Diseñar bases de datos es un proceso metódico que parte del esquema conceptual. Pero que luego requiere realizar al menos dos esquemas más para acercarnos a la forma final en la que el ordenador representará la base de datos. El diagrama comentado en los apartados anteriores es el siguiente:
En esta unidad partiremos de un esquema conceptual (de tipo Entidad/Relación) ya creado para conseguir el siguiente esquema que será el esquema relacional. Por supuesto suponemos que necesitamos una base de datos de tipo relacional (de otro modo necesitaremos otro modelo lógico).
El esquema interno (que sería el siguiente a realizar) se verá en posteriores unidades. En el caso de este manual, será un esquema compatible con el sistema de bases de datos de Oracle.
La manera clásica de representar esquemas relacionales es usando esta notación:
TABLA(Columna1, Columna2,….) |
En la que además las claves primarias se representan subrayadas y las alternativas con un subrayado discontinuo.
Ejemplo:
PIEZAS(Tipo, Modelo, Nombre, Apellido1, Apellido2) EMPRESAS(CIF, Cod_Empresa, Nombre, Dirección) SUMINISTROS(Tipo,Modelo, Cod_Empresa, Precio) EXISTENCIAS(Tipo, Modelo, N_Almacen, Cantidad) |
Además se pueden indicar con otros símbolos las restricciones de unicidad (UNIQUE) y de obligatoriedad (NOT NULL).
En ese tipo de esquemas es difícil ver las relaciones en los datos, algo que sí se ve muy bien en los esquemas entidad relación. Por ello se suelen complementar los esquemas clásicos con líneas y diagramas que representan esa información.
Es un esquema relacional en el que hay líneas que enlazan las claves principales con las claves secundarias para representar mejor las relaciones. A veces se representa en forma de nodos de grafos y otras se complementa el clásico.
Ejemplo:
Hay quien los llama esquemas entidad/relación relacionales por su similitud con los esquemas entidad/relación. Lo cierto es que intentan representar todo lo que los esquemas conceptuales son capaces de representar y adaptarlo a las premisas del Modelo Relacional.
Sin embargo la mayoría no son capaces de representar lo mismo que el modelo entidad/relación de Chen, la razón estriba en que el modelo relacional no tiene tantas formas de relación. Por ello el modelo entidad/relación debe de seguir siendo una referencia que implicará crear restricciones apropiadas para reflejar la profundidad de las relaciones del modelo conceptual.
Quizá la forma más popular en todo tipo de herramientas CASE para representar esquemas relacionales es la notación de patas de gallo (crow’s foot es el término con el que se conoce en inglés) utilizado en diversas metodologías y herramientas de trabajo como la notación Barker1 (utilizada en gran medida por la propia empresa Oracle), en la metodología SSADM2, en la metodología Information Engineering (Ingeniería de la Información) y en otras metodologías y notaciones formales. Además está presente en la mayoría de herramientas CASE.
De hecho es una mezcla entre los esquemas relacionales y los entidad/relación. Hoy en día se utiliza mucho, en especial por las herramientas CASE de creación de diseños de bases de datos.
En el diagrama anterior (Ilustración 41) se puede examinar un modelo sencillo estilo pata de gallo. En estos diagramas la cardinalidad máxima n se dibuja con las famosas patas de gallo, la cardinalidad mínima de tipo cero con un círculo y la cardinalidad de tipo uno con una barra vertical. El hecho de que suministros y existencias tengan las esquinas redondeadas es para remarcar que representan relaciones entre entidades (no siempre se remarca).
En cualquier caso tampoco hay un estándar unánimemente aceptado para este tipo de notación.
Se ha hecho muy popular la forma de presentar esquemas relacionales del programa Microsoft Access, la cual se puede observar en la Ilustración 42.
Es otra forma muy clara de representar relaciones y cardinalidades (aunque tiene problemas para representar relaciones de dos o más atributos como se observa en la Ilustración 42).
Sin duda los esquemas más completos son los que reflejan no sólo las cardinalidades sino también todas las restricciones (e incluso los tipos de datos, aunque esto ya es una competencia del esquema interno). Véase el esquema de la Ilustración 43. En ese esquema los símbolos funcionan de esta forma:
|
Símbolo |
Ejemplo |
Significado |
|
Subrayado |
DNI |
Clave principal |
|
Subrayado discontinuo |
Clave2 |
Clave alternativa |
|
º |
Nombre º |
No admite valores nulos (restricción NOT NULL) |
|
* |
Nombre * |
No admite duplicados (restricción UNIQUE) |
Además los campos que están el final de una flecha son claves secundarias.
En el esquema anterior las flechas representan cardinalidades n y los círculos cardinalidades de tipo cero. Las de tipo uno no tienen ningún símbolo asignado. A este tipo de diagramas (los de flechas y ceros) se les llama diagramas en notación Bachman.
En muchas herramientas CASE, los diagramas relacionales suelen representar las restricciones con letras. De hecho, esta notación es la más habitual actualmente puesto que son las más completas. Aunque visualmente ocupen más espacio.
Ejemplo de notación en pata de gallo con las restricciones usando abreviaturas:
En este caso los símbolos PK significan Primary Key (clave principal), FK es Foreign Key (clave secundaria) UK (o simplemente U) es Unique (unicidad) y CK es restricción de validación (check). Los números sirven para aclarar los atributos que forman parte de la restricción. Así sabemos que en la tabla de prestamos, dni forma una clave foránea y n_copia otra distinta; y que fecha_prestamo, dni y n_copia forman juntos una restricción de unicidad.
Como norma base, las entidades fuertes del modelo Entidad Relación son transformadas al modelo relacional siguiendo estas instrucciones:
En este esquema se explica de forma más visual la transformación
Las relaciones no son tan sencillas de transformar. El modelo relacional no tiene la capacidad de representar tantos tipos de relaciones como en el esquema entidad/relación.
Hay que diferenciar cada tipo de relación. Por ello se estudian a continuación todos los casos
En las relaciones varios a varios (son aquellas que tienen n a n en la cardinalidad mayor, la cardinalidad menor no cuenta para esta situación), la relación se transforma en una tabla cuyos atributos son:
Hay que tener cuidado con las cardinalidades mínimas. La razón, es que en el dibujo final, lo que era una sola relación se convierte en dos relaciones, ya que lo que se indican en un diagrama relacional son las relaciones entre las tablas y ahora habrá tres tablas.
La tabla que representa la relación contendrá a su izquierda y derecha la nueva cardinalidad.
Todos los casos se exponen a continuación:
Se ve más claro este efecto en el dibujo siguiente en el que se ha dibujado una flecha morada señalado donde estaba antes la cardinalidad mínima de cero y donde aparece ahora.
Las relaciones ternarias, cuaternarias y n-arias que unen más de dos entidades, se transforman en una tabla que contiene los atributos de la relación, más los identificadores de las entidades relacionadas. La clave principal la forman todos los identificadores juntos.
En este caso la cardinalidad mínima no varía en lo más mínimo el resultado, aunque sí habría que tenerla en cuenta, su cálculo es excesivamente complicado por lo que no se interpreta en este manual (insistiendo en la escasa o inclusa nula influencia que tienen en el esquema final).
relaciones uno a varios
Las relaciones binarias de tipo uno a varios (sólo una cardinalidad máxima vale n) no requieren ser transformadas en una tabla en el modelo relacional. En su lugar la tabla del lado varios (tabla relacionada) incluye como clave externa3 el identificador de la entidad del lado uno (tabla principal).
La cardinalidad mínima hay que revisarla bien ya que en caso de que la clave externa se relacione obligatoriamente con la principal (cardinalidad mínima de uno), habrá que indicar una restricción de tipo NOT NULL para indicar esa situación.
Se describen todas las posibilidades de forma gráfica.
En el caso de las relaciones entre dos entidades con todas las cardinalidades a 1; hay dos posibilidades:
relaciones cero a uno
Se trata de relaciones entre dos entidades con cardinalidad máxima de 1 en ambas direcciones, pero en una de ellas la cardinalidad mínima es 0. En este caso la solución difiere respecto a la anterior solución. No conviene generar una única tabla ya que habría numerosos valores nulos en la tabla (debido a que hay ejemplares que no se relacionan en las dos tablas).
La solución pasa por generar dos tablas: una para cada entidad. En la tabla con cardinalidad 0, se coloca como clave secundaria, la clave principal de la otra (dicha clave secundaria será, además, clave alternativa de esa tabla):
En el caso de que en ambos extremos nos encontremos con relaciones 0 a 1, entonces la solución es la misma, pero la clave que se copia en la tabla para ser clave secundaria, debe de ser tomada de la entidad que se relacione más con la otra (la que esté más cerca de tener la cardinalidad 1 a 1 en el otro extremo). Dicha clave secundaria, en este caso, no será clave alternativa (pero sí tendrá restricción de unicidad, ya que sus valores no se repiten).
La razón de este movimiento es cuanto más cerca esté del valor “uno” la cardinalidad mínima, menos huecos vacíos dejaremos en las tablas (base de datos, por lo tanto, más eficiente).
En la clave secundaria no se indica ninguna restricción NOT NULL, ya que no todos los datos se relacionan.
Las relaciones recursivas se tratan de la misma forma que las otras, sólo que hay que imaginar que la tabla se divide en dos, una por cada rol. Teniendo en cuenta eso, la solución es idéntica a lo ya resuelto en los casos anteriores sólo que es una sola tabla la participante.
Es fácil confundirse en este tipo de relaciones por lo que hay que imaginarse esta situación:
Visto de esa forma se trabaja como si la entidad en realidad fueran dos distintas (en realidad no lo es), una por cada rol. De esa forma es más fácil considerar la transformación.
El esquema completa de transformación de relaciones recursivas es el siguiente:
Ilustración 58. Exposición de todas las posibles relaciones recursivas de tipo “1 a n” y “n a n” y su solución al pasarle a un diagrama relacional
En el caso de las relaciones recursivas con cardinalidades máximas de 1 a 1 hay que tomar más precauciones, ya que es más fácil equivocarse:
Toda entidad débil incorpora una relación implícita con una entidad fuerte de tipo 1 a n. Por ello simplemente se pasa como tabla la entidad fuerte y la débil, bastará con añadir como atributo y clave foránea en la entidad débil, el identificador de la entidad fuerte.
En ocasiones el identificador de la entidad débil tiene como parte de su identificador al identificador de la entidad fuerte (por ejemplo si para identificar líneas de factura utilizamos el número de línea y el número de factura, clave de la entidad factura). En esos casos no hace falta añadir de nuevo como clave externa el identificador de la entidad fuerte.
El paso se expresa en el siguiente esquema:
En el caso de las relaciones ISA, se siguen estas normas:
[1]Cada entidad de las relaciones ISA (sin importar si es super o subentidad) se convierte en una tabla que contendrá cada uno de los atributos de la entidad (en el caso de que la ISA sea de tipo total, se podría incluso no hacer una tabla para la superentidad y pasar todos sus atributos a sus subentidades, pero no es recomendable porque dificulta el trabajo en la base de datos y además refleja peor este tipo de relación).
[2]Si las subentidades no tienen clave propia, se colocará como clave, la clave de su superentidad. Esta clave heredada será clave externa (foreign key), además de clave principal.
[3]En el caso de que las subentidades tengan clave principal propia. Se colocará en las subentidades el identificador de la superentidad como clave externa que además será clave alternativa.
Ilustración 62. Entidad débil cuyo identificador contiene el de la entidad fuerte. En este caso se usa esa columna como clave externa (no se requiere añadir de nuevo el identificador de la tabla principal)
[4]Que la relación ISA sea exclusiva o no, no cambia el esquema relacional, pero sí habrá que tenerlo en cuenta para las restricciones futuras en el esquema interno (casi siempre se realizan mediante triggers), ya que en las exclusivas no puede haber repetición de la clave de la superentidad en ninguna subentidad (por ello si es posible se sigue dibujando el arco en este esquema).
[5]No varía el resultado porque la relación ISA sea total o parcial; el modelo relacional no tiene capacidad para marcar esa posibilidad. Pero es interesante tenerlo en cuenta (se suele añadir un comentario al diseño relacional para posibles restricciones, nuevamente mediante triggers, a crear)
El modelo conceptual entidad/relación es el verdadero mapa de la base de datos. Y en todo momento hay que mantenerlo dentro de la documentación de la base de datos ya que refleja aspectos que, desgraciadamente, el modelo relacional no puede.
Sin embargo el modelo relacional concreta aspectos de los datos muy importantes, como son las restricciones. Tiene además la virtud de que se entiende muy bien (sigue siendo muy conceptual) ya que es más simple
En definitiva ambos esquemas son fundamentales para todo profesional de la base de datos; por ello muchas empresas utilizan un esquema híbrido relacional que refleja también aspectos del modelo conceptual (la mayoría de las herramientas CASE llaman a esos esquemas, esquemas ERD (de Entity Relationship Diagram) aunque son más relacionales que conceptuales de tipo Entidad/Relación).
Sin embargo, la costumbre actual es hacer directamente el esquema relacional. Eso supone perder información y, además, atarse a un modelo que, aunque sigue siendo el más popular con diferencia, empieza a tener serios rivales en las bases de datos de tipo NoSQL.