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

· Categorizing Relationships – Relationships are categorized by their degree, connectivity, cardinality, course, kind, as well as presence. Not every model practices practice all these categorizations. Among these various categories – degree, connectivity, and cardinality are already explained in Part – 2. The reaming categories like course, kind, as well as presence are explained in this part.

o Course – The course of a relationship specifies the initiating object or entity of a binary (2) relationship. The object or entity from which an association is initiated is known as the parent object or entity; the object or entity where the association ends is known as the child object or entity.

The course of a relationship is by means of its connectivity. In a one to one (1 to 1) relationship the course is from the independent object or entity to a dependent object or entity. When both the objects or entities are independent then the course is random. By means of one to many (1 to N) relationships, the object or entity occurring only once is identified as the parent object or entity. The course of many to many (N to N) relationships is again random.

o Kind – A classifying relationship is such type of relationship in which one (1) of the child objects or entities is a dependent object or entity too. A non-classifying relationship is such type of relationship in which both the objects or entities are independent objects or entities.

o Presence – Presence signifies whether the reality of an object or entity occurrence is dependent on the actuality of an additional, connected, object or entity occurrence. The presence of an object or entity in a relationship is demarcated as either obligatory otherwise noncompulsory. If an occurrence of an object or entity should all the time occur for an object or entity to be comprised of in a relationship, at that moment the presence is obligatory. An instance of obligatory presence is the declaration "every class should be handled by a single class teacher". If the occurrence of the object or entity is not needed, it is noncompulsory. An instance of noncompulsory presence is the declaration, "teachers may possibly be allotted to classes".

· Simplification Hierarchies – A simplification hierarchy is a procedure of generalization which states that two (2) or more (N) objects or entities which share mutual characteristics can be indiscriminate into a developed level object or entity type known as a super-type or general object or entity. The lower level of objects or entities turns out to be the sub-type, or groups, to the super-type. Sub-types are dependent objects or entities.

Simplification happens at the time when two (2) or more (N) objects or entities signify classes of the similar real world items. For an instance, Surgeon_Doctors and Physician_Doctors signify classes of the similar object or entity, Doctors. In this particular case, Doctors would be the super-type and Surgeon_Doctors as well as Physician_Doctors would be the sub-types.

Sub-types can be either mutually exclusive (dis-joint type) or else overlapping (inclusive type). The mutually exclusive type is when an object or entity occurrence can be in one (1) class only. The abovementioned instance is the mutually exclusive type. The doctor can be surgeon or else physician but surely not both. The overlapping type is when an object or entity occurrence may possibly be in two (2) or more (N) sub-types. An instance can be an individual who has savings account in some ABC Bank may also work in the same bank. The comprehensiveness constraint needs that all occurrences of the sub-type can be signified in the super-type. Simplification hierarchies can be nested too. That is, a sub-type of one (1) hierarchy can be a super-type of another. The level of nesting is restricted by means of the constriction of simplicity only. Sub-type objects or entities may possibly be the parent object or entity in a relationship but surely not the child object or entity.

• Entity Relationship (ER) Symbolization – There is no standard for signifying information items in Entity Relationship (ER) diagrams. Every single model practices its individual symbolization procedure. Every symbolization styles signify objects or entities as rectangular boxes as well as associations as lines linking the boxes. Every single style usages a distinct set of symbols to signify the cardinality of a linking. The symbolization castoff in this article is referred from Martin (one can follow the link for further details). The symbols castoff for the simple Entity Relationship (ER) diagram are as follows:

o Entities or objects are signified by means of labeled rectangles. The name of the entity or object is present in the label. Entity or object name must be of singular noun.

o Associations are signified by means of a solid line linking two (2) objects or entities. The name of the association is inscribed above the connecting line. The association name must be a verb.

o Columns or attributes, when involved, are itemized within the entity or object rectangle box. Columns or attributes which are identifiers are underlined. Columns or attribute name must be of singular noun.

o Cardinality of many (N) is signified by means of a line finishing in a crow’s foot notation. When the crow’s foot is absent, then the cardinality is one (1).

o Presence is signified by means of inserting a ring otherwise a vertical bar on the line. Obligatory presence is displayed by means of the bar (appears like – | ) adjacent to the object or entity for an occurrence is needed. Noncompulsory presence is presented by means of inserting a ring adjacent to the object or entity which is a noncompulsory. For further clarification refer the below illustration.

In the upcoming part we will be discussing the Database Design with Information Modeling, Goals of Requirements Analysis, Few methods of collecting data for requirement analysis, Three (3) facts about the requirements analysis.