BD TEMA 3 Diplomado

Elaboró: M. en C. Georgina Eslava García

UNIDAD III EL MODELO RELACIONAL

3.1 Elementos del modelo relacional 3.1.1 Relación/Tabla La relación es el elemento básico del modelo relacional y se representa por una tabla. Ejemplo ver la relación de la figura 3.1:

Figura 3.1 Ejemplo de una relación

3.1.2 Tupla/Renglón Las tuplas son los renglones de las tablas, que equivalen a cada uno de los registros que contendrá la base de datos. Ejemplo

Figura 3.2 A cada registro (renglón) se denomina como tupla.

3.1.3 Atributo/Columna Los atributos son las columnas de la tabla que corresponden a las características de cada registro localizado en la tupla. Ejemplo

Figura 3.3 A cada columna de una relación s e le denomina como atributo.

1

Elaboró: M. en C. Georgina Eslava García

Un atributo es aquel que participa en la descripción de las entidades y que como tal constituye una pieza específica de información para un determinado dominio. En el caso de que sean varios los atributos de una misma tabla, definidos por el mismo dominio, habrá que darles nombres distintos, ya que una tabla no puede tener dos atributos con el mismo nombre, sin embargo, existen los dominios compuestos los cuales están conformados por otros dominios, además de tener un nombre y permitir aplicar restricciones, por ejemplo: Un usuario podría manejar además de los tres dominios Día, Mes y Año un dominio compuesto llamado Fecha que sería la combinación de los tres y al que se le podría aplicar restricciones de integridad a fin de que no aparecieran valores no válidos para la fecha.

3.1.4 Dominio Un dominio es un conjunto finito de valores homogéneos y atómicos caracterizados por un nombre. Homogéneo significa que los valores son todos del mismo tipo y atómicos significa que son indivisibles, es decir, si se descomponen se perdería la semántica del dominio, por ejemplo: Dominio de Nacionalidades: Chilena, Francesa, Norteamericana Todo dominio tiene un nombre y un tipo de datos, en el ejemplo anterior, el tipo de datos es un conjunto de caracteres de longitud máxima de 14. Se pueden asociar unidades de medida, como metros y kilos u otras restricciones. La importancia de los dominios es que restringen las comparaciones, es decir, sólo se pueden comparar atributos definidos sobre el mismo dominio.

3.1.5 Cardinalidad de una relación La cardinalidad se define en base al número de tuplas que conforman a una tabla. Σ tuplas

3.1.6 Grado de una relación El grado es el número de atributos o columnas que conforman a una tabla. Σ atributos

Es importante señalar que la relación es de dos dimensiones, en el sentido de que la intersección de una tupla y una columna sólo puede almacenar un valor, es decir, no se admiten atributos multivaluados.

3.2 Reglas de Codd En la década de los 80's comenzaron a aparecer numerosos SGBD que se anunciaban como relacionales; sin embargo estos sistemas carecían de muchas características que se consideraban importantes en un sistema relacional, perdiendo muchas ventajas del modelo relacional. Estos "sistemas relacionales" eran simplemente sistemas que utilizaban tablas para almacenar la información, no disponiendo de elementos como claves primarias, etc. En 1984 Codd publicó 12 reglas que un sistema relacional debería cumplir.

2

Elaboró: M. en C. Georgina Eslava García

Regla Cero. Un sistema de gestión de base de datos relacional debe administrar sus datos almacenados sólo con el uso de sus capacidades relacionales. Este es el principio fundamental sobre el que se basan las doce reglas. Regla 1. Representación de la información. Toda información en una base de datos relacional debe representarse explícitamente a nivel lógico y de manera única, por medio de valores en columnas de filas de tablas. Regla 2. Acceso garantizado. Todo dato debe ser accesible mediante una combinación de un nombre de la relación (o tabla ), el valor de su llave primaria y el nombre del atributo (o columna). Regla 3. Tratamiento sistemático de los valores nulos . Los SGBD deben soportar valores nulos, que se utilizan para representar y manipular información desconocida o que no aplica. Los valores nulos deben ser tratados sistemáticamente por el sistema independiente del tipo de datos, el cual ha de ofrecer las facilidades necesarias para su tratamiento. Regla 4. Catálogo activo en línea basado en un modelo relacional . Los SGBD debe tener un catálogo en línea dinámico denominado diccionario de datos. La representación de la metainformación (Descripción lógica de los datos) debe ser igual a la de los datos ordinarios y su acceso debe poder realizarse por medio del mismo lenguaje relacional que se utiliza para los demás datos; es decir, el modelo de datos para la metainformación debe ser también relacional. Regla 5. Sub-lenguaje de datos completo. El sistema debe soportar por lo menos un lenguaje relacional que   

