Modelo relacional

INTRODUCCIÓN A BASE DE DATOS

Sistema de información (S.I)



 Un sistema de información (SI) es un conjunto de elementos orientados al tratamiento y administración de datos e información, organizados y listos para su uso posterior, generados para cubrir una necesidad u objetivo. Dichos elementos formarán parte de alguna categoría.


Todos estos elementos interactúan para procesar los datos (incluidos los procesos manuales y automáticos) y dan lugar a información más elaborada, que se distribuye de la manera más adecuada posible en una determinada organización, en función de sus objetivos.



Ventajas de una base de datos respecto a un sistema de información

Una base de datos es algo más que una mera lista o tabla.

Le permite controlar de verdad los datos, recuperarlos, ordenarlos, analizarlos, resumirlos y elaborar informes. La base de datos puede combinar datos de varios archivos, por lo que nunca habrá que introducir dos veces la misma información. Incluso puede contribuir a que la entrada de datos sea más eficaz y precisa.

En esta lección, se van a mostrar algunas de las ventajas que ofrece una base de datos y se presentarán sus componentes más importantes.

Base de datos (B.D)

Una base de datos o banco de datos (en ocasiones abreviada con la sigla BD o con la abreviatura b. d.) es un conjunto de datos pertenecientes a un mismo contexto y almacenados sistemáticamente para su posterior uso. 

Sistema gestor de base de datos (S.G.B.D)

Los sistemas de gestión de bases de datos (en inglés database management system, abreviado DBMS) son un tipo de software muy específico, dedicado a servir de interfaz entre la base de datos, el usuario y las aplicaciones que la utilizan. Permiten almacenar y posteriormente acceder a los datos de forma rápida y estructurada.

Ventajas: 

Proveen facilidades para la manipulación de grandes volúmenes de datos. Entre éstas:

• Simplifican la programación de equipos de consistencia.
• Manejando las políticas de respaldo adecuadas, garantizan que los cambios de la base serán siempre consistentes sin importar si hay errores correctamente, etc.
• Organizan los datos con un impacto mínimo en el código de los programas.
• Disminuyen drásticamente los tiempos de desarrollo y aumentan la calidad del sistema desarrollado si son bien explotados por los desarrolladores.

Usualmente, proveen interfaces y lenguajes de consulta que simplifican la recuperación de los datos.

Inconvenientes:

Típicamente, es necesario disponer de una o más personas que administren la base de datos, de la misma forma en que suele ser necesario en instalaciones de cierto porte disponer de una o más personas que administren los sistemas operativos. Esto puede llegar a incrementar los costos de operación en una empresa. Sin embargo hay que balancear este aspecto con la calidad y confiabilidad del sistema que se obtiene.

Si se tienen muy pocos datos que son usados por un único usuario por vez y no hay que realizar consultas complejas sobre los datos, entonces es posible que sea mejor usar una hoja de cálculo.

Complejidad: los software muy complejos y las personas que vayan a usarlo deben tener conocimiento de las funcionalidades del mismo para poder aprovecharlo al máximo.

Tamaño: la complejidad y la gran cantidad de funciones que tienen hacen que sea un software de gran tamaño, que requiere de gran cantidad de memoria para poder correr.

Coste del hardware adicional: los requisitos de hardware para correr un SGBD por lo general son relativamente altos, por lo que estos equipos pueden llegar a costar gran cantidad de dinero.

Ejemplos: 
                Libres (PostgreSQL, Firebird, SQLite, DB2 Express-C, Apache Derby, MariaDB, MySQL, Drizzle) 

             No libres (Advantage Database, dBase, FileMaker, Fox Pro, gsBase, IBM DB2, IBM Informix, Interbase de CodeGear filial de Borland, MAGIC, Microsoft Access, Microsoft SQL Server, NexusDB, Open Access, Oracle, Paradox, PervasiveSQL, Progress (DBMS), Sybase ASE, Sybase ASA, Sybase IQ, WindowBase, IBM IMS, CA-IDMS)

Registro

Un registro (también llamado fila o tupla) representa un objeto único de datos implícitamente estructurados en una tabla.

Campo

Un campo es la mínima unidad de información a la que se puede acceder; un campo o un conjunto de ellos forman un registro.

Tabla

Se refiere al tipo de modelado de datos, donde se guardan los datos recogidos por un programa. Su estructura general se asemeja a la vista general de un programa de Hoja de cálculo.

Modelo relacional

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.

Por qué "modelo relacional" ?

