File and data base File and data base conceptsconcepts

DB design

Webcast will coverWebcast will cover

DatabasesDatabases EntitiesEntities Basic ERDBasic ERD PK & FKPK & FK Basic Database DesignBasic Database Design

DB: subsystemsDB: subsystems

DB logical structures:

hierachicalnetwork

relational

DataBase

OS DBM

DBMS

DDL

DML

User

Applicationprogram

Views, Schema and SubschemasViews, Schema and Subschemas

2

4

5

7

910

12

13

8

1517

1

Types of databasesTypes of databases

HierarchicalHierarchical NetworkNetwork RelationalRelational Object-orientedObject-oriented

DBMSDBMS

Has Two PartsHas Two Parts

DML: Data Manipulation LanguageDML: Data Manipulation Language DDL: Data Definition LanguageDDL: Data Definition Language

Structured Query Language (SQL)Structured Query Language (SQL)

SyntaxSyntax

SELECT col namesSELECT col names

FROM tablenamesFROM tablenames

WHERE conditionsWHERE conditions

ExampleExampleEmployee name Job Title Room location Extension

Andazola, Genevieve Secretary, Financial Aid 1-308 2245

Carter, GeorgiaSecretary, Student

Affairs1-224 4716

Durbin,MartinaSecretary, Placement

Service1-110 4235

Ezikian, OliviaSecretary II,Student

Affairs1-224 4714

Hart, Dr. JohnDirector,Placement

Services1-110B 4234

Jacobs, Harry M. Director, Financial Aid 1-308 2244

Jones, MadalenaAssistant Director,

Student Affairs1-224 4715

Smith, Rose Secretary, Admissions 1-104 4823

Wells, Dr.JanetVice-President, Student

Affairs1-224 4713

York, Richard Director, Admissions 1-104 4822

SQLSQLEMPLOYEE (EMPLOYEE_NAME, JOB_TITLE, ROOM_LOCATION, EMPLOYEE (EMPLOYEE_NAME, JOB_TITLE, ROOM_LOCATION, EXTENSION)EXTENSION)

Ex: get the names of all employeesEx: get the names of all employees

SELECT employe_enameSELECT employe_ename

FROM EMPLOYEE;FROM EMPLOYEE;

Ex: Get employee information that have location Ex: Get employee information that have location I-308I-308

Select * FROM EMPLOYEESelect * FROM EMPLOYEE

WHERE ROOM_LOCATION = ‘I-308’;WHERE ROOM_LOCATION = ‘I-308’;

PRIMARY KEY (PK)PRIMARY KEY (PK)

a unique identifier a unique identifier

guarantees that each row of a guarantees that each row of a relation can be uniquely relation can be uniquely addressedaddressed

BANK ACCOUNTBANK ACCOUNT

