1 Agenda TMA02 M876 Block 4. 2 Model of database development data requirements conceptual data model logical schema schema and database establishing requirements.

Slides:



Advertisements
Similar presentations
Copyright © 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 5 More SQL: Complex Queries, Triggers, Views, and Schema Modification.
Advertisements

MSc IT UFCE8K-15-M Data Management Prakash Chatterjee Room 2Q18
Database Processing: Fundamentals, Design, and Implementation, 9/e by David M. KroenkeChapter 5/1 Copyright © 2004 Please……. No Food Or Drink in the class.
Chapter 3 The Relational Model Transparencies © Pearson Education Limited 1995, 2005.
Fundamentals, Design, and Implementation, 9/e COS 346 Day 8.
Chapter Physical Database Design Methodology Software & Hardware Mapping Logical Design to DBMS Physical Implementation Security Implementation Monitoring.
Fundamentals, Design, and Implementation, 9/e Chapter 5 Database Design.
IS 4420 Database Fundamentals Chapter 6: Physical Database Design and Performance Leon Chen.
Chapter 3. 2 Chapter 3 - Objectives Terminology of relational model. Terminology of relational model. How tables are used to represent data. How tables.
Physical Database Monitoring and Tuning the Operational System.
1 Relational Model. 2 Relational Database: Definitions  Relational database: a set of relations  Relation: made up of 2 parts: – Instance : a table,
Database Systems More SQL Database Design -- More SQL1.
Chapter 4 Relational Databases Copyright © 2012 Pearson Education, Inc. publishing as Prentice Hall 4-1.
A Guide to SQL, Seventh Edition. Objectives Understand, create, and drop views Recognize the benefits of using views Grant and revoke user’s database.
Chapter 4 Relational Databases Copyright © 2012 Pearson Education 4-1.
File and Database Design; Logic Modeling Class 24.
Transforming Data Models into Database Designs
Michael F. Price College of Business Chapter 6: Logical database design and the relational model.
Chapter 14 & 15 Conceptual & Logical Database Design Methodology
Logical Database Design Nazife Dimililer. II - Logical Database Design Two stages –Building and validating local logical model –Building and validating.
The Relational Database Model
Lecture 2 The Relational Model. Objectives Terminology of relational model. How tables are used to represent data. Connection between mathematical relations.
Chapter 4 The Relational Model Pearson Education © 2014.
Chapter 4 The Relational Model.
Chapters 17 & 18 Physical Database Design Methodology.
DAY 15: ACCESS CHAPTER 2 Larry Reaves October 7,
CSE314 Database Systems More SQL: Complex Queries, Triggers, Views, and Schema Modification Doç. Dr. Mehmet Göktürk src: Elmasri & Navanthe 6E Pearson.
Database Technical Session By: Prof. Adarsh Patel.
Concepts and Terminology Introduction to Database.
TM 7-1 Copyright © 1999 Addison Wesley Longman, Inc. Physical Database Design.
Physical Database Design Chapter 6. Physical Design and implementation 1.Translate global logical data model for target DBMS  1.1Design base relations.
Lecture 7 Integrity & Veracity UFCE8K-15-M: Data Management.
SQL Server 7.0 Maintaining Referential Integrity.
Chapter 6 1 © Prentice Hall, 2002 The Physical Design Stage of SDLC (figures 2.4, 2.5 revisited) Project Identification and Selection Project Initiation.
1 The Relational Database Model. 2 Learning Objectives Terminology of relational model. How tables are used to represent data. Connection between mathematical.
CSCI 3140 Module 3 – Logical Database Design for the Relational Model Theodore Chiasson Dalhousie University.
Lecture2: Database Environment Prepared by L. Nouf Almujally & Aisha AlArfaj 1 Ref. Chapter2 College of Computer and Information Sciences - Information.
© Pearson Education Limited, Chapter 15 Physical Database Design – Step 7 (Consider Introduction of Controlled Redundancy) Transparencies.
Chapter 6 Database Administration
FALL 2004CENG 351 File Structures and Data Management1 Relational Model Chapter 3.
14-1 Goals of Database Design A database should provide for efficient storage, update, and retrieval of data. A database should be reliable—the stored.
Lecture2: Database Environment Prepared by L. Nouf Almujally 1 Ref. Chapter2 Lecture2.
10/10/2012ISC239 Isabelle Bichindaritz1 Physical Database Design.
Views Lesson 7.
Database Systems Design, Implementation, and Management Coronel | Morris 11e ©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or.
Methodology – Monitoring and Tuning the Operational System.
GLOBEX INFOTEK Copyright © 2013 Dr. Emelda Ntinglet-DavisSYSTEMS ANALYSIS AND DESIGN METHODSINTRODUCTORY SESSION EFFECTIVE DATABASE DESIGN for BEGINNERS.
Physical Database Design Purpose- translate the logical description of data into the technical specifications for storing and retrieving data Goal - create.
The relational model A data model (in general) : Integrated collection of concepts for describing data (data requirements). Relational model was introduced.
Constraints Lesson 8. Skills Matrix Constraints Domain Integrity: A domain refers to a column in a table. Domain integrity includes data types, rules,
The Relational Model. 2 Relational Model Terminology u A relation is a table with columns and rows. –Only applies to logical structure of the database,
Session 1 Module 1: Introduction to Data Integrity
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall Chapter 9 Designing Databases 9.1.
1 CS 430 Database Theory Winter 2005 Lecture 7: Designing a Database Logical Level.
Database Systems, 8 th Edition SQL Performance Tuning Evaluated from client perspective –Most current relational DBMSs perform automatic query optimization.
Chapter 4 The Relational Model Pearson Education © 2009.
Database Planning Database Design Normalization.
Data Integrity & Indexes / Session 1/ 1 of 37 Session 1 Module 1: Introduction to Data Integrity Module 2: Introduction to Indexes.
More SQL: Complex Queries, Triggers, Views, and Schema Modification
Logical Database Design and the Rational Model
Chapter 5 Database Design
Chapter 6 - Database Implementation and Use
Methodology – Monitoring and Tuning the Operational System
Physical Database Design for Relational Databases Step 3 – Step 8
Module 5: Implementing Data Integrity by Using Constraints
COS 346 Day 8.
CHAPTER 5: PHYSICAL DATABASE DESIGN AND PERFORMANCE
Physical Database Design
Methodology – Monitoring and Tuning the Operational System
Relational Database Design
Presentation transcript:

