FIT1004 Database Topic 5: Logical Design - Pravin … · FIT1004 Database Topic 5: Logical Design...

transcript

www.infotech.monash.edu.au/FIT1004/

FIT1004 Database

Topic 5: Logical Design

Learning Objectives:• Understand the purpose of logical database design.• Understand the expected inputs and outputs of the logical database design process.• Convert a conceptual design model (ER diagram) to a logical design model (Data

Structure Diagram (DSD)).• Understand the drawing conventions of DSD.• Interpret a DSD.• Understand how business rules are reflected in DSDs.• Understand the purpose of a Data Dictionary.• Create a Data Dictionary.

References:• Rob, P. & Coronel, C., Database Systems

– 6th Edition, Chapter 6, p. 232–235, Chapter 8, p. 401–420. – 7th Edition, Chapter 6, p. 184–202, Chapter 9, p. 380–381

• Hoffer, J.A., Prescott, M.B. & McFadden, F.R., Modern Database Management, 7th Edition, Chapter 5 (Appendix A in Unit Book).

Where We Are

Introduction to Database Systems The Relational Model

Conceptual Design Logical Design Normalisation

Database Lifecycle Physical Design

SQL (DML) SQL (DDL & DCL) Implementation Transaction Management

Database Administration

Data Warehousing & Data Mining

The Database Life Cycle (Revision)

Procedure Flow in the Database Design

Topic 4(Last Week)

Topic 5(This Week)

DBMS Software Selection

• Advantages and disadvantages of candidate DBMS software 'ideally' should be carefully studied

• Key vendors– Oracle – Oracle 10G: http://www.oracle.com/database/index.html

– IBM – DB2 v9: http://www-306.ibm.com/software/data/db2/

– Microsoft – SQL Server 2005: http://www.microsoft.com/sql/default.mspx

– Teradata - http://www.teradata.com/

– Sybase - http://www.sybase.com/products/informationmanagement

– Open Source alternatives> MySQL - http://www.mysql.com/ (widely used on web – eg. Flickr,

Yahoo, Wikipedia)> PostgreSQL - http://www.postgresql.org/

DBMS Software Market Share

http://www.gartner.com/press_releases/asset_152619_11.html

• Main steps:– Define Terms of Reference

> State objectives, scope and tasks required> Describe evaluation criteria

– Shortlist two or three products> Budget, vendor support, compatibility with other software,

hardware required – Evaluate products

> Data definition– PK, FK, datatypes, domain, integrity, views, DD, data

independence> Physical definition

– File structures, reorganisation, indexing, data compression, encryption, memory and storage requirements

> Accessibility– SQL compliance, interfacing to 3GLs, multi-user, security

• Main steps (cont.):> Transaction handling

– Backup & recovery routines, checkpointing & logging facilities, granularity of concurrency, deadlock resolution strategy, parallel query processing

> Utilities– Performance measuring, tuning, load/unload facilities, user

usage monitoring, DBA support> Development

– 4GL/5GL tools, CASE tools, stored procedures, triggers and rules, web development tools

> Other– Upgradeability, vendor stability, raining and user support,

documentation, OS required, cost, replication utilities, distributed capability, portability, transaction throughput, XML support, web integration

– Recommend solution and produce a report• Commercial 'reality' company already has DBMS software with

strong commitment to vendor

Logical Database Design

• Process of transforming the conceptual ERD data model into a logical data model (represented by a schema as the final output)

• Requires that all objects in the conceptual model be mapped to specific constructs used by selected database software

• Inputs– Conceptual Model (ER Diagram) including attribute/domain

documentation– Integrity Constraints

> Entity integrity, Referential integrity, Attribute domain constraints, Enterprise constraints

– DBMS Characteristics

• Outputs– Data Dictionary– Relational schema

Data Dictionary

• Central repository which maintains data describing the tables within the database

