section 08 - review

109
Section 08 - REVIEW

Upload: shaine-villarreal

Post on 03-Jan-2016

25 views

Category:

Documents


0 download

DESCRIPTION

Section 08 - REVIEW. E-R Diagrams. The Entity-Relationship Approach Represents reality using well-defined graphics and rules Basic building blocks are “things” (entities) and relationships. Member. M. Adopts. 1. Animal. E-R Diagrams. Advantages Theoretical foundation (Set Theory) - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Section 08 - REVIEW

Section 08 - REVIEW

Page 2: Section 08 - REVIEW

E-R Diagrams

• The Entity-Relationship Approach

– Represents reality using well-defined graphics and rules

• Basic building blocks are “things” (entities) and relationships

Member

Animal

M

1 Adopts

Page 3: Section 08 - REVIEW

E-R Diagrams

• Advantages– Theoretical foundation (Set Theory)– Good for communication– Build E-R Model, then translate to any

type of RDBMS• Disadvantages

– Different (yet another new thing to learn)– Must translate to the relational model

Page 4: Section 08 - REVIEW

E-R Diagrams

• Entity-Relationship Model: Basic Concepts

– Entity

• Thing, Object, Concept of interest to the enterprise

• Each occurrence can be uniquely identified

Page 5: Section 08 - REVIEW

E-R Diagrams

• Entity-Relationship Model: Basic Concepts

– Attribute

• Property of an entity

• Column

Page 6: Section 08 - REVIEW

E-R Diagrams

• Entity-Relationship Model: Basic Concepts

– Relationship

• Association between two (or more) entities

Page 7: Section 08 - REVIEW

E-R Diagrams

• Entity-Relationship Model: Basic Concepts

– Entity Identifier

• Attribute(s) whose value uniquely identifies an entity

• Primary Key

Page 8: Section 08 - REVIEW

E-R Diagrams

• What is an Entity?

– Physical entity types

• Person

• Building

• Machine

• Book

• Usually Singular

Page 9: Section 08 - REVIEW

E-R Diagrams

• What is an Entity?

– Conceptual entity types

• Contract

• Account

• Order

• Course

Page 10: Section 08 - REVIEW

E-R Diagrams

• What is an Entity?

– Event entity types

• Transaction

• Shipment

• Reservation

• Phone Call

• Seminar Offering

Page 11: Section 08 - REVIEW

E-R Diagrams

• Entity-Relationship Model: Diagrams– Example:

– Soft Rectangle represents entities• Noun• Singular

– Connecting Line represents relationships• Verb

Member

Animal

Adopts

Page 12: Section 08 - REVIEW

E-R Diagrams

• Relationships have Characteristics

– A relationship has Cardinality (Degree)

One-to-One One-to-Many Many-to-Many

Page 13: Section 08 - REVIEW

E-R Diagrams

• Each entity’s participation is Mandatory or Optional

• Cardinality & Optionality

are based on business rules

Mandatory

Optional

Page 14: Section 08 - REVIEW

E-R Diagrams

• Mandatory

– Every instance of the entity MUST participate in the relationship

– Example:

• Every animal is cared for by at least one employee

Page 15: Section 08 - REVIEW

E-R Diagrams

• Optional

– An instance of the entity CAN participate in the relationship

– Example:

• Some employees do not take care of animals

Page 16: Section 08 - REVIEW

E-R Diagrams

• Determining Optionality & Cardinality

– Optionality & Cardinality

• Specify lower and upper bounds of each entity’s participation in the relationship

• Use one of the following templates

Page 17: Section 08 - REVIEW

E-R Diagrams

• Template 1

One ________(can/must) ________ (one and only one/one or more) __________

• Template 2 One ________ ________a minimum of (0/1) and a maximum of (1/many) __________

Page 18: Section 08 - REVIEW

E-R Diagrams

• Use either template

– Read each relationship twice

