If I have two entities, "Courses" and "Course_offerings", and they both have a key called "course number" , how do I relate these two entities? A relationship table does not make sense because it would be mapping the same course number to the same course number, which is redundant. But leaving them unlinked seems wrong. What is the correct way to do this for the ER model?
What would an ER diagram for this look like?
Related
I just read this: What's the difference between identifying and non-identifying relationships?
And the example for a non-identifying relationship there sounds like it should be a many to many table. One person can have multiple states and one state can be used by many persons.
And I can't really think of an example where a non-identifying relationship should not be a ManyToMany relationship.
So, can someone elaborate on this? Because I can't come up with any examples that go against this.
EDIT:
For example, an identifying relationship would be an appletree having apples. Those apples got spawned because of the appletree. So the appletree has many apples but each apple belongs only to that one tree.
A non-identifying OneToMany relationship would then have to have something that spawned independently, but can only ever belong to one other thing. Because if it belongs to multiple things that themselves have multiple instances...
Hang on I just realized the case where the instance A can have only one instance of B but one B can be linked to multiple A's, while B got created independently.
Case closed I guess.
non-identifying OneToMany relationship, is a OneToMany relationship.
On the other side:
A identifying OneToMany relationship could be inverted into a OneToOne relationship.
Example:
Person X has phonenumber 123456. Although in the table "Phones" many phonenumbers are present, phonenumber 123456 is probably only present once. So this phonenumber identifies person X.
Although Person X can have multiple phones, the "Many" side is almost a unique identifier and thus a sort of "one-to-one" relationship.
Example of Non-identifying:
Person X lives in Canada. If you search on Canada, you will find many persons (probably). But if you revert this query, a lookup on Canada, it's not a manytomany, but a onetomany relationship.
How do we translate something like this into SQL?
Entity A -thick line- relation -simple line- Entity B
Its easy enough to write any of the other connections, but somehow I can't seem to figure it out when it comes to 1 thick line and a simple one, like shown aboove
I have a primary key which is the date of a football season (Entity A - Season) and an entity (Entity B - Football team) which has 2 primary keys which are it's name and primary key of the Season entity. But 'cause of that doubt I have I can't relate them properly.
Relations do not typically form independent tables (diamonds). However, for a many-many relationship, you will usually see them in a separate tables. Depending on your notation (there are many) your diagram could represent a many-many relationship or a 1:1 relationship.
Strong entities (your rectangles) get tables.
In your ER diagram, you will also typically see attributes for each table in circles connected by lines to the entity itself. Those attributes are turned into columns for each table. Attributes which are underlined in the diagram are representative of a primary key for a particular entity.
Additional or strange constraints that aren't typically easily represented in an ER diagram are usually put as side notes.
To answer your question, you must know whether or not it's a many-many relationship; if so, you would create a SeasonClub table with the two different primary keys inside it.
Why is it that a lot of people are referring to One-to-One when I am sure they are referring to Many-to-one?
For instance, if you have two tables;
Inventory (InventoryID)
Item (ItemID, InventoryFK)
There is no one-to-one mapping here as far as I can tell. It's "Many items to one inventory".
Now, let's assume that there would be only one item per inventory. In this case, my colleagues would start calling it a "one-to-one". Am I correct in pointing out that it's still a many-to-one relationship? When I try to explain this to them they don't seem to understand.
I believe a proper one-to-one mapping to be something like this:
Person (Column: PersonID, Name)
PersonAddress (Column: PersonID, StreetName, StreetNumber)
Here you'd have two tables, sharing the exact same PK.
Assuming my assumptions are correct, why are so many people abusing the term "one-to-one"?
The one-to-many and one-to-one relation are implemented in a slightly different way.
One-to-many
Object (objectId) ObjectCharacteristics(charId,objectId)
One-to-one
The order of the table is not important:
Husband (husbandId) Wife(wifeId,husbandId) + unique constraint on husbandId
N.B. One-to-many relation is also a one-to-one relation in the order way. The ObjectCharacteristics has one and only one object.
But you are right the relationship is a concept that does not depend upon the specific data in your database but only on the structure of it.
I agree these terms are much abused. But who of us isn't guilty? Without knowing the constraints involved, your example of what you believe to be a one-to-one relationship could be a one-to-zero-or-one relationship (hint: the presence of a foreign key does not imply the presence of actual referencing values).
Chris Date wrote a very thorough analysis of the situation in his paper All for One, One for All.
I often see "linking" tables for M:N relationship, where N can be 1..X types of entities/classes, so that the table contains classNameId referring to ClassName table and classPK referring to the particular Entity table.
How is this called ? Does it have an alternative with the same effect without having the EntityName table ?
In the ER model, entities and subentities can be related by inheritance, the same way classes and subclasses are in an object model. The problem comes up when you transform your ER model into a relational model. The relational model does not support inheritance as such.
The design pattern is called is called generalization-specialization or gen-spec for short. Unfortunately, many database tutorials skip over how to design tables for a gen-spec situation.
But it's well understood.It looks quite different from your model, but you could create views that make it look like your model if necessary. Look up "generalization specialization relational modeling" for explanations of how to do this.
The main trick is that the specialized tables "inherit" the value of their primary key from the PK of the generalized table. The meaning of "inherit" here is that it's a copy of the same value. Thus the PK in each specialized table is also an FK link back to the correpsonding entry in the generalized table.
Me and a database architect were having argument over if a table with a compound primary key with subtypes made sense relationally and if it was a good practice.
Say we have two tables Employee and Project. We create a composite table Employee_Project with a composite primary key back to Employee and Project.
Is there a valid way for Employee_Project to have subtypes? Or can you think of any scenario where a composite key table can have subtypes?
To me a composite key relationship is a 'Is A' relationship (Employee_Project is a Employee and a Project). Subtypes are also a 'Is A' relationship. So if you have a composite key with a subtype its two 'Is A' relationships in one sentence which makes me believe this is a bad practice.
Employee-project is a bit hard, but one can imagine something like this -- although I'm not much of a chemist.
Or something like this, which would require different legal forms (fields) for single person ownership vs joint (time-share).
Or like this, providing that different forms are needed for full time and temp.
Employee projects have subtypes if the candidate subtypes are
not utterly different, but
not exactly alike
That means that
Every employee project has some
attributes (columns) in common. So they're not utterly different.
Some employee projects have different
attributes than others. So they're not exactly alike.
The determination has to do with common and distinct attributes. It doesn't have anything to do with the number of columns in a candidate key. Do you have employee projects that are not utterly different, but not exactly alike?
The most common business supertype/subtype example concerns organizations and individuals. They're not utterly different.
Both have addresses.
Both have phone numbers.
Both can be plaintiffs and defendants
in court.
But they're not exactly alike.
Individuals can go to college.
Organizations can have a CEO.
Individuals can get married.
Individuals can have children.
Organizations (in the USA) can be liquidated.
So you can express individuals and organizations as subtypes of a supertype called, say, "Parties". The attributes all the subtypes have in common relate to the supertype.
Parties have addresses.
Parties have phone numbers.
Parties can be plaintiffs and defendants
in court.
Again, this has to do with attributes that are held in common, and attributes that are distinct. It has nothing to do with the number of columns in a candidate key.
To me a composite key relationship is
a 'Is A' relationship
(Employee_Project is a Employee and a
Project).
Database designers don't think that way. We think in terms of a table's predicate.
If an employee can have many projects and a project can have many employees it is a many-to-many join that RDBM's can only represent easily in one way (the way you have outlined above.) You can see in the ER diagram below (employee / departments is one of the classic many-to-many examples) that it does not have a separate ER component. The separate table is a leaky abstraction of RDBMS's (which is probably why you are having a hard time modeling it).
http://www.library.cornell.edu/elicensestudy/dlfdeliverables/fallforum2003/ERD_final.doc
Bridge Entities
When an instance of an entity may be related to multiple instances of another entity and vice versa, that is called a “many-to-many relationship.” In the example below, a supplier may provide many different products, and each type of product may be offered by many suppliers:
While this relationship model is perfectly valid, it cannot be translated directly into a relational database design. In a relational database, relationships are expressed by keys in a table column that point to the correct instance in the related table. A many-to-many relationship does not allow this relationship expression, because each record in each table might have to point to multiple records in the other table.
http://users.csc.calpoly.edu/~jdalbey/205/Lectures/ERD_image004.gif
Here they do not event bother with a separate box although they add in later (at this step it is a 'pure' ER diagram). It can also be explicitly represented with a box and a diamond superimposed on each other.