Puede resultar confuso el concepto de modelo entidad-relación vs modelo relacional, quizás porque ambos comparten casi las mismas palabras. Como se mencionó en la sección anterior, el objetivo del modelo relacional es crear un "esquema" (schema), lo cual como se mencionará posteriormente consiste de un conjunto de "tablas" que representan "relaciones", relaciones entre los datos.
Estas tablas, pueden ser construídas de diversas maneras:

• Creando un conjunto de tablas iniciales y aplicar operaciones de normalización hasta conseguir el esquema más óptimo. Las técnicas de nomalización se explican más adelante en este capítulo.
• Convertir el diagrama e-r a tablas y posteriormente aplicar también operaciones de normalización hasta conseguir el esquema óptimo.

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í. 

Conceptos básicos

Tablas

El modelo relacional proporciona un manera simple de representar los datos: una tabla bidimensional llamada relación.

título	año	duración	tipo
Star Wars	1977	124	color
Mighty Ducks	1991	104	color
Wayne's World	1992	95	color

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.

Atributos

Los atributos son las columnas de un relación y describen características particulares de ella.

Esquemas

Es el nombre que se le da a una relación y el conjunto de atributos en ella.

Películas (título, año, duración, tipo)

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)

Tuplas

Cada uno de los renglones en una relación conteniendo valores para cada uno de los atributos.

(Star Wars, 1977, 124, color)

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.

Representaciones equivalentes de una relación

Las relaciones son un conjunto de tuplas, no una lista de tuplas. El orden en que aparecen las tuplas es irrelevante.
Así mismo el orden de los atributos tampoco es relevante

año	título	tipo	duración
1991	Mighty Ducks	color	104
1992	Wayne's World	color	95
1977	Star Wars	color	124

Otra representación de la relación Películas

Conversión del modelo e-r a un esquema de base de datos (Conversión a tablas)

Introducción

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.
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.

Conversión a tablas desde un modelo con relaciones (1-1,1-m,m-m)

Las tablas siguientes muestran las reglas que se deben seguir para poder crear dicho esquema.

modelo e-r conversión a tablas una tabla por cada conjunto de entidades nombre de tabla = nombre de conjunto de entidades una tabla por cada conjunto de relaciones m-m nombre de tabla = nombre de conjunto de relaciones definición de columnas para cada tabla conjuntos fuertes de entidades columnas = nombre de atributos conjuntos débiles de entidades columnas = llave_primaria (dominante) U atributos(subordinado) conjunto de relaciones R (m-m) entre A, B columnas (R) = llave_primaria (A) U llave_primaria (B) U atributos(R) conjunto de relaciones R (1-1) entre A y B columnas (A) = atribs(A) U llave primaria(B) U atributos(R) conjunto de relaciones R (1-m) entre A y B columnas (B) = atribs(B) U llave primaria(A) U atributos(R)

El diagrama anterior se convertiría al siguiente esquema: Debil atribs_Debil LLP_A atribs_rel_0 A LLP_A atribs_A B1 LLP_B1 atribs_B1 B2 LLP_B2 atribs_B2 LLP_A attribs_rel_2 B3 LLP_B3 atribs_B3 LLP_A atribs_rel_3 A_B1 LLP_A LLP_B1 atribs_rel_1 donde: LLP_X es la llave primaria de la entidad X (un subconjunto de atribs_X)

Ejemplo:

Para el ejemplo de la figura tendríamos el esquema:

escuela id url nombre departamento clave url nombre id_escuela curso clave seccion nombre clave_depto profesor id nombre extension estudiante id nombre carrera profesor_curso id_prof clave_curso seccion_curso estudiante_curso id_estud clave_curso seccion_curso

Conversión a tablas desde un modelo con generalización

modelo e-r de generalización a tablas dos posibilidades: 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) si A es un conjunto de entidades de mayor nivel para cada conjunto de entidades B de menor nivel, crear una tabla tal que: columnas (B) = atributos (B) U atributos (A)

La generalización se convertiría al siguiente esquema: 1) A LLP_A atribs_A B1 atribs_B1 LLP_A B2 atribs_B2 LLP_A B3 atribs_B3 LLP_A donde: LLP_X es la llave primaria de la entidad X (un subconjunto de atribs_X)

2) B1 atribs_B1 LLP_A atribs_A B2 atribs_B2 LLP_A atribs_A B3 atribs_B3 LLP_A atribs_A donde: LLP_X es la llave primaria de la entidad X (un subconjunto de atribs_X)

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.