Tenga una sintaxis lineal. Pueda ser utilizado interactivamente o en programas. Soporte operaciones de definición de datos, operaciones de manipulación de datos (actualización así como de recuperación), restricciones de seguridad e integridad, autorizaciones y operaciones de administración de transacciones.

Regla 6. Actualización de vistas. Toda vista actualizable deberá ser actualizada por medio del sistema. Regla 7. Inserción, modificación y eliminación de alto nivel . Todas las operaciones de manipulación de datos (inserción, modificación y eliminación) deben operar sobre conjuntos de filas. Regla 8. Independencia física de los datos . Los programas de aplicación y la actividad en terminales no deberán ser afectados por cambios en el nivel físico de los datos (forma en que se almacenan los datos, si en arreglos o en las listas encadenadas, etc.) o en el método de acceso. Regla 9. Independencia lógica de los datos . Los cambios a nivel lógico (como dividir o combinar tablas, columnas, filas, etc.) no deben afectar el contenido de la información a nivel lógico, no requieren modificación de aplicaciones. Regla 10. Independencia de la integridad. Las restricciones de integridad de una base de datos deberán poder definirse en el mismo sub-lenguaje de datos relacional y deberán almacenarse en el catálogo, no en los programas de aplicación. Regla 11.  Independencia de la distribución. Debe existir un sub-lenguaje de datos que pueda soportar bases de datos distribuidas sin alterar los programas de aplicación cuando se distribuyan los datos por primera vez o se redistribuyan estos posteriormente. En otras palabras, las aplicaciones no deben verse 3

Elaboró: M. en C. Georgina Eslava García

afectadas al distribuir (dividir entre varias máquinas), o al cambiar la distribución ya existente de la Base de Datos. Regla 12. Regla de la no subversión. Si un sistema relacional tiene un lenguaje de bajo nivel que permita el acceso fila a fila, éste no puede utilizarse para saltarse las reglas de integridad expresadas por medio del lenguaje de mas alto nivel (Subversión es desestabilizar, destruir lo establecido). Esto es si el sistema posee una interface de bajo nivel (p. e. llamadas en C), éste no puede subvertir el sistema; por ejemplo, pudiendo evitar restricciones de seguridad o integridad. Cualquier BDMS que proclame ser relacional, deberá manejar, completamente, las bases de datos por medio de sus capacidades relacionales. Hay que advertir que no todas las reglas tiene igual importancia. Según Codd, sólo si se satisfacen las 12 reglas se aprovecharían los beneficios potenciales que ofrecen el modelo relacional.

3.3 Tipo de llaves El término llave en una relación es un conjunto no vacío de atributos que identifican unívoca y mínimamente cada tupla. Toda relación siempre tendrá una llave candidata, estas claves pueden ser clasificadas en tres principales grupos: Llave primaria:  En inglés Primary Key (PK), es aquella llave que permite identificar las tuplas de la relación de forma única. 



Llaves alternativas: Son aquellas llaves que no han sido escogidas como claves primarias, pero que también podrían identificar de manera única a una tupla. Llave candidata:  Es el atributo o conjunto de atributos que podrían servir como llaves primarias.

Llave secundaria:  Son aquellas llaves candidatas que no se eligieron como llave primaria, es decir, tienen todas las características para ser claves primarias, pero que por alguna razón no fueron tomadas como tal debido quizás a que hubo otra que cumplía mejor con ese objetivo. Llave foránea:  Es una clave primaria en otra relación, estas representan las asociaciones entre las diferentes entidades, es decir, son claves que están siendo compartidas por dos tablas para formar una relación entre ellas.

3.4 Normalización El proceso de cristalización de las entidades y sus relaciones en formatos de tabla usando los conceptos relacionales se llama proceso de normalización y consiste en distribuir a los campos de datos en un conjunto de relaciones o tablas que representan a las entidades, sus características y sus relaciones de forma adecuada. La razón de la normalización es asegurar que el modelo conceptual de la base de datos funcionará. Esto no significa que una estructura no normalizada no funcionará, sino que puede causar algunos problemas cuando los programadores de aplicación traten de modificar la base de datos para insertar, actualizar o eliminar datos.

