Tema3DisegnoLogico

Tema 3. Diseño lógico. El modelo Relacional. SGBD DAW1B.
Curso 2024/20245 IES Albarregas
TEMA 3. EL MODELO RELACIONAL.
INDICE
1. ESTRUCTURA RELACIONAL DE LOS DATOS...............................................................................................1
. Tablas...................................................................................................................................................................1
. Transformación del MER al modelo relacional...................................................................................................1
. Dominio...............................................................................................................................................................3
. Claves...................................................................................................................................................................3
. Interrelaciones......................................................................................................................................................4
2. REDUCCION DEL DIAGRAMA ENTIDAD-RELACION AL MODELO RELACIONAL...............................5
3. CODD Y LAS BASES DE DATOS RELACIONALES......................................................................................21
4. NORMALIZACION.............................................................................................................................................22
. PRIMERA FORMA NORMAL (1FN).............................................................................................................26
. SEGUNDA FORMA NORMAL (2FN)............................................................................................................29
. TERCERA FORMA NORMAL (3FN).............................................................................................................31
. FORMA NORMAL DE BOYCE-CODD (FNBC)...........................................................................................34
. DEPENDENCIA MULTIVALUADA (DMV).................................................................................................35
. CUARTA FORMA NORMAL (4FN)...............................................................................................................36
. DEPENDENCIA DE JOIN (DJ).......................................................................................................................37
. QUINTA FORMA NORMAL (5FN)................................................................................................................38
. Campos Redundantes.........................................................................................................................................39
. RESUMEN Normalización................................................................................................................................40
1. ESTRUCTURA RELACIONAL DE LOS DATOS.
.Tablas
La representación lógica de los datos y las relaciones entre ellos se realizan mediante tablas,
donde las filas son las ocurrencias de la entidad o relación representada y las columnas de cada
fila son los atributos que definen dicha entidad o relación. En la terminología relacional, las
filas también reciben el nombre de tupla, y las columnas de atributo o campo.
Filas Columna Columna Columna

Num_empleado NombredeEmpleado Ape1
001 Juan Lopez
002 Ana Garcia
...
.Transformación del MER al modelo relacional.

Los elementos básicos del modelo ER son las entidades y las relaciones:
a) Las entidades, cuando se traducen al modelo relacional, originan tablas.
b) Las relaciones, en cambio, cuando se transforman, pueden dar lugar a claves ajenas de
alguna tabla ya obtenida o una nueva tabla.
Los atributos de la entidad serán atributos o columnas de la tabla y, de forma análoga, la clave
primaria de la entidad será la clave primaria de la tabla.
Página 1 de 40
Tema 3. Diseño lógico. El modelo Relacional. SGBD DAW1B. Curso 2024/20245 IES Albarregas
En el caso de las relaciones, es necesario tener en cuenta su grado y su cardinalidad para poder
decidir cuál es la transformación adecuada:
- Las relaciones binarias 1:1 y 1:N dan lugar a claves ajenas.
- Las relaciones binarias N:N y todas las n-arias se traducen en nuevas tablas.
Para que una tabla forme parte de una estructura relacional debe cumplir las siguientes
condiciones:
- Cada nombre de tabla debe ser único en la base de datos (esquema).
- Debe tener un sólo tipo de fila cuyo formato queda definido por el esquema de la tabla
o relación. Por lo tanto, todas las filas tienen las mismas columnas.
- Cada fila de una tabla debe ser única y no pueden existir filas duplicadas, es decir, con
el mismo contenido.
- Cada columna debe estar identificada por un nombre específico y ese nombre debe ser
único en una tabla. No pueden existir columnas con el mismo nombre.
- El valor de una columna para una fila debe ser único. No pueden existir múltiples
valores en una posición de una columna. Debe ser univaluado.
- Los valores de una columna deben pertenecer al dominio que representa y es posible
que uno mismo dominio se utilice para definir los valores de varias columnas
- Las columnas deben representar valores atómicos. Es decir, una columna no puede
estar compuesta de varias columnas.
Una tabla que cumpla estas condiciones se denomina tabla relacional o relación.
El concepto relación se utiliza generalmente para indicar que en la tabla relacional se

mantiene la asociación de otras tablas y por tanto representa a una entidad asociativa. La tabla
de base representa por sí misma un objeto o entidad propia.
Una tabla que cumpla las condiciones anteriores tiene asociadas las siguientes propiedades:
- Las filas pueden estar en cualquier orden, no siguen una secuencia determinada.
- Se pueden crear nuevas tablas relacionando columnas procedentes de dos o más tablas ya
existentes.
- Una fila hace referencia a todos los valores que la forman.
- Las columnas pueden estar en cualquier orden.
- Se hace referencia a una columna mediante el nombre que la identifica.
Ejemplo: tabla relacional "FRUTAS".

Nombre campo COD_FRUTA NOMFRUTA PRECIO
120 uva 245
tuplas o filas 123 melón 75
220 plátano 130
320 sandía 180
atributos o columnas
Se denomina Grado de una tabla relacional al número de atributos que la forma. En la
tabla frutas el grado es 3. G(frutas)=3
Se denomina Cardinalidad de una tabla relacional al número de tuplas que contiene. En
la tabla anterior C(frutas)=4.
Página 2 de 40
.Dominio
El dominio está determinado por el tipo de datos y el conjunto de todos los posibles
valores para una o más columnas de una tabla relacional. Por tanto, los valores contenidos en
una columna de una tabla relacional pertenecen a un dominio que previamente se define.
Mediante el dominio se expresan restricciones con respecto a los valores que puede tomar un
atributo.
Pueden distinguirse dos tipos de dominio:
- Dominios generales o continuos: Son aquellos que contienen todos los posibles valores entre
un máximo y un mínimo predefinidos o en un ámbito.
Ej. DNI: Números enteros positivos de 8 dígitos

Peso: Números reales y positivos.
Saldo: Números reales positivos y negativos.
Fecha de Nacimiento: Todas las fechas desde el inicio de siglo hasta hoy.
- Dominios restringidos o discretos: Contiene ciertos valores entre unos determinados.

Ej. Estado Civil: 1 Carácter de los siguientes: S,C,V,D
Provincia: Una de las provincias españolas.
En un sistema de gestión de bases de datos integrado generalmente los distintos usuarios deben
utilizar diferentes subconjuntos del universo total de los datos.
Modelo o modelo de datos denota el universo total de los datos, es decir, el conjunto completo
de todas las tablas relacionadas almacenadas en la base de datos. El Esquema es el conjunto
de declaraciones que describen el modelo.
Submodelo es el conjunto de relaciones a las que puede acceder un usuario determinado, y
subesquema las declaraciones correspondientes al submodelo.
.Claves
Una clave es un atributo o conjunto de atributos cuyos valores distinguen de forma
única una tupla específica de una tabla. Como una de las condiciones de una tabla relacional es
que no pueden existir filas duplicadas es necesaria la existencia de al menos una clave, que en
el peor de los casos estará formada por la concatenación de todos los atributos.
Para buscar la clave de una tabla relacional, nos debemos mover por los dominios de
los atributos, junto con los enlaces conceptuales existentes entre ellos, de tal modo que
tomando unos valores determinados para esos atributos, se identifique una única tupla de la
tabla. Por ej. Sean las tablas:
Personal: dni,nombre,dirección,ciudad,c.p.,fecha nacimiento,..

Clave :=> dni
Coches: Num_matrícula,Marca,modelo,color,Km.
Clave : Num_matrícula
Coches-Personal: dni,Num_matrícula
representandóse en esa tabla los distintos coches de que pueden disponer los empleados. Si
consideramos que un empleado puede disponer de más de un coche, y un coche está disponible
para más de un empleado, la clave será necesariamente: dni+num_matrícula
Página 3 de 40
Si una tabla dispone de varias claves a éstas se las denomina claves candidatas o
aspirantes. De entre todas ella se elegirá una que por excelencia identificará cada tupla. A esa
clave la denominaremos clave principal o primaria, y el resto de las claves serán claves
alternativas o secundarias. Los atributos que pertenecen a la clave primaria se denominan
atributos primarios y el resto atributos no primarios o secundarios.
Cuando la clave está formada por un sólo atributo se denomina clave simple. Si está formado
por varios se llamará clave compuesta o concatenada.
Para implementar de forma física las claves, se crearán índices. Los índices son las
formas de acceso.
El índice primario estará formado por la clave primaria, que podra ser simple o compuesta, y
los índices secundarios, si los hay, estarán formados por las claves secundarias. Cuando
interese acceder a las tuplas mediante atributos que no son clave, en transacciones on-line con
tiempo de respuesta limitado por ej., se generan índice secundarios múltiples, puesto que los
valores se repiten al no ser clave los atributos que lo forman. ( Por ej. en la tabla personal, se
puede generar un índice para el atributo ciudad, para consultar al personal de una determinada
ciudad.)
Si el sistema donde se desea implantar la BD no permite el uso de índices múltiples, se puede
generar el índice concatenando al final de los atributos elegidos la clave, para que pase a ser
clave alternativa.
Se denomina clave ajena a aquel o aquellos atributos que son clave principal en otra
tabla. Los dominios entre ambos deben ser compatibles. Por ej. DNI y matrícula son claves
ajena en coches-personal.
El concepto de clave ajena está estrechamente ligado al de integridad referencial. Para
mantener la integridad referencial de una Base de datos relacional, hay que garantizar que
cualquier clave ajena se corresponde con una clave primaria o es nula. Con ello se mantiene la
coherencia y veracidad de las relaciones entre las tablas.
.Interrelaciones
Una interrelación es una asociación entre tablas mediante atributos que tienen el mismo
dominio o compatible. Estos atributos generalmente hacen referencia a los mismos conceptos y
la interrelación se establece entre la clave ajena de una tabla (tabla hija) y la clave principal de
la otra tabla (tabla padre).
Por ej. entre las tablas asignaturas y Departamento existe una interrelación mediante el atributo
código del departamento. La tabla padre es Departamento y la tabla hija asignatura, ya que el
código de departamento es clave principal en departamento y clave ajena en asignatura.
2. REDUCCION DEL DIAGRAMA ENTIDAD-RELACION AL MODELO

