Académique Documents
Professionnel Documents
Culture Documents
3. Modelo relacional
3.1 Introducción
En el capítulo anterior se mencionaron 3 tipos de modelado: conceptual, lógico y físico.
El modelo e-r se considera un modelo conceptual ya que permite a un nivel alto el ver con claridad la
información utilizada en algun problema o negocio.
En este capítulo nos concentraremos en desarrollar un buen modelo "lógico" que se conoce como "esquema
de la base de datos" ( database schema
) a partir del cual se podrá realizar el modelado físico en el DBMS, es
importante mencionar que es un paso necesario, no se puede partir de un modelo conceptual para realizar un
físico.
La primer técnica fue de las primeras en existir y, como es de suponerse, la segunda al ser más reciente es
mucho más conveniente en varios aspectos:
El partir de un diagrama visual es muy útil para apreciar los detalles, de ahí que se llame modelo
conceptual.
El crear las tablas iniciales es mucho más simple a través de las reglas de conversión.
Se podría pensar que es lo mismo porque finalmente hay que "normalizar" las tablas de todas formas,
pero la ventaja de partir del modelo e-r es que la "normalización" es mínima por lo general.
Lo anterior tiene otra ventaja, aún cuando se normalice de manera deficiente, se garantiza un esquema
aceptable, en la primer técnica no es así.
El modelo relacional proporciona un manera simple de representar los datos: una tabla bidimensional llamada
relación.
ict.udlap.mx/people/carlos/is341/bases03.html 1/18
1/8/2019 3 Modelo relacional
Relación Películas
La relación Películas tiene la intención de manejar la información de las instancias en la entidad Películas, cada
renglón corresponde a una entidad película y cada columna corresponde a uno de los atributos de la entidad.
Sin embargo las relaciones pueden representar más que entidades, como se explicará más adelante.
3.3.2 Atributos
Los atributos son las columnas de un relación y describen características particulares de ella.
3.3.3 Esquemas
En un modelo relación, un diseño consiste de uno o más esquemas, a este conjunto se le conoce como
"esquema relacional de base de datos" (relational database schema) o simplemente "esquema de base de
datos" (database schema)
3.3.4 Tuplas
Cada uno de los renglones en una relación conteniendo valores para cada uno de los atributos.
3.3.5 Dominios
Se debe considerar que cada atributo (columna) debe ser atómico, es decir, que no sea divisible, no se puede
pensar en un atributo como un "registro" o "estructura" de datos.
Las relaciones son un conjunto de tuplas, no una lista de tuplas. El orden en que aparecen las tuplas es
irrelevante.
El modelo es una representación visual que gráficamente nos da una perspectiva de como se encuentran los
datos involucrados en un proyecto u organización.
ict.udlap.mx/people/carlos/is341/bases03.html 2/18
1/8/2019 3 Modelo relacional
Pero el modelo no nos presenta propiamente una instancia de los datos, un ejemplo que muestre con claridad
algunas datos de muestra y como se relacionan en realidad. Por eso es conveniente crear un "esquema", el
cual consiste de tablas las cuales en sus renglones (tuplas) contienen instancias de los datos.
Las tablas siguientes muestran las reglas que se deben seguir para poder crear dicho esquema.
ict.udlap.mx/people/carlos/is341/bases03.html 3/18
1/8/2019 3 Modelo relacional
Debil
LLP_A atribs_A
B1
LLP_B1 atribs_B1
B2
B3
A_B1
donde:
Ejemplo:
escuela
id url nombre
departamento
ict.udlap.mx/people/carlos/is341/bases03.html 4/18
1/8/2019 3 Modelo relacional
curso
profesor
id nombre extension
estudiante
id nombre carrera
profesor_curso
estudiante_curso
modelo e-r
de generalización a tablas
dos posibilidades:
1.
crear una tabla para el conjunto de entidades A de mayor nivel
columnas (A) = atributos(A)
para cada conjunto de entidades B de menor nivel, crear una tabla tal que:
columns (B) = atributos (B) U llave_primaria (A)
2.
ict.udlap.mx/people/carlos/is341/bases03.html 5/18
1/8/2019 3 Modelo relacional
1)
LLP_A atribs_A
B1
atribs_B1 LLP_A
B2
atribs_B2 LLP_A
B3
atribs_B3 LLP_A
donde:
2)
B1
B2
B3
ict.udlap.mx/people/carlos/is341/bases03.html 6/18
1/8/2019 3 Modelo relacional
donde:
Es importante mencionar que a pesar de que existen 2 métodos para convertir una generalización a tablas, no
hay una regla exacta de cual usar en determinado caso. A continuación se mencionan algunos consejos útiles
para la determinación de cual método emplear:
1. Si la entidad de nivel superior está relacionada con otra(s) entidades puede sugerirse emplear el método
(1) ya que de esa manera la tabla (A) será la única involucrada en la relación, de otra forma se tendrían
tres tablas (B1,B2 y B3) formando parte de la relación
2. Es importante tomar en cuenta la pertenencia de instancias, si se considera que hablamos de una
generalización disjunta, donde no se puede pertenecer a varias entidades de nivel inferior, quizás sea
recomendable el método (1), en otro caso se podría pensar en el método (2).
3. También es importante analizar ambos casos con respecto a las "consultas" que se deseen realizar ya
que esto también determina en muchos casos el método a emplear.
Las llaves resultantes en las relaciones de un esquema se pueden inferir de la siguiente manera:
1) Cada tabla que provenga de una entidad contiene por si misma una llave
2) Para las tablas resultado de una relación se toman las llaves primarias de ambas entidades y éstas
conforman la nueva llave primaria, excepto en un caso como el que sigue:
Podemos observar que existe una relación m-m entre "actor" y "serie", demostrando
que un actor puede actuar en muchas series y que muchas series tendrán a los
mismos actores.
actor_serie
bueno
Qué bonita
Evita Muñoz (Chachita) Dulce abuelita
familia
Joaquín Pardavé Génesis Caín hermano malo
Evita Muñoz (Chachita) Hermelinda linda Bruja Hermelinda
3.5 Normalización
Una vez creadas las tablas hay que verificarlas y revisar si aún se puede reducir u optimizar de alguna
manera.
Los problemas tales como la redundancia que ocurren cuando se abarrotan demasiados datos en un sola
relación son llamados anomalías. Los principales tipos son:
3.5.1.1 Definición
Una dependencia funcional en una relación R es una enunciado de la forma "si dos tuplas de R concuerdan en
los atributos A1,A2,...An (tienen los mismos valores para cada atributo), entonces deben concordar también
con otro atributo B" . Esta FD se escribiría como A1,A2,....An --> B y se dice que "A1, A2,....An determina
funcionalmente a B".
Por otro lado, si un conjunto de atributos A1,A2...An determina funcionalmente a más de un atributo,
entonces podemos simplemente escribir este conjunto de FDs como: A1, A2, ...An ---> B1,B2,...Bm
podemos entonces afirmar que: title, year --> length, filmType, studioName
1. Esos atributos determinan funcionalmente a "todos" los demás atributos de una relación.
2. No hay un subconjunto de { A1, A2,....An } que determine funcionalmente a "todos" los demás atributos
(incluyendo al resto del conjunto { A1, A2,....An })
La definición anterior de llave es similar a la que se mencionó anteriormente de superllave, sin embargo las
superllaves no son llaves "mínimas", recordemos que una llave primaria se escoge de entre el conjunto de
superllaves mínimas. Es importante hacer notar que una llave mínima no se refiere al número de atributos
incluídos, se puede tener una llave mínima ABC y otra DE donde ambas son mínimas aún cuando una de ellas
sea todavía de menor tamaño que la otra.
*Nota:
para determinar lo anterior se puede encontrar +, todos los atributos que dependen funcionalmente de
teniendo R(A,B,C,D,E)
entrada: ,F
salida: +
result= =
begin
end
Si {A,B}+ = {A,B,C,D,E,F} entonces podríamos afirmar que AB es superllave, pero para ello sería necesaria
alguna dependencia adicional ej. AB --> CF
Una tabla se encuentra en 1a NF, si todos sus atributos son atómicos (indivisibles)
El ejemplo clásico:
En 1a. NF
Una tabla se encuentra en 2a NF, si está en 1a NF y cada atributo que NO es llave es "completamente"
dependiente de la llave.
Si tenemos la tabla:
calificaciones_cursos
NO se encuentra en 2a NF ya que
curso
estud_curso
La intuición
Las dependencias funcionales
ict.udlap.mx/people/carlos/is341/bases03.html 11/18
1/8/2019 3 Modelo relacional
Al descomponer una relación R en varias relaciones R1 y R2 se debe verificar que no haya pérdidas, es decir,
que al volver a combinar las relaciones (producto entre R1 y R2) se obtengan exactamente las mismas tuplas.
{ R1 R2 --> R1 } F+
o bien si
{ R1 R2 --> R2 } F+
Al descomponer una relación R en varias relaciones R1,R2,..Rn es importante revisar que se preserven las
dependencias funcionales iniciales. De esta manera se garantiza que una actualización no provoque una
relación inválida, verificando las FDs o bien a través de combinaciones de relaciones(productos o joins)
aunque esto último no es muy eficiente.
Para ello se analizan todas la dependencias funcionales Fi para cada Ri que deberán ser un subconjunto de F+
ict.udlap.mx/people/carlos/is341/bases03.html 12/18
1/8/2019 3 Modelo relacional
F' = F1 F2
depto,clave_curso--> descripción
3.5.6.1 Características
result= {R}
done=false
calcular F+
while (! done) do
result= ( result - Ri ) ( Ri - ) ( , )
else
done=true
end
Ejemplo:
R(A,B,C,D)
B-->D
(A,B) (B,C,D)
3.5.7.1 Características
Se puede observar que las 2 primeras restricciones son las mismas que para BCNF pero existe una tercera que
da flexibilidad a las relaciones.
Podemos afirmar entonces que: "Si una relación está en BCNF, está también 3NF; pero si una relación está en
3NF no necesariamente está en BCNF".
Se puede observar {customer-name branch-name} determina al resto de los atributos así que es la superllave
de R.
se descompondría en:
ict.udlap.mx/people/carlos/is341/bases03.html 14/18
1/8/2019 3 Modelo relacional
Se puede observar que al no cumplir con las 2 primeras no está en BCNF pero gracias al relajamiento si está
en 3NF
Otro ejemplo:
deptos
empleados
Aplicando la descomposición:
deptos
empleados
id_empleado nombre_depto
Se observa como la relación no solo está en 3NF sino también en BCNF por cumplir con la segunda regla.
Para obtener la Fc se deben extraer todos los miembros "extraños", suponga un conjunto F de dependencias
funcionales y la dependencia --> está en F.
El atributo A es extraño en si A y
F lógicamente implica (F - { --> }) {( - A ) --> }
Ejemplo:
F = { A --> C , AB --> C }
El atributo A es extraño en si A y
el conjunto de dependencias (F - { --> }) { --> ( - A ) } implica lógicamente a F
Ejemplo:
F = { A --> C , AB --> CD}
C es extraño en AB --> CD porque A B --> C puede ser inferido aún después de eliminar C
*El algoritmo anterior garantiza que en una descomposición no haya pérdida (al incluir por lo menos en una
relación una de las superllaves) y que se preserven las dependencias funcionales (al incluir cada una de ellas).
Ejemplo:
student
ict.udlap.mx/people/carlos/is341/bases03.html 16/18
1/8/2019 3 Modelo relacional
Fc:
sid -->name,street,city
street, city-->zip
zip --> city
Descomponer en 3NF
R1
sid -->name,street,city
R2
street, city-->zip
zip --> city
Como se mencionó anteriormente: "Si una relación está en BCNF, está también 3NF; pero si una relación está
en 3NF no necesariamente está en BCNF".
está en 3NF pero no en BCNF puesto que "banquero" no es una superllave, normalizando:
3.6 Conclusiones
De manera que las metas del diseño de bases de datos con dependencias funcionales son:
BCNF*
Descomposición sin pérdida
Preservación de dependencias
ict.udlap.mx/people/carlos/is341/bases03.html 17/18
1/8/2019 3 Modelo relacional
* Llegar a una forma BCNF puede llegar a ser complicado, debido a esto en muchas ocasiones es suficiente
con alcanzar la 3NF para lograr un buen diseño.
ict.udlap.mx/people/carlos/is341/bases03.html 18/18