Bloque 3 - Tema 4

MODELADO DE DATOS Y METODOLOGÍAS. DISEÑO

DE BASES DE DATOS. EL MODELO LÓGICO
RELACIONAL. NORMALIZACIÓN. DISEÑO LÓGICO Y
FÍSICO. PROBLEMAS DE CONCURRENCIA DE
ACCESO. MECANISMOS DE RESOLUCIÓN DE
CONFLICTOS

Preparación Oposiciones
GESTIÓN DE SISTEMAS E INFORMÁTICA DEL
ESTADO
B3T4 MODELADO DATOS Y DISEÑO BD GSI

ÍNDICE
Í N D I C E ........................................................................................................................................................ 2
1. INTRODUCCIÓN......................................................................................................................................... 3
2. MODELO ENTIDAD/RELACIÓN EXTENDIDO ............................................................................................... 4
1. Entidad ................................................................................................................................................. 5
2. Atributo ................................................................................................................................................ 6
3. Relación ................................................................................................................................................ 8
4. Dominio .............................................................................................................................................. 13
5. Extensiones del modelo Entidad-Relación .......................................................................................... 13
6. Ejemplo modelo ER extendido ............................................................................................................ 16
3. CONSTRUCCIÓN Y VALIDACIÓN DEL MODELO ER.................................................................................... 18
4. MODELO CONCEPTUAL DE DATOS EN MÉTRICA V3 ................................................................................ 19
1. Modelo conceptual en EVS 2 .............................................................................................................. 19
2. Modelo conceptual en EVS 4 .............................................................................................................. 19
3. Modelo conceptual en ASI 1 ............................................................................................................... 20
4. Modelo conceptual en ASI 6 ............................................................................................................... 20
5. DISEÑO DE BASES DE DATOS ................................................................................................................... 22
6. LA ARQUITECTURA ANSI/SPARC .............................................................................................................. 24
7. EL MODELO LÓGICO RELACIONAL ........................................................................................................... 28
1. Conceptos fundamentales del modelo relacional .............................................................................. 28
2. Reglas de integridad........................................................................................................................... 29
3. Lenguajes relaciones .......................................................................................................................... 31
4. Las 12 reglas de Codd ......................................................................................................................... 35
8. DISEÑO LÓGICO....................................................................................................................................... 37
1. Ajustes del modelo conceptual ........................................................................................................... 37
2. Obtención del modelo lógico a partir del conceptual ......................................................................... 39
3. Reglas de transformación (enfoque OO) ............................................................................................ 46
9. NORMALIZACIÓN .................................................................................................................................... 49
1. Primera Forma normal (1FN) ............................................................................................................. 50
2. Segunda Forma normal (2FN) ............................................................................................................ 51
3. Tercera Forma normal (3FN) .............................................................................................................. 52
4. Forma normal de Boyce-Codd (FNBC) ................................................................................................ 52
5. Cuarta Forma normal (4FN) ............................................................................................................... 53
6. Quinta Forma normal (5FN) ............................................................................................................... 54
7. La normalización en Métrica v3 ......................................................................................................... 55
10. DISEÑO FÍSICO .................................................................................................................................... 56
1. Traducir el esquema lógico para el SGBD específico .......................................................................... 56
2. Diseñar la representación física ......................................................................................................... 57
3. Diseñar los mecanismos de seguridad ............................................................................................... 62
4. Monitorizar y afinar el sistema .......................................................................................................... 62
5. El diseño físico de datos según Métrica v3 ......................................................................................... 63
11. PROBLEMAS DE CONCURRENCIA DE ACCESO ..................................................................................... 66
12. MECANISMOS DE RESOLUCIÓN DE CONFLICTOS................................................................................ 70
1. Mecanismos pesimistas...................................................................................................................... 70
2. Mecanismos optimistas...................................................................................................................... 74
3. Esquemas multiversión....................................................................................................................... 74
4. Tratamiento de interbloqueos ............................................................................................................ 75

PABLO ARELLANO www.theglobeformacion.com Página 2

B3T4 MODELADO DATOS Y DISEÑO BD GSI

1. INTRODUCCIÓN
Este se centra en el análisis de los datos y de los procesos de negocio de un sistema de
información, evidentemente desde un enfoque estructurado.

Por un lado, el objetivo de la modelización de datos es el conocimiento profundo de los datos

que va a manejar el sistema de información (en adelante SI) objeto de estudio, representado
por un modelo de datos, que permite obtener estructuras de datos no redundantes, sin
inconsistencias, seguras e íntegras. Al modelo que surge como primera aproximación de ese
mundo real se le llama esquema conceptual.

De otra parte, los diagramas de flujo de datos nos permiten representar los procesos de
negocio que representan el SI, mediante el análisis de las necesidades de usuario.

PABLO ARELLANO www.theglobeformacion.com Página 3

B3T4 MODELADO DATOS Y DISEÑO BD GSI

2. MODELO ENTIDAD/RELACIÓN EXTENDIDO

Comenzamos definiendo un modelo de datos como una representación gráfica orientada a la
obtención de estructuras de datos de una forma metódica, es decir, se puede considerar un
instrumento que nos facilita la representación de las necesidades del usuario.

El modelo de datos se suele representar mediante el Modelo Entidad-Relación Extendido, que

es la técnica que propone Métrica v3 (metodología de desarrollo de sistemas de información
por las Administraciones Públicas), parte de los conceptos y simbología del Modelo Entidad-
Relación creado por Peter Chen en 1.976.

Por tanto, en el desarrollo de SI siguiendo un enfoque estructurado el Modelo E-R Extendido

es el más utilizado en el campo del diseño de bases de datos.

Como ya se ha comentado en la introducción este modelo es asimilable al esquema

conceptual definido por la arquitectura ANSI/X3/SPARC, la cual será tratada en el tema
siguiente.

Así pues, el Modelo Entidad-Relación Extendido se trata de una técnica cuyo objetivo es la
representación y definición de todos los datos que se introducen, almacenan, transforman y
producen dentro de un sistema de información, sin tener en cuenta las necesidades de la
tecnología existente, ni otras restricciones.

Dado que el modelo de datos es un medio para comunicar el significado de los datos, las
relaciones entre ellos y las reglas de negocio de un sistema de información, una organización
puede obtener numerosos beneficios de la aplicación de esta técnica, pues la definición de los
datos y la manera en que éstos operan son compartidos por todos los usuarios.

Las ventajas de realizar un modelo de datos son, entre otras:

- Comprensión de los datos de una organización y del funcionamiento de la organización.
- Obtención de estructuras de datos independientes del entorno físico.
- Control de los posibles errores desde el principio, o al menos, darse cuenta de las
deficiencias lo antes posible.
- Mejora del mantenimiento.

Aunque la estructura de datos puede ser cambiante y dinámica, normalmente es mucho más
estable que la estructura de procesos. Como resultado, una estructura de datos estable e
integrada proporciona datos consistentes que puedan ser fácilmente accesibles según las
necesidades de los usuarios, de manera que, aunque se produzcan cambios organizativos, los
datos permanecerán estables.

Este diagrama se centra en los datos, independientemente del procesamiento que los
transforma y sin entrar en consideraciones de eficiencia. Por ello, es independiente del
entorno físico y debe ser una fiel representación del sistema de información objeto del

PABLO ARELLANO www.theglobeformacion.com Página 4

B3T4 MODELADO DATOS Y DISEÑO BD GSI

estudio, proporcionando a los usuarios toda la información que necesiten y en la forma en

que la necesiten.

El modelo Entidad-Relación Extendido describe con un alto nivel de abstracción la distribución

de datos almacenados en un sistema, existiendo dos elementos principales: las ENTIDADES y
las RELACIONES. Las extensiones al modelo básico añaden además los atributos de las
entidades y la jerarquía entre éstas. Estas extensiones tienen como finalidad aportar al
modelo una mayor capacidad expresiva.

Antes de detallar este modelo, existen otras técnicas para crear modelos conceptuales de base
de datos, entre las que destacamos:
- Diagramas ORM.
- Diagramas IDEF1X.
- Diagramas UML.
- Diagramas CASE*Method.

1. Entidad
Es aquel objeto, real o abstracto, acerca del cual se desea almacenar información en la base
de datos. La estructura genérica de un conjunto de entidades con las mismas características
se denomina tipo de entidad.

Un tipo de entidad describe el esquema o intensión para un conjunto de entidades que

poseen la misma estructura.

Ejemplo: tipo de entidad CONTRIBUYENTE: DNI, nombre, apellidos, dirección, nacionalidad.

Todos los contribuyentes tienen la misma estructura à Intensión.

Existen dos clases de entidades:

- Regulares: tienen existencia por sí mismas.
- Débiles: cuya existencia depende de otra entidad.

Las entidades deben cumplir las siguientes tres reglas:

- Tienen que tener existencia propia.
- Cada ocurrencia de un tipo de entidad debe poder distinguirse de las demás.
- Todas las ocurrencias de un tipo de entidad deben tener los mismos atributos.

Asociado al concepto de entidad surge el concepto de ocurrencia de entidad. Una ocurrencia

de entidad es una realización concreta de una entidad. Por ejemplo, si LIBROS es un tipo de
entidad, una ocurrencia de la misma es “UML”.

PABLO ARELLANO www.theglobeformacion.com Página 5

B3T4 MODELADO DATOS Y DISEÑO BD GSI

Así pues, las ocurrencias de un tipo de entidad se agrupan en un conjunto de entidades o

extensión.

Ejemplo: ocurrencias del tipo de entidad CONTRIBUYENTE à Extensión.

contribuyente1 (12345678, “JUAN”, “ESPAÑOL ESPAÑOL”, “Calle X”, “ESPAÑOLA”)
contribuyente2 (56781234, “ANA”, “ABAD ABAD”, “Calle Y”, “ESPAÑOLA”)
contribuyente3 (12341234, “ALBERTO”, “PEREZ SANCHEZ”, “Calle Z”, “ESPAÑOLA”)

Notación
La representación gráfica de un tipo de entidad regular es un rectángulo etiquetado con el
nombre del tipo de entidad. Un tipo de entidad débil se representa con dos rectángulos
concéntricos con su nombre en el interior.

Ejemplo: son tipos de entidades regulares libros, facturas, cuentas, clientes, ciudadanos,
ciudades, municipios.

Ejemplo: son tipos de entidades débiles ejemplar, línea de factura, movimientos. Así, la
existencia de un ejemplar depende un libro, la de una línea de factura de una factura y la de
un movimiento de una cuenta.

2. Atributo
Es una propiedad o característica de un tipo de entidad.

Se trata de la unidad básica de información que sirve para identificar o describir la entidad.
Un atributo se define sobre un dominio.

Por tanto, un atributo es una propiedad común a todas las ocurrencias de una entidad.

Ejemplo: son atributos nombre, edad, DNI o fecha de alta.

Cada tipo de entidad ha de tener un conjunto mínimo de atributos que identifiquen

unívocamente cada ocurrencia del tipo de entidad. Este atributo o atributos se denomina
identificador principal o clave primaria.

PABLO ARELLANO www.theglobeformacion.com Página 6

B3T4 MODELADO DATOS Y DISEÑO BD GSI

Supongamos que existen varios conjuntos de atributos que identifiquen unívocamente cada
ocurrencia del tipo de entidad. Solo uno será el identificador principal o clave primaria. El resto
de los conjuntos de atributos se denominarán claves candidatas o alternativas.

También ha de conocerse el concepto de superclave, que es un conjunto de atributos (no

mínimo) que permite distinguir unívocamente cada ocurrencia del tipo de entidad. Si otro
atributo unido al anterior subconjunto, el resultado seguirá siendo una superclave.
Claves candidatas Ì Superclaves

Ejemplo: dado el tipo de entidad CONTRIBUYENTE(DNI, nombre, apellidos, dirección,

nacionalidad), podemos concluir que:
Nombre no es una clave
Apellidos no es una clave
(nombre, apellidos) no es una clave
DNI es una clave candidata à DNI es clave primaria
(DNI, nombre) es una superclave
(DNI, dirección) es una superclave

Se pueden definir restricciones sobre los atributos, según las cuales un atributo puede ser:
- Simple: son atributos que no están divididos en partes, es decir, representan un valor
indivisible.
- Compuesto: atributo que puede ser subdividido en atributos más elementales.
Ejemplo: atributo Dirección à vía, nombre, ciudad, provincia y código postal.
- Univaluado: atributo que sólo puede tomar un valor para todas y cada una de las
ocurrencias del tipo de entidad al que pertenece.
- Multivaluado: atributo que puede tomar más de un valor para algunas de las ocurrencias
del tipo de entidad al que pertenece.
Ejemplo: atributo teléfono puede tomar más de un valor a la vez.
- Obligatorio: atributo que tiene que tomar al menos un valor para todas y cada una de las
ocurrencias del tipo de entidad al que pertenece.
- Derivado: atributo cuyo valor se obtiene a partir de los valores de otros atributos de la
misma o de diferente tipo de entidad.
Ejemplo: atributo edad deriva del atributo fecha de nacimiento.

PABLO ARELLANO www.theglobeformacion.com Página 7

B3T4 MODELADO DATOS Y DISEÑO BD GSI

Notación
Un atributo se representa mediante una elipse, con su nombre dentro, conectada por una
línea al tipo de entidad o relación.

En lugar de una elipse puede utilizarse un círculo con el nombre dentro, o un círculo más
pequeño con el nombre del atributo a un lado. También pueden representarse en una lista
asociada a la entidad. El identificador aparece con el nombre marcado o subrayado, o bien
con su círculo en negro.

Ejemplo: atributos del tipo de entidad Cliente. Destaca el atributo Dirección que es
multivaluado.

3. Relación
Es una asociación o correspondencia existente entre una o varias entidades.

Una ocurrencia de la relación es la asociación concreta de ocurrencias de entidad de diferentes

entidades. Así, por ejemplo, si tenemos las entidades EMPLEADO y DEPARTAMENTO, y la
relación Trabaja en, una ocurrencia será “Pepe” trabaja en el “Departamento de Informática”.

PABLO ARELLANO www.theglobeformacion.com Página 8

B3T4 MODELADO DATOS Y DISEÑO BD GSI

La relación puede ser:

- Regular: si asocia tipos de entidad regulares.
- Débil: si asocia un tipo de entidad débil con un tipo de entidad regular. Dentro de las
relaciones débiles se distinguen:
o La dependencia en existencia: cuando las ocurrencias de un tipo de entidad débil no
pueden existir sin la ocurrencia de la entidad regular de la que dependen.
o La dependencia en identificación: cuando, además de lo anterior, las ocurrencias del
tipo de entidad débil no se pueden identificar sólo mediante sus propios atributos, sino
que se les tiene que añadir el identificador de la ocurrencia de la entidad regular de la
cual dependen.
Clave primaria entidad débil = clave primaria entidad fuerte + clave entidad débil

Ejemplo: el tipo de entidad regular CUENTA(numero_cuenta, saldo) se relaciona a través de

la relación “Compuesta por” con el tipo de entidad débil MOVIMIENTO(numero_mvto, valor).

La relación “Compuesta por” es débil (asocia un tipo regular con un tipo de entidad débil) y la
dependencia es en identificación ya que un movimiento concreto no se puede identificar si no
se conoce la cuenta sobre la que se hace. Por tanto, tenemos:
numero_cuenta es la clave primaria de CUENTA.
numero_cuenta, numero_mvto es la clave primaria de MOVIMIENTO.

Además, se dice que una relación es exclusiva cuando la existencia de una relación entre dos
tipos de entidades implica la no existencia de las otras relaciones.

Ejemplo: el tipo de entidad FUNCIONARIO tiene una relación con el tipo de entidad CCAA y
otra con el tipo de entidad AYUNTAMIENTOS. Pues ambas relaciones son exclusivas ya que un
funcionario solo podrá trabajar en una administración a la vez.

Una relación se caracteriza por:

- NOMBRE: que lo distingue unívocamente del resto de relaciones del modelo.

- GRADO: número de tipos de entidad sobre las que se establece la relación. La relación del
ejemplo anterior es binaria, es decir, de grado dos. En función del grado las relaciones se
clasifican en:
o Unarias: una entidad se relaciona consigo misma (relaciones reflexivas). GRADO 1
o Binarias: entidades relacionadas dos a dos. GRADO 2
o Ternarias: relación entre tres entidades. GRADO 3
o N-arias: relación entre n entidades. GRADO 4

