Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Formas Normales en Bases de Datos

No description
by

David Giménez

on 9 April 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Formas Normales en Bases de Datos

Universidad ORT Uruguay
Facultad de Ingeniería
Licenciatura en Sistemas Cátedra de Base de Datos
“Formas Normales” David Giménez
4.206.489-8
162027 PREGUNTAS QUE INTENTA RESPONDER ESTE TRABAJO: Como surgieron? Desde el ingreso de la informática en los procesos operaciones del gobierno y de las empresas, se utilizaron bases de datos, aunque en diferentes formas, para el respaldo y acceso posterior de la información.

Durante las décadas de los 60’s y 70’s muchos proveedores generaron sistemas generalizados de manejo de archivos, generando mucha diversidad en el campo, sin estandarización aceptada. En este tiempo la mayoría de las bases de datos se basan en un modelo de red o una simple estructura de archivo plano.

Se toma como disciplina de estudio los manejadores de bases de datos, de forma de porder lograr un estándar. Alguien sin mucha experiencia en base de datos podría definir una tabla como la que sigue: Este diseño presenta múltiples problemas:
•Hay información que no es almacenada o distinguida por la relación. Como quien es jefe y quien es empleado.
•Hay datos repetidos que pueden guardar inconsistencias. A quien le pertenece la cédula 1? Son las misma persona?
•Hay atributos que no almacenan ningún dato o permiten almacenar cualquier dato. El encabezado "Teléfono" llega a ser semánticamente difuso, puede representar un número de teléfono, una lista de números de teléfono, o de hecho cualquier cosa.
•Una consulta como "¿Qué pares de Técnicos comparten un número telefónico?" es virtualmente imposible de formular.
•Con este diseño es imposibles definir restricciones claras para los atributos. Este diseño presenta múltiples problemas: •Hay información que no es almacenada o distinguida por la relación. Como quien es jefe y quien es empleado? •Hay datos repetidos que pueden guardar inconsistencias. A quien le pertenece la cédula 1? Son las misma persona? •Hay atributos que no almacenan ningún dato o permiten almacenar cualquier dato. El encabezado "Teléfono" llega a ser semánticamente difuso, puede representar un número de teléfono, una lista de números de teléfono, o de hecho cualquier cosa. •Una consulta como "¿Qué pares de Técnicos comparten un número telefónico?" es virtualmente imposible de formular. •Con este diseño es imposibles definir restricciones claras para los atributos. Edgar Frank Codd definió las tres primeras formas normales. Estas se pueden resumir requiriendo que todos los atributos no-clave sean dependientes en "la clave, la clave completa, y nada excepto la clave".

Las cuarta y quinta formas normales se ocupan específicamente de la representación de las relaciones muchos a muchos y uno muchos entre los atributos. Cuáles son las formas normales? Y como aplicarlas? PRIMERA FORMA NORMAL Las tablas como representaciones fiel de una relación Edgar Frank Codd (Ted Codd) Científico informático inglés (23 de agosto de 1923 - 18 de abril de 2003), conocido por sus aportes a la teoría de bases de datos relacionales. En las décadas de los sesenta y los setenta trabajó en sus teorías sobre modelado de datos, publicando su trabajo "Un modelo relacional de datos para grandes bancos de datos compartidos" ("A Relational Model of Data for Large Shared Data Banks") en 1970. Para su descontento, IBM no se apresuró a explotar sus sugerencias hasta que no empezaron a ser puestas en práctica por rivales comerciales. Por ejemplo, Larry Ellison diseñó la base de datos Oracle basándose en las ideas de Codd.
Codd continuó expandiendo y desarrollando su modelo relacional, en ocasiones en colaboración con Chris Date. También trabajó el área de los autómatas celulares, sobre la que versó su tesis doctoral.
Codd definió las tres primeras Formas Normales que se aplican para la normalización de sistemas de bases de datos. Además, la Forma normal de Boyce-Codd lleva el nombre en su honor.
También acuñó el término OLAP y redactó las doce leyes del procesamiento analítico informático. Grupos repetidos Esto es "lo que para la mayoría se entiende como la característica que define la 1FN” La 1FN prohíbe a un campo contener más de un valor de su dominio de columna En el ejemplo mencionado se muestra la repetición de grupos para guardar múltiples números telefónicos para algunos técnicos.

