The entity relationship diagram is a diagrammatic technique to exhibit entities and relationships.
An entity relationship diagram .
Each entity is represented by a rectangular box and each relationship is represented by a diamond-shaped box. Lines, that connect the rectangular boxes, represent that the relationship set is defined on the connected rectangular boxes. The diagram is able to distinguish between 1:n, m:n and 1:1 mappings.
3.4.1 ER DIAGRAMS, DOMAIN MODEL, AND N‐LAYER ARCHITECTURE WITH ASP.NET 3.5 (PART1)
Let us start with a 1-tier ASP.NET application configuration. Note that the application as a whole including database and client browser is three tier.
We can call this 1-tier architecture a 3-tier architecture if we include the browser and database (if used). For the rest of this unit we will ignore the database and browser as separate tiers so that we can focus on how to divide the main ASP.NET application layers logically, using the n-layer pattern to its best use.
We will first try to separate the data access and logical code into their own separate layers and see how we can introduce flexibility and re-usability into our solution. We will understand this with a sample project. Before we go ahead into the technical details and code, we will first learn about two important terms: ER Diagram and Domain Model, and how they help us in getting a good understanding of the application we need to develop.
Entity-Relationship diagrams, or ER diagrams in short, are graphical representations depicting relationships between different entities in a system. We humans understand and remember pictures or images more easily than textual information. When we first start to understand a project we need to see how different entities in the project relate to each other.
ER diagrams help us achieve that goal by graphically describing the relationships.
An entity can be thought of as an object in a system that can be identified uniquely. An entity can have attributes; an attribute is simply a property we can associate with an entity. For example, a Car entity can have the following attributes: EngineCapacity, NumberofGears, SeatingCapacity, Mileage, and so on. So attributes are basically fields holding data to indentify an entity.
Attributes cannot exist without an entity.
Let us understand ER diagrams in detail with a simple e-commerce example: a very basic Order Management System. We will be building a simple web based system to track customer's orders, and manage customers and products.
To start with, let us list the basic entities for our simplified Order Management System (OMS):
i. Customer: A person who can place Orders to buy Products.
ii. Order: An order placed by a Customer. There can be multiple Products bought by a Customer in one Order.
iii. Product: A Product is an object that can be purchased by a Customer.
iv. Category: Category of a Product. A Category can have multiple Products, and a Product can
belong to many Categories. For example, a mixer‐grinder can be under the Electronic Gadgets category as well as in Home Appliances.
v. OrderLineItem: An Order can be for multiple Products. Each individual Product in an order will be encapsulated by an OrderLineItem. So an Order can have multiple OrderLineItems.
Now, let us picture the relationship between the core business entities is defined using an Entity-Relationship diagram. Our ER diagram will show the relational associations between the entities from a database's perspective. So it is more of a relational model and will not show any of the object-oriented associations (for which we will use the Domain Model in the later sections of this unit). In an ER diagram, we show entities using rectangular boxes, the
relationships between entities using diamond boxes and attributes using oval boxes, as shown below:
The purpose of using such shapes is to make the ER diagram clear and concise, depicting the relational model as closely as possible without using long sentences or text. So the Customer entity with some of the basic attributes can be depicted in an ER diagram as follows:
Now, let us create an ER diagram for our Order Management System. For the sake of simplicity, we will not list the attributes of the entities involved.
Here is how the ER diagram looks:
The above ER diagram depicts the relationships between the OMS entities but is still
incomplete as the relationships do not show how the entities are quantitatively related to each other. We will now look at how to quantify relationships using degree and cardinality.
3.4.2 DEGREE AND CARDINALITY OF A RELATIONSHIP
The relationships in an ER diagram can also have a degree. A degree specifies the
multiplicity of a relationship. In simpler terms, it refers to the number of entities involved in a relationship. All relationships in an OMS ER diagram have a degree of two, also called binary relationships. For example, in Customer-Order relationships only two entities are involved—Customer and Order; so it's a two degree relationship. Most relationships you come across would be binary.
Another term associated with a relationship is cardinality. The cardinality of a relationship identifies the number of instances of entities involved in that particular relationship. For example, an Order can have multiple OrderLineItems, which means the cardinality of the relationship between Order and OrderLineItem is one-to-many. The three commonly-used cardinalities of a relationship are:
i. One‐to‐one: Depicted as 1:1
Example: One OrderLineItem can have only one Product; so the OrderLineItem and Product entities share a one‐to‐one relationship
ii. One‐to‐many: Depicted as 1:n
Example: One customer can place multiple orders, so the Customer and Order entities share a one‐to‐many relationship
iii. Many‐to‐many: Depicted as n:m
Example: One Product can be included in multiple Categories and one Category can contain multiple Products; therefore the Product and Category entities share a many‐to‐many relationship
After adding the cardinality of the relationships to our ER diagram, here is how it will look:
This basic ER diagrams tells us a lot about how the different entities in the system are related to each other, and can help new programmers to quickly understand the logic and the
relationships of the system they are working on. Each entity will be a unique table in the database.