MODELO DE DATOS

INTRODUCCIÓN

Desde tiempos remotos los datos han sido registrados por el hombre en algún tipo
de soporte (papel, piedra, madera, etc.) a fin de que quedara constancia de un
fenómeno e idea. Los datos han de ser interpretados (incorporándoles significado)
para que se conviertan en información útil. Cuando utilizamos el lenguaje natural
y decimos, por ejemplo, que una persona nació en 1965, el dato (1965) va
acompañado de su interpretación (año de nacimiento de una cierta persona), sin
embargo en la informática, se separó el dato de su significado. Por ello, a fin de
facilitar la interpretación de los datos, surgen los modelos de datos como
instrumentos que ayudan a incorporar significado a los datos.
Según FLORY (1982), “modelar consiste en definir un mundo abstracto y teórico
tal que las conclusiones que se pueden sacar de él coincidan con las
manifestaciones aparentes del mundo real”. Siendo un modelo, “un conjunto de
conceptos que permiten construir una representación organizacional de la
empresa”.
Los modelos de datos proporcionan mecanismos de abstracción que permiten la
representación de aquella parcela del mundo real cuyos datos nos interesa
registrar, lo que habitualmente se denomina universo del discurso o mini-mundo
según DITTRICH (1994). Dicha representación se concibe en dos niveles: el de
las estructuras que hacen posible la representación de la información, y el de la
información en sí misma. Estos dos niveles dan lugar, en el ámbito de la base de
datos, a la distinción entre esquema y base de datos; conceptos que DITTRICH
(1994) define como: “La descripción específica de un mini-mundo determinado, en
términos de un modelo de datos, recibe el nombre de esquema (esquema de
datos o esquema de una base de datos) de dicho mini-mundo. La colección de
datos que en sí misma representa la información del mini-mundo da lugar a la
base de datos”.
Asociados a los modelos de datos están los lenguajes de datos que permiten
definir y manipular (consultar, actualizar) la base de datos.
En la arquitectura de una base de datos propuesta por ANSI (American Nacional
Standard Institute) (1975) se suelen diferenciar tres niveles de abstracción
Conceptual, Externo e Interno. El nivel global contiene una representación del
conjunto de los datos de una organización; en el nivel externo, los datos (en
general solo una parte de los mismos) se describen para atender las necesidades
de uno o varios procesos o de un grupo de usuarios en particular; el nivel interno
describe las características de los datos tal como han de encontrarse
almacenados físicamente, siendo sus elementos de descripción punteros, índices,
agrupamientos, etc..
Existen, por tanto, en una base de datos tres clases de esquemas: el esquema
global, los esquemas externos (tantos como necesiten las aplicaciones), y el
esquema interno que, en un momento determinado, es único, aunque un mismo
esquema global admite distintos tipos de esquemas internos entre los cuales se
seleccionará aquel que cumpla mejor los requisitos de eficiencia, seguridad, etc.
Los modelos globales se clasifican, a su vez, en conceptuales y convencionales.
Los modelos conceptuales (también denominados de alto nivel) facilitan la
descripción global del conjunto de información de la empresa al nivel más próximo
al usuario, por los que sus conceptos son cercanos al mundo real (entidades,
atributos, interrelaciones, etc.); los modelos convencionales se encuentran
instrumentados en los SGBD y están orientados a describir los datos a nivel lógico
para el SGBD, por lo que sus conceptos son tablas o relaciones en el caso del
modelo relacional, redes en el Codasyl, jerarquías en el jerárquico, etc. En la
figura 1 se muestra la clasificación de los modelos de datos globales.

CONCEPTUALES
Enfocados a describir el mundo real

MODELO DE DATOS
GLOBALES

CONVENCIONALES O
LÓGICOS Jerárquicos
Implementados en SGBD Codasyl
Realacional

Figura 1. Clasificación de los modelos de datos globales

MODELO, ESQUEMA Y EJEMPLAR.

La descripción de un cierto mundo real (por ejemplo una universidad) por medio
de un modelo de datos da como resultado un esquema.

Mundo Real
MODELO
DE
DATOS

Esquema
El esquema es la descripción de la estructura de la base de datos, y ejemplar del
esquema, son los datos que en un determinado momento se encuentran
almacenados en el esquema.
La relación entre los conceptos modelo, esquema y ejemplar se representa en la
figura 2, donde un modelo determinado (entre todos los existentes), como
instrumento que ayuda a interpretar la realidad, permite obtener distintos
esquemas al aplicarlo a realidades distintas. Cada uno de estos esquemas será
una determinada percepción de una cierta realidad, y podrá tener múltiples
ejemplares en el transcurso del tiempo; en un momento determinado, habrá un
único ejemplar de dicho esquema.
El esquema en sí mismo tiene que estar descrito en términos de datos, por lo que
a estos datos se les llama a veces metadatos, es decir, datos acerca de los datos.

Conjunto de reglas para

estructurar los datos del Modelo 1 Modelo i Modelo n
mundo real

Percepción de una
determinada realidad
interpretada de acuerdo
con un cierto modelo Esquema 1 Esquema i Esquema n

Valores que toma la

percepción de una cierta
realidad (esquema) en
un punto del tiempo Ejemplar 1 Ejemplar i Ejemplar n

Figura 2. Relación entre modelo, esquema y ejemplar.

CONCEPTO DE MODELO DE DATOS.

Podemos definir el concepto de modelo de datos como: “un conjunto de

