P. 1
FORMAS NORMALES BD

FORMAS NORMALES BD

|Views: 997|Likes:
Publicado pormorsa90

More info:

Published by: morsa90 on Nov 04, 2011
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOCX, PDF, TXT or read online from Scribd
See more
See less

06/12/2013

pdf

text

original

Forma normal (base de datos

)
En la teoría de bases de datos relacionales, las formas normales (NF) proporcionan los criterios para determinar el grado de vulnerabilidad de una tabla a inconsistencias y anomalías lógicas. Mientras sea más alta la forma normal aplicable a una tabla, es menos vulnerable a inconsistencias y anomalías. Cada tabla tiene una "forma normal más alta" (HNF): por definición, una tabla siempre satisface los requisitos de su HNF y de todas las formas normales más bajas que su HNF; también por definición, una tabla no puede satisfacer los requisitos de ninguna forma normal más arriba que su HNF. Las formas normales son aplicables a tablas individuales; decir que una base de datos entera está en la forma normal n es decir que todas sus tablas están en la forma normal n. Los recién llegados al diseño de bases de datos a veces suponen que la normalización procede de una manera iterativa, es decir un diseño 1NF primero se normaliza a 2NF, entonces a 3NF, etcétera. Ésta no es una descripción exacta de cómo la normalización trabaja típicamente. Una tabla sensiblemente diseñada es probable que esté en 3NF en la primera tentativa; además, si está en 3NF, también es extremadamente probable que tenga una forma HNF de 5NF. Conseguir formas normales "más altas" (sobre 3NF) usualmente no requiere un gasto adicional de esfuerzo por parte del diseñador, porque las tablas 3NF usualmente no necesitan ninguna modificación para satisfacer los requisitos de estas formas normales más altas. Edgar F. Codd originalmente definió las tres primeras formas normales (1NF, 2NF, y 3NF). Estas formas normales se han resumido como 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 (4NF y 5NF) se ocupan específicamente de la representación de las relaciones muchos a muchos y uno muchos entre los atributos. La sexta forma normal (6NF) incorpora consideraciones relevantes a las bases de datos temporales??/de tiempo real??.

Primera forma normal (1FN)
(Redirigido desde 1NF)

La primera forma normal (1FN o forma mínima) es una forma normal usada en normalización de bases de datos. Una tabla de base de datos relacional que se adhiere a la 1FN es una que satisface cierto conjunto mínimo de criterios. Estos criterios se refieren básicamente a asegurarse que la tabla es una representación fiel de una relación1 y está libre de "grupos repetitivos".2 Sin embargo, el concepto de "grupo repetitivo", es entendido de diversas maneras por diferentes teóricos. Como consecuencia, no hay un acuerdo universal en cuanto a qué características descalificarían a una tabla de estar en 1FN. Muy notablemente, la 1FN, tal y

