GUIA 8 Primera y Segunda forma normal PDF

Preview

Summary

practica de bases de datos...

Description

UNIVERSIDAD DE CUNDINAMARCA FACULTAD DE INGENIERIA FUSAGASUGA

FECHA: 2020-02-01 CURSO: BASES DE DATOS VERSION: 1.0 GUÍA No. PROF: FERNANDO SOTELO

La primera forma normal (1NF 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 1NF 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ón[1] y está libre de "grupos repetitivos".[2] Sin embargo, el concepto de "grupo repetitivo", es entendido de diversas maneras por diferentes teóricos. Como una consecuencia, no hay un acuerdo universal en cuanto a qué características descalificarían a una tabla de estar en 1NF. Muy notablemente, la 1NF, tal y como es definida por algunos autores excluye "atributos relación-valor" (tablas dentro de tablas) siguiendo el precedente establecido por E.F. Codd) (algunos de esos autores son: Ramez Elmasri y Shamkant B. Navathe[3] ). Por otro lado, según lo definido por otros autores, la 1NF sí los permite (por ejemplo como la define Chris Date).

Las tablas 1NF como representaciones de relaciones [editar] Según la definición de Date de la 1NF, una tabla está en 1NF si y solo si es "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, IDs de objeto, o timestamps ocultos]. —Chris Date, "What First Normal Form Really Means", pp. 127-84

La violación de cualesquiera de estas condiciones significaría que la tabla no es estrictamente relacional, y por lo tanto no está en 1NF. Algunos ejemplos de tablas (o de vistas) que no satisface esta definición de 1NF son:  Una tabla que carece de una clave primaria. Esta tabla podría acomodar filas duplicadas, en violación de la condición 3.  Una vista cuya definición exige que los resultados sean retornados en un orden particular, de modo que el orden de la fila sea un aspecto intrínseco y significativo de la vista.5 Esto viola la condición 1. Las tuplas en relaciones verdaderas no están ordenadas una con respecto de la otra.  Una tabla con por lo menos un atributo que pueda ser nulo. Un atributo que pueda ser nulo estaría en violación de la condición 4, que requiere a cada campo contener exactamente un valor de su dominio de columna. Sin embargo, debe ser observado que este aspecto de la condición 4 es controvertido. Muchos autores consideran que una tabla está en 1FN si ninguna clave candidata puede contener valores nulos, pero se aceptan éstos para atributos (campos) que no sean clave, según el modelo original de Codd sobre el modelo relacional, el cual hizo disposición explícita para los nulos.6

UNIVERSIDAD DE CUNDINAMARCA

FECHA: 2020-02-01 CURSO: BASES DE DATOS

FACULTAD DE INGENIERIA FUSAGASUGA

VERSION: 1.0 GUÍA No. PROF: FERNANDO SOTELO

Grupos repetidos La cuarta condición de Date, que expresa "lo que la mayoría de la gente piensa como la característica que define la 1NF",7 concierne a grupos repetidos. El siguiente ejemplo ilustra cómo un diseño de base de datos puede incorporar la repetición de grupos, en violación de la 1NF.

Ejemplo 1: Dominios y valores Suponga que un diseñador principiante desea guardar los nombres y los números telefónicos de los clientes. Procede a definir una tabla de cliente como la que sigue: Cliente ID Cliente

Nombre Apellido

Teléfono

123

Rachel

Ingram

555-861-2025

456

James

Wright

555-403-1659

789 Maria Fernandez 555-808-9633 En este punto, el diseñador se da cuenta de un requisito debe guardar múltiples números teléfonicos para algunos clientes. 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

123

Rachel

Ingram

555-861-2025

456

James

Wright

555-403-1659 555-776-4100

789 Maria Fernandez 555-808-9633 Asumiendo, sin embargo, 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), la representación de arriba no está en 1NF. La 1NF (y, para esa materia, el RDBMS) prohíbe a un campo contener más de un valor de su dominio de columna.

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

