UNIDAD II Modelo Relacional de Base de datos.

2.1. Modelo relacional de base de datos.

Una vez que las bases de datos fueron implementadas y utilizadas con exito surgieron diferentes formas de organizar y representarlas, surgieron diferentes modelos, modelo Jerárquico, modelo de redes, estos modelos dieron pauta a la creación del modelo de base de datos relacional, el cual hasta la fecha es reconocido como uno de los modelos más eficientes y que ofrece ventajas. A continuación se describen brevemente sus antecedentes.

El concepto base de datos relacional fue utilizado por primera vez por el Dr. Codd en 1970, el cual publicó un artículo en el que aplicaba los conceptos de una rama de las matemáticas llamada algebra relacional, a los problemas de almacenar enormes cantidades de datos. Este artículo dio inicio a un movimiento en la comunidad de las bases de datos que en muy poco tiempo condujó a la definición del modelo de bases de datos relacionales.

El modelo relacional surge como un intento de simplificar la estructura de las bases de datos, eliminando estructuras padre/hijo del modelo jerárquico y en su lugar representaba todos los datos como tablas conformadas a su vez por renglones y columnas con valores de datos.

Ejemplo.

Esta tabla almacena información de libros, cada columna representará datos del libro, como el título, autor, editorial, etc. En cada renglón se almacena la información referente a un libro.

Entidad Libro

Título Autor EditorialDemian Hermann Hesse SayrolsCobol Javier Ceballos Macrobit

Tabla 3. Ejemplo de Entidad o tabla. El modelo de base de datos relacional es un modelo simple, poderoso y

formal de representar la realidad. Este modelo facilita la construcción de consultas del usuario, dando como resultado una alta productividad de los programadores de la base de datos.

A continuacion se muestran conceptos utilizados en el diseño de base de datos relacional.

2.2. Conceptos fundamentales del modelo relacional.

Tabla, Entidad o Afinidad: Una entidad puede ser llamada también como afinidad o tabla, es un objeto que existe y es distinguible de otros objetos, identifica unicamente un objeto o sujeto específico del universo, representada por un conjunto de atributos, renglones y columnas, ejemplo:Tabla libro, tabla alumno, tabla empleado, etc.Esquema: la organización conceptual de toda la base de datos vista por su administrador, es la colección de tablas, de datos que conforman a las tablas y relaciones que se generan. Atributos: descriptores de la entidad de la cual se almacena información, Las columnas corresponden a los atributos (título, editorial, autor).Dominio del atributo:El conjunto de todos los valores posibles para un atributo en particular.Relación: Tabla que se genera a partir de la relación o asociación de dos o más tablas o entidades existentes.Grado de la relación: Es el número de columnas en una tabla.Cardinalidad de la relación Expresa el número específico de ocurrencias de una entidad asociadas con una ocurrencia de la entidad relacionada.Llave o clave. Es el identificador único de cada tupla. Clave primaria. Clave que el diseñador elige de la base de datos como el medio principal de identificar un registro o tupla dentro de una tabla.Clave compuesta: Una clave conformada por más de un atributo.Clave candidata: Cualquier conjunto de atributos que puede ser elegido como una clave de una relación.Clave externa: Clave primaria de una tabla externa; usada para indicar enlaces logicos entre relaciones.Tupla: Conjunto de atributos que representan a una unidad.Valor nulo. El valor dado a un atributo en una tupla, si el atributo es inaplicable o su valor es desconocido.

En general, una tabla de relación puede tener más de una llave. Cada llave es denominada llave candidata. Aunque también es posible que un conjunto de entidades no tenga atributos suficientes para formar una clave primaria. Un conjunto de entidades de este tipo se denomina conjunto de entidades débil.

Un conjunto de entidades que tiene una clave primaria se le denomina entidad fuerte.

Ejemplo de una entidad o tabla es la siguiente:

Tabla EmpleadoNoemp Nombre Puesto Profesión1234 Damian Juarez Contralor C.P.5234 Javier Carballo Jefe Centro Cómputo L.I.

Tabla 4. Ejemplo de tabla

Entidad: Empleado

