Made with
ConceptDraw
DIAGRAM 14

ORM Diagram

Object-role modelling can be used for data modelling in software engineering business activity, being simply the semantics of a universe of discourse. The final object-role models, which were coined in the 1970s, use different graphical symbols, based on set theory as well as first order predicate logic, which enables the modeller to make an unambiguous definition of a so called “arbitrary universe of discourse”. Basically, object-role models are graph database models, better analysed and designed to benefit the relational database design.

ORM based tools as well as object-role models have been used for more than 30 years and still are very popular. The mentioned object-role models have been used for modelling the business rules, data warehouses, web forms, requirements engineering forms and XML-Schemas. Originally, the roots of object-role models can be traced to research into semantic modelling for information systems during the 1970s in Europe, having an early contribution came in 1973. In that year Michael Senko wrote about data structuring in the “IBM Systems Journal” and in 1974 Jean-Raymond Abrial contributed an article about Data Semantics, followed by Eckhard Falkenberg, who published the papers in June 1975 mentioning the object-role models, as well as in 1976 again.

Already in 1989 the thesis on object-role model was completed by Terry Halpin, incorporating several extensions and, of course, providing the first full formalization of the approach. Same year, he and G.M. Nijssen wrote a book named "Conceptual Schema and Relational Database Design", as well as several joint papers. In those papers they provided the first formalization of the object-role modelling, writing six more books and over 160 technical papers about it later.

The object-role modelling can be also used in combination with standardised relation types, involving the associated roles as well as a taxonomy (the practice and science of classification) of concepts and machine-readable dictionary. Standardisation of the so called “relation types” (also known as “fact types”), concepts and roles enables increased possibilities for model reuse as well as for model integration. All object-role models are based on elementary facts. The mentioned facts can be expressed in many different types of diagrams, based on the object-role modelling process, which can be verbalised into natural language.

With object-role modelling, the propositions (which can be related to the objects of belief, primary bearers of truth-value as well as other “proportional attitude”, the meanings of declarative sentences and the referents of that-clauses) are abstracted into "fact types", when the individual propositions are regarded as “sample data”. The difference between an "elementary fact" and a "fact" itself is that an elementary fact cannot be simplified without loss of meaning. The mentioned "fact-based" approach facilitates transforming, modelling and querying information from any needed domain.

Object-role models are known to be “attribute-free”, treating all elementary facts as relationships and the decisions for grouping facts into structures, as implementation concerns irrelevant to semantics, which differs them from the models in the Unified Modelling Language and the entity-relationship methods. Object-role models improve the semantic stability, enabling any verbalization into natural language in a way of avoiding attributes in the base model.

The so called “fact-based modelling” includes procedures for mapping facts to attribute-based structures and all fact-based textual representations are based on formal subsets of native languages. Thus, the object-role models are simpler to understand by those people, who have no technical education. Although, fact-based graphical notations are known to be more expressive, to compare to the Unified Modelling Language and the entity-relationship ones. Also, it’s important to remember that object-role model can be automatically mapped to deductive and relational databases.

Object-role modelling 2 is simply the latest generation of object-role modelling, using the main objectives for the ORM 2 graphical notation, which are support for new features (such as role path delineation, modalities and closure aspects), more compact display of ORM models with no need of compromising clarity, an improved internationalization (for example, to avoid English language symbols), the simplified drawing rules for facilitating creation of a graphical editor and an extended use of views for selectively suppressing/displaying detail.

System development usually involves such stages, as feasibility study, requirements analysis, design of both operations and data as well as logical design, external design, internal design as well as its implementation, prototyping, validation, testing and, finally, maintenance. The steps of the schema design procedure include drawing the fact types and applying a population check, transforming familiar information examples into elementary facts and applying quality checks, checking for entity types that are meant to be combined, noting any arithmetic derivations, adding uniqueness constraints, checking arity of fact types, adding mandatory role constraints and checking for logical derivations, adding value, set comparison as well as subtyping constraints, adding other constraints and performing final checks.

ORM Diagram *

Example 1. ORM Diagram

The mentioned conceptual schema design procedure of object-role modelling focuses on the design as well as analysis of data and it should be taken into consideration while creating the so called object-role modelling diagrams, which can be simply created in ConceptDraw DIAGRAM software within a very short period of time having all the needed tools, provided by the solutions, that all can be found in the ConceptDraw STORE — another application, developed by the CS Odessa IT specialists in order to simplify all ConceptDraw DIAGRAM users’ processes of drawing.




See also samples:






TEN RELATED HOW TO's:

SDL Diagram →

Specification and Description Language (SDL) is used for creating the object-oriented diagrams, visualizing the processes of the state machines for the systems of communication, telecommunication, automotive, aviation and medical industries. SDL is a specification language for creating specifications, descriptions of the behavior, data, and inheritance for real-time systems. This sample shows the SDL Diagram of the process game.SDL Diagram *
Picture: SDL Diagram
Related Solution:

Venn Diagram Examples for Problem Solving.Venn Diagram as a Truth Table →

