What kind of relationships are called n-ary relationships??
Not sure what you mean by the term "n-ary", but normally relationships that both sides can have many of the other are termed many to many relationships and those that only one side does are termed one to many.
Related
I'm using EF 6 Code First, and I'm facing a design decision:
The entity model
I have an abstract entity which is realized by several concrete ones, each of which add several attributes to the entity. I have polymorphic associations (base class has several related entities), so when mapping this in EF, it makes a clear case for TPT inheritance. (More info here for readers: http://weblogs.asp.net/manavi/archive/2010/12/28/inheritance-mapping-strategies-with-entity-framework-code-first-ctp5-part-2-table-per-type-tpt.aspx)
The issue with TPT design
What I'm concerned about, is that I have several cases where I only need to process data on the base class. To be specific, I have several scheduled batch processes that need to load the entities and perform calculations and updates.
TPT inheritance will cause performing JOIN on all sub-type tables, which is unnecessary for my case.
Second design option
My second option is to create separate concrete entities for parent and child types, and forget about the inheritance altogether.
From the SQL point of view, these designs will be equivalent. From the object-oriented point of view, this option is less correct. Plus, reaching child entities from the parent is not clean enough.
When to use which design?
Personally, I'm leaning toward the second design (associations) because most of my cases would be easier and simpler. (Less logic handled by the ORM tool means more control and simplicity).
My question is when to use which design.
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
What exactly is meant by owned and unowned relationships? These terms are often used in JPA/JDO documentation, but I haven't found a good definition of them.
In addition to Nix's anwser, in JPA this term sometimes is used in different meaning - relationship is said to be owned by an entity if that entity is an owning side of the relationship, i.e. a side which defines the state of the relationship to be persisted.
There tons of good definitions out there on Owned/Unowned Relationships.
Google App Engine Entity Relationships in JDO:
A relationship between persistent objects can be described as owned, where one of the objects cannot exist without the other, or unowned, where both objects can exist independently of their relationship with one another
In Core Data, most of the time relationships are modeled bidirectional. But the docs say in another place:
It typically only makes sense to model
a to-one relationship in one
direction.
Within Core Data you should always use a bi-directional relationship unless you have an extreme edge case. If you use one directional relationships then you are going to incur performance penalties within core data itself as well as have issues with referential integrity.
Unless you know specifically why you need a uni-directional relationship then you should always do a bi-directional relationship; the rule is that simple.
While Franci's answer is interesting, I have to disagree with it. Even in the examples he provided you should have a bi-directional relationship. There are almost no situations where a uni-directional relationship is going to be a better fit.
The answer is determined by the referential integrity requirements you want to enforce. If updating or removing the object on either side affects the object on the other side of the relationship, you need two-way. However, if updating/removing the object on one side does not affect the object on the other, then a one way is a better model.
Take for example a parent-children model with a 0..n : 1 cardinality (I prefer the 1 : 0..n representation, but for the sake of argument let's reverse it). Adding a new child, updating an existing child or deleting a child has no effect on the parent object, so there's no need for the parent to know explicitly about all the children (except when it comes time to pay college tuition). However, removing the parent has an adverse effect on the children objects, as they need to be deleted or re-parented, otherwise are orphaned and in an invalid state. Thus, it's better to model it as a one-way relationship. Another example is inventory - parts catalog relationship, again with 0..n : 1 cardinality.
It's a matter of ownership: usually it doesn't make sense to have a bidirectional relationship because an entity conceptually owns the other one.
Think about some examples. If you have a structure in which you have users and an user can have a simple bank account associated with him. If you make the relation bidirectional you mean that an user owns an account but also an account owns an user.
This will make sense because you don't want to delete an user whenever you delete his account. That's why usually you don't need to have it bidirectional: because it's an additional constraint that is not needed since most of the time you will have an entity that has the other but not vice-versa.
I think you read the whole document about relations you referenced in your question.
The document also describes all disadvantages of using unidirectional relations, and that only under very rare circumstances it makes sense to create unidirectional relations.
As a general rule i would strongly recommend creating bidirectional relations, except you are knowing exactly why not to do so.
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.