- Semantic Modeling
- Relational Modeling
- Entity-Relationship Modeling
- Binary Modeling
Semantic
Modeling
In
this approach, the concept of type plays a prominent role. A type is defined as
the aggregation or collection of a certain number of properties into a unit or
component. the properties themselves are also considered as types.
The
student registration example is specified as shown as follows:
- Type registration = student, course
- Type student = name, student id, street address, city, state, zip code
- Type course = course name, course number, day-of-week, time
Aggregation is represented in the
model diagram by placing it above the properties.
Figure-1 Semantic modeling : abstraction hierarchy
Relational
Modeling
The
concept of mathematical relation forms the basis for the data structure in the
relational data model. A relation is visualized as a two-dimensional table with
rows and columns containing only atomic values. example of student registration
is defined as follows in the relational model:
- Registration (student id, course number)
- Student (name, student id, street address, city, state, zip code)
- Course (course name, course number, day-of-week, time)
Relation
registration has two attributes forming two table columns. The number of rows
in each table depends on the actual data stored. Each row is uniquely
identified by values of the columns shown in bold type. The relationships and
reference between student and registration is expressed by the column student
id in the registration table.
Figure-2 E-R diagram : student registration
Entity-Relationship
Modeling
- The concepts of entity type, attribute type, and relationship type form the basis for the entityrelationship (E-R) model.
- The structuring concept is the entity type consisting of basic attribute types.
- A complete E-R model shows the attributes for each entity type.
- The parameters (m1,n1) and (m2,n2) denote maximum and minimum cardinalities of the relationships.
- Cardinalities specify how many instances of one entity type may be associated with how many instances of the other entity type.
- Cardinality parameters take the value of 0, 1, or (indicating “many”).
Chen
Model
Being
one of the earliest modeling techniques, the first version of the Chen model
lacked some components to portray the various nuances of an organization’s
information requirements. However, later enhancements rectified these
deficiencies.
Here
are some comments on this model:
- It allows displaying of multiple inheritance and multiple type hierarchies; however, this multibox approach results in undue increase in the size of the model diagram.
- Separate symbols to each attribute and each relationship seem to produce clutter.
- The model does not clearly get across the fact that an instance of subtype is an instance of a supertype.
IE
Model
Because
two prominent authorities, Clive Finkelstein and James Martin, promulgated this
method, it is still widely used. The two proponents complemented each other to
produce a good technique.
The
following are a few remarks about the IE model:
- It is reasonably concise and free from clutter.
- Notations for important components of attributes and unique identifiers are lacking.
- It has a compact approach to subtypes, easily understood by the nontechnical users.
IDEF1X
Model
The
symbols in this model do not clearly match and portray the necessary modeling
concepts. Sometimes several symbols are needed to indicate a single concept.
Particular situations need more than one set of symbols; the same set of
symbols may have a different meaning depending on the context. For example, the
symbol for optionality depends on the cardinality of the relationship. The
solid circle symbol can mean different things depending on its setting.
With
this background, here are a few comments:
- It is difficult to review an IDEF1X model with a nontechnical domain expert.
- It may be a good design tool for data modelers but is unduly hard for analysis with users.
- Making corrections and refining the model is not easy; one simple correction may involve changing many symbols.
- The multibox approach to subtypes and separate notation for each attribute and relationship use up extra room on the model diagram.
Barker
Model
This
modeling technique is ideally suited for requirement analysis with the domain
experts. Several aspects distinguish this methodology making it more desirable
than other techniques as a good communication tool with the users.
Here
are a few remarks:
- Attributes are portrayed with indicators of their optionality.
- Subtypes are shown as entities inside other entities as opposed to the way of representing them as separate entities in other models.
- It permits “exclusive OR” constraints and expresses them better than other techniques.
- It has a unique and rigorous naming convention for relationships—relationship names are prepositions, not verbs.
ORM
Model
Being
perhaps the most versatile and most descriptive of the modeling techniques, ORM
has extensive capabilities to describe objects and their roles. The model is
not simply oriented toward entities and relationships. An object may be an
entity, attribute, or a domain.
A
few remarks:
- Ordinality and cardinality of attributes are treated in exactly the same way.
- It makes domains explicit, unlike flavors of entity/relationship modeling.
- It is much more detailed than most techniques resulting in model diagram becoming less aesthetic.
- The multibox approach for representing subtypes takes more room in the diagram.
XML
Representation
As
noted earlier, XML is not really a data modeling technique. Therefore,
it lacks the ability to represent all the finer points of data structures and
relationships. However,
XML is a robust method for describing the essence of data structures and to
serve as a template for data transmission.
The
proper use of tags provides an excellent method to describe, organize, and
communicate data structures. Although tags form the most apt tools, the
responsibility and skill of database administrators are what make the tools
work.