• Left to Right

• Right to Left

Page 19: Section 08 - REVIEW

E-R Diagrams

• Guidelines to Develop an E-R Diagram

– Identify the Major Entities

– Identify the Attributes for each entity

– Determine the Unique Identifier(s)

– Identify the Relationships

– Assign Cardinality

– Determine Optionality

– Resolve M:N Relationships

Page 20: Section 08 - REVIEW

E-R Diagrams

• Mapping the E-R Diagram to the Relational Database

– Each entity becomes a Table

– Each attribute becomes a Column

– Unique Identifier becomes the PK

– Each 1:M becomes a FK on the Many Side

Page 21: Section 08 - REVIEW

E-R Diagrams

• Practice 01

– A company has ten departments

– A company has five divisions

– A company has one hundred employees

– Each employee must work for one department

– Each division has two departments

Page 22: Section 08 - REVIEW

E-R Diagrams

• Practice 02

– A company has twenty employees

– Each employee works for a department

– There are two departments in the company

Page 23: Section 08 - REVIEW

E-R Diagrams

• Practice 03

– A company has three divisions

– A company has one manager per division

– Each manager is in charge of one committee

Page 24: Section 08 - REVIEW

E-R Diagrams

• Practice 04

– A company has a sales department with fifteen salespersons

– Each salesperson works for the sales department

– Each salesperson is supervised by one manager

– The managers may not have an employee to supervise

Page 25: Section 08 - REVIEW

E-R Diagrams

• Practice 05

– A piece of equipment is built with ten parts

– The parts come from suppliers

– All parts are held in inventory until needed to build a piece of equipment

Page 26: Section 08 - REVIEW

E-R Diagrams

• Practice 06

– There are two hundred students

– Each student must attend an orientation

– An orientation is held at the beginning of each semester

– Students attend the orientation in their first or second semester

Page 27: Section 08 - REVIEW

E-R Diagrams

• Practice 07

– There are forty rooms in a dorm

– Each room in the dorm holds two students

– There are five dorms on campus

– Each dorm has four floors

Page 28: Section 08 - REVIEW

E-R Diagrams

• Practice 08

– Each faculty member advises fifty students

– Each student has an advisor

– There are faculty that do not advise students

Page 29: Section 08 - REVIEW

E-R Diagrams

• Practice 09

– Students enroll in courses

– Courses are taught each semester

– Students receive a final grade for each course

– Each course has a maximum number of students enrolled

– Each course has a minimum number of students enrolled

Page 30: Section 08 - REVIEW

E-R Diagrams

• Practice 10– Basketball players sign contracts– Contracts are good for one to three years– Some players play in a game– Not all players may play in a game– Some players may be injured– Some injuries require a hospital visit– Hospitals take care of patients– Some hospital patients are basketball

players

Page 31: Section 08 - REVIEW

End 10-21-05

Page 32: Section 08 - REVIEW

Normalization

• Normalization using Codd’s Rules– Codd and contemporaries developed rules for

“Normal Forms”• 1NF• 2NF• 3NF

– Normal levels to do in database design• Boyce/Codd NF – 3.5NF• 4NF• 5NF

Page 33: Section 08 - REVIEW

Normalization

Class Enrolment

Class CodeClass

DescriptionStudent Number Name

503  

Mgt Info Systems  

000010000300005

Masters, RickSmith, SteveJones, Terry

540  

Quant Methods  

000020000300004

Wallace, FredSmith, SteveNurk, Sterling

Page 34: Section 08 - REVIEW

Normalization

Class Enrolment

Class Code Class Description Student Number Name

503 Mgt Info Systems 00001 Masters, Rick

503 Mgt Info Systems 00003 Smith, Steve

503 Mgt Info Systems 00005 Jones, Terry

540 Quant Methods 00002 Wallace, Rusty

540 Quant Methods 00003 Smith, Steve

