UNIDAD III. EL MODELO DE DATOS RELACIONALObjetivo: Al finalizar la unidad, el estudiante estará en la capacidad de convertir el modelo conceptual de la base de datos, representado en el diagrama Erelacional y validar las relaciones obtenidas a través del proceso de normalización.

3.1 Introducción.

En este apartado se presenta el modelo relacional, que es el modelo lógico en el que se basan la mayoría de los SMBD comerciales, en uso hoy día. En la primera parte de esta unidad, se describen los conceptos básicos del modelo relacional: la estructura de datos relacional y las reglas de integridad. Luego, se presenta la cde la base de datos (Diagrama Entidadpresenta el proceso de n

3.2 El Modelo Relacional.

En 1970, el modo en que se veían las bases de datos cambió por completo cuando E. F. Codd introdujo el modelo relacional. En aquellos momentos, el enfestructura de las bases de datos utilizaba punteros físicos (direcciones de disco) para relacionar registros de distintos ficheros. Si, por ejemplo, se quería relacionar un registro con un registro , se debía añadir al registro del registro . Este campo añadido, un puntero físico, siempre señalaría desde el registro

al registro . Codd demostró que estas bases de datos limitaban en gran medida los tipos de operaciones que los usuarios de datos eran muy vulnerables a cambios en el entorno físico. Si se añadían los controladores de un nuevo disco al sistema y los datos se movían de una localización física a otra, se requería una conversión de los ficheros de datos. Estos sistemas se basaban en el modelo de datos de red y el modelo jerárquico, los dos modelos lógicos que constituyeron la primera generación de los SMBD.

El modelo relacional representa la segunda generación de los SMBD.

datos están estructurados a nivel lógico como tablas formadas por filas y columnas, ver figura 3.1; aunque a nivel físico puede tener una estructura completamente distinta. Un punto fuerte del modelo relacional es la sencillez de su estruestructura hay un fundamento teórico importante del que carecen los SMBD de la primera generación, lo que constituye otro punto a su favor.

NumOficina

O5

O7

O3

O4

Figura Nº 3.1 Relación OFICINA de la base de datos Inmobiliaria, indicando sus partes.

El modelo relacional, como todo modelo de datos, tiene que ver con tres aspectos de los datos:

Las Filas son los registros o tuplas de la relación.

EL MODELO DE DATOS RELACIONAL Al finalizar la unidad, el estudiante estará en la capacidad de convertir el modelo

conceptual de la base de datos, representado en el diagrama E-R, en el modelo lógicorelaciones obtenidas a través del proceso de normalización.

En este apartado se presenta el modelo relacional, que es el modelo lógico en el que se basan la mayoría de los SMBD comerciales, en uso hoy día. En la primera parte de esta unidad, se describen los conceptos básicos del modelo relacional: la estructura de datos relacional y las reglas de integridad. Luego, se presenta la conversión del modelo conceptual de la base de datos (Diagrama Entidad-Relación) al modelo lógico-relacipresenta el proceso de normalización de las relaciones.

3.2 El Modelo Relacional.

En 1970, el modo en que se veían las bases de datos cambió por completo cuando E. F. Codd introdujo el modelo relacional. En aquellos momentos, el enfestructura de las bases de datos utilizaba punteros físicos (direcciones de disco) para relacionar registros de distintos ficheros. Si, por ejemplo, se quería relacionar un registro

, se debía añadir al registro un campo conteniendo la dirección en disco . Este campo añadido, un puntero físico, siempre señalaría desde el registro

. Codd demostró que estas bases de datos limitaban en gran medida los tipos de operaciones que los usuarios podían realizar sobre los datos. Además, estas bases de datos eran muy vulnerables a cambios en el entorno físico. Si se añadían los controladores de un nuevo disco al sistema y los datos se movían de una localización física a otra, se

ión de los ficheros de datos. Estos sistemas se basaban en el modelo de datos de red y el modelo jerárquico, los dos modelos lógicos que constituyeron la primera generación de los SMBD.

El modelo relacional representa la segunda generación de los SMBD. datos están estructurados a nivel lógico como tablas formadas por filas y columnas, ver figura 3.1; aunque a nivel físico puede tener una estructura completamente distinta. Un punto fuerte del modelo relacional es la sencillez de su estructura lógica. Pero detrás de esa simple estructura hay un fundamento teórico importante del que carecen los SMBD de la primera generación, lo que constituye otro punto a su favor.

NumOficina Calle Población Teléfono Fax

Enmedio, 8 Castellón 9640124 9642130

Moreno, s/n Castellón 9642576 9642567

San Miguel, 1 Villarreal 9645225 9645025

Bermúdez, 23 Castellón 9642444 9642440

Relación OFICINA de la base de datos Inmobiliaria, indicando sus partes.Fuente: El autor, 2009.

El modelo relacional, como todo modelo de datos, tiene que ver con tres aspectos de los

1

Al finalizar la unidad, el estudiante estará en la capacidad de convertir el modelo R, en el modelo lógico-

relaciones obtenidas a través del proceso de normalización.

En este apartado se presenta el modelo relacional, que es el modelo lógico en el que se basan la mayoría de los SMBD comerciales, en uso hoy día. En la primera parte de esta unidad, se describen los conceptos básicos del modelo relacional: la estructura de datos

onversión del modelo conceptual relacional. Por último, se

En 1970, el modo en que se veían las bases de datos cambió por completo cuando E. F. Codd introdujo el modelo relacional. En aquellos momentos, el enfoque existente para la estructura de las bases de datos utilizaba punteros físicos (direcciones de disco) para relacionar registros de distintos ficheros. Si, por ejemplo, se quería relacionar un registro

n campo conteniendo la dirección en disco . Este campo añadido, un puntero físico, siempre señalaría desde el registro

. Codd demostró que estas bases de datos limitaban en gran medida los podían realizar sobre los datos. Además, estas bases

de datos eran muy vulnerables a cambios en el entorno físico. Si se añadían los controladores de un nuevo disco al sistema y los datos se movían de una localización física a otra, se

ión de los ficheros de datos. Estos sistemas se basaban en el modelo de datos de red y el modelo jerárquico, los dos modelos lógicos que constituyeron la primera

El modelo relacional representa la segunda generación de los SMBD. En él, todos los datos están estructurados a nivel lógico como tablas formadas por filas y columnas, ver figura 3.1; aunque a nivel físico puede tener una estructura completamente distinta. Un punto fuerte

ctura lógica. Pero detrás de esa simple estructura hay un fundamento teórico importante del que carecen los SMBD de la primera

Fax

9642130

9642567

9645025

9642440

Relación OFICINA de la base de datos Inmobiliaria, indicando sus partes.

El modelo relacional, como todo modelo de datos, tiene que ver con tres aspectos de los

Las columnas son los campos o atributos de la relación.

2

• Estructura de datos. • Integridad de datos. • Manejo de datos.

3.3 Estructura de Datos. 3.3.1 Relaciones.

El modelo relacional se basa en el concepto matemático de relación , que gráficamente se

representa mediante una tabla. Codd, que era un experto matemático, utilizó una terminología perteneciente a las matemáticas, en concreto el de la teoría de conjuntos y de la lógica de predicados. Una relación es una tabla con columnas y filas. Un SMBD sólo necesita que el usuario pueda percibir la base de datos como un conjunto de tablas. Esta percepción sólo se aplica a la estructura lógica de la base de datos (nivel conceptual o lógico de la arquitectura de tres niveles ANSI-SPARC). No se aplica a la estructura física de la base de datos, que se puede implementar con distintas estructuras de almacenamiento. Un atributo es el nombre de una columna de una rela ción . En el modelo relacional, las relaciones se utilizan para almacenar información sobre los objetos que se representan en la base de datos. Una relación se representa gráficamente como una tabla bidimensional en la que las filas corresponden a registros individuales y las columnas corresponden a los campos o atributos de esos registros. Los atributos pueden aparecer en la relación en cualquier orden. La figura 3.1 muestra la relación OFICINA que tiene cinco atributos. Un dominio es el conjunto de valores legales de uno o varios atributos . Los dominios constituyen una poderosa característica del modelo relacional. Cada atributo de una base de datos relacional se define sobre un dominio, pudiendo haber varios atributos definidos sobre el mismo dominio. La tabla de la figura 3.2 muestra los dominios de los atributos de la relación OFICINA de la figura 3.1. Nótese que en esta relación hay dos atributos que están definidos sobre el mismo dominio, Teléfono y Fax.

Nombre del campo Descripción Definición NumOficina Número de la oficina 3 caracteres Calle Nombre de la calle donde se ubica la oficina 25 caracteres Población Nombre de la poblaciones donde se ubica la oficina 25 caracteres Teléfono Número de teléfono de la oficina 11 caracteres Fax Número de fax de la oficina 11 caracteres

Tabla Nº 3.1 Dominio de valores de la relación OFICINA. Fuente: El autor, 2009.

El concepto de dominio es importante porque permite que el usuario defina, en un lugar

común, el significado y la fuente de los valores que los atributos pueden tomar. Esto hace que haya más información disponible para el sistema cuando éste va a ejecutar una operación relacional, de modo que las operaciones que son semánticamente incorrectas, se pueden evitar. Por ejemplo, no tiene sentido comparar el nombre de una calle con un número de teléfono, aunque los dos atributos sean cadenas de caracteres. Sin embargo, el importe mensual del alquiler de un inmueble no estará definido sobre el mismo dominio que el número

de meses que dura el alquiler, pero sí tiene sentido multiplicar los valores de ambos dominios para averiguar el importe total al que asciende el un soporte completo de los dominios ya que su implementación es extremadamente compleja.

Una tupla es una fila de una relación.

filas de la tabla. En la relación valores, uno para cada atributo. Las tuplas de una relación no siguen ningún orden.

El grado de una relación es el número de campos que contiene

de la figura 3.1 es de grade la tabla es una tupla con cinco valores. El grado de una relación no cambia con frecuencia.

La cardinalidad de una relación es el número de tup las que contiene.

relaciones se van insertando y borrando tuplas a menudo, la cardinalidad de las mismas varía constantemente. La relación OFICINA, figura 3.1, es de cardinalidad cuatro. 3.3.1.1 Propiedades de las relaciones.

• Cada relación tiene un nombr• Los valores de los atributos son atómicos: en cada tupla, cada atributo toma un solo

valor. De ser así, se dice que la relación están • No hay dos atributos, dentro de una misma relación, q• El orden de los atributos no importa: los atributos no están ordenados. • Cada tupla es distinta de las demás: no hay tuplas duplicadas. • El orden de las tuplas no importa: las tuplas no están ordenadas.

3.3.1.2 Clave Primaria de las

Ya que en una relación no hay tuplas repetidas, éstas se pueden distinguir unas de otras, es decir, se pueden identificar de modo único. La forma de identificarlas es mediante los valores de sus atributos.

• Una superclave

único las tuplas de una relación. • Una clave candidata

una superclave de la relación. El atributo o conjunto de atributos es una clave candidata para • Unicidad: nunca hay dos tuplas en la relación • Irreducibilidad (minimalidad):

unicidad, es decir, no se puedeunicidad.

Cuando una clave candidata está formada por más de un atributo, se dice que es una

clave compuesta . Una relación puede tener varias claves candidatas. Por ejemplo, en la relación OFICINA de la figura puede haber varias oficinas en una misma población. Sin embargo, ya que la empresa asigna

de meses que dura el alquiler, pero sí tiene sentido multiplicar los valores de ambos dominios para averiguar el importe total al que asciende el alquiler. Los SMBD relacionales no ofrecen un soporte completo de los dominios ya que su implementación es extremadamente compleja.

Una tupla es una fila de una relación. Los elementos de una relación son las tuplas o filas de la tabla. En la relación OFICINA, figura 3.1, existen cuatro tuplas, cada una tiene seis valores, uno para cada atributo. Las tuplas de una relación no siguen ningún orden.

El grado de una relación es el número de campos que contienees de grado cinco porque tiene cinco atributos. Esto quiere decir que cada fila

de la tabla es una tupla con cinco valores. El grado de una relación no cambia con frecuencia.

La cardinalidad de una relación es el número de tup las que contiene.relaciones se van insertando y borrando tuplas a menudo, la cardinalidad de las mismas varía constantemente. La relación OFICINA, figura 3.1, es de cardinalidad cuatro.

3.3.1.1 Propiedades de las relaciones.

Cada relación tiene un nombre y éste es distinto del nombre de todas las demás. Los valores de los atributos son atómicos: en cada tupla, cada atributo toma un solo valor. De ser así, se dice que la relación están normalizadas. No hay dos atributos, dentro de una misma relación, que se llamen igual. El orden de los atributos no importa: los atributos no están ordenados. Cada tupla es distinta de las demás: no hay tuplas duplicadas. El orden de las tuplas no importa: las tuplas no están ordenadas.

3.3.1.2 Clave Primaria de las relaciones.

Ya que en una relación no hay tuplas repetidas, éstas se pueden distinguir unas de otras, es decir, se pueden identificar de modo único. La forma de identificarlas es mediante los valores de sus atributos.

es un atributo o un conjunto de atributos que identifican de modo único las tuplas de una relación.

clave candidata es una superclave en la que ninguno de sus subconjuntos es una superclave de la relación. El atributo o conjunto de atributos

lave candidata para si y sólo si satisface las siguientes propiedades: nunca hay dos tuplas en la relación con el mismo valor de

Irreducibilidad (minimalidad): ningún subconjunto de unicidad, es decir, no se pueden eliminar componentes de

Cuando una clave candidata está formada por más de un atributo, se dice que es una . Una relación puede tener varias claves candidatas. Por ejemplo, en la

OFICINA de la figura 3.1, el atributo Población no es una clave candidata ya que puede haber varias oficinas en una misma población. Sin embargo, ya que la empresa asigna

3

de meses que dura el alquiler, pero sí tiene sentido multiplicar los valores de ambos dominios alquiler. Los SMBD relacionales no ofrecen

un soporte completo de los dominios ya que su implementación es extremadamente compleja.

Los elementos de una relación son las tuplas o , figura 3.1, existen cuatro tuplas, cada una tiene seis

valores, uno para cada atributo. Las tuplas de una relación no siguen ningún orden.

El grado de una relación es el número de campos que contiene . La relación OFICINA do cinco porque tiene cinco atributos. Esto quiere decir que cada fila

de la tabla es una tupla con cinco valores. El grado de una relación no cambia con frecuencia.

La cardinalidad de una relación es el número de tup las que contiene. Ya que en las relaciones se van insertando y borrando tuplas a menudo, la cardinalidad de las mismas varía constantemente. La relación OFICINA, figura 3.1, es de cardinalidad cuatro.

e y éste es distinto del nombre de todas las demás. Los valores de los atributos son atómicos: en cada tupla, cada atributo toma un solo

ue se llamen igual. El orden de los atributos no importa: los atributos no están ordenados.

El orden de las tuplas no importa: las tuplas no están ordenadas.

Ya que en una relación no hay tuplas repetidas, éstas se pueden distinguir unas de otras, es decir, se pueden identificar de modo único. La forma de identificarlas es mediante los

conjunto de atributos que identifican de modo

es una superclave en la que ninguno de sus subconjuntos es una superclave de la relación. El atributo o conjunto de atributos de la relación

si y sólo si satisface las siguientes propiedades: con el mismo valor de .

tiene la propiedad de n eliminar componentes de sin destruir la

Cuando una clave candidata está formada por más de un atributo, se dice que es una . Una relación puede tener varias claves candidatas. Por ejemplo, en la

no es una clave candidata ya que puede haber varias oficinas en una misma población. Sin embargo, ya que la empresa asigna

4

un código único a cada oficina, el atributo NumOficina sí es una clave candidata de la relación OFICINA. También son claves candidatas de esta relación los atributos Teléfono y Fax.

En una base de datos de Inmobiliaria hay una relación denominada VISITA, la cual se

muestra a continuación, figura 3.3, que contiene información sobre las visitas que los clientes han realizado a los inmuebles. Esta relación contiene el número del cliente Qnum, el número del inmueble Inum, la fecha de la visita Fecha, ID del empleado que efectuó la visita IDEmpleado y un Comentario opcional. Para un determinado número de cliente Qnum, se pueden encontrar varias visitas a varios inmuebles. Del mismo modo, dado un número de inmueble Inum, puede que haya varios clientes que lo hayan visitado. Por lo tanto, el atributo Qnum no es una clave candidata para la relación VISITA, como tampoco lo es el atributo Inum. Sin embargo, la combinación de los dos atributos sí identifica a una sola tupla, por lo que los dos juntos son una clave candidata de VISITA. Si se desea considerar la posibilidad de que un mismo cliente pueda visitar un mismo inmueble en varias ocasiones, habría que incluir el atributo Fecha para identificar las tuplas de modo único (aunque éste no es el caso de la empresa Inmobiliaria del ejemplo).

Qnum Inum Fecha IDEmpleado Comentario

Q76 IA14 12/03/1999 1182 Muy amplia y bien ubicada

Q74 IG40 30/11/1999 1285 Falta pintura a las paredes

Q62 IG36 25/10/1998 1182 Grandes espacios

Q74 IG36 14/08/1998 5682 Muy hermosa

Tabla Nº 3.2 Relación VISITA de la base de datos Inmobiliaria. Fuente: El autor, 2009.

El único modo de identificar las claves candidatas es conociendo el significado real de los

atributos, ya que esto permite saber si es posible que aparezcan duplicados. Sólo usando esta información semántica se puede saber con certeza si un conjunto de atributos forman una clave candidata.

• La clave primaria de una relación es aquella clave candidata que se escoge para

identificar sus tuplas de modo único. Ya que una relación no tiene tuplas duplicadas, siempre hay una clave candidata y, por lo tanto, la relación siempre tiene clave primaria. En el peor caso, la clave primaria estará formada por todos los atributos de la relación, pero normalmente habrá un pequeño subconjunto de los atributos que haga esta función.

• Las claves candidatas que no son escogidas como clave primaria son denominadas

claves alternativas . Por ejemplo, la clave primaria de la relación OFICINA, figura 3.1, es el atributo NumOficina, siendo Teléfono y Fax dos claves alternativas. En la relación VISITA, figura 3.3, sólo hay una clave candidata formada por los atributos Qnum e Inum, por lo que esta clave candidata es la clave primaria.

3.3.1.3 Clave Foránea o Ajena de las relaciones.

Una clave foránea es un atributo o un conjunto de atributos de una relación cuyos valores coinciden con los valores de la clave primaria de alguna otra relación (puede ser la misma). Las claves ajenas representan relaciones entre datos. El atributo IDEmpleado de

5

VISITA, figura 3.3, es una clave ajena o foránea cuyos valores hacen referencia al atributo IDEmpleado, clave primaria de la relación EMPLEADO, figura 3.4.

IDEmplea

do Nombre Apellido Cargo Salario

1182 Pedro Pérez Asistente 958.00

1285 Juan López Jefe de Inmuebles 2458,45

2586 María Pérez Administrador 3586,12

5682 Ana Marchan Asistente 1024,00

Tabla Nº 3.3 Relación EMPLEADO de la base de datos Inmobiliaria. Fuente: El autor, 2009.

En el ámbito de las bases de datos relacionales, una clave foránea es una restricción

referencial entre dos relaciones. La clave foránea establece que un grupo de atributos, en una relación, hace referencia a otro grupo de atributos, en otra. La primera relación se denomina referenciante (relación EMPLEADO), mientras que la segunda, referenciada (relación VISITA).

Los atributos que son clave foránea en la relación referenciante deben ser clave primaria

o clave candidata en la relación referenciada. Implementar una clave foránea establece que ciertos atributos de la relación referenciante sólo podrán admitir elementos que existan previamente en determinados atributos de la relación referenciada.

La clave foránea es, entonces, una característica importante en una base de datos. Su utilización impropia puede generar problemas. Su principal objetivo es mantener la integridad de la información almacenada.

Una base de datos relacional es un conjunto de rela ciones normalizadas. Para

representar el esquema de una base de datos relacio nal se debe dar el nombre de sus relaciones, los atributos de éstas, los dominios so bre los que se definen estos atributos, las claves primarias y las claves ajenas . 3.4 Integridad de Datos.

Una vez definida la estructura de datos del modelo relacional, se pasa a estudiar las reglas de integridad que los datos almacenados en dicha estructura deben cumplir para garantizar que son correctos.

Al definir cada atributo sobre un dominio se impone una restricción sobre el conjunto de

valores permitidos para cada atributo. A este tipo de restricciones se les denomina restricciones de dominios. Hay además dos reglas de integridad muy importantes que son restricciones que se deben cumplir en todas las bases de datos relacionales y en todos sus estados o instancias (las reglas se deben cumplir todo el tiempo). Estas reglas son la regla de integridad de entidades y la regla de integridad referencial.

Una base de datos que no cumpla con alguna de estas dos reglas, se dice que la base

de datos está en estado ilegal; si cumple con ambas, estará en estado legal. Antes de definir ambas reglas, es preciso conocer el concepto de valor nulo. ¿Qué es un valor Nulo?

6

Cuando en una tupla un atributo es desconocido, se dice que es nulo. Un nulo no representa el valor cero ni la cadena vacía, éstos son valores que tienen significado. El nulo implica ausencia de información, bien porque al insertar la tupla se desconocía el valor del atributo, o bien porque para dicha tupla el atributo no tiene sentido.

Ya que los nulos no son valores, deben tratarse de modo diferente, lo que causa

problemas de implementación. De hecho, no todos los SMBD relacionales soportan los nulos.

3.4.1 Regla de Integridad de Entidades.

La primera regla de integridad se aplica a las claves primarias de las relaciones base: ninguno de los atributos que componen la clave primaria puede ser nulo.

Por definición, una clave primaria es un identificador irreducible que se utiliza para

identificar de modo único las tuplas. Irreducible significa que ningún subconjunto de la clave primaria sirve para identificar las tuplas de modo único. Si se permite que parte de la clave primaria sea nula, se está diciendo que no todos sus atributos son necesarios para distinguir las tuplas, con lo que se contradice la irreducibilidad.

Nótese que esta regla sólo se aplica a las relaciones base y a las claves primarias, no a

las claves alternativas.

3.4.2 Regla de Integridad Referencial

La segunda regla de integridad se aplica a las claves ajenas: si en una relación hay alguna clave ajena, sus valores deben coincidir con valores de la clave primaria a la que hace referencia, o bien, deben ser completamente nulos.

La regla de integridad referencial se enmarca en términos de estados de la base de datos: indica lo que es un estado ilegal, pero no dice cómo puede evitarse. La cuestión es ¿qué hacer si estando en un estado legal, llega una petición para realizar una operación que conduce a un estado ilegal? Existen dos opciones: rechazar la operación, o bien aceptar la operación y realizar operaciones adicionales compensatorias que conduzcan a un estado legal.

Por lo tanto, para cada clave ajena de la base de datos habrá que contestar a tres

preguntas: • Regla de los nulos: ¿Tiene sentido que la clave ajena acepte nulos? • Regla de borrado: ¿Qué ocurre si se intenta borrar la tupla referenciada por la clave

ajena? o Restringir: no se permite borrar la tupla referenciada. o Propagar: se borra la tupla referenciada y se propaga el borrado a las tuplas

que la referencian mediante la clave ajena. o Anular: se borra la tupla referenciada y las tuplas que la referenciaban ponen a

nulo la clave ajena (sólo si acepta nulos). • Regla de modificación: ¿Qué ocurre si se intenta modificar el valor de la clave primaria

de la tupla referenciada por la clave ajena? o Restringir: no se permite modificar el valor de la clave primaria de la tupla

referenciada.

7

o Propagar: se modifica el valor de la clave primaria de la tupla referenciada y se propaga la modificación a las tuplas que la referencian mediante la clave ajena.

o Anular: se modifica la tupla referenciada y las tuplas que la referenciaban ponen a nulo la clave ajena (sólo si acepta nulos).

3.4.3 Reglas de negocio.

Además de las dos reglas de integridad anteriores, los usuarios o los administradores de la base de datos pueden imponer ciertas restricciones específicas sobre los datos, denominadas reglas de negocio. Por ejemplo, si en una oficina de la empresa inmobiliaria sólo puede tener hasta veinte empleados, el SMBD debe dar la posibilidad al usuario de definir una regla al respecto y debe hacerla respetar. En este caso, no debería permitir ingresar un nuevo empleado en una oficina que ya tiene los veinte permitidos.

Hoy en día aún existen SMBD relacionales que no permiten definir este tipo de

restricciones ni las hacen respetar. 3.5 Manejo de Datos.

La tercera parte de un modelo de datos es la de la manipulación. Son varios los lenguajes utilizados por los SMBD relacionales para manejar las relaciones. Algunos de ellos son procedurales, lo que quiere decir que el usuario dice al sistema exactamente cómo debe manipular los datos. Otros son no procedurales, que significa que el usuario dice qué datos necesita, en lugar de decir cómo deben obtenerse.

En este apartado se presentan el álgebra relacional y el cálculo relacional, definidos por Codd como la base de los lenguajes relacionales. Se puede decir que el álgebra es un lenguaje procedural (de alto nivel), mientras que el cálculo relacional es un lenguaje no procedural. Sin embargo, ambos lenguajes son equivalentes: para cada expresión del álgebra, se puede encontrar una expresión equivalente en el cálculo, y viceversa.

El álgebra relacional (o el cálculo relacional) se utilizan para medir la potencia de los

lenguajes relacionales. Si un lenguaje permite obtener cualquier relación que se pueda derivar mediante el álgebra relacional, se dice que es relacionalmente completo. La mayoría de los lenguajes relacionales son relacionalmente completos, pero tienen más potencia que el álgebra o el cálculo porque se les han añadido operadores especiales.

Tanto el álgebra como el cálculo son lenguajes formales no muy “amigables”. Pero su

estudio sirve para ilustrar las operaciones básicas que todo lenguaje de manejo datos debe ofrecer. Estos lenguajes, han sido la base para otros lenguajes relacionales de manejo de datos de más alto nivel, como el SQL.

La Unidad Nº IV estudia el Lenguajes SQL, como el lenguaje a utilizar para realizar el

manejo de la base de datos. 3.5.1 Vistas

8

En la arquitectura de tres niveles, estudiada en la Unidad I figura Nº 1.3, se describe una vista externa como la estructura de la base de datos tal y como la ve un usuario en particular. En el modelo relacional, el término “vista” tiene un significado un tanto diferente. En lugar de ser todo el esquema externo de un usuario, una vista es una relación virtual, una relación que en realidad no existe como tal.

Una vista se puede construir realizando operaciones como las del álgebra relacional:

restricciones, proyecciones, concatenaciones, etc. a partir de las relaciones base de la base de datos. Las relaciones base son aquellas que forman parte directa de la base de datos, las que se encuentran almacenadas físicamente. Un esquema externo puede tener tanto relaciones base como vistas derivadas de las relaciones base de la base de datos.

Una vista es el resultado dinámico de una o varias operaciones relacionales realizadas

sobre las relaciones base. Una vista es una relación virtual que se produce cuando un usuario la consulta. Al usuario le parece que la vista es una relación que existe y la puede manipular como si se tratara de una relación base, pero la vista no está almacenada físicamente. El contenido de una vista está definido como una consulta sobre una o varias relaciones base. Cualquier operación que se realice sobre la vista se traduce automáticamente a operaciones sobre las relaciones de las que se deriva.

Las vistas son dinámicas porque los cambios que se realizan sobre las tablas base que

afectan a una vista se reflejan inmediatamente sobre ella. Cuando un usuario realiza un cambio sobre la vista (no todo tipo de cambios están permitidos), este cambio se realiza sobre las relaciones de las que se deriva. Las vistas son útiles por varias razones:

• Proporcionan un poderoso mecanismo de seguridad, ocultando partes de la base de

datos a ciertos usuarios. El usuario no sabrá que existen aquellos atributos que se han omitido al definir una vista.

• Permiten que los usuarios accedan a los datos en el formato que ellos desean o

necesitan, de modo que los mismos datos pueden ser vistos con formatos distintos por distintos usuarios.

• Se pueden simplificar operaciones sobre las relaciones base que son complejas. Por

ejemplo, se puede definir una vista como la concatenación de dos relaciones. El usuario puede hacer restricciones y proyecciones sobre la vista, que el SMBD traducirá en las operaciones equivalentes sobre la concatenación.

Se puede utilizar una vista para ofrecer un esquema externo a un usuario de modo que

éste lo encuentre “familiar”. Por ejemplo: • Un usuario puede necesitar los datos de los Empleados junto con los de las Visitas.

Esta vista se crea haciendo una concatenación de las relaciones VISITA y EMPLEADO, y proyectando sobre los atributos que se desee mantener, ver figura siguiente.

Qnum Inum IDEmpleado Nombre Apellido Comentario Q76 IA14 1182 Pedro Pérez Muy amplia y bien ubicada Q74 IG40 1285 Juan López Falta pintura a las paredes Q62 IG36 1182 Pedro Pérez Grandes espacios Q74 IG36 5682 Ana Marchan Muy hermosa

9

Tabla Nº 3.4 Vista de las relaciones EMPLEADO y VISITA de la base de datos Inmobiliaria. Fuente: El autor, 2009.

• Otro usuario puede que necesite ver los datos de los empleados sin ver el salario.

Para este usuario se realiza una proyección para crear una vista sin el atributo salario.

IDEmpleado Nombre Apellido Cargo

1182 Pedro Pérez Asistente 1285 Juan López Jefe de Inmuebles 2586 María Pérez Administrador 5682 Ana Marchan Asistente

Tabla Nº 3.5 Vista de la relación EMPLEADO de la base de datos Inmobiliaria. Fuente: El autor, 2009.

• Los atributos se pueden renombrar, de modo que cada usuario los vea del modo en que esté acostumbrado. También se puede cambiar el orden en que se visualizan las columnas.

IDEmpleado ApellidoEmpleado NombreEmpleado CargoActu al 1182 Pérez Pedro Asistente 1285 López Juan Jefe de Inmuebles 2586 Pérez María Administrador 5682 Marchan Ana Asistente

Tabla Nº 3.6 Vista de la relación EMPLEADO de la base de datos Inmobiliaria. Fuente: El autor, 2009.

• El Cliente Nº Q74 de la base de datos Inmobiliaria, relación VISITA de la figura 3.3, quiere ver que Inmuebles ella ha visitado. En este caso, se debe hacer una restricción para que sólo se vea el subconjunto horizontal deseado de la relación VISITA.

Qn

um Inum Fecha IDEmpleado Comentario

Q74 IG40 30/11/1999 1285 Falta pintura a las paredes Q74 IG36 14/08/1998 5682 Muy hermosa

Tabla Nº 3.7 Vista de la relación VISITA de la base de datos Inmobiliaria. Fuente: El autor, 2009.

Como se pudo observar, las vistas proporcionan independencia de datos a nivel lógico,

que también se da cuando se reorganiza el nivel conceptual. Si se añade un atributo a una relación, los usuarios no se percatan de su existencia si sus vistas no lo incluyen. Si una relación existente se reorganiza o se divide en varias relaciones, se pueden crear vistas para que los usuarios la sigan viendo como al principio.

Cuando se actualiza una relación base, el cambio se refleja automáticamente en todas

las vistas que la referencian. Del mismo modo, si se actualiza una vista, las relaciones base de las que se deriva deberían reflejar el cambio. Sin embargo, hay algunas restricciones respecto

10

a los tipos de modificaciones que se pueden realizar sobre las vistas. A continuación, se resumen las condiciones bajo las cuales la mayoría de los sistemas determinan si se permite realizar una actualización:

• Se permiten las actualizaciones de vistas que se definen mediante una consulta simple

sobre una sola relación base y que contienen la clave primaria de la relación base. • No se permiten las actualizaciones de vistas que se definen sobre varias relaciones

base.

• No se permiten las actualizaciones de vistas definidas con operaciones de agrupamiento (GROUPBY).

3.6. Conversión del Modelo Conceptual al Modelo Lóg ico-Relacional.

Una vez obtenido el modelo conceptual de la base de datos, a través de la construcción del diagrama Entidad-Relación o diagrama Entidad-Relación Extendido, se procede a la construcción del modelo lógico de la base de datos (segunda fase en el diseño de bases de datos). Este modelo lógico va a depender del modelo de datos seleccionados, en nuestro caso el modelo de datos es el relacional; el cual se acaba de estudiar.

En esta etapa se obtiene un conjunto de relaciones (tablas) que representen los datos de

interés. Este conjunto de relaciones obtenidas, posteriormente se valida mediante la normalización, técnica que se estudia al final de esta unidad, en el punto 3.8.

Primeramente, se construye el modelo lógico relacional eliminando del diagrama E-R las estructuras de datos que no se pueden implementar de manera directa sobre el modelo relacional.

3.6.1 Convertir el diagrama Entidad-Relación al mod elo lógico-relacional.

En este paso, se eliminan del modelo conceptual (diagrama E-R) las estructuras de datos que los sistemas relacionales no modelan directamente:

1. Eliminar las relaciones con cardinalidad mucho a mu cho (ver figura 3.2a), sustituyendo cada una de ellas por una nueva entidad intermedia y dos relaciones con cardinalidad uno a muchos desde esta nueva entidad con las entidades originales, figura 3.2b. La nueva entidad será débil, ya que sus ocurrencias dependen de la existencia de ocurrencias en las entidades originales. Ejemplo en la siguiente figura:

11

Figura Nº 3.2 Sustitución de una relación mucho a mucho por una entidad débil.

Fuente: El autor, 2009.

2. Eliminar las relaciones ternarias (ver figura 3.3a), sustituyendo cada una de ellas por una nueva entidad intermedia (débil) que se relaciona con cada una de las entidades originales, ver figura 3.3b. La cardinalidad de estas nuevas relaciones binarias dependerá de su significado. Ejemplo en la siguiente figura:

a) Relación Ternaria. Faltan los atributos.

