2. Section 09ER Decomposition Of Many To Many1 HSQ - DATABASES & SQL And Franchise Colleges 09 ER Decomposition of Many-to-Many

3. Section 09ER Decomposition Of Many To Many2 A MANY to MANY relationship can be decomposed into two ONE to MANY relationship. Decomposition of many to many relationships is a standard E-R technique. All many to many relationship types must be decomposed to form a complex entity as above. Mapping many to many relationship types back to reality often is very difficult.... Decomposition of a Many to Many Relationship

4. Section 09ER Decomposition Of Many To Many3 p# pdesc cost rrps# sname saddress p1 4mb simm10 20s1 CMMNewcastle p1 4mb simm10 20s4 INGRAMRedcar p2 850mb HD175 249 s1 CMMNewcastle p3 1gb HD 199 278s2 ABCDarlington p3 1gb HD 199 278s5 Comp. R. UsDarlington p4 20” Mtr 699 899s1 CMMNewcastle p4 20” Mtr 699 899s2 ABCDarlington p4 20” Mtr 699 899s5 Comp. R. UsDarlington ENTITIES :PARTS, SUPPLIERS RELATIONSHIP :many parts supplied by many suppliers. PARTSSUPPLIERS supplied by ER MODEL : Example : Many PARTS supplied by Many SUPPLIERS

5. Section 09ER Decomposition Of Many To Many4 The relationship between PARTS and SUPPLIES cannot be directly mapped into tables because of the variable number of links. Parts->Supplier LinkSupplier->Parts Link p1s1, s4s1 p1, p2, p4 p2s1s2 p3, p4 p3s2, s5s3 p4s1, s2, s5s4 p1 s5 p3, p4 OCCURRENCE DIAGRAM : P# p1 p2 p3 p4 S# s1 s2 s3 s4 s5

6. Section 09ER Decomposition Of Many To Many5 PARTSSUPPLIERS supplied by PART PART-SUPP SUPPLIER * BECOMES PART p# pdesc cost rrp p1 4mb simm 10 20 p2 850mb HD 175 249 p3 1gb HD 199 278 p4 20” Mtr 699 899 part-supp p# s# p1 s1 p1 s4 p2 s1 p3 s2 p3 s5 p4 s1 p4 s2 p4 s5 SUPPLIER s# sname saddress s1 CMMNewcastle s2 ABCDarlington s3 SIMMTECHHartlepool s4 INGRAMRedcar s5 Comp. R. UsDarlington * THE RELATIONSHIPS BECOME REDUNDANT ALL LINKAGE IS DONE THROUGH THE NEW ENTITY PART-SUPP ALL LINKAGE IS DONE THROUGH THE NEW ENTITY PART-SUPP *

7. Section 09ER Decomposition Of Many To Many6 staff#, lname, room, ext.student#, sname, saddress staff# student# LECTURER STUDENT lectures LECTURER L1 L2 L3 L4 L5 L6 lectures STUDENT S1 S2 S3 S4 Sn –Enterprise Rule : ‘MANY LECTURERS LECTURES MANY STUDENTS ‘MANY STUDENTS LECTURED by MANY LECTURER –Occurrence Diagram : m:n MANY-to-MANY Relationship

8. Section 09ER Decomposition Of Many To Many7 staff#, lname, room, ext. student#, sname, saddress staff# student# LECTURER STUDENT lectures LECTURER L1 L2 L3 L4 L5 L6 lectures STUDENT S1 S2 S3 S4 Sn –Enterprise Rule : MANY LECTURERS LECTURES MANY STUDENTS MANY STUDENTS LECTURED by MANY LECTURER –Occurrence Diagram : Example : Many LECTURERS lectures Many STUDENTS

9. Section 09ER Decomposition Of Many To Many8 u Skeleton Tables : Simple Solution LECTURER(staff#, lname, room, ext) lectures(staff#, student#) STUDENT(student#, sname, saddress) u Populated Tables u using links from occurrence diagram & sample data to show relationship) LECTURER lecturesDEPARTMENT staff# lname room ext staff# student#student# sname L1 ALBERT A4 12 L1 S3S1 bloggs L2 BLOGGS B2 18 L3 S1S2 jones L3 COATES C1 22 L5 SnS3 green L4 GREEN A3 11 L1 S2S4 smith L5 JONES D1 53 L1 S4Sn zues L6 SMITH A5 18 L1 S1 L2 S1 L2 S1 L3 S1 L3 S1

10. Section 09ER Decomposition Of Many To Many9 u Skeleton Tables : Foreign Key Solution (MS ACCESS) u m:n cannot be represented by foreign key import u MS ACCESS cannot map m:n relationships u Populated Tables u using links from occurrence diagram & sample data to show relationship) LECTURER STUDENT staff# lname room ext student# student# sname staff L1 ALBERT A4 12 S1, S2, S3, S4 S1 bloggs L1, L2, L3, L4 L2 BLOGGS B2 18 S1 S2 jones L1 L3 COATES C1 22 S1 S3 green L1 L4 GREEN A3 11 S1S4 smith L1 L5 JONES D1 53 Sn Sn zues L5 L6 SMITH A5 18 VARIABLE LENGTH RECORDS ARE GENERATED!!! SOLUTION - DECOMPOSE M:N to 1:M and M:1

