Transformación del esquema E/R al esquema relacional

La estructura básica de un modelo de base de datos relacional es la relación, su representación consiste en una tabla con un conjunto de filas y columnas en el que las columnas son los atributos y las filas (tuplas) son las ocurrencias de la relación.

Además hay otro concepto importante llamado clave candidata de una relación que se define como el conjunto de atributos (columnas) que definen univoca y mínimamente cada fila (tupla).

En una relación pueden existir varias claves candidatas, por ejemplo, en la relación:

Medicos (Código, DNI, Nombre, Dirección, Teléfono, Sueldo, Comisión, …etc)

Se pueden elegir como claves candidatas, el Código, o el DNI, si una de ellas se elige como clave primaria, por ejemplo DNI, entonces el resto (es esta caso el código) serán las claves alternativas.

Ningún atributo que forme parte de la clave primaria de una relación puede tomar valor nulo, esto se llama “integridad de entidad”.

Otro tipo de clave, la clave ajena, consiste en un conjunto de valores que coincidirán con los valores de la clave primaria de otra relación (o de ella misma). Por ejemplo en la Figura 1. Se señalan las claves ajenas que representa la relación Medicos.

Para las claves ajenas existe la regla de “integridad referencial“, que establece que los valores de la clave ajena, deben coincidir con los de la clave primaria a la que referencian o son nulos.

Es decir, para cada clave ajena se debe especificar si esta puede o no tomar valores nulos, lo que determinará las consecuencias de determinadas operaciones como modificación y borrado que  se realicen sobre tuplas de la relación  a la que se referencia. En función del tipo de operación que vayamos a implementar tenemos las siguientes opciones:

Operación Restringida (Restrict): Si deseamos borrar o modificar n  tuplas  de la relación que contiene la clave primaria sólo se permitirá la operación si no existen tuplas con la clave en la relación que contiene la clave ajena. Es decir, para borrar una Especialidad (Fig, 1) no debe haber ningún Médico que esté trabajando en dicha Especilaidad, si no, el sistema debe impedir el borrado.

Operación con transmisión en Cascada (Cascade): Si queremos borrar o modificar n tuplas de la relación que contiene la clave primaria referenciada entonces se producirá el borrado o modificación en cascada de las tuplas de la relación que contiene la clave ajena. En otras palabras, en el ejemplo la relación Especialidad, se debe modificar también el código en todos los Médicos de la base de datos que trabajen en dicha Especialidad.

Operación con puesta  a nulos (Set Null): Si queremos borrar o modificar n tuplas de la relación que contiene la clave primaria referenciada, tenemos que poner a Nulo los valores de las claves ajenas de la relación que referencia.

Por ejemplo, al borrar una Especialidad, los Médicos que trabajan en la Especialidad eliminada y que además se encuentran en la relación Médicos, se les debe colocar el atributo Cod_Esp a Nulo. Esta opción sólo es posible si el atributo que es clave ajena permite tomar valores nulos.

Operación con puesta a valor por defecto (Set Default): Si queremos borrar o modificar n tuplas de la relación que contiene la clave primaria referenciada, es necesario poner el valor por defecto a la clave ajena de la relación de referencia.

Operación que desencadena un procedimiento de usuario: En este caso, el borrado o modificación de tuplas de la tabla referenciada pone en marcha un procedimiento definido por el usuario.

Reglas de transformación

Para convertir un diagrama en el modelo E/R al relacional tenemos que seguir los siguientes principios:

- Toda entidad se convierte en una relación.

Tomando como ejemplo el siguiente esquema tendríamos:

- Toda interrelación N:M se transforma en una relación. Y se propaga la clave de cada entidad a la que apunta. La clave primaria serán las dos claves primarias de las entidades que se asocian.

- Las relaciones de tipo 1:N hay que convertirlas con “propagación de clave”. La clave primaria de la entidad con cardinalidad 1 pasa a la tabla de la entidad cuya cardinalidad es N   (La entidad  a la que apunta la flecha en el esquema E/R).

Si las relaciones de cardinalidades máximas son distintas de 1 o n la regla para convertirla consiste en propagar tantas veces la clave de una entidad como cardinalidad haya en la otra entidad.