b) Entidad débil con tres relaciones uno a mucho. Faltan los atributos.

Figura Nº 3.3 Sustitución de una relación ternaria por una entidad débil. Fuente: El autor, 2009.

3. Eliminar las relaciones recursivas (ver figura 3.4a), sustituyendo cada una de ellas por una nueva entidad (débil) y una relación binarias con la entidad original. La cardinalidad de estas relaciones dependerá de su significado. Ejemplo figura siguiente:

a) Relación recursiva. Faltan los atributos.

Estudiante Préstamo

a) Relación con cardinalidad mucho a mucho. Faltan los atributos.

Libro Préstamo Esta Estudiante Realiza

b) Entidad débil con dos relaciones uno a mucho. Faltan los atributos.

Empleado

Servicio

Cliente

Presta Consultor

Supervisa

Supervisor

Consultor Servicio

Cliente

Cliente Consultor Servicio

Figura Nº 3.4

4. Eliminar las relaciones con atributospor una nueva entidad (débil) y las relaciones binarias correspondientes de esta nueva entidad con las entidades originales, figura 3.5b. La cardinalidad de estas relatipo de la relación original y de su significado. Ejemplo en la figura siguiente:

Figura Nº 3.5

5. Eliminar los atributos multievaluados por una nueva entidad (débil) y una relación binaria de uno a muchos con la entidad original, ver figura 3.6b. Ejemplo figura siguiente.

