I need to model a large number of tables in my domain... I am trying to figure out how to correctly normalize the following:
I have Address Entity which is Abstract
StreetAddress and POBoxAddress are derived from Address
Many other entities in this domain will need a collection of addresses for instance:
Vendor.Addresses
CondoComplex.Addresses
Employee.Addresses
PositionShift.Addresses
Location.Addresses
Guest.Addresses
Property.Addresses
Owner.Addresses
etc... many other enities... So I am confused on how to store these associations in EF ? As a many to many tph with a discriminator column or am I just missing the forest for the trees and there is an less complex solution ?
Inheritance is overused in entity mappings (indeed, it's overused in general, but especially in the case of mapped objects, which aren't really strongly OO in the first place and shouldn't generally have behaviors). Most of the time, you should avoid it, as it makes queries and data structures far more complicated. Do you really need two different types for StreetAddress and POBoxAddress? Why? The Post Office won't care.
There needs to be a clear, compelling case for inheritance before you take that complexity into your model. In this case, you not only don't have it, but your question indicates that you have a strong case for not using inheritance here at all.
Leaving the case of complexity of your Address entity aside, if related entities are not going to share Addresses I don't think there's a point in creating many to many relationship. I'm not sure how your abstract Address class looks like, but I would go simply with
public List<Address> Addresses {get;set;}
in your entities
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.
First time posting here as I was told to seek help from this community if I was ever stuck!!
I was recently introduced to databases this semester and I have a hard time grasping the bridge entity that is meant to erase the many-to-many relationships.
The classic example would be the relationship between STUDENT and CLASS;
where STUDENT can be in many CLASSES and a CLASS can have many STUDENTS.
The M-M relationship is fixed by introducing the ENROLL entity. Here we would read: a STUDENT can ENROLL in many CLASSES, and a CLASS may have many STUDENTS ENROLLED in it, however each STUDENT can be ENROLLED in a CLASS only once.
In my case, I tried to fix a M-M relationship issue between PRODUCT and RAW MATERIAL for a pharmaceutical company by introducing an INGREDIENT entity, which looks like this:
RAW MATERIAL 1----M INGREDIENT M----1 PRODUCT
I am not sure if the bridge works out because I have trouble interpreting it like the STUDENT-CLASS example above.
How would you interpret this?
The concept of "bridge" or "associative" entities came from network data modeling and was a way of handling many-to-many binary as well as ternary and higher relationships. Network data modeling is a simple physical data model based on representing entities as records and relationships as references/pointers.
Since the 1970s, the relational model of data has been developed which uses relations (tables) to record relationships between sets of values (which represent business entities, measurements and labels), allowing for the direct representation of many-to-many relationships and ternary and higher relationships.
The entity-relationship model was an attempt to provide more conceptual structure on top of the relational model, by distinguishing entity relations from relationship relations.
My point with the history is that in modern data modeling, we no longer resolve or erase many-to-many (or ternary or higher) relationships (unless you're using an object-relational mapper or framework based on the network data model). Tables with composite keys, consisting of two or more entity keys, directly represent relationships, and allow us to handle attributes on relationships as well, another feature missing from network data modeling.
In your case, it may be useful to add a Quantity attribute on your Ingredient relationship. The interpretation here is that Raw material refers to a type of material rather than a specific piece or selection of raw material. Students have identity, raw materials generally don't.
Note that pharmaceutical companies may well track specific batches of raw materials.
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 thought I'll post this to the community. I am using coredata, and have two entities. Both entities have a hierarchical relationship. I am noticing quite a lot of duplicated functionality now, and am wondering if I should re-structure to have a base Entity which is abstract (HierarchicalObject), and make my entities inherit from them.
So the question is are there some limitations of this inheritance that I should take into account? Reading some of the posts out there, I see a few trade-offs, let me know if my assumptions are correct.
(Good) clean up structure, keep the HierarchicalObject functionality in one spot.
(Ok) With inheritance, both objects now end up in the same sqlite table (I am using Sqlite as the backend). So if the number of objects grow, search/sorting could take longer? Not sure if this is a huge deal, as the number of objects in my case should stay pretty static.
(not so good) With inheritance, the relationship could get more complicated? (http://www.cocoadev.com/index.pl?CoreDataInheritanceIssues)
Are there other things to take into account?
Thanks for your comments.
I think it's a mistake to draw to close a parallel between entities and classes. While very similar they do have some important differences.
The most important difference is that entities don't have code like a class would so when you have entities with duplicate attributes, your not adding a lot of extra coding and potential for introducing bugs.
A lot of people believe that class inheritance must parallel entity inheritance. It does not. As a long as a class descends from NSManagedObject and responds to the right key-value messages for the entity it represents, the class can have many merry adventures in it's inheritance that are not reflected in the entities inheritance. E.g. It's fairly common to create a custom base class right below NSManagedObject and the have all the subsequent managed object subclasses inherit from that regardless of their entities.
I think the only time that entity inheritance is absolutely required is when you need different entities to show up in the same relationship. E.g:
Owner{
vehical<-->Vehical.owner
}
Vehical(abstract){
owner<-->Owner.vehical
}
Motocycle:Vehical{
}
Car:Vehical{
}
Now the Owner.vehical can hold either a Motocycle object or a Car object. Note that the managed object class inheritance for Motocycle and Car don't have to be same. You could have something like Motocycle:TwoWheeled:NSManagedObject and Car:FourWheeled:NSManagedObject and everything would work fine.
In the end, entities are just instructions to context to tell it how the object graph fits together. As long as your entity arrangement makes that happen, you have a lot flexibility in the design details, quite a bit more than you would have in an analogous situation with classes.
I thought it would be useful to mention that the Notes app on iOS 10 uses inheritance in its Core Data model. They use a base entity SyncingObject, that has 7 sub-entities including Note and Folder. And as you mentioned all of these are stored in the same SQLite table which has a whopping 106 columns, and since are shared among all entities most are NULL. They also implemented the folder-notes one-to-many relation as a many-to-many which creates a pivot table, which might be a work-around for an inheritance problem.
There are a couple of advantages to using entity inheritance that likely outweigh these storage limitations. For example, a unique constraint can be unique across entities. And a fetch request for a parent entity can return multiple child entities making UI that uses fetched results controller simpler, e.g. grouping by accounts or folders in a sidebar. Notes uses this to show an "All Notes" row above the Folder rows which is actually backed by an Account.
I have had issues in the past with data migration of models that had inheritance - you may want to experiment with that and see if you can get it to work.
As you noted also, all objects go in one table.
However, as Core Data is managing an object graph, it is really nice to keep the structure the way you would naturally have it just modeling objects - which includes inheritance. There's a lot to be said for keeping the model sane so that you have to do less work in maintaining code.
I have personally used a fairly complex CD model with inheritance in one of my own apps, and it has worked out OK (apart from as I said having issues with data migration, but that has been so flakey for me in general I do not rely on that working any longer).
I am currently reading about the possibility about using inheritance with Entity Framework. Sometimes I use a approch to type data records and I am not sure if I would use TPT or TPH or none...
For example...
I have a ecommerce shop which adds shipping, billing, and delivery address
I have a address table:
RecordID
AddressTypeID
Street
ZipCode
City
Country
and a table AddressType
RecordID
AddressTypeDescription
The table design differs to the gerneral design when people show off TPT or TPH...
Does it make sense to think about inheritance an when having a approach like this..
I hope it makes sense...
Thanks for any help...
When considering how to represent inheritance in the database, you need to consider a few things.
If you have many different sub classes you can have a lot of extra joins in queries involving those more complex types which can hurt performance. One big advantage of TPH is that you query one table for all types in the hierarchy and this is a boon for performance, particularly for larger hierarchies. For this reason i tend to favour that approach in most scenarioes
However, TPH means that you can no longer have NOT NULL fields for sub types as all fields for all types are in a single table, pushing the responsibility for data integrity towards your application. Although this may sound horrible in practice i haven't found this to be too big a restriction.
However i would tend to use TPT if there were a lot of fields for each type and that the number of types in the hierarchy was likely to be small, meaning that performance was not so much of an issue with the joins, and you get better data integrity.
Note that one of the advantages of EF and other ORMs is that you can change your mind down the track without impacting your application so the decision doesn't need to be completely carved in stone.
In your example, it doesn't appear to have an inheritance relationship, it looks like a one to many from the address type to the addresses
This would be represented between your classes something like the following:
Address.AddressType
AddressType.Addresses
As Keith hints, this article suggests TPT in EF scales horribly, but I haven't tried it myself.