Suppose that I have a table users, with a PK id_user.
I also have an identifying relationship between the table users and the table employer. I can use the PK id_user as foreign key in the table employer and also as PK (with unique constrain) in this table?
In this case, the employer only have a worker and a worker only have an employer.
Short answer: Yes. When a foreign key is also the primary key of the child table it forces it into a one-to-one.
Longer answer: in my experience every 1-to-1 I've every made has been expanded later into a 1-to-many or many-to-many, as the users' requirements are better understood. Example: You end up needing a history of employers, so suddenly you have a many-to-many from persons to employers with effective dates.
After this happened a few times I made it a point to dig into the reasons why a 1-to-1 seemed to make sense, and always found it did not. So much so that I made a rule of thumb for myself to avoid 1-to-1 tables, as they usually indicate an incomplete understanding of requirements.
Primary keys are special unique keys. In this case I would not link worker in the employers table as typically an employer has more then one worker. If you're absolutely sure it is a one-one relation, I do not see why you use 2 tables, instead of one. Meaning, add the employer fields to the worker table. A real one-one relation is for example a phone number or email address and typically they are stored with the owner, not in a seperate table.
Related
I have two tables: students and courses, assuming that each student can be in more than one course and that each course can have more than one student.
[Table Students] [Table Courses]
id(PK) id(PK)
name name
age duration
etc... etc...
and what I want to do it is to relate both tables into another table, for example, studying, in which I will store the course or courses that is doing each student. Like this:
[Table studying]
idStudent
idCourse
What I have deduced
I think that idStudent and idCourse should be foreign keys because the information it is stored in students and courses respectively with an unique primary key and to respect the consistency of the database. It cannot exist a relation without information neither of the student nor the course or just without the information of one of them.
I also know that some tables has two primary keys to allow that in the table could exist more than one repeated value of a primary key, but not of both primary keys at the same time.
My questions
These ids (idStudent, idCourse). Have to be primary keys or foreign keys?
Should the table studying has another column with an ID?
Is my deduction in the good way?
P.S: I do not need sql statements, I just need help to clarify my confusion.
Thanks in advance!
These ids (idStudent, idCourse). Have to be primary keys or foreign keys?
You want them to be foreign keys, because the existence of each record on your third table depends on the availability of the first, that is, there cannot be a "Student Course" or a "Course with Students" without either the course or the student. It could (if you don't make those keys) but you would break referential integrity
On the other hand, having FK's is usually a good thing because you make sure that you don't remove dependable records by mistake (which is what the constraint is for on the first place) unless you did something like cascade deleting
Should the table studying has another column with an ID?
No, it does not have to but again, sometimes it is a good practice because some software like Object Relational Mappers, Diagram Software, etc. may rely on the fact that they always needs a by-convention primary key. Some others don't even support composite keys so while it is not mandatory it can help in the future and it does not hurt. Of course this all depends on what you are using the database for and how (pure SQL, which engine you use, if you use it with a framework etc.)
Is my deduction in the good way?
All is relative. But I think your logic is good. My advice is that you always design your data schemas as flexible as you can because if a project grows its harder (and more costly) to do those changes down the road. Invest time on thinking how you may expand your application functionality and think if the schema will adapt to it.
Your deduction is correct.
In fact, you should have a composite primary key consisting of both (idStudent, idCourse) columns, because this tuple is the identifier of row in the table, you do not need additional ID column (of course, you can also take that approach to add additional ID column that would be your primary key, but you do not need it if one student can have one course assigned only once)
To respect the integrity, both columns (separately) should be foreign keys - idStudent should be referencing id column of Students table and idCourse should reference id column of Courses table.
If you like you can make them primary keys on studying table. But this is unnecesary, because relation (role of studying table) is many to many and this kind of table dont need primary keys. You need to know that also when you make them pk (pair of student id and course id) , thats mean that theee could be only one pair of each, thats equivalent to constrain unique - student can take a course only ones. In the future you maybe would like to add to this table start_date and this kind of pk could be a problem, you will need to modify them.
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.
I'm using MySQL and have been planning out the database structure for a system I'm building out. As I've been going along, I started to wonder if it was acceptable to have a particular foreign key constraint in many different tables. From what I understand, it would be fine, as it makes sense. But I'd like to double check.
For example, I have a users table, and I use the user_id as a foreign key for many tables, sometimes multiple times in one table. For example, I have a one-to-one relationship with a user_settings table, which of course stores the user_id. And then I have a companies table, which alone has a few references to the user_id key. In this case, I have a column that keeps track of the user that created the company in the system (created_by), a column for the main contact (main_contact, who is also a user of the system), and there might be another reference. So that alone, already has the user_id key being used as a foreign key constraint 3-4 times.
Just to add another bit of info, I have a tasks table and that of course needs to reference the user_id to keep track of who it's assigned to, and I also have another column that keeps track of the user that created the task. That would be assigned_to and created_by, respectively.
There are more tables though that reference back to that key. I might be up to 8 references already. I do believe I've designed it properly so far, but based on what I've mentioned, does this sound fine?
Your foreign key usage seems fine to me - after all, you are simply representing logical relationships between your tables.
A user within your system interacts with the data in many ways, and to define these relationships your approach is the correct one.
The key point I think is that under a lot circumstances, you won't always want (or need) to make all the joins that represent your relationships - simply the ones that you need in that context.
As per my undestanding the way you are defining is fine i.e to use a user id to many tables as foreign key.
If your line:: I have a companies table, which alone has a few references to the user_id key doesn't mean that you are using multipe user_id in same table and I know you are not.
Question
Is there a way to have a many-to-many relationship among 3 tables without the use of automatic incrementers (usually ID), or are ID's required for this?
Why I ask
I have 3 relative tables. Since one-to-one relationships seem to can't happen directly, I made a 4th to do one-to-many relationships to the other 3 tables. However, since there's still a primary key to each table, a value can only be used once in a table, which I don't want to happen.
What I have
Connectors has multiple Pockets which have multiple pins.
The 4th Table is ConnectorFullInfo
There is no requirement that a table have an "automatic incrementer" as a primary key.
But, a familiar pattern is to add a surrogate ID column as primary key on entity tables. The "ideal" primary key will be "anonymous" (carry no meaningful information), "unique" (no duplicate values), "simple" (single column, short simple native datatype), ...
There are a couple of schools of thought on whether it's a good idea to introduce a surrogate key. I will also note that there are those who have been later burned by the decision to use a natural key rather than a surrogate key. And there are those that haven't yet been burned by that decision.
In the case of "association" tables (tables introduced to resolve many-to-many relationships), the combination of the foreign keys can be used as the primary key. I often do this.
BUT, if the association table is itself turns out to be entity table, with it's own attributes, I will introduce a surrogate ID column. As an example, the association between person and club, a person can be a member of multiple clubs, and a club can have multiple members...
club +--< membership >--+ person
When we start adding attributes to membership (such as status, date_joined, office_held, etc... at that point membership isn't just an association table; it's turning into an entity. When I suspect that an association is actually an entity, so I'll add the surrogate ID column.
The other case where I will add a surrogate ID column to an association table is when we want to allow "duplicates", where we want to allow multiple associations. In that case, I will also introduce a surrogate ID column.
Yes you can but,
It is customary to represent a table row by a unique identifier which is the number, its becomes more efficient.
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.