ORM Step 1 Detailed Study Notes

ORM Step 1 Overview

• Context: ORM (Object Role Modeling) is used to design conceptual schemas. This guide relates to ORM Step 1 in the Faculty of Science at an Australian University.

Steps in Conceptual Schema Design Procedure

1. Transform familiar examples into elementary facts.

   • Aim to convert realistic scenarios into foundational assertions within the domain of interest (UoD).

2. Draw the fact types and apply a population check.

   • Identify existing instances and ensure that your fact types accurately reflect the data in the UoD.

3. Check for entity types to be combined and note any arithmetic derivations.

   • Analyze whether certain entities can be merged based on common characteristics. Look for numerical information that can derive further data.

4. Add uniqueness constraints and check the arity of fact types.

   • Ensure each fact type is uniquely identifiable and determine the number of participants involved in each fact (arity).

5. Add mandatory role constraints, and check for logical derivations.

   • Specify roles that must be filled in each fact, and verify that logical relationships can be deduced from them.

6. Add value, set-comparison, and subtyping constraints.

   • Consider adding restrictions on the values assigned to entities, group entities into sets, or classify them into subtypes.

7. Add other constraints and perform final checks.

   • Finalize the schema by considering any additional requirements and conducting thorough reviews.

Understanding the Domain of Discourse (UoD)

• Example Context:
  • The UoD relates to employees within a company and corresponding departments, e.g., "Mary Smith works in Sales."
• Importance of Deep Structure:
  • To accurately represent and model this statement, one must analyze its underlying structure rather than relying solely on surface-level interpretation.

Elementary Facts

• Definition:
  • An elementary fact is a simple assertion, or atomic proposition, about the domain. This means it is considered true by users in that domain.
• Right Understanding:
  • The domain consists of a collection of objects each fulfilling specific roles. Elementary facts specifically express that particular objects engage in defined roles.

Examples of Elementary Facts

1. Mary Smith works in Sales.
2. Employees are identified by an employee number.
3. David Brown works in Software Maintenance and is a CS01.
4. Employee 1432 is supervised by Employee 2341.

Basic Objects in UML

• Values vs. Entities:
  • Value:
    • Identifiable by their own characteristics (no further description needed).
    • Examples include strings like "Australia" or numbers such as 17 or 3.14.
  • Entity:
    • Requires a definite description, specifying its type (e.g., a city named 'Brisbane' or a unit with code 'IAB201').

Entity Types and Reference Modes

• Clarity is Key:
  • Misinterpretation of facts can arise; thus, entities must be correctly identified. Each entity's description must specify its entity type (e.g., Country, City).
• Components of Entity Identification:
  • Each entity can generally be identified using three components:
  1. Entity Type (e.g., Country, City)
  2. Reference Mode (e.g., surname, employee name)
  3. Value (e.g., "123ABC" or 3.14)

Specific Examples

1. Mary Smith works in Sales.

   • Employee: Mary Smith (Entity Type)
   • Department: Sales (Entity Type)

2. Mary Smith’s Employee ID is “E0002.”

   • Employee ID: E0002 (Reference Mode & Value)

Role Specification Using Predicates

• Definition:
  • A predicate serves as a sentence structure, capturing the relationship between objects.
• Arity of Predicates:
  • Tells how many objects participate in the predicate.
    • Unary Predicate: 1 object, e.g., "Ann studies (……studies)."
    • Binary Predicate: 2 objects, e.g., "……works in……"
    • Ternary Predicate: 3 objects, e.g., "……obtains grade of……for……"

Surface Structures vs. Deep Structures

• Understanding Their Equivalence:
  • Surface structures may vary, but deep structures can maintain semantic equivalence.
    • Example:
    • "Mary works in Sales" vs. "Sales employs Mary."
• Semantic Fact Types:
  • The facts express that an employee works in a department, representing roles necessary in establishing a fact type, called DepartmentLocation.

Instances of Fact Types

• Fact Type Instances for DepartmentLocation:
  1. The Employee with employee name Sally Wong works in the Department with department name Accounts.
  2. The Employee with employee name David Atkins works in the Department with department name Sales.
  3. The Department with department name Accounts employs the Employee with employee name Lisa Jones.
  4. The Department with department name Marketing employs the Employee with employee name John Butler.

Importance of Roles in Modeling Information

• Key Principles:
  • Understand that elementary facts assert that an object possesses properties or that objects share relationships.
• Atomicity of Facts:
  • Each elementary fact cannot be decomposed and represents a singular truth, irrespective of its arity.

Practical Implications for Fact Modeling

• Splitting Independent Facts:
  • Example:
  • Mary Smith has the Employee ID "E0002" and works in Sales.
    • This would ideally be represented as two separate assertions:
    • The Employee with the employee name ‘Mary Smith’ has Employee ID "E0002."
    • The Employee with the employee name ‘Mary Smith’ works in the Department with department name ‘Sales.’

Cautions in Formulating Elementary Facts

• Avoiding Complexity:
  • Elementary facts typically exclude logical connectives (like not, and, or, if) and logical quantifiers (like all, some).
  • Examples:
    • Incorrect: "Mary Smith and David Atkins work in Sales."
    • Incorrect: "All people working in Sales earn $200000 per annum."

Summary of ORM Practices

• Design the UoD using elementary facts in predicate format.
  • Ensure clarity by defining each entity thoroughly, specifying its type, reference mode, and value.