Teléfono 2

Teléfono 3

UNIVERSIDAD DE CUNDINAMARCA FACULTAD DE INGENIERIA FUSAGASUGA

FECHA: 2020-02-01 CURSO: BASES DE DATOS VERSION: 1.0 GUÍA No. PROF: FERNANDO SOTELO

123

Osvaldo Ingram

555-861-2025

456

James

555-403-1659 555-776-4100

Wright

Fernande 555-808-9633 z Sin embargo, esta representación hace uso de columnas que permiten valores nulos, y por lo tanto no se conforman con la definición de la 1NF de Date. Incluso si se contempla la posibilidad de columnas con valores nulos, el diseño no está en armonía con el espíritu de 1NF. Teléfono 1, Teléfono 2, y Teléfono 3, comparten exactamente el mismo dominio y exactamente el mismo significado; el dividir del número de teléfono en tres encabezados es artificial y causa problemas lógicos. Estos problemas incluyen:  Dificultad en hacer consultas a la tabla. 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?".  La imposibilidad de hacer cumplir la unicidad los enlaces Cliente-a-Teléfono por medio del RDBMS. 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.  La restricción de los números de teléfono por cliente a tres. Si viene un cliente con cuatro números de teléfono, estamos obligados a guardar solamente tres y dejar el cuarto sin guardar. Esto significa que el diseño de la base de datos está imponiendo restricciones al proceso del negocio, en vez de (como idealmente debe ser el caso) al revés. 789

Maria

Ejemplo 3: Repetición de grupos dentro de columnas El diseñador puede, alternativamente, conservar una sola columna de número de teléfono, pero alterando su dominio, haciendo una cadena de suficiente longitud para acomodar múltiples números telefónicos: Cliente ID Cliente Nombre Apellido

Teléfono

123

Rachel

Ingram

555-861-2025

456

James

Wright

555-403-1659, 555-776-4100

789 Maria Fernandez 555-808-9633 Éste es defendiblemente el peor diseño de todos, y otra vez no mantiene el espíritu de la 1NF. El encabezado "Teléfono" llega a ser semánticamente difuso, ya que ahora puede representar, o un número de teléfono, o una lista de números de teléfono, o de hecho cualquier cosa. Una consulta como "¿Qué pares de clientes comparten un número telefónico?" es virtualmente imposible de formular, dada la necesidad de proveerse de listas de números telefónicos así como números telefónicos individuales. Con este diseño en la RDBMS, son también imposibles de definir significativas restricciones en números telefónicos.

UNIVERSIDAD DE CUNDINAMARCA FACULTAD DE INGENIERIA FUSAGASUGA

FECHA: 2020-02-01 CURSO: BASES DE DATOS VERSION: 1.0 GUÍA No. PROF: FERNANDO SOTELO

Un diseño conforme con 1NF [editar]Un diseño que está inequívocamente en 1NF hace uso de dos tablas: una tabla de cliente y una tabla de teléfono del cliente. Cliente ID Cliente

Nombre Apellido

123

Rachel

Ingram

456

James

Wright

789

Maria

Fernandez Teléfono del cliente

ID Cliente

Teléfono

123

555-861-2025

456

555-403-1659

456

555-776-4100

789

555-808-9633

En este diseño no ocurren grupos repetidos de números telefónicos. En lugar de eso, cada enlace Cliente-a-Teléfono aparece en su propio registro.

