Object-Role Modeling (ORM) is a powerful technique for business analysis and database design that allows for clear communication between stakeholders and helps to ensure that the resulting database accurately represents the requirements of the business.
To provide a blow-by-blow use case of ORM, let's consider a hypothetical project to create a customer relationship management (CRM) system for a small business. The CRM system will need to track customer information, sales opportunities, and customer interactions.
Step 1: Identify Stakeholders and Define Business Requirements
Typically one first identifies the stakeholders and define the business requirements. In this case, the stakeholders might include the business owner, sales staff, customer service representatives, and marketing staff.
To define the business requirements, we would conduct interviews with these stakeholders to understand their needs and workflows. For example, we might learn that the sales staff needs to be able to quickly access customer contact information and sales history, while the customer service representatives need to be able to view customer interactions and quickly resolve issues. During this process we may include all of Step 2, below, and create an ORM Diagram as we conduct workshops with the stakeholders.
Step 2: Develop an ORM Diagram
Once we have a clear understanding of the business requirements, we can begin to develop an ORM diagram. The ORM diagram will provide a visual representation of the objects types, attributes/properties, and relationships that need to be modelled in the database for our CRM system.
The wonderful thing about ORM is that we need not decide as to what type of database, graph or relational, that we will use for the system, as ORM is database agnostic.
To develop the ORM diagram, we would start by identifying the key object types in the system. In this case, we might identify objects such as Customer, Sales Opportunity, and Interaction.
Next, we would identify the attributes/properties that are associated with each object. For example, the Customer object type might have attributes such as Name, Address, and Phone Number. The Sales Opportunity object might have attributes such as Sales Stage, Probability, and Expected Close Date.
Finally, we would identify the relationships between the object types. For example, the Customer object type might have a relationship with the Sales Opportunity object type, indicating that a customer can be associated with multiple sales opportunities.
Step 3: Refine the ORM Diagram
After developing the initial ORM diagram, we would refine it based on feedback from stakeholders and further analysis of the business requirements. This might involve adding or removing object types, adding attributes to object types, or modifying relationships between object types.
For example, we might realize that the Interaction object needs to be split into separate objects for Phone Call, Email, and Chat interactions in order to better track customer interactions.
Step 4: Map the ORM Diagram to a Database Schema
Once the ORM diagram has been finalized, we can use it to map the object types, attributes/properties, and relationships to a database schema. This involves defining the tables and columns that will be used to store the data in the database.
For example, the Customer object types might be mapped to a Customers table/node type, with columns/properties for Name, Address, and Phone Number. The Sales Opportunity object might be mapped to a Sales_Opportunities table/node type, with columns/properties for Sales Stage, Probability, and Expected Close Date.
Step 5: Implement the Database Schema
After the database schema has been defined, we can implement it in a database management system (DBMS) such as MySQL, PostgreSQL or Neo4j. This may involve creating the tables and columns in the database, and setting up any necessary indexes or constraints for those database types that have a predefined schema.
Step 6: Test and Refine the Database Schema
Finally, we would test the database schema to ensure that it accurately represents the business requirements and meets the needs of the stakeholders. This might involve creating sample data and running queries to ensure that the data is being stored and retrieved correctly.
If any issues are identified during testing, we would refine the database schema and repeat the testing process until we are confident that the database meets the needs of the business.