540 Quant Methods 00004 Nurk, Sterling

1NF

Page 35: Section 08 - REVIEW

Normalization2NF

Class Enrolment

Class Code Class Description Student Number Name

503 Mgt Info Systems 00001 Masters, Rick

503 Mgt Info Systems 00006 Smith, Steve

503 Mgt Info Systems 00005 Jones, Terry

540 Quant Methods 00002 Wallace, Rusty

540 Quant Methods 00003 Smith, Steve

540 Quant Methods 00004 Nurk, Sterling

Page 36: Section 08 - REVIEW

Normalization

Class Code Class Description

503 Mgt Info Systems

540 Quant Methods

2NF & 3NF

CLASS

Student Number

Name

00001 Masters, Rick

00006 Smith, Steve

00005 Jones, Terry

00002Wallace, Rusty

00003 Smith, Steve

00004 Nurk, Sterling

STUDENT

Page 37: Section 08 - REVIEW

Normalization

• Rules for 1NF, 2NF, & 3NF– 1NF

• Break out repeating groups into a separate entity– 2NF

• Break out attributes that are dependent on part of the primary key into a separate entity

• Called Partial Dependency– 3NF

• Break out attributes that are wholly dependent on another key (not PK) into a separate entity

• Called Transitive Dependency

Page 38: Section 08 - REVIEW

Normalization

• Normalization Cont’d– A relation is in 3NF if all the attributes are

functionally dependent• On the Key• On the Whole Key, and• On Nothing but the Key

–(So Help Me Codd)

Page 39: Section 08 - REVIEW

Functional Dependency & Normalization

• How to Normalize Data using Functional Dependencies– Definition of Functional Dependency

• Given a relation R, attribute Y of R is functionally dependent on attribute X of R, if and only if each X value in R has associated with it precisely one Y-value in R (at any one time)

Page 40: Section 08 - REVIEW

Functional Dependency

• Y of R is Dependent on X of R• X functionally determines Y

WARD NAME

WARD TYPE NO. OF BEDS

SENIOR NURSE

PATINET NO

PATIENT NAME

DATE OF BIRTH

Liston Orthopedic 6 J Bryan 45812 D Carter 21/02/65

Liston Orthopedic 6 J Bryan 71384 R Willis 08/10/46

Liston Orthopedic 6 J Bryan 69355 G Barnes 17/06/41

Godlee General 10 V Fox 52217 M Brown 21/02/35

Godlee General 10 V Fox 10823 R Willis 12/03/54

X Y

Functional Dependency & Normalization

Page 41: Section 08 - REVIEW

Functional Dependency

• Example 01

Subscriber

Number

Name

Magazine

Code

Magazine Start Date

End Date

           

101 Jones TIM Time 3/1993 2/1999

           

110 Allen NEW Newsweek

2/1996 1/1999

    SCI Science 6/1994 5/2000

           

202 Smith

NEW Newsweek

2/1994 1/1999

    TIM Time 5/1994 4/2001

    TIM Time 5/1994 4/2001

Functional Dependency & Normalization

Page 42: Section 08 - REVIEW

Functional Dependency

• Example 01• Normalization begins with the arrangement of

information into tables with rows and columns such that repeating groups of information have been eliminated, that is, the "cells" have data with atomic values. In addition, normalized tables should have some data field(s) which is unique for all rows.

• In this case, because SMITH has two identical subscriptions, we need to invent a new field, namely SUBSCRIPTION NUMBER, in order to insure uniqueness, i.e. no duplicate rows

Functional Dependency & Normalization

Page 43: Section 08 - REVIEW

Functional Dependency

• Example 01• 1NF – Resulting Table

Subscriber

Number

Name

Subscription

Number

Magazine

Code

Magazine Start Date

End Date

             

101 Jones 001 TIM Time 3/1993 2/1999

110 Allen 002 NEW Newsweek

2/1996 1/1999

