Continuación Modelo Relacional
En la clase de hoy se ha continuado con el concepto del Modelo Relacional y las tablas. Se ha hecho una comparativa entre un diagrama de un modelo de Entidad/Relación (Como el que hemos hecho en el proyecto de BBDD de la 1º Evaluación) y como quedaría en un sistema gestor de bases de datos (SGBD), en forma de tablas, columnas, etc.
En cuanto a las entidades relacionadas con las tablas, se conservan los atributos y la clave principal (Primary Key (PK)) por ejemplo: entidad= asignatura, atributos= CodAsig, Nombre, Créditos, Carácter, curso.
Las Claves Candidatas se establece una restricción de unicidad. Los atributos compuestos se indican en un campo por atributo, los atributos derivados se indican en columnas calculadas, los atributos multivaluados se indican en una nueva tabla. Si hubiese restricciones sobre atributos, se indica en lenguaje lógico.
En una tabla, las entidades débiles conservan sus atributos y se le añade la clave principal de la entidad fuerte de la que depende. Siendo la relación de identificación, la clave principal la forma un atributo de la entidad débil y la clave principal de la fuerte. Si fuese de existencia, tendrá su clave propia, pero se establece borrado y en actualización en cascada con respecto a la entidad fuerte. ejemplo: entidad=Grupo, atributos=(CodAsig, CodGrupo, max_alum).
En cuanto a las relaciones en una tabla, están formadas por los atributos de las claves principales de las entidades conectadas y los de las relaciones. la clave principal depende de la cardinalidad de la relación. en una cardinalidad M:N, su clave principal está formada por las claves principales de la entidades relacionadas, como mínimo. Tiene una dimensión temporal. Ejemplo: relación=Consta, Clave principal=CodMatr, CodAsig, CodGrupo, Convocatoria, calificación.
En una cardinalidad 1:N, su clave principal estará formada por la clave principal de la entidad con la cardinalidad N. Ejemplo: relación=Pertenece, clave principal=CodProf, CodDpto.
La cardinalidad 1:1, su clave principal estará formada por una clave principal de una de las entidades, la otra entidad actuará como clave candidata. Ejemplo: relación=Dirige, clave principal=CodProf, CodDpto.
Cuando surgen demasiadas tablas en estos casos, se pueden hacer reducciones de tablas. Solo se pueden reducir tablas en los casos de cardinalidades 1:1 y 1:N.
En casos en los que haya relaciones reflexivas, hay dos opciones: que se generen dos tablas con una clave principal de la entidad, con sus atributos, y otra con la clave principal de la relación con los atributos. Otra forma sería crear una tabla con una clave ajena.
Generalizando, al final se debe crear una tabla por cada entidad que participa. También se puede crear una tabla para cada caso particular, eliminando la super-entidad y añadiendo atributos de la super-entidad a las otras entidades. Este caso es menos frecuente. Hay otra manera de hacerlo que seria creando una tabla con una sola relación, que tomaría atributos de las entidades, pero este caso es también poco utilizado.
Existen unas restricciones semánticas de Totalidad/Parcialidad o de Exclusividad/Solapamiento. Las de totalidad/parcialidad se controla la totalidad prohibiendo la inserción en el supertipo directamente, primero se inserta en los subtipos (disparadores). la parcialidad no requiere disparadores.
Las de exclusividad/solapamiento, se requiere un aserto (Trigger) que comprueba que si un ejemplar esta en un subtipo, no puede estar en otro.
En relaciones N-Arias, una relación puede tener varias interpretaciones y todas ellas válidas. Dependen de la cardinalidad: si es N:M:S, su PK(Primary Key) es el conjunto de las PK de cada relación. Si es N:M:1, la PK será el conjunto de las PK con una cardinalidad distinta a 1. Si es N:1:1, es posible que se divida en dos relaciones 1:n.
Al final de la clase se ha dedicado a realizar algún ejercicio de ejemplo sobre lo visto hasta ahora, sobre los modelos relacionales y el paso a tablas.
No hay comentarios:
Publicar un comentario