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.
Related
I am trying to create a Core Data model for my application. I have having issues in defining the attributes and relationships. Here's the scenario
I have a Contract Management Application. So the basic entity is Contract. It has a Tenant but can have multiple Landlords. Tenant and Landlords can either be a Person or a Company type.
I have defined the entities as shown in the table below.
I only created Landlord and Tenant to reference them easily from Contract. I feel that Contract should have a To-Many relationship with a name of landlords as a Contract can have multiple landlords. The problem I have is that each Landlord could either be a Person or a Company. Same goes with the tenant, though it would always be one for a Contract.
Here's the updated Snapshot of Landlord
& Tenant Entities
Can you please help me define what relations should I create from Contract to Landlord && Tenant ( along with reverse relations if any ) ?
Here's the ER Diagram that I could think of my head ! ;)
Can you please help me define what relations should I create from Contract to Landlord && Tenant ( along with reverse relations if any ) with each of them being either a Company or a Person ?
Thanks
I've set up a few data structures similar to yours.
What works for me in this situation is to set up an Entity that defines the roles that each person plays in a contract and another Entity that defines type of role.
So in your case I'd think about using this structure...
Delete the Entities Landlord and Tenant;
Add a new Entity called ContractRole with Relationships contract, company, person and contractRoleType.
Add a new Entity called ContractRoleType with Attribute type and Relationship contractRole;
to the existing Entities Contract, Company and Person, add a new Relationship contractRole;
the Entity ContractRoleType will have at least two types "Landlord" and "Tenant".
So for each Contract you will enter data for at least two ContractRoles, one with ContractRoleType "Landlord" and one with ContractRoleType "Tenant".
I find this type of data structure very flexible.
"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!
In an E-R diagram:
Let's say we have an entity owner and an entity pet.
A owner is related to a pet through the relationship adopts.
This relationship is one to many, i.e an owner can adopt many pets, but a pet can only be adopted by one owner.
Now each pet has a name that is unique among the pets owned by an owner, i.e an owner cannot have two pets named "Squiggles".
However, different owners can utilize the same pet names, i.e. Jack can have a pet named "Squiggles", and so can Jill.
How do I represent the pet's name in an E-R diagram?
It sounds like this is what you want:
http://en.wikipedia.org/wiki/Weak_entity
A pet would be unique identified by the owner id and its name.
The example in wikipedia sounds analogous to what you are looking for.
While this might not be exactly how you implement it in a DB this is how you would diagram it.
Consider the following schema: Employee, and EmployeeType. Employee has a fk to EmployeeType (EmployeeType might have fields like EmployeeTypeId, Description, etc...).
Now I would like to use EF's inheritance feature to create objects HourlyEmployee, and SaleriedEmployee based on the Employees fk field.
This does not seem possible. Every avenue I have tried has failed. Since Employee's FK is the descriminator for the mapping to the derived entities HourlyEmployee and SaleriedEmployee and the FK to the table EmployeeType.
Is there anything I can do short of adding a seprate field in Employee that is an duplicate of the fk field?