b) Entidad débil con una relación binaria.

Figura Nº 3.6

Cédula

Cliente

Nombre DirecciónCURP

b) Entidad débil con una relación uno a mucho. Faltan los atributos.

Figura Nº 3.4 Sustitución de una relación recursiva por una entidad débil.Fuente: El autor, 2009.

Eliminar las relaciones con atributos (ver figura 3.5a), sustituyendo cada una de ellas por una nueva entidad (débil) y las relaciones binarias correspondientes de esta nueva entidad con las entidades originales, figura 3.5b. La cardinalidad de estas relatipo de la relación original y de su significado. Ejemplo en la figura siguiente:

a) Relación con atributos.

b) Entidad débil con dos relaciones binarias.

Figura Nº 3.5 Sustitución de una relación con atributos por una entidad débil.Fuente: El autor, 2009.

Eliminar los atributos multievaluados (ver figura 3.6a), sustituyendo cada uno de ellos por una nueva entidad (débil) y una relación binaria de uno a muchos con la entidad original, ver figura 3.6b. Ejemplo figura siguiente.

a) Entidad con atributo multivaluado.

Entidad débil con una relación binaria.

Figura Nº 3.6 Sustitución de un atributo multivaluado por una entidad débil.Fuente: El autor, 2009.

Teléfonos Cliente