11. Section 09ER Decomposition Of Many To Many10 staff#, student# staff#, lname, room, ext student#, sname LECTURER STUDENT councelslecturersproj-supp –We are able to map and model any number of relationships between entities. –Modelled below are the 3 different types of relationship covered in Section 04. –More entities can be linked to complete a data model of a system. LECTURER STUDENT MODEL

12. Section 09ER Decomposition Of Many To Many11 staff#, student# staff#, lname, room, ext student#, sname LECTURER STUDENT councelslecturersproj-supp FIRST CUT DATA MODEL : LECTURER STUDENT m:n not decomposed FIRST CUT TABLES : LECTURER STUDENT LECTURER (@staff#, lname, room, ext) STUDENT (@student, sname) lectures (@staff#, @student#) proj-spec (@staff#, @student#) councels (@staff#, @student#)

13. Section 09ER Decomposition Of Many To Many12 staff#, student# staff#, lname, room, ext student#, sname * * LECTURER STUDENT councelsproj-supp LECTURES TABLES : LECTURER STUDENT Simple Solution LECTURER (@staff#, lname, room, ext) STUDENT (@student, sname) LECTURES (@staff#, @student#) proj-spec (@staff#, @student#) councels (@staff#, @student#) TABLES : LECTURER STUDENT USING FOREING KEY DESIGN LECTURER (@staff#, lname, room, ext) STUDENT (@student, sname, proj-supp- staff#, councel-staff#) councel-staff#) LECTURES (@staff#, @student#) SECOND CUT LECTURER STUDENT MODEL m:n decomposed m:n decomposed

14. Section 09ER Decomposition Of Many To Many13 Customer (Customer_no, name, street, town, county, post_code) Car (reg_no, model, engine_size) Where would the data representing the date a car is hired out be held? As an attribute of Car? The identifier of Car is Reg_no. So, any reg_no can only appear once in this entity. A car may be hired out many times so the reg_no would appear many times if Car had an attribute Date_out. As an attribute of Customer? Does not make sense- the date a customer is hired out? There is an entity missing. This is a typical feature of Many-many relationships i.e. indicates incompleteness. Example : Many CUSTOMERS hires Many CARS

15. Section 09ER Decomposition Of Many To Many14 Car Customer Contracts _for_a Car Customer Current_ Contract For_a Takes_ out_a EntitiesCustomer (Customer_no, name, street, town, county, post_code) Car (reg_no, model, engine_size) Current_Contract (reg_no, customer_no, date_out, date_in) Identifier of new entity is a composite identifier made up from the identifiers of the two original entities. The new entity represents current contracts as a customer cannot hire the same car again as the entity currently stands. This new entity is now the home for the date_in, date_out attributes. Note how the original participation conditions are preserved.

16. Section 09ER Decomposition Of Many To Many15 Entities Customer (Customer_no, name, street, town, county, post_code) Car (reg_no, model, engine_size) Contract (reg_no, customer_no, contract_date, date_out, date_in) Adding a contract_date to the identifier of current_contract allows the same car to be hired to the same customer on a different date. Car Customer Contract For_a Takes_ out_a

17. Section 09ER Decomposition Of Many To Many16 Why does Decomposition work? A possible Entity Occurrence Diagram Attends Patient A&E Dept m m Patient P3 P7 P21 P5 P17 A&E Dept AE4 AE29 AE3 Attends

18. Section 09ER Decomposition Of Many To Many17 Giving each Attendance a unique number: –Each instance of a relationship between Patient and A&E Dept Patient P3 P7 P21 P5 P17 A&E Dept AE4 AE29 AE3 Attendance A3 A1 A6 A9 A7 A8 The Attendance Entity is revealed. A new Complex Entity.

19. Section 09ER Decomposition Of Many To Many18 The New Complex Entity Decomposing the original m:m relationship gives: by Patient Attendance 1 m m1 at A&E Dept Notice how easy and simple it is to name the two new relationships outwards from the Complex Entity. Also notice the pattern of the degree of association and membership class. Is decomposition easy? So where is the difficulty???

