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

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

notice

Practical Database Design

“Structuring Your Tables”

by Larry Linson,

presented to the

Microsoft Access SIG of the

North Texas PC User Group

January 12, 2002


notice

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


notice

“Relational”

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

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

• Not from “Relationships”– between Tables


notice

Heading of a Relation

• Label for each attribute Name : Domain

• Name identifies

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


notice

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?


notice

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

the primary key– no “extraneous” information– Invoice

• Invoice Number• Supplier Name• Supplier Phone• Item• Price


notice

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• Sales Rep• State• Customer ID


notice

Third Normal Form

• In practical terms,

• as far as we usually go, and

• sometimes useful to violate

continued from previous slide


notice

There must be only one authoritative source for any

item of information.


notice


notice

and it will force you into a

structured, usable file design


notice

Avoid: Redundancy …

• A BAD IDEA– Wastes resources

– Makes life harder

• because – You have to store multiple copies

– Which is correct?


notice

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


notice

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


notice

Avoid: Repeated Fields

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

• Which students study biology?


notice

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.”


notice

Our Example . . .

• You ask,

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



notice

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.”



notice

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


notice

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


notice

Not Just “Order Information”Customer Name and Number

Bill-To Address

Ship-To Address


. . .

Order Number, Date

Ship Method & Date

Salesperson



notice

Some “Customer” InfoCustomer Name and Number

Bill-To Address

Ship-To Address


. . .

Order Number, Date

Ship Method & Date

Salesperson



notice

Some “Salesperson” InfoCustomer Name and Number

Bill-To Address

Ship-To Address


. . .

Order Number, Date

Ship Method & Date

Salesperson



notice

Repeated “Detail” InfoCustomer Name and Number

Bill-To Address

Ship-To Address


. . .

Order Number, Date

Ship Method & Date

Salesperson



notice

Some Product InfoCustomer Name and Number

Bill-To Address

Ship-To Address

Quantity

. . .

Order Number, Date

Ship Method & Date

Salesperson


Extended PriceProduct, Price


notice

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


notice

Grouping by Intuition

• Salespeople

• Customers

• Orders

• Order Details

• Products


notice

Adding the Training

• Salespeople

• Customers

• Orders

• Order Details

• Products

• Training


notice

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


notice

Try Laying Out Tables

Customers

Products

Order Details

Orders

Salespeople

Training


notice

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


notice

Continue Rearranging

Customers

Products

Orders

Salespeople

Training

A customer can have many orders

A salesperson can have many orders

Order Details


notice


Customers

Products

Order Details

Orders

Salespeople

Training

An order can have many order details


notice


Customers

Products

Order Details

Orders

Salespeople

Training

A product can be in many order details


notice


Customers

Products

Order Details

Orders

Salespeople

Training

A salesperson can take many training classes


notice

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.


notice


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:


notice


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


notice


Customers

Products

Order Details

Orders

Salespeople

Training

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

Junction


notice


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.


notice

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”


notice

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


notice

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


notice

• Thank you for your kind attention

• Please, gently wake your neighbor before leaving

• Come again when you can


notice

Practical Database Design

“Structuring Your Tables”

The End

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

Documents

extended price

order number

data typefirst normal

order forms

class period

item of information

sales people

kind of data