Diagram de clases

[samile]

http://img180.imageshack.us/img180/9509/clases.jpg

Hola,

Tengo este diagrama y quisiera saber si es necesario hacer una clase adicional que relacione appointment con patient y lo msimo entre patient and prescription.
O si asi como esta me sirve.

Gracias

[gnzsoloyo]

Bueno, creo que tienes un problema conceptual: Un diagrama de clases sirve como referencia o guía para crear un diagrama de modelo de datos, pero no son lo mismo. En tu caso estás haciendo un hibrido, ya que estás mezclando conceptos de ambas cosas.
En realidad lo que tienes que hacer es un diagrama Entidad - Relación, que es de donde realmente surge el modelo de datos, y donde se establecen realmente las tablas que van a componer la base. cuando lo hagas notarás a simple vista dónde te están faltando tablas, y dónde hay redundancias.

Yo te sugeriría que lo volvieses a plantear, separando ambos conceptos un poco mejor.

Nota: Siempre es mejor usar el propio idioma, sobre todo si vas a preguntarle a gente que tal vez no trate mucho con otra lengua todos los días...

[samile]

Iniciado por gnzsoloyo

Bueno, creo que tienes un problema conceptual: Un diagrama de clases sirve como referencia o guía para crear un diagrama de modelo de datos, pero no son lo mismo. En tu caso estás haciendo un hibrido, ya que estás mezclando conceptos de ambas cosas.
En realidad lo que tienes que hacer es un diagrama Entidad - Relación, que es de donde realmente surge el modelo de datos, y donde se establecen realmente las tablas que van a componer la base. cuando lo hagas notarás a simple vista dónde te están faltando tablas, y dónde hay redundancias.

Yo te sugeriría que lo volvieses a plantear, separando ambos conceptos un poco mejor.

Nota: Siempre es mejor usar el propio idioma, sobre todo si vas a preguntarle a gente que tal vez no trate mucho con otra lengua todos los días...

OK voy a intentar cambiarlo.

PS Lo siento por el idioma pero este es un trabajo para la facultad y es en ingles

[gnzsoloyo]

Ok.
Buen, algunos tips sobre tu caso:
1. Poner Paciente y Doctos como una jerarquía o sublcase de User es discutible desde la óptica de bases de datos, porque sus dominios son diferentes. Demasiado diferentes. En todo caso, ambos poseen un atributo username que los vincula a la tabla User.

2. No existe relación directa entre Paciente y Doctor, porque la relación se expresa como "un doctor atiende muchos pacientes y un paciente puede ser atendido por diferentes doctores". Esa cardinalidad es N:M, por lo que define la existencia de una tabla que los vincula. Aún cuando un paciente pudiese ser atendido por un único doctor, tampoco existiría, porque lo que los vincula es una instancia de una consulta realizada, y no un vínculo entre ambos.

3. La relación entre las medicinas y las líneas de las facturas no es 1:1, aunque lo parezca. Es 1:N, porque la misma medicina puede aparecer en varias recetas diferentes, y siendo linea_receta una tabla, el vínculo se expresa: "Cada medicina puede aparecer en diferentes líneas de diferentes recetas, y cada línea de receta debe contener una única medicina".

4. Le falta una relación a la HistoriaMédica. Una historia médica contiene atributos que la relacionan con un único paciente, pero a su vez contiene múltiples instancias de cada reporte, análisis, receta, estudio, etc., que se le realizó al paciente. Entonces existen diferentes tipos de documentos relacionados, cada uno de los cuales a su vez puede contar con su propia entidad de almacenamiento.

¿Se va entendiendo la idea?

Puedo seguir....

[samile]

Muchas gracias

OK tendria:
Doctor relacionado con citas "Un doctor atiende varias citas"
Paciente relacionado con citas "Un paciente asiste a varias citas"

Lo mismo seria con las prescripciones
Doctor-1--M-Prescripcion
Paciente-1--M-Prescripcion

voy bien?

[gnzsoloyo]

Exacto. Lo que no existe es una vinculación directa, como si la puede haber entre las clases.
Eso es porque lo que describe el modelo de datos no es exactamente igual a lo que muestra el modelo de clases. En esencia, el modelo de clases es estático,mientras que lo que muestra el de datos son relaciones dinámicas, representadas por los flujos de datos.

