Editing Object–role modeling (section)

== Concepts ==
[[File:Object-Role Model Overview.jpg|thumb|240px|right|Overview of object–role model notation, Stephen M. Richard (1999).<ref name="SMR99"/>]]

=== Facts ===
Object–role models are based on elementary facts, and expressed in [[diagram]]s that can be verbalised into natural language. A fact is a [[proposition]] such as "John Smith was hired on 5 January 1995" or "Mary Jones was hired on 3 March 2010".

With ORM, [[proposition]]s such as these, are abstracted into "fact types" for example "Person was hired on Date" and the individual propositions are regarded as sample data.  The difference between a "fact" and an "elementary fact" is that an elementary fact cannot be simplified without loss of meaning. This "fact-based" approach facilitates modeling, transforming, and querying information from any domain.<ref name="orm.net">{{Cite web | url=http://www.orm.net/pdf/ORM2_TechReport1.pdf | title=ORM 2 Graphical Notation | access-date=2024-05-19}}</ref>

=== Attribute-free ===
ORM is attribute-free: unlike models in the [[entity–relationship model|entity–relationship]] (ER) and [[Unified Modeling Language]] (UML) methods, ORM treats all elementary facts as relationships and so treats decisions for grouping facts into structures (e.g. attribute-based entity types, classes, relation schemes, XML schemas) as implementation concerns irrelevant to semantics. By avoiding attributes, ORM improves semantic stability and enables verbalization into natural language.

=== Fact-based modeling ===
[[Fact-based modeling]] includes procedures for mapping facts to attribute-based structures, such as those of ER or UML.<ref name="orm.net"/>

Fact-based textual representations are based on formal subsets of native languages. ORM proponents argue that ORM models are easier to understand by people without a technical education. For example, proponents argue that object–role models are easier to understand than declarative languages such as [[Object Constraint Language]] (OCL) and other graphical languages such as [[Unified Modeling Language|UML]] class models.<ref name="orm.net"/>  Fact-based graphical notations are more expressive than those of ER and [[Unified Modeling Language|UML]]. An object–role model can be automatically mapped to relational and deductive databases (such as [[datalog]]).<ref>{{Cite web|url=http://www.ormfoundation.org/files/folders/orm_2010/entry2360.aspx|archive-url=https://web.archive.org/web/20110413060716/http://www.ormfoundation.org/files/folders/orm_2010/entry2360.aspx|url-status=usurped|archive-date=April 13, 2011|title=P:11 Mapping ORM To Datalog - an Overview - The ORM Foundation|website=www.ormfoundation.org|access-date=May 31, 2020}}</ref>

=== ORM 2 graphical notation ===
ORM2 is the latest generation of object–role modeling. The main objectives for the ORM 2 graphical notation are:<ref>{{cite web|url=http://www.orm.net/pdf/ORM2.pdf |title=ORM 2 |access-date=April 22, 2009 |url-status=dead |archive-url=https://web.archive.org/web/20090219122007/http://orm.net/pdf/ORM2.pdf |archive-date=February 19, 2009 }} Halpin, T. 2005, 'ORM 2', On the Move to Meaningful Internet Systems 2005: OTM 2005 Workshops, eds R. Meersman, Z. Tari, P. Herrero et al., Cyprus. Springer LNCS 3762, pp. 676–87.</ref>
* More compact display of ORM models without compromising clarity
* Improved internationalization (e.g. avoid English language symbols)
* Simplified drawing rules to facilitate creation of a graphical editor
* Extended use of views for selectively displaying/suppressing detail
* Support for new features (e.g. role path delineation, closure aspects, modalities)

=== Design procedure ===
[[File:Schema for Geologic Surface.svg|thumb|360px|right|Example of the application of Object Role Modeling in a "Schema for Geologic Surface", Stephen M. Richard (1999).<ref name="SMR99">Stephen M. Richard (1999). [http://pubs.usgs.gov/of/1999/of99-386/richard.html Geologic Concept Modeling]. U.S. Geological Survey Open-File Report 99-386.</ref>]]
System development typically involves several stages such as: feasibility study; requirements analysis; conceptual design of data and operations; logical design; external design; prototyping; internal design and implementation; testing and validation; and maintenance.  The seven steps of the conceptual schema design procedure are:<ref name="TH01">Terry Halpin (2001). [http://www.orm.net/pdf/ORMwhitePaper.pdf "Object-Role Modeling: an overview"]</ref>

# Transform familiar information examples into elementary facts, and apply quality checks
# Draw the fact types, and apply a population check
# Check for entity types that should be combined, and note any arithmetic derivations
# Add uniqueness constraints, and check arity of fact types
# Add mandatory role constraints, and check for logical derivations
# Add value, set comparison and subtyping constraints
# Add other constraints and perform final checks

ORM's conceptual schema design procedure (CSDP) focuses on the analysis and design of data.