Top Banner
Database Fundamentals - A Review Victor Raj, PhD Murray State University
34
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Keys-ERDs

Database Fundamentals - A Review

Victor Raj, PhDMurray State University

Page 2: Keys-ERDs

Objectives

• In this module, we will review the following:

• Primary key & its characteristics

• Composite Keys

• Foreign keys

• Anomalies & Relationships

• Dependencies and Normalization

CIS609 (Review) 2

Page 3: Keys-ERDs

Tables

• Table: two-dimensional structure composed of rows and columns

CIS609 (Review) 3

Page 4: Keys-ERDs

What is a database ‘table’?

CIS609 (Review) 4

Page 5: Keys-ERDs

Primary Key

• Each row in a table must be uniquely identifiable

• A Primary Key is one or more attributes that determine other attributes

• PK’s role is based on determination• If you know the value of attribute/column A, you

can determine the value of attribute B

• If you know a person’s M# (at Murray), you can determine their name

CIS609 (Review) 5

Page 6: Keys-ERDs

Keys (continued)

• Composite key• A key that is composed of more than one attribute

• Key attribute• Any attribute that is part of a key

CIS609 (Review) 6

Page 7: Keys-ERDs

The importance of ‘null’

• Nulls:

• No data entered. Or the absence of a value

• Not permitted in primary key

• Should be avoided in other attributes

• Can represent • An unknown attribute value; a known, but missing,

attribute value; a “not applicable” condition

CIS609 (Review) 7

Page 8: Keys-ERDs

Nulls (continued)

• Issues with Nulls:

• Can create problems when functions such as COUNT, AVERAGE, and SUM are used

• Can create logical problems when relational tables are linked – it may not retrieve some rows (costly lapse!)

• Databases need special functions to deal with themCIS609 (Review) 8

Page 9: Keys-ERDs

Back to Keys…

• Foreign key (FK)

• An attribute whose values match primary key values in a related table

• Referential integrity

• FK MUST contain a value that refers to an existing valid row in another table

CIS609 (Review) 9

Page 10: Keys-ERDs

Integrity rules

CIS609 (Review) 10

Page 11: Keys-ERDs

Integrity Rules (cont’d)

• Many RDBMs enforce integrity rules automatically

• However, it is safer to manage entity and referential integrity rules in the application - allows easier database migration.

• Developers use flags to avoid nulls – represents ‘unknown’

CIS609 (Review) 11

Page 12: Keys-ERDs

Redundancy

• Simply means “duplication”

• Controlled redundancy:

• Makes the relational database work

• Facilitates linking of tables together

• Multiple occurrences of values not redundant when required to make the relationship work

• Redundancy exists only when there is unnecessary duplication of attribute values

CIS609 (Review) 12

Page 13: Keys-ERDs

Excessive redundancy Anomalies

• Insert - You cannot add a row without being forced to add information that may not yet be available

• Delete - Deleting a row will result in the loss of other important information that you had no desire of losing

• Update - You are forced to make changes repeatedly

• See Video linked on canvas http://youtu.be/G9SA0Yv-o28

CIS609 (Review) 13

Page 14: Keys-ERDs

Update anomaly

CIS609 (Review) 14

What’s the problem here?

Page 15: Keys-ERDs

Deletion anomaly

M-number

Last name

First name

Course Time Room

M001 Smith Job ACC200 11:30 MW

BB302

M002 Smith Jhansi ACC200 12:30 TR

BB302

M001 Smith Job BUS215 12:30 MW

BB206

M003 Kline Smith BUS215 12:30 MW

BB206

CIS609 (Review) 15

What challenges do you face when you delete a student? Or a

course?

Page 16: Keys-ERDs

Insertion anomaly

M-number

Last name

First name

Course Time Room

ACC200 11:30 MW

BB302

ACC200 12:30 TR

BB302

BUS215 12:30 MW

BB206

CIS609 (Review) 16

Can you list all available courses?(Recall definition of PK… No NULLS allowed)

Page 17: Keys-ERDs

A good database designer can spot and fix such anomalies intuitively

How do you “fix” these anomalies?

…understand database relationships

CIS609 (Review) 17

Page 18: Keys-ERDs

Relationships within the Relational Database

• 1:M relationship

• Very common

• 1:1 relationship

• Should be rare in any relational database design

• M:N relationships

• Also very common, but missed by novices

• Converted to two (or more) 1:M relationshipsCIS609 (Review) 18

Page 19: Keys-ERDs

The 1:M Relationship

• Relational database norm

• Found in any database environment

CIS609 (Review) 19

Page 20: Keys-ERDs

Implementing 1:M

CIS609 (Review) 20

Page 21: Keys-ERDs

The 1:1 Relationship

• One entity related to only one other entity, and vice versa

• Sometimes means that entity components were not defined properly

• Could indicate that two entities actually belong in the same table

• Certain conditions absolutely require their use

CIS609 (Review) 21

Page 22: Keys-ERDs

The M:N Relationship

• Implemented by breaking it up to produce a set of 1:M relationships

• If two entities – STUDENTS, COURSES – have a M:N relationship, create a THIRD table to tie these two together (example follows)

• You must include (at the least) the primary keys of the tables to be linked in this THIRD table to ensure referential integrity (remember that?)

CIS609 (Review) 22

Page 23: Keys-ERDs

CIS609 (Review) 23

Page 24: Keys-ERDs

CIS609 (Review) 24

Ensures referential integrity...

Cannot enroll students in classes that

don’t exist. Or enroll students that don’t exist in STUDENT

Page 25: Keys-ERDs

CIS609 (Review) 25

This separation ensures that the

course information (title, credits etc.) are

not repeated unnecessarily.

Page 26: Keys-ERDs

Degree

CIS609 (Review) 26

Page 27: Keys-ERDs

Now you know…

• The importance of keys

• Controlled redundancy

• The types of anomalies and the dangers they present

• The degree and types of relationships and how to spot them

• … now for Normalization

CIS609 (Review) 27

Page 28: Keys-ERDs

Normal forms

• First – no repeating groups, but very likely to have partial dependencies

• Second – no repeating groups, no partial dependencies, but very likely to have transitive dependencies

• Third - no repeating groups, no partial dependencies, and no transitive dependencies.

CIS609 (Review) 28

Page 29: Keys-ERDs

Repeating groups

CIS609 (Review) 29

Page 30: Keys-ERDs

Partial dependency

CIS609 (Review) 30

Page 31: Keys-ERDs

Transitive and partial dependency

CIS609 (Review) 31

Removing all but the functional dependency will result in a 3NF design. “Removal” is accomplished by splitting the table into a set of related tables.

Page 32: Keys-ERDs

Summary - 1

• Tables are basic building blocks of a relational database

• Keys are central to the use of relational tables

• Keys define functional dependencies• Primary key

• Foreign key

CIS609 (Review) 32

Page 33: Keys-ERDs

Summary - 2

• Each table row must have a primary key that uniquely identifies the other attributes

• Tables linked by common attributes• Good design begins by identifying entities,

attributes, and relationships• 1:1, 1:M, M:N (connectivity)

• Unary, binary, ternary (degree)

CIS609 (Review) 33

Page 34: Keys-ERDs

Summary - 3

• Normalization

• First – no repeating groups, will have partial dependency

• Second – no partial dependency or repeating groups, will have transitive dependency

• Third – no transitive or partial dependency or even repeating groups.

• Normalization is good for maintaining data consistency and storage efficiency.

CIS609 (Review) 34