Cliente

Nombre Número

Supervisor Empleado Supervisa

Dirección

ClienteCta

Fecha Tipo Cta.

Cliente

cédula Nombre Teléfonos

12

Entidad débil con una relación uno a mucho. Faltan los atributos.

Sustitución de una relación recursiva por una entidad débil.

(ver figura 3.5a), sustituyendo cada una de ellas por una nueva entidad (débil) y las relaciones binarias correspondientes de esta nueva entidad con las entidades originales, figura 3.5b. La cardinalidad de estas relaciones dependerá del tipo de la relación original y de su significado. Ejemplo en la figura siguiente:

Sustitución de una relación con atributos por una entidad débil.

sustituyendo cada uno de ellos por una nueva entidad (débil) y una relación binaria de uno a muchos con la entidad original,

Sustitución de un atributo multivaluado por una entidad débil.

Cuenta

Tipo Cta. Saldo No_Cta

13

3.6.2 Derivar el conjunto de relaciones (tablas).

En este paso, se obtiene el conjunto de relaciones (tablas) para el esquema lógico. Cada relación de la base de datos tendrá un nombre, y el nombre de sus atributos. El atributo o los atributos que forman la clave primaria se subrayan. Las claves ajenas o foráneas, mecanismo que se utiliza para representar las relaciones entre entidades en el modelo relacional, se especifican aparte indicando la relación (tabla) a la que hacen referencia.

A continuación, se describe cómo las relaciones (tablas) del modelo relacional

representan las entidades y relaciones que aparecer en los esquemas lógicos (diagrama E-R). 1. Entidades fuertes . Crear una relación (tabla) para cada entidad fuerte del diagrama E-R que incluya todos los atributos simples de la entidad. De los atributos compuestos, incluir en la relación sólo sus componentes, ver figura 3.7.

Cada uno de los identificadores de la entidad será una clave candidata de la relación

(tabla). De entre las claves candidatas hay que escoger la clave primaria; el resto serán claves alternativas. Para escoger la clave primaria entre las claves candidatas se pueden seguir estas indicaciones:

