The ORM Foundation

13.   And finally again tasks. Section has his own tasks. Section plans factory work. Factory has to fallow this plan. Section advises department head.

Pictures and Visaul Studi fails are in here (sorry could not find better place so fast):

http://www.4shared.com/dir/30916216/c20170cc/sharing.html

With all the best,

V.K

ORM deals in "Facts" and we use specialised ORM tools to model sets of facts.

INPUT The input to an object-role model is a set of facts.
For example: 
     Department(name) has Factory(name)
     Person(id) is head of Department(name)
     Factory(name) is in City(name).

And so on...

OUTPUT The output from an object-role model is a "logical model" . (for example a 5NF relational model or a Class model.)     

Your diagram does not look like either a relational or ER model or a class model.
Your diagram looks like any block diagram that you could build in Visio or a similar drawing package.
So I'm a bit confused by your message.

No problem for you to build your own "conceptual schema" but with ORM, this is expressed using the object-role modeling language as either an object-role model diagram or a set of facts.

Hope this helps

Ken  

Sorry for this mess in previous message. I had no idea, that text will be automatically changed here.

Anyway I came out with another great idea - comparing ER, ORM and UML (last two are actually done before, but ER is not). I hope that this will help me and someone else to undestand what are meant in each modelling language.

 With all the best

V.K

Conceptual schema comprises three main sections: fact types, constraints and derivation rules (Halpin).

So if I undestand you correctly with ORM there is no schemas just sentences? But how then this version is better then ER. Usually user (expert) wants to see a picture (schema), because it describes things. Also with sentences you can not express constraints (you can but then you have to repeat your sentence in negative form).

With all the best

 V.K

NB! I added the schema according your INPUT example. Does it mean (again) that those three sentences were conteptual "schema" and what I draw was logical?

That's a very interesting table. However, your table has a few problems:

Firstly, by using a table in this way, you imply that ER, UML and ORM are "equivalent" in some way and this is not the case.
If you do want to make a table that compares ER, UML and ORM then you need a fourth column entitled "Problem to be solved"
By doing this you will discover that there will be many blanks in the cells.

Some examples:
Row 1: "ER does not support automatic converting into a logical model..."
This statement is not true because ER  IS a logical model. (or at least a summary of one) (See the papers on the library about ER and ORM.)

Row 2: The single terms that you use (ER: Entity, ORM: Entity and UML: Object) can't really be compared in this way. (because words on their own have no meaning)

* The concept of "Entity" in ER is based on Peter Chen's 1976 assertion that "people naturally view the world as entities and attributes" (I don't think that this is true.

* The concept of "Entity" (or object) in ORM  can be loosely thought of as "a thing that you want to talk about"

* The concept of "Object" in UML relates to a coding construct using an OO language.

The "object" in an object-role model is best seen as a member of a "Universe of Discourse" .
In particular, the lessons from semiotics show that things (e.g. an ORM object) only have meaning in context. the 2 ORM Object

So I suggest that you invent a fourth column and then adapt and re-post your table.

Lastly, if you look at the "research" page on this website, you wil see that my 2008 dissertaion for my Masters degree was all about comparing UML with ER and ORM.

So  your assertion that "...comparing ER, ORM and UML (last two are actually done before, but ER is not) is not actually true.

Ken

That's good for what I imagine might be one of your first attempts to use NORMA.
I have made a valid model that is shown in the diagram embedded with this post.

Some comments on your diagram.
1: In your diagram, you can see several red symbols over your fact types.
These red symbols show that there is an error.
If you look in your ORM verbalization window, you will see descriptions of the errors. 

2: Your ternary fact that includes Department, Person and Factory does not make sense.
You will see this in the verbalizer window.

Conceptual vs Logical

In ORM, the "conceptual level" is the complete set of facts  that describe the Universe of Discourse (UoD). (from "Formal Logic" by Augustus De Morgan -1847)

The logical level is (for example) the relational diagram that is mapped from the conceptual model.
Note The logical model diagram contains less information than the ORM diagram. The "extra" information is encoded in (for example) triggers that represent the constraints that you have defined in your conceptual model)

So it is not true to assert that "With ORM there is no schemas just sentences".
ORM applies first-order predicate logic whereas UML and ER are just non-standard diagrams (One author I read called them "cartoons")
My problem here is that I don't know how to explain first-order predicate logic to you in a few words.

However, to help the discussion along, I have made a valid object-role model of the UoD  that we are discussing.
Hope this helps

Ken

Thank you Ken

ORM verbalization window makes much more sense now (I saw the errors, but didn't know how to fix them, except giving pointless values). Still seems that NORMA is great tool and I will continue with my efforts to create conceptual schema of company (initialy only department 1). As far as I understood then it is still possible to place everything into one window (sheet) and if I manage to do it, then I have accomplished maybe two things:

1. Getting to know NORMA

2. Improving my understandings of ORM

V.K

Good to hear that you are making progress.

Regarding your comments on

vkannel:

As far as I understood then it is still possible to place everything into one window (sheet)

There are several important points to bear in mind:

1: The UoD is the complete model 
2: In NORMA, the complete model is stored as a file and, when in use, is all in real memory.
3: In NORMA and VEA a conceptual model can be defined using several pages.
4: In VEA the logical model can also be spread across multiple pages but this is not yet implemented in NORMA.
5: I recommend that to simplify model development and management, a complete conceptual model should be defined on more than one page.
Thus in your conceptual model, you might use separate pages for: Person, Department, Factory, Product and so on.  

Hope this helps

Ken

Ken Evans:

Your ternary fact that includes Department, Person and Factory does not make sense.

I'm not sure I'd express it as "not making sense". It represents an example of a sentence that someone might use in natural speech, and would be understood, so in that sense it does make sense.

However, such a natural-language sentence contains two separate facts; that the person heads a department, and that the department has a factory. This makes it a compound fact - and the original ORM reflects this as a compound fact type. ORM does not allow compound fact types - and that is one of its key strengths over ER and object modelling. By forcing all fact types to be elementary, ORM makes it possible to untangle the meanings of the separate facts, and to correctly figure out and verbalise the constraints over those relationships

 You'll see that Ken has done this untangling (into elementary form) in his alternative.  When you learn always to distinguish a fact that isn't elementary, and to break it into its elementary facts, you will have made a big step towards mastering ORM.