Directory listing of http: uap.unnes.ac.id ebook biblebook Visual Basic 6 com & Library Books
3
C H A P T E R
Designing a
Relational
Database
✦
✦
✦
✦
In This Cha pter
Stating the pro blem
Brainsto rming
I
n this c hapter, I’m go ing to sho w yo u the way I design a
database. While I’ll use SQL Server to o ls in this c hapter,
the same c o nc epts c an be applied to any database system.
The key to using this appro ac h is to understand the tec hniques I’m go ing to sho w yo u and adapt them so that they
wo rk fo r yo u.
Overview of the Design Process
Designing a relatio nal database c an be as easy o r as hard as
yo u c ho o se to make it. I generally use a seven-step appro ac h
as o utlined belo w:
1. Stating the pro blem
2. Brainsto rming fo r ideas
3. Mo deling entities and relatio nships
4. Building the database
5. Creating the applic atio n
I’m go ing to disc uss the first fo ur steps in this c hapter. The
rest o f this bo o k will fo c us o n step five.
CrossReference
See Chapter 2 for inform ation about the relational
database m odel.
Mo deling entities
and relatio nships
Building the database
✦
✦
✦
✦
32
Part I ✦ Database Programming Fundamentals
Stating the Problem
While stating the pro blem may seem easy, it’s a lo t harder than it lo o ks. The pro blem
statement sho uld present an understanding o f what the o rganizatio n is trying to
ac c o mplish, while at the same time trying to emphasize the mo st c ritic al business
needs. If yo u want to replac e an existing applic atio n, yo u c an use that applic atio n as
a basis fo r the answer. But if yo u are building an applic atio n fo r the first time, it is
very impo rtant to understand what pro blem yo u’re trying to so lve. After all, if yo u
c an’t identify the pro blem, ho w are yo u go ing to kno w if yo u really so lved it?
The pro blem sho uld be stated as simply as po ssible. Fo r example, if the peo ple at
Amazo n.c o m were to state their pro blem, it might lo o k like this: we want to establish Amazo n.c o m as a brand name by selling bo o ks to c o nsumers via the Internet
at the lo west po ssible c o st to the c o nsumer and with the best po ssible servic e,
while building market share that will ensure the lo ng-term stability o f the c o mpany.
A spec ialty mail-o rder c atalo g c o mpany might want to so lve this pro blem: we want
to impro ve ho w we take c usto mer o rders o ver the telepho ne to reduc e mistakes
and impro ve servic e to o ur c usto mers. A small elec tro nic s supplier might state
their pro blem in this way: we need to impro ve o ur invento ry c o ntro l to inc rease
the number o f times the invento ry is turned o ver eac h year and to prevent sto c kpiles o f o bso lete items. In this bo o k, I’m go ing to use a c o mmo n database fo r all o f
the examples I c reate. I’ll also update an applic atio n I wro te a few years ago c alled
Car Co llec to r, whic h trac ks a c o llec tio n o f to y c ars. Sinc e I o riginally wro te this
pro gram, the Internet has bec o me very impo rtant to c o llec to rs. Web sites like
eBay make it muc h easier fo r peo ple to buy and sell c o llec tibles. In fac t, my wife
likes to buy and sell c o llec tible do lls and has been asking me to build her a versio n
o f Car Co llec to r that is targeted at the do ll market.
Taking this info rmatio n into c o nsideratio n, I c an state my pro blem like this: I want
to update Car Co llec to r to inc lude suppo rt fo r o ther types o f to ys and c o llec tibles
and add suppo rt fo r trading to ys with o ther c o llec to rs o ver the Internet. With the
new features I’m go ing to add, I’m go ing to c hange the name o f the applic atio n to
To y Co llec to r.
Note
It’s almost realistic: Toy Collector as used in this book isn’t m eant to be a com plete application, but rather a fram ew ork for show ing you different techniques for
building database applications in Visual Basic. Therefore, the database design m ay
not be as com plete as a com m ercial application, nor w ill all of the features found
in the com m ercial application be present in Toy Collector. Som e of the data structures I use, as w ell as the features included in the application, m ay seem like
overkill, but they are necessary to illustrate various points along the w ay. So, focus
on the techniques that I’m going to show you and try to understand w hy and how
I do things, rather than focusing on w hy this feature w as added or w hy that inform ation is m issing.
Chapter 3 ✦ Designing a Relational Database
Brainstorming
Onc e yo u have a basic understanding o f the pro blem yo ur applic atio n needs to
so lve, yo u need to design the database to ac c o mmo date the info rmatio n related to
yo ur applic atio n. The first step in this pro c ess it to take a lo o k at yo ur pro blem and
try to determine all o f the info rmatio n and func tio ns that might be needed to so lve
the pro blem. I c all this step brainsto rming.
Brainsto rming is the ac t o f disc ussing and rec o rding ideas witho ut regard to ho w
feasible they are to implement. This helps yo u identify all o f the info rmatio n yo u
need to keep and all o f the tasks yo ur applic atio n will need to perfo rm.
I like to c o nduc t brainsto rming sessio ns that inc lude everyo ne who will be invo lved
with the pro jec t in a single ro o m with a white bo ard. It helps to have as wide a range
o f peo ple present as po ssible. Everyo ne fro m end users, to pro grammers, to management sho uld be invo lved in this pro c ess.
Every idea that is raised sho uld be listed o n the white bo ard, even if it’s similar to
an idea that’s already listed. After the meeting, the info rmatio n sho uld be o rganized, and similar ideas c an be c o mbined as a single item. The ideas sho uld be c lassified as either a task that the applic atio n sho uld perfo rm o r a piec e o f info rmatio n
that will need to be kept.
It’s impo rtant to understand that so me o f the ideas that c o me o ut o f the brainsto rming sessio n may no t be prac tic al. At this stage o f the pro c ess, yo u sho uldn’t
wo rry abo ut prac tic ality. It is far mo re impo rtant to be c o mplete. So metimes things
that seem imprac tic al at this stage may pro ve easy to implement later, while o ther
ideas that seem easy to implement at first may no t pro ve to be wo rth the time and
effo rt.
Also , it’s impo rtant no t to make fun o f any ideas, no matter ho w bad they seem.
This is espec ially true fo r ideas c o ming fro m the less tec hnic al attendees. Quite
o ften, their ideas and c o mments may lead to a better understanding o f ho w the
applic atio n sho uld wo rk.
Brainstorming Toy Collector
Sinc e yo u c an’t ac tively partic ipate in the brainsto rming sessio n, I sat do wn and
held o ne myself, and c ame up with the fo llo wing list o f func tio ns that need to be
perfo rmed by To y Co llec to r applic atio n:
✦ Trac k items c urrently in the c o llec tio n
✦ Create repo rts o f items in the c o llec tio n
✦ Lo c ate a to y in the invento ry
33
34
Part I ✦ Database Programming Fundamentals
✦ Keep a mailing list o f c urrent and po tential c usto mers
✦ Create a Web page with a list o f items c urrently fo r sale
✦ Create a Web page with a list o f items wanted
✦ Create an HTML listing fo r eBay
✦ Evaluate the c o nditio n o f a to y
✦ Trac k purc hases and sales
✦ Pro c ess an o rder that sells o ne o r mo re to ys to a c usto mer
✦ Pro c ess an o rder that purc hases a to y fro m a c usto mer
The func tio ns will be used to maintain a database c o ntaining the fo llo wing data
elements:
✦ To y name
✦ Date o rdered
✦ Manufac turer
✦ Date rec eived
✦ Desc riptio n
✦ Date shipped
✦ Year the to y was built
✦ Credit c ard number
✦ Value
✦ Expiratio n date
✦ Pric e paid
✦ Custo mer name
✦ Asking pric e
✦ Custo mer’s first name
✦ Co nditio n
✦ Custo mer’s last name
✦ Co nditio n questio ns
✦ Custo mer’s middle initial
✦ Type o f to y
✦ Custo mer’s address
✦ Order info rmatio n
✦ Custo mer’s c ity
✦ Shipping c o st
✦ Custo mer’s state
✦ Sales tax
✦ Image o f the c o llec tible
Reviewing the results
After c o nduc ting the b rainsto rming sessio n, yo u need to review the info rmatio n
yo u c o llec ted and try to eliminate duplic ate info rmatio n and make sure that the
info rmatio n yo u have is c o mplete. Quite o ften while yo u c o nduc t this review,
yo u’ll realize that o ther related info rmatio n might b e useful and sho uld b e added
to the list.
Chapter 3 ✦ Designing a Relational Database
Examining the functions to be performed
Lo o king at the abo ve results, yo u c an see a few c o mmo n threads. First, yo u need an
invento ry system that trac ks all o f the to ys in the c o llec tio n. This is a fairly c o mmo n applic atio n, alo ng with maintaining a mailing list.
The invento ry part o f an applic atio n usually requires a unique identifier fo r an item
in invento ry. This wasn’t inc luded as part o f the o riginal brainsto rming sessio n. In a
traditio nal invento ry system, the quantity o f the item is also inc luded. Ho wever,
due to the fac t that different to ys may have different c harac teristic s based o n their
c o nditio n, I c ho o se to igno re the quantity issue and require that eac h item in the
invento ry must have its o wn unique rec o rd.
Pro c essing o rders isn’t diffic ult. Ho wever, a few mo re items need to be added to
what was already identified abo ve. Fo r instanc e, in o rder to c o mpute sales tax, yo u
need to kno w the sales tax rate. Fo r the purpo ses o f this bo o k, I’m go ing to assume
that the sales tax rate is unifo rm ac ro ss a state, even tho ugh this isn’t nec essarily
true. Yo u also need to c apture the c usto mer’s name o n the c redit c ard, sinc e it may
be different than the name they entered into yo ur database. There sho uld also be
an o ptio n to ship to an alternate destinatio n, rather than a regular mailing address.
The mailing list is pretty straightfo rward, exc ept that yo u sho uld give the c usto mer
the o ptio n to no t rec eive mail. This is impo rtant, bec ause even in to day’s marketplac e, peo ple will c o mplain abo ut unwanted mail. Also , yo u may want to inc lude
so me additio nal c o mments abo ut the c usto mer that wo uld let the user rec o rd pro blems that they may have had during previo us transac tio ns.
The c usto mer’s name is ac tually listed twic e: o nc e as simply name, and ano ther
time as first, middle, and last names. Whic h way is best really depends o n yo u.
Having a separate last name field makes it easy to searc h o n so meo ne’s last name.
Ho wever, using a single field lets yo u fo rmat a name mo re naturally, whic h is impo rtant when yo u have peo ple that have suffixes suc h as Ph.D., Junio r, Senio r o r III. It
also allo ws so meo ne to enter a title suc h as Mr., Ms., Dr., etc . with fewer pro blems.
In the lo ng run, it really do esn’t matter whic h metho d yo u pic k as lo ng as yo u’re
c o nsistent thro ugho ut yo ur database.
Evaluating the c o nditio n o f a to y c an be a fairly c o mplex pro c ess. One metho d is to
assign the to y a po int value, assuming that it’s in mint c o nditio n. Then yo u wo uld
ask a series o f questio ns abo ut spec ific flaws that are po ssible in the to y. Depending
o n the respo nse, po ints will be deduc ted fro m the maximum sc o re. The resulting
sc o re c an then be mapped o nto c o nditio n value, whic h in turn allo ws yo u to determine the true value o f the to y. Sinc e the questio ns c an vary by the type o f to y, additio nal info rmatio n is needed to determine the type o f to y and the questio ns that will
be used to determine the to y’s o verall c o nditio n.
35
36
Part I ✦ Database Programming Fundamentals
M apping the results to data types
The last step o f the brainsto rming sessio n is to map the data elements o nto a series
o f data types. After reviewing the brainsto rming info rmatio n, I like to assemble a
list o f the data elements that were derived fro m the sessio n, alo ng with Visual Basic
data type and a sho rt desc riptio n o f the elements, suc h as tho se sho wn in Table 3-1.
Table 3-1
Data Elements
Data Element
Data Type
Description
Custom erNam e
String
The nam e of the custom er.
Street
String
The street on w hich the custom er lives.
City
String
The city w here the custom er lives.
State
String
The state w here the custom er lives.
Zip
String
The proper ZIP code for the custom er’s address.
Phone
String
The custom er’s telephone num ber.
EMailAddress
String
The custom er’s e-m ail address.
MailingList
Boolean
True if the custom er w ants to receive periodic
notices.
OrderNum ber
Long
A num ber that uniquely identifies the order.
OrderStatus
String
The current status of the order.
DateOrdered
Date
The date the order w as placed.
DateShipped
Date
The date the order w as m ailed.
ShippingCost
Currency
The cost to ship the order.
SalesTax
Currency
The am ount of sales tax collected.
CreditCardNum ber
String
The credit card num ber used to purchase a toy.
ExpirationDate
String
The expiration date on the credit card.
InventoryId
Int
A unique identifier for an item in the collection.
ToyNam e
String
The nam e of the collectible toy.
Manufacturer
String
The toy’s m anufacturer.
ToyType
String
The type of toy.
ToyDescription
String
A description of the toy.
Chapter 3 ✦ Designing a Relational Database
Note
Data Element
Data Type
Description
MintValue
Currency
The value of the toy if it w as in m int condition.
Condition
Long
A num eric description of the toy’s condition.
Question
String
A question used to evaluate a toy’s condition.
TrueValue
Currency
The true value of the toy based on its condition.
DatePurchased
Date
The date the toy w as purchased.
Im age
Picture
A picture of the toy.
US first: When building an e-com m erce application, one of the first things you
need to plan for is how to handle international issues. For the m ost part, the only
w ay these issues w ould affect your database design is that additional data elem ents, such as Country and CurrencyType, w ould need to be included, plus you
w ould need to allow additional space for other fields such as ZIP code. Just
because I don’t include these fields in Toy Collector isn’t a good reason for you not
to include them in your application.
M odeling Entities and Relationships
The next step in the pro c ess is translating the info rmatio n fro m the brainsto rming
sessio n into a database design.
Entity/ relationship modeling
Entity/Re latio nship mo de ling ( also kno wn as E/ R mo deling) is a way o f desc ribing
the re latio nship between e ntitie s. An entity is a thing that c an be uniquely identified, suc h as a to y, a c usto mer, o r an o rder. Asso c iated with the entity is a set o f
attributes, whic h helps to desc ribe the entity. Eac h c usto mer has a name and an
address. Eac h to y has a name and a manufac turer. An o rder has an o rder number
and a date o rdered. Relatio nships are fo rmed between two entities, suc h as c usto mers and o rders, where a c usto mer plac es an o rder fo r a to y.
When drawing an E/ R mo del, I use rec tangles fo r entities, ellipses fo r attributes,
and diamo nds fo r relatio nships. In Figure 3-1, yo u c an see a simple E/ R mo del that
has two entities ( Custo mers and Orders) , with eac h entity having two attributes
( Custo mers-Address and Name, Orders-Order Number and Date Ordered) and a
single relatio nship ( Custo mer-Order) .
37
38
Part I ✦ Database Programming Fundamentals
Address
Customers
Name
Customer-Order
Order Number
Orders
Date Ordered
Figure 3-1: Designing a sim ple database using an E/ R m odel.
Identifying entities and attributes
The first step in this pro c ess is to review the list o f data elements fo und in Table
3-1 and lo o k fo r c o mmo n gro upings. As yo u sc an thro ugh the list o f data elements,
three main gro upings jump o ut almo st immediately: c usto mer info rmatio n, invento ry info rmatio n, and o rder info rmatio n. Eac h o f these gro upings represents a
majo r entity in the To y Co llec to r database.
At the same time, yo u need to lo o k at the vario us entities and their attributes fro m
an implementatio n po int o f view. Yo u may find that a few o ther attributes are easy
to inc lude and will add value to the applic atio n fro m the user’s po int o f view.
Tip
Dirt cheap disk drives: If you designed a database years ago, you w ill rem em ber
that disk space w as very expensive, and you alw ays tried to use the least am ount
of space possible. In today’s m arketplace, you can purchase a high-perform ance 9gigabyte SCSI disk drive for less than $500. If you allow 2,000 bytes for each custom er (w hich is very generous), you can store over 4 m illion custom ers on a single
disk drive. Since m ost applications w on’t store this m uch data, don’t let the cost of
disk space drive your database decisions.
Customer information
Table 3-2 c o ntains the list o f data elements that are related to a c usto mer, plus a few
mo re that po pped up while assembling the list. Finding so me additio nal data elements at this stage is quite no rmal, sinc e we no w have a better understanding o f
the applic atio n’s needs. In this c ase, I added fields to identify when the c usto mer
Chapter 3 ✦ Designing a Relational Database
was o riginally added to the database (DateAdded) and the last time the info rmatio n
was updated (DateUpdated). I also added a field c alled Co mments that allo ws the
user to rec o rd any c o mments they may have abo ut this partic ular c usto mer.
Table 3-2
Customer Information
Column Name
Data Type
VB Type
Description
Custom erId
Int
Long
A unique identifier for the custom er.
Nam e
Varchar(64)
String
The custom er’s nam e.
Street
Varchar(64)
String
The street address w here the
custom er lives.
City
Varchar(64)
String
The nam e of the city w here the
custom er lives.
State
Char(2)
String
The nam e of the state w here the
custom er lives.
Zip
Int
Long
The ZIP code for the custom er’s
address.
Phone
Varchar(32)
String
The custom er’s phone num ber.
Em ailAddress
Varchar(128)
String
The custom er’s e-m ail address.
DateAdded
Datetim e
Date
The date the custom er w as added to
the database.
DateUpdated
Datetim e
Date
The date the custom er’s inform ation
w as last updated.
MailingList
Bit
Boolean
When true m eans that the custom er
w ishes to receive periodic m ailings.
Com m ents
Varchar(256)
String
Com m ents about the custom er.
Inventory information
The info rmatio n abo ut the invento ry is a little mo re c o mplic ated than the c usto mer
info rmatio n. While it is easy to identify the attributes that are direc tly related to an
invento ry item (see Table 3-3), there are a few c ases where so me o f the info rmatio n
isn’t direc tly related. Fo r instanc e, the questio ns that yo u need to ask the user in
o rder to determine the c o nditio n o f a to y are related to the type o f to y, no t the ac tual
to y itself. This implies that ano ther entity c alled To yTypes (see Table 3-4) will be
needed to ho ld info rmatio n abo ut a type o f to y. Also , bec ause there are multiple
questio ns fo r eac h to y type, yo u’ll need yet ano ther entity (Co nditio nQuestio ns) to
ho ld the questio ns (see Table 3-5).
39
40
Part I ✦ Database Programming Fundamentals
Table 3-3
Inventory Items
Column Name
Data Type
VB Type
Description
InventoryId
Int
Long
A unique identifier for the item in the
collection.
ToyTypeId
Int
Long
A unique identifier for the type of toy
in the collection.
Nam e
Varchar(64)
String
The nam e of the toy.
ManufacturerId
Int
Long
The nam e of the m anufacturer w ho
m ade the toy.
YearIssued
Datetim e
Date
The date the toy w as first
m anufactured.
Description
Varchar(256)
String
A description of the toy.
MintValue
Money
Currency
The value of the toy if it is in m int
condition.
Condition
Int
Long
The condition of the toy using a
num eric scale.
ConditionMask
Varchar(64)
String
Answ ers to the condition questions
for this type of toy.
TrueValue
Money
Currency
The true value of the toy based on its
current condition.
DatePurchased
Datetim e
Date
The date the toy w as added to the
inventory.
PurchasePrice
Money
Currency
The am ount of m oney paid for the
toy.
AskingPrice
Money
Currency
The am ount of m oney you are w illing
to sell the toy for. A value of zero
m eans that you aren’t w illing to sell
the toy at this tim e.
BuyingPrice
Money
Currency
The am ount of m oney you are w illing
to pay for a sim ilar toy.
Wanted
Bit
Boolean
If true m eans that you w ant to buy
the toy.
ForSale
Bit
Boolean
If true m eans that you w ant to sell
the toy.
Chapter 3 ✦ Designing a Relational Database
Column Name
Data Type
VB Type
Description
Com m ents
Varchar(256)
Sting
Any com m ents that w ould be
displayed along w ith the toy.
DateUpdated
Datetim e
Date
The m ost recent tim e this
inform ation w as updated.
Table 3-4
Toy Types
Column Name
Data Type
VB Type
Description
ToyTypeId
Int
Long
A unique identifier for the type of toy
in the collection.
Description
Varchar(64)
String
A description of the type of toy.
Table 3-5
Condition Questions
Column Name
Data Type
VB Type
Description
TypeId
Int
Long
A unique identifier for the type of toy
in the collection.
Seq
Int
Long
A sequence num ber that is used to
distinguish betw een m ultiple
questions for a specific type of toy.
Question
Varchar(64)
String
A question used to evaluate the
condition of the toy.
Weight
Int
Long
The relative im portance of the
question w hen determ ining the toy’s
condition.
Responses
Int
Long
The highest possible value of the
response.
So metimes it is useful to c o dify a data value to ensure data c o nsistenc y. A go o d
example o f a field that c an easily get bad data is the Manufac turer field. Co nsider
ho w many different ways so meo ne c an spell Mattel. One way to ensure that the misspelling do esn’t happen is to enc o de eac h to y manufac turer as a numeric value and
41
42
Part I ✦ Database Programming Fundamentals
sto re the numeric value in the database. Then yo u need to add a translatio n table
that c an be used to translate the c o dified value into a text string. This is what the
Manufac turers table ac c o mplishes (see Table 3-6).
Table 3-6
M anufacturers
Column Name
Data Type
VB Type
Description
ManufacturerId
Int
Long
A unique identifier for the nam e of
the m anufacturer.
Nam e
Varchar(64)
String
The nam e of the m anufacturer.
Ano ther area o f c o nc ern is that we need to sto re images fo r the to ys. While I believe
it is ac c eptable fo r yo u to sto re images in a database, I also believe that they sho uld
be sto red in a separate table. Sinc e I need to use a separate table fo r the image, I
dec ided to add a sequenc e number c o lumn that will let me sto re multiple images
fo r a single to y (see Table 3-7).
Table 3-7
Images
Column Name
Data Type
VB Type
Description
InventoryId
Int
Long
A unique identifier for the item in the
collection.
Seq
Int
Long
A sequence num ber that is used to
distinguish betw een m ultiple im ages
for a single toy.
Im age
Im age
Picture
A large binary field that holds the
actual im age of the toy.
Order information
The final majo r entity that I identified in this applic atio n is the Orders entity.
Ho wever, this entity needs to be subdivided so eac h o rder c an have multiple items
in the o rder. Thus, Table 3-8 lists the attributes o f the Orders entity, while Table 3-9
lists the attributes asso c iated with a single item that is in the o rder. I c alled this
entity OrderDetails.
Chapter 3 ✦ Designing a Relational Database
Storing Images in a Database
While m any people recom m end against storing an im age in your database, I believe otherw ise. By storing im ages in the database, it is m uch easier to secure and access them . Storing
im ages outside the database m eans that you have to m aintain a separate security system to
protect the im ages. This can becom e very com plicated if you perm it the im ages to be
accessed both by Web brow ser-based applications and traditional client/ server applications.
While I believe in storing im ages in the database, I also believe that the im ages should be
stored in their ow n table, aw ay from any related data. Database perform ance is based
m ostly on how m uch inform ation you can retrieve w ith a single disk I/ O. The m ore row s
you can retrieve, the better.
In a typical database table, you m ight be able to retrieve anyw here from 10 to 100 row s
w ith a single disk I/ O. How ever, if you include an im age in the table, you m ay find that you
only get one row for each disk I/ O. By m oving the im age to a separate table, the perform ance of the m ain table isn’t com prom ised.
Table 3-8
Orders
Column Name
Data Type
VB Type
Description
OrderId
Int
Long
A unique identifier for the order.
Custom erId
Int
Long
A unique identifier for a custom er.
OrderType
Int
Long
1 = sale, 2 = purchase.
ShippingCost
Money
Currency
The total cost of shipping.
SalesTax
Money
Currency
The total cost of sales tax.
How Paid
Int
Long
1 = credit card, 2 = check.
CreditCardNum ber
Varchar(32)
String
The custom er’s credit card num ber.
ExpDate
Varchar(16)
String
The custom er’s credit card expiration
date.
OrderStatus
Int
Long
1= order placed, 2= order shipped,
3= order received.
DateOrdered
Datetim e
Date
The date and tim e the order w as
placed.
DateShipped
Datetim e
Date
The date and tim e the order w as
shipped.
DateReceived
Datetim e
Date
The date and tim e the order w as
received.
43
44
Part I ✦ Database Programming Fundamentals
Table 3-9
OrderDetails
Column Name
Data Type
VB Type
Description
OrderId
Int
Long
A unique identifier for the order.
Seq
Int
Long
A sequence num ber that is used to
distinguish betw een m ultiple item s
in a single order.
InventoryId
Int
Long
A unique identifier for the item in the
collection.
PurchasePrice
Money
Currency
The am ount paid for the toy.
The last entity I want to talk abo ut is the States entity. This entity exists mo stly to
translate the two -c harac ter state abbreviatio n into a sales tax rate, whic h is used to
c o mpute the amo unt o f sales tax that must be c o llec ted fo r an o rder. At the same
time, I dec ided to add the StateName field to translate State into a mo re meaningful
value.
Table 3-10
States
Column Name
Data Type
VB Type
Description
State
Char(2)
String
The tw o-character abbreviation for a
state.
StateNam e
Varchar(64)
String
The proper state nam e.
SalesTaxRate
Decim al
Currency
The sales tax rate for the state.
Identifying Relationships
Onc e yo u have identified all o f yo ur entities and their attributes, identifying the
relatio nships in yo ur design is a piec e o f c ake. Yo u begin by lo o king at ho w the entities are related to eac h o ther.
Chapter 3 ✦ Designing a Relational Database
There are three basic types o f relatio nships: o ne-to -o ne, o ne-to -many, and many-to many. These relatio nships refer to the number instanc es o f data in o ne entity that
are related to instanc es o f data in ano ther entity. In a o ne -to -o ne re latio nship, there
is o nly o ne instanc e o f data in o ne entity that is related to a single instanc e o f data
in ano ther entity. Fo r instanc e, assume that yo u have two entities — sto res and
managers. Eac h sto re has a single manager, while eac h manager has a single sto re.
Thus eac h sto re has a unique manager and eac h manager has a unique sto re.
In a o ne -to -many re latio nship, o ne instanc e o f data in the first entity is related to
zero o r mo re instanc es o f data in the sec o nd entity. Fo r example, assume that yo u
have an entity fo r c usto mers and an entity fo r o rders. Eac h c usto mer may plac e
as many o rders as they desire. They need no t have plac ed any o rders if they have
signed up to b e o n a mailing list. Fo r eac h o rder, there is exac tly o ne c usto mer
who plac ed the o rder. Thus fo r eac h o rder there is o nly o ne c usto mer and fo r
eac h c usto mer there may b e zero o r mo re o rders.
In a many-to -many re latio nship, multiple instanc es o f data in the first entity are
related to multiple instanc es o f data in the sec o nd entity. This c an be illustrated by
having an entity fo r parents and an entity fo r c hildren. Eac h parent may have zero
o r mo re c hildren, while eac h c hild may have multiple parents. (Remember, an
o rphan c hild has no parents, while a c hild with divo rc ed parents, may have a
mo ther, a father, a stepmo ther and a stepfather.)
Drawing the E/ R model
Drawing the E/ R mo del is a fairly simple task (see Figure 3-2) with the info rmatio n
fo und in Tables 3-2 to 3-10. While I didn’t list the attributes fo r eac h entity bec ause it
wo uld render the small drawing nearly unreadable, it is a fairly easy task. Of c o urse,
c o mparing the abo ve tables to the diagram is pro bably even mo re meaningful.
Tip
When draw ing an E/ R m odel, I suggest using a tool like Visio rather than creating
a draw ing w ith a paper and pencil. Visio allow s you to easily edit the draw ing to
accom m odate the inevitable changes that w ill occur as various people review and
com m ent on your docum ent. Of course, there are som e very expensive database
design tools that offer sim ilar capabilities, but I find Visio w orks nearly as w ell for
m ost database designs.
45
46
Part I ✦ Database Programming Fundamentals
State
CustomerState
Questions
Customers
Toy Type
Question
CustomerOrder
Images
Toy Types
M anufacturers
Orders
InventoryImages
InventoryToy Types
CustomerOrder
Name
Inventory
OrderOrder Details
Order Details
Figure 3-2: View ing the final Entity/ Relationship m odel for Toy Collector.
Building the Database
Translating an E/ R mo del into a database is a pretty straightfo rward pro c ess. Eac h
o f the entities bec o mes a table and their attributes bec o me c o lumns in the table.
Yo u c an see the final pro duc t in Figure 3-3 using the SQL Server database diagram
fac ility.
Chapter 3 ✦ Designing a Relational Database
Figure 3-3: Looking at a database diagram of the Toy Collector database.
Thoughts on Database Design
Just because you have a valid database design doesn’t m ean that you w ill get the best perform ance from it. There are a num ber of factors that w ill affect perform ance, such as the
num ber of tables in the database, the size of the colum ns, and the num ber of indexes you
are using. How ever, the biggest single factor that affects your database’s perform ance is the
hardw are you’re using.
Believe it or not, having a faster CPU w ill not necessarily m ake your database server run
faster. A database server is very I/ O intensive. Anything that allow s the database to retrieve
data faster from disk w ill help the database server’s overall perform ance.
Adding m em ory to your server allow s the database server to cache m ore data in m em ory.
After all, retrieving data from m em ory is m uch faster than retrieving it from disk. This is the
biggest change you can m ake to im prove database perform ance.
After adding m em ory to your system , using SCSI disk drives in place of IDE drives is the next
place you should look for perform ance gains. Not only can you m anage up to 15 disk drives on
a single SCSI card, SCSI also allow s you to perform concurrent operations on each drive. Thus
you can have m ultiple disk drives perform ing seeks, w hile other drives are transferring data.
SCSI-III can transfer data faster than SCSI-II or SCSI-I and should be used for best perform ance.
Using faster disk drives them selves w ill also im prove perform ance. Disks that spin at 7,200
revolutions per m inute (RPM) w ill transfer data faster than those that spin at 5,400 RPM,
although tw o 5,400 RPM disk drives w ill probably perform better than one 7,200 RPM drive,
assum ing that you can split your w orkload evenly betw een the tw o drives. Of course, if you
can spring for tw o of the new 10,000 RPM disk drives, you’ll be better off in the long run.
47
48
Part I ✦ Database Programming Fundamentals
Summary
In this c hapter yo u learned:
✦ The five steps in an applic atio n design pro c ess.
✦ Why stating the pro gram helps yo u c larify go als and o bjec tives fo r the entire
design pro c ess.
✦ Ho w to use brainsto rming to determine the data elements and func tio ns
required in yo ur applic atio n.
✦ Ho w to use Entity/ Relatio nship mo deling to design yo ur database.
✦
✦
✦
C H A P T E R
Designing a
Relational
Database
✦
✦
✦
✦
In This Cha pter
Stating the pro blem
Brainsto rming
I
n this c hapter, I’m go ing to sho w yo u the way I design a
database. While I’ll use SQL Server to o ls in this c hapter,
the same c o nc epts c an be applied to any database system.
The key to using this appro ac h is to understand the tec hniques I’m go ing to sho w yo u and adapt them so that they
wo rk fo r yo u.
Overview of the Design Process
Designing a relatio nal database c an be as easy o r as hard as
yo u c ho o se to make it. I generally use a seven-step appro ac h
as o utlined belo w:
1. Stating the pro blem
2. Brainsto rming fo r ideas
3. Mo deling entities and relatio nships
4. Building the database
5. Creating the applic atio n
I’m go ing to disc uss the first fo ur steps in this c hapter. The
rest o f this bo o k will fo c us o n step five.
CrossReference
See Chapter 2 for inform ation about the relational
database m odel.
Mo deling entities
and relatio nships
Building the database
✦
✦
✦
✦
32
Part I ✦ Database Programming Fundamentals
Stating the Problem
While stating the pro blem may seem easy, it’s a lo t harder than it lo o ks. The pro blem
statement sho uld present an understanding o f what the o rganizatio n is trying to
ac c o mplish, while at the same time trying to emphasize the mo st c ritic al business
needs. If yo u want to replac e an existing applic atio n, yo u c an use that applic atio n as
a basis fo r the answer. But if yo u are building an applic atio n fo r the first time, it is
very impo rtant to understand what pro blem yo u’re trying to so lve. After all, if yo u
c an’t identify the pro blem, ho w are yo u go ing to kno w if yo u really so lved it?
The pro blem sho uld be stated as simply as po ssible. Fo r example, if the peo ple at
Amazo n.c o m were to state their pro blem, it might lo o k like this: we want to establish Amazo n.c o m as a brand name by selling bo o ks to c o nsumers via the Internet
at the lo west po ssible c o st to the c o nsumer and with the best po ssible servic e,
while building market share that will ensure the lo ng-term stability o f the c o mpany.
A spec ialty mail-o rder c atalo g c o mpany might want to so lve this pro blem: we want
to impro ve ho w we take c usto mer o rders o ver the telepho ne to reduc e mistakes
and impro ve servic e to o ur c usto mers. A small elec tro nic s supplier might state
their pro blem in this way: we need to impro ve o ur invento ry c o ntro l to inc rease
the number o f times the invento ry is turned o ver eac h year and to prevent sto c kpiles o f o bso lete items. In this bo o k, I’m go ing to use a c o mmo n database fo r all o f
the examples I c reate. I’ll also update an applic atio n I wro te a few years ago c alled
Car Co llec to r, whic h trac ks a c o llec tio n o f to y c ars. Sinc e I o riginally wro te this
pro gram, the Internet has bec o me very impo rtant to c o llec to rs. Web sites like
eBay make it muc h easier fo r peo ple to buy and sell c o llec tibles. In fac t, my wife
likes to buy and sell c o llec tible do lls and has been asking me to build her a versio n
o f Car Co llec to r that is targeted at the do ll market.
Taking this info rmatio n into c o nsideratio n, I c an state my pro blem like this: I want
to update Car Co llec to r to inc lude suppo rt fo r o ther types o f to ys and c o llec tibles
and add suppo rt fo r trading to ys with o ther c o llec to rs o ver the Internet. With the
new features I’m go ing to add, I’m go ing to c hange the name o f the applic atio n to
To y Co llec to r.
Note
It’s almost realistic: Toy Collector as used in this book isn’t m eant to be a com plete application, but rather a fram ew ork for show ing you different techniques for
building database applications in Visual Basic. Therefore, the database design m ay
not be as com plete as a com m ercial application, nor w ill all of the features found
in the com m ercial application be present in Toy Collector. Som e of the data structures I use, as w ell as the features included in the application, m ay seem like
overkill, but they are necessary to illustrate various points along the w ay. So, focus
on the techniques that I’m going to show you and try to understand w hy and how
I do things, rather than focusing on w hy this feature w as added or w hy that inform ation is m issing.
Chapter 3 ✦ Designing a Relational Database
Brainstorming
Onc e yo u have a basic understanding o f the pro blem yo ur applic atio n needs to
so lve, yo u need to design the database to ac c o mmo date the info rmatio n related to
yo ur applic atio n. The first step in this pro c ess it to take a lo o k at yo ur pro blem and
try to determine all o f the info rmatio n and func tio ns that might be needed to so lve
the pro blem. I c all this step brainsto rming.
Brainsto rming is the ac t o f disc ussing and rec o rding ideas witho ut regard to ho w
feasible they are to implement. This helps yo u identify all o f the info rmatio n yo u
need to keep and all o f the tasks yo ur applic atio n will need to perfo rm.
I like to c o nduc t brainsto rming sessio ns that inc lude everyo ne who will be invo lved
with the pro jec t in a single ro o m with a white bo ard. It helps to have as wide a range
o f peo ple present as po ssible. Everyo ne fro m end users, to pro grammers, to management sho uld be invo lved in this pro c ess.
Every idea that is raised sho uld be listed o n the white bo ard, even if it’s similar to
an idea that’s already listed. After the meeting, the info rmatio n sho uld be o rganized, and similar ideas c an be c o mbined as a single item. The ideas sho uld be c lassified as either a task that the applic atio n sho uld perfo rm o r a piec e o f info rmatio n
that will need to be kept.
It’s impo rtant to understand that so me o f the ideas that c o me o ut o f the brainsto rming sessio n may no t be prac tic al. At this stage o f the pro c ess, yo u sho uldn’t
wo rry abo ut prac tic ality. It is far mo re impo rtant to be c o mplete. So metimes things
that seem imprac tic al at this stage may pro ve easy to implement later, while o ther
ideas that seem easy to implement at first may no t pro ve to be wo rth the time and
effo rt.
Also , it’s impo rtant no t to make fun o f any ideas, no matter ho w bad they seem.
This is espec ially true fo r ideas c o ming fro m the less tec hnic al attendees. Quite
o ften, their ideas and c o mments may lead to a better understanding o f ho w the
applic atio n sho uld wo rk.
Brainstorming Toy Collector
Sinc e yo u c an’t ac tively partic ipate in the brainsto rming sessio n, I sat do wn and
held o ne myself, and c ame up with the fo llo wing list o f func tio ns that need to be
perfo rmed by To y Co llec to r applic atio n:
✦ Trac k items c urrently in the c o llec tio n
✦ Create repo rts o f items in the c o llec tio n
✦ Lo c ate a to y in the invento ry
33
34
Part I ✦ Database Programming Fundamentals
✦ Keep a mailing list o f c urrent and po tential c usto mers
✦ Create a Web page with a list o f items c urrently fo r sale
✦ Create a Web page with a list o f items wanted
✦ Create an HTML listing fo r eBay
✦ Evaluate the c o nditio n o f a to y
✦ Trac k purc hases and sales
✦ Pro c ess an o rder that sells o ne o r mo re to ys to a c usto mer
✦ Pro c ess an o rder that purc hases a to y fro m a c usto mer
The func tio ns will be used to maintain a database c o ntaining the fo llo wing data
elements:
✦ To y name
✦ Date o rdered
✦ Manufac turer
✦ Date rec eived
✦ Desc riptio n
✦ Date shipped
✦ Year the to y was built
✦ Credit c ard number
✦ Value
✦ Expiratio n date
✦ Pric e paid
✦ Custo mer name
✦ Asking pric e
✦ Custo mer’s first name
✦ Co nditio n
✦ Custo mer’s last name
✦ Co nditio n questio ns
✦ Custo mer’s middle initial
✦ Type o f to y
✦ Custo mer’s address
✦ Order info rmatio n
✦ Custo mer’s c ity
✦ Shipping c o st
✦ Custo mer’s state
✦ Sales tax
✦ Image o f the c o llec tible
Reviewing the results
After c o nduc ting the b rainsto rming sessio n, yo u need to review the info rmatio n
yo u c o llec ted and try to eliminate duplic ate info rmatio n and make sure that the
info rmatio n yo u have is c o mplete. Quite o ften while yo u c o nduc t this review,
yo u’ll realize that o ther related info rmatio n might b e useful and sho uld b e added
to the list.
Chapter 3 ✦ Designing a Relational Database
Examining the functions to be performed
Lo o king at the abo ve results, yo u c an see a few c o mmo n threads. First, yo u need an
invento ry system that trac ks all o f the to ys in the c o llec tio n. This is a fairly c o mmo n applic atio n, alo ng with maintaining a mailing list.
The invento ry part o f an applic atio n usually requires a unique identifier fo r an item
in invento ry. This wasn’t inc luded as part o f the o riginal brainsto rming sessio n. In a
traditio nal invento ry system, the quantity o f the item is also inc luded. Ho wever,
due to the fac t that different to ys may have different c harac teristic s based o n their
c o nditio n, I c ho o se to igno re the quantity issue and require that eac h item in the
invento ry must have its o wn unique rec o rd.
Pro c essing o rders isn’t diffic ult. Ho wever, a few mo re items need to be added to
what was already identified abo ve. Fo r instanc e, in o rder to c o mpute sales tax, yo u
need to kno w the sales tax rate. Fo r the purpo ses o f this bo o k, I’m go ing to assume
that the sales tax rate is unifo rm ac ro ss a state, even tho ugh this isn’t nec essarily
true. Yo u also need to c apture the c usto mer’s name o n the c redit c ard, sinc e it may
be different than the name they entered into yo ur database. There sho uld also be
an o ptio n to ship to an alternate destinatio n, rather than a regular mailing address.
The mailing list is pretty straightfo rward, exc ept that yo u sho uld give the c usto mer
the o ptio n to no t rec eive mail. This is impo rtant, bec ause even in to day’s marketplac e, peo ple will c o mplain abo ut unwanted mail. Also , yo u may want to inc lude
so me additio nal c o mments abo ut the c usto mer that wo uld let the user rec o rd pro blems that they may have had during previo us transac tio ns.
The c usto mer’s name is ac tually listed twic e: o nc e as simply name, and ano ther
time as first, middle, and last names. Whic h way is best really depends o n yo u.
Having a separate last name field makes it easy to searc h o n so meo ne’s last name.
Ho wever, using a single field lets yo u fo rmat a name mo re naturally, whic h is impo rtant when yo u have peo ple that have suffixes suc h as Ph.D., Junio r, Senio r o r III. It
also allo ws so meo ne to enter a title suc h as Mr., Ms., Dr., etc . with fewer pro blems.
In the lo ng run, it really do esn’t matter whic h metho d yo u pic k as lo ng as yo u’re
c o nsistent thro ugho ut yo ur database.
Evaluating the c o nditio n o f a to y c an be a fairly c o mplex pro c ess. One metho d is to
assign the to y a po int value, assuming that it’s in mint c o nditio n. Then yo u wo uld
ask a series o f questio ns abo ut spec ific flaws that are po ssible in the to y. Depending
o n the respo nse, po ints will be deduc ted fro m the maximum sc o re. The resulting
sc o re c an then be mapped o nto c o nditio n value, whic h in turn allo ws yo u to determine the true value o f the to y. Sinc e the questio ns c an vary by the type o f to y, additio nal info rmatio n is needed to determine the type o f to y and the questio ns that will
be used to determine the to y’s o verall c o nditio n.
35
36
Part I ✦ Database Programming Fundamentals
M apping the results to data types
The last step o f the brainsto rming sessio n is to map the data elements o nto a series
o f data types. After reviewing the brainsto rming info rmatio n, I like to assemble a
list o f the data elements that were derived fro m the sessio n, alo ng with Visual Basic
data type and a sho rt desc riptio n o f the elements, suc h as tho se sho wn in Table 3-1.
Table 3-1
Data Elements
Data Element
Data Type
Description
Custom erNam e
String
The nam e of the custom er.
Street
String
The street on w hich the custom er lives.
City
String
The city w here the custom er lives.
State
String
The state w here the custom er lives.
Zip
String
The proper ZIP code for the custom er’s address.
Phone
String
The custom er’s telephone num ber.
EMailAddress
String
The custom er’s e-m ail address.
MailingList
Boolean
True if the custom er w ants to receive periodic
notices.
OrderNum ber
Long
A num ber that uniquely identifies the order.
OrderStatus
String
The current status of the order.
DateOrdered
Date
The date the order w as placed.
DateShipped
Date
The date the order w as m ailed.
ShippingCost
Currency
The cost to ship the order.
SalesTax
Currency
The am ount of sales tax collected.
CreditCardNum ber
String
The credit card num ber used to purchase a toy.
ExpirationDate
String
The expiration date on the credit card.
InventoryId
Int
A unique identifier for an item in the collection.
ToyNam e
String
The nam e of the collectible toy.
Manufacturer
String
The toy’s m anufacturer.
ToyType
String
The type of toy.
ToyDescription
String
A description of the toy.
Chapter 3 ✦ Designing a Relational Database
Note
Data Element
Data Type
Description
MintValue
Currency
The value of the toy if it w as in m int condition.
Condition
Long
A num eric description of the toy’s condition.
Question
String
A question used to evaluate a toy’s condition.
TrueValue
Currency
The true value of the toy based on its condition.
DatePurchased
Date
The date the toy w as purchased.
Im age
Picture
A picture of the toy.
US first: When building an e-com m erce application, one of the first things you
need to plan for is how to handle international issues. For the m ost part, the only
w ay these issues w ould affect your database design is that additional data elem ents, such as Country and CurrencyType, w ould need to be included, plus you
w ould need to allow additional space for other fields such as ZIP code. Just
because I don’t include these fields in Toy Collector isn’t a good reason for you not
to include them in your application.
M odeling Entities and Relationships
The next step in the pro c ess is translating the info rmatio n fro m the brainsto rming
sessio n into a database design.
Entity/ relationship modeling
Entity/Re latio nship mo de ling ( also kno wn as E/ R mo deling) is a way o f desc ribing
the re latio nship between e ntitie s. An entity is a thing that c an be uniquely identified, suc h as a to y, a c usto mer, o r an o rder. Asso c iated with the entity is a set o f
attributes, whic h helps to desc ribe the entity. Eac h c usto mer has a name and an
address. Eac h to y has a name and a manufac turer. An o rder has an o rder number
and a date o rdered. Relatio nships are fo rmed between two entities, suc h as c usto mers and o rders, where a c usto mer plac es an o rder fo r a to y.
When drawing an E/ R mo del, I use rec tangles fo r entities, ellipses fo r attributes,
and diamo nds fo r relatio nships. In Figure 3-1, yo u c an see a simple E/ R mo del that
has two entities ( Custo mers and Orders) , with eac h entity having two attributes
( Custo mers-Address and Name, Orders-Order Number and Date Ordered) and a
single relatio nship ( Custo mer-Order) .
37
38
Part I ✦ Database Programming Fundamentals
Address
Customers
Name
Customer-Order
Order Number
Orders
Date Ordered
Figure 3-1: Designing a sim ple database using an E/ R m odel.
Identifying entities and attributes
The first step in this pro c ess is to review the list o f data elements fo und in Table
3-1 and lo o k fo r c o mmo n gro upings. As yo u sc an thro ugh the list o f data elements,
three main gro upings jump o ut almo st immediately: c usto mer info rmatio n, invento ry info rmatio n, and o rder info rmatio n. Eac h o f these gro upings represents a
majo r entity in the To y Co llec to r database.
At the same time, yo u need to lo o k at the vario us entities and their attributes fro m
an implementatio n po int o f view. Yo u may find that a few o ther attributes are easy
to inc lude and will add value to the applic atio n fro m the user’s po int o f view.
Tip
Dirt cheap disk drives: If you designed a database years ago, you w ill rem em ber
that disk space w as very expensive, and you alw ays tried to use the least am ount
of space possible. In today’s m arketplace, you can purchase a high-perform ance 9gigabyte SCSI disk drive for less than $500. If you allow 2,000 bytes for each custom er (w hich is very generous), you can store over 4 m illion custom ers on a single
disk drive. Since m ost applications w on’t store this m uch data, don’t let the cost of
disk space drive your database decisions.
Customer information
Table 3-2 c o ntains the list o f data elements that are related to a c usto mer, plus a few
mo re that po pped up while assembling the list. Finding so me additio nal data elements at this stage is quite no rmal, sinc e we no w have a better understanding o f
the applic atio n’s needs. In this c ase, I added fields to identify when the c usto mer
Chapter 3 ✦ Designing a Relational Database
was o riginally added to the database (DateAdded) and the last time the info rmatio n
was updated (DateUpdated). I also added a field c alled Co mments that allo ws the
user to rec o rd any c o mments they may have abo ut this partic ular c usto mer.
Table 3-2
Customer Information
Column Name
Data Type
VB Type
Description
Custom erId
Int
Long
A unique identifier for the custom er.
Nam e
Varchar(64)
String
The custom er’s nam e.
Street
Varchar(64)
String
The street address w here the
custom er lives.
City
Varchar(64)
String
The nam e of the city w here the
custom er lives.
State
Char(2)
String
The nam e of the state w here the
custom er lives.
Zip
Int
Long
The ZIP code for the custom er’s
address.
Phone
Varchar(32)
String
The custom er’s phone num ber.
Em ailAddress
Varchar(128)
String
The custom er’s e-m ail address.
DateAdded
Datetim e
Date
The date the custom er w as added to
the database.
DateUpdated
Datetim e
Date
The date the custom er’s inform ation
w as last updated.
MailingList
Bit
Boolean
When true m eans that the custom er
w ishes to receive periodic m ailings.
Com m ents
Varchar(256)
String
Com m ents about the custom er.
Inventory information
The info rmatio n abo ut the invento ry is a little mo re c o mplic ated than the c usto mer
info rmatio n. While it is easy to identify the attributes that are direc tly related to an
invento ry item (see Table 3-3), there are a few c ases where so me o f the info rmatio n
isn’t direc tly related. Fo r instanc e, the questio ns that yo u need to ask the user in
o rder to determine the c o nditio n o f a to y are related to the type o f to y, no t the ac tual
to y itself. This implies that ano ther entity c alled To yTypes (see Table 3-4) will be
needed to ho ld info rmatio n abo ut a type o f to y. Also , bec ause there are multiple
questio ns fo r eac h to y type, yo u’ll need yet ano ther entity (Co nditio nQuestio ns) to
ho ld the questio ns (see Table 3-5).
39
40
Part I ✦ Database Programming Fundamentals
Table 3-3
Inventory Items
Column Name
Data Type
VB Type
Description
InventoryId
Int
Long
A unique identifier for the item in the
collection.
ToyTypeId
Int
Long
A unique identifier for the type of toy
in the collection.
Nam e
Varchar(64)
String
The nam e of the toy.
ManufacturerId
Int
Long
The nam e of the m anufacturer w ho
m ade the toy.
YearIssued
Datetim e
Date
The date the toy w as first
m anufactured.
Description
Varchar(256)
String
A description of the toy.
MintValue
Money
Currency
The value of the toy if it is in m int
condition.
Condition
Int
Long
The condition of the toy using a
num eric scale.
ConditionMask
Varchar(64)
String
Answ ers to the condition questions
for this type of toy.
TrueValue
Money
Currency
The true value of the toy based on its
current condition.
DatePurchased
Datetim e
Date
The date the toy w as added to the
inventory.
PurchasePrice
Money
Currency
The am ount of m oney paid for the
toy.
AskingPrice
Money
Currency
The am ount of m oney you are w illing
to sell the toy for. A value of zero
m eans that you aren’t w illing to sell
the toy at this tim e.
BuyingPrice
Money
Currency
The am ount of m oney you are w illing
to pay for a sim ilar toy.
Wanted
Bit
Boolean
If true m eans that you w ant to buy
the toy.
ForSale
Bit
Boolean
If true m eans that you w ant to sell
the toy.
Chapter 3 ✦ Designing a Relational Database
Column Name
Data Type
VB Type
Description
Com m ents
Varchar(256)
Sting
Any com m ents that w ould be
displayed along w ith the toy.
DateUpdated
Datetim e
Date
The m ost recent tim e this
inform ation w as updated.
Table 3-4
Toy Types
Column Name
Data Type
VB Type
Description
ToyTypeId
Int
Long
A unique identifier for the type of toy
in the collection.
Description
Varchar(64)
String
A description of the type of toy.
Table 3-5
Condition Questions
Column Name
Data Type
VB Type
Description
TypeId
Int
Long
A unique identifier for the type of toy
in the collection.
Seq
Int
Long
A sequence num ber that is used to
distinguish betw een m ultiple
questions for a specific type of toy.
Question
Varchar(64)
String
A question used to evaluate the
condition of the toy.
Weight
Int
Long
The relative im portance of the
question w hen determ ining the toy’s
condition.
Responses
Int
Long
The highest possible value of the
response.
So metimes it is useful to c o dify a data value to ensure data c o nsistenc y. A go o d
example o f a field that c an easily get bad data is the Manufac turer field. Co nsider
ho w many different ways so meo ne c an spell Mattel. One way to ensure that the misspelling do esn’t happen is to enc o de eac h to y manufac turer as a numeric value and
41
42
Part I ✦ Database Programming Fundamentals
sto re the numeric value in the database. Then yo u need to add a translatio n table
that c an be used to translate the c o dified value into a text string. This is what the
Manufac turers table ac c o mplishes (see Table 3-6).
Table 3-6
M anufacturers
Column Name
Data Type
VB Type
Description
ManufacturerId
Int
Long
A unique identifier for the nam e of
the m anufacturer.
Nam e
Varchar(64)
String
The nam e of the m anufacturer.
Ano ther area o f c o nc ern is that we need to sto re images fo r the to ys. While I believe
it is ac c eptable fo r yo u to sto re images in a database, I also believe that they sho uld
be sto red in a separate table. Sinc e I need to use a separate table fo r the image, I
dec ided to add a sequenc e number c o lumn that will let me sto re multiple images
fo r a single to y (see Table 3-7).
Table 3-7
Images
Column Name
Data Type
VB Type
Description
InventoryId
Int
Long
A unique identifier for the item in the
collection.
Seq
Int
Long
A sequence num ber that is used to
distinguish betw een m ultiple im ages
for a single toy.
Im age
Im age
Picture
A large binary field that holds the
actual im age of the toy.
Order information
The final majo r entity that I identified in this applic atio n is the Orders entity.
Ho wever, this entity needs to be subdivided so eac h o rder c an have multiple items
in the o rder. Thus, Table 3-8 lists the attributes o f the Orders entity, while Table 3-9
lists the attributes asso c iated with a single item that is in the o rder. I c alled this
entity OrderDetails.
Chapter 3 ✦ Designing a Relational Database
Storing Images in a Database
While m any people recom m end against storing an im age in your database, I believe otherw ise. By storing im ages in the database, it is m uch easier to secure and access them . Storing
im ages outside the database m eans that you have to m aintain a separate security system to
protect the im ages. This can becom e very com plicated if you perm it the im ages to be
accessed both by Web brow ser-based applications and traditional client/ server applications.
While I believe in storing im ages in the database, I also believe that the im ages should be
stored in their ow n table, aw ay from any related data. Database perform ance is based
m ostly on how m uch inform ation you can retrieve w ith a single disk I/ O. The m ore row s
you can retrieve, the better.
In a typical database table, you m ight be able to retrieve anyw here from 10 to 100 row s
w ith a single disk I/ O. How ever, if you include an im age in the table, you m ay find that you
only get one row for each disk I/ O. By m oving the im age to a separate table, the perform ance of the m ain table isn’t com prom ised.
Table 3-8
Orders
Column Name
Data Type
VB Type
Description
OrderId
Int
Long
A unique identifier for the order.
Custom erId
Int
Long
A unique identifier for a custom er.
OrderType
Int
Long
1 = sale, 2 = purchase.
ShippingCost
Money
Currency
The total cost of shipping.
SalesTax
Money
Currency
The total cost of sales tax.
How Paid
Int
Long
1 = credit card, 2 = check.
CreditCardNum ber
Varchar(32)
String
The custom er’s credit card num ber.
ExpDate
Varchar(16)
String
The custom er’s credit card expiration
date.
OrderStatus
Int
Long
1= order placed, 2= order shipped,
3= order received.
DateOrdered
Datetim e
Date
The date and tim e the order w as
placed.
DateShipped
Datetim e
Date
The date and tim e the order w as
shipped.
DateReceived
Datetim e
Date
The date and tim e the order w as
received.
43
44
Part I ✦ Database Programming Fundamentals
Table 3-9
OrderDetails
Column Name
Data Type
VB Type
Description
OrderId
Int
Long
A unique identifier for the order.
Seq
Int
Long
A sequence num ber that is used to
distinguish betw een m ultiple item s
in a single order.
InventoryId
Int
Long
A unique identifier for the item in the
collection.
PurchasePrice
Money
Currency
The am ount paid for the toy.
The last entity I want to talk abo ut is the States entity. This entity exists mo stly to
translate the two -c harac ter state abbreviatio n into a sales tax rate, whic h is used to
c o mpute the amo unt o f sales tax that must be c o llec ted fo r an o rder. At the same
time, I dec ided to add the StateName field to translate State into a mo re meaningful
value.
Table 3-10
States
Column Name
Data Type
VB Type
Description
State
Char(2)
String
The tw o-character abbreviation for a
state.
StateNam e
Varchar(64)
String
The proper state nam e.
SalesTaxRate
Decim al
Currency
The sales tax rate for the state.
Identifying Relationships
Onc e yo u have identified all o f yo ur entities and their attributes, identifying the
relatio nships in yo ur design is a piec e o f c ake. Yo u begin by lo o king at ho w the entities are related to eac h o ther.
Chapter 3 ✦ Designing a Relational Database
There are three basic types o f relatio nships: o ne-to -o ne, o ne-to -many, and many-to many. These relatio nships refer to the number instanc es o f data in o ne entity that
are related to instanc es o f data in ano ther entity. In a o ne -to -o ne re latio nship, there
is o nly o ne instanc e o f data in o ne entity that is related to a single instanc e o f data
in ano ther entity. Fo r instanc e, assume that yo u have two entities — sto res and
managers. Eac h sto re has a single manager, while eac h manager has a single sto re.
Thus eac h sto re has a unique manager and eac h manager has a unique sto re.
In a o ne -to -many re latio nship, o ne instanc e o f data in the first entity is related to
zero o r mo re instanc es o f data in the sec o nd entity. Fo r example, assume that yo u
have an entity fo r c usto mers and an entity fo r o rders. Eac h c usto mer may plac e
as many o rders as they desire. They need no t have plac ed any o rders if they have
signed up to b e o n a mailing list. Fo r eac h o rder, there is exac tly o ne c usto mer
who plac ed the o rder. Thus fo r eac h o rder there is o nly o ne c usto mer and fo r
eac h c usto mer there may b e zero o r mo re o rders.
In a many-to -many re latio nship, multiple instanc es o f data in the first entity are
related to multiple instanc es o f data in the sec o nd entity. This c an be illustrated by
having an entity fo r parents and an entity fo r c hildren. Eac h parent may have zero
o r mo re c hildren, while eac h c hild may have multiple parents. (Remember, an
o rphan c hild has no parents, while a c hild with divo rc ed parents, may have a
mo ther, a father, a stepmo ther and a stepfather.)
Drawing the E/ R model
Drawing the E/ R mo del is a fairly simple task (see Figure 3-2) with the info rmatio n
fo und in Tables 3-2 to 3-10. While I didn’t list the attributes fo r eac h entity bec ause it
wo uld render the small drawing nearly unreadable, it is a fairly easy task. Of c o urse,
c o mparing the abo ve tables to the diagram is pro bably even mo re meaningful.
Tip
When draw ing an E/ R m odel, I suggest using a tool like Visio rather than creating
a draw ing w ith a paper and pencil. Visio allow s you to easily edit the draw ing to
accom m odate the inevitable changes that w ill occur as various people review and
com m ent on your docum ent. Of course, there are som e very expensive database
design tools that offer sim ilar capabilities, but I find Visio w orks nearly as w ell for
m ost database designs.
45
46
Part I ✦ Database Programming Fundamentals
State
CustomerState
Questions
Customers
Toy Type
Question
CustomerOrder
Images
Toy Types
M anufacturers
Orders
InventoryImages
InventoryToy Types
CustomerOrder
Name
Inventory
OrderOrder Details
Order Details
Figure 3-2: View ing the final Entity/ Relationship m odel for Toy Collector.
Building the Database
Translating an E/ R mo del into a database is a pretty straightfo rward pro c ess. Eac h
o f the entities bec o mes a table and their attributes bec o me c o lumns in the table.
Yo u c an see the final pro duc t in Figure 3-3 using the SQL Server database diagram
fac ility.
Chapter 3 ✦ Designing a Relational Database
Figure 3-3: Looking at a database diagram of the Toy Collector database.
Thoughts on Database Design
Just because you have a valid database design doesn’t m ean that you w ill get the best perform ance from it. There are a num ber of factors that w ill affect perform ance, such as the
num ber of tables in the database, the size of the colum ns, and the num ber of indexes you
are using. How ever, the biggest single factor that affects your database’s perform ance is the
hardw are you’re using.
Believe it or not, having a faster CPU w ill not necessarily m ake your database server run
faster. A database server is very I/ O intensive. Anything that allow s the database to retrieve
data faster from disk w ill help the database server’s overall perform ance.
Adding m em ory to your server allow s the database server to cache m ore data in m em ory.
After all, retrieving data from m em ory is m uch faster than retrieving it from disk. This is the
biggest change you can m ake to im prove database perform ance.
After adding m em ory to your system , using SCSI disk drives in place of IDE drives is the next
place you should look for perform ance gains. Not only can you m anage up to 15 disk drives on
a single SCSI card, SCSI also allow s you to perform concurrent operations on each drive. Thus
you can have m ultiple disk drives perform ing seeks, w hile other drives are transferring data.
SCSI-III can transfer data faster than SCSI-II or SCSI-I and should be used for best perform ance.
Using faster disk drives them selves w ill also im prove perform ance. Disks that spin at 7,200
revolutions per m inute (RPM) w ill transfer data faster than those that spin at 5,400 RPM,
although tw o 5,400 RPM disk drives w ill probably perform better than one 7,200 RPM drive,
assum ing that you can split your w orkload evenly betw een the tw o drives. Of course, if you
can spring for tw o of the new 10,000 RPM disk drives, you’ll be better off in the long run.
47
48
Part I ✦ Database Programming Fundamentals
Summary
In this c hapter yo u learned:
✦ The five steps in an applic atio n design pro c ess.
✦ Why stating the pro gram helps yo u c larify go als and o bjec tives fo r the entire
design pro c ess.
✦ Ho w to use brainsto rming to determine the data elements and func tio ns
required in yo ur applic atio n.
✦ Ho w to use Entity/ Relatio nship mo deling to design yo ur database.
✦
✦
✦