I
Rule Zero: For any system that is adver-
Used as, or claimed to be, a relational
data base management.system, that sys¬
tem must be able to manage data bases
entirely through its relational capabilities.
The originator of the relational
. model for data base management
presents basic principles for
determining bow relational a
■DBMS product is —.a question
that faces many buyers today
because almost every vendor
claims its DBMS is relational.
Some vertdbrs may not realize bow
far from the mark they are.
Part 1
ByE.F.Codd
I Dcecemyeus. the<lata btuc msmgtfneai syKem market has
ufKt^rgooe a voy rapid swing In fiivor of products that take
the reladonal ap^pro^ to dua base management. It is hard
And a vendor that does not cUini its DBMS is relational. This
swing has been so encnslvc that aocne vendors of nonreiatiooal
DBMS havt quickly (and recently) added a few relational fca-
nires ~ in tome, cases, vety few features — in order to be able
to claim their systems are relational, even thou^ they may not
meet the simple requirements for being rated “minimally rela>
tional." Wc shall refer to this kind of IMMS as “bom again."
It is a safe bet dm these Jtdmny-conie'latety vendors have not
taken the time or manpower to investigate optimization mch*
niques needed in relttiottal DBMS ti> yield good performance.
This b the principal reason they continue ti> proclaim the
“performance myth” — namely, that relational DBMS must
perfbmi poorly because they are relational!
One consequence of thb rapid swing of the market to the
relational ;q>proacb b that products that are claimed by their
vendors to be relational DBMS range from those that suppon the
relmlonal model with substantial fidelity to those that definitely
do not deserve the label “relational.” b^use their support b
only token.
Soqie vendors claim that fourth-generation Ungifyn will
provide all the productivity advantages. Thb claim conveniently
overlooks the fiaa that most of these Unguagr* do little or
nothif^ for timed data (the programming language featemity .
£. F. Codd b the onginetor of the reletionel model for dele bese
menegement. He toes the teeder of the teem thet designed end imple¬
mented the first opereting s^em vith muitiprogremmmg cepebility.
Currently he is president of The Reletionel Institute end the Codd 6r
Oete Consultiitg Group, both besed in Ssn Jose. Celif.
•/»
•tin does not to reattie Chat
•■ppuit for the dynamic sharing of
dau la an abaotote reqoirementX ^
•ddMon, there is no accepted theo>
retkal fonndatlofi for fourtlngenera-
den lanfiiagea and not even an ac-
eapCed, predae definition.
Tide article outUnea a technique
Chat ahonld h^ oaera detemiine
hoer relational a DBMS really is. Ac-
cordlngly, 1 shall diseuas Che follow-
■ The fideUly DBIG to the re-
ladonal amdel.
■ Hie fldeUty<rf the proposed
And SQL standard to the rdationsl
aMMleL
■ Cooduaions regarding choosing
aDBMS product
I ahafl not atteaapt a complete de-
acriptlon of the rdational model hoe
— a relaCively brief and concise defi*
aition appeare in the article **RM/T:
t Hmlwfl «nd CdrUrol SyWwi
■KSI(tfwa*ilian.K
of hiaficira
irndmofyinmaamam md ordtf OTdy to dnp floor control
and to! Bnanew fiporting, ves ooofdbialBs ovary
oparadonal tonetton... vfWi naati
VeS kawIclBn In fiatot coda to fiwMia Bbrs Syitam/
3t aaddlactura. So mWi BPCS you got ton poavar to take
coitool of yow aidW oparadon todM And thd^fUiaity
yoii*l naad to grew along whh yotp burinas tomorrom.
COMPUTERWORLO
IN PgPTH/REUTIONAL DBMS
f9
The fidelity of the proposed Ansi standard to
the relational model is even less than that of
some relational DBMS j^oducts. However, the
standard could be readily modified to be more
faithful to the model, and pressure should be
brought on Ansi to do so.
Extending the ReistionaJ Model to
Capture More Meaning,'* (Chapter 2,
"The Basic Relatlona) Model") in the
Association for Computing Machin¬
ery’s "Transactions on Data Base
Systems" (December 1979). It is,
however, vitally important to re>-
nmaber that the relational model in¬
dudes three ma^or parts: the struc¬
tural part, the manipulative part aivd
the integrity part — a fact that is
frequently and conveniently forgot¬
ten.
In this paper, I supply a set of
rules with which a DBMS should
comply if it is daimed to be fully
relational. No existing DBMS prod-
net that 1 know of can honestly
claim to be felly relattraaL at this
time.
OCTOeeR 14, I98S
The proposed Ansi standard does
not fully comply with the relational .
model, because It is based heavily on
that nucleus of SQL that is supported
in omunon by numerous vendors.
Moreover, it takes a static, schmna-
based approach to data base descrip¬
tion —> reminiscent of Codssyl —
instead of specifying s comprehen¬
sive, dual-mode data sublanguage
that provides the powerful yet easy
access to relational data bases and
that is unique to the relstionsl sp-
. proach. Thus, the Ddelity of the pro¬
posed Ansi standard to the relstionsl
model is even less than that of some
relstionsl DBMS products.
However, the standard could be
readily modified to be more faithful
to the model, and pressure should be
brought on Ansi to do so. In fact,
vendors are advised to extend ^Ir
products soon in these respects so
that they support ctistoroers’ DBI^
needs more fully and avoid possibly
large customer expenses in applica¬
tion program maintenance at the
time of the Improvement. *
’nel2iiilea '
Twelve rules are cited below as
part of a test to determine whether a
' product that is claimed to be fully
relational is actually so. Use of the
term "fully relstionsl" in this report
is slightly more stringent than in my
Turing paper (written in 1981). This
is partly because vendora in their
ads and manuals have translated the -
term "minimally relational" to "fully
relational'* and partly because in
this report, we are dealing with rels¬
tionsl DBl^ and not relational sys¬
tems in general, which would include
mere query-reporting systems.
However, the 12 rules tend to ex¬
plain why full support of the rela¬
tional model is in the users' interest.
No new requirements are added to
the relational model. A grading
scheme is later deflned and used to
measure the degree of fidelity to the
relstionsl model.
First, I define these rules. Al¬
though I have denned each rule in
earlier papers, I believe this to be the
nrst occurrence of all 12 of them
together.
In rules eight through 11,1 specify
and require four different types of
independence aimed at protecting
customers' investments in applica¬
tion programs, terminal activities
and training. Rules eight and nine —
physical and logical data indepen¬
dence — have been heavily dis¬
cussed for many years.
Rules 10 and 11 — integrity inde¬
pendence and distribution indepen¬
dence — are aspects of the relational
approach that have received Inade¬
quate attention to date but are likely
to become as important as eight and
nine.
These rules are based on a single
foundation rule, which I shall call
Rule Zero:
For any systBm that is advertised
as, or claimed to be, a relational
data base management system, that
system must be able to manage data
bases entirely throttf^ its relational
capabilities.
This rule must hold whether or
not the ayaton supports any non¬
relational capabilities of managing
data. Any DBMS that does not satis¬
fy this Rule Zero la not worth rating
as a relational DBMS.
One consequence of this rule: Any
system clalin^ to be a relational
DBMS must support data base insert,
update and delete at the relaticmal
 L

t>rovide rc users Vdth easy access

to centralized databases. ASer all, ^'
tape can be mailed crDs$<x>utitn
locked in a drawer and can handle fa
niore capacity than the avetaiK PC
Third; M<ia / '
important, dema^

C/MMSf
,
(apt oniy or tape ptus 25, 35.
50 or 90 m^airytes hard disk. ' ■ Call 1-800-228- ' ,
-DISK lor thcTaJlgra»
dealer nearest yo'n. And come in
ftom the cold. • • -
ijl'iiV wi'if ■ 'For afraiiutkprinl(^the Carat lupuiGm
¥foV, seitd a meek jar $3 to: The Tamms
CoUectam,Deft W, lllOO W.SZndSt., OueHanJ
Pbrk, KS 66214. Preceeib, aim an adHAmal
Sonahon fivm 7?i%i\ijj, wiU be forwarded to
theWoHdWU^FtaUd. i.

Survival Strategy
For Serious Data: pg/t
■/4
Irral (ultipfa racord-t-^-tiBne). An¬
other eoneequenee ie the necessity of
eupportinf ^ infcNutstioo rale and
the gharanised acoesB rale.
’•Multiple record-at-s-tiioe" in-
dudes M special cases those situa-
tiom in which aero or one record is
retrieved, inserted, updated or de¬
leted. In ocher words, a rdatlon (ta¬
ble) nay iiavc either aero tuples
(raws) or one tuple and still be a
vattd rdatlon.
Any statement in the manuals of a
lyetew dairncd to be a relational
DBMS that advises usera to revert to
some noordaticmal capabilities **10
achieve acceptable perfmmanoe** —
or for any reason other than com¬
patibility with programs written in
Che past on nonrelational data base
syatiwis — slMuld be interpreted ss
an apology by the vended. Such a
statement indicates the vendor has
like a nei^borhood,
acts lilS a hotel,
and feels just like
home?
Answer:
•jd/wsue p9|T)ri9p ajoui e x) j nms 9snoipu9d
Xicns-o/vu 'uioojp9q-(wu e jo 'aims oiprus uiooip9q-9uo e u]
Xiqepjo^e os ‘jaioq 9uq e jo$9Qiu9uie 9tp jo
Xtreui os tpiM 9ui(^ jo suojuioa 9q) )o Xu^ os s9uiqujoD 9Deid
i9q}0 OU iOj 9Sin09 JO'UUI 99U9pfS9)] 9qj,
COMPUTCRWORLD
IW DEWH/RELATtONAL DBMS
not done the work necessary for
achieving good performance with
the rdational approach.
What is the danger to buyers and
users of a system thst is clsimed to
be a relational DBMS and that fails
on Rule Zero? Buyers and users will
expect all the advantages of a truly
relational DBMS, and they will fail to
get these advantages.
Now I shall describe the 12 rules
that, together with the nine struc¬
tural. 18 manipulative and three in¬
tegrity features of the relational
model, determine in speciHc detail
the extent of validity of a vendor's
claim to have a “fully relational
DBMS.**
All 12 rules are motivated by Rule
Zero defined above, but a DBMS can
be more readily checked for compli¬
ance with these 12 than with Rule
Zero.
II 9>{eui un 3M se 9iuoij oi 9sop sy
Byi
99
Rulel-.AU
ivforvfiation in
a relational data
base is represented
explicitly at the'
logical level and in
exactly one way —
by values in tables.
The information rale.
Atle 1: AU information in a reia-
tional data base is represented ex-
plicitiff at the logical level and in
exactly one way — by values in
tables.
Even table names, column names
OCTOBER 14. 1965
and domain names are represented
as character strings in sesne tables.
Tables containing such names are
normally part of the built-in system
catalog. The catali^ is accordingly a
relational data base itself — one thst
is dynamic and active and represents
the metadata (data describing the
rest of thedau in the system).
The information rale is enforced
not only for user productivity but
also to make it a reasonably simple
job for software vendors to define
additional software^packages (such ’
as application developmrat ai<te, ex¬
pert systems gnd so on) that inter- ,
face with rel^onal DU4S and, by
definition, are well integrated with
the DBMS.
That is, these packages retrieve r
information already existing in the
catalog and, as needed, put new in¬
formation in the catalog by the very
act of using the DBMS. •'
An additional reason to enforce
this rule is to make the data base
administrator's task of maintaining
the data base in a state of overall
integrity both simpler and more ef¬
fective. There is nothing more em¬
barrassing to a data base administra¬
tor than being a4ked if his data base
contains certain specifle information
and his replying after a week’s ex¬
amination of the data base that he
does not know.
Gmarantced acceM rale.
Rule M: Each and every datitm
(atomic value) in a relational data
base is guaranteed to be logically
accessible by resorting to a condona¬
tion table name, prinsary key val¬
ue and column name.
Clearly, each datum in a relational
data base can be accessed in a rich
variety — poasibly thousands — of
logically distinct ways. However, it
is important to have at least one
way. independent of the spetific re¬
lational data base, that is guaran¬
teed, because most computer-orient¬
ed concepts (such as scanning
successive addresses) have been de¬
liberately omitted from the relation¬
al model.
Note that the guaranteed access
rule represents an associative ad¬
dressing scheme that is unique to the
relational model. The rule does not
depend at all on the usual computer-
oriented addressing. However, the
primary key concept is an essential
part of it.
Syatematlc treatmma of aal) val-
■ea.
Mate S: Null values (distinct fi^nn
the empty {Procter string or a
string ttfbUxnk characters and dis¬
tinct Jiwm sero or any other number)
are supported infiUly relational
DBMS for representing missing <»-
formation aad inappUeable infi>P-
motion tn a ^fstematic way, inde¬
pendent of data type.
To support data base integrity, It
must be possible to specify “nulls ruK
allowed" for each primary key col¬
umn and fmr any other columns
where the data base administrator
considers it an appropriate integrity
constraint (for example, certain for¬
eign key columns).
Past techniques entailed denning
a special value (peculiar to each col¬
umn or field) to represent missing
informatitm. This would be raoat un¬
systematic in a relational data base
because users would have to employ
different techniques for each column
or domain — a difficult task because
of the high level qf language In
 OCTOBER 14. 1985 COMPUTERWORLO P/S

JNDCPTH/REUTIONAL DBMS

use (and a task that I believe regard, “update" is intended of its execution-time actions.
would decrease user produc¬ to include insertion and dele¬ Hallows the system toideter¬ w
tivity). tion as welt as modification. mine which access paths to
exploit to obtain the most Rule 4: The data basfi description
Dynamic on-Une catalog High-level insert, update efHcient code.
baaed on the relational and delete. It can also be extremely
is represented at the logical level
model. Rule 7: The capability of important in obtaining effi¬ in the same way as ordinary data,
Jtule 4: The data base de¬ handling a base relation or cient handling of transac¬ so that authorized users can apply
scription is represented at a derived relation as a sin¬ tions across a distributed
the logical level in the same gle operand applies not only
the same relational language to its
data base. In this case, users
way as ordinary data, so to the retrieval of data but would prefer that communi¬ interrogation as th^ apply
that authorized users can also tojhe insertion, update cations costs are saved by to the regular data.
apply the same relationai and deletion of data. avoiding the necessity of
language to its interrogcUion This requirement gives transmitting a separate re¬
as they apply to the regular the system much more scope quest for each record ob¬
data. in optiipizing the efficiency tained from remote sites.
One consequence of this is
that each user (whether an
application progranuner or
end user) needs to learn only
one data model — an advan¬
tage that nonrelational sys¬
tems usually do not offer
(IBM’s IMS, together with its
Looking for the first
dictionary, requires the user
to learn two distinct data
models).
CKS ai^kattons devetopment tool
Another consequence is
that author!^ users can
easily extend the catalog to
that^ as versatile as you aref .
become a full-fledged, active, As a data processed manager, you v/ear a '
relational data dictionary lot of dMuem hats. Constantly batanong
whenever the vendor fails to programmer-resources, machine resources
do so.
and time demands to get your different
fobsdone. .
Compreheimive data aab-
language rule. That’s why you r«edCONSENSUS*TiOm
Kttle &' A relational sys¬ Marbn Marietta Data Systems. The fast
tem may support several on-line applications dei^iopment ttiol to
languages and various let you develop applications three deferent
modes of terminal use (for ‘ways arM in w^tever bperatng environ¬
exampderthe fiU-in-the- ment )«)u choose.
blanks inode). However,
With CONSENSUS.you can de^lop ap¬
there must be at least one
plications n COBOL ai^ in 4GL procedural
language whose statements
and non-procedumi languages. CONSENSUS
are expressible, per some
accesses aknpst every popular database
wellni^ned syntax, as char¬
acter strings and that is and lets you develop in OCS. CMS, VMK
comprehensiife insupport¬ or batch erMTonrnents- Ar>d. most impar-
ing Ml of the following items: tantly. al CONSENSUS components are
■ Data d^nition. compatible with dne another and v^ et-
■ View <U(finition. isbng applications.
■ Data manipulation (in¬ CONSENSUS is truly a breakthrou^
teractive and by program). product One whidi Can change the
■ Integrity constraints. you develop OCS appkabons. lt'$ another
■ Authorization. of Martin Marietta’s Natural Selection^
■ TVansaction bound¬
products—an interrelated family of products
aries (begin, commit and
that work writh an extraordinary variety of
rollback): ,
machines, environments, appkatxms
The relational approach is
needs and degree of uier sophisticatxm.
intentionally highly dynamic
— that la, it should rarely be If you thou^ you’d never feid an appli¬
necessary to bring the data cations development tool that's as versatie
base activity to a halt (In as you are. you’re vi for a nice surpree.
.contrast to nonrelational It’s ready now'
DBlk^). Therefore, it does
not m^e sense to separate
the services listed above into CM ^
distinct languages. Mirbn riarcttt Dm Siwmtt cw-tei#
COMSENSUSMbmution .
in the mid-’70s, the Ansi
PO Bw 2392. Prmcetan. N| 08540
Standards Planning and Re^
O I'd Me a Represenowc iq oN.
quiremenCs (^mmittee gen¬
□ Please send me CONSENSUS bteraiura.
erated a document advocat¬
ing 42 distinct interfaces and
(potentially) 42 distinct lan¬ tir*—
guages for DBMS. Fortunate¬ rrme^
ly, that idea has apparently -
b^n abandoned.
nia^( 1
^ew updatlag rule.
Ruled: All views that are
‘theoretically updatable are
■also updatable by the sys-
,tem.
1 Ttfv |
Note that a view is theo¬
retically updatable if there
' exists a time-iruiependent al-
- gorithm for unambiguously '
Martin Marietta^ CONSENSUS.
determining a single series of
changes to the base relations W^readynew.
that will have as their effect
precisely the requested
changes in the view. In this
 IrShr^Kil

dedicated

Lock To The Ritufe.

MuIdMate is moving up with wotd
processing for the IBM System 36 and
mainframes. And MultiMate fiir
minis-an coming soon.

IMoe Advantage
Of Local Area Netwoiks.
LAN versions of MultiMate Advantage and MultiMate 3.3
Series bring word processing to every desk. Hardware specific
vOTons enhance IBM
MuItiMate’s twhniraii support
is the best in the industry with
ondine assrstanoe available every
-ifcl*' business day. User newdetters A
aixl training programs, too. V

Call 800-842-8676 ext 902

SawsWith You’D get the good word on MultiMate products and
services. Or send some words of your own to: MuhiMale
Intematiaoal Corporatioa, 52 Oiildaiid Ave., East Haitfcrd,
CT 06108. In Connecticut caU (203) 522-2116, exL902
For large scale users, site licensing
brings MultiMate convenience to
every desk at substantiaUy lower cost
You can even duplicate your own
diskettes and documentatioo if you
dxxise.
Itimate
 COMRJTERWORLO OCTOeCR 14, 1965

IN DCPTN/RELATIONAL DBMS

tkih 8: Appiicatkm pro-
gramg omd Urmimil aetivi-
tits remain logicaily umim-
pnred-whemever oMff changes
are made iM either storage
representations or access
methods.
lb hmndle this, the DBMS
must support a cl^, sharp
boundary between the logi¬
cal and semantic aspects on
ibe one haitd and the physi¬
cal and performance aspects
of the base tables on the oth-
^ i^>pHcation programs
must deal with.the logical
aspects only.
Nonrelational DBMS rare¬
ly provide complete support
for this rule — in fact; I
know of ncMte that do.
Then, the additional integri¬
ty constraints are defined in
terms of the high-level data
sublanguage and the defini¬
tions stored in the catalog,
not in the application pro-
grams.
Information about inade¬
quately identified objects is
never recorded in a relation¬
al data base. To be more spe¬
cific, the following two in¬
tegrity rules apply to every
relatuMial data base:
Batity iategrity. No com¬
ponent of a primary key is
allowed Urhave a null value.
Referential integrity. For
each distinct nonnuU foreign
key value in a relational data
base, there must exist a
matching primary key value
from the same domain.
If, as sometimes happens,
either business policies or
government regulations
change, it will probably be¬
come necessary to change
the integrity constraints.
Normally, this can be accom¬
plished in a fully relational
DBMS by changing one or
terminal activities are 16gi-
cally impaired.
Nonrelational DBMS rare¬
Rulell;.4 ly support this rule as part .
of the DBMS engine, where it
relational
belongs. Instead, they de¬
DBMS has
pend on a dictionary pack¬
distribution age, which may or may not
independence. be present and can readily be
bypassed.
more of the integrity state- Dtstiibution indepen¬
ments that are stored in the dence.
catalog. Jbife II: A relational
In many cases, neither the DBMS has distribution inde¬
application programs nor the pendence.

Logical data ladepea-

deace.
Mate $: Appiieation
programs and terminal deti-
vites remota togicailg unim-
pared when information-
preserving changes qf any
kind that theoretically per¬
mit unimpairmeni are-made

HOWTO
to the base tables.
Take the following two
examples: splitting a table
iitto two tables, either by
rows using row content or'by
columns using column
names, if primary keys are
* iweserved in each result; or

MAKEA
combining two tables into
one by means of a nonloss
joiit (Stanford University
and MIT authors call these
joins “lo^ess”).
lb provide this service
whenever possible, the

GREAT
DBMS must be capable of
handling inserts, updates
and deletes on all view that
are the<Metically updatable.
This rule permits logical data
base design to be changed
dynamically il^ for example,
such a change would im¬

IMHtESSiaV
prove performance.
The physical aiid logical
data in^pendmtee rules per¬
mit data base designers for
fclatkmai DBMS to make
mistakes in their designs
without the heavy penalties
levied by nonrelational

ATTHE
DBMS. This, in turn, means
that it is much easier to get
started with a rel^onal
DBMS because not nearly as
much peiformance-oriented
planning is needed prior to
••Nsm-off.”

lategrlty tadepeadeace.
Mate 19s Integrity con¬
straints specific to a partic-
nlar reiaiional data base
mast be definable in the re¬
lational data suhUtngnage
and storable in the catalog,
not in the appHoation pro¬
(STICE
grams.
In addition to the two in¬
tegrity rules (entity integrity
and referential integrity)
that apply to every relation¬
al data base, there tg a clear
heed to be able to specify ^
additiooal integrity cem-
straUtts reflecting^ither
business policies or govern-
meiA regulations.
Assume the relational
model is faithhilly reflected.
 IW Pgrai/REI-ATIONAL DBMS

By distribution indepen¬
dence, I mean that the DBMS
has a data sublanguage that
enables application pro- .
grains and terminal activities
to remain logically unim¬
paired:
■ when dau distribution
is nrst introduced (if the
originally installed DBMS
manages nondistributed data
only);
■ when data is redistrib¬
uted (if the DBMS manages
distributed data).
Note that the definition is
carefully worded s6 that
both distributed and nondia-
tributed. DBMS can,fuUy sup¬
port Rule 11. IBM's SQL/D8
and DB2, Oracle Corp.'sOra*
cle and Relational Tachnol-
0^, Inc. 's Ingres (all nondis-
tributed in present releases)
fully, support this rule.
This has been demonstrat¬
ed as follows: SQL programs
have been written to operate
on nondistributed data (us-,
ing System R) run corre^y
on distributed versions of
that data (using System R*,
the IBM San Jose Research
Laboratory prototype), and
the distribute Ingres pruject
at the University of Califor¬
nia at Berkeley has shown
the same capability for the
Quel language of Ingres.
It is Important to distin¬
guish distributed processing
from distributed dau. In the
former case, woric (for exam¬
ple, programs) is transmitted
to the data; in the latter case,
dau is transmitted to the
woric. Many nonreiatibnal
dBms support distributed
processing but not distribut¬
ed data. The only systems
that support the concept of
msking all the distributed
dau appear to be local are
relational DBMS — these are
prototypes right now.
In the case of a distribut¬
ed relational DBMS, a single
transaction may straddle
several remote sites. Such
straddling is managed entire¬
ly under the covers — the
system may have to execute
recovery at multiple sites.
Each program or terminal ac-
tivlty treats the toulity of
data as if it were all lo^ to
the site where the applica¬
tion program or tcrmiiial ac-
tivity is being executed.
A fuUy relational DBMS
that does not support d&-
tributed dau bases has the
capability of being extended
to provide that support
while leaving apiAication
programs and terminal activ¬
ities logically unimpaired,
both at the time of initial
distribution and whenever
later redistr^Hition is made.
Thery are four impmtant
reasons why relational
DBMS «\{oy this advantage:
■ Pecesapaaltlaa flexft-
MUty in deciding how to de¬
ploy the-dau.
■ Rerampesltlea powci
of the relational operators
when combining the results
of snbtransactions executed
St different sites.
■ Bctuomy ai traaaatia-.
Sion resulting from the fact
that there need not be a're-
quest message sent for each

With the Hewlett-Packard LaserJet Printer. record to be retrieved from

any remote site.
■ AnaljnaMlity of iateat
(owing to the very high level
of relational languages) for
vastly improved optimiza¬
tion of execution.
indictting a lower overall risk thaa had oriiicaily beeii proieciad.
Noaeabveriioa rale.~
Market Penetration Male 19: If a reiatiottal
Sum* iairodnciioa in 1976, the product has cxperieaced irenieiidoiu grawth is all gaoeraakkal
system has a low-level (tin-
araas. la fact, the only quartar>io>quarier caceptiOB occurred QI-Q2.l9lio. whta lha raw of f^-record-at-a-time) tan-
peaemtion stalled as a result of the $.36 coupbe ofTetad ^y the leadiog compaiiior geage, that tow level cannot
be used to sutwert or bgpaeg
the integrity rules and con¬
straints expressed in the
higher level relationai lan¬
guage (muUipte-reeords-at-
a-time).
In the relational ap¬
proach. preservation ot in¬
tegrity is made independent
of logical dau structure to
All lagioas are coetributiag lo this growth, especially the Southara RegioB, which Is aapariaacsag achieve integrity indepen¬
a growth ia aaarket peoetratioB far greaiar thaa iha Saduatry average, la the test three qurtert. dence. This rule is extremely
the Seechera Seglea hai lacreaaad M a rasa twice that at the taae perfed la Uw grulaaa year.
Flntrr Jh coaparas Soutbera Regioa and overall coaspeay perfomaacc with iaduiiry growth difficult fbr a "Ixan-again”
8)^tem to obey because such
s system already sui^orts an
interface below the relation¬
al constraint Interface. Ven¬
dors of “born-again" sys¬
tems do not sppear to have
given this pri^lem adequate
attention.

(hsrt two: the practical con-

HEWLETT soQuences qfthe it rules and
an evatuation {^certain
PACKARD
products against the ra¬
tional model.)
Inipect on PreRtabHity

The most suctesshii

companies hove mode Fution
Prod^Jrtl. the leoding
nippiief of query/report-
processor and spreodsheet
sofhMre for he IBM/'SB-db.
CoH4TS 461-4760 or write.

rwMM Sr«Sact» MemSoRU

muftapwLC SMum
loreipHr. astm iaa> usom