• Escoger la clave candidata que tenga menos atributos. • Escoger la clave candidata cuyos valores no tengan probabilidad de cambiar en el futuro. • Escoger la clave candidata cuyos valores no tengan probabilidad de perder la unicidad en

el futuro. • Escoger la clave candidata con el mínimo número de caracteres (si es de tipo texto). • Escoger la clave candidata más fácil de utilizar desde el punto de vista de los usuarios.

Tabla: Cliente

Figura 3.7 Conversión de una entidad fuerte en una tabla de la base de datos.

Fuente: El autor, 2009.

2. Entidades débiles. Para cada entidad débil del diagrama E-R, crear una relación (tabla) incluyendo todos sus atributos simples. De los atributos compuestos incluir sólo sus componentes. Añadir a la relación (tabla) una clave ajena o foránea. Para ello, se incluye la clave primaria de la relación (tabla) que representa a la entidad fuerte o padre, en la nueva relación creada para la entidad débil, ver figura 3.8. Subrayar la clave primaria, en este caso se trata de una clave primaria compuesta.

Tabla: TeléfonosCliente

Cédula Nombre Avenida Calle N_Casa

Teléfonos Cliente

Cliente

cédula Nombre Número

Entidad Débil Entidad Fuerte

Dirección

Calle

Avenida N_Casa

Teléfonos Cliente

Cliente

cédula Nombre

Entidad Débil Entidad Fuerte

Dirección

Calle

Avenida N_Casa

Número

14

Figura 3.8 Conversión de una entidad débil en una tabla de la base de datos. Fuente: El autor, 2009.

3. Relaciones binarias de uno a uno. Para cada relación binaria de uno a uno del diagrama E-R, se debe incluir los atributos candidatos de la entidad padre en la relación (tabla) que representa a la entidad hijo, para actuar como una clave ajena. La entidad hijo es la que participa de forma total (obligatoria) en la relación, mientras que la entidad padre es la que participa de forma parcial (opcional). Si las dos entidades participan de forma total o parcial en la relación uno a uno, la elección de padre e hijo es arbitraria. Además, en caso de que ambas entidades participen de forma total en la relación, se tiene la opción de integrar las dos entidades en una sola relación (tabla). Esto se suele hacer si una de las entidades no participa en ninguna otra relación. Ver figura 3.9.

Tabla: Presidente Tabla: País Nombre Dirección Partido NomPais Nombre Habitantes Dimensión

Figura 3.9 Conversión de una relación binaria de uno a uno al modelo relacional.

Fuente: El autor, 2009.

4. Relaciones binarias de uno a muchos . Como en las relaciones binarias de uno a uno, se incluyen los atributos de la clave primaria de la entidad padre en la relación (tabla) que representa a la entidad hijo, para actuar como una clave ajena. Pero ahora, la entidad padre es “la parte del muchos'' (cada padre tiene muchos hijos), mientras que la entidad hijo es “la parte del uno'' (cada hijo tiene un solo padre). Ver figura siguiente.

Cédula Número

Entidad Hijo Entidad Padre

Hijos Empleado

cédula Nombre Edad

Entidad Débil Entidad Fuerte

Cargo Cédula Nombre

´Tabla: Empleado Cédula Nombre Cargo

Figura 3.10 Conversión de una relación binaria de uno a uno al modelo relacional.

3.6.3 Paso de ERE a Modelo Relacional.

El paso de ERE a modelo relacional es una extensión de las normas del paso EntidadRelación. Las reglas complementarias hacen referencia a los elementos propios del ERE y son las siguientes:

Existen cuatro opciones

Superclase/Subclase correspondientes a Especializaciones o Generalizaciones.

Opción A: Crear una relación (tabla) para la superclase, con sus atributos correspondientes y una relación (tabla) parsuperclase. Esta opción es válida para especializaciones parciales o totales y con restricción de desunión o solapamiento. Ver figura 3.11.

EMPLEADO

DNI Pila Ape1 Ape2 Fecha

SECRETARIA

DNI Veloc

Figura 3.11 Conversión de una relación Superclase/Subclase al modelo relacional. Opción A.

Opción B: Crear para cada subclase una relación con los atributos de la superclase más los atributos propios, donde la clave primaria será la de la superclase. Esta opción sólo es válida para las especializaciones con restricción de totalidad y desunión ya que, si

Tabla: Hijos Cargo CédulaPadre Cédula Nombre

Conversión de una relación binaria de uno a uno al modelo relacional.Fuente: El autor, 2009.

Paso de ERE a Modelo Relacional.

El paso de ERE a modelo relacional es una extensión de las normas del paso EntidadRelación. Las reglas complementarias hacen referencia a los elementos propios del ERE y

Existen cuatro opciones para realizar el paso a modelo relacional de las relaciones Superclase/Subclase correspondientes a Especializaciones o Generalizaciones.

Crear una relación (tabla) para la superclase, con sus atributos correspondientes y una relación (tabla) para cada subclase con sus atributos más la clave primaria de la superclase. Esta opción es válida para especializaciones parciales o totales y con restricción de desunión o solapamiento. Ver figura 3.11.

Fecha Dir tipoTrabajo

TECNICO INGENIERO

DNI Nivel DNI

Conversión de una relación Superclase/Subclase al modelo relacional. Opción A.Fuente: El autor, 2009.

Crear para cada subclase una relación con los atributos de la superclase más los atributos propios, donde la clave primaria será la de la superclase. Esta opción sólo es válida para las especializaciones con restricción de totalidad y desunión ya que, si

15

Edad

Conversión de una relación binaria de uno a uno al modelo relacional.

El paso de ERE a modelo relacional es una extensión de las normas del paso Entidad-Relación. Las reglas complementarias hacen referencia a los elementos propios del ERE y

para realizar el paso a modelo relacional de las relaciones Superclase/Subclase correspondientes a Especializaciones o Generalizaciones.

Crear una relación (tabla) para la superclase, con sus atributos correspondientes y a cada subclase con sus atributos más la clave primaria de la

superclase. Esta opción es válida para especializaciones parciales o totales y con restricción

INGENIERO

Tipo

Conversión de una relación Superclase/Subclase al modelo relacional. Opción A.

Crear para cada subclase una relación con los atributos de la superclase más los atributos propios, donde la clave primaria será la de la superclase. Esta opción sólo es válida para las especializaciones con restricción de totalidad y desunión ya que, si una ocurrencia de

la superclase no pertenece a ninguna de las subclases, se pierde; y si pertenece a más de una, sus datos aparecen de forma redundante en más de una relación. Además tiene el inconveniente de que al buscar una ocurrencia cualquiera de la srecorrer todas las relaciones. Ver figura siguiente:

COCHE Nºvehiculo Matrícula Precio

CAMION Nºvehiculo Matrícula Precio

Figura 3.12 Conversión de una relación Superclase/Subclase al modelo relacional. Opción B.

Opción C: Crear una sola relación con todos los atributos de la superclase y las subclases más un atributo T que indica la subclase a la que la tupla especialización de clases desunidas y puede generar muchos valores nulos. Esta opción no es apropiada cuando se utilizan muchos atributos de definición para la especialización. Si se utilizan pocos atributos de especificacque, no requiere la utilización de JOIN para la conformación de la superclase completa. Ver figura:

PERSONA DNI Nombre Sexo

Figura 3.13 Conversión de una relación Superclase/Subclase al modelo relacional. Opción C

la superclase no pertenece a ninguna de las subclases, se pierde; y si pertenece a más de una, sus datos aparecen de forma redundante en más de una relación. Además tiene el inconveniente de que al buscar una ocurrencia cualquiera de la superclase, tendremos que recorrer todas las relaciones. Ver figura siguiente:

Precio V.max Nºpas

Precio Nºejes Peso

Conversión de una relación Superclase/Subclase al modelo relacional. Opción B.Fuente: El autor, 2009.

Crear una sola relación con todos los atributos de la superclase y las subclases más un atributo T que indica la subclase a la que la tupla pertenece. Esto corresponde a una especialización de clases desunidas y puede generar muchos valores nulos. Esta opción no es apropiada cuando se utilizan muchos atributos de definición para la especialización. Si se utilizan pocos atributos de especificación, esta opción es preferible a las opciones A y B, ya que, no requiere la utilización de JOIN para la conformación de la superclase completa. Ver

Sexo Dir Fecha-n Sueldo especialidad TipoPersona

Conversión de una relación Superclase/Subclase al modelo relacional. Opción CFuente: El autor, 2009.

16

la superclase no pertenece a ninguna de las subclases, se pierde; y si pertenece a más de una, sus datos aparecen de forma redundante en más de una relación. Además tiene el

uperclase, tendremos que

Conversión de una relación Superclase/Subclase al modelo relacional. Opción B.

Crear una sola relación con todos los atributos de la superclase y las subclases pertenece. Esto corresponde a una

especialización de clases desunidas y puede generar muchos valores nulos. Esta opción no es apropiada cuando se utilizan muchos atributos de definición para la especialización. Si se

ión, esta opción es preferible a las opciones A y B, ya que, no requiere la utilización de JOIN para la conformación de la superclase completa. Ver

TipoPersona

Conversión de una relación Superclase/Subclase al modelo relacional. Opción C

Opción D: Crear una sola tabla con todos los atributos de la superclase más atributos de las subclases, mas unos atributos Ti cuyo valor lógico nos indicará a qué subclase pertenece la tupla. Esta opción corresponde una especialización con solapamiento. Ver figura

PERSONA DNI Nombre Dir Fecha_n

Figura 3.14 Conversión de una relación Superclase/Subclase al modelo relacional. Opción D

3.7 Normalización de Bases de Datos.

El proceso de Normalización de a las relaciones obtenidas tras el paso del diagrama Esirven para ayudar a los diseñadores de bases de datos a desarrollar un esquema que minimice los problemas de lógica.

