My assignment is to draw an ER model (by hand) using Chen notation using the specifications below:
http://i57.tinypic.com/73ff2f.png
If you have questions about these specs. I'll play the role of the
client who will resolve them.
The database will serve a university.
Students have id's, names and gpa's. They must have exactly one major,
but they could have minors as well. Each major or minor is a
department which has a unique name and a phone number. For each
student with a minor, we record the date she signed up for it. Faculty
members are associated with a unique department and have id's, names
and office locations. Each internship is held by a particular student
at a particular compain and is supervised by a particular faculty
member. We also keep track of the last term in which that student
registered under that advisor for an internship at that company.
Students may have many internships over time. A given faculty member
may supervise many students at a given company, and she may supervise
a given student at several companies. However, for a given student and
company, there can be only one faculty advisor.
Students, Departments,
Faculty and Companies should be your entity types. Internship should
be a ternary relationship type. The specs should also lead you to some
binary relationship types. Don't add any ingredients to this mix other
than what appear in the specs.
Below is my work:
http://i60.tinypic.com/28rf7tf.jpg
Can anyone please help as I really need a better understanding of this (my professor is AWFUL at explaining this).
You missed (per your assignment's last paragraph) a department entity type. (Box.)
You missed 'Faculty members are associated with a unique department'. That's a relationship between those two entity types. (Diamond with lines to those boxes.)
You could have those major and minor entitie types that are 1:1 with departments. (Your present boxes with each a line to its own diamond each with a line to department.) But (per your assignment's last paragraph not listing them as entities) you could have major being a relationship 'student[s] has a major in department [d]' and similarly for minor. (Lines from student to each of two diamonds each with a line to department.) But the assignment actually says 'each major or minor is a department' so that's major as 'student[s] has major department [d]' and similarly for minor. (Same picture.)
Per your assignment's last paragraph you should make internship a ternary relationship. (Under Chen it's a relationship diamond (possibly with its own properties) formed by 3 lines to entity type rectangles (possibly with their own properties) rather than an entity box.) However, it's not clear exactly when your assignment considers that an internship holds. (It tells us what relationships hold; it's just not clear which one it wants to call interning.) (Although we can look for interpretations consistent with it being ternary.) One is 'student [s] interns at company [c] supervised by faculty member [f]'. But since 'for a given student and company, there can be only one faculty advisor' that notion of internship is more simply characterized by a binary relationship 'student [s] interns at company [c]'. But then you still need a relationship 'faculty member [f] advises student [s] at a company [c]'. So I will suggest that your assignment expects the former. We can add property term. (This is more reasonably called a relationship on student, company, faculty member and date; but E-RM considers relationships to be on entities. Although it all depends on your class's method's particulars.)
(The possibility of multiple reasonable variations is why you should propose a particular design fully handling a particular specification in a SO question.)
A problem with the E-R Model [sic] is that it introduces needless distinctions between entities, reltionships and properties. There is really no distinction between a relationship instance and an entity. Eg: Here we could just as well have an internship be per above an entity in a 4-way relationship plus property. Eg: Your assignment says 'each major or minor is a department'. But a major or minor isn't a department. A major or minor could be considered a subject, which would be the subject after which a department is named or the subject of the degree offered by a department. Or we could just have relationships in which a department participates but the relationship is about that department's subject or name or degree being a major or minor.
(If an internship as relationship participated in its own relationships I don't know how your instructor's particular method would keep the further lines organized. Some methods add internship entities (box) 1:1 with relationships (diamond); then some methods specially associate the entity type with the relationship as a reification while some make the relationship 4-way by including the reified entity type. Eg 'internship [i] is student [s] at company [c] and ...'.)
(Correctly speaking there are entity types vs relationships and entities vs relationship instances. But the assignment talks of relationship "types".)
Re E-RM see this answer and this one. Also the E-RM wiki page section 'Entity–relationship modeling'. (Which correctly mentions misinterpretations of Chen's E-RM & E-RDs by some related modeling and diagramming methods and tools and even some presentations of E-RM itself. But the 'Overview' is nonsense.)
Re E-RM problems see this.
Related
I have done a lot of reading into multiplicities for ER diagrams, and I believe I have an understanding of what each requirement is, but as someone self studying with the internet and a textbook, it is hard to see where I have made mistakes.
Any feedback on this would be greatly appreciated.
Cinema - There are multiple cinema complexes with their name, location and contact number list.
Theatres - There are 4 in each cinema. Two types are available and each one is identified by a screen number.
Seats - Many seats in each theatre are determined by the row number, seat number and the seat type (comfort level).
Purchase - Tickets are to be purchased at the cinema complex. This will include screening date, time and seat number.
Members - Members are defined by their name and email.
Signup - Many members sign up with or without a discount at the cinema of their choice.
Per "The Entity-Relationship Model-Toward a Unified View of Data", Chen ERD lines between entity type boxes and relationship type diamonds denote participation of the entity type in the relationship type. There's no direction to the relationship type. There's an order to entity types in the a natural language (or wff) expression (or name) of the relationship type, but ERDs don't show that by an arrow. ("Has" is uninformative. You mean a kind of "Within", of which you have two, isSeatWithinTheatre & isTheatreWithinCinemaComplex.)
An arrow expresses "the existence dependency of one entity type on another".
Chen ERDs have one number (or range) per line. It gives "the number of entities in each entity set which is allowed in a relationship set".
PS Your ERD says a CinemaComplex has an associated Merchandise but presumably there should be a relationship CinemaComplexSellsMerchandise.
PPS Please represent your ERD in text in your question. Every box & diamond gets a table with PK, every box, oval & participant gets an attribute, every line gets a FK. Sadly, presentations of ERDs are typically vague about allowing relationship type attributes (rather than entities) as parts of PKs.
So I'm making an E/R diagram based on drugs. It states that each drug is produced by a given pharmaceutical company and the trade name of the drug is identified among the products of the given pharmaceutical company. So here's the E/R diagram I drew up:
Now the biggest question I have about this is, are these relationships supposed to be one to many or many to many? Each one relationship is represented by an arrow (where the pointed arrow means at most one and the rounded arrow means exactly one). I first assumed that a single drug identified by a single trade name would come from just one pharmaceutical company but would it be possible for a single drug to come from multiple pharmaceutical company's? I'm also not sure if it's supposed to be a 3 way relationship or not.
Not sure if this is really a technical question you can find the answer to here. It would probably be wise to further clarify with your client, but from pure wording I would assume.
1.) 1 Drug - 1 Trade Name - 1 Company
2.) 1 Company has Many Drugs
From general knowledge of US drugs, different companies have their unique versions of drugs with the same active ingredient, but these are all filed under different trade names, maintaining 1 trade name - 1 company relationship.
For example, ibuprofen (generic) is sold under both Advil and Motrin (separate trade names).
In this style of ER diagram, Chen's original, the diamond denotes a ternary
"relationship" type, aka association type, among/on the three participant "entity" types symbolized by the boxes. As in an application relationship/association, as in "Entity-Relationship Model". The lines showing participations correspond to FKs (foreign keys).
In such a diagram each line gets labeled by the number or range giving the number of entities in each entity set which is allowed in a relationship set. The table for the relationship would have a FK for each line. Per Chen it would be described as (in order company-name-drug) (at-most-1)-to-(exactly-1)-to-N relationship (assuming the unlabeled line means any number). There is a style with a cardinality at each end of a line.
Misunderstandings/misrepresentations/misappropriations of Chen style by older & newer methods & products (although quite mainstream) lead to different so-called ER diagrams.
One such style only shows entity type boxes with relationships shown by connecting lines labeled by relationship names. The 1:many relationships can be implemented by a FK attribute in one of the entity type tables, although they needn't be, and although that's contrary to Chen ER modeling, which would use a table. Typically, for n-ary relationships for n>2, instead of just having three line segments connect at a point the point is replaced by a box for what in Chen is an "associative entity" type. The lines would then be participations/FKs under Chen. All lines now represent 1:many relationships. Other so-called ER diagrams just have boxes for tables and lines for FKs and don't even have relationships on entities in the Chen sense. The use of lines that only ever denote 1:many relationships and/or FKs lead to lines and FKs being (wrongly but ubiquitously) called "relationships". (Which seems to be how you understand the word.)
The wikipedia entry on E-R modeling (and E-R diagrams) is currently reasonable.
When we say each department is managed by an employee , Does that imply that each department must be managed by an employee and hence a total participation constraint ?
Does that imply that each department must be managed by an employee
and hence a total participation constraint ?
Yes in other words it's a one to one relationship
In my observation (based on question body and comments):
The relation is one-to-many, showing that an employee can be the manager of many departments.
None of the predicates shows on-to-one relation, since there is no peripatetic saying that an employee can be manger of one department.
The difference: (it is opinion base to decide if there is any difference as comments of this answer shows)
Each department must be managed by an employee
Emphasis a mandatory one-to-many relation (is-managed-by)
Each department is managed by an employee
Emphasis an optional one-to-many relation.
Hint:
Documenting data integrity constraints is most widely done using natural language, which often produces a quick dive into ambiguity. If you use plain English to express
data integrity constraints, you’ll inevitably hit the problem of how the English sentence maps,
unambiguously, into the table structures.Different programmers (and users alike) will interpret such sentences differently, because they all try to convert these into something that will
map into the database design. Programmers then code their perception of the constraint (not
necessarily the specifier’s).
A formal manner will be using the logic and set theory.
Here is the scenario.
Two completely different Entities are independently related to the third entity in the same way. How do we represent it in the ERD? or (Enhanced ER)
Ex:
Student "BORROWS" BOOK (from the library)
DEPARTMENT "BORROWS" BOOK (from the same library).
If I define 'BORROWS' relationship twice, it would be awkward and clumsy in terms of appearance in the diagram, and increase the complexity of implementation as well.
At the same time, I can not declare a ternary relationship since STUDENT and DEPARTMENT are not inter-related in a relationship-instance.
However, I couldn't find a better way.
How do I solve it?
If Wikipedia is to be believed, Enhanced ER permits inheritance. Why don't you have a BORROWER entity (with the appropriate relationship), and have STUDENT and DEPARTMENT subclass that?
I've been having a similar issue - where a company or a person can order a product.
You've got an order, that can belong to either a person, or a company - so what do you link the relationship to? I'm thinking orders will have a companyId, and a personId foreign key, but how do you make them exclusive? The data returned won't necessarily be the same - a company doesn't have a first name / last name field for example.
I guess it could be done by having a name returned, and in the case of a person build the string out of firstname / lastname, and in the case of a company use the companyname field .
There are couples of questions around asking for difference / explanation on identifying and non-identifying relationship in relationship database.
My question is, can you think of a simpler term for these jargons? I understand that technical terms have to be specific and unambiguous though. But having an 'alternative name' might help students relate more easily to the concept behind.
We actually want to use a more layman term in our own database modeling tool, so that first-time users without much computer science background could learn faster.
cheers!
I often see child table or dependent table used as a lay term. You could use either of those terms for a table with an identifying relationship
Then say a referencing table is a table with a non-identifying relationship.
For example, PhoneNumbers is a child of Users, because a phone number has an identifying relationship with its user (i.e. the primary key of PhoneNumbers includes a foreign key to the primary key of Users).
Whereas the Users table has a state column that is a foreign key to the States table, making it a non-identifying relationship. So you could say Users references States, but is not a child of it per se.
I think belongs to would be a good name for the identifying relationship.
A "weak entity type" does not have its own key, just a "partial key", so each entity instance of this weak entity type has to belong to some other entity instance so it can be identified, and this is an "identifying relationship". For example, a landlord could have a database with apartments and rooms. A room can be called kitchen or bathroom, and while that name is unique within an apartment, there will be many rooms in the database with the name kitchen, so it is just a partial key. To uniquely identify a room in the database, you need to say that it is the kitchen in this particular apartment. In other words, the rooms belong to apartments.
I'm going to recommend the term "weak entity" from ER modeling.
Some modelers conceptualize the subject matter as being made up of entities and relationships among entities. This gives rise to Entity-Relationship Modeling (ER Modeling). An attribute can be tied to an entity or a relationship, and values stored in the database are instances of attributes.
If you do ER modeling, there is a kind of entity called a "weak entity". Part of the identity of a weak entity is the identity of a stronger entity, to which the weak one belongs.
An example might be an order in an order processing system. Orders are made up of line items, and each line item contains a product-id, a unit-price, and a quantity. But line items don't have an identifying number across all orders. Instead, a line item is identified by {item number, order number}. In other words, a line item can't exist unless it's part of exactly one order. Item number 1 is the first item in whatever order it belongs to, but you need both numbers to identify an item.
It's easy to turn an ER model into a relational model. It's also easy for people who are experts in the data but know nothing about databases to get used to an ER model of the data they understand.
There are other modelers who argue vehemently against the need for ER modeling. I'm not one of them.
Nothing, absolutely nothing in the kind of modeling where one encounters things such as "relationships" (ER, I presume) is "technical", "precise" or "unambiguous". Nor can it be.
A) ER modeling is always and by necessity informal, because it can never be sufficient to capture/express the entire definition of a database.
B) There are so many different ER dialects out there that it is just impossible for all of them to use exactly the same terms with exactly the same meaning. Recently, I even discovered that some UK university that teaches ER modeling, uses the term "entity subtype" for the very same thing that I always used to name "entity supertype", and vice-versa !
One could use connection.
You have Connection between two tables, where the IDs are the same.
That type of thing.
how about
Association
Link
Correlation