Conceptos básicos

Modelos y esquemas

Durante la fase de diseño lógico transformaremos el Esquema Conceptual (Diagrama Entidad-Relación) en un Esquema Lógico. ¿Cómo? Se puede hacer de diferentes formas, llamadas modelos lógicos.

Esquema Conceptual

Es decir, tradicionalmente, tenemos tres tipos de modelos lógicos:

  • Modelo Lógico Relacional (el que se utiliza actualmente)
  • Modelo Lógico Jerárquico
  • Modelo Lógico Red

Nosotros utilizaremos el Modelo Lógico Relacional, en el que, a partir de un esquema ER , obtendremos un Esquema Lógico Relacional .

Hay que diferenciar entre “modelo” y “esquema”:

  • Modelo de datos: es la herramienta intelectual (conjunto de conceptos y reglas) que permite representar los aspectos estáticos y dinámicos de la parte del mundo real que queremos estudiar.
  • Esquema: es la representación concreta de la parte del mundo real utilizando un modelo de datos.

Elementos del modelo relacional

Los distintos tipos de elementos que vimos en el modelo ER tienen nombres distintos en las diferentes fases del ciclo de vida:

Fase: Análisis Diseño Implementación
Modelo: ER Relacional Físico
Objetos: Entidades y Relaciones Relaciones Tablas
Características: Atributos Campos Columnas
Datos: Ocurrencias Registros o tuplas Filas

El modelo relacional (Edgard Codd 1970) representa una BD como un conjunto de relaciones . Por ejemplo, la relación EMPLEADOS podría ser ésta:

DNI Nombre Apellido Dirección
27456363Z Pep García c/ Sequial, 3
32456783X Marta Pinar c/ Nuevo, 17, 3a
12345678A Manel Meseguer c/ Niu, 33
98765432Y Juan Rueda

A cada una de las filas de la tabla se le llama tupla o registro . Cada una de las columnas se le llama atributo o campo .

Importante

  • Los campos son los nombres de propiedades de una relación.
  • Cada registro representa un conjunto de valores de datos relacionados entre sí.

  • Una relación está formada por campos y por registros, cumpliendo las siguientes condiciones:

    1. No hay tuplas duplicadas en una relación
    2. No hay orden entre las tuplas

No es lo mismo una tabla y una relación. Las tablas son la implementación de las relaciones, donde las filas y columnas tendrán un orden en concreto. Ahora bien, abusando del lenguaje, para no confundir las “relaciones” del diseño (las tablas) con las “relaciones” del análisis (los rombos), utilizaremos indistintamente los términos de “tabla” y “relación”.

El modelo de datos dependerá del SGBD con el que vayamos a trabajar. Supondremos que nuestro SGBD sí permitirá que una clave alternativa acepte valores nulos.

Claves de las tablas

En el modelo relacional, las tuplas no pueden estar duplicadas. Para eso están las claves.

Existen distintos tipos de claves:

  • Clave candidata (primarias / alternativas)
  • Clave ajena

Clave

Es un atributo (o más de uno) de la tabla que cumple 2 condiciones:

  • a) UNICIDAD (identificación única). No puede haber dos tuplas de R con el mismo valor de cada uno de los atributos de la clave.
  • b) MINIMALIDAD (no redundancia). No sobra ningún atributo de la clave. Es decir: ninguno de los atributos de la clave puede ser eliminado sin que el conjunto resultante deje de cumplir la propiedad anterior. Ejemplo :
    • PROFESSOR = dni + nif + ... + dpt
    • La clave NO puede ser dni + nif porque puedo eliminar el nif de la clave, i la nueva clave resultante (dni) sigue cumpliendo la primera propiedad (identifica unívocamente cada registro).

Tipos de claves

  • Clave candidata: Cada una de las claves de una tabla. 2 tipos de claves candidatas:
  • Clave primaria: De todas las cluas de una tabla, se elige una como clave primaria. Ésta debe cumplir la condición de que no podrán haber valores nulos en esa clave.
  • Clave alternativa: Todas las demás claves. Siempre habrá una clave primaria, pero puede que no haya una clave alternativa. Nosotros supondremos que el SGBD donde implementaremos nuestra BD acepta valores nulos en las claves alternativas . Si no fuera así, el “paso a tablas” podría ser distinto.
  • Clave ajena (o externa) : atributo (o conjunto de atributos) de una tabla, cuyo valor debe coincidir con el valor de la clave primaria de otra tabla, a la que referencia. Las claves ajenas sirven para representar las relaciones entre entidades del ER.

Relación PROFESORES

  • DEPARTAMENTOS = dept + nom_dept + ...
  • PROFESORES = dni + nom + ... + dpt
    • C. Aj : dpt -> DEPARTAMENTOS (dept)
      • Estamos diciento que dpt es una clave ajena e identifica al DEPARTAMENTO. Los valores de dpt que aparecen en PROESORES han de estar también como valores de la clave primaria de DEPARTAMENTOS (es decir, en dept). Es decir, si en PROFESORES hay un valor de dpt que no está en DEPARTAMENTOS, habría una violación de la integridad referencial.

Restricciones de valor NO NULO (VNN)

Si a una relación se le pone esta restricción en un atributo, ningún valor de este atributo podrá ser nulo. En el modelo relacional, para expresar que un atributo tiene una restricción de valor no nulo, lo indicaremos con VNN. Por ejemplo:

