ISA Fig 223 Notation for Generalization Consider a simple example Suppose you

Isa fig 223 notation for generalization consider a

This preview shows page 9 - 11 out of 15 pages.

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.
Image of page 9
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
Image of page 10
Image of page 11

You've reached the end of your free preview.

Want to read all 15 pages?

  • Winter '17
  • DR Mubashir

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture