Top Banner
Lecture 7 Conceptual Database Design SFDV2002 - Principles of Information Systems
26

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

Dec 29, 2015

Download

Documents

Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Lecture 7 Conceptual Database Design SFDV2002 - Principles of Information Systems.

Lecture 7Conceptual Database

Design

SFDV2002 - Principles of Information Systems

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

2

Overview

Database DesignCASE supportDiagramming techniques

ERDs (Traditional or Data Centred Approach) Class diagrams

Form Analysis

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

3

Databases

Member ID Title

Surname

First Name

13 Mr. BurnsMontgomer

y

14 Mr. Simpson Homer

15 Mr. Flanders Ned

16 Mr. Drinkwell Moe

Hire NumberMember

ID Video CodeDate of

Loan Due Date

142 13 10-0000-0 05-Jul-04 10-Jul-04

143 13 10-0000-3 05-Jul-04 10-Jul-04

144 14 20-0000-1 05-Jul-04 10-Jul-04

Video Code Title

10-0000-0 Star Wars: Episode IV

10-0000-2 Star Wars: Episode V

10-0000-3 Star Wars: Episode VI

It is also known as Persistent data. DBMS-interact with database, Databases used for:

Store large quantities of informationRetrieve information quicklyOrganise and reorganise informationPrint and distribute information in a variety of ways

Key elements TablesRow (records)Columns (fields)Relationships

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

4

Levels of Information DesignHigh

Low

Employee

SalaryEmployee Project Role

Project

Budget

1: Specification

2: ImplementationCREATE 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));

Ab

stra

ctio

n s

pect

rum

Conceptual

Logical

Physical

Business

System

Technology

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

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]

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

6

How is Data Modeling supported by CASE?

Diagramgenerator

Designgenerator

Codegenerator

Databasegenerator

Prototypingtool

Query tool andreport generator

Security andversion control

Error- checkingtool

Reverse-engineering tool

Drawingtool

Repository

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.

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

7

Entities

Category Examples

Tangible things airplane, books, vehicle, document, worksheet

Roles played employee, customer, doctor, patient, end user

Organisational unit division, department, task force

Incidents, events or interactions

flight, service call, purchases, order, payment

[Adapted from: Satzinger et al., 2002]

Diagrammatic representation: rectangle

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

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

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

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]

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

10

CustomerCustomer #

Firstname

Surname

Street address

Suburb

Phone

Entity Type versus Entity InstanceInstance 1

1001

Sarah

Ulmer

10 Pitt Street

Central4776534

Instance 2

1002

Valerie

Villi

1 Forbes Street

St. ClairEntity type•Definition of the thing or object.•General representation of the object or thing•Template •Include type of information (attributes) that describe the entityEntity 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.

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

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.

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

12

Cardinality: Options: 1:1, 1:M, M:M

Optionality (participation) Options: optional or mandatory

Labels Degree, typically binary

purchases

involves

Relationships

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

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.

Author Bookwrite

written by

Author Bookwrite

written by

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

14

Relationship Example II

An author may write one or more books.

Author Bookwrite

written by

A book must be written by one and only one author.

Author Bookwrite

written by

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

Many – Many (M-M) Many – Many (M-M)

Course StudentStudy by

Study

A course study by many student

A Student study many Course

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

One – Many (1-M) One – Many (1-M)

Customer OrderPlace

Placed by

A Customer Place many Order

An Order Placed by only one Customer

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

One – One (1-1) One – One (1-1)

Citizen SSIDHas

Issued for

A Citizen Has only one SSID

A SSID Issued for only one Citizen

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

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

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

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

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

20

Associative EntitiesM:M relationships

Create associative entity – Two M:1 relationships

Student numbername

Student numberCourse IDdate started

Course IDtitle

Student numbername

Course IDtitle

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

21

Associative Entities – PowerDesigner

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

22

Form Analysis

CUSTOMER

VEHICLE RENTALVEHICLE

TYPE

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

23

Resulting Conceptual Design

rented by

rent

assigned to

assigned

of

classification for

Customer

Cust IDSurnameFirst NameAddressCityPhone 1Phone 2

<pi> <M><M><M><M><M><M>

Vehicle

Reg Num <pi> <M>

Vehicle Type

Vech Type IDDescription

<pi> <M><M>

Rental

Rental IDRent DateDue DateReminded

<pi> <M><M><M>

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

24

Video

Hire

Member

rented

is rented by

is rented by

make

Video

Hire

Member

Suggested Steps for ERD creation

1. Identify Entities

2. Identify Relationships

3. Document Attributes

rented

is rented by

is rented by

make

Video

Video CodeDeparture Location

<pi> <M><M>

HireHire NumDeparture LocationStreet AddressSuburbCity

<pi> <M><M>

<M><M>

MemberMember IDDeparture LocationSurnameFirst NameStreet AddressSuburbCityGenderDOBPhoneEmail

<pi> <M>

<M><M><M>

<M><M><M>

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

25

UML: Class Diagram

Inheritance

Multiplicities

Behaviour

Attributes

Object class

Composition

Association

Superclass

Subclasses

Classes are equivalent to entity types

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

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, 8th Edition, Addison Wesley, 2004

---------------------------------------------------- NOTE: Start Tutorial 3 + Practical 3