MODELO DE DATOS INTRODUCCIN Desde tiempos remotos los datos han sido registrados por el hombre en algn tipo

de soporte (papel, piedra, madera, etc.) a fin de que quedara constancia de un fenmeno e idea. Los datos han de ser interpretados (incorporndoles significado) para que se conviertan en informacin til. Cuando utilizamos el lenguaje natural y decimos, por ejemplo, que una persona naci en 1965, el dato (1965) va acompaado de su interpretacin (ao de nacimiento de una cierta persona), sin embargo en la informtica, se separ el dato de su significado. Por ello, a fin de facilitar la interpretacin de los datos, surgen los modelos de datos como instrumentos que ayudan a incorporar significado a los datos. Segn FLORY (1982), modelar consiste en definir un mundo abstracto y terico 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 representacin organizacional de la empresa. Los modelos de datos proporcionan mecanismos de abstraccin que permiten la representacin de aquella parcela del mundo real cuyos datos nos interesa registrar, lo que habitualmente se denomina universo del discurso o mini-mundo segn DITTRICH (1994). Dicha representacin se concibe en dos niveles: el de las estructuras que hacen posible la representacin de la informacin, y el de la informacin en s misma. Estos dos niveles dan lugar, en el mbito de la base de datos, a la distincin entre esquema y base de datos; conceptos que DITTRICH (1994) define como: La descripcin especfica de un mini-mundo determinado, en trminos 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 coleccin de datos que en s misma representa la informacin del mini-mundo da lugar a la base de datos. Asociados a los modelos de datos estn 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 abstraccin Conceptual, Externo e Interno. El nivel global contiene una representacin del conjunto de los datos de una organizacin; 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 caractersticas de los datos tal como han de encontrarse almacenados fsicamente, siendo sus elementos de descripcin 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 (tambin denominados de alto nivel) facilitan la descripcin global del conjunto de informacin de la empresa al nivel ms prximo 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 estn orientados a describir los datos a nivel lgico para el SGBD, por lo que sus conceptos son tablas o relaciones en el caso del modelo relacional, redes en el Codasyl, jerarquas en el jerrquico, etc. En la figura 1 se muestra la clasificacin de los modelos de datos globales. CONCEPTUALES Enfocados a describir el mundo real MODELO DE DATOS GLOBALES CONVENCIONALES O LGICOS Implementados en SGBD

Jerrquicos Codasyl Realacional

Figura 1. Clasificacin de los modelos de datos globales

MODELO, ESQUEMA Y EJEMPLAR. La descripcin 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 descripcin 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 relacin 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 percepcin de una cierta realidad, y podr tener mltiples 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 trminos 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 mundo real

Modelo 1

Modelo i

Modelo n

Percepcin de una determinada realidad interpretada de acuerdo con un cierto modelo Valores que toma la percepcin de una cierta realidad (esquema) en un punto del tiempo

Esquema 1

Esquema i

Esquema n

Ejemplar 1

Ejemplar i

Ejemplar n

Figura 2. Relacin 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 segn las cuales han de ser estructurados los datos acerca del mundo real. La representacin de una determinada realidad mediante un modelo ( instrumento que nos facilita el proceso de representacin) da lugar a un esquema, el cual describe las categoras existentes en dicha realidad. Sin embargo, la realidad no contempla solo aspectos estticos, sino tambin propiedades dinmicas y estas han de ser tambin especificadas en operaciones de consulta y actualizacin de la base de datos.

