`
`.
`
`(
`
`:
`
`}
`
`2
`
`ys,
`
`\
`
`fe~
`
`
`/4
`THE SYSTEMS PROGRAMMING SERIES
`
`i
`1
`2%
`= —S ey NN ~~ .
`a MhHy
`»
`2 ; i ™ Ww X
`q
`fef'sifieOhelstf
`
`Md ee
`“,
`|
`
`-
`uf {
`
`\\NdNt
`
`’
`AN INTRODUCTION TO
`iyyi
`
`: ’ '
`TYHA
`
`‘
`
`| |
`|
`
`rif!itFi
`i4|/
`battUy
`(Ihi
`
`
`
`DATABASE }..
`
`
`
`
`
`
`
`
`
`
`
`} j
`
`a
`
`\ 1
`
`
`
`
`iyiwit
`
`iI
`in ‘5
`)||
`my
`
`
`
`
`Meta Platforms, Inc.
`Exhibit 1024
`Page 001
`
`Meta Platforms, Inc.
`Exhibit 1024
`Page 001
`
`

`

`
`
`SIXTH
`
`EDITION
`
`C. J. Date
`
`AN INTRODUCTION TO
`
`Page 002
`
`Database
`Systems
`
`Meta Platforms, Inc.
`Exhibit 1024
`Page 002
`
`

`

`
`
`This bookis in the
`Addison-Wesley Systems Programming SerieseeystemsFrOgramming
`series
`This book is dedicated to my wife Lindy
`and to the memory of my mother Rene
`
`Consulting Editors: IBM Editorial Board
`
`Manyofthe designations used by manufacturers and sellers to distinguish their products
`are claimed as trademarks. Where those designations appear in this book, and Addison-
`Wesley was aware of a trademark claim,the designations havebeenprintedin initial caps
`
`The programsand applications presentedin this b
`ook have been included fortheir
`instructional value, They have beentested with c
`are, but are not guaranteed for any
`particular purpose. The publisher doesnotoffer
`any warranties or representations, nor
`doesit acceptany liabilities with respectto the
`programsorapplications.
`Library of Congress Cataloging-in-Publication Data
`
`An introduction to database systems / C. J. Date. — 6th ed.
`cm. — (The Systems programmingseries)
`Includes bibliographical references and index.
`ISBN 0-201-54329_xK
`1. Database management.
`I.Title,
`Il. Series: Addison-Wesley
`systems programmingseries.
`QA76.9.D3D3659
`1995
`005.74—dc20
`
`94-3187
`CIP
`
`Reprinted with corrections November, 1994
`
`94
`
`nd
`
`Meta Platforms, Inc.
`Exhibit 1024
`Page 003
`
`

`

`
`
`Chapter 1 An Overview of Database Management
`
`3
`
`
`
`
`
`
` =
`
`
`WINE
`
`PRODUCER
`
`YEAR
`
`READY
`
`BOTTLES
`ls
`94 |
`iT:
`92
`Chardonnay a Buena Vista
`
`94
`5
`92
`Chardonnay
`Geyser Peak
`
`
`93
`4
`91
`Chardonnay
`Stonestreet
`94
`1
`93
`Jo. Riesling
`Jekel
`94
`4
`92
`Fumé Blane
`Ch. St. Jean
`
`93
`2
`or
`Fumé Blanc
`Robt. Mondavi
`
`
`94
`3
`93
`Gewurztraminer
`Ch. St. Jean
`aE
`12
`86
`Cab. Sauvignon Windsor
`97
`I
`89
`Cab. Sauvignon
`Geyser Peak
`
`99
`12
`88
`Cab. Sauvignon
`Robt. Mondavi
`94
`3
`91
`Pinot Noir
`Gary Farrell
`95
`3
`88
`Pinot Noir
`Stemmler
`
`93
`2
`90
`Pinot Noir
`Dehlinger
`95
`9
`89
`Merlot
`Clos du Bois
`98
`9
`89
`Zinfandel
`Lytton Spring
`
`98
`2
`90
`Zinfandel
`Rafanelli
`
`fe — =|
`
`||An Overview of
`Database Management
`
`
`
`1.1 An Introductory Example
`A database System is essen
`tially nothi
`.
`System. The database itself
`we more: than a computerized record.-
`can be regarded as a kind
`
`Adding new, empty fi
`les to the database
`Inserting new data int
`0 existing files
`a Retrieving data from
`Updating data
`in
`ex; aa ia
`410 existing files
`Deleting data from existing files
`Removing existing fi
`£6EIAPLY ar otherwise, from the database
`B
`tr
`y wayofillustrati
`:
`a aa
`file, called CELL.
`na :1g. 1.1 shows a very small
`AR, which
`;
`database containingjust a single
`E
`
`1
`
`;
`
`992
`
`-1994,
`
`1994
`
`and
`
`‘d and
`
`1993
`
`
`
`
`
`FIG. 1.1 The wine cellar database (CELLARfile)
`
`m=
`
`Second,the rowsof such a table can be thoughtof as representing the records of
`the file (sometimesreferred to explicitly as /ogical records, to distinguish them
`from other kinds of records to be discussed later). Likewise, the columns can be
`regarded as representing the fields of those logical records. In this book, wewill
`tend to use the “record” and “field” terminology when we are talking about
`database systems in general, the “row” and “column” terminology when weare
`talking aboutrelational systems specifically. (Actually, when we get to our more
`formal relational discussions in later parts of the book, we will switch to more
`formal terms anyway.)
`
`
`
`
`Retrieval:
`
`SELECT WINE, BIN, PRODUCER
`FROM
`CELLAR
`
`WHERE READY = 95 ;
`
`
`
`RQ
`58|Clos du Bois
`
`
`Meta Platforms, Inc.
`Exhibit 1024
`Page 004
`
`

`

