Presentation is loading. Please wait.

Presentation is loading. Please wait.

Lecture 7 Conceptual Database Design SFDV2002 - Principles of Information Systems.

Similar presentations


Presentation on theme: "Lecture 7 Conceptual Database Design SFDV2002 - Principles of Information Systems."— Presentation transcript:

1 Lecture 7 Conceptual Database Design SFDV2002 - Principles of Information Systems

2 2 Overview  Database Design  CASE support  Diagramming techniques  ERDs (Traditional or Data Centred Approach)  Class diagrams  Form Analysis

3 3 Databases Member IDTitleSurnameFirst Name 13Mr.BurnsMontgomery 14Mr.SimpsonHomer 15Mr.FlandersNed 16Mr.DrinkwellMoe Hire NumberMember IDVideo CodeDate of LoanDue Date 1421310-0000-005-Jul-0410-Jul-04 1431310-0000-305-Jul-0410-Jul-04 1441420-0000-105-Jul-0410-Jul-04 Video CodeTitle 10-0000-0Star Wars: Episode IV 10-0000-2Star Wars: Episode V 10-0000-3Star Wars: Episode VI It is also known as Persistent data. DBMS-interact with database, Databases used for: Store large quantities of information Retrieve information quickly Organise and reorganise information Print and distribute information in a variety of ways Key elements Tables Row (records) Columns (fields) Relationships

4 4 Levels of Information Design High Low Employ ee Salary EmployeeProjectRole Proje ct Budget 1: Specification 2: Implementation CREATE TABLE department ( dept_code CHAR(4), name VARCHAR2(30) NOT NULL, PRIMARY KEY (dept_code), UNIQUE (name) ); CREATE TABLE employee ( emp_id NUMBER(7), firstnames VARCHAR2(50) NOT NULL, surname VARCHAR2(50) NOT NULL, phone VARCHAR2(15), sex CHAR(1) DEFAULT 'F', dept_code CHAR(4) NOT NULL, PRIMARY KEY (emp_id), FOREIGN KEY (dept_code) REFERENCES department ); CREATE TABLE department ( dept_code CHAR(4), name VARCHAR2(30) NOT NULL, PRIMARY KEY (dept_code), UNIQUE (name) ); Abstraction spectrum ConceptualLogicalPhysical Business System Technology

5 5 Entity Relationship Diagrams  “To provide an accurate model of the information needs of the organisation, which will act as a framework for development of new enhanced systems.” 1. Entities – Usually nouns, Often described with the singular  “An entity is a thing or object of significance, whether real or imagined, about which information needs to be known or held.” 2. Relationships – Links or associations  Represent real-world associations between entities 3. Attributes – atomic, described with singular  Describe a characteristic of an entity  Identify a unique instance of an entity [Barker, 1990]

6 6 How is Data Modeling supported by CASE? Upper-CASE: Focus on activities associated with the early stages of systems development, i.e., analysis and design (e.g. conceptual modeling). Lower-CASE: Focus on the later stages of systems development and are capable of automatically generating structured program code, i.e., implementation. Code, user interface, realization of models (e.g. databases). Reverse engineer existing systems for functional and data requirements. Integrated-CASE (I-CASE): Provide links between upper- and lower-CASE packages. i.e. comprises both. Based around central repository. Share designs with other developers. Quality control over designs.

7 7 Entities CategoryExamples Tangible thingsairplane, books, vehicle, document, worksheet Roles playedemployee, customer, doctor, patient, end user Organisational unit division, department, task force Incidents, events or interactionsflight, service call, purchases, order, payment [Adapted from: Satzinger et al., 2002] Diagrammatic representation: rectangle

8 8 Identifying entities Entities are things that people talk about, write about, record information about and do work on. Often the nouns in sentences Can often be actors (roles people play) – that you need to store information about Categories: Tangible things: e.g., airplane, books, vehicle, document, worksheet Often the most obvious – easily identified (compared to intangible) Roles played: e.g., employee, customer, doctor, patient, end user Other is the roles people play – you record different information based on the roles they play. Need to be important to the organisation. Organisational unit: e.g., division, department, task force Devices: e.g., sensor, printer, display, hard disk Incidents, events or interactions: e.g., flight, service call, purchases, order, payment Something these are though of as relationship between things – but if you are storing something about them – then they are entities. Sites or locations: e.g., warehouse, factory, retail store

