appendix c designing databases appendix c designing databases copyright © 2015 mcgraw-hill...

37
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.

Upload: victoria-mcdaniel

Post on 23-Dec-2015

219 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: APPENDIX C DESIGNING DATABASES APPENDIX C DESIGNING DATABASES Copyright © 2015 McGraw-Hill Education. All rights reserved. No reproduction or distribution

APPENDIX C

DESIGNING DATABASES

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.

Page 2: APPENDIX C DESIGNING DATABASES APPENDIX C DESIGNING DATABASES Copyright © 2015 McGraw-Hill Education. All rights reserved. No reproduction or distribution

C-2

INTRODUCTIONThe 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

Page 3: APPENDIX C DESIGNING DATABASES APPENDIX C DESIGNING DATABASES Copyright © 2015 McGraw-Hill Education. All rights reserved. No reproduction or distribution

C-3

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

Page 4: APPENDIX C DESIGNING DATABASES APPENDIX C DESIGNING DATABASES Copyright © 2015 McGraw-Hill Education. All rights reserved. No reproduction or distribution

C-4

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

Page 5: APPENDIX C DESIGNING DATABASES APPENDIX C DESIGNING DATABASES Copyright © 2015 McGraw-Hill Education. All rights reserved. No reproduction or distribution

C-5

Entities And Their Attributes

Page 6: APPENDIX C DESIGNING DATABASES APPENDIX C DESIGNING DATABASES Copyright © 2015 McGraw-Hill Education. All rights reserved. No reproduction or distribution

C-6

Attributes

There are several types of attributes including:

– Simple versus composite

– Single-valued versus multi-valued

– Stored versus derived

– Null-valued

Page 7: APPENDIX C DESIGNING DATABASES APPENDIX C DESIGNING DATABASES Copyright © 2015 McGraw-Hill Education. All rights reserved. No reproduction or distribution

C-7

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

Page 8: APPENDIX C DESIGNING DATABASES APPENDIX C DESIGNING DATABASES Copyright © 2015 McGraw-Hill Education. All rights reserved. No reproduction or distribution

C-8

Simple versus Composite

Page 9: APPENDIX C DESIGNING DATABASES APPENDIX C DESIGNING DATABASES Copyright © 2015 McGraw-Hill Education. All rights reserved. No reproduction or distribution

C-9

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

Page 10: APPENDIX C DESIGNING DATABASES APPENDIX C DESIGNING DATABASES Copyright © 2015 McGraw-Hill Education. All rights reserved. No reproduction or distribution

C-10

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

Page 11: APPENDIX C DESIGNING DATABASES APPENDIX C DESIGNING DATABASES Copyright © 2015 McGraw-Hill Education. All rights reserved. No reproduction or distribution

C-11

Single-Valued versus Multi-Valued

Page 12: APPENDIX C DESIGNING DATABASES APPENDIX C DESIGNING DATABASES Copyright © 2015 McGraw-Hill Education. All rights reserved. No reproduction or distribution

C-12

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

Page 13: APPENDIX C DESIGNING DATABASES APPENDIX C DESIGNING DATABASES Copyright © 2015 McGraw-Hill Education. All rights reserved. No reproduction or distribution

C-13

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

Page 14: APPENDIX C DESIGNING DATABASES APPENDIX C DESIGNING DATABASES Copyright © 2015 McGraw-Hill Education. All rights reserved. No reproduction or distribution

C-14

DOCUMENTING ENTITY-RELATIONSHIP DIAGRAMS

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

Page 15: APPENDIX C DESIGNING DATABASES APPENDIX C DESIGNING DATABASES Copyright © 2015 McGraw-Hill Education. All rights reserved. No reproduction or distribution

C-15

Basic Data Relationships

Page 16: APPENDIX C DESIGNING DATABASES APPENDIX C DESIGNING DATABASES Copyright © 2015 McGraw-Hill Education. All rights reserved. No reproduction or distribution

C-16

Basic Data RelationshipsThe relationships that are stored in a database

are between instances of entities

Page 17: APPENDIX C DESIGNING DATABASES APPENDIX C DESIGNING DATABASES Copyright © 2015 McGraw-Hill Education. All rights reserved. No reproduction or distribution

C-17

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

Page 18: APPENDIX C DESIGNING DATABASES APPENDIX C DESIGNING DATABASES Copyright © 2015 McGraw-Hill Education. All rights reserved. No reproduction or distribution

C-18

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

