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).
Related
Hello,
Having a massive difficulty converting a disjointed EER diagram to mysql
I believe the User entity has been setup correctly, just wondering how I would link User to a buyer/seller? Would I add a buyer/seller ID on the user then link that as a FK?
Here is mysql below.. Any help would be greatly appreciated, thanks
Your model shows that the subclasses Buyer and Seller are disjoint specializations of the User entity (A seller cannot be a buyer, and a buyer cannot be a seller) denoted by the circle with 'D'. Depending on your situation, you could challenge this design (can someone sell while having bought in the past?).
Each of these entities have different attributes not common to one another, except the ones shared by a User.
There are different ways of modeling this, but a what you might need for instance, is to have a Buyer table and Seller table. Both of these tables would then contain a foreign key to the User table.
A less normalized alternative is to have a User table that contains attributes from both subclasses, but then some of the attributes would be NULL if they're not applicable. They would then be distinguishable by a Role attribute.
Advised reading: Database Normalization
thanks for all your help, in the end I made buyer and seller tables with the same attributes and then linked them by foreign key back to the USER ID as otherwise I wouldn't have been able to access the attributes..
I have the following database schema:
t_class: Stores metadata about a class (primary key: class_ID)
t_students: linked to class by foreign key class_ID
t_exams: Stores metadata about an exam (no foreign keys so far)
t_grades: Links t_exams to t_students as the both having a n to m relationsship (has no primary key, but two foreign keys: exam_ID and student_ID). It also has the column grade which stores the result of each student in an exam.
The problem: It is possible that t_grades has no entries for a particular exam. With the current schema there's no way to get all exams of a class if t_grades has no entry.
My solution:
a) Add a key class_ID to t_exams. Downsides: It is more a less a redundant key and I can't add it as a foreign key (results in mysql error 1452)
b) Automatically add all students of a class to t_grades and just leave t_grades.grade empty. This feels very redundant as well.
Question: Is there a better way to solve this specific problem or should I stick with one of my solutions?
Create Code:
Sample database from this post
From the actual database I'm using (it's mostly German unfortunately
I really don't like the way you've graphed your database design, but I understand your problem.
In my opinion you should connect the t_exams directly to t_classes, since all students in a class should take the exam. So, that's your first solution.
In simple terms: A student belongs to a class, a class can get an exam, and an exam, a student took, can be graded.
This seems like a perfectly logical design to me. I don't get why you cannot implement this? I guess we need to see your CREATE TABLE queries?
I agree: My graph is also far from perfect, but just like with yours: I hope you get the idea.
Currently trying to get to grips with SQL for the first time, so I am working through a few problems. Here is a sample database spec:
Students (name, gender, course) do projects(title). Each project has
two supervisors (name, gender, department). All students do a project
but not all projects get taken. More than one student can do the same
project. Students meet one of their supervisors regular and these
meetings are recorded (date, time, student, supervisor, notes).
So far I've got an ER diagram drawn up which I think is correct:
I can get the basics (e.g. creating a Student table etc) but I'm having trouble getting my head around how to represent the relationships, specifically the meetings relationship, and how to represent it and its attributes in SQL. Should I instead create a 'meetings' entity?
Yes, you should create a Meeting entity to represent the many to many relationship between Student and Supervisor. In it you can relate to those tables using foreign keys that correspond to the those respective tables. In SQL it may look something like this:
Create table Meeting {
id INT NOT NULL PRIMARY KEY AUTO_INCREMENT,
student_id INT NOT NULL,
supervisor_id INT NOT NULL,
//rest of the fields...
FOREIGN KEY (student_id) REFERENCES Student(id)
FOREIGN KEY (supervisor_id) REFERENCES Supervisor(id)
}
You would also do the same thing for the Supervise between Project and Supervisor. Also you could use something called a composite key on your Meeting table, I guess it comes down to personal preference, I usually do it this way when representing many to many relationships. I'm not saying this is the syntax you will use, that depends on your database, this was just an example to point you in the right direction. Hope it helps.
Also for your diagram (I'm just guessing this is for a class) you might want to look into software such as visio or visual paradigm to create your ER diagram. While most people will be able to understand your current diagram, that's not correct modeling.
For fun I made a diagram based on your tables:
You would want an entity between Supervisor and Project if they are a many to many relationship. This is called an associative entity. I labeled mine SupervisorProject just so they are a little more clear.
Edit
Overlooked the fact that Student and project was a many to one, fixed that, sorry.
In response to Cohagen this stackoverflow post suggests that many to many relationships like Supervise can be represented by keeping the relationship table even if it has no attributes. In contrast the Do table lies between a many to one relationship and doesn't have attributes so we can get rid of it and simply add a foreign key reference to the project table in students.
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.
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.