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

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

en violación de la 1NF. [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. que requiere a cada campo contener exactamente un valor de su dominio de columna. que expresa "lo que la mayoría de la gente piensa como la característica que define la 1FN". Una vista cuya definición exige que los resultados sean retornados en un orden particular. Sin embargo. según el modelo original de Codd sobre el modelo relacional. Una tabla con por lo menos un atributo que pueda ser nulo. el cual hizo disposición explícita para los nulos. pero se aceptan éstos para atributos (campos) que no sean clave. de modo que el orden de la fila sea un aspecto intrínseco y significativo de la vista. debe observarse que este aspecto de la condición 4 es controvertido.7 concierne a grupos repetidos. 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.6 [editar] Grupos repetidos La cuarta condición de Date. El siguiente ejemplo ilustra cómo un diseño de base de datos puede incorporar la repetición de grupos. el diseñador se da cuenta de un requisito para guardar múltiples números teléfonicos para algunos clientes.   Una tabla que carece de una clave primaria. en violación de la condición 3.5 Esto viola la condición 1. 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. Esta tabla podría acomodar filas duplicadas. 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 . Un atributo que pueda ser nulo estaría en violación de la condición 4.

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

conservar una sola columna de número de teléfono. o una lista de números de teléfono. ya que ahora puede representar. El encabezado "Teléfono" llega a ser semánticamente difuso. 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.[editar] Ejemplo 3: Repetición de grupos dentro de columnas El diseñador puede. o un número de teléfono. Una consulta como "¿Qué pares de clientes comparten un número telefónico?" es virtualmente imposible de formular. Cliente ID Cliente Nombre Apellido 123 456 789 Rachel Ingram James Cesar Wright Dure Teléfono del cliente ID Cliente Teléfono . o de hecho cualquier cosa. 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. son también imposibles de definir significativas restricciones en números telefónicos. pero alterando su dominio. 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.

pero puede ser considerado un ensamblaje de elementos más básicos para otros propósitos. 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".10 11 En particular. 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. y año. cada enlace Cliente-a-Teléfono aparece en su propio registro.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.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)". mes. Es valioso notar que este diseño cumple los requerimientos adicionales para la segunda (2NF) y la tercera forma normal (3FN). la 1NF no puede ser definida con referencia a la atomicidad. Codd. y que esta ambigüedad ha conducido a una extensa confusión sobre cómo debe ser entendida la 1NF. ya que el RDBMS típicamente proporciona operadores para descomponerla en subcadenas.9 [Hugh Darwen] y [Chris Date] han sugerido que el concepto de Codd de un "valor atómico" es ambiguo.aunque quizás no siempre deseable. Un número de punto fijo parecería no ser atómico. 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 . pues parecería implicar que pocos. Si esta posición es aceptada.F. más notablemente la de E. En lugar de eso. tipos de datos son atómicos:    Una cadena de caracteres parecería no ser atómica. ya que el RDBMS proporciona típicamente operadores para descomponerlo en componentes de números enteros y fraccionarios.13 . hacen referencia al concepto de atomicidad. Una fecha parecería no ser atómica. [editar] Atomicidad Algunas definiciones de 1NF. Date discute que los atributos relación-valor. ya que el RDBMS proporciona típicamente operadores para descomponerla los componentes de día. si algún. por medio de los cuales un campo dentro de una tabla puede contener una tabla. son útiles en casos raros. la noción de un "valor que no puede ser descompuesto" es problemática.

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

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). 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).

es posible actualizar el lugar del trabajo de Jones en sus registros "Mecanografía" y "Taquigrafía" y no actualizar su registro "Tallado". Lugar actual de trabajo. es dependiente solo en parte de la clave candidata. y dos veces que Ellis trabaja en 73 Industrial Way. las cuales están en 2NF. . Los datos resultantes implicarían respuestas contradictorias a la pregunta "¿Cuál es el lugar actual de trabajo de Jones?". 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. llamada Empleado. Esta redundancia hace a la tabla vulnerable a anomalías de actualización: por ejemplo. Por lo tanto la tabla no está en 2NF.El atributo restante. 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.

[editar] 2NF y las claves candidatas Una tabla para la cual no hay dependencias funcionales parciales en la clave primaria está típicamente. Año} y no son partes de ella. es necesario establecer que ningún atributo no-principal tienen dependencias de clave parciales en cualesquiera de estas claves candidatas. 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 . la tabla puede contener otras claves candidatas.Sin embargo. 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. Además de la clave principal. Este problema es tratado por la tercera forma normal (3NF). no todas las tablas 2NF están libres de anomalías de actualización. en 2NF. particularmente las combinaciones Ganador / Fecha de nacimiento del ganador son mostradas redundantemente en múltiples registros. pero no siempre.