`|
`|
`|
`
`inserting new data:
`INSERT
`INTO
`
`ce ( BIN, WINE, PRODUCER, YEAR, BOTTLES
`ALUES ( 53,
`‘Pinot Noir',
`"Saintsbury'!
`92,
`’
`'
`
`
`
`Updating existing data:
`
`|
`|
`
`|
`
`DELETE
`CELLAR
`FROM
`WHERE BIN = 2 ;
`peeeeee
`FIG, 1.3 INSERT, UPDATE, and DELETE examples
`
` 4
`
`
`
`Chapter 1 An Overview of Database Management
`
`READ
`1,
`se :
`'
`)
`
`y
`
`e
`
`Application
`programs
`
`Database
`
`7 Database management system (DBMS) A107)
`
`End users
`
`192
`
`1994,
`
`1994
`
`nd
`
`and
`
`' d
`
`993
`
`UPDATE CELLAR
`SET
`BOTTLES = 4
`
`WHERE BIN = 3 ;
`| Deleting existing data:
`
`eeSe
`
`|
`
`| |
`
`}
`
`Originally an abbreviation for “
`
`S
`
`1.2 Whatisa Database System?
`To repeatfr
`:
`om Section 1.]
`5
`F
`keeping system:
`Seite database 5 St
`:
`a
`:
`m; thatis,it j
`©
`system is basically
`tain information and to nikeeee System whose aadgere
`that information available onRe rfa-
`concemed can be anythj
`ye
`ything that is d
`organization the system is intended Sere. 0 be of significance to the individual or
`5
`i gs in other words tha
`to
`assist in
`ri
`if
`the general Pp OCeSssS O running the business ofth
`‘ is needed
`
`[he information
`
`FIG. 1.4 Simplified picture of a database system
`
`Fig. 1.4 shows a greatly simplified view of a database system. The figure is in-
`tendedto illustrate the point that a database system involves four major components,
`namely, data, hardware, software, and users. We consider these four components
`briefly below. Later, of course, we will discuss each in much moredetail (except for the
`hardware component, mostdetails of which are beyond the scope of this book).
`
`Data
`Database systems are available on machinesthat range all the way from quite small
`micros (even portable PCs) to the largest mainframes. Needless to say, the facilities
`provided by any given system are to some extent determined by the size and power of
`the underlying machine.In particular, systems on large machines (“large systems’’)
`tend to be multi-user, whereas those on smaller machines(“small systems”) tend to be
`single-user. A single-user system is a system in whichat mostoneuser can access the
`database at any given time; a multi-user system is a system in which many users can
`access the database concurrently. As Fig. 1.4 suggests, we will normally assume the
`
`Meta Platforms, Inc.
`Exhibit 1024
`Page 005
`
`€
`

`

