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:
Related
I am trying as an exercise for an exam to transfer a database from the ER model to a relational database.
However, I am very unsure whether my solution makes sense. In particular, the two relationships between location and has makes great problems. I thought I could add one ZipCode as a regular primary key into the table has and a second ZipCode as foreign key. I would be very grateful if someone could help me with this.
My Solution so far:
If you are following Chen ER design with this Chen ER diagram then you need a table for every entity type box and every relationship (association) type diamond and a FK (foreign key) for every participation/role line for a relationship type.
(It is a bad idea to call lines/FKs "relationships" or "associations" in a Chen context because diamonds/tables represent relationship types and lines/FKs represent participations.)
So your Ship tourID would be dropped in favour of relationship/table takes with lines/FKs to Ship & Tour. And you would have two FKs in the has table to Location. It doesn't matter that you need different column names in the relationship table than in the participant table. A FK just says the values in some table & column list appear in some other table & column list. The diagram says the names are start & target; use them.
Don't use a flaccid uninformative name like has. If you picked a better name and/or explained when a triplet of entities satisfied the has relationship then we could know what reasonable designs would be. Eg you may not be using cardinalities correctly. The Chen way is, a number or range tells for some instance of the entity type how many relationship instances it can participate in. Another way is, a number or range tells you for a some combination of entity instances of the other participating entity types how many instances of the line's entity type can participate with it. If the latter has a zero that means a relationship instance can have a NULL. But that can't arise in a Chen design; participating entity instance combinations identify relationship instances and form PKs (primary keys).
However, a Chen design can't express all relational designs. And we can represent the same data as a Chen ER schema by rearranging tables. Eg dropping binary relationship tables that are not many:many and putting FKs (sometimes nullable) into entity tables instead, just as you did with takes, Ship & Tour. Some methods have non-Chen diagrams expressing such designs directly. Others allow it in the move from Chen diagram to schema. You have to ask your teachers whether they care just what variations from the Chen style of ER diagrams and corresponding schemas you are permitted to make.
(It is this dropping in non-Chen methods of explicit 1:many relationships/associations and their representation by FKs that leads to FKs being incorrectly (but commonly) called "relationships" or "associations".)
When we establish a one-to-one or many-to-one relationship, we can call it mapping. For example, we map a spouse to his/her spouse or each child to its parent. But what would be the verb singifying an establishment of a many-to-many relationship, underlining that it is not a 1+ to 1 relationship?
you can distribute, permute, or combine multiple groups to define many to many relationships. Mapping a group to other groups does not explicitly state if the members are crossed or not, like in a Cartesian product.
Permute is a more specific case because the order matters, but both permutations and combinations are the result of distributing a set among other sets (or groups among other groups).
To cross reference or to associate. I do not know if there is a definitive term but these seem plausible.
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.
I have different kind of actors:
Parents;
Subsidiaries;
Insurers;
Brokers;
for each of the actors, there will be users with a personal account and user role.
I need to register the address and other (entity specific, including foreign keys) info into a table, which could be done by defining one "actor_tbl" and specifying the type of actor with an id.
However, the four types of actor have interrelations, which means that one parent can have multiple subsidiaries, one insurer can have multiple subsidiaries, one broker can have multiple parents, etc...
From this point of view, it would make more sense for me to create a separate table for each of the actor types, and create many-to-many relationships to make the right combinations. It think that it may also increase general readability and reduce the possibility for errors (all entities would be clearly separated from one another).
However, doing so takes away the principle of storing all entities with similar characteristics into a single table.
How would you take on this problem? What is the most recommended way to implement this structure?
You can see a superclass/subclass relationship between Actor and the four kinds of actors. The first point here is to clarify the constraints on this relationship. From your description, I'm assuming the participation is mandatory (every Actor will be also a member of a subclass) and the subclasses are disjoint (e.g. a Parent cannot be a Broker, and so on).
In this case, you'll need four relations, one for each subclass.
If instead the participation is optional (some Actor may not be a member of any subclass), you'll need a relation Actor(ActorID, ...) to store all the attributes in common between the subclasses (e.g. address), then one relation for each subclass, which will look like:
Parent(ActorID, ...)
Subsidiary(ActorID, ...)
Insurer(ActorID, ...)
Broker(ActorID, ...)
For these four relations, ActorID will be both primary key and foreign key referencing Actor(ActorID). The dots represent the attributes which are peculiar to the specific entity (as mentioned before, the common attributes will be in the Actor relation).
For Actors which are not member of any subclass, you just store the record in the Actor relation. For Actors which are instead member of a subclass, you'll store the record in Actor and in the specific subclass relation.
In all cases, relationships between the subclasses will be modelled depending on their cardinality.
If the disjointness between subclasses is different, i.e. non-disjoint subclasses, then the story is different.
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.