4

Elaboró: M. en C. Georgina Eslava García

Las formas de normalización fueron propuestas originalmente por Codd, entre 1971 y 1972. Posteriormente varios investigadores continuaron trabajando en esta teoría y a lo largo del tiempo han surgido varias formas de normalización que complementan y refuerzan a las enunciadas por Codd. Las formas normales son una serie de restricciones que se definen sobre las estructuras relacionales para evitar anomalías al efectuar adiciones, eliminaciones o actualizaciones de tuplas. Con el fin de conseguir que una relación cumpla con una forma normal se efectúa un proceso de descomposición, que consiste en dividir a los atributos de una relación en dos subconjuntos (posiblemente con una intersección no vacía) sin que por ello se pierda alguna información contenida en la relación original. Las ventajas de la normalización son las siguientes:    

Minimiza los datos redundantes, con ello evita la duplicación de esfuerzos. Evita anomalías en inserciones, modificaciones y borrados. Promueve el uso más eficaz del espacio físico. Mejora la independencia de datos.

Uno de los conceptos fundamentales en la normalización es el de dependencia funcional. La dependencia funcional es una noción semántica donde cada dependencia es una clase especial de regla de integridad y representa una relación de uno a muchos. Básicamente, las reglas de normalización están encaminadas a eliminar redundancias e inconsistencias de dependencia en el diseño de las tablas. Las tres formas normales son Primera Forma Normal, Segunda Forma Norma, tercera forma Normal, entre otras.

Figura 3.4 Formas Normales

3.4.1 Primera forma normal Primera Forma Normal (1FN): Una relación está en primera forma normal si: 



Todos los atributos contienen valores atómicos, es decir, en la intersección tupla-atributo se tiene un solo dato. No hay grupos de datos repetitivos 5

Elaboró: M. en C. Georgina Eslava García

    

La tabla contiene una clave primaria. No contiene valores nulos en el atributo de la clave primaria. No debe existir variación en el número de columnas. Los atributos no clave deben identificarse por la clave primaria (Dependencia funcional) Debe existir una independencia del orden tanto de las filas como de las columnas, es decir, si los datos cambian de orden no deben cambiar sus significados

3.4.2 Segunda forma normal Segunda Forma Normal (2FN): Una relación está en segunda forma normal si, y sólo si, está en 1FN y, además, cada atributo que no sea la clave primaria es completamente dependiente de la clave primaria.

3.4.3 Tercera forma normal Tercera Forma Normal (3FN): Una relación está en tercera forma normal si, y sólo si, está en 2FN y, además, cada atributo que no es la clave primaria no depende transitivamente de la clave primaria. La dependencia es transitiva si existe cualquier atributo no llave que sea dependiente de otro atributo no es llave que a su vez es dependiente de la PK en la misma relación Un dato sin normalizar no cumple con ninguna regla de normalización. La normalización se lleva a cabo en una serie pasos, cada paso corresponde a una forma normal que tiene ciertas propiedades. Conforme se va avanzando en la normalización, las relaciones tienen un formato más estricto y más fuerte y por lo tanto, son menos vulnerables a las anomalías de actualización.

3.4.4 Proceso de Normalización Paso 1: Si la tabla no cumple con la 1FN,  se tienen que dejar valores atómicos. Si la relación presenta repetición de tuplas a causa de algunos atributos, entonces s e saca el conjunto de atributos que provocan la repetición de la relación original y se agregan en una nueva relación junto con una copia de la PK de la relación original. Ejemplo: Considerar los datos de la relación PEDIDO.

PEDIDO ID_ORDEN FECHA ID_CLIENTE NOM_CLIE ESTADO ID_ITEM DESC_ITEM CANT PRECIO MARTI 2301 02/23/13 101 QUERETARO 3786 PELOTA 3 35.00 SUAREZ 2301

02/23/13

101

2301

02/23/13

101

2302

02/25/13

107

2303

02/27/13

110

2303

02/27/13

110

MARTI SUAREZ MARTI SUAREZ RODRIGO ERNESTO GONZÁLEZ JULIO MENDEZ JULIO MENDEZ

