Conozca el diagrama ER (Relación de entidad), sus partes y lo que suele fallar al crearlo.
¿Alguna vez ha creado un modelo de base de datos relacional? ¿O tal vez estás tratando de crear el primero? Usted sabe (o pronto lo descubrirá) que traducir los problemas del mundo real a la lógica de la base de datos a veces puede ser bastante difícil.
Una de las herramientas que podría ayudarte es el diagrama ER. La sabiduría común en el diseño de bases de datos sostiene que cuanto mejor sea su diagrama ER, más fácil será construir el modelo de la base de datos. Este elemento importante marca la pauta para todas las frustraciones o éxitos futuros. Con un buen diagrama ER, crear un modelo de base de datos relacional es bastante sencillo. Por supuesto, se pueden cometer errores en cualquier fase del modelado de la base de datos. Sin embargo, tener un buen diagrama ER puede ayudarte a evitar algunos de esos errores.
Entonces, veamos qué es el diagrama ER y cómo podemos evitar sus errores comunes.
¿Qué es un diagrama ER?
"Diagrama ER", o ERD, es la abreviatura de Diagrama de relación de entidad. Mapea el problema a modelar, pero de una manera estructurada que muestra las relaciones entre las entidades.
Los componentes básicos de un diagrama ER
Los diagramas ER constan de los siguientes elementos:
- Entidad
- Relaciones
- Atributos de entidad o relación
El primer elemento del diagrama ER es la entidad . La entidad es un objeto o una ocurrencia sobre la que queremos almacenar información. Básicamente, es cualquier cosa sobre la que podamos recopilar datos. Por ejemplo, podemos almacenar datos sobre empleados, estudiantes, profesores, compradores, productos, departamentos, pagos, ubicaciones, etc.
Una vez que tenemos entidades, es necesario crear relaciones . Una relación muestra cómo una entidad está conectada y asociada con una o más entidades.
El elemento final del diagrama ER es una entidad o relación atributo . Un atributo es una descripción de una propiedad que pertenece a una entidad o relación. Los atributos tienen valores. Algunos atributos para las entidades mencionadas anteriormente podrían ser:
- Empleado, estudiante, profesor, comprador – DNI, nombre, apellidos, fecha de nacimiento, domicilio, etc.
- Producto – ID, categoría, descripción, color, número de serie, etc.
- Departamento – ID, nombre del departamento, jefe de departamento, número de empleados, etc.
- Pagos – DNI, fecha y hora, importe.
- Ubicación – Ciudad, código postal, región, país, continente.
Tipos de relaciones
Antes de entrar en los errores habituales que se encuentran en los diagramas ER, es importante comprender los posibles tipos de relaciones. La mayoría de los errores de ERD son esencialmente relaciones mal definidas entre entidades.
Hay tres tipos de relaciones entre entidades:
- Uno a uno (1:1)
- Uno a muchos (1:N)
- Muchos a muchos (M:N)
Relaciones uno a uno (1:1)
El primer tipo de relación es uno a uno o 1:1 . En esta relación, una sola instancia de una entidad puede conectarse solo con una sola instancia de otra entidad (y viceversa, por supuesto).
Digamos que tenemos la entidad estudiante con los atributos nombre y apellido . También tenemos la entidad id con el único atributo id . La relación 1:1 significaría que un estudiante solo puede tener un número de identificación. También significa que un número de identificación puede pertenecer a un solo estudiante.
Esta relación se ve muy raramente en las bases de datos. Si solo se puede conectar una identificación con un solo estudiante, no hay necesidad de separarlos en dos entidades diferentes.
He aquí un ejemplo de esta relación:
Relaciones de uno a muchos (1:N)
El tipo más común de relación de base de datos es uno a muchos o 1:N . Una relación de uno a muchos significa que cada instancia individual de una entidad se puede conectar con varias instancias de otra entidad. También significa que cada instancia de la segunda entidad se puede asociar con solo una instancia de la primera entidad.
Por ejemplo, hay una entidad comprador con los atributos id , nombre y apellido . Queremos establecer una relación con la entidad pago que tiene los atributos id , fecha y valor . Esta es una relación 1:N porque un comprador puede hacer uno o varios pagos. Sin embargo, un pago no puede ser realizado por varios compradores; solo puede ser hecho por un comprador.
Aquí está el ejemplo:
Esta relación también se puede ver al revés. En esta situación, se llama muchos a uno o N:1 . Por supuesto, este no es un nuevo tipo de relación. Es lo mismo que 1:N, pero se mira desde la dirección opuesta.
Como ejemplo, supongamos que tenemos la entidad empleado con los atributos id , nombre y apellido . Queremos establecer empleado la relación de con la entidad departamento que tiene los atributos id y nombre . La relación entre estas dos entidades es N:1. Esto significa que cada empleado puede trabajar en un solo departamento, pero varios empleados pueden trabajar en el mismo departamento.
Relaciones de muchos a muchos (M:N)
A Muchos a muchos o M:N relación significa que cada instancia de la primera entidad se puede asociar con más de una instancia de la segunda entidad. También significa que cada instancia de la segunda entidad se puede asociar con múltiples instancias de la primera entidad.
Veamos cómo funciona esto entre las entidades estudiante y conferencia . Digamos que estudiante tiene los atributos id , nombre y apellido . La entidad conferencia tiene los atributos id y nombre . Una relación de muchos a muchos se puede interpretar de la siguiente manera:un estudiante puede asistir a una o más clases, mientras que una clase puede ser atendida por uno o más alumnos.
Aquí está el diagrama para este ejemplo:
En el modelado de bases de datos, tales relaciones generalmente se dividen en dos o más relaciones 1:N o N:1 mediante la introducción de nuevas entidades.
Errores típicos que se cometen al crear un diagrama ER
Muchos errores del diagrama ER encajan en una de estas cuatro categorías:
- Relaciones incorrectas entre entidades
- Usar una instancia de entidad en lugar de una entidad
- Confundir un atributo con una entidad
- Atributos complejos
Veamos cada uno individualmente.
Relaciones incorrectas entre entidades
Los errores más comunes ocurren al definir la relación entre entidades . Por lo general, no hay errores en una relación 1:1. Sin embargo, es muy fácil confundir una relación 1:N con una relación M:N. Esto generalmente se debe a no comprender los requisitos proporcionados por el usuario final. Es vital tener requisitos muy claramente definidos y una comprensión profunda de por qué se necesita la base de datos y cómo se utilizará. Si creamos un diagrama ER con datos insuficientes y una comprensión incompleta, lo más probable es que las relaciones entre las entidades se definan incorrectamente.
Veamos un ejemplo. Si está creando una base de datos para un banco, lo más probable es que cree un diagrama ER con la entidad cliente tener los atributos id , nombre y apellido . También tendrá una entidad llamada cuenta con los atributos id y escribir . Si no tienes experiencia en la industria bancaria, probablemente pensarás que siempre hay una relación 1:N entre el cliente y cuenta entidades, como se muestra a continuación.
Un cliente puede tener varias cuentas en un banco. Sin embargo, una cuenta puede ser propiedad de un solo cliente. ¿Es esto realmente cierto? Tal vez lo sea, tal vez no lo sea. Muchos bancos ofrecen cuentas conjuntas que pueden ser utilizadas por varios clientes. ¿Está creando un diagrama ER para un banco que ofrece dicho servicio? Si el banco no ofrece cuentas conjuntas, entonces tienes razón:la relación entre cliente y cuenta es 1:N. Sin embargo, si el banco ofrece cuentas conjuntas, entonces la relación es M:N.
Usar una instancia de entidad en lugar de una entidad
Otro error común es usar una instancia de entidad en lugar de una entidad. Una instancia de entidad es una aparición única de una determinada entidad, es decir, una entidad que en realidad podría ser un atributo de una categoría más grande.
Pongamos que trabajamos en una empresa que destina móviles y portátiles a determinados empleados. Entonces, en nuestra base de datos, tendríamos una entidad llamada laptop con los atributos id y modelo y una entidad llamada empleado con los atributos id , nombre y apellido , ¿derecho?
Aquí hay un problema:una computadora portátil en realidad no es una entidad; también hay que tener en cuenta los teléfonos móviles. La solución es reemplazar la entidad portátil con una entidad más general, como equipo . Esta entidad podría tener los atributos ID , escribir y modelo , Como se muestra abajo. El tipo podría consistir en valores como teléfono , ordenador , tableta y portátil . De esta forma, no hay necesidad de crear una entidad separada para cada tipo de equipo.
Puede encontrar el ejemplo aquí:
Confundir un atributo con una entidad
El siguiente error común es confundir un atributo con una entidad. Digamos que hemos decidido crear una entidad llamada empleado que constará de los atributos id , nombre , apellido , fecha_nacimiento , id_departamento , nombre_departamento y jefe_departamento . Esta entidad nos traerá problemas cuando estemos creando un modelo de base de datos porque consta de demasiados atributos que no definen de manera única a esta entidad en particular .
Recuerde, definimos entidades como cualquier cosa sobre la que podamos recopilar datos. Con eso en mente, podemos ver que el empleado actual la entidad se puede dividir en dos entidades:empleado y departamento , Como se muestra abajo.
Atributos complejos
El último error común del que hablaremos es incluir un atributo complejo en una entidad. En otras palabras, tenemos un atributo que en realidad debería ser su propia entidad .
Digamos que tenemos una entidad llamada estudiantes que está definido por los siguientes atributos:id , nombre , apellido , fecha_nacimiento , dirección y examen_aprobado . Toma, examen_aprobado es un atributo complejo que consta de más de una pieza de información, es decir, el ID y la fecha del examen y la calificación del estudiante. Dejarlo así sería un error. En su lugar, deberíamos crear una nueva entidad fuera de este complejo atributo . La nueva entidad podría llamarse exámenes y consta de los siguientes atributos:id , fecha , students_id y puntuación .
Puede encontrar el ejemplo aquí:
¿Recibió algún consejo útil sobre el diagrama ER?
Estos cuatro tipos de errores son los más comunes en el proceso de creación del diagrama ER. Por supuesto, no hay una lista completa de errores típicos o tipos de errores. En la vida real, es probable que ocurran muchos tipos de errores. La falta de planificación, el soporte técnico insuficiente y un proceso de diseño de base de datos apresurado contribuyen con sus propios problemas. Si alguna vez ha creado bases de datos o ha participado en ellas desde el punto de vista comercial, ¡probablemente haya experimentado algunas de ellas! Todas esas circunstancias conducen a varios errores, algunos de los cuales son bastante únicos.
¿Tienes tu propio ejemplo de un diagrama ER no tan bueno? ¿O tal vez hay otros errores que encuentras con frecuencia? Házmelo saber en la sección de comentarios.
