First I'll explain the statement of diagram and after that I will explain my problem and I'll attach my actual diagram.
I should make an ER diagram about the following statement:
Perform the design and implementation of a database to store information about patients admitted to a hospital, patients can be adults or children. In the case of children we save information from who their parents who in turn can also be patient. In this hospital, patients arriving at the emergency department of the hospital are examined by a doctor and, depending on their health status, are entered in the corresponding plant (traumatology, intensive care...) under the supervision of a nurse.
Each patient receives a treatment that must be stored
Well, I design the following diagram; but my main problem is how to make the relation between fathers that can be patients. I decided put all fathers as patients and don't represent adults as entity, I have considered them implicit into patient's entity. But I'm not very sure about the validity of my solution.
I'd be grateful if someone can help me with my doubt.
How about subtyping patient from person and then creating a relationship from patients who are children to their parent persons? In this way, not every person need to be a patient but parents can be patients too. The relationship between parent and child indicates the role of each so there's no need to specifically subtype patients into parents or children.
Note also that your Doctors can currently only examine one patient.
Related
In this case will the employee have the information about the rental date, so as to send a reminder? If not, how do I execute the connection?
Make the diagram like this to show that the employee is given information about the rents. Information about the attributes of the rents relationship is shared between the customer entity and the employee entity.
This diagram could be made more detailed if more information about the database is provided, especially if the information is in the form of code.
I am new to using UML and I am not sure if my diagram is correct. I would like some advice from someone more experienced than me.
The statement of my problema says:
Students study courses and each student can take several courses "studies" each. Any course can have more than one student studying it.
Students, who are identified by a numerical code, have a name, date of birth and one or more nationalities.
A student who studies can receive scholarships.
A Student can recieve more than one scholarship per course. And an
individual scholarship can be given to more than one student. The
scholarships have a numeric code, which identifies them, a name, a
base amount and different conditions to be fulfilled at the time of
the assignment.
My proposal is the following:
What I want is to represent students, grants and the courses the student takes, and I am not sure if I should use an associative relation or a ternary relation.
Can anybody confirm if my proposal UML diagram is the right one?
The only statement directly relating students, courses & grants is the unclear "[a s]tudent can receive more than one grant per course".
It only actually says that each student-course pair can have more than one associated grant. (Maybe the author of the assignment thought that that "per" sentence is saying more than that, but it's not.) It doesn't say of a student whether their grants depend on their courses, and if so how. Your design is best when given a triplet you can't tell anything about any other triplet. The design with Takes(student,course) & Receives(student, course, grant) with th FK (foreign key) {student, course} from Receives to Takes is best when if you know a student & course pair then you know its grants. If grants are given to a student independently of courses then a design with Takes(student,course) & Receives(student,grant) is enough.
Clarify with your instructor.
Almost. The lozenge (or diamond) shaped element is itself an association class which associates all connected classes. What you want it a simple association class between Student and Studies like this:
The Scholarship represents the exams passed by the students in specific studies. The association class relation is indicated by the dashed line linked to the association (which has a m-n multiplicity).
Before you get to any attributes, I don't see a correlation between the nouns in the problem statement and your classes. I would expect to see the following classes:
Student
Course
Nationality
Scholarship
I would also expect to see an association class, called CourseEnrollment, that would have the following italicized properties at the ends of the association:
Student studiedCourse [1..*] Course
Course studyingStudent [1..*] Student
That association class would have yet another association with Scholarship, called ScholarshipAward, that would have the following italicized properties at the ends of the association:
CourseEnrollment awardedScholarship [0..*] Scholarship
Scholarship receivingCourseEnrollment [0..*] CourseEnrollment
With this arrangement, a Scholarship can be awarded to a combination of Student and Course.
(I apologies in advance for my English)
I need to make a model of relation.
Normally it a thing we should do in team, but I am stuck to be alone, so I am kind of overwhelm by this
It about a school and it information concerning The Student, The Parents and the Class he want to enroll. Also they keep academic results.
I just can't get an ideal of how I could link them all and avoiding relations problems
http://i.imgur.com/fdwxH8g.jpg
First, I suggest you add a Person table to supertype Parent and Student, and move all the personal and contact information attributes to Person. You're sure to want to add additional information later, and having to duplicate everything for parents, students (and later, teachers and other school staff) gets to be a nuisance.
person (person_id PK, last_name, first_name, sex, birthday, email, address, city, phone_number, cellphone_number)
Next, do you want to record biological parents or caregivers? In schools we normally care about caregivers and their relationship to the student. To record that, you could create a relationship type table:
relationship (relationship_id PK, description)
with entries for father, mother, aunt, grandfather, fostermother, etc. You can then record the relationship between 2 persons like so:
parent (parent_id PK/FK, child_id PK/FK, relationship FK)
If you wanted to record biological parents, you could use:
bioparents (child_id PK/FK, father_id FK, mother_id FK)
with father and mother ids nullable (or decompose into separate tables for father and mother) since we're unlikely to know both parents for all students.
Finally, we get to the business at hand, students. Historical information and alumni are important in schools, so take care to model students over time, not just current students. You need to consider the time resolution for student registrations - are registrations annual, quarterly, or something else? For annual registrations, you could start with:
student (person_id PK/FK, year)
Now, what is a class? Is it something that recurs over time, or are classes with the same name in different years/quarters separate things? Can classes contain learners of different forms/grades/levels, or are they partitions of those? Is a class a grouping of students that attend multiple subjects, or a subject-specific grouping? I'm familiar with two types of classes, which could be called form classes and academic classes, but things may be different in your region of the world.
Using your class table:
class (class_number PK, name, prerequisite, formation_time)
We need to link students to it. If class membership is an annual thing, we can add to the student relation above, e.g.
student (person_id PK/FK, year, class_number FK)
Now, I just made up tables as I went along, but if you want to do this properly, you really should list/model your functional dependencies before you start making up tables. You could look into a formal modeling discipline like Object-Role Modeling, or at least write out simple logical relations in both directions:
a Student has one or more Parents
a Parent has one or more Students
a Class has a Year
a Year has zero or more Classes
a Student has a Class per Year
For non-binary relations, you don't need to write it out in every direction, but you do need to decide which combinations of attributes uniquely determine the others. For example, the combination of Student and Year uniquely determines the Class.
Anyway, that should give you a start.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Note: This is a rough copy i didnt include constraints, weak entities, ..., etc yet. I still need to have a solid understanding of this question.
Questions:
To keep track of what theater company manages performer, what performer is in two theatre companies do i have to make a unique code for each entity set in other entity sets to keep track of them?
Can start_Location simply point to Place for the theatre company entity?
Can an Actor be Born in a place or does it have to have a attribute that points to place?
Do my relationships so far make sense?
Are there any redundant attributes such as Short_Descript in Plays?
Can i make an attribute in Place called "Town, State/Department/Province"? Or does it have to be a composed attribute?
Please note: I will be editing and updating my diagram if I have more questions and such...
I would appreciate any suggestions or hints.
ERD:
Question Information:
An actor is born in a place and he/she lives presently in a place (this information is mandatory).
We store in the database only the last known place where the actor lives.
We need the following information for an actor: actor number, actor name , date when actor was born, and date when actor died (check if died > born).
An actor is a performer, or/and a theater director.
We store for performer the date when he/she started to perform.
We store for theater director the date when starts his/her last employment as theater director
We consider in DBActors the following types of plays: drama, comedy and tragedy.
For each we like to store the following data: play’s number , play’s title , play’s short description , year when it was written ,date when it was first presented on stage(p_date_p, date).
For dramas we store also the drama type,name of the main positive character, and name of main negative character.
The drama type is one of the following:
“classical”, “medieval”, “renaissance”, “nineteenth-century”, “modern”, and
“contemporary”
For comedies we store the comedy type, the name of main
character , and the name of the second character
The comedy type is one of the following: “ancient mroman”, “ancient greek”, “farce”, “comedy of humors”, “comedy of manners”,
“commedia dell’arte”, and “theater of absurd”;
For tragedies we store the tragedy type(t_type, varchar(20)),and name of main
character
The tragedy type is one of the following: “Greek”, “Roman”, “Renaissance”, “Neo
-classical”, and “Modern”
A play is written by one or many dramatists
It is possible that we do not know the dramatist for certain plays.
We store in the database all known plays even if they were not performed (“closet plays”)
Some actors are also dramatists.
We store in the database all known mdramatists.
An actor is hired by a unique theater company at any timestamp
He/she will stay in the same company the whole year when he/she was hired.
We store in the database the year when he/she was hired by the theater company
(small integer)
It is possible that the actor changes the theater company where he/she is
working during his/her life many times. It is possible that an actor is hired by the same company many times in different years. He/she can perform in
one or many plays (at least one)
which are presented by theater companies.
It is possible that an actor is hired by a theater company and performs in a play presented by another theater company.
It is unusual but possible that the same performer plays in the same play
presented by different theater companies. A theater company performs/presents
one or many plays every year.
Same play can be performed by one or many distinct theater companies.
We like to store in the database the date when the play starts to be performed
by a theater company.
It is possible that the same play is performed by different theater companies starting at same date.
We need to store for a dramatist his/her dramatist number,his/her name.
A dramatist wrote one or many plays(at least one).
The information to be stored in the database for each theater company
is: theater company number,theater company name , date when the
theater company started.
For each theater company we store in the database
the first location (place) where the theater company started
There might be more than one theater company starting in the same place.
A theater company must hire at least one actor.
Each theater company has a unique theater director.
He/she starts his/her work at a specific date.
It is possible that the same theater company has different theater directors but at distinct times and the same theater director manages different
theater companies in distinct times(never at the same date).
It is possible that the same theater director manages the same
theater company at different dates.
The information to be stored for place is: place number, town and state/department/province, place country
Here are my responses to your questions:
Whenever you look at two tables and see a Many to Many relationship, you can solve the problem easily using a linker table. Also known as a junction table “is a database table that contains common fields from two or more other database tables within the same database. It is on the many side of a one-to-many relationship with each of the other tables. Junction tables are known under many names, among them cross-reference table, bridge table, join table, map table, intersection table, linking table, many-to-many resolver, link table, pairing table, transition table, crosswalk, associative entity or association table.” Wikipedia example You saw me use these tables in your previous question. In this case you are stating that an actor can be managed my many Theater Companies and A Theater Company and also manage many Actors. This is a many to many so if you created a link table in between those tables for every relastionship between the two you’d add a new row in the link table that only contains a theater Company id and an actor id. If an actor was managed by many theater companies then you’d add several rows to the link table each holding the same actor id but each row having a different theater company’s id.
Yes, you can have start_Location point directly to place. This means that that Start_Location attribute must be a Foreign Key (FK) pointing the theater company to the Primary Key (PK) of the related Place record.
By all means an actor can be born in a place, but just like above, you need a column in Actor, that is a FK to the Place Table’s PK. You could call this column Birth_Place and all it’d hold is the PK of the record in Place that relates to the actor’s birth place. This column would also need to be NOT NULL because all actor’s need a Birth_Place.
So far it seems like your diagram will work to solve this problem, yes. Just see question 1’s answer for that follow up addition.
You’re getting good at removing redundancies. Your diagram looks good. The only suggestion, I’d make is why do you have a play table and then 3 separate play type tables? Why not add them together in on Table called Play. It’d sit exactly where Play currently sits in your diagram and contain the same attributes it already does, but you also add the following:
a. Type – Would be a string that you could place “Drama”, “Comedy”, or “Tradegy” in so you’d know exactly what type of play it is. Also this would allow you to add future play types to the plays table and not have to add a whole new table to the DB.
b. Sub_Type – Would also be a string and hold the type that you currently have under the separate tables. They are all essentially the same attribute in each table and would just hold different type descriptors depending on the parent Type.
c. Main_Character – Would be a string that holds the main character, because in your three separate tables, you have main characters. You’re just calling them 3 separate things. (get the direction I’m going in here? )
d. Secondary_Character – Would be a string that holds the secondary character. You have a secondary character in your dramas and comedies, but non in your tradegies so in tradegy records this column would wind up being null. See what I did there? You now have one table where you used to have 4, and in that one table you can retrieve all the same information you had in those 4 separate tables. Hopefully that’ll make your life easier.
You can do whatever you like, but I’m assuming you mean by best practices and it would be generally considered best practice to separate this single attribute into it’s Simple attribute sub parts. I.E. make it a composed attribute.
So I have some question about the association, aggregation and composition in UML diagram. Here is some scenarios :
Product review rating composition to product review. This means that for each product review rating MUST HAVE product review? If product review doesn't exist, rating for review doesn't make sense.
Customer NRIC associate to cart and order. We cannot use aggregation because if customer does not exist, cart and order cannot exist also.
Can somebody please help me check if my relationships are correct? Is it good to link all your tables with association because I kind of confused on aggregation and association. I do not know when to use that.
Correct me if I am wrong. Thanks in advance.
Take a look at this class diagram example for composition:
Composition declares an ownership associationship. Person owns Leg and Hand. Or other way around, Hand belongs to Person.
Now ask yourself how would you describe each relationship in your model. If you would say Product review rate owns a Product review or Product review belongs to a Product review rate, then your diagram is OK. If the ownership has the opposite direction (Product review rate belongs to Product review, then the diamond must go to the other side of the association.
The same thing applies to aggregation. If the association somehow declares an ownership, then the diamond must go to the side of the owner class.
The difference between aggregation and composition is that objects owned as composites can't be created without their owner, so usually they are created by their owner. These objects are destroyed when their owner is destroyed, they couldn't be used by another owner after their owner dies. Objects owned by an aggregation association can be created without their owner and possibly could outlive him and serve another owner.