PABLO ARELLANO www.theglobeformacion.com Página 9

B3T4 MODELADO DATOS Y DISEÑO BD GSI

- TIPO DE CORRESPONDENCIA (o razón de cardinalidad): es el número máximo de

ocurrencias de cada tipo de entidad que pueden intervenir en una ocurrencia de la relación
que se está tratando.

Conceptualmente se pueden identificar tres clases de relaciones:

o Relaciones 1:1 (uno a uno): cada ocurrencia de una entidad se relaciona con una
y sólo una ocurrencia de la otra entidad.

o Relaciones 1:N (uno a muchos): cada ocurrencia de una entidad puede estar
relacionada con cero, una o varias ocurrencias de la otra entidad.

o Relaciones M:N (muchos a muchos): cada ocurrencia de una entidad puede estar
relacionada con cero, una o varias ocurrencias de la otra entidad y cada
ocurrencia de la otra entidad puede corresponder a cero, una o varias
ocurrencias de la primera.

- CARDINALIDAD: representa la participación en la relación de cada una de las entidades

afectadas, es decir, el número máximo y mínimo de ocurrencias de un tipo de entidad que
pueden estar interrelacionadas con una ocurrencia de otro tipo de entidad (min, max). La
cardinalidad máxima coincide con el tipo de correspondencia. MAX= 1, n

Según la cardinalidad, una relación es:

o Obligatoria: cuando para toda ocurrencia de un tipo de entidad existe al menos una
ocurrencia del tipo de entidad asociado. (1, max)
o Opcional: cuando, para toda ocurrencia de un tipo de entidad, puede existir o no una
o varias ocurrencias del tipo de entidad asociado. (0, max)

Las relaciones pueden tener atributos propios, de forma similar que los atributos de los tipos
de entidad

Notación
Se representa por un rombo unido a las entidades relacionadas por dos líneas rectas a los
lados. El tipo de correspondencia se representa gráficamente con una etiqueta 1:1, 1:N o M:N,
cerca de alguno de los vértices del rombo, o bien situando cada número o letra cerca de la
entidad correspondiente, para mayor claridad.

PABLO ARELLANO www.theglobeformacion.com Página 10

B3T4 MODELADO DATOS Y DISEÑO BD GSI

La representación gráfica de las cardinalidades se realiza mediante una etiqueta del tipo (0,1),
(1,1), (0,n) o (1,n), que se coloca en el extremo de la entidad que corresponda. Si se
representan las cardinalidades, la representación del tipo de correspondencia es redundante.

Las relaciones reflexivas se consideran un caso particular, en las que una

entidad se relaciona consigo misma. Cabe resaltar el concepto de ROL o
papel de la entidad (extensible a todo tipo de relaciones pero que resulta
agravado en las relaciones reflexivas), esto es, el significado que tiene la
participación de las ocurrencias en la relación. El rol se especifica en los
extremos de la relación.

Para relaciones reflexivas el rol de la entidad debe especificarse, en el resto se considera

opcional.

Ejemplo: en la siguiente relación entre ocurrencias del tipo de entidad EMPLEADO, conviene
distinguir a los empleados que asumirán el rol de “JEFE” y a los empleados que adoptarán el
papel de “SUBORDINADO”.

SUBORDINADO

JEFE

En la representación de las relaciones exclusivas se incluye un arco sobre las líneas que
conectan el tipo de entidad a los dos o más tipos de relación.

PABLO ARELLANO www.theglobeformacion.com Página 11

B3T4 MODELADO DATOS Y DISEÑO BD GSI

Ejemplo: dados los tipos de entidad PERSONA y EDIFICIO y las relaciones USA y POSEE entre
ambos tipos de entidad, tenemos:

Una persona usa uno o más edificios y un edificio puede ser usado (o no) por una o varias
personas. Por otro lado, una persona posee uno o más edificios y un edificio es poseído por
una persona.

Entonces, el tipo de correspondencia y la cardinalidad es la que se presenta a continuación (se

advierte que por claridad expositiva se van a representar ambas, pero se reitera que la
cardinalidad incluye el tipo de correspondencia):

PABLO ARELLANO www.theglobeformacion.com Página 12

B3T4 MODELADO DATOS Y DISEÑO BD GSI

TIPO DE N:M
CORRESPONDENCIA
Número máximo de ocurrencias de
cada tipo de entidad que pueden
intervenir en una ocurrencia de la
relación que se está tratando 1:N

CARDINALIDAD (1,n) (0,n)

Números mínimo y máximo de
ocurrencias de un tipo de entidad que
pueden estar relacionadas con una
ocurrencia del otro tipo de entidad (0,1) (1,n)

4. Dominio
Es un conjunto nominado de valores homogéneos. El dominio tiene existencia propia con
independencia de cualquier entidad, relación o atributo.

Así pues, una cierta característica o propiedad (atributo) de un objeto toma valores que
pertenecen a un determinado dominio.

El dominio para un atributo puede ser, entre otros, un conjunto de enteros, de números reales
o de caracteres.

5. Extensiones del modelo Entidad-Relación

Además de estos elementos, existen extensiones del modelo entidad/relación que incorporan
determinados conceptos o mecanismos de abstracción para facilitar la representación de
ciertas estructuras del mundo real:
- La GENERALIZACIÓN permite abstraer un tipo de entidad de nivel superior (supertipo) a
partir de varios tipos de entidad (subtipos); en estos casos los atributos comunes y
relaciones de los subtipos se asignan al supertipo. Se pueden generalizar por ejemplo los
tipos profesor y estudiante obteniendo el supertipo persona.

- La ESPECIALIZACIÓN es la operación inversa a la generalización, en ella un supertipo se

descompone en uno o varios subtipos, los cuales heredan (automáticamente) todos los
atributos y relaciones del supertipo, además de tener los suyos propios. Se denominan
relaciones "es un".

PABLO ARELLANO www.theglobeformacion.com Página 13

B3T4 MODELADO DATOS Y DISEÑO BD GSI

Ejemplo: es el caso del tipo empleado, del que se pueden obtener los subtipos Profesor y
PAS.

Ejemplo: jerarquía del tipo de entidad Estudiante.

- CATEGORÍAS. Se denomina categoría al subtipo que aparece como resultado de la unión

de varios tipos de entidad. En este caso, hay varios supertipos y un sólo subtipo. Si por
ejemplo se tienen los tipos persona y compañía y es necesario establecer una relación con
vehículo, se puede crear propietario como un subtipo unión de los dos primeros.

- La AGREGACIÓN consiste en construir un nuevo tipo de entidad como composición de

otros y su tipo de relación y así poder manejarlo en un nivel de abstracción mayor.

Ejemplo: se tienen los tipos de entidad empresa y solicitante de empleo relacionados

mediante el tipo de relación entrevista, pero es necesario que cada entrevista se
corresponda con una determinada oferta de empleo. Como no se permite la relación entre
tipos de relación, se puede crear un tipo de entidad compuesto por empresa, entrevista y
solicitante de empleo y relacionarla con el tipo de entidad oferta de empleo.

El proceso inverso se denomina desagregación.

PABLO ARELLANO www.theglobeformacion.com Página 14

B3T4 MODELADO DATOS Y DISEÑO BD GSI

- La ASOCIACIÓN, consiste en relacionar dos tipos de entidades que normalmente son de

dominios independientes, pero coyunturalmente se asocian.

La existencia de supertipos y subtipos, en uno o varios niveles, da lugar a una jerarquía, que
permitirá representar una restricción del mundo real.

Notación
La representación de las jerarquías se realiza mediante un triángulo invertido, con la base
paralela al rectángulo que representa el supertipo y conectando a éste y a los subtipos. Si la
división en subtipos viene determinada en función de los valores de un atributo discriminante,
éste se representará asociado al triángulo que representa la relación.

En el triángulo se representará:
- Con una letra d el hecho de que los subtipos sean disjuntos.
- Con un círculo o una O si los subtipos pueden solaparse.
- Con una U el caso de uniones por categorías.
- La presencia de una jerarquía total se representa con una doble línea entre el supertipo y
el triángulo.

De las representaciones anteriores podemos enunciar las siguientes definiciones:

- Jerarquía TOTAL: toda ocurrencia del supertipo pertenece siempre a algún subtipo.
- Jerarquía PARCIAL: una ocurrencia del supertipo no pertenece a algún subtipo.
- Jerarquía DISJUNTA: una ocurrencia del supertipo solo puede pertenecer a uno de los
subtipos.
- Jerarquía SOLAPADA: una ocurrencia del supertipo puede pertenecer a varios subtipos.

PABLO ARELLANO www.theglobeformacion.com Página 15

B3T4 MODELADO DATOS Y DISEÑO BD GSI

A partir de ahí, se pueden mezclar cualquiera de las opciones {total | parcial} con cualquier
otra de las siguientes {disjunta | solapada}.

6. Ejemplo modelo ER extendido

Modelo entidad-relación extendido para un sistema de gestión de técnicos y su asignación a
proyectos dentro de una empresa u organización.

Como se aprecia en el diagrama, TÉCNICO es un subtipo de EMPLEADO, generado por

especialización, pues era necesario para establecer la relación Trabaja en con PROYECTO, ya
que no todos los empleados de la empresa, como los administrativos, son susceptibles de
trabajar en un proyecto. La entidad TÉCNICO tendrá los atributos de EMPLEADO más el
atributo nivel.

PABLO ARELLANO www.theglobeformacion.com Página 16

B3T4 MODELADO DATOS Y DISEÑO BD GSI

PABLO ARELLANO www.theglobeformacion.com Página 17

B3T4 MODELADO DATOS Y DISEÑO BD GSI

3. CONSTRUCCIÓN Y VALIDACIÓN DEL MODELO ER

Podemos establecer para la construcción del modelo conceptual de datos las siguientes fases:

1. Identificar las entidades del SI objeto de desarrollo.

Para identificar los tipos de entidad sirve de ayuda clasificar la información en:
- Objetos reales: máquinas, edificios, almacenes.
- Personas: empleados, funcionarios, clientes, proveedores.
- Actividades del sistema: licencias, facturas, albaranes, expedientes, documentos.
- Objetos abstractos: categorías de personal, departamentos.

2. Determinar los identificadores principales de las entidades.

Para determinarlos, se obtendrán aquellos atributos que identifiquen unívocamente cada
ocurrencia de cada tipo de entidad. Si para un tipo de entidad hubiera varios, se elegirá
solo uno. Aunque resulta obvio, el conjunto de atributos que forman el identificador
principal no pueden tomar valores sin información (nulos).

3. Establecer las relaciones entre las entidades y el grado de las mismas.

Para establecer las asociaciones o relaciones entre entidades, se estudia cada una de las
relaciones de una entidad con las demás entidades identificadas, para comprobar si dichas
relaciones tienen sentido e importancia para el sistema que se está desarrollando.

Del conjunto de relaciones se estudiará su cardinalidad y la posibilidad de relaciones

exclusivas.

4. Dibujar el modelo de datos.

Dibujar el diagrama según la notación descrita.

5. Identificar y describir los atributos de cada entidad.

Para identificar los atributos de cada entidad, habrá que tener en cuenta todas aquellas
propiedades de cada entidad en las que el sistema tenga interés. Luego se incorporarán al
diagrama.

6. Verificaciones.
Una vez construido el modelo Entidad-Relación, hay que analizar si se presentan
redundancias. Para poder asegurar su existencia se deben estudiar con mucho
detenimiento las cardinalidades mínimas de las entidades, así como la semántica de las
relaciones.

Los atributos redundantes, los que se derivan de otros elementos mediante algún cálculo,
deben ser eliminados del modelo Entidad-Relación o marcarse como redundantes.

Igualmente, las relaciones redundantes deben eliminarse del modelo, comprobando que
al eliminarlas sigue siendo posible el paso, tanto en un sentido como en el inverso, entre
las dos entidades que unían.

PABLO ARELLANO www.theglobeformacion.com Página 18

 B3T4 MODELADO DATOS Y DISEÑO BD GSI

4. MODELO CONCEPTUAL DE DATOS EN MÉTRICA V3

La metodología Métrica v3, contempla el modelado conceptual en los procesos de EVS y ASI.
Concretamente en las actividades:
- EVS 2: Estudio de la situación actual.
- EVS 4: Estudio de alternativas de solución.
- ASI 1: Definición del sistema.
- ASI 6: Elaboración del modelo de datos.

1. Modelo conceptual en EVS 2

Teniendo en cuenta el objetivo del estudio de la situación actual, se realiza una valoración de
la información existente acerca de los sistemas de información afectados. En función de dicha
valoración, se especifica el nivel de detalle con que se debe llevar a cabo el estudio.

Tarea Productos Técnicas/Prácticas Participantes

Descripción de Analistas
los Sistemas de Descripción Lógica del Sistema Modelo Entidad / Usuarios Expertos
EVS 2.3 Actual Relación Extendido
Información Equipo de Soporte
(entre otros) (entre otros)
Existentes Técnico

Si se ha decidido describir los sistemas a nivel lógico, y si existe un conocimiento suficiente de

los sistemas de información a especificar, puede hacerse directamente, aplicando las técnicas
de modelización y siguiendo un método descendente. Si no se dispone del conocimiento
suficiente, se construyen los modelos a partir de la descripción del modelo físico, es decir, de
forma ascendente.

2. Modelo conceptual en EVS 4

Si la alternativa de solución incluye un desarrollo a medida, se debe incorporar en la
descripción de la misma un modelo abstracto de datos y un modelo de procesos, y en
orientación a objetos, un modelo de negocio y un modelo de dominio.

Tarea Productos Técnicas/Prácticas Participantes

Jefe de Proyecto
Analistas
Descripción de Modelo Abstracto de Modelo Entidad / Usuarios Expertos
EVS 4.2 las Alternativas Datos (EST) Relación Extendido Técnicos de sistemas
de Solución (entre otros) (entre otros) Responsables de
Seguridad
Especialistas en Comunicaciones

PABLO ARELLANO www.theglobeformacion.com Página 19

 B3T4 MODELADO DATOS Y DISEÑO BD GSI

3. Modelo conceptual en ASI 1

En ASI 1.1 se obtiene un modelo conceptual de datos identificando las entidades y relaciones
que forman parte del sistema de información objeto de este análisis a partir del modelo
abstracto de datos generado en la tarea Evaluación de Alternativas y Selección (EVS 6.2).

Tarea Productos Técnicas/Prácticas Participantes

Sesiones de Trabajo
Catálogo de Requisitos
Catalogación Jefe de Proyecto
Glosario
Determinación Diagrama de Flujo de Datos Analistas
Contexto del Sistema (EST)
ASI 1.1 del Alcance del Modelo Entidad / Directores de los
Modelo Conceptual de Datos (EST)
Sistema Relación Extendido Usuarios
Modelo de Negocio (OO)
Casos de Uso
Modelo de Dominio (OO)
Diagrama de Clases

4. Modelo conceptual en ASI 6

El objetivo de esta actividad que se lleva a cabo únicamente en el caso de Análisis Estructurado
es identificar las necesidades de información de cada uno de los procesos que conforman el
sistema de información, con el fin de obtener un modelo de datos que contemple todas las
entidades, relaciones, atributos y reglas de negocio necesarias para dar respuesta a dichas
necesidades.

Tarea Productos Técnicas/Prácticas Participantes

Elaboración del Modelo Modelo Entidad /
ASI 6.1 Modelo Conceptual de Datos Analistas
Conceptual de Datos Relación Extendido

Elaboración del Modelo Modelo Entidad /

ASI 6.2 Modelo Lógico de Datos Analistas
Lógico de Datos Relación Extendido

ASI 6.1 Elaboración del Modelo Conceptual de Datos

Para la elaboración del modelo conceptual de datos, generalmente se parte de un modelo

conceptual especificado en la tarea Determinación del Alcance del Sistema (ASI 1.1).

El objetivo de esta tarea es identificar y definir las entidades que quedan dentro del ámbito
del sistema de información, los atributos de cada entidad (diferenciando aquellos que pueden
convertirse en identificadores de la entidad), los dominios de los atributos y las relaciones
existentes entre las entidades, indicando las cardinalidades mínimas y máximas.

Estas relaciones pueden ser múltiples, recursivas, de explosión e implosión, generalizaciones

y agregaciones.

PABLO ARELLANO www.theglobeformacion.com Página 20

