El modelo de datos entidad-relación , también llamado ER , es uno de los varios modelos de datos que puede usar para razonar sobre sus datos.
En particular, es un modelo de datos conceptuales , ya que no está vinculado a ninguna implementación en particular. Esa es una tarea que se le deja al modelo de datos lógicos.
El modelo de datos ER es tan general, de tan alto nivel, que puede ser implementado por una variedad de tipos de bases de datos completamente diferentes.
Es genial porque no piensas en los detalles de implementación, sino que solo piensas en tus datos y cómo están organizados. . Y mientras lo hace, se ve obligado a analizar el problema de maneras en las que no había pensado antes.
Considero que los diagramas ER son excelentes para ayudarlo a analizar un escenario donde hay datos involucrados.
El Modelo ER le brinda las herramientas para representar, utilizando una notación gráfica, todos los datos que necesita para modelar, las relaciones entre los diferentes tipos de datos y la información asociada con ellos.
Hay 2 elementos que componen un modelo ER:
- las entidades
- las relaciones
Las entidades son tipos de datos, como elementos o personas, que tienen propiedades comunes.
Las relaciones son las relaciones entre entidades.
Déjame darte un ejemplo, hablemos de libros y sus autores. Tenemos 2 entidades :
- libro
- autor
Un libro particular es una instancia de la entidad libro.
Como tenemos 2 entidades, tenemos 2 relaciones entre ellos. Uno es la relación entre un solo libro y la entidad del autor. Uno es la relación entre un solo autor y la entidad libros. Si lo pensamos bien, tenemos:
- un libro tiene un autor
- un autor puede escribir muchos libros diferentes
La notación visual para entidades
Dado este sencillo ejemplo, podemos comenzar a introducir la notación visual que nos ayudará a crear el modelo de datos ER de nuestro escenario.
Nota:Hay muchas maneras diferentes de dibujar diagramas ER. Usaré el que, en mi opinión , es más visual y tiene más sentido.
Las entidades se representan como rectángulos, con algo de texto para identificarlas:
La notación visual para relaciones
La relación entre entidades se representa, en su forma más básica, usando una línea que conecta dos relaciones y un diamante con algún texto para identificar el tipo de relación:
Tenga en cuenta que no creé 2 relaciones "el libro tiene autor" y "el autor escribió el libro". Hice una única relación “autor” entre un Libro y un Autor.
Cardinalidades
Una vez que tenemos una relación, ahora debemos indicar los números involucrados. Por el momento, tenemos muchas preguntas:
- ¿Cuántos autores puede tener un libro?
- ¿Puede un autor escribir varios libros?
- ¿Un autor necesita escribir al menos un libro para ser llamado autor?
- ¿Puede un libro ser escrito por varios autores?
- ¿Puede existir un libro sin al menos un autor?
Todas esas son buenas preguntas para hacer, y en este caso creo que las respuestas son bastante obvias. Y cuando la respuesta no sea obvia, puede pensar en el problema y agregar sus propias restricciones.
Hay varias formas de indicar visualmente las cardinalidades en un diagrama. Algunos prefieren cambiar la forma de la línea cuando se vincula a una entidad.
Prefiero los números, que aclaran las cosas:
Los números anteriores significan esto:un libro puede ser escrito por 1 o más autores. n significa cualquier número de elementos.
Y un autor puede haber escrito desde 0 libros (tal vez esté escribiendo uno ahora) hasta una cantidad infinita de libros.
La primera se denomina relación de cero a muchos . La segunda es una relación de uno a muchos .
También podemos tener:
- relaciones uno a uno
- relaciones de muchos a muchos
- relaciones de cero a uno
Atributos
Cada entidad puede tener uno o más atributos.
Digamos que usaremos la relación anterior en una librería. Cada autor tiene un nombre, una biografía, una URL del sitio web.
Cada libro tiene un título, una editorial, un año de publicación, un ISBN. El editor también podría ser una entidad, si queremos. Pero también podemos definirlo como un atributo de un libro.
Así es como podemos representar la información anterior:
Atributos del identificador
Las entidades deben identificarse mediante una clave única. La entidad del libro se puede identificar de forma única mediante el atributo ISBN. Cada libro tiene un solo ISBN (considerando que no representamos una sola copia de un libro, sino un "título" del libro).
Identificamos los atributos de la clave principal al subrayarlos:
El autor, por otro lado, no tiene un identificador único en este momento. Dos autores pueden tener el mismo nombre.
Por lo tanto, debemos agregar un atributo clave único. Por ejemplo, un id atributo:
Los atributos del identificador pueden abarcar múltiples atributos.
Por ejemplo, el ID del pasaporte y el país del autor identifican de forma única a la persona y podrían reemplazar el id atributo que agregamos:
¿Cuál elegir? Es una cuestión de qué tiene más sentido en su aplicación. Si estamos modelando una librería, no podemos esperar tener el país y la identificación del pasaporte de todos los autores de libros. Por lo tanto, usaremos un id aleatorio elegiremos y asociaremos con cada autor.
Atributos de relación
Los atributos no son exclusivos de las entidades. Las relaciones también pueden tener atributos.
Considere que necesitamos modelar una biblioteca. Además de las entidades de libro y autor, ahora presentamos la entidad de lector , una persona que toma prestado el libro para leerlo. Tomamos su nombre y número de cédula cuando lo toman prestado:
Pero aún nos falta información. Necesitamos saber cuándo la persona tomó prestado el libro y la fecha en que lo devolvió, para que podamos almacenar la información sobre toda la historia de un libro en particular en nuestra biblioteca. Esta información no pertenece ni al libro ni a las entidades lectoras; pertenece a la relación:
Entidades débiles
Hablamos sobre las claves principales anteriormente y cómo ayudan a identificar de forma única una entidad.
Algunas entidades dependen de otras entidades para su existencia y se denominan entidades débiles. .
Supongamos que necesitamos modelar pedidos para una tienda en línea.
Para cada pedido, almacenaremos la identificación del pedido, que comienza en 1 y aumenta con el tiempo, la fecha y la hora en que se realizó y la información sobre el cliente, para que sepamos a quién facturar y dónde enviarlo.
Entonces también necesitamos saber qué ordenaron. Creamos una entidad débil "artículo pedido", que representa cada artículo en el carrito en el momento del pago.
Esta entidad almacenará el precio del artículo en el momento del pago (por lo que cuando cambiemos el precio de los productos en oferta, no afectará a los pedidos ya realizados), la cantidad de artículos que se pidieron y las opciones elegidas. Digamos que vendemos camisetas, por lo tanto, necesitamos almacenar el color y el tamaño de la camiseta ordenada.
Es una entidad débil porque una entidad de artículo pedido no puede existir sin una entidad de pedido.
Relaciones recursivas
Una entidad puede tener una relación recursiva consigo misma. Supongamos que tenemos una entidad persona. Podemos modelar la relación padre-hijo de esta manera:
Una persona puede tener de 0 a n hijos, un hijo tiene 2 padres (considerando el escenario más simple).
Relaciones ISA
ISA significa IS-A, y es una forma de modelar generalizaciones en el modelo ER.
Lo usamos para agrupar entidades similares bajo un paraguas común. Por ejemplo, un autor y un lector, en el caso de los libros y el ejemplo de la biblioteca, se pueden generalizar utilizando una entidad de persona.
Ambos tienen un nombre, así que extraemos el nombre hasta la entidad persona, y solo gestionamos las peculiaridades de ser autor o lector en la entidad correspondiente:
Relaciones no binarias
No todas las relaciones son estrictamente binarias. Tomemos un escenario de lección.
Una lección tiene lugar en una sala de la escuela hoy a las 10:00, con un profesor, hablando a una clase sobre física.
Entonces, una lección se da en un momento particular del día, involucra un tema, un maestro, una clase y un salón.
Podemos modelarlo de esta manera:
