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.
Related
Currently, I'm working on design class model and domain class model.
I have entity class Account and class Member .
I know that class diagrams and ER models can differ from each other.
However, Should I in the ER model include such entities as Account and Member , or can I combine them into Account entity?
First of all, it seems to me that Member belongs to the domain and matters to the business users. It should therefore also be «Entity». But your question seems not really about entities, but more about tables:
Members and Accounts are in your UML distinct classes, since they have different structural and behavioral characteristics. But also in an ER model they would be different entities, as their attributes may vary independently:
Considering that Account and Member are associated one to one in your model, you could consider to store both in a combo-table. That’s an implementation decision about the tables. But it does not really change the entity semantics: a member is still something different from an account.
While you can do this combo-table shortcut, you should ask yourself if this is a good idea in view of the principle of separation of concerns. Keeping them separate will ease your ORM mapping and facilitate maintenance.
If the association of Member with Account would be one-to-many or many-to-many, it would be another story: if you’d combine them into a single table, your relational model would no longer be normalised, and this has many inconveniences.
I am learning about ER modelling about Database systems. My problem is that there is a entity called books,enitity named user and I want to create a borrows relationship between user and book with attribute issue date. I modelled it as described but it was pointed that borrows cannot be a relationship because a same user can borrow a book twice. Can anybody explain me what this is as I am using issue data as an attribute so records in borrows relationship would not collide as I will use PK as userid,bookid and issue date. How can I model this accurately? I am a little confused in this.
In the ER model, entity relations consist of attributes of a single entity set, in which the PK identifies only one entity set. Relationship relations have a composite PK that represents two or more entity sets.
Your question uses a composite PK that represents two entity sets (userid and bookid) and a value set (issue date). Strictly speaking, it's neither an entity relation nor a relationship relation. It's a combination of a relationship relation (two entity keys) and a weak entity set (issue date functions similar to a weak key). If we want to be creative, we might call it a weak relationship.
If I was forced to draw an ER diagram for this, I might present it like this:
The ER model isn't a complete logical model (unlike the relational model) and there are some situations which aren't handled well or at all. This is one of those situations.
As per description, User and Book are the entities.
One user can borrow an instance of book.
Similary, one user can borrow multiple instances of book, whether It can be same
instance or various instances.
So every transaction between the User and Book has the Issue Date.
Neither the user nor the book has the Issue Date.
Here, the relationship between User and Book are Many to Many.
The Bridge table is Transaction. We can name it as Borrow also as per your interest.
Now, The user has one to many transactions.
Every Book has one to many transactions.
Every transaction is a combination of a User and Book.
Note: Since every user can have the same book multiple times and at the same day. So we can have a composite primary key of user_id, book_id and Issue_timestamp as there is a chance of redundancy in the Issue Date in the same combination.
Lets say a relationship is described as:
A company has many employees
A company has many departments
A department has many employees
So, something like this;
Company -<< Departments >>- Employees
If department table has a basic structure of:
// Pseduocode
company_id // Foreign key
department_id // Primary key
[employees] // Array or collection of employees
If we go back to this phrase;
A Company has many employees
Does this mean that the employee table needs or requires a reference for the company_id too?
So, Employee would be:
employee_id
company_id // I'm not sure if this is requried or not
department_id
I'm intending to hopefully abstract this data into a contracts table in case of employees are freelancers/contracters, etc or have multiple employees.
But for now..
My question is:
Does my employee table require a reference to the company table, or is the company reference implied via the department table?
Many thanks
Question is: do you need a straight connection between Company and Employee? If you do, add it, if not then yes, the connection is implied through Department.
EDIT:
Technically, your Department table does not need a list of Employees. Each row of Employee table has a reference ID to Department, that's enough.
Check this out for more information.
The relationship is implied through the department, so you don't conceptually need it. Adding it, would be an example of denormalisation, and would allow inconsistencies to crop up. For example, you might have company_1 with department_1 and company_2. Now employee_1 might be linked to department_1 but company_2, because of some flaw/bug in the application code. There's no way to express this constraint as a SQL schema, so you'd have to go with more complicated stuff such as triggers, or application code checks etc.
However, sometimes you only need info about companies and employees, but not about departments. If it's really performance critical, doing the extra join with departments in order to find the company for an employee or the employees for a company might not cut it, so you'll just have to live with the denormalisation.
You probably do not need to link Company with Employee. The relation between Departement and Company already do the job. You may need it only if there are existing particular cases requiring this relationship.
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.
I have 2 entities in my domain that have a one-to-one relationship with one another.
Entity Business has a Promotion. And Promotion has a Business. I know this doesn't make a lot of sense and I could as well integrate the fields of Promotion into my Business entity, but I'm dealing with a legacy database here and I'm trying to model my domain on top of it without changing anything in the database for now.
My problem is that although the relationship goes both ways, it's only stored on the side of the promotion table that has a business_id foreign key, but there is no promotion_id foreign key in the business table. So when I try to run my app, Grails can't find the promotion_id column it expects to find for the promotion field in Business.
Is there any way to model my domain entity so that it understands that the column for the relationship is in the destination table only?
Right after I asked this question, I found my own answer: using hasOne as explained in http://grails.org/doc/latest/ref/Domain%20Classes/hasOne.html