Base de datos

Fundamentos Base de datos

Unidad 4: Diseo de BD relacionales

Base de datos

4.1 Caractersticas del diseo relacional

Caractersticas

Una base de datos relacional se compone de varias tablas o relaciones.

No pueden existir dos tablas con el mismo nombre ni registro.

Cada tabla es a su vez un conjunto de registros (filas y columnas).

La relacin entre una tabla padre y un hijo se lleva a cabo por medio de las
claves primarias y ajenas (o forneas).

Las claves primarias son la clave principal de un registro dentro de una tabla y
stas deben cumplir con la integridad de datos.

Las claves ajenas se colocan en la tabla hija, contienen el mismo valor que la
clave primaria del registro padre; por medio de stas se hacen las relaciones.

4.2 Dominios atmicos y la primera forma normal (1FN)

La primera forma normal (1FN o forma mnima) es una forma normal usada en
normalizacin de bases de datos. Una tabla de base de datos relacional que se adhiere a
la 1FN es una que satisface cierto conjunto mnimo de criterios. Estos criterios se
refieren bsicamente a asegurarse que la tabla es una representacin fiel de una relacin
y est libre de "grupos repetitivos".
Segn la definicin de Date de la 1NF, una tabla est en 1NF si y solo si es "isomorfa a
alguna relacin", lo que significa, especficamente, que satisface las siguientes cinco
condiciones:
1. No hay orden de arriba-a-abajo en las filas.
2. No hay orden de izquierda-a-derecha en las columnas.
3. No hay filas duplicadas.
4. Cada interseccin de fila-y-columna contiene exactamente un valor
del dominio aplicable (y nada ms).

Atomicidad
Algunas definiciones de 1NF, ms notablemente la de E.F. Codd, hacen referencia al
concepto de atomicidad. Codd indica que "se requiere que los valores sean atmicos con
respecto al DBMS en los dominios en los que cada relacin es definida".Codd define un
valor atmico como uno que "no puede ser descompuesto en pedazos ms pequeos por
el DBMS (excepto ciertas funciones especiales).

Base de datos

4.3 Dependencias funcionales

Dependencia funcional

B es funcionalmente dependiente de A.

Una dependencia funcional es una conexin entre uno o ms atributos. Por ejemplo si se conoce el valor
de DNI tiene una conexin con Apellido o Nombre.
Las dependencias funcionales del sistema se escriben utilizando una flecha, de la siguiente manera:
FechaDeNacimiento

Edad

De la normalizacin (lgica) a la implementacin (fsica o real) puede ser sugerible tener stas
dependencias funcionales para lograr la eficiencia en las tablas.

4.4 Segunda forma normal

Dependencia Funcional. Una relacin est en 2FN si est en 1FN y si los atributos que
no forman parte de ninguna clave dependen de forma completa de la clave principal. Es
decir que no existen dependencias parciales. (Todos los atributos que no son clave
principal deben depender nicamente de la clave principal).
En otras palabras podramos decir que la segunda forma normal est basada en el
concepto de dependencia completamente funcional.
En trminos levemente ms formales: una tabla 1NF est en 2NF si y solo si ninguno de
sus atributos no-principales son funcionalmente dependientes en una parte (subconjunto
apropiado) de una clave candidata. (Un atributo no-principal es uno que no pertenece a
ninguna clave candidata).
Observe que cuando una tabla 1NF no tiene ninguna clave candidata compuesta (claves
candidatas consistiendo en ms de un atributo), la tabla est automticamente en 2NF.
Ejemplo
Habilidades de los empleados
Empleado Habilidad

Lugar actual de trabajo

Base de datos
Jones

Mecanografa

114 Main Street

Jones

Taquigrafa

114 Main Street

Jones

Tallado

114 Main Street

Roberts

Limpieza ligera 73 Industrial Way

Ellis

Alquimia

73 Industrial Way

Ellis

Malabarismo

73 Industrial Way

Harrison

Limpieza ligera 73 Industrial Way

La nica clave candidata de la tabla es {Empleado, Habilidad}.

