Presentación Tema 8

Tema 9:

Diseño
Modelo Relacional
lógico de datos.
– Presentación y objetivos
– Elementos del modelo relacional
– Claves
– Restricciones
– Álgebra relacional
 Pasos en el Diseño de
 Transformación
datos del esquema conceptual al
–esquema
Transformación
lógico de interrelaciones N:M
– Transformación de interrelaciones 1:N
– Transformación de interrelaciones 1:1
– Transformación n-arias
– Transformación de dependencia en existencia e
– Interrelaciones
Transformación
identificación
– Generalizaciones
Transformación
exclusivas
 Normalización del esquema lógico de datos
– Introducción
– Noción intuitiva de las formas normales
– Dependencias funcionales. Teoría de la normalización
– Definición de dependencia funcional
– Dependencia funcional completa y
– Dependencia
2FN funcional transitiva y
3FN
Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)
MODELO RELACIONAL. PRESENTACIÓN Y
OBJETIVOS
 Presentación y objetivos.
Codd propone, a finales de los años sesenta, un modelo de datos basado en
la teoría de las relaciones, en donde los datos se estructuran en forma de
relaciones (tablas).
El trabajo publicado por Codd presentaba un nuevo modelo de datos que
perseguía una serie de objetivos, que se pueden resumir en los siguientes:
– Independencia Física: es decir, que el modo en el que se almacenan los
datos no influya en su manipulación lógica y, por tanto, los usuarios que
accedan a esos datos no tengan que modificar sus programas por cambios
en el almacenamiento físico.
– Independencia Lógica: esto es, que el añadir, eliminar o modificar
objetos de la base de datos no repercuta en los programas y/o usuarios que
están accediendo a subconjuntos parciales de los mismos (vistas).
– Flexibilidad: en el sentido de poder presentar a cada usuario los datos de
la forma en que éste prefiera.
– Sencillez: las características anteriores, así como unos lenguajes de
usuario muy sencillos, producen como resultado que el modelo de datos
relacional sea fácil de comprender y de utilizar por parte del usuario final.

MODELO RELACIONAL. PRESENATICÓN Y
OBJETIVOS
 Presentación y objetivos
Para conseguir los objetivos citados, Codd
introduce el concepto de relación (tabla) como
estructura básica del modelo.
En este tema, una vez que estudiemos el modelo

relacional, lo que haremos será convertir el modelo
entidad interrelación creado en la fase de análisis
en una serie de tablas (o relaciones) con una serie
de reglas.

MODELO RELACIONAL. ELEMENTOS
 Tablas o relación:
Conjunto de campos, cada uno con su propio dominio, para
describir un conjunto de entidades del mismo tipo.
Ejemplo: Tabla persona
N o mA bp r e eD l l i i dr e o T c s e c l i e o f n o n o

 Tupla o fila:
Conjuntos de valores que dentro de una tabla sirven para describir una
ocurrencia de la entidad que describimos mediante la tabla.
Ej: Fila de la tabla persona.
J u a nP e r Ce z\ S 9 e 5 v 5 i l6 l a 6 7 7 8

 Tupla o fila:

MODELO RELACIONAL. CLAVES
 Claves:
– Clave candidata: Conjunto no vacío de atributos que
identifican unívoca y mínimamente cada tupla (o fila).
Siempre debe existir, al menos, una clave candidata ya que no
pueden existir en una tabla dos tuplas iguales. Si no se
cumpliese este requisito deberíamos eliminar aquellos atributos
que lo impidiesen. Una relación puede tener más de una clave
candidata, entre las cuales se debe distinguir:
 Clave primaria: es aquella clave candidata que el usuario
escogerá, por consideraciones ajenas al modelo relacional, para
identificar las tuplas de la relación.
 Clave alternativa: son aquellas claves candidata que no han sido
escogidas como clave primaria.
– Clave ajena: Se denomina clave ajena de una relación R2 a un
conjunto no vacío de atributos cuyos valores han de coincidir con
los valores de la clave primaria de una relación R1. Cabe
destacar que la clave ajena y la correspondiente clave primaria
han de estar definidas sobre los mismos dominios.

MODELO RELACIONAL. CLAVES
 Claves:
