3.

Modelo relacional
3.1 Introduccin
En el captulo anterior se mencionaron 3 tipos de modelado: conceptual, lgico y fsico.

El modelo e-r se considera un modelo conceptual ya que permite a un nivel alto el ver con claridad la informacin utilizada en algun problema o negocio.

En este captulo nos concentraremos en desarrollar un buen modelo "lgico" que se conoce como "esquema de la base de datos" (database schema) a partir del cual se podr realizar el modelado
fsico en el DBMS, es importante mencionar que es un paso necesario, no se puede partir de un modelo conceptual para realizar un fsico.

3.2 Por qu "modelo relacional" ?

Puede resultar confuso el concepto de modelo entidad-relacin vs modelo relacional, quizs porque ambos comparten casi las mismas palabras. Como se mencion en la seccin 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 construdas de diversas maneras:

Creando un conjunto de tablas iniciales y aplicar operaciones de normalizacin hasta conseguir el esquema ms ptimo. Las tcnicas de nomalizacin se explican ms adelante en este
captulo.

Convertir el diagrama e-r a tablas y posteriormente aplicar tambin operaciones de normalizacin hasta conseguir el esquema ptimo.

La primer tcnica fue de las primeras en existir y, como es de suponerse, la segunda al ser ms reciente es mucho ms 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 ms simple a travs de las reglas de conversin.

Se podra 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 "normalizacin" es mnima por lo
general.

Lo anterior tiene otra ventaja, an cuando se normalice de manera deficiente, se garantiza un esquema aceptable, en la primer tcnica no es as.
3.3 Conceptos bsicos
3.3.1 Tablas

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

ttulo ao duracin tipo

Star Wars 1977 124 color
Mighty Ducks 1991 104 color
Wayne's World 1992 95 color

Relacin Pelculas

La relacin Pelculas tiene la intencin de manejar la informacin de las instancias en la entidad Pelculas, cada rengln corresponde a una entidad pelcula y cada columna corresponde a uno de
los atributos de la entidad. Sin embargo las relaciones pueden representar ms que entidades, como se explicar ms adelante.

3.3.2 Atributos

Los atributos son las columnas de un relacin y describen caractersticas particulares de ella.

3.3.3 Esquemas

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

Pelculas (ttulo, ao, duracin, tipo)

En un modelo relacin, un diseo consiste de uno o ms 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 relacin conteniendo valores para cada uno de los atributos.

(Star Wars, 1977, 124, color)

3.3.5 Dominios

Se debe considerar que cada atributo (columna) debe ser atmico, es decir, que no sea divisible, no se puede pensar en un atributo como un "registro" o "estructura" de datos.

3.3.6 Representaciones equivalentes de una relacin

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

 ao ttulo tipo duracin
1991 Mighty Ducks color 104
1992 Wayne's World color 95
1977 Star Wars color 124

Otra representacin de la relacin Pelculas

3.4 Conversin del modelo e-r a un esquema de base de datos (Conversin a tablas)
3.4.1 Introduccin

El modelo es una representacin visual que grficamente nos da una perspectiva de como se encuentran los datos involucrados en un proyecto u organizacin.

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.

3.4.2 Conversin 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 conversin a tablas

una tabla por cada conjunto de entidades

o nombre de tabla = nombre de conjunto de entidades

una tabla por cada conjunto de relaciones m-m

o nombre de tabla = nombre de conjunto de relaciones

definicin de columnas para cada tabla

o conjuntos fuertes de entidades

columnas = nombre de atributos

o conjuntos dbiles de entidades

columnas = llave_primaria (dominante) U atributos(subordinado)

o conjunto de relaciones R (m-m) entre A, B

columnas (R) = llave_primaria (A) U llave_primaria (B) U atributos(R)

o conjunto de relaciones R (1-1) entre A y B

columnas (A) = atribs(A) U llave primaria(B) U atributos(R)

o 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 convertira al siguiente esquema:

Debil

atribs_Debil LLP_A atribs_rel_0

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

3.4.3 Conversin a tablas desde un modelo con generalizacin

modelo e-r
de generalizacin a tablas
dos posibilidades:

1.

o crear una tabla para el conjunto de entidades A de mayor nivel