El atributo restante, Lugar actual de trabajo, es dependiente solo en parte de la clave
candidata, llamada Empleado. Por lo tanto la tabla no est en 2NF

Solucionado
Habilidades de los empleados

Empleados
Empleado

Lugar actual de trabajo

Jones

114 Main Street

Roberts

73 Industrial Way

Ellis
Harrison

Empleado Habilidad
Jones

Mecanografa

73 Industrial Way

Jones

Taquigrafa

73 Industrial Way

Jones

Tallado

Roberts

Limpieza ligera

Ellis

Alquimia

Ellis

Malabarismo

Harrison

Limpieza ligera

4.5 Tercera forma normal

La tabla se encuentra en 3FN si es 2FN y si no existe ninguna dependencia funcional
transitiva entre los atributos que no son clave.
Un ejemplo de este concepto sera que, una dependencia funcional X->Y en un esquema
de relacin R es una dependencia transitiva si hay un conjunto de atributos Z que no es
un subconjunto de alguna clave de R, donde se mantiene X->Z y Z->Y.
Un ejemplo de una tabla 2NF que falla en satisfacer los requerimientos de la 3NF es:
4

Base de datos
Ganadores del torneo
Torneo

Ao Ganador

Fecha de nacimiento del ganador

Indiana Invitational 1998 Al Fredrickson 21 de julio de 1975

Cleveland Open

1999 Bob Albertson

28 de septiembre de 1968

Des Moines Masters 1999 Al Fredrickson 21 de julio de 1975

Indiana Invitational 1999 Chip Masterson 14 de marzo de 1977

La nica clave candidata es {Torneo, Ao}.

La violacin de la 3NF ocurre porque el atributo no primario Fecha de nacimiento del
ganador es dependiente transitivamente de {Torneo, Ao} va el atributo no
primario Ganador. El hecho de que la Fecha de nacimiento del ganador es
funcionalmente dependiente en el Ganador hace la tabla vulnerable a inconsistencias
lgicas, pues no hay nada que impida a la misma persona ser mostrada con diferentes
fechas de nacimiento en diversos registros.
Para expresar los mismos hechos sin violar la 3NF, es necesario dividir la tabla en dos:
Ganadores del torneo
Torneo

Ao Ganador

Indiana Invitational 1998 Al Fredrickson

Cleveland Open

1999 Bob Albertson

Des Moines Masters 1999 Al Fredrickson

Indiana Invitational 1999 Chip Masterson

Fecha de nacimiento del jugador

Ganador

Fecha de nacimiento

Chip Masterson 14 de marzo de 1977

Al Fredrickson 21 de julio de 1975
Bob Albertson 28 de septiembre de 1968

Las anomalas de actualizacin no pueden ocurrir en estas tablas, las cuales estn en
3NF.

4.6 Forma normal Boyce-Codd(o FNBC)

La Forma Normal de Boyce-Codd es una forma normal utilizada en la normalizacin de
bases de datos. Es una versin ligeramente ms fuerte de la Tercera forma normal
(3FN). La forma normal de Boyce-Codd requiere que no existan dependencias
funcionales no triviales de los atributos que no sean un conjunto de la clave candidata.
En una tabla en 3FN, todos los atributos dependen de una clave, de la clave completa y
de ninguna otra cosa excepto de la clave (excluyendo dependencias triviales, como
). Se dice que una tabla est en FNBC si y solo si est en 3FN y cada
dependencia funcional no trivial tiene una clave candidata como determinante. En
trminos menos formales, una tabla est en FNBC si est en 3FN y los nicos
determinantes son claves candidatas.
5

Base de datos
Ejemplo :
Referencia cruzada de Tutor/Estudiante
ID Tutor Nmero de seguro social del tutor ID Estudiante
1078

088-51-0074

31850

1078

088-51-0074

37921

1293

096-77-4146

46224

1480

072-21-2223

31850

El propsito de la tabla es mostrar qu tutores estn asignados a qu estudiantes. Las

claves candidatas de la tabla son:

{ID Tutor, ID Estudiante}

{Nmero de seguro social del tutor, ID Estudiante}