La manera más simple es permitir que el campo "Teléfono" contenga más de un valor en cualquier registro dado. Esta representación presenta los siguientes problemas. •Dificultad en hacer consultas a la tabla. Es difícil contestar preguntas tales como "¿Qué empleados tienen el teléfono X?" y "¿Qué empleados comparten un número de teléfono?".

•La imposibilidad de hacer cumplir la unicidad las relaciones Cliente-a-Teléfono por medio del RDBMS. Al empleado 2 se le puede dar equivocadamente un valor para el Teléfono 2 que es exactamente igual que el valor de su Teléfono 1. Y eso que significaría?.

•Restringe la realidad en cuanto a la cantidad de teléfono por empleados a dos. Si viene un empleado con cuatro números de teléfono, estamos obligados a guardar solamente dos y dejar los restantes sin guardar. Esto significa que el diseño de la base de datos está imponiendo restricciones al proceso del negocio, en vez de a la inversa como debe ser. •Como surgieron las Formas Normales? •Que son las formas normales? •Que beneficios brinda su aplicación? •Cuáles son las formas normales? •Caso de estudio que permita el desarrollo del tema. •Caso de la vida real: Base de datos distribuida de DNS •Como aplicarlas? ? ? El modelo relacional de Codd estaba basado en una teoría de conjuntos matemáticos que servía para múltiples propósitos: •Abstraer la representación de datos de su almacenaje físico y manipularlos.

•Minimizar la redundancia de datos, dividiéndolos en distintos grupos no duplicados que pueden ser relacionados en un infinito número de formas para producir un infinito número de representaciones.

•Incrementar la consistencia de datos, por ejemplo si se cambia el nombre de un cliente, este cambiara en todos los reportes que se hagan acerca de ese cliente, porque esa parte es guardada en una sola parte pero genera varias vistas o representaciones del dato. (A U B) - (A B) (x - a) + (y - b) = r 2 2 2 U Con el modelo de las bases de datos relacionales cobraron mayor fuerza y se desarrollaron varios manejadores Codd definió reglas matemáticas que debían cumplir los datos dentro de una base de datos relacional para que estos fueran confiables y seguros. A estas reglas se les denomina formas normales. Siendo Codd quien definió las primeras 3 formas normales. Que son las formas normales?
Y
Que beneficios brinda su aplicación? Las FN son reglas matemáticas que se basan en la teoría de conjuntos que dan garantía de que en las relaciones representadas no ocurren anomalías de actualización ni existe perdida de información ni de dependencias entre los datos.

Son criterios para determinar el grado de vulnerabilidad de una tabla a inconsistencias y anomalías lógicas. Mientras más alta sea la forma normal aplicable a una tabla, es menos vulnerable a inconsistencias y anomalías. Las formas normales proveen a los diseñadores de bases de datos de lo siguiente: •Un marco formal para analizar los esquemas de relación con base en sus calves y en las dependencias funcionales entre sus atributos.

•Una serie de pruebas que pueden efectuarse sobre esquemas de relación individuales de modo que la base de datos relacional pueda normalizarse hasta el grado deseado. La aplicación de las formas normales no ayudan a: • Reducir valores redundantes en las tuplas.

• Evitar valores contradictorios en las tuplas.

• Evitar incoherencia de datos.

• Reducir valores nulos en las tuplas.
• Mejorar la semántica de los atributos.

• Evitar reuniones de datos aditivas, es decir con datos no correspondientes o erróneos.

• Evitar pérdidas de datos en las reuniones de diferentes relaciones. Como aplicar las formas normales? HNF:
Highest Normal Form
de la Tabla 1 Las formas normales son aplicables a tablas individuales. TABLA 1 TABLA 2 TABLA 3 En 2FN En 3FN En 4FN 1FN 2FN Una tabla satisface los requisitos de su HNF y de todas las formas normales inferiores. Entonces se considera que una base de datos se encuentra en una forma normal N, si todas sus tablas satisfacen los requisitos de esa esa forma normal N. Es decir la HNF de cada tabla es igual o superior a N. 3FN
Y
BOYCE - CODD 4 FN 5 FN NO es necesario comenzar por la 1ra, pasar a la 2da, luego a la 3ra y así sucesivamente.