QUERETARO

4011

RAQUETA

6

65.00

QUERETARO

9132

PAQ-3

8

4.75

DISTRITO FEDERAL

5794

PAQ-6

4

5.00

GUERRERO

4011

RAQUETA

2

65.00

GUERRERO

3141

FUNDA

2

10.0

6

Elaboró: M. en C. Georgina Eslava García

 Al examinar estos registros, se observa que la intersección de tupla con el atributo NOM_CLIENTE no es atómico. La 1FN establece que deben ser atómicos, por lo tanto tenemos que agregar un nuevo campo

PEDIDO ID_ORDEN FECHA ID_CLIENTE NOM_CLIE  APEIDO_CLIE ESTADO ID_ITEM DESC_ITEM CANT PRECIO 2301 02/23/13 101 MARTI SUAREZ QUERETARO 3786 PELOTA 3 35.00 2301 2301

02/23/13 02/23/13

101 101

2302

02/25/13

107

2303 2303

02/27/13 02/27/13

110 110

MARTI MARTI RODRIGO ERNESTO JULIO JULIO

SUAREZ SUAREZ

QUERETARO QUERETARO DISTRITO FEDERAL GUERRERO GUERRERO

GONZÁLEZ MENDEZ MENDEZ

4011 9132

RAQUETA PAQ-3

6 8

65.00 4.75

5794

PAQ-6

4

5.00

4011 3141

RAQUETA FUNDA

2 2

65.00 10.0

Observar que además la relación contiene un grupo repetido para ID_ITEM, DESC_ITEM, CANT y PRECIO, que no dependen de la llave primaria lo que ocasiona que para algunas tuplas existan dos o mas ID_ITEM repetidos, por lo tanto tenemos que sacar el conjunto de tuplas que provocan la repetición de la relación original y se agregan en una nueva relación junto con una copia del atributo de la PK de la relación en cuestión. Los registros quedan ahora conformados en dos tablas: la original PEDIDO y la nueva relación que será denominada ARTICULO_ORDEN PEDIDO ID_ORDEN 2301

FECHA 02/23/13

ID_CLIENTE 101

NOM_CLIE MARTIN

 APEIDO_CLIE SUAREZ

2302

02/25/13

107

RODRIGO ERNESTO

GONZÁLEZ

2303

02/27/13

110

JULIO

MENDEZ

ESTADO QUER TARO CIUDAD DE MÉXICO GUERRERO

 ARTICULO_ORDEN ID_ORDEN 2301

ID_ITEM 3786

DESC_ITEM PELOTA

CANT 3

PRECIO 35.00

2301 2301 2302 2303 2303

4011 9132 5794 4011 3141

RAQUETA PAQ-3 PAQ-6 RAQUETA FUNDA

6 8 4 2 2

65.00 4.75 5.00 65.00 10.0

Paso 2: Verificar si la relación cumple con la 2FN, es decir identificar cualquier atributo no llave que no dependa de la llave primaria de la relación. En seguida serán retirados de la relación original y agregados en una nueva relación junto con una copia del atributo del que dependen. Ejemplo: En base a las tablas o relaciones de PEDIDO y ARTICULO_ORDEN, se observa que la relación PEDIDO  está en 2FN, ya que cualquier valor único de ID_ORDEN  determina un sólo valor para cada columna. Por lo tanto, todas las columnas son dependientes de la llave primaria ID_ORDEN. Por otra parte, la relación  ARTICULO_ORDEN  no se encuentra en 2FN  ya que los atributos PRECIO y DESC_ITEM  son dependientes de ID_ITEM, pero no son dependientes de ID_ORDEN, por lo tanto se eliminarán de la relación  ARTICULO_ORDEN y se creará a una nueva relación que se denominará  ARTICULO que contendrá a los atributos no dependientes y una copia de la llave de la que si dependen 7

Elaboró: M. en C. Georgina Eslava García

Las relaciones quedan ahora de la siguiente manera.  ARTICULO_ORDEN ID_ORDEN 2301 2301 2301 2302 2303 2303

ID_ITEM 3786 4011 9132 5794 4011 3141

CANT 3 6 8 4 2 2

 ARTICULO ID_ITEM DESC_ITEM 3786 PELOTA 4011 RAQUETA 9132 PAQ-3 5794 PAQ-6 3141 FUNDA