B3T4 MODELADO DATOS Y DISEÑO BD GSI

También se identifican aquellas entidades de datos que no forman parte del modelo, pero que
están relacionadas con alguna entidad del mismo, indicando a su vez el tipo de relación y las
cardinalidades mínimas y máximas.

Asimismo, se pueden describir las reglas de negocio, también llamadas restricciones

semánticas, en lenguaje natural o mediante expresiones lógicas.

ASI 6.2 Elaboración del Modelo Lógico de Datos

En esta tarea se obtiene el modelo lógico de datos a partir del modelo conceptual para lo cual
se realizarán las acciones siguientes:
- Resolver las relaciones complejas que pudieran existir entre las distintas entidades.
- Eliminar las relaciones redundantes que puedan surgir como consecuencia de la resolución
de las relaciones complejas.
- Eliminar cualquier ambigüedad sobre el significado de los atributos.
- Identificar las relaciones de dependencia entre entidades .
- Completar la información de las entidades y los atributos, una vez resueltas las relaciones
complejas.
- Revisar y completar los identificadores de cada entidad.

También se debe especificar para cada entidad el número máximo y medio de ocurrencias,
estimaciones de crecimiento por periodo, tipo y frecuencia de acceso, así como aquellas
características relativas a la seguridad, confidencialidad, disponibilidad, etc. consideradas
relevantes.

PABLO ARELLANO www.theglobeformacion.com Página 21

B3T4 MODELADO DATOS Y DISEÑO BD GSI

5. DISEÑO DE BASES DE DATOS

El diseño y construcción de una base de datos es un proceso de abstracción y modelización de
un problema real, conforme a unas reglas y formalismos determinados, con el objetivo de
conseguir una representación del mismo tratable por el ordenador.

Esto implica partir de un problema claramente determinado, definir cuáles son las entidades
que participan en el mismo y sus atributos (fase de abstracción), construir un modelo y, por
último, transformarlo para su implementación mediante algún lenguaje o herramienta
concretos.

El problema de la modelización de datos comienza con el estudio y captura de requisitos en la

etapa conocida como Análisis. Con estos requisitos es posible representar el problema desde
un punto de vista conceptual, obteniendo el modelo conceptual a través de la técnica
denominada Modelo de Entidad-Relación Extendido.

Una vez validado es posible transformarlo a un modelo lógico específico (jerárquico, red,
relacional u orientado a objetos) dentro de la etapa conocida como Diseño.

Finalmente, se hace necesario implantar este modelo lógico en alguna de las soluciones
concretas de SGBD (modelo físico) dentro de la etapa conocida como Construcción del
sistema.

Modelo Modelo Modelo

conceptual lógico físico
(E/R) (relacional) (en SGBD)

El diseño lógico es el proceso de construir un esquema de la información que utiliza una

organización teniendo en cuenta un modelo lógico independiente del SGBD que se vaya a
utilizar y de cualquier otra consideración física.

En esta etapa, se transforma el esquema conceptual en un esquema lógico que utilizará las
estructuras de datos del modelo lógico en el que se basa el SGBD (jerárquico, red, relacional,
orientado a objetos). Conforme se va desarrollando el esquema lógico, éste se va probando y
validando con los requisitos de usuario.

La normalización es una técnica que se utiliza para comprobar la validez de los esquemas
lógicos basados en el modelo relacional, ya que asegura que las relaciones (tablas) obtenidas
no tienen datos redundantes, obteniéndose el modelo lógico de datos normalizado.

Tanto el diseño conceptual, como el diseño lógico, son procesos iterativos, tienen un punto
de inicio y se van refinando continuamente. Ambos se deben ver como un proceso de
aprendizaje en el que el diseñador va comprendiendo el funcionamiento de la organización y

PABLO ARELLANO www.theglobeformacion.com Página 22

B3T4 MODELADO DATOS Y DISEÑO BD GSI

el significado de los datos que maneja. Por tanto, el diseño conceptual y el diseño lógico son
etapas clave para conseguir un sistema que funcione correctamente.

El diseño físico es el proceso de descripción de la implementación de la base de datos en

memoria secundaria: estructuras de almacenamiento y métodos de acceso que garanticen un
acceso eficiente a los datos. En general, el propósito del diseño físico es describir cómo se va
a implementar físicamente el esquema lógico obtenido en la fase anterior.

PABLO ARELLANO www.theglobeformacion.com Página 23

B3T4 MODELADO DATOS Y DISEÑO BD GSI

6. LA ARQUITECTURA ANSI/SPARC
Las bases de datos son parte integral de cualquier sistema de información. Por tanto, una de
las características que deben presentar es la capacidad de adaptación a cambios en el entorno.
Estos cambios, inevitables en cualquier organización, pueden ser físicos (cambios en el
hardware, en el formato de los ficheros, etc.) o lógicos (cambios en los programas, en el
lenguaje de programación, etc.).

No es deseable que un cambio en el formato de archivo de los datos obligue a rehacer la

aplicación que accede a los mismos. Es necesario, pues, independizar la estructura lógica de
los datos de la forma en que estos se guardan físicamente. Así, cualquier cambio en uno de
los dos niveles será transparente para el otro, facilitando la tarea de mantenimiento, tanto de
las aplicaciones como de las bases de datos.

Esta independencia entre el modelo lógico de los datos y su estructura física es la que
proporciona la arquitectura en 3 niveles del Instituto Nacional de Estandarización Americano
(ANSI). Según este organismo la independencia de los datos es la capacidad de un sistema de
gestión de base de datos para permitir que las referencias a los datos a través de los
programas estén aisladas de los posibles cambios y diferentes usos que el entorno pueda
propiciar, como pueden ser: la forma de almacenamiento, el modo de compartición con otros
programas o el modo de organización para mejorar el rendimiento del sistema de base de
datos.

Independencia de los datos

La arquitectura de tres niveles es útil para explicar el concepto de independencia de
datos que podemos definir como la capacidad para modificar el esquema en un nivel del
sistema sin tener que modificar el esquema del nivel inmediato superior.

Se pueden definir dos tipos de independencia de datos:

- La independencia LÓGICA es la capacidad de modificar el esquema conceptual sin tener
que alterar los esquemas externos ni los programas de aplicación. Se puede modificar el
esquema conceptual para ampliar la base de datos o para reducirla. Si, por ejemplo, se
reduce la base de datos eliminando una entidad, los esquemas externos que no se refieran
a ella no deberán verse afectados.

- La independencia FÍSICA es la capacidad de modificar el esquema interno sin tener que

alterar el esquema conceptual (o los externos). Por ejemplo, puede ser necesario
reorganizar ciertos ficheros físicos con el fin de mejorar el rendimiento de las operaciones
de consulta o de actualización de datos. Dado que la independencia física se refiere sólo a
la separación entre las aplicaciones y las estructuras físicas de almacenamiento, es más
fácil de conseguir que la independencia lógica.

Para conseguir este ideal de independencia, ANSI propone que las bases de datos se
construyan siguiendo un modelo o arquitectura de 3 niveles:

PABLO ARELLANO www.theglobeformacion.com Página 24

B3T4 MODELADO DATOS Y DISEÑO BD GSI

- Nivel externo o lógico.

- Nivel conceptual.
- Nivel físico o interno.

Estos tres niveles están organizados de forma jerárquica, siendo el nivel físico el más cercano
a la máquina y el nivel externo aquél con el que interactúa el usuario. Esta arquitectura por
capas sirve para aislar al usuario de las complejidades del modelo de datos y de
almacenamiento físico de la base, ya que sólo se le permitirá ver la parte lógica de la base
necesaria para su trabajo. Además, también aísla el modelo lógico de datos (aquí llamado
conceptual) de la implementación específica que se realice del mismo, por lo que, en teoría,
éste sería portable de unos gestores de bases de datos a otros. Todo ello dio lugar a la
denominada Arquitectura ANSI/X3/SPARC.

Nivel LÓGICO o EXTERNO

En este nivel se guardan las distintas vistas parciales de la base de datos que se muestran a
los usuarios y/o aplicaciones. Puesto que no todos los programas ni las personas que acceden
a la base de datos necesitan tener una visión total de la información guardada en la misma,
resulta conveniente crear vistas o esquemas específicos según las necesidades particulares de
cada uno.

La existencia de este nivel aísla por completo a los usuarios y/o aplicaciones no sólo del
aspecto físico de la base de datos, sino también de cualquier parte de la misma que no esté
directamente relacionada con la tarea que deben desempeñar, aumentando así la
independencia y la protección frente a cambios en otras áreas de la organización.
Adicionalmente, esta capa también aumenta la seguridad de los datos, ya que, como

PABLO ARELLANO www.theglobeformacion.com Página 25

B3T4 MODELADO DATOS Y DISEÑO BD GSI

consecuencia de la creación de vistas parciales de la base de datos, los usuarios no disponen

de acceso más que a partes seleccionadas de la misma, disminuyendo así la posibilidad de
consultar, modificar o borrar datos privilegiados.

A partir del nivel externo se crea el esquema externo para cada base de datos en concreto.
Los esquemas externos pueden ser múltiples para una misma base de datos y además se
puede producir anidamiento entre ellos. El esquema externo queda representado por los
datos que de forma efectiva pueda acceder cada usuario y/o aplicación, más los permisos de
acceso efectivos sobre los mismos.

Por razones de eficiencia del procesamiento de las consultas, una vista puede estar
materializada, es decir, la consulta se evalúa y el resultado se almacena físicamente. Cuando
las relaciones de la base de datos se actualizan, la vista materializada se debe actualizar
correspondientemente.

Nivel CONCEPTUAL
Este modelo pretende reflejar la estructura y relaciones existentes entre los datos del mundo
real que se van a guardar en la base de datos, aislando entre sí los niveles externo (vista del
usuario) e interno (vista de la máquina).

Para construir el esquema es necesario definir el universo del discurso o, lo que es lo mismo,
acotar aquella parte del mundo real que se quiere modelar, incluyendo todos los elementos
o características relevantes y excluyendo aquellas que pese a existir en el problema original
no son relevantes. Para ello, se utiliza típicamente la técnica de Modelo Entidad-Relación
Extendido.

A partir del modelo conceptual se obtiene el esquema conceptual que se identifica mediante
las estructuras de datos, relaciones y restricciones.

Dentro de este nivel se incluye también la manera de obtener una adecuación del mismo al
entorno de implantación elegido, es decir, el modelo lógico.

El modelo lógico de datos se define como un conjunto de conceptos, reglas y convenciones

que permiten describir un modelo conceptual. Los modelos de datos comúnmente utilizados
son:
− Modelo jerárquico: presenta una estructura en árbol donde nodos y ramas siguen una
relación del tipo 1:N.
− Modelo Codasyl: estructura en red donde se establecen relaciones N:M. Es más flexible
que el jerárquico.
− Modelo relacional: presenta estructuras de la teoría matemática de conjuntos (álgebra
relacional) y/o de la lógica de predicados (cálculo relacional). Permite el procesamiento de
conjuntos de datos y no simples registros como en los anteriores. Se caracteriza por
disponer los datos organizados en tablas (relaciones) que cumplen ciertas restricciones.
− Modelo orientado a objetos.

PABLO ARELLANO www.theglobeformacion.com Página 26

B3T4 MODELADO DATOS Y DISEÑO BD GSI

Cada uno de estos modelos tiene sus características únicas que los hacen más adecuados para
modelar unos problemas u otros, así mismo, el modelo elegido va a condicionar en gran
medida los lenguajes de datos utilizados, ya que la propia estructura del modelo llega a
imponer determinadas formas de acceder a los datos.

Nivel INTERNO o FÍSICO

En este nivel se especifica qué, cómo y dónde se van a almacenar los datos físicamente. Se
ocupa de tratar con el sistema operativo, con el sistema de ficheros, con los dispositivos de
entrada/salida y, en general, con todos aquellos aspectos de bajo nivel necesarios para
almacenar efectivamente la información en el ordenador. El contenido de este nivel depende
por completo de la combinación hardware/software que se emplee en cada instalación.

Del nivel físico se deriva el esquema interno, que contiene las definiciones de los registros
guardados, los métodos de representación, los campos de datos y los índices. Hay un solo
esquema interno por base de datos.

Como resumen de esta arquitectura, su propósito principal es que el Esquema Conceptual sea
una descripción estable de la organización e independiente de las “vistas” y de la forma de
almacenamiento de los datos. Debido a esta independencia de niveles, las Bases de Datos
pueden ser flexibles y adaptables a los cambios.

PABLO ARELLANO www.theglobeformacion.com Página 27

B3T4 MODELADO DATOS Y DISEÑO BD GSI

7. EL MODELO LÓGICO RELACIONAL

El modelo relacional es un modelo con sólidos fundamentos matemáticos, basado en la teoría
de conjuntos. Fue definido por E. F. Codd en 1970.

Las características fundamentales del modelo relacional son:

− Las estructuras de datos son simples: se trata de relaciones que se presentan al usuario
en forma de tablas bidimensionales, permitiendo un alto grado de independencia de la
información, con respecto al medio físico de almacenamiento de los datos.
− Proporciona una base sólida para la consistencia de los datos a través de las reglas de
integridad. Igualmente, el proceso de normalización, al eliminar ciertas anomalías que
pueden presentarse en las relaciones, representa una valiosa ayuda para el diseño de la
BD.
− Permite la manipulación de las relaciones en forma orientada a conjuntos. Esto ha
conducido al desarrollo de lenguajes muy potentes basados, bien en la teoría de conjuntos
(álgebra relacional), bien en la lógica de predicados (cálculo relacional).

1. Conceptos fundamentales del modelo relacional

El esquema de una BDR se compone de uno o más esquemas de relación y de un conjunto de
restricciones de integridad.

Un esquema de relación consiste en el nombre de relación, seguido de los nombres de los

atributos:
Nombre_Relación (Atributo1, Atributo2, ... , AtributoN)

La definición formal de una relación: “Dados los dominios D1, D2, … , Dn (no necesariamente
distintos), R es una relación entre estos n conjuntos si es un conjunto de n tuplas (d1, d2,…, dn)
tal que d1 pertenece a D1... dn pertenece a Dn”.

Un dominio es un conjunto de valores.

Cada atributo, o propiedad con interés informativo de una relación está asociado a un dominio
del que toma sus posibles valores.

El número de atributos de una relación define su grado, mientras que el número de tuplas de
la relación define su cardinalidad.

La extensión u ocurrencia de una relación es una tabla donde las filas corresponden a las
tuplas y las columnas a los atributos, es decir, es el conjunto de tuplas de una relación.

PABLO ARELLANO www.theglobeformacion.com Página 28

B3T4 MODELADO DATOS Y DISEÑO BD GSI

GRADO

Atributo1 Atributo2 … AtributoN

TUPLA

CARDINALIDAD

De estas definiciones se deducen las características de una tabla de estructura relacional:

− Cada tabla debe contener un solo tipo de filas. El formato de cada fila queda definido por
el esquema de la relación. Es decir, todas las filas tienen las mismas columnas y formato.
− Cada fila tiene que ser única, no puede haber filas duplicadas.
− El orden de las filas dentro de una tabla es indiferente.
− Cada columna debe estar identificada por un nombre específico.
− El orden de las columnas dentro de una tabla es indiferente.
− Cada columna debe extraer sus valores de un dominio.
− Un mismo dominio podrá servir para definir los valores de varias columnas diferentes.
− El valor individual de la intersección de cualquier fila y columna será un único dato.

2. Reglas de integridad
Permiten definir propiedades de los datos que no pueden ser capturadas basándose en
conjuntos y relaciones. Las razones para que un modelo requiera restricciones son:
− Semántica: permite reflejar más exactamente la información a modelar.
− Integridad: comunica al SGBD qué estados de la BD están permitidos.

Al definir cada atributo sobre un dominio se impone una restricción sobre el conjunto de
valores permitidos para cada atributo. A este tipo de restricciones se les denomina
restricciones de dominios.

Hay además dos reglas de integridad muy importantes que son restricciones que se deben
cumplir en todas las bases de datos relacionales y en todos sus estados o instancias (las reglas
se deben cumplir todo el tiempo). Estas reglas son la regla de integridad de entidades y la
regla de integridad referencial.

PABLO ARELLANO www.theglobeformacion.com Página 29

B3T4 MODELADO DATOS Y DISEÑO BD GSI

