The Relational
Database M odel
I
n this c hapter, I’m go ing to intro duc e yo u to the develo p-ment 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 datab ases might no t have b ec o me as po pular as they are to day. Their po pularity is due mo stly to ho w the relatio nal datab ase industry evo lved and the standards that were an o utgro wth o f this evo lutio n. Of c o urse the b usiness b enefits o f a relatio nal datab ase 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 datab ases appears to b e tied to the perso nal c o mputer revo lutio n, the histo ry o f the relatio nal datab ase b egins muc h earlier. And the o rigins o f the relatio nal datab ase b egin at the wo rld’s largest c o m-puter 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 b usiness, muc h like Mic ro so ft do es to day. That c o mpany was IBM. To day’s IBM b ears little resemb lanc 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
2
2
✦
✦
✦
✦
In This Cha pter
Intro ducing the Structured Q uery Lang uag e
Business benefits o f a relatio nal database
Parts o f a relatio nal database
advanc e. This sho wed mo st dramatic ally in their researc h lab s. They had researc hers who se so le purpo se was to think ab o 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 the-o ry. This prthe-o jec t bec ame knthe-o wn as System/ R. Althe-o ng with the wthe-o rk the-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 devel-o ped by Cdevel-o dd ten years earlier were ready tdevel-o be turned intdevel-o a c devel-o mmerc ial prdevel-o duc t.
Ingres and Oracle
IBM was no t the o nly c o mpany to wo rk o n relatio nal datab ases during the 1970’s. So me pro fesso rs at the University o f Califo rnia’s Berkeley c o mputer lab s also b uilt a relatio nal datab ase kno wn as Ingres. The q uery language fo r this datab ase was kno wn as QUEL, whic h is sho rt fo r QUEry Language. Like SQL, this language was b ased 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.
Ano ther c o mpany c alled Relatio nal So ftware, Inc . was fo rmed in the late 1970’s to c re-ate 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 sys-tems 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 annibal-ize 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 trans-ac tio n pro c essing.
IBM also lab eled DB2 as a strategic pro duc t. In IBM speak, this meant that a c us-to mer that was c o nc erned ab o ut the future sho uld b e running DB2 us-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 b ringing a signific ant impro ve-ment 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 b uy 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 b lem as well as mo re hardware.
ANSI Standard SQL
In 1982, the Americ an Natio nal Standards Institute (ANSI) began a pro c ess to deter-mine 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 vari-o us levels vari-o f c vari-o mplianc e, many database vendvari-o rs c vari-o uld c laim that their database suppo rted the ANSI SQL standard.
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 state-m ents state-m ay not be costate-m 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.
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 devel-oped 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 tech-nology 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.
Business benefits of a relational database
Ob vio usly, SQL wo uldn’t have ac hieved its suc c ess unless it met peo ple’s expec ta-tio ns. SQL suc c eeded b ec ause o f several key fac to rs, suc h as the underlying rela-tio nal datab ase tec hno lo gy, the existenc e o f an independent ANSI standard, and the fac t that the language itself is very ro b ust and that mo st o f the datab ase sys-tems using SQL are b ased 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 diffi-c ult task due to the fadiffi-c t that the hierardiffi-c hies must be diffi-c o mpletely desdiffi-c 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 b-lems, 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
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 a-tio 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.
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 n-tains a spec ific attribute abo ut that c usto mer, suc h as their name o r street address.
Columns and data types
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 upis 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:
✦Numbe rs— Integers, fixed dec imal po int and flo ating dec imal po int numbers fall into this c atego ry.
✦Characte r strings—Fixe d-le ngthc harac ter strings always use the same amo unt o f sto rage in yo ur table, while variable -le ngthc 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 value s— 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 value s— 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.
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 Nullis also available. This flag indic ates whether the c o lumn c o ntains a valid value. If the c o l-umn has a valid value, this flag will be set to false and the c o ll-umn 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.
Nulls aren’t empty:Don’t confuse an em pty string w ith Null. An em pty string rep-resents a value, w hile Nullm 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 h-anism that allo ws yo u to quic kly selec t a ro w o r set o f ro ws. This mec hh-anism is kno wn as an inde x.
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 u-rity 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 tab le sho uld have a key who se value is uniq ue fo r eac h ro w in the tab le. This is kno wn as the
primary ke y. Fo r example, a tab le that c o ntains info rmatio n ab o 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.
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 nis a way to c lassify yo ur datab ase struc ture. Fro m a theo retic al view-po int, the mo re no rmalized yo u datab ase is, the b etter. These are the fo ur b asic levels o f no rmalizatio n that are c o mmo nly fo und in no rmal datab ase designs:
✦Unnormalize d: 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 m-po site fields are no t permitted.
✦Se cond 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.
Theory vs. Reality
One of the advantages of a relational database is the use of set theory to describe opera-tions 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.
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 r-matio n with so meo ne’s address, sinc e yo u c an get this info rr-matio 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 fea-ture 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 heav-ily 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.
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 manip-ulatio 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.