Por lo tanto los tres atributos de la tabla son atributos primarios, es decir, los tres
atributos pertenecen a las claves candidatas.
Recuerde que la 2NF prohbe dependencias funcionales parciales de atributos noprimarios en las claves candidatas, y la 3NF prohbe dependencias funcionales
transitivas de atributos no-primarios en claves candidatas. Dado que la tabla de arriba
carece de cualquier atributo no-primario, est en 2NF y 3NF.
La FNBC es ms rigurosa que la 3NF en que no permite ninguna dependencia funcional
en la cual el conjunto determinante de atributos no sea una clave candidato (o
superconjunto de eso). La dependencia de ID Tutor en Nmero de seguro social del
tutor es ese tipo de dependencia. Por consiguiente, la tabla de arriba no est en FNBC
Cualquier tabla que sea insuficiente en FNBC ser vulnerable a inconsistencias lgicas.
En la tabla de arriba poda ser representada una combinacin inconsistente de ID Tutor
y Nmero de seguro social del tutor.
En este caso, corregir el problema sera una simple cuestin de usar solo un esquema de
identificacin para los tutores: o el ID, o el nmero del seguro social, pero no ambos.
ID Tutor ID Estudiante
1078

31850

1078

37921

1293

46224

1480

31850

O bien:
Nmero de seguro social del tutor ID Estudiante
088-51-0074

31850

088-51-0074

37921

Base de datos
096-77-4146

46224

072-21-2223

31850

4.7 Algoritmos de descomposicin

Dentro del diseo de bases de datos relacionales,podemos encontrar anomalas en el
diseo, tales como la redundancia de datos, por lo que se debe replantar el diseo
haciendo algunas modificaciones que eliminen dichas redundancias.
Partiendo de este hecho, debemos modificar nuestro esquema de relacin en el que
tenemos redundancias descomponindolo en sub-esquemas con menor cantidad de
atributos; esta descomposicin debe ser cuidadosa, debido a que una mala
descomposicin nos lleva a otra modalidad de mal diseo.
Tras descomponer el esquema principal en sub-esquemas debemos tener en cuenta que
entre estos debe haber solo un atributo en comn mediante el cual relacionaremos
nuestros esquemas, sin embargo debemos ser cuidadosos con este atributo ya que a su
vez este debe ser la nica forma en que se puedan generar las relaciones entre subesquemas, es decir, que cumpla con la dependencia funcional.
De ser as decimos que tenemos una descomposicin de reunin sin prdida caso
contrario si no se cumple decimos que tenemos una descomposicin de reunin con
prdida lo que significa un mal diseo de base de datos.
Ejemplo:

Esquema renta_equipos
nombre_tienda

ciudad_tienda

capital

nombre_cliente

num_contrato

mensualidad

Galeras

Pachuca

250000

Vargas

tel-01

1000

Gran patio

Pachuca

150000

Escamilla

tel-13

560

Satlite

DF

300000

Muoz

tel-31

320

Centro Histrico

DF

350000

Prez

tel-22

560

Tulancingo Centro

Tulancingo

100000

Jurez

tel-14

1500

Galeras

Pachuca

250000

Escamilla

tel-99

540

Satlite

DF

300000

Muoz

tel-29

2000

Centro Histrico

DF

350000

Cortes

tel-95

1700

Satlite

DF

300000

Gutirrez

tel-43

360

Tulancingo Centro

Tulancingo

100000

Cern

tel-70

850

A partir de aqu pudisemos descomponerlo en los siguientes esquemas:

Tienda-cliente
nombre_tienda

ciudad_tienda

capital

nombre_cliente

Galeras

Pachuca

250000

Vargas

Gran patio

Pachuca

150000

Escamilla

Base de datos
Satlite

DF

300000

Muoz

Centro Histrico

DF

350000

Prez

Tulancingo Centro

Tulancingo

100000

Jurez

Galeras

Pachuca

250000

Escamilla

Satlite

DF

300000

Muoz

Centro Histrico

DF

350000

Cortes

Satlite

DF

300000

Gutirrez

Tulancingo Centro

Tulancingo

100000

Cern

Cliente-renta
nombre_cliente