Descubrimiento de llaves en las relaciones

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. La tabla que se crearía sería: actor_serie id_actor id_serie id_personaje Joaquín Pardavé Génesis Abel hermano bueno Evita Muñoz (Chachita) Qué bonita familia Dulce abuelita Joaquín Pardavé Génesis Caín hermano malo Evita Muñoz (Chachita) Hermelinda linda Bruja Hermelinda si se considera "id_actor, id_serie" como la llave primaria caemos en un problema porque esa combinación no identifica de manera única a la tupla, como es el caso de "Joaquín Pardavé, Génesis" ya que en la primer tupla tenemos que determina a "Abel hermano bueno" y en la tercera a "Caín hermano malo". La relación es correcta ya que un actor puede representar a varios personajes en la misma obra, pero entonces la llave "id_actor, id_serie" no es la correcta y en este caso lo más recomendable sería emplear los tres atributos de la relación "id_actor, id_serie, id_personaje"

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:

1. Redundancia: la información se repite innecesariamente en muchas tuplas. En la relación siguiente, length y filmType.
2. Anomalías de actualización: cuando al cambiar la información en una tupla se descuida el actualizarla en otra. Si en la relación encontramos que el length de StarWars es 125 podríamos cambiarlo únicamente para la primer tupla y olvidar actualizar las demás.
3. Anomalías de eliminación: si un conjunto de valores llegan a estar vacíos y se llega a perder información relacionada como un efecto de la eliminación. Si eliminamos al actor Emilio Estevez, perdemos también la tupla de la película MightyDucks.

title	year	length	filmType	studioName	starName
Star Wars	1977	124	color	Fox	Carrie Fisher
Star Wars	1977	124	color	Fox	Mark Hamill
Star Wars	1977	124	color	Fox	Harrison Ford
Mighty Ducks	1991	104	color	Disney	Emilio Estevez
Wayne's World	1992	95	color	Paramount	Dana Carvey
Wayne's World	1992	95	color	Paramount	Mike Meyers

Dependencias funcionales (FD)

Definición

En el diseño de esquemas de bases de datos el concepto de dependencia funcional (functional dependency) es vital para eliminar "redundancia", otros factores sería el manejo de dependencias multivaluadas y las restricciones de integridad referencial.
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,

A1, A2, ... An ---> B1
A1, A2, ... An ---> B2
A1, A2, ... An ---> Bm

entonces podemos simplemente escribir este conjunto de FDs como: A1, A2, ...An ---> B1,B2,...Bm

Movies(title, year, length, filmType, studioName, starName)

title	year	length	filmType	studioName	starName
Star Wars	1977	124	color	Fox	Carrie Fisher
Star Wars	1977	124	color	Fox	Mark Hamill
Star Wars	1977	124	color	Fox	Harrison Ford
Mighty Ducks	1991	104	color	Disney	Emilio Estevez
Wayne's World	1992	95	color	Paramount	Dana Carvey
Wayne's World	1992	95	color	Paramount	Mike Meyers
...

title, year --> length
title, year --> filmType
title, year --> studioName
title, year -/-> starName

podemos entonces afirmar que: title, year --> length, filmType, studioName
Quizás las dependencias funcionales más evidentes sean las llaves.
Decimos que un conjunto { A1, A2,....An } es una llave de un relación si:

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.
Al conjunto de dependencia funcionales de una relación R se le denominará F.
 

Axiomas de Armstrong:

• Reflexividad: sea un conjunto de atributos y entonces --> *
• Aumentación: si --> y es un conjunto de atributos entonces -->
• Transitividad: si --> y --> entonces -->

*Nota:

• De manera general una dependencia funcional de la forma --> se considera "dependencia funcional trivial" si
• Si al menos algún elemento de no pertenece a se considera una dependencia no trivial.
• Si ningún elemento de pertenece a entonces se considera una dependencia completamente no trivial

Reglas adicionales

• Unión: si --> y --> entonces -->
• Decomposición: si --> entonces --> y -->
• Pseudotransitividad: si --> y --> entonces -->

Cerradura de un conjunto de atributos

Para un esquema R y un conjunto de atributos , si --> R entonces es superllave
para determinar lo anterior se puede encontrar +, todos los atributos que dependen funcionalmente de
teniendo R(A,B,C,D,E)
si A+=(A,B,C,D,E), entonces A--> R entonces A es superllave
La cerradura se puede calcular siguiendo el siguiente algoritmo:
entrada: , F
salida: +

result= while changes to result do for each ( --> F ) do begin if result then result=result end end

= =result     result --> (reflexividad) --> , --> (transitividad)