`
`
`Part | Basic Conce AG
` on,
`eeon stored in the system is all held in a single database, and We will
`In practice Bernee it does not materially affect any of our other disenl
`ene an ae eremightbe goodreasons,even in a small system,
`wh ae
`ete several distinct databases. We will touch
`eerie “ata
`sonselsewhere in this book(e.g,, in Chapter2),
`feedsHose oe
`ee ce the data inthe database—atleast in a lar
`&€ System—will be both
`e ee iared. AS we will see in Section 1,4, these two
`aspects, dataintegra;
`ronment; and dataintegration,aleastcanesee
`ion
`eins in the “large” envi-
`;
`, at
`least, can be significant
`j
`Seaceearemany additional*ibdtteeds al- te
`the small” Environment
`be discussed later), even
`nment. But first let us explai
`ali
`grated” and “shared.”
`abe
`mean bytheterms “inte.
`By integrated, w»
`We mean that the datab
`several otherwise
`dict;
`‘abase can be thought
` .
`or partly okadatafiles,withanyeee of
`EMPLOYEE file,
`giv;
`example, a £lven database might eCtain a
`.
`:
`Ale
`
`B
`
`992
`
`-1994,
`
`Ww
`
`1994
`
`ind
`
`and
`
`4 d
`
`1993
`
`Chapter 1 An Overview of Database Management
`(moreover, different users’ portions will overlap in many different ways). In other
`words, a given database will be perceived by different users in a variety of different
`ways.In fact, even when two users share the sameportion of the database, their views
`ofthat portion mightdiffer considerably ata detailed level. This latter pointis discussed
`morefully in Section 1.5 andin the next chapter.
`
`m
`
`Hardware
`The hardwareportions of the system consist of:
`m Thesecondary storage volumes—typically moving-head magnetic disks—thatare
`used to hold the stored data, together with the associated I/O devices (disk drives,
`etc.), device controllers, 1/O channels, and so forth; and
`The processor(s) and associated main memory that are used to support the execu-
`tion of the database system software (see the next subsection below).
`This book does not concern itself very greatly with the hardware portions of the
`system,for the following reasons among others: First, these aspects form a majortopic
`in their own right; second, the problems encountered in this area are not peculiar to
`database systems; andthird, those problems have been very thoroughly investigated
`and documented in numerousotherplaces.
`
`For
`
`Software
`Betweenthe physical databaseitself (i.e., the data as actually stored) andthe users of
`the system is a layer of software, the database manager (DB manager) or, more USU-
`ally, database management system (DBMS).All requests from users for access to the
`database are handled by the DBMS;thefacilities sketched in Section 1.1 for adding and
`removingfiles(ortables), retrieving data from and updating data in suchfiles or tables,
`and so forth,areall facilities provided by the DBMS. One general function provided by
`the DBMSisthus the shielding of database users from hardware-level details (much
`as programming-language systemsshield application programmers from hardware-
`level details). In other words, the DBMSprovidesusers with a view of the databasethat
`is elevated somewhat above the hardwarelevel, and supports user operations( such as
`the SQL operationsdiscussedbriefly in Section 1.1) that are expressed in termsof that
`higher-level view. Weshall discuss this function, and other functions of the DBMS,in
`considerably more detail throughout the body ofthis book.
`Note: The DBMSiseasily the most important software componentin the overall
`
`
`
`Meta Platforms, Inc.
`Exhibit 1024
`Page 006
`
`

`

`
`
`ably other operations) as wel]
`‘4
`uAdatabase consists of some collection of persistent data that is used by the appli-
`Most systems
`:
`also provide additi
`aes
`‘d and
`not issue explicit command Ea bia interfaces in which ests do
`cation systems of some given enterprise.
`S such
`ao ee items from a meny ree at all, but instead operate by
`S-driven interf.
`In boxes on
`formal training in ITree to be easier to use for seesar mae ee
`Information Systemsig a Information Technology:
`the a © not havea
`command-driven interf. ©nused with much the same meanin aaa a
`tain amount of pastesae query languages—do tend a ell
`(obviously notas ee al T expertise, though Parhanehst
`O require a cer-
`guagelike COBOL),
`THe eed 10write an application nee ee
`a
`). Then again
`more flexible than
`gain, a command-driven interface js likely to be
`:
`a4 menu- or form
`_
`typically provide certaj
`___°rms-driven one,
`j
`faces,
`€rtain functions that are
`*
`in
`that query languages
`not supported by those otherinter-
`
`srr
`
`es
`
`Program in a lan-
`
`1. A manufacturing company
`2. A bank
`
`3. A hospital
`4. A university
`5. A government department
`
`"Cents
`
`Chapter 1 An Overview of Database Management
`
`Persistent Data
`
`It is customary to refer to the data in a database as “persistent” (even though it might
`not actually persist for very long!). By “persistent,” we mean to suggest that database
`data differs in kind from other, more ephemeral, data, such as input data, outputdata,
`control statements, work queues, software control blocks, intermediate results, and
`more generally any data thatis transient in nature. Let us elaborate briefly on the terms
`‘input data’ and “output data”:
`“Input data”refers to information entering the system forthe very first time (typi-
`cally from a terminal or workstation). Such information might cause a change to be
`madeto the persistent data (it might becomepart ofthe persistent data), but itis not
`initially part of the database as such.
`Similarly, “output data” refers to messages and results emanating from the system
`(typically printed or displayed on a screen). Again, such information might be derived
`from the persistent data, butit is not itself consideredto be part of the database.
`
`=
`
`Of course, the distinction between persistent and transient data is not a hard and
`fast one—it depends to some extent on context(i-e., how the data is being used). How-
`ever, assuming that the distinction does at least make someintuitive sense, we can now
`give a slightly more precise definition of the term “database”:
`
`Theterm “enterprise” here is simply a convenient generic term for any reasonablyself-
`contained commercial, scientific, technical, or other organization. An enterprise might
`be a single individual (with a small private database), or a complete corporation or
`similar large body (with a very large shared database), or anything in between. Here are
`some examples:
`
`ad
`
`1994
`
`and
`
`1993
`
`Part! Bac:ASIC Cy
`plication programsthat use the database, typically in a language
`or PL/I or some more modern language such as C or Pascal. Thosea “OB9
`ooueeoan theoe ways—retrievingexistinginformation,inca Oper.
`va berie n changingexisting information. All of these aeeo
`facies 4issuing the appropriate request to the DBMS raAs
`See ry* conventional batch applications, or they may be 4 a
`is accessingthe databas es Isto SOpport an enduser(see the next Paragra ivi
`selene efrom an online workstation or terminal. M ae
`€ online variety,
`eee
`The secondclassof user, then, is end users
`ae Interact with the System from
`online workstations or terminals. A given .
`user Can accessthe database Via
`oneofthe online applications mentioned in t
`he previous Paragraph,or he or Ric
`
` 1.3 What Is a Database?
`
`Meta Platforms, Inc.
`Exhibit 1024
`Page 007
`
`