Atributos. Noemp, Nombre, Puesto, Profesión.Dominios atributo Noemp: 1234, 5234Dominios atributo Nombre: Damian Juarez, Javier CeballoslDominios atributo Puesto: Contralor, Jefe Centro Cómputo.Dominios atributo Profesión: C.P., L.I.

2.3. Transformación de un modelo conceptual en un modelo relacional.

Se ha revisado la representación de un modelo conceptual, ahora se revisaran los detalles que se deben considerar para realizar la conversión entre un modelo conceptual y un modelo relacional. Un modelo de datos conceptual consta de objetos, interrelaciones, atributos, especializaciones, agregados, etc. Cada uno de ellos podrá ser transformado generando la creación de relaciones normalizadas.

Transformar conjuntos de objetos y atributos.

Fig. 14 Descripción Objeto Persona

Este es un objeto con dos atributos. Persona es un objeto y los atributos son no_ss y fecha_nac

Este diagrama se transforma en una relación con atributos, de la sig. manera.

PERSONA (NO_SS, FECHA-NAC). Se considera que el NO_SS puede servir como campo clave, ya que identifica unicamente a la persona.El campo subrayado representa al campo llave.

Transformar modelos sin claves externas.

Suponga el sig. modelo conceptual.

Fig. 15 Transformación modeloEn este caso es posible transformar este diseño al modelo relacional de la sig. forma.

PERSONA

FECHA-NACNO_SS

VENTA

IMPORTE NO_PTO

VENTA(Importe, no_pto), solo que no encontramos un campo que pueda servir de clave, por lo que es necesario añadir un atributo que nos represente a la clave para esta relación. Ejemplo: VENTA(No_venta, Importe, no_pto)

Transformar la especialización y la generalización de conjuntos de objetos.

Fig. 16 Transfomación conjunto de objetos.

Este diseño se puede representar en el modelo relacional de la sig. manera.Persona casada es una especialización de persona, por lo que hereda todos los datos de persona, además de sus propios atributos, de tal forma que el modelo relacional se representaría de la sig. forma.

PERSONA_CASADA (No_ss, nombre, dirección, conyúge)Clave externa: No_ss referencia a personaPara eliminar la redundancia, se eliminan los datos repetidos en la tabla de especialización quedando de la sig. forma:

PERSONA_CASADA (No_ss, conyuge)Clave externa: No_ss referencia a persona

Transformar interrelaciones.Las interrelaciones se transforman en tres formas diferentes, dependiendo

de la cardinalidad de las interrelaciones (uno-uno, uno-muchos, muchos-muchos). Cliente 1,1 1,* 1,1 Fig. 17 Transformación interrelaciones

Uno a uno.Considere:Un cliente sólo tenga una cuenta y una cuenta sólo pertenezca a un cliente.

PERSONA

PERSONA CASADA

No-ss Nombre Direccion

Conyuge

Cliente CuentaTiene Cuenta

La transformación de este modelo conceptual al modelo relacional puede quedar de la sig. manera.

Cuenta(No-cta, No-cte)Clave externa hace referencia a número de cliente.

Cliente (No-cte,No-cta)Clave externa hace referencia a número de cuenta.

Uno a muchos.Considere:Un cliente tenga muchas cuentas y una cuenta sólo pertenezca a un cliente.

Un cliente puede tener muchas cuentas

Cuenta(No-cta, No-cte, saldo, fecha_apertura)Cliente (No-cte, nombre, dirección)Clave externa hace referencia a número de cliente.

Relaciones muchos a muchos.Considere:Un cliente puede tener muchas cuentas y una cuenta puede estar asignado a varios clientes.

Cuenta(No-cta, fecha_apertura)Cliente (No-cte, nombre, dirección)Tiene_cuenta(No-cte, No-cta, saldo)Clave foránea No-cte hace referencia a número de cliente.Clave foránea No-cta hace referencia a número de cuenta.

2.4. Restricciones de Integridad.En la realización del diseño de una base de datos es muy importante

considerar a las restricciones necesarias para lograr un buen diseño de la misma.

Entendiendo por restricción, a las reglas que limitan los valores que pueden estar en una base de datos.