Ejemplo de VNN

  • DEPARTAMENTOS = dept + nom_dept + ...
  • PROFESORES = dni + nom + ... + dpt
    • C. Aj : dpt -> DEPARTAMENTOS (dept)
    • VNN: nom, dpt

Restricciones de integridad implícitas

Hay algunas restricciones que no es necesario indicarlas en el esquema lógico porque ya se sobreentienden. Están implícitas en el modelo. Son reglas de integridad general relacionadas con los tipos de claves:

  • Integridad de claves (clave primaria): Ningún atributo componente de la clave primaria de una relación puede tener un valor nulo.
  • Integridad referencial (clave ajena): Si algún valor de una clave ajena no es nulo, deberá ser igual a algún valor del campo de la tabla a la que hace referencia.

Ejemplo de clave ajena:

Ejemplo de clave ajena

  • DEPARTAMENTO = dept + nom_dept + ...
  • ASIGNATURA = cod + nom + ... + dpt

    • C. Aj : dpt -> DEPARTAMENTO (dept)

      En este caso, la clave ajena dpt de la tabla ASSIGNATURA hace referencia a la clave primaria dept de la tabla DEPARTAMENTO. Esto significa que los valores

Integridad referencial

La integridad de claves indica que los valores de la clave primaria (dept) no pueden ser nulos y deben ser únicos en la tabla DEPARTAMENT. La integridad referencial indica en este ejemplo que los valores de la clave ajena (dpt) o son nulos o coinciden con el valor de la clave primaria de DEPARTAMENT (dept) en alguna tupla.

  • Para indicar que un campo es clave primaria, subrayaremos ese campo.
  • Para indicar que un campo es una clave ajena, lo indicaremos con “C. Aj”, como en el ejemplo anterior.

Otras consideraciones

En este apartado repasaremos algunos conceptos y lo veremos gráficamente.

El esquema de una tabla T, denotado :

T = A1 + A2 + ...+ An

se compone del nombre de la tabla (T) y de la lista de los atributos de la tabla ( A1, ... , An) . Además, todo esquema de tabla debe tener una clave primaria, que suele subrayarse.

Ejemplo de esquema de tabla:

  • EMPLEADOS = DNI + Nombre + Apellidos + Dirección

Ejemplos de ocurrencias (registros) de la tabla EMPLEADOS:

DNI Nombre Apellidos Dirección
20934594S Pepito Pérez c/ Sequial, 5, 2a
24562354A Pepita Garcia c/ Nuevo 19
78378243N Maria Albors

Una BD relacional suele contener muchas tablas (relaciones). Por ejemplo, la BD Instituto podría estar formada por las tablas: PROFESORES, ASIGNATURAS, ALUMNOS y GRUPOS.

Relaciones unarias

Una clave ajena puede hacer referencia a su propia tabla, por ejemplo una relación entre un empleado y su jefe. En este caso, la relación se denomina relación unaria

Algunas observaciones a realizar (que veremos en el tema) son:

  • Un mismo concepto del mundo real, al representarse como un atributo, puede tener nombres diferentes en las tablas donde aparece (“ dpt ”, “ dept ”, “ depart ”, ...)
  • Las relaciones del ER (es decir, los rombos y triángulos) se representarán en el esquema relacional con las claves primarias y ajenas de las tablas.
  • En un esquema relacional habrá que crear:
    • Una tabla por cada entidad
    • Una tabla por cada atributo multivalente.
    • Una tabla por cada relación ternaria
    • Una tabla por cada relación binaria M:M

Teniendo en cuenta las claves ajenas, podemos “navegar” por las tablas:

Modelo Relacional: transformación del ER en tablas

Existen dos técnicas para diseñar BD relacionales, dependiendo de si hemos realizado previamente el ER o no. Es decir, para obtener el conjunto de tablas de un esquema relacional, podemos hacerlo de 2 formas:

Transformación del ER en tablas"

Esta técnica se utiliza cuando partimos de un esquema ER . Aplicándole unas reglas obtendremos el conjunto de tablas correspondiente. También se debe intentar pasar a tablas las demás restricciones que no se podían captar en el ER. Las que no se puedan pasar a tablas, quedarán todavía como “otras restricciones de integridad”.

Normalización de tablas

Esta técnica se utiliza cuando partimos de un esquema de tablas “hecho de cualquier modo” . Aplicando unas reglas a esas tablas, obtendremos un buen esquema de tablas. Es decir: obtendremos un conjunto de tablas normalizadas.

En ambas técnicas, se pretende conseguir, entre otros, los siguientes objetivos:

  • Conservar las restricciones de clave, conectividad y cardinalidad.
  • Evitar duplicaciones de datos.
  • Evitar valores nulos donde no toque ponerlos.

De esas dos técnicas del modelo relacional en este punto veremos la transformación del ER en tablas: veremos cómo obtener el conjunto de relaciones (tablas) equivalentes a cada una de las entidades y relaciones del modelo Entidad/Relación.

Aunque con esta técnica se pueden obtener tablas con redundancias, es la más utilizada en la práctica. Por tanto precisaría de unproceso de normalización posterior para eliminar las redundancias. Pero este proceso queda fuera del alcance de este tema.