`

`It is important to understandthat, in addition to the basic entities themselves, there
`will also be relationships linking those basic entities together. Such relationships are
`represented by diamondsand connecting lines in Fig. 1.6. For example, there is a rela-
`tionship (“SP”) between suppliers andparts: Each supplier supplies certain parts, and
`conversely each part is supplied by certain suppliers (more accurately, each supplier
`supplies certain kinds ofparts, each kind ofpart is supplied by certain suppliers). Sim-
`ilarly, parts are used in projects, and conversely projects use parts (relationship PJ);
`parts are stored in warehouses, and warehousesstore parts (relationship WP); and so
`on. Notethat these relationships are all bidirectional—thatis, they can be traversed in
`either direction. For example,relationship SP between suppliers and parts can be used
`to answereitherof the following questions:
`= Given a supplier, find the parts supplied by that supplier
`= Givenapart, find the suppliers who supply that part
`The significant point aboutthis relationship, and all of the others illustrated in the
`figure, is that they are just as much a part of the data as are the basic entities. They
`musttherefore be representedin the database,just like the basic entities. Later in this
`book we will consider ways in which this can be done.
`Incidentally, Fig. 1.6 is a simple example of whatis called (for obvious reasons) an
`entity/relationship diagram (E/R diagram for short). In Chapter 12 we will consider
`such diagramsin some detail.
`Fig. 1.6 also illustrates a numberof other points:
`1. Although mostofthe relationships in the diagram involve twotypesof entity—ce.,
`they are binary relationships—itis by no meansthecasethatall relationships must
`necessarily be binary in this sense. In the example there is onerelationship (“SPJ”)
`involving three types of entity (suppliers, parts, and projects )—a ternary relation-
`ship. The intendedinterpretation is that certain suppliers supply certain parts to
`certain projects. Note carefully that this ternary relationship (“suppliers supply
`parts to projects’) is not equivalent, in general, to the combination of the three
`binary relationships “suppliers supply parts,” “parts are used in projects,” and
`“projects are supplied by suppliers.” For example, the statementthat
`(a) Smith supplies monkey wrenchesto the Manhattan project
`tells us more than the following three statements do:
`(b) Smith supplies monkey wrenches,
`(c) Monkey wrenchesare used in the Manhattan project, and
`
`
`
`10
`
`4. Student data
`
`eo
`
`5. Planning data
`
`Note: Thefirst few editions of this book used the term ‘‘o
`perationaldata”j
`of “persistent data.” That earlier term reflected the original e
`n Place
`mphasis in datah
`ase Sys.
`tems on operationalor production applications—i.e., routin
`e, highly repetitive apny.
`cations that were executed over and over again to support th
`e day-to-day operatior, of
`the enterprise (forexample, an application to Support the dep
`osit Or withdrawal Ofcash
`ina banking system). Nowthat databases are increasingly be
`Ing used for other kinds of
`application as well—i.e., decision support applications—t
`he term “Operational data”
`Le
`ays often maintai
`:
`ain twodis-
`aining operational data and one containing decision RipponOr
`data. The decisicision support database frequently consists ofsummary information (n(eg.,
`
`, one cont
`
`Entities and Relationships
`
`Warehouses
`
`
`
`Part | Basic Concenes
`Chapter 1 An Overview of Database Management
`11
`
`
`EY
`
`tion,
`193
`
`193
`
`1992
`
`[-1994,
`
`, 1994
`
`and
`
`Q4
`
`ed and
`
`L993
`
`Meta Platforms, Inc.
`Exhibit 1024
`Page 008
`
`

`

` iAhaafocnti
`
`inferences suchas these are examples of what is sometimes called th
`trap.
`2. The diagram also includes onerelationship (PP) involvin
`(parts). The relationshiphereis thatcertain parts include
`otherparts asj
`:
`ee
`S
`as
`imn
`materials relationship)—for example
`components(the so-calledbill-of-
`4 componentof a hinge assembly
`, whichis also considered as
`turn be a component ofsome higher-level part such asa lid. Nitea is oad
`ship is still binary; it isj
`Is relat;
`;
`Just that the two types of entit
`;
`Elation-
`namelyparts and parts, happento be oneandthe same. gees linked together,
`3. In general, a given set of enti
`
`* Connection
`
`entity
`ediate
`a Screw jg
`
`t
`
`and employees: One (EJ) rep
`Jects, the other (MJ) represents the fact thatemploye
`Note carefull
`‘
`y that a relationshi
`;
`in its
`takeas ourdefinitio
`onsiuip canbe regarded as an entity
`thenaTelationship ees anyobjectaboutwhichweoaktoenee ‘ight. If we
`house W8”is an enti ma
`ts the definition. For instance “part Pd j s prmation,
`the correspondingmeinen we might well wish to record eo mee
`of the present ch
`- Moreover, there are definiteadvanta
`ation—e.g.,
`chapter) to be obtained Lynne naees vantages (beyondthe scope
`tween entities and relationships.In this b
`foreoeecessary distinctions be-
`shipsas just
`ook,therefore
`eas
`a special kind ofentity,
`~~ “6wall generally treat relation-
`Just
`
`1
`
`i
`
`:
`
`5
`
`1
`
`*
`
`P
`
`Properties
`
`-
`
`es; and'so on. Such oreneus oo Projects have priorities;
`Properties
`r
`eT
`Forexample,the databasemightwhe Peepeered
`ntity typetoate
`cludearecord type S represent-
`record type in
`turn
`might
`i
`CITY
`representing
`type in turn mightinclude a field type
`.
`the “location”
`Properties in turn might be rae
`ple in nature.
`o
`ce
`ample weesthey might havean internal
`structure ofarbitrary complexity. For ex
`oes ofjtisca upPlier location” property is pre-
`sumably quite simple, consisting as it d
`aracter string. By pa name, and can berepresented
`in the database by a simple ch
`“floorplan” property, and that
`;
`ntrast, a warehouse might have a
`
`
`
`Chapter 1 An Overview of Database Management
`13
`
`
`LEY
`
`tion,
`193
`
`193
`
`1992
`
`1-1994,
`
`]
`
`5. 1994
`
`| and
`
`194
`
`ted and
`
`1993
`
`4 ,
`
`dition,
`
`> 1
`
`1.4 Why Database?
`Why use a database system? What are the advantages? To some extent the answerto
`these questions depends on whetherthe system in question is single- or multi-user (or
`rather, to be more accurate, there are numerous additional advantagesin the multi-user
`case). Let us consider the single-user case first.
`Refer backto the wine cellar example onceagain (Fig. I.1), which we can regard
`as typical of a single-user database. Now, that particular database is so small and so
`simplethat the advantages might not be very immediately obvious. But imagine a sim-
`ilar databasefora large restaurant, with a stock of perhaps thousandsofbottles and with
`very frequent changesto that stock; or think of a liquor store, with again a very large
`stock and with high turnoveronthatstock. (These would typically still be single-user
`systems, incidentally, even though the databaseis larger.) The advantagesof a database
`system overtraditional, paper-based methodsof record-keeping will perhaps be more
`readily apparentin these examples. Here are someof them:
`Compactness: No need for possibly voluminouspaperfiles.
`Speed: The machine canretrieve and change data far faster than a humancan. In
`particular, ad hoc, spur-of-the-moment queries (e.g., “Do we have more Zinfandel
`than Pinot Noir?”) can be answered quickly without any need for time-consuming
`manual orvisual searches.
`Less drudgery: Muchofthe sheer tedium of maintaining files by hand is elimi-
`nated. Mechanicaltasks are alwaysbetter done by machines.
`= Currency: Accurate, up-to-date informationis available on demandat any time.
`The foregoing benefits apply with even more force in a multi-user environment, of
`course, where the databaseis likely to be much larger and much more complex than in
`the single-user case. However,there is one overriding additional advantage in such an
`environment, namely as follows: The database system provides the enterprise with cen-
`tralized controlofits data (which,as the reader should realize from Section 1.3, is one
`of its most valuable assets). Such a situation contrasts sharply with that found in an
`enterprise withouta database system, where typically each application has its own pri-
`vate files—quite often its own private tapes and disks, too—sothat the data is widely
`dispersed and mightthusbe difficult to control in any systematic way.
`
`m_
`
`Data Administration and Database Administration
`
`Meta Platforms, Inc.
`Exhibit 1024
`Page 009
`
`

`

`14
`
`15
`
`993
`
`r
`1992
`
`SEES 1cébya tea ;
`
`11-1994,
`
`1,
`192
`
`39,
`
`le
`
`2.
`
`a
`
`Pecific advantages that accrue from
`
`applicati
`
`i
`
`i
`
`Part! Basic ConcentS$
`Chapter 1 An Overview of Database Management
`person. Thus,it is the data administrator’s job to decide whatdata should
`the databasein the first place, andto establish policies for maintaining and d Bei
`databaseis said to be inconsistent. Clearly, a database thatis in an inconsistentstate
`that data onceit has been stored. An example ofsuch a policy would be o ce eh
`is capable of supplying incorrect or contradictory informationto its users.
`whocan perform whatoperations on what data in what pifrumistances—in reatates
`It should also be clearthat if the given fact is represented by a single entry (1.¢.,
`a data securitypolicy (see further discussion below),
`ae rs
`if the redundancy is removed), then such an inconsistency cannot occur. Alterna-
`tively, if the redundancy is not removedbut is controlled (by making it known to
`Note carefully that the data administrator is a manager
`nota technician (although
`he or she certainly does need to have some appreciation oft
`the DBMS), then the DBMScould guarantee that the database is never inconsistent
`he capabilities of database
`as seen by the user, by ensuring that any change madeto either of the two entries
`systems at a technical level). The technical person respon
`sible for implementi
`:
`es administrator (usually ric
`is automatically applied to the other one also. This process is known as propagat-
`Pe
`ting the
`data administrator’s decisions is the
`ing updates—where (as is usually the case) the term “update”is taken to include
`DBA). Thus, the DBA,unlike the data
`administrator, 1s an /Tprofessional, The job of
`all of the operations of insertion, deletion, and modification. Note, however, that
`the DBAisto create the actual database
`and to imple
`:
`to enf
`;
`:
`a
`plementthe technical
`auieieesdecisionsmadebythedataadministrator TheAa
`few commercially available systems today are capable of automatically propagat-
`ing updates in this manner, that is, most current products do not support controlled
`ensuring
`that the system o
`:
`:
`18 also
`mvidin
`:
`perates with adequate pe
`.
`aeseee ofother related technical services. TheDEAae and for
`redundancyatall, except in certain special situations.
`typically bevetnetesSeoetechnicalassistants(i.e., theBESacto,bil
`The data can be shared.
`Wediscussed this point in Section 1.2, but for completeness we mention it
`for simplicity, however,it is See
`m ofseyeral people, notjust by one person)
`
`
`again here. Sharing means not only that existing applications can share the data in
`eae
`fp
`enient to assu
`ign
`individual. Wewill discuss the DBA function in Rateis ‘ uaa 2apter
`the database, but also that new applications can be developed to operate against
`that samestored data. In other words,it might be possible to satisfy the data re-
`quirementsofnew applications without having to create any additionalstored data.
`Benefits of the Database Approach
`Weclose this section by iden
`Standards canbe enforced.
`the notion ofcentralized con de ne
`:
`tifying
`s
`With central control of the database, the DBA (under the direction of the data
`trol of the data.
`administrator) can ensurethatall applicable standards are observed in the represen-
`Redundancycan be reduced.
`tation of the data. Applicable standards might include any orall of the following:
`corporate, installation, departmental, industry, national, and international stan-
`In nondatabase systems each
`sep ‘cationhasits own privatefiles. This fact can
`dards. Standardizing data representationis particularly desirable as an aid to data
`often lead to considerable redun
`y In stored data, with resultant
`interchange, or migration of data between systems (this consideration is becoming
`nnel application and an education-re
`ia
`Stor
`stor-
`waste in
`age space. For example, a perso
`particularly important with the adventofdistributed processing technology—see
`tion might both
`cords applica-
`Section 2.12). Likewise, data naming and documentation standards are also very
`desirable as an aid to data sharing and understandability.
`Security restrictions can be applied.
`Having complete jurisdiction over the database, the DBA (a) can ensure that
`the only meansofaccessto the database is throughthe proper channels, and hence
`(b) can define security rules to be checked whenever access is attempted to sensi-
`tive data (again, under appropriate direction from the data administrator). Different
`rules can be established for each type ofaccess(retrieve,insert, delete, etc.) to each
`piece of information in the database. Note, however, that without such rules the
`
`Page 010
`
`194
`
`ted and
`
`dition,
`
`Meta Platforms, Inc.
`Exhibit 1024
`Page 010
`
`

