Directory listing of http: uap.unnes.ac.id ebook biblebook Visual Basic 6 com & Library Books
2
C H A P T E R
The Relational
Database M odel
✦
✦
✦
✦
In This Cha pter
I
n this c hapter, I’m go ing to intro duc e yo u to the develo pment o f SQL language and why it’s impo rtant fo r relatio nal
databases. Then I’ll give yo u a brief o verview o f the vario us
struc tures in a relatio nal database.
Introducing the Structured
Query Language
Witho ut the Struc tured Query Language ( SQL) , relatio nal
databases might no t have bec o me as po pular as they are
to day. Their po pularity is due mo stly to ho w the relatio nal
database industry evo lved and the standards that were an
o utgro wth o f this evo lutio n. Of c o urse the business benefits
o f a relatio nal database also had a great deal o f impac t o n its
ac c eptanc e.
Relational history
While the rise in po pularity o f relatio nal databases appears
to be tied to the perso nal c o mputer revo lutio n, the histo ry o f
the relatio nal database begins muc h earlier. And the o rigins
o f the relatio nal database begin at the wo rld’s largest c o mputer c o mpany rather than at M.I.T.S., the unkno wn c o mpany
that designed the wo rld’s first perso nal c o mputer.
The prequel to SEQUEL
In the early 1970’s, o ne c o mpany do minated the c o mputer
business, muc h like Mic ro so ft do es to day. That c o mpany was
IBM. To day’s IBM bears little resemblanc e to the IBM o f that
era. To many peo ple at that time, c o mputer meant IBM. IBM
was a massive o rganizatio n that planned things years in
Intro ducing the
Structured Q uery
Lang uag e
Business benefits o f a
relatio nal database
Parts o f a relatio nal
database
✦
✦
✦
✦
20
Part I ✦ Database Programming Fundamentals
advanc e. This sho wed mo st dramatic ally in their researc h labs. They had
researc hers who se so le purpo se was to think abo ut alternate ways to perfo rm
c o mputing tasks witho ut regard to prac tic ality. One o f these researc hers was
Dr. E.F. Co dd.
In June 1970, Dr. Co dd published an artic le titled “A Relatio nal Mo del o f Data fo r
Large Shared Data Banks” in the jo urnal, Co mmunicatio ns o f the Asso ciatio n fo r
Co mputing Machine ry . This artic le presented a mathematic al theo ry fo r sto ring and
manipulating data using tabular data struc tures. This theo ry is the basis fo r the
mo dern relatio nal database.
SEQUEL and System/ R
The idea o f a relatio nal database was appealing fo r many reaso ns and IBM autho rized
a researc h pro jec t in the mid-1970’s to c reate a database system based o n that theo ry. This pro jec t bec ame kno wn as System/R. Alo ng with the wo rk o n the database
itself, wo rk was also underway to develo p a query language fo r the database. The
researc hers develo ped several different languages, inc luding o ne kno wn as SEQUEL
(Struc tured English QUEry Language).
In the late 1970’s, IBM dec ided to release System/ R to so me o f their key c usto mers
fo r evaluatio n. As part o f this evaluatio n pro c ess, the query language was renamed
SQL, altho ugh it c o ntinued to be pro no unc ed SEQUEL. The System/ R pro jec t c ame
to a c lo se in 1979, when IBM dec ided that the relatio nal database theo ries develo ped by Co dd ten years earlier were ready to be turned into a c o mmerc ial pro duc t.
Ingres and Oracle
IBM was no t the o nly c o mpany to wo rk o n relatio nal databases during the 1970’s.
So me pro fesso rs at the University o f Califo rnia’s Berkeley c o mputer labs also built
a relatio nal database kno wn as Ingres. The query language fo r this database was
kno wn as QUEL, whic h is sho rt fo r QUEry Language. Like SQL, this language was
based o n a highly struc tured fo rm o f the English language.
Ingres was also develo ped o n a Unix platfo rm, unlike System/ R, whic h ran o n an
IBM mainframe o perating system. At that time, Unix systems generally ran o n small
mini-c o mputers suc h as Digital’s VAX, whic h were muc h c heaper to ac quire and
o perate than mainframes. This made the database po pular with many universities
that used the database to teac h the fundamental c o nc epts o f relatio nal database
implementatio ns.
Eventually, so me o f the pro fesso rs left the Berkeley c o mputer lab s in 1980 and
fo rmed a c o mpany kno wn as Relatio nal Tec hno lo gy, Inc . to b uild a c o mmerc ial
versio n o f Ingres. Ingres still exists as a c o mmerc ial datab ase, tho ugh it hasn’t
ac hieved the po pularity o f so me o ther datab ase implementatio ns.
Chapter 2 ✦ The Relational Database M odel
Ano ther c o mpany c alled Relatio nal So ftware, Inc . was fo rmed in the late 1970’s to c reate their o wn relatio nal database system. Their database system, c alled Orac le, was
first shipped in 1979, making it the first c o mmerc ially available relatio nal database
system. Like IBM’s System/R pro jec t, it was based o n SQL, and like Ingres, it ran o n a
VAX mini-c o mputer. To day, Orac le is the leading supplier o f relatio nal database systems in the wo rld.
Back to IBM
In 1981, IBM shipped their first c o mmerc ial relatio nal database system, c alled
SQL/ Data System (SQL/ DS). SQL/ DS was available fo r the Virtual Mac hine (VM)
o perating system and was targeted primarily at c o mputer c enters that wanted to
pro vide ad ho c query pro c essing fo r relatively small databases.
IBM c ho se this appro ac h fo r two main reaso ns. First, they didn’t want to c annibalize sales o f their highly suc c essful hierarc hic al database system, Info rmatio n
Management System (IMS), whic h ran o n the large Multiple Virtual Sto rage (MVS)
based mainframes. Sec o nd, fo r any given wo rklo ad, SQL/ DS was muc h slo wer than
IMS. By restric ting relatio nal database tec hno lo gy to a small nic he, IBM was able to
get prac tic al experienc e with the tec hno lo gy witho ut alienating its c usto mers.
In 1983, IBM released the first relatio nal database system to run o n MVS, c alled
Data Base/ 2, whic h is mo re c o mmo nly kno wn as DB2. In the early days, DB2 gained
a reputatio n fo r being a reso urc e ho g and fo r very slo w perfo rmanc e. This was true
when c o mpared to the IMS database, whic h had many mo re years o f tuning and
o ptimizatio n than DB2 had at that time. IBM’s respo nse was to suggest that DB2
sho uld be used fo r ad ho c query pro c essing, and to use IMS fo r high-vo lume transac tio n pro c essing.
IBM also labeled DB2 as a strategic pro duc t. In IBM speak, this meant that a c usto mer that was c o nc erned abo ut the future sho uld be running DB2 to day. While
this helped DB2 sales, it didn’t help DB2 perfo rmanc e. Ho wever, as time went o n,
two things helped to c hange DB2 perfo rmanc e dramatic ally. First, DB2 underwent
several majo r versio n c hanges, with eac h c hange bringing a signific ant impro vement in perfo rmanc e. At the same time, the pric e o f hardware dro pped immensely,
whic h meant that c usto mers c o uld buy a lo t mo re c o mputing po wer fo r the same
amo unt o f mo ney. And no thing so lves a perfo rmanc e pro blem as well as mo re
hardware.
Tip
A lot of memory is good and too much is just right: When dealing w ith a relational database, nothing im proves perform ance as m uch as adding m em ory.
Adding m ore RAM to a com puter allow s the database to reduce the am ount of I/ O
needed to process a query. Adding RAM for a disk cache w ill also w ork w onders.
21
22
Part I ✦ Database Programming Fundamentals
ANSI Standard SQL
In 1982, the Americ an Natio nal Standards Institute (ANSI) began a pro c ess to determine a standard fo r a relatio nal database query language. Over the next fo ur years
they reviewed several different languages, inc luding SQL and QUEL; ho wever, with
IBM’s weight behind DB2, SQL was eventually selec ted as the standard. Even tho ugh
SQL was selec ted as the standard, there were so me majo r differenc es between the
ac tual syntax used by DB2 and the final syntax ado pted by ANSI in 1986.
The final syntax ado pted in 1986 had a lo t o f o pen ho les, whic h pro mpted ANSI to
revise the standard fo r a sec o nd time in 1989 and again in 1992. The standards have
bec o me kno wn as SQL-86, SQL-89, and SQL-92. Bec ause the standards allo wed vario us levels o f c o mplianc e, many database vendo rs c o uld c laim that their database
suppo rted the ANSI SQL standard.
Caution
A non-standard standard: The ANSI standard perm its vendors to add their ow n
proprietary extensions to their SQL im plem entations. In practice, this m eans that
each vendor’s im plem entation is significantly different from each other. While the
really sim ple statem ents are com patible betw een vendors, m any com plex statem ents m ay not be com patible betw een database vendors. If you are trying to use
the one-program fits all database system s approach to application design, you
need to verify that the statem ents you use are appropriate for all database system s.
Ingres finally bo wed to the pressure and in 1986, added suppo rt fo r SQL alo ngside
QUEL. Sinc e that time, nearly all database vendo rs have added suppo rt fo r SQL to
their databases. Even so me database vendo rs with no n-relatio nal database systems
no w suppo rt the Struc tured Query Language.
Other relatio nal database vendo rs fo llo wed Orac le’s lead and jumped o n the SQL
bandwago n, suc h as Sybase, Info rmix, Digital, and Mic ro so ft. Fo r the mo st part,
these vendo rs igno red the high-end mainframes and c o nc entrated their effo rts o n
mini-c o mputers and/ o r perso nal c o mputer netwo rked servers, whic h turned o ut to
be the right dec isio n sinc e the demand fo r mainframe databases is dec lining as the
demand fo r mainframes remains stagnant.
Note
M ainframes and Unix servers: Having w orked w ith com puters of m any different
sizes over the years, I’ve learned that there isn’t as m uch difference betw een a
m ainfram e and som e of the largest Unix servers on the m arket as m ost people
believe. Much of the technology used in the high-end Unix servers w as first developed for the m ainfram e, w hile the innovative design approaches used to build
affordable Unix servers w ere incorporated into m ainfram es. This blending of technology and design m eans that m ainfram es w ill continue to be around for a long
tim e as an alternative to the high-end Unix servers.
Chapter 2 ✦ The Relational Database M odel
Business benefits of a relational database
Obvio usly, SQL wo uldn’t have ac hieved its suc c ess unless it met peo ple’s expec tatio ns. SQL suc c eeded bec ause o f several key fac to rs, suc h as the underlying relatio nal database tec hno lo gy, the existenc e o f an independent ANSI standard, and
the fac t that the language itself is very ro bust and that mo st o f the database systems using SQL are based o n mo dern c lient/ server arc hitec tures.
Relational database technology
Designing a no n-relatio nal database c an be a diffic ult task and using o ne c an be
even wo rse. In mo st no n-relatio nal database systems, c reating a database is a diffic ult task due to the fac t that the hierarc hies must be c o mpletely desc ribed o r all o f
the po ssible relatio nships must be tho ught o ut befo re the database is c reated. A
relatio nal database allo ws yo u to make c hanges easily and o n the fly. Yo u c an add
and remo ve database struc tures while the database is running.
The relatio nal database mo del also permits peo ple to use relatio nships that haven’t
been predefined. This lets an o rganizatio n c hange their databases gradually o ver
time, whic h reduc es the impac t and sc o pe o f any single c hange.
Pros and cons of the ANSI standard
Many peo ple believe that the ANSI standard guarantees that pro grams written to
use SQL c an be mo ved fro m o ne database platfo rm to ano ther with minimal pro blems, in muc h the same way that peo ple c an mo ve an ANSI C pro gram fro m o ne
mac hine to ano ther. This gives many users the feeling that if they need to , they c an
switc h database vendo rs. In reality, unless yo u make a spec ial effo rt to design yo ur
applic atio n to the ANSI standard, mo st peo ple will find mo ving fro m o ne database
system to ano ther mo re tro uble than it’s wo rth.
Ho wever, there are many advantages to having an independent standard than simply
po rtability. One o f the largest pro blems to day is finding kno wledgeable peo ple to
develo p applic atio ns. Often peo ple are hired with so me o f the skills, but need to be
trained in o thers. While the details o f the SQL syntax may vary fro m o ne database
vendo r to ano ther, the basic statements are the same. This makes it po ssible to train
so meo ne in a new database system by fo c using o nly o n ho w their SQL is different
fro m the standard rather than starting with a who le new language. This means that
peo ple c an mo ve fro m o ne database system to ano ther with muc h less effo rt than
wo uld have been po ssible witho ut an independent standard.
Powerful query language
Prio r to SQL, mo st database systems used o ne metho d to ac c ess a database interac tively and ano ther metho d fo r pro grammatic ac c ess. This fo rc ed pro grammers to
learn multiple languages to ac c ess their database. Also , the interac tive query language wasn’t po werful eno ugh to answer c ertain types o f questio ns. In additio n,
23
24
Part I ✦ Database Programming Fundamentals
there was typic ally a third language that was used to define the struc ture o f the
database. This made it muc h harder than it really needed to be fo r many applic atio n pro grammers. SQL so lves this pro blem by pro viding a single query language.
This same language c an be used interac tively, pro grammatic ally and to define the
database struc tures.
Client/ server architecture
Ano ther benefit o f using database systems based o n the SQL language is that mo st
database systems have been develo ped using a c lient/ server arc hitec ture. This
makes it a natural fit fo r mo dern perso nal c o mputer netwo rks. This also makes it
easy to sc ale the size o f the c o mputer running the database server, whic h in turn
allo ws an o rganizatio n to spend less mo ney o n c o mputing reso urc es.
Parts of a Relational Database
In o rder to understand ho w to ac c ess a relatio nal database, yo u need to understand
the basic parts o f a relatio nal database and ho w they fit to gether.
Tip
Separation of data: I often do m y developm ent directly on a Window s 2000/ NT
Server system , w ith a local database server. This w ay, I can test applications I’m
w orking on against a test database w ithout im pacting m y production database
server.
Tables and rows of data
A database ho lds yo ur data in a series o f o ne o r mo re table s. Eac h table is similar to
a spreadsheet, with the data o rganized into a series o f ro ws and c o lumns. Eac h ro w
c o rrespo nds to a rec o rd in a file and represents a unique instanc e o f a piec e o f data.
A c o lumn c o rrespo nds to a field in a file and represents a single attribute o f a piec e
o f data.
Co nsider a table that c o ntains info rmatio n abo ut a c usto mer. Eac h ro w in the table
c o ntains info rmatio n abo ut a single c usto mer, while eac h c o lumn in the table c o ntains a spec ific attribute abo ut that c usto mer, suc h as their name o r street address.
Columns and data types
The data in a c o lumn is o ften c alled ato mic , whic h implies that the data in the c o lumn c an’t be subdivided. Fo r instanc e, c o nsider a field c alled Name, whic h c o nsists
o f three subparts: Name.First, Name.Middle, and Name.Last. The Name field is no t
Chapter 2 ✦ The Relational Database M odel
ato mic sinc e it c an be bro ken into smaller piec es. On the o ther hand, a field that
c o ntains an unstruc tured name value wo uld be ato mic sinc e there is no struc ture to
the field.
A re pe ating gro up is a field that c o ntains mo re than o ne instanc e o f a data value.
Thus any field that is an array o r a c o llec tio n is a repeating gro up. Sinc e a repeating
gro up is also no t ato mic , it c an’t be represented by a single c o lumn.
Asso c iated with eac h c o lumn is a data type that identifies the type o f data yo u plan
to sto re in the c o lumn. In general there are fo ur main data types:
✦ Numbers — Integers, fixed dec imal po int and flo ating dec imal po int numbers
fall into this c atego ry.
✦ Character strings — Fixe d-le ngth c harac ter strings always use the same
amo unt o f sto rage in yo ur table, while variable -le ngth c harac ter strings sto re
o nly the c harac ters in the string, plus so me info rmatio n that allo ws the
database to trac k the length o f the string.
✦ Date/ time values — This data type c o ntains a date value, a time value, o r a
c o mbinatio n date and time value. Eac h database server will determine the
exac t meaning o f these values and ho w they are sto red.
✦ Binary values — This is basic ally an unfo rmatted, sto re-it-yo urself field. Yo u
c an sto re items suc h as images, so und c lips, and even applic atio n pro grams
using a binary data type.
Note
All binary data types are not the same: The database server you are using w ill
determ ine the characteristics for a binary data type.
In additio n to sto ring a data value in a c o lumn, a spec ial flag kno wn as Null is also
available. This flag indic ates whether the c o lumn c o ntains a valid value. If the c o lumn has a valid value, this flag will be set to false and the c o lumn will be kno wn as
Not Null . Ho wever if yo u do n’t assign a value to this c o lumn, then the flag will be
set to true and the c o lumn will be kno wn as Null .
Note
Nulls aren’t empty: Don’t confuse an em pty string w ith Null . An em pty string represents a value, w hile Null m eans that no value is associated w ith the colum n.
Indexes and keys
In the theo retic al relatio nal database mo del there isn’t any o rganizatio n to ho w the
ro ws are sto red in the table. Ho wever, fro m a prac tic al viewpo int, yo u need a mec hanism that allo ws yo u to quic kly selec t a ro w o r set o f ro ws. This mec hanism is
kno wn as an inde x .
25
26
Part I ✦ Database Programming Fundamentals
An index is a spec ial database struc ture that maintains a set o f c o lumn values,
so rted in a way that minimizes the searc h time. Typic ally, an index is implemented
as an inverted list, similar to that used in the indexed database mo del. This allo ws
the database server to quic kly searc h thro ugh the list o f values in the index to
selec t the desired ro ws fro m the table. Indexes are separate fro m the table and c an
be added and remo ved o n the fly.
A c o lumn is said to depend o n ano ther field when there is o nly o ne po ssible value
o f the sec o nd field fo r a spec ific value o f the first c o lumn. If this so unds c o nfusing,
c o nsider the fo llo wing: yo u have a table with a name c o lumn and a so c ial sec urity
number c o lumn. Sinc e the so c ial sec urity number is unique fo r eac h individual and
eac h individual has o nly o ne name, the name field is dependent o n the so c ial sec urity number. No te that the reverse isn’t true, sinc e it is po ssible to have mo re than
o ne so c ial sec urity number fo r a given name. In o ther wo rds, there may be mo re
than o ne perso n with the name o f Jo hn Smith in this c o untry, and eac h will have
their o wn unique so c ial sec urity number.
The list o f c o lumns inc luded in the index is kno wn as the ke y . Every table sho uld
have a key who se value is unique fo r eac h ro w in the table. This is kno wn as the
primary ke y . Fo r example, a table that c o ntains info rmatio n abo ut c usto mers might
have a c o lumn c alled Custo merId as the primary key. A key that c o ntains mo re
than o ne c o lumn is also kno wn as a co mpo site ke y .
Any o ther keys in the table are referred to as se co ndary ke ys. Unlike the primary
key, sec o ndary keys need no t be unique. They merely help yo u lo c ate a c o mmo n
subset o f ro ws in a table.
When a gro up o f c o lumns in o ne table matc hes the primary key definitio n in ano ther
table, the gro up o f c o lumns is c alled a fo re ign ke y . Fo reign keys are useful when yo u
want to establish a relatio nship between two tables. Fo r example, in the c usto mer
table, o ne o f the c o lumns might be zip c o de. Yo u c o uld add a ZIP c o de table to yo ur
database, whic h c o ntains a list o f ZIP c o des eac h with their c o rrespo nding c ity
name. Thus, fo r any given ZIP c o de, yo u c o uld determine the name o f the c ity where
the c usto mer lives. This way yo u c o uld auto matic ally fill in the c ity name when a
c usto mer enters their ZIP c o de.
Yo u c an c ho o se to make a relatio nship — a required relatio nship — in whic h c ase
the database server will prevent yo u fro m adding a ro w to the table unless the
value in the fo reign key c o lumns is fo und as the primary key in the c o rrespo nding
table. Thus if yo u c ho o se to enfo rc e the abo ve relatio nship, yo u c an o nly insert a
ro w into the c usto mer’s table if the c usto mer’s ZIP c o de exists in the ZIP c o de table.
Ano ther advantage o f indexes is that yo u c an use an index to ensure that a value in
the table is unique. While the primary key o f the table must be unique, in so me
c ases yo u may want the sec o ndary key to be unique as well.
Chapter 2 ✦ The Relational Database M odel
Theory vs. Reality
One of the advantages of a relational database is the use of set theory to describe operations against its data. It allow s a high degree of separation betw een how the data is view ed
by the database user and how the data is actually stored internally. How ever, just because
som ething m akes sense in theory doesn’t necessarily m ean it’s a good idea, because the
theory doesn’t take into consideration the physical lim itations of your database server.
Without indexes, every query w ould have to read every row in a table. On sm all tables this
w ouldn’t be a big handicap, since it doesn’t take very long to read all of the row s. How ever,
on large tables this can be a m ajor problem .
Views
One o f the mo st impo rtant c o nc epts in a relatio nal database is kno wn as a vie w .
A view is simply a “virtual table” c reated fro m o ne o r mo re base tables in yo ur
database. Views c o me in two flavo rs: updateable and no n-updateable. As their
names imply, updateable views c an be updated and are usually c reated fro m a
single table. No n-updateable views are generally c reated fro m two o r mo re tables
o r c o ntain c o lumns who se values are c alc ulated in so me fashio n.
Normalization
No rmaliz atio n is a way to c lassify yo ur database struc ture. Fro m a theo retic al viewpo int, the mo re no rmalized yo u database is, the better. These are the fo ur basic
levels o f no rmalizatio n that are c o mmo nly fo und in no rmal database designs:
✦ Unnormalized: No rules are impo sed o n the database struc ture.
✦ First normal form: Eac h field must b e ato mic . Repeating gro ups and c o mpo site fields are no t permitted.
✦ Second normal form: Every no n-key field must depend o n the entire primary
key. A field must no t depend o n o nly part o f a c o mpo site primary key. The
database must also be in first no rmal fo rm.
✦ Third normal form: A no n-key field c an’t depend o n ano ther no n-key field.
The database must also be in the sec o nd no rmal fo rm.
Relatio nal database theo ry also desc ribes a fo urth no rmal fo rm, a fifth no rmal fo rm,
and a Bo yc e/ Co dd no rmal fo rm. These last fo rms o ften result in a database that has
to o many tables to o ffer go o d perfo rmanc e.
27
28
Part I ✦ Database Programming Fundamentals
Yo u c an’t build an unno rmalized relatio nal database sinc e repeating gro ups and
c o mpo site fields aren’t permitted. (Of c o urse there are ways aro und even these
restric tio ns in mo st database servers.) The mo st impo rtant thing to understand is
that as yo u mo ve up the no rmalizatio n ladder, the database’s large tables bec o me
bro ken do wn into mo re and mo re small tables. This is do ne in the name o f reduc ing
data duplic atio n.
Fo r example, in a truly no rmalized database, yo u wo uldn’t sto re c ity and state info rmatio n with so meo ne’s address, sinc e yo u c an get this info rmatio n fro m the perso n’s
ZIP c o de. Yo u wo uld add ano ther table to yo ur database that uses the ZIP c o de as a
primary key and have the c o rrespo nding c ity and state info rmatio n fo r that ZIP c o de.
Ho wever, to get so meo ne’s address, yo u no w must ac c ess two different tables, whic h
is far mo re expensive than ac c essing a single table with all o f the c usto mer’s address
info rmatio n.
Thoughts on Relational Databases
Relational databases have a m uch longer history than m ost people w ould believe.
How ever, I believe this history played a very im portant part in shaping the relational
databases you use today.
Unlike other types of databases that w ere either developed by a com m ittee or by a single
vendor w ho w ere able to unilaterally im pose their standards on their custom ers, relational
databases w ere developed through intense com petition. This com petition has existed for
nearly tw enty years and show s no sign of letting up.
When selecting a database, rely less on the features of a particular relational database, and
m ore on the database vendor’s track record. Relational databases are usually updated every
couple of years and som etim es m ore often than that. When one particularly innovative feature show s up in one database system , the other vendors w ill be quick to copy and im prove
on it and you’ll m ost likely see it released in the next version of their database softw are.
Many custom ers w ill m ake a decision on w hich database to buy based on w hich database
vendor has the best features at the tim e of their evaluation. I’ve seen organizations use this
approach, only to have problem s dow n the road w hen the vendor decided to freeze their
product at a particular version and not enhance it any m ore. This left the organization heavily dependent on a dead-end product and forced them to undergo a m ajor conversion
effort to a sim ilar product from another vendor. This cost a lot of tim e and effort that could
have been used to develop new applications.
Carefully consider these issues w hen picking your database product. Rem em ber that the
investm ent you m ake in your database is not just for a year or tw o but for the next ten to
tw enty years. There are m any vendors in today’s m arket that have a long track record and
have proven them selves over tim e. Choosing one of these vendors w ill save you tim e and
m oney in the long run.
Chapter 2 ✦ The Relational Database M odel
Summary
In this c hapter yo u learned that:
✦ The evo lutio n o f the relatio nal database resulted in many database vendo rs
o ffering pro duc ts that appear to be c o mpatible bec ause they are based o n the
SQL database language, but in reality they are highly inc o mpatible.
✦ There are many business benefits to using relatio nal database systems in yo ur
applic atio ns, inc luding having a single language fo r data definitio n, data manipulatio n and query pro c essing, and a c lient server arc hitec ture fo r effic ient
sharing o f data.
✦ The majo r parts o f a relatio nal database inc lude tables, c o lumns, ro ws,
indexes, and views.
✦ No rmalizing a database is no t nec essarily a go o d thing.
✦
✦
✦
29
C H A P T E R
The Relational
Database M odel
✦
✦
✦
✦
In This Cha pter
I
n this c hapter, I’m go ing to intro duc e yo u to the develo pment o f SQL language and why it’s impo rtant fo r relatio nal
databases. Then I’ll give yo u a brief o verview o f the vario us
struc tures in a relatio nal database.
Introducing the Structured
Query Language
Witho ut the Struc tured Query Language ( SQL) , relatio nal
databases might no t have bec o me as po pular as they are
to day. Their po pularity is due mo stly to ho w the relatio nal
database industry evo lved and the standards that were an
o utgro wth o f this evo lutio n. Of c o urse the business benefits
o f a relatio nal database also had a great deal o f impac t o n its
ac c eptanc e.
Relational history
While the rise in po pularity o f relatio nal databases appears
to be tied to the perso nal c o mputer revo lutio n, the histo ry o f
the relatio nal database begins muc h earlier. And the o rigins
o f the relatio nal database begin at the wo rld’s largest c o mputer c o mpany rather than at M.I.T.S., the unkno wn c o mpany
that designed the wo rld’s first perso nal c o mputer.
The prequel to SEQUEL
In the early 1970’s, o ne c o mpany do minated the c o mputer
business, muc h like Mic ro so ft do es to day. That c o mpany was
IBM. To day’s IBM bears little resemblanc e to the IBM o f that
era. To many peo ple at that time, c o mputer meant IBM. IBM
was a massive o rganizatio n that planned things years in
Intro ducing the
Structured Q uery
Lang uag e
Business benefits o f a
relatio nal database
Parts o f a relatio nal
database
✦
✦
✦
✦
20
Part I ✦ Database Programming Fundamentals
advanc e. This sho wed mo st dramatic ally in their researc h labs. They had
researc hers who se so le purpo se was to think abo ut alternate ways to perfo rm
c o mputing tasks witho ut regard to prac tic ality. One o f these researc hers was
Dr. E.F. Co dd.
In June 1970, Dr. Co dd published an artic le titled “A Relatio nal Mo del o f Data fo r
Large Shared Data Banks” in the jo urnal, Co mmunicatio ns o f the Asso ciatio n fo r
Co mputing Machine ry . This artic le presented a mathematic al theo ry fo r sto ring and
manipulating data using tabular data struc tures. This theo ry is the basis fo r the
mo dern relatio nal database.
SEQUEL and System/ R
The idea o f a relatio nal database was appealing fo r many reaso ns and IBM autho rized
a researc h pro jec t in the mid-1970’s to c reate a database system based o n that theo ry. This pro jec t bec ame kno wn as System/R. Alo ng with the wo rk o n the database
itself, wo rk was also underway to develo p a query language fo r the database. The
researc hers develo ped several different languages, inc luding o ne kno wn as SEQUEL
(Struc tured English QUEry Language).
In the late 1970’s, IBM dec ided to release System/ R to so me o f their key c usto mers
fo r evaluatio n. As part o f this evaluatio n pro c ess, the query language was renamed
SQL, altho ugh it c o ntinued to be pro no unc ed SEQUEL. The System/ R pro jec t c ame
to a c lo se in 1979, when IBM dec ided that the relatio nal database theo ries develo ped by Co dd ten years earlier were ready to be turned into a c o mmerc ial pro duc t.
Ingres and Oracle
IBM was no t the o nly c o mpany to wo rk o n relatio nal databases during the 1970’s.
So me pro fesso rs at the University o f Califo rnia’s Berkeley c o mputer labs also built
a relatio nal database kno wn as Ingres. The query language fo r this database was
kno wn as QUEL, whic h is sho rt fo r QUEry Language. Like SQL, this language was
based o n a highly struc tured fo rm o f the English language.
Ingres was also develo ped o n a Unix platfo rm, unlike System/ R, whic h ran o n an
IBM mainframe o perating system. At that time, Unix systems generally ran o n small
mini-c o mputers suc h as Digital’s VAX, whic h were muc h c heaper to ac quire and
o perate than mainframes. This made the database po pular with many universities
that used the database to teac h the fundamental c o nc epts o f relatio nal database
implementatio ns.
Eventually, so me o f the pro fesso rs left the Berkeley c o mputer lab s in 1980 and
fo rmed a c o mpany kno wn as Relatio nal Tec hno lo gy, Inc . to b uild a c o mmerc ial
versio n o f Ingres. Ingres still exists as a c o mmerc ial datab ase, tho ugh it hasn’t
ac hieved the po pularity o f so me o ther datab ase implementatio ns.
Chapter 2 ✦ The Relational Database M odel
Ano ther c o mpany c alled Relatio nal So ftware, Inc . was fo rmed in the late 1970’s to c reate their o wn relatio nal database system. Their database system, c alled Orac le, was
first shipped in 1979, making it the first c o mmerc ially available relatio nal database
system. Like IBM’s System/R pro jec t, it was based o n SQL, and like Ingres, it ran o n a
VAX mini-c o mputer. To day, Orac le is the leading supplier o f relatio nal database systems in the wo rld.
Back to IBM
In 1981, IBM shipped their first c o mmerc ial relatio nal database system, c alled
SQL/ Data System (SQL/ DS). SQL/ DS was available fo r the Virtual Mac hine (VM)
o perating system and was targeted primarily at c o mputer c enters that wanted to
pro vide ad ho c query pro c essing fo r relatively small databases.
IBM c ho se this appro ac h fo r two main reaso ns. First, they didn’t want to c annibalize sales o f their highly suc c essful hierarc hic al database system, Info rmatio n
Management System (IMS), whic h ran o n the large Multiple Virtual Sto rage (MVS)
based mainframes. Sec o nd, fo r any given wo rklo ad, SQL/ DS was muc h slo wer than
IMS. By restric ting relatio nal database tec hno lo gy to a small nic he, IBM was able to
get prac tic al experienc e with the tec hno lo gy witho ut alienating its c usto mers.
In 1983, IBM released the first relatio nal database system to run o n MVS, c alled
Data Base/ 2, whic h is mo re c o mmo nly kno wn as DB2. In the early days, DB2 gained
a reputatio n fo r being a reso urc e ho g and fo r very slo w perfo rmanc e. This was true
when c o mpared to the IMS database, whic h had many mo re years o f tuning and
o ptimizatio n than DB2 had at that time. IBM’s respo nse was to suggest that DB2
sho uld be used fo r ad ho c query pro c essing, and to use IMS fo r high-vo lume transac tio n pro c essing.
IBM also labeled DB2 as a strategic pro duc t. In IBM speak, this meant that a c usto mer that was c o nc erned abo ut the future sho uld be running DB2 to day. While
this helped DB2 sales, it didn’t help DB2 perfo rmanc e. Ho wever, as time went o n,
two things helped to c hange DB2 perfo rmanc e dramatic ally. First, DB2 underwent
several majo r versio n c hanges, with eac h c hange bringing a signific ant impro vement in perfo rmanc e. At the same time, the pric e o f hardware dro pped immensely,
whic h meant that c usto mers c o uld buy a lo t mo re c o mputing po wer fo r the same
amo unt o f mo ney. And no thing so lves a perfo rmanc e pro blem as well as mo re
hardware.
Tip
A lot of memory is good and too much is just right: When dealing w ith a relational database, nothing im proves perform ance as m uch as adding m em ory.
Adding m ore RAM to a com puter allow s the database to reduce the am ount of I/ O
needed to process a query. Adding RAM for a disk cache w ill also w ork w onders.
21
22
Part I ✦ Database Programming Fundamentals
ANSI Standard SQL
In 1982, the Americ an Natio nal Standards Institute (ANSI) began a pro c ess to determine a standard fo r a relatio nal database query language. Over the next fo ur years
they reviewed several different languages, inc luding SQL and QUEL; ho wever, with
IBM’s weight behind DB2, SQL was eventually selec ted as the standard. Even tho ugh
SQL was selec ted as the standard, there were so me majo r differenc es between the
ac tual syntax used by DB2 and the final syntax ado pted by ANSI in 1986.
The final syntax ado pted in 1986 had a lo t o f o pen ho les, whic h pro mpted ANSI to
revise the standard fo r a sec o nd time in 1989 and again in 1992. The standards have
bec o me kno wn as SQL-86, SQL-89, and SQL-92. Bec ause the standards allo wed vario us levels o f c o mplianc e, many database vendo rs c o uld c laim that their database
suppo rted the ANSI SQL standard.
Caution
A non-standard standard: The ANSI standard perm its vendors to add their ow n
proprietary extensions to their SQL im plem entations. In practice, this m eans that
each vendor’s im plem entation is significantly different from each other. While the
really sim ple statem ents are com patible betw een vendors, m any com plex statem ents m ay not be com patible betw een database vendors. If you are trying to use
the one-program fits all database system s approach to application design, you
need to verify that the statem ents you use are appropriate for all database system s.
Ingres finally bo wed to the pressure and in 1986, added suppo rt fo r SQL alo ngside
QUEL. Sinc e that time, nearly all database vendo rs have added suppo rt fo r SQL to
their databases. Even so me database vendo rs with no n-relatio nal database systems
no w suppo rt the Struc tured Query Language.
Other relatio nal database vendo rs fo llo wed Orac le’s lead and jumped o n the SQL
bandwago n, suc h as Sybase, Info rmix, Digital, and Mic ro so ft. Fo r the mo st part,
these vendo rs igno red the high-end mainframes and c o nc entrated their effo rts o n
mini-c o mputers and/ o r perso nal c o mputer netwo rked servers, whic h turned o ut to
be the right dec isio n sinc e the demand fo r mainframe databases is dec lining as the
demand fo r mainframes remains stagnant.
Note
M ainframes and Unix servers: Having w orked w ith com puters of m any different
sizes over the years, I’ve learned that there isn’t as m uch difference betw een a
m ainfram e and som e of the largest Unix servers on the m arket as m ost people
believe. Much of the technology used in the high-end Unix servers w as first developed for the m ainfram e, w hile the innovative design approaches used to build
affordable Unix servers w ere incorporated into m ainfram es. This blending of technology and design m eans that m ainfram es w ill continue to be around for a long
tim e as an alternative to the high-end Unix servers.
Chapter 2 ✦ The Relational Database M odel
Business benefits of a relational database
Obvio usly, SQL wo uldn’t have ac hieved its suc c ess unless it met peo ple’s expec tatio ns. SQL suc c eeded bec ause o f several key fac to rs, suc h as the underlying relatio nal database tec hno lo gy, the existenc e o f an independent ANSI standard, and
the fac t that the language itself is very ro bust and that mo st o f the database systems using SQL are based o n mo dern c lient/ server arc hitec tures.
Relational database technology
Designing a no n-relatio nal database c an be a diffic ult task and using o ne c an be
even wo rse. In mo st no n-relatio nal database systems, c reating a database is a diffic ult task due to the fac t that the hierarc hies must be c o mpletely desc ribed o r all o f
the po ssible relatio nships must be tho ught o ut befo re the database is c reated. A
relatio nal database allo ws yo u to make c hanges easily and o n the fly. Yo u c an add
and remo ve database struc tures while the database is running.
The relatio nal database mo del also permits peo ple to use relatio nships that haven’t
been predefined. This lets an o rganizatio n c hange their databases gradually o ver
time, whic h reduc es the impac t and sc o pe o f any single c hange.
Pros and cons of the ANSI standard
Many peo ple believe that the ANSI standard guarantees that pro grams written to
use SQL c an be mo ved fro m o ne database platfo rm to ano ther with minimal pro blems, in muc h the same way that peo ple c an mo ve an ANSI C pro gram fro m o ne
mac hine to ano ther. This gives many users the feeling that if they need to , they c an
switc h database vendo rs. In reality, unless yo u make a spec ial effo rt to design yo ur
applic atio n to the ANSI standard, mo st peo ple will find mo ving fro m o ne database
system to ano ther mo re tro uble than it’s wo rth.
Ho wever, there are many advantages to having an independent standard than simply
po rtability. One o f the largest pro blems to day is finding kno wledgeable peo ple to
develo p applic atio ns. Often peo ple are hired with so me o f the skills, but need to be
trained in o thers. While the details o f the SQL syntax may vary fro m o ne database
vendo r to ano ther, the basic statements are the same. This makes it po ssible to train
so meo ne in a new database system by fo c using o nly o n ho w their SQL is different
fro m the standard rather than starting with a who le new language. This means that
peo ple c an mo ve fro m o ne database system to ano ther with muc h less effo rt than
wo uld have been po ssible witho ut an independent standard.
Powerful query language
Prio r to SQL, mo st database systems used o ne metho d to ac c ess a database interac tively and ano ther metho d fo r pro grammatic ac c ess. This fo rc ed pro grammers to
learn multiple languages to ac c ess their database. Also , the interac tive query language wasn’t po werful eno ugh to answer c ertain types o f questio ns. In additio n,
23
24
Part I ✦ Database Programming Fundamentals
there was typic ally a third language that was used to define the struc ture o f the
database. This made it muc h harder than it really needed to be fo r many applic atio n pro grammers. SQL so lves this pro blem by pro viding a single query language.
This same language c an be used interac tively, pro grammatic ally and to define the
database struc tures.
Client/ server architecture
Ano ther benefit o f using database systems based o n the SQL language is that mo st
database systems have been develo ped using a c lient/ server arc hitec ture. This
makes it a natural fit fo r mo dern perso nal c o mputer netwo rks. This also makes it
easy to sc ale the size o f the c o mputer running the database server, whic h in turn
allo ws an o rganizatio n to spend less mo ney o n c o mputing reso urc es.
Parts of a Relational Database
In o rder to understand ho w to ac c ess a relatio nal database, yo u need to understand
the basic parts o f a relatio nal database and ho w they fit to gether.
Tip
Separation of data: I often do m y developm ent directly on a Window s 2000/ NT
Server system , w ith a local database server. This w ay, I can test applications I’m
w orking on against a test database w ithout im pacting m y production database
server.
Tables and rows of data
A database ho lds yo ur data in a series o f o ne o r mo re table s. Eac h table is similar to
a spreadsheet, with the data o rganized into a series o f ro ws and c o lumns. Eac h ro w
c o rrespo nds to a rec o rd in a file and represents a unique instanc e o f a piec e o f data.
A c o lumn c o rrespo nds to a field in a file and represents a single attribute o f a piec e
o f data.
Co nsider a table that c o ntains info rmatio n abo ut a c usto mer. Eac h ro w in the table
c o ntains info rmatio n abo ut a single c usto mer, while eac h c o lumn in the table c o ntains a spec ific attribute abo ut that c usto mer, suc h as their name o r street address.
Columns and data types
The data in a c o lumn is o ften c alled ato mic , whic h implies that the data in the c o lumn c an’t be subdivided. Fo r instanc e, c o nsider a field c alled Name, whic h c o nsists
o f three subparts: Name.First, Name.Middle, and Name.Last. The Name field is no t
Chapter 2 ✦ The Relational Database M odel
ato mic sinc e it c an be bro ken into smaller piec es. On the o ther hand, a field that
c o ntains an unstruc tured name value wo uld be ato mic sinc e there is no struc ture to
the field.
A re pe ating gro up is a field that c o ntains mo re than o ne instanc e o f a data value.
Thus any field that is an array o r a c o llec tio n is a repeating gro up. Sinc e a repeating
gro up is also no t ato mic , it c an’t be represented by a single c o lumn.
Asso c iated with eac h c o lumn is a data type that identifies the type o f data yo u plan
to sto re in the c o lumn. In general there are fo ur main data types:
✦ Numbers — Integers, fixed dec imal po int and flo ating dec imal po int numbers
fall into this c atego ry.
✦ Character strings — Fixe d-le ngth c harac ter strings always use the same
amo unt o f sto rage in yo ur table, while variable -le ngth c harac ter strings sto re
o nly the c harac ters in the string, plus so me info rmatio n that allo ws the
database to trac k the length o f the string.
✦ Date/ time values — This data type c o ntains a date value, a time value, o r a
c o mbinatio n date and time value. Eac h database server will determine the
exac t meaning o f these values and ho w they are sto red.
✦ Binary values — This is basic ally an unfo rmatted, sto re-it-yo urself field. Yo u
c an sto re items suc h as images, so und c lips, and even applic atio n pro grams
using a binary data type.
Note
All binary data types are not the same: The database server you are using w ill
determ ine the characteristics for a binary data type.
In additio n to sto ring a data value in a c o lumn, a spec ial flag kno wn as Null is also
available. This flag indic ates whether the c o lumn c o ntains a valid value. If the c o lumn has a valid value, this flag will be set to false and the c o lumn will be kno wn as
Not Null . Ho wever if yo u do n’t assign a value to this c o lumn, then the flag will be
set to true and the c o lumn will be kno wn as Null .
Note
Nulls aren’t empty: Don’t confuse an em pty string w ith Null . An em pty string represents a value, w hile Null m eans that no value is associated w ith the colum n.
Indexes and keys
In the theo retic al relatio nal database mo del there isn’t any o rganizatio n to ho w the
ro ws are sto red in the table. Ho wever, fro m a prac tic al viewpo int, yo u need a mec hanism that allo ws yo u to quic kly selec t a ro w o r set o f ro ws. This mec hanism is
kno wn as an inde x .
25
26
Part I ✦ Database Programming Fundamentals
An index is a spec ial database struc ture that maintains a set o f c o lumn values,
so rted in a way that minimizes the searc h time. Typic ally, an index is implemented
as an inverted list, similar to that used in the indexed database mo del. This allo ws
the database server to quic kly searc h thro ugh the list o f values in the index to
selec t the desired ro ws fro m the table. Indexes are separate fro m the table and c an
be added and remo ved o n the fly.
A c o lumn is said to depend o n ano ther field when there is o nly o ne po ssible value
o f the sec o nd field fo r a spec ific value o f the first c o lumn. If this so unds c o nfusing,
c o nsider the fo llo wing: yo u have a table with a name c o lumn and a so c ial sec urity
number c o lumn. Sinc e the so c ial sec urity number is unique fo r eac h individual and
eac h individual has o nly o ne name, the name field is dependent o n the so c ial sec urity number. No te that the reverse isn’t true, sinc e it is po ssible to have mo re than
o ne so c ial sec urity number fo r a given name. In o ther wo rds, there may be mo re
than o ne perso n with the name o f Jo hn Smith in this c o untry, and eac h will have
their o wn unique so c ial sec urity number.
The list o f c o lumns inc luded in the index is kno wn as the ke y . Every table sho uld
have a key who se value is unique fo r eac h ro w in the table. This is kno wn as the
primary ke y . Fo r example, a table that c o ntains info rmatio n abo ut c usto mers might
have a c o lumn c alled Custo merId as the primary key. A key that c o ntains mo re
than o ne c o lumn is also kno wn as a co mpo site ke y .
Any o ther keys in the table are referred to as se co ndary ke ys. Unlike the primary
key, sec o ndary keys need no t be unique. They merely help yo u lo c ate a c o mmo n
subset o f ro ws in a table.
When a gro up o f c o lumns in o ne table matc hes the primary key definitio n in ano ther
table, the gro up o f c o lumns is c alled a fo re ign ke y . Fo reign keys are useful when yo u
want to establish a relatio nship between two tables. Fo r example, in the c usto mer
table, o ne o f the c o lumns might be zip c o de. Yo u c o uld add a ZIP c o de table to yo ur
database, whic h c o ntains a list o f ZIP c o des eac h with their c o rrespo nding c ity
name. Thus, fo r any given ZIP c o de, yo u c o uld determine the name o f the c ity where
the c usto mer lives. This way yo u c o uld auto matic ally fill in the c ity name when a
c usto mer enters their ZIP c o de.
Yo u c an c ho o se to make a relatio nship — a required relatio nship — in whic h c ase
the database server will prevent yo u fro m adding a ro w to the table unless the
value in the fo reign key c o lumns is fo und as the primary key in the c o rrespo nding
table. Thus if yo u c ho o se to enfo rc e the abo ve relatio nship, yo u c an o nly insert a
ro w into the c usto mer’s table if the c usto mer’s ZIP c o de exists in the ZIP c o de table.
Ano ther advantage o f indexes is that yo u c an use an index to ensure that a value in
the table is unique. While the primary key o f the table must be unique, in so me
c ases yo u may want the sec o ndary key to be unique as well.
Chapter 2 ✦ The Relational Database M odel
Theory vs. Reality
One of the advantages of a relational database is the use of set theory to describe operations against its data. It allow s a high degree of separation betw een how the data is view ed
by the database user and how the data is actually stored internally. How ever, just because
som ething m akes sense in theory doesn’t necessarily m ean it’s a good idea, because the
theory doesn’t take into consideration the physical lim itations of your database server.
Without indexes, every query w ould have to read every row in a table. On sm all tables this
w ouldn’t be a big handicap, since it doesn’t take very long to read all of the row s. How ever,
on large tables this can be a m ajor problem .
Views
One o f the mo st impo rtant c o nc epts in a relatio nal database is kno wn as a vie w .
A view is simply a “virtual table” c reated fro m o ne o r mo re base tables in yo ur
database. Views c o me in two flavo rs: updateable and no n-updateable. As their
names imply, updateable views c an be updated and are usually c reated fro m a
single table. No n-updateable views are generally c reated fro m two o r mo re tables
o r c o ntain c o lumns who se values are c alc ulated in so me fashio n.
Normalization
No rmaliz atio n is a way to c lassify yo ur database struc ture. Fro m a theo retic al viewpo int, the mo re no rmalized yo u database is, the better. These are the fo ur basic
levels o f no rmalizatio n that are c o mmo nly fo und in no rmal database designs:
✦ Unnormalized: No rules are impo sed o n the database struc ture.
✦ First normal form: Eac h field must b e ato mic . Repeating gro ups and c o mpo site fields are no t permitted.
✦ Second normal form: Every no n-key field must depend o n the entire primary
key. A field must no t depend o n o nly part o f a c o mpo site primary key. The
database must also be in first no rmal fo rm.
✦ Third normal form: A no n-key field c an’t depend o n ano ther no n-key field.
The database must also be in the sec o nd no rmal fo rm.
Relatio nal database theo ry also desc ribes a fo urth no rmal fo rm, a fifth no rmal fo rm,
and a Bo yc e/ Co dd no rmal fo rm. These last fo rms o ften result in a database that has
to o many tables to o ffer go o d perfo rmanc e.
27
28
Part I ✦ Database Programming Fundamentals
Yo u c an’t build an unno rmalized relatio nal database sinc e repeating gro ups and
c o mpo site fields aren’t permitted. (Of c o urse there are ways aro und even these
restric tio ns in mo st database servers.) The mo st impo rtant thing to understand is
that as yo u mo ve up the no rmalizatio n ladder, the database’s large tables bec o me
bro ken do wn into mo re and mo re small tables. This is do ne in the name o f reduc ing
data duplic atio n.
Fo r example, in a truly no rmalized database, yo u wo uldn’t sto re c ity and state info rmatio n with so meo ne’s address, sinc e yo u c an get this info rmatio n fro m the perso n’s
ZIP c o de. Yo u wo uld add ano ther table to yo ur database that uses the ZIP c o de as a
primary key and have the c o rrespo nding c ity and state info rmatio n fo r that ZIP c o de.
Ho wever, to get so meo ne’s address, yo u no w must ac c ess two different tables, whic h
is far mo re expensive than ac c essing a single table with all o f the c usto mer’s address
info rmatio n.
Thoughts on Relational Databases
Relational databases have a m uch longer history than m ost people w ould believe.
How ever, I believe this history played a very im portant part in shaping the relational
databases you use today.
Unlike other types of databases that w ere either developed by a com m ittee or by a single
vendor w ho w ere able to unilaterally im pose their standards on their custom ers, relational
databases w ere developed through intense com petition. This com petition has existed for
nearly tw enty years and show s no sign of letting up.
When selecting a database, rely less on the features of a particular relational database, and
m ore on the database vendor’s track record. Relational databases are usually updated every
couple of years and som etim es m ore often than that. When one particularly innovative feature show s up in one database system , the other vendors w ill be quick to copy and im prove
on it and you’ll m ost likely see it released in the next version of their database softw are.
Many custom ers w ill m ake a decision on w hich database to buy based on w hich database
vendor has the best features at the tim e of their evaluation. I’ve seen organizations use this
approach, only to have problem s dow n the road w hen the vendor decided to freeze their
product at a particular version and not enhance it any m ore. This left the organization heavily dependent on a dead-end product and forced them to undergo a m ajor conversion
effort to a sim ilar product from another vendor. This cost a lot of tim e and effort that could
have been used to develop new applications.
Carefully consider these issues w hen picking your database product. Rem em ber that the
investm ent you m ake in your database is not just for a year or tw o but for the next ten to
tw enty years. There are m any vendors in today’s m arket that have a long track record and
have proven them selves over tim e. Choosing one of these vendors w ill save you tim e and
m oney in the long run.
Chapter 2 ✦ The Relational Database M odel
Summary
In this c hapter yo u learned that:
✦ The evo lutio n o f the relatio nal database resulted in many database vendo rs
o ffering pro duc ts that appear to be c o mpatible bec ause they are based o n the
SQL database language, but in reality they are highly inc o mpatible.
✦ There are many business benefits to using relatio nal database systems in yo ur
applic atio ns, inc luding having a single language fo r data definitio n, data manipulatio n and query pro c essing, and a c lient server arc hitec ture fo r effic ient
sharing o f data.
✦ The majo r parts o f a relatio nal database inc lude tables, c o lumns, ro ws,
indexes, and views.
✦ No rmalizing a database is no t nec essarily a go o d thing.
✦
✦
✦
29