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 matemáticas llamada algebra relacional, relacional , a los problemas problemas de almacenar enormes cantidades de datos. Este artículo dio inicio a un movimiento en la comunidad comunidad de las bases de datos que en muy 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 Demian Cobol
Autor Hermann Hesse Javier Ceballos
Editorial Sayrols 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 Empleado Noemp Nombre 1234 Damian Juarez 5234 Javier Carballo Tabla 4. Ejemplo de tabla
Entidad: Empleado
Puesto Contralor Jefe Centro Cómputo
Profesión C.P. L.I.
Atributos. Noemp, Nombre, Puesto, Profesión. Dominios atributo Noemp: 1234, 5234 Dominios atributo Nombre: Damian Juarez, Javier Ceballosl Dominios 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 con juntos de ob jetos y atributos. NO_SS
FECHA-NAC PERSONA
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.
IMPORTE
NO_PTO
VENTA
Fig. 15 Transformación modelo
En este caso es posible transformar este diseño al modelo relacional de la sig. forma.
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 con juntos de ob jetos.
No-ss
Nombre
Direccion
PERSONA
Conyuge PERSONA CASADA
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 persona Para 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 Cliente
1,1
Tiene Cuenta
1,*
1,1
Cuenta
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.
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 Juan López
Carrera 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 Factura F olio 1 2
F echa
10/12/2007 10/12/2007
Tabla Clientes No_cte 100 Camila Ortega 120 Jorge Rábago
Nombre
No_cte
100 150
Dirección
Otay 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. 1 2 3
Nombre_asig Base de Datos Lenguajes Algoritmicos Desarrollo Humano
Créditos 8 7 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.
y
y y
y
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 1235 Manuel Alvarez 1235 Manuel Alvarez 1412 Martin Pérez 1412 Martin Pérez 1412 Martin Pérez 1412 Martin Pérez 1511 Carlos Díaz
Oficio Electricista Electricista Obrero Plomero Plomero Plomero Plomero
Id-sup 1511 1511
Id-edificio 300 400 500 600 450 400 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 1235 1412 1511
Manuel Alvarez Martin Pérez Carlos Díaz
Oficio Electricista Plomero Plomero
Id-sup 1511
Id-edificio 300,450,500 400.450,500,600 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. Traba jador Id-trab 1235 1412 1511
Nombre Manuel Alvarez Martin Pérez Carlos Díaz
Oficio Electricista Plomero Plomero
Id-sup 1511
Asignación por traba jador Id-trab Id-edificio 1235 1235 1235 1412 1412 1412 1412 1511 1511
300 450 500 400 450 500 600 450 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 1235 1412 1235 1412 1412
Nombre Manuel Alvarez Martin Pérez Manuel Alvarez Martin Pérez Martin Pérez
Id-edificio 300 400 450 500 600
Fecha inicio 01/01/01 01/04/01 10/03/01 02/10/01 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. Traba jador Id-trab 1235 1412 1511
Oficio Electricista Plomero Plomero
Sueldo 3.50 3.00 3.75
