The ORM Foundation

Hi,

I'm working my way through this piece (its in the library), and i'v got a question regarding one of the examples.

On page 6 there's a facts set which I'm trying to module, just for practice. I'm not sure how the first fact, f9, should be modeled. Here's my suggestion, I'll appreciate your remarks:

it didnt paste it...well i added it attached, i hope it'll work.

Thanks!

here is the facts set:

f10 Professor ‘Codd EF' holds Chair ‘Databases'.

f12 Professor ‘Codd EF' heads Dept ‘Computer Science'.

f14 Dept ‘Computer Science' has senior lecturers in Quantity 9.

f16 Department ‘Computer Science' has lecturers in Quantity 8.

f17 Lecturer ‘Adams A' obtained Degree ‘MSc' from University ‘OXON'.

 and another one if i may, this time about the difference between values and entities. why can Rank be a valu refering to the entity Academic? 

thanks 

Dear Rolemo

There is more than one correct way to model information. If you want to model the fact f9 the way it was verbalized then the predicate reading should have been "has professors in" and the righthand object type would be Quantity, not PrfQuantity.

Notice fact s f14 and f16 are similar, except the predicate readings have "senior lecturers" and "lecturers" instead of "professors". An ORM transform allows you to replace the 3 binaries with a single ternary by introducing an object type to capture the academic rank, as indicated in your following post.

Cheers

Terry

Dear Rolemo

In this case we chose to identify ranks by rank codes (e.g. "SL" for Senior Lecturer). We could instead have identified ranks by rank names (e.g. "Senior Lecturer"). Modeling it this way, we are talking directly about the ranks, rather than codes or names. I think this is probably how most people would think of it. This also makes it easier to add fact types such as "Rank has RankName". However if you are not saying anything else about ranks, and you prefer the fact type "Academic has RankCode" instead of Academic has Rank, then you can model with a value type for RankCode.

Cheers

Terry

 thanks

Terry Halpin:

Dear Rolemo

There is more than one correct way to model information. If you want to model the fact f9 the way it was verbalized then the predicate reading should have been "has professors in" and the righthand object type would be Quantity, not PrfQuantity.

Notice fact s f14 and f16 are similar, except the predicate readings have "senior lecturers" and "lecturers" instead of "professors". An ORM transform allows you to replace the 3 binaries with a single ternary by introducing an object type to capture the academic rank, as indicated in your following post.

Cheers

Terry

Yes I've read it later in the article. You are saying that:

"Facts of the kind expressed in f9, f14 and f16 can now all be expressed in terms of the ternary fact type:

Dept employs academics of Rank in Quantity. For example, f9 can be replaced by:

f9' Dept ‘Computer Science’ employs academics of Rank ‘P’ in Quantity 5."

this explains some but also raised another question: aren't "academics" an entity? till I've seen it in this article, I didnt understand that the predicate may contain nouns, now i see many of your predicates does (e.g. the original f9: Dept ‘Computer Science' has professors in Quantity 5).

Dear Terry, I'm afraid I've got another one. kindly inform me when I'm becomming an annoyance....

well on the same article, I examined the ternary mentioned in my post above. i tried to insert it into the NORMA, please see below the results.

I know i've got something wrong, but i can't say what it is. here's the problem:

each Academic must have obtained at least one Degree. so far so good.

but this diagram is indicating that for each Academic, that Academic obtained that Degree from at most one University, whie i was aiming to indicate that that Academic obtained that Degree from one an d only one University.

 I tried to fix this, but so far can't get it right...

Cheers 

i'll appreciate your help also in figuring this sentance out (still from Terry's paper):

If a fact type is elementary all its functional dependencies (FDs) are implied by uniqueness constraints.

specifically, what are:

• elementary facts (and what other types of facts exist?)
• functional dependencies

and may i suggest that an ORM glossary/wiki should be implemented here somewhare?

 thanks again 

Dear Rolemo

Yes a predicate reading may contain nouns. In ORM, it is up to you what you wish to think of as an object (I call this "object relativity"). A predicate reading in ORM is the same as in predicate logic, viz. a sentence with object placeholders in it. You can phrase the sentence and choose the objects how you wish.

Cheers

Terry

Rolemo

Your ternray is correct as is. There are two constraints on it (a mandatory role constraint and a uniqueness constarint). When you combine the meaning of these constraints you obtain the meaning you were after (corresponding to a multiplicity constraint of 1 in UML -- we don't use UML's multiplicity constraint notation because it has several problems especially when n-aries are involved).

Cheers

Terry

Hi Rolemo

Facts may be compound or atomic. Atomic facts can't be rephrased as a conjunction of 2 or more smaller facts without information loss (with the same objects involved). Atomic facts are either elementary facts or existentail facts. Elementary facts apply a logical predicate to one or more objects, e.g.

The Country identified by the CountryCode 'US' is democratic (a unray fact);

The Politician named 'George W. Bush' is the preident of The Country identified by the CountryCode 'US' (a binary fact).

 The Sportsman named 'Don Bradman' played the Sport named 'Cricket' for the Country identified by the CountryCode 'US' (a ternary fact).

Existential facts simply assert the existence of an object, e.g.

There exists a Country that is identified by the CountryCode 'US' .

Given an attribute set X and an attribute Y, X functionally determines Y iff for each instance of X there is at most one instance of Y.

There is an ORM symbol glossary in the library.

You will find a glossary of ORM terms in the back of Information Modeling and Relational Databases.

Cheers

Terry