FIT1004 Database Topic 5: Logical Design - Pravin … · FIT1004 Database Topic 5: Logical Design...
Transcript of FIT1004 Database Topic 5: Logical Design - Pravin … · FIT1004 Database Topic 5: Logical Design...
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).
2
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
3
The Database Life Cycle (Revision)
4
Procedure Flow in the Database Design
Topic 4(Last Week)
Topic 5(This Week)
5
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/
6
DBMS Software Market Share
http://www.gartner.com/press_releases/asset_152619_11.html
7
DBMS Software Selection
• 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
8
DBMS Software Selection
• 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
9
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
10
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/
11
Data Dictionary
12
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
13
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
14
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
15
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
16
Transform ERD into Relations:Step 2: Map Weak Entities
• Mapping a weak entity DEPENDENT
Graphics from Hoffer, J.A., et al; Modern Database Management, 7th Ed., Chapter 5
17
Transform ERD into Relations:Step 3: Map Binary Relationships
• Mapping binary One-to-Many Relationships
Graphics from Hoffer, J.A., et al; Modern Database Management, 7th Ed., Chapter 5
18
Transform ERD into Relations:Step 3: Map Binary Relationships (con’t)
• Mapping binary One-to-One Relationships
Graphics from Hoffer, J.A., et al; Modern Database Management, 7th Ed., Chapter 5
19
Transform ERD into Relations:Step 4: Map Associative Entities
• Identifier not assigned
Graphics from Hoffer, J.A., et al; Modern Database Management, 7th Ed., Chapter 5
20
Transform ERD into Relations:Step 4: Map Associative Entities (con’t)
• Identifier assigned – SHIPMENT has a PK is this an associative?
Graphics from Hoffer, J.A., et al; Modern Database Management, 7th Ed., Chapter 5
21
Transform ERD into Relations:Step 5: Map Unary Relationships
• Unary One-to-Many Relationships
Graphics from Hoffer, J.A., et al; Modern Database Management, 7th Ed., Chapter 5
22
Transform ERD into Relations:Step 5: Map Unary Relationships (con’t)
• Unary Many-to-Many Relationships
Graphics from Hoffer, J.A., et al; Modern Database Management, 7th Ed., Chapter 5
Note: Contains (or COMPONENT) is an associative entity here
23
Ternary Relationships – model as binary relationships?
24
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)
25
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
26
Transform ERD into Relations:Step 6: Map Ternary (& n-ary) Relationships
• PATIENT TREATMENT ternary relationship with associative entity
Graphics from Hoffer, J.A., et al; Modern Database Management, 7th Ed., Chapter 5
27
Transform ERD into Relations:Step 7: Map Supertype/Subtype Relationships
Graphics from Hoffer, J.A., et al; Modern Database Management, 7th Ed., Chapter 5
28
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
29
• 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)
30
• 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
31
• 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
32
Attempt ☺Transforming Fly-By-Night Travel Conceptual ER into Logical ER Diagram (Last weeks case study)
33
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)
34
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
35
STUDENT-SUBJECT ERD
d:Cu:C
d:Cu:C
(Note d:C being used to demonstrate a point, how wise would it really be?)
36
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
d:Cu:C
37
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
d:Cu:C
38
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