Lecture Handout. Database Management System. Overview of Lecture. Inheritance Is. Lecture No. 11. Reading Material

Transcription

1 Lecture Handut Database Management System Lecture N. 11 Reading Material Database Systems Principles, Design and Implementatin written by Catherine Ricard, Maxwell Macmillan. Overview f Lecture Inheritance Super type Subtypes Cnstraints Cmpleteness Disjintness Subtype Discriminatin Accrding t the Micrsft Dictinary f Cmputing Inheritance Is The transfer f the characteristics f a class in bject-riented prgramming t ther classes derived frm it. Fr example, if vegetable is a class, the classes legume and rt can be derived frm it, and each will inherit the prperties f the vegetable class: name, grwing seasn, and s n2. Transfer f certain prperties such as pen files, frm a parent prgram r prcess t anther prgram r prcess that the parent causes t run. Page 89

2 Inheritance in the paradigm f database systems we mean the transfer f prperties f ne entity t sme derived entities, which have been derived frm the same entities. Super types and Subtypes Subtypes hld all the prperties f their crrespnding super-types. Means all thse subtypes which are cnnected t a specific supertype will have all the prperties f their supertype. EmpName EmpAddress EmpId EMPLOYEE EmpPhN Grade NOfHrs SALARIED HOURLY AnnualSal HurlyRate Fig-1 a The Figure:1 abve shws that the supertype and subtype relatin between the SALARIED and HOURLY emplyees with the supertype entity EMPLOYEE, we can see that the attributes which are specific t the subtype entities are nt shwn with the supertype entity. Only thse attributes are shwn n the supertype entity which are t be inherited t the subtypes and are cmmn t all the subtype entities assciated with this supertype. Page 90

3 The example shws that there is a majr entity r entity supertype name EMPLOYEE and has a number f attributes. Nw that in a certain rganizatin there can be a number f emplyees being paid n different payment criteria. P_Name P_Address P_Id PERSON P_PhN C_Name Qual STD FAC CGPA Grade Fig 1 b The secnd example is that f student and the Faculty members wh are at the super level same type f entities. Bth the entities at the super level belng t the same entity f type Persn. The distinct attributes f the student and faculty members are added later t he sub entities student and fac. Supertype / subtype Relatinship: The use f supertype and subtype fr the entities is very useful because it allws us t create hierarchy f the entities accrding t the attributes they have and we need nt t write all the attributes again and again. We can grup similar types f entities and the attributes assciated with thse entities at certain levels. This als adds clarity t the definitins f the entities as it is nt necessary t write the attribute again and again fr all the entities. Page 91

4 Mrever it als eases the peratin f remving r adding attributes frm the entities, here it is wrth nting that adding an attribute at the super entity level will add the attribute t the belw listed r derived sub entities and remving the attribute will remve the attribute frm the entities at sublevels in the same way. The prcess f identifying supertype and creating different type f sub entities is supprted by the general knwledge f the designer abut the rganizatin and als based f the attributes f the entities which are entities existing in the system.. Specifying Cnstraints Once there has been established a super/sub entity relatinship there are a number f cnstraints which can be specified fr this relatinship fr specifying further restrictins n the relatinship. Cmpleteness Cnstraint There are tw types f cmpleteness cnstraints, partial cmpleteness cnstraints and ttal cmpleteness cnstraints. Ttal Cmpleteness: Ttal Cmpleteness cnstraint exist nly if we have a super type and sme subtypes assciated with that supertype, and the fllwing situatin exists between the super type and subtype. All the instances f the supertype entity must be present in at ne f the subtype entities, i.e. there shuld be nt instance f the supertype entity which des nt belng t any f the subtype entity. This is a specific situatin when the supertype entities are very carefully analyzed fr their assciated subtype entities and n sub type entity is ignred when deriving sub entities frm the supertype entity. Page 92

5 Partial Cmpleteness Cnstraint: This type f cmpleteness cnstraint exists when it is nt necessary fr any supertype entity t have its entire instance set t be assciated with any f the subtype entity. This type f situatin exists when we d nt identify all subtype entities assciated with a supertype entity, r ignre any subtype entity due t less imprtance f least usage in a specific scenari. Disjintness Cnstraint This rule r cnstraint defines the existence f a supertype entity in a subtype entity. There exist type types f disjint rules. Disjintness rule Overlap rule Disjint cnstraint: This cnstraint restricts the existence f ne instance f any supertype entity t exactly ne instance f any f the subtype entities. Cnsidering the example given in Fig 1a it is seen that there can be tw types f emplyees, ne which are fixed salary emplyees and the thers are hurly paid emplyees. Nw the disjint rule tells that at a certain type an emplyee will be either hurly paid emplyee r salaried emplyee, he can nt be placed in bth the categries in parallel. Overlap Rule: This rule is in cntrast with the disjint rule, and tells that fr ne instance f any supertype entity there can be multiple instances existences f the f the instance fr mre then ne subtype entities. Again taking the same example f the emplyee in an rganizatin we can say that ne emplyee wh is wrking in an rganizatin can be allwed t wrk fr the cmpany at hurly rates als nce he has cmpleted his duty as a Page 93

