Copyright 2008 McGraw-Hill Ryerson 1 TECHNOLOGY PLUG-IN T5 DESIGNING DATABASE APPLICATIONS.

Slides:



Advertisements
Similar presentations
Entity-Relationship (ER) Modeling
Advertisements

BUSINESS DRIVEN TECHNOLOGY Plug-In T4 Designing Database Applications.
Ch5: ER Diagrams - Part 1 Much of the material presented in these slides was developed by Dr. Ramon Lawrence at the University of Iowa.
The Relational Database Model
Systems Development Life Cycle
Modeling the Data: Conceptual and Logical Data Modeling
Database Design & Mapping
System Analysis - Data Modeling
Systems Development Life Cycle
Systems Analysis Requirements structuring Process Modeling Logic Modeling Data Modeling  Represents the contents and structure of the DFD’s data flows.
The Relational Database Model:
1 © Prentice Hall, 2002 Chapter 5: Logical Database Design and the Relational Model Modern Database Management 6 th Edition Jeffrey A. Hoffer, Mary B.
Chapter 3: Modeling Data in the Organization
Chapter 4 Relational Databases Copyright © 2012 Pearson Education, Inc. publishing as Prentice Hall 4-1.
Concepts of Database Management Seventh Edition
Chapter 3: Data Modeling
BUSINESS DRIVEN TECHNOLOGY
Chapter 3 © 2005 by Prentice Hall 1 Objectives Definition of terms Definition of terms Importance of data modeling Importance of data modeling Write good.
Chapter 4 Relational Databases Copyright © 2012 Pearson Education 4-1.
APPENDIX C DESIGNING DATABASES
Michael F. Price College of Business Chapter 6: Logical database design and the relational model.
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 10 Structuring.
Yong Choi School of Business CSUB
PHASE 3: SYSTEMS DESIGN Chapter 7 Data Design.
3 The Relational Model MIS 304 Winter Class Objectives That the relational database model takes a logical view of data That the relational model’s.
Computer System Analysis Chapter 10 Structuring System Requirements: Conceptual Data Modeling Dr. Sana’a Wafa Al-Sayegh 1 st quadmaster University of Palestine.
DeSiamorewww.desiamore.com/ifm1 Database Management Systems (DBMS)  B. Computer Science and BSc IT Year 1.
6-1 DATABASE FUNDAMENTALS Information is everywhere in an organization Information is stored in databases –Database – maintains information about various.
Database. Basic Definitions Database: A collection of related data. Database Management System (DBMS): A software package/ system to facilitate the creation.
MIS 385/MBA 664 Systems Implementation with DBMS/ Database Management Dave Salisbury ( )
Chapter 1 Overview of Database Concepts Oracle 10g: SQL
Chapter 5 Entity–Relationship Modeling
1 ER Modeling BUAD/American University Entity Relationship (ER) Modeling.
Concepts and Terminology Introduction to Database.
Normalization (Codd, 1972) Practical Information For Real World Database Design.
Fundamentals of Relational Database Operations
McGraw-Hill/Irwin © 2008 The McGraw-Hill Companies, All Rights Reserved Plug-In T5: Designing Database Applications Business Driven Technology.
Storing Organizational Information - Databases
1 A Guide to MySQL 2 Database Design Fundamentals.
Concepts of Database Management Sixth Edition Chapter 6 Database Design 2: Design Method.
McGraw-Hill/Irwin © 2008 The McGraw-Hill Companies, All Rights Reserved Chapter 7 Storing Organizational Information - Databases.
DataBase Management System What is DBMS Purpose of DBMS Data Abstraction Data Definition Language Data Manipulation Language Data Models Data Keys Relationships.
Lecture 4 Conceptual Data Modeling. Objectives Define terms related to entity relationship modeling, including entity, entity instance, attribute, relationship,
DeSiamorePowered by DeSiaMore1 Database Management Systems (DBMS)  B. Computer Science and BSc IT Year 1.
3 & 4 1 Chapters 3 and 4 Drawing ERDs October 16, 2006 Week 3.
Copyright 2006 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Third Edition Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Chapter.
Msigwaemhttp//:msigwaem.ueuo.com/1 Database Management Systems (DBMS)  B. Computer Science and BSc IT Year 1.
© 2005 by Prentice Hall 1 The Database Development Process Dr. Emad M. Alsukhni The Database Development Process Dr. Emad M. Alsukhni Modern Database Management.
1 © Prentice Hall, 2002 Chapter 5: Logical Database Design and the Relational Model Modern Database Management 6 th Edition Jeffrey A. Hoffer, Mary B.
Programming Logic and Design Fourth Edition, Comprehensive Chapter 16 Using Relational Databases.
Data Modeling Yong Choi School of Business CSUB. Part # 2 2 Study Objectives Understand concepts of data modeling and its purpose Learn how relationships.
Lection №4 Development of the Relational Databases.
1 DATABASE TECHNOLOGIES (Part 2) BUS Abdou Illia, Fall 2015 (September 9, 2015)
Copyright © 2013 by The McGraw-Hill Companies, Inc. All rights reserved. McGraw-Hill/Irwin APPENDIX C DESIGNING DATABASES APPENDIX C DESIGNING DATABASES.
Chapter 10 Designing Databases. Objectives:  Define key database design terms.  Explain the role of database design in the IS development process. 
Understand Relational Database Management Systems Software Development Fundamentals LESSON 6.1.
Chapter 3: Modeling Data in the Organization. Business Rules Statements that define or constrain some aspect of the business Assert business structure.
Logical Database Design and the Relational Model.
Chapter 3 The Relational Database Model. Database Systems, 10th Edition 2 * Relational model * View data logically rather than physically * Table * Structural.
Microsoft Access 2010 Chapter 11 Database Design.
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 10 Structuring.
McGraw-Hill/Irwin Copyright © 2006 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter 6 Modeling the Data: Conceptual and Logical Data Modeling.
Week 2 Lecture The Relational Database Model Samuel ConnSamuel Conn, Faculty Suggestions for using the Lecture Slides.
DATA SCIENCE MIS0855 | Spring 2016 Designing Data
Microsoft Office Access 2010 Lab 1
© 2014 by McGraw-Hill Education. This is proprietary material solely for authorized instructor use. Not authorized for sale or distribution in any manner.
© The McGraw-Hill Companies, All Rights Reserved APPENDIX C DESIGNING DATABASES APPENDIX C DESIGNING DATABASES.
DESIGNING DATABASE APPLICATIONS
CIS 207 The Relational Database Model
Presentation transcript:

Copyright 2008 McGraw-Hill Ryerson 1 TECHNOLOGY PLUG-IN T5 DESIGNING DATABASE APPLICATIONS

T5-2 LEARNING OUTCOMES 1.Describe the purpose of the relational database model in a database management system 2.List the relational database model’s basic components 3.Describe why entities and attributes are organized into tables 4.Describe how data redundancy is handled in the relational database model

T5-3 5.Explain the need for an entity- relationship Diagram in a database management system 6.Describe the Chen model symbols used in entity-relationship modeling 7.Explain the purpose of normalization 8.List the three normal forms typically used in normalization LEARNING OUTCOMES

T5-4 INTRODUCTION The chapters introduced: –Database - maintains information about various types of objects (inventory), events (transactions), people (employees), and places (warehouses) –Database management system (DBMS) - software through which users and application programs interact with a database –Relational database model - a type of database that stores its information in the form of logically-related two-dimensional tables

T5-5 ENTITIES AND DATA RELATIONSHIPS Data model - a formal way to express data relationships to a database management system (DBMS) The underlying relationships in a database environment are: –Independent of the data model –Independent of the DBMS that is being used Before designing a database for any data model, data relationships need to be defined Entity-relationship diagram (ERD) - a technique for documenting the relationships between entities in a database environment

T5-6 Entities And Their Attributes Entity - also called a table, is a person, place, thing, transaction, or event about which information is stored –A customer is an entity, as is a merchandise item Attributes, also called fields or columns, are characteristics or properties of an entity class –Example: A CUSTOMER entity can be described by a Customer Number, First Name, Last Name, Street, City, State, Zip Code, Phone Number, Credit Card No, and Credit Card Exp

T5-7 Entities And Their Attributes

T5-8 Entity Identifiers Entity identifier - ensures that each entity instance has a unique attribute value that distinguishes it from every other entity instance –An entity identifier is also referred to as a primary key –An entity identifier ensures that each entity has a unique attribute value that distinguishes it from every other entity

T5-9 Entity Identifiers Constraint - a rule to which some elements in a database must adhere –When an instance of an entity in a database is stored, the DBMS needs to ensure that the new instance has a unique identifier

T5-10 Entity Identifiers

T5-11 Attributes There are several types of attributes, including: –Simple versus composite –Single-valued versus multi-valued –Stored versus derived –Null-valued

T5-12 Simple versus Composite Composite attributes can be divided into smaller subparts, which represent more basic attributes that have their own meanings Example: Address Address can be broken down into a number of subparts, such as Street, City, State, Zip Code Street may be further broken down by Number, Street Name, and Apartment/Unit Number Attributes that are not divisible into subparts are called simple attributes

T5-13 Simple versus Composite