2 Ejemplo 2: Grupos repetidos a través de columnas o 2. No hay orden de arriba-a-abajo en las filas. o timestamps ocultos].1 Ejemplo 1: Dominios y valores o 2. —Chris Date. No hay filas duplicadas. 3.4 Un diseño conforme con 1FN 3 Atomicidad 4 Normalización más allá de la 1NF 5 Notas y referencias 6 Véase también 7 Lectura adicional 8 Enlaces externos [editar] Las tablas 1FN como representaciones de relaciones Según la definición de Date de la 1FN. las filas no tienen componentes como IDs de fila.F. "What First Normal Form Really Means". Todas las columnas son regulares [es decir. que satisface las siguientes cinco condiciones: 1. Contenido [ocultar]         1 Las tablas 1FN como representaciones de relaciones 2 Grupos repetidos o 2. Por otro lado. 5. 2. pp. la 1FN sí los permite (por ejemplo como la define Chris Date). una tabla está en 1FN si y solo si es "isomorfa a alguna relación". 4. Navathe3 ).3 Ejemplo 3: Repetición de grupos dentro de columnas o 2. específicamente. lo que significa. No hay orden de izquierda-a-derecha en las columnas. según lo definido por otros autores. y por lo tanto no está en 1FN. Algunos ejemplos de tablas (o de vistas) que no satisfacen esta definición de 1FN son: . 127-84 La violación de cualesquiera de estas condiciones significaría que la tabla no es estrictamente relacional. Codd) (algunos de esos autores son: Ramez Elmasri y Shamkant B. IDs de objeto.como es definida por algunos autores excluye "atributos relación-valor" (tablas dentro de tablas) siguiendo el precedente establecido por E. Cada intersección de fila-y-columna contiene exactamente un valor del dominio aplicable (y nada más).

Una tabla con por lo menos un atributo que pueda ser nulo. El siguiente ejemplo ilustra cómo un diseño de base de datos puede incorporar la repetición de grupos. Esta tabla podría acomodar filas duplicadas. que expresa "lo que la mayoría de la gente piensa como la característica que define la 1FN". Un atributo que pueda ser nulo estaría en violación de la condición 4. Procede a definir una tabla de cliente como la que sigue: Cliente ID Cliente Nombre Apellido 123 456 789 Teléfono Rachel Ingram 555-861-2025 James Cesar Wright 555-403-1659 Dure 555-808-9633 En este punto. de modo que el orden de la fila sea un aspecto intrínseco y significativo de la vista.7 concierne a grupos repetidos. Una vista cuya definición exige que los resultados sean retornados en un orden particular. en violación de la 1NF.6 [editar] Grupos repetidos La cuarta condición de Date. el cual hizo disposición explícita para los nulos.   Una tabla que carece de una clave primaria. Muchos autores consideran que una tabla está en 1FN si ninguna clave candidata puede contener valores nulos. Las tuplas en relaciones verdaderas no están ordenadas una con respecto de la otra. Razona que la manera más simple de hacer esto es permitir que el campo "Teléfono" contenga más de un valor en cualquier registro dado: Cliente ID Cliente Nombre Apellido Teléfono . [editar] Ejemplo 1: Dominios y valores Suponga que un diseñador principiante desea guardar los nombres y los números telefónicos de los clientes. pero se aceptan éstos para atributos (campos) que no sean clave. según el modelo original de Codd sobre el modelo relacional. Sin embargo. el diseñador se da cuenta de un requisito para guardar múltiples números teléfonicos para algunos clientes. que requiere a cada campo contener exactamente un valor de su dominio de columna. debe observarse que este aspecto de la condición 4 es controvertido. en violación de la condición 3.5 Esto viola la condición 1.

el RDBMS) prohíbe a un campo contener más de un valor de su dominio de columna. estamos obligados a guardar solamente tres y dejar el cuarto sin guardar. . para esa materia. que la columna "Teléfono" está definida en algún tipo de dominio de número telefónico (por ejemplo. el dominio de cadenas de 12 caracteres de longitud). comparten exactamente el mismo dominio y exactamente el mismo significado. sin embargo.123 456 789 Rachel Ingram 555-861-2025 James Cesar Wright Dure 555-403-1659 555-776-4100 555-808-9633 Asumiendo. Es difícil contestar preguntas tales como "¿Qué clientes tienen el teléfono X?" y "¿Qué pares de clientes comparten un número de teléfono?". [editar] Ejemplo 2: Grupos repetidos a través de columnas El diseñador puede evitar esta restricción definiendo múltiples columnas del número telefónico: Cliente ID Cliente Nombre Apellido Teléfono 1 123 456 789 Rachel Ingram 555-861-2025 James Cesar Wright 555-403-1659 555-776-4100 Dure 555-808-9633 Teléfono 2 Teléfono 3 Sin embargo. La imposibilidad de hacer cumplir la unicidad los enlaces Cliente-a-Teléfono por medio del RDBMS. La restricción de los números de teléfono por cliente a tres. Teléfono 1. en vez de (como idealmente debe ser el caso) al revés. y Teléfono 3. La 1FN (y. Si viene un cliente con cuatro números de teléfono. Esto significa que el diseño de la base de datos está imponiendo restricciones al proceso del negocio. el diseño no está en armonía con el espíritu de 1NF. esta representación hace uso de columnas que permiten valores nulos. la representación de arriba no está en 1FN. Incluso si se contempla la posibilidad de columnas con valores nulos. Estos problemas incluyen:    Dificultad en hacer consultas a la tabla. Teléfono 2. el dividir del número de teléfono en tres encabezados es artificial y causa problemas lógicos. Al cliente 789 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 por lo tanto no se conforman con la definición de la 1NF de Date.

conservar una sola columna de número de teléfono. son también imposibles de definir significativas restricciones en números telefónicos. Una consulta como "¿Qué pares de clientes comparten un número telefónico?" es virtualmente imposible de formular. haciendo una cadena de suficiente longitud para acomodar múltiples números telefónicos: Cliente ID Cliente Nombre Apellido 123 456 789 Teléfono Rachel Ingram 555-861-2025 James Cesar Wright 555-403-1659. o una lista de números de teléfono. ya que ahora puede representar. 555-776-4100 Dure 555-808-9633 Éste es defendiblemente el peor diseño de todos. [editar] Un diseño conforme con 1FN Un diseño que está inequívocamente en 1FN hace uso de dos tablas: una tabla de cliente y una tabla de teléfono del cliente. y otra vez no mantiene el espíritu de la 1NF.[editar] Ejemplo 3: Repetición de grupos dentro de columnas El diseñador puede. o un número de teléfono. pero alterando su dominio. El encabezado "Teléfono" llega a ser semánticamente difuso. Con este diseño en la RDBMS. alternativamente. dada la necesidad de proveerse de listas de números telefónicos así como números telefónicos individuales. o de hecho cualquier cosa. Cliente ID Cliente Nombre Apellido 123 456 789 Rachel Ingram James Cesar Wright Dure Teléfono del cliente ID Cliente Teléfono .

la 1NF no puede ser definida con referencia a la atomicidad. Una fecha parecería no ser atómica. cada enlace Cliente-a-Teléfono aparece en su propio registro. pues parecería implicar que pocos. ya que el RDBMS proporciona típicamente operadores para descomponerla los componentes de día. Un número de punto fijo parecería no ser atómico. por medio de los cuales un campo dentro de una tabla puede contener una tabla. Codd.aunque quizás no siempre deseable. hacen referencia al concepto de atomicidad.8 Codd define un valor atómico como uno que "no puede ser descompuesto en pedazos más pequeños por el DBMS (excepto ciertas funciones especiales)". ya que el RDBMS proporciona típicamente operadores para descomponerlo en componentes de números enteros y fraccionarios. Date sugiere que "la noción de atomicidad no tiene ningún significado absoluto":12 un valor puede ser considerado atómico para algunos propósitos.F.13 . y que esta ambigüedad ha conducido a una extensa confusión sobre cómo debe ser entendida la 1NF.123 456 456 789 555-861-2025 555-403-1659 555-776-4100 555-808-9633 En este diseño no ocurren grupos repetidos de números telefónicos. y año. son útiles en casos raros. Codd 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". Date discute que los atributos relación-valor. Si esta posición es aceptada. En lugar de eso. si algún. Las columnas de cualquier tipo de datos concebible (desde tipos de cadenas y tipos numéricos hasta tipos de arreglos y tipos de tabla) son entonces aceptables en un tabla 1NF . más notablemente la de E.9 [Hugh Darwen] y [Chris Date] han sugerido que el concepto de Codd de un "valor atómico" es ambiguo. [editar] Atomicidad Algunas definiciones de 1NF.10 11 En particular. pero puede ser considerado un ensamblaje de elementos más básicos para otros propósitos. ya que el RDBMS típicamente proporciona operadores para descomponerla en subcadenas. Es valioso notar que este diseño cumple los requerimientos adicionales para la segunda (2NF) y la tercera forma normal (3FN). mes. tipos de datos son atómicos:    Una cadena de caracteres parecería no ser atómica. la noción de un "valor que no puede ser descompuesto" es problemática.

org Primer nombre del subscriptor Steve Carol Apellido del subscriptor Wallace Robertson Robertson Clark crobertson@aardvarkmail. Específicamente: una tabla 1NF está en 2NF si y solo si. Por ejemplo. pero no está en 2NF y por lo tanto es vulnerable a inconsistencias lógicas: Dirección de correo del subscriptor ID del subscriptor 108 252 252 360 Dirección de correo steve@aardvarkmail. La 2NF fue definida originalmente por E. Si el cambio es aplicado solamente a una fila.net carol@mongoosemail. el cambio debe ser aplicado a dos filas. la tabla siguiente está en 1NF. Una tabla que está en la primera forma normal (1NF) debe satisfacer criterios adicionales para calificar para la segunda forma normal. también está. Segunda forma normal (2FN) (Redirigido desde 2NF) La segunda forma normal (2NF) es una forma normal usada en normalización de bases de datos.[editar] Normalización más allá de la 1NF Cualquier tabla que esté en la segunda forma normal (2NF) o más arriba. Dirección de correo}. Por una parte. por definición. el atributo no clave depende de toda la clave primaria en vez de solo una parte de ella. Si Carol Robertson cambia su apellido por el de matrimonio. Codd1 en 1971.F. resulta en una contradicción: la pregunta "cuál es nombre del cliente 252?" tiene dos respuestas que están en conflicto. puede o no puede estar en 3NF. en 1NF (cada forma normal tiene criterios más rigurosos que su precursor).com Harriet La clave de la tabla es {ID del subscriptor. . y así sucesivamente. dada una clave primaria y cualquier atributo que no sea un constituyente de la clave primaria. una tabla que está en 1NF puede o no puede estar en 2NF. si está en 2NF. Las formas normales más arriba que la 1NF son pensadas para ocuparse de las situaciones en las que una tabla sufre de problemas de diseño que pueden comprometer la integridad de los datos dentro de ella.net Carol hclark@antelopemail. La 2NF aborda este problema.

Contenido [ocultar]       1 Ejemplo 2 2NF y las claves candidatas 3 Referencias 4 Lectura adicional 5 Véase también 6 Enlaces externos [editar] Ejemplo Considere una tabla describiendo las habilidades de los empleados: Habilidades de los empleados Empleado Jones Jones Jones Bravo Ellis Ellis Habilidad Lugar actual de trabajo Mecanografía 114 Main Street Taquigrafía Tallado 114 Main Street 114 Main Street Limpieza ligera 73 Industrial Way Alquimia 73 Industrial Way Malabarismo 73 Industrial Way Harrison Limpieza ligera 73 Industrial Way La única clave candidata de la tabla es {Empleado. Habilidad}. la tabla está automáticamente en 2NF. . Observe que cuando una tabla 1NF no tiene ninguna clave candidata compuesta (claves candidatas consistiendo en más de un atributo).En términos levemente más formales: una tabla 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 primaria (Un atributo no-principal es uno que no pertenece a ninguna clave primaria).

El atributo restante. Lugar actual de trabajo. Los datos resultantes implicarían respuestas contradictorias a la pregunta "¿Cuál es el lugar actual de trabajo de Jones?". . Un alternativa 2NF a este diseño representaría la misma información en dos tablas: Empleados Empleado Lugar actual de trabajo Jones Bravo Ellis 114 Main Street 73 Industrial Way 73 Industrial Way Harrison 73 Industrial Way Habilidades de los empleados Empleado Jones Jones Jones Bravo Ellis Ellis Harrison Habilidad Mecanografía Taquigrafía Tallado Limpieza ligera Alquimia Malabarismo Limpieza ligera Las anomalías de actualización no pueden ocurrir en estas tablas. Por lo tanto la tabla no está en 2NF. Observe la redundancia de la manera en que son representadas los Lugares actuales de trabajo: nos dicen tres veces que Jones trabaja en la 114 Main Street. las cuales están en 2NF. llamada Empleado. Esta redundancia hace a la tabla vulnerable a anomalías de actualización: por ejemplo. y dos veces que Ellis trabaja en 73 Industrial Way. es dependiente solo en parte de la clave candidata. es posible actualizar el lugar del trabajo de Jones en sus registros "Mecanografía" y "Taquigrafía" y no actualizar su registro "Tallado".

en 2NF. es necesario establecer que ningún atributo no-principal tienen dependencias de clave parciales en cualesquiera de estas claves candidatas. particularmente las combinaciones Ganador / Fecha de nacimiento del ganador son mostradas redundantemente en múltiples registros.Sin embargo. pero no siempre. no todas las tablas 2NF están libres de anomalías de actualización. Año} y no son partes de ella. Además de la clave principal. Las múltiples claves candidatas ocurren en la siguiente tabla: Modelos eléctricos de cepillo de dientes Fabricante Forte Forte Modelo X-Prime Ultraclean Nombre completo del modelo País del fabricante Forte X-Prime Forte Ultraclean Dent-o-Fresh EZBrush Kobayashi ST-60 Italia Italia USA Japón Dent-o-Fresh EZBrush Kobayashi ST-60 . Un ejemplo de una tabla 2NF que sufre de anomalías de actualización es: Ganadores del torneo Torneo Año Ganador Fecha de nacimiento del ganador Des Moines Masters 1998 Chip Masterson 14 de marzo de 1977 Indiana Invitational 1998 Al Fredrickson 21 de julio de 1975 Cleveland Open 1999 Bob Albertson 28 de septiembre de 1968 Des Moines Masters 1999 Al Fredrickson 21 de julio de 1975 Indiana Invitational 1999 Chip Masterson 14 de marzo de 1977 Aunque el Ganador y la Fecha de nacimiento del ganador están determinadas por una clave completa {Torneo. [editar] 2NF y las claves candidatas Una tabla para la cual no hay dependencias funcionales parciales en la clave primaria está típicamente. Este problema es tratado por la tercera forma normal (3NF). la tabla puede contener otras claves candidatas.

que a su vez depende de X. y País del fabricante es dependiente en un subconjunto apropiado de él: Fabricante. dada por Carlo Zaniolo2 en 1982. la tabla no está en 2NF. La definición de Codd indica que una tabla está en 3NF si y solo si las dos condiciones siguientes se mantienen:   La tabla está en la segunda forma normal (2NF) Ningún atributo no-primario de la tabla es dependiente transitivamente de una clave primaria Un atributo no-primario es un atributo que no pertenece a ninguna clave candidata. La 3NF fue definida originalmente por E. {Fabricante. ó X es una superclave. Una formulación alternativa de la definición de Codd.F. es ésta: Una tabla está en 3NF si y solo si. Tercera forma normal (3FN) (Redirigido desde 3NF) La tercera forma normal (3NF) es una forma normal usada en la normalización de bases de datos. La BCNF simplemente elimina la tercera alternativa ("A es un atributo primario"). . Modelo} es también una clave candidata. X → Z por virtud de X → Y e Y → Z. Codd1 en 1971. por lo menos una de las condiciones siguientes se mantiene:    X contiene A.Hoch Hoch Toothmaster Hoch Toothmaster Contender Hoch Contender Alemania Alemania Aun si el diseñador ha especificado la clave principal como {Nombre completo del modelo}. pero sí de un tercer conjunto de atributos Y. Es decir. Una dependencia transitiva es una dependencia funcional X → Z en la cual Z no es inmediatamente dependiente de X. ó 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). para cada una de sus dependencias funcionales X → A.