num_contrato

mensualidad

Vargas

tel-01

1000

Escamilla

tel-13

560

Muoz

tel-31

320

Prez

tel-22

560

Jurez

tel-14

1500

Escamilla

tel-99

540

Muoz

tel-29

2000

Cortes

tel-95

1700

Gutirrez

tel-43

360

Cern

tel-70

850

De esta descomposicin podemos observar que para el caso de que un cliente tenga
contratos en ms de una tienda, las tuplas no permiten determinar que prstamo es de
qu sucursal provocando una prdida de informacin que nos lleva a una
descomposicin de reunin con prdida.
Sin embargo podemos descomponer nuestro esquema en los siguientes sub-esquemas
sin perder informacion:
Esquema-tienda
nombre_tienda

ciudad_tienda

capital

Galeras

Pachuca

250000

Gran patio

Pachuca

150000

Satlite

DF

300000

Centro
Histrico

DF

350000

Tulancingo
Centro

Tulancingo

100000

Esquema-contrato
nombre_tienda

nombre_cliente

num_contrato

mensualidad

Galeras

Vargas

tel-01

1000

Base de datos
Gran patio

Escamilla

tel-13

560

Satlite

Muoz

tel-31

320

Centro Histrico

Prez

tel-22

560

Tulancingo Centro

Jurez

tel-14

1500

Galeras

Escamilla

tel-99

540

Satlite

Muoz

tel-29

2000

Centro Histrico

Cortes

tel-95

1700

Satlite

Gutirrez

tel-43

360

Tulancingo Centro

Cern

tel-70

850

De aqu observamos que se tiene en comn el atributo nombre_tienda y este atributo si

cumple la dependencia funcional:
Nombre_tiendacapital, ciudad_tienda
As pues podemos decir que tenemos una descomposicin de reunin sin prdida.

4.8 Formas normales superiores

Cuarta forma Normal
La cuarta forma normal (4NF) es una forma normal usada en la normalizacin de bases
de datos. La 4NF se asegura de que los hechos multivalores independientes estn
correcta y eficientemente representados en un diseo de base de datos. La 4NF es el
siguiente nivel de normalizacin despus de la forma normal de Boyce-Codd (BCNF).
La definicin de la 4NF confa en la nocin de una dependencia multivalor. Una tabla
con una dependencia multivalor es una donde la existencia de dos o ms relaciones
independientes muchos a muchos causa redundancia; y es esta redundancia la que es
removida por la cuarta forma normal.
Ejemplo:
Permutaciones de envos de pizzas
Restaurante

Variedad de Pizza rea de envo

Vincenzo's Pizza Corteza gruesa

Springfield

Vincenzo's Pizza Corteza gruesa

Shelbyville

Vincenzo's Pizza Corteza fina

Springfield

Vincenzo's Pizza Corteza fina

Shelbyville

Elite Pizza

Corteza fina

Capital City

Elite Pizza

Corteza rellena

Capital City

A1 Pizza

Corteza gruesa

Springfield

Base de datos
A1 Pizza

Corteza gruesa

Shelbyville

A1 Pizza

Corteza gruesa

Capital City

A1 Pizza

Corteza rellena

Springfield

A1 Pizza

Corteza rellena

Shelbyville

A1 Pizza

Corteza rellena

Capital City

Cada fila indica que un restaurante dado puede entregar una variedad dada de pizza a un
rea dada.
Note que debido a que la tabla tiene una clave nica y ningn atributo no-clave, no viola
ninguna forma normal hasta el BCNF. Pero debido a que las variedades de pizza que un
restaurante ofrece son independientes de las reas a las cuales el restaurante enva, hay
redundancia en la tabla: por ejemplo, nos dicen tres veces que A1 Pizza ofrece la
Corteza rellena, y si A1 Pizza comienza a producir pizzas de Corteza de queso entonces
necesitaremos agregar mltiples registros, uno para cada una de las reas de envo de
A1 Pizza. En trminos formales, esto se describe como que Variedad de pizza est
teniendo una dependencia multivalor en Restaurante.
Para satisfacer la 4NF, debemos poner los hechos sobre las variedades de pizza
ofrecidas en una tabla diferente de los hechos sobre reas de envo:

