44220: Database Design & Implementation Conceptual Data Modelling Ian Perry Room: C49 Tel Ext.:

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

Ian PerrySlide : 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.

Ian PerrySlide : 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!

Ian PerrySlide : 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.

Ian PerrySlide : 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.

Ian PerrySlide : 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.

Ian PerrySlide : 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.

Ian PerrySlide : 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.

Ian PerrySlide : Database Design & Implementation: Conceptual Data Modelling Entities & Attributes (Example 1) Entity Attributes Key Attribute Invoice Jan Jan _ Jan _ Jan Jan _0001 CustomerIDPaymentDateInvoiceDateInvoiceNo

Ian PerrySlide : 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

Ian PerrySlide : 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)

Ian PerrySlide : 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.

Ian PerrySlide : 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

Ian PerrySlide : 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

Ian PerrySlide : 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.

Ian PerrySlide : 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.

Ian PerrySlide : 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.

Ian PerrySlide : 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!