110 Allen 003 SCI Science 6/1994 5/2000

202 Smith

004 NEW Newsweek

2/1994 1/1999

202 Smith

005 TIM Time 5/1994 4/2001

202 Smith

006 TIM Time 5/1994 4/2001

Functional Dependency & Normalization

Page 44: Section 08 - REVIEW

Functional Dependency

• Example 01• Functional Dependency A central concept of

the normalization process is the functional dependency. Simply put, a functional dependency exists between two data fields when for each distinct value of one field, there is only one possible value for the other field.  

Functional Dependency & Normalization

Page 45: Section 08 - REVIEW

Functional Dependency

• Example 01• For example, if we assume that SUBSCRIBER

NUMBER is a uniquely assigned number for each subscriber, then there is a functional dependency between SUBSCRIBER NUMBER and NAME. We could say that SUBSCRIBER NUMBER functionally determines NAME or, conversely,that NAME is functionally dependent upon SUBSCRIBER NUMBER.

Functional Dependency & Normalization

Page 46: Section 08 - REVIEW

Functional Dependency

• Example 01• This functional dependency and others are shown

below, using a convenient notation, i.e. " A-->B.“

 • SUBSCRIBER NUMBER-->NAME• MAGAZINE CODE-->MAGAZINE• SUBSCRIPTION NUMBER-->SUBSCRIBER

NUMBER, NAME, MAGAZINE CODE,MAGAZINE, START DATE, END DATE  

Functional Dependency & Normalization

Page 47: Section 08 - REVIEW

Functional Dependency

• Example 01• It is critical to this process to fully understand

the underlying assumptions about the information that is being normalized. Successful normalization is, for all practical purposes, impossible without understanding the meaning and usage of information.

Functional Dependency & Normalization

Page 48: Section 08 - REVIEW

Functional Dependency

• Example 01• In our example, our assumptions are: • (1) SUBSCRIBER NUMBER is uniquely

assigned to each subscriber.• (2) MAGAZINE CODE is a convenient unique

code for each magazine name.• (3) SUBSCRIPTION NUMBER is uniquely

assigned to each subscription and therefore functionally determines all fields.

Functional Dependency & Normalization

Page 49: Section 08 - REVIEW

Functional Dependency

• Example 01• 2NF• Information which is in Second Normal Form has the

quality that some field (or fields) functionally determines all of the others. This field(s) is called a primary key. Building Second Normal Form tables is simply the mechanical process of making tables out of the functional dependencies and noting which field(s) is the primary key. The following notation shows our new tables in Second Normal Form.

Functional Dependency & Normalization

Page 50: Section 08 - REVIEW

Functional Dependency

• Example 01• 2NF

Subscriber

NumberKEY

Subscriber

Name

Magazine

CodeKEY

Magazine

Name

Subscription

NumberKEY

Subscriber

Number

Name

Magazine

Code

Magazine

Name

Start

Date

EndDate

Subscriber Table

Magazine Table

Subscription Table

Functional Dependency & Normalization

Page 51: Section 08 - REVIEW

Functional Dependency

• Example 01• At this point in the normalization process, the

task is to determine if the Second Normal Form tables are also in Third Normal Form. Third Normal Form tables are defined as tables where there is no functional dependency between non-key fields.

Functional Dependency & Normalization

Page 52: Section 08 - REVIEW

Functional Dependency

• Example 01• The SUBSCRIBER and MAGAZINE tables are

therefore in Third Normal Form since each has only one non-key field. The SUBSCRIPTION table, however, has several functional dependencies between non-key fields. They are:

• SUBSCRIBER NUMBER --> NAME• MAGAZINE CODE --> MAGAZINE. • This table can be made into Third Normal Form by

very simply eliminating the dependent field(s).

Functional Dependency & Normalization

Page 53: Section 08 - REVIEW

Functional Dependency

• Example 01• 3NF

Subscriber