Esta  regla es útil si la cardinalidad es un número pequeño, o si  la cardinalidad máxima y la mínima son iguales, y garantiza evitar los valores nulos.

Para la relación Medico-Medico:

Para la interrelación pertenece de Medico-Especialidad:

Si las relaciones son del tipo 1:1, es un caso particular de una N:M o de una 1:N, pero no hay reglas fijas para la transformación de este tipo de relación. Se  fusionan en una sola entidad, se pueden incluir en el esquema relacional de diversas formas dependiendo de las cardinalidades de las entidades que participan en la misma. Los criterios para aplicar una u otra regla dependen de las cardinalidades mínimas, tratando de mantener la mayor cantidad de semántica posible y evitar los valores nulos.

- Para relaciones que asocian entidades con cardinalidades (0,1), la relación 1:1 se transforma en una relación, además de las dos relaciones que representan cada una de las entidades. Por ejemplo, si tenemos la asociación Matrimonio entre las entidades Hombre y Mujer, que se transforma en una relación, evitando así los valores nulos que aparecerían en caso de propagar la clave de la entidad Mujer a la tabla Hombre o viceversa, ya que como muestran las cardinalidades ni todos los hombres ni todas las mujeres se encuentran casados.

-Si una de las entidades de la relación tiene cardinalidades (0,1), y en la otra la cardinalidad es (1,1), conviene propagar la clave de la entidad con cardinalidades (1,1) a la tabla resultante de la entidad de cardinalidades (0,1). En la figura 2, tenemos una relación que contiene el médico que es responsable de una especialidad, suponiendo que un médico pueda ser como máximo de una especialidad y que cada especialidad debe tener un responsable –pero sólo uno -. En este caso propagamos la clave de Medico a la tabla de Especialidad, de este modo evitamos valores nulos, y captando más semántica – recogemos la cardinalidad mínima 1, que en caso de proceder con la propagación en sentido contrario no podríamos captar directamente-.

Como esto ya se ha hecho por la relación 1:N Pertenece, no hay cambios en el modelo.

 -En el caso de que ambas entidades tengan cardinalidades (1,1), podemos propagar la clave de cualquiera de ellas a la tabla resultante de la otra, pero hay que determinar si  los  accesos serán frecuentes o prioritarios a los datos de las tablas, si es así conviene propagar las dos claves. Sin embargo, esto introduce redundancias que deben ser controladas por medio de restricciones.

En resumen: en las relaciones 1:1 existen tres posibilidades: Si la cardinalidad es (0,1) en ambas entidades, se crea tabla. Mientras que si la cardinalidad de una es (0,1) y de la otra es (1,1) se suele pasar la clave primaria de (1,1) a la de (0,1). Si la cardinalidad de ambas es (1,1) se pasa la clave de cualquiera de ellas a la otra. 

Para la interrelación responsable Medico-Especialidad

Las dependencias en existencia y en identificación no pertenecen al modelo relacional. En el ejemplo de la figura 2 vemos la manera de transformar  una dependencia en existencia  propagando la clave, para ello creamos una clave ajena, con nulos no permitidos, en la relación de la entidad dependiente, y tiene como característica la de obligar a una modificación y un borrado en cascada. Además si la dependencia es en identificación, la clave primaria de la relación de la entidad débil tiene que estar formada por la concatenación de las claves de las dos entidades participantes en la relación.

En cuanto a los tipos y subtipos, no son objetos que se puedan representar explícitamente en el modelo relacional estándar. Si tenemos una Entidad y sus subtipos son posibles varias soluciones de transformación en el modelo relacional, pero hay que tener en cuenta la subsiguiente pérdida de semántica dependiendo de la estrategia elegida.

Tenemos varias opciones:

Opción a: Englobar todos los atributos de entidad y sus subtipos en una sola relación, En general, adoptaremos esta solución cuando los subtipos se diferencien en muy pocos atributos y las relaciones que los asocian con el resto de entidades del esquema sean las mismas para todos los subtipos.