En realidad se podría realizar un primer diseño cuya HNF sea la 4ta o 5ta formal normal. Caso de estudio:

Supongamos entonces el caso de una base de datos que desea guardar la información de los técnicos y los proyectos en los que trabajan. TÉCNICOS PROYECTOS TP Indicando además que las personas que se encuentran en los primeros diez lugares son jefes, y el resto son empleado. Una tabla en 1FN satisface un conjunto mínimo de criterios: •La tabla es una representación fiel de una relación.
•La tabla está libre de "grupos repetitivos". Según la definición de Christopher Date (nacido en 1941) una tabla debe ser “isomorfa a alguna relación", lo que significa, específicamente, que satisface las siguientes cinco condiciones: 1. No hay orden de arriba a abajo en las filas.
2. No hay orden de izquierda a derecha en las columnas.
3. No hay filas duplicadas.
4. Cada intersección de fila y columna contiene exactamente un valor del dominio aplicable (y nada más).
5. Todas las columnas son regulares (es decir, las filas no tienen componentes como IDs de fila, como los números en las filas de Excel). La violación de cualquiera de estas condiciones significaría que la tabla no es estrictamente relacional, y por lo tanto no está en 1FN Una primera aproximación al problema podría ser como sigue. Atomicidad Codd hace referencia al concepto de atomicidad. Indica que "se requiere que los valores sean atómicos con respecto al DBMS en los dominios en los que cada relación es definida”.

Define un valor atómico como uno que "no puede ser descompuesto en pedazos más pequeños por el DBMS (excepto por ciertas funciones especiales)”. La atomicidad debe ser considerara en base al concepto representado. En el ejemplo de los números de teléfonos, la atomicidad estaría dada porque cada campo contuviese un único número de teléfono y no varios. Un diseño conforme con 1FN Un analista con poca experiencia podría sugerir una solución como la siguiente: La cual se encuentra inequívocamente en 1 FN. Tecnicos TelefonosTecnicos TiposTelefonos TecnicosUniversidades TecnicosHabilidades Cedula
Tecnico

Claves candidatas: {Cedula} Cedula
Telefono
idTipoTelefono

Claves candidatas:
{Cedula, Telefono} idTipoTelefono
TipoTelefono

Claves candidatas:
{idTipoTelefono},
{TipoTelefono} Cedula
RUTUniversidad
Universidad

Claves candidatas:
{Cedula, RutUniversidad},
{Cedula, Universidad} Cedula
Habilidad
LugarDeResidencia

Claves candidatas:
{Cedula, Habilidad} Equipos TecnicosEquiposProyectos Proyectos ProyectosSupervisores Codigo
Equipo

Claves candidatas: {Codigo} Cedula
Codigo
CodProy

Claves candidatas: {Cedula, Codigo, CodProy} CodProy
Proyecto


Claves candidatas: {CodProy} CodProy
Año
Supervisor
Experiencia

Claves candidatas: {CodProy, Año} SEGUNDA FORMA NORMAL La segunda forma normal se basa en el concepto de dependencia funcional. Una tabla está en 2NF si y solo si, todas los atributos no primos dependen de toda la clave candidata y no solo una parte de ella.

Entiéndase como atributo no primo o principal como uno que no pertenece a ninguna clave candidata. En términos levemente más formales: una tabl en 1NF está en 2NF si y solo si ninguno de sus atributos no principales son funcionalmente dependientes en una parte (subconjunto propio) de una clave candidata. Aquí debemos entender claramente el concepto de dependencia funcional. X -> Y. esto indica que un atributo o conjunto de atributos X definen a un atributo o conjunto de atributos Y. El reciproco no tiene por qué ser verdadero, es mas es probable que no lo sea (Y -> X). Entiéndase que la dependencia es en base a la semántica de la realidad representada, aunque también pueden inferirse dependencias funcionales que no son semánticamente obvias. Aquí debemos entender claramente el concepto de: Dependencia Funcional: X -> Y Esto indica que un atributo o conjunto de atributos X definen a un atributo o conjunto de atributos Y.

