APPENDIX C DESIGNING DATABASES

Slides:



Advertisements
Similar presentations
BUSINESS DRIVEN TECHNOLOGY Plug-In T4 Designing Database Applications.
Advertisements

Ch5: ER Diagrams - Part 1 Much of the material presented in these slides was developed by Dr. Ramon Lawrence at the University of Iowa.
Database Systems: Design, Implementation, and Management Eighth Edition Chapter 4 Entity Relationship (ER) Modeling.
Chapter 4 Entity Relationship (E-R) Modeling
Entity Relationship (ER) Modeling
Copyright © 2015 Pearson Education, Inc. Database Design Chapters 17 and
Accounting System Design
Systems Development Life Cycle
Entity-Relation Modeling Hun Myoung Park, Ph.D., Public Management and Policy Analysis Program Graduate School of International Relations International.
Database Design & Mapping
Copyright © 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 7 Data Modeling Using the Entity- Relationship (ER) Model.
Agenda for Week 1/31 & 2/2 Learn about database design
The Relational Database Model:
Business Driven Technology Unit 2 Exploring Business Intelligence Copyright © 2015 McGraw-Hill Education. All rights reserved. No reproduction or distribution.
Chapter 3: Data Modeling
Chapter 4 Entity Relationship (ER) Modeling
Database Systems: Design, Implementation, and Management Tenth Edition
Chapter 4 Entity Relationship (E-R) Modeling
Database Management COP4540, SCS, FIU Database Modeling Using the Entity-Relationship Model (Chapter 3)
Michael F. Price College of Business Chapter 6: Logical database design and the relational model.
Data Modeling 1 Yong Choi School of Business CSUB.
© 2003 McGraw-Hill Australia Pty Ltd, PPTs t/a Accounting Information & Reporting Systems by A. Aseervatham and D. Anandarajah. Slides prepared by Kaye.
Yong Choi School of Business CSUB
Data Modeling Using the Entity-Relationship Model
Data Modeling Using the Entity-Relationship Model
1 Web-Enabled Decision Support Systems Entity-Relationship Modeling Prof. Name Position (123) University Name.
3.1 CSIS 3310 Chapter 3 The Entity-Relationship Model Conceptual Data Modeling.
DeSiamorewww.desiamore.com/ifm1 Database Management Systems (DBMS)  B. Computer Science and BSc IT Year 1.
CSE314 Database Systems Data Modeling Using the Entity- Relationship (ER) Model Doç. Dr. Mehmet Göktürk src: Elmasri & Navanthe 6E Pearson Ed Slide Set.
Database. Basic Definitions Database: A collection of related data. Database Management System (DBMS): A software package/ system to facilitate the creation.
Chapter 5 Entity–Relationship Modeling
1 ER Modeling BUAD/American University Entity Relationship (ER) Modeling.
MIS 385/MBA 664 Systems Implementation with DBMS/ Database Management Dave Salisbury ( )
Copyright © 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 7 Data Modeling Using the Entity- Relationship (ER) Model.
Concepts and Terminology Introduction to Database.
Fundamentals of Relational Database Operations
Copyright 2008 McGraw-Hill Ryerson 1 TECHNOLOGY PLUG-IN T5 DESIGNING DATABASE APPLICATIONS.
McGraw-Hill/Irwin © 2008 The McGraw-Hill Companies, All Rights Reserved Plug-In T5: Designing Database Applications Business Driven Technology.
CS370 Spring 2007 CS 370 Database Systems Lecture 4 Introduction to Database Design.
© Pearson Education Limited, Chapter 7 Entity-Relationship modeling Transparencies.
Database Systems: Design, Implementation, and Management Eighth Edition Chapter 4 Entity Relationship (ER) Modeling.
Chapter 4 Entity Relationship (ER) Modeling.  ER model forms the basis of an ER diagram  ERD represents conceptual database as viewed by end user 
Next Back A-1 Management Information Systems for the Information Age Second Canadian Edition Copyright 2004 The McGraw-Hill Companies, Inc. All rights.
C-1 Management Information Systems for the Information Age Copyright 2004 The McGraw-Hill Companies, Inc. All rights reserved Extended Learning Module.
Entity-Relationship Model Using High-Level Conceptual Data Models for Database Design Entity Types, Sets, Attributes and Keys Relationship Types, Sets,
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.
Msigwaemhttp//:msigwaem.ueuo.com/1 Database Management Systems (DBMS)  B. Computer Science and BSc IT Year 1.
1 A Demo of Logical Database Design. 2 Aim of the demo To develop an understanding of the logical view of data and the importance of the relational model.
Data modeling using the entity-relationship model Chapter 3 Objectives How entities, tuples, attributes and relationships among entities are represented.
Database Systems: Design, Implementation, and Management Ninth Edition Chapter 4 Entity Relationship (ER) Modeling.
Databases Illuminated Chapter 3 The Entity Relationship Model.
MIS 385/MBA 664 Systems Implementation with DBMS/ Database Management
INTRODUCTION TO DATABASE DESIGN. Definitions Database Models: Conceptual, Logical, Physical Conceptual: “big picture” overview of data and relationships.
Data Modeling Yong Choi School of Business CSUB. Part # 2 2 Study Objectives Understand concepts of data modeling and its purpose Learn how relationships.
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.
The Entity-Relationship Model, P. I R. Nakatsu. Data Modeling A data model is the relatively simple representation, usually graphic, of the structure.
Chapter 3: Modeling Data in the Organization. Business Rules Statements that define or constrain some aspect of the business Assert business structure.
McGraw-Hill/Irwin Copyright © 2006 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter 6 Modeling the Data: Conceptual and Logical Data Modeling.
IS 4420 Database Fundamentals Chapter 3: Modeling Data in the Organization Leon Chen.
Rationale Databases are an integral part of an organization. Aspiring Database Developers should be able to efficiently design and implement databases.
Database Designsemester Slide 1 Database Design Lecture 7 Entity-relationship modeling Text , 7.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
Review of Week 1 Database DBMS File systems vs. database systems
Entity-Relationship Diagram (ERD)
Presentation transcript:

APPENDIX C DESIGNING DATABASES Copyright © 2015 McGraw-Hill Education. All rights reserved. No reproduction or distribution without the prior written consent of McGraw-Hill Education.

INTRODUCTION The core chapters introduced: Database - maintains information about various types of objects (inventory), events (transactions), people (employees), and places (warehouses) Database management system (DBMS) – creates, reads, updates, and deletes data in a database while controlling access and security Relational database model - a type of database that stores its information in the form of logically-related two-dimensional tables

ENTITIES AND DATA RELATIONSHIPS Data model – The logical data structures that detail the relationships among data elements using graphics or pictures The underlying relationships in a database environment are: Independent of the data model Independent of the DBMS that is being used Entity-relationship diagram (ERD) - A technique for documenting the relationships between entities in a database environment

Entities And Their Attributes Entity - Also called a table, stores information about a person, place, thing, transaction, or event A customer is an entity, as is a merchandise item Attribute – Data elements associated with an entity A CUSTOMER entity can be described by a Customer Number, First Name, Last Name, Street, City, State, Zip Code, Phone Number

Entities And Their Attributes

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

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

Simple versus Composite

Single-Valued versus Multi-Valued Single-valued attribute 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

Single-Valued versus Multi-Valued Multi-valued attribute 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

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

Null-Valued Null-valued attribute – Assigned to an attribute when no other value applies or when a value is unknown Example: A person who does not have a mobile phone would have null stored at the value for the Mobile Phone Number attribute

DOCUMENTING ENTITY-RELATIONSHIP DIAGRAMS The two most commonly used styles of ERD notation are: Chen 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

Basic Data Relationships

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

Basic Data Relationships 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: One-to-one One-to-many Many-to-many

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

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

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

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

Documenting Relationships – The Chen Method 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

DEALING WITH MANY-TO-MANY RELATIONSHIPS There are problems with many-to-many relationships 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 Relationships cannot have attributes An entity must represent the relationship

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)

Composite Entities There are three ORDER instances and three merchandise ITEM instances. The first ORDER for Customer Number 1111 (Order Number 1000) contains only one ITEM (Item Number 9244). The second ORDER for Customer Number 1111 (Order Number 1001) contains a second copy of Item Number 9244, but ordered on a different date. Order Number 1002, which belongs to Customer Number 1211, has two ITEM(s) on it (Item Number 9250 and Item Number 9255).

Composite Entities A composite entity called a LINE ITEM (thinking of it as a line item on a packing slip) is created to represent the relationship between an ORDER and a PRODUCT.

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

Relational Data Model and the Database 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

FROM ENTITIES TO TABLES 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

FROM ENTITIES TO TABLES When rows of data are included, an instance of a relation is created

FROM ENTITIES TO TABLES 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 Note the proper notation is to capitalize the table name (e.g. CUSTOMER) and all columns are in title case.

FROM ENTITIES TO TABLES 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

FROM ENTITIES TO TABLES 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: The name of the table The name of the column The primary key of the row

FROM ENTITIES TO TABLES 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: A primary key should contain some value that is highly unlikely ever to be null A primary key should never change

LOGICALLY RELATING TABLES The use of identifiers represent relationships between entities

LOGICALLY RELATING TABLES 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)

LOGICALLY RELATING TABLES 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)