In Mapping Superclass, Subclass Relationship
Participation Constraint – Partial
Disjoint Constraint - Disjoint
Do we have to map a Foreign key from child to parent?
If we don't, why not?
Related
I want to know how to map the relation between the landlord and property as well as the relation between the student and the landlord.
I know how to map a one to many relation. In this case, it's the relation between the landlord and the property. But since landlord is a subclass of Person, and uses the primary key of person, which is nic, as the primary key of the landlord, should I take the nic as the foreign key to the relation between landlord and property?
So that;
Property(Idno,Street,City,Fee,Amount,NIC)
Should it be like this?
And in the other relationship, which is the relationship between Student and Landlord, since both are sub classes of the entity Person and both are having NIC as their primary key because of it being the primary key of the superclass, how should that be mapped?
student(NIC,STID,Gender,DOB,NIC)
This isn't correct imo. Please help.
Yes you should take NIC. That's because it's the primary key and the only unique identifier. It's not wise to create another key or something like that.
Now about the landlord and student relation there should be none directly to them. Think it like a database you would have a table that are the properties that have 2 foreign keys. The landlord and the current student it is rented to. So I think there should be a relationship betweeen the student and property. Not between the landlord and the student.
Is there such a thing as primary and secondary constraints in core data?
I have a one to many relationship. In the "many" entity, I would like to have a constraint for one attribute. The problem is that the constraint is for all entities that I create and not for the specific one that is related to the "one" entity in the relationship.
"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.
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.
If you have
Parent
has_many :children
Child
Is there any reason a foreign key on Child (to Parent) and a corresponding belongs_to :parent might not be desirable?
When, if ever, would you not want your Child to be able to access its parent?
It's a trade-off. The usual argument against foreign keys is that the index for a foreign key incurs some performance overhead on insert/update/delete. Just like any index.
But an index also gives great benefit when you search via that column.
SELECT * FROM Child WHERE parent_id = :id
Also don't underestimate the overhead of searching for orphaned children and cleaning up bollixed references, which are the inevitable consequence of omitting foreign key constraints.
-- Typical chore: searching for orphaned child rows.
SELECT c.* FROM Child c LEFT OUTER JOIN Parent p
ON (c.parent_id = p.parent_id)
WHERE p.parent_id IS NULL;
There are also some database designs in which you can't use foreign keys, such as Polymorphic Associations or Entity-Attribute-Value. But these designs are anti-patterns in their own right.
Performance. There is a cost when inserting a child record to determine if there is a parent record. You can still access the parent record (assuming you have a parentID column in the child table, just no referential integrity).