T5-14 Single-Valued versus Multi-Valued Single-valued means having only a single value of each attribute of an entity at any given time Example: –A CUSTOMER entity allows only one Telephone Number for each CUSTOMER –If a CUSTOMER has more than one Phone Number and wants them all included in the database the CUSTOMER entity cannot handle them

T5-15 Multi-valued means having the potential to contain more than one value for an attribute at any given time An entity in a relational database cannot have multi-valued attributes, those attributes must be handled by creating another entity to hold them Relational databases do not allow multi-valued attributes because they can cause problems: –Confuses the meaning of data in the database –Significantly slow down searching –Place unnecessary restrictions on the amount of data that can be stored Single-Valued versus Multi-Valued

T5-16 Single-Valued versus Multi-Valued

T5-17 Stored versus Derived If an attribute can be calculated using the value of another attribute, it is called a derived attribute The attribute that is used to derive the attribute is called a stored attribute Derived attributes are not stored in the file, but can be derived when needed from the stored attributes Example: A person’s age –If the database has a stored attribute such as the person’s Date of Birth, you can create a derived attribute called Age from taking the Current Date and subtracting the Date of Birth to get the age

T5-18 Null-Valued There are cases where an attribute does not have an applicable value for an attribute For these situations, the null-valued attribute is created Example: A person who does not have a mobile phone would have null stored at the value for the Mobile Phone Number attribute

T5-19 DOCUMENTING LOGICAL DATA RELATIONSHIPS The two most commonly used styles of ERD notation are: 1.Chen 2.Information Engineering The Chen model uses rectangles to represent entities –Each entity's name appears in the rectangle and is expressed in the singular, as in CUSTOMER –Attributes are expressed in ovals

T5-20 DOCUMENTING LOGICAL DATA RELATIONSHIPS

T5-21 Basic Data Relationships The relationships that are stored in a database are between instances of entities

T5-22 Once the basic entities and attributes have been defined, the next task is to identify the relationships among entities There are three basic types of relationships: 1.One-to-one 2.One-to-many 3.Many-to-many Basic Data Relationships

T5-23 One-to-One One-to-one (1:1) – a relationship between two entities in which an instance of entity A can be related to only one instance of entity B and entity B can be related to only one instance of entity A

T5-24 One-to-Many One-to-many (1:M) – a relationship between two entities, in which an instance of entity A, can be related to zero, one, or more instances of entity B and entity B can be related to only one instance of entity A

T5-25 Many-to-Many Many-to-many (M:N) – a relationship between two entities in which an instance of entity A can be related to zero, one, or more instances of entity B and entity B can be related to zero, one, or more instances of entity A

T5-26 RELATIONSHIP CONNECTIVITY AND CARDINALITY Cardinality - expresses the specific number of entity occurrences associated with one occurrence of the related entity In the Chen model, the cardinality is indicated by placing numbers beside the entities in the format of (x, y) –The first number is the minimum value and the second number is the maximum value

T5-27 Documenting Relationships – The Chen Method The Chen method uses diamonds for relationships and lines with arrows to show the type of relationship between entities

T5-28 There is no obvious way to indicate weak entities and mandatory relationships –An ORDER should not exist in the database without a CUSTOMER –ORDER is a weak entity and its relationship with a CUSTOMER is mandatory –Some database designers have added a new symbol to the Chen method for a weak entity, a double-bordered rectangle Documenting Relationships – The Chen Method

T5-29 DEALING WITH MANY-TO-MANY RELATIONSHIPS There are problems with many-to-many relationships 1.The relational data model cannot handle many-to-many relationships directly –It is limited to one-to-one and one-to-many relationships –Many-to-many relationships need to be replaced with a collection of one-to-many relationships 2.Relationships cannot have attributes –An entity must represent the relationship

T5-30 Composite Entities Composite entities - entities that exist to represent the relationship between two other entities Example: –There is a many-to-many relationship between an ITEM and an ORDER An ORDER can contain many ITEM(s) and over time, the same ITEM can appear on many ORDER(s)

T5-31 Composite Entities

T5-32 Composite Entities

T5-33 SCHEMAS Schema - a completed entity-relationship diagram representing the overall, logical plan of a database –The way in which the people responsible for maintaining the database will see the design Physical schema -the underlying physical storage, which is managed by the DBMS

T5-34 The Relational Data Model Once the ERD is completed, it can be translated from a conceptual logical schema into the formal data model required by the DBMS Most database installations are based on the relational data model The relational data model is the result of the work of one person, Edgar (E. F.) Codd

T5-35 UNDERSTANDING RELATIONS The word “table” is used synonymously with “entity” The definition specifies what will be contained in each column of the table, but does not include data When rows of data are included, an instance of a relation is created

