Article Surfing Archive

Entity-relationship analysis comprises of three major abstractions to describe data. These are entities, relationships and attributes.

Here entities are the distinct things in the enterprise. Relationship is the relation between the entities and attributes are the nature or properties of the entities.

So in a software design scenario we assimilate similar objects in sets and call these sets as entities. We then model all interactions between the objects within the entity sets by relationships or relationship sets. Relationship sets are more difficult to perceive than entity sets. We can see the entities but relationships are always underlying and we cannot see them. This makes data analysis difficult because it is necessary to create models of things that do not physically exist as single objects.

There are two major parts in entity-relationship scenario. They are Conceptual data modeling and physical data modeling.

A Conceptual Data Modeling represents the overall logical structure of a database, which is independent of any software or data storage structure. A conceptual model often contains data objects not yet implemented in the physical databases. It gives a formal representation of the data needed to run an enterprise or a business activity.

The Conceptual Data Model fills the following roles:

Represent the organization of data in a graphic format

Verify the validity of data design

Generate the Physical Data Model, which specifies the physical implementation of the database.

A Conceptual Data Model graphically represents the interaction of the following objects:

Domain : Set of values for which a data item is valid

Data item : Elementary piece of information

Entity : Person, place, thing, or concept that has characteristics of interest to the enterprise and about which you want to store information

Entity attribute : Elementary piece of information attached to an entity

Relationship : Named connection or association between entities

Inheritance link : Special relationship that defines an entity as a special case of a more general entity

Steps to build Conceptual Data Model

CDM defining domains

Defining data items

Defining entities

Defining entity attributes

Defining relationships

Defining inheritance

Defining check parameters

Defining CDM domains

Domains help us to identify the types of information in our project. They define the set of values for which a data item is valid. We include data types, lengths, lists of values and more as properties of a domain. Applying domains to data items makes it easier to standardize data characteristics for attributes in different entities. Applying domains to data items makes it easier to standardize data characteristics for attributes in different entities.

Defining data items

A data item is an elementary piece of information in the data dictionary. Rather than creating an attribute directly attached to an entity, we can define a data item first, and then attach it to an entity.

Defining entities

An entity represents an object defined within the information system about which we want to store information. For example, in a model concerning employees and divisions, the entities are Employee and Division. An occurrence of an entity is an individual element belonging to the entity. For example, the employee Mr. X is one occurrence of the entity Employee.

Defining entity attributes

Attributes are elementary pieces of information attached to an entity.

There are four ways to create an entity attribute:

Use a data item as an entity attribute

Duplicate a data item as an entity attribute

Reuse a data item as an entity attribute

Create an entity attribute directly on the attribute list

Defining relationships

A relationship is a named connection or association between entities. It expresses the reason why entities from one or two entity types are associated. For example, the relationship Member links the entities Employee and Team, because employees can be members of teams. This relationship expresses that each employee works in a team and that each team has employees. An occurrence of a relationship entails one and only one occurrence of each of the two entities involved in the relationship. For example, the employee Mr. X working in the Marketing team is one occurrence of the relationship Member.

Defining inheritance

Inheritance allows you to define an entity as a special case of a more general entity. The entities involved in an inheritance have many similar characteristics but are nonetheless different. The general entity is known as a super type (or parent) entity and contains all of the common characteristics. The special case entity is known as a subtype (or child), entity and contains all of the particular characteristics. Between entities, it is also possible to define an inheritance link. In an inheritance link, one or more subtype (or child) entities inherit, at the physical level, all or part of the attributes carried by one super type (or parent) entity.

Defining check parameters

Check parameters indicate data ranges and validation rules. You can attach check parameters to domains, data items, and entity attributes.

There are two types of check parameters:

Standard parameters : Common data controls (minimum, maximum, and accepted values, and more)

Validation rules : Customized rules for data validation

Final note

On the conceptual level, you define standard parameters. It is possible, but not recommended, to define validation rules on the conceptual level.