Las restricciones más importantes son las siguientes:

Integridad de la entidad. El atributo que es clave de una fila no puede ser nulo.

Ejemplo

No_matricula Nombre CarreraJuan López Ing. Sistemas

El No_matricula, siendo el campo llave, no puede ser nulo.

Fig. 18 Integridad de la Entidad.

Integridad referencial. El valor no nulo de una clave externa debe ser un valor real de la clave de otra relación.

Tabla FacturaFolio Fecha No_cte

1 10/12/2007 1002 10/12/2007 150

Tabla ClientesNo_cte Nombre Dirección100 Camila Ortega Otay120 Jorge Rábago La Mesa

Fig. 19. Integridad Referencial.

La integridad referencial no permitirá generar una factura a un cliente que aún no está dado de alta en el catálogo.

Dependencia funcional. El valor de un atributo en una tupla determina el valor de otro atributo en la tupla.

No_asig. Nombre_asig Créditos1 Base de Datos 82 Lenguajes Algoritmicos 73 Desarrollo Humano 5

Fig. 20 Dependencia funcional.

La Dependencia funcional, permitirá conocer cualquier dato de la tupla, conociendo el valor del campo llave.

El modelo de datos relaciónal de Codd incluye varias restricciones que se usan para verificar la validación de los datos.

Los valores en las celdas de la tabla, deben ser de valor único; no se permite repetir grupos, ni tener arreglos como valores.

Todos los ingresos en cualquier columna (atributo) deben ser del mismo tipo. Cada columna posee un nombre único y no es importante el orden de las

columnas en la tabla. En la tabla no pueden ser idénticas dos hileras (tuplas) y no es importante el

orden de los renglones.

La simplicidad del modelo relacional se da desde que todas las relaciones son definidas independientemente. La relación en el modelo E-R puede ser representada por la unión entre atributos de diferentes tablas.

Para entender el modelo relacional y la normalización es necesario conocer los conceptos de dependencia funcional y de clave, de la cual ya hemos hablado previamente.

Una dependencia funcional es una relación entre uno o más atributos, esto es un dato será dependiente de otro y podremos encontrar información a partir de un dato original.

Cuando en una tabla o base de datos no se tiene un diseño correcto de los datos, se puede incurrir en las siguientes anomalías: Anomalias de actualización. Inconsistencia de los datos como resultados de datos redundantes y actualizaciones parciales.

Anomalias de borrado. Pérdida no intencionada, de datos debido a que se han borrado otros datos.

Anomalias de Inserción. Imposibilidad de adicionar datos en la base de datos debido a la ausencia de otros datos.Ejemplo:

Tabla Trabajador.Id-trab Nombre Oficio Id-sup Id-edificio

1235 Manuel Alvarez Electricista 1511 3001235 Manuel Alvarez Electricista 1511 4001412 Martin Pérez Obrero 5001412 Martin Pérez Plomero 6001412 Martin Pérez Plomero 4501412 Martin Pérez Plomero 4001511 Carlos Díaz Plomero 450

Tabla 5. Entidad trabajador

Esta es una tabla mal diseñada, que muestra redundancia, en datos como el nombre y el oficio.

Esta redundancia no sólo ocupa espacio, sino que puede llevar a perder la integridad de los datos (pérdida de la consistencia).Suponiendo que un trabajador atiende a más de un edificio al mismo tiempo y que además el oficio en una tupla es incorrecto y las demás son correctas. Esto genera inconsistencia entre las tuplas que contienen información del trabajador. Este es un ejemplo de anomalías de actualización.

Suponga que un empleado ha dejado de trabajar por un tiempo y el edificio que tenia asignado fue concluido. Si se desea eliminar las tuplas de los edificios terminados es posible que la tupla de un trabajador sea borrada y no se tengan los datos del empleado.Esto se denomina anomalías de borrado.

A modo inverso, puede tenerse contratado un nuevo empleado llamado Jorge Mejía, si aún no se le asigna un edificio. A esto se le llama anomalías de actualización.

Para eliminar este tipo de errores es necesario aplicar la técnica de normalización que nos permita tener un diseño correcto.