Veamos un ejemplo de clave ajena:
Nombre Apellidos DNI Cod_departamento
Juan Pérez 28689555B 1
Pedro Jiménez 54789321C 1
José Sánchez 87456321S 2
Nombre Cod_departamento
Ciencias 1
Historia 2

MODELO RELACIONAL. RESTRICCIONES
 Restricciones:
– Las tablas sólo contienen un tipo de filas.
– Todas las filas tienen el mismo número de campos o
columnas.
– Cada campo o columna tiene un nombre único.
– En cada fila, cada campo tiene un único valor.
– Ese valor debe estar dentro del domino del campo de dicha
fila o columna.
– No hay dos tuplas iguales.
– El orden de las tuplas no es significativo.
– El orden de los atributos (columnas) no es significativo.
– Cada atributo sólo puede tomar un único valor del dominio.
– Ningún atributo que forme parte de la clave primaria de una
relación puede tomar un valor nulo.

MODELO RELACIONAL. ÁLGEBRA
RELACIONAL
 Álgebra Relacional:
Es el lenguaje de consulta del modelo relacional. Nos va a permitir
obtener información de las tablas que definen nuestro modelo
relacional mediante una serie de operadores que dadas una o varias
tablas nos dan como resultado una nueva tabla.

MODELO RELACIONAL. ÁLGEBRA
RELACIONAL
 Álgebra Relacional:
Las operaciones son las siguientes:
– Operadores primitivos
A. Unarios: Trabajan con una única tabla.
1. Selección (σ)
2. Proyección (π)
B. Binarias: Trabajan con dos tablas
1. Unión (U)
2. Diferencia (-)
3. Producto cartesiano (x)
– Operadores derivados: Obtenidas por composición de varias
operaciones de las citadas anteriormente
A. Combinación (θ)
B. Intersección (∩)