Venn diagrams are illustrations used in the branch of mathematics known as set theory. They show the mathematical or logical relationship between different groups of things (sets). A Venn diagram shows all the possible logical relations between the sets.Venn Diagram Examples for Problem Solving - Venn Diagram as a Truth Table
Picture: Venn Diagram Examples for Problem Solving.Venn Diagram as a Truth Table
Related Solution:

How to Design a Good Workflow →

To design a good workflow you have to focus on process analysis, not using the a drawing tool. This is more possible with ConceptDraw DIAGRAM software that brings the most natural drawing manner you have ever tried. First, define steps and procedures using simple rectangle shape, then select all shapes and click the Chain button to connect all shapes just in one click. After that you are able to modify some relations if needed.How to Design a Good Workflow *
Picture: How to Design a Good Workflow
Related Solution:

UML Object Diagram. Design Elements →

UML Object Diagram shows the structure of a modeled system at a specific time. ConceptDraw has 393 vector stencils in the 13 libraries that helps you to start using software for designing your own UML Diagrams. You can use the appropriate stencils of UML notation from UML Object library.UML Object Diagram. Design Elements *
Picture: UML Object Diagram. Design Elements
Related Solution:

UML Class Diagram Example for GoodsTransportation System →

Class Diagram for Goods Transport System in UML. This sample was created in ConceptDraw DIAGRAM diagramming and vector drawing software using the UML Class Diagram library of the Rapid UML Solution from the Software Development area of ConceptDraw Solution Park. This sample shows the concept of working of the transport company and is used by transport companies, carriers at the transportation of various goods.UML Class Diagram Example for GoodsTransportation System *
Picture: UML Class Diagram Example for GoodsTransportation System
Related Solution:

Building Drawing. Design Element: Piping Plan →

A technical drawing of a building is called an architectural drawing. According to a set of conventions, a building drawing includes a number of views, as well as unit measurements, scales, sheet sizes, cross referencing and annotation. Computer progress had a major impact of the methods of architectural drawing, making manual drawing almost obsolete. Digital drawing software, such as ConceptDraw DIAGRAM , offers a number of tools for each design element: piping plan, floor plan, etc. Any building should have its plumbing and piping plans for every room, that has a water supply. Plans are applied to indicate arrangement of piping system in the building. This diagram presents a suite of standard piping icons for making building plans that include plumbing and piping layout. This diagram was designed using ConceptDraw solution for Piping and Plumbing planning. Using symbols is valuable for making a valid piping plan. Because any professional will properly interpreted such plan as a piece of technical documentation of a construction project.Building Drawing. Design Element: Piping Plan *
Picture: Building Drawing. Design Element: Piping Plan
Related Solution:

How To Create Restaurant Floor Plan in Minutes →

As restaurant industry is growing rapidly nowadays, researches show that almost half of the adults have worked in a restaurant or a cafe. Moreover, many of them dream to start their own someday. Unfortunately, it takes a lot of time to write a business plan and to find a great location, although some know how to create a restaurant floor plan in minutes or how to plan budget effortlessly. Hiring employees can also cause a lot of headache, but this is crucial for further success, because every guest comes to restaurant for a good service and delicious food. It is also worth noting that restaurant concept is also important, because it defines target audience and influences the menu. This diagram represents the floor plan of an ongoing sports-theme establishment - restaurant, cafe, or other food service. A number of widescreen monitors installed along the perimeter provide visitors the opportunity to follow the course of a match from anywhere in the dining room of restaurant or cafe. The most of sports fans believe that food and alcohol is a big part of any sports show. That is why the dining room takes the most space - almost 60% of the total establishment space. Nearly all sports fans consume beverages while watching sports - beer, soda or water at least. Thus, the restaurant floor plan designers added a large lavatory there. Moreover, project developers considered unnecessary the gender division of such delicate place - perhaps they guess that only men are watching football, or believe that alcohol will eliminate the most of gender differences.Restaurant Floor Plan
Picture: How To Create Restaurant Floor Plan in Minutes
Related Solution:

UML Interaction Overview Diagram. Design Elements →

UML Interaction Overview Diagram schematically shows a control flow with nodes and a sequence of activities that can contain interaction or sequence diagrams. ConceptDraw has 393 vector stencils in the 13 libraries that helps you to start using software for designing your own UML Diagrams. You can use the appropriate stencils of UML notation from UML Interaction Overview library.UML Interaction Overview Diagram. <br>Design Elements *
Picture: UML Interaction Overview Diagram. Design Elements
Related Solution:

IDEF0 Diagram →

The vector stencils library IDEF0 Diagram from the solution IDEF0 Diagrams contains specific IDEF0 diagram symbols such as arrow symbols and entity symbols for ConceptDraw DIAGRAM diagramming and vector drawing software. The IDEF0 Diagram solution is contained in the Software Development area of ConceptDraw Solution Park.IDEF0 Diagram *
Picture: IDEF0 Diagram
Related Solution:
ConceptDraw
DIAGRAM 14