RELACIONAL.
En la fase de diseño lógico realizaremos las transformación del MER al modelo
elegido, en este caso el relacional.
Para convertir el diagrama E-R al modelo relacional, estudiaremos las direferentes
cardinalidades existentes entre las entidades, así como el número de entidades participantes en
la relación.
Página 4 de 40
Los atributos se transformarán en columnas. En cada tabla identificaremos el atributo o

atributos que forman la clave primaria.
Nos apoyaremos en un ejemplo sobre una empresa de vendedores a domicilio que actúan en
determinadas zonas urbanas para estudiar los casos posibles.
* Cardinalidad 1:1
Ej. Un vendedor actúa en una zona y en una zona sólo actúa un vendedor
CODVEN NOMVEN TELVEN CODZON NOMZON

208 Martin 2030345 1 Vallecas
152 Sánchez 3521144 3 Aluche
En
principio se podría implementar con una sola tabla. La clave primaria de la relación puede ser
cualquiera de las claves de cada entidad, pero se tomará la que pertenezca a la entidad más
dominante.
Dado que el grado de correspondencia es 1:1 y exige obligatoriedad, CODVEN y CODZON no
podrán estar repetidos, no tomarán valores nulos ni existirá información redundante.
Inconvenientes
Estamos aglutinando mucha información, porque si se hacen muchos accesos a la tabla de
zona, tendremos que cargar los datos de vendedor.
Aunque sólo se necesite una tabla, es preferible si se van a hacer accesos por separado a las
entidades, que se utilicen 2 tablas, una para cada entidad. Para relacionarlas, una de las claves
pase a la otra tabla como clave ajena. Normalmente la clave no dominante en la tabla
dominante
VENDEDOR
CODVEN NOMVEN TELVEN CODZON
208 Martin 2030345 1
152 Sánchez 3521144 3
ZONA
CODZON NOMZON
1 Vallecas
3 Aluche
Página 5 de 40
* Cardinalidad 1:c ó c:1 Según el ej. un vendedor actúa en una zona y en una zona actúa uno
o ningún vendedor
Hay dos posibilidades:

a) Una tabla que mantiene a las dos entidades y cuya clave será la de la entidad que
tiene no obligatoriedad, ya que la otra podrá tomar valores nulos.
CODVEN NOMVEN TELVEN CODZON NOMZON

208 Martin 2030345 1 Vallecas
152 Sánchez 3521144 3 Aluche
---- ------ ----- 2 Centro
Inconvenientes
La cantidad de valores nulos de cada fila es grande desaprovechando memoria.
b) Dos tablas distintas para almacenar toda la información. Cada una de las tablas
contendrá la información relativa a una entidad y su clave primaria será la de la entidad que la
contenga. La clave de la entidad no obligatoria se incorporará como un atributo más a la tabla
formada a partir de la entidad obligatoria, siendo clave ajena.
VENDEDORES
208 Martin 2030345 1
152 Sánchez 3521144 3
ZONAS
CODZON NOMZON
1 Vallecas
3 Aluche
2 Centro
En la segunda solución no aparecen valores nulos en ninguna de las tablas. Esta solución se
utilizará cuando existan muchos valores de una entidad que no tienen correspondencia, pues en
ese caso todos los atributos de la otra entidad tienen valor nulo para esas filas provocando una
disminución notable de la velocidad de tratamiento de la tabla, ya que cualquier operación de
lectura/escritura sobre la tabla se realiza con una fila de tamaño mucho mayor del que se va a
utilizar.
Página 6 de 40
* Cardinalidad c:c Según el ej. un vendedor actúa en una o ninguna zona y en una zona
actúa uno o ningún vendedor. Es decir puede haber zonas que no tengan vendedores y
vendedores que no tengan zona.
Hay dos posibles soluciones:

a) Dos tablas, una para cada entidad, añadiendo en la tabla de la entidad más dominante
la clave de la otra entidad que en algunos casos tendrá valores nulos.
208 Martin 2030345 1
152 Sánchez 3521144 3
352 Romero 3721242 ------
ZONAS
CODZON NOMZON
1 Vallecas
3 Aluche
2 Centro
En este caso aparecen valores desconocidos en la clave ajena de la tabla dominante. Se puede
acceder desde el vendedor a la zona asociada o desde la zona al vendedor asignado. Esta es la
solución que generalmente se utiliza. Si existen muchos valores nulos en la clave ajena la
memoria que ocupan no es mucha, sólo el tamaño de la clave, y la ventaja reside en que
tratando sólo esa tabla se maneja la relación y no es necesario cargar y tratar dos tablas en
memoria.
b) Tres tablas: Una para cada entidad con la clave de la entidad y una tercera para
almacenar la correspondencia o relación entre las entidades, que estará formada por las claves
de las dos entidades, pudiendo ser cualquiera de ellas la clave primaria, siendo generalmente la
clave de la entidad más dominante.
VENDEDOR
CODVEN NOMVEN TELVEN
208 Martin 2030345
152 Sánchez 3521144
352 Romero 3721242
ZONAS
CODZON NOMZON
1 Vallecas
3 Aluche
2 Centro
Página 7 de 40
VEND/ZONAS
CODVEN CODZON
208 1
152 3
Esta solución se utiliza si no queremos tratar los valores nulos en la clave ajena de la
tabla dominante. En otro caso es más apropiada la solución anterior.
* Cardinalidad 1:N ó 1:M Según el ej. un vendedor actúa en ninguna, una o varias
zonas( para N y en una o varias para M)) y en una zona actúa un vendedor
Se necesitan dos tablas, una para cada entidad, utilizándose la clave de cada entidad
como clave primaria en su tabla correspondiente. La clave de la entidad padre (1) se añade
como atributo a la tabla de la entidad hija (n ó m).
VENDEDOR
208 Martin 2030345
152 Sánchez 3521144
352 Romero 3721242
457 Romera 3729092
ZONAS
CODZON NOMZON CODVEN
1 Vallecas 208
3 Aluche 152
2 Centro 208
* Cardinalidad C:N ó C:M Según el ej. un vendedor actúa en ninguna, una o varias
zonas( para N y en una o varias para M)) y en una zona actúa uno ningún vendedor
Hay
dos
soluciones:
Página 8 de 40
a) Dos tablas, una para cada entidad y en la tabla hija se incorpora la clave de la entidad
padre (clave ajena con valor nulo en ciertos casos). Esta solución es la misma que la usada para
la cardinalidad 1:N ó 1:M. Es la más generalizada.
b) Tres tablas, una para cada entidad, utilizándose como clave primaria de cada tabla la
clave de la entidad, y una tercera para la correspondencia de ambas, constituida por los
atributos que componen las claves de las dos entidades, siendo la clave de esta relación la
correspondiente a la entidad hija (n ó m). Esta solución no es la más apropiada, pero se
utilizará cuando no se desee tratar valores nulos.
VENDEDOR
208 Martin 2030345
152 Sánchez 3521144
352 Romero 3721242
ZONAS
CODZON NOMZON
1 Vallecas
3 Aluche
2 Centro
VENDxZONAS
CODZON CODVEN
1 208
2 208
3 152
* Cardinalidad N:N, N:M, M:M Según el ej. un vendedor actúa en ninguna, una o varias
zonas( para N y en una o varias para M)) y en una zona actúa ninguno, uno o varios
vendedores (para N y uno o varios para M).
Tres tablas, una por cada entidad, siendo la clave primaria la correspondiente a la clave
de la entidad que representa, y una tercera formada por los atributos que conforman la clave de
ambas entidades, siendo la clave de esta tabla la concatenación de las claves de las dos
entidades.
VENDEDOR
208 Martin 2030345
152 Sánchez 3521144
352 Romero 3721242
Página 9 de 40
ZONAS
CODZON NOMZON
1 Vallecas
3 Aluche
2 Centro
VENDxZONAS
CODVEN CODZON
208 1
208 2
152 1
* Cardinalidad N:M y la dimensión de la relación no es binaria

Si existe una cardinalidad muchos a muchos y la dimensión de la relación no es binaria,
sino que es orden "N", serán necesarias n+1 tablas para representarlo en el modelo relacional.
Una por cada entidad, siendo su clave primaria la clave de la entidad, y una más que contenga
los atributos correspondientes a las claves de todas las entidades, cuya clave será la
concatenación de las claves de todas las entidades que relaciona.
- Cardinalidad N:M:M
Ej. Supongamos una relación ternaria de forma que se asocien las entidades vendedor, zona y
material, de modo que un vendedor puede actuar en varias zonas y vender diversos materiales
en cada una de ellas, y que en cada zona diversos vendedores pueden ofrecer varios materiales
y que un material puede ser ofrecido en diversas zonas por diversos vendedores.
Para representarlo en el modelo relacional, necesitaríamos cuatro tablas:
VENDEDORES => CODVEN, NOMVEN, TELVEN

ZONAS => CODZON, NOMZON
MATERIALES => CODMAT, NOMMAT
Página 10 de 40
VENDxZONASxMATER. => CODVEN, CODZON, CODMAT Fecha_inicial Fecha_final
- Cardinalidad N:M:1
4 tablas. Una tabla por entidad. Para la relación cuando la conectividad de la relación es
M:N:1, la relación que se obtiene de su transformación tiene como clave primaria todos los
atributos que forman las claves primarias de las dos entidades de los lados de la relación
etiquetados con M y con N.
Ej. Un material es vendido en una zona por un único vendedor, en una zona un vendedor vende
varios materiales.y un vendedor vende un material en varias zonas.
VENDxZONASxMATER.=>CODMAT CODZON CODVEN Fecha_inicial Fecha_final
- Cardinalidad N:1:1
4 tablas, una para cada entidad y la de relación. Cuando la conectividad de la relación es N:1:1,
la relación que se consigue de su transformación tiene como clave primaria los atributos que
forman la clave primaria de la entidad del lado N y los atributos que forman la clave primaria
de cualquiera de las dos entidades que están conectadas con 1.
Ej. Un material es vendido en una zona por un único vendedor, en una zona un vendedor vende
varios materiales.y un vendedor vende un material en una única zona.
Página 11 de 40
VENDxZONASxMATER.=>CODMAT CODZON CODVEN Fecha_inicial Fecha_final
- Cardinalidad 1:1:1
En prinicipio: 4 tablas, una para cada entidad y la de relación.
Ej. Un material es vendido en una zona por un único vendedor, en una zona un vendedor
vende un único material y un vendedor vende un material en una única zona.
Cuando la conectividad de la interrelación es 1:1:1, la relación que se obtiene de su

