1. 44220: Database Design & Implementation Conceptual Data Modelling Ian Perry Room: C49 Tel Ext.: 7287 E-mail: I.P.Perry@hull.ac.ukI.P.Perry@hull.ac.uk http://itsy.co.uk/ac/0506/sem2/44220_DDI/

2. Ian PerrySlide 244220: Database Design & Implementation: Conceptual Data Modelling Remember the ‘Stack’ We MUST begin by developing a Conceptual Data Model.

3. Ian PerrySlide 344220: Database Design & Implementation: Conceptual Data Modelling Conceptual Data Model? A Conceptual Data Model is an abstraction which reflects the requirements of a ‘real- world’ system, by definition of: Objects of Interest Semantics Constraints Need a ‘language’ to explore & explain our view of a ‘real-world’ situation: Ideally this ‘language’ should be compromise free and will ‘work’ using any Software & Hardware. Useful choice is that of ER Modelling: Need to identify Entities, Attributes & Relationships.

4. Ian PerrySlide 444220: Database Design & Implementation: Conceptual Data Modelling ‘Facts’ about the ‘Real-World’ Customers place orders. Patients take medication. Lecturers teach students. Students attend lectures: Some students attend all lectures. Some students attend some lectures. Some students attend no lectures!

5. Ian PerrySlide 544220: Database Design & Implementation: Conceptual Data Modelling ‘Facts’ need to be Expressed An ER Model lets us do so in way that: Encourages thorough Analysis. Can be applied to ALL Database Theories. Is independent of Software & Hardware. Provides an effective means of Communication. For an ER Model we must determine: the Objects of Interest. their Characteristics. their Associations.

6. Ian PerrySlide 644220: Database Design & Implementation: Conceptual Data Modelling Entities/Attributes/Relationships Entities - Objects of Interest (Nouns): Customer, Supplier, Order, Employee, Stock, etc. Attributes - Characteristics (Adjectives): Customer - Name, Address, etc. Stock - Description, Price, Quantity, etc. Relationships - Associations (Verbs): Customer ‘places’ Order. Supplier ‘supplies’ Stock.

7. Ian PerrySlide 744220: Database Design & Implementation: Conceptual Data Modelling Entities = Objects of Interest Must play a necessary role in the business system: so, we must make decisions about what to include and what to exclude. Each Entity MUST have name that is: a noun; is singular; is succinct; and is meaningful. Each Entity MUST be described by; one-or-more Attributes.

8. Ian PerrySlide 844220: Database Design & Implementation: Conceptual Data Modelling Attributes = Characteristics Attributes describe an Entity. Must have Meaningful Names: NOT; Field 1, Field 2, etc. Should be Atomic: NOT; Address, Invoice, etc. For example: House No., Street, Town, County, Post Code, etc. Invoice No., Customer ID, Invoice Date, etc.

9. Ian PerrySlide 944220: Database Design & Implementation: Conceptual Data Modelling Entities & Attributes Each Entity requires an Attribute Identifier, which can be defined as: the minimum number of Attributes that, when given value(s), uniquely identify one Entity Occurrence from another. these are often called ‘key’ Attributes. Consequently: it is mandatory that values exist for all of these ‘key’ Attributes.

10. Ian PerrySlide 1044220: Database Design & Implementation: Conceptual Data Modelling Entities & Attributes (Example 1) Entity Attributes Key Attribute Invoice 1000214 Jan 20057 Jan 20052005_0003 100344 Jan 20052005_0002 1000211 Jan 20054 Jan 20052005_0001 CustomerIDPaymentDateInvoiceDateInvoiceNo

11. Ian PerrySlide 1144220: Database Design & Implementation: Conceptual Data Modelling Entities & Attributes (Example 2) Entity Attributes Key Attributes ModuleNameLevelCourseCodeStaffNo Database Design1ITB234 Marketing1ITB346 Marketing2ITB Research Methods IS PlanningM254 Module 2

12. Ian PerrySlide 1244220: Database Design & Implementation: Conceptual Data Modelling Relationships = Associations A Relationship MAY OCCCUR; between any TWO Entities. Each Relationship REPRESENTS; the possible existence of an Association between TWO Entities. Every Relationship SHOULD be described : by Degree (a quantitative association) by Type (a qualitative association)

13. Ian PerrySlide 1344220: Database Design & Implementation: Conceptual Data Modelling Quantitative = Degree Identifies the number of Entity Occurrences that might be on each side of a Relationship. May be simple: one_to_one (1:1), e.g. Wife - Husband one_to_many (1:M), e.g. Lecturer - Student May be complex: many_to_many (M:M), e.g. Product – Customer MOST ‘real-world’ Relationships are M:M, however: Logical & Physical Data Models CAN NOT handle such complex Relationships.

14. Ian PerrySlide 1444220: Database Design & Implementation: Conceptual Data Modelling Qualitative = Type MUST be a succinct & meaningful verb (or verb-phrase), e.g.: Wife is married to Husband MOST Relationships are bi-directional, e.g.: Lecturer bores Student Student bored by Lecturer Product bought by Customer Customer buys Product

15. Ian PerrySlide 1544220: Database Design & Implementation: Conceptual Data Modelling Example Relationships (by Degree & Type) HusbandWife is married to One-to-One 11 LecturerStudent bores => One-to-Many 1M <= bored by ProductCustomer bought by => Many-to-Many MM <= buys

16. Ian PerrySlide 1644220: Database Design & Implementation: Conceptual Data Modelling Decomposing Complexity Try to simplify any complex ‘real-world’ M:M Relationships that you discover into 2 x 1:M Relationships: This results in the creation of an new ‘artificial’ linking Entity composed of the identifiers (i.e. the ‘key’ Attributes) from either side of the original Many-to-Many relationship. ALWAYS attempt to simplify any complex (i.e. M:M) Relationships at the Conceptual Data Modelling stage: you will have to ‘solve’ these ‘problems’ when you move on to the Logical Data Model.

17. Ian PerrySlide 1744220: Database Design & Implementation: Conceptual Data Modelling An Example of Decomposition CustomerKeyProductKey CustomerKey ProductKey ProductCustomer bought by => 1 x Many-to-Many MM <= buys ProductCustomer 2 x One-to-Many Prod/Cust 1M1M <= buysbought by => NB.The Relationship is still between the two ‘real-world’ Entities; the ‘artificial’ Entity is just there to solve a problem.

18. Ian PerrySlide 1844220: Database Design & Implementation: Conceptual Data Modelling Conceptual Data Modelling Process Identify ALL of the relevant Entities: must play a necessary role in the business system. Identify those Attributes that adequately describe each Entity: remember to choose ‘key’ attribute(s). Identify the Relationships between Entities: determine the Degree of each Relationship. determine the Type of each Relationship. attempt to decompose any many-to-many Relationships that you have identified.

19. Ian PerrySlide 1944220: Database Design & Implementation: Conceptual Data Modelling This Week’s Workshop In this Workshop we will continue to explore some of the design decisions you must make in order to begin to construct a Conceptual Data Model of the ‘real world’. Working alone, or in a small team, consider the following ‘things’ that exist in the ‘real’ world. University, Bank, Sports Activity. For each of the above; list the Entities, list likely Attributes that ‘describe’ each Entity, and identify ‘Key’ Attributes. DON’T arrive at the workshop un-prepared!