teniendo R (A,B,C,D,E,F) y F las dependencias: AB-->C, BC-->AD, D-->E, CF-->B.
Comprobar que {A,B}+ ={A,B,C,D,E}


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
El calcular la cerradura es empleado para:

• Verificar si es una superllave, calculando + y revisando si + contiene a todos los atributos de la relación R.
• Verificar una dependencia funcional --> (es decir, si pertenece a F+) checando si +.
• Calcular F+ (la cerradura de todo el conjunto de dependencias F en una relación R): Para cada R se calcula + y para cada elemento S + se obtiene una dependencia funcional --> S.

 

Primera forma normal

Una tabla se encuentra en 1a NF, si todos sus atributos son atómicos (indivisibles)
El ejemplo clásico:

nombre

dirección

teléfono

En 1a. NF

nombre

apellido_paterno

apellido_materno

dirección

teléfono

Segunda forma normal

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

id_estudiante

depto

clave_curso

descripción

calificación

NO se encuentra en 2a NF ya que

{ id,clave,depto} --> descripción
{clave,depto} --> descripción

Analizando todas las dependencias funcionales:

{ id,clave,depto} --> descripción
{clave,depto} --> descripción
{ id,clave,depto} --> calificación

Para realizar la normalización (2NF) la relación se descompondría en:

curso depto clave_curso descripción estud_curso id depto clave_curso calificación

La descomposición se basa básicamente en:

• La intuición
• Las dependencias funcionales

Es importante que al descomponer una relación exista:

• Descomposición sin pérdida
• Preservación de dependencias funcionales

 

Descomposición sin pérdida

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.
Decimos entonces que para una descomposición en R1 y R2 no hay pérdida si:
{ R1 R2 --> R1 } F+
o bien si
{ R1 R2 --> R2 } F+

Para el ejemplo anterior la relación

id_estudiante

depto

clave_curso

descripción

calificación

F={ { id,clave,depto} --> descripción, {clave,depto} --> descripción, { id,clave,depto} --> calificación }
tiene F+= { { id,clave,depto} --> id,clave,depto,descripción,calificación, {clave,depto} --> descripción }
y dicha relación se descompone en:

depto

clave_curso

descripción

id_estudiante

depto

clave_curso

calificación

donde R1 R2 = depto,clave_curso donde depto,clave_curso -->descripción
y {depto,clave_curso -->descripción} { { id,clave,depto} --> id,clave,depto,descripción,calificación, {clave,depto} --> descripción }

 

Preservación de dependencias

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+
De manera que F' = F1 F2 ...Fn
y la preservación se verifica si F'+= F+

para el ejemplo anterior teniendo:
F={ { id,clave,depto} --> descripción, {clave,depto} --> descripción, { id,clave,depto} --> calificación }
F+= { { id,clave,depto} --> id,clave,depto,descripción,calificación, {clave,depto} --> descripción }
F1= depto,clave_curso--> descripción
F2= id_estudiante,depto,clave_curso --> calificación
F' = F1 F2
depto,clave_curso--> descripción
id_estudiante,depto,clave_curso --> calificación
F'+= { { id,clave,depto} --> id,clave,depto,descripción,calificación, {clave,depto} --> descripción }
y como F'+= F+ entonces si hay preservación de dependencias.

 

Forma normal de Boyce-Codd (BCNF)

Características

Un esquema relacional se encuentra en BCNF si para toda dependencia funcional X --> A:

• X --> A es una dependencia funcional trivial

o

• X es una super llave

BCNF no necesariamente preserva las dependencias funcionales F'+ != F+

Algoritmo general de descomposición tratando de alcanzar BCNF

result= {R} done=false calcular F+ while (! done) do if(existe un esquema Ri en result que no está en BCNF) then si --> es una dependencia funcional no trivial en Ri tal que --> Ri no está en F+ y = 0 result= ( result - Ri ) ( Ri - ) ( , ) else done=true end

Ejemplo:

R(A,B,C,D)

B--> C	(B)+ = {CD}
B-->D

La superllave sería {AB} por lo tanto no cumple con BCNF
(B-->CD y B no es superllave).
Descomponiendo usando B-->CD
(A,B) (B,C,D)
Esta última en BCNF

Tercera forma normal

Características

Un esquema relacional se encuentra en 3NF si para toda dependencia funcional X --> A:

• X --> A es una dependencia funcional trivial

o

• X es una super llave

o