2.5. Normalización. Se han realizado muchos trabajos teóricos acerca de lo que es una relación bien estructurada. Este trabajo se ha denominado Normalización, Codd, definió varias formas normales de afinidades.

La técnica de normalización es semejante a lo que comunmente se dice de que un párrafo en una lectura, debe tener un sólo tema, si un párrafo tiene más de un tema, debe dividirlo en tantos párrafos como temas se consideren. La lógica que se aplica a la normalización es cada afinidad normalizada tiene un sólo tema, Si tiene dos o más, deberá fragmentarse en afinidades o tablas, cada una de las cuales tendrá un sólo tema.

Estas clases de afinidades y las técnicas para prevenir las anomalías son llamadas formas normales. Dependiendo de su estructura, una afinidad puede estar en primera forma normal, segunda forma normal o alguna otra. En su artículo Ted Codd, estableció la primera, segunda y tercera forma normal. Cada una de estas formas están anidadas, esto es una afinidad que está en tercera forma, debe estar en primera y segunda forma normal.

2.5.1.Primera forma normal

Una afinidad está en primera forma normal, si la tupla tiene un campo definido como campo clave y todos sus valores son atómicos o únicos para cada atributo en la relación. Esto es que los valores de los atributos no pueden ser un conjunto de valores o un grupo repetitivo.

Cualquier tabla de datos que cumpla con la definición de una afinidad, se dice que está en la primera forma normal.

Si en una tabla nos encontramos grupos repetitivos es necesario crear una tabla de relación que interrelacione a las tablas determinadas.

Ejemplo:

Tabla Trabajador.Id-trab Nombre Oficio Id-sup Id-edificio

1235 Manuel Alvarez Electricista 1511 300,450,5001412 Martin Pérez Plomero 400.450,500,6001511 Carlos Díaz Plomero 450,500

Fig. 21 Tabla Trabajador.

En esta tabla se observa que cada empleado puede atender a diferentes edificios, este es el caso de un atributo como grupo repetitivo, por lo que es necesario corregir esta tabla creando una nueva tabla de relación.

TrabajadorId-trab Nombre Oficio Id-sup

1235 Manuel Alvarez Electricista 15111412 Martin Pérez Plomero1511 Carlos Díaz Plomero

Asignación por trabajadorId-trab Id-edificio

1235 3001235 4501235 5001412 4001412 4501412 5001412 6001511 4501511 500

Fig. 22 Tabla Asignación por Trabajador.

2.5.2. Segunda forma normal.

La segunda y tercera forma normal se ocupan de la relación entre los atributos claves y no claves. Una relación está en segunda forma normal (2FN) si todos sus atributos que no son claves dependen por completo de la clave, esto es cada afinidad que tiene un atributo único como clave, está en segunda forma

normal. La clave es sólo un atributo, en forma predeterminada, cada atributo que no es clave no es funcionalmente dependiente de una parte de la clave; no puede haber dependencias parciales. Por tanto, la 2FN puede violarse sólo cuando una clave sea compuesta o, en otras palabras, que conste de más de un atributo.

Ejemplo: Trabajador

Id-trab Nombre Id-edificio Fecha inicio1235 Manuel Alvarez 300 01/01/011412 Martin Pérez 400 01/04/011235 Manuel Alvarez 450 10/03/011412 Martin Pérez 500 02/10/011412 Martin Pérez 600 03/12/01

Tabla 6. Entidad Trabajador

En esta tabla tenemos los datos del trabajador (id-trab y nombre) cada vez que aparece una tupla de edificio asignado, existe redundancia en el nombre y podria accesar datos por id-trabajador y por nombre, esto es una violación a la 2FN.

2.5.3.Tercera forma normal.

Una afinidad está en tercera forma normal si está en segunda forma normal y no tiene dependencias transitivas. Una dependencia transitiva es un arreglo de dependencias funcionales. Es posible decir que una relación está en 3FN si para toda dependencia funcional DF: X Y, X es una clave.

TrabajadorId-trab Oficio Sueldo

1235 Electricista 3.501412 Plomero 3.001511 Plomero 3.75