in

The ORM Foundation

Get the facts!

orm notations misunderstanding

Last post 05-12-2013 14:17 by Ken Evans. 14 replies.
Page 1 of 1 (15 items)
Sort Posts: Previous Next
  • 10-12-2008 16:58

    orm notations misunderstanding

    hi,

    well its my first visit here, i must say that the forum seems knid of a lonely place...

    anyway, what i wa nted to ask about re the uniqness arrows. you know, the small ones just abouve the facts box. thing is i cant understand why not to use the UML [0...1], [1...*] etc. theseare much more precisr and easier to follow.

     

    thanks

     

  • 10-13-2008 6:29 In reply to

    Re: orm notations misunderstanding

    "i cant understand why not to use the UML [0...1], [1...*] etc. theseare much more precisr and easier to follow."

    Your question raises the deeper question of "What is the difference between UML and ORM?".
    Two simple answers to this question are that:
    1: ORM is more expressive than UML
    2: The object-role modeling process produces models with fewer errors. 

    For example: one of the problems with the UML multiplicity notation is that it bundles together the concepts of "mandatory" and "uniqueness". This means that UML cannot be used to capture some constraints and so in this regard, ORM is more expressive. 

    "...there are many cases with n-ary associations where the multiplicity notation of UML is incapable of capturing even a simple mandatory role constraint, of a minimum frequency constraint above 1." (Halpin 2008:361) 

    The "UML vs ORM" question has many aspects and I have only mentioned some simple ones in this post.

    You can find in-depth information in two places:  
    1: The Big Brown Book (Halpin & Morgan 2008) has a 52 page chapter that compares UML and ORM.
    2: The library in this website contains several articles that compare UML and ORM.

    Terry Halpin will probably add something to my comments but he is in a USA time-zone so he won't see your post for at least another four hours.

    Hope this helps

    Ken

    Reference:
    Halpin, T. & Morgan,T. 2008, Information Modeling and Relational Databases: Second Edition, Morgan Kaufmann (Click on the link on the home page)

     

  • 10-13-2008 14:29 In reply to

    Re: orm notations misunderstanding

     As Ken indicated, there are major problems with the UML multiplicity notation. Unlike ORM and Barker ER, UML combines the global notion of mandatory with the local notion of frequency in a single concept of multiplicity. While this works reasonably well for binary associations, it leads to all kinds of problems with n-ary associations, with the result that many mandatory and frequency constraints that are trivial to express in ORM cannot be expressed at all with UML's multiplicity notation. The semantics for UML multiplicity on n-aries is also unfortunate,with the result that even some experienced UML users misunderstand what the constraint really means for certain n-ary cases.

    Apart from being more expressibve, the ORM uniqueness, frequency, and mandatory constraint notation is expressly designed to facilitate validation by population.

    If you still want to see a cardinality marker at the ends of associations, I suggest you turn on the crowsfoot option (while the crowsfoot notation is popular in ER, it was actually invented by Gordon Everest, an ORM practitioner and educator). To turn on this option, choose Tools > Options > ORM Designer > Entity Relationship Learning Mode > Binary Fact Type Multiplicity Display > On.

    Cheers

    Terry

  • 10-15-2008 1:37 In reply to

    Re: orm notations misunderstanding

    thanks!

    your answers comvinced me that i must improve my understanding of both ORM and UML. to be honest i'm using mainly ORM, and im not sure im allways keeping with the rules. i've looked arround for a good guide book, havnt yet found one. I've heard about the big brown one, tempting as it sounds, i figure it's scope is still beyond my current level of knowledge. could you recommend a strait forward source for novices? something that will focus on the notations, rules, and practicalities?

     

    best regards

  • 10-15-2008 5:50 In reply to

    Re: orm notations misunderstanding

    You say that you are "using mainly ORM"
    You can help the ORM experts to help you if you mention which ORM tool you are using.

    What are you trying to model with UML?
    Are you using the "Use Case First" approach? (described at:  http://www.ibm.com/developerworks/rational/library/5383.html )

    Regarding books, the "Big Brown Book" is the reference book on ORM. However, I can see how it might appear to be challenging for a novice.

    Unfortunately a "straight forward ORM book for Novices" dos not exist.
    However, if you can post a few (say 12) questions that you think such a book should cover, then someone might write one.

    Here are some comments as a starter:
    Notation & Rules:  
    When you build an object-role model you are (in effect) creating a formal representation of an information domain (A Universe of Discourse)
    The word "formal" refers to "formal logic" so one way of looking at ORM notation is that it is a "logic shorthand".
    Thus it will help if you begin by getting an outline understanding of  first order predicate logic. (Which is what ORM implements)

    Practicalities:
    To get a "practical" understanding of ORM I don't see much alternative to using an ORM tool to solve one or more modeling problems.
    We wrote "Database Modeling with Microsoft Visio for Enterprise Architects" to meet the need for a "practical user guide" to using the VEA tool.
    To the best of my knowledge, this is the only "practical how-to ORM" book on the market. Of course you need the VEA tool to make use of it.

    Here is a summary of what you can do with VEA:

    Create conceptual models (ORM)
    Create logical models (ER, IDEF1X) and generate physical databases
    Reverse engineer a database schema to a logical model
    Import ERwin ERX files
    Export ERwin ERX files
    Import VisioModeler files
    Publish diagrams in HTML
    Reverse engineer a physical database schema into ORM
    Generate database schema and DDL scripts from conceptual and physical models
    Check models for errors
    Generate reports

    Hope this helps

    Ken

  • 10-15-2008 14:10 In reply to

    Re: orm notations misunderstanding

    Ken Evans:

    Unfortunately a "straight forward ORM book for Novices" dos not exist.
    However, if you can post a few (say 12) questions that you think such a book should cover, then someone might write one.

     

     

    Good news! I am working on an introductory level ORM book, and I may not be the only person to be doing so. After I started on mine, one other person mentioned to me that he was also thinking about writing one.

    Unfortunately, I still have a lot more writing and rewriting to do, so the book will not be finished soon. At this stage, I would be very much interested in suggestions on what you all think such a book should cover. (I would prefer to hear your suggestions before I finish, but would appreciate them even after.)

    rolemo, Don't give up on the Brown Book. You might have to scan or skip over some sections, but the information you need is probably there and is likely to be clearly written with many good examples.

  • 10-15-2008 17:34 In reply to

    Re: orm notations misunderstanding

    Hi Ken, Thanks! This is really helpful. The IBM piece is exactly the kind of stuff I’m looking for. I’ll be happy to supply some further details. I’m managing a group of 5 programmers, our main business is building small-medium size, “tailor made” Learning Management Systems (LMS). Our systems serve national and global organizations, to distribute and monitor training (mainly e-learning) and other forms of knowledge (articles, guides, messages, forums, certifications…you name it). The average project lasts a year or so.  Till not long ago we weren’t using any formal modeling technique. We simply learned the customer’s needs, listed them and provided solutions. Sure we used diagrams and tables and lists, my team produced Classes diagrams and ERDs when needed, but not systematically. As projects’ scope keeps growing, we’re leaving behind asp spaghetti codes and entering the .NET, c# arena. And I’m afraid to say I know very little programming, if at all.   Now I think my case might be somewhat exceptional here, since my current focus is less on ORM’s contribution to improving the code or software, and more to the benefits that might be derived for ORM from a  project management angle. I fined that visual modeling of the logical structures forming the Universe of Discourse we’re dealing with is extremely helpful in:
    1. Clarifying – defining the logical structure, making our assumptions explicit and discussable, exposing latent mistakes made by us or the customer. Mainly in the early stages of the project.
    2. Scope monitoring – as diagrams offer a concrete and clear definition for otherwise obscure ideas and processes (no matter how many word are used – there’s always an interpretation you haven’t considered), they provide a baseline to which future versions can be compared, making any deviations clearly visible. This is extremely valuable, as scope creep is a serious problem.
     So recently I started using MS VISIO 2007 to build ORM’s portraying the entities, facts and so forth. I build it early in the process, present it to the customer, and make it a subject of our discussion. You may say that the final ORM is the final milestone of the requirements analysis.  Now regarding the article you recommended, I guess you can say that we use some form of use case first, but I must say I was surprised to read the method as described in the article. I haven’t yet read the whole thing (apparently there’s a part 2), but I fail to understand how he jumps from use cases to writing code so fast. When exactly do they stop to consider the whole formation of classes? Maybe I better read more first, because from what I’ve read so far it sound almost as if they’re writing a separate application for each use case, and I can’t believe that’s the case. As for your generous suggestion that I’ll hand the 12 questions that’ll form the ORM “for dummies” – I’m honored J I hope it’ll be fine if they’ll come one at a time, and I’m taking the liberty to invite all who reads this to join in. For the moment’ I’ll need to learn some more. And actually, here is my first question: I’ve just installed VS 2005, then downloaded NORMA for vs2005 from the library (filename: NORMA_VS-2008-05CTP.VS2005), opened it and installed. Now here is the problem – I can not understand how to open the NORMA tool and use it. If I go to Help > About MS Visual Studio, it lists NORMA as installed, so It seems everything is working fine.  Once again – thanks J

     

    Filed under: , ,
  • 10-15-2008 17:34 In reply to

    Re: orm notations misunderstanding

    Hi Ken, Thanks! This is really helpful. The IBM piece is exactly the kind of stuff I’m looking for. I’ll be happy to supply some further details. I’m managing a group of 5 programmers, our main business is building small-medium size, “tailor made” Learning Management Systems (LMS). Our systems serve national and global organizations, to distribute and monitor training (mainly e-learning) and other forms of knowledge (articles, guides, messages, forums, certifications…you name it). The average project lasts a year or so.  Till not long ago we weren’t using any formal modeling technique. We simply learned the customer’s needs, listed them and provided solutions. Sure we used diagrams and tables and lists, my team produced Classes diagrams and ERDs when needed, but not systematically. As projects’ scope keeps growing, we’re leaving behind asp spaghetti codes and entering the .NET, c# arena. And I’m afraid to say I know very little programming, if at all.   Now I think my case might be somewhat exceptional here, since my current focus is less on ORM’s contribution to improving the code or software, and more to the benefits that might be derived for ORM from a  project management angle. I fined that visual modeling of the logical structures forming the Universe of Discourse we’re dealing with is extremely helpful in:
    1. Clarifying – defining the logical structure, making our assumptions explicit and discussable, exposing latent mistakes made by us or the customer. Mainly in the early stages of the project.
    2. Scope monitoring – as diagrams offer a concrete and clear definition for otherwise obscure ideas and processes (no matter how many word are used – there’s always an interpretation you haven’t considered), they provide a baseline to which future versions can be compared, making any deviations clearly visible. This is extremely valuable, as scope creep is a serious problem.
     So recently I started using MS VISIO 2007 to build ORM’s portraying the entities, facts and so forth. I build it early in the process, present it to the customer, and make it a subject of our discussion. You may say that the final ORM is the final milestone of the requirements analysis.  Now regarding the article you recommended, I guess you can say that we use some form of use case first, but I must say I was surprised to read the method as described in the article. I haven’t yet read the whole thing (apparently there’s a part 2), but I fail to understand how he jumps from use cases to writing code so fast. When exactly do they stop to consider the whole formation of classes? Maybe I better read more first, because from what I’ve read so far it sound almost as if they’re writing a separate application for each use case, and I can’t believe that’s the case. As for your generous suggestion that I’ll hand the 12 questions that’ll form the ORM “for dummies” – I’m honored J I hope it’ll be fine if they’ll come one at a time, and I’m taking the liberty to invite all who reads this to join in. For the moment’ I’ll need to learn some more. And actually, here is my first question: I’ve just installed VS 2005, then downloaded NORMA for vs2005 from the library (filename: NORMA_VS-2008-05CTP.VS2005), opened it and installed. Now here is the problem – I can not understand how to open the NORMA tool and use it. If I go to Help > About MS Visual Studio, it lists NORMA as installed, so It seems everything is working fine.  Once again – thanks J

     

    Filed under: , ,
  • 10-15-2008 17:53 In reply to

    Re: orm notations misunderstanding

    To get started with NORMA, I suggest you work through the NORMA Labs that I uploaded to the ORM Foundation. You can find them in the Library.

     

    Cheers

    Terry

  • 10-15-2008 18:03 In reply to

    Re: orm notations misunderstanding

     good news indeed. well you can start with my question from two min ago - the basic operations of NORMA. 

     uniquness notations - i use them but i  had hadr time figuring exaxtly how they work. the idea isnt that dificult, but somehow they're not that intuitive, and evevn after i fgured them out it was still dificult to find simple and thorough explanations about them on the web.

     

    a nother thing that i still havent figure out, is the wording inside the binary. does "car color" "defining" a "car, or maybe a "car color" "is of" "car, or maybe a "car" "has a" "color"? 

     

    i'll be happy to test your explanations as much as i can :-)

     

  • 10-15-2008 18:06 In reply to

    Re: orm notations misunderstanding

    thanks Terry :-)

    i'll go have a look. 

  • 10-15-2008 18:58 In reply to

    Re: orm notations misunderstanding

    The IBM piece is exactly the kind of stuff I’m looking for
    Ummmmmmm. I have just spent nine months working on my MSc Dissertation. The project was about testing the hypothesis that ORM is at least 25% more effective than other approaches such as UML & ER.
    My conclusion from that project (and of many years of working with ORM) is not to waste your time with the approach recommended on the IBM website.
    I found several research studies that show that if you must use UML, then its best to start by creating "Data only Class models" without bothering with the Use Case stuff.

    Now "Data only Class models" are remarkably similar to ER models.
    And the best way to create an ER model is by generating it from an object-role model. (by using an ORM Tool).
    So once you get your head around ORM, then you can generate and update ER models to your hearts content - with very little extra effort.

    Now I think my case might be somewhat exceptional here, since my current focus is less on ORM’s contribution to improving the code or software, and more to the benefits that might be derived for ORM from a  project management angle
    IdeaWelcome to the world of the enlightened few!
    That's where I started (many years ago Cool)
    If you look in the ORM2005 section of the library you will see the "Requirements Engineering with ORM" presentation that I gave in Cyprus.
    Your case is "exceptional" only in the sense that not many folks seem to see the connection.

    Clarifying – defining the logical structure
    ORM enables semantic precision because ORM uses "verbalization" techniques to express ORM diagrams in easy-to-understand sentences. This makes it easy for a non-technical domain expert to understand the precise meaning of an object-role model.

    If you look at the following diagram, it gives an example of how to use the "Uniqueness constraint" and the "Mandatory role constraint" to precisely define the fact "Student writes Dissertation".

    A uniqueness constraint is represented by a line that spans one or more roles. The line signifies that there may not be any duplicate values in the column(s) that are spanned by the uniqueness constraint line. Thus, in the left hand column of the first row, the line over the left hand role means that the value of Student (.id) may not be duplicated in any of the instances of this fact type. The right hand column shows the verbalized fact. We can immediately see that the sentence "It is possible that more than one Student writes the same Dissertation" is against the University rules so this constraint structure is not correct.

    In the second row, we have added a uniqueness constraint over the right hand role. This means that there may not be more than one instance of each Dissertation in the column. However, the verbalization "Each Student writes at most one Dissertation" shows that this fact does not meet University requirements because the term "at most one" allows for a student not to write a Dissertation at all!

    In the third row, the dot on the left hand role signifies a "mandatory role constraint". This means that every instance of "Student" must play a role in this fact. By combining the two uniqueness constraints with a mandatory constraint, we get the following verbalization that exactly meets the University requirements:

    Each Student writes exactly one Dissertation.
    For each Dissertation, at most one Student writes that Dissertation.

    ORM is unique in providing an easy to understand conceptual information model that is at the same time, a formal description of the application domain.


  • 10-16-2008 2:05 In reply to

    Re: orm notations misunderstanding

    cheers Ken! i believe I got now. I guess i'll still need to snuff arownd a little before i totaly abandon them crows feets, but ORM's case seems quite convincing at this point. and thanks to Terry's NORMA labs i'm getting fong of NORMA as well...what can I say, ORM scratches me right where i itch :-) 

    thanks a lot!

  • 05-10-2013 15:55 In reply to

    Re: orm notations misunderstanding

    Hi, the table looks highly understandable, can you give it to me ?Thank you :)
  • 05-12-2013 14:17 In reply to

    Re: orm notations misunderstanding

     Sorry, but I don't understand your question.

    Which "table" are you talking about?

    What is it that you want to be given?

Page 1 of 1 (15 items)
© 2008-2014 The ORM Foundation: A UK not-for-profit organisation -------------- Terms of Service