1 Agenda TMA02 M876 Block 4

2 Model of database development data requirements conceptual data model logical schema schema and database establishing requirements data analysis database design implementation

3 Steps for Database Design Use a relational conceptual data model to give a set of tables for an initial database design Do the tables represent the data in an acceptable way, according to the given criteria for usability, efficiency and so on? Define constituents of each table columns primary key foreign keys constraints Revise tables Implementation Yes No

4 Defining Columns Choose the most appropriate data type for a column. Before choosing the data type, we have to know:- Characteristics of the expected values for the column. Operations for the column. Data TypeCharacteristicsOperations NumericRange, Precision +, -, *, / CharacterLength|| Datetime-

5 NOT NULL Constraints NOT NULL constraints apply to Primary key Foreign key (mandatory participation condition) A row of table which may become meaningless if a column is NULL Two extreme forms of policy Every column is defined as NOT NULL  Every row is meaningful and usable Allow NULL to occur  Flexibility of entering incomplete rows of data

6 Default Values Any NOT NULL column for which there will be missing values must have a default value. Two kinds of default value:- Real value Non-real value  In formulating a query, you should consider whether the value should be including in the processing or not.

7 Codes Store alternative values instead of the actual values (e.g. S - Single, M – Married, D - Divorced) Advantage Less storage space Disadvantage Not immediately understandable Solution: create an additional code table and join this table to the other tables so that only the decodes are visible to users.

8 Domains SQL Domain  Relational Domain Comparison of two SQL columns requires only that they are of comparable data types, NOT that they are the same domain SQL domain provides a common definition, including both constraints and default values, that can be shared by a number of columns. For example, if we define a SQL domain GPA which is Numeric(3, 2), all columns of this domain will be rounded to 2 decimal places automatically when calculating GPA.

9 Defining Tables Transformation of relations to SQL tables Three issues shall be considered:- Defining the primary key Defining the foreign key Defining constraints

10 Defining Primary Keys Primary keys should be chosen according to the criteria of uniqueness, minimality and not being null. Minimality is important since long primary key will consume storage space and slow the processing associated with primary key, such as joining tables. Sometimes, primary key is replaced by surrogate (unique values generated by a DBMS) to achieve minimality.

11 Defining Foreign Keys When defining a foreign key, it is important to consider whether any referential action should be associated when a referenced row is to be deleted. There are three possible referential actions:- RESTRICT SET NULL SET DEFAULT CASCADE Participation condition at the 'many' end of the relationship represented by the foreign key determines the choice of referential action. Participation ConditionReferential Actions MandatoryRESTICT or CASCADE OptionalRESTICT or SET DEFAULT or SET NULL

12 Defining Constraints Kinds of constraints:- Primary key, expressed as PRIMARY KEY Alternate key, expressed as UNIQUE Referential constraint, expressed as FOREIGN KEY Mandatory participation condition, expressed as NOT NULL for one end and CHECK clause for the other end NOT all constraints in a conceptual data model have to be defined in a database schema. Two reasons for this: processing inconsistency and processing inefficiency.

13 Revising Tables Avoiding NULL to enhance usability. Denormalization Normalization, which divide a table into tables, is to avoid duplication of data and thus prevent anomalies. Reverse process which combines tables to provide more efficient retrieval.

14 Addition Data Derived data Additional column  Efficient  Need to maintain consistency of the derived data – use Trigger Create view  Inefficient Extra tables Snapshot  Auditing and archiving Summary table

15 Usage Define views and privileges Reason for defining a view as the means to access data in a database rather than using the base tables: Usability, because specific data required by users can be defined as a view, providing a simplified way to access the data; Flexibility, because a view enables changes to be made to base tables without affecting the users’ view of data, providing data independence; Access control, because defining users’ privileges for views, rather than base tables, allows more precise control on the data made available to users.