NumberKEY

Subscriber

Name

Magazine

CodeKEY

Magazine

Name

Subscription

NumberKEY

Start

Date

EndDate

Subscriber Table

Magazine Table

Subscription Table

Functional Dependency & Normalization

Page 54: Section 08 - REVIEW

Functional Dependency

• Example 01• Having reached Third Normal Form, it

should be possible to identify foreign keys. Foreign keys are some field(s) in one table which is(are) the primary key in another.

Functional Dependency & Normalization

Page 55: Section 08 - REVIEW

Functional Dependency

• Example 01• In this case, SUBSCRIBER NUMBER in the

SUBSCRIPTION table is a foreign key referencing the primary key of the SUBSCRIBER table. And MAGAZINE CODE in the SUBSCRIPTION table is a foreign key referencing the primary key of the MAGAZINE table.

SubscriptionNumber

Primary Key

SubscriberNumber

Foreign Key

MagazineCode

Foreign Key

Start

Date

EndDate

Functional Dependency & Normalization

Page 56: Section 08 - REVIEW

Normalization

• Practice 01

Student# Advisor Adv-Room Class1 Class2 Class3

1022 Jones 412 101-07 143-01 159-02

4123 Smith 216 201-01 211-02 214-01

Page 57: Section 08 - REVIEW

Normalization

• Practice 01• 1NF

Student# Advisor Adv-Room Class#

1022 Jones 412 101-07

1022 Jones 412 143-01

1022 Jones 412 159-02

4123 Smith 216 201-01

4123 Smith 216 211-02

4123 Smith 216 214-01

Page 58: Section 08 - REVIEW

Normalization

• Practice 01• 2NF

Student:

Student# Advisor Adv-Room

1022 Jones 412

4123 Smith 216

Registration:

Student# Class#

1022 101-07

1022 143-01

1022 159-02

4123 201-01

4123 211-02

4123 214-01

Page 59: Section 08 - REVIEW

Normalization

• Practice 01• 3NF

Students:

Student# Advisor

1022 Jones

4123 Smith

Faculty

Advisor Room

Jones 412

Smith 216

Page 60: Section 08 - REVIEW

Normalization

• Practice 01• Final Tables

Student:

Student# Advisor

1022 Jones

4123 Smith

Faculty

Advisor Room

Jones 412

Smith 216

Registration:

Student# Class#

1022 101-07

1022 143-01

1022 159-02

4123 201-01

4123 211-02

4123 214-01

Page 61: Section 08 - REVIEW

Normalization

• Practice 02

Class Enrollment

Class CodeClass

DescriptionStudent Number

Name

503 Mgt Info Systems 00001 Masters, Rick

    00003 Smith, Steve

    00005 Jones, Terry

540 Quant Methods 00002 Wallace, Fred

    00003 Smith, Steve

    00004 Nurk, Sterling

Page 62: Section 08 - REVIEW

Normalization

• Practice 02• 1NF

Class Enrollment

Class Code Class Description Student Number Name

503 Mgt Info Systems 00001 Masters, Rick

503 Mgt Info Systems 00003 Smith, Steve

503 Mgt Info Systems 00005 Jones, Terry

540 Quant Methods 00002 Wallace, Rusty

540 Quant Methods 00003 Smith, Steve

540 Quant Methods 00004 Nurk, Sterling

Page 63: Section 08 - REVIEW

Normalization

• Practice 02• 2NF• 3NF

Student Number

Name

00001 Masters, Rick

00002 Wallace, Rusty

00003 Smith, Steve

00004 Nurk, Sterling

00005 Jones, Terry

Class CodeClass

Description

503 Mgt Info Systems

540 Quant Methods

CLASS

STUDENT

Page 64: Section 08 - REVIEW

Normalization

• Practice 03

Projectnumber

Project name

Employee number

Employeename

RateCategory

Hourlyrate

1023Madagascartravel site