La normalización es el proceso mediante el cual se t

conjunto de estructuras de datos más pequeñas, que además de ser más simples y más estables, son más fáciles de mantener. La normalización se adoptó porque el viejo estilo de poner todos los datos en un solo lugar, como un aera ineficiente y conducía a errores de lógica cuando se trataban de manipular los datos.

Las bases de datos relacionales se normalizan para:

• Evitar la redundancia• Evitar problemas de actualización de los datos en las relaciones. • Proteger la integridad

El proceso de normalización tiene un nombre y una serie de reglas para cada fase. Esto puede parecer un poco confuso al principio, pero poco a poco se va entendiendo el proceso, así como las razones para hacerlo de esta manera.

Crear una sola tabla con todos los atributos de la superclase más atributos de las subclases, mas unos atributos Ti cuyo valor lógico nos indicará a qué subclase pertenece la tupla. Esta opción corresponde una especialización con solapamiento. Ver figura

Fecha_n Sexo Empleado Sueldo Estudiante Especialidad

Conversión de una relación Superclase/Subclase al modelo relacional. Opción DFuente: El autor, 2009.

3.7 Normalización de Bases de Datos.

Normalización de Bases de Datos consiste en aplicar una serie de reglas a las relaciones obtenidas tras el paso del diagrama E-R al modelo relacionalsirven para ayudar a los diseñadores de bases de datos a desarrollar un esquema que minimice los problemas de lógica.

La normalización es el proceso mediante el cual se transforman datos complejos a un conjunto de estructuras de datos más pequeñas, que además de ser más simples y más estables, son más fáciles de mantener. La normalización se adoptó porque el viejo estilo de poner todos los datos en un solo lugar, como un archivo o una relación de la base de datos, era ineficiente y conducía a errores de lógica cuando se trataban de manipular los datos.

Las bases de datos relacionales se normalizan para:

redundancia de los datos. Evitar problemas de actualización de los datos en las relaciones.

integridad de los datos.

El proceso de normalización tiene un nombre y una serie de reglas para cada fase. Esto puede parecer un poco confuso al principio, pero poco a poco se va entendiendo el proceso, así como las razones para hacerlo de esta manera.

17

Crear una sola tabla con todos los atributos de la superclase más atributos de las subclases, mas unos atributos Ti cuyo valor lógico nos indicará a qué subclase pertenece la tupla. Esta opción corresponde una especialización con solapamiento. Ver figura siguiente:

Especialidad

Conversión de una relación Superclase/Subclase al modelo relacional. Opción D

consiste en aplicar una serie de reglas modelo relacional. Estas reglas

sirven para ayudar a los diseñadores de bases de datos a desarrollar un esquema que

ransforman datos complejos a un conjunto de estructuras de datos más pequeñas, que además de ser más simples y más estables, son más fáciles de mantener. La normalización se adoptó porque el viejo estilo de

rchivo o una relación de la base de datos, era ineficiente y conducía a errores de lógica cuando se trataban de manipular los datos.

Evitar problemas de actualización de los datos en las relaciones.

El proceso de normalización tiene un nombre y una serie de reglas para cada fase. Esto puede parecer un poco confuso al principio, pero poco a poco se va entendiendo el proceso,

18

3.7.1 Grados de normalización.

Existen básicamente tres niveles de normalización: Primera Forma Normal (1FN), Segunda Forma Normal (2FN) y Tercera Forma Normal (3FN). Cada una de estas formas tiene sus propias reglas. Cuando una base de datos se conforma a un nivel, se considera normalizada a esa forma de normalización. No siempre es una buena idea tener una base de datos conformada en el nivel más alto de normalización, puede llevar a un nivel de complejidad que pudiera ser evitado si estuviera en un nivel más bajo de normalización.

En la tabla siguiente se describe brevemente en que consiste cada una de las reglas, y

posteriormente se explican con más detalle.

Regla Descripción

Primera Forma Normal (1FN)

Incluye la eliminación de todos los grupos repetidos.

Segunda Forma Normal (2FN)

Asegura que todos los atributos (campos) que no son clave primaria sean completamente dependientes de la clave primaria (llave).

Tercera Forma Normal (3FN)

Elimina cualquier dependencia transitiva. Una dependencia transitiva es aquella en la cual los atributos que no son clave primaria (llave) son dependientes de otros atributos que tampoco son clave primaria.

Tabla Nº 3.8 Descripción de las formas normales 1FN, 2FN y 3 FN. Fuente: El autor, 2009.

3.7.2 Primera Forma Normal (1FN).

Una relación está en Primera Forma Normal sólo si cumple con las siguientes reglas: • Todos los atributos son atómicos. Un atributo es atómico si los elementos del dominio

son indivisibles, mínimos. • La relación contiene una clave primaria. • La relación no contiene atributos nulos. • Si no posee ciclos repetitivos.

A continuación se explicará algunos términos, citados anteriormente, a objeto de

entender cuando una relación (tabla) no se encuentra en su 1FN. 1. ¿Que son Ciclos o 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 1FN.

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 relación (tabla) cliente como sigue:

ID Cliente Nombre Apellido Teléfono

123 Raquel Pérez 0293-55586025

19

456 Jaime Rengel 0281-55540359

789 María Fernández 0414-55508633

Tabla Nº 3.9 Tabla CLIENTE. Fuente: El autor, 2009.

En este punto, el diseñador se da cuenta que un requisito es guardar múltiples números

telefónicos para algunos clientes, es decir el atributo o campo Teléfono es multivaluado. 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. Ver tabla siguiente.

ID Cliente Nombre Apellido Teléfono

123 Raquel Pérez 02935556025

456 Jaime Rengel 02815554059 02815557700

789 María Fernández 04145550833

Tabla Nº 3.10 Tabla CLIENTE no Normalizada. Fuente: El autor, 2009.

Asumiendo, sin embargo, que el campo "Teléfono" posee un dominio de valores de 11

caracteres numéricos de longitud y un formato de captura de datos igual a 99999999999, la representación de arriba no está en 1FN. La 1FN prohíbe a un campo contener más de un valor de su dominio, es decir, el campo Teléfono perdería su atomicidad.

Ejemplo 2: Grupos repetidos a través de columnas

El diseñador decide evitar esta restricción definiendo múltiples columnas (atributos) del número telefónico, resultando la siguiente tabla:

Tabla Nº 3.11 Tabla CLIENTE con atributos repetidos. Fuente: El autor, 2009.

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 1FN. Incluso si se contempla la posibilidad de columnas con valores nulos, el diseño no está en armonía con el espíritu de 1FN. 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 relación. 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?".

ID Cliente Nombre Apellido Teléfono 1 Teléfono 2 Teléfono 3

123 Raquel Pérez 02935556025

456 Jaime Rengel 02815554059 02815557700

789 María Fernández 04145550833

20

• La imposibilidad de hacer cumplir la unicidad los enlaces Cliente-a-Teléfono por medio del SMBD. 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.

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, como se muestra continuación:

Tabla Nº 3.12 Tabla CLIENTE con atributo Teléfono no atómico. Fuente: El autor, 2009.

Éste es defendiblemente el peor diseño de todos, y otra vez no mantiene el espíritu de la

1FN. 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 es imposibles definir significativas restricciones en números telefónicos. Además, igual se estaría limitando el número de teléfonos que podrían guardarse para un cliente. Un diseño conforme con 1FN.

Un diseño que está inequívocamente en 1FN hace uso de dos relaciones: una relación de cliente y una relación de teléfono del cliente, ver tablas respectivas.

Tabla Nº 3.13 Tablas CLIENTE Normalizada. Fuente: El autor, 2009.

En este diseño no ocurren grupos repetidos de números telefónicos. No se guardan valores nulos. Tampoco limita el número de teléfonos que se puede guardar de un mismo cliente. Y se mantiene el dominio de valores del campo teléfono a los 11 caracteres en el formato 99999999999.

ID Cliente Nombre Apellido Teléfono

123 Raquel Pérez 02935556025

456 Jaime Rengel 02815554059, 0281557700

789 María Fernández 04145550833

ID Cliente Nombre Apellido

123 Raquel Pérez

456 Jaime Rengel

789 María Fernández

ID Cliente Teléfono

21

Tabla Nº 3.14 Tablas TELEFONOCLIENTE Normalizada. Fuente: El autor, 2009.

2. ¿Qué es Atomicidad?

E.F. Codd, hace referencia al concepto de atomicidad e indica que "se requiere que los valores sean atómicos con respecto al SMBD en los dominios en los que cada relación es definida". Codd define un valor atómico como uno que "no puede ser descompuesto en pedazos más pequeños por el SMBD (excepto ciertas funciones especiales)".

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 1FN. 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 SMBD típicamente proporciona operadores para descomponerla en subcadenas.

• Una fecha parecería no ser atómica, ya que el SMBD proporciona típicamente operadores para descomponerla en los componentes día, mes, y año.

• Un número de punto decimal parecería no ser atómico, ya que el SMBD 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": 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 1FN 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 entonces aceptables en una relación 1FN - aunque quizás no siempre deseable. Date discute que los atributos relación-valor, por medio de los cuales un campo dentro de una relación puede contener una relación, son útiles en casos raros. 3.7.3 Segunda Forma Normal (2FN).

Una relación está en 2FN si está en 1FN y si los atributos que no forman parte de la

clave primaria dependen de ella en forma completa. Es decir que no existen dependencias parciales.

La regla de la 2FN establece que todas las dependencias parciales se deben eliminar y

separar dentro de sus propias tablas. Una dependencia parcial es un término que describe a

123 02935556025

456 02815554059

456 02815557700

789 04145550833

22

aquellos datos que no dependen de la clave primaria de la relación (tabla) para identificarlos. Una vez alcanzado el nivel de la 2 Forma Normal, se controlan la mayoría de los problemas de lógica. Podemos insertar un registro sin un exceso de datos en la mayoría de las tablas.

