A dashed line means that the relationship is strong, whereas a solid line means that the relationship is weak. On the following diagram how do we decide that the relationship between the Room and Class entities is strong. Is it because Room entity has a regular key (non-composite)?
Weak (Non-Identifying) Relationship
Entity is existence-independent of other enties
PK of Child doesn’t contain PK component of Parent Entity
Strong (Identifying) Relationship
Child entity is existence-dependent on parent
PK of Child Entity contains PK component of Parent Entity
Usually occurs utilizing a composite key for primary key, which means one of this composite key components must be the primary key of the parent entity.
We draw a solid line if and only if we have an ID-dependent relationship; otherwise it would be a dashed line.
Consider a weak but not ID-dependent relationship; We draw a dashed line because it is a weak relationship.
In an ER diagram, I believe when the relationship is strong, i.e., the primary_key of the parent forms a composite or non-composite primary_key in the child entities, we use a solid line to depict that. Similarly, for the case when the relationship is weak, which means the primary_key of the parent is not used as a primary_key in the child entity, then we use a dashed line to show that.
The relationship Room to Class is considered weak (non-identifying) because the primary key components CID and DATE of entity Class doesn't contain the primary key RID of entity Room (in this case primary key of Room entity is a single component, but even if it was a composite key, one component of it also fulfills the condition).
However, for instance, in the case of the relationship Class and Class_Ins we see that is a strong (identifying) relationship because the primary key components EmpID and CID and DATE of Class_Ins contains a component of the primary key Class (in this case it contains both components CID and DATE).
In entity relationship modeling, solid lines represent strong relationships and dashed lines represent weak relationships.
Related
As i know optionality means the minimum cardinality of a relationship which is denoted as optional to optional, mandatory to optional, mandatory to mandatory..
And Participation denoted as bold line and a normal line.
In the Internet some refer participation as the dependency of the entity to the relationship which is also looks like identifying and non identifying relationship.
and some refer it as the minimum cardinality
What is the correct definitions of those relationships and what is the difference..
Let's start with definitions and examples of each of the concepts:
Total and partial participation:
Total participation (indicated by a double or thick association line) means that all the entities in an entity set must participate in the relationship. Partial participation (indicated by a single thin line) means that there can be entities in the entity set that don't participate in the relationship.
Medicine participates totally in the Produce relationship, meaning that Medicine can't exist unless Produced by a Laboratory. In contrast, a Laboratory can exist without Producing Medicine - Laboratory participates partially in the Produce relationsip.
Mandatory and optional roles:
In a relationship, roles can be optional or mandatory. This affects whether a relationship instance can exist without an entity in a given role. Mandatory roles are indicated with a solid association line, optional roles are indicated with a dotted line.
Roles aren't often talked about in database tutorials, but they're an important concept. Consider a marriage - a relationship with two mandatory roles filled by the same entity set. In most relationships, the entity sets also define the roles, but when an entity set appears multiple times in a single relationship, we distinguish them in different roles.
In the example above, a Patient can Purchase Medicine with or without a Prescription. A Purchase can't exist without a Patient and Medicine, but a Prescription is optional (overall, though it may be required in specific cases).
Identifying relationship / weak entity:
A weak entity is an entity that can't be identified by its own attributes and therefore has another entity's key as part of its own. An identifying relationship is the relationship between a weak entity and its parent entity. Both the identifying relationship and the weak entity are indicated with double borders. Weak entity sets must necessarily participate totally in their identifying relationship.
In this example, a Prescription contains LineItems which are identified by the Prescription's key and a line number. In other words, the LineItems table will have a composite key (Prescription_ID, Line_Number).
For examples of non-identifying relationships, see the previous examples. While Medicine participates totally in the Produce relationship, it has its own identity (e.g. a surrogate key, though I didn't indicate it). Note that surrogate keys always imply regular entities.
Mandatory/optional vs total/partial participation
Mandatory or optional roles indicate whether a certain role (with its associated entity set) is required for the relationship to exist. Total or partial participation indicate whether a certain relationship is required for an entity to exist.
Mandatory partial participation: See above: A Laboratory can exist without producing any medicine, but Medicine can't be Produced without a Laboratory.
Mandatory total participation: See above: Medicine can't exist without being Produced, and a Laboratory can't Produce something unspecified.
Optional partial participation: See above: A Prescription can exist without being Purchased, and a Purchase can exist without a Prescription.
That leaves optional total participation, which I had to think about a bit to find an example:
Some Patients Die of an unknown Cause, but a Cause of death can't exist without a Patient Dying of it.
Total/partial participation vs identifying/non-identifying relationships
As I said before, weak entity sets always participate totally in their identifying relationship. See above: a LineItem must be Contained in a Prescription, it's identity and existence depends on that. Partial participation in an identifying relationship isn't possible.
Total participation doesn't imply an identifying relationship - Medicine can't exist without being Produced by a Laboratory but Medicine is identified by its own attributes.
Partial participation in a non-identifying relationship is very common. For example, Medicine can exist without being Purchased, and Medicine is identified by its own attributes.
Mandatory/optional vs identifying/non-identifying relationships
It's unusual for a relationship to have less than two mandatory roles. Identifying relationships are binary relationships, so the parent and child roles will be mandatory - the Contain relationship between Prescription and LineItem can't exist without both entities.
Optional roles are usually only found on ternary and higher relationships (though see the example of patients dying of causes), and aren't involved in identification. An alternative to an optional role is a relationship on a relationship:
By turning Purchase into an associative entity, we can have it participate in a Fill relationship with Prescription. To maintain the same semantics as above I specified that a Purchase can only Fill one Prescription.
Physical modeling
If we translate from conceptual to physical model (skipping logical modeling / further normalization), making separate tables for each entity and relationship, things look pretty similar, though you have to know how to read the cardinality indicators on the foreign key lines to recover the ER semantics.
However, it's common to denormalize tables with the same primary keys, meaning one-to-many relationships are combined with the entity table on the many side:
A relationship is physically represented as two or more entity keys in a table. In this case, the entity keys - patient_id and cause_of_death_id are both found in the Patient table. Many people think the foreign key line represents the relationship, but this comes from confusing the entity-relationship model with the old network data model.
This is a crucial point - in order to understand different kinds of relationships and constraints on relationships, it's essential to understand what relationships are first. Relationships in ER are associations between keys, not between tables. A relationship can have any number of roles of different entity sets, while foreign key constraints enforce a subset constraint between two columns of one entity set. Now, armed with this knowledge, read my whole answer again. ;)
I hope this helps. Feel free to ask questions.
"The unique identifier of the entity on the “one side” of the one-to-many relationship is placed as a foreign key in the table representing the entity on the “many side.”
Why can't the primary key of the entity on the "many side" of the one-to-many relationship be placed as a foreign key in the table representing the entity on the "one side" ?
Ex. one-to-many relationship between Customer and Order
A customer can place many orders, but each order can be placed by only one customer.
Why can't order id be placed as a foreign key in the customer table?
Any one entity can have only one value of the foreign key, and therefore can reference only one related entity. The referenced entity is thus on the (a) "one" side of the relationship by definition. The entity bearing the FK can be either the other "one" side of a one:one relationship or the "many" side of a one:many relationship; the difference is whether foreign key values may be duplicated in more than one entity of that type.
I'm using CoreData for the first time in one of my project. My table involves FOREIGN KEYS and since CoreData doesn't support FOREIGN KEYS, I'm having some issues.
Below is the structure of my tables.
My Problem is the establishment attribute.The establishment attribute is supposed to hold the name of a particular facility from the Facilities table. However, since it's a relationship, Xcode expects a Facility rather than just a name of a facility (NSString).
Is this possible, or am I just mixing up FOREIGN KEYS with RELATIONSHIPS in CoreData? How would I solve this problem?
Thanks in advance.
A relationship is not a property, so it does not have a type. In the model editor you add a relationship explicitly.
From your diagram, I see that you did not set the inverse relationship. There needs to be a corresponding relationship from name to the Assessors entity. (Set the "Destination" to Assessors in the model editor.)
I would also suggest to rename a few items.
First, use singular: Assessor, Facility. These are objects (comparable to classes), not tables.
Second, because your name attribute refers to an assessor, call it assessor, and similarly call its reverse relationship facilities (it is a to-many relationship in this direction, so the plural is appropriate).
If you need the name of the assessor of a facility, you use
facility.assessor.name
This should make it obvious why you do not need foreign keys. Indeed, I would urge you to think that it is not Core Data that does not support foreign keys, but that it is the traditional relational databases that do not support relationships!
There is a problem with core data when a to-many relationship has no inverse. Changes made to the related property do not persist. This is a problem many of us have faced, as it can be found by googling.
This is to ask if some of you found a trick/workaround to achieve persistence, beside the obvious answer or adding an inverse relationship.
Background:
Even if unidirectional relationship are discouraged in the documentation, they are not forbidden. The doc only insists on responsibility incurred when having no inverse.
The reason of not wanting an inverse is outlined in the core-data doc: when you have a large number of items linked to one entity the inverse relationship is loading a large NSSet each time an item is added. Consuming memory, possibly more than allowed for no reason.
Example
In employees/department typical paradigm, if you have a huge number of employees able to belong to several departments, you need a to-many relationship from employee to department. You do not want the inverse because each time an employee is linked to a department, a (very) large NSSet must be loaded, updated and saved. Moreover if the department entity is never deleted, graph integrity is easy to maintain.
Please do not reply that this is a feature of core-data and that inverse relationship is mandatory. This is not stated as such and is more like a bug than a feature. Posting a bug report is not solving the point for current deployed systems.
Edit: The Join entity solution
This edit is to give more light and discussion to Dan Shelly's answer proposal below.
First, to reply to your first, I'm not trying to have a many-to-many but a true unidirectional to-many. The very same page your linked has this text a bit below the one you quoted:
Unidirectional Relationships
It is not strictly necessary to model a relationship in both directions. In some cases it may be useful not to, for example when a to-many relationship may have a very large number of destination objects and you are rarely likely to traverse the relationship (you may want to ensure that you do not unnecessarily fault in a large number of objects at the destination of a relationship). Not modeling a relationship in both directions, however, imposes on you a great number of responsibilities, to ensure the consistency of the object graph, for change tracking, and for undo management.
That said your proposed solution of adding an join entity is a way to go if there is no solution to force core-data to generates and updates it automatically.
IMO, and for my use case, the join entity does not even need to have the relationship to Department. This to-one is useless and may be replaced by a property of the join entity keeping related Department information, like its objectID or other indexed property to reach it.
i.e:
DepartmentEmployee:
Properties: Dept_ix (integer)
Relationships: employee (to-one,nullify)
This is a great question.
ButFirst thing first:It clearly state in the documentation:
"Important: You must define many-to-many relationships in both directions—that is, you must specify two relationships, each being the inverse of the other. You can’t just define a to-many relationship in one direction and try to use it as a many-to-many. If you do, you will end up with referential integrity problems."
Never the less, Lets describe the issue (resulting database)
When defining a to-many relationship, the resulting database does not add an additional table to map the relationship.
It only sets a property on the entity at one end of the to-many relationship equal to the last item that referenced it.
Example:
Model:
Entity: Department
Relationships: NONE
Properties: name (string)
Entity: Employee
Relationships: departments (to-many,no-action)
Properties: name
Resulting Database:
ZDEPARTMENT:
Z_PK
Z_ENT
Z_OPT
Z2DEPARTMENTS (int)
ZNAME
ZEMPLOYEE:
Z_PK
Z_ENT
Z_OPT
ZNAME
This structure will obviously result in data inconsistency.
The solution will be to hold an entity: DepartmentEmployee modeling the to-many relationship in both directions but one of them would be unidirectional (Department -> DepartmentEmployee):
DepartmentEmployee:
Relationships: department (to-one,no-action), employee (to-one,nullify)
and you will have to maintain the table upon deletion of a department object.
Hope this made some sense :)
First a reply for your comment:
IMO, and for my use case, the join entity does not even need to have the relationship to Department. This to-one is useless and may be replaced by a property of the join entity keeping related Department information, like its objectID or other indexed property to reach it.
This is exactly what the department property is doing in the joined relationship.
If you would look at the generated SQLite structure, you will see and additional mapping table between the Employee entity and the Department entity, holding only their int64 ids.
Now, the given example was:
Example
In employees/department typical paradigm, if you have a huge number of employees able to belong to several departments, you need a to-many relationship from employee to department. You do not want the inverse because each time an employee is linked to a department, a (very) large NSSet must be loaded, updated and saved. Moreover if the department entity is never deleted, graph integrity is easy to maintain.
A simple ONE-to-many relationship with no inverse could be easily implemented.
You can look at it as just another property on the object in the 'many' side of the relationship.
This example request a ONE-to-many relationship of the kind:
Employee-->>Department (an Employee may belong to many departments)
The inverse is:
Department-->Employee
Since we must not implement a many-to-many relationships without an inverse, we must implement the to-ONE side of the relationship, just to make sure we comply with the implementation of the framework.
Re-iterating:
By the documentation we know that no many-to-many relationship will NOT persist without an inverse relationship being defined.
==>
Since we like to model the relationship without an inverse we will model it only as the to-ONE part of the coupling (modelling it as a to-many will violate the persistency promised by the framework)
Think of it as useful for defining files in a folder (a file may not belong to more than one folder), or parent child relationship.
==>
We must define the relationship as:
Department-->Employee (Which does not make much sense since a department that can hold only one employee is not really a department is it)
To look at it from another angel (negative proof):
Suppose we would like to go against the framework and define a MANY-to-many relationship with no inverse.
==>
That would mean that we will only implement it in one direction leaving a ... to-many relationship or ... MANY-to relationship
==>
this is the same thing isn't it (a to-many relationship from and entity1 to entity2)
==>
NOW, if we have a ONE-to-many relationship and we choose to not implement the inverse of it, we can choose to implement the to-many part? NO WE CANNOT, this will look as only half of a MANY-to-many relationship
==>
We MUST implement the ONE-to part of it.
For making some more sense, I will show the more logical:
Department-->>Employee
So our implementation for this ONE-to-many relationship would be:
Department<--Employee
This will result in the following SQLite DB structure:
ZDEPARTMENT:
Z_PK
Z_ENT
Z_OPT
ZNAME
ZEMPLOYEE:
Z_PK
Z_ENT
Z_OPT
ZDEPARTMENT (int)
ZNAME
We could now define a fetched property on Department to fetch all the employees belonging to it:
employees predicate: department == $FETCH_SOURCE
You can enforce this relationship in the prepareForDeletion method of Department (not tested):
(You will first set the userInfo dictionary on Department to hold the type of enforcement)
(I left the implementation of the 'Deny' rule to the reader :D )
- (void) prepareForDeletion
{
[super prepareForDeletion];
NSEntityDescription* entity = [self entity];
NSDictionary* dict = [entity userInfo] ;
if ([dict count]) {
[dict enumerateKeysAndObjectsUsingBlock:^(NSString* key, NSString* value, BOOL *stop) {
NSArray* arr = [self valueForKey:key];
if( [value isEqualToString:#"cascade"]) {
for (NSManagedObject* obj in arr) {
[[self managedObjectContext] deleteObject:obj];
}
} else if ( [value isEqualToString:#"nullify"] ) {
NSArray* arr = [self valueForKey:key];
for (NSManagedObject* obj in arr) {
[obj setValue:nil forKey:#"department"];
}
}
}];
}
}
As I see it, this is all you can do with regard to inverse relationships.
If you still believe you need a many-to-many relationship, please refer to my other answer.
Regards,
Dan.
Have you considered doing away with the relationship entirely and programmatically managing the foreign key on employee?
If you have a UI which sets the property from a list of existing Departments (a pick list, etc.) you can simply take the primary key from that list and assign it as the departmentID property on your Employee.
You should then be able to implement a validateDepartmentID:error method on your Employee object which checks that the given departmentID is valid (i.e. is in a fetched list of departments) and/or is not null so that you maintain referential integrity between the Employee and Department.
When fetching the list of Employees in a Department, you can either use fetched properties or add an instance method to the Department which returns an instance of NSFetchedResultsController containing the Department's employee list.
The only other thing you'd need to do is inject some deletion logic in your Department class (likely on -prepareForDeletion) to update the departmentID on any affected child records. That one depends on your business logic.
The Apple docs on property validation cover -prepareForDeletion and -validateValue:forKey:error if you're not familiar with them.
I read a lot of examples and tutorials about adding referential constraints but my designer just doesn't give me the FK I would need to select.
I'm using model first and all my IDs are GUIDs.
These are the two entities:
These are the properties of their association:
And this is the "Referential Constraint Dialog":
As you can see: There is no FK to select as "Dependent Property"...
In the database there is a FK column for that:
What am I doing wrong?
Thanx
Because your entity doesn't have any FK property. You must first create the property which will be used as your FK and select it in Dependent Property drop down (it shows only existing properties of dependent entity).