So, I've read a whole lot of answers here on stackoverflow, but I'm still confused about the whole concept thereof. Specifically, I've gone over this article (including all the ones it references), but can't seem to find a solid grasp on the concept (or perhaps it is my confusion between cardinality (n:m, etc.) and identities):
Still Confused About Identifying vs. Non-Identifying Relationships
My issue is this: I know that identifying relationships imply that the primary key of a child entity must include its foreign key, and that the opposite is true for non-identifying relationships (Is this correct?). Now, this seems a bit too "forward thinking" to me? The same was also said in one of the comments in one of the links. How can I "take a step back" and actually see which relations are of which identity?
For example, I have two dilemmas:
job_title (parent, 1) to employee (child, 1..*). Am I right in thinking that, because job_title is a lookup table, it must be a non-identifying relation? Or would it be more accurate in saying that "an employee can't exist without a job_title, thus it must be identifying"? Or would it be the relationship defining that scenario?
employee to employee_equipment (bridging entity between the m:n cardinality) to equipment. Now, I read that this has to be an identifying relationship on both sides of employee_equipment. But, what if an employee doesn't NEED equipment? Can one have an optional identifying relationship?
I guess that I'm really looking for a way to identify which identity tables should belong to, without thinking of primary/foreign keys, or anything really technical for that matter.
Any help would be much appreciated!
You are over-thinking the linkage between optionality and identity. Until the whole thing comes more naturally to you, it's best to think of them as being completely unrelated.
About optionality, it is important to remember that the optionality is directional. To use your example of employee_equipment: Sure, employees don't need equipment. The one-to-many relationship from employee to employee_equipment is optional. At the same time, looking at it from the opposite perspective, the relationship is mandatory. You can't have a record in employee_equipment unless there is an employee to associate it with.
Identity has nothing to do with optionality, except coincidentally an identifying relationship is mandatory from the child to the parent. Whether it is also mandatory from the parent to the child is neither here nor there as far as identity is concerned.
What makes a relationship identifying is that you have to know what parent you are talking about (as well as some other things) in order to know what child you are talking about. That is, the primary key of the child must include a foreign key to the parent.
Pure intersection tables (e.g. employee_equipment) are good examples of this. The primary key of a pure intersection is the combination of the foreign keys to both parent tables. Note that some people may also add a surrogate key to these kinds of tables. It doesn't matter so much from an identity perspective if there are multiple candidate keys. What is important in determining identity is whether the foreign key is part of a candidate key, whether or not that candidate key happens to be the primary key.
Another good example would be something like a database's metadata catalog, where a column is identified by the table to which it belongs, just as the table is identified by the schema it is in, and so on. Knowing that a column is called NAME doesn't tell you which column it is. Knowing that it is the NAME column in the CUSTOMER table helps. (You'll also have to know which schema CUSTOMER is in, and so forth).
Joel has provided a good answer (+1 to him), let me just offer a small mental shortcut that you can use when thinking about identifying relationships... just ask yourself:
Can I achieve uniqueness only with the attributes of the child entity?
If no, and you need to include the attributes migrated from the parent into the child key to make it unique, then you have an identifying relationship1. It's about identification-dependence, not existence-dependence2!
You might be interested in this post for some more musings on the topic.
1 And the child entity is "weak" or "dependent".
2 Although identification-dependence usually implies existence-dependence.
Related
I will make an ERD, but from some examples from the tutorials that I have read are different and they do not explain conditions so that the relationship stands between 2 entities?, Is it because their relationship in the real world is like that? or because they have interconnected keys ?
Well, imagine relations like in real life. A child, the parents and the grandparents are multiple relationships. You can set up the database to show the biological relations, so you receive an error when trying to delete a parent/grandparent or you can set up the database to show the current/cultural relations so deleting/switching a parent/grandparent would work without deleting the child.
A child may have a foreign key referring to a parent, which becomes NULL after deleting the parent or prevents the deletion entirely. Some (mostly older) databases don’t check for that, so you could end up with a child referring a non existing parent but this would be considered a corrupt data entry.
I'm using mySQL, and have such schema structure
Table Mark has refrences to date, student, subject, and teacher
and table teacher has many to many with subject.
So there is a mark-subject-tache circular refrence.
Is it acceptable, and how to avoid it if not?
Post is old but possibly this answer will help someone.
Normally, one needs to avoid circular references as this will create more problems later e.g. you won't be able to delete without making references null. Anyway, in some cases, you can have the circular references to make design compact.
In your case, you can treat Subject entity as master entity i.e. Subject will have its own independent lifecycle. By doing so, you will have many-to-one relationship from Mark to Subject and one-to-many unidirectional relationship from Teacher to Subject (this will require a link table between Teacher and Subject).
I have two tables currently with the same primary key, can I have these two tables with the same primary key?
Also are all the tables in 3rd normal form
Ticket:
-------------------
Ticket_id* PK
Flight_name* FK
Names*
Price
Tax
Number_bags
Travel class:
-------------------
Ticket id * PK
Customer_5star
Customer_normal
Customer_2star
Airmiles
Lounge_discount
ticket_economy
ticket_business
ticket_first
food allowance
drink allowance
the rest of the tables in the database are below
Passengers:
Names* PK
Credit_card_number
Credit_card_issue
Ticket_id *
Address
Flight:
Flight_name* PK
Flight_date
Source_airport_id* FK
Dest_airport_id* FK
Source
Destination
Plane_id*
Airport:
Source_airport_id* PK
Dest_airport_id* PK
Source_airport_country
Dest_airport_country
Pilot:
Pilot_name* PK
Plane id* FK
Pilot_grade
Month
Hours flown
Rate
Plane:
Plane_id* PK
Pilot_name* FK
This is not meant as an answer but it became too long for a comment...
Not to sound harsh, but your model has some serious flaws and you should probably take it back to the drawing board.
Consider what would happen if a Passenger buys a second Ticket for instance. The Passenger table should not hold any reference to tickets. Maybe a passenger can have more than one credit card though? Shouldn't Credit Cards be in their own table? The same applies to Addresses.
Why does the Airport table hold information that really is about destinations (or paths/trips)? You already record trip information in the Flights table. It seems to me that the Airport table should hold information pertaining to a particular airport (like name, location?, IATA code et cetera).
Can a Pilot just be associated with one single Plane? Doesn't sound very likely. The pilot table should not hold information about planes.
And the Planes table should not hold information on pilots as a plane surely can be connected to more than one pilot.
And so on... there are most likely other issues too, but these pointers should give you something to think about.
The only tables that sort of looks ok to me are Ticket and Flight.
Re same primary key:
Yes there can be multiple tables with the same primary key. Both in principle and in good practice. We declare a primary or other unique column set to say that those columns (and supersets of them) are unique in a table. When that is the case, declare such column sets. This happens all the time.
Eg: A typical reasonable case is "subtyping"/"subtables", where entities of a kind identified by a candidate key of one table are always or sometimes also of the kind identifed by the same values in another table. (If always then the one table's candidate key values are also in the other table's. And so we would declare a foreign key from the one to the other. We would say the one table's kind of entity is a subtype of the other's.) On the other hand sometimes one table is used with attributes of both kinds and attributes inapplicable to one kind are not used. (Ie via NULL or a tag indicating kind.)
Whether you should have cases of the same primary key depends on other criteria for good design as applied to your particular situation. You need to learn design including normalization.
Eg: All keys simple and 3NF implies 5NF, so if your two tables have the same set of values as only & simple primary key in every state and they are both in 3NF then their join contains exactly the same information as they do separately. Still, maybe you would keep them separate for clarity of design, for likelihood of change or for performance based on usage. You didn't give that information.
Re normal forms:
Normal forms apply to tables. The highest normal form of a table is a property independent of any other table. (Athough you might choose that form based on what forms & tables are alternatives.)
In order to normalize or determine a table's highest normal form one needs to know (in general) all the functional dependencies in it. (For normal forms above BCNF, also join dependencies.) You didn't give them. They are determined by what the meaning of the table is (ie how to determine what rows go in it in any given situation) and the possible situtations that can arise. You didn't give them. Your expectation that we could tell you about the normal forms your tables are in without giving such information suggests that you do not understand normalization and need to educate yourself about it.
Proper design also needs this information and in general all valid states that can arise from situations that arise. Ie constraints among given tables. You didn't give them.
Having two tables with the same key goes against the idea of removing redundancy in normalization.
Excluding that, are these tables in 1NF and 2NF?
Judging by the Names field, I'd suggest that table1 is not. If multiple names can belong to one ticket, then you need a new table, most likely with a composite key of ticket_id,name.
Asked this here a couple of days ago, but haven't gotten many views, let alone a response, so I'm reposting to stackoverflow.
I'm modeling a DB for a conference ticketing system. In this system attendees are members of an attendee group, which belong to a conference. These relationships are identifying, and therefore FKs must be PKs in the respective children.
My current model:
Q: Is it proper to have attendeeGroupConferenceId FK, as a PK, in the attendee table, as MySQL Workbench has automatically set up for me?
On one side one would get a performance boost by keeping it in there for quick association at "check in". However, it does not strictly necessary since the combination of id, attendeeGroupId, and a corresponding lookup of conferenceId in the respective attendeeGroup table, is enough. (Therefore becomes redundant data.)
To me, it feels like it might violate some form of normalization, but I plan on keeping it in for the speed boost as described. I'm just curious about what proper design says about giving it PK status or not.
You definitely don't need the attendeeGroupConferenceId in your attendee table. It's redundant and notice that candidate key is the combination of (attendeeGroupId, personId), not the attendeeGroupConferenceId alone.
The table attendee also seems to violate the Second normal form (2NF) as it is.
My suggestion is to remove the attribute attendeeGroupConferenceId. In any case you can just join the tables in your queries to get extra info rather than keeping an extra attribute.
I've read this question: What's the difference between identifying and non-identifying relationships?
But I'm still not too sure...
What I have is three tables.
Users
Objects
Pictures
A user can own many objects and can also post many pictures per individual object.
My gut feeling tells me this is an identifying relationship, because I'll need the userID in the objects table and I'll need the objectID in the pictures tables...
Or am I wrong? The explanations in the other topic limit themselves to the theoretical explanation of the way the database interprets it after it's already been coded, not how the objects are connected in real life. I'm kinda confused as to how to make the decision of identifying versus non-identifying when thinking about how I'm going to build the database.
Both sound like identifying relationships to me. If you have heard the terms one-to-one or one-to-many, and many-to-many, one-to- relationships are identifying relationships, and many-to-many relationships are non-identifying relationships.
If the child identifies its parent, it is an identifying relationship. In the link you have given, if you have a phone number, you know who it belongs to (it only belongs to one).
If the child does not identify its parent, it is a non-identifying relationship. In the link, it mentions states. Think of a state as a row in a table representing mood. "Happy" doesn't identify a particular person, but many people.
Edit: Other real life examples:
A physical address is a non-identifying relationship, because many people may reside at one address. On the other hand, an email address is (usually considered) an identifying relationship.
A Social Security Number is an identifying relationship, because it only belongs to one person
Comments on Youtube videos are identifying relationships, because they only belong to one video.
An original of a painting only has one owner (identifying), while many people may own reprints of the painting (non-identifying).
I think that an easier way to visualize it is to ask yourself if the child record can exist without the parent. For example, an order line item requires an order header to exist. Thus, an order line item must have the order header identifier as part of its key and hence, this is an example of an identifying relationship.
On the other hand, telephone numbers can exist without ownership of a person, although a person may have several phone numbers. In this case, the person who owns the phone number is a non-key or non-identifying relationship since the phone numbers can exist irrespective of the owner person (hence, the phone number owner person can be null whereas in the order line item example, the order header identifier cannot be null.
NickC Said: one-to- relationships are identifying relationships, and many-to-many relationships are non-identifying relationships
The explanation seems totally wrong to me. You can have:
Ono-to-One Non-identifying Relationships
One-to-Many Non-identifying Relationships
One-to-One Identifying Relationships
One-to-Many Identifying Relationships
Many-to-Many Identifying Relationships
Imagine you have the following tables: customer, products and feedback. All of them are based on the customer_id which exists on the cutomer table. So, by NickC definition there shouldn't be exists any kind of Many-to-Many Identifying Relationships, however in my example, you can clearly see that: A Feedback can exists only if the relevant Product exists and has been bought by the Customer, so Customer, Products and Feedback should be Identifying.
You can take a look at MySQL Manual, explaining how to add Foreign Keys on MySQL Workbench as well.
Mahdi, your instincts are correct. This is a duplicate question and this up-voted answer is not correct or complete.
Look at the top two answers here:
difference between identifying non-identifying
Identifying vs non-identifying has nothing to do with identity.
Simply ask yourself can the child record exist without the parent? If the answer is yes, the it is non-identifying.
The core issue whether the primary key of the child includes the foreign key of the parent. In the non-identifying relationship the child's primary key (PK) cannot include the foreign key (FK).
Ask yourself this question
Can the child record exist without the parent record?
If the child can exist without the parent, then the relationship is non-identifying. (Thank you MontrealDevOne for stating it more clearly)
One-to-one identifying relationship
Social security numbers fit nicely in to this category. Let's imagine for example that social security numbers cannot exist with out a person (perhaps they can in reality, but not in our database) The person_id would be the PK for the person table, including columns such as a name and address. (let's keep it simple). The social_security_number table would include the ssn column and the person_id column as a foreign key. Since this FK can be used as the PK for the social_security_number table it is an identifying relationship.
One-to-one non-identifying relationship
At a large office complex you might have an office table that includes the room numbers by floor and building number with a PK, and a separate employee table. The employee table (child) has a FK which is the office_id column from the office table PK. While each employee has only one office and (for this example) every office only has one employee this is a non-identifying relationship since offices can exist without employees, and employees can change offices or work in the field.
One-to-many relationships
One-to-many relationships can be categorized easily by asking the same question.
Many-to-many relationships
Many-to-many relationships are always identifying relationships. This may seem counter intuitive, but bear with me. Take two tables libary and books, each library has many books, and a copy of each book exists in many libraries.
Here's what makes it and identifying relationship:
In order to implement this you need a linking table with two columns which are the primary keys of each table. Call them the library_id column and the ISBN column. This new linking table has no separate primary key, but wait! The foreign keys become a multi-column primary key for the linking table since duplicate records in the linking table would be meaningless. The links cannot exist with out the parents; therefore, this is an identifying relationship. I know, yuck right?
Most of the time the type of relationship does not matter.
All that said, usually you don't have to worry about which you have. Just assign the proper primary and foreign keys to each table and the relationship will discover itself.
EDIT: NicoleC, I read the answer you linked and it does agree with mine. I take his point about SSN, and agree that is a bad example. I'll try to think up another clearer example there. However if we start to use real-world analogies in defining a database relationship the analogies always break down. It matters not, whether an SSN identifies a person, it matters whether you used it as a foreign key.