3.7.4 Tercera Forma Normal (3FN).

Una relación se encuentra en 3FN si está en 2FN y cada atributo que no forma parte de la clave primaria, depende directamente y no transitivamente, de la clave primaria.

Una relación está normalizada en esta forma si todas las columnas que no son clave son

funcionalmente dependientes por completo de la clave primaria y no hay dependencias transitivas. Una dependencia transitiva es aquella en la cual existen atributos que no son clave primaria y dependen de otros atributos que tampoco son clave primaria.

Cuando las relaciones están en la Tercera Forma Normal se previenen errores de lógica

cuando se insertan o borran registros. Cada atributo en una relación está identificado de manera única por la clave primaria, y no debe haber datos repetidos. Esto provee un esquema limpio y elegante, que es fácil de trabajar y expandir.

3.7.5 Ejemplo de un proceso de Normalización.

Para explicar con un ejemplo en que consiste el proceso de Normalización y cada una de las reglas que esto implica, vamos a considerar los datos de la relación ÓRDENES, que sigue a continuación.

ID_ORDEN FECHA ID_CLIENTE NOM_CLIENTE ESTADO NUM_ITEM DESC_ ITEM CANT PRECIO

2301 23/02/08 101 MARTI SUCRE 3786 RED 3 35

2301 23/02/08 101 MARTI SUCRE 4011 RAQUETA 6 65

2301 23/02/08 101 MARTI SUCRE 9132 PAQ-3 8 4.75

2302 25/02/08 107 HERMAN LARA 5794 PAQ-6 4 5.0

2303 27/02/08 110 MARIA APURE 4011 RAQUETA 2 65

2303 27/02/08 110 MARIA APURE 3141 FUNDA 2 10

Tabla Nº 3.15 Tablas ORDENES no Normalizada. Fuente: El autor, 2009.

a.) Paso de una relación a su 1FN.

Primeramente debemos examinar las tuplas de la relación base, en nuestro caso la relación ÓRDENES, a objeto de identificar si cumple con cada una de las reglas de la 1FN, presentadas anteriormente en el punto 3.7.2.

Al examinar estas tuplas, se puede observar que existen valores repetidos en las

columnas ID_ORDEN, FECHA, ID_CLIENTE, NOM_CLIENTE y ESTADO para valores diferentes de las columnas NUM_ITEM, DESC_ITEM, CANT y PRECIO. La 1FN prohíbe los grupos repetidos, por lo tanto tenemos que llevar la relación ÓRDENES a la 1FN. Los pasos a seguir son:

23

1. Tenemos que eliminar de la relación ORDENES las columnas que están causando la los grupos repetidos de valores, es decir, las columnas NUM_ITEM, DESC_ITEM, CANT y PRECIO.

2. Tenemos que crear una nueva relación; la misma ha de tener la Clave Primaria (FK)

de la relación base, es decir, la columna ID_ORDEN, y el grupo de columnas que eliminamos en el paso anterior.

3. Posteriormente, definimos una Clave Primaria para la nueva relación. Esta será una

clave compuesta por la Clave Primaria de la relación base y una de las columna restantes. Se debe considerar cual de ellas es la más adecuada.

Los registros quedan ahora conformados en dos relaciones; la relación Base ÓRDENES

y la nueva relación ARTÍCULOS_ORDENES .

ID_ORDEN FECHA ID_CLIENTE NOM_CLIENTE ESTADO

2301 2/23/03 101 MARTI SUCRE

2302 2/25/03 107 HERMAN LARA

2303 2/27/03 110 MARIA APURE

Tabla Nº 3.16 Tablas OREDENES en 1FN. Fuente: El autor, 2009.

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

Tabla Nº 3.17 Tablas ARTICULOS_ORDENES en 1FN. Fuente: El autor, 2009.

Si observamos nuevamente la relación ÓRDENES, podemos ver que:

• No existen grupos repetitivos, • La relación posee una clave primaria, • No contiene valores nulos, • Todos sus valores son atómicos

Se puede decir, entonces, que la relación ÓRDENES se encuentra en la 1FN, ya que

cumple con todas las reglas enumeradas en el punto 3.7.2.

Evaluamos si la nueva relación ARTÍCULOS_ORDENES está en su 1FN. De no estar se repite el proceso anterior para esta nueva relación. De lo contrario seguimos con la 2FN. La relación ARTÍCULOS_ORDENES si está en su 1FN.

24

b.) Paso a la 2FN.

Una vez comprobada que las relaciones resultantes se encuentran en su 1FN, procederemos a aplicar la 2FN, es decir, tenemos que eliminar cualquier columna no clave primaria que no dependa de la clave primaria de la relación. Los pasos a seguir son:

• Determinar cuáles atributos que no son clave primaria no dependen de la clave primaria de la relación.

• Eliminar esos atributos de la relación base.

• Crear una segunda relación con esos atributos y lo(s) atributos(s) de la clave primaria de la cual dependen.

La relación ÓRDENES está en 2FN. Cualquier valor único de ID_ORDEN determina un

sólo valor para cada columna. Por lo tanto, todas las columnas poseen dependencia funcional completa con la llave primaria ID_ORDEN.

Por su parte, la relación ARTÍCULOS_ORDENES no se encuentra en 2FN; ya que las

columnas PRECIO y DESC_ITEM son dependientes de la columna NUM_ITEM, pero no son dependientes de ID_ORDEN, es decir, no existe dependencia funcional completa con el campo clave, en este caso, ID_ODEN y NUM_ITEM; por lo tanto tenemos que llevar la relación ARTÍCULOS_ORDENES a su 2FN. Los pasos a seguir son:

1. Eliminar estas columnas (PRECIO y DESC_ITEM) de la relación

ARTÍCULOS_ORDENES.

2. Crear una nueva relación, es este caso la relación ARTÍCULOS, con dichas columnas y la columna de la clave primaria de la que dependen.

3. Esa columna representará para la nueva relación la clave primaria.

Las relaciones quedan ahora de la siguiente manera.

ID_ORDEN NUM_ITEM CANT

2300 3786 3

2301 4011 6

2301 9132 8

2302 5794 4

2303 4011 2

2303 3141 2

Tabla Nº 3.18 Tablas ARTICULOS_ORDENES y ARTICULOS Normalizadas. Fuente: El autor, 2009.

c.) Paso a la 3FN.

NUM_ITEM DESC_ITEM PRECIO

3786 RED 35

4011 RAQUETA 65

9132 PAQ-3 4.75

5794 PAQ-6 5.0

4011 RAQUETA 65

3141 FUNDA 10

25

La tercera forma normal nos dice que tenemos que eliminar cualquier columna no llave

que sea dependiente de otra columna no llave. Los pasos a seguir son: • Determinar las columnas que son dependientes de otra columna no llave. • Eliminar esas columnas de la relación base. • Crear una segunda relación con esas columnas y con la columna no llave de la cual

son dependientes.

Al observar las relaciones que se han creado, nos damos cuenta que tanto la relación Artículos , como la relación Artículos _ órdenes se encuentran en 3FN. Sin embargo la relación Órdenes no lo está, ya que NOM_CLIENTE y ESTADO son dependientes de ID_CLIENTE, y esta columna no es la llave primaria.

Para normalizar esta relación, realizaremos los siguientes pasos: 1. Eliminaremos de la relación Órdenes, las columnas no llave (NOM_CLIENTE y

ESTADO) que tienen dependencia transitiva. 2. Creamos una nueva relación con estas columnas, y adicionamos la columna no llave

ID_CLIENTE que causó la dependencia transitiva.

3. La nueva relación Clientes tendrá como clave primaria la columna que produjo la dependencia transitiva, es decir, ID_CLIENTE.

ID_ORDEN FECHA ID_CLIENTE

2301 2/23/03 101

2302 2/25/03 107

2303 2/27/03 110

Tabla Nº 3.19 Tablas ORDENES en 3FN. Fuente: El autor, 2009.

ID_CLIENTE NOM_CLIENTE ESTADO

101 MARTI CA

107 HERMAN WI

110 MARIA MI

Tabla Nº 3.20 Tabla CLIENTES en 3FN. Fuente: El autor, 2009.

3.7.6 ¿Qué tan lejos debe llevar la normalización?

La siguiente decisión es ¿qué tan lejos debe llevar la normalización? La normalización es una ciencia 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 para crear relaciones que sean fáciles de

26

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 relaciones sólo para seguir las reglas o estas divisiones son en

verdad prácticas?. Éstas son el tipo de cosas que nosotros 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.

Existen seis niveles más de normalización que no se han discutido aquí. 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. Éstas existen para hacer una base de datos realmente relacional. Tienen que ver principalmente con dependencias múltiples y claves relacionales. 3.7.7 Forma normal de Boyce-Codd

La Forma Normal de Boyce-Codd (FNBC) es una versión ligeramente más fuerte de la Tercera Forma Normal (3FN). 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. En una relación en 3FN, todos los atributos dependen de una clave, de la clave completa y de ninguna otra cosa excepto de la clave. Se dice que una relación está en FNBC si y solo si está en 3FN y cada dependencia funcional no trivial tiene una clave candidata como determinante. En términos menos formales, una relación está en FNBC si está en 3FN y los únicos determinantes son claves candidatas.

Solamente en casos raros una relación en 3FN no satisface los requerimientos de la

BCNF. Un ejemplo de tal relación es (teniendo en cuenta que cada estudiante puede tener más de un tutor), como el que se muestra en la tabla siguiente:

ID Tutor Número de seguro social del tutor ID Estudiante

1078 088-51-0074 31850

1078 088-51-0074 37921

1293 096-77-4146 46224

1480 072-21-2223 31850

