Dynamic Types within a Relational Model using Object-Role-Modeling (ORM)

Question

In Object Role Modeling (ORM), given an entity of thing that had a relationship to an entity of type and where the type entity can be specified to live and the thing entity could have a value for date of birth, how would I specify a constraint that would exclude instances of thing from having a value for date of birth if the instance of type associated with thing was not set to live. See Diagram Below...

ORM Diagram of Model to be constrained http://img197.imageshack.us/img197/6551/dynamictypeorm.jpg

The purpose behind my questions is to allow for the modeling of types within a system when it is unclear what the types will be, but characteristics of the types are known. Your answers do not need to be in terms of ORM if you feel there is a more applicable approach. Thanks for reading, hopefully you can help me.

Answer 1

The book that John Sanders has recommended is one of the best books I have ever read. Also, all your ORM questions can most likely be answered through a reading of it.

To directly answer you question though, (and sidestep any questions of the validity of the model), there are two obvious ways I see to constrain it as is.

We could use either a subset constraint or an equality constraint, depending on what it is you actually want to capture.

Assigning an equality constraint (Right) between the roles, we can generate a constraint that would conceptually require that any Thing of a living Type has a date of birth and that any Thing with a date of birth be of a living Type.

Assigning a Subset constraint (Left) between the roles, we can constrain the model such that any Thing of a Type with a DateOfBirth must be of a Type that is living. This, unlike the equality constraint will allow for things to be of a living type, but not have a date of birth.

additions:
To create these types of subset and equality constraints that will work, we need to use something called a 'Join Path'. Using a join path, we can create a Join-Subset Constraint and Join-Equality constraint that will span multiple roles on both sides of the constraint. Examples of join paths can at times be obvious and easy to follow. but can also get a little overwhelming and complex at times. Also of note, is that although NORMA does support creating join paths, in equality, subset, and exclusion constraints the verbilazation is not 100% complete for them, as explained here. This is also one of the reasons why it is easier to use Subsets at current, since it is easier to validate the correctness of the model conceptually.

To create a Join Path in NORMA when assigning the roles for a Subset, Equality, or Exclusion constraint first assign all roles that are part of a path with a single click, and then double click to move on to the next path. When the constraint is capable of join paths, the Roles involved in that constraint will be labeled [#.#] instead of just [#]. So when we are creating our constraints we can say here that roles [1.1]&[1.2] are a subset/equal to roles [2.1]/[2.1]. Note that the Facts playing a part in each role must also match. So he we get a verbalization from NORMA:
If some Thing has some DateOfBirth; some Thing is of some Type then that Thing is of some Type; that Type is living. Which is better stated as: If some Thing of some Type has some DateOfBirth; then that Type is living.

However, there is a third (and preferable) way that we could constrain this, which would be subtyping. Since things that are alive, and things that aren't alive are very different, we probably don't want to be mapping them to the same tables anyway. Here we split our Type fact into two subtypes, OrganicTypes and NonOrganicTypes. The Exclusive Or constraint between the two subtypes tells us that every type is either Organic or NonOrganic. and the Note tells us the Derivation Rule that we use for determining which group a type belongs to. From there, we redefine our [Thing is of Type] role to [LivingThing is of OrganicType]. and since OrganicThings by deffinition are capable of life, our constraint for DOB/is living is now built into the model.

Answer 2

Actually, there's more than one problem with your model, even as simple as it is. A thing may have a date of birth if it was ever living. It may once have been living, yet now be dead.

Also, you'll want to clarify whether the absence of the fact "Type lives" implies "Type does not live" (Closed World Assumption), or whether it only implies "Type is not known to live" (Open World Assumption, I think).

One additional concern I have is that your question seems to be somewhat confused, combining "relational model" and "ORM" in the same "sentence". Object-Role Modeling is a Conceptual modeling tool for creating conceptual models, which may then be mapped to a Relational schema. Even if you are reverse-engineering an existing Relational schema, it's best to use the schema as only part of the information you would use to create a correct Conceptual model. In addition, use examples of valid input and output, and also discussions with the domain experts. This will often help you discover important constraints which were not captured by the Relational schema, or which may have been captured incorrectly.

---

BTW, for an excellent ORM tool, see NORMA. It's an add-in to Visual Studio 2005 or 2008 (Standard Edition or above), and uses the modern ORM2 notation. It can generate SQL for several different databases, as well as ER diagrams and even code.

---

Also, see The Book:

Answer 3

In a database context, assuming that you have three separate tables, I would create a function that counts the number of rows in a join between the entity and its type. Use this function in the table holding the DOB to ensure that the DOB is null or the count is 1.

Pseudo-code:

 function fn_count_living(id)
     declare @count int
     select @count = count(*)
     from entities inner join types on entities.typeid = types.id
     where entities.id = id and types.living = 1
     return @count
 end

Constraint

 fn_count_living(entity_id) = 1 or dob is null

Answer 4

ORM (and domain model) as I understand them are both conceptual model, which are used to analyze the business domain, instead of designing solutions. At this layer, bringing in concepts like "types" or "dynamic types" are too early, and does not suit the purpose of the model.

From Object Role Modeling: An Overview

alt text http://i.msdn.microsoft.com/Aa290383.dv_vsea_ormoverview_06%28en-us,VS.71%29.gif

You can put an equality constraint (a dotted line with a circled “=” symbol) between "is alive" and "has date of birth." Similar to the "is tenured" and "is contracted till."