Isa fig 223 notation for generalization consider a

ISA
Fig. 2.23 Notation for Generalization
Consider a simple example. Suppose you have an accounting database, which keeps
track of accounts receivable and accounts payable. Of course the database keeps track
of the companies to which you owe money and the companies that owe you money. For
all these companies, you keep track of their mailing address and a contact person. For
the companies that owe you money you keep track of how much they owe you. For the
companies that you owe money you keep track of how much you owe them. What to do?
Should we have three entity types: one for the whole set and one for each subset? That
would be a mess. That is why the concept of entity subtypes was created.
In this database you should define a company entity type with two subtypes: TO_
COMPANY and FR_COMPANY. The company entity type stores all facts that are common
attributes---in this case, the address and contact person. The FR_COMPANY entity subtype
tracks the balance owed from this company while the TO_COMPANY entity subtype tracks
the balance owed to this company.
Fig. 2.24 Generalization
The inverse of generalization is called specialization. A specialization entity-set inherits
all the attributes of any of its generic entity-sets, including the entity-identifier.

34
Data Base Management systems
Notes
Amity Directorate of Distance & Online Education
Specialization
Specialization is the process of defining one or more subtypes for a supertype
and forming supertype/subtype relationship. It is termed as top-down approach. These
supertype/subtype relationships can be used in the case when

There are attributes that apply to some (but not all) of the instances of an entity type.

The instances of a subtype participate in a relationship unique to that subtype.
Consider an entity STAFF, shown in the figure.
Fig 2.25 Staff entity
In this entity type, some of the attributes apply to all the persons of the organization
like empid, name, and qualification. However some attributes are specific to a particular
type of employee. For instance, subject attribute is only for those employees who are
working a faculties, not for other supporting staff. Similarly, overtime attribute is specific
to supporting staff only as faculties are not entitled for any overtime.
These factors suggest that STAFF entity type should be specialized to FACULTY
subtype and SUPPORT STAFF. FACULTY entity will have the attributes empid, name,
qualification and subject while SUPPORT STAFF entity type will have emp.
Aggregation
Aggregation overcomes a limitation of basic ER Modeling. We can not express
relationships in that basic model. Aggregation treats a relationship as a higher-level entity.
Aggregation allows modeling relationships between relationships. We shall take an example
with which we shall illustrate the need for aggregation. Consider a database, which gives
information about students who are enrolled in different courses. Further each course has a
separate account for each student. The diagram for this using aggregation is given in fig. 2.27
Fig. 2.26 Aggregation
Summary
The ER Model is the generalization of earlier described models, hierarchical and
networks models. An ER Model is normally expressed by a graphical representation called
Entity Relationship Diagram (or E-R Diagram). Cardinality of the relationship may be defined