Por ejemplo podemos considerar mínima la diferencia entre un investigador y un traumatólogo desde el punto de vista de ser médicos de un hospital (figura 3). Debido a esto, la mejor solución para este caso sería la creación de una sola tabla que contenga todos los atributos del supertipo y de los subtipos, añadiendo un atributo adicional que le indique el tipo de médico que realiza –el atributo discriminante de la jerarquía-. Por otra parte se tendrán que especificar las restricciones semánticas correspondientes que obliguen a que los médicos que sean investigadores no puedan tener consulta (Que Consulta sea nulo).

Opción b: Crear una relación para el supertipo y tantas relaciones como subtipos haya, con sus atributos correspondientes. Ésta es la solución adecuada cuando existen muchos atributos distintos entre los subtipos, se quieren mantener de todas maneras los atributos comunes a todos ellos en una relación. Igual que en la opción anterior, habrá que crear las restricciones  oportunas.

Opción c: Considerar relaciones distintas para cada subtipo que contengan además atributos comunes. Elegiremos esta opción cuando se den las mismas condiciones que en el caso anterior (muchos atributos distintos) y los accesos realizados sobre los datos de los distintos subtipos afecten casi siempre a atributos comunes.

Podemos elegir una estrategia u otra dependiendo de si es la semántica o la eficiencia la que prima para el diseñador en un momento determinado.

Ejemplo sencillo

Continuando con el ejemplo sencillo, el esquema E/R obtenido en el post anterior: El modelo E/R y el diagrama de estructura de datos era el siguiente:

Ahora lo pasaremos a un modelo relacional, teniendo en cuenta que teníamos pendiente una posible redundancia en una interrelación.

Paso1. Convertimos las entidades en relaciones:

Hospital (strId_HOS, Nombre, Direccion, Telefono)

Médico (strId_MED, Nombre, Especialidad)

Paciente (strId_PAC, Nombre, Direccion, Fecha Nac)

Sala (Nº de Camas, strId_SAL)

Paso 2. Convertimos las interrelaciones N:M

Paso 3. Convertimos las relaciones 1:N

Propagamos las claves

Paso 4. Consideramos el caso Especial 1:5 como si fuera un 1:N por lo que tenemos

O considerando la regla 1:N cuando N es pequeño (en este caso 5) podríamos hacer

Sala (strId_SAL, Nº de Camas, strId_HOS, strId_PAC1, strId_PAC2, strId_PAC3 strId_PAC4, strId_PAC5)

En este caso concreto lo desestimaremos por dos motivos:

1º Por que debería ser variable entre 1 y 5 dependiendo del valor Nº de Camas

2º Por evitar dejar los campos a nulos

Finalmente la posible interrelación redundante no se elimina pues  solamente añade un campo al paciente con el cual podemos identificar en que sala se encuentra.

El modelo de Base de Datos quedaría del siguiente modo.

Análisis orientado a objetos (AOO) III. Caso práctivo de modelado CRC

Se trata de modelar un sistema de biblioteca con los siguientes requisitos:

Crear una aplicación para gestionar una biblioteca, la aplicación incluirá las búsquedas y préstamo de material bibliográfico, libros, revistas, documentos, etc.

Los socios podrán consultar el material bibliográfico.

Cada socio puede tener prestado un número máximo de elementos, 2 libros, 3 revistas y 4 documentos y cada tipo de material tiene un periodo de préstamo diferente. Libros 15 días, revistas 7 días, Documentos tres días.

Si se devuelve un elemento después de su fecha habrá una multa que también dependerá del tipo de objeto y de los días de demora.

Resolución

En nuestra búsqueda identificamos los nombres (Objetos) y los verbos (Responsabilidades)

Podemos crear la tarjeta CSocio que contendrá los datos del socio (nombre, dirección, teléfono, etc) con las responsabilidades de saber que elementos tiene prestados y por cuanto tiempo.

También parece obvia la tarjeta CMaterial que contendrá los datos del material (ISBN, Título, autor, etc ) y las responsabilidades de conocer las fechas de préstamo y devolución y la multa en caso de demora. Como estas responsabilidades dependerán del tipo de material se puede crear la tarjeta CLibro, CRevista y CDocumento como tarjetas hijas de CMaterial. Finalmente se puede crear un tarjeta que englobe todo CBiblioteca que tenga por funciones prestar y recibir material, visualizarlo, saber si está prestado o no.

El primer diagrama CRC podría ser de este estilo:

                      