MODELO RELACIONAL. AR. SELECCIÓN (σ)
 Álgebra Relacional. Selección (σ
( ):
La selección, también llamada restricción, de una relación
mediante una condición, da como resultado una relación formada
por el subconjunto de tuplas que satisface la expresión.
EMPLEADOS
σ
José Sánchez
apellidos=“Pérez ”
87456321S 2
(EMPLEADO
Julián Pérez S) 45215632L
Nombre 1
Apellidos DNI Cod_departamento
Julián Pérez 45215632L 1

MODELO RELACIONAL. AR. PROYECCIÓN
(π)
 Álgebra Relacional. Proyección (π
( ):
La proyección de una relación sobre un subconjunto de sus
atributos es una relación definida sobre ellos; es, por tanto, un
subconjunto vertical de la relación a la que se aplica el operador.
EMPLEADOS
π
José Sánchez
nombre,apellidos
87456321S 2
(EMPLEADOS) Nombre Apellidos
Julián Pérez 45215632L 1
Juan Pérez
Pedro Jiménez
José Sánchez
Julián Pérez
MODELO RELACIONAL. AR. UNIÓN (U)
 Álgebra Relacional. Unión (U
( ):
La unión de dos relaciones compatibles (los campos están definidos sobre el
mismo dominio) en su esquema es otra relación definida sobre el mismo
esquema de relación, cuya extensión estará constituida por las tuplas que
pertenezcan a r o r´ o a ambas (se eliminarán las tuplas duplicadas puesto que
se trata de una relación).

MODELO RELACIONAL. AR. DIFERENCIA (-)
 Álgebra Relacional. Diferencia (-):
La diferencia de dos relaciones compatibles (los campos están definidos
sobre el mismo dominio) en su esquema es otra relación definida sobre el
mismo esquema de relación, cuya extensión estará constituida por las
tuplas que pertenezcan a r pero no a r´.
No es lo mismo hacer r-r´ que r´-r. El resultado será una relación diferente.

MODELO RELACIONAL.AR.PRODUCTO
CARTESIANO(X)
 Álgebra Relacional. Producto cartesiano (x):
El producto cartesiano de dos relaciones de cardinalidades m y m´es una
relación cuyo esquema estará definido sobre la unión de los atributos de
ambas relaciones, y cuya extensión estará constituida por las m x m´tuplas
formadas concatenando cada tupla de la primera relación con cada una de
las tuplas de la segunda.
Nº columnas= Suma de las columnas de las dos tablas.
Nº Filas = El producto de las filas de T1 por las filas de T2.

MODELO RELACIONAL. AR. COMBINACIÓN
(θ )
 Álgebra Relacional. Combinación (θ):
EMP DPTO
Nombre Apellidos DNI Cod Nombre Cod
Ciencias 1
Historia 2
José Sánchez 87456321S 2
Julián
EMP =Π
θ DPTOPérez 45215632L 1
EMP.nombre,apellidos,dni,DPTO.cod,DPTO.nombre (σEMP.cod=DPTO.cod (EMP X
)
DPTO)Nombre Apellidos DNI Cod Nombre dpto
Juan Pérez 28689555B 1 Ciencias
Pedro Jiménez 54789321C 1 Ciencias
José Sánchez 87456321S 2 Historia
Juliánde aplicaciones
Anális y diseño Pérez informáticas
45215632L 1(TEMA 9)Ciencias
de gestión
MODELO RELACIONAL. AR. COMBINACIÓN
(θ )
 Álgebra Relacional. Combinación (θ):

MODELO RELACIONAL. AR. INTERSECCIÓN
( ∩)
 Álgebra Relacional. Intersección (∩):
La intersección de dos relaciones compatibles (los campos están
definidos sobre el mismo dominio) en su esquema es otra relación
definida sobre el mismo esquema de relación, cuya extensión estará
constituida por las tuplas que pertenezcan a ambas relaciones.

PASOS EN EL DISEÑO DE DATOS
ERS Análisis (Qué)

Lenguaje comprensible
por el usuario
E-R DFD
Diseño de alto nivel Enfoque Organización
(arquitectónico)
Enfoque de lógica
funcional
datos
Arquitectura de procesos
Modelo lógico de datos
(Diseño Modular)
Diseño (Cómo)
Descripción de los
Modelo físico de datos módulos
(Diseño procedimental)
Diseño de bajo nivel Decisiones
(detallado) concretas:
Esquema de BD Cuadernos de organización y
y ficheros carga rendimiento
Implementación
Codificación y Lenguaje comprensible por la
máquina
pruebas

PASOS EN EL DISEÑO DE DATOS
ERS
1. Transformación del
esquema conceptual al
E-R esquema lógico
Diseño de alto nivel
(arquitectónico)
Enfoque de
datos MA9 2. Normalización del esquema lógico
TE
Modelo lógico de datos
Modelo físico de datos TEMA 11

Diseño de bajo nivel
(detallado)
Esquema de BD
y ficheros

TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL
 Transformación del esquema conceptual
El paso de un esquema en el modelo E/R al relacional está
basado en los tres principios siguientes:
– Todo tipo de entidad se convierte en una relación.
– Todo tipo de interrelación N:M se transforma en una relación.
– Todo tipo de interrelación 1:N se traduce en el fenómeno de
propagación de clave o se crea una nueva relación.
Modelo E/R
Entidades, atributos,
relaciones
Modelo lógico
Tablas

 Transformación de interrelaciones
– Interrelaciones N:M : Se transforma en una relación (tabla)
que tendrá como clave primaria la concatenación de las
claves primarias de las entidades involucradas. El resto de
atributos serán los que pueda tener la interrelación.
Además, cada uno de los atributos que forman la
clave primaria de esta relación son clave ajena
respecto a cada una de las tablas donde este
atributo es
a1
clave primaria.
r1 r2
b1
a2 A B b2
(1,M) (1,N)
a3 (M,N) b3
A1 A2 A3 B1 B2 B3
A1 B1 R1 R2

– Interrelaciones N:M : Un ejemplo.

– Interrelaciones 1:N : Se propaga la clave primaria del tipo de
entidad que tiene la cardinalidad máxima 1 a la que tiene N,
es decir, en el sentido de la flecha.
Además, los atributos que forman la clave primaria
que se propagan son clave ajena respecto a la
tabla donde este atributo es clave primaria.
Además, si la relación tiene atributos, se propagan
en el mismo sentido.
r1 r2
a1 b1
a2 A B b2
(1,1) (1,N)
a3 (1,N) b3
A1 A2 A3 B1 B2 B3 A1 R1 R2

– Interrelaciones 1:N : Ejemplo
Como vemos en la figura, al ser la cardinalidad de EDITORIAL

(1,1), no pueden admitirse valores nulos en la clave ajena
pero se han de admitir, en cambio, valores nulos si la
cardinalidad es (0,1). A esto lo llamaremos una RESTRICCIÓN.

– Interrelaciones 1:N : Las interrelaciones 1:N también pueden
transformarse como si se tratará de una interrelación N:M. Esta
opción suele ser mejor cuando la interrelación tiene atributos.
En este caso mejor

– Interrelaciones 1:1: no hay regla fija para la transformación de este tipo de
interrelación. Por tanto podríamos crear una relación o propagar la clave. En
este segundo caso la propagación de la clave puede efectuarse en ambas
direcciones.
Los criterios para aplicar una transformación u otra y para
propagar la clave se basan en las cardinalidades mínimas:
 Si las entidades que se asocian poseen cardinalidades (0,1), entonces la
interrelación 1:1 se transformará en una relación.
r1 r2
a1 b1
a2 A B b2
(0,1) (0,1)
a3 (1,1) b3
A1 A2 A3 B1 B2 B3
A1 B1 R1 R2

– Interrelaciones 1:1: Ejemplo transformación en una relación.
Cod_mujer debe ser

clave alternativa

– Interrelaciones 1:1:
 Si una de las entidades que participa en la interrelación posee
cardinalidades (0,1), mientras que en la otra es (1,1) entonces
conviene propagar la clave de la entidad con cardinalidad (1,1) a
la tabla resultante de la entidad con cardinalidad (0,1).
r1 r2
a1 b1
a2 A B b2
(1,1) (0,1)
a3 (1,1) b3
A1 A2 A3 B1 B2 B3 A1 R1 R2

– Interrelaciones 1:1: Ejemplo propagación.

– Interrelaciones 1:1:
 En el caso de que ambas entidades presenten cardinalidades
(1,1), 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.

– Interrelaciones n-arias : Si las cardinalidades máximas de
todas las entidades es N, entonces se crea una tabla por cada
entidad y se creará otra donde la clave será la agregación de
las claves de todas las tablas.
En el ejemplo de abajo la interrelación es N:N:N
r1 r2
a1 b1
a2 A B b2
a3 B1 B2 B3
b3
C
A1 A2 A3
C1 C2 C3
A1 B1 C1 R1 R2

– Interrelaciones n-arias : Si las cardinalidades máximas de
todas las entidades es N, entonces se crea una tabla por cada
entidad y se creará otra donde la clave será la agregación de
las claves de todas las tablas.
En el ejemplo de abajo la interrelación es N:N:N
r1 r2
a1 b1
a2 A B b2
a3 B1 B2 B3
b3
C
A1 A2 A3
C1 C2 C3
A1 B1 C1 R1 R2

– Interrelaciones n-arias : Si las cardinalidades máximas de alguna
entidad es 1, entonces se crea una tabla por cada entidad y se
creará otra donde la clave será la agregación de las claves de las
entidades donde la cardinalidad máxima es N.
PROVEEDOR 1:N:M PROYECTO
(0,1) suministrar
Es suministrado por Suministra para (0,M)
suministra
(0,N)
PIEZA
Clave ajena
Proveedor (cod_proveedor, …)
Proyecto (cod_proyecto, …)
Pieza (cod_pieza, …)
Suministrar (cod_pieza, cod_proyecto, cod_proveedor, …)

– Interrelaciones n-arias : Si todas las cardinalidades máximas
de las entidades es 1, excepto 1, entonces se crea una tabla
por cada entidad y la tabla que corresponde a la cardinalidad
máxima N tendrá claves ajenas a las demás.
PROVEEDOR 1:1:M PROYECTO
(0,1) suministrar
Es suministrado por Suministra para (0,1)
suministra
(0,N)
PIEZA
Proveedor (cod_proveedor, …) Claves ajenas

Proyecto (cod_proyecto, …)
Pieza (cod_pieza, cod_proveedor, cod_proyecto …)

– Dependencias en existencia e identificación: La manera de
transformar una interrelación de este tipo es utilizar el
mecanismo de propagación de clave, creando una clave
ajena, con nulos no permitidos, en la entidad dependiente.
También deberemos obligar a una modificación y y un
borrado en cascada.
Además, en el caso de dependencia en
identificación la clave primaria de la relación de la
entidad débil debe estar formada por la
concatenación de las claves de las dos entidades
participantes en la interrelación.

– Interrelaciones exclusivas: La manera de transformar una
interrelación de este tipo es utilizar el mecanismo de
propagación de clave, creando dos claves ajenas. Para obligar
a dicha exclusividad necesitamos una restricción. (La forma
de poner las restricciones en SQL lo veremos en el tema 11).
BECA (cod_beca, ….)
PROYECTO (cod_proyecto, …)
PROFESOR (nif, cod_beca, cod_proyecto, …)
Restricción: Una de las dos claves ajenas es nula y
la otra no. (0,1)
percibe BECA
(0,N)
N:1
PROFESOR
(1,N)
contratado PROYECTO
(0,N)
N:M
– Tipos y subtipos: Los tipos y subtipos no son objetos que se
puedan representar explícitamente en el modelo relacional.
Ante una entidad y sus subtipos caben varias soluciones de
transformación en el modelo relacional, con la consiguiente
pérdida de semántica dependiendo de la estrategia elegida.
Destacamos tres principalmente:

– Tipos y subtipos:
 Opción a: englobar todos los atributos de la entidad y sus subtipos en una sola relación,
añadiendo un atributo adicional que indique el tipo (el discriminante de la jerarquía). Este
discriminante podrá tener valores nulos si la jerarquía es parcial y todo lo contrario si la
jerarquía es total.
En general, adoptaremos esta solución cuando los subtipos se
diferencian en muy pocos atributos y las interrelaciones que se
asocian con el resto de entidades sean las mismas para todos los
subtipos.
No utilizar nunca en PARCIAL CON SOLAPAMIENTO

Si total CON SOLAPAMIENTO, entonces el
discriminante formará parte de la clave.
Es posible que haya que incluir restricciones
semánticas. Por ejemplo: Si el tipo de
documento es ARTICULO, entonces el año de
edición y el código de editorial deben ser
nulos.
 Opción b: crear una relación para el supertipo y tantas relaciones como subtipos haya,
con sus atributos correspondientes.
En general, adoptaremos esta solución cuando existen muchos
atributos distintos entre los subtipos y se quieren mantener de
todas maneras los atributos comunes a todos ellos en una relación.
Es posible que haya que incluir

restricciones semánticas.

 Opción c: Considerar relaciones distintas para cada subtipo, que contengan
además los atributos comunes.
En general, adoptaremos esta solución cuando existen
muchos atributos distintos entre los subtipos, pocos
atributos comunes en el supertipo y existan pocas
relaciones en las que participe el supertipo.
Esta opción sólo nos la podemos plantear si la

generalización es total y sin solapamiento.
Es posible que haya que incluir restricciones

semánticas. Por ejemplo: Si el tipo de
documento es ARTICULO, entonces el año de
edición y el código de editorial deben ser
nulos.
– Tipos y subtipos: Podemos, por tanto, elegir entre tres estrategias
distintas para la transformación de un tipo y sus subtipos al modelo
relacional. Sin embargo, desde un punto de vista exclusivamente
semántico la opción b es la mejor. Por otra parte, desde el punto de
vista de la eficiencia tenemos que tener en cuenta que:
 Opción a: El acceso a una fila que refleje toda la información de una
determinada entidad es mucho más rápido (no hace falta combinar varias
relaciones).
 Opción b: La menos eficiente, aunque es la mejor desde el punto de vista
exclusivamente semántico.
 Opción c: Con esta solución aumentamos la eficiencia ante determinadas
consultas (por ejemplo, las que afecten a todos los atributos de un
subtipo) pero la disminuimos ante otras (como las que conciernen a los
atributos comunes de los distintos subtipos) e introducimos redundancias.
Esta solución es en la que se pierde más semántica.
Elegiremos una estrategia u otra dependiendo de que sea la
semántica o la eficiencia la que imprime para el usuario en un
momento determinado.

 NOTACIÓN DEL DISEÑO LÓGICO DE DATOS
Para cada relación obtenida creamos lo siguiente:
NOMBRE_RELACIÓN (atrib1, atrib2, atrib3, …, atribn)
PK( atributos que forman la clave principal )
AK1 (atributos de una clave alternativa)
AK2 (……)
Akn(…….)  Uno por cada clave alternativa
FK1 (atributos de una clave ajena)/Entidad a la que referencia
FK2 (…..)/Entidad
FKn (…..)/Entidad  Uno por cada clave ajena
Restricciones:
atributo NOT NULL
Cualquier otra restricción expresada en lenguaje natural
* Comentarios*

NORMALIZACIÓN DEL ESQUEMA LÓGICO DE
DATOS
 Introducción
Cuando se diseña una B.D. mediante el modelo relacional, tenemos distintas
alternativas, es decir, podemos obtener diferentes esquemas relacionales, y no
todos ellos son equivalentes, ya que unos van a representar la realidad mejor que
otros.
Las relaciones que resultan de la transformación del esquema E/R pueden
presentar algunos problemas, derivados de fallos en la percepción del universo de
discurso, en el diseño del esquema E/R o en el paso al modelo relacional.
En definitiva, el esquema relacional debe ser analiazado para comprobar que no
presenta los problemas anteriormente citados, evitando la pérdida de información
y la aparición de estados que no son válidos en el mundo real.
Ante las posibles dudas respecto a si un determinado esquema relacional es
correcto, es mejor aplicar a dicho esquema un método formal de análisis que
determine lo que pueda estar equivocado en el mismo y nos permita deducir otro
que nos asegure el cumplimiento de ciertos requisitos; este método formal es la
teoría de la normalización.

DATOS
 Introducción
Se ha de comentar que la anomalias a las que da
lugar un diseño inadecuado de una B.D se
producen sólo en procesos de actualización y nunca
en los de consulta. La aplicación de la teoría de la
normalización consigue una disminución de dichas
anomalías, evitando muchos de los problemas
que se pueden plantear en las
actualizaciones.

DATOS
 Noción intuitiva de las formas normales
La teoría de la normalización consiste en obtener
esquemas relacionales que cumplan unas
determinadas condiciones, y se centra en lo que se
conoce como formas normales. Se dice que un
esquema lógico de datos está en una determinada
forma normal si satisface determinado conjunto
específico de restricciones.
Todas las relaciones que están en la 5FN
también están en 4FN, y así sucesivamente; sin
embargo, existen relaciones que estando en
1FN no están en 2FN, ni estando en 2FN están
en 3FN, etc. A fin de evitar las anomalías que
describíamos anteriormente es preferible la
2FN a la 1FN, la 3FN es mejor que la 2FN, etc.

DATOS
– 1FN: Un atributo no puede tomar más de un valor.
La segunda (2FN) y la tercera (3FN) formas normales se formulan teniendo

en cuenta la relación entre los campos claves y los que no forman parte de
ninguna clave.
– 2FN: Si además de estar en 1FN, todos los campos que no formen parte de
ninguna clave candidata suministran información acerca de la clave
completa. Ejemplo:
VENTAS(Cod_pieza, cod_almacén, cantidad, dirección_almacén)
PK(Cod_pieza, cod_almacén)
La dirección del almacén es un campo que da información sobre el código
del almacén pero no de la clave completa por lo que esta relación viola la
2FN. Para evitarlo podríamos descomponer la relación en:
NUMERO_VENTAS( Cod_pieza, cod_almacén, cantidad)
ALMACENES( Cod_almacén, dirección_almacén)

DATOS
– 3FN: Además de estar en la 1FN y en la 2FN, los campos que no
forman parte de la clave candidata deben facilitar información sólo
acerca de la(s) clave(s) candidatas, y no acerca de otros campos.
Ejemplo:
EMPLEADOS( cod_empleado, cod_departamento,
nombre_departamento)
PK(cod_empleado)
Esta relación no está en 3FN ya que el nombre del departamento es
un hecho acerca del código del departamento además de serlo,
transitivamente, del código de empleado.
Para conseguir la 3FN sería conveniente descomponerlo de la
siguiente manera:
EMPLEADOS( cod_empleado, nombre_departamento)
DEPARTAMENTO( cod_departamento, nombre_departamento)

DATOS
– Forma normal de Boyce-Codd (FNBC): Una relación está en FNBC si,
y solo si, las claves candidatas son los únicos descriptores sobre los
que se facilita información por cualquier otro atributo. Ejemplo:
PRESTAMOS (num_socio, nombre_socio, cod_libro, fecha_prestamo)
PK(num_socio, cod_libro)
AK(nombre_socio, cod_libro)
Aunque está en 3FN no está en FNBC porque el número de socio es
una información acerca del nombre de socio y viceversa; sin
embargo, ninguno de estos dos atributos son clave (aunque formen
parte de la clave). Para solucionarlo:
PRESTAMOS (num_socio, cod_libro, fecha_prestamo)
SOCIOS (num_socio, nombre_socio)

DATOS
 Dependencias funcionales.Teoría de la
normalización
Ya hemos visto la noción intuitiva de las formas
normales pero no podemos normalizar un esquema
lógico de datos de manera intuitiva.
La normalización a nivel teórico se basa en el
concepto de dependencia funcional. Existen
muchos tipos de dependencias (funcionales,
multivaluadas, de combinación, etc.), pero nosotros
sólo trataremos las dependencias funcionales, ya
que son las que se encuentran asociadas a las tres
primeras formas normales.

DATOS
normalización
– Definición de dependencia funcional:
Decimos que un descriptor Y (conjunto de campos)
depende funcionalmente del descriptor X o que X
determina o implica a Y, si, y solo si, cada valor de X
tiene asociado en todo momento un único valor de Y. Lo
que se representa como: X  Y.
Así, por ejemplo, podemos decir que:
COD_ALMACEN  DIRECCION_ALMACEN
Ya que cada código de almacén existe una sola dirección
o que el código del almacén determina su dirección. En
esta dependencia al COD_ALMACÉN (X) lo
denominaremos Implicante y a DIRECCIÓN_ALMACÉN (Y)
Implicado.
DATOS
 Dependencias funcionales.Teoría de la normalización
– Dependencia funcional completa y 2FN:
Si el descriptor X es compuesto: (X1, X2), se dice que Y tiene
dependencia funcional completa o plena respecto de X, si depende
funcionalmente de X, pero no depende de ningún subconjunto del
mismo, esto es: X  Y, pero X1 -/->Y y X2 -/->Y.
Así, por ejemplo, si suponemos que en una empresa un empleado puede
trabajar en varios proyectos, realizando una sola función en cada uno de
ellos (consultor, analista, programador, etc.), aunque pueda ser distinta
según el proyecto, tendríamos que:
(DNI_EMPLEADO, COD_PROYECTO)  FUNCIÓN
es una dependencia completa, ya que ninguno de los elementos del
descriptor por separado determina el implicado, al poder tener un
empleado muchas funciones, lo mismo que un proyecto.

DATOS
normalización
Sin embargo, la dependencia:
(COD_PIEZA, COD_ALMACÉN)  DIRECCIÓN_ALMACÉN
no es completa, ya que: COD_ALMACÉN 
DIRECCIÓN_ALMACÉN
Podemos ahora definir la 2FN de manera más rigurosa

diciendo que un registro está en 2FN si:
 Está en 1FN.
 Todo campo no clave tiene una dependencia funcional completa
respecto de las claves candidatas.

DATOS
 Dependencias funcionales.Teoría de la normalización
Veamos un ejemplo: la relación
VENTAS (cod_pieza, cod_almacén, cantidad, dirección_almacén)
no se encuentra en 2FN ya que la clave es el código de la pieza y el
código del almacén y la dirección del almacén no presenta
dependencia funcional completa ya que:
COD_ALMACÉN  DIRECCIÓN_ALMACÉN
Sin embargo, las relaciones N_VENTAS( cod_pieza, cod_almacén,
cantidad) y ALMACENES( cod_almacén, dirección_almacén) sí están en
2FN, ya que: COD_PIEZA, COD_ALMACÉN  CANTIDAD es una
dependencia completa y COD_ALMACÉN  DIRECCIÓN_ALMACÉN
también lo es, ya que en el caso de que la clave sea simple (esté
formada por un solo campo) siempre que se encuentre en 1FN estará
también en 2FN.

DATOS
 Dependencia funcional transitiva y 3FN
Si existen las siguientes dependencias funcionales que se
muestran en el diagrama.
Se dice que Z tiene una dependencia transitiva respecto de X a través de Y, lo

que se representa como: X  Z.
Por ejemplo, si suponemos que se dan las siguientes dependencias:
COD_EMPLEADO  COD_DEPARTAMENTO
COD_DEPARTAMENTO  NOMBRE_DEPARTAMENTO
COD_DEPARTAMENTO -/-> COD_EMPLEADO
Podemos afirmar que COD_EMPLEADO  NOMBRE_DEPARTAMENTO
transitivamente a través de COD_DEPARTAMENTO.

DATOS
 Dependencia funcional transitiva y 3FN
Se dice que un registro se encuentra en 3FN si:
 Está en 2FN.
 Ningún campo no clave depende transitivamente de ninguna
clave.
Ejemplo: La relación
EMPLEADOS (cod_empleado, cod_depto, nombre_depto) no se
encuentra en 3FN ya que la clave es el COD_EMPLEADO y:
COD_EMPLEADO  COD_DEPARTAMENTO
COD_DEPARTAMENTO  NOMBRE_DEPARTAMENTO
Por tanto, COD_EMPLEADO  NOMBRE_DEPARTAMENTO y esto
significa que un campo no clave (nombre del departamento)
depende transitivamente de la clave (código de empleado).

DATOS
 Forma normal de Boyce-Codd (FNBC)
Se dice que un registro se encuentra en FNBC si, y solo si, todo
determinante es clave, donde por determinante entendemos cualquier
conjunto de campos del que otro campo depende funcionalmente de forma
completa. Ejemplo: dada la relación
VENTAS( cod_pieza, cod_almacén, nombre_almacén, cantidad) donde
suponemos que los almacenes se identifican tanto por su código como por
su nombre. Por tanto, en la relación VENTAS existen dos claves candidatas:
(cod_pieza, cod_almacén) y (cod_pieza, nombre_almacén)
Veamos cuales son los determinantes:
(cod_pieza, cod_almacén) y (cod_pieza, nombre_almacén) son
determinantes al ser claves por cod_almacén y nombre_almacén también
son determinantes por sí solo ya que:
cod_almacén  nombre almacén y al contrario. Por tanto esta relación no
está en FNBC, ya que no todo determinante es clave. Estos campos forman
parte de la clave pero no son la clave.

DATOS
 Forma normal de Boyce-Codd (FNBC)
Si queremos cumplir la FNBC deberemos descomponer la
relación, por ejemplo, de la siguiente manera:
ALMACENES( cod_almacén, nombre_almacén)
N_VENTAS( cod_pieza, cod_almacén, cantidad) donde en la
primera relación existen dos claves: cod_almacén y
nombre_almacén y ambos campos son también determinante
ya que:
cod_almacén  nombre_almacén
nombre_almacén  cod_almacén por tanto está en FNBC.
Mientras que en la segunda relación existe una clave
compuesta (cod_pieza, cod_almacén) y un único
determinante formado por esos dos campos ya que:
cod_pieza, cod_almacén  cantidad por lo que se encuentra
en FNBC.

Presentación Tema 8

Cargado por

Información del documento

Título original

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

Presentación Tema 8

Cargado por

Copyright:

Formatos disponibles

Tema 9:

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

En este tema, una vez que estudiemos el modelo

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

Ejemplo: Tabla persona

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

Ej: Fila de la tabla persona.

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

Juan Pérez 28689555B 1

Pedro Jiménez 54789321C 1

José Sánchez 87456321S 2

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

Juan Pérez 28689555B 1

Pedro Jiménez 54789321C 1

Juan Pérez 28689555B 1

Julián Pérez 45215632L 1

Juan Pérez 28689555B 1

Pedro Jiménez 54789321C 1

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

Pedro Jiménez 54789321C 1 Ciencias

José Sánchez 87456321S 2 Historia

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

ERS Análisis (Qué)

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

Modelo físico de datos TEMA 11

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

Como vemos en la figura, al ser la cardinalidad de EDITORIAL

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

En este caso mejor

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

Cod_mujer debe ser

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

PROVEEDOR 1:N:M PROYECTO

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

PROVEEDOR 1:1:M PROYECTO

Proveedor (cod_proveedor, …) Claves ajenas

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

No utilizar nunca en PARCIAL CON SOLAPAMIENTO

Es posible que haya que incluir

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

Esta opción sólo nos la podemos plantear si la

Es posible que haya que incluir restricciones

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)