From the Grails documentation, by default one-to-many relationships are represented using a join table.
I don't understand why this is desirable. I had little SQL experience before starting to use Hibernate and/or Grails' GORM. It seems like using a foreign key in the 'many'-side table pointing at a row on the 'one'-side table is the way to implement a one-to-many relationship...
Can anyone explain this sort of design decision?
The reason for using an join table for a unidirectional one-to-many relationship is because the many side of the relationship may have many relationships and does not know of those relationships. Perhaps an example is best here:
class Book {
String title
}
class BookStore {
String name
static hasMany = [books: Book]
}
class Library {
String name
static hasMany = [books: Book]
}
In the above domain, a Book has no need to have both the BookStore and Library IDs on it's table. A Book is perfectly valid without either. By using join tables this keeps from polluting the book table with foreign keys.
Keep in mind because this is modeling uni-directional and not bi-directional relationships.
Related
I often see "linking" tables for M:N relationship, where N can be 1..X types of entities/classes, so that the table contains classNameId referring to ClassName table and classPK referring to the particular Entity table.
How is this called ? Does it have an alternative with the same effect without having the EntityName table ?
In the ER model, entities and subentities can be related by inheritance, the same way classes and subclasses are in an object model. The problem comes up when you transform your ER model into a relational model. The relational model does not support inheritance as such.
The design pattern is called is called generalization-specialization or gen-spec for short. Unfortunately, many database tutorials skip over how to design tables for a gen-spec situation.
But it's well understood.It looks quite different from your model, but you could create views that make it look like your model if necessary. Look up "generalization specialization relational modeling" for explanations of how to do this.
The main trick is that the specialized tables "inherit" the value of their primary key from the PK of the generalized table. The meaning of "inherit" here is that it's a copy of the same value. Thus the PK in each specialized table is also an FK link back to the correpsonding entry in the generalized table.
I have a few tables that share only a few navigation properties and an ID.
I think Table per Concrete type inheritance would be interesting here.. (?)
It looks something like this :
Contact (Base, Abstract, not mapped)
- ContactID
- navigation properties to other tables (email, phone, ..)
Person : Contact (mapped to table Person with various properties + ContactID)
- various properties
Company : Contact (mapped to table Company with various properties + ContactID)
- various properties
Now for this to work, the primary key (contactID) should be unique across all tables.
2 options then:
- GUIDs (not a fan)
- an additional DB table generating identities (with just a ContactID field, deriving tables have FK), this would not be mapped in EF.
Is this setup doable ?
Also, what will happen in the ObjectContext ? What kind of temporary key does EF generate before calling SaveChanges ? Will it be unique across objects ?
Thanks for any thoughts.
mike.
We use a similiar construction with the folowing db design:
ContactEntity
ID
ContactPossibility
ID
Position
ContactTypeID
ContactEntityID
Address
ID (=PK and FK to ContactPossibility.ID)
Street
etc.
Telephone
ID (=PK and FK to ContactPossibility.ID)
Number
etc.
Person
ID (=PK and FK to ContactEntity.ID)
FirstName
etc.
Company
ID (=PK and FK to ContactEntity.ID)
Name
etc.
This results in the entity model in two abstract classes: ContactEntity (CE) & ContactPossibility (CP) and multiple derived classes (Address=CP, Email=CP, Person=CE, Company=CE). The abstract and derived classes (rows in the db ;) share the same unique identifier, because we use an ID field in derived classes that's a foreign key to the primary key of the abstract class. And we use Guid's for this, because our software has the requirement to function properly off-line (not connected to the main database) and we have to deal smoothly with synchronisation issues. Also, what's the problem with Guid's?
Entity Framework does support this db / class design very good and we have a lot of pleasure from this design.
Is this setup doable ?
Also, what will happen in the ObjectContext ?
What kind of temporary key does EF generate before calling SaveChanges ?
Will it be unique across objects ?
The proposed setup is very very doable!
The ObjectContext acts fine and will insert, update and delete the right tables for derived classes without effort. Temporary keys? You don't need them if you use the pattern of an ID for derived classes that is both primary key and foreign key to the abstract class. And with Guid's you can be pretty sure that's unique across objetcs.
Furthermore: The foreignKey from CP to CE will provide every CE (Person, Company, User, etc.) with a trackable collection of ContactPossibilities. Which is real cool and handy.
Hope this helps...
(not enough space in the comments section)
I've been running some tests.
The thing is you're OK as long as you ONLY specify the subtype you're querying for (ex. 'Address' in your case).
But if you query for the base type (even if you don't need the subtypes info), ex. only ContactPossibility.ID, the generated SQL will UNION all subtype tables.
So querying your 'trackable' collection of ContactPossibilities can create a performance problem.
I tried to work around this by unmapping the base entity and split the inherited entities to their own table + the common table, basically transforming the TPT into TPC : this worked fine from a conceptual perspective (after a lot of edmx editing). Until I realized this was stupid... :) Indeed in that case you will always need to Union all underlying tables to query for the common data...
(Though I'm not sure in the case described at the end of this post, didn't pursue to test it)
So I guess, since mostly I will need to query for a specific type (person, company, address, phone,..), it's gonna be OK for now and hoping MS will come with a fix in EF4.5.
So I'll have to be careful when querying, another interesting example :
Let's say you want to select a person and then query for his address, something like (tried to follow your naming) :
var person = from b in context.ContactEntities.OfType-Person-()
where b.FirstName.StartsWith("X")
select b;
var address = from a in context.ContactPossibilities.OfType-Address-()
where **a.ContactEntity == person.FirstOrDefault()**
select a;
this will produce a Union between all the tables of the Contact derived entities, and performance issues : generated SQL takes ContactPossibility table and joins to Address on ContactPossibilityID, then joins a union of all Contact derived tables joined with the base Contact table, before finally joining a filtered Person table.
However, consider the following alternative :
var person = from b in context.ContactEntities.OfType-Person-()
where b.FirstName.StartsWith("X")<BR>
select b;
var address = from a in context.ContactPossibilities.OfType-Address-()
where **a.ContactID == person.FirstOrDefault().ID**
select a;
This will work fine : generated SQL takes ContactPossibility table and joins to Address on ContactPossibilityID, and then joins the filtered Person table.
Mike.
There are several approaches how to store entities hierarchy in relation database
For example there is person entity (20 basic attributes), student entity (the same as person but several new specific fields are present), employee (the same as person but some new fields are present) e.t.c.
When you advice to use (and not to use) the following data modeling approaches:
One big table with all possible fields + personType marker field (student or employee)
Table inheritance
One Table with XML field (or maybe another data type) to store all the custom fields
Something else but also relational...
Thank you in advance!
A database models facts, not objects, and each table should model a relatively self-contained set of facts. The consequence of this is that your tables should look something like this:
person { person_id PK, name, dob, ... }
student { person_id PK FK(person.person_id), admission_id, year_started, ... }
employee { person_id PK FK(person.person_id), salary_bracket, ... }
An additional consequence is that a student can also be an employee, which probably models real life closer than an inheritance graph would.
Have a look at the hibernate inheritance mapping docs. There you find three common approaches and a list of pros and cons of each.
If you are using an ORM to implement your classes, the ORM tools you are using will provide you options, generally two options, one class one table or one parent class one table and each table for each children class. I am using XPO from Devexpress.com, one ORM framework. It offers these two options.
If you use ORM, I am afraid there are no other generic options.
Ying
I'm using NHibernate (fluent) to access an old third-party database with a bunch of tables, that are not related in any explicit way. That is a child tables does have parentID columns which contains the primary key of the parent table, but there are no foreign key relations ensuring these relations. Ideally I would like to add some foreign keys, but cannot touch the database schema.
My application works fine, but I would really like impose a referential integrity rule that would prohibit deletion of parent objects if they have children, e.i. something similar 'ON DELETE RESTRICT' but maintained by NHibernate.
Any ideas on how to approach this would be appreciated. Should I look into the OnDelete() method on the IInterceptor interface, or are there other ways to solve this?
Of course any solution will come with a performance penalty, but I can live with that.
I can't think of a way to do this in NHibernate because it would require that NHibernate have some knowledge of the relationships. I would handle this in code using the sepecification pattern. For example (using a Company object with links to Employee objects):
public class CanDeleteCompanySpecification
{
bool IsSatisfiedBy(Company candidate)
{
// Check for related Employee records by loading collection
// or using COUNT(*).
// Return true if there are no related records and the Company can be deleted.
// Hope that no linked Employee records are created before the delete commits.
}
}
I'm hoping someone can help me with mapping a legacy database. The
problem I'm describing here has plagued others, yet I was unable to
find a real good solution around the web.
DISCLAIMER: this is a legacy DB. I have no control over the composite
keys. They suck and can't be changed no matter much you tell me they
suck. I can't add surrogate keys either. Please don't suggest either of these as they are not options.
I have 2 tables, both with composite keys. One of the keys from one
table is used as part of the key to get a collection from the other
table. In short, the keys don't fully match between the table.
ClassB is used everywhere I would like to avoid adding properties for
the sake of this mapping if possible.
public class ClassA
{
//[PK]
public string SsoUid;
//[PK]
public string PolicyNumber;
public IList<ClassB> Others;
//more properties....
}
public class ClassB
{
//[PK]
public string PolicyNumber;
//[PK]
public string PolicyDateTime;
//more properties
}
I want to get an instance of ClassA and get all ClassB rows that match
PolicyNumber. I am trying to get something going with a one-to-many,
but I realize that this may technically be a many-to-many that I am
just treating as one-to-many.
I've tried using an association class but didn't get far enough to see
if it works. I'm new to these more complex mappings and am looking
for advice. I'm open to pretty much any ideas.
Thanks,
Corey
The easiest way to handle mapping legacy database schemas is to add a surrogate generated primary key (i.e. identity in SQL Server) to each database table and change your existing composite primary keys to unique constraints. This allows you to keep your existing foreign keys and makes the NHibernate mapping easy.
If that's not possible then you may be able to use property-ref in your mappings to accomplish this.
Edit: You can always fall back to an anemic domain model. That is, map each class but exclude the relationships. You would have one data access method to get ClassA by key, and one to get a collection of ClassB by PolicyNumber.
I was eventually able to get the DB team to concede to adding some surrogate keys to the tables I was dealing with. This is the document I used to plead my case.