transformación tiene como clave primaria los atributos que forman la clave primaria de dos
entidades cualesquiera de las tres relacionadas.
Por tanto hay tres claves candidatas para la relación.
Página 12 de 40
VENDEDORES => CODVEN, NOMVEN, TELVEN

ZONAS => CODZON, NOMZON
MATERIALES => CODMAT, NOMMAT
En la relación podría ser clave la concatenación de dos de cualquiera de las 3 claves de entidad.
Por ej.
VENDxZONASxMATER. => CODVEN, CODZON, CODMAT Fecha_inicial Fecha_final
Transformación de relaciones n-arias
La transformación de las relaciones n-arias se puede ver como una generalización de lo que
hemos explicado para las ternarias. En todos los casos, la transformación de una relación n-aria
consistirá en la obtención de una nueva relación que contiene todos los atributos que forman
las claves primarias de las n entidades relacionadas y todos los atributos de la relación (si los
hubiera). Podemos distinguir los casos siguientes:
a) Si todas las entidades están conectadas con “muchos”, la clave primaria de la nueva relación
estará formada por todos los atributos que forman las claves de las n entidades relacionadas.
b) Si una o más entidades están conectadas con “uno”, la clave primaria de la nueva relación
estará formada por las claves de n – 1 de las entidades relacionadas, con la condición de que la
entidad, cuya clave no se ha incluido, debe ser una de las que está conectada con “uno”.
Página 13 de 40
Página 14 de 40
- Transformación de relaciones recursivas (reflexivas).
Las transformaciones de las relaciones recursivas son similares a las que hemos visto para el
resto de las relaciones.
De este modo, si una relación recursiva tiene conectividad 1:1 o 1:N, da lugar a una clave
ajena, y si tiene conectividad M:N o es n-aria, origina una nueva relación.
- Cardinalidad 1:1. Obtener el modelo relacional del siguiente diagrama ER
Ejemplo, recogida de información de los matrimonios celebrados en una parroquia.
PERSONA : (dni, nombre,fecha, dni_pareja)

Claves posibles:
dni
dni_pareja
pk: dni
fk: dni_pareja referencia a PERSONA(dni)
Página 15 de 40
- Cardinalidad N:N. Obtener el modelo relacional del siguiente diagrama ER
Ejemplo, INE recoge la información de los matrimonios en el estado español.
PERSONA (DNI, nombre)
BODA (DNI_p1, DNI_p2, fecha)

pk: <DNI_p1, DNI_p2, fecha>
fk:
DNI_p1 referencia a PERSONA
DNI_p2 referencia a PERSONA
PIENSA: Crees que se podría optimizar la clave?
- Cardinalidad C:N Obtener el modelo relacional del siguiente diagrama ER
Ejemplo, información del departamento. El departamento depende de otro departamento de

más alto nivel. El de más alto nivel no depende de ninguno.
Ninguno depende del de más bajo nivel.
Página 16 de 40
DEPARTAMENTO : (cod_dpto, nombre, coddptodepende)

pk: cod_dpto
fk: coddptodepende (número departamento del que dependende el departamento pk).
Debe admitir nulo
La cardinalidad M:1 tendría el mismo paso.
- Transformación de entidades débiles
Las entidades débiles se traducen al modelo relacional igual que el resto de entidades, con una
pequeña diferencia. Estas entidades siempre están en el lado N de una relación 1:N que
completa su identificación.
Así pues, la clave ajena originada por esta relación 1:N debe formar parte de la clave primaria
de la relación correspondiente a la entidad débil.
Ejemplo de transformación de entidad débil
BANCO(codbanco, razonSocial,capital
SUCURSAL(Codbanco,numsucursal superficie,direccion)
Generalización/especialización
La generalización/especialización permite reflejar el hecho de que hay una entidad general, que
denominamos entidad superclase, que se puede especializar en entidades subclase:
a) La entidad superclase nos permite modelizar las características comunes de la

entidad vista de una forma genérica.
b) Las entidades subclase nos permiten modelizar las características propias de sus
especializaciones.
Es necesario que se cumpla que toda ocurrencia de una entidad subclase sea también una
ocurrencia de su entidad superclase.
Página 17 de 40
En la figura siguiente están representadas la entidad superclase, el empleado, y las entidades

subclase, que corresponden al directivo, al técnico y al administrativo.
Página 18 de 40
En la generalización/especialización, las características (atributos o relaciones) de la entidad

superclase se propagan hacia las entidades subclase. Es lo que se denomina herencia de
propiedades.
Para pasarlo al modelo relacional, cada una de las entidades superclase y subclase que forman
parte de una generalización/especialización se transforma en una tabla:
a) La tabla de la entidad superclase tiene como clave primaria la clave de la entidad

superclase y contiene todos los atributos comunes.
b) Las tablas de las entidades subclase tienen como clave primaria la clave de la entidad
superclase y contienen los atributos específicos de la subclase.
Ejemplo de transformación de la generalización/especialización
El ejemplo anterior contiene una generalización/especialización y, también, una relación M:N

en la que interviene una de las entidades subclase. Este ejemplo se traduce al modelo relacional
como se indica a continuación:
EMPLEADO(DNI, nombre, apellido, dirección, teléfono)

Clave primaria: DNI
DIRECTIVO(DNI, coche)
Clave primaria: DNI
fk: {DNI} referencia EMPLEADO
ADMINISTRATIVO (DNI, tiempo)
Clave primaria: DNI
TÉCNICO (DNI, título)
Clave primaria: DNI
PROYECTO(pro, …)
Clave primaria: pro
TRABAJA(DNI, pro, superficie)

Clave primaria: {DNI, pro}
fk:
{DNI} referencia TÉCNICO
{pro} referencia PROYECTO
Conviene observar que los atributos comunes se han situado en la relación EMPLEADO y que
los atributos específicos se han situado en la relación de su entidad subclase. De este modo,
coche está en DIRECTIVO, título en TÉCNICO y tiempo en ADMINISTRATIVO. Por otro lado,
la relación específica para los empleados técnicos denominada trabaja se transforma en la tabla
TRABAJA. Observa que esta tabla tiene una clave ajena que referencia sólo a los empleados
técnicos, y no a los empleados directivos o administrativos.
RESUMEN
Página 19 de 40
Los casos con cardinalidad C tienen dos soluciones dependiendo del tratamiento de los
nulos.
1:1 => a)1 tabla. Clave entidad dominante. (depende del SI)
b) 2 tablas. En la tabla dominante la clave de la otra tabla.
1:c => a) 1 tabla. Clave entidad no obligatoria. (resto nulos) (depende del SI)
b) 2 tablas una para cada entidad.En la obligatoria como atributo la no obligatoria
c:c => a) 2 tablas una para cada entidad.En la dominante es atributo la no dominante.
b) 3 tablas. Una para cada entidad.En la de relación las dos claves y como clave
la dominante.
1:N ,1:M => 2 tablas una para cada entidad. La clave de la padre como atributo a la hija.
C:N,C:M => a) 2 tablas. La del padre como atributo a la hija.
b) 3 tablas. En la de relación la clave será la hija.
N:M,N;N,M:M => Tres tablas una para cada entidad. En la de relación como clave la
concatenación de las claves de las entidades que relaciona.
M:M y dim > 2 => n+1 tablas. Una para cada entidad, y otra cuya clave será normalmente la
concatenación de las claves de las entidades que relaciona en función de la
cardinalidad
RESTRICCIONES DEL MODELO RELACIONAL
El modelo relacional tiene una serie de restricciones, es decir estructuras u ocurrencias no

permitidas. Las restricciones pueden ser :
- inherentes al modelo que son las restricciones de integridad

- o de usuario que son unos predicados definidos sobre columnas o filas que deben
ser verificados por el sistema para determinar si son válidos en el sistema de
información.
Las restricciones inherentes al modelo son:
- Regla de Integridad de Entidad: "Ninguna columna de las que forman la clave primaria
puede tener valor nulo".
Un nulo no es ningún valor, sino que es una marca que se aplica a una columna para indicar
que no tiene asignado ningún valor.
- Regla de Integridad Referencial: "Una clave ajena debe tener un valor de la clave primaria
de la tabla con la que está relaciona, o bién tener valor nulo".
- Reglas para claves ajenas : Cualquier estado de la base de datos que no satisfaga la
integridad referencial es incorrecto por definición. Hay una serie de reglas para evitar estos
estados incorrectos que se indican en el momento de la definición de la base de datos,
especificando que debe hacer el sistema en caso de borrado o modificación que atente contra la
integridad referencial. Hay las siguientes posibilidades:
- Operación restringida (RESTRICT) : No se permite borrar filas ni modificar el
valor de su clave primaria si existen claves ajenas que contengan su valor.
- Operación con propagación en cascada (CASCADE) : El borrado o la
modificación de la clave primaria lleva consigo el borrado o modificación de las
filas con los mismos valores en la clave ajena.
- Operación con puesta a nulos (SET NULL) : El borrado o modificación de las
filas de tabla que contiene la clave primaria provoca la asignación de el valor nulo
en las claves ajenas con el mismo valor.
Página 20 de 40
- Operación con puesta a valor por defecto (SET DEFAULT) : El borrado o

