Lección 16 - El modelo entidad-relación

Curso SQL para principiantes


El modelo entidad-relación es una herramienta para generar el modelo de datos que describe la estructura y relaciones de una BD. Estos modelos al mismo tiempo están describiendo una situación real, con elementos reales que se relacionan entre sí. Por ejemplo: La actividad de un almacén de fruta, o sin ir más lejos, la actividad de este mismo foro.
Obviamente no se está describiendo la actividad concreta de, por ejemplo, cargar un camión de fruta. Pero sí se está describiendo que en esta realidad(el almacén de fruta) hay una entidad llamada REPARTIDORES, que está relacionada con otro entidad llamada PEDIDOS, donde estos últimos serán adquiridos, y por tanto se relacionan, por otro entidad llamada CLIENTES, etc... Al igual que, en el caso de este foro, no se está describiendo como publicar un mensaje, pero sí que hay una entidad llamada MENSAJES, que se relaciona con otro entidad llamada USUARIOS, que a su vez se relacionan con otra entidad llamada VISITAS, etc...

El modelo entidad-relación es un diagrama que ayuda a generar la estructura de datos con la que gestionar un problema o actividad real. Una vez este modelo se ha convertido en una estructura dentro la BD, es decir, las tablas con sus claves primarias y foráneas, mediante SQL es posible tanto mantener el funcionamiento de la actividad alimentando la base de datos, como analizar los datos en beneficio de la actividad. Por ejemplo, en el caso del almacén de fruta, la estructura de datos debería permitir registrar pedidos de los clientes, pero también y en consecuencia, obtener las ventas por cliente en un periodo determinado. En el caso de este foro, la estructura de datos permite registrar nuevos usuarios, pero también conocer cuantos usuarios hay registrados hasta la fecha, o cuantos de ellos están online en un momento dado.

Este curso NO tiene el propósito directo de que usted aprenda a diseñar modelos entidad-relación. En este sentido la formación puede ayudar pero en cualquier caso, esto es algo que se adquiere con el tiempo, después de pelearse mucho diseñando modelos para actividades diversas, y equivocarse en su empeño una y otra vez. Diseñar un modelo de datos es sin lugar a dudas un ejercicio de alta creatividad, donde dependiendo de como interprete los requerimientos el analista, y su grado de imaginación, dará como fruto resultados distintos, pudiendo ser todos ellos válidos. En esencia se trata de plasmar una realidad en forma de entidades relacionadas entre sí que posteriormente será traducido a tablas dentro de una BD con sus claves primarias y foráneas.

Veamos por ejemplo el modelo entidad-relación simplificado (sin los atributos o campos de cada entidad) que describe la BD de la academia que se ha usado en las dos lecciones anteriores:



Observamos que existen tres entidades: CURSOS, PROFESORES y ALUMNOS, también se observa la cardinalidad de las relaciones mediante los indicadores a ambos lados de las mismas, junto a las entidades que se están relacionando. Para establecer la cardinalidad de relaciones debemos formularnos las preguntas que responden a dicha cuestión, por ejemplo, tomemos la relación CURSOS - PROFESORES y veamos como se establece la cardinalidad de dicha relación:

  • Un profesor puede impartir varios cursos. Lo que implica anotar una N en el lado de la entidad CURSOS de dicha relación.

  • Un curso es impartido por un solo profesor. Lo que implica anotar un UNO en el lado de la entidad PROFESORES de dicha relación.

Como ya se dijo con anterioridad este tipo de relación implica añadir una clave foránea de la tabla PROFESORES en la tabla CURSOS. Es decir, el campo ID_PROFE de la tabla CURSOS.

Tomemos ahora la relación CURSOS - ALUMNOS:

  • En un curso se matriculan varios alumnos. Lo que implica anotar una N en el lado de la entidad ALUMNOS de dicha relación.

  • Un alumno puede asistir a varios cursos. Lo que implica anotar una M en el lado de la entidad CURSOS de dicha relación.
Observese que se anota M porque la N ya se usa en el otro extremo de la relación, con esto se indica que es una relación de varios a varios pudiendo ser N y M de distinto valor para un curso y alumno dados.

Como ya se dijo con anterioridad este tipo de relación implica crear en la BD una tabla auxiliar llamada tabla de relación.

* * *