Entiéndase que la dependencia es en base a la semántica de la realidad representada, aunque también pueden inferirse dependencias funcionales que no son semánticamente obvias. Cédula -> {Nombre_Persona} El nombre de la persona depende funcionalmente de la cédula de la persona. Es decir que el valor del campo Cédula determina de manera única o funcionalmente el nombre de la persona. RUT -> {Empresa, Dirección, Teléfono} Aquí el campo RUT identifica de manera única a los datos de una empresa, sea su nombre, dirección y teléfono. Es decir que cada uno de estos campos depende funcionalmente del valor del campo RUT. EJEMPLO: IMPORTANTE: Cuando una tabla en 1NF no tiene ninguna clave candidata compuesta (claves candidatas consistiendo en más de un atributo), la tabla está automáticamente en 2NF. En el ejemplo trabajado, en la tabla TecnicoHabilidad, el campo LugarDeResidencia presenta varios problemas:

•Si un técnico posee más de una habilidad el valor de lugar de residencia aparecería repetido y podría ser vulnerable a anomalías de actualización.

De ser así, los datos resultantes implicarían respuestas contradictorias a la pregunta "¿Cuál es el lugar de residencia del técnico X?".

•Además el dato "lugar de residencia" es semanticamente dependiente de la cédula del técnico y no de la habilidad que posea, por lo que depende solamente de parte de la clave y no de toda la clave. Por lo tanto esta relación no está en 2FN Tecnicos Cedula
Tecnico
LugarDeResidencia

Claves candidatas: {Cedula} Cedula
Habilidad

Claves candidatas:
{Cedula, Habilidad} Un alternativa conforme a 2NF de este diseño representaría la misma información en dos tablas: TecnicosHabilidades Estas tablas están en 2NF IMPORTANTE:

Una tabla para la cual no hay dependencias funcionales parciales en la clave primaria está típicamente, pero NO siempre, en 2NF.

Además de la clave principal, la tabla puede contener otras claves candidatas; es necesario establecer que ningún atributo no-principal tienen dependencias de clave parciales en cualesquiera de estas claves candidatas. Ejemplo de KP: {Nombre completo del modelo} KC: {Fabricante, Modelo} {Fabricante} -> {País del fabricante} La tabla NO está en 2FN TERCERA FORMA NORMAL La tercera forma normal se basa en el concepto de dependencia transitiva. Una tabla está en 3FN si y solo si:

•La tabla está en segunda forma normal (2NF)

•Ningún atributo no-primario de la tabla es dependiente transitivamente de una clave candidata. Que es una dependencia transitiva ? Una dependencia transitiva es una dependencia funcional: X -> Y
Y -> Z X -> Z Una formulación alternativa de la definición de Codd, dada por Carlo Zaniolo en 1982, es ésta:

Una tabla está en 3FN si y solo si, para cada una de sus dependencias funcionales X -> A, por lo menos una de las condiciones siguientes se mantiene:

•X contiene A
•X es una superclave
•A es un atributo primario (es decir, A está contenido dentro de una clave candidata)

La definición de Zaniolo tiene la ventaja de dar un claro sentido de la diferencia entre la 3NF y la más rigurosa forma normal de Boyce-Codd (BCNF). La BCNF simplemente elimina la tercera alternativa ("A es un atributo primario"). Otra forma de definir 3FN Un resumen de la definición de Codd de la 3NF, fue dado por Bill Kent:

Cada atributo no-clave "debe proporcionar un hecho sobre la clave, la clave entera, y nada más excepto la clave". "Nada excepto la clave" Requerir que los atributos no-clave sean dependientes en "la clave completa" asegura que una tabla esté en 2NF; un requerimiento posterior que los atributos no-clave sean dependientes de "nada excepto la clave" asegura que la tabla esté en 3NF. En nuestro ejemplo la siguientes tablas están en 2FN pero fallan en satisfacer los requerimientos de la 3FN CodProy
Proyecto