modificación de las filas de tabla que contiene la clave primaria provoca la
asignación de un valor por defecto. Este valor por defecto se especificará en el
momento de definir la clave ajena.
- Restricciones de usuario : es un predicado definido sobre columnas o filas que han de ser
verificadas por el sistema para determinar si la información es válida. Estas restricciones de
usuario pueden estar almacenadas en el diccionario de la base de datos o bien estar soportadas
como procedimientos o disparadores. Una restriccion de usuario ha de tener un nombre, el
predicado que ha de ser satisfecho y una respuesta a la operación que intenta violar la
restricción.
(Ej: SALAR >= SALAR_MINIMO_INTERPROFESIONAL).
3. CODD Y LAS BASES DE DATOS RELACIONALES.

E.F. Codd es considerado el creador de las bases de datos relacionales a raiz de los
trabajos publicados sobre el tema en 1969-1970, aunque los primeros SGBDR no aparecieron
en el mercado hasta principios de los años ochenta. En la actualidad muchas bases de datos se
distribuyen como relacionales aprovechando la garantía ofrecida por bases de datos puramente
relacionales y de gran prestigio como db2 por ej.. Por ello, en 1985, Codd publicó un artículo
en el que daba a conocer once reglas que debe cumplir cualquier base de datos que desee
considerarse relacional:
1.- Regla de Información: Toda la información de una base de datos relacional está
representada explícitamente a nivel lógico y exactamente de un modo (mediante valores de
tablas).
2.- Regla de acceso garantizado: Se garantiza que todos y cada uno de los datos (valor
indisoluble, único o atómico) de una base de datos relacional son lógicamente accesibles
recurriendo a una combinación de nombre de tabla, valor de clave primaria y nombre de
columna.
3.- Tratamiento sistemático de valores nulos: Los valores nulos (distinto de cadena de
caracteres vacía o en blanco y distinto de cero o cualquier otro número) se soportan en los
SGBD completamente relacionales para representar la falta de información y la información
inaplicable de un modo sistemático e independiente del tipo de datos.
4.- Catálogo en línea dinámico basado en el modelo relacional: La descripción de la base de

datos se representa a nivel lógico, del mismo modo que los datos ordinarios, de modo que los
usuarios autorizados puedan aplicar a su interrogación o consulta el mismo lenguaje relacional
que aplican a los datos regulares.
5.- Regla de sublenguaje completo de datos: Un sistema relacional puede soportar varios
lenguajes y varios modos de uso terminal (por ejemplo el modo de rellenar con blancos). Sin
embargo, debe haber al menos un lenguaje cuyas sentencias sean expresables, mediante alguna
sintaxis bien definida, como cadenas de caracteres, y que sea completa en cuanto al soporte de
todos los puntos siguientes:
- Definición de datos
- Definición de vistas
- Manipulación de datos (interactiva y por programa)
- Restricciones de integridad
Página 21 de 40
- Autorización
- Fronteras de transacciones (comienzo, cumplimentación y vuelta atrás)
6.- Regla de actualización de vista: Todas las vistas que sean teóricamente actualizables son
también actualizables por el sistema.
7.- Inserción, modificado y borrado de alto nivel. La capacidad de manejar una relación de
base de datos o una relación derivada como un único operando se aplica no sólo a la
recuperación de datos, sino también a la inserción, modificación y borrado de los datos.
8.- Independencia física de los datos. Los programas de aplicación y las actividades terminales
permanecen lógicamente inalterados cualquiera que sean los cambios efectuados ya sea a las
representaciones de almacenamiento o a los métodos de acceso.
9.- Independencia lógica de los datos: Los programas de aplicación y las actividades
terminales permanecen lógicamente inalterados cuando se efectúen sobre las tablas de base
cambios preservadores de la información de cualquier tipo que teóricamente permita
alteraciones.
10.- Independencia de integridad. Las restricciones de integridad específicas para una base de
datos relacional particular deben ser definibles en el sublenguaje de datos relacional y
almacenables en el catálogo, no en los programas de aplicación.
11.- Regla de no subversión: Si un sistema relacional tiene un lenguaje de bajo nivel (un sólo
registro cada vez), ese bajo nivel no puede ser utilizado para subvertir o suprimir las relgas de
integridad y las restricciones expresadas en el lenguaje relacional de nivel superior (múltiples
registros a la vez).
4. NORMALIZACION
La normalización es una metodología de análisis para el diseño de los datos.
Las bases de datos relacionales se normalizan para:
• Evitar la redundancia de los datos.
• Evitar problemas de actualización de los datos en las tablas.
• Proteger la integridad de los datos.
La normalización de las relaciones que forman una base de datos van a evitar los
inconvenientes de redundancia y anomalías de actualización de datos que un mal diseño pueda
tener.
El punto de partida puede ser:

- el diseño conceptual, en cuyo caso conoceremos ya los atributos existentes y las relaciones
entre ellos
- o bien un diseño lógico existente al que aplicaremos las formas normales para corregir en su
caso las posibles anomalías existentes, tales como redundancias de información derivadas de
diseños deficientes o de sucesivas ampliaciones de la base de datos.
Página 22 de 40
El proceso de normalización generalmente se usa en el modelo de datos relacional, pero

se puede extender su uso a los modelos jerárquicos o en red, ya que un modelo relacional se
puede modificar para su implantación en un SGBD jerárquico o en red.
El proceso de normalización consiste en la aplicación de una serie de normas para

obtener los datos agrupados en diferentes tablas, de forma que su estructura sea óptima para su
implementación, gestión y explotación desde futuras aplicaciones, eliminando redundancias
perjudiciales. Se basa en la independencia de los datos y en las relaciones entre ellos, y obtiene
un número de tablas, dejando en cada una de ellas los atributos imprescindibles para
representar a las entidades, o a la relación entre entidades a la que hace referencia la tabla
mediante la conexión de sus claves. Se dice que una tabla está en una forma normal cuando
satisface las restricciones impuestas por dicha norma..
El proceso de normalización parte de las formas normales definidas por E.F.Codd

(creador de las b.d. relacionales) en 1970. Codd formuló las tres primeras formas normales
(1FN, 2FN, 3FN). Posteriormente unas anomalías detectadas forzaron a crear una forma
normal más completa que se denominó FNBC (forma normal de Boyce y Codd). Más tarde
Fagin definió la 4FN y la 5FN.
Ventajas.
Las ventajas que se obtienen tras la normalización de los datos son:
- Facilidad de uso y claridad: Los datos están agrupados en tablas que identifican claramente
un objeto o relación. Su representación es clara y sencilla para el usuario.
- Flexibilidad y facilidad de gestión: La información que necesitan los usuarios se puede
obtener de las tablas relacionales o relaciones mediante operaciones del álgebra y el cálculo
relacional.
- Precisión: Las interrelaciones entre las tablas consiguen mantener información diferente
relacionada con toda exactitud.
- Mínima redundancia: La información no está duplicada innecesariamente.
- Máximo rendimiento de las aplicaciones: Sólo se trata aquella información que va a servir de
utilidad a cada aplicación.
Como ejemplo de los inconvenientes de la desnormalización no justificada de los datos,

tomaremos los ficheros utilizados en una facturación de un distribuidor.
FACTURAS : Contiene las facturas que se emiten a las empresas a las que se distribuyen.
Num_Factura
Nombre de la Empresa
Dirección de la empresa
Ciudad
Fecha de la factura
ARRAY de 15 posiciones para guardar el detalle de la factura, con los campos:
- Nombre del artículo
- Unidades
- Precio unitario
- % iva
- Precio total
Total importe de la factura
Página 23 de 40
Porcentaje de descuento
Total descuento
Total factura
EMPRESAS : Contiene los datos sobre las empresas a las que distribuye.
Cod_empresa
CIF
Nombre de la empresa
Domicilio
Ciudad
Teléfono
fax
Persona de contacto
Total acumulado compras
Fecha última compra.
ARTÍCULOS : Contiene los datos sobre los artículos que se distribuyen
Cod_artículo
Denominación
Precio de última compra
Precio de venta
Porcentaje de IVA
Unidades mínimas
Unidades en almacen
Porcentaje de reposición
Fecha de última entrada
Fecha de última salida
PROVEEDORES Contiene los proveedores que nos suministran los artículos y los artículos
que suministra cada proveedor.
Código de proveedor
Cod_artículo que sumistra
Precio del artículo
CIF
Nombre
Domicilio
Ciudad
Teléfono
Fax
Inconvenientes de este diseño:
- Mala gestión de la memoria. En facturas se define un array para guardar cada uno de los
artículos. Cuando el número de artículos es inferior al tamaño del array se desperdicia
memoria. Si el número de artículos es superior a 15 no podemos reflejarlo en la misma factura.
Así mismo, se plantean problemas para la actualización de un determinado artículo o para la
búsqueda en todas las facturas. Esta anomalía es tratada en la 1FN y se corrige aplicando una
Página 24 de 40
serie de proyecciones para eliminar los grupos repetitivos sin que se produzca pérdida de
información.
- Existe redundancia de información. Dado que un proveedor puede suministrar más de un
artículo, se están repitiendo los datos del proveedor por cada artículo que suministra.
Esta anomalía es tratada en la 2FN y se corrige realizando unas proyecciones para eliminar
dependencias parciales de los atributos con respecto a la clave.
- Existen atributos que no dependen de la clave, sino de otro atributo secundario. Esta situación
provoca problemas de mantenimiento. Por ejemplo en la tabla facturas se guarda además del
código otros datos de cliente. Si se realiza una modificación de la dirección de un cliente
tendremos que modificarlo tanto en el fichero de clientes como en facturas. Esta situación es
tratada en la 3FN y se corrige realizando unas proyecciones para eliminar las dependencias de
atributos secundarios.
- Existen campos calculados que sería necesario recalcular si se produce algún cambio en las
cantidades que intervienen. Por ej. Total factura, será necesario modificarlo si se modifica el
precio de algún artículo.
DEPENDENCIA FUNCIONAL (DF)
Concepto de DF.
La normalización se basa en la dependencia funcional.
Se dice que el atributo o conjunto de atributos B depende funcionalmente del atributo o
conjunto de atributos A y se representa como A --> B si y sólo si cada valor de A se
corresponde a nivel conceptual con un único valor de B. En otros términos, si en cualquier
instante conocido el valor de A podemos conocer el valor de B.
Las DF se determinan al estudiar las propiedades de todos los atributos de la relación y las
interrelaciones existentes entre ellos.
Ej. Entre los atributos DNI y NOMBRE existe una DF.

