Entity-Relationship Modeling

 

Contrasting Design for Database and OOAD

Information modeling originated and became popular within the database community. It is concerned with modeling the structure of data so that it can be properly managed by a database.

The Entity-Relationship (ER) approach is the most common approach to information modeling. ER is a popular graphical technique because the notation is easy to understand, yet powerful to model real problems.  ER diagrams are readily converted into a database implementation.  The ER diagram focuses solely on data, representing a “data network” that exists for a given system.  The ERD is especially useful for application in which data and relationships, that govern data, are complex.  The ER model consists of three interrelated pieces of information, the data-object, the attributes that describe the data, object and the relationship that connect data object to one another.

Data Objects, Attributes and Relationships

A data object is a representation of any composite information that must be understood by software.  Composite information is something that has a number of different properties and attributes.  For example, width is an invalid data object, but dimension (having height, width and depth) is valid object.  Attributes define the properties of data object and are used to:

  • Name an instances of data object
  • Describe the instance
  • Make reference to another instance in another table
  • Act as “key” to identify a data object.  For example car ID.

The relationships show how data objects are connected to each other.  For example, a bookstore orders books where order is a relationship.

 

Cardinality and Modality

Cardinality is the degree of relationship in a pair of objects.  It is the specification of number of occurrences of one object that can be related to the number of occurrences of another.  The possible combinations are, 1 : 1 (one-to-one), 1 : N (one-to-many) and M : N (many-to-many).

Modality of a relationship is 0 if there is no explicit need for the relationship to occur or the relationship is optional.  The modality is 1 if an occurrence of relationship is mandatory.  The example of cardinality and modality is given in fig 1

 

en

 

The symbols of the relationship closest to the data object rectangles indicate cardinality.  Modality is indicated by the symbols that are further away from the data object diagram.  A single customer can be provided with zero or many repairs, but one repair action is associated with one customer. Further, the circle on the right object indicates that there may not be any repair action required for the type of problem repaired by the customer.

 

Entity Relationship Diagrams

Data objects are represented by a labeled rectangle. A labeled line connecting objects indicates relationships. In some variations, the connecting line contains a diamond that is labeled. The attributes are mentioned in oval. An example of ER diagram is given in fig 2

 

en1

 

Fig 3 shows a relational database linked to each other by a common field D#.

1D #

Make

Model

Color

Owner

Lexus

LS400

White

RSP

Cherry

Corvette

Red

CCD

BMW

75 Oil

White

IJK

 

ID#

Price

1.

50

2.

70

3.

100

Figure 3


The following categories can be used to differentiate between the conventional and OO analysis methods:

  • Identification/classification of entities
  • General to specific and whole-to-part entity relationships
  • Other entity relationships
  • Description of attributes of entities
  • Large scale model positioning
  • States and transition between states
  • Top-down decomposition
  • Detailed specification for functions
  • Identification for exclusive services
  • Entity communication (through message or events)

 

The following methods are used to compare various conventional and OO design methods: -

  • Representation of hierarchy of modules
  • Specification of data definitions
  • Specification of procedural logic
  • Indication of end-to-end processing sequence
  • Representation of object state and transitions
  • Definition of classes and hierarchies
  • Assignment of operations to classes
  • Detailed definition of operations
  • Specification of message connections
  • Identification of exclusive services

 

 

 

 



Like it on Facebook, Tweet it or share this article on other bookmarking websites.

No comments