Claves candidatas: {CodProy} CodProy
Año
Supervisor
Experiencia
Claves candidatas: {CodProy, Año} Proyectos ProyectosSupervisores La violación de la 3NF ocurre porque el atributo no primario Experiencia es dependiente transitivamente de {CodProy, Año} vía el atributo no primario Supervisor. El hecho de que la Experiencia del supervisor es funcionalmente dependiente en el Supervisor hace la tabla vulnerable a inconsistencias lógicas, pues no hay nada que impida a la misma persona ser mostrada con diferentes datos de experiencia en diversos registros. CodProy
Proyecto

Claves candidatas: {CodProy} CodProy
Año
Supervisor

Claves candidatas: {CodProy, Año} Proyectos ProyectosSupervisores Supervisor
Experiencia

Claves candidatas: {Supervisor} Supervisores Las anomalías de actualización no pueden ocurrir en estas tablas, las cuales están en 3NF. FORMA NORMAL DE BOYCE-CODD Es una versión ligeramente más fuerte de tercera forma normal (3FN) DEFINICIÓN: Una tabla está en FNBC si y solo si

Está en 3FN
cada dependencia funcional no trivial tiene una clave candidata como determinante.

En términos menos formales, una tabla está en FNBC si está en 3FN y los únicos determinantes son claves candidatas. Solamente en casos raros una tabla en 3NF no satisface los requerimientos de la FNBC Tecnicos TecnicosUniversidades Cedula
Tecnico
LugarDeResidencia

Claves candidatas: {Cedula} Cedula
RUTUniversidad
Universidad

Claves candidatas:
{Cedula, RutUniversidad},
{Cedula, Universidad} En nuestro ejemplo, la relación TécnicoUniversidad no está en FNBC El propósito de la tabla TecnicoUniversidad es mostrar a que Universidades asistió cada técnico. Dadas las claves candidatas, tres atributos de la tabla son atributos primarios, es decir, los tres atributos pertenecen a las claves candidatas. Dado que la tabla de arriba carece de cualquier atributo no-primario, está en 2NF y 3NF. La FNBC es más rigurosa que la 3NF en que no permite ninguna dependencia funcional en la cual el conjunto determinante de atributos no sea una clave candidata.

La dependencia de RutUniversidad - Universidad es ese tipo de dependencia. Por consiguiente, la tabla no está en FNBC En este caso, corregir el problema sería una simple cuestión de usar solo un esquema de identificación para las universidades: o el RUT o el Nombre, pero no ambos Tecnicos TecnicosUniversidades Cedula
Tecnico
LugarDeResidencia

Claves candidatas: {Cedula} Cedula
RUT


Claves candidatas:
{Cedula, RUT} Universidades RUT
Universidad

Claves candidatas:
{RUT},
{Universidad} Una forma sencilla de comprobar si una relación se encuentra en FNBC consiste en comprobar, además de que esté en 3FN, lo siguiente:

•(1) Si no existen claves candidatas compuestas (con varios atributos), está en FNBC.

•(2) Si existen varias claves candidatas compuestas y éstas tienen un elemento común, no está en FNBC.

En el ejemplo existían dos claves candidatas y ambas comparten el atributo Cedula, por lo tanto no estaba en FNBC. Otra formulación CUARTA FORMA NORMAL La cuarta forma normal se basa en el concepto de dependencia multivaluada DEFINICIÓN: Una tabla está en 4FN si y solo si

Está en 3NF o en BCNF (cualquiera de ambas)

No posee dependencias multivaluadas no triviales. Una tabla con una dependencia multivaluada es una donde la existencia de dos o más relaciones independientes muchos a muchos causa redundancia; y es esta redundancia la que es suprimida por la cuarta forma normal. Considere el siguiente ejemplo: EQUIPOS TÉCNICOS PROYECTOS Debido a que la tabla tiene una clave única y ningún atributo no-clave, no viola ninguna forma normal hasta el BCNF. Pero debido a que los técnicos asignados a un equipo de trabajo son independientes del proyecto asignado para ese equipo, hay redundancia en la tabla:

Por ejemplo, nos dicen dos veces que el equipo A trabaja sobre el proyecto X.