columnas (A) = atributos(A)

o para cada conjunto de entidades B de menor nivel, crear una tabla tal que:

columns (B) = atributos (B) U llave_primaria (A)

2.

o 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 generalizacin se convertira al siguiente esquema:

1)

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 mtodos para convertir una generalizacin a tablas, no hay una regla exacta de cual usar en determinado caso. A continuacin se mencionan
algunos consejos tiles para la determinacin de cual mtodo emplear:

1. Si la entidad de nivel superior est relacionada con otra(s) entidades puede sugerirse emplear el mtodo (1) ya que de esa manera la tabla (A) ser la nica involucrada en la relacin, de otra
forma se tendran tres tablas (B1,B2 y B3) formando parte de la relacin

2. Es importante tomar en cuenta la pertenencia de instancias, si se considera que hablamos de una generalizacin disjunta, donde no se puede pertenecer a varias entidades de nivel inferior,
quizs sea recomendable el mtodo (1), en otro caso se podra pensar en el mtodo (2).

3. Tambin es importante analizar ambos casos con respecto a las "consultas" que se deseen realizar ya que esto tambin determina en muchos casos el mtodo a emplear.

3.4.4 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 relacin 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 relacin m-m entre "actor" y "serie", demostrando que un actor puede actuar en muchas series y que muchas series tendrn a
los mismos actores.

La tabla que se creara sera:

actor_serie

id_actor id_serie id_personaje

Joaqun Pardav Gnesis Abel hermano bueno
Evita Muoz (Chachita) Qu bonita familia Dulce abuelita
Joaqun Pardav Gnesis Can hermano malo
Evita Muoz (Chachita) Hermelinda linda Bruja Hermelinda

si se considera "id_actor, id_serie" como la llave primaria caemos en un problema porque esa combinacin no identifica de manera nica a la tupla, como es el
 caso de "Joaqun Pardav, Gnesis" ya que en la primer tupla tenemos que determina a "Abel hermano bueno" y en la tercera a "Can hermano malo".

La relacin 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 ms recomendable sera emplear los tres atributos de la relacin "id_actor, id_serie, id_personaje"

3.5 Normalizacin
Una vez creadas las tablas hay que verificarlas y revisar si an se puede reducir u optimizar de alguna manera.

Los problemas tales como la redundancia que ocurren cuando se abarrotan demasiados datos en un sola relacin son llamados anomalas. Los principales tipos son:

1. Redundancia: la informacin se repite innecesariamente en muchas tuplas. En la relacin siguiente, length y filmType.

2. Anomalas de actualizacin: cuando al cambiar la informacin en una tupla se descuida el actualizarla en otra. Si en la relacin encontramos que el length de StarWars es 125 podramos
cambiarlo nicamente para la primer tupla y olvidar actualizar las dems.

3. Anomalas de eliminacin: si un conjunto de valores llegan a estar vacos y se llega a perder informacin relacionada como un efecto de la eliminacin. Si eliminamos al actor Emilio
Estevez, perdemos tambin la tupla de la pelcula 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

3.5.1 Dependencias funcionales (FD)

3.5.1.1 Definicin

En el diseo de esquemas de bases de datos el concepto de dependencia funcional (functional dependency) es vital para eliminar "redundancia", otros factores sera el manejo de dependencias
multivaluadas y las restricciones de integridad referencial.

Una dependencia funcional en una relacin 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 tambin con otro atributo B" . Esta FD se escribira 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 ms 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

Quizs las dependencias funcionales ms evidentes sean las llaves.

Decimos que un conjunto { A1, A2,....An } es una llave de un relacin si:

1. Esos atributos determinan funcionalmente a "todos" los dems atributos de una relacin.

2. No hay un subconjunto de { A1, A2,....An } que determine funcionalmente a "todos" los dems atributos (incluyendo al resto del conjunto { A1, A2,....An })

La definicin anterior de llave es similar a la que se mencion anteriormente de superllave, sin embargo las superllaves no son llaves "mnimas", recordemos que una llave primaria se escoge de
entre el conjunto de superllaves mnimas. Es importante hacer notar que una llave mnima no se refiere al nmero de atributos includos, se puede tener una llave mnima ABC y otra DE donde
ambas son mnimas an cuando una de ellas sea todava de menor tamao que la otra.

