UT+02.+Diseño+lógico

=UT 2. Diseño lógico de Bases de Datos.=

2.1 La representación del problema: los diagramas E/R entidades y relaciones. Cardinalidad. Debilidad.
=Metodología para el diseño de un diagrama E/R.= Al enfrentarnos con el problema de tener que realizar un modelo conceptual de un sistema, podemos afrontarlo siguiendo los siguientes pasos o tareas:
 * 1) **Identificar las entidades**. Una forma de identificar las entidades es buscar los nombres que se mencionan en los requisitos de la base de datos. Otra forma de identificar las entidades es buscar aquellos objetos que existen por sí mismos. Por ejemplo, //empleado.//
 * 2) **Identificar las relaciones**. Una vez definidas las entidades, se deben definir las relaciones existentes entre ellas. Del mismo modo que para identificar las entidades se buscaban nombres en las especificaciones de requisitos, para identificar las relaciones se suelen buscar las expresiones verbales (por ejemplo: oficina tiene empleados, empleado gestiona inmueble, cliente visita inmueble). Una vez identificadas todas las relaciones, hay que determinar la cardinalidad mínima y máxima con la que participa cada entidad
 * 3) **Identificar los atributos y asociarlos a entidades y relaciones**. Al igual que con las entidades, se buscan nombres en las especificaciones de requisitos. Son atributos los nombres que identifican propiedades, cualidades, identificadores o características de entidades o relaciones.
 * 4) **Determinar los dominios de los atributos**. El dominio de un atributo es el conjunto de valores que puede tomar el atributo.
 * 5) **Determinar los identificadores**. Cada entidad tiene al menos un identificador.
 * 6) **Determinar las jerarquías de generalización (si las hay)**. Hay que ver si es necesario reflejar las diferencias entre distintas ocurrencias de una entidad, con lo que surgirán nuevas subentidades de esta entidad genérica.
 * 7) **Dibujar el diagrama entidad-relación**. Una vez identificados todos los conceptos, se puede dibujar el diagrama entidad-relación correspondiente a una de las vistas de los usuarios.
 * 8) **Revisar el esquema conceptual con el usuario**. Este proceso debe repetirse hasta que se esté seguro de que el esquema conceptual es una fiel representación de la parte de la empresa que se está tratando de modelar

Evidentemente, no es necesario seguir estos pasos al pie de la letra, en un proceso de modelado real se pueden realizar las tareas en el orden en que se encuentren las diferentes elementos del modelo.

2.2 El modelo E/R ampliado.
Ejercicios Algunos ejerccios puestos en exámenes

2.3 El modelo relacional: Terminología del modelo relacional. Características de una relación. Claves primarias y claves ajenas.
El modelo relaciona fue inventado por E.F. Codd como un modelo general de datos. Es un modelo simple y potente que sirve para representar problemas. El formalismo y la base matemática utilizada para definirlo se denomina teoría de bases de datos relacionales.

Elementos del modelo.
El elemento principal del modelo relacional es la relación. Una base de datos relacional está formada por un conjunto de relaciones. Los componentes del modelos son:
 * La relación.
 * Los dominios.
 * Claves.
 * Vistas

2.3.1 Estructura de datos básica: Relación
Una relación es una estructura de datos que se utiliza para almacenar toda la información de una base de datos relacional. Representa una entidad o una asociación de entidades. La relación se representa mediante una tabla. Una relación está formada por un conjuto de atributos y un conjunto de tuplas.
 * Atributo (columna). Se representa como una columna en la tabla.
 * Tupla (fila). Se representa como una fila en la tabla.

Restricciones inherentes.

 * 1) En una relación no puede haber dos tuplas iguales (la clave primaria es obligatoria).
 * 2) El orden de las tuplas y de los atributos no es relevante.
 * 3) Cada atributo sólo puede tomar un valor.
 * 4) Ningún atributo que forme parte de la clave primaria de una relación puede tomar un valor nulo.

Restricciones semánticas.

 * 1) Restricción de **clave primaria** (PRIMARY KEY). Declara un atributo o conjunto de atributos como clave primaria de una relación, que identifica unívocamente cada tupla de la relación.
 * 2) Restricción de **unicidad** (UNIQUE). Permite definir claves alternativas.
 * 3) Restricción de **obligatoriedad** (NOT NULL). Permite declarar si uno o varios atributos de una relación deben tomar siempre un valor, es decir, no pueden tomar valores nulos.
 * 4) Restricción de **clave ajena** (FOREIGN KEY). Llamada también integridad referencial, es un conjunto de atributos de una relación que es clave primaria en otra o la misma relación. Permite enlazar relaciones (tablas) entre sí. La integridad referencial nos indica que que los valores de la clave ajena en la relación hijo deben corresponderse con los valores de la clave primaria en la relación padre o bien ser nulos. Además de la integridad referencial, el modelo relacional permite definir opciones de borrado y modificación en las claves ajenas. Estas opciones indican las acciones que hay que llevar a cabo cuando se produce un borrado o modificación de una tupla en la relación padre referenciada por una relación hija.
 * Ninguna acción (RESTRICT).
 * Actualizar en cascada (CASCADE).
 * Poner a nulo (SET NULL).
 * Predeterminar (SET DEFAULT).

