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.
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.
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.
I am trying to show the following in the ER diagram:
There are instructors and courses, a course is taught by only one instructor
whereas an instructor can give many courses.
My question is, is there any difference between two diagrams, in other words, does it matter which line we turn into an arrow, or what only matters is only the direction of the arrow?
Also, if we think about the mapping cardinalities; is it 1 to many or many to 1? If we think in terms of courses, then it is many to one but if we think in terms of instructors, then it is one to many. How do we decide this?
Thank you.
In ER diagrams when the relationship is denoted the arrows are not used. Some instructors use this arrow when they want to decide the cardinalities but that is just to get the cardinality (1:1, 1:M and N:M)
I have attached the ER diagram for this in Chen notation and also using Crow Notation you can use either of them.
Deciding the cardinality for a relationship is a practical scenario there is no hard and pass rule to obtain it. What you need to do is start from one side of the relationship and take one tuple (instance) and see how many tuples from the other entity participate for the relationship. Then do the vise versa. Then you know the participation number of tuples) from each entity to the relationship. Think about set theory and functions in mathematics when you decide the cardinality (ie Set of instructors, Set of Courses and set of Teaches relationship type) then this is so easy but if you are not from a mathematic background just think of practical scenario.
For Example
a) For 1 instructor he or she can teach Many (M) courses
b) For 1 Course there is only 1 instructor
so in instructor side there is always 1 in a) and b) but in Courses there is M and 1 in a) and b) there for Instructor:Course cardinality is 1:M
I don't think the other answer is fully correct.
I would say that one should use arrows, and one should use a notation that gives a meaningful name to each direction of the relationship. In this case it will be "teaches" in one direction, and "is taught by" in the other. Either use arrows next to the names or put the name near to the entity to which it refers. You could use one line (with two arrow heads) or two lines (with one arrow each).
I would also suggest that cardinality is just one kind of constraint, and the notation should reflect that. For example, the two names for the relationship could be "teaches (many)" and "is taught by (exactly one)". The point is you might have "teaches (one or two)" or "is taught by (exactly two)" and so on.
It is better to be explicit and clear about exactly what your constraints really are.
Both are having exactly opposite cardinality
🔸Simple clean line means many.
🔸Arrow means one.
If we consider both with same cardinality.
then, many to many should be represented by following the second convention as (please assume diamond for relationship set and rectangle for entity set)
INSTRUCTOR <---- TEACHES -----> COURSE
which is actually of no meaning.
If we consider both with opposite cardinality.
then, many to many should be represented by following the second convention as (please assume diamond for relationship set and rectangle for entity set)
INSTRUCTOR ----- TEACHES ------ COURSE
No explicit arrow is always considered many to many. So, it is correct (only if we consider both opposite)
Consider an 'employee' entity set and 'department' entity set, having relationship set as 'manage'.
Employee-------------Manage--------------------Department
(entity set) (Relationship set) (entity set)
One to many relationship means one entity of employee set can be associated with more than one entity of Department entity set but, an entity of Department set can be associated with at most one entity of employee entity set.
That means if there is one to many relationship between employee and department entity sets, then each employee can manage more than one department and at the same time each department is managed by at most one employer.
I have to create an ER diagram based on a relational schema.
There is a table of players, and a table of zones. A player can 'live' in many zones, and each zone is owned by one or more players.
I've come up with this simple ER diagram but I'm not sure having relationships going each way is allowed?
Cheers
Yes, that is a perfectly good Entity Relation Diagram. (I am not responding as to whether it makes sense or not: you still need to resolve the Relations and Cardinality.)
Using the correct terms helps people understand exactly what you are discussing, and which level you are discussing. Loose talk results in much more volume in the discussion, and time wasted in clarifying what you meant by which term. Not good for productive technical endeavours.
At this early stage, it is normal to model Entities and Relations (not Attributes), that's why it is called an ER diagram; we are nowhere near modelling the data. The Relations are relevant, and that's why you are detailing and evaluating their nature in the diamonds and Cardinality. The goal is to clarify the true Entities, and their Relations to each other. Many-to-many relations remain as relations. The ERD is purely Logical, there is no Physical.
Once you have some confidence with that, that you have gotten the Entities and Relations right, you move onto a Data Model (which includes Attributes). Still at a Logical level, the n::n relations remain as relations.
As you progress, you may show further detail, such as Domain for each Attribute. That's the DataType, but at the Logical level, just as the terms are Entity = Table and Attribute = Column, Domain = DataType.
.
When you get to the Physical level, the Data Model has Tables; Columns; DataTypes.
And n::n Relations are manifested as the Associative Tables.
.
The idea is, as long as you are working through the prescribed steps, at (1), the content in the diamonds will determine (expose) if they need to be stored, and the diamond is thus promoted to an Entity; otherwise it remains a Relation.
There is a junction table called lives-in in the relational schema I've been given. However, I thought when mapping a relational schema [back] to an ER diagram a junction table becomes a relationship?
The Relational term is Associative table.
Yes. If it is a pure n::n Table (containing nothing but the two FKs to the PKs of the parent Tables), at the ERD level, which is Logical only, it is a Relation.
If it has Columns other than the two FKs, it is an Entity.
Since there's a many-to-many relationship between [Players] and [Zones] you have to add a junction table (called for ex. [PlayersZones]). The notation itself is correct (Chen notation), though I prefer the Crow's Foot Notation.
I am not able to see your images (blocked!) so I'll just try to describe the "correct" design. If a player living in a zone doesn't necessarily mean they own it, you should have four tables:
PLAYER (playerid, <other fields>)
ZONE (zoneid, <other fields>
PLAYER_ZONE(playerid, lives_in_zoneid)
ZONE_OWNER (zoneid, owner_playerid)
Otherwise three tables would suffice.
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