PRECIO 35.00 65.00 4.75 5.00 10.0

Paso 3: Verificar si la relación cumple con la 3FN, es decir identificar cualquier atributo no llave que presente dependencia transitiva. Si fuera el caso entonces dichos atributos se tiene que eliminar de la relación en cuestión. En este caso es necesario determinar los atributos que son dependientes de otro atributo no llave que está en transitividad con la PK, eliminarlos de la relación en cuestión y agregarlos en otra nueva, junto con el atributo llave del cual son dependientes . Ejemplo: La relación PEDIDO  no está en 3FN, porque NOM_CLIE  APEIDO_CLIE ESTADO ,

,

depende de ID_CLIENTE que a su vez depende de la PK,ID_ORDEN, por lo tanto se retirarán los atributos NOM_CLIE y ESTADO_CLIE  de la relación PEDIDO y se colocarán en una nueva relación denominada CLIENTE  junto con una copia del atributo dependiente, en este caso ID_CLIENTE. Las nuevas relaciones CLIENTE y PEDIDO se muestran a continuación. PEDIDO ID_ORDEN 2301 2302 2303

FECHA 2/23/03 2/25/03 2/27/03

ID_CLIENTE 101 107 110

CLIENTE ID_CLIENTE NOM_CLIE 101 MARTIN

NOM_CLIE SUAREZ

ESTAD_CLIE QUER TARO

107

RODRIGO ERNESTO

GONZÁLEZ

CIUDAD DE MÉXICO

110

JULIO

MENDEZ

GUERRERO

8

Elaboró: M. en C. Georgina Eslava García

Ejemplo 2. Dada la siguiente relación normalizar por primera, segunda y tercera forma. IdLibro Titulo 2301 El principito 2301 2301 2303 2303 2303 2305 2305 2305 2305 2305 2305

idAutor  101

Libro Nombre_Autor   Antoin de Exuperry

Telefono_Autor  33435678

101 101 110 110 110 140 140 150 150 150 160

 Antoin de Exuperry  Antoin de Exuperry Benito Perez Benito Perez Benito Perez Iván López Iván López María de Jesús Castellano María de Jesús Castellano María de Jesús Castellano John Ospino

4563789 5535555 6973633 8886868 8484848 34567822 78117822 86868689 23234222 43456780 1112345

El principito El principito Marianela Marianela Marianela Bases de datos Bases de datos Bases de datos Bases de datos Bases de datos Bases de datos

No está en primera forma normal, existen atributos que no son atómicos y además hay grupos repetidos. Se aplica el proceso de convertir a primera forma normal. En ese caso se agrega el atributo ApellidoAutor para lograr volverlo atómico.

IdLibro Titulo 2301 El principito 2301 2301 2303 2303 2303 2305 2305 2305 2305 2305 2305

El principito El principito Marianela Marianela Marianela Bases de datos Bases de datos Bases de datos Bases de datos Bases de datos Bases de datos

idAutor  101 101 101 110 110 110 140 140 150 150 150 160

Libro Nombre_Autor   Antoin  Antoin  Antoin Benito Benito Benito Iván Iván María de Jesús María de Jesús María de Jesús John

 ApellidoAutor de Exuperry

Telefono_Autor  33435678

de Exuperry de Exuperry Perez Perez Perez López López Castellano Castellano Castellano Ospino

4563789 5535555 6973633 8886868 8484848 34567822 78117822 86868689 23234222 43456780 1112345

En seguida se observan que existes atributos que provocan repetir el IdLibro y el Título, es decir existen grupos repetidos debido a que un libro puede ser escrito por varios autores. Libro IdLibro Titulo 2301 El principito

idAutor  101

Nombre_Autor   Antoin

 ApellidoAutor de Exuperry

Telefono_Autor  33435678

2301 El principito 2301 El principito 2303 Marianela

101 101 110

 Antoin  Antoin Benito

de Exuperry de Exuperry Perez

4563789 5535555 6973633

9

Elaboró: M. en C. Georgina Eslava García

2303 Marianela 2303 Marianela Bases de 2305 datos Bases de 2305 datos Bases de 2305 datos Bases de 2305 datos Bases de 2305 datos Bases de 2305 datos

110 110 140 140 150 150 150 160

Benito Benito Iván

Perez Perez López

Iván

López

María de Jesús

