Announcements n Difference between “excused” and “absent” n Office hours next week May not be here Monday Tuesday: 1:00 to 2:00 Wednesday: 10:00 to 11:00 Friday: 1:30 to 2:30 n Questions regarding Syllabus, Class?

The Coffee Roasting Company Phase I Designing the Database

Overview n Apply normalization process to purchasing cycle documents Purchase Order Receiving Report Payment Voucher n Combine three document sub-schemas into overall schema for purchasing cycle

What is a Database? n Collection of data organized into: Tables (similar to a spreadsheet) – typically associated with an object/item of interest such as a customer, product, etc. –Columns represent fields Attributes and characteristics that describe the object/item in the table A customer has a name, address, phone, etc. –Rows represent an instance of each object/item Plow House, Stayton OR, (503)

Database Rules n Only one type of record in each table If put both customers and suppliers in same table, how can you tell a customer from a supplier? If use an “external entity” table for both customers and suppliers, then a field in the table would be used to identify the type of external entity.

Database Rules n Each record (row) in a table must be unique If two rows were exactly the same: Plow House, Stayton OR, (503) –Is this an error – was the record entered twice by mistake –Which record should you use?

Database Rules n Each row within a table should have a primary key Given that each record must be different in some way, how can you easily find a given record? That is, what field should you use to find each different record Plow House, Stayton OR, (503) Plow House, Corvallis OR, (541) Plow House, Bend OR, (503) Hitching Post, Bend OR, (503)

Database Rules n Characteristics of a Primary Key Must be unique for each row in the table Must be stable over the life of the database –Names are not a good choice – names change –Normally assign an ID number or code Hence extensive use of SSN –Internally generated numbers and codes will be unique and will not change Should make sense from a business perspective –Phone number? Easy to use –Starting to use alphanumeric codes instead of numbers

Design of the Database n Purpose: Capture the information off of the Purchase Cycle forms and set up a database that: Allows easy search and manipulation Reduces amount of redundant information Allows for future expansion and modification of data

What is Database Design? n Process of determining the content and arrangement of data needed to support various activities. n Could use a “Common-sense” approach No way to assure that design works as intended n We will use the “Normalization” Model

What is Normalization? n Technique to “optimize” the design of a Relational Database Break large complex table into smaller, simpler tables Ensure that the smaller tables fit back together. –When break a Whole into its Parts, need to be sure you can recreate the Whole from the Parts

What is Normalization? n Must be familiar with business processes Must understand relationships between purchase order, receiving report and payment voucher –Can multiple purchases arrive on the same receiving report? –Can a single purchase arrive on multiple receiving reports? –Can multiple purchases be paid with the same payment voucher? –If multiple shipments are received, when do we pay?

Overview of Normalization n 1NF: Create two-dimensional tables Identify and define relevant data elements Remove repeating groups Select primary key n 2NF: Ensure full functional dependence on Primary Key n 3NF: Remove transitive dependencies

Normalization Rules n No repeating groups Typically occurs when multiple products on single form Each product should occupy a separate row in the table

First Normal Form Purpose n Organize data in table Rows and Columns Allows flexibility for future expansion n Does not reduce redundancy Merely an organization step to set up for normalization Does include specification of the primary keys

First Normal Form Step 1 n Identify and define relevant data elements Usually, do not include calculated fields –Can be easily derived when needed Exception is when need to store information for historical purposes –We will compute the sales price for a product –Once computed and conveyed to the customer, should not change the price –For example, the underlying base price may change after the order confirmation is sent to the customer

First Normal Form Step 1 – cont’d n As identify fields, define: Data element name Field name within database (normally shorter without spaces or special characters) Type of data to be stored (number, text, date, etc) Size and format of stored data –Number can be integer, single precision, currency, …

First Normal Form Step 1 – cont’d Which items should be included from this form?

First Normal Form Step 2 n Select relevant data elements n Eliminate Repeating Groups Repeating groups occur when multiple items allowed on form –Product name, type, pounds ordered, cost-per- pound are repeated on form Information on each product ordered should be entered into separate row in table

First Normal Form Repeating Groups What information is repeated on this form?

n Information on each product ordered should be entered into separate row in table Note that we can now add multiple products per order by adding rows to the table.

First Normal Form Step 1 n Select relevant data elements n Eliminate Repeating Groups Each product ordered is entered into separate row in table n Select Primary Key Combination of values within certain columns used to distinguish one row from another

Select Primary Key n On forms with repeating information (products): Need one component of key to identify information in the non-repeating section –Top portion of PO form Need one component of key to identify information in the repeating section –Bottom portion of PO form

First Normal Form Select Primary Key Which fields to use? Non-repeating, Repeating

Select Primary Key n Need to develop a product code to use instead of product name Internally assigned, so we know they are unique and stable As new products are added, we will assign new codes Easy to use –First letters of product name

