Aprendiendo el diseño de diagramas de relación de entidad

Hola Este artículo está dedicado a uno de los modelos de diseño más populares y familiares, ER ( Entity Relationship ), que fue propuesto por científicos en el campo de la informática: Peter Chen, en 1976.


En el curso del artículo, en un lenguaje simple, usando ejemplos simples de la vida, desarrollaremos diferentes versiones del diagrama que dependerán de su tipo de conexión. ¡Empecemos!

Diseño orientado a objetos

En primer lugar, me gustaría decir algunas palabras sobre OOP (Programación / Diseño Orientado a Objetos) para que no haya problemas con la comprensión del paradigma del diagrama en sí. Es más conveniente para mí abstraer este modelo con el principio de OOP, donde la esencia es el objeto, los atributos son sus características y las conexiones son un poco intermedias (en algunos casos, como método).

Inicio rápido

La principal ventaja del modelo de diseño Entity Relationship es que es universal. Puede diseñar una base de datos (Bases de datos), el funcionamiento de un programa, los principios de interacción, etc.

¿Qué necesitas saber al comienzo del estudio?

- Debe saber desde el principio que el trabajo principal se lleva a cabo en la relación de esencia y comunicación. Para una percepción más fácil, vale la pena recordar que la esencia es un sustantivo que está en un rectángulo, y la conexión es un verbo que está en un rombo. Aquí hay un ejemplo:



Creo que entiendes qué es qué. Nuestro programador enseña Python. Parece que todo es lógico. Pero aquí, solo, ¿cuáles son estas unidades en el ejemplo?

- Este es un indicador del tipo de conexión! En este ejemplo, el tipo de conexión es One-to-One:

$$

$$1: 1$$

Volveremos a los tipos de comunicación, pero un poco más tarde, y ahora necesitamos analizar otro PERO:
- El cuadro debe leerse en ambas direcciones. Si lees de izquierda a derecha, entonces todo es lógico, como se dijo anteriormente, pero si por el contrario ... pensaremos un par de veces más sobre qué es la lógica. De hecho, está escrito de esa manera y es correcto. Esta es solo una de algunas características de este modelo, que a veces puede ser confusa. Sin embargo, nada le impide, como muchos, en el lado de la unidad, agregar una flecha, como en el siguiente ejemplo:



PD: espero que estés interesado. Puede crear tales diagramas en el editor de diagramas - Dia.

Atributos

Entonces, tenemos un programador, pero no sabemos nada de él ... ¿Sin el cual un programador no es un programador?
- ¡Sin ningún atributo!

Complementemos nuestro ejemplo:



Sí, los atributos realmente no distinguen a nuestro programador de una persona común ... ¡pero en el futuro lo arreglaremos con nuevos atributos! En mi opinión, el atributo es COLUMNA (columna) en la tabla Base de datos.

Los atributos están vacíos.

Si no es necesario indicar un apellido en la tabla de su base de datos (entonces el atributo será opcional), entonces el atributo debe constar de dos óvalos: externo e interno (dentro del cual está el nombre del atributo).

Identificando atributos

Puede ver un guión bajo del nombre del atributo en el diagrama; esto es normal. No debes tener miedo de esto, tal vez sea solo un atributo de identificación. Es decir, es un atributo que siempre debe completarse, que es obligatorio (clave principal). Como ejemplo, la id conocida.

Bueno, ahora tenemos que darle al programador conocimiento (qué lenguajes, tecnologías conoce).
"¿Pero no enumeraremos inmediatamente con cada atributo separado los componentes de su conocimiento?"
Así es, ¡usaremos un atributo compuesto ( un atributo que consiste en atributos de componentes)! Quiero señalar que los componentes de atributo también pueden ser compuestos. La única pregunta es cómo lo implementará.

Tipos de comunicacion

Genial Pudimos resolver esto. ¡Ahora considere los tipos de comunicación restantes!

Continuemos con el tipo de conexión: uno a muchos:

$$

$$1: N$$

Déjame mostrarte un ejemplo:



Ahora nuestro programador también está estudiando Perl. No esta mal.
Sin embargo, quiero señalar que el ejemplo mencionado anteriormente es solo una excepción, para mostrar claramente cuál es la relación, porque puede haber mil ramas, lo que sería una tontería dibujar. En el futuro, volveremos a un registro abreviado y correcto, y vale la pena recordar este patrón frágil para que haya una idea general de qué es qué. Espero haber logrado explicarle lo que representa el tipo de conexión "Uno a muchos".
* La relación de una entidad a varias y viceversa *

Antes de continuar estudiando los tipos de enlaces, debe descubrir que los atributos también existen en los enlaces .
No lo mostraré como un ejemplo; tal vez, se pueda entender sin problemas, en palabras. Solo imagine que tiene una conexión de Transacción. Suponga que en su proyecto necesita guardar toda la información sobre las transacciones guardadas, ya sea que se guarde en un archivo o una base de datos, no importa. Necesita ahorrar tiempo, excepciones (errores que ocurrieron) y algo más. En nuestro caso, todos los anteriores son atributos que pertenecerán a la conexión. Dichos atributos también pueden ser compuestos, identificativos, opcionales. La pregunta es solo en la implementación. Vamos a continuar