Ya que aplicándola a todos los atributos prohibiría implícitamente claves de candidato compuestas. [editar] Ejemplo Un ejemplo de una tabla 2NF que falla en satisfacer los requerimientos de la 3NF es: Ganadores del torneo . y nada excepto la clave". y nada más excepto la clave". pues el anterior se refiere solamente a asegurarse de que los atributos no-clave son dependientes en las claves. puesto que cada parte de cualquiera de tales claves violaría la cláusula de "clave completa". cada uno de ellos representa un hecho sobre la clave en el sentido de proporcionar parte o toda la clave en sí misma. Los atributos primarios (que son claves o partes de claves) no deben ser funcionalmente dependientes en absoluto. fue dado por Bill Kent: cada atributo no-clave "debe proporcionar un hecho sobre la clave. la clave entera.Contenido [ocultar]         1 "Nada excepto la clave" 2 Ejemplo 3 Derivación de las condiciones de Zaniolo 4 Normalización más allá de la 3NF 5 Referencias 6 Lectura adicional 7 Véase también 8 Enlaces externos [editar] "Nada excepto la clave" Un memorable resumen de la definición de Codd de la 3NF. Chris Date refiere al resumen de Kent como "una intuitiva atractiva caracterización" de la 3NF.4 Requerir que los atributos no-clave sean dependientes en "la clave completa" asegura que una tabla esté en 2NF. y observa que con una ligera adaptación puede servir como definición ligeramente más fuerte de la forma normal de Boyce-Codd: "Cada atributo debe representar un hecho acerca de la clave.3 Una variación común complementa esta definición con el juramento: "con la ayuda de Codd". un requerimiento posterior que los atributos no-clave sean dependientes de "nada excepto la clave" asegura que la tabla esté en 3NF. la clave entera. siendo paralelo al compromiso tradicional de dar evidencia verdadera en un tribunal de justicia..5 La versión 3NF de la definición es más débil que la variación de BCNF de Date. Debe ser observado que esta regla se aplica solamente a los atributos funcionalmente dependientes.