T5-36 Columns and Column Characteristics Two or more tables within the same relational schema may have columns with the same names When the same column name appears in more than one table and tables that contain that column are used in the same data manipulation operation –The name of the column must be qualified by preceding it with the name of the table and a period Example: –CUSTOMER.Customer Number, First Name, Last Name, Phone Number

T5-37 Rows and Row Characteristics A row in a relation has the following properties: –Only one value at the intersection of a column and row - a relation does not allow multi- valued attributes –Uniqueness - there are no duplicate rows in a relation –Primary key - a field (or group of fields) that uniquely identifies a given entity in a table

T5-38 Primary Key A unique primary key makes it possible to uniquely identify every row in a table The primary key is important to define to be able to retrieve every single piece of data put into a database There are only three pieces of information to retrieve for any specific bit of data: 1.The name of the table 2.The name of the column 3.The primary key of the row

T5-39 The proper notation to use when documenting the name of the table, the column name, and primary key: –CUSTOMER(Customer Number, First Name, Last Name, Phone Number) Two qualities of all primary keys: 1.A primary key should contain some value that is highly unlikely ever to be null 2.A primary key should never change Primary Key

T5-40 REPRESENTING DATA RELATIONSHIPS The use of identifiers represent relationships between entities

T5-41 When a table contains a column that is the same as the primary key of a table, the column is called a foreign key Foreign key - a primary key of one table that appears as an attribute in another file and acts to provide a logical relationship between the two files Example: –CUSTOMER(Customer Number, First Name, Last Name, Phone Number) –ORDER(Order Number, Customer Number, Order Date) REPRESENTING DATA RELATIONSHIPS

T5-42 Foreign Keys And Primary Keys In The Same Table Foreign keys do not necessarily need to reference a primary key in a different table –They need only reference a primary key Example: –EMPLOYEE(Employee Number, First Name, Last Name, Department, Manager Number)

T5-43 Referential Integrity The relational data model enforces a constraint called referential integrity –Referential integrity - states that every non-null foreign key value must match an existing primary key value Referential integrity ensures the consistency of the cross-references among tables Referential integrity constraints are stored in the database that are enforced automatically by the DBMS

T5-44 The Data Dictionary Data dictionary - a file that stores definitions of information types, identifies the primary and foreign keys, and maintains the relationships among the tables The structure of a relational database is stored in the database's data dictionary, or catalog The data dictionary is made up of a set of relations, identical in properties to the relations used to hold data Information found in a data dictionary: –Definitions of the columns that make up each table –Integrity constraints placed on relations –Security information (which user has the right to perform which operation of which table)

T5-45 The Data Dictionary

T5-46 RELATIONSHIPS AND BUSINESS RULES The “correct” design for a specific business depends on the business rules –What is correct for one organization may not be correct for another –Not a matter of right or wrong database design, but an issue of how the business operates

T5-47 Normalization Normalization - the process of placing attributes into tables that avoid the problems associated with poor database design –Given any group of entities and attributes, there is a large number of ways to group them into relations There are at least two ways to approach normalization: 1.Work from an ERD 2.Use the theoretical concepts behind good design to create relations

T5-48 NORMAL FORMS Normal forms - the theoretical rules that the design of a relation must meet –Each normal form represents an increasingly stringent set of rules –The higher the normal form, the better the design of the relation

T5-49 NORMAL FORMS Nested normal forms

T5-50 First Normal Form (1NF) First normal form (1NF) - where each field in a table contains different information A table is in first normal form (1NF) if the data are stored in a two-dimensional table with no repeating groups Example: –ORDER(Customer Number, First Name, Last Name, Street, City, State, Zip, Phone, Order Date, Item Number, Title, Price, Has Shipped)

T5-51 Second normal form (2NF) -when the relation is in first normal form and all nonkey attributes are functionally dependent on the entire primary key Example: –ITEM (Item Number, Title, Distributor, Warehouse Phone Number) Second Normal Form (2NF)

T5-52 Third Normal Form (3NF) Third normal form (3NF) - when the relation is in second normal form and there are no transitive dependencies The relation needs to broken down into two smaller relations: –ITEM(Item Number, Distributor Number) –DISTRUBUTOR(Distributor Number, Warehouse Phone Number)

T5-53 NORMALIZED RELATIONS AND DATABASE PERFORMANCE Normalizing the relations in a database separates entities into their own relations –Makes it possible to enter, modify, and delete data without disturbing entities other than the one directly being modified Join - an operation that combines two relations by matching rows based on values in columns in the two tables –The matching relationship is primary key to foreign key