Descarga la aplicación para disfrutar aún más
Vista previa del material en texto
Gestión de Datos Mg. Ing. Gustavo E. Juárez FRT -UTN Gestión de Datos Departamento Sistemas Facultad Regional Tucumán Universidad Tecnológica Nacional PARTE I - Formas Normales Mg. Ing. Gustavo E. Juárez FRT -UTN Gestión de Datos Departamento Sistemas Facultad Regional Tucumán Universidad Tecnológica Nacional Normalización La teoría del modelo relacional y el proceso de normalización de las Bases de Datos, fue desarrollado por Edgar Frank Codd en sus papers: • “A relational model for large shared data banks” – ACM – 1970. • “Further normalization of the data base relational model” – RUSTIN – 1972. En estos papers investiga, identifica las causas y define las primeras tres “formas normales”. Comentario: Una relación es una forma normal específica si satisface el conjunto de requisitos o restricciones para dicha forma. Mg. Ing. Gustavo E. Juárez FRT -UTN Gestión de Datos Departamento Sistemas Facultad Regional Tucumán Universidad Tecnológica Nacional Normalización Introducción: Con el fin de corregir algunas redundancias y anomalías, EF Codd (1972) propuso tres formas normales, 1FN, 2FN y 3FN, logrado pérdida menores a causa del proceso de descomposición, (preservación de la dependencia) de la relación inicial universal en relaciones más pequeñas, sobre la base de las dependencias funcionales (FDS). Mg. Ing. Gustavo E. Juárez FRT -UTN Gestión de Datos Departamento Sistemas Facultad Regional Tucumán Universidad Tecnológica Nacional Normalización Poco después, Heath y Boyce y Codd (1974) identificaron algunas insuficiencias de la definición de 3FN, por lo que redefinieron la 3FN y se le cambió el nombre Forma Normal de BoyceCodd - FNBC. Ronald Fagin (1977) fue el primero en describir la cuarta forma normal, 4NF, basado en las dependencias multivaluadas - MVDS (Zaniolo, Fagin, Delobel), así como la quinta forma normal, 5NF (Fagin, 1979) o forma normal de proyección-enlace (PJ / NF), la cual se basa en unir dependencias (JDS). Mg. Ing. Gustavo E. Juárez FRT -UTN Gestión de Datos Departamento Sistemas Facultad Regional Tucumán Universidad Tecnológica Nacional Normalización – Tipos y Modelado de Datos Dependencias Funcionales Es un tipo de relación entre atributos Dependencias Multivaluadas Dos tuplas (A,m) donde A es un conjunto y m es una Función de A Inclusión Es la existencia de atributos en una tabla R, cuyos valores deben ser un subconjunto de valores de los atributos correspondientes en la otra tabla S Enlace / Join Una tabla de T está sujeta a una condición de enlace (JOIN) si T siempre se puede recrear al unirse varias Tablas, cada una con un subconjunto de los atributos de T Problemas Mg. Ing. Gustavo E. Juárez FRT -UTN Gestión de Datos Departamento Sistemas Facultad Regional Tucumán Universidad Tecnológica Nacional Normalización - Objetivos • Desarrollar una “buena” descripción de los datos, sus relaciones y sus restricciones. • Identificar un conjunto “adecuado” de relaciones. • Mejorar el Diseño Lógico. Mg. Ing. Gustavo E. Juárez FRT -UTN Gestión de Datos Departamento Sistemas Facultad Regional Tucumán Universidad Tecnológica Nacional Normalización - Propósitos • Producir un conjunto estable de relaciones que sea un modelo fiel de las operaciones de la empresa. • Lograr un diseño flexible que permita extender el modelo cuando se necesite representar nuevos atributos, conjuntos de entidades y relaciones. • Diseñar la base de datos fortaleciendo ciertos tipos de restricciones de integridad. • Reducir la redundancia en las bases de datos, para ahorrar espacio y en pos de evitar inconsistencias en los datos. ABSTRACCION ESCALABILIDAD ANOMALIA COMPLETITUD Mg. Ing. Gustavo E. Juárez FRT -UTN Gestión de Datos Departamento Sistemas Facultad Regional Tucumán Universidad Tecnológica Nacional Anomalías Definición: “Una anomalía es un estado inconsistente, incompleto o contradictorio de la base de datos“ (Ricardo). Una tabla que cumple con una mínima definición de relación puede no tener una estructura eficaz u apropiada. Si hubiera anomalías presentes en la relación, esta sería incapaz de representar cierta información, pudiendo perder información a partir de procesar actualizaciones, corriendo el riesgo de que los datos se vuelvan inconsistentes. Mg. Ing. Gustavo E. Juárez FRT -UTN Gestión de Datos Departamento Sistemas Facultad Regional Tucumán Universidad Tecnológica Nacional Tipificación de las Anomalías 1. Anomalías de Inserción: ocurre cuando no se puede ingresar una ocurrencia hasta que se tenga un hecho adicional acerca de otra entidad. 2. Anomalías de Modificación: ocurre cuando se modifica un valor, y no se verifican los valores ingresados, los que finalmente son consolidados en la base de datos. Una Solución a este problema posible es dividir la relación en dos relaciones. 3. Anomalías de Eliminación: ocurre cuando se elimina una tupla o un valor especifico, y este hecho afecta a otras entidades. Mg. Ing. Gustavo E. Juárez FRT -UTN Gestión de Datos Departamento Sistemas Facultad Regional Tucumán Universidad Tecnológica Nacional Anomalías de inserción, actualización y borrado Considere la siguiente relación: NewClass (classNo, stuId, stuLastName, facId, schedule, room, grade) Aclaraciones: • En este ejemplo se supone que solamente existe un miembro del personal docente para cada clase (esto es: no hay enseñanza en equipo). • Se supone que cada clase siempre tiene asignado el mismo salón. Mg. Ing. Gustavo E. Juárez FRT -UTN Gestión de Datos Departamento Sistemas Facultad Regional Tucumán Universidad Tecnológica Nacional Anomalías de inserción, actualización y borrado La tabla NewClass Anomalía de actualización. Suponga que quiere cambiar el horario de ART103A a MWF12. Es posible que pueda actualizar los dos primeros registros de la tabla NewClass, pero no el tercero, lo que resulta en un estado inconsistente en la base de datos. Entonces sería imposible decir el verdadero horario para dicha clase. Ésta es una anomalía de actualización. Mg. Ing. Gustavo E. Juárez FRT -UTN Gestión de Datos Departamento Sistemas Facultad Regional Tucumán Universidad Tecnológica Nacional Anomalías de inserción, actualización y borrado La tabla NewClass Anomalía de inserción. Ocurre cuando intenta agregar información acerca de un curso para el cual todavía no hay estudiantes registrados. Por ejemplo, suponga que crea una nueva clase, con valores MTH110A, F110, MTuTh10, H225 para classNumber, facId, schedule y room. No es posible registrar la información del curso, aun cuando tenga los valores para estos atributos. Dado que la clave es {courseNo,stuId}, no tiene permiso para insertar un registro con un valor nulo para stuId. Puesto que no tiene posibilidad de representar esta información de clase, tiene una anomalía de inserción. MTH110A Mg. Ing. Gustavo E. Juárez FRT -UTN Gestión de Datos Departamento Sistemas Facultad Regional Tucumán Universidad Tecnológica Nacional Anomalías de inserción, actualización y borrado La tabla NewClass Anomalía de borrado. Cuando borra el registro del único estudiante que toma un curso particular, ocurre una anomalía de borrado. Por ejemplo, si el estudiante S1001 se retira de HST205A, perdería toda la información acerca de dicho curso. Sería deseable conservar la información del curso, pero no puede hacerlo sin un stuId correspondiente. De igual modo, si un estudiante abandona el único curso que toma, se pierde toda la información acerca de dicho estudiante. Mg. Ing. Gustavo E. Juárez FRT -UTN Gestión de Datos Departamento Sistemas Facultad Regional Tucumán Universidad Tecnológica Nacional Formas Normales Las relacionesse pueden clasificar por tipo de anomalías de modificación a las cuales son vulnerables. En la Década de 1970 los teóricos relacionales investigaron acerca de estos tipos. Cuando alguno encontraba una anomalía, la clasificaba y pensaba en una manera de prevenirla, las cuales con el tiempo y luego de estudiar numerosas ocurrencias, recibieron el nombre de Formas Normales. Mg. Ing. Gustavo E. Juárez FRT -UTN Gestión de Datos Departamento Sistemas Facultad Regional Tucumán Universidad Tecnológica Nacional Formas Normales Tanto para el Análisis Conceptual como para el desarrollo del Modelo Lógico, es necesario considerar ciertas especificaciones que faciliten el trabajo con las Tablas. En este sentido, Sommerville (1988) dijo " un buen diseño, es la clave de una eficiente ingeniería del software. Un software bien diseñado es fácil de aplicar y mantener, además de ser comprensible y fiable. Sistemas mal diseñados, aunque puedan funcionar, serán costosos de mantener”. . Mg. Ing. Gustavo E. Juárez FRT -UTN Gestión de Datos Departamento Sistemas Facultad Regional Tucumán Universidad Tecnológica Nacional Formas Normales Codd mediante la publicación de trabajos como “A relational model for a large shared data banks”, y “Further normalization of the data base relational model”, definió las 1FN, 2FN y 3FN (Primera, Segunda y Tercera Forma Normal). Más tarde, otros autores continuaron investigando los patrones de anomalías que ocurrían en las Bases de Datos y especificaron las siguientes formas normales: Mg. Ing. Gustavo E. Juárez FRT -UTN Gestión de Datos Departamento Sistemas Facultad Regional Tucumán Universidad Tecnológica Nacional Restricciones Para que una tabla sea una relación debe cumplir con ciertas restricciones: 1. Las celdas deben ser de un valor único. No se puede tener ni repetir grupos ni tener series en calidad de valores. 2. Todas las entradas en una misma columna deben ser del mismo tipo. 3. Cada columna tiene un nombre único y el orden en las columnas en la tabla no es importante. 4. Dos renglones en la tabla no pueden ser idénticos y el orden de los renglones no tiene importancia. PRIMERA FORMA NORMAL (PFN o 1FN) Mg. Ing. Gustavo E. Juárez FRT -UTN Gestión de Datos Departamento Sistemas Facultad Regional Tucumán Universidad Tecnológica Nacional MARCO HISTORICO DE LAS FORMAS NORMALES Formas Normales Definida por Primera Forma Normal (1NF) E.F. Codd (1970) C.J. Date (2003) Segunda Forma Normal (2NF) E.F. Codd (1971) Tercera Forma Normal (3NF) E.F. Codd (1971) Forma Normal de Boyce-Codd (BCNF) Raymond F. Boyce and E.F. Codd (1974) Cuarta Forma Normal (4NF) Ronald Fagin(1977) Quinta Forma Normal (5NF) Ronald Fagin (1979) Forma Normal de Dominio Clave (DKNF) Ronald Fagin (1981) Sexta Forma Normal (6NF) C.J. Date, Hugh Darwen y Nikos Lorentzos (2002) Mg. Ing. Gustavo E. Juárez FRT -UTN Gestión de Datos Departamento Sistemas Facultad Regional Tucumán Universidad Tecnológica Nacional Formas Normales Es posible entender mejor el proceso de normalización mediante la utilización de conjuntos incluidos unos de otros, en donde las formas normales se encuentran anidadas con un mismo centro. El objetivo del diseño debe ser poner el esquema en la forma normal más alta, que es práctica y adecuada para los datos en la base de datos. La normalización requiere tener en claro la semántica del modelo. Mg. Ing. Gustavo E. Juárez FRT -UTN Gestión de Datos Departamento Sistemas Facultad Regional Tucumán Universidad Tecnológica Nacional Formas Normales – Dependencias Funcionales Definición: “Si R es un esquema de relación, y A y B son conjuntos de atributos no vacíos en R, se dice que B es funcionalmente dependiente en A si y sólo si cada valor de A en R tiene asociado exactamente un valor de B en R” Esto se escribe como A → B que se lee como “A determina funcionalmente a B”. Una dependencia funcional es en realidad una relación muchos a uno del conjunto de atributos A al conjunto de atributos B Mg. Ing. Gustavo E. Juárez FRT -UTN Gestión de Datos Departamento Sistemas Facultad Regional Tucumán Universidad Tecnológica Nacional Para describir la primera forma normal se usará un contraejemplo. Si supone que a un estudiante se le permite tener más de una especialidad, y se intenta almacenar especialidades múltiples en el mismo campo del registro del estudiante, la tabla NewStu puede parecerse a la que muestra la Figura. Este ejemplo viola la definición de la primera forma normal. PRIMERA FORMA NORMAL (PFN o 1FN) Mg. Ing. Gustavo E. Juárez FRT -UTN Gestión de Datos Departamento Sistemas Facultad Regional Tucumán Universidad Tecnológica Nacional Definición 1FN: “Una relación está en la primera forma normal (1FN) si y sólo si cada atributo tiene valor sencillo para cada tupla”. Esto significa que cada atributo en cada fila, o cada “celda” de la tabla, contiene sólo un valor. Una forma alternativa de describir la primera forma normal es decir que los dominios de los atributos de la relación son atómicos. Esto significa que en el dominio no se permiten conjuntos, listas, campos repetidos o grupos. PRIMERA FORMA NORMAL (PFN o 1FN) Mg. Ing. Gustavo E. Juárez FRT -UTN Gestión de Datos Departamento Sistemas Facultad Regional Tucumán Universidad Tecnológica Nacional Los valores en el dominio deben ser valores únicos que no se puedan descomponer más. En la Figura se ve la violación de esta regla en los registros de los estudiantes S1006 y S1010, quienes ahora tienen dos valores mencionados para major. PRIMERA FORMA NORMAL (PFN o 1FN) Mg. Ing. Gustavo E. Juárez FRT -UTN Gestión de Datos Departamento Sistemas Facultad Regional Tucumán Universidad Tecnológica Nacional PRIMERA FORMA NORMAL (PFN o 1FN) Mg. Ing. Gustavo E. Juárez FRT -UTN Gestión de Datos Departamento Sistemas Facultad Regional Tucumán Universidad Tecnológica Nacional Definición Dependencia Funcional: “En una relación R, el atributo A de R es completamente dependiente funcional sobre un atributo o conjunto de atributos X de R si A es funcionalmente dependiente sobre X pero no funcionalmente dependiente sobre cualquier subconjunto propio de X". SEGUNDA FORMA NORMAL (SFN o 2FN) Mg. Ing. Gustavo E. Juárez FRT -UTN Gestión de Datos Departamento Sistemas Facultad Regional Tucumán Universidad Tecnológica Nacional Dependencia funcional completa y Segunda Forma Normal (SFN o 2FN) Para la relación que se muestra en la Figura, se tienen las siguientes dependencias funcionales además de las triviales: SEGUNDA FORMA NORMAL (SFN o 2FN) {courseNo, stuId} → {stuLastName} {courseNo, stuId} → {facId} {courseNo, stuId} → {schedule} {courseNo, stuId} → {room} {courseNo, stuId} → {grade} Mg. Ing. Gustavo E. Juárez FRT -UTN Gestión de Datos Departamento Sistemas Facultad Regional Tucumán Universidad Tecnológica Nacional Dado que no hay otra clave candidata, se elige {courseNo, stuId} para la clave primaria. De nuevo, al ignorar las dependencias funcionales triviales, también se tienen las dependencias funcionales courseNo → facId courseNo → schedule courseNo → room stuId → lastName De modo que se encuentran atributos que son funcionalmente dependientes en la combinación {courseNo, stuId}, pero también funcionalmente dependientes en un subconjunto de dicha combinación. Se dice que tales atributos no son por completo dependientes funcionales de la combinación. SEGUNDA FORMA NORMAL (SFN o 2FN) Mg. Ing. Gustavo E. Juárez FRT -UTN Gestión de Datos Departamento Sistemas Facultad Regional Tucumán Universidad Tecnológica Nacional Definición 2FN: “Una relación está en segunda forma normal (2FN) si y sólo si está en primeraforma normal y todos los atributos no clave son completamente dependen completamente de la clave”. Claro está, si una relación es 1FN y la clave consiste en un solo atributo, la relación es automáticamente 2FN. Tiene que preocuparse por 2FN sólo cuando la clave sea compuesta. SEGUNDA FORMA NORMAL (SFN o 2FN) Mg. Ing. Gustavo E. Juárez FRT -UTN Gestión de Datos Departamento Sistemas Facultad Regional Tucumán Universidad Tecnológica Nacional Una relación 1FN que no es 2FN se puede transformar en un conjunto equivalente de relaciones 2FN. La transformación se efectúa al realizar proyecciones sobre la relación original en tal forma que es posible regresar al original al tomar la combinación de las proyecciones. SEGUNDA FORMA NORMAL (SFN o 2FN) Mg. Ing. Gustavo E. Juárez FRT -UTN Gestión de Datos Departamento Sistemas Facultad Regional Tucumán Universidad Tecnológica Nacional Dependencia funcional completa y Segunda Forma Normal (SFN o 2FN) Es importante notar que, cuando se usa esta notación menos formal, los atributos a la derecha de la flecha se pueden “descomponer” y citar como DF separadas, pero los atributos en el lado izquierdo deben permanecer unidos, pues es su combinación la que es determinante. Las dependencias funcionales son SEGUNDA FORMA NORMAL (SFN o 2FN) courseNo → facId, schedule, room stuId → lastName courseNo,stuId → grade facId, schedule, room, lastName Mg. Ing. Gustavo E. Juárez FRT -UTN Gestión de Datos Departamento Sistemas Facultad Regional Tucumán Universidad Tecnológica Nacional Al usar proyección, se descompone la relación NewClass en el siguiente conjunto de relaciones: Register (courseNo, stuId, grade) Stu (stuId, stuLastName) Class2 (courseNo, facId, schedule, room) . SEGUNDA FORMA NORMAL (SFN o 2FN) Mg. Ing. Gustavo E. Juárez FRT -UTN Gestión de Datos Departamento Sistemas Facultad Regional Tucumán Universidad Tecnológica Nacional Aunque las relaciones de la segunda forma normal son mejores que las de la primera forma normal, todavía pueden tener anomalías de actualización, inserción y borrado. Considere la siguiente relación: NewStudent (stuId, lastName, major, credits, status) La Figura muestra una instancia de esta relación. Aquí, la única clave candidata es stuId y se usará como la clave primaria. Todo otro atributo de la relación es funcionalmente dependiente de la clave, así que se tiene la siguiente dependencia funcional, entre otras, stuId → credits TERCERA NORMAL (TFN o 3FN) Mg. Ing. Gustavo E. Juárez FRT -UTN Gestión de Datos Departamento Sistemas Facultad Regional Tucumán Universidad Tecnológica Nacional Sin embargo, dado que el número de créditos determina el status, también se tiene credits → status Por tanto, stuId de manera funcional determina status en dos formas, directa y transitivamente, a través del atributo no clave status. Al usar transitividad se tiene (stuId → credits) ∧ (credits →status)⇒ (stuId → status) TERCERA NORMAL (TFN o 3FN) Mg. Ing. Gustavo E. Juárez FRT -UTN Gestión de Datos Departamento Sistemas Facultad Regional Tucumán Universidad Tecnológica Nacional Definición Dependencia Transitiva: “Si A, B y C son atributos de la relación R, tales que A → B y B → C, entonces C es transitivamente dependiente de A”. Para la Tercera Forma Normal se quiere eliminar ciertas dependencias transitivas. Las dependencias transitivas causan anomalías de inserción, borrado y actualización. TERCERA NORMAL (TFN o 3FN) Mg. Ing. Gustavo E. Juárez FRT -UTN Gestión de Datos Departamento Sistemas Facultad Regional Tucumán Universidad Tecnológica Nacional Debido a estos problemas, es deseable remover las dependencias transitivas y crear un conjunto de relaciones que satisfagan la siguiente definición. Definición 3FN: “Una relación está en tercera forma normal (3FN) si, siempre que exista una dependencia funcional no trivial X → A, entonces o X es una superclave o A es un miembro de alguna clave candidata”. TERCERA NORMAL (TFN o 3FN) Mg. Ing. Gustavo E. Juárez FRT -UTN Gestión de Datos Departamento Sistemas Facultad Regional Tucumán Universidad Tecnológica Nacional Las características de la tercera forma normal implican que cada atributo no clave debe depender de la clave, toda la clave y nada más que la clave. Al comprobar la tercera forma normal, se busca si algún atributo no clave candidata (o grupo de atributos) es funcionalmente dependiente de otro atributo no clave (o grupo). Si existe tal dependencia funcional, se remueve de la relación el atributo funcionalmente dependiente, y se le coloca en una nueva relación con su determinante. El determinante puede permanecer en la relación original. TERCERA NORMAL (TFN o 3FN) Mg. Ing. Gustavo E. Juárez FRT -UTN Gestión de Datos Departamento Sistemas Facultad Regional Tucumán Universidad Tecnológica Nacional Dependencia Transitiva y Tercera Forma Normal (TFN o 3FN) Para el ejemplo NewStudent, dado que la dependencia indeseable es credits → status, y status no es parte de alguna clave candidata, se forma el conjunto de relaciones: NewStu2 (stuId, lastName, major, credits) Stats (credits, status) TERCERA NORMAL (TFN o 3FN) Mg. Ing. Gustavo E. Juárez FRT -UTN Gestión de Datos Departamento Sistemas Facultad Regional Tucumán Universidad Tecnológica Nacional De hecho, se puede decidir no almacenar status en la base de datos, y calcular el status para aquellas vistas que la necesiten. En este caso, simplemente se elimina la relación Status. Este ejemplo no involucra múltiples claves candidatas. Si en la relación original se tiene una segunda clave candidata, socialSecurityNumber, se tendría socialSecurityNumber → status TERCERA NORMAL (TFN o 3FN) Mg. Ing. Gustavo E. Juárez FRT -UTN Gestión de Datos Departamento Sistemas Facultad Regional Tucumán Universidad Tecnológica Nacional Compendio de Formas Normales Integración de conocimientos adquiridos Mg. Ing. Gustavo E. Juárez FRT -UTN Gestión de Datos Departamento Sistemas Facultad Regional Tucumán Universidad Tecnológica Nacional Definición 1FN: “Una relación está en la primera forma normal (1FN) si y sólo si cada atributo tiene valor sencillo para cada tupla”. Definición Dependencia Funcional: “En una relación R, el atributo A de R es completamente dependiente funcional sobre un atributo o conjunto de atributos X de R si A es funcionalmente dependiente sobre X pero no funcionalmente dependiente sobre cualquier subconjunto propio de X". Definición 2FN: “Una relación está en segunda forma normal (2FN) si y sólo si está en primera forma normal y todos los atributos no clave son completamente dependientes funcionales sobre la clave”. Compendio de Formas Normales Mg. Ing. Gustavo E. Juárez FRT -UTN Gestión de Datos Departamento Sistemas Facultad Regional Tucumán Universidad Tecnológica Nacional Definición Dependencia Transitiva: “Si A, B y C son atributos de la relación R, tales que A → B y B → C, entonces C es transitivamente dependiente de A”. Definición 3FN: “Una relación está en tercera forma normal (3FN) si la relacion esta en Segunda Forma Normal (2FN), siempre que exista una dependencia funcional no trivial X → A, entonces o X es una superclave o A es un miembro de alguna clave candidata”. Compendio de Formas Normales Mg. Ing. Gustavo E. Juárez FRT -UTN Gestión de Datos Departamento Sistemas Facultad Regional Tucumán Universidad Tecnológica Nacional Referencias • Paper “A relational model for a large shared data banks”, E. F. Codd. • Libro “Fundamentos de Bases de Datos”, Rovarini P., De La Vega H. • Libro “Sistemas de Bases de Datos. Conceptos Fundamentales”, R. Elmasrhi – S. Navathe. 2ª Edic. Edit . Addison – Wesley. • Faculta de Ingeniería. Universidadde Talca (CHI). http://ing.utalca.cl/~jperez/bd/documentos/al.pdf Mg. Ing. Gustavo E. Juárez FRT -UTN Gestión de Datos Departamento Sistemas Facultad Regional Tucumán Universidad Tecnológica Nacional Apuntes del Mg. Ing. Gustavo E. Juárez FRT -UTN Gestión de Datos Departamento Sistemas Facultad Regional Tucumán Universidad Tecnológica Nacional
Compartir