I have a base class Participants inherited by Artist, Author and TextWriter.
I have only one table in the data store:
Participants {
ID,
FirstName,
LastName,
IsArtist,
IsAuthor,
IsTextWriter,
}
The idea is to have a class for all the roles that a participant can have.
I've managed to create the edmx file but when I try to get an Participant (as Artist) that is also an Author I receive the following error:
All objects in the EntitySet 'Participants' must have unique primary keys. However, an instance of type 'Artist' and an instance of type 'Author' both have the same primary key value, 'EntitySet=Participants;ID=1'.
Thank you
Yes, this is possible. What you're asking for is "table per hierarchy" inheritance. Your table needs to contain any "discriminator column" which identifies the type of each row.
However, no record for one person can have more than one concrete type when materialized (read from the DB), because an object can only have one type. I've written about this issue before:
One of the mental barriers that you have to get over when designing a good object relational mapping is the tendency to think primarily in object oriented terms, or relational terms, whichever suits your personality. A good object relational mapping, though, incorporates both a good object model and a good relational model. For example, let’s say you have a database with a table for People, and related tables for Employees and Customers. A single person might have a record in all three tables. Now, from a strictly relational point of view, you could construct a database VIEW for employees and another one for customers, both of which incorporate information from the People table. When using a one VIEW or the other, you can temporarily think of an individual person as "just" an Employee or "just" a Customer, even though you know that they are both. So someone coming from this worldview might be tempted to do an OO mapping where Employee and Customer are both (direct) subclasses of Person. But this doesn’t work with the data we have; since a single person has both employee and customer records (and since no Person instance can be of the concrete subtype Employee and Customer simultaneously), the OO relationship between Person and Employee needs to be composition rather than inheritance, and similarly for Person and Customer.
If "Bob" is a Participant who is both an Artist and an Author, then he cannot be of type, say, Artist and Author at the same time, unless one is a supertype of the other. Either Artist and Author should have a subtype relationship with the other or you should use aggregation rather than inheritance to relate Participant with Artist and Author. An instance of an object can have only one concrete type; this does not change because you store it to the DB.
Related
I am new to CoreData environment and I'm trying to understand how it works.
In my project, I have a superclass VetExam whose subclasses are Examination, Treatments and Vaccination, which share the same attributes of their superclass and has a reference to Pet class. On the other hand, Pet class holds an array of reference of every class except of VetExam, which should only be used for Polymorphism (so that I can use VetExam object and create a single view for each type).
Based on this model, I've tried to create entities in CoreData, but it seems that I have to specify for each type the inverse relationship for each entity. This represent a problem since from VetExam entity side the relationship is of type Pet but on Pet side is To-Many for each type of Examination, which does not allow me to get the inverse reference of VetExam.
Since this explaination can easily be misunderstood, I will show you the visual representation of it.
The problem is in VetExam entity, whose Inverse attribute is not known.
Does anyone know how to deal with this type of situation?
A preliminary note on inheritance...
Class inheritance
AND
Entity inheritance
For the second, I highlight the note in the Apple Documentation:
Be careful with entity inheritance when working with SQLite persistent
stores. All entities that inherit from another entity exist within the
same table in SQLite. This factor in the design of the SQLite
persistent store can create a performance issue.
What this means is that Core Data framework creates one large table in the SQLite database that includes the parent entity and the child entities. Such a large table inherently contains inefficiencies. While this may seem convenient for you to manage now in your model editor and in your NSManagedObject subclasses, this may cause inefficiencies / performance issues in the long run if you expect your app to persist and retrieve large amounts of data in the four entities you mention.
Advice from others is very relevant here because four separate entities will in my humble opinion be easier to manage, rather than one parent entity and three child entities. You do not have to give up the class inheritance you’ve developed in your code if you choose this option.
So, to answer your question...
My logic:
Every Pet may have many instances of VetExam during its life, but each instance of VetExam is carried out on only one Pet?
If yes, then create a one-to-many relationship between Pet and VetExam -
Pet <—>> VetExam.
Whatever occurs during the VetExam is any combination of one Examination, Treatment and/or Vaccination. That is and in an attempt to be clear, the VetExam may optionally have an examination, but it may not have a treatment or a vaccination. This is likely to change for each VetExam, therefore this is directly related to the VetExam, not the Pet.
If yes, then create optional one-to-one relationships between VetExam and the entities Examination, Treatment and Vaccination.
VetExam <—> Examination
VetExam <—> Treatment
VetExam <—> Vaccination
In this model, each entity relationship detailed above has an inverse.
Finally, it might be worth noting that in this proposed model, the relationship between a Pet and all the examinations, treatments and vaccinations it receives during its lifetime is stored against PetExam, not directly against the Pet.
I am new to the RDBMS.
I am Learning ER model in RDBMS.
In ER model, the entity is an real world object and it has an attributes.
The relationship is an mapping between entity set.
The relationship also have a the attributes.
Please explain the difference between entity and relationship.
You seem to have the definition differences available. But I assume you still do not understand the differences. Here is a very simplified example of two entities and the relationship that may exist between them:
A Bank and a Person are each an entity. The relationship that exists between a Bank and a Person is that a Person is a Customer to a Bank. Therefore Customer is the relationship. An attribute for a Person for example would be Date_of_Birth. An attribute for a Bank would be Bank_Name . An attribute for a Customer would be Customer_Bank_Acc_Number.
Update:
For those that like to pick at details here is a better relationship example:
A Person can have a relationship with a Bank of either being a Debtor or Creditor.
Update
There is also what is called an Associative Entity. Click the link for details on how that is different to an Associative Relationship.
I hope this makes sense. Cheers
In the tutorials im following for learning about the entity framework, they keep mentioning entities. I often see it gets used as a synonym for the dbsets<> in the database context class, but what's the literal meaning of it?
I already know how the entity framework works, I just dont understand the meaning of the word.
In Entity Framework an entity is largely equivalent to a class in the conceptual model (or the class model, which is mapped to the store model).
In domain model terms an entity is
An object that is not defined by its attributes, but rather by a thread of continuity and its identity.
(Source: Wikipedia)
That quite a mouthful for "an object with an identity", as opposed to a value object, like a DateTime or (maybe) an Address. A Customer is an entity, because it is identified by "who" he is. Two customers with the same name are still two customers.
So entities can loosely be defined as the "things" the business domain is about. The things both the customer/user and the system designer/developer talk about in ubiquitous language. And in EF those things are represented by classes.
So it's not the DbSet. The DbSet is a repository that provides entity objects.
I often see people referring to entities as models. I don't know the origin of this terminology (it seems to happen too often to be a coincidence), but I don't think it's correct. It's mostly confusing. The model in EF is either the store model or the conceptual model, so it's a collection of entities. A model can also be a view model that comprises any number of attributes of any number of entities.
Lets take a Person object for example and lets say the Person data is being posted to a database and its moving through the tiers
When its in my UI, I call it a Person Model or ViewModel.
When its in my business layer I call it a Person Business Object.
When its in my Data Layer, I call it a Person Entity.
Its the same data that is moving into different objects in different tiers. The entity is just the name of the object that is holding the Person data in the Data Access tier....
An entity is simply an object that represents some form of relational data. This is typically used for representing relational databases, but it is not confined to that. I suggest looking at http://msdn.microsoft.com/en-us/data/aa937709 for a brief overview of how the Entity Framework works.
I am trying to understand the concept of relationship in CoreData Modeling and its getting little hard to understand as of what entity could be a good sense of having a relationship. Is there a way to have a unique number generated for a relationship that can correspond to another entity as well? So lets say I have a new entity entry, it will have a unique number 101 for relationship info, and details will also have 101 created, and hence can have a corresponding relationship intact somehow. Not sure if CoreData Model have this sorted out to have some sort of generator to generate a unique value for both the entities.
Thanks
Core Data is a high level library which purpose is to manage and persist an object graph as transparently as possible. How Core Data links objects in the database (which is not necessarily a database by the way) is an implementation detail.
In the model editor, you simply create the entities you need and link them with relationships. Core Data manage the connections for you.
Person:
- first_name: string
- middle_name: string
- last_name: string
- private_address: -> Address (to-one relationship)
- work_address: -> Address (to-one relationship)
Address:
- persons: ->> Person (to-many relationship, you may want to reuse an address)
- address1: string
- address2: string
- zip: string
- city: string
- country: string
...
person.first_name returns you the first name of the person, and person.private_address.city returns the person's city of residence as easily. address.persons returns all the persons sharing the same address (private or/and work), as an NSSet. address.persons.count returns how many persons share that address. What you see is an object graph.
Core Data provides you some sort of unique ID for every entity, once the entity is saved at least, objectID, an opaque NSManagedObjectID. You'll maybe better served with the URIRepresentation (again, once the entity is saved). If your intention is to create cross-store relationships, you can use the URIRepresentation or use your own unique ID. It's fairly easy to maintain a per-entity unique ID, or even a per-store unique ID.
But most of the time, you do not have to deal with such low level concerns though. Core Data is pretty good at managing the relationships for you.
You probably need to read the Core Data Programming Guide to get a better understanding.
If you come from a SQL background, a relationship basically represents a FOREIGN KEY or join table, mapping objects from one another.
So let's say you have a Company which has many Employees. You create entities for the two types, and set up a one-to-many relationship between the company and employee (or even many-to-many if an employee works for multiple companies).
Using Core Data you can then easily add, remove, or otherwise access the employees for a given company.
So a relationship is used to associated instances of entities with one another.
Have a scenario with a client's new crm where they have suppliers and clients and a supplier is also a client and vice versa. Table per hierarchy will only allow a person to only be one or the other, so I assume table per type would be better suited.
The db structure would be:
[Contact]
ContactId pk
Name
...
[Client]
ContactId pk / fk
VATNumber
...
[Supplier]
ContactId pk / fk
...
Anyone have any other suggestions or experience from a similar scenario?
Table per type will also assume one Contact is either a client or a supplier (this is clearer if you look at the generated SQL: eg. see "Inheritance with EF Code First CTP5: Part 2 – Table per Type (TPT)").
Instead I think you need to change your model to be Contact and Contact-Role with a one to many relationship. Contact-Role would have the Supplier and Client subtypes. The whole Contact-Role hierarchy could then be mapped as TPH or TPT.
This reflects an OO design where each client has one or more roles (inheritance, "is-a" releationship, will always be singular, you cannot have an object of abstract type client that is simultaneously both subtypes of client).
This cannot work unless you model it as three level inheritance which would require that either client is always supplier or supplier is always client. I guess that is not correct model in your application which means you cannot use inheritance.
You have to either use one-to-one (0..1-1) relations between contact-client and contact-supplier or you can simply place all properties to single table and add IsClient and IsSupplier bit columns - it is not very nice and it is less extensible but it is very easy to use. These two bit columns can be useful in case of relational representation as well.