11VincentRadebe

A $60

    12 Pauline James B $50

    16Charles

RamorazC $40

1056OnlineEstateagency

11VincentRadebe

A $60

    17MoniqueWilliams

B $50

Page 65: Section 08 - REVIEW

Normalization

• Practice 03• 1NF

Project number

Project name

Employee number

Employee name

Rate category

Hourly rate

1023Madagascar

travel site11

Vincent Radebe

A $60

1023Madagascar

travel site12

Pauline James

B $50

1023Madagascar

travel site16

Charles Ramoraz

C $40

1056Online estate

agency11

Vincent Radebe

A $60

1056Online estate

agency17

Monique Williams

B $50

Page 66: Section 08 - REVIEW

Normalization• Practice 03• 2NF Cont’d

Project number

Project name

1023 Madagascar travel site

1056 Online estate agency

PROJECT

Page 67: Section 08 - REVIEW

Normalization• Practice 03• 2NF

Employee number

Employee name

Rate category

Hourly rate

11Vincent Radebe

A $60

12Pauline James

B $50

16Charles

RamorazC $40

17Monique Williams

B $50

EMPLOYEE

Page 68: Section 08 - REVIEW

Normalization

• Practice 03• 3NF

Employeenumber

Employee name

11 Vincent Radebe

12 Pauline James

16 Charles Ramoraz

17 Monique Williams

EMPLOYEE

Rate category Hourly rate

A $60

B $50

C $40

RATE

Page 69: Section 08 - REVIEW

• De-normalization– De-normalization means combining two

(or more) tables• Usually done when tables are

frequently joined– De-normalization (joining two tables)

depends on usage• Depends on how applications and

users access the data

De-Normalization

Page 70: Section 08 - REVIEW

• De-normalization is done to improve performance

– Tailors data structures for one specific application’s use

– Improves performance of one type of access at expense of others

De-Normalization

Page 71: Section 08 - REVIEW

De-Normalization

• De-normalization Trade-Offs

Normalization De-normalization

Eliminates update anomalies Improves performance for specific application(s)

Minimizes data redundancy

Supports simpler logic

Provides application-independent database design

Encourages sharing of data

Page 72: Section 08 - REVIEW

• When to De-Normalize– This is EVIL, Do Not Do…– When does de-normalization have

minimal impact?• Data is accessed primarily on a

read-only basis• Data is accessed primarily by one

application

De-Normalization

Page 73: Section 08 - REVIEW

• When to de-normalize

– After database design is done and tables are normalized to 3NF

– After clustering related tables in the same logical container

– After considering trade-offs and usage of data

De-Normalization

Page 74: Section 08 - REVIEW

• Alternatives to de-normalization– Physical placement of data

• Use of container• Can improve performance without

impacting logical design– Selective hardware upgrades

• More main memory, expanded storage, cache storage devices

De-Normalization

Page 75: Section 08 - REVIEW

• Fragmentation – Better alternative to de-normalization– Means breaking one table into two (or

more) tables• Usually done when one table is very

large• Or groups of user almost exclusively

access a subset of data in a table

Fragmentation

Page 76: Section 08 - REVIEW

• Fragmentation can be based on selection or projection– Must be able to reconstruct the

original table – by union or join– Primary key column(s) must be

included in all vertical fragments• Disadvantage is that the user must be

aware of all the fragmented tables

Fragmentation

Page 77: Section 08 - REVIEW

Physical Design

• Physical Database Design– Goals

• Improve performance–By minimizing disk I/O

• Improving management of the data

–By grouping tables that can be managed as a group

Page 78: Section 08 - REVIEW

• Steps in Physical Design Process– Determine which tables can be managed

as a group• Many RDBMSs support the concept of

a Container (Oracle Tablespace, db space, Access uses the .mdb)

–A collection of tables, and indexes

Physical Design

Page 79: Section 08 - REVIEW