20. Section 09ER Decomposition Of Many To Many19 A Complex Entity Type Mapping Tool Decomposition of a many to many relationship type reveals a complex entity –An entity with more than one attribute in its identifier. –It may be a simple entity type that has not been identified so far. –The new entity may be something obvious to a user but not to the data analyst or equally something unfamiliar to both. You may be tempted simply to assign the complex entity a code or number as identifier, however: –A complex entity always has a 'natural' composite identifier. –It is helpful to the understanding of a entity to know its ‘natural’ identifier even if we eventually use a code instead. To use a complex entity in an ERD you need the following: ENTITY NAME ATTRIBUTES IDENTIFIER DESCRIPTION

21. Section 09ER Decomposition Of Many To Many20 Example Appropriately name the new entity type. Complex entity naming may be difficult. –A weak name may initially be all that is possible at first such as Employee-Project. –An attempt should be made to find a 'good' name. Asymmetric viewing often provides useful clues –Something like "Assignment", "Task" or "Job" would hopefully be found. Decompose the Many to Many relationship

22. Section 09ER Decomposition Of Many To Many21 Asymmetric Viewing Tool for Complex Entities (look both ways!) This is a Simple Tool to help in the mapping of complex entities The analyst often finds it difficult to decide what the complex entity represents in reality. –Thus, in this example they cannot define an Assignment. –To put it another way, the analyst cannot say what it is a list of. –Using this tool the analyst examines the complex entity from the viewpoint of each contributing entity in turn. Examining the diagram from the Employee viewpoint: –Assignment is a list of the projects that an employee is involved in and the roles they have in those projects. Examining the diagram from the Project viewpoint: –Assignment is a list of the employees are involved in a project and the roles they have in those projects.

23. Section 09ER Decomposition Of Many To Many22 Identifiers for Complex Entities Select appropriate identifier for the new entity type, often a composite of attributes. –A composite of the Foreign Keys? For this example, [emp#,project#] seems appropriate at first. – Invent several new attributes for the new entity type. This aspect is essential. For example; role, supervisor, hours-allocated, hours-so-far, hours-required, date-started, finish-date. Asymmetric viewing is useful again in finding new attributes of the complex entity. For any entity type you wish to include in a database, you should be able to invent or observe appropriate attributes.

24. Section 09ER Decomposition Of Many To Many23 Checking the identifier of a Complex Entity Draw up an appropriate relational table and create an example table occurrence. –We have guessed that the identifier is [emp#, project#] Now simply invent a few reasonable rows using combinations of value of emp# and project# as instances of the identifier. An experiment! –The experiment also works well with fewer attributes; just one additional attribute (other than the identifier) is usually sufficient. We then try to repeat one of the instances of the identifier in a new row. – We try to find out if different attribute values are possible for that row (illustrated below in the first and last rows). It does not make sense to have the same assignment repeated with a different finish-date.

25. Section 09ER Decomposition Of Many To Many24 A ‘better’ Identifier The identifier [ emp#,project#] is clearly inadequate –It is possible that the same employee can have multiple roles on the same project. The identifier [ emp#,project#, role] now seems more sensible. Look at the new row below and work out why the above identifier is more appropriate.

26. Section 09ER Decomposition Of Many To Many25 Finally the entity can be documented as below: ENTITY NAMEAssignment ATTRIBUTESemp#, project#, role, supervisor, hrs-alloc, hrs-so-far, start-date, finish-date hrs-rec, IDENTIFIERemp#,project#, role DESCRIPTIONetc. Repeat the process until your judgement is that the entity is well enough defined. Never integrate an entity into a model if don't know it's identifier and some attributes The Best Identifier??

27. Section 09ER Decomposition Of Many To Many26 Consider the following identifiers for the 'Assignment' complex entity and their implications. emp#,project#, role, start-date, supervisor, hrs-alloc, hrs-so-far, hrs-rec, finish-date emp#,project#, start-date, role, supervisor, hrs-alloc, hrs-so-far, hrs-rec, start-date, finish-date emp#,project#, role, sequence-number, supervisor, hrs-alloc, hrs-so-far, hrs-rec, start-date, finish-date emp#,project#, sequence-number, role, supervisor, hrs-alloc, hrs-so-far, hrs-rec, start-date, finish-date The sequence number simply implies a chronological order to an employee's assignments. The 'Assignment' problem solution is very general and other solutions are possible. –Perhaps an employee can be reassigned to a project for the same role (e.g. programming).

28. Section 09ER Decomposition Of Many To Many27 Summary Introduced Decomposition of m:m relationships to form Complex Entities. Explained that understanding Complex Entities can be difficult. Introduced Asymmetric Viewing (a long name for a simple idea). Showed that for any entity you need to know: ENTITY NAME ATTRIBUTES IDENTIFIER DESCRIPTION Introduced a technique for verifying the identifiers of Complex Entities.

29. Section 09ER Decomposition Of Many To Many28 ERD SAMPLES Ascent Resources Ascent S/W and ERD Solutions Installing Ascent At Home Using Ascent - ER Modeling Library of Free Data Models

30. Section 09ER Decomposition Of Many To Many29 End of Lecture