Database management systems 3 - Data Modelling


Published on

Published in: Technology, Health & Medicine

Database management systems 3 - Data Modelling

  1. 1. Database Management Systems Data Modelling By Nickkisha Farrell, BSc IT, Dip Ed February 2014
  2. 2. IN THIS PRESENTATION What is data modelling? Types of data Models Creating a Data Model Entities, Attributes, Relationships and Cardinality How to draw Entity Relationship Diagrams ERD: Problem and Solution 2
  3. 3. INTRODUCTION • In order ultimately to design databases to support an organization, one should have: • a clear understanding of how the organization is structured • how it functions • understand its components, what they do and how they relate to each other. • There must be a way of recording (diagramming) the business • This is the principle of DATA MODELING. 3
  4. 4. DATA MODELLING • Process used to define and analyze data requirements needed to support the business processes, so that anomalies and inconsistencies may be eliminated during the physical database design. • Therefore, the process of data modeling involves professional data modelers working closely with business stakeholders, as well as potential users of the information system. 4
  5. 5. DATA MODELLING The analysis of data objects and their relationships to other data objects. • Types of data models: 1. Conceptual: describes WHAT the system contains 2. Logical: describes HOW the system will be implemented, regardless of the DBMS 3. Physical: describes HOW the system will be implemented using a specific DBMS 5
  6. 6. TYPES OF DATA MODELS • Entity-Relationship (E-R) Models • The most common method for database modelling • Only addresses data and relationships • Classic, simplest • Best for deriving a sound table design • Basis for most other modeling approaches • UML (unified modeling language) • Class models • Goes beyond data, also models behaviors 6
  7. 7. ENTITY RELATIONSHIP DIAGRAMS • a graphical representation of the logical structure of a database • identifies the concepts or entities that exist in a system and the relationships between those entities • help the database analyst/designer gains a better understanding of the information to be contained in the database. • facilitate documentation of the database design lifecycle. • used to communicate the logical structure of the database to users . 7
  8. 8. ENTITY • Entity • Generalized category representing person, place, thing on which we store and maintain information • Entity Names become Table Names • E.g. Department, Employee 8
  9. 9. Types of Attributes ATTRIBUTE Primary key Atomic Composite Multi-valued Derived •Attributes: •Specific characteristics of each entity, e.g.: •DEPARTMENT name, address •EMPLOYEE id, name, contact number 9
  10. 10. PRIMARY KEY ATTRIBUTES • Attribute whose value is unique for every entity instance • Every entity MUST have a PK • Designate by: • • • • Placing as first attribute in the entity Underline Label using "PK“ UniversityStudent PK StudentID StudentName StudentDOB StudentAge Must be values that are: • Unique for every possible record • Do not change • Best practice: numeric with no blank spaces or formatting characters
  11. 11. ATOMIC AND COMPOSITE ATTRIBUTES • Atomic attribute: represents a single data value • Eg: 17, “Melissa", 11/25/1997 • Composite attribute: can be decomposed into atomic attributes • “Melissa K. Jones" • “VC100 Murrays Vilage, Kingstown, SVG" • Should be decomposed as much as possible when storing in a database
  12. 12. COMPOSITE ATTRIBUTES • Decompose into atomic components for: • Sorting • Searching • Formatting Student Student_ID Student_Name Student_Address Student_DOB Student_Class Student_First_Name Student_MI Student_Last_Name Student_Address_Line_1 Student_Address_Line_2 Student_City Student_State Student_Country Student_Postal_Code
  13. 13. MULTI-VALUED ATTRIBUTES • Can have multiple values for the same entity Student Employee Student_ID (PK) Student_First_Name Student_Last_Name Student_Address Student_DOB Student_Phone1 Student_Phone2 Employee_ID (PK) Employee_First_Name Employee_Last_Name Employee_Address Employee_DOB Employee_Dependent1 Employee_Dependent2
  14. 14. HANDLING MULTI-VALUED ATTRIBUTES • If it has a definite maximum number, leave as a repeating attribute • If the upper limit is variable, make a new entity Student Employee Student_ID Student_First_Name Student_Last_Name Student_Address Student_DOB Student_Phone1 Student_Phone2 Employee_ID Employee_First_Name Employee_Last_Name Employee_Address Employee_DOB Employee_Dependent1 Employee_Dependent2 has Dependent Dependent_ID Dependent_Name
  15. 15. DERIVED ATTRIBUTES • Value that can be derived from other attributes • Student_Age = 17 (DOB = 04/26/1997, current date is 04/30/2014) • Store the underlying data values from which you can derive the attribute value … • Examples: • DOB => Age • … unless the underlying values can change! • PRODUCT_PRICE, COURSE_CREDITS
  16. 16. RELATIONSHIPS • Relationship: • A data relationship is a natural association that exists between one or more entities. • E.g. Employees belong to departments. Relationships always connect two entities 16
  17. 17. CARDINALITY • Cardinality: • Defines the number of occurrences of one entity for a single occurrence of the related entity. • E.g. a department may have one or more employees, but an employee can belong to only one department. • Ordinality : • Closely linked to cardinality. • Describes the relationship as either mandatory or optional. • Specifies the absolute minimum number of relationships. • When the minimum number is = zero, relationship is optional • When the minimum number is > than zero , relationship is mandatory 17
  18. 18. HOW TO CREATE ERDs 1. Identify Entities Identify the roles, events, locations, tangible things or concepts about which the end-users want to store data. 2. Find Relationships Find the natural associations between pairs of entities using a relationship matrix. 3. Fill in Cardinality Determine the number of occurrences of one entity for a single occurrence of the related entity. 4. Identify Attributes Determine the information details (fields) which are essential to the system under development. 5. Define Primary Keys Identify the data attribute(s) that uniquely identify one and only one occurrence of each entity. 6. Draw Key-Based ERD Eliminate Many-to-Many relationships. Draw ERD and include primary and foreign keys in each entity. Adjust the ERD from step 7 to account for entities or relationships 7. Draw fully attributed ERD discovered in step 8. 10. Check Results Does the final Entity Relationship Diagram accurately depict the system data? 18
  19. 19. ERD NOTATION • Crows Foot Notation Entity Relationship Attribute 19
  20. 20. ERD NOTATION • Chen Notation - Cardinality Entity Relationship Entity UniversityStudent PK StudentID Attributes StudentName StudentDOB StudentAge Primary key 20
  21. 21. ERD NOTATION • Bachman Notation - Cardinality Entity Relationship 21
  22. 22. DATA MODEL RELATIONSHIPS • Specify the number of instances of one entity that can be associated with instances of a related entity • There are three types of data model relationships: 1:M 1:1 M:M • One to Many • One to One • Many to Many
  23. 23. ONE TO MANY RELATIONSHIP EXAMPLE Store Store_ID Store_Name Store_Address Store_ID Store_Name Store_Address 1 Northside 3233 Wisconsin St. 2 Southside 4211 Golf Road Video_ID Video_Title Video_Format 1000 The Princess Bride DVD 1001 Sideways Bluray 1002 Just Visiting DVD 1003 Crash Bluray Rents Video Video_ID Video_Title Video_Format
  24. 24. ONE TO ONE RELATIONSHIP EXAMPLE Spouse Spouse_ID Spouse_Name Spouse_ID Spouse_Name 52 Ryan, Judy 53 Redmann, Rudy Has Customer Customer_ID Customer_Name Customer_Address Customer_ ID Customer_ Name Customer_Address 1 Ryan, Paul 5454 Hyde Court 2 Myers, Mary 112 Birch Place
  25. 25. MANY TO MANY RELATIONSHIP EXAMPLE Video Video_ID Video_Title Rents Customer Customer_ID Customer_Name Customer_Address
  26. 26. ERD MODEL EXAMPLE UniversityInstructor PK ServiceProject InstructorID PK InstructorLastName InstructorFirstName InstructorOffice Advises ProjectDescription ProjectStartDate Completes UniversityStudent PK UniversityCourse StudentID StudentLastName StudentFirstName StudentMI StudentDOB ProjectID PK EnrollsIn CourseID CourseName CourseTitle
  27. 27. NOW ITS YOUR TURN • SCENARIO • A company has several departments. Each department has a supervisor and at least one employee. Employees must be assigned to at least one, but possibly more departments. At least one employee is assigned to a project, but an employee may be on vacation and not assigned to any projects. The important data fields are the names of the departments, projects, supervisors and employees, as well as the supervisor and employee number and a unique project number. 27
  28. 28. SOLVING THE PROBLEM 1. Identify Entities • The entities in this system are Department, Employee, Supervisor and Project. One is tempted to make Company an entity, but it is a false entity because it has only one instance in this problem. True entities must have more than one instance. 2. Find Relationships We construct the following Entity Relationship Matrix: Department Employee Supervisor Project Department Employee is assigned belongs to runs uses Supervisor run by Project works on 28
  29. 29. SOLVING THE PROBLEM 3. Fill in Cardinality From the description of the problem we see that: •Each department has exactly one supervisor. •A supervisor is in charge of one and only one department. •Each department is assigned at least one employee. •Each employee works for at least one department. •Each project has at least one employee working on it. •An employee is assigned to 0 or more projects. 29
  30. 30. SOLVING THE PROBLEM 4. Identify Attributes • The only attributes indicated are: • • • • • • • Department names projects supervisors employees supervisor number employee number project number 5. Define Primary Keys • The primary keys are: • Department Name • Supervisor Number • Employee Number Project Number 6. Draw Key-Based ERD 30
  31. 31. PROBLEM SOLVED 7. Draw fully attributed ERD 31
  32. 32. SUMMARY • ER Modeling models information conceptually • Based on functional business needs • “What”, not “How” • Diagrams provide easy means of communication for both analyst and user • When creating ERD the most important steps are: • Define entities • Define attributes • Define relationships • Identify relationship cardinality (1:1, 1:M, M:M) 32
  33. 33. REFERENCES • Gillenson, Mark L.,2012, Fundamentals of Database Management Systems / Mark L. Gillenson.—2nd ed., John Wiley and sons inc • -ERD.html • 33