Directory listing of http: uap.unnes.ac.id ebook biblebook Visual Basic 6 com & Library Books
1
C H A P T E R
Basic Concepts
I
n this c hapter, I’m go ing to intro duc e yo u to the c o nc epts
behind databases and why databases are impo rtant to
yo ur applic atio n pro gram. I’ll also c o ver different database
arc hitec tures and fo llo w that up with a brief o verview o f the
database systems to be c o vered in this bo o k.
✦
✦
✦
✦
In This Cha pter
W hy use a
database?
Database architecture
Why Use a Database?
A database is simply a general-purpo se to o l that allo ws yo u to
sto re any info rmatio n yo u want that c an be read and updated
by o ne o r mo re c o nc urrent applic atio n pro grams in a sec ure
and reliable fashio n. No te that while this definitio n desc ribes
c o nventio nal database systems suc h as SQL Server and Orac le
8i, it c an also be used to desc ribe a c o llec tio n o f no rmal disk
files. I want to explo re these c o nc epts using c o nventio nal disk
files to help yo u better understand why yo ur applic atio n needs
a database system.
Storing information
There are many ways to sto re info rmatio n o n a c o mputer, but
eventually all o f them bo il do wn to plac ing info rmatio n in a file
so mewhere o n a disk drive. There are two basic types o f files,
whic h are c harac terized by ho w they are ac c essed. Se que ntial
acce ss files are ac c essed as a single unit, while rando m acce ss
files allo w yo u to direc tly ac c ess the file in small piec es.
Using conventional file access
In o rder to pro c ess the data in a sequential ac c ess file, yo u
must read o r write the entire file. This type o f ac c ess is useful
fo r a wo rd pro c esso r where yo u want to make all o f the info rmatio n in the file available to the user at the same time.
Co mmo n databases
✦
✦
✦
✦
4
Part I ✦ Database Programming Fundamentals
Generally a pro gram will lo ad the entire file into memo ry, make whatever c hanges
are nec essary, and then save the entire file when the user is ready to exit the
pro gram.
When dealing with sequential ac c ess files, yo u need no t lo ad the entire file into
memo ry. Indeed, many pro grams merely lo ad eno ugh data fro m the file to perfo rm
a given task and lo ad mo re data when the task is c o mplete. The main idea is that
yo ur pro gram reads the data fro m the beginning o f the file to the end in a linear
fashio n. Henc e the term se que ntial.
In mo st applic atio n pro grams, yo u o nly want to ac c ess a subset o f the data at a given
po int in time, so rather than pro c essing the entire file just to get a small piec e o f data,
a rando m ac c ess file allo ws yo u to divide the file into c hunks c alled re co rds. (See
“Organizing data in rec o rds,” belo w fo r details.) Eac h rec o rd has a unique rec o rd
number, whic h is determined by its relative po sitio n in the file. Yo u c an retrieve o r
update any rec o rd in the file by spec ifying the appro priate rec o rd number.
The key to making rando m ac c ess files wo rk is that eac h rec o rd in the file is always
the same size. This allo ws yo u to determine the lo c atio n o f the rec o rd by c o mputing the starting byte o f the rec o rd, just by kno wing the size o f the rec o rd and the
relative rec o rd number in the file.
Even tho ugh a rando m ac c ess file may be o rganized differently than a sequential
ac c ess file, yo u c an also pro c ess a rando m ac c ess file sequentially by reading the
rec o rds in o rder o f their rec o rd numbers. This implies that yo u do n’t lo se any func tio nality o f a sequential ac c ess file if yo u c ho o se to c reate yo ur file as rando m
ac c ess.
Organizing data in records
A rec o rd represents a c hunk o f data c o ntained in a file and is o rganized into o ne
o r mo re fie lds. Eac h field has a spec ific name and data type asso c iated with it.
The name is used to uniquely identify the field in the rec o rd, and the data type
desc ribes what kind o f info rmatio n the field c an ho ld.
CrossReference
See “Colum ns and Data Types” in Chapter 2 for m ore inform ation on this topic.
Bec ause eac h rec o rd in the file always ho lds the same info rmatio n, yo u c an think o f
a file full o f rec o rds as a table o r grid, where eac h rec o rd c o rrespo nds to a ro w and
eac h field c o rrespo nds to a c o lumn (see Figure 1-1). The table c o nc ept also c o nveys
the c o nc ept o f ho w the info rmatio n is ac tually sto red in the file, sinc e the relative
po sitio n o f eac h field is fixed in relatio n to the o ther fields and the relative rec o rd
number uniquely identifies the rec o rd’s plac e in the table.
Chapter 1 ✦ Basic Concepts
Name
Christopher James
Samantha Ashley
Terry Katz
Robert Weiler
Wayne Freeze
Bonnie Jean
Jill Heyer
Raymond Bucky
Address
1234 M ain Street
2345 Central Avenue
3456 Pennsylvania Ave
4567 Redw ood Way
5678 Baltimore Street
6789 Oak Street
7890 Washington Drive
8901 Souix Circle
City
College Park
College Park
College Park
College Park
College Park
College Park
College Park
College Park
State
MD
MD
MD
MD
MD
MD
MD
MD
Zip Code
20742
20742
20742
20742
20742
20742
20742
20742
Figure 1-1: A file w ith records looks like a grid or a table.
Concurrency
One o f the mo st c ritic al issues to c o nsider when dealing with an applic atio n is
ensuring that two o r mo re c o nc urrently-running pro grams do n’t interfere with
eac h o ther while pro c essing data. If the pro per steps aren’t taken, it wo uld be easy
fo r o ne pro gram to destro y info rmatio n that ano ther pro gram c hanged in the file.
Fo r instanc e, assume that yo u have a rando m ac c ess file that c o ntains c usto mers’
c hec king ac c o unt balanc es. Then assume that yo u have o ne pro gram that debits
the ac c o unt fo r c hec ks that the c usto mer wro te, while ano ther pro gram c redits
c usto mer depo sits. While this sc enario is unlikely, it is po ssible that the two pro grams may attempt to update the same c usto mer rec o rd at the same time.
No w, c o nsider the fo llo wing seq uenc e o f events. The deb it pro gram reads the
c usto mer’s rec o rd. Befo re the deb it pro gram has a c hanc e to update the info rmatio n, the c redit pro gram reads the c usto mer’s rec o rd and adds the depo sit to the
ac c o unt’s to tal b alanc e. After the c redit pro gram updates the c usto mer’s info rmatio n, the deb it pro gram c o mpletes its pro c ess b y writing its updated ac c o unt
b alanc e b ac k to the file. In this sc enario , the c redit to the ac c o unt was lo st, sinc e
the update do ne b y the deb it pro gram used an o ut-o f-date ac c o unt b alanc e.
The pro per way to prevent the c o nc urrenc y pro blem is by c o ntro lling ac c ess to the
data. Typic ally, this is do ne by lo cking the file to prevent o ther users fro m ac c essing
any o f the data in the file yo u want to use. The sequenc e o f events in the abo ve sc enario wo uld no w lo o k like this: The debit pro gram wo uld lo c k the file. Then it wo uld
read the c usto mer rec o rd. The c redit pro gram wo uld attempt to lo c k the file. Sinc e
the debit pro gram already lo c ked the file, the c lient pro gram wo uld be suspended.
The debit pro gram wo uld c o mplete its update and then release the lo c k o n the file.
The c redit pro gram wo uld be resumed and the lo c k wo uld be granted. It wo uld then
perfo rm its update and release the lo c k, thus ensuring that the c o rrec t balanc e
wo uld be in the file.
5
6
Part I ✦ Database Programming Fundamentals
Securing your data
In mo st c o mputer systems, yo u c an identify the users who are able to read o r
update a partic ular file, and deny ac c ess to all o thers using no rmal o perating system sec urity. Ho wever, it is o ften desirable to allo w so meo ne to see o nly part o f a
rec o rd — in a c ase, fo r instanc e, where yo u want to keep an emplo yee’s salary info rmatio n in the same rec o rd with the emplo yee’s address and telepho ne number.
To prevent peo ple fro m seeing salary info rmatio n, yo u have to c reate ano ther file
that c o ntains info rmatio n abo ut eac h perso n who c an ac c ess yo ur file and whic h
fields they are permitted to ac c ess. Then yo ur applic atio n pro grams must pro perly
use this info rmatio n to prevent unwanted ac c ess to data.
Of c o urse this metho d is o nly as reliable as yo ur applic atio n pro gramming staff.
One small mistake in a pro gram c o uld allo w a user to read and/ o r c hange the value
that they sho uldn’t have ac c ess to .
Performing backups and using transaction logs
No matter what yo u do to yo ur data, yo u need to ensure that o nc e a c hange has
been made to it, it wo n’t be lo st. After all, it is po ssible that yo ur hard disk c o uld
c rash and destro y yo ur files o r yo ur c o mputer c o uld suffer a po wer failure while
the files were being updated.
There are a number o f different ways to prevent yo ur data fro m being lo st. The
mo st c o mmo n prac tic e is to bac k up yo ur data o n a regular basis. Of c o urse yo u
c an’t permit any users to update data while yo u’re do ing this, o r yo ur data files may
be in an inc o nsistent state bec ause so meo ne c hanged a value in o ne file befo re the
bac kup pro c ess c o pied the o ne file and after the bac kup pro c ess c o pied ano ther
file. Alternate ways to prevent yo u fro m lo sing yo ur data inc lude using redundant
disk drives and/ o r database servers so that yo ur data will still exist even if yo u lo se
a disk drive o r server. Ho wever, I stro ngly rec o mmend that yo u bac k up yo ur data
even if yo u use redundant equipment, just in c ase yo u lo se bo th yo ur primary c o py
and yo ur redundant c o py.
Mo st applic atio ns bac k up their data o nc e a day, whic h limits the amo unt o f data
yo u might lo se to a maximum o f a single day. But lo sing even half a day’s wo rth o f
info rmatio n c an be a big pro blem in mo st situatio ns. Fo r instanc e, in the c ase o f a
mail-o rder pro c essing applic atio n, yo u always have the o riginal o rder do c uments
that yo u c an reenter. Ho wever, in the c ase o f a telepho ne o rder pro c essing applic atio n, yo u may no t even kno w whic h c usto mers plac ed an o rder if yo u lo se yo ur
files, and even if yo u did, do yo u really want to c all all o f yo ur c usto mers bac k to
find o ut what they o rdered?
Chapter 1 ✦ Basic Concepts
There are a c o uple o f so lutio ns to this pro blem. First yo u c an print every c hange
yo u make to the files o n a printer. This way, yo u will always have a paper rec o rd o f
the c hanges, and c an reenter the info rmatio n if yo u need to .
A better way wo uld be to write all o f yo ur c hanges to a spec ial file kno wn as a transactio n lo g. This file inc ludes o nly the c hanges that were made to the file. Thus, if yo u
have to resto re the file fro m the previo us day’s bac kup, yo u c o uld run a pro gram that
wo uld read the values fro m the transac tio n lo g and reapply them to the main file.
Bo th o f these appro ac hes aren’t 100% reliable, sinc e the applic atio n pro grammer
must explic itly send the info rmatio n to the printer o r write the c hanges to the
transac tio n lo g. If the pro grammer fo rgets to inc lude the appro priate c alls in their
pro gram, the info rmatio n is pretty muc h useless.
A database is the answer
While yo u c an use files to ho ld yo ur o rganizatio n’s data, yo u c an see that there are
a number o f pro blems asso c iated with this prac tic e. A database system so lves
these pro blems and o thers that yo u may no t have tho ught o f.
Tables, rows, and columns
Rec all that a database ho lds info rmatio n in tables that c o rrespo nd to rando m ac c ess
files. Eac h rec o rd in the file c o rrespo nds to a ro w in the table. Eac h field in the file
c o rrespo nds to a c o lumn in the table. Unlike a rec o rd, yo u c an c ho o se whic h c o lumns
yo u wish to retrieve fro m a table. By retrieving o nly the c o lumns yo u need, yo u help
to iso late yo ur pro gram fro m c hanges in the table. This means yo u c an add and
delete c o lumns fro m a table, and as lo ng as yo ur pro gram do esn’t referenc e any o f
these c o lumns, yo ur pro gram will c o ntinue to wo rk witho ut c hange.
The c o nc ept o f a relative rec o rd number isn’t available to lo c ate a ro w in a table. It
has been replac ed with a mo re po werful c o nc ept kno wn as the primary ke y. The primary key is a set o f o ne o r mo re fields who se values will uniquely identify a ro w in a
table. Where yo u may have used an emplo yee number o r part number as the relative rec o rd number in a rando m ac c ess file, yo u c an no w use an arbitrary set o f values to lo c ate the ro w. This gives yo u a lo t mo re flexibility when designing a table.
Locking
Just as yo u use lo c king to prevent two pro grams fro m ac c essing the same data in a
file-o riented applic atio n, the database management system uses lo c king to prevent
the same thing fro m happening. The database system auto matic ally determines ho w
to use lo c ks to prevent two o r mo re pro grams fro m ac c essing the same data at the
same time. Unlike file-o riented applic atio ns, where the entire file is lo c ked, the
database system is smart eno ugh to allo w pro grams to update data in the same
table at the same time as lo ng as all o f the pro grams are all ac c essing different ro ws.
7
8
Part I ✦ Database Programming Fundamentals
Yo u c an get a big perfo rmanc e bo o st in yo ur applic atio n bec ause a database permits multiple pro grams to ac c ess data in the same table at the same time. With filebased applic atio ns, o ne pro gram had to c o mplete the read, pro c ess, and update
sequenc e befo re the next pro gram c o uld start. This translates into lo nger and
lo nger delays as mo re and mo re users try to ac c ess the files at the same time. Sinc e
the database system permits multiple, no n-c o nflic ting read, pro c ess, and update
sequenc es to be ac tive at the same time, the wait time is no lo nger a fac to r.
Security
Database systems are designed fro m the gro und up to be sec ure. Yo u c an spec ify
whic h users c an ac c ess whic h data in whic h fashio n. Sinc e the sec urity is mo ved
o utside the applic atio n, it is muc h easier to verify that o nly pro perly autho rized
users c an ac c ess a piec e o f info rmatio n.
Restoring lost data
Unlike a c o llec tio n o f rando m-ac c ess files, a database system has a c o mprehensive
mec hanism to ensure that o nc e data has been written to the database, it isn’t lo st.
A database system inc ludes to o ls that will bac k up the database in a way that will
prevent the pro blem where so me o f the c hanges are c aptured, while o thers aren’t.
This means that yo u c an always resto re yo ur database to a c o nsistent state.
Also , a database system inc ludes an integrated transac tio n lo g that will auto matic ally
c apture all o f the c hanges to the database. When yo u have to resto re a database, the
resto re pro c ess c an auto matic ally pro c ess the transac tio n lo g. All o f the transac tio ns
written to the lo g will be rec o vered, whic h means that the data will be c o rrec t as o f
the mo ment befo re yo ur disk c rashed.
Database Architecture
Nearly all database systems available o n the market to day are implemented using a
clie nt/se rve r arc hitec ture. This arc hitec ture defines two types o f pro grams and ho w
they interac t with eac h o ther.
Servers and clients
A clie nt is a pro gram that generates requests that are sent to ano ther pro gram,
c alled a se rve r, fo r exec utio n. When the server has finished the request, the results
are returned to the c lient. In to day’s c o mputing enviro nment, many applic atio ns are
implemented using c lient/ server tec hno lo gy. Fo r instanc e, yo ur Web bro wser is a
c lient pro gram that talks to a Web server. A file server c o ntains files that are made
available to yo u o ver a netwo rk. Likewise, a print server allo ws a netwo rk manager
to share a single printer with many different users.
Chapter 1 ✦ Basic Concepts
Note
Servers, clients, hardware, software, and confusion: The term s client and server
are often used to describe both the softw are applications and the hardw are they
run on. This can lead to som e confusion. It is quite possible that you m ay use a
Web brow ser (client) application to access a Web server on the sam e com puter.
For exam ple, I frequently test new Web pages on a test Web server running on the
sam e com puter as the brow ser before uploading them to a production Web
server. In general, w hen I use the term s client and server I’m referring to the softw are applications and not the physical m achines they run on.
Database servers and database clients
A database se rve r is a pro gram that rec eives database re que sts fro m a database clie nt
and pro c esses the requests o n the database c lient’s behalf (see Figure 1-2). A
database c lient is a pro gram that generates database requests by interac ting with a
user, pro c essing a data file o r in respo nse to a partic ular event in yo ur c o mputer. A
database request is a spec ific o peratio n that is to be perfo rmed by the database
server, suc h as returning data fro m a table, updating o ne o r mo re ro ws in a table, o r
perfo rming so me o ther database management task.
Database Request
Database Client
Database Server
Response from the
Database Server
Figure 1-2: Database clients send database requests to a database server for
processing.
Database servers
A database server typic ally runs o n its o wn c o mputer system and rec eives
database requests ac ro ss a netwo rk. If the request generates a respo nse, then the
respo nse is returned to the database c lient c o mputer o ver the netwo rk. This
arrangement iso lates the database server fro m eac h o f the database c lients, whic h
impro ves the perfo rmanc e and reliability o f the database system.
A spec ial so ftware pac kage kno wn as the Database Manage me nt Syste m (DBMS) is
run o n the database server. It is this so ftware that rec eives database requests, pro c esses them, and returns the resulting info rmatio n bac k to the database c lient.
9
10
Part I ✦ Database Programming Fundamentals
The database server is typic ally run o n an o perating system designed to suppo rt
servers, suc h as Windo ws 2000/ NT Server o r any o f the vario us flavo rs o f Unix.
Deskto p o perating systems suc h as Windo ws 98/ 95 do n’t pro vide the reliability o r
stability nec essary to run a database server.
In small enviro nments, yo u c an run several different servers o n yo ur server c o mputer — suc h as a file server, Web server, mail server and transac tio n server — in
additio n to yo ur database server. Ho wever, as yo ur wo rklo ad inc reases, it will
bec o me desirable to dedic ate c o mputers to eac h o f these func tio ns.
This type o f arrangement wo uld allo w yo u to sc ale the size o f eac h c o mputer system to ac c o mmo date yo ur wo rklo ad. Yo u c an add mo re memo ry, faster CPUs and
mo re disk spac e to keep pac e with inc reases in yo ur wo rklo ad. Also , by dedic ating
a c o mputer to running the database server, yo u run less o f a risk o f a system c rash
bec ause o f a so ftware pro blem in ano ther server suc h as the transac tio n server.
Database clients
The database c lient is simply an applic atio n running o n the same netwo rk as the
database server that requests info rmatio n fro m the database. The applic atio n pro gram generates database requests using an Applicatio ns Pro gramming Inte rface
(API), whic h is no thing mo re than a set o f subro utine c alls o r set o f o bjec ts that
yo ur pro gram uses to send requests to the database and rec eive info rmatio n fro m
the database.
The API allo ws the pro gram to c o mmunic ate with mo re than o ne database system
thro ugh the use o f a spec ial piec e o f c o de kno wn as a database drive r. A database
driver represents a spec ial pro gram that is installed o n the database c lient c o mputer. It translates the standardized database requests made using the API into the
spec ial language used by the spec ific database server.
By using database drivers, the same applic atio n pro gram c an c o mmunic ate with
different database systems witho ut c hanging the applic atio n itself. This level o f
independenc e is impo rtant sinc e it allo ws an o rganizatio n to replac e o ne database
system with ano ther with o nly a minimal impac t to the applic atio ns themselves.
Simple database systems
While mo st datab ase systems fall into the c lient/ server arc hitec ture I desc rib ed
ab o ve, a few simple datab ase systems wo rk differently. These are typic ally lo wend datab ase systems where perfo rmanc e and sc alab ility issues are no t a pro b lem. These systems still c o mmunic ate with yo ur applic atio n via a standard API,
b ut instead o f passing req uests o nto a datab ase server o n a different c o mputer,
they pass the req uests to c o de residing in the c lient c o mputer.
Chapter 1 ✦ Basic Concepts
This database c o de in the lo c al c lient c o mputer is designed to c o o perate with o ther
c o pies o f the database c o de running in o ther c o mputers to ac c ess a c o mmo n file o r
set o f files lo c ated so mewhere o n the netwo rk. The database files c o uld be lo c ated
o n the same c o mputer as o ne o f the database c lients, o r lo c ated o n a c entral file
server. A lo w-end database system is also a go o d c ho ic e if yo u are designing a
stand-alo ne applic atio n fo r a single user.
Administratio n o f these database systems is fairly easy. Bac king up the database is
ac c o mplished by bac king up the file c o ntaining the database, and rec o very pro c esses
are limited to resto ring a bac ked-up versio n o f the database.
Of c o urse this appro ac h c an have a big impac t o n perfo rmanc e, bec ause lo c king
must no w be do ne at the file level rather than based o n the values selec ted fro m
the database. While this will o bvio usly hurt an applic atio n with many users, the
o verhead is lo w eno ugh that fo r a handful o f users, the perfo rmanc e may ac tually
be better than the c lient/ server arc hitec ture.
Types of Databases
There are fo ur basic types o f database systems: hierarc hic al, netwo rked, indexed
and relatio nal. While eac h o f the fo ur types has many similar c o nc epts, their differenc es result fro m ho w they sto re their data.
Hierarchical databases
The hie rarchical database is the o ldest fo rm o f database in existenc e. Data is
arranged in a series o f tree struc tures, whic h o ften reflec t the natural relatio nship
between data. IBM’s IMS database, whic h is still available to day, is the c lassic example o f a hierarc hic al database.
A hierarc hy mo dels a data relatio nship kno wn as 1 to many . A 1 to many relatio nship
means that o ne data value is related to o ne o r mo re o ther data values. The c lassic
example fo r this type o f relatio nship is students and c lasses. When students attend
sc ho o l, they take many c lasses, a situatio n whic h c an be desc ribed with a natural
hierarc hy (see Figure 1-3).
Networked databases
The ne two rke d database was develo ped as an alternative to the hierarc hic al database.
While a lo t o f data c an be o rganized using a hierarc hic al relatio nship, it is diffic ult to
mo del o ther data relatio nships. Co nsider the c ase o f students and their teac hers. A
student will take c o urses fro m many different teac hers, whereas a teac her will teac h
mo re than o ne student (see Figure 1-4). This relatio nship is c alled many to many.
11
12
Part I ✦ Database Programming Fundamentals
Student Body
Christopher James
Samantha Ashley
Terry Katz
CM SC 101
CM SC 101
ENGL 101
M ATH 101
ENGL 101
GOVT 101
PSYC 101
PSYC 101
PSYC 101
Figure 1-3: A hierarchical database reflects the natural relationship
betw een data.
Student Body
Christopher James
Samantha Ashley
Robert Weiler (M ATH 101)
Terry Katz
Raymond Bucky (GOVT 101)
Wayne Freeze (CM SC 101)
Jill Heyer (ENGL 101)
Bonnie Jean (PSYC 101)
Figure 1-4: A netw orked database can handle situations that a hierarchical
database cannot.
Chapter 1 ✦ Basic Concepts
A netwo rked database sto res info rmatio n in datasets, whic h are similar to files and
tables. A rec o rd o n o ne dataset that is related to a set o f rec o rds in ano ther dataset
will have a set o f physic al po inters, also kno wn as a link. Thus the rec o rd in the first
dataset is linked to the rec o rds in the sec o nd dataset. The primary drawbac k to
netwo rked databases is that it c an be quite c o mplic ated to maintain all o f the links.
A single bro ken link c an lead to eno rmo us pro blems in the database.
Indexed databases
While similar in c o nc ept to a netwo rked database, an inde xe d database replac es
links with an inve rte d list. An inverted list is ano ther file that c o ntains a list o f
unique values fo und in a partic ular field in a dataset, alo ng with po inters to eac h
rec o rd in whic h the value appears. This value is kno wn as a ke y value . If yo u kno w
the key value, yo u c an quic kly list all o f the rec o rds in the dataset that c o ntain that
value. In prac tic e, an indexed database is the mo st effic ient database system in the
marketplac e to day.
Relational databases
The c o nc ept o f the re latio nal database manage me nt syste m ( RDBMS) go es bac k to
the early 1970’s, when IBM researc hers were lo o king fo r a better way to manage
data. One o f the pro blems with hierarc hic al, netwo rked, and indexed databases is
that they all require po inters to c o nnec t data to gether. The researc hers built a
mathematic al mo del, whic h disc arded the po inters and used c o mmo n values to
link multiple rec o rds to gether. Thus, yo u weren’t limited to hierarc hic al struc tures
as in the hierarc hic al database mo del, and yo u didn’t have to set links as in the
netwo rked database mo del. ( The indexed mo del evo lved after the o riginal wo rk
was do ne o n the relatio nal database mo del.)
The primary drawbac k to the relatio nal database mo del is that a relatio nal
database is very slo w when c o mpared to the o ther database mo dels. Witho ut
po inters to help yo u quic kly lo c ate a partic ular rec o rd, yo u may have to read
every rec o rd in a table to find o ne partic ular rec o rd. To help c o mbat this pro blem,
the c o nc ept o f an inde x was intro duc ed. Even with indexes, relatio nal databases
are generally less effic ient than databases implemented using the o ther database
mo dels. Ho wever, the relatio nal database gained po pularity as c o mputing began to
shift fro m traditio nal mainframe c o mputers to smaller mini-c o mputers and perso nal c o mputers. The initial applic atio ns o f relatio nal databases were far less
demanding than the database systems running o n mainframes, so the perfo rmanc e
issues were no t as muc h o f a fac to r as they c o uld have been. As time went o n, the
speed o f mini-c o mputers and perso nal c o mputers inc reased to the po int where
they rivaled mainframe c o mputers.
CrossReference
See Chapter 2 for a m ore in-depth discussion of relational databases.
13
14
Part I ✦ Database Programming Fundamentals
Common Databases
In to day’s marketplac e there are a number o f relatio nal database systems yo u c an
use. In this bo o k, ho wever, I’m go ing to fo c us o n o nly three: Mic ro so ft SQL Server
7.0, Mic ro so ft Jet 3.5/ 4.0 and Orac le 8i. These three database systems make up the
majo rity o f the database systems in the wo rld to day, at least fro m the Visual Basic
pro grammer’s perspec tive. Altho ugh there are o ther database systems that run in
the mainframe wo rld, suc h as CA’s IDMS and IBM’s IMS, they aren’t typic ally used
by Visual Basic pro grammers.
SQL Server 7.0
One o f Mic ro so ft’s majo r design go als with SQL Server 7.0 was to c reate a sc alab le
pro duc t that ran the same o n a Windo ws 98 system with limited memo ry and disk
spac e, up to a large Windo ws 2000/ NT Server system with multiple pro c esso rs,
gigab ytes o f main memo ry, and lo ts o f disk spac e. To ac c o mplish this, Mic ro so ft
c reated three versio ns o f SQL Server. The Deskto p Editio n runs o n Windo ws 98
and Windo ws 2000/ NT Wo rkstatio n. It’s designed to handle smaller datab ases and
is ideal fo r helping develo pers test their pro grams away fro m the pro duc tio n
datab ase server. The Standard Editio n is the mo st c o mmo n editio n and pro vides
the features that yo u really need fo r mo st applic atio ns. The Enterprise Editio n
expands the Standard Editio n b y adding features that help SQL Server handle
applic atio ns with a lo t o f data and a large numb er o f transac tio ns.
Besides fo c using o n sc alability, Mic ro so ft also wo rked hard to reduc e the to tal c o st
o f o wnership fo r a database system. Mo dern relatio nal databases are o ften served
by a gro up o f spec ialists kno wn as database administrato rs. These peo ple are expensive to hire and diffic ult to keep, due to the inc reasing demand fo r their skills. SQL
Server 7.0 addresses this pro blem by inc luding a number o f wizards that make it
easy to perfo rm ro utine tasks. Also the SQL Server Agent c an be used to run vario us ac tivities when yo ur mac hine is left unattended.
Note
A good primer: See Microsoft SQL Server 7 for Dummies by Anthony T. Mann for
m ore detailed inform ation about how to adm inister an SQL Server 7 database
server.
Mic ro so ft also addressed data wareho using applic atio ns by inc luding two key features in SQL Server 7. The first is the Data Transfo rmatio n Se rvice s (DTS). This feature
makes it easy to mo ve data fro m o ne plac e to ano ther. This is partic ularly impo rtant,
sinc e the data in a data wareho use is usually taken fro m tac tic al applic atio ns like
ac c o unting and invento ry systems, even if they exist o n the c o rpo rate mainframe.
Chapter 1 ✦ Basic Concepts
The sec o nd key feature is OLAP Se rvice s (OLAP stands fo r o nline analytic al pro c essing). These servic es bridge the gap between the data wareho use and the analysis
to o ls running o n the user’s wo rkstatio n. The data wareho use data is prepro c essed
in the OLAP server befo re the results are presented to the analysis to o l. Mic ro so ft
has made the applicatio n pro gramming inte rface (API) to OLAP Servic es available,
so that o ther c o mpanies c an design c lient to o ls to analyze OLAP data.
M icrosoft Jet 3.5/ 4.0
Mic ro so ft Ac c ess is a simple deskto p database applic atio n develo pment to o l that is
targeted at small- to medium-sized o rganizatio ns. At the heart o f Ac c ess is a true
relatio nal database engine kno wn as Mic ro so ft Jet. Like SQL Server, Jet is based o n
the SQL standard. Unlike SQL Server, the database c o de runs in the applic atio n itself
rather than in a database server. Also , bec ause Jet was develo ped independently o f
SQL Server, it isn’t to tally c o mpatible with SQL Server.
Even tho ugh Jet is develo ped as part o f Mic ro so ft Ac c ess, Jet is inc luded with
Visual Basic . Yo u c an develo p applic atio ns using Jet and freely distribute the Jet
runtime c o de with yo ur applic atio n. Yo u c an’t do this with SQL Server applic atio ns.
Jet 3.5 is the versio n o f Jet that shipped with Ac c ess 97 and Visual Basic 6, while
Jet 4.0 is the versio n shipped with Ac c ess 2000. While Jet 4.0 o ffers so me impro vements o ver Jet 3.5, yo u sho uld pro bably stic k with Jet 3.5 unless yo u need to share
yo ur database with an Ac c ess 2000 applic atio n, sinc e Ac c ess 2000 wo rks o nly with
Jet 4.0.
Oracle 8 i
Orac le 8i is a high perfo rmanc e database system that runs o n many different o perating systems. While SQL Server is available o nly fo r Windo ws-based systems,
Orac le 8i runs o n everything fro m small Linux systems to large Sun So laris-based
systems and IBM mainframes running MVS/ ESA o r OS/ 390. Of c o urse it also runs
o n Windo ws 2000/ NT. Sinc e the same c o de base is used fo r all o f the different platfo rms, Orac le 8i applic atio ns need no t wo rry abo ut the c o mputer that is ho sting
the database server.
Like SQL Server, Orac le 8i is available in several editio ns. The Standard Editio n represents the mo st c o mmo n fo rm o f Orac le 8i, and is suitable fo r mo st database applic atio ns. Orac le 8i Enterprise Editio n is designed to suppo rt high-vo lume o nline
transactio n pro ce ssing (OLTP) applic atio ns and query-intensive data wareho uses.
Orac le 8i Perso nal Editio n is targeted at single user develo pment and deplo yment
applic atio ns.
15
16
Part I ✦ Database Programming Fundamentals
Thoughts on Database Systems
Although the architecture of a database system m ay perm it you to w rite an application program that w ill w ork w ith several different database system s, reality is a lot different than
theory.
Most database system s offer assorted extensions that can im prove the perform ance and
abilities of m ost applications. How ever, if you take advantage of these extensions, your
application becom es tied to a single database system . While this isn’t necessarily bad, it is
som ething to consider if you think you m ay change database system s in the future. The key
to addressing this problem is to design your database and your application so that they only
contain features that are com m on to all of the database system s you m ay use.
Isolating the database system from the application is even m ore im portant if you are developing applications for resale. Most likely your custom ers w ill already have an investm ent in
a database system and w ould prefer that your application use that database system rather
than having to invest in a totally new database system .
Isolating your application from your database system is m ore difficult than you m ight
believe. This is especially true if you use only one type of database system . You’ll often find
yourself in situations that are easier to solve if you use a database system -specific feature
than if you solve it in a m ore general-purpose w ay. This isn’t necessarily bad, and often w ill
allow you to build a better application in the long run.
If you plan to use only one database system , selecting the proper one is very im portant.
Although m any people pick a database by finding the one w ith the best set of features, you
really should look for a database that w ill be around in five or ten years. Over tim e, a feature that is found in only one database m anagem ent system w ill be included in the other
system s in their next release. After a few releases, those features that you found very im portant w hen you picked your database vendor aren’t all that im portant anym ore.
Evaluate a database vendor in term s of their com m itm ent to their database system . A vendor that is constantly im proving their database is m uch better than a database vendor that
doesn’t. A lack of enhancem ents over a long period of tim e m eans that people w ill tend to
select other databases to fit their needs. Eventually, if the enhancem ents stop, the vendor
w ill stop supporting the database system and you m ay find yourself in a situation w here all
of your applications are so dependent on one database system that you can’t m ove them
to another database system .
Chapter 1 ✦ Basic Concepts
Summary
In this c hapter yo u learned that:
✦ Database systems have many advantages o ver using c o nventio nal files to ho ld
yo ur data, inc luding better c o nc urrenc y c o ntro ls, better sec urity, and better
bac kup and rec o very mec hanisms.
✦ Database systems are usually implemented using c lient/ server arc hitec tures.
✦ The different types o f databases inc lude the hierarc hic al, netwo rked, indexed,
and relatio nal mo dels.
✦ SQL Server 7.0, Oracle 8i and Jet are three o f the mo st c o mmo n database systems that a Visual Basic pro grammer is likely to enc o unter.
✦
✦
✦
17
C H A P T E R
Basic Concepts
I
n this c hapter, I’m go ing to intro duc e yo u to the c o nc epts
behind databases and why databases are impo rtant to
yo ur applic atio n pro gram. I’ll also c o ver different database
arc hitec tures and fo llo w that up with a brief o verview o f the
database systems to be c o vered in this bo o k.
✦
✦
✦
✦
In This Cha pter
W hy use a
database?
Database architecture
Why Use a Database?
A database is simply a general-purpo se to o l that allo ws yo u to
sto re any info rmatio n yo u want that c an be read and updated
by o ne o r mo re c o nc urrent applic atio n pro grams in a sec ure
and reliable fashio n. No te that while this definitio n desc ribes
c o nventio nal database systems suc h as SQL Server and Orac le
8i, it c an also be used to desc ribe a c o llec tio n o f no rmal disk
files. I want to explo re these c o nc epts using c o nventio nal disk
files to help yo u better understand why yo ur applic atio n needs
a database system.
Storing information
There are many ways to sto re info rmatio n o n a c o mputer, but
eventually all o f them bo il do wn to plac ing info rmatio n in a file
so mewhere o n a disk drive. There are two basic types o f files,
whic h are c harac terized by ho w they are ac c essed. Se que ntial
acce ss files are ac c essed as a single unit, while rando m acce ss
files allo w yo u to direc tly ac c ess the file in small piec es.
Using conventional file access
In o rder to pro c ess the data in a sequential ac c ess file, yo u
must read o r write the entire file. This type o f ac c ess is useful
fo r a wo rd pro c esso r where yo u want to make all o f the info rmatio n in the file available to the user at the same time.
Co mmo n databases
✦
✦
✦
✦
4
Part I ✦ Database Programming Fundamentals
Generally a pro gram will lo ad the entire file into memo ry, make whatever c hanges
are nec essary, and then save the entire file when the user is ready to exit the
pro gram.
When dealing with sequential ac c ess files, yo u need no t lo ad the entire file into
memo ry. Indeed, many pro grams merely lo ad eno ugh data fro m the file to perfo rm
a given task and lo ad mo re data when the task is c o mplete. The main idea is that
yo ur pro gram reads the data fro m the beginning o f the file to the end in a linear
fashio n. Henc e the term se que ntial.
In mo st applic atio n pro grams, yo u o nly want to ac c ess a subset o f the data at a given
po int in time, so rather than pro c essing the entire file just to get a small piec e o f data,
a rando m ac c ess file allo ws yo u to divide the file into c hunks c alled re co rds. (See
“Organizing data in rec o rds,” belo w fo r details.) Eac h rec o rd has a unique rec o rd
number, whic h is determined by its relative po sitio n in the file. Yo u c an retrieve o r
update any rec o rd in the file by spec ifying the appro priate rec o rd number.
The key to making rando m ac c ess files wo rk is that eac h rec o rd in the file is always
the same size. This allo ws yo u to determine the lo c atio n o f the rec o rd by c o mputing the starting byte o f the rec o rd, just by kno wing the size o f the rec o rd and the
relative rec o rd number in the file.
Even tho ugh a rando m ac c ess file may be o rganized differently than a sequential
ac c ess file, yo u c an also pro c ess a rando m ac c ess file sequentially by reading the
rec o rds in o rder o f their rec o rd numbers. This implies that yo u do n’t lo se any func tio nality o f a sequential ac c ess file if yo u c ho o se to c reate yo ur file as rando m
ac c ess.
Organizing data in records
A rec o rd represents a c hunk o f data c o ntained in a file and is o rganized into o ne
o r mo re fie lds. Eac h field has a spec ific name and data type asso c iated with it.
The name is used to uniquely identify the field in the rec o rd, and the data type
desc ribes what kind o f info rmatio n the field c an ho ld.
CrossReference
See “Colum ns and Data Types” in Chapter 2 for m ore inform ation on this topic.
Bec ause eac h rec o rd in the file always ho lds the same info rmatio n, yo u c an think o f
a file full o f rec o rds as a table o r grid, where eac h rec o rd c o rrespo nds to a ro w and
eac h field c o rrespo nds to a c o lumn (see Figure 1-1). The table c o nc ept also c o nveys
the c o nc ept o f ho w the info rmatio n is ac tually sto red in the file, sinc e the relative
po sitio n o f eac h field is fixed in relatio n to the o ther fields and the relative rec o rd
number uniquely identifies the rec o rd’s plac e in the table.
Chapter 1 ✦ Basic Concepts
Name
Christopher James
Samantha Ashley
Terry Katz
Robert Weiler
Wayne Freeze
Bonnie Jean
Jill Heyer
Raymond Bucky
Address
1234 M ain Street
2345 Central Avenue
3456 Pennsylvania Ave
4567 Redw ood Way
5678 Baltimore Street
6789 Oak Street
7890 Washington Drive
8901 Souix Circle
City
College Park
College Park
College Park
College Park
College Park
College Park
College Park
College Park
State
MD
MD
MD
MD
MD
MD
MD
MD
Zip Code
20742
20742
20742
20742
20742
20742
20742
20742
Figure 1-1: A file w ith records looks like a grid or a table.
Concurrency
One o f the mo st c ritic al issues to c o nsider when dealing with an applic atio n is
ensuring that two o r mo re c o nc urrently-running pro grams do n’t interfere with
eac h o ther while pro c essing data. If the pro per steps aren’t taken, it wo uld be easy
fo r o ne pro gram to destro y info rmatio n that ano ther pro gram c hanged in the file.
Fo r instanc e, assume that yo u have a rando m ac c ess file that c o ntains c usto mers’
c hec king ac c o unt balanc es. Then assume that yo u have o ne pro gram that debits
the ac c o unt fo r c hec ks that the c usto mer wro te, while ano ther pro gram c redits
c usto mer depo sits. While this sc enario is unlikely, it is po ssible that the two pro grams may attempt to update the same c usto mer rec o rd at the same time.
No w, c o nsider the fo llo wing seq uenc e o f events. The deb it pro gram reads the
c usto mer’s rec o rd. Befo re the deb it pro gram has a c hanc e to update the info rmatio n, the c redit pro gram reads the c usto mer’s rec o rd and adds the depo sit to the
ac c o unt’s to tal b alanc e. After the c redit pro gram updates the c usto mer’s info rmatio n, the deb it pro gram c o mpletes its pro c ess b y writing its updated ac c o unt
b alanc e b ac k to the file. In this sc enario , the c redit to the ac c o unt was lo st, sinc e
the update do ne b y the deb it pro gram used an o ut-o f-date ac c o unt b alanc e.
The pro per way to prevent the c o nc urrenc y pro blem is by c o ntro lling ac c ess to the
data. Typic ally, this is do ne by lo cking the file to prevent o ther users fro m ac c essing
any o f the data in the file yo u want to use. The sequenc e o f events in the abo ve sc enario wo uld no w lo o k like this: The debit pro gram wo uld lo c k the file. Then it wo uld
read the c usto mer rec o rd. The c redit pro gram wo uld attempt to lo c k the file. Sinc e
the debit pro gram already lo c ked the file, the c lient pro gram wo uld be suspended.
The debit pro gram wo uld c o mplete its update and then release the lo c k o n the file.
The c redit pro gram wo uld be resumed and the lo c k wo uld be granted. It wo uld then
perfo rm its update and release the lo c k, thus ensuring that the c o rrec t balanc e
wo uld be in the file.
5
6
Part I ✦ Database Programming Fundamentals
Securing your data
In mo st c o mputer systems, yo u c an identify the users who are able to read o r
update a partic ular file, and deny ac c ess to all o thers using no rmal o perating system sec urity. Ho wever, it is o ften desirable to allo w so meo ne to see o nly part o f a
rec o rd — in a c ase, fo r instanc e, where yo u want to keep an emplo yee’s salary info rmatio n in the same rec o rd with the emplo yee’s address and telepho ne number.
To prevent peo ple fro m seeing salary info rmatio n, yo u have to c reate ano ther file
that c o ntains info rmatio n abo ut eac h perso n who c an ac c ess yo ur file and whic h
fields they are permitted to ac c ess. Then yo ur applic atio n pro grams must pro perly
use this info rmatio n to prevent unwanted ac c ess to data.
Of c o urse this metho d is o nly as reliable as yo ur applic atio n pro gramming staff.
One small mistake in a pro gram c o uld allo w a user to read and/ o r c hange the value
that they sho uldn’t have ac c ess to .
Performing backups and using transaction logs
No matter what yo u do to yo ur data, yo u need to ensure that o nc e a c hange has
been made to it, it wo n’t be lo st. After all, it is po ssible that yo ur hard disk c o uld
c rash and destro y yo ur files o r yo ur c o mputer c o uld suffer a po wer failure while
the files were being updated.
There are a number o f different ways to prevent yo ur data fro m being lo st. The
mo st c o mmo n prac tic e is to bac k up yo ur data o n a regular basis. Of c o urse yo u
c an’t permit any users to update data while yo u’re do ing this, o r yo ur data files may
be in an inc o nsistent state bec ause so meo ne c hanged a value in o ne file befo re the
bac kup pro c ess c o pied the o ne file and after the bac kup pro c ess c o pied ano ther
file. Alternate ways to prevent yo u fro m lo sing yo ur data inc lude using redundant
disk drives and/ o r database servers so that yo ur data will still exist even if yo u lo se
a disk drive o r server. Ho wever, I stro ngly rec o mmend that yo u bac k up yo ur data
even if yo u use redundant equipment, just in c ase yo u lo se bo th yo ur primary c o py
and yo ur redundant c o py.
Mo st applic atio ns bac k up their data o nc e a day, whic h limits the amo unt o f data
yo u might lo se to a maximum o f a single day. But lo sing even half a day’s wo rth o f
info rmatio n c an be a big pro blem in mo st situatio ns. Fo r instanc e, in the c ase o f a
mail-o rder pro c essing applic atio n, yo u always have the o riginal o rder do c uments
that yo u c an reenter. Ho wever, in the c ase o f a telepho ne o rder pro c essing applic atio n, yo u may no t even kno w whic h c usto mers plac ed an o rder if yo u lo se yo ur
files, and even if yo u did, do yo u really want to c all all o f yo ur c usto mers bac k to
find o ut what they o rdered?
Chapter 1 ✦ Basic Concepts
There are a c o uple o f so lutio ns to this pro blem. First yo u c an print every c hange
yo u make to the files o n a printer. This way, yo u will always have a paper rec o rd o f
the c hanges, and c an reenter the info rmatio n if yo u need to .
A better way wo uld be to write all o f yo ur c hanges to a spec ial file kno wn as a transactio n lo g. This file inc ludes o nly the c hanges that were made to the file. Thus, if yo u
have to resto re the file fro m the previo us day’s bac kup, yo u c o uld run a pro gram that
wo uld read the values fro m the transac tio n lo g and reapply them to the main file.
Bo th o f these appro ac hes aren’t 100% reliable, sinc e the applic atio n pro grammer
must explic itly send the info rmatio n to the printer o r write the c hanges to the
transac tio n lo g. If the pro grammer fo rgets to inc lude the appro priate c alls in their
pro gram, the info rmatio n is pretty muc h useless.
A database is the answer
While yo u c an use files to ho ld yo ur o rganizatio n’s data, yo u c an see that there are
a number o f pro blems asso c iated with this prac tic e. A database system so lves
these pro blems and o thers that yo u may no t have tho ught o f.
Tables, rows, and columns
Rec all that a database ho lds info rmatio n in tables that c o rrespo nd to rando m ac c ess
files. Eac h rec o rd in the file c o rrespo nds to a ro w in the table. Eac h field in the file
c o rrespo nds to a c o lumn in the table. Unlike a rec o rd, yo u c an c ho o se whic h c o lumns
yo u wish to retrieve fro m a table. By retrieving o nly the c o lumns yo u need, yo u help
to iso late yo ur pro gram fro m c hanges in the table. This means yo u c an add and
delete c o lumns fro m a table, and as lo ng as yo ur pro gram do esn’t referenc e any o f
these c o lumns, yo ur pro gram will c o ntinue to wo rk witho ut c hange.
The c o nc ept o f a relative rec o rd number isn’t available to lo c ate a ro w in a table. It
has been replac ed with a mo re po werful c o nc ept kno wn as the primary ke y. The primary key is a set o f o ne o r mo re fields who se values will uniquely identify a ro w in a
table. Where yo u may have used an emplo yee number o r part number as the relative rec o rd number in a rando m ac c ess file, yo u c an no w use an arbitrary set o f values to lo c ate the ro w. This gives yo u a lo t mo re flexibility when designing a table.
Locking
Just as yo u use lo c king to prevent two pro grams fro m ac c essing the same data in a
file-o riented applic atio n, the database management system uses lo c king to prevent
the same thing fro m happening. The database system auto matic ally determines ho w
to use lo c ks to prevent two o r mo re pro grams fro m ac c essing the same data at the
same time. Unlike file-o riented applic atio ns, where the entire file is lo c ked, the
database system is smart eno ugh to allo w pro grams to update data in the same
table at the same time as lo ng as all o f the pro grams are all ac c essing different ro ws.
7
8
Part I ✦ Database Programming Fundamentals
Yo u c an get a big perfo rmanc e bo o st in yo ur applic atio n bec ause a database permits multiple pro grams to ac c ess data in the same table at the same time. With filebased applic atio ns, o ne pro gram had to c o mplete the read, pro c ess, and update
sequenc e befo re the next pro gram c o uld start. This translates into lo nger and
lo nger delays as mo re and mo re users try to ac c ess the files at the same time. Sinc e
the database system permits multiple, no n-c o nflic ting read, pro c ess, and update
sequenc es to be ac tive at the same time, the wait time is no lo nger a fac to r.
Security
Database systems are designed fro m the gro und up to be sec ure. Yo u c an spec ify
whic h users c an ac c ess whic h data in whic h fashio n. Sinc e the sec urity is mo ved
o utside the applic atio n, it is muc h easier to verify that o nly pro perly autho rized
users c an ac c ess a piec e o f info rmatio n.
Restoring lost data
Unlike a c o llec tio n o f rando m-ac c ess files, a database system has a c o mprehensive
mec hanism to ensure that o nc e data has been written to the database, it isn’t lo st.
A database system inc ludes to o ls that will bac k up the database in a way that will
prevent the pro blem where so me o f the c hanges are c aptured, while o thers aren’t.
This means that yo u c an always resto re yo ur database to a c o nsistent state.
Also , a database system inc ludes an integrated transac tio n lo g that will auto matic ally
c apture all o f the c hanges to the database. When yo u have to resto re a database, the
resto re pro c ess c an auto matic ally pro c ess the transac tio n lo g. All o f the transac tio ns
written to the lo g will be rec o vered, whic h means that the data will be c o rrec t as o f
the mo ment befo re yo ur disk c rashed.
Database Architecture
Nearly all database systems available o n the market to day are implemented using a
clie nt/se rve r arc hitec ture. This arc hitec ture defines two types o f pro grams and ho w
they interac t with eac h o ther.
Servers and clients
A clie nt is a pro gram that generates requests that are sent to ano ther pro gram,
c alled a se rve r, fo r exec utio n. When the server has finished the request, the results
are returned to the c lient. In to day’s c o mputing enviro nment, many applic atio ns are
implemented using c lient/ server tec hno lo gy. Fo r instanc e, yo ur Web bro wser is a
c lient pro gram that talks to a Web server. A file server c o ntains files that are made
available to yo u o ver a netwo rk. Likewise, a print server allo ws a netwo rk manager
to share a single printer with many different users.
Chapter 1 ✦ Basic Concepts
Note
Servers, clients, hardware, software, and confusion: The term s client and server
are often used to describe both the softw are applications and the hardw are they
run on. This can lead to som e confusion. It is quite possible that you m ay use a
Web brow ser (client) application to access a Web server on the sam e com puter.
For exam ple, I frequently test new Web pages on a test Web server running on the
sam e com puter as the brow ser before uploading them to a production Web
server. In general, w hen I use the term s client and server I’m referring to the softw are applications and not the physical m achines they run on.
Database servers and database clients
A database se rve r is a pro gram that rec eives database re que sts fro m a database clie nt
and pro c esses the requests o n the database c lient’s behalf (see Figure 1-2). A
database c lient is a pro gram that generates database requests by interac ting with a
user, pro c essing a data file o r in respo nse to a partic ular event in yo ur c o mputer. A
database request is a spec ific o peratio n that is to be perfo rmed by the database
server, suc h as returning data fro m a table, updating o ne o r mo re ro ws in a table, o r
perfo rming so me o ther database management task.
Database Request
Database Client
Database Server
Response from the
Database Server
Figure 1-2: Database clients send database requests to a database server for
processing.
Database servers
A database server typic ally runs o n its o wn c o mputer system and rec eives
database requests ac ro ss a netwo rk. If the request generates a respo nse, then the
respo nse is returned to the database c lient c o mputer o ver the netwo rk. This
arrangement iso lates the database server fro m eac h o f the database c lients, whic h
impro ves the perfo rmanc e and reliability o f the database system.
A spec ial so ftware pac kage kno wn as the Database Manage me nt Syste m (DBMS) is
run o n the database server. It is this so ftware that rec eives database requests, pro c esses them, and returns the resulting info rmatio n bac k to the database c lient.
9
10
Part I ✦ Database Programming Fundamentals
The database server is typic ally run o n an o perating system designed to suppo rt
servers, suc h as Windo ws 2000/ NT Server o r any o f the vario us flavo rs o f Unix.
Deskto p o perating systems suc h as Windo ws 98/ 95 do n’t pro vide the reliability o r
stability nec essary to run a database server.
In small enviro nments, yo u c an run several different servers o n yo ur server c o mputer — suc h as a file server, Web server, mail server and transac tio n server — in
additio n to yo ur database server. Ho wever, as yo ur wo rklo ad inc reases, it will
bec o me desirable to dedic ate c o mputers to eac h o f these func tio ns.
This type o f arrangement wo uld allo w yo u to sc ale the size o f eac h c o mputer system to ac c o mmo date yo ur wo rklo ad. Yo u c an add mo re memo ry, faster CPUs and
mo re disk spac e to keep pac e with inc reases in yo ur wo rklo ad. Also , by dedic ating
a c o mputer to running the database server, yo u run less o f a risk o f a system c rash
bec ause o f a so ftware pro blem in ano ther server suc h as the transac tio n server.
Database clients
The database c lient is simply an applic atio n running o n the same netwo rk as the
database server that requests info rmatio n fro m the database. The applic atio n pro gram generates database requests using an Applicatio ns Pro gramming Inte rface
(API), whic h is no thing mo re than a set o f subro utine c alls o r set o f o bjec ts that
yo ur pro gram uses to send requests to the database and rec eive info rmatio n fro m
the database.
The API allo ws the pro gram to c o mmunic ate with mo re than o ne database system
thro ugh the use o f a spec ial piec e o f c o de kno wn as a database drive r. A database
driver represents a spec ial pro gram that is installed o n the database c lient c o mputer. It translates the standardized database requests made using the API into the
spec ial language used by the spec ific database server.
By using database drivers, the same applic atio n pro gram c an c o mmunic ate with
different database systems witho ut c hanging the applic atio n itself. This level o f
independenc e is impo rtant sinc e it allo ws an o rganizatio n to replac e o ne database
system with ano ther with o nly a minimal impac t to the applic atio ns themselves.
Simple database systems
While mo st datab ase systems fall into the c lient/ server arc hitec ture I desc rib ed
ab o ve, a few simple datab ase systems wo rk differently. These are typic ally lo wend datab ase systems where perfo rmanc e and sc alab ility issues are no t a pro b lem. These systems still c o mmunic ate with yo ur applic atio n via a standard API,
b ut instead o f passing req uests o nto a datab ase server o n a different c o mputer,
they pass the req uests to c o de residing in the c lient c o mputer.
Chapter 1 ✦ Basic Concepts
This database c o de in the lo c al c lient c o mputer is designed to c o o perate with o ther
c o pies o f the database c o de running in o ther c o mputers to ac c ess a c o mmo n file o r
set o f files lo c ated so mewhere o n the netwo rk. The database files c o uld be lo c ated
o n the same c o mputer as o ne o f the database c lients, o r lo c ated o n a c entral file
server. A lo w-end database system is also a go o d c ho ic e if yo u are designing a
stand-alo ne applic atio n fo r a single user.
Administratio n o f these database systems is fairly easy. Bac king up the database is
ac c o mplished by bac king up the file c o ntaining the database, and rec o very pro c esses
are limited to resto ring a bac ked-up versio n o f the database.
Of c o urse this appro ac h c an have a big impac t o n perfo rmanc e, bec ause lo c king
must no w be do ne at the file level rather than based o n the values selec ted fro m
the database. While this will o bvio usly hurt an applic atio n with many users, the
o verhead is lo w eno ugh that fo r a handful o f users, the perfo rmanc e may ac tually
be better than the c lient/ server arc hitec ture.
Types of Databases
There are fo ur basic types o f database systems: hierarc hic al, netwo rked, indexed
and relatio nal. While eac h o f the fo ur types has many similar c o nc epts, their differenc es result fro m ho w they sto re their data.
Hierarchical databases
The hie rarchical database is the o ldest fo rm o f database in existenc e. Data is
arranged in a series o f tree struc tures, whic h o ften reflec t the natural relatio nship
between data. IBM’s IMS database, whic h is still available to day, is the c lassic example o f a hierarc hic al database.
A hierarc hy mo dels a data relatio nship kno wn as 1 to many . A 1 to many relatio nship
means that o ne data value is related to o ne o r mo re o ther data values. The c lassic
example fo r this type o f relatio nship is students and c lasses. When students attend
sc ho o l, they take many c lasses, a situatio n whic h c an be desc ribed with a natural
hierarc hy (see Figure 1-3).
Networked databases
The ne two rke d database was develo ped as an alternative to the hierarc hic al database.
While a lo t o f data c an be o rganized using a hierarc hic al relatio nship, it is diffic ult to
mo del o ther data relatio nships. Co nsider the c ase o f students and their teac hers. A
student will take c o urses fro m many different teac hers, whereas a teac her will teac h
mo re than o ne student (see Figure 1-4). This relatio nship is c alled many to many.
11
12
Part I ✦ Database Programming Fundamentals
Student Body
Christopher James
Samantha Ashley
Terry Katz
CM SC 101
CM SC 101
ENGL 101
M ATH 101
ENGL 101
GOVT 101
PSYC 101
PSYC 101
PSYC 101
Figure 1-3: A hierarchical database reflects the natural relationship
betw een data.
Student Body
Christopher James
Samantha Ashley
Robert Weiler (M ATH 101)
Terry Katz
Raymond Bucky (GOVT 101)
Wayne Freeze (CM SC 101)
Jill Heyer (ENGL 101)
Bonnie Jean (PSYC 101)
Figure 1-4: A netw orked database can handle situations that a hierarchical
database cannot.
Chapter 1 ✦ Basic Concepts
A netwo rked database sto res info rmatio n in datasets, whic h are similar to files and
tables. A rec o rd o n o ne dataset that is related to a set o f rec o rds in ano ther dataset
will have a set o f physic al po inters, also kno wn as a link. Thus the rec o rd in the first
dataset is linked to the rec o rds in the sec o nd dataset. The primary drawbac k to
netwo rked databases is that it c an be quite c o mplic ated to maintain all o f the links.
A single bro ken link c an lead to eno rmo us pro blems in the database.
Indexed databases
While similar in c o nc ept to a netwo rked database, an inde xe d database replac es
links with an inve rte d list. An inverted list is ano ther file that c o ntains a list o f
unique values fo und in a partic ular field in a dataset, alo ng with po inters to eac h
rec o rd in whic h the value appears. This value is kno wn as a ke y value . If yo u kno w
the key value, yo u c an quic kly list all o f the rec o rds in the dataset that c o ntain that
value. In prac tic e, an indexed database is the mo st effic ient database system in the
marketplac e to day.
Relational databases
The c o nc ept o f the re latio nal database manage me nt syste m ( RDBMS) go es bac k to
the early 1970’s, when IBM researc hers were lo o king fo r a better way to manage
data. One o f the pro blems with hierarc hic al, netwo rked, and indexed databases is
that they all require po inters to c o nnec t data to gether. The researc hers built a
mathematic al mo del, whic h disc arded the po inters and used c o mmo n values to
link multiple rec o rds to gether. Thus, yo u weren’t limited to hierarc hic al struc tures
as in the hierarc hic al database mo del, and yo u didn’t have to set links as in the
netwo rked database mo del. ( The indexed mo del evo lved after the o riginal wo rk
was do ne o n the relatio nal database mo del.)
The primary drawbac k to the relatio nal database mo del is that a relatio nal
database is very slo w when c o mpared to the o ther database mo dels. Witho ut
po inters to help yo u quic kly lo c ate a partic ular rec o rd, yo u may have to read
every rec o rd in a table to find o ne partic ular rec o rd. To help c o mbat this pro blem,
the c o nc ept o f an inde x was intro duc ed. Even with indexes, relatio nal databases
are generally less effic ient than databases implemented using the o ther database
mo dels. Ho wever, the relatio nal database gained po pularity as c o mputing began to
shift fro m traditio nal mainframe c o mputers to smaller mini-c o mputers and perso nal c o mputers. The initial applic atio ns o f relatio nal databases were far less
demanding than the database systems running o n mainframes, so the perfo rmanc e
issues were no t as muc h o f a fac to r as they c o uld have been. As time went o n, the
speed o f mini-c o mputers and perso nal c o mputers inc reased to the po int where
they rivaled mainframe c o mputers.
CrossReference
See Chapter 2 for a m ore in-depth discussion of relational databases.
13
14
Part I ✦ Database Programming Fundamentals
Common Databases
In to day’s marketplac e there are a number o f relatio nal database systems yo u c an
use. In this bo o k, ho wever, I’m go ing to fo c us o n o nly three: Mic ro so ft SQL Server
7.0, Mic ro so ft Jet 3.5/ 4.0 and Orac le 8i. These three database systems make up the
majo rity o f the database systems in the wo rld to day, at least fro m the Visual Basic
pro grammer’s perspec tive. Altho ugh there are o ther database systems that run in
the mainframe wo rld, suc h as CA’s IDMS and IBM’s IMS, they aren’t typic ally used
by Visual Basic pro grammers.
SQL Server 7.0
One o f Mic ro so ft’s majo r design go als with SQL Server 7.0 was to c reate a sc alab le
pro duc t that ran the same o n a Windo ws 98 system with limited memo ry and disk
spac e, up to a large Windo ws 2000/ NT Server system with multiple pro c esso rs,
gigab ytes o f main memo ry, and lo ts o f disk spac e. To ac c o mplish this, Mic ro so ft
c reated three versio ns o f SQL Server. The Deskto p Editio n runs o n Windo ws 98
and Windo ws 2000/ NT Wo rkstatio n. It’s designed to handle smaller datab ases and
is ideal fo r helping develo pers test their pro grams away fro m the pro duc tio n
datab ase server. The Standard Editio n is the mo st c o mmo n editio n and pro vides
the features that yo u really need fo r mo st applic atio ns. The Enterprise Editio n
expands the Standard Editio n b y adding features that help SQL Server handle
applic atio ns with a lo t o f data and a large numb er o f transac tio ns.
Besides fo c using o n sc alability, Mic ro so ft also wo rked hard to reduc e the to tal c o st
o f o wnership fo r a database system. Mo dern relatio nal databases are o ften served
by a gro up o f spec ialists kno wn as database administrato rs. These peo ple are expensive to hire and diffic ult to keep, due to the inc reasing demand fo r their skills. SQL
Server 7.0 addresses this pro blem by inc luding a number o f wizards that make it
easy to perfo rm ro utine tasks. Also the SQL Server Agent c an be used to run vario us ac tivities when yo ur mac hine is left unattended.
Note
A good primer: See Microsoft SQL Server 7 for Dummies by Anthony T. Mann for
m ore detailed inform ation about how to adm inister an SQL Server 7 database
server.
Mic ro so ft also addressed data wareho using applic atio ns by inc luding two key features in SQL Server 7. The first is the Data Transfo rmatio n Se rvice s (DTS). This feature
makes it easy to mo ve data fro m o ne plac e to ano ther. This is partic ularly impo rtant,
sinc e the data in a data wareho use is usually taken fro m tac tic al applic atio ns like
ac c o unting and invento ry systems, even if they exist o n the c o rpo rate mainframe.
Chapter 1 ✦ Basic Concepts
The sec o nd key feature is OLAP Se rvice s (OLAP stands fo r o nline analytic al pro c essing). These servic es bridge the gap between the data wareho use and the analysis
to o ls running o n the user’s wo rkstatio n. The data wareho use data is prepro c essed
in the OLAP server befo re the results are presented to the analysis to o l. Mic ro so ft
has made the applicatio n pro gramming inte rface (API) to OLAP Servic es available,
so that o ther c o mpanies c an design c lient to o ls to analyze OLAP data.
M icrosoft Jet 3.5/ 4.0
Mic ro so ft Ac c ess is a simple deskto p database applic atio n develo pment to o l that is
targeted at small- to medium-sized o rganizatio ns. At the heart o f Ac c ess is a true
relatio nal database engine kno wn as Mic ro so ft Jet. Like SQL Server, Jet is based o n
the SQL standard. Unlike SQL Server, the database c o de runs in the applic atio n itself
rather than in a database server. Also , bec ause Jet was develo ped independently o f
SQL Server, it isn’t to tally c o mpatible with SQL Server.
Even tho ugh Jet is develo ped as part o f Mic ro so ft Ac c ess, Jet is inc luded with
Visual Basic . Yo u c an develo p applic atio ns using Jet and freely distribute the Jet
runtime c o de with yo ur applic atio n. Yo u c an’t do this with SQL Server applic atio ns.
Jet 3.5 is the versio n o f Jet that shipped with Ac c ess 97 and Visual Basic 6, while
Jet 4.0 is the versio n shipped with Ac c ess 2000. While Jet 4.0 o ffers so me impro vements o ver Jet 3.5, yo u sho uld pro bably stic k with Jet 3.5 unless yo u need to share
yo ur database with an Ac c ess 2000 applic atio n, sinc e Ac c ess 2000 wo rks o nly with
Jet 4.0.
Oracle 8 i
Orac le 8i is a high perfo rmanc e database system that runs o n many different o perating systems. While SQL Server is available o nly fo r Windo ws-based systems,
Orac le 8i runs o n everything fro m small Linux systems to large Sun So laris-based
systems and IBM mainframes running MVS/ ESA o r OS/ 390. Of c o urse it also runs
o n Windo ws 2000/ NT. Sinc e the same c o de base is used fo r all o f the different platfo rms, Orac le 8i applic atio ns need no t wo rry abo ut the c o mputer that is ho sting
the database server.
Like SQL Server, Orac le 8i is available in several editio ns. The Standard Editio n represents the mo st c o mmo n fo rm o f Orac le 8i, and is suitable fo r mo st database applic atio ns. Orac le 8i Enterprise Editio n is designed to suppo rt high-vo lume o nline
transactio n pro ce ssing (OLTP) applic atio ns and query-intensive data wareho uses.
Orac le 8i Perso nal Editio n is targeted at single user develo pment and deplo yment
applic atio ns.
15
16
Part I ✦ Database Programming Fundamentals
Thoughts on Database Systems
Although the architecture of a database system m ay perm it you to w rite an application program that w ill w ork w ith several different database system s, reality is a lot different than
theory.
Most database system s offer assorted extensions that can im prove the perform ance and
abilities of m ost applications. How ever, if you take advantage of these extensions, your
application becom es tied to a single database system . While this isn’t necessarily bad, it is
som ething to consider if you think you m ay change database system s in the future. The key
to addressing this problem is to design your database and your application so that they only
contain features that are com m on to all of the database system s you m ay use.
Isolating the database system from the application is even m ore im portant if you are developing applications for resale. Most likely your custom ers w ill already have an investm ent in
a database system and w ould prefer that your application use that database system rather
than having to invest in a totally new database system .
Isolating your application from your database system is m ore difficult than you m ight
believe. This is especially true if you use only one type of database system . You’ll often find
yourself in situations that are easier to solve if you use a database system -specific feature
than if you solve it in a m ore general-purpose w ay. This isn’t necessarily bad, and often w ill
allow you to build a better application in the long run.
If you plan to use only one database system , selecting the proper one is very im portant.
Although m any people pick a database by finding the one w ith the best set of features, you
really should look for a database that w ill be around in five or ten years. Over tim e, a feature that is found in only one database m anagem ent system w ill be included in the other
system s in their next release. After a few releases, those features that you found very im portant w hen you picked your database vendor aren’t all that im portant anym ore.
Evaluate a database vendor in term s of their com m itm ent to their database system . A vendor that is constantly im proving their database is m uch better than a database vendor that
doesn’t. A lack of enhancem ents over a long period of tim e m eans that people w ill tend to
select other databases to fit their needs. Eventually, if the enhancem ents stop, the vendor
w ill stop supporting the database system and you m ay find yourself in a situation w here all
of your applications are so dependent on one database system that you can’t m ove them
to another database system .
Chapter 1 ✦ Basic Concepts
Summary
In this c hapter yo u learned that:
✦ Database systems have many advantages o ver using c o nventio nal files to ho ld
yo ur data, inc luding better c o nc urrenc y c o ntro ls, better sec urity, and better
bac kup and rec o very mec hanisms.
✦ Database systems are usually implemented using c lient/ server arc hitec tures.
✦ The different types o f databases inc lude the hierarc hic al, netwo rked, indexed,
and relatio nal mo dels.
✦ SQL Server 7.0, Oracle 8i and Jet are three o f the mo st c o mmo n database systems that a Visual Basic pro grammer is likely to enc o unter.
✦
✦
✦
17