Antes de definirlas, es preciso conocer el concepto de nulo. Cuando en una tupla un atributo
es desconocido, se dice que es nulo. Un nulo no representa el valor cero ni la cadena vacía,
éstos son valores que tienen significado. El nulo implica ausencia de información, bien porque
al insertar la tupla se desconocía el valor del atributo, o bien porque para dicha tupla el
atributo no tiene sentido.

Regla de integridad de la ENTIDAD

Se aplica a las claves primarias de las relaciones. Ninguno de los atributos que componen la
clave primaria puede ser nulo.

Por definición, una clave primaria es un identificador irreducible que se utiliza para identificar
de modo único las tuplas. Que sea irreducible significa que ningún subconjunto de la clave
primaria sirve para identificar las tuplas de modo único. Si se permite que parte de la clave
primaria sea nula, se está diciendo que no todos sus atributos son necesarios para distinguir
las tuplas, con lo que se contradice la irreducibilidad.

Esta regla sólo se aplica a las relaciones y a las claves primarias, no a las claves alternativas.

Regla de integridad REFERENCIAL

La segunda regla de integridad se aplica a las claves ajenas. Si en una relación hay alguna clave
ajena, sus valores deben coincidir con valores de la clave primaria a la que hace referencia, o
bien, deben ser completamente nulos.

Ejemplo: clave ajena de la relación libro que referencia a una editorial.

Editorial(cod_editorial, direccion, provincia, ...)

Libro(cod_libro, titulo, ..., cod_editorial)

Ejemplo: claves ajenas de la relación Escribe que referencia a un Autor y a un Libro

respectivamente.
Autor(DNI, nombre, apellidos, ...)
Libro(cod_libro, titulo, ..., cod_editorial)

Escribe(autor, cod_libro, titulo, ..., cod_editorial)

PABLO ARELLANO www.theglobeformacion.com Página 30

B3T4 MODELADO DATOS Y DISEÑO BD GSI

3. Lenguajes relaciones
Son varios los lenguajes utilizados por los SGBD relacionales para manejar las relaciones.
Algunos de ellos son procedurales, lo que quiere decir que el usuario dice al sistema
exactamente cómo debe manipular los datos. Otros son no procedurales, que significa que el
usuario dice qué datos necesita, en lugar de decir cómo deben obtenerse.

La base de los lenguajes relacionales la constituyen el álgebra relacional y el cálculo

relacional. Ambos lenguajes son equivalentes: para cada expresión del álgebra, se puede
encontrar una expresión equivalente en el cálculo, y viceversa.

El álgebra relacional (o el cálculo relacional) se utiliza para medir la potencia de los lenguajes
relacionales.

Si un lenguaje permite obtener cualquier relación que se pueda derivar mediante el álgebra
relacional, se dice que es relacionalmente completo. La mayoría de los lenguajes relacionales
son relacionalmente completos, pero tienen más potencia que el álgebra o el cálculo porque
se les han añadido operadores especiales. En este apartado se verán las características más
importantes correspondientes al álgebra relacional.

Álgebra relacional
Lenguaje formal con una serie de operadores que trabajan sobre una o varias relaciones para
obtener otra relación resultado, sin que cambien las relaciones originales.

Tanto los operandos como los resultados son relaciones, por lo que la salida de una operación
puede ser la entrada de otra operación. Esto permite anidar expresiones del álgebra, del
mismo modo que se pueden anidar las expresiones aritméticas.

De los ocho operadores, solo hay 5 fundamentales, que forman un conjunto relacionalmente
completo, es decir, permite obtener cualquier subconjunto de los datos contenidos en una
BD:
− Selección: opera sobre una sola relación R y da como resultado otra relación cuyas tuplas
son las tuplas de R que satisfacen la condición especificada (C). Esta condición es una
comparación en la que aparece al menos un atributo de R, o una combinación booleana
de varias de estas comparaciones.

σc(R)

PABLO ARELLANO www.theglobeformacion.com Página 31

B3T4 MODELADO DATOS Y DISEÑO BD GSI

− Proyección: opera sobre una sola relación R y da como resultado otra relación que
contiene un subconjunto vertical de R, extrayendo los valores de los atributos
especificados y eliminando duplicados.

π 1..n (R)

− Producto cartesiano: relación resultante de combinar cada fila de la relación R con todas
las de la relación S. Ya que es posible que haya atributos con el mismo nombre en las dos
relaciones, el nombre de la relación se antepondrá al del atributo, en este caso, para que
los nombres de los atributos sigan siendo únicos en la relación resultado. En la relación
resultante:
o El grado es la suma del número de columnas de R y S.
o La cardinalidad es el producto del número de filas de R por el número de filas de S.

RxS

− Unión: Dadas dos relaciones R y S, se define la unión entre ambas como la relación
resultante de tomar las filas que están en una u otra relación y además las que están en
ambas (sólo una vez).

Para que se pueda producir la unión es necesario que las relaciones R y S presenten igual
grado y compatibilidad de dominios para cada par de atributos tomados de uno en uno
entre ambas relaciones, es decir, r1 ha de ser de un dominio igual o compatible a s1 y, en
general, rN ha de ser de un dominio igual o compatible a sN.

PABLO ARELLANO www.theglobeformacion.com Página 32

B3T4 MODELADO DATOS Y DISEÑO BD GSI

RUS

− Diferencia: dadas dos relaciones R y S, se define la diferencia entre ambas como la relación
resultante de tomar las filas que están en R y no están en S. Se trata de una operación no
conmutativa, a diferencia de las anteriores.

R-S

Operadores no fundamentales:
− Join: dadas dos relaciones R y S, se define la concatenación o join como la relación
resultante del producto cartesiano entre ambas tablas una vez seleccionadas aquellas filas
que tomen igual valor en aquella/s filas expresadas en la operación. Para que la operación
se pueda producir es necesario que ambas relaciones presenten, al menos, un campo en
común sobre el que establecer la condición de igualdad

R|x|S

PABLO ARELLANO www.theglobeformacion.com Página 33

B3T4 MODELADO DATOS Y DISEÑO BD GSI

− Intersección: dadas dos relaciones R y S, se define la intersección como la relación

resultante de tomar las filas que están tanto en R como en S. Al igual que en la unión, las
relaciones R y S han de presentar igual grado y compatibilidad de dominios para cada par
de atributos tomados de uno en uno entre ambas relaciones.

R∩S

− División: dadas dos relaciones R y S en las que existe un subconjunto de atributos (X) que
están formando parte de S y R al mismo tiempo y otro conjunto de atributos (Y) que
únicamente forman parte de R, se define la división o cociente como la relación resultante
de combinar cada fila de Y con todas las filas que forman parte de los atributos X. En
definitiva, para que t aparezca en el resultado, los valores de t deben aparecer en R en
combinación con cada tupla de S.

PABLO ARELLANO www.theglobeformacion.com Página 34

B3T4 MODELADO DATOS Y DISEÑO BD GSI

R÷S

4. Las 12 reglas de Codd

Las bases de datos relacionales se han ido imponiendo a partir de los años 80 debido a la
superioridad que ofrece el modelo de datos en que se basan, el modelo relacional, frente a
sus antecesores: el modelo jerárquico o de estructuras en árbol y el modelo Codasyl o de
estructuras en red.

En el año 1985, Codd estableció una regla general global, llamada “Regla Cero” y doce
principios, de los cuales al menos seis deben satisfacerse para que una base de datos pueda
considerarse relacional. Estos son los siguientes:
- Regla 0. Gestión de una Base de Datos Relacional. Un sistema de gestión de bases de
datos relacionales (SGBDR) debe ser capaz de manejar las bases de datos exclusivamente
con sus capacidades relacionales.
- Regla 1. Representación de la información. Toda la información en una base de datos
relacional se representa explícitamente a nivel lógico y de una manera única, por medio
de valores en tablas.
- Regla 2. Acceso garantizado. Todos y cada uno de los datos elementales en una base de
datos relacional deben ser accesibles lógicamente mediante una combinación de: nombre
de tabla, valor de clave primaria y nombre de columna.
- Regla 3. Representación sistemática de la información que falta. Los valores nulos deben
ser soportados por un SGBD completamente relacional para representar, de modo
sistemático, la información desconocida o inaplicable.
- Regla 4. Catálogo dinámico. La descripción de la base de datos se representa a nivel lógico
en la misma forma que los datos, de forma que los usuarios autorizados puedan aplicar el
mismo lenguaje relacional para consultarlo.
- Regla 5. Sublenguaje global de datos. Debe existir, al menos, un lenguaje cuyas sentencias
sean expresables mediante una sintaxis bien definida, como cadena de caracteres, y capaz
de soportar definición de datos, definición de vistas, manipulación de datos, restricciones
de integridad, autorizaciones y manejo de transacciones.
- Regla 6. Actualización de vistas. Todas las vistas teóricamente actualizables deberán ser
también actualizables por el sistema.
- Regla 7. Inserciones, actualizaciones y eliminaciones de alto nivel. La capacidad para
manejar como un solo operando una relación base o una relación derivada se aplica, no

PABLO ARELLANO www.theglobeformacion.com Página 35

B3T4 MODELADO DATOS Y DISEÑO BD GSI

sólo a las recuperaciones de datos, sino también a sus inserciones, actualizaciones y

eliminaciones.
- Regla 8. Independencia física de los datos. Los programas de aplicaciones y las actividades
terminales permanecerán lógicamente inalterados siempre que se realicen cambios en las
representaciones de almacenamiento o en los métodos de acceso.
- Regla 9. Independencia lógica de los datos. Cuando se efectúe en las tablas cualquier tipo
de cambio que preserve la información, los programas de aplicación permanecerán
intactos.
- Regla 10. Independencia de la integridad. Las reglas de integridad de una base de datos
particular deben ser definibles por medio del sublenguaje de datos relacional y
almacenables en el catálogo, no en los programas de aplicaciones.
- Regla 11. Independencia de la distribución. Un sistema relacional debe tener un
sublenguaje de datos que pueda soportar bases de datos distribuidas sin alterar los
programas de aplicaciones o actividades finales.
- Regla 12. Regla de la no inversión (o no subversión). Si un sistema relacional tiene un
lenguaje de bajo nivel, éste no puede ser utilizado para pasar por alto las reglas de
integridad y las restricciones expresadas por medio del lenguaje relacional de más alto
nivel.

En definitiva, de las reglas de Codd podernos concluir que un sistema de base de datos
relacional se caracteriza:
- Por presentar externamente sus datos como tablas, aunque internamente se sigan
manejando de forma convencional mediante índices, páginas, etc.
- Por la disponibilidad de un lenguaje para operar con las tablas, que al menos tenga las
funciones de recuperación, modificación, selección de subconjuntos de tablas sin
predefinición de caminos de acceso, definición de datos, etc., y que proporcione medios
para controla la integridad, seguridad y consistencia de los datos.
- Por disponer de interfaces que permitan el acceso concurrente desde terminales
interactivos y programas de aplicación, así como herramientas estándar para controlar la
operación y facilitar los procesos de respaldo y recuperación.

PABLO ARELLANO www.theglobeformacion.com Página 36

B3T4 MODELADO DATOS Y DISEÑO BD GSI

8. DISEÑO LÓGICO
A partir del esquema conceptual se elabora el modelo lógico. Este modelo debe coincidir con
el modelo datos soportado por el SGBD que se vaya a utilizar. Es nuestro caso el modelo de
datos es el modelo relacional.

Las técnicas de modelado conceptual son diferentes de las técnicas de modelado lógico, por
lo que habrá que convertir cada elemento presente en el modelo conceptual en elementos
expresables en la técnica de modelado lógico que hayamos seleccionado. Para ello se realizan
una serie de transformaciones y el proceso de normalización.

1. Ajustes del modelo conceptual

ELIMINACIÓN DE ATRIBUTOS COMPUESTOS
Estos atributos se caracterizan porque se pueden descomponer en descomponer en una
enumeración de atributos simples que expresan de forma más precisa la información a
representar.

Ejemplo: el atributo “Código_Cuenta_Bancaria” de la entidad “Cuentas Banco” se podría

descomponer:
- Código_Banco.
- Código_Sucursal.
- Número_de_cuenta.

El resultado es una información más precisa y al mismo tiempo más breve al haberse
eliminado el Código de Control al ser posible calcularlo a partir de los demás campos.

Esta descomposición de los atributos compuestos en otros simples se realiza,

fundamentalmente, para facilitar el acceso a la información y su posterior tratamiento.

Como resultado de esta eliminación se obtiene un Diagrama Entidad-Relación en el cual todas

las entidades tienen atributos simples.

ELIMINACIÓN DE ATRIBUTOS MULTIVALORADOS O MULTIVALUADOS

Los atributos multivalorados son aquellos que pueden tomar más de un valor para una misma
ocurrencia de una entidad.

PABLO ARELLANO www.theglobeformacion.com Página 37

B3T4 MODELADO DATOS Y DISEÑO BD GSI

Se observa que el atributo Movimientos puede tomar más de un valor, ya que una Cuenta
bancaria normalmente tiene más de un movimiento. Este tipo de atributos no son válidos en
el modelo relacional, por lo que es necesario eliminarlos.

La solución al problema consiste en crear una nueva entidad que represente al atributo
multivalorado y una relación entre esta entidad y la original. En nuestro ejemplo, esto se haría
de la siguiente manera:

Por lo tanto, un movimiento pertenece a una cuenta y una cuenta puede tener múltiples
movimientos.

Como resultado de esta eliminación se obtiene un Diagrama Entidad-Relación en el cual todas

las entidades tienen atributos univalorados.

ELIMINACIÓN DE RELACIONES REDUNDANTES

Una relación es redundante cuando se puede obtener la misma información que aporta
mediante otras relaciones. El hecho de que haya dos caminos diferentes entre dos entidades
no implica que uno de los caminos corresponda a una relación redundante, eso dependerá de
la carga semántica que aporte cada una de las relaciones representadas.

PABLO ARELLANO www.theglobeformacion.com Página 38

B3T4 MODELADO DATOS Y DISEÑO BD GSI

Se observa que la relación “Alberga” es innecesaria puesto que, en principio, podríamos

conocer todas las especies de animales existentes en un zoo a través de la relación entre la
entidad “Animal” y “Especies” al existir también una relación entre “Zoo” y “Animal”.

Sin embargo, en el siguiente ejemplo no sería normal que se eliminara alguna de las
relaciones, aun cuando estén vinculando a las mismas entidades, ya que la carga semántica
de cada una de ellas es diferente:

2. Obtención del modelo lógico a partir del conceptual

TRANSFORMACIÓN DE DOMINIOS
Un dominio del modelo conceptual se transforma en un dominio equivalente del modelo
lógico.

Para ello, se emplea la sentencia CREATE DOMAIN. En otro caso, será necesario utilizar los
tipos primitivos más afines con el dominio representable y delimitar sus elementos mediante
restricciones de usuario asociadas a la tabla a la que pertenezca el atributo con tal dominio.

TRANSFORMACIÓN DE ENTIDADES
Cada entidad del modelo conceptual se transforma en una relación o tabla con estructura
relacional. La clave primaria de la entidad pasa a ser la clave primaria de la relación. Los
atributos que forman parte de la clave no podrán tomar el valor nulo.

Ejemplo: Dado el siguiente diagrama conceptual:

PABLO ARELLANO www.theglobeformacion.com Página 39

B3T4 MODELADO DATOS Y DISEÑO BD GSI

Daría como resultado esta relación:

CLIENTE(NIF (PK), Nombre, Dirección, Teléfono)

La representación gráfica de una tabla es un rectángulo con una línea horizontal

que lo divide en dos. La parte superior, de ancho menor, se etiqueta con el
nombre de la tabla.

TRANSFORMACIÓN DE ATRIBUTOS
Cada atributo se transforma en una columna de la tabla en la que se transformó la entidad a
la que pertenece. El identificador único se convierte en clave primaria.
− Claves Primarias o Identificadores: las claves primarias o identificadores de la entidad
pasan a ser claves primarias en la relación resultantes (PRIMARY KEY).
− Claves candidatas (o alternativas): se transforman como atributos convencionales, pero
en su implementación deberá añadirse la restricción UNIQUE.
− Atributos convencionales: se transforman en campos de la relación con el dominio que
tuvieran asignado.
− Atributos compuestos y multivalorados: se transforman tal y como se indicaba más
arriba.

