0% found this document useful (0 votes)
5 views20 pages

Session 08

Uploaded by

Monte Hartono
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
5 views20 pages

Session 08

Uploaded by

Monte Hartono
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 20

I S 300: INTRODUCTION TO

INFORMATION SYSTEMS
- Autumn 2019
- Shaosong Ou, Ph.D.

Session 8 – October 22nd, 2019


Managing Big Data;
Relational Database Principles
Agenda

Working with data: High-demand job skills

Database Management
q How to design, maintain, and communicate with a large database
q Users à Applications à Database Management Systems (DBMS) à
Databases
q Most popular ones: Microsoft SQL Server and Access, Oracle’s MySQL and Oracle
Database, and IBM’s DB2
q SQL: the programming language interfacing with the database

Reminder: Midterm Exam and Team Project topics


Data Organization Hierarchy

?
-

÷
S

3 © Prentice Hall 2011


Traditional File Processing

4
Problems w/ Traditional File Environment

• Files maintained separately by different departments


• Data redundancy
• Data inconsistency
• Program-data dependence
• Lack of flexibility
• Poor security
• Lack of data sharing and availability
Recording Data by Lists

6 © Prentice Hall 2011


Why Relational Database?

Problem with lists: hard to manage and scale


Example: Parcels and owners. Consider the following situation:
• What if a parcel has multiple owners, e.g. Joe and Mary Peterson?
• What if Joe and Mary add Mike to be a new owner?
• What if Mike sells the lot and no longer owns any parcels?
• What if Joe owns multiple parcels?
• What if Joe and Mary pass away and have no heir?
• What if Mike appears multiple times with diff. phone #’s & names?
• What if Mike gifts the parcel and phone to his buddy?
• What if in addition to the current owner, you also need to document a
parcel’s previous two (three) owners?
A Relation

A relation is a two-dimensional table that has specific characteristics.


The table dimensions, like a matrix, consist of rows and columns
Equivalent Sets of Terms

Table Row Column

File Record Field

Relation Tuple Attribute


Characteristics of a Relation

1. Rows contain data about an entity


2. Columns contain data about attributes of the entity
3. Cells of the table hold a single value
4. All entries in a column are of the same kind
5. Each column has a unique name
6. The order of the columns is unimportant
7. The order of the rows is unimportant
8. No two rows may hold identical sets of data values
A Sample Relation

Employee FirstName LastName Department EmailAddress Phone


Number

101 Mary Jacobs Administration [email protected] 360-285-8110

102 Rosalie Jackson Administration [email protected] 360-285-8120

103 Richard Bandalone Legal [email protected] 360-285-8210

104 George Smith Human Resources [email protected] 360-285-8310

105 Alan Adams Human Resources [email protected] 360-285-8320

106 Ken Evans Finance [email protected] 360-285-8410

107 Mary Abernathy Finance [email protected] 360-285-8420


Nonrelation Example 1

Cells of the table hold multiple values


Employee FirstName LastName Department EmailAddress Phone
Number

101 Mary Jacobs Administration [email protected] 360-285-8110

102 Rosalie Jackson Administration [email protected] 360-285-8120

103 Richard Bandalone Legal [email protected] 360-285-8210

104 George Smith Human Resources [email protected] 360-285-8310,


360-285-8391,
206-723-8392

105 Alan Adams Human Resources [email protected] 360-285-8320

106 Ken Evans Finance [email protected] 360-285-8410

107 Mary Abernathy Finance [email protected] 360-285-8420


Nonrelation Example 2
Order of rows matters and different column entries in EmailAddress
Employee FirstName LastName Department EmailAddress Phone
Number
101 Mary Jacobs Administration [email protected] 360-285-8110
102 Rosalie Jackson Administration [email protected] 360-285-8120
103 Richard Bandalone Legal [email protected] 360-285-8210
104 George Smith Human Resources [email protected] 360-285-8310
Fax: 360-285-8391
Home: 206-723-8392
105 Alan Adams Human Resources [email protected] 360-285-8320
106 Ken Evans Finance [email protected] 360-285-8410
107 Mary Abernathy Finance [email protected] 360-285-8420
Fax: 360-285-8491
Normalization

Normalization is the process of (or set of steps for) breaking a table or relation
with more than one theme into a set of tables such that each has only one
theme.

Relational design principles for normalized relations:


• to be a well formed relation, every determinant must be a candidate
key
• any relation that is not well formed should be broken into two or more
relations that are well formed
Connecting Relations: Keys
A primary key is a candidate key that is chosen as the key the DBMS will use
to uniquely identify each record in a relation.
The primary key of one relation is placed into a second relation as a foreign
key to represent a relationship.

For example:
Referential Integrity

Referential integrity states that every value of a foreign key must match a
value of an existing primary key.

In the relationship between EMPLOYEE and DEPARTMENT, the department


attribute located in the EMPLOYEE table is the foreign key and whatever
value is placed in that column, the same value MUST exist in the Department
attribute in the DEPARTMENT table.
Normalization Example
Sample PRESCRIPTION Relation and Data
PrescriptionN Date Drug Dosage CustomerName CustomerPhone CustomerEmailAddress
umber
P10001 10/17/2017 DrugA 10mg Smith, Alvin 575-523-2233 [email protected]
P10003 10/17/2017 DrugB 35mg Rhodes, Jeff 575-645-3455 [email protected]
P10004 10/17/2017 DrugA 20mg Smith, Sarah 575-523-2233 [email protected]
P10007 10/18/2017 DrugC 20mg Frye, Michael 575-645-4566 [email protected]
P10010 10/18/2017 DrugB 30mg Rhodes, Jeff 575-645-3455 [email protected]

• There are two themes: prescription and customer.


• These two themes should be broken into two separate tables.
Normalized Themes
Normalized Customer and Prescription Relations and Data. Note that the
CustomerEmailAddress is the foreign key in the PRESCRIPTION table below.
CustomerEmailAddress CustomerName CustomerPhone
[email protected] Smith, Alvin 575-523-2233
[email protected] Rhodes, Jeff 575-645-3455
[email protected] Frye, Michael 575-645-4566
[email protected] Smith, Sarah 575-523-2233

PrescriptionNumber Date Drug Dosage CustomerEmailAddress


P10001 10/17/2017 DrugA 10mg [email protected]
P10003 10/17/2017 DrugB 35mg [email protected]
P10004 10/17/2017 DrugA 20mg [email protected]
P10007 10/18/2017 DrugC 20mg [email protected]
P10010 10/18/2017 DrugB 30mg [email protected]
An Unnormalized Relation for Order
Normalized Tables Created from Order

You might also like