La clase CBiblioteca se conecta a la Base de Datos (esto puede requerir otra clase) para obtener y actualizar información relativa al material y a los préstamos. Dicha clase colabora con CSocio para obtener el material que presta o desea consultar el socio y con CMaterial para obtener la información relativa a este.

La clase CSocio contiene los datos del socio, del material que tiene prestado y las multas que se han aplicado al socio.

La clase CMaterial tiene información relativa a las fechas que presta el material y calcula las multas, de ella derivan tres clases específicas CLibro, CRevista y CDocumento que tienen la responsabilidad de calcular la multa correspondiente. Dicho cálculo es específico para cada tipo de material (polimorfismo), el resto de datos comunes se almacenan en la clase base CMaterial. Siguiendo estas tarjetas se valida y mejora el sistema de clases, creando nuevas clases responsabilidades y colaboraciones hasta llegar al diseño definitivo.

El modelo E/R y el diagrama de estructura de datos

El modelo E/R (Entidad/Relación)  se puede ver como una vista unificada de los datos, y adopta una organización más lógica de los datos consistente en Entidades y sus Relaciones.

Elementos del modelo E/R

El modelo de datos se compone de tres tipos de información relacionadas: el objeto de datos o Entidad, los atributos que describen la entidad y la relación que conecta las entidades entre sí.

Entidad

Una Entidad  es una representación de cualquier información que es procesada por el software.

Una entidad puede ser cualquier cosa que produce o consume información, una cosa (por  ejemplo, un informe o un teclado), un suceso (por ejemplo, una alarma), una unidad de la organización (por ejemplo, departamento de compras), o una estructura (por ejemplo, un archivo), una ocurrencia (por ejemplo, una salida del almacén), un puesto (por ejemplo, un operador de máquina).

Una persona, por ejemplo un paciente de un hospital se puede ver como una Entidad en el sentido en que se puede definir según un conjunto de atributos. La descripción de la entidad incorpora a la entidad todos sus atributos. (Nombre, DNI, domicilio, etc.)

Las entidades se relacionan con otras. Por ejemplo, un paciente puede tener una habitación, donde la relación tener implica una «conexión» específica entre paciente y habitación. Las relaciones siempre se definen por el contexto del problema que se está analizando.

Existen dos clases de entidades: regulares que son las que tienen una existencia por sí mismas, por ejemplo, Paciente, Hospital; y las débiles, en las que su existencia depende de otra entidad, por ejemplo, Familiar depende de Paciente, y la desaparición de los datos de un paciente de la BD lleva consigo el que desaparezcan también los datos de todos los familiares que estaban asociados al paciente.

En los esquemas se toma la convención de que las entidades regulares se representan mediante un rectángulo, mientras que para las débiles se utilizan dos rectángulos concéntricos.

Relación

Se denomina relación a la asociación entre entidades, y se representa mediante un rombo.

Las entidades se pueden conectar entre sí de muchas formas diferentes.  Por ejemplo dos entidades Tornillo y Almacén. Se establece una conexión entre tornillo y almacén porque los dos objetos se relacionan.  En función del contexto del software que se va construir. Podemos definir un conjunto de parejas entidad-relación que definen las relaciones relevantes. Por ejemplo:

Un almacén pide tornillos

Un almacén almacena tornillos

Un almacén vende tornillos

Un almacén devuelve tornillos

En la definición de relación existen los siguientes elementos:

Nombre: como cualquier objeto del modelo E/R, cada tipo de relación tiene un nombre que lo distingue unívocamente del resto y mediante el cual se referencia.

Grado: es el número de entidades que participan en una relación. Si una relación asocia dos tipos de entidad distintas (grado 2), como en el caso de la relación “Pertenece” entre Médico  y Especialidad. En el caso de que asocie sólo un tipo de entidad , se trata de una relación de grado 1 o reflexiva, esto sucede cuando por ejemplo si un médico es director de un departamento tenemos “director de” en la entidad Médico que al mismo tiempo uno de los médicos es director del resto.

Si encontramos una relación de grado n hay que tender a subdividirla en parejas de relaciones de grado 2 aunque dependiendo de la semántica del enunciado esto no siempre será posible y se deberá establecer una relación de grado 3, 4 o n.