El último tipo de conexión sigue siendo: De muchos a muchos:

$$

$$M: N$$

Como de costumbre, te mostraré con el ejemplo, pero no con el Programador, sino con el ejemplo de la relación del Espectador con la Película, en cualquier servicio para ver películas:



Hay dos cuestiones polémicas. Comencemos.

Primero:
- ¿Por qué la comunicación es más como una entidad?

Para simplificar la relación del tipo "Muchos a muchos", se utilizan entidades intermedias .

"¿Por qué no hay ramas?"

- El espectador puede suscribirse a muchas películas.
- Las películas pueden tener muchos espectadores que se suscriben a ellas.

Ahora, veamos otra forma de implementar la relación Much to Many, que será un poco más difícil de escribir, pero tal vez más comprensible para aquellos que no conocen las entidades intermedias:



Como habrás notado, en este ejemplo hay un tipo de conexión "Uno a muchos", e incluso varios.
Esto es cierto y fácil de explicar. El hecho es que el tipo de conexión "Muchos a muchos" es igual a dos comunicaciones "Uno a muchos".

$$

$$M: N = 1: N + N: 1$$

Probablemente le interese saber por qué nosotros, entre la conexión y la entidad, tenemos dos aristas.
Esto ya es un poco más difícil de explicar. Lee atentamente.
El hecho es que hay conexiones opcionales y obligatorias . Recuerda la identidad:

Las conexiones opcionales crean una participación parcial, mientras que las obligatorias crean una participación total.

- ¿Qué es la participación parcial y total?

La participación parcial también es una de las excepciones, algo similar a un atributo opcional, solo depende de la entidad. Imagina la foto. Hay dos entidades:
Comprador y Productos. Tipo de conexión: uno a muchos.
Tienen una conexión común: las compras. Pero necesitamos entender algo más. ¿Sin el cual el comprador no es el comprador?
- ¡Sin al menos una compra!
Este caso es un representante de una conexión parcial, porque damos la opción de "Comprar y convertirse en comprador o rechazar". En este caso, tendremos una ventaja entre el enlace "Compras" y la entidad "Productos". Ahora considere la plena participación.

La participación plena es el caso cuando no hay otra opción. Nuestro programador seguirá siendo un programador, incluso si no aprende nada, debido al hecho de que fijamos en el diagrama que debe aprender algo, y no puede haber excepciones. Arreglamos este negocio con dos aristas. El tipo de participación depende de cómo diseñe, si el muestreo es necesario en la etapa de comunicación.
Esto esta hecho. Continuamos

Recuerde el ejemplo "Uno a muchos", donde después del enlace "Enseña" había nombres de YP (Lenguajes de programación), lo que condujo a una gran cantidad de ramas, porque no era correcto en términos de escritura. Solo piense, porque no tenemos que hacer ramas para cada PL. Simplemente podemos crear una entidad "Lenguaje de programación", en el que colocamos los atributos que serán responsables de su nombre, edad, poder y mucho más. Creo que lo entiendes. Le aconsejo que use la entrada abreviada "Much to many".

Entidades débiles

Considere el concepto final.

Imagine que tiene una tabla "Principal" y "Secundario", respectivamente, las mismas entidades en el diagrama. ¿Puede uno existir sin el otro? Creo que no Tanto en biológico como en general lógico.

Esencia débil: no puede haber manzana sin un manzano

.

En este ejemplo, la entidad "Niño" es una entidad débil.

Las entidades débiles son aquellas entidades que no pueden existir sin otra entidad.

Creamos la entidad "Niño", con la esperanza de que los Padres / Padres no tengan hijos con el mismo nombre, de lo contrario, nuestra entidad, que puede ser una tabla en la base de datos, difícilmente puede llamarse Normalizada (una tabla en la que las reglas de Automatización de datos y hay un identificador de clave principal), porque no podemos distinguir trivialmente a los niños.

Sin embargo, tales casos ocurren, pero puede solucionarlo agregando un atributo adicional. En este caso, el atributo "Nombre" es lo que crea una situación similar, y se llama el componente clave de una entidad débil . El nombre de tales atributos, en óvalos, está subrayado con una línea punteada, y la esencia y la conexión se colocan en figuras adicionales en las que están compuestos.

Te presentaré esto como un ejemplo:

Conclusión

En conclusión, quiero decir que uno de los trabajos cooperativos competentes fundamentales es una buena explicación de las tareas, una buena presentación del producto que necesita ser desarrollado, lo que ayuda a diseñar modelos. Entity Relatioship es un modelo de diseño que ha sido popular durante décadas. Le permite crear gráficos elegantes que, con el enfoque correcto, se pueden complementar y modificar en el futuro. Tómese el tiempo para aprender. Gracias por su atencion!

Fuentes

- Libro "Autoría de MySQL" Autoría:
Seyed M.M. "Saied" Tahagghoghi, Hugh E. Williams
- en.wikipedia.org/wiki/Entity –relationship_model