Castellano

María de Jesús

Castellano

María de Jesús

Castellano

John

Ospino

8886868 8484848 34567822 78117822 86868689 23234222 43456780 1112345

Se procede a sacar los atributos que provocan la repetición y ponerlos en otra tabla junto con una copia de la llave primaria. Libro IdLibro Titulo 2301 El principito 2303 Marianela 2305 Bases de datos

IdLibro 2301

idAutor  101

Nombre_Autor   Antoin

Libro-Autor  ApellidoAutor de Exuperry

2301 2301 2303 2303 2303 2305 2305 2305 2305 2305 2305

101 101 110 110 110 140 140 150 150 150 160

 Antoin  Antoin Benito Benito Benito Iván Iván María de Jesús María de Jesús María de Jesús John

de Exuperry de Exuperry Perez Perez Perez López López Castellano Castellano Castellano Ospino

Telefono_Autor  33435678 4563789 5535555 6973633 8886868 8484848 34567822 78117822 86868689 23234222 43456780 1112345

De las tablas resultantes se observa que la tabla 1 cumple con todas las formas normales, sin embargo la tabla Libro- Autor no cumple con la primera forma normal pues hay grupos repetidos. Entonces detectamos que el Teléfono es el atributo que ocasiona tuplas repetidas, por lo tanto se crea una nueva tabla con el teléfono del autor y una copia de la llave primaria

10

Elaboró: M. en C. Georgina Eslava García

Libro-Autor idLibro 2301 2303 2305 2305 2305

idAutor  101 110 140 150 160

Nombre_Autor   Antoin Benito Iván María de Jesús John

idAutor  101 101 101 110 110 110 140 140 150 150 150 160

 ApellidoAutor de Exuperry Perez López Castellano Ospino

 Autor_Telefono Telefono_Autor  33435678 4563789 5535555 6973633 8886868 8484848 34567822 78117822 86868689 23234222 43456780 1112345

Sin embargo la relación Libro-Autor, no cumple con la tercera forma normal pues no todos los campos dependen directamente de id_libro, sino de manera transitiva nombre autor, y apellido autor dependen de id_autor y este a su vez dependen de idlibro en ese caso, se sacaran dichos campos en otra relación y se llevará la clave de la que si dependen directamente. Libro-Autor idLibro idAutor  2301 101 2303 110 2305 140 2305 150 2305 160

 Autor idAutor  101 110 140 150 160

Nombre_Autor   Antoin Benito Iván María de Jesús John

 ApellidoAutor de Exuperry Perez López Castellano Ospino 11

Elaboró: M. en C. Georgina Eslava García

Final menta las tablas obtenidas cumplen con la 1FN, 2FN,3FN. Libro IdLibro Titulo 2301 El principito 2303 Marianela 2305 Bases de datos

Libro-Autor idLibro idAutor  2301 101 2303 110 2305 140 2305 150 2305 160

 Autor_Telefono idAutor  Telefono_Autor  101 33435678 101 101 110 110 110 140 140 150 150 150 160

4563789 5535555 6973633 8886868 8484848 34567822 78117822 86868689 23234222 43456780 1112345

 Autor idAutor  101 110 140 150 160

Nombre_Autor   Antoin Benito Iván María de Jesús John

 ApellidoAutor de Exuperry Perez López Castellano Ospino

La siguiente decisión es ¿qué tan lejos se debe llevar la normalización? La normalización es subjetiva. Determinar las necesidades de simplificación depende de nosotros. Si la base de datos va a proveer información a un solo usuario para un propósito simple y existen pocas posibilidades de expansión, normalizar los datos hasta la 3FN quizá sea algo exagerado. Las reglas de normalización existen como guías para crear tablas que sean fáciles de manejar, así como flexibles y eficientes. A veces puede ocurrir que normalizar los datos hasta el nivel más alto no tenga sentido. ¿Se están dividiendo tablas sólo para seguir las reglas o estas divisiones son en verdad prácticas?. Éstas son el tipo de cosas que como diseñadores de la base de datos, necesitamos decidir, y la experiencia y el sentido común nos pueden auxiliar para tomar la decisión correcta. La normalización no es una ciencia exacta, más bien subjetiva.