`

`7
`Chapter 1 An Overview of Database Management
`quence asdefined by that index, and the internal structure ofthe application will be
`built around that knowledge.In particular, the precise form of the various data access
`and exception-checking procedures within the application will depend very heavily on
`details ofthe interface presented to the application by the data management software.
`Wesay that an application such as the one in this example is data-dependent,
`because it is impossible to changethe storage structure (how the data is physically
`stored) or access technique(howit is accessed) without affecting the application, prob-
`ably drastically. For instance, it would notbe possibleto replace the indexedfile inthe
`example by a hash-addressedfile without making major modifications to the applica-
`tion. Whatis more, the portions of the application requiring alteration in such a case are
`precisely those portionsthat communicate withthe data management software; the dif-
`ficulties involved are quite irrelevant to the problem the application was originally writ-
`ten to solve—i.e., they are difficulties introducedbythe nature of the data management
`In adatabase system, however,it would be extremely undesirable to allow applica-
`tions to be data-dependent, for at least the following two reasons:
`1. Different applications will need different views of the same data. For example,
`supposethat before the enterprise introducesits integrated database, there are two
`applications, A and B, each owningaprivate file that includes the field “customer
`balance.” Suppose, however, that application A records this field in decimal,
`“best for the enterprise.”
`For
`.
`*
`€xample, a representation can be chosen for the data
`whereasapplication B recordsit in binary.It will still be possible to integrate the
`In storage that givesfast
`access for the mosti
`i
`twofiles, and to eliminate the redundancy, provided the DBMSis ready and able
`‘©
`most
`importantapplications
`i
`ance forcertain other sppleanene. oo
`cost of poorer perform
`to perform all necessary conversions between the stored representation chosen
`i
`Ove are
`wever, one
`Most of the ad anta:
`(which might be decimal or binary or somethingelse again) and the form in which
`ges listed ab
`y
`i
`:
`V
`probabl;
`fairly obvious. Ho
`ver,
`int
`:
`each application wishesto see it. For example,if it is decided to store the field in
`the others) need
`decimal, then every accessby B will require a conversionto or from binary.
`This is a fairly trivial example of the kind of difference that might exist in a
`database system between the data as seen by a given application and the data as
`physically stored. Many other possible differences will be consideredlater.
`_ The DBA musthave the freedom to change the storage structure or access tech-
`nique in response to changing requirements, without having to modify existing
`applications. For example, new kindsof data might be addedto the database; new
`standards might be adopted; application priorities (and therefore relative perfor-
`mance requirements) might change; new types of storage device might become
`available; andso on.If applications are data-dependent, such changes will typically
`require corresponding changesto be made to programs, thus tying up programmer
`
`Page 011
`
`75, 1994
`
`d and
`55
`994
`
`noted and
`5,
`
`2 d
`
`i
`;
`:
`g its opposite. Appli-
`P
`T systemst
`’
`hichthe data is
`ead tobe data-dependent. Whatthis Sabie is
`
`laining
`
`ition,
`
`Part! Basic Concenes
`above); of course,that particular problem canarise onlyif redundancyexic.
`;
`stored data. Even ifthere is no redundancy, however, the database Richa ithe
`tain incorrect information. For example, an employee might be shown EF a
`worked 400hours in the weekinstead of40, or as belonging to a eainent5‘i
`no such departmentexists. Centralized control of the database canhelp in
`» , a
`such problems—insofaras they can be avoided—bypermitting the ace ance
`trator to define(and the DBA to implement)integrity rules to be Rete pete
`any data update operation is attempted. (Again weare using the te ae
`ee tocoverall oftheoperationsofinsertion, deletion, and hace,
`nanceAeTeeRanesevenmoreimportantinamlae
`ail
`s
`te
`les" environment, precisely becau:
`|
`ase is shared. For without appropriate controls it would be Peecicicfo. One
`user to update the database inco
`’
`rectly, thereby generating
`b
`ine” other i
`ing bad data andso “infect-
`eaei Taeof that data. It should also be mentioned He
`adaueeee
`to be somewhat weak in their support forinteerit
`:
`nd
`gh
`there
`have been somerecent improvements in this area a
`Conflicting requirements can be balanced
`
`the
`
`interface.
`
`1
`
`993
`
`ar;
`1992
`
`91-1994,
`
`91,
`992
`
`89,
`
`Meta Platforms, Inc.
`Exhibit 1024
`Page 011
`
`€
`

`

`
` 18
`Part | Basic Concen,$
`applications concerned do not depend on anyoneparticular Storage structy
`technique. In Chapter 2, we describe an architecture for database systems a OT acces.
`a basis for achieving the data independence objective. Before then ho a PTOVidex
`sAstored recordis a collection of related stored fields. Again we distinguish be-
`considerin more detail some examples ofthe types ofchange that the mee >
`let ys
`tion,
`tween type and occurrence. A stored record occurrence(or instance) consists of a
`to make, and that we might therefore wish applications to
`MISht Wish
`993
`be immuneto.
`group of related stored field occurrences. For example, a stored record occurrence
`Westart by defining three terms: storedfield, stored
`record, and storedfile ( refer
`in the “parts” Gatabase might consist of an occurrence of each of the following
`to Fig.1.7).
`stored fields: part number, part name,part color, and part weight. Wesay that the
`Yr
`=Astoredfield is the smallest unit of stored dat
`database contains many occurrencesof the “part” stored record type (again, one
`1992
`a. The database will, in genera
`occurrence for each distinct kind ofpart).
`contain many occurrences (or instances) of eac
`h of several types of Stored fiejq
`)1-1994,
`As an aside, we note that it is commonto drop the qualifiers “type” and “oc-
`For example, a database containing informatio
`n about parts would r
`currence” and to rely on context to indicate which is meant. Although there is a
`cludea stored field type called “
`part number,” and there would be Re eein
`slight risk of confusion, the practice is convenient, and we