If I have two different types of user, Parent and Child. They have identical fields, however a Child has a one to many relationship with exams, a relationship that does not exist for Parents.
Would Parent and Child best be modelled as a single table, or combined?
What if I have two different types of user, Parent and Child. They are the same apart from a child belongs to a school (a school has many children)
again, Would Parent and Child best be modelled as a single table, or combined?
They have identical fields, however a Child has a one to many relationship with exams
Even when fields are the same, different constraints1 means you are dealing with logically separate entities. Absent other factors, separate entities should be put into separate physical tables.
There may, however, be reasons to the contrary. For example, if there is a key that needs to be unique across parents and children combined, or there is another table that needs to reference all of them etc...
If that's the case, then logically both "parent" and "child" are inheriting from the "person", containing the common constraints (and fields). Such "inheritance" can be represented by either storing the whole hierarchy into a single table (and setting unused "portion" to NULL), or by separating all three "classes" into their own tables, and referencing the "base class" from "inherited classes", for example2:
PERSON_ID is unique across all parents and children. In addition to that, OTHER_TABLE can reference it directly, instead of having to separately reference PARENT_ID or CHILD_ID.
1 A foreign key in this case.
2 A very simplified model that just illustrates the point above and does not try to model everything you mentioned in your question
Parent and Child both are Persons without a doubt. You should never put them in seperate tables.
Only time separates them : what if a Child becomes a parent?
A parent easily can have children for that you need a relationship table.
Als a relationship table is the right way to model school membership.
so tables here :
person
is_child_of (many to many, join table) --> relations between persons can be is_parent_of
plain and simple
Remember : being a child is a relation from person to person.
How would you model a grandchild if needed? Yet another table? And a great grandchild?
And supose you are fine with that and you make a lot of tables for a lot of "kind of" relationships, an all of a sudden you want you have to add a field (day of birth) or alter a field format : you have to do it in all your different tables.
You have described three different entities in your question -- Parents, Child(ren), and Exams. You have shows how the three differ in the their relationships to each other.
From everything in your question, I would say that you have three entities and you should set them up as such in your database. That is, Parent and Child should have separate tables.
If the items are modeled differently in your system, I would say that they should be different tables. Just because parents and children both have similar properties (names, ages, etc.), does not mean they will always have the same relationships with other entities in your database. You could have parent and child be in same table with column relating child to parent, but this just leads to awkward self-join queries when trying to represent this relationship. This in itself can become very odd if a child has two parents. So to me you would have a number of different tables:
parent
child
child_to_parent (many-to-many join table)
school
child_to_school (one school to many children)
classes
child_to_classes (many-to-many)
classes_exams (one-to-many table relating exams to classes)
child_to_classes_exams (many-to-many table relating children to exams for specific classes)
* and maybe things like the following
teacher
teacher_to_classes (many-to-many)
Now certainly in your class design (if you are using OOP), you could have child and parent extend from a common "person" class which would handle logic for setting common properties.
I would break children out into a separate table for the simple reason that a parent may have many children (if not now, maybe in the future).
More than the current need, it is also important to consider what may happen in the future even if it doesn't make sense now. You may have two parent users who want to administrate one child and that child's exams.
Consider the most possible future functional requirements and program with them in mind.
Related
I am not a developer by any means, but I have a fairly good understanding of how relational databases work and the various types. I am trying to map a database design diagram (using Visio) and need to understand how I would represent the correct relationships in the correct way for a table which needs to reference Parent/Child categories.
As an example: A member/profile table linking to a product parent category table (referemce table containing 3 different product types) which also has 2 layers of sub categories for each parent as a tree like structure that drills down into more specific products. I understand the Parent/Child relationships but would I need to link the member/profile table to the Parent Category table (which inherently links to the child categories), or would I need to link the member/profile table to all three tables individually (parent and two child tables).
What I am trying to represent within the diagram, to ensure this is correct is that this database will be used to drive a front end website and when a user selects a Parent Category type from a drop down list, depending on the category chosen, it would then present the appropriate drop down lists for the associated child categories, allowing the specific Product Types and Child categories products to be associated with the member.
I hope this makes sense and I have explained this in a way that someone will understand. I just need to know how to represent this correctly within Visio.
I'm having trouble determining the proper database design involving entities that may or may not have a relationship with a super entity, or parent entity.
I have the tables work_orders, work_order_groups, and contracts for the corresponding entities.
Originally, it started out with work orders having a 1-to-1 relationship with contracts. But the concept of child work orders was introduced, for extra work of a different type. They were still work orders, but branched from a main work order, so a parent_work_order_id was added to represent that relationship as a foreign key referencing the id of another work order. So a work order could have 0-to-1 parent work orders.
Those child work orders shared the same contract with the parent work order, thus the relationship was changed to 1-to-M for contracts to work orders.
Hopefully at this point, the database design sounds acceptable. Now this is where I'm having some doubts. We've introduced a package deal, where there can be multiple work orders grouped together. We need a work order group entity to exist, so that we can record details about that group. The work orders would have a 0-to-1 relationship with the work order groups.
The contract is going to be created on details from the work order group, so I'm thinking the contract should be associated to the work order group. This would give a 1-to-1 relationship between work order groups and contracts. Similar to child work orders, all work orders within a group are going to share the same contract. And so that can cascade down to all child items: You'd have a work order group with a contract, all the work orders share that contract, and then all the child work orders too. I'm unsure about this design. In my head, I've got something like this:
Is this acceptable? I feel like I'm going to be storing the contracts_id in multiple places, although that is indeed how the relationship works out.
0-to-1 -- Have the id (of the '0') be a valid id or NULL (or perhaps 0) sitting in the Entity table for the '1'.
1:many -- In a single table ('tree'/'parent-child'/'hierarchy') -- The child record has the id of the one parent. The ultimate ancestor (if there is such) will have a parent of NULL or 0. A childless parent is possible, but not obvious by looking at the parent row.
1:many -- In two tables, do something similar.
Can a parent table be a child table of its child table?
For example, if there are only two tables that are linked so one is parent, and another one is child. Can the parent table be a child table and vice versa?
Yes.
Say you have classes and teachers.
Teacher table can have a ClassID; Class can have a TeacherID. It may / may not make any sense depending on the model, but on the database level it's certainly possible.
It's like you want, so yes you can : you'll have to use join and alias to get back your data properly.
If you only get a A-B-A relationship it's OK, but be careful with recursive relationship when you don't have a fixed deep as, it's a big pain to get back everything on a single query (take a look a the Tree pattern and other specific DB structure, it can be a better choice).
The entity which participates in the 1:0+ relationship is the parent entity.
Is that correct?
Update:
No, this is wrong.
In a 1:1 relationship, you just have one table. There's no distinction. The attributes must apply to both types of entity.
However, in an optional 1:1 relationship, often called 1:0+ or "one to zero or one" relationship, the child would be the optional one, not the parent.
In short, there will always be a parent.
In your image, there's an optional one-to-one from staff to notebook, i.e. a staff member may have zero notebooks or one notebook. There's also a one-to-one relationship from notebook to staff, i.e. a notebook must have exactly one member of staff as an owner.
Here's a diagram to help you understand:
In the context of identifying and non-identifying relationships between tables, MySQL's documentation refers a lot to the tables as parent and child tables.
How do you determine which table is the parent table and which table is the child table?
A child table (A.K.A. weak entity) is a table whose primary key attributes depend on another table, thus the child table is identified or partially identified by rows in the table it depends on (parent). Rows in a child table cannot exist without a corresponding row in its parent table.
To illustrate, let's take a simple and completely relevant example we are all familiar with: Parents and children in the context of family. We can model out this relationship with tables like so:
In the model above, each row in the Parents table is uniquely identified by an SSN. The SSN is an intrinsic and unique attribute to each parent, thus it is a standalone or "strong" entity because it does not rely on another table to define its identity.
Children however, require a parent in order to exist (Parent_SSN must reference to an existing SSN in the Parents table).
Notice the composite primary key (Parent_SSN, Name) in the Children table. This means that children are uniquely identified by the combination of Parent_SSN and Name. You cannot query for an individual child based only on the Name field because multiple parents may have children with the same name. Likewise, you cannot query for an individual child based only on the Parent_SSN field because one parent may have many children. Taking that into consideration, children are partially identified by their parent, hence identifying relationship.
But can't children be uniquely identified by an SSN as well? Why yes, certainly. Let's go ahead and adjust our model to include that:
In this version of the model, notice we have introduced the SSN field for Children. The unique identity of children is now defined by their own intrinsic and unique SSN. Their identity no longer depends on the Parents table. Although the Parent_SSN field still references the SSN of the Parents table, it has no part in the unique identity of the child, thus parents have a non-identifying relationship to their children, and both tables can now be considered "strong" standalone entities.
As an aside, this version of the model has a few advantages over the first:
One parent may now have two or more children with the same name, whereas the entity integrity constraint in the previous model would not allow for this.
You can allow the Parent_SSN field to contain NULL to account for the event that you have data about the child, but do not know who his/her parent is.
In both of the above models, the Parents table is considered to be the parent table of the Children table. However, in non-identifying relationships like in the second model, Parents is only a parent table in the context of the foreign key Parent_SSN because Parent_SSN references/depends on SSN in the Parents table, but does not have any part in defining the actual identity of children.
To illustrate why context is important when deciding which tables are parent/child tables, consider the following example involving a circular dependency:
In this example, employees and departments are uniquely identified by their own attributes and do not derive any part of their identity from other tables.
Here, we have two non-identifying relationships: an employee works for a department (DeptNo in the Employee table), and a department is managed by an employee (ManagerSSN in the Department table). Which one is the parent table? ...Child table?
It depends on context — which foreign key relationship are you talking about? The Department table would be considered the parent table in the context of DeptNo in the Employee table because DeptNo is referencing/dependent on the Department table.
However, the Employee table would be considered the parent table in the context of ManagerSSN in the Department table because ManagerSSN is referencing/dependent on the Employee table.
A great definition is proposed here:
An identifying relationship is when the existence of a row in a child
table depends on a row in a parent table. (...) Formally, the "right"
way to do this is to make the foreign key [i.e. the parent's primary key] part of
the child's primary key.
There is no strict rule that will determine the role of a table in a relationship. In fact, that's the beauty and innovation of the relational model: no hierarchies.
Usually, if there is a hard dependency from certain table to another, the child or parent role are determined by semantics of the tables. Example: in a order, order_details relations, it's pretty obvious that order is the parent and order_details is the child.
In other cases, it's not clear what role a relation plays in a relationship. Example: orders and customers relation. If you perform a query to get all orders belonging to a certain customer then the parent might be customers and orders are children. But you can also do a query to get all shipment information (stored in customers relation) for a specific order, and in this case, you might argue that order is the parent while customers is the child in this query.
As I said before, when relational model was invented in late 70's, one of its main benefits over one of the reigning paradigm (hierarchical data model) was the ability of look for related data regardless of their dependency.