SQL Server Database Design

Whats the problem?

Many new DBAs or DB designer roll databases with poorly designed
tables into production.
The bad design create production problem ()
Fixing a table design problem oten dri!es changes bac" into the
application code. #o these $xes ha!e a relati!ely high cost.
%ew people are not $nding or understanding the a!ailable DB design
documentation or boo"s until ater their design production.
Relational Databases
in the relational Database& the basic unit or storing data is called a
relation& which loo"s li"e a ' dimensional array or table.
(elational database are based on part o set theory that deals with
types o sets called relations.
#)* Database are a relational database& in #)* databases relations
are typically called tables. +ach class o entity to be recorded ion the
database is represented using tables& such as customers& parts& and orders.
there are two design processes mathematically pro!en to generate
a set o tables that minimi,e redundancy and data maintenance anomalies-
%ormali,ation +ntity.relationship modeling
Main Component:
Table (relation): represents
#ome class o entity (Tables) or which you need to record data-
#tudent& /lass& 0art& 1rder
The relationship between the entities (Tables)- #tudent/lass&
1rder0roduct
/olumn (attribute)- represents a characteristic o that class o ob2ects-
%ame& /olor& 3eight& 0rice& etc
+ach column has a
Data Type (4nteger& character& etc)
Domain (#et o allowed !alues)
(ow(tuple)- represents an indi!idual o that class-
0art 5 6'7& #tudent Alan Bruce& etc
Table Kes:
! "an#i#ate $e (%rimar Ke) is one or more "ol&mn 'hose val&es
is &ni(&e )or the ea"h ro' in the table
The candidate "ey uni8uely identiy each row.
The !alues o the other columns in the row are said to depend on
the "eys
a table can ha!e multiple candidate "eys.
* o& pi"$ one o) the $e to be the primar $e+
All columns in the table depend on the primary "ey
relati!ely small
relati!ely stable.
* ! )oreign Ke in one table establishes a relationship to another
table b re)erring to the primar $e in another table+
* ,or e-ample. an or#er%ro#&"t table 'ill have:
An 1rder4D column reerencing bac" to the 1rder4D
0rimary "ey in the 1rder table.
A 0roduct%umber column reerencing bac" to the
0roduct%umber 0rimay "ey in the product table.
/-ample o) a table:
Design a set o) Tables:
Database design cycle is similar to most system design processes.
To Design a set o tables& you
4nter!iew your end users and de!elopers to see what data they
need stored in the database& The database must hold the data re8uired to-
0roduce all web pages& Forms and (eports
(un all business processes.
9ou then ta"e those data re8uirements through a design
process that creates logical de$nitations o the set o tables needed to hold
that data.
Typically use either normali,ation& or entity.relationship
modeling to design a set o tables that e:ciently store the data and
minimi,es logical problems.
At this stage &the table descriptions are generic enough
that they could be implemented on any DBM#.
9ou re!iew this logical model against the re8uirements& ad2ust
as needed.
9ou then create the physical model which can be implemented
on a speci$c DBM#& #uch as #)* #er!er& M9 #)*& 1racle& or DB'
ma"e implementation speci$c choices or things li"e
indexing and data type.
Build a set o /(+AT+ statements that will create
physical tables.

0ormali1ation:
* %ro"ess )or iterating table #esigns thro&gh a series o) 203RM!L
,3RMS4
* +ach normal orm de$nes increasingly rigorous re8uirements
or the columns and ;eys.
+ach normal orm re8uires the tables meet the re8uirements
o all pre!ious normal orms.
* Most #atabase #esigners go thro&gh 5
st
. 6
n#
. an# 7
r#
normal )orms
Boyce./odd normal orms is li"e a combined o '
nd
and 7
rd

normal orm.
#hould e!aluate against <
th
& and =
th
normal orm.
* 83!L: all the val&es in a ro' #epen# on the $e. the 'hole $e.
an# nothing b&t $e+
0ormal ,orm /-plaine#:
* Data 9ie's are the starting %oint+
* :#enti) the "ol&mns. #omains. an# Kes+
* To 8et to 5
st
0ormal ,orm:
Ma"e columns atomic (#ee #lide 6' or details) & split
columns that ha!e multiple !alues into separate columns .
(emo!e repeating "eys
* 5
st
0ormal ,orm
All columns depend on a ;ey.
All columns atomic
To get to '
nd
normal rom- remo!e partial "ey dependencies.
* 6
n#
0ormal ,orm
All columns depend on a whole "ey.
To get to 7
rd
normal orm- (emo!e all non."ey dependencies.
* 7
r#
0ormal ,orm
All columns depend only on the primary "ey& The whole primary
"ey& and nothing but the primary "ey.
* ;
th
0ormal ,orm
There are no multiple& independent& multi.!alued acts in the
table.
Lets 0ormali1e a ,orm
/omputer Mart
>=6< east ?
th
street
Broo"lyn& %9 66=6@
A6B.=B'.'6<@
1rder %umber-........... /ustomer
4D-...................
Date-.......................... /ustomer %ame-..............
Deli!ery date-.............. /ustomer
address-............
/ustomer /ity-...... #tate-..............................Cip....................
0hone- (A6B).'=<.6'<= 0arts 1rdered-
#ubtotal-....................
Tax..........................
Total- .......................

<&il# Data 9ie'
*ist the data !iews.
Determine domains or all columns
Determine the candidate "eys.
Brac"et all repeating groups
/-ample Data 9ie'
Col&mn 0ame Data Tpe Domain Ke
%art0&mber n"har(=) %art0&mber $/>
%artDes"ription 0var"har(6?) %artDes"ription
%artColor 0var"har(6@) Colors
%artWeight 0&meri" (A+6) Bs3&n"es
%artCost smallmone BSC&rren"
3r#er%artQt smallint Q&antit
3r#er%artCost smallmone BSC&rren"
S&bTotal smallmone BSC&rren"
Ta- smallmone BSC&rren"
3r#erTotal smallmone BSC&rren"
%roblems in the Data 9ie'
0art is a repeating Droup
%ame& Address& and 0hone not atomic
%ote-
Atomic- (ule o atomicity-
(ule 6- column with atomic data canEt ha!e se!eral !alue o same type
o data in same column.
rule'- a table with atomic data canEt ha!e se!eral columns with same
data type.
*i"e ull name column canFt say that it could be atomic because it can
be urther di!ided into last name& $rst name. /olumn with interest also
be di!ided into urther& so column which canEt be di!ided "nown as
atomic.
Data 9ie's to 5st 0ormal ,orm
#plit columns that is not atomic into separate columns or each part o the
original column
(emo!e repeating groups
0lace repeating groups in a new table
the "ey o the new table is built by combining the source table "ey and the
repeating group "ey.
0ote: ,irst 0ormal ,orm
Tables are said to be in first normal form when:
- The table has a primary key.
- No single attribute (column) has multiple values.
- The non-key attributes (columns) depend on the primary key.


5st 0ormal ,orm /-ample 3r#er Table
/olumn %ame Data Type Domain ;ey
1rder%umber int 1rder%umber ;ey
1rderDate datetime BusinessDate
Deli!eryDate datetime Anyday
/ustomer%umber int /ustomer%umbe
r
;ey
/ustomerFirst%ame %!archar (=@) 0eople%ames
/ustomer#urname %!archar(7=) surname
/ustomerAddr%umb
r
%!archar (=@) #treetAddress
/ustomerstreet%am
e
%!archar('=) Galid#treet%ame
/ustomerApt%umbr %!archar ('=) Galidaptnumber
/ustomer/ity %!archar ('=) /ity%ame
/ustomer#tate /har(') H##tate/ode
/ustomerCip /har(=) H#,ipcodes
/ustomer0hone char (6@) H#0honenbr
#ubtotal smallmoney H#/urrency
Tax smallmoney H#/urrency
1rdertotal smallmoney H#/urrency
6n# 0ormal ,orm
0ote: 6
n#
0ormal ,orm:
Tables are said to be in second normal form when:
- The tables meet the criteria for first normal form.
- If the primary key is a composite of attributes (contains multiple
columns) the non key attributes (columns) must depend on the whole
key.
Note: !ny table with a primay key that is composed of a single
attribute (column) is automatically in second normal form.
**5st 0ormal ,orm to 6n# 0ormal ,orm
* (emo!e partial "ey dependencies
0lace columns that depend only on part o a primary "ey in a new table
whose "ey is the "ey part that the columns depend on
3r#er Table
Col&mn 0ame Data Tpe Doamins Ke
1rder%umber int 1rder%umber ;ey
1rderDate datetime BusinessDate
Deli!eryDate datetime Anyday
/ustomer%umber int /ustomer%umb
er
;ey
/ustomerFirst%a
me
%!archar (=@) 0eople%ames
/ustomer#urnam
e
%!archar(7=) surname
/ustomerAddr%u
mbr
%!archar (=@) #treetAddress
/ustomerstreet%a
me
%!archar('=) Galid#treet%ame
/ustomerApt%um
br
%!archar ('=) Galidaptnumber
/ustomer/ity %!archar ('=) /ity%ame
/ustomer#tate /har(') H##tate/ode
/ustomerCip /har(=) H#,ipcodes
/ustomer0hone char (6@) H#0honenbr
#ubtotal smallmoney H#/urrency
Tax smallmoney H#/urrency
1rdertotal smallmoney H#/urrency
3r#er %art Table
/olumn name Data Type Domain ;ey
0art%umber %char(>) 0art%umber 9es
0artDescription %!archar(7@) 0artDescription
0art/olor %!archar('@) /olors
0art3eight %umeric(=.') HD1unces
0art/ost #mallmoney H#/urrency
7
r#
0ormal ,orm:
0ote: Tables are said to be in third normal form when:
- The tables meet the criteria for second normal form.
- "ach non-key attribute in a row does not depend on the entry in
another key column.
6n# 0ormal ,orm To 7r# 0ormal ,orm
(emo!e non."ey dependencies
Mo!e columns that depend on a "ey that is not the primary "ey to a new
table
The primary "ey o the new table is the "ey on which all the mo!ed
columns depend
The columns orming the "ey or the table are let in the source table as a
oreign "ey
7
RD
0ormal ,orm e-ample:
3r#erTable
Col&mn name Data Tpe Domain Ke
1rder%umber int 1rder%umber 0;
1rderDate datetime BusinessDate
Deli!eryDate datetime AnyDay
/ust%umber int /ustomer%umber F;
#ubtotal smallmoney H#/urrency
Tax smallmoney H#/urrency
1rderTotal smallmoney H#/urrency
C&stomerTable
Col&mn 0ame Data Tpe Domain Ke
/ust%umber int /ustomer%umber 0;
/ustFirst%ame %!archar ('=) First%ame
/ust*ast%ame nGarchar('=) last%ame
/ustAddr%umber %!archar('@) Galid#treet%umbe
r
/ust#treet%ame %!archar('=) Galid#treet%ame
/ustApt%umber %!archar(6@) GalidApt%umber
/ust/ity %!archar ('=) /ity%ame
/ust#tate %char(') H##tate/ode
/ustCip /har(=) H#Cip/ode
/ust0hone %!archar(66) H#0hone%umber
3r#er%artTable
Col&mn 0ame Data Tpe Domain Ke
1rder%umber int 1rder%umber 0;
0art%umber %char(>) 0art%mber
1rder0art)ty smallint )uantity
1rder0art/ost smallmoney H#/urrency
%artTable
Col&mn 0ame Data Tpe Domain Ke
0art%umber %char(>) 0art%umber 0;
0artDescription %!archar('@@) 0artDescription
0art/olor %!archar('@) /olors
0art3eight %umeric(B&') H#1unces
0art/ost #mallmoney H#/urrency
Does this #esign meet all b&siness
re(&irements?
:) es :mplement %hsi"al #esign+ :) not )ollo' ;
th
an# ?
th

0ormal )orm
Fourth Normal Form:
Tables are said to be in fourth normal form when:
- The table meets the criteria for third normal form.
- #ituations where non-key attributes depend on the key column
e$clusive of other non-key columns are eliminated.
Fifth Normal Form:
Tables are said to be in fifth normal form when:
- The table meets the criteria for fourth normal form.
- The table consists of a key attribute and a non-key attribute only.
0ormali1ation: ,inal Steps
Do through the normali,ation process againast all o the orms& screens
and reports identi$ed in the initial re8uirements gathering& along with
all the data processing re8uirements.
Merge tables
- /ombine the columns rom all tables that share the same primary
"ey
Galidate against processing re8uirements
- +nsure all organi,ational acti!ities are modeled in the tables
:mplement ! %hsi"al Design:
Step 1. Select a server.
The Data Hse Analysis and Data Golume Analysis models& which 4
explained last month& de$ne the guidelines or choosing a ser!er with
ade8uate /0H power and enough hard dis" capacity to see you through
the $rst ew years o operation. The Data Hse Analysis model lets you
!isually map the important processes that run on a database.
Step 2. Create a database:
9ou can use the Data Golume Analysis model again to guide you in si,ing the
user data and transaction log $le. This model gi!es you a rough idea o space
re8uirements& which you can translate into initial database $le si,es.
Step 3. Create the database objects.
9ou ha!e two options or creating the tables& indexes& !iews& constraints&
stored procedures& and triggers that ma"e up an operational database. First&
you can use the physical data model to guide you in writing #)* scripts that
you can later execute& or you can create the ob2ects directly by using
+nterprise ManagerFs graphical and programming interace.
Step 4. Load the data.
Iow should you approach loading data into the databaseJ The answer
depends on where the data is coming rom (the source) and how much data
you need to load. 4 you donFt ha!e any data to load when you $rst create the
database (a highly unusual situation)& you need to concentrate only on the
data.capture schemes you plan to implement& such as data entry orms or
automated capture programs li"e those used in monitored en!ironments
such as manuacturing sites and hospital intensi!e care units. Most li"ely&
youFll ha!e to import data rom comma.delimited Kat $les or transer data
rom other systems into your database.
Step 5. Create and run security scripts
/reating security scripts is& unortunately& a tas" that you ha!e to perorm
manually. 9ou can use the security matrix rom LThe #ecurity Matrix&L March
'@@@& as a guide to building your #)* #er!er security scripts. 9ou can also
set up security through +nterprise Manager& then ha!e +nterprise Manager
generate the scripts.
Step 6. Create backup and other utility tasks.
%ow that youF!e created your database and loaded some data& you need to
implement your disaster.a!oidance plan. *ast month& 4 tal"ed about planning
bac"up and reco!ery schemes and e!aluating (A4D and ailo!er techni8ues.
This month& you bring those plans to lie. 9ou can use the #)* #er!er A.@
Database Maintenance 0lan 3i,ard to help set up scheduled bac"ups or all
user and system databases. 9ou can also use the Maintenance 0lan wi,ard to
help set up tas"s to reorgani,e data and index pages& update statistics&
reco!er unused space rom database $les& chec" or database integrity& and
generate reports about utility 2ob acti!ity.
Step C+ %er)orm mis"ellaneo&s tas$s:
4 you arenFt implementing replication& you can ta"e the e!ening oM.
Iowe!er& i youFre going to use replication& you need to decide which type o
replication to implement- snapshot& transactional& or merge. (For more
inormation& see Ted Daley and Bob 0eiM& LMerge Cone&L %o!ember 6???.)
#napshot replication copies data to the target database based on a regular
inter!al that you set up. Transactional replication copies data as it changes
on the source database. And merge replication lets target databases update
local data& then roll up changed data to the source database. 3hich is best
or your particular en!ironmentJ #napshot replication is best when you ha!e
relati!ely static data sets that need rereshed only occasionally or or road
warriors who connect only periodically to the central database with their
laptops and download copies o data $les. Transactional replication is best
when you need near.realtime changes to the target database and you can
set up a persistent connection between the source and the target database.
Merge replication is best when you ha!e& say& a ro!ing sales orce that
changes data rom the road or when youF!e created hori,ontally partitioned
$les& perhaps by geography& where +ast /oast customers& or example&
reside on the %ew 9or" replicate& 3est /oast customers reside on the #an
Diego replicate& and the master customer list resides at company
head8uarters in Den!er.
,rom <eginning to /n#:
/ongratulationsN 9ouF!e sur!i!ed the past > months o transorming an idea
or a database into reality. Oust remember that no two database pro2ects are
the same. +ach has its own challenges and opportunities& which you ha!e to
address indi!idually. To recreate the database 4 used in this data.modeling
series& go to http-PP www.s8lmag.com& enter 4nstantDoc 4D ?6<>& and
download the Gisio.generated code 4 used to build the sample 0ublications
database. 9ou can also download a ully unctioning sample physical model