Cardinales de las entidades: la cardinalidad se define como: El número máximo y mínimo de ocurrencias de un tipo de entidad que se pueden  relacionar con una ocurrencia del otro, u otros tipos de entidad que también participan en el tipo de relación.

Se representan gráficamente por una etiqueta del tipo (0,1), (1,1), (0,n) o (1,n) según corresponda. Por ejemplo, si a una especialidad pertenecen de 0 a n médicos, en la entidad Médico tendremos las cardinalidades (0,n); en otro sentido, también podemos suponer que un médico tiene que pertenecer obligatoriamente a una especialidad y como mucho a una (si no permitimos médicos con dos o más especialidades), por lo que las cardinalidades de Especialidad serán (1,1). Fig. 1

Si eliminamos la restricción y permitimos un médico con más de una especialidad en vez de (1,1) tendremos (1,n).

Tipo de correspondencia: es el número máximo de ocurrencias de cada tipo de entidad que pueden intervenir en una ocurrencia de relación que se está tratando. Se representa gráficamente como una etiqueta con 1:1, 1,N o N:M, según corresponda.

Si la correspondencia es N se dibuja una flecha hacia la entidad que tiene las N ocurrencias (Fig, 2), si es del tipo M:N se dibuja una flecha hacia cada entidad.(Fig. 3) 

Como se vio con las entidades, pueden ser regulares o débiles, en el caso de las relaciones si relacionan a dos entidades regulares será también regular, si una de las dos es débil, la relación también será débil. Dentro de las relaciones débiles aparece el concepto de Existencia cuando las ocurrencias de la entidad débil no pueden existir si desaparece la entidad regular de la que dependen.

Puede darse otro caso en el que una relación débil como la comentada anteriormente, no se puedan identificar las ocurrencias de la entidad débil de forma única a través de sus atributos propios lo cual obliga a añadir una clave perteneciente a la entidad regular (por ejemplo, si para identificar los ejemplares de un medicamento del almacén, utilizamos el código del producto y un contador, AAA01, AAA02 etc.) en ese caso lo llamamos dependencia de Identificación.

Una dependencia en la identificación es siempre una dependencia en existencia (pero no ocurre lo contrario).

Si la dependencia es en identificación, el rombo que representa la relación va etiquetado con “ID”, y con una “E” en caso de que la dependencia sea en existencia. Los datos sobre de los familiares de un paciente ingresado en un hospital sólo tienen sentido si dicho paciente permanece en la base de datos, aparece pues una dependencia en existencia.

Si las relaciones son exclusivas, se representa mediante un arco; como por ejemplo en la figura 3, en la cual se supone que si un médico es responsable de una especialidad no puede trabajar en otra especialidad.

Atributo

Cada propiedad o característica que tiene un tipo de entidad o un tipo de relación se llama Atributo. Los atributos toman los valores de un rango. Un atributo se representa gráficamente como un círculo u óvalo con su nombre.

Los atributos definen las propiedades de una entidad y se pueden usar para:

Nombrar una ocurrencia de la entidad

Describir la  ocurrencia,

Hacer referencias a otra ocurrencia en otra tabla.

Entre todos los atributos de una entidad hay que elegir uno o varios que identifiquen de forma unívoca cada una de las ocurrencias de dicha entidad. Este atributo o conjunto de atributos se llaman Atributo Identificador Principal (AIP), y lo representaremos por un círculo relleno.

Igual que las entidades, las relaciones también pueden tener atributos. Por ejemplo, la relación n:m Trabaja entre las entidades Médico y Odontología, tiene el atributo Función que especifica la función que tiene un médico en odontología, por ejemplo, ayudante. Fig, 4.

Generalización

Una necesidad habitual al modelar Bases de Datos es la descomposición de tipos de entidad en varios subtipos; en efecto, en el mundo real se identifican varias “jerarquías” de entidades. La relación que se establece entre un supertipo y sus subtipos corresponde a la noción de “Es-Un” (conocida por su s siglas inglesas “Is-a”) o más exactamente, “Es-un-tipo-de”.