y País del fabricante es dependiente en un subconjunto apropiado de él: Fabricante. X → Z por virtud de X → Y e Y → Z. La 3NF fue definida originalmente por E. 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). Modelo} es también una clave candidata. La BCNF simplemente elimina la tercera alternativa ("A es un atributo primario"). la tabla no está en 2NF. Codd1 en 1971. pero sí de un tercer conjunto de atributos Y. 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. Una dependencia transitiva es una dependencia funcional X → Z en la cual Z no es inmediatamente dependiente de X. para cada una de sus dependencias funcionales X → A. dada por Carlo Zaniolo2 en 1982.F. . por lo menos una de las condiciones siguientes se mantiene:    X contiene A. que a su vez depende de X. Es decir. ó X es una superclave. 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. Una formulación alternativa de la definición de Codd. {Fabricante.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}. ó A es un atributo primario (es decir. es ésta: Una tabla está en 3NF si y solo si.

siendo paralelo al compromiso tradicional de dar evidencia verdadera en un tribunal de justicia. Ya que aplicándola a todos los atributos prohibiría implícitamente claves de candidato compuestas.. la clave entera. puesto que cada parte de cualquiera de tales claves violaría la cláusula de "clave completa". 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. Chris Date refiere al resumen de Kent como "una intuitiva atractiva caracterización" de la 3NF.5 La versión 3NF de la definición es más débil que la variación de BCNF de Date. un requerimiento posterior que los atributos no-clave sean dependientes de "nada excepto la clave" asegura que la tabla esté en 3NF. y nada excepto la clave". Debe ser observado que esta regla se aplica solamente a los atributos funcionalmente dependientes.4 Requerir que los atributos no-clave sean dependientes en "la clave completa" asegura que una tabla esté en 2NF. [editar] Ejemplo Un ejemplo de una tabla 2NF que falla en satisfacer los requerimientos de la 3NF es: Ganadores del torneo . 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. 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.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. la clave entera. fue dado por Bill Kent: cada atributo no-clave "debe proporcionar un hecho sobre la clave.3 Una variación común complementa esta definición con el juramento: "con la ayuda de Codd".

Año}. La violación de la 3NF ocurre porque el atributo no primario Fecha de nacimiento del ganador es dependiente transitivamente de {Torneo.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. 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 . Año} vía el atributo no primario Ganador. Para expresar los mismos hechos sin violar la 3NF. pues no hay nada que impida a la misma persona ser mostrada con diferentes fechas de nacimiento en diversos registros. El hecho de que la Fecha de nacimiento del ganador es funcionalmente dependiente en el Ganador hace la tabla vulnerable a inconsistencias lógicas.

Por lo tanto A no es dependiente transitivo de Y. uno donde X no contiene a A) y sea A un atributo no clave.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. que en la práctica raramente se encuentran. y borrado. En una tabla en 3FN. como ). son afectadas por tales anomalías. y dada arriba. si y solo si el X → Y. 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. También sea Y una clave de R. una tabla está en FNBC si está en 3FN y los únicos determinantes son claves candidatas. . son insuficientes para satisfacer las formas normales más altas 4NF o 5NF. [editar] Derivación de las condiciones de Zaniolo La definición de 3NF ofrecida por Carlo Zaniolo en 1982. Entonces Y → X. las cuales están en 3NF. todos los atributos dependen de una clave. es probada así: Sea X → A un FD no trivial (es decir. En terminos menos formales. 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. éstas son tablas que no satisfacen la forma normal de Boyce-Codd (BCNF) o.Las anomalías de actualización no pueden ocurrir en estas tablas. inserción. si satisfacen la BCNF. Ciertos tipos de tablas 3NF. de la clave completa y de ninguna otra cosa excepto de la clave (excluyendo dependencias triviales. es decir. 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. si y solo si X es una superclave. Es una versión ligeramente más fuerte de la Tercera forma normal (3FN).

En dicho departamento hay varios responsables. La redundancia del departamento es completamente evitable.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. Solamente en casos raros una tabla en 3NF no satisface los requerimientos de la FNBC. ID Estudiante} . ID Estudiante} {Número de seguro social del tutor. es que el o la responsable sólo puede ser responsable en un departamento. El detalle importante que no se ha tenido en cuenta. No está por tanto en FNBC. 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. Este detalle último produce una dependencia funcional ya que: Responsable→Departamento Por lo tanto hemos encontrado un determinante que no es clave candidata. pero cada trabajador sólo tiene asignado uno. En este caso la redundancia ocurre por mala selección de clave.

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

Sign up to vote on this title
UsefulNot useful