TRANSFORMACIÓN DE RELACIONES
Relaciones 1:1
Como norma general, es un caso particular de las 1:N y por tanto se propaga la clave en las
dos direcciones. Se debe analizar la situación, intentando recoger la mayor semántica posible,
y evitar valores nulos.

1) Será necesario crear una nueva tabla si:

a. Las cardinalidades mínimas son cero (ambas), esto evitará valores nulos en las claves
ajenas y mantendrá la simetría natural (las entidades mantienen su independencia en
tablas separadas)
b. La relación tiene atributos propios.
c. Se prevé que posteriormente puedan variarse las cardinalidades.

Ejemplo:

Se crearán tres tablas:

EMPLEADO(DNI (PK), Nombre, Apellido)

PABLO ARELLANO www.theglobeformacion.com Página 40

B3T4 MODELADO DATOS Y DISEÑO BD GSI

ORDENADOR(NumSerie (PK), Memoria)

UTILIZA(NumSerie+DNI (PK), horario)

2) Si una de las cardinalidades mínimas es cero y la otra no, será (1,1), conviene propagar la
clave de esta última (la obligatoria) a la primera.

3) Si las dos entidades participan de forma completa, es decir, todas cardinalidades mínimas
son 1:
a. Si las entidades tienen el mismo identificador se transforman en una única tabla
formada por la concatenación de los atributos de los dos tipos de entidad.
b. En el caso de que tengan diferente identificador, cada entidad se transforma en una
tabla y se puede propagar la clave de cualquiera de ellas a la tabla resultante de la otra,
teniendo en cuenta, en este caso, los accesos más frecuentes y prioritarios a los datos
de las tablas.

Relaciones 1:N
Según el caso que nos ocupe:
1) Relaciones entre entidades fuertes. Se utiliza el método de propagación de clave. En este
caso, el identificador de la entidad con cardinalidad uno cede su clave a la de cardinalidad
muchos. En esta última, pasa a ser una clave ajena.

2) Relaciones de dependencia (entidad fuerte-entidad débil):

a. Dependencia por existencia. Igualmente, se utiliza el método de propagación de clave
(punto 1).
b. Dependencia por identificador. Se utiliza el método de propagación de clave, y además
la clave primaria de la tabla con cardinalidad muchos estará formada por la
concatenación de su propia clave más la que le cede la de cardinalidad uno.

Relaciones N:M y ternarias

Se crea una tabla como consecuencia de la relación que tendrá como clave primaria la
concatenación de los identificadores de las entidades relacionadas. La condición de clave
ajena se expresa mediante FOREIGN KEY.

Relaciones de agregación
Las relaciones de agregación se transforman del mismo modo que las 1:N.

Relaciones Reflexivas
Cuando se trata de relaciones reflexivas con correspondencia 1:N se transforma utilizando el
método de propagación de clave, aunque, en este caso, al tratarse de la misma tabla, es
necesario renombrar el nombre del identificador que se transfiere, ya que si no estaría
repetido respecto del ya existente en la entidad de origen.

PABLO ARELLANO www.theglobeformacion.com Página 41

B3T4 MODELADO DATOS Y DISEÑO BD GSI

Transformación de relaciones exclusivas

Después de haber realizado la transformación según las relaciones 1:N, se debe tener en
cuenta que si los identificadores propagados se han convertido en claves ajenas de la tabla
originada por la entidad común a las relaciones, hay que comprobar que una y sólo una de
esas claves es nula en cada ocurrencia. En otro caso, estas comprobaciones se deben hacer en
las tablas resultantes de transformar las relaciones.

La relación entre tablas se representa gráficamente mediante una línea que las une. En ella
pueden aparecer en sus extremos diversos símbolos para indicar la cardinalidad de la relación,
como se muestra a continuación:

TRANSFORMACIÓN DE JERARQUÍAS
En el modelo lógico relacional no se dispone de instrumentos que permitan representar
supertipos y subtipos. Se definen distintos métodos de transformación, dependiendo de los
objetivos perseguidos:
− Información semántica representada en el modelo.
− Eficiencia de acceso a los datos.

Opción 1. Consiste en crear una tabla para el supertipo que tenga de clave primaria el
identificador y una tabla para cada uno de los subtipos que tengan el identificador del
supertipo como clave ajena.

Esta solución es apropiada cuando los subtipos tienen muchos atributos distintos y se quieren
conservar los atributos comunes en una tabla. También se deben definir las restricciones y
aserciones adecuadas. Es la solución que mejor conserva la semántica.

PABLO ARELLANO www.theglobeformacion.com Página 42

B3T4 MODELADO DATOS Y DISEÑO BD GSI

Opción 2. Se crea una tabla para cada subtipo, los atributos comunes aparecen en todos los
subtipos y la clave primaria para cada tabla es el identificador del supertipo.

Esta opción mejora la eficiencia en los accesos a todos los atributos de un subtipo, sean los
comunes al supertipo o los específicos.

Opción 3. Agrupar en una tabla todos los atributos de la entidad supertipo y de los subtipos.
La clave primaria de esta tabla es el identificador de la entidad. Se añade un atributo que
indique a qué subtipo pertenece cada ocurrencia (el atributo discriminante de la jerarquía).

PABLO ARELLANO www.theglobeformacion.com Página 43

B3T4 MODELADO DATOS Y DISEÑO BD GSI

Esta solución puede aplicarse cuando los subtipos se diferencien en pocos atributos y las
relaciones entre los subtipos y otras entidades sean las mismas. Para el caso de que la
jerarquía sea total, el atributo discriminante no podrá tomar valor nulo (ya que toda
ocurrencia pertenece a alguna de las entidades subtipo).

Nota: La notación utilizada es la más habitual, pero MÉTRICA v3 no exige su utilización.

Ejercicio: Transformar el modelo conceptual que se expone a continuación al modelo lógico

relacional.

PABLO ARELLANO www.theglobeformacion.com Página 44

B3T4 MODELADO DATOS Y DISEÑO BD GSI

PABLO ARELLANO www.theglobeformacion.com Página 45

B3T4 MODELADO DATOS Y DISEÑO BD GSI

3. Reglas de transformación (enfoque OO)

El objetivo de esta técnica es obtener un modelo físico de datos a partir del modelo de clases.
Para ello es necesario aplicar un conjunto de reglas de transformación que conserven la
semántica del modelo de clases.

Cada uno de los elementos del modelo de clases se tiene que transformar en un elemento del
modelo físico. En algunos casos la transformación es directa porque el concepto se soporta
igual en ambos modelos, pero otras veces no existe esta correspondencia, por lo que es
necesario buscar una transformación que conserve lo mejor posible la semántica, teniendo en
cuenta los aspectos de eficiencia que sean necesarios en cada caso.

TRANSFORMACIÓN DE CLASES
Una clase se transforma en una tabla. Lo habitual es que en los modelos con herencia pueden
surgir excepciones cuando se apliquen las reglas de transformación propias de la herencia.
Además, es posible que dos clases se transformen en una sola tabla cuando el
comportamiento de una de ellas sea irrelevante en la base de datos.

TRANSFORMACIÓN DE ATRIBUTOS DE CLASES

Cada atributo se transforma en una columna de la tabla en la que se transformó la clase a la
que pertenece. El identificador único se convierte en clave primaria. Además, se deben tener
en cuenta las reglas de transformación que se aplican a la herencia de clases.

PABLO ARELLANO www.theglobeformacion.com Página 46

B3T4 MODELADO DATOS Y DISEÑO BD GSI

Si existen restricciones asociadas a los atributos, éstas pueden recogerse con algunas cláusulas
del lenguaje lógico, que se convertirán en disparadores cuando éstos sean soportados por el
sistema gestor de base de datos.

TRANSFORMACIÓN DE RELACIONES
Relaciones 1:1
Es un caso particular de las 1:N y se puede tanto crear una tabla o propagar la clave, si bien,
en este último caso, la clave se propaga en las dos direcciones.

Para decidir qué solución adoptar, se debe analizar la situación, intentando recoger la mayor
semántica posible, y evitar valores nulos.

Relaciones M:N
Se transforman en una tabla, cuya clave primaria es la concatenación de los identificadores de
las clases asociadas, siendo cada uno de ellos clave ajena de la propia tabla. Si la relación tiene
atributos, éstos se transforman en columnas de la tabla.

Relaciones 1:N
Existen varias posibilidades:
1) Propagar el identificador de la clase de cardinalidad máxima 1 a la que es N, teniendo en
cuenta que:
- Relación de asociación: la clave propagada es clave ajena en la tabla a la que se ha
propagado.
- Relación de dependencia: la clave primaria de la tabla correspondiente a la clase débil
está formada por la concatenación de los identificadores de ambas clases.

2) La relación se transforma en una tabla de clave primaria sólo el identificador de la clase de

cardinalidad máxima N si:
- La relación tiene atributos propios y se desea que aparezcan como tales.
- Se piensa que en un futuro la relación puede convertirse en M:N.
- El número de ocurrencias relacionadas de la clase que propaga su clave es muy
pequeño (y por tanto pueden existir muchos valores nulos).

Al igual que en el caso de relaciones M:N, las claves propagadas son claves ajenas de la nueva
tabla creada.

Relaciones de agregación
Las relaciones de agregación se transforman del mismo modo que las 1:N.

Transformación de relaciones exclusivas

Después de haber realizado la transformación según las relaciones 1:N, se debe tener en
cuenta que si se han propagado los atributos de las clases, convirtiéndose en claves ajenas de
la tabla que provenía de la clase común a las relaciones, hay que comprobar que una y sólo

PABLO ARELLANO www.theglobeformacion.com Página 47

B3T4 MODELADO DATOS Y DISEÑO BD GSI

una de esas claves es nula en cada ocurrencia. En caso de no propagarse las claves, estas
comprobaciones se deben hacer en las tablas resultantes de transformar las relaciones.

TRANSFORMACIÓN DE LA HERENCIA
Existen varias posibilidades que deben ser evaluadas por el diseñador a fin de elegir la que
mejor se ajuste a los requisitos. Las opciones para tratar la transformación de la herencia son:
Opción 1. Consiste en crear una tabla para la superclase que tenga de clave primaria el
identificador y una tabla para cada una de las subclases que tengan el identificador de la
superclase como clave ajena.

Esta solución es apropiada cuando las subclases tienen muchos atributos distintos, y se
quieren conservar los atributos comunes en una tabla. También se deben implantar las
restricciones y/o aserciones adecuadas. Es la solución que mejor conserva la semántica.

Opción 2. Se crea una tabla para cada subclase, los atributos comunes aparecen en todas las
subclases y la clave primaria para cada tabla es el identificador de la superclase.

Esta opción mejora la eficiencia en los accesos a todos los atributos de una subclase (los
heredados y los específicos).

Opción 3. Agrupar en una tabla todos los atributos de la clase y sus subclases. La clave primaria
de esta tabla es el identificador de la clase. Se añade un atributo que indique a qué subclase
pertenece cada ocurrencia (el atributo discriminante de la jerarquía).

Esta solución puede aplicarse cuando las subclases se diferencien en pocos atributos y las
relaciones que asocian a las subclases con otras clases, sean las mismas. Para el caso de que
la jerarquía sea total, el atributo discriminante no podrá tomar valor nulo (ya que toda
ocurrencia pertenece a alguna subclase).

PABLO ARELLANO www.theglobeformacion.com Página 48

B3T4 MODELADO DATOS Y DISEÑO BD GSI

9. NORMALIZACIÓN
La teoría de la normalización, como técnica formal para organizar los datos, ayuda a encontrar
fallos y a corregirlos, evitando así introducir anomalías en las operaciones de manipulación
de datos (Técnica de Métrica v3).

Se dice que:
“Una relación está en una determinada forma normal si satisface un cierto conjunto de
restricciones sobre los atributos.”

Cuantas más restricciones existan, menor será el número de relaciones que las satisfagan, así,
por ejemplo, una relación en tercera forma normal estará también en segunda y en primera
forma normal. Y, en consecuencia, cuanto más alta sea la forman normal aplicable a una
relación menos vulnerable será a inconsistencias y anomalías.

La teoría de la normalización tiene por objetivo:

− La eliminación de dependencias entre atributos que originen anomalías en la
actualización de los datos.
− Proporcionar una estructura más regular para la representación de las tablas,
constituyendo el soporte para el diseño de bases de datos relacionales.

Como resultado de la aplicación de esta técnica se obtiene un modelo lógico de datos

normalizado.

Antes de definir las distintas formas normales se explican, muy brevemente, algunos
conceptos necesarios para su comprensión.

Dependencia funcional
Un atributo Y se dice que depende funcionalmente de otro X si, y sólo si, a cada valor de X le
corresponde un único valor de Y, lo que se expresa de la siguiente forma: X → Y (también se
dice que X determina o implica a Y). X se denomina implicante o determinante e Y es el
implicado.

Dependencia funcional completa

Un atributo Y tiene dependencia funcional completa respecto de otro X, si depende
funcionalmente de él en su totalidad, es decir, no depende de ninguno de los posibles
atributos que formen parte de X.

Dependencia transitiva
Un atributo depende transitivamente de otro si, y sólo si, depende de él a través de otro
atributo. Así, Z depende transitivamente de X, si:
X→Y
Y --/→ X
Y→Z

PABLO ARELLANO www.theglobeformacion.com Página 49

B3T4 MODELADO DATOS Y DISEÑO BD GSI

Se dice que X implica a Z a través de Y.

Se pueden utilizar un conjunto de reglas, denominadas axiomas de Armstrong, que ayudan a

descubrir las dependencias funcionales:
- Regla de la reflexividad: si X es un conjunto de atributos e Y ⊆ X, entonces se cumple que
X → Y.
- Regla de la aumentatividad: si se cumple que X → Y y Z es un conjunto de atributos,
entonces se cumple que ZX → ZY.
- Regla de la transitividad: si se cumple que X → Y y también se cumple que Y → Z, entonces
se cumple que X → Z.

Una vez definidas las anteriores dependencias, se pueden enunciar las formas normales:
− Primera, Segunda y Tercera Formas Normales: Codd en 1970.
− Forma Normal de Boyce y Codd (FNBC): Boyce-Codd en 1974.
− Cuarta Forma Normal (4FN): Fagin en 1977.
− Quinta Forma Normal (5FN): Fagin en 1979.

1FN
2FN
3FN
FNBC
4FN
5FN

Nota: Métrica v3 define hasta la 3FN.

1. Primera Forma normal (1FN)

Una relación está en 1FN si no tiene grupos repetitivos, es decir, un atributo sólo puede tomar
un único valor de un dominio simple.

PABLO ARELLANO www.theglobeformacion.com Página 50

B3T4 MODELADO DATOS Y DISEÑO BD GSI

Una vez identificados los atributos que no dependen funcionalmente de la clave principal, se
formará con ellos una nueva relación y se eliminarán de la antigua. La clave principal de la
nueva relación estará formada por la concatenación de uno o varios de sus atributos más la
clave principal de la antigua relación.

Ejemplo:

Se soluciona repitiendo toda la tupla para cada uno de los valores del grupo repetitivo.

2. Segunda Forma normal (2FN)

Una relación está en 2FN si está en 1FN y todos los atributos que no forman parte de las
claves candidatas (atributos no principales) tienen dependencia funcional completa
respecto de éstas, es decir, no hay dependencias funcionales de atributos no principales
respecto de una parte de las claves. Cada uno de los atributos de una relación depende de
toda la clave.

Una vez identificados los atributos que no dependen funcionalmente de toda la clave, sino
sólo de parte de la misma, se formará con ellos una nueva relación y se eliminarán de la
antigua. La clave principal de la nueva relación estará formada por la parte de la antigua de la
que dependen funcionalmente.

Ejemplo:

PABLO ARELLANO www.theglobeformacion.com Página 51

B3T4 MODELADO DATOS Y DISEÑO BD GSI

Solución:
R1(ALMACÉN, PIEZA, CANTIDAD)
R2(ALMACÉN, DIR_ALMACÉN)

3. Tercera Forma normal (3FN)

Una relación está en 3FN si está en 2FN y todos sus atributos no principales dependen
directamente de alguna de las claves, es decir, no hay dependencias funcionales transitivas
de atributos no principales respecto de las claves.