Si el mismo equipo comienza a trabajar sobre el proyecto Z nos dirá dos veces que los técnicos 1 y 2 pertenecen a ese equipo, porque necesitaremos agregar múltiples registros, uno para cada una de los técnicos integrantes del equipo. En términos formales: Técnico tiene una dependencia multivalor en Equipo. Para satisfacer la 4FN, debemos poner los hechos sobre las integrantes de los equipos en una tabla diferente de los hechos sobre los proyectos sobre los que trabaja cada equipo: EQUIPOS TÉCNICOS PROYECTOS IMPORTANTE Esta solución depende fuertemente de la realidad a representar:

Ya que si los componentes de los equipos variaran por proyecto, la tabla original de las tres columnas satisfaría la 4FN. Como demostró Ronald Fagin siempre posible alcanzar la 4NF pero no siempre deseable. QUINTA FORMA NORMAL También conocida como forma normal de proyección-unión (PJ/NF) Una tabla se dice que está en 5FN si y solo si

Está en 4NF

Cada dependencia de unión (join) en ella es implicada por las claves candidatas. Es difícil descubrir dependencias de reunión en bases de datos reales de cientos de tributos, es por eso que en la práctica real se les presta poca atención. Por ejemplo si tuviéramos Proyectos, Componente y Proveedor.

Donde cada proyecto requiere de cierto componente, que es provisto por cierto proveedor.

Con una relación ternaria estaría bien para representar esa realidad. PROVEEDORES COMPONENTES PROYECTOS Pero si la realidad indicara que:

Si un proveedor P suministra el componente C
Y un Proyecto Y consume el componente C,
Y el proveedor P es quien suministra al Proyecto Y

Entonces el proveedor P lo suministra del componente C. Entonces la realidad debería modelarse con tres relaciones diferentes que permitan la reunión sin pérdida. PROVEEDORES COMPONENTES PROYECTOS CASO DE ESTUDIO: BASE DE DATOS DISTRIBUIDA DE DNS DNS: Sistema de Nombres de Dominio. Es una base de datos distribuida, organizada de forma jerárquica cuya estructura se mantiene hasta hoy día casi idéntica a como lo era cuando se creó. La estructura genérica de un registro en una base de datos DNS es la siguiente: Registro {Nombre, TTL, Clase, Tipo, Valor} Un ejemplo de la tabla del servidor de dominio de ort.edu.uy. podría ser como sigue: En que forma normal se encuentra esta tabla ? Evidentemente esta tabla no cumple ninguno de los requisitos planteados en ninguna de las formas normales.

Ni siquiera de la primera forma normal, ya que el dominio del campo valor puede ser virtualmente cualquier cosa. Existen en funcionamiento muchas bases de datos que no se apegan a los criterios de normalización y que usamos día a día sin inconvenientes. Las formas normales nos brinda un marco de correctitud y seguridad en cuanto a los datos contenidos en nuestras bases de datos, pero no son requisitos esenciales para su funcionamiento. Sin embargo de no trabajar con bases de datos normalizadas, al momento de interactuar con ellas o desarrollar software para manipular sus datos debemos tener mayores consideraciones y seguramente más hora de trabajo para asegurar la correctitud y seguridad de los datos. RESUMEN Las formas normales son una herramienta formal para el diseño y estructuración de las bases de datos relacionales. No es necesaria su aplicación para que una base de datos funcione. Pero si es una forma de lograr seguridad en los datos, que de otra manera deberían ser garantizadas por la programación de las reglas del negocio en el sistema desarrollado sobre la base de datos. El analista de datos no debería pasar por alto las formas normales y las reglas de normalización al momento de brindar una solución de base de datos ante una realidad planteada, de forma de tener ciertas garantías de eficiencia y seguridad en los datos a almacenar. Bibliografía Sistemas de Bases de Datos – Conceptos Fundamentales – Elmasri / Navathe. 2da Edición.

Wikipedia: Formas Normales.

Documentos publicados por la cátedra de Redes de Datos de la Facultad de Ingeniería de la Universidad ORT (esto en lo que refiere al análisis de DNS). MUCHAS GRACIAS !!! En nuestro ejemplo la relación Técnicos se encuentra en 2FN
Full transcript