2. Modelado Conceptual - ZornStolz/MSI_Wiki GitHub Wiki

Proceso para realizar un modelo conceptual

Se tomara el siguiente ejemplo para seguir el proceso:

Una Entidad del estado desea tener una base de datos de los museos que tiene. Desean poder registrar cada museo con un código único, el nombre del museo y su dirección. De los museos desean saber quien es el gerente que administra los empleados, estos empleados tendrán un identificador único, nombre, cargo, teléfono y área de trabajo en el museo. También necesitan registrar cada obra y saber quien fue su autor, nombre de él y periodo en que vivió. De la obra guardaran nombre, antigüedad, fecha de adquisición, valuación y su seguro. A la entidad le interesa saber también cuales han sido donadas, quien las donó y su teléfono de contacto. Por último, quieren saber cuántas entradas al museo se venden con su costo.

Para empezar a realizar el modelo conceptual debemos entender a la perfección el enunciado que se nos entrega, después de haber comprendido en su totalidad, aplicamos los siguientes pasos:

El primer paso a seguir es identificar las entidades, para esto señalamos todos los sustantivos del texto, luego por cada sustantivo identifica si: a). El sustantivo representa a un conjunto de objetos cuya información deba guardarse en la base de datos. y b). El sustantivo representa un dato de otro sustantivo el cual se cataloga como (atributo o dominio).
El segundo paso, consta de identificar las relaciones, para esto debemos hacer la matriz de relaciones la cual nos permite cruzar todas las entidades entre sí, luego debemos buscar verbos que conecten esos sustantivos y colocarlos en la celda donde se cruza. Después de haber hecho estos dos pasos correctamente.
El tercer paso involucra realizar la primera versión del modelo con los datos obtenidos hasta el momento y miraremos que efectivamente nuestro modelo conceptual ya tiene una estructura definida para nuestro enunciado.
En el cuarto paso, dibujaremos las llaves primarias, las llaves primarias nos ayudaran a identificar que efectivamente es una entidad regular con la que se puede modelar el enunciado.
En el quinto paso, identificamos los atributos, para esto debemos ir a la lista de sustantivos y usar los que fueron señalados como datos, luego de esto, definir los atributos que no son muy precisos.
En el sexto paso, dibujaremos los atributos a cada entidad según corresponda.
En el séptimo paso, dibujaremos las cardinalidades, para ellos debemos basarnos en la matriz de relaciones, ya que de ahí encontraremos si tiene sentido o no.

Por ultimo, revisamos si se cumplen los requerimientos de información y estos serían las fases de un modelo conceptual. El siguiete modelo sería fruto del seguimiento de los pasos enumerados anteriormente.

Modelo Entidad Relación MER

Modelo planteado por Chen. Este tipo de modelos nos permite darles sentido e interpretación a nuestros datos, podemos diseñar y modelar bajo convenciones generales la estructura de nuestra base de datos para que cualquier persona que conozca las convenciones pueda entender el modelo de la base de datos. Este modelo ofrece las siguientes pautas:

Entidades

Las entidades aquí se modelan usando un rectángulo. El estándar nos indica que el nombre de la entidad debe escribirse en singular y con la primera letra en mayúscula. Tomando el ejemplo anterior:

Así se ve la entidad empleado.

También están las entidades débiles quienes se grafican con un rectángulo encerrado por otro rectángulo. Salvo esa única diferencia sigue las mismas reglas de diseño de una entidad normal.

Si suponemos que se guarda por el seguro y beneficios del nucleo familiar del trabajador, esa entidad Miembro Familiar de un empleado sería una entidad débil que se ve así.

Atributos

los atributos se modelan usando un rectángulo con esquinas redondeadas, en minúscula y singular. Estos se conectan a su respectiva entidad por medio de una linea continua.

Así se ve el atributo nombre de museo.

No podemos olvidar que la clave primaria se modela como un atributo, las condiciones son las mismas que las anteriores. Ahora se agrega un detalle más, el nombre ira subrayado. El identificador único podría no tener el prefijo Id, pero se considera buena práctica agregar este prefijo. Cabe destacar que el uso del prefijo puede ser variado, es decir, id..., ID..., Id..., ID_..., etc. En este caso preferimos usar IdObra, con Obra la primera en mayúscula.

Así se ve el atributo IdObra de museo.

Relaciones

Estas como sabemos tienen variedad debido a su cardinalidad y por el número de entidades que relacionan. A continuación, unos ejemplos de cómo se diagramaría en MER estas relaciones, algunos serán tomados del ejemplo anteriormente tratado otros serán casos hipotéticos para representar la relación. Las relaciones se leen e interpretan partiendo del singlar de una entidad hacia la otra entidad teniendo en cuenta las características de llegada.

Relación 1 a 1