Una vez identificados los atributos que dependen de otro atributo distinto de la clave, se
formará con ellos una nueva relación y se eliminarán de la antigua. La clave principal de la
nueva relación será el atributo del cual dependen. Este atributo en la relación antigua pasará
a ser una clave ajena.

Ejemplo:

Solución:
R1(MATRICULA, MODELO)
R2(MODELO, POTENCIA)

4. Forma normal de Boyce-Codd (FNBC)

Una relación está en Forma Normal de Boyce-Codd si y sólo si está en 3FN y además todo
determinante es una clave candidata.

Está a medio camino entre la 3FN -ligeramente más fuerte- pero todavía no es 4FN.

Ejemplo:
R(dni, nombre, codalumno, codasig, nota)

PABLO ARELLANO www.theglobeformacion.com Página 52

B3T4 MODELADO DATOS Y DISEÑO BD GSI

Claves candidatas: (dni, codasig) y (codalumno,codasig) y se cumple que dni à nombre

dni es un determinante que no es clave candidata y, por tanto, R no está en FNBC.

Solución:
R1(dni, codalumno, nombre)
R2(dni, codasig, nota)

Ejemplo:
R(alumno, asignatura, profesor, nota)

Dependencias:
{alumno, asignatura} à profesor
{alumno, asignatura} à nota
{profesor} à asignatura

Claves candidatas:
{alumno, asignatura}
{alumno, profesor}

{profesor} à asignatura y, por tanto, R no está en FNBC ya que Profesor no es clave candidata.

Solución:
R1(alumno, asignatura, nota)
R2(profesor, asignatura)

5. Cuarta Forma normal (4FN)

Una relación está en cuarta forma normal si y sólo si está en FNBC y además en todas las
dependencias múltiplemente valoradas el implicante es clave candidata.

Ejemplo: Un valor de X puede tener varios valores de Y.

Empleado(Nombre, Proyecto, Hijo)

Nombre →→ Proyecto|Hijo y, por tanto, R no está en 4FN.

PABLO ARELLANO www.theglobeformacion.com Página 53

B3T4 MODELADO DATOS Y DISEÑO BD GSI

Solución:

6. Quinta Forma normal (5FN)

Una relación está en quinta forma normal si y sólo si está en 4FN y además toda dependencia
de combinación está implicada por una clave candidata.

Una dependencia de combinación aparece en relaciones que no pueden descomponerse en

otras dos sin perder información. Para evitar esta pérdida de información hay que
descomponerla, al menos, en otras tres relaciones.

Si en cada dependencia de reunión denotada por (X1, X2, ..., Xn), cada Xi es una clave
candidata.

Cuando una relación se descompone en más de dos relaciones (porque no se pueda encontrar
una descomposición sin pérdidas en dos proyecciones), se ha de cumplir este requisito para
para que la descomposición sea sin pérdidas.

Ejemplo:
Solidarios(ONG, Proyecto, Lugar)

Solución: dividir R en R1, R2, ..., Rn

R1(ONG, Proyecto)
R2(Proyecto, Lugar)
R3(ONG, Lugar)

Si aplicamos una Reunión Natural a dos de esas tres relaciones, se producen tuplas falsas, pero
si aplicamos una Reunión Natural a las tres NO se producen tuplas falsas.

PABLO ARELLANO www.theglobeformacion.com Página 54

 B3T4 MODELADO DATOS Y DISEÑO BD GSI

7. La normalización en Métrica v3
En ASI 6 “Elaboración del modelo de datos” se lleva a cabo la normalización del modelo lógico
de datos:

Tarea Productos Técnicas/Prácticas Participantes

Normalización del Modelo Modelo Lógico de Datos
ASI 6.3 Normalización Analistas
Lógico de Datos Normalizado

PABLO ARELLANO www.theglobeformacion.com Página 55

B3T4 MODELADO DATOS Y DISEÑO BD GSI

10. DISEÑO FÍSICO

El diseño físico de datos define el esquema interno de la base de datos. Según Métrica v3 se
define la estructura física de datos del Sistema de Información a partir del modelo lógico de
datos normalizado.

En función del SGBD, los requisitos y el entorno, se busca la eficiencia, tratando de mejorar
tiempos de respuesta y optimizar los recursos del sistema.

Por tanto, el objetivo es obtener un esquema interno de la BD que cumpla lo mejor posible
los objetivos de funcionamiento de la BD que los usuarios esperan: minimizar el tiempo de
respuesta de la BD y su espacio de almacenamiento e incrementar la seguridad.

El diseño físico se divide de cuatro fases, cada una de ellas compuesta por una serie de pasos:
− Traducir el esquema lógico para el SGBD específico.
− Diseñar la representación física.
− Diseñar los mecanismos de seguridad.
− Monitorizar y afinar el sistema.

ATENCIÓN: La obtención de modelo lógico de datos a partir del modelo conceptual a través
de transformaciones (vistas en el apartado anterior), Métrica v3 lo presenta como diseño
físico en lugar de diseño lógico, usando la técnica Reglas de Obtención del Modelo Físico a
partir del Lógico.

El objetivo de esta técnica es obtener un modelo físico de datos a partir del modelo lógico
de datos normalizado. Para ello es necesario aplicar un conjunto de reglas que conserven la
semántica del modelo lógico.

Cada uno de los elementos del modelo lógico se tiene que transformar en un elemento del
modelo físico. En algunos casos la transformación es directa porque el concepto se soporta
igual en ambos modelos, pero otras veces no existe esta correspondencia, por lo que es
necesario buscar una transformación que conserve lo mejor posible la semántica, teniendo en
cuenta los aspectos de eficiencia que sean necesarios en cada caso.

1. Traducir el esquema lógico para el SGBD específico

Para ello, es necesario conocer toda la funcionalidad que el SGBD ofrece. Por ejemplo, el
diseñador deberá saber:
- Si el sistema soporta la definición de claves primarias, claves ajenas y claves alternativas.
- Si el sistema soporta la definición de datos requeridos (es decir, si se pueden definir
atributos como no nulos).

PABLO ARELLANO www.theglobeformacion.com Página 56

B3T4 MODELADO DATOS Y DISEÑO BD GSI

- Si el sistema soporta la definición de dominios.

- Si el sistema soporta la definición de restricciones o aserciones de usuario.
- Cómo se crean las tablas.

La tarea fundamental de construcción del esquema físico es la implementación de las

relaciones o tablas obtenidas en el modelo lógico. Se definen mediante el lenguaje de
definición de datos (DDL) del SGBD. Para ello, se utiliza la información producida durante el
diseño lógico, es decir, el esquema lógico global.

El esquema lógico consta de un conjunto de relaciones o tablas y, para cada una de ellas, se
tiene:
- El nombre de la relación.
- La lista de atributos entre paréntesis.
- La clave primaria y las claves ajenas, si las tiene.
- Las reglas de integridad de las claves ajenas.

Y para cada uno de los atributos se define:

- Su dominio: tipo de datos, longitud y restricciones de dominio.
- El valor por defecto, que es opcional.
- Si admite nulos.
- Si es derivado y, en caso de serlo, cómo se calcula su valor.

Como consecuencia de todo ello se podrán crear los “scripts” de la base de datos escritos con
la sintaxis y funcionalidades del LDD del SGBDR. Las dos órdenes fundamentales a utilizar en
este caso son: CREATE TABLE y CREATE DOMAIN.

Esta sintaxis, además, permite incluir referencias al modo de almacenamiento como pueden
ser: ficheros físicos o lógicos (tablespaces) asignables a cada tabla, segmentos o bloque
asignados inicialmente y en expectativa de crecimiento, particionamientos de la estructura,
etc.

Además, será necesario completar la funcionalidad de las estructuras creadas mediante las
denominadas restricciones de usuario, que permitirán delimitar las actualizaciones que se
realizan sobre las relaciones de la base de datos mediante restricciones, aserciones o
disparadores. En cuanto a las primeras, se definen mediante la cláusula de CREATE TABLE,
CONSTRAINT CHECK (<condición>), las segundas mediante la orden CREATE ASSERTION y los
últimos con CREATE TRIGGER.

2. Diseñar la representación física

Uno de los objetivos principales del diseño físico es almacenar los datos de modo eficiente.
Para medir la eficiencia hay varios factores que se deben tener en cuenta:

PABLO ARELLANO www.theglobeformacion.com Página 57

B3T4 MODELADO DATOS Y DISEÑO BD GSI

- Productividad de transacciones. Es el número de transacciones que se quiere procesar por

unidad de tiempo.
- Tiempo de respuesta. Es el tiempo que tarda en ejecutarse una transacción. Desde el
punto de vista del usuario, este tiempo debería ser el mínimo posible.
- Espacio en disco. Es la cantidad de espacio en disco que hace falta para los ficheros de la
base de datos. Normalmente, el diseñador deberá minimizar este espacio.

Normalmente, todos estos factores no se pueden satisfacer a la vez. Por lo tanto, el diseñador
deberá ir ajustando estos factores para conseguir un equilibrio razonable. El diseño físico
inicial no será el definitivo, sino que habrá que ir monitorizándolo para observar sus
prestaciones e ir ajustándolo como sea oportuno.

ANALIZAR LAS TRANSACCIONES

Para realizar un buen diseño físico es necesario conocer las consultas y las transacciones que
se van a ejecutar sobre la base de datos. Esto incluye tanto información cualitativa, como
cuantitativa. Para cada transacción, hay que especificar:
- La frecuencia con que se va a ejecutar.
- Las relaciones y los atributos a los que accede la transacción, y el tipo de acceso: consulta,
inserción, modificación o eliminación. Los atributos que se modifican no son buenos
candidatos para construir estructuras de acceso.
- Los atributos que se utilizan en los predicados del WHERE de las sentencias SQL. Estos
atributos pueden ser candidatos para construir estructuras de acceso, dependiendo del
tipo de predicado que se utilice.
- Si es una consulta, los atributos involucrados en el join de dos o más relaciones. Estos
atributos pueden ser candidatos para construir estructuras de acceso.
- Las restricciones temporales impuestas sobre la transacción. Los atributos utilizados en los
predicados de la transacción pueden ser candidatos para construir estructuras de acceso.

Cálculo de accesos
El cálculo de accesos es una práctica de Métrica v3 que permite realizar una estimación del
número de accesos aproximado que debe realizarse para obtener la información de cada
consulta, tomando como referencia las vistas del modelo de datos obtenidas como
consecuencia del análisis de los caminos de acceso a los datos.

Esta práctica se utiliza en los procesos Análisis del Sistema de Información (ASI) y Diseño del
Sistema de Información (DSI) aplicando los mismos criterios, la única diferencia es que
mientras en el primero el acceso es lógico y permite determinar la viabilidad de las consultas,
en el segundo es físico y permite establecer las pautas para la optimización del modelo físico
de datos.

El cálculo de accesos consiste en realizar una estimación del número de ocurrencias o filas de
cada entidad o tabla/fichero del modelo de datos que deben ser leídas, teniendo en cuenta
los identificadores/claves candidatas o índices asociados a cada entidad o tabla/fichero a leer.

PABLO ARELLANO www.theglobeformacion.com Página 58

B3T4 MODELADO DATOS Y DISEÑO BD GSI

La estimación de si una consulta es excesivamente costosa se realiza comparando el número

de accesos necesarios para realizar el resto de las consultas.

Una vez realizada la estimación inicial del número de accesos, se ajustan los valores obtenidos,
dividiendo por la prioridad establecida para cada acceso (por ejemplo 1: alta, 2: media, 3: baja)
y multiplicando el resultado obtenido por la frecuencia del acceso, es decir el número de veces
que se ejecuta la consulta al día.

Si el resultado final se sale de un intervalo razonable en el que se encuentran el resto de las

consultas, se debe analizar si se modifica la consulta, o si por su prioridad y frecuencia es
necesaria la modificación del modelo de datos.

Caminos de acceso
El objetivo de esta práctica de Métrica v3 es analizar la secuencia de acceso a los datos que
realizan los módulos a través del modelo de datos. También puede utilizarse para entornos de
ficheros.

Permite verificar en el proceso Análisis del Sistema de Información (ASI) que el modelo lógico
de datos normalizado satisface las principales consultas de información recogidas en el
catálogo de requisitos, y en el proceso Diseño del Sistema de Información (DSI) que el modelo
físico de datos soporta adecuadamente los principales accesos de actualización, cuando
proceda, y de consulta.

Los caminos de acceso representan la secuencia y tipo de acceso a los datos persistentes del
sistema, que deben realizar los procesos primitivos a partir del modelo lógico de datos
normalizado, o los módulos/clases a partir del modelo físico de datos.

En función del modelo de datos sobre el que se realiza el acceso, se identifican las entidades
o tablas/ficheros que deben ser accedidas por cada proceso primitivo o módulo/clase, y se
crean vistas del modelo de datos en el que aparecen únicamente dichas entidades
(subconjunto del modelo de datos). Es conveniente examinar todas las entidades relacionadas
con las identificadas inicialmente, debido a que puede que aparezcan más entidades que no
se habían contemplado en un primer momento.

Para cada entidad identificada se indica el tipo de acceso realizado, es decir, si se trata de una
lectura, inserción, modificación o eliminación.

Una vez identificadas las entidades o tablas/ficheros y el tipo de acceso, el siguiente paso es
determinar el orden que se sigue para la obtención de los datos a través del modelo de datos,
con el fin de identificar accesos redundantes o excesivamente complejos que puedan
comprometer el rendimiento final del sistema.

Se recomienda aplicar esta práctica para aquellos módulos que presenten, entre otras, alguna
de las siguientes características:
- Tratamiento crítico.
- Accesos complejos a datos.

PABLO ARELLANO www.theglobeformacion.com Página 59

B3T4 MODELADO DATOS Y DISEÑO BD GSI

- Alta concurrencia.

ESCOGER LAS ORGANIZACIONES DE FICHEROS

En el caso de aquellos SGBDRs que permitan asociar cada estructura de datos con un fichero
físico es recomendable escoger la organización de ficheros óptima para cada relación.

Por ejemplo, un fichero desordenado es una buena estructura cuando se va a cargar gran
cantidad de datos en una relación al inicializarla, cuando la relación tiene pocas tuplas,
también cuando en cada acceso se deben obtener todas las tuplas de la relación, o cuando la
relación tiene una estructura de acceso adicional, como puede ser un índice.

Por otra parte, los ficheros dispersos (hashing) son apropiados cuando se accede a las tuplas
a través de los valores exactos de alguno de sus campos (condición de igualdad en el WHERE).

Si la condición de búsqueda es distinta de la igualdad (búsqueda por rango, por patrón, etc.),
la dispersión no es una buena opción. Hay otras organizaciones, como la ISAM o los árboles
B+.

ESCOGER LOS ÍNDICES SECUNDARIOS

Los índices secundarios permiten especificar caminos de acceso adicionales para las relaciones
base. Hay que tener en cuenta que estos índices conllevan un coste de mantenimiento que
hay que sopesar frente a la ganancia en prestaciones. A la hora de seleccionar los índices, se
pueden seguir las siguientes indicaciones:
- Construir un índice sobre la clave primaria de cada relación base, normalmente se crea de
forma implícita con la cláusula CONSTRAINT PRIMARY KEY.
- No crear índices sobre tablas pequeñas.
- Añadir un índice sobre los atributos que se utilizan para acceder con mucha frecuencia.
- Añadir un índice sobre las claves ajenas que se utilicen con frecuencia para hacer joins.
- Evitar los índices sobre atributos que se modifican a menudo.
- Evitar los índices sobre atributos poco selectivos (aquellos en los que la consulta selecciona
una porción significativa de la tabla).
- Evitar los índices sobre atributos formados por cadenas de caracteres largas.

CONSIDERAR LA INTRODUCCIÓN DE REDUNDANCIAS CONTROLADAS

En ocasiones, puede ser conveniente relajar las reglas de normalización introduciendo
redundancias de forma controlada, con objeto de mejorar las prestaciones del sistema. En la
etapa del diseño lógico se recomienda llegar, al menos, hasta la tercera forma normal para
obtener un esquema con una estructura consistente y sin redundancias. Pero, a menudo,
sucede que las bases de datos, así normalizadas, no proporcionan la máxima eficiencia, con lo
que es necesario volver atrás y desnormalizar algunas relaciones. Es importante hacer notar

PABLO ARELLANO www.theglobeformacion.com Página 60

B3T4 MODELADO DATOS Y DISEÑO BD GSI