Centrándonos en la relación médico - paciente, podemos deducir:
- Debe existir una entidad Consulta, que contiene la información de la cita médica, con quién y de qué paciente, y en qué fecha y hora.
- Debe existir una entidad Receta, que se relaciona con el paciente y el médico a través de la consulta (la receta se emite en una consulta), y con la historia clínica (debería indicarse allí lo mismo que se indica en la receta, entonces vincular ambos es una forma simple de hacerlo y evitar redundancias)
- Debe existir una entidad HistoriaClínica que debe vincularse con Paciente, Medico, Receta, Consulta, Estudios, y tal vez algo más.
- Debería haber una entidad Estudios, vinculada con Paciente, Médico, Especialista, Receta (si se indicó en ella), TipoEstudio (conviene codificarlos).
- El médico debe tener una Especialidad (que implica posiblemente dos tablas: la de Especialidad y la de Médico_Especialidad, si tiene más de una).
- El paciente, a su vez, puede estar vinculado a un ServicioMedico (la cobertura que él paga), que también puede ser N:M si el paciente cambia, para mantener la historicidad de la misma.

Y podemos seguir...

[samile]

La informacion sobre estudios no la deseo incluir por ahora. Gracias
Entre Doctor y la tabla de turnos (Time Table)
deberia existir una tercera entidad Doctor_Turno??

Doctor-1--M-Doctor_Turno
Doctor_Turno -M--1-Turno

cierto??

Gracias

[gnzsoloyo]

SI, si las consultas pueden no realizarse, entonces necesitas dos entidades distintas: Una para los turnos y otra para las Consultas, que efectivamente se realizan.
Es correcto.

En definitiva, Turnos es una tabla de uso administrativo, que no se asienta en la Historia Clínica. Es para otros destinos, pero se necesita.

[samile]

UN momento entre receta y paciente no habria relacion directa, seria solo a travez de la cita. Algo como:

Receta-1--1--Cita
Paciente-1---*-Cita
Medico-1---*-Cita
???

[gnzsoloyo]

Si se debe mantener un registro de las recetas, esta, por cuestiones de normalización debe dividirse en dos, tal como lo habías planteado: La receta, y los ítems o líneas de la receta.
Ahora bien. Una receta pertenece a un paciente y es escrita por un médico, por lo que la receta debe contener ambas claves. Pero a su vez, entre los datos de la historia clínica debe aparecer que se le hizo una receta o mas de una en un una consulta, por lo que ambos datos deben estar vinculados a la historia clínica. Como sería recargar poner cada receta a la historia, lo mejor es poner en la receta el ID de la consulta y el de la consulta en la historia.
De modo que, en realidad, lo que hay es una relación entre la cita y la receta. La relación entre Receta - Médico - Paciente, se puede considerar implícita en la Cita, a los efectos del diseño de tablas.
Además, de esa forma lo puedes hacer como N:M, con lo cual podría haber más de una receta por cada cita.
Eso implicaría una tabla intermedia que relacione las PK de las recetas con las de las citas.

[samile]

Yo creeria que la relacion entre Receta y cita debe ser 1 a 1, en una receta se incluyen todas las medicinas recetadas.

Solo serian varias si se generara receta para los examenes.

[gnzsoloyo]

Bueno, eso depende más de las reglas del negocio que de que se puede deducir solamente a nivel conceptual. Para definir esos detalles necesitas saber cuales son los requerimientos que surgen del relevamiento del sistema.
No hay una regla fija allí, pero el hecho que se consideren estudios, puede implicar una relación al menos 1:N

[samile]

solo una pregunta mas...q puede ser un poco tonta ..pero tengo dudas
en el diagrama deben incluirse los ids que hacen la relacion por ejemplo:

Cita
-IdDoctor
-IdPaciente
-IdReceta

HistoriaMedica
-IdReceta
-IdPaciente

si cierto?

[gnzsoloyo]

Exacto, además si usas una herramienta CASE te lo va a exigir.
Por lo demás es muy buena idea hacer que los ID se identifiquen de la forma que los pones y no usar simplemente "ID" en su tabla.
Luego te facilita las consultas.

[samile]

ok. gracias


otra cosita (probablamente la ultima) :))

entre receta e historia medica, debe existir una tabla que las relaicone porque una historia tiene mas de una receta...cierto?

[gnzsoloyo]

Si.
Una regla genérica de las transforamciones del DER lógico (el diagrama entidad - relación) al DER físico (diagrama de tablas) que siempre se cumple dice que toda relación N:M entre dos entidades genera una tabla, aunque la misma no se encuentre expresada gráficamente en el DER lógico.