dni --> nombre
Num_expte. --> nombre_alumno.
Existen atributos que no tienen entre sí una DF por ej. los atributos empresa, dni y sueldo,
suponiendo que una persona puede trabajar en varias empresas.
dni -/-> sueldo Depende también de la empresa
pero sí se cumple que dni.empresa --> sueldo.
La concatenación de los atributos dni y empresa hacen que el sueldo DF de ellos.
El operador “.” representa la expresión “junto con” o “y” entre los atributos que relaciona. El
operador “|” hace referencia a la expresión “o también”
Así dni --> nombre | dirección.
Es preciso estudiar las DF para encontrar las claves candidatas, y a partir de ellas
obtener el mínimo conjunto posible de atributos tales que una vez conocidos sus valores en las
tuplas los demás queden definidos. Será la clave principal.
Todo el proceso de normalización está basado en distintas variantes de la DF. Lo

primero que se debe conocer por tanto son las DF existentes entre los atributos, y sobre todo
aquellas relevantes que relacionan atributos de distintas entidades mediante sus claves dando
lugar a relaciones, ya que son las que llevan de forma implícita la complejidad del problema.
Estas deben ser cuidadosamente analizadas y estudiadas y aprobadas por el usuario.
Página 25 de 40
El proceso de normalización consiste en reemplazar las relaciones por proyecciones

adecuadas en función de las DF existentes, de forma que la reunión natural de las proyecciones
genere la relación original y no se produzca pérdida de información.
Si se cumple la DF la tabla puede descomponerse, siendo condición suficiente pero no

necesaria, es decir, la tabla también puede descomponerse sin necesidad de cumplir ninguna
DF.
Para llevar a cabo el proceso de normalización es aconsejable dar los siguientes pasos:
1.- Elegir una clave primaria para cada relación.
2.- Construir un diagrama de dependencia en función de esas claves.
3.- Construir las nuevas relaciones basándonos en esas claves.
Dependencia funcional total.

Se dice que el atributo Y tiene una dependencia funcional total con el atributo X, si
tiene una dependencia funcional con X y no depende funcionalmente de ningún subconjunto de
X.
Ej. dni.empresa --> nombre.
No es total puesto que Nombre depende del dni únicamente. A esta dependencia se la
denomina parcial.
La DF total sería dni.empresa --> sueldo.
Las dependencias que interesan para tratar las anomalías y su solución son la DF totales.
Representación gráfica de las DF.

La representación gráfica de las DF permite tener una visión gral. de los datos y las
relaciones existentes entre ellos. Previamente hemos de tener identificadas las entidades, sus
claves y las claves de las relaciones entre las entidades y realizada la fase del diseño
conceptual.
La clave, obtenida de tratar las DF existentes, se representa dentro de una caja de líneas
continuas con sus atributos primarios. El resto de los atributos se representa fuera de la caja, y
después las dependencias significativas entre ellos. Si existen dependencias parciales, se
representarán en una caja de líneas discontinúas para no confundirlo con la clave.
Por ej. sean las dependencias:

A.B.C --> M | N | S es equivalente a A.B.C. -->M | S
M --> N M --> N
B.C --> O | P | R B.C --> O | R
O --> P O --> P
C --> Q C --> Q
Una tabla está normalizada cuando cumple todas las formas normales
.PRIMERA FORMA NORMAL (1FN)

Una tabla se encuentra en 1FN si y sólo si los valores que componen el atributo de una
tupla son atómicos (univaluados y elementales). Es decir, un atributo no pude contener varios
valores ni valores compuestos.
Al conjunto de atributos que se repiten se le denomina cjto. repetitivo. Diremos por tanto que
una tabla está en 1FN si no existen conjuntos repetitivos.
Página 26 de 40
Por ej. en la siguiente tabla se encuentran los distintos tipos de materiales existentes en
una ferretería. Un material tiene un código que lo identifica, su descripción y sus medidas.
MATERIALES
COD_MAT DESCRIPCION MEDIDAS

039 Tornillo 3,5-5-7
067 Arandela 2-5
461 Broca 5-6-7-8-9
057 Taco 5-6-7-8-9-10
Esta tabla no se encuentra en 1FN puesto que el atributo medidas tiene distintos valores en
distintas tuplas en lugar de contener un único valor.
Es un defecto común que se encontraba en los ficheros cuando para un valor (clave) se podían
encontrar un conjunto de valores de otro atributo.
El problema que se plantea es:
- La falta de espacio en el campo para los valores que pueden aparecer, o el

desaprovechamiento del atributo cuando existen pocos valores.
- La dificultad del tratamiento para actualizaciones (MIB), consultas y búsquedas de un valor

determinado. Por ej. conocer los materiales con una determinada medida.
Este tipo de problemas, derivados del diseño, puede aparecer en ficheros existentes en
sistemas ya creados que deben ser optimizados.
Para pasar a 1FN una tabla que tiene atributos multivaluados se siguen los siguientes pasos:
1.- Se localizan los atributos que forman la clave principal.

2.- Se descompone la tabla realizando dos proyecciones:
2.1 . La clave con los atributos que tienen valores únicos, tomando la tabla el nombre de
la tabla original.
2.2. Se crea otra tabla con la clave y los atributos que tienen valores múltiples,
distribuyendo cada uno en una fila, por lo que cada fila tendrá un único valor elemental para
cada atributo. La tabla que se genera tendrá un nombre nemotécnico que estará compuesto por
la abreviatura de los atributos que la definen, y la clave estará formada en la mayoría de los
casos por ambos atributos. Si se encontrará un conjunto de atributos que definen de forma
única cada fila y cuyo número fuese inferior, se elegiría como clave primaria.
Según el ej.
MATERIALES MAT-MED
COD_MAT DESCRIPCION COD_MAT MEDIDA
039 Tornillo 039 3,5
067 Arandela 039 5
461 Broca 039 7
057 Taco 067 2
067 5
461 5
.... ....
En ciertos casos no es conveniente formar la clave con atributos que tienen un dominio
tan diferente (alfanumérico y real). Para solucionarlo se codifica el atributo con dominio
Página 27 de 40
conflictivo, en este caso el real. Es conveniente no crear índices primarios sobre atributos cuyo
dominio es flotante. Quedaría de la forma:
MEDIDAS MAT-MED
COD_MED MEDIDA COD_MAT COD_MED
1 3.5 039 1
2 5 039 2
3 7 039 3
4 2 067 4
.... .... 067 2
.... ...
En el caso de los atributos compuestos se descomponen esos atributos en campos separados,

ya que se pueden unir sin problema en cualquier operación pero extraer datos independientes
resulta complicado si todo se guarda en un mismo campo.
Ej. Clientes
DNI Apellidos y Nombre Direccion Telefono

1234567A Garcia Ferrol De la O Juan C/ Paz ,2 Mérida Badajoz 123443122
8923232B Ferran Perez Maria de la O C/ Luz, 2 Casar Caceres 232323323
Se descompone de la forma:
DNI Apellidos Nombre Direccion Localidad Provincia Telefono

1234567A Garcia Ferrol De la O Juan C/ Paz ,2 Mérida Badajoz 12344312
2
8923232B Ferran Perez Maria de la O C/ Luz ,2 Casar Caceres 23232332
3
Veamos otro ejemplo con un fichero de facturas donde almacenamos las facturas que nos
emiten los proveedores:
FACTURA
Num_factura Cod_prov Fecha_fac Cod_artículo Cantidad
123 1 01/01/2023 1 5
2 6
3 7
234 1 12/01/2023 2 3
3 4
123 2 12/01/2023 4 23
5 2
6 6
7 10
Esta tabla no se encuentra en 1FN, ya que en una factura se detallan varios artículos, por tanto
encontramos los atributos Cod_artículo y cantidad_enviada que pueden tomar varios valores
para una factura de un proveedor. No dependen funcionalmente de factura, ya que con un
número de factura no identificamos un único artículo. Lo convertimos a 1FN, realizando las
proyecciones siguientes:
FACTURAS= P(FACTURA, num_factura,cod_prov,fecha_fac)
ART_FAC=P(FACTURA, Num_fac,cod_prov, cod_art,cantidad)
Página 28 de 40
FACTURAS ART_FACT
Num_factura Cod_prov Fecha_fac Num_fac Cod_prov Cod_art Cantidad
Puede ocurrir que exista más de un conjunto repetitivo. En ese caso se aplican de nuevo
los pasos para convertir la tabla a 1FN tantas veces como sea necesario hasta que cumpla la
norma.
Ejercicio:
Dada la tabla CLIENTES en donde el diseñador se da cuenta de que tiene que guardar
múltiples números de teléfono para algunos clientes (un cliente puede tener varios teléfonos).
ID Cliente Nombre Apellido Teléfono

123 Rachel Ingram 555-861-202
555-403-165
456 James Wright
555-776-410
789 Cesar Dure 555-808-963
Pasarla a 1FN.
Realiza un correcto diseño del MER para esa información y observa al pasarlo al modelo
relacional que resulta normalizado.
.SEGUNDA FORMA NORMAL (2FN)
Una tabla está en 2FN si y sólo si cumple dos condiciones:
1. Se encuentra en 1FN
2. Todo atributo secundario (aquellos que no pertenecen a la clave pincipal) depende de la
clave principal en su totalidad y no de una parte de ella. Es decir todo atributo secundario tiene
una dependencia funcional total con la clave.
Esta forma normal sólo se considera si la clave principal es compuesta, es decir, si está
formada por varios atributos. Si la clave principal es simple (un único atributo), entonces la
tabla ya se encuentra en 2FN si se encuentra en 1FN.
Por ej. sea la tabla PERSONAL donde almacenamos información sobre los sueldos de las
personas en varias empresas.
PERSONAL (dni, empresa, nombre, sueldo)
la DF que refleja la tabla es dni.empresa -->nombre | sueldo