que la desnormalización sólo debe realizarse cuando se estime que el sistema no puede
alcanzar las prestaciones deseadas. Por lo tanto, hay que tener en cuenta los siguientes
factores:
- La desnormalización hace que la implementación sea más compleja.
- La desnormalización hace que se sacrifique la flexibilidad.
- La desnormalización puede hacer que los accesos a datos sean más rápidos, pero ralentiza
las actualizaciones.

Optimización
La optimización consiste en una desnormalización controlada del modelo físico de datos que
se aplica para reducir o simplificar el número de accesos a la base de datos.

El objetivo de esta técnica es reestructurar el modelo físico de datos con el fin de asegurar
que satisface los requisitos de rendimiento establecidos y conseguir una adecuada eficiencia
del sistema, según se define en Métrica v3.

Para ello, se seguirán alguna de las recomendaciones que a continuación se indican:

- Introducir elementos redundantes.
- Dividir entidades.
- Combinar entidades si los accesos son frecuentes dentro de la misma transacción.
- Redefinir o añadir relaciones entre entidades para hacer más directo el acceso entre
entidades.
- Definir claves secundarias o índices para permitir caminos de acceso alternativos.

Con el fin de analizar la conveniencia o no de la desnormalización, se han de considerar, entre

otros, los siguientes aspectos:
- Los tiempos de respuesta requeridos.
- La tasa de actualizaciones respecto a la de recuperaciones.
- Las veces que se accede conjuntamente a los atributos.
- La longitud de los mismos.
- El tipo de aplicaciones (en línea / por lotes).
- La frecuencia y tipo de acceso.
- La prioridad de los accesos.
- El tamaño de las tablas.
- Los requisitos de seguridad: accesibilidad, confidencialidad, integridad y disponibilidad
que se consideren relevantes.

PABLO ARELLANO www.theglobeformacion.com Página 61

B3T4 MODELADO DATOS Y DISEÑO BD GSI

3. Diseñar los mecanismos de seguridad

Los datos constituyen un recurso esencial para la organización, por lo tanto su seguridad es
de vital importancia. Durante el diseño lógico se habrán especificado los requerimientos en
cuanto a seguridad que en esta fase se deben implementar. Para llevar a cabo esta
implementación, el diseñador debe conocer las posibilidades que ofrece el SGBD que se vaya
a utilizar.
- Diseñar las vistas de los usuarios: las vistas de los usuarios se corresponden a los
esquemas lógicos locales. Las vistas, además de preservar la seguridad, mejoran la
independencia de datos, reducen la complejidad y permiten que los usuarios vean los
datos en el formato deseado. Para crearlas se utiliza la orden CREATE VIEW.

- Diseñar las reglas de acceso: para cada usuario o grupo de usuarios se determinan tanto
los permisos sobre determinados objetos de la base de datos, como los permisos o
privilegios del sistema, es decir, las operaciones de DDL que están disponibles para ese
usuario o grupo. Normalmente, los privilegios se agrupan en conjuntos denominados
«Roles». Para otorgar un permiso o rol se utiliza la orden GRANT y para denegarlo REVOKE.
Se definen mediante el Lenguaje de Control de Datos (DCL).

4. Monitorizar y afinar el sistema

Una vez implementado el esquema físico de la base de datos, se debe poner en marcha para
observar su rendimiento (monitorizar). En el caso de que no se satisfagan las necesidades de
rendimiento deseadas, el esquema deberá ser modificado (afinar).

Este proceso no es estático y puntual, sino que la monitorización está presente a lo largo de
toda la vida del sistema, requiriéndose nuevas modificaciones (refinar) para adaptarse a los
nuevos requisitos.

PABLO ARELLANO www.theglobeformacion.com Página 62

 B3T4 MODELADO DATOS Y DISEÑO BD GSI

5. El diseño físico de datos según Métrica v3

En DSI 6 “Diseño físico de datos” se define la estructura física de datos que utilizará el sistema
a partir del modelo lógico de datos normalizado:

Tarea Productos Técnicas/Prácticas Participantes

Equipo de Arquitectura
Diseño del Modelo
DSI 6.1 Modelo Físico de Datos Normalización Equipo de Proyecto
Físico de Datos
DBAs

Especificación de Especificación de los

Cálculo de accesos físicos
DSI 6.2 los caminos de caminos de accesos a los Equipo de Proyecto
Caminos de acceso
acceso a los datos datos

Equipo de Arquitectura
Optimización del
Modelo físico de datos Equipo de Proyecto
DSI 6.3 Modelo Físico de Optimización
optimizado DBAs
Datos
Equipo de Seguridad

Esquemas físicos de
Especificación de la Equipo de Seguridad
datos
DSI 6.4 Distribución de Matricial Equipo de Soporte
Asignación de esquemas
Datos Técnico
físicos de datos a nodos

DSI 6.1 Diseño del Modelo Físico de Datos

El objetivo de esta tarea es realizar el diseño del modelo físico de datos a partir del modelo
lógico de datos normalizado o del modelo de clases, en el caso de diseño orientado a objetos.

Como paso previo al diseño de la estructura física de datos, se analizan las peculiaridades
técnicas del gestor de bases de datos o sistema de ficheros a utilizar, y las estimaciones sobre
la utilización y volumen de las ocurrencias de cada entidad/clase del modelo lógico de datos
normalizado o modelo de clases. Además, si se ha establecido la necesidad de llevar a cabo
una migración de datos, se deben tener en cuenta también los volúmenes de las estructuras
de datos implicadas en la conversión. Esta información sirve para decidir la mejor
implementación del modelo lógico de datos/modelo de clases, así como para hacer una
estimación del espacio de almacenamiento.

De acuerdo al análisis anterior, se determina cómo se van a convertir las entidades/clases en

tablas, considerando las relaciones existentes entre ellas y los identificadores, definiendo sus
claves primarias, ajenas, alternativas u otros medios de acceso en general.

También se definen aquellos elementos que, en función del gestor o sistemas de ficheros a
utilizar, se considere necesario implementar, como bloqueo, compresión de datos, clusters…

PABLO ARELLANO www.theglobeformacion.com Página 63

B3T4 MODELADO DATOS Y DISEÑO BD GSI

DSI 6.2 Especificación de los caminos de acceso a los datos

El objetivo de esta tarea es determinar los caminos de acceso a los datos persistentes del
sistema, utilizados por los principales módulos/clases de acuerdo al modelo físico de datos,
con el fin de optimizar el rendimiento de los gestores de datos o sistemas de ficheros y el
consumo de recursos, así como disminuir los tiempos de respuesta.

Para el inicio de esta tarea, se toma como referencia el Diseño Detallado de los Subsistemas
de Soporte (DSI 2.1) y el Diseño de la Arquitectura Modular (DSI 5) o Diseño de Clases (DSI 4)
de los subsistemas específicos, productos que se están generando en paralelo a esta actividad.

Para cada módulo/clase se identifican las tablas o ficheros y el tipo de acceso realizado, así
como el orden que debe seguirse para la obtención de los datos. Asimismo, se efectúa una
estimación del número de accesos que deben realizarse teniendo en cuenta, a su vez, la
frecuencia y la prioridad del acceso.

La información obtenida sirve para identificar accesos excesivamente costosos o redundantes

que pueden comprometer el rendimiento final del sistema y que, por lo tanto, exigen la
optimización del modelo físico de datos, mediante la creación de nuevos accesos, posibles
desnormalizaciones o particiones del modelo físico de datos.

DIS 6.3 Optimización del Modelo Físico de Datos

En esta tarea se optimiza el diseño físico de datos, con el objetivo de mejorar el tiempo de
respuesta en el acceso a datos persistentes, hacer una adecuada utilización de los recursos
del sistema y, en consecuencia, garantizar que el diseño satisface las necesidades de
tratamiento establecidas para el sistema de información en cuanto a que se ajusta a los
requisitos de rendimiento exigidos.

A partir de la especificación de la secuencia de accesos de aquellos módulos/clases

identificados como críticos, obtenida en la tarea anterior, se detectan las posibles mejoras con
el fin de conseguir los niveles de rendimiento establecidos y, por lo tanto, una mayor eficiencia
del sistema. Como resultado, puede ser necesaria una desnormalización controlada que se
aplica para reducir o simplificar el número de accesos a los sistemas de almacenamiento de
datos.

DSI 6.4 Especificación de la Distribución de Datos

En esta tarea se determina el modelo de distribución de datos, teniendo en cuenta los

requisitos de diseño establecidos. Se establece la ubicación de los gestores de bases de datos
o sistemas de ficheros, así como de los distintos elementos de la estructura física de datos, en
los nodos correspondientes, de acuerdo al particionamiento físico del sistema de información
especificado en la actividad Diseño de la Arquitectura del Sistema (DSI 1).

PABLO ARELLANO www.theglobeformacion.com Página 64

B3T4 MODELADO DATOS Y DISEÑO BD GSI

El resultado de esta actividad es la especificación de los modelos físicos particulares de cada

nodo, esquemas físicos de datos, así como su asignación a los nodos.

PABLO ARELLANO www.theglobeformacion.com Página 65

B3T4 MODELADO DATOS Y DISEÑO BD GSI

11. PROBLEMAS DE CONCURRENCIA DE ACCESO

Las operaciones de acceso de las aplicaciones a la base de datos ponen en peligro su
integridad. Estas operaciones se organizan en transacciones.

Una transacción es una secuencia de operaciones de acceso a la BD que constituye una unidad
lógica de ejecución.

Como ejemplo de transacción, imaginemos que ordenamos la transferencia por la compra de

un producto en Amazon. Este proceso está formado por un conjunto de operaciones:
1) Comprobar que nuestra cuenta es válida y está operativa.
2) Comprobar si hay saldo suficiente.
3) Comprobar los datos de la cuenta del vendedor.
4) Retirar el dinero de nuestra cuenta.
5) Ingresar el dinero en la cuenta del vendedor.

Podemos observar en el ejemplo que las operaciones de la transacción deben ejecutarse todas
o ninguna, que si falla la operación 4 o 5 la BD quedará en un estado inconsistente, que los
cambios en los datos no deben ser visibles hasta que la transacción sea confirmada y que una
vez finalice con éxito la ejecución de las operaciones se deben confirmar los cambios en la BD.

Del ejemplo visto, se desprenden las propiedades que deben cumplir las transacciones:
- ATOMICIDAD: una transacción es una unidad atómica de ejecución. O se ejecutan todas
sus operaciones o ninguna.
- CONSISTENCIA: la transacción debe dar lugar a un estado de la BD consistente,
cumpliéndose todas las restricciones de integridad, es decir, nunca dejará datos
inconsistentes.
- AISLAMIENTO: las modificaciones introducidas por una transacción no confirmada no son
visibles al resto de transacciones.
- DURABILIDAD: la confirmación implica la grabación de los cambios introducidos en la BD,
de modo que serán permanentes.

A estas propiedades se las suele conocer como propiedades ACID por sus siglas en inglés:
Atomicity, Consistency, Isolation y Durability.

Por tanto, esta unidad lógica de trabajo es un conjunto de sentencias que se ejecutan como si
fuesen una única sentencia. Además, existe una relación entre las sentencias que forman
parte de una transacción, de tal forma que la no ejecución de una sentencia supone que
carezca de sentido la ejecución de las demás.

Las transacciones se inician de forma implícita al ejecutar sentencias como CREATE, ALTER,
INSERT, UPDATE o de forma explícita con la sentencia SET TRANSACTION.

PABLO ARELLANO www.theglobeformacion.com Página 66

B3T4 MODELADO DATOS Y DISEÑO BD GSI

La finalización de una transacción debe ser explícita con una de las siguientes sentencias:
- COMMIT: confirma los cambios realizados en la base de datos durante la ejecución de la
transacción.
En bases de datos distribuidas se utiliza el algoritmo protocolo commit en 2 fases (two
phase commit) para la gestión de transacciones. Está basado en la existencia de un
coordinador. Al resto de nodos de la red se les llama participantes. El protocolo se divide
en dos fases: fase de preparación de commit donde el coordinador intenta preparar a
todos los participantes y fase commit donde el coordinador completa las transacciones a
todos los participantes.
- ROLLBACK: deshace todos los cambios que se hayan producido en la base de datos y se
vuelve al estado anterior al inicio de la ejecución de la transacción.
- SAVEPOINT: define un punto de recuperación en una transacción para poder revertirla
hasta dicho punto mediante ROLLBACK.

Los estados por los que pasa una transacción están representados en el siguiente diagrama:

Por otro lado, y en relación con las transacciones, es misión del SGBD la gestión de la
concurrencia y los bloqueos. Para ello, supongamos las operaciones de acceso:
- leer(X): consulta de un dato.
- escribir(X): actualización (inserción, modificación o borrado) de un dato.

Ahora bien, supongamos la ejecución de dos transacciones concurrentes. La primera

transacción retira 100€ de una cuenta y la segunda transacción retira 200€ de la misma
cuenta. Como podemos observar en la imagen siguiente, el resultado es incorrecto.

PABLO ARELLANO www.theglobeformacion.com Página 67

B3T4 MODELADO DATOS Y DISEÑO BD GSI

Visto en el ejemplo el acceso concurrente a los datos, el SGBD controla los accesos
concurrentes para evitar la pérdida de actualizaciones, la obtención de información
incoherente y la lectura de datos no confirmados que podrían ser anulados.

Los problemas de interferencias entre transacciones que nos podemos encontrar son:
− Lectura NO REPETIBLE: dos transacciones paralelas intentan modificar el mismo objeto de
la base de datos, leyendo ambas el valor antes de que la otra transacción lo actualice. Es
decir, ocurre cuando una transacción T1 lee dos veces un valor y no coinciden porque una
segunda transacción T2 ha modificado dicho valor entre ambas lecturas.
T1 lee fila A.
T2 modifica fila A.
T1 lee de nuevo la fila A y obtiene resultados diferentes.

− Lectura SUCIA: cuando se permite que una transacción lea una fila que fue modificada por
otra transacción que todavía no hizo commit y, por lo tanto, no ha almacenado el nuevo
valor. Es decir, ocurre cuando una transacción T2 lee un dato modificado por otra
transacción T1 antes de que haya realizado el commit (viola la propiedad de aislamiento).
Si T1 falla o realiza otra modificación del dato, el valor leído por T2 nunca ha llegado a ser
válido.
T1 inserta fila A.
T2 lee fila A.
T1 ejecuta rollback (se pierde la fila A).

− Lectura FANTASMA: es un caso particular de las lecturas no repetibles. Durante una

transacción se ejecutan dos consultas idénticas, y entre ambas consultas otra transacción
modifica datos que afectan a esta consulta. La colección de filas retornada por la segunda
consulta será distinta a la de la primera. Esto es, ocurre cuando una transacción T1 realiza
varias consultas iguales y una segunda transacción T2 inserta datos entre la realización de
ambas consultas, provocando que la segunda lectura de T1 muestre más datos que la
primera consulta.
T1 lee un conjunto de filas (satisfacen cláusula WHERE consulta SQL).

PABLO ARELLANO www.theglobeformacion.com Página 68

B3T4 MODELADO DATOS Y DISEÑO BD GSI

T2 inserta una nueva fila (satisface cláusula WHERE consulta anterior).

T1 vuelve a ejecutar consulta paso 1 y obtiene una fila más

Según el nivel de error que se considere aceptable en nuestro sistema, se establecerá el NIVEL
DE AISLAMIENTO necesario para evitar alguno o todos los problemas descritos en el apartado
anterior. Los niveles de aislamiento de las transacciones contemplados en ANSI SQL-92 son
(de menor a mayor nivel de aislamiento):
- Lectura NO COMPROMETIDA (read uncommitted): los cambios realizados por las
transacciones se encuentran disponibles inmediatamente. También denominada lectura
no confirmada.
- Lectura COMPROMETIDA (read committed): los cambios realizados por las transacciones
sólo se encuentran a disposición del resto cuando se comprometen (se realiza un commit).
Previene solo las lecturas sucias. También denominada lectura confirmada.
- Lectura REPETIBLE (repeatable read): las filas leídas o actualizadas por una transacción
quedan bloqueadas hasta que dicha transacción termina. Previene la lectura sucia y la
lectura no repetible.
- SERIALIZABLE: las transacciones ejecutadas de manera simultánea producen los mismos
efectos que si se ejecutaran en serie. Previene todas las interferencias entre transacciones.