6 salaried emplyee. In such a situatin the emplyee instance recrd fr this emplyee will be stred in bth the sub entity types. P_Name AdmDate Ph_Id P_Id PATIENT RESPONSIBLE PHYSICIAN Prescriptin WardN OUT DOOR PATIENT IN DOOR PATIENT DateDischarge Fig 2-a In the example the cmpleteness f the relatin is shwn between the supertype entity and the subtype entity, it shws that fr the data f patients we can have nly tw type f patients and ne patient can be either an utdr patient r indr patient. In it we can see that we have identified all pssible subtypes f the supertype patient. This implies a cmpleteness cnstraint. One mre thing t nte here is the linked entity physician t the patient entity. And all the relatinships assciated with the supertype entity are inherited t subtype entities f the cncerned supertype. Page 94

7 Veh_Id Mdel Price VEHICLE Registratin NOfDrs CAR TRUCK Pessengers Fig 2-b The Figure2b shws the supertype and subtype relatinship amng different type f vehicles. Here we can see that the Vehicle has nly tw subtypes, knwn as Truck and Car, As it is nrmal t have a number f ther vehicles in the cmpany f a certain type but when we have nted just a limited number f vehicles then it means that we are nt interested in string infrmatin fr all the vehicles as separate entities. They may be stred in the vehicle entity type itself and distinct vehicle may be stred in the subtypes car and truck f the Vehicle. This is a scenari where we have the freedm t stre several entities and neglect thers, and it is called as partial cmpleteness cnstraint rule. After the discussin f the Ttal Cmpleteness and Partial cmpleteness let us mve t the next cnstraint that is disjintness and check fr its examples. Again in the Figure 2-a. we have the envirnment where patient entity type has tw subtypes indr and utdr patient. T represent disjintness we place the letter D in the circle which is splitting the super entity type int tw sub entity types. Suppse that the hspital has placed a restrictin n the patient t be either a n indr patient r Page 95

8 utdr patient, in such a case there exists disjintness which specifies that the patients data can nt be place in the database in bth the subtype entities. It will be wither indr r utdr. Part_N PartName PART O Sup_Id MANUFAC- TURED PURCHASED PURCHASED Sup_address Fig- 3 The figure 3 abve shws the secnd type f disjint cnstraint which tells that the entity subtype instance can be repeated fr any single entity supertype instance. We can see the relatinship f a certain hardware cmpany fr the parts prvided by the cmpany t its clients. Nw there may exist an verlapping situatin fr a certain part which is t be prvided t a certain firm, but the manufactured quantity f that part is nt enugh t meet the specific rder, In this situatin the cmpany purchases the remaining the deficient number f parts frm the ther suppliers. We can easily say that the data fr that specific part is t be placed in bth the entity subtypes. Because it belngs t bth the subtype entities, this is an verlapping situatin and expresses disjintness with verlapping. Anther imprtant thing which is t be nted here that the purchased part subtype entity has a relatinship with anther entity where the data fr the suppliers is stred frm whm the parts are bught. Nw this relatin des nt have nay interactin with the manufactured parts relatin as it is nt cnnected with its supertype i.e. parts supertype entity. Page 96

9 Cnsidering the abve discussed we can have fur different types f cmbinatin existing fr the supertype and subtype entities. Cmplete Disjint Cmplete Overlapping Partial Disjint Partial verlapping Subtype Discriminatr This is a tl r a technique which prvides us a methdlgy t determine that t which subtype ne instance f a supertype belngs. T determine the relatin we place an attribute in the entity supertype which can specify thrugh its value, that t which entity subtype it belngs. Fr example we cnsider the example There can be tw different situatins which specify the placement r relatinship f a supertype entity instance in a subtype entity instance. First situatin is that f disjint situatin where ne supertype entity instance can be placed nly in ne subtype f that supertype. Let us cnsider the example f vehicles abve in Figure-2-b it shw that there can be tw different vehicles car and truck assciated with the supertype vehicle nw if we place an attribute named Vehicle_type in the supertype we can easily determine the type f the assciated subtype by placing a C fr car and a T fr truck instance f the vehicle. The ther situatin where the Subtype discriminatr is required the verlapping cnstraint; it is the situatin where ne supertype attribute can be placed in mre than ne subtype entities. Cnsidering again the part example shwn in Figure 3, which has an verlapping cnstraint; In this situatin we can have many slutin ne cmmn slutin is t place tw attribute in the supertype ne fr manufactured and ther ne fr purchased. We can cmbine them as a cmpsite attribute, when we place Y fr manufacture and N fr Page 97

10 Purchased then it means the part is manufactured by the cmpany, and similarly the fllwing situatin will give us further infrmatin Attribute Manufacture Purchased Result Y Y Manufacture Purchased Y N Manufactured N Y Purchased. Significance f Subtype Discriminatr: Existence f subtype discriminatr helps us a lt in finding the crrespnding subtype entities, althugh we can find a subtype entity instance withut having a subtype discriminatr in the supertype but that invlves lts f effrts and might cnsume a huge time in wrst case situatins. This cncludes ut discussin f The ER Mdel in the curse. Page 98