Atomicidad Algunas definiciones de 1NF, más notablemente la de E.F. Codd, hacen referencia al concepto de atomicidad. 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".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)".9 Hugh Darwen y Chris Date han sugerido que el concepto de Codd de un "valor atómico" es ambiguo, y que esta ambigüedad ha conducido a una extensa confusión sobre cómo debe ser entendida la 1NF.10 11 En particular, la noción de un "valor que no puede ser descompuesto" es problemática, pues parecería implicar que pocos, si algún, tipos de datos son atómicos:  Una cadena de caracteres parecería no ser atómica, ya que el RDBMS típicamente proporciona operadores para descomponerla en subcadenas.  Una fecha parecería no ser atómica, ya que el RDBMS proporciona típicamente operadores para descomponerla los componentes de día, mes, y año.  Un número de punto fijo parecería no ser atómico, 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, pero puede ser considerado un ensamblaje de elementos más básicos para otros propósitos. Si esta posición es aceptada, la 1NF no puede ser definida con referencia a la atomicidad. 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

UNIVERSIDAD DE CUNDINAMARCA

FECHA: 2020-02-01 CURSO: BASES DE DATOS

FACULTAD DE INGENIERIA FUSAGASUGA

VERSION: 1.0 GUÍA No. PROF: FERNANDO SOTELO

entonces aceptables en un tabla 1NF - aunque quizás no siempre deseable. Date discute que los atributos relación-valor, por medio de los cuales un campo dentro de una tabla puede contener una tabla, son útiles en casos raros.13 Un dato sin normalizar no cumple con ninguna regla de normalización. Para explicar con un ejemplo en que consiste cada una de las reglas, vamos a considerar los datos de la siguiente tabla. ID_ORDE FECH ID_CLIENT NOM_CLIEN N A E TE

ESTAD NUM_ITE DESC_ITE CAN PRECI O M M T O

2301

2/23/0 101 3

MARTI

CA

3786

RED

3

35

2301

2/23/0 101 3

MARTI

CA

4011

RAQUETA

6

65

2301

2/23/0 101 3

MARTI

CA

9132

PAQ-3

8

4.75

2302

2/25/0 107 3

HERMAN

WI

5794

PAQ-6

4

5.0

2303

2/27/0 110 3

WE-SPORTS

MI

4011

RAQUETA

2

65

2303

2/27/0 110 3

WE-SPORTS

MI

3141

FUNDA

2

10

Al examinar estos registros, podemos darnos cuenta que contienen un grupo repetido para NUM_ITEM, DESC_ITEM, CANT y PRECIO. La 1FN prohibe los grupos repetidos, por lo tanto tenemos que convertir a la primera forma normal. Los pasos a seguir son:  

Tenemos que eliminar los grupos repetidos. Tenemos que crear una nueva tabla con la PK de la tabla base y el grupo repetido.

Los registros quedan ahora conformados en dos tablas que llamaemos ORDENES y ARTICULOS_ORDENES - ORDENES ID_ORDEN

FECHA

ID_CLIENTE

NOM_CLIENTE

ESTADO

2301

2/23/03

101

MARTI

CA

2302

2/25/03

107

HERMAN

WI

2303

2/27/03

110

WE-SPORTS

MI

UNIVERSIDAD DE CUNDINAMARCA

FECHA: 2020-02-01 CURSO: BASES DE DATOS

FACULTAD DE INGENIERIA FUSAGASUGA

VERSION: 1.0 GUÍA No. PROF: FERNANDO SOTELO

- ARTICULOS_ORDENES ID_ORDEN

NUM_ITEM

DESC_ITEM

CANT

PRECIO

2301

3786

RED

3

35

2301

4011

RAQUETA

6

65

2301

9132

PAQ-3

8

4.75

2302

5794

PAQ-6

4

5.0

2303

4011

RAQUETA

2

65

2303

3141

FUNDA

2

10

Segunda forma normal La segunda forma normal (2NF) es una forma normal usada en normalización de bases de datos. La 2NF definida originalmente por E.F. Codd[1] en 1971. Una tabla que está en la primera forma normal (1NF) debe satisfacer criterios adicionales para calificar para la segunda forma normal. Específicamente: una tabla 1NF está en 2NF si y solo si, dada cualquier clave candidata y cualquier atributo que no sea un constituyente de la clave candidato, el atributo no clave depende de toda la clave candidata en vez de solo una parte de ella. 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 apropiado) de una clave candidata. (Un atributo no-principal de A es uno que no pertenece a ninguna clave candidato). Observe que cuando una tabla 1NF no tiene ninguna clave candidato compuesta (claves candidato consistiendo en más de un atributo), la tabla está automáticamente en 2NF.

