This is the first lesson that will explain the Domain Model in WebRatio Platform. In the first lesson, we introduce the main concepts related to the Domain Model, including a deep analysis of the notation adopted - Entity Relationship (E-R). The following lessons show some detailed content and will explain the procedures to map the Domain Model to a database.
Domain Model Definition
A Web application is like a house. The Domain Model of the Web application is comparable to the foundation of the house. In order for a Web application to manage and display information to the user, it must have a proper and consistent foundation, that represents key concepts of the Web application.
The Domain Model describes the conceptual data organization of the WebRatio Platform applications. The Domain Model is a model that contains content elements that View Components may access to retrieve information, process it, and show it to the user. The Domain Model also stores information captured from the user.
The Domain Model is presumed to be represented in UML and therefore consists of a set of UML model elements, but It is also compatible with the Entity-Relationship model. WebRatio uses both the Entity-Relationship and the UML representation of data.
An Entity - Relationship Model (ERM) is an abstract and conceptual representation of data. Even if you are familiar with this notation, this lesson may be helpful to you as you learn how to use notation productively inside WebRatio. Entity-Relationship modeling is a database modeling method, used to produce a type of conceptual schema or semantic Domain Model of a system, often a relational database, and its requirements in a top-down fashion.
The ER schema is based on 3 main concepts:
An Entity represents a description of the common features of a set of real-world objects.
In a CRM Web Application, examples of Entities are "Company" and "Person".
An Eentity has a population, which is the set of objects that are described by the Entity. These objects are also called Entity instances.
Examples of instances of an "Company" entity may include "Google", "Microsoft" and "Amazon" (all of which are part of a population of the Entity).
An Attribute represents a property of real-world objects that is relevant for purposes of the Web application. Attributes are associated with the concept of Entity, with the meaning that all the Entity instances are characterized by the same set of Attributes.
For the "Company" entity, examples of Attributes are the "VAT Code", "Name" and "Address". For the "Person" entity, examples of Attributes are the "First Name", "Last Name", "Birth Date" and "Sex".
A particular Attribute is the Primary Key, used to identify an Entity uniquely. An Entity may have a set of Primary Key Attributes. It is admissible that an Entity instance may not have a value for one or more Attributes, except of course for Primary Key(s).
An example of Primary Key is the "VAT Code" for a "Company". An example of a Primary Key with multiple Attributes is "First Name", "Last Name" and "Birth Date" of a "Person".
A Relationship represents a connection between Entities. The meaning of the association is conveyed by the Relationship's name and Cardinality. An example of Relationship between "Person" entity and "Company" entity is "Employment".
Each Relationship has two Roles, that are the ways in which a Relationship could be read. "Employment" relationship has "Employer" role for "Company" entity, and "Employee" role for "Person" entity.
The Cardinality specifies how many Entity instances can participate to a Relationship. There are three types of Cardinality:
- 1-1 Relationships. Both Relationship Roles have maximum Cardinality 1. An example of a 1-1 Relationship between "Company" entity and "Person" entity is "CEO".
- 1-N Relationships. One Relationship Role has maximum Cardinality 1 and the other has maximum Cardinality N. An example of a 1-N Relationship between "Company" entity and "Person" entity is "Employment".
- N-N Relationships. Both Relationship Roles have maximum Cardinality N. An example of an N-N Relationship between "Company" entity and "Person" entity is "Customer".
It is not possible to connect two Entities with a different duration (e.g. one persistent and the one volatile).
How to Design an ER Model
And now lets try to design an ER Model based on the following scenario.
An Inventory database stores information about a company's products in stock: The Company possesses several warehouses characterized by a name, a code, and an address. Each warehouse is composed of several shelves. Each shelf has a code, a row number, a column number, and a level.
Click the "Next" button to proceed with the example.
Let's identify the Entities:
Let's identify the Relationships between these Entities:
- The "Possession" relationship between the "Company" entity and the "Warehouse" entity, with Cardinality 1-N.
- The "Composition" relationship between the "Warehouse" entity and the "Shelf" entity, with Cardinality 1-N.
Let's identify the Attributes and Key Attributes for the Entities.
The Attributes of the "Company" entity are:
The Attributes of the "Warehouse" entity are:
The Attributes of the "Shelf" entity are:
This is how we created the ER Model.