pues no hay nada que impida a la misma persona ser mostrada con diferentes fechas de nacimiento en diversos registros. La violación de la 3NF ocurre porque el atributo no primario Fecha de nacimiento del ganador es dependiente transitivamente de {Torneo. Año} vía el atributo no primario Ganador. Año}.Torneo Año Ganador Fecha de nacimiento del ganador Indiana Invitational 1998 Al Fredrickson 21 de julio de 1975 Cleveland Open 1999 Bob Albertson 28 de septiembre de 1968 Des Moines Masters 1999 Al Fredrickson 21 de julio de 1975 Indiana Invitational 1999 Chip Masterson 14 de marzo de 1977 La única clave candidata es {Torneo. Para expresar los mismos hechos sin violar la 3NF. es necesario dividir la tabla en dos: Ganadores del torneo Torneo Año Ganador Indiana Invitational 1998 Al Fredrickson Cleveland Open 1999 Bob Albertson Des Moines Masters 1999 Al Fredrickson Indiana Invitational 1999 Chip Masterson Fecha de nacimiento del jugador Jugador Fecha de nacimiento Chip Masterson 14 de marzo de 1977 Al Fredrickson 21 de julio de 1975 Bob Albertson 28 de septiembre de 1968 . El hecho de que la Fecha de nacimiento del ganador es funcionalmente dependiente en el Ganador hace la tabla vulnerable a inconsistencias lógicas.

Se dice que una tabla está en FNBC si y solo si está en 3FN y cada dependencia funcional no trivial tiene una clave candidata como determinante. uno donde X no contiene a A) y sea A un atributo no clave. Por lo tanto A no es dependiente transitivo de Y. En una tabla en 3FN. y borrado. y dada arriba. si y solo si el X → Y. Ciertos tipos de tablas 3NF. es decir. si y solo si X es una superclave. son afectadas por tales anomalías. [editar] Derivación de las condiciones de Zaniolo La definición de 3NF ofrecida por Carlo Zaniolo en 1982. que en la práctica raramente se encuentran. es probada así: Sea X → A un FD no trivial (es decir. éstas son tablas que no satisfacen la forma normal de Boyce-Codd (BCNF) o. En terminos menos formales. una tabla está en FNBC si está en 3FN y los únicos determinantes son claves candidatas. . También sea Y una clave de R. Es una versión ligeramente más fuerte de la Tercera forma normal (3FN). todos los atributos dependen de una clave. de la clave completa y de ninguna otra cosa excepto de la clave (excluyendo dependencias triviales. si satisfacen la BCNF.Las anomalías de actualización no pueden ocurrir en estas tablas.6 [editar] Normalización más allá de la 3NF La mayoría de las tablas 3NF están libres anomalías de actualización. inserción. La forma normal de Boyce-Codd requiere que no existan dependencias funcionales no triviales de los atributos que no sean un conjunto de la clave candidata. son insuficientes para satisfacer las formas normales más altas 4NF o 5NF. Forma normal de Boyce-Codd (FBCN) (Redirigido desde BCNF) La Forma Normal de Boyce-Codd (o FNBC) es una forma normal utilizada en la normalización de bases de datos. Entonces Y → X. como ). las cuales están en 3NF.

No está por tanto en FNBC. En este caso la redundancia ocurre por mala selección de clave. En dicho departamento hay varios responsables. Un ejemplo de tal tabla es (teniendo en cuenta que cada estudiante puede tener más de un tutor): Referencia cruzada de Tutor/Estudiante ID Tutor Número de seguro social del tutor ID Estudiante 1078 1078 1293 1480 088-51-0074 088-51-0074 096-77-4146 072-21-2223 31850 37921 46224 31850 El propósito de la tabla es mostrar qué tutores están asignados a qué estudiantes. Las claves candidatas de la tabla son:   {ID Tutor. ID Estudiante} {Número de seguro social del tutor. Solamente en casos raros una tabla en 3NF no satisface los requerimientos de la FNBC. ID Estudiante} .Contenido [ocultar]       1 Ejemplo 2 Otra formulación 3 Referencias 4 Lectura adicional 5 Véase también 6 Enlaces externos [editar] Ejemplo La cuestión es que un trabajador puede trabajar en varios departamentos. es que el o la responsable sólo puede ser responsable en un departamento. El detalle importante que no se ha tenido en cuenta. pero cada trabajador sólo tiene asignado uno. Este detalle último produce una dependencia funcional ya que: Responsable→Departamento Por lo tanto hemos encontrado un determinante que no es clave candidata. La redundancia del departamento es completamente evitable.

es decir. En la tabla de arriba podía ser representada una combinación inconsistente de ID Tutor y Número de seguro social del tutor. la tabla de arriba no está en FNBC Cualquier tabla que sea insuficiente en FNBC será vulnerable a inconsistencias lógicas. o el número del seguro social. está en FNBC. los tres atributos pertenecen a las claves candidatas. corregir el problema sería una simple cuestión de usar solo un esquema de identificación para los tutores: o el ID. Recuerde que la 2NF prohíbe dependencias funcionales parciales de atributos no-primarios en las claves candidatas. y la 3NF prohíbe dependencias funcionales transitivas de atributos no-primarios en claves candidatas. La dependencia de ID Tutor en Número de seguro social del tutor es ese tipo de dependencia. está en 2NF y 3NF. Dado que la tabla de arriba carece de cualquier atributo no-primario. En el ejemplo existen dos claves candidatas y ambas comparten el atributo ID Estudiante. pero no ambos.Por lo tanto los tres atributos de la tabla son atributos primarios. . no está en FNBC. además de que esté en 3FN. lo siguiente:   (1) Si no existen claves candidatas compuestas (con varios atributos). 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 candidato (o superconjunto de eso). [editar] Otra formulación Una forma sencilla de comprobar si una relación se encuentra en FNBC consiste en comprobar. por lo tanto no está en FNBC. Por consiguiente. En este caso. (2) Si existen varias claves candidatas compuestas y éstas tienen un elemento común.

You're Reading a Free Preview

Descarga
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->