The ORM Foundation

Let's take as starting point the following simple model:

- Entity type 'Party'
- Entity type 'Partner', subtype of 'Party
- Entity type 'Customer', subtype of 'Party'
- Entity type 'Consumer', subtype of 'Customer'
- Entity type 'Business customer', subtype of 'Customer'

When making a relational mapping, I have one entity type 'Party'. That's OK.

Now I would expect in the entity type 'Party' a way to indicate what kind of party it is.

What is my wrong reasoning?

Do I have to add to the ORM model a fact type 'Party is of Party_Type' (with possible values of 'Party_Type': Partner, Consumer, Business customer)?

Jacob

Hi Jacob,

You're not missing anything. Single-table relational mapping with asserted subtypes that play no other roles is an undone in NORMA. The only way to generate this data right now is to push the asserted subtypes into a separate table. This can be done by choosing the subtype connector and setting the Relational Mapping AbsorptionChoice property to 'Not Absorbed' (selecting the subtype and setting the AbsorptionChoice to 'Separate' is an equivalent action).

The general solution to this problem is far from trivial because 'isSubtype' column falls into one of three categories:

• If the subtype plays no other roles, this is an asserted boolean column.
• If the subtype plays no mandatory roles, then the column is semi-derived (derivably true if any roles are played, asserted if no roles are played).
• If the subtype plays at least one mandatory role then the column is fully derived. However, the derivation may not be trivial because the mandatory role may be expressed outside the current table.

In most models, subtypes will actually play additional roles. In fact, Terry recommends not creating subtypes if they subtype plays no additional roles. The end result is that as the model matures, in practice you get very few subtypes with no role players.

If you find that you have a large subtype tree where the subtypes play no roles, you may want to consider a PartyType style fact type on the supertype.

The NORMA RMAP is still relatively basic. This is one area that those funding NORMA-related development have had little interest in for the past few years, but that is rapidly changing, so Terry (SQL guru) and I will be spending more time on this area in the next year.

-Matt

 Matt -

 Can you offer any guidance on the relative value of having / not having an 'isSubtype' column in the supertype table when a non-absorbed subtype has a mandatory role?  I am delving into MS Entity Framework (EF) on my project and am looking for 'good' practices. ('Best' practices will come over time).

I have chosen (for the time being) to not have any of my subtypes absorbed into their supertypes, (in order to reduce the number of nullable columns that will be generated), with the expectation that EF will easily reconstitute the appropriate entities.  It is my suspicion that the EF object hierarchy will have no great need of an explicit supertype->subtype relationship that an 'isSubtype' column would provide, i.e., that the implicit subtype->supertype relationship will suffice.

I appreciate any observations that you might be able to make.  (I have read selectively from Ch 6 and have only skimmed Ch 11 of the big brown book, so I apologize if my answers are contained there.) 

- Chris

p.s. One thing that I have really been enjoying is the ease with which I can modify my conceptual model, regenerate my database, and then regenerate my EF classes. 

Hi Chris,

I can only comment on this from a NORMA perspective, not EF, which I haven't needed to touch since its beta days. One of the final student projects at Neumont (2007 timeframe) was to directly generate entity framework xml from an ORM model, without needing to import from the database. I'm pretty sure I still have the code, but it was against a beta version of the framework, not quite finished, and never got checked in.

For NORMA, the problem challenge with subtype columns in a supertype table is that absorbed subtypes can be asserted, derived, or semi-derived depending on the situation in the model. For a normal subtype that actually plays some roles, you will generally get some additional columns in the supertype table. If an asserted subtype plays no roles, then you currently get nothing. Obviously, this is bad on my part. However, it is also generally considered poor modeling to introduce a subtype that plays no roles, so this is a relatively rare occurrence.

In an absorbed subtype, the 'isOfSubtype' column would be asserted if the subtype plays no roles beyond the subtype relationship, semi-derived if it plays no mandatory roles, and fully derived otherwise. Of course, the derivation is easiest if a mandatory played role is actually in the table (as opposed to in a join table, for example). Basically, I've punted this issue until I can generate derived columns because I can only do it half-baked without derivation support. So, if you have a subtype with no role players, use a unary fact type instead and you'll get an absorbed column, or separate the subtype table.

Having said that, if you have a separated table for the subtype then I see very little reason to have an 'isOfSubtype' column in the supertype table. In a query, the check is trivial and fast with an indexed join to the subtype table. If EF can be told to recognize the subtype without adding the noise in the database, then by all means do it.

Of course, you need to be very careful when translating ORM subtypes into anything in the OO space to be sure that the OO subtypes mean the same thing as in ORM. ORM subtypes imply that the subtype and supertype are the same instance and always of compatible conceptual types, whereas the OO subtyping paradigm can be used behaviorally, allowing an object to look and act like a duck even if isn't really a duck. The impedance mismatch is not as bad with single-inheritance systems (VB, C#) as with multi-inheritance, but it still requires care in translation.

-Matt

 Oops, I just noticed that I'm repeated myself and had said much of that earlier in this thread. Sorry about the excess verbosity.

Matt -

The problem with ignorance is that one answer generates another question...but I will try and contain myself. 

Matthew Curland:

If an asserted subtype plays no roles, then you currently get nothing. Obviously, this is bad on my part.

How is this bad, let alone obviously so?  If all that pertains to a subtype instance is the assertion that it is a subtype, then what more could you provide? Are you anticipating generating the IsOfSubtype column from the subtype's derivation note rather than explicitly adding it to the model via a role, or am I completely missing something?

 In any case, I will remove my 'has IsOfSubtype' fact types and see where EF takes me.  And, there is no need to apologize for verbosity - reading a slightly different explanation helps my comprehension.

- Chris 

Hello Chris,

Subtypes fall into two categories in ORM. Asserted subtypes don't need a derivation rule based on elements in the supertype: you just assert that you are of the supertype, and you are one. For a subtype that plays no other roles, another way to think about this is as a derived subtype based a unary fact type on the supertype. So, if 'A is a b' is a unary on A, then B can be a derived subtype with a derivation rule for the unary. So, when I say a subtype gets no columns if it plays no roles, in effect I'm saying that you don't get this unary, so there is no way to declare that you are of the subtype.

Note that in the future all of the derivations will be formally done, not just notes like they you have now. The notes are for your benefit only; the tool can do nothing with them. Definitions for formal derivation rules are already supported (loaded, verbalized, etc.) in the open source tool (the underlying structure is the same as with automatic join paths), but the current (and future) editors are not yet available. There's more info on what I'm doing behind the scenes at http://www.ormfoundation.org/forums/p/1054/3321.aspx#3321, but I think most people didn't read it because of the header (regarding shape coloring).

-Matt