Enhanced ER Model Pr st ACCOUNTANT re pe Fig. 3.3 Some instances of the specialisation of EMPLOYEE into the {ACCOUNTANT, ENGINEER, MECHANIC) set of subclasses ‘As the above Fig. 3.3 suggests, a superclass/subclass relationship such as EMPLOYEE/ACCOUNTANT somewhat resembles a 1:1 relationship at the instanes level. The main difference is that, in a 1:1 relationship two distinct entities wre related. We can consider an entity in the subclass as being the sane as the entity in the superclass but playing a specialised role of ACCOUNTANT, or an EMPLOYEE specialised in the role of MECHANIC: Use of subclasses in data modeling ‘There are two main reasons for including ¢ data model © Certain attributes entity type. ‘n sabelass is defined in order to group the entities to which these attributes apply. For example, the ACCOUNTANT subclass may have an attribute experience ; whereas the ENGINEER subclass may have an attribute Engineer type, but ACCOUNTANT and ENGINEER share their other attributes as members of the EMPLOYEE entity type. | Some relationship types may be participated in only by entities that are members of the subclass. Example, if only HOURLY_EMPLOYEES can belong to a trade union, we aaa resent the fact by creating the subclass HOURLY_EMPLOYEE of EMPLOYEE and relating the subclass to an entity type TRADE_UNION via the BELONGS_TO relation type. 3.5 CONSTRAINTS ON SPECIALISATION AND GENERALISATION s of constraints that may apply to specialisation or Jass/subclass relationships in a may apply to some but not to all entities of the (superclass) ‘The various type generalisation are :Database Management and Desig, ew total edi partial overlapping disjoint total ° Overlapping total ‘¢ Overlapping partial fining attribute for 4 traints that apply tog for brevity, we shal} th specialisation ang @ disjoint partial In addition, a defining predicate for a subclass or & d specialisation may be specified. We shall discuss now co" ingle specialisation or a single generalisation. Howevs’, hh it applies to bot discuss the specialisation only even thougl generalisation. Refer Fig, 3.2. We have several specialisations defined on the same such a case, entities may for example a specialisal ) specialisation. In such a case, pelong to subclasses in each tion may consist of a single we are not using a (superclass) entity type. In st of the specialisations, Take subclass only like (Manager! circle notation. ‘Mechanic’ MECHANIC. Exper Fig. 3.4 (a) Attribute-defined specialisation on the job type attribute of EMPLOYEE In some specialisations, we can decide exactl iti , y the entities that wi members of each subclass, by placing condition on the value of, nae attibats the superclass, Such subclasses are called predicate-defined or condition defined subclasses. For example, if the EMPLOYEE entity type has an attribute job type as shown in fig. below, we can specify the condition of Rete in the |Enhanced ER Model “~ ACCOUNTANT subclass by the predicate (Job typox"A 4G call the defining predicate of the subclass, The fenditien oacoupeity ee err that members of the ACCOUNTANT subclass must satisfy the predicate and that all entities in the EMPLOYER entity type whowe attribute value for job wpe is Arountant ue felong to the subclass, We display a predicate defined subclass by writing the predicate condition next oe aa dept ‘ext to the line that connects the EMPLOYEE, |ALAREED. [Accountant] EoivEER]( MECHANIC} 5) ( HOURLY_ ge TIME, EMPLOYEE} \EMPLOYER) | EMPLOYEE) LU) ENGINEERING_ MANAGER Fig. 3.4 (b) Specialisation lattice with the shared subclass ENGINEERING MANAGER If all the subclasses in a specialisation have the membership condition on the same attribute of the superclass, the specialisation itselfis called an attribute- defined specialisation and the attribute is called the defining attribute of the specialisation. We display an attribute defined specialisation as shown in figure 3.4 (a), by placing the defining attribute name next to the are from the circle to the superclass. When we do not have such a condition for determining membership, the subclass is called user defined. ‘Two other constraints may apply to specialisation. * disjointness constraint * non disjoint (over lapping) constraint The first one, specifies that the subclasses of the specialisation must be disjoint (an entity can be a member of at most one of the subclasses of the specialisation), Figure 3.4 (a), illustrates this case, where the d in the circle stands for disjoint, We also use the d notation to specify the constraint that user defined subclasses of a specialisation must be disjoint as illustrated by the specialisation. (HOURLY EMPLOYEE, SALARIED_EMPLOYEE, PART TIME_ EMPLOYEE) in Fig. 3,2. Here a specialisation that is attribute defined implies the disjointness constraint if the attribute used to define the membership predicate is single valued,oe Database Management ang i i tities may overlap, that ig if the subclasses are not disjoint, their sets of ent hat is, ‘ins entity may be a member of more than one subclass oF fo Pecilie Overlap is displayed by placing on O in the circle as shown in the figure 3.5 Supplier Name MANUFACTURED_PART BOUGHT_OUT Fig. 3.5 Specialisation with non disjoint (overlapping) subclasses The second constraint on specialisation is called the completeness constrain which may be either : © Total (Every entry entity in the superclass must be a member of subclass in the specialisation) Partial (Allows an entity not to belong to any of the subclasses) For example, if every EMPLOYEE must be either an HOURLY_EMPLOYEE ofa SALARIED_EMPLOYEE, PART_TIME EMPLOYEE of Fig. 3.2 is a total fPesialisation of EMPLOYEE; this is shown in EER diagrams by using double line to connect the superclass to the circle. A single line is used to display a partial specialisation, Please note that the disjointness and completeness constraints are independent. 3.6 DISJOINTNESS Disjointness is already explained in para 3.5, that is constraints om specialisation and generalisation. Two constraints referred to specialisation are disjointness constraint completeness or partial, Disjointness constraint specifies or the subclass of the specialisation must be disjoint. This means that an entity can be a member atmost of one of the subclasses of the specialisation Nondisjoint constraint is a” | |enhanced ER Model ‘i 85 overlapping constraint. See figure 3.4 (b) illustrate isjoi ecircle et ee We also use the d Fitton leobet Weg pai efined subclasses of a specialisation must be disjoint = eee ee strated by that user~ ‘we gpecialisation {HOURLY_EMP the a9ecias ee), a LOYEE, SALARIED EMPLOYEE