Se representa utilizando un triángulo invertido, con la base paralela al rectángulo que representa el supertipo y se conecta a los subtipos como se muestra en la figura 5.  Las características de esta relación son las siguientes: cualquier ocurrencia de un subtipo es una ocurrencia del supertipo, aunque no sucede lo contrario, con lo que las cardinalidades serán siempre (1,1) en el supertipo y (0,1) o (1,1) en los subtipos.

Esta clase de relaciones tiene otra característica muy importante, es la herencia, pues todo atributo del supertipo pasa a ser un atributo de los subtipos; así, por ejemplo, se puede establecer una asociación de este tipo entre la entidad Médico y las entidades Investigador y Traumatólogo, en el sentido de que los investigadores y los traumatólogos “son” o “son tipos de” médicos, y, por tanto, heredarán todas las características de la entidad Médico (Código de personal, nombre, dirección, sueldo, etc.).

En las abstracciones de este tipo los atributos comunes a todos los subtipos (incluidos los identificadores) se asignan al supertipo, por otra parte los atributos específicos se deben asociar al subtipo que le corresponda. Además, las relaciones que afectan a todos los subtipos se asocian al supertipo, se asocian a los subtipos las relaciones específicas en las que participa el correspondiente subtipo –pero sólo dicho subtipo-; por ejemplo, en la figura 5 se considera que sólo los Traumatólogos están asociados a la entidad Paciente.

Fig. 5.

Construcción de un esquema E/R

Se comienza por analizar la realidad  de lo que se desea plasmar en la base de datos, se analizan listados, pantallas, normativas, etc. 

Después se realiza un esquema, expresado en lenguaje natural, que nos facilite la creación de un esquema conceptual, por tanto es necesario “interpretar” las frases en el lenguaje natural en el que se ha descrito el esquema, luego las convertimos en elementos del modelo E/R, como pueden ser las entidades, atributos y las relaciones.

No existen reglas exactas que nos digan qué elemento va a ser una entidad o cual una relación, pero sí se pueden marcar unas normas generales y con un poco de buen criterio de diseñador, se puede elaborar un primer esquema conceptual:

           

-Un sustantivo (nombre común) que actúa como sujeto o complemento directo de una frase es, en general, una entidad, aunque también puede ser un atributo. Por ejemplo, en la frase “Los médicos atienden a pacientes”, existen dos posibles entidades: Médico y Paciente.

-Los nombres propios nos indican las ocurrencias de un tipo de entidad, Por ejemplo, “Félix” indica una ocurrencia de Paciente.

-Un verbo es una relación, en la frase anterior “atender” indica una relación entre las dos entidades, Médico y Paciente.

-Una preposición o una frase preposicional entre dos nombres suele ser un tipo de relación, o también puede establecer la asociación entre una entidad y sus atributos. Por ejemplo, al decir “la especialidad del médico”, estamos indicando la relación entre las entidades Especialidad y Médico, mientras que si decimos “la dirección del Médico”, estamos asociando el atributo Dirección a la entidad Médico.

Por tanto, simplemente basándonos en estos conceptos lingüísticos podemos generar un  esquema de conceptos preliminar.

Podemos construirlo desde un nivel alto de abstracción a uno bajo (descendente) o generar un esquema E/R en el papel y luego ir extendiéndolo y complicándolo (mancha de aceite).

Al finalizar el esquema, buscamos redundancias, ya que pueden derivar en problemas al implementar la base de datos. Es necesario buscar si existen atributos redundantes (los que se derivan de otros mediante algún cálculo, y que deben ser eliminados del esquema E/R, o bien etiquetados como redundantes), además hay que considerar la existencia de bucles en el diagrama E/R, ya que también pueden indicar la existencia de relaciones redundantes.

Como norma general, hay que tener en cuenta que la existencia de un bucle no implica la existencia de relaciones redundantes. Pero es necesario estudiar con mucho detenimiento las cardinalidades mínimas de las entidades y la semántica que aporten las relaciones. Si al eliminar una relación es siempre posible el paso en un sentido como en el inverso, entre las dos entidades unidas por la relación entonces existen relaciones redundantes.

Ejemplo sencillo

En la construcción de un sistema de información para el control hospitalario se revelaron los siguientes conceptos:

- Hospital: con los datos Nombre, Dirección y Teléfono

- Sala con los datos: número y cantidad de camas

- Médico, con los datos: Identidad, Nombre y Especialidad

- Paciente, con los datos: Identidad, Nombre, Dirección y Fecha de nacimiento.

Por otra parte, las relaciones reveladas entre dichos conceptos son:

-Cada hospital tiene varias salas. Todas y cada una de ellas pertenecen a un hospital (y sólo a uno).

-Cada médico trabaja en un único hospital, todo hospital tiene al menos 10 médicos.

-Un paciente puede estar internado; si lo está, estará en una sala y sólo en una.

-La capacidad máxima de camas que puede tener una sala es de cinco pacientes.

-Cada paciente puede ser atendido por más de un médico (pero por lo menos por uno) y a su vez un médico puede atender a varios pacientes.

1º Definimos las entidades, para ello ponemos en rojo y negrita los sustantivos y nombres.

Con lo que obtenemos los siguientes candidatos a Entidad: Hospital, Sala, Médico, Paciente, Cama

2º Definimos las candidatas a relaciones, marcando los verbos en azul e itálica.

3º Marcamos en verde subrayado las preposiciones para asignar los atributos o identificar nuevas relaciones

Por lo que tenemos posibles relaciones: Hospital tiene salas, Hospital tiene Médicos, Médico trabaja en Hospital, Paciente está internado, en sala.

Paciente atendido por médico.

Y los siguientes atributos:

Hospital: Nombre, Dirección, Teléfono.

Sala: Número, Cantidad de camas.

Médico: Identidad, Nombre, Especialidad

Paciente: Identidad, Nombre, Dirección, Fecha Nacimiento

Cama:

4º Con estos datos montamos un esquema preliminar

5º Buscamos redundancias, en este caso hay dos evidentes, Médico y Paciente

Con lo que quitándolas queda del siguiente modo:

6º Si el esquema es cíclico es posible que haya relaciones redundantes, En nuestro caso es posible que la relación ”Está Ingresado”  sea redundante con la Interrelación “Atiende”, pues todos los pacientes atendidos están ingresados. (Aunque esto no sea así en la realidad, pues en un hospital se atiende a pacientes externos e ingresados, nos ceñimos al enunciado original donde no dice que haya pacientes externos) En principio no vamos a quitar dicha relación, pero hay que ponerla en “Cuarentena”.

7º Buscamos las cardinalidades

Para la cardinalidad Hospital-Médico tenemos el enunciado

-Cada médico trabaja en un único hospital, todo hospital tiene al menos 10 médicos.

Con lo que tenemos:

Para la cardinalidad Hospital-Sala tenemos el enunciado:


-Cada hospital tiene varias salas. Todas y cada una de ellas pertenecen a un hospital (y sólo a uno).

Para la cardinalidad Paciente-Sala (aunque es posible que se elimine en el futuro) tendríamos:

-Un paciente puede estar internado; si lo está, estará en una sala y sólo en una.

 Además

-La capacidad máxima de camas que puede tener una sala es de cinco pacientes.

Finalmente para la cardinalidad Médico-Paciente tenemos el enunciado:

-Cada paciente puede ser atendido por más de un médico (pero por lo menos por uno) y a su vez un médico puede atender a varios pacientes.

Y colocando el tipo de correspondencia, tenemos el siguiente Esquema preliminar, (teniendo en cuenta que la relación “Está Ingresado” podría ser redundante, aunque de momento no se quitará)

Análisis orientado a orientado a objetos (AOO) II

El proceso de AOO

Para comenzar a analizar un proyecto no comenzaremos intentando ver que objetos tendrá la aplicación sino más bien si interaccionará con personas o con máquinas, como será esta interacción, si pertenece a un conjunto más amplio de programas o si se coordinará con otras aplicaciones. A continuación se exponen una serie de técnicas para recopilar datos para definir un modelo de análisis.

Casos de uso

Es una visión del sistema desde el punto de vista del usuario define el sistema con un escenario de uso habitual de interacción del sistema con el usuario final. Esta visión debe quedar definida de forma clara y sin ambigüedades y será un excelente modelo de creación de requisitos y de validación de pruebas. El resultado final es un diagrama de casos de uso de UML que puede representarse en diferentes niveles de abstracción.