– Develop a plan for allocating tables to disk devices• Consider parallel disk controllers• Group tables together that are

frequently joined• Distribute heavily accessed table to

different disk devices–To avoid excessive head movement

on one disk

Physical Design

Page 80: Section 08 - REVIEW

– Build indexes on table columns, based on frequency of use

– Restructure tables if necessary

• Fragment large tables into multiple smaller ones

• De-normalize tables if appropriate

Physical Design

Page 81: Section 08 - REVIEW

• Indexes

– Index is a separate structure (table)

• Points into the data table

• Built on one or more columns in the data table

Physical Design

Page 82: Section 08 - REVIEW

• Comments on Indexing– An index can be built on any column or

combination of columns– An index can be unique or non-unique– An index on the primary key is called the

primary index– Most RDBMSs use an internal row id as

the pointer to the row– Use of the index is transparent to the user

Physical Design

Page 83: Section 08 - REVIEW

• Use of an index

– Provides access to a row based on data value(s)

– Avoids duplicates – only way

– Supports sequential processing on the indexed field

– Improves performance

Physical Design

Page 84: Section 08 - REVIEW

• Use of an index improves performance on Retrieval– Processing an index is more efficient than

processing a table – for reads• Index is usually small, relative to the

table–Can be held entirely in memory

• The smaller the index value, the more entries per block the more likely the index will be in memory

Physical Design

Page 85: Section 08 - REVIEW

• Use of index degrades performance on Updates

– Inserting a row is the source of much disk I/O (overhead)

• Every index on the table must be searched and updated also

Physical Design

Page 86: Section 08 - REVIEW

• Data Types– Depends on the conventions used by a

particular database– ORACLE uses:

• NUMBER• CHAR - Characters

• VARCHAR2 - Characters• DATE/TIME• LOB

Physical Design

Page 87: Section 08 - REVIEW

• NUMBER– Numerical data– Guaranteed to 38 digits accuracy– NUMBER(10) – 10 digits allowed

• CHAR– Character data– Fixed-Length up to 2,000 bytes– Good for 2 or 3 characters– Y/N, T/F, USA/CAN– CHAR(2) – 2 characters allowed

Physical Design

Page 88: Section 08 - REVIEW

• VARCHAR2– Character data– Variable-Length up to 4,000 bytes– VARCHAR2(15) – up to 15 characters

• DATE/TIME– Date & Time data– DATE – DD-MON-YY (Default)– TIME – HH:MN:SE (Default)

Physical Design

Page 89: Section 08 - REVIEW

• LOB– Large OBject data type

• CLOB–Long variable length characters

• BLOB–Binary objects – Video, Sound, Graphics

• BFILE–Reference to an OS file

– Up to 4GB of data per file

Physical Design

Page 90: Section 08 - REVIEW

SQL

• Structured Query Language

– DDL – Data Definition Language

• CREATE

• DROP

• ALTER

Page 91: Section 08 - REVIEW

SQL

• Structured Query Language

– DML – Data Manipulation Language

• SELECT

• INSERT

• DELETE

• UPDATE

Page 92: Section 08 - REVIEW

SQL

• Structured Query Language

– DCL – Data Control Language

• GRANT

• REVOKE

Page 93: Section 08 - REVIEW

SQL

• Primary Key SQL

– PRIMARY KEY (student_ID)

• Foreign Key SQL

– CONSTRAINT student_ID FOREIGN KEY (student_id) REFERENCES Student(student_ID)

Page 94: Section 08 - REVIEW

SQL• Practice 01• Create these Tables with SQL

Student:

Student# Advisor

1022 Jones

4123 Smith

Faculty

Advisor Room Dept

Jones 412 42

Smith 216 42

Registration:

Student# Class#

1022 101-07

1022 143-01

1022 159-02

4123 201-01

4123 211-02

4123 214-01

Page 95: Section 08 - REVIEW