EVITA la interferencia
Nivel de aislamiento Lectura SUCIA Lectura NO REPETIBLE Lectura FANTASMA

Lectura NO COMPROMETIDA NO NO NO

Lectura COMPROMETIDA SI NO NO

Lectura REPETIBLE SI SI NO

SERIALIZABLE SI SI SI

PABLO ARELLANO www.theglobeformacion.com Página 69

B3T4 MODELADO DATOS Y DISEÑO BD GSI

12. MECANISMOS DE RESOLUCIÓN DE CONFLICTOS

En los SGBD, múltiples usuarios acceden concurrentemente a la información de la base de
datos. Para controlar estos accesos concurrentes se utilizan normalmente los bloqueos. Cada
SGBD debe disponer de un planificador para asegurar que las operaciones concurrentes se
realizan sin conflictos.

El tamaño del elemento de datos o granularidad adecuado para el bloqueo (por ejemplo, fila
o tabla) afecta al grado de concurrencia de forma que, a menor tamaño del elemento que es
bloqueado aumenta el grado de concurrencia, aumenta la carga de trabajo para la gestión de
bloqueos y el espacio ocupado por la información de bloqueos.

La propiedad de concurrencia permite la intercalación de operaciones de distintas

transacciones con el objeto de mejorar el rendimiento, pero asegurando siempre la integridad
y consistencia de la BD.

El objetivo es evitar las interferencias entre transacciones (aislamiento) imponiendo

restricciones a la libre intercalación de operaciones de transacciones para garantizar que el
plan resultante es serializable.

Se proponen dos estrategias parara resolver los problemas de concurrencia:

- Mecanismos PESIMISTAS: basados en la suposición de que los conflictos entre
transacciones concurrentes ocurren con alta frecuencia. Se impiden ciertas operaciones si
son sospechosas de producir planes no serializables.
- Mecanismos OPTIMISTAS: basados en la suposición de que los conflictos entre
transacciones concurrentes ocurren con baja frecuencia. Permite a varios usuarios
intentar actualizar el mismo registro. Cuando un usuario actualiza satisfactoriamente el
registro, se informa que existe un conflicto al resto de usuarios que están intentando
confirmar sus actualizaciones.

También denominadas técnicas de validación o técnicas de certificación.

Los mecanismos optimistas se aconsejan en aquellos casos en que la mayoría de las

transacciones son de sólo lectura, la tasa de conflictos entre las transacciones puede ser baja.
Así, muchas de esas transacciones, si se ejecutasen sin la supervisión de un esquema de
control de concurrencia, llevarían no obstante al sistema a un estado consistente.

1. Mecanismos pesimistas
Protocolos:
- Protocolo basado en BLOQUEOS: los datos son bloqueados (operación lock) previamente
a su modificación para evitar que nadie más los modifique. Una vez realizados los cambios,
se confirman los cambios mediante un commit o se deshacen mediante un rollback,

PABLO ARELLANO www.theglobeformacion.com Página 70

B3T4 MODELADO DATOS Y DISEÑO BD GSI

liberándose (operación unlock) automáticamente el bloqueo. Si una transacción T2 intenta

adquirir un bloqueo de los mismos datos mientras están bloqueados por T1, tiene que
esperar hasta que la primera transacción finalice. La granularidad puede ser a nivel de
atributo, tupla, tabla, bloque de disco, fichero completo o incluso la base de datos entera.

Este protocolo no garantiza la serializabilidad por sí solo.

Los modos mediante los cuales se puede bloquear un elemento de datos son:
- Compartido: si una transacción T obtiene un bloqueo en modo compartido (C) sobre
el elemento Q, entonces T puede leer Q pero no lo puede escribir à bloquear_C(Q).
- Exclusivo: si una transacción obtiene un bloqueo en modo exclusivo (X) sobre el
elemento Q, entonces T puede tanto leer como escribir Q à bloquear_X(C).

Es necesario que toda transacción solicite un bloqueo del modo apropiado sobre el
elemento de datos Q dependiendo de los tipos de operaciones que se vayan a realizar
sobre Q.

Ejemplo: dadas las transacciones T1 y T2

T1 transfiere 50€ de la cuenta B a la A y muestra T2 visualiza el contenido de las cuentas A y B:
el contenido de ambas:
leer(B) leer(A)
B = B – 50 leer(B)
escribir(B) visualizar(A+B)
leer(A)
A = A + 50
escribir(A)
visualizar(A+B)

Incorporación de bloqueos en T1: Incorporación de bloqueos en T2:

bloquear_X(B) bloquear_C(A)
leer(B) leer(A)
B = B – 50 bloquear_C(B)
escribir(B) leer(B)
bloquear_X(A) visualizar(A+B)
leer(A) desbloquear(A)
A = A + 50 desbloquear(B)
escribir(A)
desbloquear(B)
desbloquear(A)
visualizar(A+B)

Problemas de este protocolo:

o Interbloqueo o abrazo mortal (deadlock): sucede cuando los usuarios A y B están
actualizando la base de datos a la vez y A bloquea un registro e intenta adquirir un
bloqueo mantenido por B, que a su vez está esperando a adquirir un bloqueo
mantenido por A, ambas transacciones quedarían en espera indefinidamente.

PABLO ARELLANO www.theglobeformacion.com Página 71

B3T4 MODELADO DATOS Y DISEÑO BD GSI

o Inanición: consistente en el aplazamiento indefinido de una transacción que está a la

espera de adquirir un recurso bloqueado.

- Protocolo de BLOQUEO EN 2 FASES (two-phase-locking): la idea básica es no hacer ningún

bloqueo (lock) después de algún desbloqueo (unlock). Durante la ejecución de una
transacción existan dos fases:
o Fase de crecimiento: se adquieren los recursos (mediante locks).
o Fase de devolución: se liberan los recursos (mediante unlocks). Los recursos adquiridos
por una transacción solo serán liberados después de ejecutarse una operación commit
o rollback.

Este protocolo garantiza la serializabilidad.

- Protocolo basado en ordenación por MARCAS TEMPORALES (time stamping): en los

protocolos de bloqueo que se han descrito se determina el orden entre dos transacciones
conflictivas en tiempo de ejecución a través del primer bloqueo que soliciten ambas que
traiga consigo modos incompatibles. Otro método para determinar el orden de
secuencialidad es seleccionar previamente un orden entre las transacciones. El método
más común para hacer esto es utilizar un esquema de ordenación por marcas temporales.

A toda transacción Ti del sistema se le asocia una única marca temporal fijada por el
sistema. Si a la transacción Ti se le ha asignado la marca temporal MT(Ti) y una nueva
transacción Tj entra en el sistema, entonces MT(Ti) < MT(Tj). Las marcas temporales de las
transacciones determinan el orden de secuencia. De este modo, si MT(Ti) < MT(Tj)
entonces el sistema debe asegurar que toda planificación que produzca es equivalente a
una planificación secuencial en la cual la transacción Ti aparece antes que la transacción
Tj. Por lo que se usa el orden de las marcas de tiempo para garantizar la serializabilidad.

Por otor lado, a cada elemento X de la BD se le asignan 2 valores:

o MT_lectura(X): marca de tiempo de la transacción más nueva (mayor marca de
tiempo) que ha leído X.
o MT_escritura(X): marca de tiempo de la transacción más nueva (mayor marca de
tiempo) que ha escrito X.

Este protocolo asegura que todas las operaciones leer y escribir conflictivas se ejecutan en
el orden de las marcas temporales, operando de la siguiente forma:
o Si una transacción T quiere leer X:
a) Si MT(T) < MT_escritura(X) entonces T necesita leer un valor de X que ya se ha
sobrescrito por lo que se rechaza la operación leer y T se retrocede.
b) Si MT(T) ≥ MT_escritura(X) entonces se ejecuta la operación leer y MT_lectura(X)
= max(MT_lectura(X), MT(T)).

PABLO ARELLANO www.theglobeformacion.com Página 72

B3T4 MODELADO DATOS Y DISEÑO BD GSI

o Si una transacción T quiere escribir X:

a) Si MT(T) < MT_lectura(X) entonces una transacción más nueva ya ha leído X antes
de que T tuviera la oportunidad de modificarlo; se rechaza la operación escribir y
T se retrocede.
b) Si MT(T) < MT_escritura(X) entonces T está intentando escribir un valor de X
obsoleto pues ya ha sido escrito por una transacción más nueva. Por tanto, se
rechaza la operación escribir y T se retrocede (si se aplica la regla de escritura de
Thomas se ignora la instrucción de escribir si MT(T) ≥ MT_lectura(X)).
c) En otro caso se ejecuta la operación escribir y MT_escritura(X) = MT(T).

Ejemplo: dadas las transacciones T1 y T2

T1 visualiza el contenido de las cuentas A y B: T2 transfiere 50€ de la cuenta B a la A y
muestra el contenido de ambas:
leer(B) leer(B)
leer(A) B = B – 50
visualizar(A+B) escribir(B)
leer(A)
A = A + 50
escribir(A)
visualizar(A+B)

La planificación de las transacciones con el protocolo de marcas temporales es:

T1 T2
leer(B)
leer(B)
B = B - 50
escribir(B)
leer(A)
leer(A)
visualizar(A+B)
A = A + 50
escribir(A)
visualizar(A+B)

Variante del protocolo de ordenación por marcas temporales: regla de escritura de

Thomas. Solo se modifica el procedimiento de actuación cuando T quiere escribir X,
apartado b).

PABLO ARELLANO www.theglobeformacion.com Página 73

B3T4 MODELADO DATOS Y DISEÑO BD GSI

2. Mecanismos optimistas
Protocolos:
- Protocolo basado en VALIDACIÓN: cada transacción T se ejecuta en dos o tres fases
diferentes durante su tiempo de vida dependiendo de si es una transacción de sólo lectura
o una de actualización. Las actualizaciones se realizan inicialmente sobre copias locales
(como las versiones). Este protocolo no impone restricciones, no requiere bloqueo y se
comprueban posibles interferencias al final. Se compone de 3 fases:
o Fase de lectura: ejecución de la transacción T. Los cambios se guardan en variables
locales temporales, no actualizándose la base de datos.
o Fase de validación: se comprueba si ha habido algún conflicto por la ejecución de T, es
decir, si se pueden copiar las variables locales a la base de datos preservando la
secuencialidad.
o Fase de escritura: si la fase de validación ha tenido éxito se actualización los datos a la
base de datos. En otro caso, T se retrocede.

3. Esquemas multiversión
En los esquemas de control de concurrencia multiversión, cada operación escribir(X) crea una
nueva versión de X. Cuando se realiza una operación leer(X) el gestor de control de
concurrencia elige una de las versiones de X que se va a leer. El esquema de control de
concurrencia debe asegurar que la elección de la versión que se va a leer se haga de tal manera
que asegure la secuencialidad. Asimismo, es crucial por motivos de rendimiento, que una
transacción sea capaz de determinar rápida y fácilmente la versión del elemento de datos que
se va a leer.

- Marcas temporales multiversión: protocolo más utilizado y que asegura la

secuencialidad. A cada transacción T del sistema se le asocia una única marca temporal
estática MT(T), ya descrita anteriormente.

A cada elemento de datos X se le asocia una secuencia de versiones <X1, X2, … , Xn>. Cada
versión Xi contiene tres campos:
o contenido es el valor de la versión Xi.
o MT_escritura(Xi) es la marca temporal de la transacción que haya creado la versión Xi.
o MT_lectura(Xi) es la mayor marca temporal de todas las transacciones que hayan leído
con éxito la versión Xi.

Una transacción T crea una nueva versión Xi del elemento de datos X cuando realiza la
operación escribir(X).
o contenido de la versión = valor que ha escrito T.
o MT_escritura(Xi) = MT(T).

PABLO ARELLANO www.theglobeformacion.com Página 74

B3T4 MODELADO DATOS Y DISEÑO BD GSI

o MT_lectura(Xi) = MT(Tj) cada vez que una transacción Tj lee el contenido de Xi si

MT_lectura(Xi) < MT(Tj).

Justificación del aseguramiento de la secuencialidad. La transacción T realiza una

operación leer(X) o escribir(X). Sea Xi la versión de T cuya marca temporal de escritura es
la mayor marca temporal menor o igual que MT(T).
o Si la transacción T ejecuta leer(X), entonces el valor que se devuelve es el contenido
de la versión Xi.
o Si la transacción T ejecuta escribir(X) y si MT(T) < MT_lectura(Xi), entonces la
transacción Ti se retrocede. Si no, si MT(T) = MT_lectura(Xi) se sobrescribe el contenido
de Xi, y en otro caso se crea una nueva versión de Q.

- Bloqueo de dos fases multiversión: combina las ventajas del control de concurrencia
multiversión con las ventajas del bloqueo de dos fases. Este protocolo distingue entre
transacciones de sólo lectura y transacciones de actualización.

Las transacciones de actualización realizan un bloqueo de dos fases riguroso, es decir,

mantienen todos los bloqueos hasta el final de la transacción. Así, se pueden secuenciar
según su orden de terminación.

A las transacciones de sólo lectura se les asigna una marca temporal leyendo el valor actual
de contador_mt antes de que comiencen su ejecución. Para realizar las lecturas siguen el
protocolo de ordenación por marcas temporales multiversión. Así, cuando una transacción
de sólo lectura T ejecuta leer(X), el valor que se devuelve es el contenido de la versión con
la mayor marca temporal menor que MT(T).

4. Tratamiento de interbloqueos
Ante una situación de interbloqueo, donde toda transacción de un conjunto dado está
esperando a otra transacción del mismo conjunto, se deben tratar dichos interbloqueos de
dos formas:
- PREVENCIÓN de interbloqueos: asegura que el sistema no llegará nunca a un estado de
interbloqueo. Existen dos enfoques a la prevención de interbloqueos. Un enfoque asegura
que no puede haber esperas cíclicas ordenando las peticiones de bloqueo o exigiendo que
todos los bloqueos se adquieran juntos. El otro enfoque es más cercano a la recuperación
de interbloqueos y realiza retrocesos de las transacciones en lugar de esperar un bloqueo,
siempre que el bloqueo pueda llevar potencialmente a un interbloqueo.

La segunda aproximación para prevenir interbloqueos consiste en utilizar expropiación y

retrocesos de transacciones. En la expropiación, cuando la transacción T2 solicita un
bloqueo que la transacción T1 posee, el bloqueo concedido a T1 debe expropiarse
retrocediendo T1 y concediéndolo a continuación a T2.

PABLO ARELLANO www.theglobeformacion.com Página 75

 B3T4 MODELADO DATOS Y DISEÑO BD GSI

o Esquema esperar-morir (wait-die): técnica sin expropiación. Cuando la transacción Ti

solicita un elemento de datos que posee Tj, Ti espera solo si MT(Ti) < MT(Tj). En otro
caso Ti retrocede (muere).

o Esquema herir-esperar (wound-wait): técnica con expropiación. Cuando la

transacción Ti solicita un elemento de datos que posee Tj, Ti puede esperar si MT(Ti) >
MT(Tj). En otro caso Tj retrocede (Ti hiere a Tj).

Ejemplo: dadas 2 transacciones T1 y T2, donde MT(T1)=8 y MT(T2)=10 y suponiendo

que T2 tiene un bloqueo en un elemento y T1 pide bloqueo para ese mismo elemento,
¿cómo se resuelve el conflicto si se aplica el enfoque WOUND-WAIT?
T1 se apropia del elemento que tenía bloqueado T2. T2 se aborta y se reinicia usando
la misma marca de tiempo.

Para ambos esquemas, cuando una transacción se retrocede se mantiene un MT original.

Esto hace que se evite la inanición.

Existe otro enfoque que se basa en bloqueos con límite de tiempo.

- DETECCIÓN y RECUPERACIÓN de interbloqueos: el sistema permite llegar a un estado de

interbloqueo, del cual ha de recuperarse. Periódicamente se ejecuta un algoritmo que
comprueba si el sistema se encuentra en un estado de interbloqueo. En caso afirmativo, el
sistema intenta recuperarse del interbloqueo.

Para la detección de interbloqueos se utiliza un grafo de espera, donde los nodos representan
las transacciones y los arcos las esperas.

Para la recuperación de interbloqueos, se seleccionan las transacciones interbloqueadas

(víctimas) que han de retrocederse.

PABLO ARELLANO www.theglobeformacion.com Página 76