The ORM Foundation

I'm converting an EERD diagram to ORM and have a couple of questions to how some fact types should be displayed.

If a value to an entity is to be derived, then should it still show the dot on the entity side as a mandatory required field. I have an age value but it won't be stored, it will be calculated from DOB.

In EERD multivalued attributes are shown with a double ringed oval, I've looked at at least 4 papers for ORM and not one covers how this should be displayed in the diagram, it will become its own entity and map to a table with an id as a reference but is there a better way to display this as the DB designer actually has choices and I would think this should be shown.

and finally Composite attributes. E.G Name, Address, in EERD they mess up all diagrams by having there values extend from the composite title. Some ORM papers show all the attributes and ignore the composite completely and others just show the composite title, some even show a mixture of both which is really confusing,

If someone could clarify any of the above methods I would be grateful.

Thank you.

Your post covers several points so, for clarity, I will respond with a separate post for each point.

If a value to an entity is to be derived, then should it still show the dot on the entity side as a mandatory required field. I have an age value but it won't be stored, it will be calculated from DOB.

The concept of "mandatory" is quite different from the concept of "derived and stored" as shown in the example in the attached diagram.

The first and second rows show the difference between a fact that uses the "mandatory dot" and one that does not.

First Row: If you omit the mandatory role constraint in the fact "Person has Age" then you are asserting that a person has "at most one" age.(See verbalization in the right hand column). This permits the state that a person may not necessarily have an age at all. In the real world, this is not possible.

Second Row: You express the constraint that a person must have an age by adding a mandatory constraint to the fact. You can see that the "at most one" verbalization in the right hand column has changed to "exactly one".    

Third row:   Here you can see that the act of adding a "Derivation rule" in the property sheet of the Fact Type (right hand column) causes an asterisk to appear against the "has" in the ORM diagram. If you just want "Derived" you get one asterisk. If you want "Derived and Stored" you would see two asterisks.

Hope this helps 

Ken

PS: If the diagram is a bit fuzzy, just click on it and you should see a clear image.

combitz:

In EERD multivalued attributes are shown with a double ringed oval, I've looked at at least 4 papers for ORM and not one covers how this should be displayed in the diagram, it will become its own entity and map to a table with an id as a reference but is there a better way to display this as the DB designer actually has choices and I would think this should be shown.

Please will you explain a little more about what you mean and what you are trying to achieve.

EERD? There are many different notations for showing "Entity Relationship" diagrams (which is what I assume to be the generic meaning of "EERD")
So please will you explain the meaning of this acronym. I am familiar with the use of "ER" and "ERD" but "EERD" is a new one on me.

Regarding the use of multi-valued attributes, pages 354-357 of Terry's 2008 book have a detailed explanation of how multivalued attributes are handled in ORM. However, Terry sums up his view of multivalued attributes on page 357 with the phrase: "...multivalued attibutes should normally be avoided in analysis models..." ...

Ken

combitz:

and finally Composite attributes. E.G Name, Address, in EERD they mess up all diagrams by having there values extend from the composite title. Some ORM papers show all the attributes and ignore the composite completely and others just show the composite title, some even show a mixture of both which is really confusing,

Sorry, but again I'd like to know a little more about what you mean by a "composite attribute"?
Do you have a reference to a book or paper where this term is used?"

However, since you mention "E.G. Name, Address,", I thought that the following diagram might be helpful. The diagram shows an example of how "Name and Address" would be handled in ORM.

Hope this helps.

Ken

Thank you for such a detailed answer.

I've been studying Database Design for the last 3 months and 9 weeks of it has been EERD, in the last 4 weeks they introduced ORM. Our assement is to compare both methods for an imaginary project which we had to produce originally in EERD format with a few queries thrown in for fun. So I've spent my Christmas getting stuck in, but these were some questions I had floating around in my head and other forums couldn't answer them. It has been a heck of a steep learning curve in 4 to 5 weeks with other modules too.

 For the multivalued attribute in Enhanced Entity Relationsal Modeling the entity is displayed in a double oval shape as below with prerequisite

This would then give the designer more choice as to how they wished to store the data, but in most cases it will become an entity itself and be stored as a reference with a unique id. This I feel is just a cop out, it lets the designer choose how to implement it allowing for potential missunderstanding.  Looking at the diagram (which is not mine) I would think this could be a many to many relationship but who knows? Each course may only have one prerequisite. So EERD fails to show this then.

The composite valued attributes I see are more detailed in ORM, what did suprise me is the address is shown as an object and the values part of it. If I can eventually remove all my errors, I can then see how this would map to tables as I would guess the address object would be ignored and its values added to the person object. we shall see.

I'm using the free unsupported MS Visio tool at the moment but I noticed many drawings are different from the version I am using. Is it me or is this adding to the possiblity for misunderstanding. After a second year of "look here" / "look there" EERD notation confusion I hope ORM will keep its clarity. 

Thanks again for your time.

Excellent resources, the NORMA tool should prove to be very powerfull/helpful in the future.

Thanks for the extra info.

I Googled EERD (Enhanced Entity Relationship Modeling) and came up with several hits.
For example http://www.is.informatik.uni-kiel.de/~thalheim/HERM/HERMindetail.pdf from which I extracted the following text for comment:

My first observation is that the thinking behind the EERD is TOTALLY different to the thinking behind ORM.

With ORM we have only three layers:

1: Conceptual: The set of facts that are meaningful to a domain expert.
2: Logical: An (automatic) transform of the conceptual model into a 5th normal form logical model (= a fully populated ER diagram if you prefer)
3: Physical: We use the logical model to generate DBMS specific DDL to create the DBMS catalog.

For example: I took row 1 from your EERD examples and created the following sequnce to show:

1: The ORM conceptual model diagram
2: The semantic meaning of the ORM diagram (we call this the "verbalization". It is very useful for checking semantics with non-technical domain experts) 
3: The logical (ER) model generated (automatically) from the ORM conceptual model.
(I could have easily generated the DDL as well)

At first glance, the EERD seems to me to be a mish-mash of confusing ideas represented by a mish-mash of confusing symbols.
But then unlike you, I have not spent nine weeks studying it

Ken