Page 19: APPENDIX C DESIGNING DATABASES APPENDIX C DESIGNING DATABASES Copyright © 2015 McGraw-Hill Education. All rights reserved. No reproduction or distribution

C-19

One-to-ManyOne-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

Page 20: APPENDIX C DESIGNING DATABASES APPENDIX C DESIGNING DATABASES Copyright © 2015 McGraw-Hill Education. All rights reserved. No reproduction or distribution

C-20

Many-to-ManyMany-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

Page 21: APPENDIX C DESIGNING DATABASES APPENDIX C DESIGNING DATABASES Copyright © 2015 McGraw-Hill Education. All rights reserved. No reproduction or distribution

C-21

Documenting Relationships – The Chen Method

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

Page 22: APPENDIX C DESIGNING DATABASES APPENDIX C DESIGNING DATABASES Copyright © 2015 McGraw-Hill Education. All rights reserved. No reproduction or distribution

C-22

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

Page 23: APPENDIX C DESIGNING DATABASES APPENDIX C DESIGNING DATABASES Copyright © 2015 McGraw-Hill Education. All rights reserved. No reproduction or distribution

C-23

DEALING WITH MANY-TO-MANY RELATIONSHIPS

There are problems with many-to-many relationships1.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

Page 24: APPENDIX C DESIGNING DATABASES APPENDIX C DESIGNING DATABASES Copyright © 2015 McGraw-Hill Education. All rights reserved. No reproduction or distribution

C-24

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)

Page 25: APPENDIX C DESIGNING DATABASES APPENDIX C DESIGNING DATABASES Copyright © 2015 McGraw-Hill Education. All rights reserved. No reproduction or distribution

C-25

Composite Entities

Page 26: APPENDIX C DESIGNING DATABASES APPENDIX C DESIGNING DATABASES Copyright © 2015 McGraw-Hill Education. All rights reserved. No reproduction or distribution

C-26

Composite Entities

Page 27: APPENDIX C DESIGNING DATABASES APPENDIX C DESIGNING DATABASES Copyright © 2015 McGraw-Hill Education. All rights reserved. No reproduction or distribution

C-27

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

Page 28: APPENDIX C DESIGNING DATABASES APPENDIX C DESIGNING DATABASES Copyright © 2015 McGraw-Hill Education. All rights reserved. No reproduction or distribution

C-28

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

Page 29: APPENDIX C DESIGNING DATABASES APPENDIX C DESIGNING DATABASES Copyright © 2015 McGraw-Hill Education. All rights reserved. No reproduction or distribution

C-29

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

Page 30: APPENDIX C DESIGNING DATABASES APPENDIX C DESIGNING DATABASES Copyright © 2015 McGraw-Hill Education. All rights reserved. No reproduction or distribution

C-30

FROM ENTITIES TO TABLES

When rows of data are included, an instance of a relation is created

Page 31: APPENDIX C DESIGNING DATABASES APPENDIX C DESIGNING DATABASES Copyright © 2015 McGraw-Hill Education. All rights reserved. No reproduction or distribution

C-31

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

Page 32: APPENDIX C DESIGNING DATABASES APPENDIX C DESIGNING DATABASES Copyright © 2015 McGraw-Hill Education. All rights reserved. No reproduction or distribution

C-32

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

Page 33: APPENDIX C DESIGNING DATABASES APPENDIX C DESIGNING DATABASES Copyright © 2015 McGraw-Hill Education. All rights reserved. No reproduction or distribution

C-33

FROM ENTITIES TO TABLESA unique primary key makes it possible to

uniquely identify every row in a tableThe 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

Page 34: APPENDIX C DESIGNING DATABASES APPENDIX C DESIGNING DATABASES Copyright © 2015 McGraw-Hill Education. All rights reserved. No reproduction or distribution

C-34

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

FROM ENTITIES TO TABLES

Page 35: APPENDIX C DESIGNING DATABASES APPENDIX C DESIGNING DATABASES Copyright © 2015 McGraw-Hill Education. All rights reserved. No reproduction or distribution

C-35

LOGICALLY RELATING TABLES

The use of identifiers represent relationships between entities

Page 36: APPENDIX C DESIGNING DATABASES APPENDIX C DESIGNING DATABASES Copyright © 2015 McGraw-Hill Education. All rights reserved. No reproduction or distribution

C-36

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

Page 37: APPENDIX C DESIGNING DATABASES APPENDIX C DESIGNING DATABASES Copyright © 2015 McGraw-Hill Education. All rights reserved. No reproduction or distribution

C-37

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)