© copyright 2002, 2005, 2013 l. m. linson, may be freely used with this notice practical database...

© Copyright 2002, 2005, 2013 L. M. Linson, may be freely used with this notice

Practical Database Design

“Structuring Your Tables”

by Larry Linson,

presented (again) to the

Microsoft Access SIG of the

North Texas PC User Group

June 15, 2013


Purpose• Laying out or structuring tables

– in an Access (or other relational) database

• Without formal data modeling• Without becoming a relational

database expert• Accomplishing results with

– common sense– intuition


“Relational”

• “Relation” = Table– Rows (“Tuples”) and

– Columns (“Attribute”)• Scalar means one value per …

• Not from “Relationships”– between Tables

You don’t need to rememberall this. It’s just so you’ll havea feel for what the person issaying when they try toimpress you with their ‘superior knowledge.”


Heading of a Relation

• Label for each attribute Name : Domain

• Name identifies

• Domain = kind of data (not the data type)



First Normal Form

• If domains are scalar– one item of information per

attribute

– some questionable, e.g., dates• clearly consist of parts• depends on problem space• do you need to use the parts?



Second Normal Form • In First Normal Form and • If all attributes dependent on

the primary key– no “extraneous” information– Invoice

• Invoice Number (primary key)• Supplier Name• Supplier Phone (not related to Invoice Number)• Item• Price



Third Normal Form . . .

• In Second Normal Form and • If all attributes are mutually

independent– violation example,

• If one Sales Rep per State

– Order• Order ID (primary key)• Sales Rep• State (dependent on Sales Rep or Customer ID)• Customer ID



Third Normal Form

• In practical terms,

• as far as we usually go, and

• sometimes useful to violate

continued from previous slide



There must be only one authoritative source for any

item of information.

This one you shouldremember. It will helpto keep you out of trouble.


and it will force you into a

structured, usable file design


Avoid: Redundancy …

• A BAD IDEA– Wastes resources

– Makes life harder

• because when a change– You have to store multiple copies

– Which is correct?


Avoid: Redundancy …• Even worse if

– in two or more tables

• because – not only how many records to

change

– but how many places to look for it


Avoid: Composite Fields

• Concatenating is easy– [Title] &[First] & [Mid] & [Last] & [Suf]

• Extracting isn’t so easy– “Umm? How?” he pondered,

• scratching his head and staring


Avoid: Repeated Fields

• One record w/ repeat– [Student] – [Period 1 Class]– [Period 2 Class]– . . . – [Period 6 Class]

• Which students study biology?


Our Example . . .

• A friend, client, or employer says,

–“Our order-taking process is a little clumsy. I’d like you to create a database to smooth it out and make it quicker for the sales people.”


Our Example . . .

• You ask,

–“What, exactly, do you want in that database?”



Our Example

• Friend, client, employer responds,

–“Here’s one of our order forms. Too, I’d like to keep track of the product training courses our sales people have to take. Please make a prototype to suggest what I need.”



An OrderCustomer Name and Number

Bill-To Address

Ship-To Address

Quantity, Product, Price, Extended Price

. . .

Order Number, Date

Ship Method & Date

Salesperson

Subtotal, Tax, Shipping, Total


Better than we might expect

• Suggests the information

• Seems to group the information, too

• Natural and intuitive– Sales staff used to it– Likely refined over years

• Try using it to group the information– Then make tables for each group


Not Just “Order Information”Customer Name and Number

Bill-To Address

Ship-To Address


. . .

Order Number, Date

Ship Method & Date

Salesperson



Some “Customer” InfoCustomer Name and Number

Bill-To Address

Ship-To Address


. . .

Order Number, Date

Ship Method & Date

Salesperson



Some “Salesperson” InfoCustomer Name and Number

Bill-To Address

Ship-To Address


. . .

Order Number, Date

Ship Method & Date

Salesperson



Repeated “Detail” InfoCustomer Name and Number

Bill-To Address

Ship-To Address


. . .

Order Number, Date

Ship Method & Date

Salesperson



Some Product InfoCustomer Name and Number

Bill-To Address

Ship-To Address

Quantity

. . .

Order Number, Date

Ship Method & Date

Salesperson


Extended PriceProduct, Price


And the rest is “Order Info”Customer Name and Number

Bill-To Address

Ship-To Address

Quantity

. . .

Order Number, Date

Ship Method & Date

Salesperson


Extended PriceProduct, Price


Grouping by Intuition

• Salespeople

• Customers

• Orders

• Order Details

• Products


Adding the Training

• Salespeople

• Customers

• Orders

• Order Details

• Products

• Training


Sales Database Information – The Intuitive Approach

• Salespeople sell products to customers• Customers purchase products• Orders record a customer purchase• Order Details show products, quantities• Products are what is sold, with price• Training (Product information) for

Salespeople


Try Laying Out Tables

Customers

Products

Order Details

Orders

Salespeople

Training


Rearrange by Relationship

Customers

Products

Orders

Salespeople

Training

(use real-world relationships)

There’s a customer for every order

There’s a salesperson for every order

Order Details


Continue Rearranging

Customers

Products

Orders

Salespeople

Training

A customer can have many orders

A salesperson can have many orders

Order Details



Customers

Products

Order Details

Orders

Salespeople

Training

An order can have many order details



Customers

Products

Order Details

Orders

Salespeople

Training

A product can be in many order details



Customers

Products

Order Details

Orders

Salespeople

Training

A salesperson can take many training classes


Did We Forget Something?

Customers

Products

Order Details

Orders

Salespeople

Training

Many salespeople can be in a training class

Maybe! Depends on what we may need to do.



Customers

Products

Order Details

Orders

Salespeople

Training

Many salespeople can have taken a training class or many can be in a session of a class.

No, let’s revise that statement:



Customers

Products

Order Details

Orders

Salespeople

Training

Many salespeople can have taken a training class or many can be in a session of a class.

If the first, then we have a many-to-many



Customers

Products

Order Details

Orders

Salespeople

Training

If we have a many-to-many, to implement we need a junction or intersection table

Junction



Customers

Products

Order Details

Orders

Salespeople

Training

Many salespeople can have taken a training class or many can be in a session of a class.If our data model requires the second, then

we need another table for sessions.


How Many Levels

• Take to as many levels of detail– as you need to represent what you need to

“model”

• A database is merely a model– of the real world– detailed enough to satisfy the needs

• and deal with the business “issue”– we don’t have “problems” any more, only “issues”– or, perhaps, “opportunities”


How Many Levels?

• Einstein is supposed to have said, “As simple as possible, but no simpler.”

• Too simple, and you don’t satisfy the purpose

• Not simple enough, it will be “cumber-some” and you have to work too hard to satisfy the purpose


What did he say

• Look at what is needed

• You are “modeling” the real world

• Base on “real world” activity, data

• Organize for what you need

• Look for natural groupings

• Look for natural relationships

• Review with the user


• Thank you for your kind attention

• Please, gently wake your neighbor before leaving

• Come again when you can


Practical Database Design

“Structuring Your Tables”

The End

© copyright 2002, 2005, 2013 l. m. linson, may be freely used with this notice practical database...

Documents

normal form

superior knowledge

person issaying

youll havea

tablesyou dont

data typeyou dont

class period

previous slideyou dont