• A es miembro de una llave candidata de R
  Lo anterior no quiere decir que una sola llave candidata deba contener a todos los atributos de A, cada atributo de A puede estar contenido en llaves candidatas diferentes.

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".
ejemplo, dada la relación

branch-name

customer-name

banker-name

office-number

banker-name --> branch-name office-number
customer-name branch-name --> banker-name

Se puede observar {customer-name branch-name} determina al resto de los atributos así que es la superllave de R.
No está en 3NF porque:

• Las DFs no son triviales
• En la primer dependencia, "banker-name" no es superllave de R
• Se puede observar que office-number y banker-name no son parte de alguna llave candidata

se descompondría en:

banker-name

branch-name

office-number

banker-name --> branch-name office-number

customer-name

branch-name

banker-name

customer-name branch-name --> banker-name
banker-name --> branch-name

Esta descomposición si está en 3NF porque:

• No hay dependencias funcionales triviales
• En la segunda relación, la segunda DF no cumple que banker-name es superllave
• En la segunda relación, la segunda DF, branch-name es miembro de la llave candidata
  {customer-name, branch-name}

Al cumplirse la 3er regla se confirma que la descomposición está en 3NF.
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 nombre_depto extensión id_jefe nombre_depto --> extensión, jefe empleados id_empleado nombre_depto id_jefe id_empleado --> nombre_depto, id_jefe nombre_depto --> id_jefe

No está en 3NF porque:

• Las DFs no son triviales
• En la dependencia "nombre_depto-->id_jefe" de la segunda relación, "nombre_depto" no es superllave de R
• Se puede observar nuevamente para la segunda relación que id_jefe no es parte de alguna llave candidata

Aplicando la descomposición:

deptos nombre_depto extensión id_jefe nombre_depto --> extensión, jefe empleados id_empleado nombre_depto id_empleado --> nombre_depto

Esta descomposición si está en 3NF porque:

• No hay dependencias funcionales triviales
• Para toda dependencia X--> A , X es superllave.

Se observa como la relación no solo está en 3NF sino también en BCNF por cumplir con la segunda regla.

Algoritmo general de descomposición tratando de alcanzar 3NF

Forma canónica de las FDs (Fc)

La forma canónica de F es aquel conjunto mínimo de dependencias funcionales equivalentes a F, sin dependencias redundantes o partes redundantes de dependencias.
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 }
  B es extraño en AB --> C porque { A --> C, AB --> C } lógicamente implica A --> C (el resultado de quitar B de 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

Test para verificar si un atributo es extraño
Dado un conjunto de dependencias F y --> está en F

• Para verificar si A es extraño en
  • calcular ( { } - A )+ usando las dependencias en F
  • verificar si ( { } - A )+ contiene a , si lo hace entonces A es extraño
• Para verificar si A es extraño en
  • calcular + usando solo las dependencias en:

    F'=(F - { --> }) { --> ( - A) }

  • verificar si + contiene a A, si lo hace entonces A es extraño

Algoritmo basado en Fc

Fc: Forma canónica de las FDs Para cada dependencia X --> Y en Fc, crear una relación Ri (X,Y) Si ninguna de las Ris contiene una de las superllaves de la relación, crear Ri(X) donde X es una de las superllaves de la relación original Si Ri y Rj tienen una llave en común, mezclar Ri y Rj Eliminar relaciones redundantes

*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:

sid

name

street

city

zip

student

Fc:
sid -->name,street,city
street, city-->zip
zip --> city
Descomponer en 3NF

1. R1(sid, name, street, city), R2(zip, street, city), R3(zip, city)
2. -
3. -
4. Eliminar R3

sid

name

street

city

R1

sid -->name,street,city

zip

street

city

R2

street, city-->zip
zip --> city

BCNF vs 3NF

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".
En la práctica la mayoría de los esquemas en 3NF también están en BCNF, contraejemplo:

(Sucursal, Cliente, Banquero)

banquero --> sucursal
sucursal, cliente --> banquero

está en 3NF pero no en BCNF puesto que "banquero" no es una superllave, normalizando:

suc-banquero (sucursal, banquero)
suc-cliente (sucursal, cliente)

Nuevamente se presentan las pérdidas de dependencias
Qué es mejor ? BCNF o 3NF ?

• De manera general se puede decir que ambas son buenas.
• El caso ideal es conseguir BCNF sin pérdidas y con preservación de dependencias.
• Si se alcanza BCNF pero no hay preservación de dependencias se puede considerar una 3NF (recordando que 3NF siempre debe carecer de pérdidas y debe preservar dependencias).

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

* 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.
 como relaccionar tablas


Juanma