Al conjunto de dependencia funcionales de una relacin R se le denominar F.

3.5.1.2 Axiomas de Armstrong:

 Reflexividad: sea un conjunto de atributos y entonces --> *
Aumentacin: 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 algn elemento de no pertenece a se considera una dependencia no trivial.

Si ningn elemento de pertenece a entonces se considera una dependencia completamente no trivial

3.5.1.3 Reglas adicionales

Unin: si --> y --> entonces -->

Decomposicin: si --> entonces --> y -->

Pseudotransitividad: si --> y --> entonces -->

3.5.1.4 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
=result
 for each ( --> F ) do
begin
result --> (reflexividad)
if result then
--> , --> (transitividad)
result=result
end
end

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 podramos afirmar que AB es superllave, pero para ello sera 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 relacin 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 relacin R): Para cada R se calcula + y para cada elemento S + se obtiene una dependencia funcional
--> S.

3.5.2 Primera forma normal

Una tabla se encuentra en 1a NF, si todos sus atributos son atmicos (indivisibles)

El ejemplo clsico:

nombre direccin telfono

En 1a. NF

nombre apellido_paterno apellido_materno direccin telfono

3.5.3 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 descripcin calificacin

NO se encuentra en 2a NF ya que

{ id,clave,depto} --> descripcin

{clave,depto} --> descripcin

Analizando todas las dependencias funcionales:

{ id,clave,depto} --> descripcin

{clave,depto} --> descripcin

{ id,clave,depto} --> calificacin

Para realizar la normalizacin (2NF) la relacin se descompondra en:

curso

depto clave_curso descripcin

estud_curso

id depto clave_curso calificacin

La descomposicin se basa bsicamente en:

La intuicin

Las dependencias funcionales

Es importante que al descomponer una relacin exista:

Descomposicin sin prdida

 Preservacin de dependencias funcionales

3.5.4 Descomposicin sin prdida

Al descomponer una relacin R en varias relaciones R1 y R2 se debe verificar que no haya prdidas, 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 descomposicin en R1 y R2 no hay prdida si:

{ R1 R2 --> R1 } F+

o bien si

{ R1 R2 --> R2 } F+

Para el ejemplo anterior la relacin

id_estudiante depto clave_curso descripcin calificacin

F={ { id,clave,depto} --> descripcin, {clave,depto} --> descripcin, { id,clave,depto} --> calificacin }

tiene F+= { { id,clave,depto} --> id,clave,depto,descripcin,calificacin, {clave,depto} --> descripcin }

y dicha relacin se descompone en:

depto clave_curso descripcin

id_estudiante depto clave_curso calificacin

donde R1 R2 = depto,clave_curso donde depto,clave_curso -->descripcin

y {depto,clave_curso -->descripcin} { { id,clave,depto} --> id,clave,depto,descripcin,calificacin, {clave,depto} --> descripcin }

3.5.5 Preservacin de dependencias

Al descomponer una relacin R en varias relaciones R1,R2,..Rn es importante revisar que se preserven las dependencias funcionales iniciales. De esta manera se garantiza que una actualizacin no
provoque una relacin invlida, verificando las FDs o bien a travs 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 debern ser un subconjunto de F+

De manera que F' = F1 F2 ...Fn

y la preservacin se verifica si F'+= F+

para el ejemplo anterior teniendo:

F={ { id,clave,depto} --> descripcin, {clave,depto} --> descripcin, { id,clave,depto} --> calificacin }

F+= { { id,clave,depto} --> id,clave,depto,descripcin,calificacin, {clave,depto} --> descripcin }

F1= depto,clave_curso--> descripcin

F2= id_estudiante,depto,clave_curso --> calificacin

F' = F1 F2

depto,clave_curso--> descripcin

id_estudiante,depto,clave_curso --> calificacin

F'+= { { id,clave,depto} --> id,clave,depto,descripcin,calificacin, {clave,depto} --> descripcin }

y como F'+= F+ entonces si hay preservacin de dependencias.

3.5.6 Forma normal de Boyce-Codd (BCNF)