sin embargo las DF también son dni --> nombre dni.empresa --> sueldo
La tabla PERSONAL no se encuentra en 2FN ya que existe un atributo (nombre) que depende
de parte de la clave (dni) y no tiene por tanto una dependencia funcional total con la clave.
La representación gráfica quedaría de la forma:
PERSONAL
Página 29 de 40
DNI ----|----> nombre

EMPRESA |----> sueldo
Gráficamente, si existe una flecha que parte del interior de la caja que engloba a la
clave, entonces la tabla no está en 2FN.
Cuando una tabla no se encuentra en 2FN se está produciendo una redundancia de información
con los consiguientes problemas en las operaciones de actualización (MIB), búsquedas y
consultas.
Para convertir una tabla que no está en 2FN, y ya se encuentra en 1FN, se realizan dos
proyecciones obteniéndose 2 tablas:
1.- Una tabla con la clave y todos los atributos que tienen una dependencia funcional total con
ella. La clave será la clave completa.
2.- Otra tabla con la parte de la clave que tiene dependencias, que será la clave, y los atributos
que dependen de ella.
Según el ejemplo:
EMPLEADOS=P(PERSONAL,dni,nombre);
SUELDOS=P(PERSONAL, dni,empresa,sueldo);
Como Ej. aplicar la 2FN a la siguiente tabla de facturas

FACTURAS
Num_factura Num_línea Cod_cliente Cod_artículo cantidad precio fecha_fac Num_albarán
12 1 1 1 3 5 01/02/23 13
12 2 1 2 4 89 01/02/23 13
12 3 1 5 5 34 01/02/23 13
13 1 2 2 5 23 01/02/23 15
Se encuentra en 1FN, ya que no existen grupos repetitivos

Las DF existentes son:
Num_factura.Num_línea ---> cod_art | cantidad | precio
Num_factura ---> Cod_cliente| fecha_fac | Num_albarán
En la tabla original no existe una DF total de todos los atributos con la clave. La pasamos a
2FN:
CAB_FAC = P(FACTURAS, Num_factura, cod_cliente fecha_fac, Num_albarán)

LIN_FAC = P (FACTURAS, Num_factura, Num_línea, Cod_art, cantidad, precio)
Al elegir la clave de LIN_FAC, si queremos controlar que un artículo no aparezca en más de

una línea, podemos eliminar num_línea y poner en su lugar cod_art, y las DF serían las
mismas.
LIN_FAC = P (FACTURAS, Num_factura,Cod_art, cantidad, precio)
Ejercicio
Considera una tabla describiendo las habilidades de los empleados y el lugar habitual de
trabajo. Un empleado puede tener varias habilidades pero un solo lugar de trabajo.
Página 30 de 40
Habilidades de los empleados
Empleado Habilidad Lugar_trabajo

Jones Mecanografía 114 Main Street
Jones Taquigrafía 114 Main Street
Jones Tallado 114 Main Street
Bravo Limpieza ligera 73 Industrial Way
Ellis Alquimia 73 Industrial Way
Ellis Malabarismo 73 Industrial Way
Harrison Limpieza ligera 73 Industrial Way
La clave de la tabla es {Empleado, Habilidad}.
Aplica la 2FN y representa el MER de forma correcta.
.TERCERA FORMA NORMAL (3FN)
La DF transitiva se aplica para analizar las tablas en 3FN.
En una tabla T, un atributo C es transitivamente dependiente de otro (A), si se conoce por

diferentes vías, una a través de la clave, y otra a partir de otro atributo intermedio (B) no
primario.
A ------> B ------> C.
Se puede entonces descomponer en dos relaciones de la forma:
A -----> B y B -----> C.
Una tabla está en 3FN si y sólo si cumple dos condiciones:

1.- Se encuentra en 2FN
2.- No existen atributos no primarios que son transitivamente dependientes de cada posible
clave de la tabla.
Esto significa que un atributo secundario sólo se debe conocer a través de la clave
principal o claves secundarias de la tabla y no por medio de otro atributo no primario.
Un ejemplo de una tabla 2FN que falla en satisfacer los requerimientos de la 3FN es:
Ganadores del torneo

Fecha_nacimiento
Torneo Año Ganador
(fecha de nacimiento del ganador)
Indiana Invitational 1998 Al Fredrickson 21 de julio de 1975
Cleveland Open 1999 Bob Albertson 28 de septiembre de 1968
Des Moines Masters 1999 Al Fredrickson 21 de julio de 1975
Indiana Invitational 1999 Chip Masterson 14 de marzo de 1977
Restaurante del Pozo 1994 Fred Landon 14 de febrero de 1964
Página 31 de 40
Dfs:
Torneo, Año-> Ganador
Ganador-> Fecha_nacimiento
Clave {Torneo, Año}
La violación de la 3NF ocurre porque el atributo no primario “Fecha de nacimiento del

ganador” es dependiente transitivamente de {Torneo, Año}.
El hecho de que la “Fecha de nacimiento del ganador” (atributo no-primario) es

funcionalmente dependiente de Ganador hace que la tabla sea vulnerable a inconsistencias
lógicas, pues no hay nada que impida a la misma persona ser mostrada con diferentes fechas de
nacimiento en diversos registros.
Por lo tanto existe una dependencia funcional transitiva del atributo Fecha_nacimiento con la
clave.
Torneo, Año-> Ganador -> Fecha_nacimiento
por transitividad Torneo, Año→ Fecha_nacimiento
Algoritmo de descomposición para pasarla a 3FN:
Para pasar una tabla a 3FN se realizan 2 proyecciones y se genera:
1.- Una tabla con la clave y todos los atributos no primarios que no son transitivamente
dependientes.
2.- Otra tabla con los atributos transitivamente dependientes y el atributo no primario (que será
la clave de la nueva tabla) por medio del cual se mantiene la transitividad.
En el ejemplo, para expresar los mismos hechos sin violar la 3FN, es necesario dividir la tabla
en dos. Utilizamos la dependencia funcional que no se encuentra en 3FN (Ganador ->
Fecha_nacimiento).
Ganador_fecha_nacimiento
Ganador Fecha de nacimiento

Chip Masterson 14 de marzo de 1977
Al Fredrickson 21 de julio de 1975
Bob Albertson 28 de septiembre de 1968
Dfs:
Ganador -> Fecha_nacimiento
Ganadores_torneo
Torneo Año Ganador

Indiana Invitational 1998 Al Fredrickson
Cleveland Open 1999 Bob Albertson
Página 32 de 40
Des Moines Masters 1999 Al Fredrickson

Indiana Invitational 1999 Chip Masterson
Dfs:
Torneo, Año-> Ganador
La anomalía de actualización referenciada anteriormente (la misma persona con diferentes

fechas de nacimiento) no pueden ocurrir en estas tablas, están en 3FN.
Ejemplo: sean los atributos Num_matrícula, grupo asignado y aula del grupo, con los
siguientes condicionantes: un alumno sólo tiene asignado un grupo y a un grupo siempre le
corresponde un único aula.
Num_mat ---> grupo_asig | aula_grupo

grupo_asig ---> aula_grupo
El atributo aula_grupo es transitivamente dependiente de Num_mat, ya que se puede conocer

por medio de grupo_asig.
Del ej. anterior Num_mat --> Gru_asig --> aula.
Existe una dependencia transitiva del atributo aula.
Lo pasamos a 3FN:
ALUMNOS = P(tabla, Num_mat, gru_asig)
GRUPOS= P (tabla, gru_asig, aula)
Ejercicio:
En el ej. de facturas, supongamos que además tenemos en facturas los datos del cliente
al cual la emitimos siendo la tabla diseñada de la forma:
Num_factura, Fecha, Num_albaran, Cod_cliente,razón_social_cliente , Direccion_cliente
Pasarla a 3FN
Las DF serían:
Num_factura --> Cod_cliente -->razón_social | Dirección

Num_factura --> Num_albarán
Num_factura --> Fecha
FACTURAS= P(FACTURA, Num_factura, Cod_cliente, Num_albarán, Fecha)

CLIENTES = P(FACTURAS, Cod_cliente, Razón_social, Dirección)
Página 33 de 40
.FORMA NORMAL DE BOYCE-CODD (FNBC)

Tras la aplicación de la 3FN se observó que se encontraban algunas anomalías que no
eran abordadas. Son casos de tablas que, estando en 3FN, mantienen una dependencia de un
atributo secundario con parte de la clave, es decir, parte de la clave depende funcionalmente de
un atributo secundario.
Gráficamente sería de la siguiente forma:
T (A, B, C)
A | --> C|
B <--| -------|
Por ello, se pensó una definición más global que abordase estas anomalías. La nueva
definición se debe a Boyce y a Codd.
“ Una tabla T está en FNBC si y sólo si las únicas DF elementales son aquellas en las que la
clave principal ( y claves secundarias) determinan un atributo”
La definición engloba la 3FN puesto que las dependencias transitivas existen por medio de
atributos secundarios que no son clave.
Si la clave está formada por un único atributo y se encuentra en 3FN la tabla se encuentra en
FNBC.
Veamos como ejemplo la siguiente tabla en la que almacenamos los quesos típicos de cada
región y el país al que pertenece la región:
QUESOS (Queso, pais, región).
Cabrales,España, Asturias
Beyusco, España, Asturias
Livarot, Francia, Normandía
Grana, Italia, Parma
Encontramos las siguientes DF:
Queso.pais --> región
región --> país
Esta relación se encuentra en 3FN ya que ningún atributo secundario es conocido a través de
otro atributo secundario. Sin embargo no se encuentra en FNBC, ya que región (atributo
secundario), me permite conocer parte de la clave (país), lo que origina redundancias
perjudiciales.
La información en la tabla está fuertemente relacionada. Si mantenemos la dependencia región