Variedades por restaurante

reas de envo por restaurante
Restaurante

Variedad de pizza
Restaurante

rea de envo

Vincenzo's Pizza Corteza gruesa

Vincenzo's Pizza Springfield
Vincenzo's Pizza Corteza fina
Vincenzo's Pizza Shelbyville
Elite Pizza
Elite Pizza
A1 Pizza
A1 Pizza

Corteza fina
Elite Pizza

Capital City

A1 Pizza

Springfield

A1 Pizza

Shelbyville

A1 Pizza

Capital City

Corteza rellena
Corteza gruesa
Corteza rellena

Quinta forma normal

La quinta forma normal (5NF), tambin conocida como forma normal de proyeccinunin (PJ/NF), es un nivel de normalizacin de bases de datos designado para reducir
redundancia en las bases de datos relacionales que guardan hechos multi-valores
aislando semnticamente relaciones mltiples relacionadas. Una tabla se dice que est
10

Base de datos
en 5NF si y solo si est en 4NF y cada dependencia de unin (join) en ella es implicada
por las claves candidato.
Psiquiatra-para-Asegurador-para-Condicin
Psiquiatra

Asegurador

Condicin

Dr. James

Healthco

Ansiedad

Dr. James

Healthco

Depresin

Dr. Kendrick

FriendlyCare OCD

Dr. Kendrick

FriendlyCare Ansiedad

Dr. Kendrick

FriendlyCare Depresin

Dr. Lowenstein FriendlyCare Esquizofrenia

Dr. Lowenstein Healthco

Ansiedad

Dr. Lowenstein Healthco

Demencia

Dr. Lowenstein Victorian Life Trastorno de conversin

El psiquiatra puede ofrecer tratamiento reembolsable a los pacientes que sufren de la

condicin dada y que son asegurados por el asegurador dado. En ausencia de cualquier
regla que restrinja las combinaciones vlidas posibles de psiquiatra, asegurador, y
condicin, la tabla de tres atributos Psiquiatra-para-Asegurador-para-Condicin es
necesaria para modelar la situacin correctamente.
Sin embargo, suponga que la regla siguiente se aplica:
Cuando un psiquiatra es autorizado a ofrecer el tratamiento reembolsable a los
pacientes asegurados por el asegurador P, y el psiquiatra puede tratar la condicin C,
entonces - en caso que el asegurador P cubra la condicin C - debe ser cierto que el
psiquiatra puede ofrecer el tratamiento reembolsable a los pacientes que sufren de la
condicin C y estn asegurados por el asegurador P.

Con estas restricciones es posible dividir la relacin en tres partes.

Psiquiatra-para-Condicin
Psiquiatra

Condicin

Dr. James

Ansiedad

Dr. James

Depresin

Dr. Kendrick

OCD

Dr. Kendrick

Ansiedad

Dr. Kendrick

Depresin

Dr. Lowenstein Esquizofrenia

Psiquiatra-para-Asegurador
Psiquiatra

Asegurador

Dr. James

Healthco

Dr. Kendrick

FriendlyCare

Dr. Lowenstein FriendlyCare

Dr. Lowenstein Healthco
Dr. Lowenstein Victorian Life

Dr. Lowenstein Ansiedad

Dr. Lowenstein Demencia
Dr. Lowenstein

Trastorno de
conversin

11

Base de datos
Asegurador-para-Condicin
Asegurador

Condicin

Healthco

Ansiedad

Healthco

Depresin

Healthco

Demencia

FriendlyCare OCD
FriendlyCare Ansiedad
FriendlyCare Depresin
FriendlyCare Trastorno emocional
FriendlyCare Esquizofrenia
Victorian Life Trastorno de conversin

4.9 Integridad de las bases de datos

Integridad de las Bases de Datos, la integridad en una base de datos es la correccin y exactitud de la
informacin contenida. Adems de conservar la seguridad en un sistema de bases de datos que permite
el acceso a mltiples usuarios en tiempos paralelos.