Select Primary Key n Pick combination of: Purchase Order Number –internally assigned, unique Product Code –internally assigned, unique

Purchase Order Form in First Normal Form n PONum and ProdCode will be primary key n No repeating columns of information

Second Normal Form n Only required if primary key is “concatenated” Combination of data elements used in key n Technical definition is Full Functional Dependence All components of key are needed to identify each non-key field in the table n Purpose: Reduce redundancy & eliminate modification anomalies What happens if need to change delivery date of PO ?

Second Normal Form n Identify all possible combinations of Primary Key Components PONum + ProdCode PONum ProdCode n For each non-key data element, determine which combination of key components is needed for unique identification May need to look through multiple documents to understand relationships

Second Normal Form Which non-key fields are functionally dependent on PONum? ProdCode? Combination?

Business Process Assumptions n Unit Cost is negotiated Note cost difference between and

Second Normal Form n PO Products – Combination of PONum & ProdCode is primary key. All non-key fields have full functional dependence on PONum & ProdCode? –Do we always order 400 pounds of GA?

Second Normal Form n Products – ProdCode is primary key. All non-key fields have full functional dependence on ProdCode

Second Normal Form n PO Details – PONum is primary key. All non-key fields have full functional dependence on PONum

Third Normal Form n Remove Transitive Dependencies Technical definition: a non-key field has functional dependence on a non-key field Non-Technical: Fields A, B and C where A is key. –By definition, B and C have dependence on A –What if you could also determine C based on knowledge of B

Transitive Dependency Example –Supplier name is not part of key, yet name can be used to determine sales office, contact, and phone Assuming one contact per supplier

Solution - split Supplier Information into another table n When create supplier table, must select a primary key Name is not a good choice for the key n Create an internally assigned Supplier Code

Transitive Dependency Another problem – Ship Office –Droubi’s has two shipping offices – name/code does not uniquely identify shipping office – need separate table

Solution - split Supplier Shipping Information into another table n Create supplier shipping code

Third Normal Form Tables

Still have a transitive dependency

Transitive Dependency n Does Zip Code determines City and State?

Third Normal Form Tables

n One-to-Many Relationships Single-field primary key always has cardinality of One Multiple-field primary key has cardinality of Many Non-key field that is part of a relationship has cardinality of Many

Receiving Report n First Normal Form Select and define data elements of interest Eliminate repeating groups Identify primary key Specify any assumptions you had to make.

Business Process Assumptions n Only one receiving warehouse n Do we need to assume that the quantities received are the same as quantities ordered?

Eliminate Repeating Groups n Multiple data elements for: Product Name Product Type Quantity Received n Place each “Product” in separate row

Identify Primary Key n Select data element from top (non-repeating) and bottom (repeating) n Best Key: Combination of: RRNumber Product Code –Created for each product

Second Normal Form n Is the FNF table in Second Normal Form? Why or why not? n If not, what are the functional dependencies? n What business process assumptions did you make?

Second Normal Form n Required since primary key is concatenated n Three Combinations RRNum ProdCode RRNum + ProdCode

Third Normal Form n Are the SNF tables in Third Normal Form? Why or why not? n If not, what are the transitive dependencies? n What business process assumptions did you make?

Third Normal Form n From business perspective: Makes sense to put supplier information in separate table -- reduces redundancy n From Normalization perspective: Transitive dependence between: –RRNum –Supplier Name –Supplier Ship Address, CSZ Will also deal with transitive dependence between zip and city state

Practice Exercise

Payment Voucher n First Normal Form Select and define data elements of interest Eliminate repeating groups Identify primary key Business Process Assumptions

Second Normal Form n Is the FNF table in Second Normal Form? Why or why not? n If not, what are the functional dependencies? n What business process assumptions did you make?

Third Normal Form n Are the SNF tables in Third Normal Form? Why or why not? n If not, what are the transitive dependencies? n What business process assumptions did you make?

Assignment n Design Third Normal Form Datadase for Order Fulfillment of CRC You must be able to create these reports from data within the tables. –Sales Order Confirmation –Bill of Lading –Backorder Notice Focus on the data, not the process –Do not worry about what triggers the Backorder Notice, just be able to create the report from the underlying tables

Assignment  Once you have designed the tables:  Use Access to document the relationships between the tables and as your data dictionary  Create empty tables in Access  Enter the abbreviated field names, specify the data type and size, enter the long name as the caption  Set the primary key fields

Assignment  Use the “relationships” feature in Access to define the relationships between tables  Always set to enforce referential integrity

Assignment  Provide a description of the processes that you used to design the third normal form tables. Specifically:  You must justify your selection of fields for the primary keys  You must describe how you know that each table is in third normal form.  Provide all assumptions you had to make regarding the nature of the business operations to support the placement of the various data elements within the tables.

Questions?