3.5.6.1 Caractersticas

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

X --> A es una dependencia funcional trivial

X es una super llave

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

3.5.6.2 Algoritmo general de descomposicin 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 sera {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

3.5.7 Tercera forma normal

3.5.7.1 Caractersticas

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

 X --> A es una dependencia funcional trivial

X es una super llave

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 relacin est en BCNF, est tambin 3NF; pero si una relacin est en 3NF no necesariamente est en BCNF".

ejemplo, dada la relacin

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 descompondra 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 descomposicin si est en 3NF porque:

No hay dependencias funcionales triviales

En la segunda relacin, la segunda DF no cumple que banker-name es superllave

En la segunda relacin, la segunda DF, branch-name es miembro de la llave candidata

{customer-name, branch-name}

Al cumplirse la 3er regla se confirma que la descomposicin 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 extensin id_jefe

nombre_depto --> extensin, 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 relacin, "nombre_depto" no es superllave de R

Se puede observar nuevamente para la segunda relacin que id_jefe no es parte de alguna llave candidata

Aplicando la descomposicin:

deptos

nombre_depto extensin id_jefe

 nombre_depto --> extensin, jefe

empleados

id_empleado nombre_depto

id_empleado --> nombre_depto

Esta descomposicin si est en 3NF porque:

No hay dependencias funcionales triviales

Para toda dependencia X--> A , X es superllave.

Se observa como la relacin no solo est en 3NF sino tambin en BCNF por cumplir con la segunda regla.

3.5.7.2 Algoritmo general de descomposicin tratando de alcanzar 3NF

3.5.7.2.1 Forma cannica de las FDs (Fc)

La forma cannica de F es aquel conjunto mnimo de dependencias funcionales equivalentes a F, sin dependencias redundantes o partes redundantes de dependencias.

Para obtener la Fc se deben extraer todos los miembros "extraos", suponga un conjunto F de dependencias funcionales y la dependencia --> est en F.

El atributo A es extrao en si A y
F lgicamente implica (F - { --> }) {( - A ) --> }

Ejemplo:
F = { A --> C , AB --> C }

B es extrao en AB --> C porque { A --> C, AB --> C } lgicamente implica A --> C (el resultado de quitar B de AB --> C ).

El atributo A es extrao en si A y
el conjunto de dependencias (F - { --> }) { --> ( - A ) } implica lgicamente a F

Ejemplo:
F = { A --> C , AB --> CD}

C es extrao en AB --> CD porque A B --> C puede ser inferido an despus de eliminar C

Test para verificar si un atributo es extrao

Dado un conjunto de dependencias F y --> est en F

Para verificar si A es extrao en

o calcular ( { } - A )+ usando las dependencias en F

o verificar si ( { } - A )+ contiene a , si lo hace entonces A es extrao

Para verificar si A es extrao en

o calcular + usando solo las dependencias en:

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

o verificar si + contiene a A, si lo hace entonces A es extrao

3.5.7.2.2 Algoritmo basado en Fc

Fc: Forma cannica de las FDs

1. Para cada dependencia X --> Y en Fc,

crear una relacin Ri (X,Y)

2. Si ninguna de las Ris contiene una de las superllaves de la relacin,

crear Ri(X) donde X es una de las superllaves de la relacin original

3. Si Ri y Rj tienen una llave en comn,

mezclar Ri y Rj

4. Eliminar relaciones redundantes

*El algoritmo anterior garantiza que en una descomposicin no haya prdida (al incluir por lo menos en una relacin 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

3.5.8 BCNF vs 3NF

Como se mencion anteriormente: "Si una relacin est en BCNF, est tambin 3NF; pero si una relacin est en 3NF no necesariamente est en BCNF".

En la prctica la mayora de los esquemas en 3NF tambin estn 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 prdidas 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 prdidas y con preservacin de dependencias.

Si se alcanza BCNF pero no hay preservacin de dependencias se puede considerar una 3NF (recordando que 3NF siempre debe carecer de prdidas y debe preservar dependencias).

3.6 Conclusiones
De manera que las metas del diseo de bases de datos con dependencias funcionales son:

BCNF*

Descomposicin sin prdida

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