SQL

• Practice 01

• Registration Table

– CREATE TABLE registration

• (Student# NUMBER(5),

• Class# NUMBER(5));

Page 96: Section 08 - REVIEW

SQL

• Practice 01

• Student Table

– CREATE TABLE student

• (Student# NUMBER(5),

• Advisor VARCHAR2(12));

Page 97: Section 08 - REVIEW

SQL

• Practice 01

• Faculty Table

– CREATE TABLE faculty

• (Advisor VARCHAR2(12),

• Room NUMBER(4),

• Dept NUMBER(2));

Page 98: Section 08 - REVIEW

SQL

• Practice 02• Create using SQL

SUPPLIER_ID NAME LOCATION ZIPCODE

10024 Best Buy OH 45502

13467 Circuit City WV 36709

45001 Staples KY 20065

SUPPLIER

Page 99: Section 08 - REVIEW

SQL• Practice 02• Supplier Table

– CREATE TABLE supplier• (Supplier_ID Number(5),• Name

VARCHAR2(20),• Location CHAR(2),• Zipcode Number(5));

Page 100: Section 08 - REVIEW

SQL

• Practice 03

• Create using SQL

PARTS

Part# Part_Name Part_Loc Part_Price

Z143028G Widget 114 100

G45610B Thingy 232 500

WAREHOUSE

WHSE# WHSE_Size WHSE_City WHSE_StateWHSE_Statu

s

114 24000 Rio Grande OH Full

232 3200 Charleston WV Empty

Page 101: Section 08 - REVIEW

SQL

• Practice 03

• Parts Table

– CREATE TABLE Parts

• (Part# VARCHAR2(12),

• Part_Name VARCHAR2(20),

• Part_Loc NUMBER(3),

• Part_Price NUMBER(4));

Page 102: Section 08 - REVIEW

SQL• Practice 03• Warehouse Table

– CREATE TABLE warehouse • (WHSE# NUMBER(3),• WHSE_Size NUMBER(6),• WHSE_City VARCHAR2(15),• WHSE_State CHAR(2),• WHSE_Status VARCHAR2(10));

Page 103: Section 08 - REVIEW

SQL

• Practice 04

• Use SQL to find the following:

– How many people make $10,000 per month

EMPLOYEE

Employee#Employee_Nam

eSalary

1001 Smith 10000

1002 Jones 12000

1003 Thomas 8000

1004 Harrison 9500

Page 104: Section 08 - REVIEW

SQL

• Practice 04

– SQL• SELECT employee#, employee_name,

salary• FROM employee• WHERE salary = 10000;

Employee#Employee_Nam

eSalary

1001 Smith 10000

Page 105: Section 08 - REVIEW

SQL

• Practice 05

• Use SQL to find the following:

– Who makes more than $8000 but less then $10000

EMPLOYEE

Employee#Employee_Nam

eSalary

1001 Smith 10000

1002 Jones 12000

1003 Thomas 8000

1004 Harrison 9500

Page 106: Section 08 - REVIEW

SQL

• Practice 05

– SQL• SELECT employee#, employee_name,

salary• FROM employee• WHERE salary > 8000 AND salary < 10000;

Employee#Employee_Nam

eSalary

1004 Harrison 9500

Page 107: Section 08 - REVIEW

SQL

• Practice 06

• Use SQL to find the following:

– Give me a list of employees and their salaries in alphabetical order?

EMPLOYEE

Employee#Employee_Nam

eSalary

1001 Smith 10000

1002 Jones 12000

1003 Thomas 8000

1004 Harrison 9500

Page 108: Section 08 - REVIEW

SQL

• Practice 06

– SQL• SELECT employee_name Name, salary• FROM employee• ORDER BY employee_name;

Name Salary

Harrison 9500

Jones 12000

Smith 10000

Thomas 8000

Page 109: Section 08 - REVIEW

END REVIEW