Ejemplo Considere una tabla describiendo las habilidades de los empleados: Habilidades de los empleados Empleado

Habilidad

Lugar actual de trabajo

Jones

Mecanografía

114 Main Street

Jones

Taquigrafía

114 Main Street

Jones

Tallado

114 Main Street

Roberts

Limpieza ligera

73 Industrial Way

UNIVERSIDAD DE CUNDINAMARCA FACULTAD DE INGENIERIA FUSAGASUGA

FECHA: 2020-02-01 CURSO: BASES DE DATOS VERSION: 1.0 GUÍA No. PROF: FERNANDO SOTELO

Ellis

Alquimia

73 Industrial Way

Ellis

Malabarismo

73 Industrial Way

Harrison

Limpieza ligera

73 Industrial Way

La única clave candidata de la tabla es {Empleado, Habilidad}. El atributo restante, Lugar actual de trabajo, es dependiente en solo parte de la clave candidata, llamada Empleado. 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, y dos veces que Ellis trabaja en 73 Industrial Way. Esta redundancia hace a la tabla vulnerable anomalías de actualización: por ejemplo, es posible actualizar el lugar del trabajo de Jones en sus registros "Mecanografía" y "Taquigrafía" y no actualizar su registro "Tallado". 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 Emplead o

Lugar actual de trabajo

Jones

114 Main Street

Roberts

73 Industrial Way

Ellis

73 Industrial Way

Harrison

73 Industrial Way

Habilidades de los empleados Empleado

Habilidad

Jones

Mecanografía

Jones

Taquigrafía

Jones

Tallado

Roberts

Limpieza ligera

Ellis

Alquimia

Ellis

Malabarismo

Harrison Limpieza ligera Las anomalías de actualización no pueden ocurrir en estas tablas, las cuales están en 2NF. Sin embargo, no todas las tablas 2NF están libres de anomalías de actualización. Un ejemplo de una tabla 2NF que sufre de anomalías de actualización es:

UNIVERSIDAD DE CUNDINAMARCA

FECHA: 2020-02-01 CURSO: BASES DE DATOS

FACULTAD DE INGENIERIA FUSAGASUGA

VERSION: 1.0 GUÍA No. PROF: FERNANDO SOTELO

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, Año} y no son partes de ella, particularmente las combinaciones Ganador / Fecha de nacimiento del ganador son mostradas redundantemente en múltiples registros. Este problema es tratado por la tercera forma normal (3NF).

2NF y las claves candidatas 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 candidato. Las múltiples claves candidato ocurren en la siguiente tabla: Modelos eléctricos de cepillo de dientes Fabricante

Modelo

Nombre completo del modelo

País del fabricante

Forte

X-Prime

Forte X-Prime

Italia

Forte

Ultraclean

Forte Ultraclean

Italia

Dent-oFresh

EZBrush

Dent-o-Fresh EZBrush

USA

Kobayashi

ST-60

Kobayashi ST-60

Japón

Hoch

Toothmaster Hoch Toothmaster

Alemania

Hoch

Contender

Alemania

Hoch Contender

UNIVERSIDAD DE CUNDINAMARCA FACULTAD DE INGENIERIA FUSAGASUGA

FECHA: 2020-02-01 CURSO: BASES DE DATOS VERSION: 1.0 GUÍA No. PROF: FERNANDO SOTELO

Aun si el diseñador ha especificado la clave principal como {Nombre completo del modelo}, la tabla no está en 2NF. {fabricante, modelo} es también una clave candidato, y País del fabricante es dependiente en un subconjunto apropiado de él: Fabricante....