Hi I am doing an assignment on ER modelling and there is a part that I'm stuck on, here is an extract:
Patient is a person who is either admitted to the hospital or is registered in an outpatient program. Each patient has a patient number (ID), name, dob, and tele. Resident patients have a Date Admitted. Each outpatient is scheduled for zero or more return visits, which have data and comments. Each time a patient is admitted to the hospital or registered as an outpatient, they receive a new patient number.
I can't do the last section bolded. I have attempted the question: http://tinypic.com/r/358dus9/4
Also if anyone can check if I've done it correctly, would be highly appreciated thanks!
Sometimes assignments also contain "information" that is pretty much immaterial.
The purpose is precisely to learn to filter out the 'real' information from the noise.
(With the caveat that there are dozens and dozens of ER dialects, and each has its own peculiarities,) ER does not have a way to express the information that "attribute x in entity y is to be autogenerated by the system.". For this reason, and as far as the actual ER modeling is concerned, your bold phrase is just noise.
I agree with Erwin on this one. I'll add that not having to have a consistent structure for the patient means that you don't have to create another table for the patient, you can just put it into the ER case directly.
Generally, this is a bad practice however. In reality, you would still have a regular patients table with identifiable patients over several visits. Then again, this is a class and as we all know, the #1 rule is not to disobey the teacher (no matter how insane it is). The real lesson here is to learn how to take requirements, have them clarify the requirements, explain the consequences if they don't follow your advice on how the data will be modeled and then go ahead with whatever they say as they have the final say as the client.
Depends on the course that you're taking, as well. Microsoft SQL Server/SQL Express has the autonumber setting possible, while Oracle does not feature this (although it's accomplished through this). Insofar as the modeling is concerned, there is no way to model that requirement specifically, as far as I know.
Entity-relationship diagrams are used to model the relationships and the data itself as it exists. What you're looking for is more of a UML approach to describing the process in which it has data created for that field.
Related
I am working on a practice questions for ERD, and I was wondering what the correct approach is for modelling either or relationships.
For example, in a Taekwondo school, you will have customer accounts, which will represent and pay for one or many students. The account is owned by either a parent, or a the student himself. Therefore the account owner is either a parent or a student. What is the best way to represent a relationship like this?
Here is what I came up with, but I am unsure if this conforms to best practice:
1 Clarification
Representing an either-or relationship in Crows foot ERD
The diagram you have is a good start. Note:
that is not ERD. That is way more detail than an ERD can handle
ERD does not have a Crows Foot, that is IEEE notation
Ultimately, you need a data model that has the detail required for an implementation (way more than ERD). That is why I said your diagram is a good start, it is moving in that direction. However, we have a Standard for Relational Data Modelling: IDEF1X, the Standard for modelling Relational databases since 1993, available since 1984 before it was elevated to a standard.
Evidently both Dr E F Codd's Relational Model, and the diagrammatic method for modelling Relational databases is suppressed.
The relationship symbol, especially the cardinality, in IEEE notation is better (more easily understood) than IDEF1X, therefore most people use that. All data modelling tools, such as ERwin, implement IDEF1X, and allow either IDEF1X or IEEE notation for relationships.
2 Request
The diagram as intended is illegal. Why ? Because you have one relationship going "out" of Person, to two tables. Not possible. You are asking how to represent such a relationship in a data model (not possible in ERD). The answer is, that is an OR Gate is logical terms, a Subtype in Relational terms.
Please inspect these answers for overview and detail. Follow the links for implementation details and code:
How can I relate a primary key field to multiple tables?
Structuring database relationships for tracking different variations of app settings
How do I get around this relational database design smell?
Subtypes can be:
Exclusive (the Basetype must be one of the Subtypes), or
Non-Exclusive (the Basetype must be any [more than one] of the Subtypes).
From Role it appears to be Exclusive. What you call Role is a Discriminator in IDEF1X.
That is best practice for Relational databases.
Relational Data Model
This is best practice for for data models (this level of detail shows attribute name only).
Of course, all my data models are rendered in IDEF1X.
My IDEF1X Introduction is essential reading for beginners.
ParentId, StudentId, OwnerId are all RoleNames (Relational term)of PersonId. This makes the context of the FK explicit.
3 Correction
but I am unsure if this conforms to best practice
Since you are concerned, there is one other issue. There is a mistake in your model, it is one of the common errors that happen when one stamps id on every file. Such a practice cripples the modelling exercise, and makes it prone to various errors. (I understand that you are taught that crippling method.)
Since a Person can have 0-or-1 Account, and the Person PK (which is unique to a Person), is a FK in Account, it can be the PK in Account.
AccountId is not necessary: it is 100% redundant, one additional field and one additional index, that can be eliminated.
I need to create a data model for an education based application. The question I want to ask is is it better to make one junction table for two tables with many-to-many relation or create one big junction table to deal with all many-to-many relationships?
Say, I have student, tutor, subject, grade tables.
student and tutor are in many-to-many
tutor and subject are in many-to-many
tutor and grade are also in many-to-many
A student can have many tutors for one subject of one grade.
There can be many tutors for one subject of one grade.
A subject of one grade can be taught by many tutors.
Above are just a few examples of the relationships.
My question is how to model these relationships efficiently? Should I have one junction table for each of the relationships or should I combine them into one big bridge table?
So, if I have a class table as well, then from the big bridge table I can get for which class which tutor taught which subject of what grade along with other details of the class.
Let's assume the database is not yet electronic, but a good old filing cabinet instead.
Let's assume the database is for a library, and there are a couple of distinct sorts of "many-to-many info" to be maintained : authors to books (coauthored books have >1 author), readers to books, readers to readers, book availability in possibly multiple site locations of the library, ...
Would you ever think of stashing all those distinct sorts of information in one big filing cabinet ? Imagine what the consequences are for its users ? Sometimes you'll be prohibited to do something "readers to books" merely because someone else is right there doing something "readers to readers". If and when you manage to gain access and it's finally your turn do so something, say "authors to books", your work will be slowed down because all the "readers to books" stuff might come in between and you'll have to spend extra time merely skipping the unneeded stuff. If a "conversion operation" must be performed, say, a new kind of many-to-many stuff is discovered and must be integrated in the single filing cabinet, the entire database is inaccessible while the conversion operation is being performed (people adding filing cards of a color that wasn't yet in use). Etc. etc. . Those undesirable properties carry over almost 1-1 to the electronic equivalent.
As someone else put it : don't be afraid of tables. It's what a DBMS is good at.
EDIT
Brief : just keep it at one table per fact type, and abstain from making (/trying to discover) geeky abstractions like "they're all just properties" / "they're all just some many-to-many-relation" / ... . They're geeky because an end user/business user will not "see" it. And thus there is no business value in making them.
I am having some trouble getting my head around cardinality in ER diagramming. I am linking an example I found to help me explain where I am getting confused.
http://www.postgresqltutorial.com/download/dvd-rental-er-diagram/#
Question 1:
The cardinality between Customer and Rental is 0:1. So that means a customer can take out zero or one rentals. I would have thought the customer would be able to take out 1 or many rentals (1:*) because a customer means that they are taking out a rental (can't be a customer if you are not spending any money) and that a customer could take out many rentals.
Question 2:
Also for the Staff to Payment relationship. Staff to Payment is 0:1 cardinality. I would have thought that a staff would make at least one payment because payments are necessary for the rental transaction. And then in reverse (one payment can be made by one and only payment): just to clarify this is because logically a payment is a transaction that only be made by one person at a time?
I agree with you. The same thing occurs on both sides of film_category, which I believe represents a many-to-many relationship based on the primary key. I think the diagram was drawn incorrectly.
Note that there's no such thing as 0:1 cardinality, but rather 0/1:1. Also, despite what the site and diagram says, the diagram is a table diagram and not an ER diagram. The notation used doesn't support or distinguish all the concepts from the Entity-Relationship model. Proper ER diagrams use Chen's notation or something equivalent.
Database Design
Is this a bad design for a relational database. I don't see anyone doing examples that look like this.
But considering that an interview is comprised of all the different tables I have linked to the interview table it seems valid.
Except of OH Number (Oral History Number.) An oral history from one narrator may be comprised of different interviews conducted at different dates. Each individual interview is assigned a unique ID that make op a series that is assigned 1 OH Number.
I'm also thinking of putting "Interviewer, Indexer, and Transcriptionist in the same table.
I created the following mock-up for you given the details you have provided. I believe this will be a good starting place. You have an interview object and a person object. You have a joining table of InterviewPerson. This allows you to have one to many person objects per interview.
I want the database to be robust enough that if a researcher called in
and wanted all the interviews conducted by John Doe, on Race
Relations, I could pull a query for it.
To do the aforementioned as you have stated, you would join both the Interview table and the Person table on the InterviewPerson table, and then you would limit your query of that joining based on the Person.firstName, Person.lastName, Interview.topic (or title).
Please note, this is a rough draft but should be a good general idea and start.
Database Design Redux
This is what I came up with based on your suggestions.
I have a database to create with a list of fields I need to include in it. I am required to do a table showing the normalization process from 1NF to 2NF to 3NF. However, I don't understand normalization AT ALL and I urgently need to try and get it normalized. The fields I am using are as follows:
CustomerID
Surname
Forename
Email
PhoneNo
ReservationID
DateRes
Collected(Y/N)
PhoneID
Brand
Model
OperatingSystem
ScreenSize
StorageSize
Price
Description
Img1
Img2
Thumbnail
Stock
Flagged (Y/N)
ContactID
Subject
Message
DateContact
Replied (Y/N)
I am not so good at database design so any help would be useful.
Assuming this is not homework, I wonder why you have to show the process by which your reach 3NF at all. If your database is in 3NF, who cares how you got there? Again, assuming this is not homework, there is an easy way to design a database that is in 3NF right off the bat.
Learn ER modeling. Use ER modeling to describe the information requirements your database has to meet. Choose your entities carefully. For each entity, choose an id for that entity very carefully. If it's not in the data as given, you may have to synthesize an id. This is data analysis, NOT database design. Make very, very sure that the attributes you discover at this stage are attached to the correct entity or relationship.
This is context dependent. For example, in a personnel system, "Date of Birth" is an attribute of an employee. But in a birthing center, "Date of Birth" is an attribute of a birth, and the person born has a relationship to that birth. Several persons can be born in one birth.
Learn how to convert an ER model to a relational model. For these purposes SQL models and relational models can be treated as equivalent. Be very, very careful in your choices of primary keys, and be aware of the consequences of using features like "automunber". You may need to use this feature, but come up with ways of coping when redundant data entry results in two rows with different primary keys that both refer to the same instance of a subject matter entity.
If your attributes have been connected to the right entity or relationship, if you did the conversion to a relational model correctly, and if you chose your primary keys right, your database will automagically be in 3NF.
If this IS homework, then your teacher's requirements are not clear from your question. It's probably just as easy to learn what the teacher is trying to teach you as it is to tell us what the real requirements are.