Entidades fuertes y débiles
Existen dos tipos de entidades, las fuertes, en ocasiones llamadas maestros, que de forma independiente identifican sus registros con un clave propia, y las débiles que dependen de una entidad fuerte para identificar sus registros, o si usted quiere, no tiene sentido su existencia sin una entidad fuerte donde apoyarse. Un ejemplo típico de entidad débil es la entidad LINEAS_FACTURA que depende del maestro de FACTURAS para identificar sus registros. La cardinalidad de esta relación es de 1 a N, puesto que una factura puede tener varias líneas mientras que una línea solo puede pertenercer a una factura. Pues bien, en la entidad débil LINEAS_FACTURA la clave primaria será compuesta y en ella formará parte el campo ID_FACTURA que a su vez será clave foránea de la tabla FACTURAS. El otro campo que formará la clave primaria será por ejemplo ID_LINEA, de modo que para identificar un registro de la entidad LINEAS_FACTURAS se necesita de la clave de su maestro o entidad fuerte además de ID_LNEA. Ejemplo: factura: 92054 linea: 3 identifica la linea 3 de la factura 92054. La cardinalidad de la relación de una entidad débil con su maestro o entidad fuerte siempre será de 1 a N. Las entidades débiles se representan en el diagrama entidad-relación con un doble rectángulo:



Lo cierto es que no afecta al funcionamiento de la gestión errar y hacer débil una entidad que en realidad es fuerte o viceversa. Sin embargo una vez adviertes que aquella parte esta mal construida, el evolucionarla o simplemente explotarla se hace más incomoda al acarrear claves compuestas cuando no deberían serlo, o el tener claves propias cuando en realidad deberían ser compuestas y estar sujetas a la entidad fuerte de la que dependen.

En ocasiones puede ser un verdadero dilema decidir en tiempo de diseño si una entidad es fuerte o débil. Si usted tiene dudas sobre que naturaleza aplicar a una entidad, puede serle de ayuda las siguientes premisas:

  • Si para la entidad que se estudia su naturaleza los registros pueden cambiar de padre en un futuro, con toda seguridad es una entidad fuerte.
  • Si la entidad padre de la entidad que se está estudiando su naturaleza simplemente agrupa registros siendo en ocasiones dudoso que padre asociarle a un registro hijo, o si usted quiere existen varios candidatos igual de válidos, probablemente se trate de una entidad fuerte.
  • Si para la entidad que se estudia su naturaleza no se esperan demasiados registros para un mismo padre, es decir, tendrá un número de registros relativamente pequeño para un padre dado, y aparte de su posible maestro no se relaciona con apenas con otras entidades, entonces probablemente se una entidad débil.
  • Si la entidad que se estudiando su naturaleza se relaciona con otras muchas entidades de modo que deberemos crear en todas ellas claves foráneas a la entidad que se está analizando, entonces aunque sea una entidad débil quizás sea conveniente valorar el identificar sus registros con una clave propia y hacerla fuerte. De otro modo deberemos acarrear la clave compuesta hacia todas estas entidades relacionadas para crear las claves foráneas.

* * *

El propósito de este curso no es profundizar con los modelos entidad-relación. Para acabar diremos que una vez se tiene desarrollado un modelo entidad-relación completo, no simplificado como se ha mostrado en esta lección, existe un procedimiento o protocolo para traducirlo en forma de tablas y relaciones en una base de datos. Por ejemplo, cada entidad será una tabla en la BD, las relaciones N - M obligarán a crear nuevas tablas que relacionarán las tablas que representan a cada entidad de la relación. Para las relaciones 1 - N se creará una clave foránea de la tabla de cardinalidad 1 en la tabla con cardinalidad N.

* * *

Resumen
El modelo entidad-relación es una herramienta en forma de diagrama que ayuda a generar la estructura de datos con la que gestionar un problema o actividad real, es decir las tablas con sus claves en una BD relacional.

Cuanto mayor sea el grado de conocimiento de la actividad a gestionar tanto mejor para desarrollar el modelo entidad-relación. Esta es un ejercicio creativo donde la teoría al respecto ayuda pero no enseña a desempeñarlo con soltura, solo se adquiere con la práctica y experiencia.

Una vez se tiene un modelo desarrollado la traducción a objetos de BD es directa aplicando una serie de pasos.

En un modelo entidad-relación encontraremos esencialmente relaciones de dos tipos: de 1 a N y, de N a M. También encontraremos dos tipos de entidades: fuertes y débiles. Una entidad débil necesitará la clave de la entidad fuerte para identificar sus registros. La cardinalidad de una relación de una entidad débil con su maestro o entidad fuerte siempre será de 1 a N.

* * *

Ejercicio
Modifique el modelo entidad-relacion presentado en esta lección para que considere la siguiente premisa: Todo alumno tendrá un profesor que lo tutele.




    Lección 15 - Reunión interna y externa (INNER / OUTER JOIN)
  • Lección 17 - Funciones

Creative Commons License Creative Commons License

Este curso está sujeto a la licencia Reconocimiento-NoComercial-SinObraDerivada 3.0 de Creative Commons. Usted puede copiarla, distribuirla y comunicarla públicamente siempre que especifique su autor y deletesql.com; no la utilice para fines comerciales; y no haga con ella obra derivada. Puede usted consultar la licencia completa aquí.




Volver a Curso SQL desde cero

¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 10 invitados