Por lo tanto, podemos decir que las propiedades del mundo real son de dos tipos: Estticas, o relativamente invariantes en el tiempo, que responden a lo que suele entenderse como estructuras. Dinmicas, que son las operaciones que se aplican a los datos o valores almacenados en las estructuras, las cuales varan en el transcurso del tiempo al aplicrsele dichas operaciones. El modelo de datos debe proporcionar facilidades para recoger ambos aspectos. El componente esttico de un determinado modelo de datos expresado con una sintaxis es el Lenguaje de definicin de Datos ((LDD) y el componente dinmico el Lenguaje de Manipulacin 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 nmero de cdula. Cuando se disea una base de datos se desea que esta refleje lo ms fielmente posible el universo del discurso que estamos tratando de recoger en nuestro sistema de informacin, 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 tambin estas reglas llamadas restricciones semnticas o de integridad , las cuales pueden ser definidas como condiciones que limitan el conjunto de ejemplares vlidos de un esquema. La semntica y la integridad son conceptos que en las bases de datos suelen ir asociados, aunque no son idnticos. El trmino semntica se refiere al significado de los datos y el de integridad a la correccin 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 semntica del mundo real, ser posible comprobar si los valores de los datos se atienen o no a sta semntica previamente definida, comprobndose la integridad de los mismos.

LOS MODELOS DE DATOS EN EL PROCESO DE DISEO DE UNA BASE DE DATOS. Se conoce como proceso de diseo 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 desempean un papel importante en el proceso de diseo de una base de datos al ofrecernos facilidades de abstraccin que nos ayudan a representar la realidad. Los objetivos que persigue todo modelo de datos son de dos tipos: Formalizacin, ya que el modelo de datos permite definir formalmente las estructuras permitidas y las restricciones; tambin el modelo de datos establece la base para la definicin de un lenguaje de datos y facilita una apreciacin ms objetiva de la rigidez o flexibilidad de las estructuras de datos.

Diseo, ya que el modelo de datos es un elemento fundamental en el desarrollo de una metodologa de diseo de bases de datos, en el cual se basan los otros componentes de la metodologa (lenguajes, documentacin y otras herramientas). MUNDO REAL Universidad, Biblioteca, Departamento de formacin de una empresa, Hospital, Entidad bancaria, etc. Visin del mundo real bajo unos determinados objetivos Modelos conceptuales (Modelo EntidadRelacin, etc.)

UNIVERSO DEL DISCURSO

MODELADO CONCEPTUAL DE LOS DATOS

MODELADO LGICO (BASE DE DATOS)

Modelos Convencionales o de base de datos (Modelo Relacional, red, jerrquico, etc.) Modelos Internos (registros internos o almacenados, punteros, organizaciones secuenciales, indizadas, direccionadas, agrupamientos, etc.) Estructuras Fsicas (registros fsicos,bytes, bits, campos, items, etc.)

MODELADO INTERNO (ESTRUCTURAS DE DATOS)

ALMACENAMIENTO FISICO

Etapas en el diseo 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 teora matemtica de las relaciones, los datos se estructuran lgicamente en forma de relaciones (tablas). Este modelo asla al usuario de las estructuras fsicas de los datos, consiguiendo as la independencia de las aplicaciones respecto de los datos. La estructura bsica del modelo relacional es la relacin (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 relacin a la que pertenece.

RESTRICCIONES Integridad de una Entidad. Es una restriccin debida a la necesidad de que todas las tuplas de una relacin sean distintas, lo cual establece que: Ningn atributo que forme parte de la clave primaria puede tomar valore nulos. Valor nulo de un atributo representa informacin 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 relacin no podran ser identificadas, por lo que se violara la condicin 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 diseos independientes de DBMS. Segundo, el modelo relacional es la base de una importante categora 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 terminologa relacional Modelo Relacional Afinidad Tupla(Fila) Atributo Programador Archivo Registro Campo Usuario Tabla Fila 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 nmeros de empleados debe haber nmeros 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 idnticas 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 trmino afinidad.

Atributo 1 Nombre Tupla 1 Tupla 2 . . . . Tupla 7 Araujo Dvila Garca Jerez Moreno Nuez Salas

Atributo 2 Edad 21 22 22 21 19 20 19

Atributo 3 Sexo F M M F M F M

Atributo 4 NumerodeEmplea do 010110 010100 101000 201100 111100 111101 111111

Para entender el modelo relacional y la normalizacin se deben comprender dos trminos: dependencia funcional y clave. Dependencia Funcional. Una dependencia funcional es una relacin entre uno o ms 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 trminos ms 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 nmero de identificacin 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 notacin: SID Especialidad Esta expresin 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 sealado, una dependencia funcional es una relacin entre valores de atributos. Si SID determina Especialidad, un valor particular de SID har pareja slo con un valor de Especialidad. En sentido inverso, un valor de Especialidad puede hacer pareja con uno o ms valores diferentes de SID. Suponga que informtica 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 Informtica de Especialidad. Sin embargo lo opuesto no es cierto, pues la especialidad de Informtica puede hacer pareja con varios valores de SID (diversos estudiantes pueden tener especialidad en Informtica). se puede decir que la relacin de SID con Especialidad es muchos a uno (N:1). En general se puede decir que si A determina a B, la relacin de los valores de A a B es N:1. Las dependencias funcionales pueden involucrar grupos de atributos. Considere la afinidad CALIFICACIONES(SID, NombreDeClase, Calificacin). La combinacin

de un SID y un NombreDeClase determina una calificacin, una dependencia funcional que se escribe as: (SID, NombreDeClase) Calificacin Observe que tanto SID como NombreDeClase son necesarios para determinar una calificacin. No se puede subdividir la dependencia funcional porque SID no determina la calificacin por s mismo. Claves. Una clave es un grupo de uno o ms 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 slo en una actividad a la vez. Un valor de SID determina una hilera nica, de modo que es una clave. SID 100 150 175 200 Actividad Esqu Natacin Squash Natacin Cuota 200 50 50 50 Clave:SID

ACTIVIDAD(SID, Actividad, Cuota)

Las claves tambin 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, sera posible que un valor de SID apareciera en dos o ms hileras de la tabla y, por lo tanto, SID no identificara una sola hilera. Algunas combinaciones de atributos, tal vez (SID, Actividad) pueden ser requeridas. Hay un sutil pero importante punto en el prrafo 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 hiptesis, 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 combinacin es la clave, lo determina por completo la semntica fundamental de la base de datos. Se debe interrogar a los usuarios para resolver tales preguntas. Recuerde que todas las hiptesis hechas acerca de las dependencias funcionales, claves y similares, estn determinadas por los modelos mentales del usuario. NORMALIZACION. En el modelo relacional, como en los dems modelos de datos, el diseo de una base de datos se puede abordar de dos formas distintas: A. Obteniendo el esquema relacional directamente a partir de la observacin de nuestro universo del discurso, de forma que plasmemos nuestra percepcin del mismo en un conjunto de esquemas de relacin, los cuales

contendrn los atributos y las restricciones de integridad que representan los objetos y reglas que hemos podido captar en nuestro anlisis del mundo real. B. Realizando el proceso de diseo de dos fases, en la primera se lleva a cabo el diseo conceptual, por ejemplo en el modelo E-R, obtenindose el correspondiente esquema conceptual; en la segunda, ste se transforma en un esquema relacional, siguiendo unas determinadas reglas de transformacin. Estas relaciones que resultan de la observacin del mundo real o de la transformacin al modelo relacional del esquema E-R elaborado en la etapa de modelado conceptual, pueden presentar algunos problemas, derivados de fallos en la percepcin del universo del discurso, en el diseo 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. Ambigedades. Prdida de informacin. Prdidas de dependencias funcionales, es decir, de ciertas restricciones de integridad que dan lugar a interdependencias entre los datos. Existencias de valores nulos (inaplicables). Aparicin, en la base de datos, de estados que no son vlidos en el mundo real (anomalas de insercin, borrado y modificacin. Anomalas de Modificacin. No todas las afinidades son deseables. Una tabla que cumple la definicin mnima 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 anomalas de modificacin. Las anomalas pueden eliminarse volviendo a definir la afinidad en dos o ms 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 tambin el hecho de que esquiar cuesta $200. Esto se denomina anomala de eliminacin; 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 eliminacin se pierden hechos acerca de dos entidades. Puede usarse la misma afinidad para ilustrar una anomala de insercin. Suponga que se quiere almacenar el hecho de que Buceo Autnomo cuesta $175, pero no se pueden acceder estos datos en la afinidad ACTIVIDAD hasta que un estudiante tome Buceo Autnomo. Esta restriccin se llama una anomala de insercin. 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 anomalas de insercin y eliminacin, 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 100 150 175 200 Actividad Esqu Natacin Squash Natacin Actividad Esqu Natacin Squash Cuota 200 50 50

ESTU-ACT (SID, Actividad) Clave: SID

ACT-COST (Actividad, Cuota) 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 contendra 250, RACQUETBOL) pero debe hacerse?. Debera 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 restriccin se llama restriccin de integridad referencial. si la accin debe prohibirse, esta restriccin debe documentarse como parte del diseo del esquema. Durante la implementacin, se definir la restriccin para el DBMS si el producto en uso proporciona tales restricciones de verificacin. Si no, la restriccin debe imponerse a travs de programas de aplicacin. Clases de Afinidades. Las afinidades pueden clasificarse por los tipos de anomalas de modificacin a las cuales son vulnerables. En los aos setenta, los tericos relacionales investigaron estos tipos. Alguien encontraba una anomala, la clasificaba y pensaba en la forma de prevenirla. Cada vez que esto ocurra, mejoraban los criterios para disear las afinidades. Estas clases de afinidades y las tcnicas para prevenir las anomalas 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 tenan serias limitaciones. Ninguna teora garantizaba que una de ellas eliminara todas las anomalas: cada forma solo eliminaba algunas. Esta situacin cambi en 1981 cuando R. Fagin defini la forma normal dominio/clave (DK/NF), y est libre de todas las anomalas de modificacin, sin importar su tipo. Primera Formas Normal. Cualquier tabla de datos que cumpla con la definicin 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 idnticas, 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 anomalas de modificacin. 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 anomalas de eliminacin y de insercin. SID Actividad Cuota 100 Esqu 200 100 Golf 65 150 Natacin 50 175 Squash 50 200 Natacin 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 combinacin (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 habra anomalas de

modificacin si Cuota dependiera por completo de la clave. Para eliminar estas anomalas se debe separar la afinidad en dos afinidades. Esta situacin conduce a la definicin 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 estn determinadas por SID). A pesar de esto VIVIENDA tiene anomalas. Para eliminar las anomalas de una afinidad en segunda forma normal, debe quitarse la dependencia transitiva, lo que conduce a la definicin 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 EDIFCUOTA(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 Matemticas Marquez 150 Psicologa Jaimes 200 Matemticas Ramrez 250 Matemticas Marquez 300 Psicologa Perez 350 Matemticas Ramrez 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 asesora 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 combinacin (SID, Especialidad) determina NombreF y la combinacin (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. Tambin est en segunda forma normal, pues cualquier atributo que no es clave depende de toda la clave (sin importar cul clave candidata se seleccione). Tambin est en tercera forma normal porque no tiene dependencias transitivas. A pesar de todo esto, tiene anomalas de modificacin. Suponga que estudiante 300 deja la escuela. Si se quita la tupla Estudiante 300, se perder el hecho de que Perez imparte asesora en Psicologa. Esta es una anomala de eliminacin. En forma similar Cmo se almacena el hecho de que Alviarez asesora en Economa?. No es posible hasta que un estudiante se inscribe en tal materia. Esta es una anomala de insercin. Situaciones como la anterior conducen a la definicin 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 anomalas. Por ejemplo, las afinidades ESTU-ASE(SID,

NombreF) y ASE-MATERIA(NombreF, Materia) (MiembroDeLaFacultad, Materia) no tienen anomalas. SID NombreF NombreF Materia 100 Marquez Marquez Matemticas 150 Jaimes Jaimes Psicologa 200 Ramrez Ramrez Matemticas 250 Marquez Perez Psicologa 300 Perez 350 Ramrez Las afinidades en BCNF no tiene anomalas con respecto a las dependencias funcionales. Cuarta Forma Normal. Considere la afinidad ESTUDIANTE de la siguiente figura que muestra la relacin entre estudiantes, especialidad y actividades. SID Especialidad Actividad 100 Msica Natacin 100 Contabilidad Natacin 100 Msica Tenis 100 Contabilidad Tenis 150 Matemticas Carrera ESTUDIANTE (SID, Especialidad, Actividad) Clave: (SID, Especialidad, Actividad) Dependencia de valores mltiples 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 combinacin de los atributos (SID, Especialidad, Actividad). La estudiante 100 tiene su especialidad en msica y contabilidad y tambin participa en natacin y tenis. El estudiante 150 solo tiene especialidad en matemticas y participa en carrera. Cul es la relacin 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 tambin se aplica a la relacin entre SID y Actividad. Tal dependencia por atributos se denomina dependencia de valores mltiples. estas conducen a anomala de modificacin. 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 mltiples cuando una afinidad tiene al menos tres atributos, dos de los cuales poseen valores mltiples y sus valores dependen solo del tercer atributo. Para evitar la dependencia de valores mltiples se construyen dos afinidades, donde cada una almacena datos para solamente uno de los atributos de valores mltiples. Las afinidades ESTU-ESPECIALIDAD(SID, Especialidad) y ESTU-ACT(SID, Actividad) como se ve en la siguiente figura.

SID Actividad 100 Esqu 100 Natacin 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 mltiples. 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 prcticas. A continuacin se estudia una forma normal que garantiza que no habr anomalas de ningn tipo. Cuando se ponen las afinidades en esa forma, se sabe que no pueden ocurrir ni siquiera las extraas anomalas asociadas a la quinta forma normal. Forma Normal Dominio/Clave. Una afinidad est en DK/NF si cada restriccin en la afinidad es una consecuencia lgica de la definicin de las claves y dominios. Considere los trminos importantes en esta definicin: restriccin, clave y dominio. Una restriccin es cualquier regla que gobierna los valores estticos de atributos y que es precisa para establecer si es verdadera o no. Las reglas para editar, las restricciones de interrelacin, las dependencias funcionales y las dependencias de valores mltiples son ejemplos de restricciones. Una clave es el nico identificador de una tupla. Un dominio tiene una descripcin fsica y una descripcin semntica o lgica. La descripcin fsica es la serie de valores que puede tener el atributo y la descripcin lgica 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 cules afinidades pueden convertirse a DK/NF. Encontrar o disear las afinidades DK/NF es ms un arte que una ciencia. Se debe definir las afinidades de modo que las restricciones sean consecuencias lgicas de los dominios y las claves. Cuando no se pueda estas restricciones deben desarrollarse dentro de los programas de aplicacin que procesan la base de datos. A continuacin 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 dgito 1

SID 100 100 150

Especialidad Msica Contabilidad Matemticas

SID determina funcionalmente los otros tres atributos, de modo que SID es una clave. Suponga que tambin se sabe (a partir de la definicin de requerimientos) que Edificio Cuota y que SID no debe empezar con 1. Si se expresan estas condiciones como consecuencias lgicas de las definiciones de dominio y clave, se puede estar seguro, que no habr anomalas de modificacin. Definiciones de dominio SID IN CDDD, donde C es un dgito decimal 1 D = dgito 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 ensean. 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 ensear varias clases y asesorar a varios estudiantes, pero un estudiante es asesorado slo 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 normalizacin 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 ensea y el tercero se refiere al nmero de identificacin, 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=dgito decimal; NombreF IN CARAC (30)

Clase IN CARAC(10) SID IN CDDD, C es un dgito decimal 1 D=dgito 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 lgicas de las claves. La afinidad PREPARACION contiene la correspondencia de facultad y clases; muestra las clases que un profesor est preparado para ensear. La clave es la combinacin (NombreF, Clase). Se requieren ambos atributos en la clave porque un profesor puede ensear 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 mltiples. 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 0 parano graduadosde la facultad EstadoDeGradoDeFacultad 1 paragraduadosde la facultad

R S T

Esta afinidad contiene informacin 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 restriccin es que solo los miembros de la facultad de graduados estn 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= dgito decimal NombreF IN CARAC(30) EstadoDeGradoDeFacultad IN [0,1] GSID CDDD donde C=9; D= un dgito decimal, estudiante graduado NGSID IN CDDD, donde C 1 y C 9; D= un dgito 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 Caracterstica 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 mltiples 5NF No se describi en este anlisis DK/NF Todas las restricciones en las actividades son consecuencias lgicas de los dominios y las claves. La Sntesis de Afinidades Anteriormente se estudi el diseo relacional desde una perspectiva analtica. A continuacin estudiaremos el diseo relacional desde un punto de vista sinttico. Para esto se pregunta: dados una serie de atributos con ciertas dependencias funcionales qu afinidades se debern 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 relacin de atributos uno a uno 2. Uno determina al otro A B pero B no A Por lo tanto, A y B tiene una relacin de muchos a uno. 3. No estn relacionados funcionalmente. A no B y B no A Por lo tanto, A y B tiene una relacin de atributos muchos a muchos. En la siguiente tabla se muestran los tres tipos de relaciones de atributos. Tipo de relacin del atributo Uno-a-uno Muchos-aMuchos-auno muchos Definicin 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 relacin de sus valores de datos es uno-a-uno. Si dos atributos identifican de manera nica la misma cosa (entidad u objeto), la relacin de sus valores de datos es uno-a-uno. Si dos atributos tienen una relacin uno-a-uno se determinan funcionalmente entre s. Cuando se crea una base datos con atributos que tiene una relacin uno-a-uno, los dos atributos deben aparecer juntos cuando menos en una afinidad. Relaciones de atributos muchos-a-uno En la relacin del asesor del ejemplo 2, SID determina a FID. Varios estudiantes (SID) son asesorados por un miembro de la facultad. esta es una relacin muchos a uno. Si A, B y C estn en la misma afinidad y si A determina B, entonces A debe ser la clave ( lo cual significa que tambin determina C). Este enunciado se aplica en el diseo 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, tambin 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 relacin a muchos-amuchos. En el ejemplo 2, NombreF y Clase tiene una relacin de mucho a muchos. Un profesor ensea muchas clases y una clase es impartida por varios profesores. Cuando se construyen afinidades que tienen atributos mltiples como claves, se pueden agregar nuevos atributos que sean funcionalmente dependientes de todas las claves. CantidadDeVecesEnseadas es funcionalmente dependiente de (NombreF, Clase) y puede agregarse a la afinidad. Sin embargo OficinaDeFacultad no puede incluirse porque solo sera 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 relacin 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 debern 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 relacin 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 relacin 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 combinacin (E,F). Un atributo no puede agregarse a T, si no est determinada por la combinacin (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.