• Data kept– Names of the tables– Names and detailed descriptions of the attributes– Domains and lengths of the attributes– Integrity constraints

• Can be created and maintained manually or using Computer-Aided Software Engineering (CASE) tools, such as:

– ERwin – Computer Associates (http://ca.com/)– Rational Rose – IBM - http://www.ibm.com/software/rational/– VISIO – Microsoft (http://office.microsoft.com/en-

us/FX010857981033.aspx) – Enterprise version required to generate schemas

– Database Design Studio - http://www.chillisource.com/

Data Dictionary

• Main uses– Easier management of the data about the database

structure since all this information is stored at a central location

– A communication tool between database designers and users

– Identifying redundancy and inconsistency in attribute names

– Tracking the changes of the database structure

Data Structure Diagram (DSD)

• Logical ERD model representation useful as midpoint between Conceptual ERD and schema:– Shows all attributes– PK's indicated in some manner Underlined, labelled as PK, …– Relationships (ERD diamonds) replaced by FK's, FK's indicated in

some manner Italics, broken underline, labelled as FK,….

vend_code lastname firstname initial areacode phone

prod_code descript vend_code

INVENTRY

VENDOR

BASIC Principles for conversion from Conceptual ERD to Logical ERD (DSD)

• 1:1 total (mandatory on both sides)– join

> one box on DSD (record type)• 1:N

– place key attribute/s of one end into many end as foreign key (FK)

> two record types• N:M

– create intersection record, based on composite entity> three record types

Transform ERD into Relations:Step 1: Map Regular Entities

• Mapping the regular entity CUSTOMER

Graphics from Hoffer, J.A., et al; Modern Database Management, 7th Ed., Chapter 5

Transform ERD into Relations:Step 2: Map Weak Entities

• Mapping a weak entity DEPENDENT

Transform ERD into Relations:Step 3: Map Binary Relationships

• Mapping binary One-to-Many Relationships

Transform ERD into Relations:Step 3: Map Binary Relationships (con’t)

• Mapping binary One-to-One Relationships

Transform ERD into Relations:Step 4: Map Associative Entities

• Identifier not assigned

Transform ERD into Relations:Step 4: Map Associative Entities (con’t)

• Identifier assigned – SHIPMENT has a PK is this an associative?

Transform ERD into Relations:Step 5: Map Unary Relationships

• Unary One-to-Many Relationships

Transform ERD into Relations:Step 5: Map Unary Relationships (con’t)

• Unary Many-to-Many Relationships

Note: Contains (or COMPONENT) is an associative entity here

Ternary Relationships – model as binary relationships?

• Ternary represents more information than three binary relationships

• For example - Supplier 1 supplies Project 2 with Part 3 -

– ternary> instance (supplier 1, project 2, part 3) exists

– binaries> instances

– (supplier1, project 2) (project 2, part 3) (supplier 1, part 3)

> BUT does not imply (supplier 1, project 2, part 3)

How then to model such Ternary relationships?

• Some tools allow such relationships to be shown as natively ternary (or n-ary)

• More general approach - model as WEAK entity

Transform ERD into Relations:Step 6: Map Ternary (& n-ary) Relationships

• PATIENT TREATMENT ternary relationship with associative entity

Transform ERD into Relations:Step 7: Map Supertype/Subtype Relationships

Conceptual ERD Logical ERD (DSD) Schema

• Consider a simple model:– a painter may paint many paintings– each painting is painted by one and only one

painter– a painting may (or may not) be exhibited in a

gallery

ptr_numptr_nameptr_phone

pntg_numpntg_titlepntg_price

gal_numgal_ownergal_phone

Stage 1: Conceptual ERD

• Yields record types:– Painter (ptr_num, ptr_name, ptr_phone)– Painting (pntg_num, pntg_title, pntg_price, ptr_num,

gal_num)– Gallery (gal_num, gal_owner, gal_phone)

• Deleting a painter (row) from the PAINTER table:– PAINTING table will contain references to PAINTER

