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.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 ssfiles 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 r-matio n in the file available to the user at the same time.
1
1
✦
✦
✦
✦
In This Cha pter
W hy use a database?
Database architecture Co mmo n databases
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 mput-ing the startmput-ing byte o f the rec o rd, just by kno wmput-ing 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.
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.
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 b e 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 b alanc es. Then assume that yo u have o ne pro gram that deb its 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 ssib le 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 rma-tio 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 r-matio 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 ckingthe 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 e-nario 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.
Christopher James 1234 M ain Street College Park M D 20742 Samantha Ashley 2345 Central Avenue College Park M D 20742 Terry Katz 3456 Pennsylvania Ave College Park M D 20742 Robert Weiler 4567 Redw ood Way College Park M D 20742 Wayne Freeze 5678 Baltimore Street College Park M D 20742 Bonnie Jean 6789 Oak Street College Park M D 20742 Jill Heyer 7890 Washington Drive College Park M D 20742 Raymond Bucky 8901 Souix Circle College Park M D 20742
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 sys-tem 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 r-matio 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.
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 transac-tio 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 pri-mary 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 rela-tive rec o rd number in a rando m ac c ess file, yo u c an no w use an arbitrary set o f val-ues to lo c ate the ro w. This gives yo u a lo t mo re flexibility when designing a table.
Locking
Yo u c an get a big perfo rmanc e bo o st in yo ur applic atio n bec ause a database per-mits multiple pro grams to ac c ess data in the same table at the same time. With file-based 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 rarc 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
Servers, clients, hardware, software, and confusion:The term s clientand 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 soft-w are applications and not the physical m achines they run on.
Database servers and database clients
A database se rve ris a pro gram that rec eives database re que stsfro 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.
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 ba-c k to the database -c lient.
Database Client Database Server
Database Request Response from the
Database Server
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 m-puter — 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 sys-tem 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 m-puter. 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
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 differ-enc es result fro m ho w they sto re their data.
Hierarchical databases
The hie rarchical databaseis 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 exam-ple 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
Figure 1-3: A hierarchical database reflects the natural relationship betw een data.
Figure 1-4: A netw orked database can handle situations that a hierarchical database cannot.
Student Body
Samantha Ashley Terry Katz Christopher James
Robert Weiler (M ATH 101) Raymond Bucky (GOVT 101) Wayne Freeze (CM SC 101)
Bonnie Jean (PSYC 101)
Jill Heyer (ENGL 101) Student Body
Samantha Ashley Terry Katz Christopher James
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 databasereplac 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 b ac k to the early 1970’s, when IBM researc hers were lo o king fo r a b etter way to manage data. One o f the pro b lems with hierarc hic al, netwo rked, and indexed datab ases is that they all req uire po inters to c o nnec t data to gether. The researc hers b uilt 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 datab ase mo del, and yo u didn’t have to set links as in the netwo rked datab ase mo del. ( The indexed mo del evo lved after the o riginal wo rk was do ne o n the relatio nal datab ase mo del.)
The primary drawb ac k to the relatio nal datab ase mo del is that a relatio nal datab ase is very slo w when c o mpared to the o ther datab ase mo dels. Witho ut po inters to help yo u q uic kly lo c ate a partic ular rec o rd, yo u may have to read every rec o rd in a tab le to find o ne partic ular rec o rd. To help c o mb at this pro b lem, the c o nc ept o f an inde xwas intro duc ed. Even with indexes, relatio nal datab ases are generally less effic ient than datab ases implemented using the o ther datab ase mo dels. Ho wever, the relatio nal datab ase gained po pularity as c o mputing b egan to shift fro m traditio nal mainframe c o mputers to smaller mini-c o mputers and per-so nal c o mputers. The initial applic atio ns o f relatio nal datab ases were far less demanding than the datab ase 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 b een. 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.
See Chapter 2 for a m ore in-depth discussion of relational databases.
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 expen-sive 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 vari-o us ac tivities when yvari-o ur mac hine is left unattended.
A good primer: See Microsoft SQL Server 7 for Dum m iesby 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 fea-tures 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.
The sec o nd key feature is OLAP Se rvice s( OLAP stands fo r o nline analytic al pro c ess-ing) . 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 ve-ments o ver Jet 3.5, yo u sho uld pro b ab ly stic k with Jet 3.5 unless yo u need to share yo ur datab ase 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 8iis a high perfo rmanc e database system that runs o n many different o per-ating systems. While SQL Server is available o nly fo r Windo ws-based systems, Orac le 8iruns 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 plat-fo rms, Orac le 8iapplic atio ns need no t wo rry abo ut the c o mputer that is ho sting the database server.
Thoughts on Database Systems
Although the architecture of a database system m ay perm it you to w rite an application pro-gram 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 devel-oping 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 fea-ture 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 por-tant w hen you picked your database vendor aren’t all that im porpor-tant anym ore.
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 8iand Jet are three o f the mo st c o mmo n database sys-tems that a Visual Basic pro grammer is likely to enc o unter.
