A patient has two subtypes inpatient and outpatient.
I understand that inpatient and outpatient are weak entities.
How can I connect the patient entity with both inpatient entity and outpatient entity.
it is a little different depending on the ER-diagram tool.
sub-entity is all connect to parent entity
I will add several pictures.
Related
I have an ERD that I have developed relational model for. I just wanted to know if there are any errors in my relation model. I have listed the relational model below. I have a picture of the ERD.
PHYSICIAN (DRID (PK), NAME, SPECIALTY, PRESCRIPTION(FK))
PRESCRIPTION (PRESCRIPTIONID(PK), DRID(FK), DRUGID(FK), PATIENTID, DRUGDOSAGE)
DRUG (DRUGID(PK), DRUGNAME, DRUGMANU, DRID)
ORDERS (DRUGID(PK), PRESCRIPTIONID(FK))
I can see a few issues in your ERD:
Why does Prescription have a double-bordered box? It's not a weak entity set, it's identified by its own attributes.
Instead of showing Patient ID as an attribute of Prescription, draw a relationship between Prescription and Patient.
The ternary relationship Orders allows different physicians to prescribe drugs on the same prescription. Two binary relationships (many-to-one from Prescription to Physician, and a many-to-many between Prescription and Drug) should work better. In fact, your relational model almost does this already.
Should each prescription record only one Drug Dosage? I would place this attribute on the suggested binary relationship between Prescription and Drug.
As for your relational model:
If you include PRESCRIPTION in PHYSICIAN, this creates a functional dependency DRID -> PRESCRIPTION, in other words, each physician is associated with a single prescription. This is independent of PRESCRIPTIONID -> DRID in the Prescription table, which properly represents the binary relationship I suggested above.
If you include DRUGID in PRESCRIPTION, this creates a functional dependency PRESCRIPTIONID -> DRUGID, in other words, each prescription is associated with a single drug. This is independent of the association between drugs and prescriptions in the ORDERS table.
If you include DRID in DRUG, this creates a functional dependency DRUGID -> DRID, in other words, each drug is associated with a single physician. The physician for each drug in a prescription can be determined by joining PRESCRIPTION with ORDERS, no need to try and record it per drug.
ORDERS should use a composite primary key (DRUGID, PRESCRIPTIONID) to represent a many-to-many relationship. As it stands, each drug can be associated with a single prescription.
I hope that helps.
Im making an ERD now for medicine care.
I have an issue with 2 entities:
Patient and caregiver.
The caregiver is a person that helps for the patient and can do features on the application for the patient.
For now I choose that the patient is a separate user from the caregiver.
If its like that,I need to do a seperate entities for the caregiver and for the patient. When I do this , there is an overload on the ERD because the 2 entities can do the same thing on the system so they have the same connections to other entities.
In addition , they have just one attribute that is different between them and this is the diagnosis of the patient.
What to do?
I would suggest looking into adding the caregiver as a sub class if all the rows are the same apart from one. But having them both as separate entities wouldnt be an overload on the database as long as you add primary/foreign keys correctly. Have you got a current ERD i can look at?
I am about to develop a solution for a customer where the basic entity is a member and members can have different multiple social relationships with other members. For instance Lets say we have four types of members Doctors, Specialist, Nurses and Patients. So one or more Doctors can consult one or more Specialists, One or more Doctors can treat one or more Patients. One or more Doctor is in Charge of one or more Nurses. So if I were to use a Relational DB a high degree of recursion would be necessary (as All entities must be members). Whereas recursion is not necessary in a Graph data model.
Is it then safe to say it is better to use a Graph database for a social type application where members may have different or overlapping roles.
A graph database would be good at modelling these kinds of relationships. There's a few ways that you might model it. You could think of a vertex as being a Member with different edges from Member to other Members representing the types of relationships:
Member --consults--> Member (physician to specialist)
Member --reportsTo--> Member (nurse to physician)
Member --diagnoses--> Member (physician to patient)
Obviously a Member may have as many of any edge type (e.g. multiple "consults" with specialists). In a more complex model, you might also see a Member as being an "identity" for a person such that your model looks like:
Member --actsAsPhysician--> Physician
Member --actsAsSpecialist--> Specialist
Physician --consults--> Specialist
In this approach the "consults" edge can only exist on a "Physician" vertex, thus you provide some constraints as to what vertex types can be expected to have what kind of edges.
Graphs provide you a lot of flexibility in being able to model data such as it exists in the real-world as you are really just describing entities and the relationships among them. I'd encourage you to look at http://tinkerpop.com for a collection of tools that are helpful in building graph applications independent of the graph database you choose.
If every one is a member then member is central to the data model in a relational perspective. There is no need for recursive SQL select statements:
Member ->---<- Doctor ->---<- Patients
One or More Members is One or More Doctors One or More Doctors treats One or More Patients
Your model will have a lot of Many to Many relationships and alot of Relationship tables. For instance the Treats relation could contain attributes such as Treatment Period
Ailment
etc.
Your solution could be implemented in any topology. While the network/graph topology is faster than the Set topology the graph data model once implemented is almost impossible to change. History tells us it is unwise to build rigid business applications. So research the pros and cons of each and make a decision.
As i read through software engineering appendix 1 from Roger Pressman book that
an association between two classes means that there is a structural
relationship between them
what structural relationship means?
UML differentiates 'structural' and 'behavioural' models. Class Diagrams, Package Diagrams and a few other capture the structural aspects. State/Sequence/Activity Diagrams capture behavioural aspects.
'Structural' means it holds over time. For example, the association between Order and OrderLines ("Order consists of 1 or more OrderLines / OrderLine is part of exactly one Order"). Or Dog and Person ("Dog is owned by exactly one Person / Person owns many Dogs"). Used well, Associations capture invariant rules from the problem domain. To use the Dog example: the association says a Dog can't ever be owned by more than one Person at any given time. Doesn't matter if the Dog is running, sitting, or eating: it must have exactly one Owner. Note also the owner could change over time: but there can never be more than one at any point.
An alternative is to think of Associations as the kind of thing that might be captured using foreign keys in a relational database.
hth.
i have an erd for a school assignment that contains a many to many relationship that as far as i can tell is un-expandable. I have a class that can be taught by many teachers (as in many teachers in the same room at the same time teaching the same people) and one teacher is assigned as the head teacher, so as far as i can see, one class can be taught by many teachers and many teachers can teach the same class (at the same time). Has anyone got any idea how i could expand this?
I have tried making a week entity eg group. so one class is taugt by one group and one group can teach many classes but i still end up with the issue of one group can have many teachers and many teachers can be in a group.
Every way i look at i end up with a many to many relationship between teacher and either class or the weak entity, any help would be greatly appreciated.
thanks
The usual (and best) approach to modeling m:n relationships is to create an intermediate association.
In this case you would have a 1:m relationship between Class and the association (since each class can be associated with many teachers) and also a 1:m relationship between Teacher and the associtaion (since each teacher can be associated many classes).
When it comes to creating tables, the association becomes a table in its own right, with foreign keys to both Class and Teacher, thus linking them together.