Information Modeling By means of Entity Relationship (ER) Method Part – 5

Phases in Constructing the Information Model

Though Entity Relationship (ER) diagram lists as well as describes the concepts which are mandatory for building an information model, but still there is no regular manner for completing so. A number of practices insist on a bottom up progress method where the model is constructed in phases. Usually, the objects or entities as well as associations are displayed first, trailed by significant columns or attributes, and then the modeling is completed by means of adding non significant columns or attributes. Further professionals claim that, phased wise construction method is unrealistic for the reason that it needs too many get-togethers (meetings) with the end users. The orders used for this documentation are stated as follows:

1. Identifying the information objects or entities as well as relations.

2. Enlisting the preliminary Entity Relationship (ER) diagram by means of objects or entities as well as relations.

3. Filtering the Entity Relationship (ER) diagram.

4. Adding important columns or attributes to the diagram.

5. Adding non important columns or attributes to the diagram.

6. Drawing simplification hierarchies.

7. Authenticating the model via normalization.

8. Adding corporate as well as reliability guidelines to the model.

In real time the model construction is not a severe linear procedure. As stated above, the requirements analysis as well as the preliminary Entity Relationship (ER) diagram model frequently takes place concurrently. Filtering in addition to authenticating the diagram may possibly discover difficulties or absent data which need extra data collecting as well as analysis.

Detecting Information Entities as well as Relations

In direction to start with creation of the simple model, the designer should study the data collected all through the requirements analysis process for the purpose of:

• Categorizing information objects as either entities or columns or attributes.

• Classifying as well as describing relations among objects or entities.

• Mentioning as well as describing the recognized objects or entities, columns or attributes, as well as relations.

• Recording this data in the information document.

To complete these objectives the designer should study the descriptions from end users, proceedings from meeting, rule as well as process documents, in addition to the design documents from the existing information system is available.

Even though it is easy to describe the simple concepts of the Entity Relationship (ER) model, but at the same time it is not a stress-free job to discriminate their characters in constructing the information model.

What marks an object as an entity or attribute?

For an instance, the statement "Employees work on Projects". Now, whether the employees should be categorized as an entity or attribute? Very frequently, the right answer is subjected to the necessities of the database. In a number of circumstances, employee will be an entity, in some other circumstance it will be an attribute.

Despite the fact that the definitions of the concepts in the Entity Relationship (ER) model are easy to understand, but the model do not address the important concern of in what manner to classify them. A number of generally assumed rules are:

• Entities have expressive facts.

• Columns or attributes either classify or define entities.

• Relations are links among entities.

These rules are discussed in more detail below:

• Entities

• Columns or attributes

· Authenticating columns or attributes

· Resultant columns or attributes as well as code standards

• Relations

• Identifying Information Objects

• Object Description

• Recording Facts in Design Document

Entities

There are numerous descriptions of an entity:

"Every unique individual, place, item, episode, or notion, about which data is reserved, is known as entity", "An item which can be particularly recognized is known as entity", "Every unique object which is to be characterized in a database is known as entity", "…everything about which an individual stores data like dealer, engine tool, worker, usefulness pole, ticketing systems etc. is known as entity. For every single entity type, certain columns or attributes are stored.

These below descriptions have shared themes about entities:

· An entity is an "item", "notion" or, “thing". But, entities can at times signify the relations among two (2) or more (N) objects. This kind of entity is identified as an associative entity.

· Entities are objects which have expressive facts. If an information object recognized by an individual is defined by means of another object, then it is an entity. When there are no expressive facts related with the object, it is not an entity. Whether or not the information objects is an entity it will be subjected to the business or action being displayed.

· An entity signifies several things which share properties. They are not solo things. For an instance, Savings and Current are both accounts which share common columns or attributes like account number, debit, credit, and balance. The entity outlining these items would be ACCOUNT, with Savings and Current being instances of the entity.

· Entities which share mutual assets are the candidates for being transformed to generalization hierarchies.

· Entities must not be castoff to discriminate among time periods. For an instance, the entities 1st Quarter Net Profit, 2nd Quarter Net Profits, etc. must be warped into a sole entity known as Net Profits. A columns or attribute identifying the time period would be castoff to classify by means of time.

· Not everything the end users desire to gather data about is an entity. A composite notion may possibly necessitate more than one entity to signify it. Other "items" the end users think significant might not be entities.

In the upcoming part we will be discussing the Columns or Attributes, how to Authenticate Columns or Attributes, Resultant Columns or Attributes as well as Code Standards and the Relations.