3.4.4 Otras formas normales Existen seis niveles más de normalización. Ellos son Forma Normal Boyce-Codd, Cuarta Forma Normal (4NF), Quinta Forma Normal (5NF) o Forma Normal de Proyección-Unión, Forma Normal de Proyección-Unión Fuerte, Forma Normal de Proyección-Unión Extra Fuerte y Forma Normal de Clave de Dominio. Estas formas de normalización pueden llevar las cosas más allá de lo que necesitamos y tienen que ver principalmente con dependencias múltiples y claves relacionales. 12

Elaboró: M. en C. Georgina Eslava García

3.5 Reglas de integridad Los conceptos básicos de integridad en el modelo relacional son el de llave primaria, llave foránea, valores nulos y un par de reglas de integridad.

3.5.1 Manejo de valores nulos En un DBMS relacional debe soportar los valores nulos, que son distintos de una cadena de caracteres vacía o de una cadena con caracteres en blanco o de cero o cualquier otro número, para representar información faltante o no aplicable de una forma consistente, independientemente del tipo de dato. Es importante tomar en cuenta el manejo de valores nulos en la creación de las aplicaciones, por ejemplo NOMBRE  APELLIDO CALIFICACIÓN  ADRIANA NÉSTOR FABIÁN JULIO PEDRO  ALEJANDRA

PASTRANA GONZÁLEZ RODRÍGUEZ GÓMEZ  ÁLVAREZ

8 10 9 4

Si se deseara saber el promedio del grupo se tendrían 6.2, pero es un resultado que no representa la realidad, ya que existe un alumno cuya calificación se desconoce, en este caso es un error contemplar un cero. Otro caso es el manejo del NULL y los operadores lógicos, etc. &(AND) V V V F F NULL NULL

F NULL F NULL F F F NULL

|| (OR) V F NULL

V F NULL V V V V F NULL V NULL NULL

~(NOT) V F F V NULL NULL

3.5.2 Integridad de la entidad La restricción de integridad de entidades, establece que ningún valor de la llave primaria puede ser nulo. Esto es porque el valor de la llave primaria sirve para identificar las tuplas individuales en una relación, en el que la llave primaria tenga valores nulos implica que no se pueden identificar algunas tuplas.

3.5.3 Integridad referencial El término de integridad referencial se enmarca en la segunda regla de integridad y se aplica a las claves foráneas: "Si en una relación hay alguna clave foránea, sus valores deben coincidir con valores de la clave primaria a la que hace referencia, o bien, deben ser completamente nulos". 13

Elaboró: M. en C. Georgina Eslava García

Lo que en realidad trata de decir el texto anterior es que las claves foráneas no pueden dejar de tener correspondencia con la clave primaria de la tabla externa; las tuplas que contienen llaves foráneas que no tienen una llave candidata, se denominan entidades huérfanas.

3.6 Índices En un archivo indexado el acceso a los registros se logra sólo mediante uno o más índices, debe existir un apuntador en algún índice para permitir la recuperación del registro. Un índice estará asociado con un campo llave y pueden existir índices para todos los campos de los que se espere un argumento de búsqueda. Un índice o tabla de índices es un archivo separado del archivo maestro al cual pertenece. En el índice cada registro contiene dos datos: la llave del registro y una dirección de almacenamiento (o apuntador al registro físico). El índice puede definirse como una tabla que opera con un procedimiento que acepta información acerca de ciertos valores de datos (campo o atributo), como entrada y provee, como salida, una información que permite la rápida localización del registro, o los registros, a que pertenecen aquellos valores de datos. Cuando se utiliza este tipo de organización para una archivo, el sistema debe explorar el índice más bien que el archivo en sí. Con este recurso se economiza tiempo, pero acosta del espacio que se necesita para almacenar el índice. Este método es semejante al que se usa en las bibliotecas para localizar libros. El usuario busca el título que desea en un fichero de tarjetas y obtiene como resultado el número de catálogo del libro, número que equivale de cierta forma, a la dirección relativa del libro en los estantes. Si en la tabla de índices se tiene un apuntador a cada registro del archivo, se le llama índice exhaustivo. En el caso de que solo se tengan apuntadores a registros en los cuales el valor de la llave es significativo, se tendrá un índice selectivo. Un índice o tabla de índices es un archivo separado del archivo maestro al cual pertenece. En el índice cada registro contiene dos datos: la llave del registro y una dirección de almacenamiento (o apuntador al registro físico).

14