Reglas de Integridad
Regla de integridad de unicidad de la clave primaria
La regla de integridad de unicidad est relacionada con la definicin de clave primaria que establece que
toda clave primaria que se elija para una relacin no debe tener valores repetidos por lo que el conjunto de
atributos CP es la clave primaria de una relacin R, entonces la extensin de R no puede tener en ningn
momento dos tuplas con la misma combinacin de valores para los atributos de CP.

Regla de integridad de entidad de la clave primaria

La regla de integridad de entidad de la clave primaria dispone que los atributos de la clave primaria de una
relacin no pueden tener valores nulos. Esta regla es necesaria para que los valores de las claves primarias
puedan identificar las tuplas individuales de las relaciones. Si las claves primarias tuviesen valores nulos,
es posible que algunas tuplas no se pudieran distinguir. Un SGBD relacional tendr que garantizar el
cumplimiento de esta regla de integridad en todas las inserciones y en todas las modificaciones que afecten
a atributos que pertenecen a la clave primaria de la relacin.

Regla de integridad referencial

La regla de integridad referencial est relacionada con el concepto de clave fornea, lo que determina que
todos los valores que toma una clave fornea deben ser valores nulos o valores que existen en la clave
primaria que referencia. La necesidad de esta regla es debido a que las claves forneas tienen por objetivo
establecer una conexin con la clave primaria que referencian. Si un valor de una clave fornea no estuviese
presente.
Restriccin
La restriccin en caso de borrado, consiste en no permitir borrar una tupla si tiene una clave primaria
referenciada por alguna clave fornea y la restriccin en caso de modificacin consiste en no permitir

12

Base de datos
modificar ningn atributo de la clave primaria de una tupla si tiene una clave primaria referenciada por
alguna clave fornea.
Actualizacin en cascada
La actualizacin en cascada consiste en permitir la operacin de actualizacin de la tupla, y en efectuar
operaciones compensatorias que propaguen en cascada la actualizacin a las tuplas que la referenciaban;
se acta de este modo para mantener la integridad referencial. La actualizacin en cascada en caso de
borrado consiste en permitir el borrado de una tupla t que tiene una clave primaria referenciada, y borrar
tambin todas las tuplas que referencian t y la actualizacin en cascada en caso de modificacin consiste
en permitir la modificacin de atributos de la clave primaria de una tupla t que tiene una clave primaria
referenciada, y modificar del mismo modo todas las tuplas que referencian t.
Anulacin
La anulacin consiste en permitir la operacin de actualizacin de la tupla y en efectuar operaciones
compensatorias que pongan valores nulos a los atributos de la clave fornea de las tuplas que la
referencian; esta accin se lleva a cabo para mantener la integridad referencial. Los SGBD relacionales
permiten establecer que un determinado atributo de una relacin no admite valores nulos, slo se puede
aplicar la poltica de anulacin si los atributos de la clave fornea s los admiten. Ms concretamente, la
anulacin en caso de borrado consiste en permitir el borrado de una tupla t que tiene una clave referenciada
y, adems, modificar todas las tuplas que referencian t, de modo que los atributos de la clave fornea
correspondiente tomen valores nulos y la anulacin en caso de modificacin consiste en permitir la
modificacin de atributos de la clave primaria de una tupla t que tiene una clave referenciada y, adems,
modificar todas las tuplas que referencian t, de modo que los atributos de la clave fornea correspondiente
tomen valores nulos.

Regla de integridad de dominio

La regla de integridad de dominio est relacionada con la nocin de dominio. Esta regla establece dos
condiciones.

La primera condicin consiste en que un valor no nulo de un atributo Ai debe pertenecer al dominio del
atributo Ai; es decir, debe pertenecer a dominio(Ai). Esta condicin implica que todos los valores no
nulos que contiene la base de datos para un determinado atributo deben ser del dominio declarado
para dicho atributo.

La segunda condicin sirve para establecer que los operadores que pueden aplicarse sobre los valores
dependen de los dominios de estos valores; es decir, un operador determinado slo se puede aplicar
sobre valores que tengan dominios que le sean adecuados.

13