--> país en la misma tabla resulta que existen muchas tuplas que se corresponden con el mismo
país, tanta como quesos haya en las regiones del país, lo que genera los problemas conocidos
de actualización (MIB), consultas, y mala gestión de la memoria.
Por otra parte, si eliminamos la tupla Grana, Italia,Parma, desaparece la relación entre Parma e
Italia. Por todo ello, la tabla no se encuentra optimizada.
El algoritmo de descomposición que se aplica a una tabla que no se encuentra en FNBC
es el siguiente:
1.- Sea la DF X --> Y donce X e Y son disjuntos, X es un atributo no primario e Y forma
parte de la clave.
2.- Se obtienen las proyecciones:
2.1- T1 = P (tabla, X,Y)
2.2- T2 = P (tabla, U - Y) siendo U todos los atributos que componen la tabla.
Por tanto, para que una tabla que está en 3FN y no cumple la FNBC se encuentre en FNBC, se
realizan las siguientes proyecciones:
Página 34 de 40
1.- Se crea una tabla con la parte de la clave que depende funcionalmente del atributo
secundario (país) y el atributo secundario (región). La clave será el atributo secundario.
REGIONES=P(QUESOS,región, país)
2.- Se crea otra tabla con la parte de la clave que es independiente (queso) y todos los atributos
no primarios. La clave de esta tabla será, generalmente, la concatenación de la parte de la
clave independiente y el atributo secundario que determina parte de la clave (región), aunque
se decide siempre en función de las DF existentes.
T2=P(QUESOS, queso, región) Serán clave ambos atributos si región no DF de queso,

es decir si dado un queso no puedo determinar una única región.
Así, a partir del atributo región se puede obtener la relación original.
Ej. CALLEJERO (Dirección, Ciudad, Cod_postal)

C/Pez, 2 Móstoles 28823
C/Luz, 5 Móstoles 28823
C/Pez, 2 Madrid 28007
C/Mar, 4 Madrid 28019
Con las siguientes DF:

Cod_postal --> Ciudad
Dirección.ciudad --> Cod_postal.
No se encuentra en FNBC, ya que existe a partir de una atributo secundario podemos conocer
parte de la clave. La convertimos a FNBC.
1.- CALLEJ_CIUDAD= P (CALLEJERO, cod_postal, ciudad)

2.- CALLEJ_DIRECC= P (CALLEJERO, Dirección, cod_postal)
.DEPENDENCIA MULTIVALUADA (DMV)
La DMV se utiliza para tratar la 4FN. Se define como: “Sean A, B y C tres

subconjuntos distintos de atributos de una tabla T, se dice que A tiene una DMV con B, que A
multidetermina a B o que B depende multivaluadamentes de A y se escribe como A--->-> B ó
A DMV B, si para cada valor de A existen un conjunto de valores de B asociados, y esta
asociación es independiente del resto de atributos C. (Es decir, que los valores de C no influyen
en esa asociación).
Como es necesario que en una DMV entre 2 atributos el resto de los campos sean
independientes, es necesaria la existencia de al menos 3 atributos para que se produzca una
dependencia multivaluada.
Por ej. sea la tabla PROF_ASI_TEX que representa a los profesores, asignaturas que imparten
y los textos de bibliografía de las asignaturas. Se parte de los condicionantes siguientes:
a) Un profesor imparte varias asignaturas y una asignatura puede ser impartida por varios
profesores.
Página 35 de 40
b) Una asignatura tiene varios textos y un texto se puede utilizar en varias asignaturas,
independientemente del profesor que imparta la asignatura.
PROF_ASI_TEX (Profesor, asignatura, texto) Al no existir DF entre los atributos la clave está
formada por la concatenación de los tres.
Existen por tanto las DMV siguientes:
Asignatura -->--> Profesor (independientemente del texto)

Asignatura -->-> Texto (independientemente del profesor)
pudiendo respresentarse como Asignatura -->-> Profesor | Texto.

Sin embargo, no existe Profesor -->-> texto, puesto que no es independiente de Asignatura.
.CUARTA FORMA NORMAL (4FN)
La 4FN se aplica para eliminar las DMV de las tablas, puesto que implican
redundancias perjudiciales de información, y por tanto problemas de actualización e integridad
de los datos.
La 4FN la enunció Fagin tras el terorema que demostró y que dice: “Una tabla T con atributos
A, B y C se puede descomponer sin pérdidas en 2 proyecciones T1(A, B) y T2(A, C) si y sólo
si la DMV A -->-> B | C se cumple en T”
Así, se dice que una tabla está en 4FN si cumple 2 condiciones:

1.- Está en FNBC
2.- Las únicas DMV existentes son las DF de la clave con los atributos secundarios.
Entre los atributos que forman la clave no puede existir más de una relación 1:N.
El algoritmo de descomposición de una tabla que no cumple la 4FN es el siguiente:
a) Sea una DMV X -->-> Y donde X e Y son disjuntos.

b) Se realizan 2 proyecciones.
b1) T1 = P(tabla, X,Y)
b2) T2 = P(tabla, U-Y) siendo U todos los atributos que componen la tabla.
Una tabla que no está en 4FN, se pasa a 4FN realizando, por tanto las siguientes proyecciones:
1.- En una tabla se mantiene una DMV
2.- En otra tabla se deja la otra DMV, de modo que los atributos que dependen
multivaluadamente quedan cada uno en una tabla.
Según el ej.
1.- ASI_PROF= P(PROF_ASI_TEX, asignatura,profesor)
2.- ASI_TEX= P(PROF_ASI_TEX, asignatura, texto).
Ej. Dada la tabla ESTUDIANTE (Num_expte, Asignatura, Deporte) que guarda la información
de las asignaturas que estudía el alumno y los deportes que practica, (siendo estos
independientes de la asignatura que curse).
Encontramos las DMV: Num_expte -->-> Asignaturas
Num_expte -->-> Deportes
Página 36 de 40
No se encuentra en 4FN. La transformamos:

1.- AL_ASIG= P(ESTUDIANTE, Num_expte, Asignatura)
2.- AL-DEP = P(ESTUDIANTE, Num_expte, Deporte)
.DEPENDENCIA DE JOIN (DJ)

La dependencia de join es una dependencia entre tablas. Hay casos en los que las tablas
que se encuentran en 4FN no están aún totalmente optimizadas, bien porque son pequeñas y
tienen mucha redundancia, al realizar determinadas operaciones de consultas frecuentes,o bien
por ser muy grandes con entidades diferentes relacionadas con una cardinalidad 1:1 y resultan
intratables en las transacciones que las manejan.
En esos casos conviene realizar proyecciones para que las tablas resultantes sean más
tratables.
La DJ indica que una tabla T formada por los atributos A1, A2,...,An tiene una DJ con
sus proyecciones T1, T2,...Tn, si la tabla T original se puede obtener por medio del join de sus
proyecciones T1*T2*.....*Tn.
Por ej. sea la Tabla T (A, B, C)
a1,b1,c1
a2,b1,c1
a1,b2,c1
a1,b1,c2
Podríamos manejar tablas más pequeñas, con menos columnas, eliminando la redundancia,
creando las siguientes proyecciones:
T1= P(T, A , B) T2=P(T,B,C) T3 = P(T, A, C)
a1,b1 b1,c1 a1,c1
a2,b1 b2,c1 a2,c1
a1,b2 b1,c2 a1,c2
de forma que al realizar el join por los campos comunes, resulta la tabla original
T(A, B, C)
a1, b1, c1
a1, b1, c2
a2, b1, c1
a1, b2, c1
Se puede decir entonces que la tabla T mantiene una DJ con sus proyecciones T1,T2 y T3 y se
escribe como:
T (A, B, C) DJ (T1 (A,B), T2(B, C), T3(A, C))
En una tabla que se pretende seguir descomponiendo no se trata de realizar

combinaciones de sus atributos en las diferentes proyecciones que se puedan generar, ni
tampoco probar a descomponer realizando el join con algunos valores, puesto que pueden no
aparecer tuplas intrusas inicialmente y en futuro aparecer. (En el ej. anterior eliminando la
tupla original a1,b1,c2 habría resultado que las 2 primeras proyecciones T1 y T2 serían
correctas cuando realmente no es así).
Página 37 de 40
La norma a seguir aparece en la definición de la 5FN.
.QUINTA FORMA NORMAL (5FN)