Si suponemos que cada obra solo tiene un único artista. Un artista tiene una sola obra en el museo. La relación se vería así. Lo que indica la relación es el rombo con líneas continuas que van del rombo a las entidades involucradas.

Relación 1 a N

Muestra la relación de un museo que vende muchas entradas. La entrada es vendida por un museo. La letra N es la notación que indica muchos.

Relación N a M

La relación muchos a muchos.

Supongamos que una obra puede ser realizada por varios artistas en colaborativo. Un artista tiene varias obras.

Relación opcional

La obra puede o no tener un donador asociado a ella, como observamos se utiliza un círculo en medio de la línea que los conecta, esto indica la opcionalidad de la entidad. Un donador tendrá asociada las obras donadas por el.

Relación recursiva

Un empleado gerente tiene varios empleados que administrar. Un empleado es administrado por un gerente. la salida de la relación vuelve a la entidad origen, aquí se ve el uso de roles que por buenas prácticas también debería de estar para poder distinguir mejor el sentido y lo que modela la relación.

Relación con múltiples entidades

Hasta esta última todas las relaciones han sido binarias, la relación solo implica dos entidades. Hay relaciones que usan más de dos entidades en este ejemplo es una terciaria por que la relación tiene involucradas tres entidades. Estas pueden tener también varias cardinalidades, en este ejemplo es uno a uno.

Un empleado registra en un museo la venta de una entrada. Una entrada vendida por un empleado es registrada en un museo. El museo registra la venta de una entrada y que empleado la vendió.

Notación Pata De Gallina

En esta notación podemos encontrar significantes diferencias respecto al Modelo planteado por Chen. Aquí mostraremos ejemplos parecidos los anteriores para destacar las diferencias.

Entidades

Las entidades son un cuadrado también, el estándar de nombrado de Chen aplica igual aquí.

Entidad Museo, sin diferencia con el modelo de Chen.

Entidad débil, esta cambia respecto a Chen. Aquí por ser entidad se representará igualmente con un cuadrado.

Es un rectángulo normal, sin el recuadro que tenía Chen.

Atributos

Los atributos se escriben todos dentro del cuadrado de su entidad en minúscula. El identificador único tiene un # que precede al nombre de la clave. Los atributos tienen unos círculos que indican si es obligatorio o no el registro de ese dato cuando se crea un nuevo registro.

Aquí hay una gran diferencia, en este modelo los atributos están encerrados dentro del cuadrado de su entidad. En Chen los atributos estaban en recuadros individuales conectados por líneas continuas a su entidad.

Claro eso afecta a las entidades débiles, también tendrán sus atributos adentro. Como sabemos no encontraremos # antes de un atributo aquí.

Relaciones

En este apartado veremos la razón por la cual es llamada pata de gallina.

Relación 1 a 1

La relación uno a uno se denota por una línea continua entre las entidades involucradas.

El ejemplo del modelo anterior una obra un autor

Relación 1 a N

El muchos es representado aquí con tres líneas que salen de uno de los extremos de la relación a la entidad de la que habría muchos. Como observaremos esta línea ya no es continua, en el modelo pata de gallina se pone una regla que hace que en la entidad que es única sea opcional para la entidad muchos. En consecuencia, podemos observar que la opcionalidad en pata de gallina es denotada por una línea discontinua.

Aquí podemos evidenciar la diferencia con el modelo MER. No solo se diferencia por la forma en la que se gráfica, este modelo agrega reglas a las relaciones. a partir de ahora donde quiera haya un muchos se vera la opcionalidad.

Un museo vende muchas entradas, una entrada puede o no ser vendida por el museo.

Relación N a N

Aquí no es muy relevante de qué lado está la opcionalidad.

Como vemos ambos lados de las línea terminan con las tres líneas, simulando la pata de una gallina. De hecho, en el lado de la opcional solo hay dos líneas.

Relación Recursiva

Aquí no aparece el rol, pero se podría colocar para agregar claridad. Una línea continua que sale y llega a la misma entidad.

Como la relación es uno a muchos es el mismo tipo de línea.

Relación múltiple

Por las características de las líneas que expresan las relaciones, en esta notación notaremos un gran cambio. Se usa una entidad con el nombre de nuestra relación, en principio sin atributos, si los tiene se agregarían. Todas las líneas de relación saldrían de las entidades involucradas y llegaron a la entidad que modela la unión de todas las relaciones.

Así se vería una ternaria. si fuese más entidades se colocarían igual. En este caso todas las puntas son uno a uno.

A continuación, tenemos el modelo conceptual anteriormente formulado en notación pata de gallina. Se agrego la entidad débil Miembro familiar, esta se usará en los demás ejemplos.

Como pudimos observar esta notación nos ofrece más detalles y simplicidad en el número de elementos a graficar. Una principal ventaja de usar este modelo es que este tipo de modelamiento esta implementado con la sintaxis descrita anteriormente en herramientas de desarrollo de modelos de bases de datos.