Continuación Unidad 3
En la clase online de hoy hemos continuado con el contenido de la unidad 3 de Bases de Datos, el Modelo Relacional. En particular, hemos seguido realizando ejercicios sobre la obtención del modelo relacional de una serie de esquemas E/R( Entidad/Relación). Se han realizado los ejercicios 1, 2 y 3 de los propuestos en el aula virtual, el resto se ha propuesto ir haciéndolos para tratarlos en la próxima clase.
Continuación Selectores
En la clase hemos continuado viendo los selectores, como los selectores de id. Hay que aplicar un id, con el nombre que queramos, en la etiqueta que queramos aplicar unas características concretas y únicas en esa etiqueta. El nombre que apliquemos a un id no se puede volver a usar en ese documento. Se ubica justo después del nombre de la etiqueta, ejemplo: <h1 id="encabezado">. En CSS, los id se representan con el símbolo "#".
Se ha visto los modelos de cajas en CSS. Una caja es donde se encuentran un conjunto de elementos, o solo un elemento (muchos elementos forman una caja propia automáticamente) que queremos acotar, por tener relación entre ellos en nuestra página o por otro motivo en un documento de HTML. En los estilos de CSS, se pueden aplicar una serie de características a las cajas. Algunos son: border, margin, float, padding, etc.
Se ha observado que es muy importante validar nuestra página web, además de realizar una serie de pruebas en distintos navegadores de internet para comprobar que nuestra página funciona. Se puede comprobar mediante unas webs concretas, lo que los navegadores son capaces de soportar o no, como por ejemplo caniuse.com.
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.