9 9 Is ‘it’ really an Entity? 1. Is it a unique thing the system needs to know about? 2. Is it inside the scope of the system you are working on? 3. Does the system need to remember more than one of these items? 4. Is it a synonym for some other thing you have identified? 5. Is it an output of the system produced from other information you have identified? 6. Is it an input that results when recording some other information you have identified? 7. Is it likely to be a specific piece of information about some other thing you have identified? 8. Is it something that you might need if assumptions change? [Satzinger, 2007]

10 10 Customer Customer # Firstname Surname Street address Suburb Phone … Entity Type versus Entity Instance Instance 1 1001 Sarah Ulmer 10 Pitt Street Central 4776534 Instance 2 1002 Valerie Villi 1 Forbes Street St. Clair Entity type Definition of the thing or object. General representation of the object or thing Template Include type of information (attributes) that describe the entity Entity instance A particular example (occurrence) of an entity type. Values assigned to each attribute of the entity. Each instance (occurrence) of an entity must be separate and distinct.

11 11 Attributes  Optionality  Options: optional or mandatory  Role  Descriptive  Identifying (Unique Identifiers)  “Each entity must be uniquely identifiable so that each instance of the entity is separate and distinctly identifiable from all other instance of that type of entity.” [Barker, 1990] A piece of information that describes an entity” (Date 2004) An attribute is any detail that serves to qualify, identify, classify, quantify or express the state of an entity (Baker 1990) One piece of specific information about a thing (atomic). Attributes could be text, numbers, a picture, sound, etc.

12 12  Cardinality:  Options: 1:1, 1:M, M:M  Optionality (participation)  Options: optional or mandatory  Labels  Degree, typically binary purchases involves Relationships

13 13 Relationship Example I An author must write one (at least one) or more books. A book must be written by one and only one author. AuthorBook write written by AuthorBook write written by

14 14 Relationship Example II An author may write one or more books. AuthorBook write written by A book must be written by one and only one author. AuthorBook write written by

15  Many – Many (M-M) CourseStudent Study by Study A course study by many student A Student study many Course

16  One – Many (1-M) CustomerOrder Place Placed by A Customer Place many Order An Order Placed by only one Customer

17  One – One (1-1) CitizenSSID Has Issued for A Citizen Has only one SSID A SSID Issued for only one Citizen

18 18 Video Store Database Example ERD Notations There are many different notations We are using variation of the Information Engineering (IE) notation in this course

19 19 Categories of Entity  Strong  Exist independently of other entities  e.g., Customer, CD, …  Weak  Existence dependent on another entity  e.g., Sale, Sale_line  Associative  Describes a particular association  Requires at least one descriptive attribute

20 20 Associative Entities M:M relationships Create associative entity – Two M:1 relationships Student number name Student number Course ID date started Course ID title Student number name Course ID title

21 21 Associative Entities – PowerDesigner

22 22 Form Analysis CUSTOMER VEHICLE RENTAL VEHICLE TYPE

23 23 Resulting Conceptual Design

24 24 Suggested Steps for ERD creation 1. Identify Entities 2. Identify Relationships 3. Document Attributes

25 25 UML: Class Diagram Inheritance Multiplicities Behaviour Attributes Object class Composition Association Superclass Subclasses Classes are equivalent to entity types

26 26 References  Barker, CASE*METHOD Entity Relationship Modelling, Addison Wesley, 1990  Satzinger, et al., Systems Analysis and Design in a changing world, Thomson, 2007  Date, An Introduction to Database Systems, 8 th Edition, Addison Wesley, 2004  ----------------------------------------------------  NOTE: Start Tutorial 3 + Practical 3


Download ppt "Lecture 7 Conceptual Database Design SFDV2002 - Principles of Information Systems."

Similar presentations


Ads by Google