Tabla Nº 3.21 Referencia cruzada de Tutor/Estudiante. Fuente: El autor, 2009.

El propósito de la relación es mostrar qué tutores están asignados a qué estudiantes. Las

claves candidatas de la relación son: • {ID Tutor, ID Estudiante} • {Número de seguro social del tutor, ID Estudiante}

Por lo tanto los tres atributos de la relación son atributos primarios, es decir, los tres

atributos pertenecen a las claves candidatas. Recuerde que la 2FN prohíbe dependencias funcionales parciales de atributos no-primarios en las claves candidatas, y la 3FN prohíbe

27

Código

Aportes Financieros

Proyecto Urbanístico

Comunidad Fuentes Financieras

Partida Monto

Elaborado

A-P

Número

RIF

Dueño

Ärea

Dirección

IDProyecto

NroCheque

Fecha

Vivienda

Estado Ubicación

Habitantes

Numero

Costo Descripción

Nombre Teléfonos

Dirección

Calle

Edificio

Avenida

A

dependencias funcionales transitivas de atributos no-primarios en claves candidatas. Dado que la relación de arriba carece de cualquier atributo no-primario, está en 2FN y 3FN.

La FNBC es más rigurosa que la 3FN 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 dependencia de ID Tutor en Número de seguro social del tutor es ese tipo de dependencia. Por consiguiente, la relación de arriba no está en FNBC.

Cualquier relación que sea insuficiente en FNBC será vulnerable a inconsistencias lógicas. En la relación de arriba podía ser representada una combinación inconsistente de ID Tutor y Número de seguro social del tutor.

En este caso, corregir el problema sería una simple cuestión de usar solo un esquema de

identificación para los tutores: o el ID, o el número del seguro social, pero no ambos. 3.8 Ejercicios Propuestos.

1. Que condiciones deberá cumplir una clave candidata, dentro de una entidad, para poder ser la clave principal o llave primaria de la relación correspondiente.

2. Objetivos del Diseño de Bases de Datos.

3. ¿Existen relaciones ternarias en el modelo lógico relacional?

4. Obtenga los modelos lógicos a partir de los modelos conceptuales que se presentan a continuación, respectivamente:

28

Carteleras

Cines

Publica

Nombre

FechaInicio

Función Películas

Actores

C-P

Clase

Dirección

Papel Código

Género

IdCartelera

FechaFinal

Responsable Titulo

H. Salida H. Inicio

Nombre

Rif

Salas

C

Departamento Proyecto

Docentes

D-P

D-P

D-P Cedula

Cargo

Costo

Nombre

Teléfono

IdDepartamento

FechaInicio

Apellido Titulo

Nombre

Código

Descripción

B

E

D

5. En que consiste la normalización.

6. Mencione al menos 3 ventajas de una base de datos normalizada.

7. ¿Cuando una relación está en su 1FN?

F

En que consiste la normalización.

Mencione al menos 3 ventajas de una base de datos normalizada.

¿Cuando una relación está en su 1FN?

29

30

8. ¿Que es la dependencia funcional completa?

9. En que consiste la normalización

10. ¿Cuando una relación está en su 2FN?

11. Mencione al menos 2 ventajas de una base de datos normalizada hasta su 3FN.

12. ¿Cuando una relación está en su 3FN?

13. ¿Que es dependencia transitiva?

14. ¿Qué es eliminado en la relación cuando se pasa de su 2FN a su 3FN?

15. ¿Qué es eliminado en la relación cuando se pasa de su 1FN a su 1FN?

31

16. Normalizar las siguientes relaciones a su 1FN, 2FN y 3FN. Colocar nombres a las relaciones resultantes y señalar el o los campos claves.

# Proyecto

Descripción Proyecto

Fecha Inicio

# Servicio

Descripción Cedula Nombre Analista

Meta a Alcanzar

Horas Asignadas

Línea Investig.

Descrip. Investig.

# Dpto.

Nombre Departamento

Costo Total Asignado

01 Pagina WEB 12-03-04 L-A Diseño 258 José Diseño

Navegacional 8 L1 Software 01 Telemática 1.002.581 3.000.000

01 Pagina WEB 12-03-04 L-A Diseño 115 Omar Diagrama de Clases

4 L1 Software 01 Telemática 1.002.581 3.000.000

01 Pagina WEB 12-03-04 L-P Programación 357 María Códigos Fuentes 6 L1 Software 01 Telemática 1.758.685 3.000.000

02 BDD Control Egresados 22-05-02 L-A Diseño 578 José Modelo Físico 5 L1 Software 02 Informática 1.000.000 2.000.0000

02 BDD Control Egresados 22-05-02 L-D

Administrador BDD 258 José

Construcción BDD 11 L1 Software 02 Informática 1200.000 2.000.000

03 Voz Sobre IP 18-11-03 L-T Telefonía 115 Omar Mascara de RED 7 L2 Redes 05 Electrónica 800.000 1.500.000

03 Voz Sobre IP 18-11-03 L-C Diseño Cableado 987 María Tendido de

Cable 15 L2 Redes 05 Electrónica 900.000 1.500.000

03 Voz Sobre IP 18-11-03 L-A Diseño 258 José Protocolo de Red 22 L2 Redes 05 Electrónica 900.000 1.500.000

04 Diseño

Multimedia 22-06-04 L-A Diseño 525 Pablo

Diagrama de Clase

116 L3 Multimedia 02 Informática 1.500.000 1.500.000

Etc..

Nº

Equipo País

Equipo Manager Nº

Partido Fecha Partido

Lugar Partido

Total Goles

Partido

Cedula Jugador

Nombre Jugador

Posición Jugador Partido

Goles Anotados Jugador

Resultado Partido

Total Partidos Equipo

89 Brasil Juan 101 12-06-92 Caracas 5 11 Nelson Central 0 Ganador 3

89 Brasil Juan 101 12-06-92 Caracas 5 22 Joel Arquero 0 Ganador 3 89 Brasil Juan 101 12-06-92 Caracas 5 33 Pablo Defensa 1 Ganador 3 89 Brasil Juan 102 14-07-93 Cumaná 7 11 Nelson Lateral 2 Perdedor 3

89 Brasil Juan 102 14-07-93 Cumaná 7 22 Joel Defensa 3 Perdedor 3

89 Brasil Juan 102 14-07-93 Cumaná 7 33 Pablo Arquero 0 Perdedor 3 90 Vzla Luis 101 12-06-92 Caracas 5 87 Marcos Lateral 2 Perdedor 5

90 Vzla Luis 101 12-06-92 Caracas 5 88 Paz Arquero 0 Perdedor 5 90 Vzla Luis 101 12-06-92 Caracas 5 89 Veliz Central 0 Perdedor 5

91 Perú Pedro 102 14-07-93 Cumaná 7 91 Páez Lateral 2 Ganador 4 91 Perú Pedro 102 14-07-93 Cumaná 7 92 Richard Arquero 0 Ganador 4

91 Perú Pedro 102 14-07-93 Cumaná 7 93 John Defensa 1 Ganador 4

92 Chile Carlos 103 21-06-94 Guiria 3 67 Veltri Defensa 0 Perdedor 2 92 Chile Carlos 103 21-06-94 Guiria 3 68 Can Arquero 1 Perdedor 2

92 Chile Carlos 103 21-06-94 Guiria 3 69 Jeli Lateral 2 Perdedor 2 Cedula Nombre Teléfono Código Cargo Cargo Código Curso Nombre Curso Nivel Resultado

32

17 Juana 4512656 01 Analista-Diseñador 1-AA Power Designer Avanzado Aprobado 17 Juana 4512656 01 Analista-Diseñador 1-BB PowerBuilder Básico Reprobado 17 Juana 4512656 01 Analista-Diseñador 1-JJ Java Medio Aprobado 17 Juana 4512656 01 Analista-Diseñador 1-CC SQL Server Medio Reprobado 18 Pedro 4312586 01 Analista-Diseñador 1-AA Power Designer Avanzado Rechazado 19 Pablo 4161582 02 Especialista en Redes 1-CC SQL Server Medio Aprobado 19 Pablo 4161582 02 Especialista en Redes 1-DD UNIX Avanzado Rechazado 20 María 485748 02 Especialista en Redes 1-FF Power Designer Medio Aprobado

Etc.

Número

Vendedor Nombre de Vendedor

Área de Venta

Número de cliente

Nombre del Cliente

Número de Bodega

Ubicación de Bodega

Importe de venta

3462 Pedro Cumana 15-2 Juana 4 Peñón 12586 3462 Pedro Cumana 14-9 Maria 3 San Luis 12248 3462 Pedro Cumana 16-8 José 3 San Luis 22568 3593 Juan Carúpano 21-4 Luis 2 Monte Verde 58932 3593 Juan Carúpano 16-5 Martha 2 Monte Verde 12562 3593 Juan Carúpano 11-2 Andres 1 EL Silencio 42155 Etc.

#Proyecto Nombre #Area Nombre

Area Cedula

investigador Nombre Depto. Costo Total Proyecto Fuente

Financiera Tiempo

01 Tejido Óseo 01 Medicina 11826857 Juan Biología 1000 3000 Ivic 1 Año 01 Tejido Óseo 01 Medicina 15752863 Pedro Alimentos 1000 3000 Ivic 1 Año 01 Tejido Óseo 02 Salud 11824757 Ana Biología 2000 3000 Ivic 1 Año 01 Tejido Óseo 02 Salud 534534 Luis Biología 2000 3000 Ivic 1 Año 02 El Espacio 03 Matemáticas 534534 Luis Biología 5000 8000 Cenamec 6 Meses 02 El Espacio 03 Matemáticas 15752863 Pedro Alimentos 5000 8000 Cenamec 6 Meses 02 El Espacio 01 Medicina 8564145 Maria Física 3000 8000 Cenamec 6 Meses

Etc..

33