Para que una tabla se encuentre en 5FN se deben cumplir 2 condiciones:
1.- Se encuentra en 4FN
2.- Toda DJ viene implicada por las claves (principales o secundarias) de la tabla.
Es decir, una tabla estará en 5FN si es posible generar unas proyecciones, y al realizar
su join, los atributos comunes que realizan la operación (atributos de join) están formados por
claves (primaria o secundarias) de la tabla.
Si las posibles proyecciones de una tabla no pueden llevar implicadas las claves, entonces la
tabla no se encuentra en 5FN, y debe por tanto proyectarse para evitar los problemas de las
anomalías de actualización.
Por ej. Las operaciones que realizan en los cajeros diversos clientes.
CAJOPE= (Cajero,Operación, Cliente)
001, Ingreso, Cliente 1
001, Reintegro, Cliente 1
Se encuentra en 4FN.
La tabla original, CAJOPE, tendrá multitud de registros que son costosos de tratar cuando se
realizan diversas consultas sobre la misma tabla, por ej., para conocer qué operaciones se han
realizado en una cajero tendrá que tratar todas aquellas filas en las que los clientes han
realizado operaciones en ese cajero.
Evidentemente, si pasamos la tabla a 5FN, los datos se distribuirán en tres tablas,
complicándose el programa de alta o modificación, sin embargo, las consultas se distribuyen en
tablas diferentes y tratan única y exclusivamente las filas afectadas. Por ej., para conocer las
operaciones que ha realizado un cliente, no se repetiría para cada cajero. Además frente a una
transacción que se realiza de alta, cuando la aplicación ya está disponible, se ejecutan
generalmente cientos de consultas y éstas son las que hay que optimizar. Si no se desean
realizar accesos on-line para dichas consultas, no sería necesario pasarlo a 5FN proyectando la
tabla original, y se puede evaluar dejarla en 4FN.
Para pasarla a 5FN creamos proyecciones de las claves de manera que exista una DJ de las
proyecciones generadas con la tabla CAJOPE, resultando:
CAJOPE(Cajero, Operación, Cliente) DJ (T1(Cajero, Operación), T2(Cajero, Cliente),
T3(Operación, Cliente))
La 5FN también se aplica a tablas muy grandes que son intratables desde transacciones
y que mantiene varias entidades, todas relacionadas entre sí de la forma 1:1. Estas tablas están
en 5FN, pero se aplica la DJ para proyectarlas. Las proyecciones que se pueden formar deben
tener como atributo de join una clave de la tabla (primaria o secundaria), para que cunado se
realice la operación de join siempre se cumpla que una tupla se relaciona con una única tupla
de otra proyección.
Página 38 de 40
Por ej. datos de los empleados de una empresa: EMPLEADOS
Cod_trabajador, nif, nombre, dirección,...,nº S/S, fecha alta en S.S.,..,Categoría,puesto..
Esta tabla se encuentra en 5FN, pero para optimizar el diseño, nos interesa crear varias
proyecciones de manera que se maneje por cada fila un número menor de atributos, sólo los
necesarios.
EMPLEADOS(Cod_trabajador,...,puesto....)
DJ ((DATOS_PERSONALES(Cod_trabajador, nombre, dirección,..),
DATOS_SS(Cod_trabajador, nºSS, fecha,...),
DATOS_LABORALES(Cod_trabajador, categoría, puesto,...)).
Se realizarían por tanto 3 proyecciones. El atributo de join será el Cod_trabajador, clave
primaria de la original.
.Campos Redundantes
Por último hay que tener en cuenta los inconvenientes de la existencia de campos
redundantes, es decir, aquellos campos cuyo resultado se basa en los cálculos efectuados con
otros atributos o cuya información puede obtenerse a partir de los atributos existentes, ya que
conlleva los problemas de actualización (MIB) derivados de la redundancia de información.
Por ej. ARTICULOS (Cod_artículo,....,Precio Unitario, Unidades en almacen, ,Total
pesetas en almacen de ese artículo, total acumulado de ventas de ese artículo)
En esta tabla encontramos un campo calculado: Total pesetas en almacen que se obtiene de la
operación: Precio_unitario*Unidades en almacen. Este campo deberá ser actualizado cada vez
que modifiquemos cualquiera de los campos que intervienen.
Igualmente ocurre con el total acumulado de ventas, que se obtiene a partir de las ventas
realizadas reflejadas en las facturas. Estamos guardando información redundante, y mantener la
integridad de los datos conlleva operaciones extras, cuando esta información podría obtenerse a
partir de los atributos existentes. En este caso, estamos hablando de una redundancia
perjudicial, ya que es más costoso, mantener esos campos que recalcularlos.
Sin embargo, y depediendo de la explotación que se vaya a realizar de la información y

del número de datos que manejemos, pueden existir casos en los que la redundancia esté
justificada. Por ej. CLIENTE( Cod_cliente,..,total compras)
Si se van a realizar consultas frecuentes sobre el importe total de compras de los clientes, y el
número de facturas con el que trabajamos es grande, se puede justificar así, la existencia de
este campo redundante, a pesar de las operaciones extra que hemos de realizar en procesos de
MIB para mantenerlo actualizado.
Por tanto, antes de introducir un campo redundante, hemos de sopesar las ventajas e
inconvenientes, para un sistema de información concreto, y en caso de introducirlo, hemos de
justificarlo por escrito, indicando siempre a qué operaciones de qué tablas afecta.
Página 39 de 40
.RESUMEN Normalización
* 1FN => No existen conjuntos repetitivos en una tupla.
Proyección: a) Una tabla con la clave y los atributos con valores únicos.
b) Una tabla con la clave y los atributos con valores múltiples, cada uno en una
fila. La clave, suele ser la concatenación de ambos.
* 2FN => 1.- Se encuentra en 1FN.

2.- Todos los atributos secundarios tienen una dependencia funcional total de la
clave.
Proyección: a) Una tabla con la clave completa y los atributos que tienen una dependencia
total de ella. La clave será la antigua.
b) Una tabla con la parte de la clave que tiene dependencias y los atributos que
dependen de ella. La clave será la parte de la clave antigua que tiene dependencias.
* 3FN => 1.- Se encuentra en 2FN.

2.- Todo atributo secundario se conoce a través de la clave principal o claves
secundarias. Un atributo secundario no debe conocerse por medio de otro atributo secundario.
Proyección: a) Una tabla con la clave y los atributos no primarios que sólo se conocen por
medio de la clave primaria o secundarias.
b) Una tabla con los atributos que dependen del secundario, y el atributo
secundario del cual dependen. Este último será la clave.
* FNBC => 1.- Se encuentra en 3FN.

2.- A partir de un atributo no primario no debe conocerse parte de la clave.
(Las únicas DF elementales son aquellas en las que la clave ppa. o secundarias determinan un
atributo. Esto incluye a la 3FN).
Proyección: a) Una tabla con la parte de la clave que depende funcionalmente del atributo
secundario y el atributo secundario. La clave será este último.
b) Una tabla con la parte de la clave independiente y los atributos no primarios. La
clave será generalmente la parte de la clave antigua y el atributo del cual depende.
* 4FN => 1.- Se encuentra en FNBC.

2.- Las únicas DMV existentes son las DF de la clave con los atributos secundarios.
Proyección: a) En una tabla se mantiene una DMV.
b) En otra tabla otra DMV.
*5FN => 1.- Está en 4FN.

2.- Toda DJ viene implicada por las claves (principal o secundarias).
Proyecciones: Una vez evaluada la conveniencia, se realizan proyecciones que lleben ímplicita
la clave.
Campos Calculados: Es necesario realizar un estudio exhaustivo para determinar o no su

existencia.
Página 40 de 40

Tema3DisegnoLogico

Cargado por

Copyright:

Formatos disponibles

Tema3DisegnoLogico

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tema3DisegnoLogico

Cargado por

Copyright:

Formatos disponibles

Tema 3. Diseño lógico. El modelo Relacional. SGBD DAW1B.

Curso 2024/20245 IES Albarregas

TEMA 3. EL MODELO RELACIONAL.

1. ESTRUCTURA RELACIONAL DE LOS DATOS.

Filas Columna Columna Columna

.Transformación del MER al modelo relacional.

a) Las entidades, cuando se traducen al modelo relacional, originan tablas.

- Las relaciones binarias 1:1 y 1:N dan lugar a claves ajenas.

El concepto relación se utiliza generalmente para indicar que en la tabla relacional se

Ejemplo: tabla relacional "FRUTAS".

Pueden distinguirse dos tipos de dominio:

Ej. DNI: Números enteros positivos de 8 dígitos

- Dominios restringidos o discretos: Contiene ciertos valores entre unos determinados.

Personal: dni,nombre,dirección,ciudad,c.p.,fecha nacimiento,..

2. REDUCCION DEL DIAGRAMA ENTIDAD-RELACION AL MODELO

Los atributos se transformarán en columnas. En cada tabla identificaremos el atributo o

CODVEN NOMVEN TELVEN CODZON NOMZON

Hay dos posibilidades:

CODVEN NOMVEN TELVEN CODZON NOMZON

Hay dos posibles soluciones:

* Cardinalidad N:M y la dimensión de la relación no es binaria

Para representarlo en el modelo relacional, necesitaríamos cuatro tablas:

VENDEDORES => CODVEN, NOMVEN, TELVEN

VENDxZONASxMATER. => CODVEN, CODZON, CODMAT Fecha_inicial Fecha_final

VENDxZONASxMATER.=>CODMAT CODZON CODVEN Fecha_inicial Fecha_final

VENDxZONASxMATER.=>CODMAT CODZON CODVEN Fecha_inicial Fecha_final

Cuando la conectividad de la interrelación es 1:1:1, la relación que se obtiene de su

Por tanto hay tres claves candidatas para la relación.

VENDEDORES => CODVEN, NOMVEN, TELVEN

Transformación de relaciones n-arias

- Transformación de relaciones recursivas (reflexivas).

- Cardinalidad 1:1. Obtener el modelo relacional del siguiente diagrama ER

Ejemplo, recogida de información de los matrimonios celebrados en una parroquia.

PERSONA : (dni, nombre,fecha, dni_pareja)

- Cardinalidad N:N. Obtener el modelo relacional del siguiente diagrama ER

Ejemplo, INE recoge la información de los matrimonios en el estado español.

PERSONA (DNI, nombre)

BODA (DNI_p1, DNI_p2, fecha)

PIENSA: Crees que se podría optimizar la clave?

- Cardinalidad C:N Obtener el modelo relacional del siguiente diagrama ER

Ejemplo, información del departamento. El departamento depende de otro departamento de

DEPARTAMENTO : (cod_dpto, nombre, coddptodepende)

La cardinalidad M:1 tendría el mismo paso.

- Transformación de entidades débiles

Ejemplo de transformación de entidad débil

a) La entidad superclase nos permite modelizar las características comunes de la

En la figura siguiente están representadas la entidad superclase, el empleado, y las entidades

En la generalización/especialización, las características (atributos o relaciones) de la entidad

a) La tabla de la entidad superclase tiene como clave primaria la clave de la entidad

Ejemplo de transformación de la generalización/especialización

El ejemplo anterior contiene una generalización/especialización y, también, una relación M:N

EMPLEADO(DNI, nombre, apellido, dirección, teléfono)

TRABAJA(DNI, pro, superficie)

RESTRICCIONES DEL MODELO RELACIONAL

El modelo relacional tiene una serie de restricciones, es decir estructuras u ocurrencias no

- inherentes al modelo que son las restricciones de integridad

Las restricciones inherentes al modelo son:

- Operación con puesta a valor por defecto (SET DEFAULT) : El borrado o

3. CODD Y LAS BASES DE DATOS RELACIONALES.

4.- Catálogo en línea dinámico basado en el modelo relacional: La descripción de la base de