conceptos, reglas y convenciones bien definidos que nos permiten aplicar una
serie de abstracciones a fin de describir y manipular los datos de un cierto mundo
real que deseamos almacenar en la base de datos”.
Un modelo de datos define las reglas según las cuales han de ser estructurados
los datos acerca del mundo real. La representación de una determinada realidad
mediante un modelo ( instrumento que nos facilita el proceso de representación)
da lugar a un esquema, el cual describe las categorías existentes en dicha
realidad. Sin embargo, la realidad no contempla solo aspectos estáticos, sino
también propiedades dinámicas y estas han de ser también especificadas en
operaciones de consulta y actualización de la base de datos.
Por lo tanto, podemos decir que las propiedades del mundo real son de dos tipos:
Estáticas, o relativamente invariantes en el tiempo, que responden a lo que
suele entenderse como estructuras.
Dinámicas, que son las operaciones que se aplican a los datos o valores
almacenados en las estructuras, las cuales varían en el transcurso del tiempo
al aplicársele dichas operaciones.
El modelo de datos debe proporcionar facilidades para recoger ambos aspectos.
El componente estático de un determinado modelo de datos expresado con una
sintaxis es el Lenguaje de definición de Datos ((LDD) y el componente dinámico el
Lenguaje de Manipulación de Datos (LMD).

RESTRICCIONES DE INTEGRIDAD.

En el mundo real ciertas reglas que deben cumplir los elementos en él existentes;
por ejemplo, una persona solo puede tener un número de cédula. Cuando se
diseña una base de datos se desea que esta refleje lo más fielmente posible el
universo del discurso que estamos tratando de recoger en nuestro sistema de
información, por lo que en el esquema de la base de datos, junto con los objetos,
las asociaciones y las propiedades de los mismos, debemos describir también
estas reglas llamadas restricciones semánticas o de integridad , las cuales pueden
ser definidas como condiciones que limitan el conjunto de ejemplares válidos de
un esquema.
La semántica y la integridad son conceptos que en las bases de datos suelen ir
asociados, aunque no son idénticos. El término semántica se refiere al significado
de los datos y el de integridad a la corrección de los mismos y a su consistencia
respecto al mundo real del cual proceden. Cuando en el esquema de una base de
datos se encuentra descrita la semántica del mundo real, será posible comprobar
si los valores de los datos se atienen o no a ésta semántica previamente definida,
comprobándose la integridad de los mismos.

LOS MODELOS DE DATOS EN EL PROCESO DE DISEÑO DE UNA BASE DE

DATOS.

Se conoce como proceso de diseño de una base de datos al conjunto de etapas

necesarias para pasar de una determinada realidad (Universo del Discurso) a la
base de datos que la representa. Los modelos de datos desempeñan un papel
importante en el proceso de diseño de una base de datos al ofrecernos facilidades
de abstracción que nos ayudan a representar la realidad.
Los objetivos que persigue todo modelo de datos son de dos tipos:
Formalización, ya que el modelo de datos permite definir formalmente las
estructuras permitidas y las restricciones; también el modelo de datos establece la
base para la definición de un lenguaje de datos y facilita una apreciación más
objetiva de la rigidez o flexibilidad de las estructuras de datos.
Diseño, ya que el modelo de datos es un elemento fundamental en el desarrollo
de una metodología de diseño de bases de datos, en el cual se basan los otros
componentes de la metodología (lenguajes, documentación y otras herramientas).

MUNDO REAL Universidad, Biblioteca, Departamento

de formación de una empresa, Hospital,
Entidad bancaria, etc.
UNIVERSO DEL DISCURSO Visión del mundo real bajo unos
determinados objetivos

MODELADO CONCEPTUAL DE LOS Modelos conceptuales (Modelo Entidad-

DATOS Relación, etc.)

MODELADO LÓGICO Modelos Convencionales o de base de

(BASE DE DATOS) datos (Modelo Relacional, red,
jerárquico, etc.)

MODELADO INTERNO Modelos Internos (registros internos o

(ESTRUCTURAS DE DATOS) almacenados, punteros, organizaciones
secuenciales, indizadas, direccionadas,
agrupamientos, etc.)
ALMACENAMIENTO Estructuras Físicas (registros
FISICO físicos,bytes, bits, campos, items, etc.)

Etapas en el diseño de una base de datos y tipo de modelos en los que se

apoyan.

MODELO DE DATOS RELACIONAL

El modelo de datos relacional, basado en la teoría matemática de las relaciones,

los datos se estructuran lógicamente en forma de relaciones (tablas). Este modelo
aísla al usuario de las estructuras físicas de los datos, consiguiendo así la
independencia de las aplicaciones respecto de los datos.
La estructura básica del modelo relacional es la relación (o tabla), que sirve para
representar tanto los objetos como las asociaciones entre ellos. Los atributos son
las propiedades de las relaciones, y se definen sobre los dominios, los cuales, a
diferencia de los atributos, tienen vida propia, es decir, existen con independencia
de cualquier otro elemento del modelo, mientras que la existencia de un atributo
va unida a la de la relación a la que pertenece.
RESTRICCIONES

Integridad de una Entidad. Es una restricción debida a la necesidad de que

todas las tuplas de una relación sean distintas, lo cual establece que: “Ningún
atributo que forme parte de la clave primaria puede tomar valore nulos”. Valor nulo
de un atributo representa información desconocida, no aplicable, etc. Por lo tanto
si alguno de los atributos que forman parte de la clave primaria tomase valores
nulos, algunas de las tuplas de la relación no podrían ser identificadas, por lo que
se violaría la condición de que el valor de la clave debe ser único para cada tupla.

EL MODELO RELACIONAL Y LA NORMALIZACION.

El modelo relacional es importante por dos razones. Primero, debido a que las
estructuras del modelo relacional son amplias y generales y pueden utilizarse para
expresar diseños independientes de DBMS. Segundo, el modelo relacional es la
base de una importante categoría de productos DBMS.
El Modelo Relacional.
Una afinidad es una tabla de dos dimensiones. Cada hilera de la tabla tiene datos
que pertenecen a alguna cosa o a una parte de alguna cosa. Cada columna de la
tabla contiene datos referentes a un atributo. Las hileras se denominan tupla y las
columnas se llaman atributos.
La siguiente tabla muestra la terminología relacional

Modelo Relacional Programador Usuario

Afinidad Archivo Tabla
Tupla(Fila) Registro Fila
Atributo Campo Columna

Para que una tabla sea una afinidad debe cumplir ciertas restricciones. Primero,
las celdas de la tabla deben ser de valor único; no se permite repetir grupos ni
tener arreglos como valores. Todos los ingresos en cualquier columna (atributo)
deben ser del mismo tipo. Si una columna contiene números de empleados debe
haber números de empleado para cada hilera de la tabla. Cada columna posee un
nombre único y no es importante el orden de las columnas en la tabla. En una
tabla no pueden ser idénticas dos hileras (tuplas) y no es importante el orden de
las hileras.
La siguiente figura es un ejemplo de una tabla (Afinidad EMPLEADO). El formato
generalizado EMPLEADO (Nombre, Edad, Sexo, NumerodeEmpleado) se llama
estructura de la afinidad y es lo que la mayor parte de la gente quiere decir
cuando usa el término afinidad.
 Atributo 1 Atributo 2 Atributo Atributo 4
Nombre Edad 3 NumerodeEmplea
Sexo do
Tupla 1 Araujo 21 F 010110
Tupla 2 Dávila 22 M 010100
. García 22 M 101000
. Jerez 21 F 201100
. Moreno 19 M 111100
. Nuñez 20 F 111101
Tupla 7 Salas 19 M 111111

Para entender el modelo relacional y la normalización se deben comprender dos

términos: dependencia funcional y clave.

Dependencia Funcional.
Una dependencia funcional es una relación entre uno o más atributos. Suponga
que si se da el valor de un atributo se puede obtener (o buscar) el valor de otro. Si
se conoce el valor de NumeroDeCuentaDeCliente se puede hallar el valor de
EstadoDeCuentaDeCliente. Si esto es cierto, se puede decir que
EstadoDeCuentaDeCliente es funcionalmente dependiente de
NumeroDeCuentaDeCliente. En términos más generales, el atributo Y es
dependiente del atributo X si el valor de X determina el valor de Y. O, puesto de
otro modo, si se conoce el valor de X, se puede obtener el valor de Y.
Suponga que los estudiantes tienen un número de identificación único (ID de
estudiante o SID) y que cada alumno tiene una y solo una especialidad. Dado el
valor de un SID se puede encontrar la especialidad del estudiante y así la
especialidad depende del SID.
Las dependencias funcionales se escriben usando la siguiente notación:
SID Especialidad
Esta expresión se lee como: "SID determina funcionalmente Especialidad", "SID
determina Especialidad" o "Especialidad es dependiente de SID". Los atributos del
lado izquierdo de la flecha se llaman determinantes.
Como se ha señalado, una dependencia funcional es una relación entre valores de
atributos. Si SID determina Especialidad, un valor particular de SID hará pareja
sólo con un valor de Especialidad. En sentido inverso, un valor de Especialidad
puede hacer pareja con uno o más valores diferentes de SID.
Suponga que informática es la especialidad del estudiante cuyo SID es 123. Cada
vez que SID y Especialidad se encuentren juntos en una afinidad, el valor de SID
para 123 hará pareja con el valor Informática de Especialidad. Sin embargo lo
opuesto no es cierto, pues la especialidad de Informática puede hacer pareja con
varios valores de SID (diversos estudiantes pueden tener especialidad en
Informática). se puede decir que la relación de SID con Especialidad es muchos a
uno (N:1). En general se puede decir que si A determina a B, la relación de los
valores de A a B es N:1.
Las dependencias funcionales pueden involucrar grupos de atributos. Considere la
afinidad CALIFICACIONES(SID, NombreDeClase, Calificación). La combinación
de un SID y un NombreDeClase determina una calificación, una dependencia
funcional que se escribe así:
(SID, NombreDeClase) Calificación
Observe que tanto SID como NombreDeClase son necesarios para determinar
una calificación. No se puede subdividir la dependencia funcional porque SID no
determina la calificación por sí mismo.

Claves.
Una clave es un grupo de uno o más atributos que identifican de modo único a una
hilera. Considere la afinidad ACTIVIDAD de la siguiente figura, cuyos atributos son
SID, Actividad y Cuota. El significado de una hilera es que un estudiante se apunta
en la actividad designada por una cuota especificada. Suponga que a un
estudiante se le permite participar sólo en una actividad a la vez. Un valor de SID
determina una hilera única, de modo que es una clave.

SID Actividad Cuota

100 Esquí 200
150 Natación 50
175 Squash 50
200 Natación 50

ACTIVIDAD(SID, Actividad, Cuota) Clave:SID

Las claves también pueden estar compuestas por un grupo de atributos tomados
en conjunto. Si a los estudiantes se les permitiera inscribirse en distintas
actividades al mismo tiempo, sería posible que un valor de SID apareciera en dos
o más hileras de la tabla y, por lo tanto, SID no identificaría una sola hilera.
Algunas combinaciones de atributos, tal vez (SID, Actividad) pueden ser
requeridas.
Hay un sutil pero importante punto en el párrafo anterior. Si los atributos son o no
son claves y si son, o no, dependencias funcionales, no lo determina una serie
abstracta de reglas sino, mas bien, las hipótesis, es decir, los modelos mentales
del usuario y las reglas del negocio de las organizaciones que desarrollan las
bases de datos. En el ejemplo anterior, si SID (SID, Actividad) o alguna otra
combinación es la clave, lo determina por completo la semántica fundamental de
la base de datos. Se debe interrogar a los usuarios para resolver tales preguntas.
Recuerde que todas las hipótesis hechas acerca de las dependencias funcionales,
claves y similares, están determinadas por los modelos mentales del usuario.

NORMALIZACION.

En el modelo relacional, como en los demás modelos de datos, el diseño de una

base de datos se puede abordar de dos formas distintas:
A. Obteniendo el esquema relacional directamente a partir de la observación
de nuestro universo del discurso, de forma que plasmemos nuestra
percepción del mismo en un conjunto de esquemas de relación, los cuales
 contendrán los atributos y las restricciones de integridad que representan
los objetos y reglas que hemos podido captar en nuestro análisis del mundo
real.
B. Realizando el proceso de diseño de dos fases, en la primera se lleva a cabo
el diseño conceptual, por ejemplo en el modelo E-R, obteniéndose el
correspondiente esquema conceptual; en la segunda, éste se transforma en
un esquema relacional, siguiendo unas determinadas reglas de
transformación.
Estas relaciones que resultan de la observación del mundo real o de la
transformación al modelo relacional del esquema E-R elaborado en la etapa de
modelado conceptual, pueden presentar algunos problemas, derivados de fallos
en la percepción del universo del discurso, en el diseño del esquema E-R, o en el
paso al modelo relacional, entre estos problemas cabe destacar los siguientes:
Incapacidad para almacenar ciertos hechos
Redundancias y, por lo tanto, posibilidad de inconsistencias.
Ambigüedades.
Pérdida de información.
Pérdidas de dependencias funcionales, es decir, de ciertas restricciones de
integridad que dan lugar a interdependencias entre los datos.
Existencias de valores nulos (inaplicables).
Aparición, en la base de datos, de estados que no son válidos en el mundo real
(anomalías de inserción, borrado y modificación.

Anomalías de Modificación.

No todas las afinidades son deseables. Una tabla que cumple la definición mínima
de una afinidad tal vez no tenga una estructura efectiva o apropiada. Para algunas
afinidades, el cambiar los datos puede tener consecuencias no deseables,
llamadas anomalías de modificación. Las anomalías pueden eliminarse
volviendo a definir la afinidad en dos o más afinidades. En la mayor parte de las
circunstancias, se prefieren las afinidades redefinidas o normalizadas.
Considere de nuevo ACTIVIDAD de la figura anterior. Si se elimina la tupla para
estudiante 100, no solo se perderá el hecho de que es un esquiador, sino también
el hecho de que esquiar cuesta $200. Esto se denomina anomalía de
eliminación; esto es, eliminando los hechos acerca de una entidad (que
Estudiante 100 es esquiador) de manera inadvertida se eliminan los hechos
acerca de otra entidad (que esquiar cuesta $200). Con una eliminación se pierden
hechos acerca de dos entidades.
Puede usarse la misma afinidad para ilustrar una anomalía de inserción. Suponga
que se quiere almacenar el hecho de que Buceo Autónomo cuesta $175, pero no
se pueden acceder estos datos en la afinidad ACTIVIDAD hasta que un estudiante
tome Buceo Autónomo. Esta restricción se llama una anomalía de inserción. No se
puede insertar un hecho acerca de una entidad, hasta que se posea un hecho
adicional acerca de una entidad.
Se pueden eliminar las anomalías de inserción y eliminación, dividiendo la afinidad
ACTIVIDAD en dos afinidades, cada una concerniente a un tema distinto. Se
pueden poner atributos de SID y de Actividad en una afinidad, la nueva afinidad se
llamará ESTU-ACT (estudiante-actividad); y se pueden obtener los atributos para
Actividad y Cuota en una afinidad llamada ACT-COST (actividad-costo). La
siguiente figura muestra los mismos datos de muestra almacenados en estas dos
nuevas afinidades.

SID Actividad Actividad Cuota

100 Esquí Esquí 200
150 Natación Natación 50
175 Squash Squash 50
200 Natación

ESTU-ACT (SID, Actividad) ACT-COST (Actividad, Cuota)

Clave: SID Clave: Actividad

Sin embargo, separar una afinidad en dos afinidades tiene una desventaja.
suponga que un estudiante trata de inscribirse en una actividad que no existe. Por
ejemplo, Estudiante 250 quiere enrolarse en Racquetbol. Se puede insertar esta
nueva tupla en EST-ACT (la hilera contendría 250, RACQUETBOL) pero ¿debe
hacerse?. ¿Debería permitirse que un estudiante se inscriba en una actividad que
no está en la afinidad ACT-COST?. Puesto de otra forma ¿Las aplicaciones de la
base de datos deben prevenir de alguna forma que se agreguen hileras de
estudiantes si el valor de ACTIVIDAD no está en la tabla ACT-COST?.
La respuesta a esta pregunta se encuentra en los requerimientos del usuario. Esta
restricción se llama restricción de integridad referencial. si la acción debe
prohibirse, esta restricción debe documentarse como parte del diseño del
esquema. Durante la implementación, se definirá la restricción para el DBMS si el
producto en uso proporciona tales restricciones de verificación. Si no, la restricción
debe imponerse a través de programas de aplicación.

Clases de Afinidades.
Las afinidades pueden clasificarse por los tipos de anomalías de modificación a
las cuales son vulnerables. En los años setenta, los teóricos relacionales
investigaron estos tipos. Alguien encontraba una anomalía, la clasificaba y
pensaba en la forma de prevenirla. Cada vez que esto ocurría, mejoraban los
criterios para diseñar las afinidades. Estas clases de afinidades y las técnicas para
prevenir las anomalías son llamadas formas normales.

En la siguiente figura se aprecian las formas normales.

 Primera Forma Normal(1NF)

Segunda Forma Normal (2NF)

Tercera Forma Normal (3NF)

Forma Normal de Boyce-Codd(BCNF) *

Cuarta Forma Normal (4NF)

Quinta Forma Normal (5NF)

* Forma normal dominio/clave(DK/NF)

Estas formas normales fueron útiles, aunque tenían serias limitaciones. Ninguna
teoría garantizaba que una de ellas eliminaría todas las anomalías: cada forma
solo eliminaba algunas. Esta situación cambió en 1981 cuando R. Fagin definió la
forma normal dominio/clave (DK/NF), y está libre de todas las anomalías de
modificación, sin importar su tipo.
Primera Formas Normal.
Cualquier tabla de datos que cumpla con la definición de una afinidad, se dice que
está en la primera forma normal. Para que una tabla sea una afinidad debe
cumplirse lo siguiente: las celdas de las tablas deben poseer valores simples y no
se permiten grupos ni arreglos repetidos como valores. Todos los ingresos en
cualquier columna (atributo), deben ser del mismo tipo. Cada columna debe tener
un nombre único, el orden de las columnas en la tabla no es importante. Dos
hileras en una tabla no deben ser idénticas, aunque el orden de las hileras no es
importante. La afinidad ACTIVIDAD está en la primera forma normal.
Segunda forma normal.
Considere la afinidad ACTIVIDADES de la siguiente figura. Tal afinidad posee
anomalías de modificación. Si se elimina la tupla para estudiante 175, se perderá
el hecho de que Squash cuesta 50$. Tampoco se puede ingresar una actividad
hasta que se inscribe un estudiante. la afinidad está expuesta a anomalías de
eliminación y de inserción.
SID Actividad Cuota
100 Esquí 200
100 Golf 65
150 Natación 50
175 Squash 50
200 Natación 50
200 Golf 65
Afinidad con una clave de dos atributos (SID, Actividad)
El problema con esta afinidad es que posee una dependencia que involucra solo
parte de la clave. La clave es la combinación (SID, Actividad), la afinidad contiene
una dependencia, Actividad Cuota. El determinante de esta dependencia
(Actividad) es parte de la clave (SID, Actividad). Se dice que Cuota es
parcialmente dependiente de la clave de la tabla. No habría anomalías de
modificación si Cuota dependiera por completo de la clave. Para eliminar estas
anomalías se debe separar la afinidad en dos afinidades.
Esta situación conduce a la definición de segunda forma normal: Una afinidad esta
en segunda forma normal si todos sus atributos que no son claves dependen por
completo de la clave. De acuerdo a esto, cada afinidad que tiene un atributo único
como clave está en segunda forma normal.
ACTIVIDADES puede descomponerse para formar dos afinidades en segunda
forma normal. Las afinidades son las mismas ESTU-ACT y ACT-COST.
Tercera Forma Normal.
Considere la afinidad VIVIENDA que se muestra en la siguiente figura:
SID Edificio Cuota
100 Rosa 1200
150 Imagen 1100
200 Rosa 1200
250 Perucho 1100
300 Rosa 1200
VIVIENDA(SID, Edificio, Cuota)
Clave: SID
Dependencias Funcionales: Edificio Cuota
SID Edificio Cuota
La clave es SID y las dependencias funcionales son SID Edificio y Edificio
Cuota. Estas dependencias surgen porque cada estudiante vive en un edificio y
cada edificio tiene una cuota. Cada estudiante que vive en las Res. Rosa paga
1200 por trimestre.
Debido a que SID determina Edificio y Edificio determina Cuota, indirectamente
SID Cuota. Un arreglo de dependencias funcionales como éste se denomina
una dependencia transitiva, ya que SID determina Cuota por medio del atributo
Edificio.
Por esta dependencia transitiva, SID (un atributo simple) es la clave y la afinidad
está en segunda forma normal (tanto Edificio como Cuota están determinadas por
SID). A pesar de esto VIVIENDA tiene anomalías.
Para eliminar las anomalías de una afinidad en segunda forma normal, debe
quitarse la dependencia transitiva, lo que conduce a la definición de una tercera
forma normal: una afinidad está en tercera forma normal si esta en segunda forma
normal y no tiene dependencias transitivas.
La afinidad VIVIENDA puede dividirse en dos afinidades en tercera forma normal.
Los ejemplos son las afinidades ESTU-VIVIENDA(SID, Edificio) y EDIF-
CUOTA(Edificio, Cuota) de la siguiente figura.
SID Edificio Edificio Cuota
100 Rosa Rosa 1200
150 Imagen Imagen 1100
200 Rosa Perucho 1100
250 Perucho
300 Rosa
ESTU-VIVIENDA(SID,Edificio) EDIF-CUOTA(Edificio, Cuota)
Clave : SID Clave: Edificio
Forma Normal de Boyce-Codd.
Considere la afinidad ASESOR de la siguiente figura.
SID Especialidad NombreF
100 Matemáticas Marquez
150 Psicología Jaimes
200 Matemáticas Ramírez
250 Matemáticas Marquez
300 Psicología Perez
350 Matemáticas Ramírez
ASESOR(SID,Especialidad,NombreF)
Clave(primaria): (SID, Especialidad)
Clave(candidata): (SID,NombreF)
Dependencias Funcionales NombreF Especialidad
Suponga que los requerimientos que sustentan esta afinidad son que un
estudiante (SID) pueda tener una o mas especialidades (Especialidad), una
especialidad pueda tener varios miembros de la facultad (NombreF) como
consejeros, y un miembro de la facultad (NombreF) solo imparte asesoría en una
área de especialidad.
Puesto que los estudiantes pueden tener varias especialidades, SID no determina
Especialidad. Como los estudiantes pueden tener varios asesores, SID tampoco
determina NombreF. SID por sí mismo no puede ser una clave.
La combinación (SID, Especialidad) determina NombreF y la combinación (SID,
NombreF) determina Especialidad. Cualquiera de las combinaciones puede ser
una clave. Dos o mas atributos o conjuntos de atributos que puedan ser una clave,
se denominan claves candidatas. Cualquiera de las candidatas que se
seleccione para ser la clave se denomina clave primaria.
Ademas de las claves candidatas, hay otra dependencia funcional a considerar:
NombreF determina Especialidad (cualquier miembro de la facultad asesora en
solo una especialidad. Por lo tanto, conociendo NombreF se puede determinar
Especialidad). De tal modo NombreF es un determinante.
ASESOR está en primera forma normal. También está en segunda forma normal,
pues cualquier atributo que no es clave depende de toda la clave (sin importar cuál
clave candidata se seleccione). También está en tercera forma normal porque no
tiene dependencias transitivas. A pesar de todo esto, tiene anomalías de
modificación.
Suponga que estudiante 300 deja la escuela. Si se quita la tupla Estudiante 300,
se perderá el hecho de que Perez imparte asesoría en Psicología. Esta es una
anomalía de eliminación. En forma similar ¿Cómo se almacena el hecho de que
Alviarez asesora en Economía?. No es posible hasta que un estudiante se inscribe
en tal materia. Esta es una anomalía de inserción.
Situaciones como la anterior conducen a la definición de la forma normal de
Boyce-Codd (BCNF): Una afinidad está en BCNF si cada determinante es una
clave candidata. ASESOR no está en BCNF puesto que tiene un determinante,
NombreF, que no es una clave candidata.
Como en los ejemplos anteriores, ASESOR puede descomponerse en dos
afinidades que no tengan anomalías. Por ejemplo, las afinidades ESTU-ASE(SID,
NombreF) y ASE-MATERIA(NombreF, Materia) (MiembroDeLaFacultad, Materia)
no tienen anomalías.
SID NombreF NombreF Materia
100 Marquez Marquez Matemáticas
150 Jaimes Jaimes Psicología
200 Ramírez Ramírez Matemáticas
250 Marquez Perez Psicología
300 Perez
350 Ramírez
Las afinidades en BCNF no tiene anomalías con respecto a las dependencias
funcionales.
Cuarta Forma Normal.
Considere la afinidad ESTUDIANTE de la siguiente figura que muestra la relación
entre estudiantes, especialidad y actividades.
SID Especialidad Actividad
100 Música Natación
100 Contabilidad Natación
100 Música Tenis
100 Contabilidad Tenis
150 Matemáticas Carrera
ESTUDIANTE (SID, Especialidad, Actividad)
Clave: (SID, Especialidad, Actividad)
Dependencia de valores múltiples
SID Especialidad ( Se lee SID multidetermina Especialidad)
SID Actividad ( Se lee SID multidetermina Actividad)
Suponga que los estudiantes pueden inscribirse en varias especialidades y
participar en diversas actividades. La única clave es la combinación de los
atributos (SID, Especialidad, Actividad). La estudiante 100 tiene su especialidad
en música y contabilidad y también participa en natación y tenis. El estudiante 150
solo tiene especialidad en matemáticas y participa en carrera.
¿Cuál es la relación entre SID y Especialidad?. No es una dependencia funcional
porque los estudiantes pueden tener distintas especialidades. Un valor único de
SID puede poseer muchos valores de Especialidad. Esto también se aplica a la
relación entre SID y Actividad.
Tal dependencia por atributos se denomina dependencia de valores múltiples.
estas conducen a anomalía de modificación. Observe la redundancia de datos de
la tabla anterior. la estudiante 100 tiene cuatro registros, cada uno de los cuales
muestra una de sus especialidades junto con una de sus actividades.
Existe una dependencia de valores múltiples cuando una afinidad tiene al menos
tres atributos, dos de los cuales poseen valores múltiples y sus valores dependen
solo del tercer atributo.
Para evitar la dependencia de valores múltiples se construyen dos afinidades,
donde cada una almacena datos para solamente uno de los atributos de valores
múltiples.
Las afinidades ESTU-ESPECIALIDAD(SID, Especialidad) y ESTU-ACT(SID,
Actividad) como se ve en la siguiente figura.
 SID Especialidad SID Actividad
100 Música 100 Esquí
100 Contabilidad 100 Natación
150 Matemáticas 100 Tenis
150 Carrera
ESTU-ESPECIALIDAD(SID, Especialidad) ESTU-ACTIVIDAD(SID, Actividad)
Clave: (SID, Especialidad) Clave: (SID, Actividad)
La cuarta forma normal se define: Una afinidad está en cuarta forma normal si
está en BCNF y no tiene dependencia de valores múltiples.
Quinta Forma Normal.
Tiene que ver con afinidades que pueden dividirse en subafinidades (como se ha
venido haciendo), pero que no pueden reconstruirse. No se sabe cuales son las
consecuencias de tales dependencias, incluso si tienen consecuencias prácticas.
A continuación se estudia una forma normal que garantiza que no habrá
anomalías de ningún tipo. Cuando se ponen las afinidades en esa forma, se sabe
que no pueden ocurrir ni siquiera las extrañas anomalías asociadas a la quinta
forma normal.
Forma Normal Dominio/Clave.
Una afinidad está en DK/NF si cada restricción en la afinidad es una consecuencia
lógica de la definición de las claves y dominios. Considere los términos
importantes en esta definición: restricción, clave y dominio.
Una restricción es cualquier regla que gobierna los valores estáticos de atributos y
que es precisa para establecer si es verdadera o no. Las reglas para editar, las
restricciones de interrelación, las dependencias funcionales y las dependencias de
valores múltiples son ejemplos de restricciones.
Una clave es el único identificador de una tupla.
Un dominio tiene una descripción física y una descripción semántica o lógica. La
descripción física es la serie de valores que puede tener el atributo y la descripción
lógica es el significado del atributo.
Una afinidad está en la forma normal dominio/clave si al ejecutar las restricciones
de la clave y el domino provocan que se cumplan todas las restricciones.
No se conoce un algoritmo para convertir una afinidad a DK/NF, ni siquiera se
sabe cuáles afinidades pueden convertirse a DK/NF. Encontrar o diseñar las
afinidades DK/NF es más un arte que una ciencia. Se debe definir las afinidades
de modo que las restricciones sean consecuencias lógicas de los dominios y las
claves. Cuando no se pueda estas restricciones deben desarrollarse dentro de los
programas de aplicación que procesan la base de datos.
A continuación se muestran tres ejemplos.
Ejemplo 1 de la forma normal dominio/clave.
Se tiene la afinidad ESTUDIANTE de la siguiente figura, que contiene SID,
NivelDeGrado, Edificio y Cuota. Edificio es el lugar donde vive el estudiante y
Cuota es la cantidad que paga el estudiante por vivir en ese edificio.
ESTUDIANTE(SID, NiveDeGrado, Edificio, Cuota)
Clave : SID
Restricciones: Edificio Cuota
SID no debe empezar con el dígito 1
SID determina funcionalmente los otros tres atributos, de modo que SID es una
clave. Suponga que también se sabe (a partir de la definición de requerimientos)
que Edificio Cuota y que SID no debe empezar con 1. Si se expresan estas
condiciones como consecuencias lógicas de las definiciones de dominio y clave,
se puede estar seguro, que no habrá anomalías de modificación.
Definiciones de dominio
SID IN CDDD, donde C es un dígito decimal 1 D = dígito decimal;
NivelDeGrado IN ("FR", "SO", "JR", "SN", "GR" )
Edificio IN CARAC (4)
Cuota IN DEC (4)
Definiciones de afinidad y clave
ESTUDIANTE (SID, NivelDeGrado, Edificio)
Clave: SID
EDIF-CUOTA (Edificio, Cuota)
Clave: Edificio
Ejemplo 2 de la forma normal dominio/clave
La afinidad PROFESOR contiene datos acerca de los profesores, las clases que
imparten y los estudiantes a quienes enseñan. FID (ID de Facultad) y NombreF
(Nombre de Facultad) identifican inequivocamente a un profesor. SID identifica de
modo único a un estudiante, pero NombreE no identifica a SID. Los profesores
pueden enseñar varias clases y asesorar a varios estudiantes, pero un estudiante
es asesorado sólo por un profesor. Las FID comienzan con un 1, pero las SID no
deben comenzar con 1. Se muestra en la siguiente figura:
PROFESOR (FID, NombreF, Clase, SID, NombreE)
Clave: (FID, Clase, SID)
Restricciones: FID NombreF
NombreF FID
FID Clase I SID
NombreF Clase I SID
SID FID
SID NombreF
SID NombreE
FID debe empezar con 1; SID no debe empezar con 1
FID y NombreF se determinan funcionalmente entre sí (en esencia son
equivalentes), FID y NombreF multideterminan Clase y SID. SID determina
funcionalmente FID y NombreF. SID determina NombreE.
La esencia de la normalización es que cada afinidad debe tener un solo tema.
Considerado desde esta perspectiva, hay tres temas en PROFESOR. Uno es la
correspondencia entre las FID y NombreF. Otro concierne las clases que un
profesor enseña y el tercero se refiere al número de identificación, nombre y
asesor de un estudiante especificado.
La siguiente figura muestra las tres afinidades que reflejan esto.
Definiciones del dominio
FID IN CDDD, C=1 D=dígito decimal;
NombreF IN CARAC (30)
Clase IN CARAC(10)
SID IN CDDD, C es un dígito decimal 1 D=dígito decimal
NombreE IN CARAC(30)
Definiciones de afinidad y clave
FACULTAD(FID, NombreF)
Clave(primaria) : FID
Clave (candidata): NombreF
PREPARACION: (NombreF, Clase)
Clave: NombreF, Clase
ESTUDIANTE (SID, NombreE, NombreF)
Clave: SID
La afinidad FACULTAD representa la equivalencia de FID y NombreF, FID es la
clave y NombreF es la clave alternativa, lo que significa que ambos atributos son
únicos para la afinidad. Debido a que ambas son claves, las dependencias
funcionales FID NombreF y NombreF FID son consecuencias lógicas de las
claves.
La afinidad PREPARACION contiene la correspondencia de facultad y clases;
muestra las clases que un profesor está preparado para enseñar. La clave es la
combinación (NombreF, Clase). Se requieren ambos atributos en la clave porque
un profesor puede enseñar varias clases. ESTUDIANTE representa los nombres
del estudiante y el asesor para una SID particular. Cada una de estas afinidades
tiene un tema, observe que al separar el tema PREPARACION de ESTUDIANTE
se ha eliminado la dependencia de valores múltiples.
Ejemplo 3 de la forma normal dominio/clave
Considere las restricciones en la afinidad ESTU-ASESOR de la siguiente figura.
ESTU-ASESOR(SID, NombreE, FID, NombreF, EstadoDeGradoDeFacultad)
Clave: SID
Restricciones: FID NombreF
NombreF FID
FID y NombreF EstadoDeGradoDeFacultad
Solamente un graduado de la facultad puede asesorar estudiantes
graduados
FID empieza con 1
SID no debe empezar con 1
SID de estudiantes graduados empieza con 9
EstadoDeGradoDeFacultad
R
S 0 parano graduadosde la facultad
T 1 paragraduadosde la facultad
Esta afinidad contiene información de un estudiante y su asesor. SID determina
NombreE, FID, NombreF y EstadoDeGradoDeFacultad y, por lo tanto, es la clave.
FID y NombreF identifican a un solo miembro de la facultad y son equivalentes
entre sí. Tanto FID como NombreF determinan EstadoDeGradoDeFacultad. El
nuevo tipo de restricción es que solo los miembros de la facultad de graduados
están facultados para asesorar a los estudiantes graduados.
Las restricciones de dominio son que SID debe empezar con un 9 y no con un 1
para los estudiantes graduados, FID debe comenzar con un 1 y
EstadoDeGradoDeFacultad es 0 para la facultad de no graduados y 1 para la
facultad de graduados. Con estas restricciones si SID comienzan con 9, el valor de
EstadoDeGradoDeFacultad debe ser 1.
Para llevar esta afinidad en DK/NF se identifica lo siguiente. Hay dos temas:
asesoramiento de graduados y asesoramiento de no graduados. La siguiente
figura contiene una afinidad G-ASE para los estudiantes graduados y una afinidad
NG-ASE para los no graduados.
Definiciones de dominio
FID IN CDDD, donde C=1, D= dígito decimal
NombreF IN CARAC(30)
EstadoDeGradoDeFacultad IN [0,1]
GSID CDDD donde C=9; D= un dígito decimal, estudiante
graduado
NGSID IN CDDD, donde C 1 y C 9; D= un dígito decimal
estudiante no graduado
NombreE IN CARAC (30)
Definiciones adicionales del dominio
NombreFDeG IN NombreF de Facultad, donde
EstadoDeGradoDeFacultad = 1
Definiciones de afinidades y claves
FACULTAD (FID, NombreF, EstadoDeGradoDeFacultad)
Clave: FID o NombreF
G-ASE (GSID, NombreE, NombreFDeG)
Clave: GSID
NG-ASE (NGSID, NombreE, NombreF)
Clave: NGSID

RESUMEN DE LAS FORMAS NORMALES

Forma Característica que la define
1NF Cualquier afinidad
2NF Todos los atributos que no son claves dependen por completo de las
claves
3NF No hay dependencias transitivas
BCNF Cada determinante es una candidata para clave
4NF No hay dependencia de valores múltiples
5NF No se describió en este análisis
DK/NF Todas las restricciones en las actividades son consecuencias lógicas
de los dominios y las claves.

La Síntesis de Afinidades
Anteriormente se estudió el diseño relacional desde una perspectiva analítica. A
continuación estudiaremos el diseño relacional desde un punto de vista sintético.
Para esto se pregunta: dados una serie de atributos con ciertas dependencias
funcionales ¿qué afinidades se deberán formar?.
Observe primero que dos atributos (por ejemplo A y B) pueden relacionarse en
tres formas:
1. Se determinan entre sí:
A ByB A
Por lo tanto A y B tienen una relación de atributos uno a uno
2. Uno determina al otro
A B pero B no A
Por lo tanto, A y B tiene una relación de muchos a uno.
3. No están relacionados funcionalmente.
A no B y B no A
Por lo tanto, A y B tiene una relación de atributos muchos a muchos.
En la siguiente tabla se muestran los tres tipos de relaciones de atributos.
Tipo de relación del atributo
Uno-a-uno Muchos-a- Muchos-a-
uno muchos
Definición de la R(A,B) S(C,D) T(E,F)
afinidad*
Dependencias A B C D E/ F
B A D C F/ E
Clave AoB C (E,F)
Regla para agregar
otro atributo. AOB C C E (E,F) G
* Las letras usadas en estas definiciones de afinidades son iguales para la
siguiente tabla.
Relaciones de atributos uno-a-uno.
Este caso se ilustra mediante FID y NombreF en los ejemplos 2 y 3 de la forma
normal dominio/clave. Cada uno de estos atributos identifica de modo único a una
persona de la facultad. En consecuencia, el valor de FID corresponde a un valor
de nombreF y viceversa.
Pueden derivarse tres enunciados equivalentes a partir del ejemplo de FID y
NombreF.
Si dos atributos se determinan funcionalmente entre sí, la relación de sus
valores de datos es uno-a-uno.
Si dos atributos identifican de manera única la misma cosa (entidad u objeto),
la relación de sus valores de datos es uno-a-uno.
Si dos atributos tienen una relación uno-a-uno se determinan funcionalmente
entre sí.
Cuando se crea una base datos con atributos que tiene una relación uno-a-uno,
los dos atributos deben aparecer juntos cuando menos en una afinidad.
Relaciones de atributos muchos-a-uno
En la relación del asesor del ejemplo 2, SID determina a FID. Varios estudiantes
(SID) son asesorados por un miembro de la facultad. esta es una relación muchos
a uno.
Si A, B y C están en la misma afinidad y si A determina B, entonces A debe ser la
clave ( lo cual significa que también determina C).
Este enunciado se aplica en el diseño de la base de datos de la siguiente forma:
cuando se construye una afinidad, si A determina B los únicos atributos que se
pueden agregar a la afinidad, también deben estar determinados por A.
Relaciones de atributos muchos-a-muchos.
Si A no determina a B y B no determina a A entonces su relación a muchos-a-
muchos. En el ejemplo 2, NombreF y Clase tiene una relación de mucho a
muchos. Un profesor enseña muchas clases y una clase es impartida por varios
profesores.
Cuando se construyen afinidades que tienen atributos múltiples como claves, se
pueden agregar nuevos atributos que sean funcionalmente dependientes de todas
las claves. CantidadDeVecesEnseñadas es funcionalmente dependiente de
(NombreF, Clase) y puede agregarse a la afinidad. Sin embargo
OficinaDeFacultad no puede incluirse porque solo sería dependiente de NombreF,
no de clase. Si fuera necesario almacenar OficinaDeFacultad en la base de datos,
debe agregarse a la afinidad relacionada con la facultad, no a la que se refiere a
preparaciones.
Reglas para construir afinidades.
Referentes a las afinidades uno-a-uno.
Los atributos que tienen una relación uno-a-uno deben aparecer juntos, cuando
menos en una afinidad. Llame a esta afinidad R y a los atributos A y B.
A o B deben ser la clave de R.
Un atributo puede agregarse a R si está determinado funcionalmente por A o
B.
Un atributo que no está determinado funcionalmente por A o B no puede
agregarse a R.
A y B deben aparecer juntos en R, pero no deberán aparecer juntos en otras
afinidades.
A o B deben usarse consistentemente para representar el par en las afinidades
diferentes a R.
Referentes a relaciones muchos-a-uno
Los atributos que tienen una relación muchos-a-uno pueden existir juntos en
una afinidad. Suponga que C determina D en la afinidad S.
C debe ser la clave de S.
Un atributo puede agregarse a S si está determinado por C.
Un tributo que no esta determinado por C no puede agregarse a S.
Referente a las relaciones muchos-a-muchos.
Los atributos que tienen una relación muchos-a-muchos pueden existir juntos
en una afinidad. Suponga que dos de tales atributos, E y F, residen juntos en la
afinidad T.
La clave de T debe ser (E,F).
Un atributo puede agregarse a T, si está determinado por la combinación (E,F).
Un atributo no puede agregarse a T, si no está determinada por la combinación
(E,F).
Si agregar un nuevo atributo, G, expande la clave a (E,F,G), entonces el tema
de la afinidad ha sido cambiado. G no pertenece a T o el nombre de T debe
cambiarse para reflejar el nuevo tema.