Ya hemos visto anteriormente que existen varios esquemas a realizar para poder representar en forma de base de datos informática un problema procedente del ordenador.
El primero de esos esquemas es el llamado esquema conceptual, que representa la información de forma absolutamente independiente al Sistema Gestor de Base de Datos. Los esquemas internos de las diferentes bases de datos no captan la semántica del mundo real, ya que se centran más en estructura de almacenamiento más cercanas a la computadora; de ahí que primero haya que pasar por uno o dos esquemas previos, más cercanos al mundo real y que permitirían adaptar el problema a todo tipo de sistemas.
El hecho de saltarse el esquema conceptual conlleva un problema de pérdida de percepción con el problema real, ya que nos aproximamos demasiado al ordenador y nos alejamos de la información como la entiende el ser humano y eso, a la larga, provoca problemas de incoherencia en los datos. El esquema conceptual debe reflejar todos los aspectos relevantes del mundo a real a modelar.
En 1976 y 1977 dos artículos de Peter P. Chen detallaron un modelo para realizar esquemas con la idea de proveer una visión unificada de los datos de un sistema de base de datos. Este modelo es el modelo entidad/interrelación (entity/relationship en inglés) que actualmente se conoce más con el nombre de entidad/relación (Modelo E/R o ME/R, en inglés E/RM).
Posteriormente otros autores han añadido mejoras a este modelo lo que ha producido toda una familia de modelos basados en el modelo Entidad/Relación original. La más aceptada actualmente es el modelo entidad/relación extendido (ERE) que complementa algunas carencias del modelo original. No obstante las diversas variantes del modelo hacen que los esquemas que dibujan los profesionales no sigan un verdadero estándar y sean dispares, aunque hay ideas muy comunes a todos los “dialectos” del modelo entidad/relación.
Hay que insistir en que este modelo no tiene nada (o muy poco) que ver con las bases de datos relacionales, los esquemas entidad/relación se pueden utilizar (en principio) con cualquier SGBD ya que son conceptuales. Puede que nos confunda el uso de la palabra relación, ya que está presente en el modelo relacional de las bases de datos de Edgar F. Codd; pero el concepto de relación en este esquema no tiene nada que ver con la idea de relación expuesta por Codd en su modelo relacional.
Se trata de cualquier objeto u elemento (real o abstracto) acerca del cual se pueda almacenar información en la base de datos. Es decir cualquier elemento informativo que tenga importancia para una base de datos.
Ejemplos de entidades son una persona que se llama Pedro, la factura número 32456, el coche matrícula 3452BCW, etc. Una entidad no es un propiedad concreta sino un objeto que puede poseer múltiples propiedades (atributos). Es decir “Sánchez” es el contenido del atributo Primer Apellido de la entidad que representa a la persona Pedro Sánchez Crespo con DNI 12766374,...
Las entidades son objetos completos, con todos los valores de las propiedades de dicho objeto. Descubrir entidades es la tarea principal del diseño de esquemas Entidad/Relación
Las entidades que poseen las mismas propiedades, por que se refieren al mismo tipo de ente, forman conjuntos de entidades. Ejemplos de conjuntos de entidades son: personas, facturas, coches,...
Ilustración 20. Ejemplo de entidad y conjunto de entidades
En la actualidad se suele llamar entidad a lo que anteriormente se ha definido como conjunto de entidades, seguramente por una cuestión de ahorro en el lenguaje. De este modo hablaríamos de la entidad PERSONAS. Mientras que cada persona en concreto sería una ocurrencia o un ejemplar de la entidad persona.
Esta terminología es la que actualmente vamos a utilizar en este manual, por lo que hablaremos de entidades como conjunto de ejemplares.
En el modelo entidad relación los conjuntos de entidades se representan con un rectángulo dentro del cual se escribe el nombre de la entidad:
Ilustración 21. Representación de la entidad personas
Representan asociaciones entre entidades, es decir entidades de un conjunto que tienen contacto con entidades de otro conjunto. Es el elemento del modelo que permite relacionar en sí los datos del mismo; de otro modo tendríamos información aislada. Por ejemplo, en el caso de que tengamos una entidad personas y otra entidad trabajos. Ambas se relacionan ya que las personas trabajan y los trabajos son realizados por personas.
Ilustración 22. Ejemplo de relación, el nombre podría ser: trabajador
En el dibujo anterior, trabajar podría ser el nombre del conjunto de relaciones entre las entidades personas y trabajos.
En una relación (Chen llamaba conjunto de relaciones a lo que ahora vamos a llamar relación a secas) cada ejemplar (cada relación en la terminología de Chen) asocia un elemento de una entidad con otro de la otra entidad.
Una regla fundamental es que en una relación no pueden aparecer dos veces relacionados los mismos ejemplares de cada entidad. Una relación estable una asociación entre un ejemplar de una entidad con un ejemplar de otra entidad, una vez. Es decir; en el ejemplo anterior, en la relación no puede aparecer dos veces el mismo trabajador asociado al mismo trabajo. Si consideramos que nuestro diseño requiere esta posibilidad, no hay que dudar: nuestro diseño no será correcto.
La representación gráfica de las entidades se realiza con un rombo al que se le unen líneas que se dirigen a las entidades, las relaciones tienen nombre (se suele usar un verbo). En el ejemplo anterior podría usarse como nombre de relación, trabajar:
Ilustración 23. Tipos de relaciones
Indica el número de relaciones en las que una entidad puede aparecer. Se anota en términos de:
En los esquemas entidad / relación la cardinalidad se puede indicar de muchas formas. Quizá la más completa (y la que se utiliza en este documento es ésta) consiste en anotar en los extremos la cardinalidad máxima y mínima de cada entidad en la relación.
Ejemplo de uso de cardinalidad:
Ilustración 24. Cardinalidades
En el ejemplo un jugador tiene una cardinalidad mínima de 0 (puede no estar en ningún equipo) y una máxima de 1 (como mucho está en un equipo, no puede estar en dos a la vez). Cada equipo tiene una cardinalidad mínima de uno (en realidad sería una cardinalidad mínima más alta, pero se anota un uno) y una máxima de n (en cada equipo hay muchos jugadores)
A veces en las líneas de la relación se indican roles. Los roles representan el papel que juega una entidad en una determinada relación. Son imprescindibles cuando las relaciones son complejas, ya que ayudan a entender el sentido de la relación.
Ejemplo:
Ilustración 25. Ejemplo de rol. Un trabajador puede ser visto como jefe o como empleado según a qué lado de la relación esté
Describen propiedades de las entidades y las relaciones. Son fundamentales y establecen la información que deseamos almacenar de cada objeto de la base de datos. El modelo Entidad/Relación clásico los representa con elipses, dentro de las cuales se coloca el nombre del atributo. La elipse se une con una línea a las entidades.
Ejemplo:
Ilustración 26. Extracto de esquema E/R con atributos
Se trata de atributos que se pueden descomponer en otros más sencillos:
Pueden tomar varios valores (varios teléfonos para el mismo cliente):
Otra forma de representar atributos que pueden tomar múltiples valores es ésta:
Lo son si pueden tener valor nulo (es decir, si pueden quedar vacíos, sin valor):
Otra forma de representarlos es:
Se trata de uno o más atributos de una entidad cuyos valores son únicos en cada ejemplar de la entidad. Es decir todos los elementos de una entidad tienen en ese (o esos) atributo, un valor diferente (y nunca vacío).
Este tipo de atributos son fundamentales y se marcan en el esquema subrayando el nombre del identificador.
Para que un atributo sea considerado un buen identificador tiene que cumplir con los siguientes requisitos:
[1]Deben distinguir a cada ejemplar de la entidad o relación. Es decir no puede haber dos ejemplares con el mismo valor en el identificador.
[2]Todos los ejemplares de una entidad deben tener el mismo identificador.
[3]Un identificador puede estar formado por más de un atributo.
[4]Puede haber varios identificadores candidatos, en ese caso hay que elegir el que tenga más importancia en nuestro sistema (el resto pasan a ser alternativos).
Todas las entidades deben de tener un identificador, en el caso de que una entidad no disponga de un identificador (puede ocurrir, pero hay que ser cauteloso, a veces se trata de entidades que están mal modeladas) entonces hay que añadir un atributo que haga de identificador. Los futuros valores de este atributo no nos interesan, lo único que necesitamos de él es que disponga de un valor diferente para cada ejemplar de la entidad. El nombre de este atributo artificial es la palabra id seguida del nombre de la entidad. Por ejemplo id_personas.
Se trata de uno o más atributos en la entidad cuyos valores son únicos para cada ejemplar de una entidad, pero que no son identificadores ya que hay atributos que resultan ser mejores identificadores. Los identificadores alternativos se marcan con un subrayado discontinuo (ejemplo de subrayado discontinuo)
Como hemos visto en los dos puntos anteriores, es habitual disponer de varios identificadores candidatos para la misma entidad. Por ello ¿cuál elegir como identificador principal?
[1]Siempre debemos elegir el candidato que tenga más que ver con el problema que estamos resolviendo. Es decir entre un documento nacional de identidad y un código que sólo se usa en la empresa (código cliente, código de socio, nº de personal,…), hay que elegir la segunda opción. La razón es que seguro que en la empresa se tienen más en consideración este segundo número. Como razón técnica : los códigos internos siempre son más cortos que los generales.
[2]Realmente en el modelo conceptual la única razón a tener en cuenta es la expuesta en el punto anterior. Sin embargo, podemos ahorrar trabajo cuando hagamos el esquema lógico si ya cumplimos estas otras reglas (que en realidad son técnicas):
[3]En todo caso, cuando pasemos el modelo E/R a su forma lógica (por ejemplo utilizando el modelo relacional) podemos cambiar de idea respecto al identificador a fin de diseñar un esquema más eficiente; por lo que lo dicho en el apartado anterior puede no ser tenido en cuenta.
En el caso de que nos inventemos un identificador principal, por no tener candidatos o no ser adecuados, se debería de nombrar con el texto id seguido del nombre de la entidad en singular. Por ejemplo para una entidad de clientes sería id_cliente. De esa forma, cualquier analista que observe el diagrama entiende, solo por el nombre del identificador, si ha sido forzado o no.
En el modelo entidad relación extendido aparecen nuevos tipos de relaciones. Son las relaciones ISA (es un) y las entidades débiles
Se dice que una entidad débil es aquella cuya existencia depende de otra (considerada su entidad fuerte). Se trata de entidades totalmente supeditadas a otras, de modo que si un ejemplar de la entidad fuerte desaparece, todos los ejemplares de la entidad débil relacionados, desparacerán también del sistema.
Las entidades débiles ocurren cuando hay una entidad más fuerte de la que dependen, en el sentido de que la propia existencia de la entidad débil está supeditada a la existencia de su entidad fuerte. Lógicamente tienen relación con esa entidad, y es esa relación es la que marca el hecho de que una entidad es débil y la otra fuerte.
Ilustración 27. Relación que encaja en la definición de una entidad débil.
En la Ilustración 27, la relación entre las tareas y los trabajos es 1 a n (cada trabajo se compone de n tareas). Una tarea obligatoriamente está asignada a un trabajo, es más no tiene sentido hablar de tareas sin hablar del trabajo del que forma parte. La relación que tienen las tareas con los trabajos es de debilidad, puesto que no podemos referirnos a una tarea de forma independiente.
En el ejemplo anterior hay incluso (aunque no siempre) una dependencia de identificación ya que las tareas se identifican por un número de tarea y el número de trabajo al que se asignan. Cuando eso ocurre, es un síntoma definitivo de que se trata de una entidad débil. Por ello es tan importante determinar correctamente los identificadores de las entidades.
La cardinalidad de una entidad débil siempre es la siguiente:
La forma de representar estas relaciones es la siguiente:
Ilustración 28. Representación de una entidad débil
No hace falta dibujar el rombo de la relación ni la cardinalidad, se sobreentiende el tipo y cardinalidad (1 a n) que posee. En este caso además hay dependencia de identificación (no siempre la hay)
Son relaciones que indican relaciones que permiten distinguir tipos de entidades, es decir tendremos entidades que son un (is a, en inglés) tipo de entidad respecto a otra entidad más general.
Se utilizan para unificar entidades agrupándolas en una entidad más general (generalización) o bien para dividir una entidad en entidades más específicas (especificación): aunque hoy en día a todas ellas se las suele llamar generalización e incluso (quizá incluso más adecuadamente) relaciones de herencia.
Se habla de superentidad refiriéndonos a la entidad general sobre las que derivan las otras (que se llaman subentidades). En la superentidad se indican los atributos comunes a todas las subentidades, se sobreentiende que las subentidades también tienen esos atributos, pero no se indican de nuevo esos atributos en el diagrama.
Normalmente cuando tenemos una especialización, las subentidades comparten clave con la superentidad (además de los atributos comunes); esto es muy matizable y de hecho hoy en día ningún diseñador intenta distinguir entre si tenemos una especialización o una generalización, porque al final ambas implican el mismo esquema interno en la base de datos.
La forma clásica de representar una ISA en el modelo Entidad/Relación es:
Ilustración 29. Relación ISA. ¿Generalización o especialización? En la práctica no importa
En general se suelen indicar las cardinalidades en las relaciones ISA, pero se suele sobreentender (cuando no se indican explícitamente) que hay un (0,1) encima de cada subentidad (que significa que cada ejemplar de la subentidad solo puede relacionarse como mucho con uno de la subentidad e incluso con ninguno; un empleado de personal podría ser o no ser un profesor).
Pero se puede perfectamente indicar la cardinalidad (se usa ya la notación de ISA con triángulo hacia abajo que es la más popular en España actualmente):
Ilustración 30. Ejemplo de relación ISA
Las cardinalidades que aparecen en el esquema anterior son las habituales (de hecho no se suele indicar ya que se sobrentienden esas cardinalidades). Aunque, en principio, cualquier cardinalidad sería válida es raro utilizar otras diferentes a las de la Ilustración 31.
En la relación ISA anterior, los profesores, bedeles y técnicos heredan el atributo id personal y el nombre, el resto son atributos propios sólo de cada entidad (trienios pertenece sólo a los profesores, en este ejemplo)
Ilustración 31. La clave de la superentidad no es clave de las subentidades y además la cardinalidad indica que hay libros, discos y material de merchandising que no se relaciona obligatoriamente con algún artículo
En la ilustración anterior se utiliza una clave distinta para cada subentidad (es decir, discos, libros y merchandising tienen clave propia), no la heredan.
Además, es un caso en el que no hay relación obligatoria con la superentidad; es decir, un disco podría no ser un artículo (porque a lo mejor quiero meter discos en mi base de datos que no vendo en la tienda). No es muy habitual utilizar de esta forma relaciones ISA, pero desde luego es posible.
Normalmente en los esquemas no se indican las cardinalidades de las relaciones ISA y se sobrentiende que la superentidad tiene un 1,1 y las subentidades 0,1; es la cardinalidad habitual.
Ilustración 32. A la derecha el mismo gráfico Entidad/Relación sin indicar las cardinalidades. Se sobrentiende que son las de la izquierda
En las relaciones ISA (y también en otros tipos de relaciones) se puede indicar el hecho de que cada ejemplar sólo puede participar en una de entre varias ramas de una relación. Este hecho se marca con un arco entre las distintas relaciones. En las relaciones ISA se usa mucho para indicar que cada ejemplar de la superentidad sólo se relaciona con una subtentidad, por ejemplo:
Ilustración 33. Relación ISA con obligatoriedad
En el ejemplo, el personal sólo puede ser o bedel o profesor o técnico; una y sólo una de las tres cosas (es por cierto la forma más habitual de relación ISA).
Ilustración 34. Tipos de relaciones ISA, las cuatro posibilidades.
Realmente lo que hay que matizar bien en las relaciones ISA es la forma de relacionarse la superentidad con la subentidad. Eso se matiza en base a dos conceptos:
La forma gráfica más aceptada actualmente para representar este tipo de relaciones es la mostrada en la Ilustración 35.
Las herramientas CASE actuales no suelen utilizar la forma de dibujar del modelo clásico. Las razón fundamental está en la dificultad de dibujar los atributos ya que ocupan un excesivo espacio en el diagrama. Como además los analistas están acostumbrados a representar diagramas lógicos basados en el modelo relacional de bases de datos, se usan diagramas entidad relación en los que la representación de entidades y relaciones se hace de esta forma:
Ejemplo:
Ilustración 35. Representación clásica y más moderna del mismo diagrama Entidad/Relación
Ilustración 36. Representación clásica y equivalente moderno de una entidad débil