which no longer exists: deletion anomaly– Impose a DELETE RESTRICT requirement

> DBMS will not permit removal of a PAINTER if they still have a PAINTING

Stage 2: Logical ERD (DSD)

• Adding a painter (row):– No problems caused

• Modifying the primary key in the PAINTER table:– Should we allow key updates?– PAINTING table will contain references to PAINTER which no longer exist:

update anomaly– Impose an UPDATE CASCADE requirement – DBMS will automatically

update all related FK's (pntg_num in PAINTING) to the new value• Deleting a gallery (row) from the GALLERY table:

– Deletion anomaly impose DELETE RESTRICT• Adding a gallery (row) to the GALLERY table:

– No problem caused• Modifying the primary key in the GALLERY table:

– Update anomaly impose UPDATE CASCADE

• Given these results the SQL2 type schema needs to be of the form:create table gallery (

gal_num smallint not null,gal_owner char (20) not null,gal_phone char (10) not null,

primary key (gal_num));create table painter (

ptr_num smallint not null,ptr_name char (20) not null,ptr_phone char (10) not null,

primary key (ptr_num));create table painting (

pntg_num integer not null,pntg_title char (50) not null,pntg_price decimal(8,2) not null,ptr_num smallint not null,gal_num smallint,

primary key (pntg_num),foreign key (ptr_num) references painter

on delete restricton update cascade,

foreign key (gal_num) references gallery on delete restricton update cascade);

VERY IMPORTANT

This is a generalised version of SQL, this is not Oracle syntax

Stage 3: DBMS Schema

Attempt ☺Transforming Fly-By-Night Travel Conceptual ER into Logical ER Diagram (Last weeks case study)

Delete/Update Rules

• delete/update rules important component of Logical ERD (needed for schema creation)

• How to add them:– Gershwin: use an MS-Word table to document the

rules eg. PAINTER ------ d:R u:C --< PAINTING – MS Visio: Database, Options, Document –

Relationship tab, show referential action (set in relationships properties)

Oracle Constraints• An integrity constraint is a rule that restricts the values for one

or more columns in a table

FK clause:

FK: Oracle default, which cannot be specified, is DELETE RESTRICTand UPDATE CASCADE, only options are DELETE CASCADE or SET NULL

STUDENT-SUBJECT ERD

d:Cu:C

(Note d:C being used to demonstrate a point, how wise would it really be?)

Logical Design - Mapping of DSD to SQL

• Need to discuss mapping to SQL before theoretical treatment of SQL

• Each record type (box on the logical ERD) becomes a table -> three Create Table statements required– declare integrities for PK under Oracle

create table student (stu_no char (8) not null,stu_name char (20) not null,

constraint pk_student primary key (stu_no));

create table subject (sub_code char (7) not null,sub_name char (20) not null,

constraint pk_subject primary key (sub_code));

d:Cu:C

Mapping of DSD to SQL cont’d

• declare integrities for referential integrity under Oracle

create table enrol (stu_no char (8) not null,sub_code char (7) not null,date_of_enrol date not null,

constraint pk_enrol primary key (stu_no, sub_code),constraint fk_enrol1 foreign key (stu_no)

references student (stu_no)on delete cascade,

constraint fk_enrol2 foreign key (sub_code)references subject (sub_code)on delete cascade);

d:Cu:C

Summary

• This lecture– Understand the purpose of logical database design.– Understand the expected inputs and outputs of the logical

database design process.– Convert a conceptual design model (ER diagram) to a logical

design model (Data Structure Diagram (DSD)).– Understand the drawing conventions of DSD.– Interpret a DSD.– Understand how business rules are reflected in DSDs.– Understand the purpose of a Data Dictionary.– Create a data dictionary.

• Next lecture– Normalisation

FIT1004 Database Topic 5: Logical Design - Pravin … · FIT1004 Database Topic 5: Logical Design...

Documents