( ss#, cust name, cust address)( ss#, cust name, cust address)

What’s the PK?What’s the PK?

BANK ACCOUNT( ss#, cuts name, cust BANK ACCOUNT( ss#, cuts name, cust address)address)

SS# can be a PK since it can not repeat in SS# can be a PK since it can not repeat in this tablethis table

What happens if we add cust_account to this What happens if we add cust_account to this tabletable

BANK ACCOUNT( ss#, cuts name, cust BANK ACCOUNT( ss#, cuts name, cust address, address, cust-account)cust-account)

BANK ACCOUNT( ss#, cuts name, BANK ACCOUNT( ss#, cuts name, cust address, cust-account)cust address, cust-account)

ss# can NOT be a PK if we assume a customer can ss# can NOT be a PK if we assume a customer can have multiple accountshave multiple accounts

For customer smith Table may look likeFor customer smith Table may look like111-11-1123111-11-1123 smithsmith UBUB CHK112CHK112111-11-1123111-11-1123 smithsmith UBUB SAV123SAV123

Note now ss# can NOT be a PK since ss# values are Note now ss# can NOT be a PK since ss# values are repeatingrepeating

this violates the definition of PK, it returns two this violates the definition of PK, it returns two rows!!!!rows!!!!

BANK ACCOUNT( ss#, cuts name, BANK ACCOUNT( ss#, cuts name, cust address, cust-account)cust address, cust-account)

Can cust-account can be a PK?Can cust-account can be a PK?

Only if two customers can NOT share the Only if two customers can NOT share the same account, i.e., no joint accountsame account, i.e., no joint account

BANK ACCOUNT( ss#, cuts name, BANK ACCOUNT( ss#, cuts name, cust address, cust-account)cust address, cust-account)

PK must be a combination of TWO PK must be a combination of TWO attributesattributes

In this case In this case SS# and cust-account SS# and cust-account

Should be PK for this relationShould be PK for this relation

FKFK

Relates two tablesRelates two tables Used to maintain INTEGRITY Used to maintain INTEGRITY

(cross reference)(cross reference)

An attribute in ONE table must An attribute in ONE table must match values in another table match values in another table where that attribute is a PKwhere that attribute is a PK

VENDOR and PRODUCT tablesVENDOR and PRODUCT tables

VENDOR (VENDOR (Vend_CODEVend_CODE, VEND_CONTACT, , VEND_CONTACT, VEND_ADDRESS, VEND_PHONE)VEND_ADDRESS, VEND_PHONE)

PRODUCT (PRODUCT (PROD_CODEPROD_CODE, PROD-DESCRIPTION, , PROD-DESCRIPTION, PROD_PRICE, PROD_ON_HAND, PROD_PRICE, PROD_ON_HAND, VEND_CODEVEND_CODE))

Red implies PK for each table Red implies PK for each table Purple key is PRODUCT table is FK to VENDOR Purple key is PRODUCT table is FK to VENDOR

tabletable

EntitiesEntities

An object of interestAn object of interest PersonPerson PlacePlace EventEvent ConceptConcept

Ex: Ex: StudentStudentOrderOrderCustomerCustomer

RelationshipRelationship

Exists between entitiesExists between entities

With entity itselfWith entity itself

Binary between TWO entitiesBinary between TWO entities

Ternary between THREE entitiesTernary between THREE entities

Relationship among entitiesRelationship among entities

Assume: A team can have many players and Assume: A team can have many players and a player can play for ONLY ONE teama player can play for ONLY ONE team

TEAM PLAYERTEAM PLAYER

TEAM-------TEAM------- > PLAYER > PLAYER

Relationship?Relationship?

STUDENT CLUBSTUDENT CLUB

Can a student belong to many clubs? Can a student belong to many clubs? Yes then 1:mYes then 1:mCan a club have many student members? Can a club have many student members? Yes then 1:nYes then 1:n M:NM:NSTUDENT <STUDENT <---------------->CLUB>CLUB

DB Design ConceptsDB Design Concepts

ENROLLMENTENROLLMENT

((SID, SNAME, SADD,CID,CNAME,GRADE,SEMESTER)SID, SNAME, SADD,CID,CNAME,GRADE,SEMESTER)

how to represent entities and relations

112 Smith,J UB INSS640 MIS Sp06

112 Smith,J UB INSS651 DBMS Sp06

112 Smith,J UB MGMT600 Leadership Sp06

113 Mary,K TOWSON INSS640 MIS Sp06

113 Mary,K TOWSON MGMT600 Leadership B F05

114 Chao, P TOWSON INSS640 MIS B F05

Data RedundancyData Redundancy

Remove redundancyRemove redundancy

STUDENT (SID,SNAME,SADD)CLASS(CID,CNAME)GRADE (SID,CID,GRADE,SEMESTER)

DB Design principlesDB Design principles NORMALIZATION:

1. represent each ENTITY as a TABLE

2. select the PRIMARY KEY

3. assign entity ATTRIBUTES to FIELDS

4. represent an ONE-TO-MANY relation by a FOREIGN KEY in the MANY table.

5. represent MANY-TO MANY relations as a NEW TABLE. Use FOREIGN KEYS to identify entities involved. The combination of foreign keys is the PRIMARY KEY of the new table. Assign the common attributes to fields.