Representación del modelo relacional en texto:
El nombre de la relación se pone en mayúsculas, y entre paréntesis todos sus atributos en minúsculas.

code RELACION(Atributo1, Atributo2, Atributo3, ...) code

Modificadores del estilo de los atributos:
 * Atributo clave primaria: __Subrayado__
 * Atributo clave alternativa: **Negrita**
 * Atributo no obligatorio: Asterisco*
 * Atributo que es clave ajena: //cursiva//

Para indicar la clave ajena, puede tomarse dos alternativas, ponerlo directamente como texto: code ESPECIE(Especie, NombreCientifico, MesFloración*) PLANTA(IDPlanta, FechaPuesta, Foto*, Especie) Clave ajena: {Especie} referencia a ESPECIE code O dibujar una flecha que apunte a la tabla a la que se referencia:

Cuando se realizan cambios en los valores que afectan a claves ajenas de borrado (ON DELETE, denotado con una **d**) y modificación (ON MODIFY, denotado con una **m**) existen cuatro opciones de comportamiento: Estas letras se anotan junto a la flecha que indica la clave ajena como en el siguiente ejemplo:
 * Ninguna acción (RESTRICT). Se denota con una **r**.
 * Actualizar en cascada (CASCADE). Se denota con una **c**.
 * Poner a nulo (SET NULL). Se denota con una **n**.
 * Predeterminar (SET DEFAULT). Se denota con una **d**.

2.4 Paso del diagrama E/R al modelo relacional.
En este apartado se describen todos los pasos necesarios para pasar de un esquema E/R a un esquema lógico.

2.4.1 De Entidad fuerte a Relación
Una entidad fuerte da como resultado una relación cuyos atributos son los atributos de la entidad. Lla clave primaria de la relación será el conjunto de atributos que eran identificadores principales en la entidad.

2.4.2 De Entidad debil a Relación
Una entidad debil da como resultado una relación cuyos atributos son los atributos de la entidad débil y los atributos de la clave de la entidad fuerte con la que está relacionada de forma dependiente, que se consideran clave ajena. La clave se obtiene juntando los atributos de la clave ajena y los atributos "cruzados" de la entidad débil.

2.4.3 De Relaciones a Relaciones
Las relaciones entre entidades dan como resultado la inclusión de claves ajenas en entidades u otras relaciones:
 * Cuando existen relaciones "uno a uno" o "uno a muchos" se añade una clave ajena en la relación que surgió de la entidad del lado de "muchos", o en cualquier lugar en el caso de "uno a uno". Los atributos de la relación se añaden a continuación de la clave ajena.
 * Cuando existen relaciones "muchos a muchos" se crea una nueva relación cuyos atributos son las claves de ambas entidades relacionadas. Los atributos de la relación se añaden a ésta relación.
 * La relaciones más complejas (grado 3) se definen como una extensión de las de grado dos "muchos a muchos".

2.4.4 De relaciones de generalización a Relaciones.
Dependiendo del tipo de relación (parcial/completa, exclusiva/solapada) pueden transformase de una de las siguientes formas:


 * OPCION A**: Crear una relación para la superentidad, con sus atributos correspondientes y una relación para cada subentidad con sus atributos mas la clave primaria de la superclase (clave ajena y clave primaria a la vez en la subclase). Esta opción es válida para cualquier tipo de generalización.
 * OPCION B**: Crear para cada subentidad una relación con los atributos de la superentidad mas los atributos propios, donde la clave primaria será la de la superentidad. Esta opción sólo es válida para las especializaciones totales (ya que no existe relación de la superentidad) y exclusivas (para no tener datos redundantes.
 * OPCION C**: Crear una sola relación con todos los atributos de la superentidad y las subentidades mas un atributo T que indica la subentidad a la que la tupla pertenece. Apropiada para relaciones de tipo exclusiva. La relación tendrá siempre muchos valores nulos. Esta opción es apropiada únicamente cuando existen subentidades con pocos atributos.
 * OPCION D**: Crear una sola relación con todos los atributos de la superentidad mas los atributos de las subentidades, mas unos atributos Ti cuyo valor lógico nos indicará a qué subentidad pertenece la tupla. Esta opción corresponde a la opción C pero para soportar solapamiento.