Design and Implementation of aRelationship-Entity-Datum Data ModelR. G. G. CattellCSL-83-4 April 1983 [P83-00004]c Copyright Xerox Corporation 1983. All rights reserved.Abstract: The Model level of the Cypress Database Management System, built upon theearlier Cedar DBMS, provides data description and access capabilities at a higher level ofabstraction than the existing system and other conventional DBMS's. In this report wedescribe the design of the Cypress data model and discuss issues in the efficientimplementation of such a model. Cypress incorporates features motivated by experience withlocal database applications. It may be viewed as an integration of a number of existing datamodels; we present the criteria that led to this choice. The Cypress primitives include simpledata values such as strings or integers, entities representing real or abstract objects, andrelationships among entities and/or simple data values. We also provide mechanisms for ahierarchy of types, relational keys, and segmentation of databases into independent files.Cypress allows a conventional relational query language. We argue that our extensions tosimpler data models allow a more powerful and efficient implementation, and we describe theoptimizations Cypress performs. We also discuss some preliminary experience with usertools and applications developed in conjunction with Cypress.CR categories: H.2.1, H.2.2, H.4.1Key words and phrases: Cedar, Cypress, database systems, semantic model, data modelXEROXXerox CorporationPalo Alto Research Center3333 Coyote Hill RoadPalo Alto, California 94304ЪНЇО^epТ·НЇО[П$НЇОV!qТXНЇОQqrТFП*s НЇОLбtsП8НЇОE qТх uТиПFНЇОBжТЇП!Т╦П9НЇО@║ТъП.ТЮП(НЇО>mТ%Т&П7НЇО<8Т┘ПVТ├НЇО:Т░П1Т▒П,НЇО7пТ┼П$Т▀П;НЇО5⌡ТЎП1Т©П+НЇО3gТёП;ТєНЇО12ТоПSТпНЇО.ЧТўП9Т╞НЇО,иТ┴ПNТ┼НЇО*∙ТсПLТт НЇО(`ТП=НЇО ╘q uНЇОЯqТЧuvП6ТЪНЇОЙwН*+О(uТXН*+ОєН*+О Н*+О⌡ЪVЇT?QR"І*`^оaTABLE OF CONTENTS1.Introduction11.1Data modelling1.2Cypress and Cedar1.3Design criteria and motivation2.Cypress data model concepts52.1Data independence2.2Basic primitives2.3Names and keys2.4Basic operations2.5Aggregate operations2.6Convenience operations2.7Normalization2.8Segments2.9Augments2.10Views2.11Summary3.Model level interface273.1Types3.2Transactions and segments3.3Data schema definition3.4Basic operations3.5Query operations3.6System domains and relations3.7Errors4. Application example474.1A database application4.2Schema design4.3Example program5. Data model design issues575.1Relations and attributes5.2Entities and domains5.3Entities as relationships5.4Relationships as entities5.5Lists and sets5.6Entity names5.7Keys, normalization, and dependencies5.8Generalization and type hierarchies5.9Access primitives5.10Views, segments, and augments5.11SummaryЪН!BО^оyТiН═ОZСxН─Н8@Н√ОX°Н! ТX Н√ОWН! Н√ОU■Н! Н═ОS<Н─Н8@Н√ОPДН! Н√ОO`Н! Н√ОMэН! Н√ОLXН! Н√ОJтН! Н√ОIPН! Н√ОGлН! Н√ОFHН! Н√ОDдН! Н√ОC@Н! Н√ОA╪Н! Н═О?dН─Н8@Н√О=Н! Н√О;┬Н! Н√О:Н! Н√О8─Н! Н√О6ЭН! Н√О5xН! Н√О3ТН! Н═О1°Н8@Н√О/DН `Н√О-юН `Н√О,<Н `Н═О)ДН8@Н√О'█Н! Н√О& Н! Н√О$┘Н! Н√О#Н! Н√О!}Н! Н√ОЬН! Н√ОtН! П%Н√ОПН! П#Н√ОlН! Н√ОХН! Н√ОdН! Ъj═е ЪJkВ6.Data model implementation issues736.1Storage level structures6.2Entities and relationships6.3Values6.4Caching the data schema6.5Links and colocation6.6Surrogate relations6.7Basic operations6.8Aggregate operations6.9Summary7.Database environment and applications877.1Database environment7.2Database tools7.3Database applications7.4Summary8.Status and conclusions1018.1Summary8.2Some results8.3Status and plans8.4Summary9.Annotated bibliography10510.Appendix and index113ЪН═О_xН─ТXН8@Н√О\ЎН! Н√О[:Н! Н√ОYІН! Н√ОX2Н! Н√ОVўН! Н√ОU*Н! Н√ОSіН! Н√ОR"Н! Н√ОP·Н! Н═ОNFН─П%Н8@Н√ОKНН! Н√ОJjН! Н√ОHФН! Н√ОGbН! Н═ОE Н─Н8@Н√ОB╡Н! Н√ОA.Н! Н√О?╙Н! Н√О>&Н! Н═О;оН─Н8@Н═О9wН─Н8@Ъь═90!╞'▓11. Introduction1.1 Data modellingA data model is a scheme for describing the types of data that may be stored in a database: howthese data may be structured, and how they may be accessed. Any particular database consists ofthe data themselves plus a data schema that describes the types of data in terms of the datadescription primitives of the data model. The three data models most widely used in the past arethe network, hierarchical, and relational models. A good summary of these models can be found inComputing Surveys, March 1976.In recent years, data models with more sophisticated representation schemes have been proposed,often called semantic data models. Unfortunately, this more recent work is voluminous and difficultto understand: their terminology is mutually conflicting, the models are complex, and related workwas done concurrently by a number of authors. Furthermore, almost none of the models wereactually implemented. Related problems of data structure specification have also been addressedextensively in the programming language and artificial intelligence literature, as abstract data typemechanisms and knowledge representation languages. A survey of the literature is beyond thescope of this document. An annotated bibliography is included in the last section, however, andTsichritzis & Lochovsky [1982] summarize much of the recent data modelling work.The data model described herein is the result of analyzing the strengths and weakness of a numberof proposed models, and integrates a variety of viewpoints. It includes only those features that areaccepted in some form in a number of models, or proved particularly useful for our databaseapplications. We will call our model the Cypress data model. It might alternately be called theRelationship-Entity-Datum model, after its three basic primitives.The Cypress data model is described in Section 2. Sections 3 and 4 provide a description of theprogrammer's interface to our implementation, and an example of its use. Section 5 contrasts theCypress data model to others in the literature, and describes how we arrived at this particularintegration of data modelling ideas. Section 6 describes issues in the implementation of the Cypressdata model; as none of the models we reference have actually been implemented, this is animportant result of the work. To complete our description of the Cypress work, Section 7 coversexperience with database access tools and applications built upon the system. Sections 8 and 9provide a summary and annotated bibliography. An appendix of formal axioms for the model andan index of important terms are also included.For the sake of clean exposition, Section 2 covers only the abstract model, not its implementation orЪНHYОfЯpНЇО\TqТ─НЇОUЇrНЇОQшpТ s pПPТ⌡НЇОOїТ²Т·ПOНЇОMrТтТуs pП6НЇОK>Т⌡ПaНЇОI Т┤ПXТ┬НЇОF▌sТ─pНЇОB╡pТ╚Т╛ПOНЇО@~Т┤spТ┬П2НЇО>JТ▄ПRТ█НЇО<Т╨П!Т╩П9НЇО9АТ╟П/Т╠П1НЇО7╛Т╗П[Т╘ НЇО5xТиТйПDНЇО3CТ╙П2Т╚П.НЇО0хТ─ПPНЇО,МpТ▐ПHТ░НЇО*╦Т▓П\Т⌠НЇО(└Тл ТмПPНЇО&OТ╙П)Т╚П8НЇО#тТ─ПBНЇОЬpТєПYТ╔НЇОдТ÷П<Т═П%НЇО░ТйТкПCНЇО[Т┘ПYТ├НЇО'ТЮПYНЇОРТ╒П!ТёП?НЇОЎТ╪ПYТҐНЇО┴Т░ПSТ▒ НЇОТ─П.НЇО 3pТ┌ПKТ┐ бЇ Л=Г^ШDESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL2rationale. The reader interested only in the basic ideas may read about the data model in Section 2and about the applications it enables in Section 7, without loss of continuity. A potential client ofCypress should read Sections 2, 3, and 4.1.2 Cypress and CedarThe motivation for design and implementation of a database system in the Computer ScienceLaboratory arose from the needs of anticipated and existing database applications running in theCedar Programming Environment. The design of a data model was deferred to the second phase ofthe earlier Cedar Database Managment System (DBMS) project to allow a choice of model aftersome experience with our needs. With the second phase of development, the name of the CedarDBMS was changed to Cypress, to distinguish it from the Cedar DBMS which it replaced, theCedar Programming Environment in which it provides database facilities, and the Cedar MesaProgramming Language in which it is written.The original Cedar DBMS, described by Brown, Cattell, and Suzuki [1980], implemented tupleswhose elements are integers, strings, and references to other tuples. It provides a large virtualmemory of tuples which can be moved or deleted safely, optional B-trees for indexing of tuples, andconcurrent transaction-based access to data over a network. It was built in three levels: the Cache,Storage, and Tuple Levels. The latter (top) level provides primitive query mechanisms, and doeslittle or no checking of the integrity of data type, form, uniqueness, or referents; the addition of theModel Level introduces types to the essentially typeless underlying system. Initial clients of the Cedar DBMS included:1.The CSL Notebook, a database of memoranda from laboratory members,2.PDB, a personal database including notes, bibliographies, addresses, phone numbers, etc.,3.A database of components of large Mesa (Mitchell et al [1976]) systems and their inter-dependencies,4.A database of Mesa source programs decomposed to the level of procedures, types, andvariables,5.A database of data and events in an automated office system.Most of these applications built their own data model on top of the existing system, to enable thedata structures and access mechanisms they required. In some cases, building on top as opposed toЪНvОfЯptТF ptpt ptptpТXtТFptНMpНЇО_Т├П!Т┤ПCНЇО\АТ∙ПRТ√НЇОZfТ─П)НЇОSиrНЇОOМpТжП1ТвП(НЇОM╧Т╠ПQТ╡НЇОK└Т└П>Т┘НЇОIPТ╞П=Т╟НЇОGТ╒П%ТёП7НЇОDГТюП=ТаНЇОB╡ТтПOТу НЇО@7Т─П,НЇО<\pТиП"ТйП9НЇО:'ТлПbНЇО7СТ├Т┤ПMНЇО5ЎТ▐П+Т░П;НЇО3┼Т╞П;Т╟П%НЇО1UТ▄П4Т█П4НЇО.зТ─ПKН=OpТНЇО*╦Т─П+Н О&√pН`ПBН О"spН`ПYН О≤pН`ТьТыП?Н`ОН ОApН`Тш ТэПJН`Оф Н ОєpН`Т─П<НЇО хpТ║ПTТ╒ НЇО⌠Т▒ПTТ▓ &ML>Q\©УINTRODUCTION3integrating the data model with the existing system (an option not available to them) led todifficulties with the performance or integrity of the total system. This is not surprising, even thoughthe original system was designed to allow several data modelling choices at a future date; the choiceof data model must influence the choices at all levels of the system, if adequate performance is to beobtained.The addition of a data model to the database system makes possible the development of general-purpose tools. The more data semantics encoded in the database, the more the database system andits associated tools may provide without specific knowledge of an application's semantics. In orderto print out data in a meaningful form, for example, a tool must know which data comprise namesfor objects. In order to abbreviate and/or check the type of input data, a tool must know whattypes of data may be related to what others in what ways. In order to efficiently representpotentially circular pointer structures linearly, a tool needs a specification of allowed datarelationships. And so on.The introduction of a data model also simplifies sharing a single database among multipleapplications. A hierarchy of types allows different applications to have differing perspectives on thesame objects. The logical integrity checks help protect the applications from one another. Moresophisticated data modelling mechanisms allow applications different independent views of the dataor different physical environments (files) for their data. Sharing a database between applications isimportant to avoid redundant, inconsistent representation of the same information, to mutuallybenefit from multiple data input sources, and, most importantly, to present one simple data accessand manipulation mechanism to computer users. This contrasts, for instance, to three separatepersonnel databases (and access tools) for applications dealing with phone numbers, electronic mail,and laboratory bibliographies. Finally, the introduction of the Model Level data model is important to future plans for the nextlevel of the Cypress DBMS, the Query Level. At the Query Level, a database query language willbe implemented to allow access and/or updates to individual data items or data aggregates, in aconcise form amenable to optimization and decoupled operation in a database server on a computernetwork. The Model Level provides the functions to enumerate the database objects satisfying thequeries parsed by the Query Level.In summary, the development of the Model Level of the Cypress DBMS is a follow-on to the Cache,Storage, and Tuple Levels, a prerequisite of the Query Level, and motivated by:1.the perceived needs of, or shortcomings for, future and existing database applications,2.facilitation of shared databases for partial or complete integration of multiple applications,ЪН%└ОfЯpt НHYpНЇО_ТГТХПBНЇО\АТ┬ПLТ┴НЇОZґТ▄ПKТ█НЇОXxТ┐П9Т└П-НЇОUЩНЇОR"pТґПRТўНЇОOМТ┴П'Т┼П:НЇОM╧Т°П;Т²П)НЇОK└Т√Т≈ПNНЇОIPТ╠Т╡ПSНЇОGТЮП\НЇОDГТПQТНЇОBlТ─НЇО>░pТПPТ НЇО<\Т▌ПDТ▐П#НЇО:'Т╞П8Т╟П)НЇО7СТ⌡П]Т°НЇО5ЎТ≥ПCТ П#НЇО3┼ТщПUТчНЇО1UТєПKТ╔НЇО/!ТяПOТрНЇО,МТ√П?Т≈П%НЇО*rТ─Н$┐pТНЇО&√Т╘ПTТ╙НЇО$aТ≤Т≥ПEНЇО"-Т╧П-Т╨П2НЇОЬТ▐ПWТ░НЇОдТ·П]Т÷НЇОIТ─П"НЇОmpТ│П_НЇОРТ─ПOН ОпpН`ПWН ОўpН`П^ЪNЇg>Q[єDESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL43.the need for more data semantics to enable useful database utilities, e.g. a browser, and4.the need for a query language for database access. 1.3 Design criteria and motivationHow do we choose a data model? Why should one data model be better than another? In mostcases we can find a representational isomorphism between two models, such that we canautomatically map between the two equivalent representation schemes. However, the models maystill differ in the data access primitives they provide and the ease with which a user can understandand operate within the model. The arguments concerning ease of understanding are generally quitesubjective, however, and will be avoided here except where these arguments are generally well-accepted in the literature.The choices in the development of the Cypress Data Model were made on the basis of two criteria:simplicity and utility. Simplicity means ease of understanding and also representational parsimony,i.e., avoiding two or more mechanisms to represent the same semantics. Utility means the degree towhich the data model avoids writing application-specific code for some function or integrity check;every feature need not be of use to all applications, though the feature should be of negligible costto those that do not require it.Simplicity and utility can of course be mutually conflicting; the result must be a balanceincorporating the features deemed important for most applications, in the simplest form discovered.To make the presentation less confusing, we separate the discussion of the model itself in thesections to follow from the analysis of the simplicity and utility of its features in Section 5 and thediscussion of its implementation in Section 6.ЪНvОfЯptТF ptpt ptptpТXtТFptНMpН О^оН`Т─ПYН ОZґpН`П2Н.qpТНЇОTrТ─П"НЇОP4pТ·ПCТ÷НЇОMЪТП<ТНЇОKкТ═Т║ПDНЇОI√Т▀П?Т▄П&НЇОGbТ┬П<Т┴П%НЇОE-ТбПNТцНЇОB╡Т─НЇО>вpТ▐П%Т░П;НЇО<╒s pТ║spТ╒ПAНЇО:nТ┼П;Т▀П(НЇО89Т²П=Т·П&НЇО6Т∙П$spТ√П>НЇО3┼Т─НЇО/ўpТПAТНЇО-zТ≤ПEТ≥НЇО+EТтП^НЇО)Т≤Т≥ПPНЇО&√Т─П.M&O?QA╪д52. Cypress data model conceptsIn this section, we give an informal description of the Cypress data model. The evaluation andjustification of the model have been deferred to Section 5. A more formal description of the modelhas been deferred to a future paper (some axioms can be found in the appendix). 2.1 Data independenceWe deal here with the conceptual data model, the logical primitives for data access and data typedefinition. This should be carefully distinguished from the physical data model, the mechanisms weare given for actual storage and access of data. The physical model in the Cypress implementation correspondsto the Storage level. The physical data model is hidden as much as possible from the database client tofacilitate data independence, the guarantee that a user's program will continue to work (perhaps witha change in efficiency) even though the physical data representation is redesigned. For any particular database using the given conceptual and physical models, the actual specificationsof this database using the primitives the models provide are termed the conceptual data schema andphysical data schema. Note that a mapping must be provided between the conceptual and physicallevels, either automatically or with further instruction from the client; we will do some of both.The logical to physical mapping is intimately associated with the performance of the databasesystem as viewed by the user performing operations at the conceptual level. Performance isgenerally not a criteria for choosing between conceptual data models, unless there is no known wayto map the differing conceptual views into the same or equally efficient implementations.2.2 Basic primitivesThree basic primitives are defined in the model: an entity, datum, and relationship.An entity represents an abstract or concrete object in the world: a person, an organization, adocument, a product, an event. In programming languages and knowledge representation entitieshave variously been referred to as atoms, symbols, and nodes. A datum, unlike an entity, representsliteral information such as times, weights, part names, or phone numbers. Character strings andintegers are possible datum types.It is a policy decision whether something is represented as an entity or merely a datum: e.g., anemployee's spouse may be represented in a database system as a datum (the spouse's name), or thespouse may be an entity in itself. The database system provides a higher level of logical integritychecking for entities than for datum values, as we will see later: unique entity identifiers, checks onН<╒О\∙pНОTsqТ─НОP≈pТЁПPТЄНОNcТ┘П-Т├П6НОKХТ─ПOН4pТНОEKrТ─НОAopТїspТ╗П)НО?:Т▀П=spТ▄ НО=Т├П'Т┤tП>НО:яТ┌pПPТ┐НО8²Т┤ spТ┬П,НО6"Т─ПSН4pТНО2FТ┬П6Т┴ spНО0Т▀П%Т▄П#spНО-щsТ░Т▒pПKНО+╘ТЇПbНО)tТжП8ТвП%НО'@ТАПLТБНО%Т█ПXТ▌ НО"▒Т─ПYНОСrНОяpП5s pspНОУpТхПAТиНОаТ╗П<Т╘П"НО▄Т│П)Т┌П;НО XТ╡ТЁПEНО щТ─П"НОpТіspПSНОмТ▐ПDТ░НО≤Т° Т²ПZНОdТ┐Пh .Ї \>Г]╞ЫDESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL6entity types, and removal of dependent data upon entity deletion. We shall discuss theentity/datum choice further in Section 4.2.We will use the term value to refer to something that can be either a datum or an entity. In manyprogramming languages, there is no reason to distinguish entity values from datum values. Indeed,most of the Cypress operations deal with any kind of value, and some make it transparent to thecaller whether an entity or datum value is involved. The transparent case makes Relationaloperations possible in our model, as we will see in Section 2.5.A relationship is a tuple whose elements are [entity or datum] values. We refer to the elements(fields) of relationships by name instead of position. These names for positions are called attributes.Note that we have separated the representatives of unique objects (entities) from the representationof information about objects (relationships), unlike some object-oriented programming languagesand data models. Therefore an entity is not an "object" (or "record") in the programming languagesense, although entities are representatives of real-world objects. We discuss the advantages of theentity-relationship distinction along with other data model design issues in Section 5. We also define entity types, datum types, and relationship types. These are called domains,datatypes, and relations, respectively. We make use of these three types through one fundamentaltype constraint: every relationship in a relation has the same attributes, and the values associatedwith each attribute must be from a pre-specified domain or datatype. One might think of a relationas a "record type" in a programming language, although relations permit more powerful operationsthan record types.As an example, consider a member relation that specifies that a given person is a member of a givenorganization with a given job title, as in the following figure. The person and organization might beentities, while the title might be a string datum. We relax the fundamental type constraintsomewhat in allowing a lattice of types of domains: a particular value may then belong to the pre-specified domain or one of its sub-domains. For example, one could be a member of a University,a Company, or any other type of Organization one chooses to define. Other relations, e.g. an"offers-course" relation, might apply only to a University.<==BBpBЖяю╪-.═CЯЪ@CtlҐJ╩█e╪▀⌠CР╨)+z╨їRD@╙┬╩░:p╪═в Cг©`╪ю╪3ХҐіdDs?Cл─╪─c`ТEufdDВФpCгю╪0tҐ┼┬юCШ┬─CC╪6ю╩▓≤╪╪Т@CШ┬─╨?═╩9▓ЭCю|■╪+5чҐ╞О ҐЄy░╪─╪▀■BЙ╦Dr⌡Ctlю╪GbpEdН\Dm█"CP▌п╪∙лaҐЄ╠Ю@Bе@CЧА─Bц░╪u─╩≤eҐҐ▓CСЧClD╪╨h╩█П╪⌠╪─CСЧ─╪іҐ,BЫ"BPЮҐ;>Ґ╒╪%}─╪%~╪╔Dq#Cз┌╪%|─-d CZBтCW2ҐЎЎПD@╩ю╩═D@╪═CQ2Ў═@ҐЎЎ/П╪╪⌠╪CE≤DrClC─╪─-RdC`CQ2Ґ+ЬҐЎAПЗCСЧ╪⌠ю╩²h╪"ClC─CСЧ─╪іBтCK2Ґ7ВЧҐЎAп╩юD@D`╩ю-▐d CZҐ,BА"Ґ░Ґ3>BmПCз┌─╪%~╩▌щ@╪╔|Cз┌Cз┐─╪╦CHBу"Ґ░Ґ;>B]П╪Cl@Db≤CВч╪⌠╪─╪─-аcФCH╪╦BhХ╪ҐpҐ▓BлюClB╪╩█ЯCE■CСЧClGҐ,CZBPХҐЮҐ╒Bдю╪%}─Cз┌Dq"юCZ└╪%~╪%|─-ДcЄBт╪і╪╗лЎПBПD╩ю╩═D@D@C`Ў═0╪ўлЎ/ПBХCЪ╪⌠ЎCСЧDr╪╨l╪╪⌠╧-Рcw╪═Ґ+З╪ўлAПBПD╪⌠Ў╪╪$Db≥CСЧ╪⌠╧BтCZҐ7З╪ЄлAпBХDD@D`╩ю╩ю-Дc:Ґ,╪іҐ▄ҐЮBmПBлю╪%}─╪%~╪╔Dq#Cз┌╪%|─CHCHҐ▄Ґ*ЮB]ПBдюClBCСЧCВэ╩²g╪ClG-аc╪╦╪╦╪ҐoҐ≈ BлбBmП╪╪⌠╪CE≤DrClC─╪─CZBтҐчҐ╞ BдбB]ПCз┌─Cз┌CZ│╩▌щ╪%~Cз┐─-▐bЕ╪іҐ,╪╗нBПBAП╩юD@D`╩юC`╪ўнA_юBХBAпCСЧClD╪╨h╩█П╪⌠╪─CСЧ─-Rbв╪═╪ўнBтBПBЎП╪Cl@Db≤CВч╪⌠╪─╪─CZҐ,╪ЄнBхBХBЎ/ПD@╩ю╩═D@-bЕ╪іBтҐчBПpBлбҐ▓╪%}─Cз┌Dq"юCZ└╪%~╪%|─CH╪╦Ґ*чBДpBдбҐ╒CСЧ╪⌠ю╩²h╪"ClC─CСЧ─,Цc╪╦CHҐ≈CB░BmПҐ3?Ъ╪⌠ЎCСЧDr╪╨l╪╪⌠╧Bт╪іҐ╞BЫЧB]ПҐ;@Cз┌─╪%~╩▌щ@╪╔|Cз┌Cз┐─,юc:Ґ,CZCW4AПҐ╩ЧD@D`╩ю╩ю╪═A_пCQ3ЧAпҐ╪ClB╪╩█ЯCE■CСЧClGJohn SmithЪ]яEо∙ҐEu╘Bk@BBpBЖяю╪-.═CЯЪCtlҐL╩█e╪▀▓─CР╨)+z╨їRD@╙┬╩░:p╪═в Cг©`╪ю╪3ХҐіdDs?Cл`╪─#a4EufdDВФpCгю╪0tҐ┼┬юCШ┬─CC╪6ю╩▓≤╪╪Т@CШ┬─╨?═╩9▓ЭCю|■╪+5чҐ╞О ҐЄy░╪─╪▀■BЙ╦Dr⌡Ctlю╪"b╟EdН\Dm█"CP▌п╪∙лaҐЄ╠Ю@Bе@CЧА─Bц░╪u─╩≤eҐҐ▓CСЧClD╪╨h╩█П╪⌠╪─CСЧ─╪іҐ,BЫ"BPЮҐ;>Ґ╒╪%}─╪%~╪╔Dq#Cз┌╪%|─&ud)CZBтCW2ҐЎЎПD@╩ю╩═D@╪═CQ2Ў═@ҐЎЎ/П╪╪⌠╪CE≤DrClC─╪─&╡d7C`CQ2Ґ+ЬҐЎAПЗCСЧ╪⌠ю╩²h╪"ClC─CСЧ─╪іBтCK2Ґ7ВЧҐЎAп╩юD@D`╩ю&Оd)CZҐ,BА"Ґ░Ґ3>BmПCз┌─╪%~╩▌щ@╪╔|Cз┌Cз┐─╪╦CHBу"Ґ░Ґ;>B]П╪Cl@Db≤CВч╪⌠╪─╪─'!dCH╪╦BhХ╪ҐpҐ▓BлюClB╪╩█ЯCE■CСЧClGҐ,CZBPХҐЮҐ╒Bдю╪%}─Cз┌Dq"юCZ└╪%~╪%|─'DcтBт╪і╪╗лЎПBПD╩ю╩═D@D@C`Ў═0╪ўлЎ/ПBХCЪ╪⌠ЎCСЧDr╪╨l╪╪⌠╧'Rc≈╪═Ґ+З╪ўлAПBПD╪⌠Ў╪╪$Db≥CСЧ╪⌠╧BтCZҐ7З╪ЄлAпBХDD@D`╩ю╩ю'DcZҐ,╪іҐ▄ҐЮBmПBлю╪%}─╪%~╪╔Dq#Cз┌╪%|─CHCHҐ▄Ґ*ЮB]ПBдюClBCСЧCВэ╩²g╪ClG'!c(╪╦╪╦╪ҐoҐ≈ BлбBmП╪╪⌠╪CE≤DrClC─╪─CZBтҐчҐ╞ BдбB]ПCз┌─Cз┌CZ│╩▌щ╪%~Cз┐─&Оc╪іҐ,╪╗нBПBAП╩юD@D`╩юC`╪ўнA_юBХBAпCСЧClD╪╨h╩█П╪⌠╪─CСЧ─&╡bВ╪═╪ўнBтBПBЎП╪Cl@Db≤CВч╪⌠╪─╪─CZҐ,╪ЄнBхBХBЎ/ПD@╩ю╩═D@&uc╪іBтҐчBПpBлбҐ▓╪%}─Cз┌Dq"юCZ└╪%~╪%|─CH╪╦Ґ*чBДpBдбҐ╒CСЧ╪⌠ю╩²h╪"ClC─CСЧ─&Cc(╪╦CHҐ≈CB░BmПҐ3?Ъ╪⌠ЎCСЧDr╪╨l╪╪⌠╧Bт╪іҐ╞BЫЧB]ПҐ;@Cз┌─╪%~╩▌щ@╪╔|Cз┌Cз┐─& cZҐ,CZCW4AПҐ╩ЧD@D`╩ю╩ю╪═A_пCQ3ЧAпҐ╪ClB╪╩█ЯCE■CСЧClG0╡aвD`D`╪@╪@D`╩═╪@Cю╩═╩═CюCю╩═D`Cю╪@0▓aвC`BтCQ4ЎПҐ╪Cl@CСЧCВч╩²g╪ClGҐ,╪іBхCK4Ў/ПҐ╪╩ю╩═D@D@0═bBтCZBПpBА Ґ▓Ґ3@Cз┐Cз┌CZ─╩▌щ╪%~Cз┐─╪╦╪╦BДpBу Ґ╒Ґ;@╪⌠ю╪╪"Db≥CСЪ╪⌠╧0цbFCHCHCB▓BhЮҐ3>Ґ▓CСЧClD╪╨h╩█П╪⌠╪─CСЧ─╪іҐ,BЫ$BPЮҐ;>Ґ╒╪%}╪%~╪╔─Dq#Cз┌╪%|─0УbiCZBтCW2ҐЎЎПD@╩ю╩═D@╪═CQ2Ў═@ҐЎЎ/П╪╪⌠╪CE≤DrClC─╪─12bwC`CQ2Ґ+ЬҐЎAПЗCСЧ╪⌠ю╩²h╪"ClC─CСЧ─╪іBтCK2Ґ7ВЧҐЎAп╩юD@D`╩ю1obiCZҐ,BА$Ґ░Ґ3>BmПCз┌╪%~╩▌щ─╪╔|Cз┌Cз┐─╪╦CHBу$Ґ░Ґ;>B]П╪Cl@Db≤CВч╪⌠╪─╪─1║bFCH╪╦BhЮ╪ҐpҐ▓BлюClD╪╩█ПCE■CСЪClGҐ,CZBPЮҐЮҐ╒Bдю╪%~Cз┌Dq"─CZ└╪%~╪%|─1дbBт╪і╪╗лЎПBПD╩ю╩═D@D@C`Ў═@╪ўлЎ/ПBХCЪ╪⌠╪CСЧDr╪╨l╪╪⌠╧1рaв╪═Ґ+Ь╪ўлAПBПD╪⌠ю╪╪"Db≥CСЪ╪⌠╧BтCZҐ7Ь╪ЄлAпBХDD@D`╩ю╩ю1дa Ґ,╪іҐ░ҐЮBmПBлю╪%}╪%~╪╔─Dq#Cз┌╪%|─CHCHҐ░Ґ*ЮB]ПBдюCl@CСЧCВч╩²g╪ClG1║ah╪╦╪╦╪ҐnҐ≈ BлбBmП╪╪⌠╪CE≤DrClC─╪─CZBтҐэҐ╞ BдбB]ПCз┐Cз┌CZ─╩▌щ╪%~Cз┐─1oaE╪іҐ,╪╗нBПBAП╩юD@D`╩юC`╪ўнA_юBХBAпCСЧClD╪╨h╩█П╪⌠╪─CСЧ─12a7╪═╪ўнBтBПBЎП╪Cl@Db≤CВч╪⌠╪─╪─CZҐ,╪ЄнBхBХBЎ/ПD@╩ю╩═D@0УaE╪іBтҐэBПpBлбҐ▓╪%~Cз┌Dq"─CZ└╪%~╪%|─CH╪╦Ґ*эBДpBдбҐ╒CСЧ╪⌠ю╩²h╪"ClC─CСЧ─0цah╪╦CHҐ≈ CB░BmПҐ3?Ъ╪⌠╪CСЧDr╪╨l╪╪⌠╧Bт╪іҐ╞ BЫЧB]ПҐ;@Cз┌╪%~╩▌щ─╪╔|Cз┌Cз┐─0═a Ґ,CZCW4AПҐ╩ЧD@D`╩ю╩ю╪═A_юCQ3ЧAпҐ╪ClD╪╩█ПCE■CСЪClGJohnMaryJohnTom#р[ВD`D`╪@╪@D`╩═╪@Cю╩═╩═CюCю╩═D`Cю╪@#╡[ВC`BтCQ4ЎПҐ╪ClBCСЧCВэ╩²g╪ClGҐ,╪іBхCK4Ў/ПҐ╪╩ю╩═D@D@#ю\4BтCZBПrBА Ґ▓Ґ3@Cз┌─Cз┌CZ┐╩▌щ╪%} Cз┐─╪╦╪╦BДrBу Ґ╒Ґ;@╪⌠Ў╪╪$Db≥CСЧ╪⌠╧#Ц\fCHCHCB▓BhЮҐ3=Ґ▓CСЧClD╪╨g╩█П╪⌠ЎCСЧ─╪іҐ,BЫ$BPЮҐ;=Ґ╒╪%}─╪%~╪╔}Dq#Cз┌Ю╪%|─$\┴CZBтCW2ҐЎЎПD@╩ю╩═D@╪═CQ2Ў═@ҐЎЎ/П╪╪⌠╪CE≥DrClB╪─$R\≈C`CQ2Ґ+ЬҐЎAПЗCСЩ─╪⌠ю╩²h─╪"ClBCСЧ─╪іBтCK2Ґ7ВЧҐЎAп╩юD@D`╩ю$▐\┴CZҐ,BА$Ґ░Ґ3=BmПCз┌─╪%~╩▌эю╪╔|Cз┌ЮCз┐─╪╦CHBу$Ґ░Ґ;=B]П╪─Cl@Db≈─CВч╪⌠Ў╪─$а\fCH╪╦BhД╪ҐpҐ▓BлюClB╪╩█ЯCE■CСЧClGҐ,CZBPДҐЮҐ╒Bдю╪%}─Cз┌Dq#@CZ└╪%} ╪%|─$Д\4Bт╪і╪╗лЎПBПD╩ю╩═D@D@C`Ў═0╪ўлЎ/ПBХCЪ╪⌠ЎCСЧDr╪╨l╪╪⌠╧$Р[В╪═Ґ+З╪ўлAПBПD╪⌠Ў╪╪$Db≥CСЧ╪⌠╧BтCZҐ7З╪ЄлAпBХDD@D`╩ю╩ю$Д[╨Ґ,╪іҐ▌ҐЮBmНBлю╪%}─╪%~╪╔}Dq#Cз┌Ю╪%|─CHCHҐ▌Ґ*ЮB]НBдюClBCСЧCВэ╩²g╪ClG$а[┬╪╦╪╦╪ҐnҐ≈ BлцBmП╪╪⌠╪CE≥DrClB╪─CZBтҐэҐ╞ BдцB]ПCз┌─Cз┌CZ┐╩▌щ╪%} Cз┐─$▐[e╪іҐ,╪╗нBПBAП╩юD@D`╩юC`╪ўнA_юBХBAпCСЧClD╪╨g╩█П╪⌠ЎCСЧ─$R[W╪═╪ўнBтBПBЎП╪─Cl@Db≈─CВч╪⌠Ў╪─CZҐ,╪ЄнBхBХBЎ/ПD@╩ю╩═D@$[e╪іBтҐэBПpBлцҐ▓╪%}─Cз┌Dq#@CZ└╪%} ╪%|─CH╪╦Ґ*эBДpBдцҐ╒CСЩ─╪⌠ю╩²h─╪"ClBCСЧ─#Ц[┬╪╦CHҐ≈CB░BmНҐ3?Ъ╪⌠ЎCСЧDr╪╨l╪╪⌠╧Bт╪іҐ╞BЫЧB]НҐ;@Cз┌─╪%~╩▌эю╪╔|Cз┌ЮCз┐─#ю[╨Ґ,CZCW4AПҐ╩ЧD@D`╩ю╩ю╪═A_пCQ3ЧAпҐ╪ClB╪╩█ЯCE■CСЧClG-r\D`D`╪@╪@D`╩═╪@Cю╩═╩═CюCю╩═D`Cю╪@-R\C`BтCQ4ЎПҐ╪ClBCСЧCВэ╩²g╪ClGҐ,╪іBхCK4Ў/ПҐ╪╩ю╩═D@D@-`\TBтCZBПtBА Ґ▓Ґ3@Cз┌─Cз┌CZ│╩▌щ╪%~Cз┐─╪╦╪╦BДtBу Ґ╒Ґ;@╪⌠Ў╪╪$Db≥CСЧ╪⌠╧-┐\├CHCHCB▒BhЮҐ3>Ґ▓CСЧClD╪╨h╩█П╪⌠╪─CСЧ─╪іҐ,BЫ"BPЮҐ;>Ґ╒╪%}─╪%~╪╔Dq#Cз┌╪%|─-╣\╘CZBтCW2ҐЎЎПD@╩ю╩═D@╪═CQ2Ў═@ҐЎЎ/П╪╪⌠╪CE≤DrClC─╪─-Р\ЇC`CQ2Ґ+ЬҐЎAПЗCСЧ╪⌠ю╩²h╪"ClC─CСЧ─╪іBтCK2Ґ7ВЧҐЎAп╩юD@D`╩ю./\╘CZҐ,BА"Ґ░Ґ3>BmПCз┌─╪%~╩▌щ@╪╔|Cз┌Cз┐─╪╦CHBу"Ґ░Ґ;>B]П╪Cl@Db≤CВч╪⌠╪─╪─.a\├CH╪╦BhХ╪ҐpҐ▓BлюClB╪╩█ЯCE■CСЧClGҐ,CZBPХҐЮҐ╒Bдю╪%}─Cз┌Dq"юCZ└╪%~╪%|─.└\TBт╪і╪╗лЎПBПD╩ю╩═D@D@C`Ў═0╪ўлЎ/ПBХCЪ╪⌠ЎCСЧDr╪╨l╪╪⌠╧.▓\╪═Ґ+З╪ўлAПBПD╪⌠Ў╪╪$Db≥CСЧ╪⌠╧BтCZҐ7З╪ЄлAпBХDD@D`╩ю╩ю.└[зҐ,╪іҐ▄ҐЮBmПBлю╪%}─╪%~╪╔Dq#Cз┌╪%|─CHCHҐ▄Ґ*ЮB]ПBдюClBCСЧCВэ╩²g╪ClG.a[╗╪╦╪╦╪ҐoҐ≈ BлбBmП╪╪⌠╪CE≤DrClC─╪─CZBтҐчҐ╞ BдбB]ПCз┌─Cз┌CZ│╩▌щ╪%~Cз┐─./[┘╪іҐ,╪╗нBПBAП╩юD@D`╩юC`╪ўнA_юBХBAпCСЧClD╪╨h╩█П╪⌠╪─CСЧ─-Р[w╪═╪ўнBтBПBЎП╪Cl@Db≤CВч╪⌠╪─╪─CZҐ,╪ЄнBхBХBЎ/ПD@╩ю╩═D@-╣[┘╪іBтҐчBПpBлбҐ▓╪%}─Cз┌Dq"юCZ└╪%~╪%|─CH╪╦Ґ*чBДpBдбҐ╒CСЧ╪⌠ю╩²h╪"ClC─CСЧ─-┐[╗╪╦CHҐ≈CB░BmПҐ3?Ъ╪⌠ЎCСЧDr╪╨l╪╪⌠╧Bт╪іҐ╞BЫЧB]ПҐ;@Cз┌─╪%~╩▌щ@╪╔|Cз┌Cз┐─-`[зҐ,CZCW4AПҐ╩ЧD@D`╩ю╩ю╪═A_пCQ3ЧAпҐ╪ClB╪╩█ЯCE■CСЧClG7Р[ВD`D`╪@╪@D`╩═╪@Cю╩═╩═CюCю╩═D`Cю╪@7р[ВC`BтCQ4ЎПҐ╪Cl@CСЧCВч╩²g╪ClGҐ,╪іBхCK4Ў/ПҐ╪╩ю╩═D@D@7Ю\4BтCZBПpBА Ґ▓Ґ3@Cз┐Cз┌CZ─╩▌щ╪%~Cз┐─╪╦╪╦BДpBу Ґ╒Ґ;@╪⌠ю╪╪"Db≥CСЪ╪⌠╧8\fCHCHCB▓BhЮҐ3>Ґ▓CСЧClD╪╨h╩█П╪⌠╪─CСЧ─╪іҐ,BЫ$BPЮҐ;>Ґ╒╪%}╪%~╪╔─Dq#Cз┌╪%|─85\┴CZBтCW2ҐЎЎПD@╩ю╩═D@╪═CQ2Ў═@ҐЎЎ/П╪╪⌠╪CE≤DrClC─╪─8r\≈C`CQ2Ґ+ЬҐЎAПЗCСЧ╪⌠ю╩²h╪"ClC─CСЧ─╪іBтCK2Ґ7ВЧҐЎAп╩юD@D`╩ю8╞\┴CZҐ,BА$Ґ░Ґ3>BmПCз┌╪%~╩▌щ─╪╔|Cз┌Cз┐─╪╦CHBу$Ґ░Ґ;>B]П╪Cl@Db≤CВч╪⌠╪─╪─8А\fCH╪╦BhЮ╪ҐpҐ▓BлюClD╪╩█ПCE■CСЪClGҐ,CZBPЮҐЮҐ╒Bдю╪%~Cз┌Dq"─CZ└╪%~╪%|─9\4Bт╪і╪╗лЎПBПD╩ю╩═D@D@C`Ў═@╪ўлЎ/ПBХCЪ╪⌠╪CСЧDr╪╨l╪╪⌠╧9[В╪═Ґ+Ь╪ўлAПBПD╪⌠ю╪╪"Db≥CСЪ╪⌠╧BтCZҐ7Ь╪ЄлAпBХDD@D`╩ю╩ю9[╨Ґ,╪іҐ░ҐЮBmПBлю╪%}╪%~╪╔─Dq#Cз┌╪%|─CHCHҐ░Ґ*ЮB]ПBдюCl@CСЧCВч╩²g╪ClG8А[┬╪╦╪╦╪ҐnҐ≈ BлбBmП╪╪⌠╪CE≤DrClC─╪─CZBтҐэҐ╞ BдбB]ПCз┐Cз┌CZ─╩▌щ╪%~Cз┐─8╞[e╪іҐ,╪╗нBПBAП╩юD@D`╩юC`╪ўнA_юBХBAпCСЧClD╪╨h╩█П╪⌠╪─CСЧ─8r[W╪═╪ўнBтBПBЎП╪Cl@Db≤CВч╪⌠╪─╪─CZҐ,╪ЄнBхBХBЎ/ПD@╩ю╩═D@85[e╪іBтҐэBПpBлбҐ▓╪%~Cз┌Dq"─CZ└╪%~╪%|─CH╪╦Ґ*эBДpBдбҐ╒CСЧ╪⌠ю╩²h╪"ClC─CСЧ─8[┬╪╦CHҐ≈ CB░BmПҐ3?Ъ╪⌠╪CСЧDr╪╨l╪╪⌠╧Bт╪іҐ╞ BЫЧB]ПҐ;@Cз┌╪%~╩▌щ─╪╔|Cз┌Cз┐─7Ю[╨Ґ,CZCW4AПҐ╩ЧD@D`╩ю╩ю╪═A_юCQ3ЧAпҐ╪ClD╪╩█ПCE■CСЪClG&pc+╩ібч╩OHЎ▀─@ҐЎЮ0Ґї>Ba├п╪▄ю╪ Є╪.─Dd^CРK─╪▄юDm┘╪DЛ·▓╪ї∙√Ba$═B≥Х©*и─C]├CВ&DAЭ╩║Z╪ьюC]┬%╞ai╩▐A═╩/≤╪╡+эBШ@CS└єҐPH╪╔|╪F╩╪тюD]нCВ╩╪╔}DYЇDУЎсCч┐d╪╦▄╪║²\Bю7╦Cs@CРLCЯр╩⌡╒╪ ЄCs@$п_╛╪з╡╩=д╙CC%┬AцuюЎ34═Ґё/ЮҐ-д╪╙╩╚├юDN∙CЧV`Ґ-йC^мPDхс+BТW┬AГu©M─Ґ≈0 CZ└CВ╨DC+@╩╒2╪ECZ┐$┴^⌡╪ІCч╩▌Ї└B~tAцw═©!0°Ў вЮЎ,≤╪╩╒╞─DCзCЪЕЎ,╦BNGdDx еBm<╟Aт?@Ґ©тBр<CЧVDTy@╩╠k╪╘═Bр6$r]ІҐёШ~╩9pBе?bЎ╔╡─Ў#Wz©─▓AQ╪╩·ююCЭ.CЪЫ═AQЎ#Ш┌Dх╦ AэЮAш`├Ў юAсhCЪДD]P─╩╪&╪AсH&ИcNEd▓i╨°I4@oЭ©░Ў-|©Cы╨╪$╦╩▌╛@╪╘`CшI@Cы╩─╨²$яEd▓hҐ≥1юЎ1─AхA[Т─╪%Cз Dq ─C\p╪%Юю╪%─* `-Emf·╨░ЁOҐ│5ҐЄр@Aоg@AnхCьh╪#n╩▌_╪╞ЛCэ▒юCьh╨■ЁOEpYї@zЧ©│ЎюЎ╩x╪&FCшHDqSюCV═╪$Ію╪&D─authorauthorauthorauthorR_Ї▓_ЇD@╩ю╩═D@R_w╩юD@D`╩юР_W$2_WD@╩ю╩═D@Р_╩юD@D`╩ю%Р^Ї*2^ЇD@╩ю╩═D@%Р^w╩юD@D`╩ю/r^W3╡^WD@╩ю╩═D@/r^╩юD@D`╩ю6╡_:Р_D@╩ю╩═D@6╡^в╩юD@D`╩юGeorgeBackgammon for BeginnersAdvanced Backgammon0Йab╩ЬН╨ЎAдBNLBmBЖWҐkp╪>Ў─╪Б╪─DhCН╪>╪─DуЯщEH┐┴CЖR╪ўО(╪╙╨tBG╧ CсqCАC|R╩░Д╪Н@Cсp/N_G╩"Ґё╨╠P≈DC╩X╪╒=Ю╪═k┬BOРю╪╙█╪X╩╨чD\`CЬ╗ю╪╙┴DzҐєEV╗LAЧ┤юBц≈ЮCJ~x╪ЎСPCаA─CНCЦК─╩≈Ъ╪БCаC─1Ґa∙EQЕФ╩┐:■By@Ў ═ ҐЕ0╪╪ъ╗CМт╪>@╩≈х╪CаҐCМр╨ЁклDш:∙ҐU╟╪J│Aя{@CVЄV╪bC[D]З─DBО╪єА─╪c─4B`rDХЫ█╩┌SъЎ╩╪=ЎьҐ°ЮЮBx▀PCчy╪)є╩▐Ч╪▒HCж\─Cч{╩#cфDт╘Ґ°П ╪їж,ҐЎ' ?х√╪,CаюDh8CБЭ╪>C╪.5т_DDo!Ю╩ hNЎ▀ўюҐ7p╪Ў4є╟Aч`CуЙ╪!╩█А─╪╪CчАюCуИ─╩⌡░ЗDnК╡Ў0MpҐ∙.┬Ў├═AUЫ@╪!├Cж\DpCnЄ╪)╒─╪!┤6╙^lDХ'H╩Ь°╪╘b≤╪І╦╗Bd─═BsАпCлу╪═╩▄м─Ґ≥CФ_юCлж╩$ёDЗ|NAыП─Ў Ґ/г╟Ў)°`╪*CчДDrCCТ╪!╪*─Н)О]"ptТF ptpt ptptpТXtТFptНpНjОUrТ─НjОQ$pТЁП*ТЄП7НjОNПТмП!spspТнspНjОL╩Т√П$Т≈ПBНjОJ┤Т╦П,Т╧П4НjОHSТ▄ПYspНjОEьТ─ПVНjОAЭpТ■ spП-Т∙П&НjО?гТ░ПaНjО=⌠Т╔spТіП@НjО;^ТкТлПGНjО9*Т┼П<Т▀П%НjО6╞Т─НjО&Ёp3НjО"вТ┼П+Т▀П5НjО ёТ┼ПVspТ▀НjОnТцТдПJНjО:ТєПXТ╔НjОТ▀П?Т▄П!НjОяТдП_НjОVТ─П$НjОzpТГП9ТХНjОЪТ─П\Н`О щpН8pТНjОТ╞П+Т╟П7НjОлТхПEТиНjО≤sТяpПCТр НjОdТ╒spП,spТёЪ dM о>Г^<ЭНРО[w$Ьx Ш7ЬШ7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7ЬxШ7ЬШ7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7НО_ВЬxШ7ЬШ7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7ЬxШ7ЬШ7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7НrОc≈НrО\WН/О[wН9рО[WЬx Ш7ЬШ7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7ЬxШ7ЬШ7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7ЬxШ7ЬШ7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Н О_≈Н%рО^вН/rО^wН6▓О_7Ш#Ш#Ш#Ш#Ш#Н%╡О[WН'╡ОdН2╡Оaв Ш7Ш7Ш7Ш7Ш7Ш7 d<╒ЧеуtuCYPRESS DATA MODEL CONCEPTS9name] that may be used to uniquely identify an internal entity. The three are interchangeable,however, since they must always be in one-to-one correspondence. The reader may find it simple to think of entity-valued attributes of relationships as pointers to theentities, in fact bi-directional pointers, since the operations we provide allow access in eitherdirection. This is a useful analogy. However, there is no constraint that the model be implementedwith pointers, and the relationships of a relation could equally well be conceptualized as rows of atable whose columns are the attributes of the relation and whose entries for entity-valued attributesare the string names of the entities. For example, the author relationships in the previous figurecould also be displayed in the form:Author:PersonBookGeorgeBackgammon for BeginnersJohnBackgammon for BeginnersJohnAdvanced BackgammonTomAdvanced BackgammonThus our introduction of entities to the Relational model does not entail a different representationthan, say, a Network model might imply, but simply additional integrity checks on entity names andtypes, and new operations upon entities. This compatibility with the Relational data model isimportant, as it allows the application of the powerful Relational calculus or algebra as a querylanguage. We return to query languages in Section 2.5.Note that the only information about an entity associated directly with the entity is the name; thiscontrasts with most other data models. A person's age or spouse, for example, would berepresented in the Cypress data model via age or spouse relations. Thus the relationships in adatabase are the information-carrying elements: entities do not have attributes. However the modelprovide an abbreviation, properties, to access information such as age or spouse in a singleoperation. We will discuss properties later. In addition, the physical data modelling algorithms canstore these data directly with the person entity as a result of the relation key information (since aperson can have only one age, a field can be allocated for that field in the stored objectrepresenting a person.)2.4 Basic operationsThe data model provides the capability to define and examine the data schema, and performoperations on entities, relationships, and aggregates of entities and relationships. In this section wediscuss the basic operations on entities and relationships. In Section 2.5, we discuss the operationsЪН+О\∙ptpТXtptptН<╒pНОT╨Т╪ПJТҐНОR?Т─П@Н*+pТНОNcТ▒Т▓ПAspНОL.ТГПBТХНОIЗТ┘ПdНОGфТ√Т≈ПRНОE▒Т░ Т▒ПZНОC]Т╗П&Т╘spП%НО@БТ─П$Н О=sН ┴О:zЧЪО:яpН╘О:zЧО:яН ∙О8²Н╘Н ∙О6iН╘Н ∙О44Н╘Н ∙О2Н╘НО.$Т Т⌡П'spП"НО+ОТ┌П'Т┐П;НО)╩ТмП.ТнП0НО'┤Т╧Т╨ПQНО%Т─П7НО!0pТ П'Т⌡spП"НОШТШ ТЭПIНОгТҐП7ТЎП(НО▓Т│ПRТ┌НО^ТТs pТУП"НО*Т┬ПWТ┴НОУТ═Т║ПGНОаТУП)ТЖП1НОFТ─НО╗rНОмpТвП&ТьП3НО≤Т⌠ПTТ■НОdТ√П[Т≈ ЎЇ \=Г]╞DESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL10on aggregate types, i.e. domains and relations. We defer to Section 2.6 the discussion of"convenience" operations built upon the basic and aggregate operations.Four basic operations are defined for entities:1.DeclareEntity[domain, name]: Returns a new or existing entity in a domain. An entityname must be specified.2.DestroyEntity[entity]: Destroys an entity; this also destroys all relationships that refer to it.3.DomainOf[entity]: Returns the domain of an entity (its type).4.NameOf[entity]: Returns the string name of an entity.Five basic operations are defined for relationships:1.DeclareRelationship[relation, list of attribute values]: Returns a relationship with thegiven attribute values in the given relation.2.DestroyRelationship[relationship]: Destroys a relationship.3.RelationOf[relationship]: Returns a relationship's relation.4.GetF[relationship, attribute]: Returns the value associated with the given attribute of thegiven relationship.5.SetF[relationship, attribute, value]: Sets the value of the given relationship attribute.The operations upon relationships recognize a specially-distinguished undefined value for anattribute. Unassigned attributes of a newly-created relationship have this value. A client of the datamodel may retrieve a value with GetF and test whether it equals the distinguished undefined value,and may set a previously defined value to be the distinguished undefined value with SetF.Other "convenience" operations are built on top of the basic operations on entities andrelationships: properties and translucent attributes. They are described in Section 2.6. Althoughthese operations are not essential to the basis of the Cypress model, they do furnish a fundamentallydifferent perspective on the model. They provide a mechanism to associate information directlywith entities (instead of through relationships) and to write programs largely independent ofattribute types.The reader will also note that we have ignored issues of concurrent access and protection in thebasic operations. We will see later that an underlying transaction, file, and protection is associatedwith the relation and domain handles used in the basic operations. This convenience allows us totreat concurrency, protection, and data location orthogonally.ЪН)ОZaptТF ptpt ptptpТXtТFptНpНjОR├ТЩП/ТЧП+НjОPТ─ПGНjОKХpП/НОH pН`uТ÷pupТ═П(Н`ОE▓Т─НОB┴pН`upТ┐upПCТ└НО?│Н`upТ─upП+НОЪ 8M░=Г[{CYPRESS DATA MODEL CONCEPTS112.5 Aggregate operationsThere are two kinds of operations upon domains and relations, the aggregate types in our model:the definition of domains and relations, and queries on domains and relations. We first discusstheir definitions.Schema definitionAs in other database models and a few programming languages, the Cypress model is self-representing: the data schema is stored and accessible as data. Thus application-independent toolscan be written without coded-in knowledge of the types of data and their relationships.Client-defined domains, relations, and attributes are represented by entities. These entities belong tospecial built-in domains, called the system domains:the Domain domain, with one element (entity) per domainthe Attribute domain, with one element per attributethe Relation domain, with one element per relationThere is also a predefined Datatype domain, with pre-defined elements StringType, BoolType, andIntType, called built-in types. An implementation may also allow client-defined datum types, but theimplementation described in Section 3 currently does not.There may be other system domains, depending upon the implementation of the Relationship-Entity-Datum model, for example to represent indices on relations. The Domain domain, Attributedomain, and all other domains are members of the Domain domain.Information about domains, relations, and attributes are represented by system relations in which thesystem entities participate. The pre-defined SubType relation is a binary relation between domainsand their subdomains. There are also predefined binary relations that map attributes to informationabout the attributes:aRelation: maps an attribute entity to its relation entity.aType: maps an attribute to its type entity (a domain or a built-in type)aUniqueness: maps an attribute entity to {TRUE, FALSE}, depending whether it is partof a key of its relation. We are assuming only one key per relation, here; our implementation relaxes thisassumption in the case of single-attribute keys. The following diagram graphically illustrates a segment of a data schema describing the memberrelation and several domains. The left side of the figure shows two subdomains of Organization,(Company and University), and the right shows the types and uniqueness properties of the memberrelation's attributes memberOf, memberIs, and memberAs.Н+ОYтptpТXtptptН;РpНОQЫrТ─НОNpТ╔ПBspТіНОKХТ╣П4ТІП,НОIЄТ─НОEьsНОBпpТЬП<ТЫНО@°Т≈Т≤ПMНО>gТ─ПWНО;_Т┘П"Т├ПFНО9+Т─П%spНИО6#upП&НИО3upНИО0upНО- Т├Т┤ uvupu suspНО*жupТ s pТtПDНО(║Т─П9НО%≥pТ│П`НО#eТЦП%ТДП4НО!0Т─П?НО(Т┴ПHsТ┼ pНОТТ⌠П.upТ■П"НО©Т▄ПdНО▀Т─НИО┐upП3НИО{upПEНИОsu pТ∙ПEТ√НЖО>Т├tП2Т┤НЖО Т─П0НдtТНОpТІПXuНОмpТєП3Т╔uНО≥Т─Т│ pП?uНОdpТ─upus dЇ >ГZН DESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL12<==Ґ▓CСЧClD╪╨h╩█П╪⌠╪─CСЧ─╪іҐ,BЫ$BPЮҐ;>Ґ╒╪%}╪%~╪╔─Dq#Cз┌╪%|─CYiCZBтCW2ҐЎЎПD@╩ю╩═D@╪═CQ2Ў═@ҐЎЎ/П╪╪⌠╪CE≤DrClC─╪─CRYwC`CQ2Ґ+ЬҐЎAПЗCСЧ╪⌠ю╩²h╪"ClC─CСЧ─╪іBтCK2Ґ7ВЧҐЎAп╩юD@D`╩юC▐YiCZҐ,BА$Ґ░Ґ3>BmПCз┌╪%~╩▌щ─╪╔|Cз┌Cз┐─╪╦CHBу$Ґ░Ґ;>B]П╪Cl@Db≤CВч╪⌠╪─╪─CаYFCH╪╦BhЮ╪ҐpҐ▓BлюClD╪╩█ПCE■CСЪClGҐ,CZBPЮҐЮҐ╒Bдю╪%~Cз┌Dq"─CZ└╪%~╪%|─CДYBт╪і╪╗лЎПBПD╩ю╩═D@D@C`Ў═@╪ўлЎ/ПBХCЪ╪⌠╪CСЧDr╪╨l╪╪⌠╧CРXв╪═Ґ+Ь╪ўлAПBПD╪⌠ю╪╪"Db≥CСЪ╪⌠╧BтCZҐ7Ь╪ЄлAпBХDD@D`╩ю╩юCДX Ґ,╪іҐ░ҐЮBmПBлю╪%}╪%~╪╔─Dq#Cз┌╪%|─CHCHҐ░Ґ*ЮB]ПBдюCl@CСЧCВч╩²g╪ClGCаXh╪╦╪╦╪ҐnҐ≈ BлбBmП╪╪⌠╪CE≤DrClC─╪─CZBтҐэҐ╞ BдбB]ПCз┐Cз┌CZ─╩▌щ╪%~Cз┐─C▐XE╪іҐ,╪╗нBПBAП╩юD@D`╩юC`╪ўнA_юBХBAпCСЧClD╪╨h╩█П╪⌠╪─CСЧ─CRX7╪═╪ўнBтBПBЎП╪Cl@Db≤CВч╪⌠╪─╪─CZҐ,╪ЄнBхBХBЎ/ПD@╩ю╩═D@CXE╪іBтҐэBПpBлбҐ▓╪%~Cз┌Dq"─CZ└╪%~╪%|─CH╪╦Ґ*эBДpBдбҐ╒CСЧ╪⌠ю╩²h╪"ClC─CСЧ─BЦXh╪╦CHҐ≈ CB░BmПҐ3?Ъ╪⌠╪CСЧDr╪╨l╪╪⌠╧Bт╪іҐ╞ BЫЧB]ПҐ;@Cз┌╪%~╩▌щ─╪╔|Cз┌Cз┐─BюX Ґ,CZCW4AПҐ╩ЧD@D`╩ю╩ю╪═A_юCQ3ЧAпҐ╪ClD╪╩█ПCE■CСЪClG+РdWD`D`╪@╪@D`╩═╪@Cю╩═╩═CюCю╩═D`Cю╪@+рdWC`BтCQ4ЎПҐ╪ClBCСЧCВэ╩²g╪ClGҐ,╪іBхCK4Ў/ПҐ╪╩ю╩═D@D@+Юd■BтCZBПtBА Ґ▓Ґ3@Cз┌─Cз┌CZ│╩▌щ╪%~Cз┐─╪╦╪╦BДtBу Ґ╒Ґ;@╪⌠Ў╪╪$Db≥CСЧ╪⌠╧,dфCHCHCB▒BhЮҐ3>Ґ▓CСЧClD╪╨h╩█П╪⌠╪─CСЧ─╪іҐ,BЫ"BPЮҐ;>Ґ╒╪%}─╪%~╪╔Dq#Cз┌╪%|─,5dИCZBтCW2ҐЎЎПD@╩ю╩═D@╪═CQ2Ў═@ҐЎЎ/П╪╪⌠╪CE≤DrClC─╪─,rdВC`CQ2Ґ+ЬҐЎAПЗCСЧ╪⌠ю╩²h╪"ClC─CСЧ─╪іBтCK2Ґ7ВЧҐЎAп╩юD@D`╩ю,╞dИCZҐ,BА"Ґ░Ґ3>BmПCз┌─╪%~╩▌щ@╪╔|Cз┌Cз┐─╪╦CHBу"Ґ░Ґ;>B]П╪Cl@Db≤CВч╪⌠╪─╪─,АdфCH╪╦BhХ╪ҐpҐ▓BлюClB╪╩█ЯCE■CСЧClGҐ,CZBPХҐЮҐ╒Bдю╪%}─Cз┌Dq"юCZ└╪%~╪%|─-d■Bт╪і╪╗лЎПBПD╩ю╩═D@D@C`Ў═0╪ўлЎ/ПBХCЪ╪⌠ЎCСЧDr╪╨l╪╪⌠╧-dW╪═Ґ+З╪ўлAПBПD╪⌠Ў╪╪$Db≥CСЧ╪⌠╧BтCZҐ7З╪ЄлAпBХDD@D`╩ю╩ю-dҐ,╪іҐ▄ҐЮBmПBлю╪%}─╪%~╪╔Dq#Cз┌╪%|─CHCHҐ▄Ґ*ЮB]ПBдюClBCСЧCВэ╩²g╪ClG,АcХ╪╦╪╦╪ҐoҐ≈ BлбBmП╪╪⌠╪CE≤DrClC─╪─CZBтҐчҐ╞ BдбB]ПCз┌─Cз┌CZ│╩▌щ╪%~Cз┐─,╞cе╪іҐ,╪╗нBПBAП╩юD@D`╩юC`╪ўнA_юBХBAпCСЧClD╪╨h╩█П╪⌠╪─CСЧ─,rcЇ╪═╪ўнBтBПBЎП╪Cl@Db≤CВч╪⌠╪─╪─CZҐ,╪ЄнBхBХBЎ/ПD@╩ю╩═D@,5cе╪іBтҐчBПpBлбҐ▓╪%}─Cз┌Dq"юCZ└╪%~╪%|─CH╪╦Ґ*чBДpBдбҐ╒CСЧ╪⌠ю╩²h╪"ClC─CСЧ─,cХ╪╦CHҐ≈CB░BmПҐ3?Ъ╪⌠ЎCСЧDr╪╨l╪╪⌠╧Bт╪іҐ╞BЫЧB]ПҐ;@Cз┌─╪%~╩▌щ@╪╔|Cз┌Cз┐─+ЮdҐ,CZCW4AПҐ╩ЧD@D`╩ю╩ю╪═A_пCQ3ЧAпҐ╪ClB╪╩█ЯCE■CСЧClGmember,RUВD`D`╪@╪@D`╩═╪@Cю╩═╩═CюCю╩═D`Cю╪@,2UВC`BтCQ4ЎПҐ╪ClBCСЧCВэ╩²g╪ClGҐ,╪іBхCK4Ў/ПҐ╪╩ю╩═D@D@,@V4BтCZBПtBА Ґ▓Ґ3@Cз┌─Cз┌CZ│╩▌щ─╪%~Cз┌─╪╦╪╦BДtBу Ґ╒Ґ;@╪⌠Ў╪╪$Db≥CСЧ╪⌠╧,cVfCHCHCB▒BhЮҐ3>Ґ▓CСЧClD╪╨h╩█П╪⌠╪─CСЧ─╪іҐ,BЫ"BPЮҐ;>Ґ╒╪%}─╪%~╪╔Dq"─Cз┌╪%}─,∙V┴CZBтCW2ҐЎЎПD@╩ю╩═D@╪═CQ2Ў═@ҐЎЎ/П╪╪⌠╪CE≤DrClC─╪─,рV≈C`CQ2Ґ+ЬҐЎAПЗCСЧ╪⌠ю╩²h╪"ClC─CСЧ─╪іBтCK2Ґ7ВЧҐЎAп╩юD@D`╩ю-V┴CZҐ,BА"Ґ░Ґ3>BmПCз┌─╪%}╩▌щ@╪╔─Cз┌Cз│─╪╦CHBу"Ґ░Ґ;>B]П╪Cl@Db≤CВч╪⌠╪─╪─-AVfCH╪╦BhХ╪ҐpҐ▓BлюClB╪╩█ЯCE■CСЧClGҐ,CZBPХҐЮҐ╒Bдю╪%}─Cз┐Dq"юCZ─╪%~╪%~─-dV4Bт╪і╪╗лЎПBПD╩ю╩═D@D@C`Ў═0╪ўлЎ/ПBХCЪ╪⌠ЎCСЧDr╪╨l╪╪⌠╧-rUВ╪═Ґ+З╪ўлAПBПD╪⌠Ў╪╪$Db≥CСЧ╪⌠╧BтCZҐ7З╪ЄлAпBХDD@D`╩ю╩ю-dU╨Ґ,╪іҐ▄ҐЮBmПBлю╪%}─╪%~╪╔Dq"─Cз┌╪%}─CHCHҐ▄Ґ*ЮB]ПBдюClBCСЧCВэ╩²g╪ClG-AU┬╪╦╪╦╪ҐoҐ≈ BлбBmП╪╪⌠╪CE≤DrClC─╪─CZBтҐчҐ╞ BдбB]ПCз┌─Cз┌CZ│╩▌щ─╪%~Cз┌─-Ue╪іҐ,╪╗нBПBAП╩юD@D`╩юC`╪ўнA_юBХBAпCСЧClD╪╨h╩█П╪⌠╪─CСЧ─,рUW╪═╪ўнBтBПBЎП╪Cl@Db≤CВч╪⌠╪─╪─CZҐ,╪ЄнBхBХBЎ/ПD@╩ю╩═D@,∙Ue╪іBтҐчBПpBлбҐ▓╪%}─Cз┐Dq"юCZ─╪%~╪%~─CH╪╦Ґ*чBДpBдбҐ╒CСЧ╪⌠ю╩²h╪"ClC─CСЧ─,cU┬╪╦CHҐ≈CB░BmПҐ3?Ъ╪⌠ЎCСЧDr╪╨l╪╪⌠╧Bт╪іҐ╞BЫЧB]ПҐ;@Cз┌─╪%}╩▌щ@╪╔─Cз┌Cз│─,@U╨Ґ,CZCW4AПҐ╩ЧD@D`╩ю╩ю╪═A_пCQ3ЧAпҐ╪ClB╪╩█ЯCE■CСЧClG*r]7D`D`╪@╪@D`╩═╪@Cю╩═╩═CюCю╩═D`Cю╪@*R]7C`BтCQ4ЎПҐ╪ClBCСЧCВэ╩²g╪ClGҐ,╪іBхCK4Ў/ПҐ╪╩ю╩═D@D@*`]tBтCZBПtBА Ґ▓Ґ3@Cз┌─Cз┌CZ│╩▌щ╪%~Cз┐─╪╦╪╦BДtBу Ґ╒Ґ;@╪⌠Ў╪╪$Db≥CСЧ╪⌠╧*┐]іCHCHCB▒BhЮҐ3>Ґ▓CСЧClD╪╨h╩█П╪⌠╪─CСЧ─╪іҐ,BЫ"BPЮҐ;>Ґ╒╪%}─╪%~╪╔Dq#Cз┌╪%|─*╣]иCZBтCW2ҐЎЎПD@╩ю╩═D@╪═CQ2Ў═@ҐЎЎ/П╪╪⌠╪CE≤DrClC─╪─*Р]вC`CQ2Ґ+ЬҐЎAПЗCСЧ╪⌠ю╩²h╪"ClC─CСЧ─╪іBтCK2Ґ7ВЧҐЎAп╩юD@D`╩ю+/]иCZҐ,BА"Ґ░Ґ3>BmПCз┌─╪%~╩▌щ@╪╔|Cз┌Cз┐─╪╦CHBу"Ґ░Ґ;>B]П╪Cl@Db≤CВч╪⌠╪─╪─+a]іCH╪╦BhХ╪ҐpҐ▓BлюClB╪╩█ЯCE■CСЧClGҐ,CZBPХҐЮҐ╒Bдю╪%}─Cз┌Dq"юCZ└╪%~╪%|─+└]tBт╪і╪╗лЎПBПD╩ю╩═D@D@C`Ў═0╪ўлЎ/ПBХCЪ╪⌠ЎCСЧDr╪╨l╪╪⌠╧+▓]7╪═Ґ+З╪ўлAПBПD╪⌠Ў╪╪$Db≥CСЧ╪⌠╧BтCZҐ7З╪ЄлAпBХDD@D`╩ю╩ю+└\ЗҐ,╪іҐ▄ҐЮBmПBлю╪%}─╪%~╪╔Dq#Cз┌╪%|─CHCHҐ▄Ґ*ЮB]ПBдюClBCСЧCВэ╩²g╪ClG+a\х╪╦╪╦╪ҐoҐ≈ BлбBmП╪╪⌠╪CE≤DrClC─╪─CZBтҐчҐ╞ BдбB]ПCз┌─Cз┌CZ│╩▌щ╪%~Cз┐─+/\╔╪іҐ,╪╗нBПBAП╩юD@D`╩юC`╪ўнA_юBХBAпCСЧClD╪╨h╩█П╪⌠╪─CСЧ─*Р\≈╪═╪ўнBтBПBЎП╪Cl@Db≤CВч╪⌠╪─╪─CZҐ,╪ЄнBхBХBЎ/ПD@╩ю╩═D@*╣\╔╪іBтҐчBПpBлбҐ▓╪%}─Cз┌Dq"юCZ└╪%~╪%|─CH╪╦Ґ*чBДpBдбҐ╒CСЧ╪⌠ю╩²h╪"ClC─CСЧ─*┐\х╪╦CHҐ≈CB░BmПҐ3?Ъ╪⌠ЎCСЧDr╪╨l╪╪⌠╧Bт╪іҐ╞BЫЧB]ПҐ;@Cз┌─╪%~╩▌щ@╪╔|Cз┌Cз┐─*`\ЗҐ,CZCW4AПҐ╩ЧD@D`╩ю╩ю╪═A_пCQ3ЧAпҐ╪ClB╪╩█ЯCE■CСЧClG2`ЇD`D`╪@╪@D`╩═╪@Cю╩═╩═CюCю╩═D`Cю╪@`ЇC`BтCQ4ЎПҐ╪ClBCСЧCВэ╩²g╪ClGҐ,╪іBхCK4Ў/ПҐ╪╩ю╩═D@D@ `ТBтCZBПrBА Ґ▓Ґ3@Cз┌─Cз┌CZ┐╩▌щ╪%} Cз┐─╪╦╪╦BДrBу Ґ╒Ґ;@╪⌠Ў╪╪$Db≥CСЧ╪⌠╧Ca&CHCHCB▓BhЮҐ3=Ґ▓CСЧClD╪╨g╩█П╪⌠ЎCСЧ─╪іҐ,BЫ$BPЮҐ;=Ґ╒╪%}─╪%~╪╔}Dq#Cз┌Ю╪%|─uaICZBтCW2ҐЎЎПD@╩ю╩═D@╪═CQ2Ў═@ҐЎЎ/П╪╪⌠╪CE≥DrClB╪─╡aWC`CQ2Ґ+ЬҐЎAПЗCСЩ─╪⌠ю╩²h─╪"ClBCСЧ─╪іBтCK2Ґ7ВЧҐЎAп╩юD@D`╩юОaICZҐ,BА$Ґ░Ґ3=BmПCз┌─╪%~╩▌эю╪╔|Cз┌ЮCз┐─╪╦CHBу$Ґ░Ґ;=B]П╪─Cl@Db≈─CВч╪⌠Ў╪─!a&CH╪╦BhД╪ҐpҐ▓BлюClB╪╩█ЯCE■CСЧClGҐ,CZBPДҐЮҐ╒Bдю╪%}─Cз┌Dq#@CZ└╪%} ╪%|─D`ТBт╪і╪╗лЎПBПD╩ю╩═D@D@C`Ў═0╪ўлЎ/ПBХCЪ╪⌠ЎCСЧDr╪╨l╪╪⌠╧R`Ї╪═Ґ+З╪ўлAПBПD╪⌠Ў╪╪$Db≥CСЧ╪⌠╧BтCZҐ7З╪ЄлAпBХDD@D`╩ю╩юD`zҐ,╪іҐ▌ҐЮBmНBлю╪%}─╪%~╪╔}Dq#Cз┌Ю╪%|─CHCHҐ▌Ґ*ЮB]НBдюClBCСЧCВэ╩²g╪ClG!`H╪╦╪╦╪ҐnҐ≈ BлцBmП╪╪⌠╪CE≥DrClB╪─CZBтҐэҐ╞ BдцB]ПCз┌─Cз┌CZ┐╩▌щ╪%} Cз┐─О`%╪іҐ,╪╗нBПBAП╩юD@D`╩юC`╪ўнA_юBХBAпCСЧClD╪╨g╩█П╪⌠ЎCСЧ─╡`╪═╪ўнBтBПBЎП╪─Cl@Db≈─CВч╪⌠Ў╪─CZҐ,╪ЄнBхBХBЎ/ПD@╩ю╩═D@u`%╪іBтҐэBПpBлцҐ▓╪%}─Cз┌Dq#@CZ└╪%} ╪%|─CH╪╦Ґ*эBДpBдцҐ╒CСЩ─╪⌠ю╩²h─╪"ClBCСЧ─C`H╪╦CHҐ≈CB░BmНҐ3?Ъ╪⌠ЎCСЧDr╪╨l╪╪⌠╧Bт╪іҐ╞BЫЧB]НҐ;@Cз┌─╪%~╩▌эю╪╔|Cз┌ЮCз┐─ `zҐ,CZCW4AПҐ╩ЧD@D`╩ю╩ю╪═A_пCQ3ЧAпҐ╪ClB╪╩█ЯCE■CСЧClG;r`7D`D`╪@╪@D`╩═╪@Cю╩═╩═CюCю╩═D`Cю╪@;R`7C`BтCQ4ЎПҐ╪Cl@CСЧCВч╩²g╪ClGҐ,╪іBхCK4Ў/ПҐ╪╩ю╩═D@D@;``tBтCZBПpBА Ґ▓Ґ3@Cз┐Cз┌CZ─╩▌щ╪%~Cз┐─╪╦╪╦BДpBу Ґ╒Ґ;@╪⌠ю╪╪"Db≥CСЪ╪⌠╧;┐`іCHCHCB▓BhЮҐ3>Ґ▓CСЧClD╪╨h╩█П╪⌠╪─CСЧ─╪іҐ,BЫ$BPЮҐ;>Ґ╒╪%}╪%~╪╔─Dq#Cз┌╪%|─;╣`иCZBтCW2ҐЎЎПD@╩ю╩═D@╪═CQ2Ў═@ҐЎЎ/П╪╪⌠╪CE≤DrClC─╪─;Р`вC`CQ2Ґ+ЬҐЎAПЗCСЧ╪⌠ю╩²h╪"ClC─CСЧ─╪іBтCK2Ґ7ВЧҐЎAп╩юD@D`╩юBmПCз┌╪%~╩▌щ─╪╔|Cз┌Cз┐─╪╦CHBу$Ґ░Ґ;>B]П╪Cl@Db≤CВч╪⌠╪─╪─0Ў▀0BЭDCЭ,DM≤─╩╙·╪сюBЭ@+1a╪Е╨Ґa╞Cр0^Ґ)┘`Ґ1хOЎ≥├@н`╩ю╩÷dюCЧ*CЪЧ@н@Ў&7⌡EI9иBК@hAЮН─Bеs╟Ґ)_@Bч┬CЩлDR┬─╩╞a╪3@Bч├+^ЦAQ·Х╩=n`Aрє5©÷▓©▒\ю"ZAv╪╩·2@CЗjCЪРAvЎШDц8 @Ул─@Пn╔Ў╪Тю©1═CЪЧD`⌡@╪ь╪©1юaRelation+▓dW╨5п²Aчф@э─@ЪЛЎ!)Л╪©-─CЧD`ё@рp╪─Eи║:B^фBRє─Ґ8СpЎ┌jAчІCЪЪ─©ў╩©┘@╩═R@RD@&РdW╨>T┬Ґ╚xтBТ─юҐ╔<Bф`╪=ўe╪╪─Ґ8Cн7Dl▄BЗл╪╪Eu|дDtшCЩо8╩≥єь╪╒!PC}/7CЪЧ@р─╪П╩÷]©-░CЪЭ─#cЪ╩1╛р╪2≥nBЯJпҐ;.@Ґ╞ЗЎp ╪┬╪∙пCI╘DqФCj/@╪┬Dг╙rDAV6BЪ°ХҐ┼XҐ°АП©?─CЭC─BЗх╪1и╩⌠tҐ4CЭD!ъc ╩+І╩Ё'╡CKuєҐ1≤Ґ▒W©*M─╪╘─╪4xҐ╟PDsDCк┬ ╪╚─DклZDnн≈BВ⌠ЮҐ>Л Ґ╩ ПҐ║іPCТxCj0╪ІW╩▌╪∙пюCТx іbъ╩╚j╩#╘,CZО≤╪?pҐ7!8Bлgx╪"ж─╪(8╪╡ЧDqдCвг╪"т─DУBfDН{5BIs╟AЫП═Aъ⌠ Ґ Х┬CГVCк┬BO╦╩▄╪╪4w`CГT─aRelation─DiцBз╪Э─/├^DGs≤ЎКlAЮ░Ў%і■Ў17`?mюCЧМҐ=п╩Є─╩╘Bб7CЧЛ╩╧НBи[Aщ+╟Ўp■Ў3(═@W░╪.AМ DE─D\uЎх╪-0]ВDЖа9╪└ФAcsю╪9П▒Ґ║ШПBo⌡ЮCЬv╪╘t╩ёP─╩╩JCV▄─CЬw╩│ZDP%╪>╪7─DhECМбH╪>$─cgCаш CМбCБх@╩≈╩╪=пCаш─я`м^m╪╡И╪П╩Ї╨─DYЯCЗ╪╡Х⌠`АCMCЗDHE─╩і╪ЯCM^t╡ZtҐ═k╪░╩іd░DHґCЪqҐ═tр^zB_∙CЪpDY⌡p╩ЇS╪▐B_▄╠Z UBЧД╪Ч╩⌠"@CлnCЭ═BЧЮsZoҐCЭDlщю╪3▓╪Ч`Ґ dSubTypeR[В▓[ВD@╩ю╩═D@R[Ї╩юD@D`╩ю`~]>╪╗─╪/HҐ)DrчCпЇ═╪╗ч`╟CЦW─Cп╦BжП╩█"╪/H`CЦX ]BйZб╪*_@╪ э╪█тDoйCъ$`╪*`з]lCу═юCъ$Cr,╩░6╪ ш═Cу═нZгнY╪─Щ╪ч╪мюDg3CО"═╪─Ы√ZГCCО"CГ2@╩≤м╪щ`C)cm `mCь░@╪#√╩▌h`╪╞$CэjCь░ШcA╪'oюCэjDq≈═CPэ╪#√╪'p`nХ^ўCщ⌠@╪(╙╩▐╣═╪∙ПCвVpCщ■э`@╪"lюCвVDpJ`Cj╪(╘░╪"lН^і.\FCw;╪╪╩█=─BъXCЯECw=І^┬╪┬еCЯDDrб─Ґ ╗╪╩╪┬ц0\C░XЦC`≈╪ v╩▌РюC\0CЖ┼C`≤Т\+╪÷i─CЖ┼Dq `╪ёп╪ u░╪÷hН)О]"ptТF ptpt ptptpТXtТFptНpНjОB┴3НjО?│Т└П2Т┘П5НjО=LТўП2Т╞П*НjО;Т║ПQТ╒НjО8ЦН`О5шuТ─pП"Н VО2сuП&Н`О/кupН VО,цuП3НjО(ГsНjО%pТ uП.Т⌡pП&НjО"вТЙТКПDНjО ёТ╪П'u pТҐП)НjОnТЎПJТ©НjО:Т▒ tП.Т▓ПAНjО^pТС uП!p ТТНjО)Т├Т┤ПKНjОУТ─НjОТ╠П4upТ╡u pНjО ЕТ П+Т upНjО╟Т╒П!ТёupНjО |ТГП=ТХНjОGu pНjО≤Т│П_Т┌НjОdТ╙upП5Т╚FM о>Q^<зН2ОQВ$Ьx Ш7ЬШ7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7ЬxШ7ЬШ7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Н-РОcЇЬxШ7ЬШ7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7ЬxШ7ЬШ7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7ЬxШ7ЬШ7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7ЬxШ7ЬШ7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7ЬxШ7ЬШ7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7ЬxШ7ЬШ7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7НRОWЇН▓ОcWЬЪ ШЬШ#Ш#Ш#Ш#Н5рОZЬЪ ШЬШ#Ш#Ш#Ш#НDRОX7 Ш7Ш7Ш7Н=2Оbв НIОaВШ7Ш7Н3Оbw Ш7Ш7Ш7Ш7Н+RО_Ї Ш7Ш7Ш7Ш7Ш7Н!▓Оbw Ш7Ш7Н?rО\W Ш7Ш7Ш7Ш7Ш7Н2О]В Ш7Ш7Н,2ОXвЬЪ ШЬШ#Ш#Ш#Ш#Н2ОVw Ш7Ш7НОZВ НОZВН╡О_≈Н▓О_ЇН+╡О[ВН=О_WШ#Ш#Ш#Ш#Ш#Ш#Ш#Ш#Ш#Ш#ЬxШ7ЬШ7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7НrОT Ш#Ш#Ш#Ш#Н2О\Ш#Ш#Ш#Ш#Ш#Ш#Ш#Ш#FVЮ┘Зatu╪CYPRESS DATA MODEL CONCEPTS13languages (and MultiRelationSubset implementations) could be built on top of the operations wehave defined thus far. For the purposes of this report, however, we will assume that our querylanguage is the Relational algebra (Codd[1970]), providing the join, projection, and selectionoperators on relations. We choose the relational algebra due to its wide acceptance in the literature,and now commercially. Our choice does not preclude an entity-centric query language in futurework, however. We and others have designed but have not implemented such languages. To demonstrate that the relational algebra can be used with our system, we will define a mappingof the relational operations onto the Cypress model. Some augmentation of the relational algebra isnecessary to include the operations our model provides upon domains. The important aspects ofthe mapping are:1.The Cypress relations exist in our relational mapping essentially unchanged, except thatsome type constraints exist on attribute values; these constraints simply appear asexceptional conditions when violated, they do not effect the form of the relationaloperations.2.For each domain in our schema, we define a unary relation in our mapping with the entityname as its only attribute. The sole purpose of the unary domain relations is to specify theexistence of entities in the domain. For example, a Person relation would contain onetuple per person entity in the database. The unary domain relations allow DomainSubsetto be performed in the relational algebra as a select operation on the domain.3.Entity-valued attributes of relations appear to have the name of the corresponding entitystored in them. There are no "atomic" entity values, so the ChangeName operation isexpensive in this model. All references to an entity in the database appear as the stringname of the entity, and the system generates an error if an entity-valued attribute isinitiaized to an entity which does not exist in the domain.Our representation of the data schema is as before: schema entities and relationships in the domaindomain, relation domain, attribute domain, subtype relation, and attribute relations.The join, project, and select operations in the relational algebra can now be performed byMultiRelationSubset, or by the appropriate calls to RelationSubset. Note that we must typicallydeclare new relations for the result and intermediate results of computing such queries. A selectoperation on a domain may be used to determine whether a particular entity exists, or to enumeratethe entities of a domain. A select operation on a relation may be used to find relationships thatreference a particular entity. Query operations on the schema can be used to determine whatrelations might reference an entity of a particular domain.The unary relations representing domains are used only to determine the existence of entities. AnЪН+О\∙ptpТXtptptН;РpНОT╨ТёupТєП"НОR┘Т╞Т╟ПDНОPQТП?spТs psНОNpТ└П@Т┘П'НОKХТўТ╞ПIНОIЁТ─ПTН6▓ТНОEьТ⌡П`НОCёТ┘ПYТ├ НОAoТ╘ПDТ╙НО?:Т─Н·О;_НЖТфПXНЖО9*ТПSНЖО6ЖТПSНЖО4а Н·О0ЕНЖТ▄П@Т█НЖО.╠Т┤Т┬ПVНЖО,}Т╧П)Т╨upНЖО*HТ∙Т√П;uНЖО(pТ─П/spН·О$8НЖТ╣П9spТІНЖО"ТЇТ╦П4u pНЖОоТ╛П(ТґП2НЖО⌡ТъПIТЮНЖОfТ─П;НО┼Т┐П(Т└П<НОVТ─ПUНОzТВПWТЬНОFupТ⌡Т°u pНО Т╙П5Т╚П-НО щТ┘ПbНО╗ТіП-ТїП5НОtТиПBТйНО?Т─П;НОdТ≤ПTТ≥ ЪnЇ \=Г]╞ DESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL14implementation could automatically create entities in these domains when an entity-valued attributeof a relationship is assigned a previously non-existent entity name. Note that domain relations mayin fact be ignored altogether by the user if this is done. Domain relations are purely an extension tothe Relational model. We chose not to automatically create entities in our mapping, as we wouldlose the logical integrity check the entities provide. 2.6 Convenience operationsSome more convenient specialized operations are built upon the basic operations described in theprevious two sections. They implement what we call properties and translucent attributes. Althoughtheoretically speaking these operations add no power to the model, they permit a significantlydifferent perspective on the data access and so should be thought of as part of the model.PropertiesProperties allow the client to treat entities as if they, like relationships, had "attributes." Theyprovide the convenience of treating attributes of relationships that reference an entity as if theywere attributes (or properties) of the entity itself. The property operations are: 1.GetPList[entity, attribute1, attribute2]: Attribute1 and attribute2 must be from the samerelation. Returns the values of attribute1 for all relationships in the relation that referencethe entity via attribute2. Attribute2 may be omitted, in which case it is assumed to be theonly other entity-valued attribute of the relation.2.GetP[entity, attribute1, attribute2]: this is identical to GetPList except exactly onerelationship must reference the entity via attribute2; otherwise an error is generated. GetPalways returns one value.3.SetPList[entity, attribute1, value list, attribute2]: Attribute1 and attribute2 must be fromthe same relation. Destroys any existing relationships whose attribute2 equals the entity,and creates new ones for each value in the list, with attribute1 equal to the value, andattribute2 equal to the entity. Attribute2 can be defaulted as in GetPList.4.SetP[entity, attribute1, value, attribute2]: this is identical to SetPList except it simplyadds a new relationship referencing the entity instead of destroying any existing ones(unless attribute1 is a key of its relation, in which case the existing one must be replaced).Thus the property operations allow information specified through relationships to be treated asproperties of the entity itself, in single operations. The property operations and the operationsdefined in earlier sections may be used interchangeably, as there is only one underlyingrepresentation of information: the relationships. As an example of the use of properties, considerН)О\∙ptТF ptpt ptptpТXtТFptНpНjОT╨Т░П;Т▒П(НjОR┘Т▓П7Т⌠sНjОPQТ▀П:pТ▄НjОNТ²ПWТ·НjОKХТ─П6Н ╘ТНjОE▒rТ─НjОA╣pТіПOТїНjО?│Т├П4s ps Т┤ p НjО=LТсПPТт НjО;Т─ПZНjО7uОMtОзpТ╟Н`ОиТ╩Т╪П"uОҐ▓CСЧClD╪╨h╩█П╪⌠╪─CСЧ─╪іҐ,BЫ"BPЮҐ;>Ґ╒╪%}─╪%~╪╔Dq#Cз┌╪%|─-∙[)CZBтCW2ҐЎЎПD@╩ю╩═D@╪═CQ2Ў═@ҐЎЎ/П╪╪⌠╪CE≤DrClC─╪─-р[7C`CQ2Ґ+ЬҐЎAПЗCСЧ╪⌠ю╩²h╪"ClC─CСЧ─╪іBтCK2Ґ7ВЧҐЎAп╩юD@D`╩ю.[)CZҐ,BА"Ґ░Ґ3>BmПCз┌─╪%~╩▌щ@╪╔|Cз┌Cз┐─╪╦CHBу"Ґ░Ґ;>B]П╪Cl@Db≤CВч╪⌠╪─╪─.A[CH╪╦BhХ╪ҐpҐ▓BлюClB╪╩█ЯCE■CСЧClGҐ,CZBPХҐЮҐ╒Bдю╪%}─Cз┌Dq"юCZ└╪%~╪%|─.dZтBт╪і╪╗лЎПBПD╩ю╩═D@D@C`Ў═0╪ўлЎ/ПBХCЪ╪⌠ЎCСЧDr╪╨l╪╪⌠╧.rZ≈╪═Ґ+З╪ўлAПBПD╪⌠Ў╪╪$Db≥CСЧ╪⌠╧BтCZҐ7З╪ЄлAпBХDD@D`╩ю╩ю.dZZҐ,╪іҐ▄ҐЮBmПBлю╪%}─╪%~╪╔Dq#Cз┌╪%|─CHCHҐ▄Ґ*ЮB]ПBдюClBCСЧCВэ╩²g╪ClG.AZ(╪╦╪╦╪ҐoҐ≈ BлбBmП╪╪⌠╪CE≤DrClC─╪─CZBтҐчҐ╞ BдбB]ПCз┌─Cз┌CZ│╩▌щ╪%~Cз┐─.Z╪іҐ,╪╗нBПBAП╩юD@D`╩юC`╪ўнA_юBХBAпCСЧClD╪╨h╩█П╪⌠╪─CСЧ─-рYВ╪═╪ўнBтBПBЎП╪Cl@Db≤CВч╪⌠╪─╪─CZҐ,╪ЄнBхBХBЎ/ПD@╩ю╩═D@-∙Z╪іBтҐчBПpBлбҐ▓╪%}─Cз┌Dq"юCZ└╪%~╪%|─CH╪╦Ґ*чBДpBдбҐ╒CСЧ╪⌠ю╩²h╪"ClC─CСЧ─-cZ(╪╦CHҐ≈CB░BmПҐ3?Ъ╪⌠ЎCСЧDr╪╨l╪╪⌠╧Bт╪іҐ╞BЫЧB]ПҐ;@Cз┌─╪%~╩▌щ@╪╔|Cз┌Cз┐─-@ZZҐ,CZCW4AПҐ╩ЧD@D`╩ю╩ю╪═A_пCQ3ЧAпҐ╪ClB╪╩█ЯCE■CСЧClGB`ВD`D`╪@╪@D`╩═╪@Cю╩═╩═CюCю╩═D`Cю╪@AР`ВC`BтCQ4ЎПҐ╪Cl@CСЧCВч╩²g╪ClGҐ,╪іBхCK4Ў/ПҐ╪╩ю╩═D@D@Ba4BтCZBПpBА Ґ▓Ґ3@Cз┐Cз┌CZ─╩▌щ╪%~Cз┐─╪╦╪╦BДpBу Ґ╒Ґ;@╪⌠ю╪╪"Db≥CСЪ╪⌠╧B#afCHCHCB▓BhЮҐ3>Ґ▓CСЧClD╪╨h╩█П╪⌠╪─CСЧ─╪іҐ,BЫ$BPЮҐ;>Ґ╒╪%}╪%~╪╔─Dq#Cз┌╪%|─BUa┴CZBтCW2ҐЎЎПD@╩ю╩═D@╪═CQ2Ў═@ҐЎЎ/П╪╪⌠╪CE≤DrClC─╪─B▓a≈C`CQ2Ґ+ЬҐЎAПЗCСЧ╪⌠ю╩²h╪"ClC─CСЧ─╪іBтCK2Ґ7ВЧҐЎAп╩юD@D`╩юBоa┴CZҐ,BА$Ґ░Ґ3>BmПCз┌╪%~╩▌щ─╪╔|Cз┌Cз┐─╪╦CHBу$Ґ░Ґ;>B]П╪Cl@Db≤CВч╪⌠╪─╪─CafCH╪╦BhЮ╪ҐpҐ▓BлюClD╪╩█ПCE■CСЪClGҐ,CZBPЮҐЮҐ╒Bдю╪%~Cз┌Dq"─CZ└╪%~╪%|─C$a4Bт╪і╪╗лЎПBПD╩ю╩═D@D@C`Ў═@╪ўлЎ/ПBХCЪ╪⌠╪CСЧDr╪╨l╪╪⌠╧C2`В╪═Ґ+Ь╪ўлAПBПD╪⌠ю╪╪"Db≥CСЪ╪⌠╧BтCZҐ7Ь╪ЄлAпBХDD@D`╩ю╩юC$`╨Ґ,╪іҐ░ҐЮBmПBлю╪%}╪%~╪╔─Dq#Cз┌╪%|─CHCHҐ░Ґ*ЮB]ПBдюCl@CСЧCВч╩²g╪ClGC`┬╪╦╪╦╪ҐnҐ≈ BлбBmП╪╪⌠╪CE≤DrClC─╪─CZBтҐэҐ╞ BдбB]ПCз┐Cз┌CZ─╩▌щ╪%~Cз┐─Bо`e╪іҐ,╪╗нBПBAП╩юD@D`╩юC`╪ўнA_юBХBAпCСЧClD╪╨h╩█П╪⌠╪─CСЧ─B▓`W╪═╪ўнBтBПBЎП╪Cl@Db≤CВч╪⌠╪─╪─CZҐ,╪ЄнBхBХBЎ/ПD@╩ю╩═D@BU`e╪іBтҐэBПpBлбҐ▓╪%~Cз┌Dq"─CZ└╪%~╪%|─CH╪╦Ґ*эBДpBдбҐ╒CСЧ╪⌠ю╩²h╪"ClC─CСЧ─B#`┬╪╦CHҐ≈ CB░BmПҐ3?Ъ╪⌠╪CСЧDr╪╨l╪╪⌠╧Bт╪іҐ╞ BЫЧB]ПҐ;@Cз┌╪%~╩▌щ─╪╔|Cз┌Cз┐─B`╨Ґ,CZCW4AПҐ╩ЧD@D`╩ю╩ю╪═A_юCQ3ЧAпҐ╪ClD╪╩█ПCE■CСЪClGJohn Smith.[1Eо∙ҐEu╘BkDBBpBЖпю╪-.═CЯЪCtlҐH╩█e╪▀■CР╨)+z╨їRD@╙┬╩░:p╪═в═Cг©`╪─╪3ХҐіlDs?Cл╪─3C^■EufdDВФpCгю╪0tҐ┼┬юCШ┬CC╪6ю╩▓≤╪╪УCШ┬─╨?═╩9▓ЭCю|╪+5чҐ╞О ҐЄy░╪╪▀■BЙ╦Dr⌡Ctl╪7'`EdН\Dm█"CP█п╪∙лaҐЄ╠Ю@Bе@CЧБBц░╪t╩≤eҐ@CJд╟BR└═Ґ≤Й╪─ЮCОDs─Ґ│Ю╪Ф@╪─ъ8л\дCУdP╩©m┬©'~Bй hAъS─Ў# `CБ╚╪.x╩▒┐╪=└Cя┼CБў╩ҐюLCМ~:Ў≈DBоЙpAС|─Ў╡═╪)ГCчІDrCDэ╪!H@╪)Х9F\PDnj,╩єаzAAщюCPZxBG╔хҐґ▌┬CЯ+╪┬h╩ ▒╪Cw≥CЯ.╩┌пDB┤▒Ў┼# BЭ ╪BfB8Ў<БП╪UCя┬Dn}Cб|╪.v╪R:.[ЇEE?Є╩6яGCZ■╟CХҐ╠\@╪І3ЎCЗ╪╡┬╩╔Т╩ЇчCMt─CЗ╨Ё3Da║·Ґ│⌠─AЙ BШ≥ЮBПH─╪тCw°DepCМР╪┬e╪жCi[ю╪)=╟Ґ6ФpB\Zp╪п─╪Ё╦CюЗDnІCLGю╪п─ERщDfqзCJmХ╪ї┐5Ў▌@Ґ<йфCЪrB_0╪g╩ wҐ═пCЪs─Є^┼╨ё}╩▀Е^BЬ╒P╪┴╠lҐ⌡4 Bк68╪ y╪÷\C\DqC`╔ю╪ xEZ,ЛDи├▄AЗ*AWлAMO─Ґ&)хCЗ/─CLD╪?╩▒K╪Ё╦@CЗ0─$│^Э╨!─E{НBиW─Ґ╣\`╪9з╗╪`l╪\─C[D]РDBЗ╪єЪ@╪[─EИпҐ╨╞┌Т╩╡I,╩&хЄC[d╟CЗ≤CК2╪:╩∙П@╪%*CеС═CК1─]be╪▓еnBс╨@дШ ©■ЛP©■n ?о╦ю╪╪─CW╗D]@DDJ╪╗Yю╪╨CmЖІҐ/зь@д─P©■p©∙Ю?пG@CВё─╪╔╩╒╩ҐC[юCВё─'by╨√_DлЭNҐ0╪# ▌Ґ╚ЎюAХЦ─╪x@Bм`DMе DU:Ґ2є╪xEtP╩╧│Ґ-ёP╪-e6Ґ░]@ю5хCЬC─╪╗X╩╒Ъю╩╩ІCWі@CЬFІcW╨╔еPCНTЧҐ╒■─╪÷≥)Ў@AJM╛╪ApDB≤ D^6Ў░T╪E_я┴Ґ,bBҐ╣И`╪╘C╨Ґ╨(`©▄и@CЧ┤юҐ2═╩╡:ю╩╙фBм\CЧ┬яc≈╨╦ВРB{ЬЄЎkҐ"Мy@я▒AЭH╣╪©─CЩlD`ы@М─╪─EH{ЫAШЬ╡A|ъ─ЎcюЎWKCЪТЎ░╩ҐgЮ╩║йAo╛CЪРr]≈r[≈р[≈р]≈r]≈▓]≈▓[≈╩ю╩═D@D@R]≈D@D`╩ю╩юr[Їр[ЇD@╩ю╩═D@r[w╩юD@D`╩ю╡[≈╡]≈D@D`╩ю╩юР[≈╩ю╩═D@D@р]wr]w╩юD@D`╩юр]ЇD@╩ю╩═D@professormembermemberOfmemberIsmemberAs-┬Z ╨=uc╨┌gцҐ?s`Ґ²╧ю╪╗█ПCъ╟╪┤╪=╚BOюDsD─CбV@╪┬─Eла╪E]М╩і5═D|%єCа=╪1TPCщ─CвзCM_╩▌A╪(&Cщ)#V├╪ТN╪3ЛЎ&0@HTAPїЮ@ЕЮ╪░╪┘╗Bр╦DrЙCzX╪░DA\хCг│Ў##@lu@AT≤ @ьЕ CМxCбVҐ╟H╩▄╩╪=╙@CМw─(║V;╨ІД\╩0sЪ╪▐юЮCllpBюD╟A^≥─╪╨╪ЄJCа}Dn║─CKЇ─╪╩EQ'Ddr≤╪╙4ХC`ї8AСЩ@AН@CПpCzXҐ-H╩█╪┘╗CПp&0U6╨≥┼V╩│h╪┴TPCуМBу²═©%─╪є─Ґ≥░CЛ&─DeЛBfo╪єEmDACвБ▐╪Ў @Cи-ЁAtЁAХЮCЗFCK╦╪>┐╩▒]╪ЄH─CЗG"вT▄╨═dG╪3цҐ}PCuFBxс═ЎЁ⌠H╪─AьDDD]*Ў'З╪E` Ь╪ҐБRЎ▀Ce8ЦAf│─A],юCЪ[─Bfp╪ы─╩ Ґ≥▐CЪ\яTw╨"ъCюдBu_D`≈Л©÷ь╪?'c╪Й@Bь<DO√ DS┴─Ґ'д╪ИEшo┬╩─0Ґ°╘─@ж`Bе;@C~;CЪА─Ў'П╩╩О╩╒вAьCЪА─UwWwрWwрUwUwРUwРWwD@D`╩ю╩ю2Uw╩ю╩═D@D@WWрWW╩юD@D`╩юW≈D@╩ю╩═D@РWwРUw╩ю╩═D@D@╡WwD@D`╩ю╩юрU≈U≈D@╩ю╩═D@рUW╩юD@D`╩ю34ageageIsageOf$РS≈&РS≈D@╩ю╩═D@$РSW╩юD@D`╩ю2r`≈7r`≈D@╩ю╩═D@2r`W╩юD@D`╩ю$╡_≈)╡_≈D@╩ю╩═D@$╡_W╩юD@D`╩юН+О]"ptpТXtptptН;РpНОUGТ─НОAЭ3НО> Т√Т≈u pП8uНО;ЛpТКupupТЛuНО9ЇpТ─tpП:НИО5шuТ4puТ5НЖО3ї pНИО/кuТ─pupuН*+pТНИО+ОuТАТБpupНЖО)╩Тў upupu pupНЖО'├Т░Т▒ upupНЖО%RupТ─П;Н1°ТНИО!vuТ⌡pupТ°П,НЖОBТ√upupТ≈upНЖО Т┌upupupТ┐upНЖОыТ─ НgТНОЩТПZНОиТ─ПMН1°tТНОМsТ─НО pТЇП5Т╦П'НО щТаПFТбНО╗ТМП9ТННОtТ─НО≤ТкП\ТлНОdТ■П)Т∙ upП%ЪчЇ о=Г^<ЩНrОRЇ$НDrО`≈Ьx Ш7ЬШ7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7ЬxШ7ЬШ7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Н.rОXв Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7ЬЪШЬШ#Ш#Ш#Ш#Н22О`ЇН▓ОcВН02О[≈Н▓О\ВН<▓ОYW ЬxШ7ЬШ7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Н РОc≈Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7ЬЪШЬШ#Ш#Ш#Ш#НРО\Н$rО_ЇН:РОaН$rО[WН:О\ Ш7Ш7Ш7Ш7Ш7Ш7ЬЪШЬШ#Ш#Ш#Ш#НrОUвН$▓ОSвН╡ОU7Н)рОVW Ш#Ш#Ш#Ъч&└EЫtuИDESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL16we choose to define an Organization domain, then the memberOf attribute is entity-valued; butinstead we might choose to make the memberOf attribute be string-valued, merely giving the nameof the organization without defining organizations as entities. This might be appropriate, forexample, if we did not wish to invoke the type checking on uniqueness of names and thecorrectness of entity types. We would like to write programs that are independent of whether anattribute is string-valued or entity-valued (as in the Relational data model).We introduce translucent attributes to avoid dependence on attribute types. Any attribute may betreated as a translucent attribute, by using the GetFS and SetFS operations to retrieve or assign itsvalue.GetFS[relationship, attribute] is identical to the GetF operation, except it returns a stringregardless of the attribute's type. If the attribute is datum-valued, e.g. an integer or boolean, it isconverted to a string equivalent. If the attribute is entity-valued, the name of the entity is returned.SetFS[relationship, attribute, value] performs the inverse mapping. If the attribute is datum-valued, e.g. an integer or boolean, a string equivalent is accepted. If the attribute is entity-valued,the name of the entity is passed to SetFS. If an entity with the given name does not exist in thedomain that is the attribute's type, then one is automatically created.Changing entity namesAnother convenience operation is provided on entities to change an entity's name:ChangeName[entity, new name]. This operation is semantically equivalent to destroying the givenentity and creating a new one with the new name, participating in the same relationships that the oldone did. See the description of ChangeName in Section 3.4 for precise semantics in our implementation, however. 2.7 NormalizationA common topic in the database literature is relational normalization (Codd [1970], Armstrong[1974], Hall et al[1976], Rissanen [1977], Beeri et al [1978], Fagin[1977, 1981], Biller[1979]). Arelation is normalized by breaking it into two or more relations of lower order (fewer attributes) toeliminate undesirable dependencies between the attributes. For example, one could define a"publication" relation with three attributes:Н)ОMЗptТF ptpt ptptpТXtТFptНpНjОFТ╚upupТ╛НjОCЙТ┼Т▀upП3НjОAІТчПNТъНjО?│ТМП)ТНП-НjО=MТ║ Т╒ПRНjО;Т─ПNНjО7=Т²s Т· pП>НjО5Т█П1upup Т▌НjО2тНjО.ЬuТpupТНjО,дТ²П$Т·ПDНjО*▐Т┤ПIТ┬spНjО&ЁuТеП&pТфП%НjО$Т≥ПVТ НjО"JТ≤П$upП(Т≥НjО Т─ПGНjО:sНjО2pТ▄ПKТ█НjОЧuТ┼pТ▀П3НjОиТ│П0Т┌П5НjО∙Т╞tП&Т╟ПBpТНjО>rТ─НjО 6pТэП8spТщНjОТвП>ТьП%НjОмТ≤ПeНjО≥ТППHТЯНjОdТ─П-Ъ (MВ?QOЩCYPRESS DATA MODEL CONCEPTS17Publication:PersonBookDateGeorgeBackgammon for Beginners1978JohnBackgammon for Beginners1978MaryHow to Play Chess1981MaryHow to Cheat at Chess1982This relation represents the fact that John and George wrote a book together entitled "Backgammonfor Beginners," published in 1978, and Mary wrote two books on the subject of chess, in 1981 and1982. Alternatively, we could encode the same information in two relations, an author relation and apublication-date relation:Author:PersonBookGeorgeBackgammon for BeginnersJohnBackgammon for BeginnersMaryHow to Play ChessMaryHow to Cheat at ChessPublication-date:BookDateBackgammon for Beginners1978How to Play Chess1981How to Cheat at Chess1982Although the second two relations may seem more verbose than the first one, they are actuallyrepresentationally better in some sense, because the publication dates of books are not representedredundantly. If one wants to change the publication date of "Backgrammon for Beginners" to 1979,for example, it need only be changed in one place in the publication-date relation but in two placesin the publication relation. If the date were changed in only one place in the publication relation,the database would become inconsistent. This kind of behavior is called an update anomaly. Thesecond two relations are said to be a normalized form (as it happens, third normal form) of the firstrelation, and thereby avoid this particular kind of update anomaly. A variety of successively stricter criteria for normalization have been developed and studied, basedon different kinds of real-world dependencies between attributes. Work on normalization willalmost certainly continue through the forseeable future.Relational normalization is not strictly part of the Cypress data model. However the model'soperations (and the tools we will develop in the implementation) encourage what we will callfunctionally irreducible form, in which relations are of the smallest order that is naturally meaningful.This form is in some sense the most fully normalized canonical form that could be defined. Н+О\ptpТXtptptН;РpН ОT-sН ┴ОQ║ЧЪОQЬpН╘ОQ║ЧОQЬН%IОQ║ЧвОQЬН ∙ОOдН╘Т─Н%IН ∙ОM▐Н╘Н%IН ∙ОK[Н╘Н%IН ∙ОI&Н╘Н%IНОFТ┼П<Т▀П%НОCЙТ≥П>Т П"НОA╣Т─П%Т│П@НО?│Т─Н О;╔sН ┴О9ЧЪО9qpН╘О9ЧО9qН ∙О7<Н╘Н ∙О5Н╘Н ∙О2сН╘Н ∙О0÷Н╘Н О,цsН ┴О*8ЧО*▐pНiО*8ЧвО*▐Н ∙О(ZНiН ∙О&&НiН ∙О#ЯНiНО ИТцТдПJНО╣ТёПFТєНО─Т┼ПaНОLТ█Т▌ПKНОТ⌡П9Т°П,НОЦТ║Т╒П:spНО╞Т┼Т▀ПHНОzТ─ПCН)TpТНОrТ╒П/ТёП5НО>ТщПXТчНО Т─П8НОpТшПHТэНОмТшПJТэНО≤sТ└pП8Т┘НОdТЕТФП@ТЪ4Ї И?Q]"6DESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL18Functionally irreducible normal form cannot be defined simply syntactically, but rather requiresresort to the semantics of relations. Specifically, the presence or absence of a relationship in arelation represents the truth of some predicate on the state of the represented world (Kent [1979]).For example, a "member" relationship represents the fact that a particular person is a member of aparticular organization. (The absence of such a relationship may mean falsity of that predicate or lack of knowledge;we fortunately need not concern ourselves with this distinction here). A relation is in irreducible form if it is ofthe smallest order possible without introducing new artificial domain(s) not otherwise desired (allrelations can be reduced to binary by introducing artificial domains). Biller [1979] provides a moreprecise definition of irreducible form. We will allow a slight weakening of irreducible form,functionally irreducible form, which permits combining two or more irreducible relations only whentheir semantics are mutually dependent (and therefore all present or absent in our worldrepresentation). For example, a birthday relation between a person, month, day, and year can becombined instead of using three relations. Another example would be an address relation between aperson, street, city, and zip code. Combining an age and phone relation would not result infunctionally irreducible form, however, as their semantics are not mutually dependent. The functionally irreducible relations seen by the user are independent of the physical representationchosen by the system for efficiency, so we are concerned only with the logical data access. Note thatin addition to avoiding update anomalies, functionally irreducible form provides a one-to-onecorrespondence between the relationships in the database and the atomic facts they represent, acanonical form that is in some sense more natural than any other form. 2.8 SegmentsWe would like a mechanism to divide up large databases, to provide different perspectives or subsetsof the data to different users or application programs. In this section we discuss a mechanism toprovide this separation: segments. A segment is a set of entities and relationships that a databaseclient chooses to treat as one logical and physical part of a database.In introducing segments, we will slightly change the definition of an entity, previously defined to beuniquely determined by its domain and name. We will treat entities with the same name anddomain in different segments as different entities, although they may represent the same externalentity. The unique identifier of an internal entity is now the triple[segment, domain, name]. A consequence of this redefinition of entities is that relations and domains do not span segments,either. Application programs must maintain any desired correspondence between entities, domains,or relations with the same name in different segments. We will return to this later. In the nextsection, we will discuss a more powerful but more complex and expensive mechanism, augments, inwhich the database system itself maintains the correspondence.ЪН)О[{ptТF ptpt ptptpТXtТFptНpНjОS═ТмПWТнНjОQkТцПDТдНjОO7Т║Т╒spП5НjОMТ⌠ПVТ■НjОJнТ┐twtП(Т└П(НjОH≥Т▒П.Т▓ps pspНjОFeТ╦ПHТ╧НjОD1Т∙Т√ПJНjОAЭТЦПIТДНjО?хТ░Т▒ПJНjО=⌠ТПXНjО;_Т╛П!spП'ТґНjО9*Т┬П3Т┴spНjО6ЖТэП.ТщspspНjО4аТ─ПVН:FpТНjО1╧Т└Т┘ПVНjО/┘Т┌ПaТ┐НjО-PТЯПRТР НjО+ТгП(ТхП7НjО(ХТ─ПFН2pТНjО"▒rТ─НjО┴pТ┐П:Т└П*НjОTТ╘ПbНjО Т·Т÷spПCНjОКТ─ПGНjОЦpТ▄Т█ПNНjО╞ТхПLТи НjОzТЄПEТ╣НjОFТ─ПFН`О>pН6pТНjО 6Т╘П6Т╙П,НjОТ⌡ПNТ°НjОмТ╚П7Т╛rp НjО≤Т■ПSspНjОdТ─П=s·Mv?Q\∙>CYPRESS DATA MODEL CONCEPTS19We introduce three new operations to the data model in conjunction with segments:DeclareSegment[segment, file]: opens a segment with the given name, whose data isstored in the given file.GetSegments[] returns a list of all the segments which have been opened.SegmentOf[entity or relationship] returns the segment in which a given entity orrelationship exists. It may also be applied to relations or domains, since they are entities.With the addition of segments to the data model, we redefine the semantics of the basic accessoperations as follows:1.DeclareDomain and DeclareRelation take an additional argument, namely the segment inwhich the defined domain or relation will reside. The entity representing a domain orrelation now represents data in a particular segment.2.DeclareEntity and DeclareRelationship are unaffected: they implicitly refer to thesegment in which the respective domain or relation was defined. By associating a segment(and therefore a transaction and underlying file) with each relation or domain entityreturned to the database client, we conveniently obviate the need for additional argumentsto every invocation of the basic operations in the data model.3.DestroyEntity, DestroyRelationship, GetF, SetF, DomainOf, RelationOf, and Eq aresimilarly unaffected: they deal with entities and relationships in whatever segment they aredefined. Note that by our definition, entities in different segments are never Eq. Also notethat nothing in our definition makes a SetF across a segment boundary illegal (i.e.SetF[relationship, attribute, entity] where the relationship and entity are in differentsegments). Our current implementation requires that special procedures GetFR and SetFR be used onattributes that can cross segment boundaries, see Section 3.4.DomainSubset and RelationSubset are unchanged when applied to client-defined domainsor relations, i.e., they enumerate only in the segment in which the relation or domain wasdeclared. However an optional argument may be used when applied to one of the systemdomains or relations (e.g. the Domain domain), allowing enumeration over a specificsegment or all segments. RelationSubset's attribute-value-list arguments implictly indicate the appropriatesegment even for system relations, so a segment is not normally needed unless the entire relation isenumerated.Note that the data in a segment is stored in an underlying file physically independent from othersegments, perhaps on another machine. Introducing a file system into the conceptual data modelН+О[5ptpТXtptptН;РpНОSZТ─ПQНЖОO~uТиpП!ТйНЖОMIТ─НЖОInu pП:НЖОE▓uТП"p ТП#НЖОC]ТїПTТ╗ НО>ўТ©ТюПMНОН·О#╛НЖuТЛП9ТМ pupНЖО!wТ┼Т▀ПBНЖОCТ│Т┌П=upНЖОТЫТЗП@НЖОзuТГП&pП2НЖО╔ТЎtПAТ©НЖОqТ─П<Н·О∙pНЖupТ┌u pТ┐П5НЖОaТ°П?Т²НЖО,Т≈Т≤П@НЖОЬТМПJТННЖО цТ≈tПTНЖО╡ТЕТФПXНЖО║ НО≥pТ╗П?Т╘П"НОdТґП_ Ї╪>Q\ODESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL20may seem like an odd transgression at this point. From a practical point of view, however, webelieve it better to view certain problems at the level of file systems. This point of view allowssegments to be used for the following purposes:1.Physical independence: Different database applications typically define their data inseparate segments. As a result one application can continue to operate although the datafor another has been logically or physically damaged. One application can entirely rebuildits database without affecting another, or an application can continue to operate in adegraded mode missing data in an unavailable segment.2.Logical independence: Different database applications may have information which pertainsto the same external entity, e.g. a person with a particular social security number. Whenone application performs a DestroyEntity operation, however, we would like the entity todisappear only from that application's point of view. Information maintained by otherapplications should remain unchanged. 3.Protection: Clients can trust the protection provided by a file system more easily than acomplex logical protection mechanism provided by the database system. An even higherassurance of protection can be achieved by physical isolation of the segment at a particularcomputer site. A more complex logical protection mechanism would be desirable for somepurposes, but was deemed beyond the scope of Cypress.4.Reliability: Because segment files are physically as well as logically separate, the probabilityof simultaneous physical failure is lower than for data in the same file. An even higherdegree of independence can be achieved using segments at different sites. Replication ofdata can be provided at the level of segments to provide recovery from failure. Ourimplementation's file systems do not do this, however.5.Performance: Data may be distributed to sites where they are most frequently used. Forexample, personal data may reside on a client's machine while publicly accessed data resideon a file server. If the file system provides replication, it can be used to improveperformance for commonly accessed data.Concurrency control may also be handled by the file system, although locks should be at agranularity finer than whole segments (e.g., file pages). As noted earlier, information about an external entity may be distributed over multiple segments.One or more database applications may cooperate in maintaining the illusion that entities, domains,and relations span segment boundaries. This illusion may be used in at least two ways:1.Private additions may be added to a public segment by adding entities or relationships in aprivate segment. The new relationships may reference entities in the public segment byН)О\∙ptТF ptpt ptptpТXtТFptНpНjОT╨Т╪П7ТҐП'НjОR┘Т╣ПcНjОPQТ─П/НОLuН`sТpТП@Н`ОJAТ╔ТіПFН`ОHТ■ПJТ∙Н`ОEьТЮПIТАН`ОCёТ─П5НО?гН`sТ┴pП"Т┼П$Н`О=⌠Т╔ПLТі Н`О;_ТґspТўН`О9*ТйП&ТкП0Н`О6ЖТ─П%Н.ТНО3Н`s pТ╙П1Т╚Н`О0ЕТўПFТ╞Н`О.╠Т▓ПOТ⌠Н`О,}Т▐ Т░ПIН`О*HТ─П5НО&lН`s pТ└Т┘П>Н`О$8ТёП#ТєП7Н`О"ТїП&Т╗П3Н`ОоТшП8ТэtН`О⌡Т─П6НО©pН`spТ·ПHТ÷Н`О┼Т▄П/Т█П,Н`ОVТКПEТЛН`О!Т─П'НjОТЛПQТМНjО ЕТ─П9Н)ЎТНjО щТ╟ПNТ╠НjО╗Т√П!Т≈ПBНjОtТ─ПWНО≤Н`Т█П*Т▌П1Н`ОdТІТЇПF"M \?Q]╞3CYPRESS DATA MODEL CONCEPTS21creating representative entities with the same name in the private segment. An examplewould be personal phone numbers and addresses added to a public database of phonenumbers and addresses: an application program would make the two segments appear tothe user as one database.2.If two applications use separate segments A and B, they may safely reference each other'sdata yet remain physically independent. One of the applications may destroy andreconstruct its segment if it uses the same unique names for its entities. If both applicationshave relationships referencing an entity e, and application A does a DestroyEntity operationon e, the entity and relationships referencing it disappear from application A's point ofview, but application B's representative entity and relationships remain.2.9 AugmentsIn this section, we discuss a more elaborate mechanism for segmenting databases, with morepowerful properties. We call these augments, because they are "additive" segments as we will see.Entities, domains, and relations are defined independently of augments. An entity with the samename and domain appears as the same entity regardless of particular augments in which data arestored. However, the entity may or may not be defined in a particular augment. Also, relationshipscontinue to be associated with a particular segment.NOTE: The ideas in the remainder of Section 2 have not been implemented, they are included forfuture interest. These features are not discussed again in this report except for Section 5.10, incontrasting data models. Augments are intended for two main purposes:1.Additive databases: Information about an entity may be distributed among multipleaugments. The database system will make all the augment boundaries invisible, i.e. all thedata will appear as if it is one augment from the application program's point of view.2.Subtractive databases (versions): The relations in an augment encode some state of theworld the database represents. Updates, representing changes to that state, can be made byadding them in a separate augment. The database may then be viewed with and withoutthe changes (or a number of alternate changes) by adding and removing the augment(s) ontop.The operations on augments themselves appear very similar to those on segments. However, anordering on the open augment list is maintained by the database system. The DeclareAugment callЪН+О[бptpТXtptptН;РpНЖОSГТЄПBТ╣НЖОQ╡ТиП6ТйНЖОO~Т╒П4ТёНЖОMIТ─Н·ОInНЖТ÷П*spspТ═П'НЖОG9Т ПPНЖОEТ│П@Т┌НЖОBпТ┴П)spТ┼spНЖО@°ТцspП-Тдsp НЖО>gТ─spП2НО8rНО3apТМПZНО1-Т═П$spП&Т║НО.ЬТґТўП@НО,дТ╞ПCТ╟НО*▐Т┬ПdНО([Т─П4НО#╚spТ╛sПBТґНО!wТяpТрsПQНОCТ─Н┬pТНО⌠Т─П,Н·ОЇpНЖsТЬpТЫП,НЖО┐Т■Т∙П=НЖОNТ─ПVН·ОspНЖsТцП!pТдП$НЖО>Т┼ПEТ▀НЖО Т╒ПHТёНЖОуТ▐ПWНЖО║НО≥pТ╩ПYТ╪НОdspТ√П@Т≈Ъ ├Ї/?Q\эDESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL22may specify where in the current list the new augment should be opened:DeclareAugment[augment, file, previous augment] opens an augment with the given name, whosedata is stored in the given file. It is defined to appear before the given previous augment in theordering, or at the end if none is given. GetAugments[] returns a list of all the augments whichhave been opened in order. AugmentOf[relationship] may be applied to a relationship todetermine in which augment it is stored.With the addition of augments to the data model, we redefine the semantics of the basic accessoperations as follows:1.DeclareRelation and DeclareDomain return a handle representing the relation or domainin all augments. The relation or domain is declared to exist in the augment passed as anargument; the declare procedure may be called additional times to define the same relationor domain to extend into other augments.2.DeclareEntity and DeclareRelationship create an entity or relationship, respectively, in thetop-most augment in the augment list in which the respective domain or relation is defined.3.GetF, DomainOf, RelationOf, and Eq are unchanged, defined in the obvious way. Anyentities returned by GetF, DomainOf, or RelationOf are of course augment-independent.Eq returns TRUE iff the two entities have the same name and their domains have the samename, regardless of whether the entities are in the same augment.4.SetF is defined as before, with two exceptions. Consider the callSetF[r, a, e]where r is a relationship in augment A, a is an attribute of RelationOf[r] with type T, and eis an entity value in domain D. This call will cause e to exist in A, if it does not already.D must already exist in A. Otherwise, the call fails and nothing is created in A. (The clientmay create D and retry the operation).5.DestroyEntity and DestroyRelationship destroy the given entity or relationship if there isno namesake of the domain or relation higher in the current augment list. Otherwise, theycreate an anti-entity or anti-relationship, respectively, in the top-most client-declarednamesake of the domain or relationship. The semantics of SetF is, in effect, that of aDestroyRelationship followed by a CreateRelationship with the attribute changed.6.DomainSubset searches its domain in all open augments, and has the property that anentity in an augment will not appear in the enumeration if an anti-entity with the samename exists in the entity's domain higher in the current augment list. DomainSubset neverЪН)О\OptТF ptpt ptptpТXtТFptНpНjОTtТЦП<ТД НjОR?uТ┌П0pП%Т┐НjОPТ╗ПcНjОMжТєП*Т╔u pП(НjОK╒ТЭup ТЩНjОImТ─П(НjОDЎpТ╩Т╪ПAНjОB┼Т─НО>ўpН`upТ upП4Н`ОНЧОпuТН`ОТpТ│П%spspТ┌u p spsН`О©pТ√spspТ≈spН`О▀spТ─spТ│П!spН`ОVТ─ spНО{Н`upТ²upП5Н`ОFТ▌П;Т▐Н`О Т s pspТП.Н`О щТҐТЎП$upН`О╘upТ─upНОмН`upТюПDТаН`О≥Т╣ПNТІН`ОdТ─ Т│П=upЪ M ╒?Q]iICYPRESS DATA MODEL CONCEPTS23returns the same entity twice, even though it exists in more than one augment.7.RelationSubset similarly searches its relation in all open augments, and has the propertythat a relationship in an augment will not appear in the enumeration if an anti-relationshipwith the same attribute values exists in the relationship's relation higher in the currentaugment list.Augments act specially upon relations upon which keys have been defined: 1.If a CreateRelationship would create a relationship with the same key value as an existingrelationship in the relation in some open augment, then an anti-relationship is automaticallycreated for the existing relationship (in the same augment as the new relationship, the top-most one possible) before creating the new one.2.If an augment is opened containing relationships whose key values match existing ones inopen augments, then anti-relationships for the matching existing relationships areautomatically created in the newly opened augment at that time.The net effect of our definition of augments is that a user or program may make arbitrarymodifications to data in an underlying augment, in a fashion which appears exactly as if a singleaugment contains all the data. The underlying augment, however, is completely unchanged. Theunmodified data in the underlying augment may concurrently be examined by another user, orappear to be modified through another user's augment. Furthermore, the modifications made by thesame user over time are separated and can later be removed.Note that two augments can be merged in a straightforward way to produce an augment thatbehaves as the two in the same order in the same place in the current augment list. The augmentsare merged by combining the elements of the relations and domains in the two augments, discardingentities and anti-entities that match and relationships and anti-relationships that match.Augments are not related in definition or implementation to the atomic transactions that animplementation of the model also provides. However, the reader might find it informative to thinkof a transaction as an augment defined on top of the current data, which is automatically mergedwith the data when the transaction is committed. Transactions thus serve as "short-term" augments.The two mechanisms are useful for entirely different purposes in practice, however.Н+ОR╘ptpТXtptptН;РpНЖОJнТ─ПNН·ОFРНЖu pТ╘П#Т╙П(НЖОDҐТ▐Т░ПFНЖОB┴ТкПRТлНЖО@UТ─НО;╔ПHН1≤ТН·О7иНЖТ▄upТ█П4НЖО5∙Т┤Т┬П>НЖО3`Т■П2Т∙П*НЖО1,Т─П/Н·О-PНЖТ║П"Т╒П6НЖО+ТEПNТFНЖО(ГТ─П?НО$8ТК ТЛПKНО"Т╠ПCsТ╡НОоТґТўpПAНО⌡ТлПZНОfТ┌П,Т┐П5НО2Т─П;НО┌ТуТжПOНОNТ⌠ПSТ■ НОТ├ПDТ┤НО ЕТ─ПZНО 5ТТП&ТУП5НОТ▓Т⌠ПBНОмТ╗П-Т╘П3НО≤Т█П"Т▌ПAНОdТ─ПSЪ VЇH?QSцЛDESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL242.10 ViewsA view is a relation whose relationships are not actually stored. Instead, the primitive retrieval andstorage operations on a view invoke procedures defined by a database client who defines the view.Arbitrary procedures may be defined, and views can therefore be used for a variety of purposes:1.Defining a pseudo-relation in terms of existing relations for convenience: e.g., a fatherview could be implemented in terms of parent and sex relations that are actually stored.2.Allowing changes to the logical representation of data (e.g., actually changing the databaseto store father and mother relations instead) without changing existing programs written interms of the older form.3.Implementing operations on entities in an object-based style by storing tuples in a view.E.g., a Send operation on a Message entity might be invoked by storing a tuple in a sendrelation with two attributes, the message and the recipient. Any result of such a sendoperation would be stored in the database (e.g. as a third attribute of the send relationshipreturned). Thus the view mechanism provides a basis for encoding of proceduralinformation in a database.Views are so-called because they provide a database client a different view of the database than whatwas originally stored. View definitions and implementations are stored in a database as any otherdata, being automatically retrieved when required by the database system.The implementor of a view must define the same operations as needed for any relation. Unlikeview mechanisms in some database systems, views may be defined directly in the underlyingprogramming language. In our case, this is Cedar, and the operations the implementation mustexport are defined as a Cedar interface exported by the view. The view can be dynamically loadedwhen required at run-time. The operations the view provides are:1.RelationSubset and CreateRelationship on the view2.DestroyRelationship, RelationOf, GetF and SetF on its relationshipsA view may also be defined at a higher level than the underlying programming language, in a querylanguage; this simplifies the definition of views as well as allowing some kinds of optimizations thatneed no longer treat a view as a "black box" implementation of an access definition.2.11 SummaryWe have introduced the three basic primitives of the Cypress data model: entity values, datumvalues, and relationships. The basic type checking provided by the model insures that the attributesof relationships are of the proper entity or datum types. Relationship types are called relations.ЪН)О]"ptТF ptpt ptptpТXtТFptНpНjОUGrТ─ НjОR?pТ≈spП;Т≤П&НjОP Т²Т·ПJНjОMжТ╠П2Т╡П-НОIЗН`Т╩ПSТ╪uН`ОGеpТ─П&upupП$НОCЙН`Т°Т²ПLН`ОA╣Т█upupП6Т▌ Н`О?│Т─НО;╔Н`ТІПYН`О9qТ├upТ┤upП1uН`О7ТлП9ТмП%НО Т╠П#Т╡П<НОуТ─ПCНОмТ┬ПVТ┴НО≤Т╧П[Т╨НОdТ─П5ЪЇ5>Q2В⌡273. Model Level InterfaceWe now describe the Cedar interface to the implementation of the Cypress data model. Aknowledge of the Cedar or Mesa programming language (Mitchell et al [1979]) and the Cedarprogramming environment is not essential to understanding this section. We will explain Cedarfeatures as they are encountered.We do assume that the reader is familiar with the basic conceptual data model, i.e., has read theprevious section. Our presentation is therefore slightly different in this section: we describe theprocedures in the database interface in roughly the order that a client will want to use them in aprogram. We present types and initialization, schema definition, the basic operations, and thenqueries. It should be emphasized that the interface we are about to describe is only one possibleimplementation of the abstract data model described in Section 2. For example, we have chosen toimplement a procedural interface called by Cedar programs, and to do type checking at run-time.We will discuss some of the trade-offs in our choice of interface in Section 6. The introduction ofnew interfaces, such as a Query level with a compiled access language, will provide a differentperspective on the Cypress data model.3.1 TypesIn this subsection we describe the most important types in the interface. Less pervasive types aretreated at the point where they are first used.Entity: TYPE;Relship: TYPE;An Entity or Relship is not the actual database entity or relationship; they are handles for the actualdatabase objects. All accesses to database objects are performed by calling interface procedures withthe handles as parameters. Even comparisons of two entities for equality must be done in this way.The Entity and Relship handles are allocated from storage and automatically freed by the garbagecollector when no longer needed.Value: TYPE = REF ANY;ValueType: TYPE;Datatype: TYPE;StringType, IntType, BoolType, AnyDomainType: DataType;НG╘ОfЯpНЇО^оqТНЇОZСpТЛПHТМНЇОX©ТсП=ТтНЇОV┼ТаПXТбНЇОTVТП!НЇОPzТґП(ТўП9НЇОNFТ╡ПKТЁНЇОLТ╗П'Т╘П;НЇОIщТхТиПFНЇОG╗ТНЇОCмТТП<НЇОA≤Т░П>Т▒П#НЇО?dТ╙П*Т╚П5НЇО=/Т≤ПLТ≥НЇО:ШТиТйПFНЇО8фТП&НЇО2prНЇО.■pТ╔ПYТі НЇО,_ТП/Н хО(└sТXН хО&O НЇО"spТ┘spspТ├П:tpНЇО ?Т┬Т┴ПTНЇОТ▌П3Т▐П0НЇОжТ═spspП'Т║П#НЇО╒ТН хОфsТXН хО▒Н хО]Н хО)П7ЪўЇБ?QY)эDESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL28Storing Cedar data values in tuples presents several problems. First, since we would like to define asingle operation to store a new value into a specified attribute of a Relship (for instance), there mustbe a single type for all values that pass through this "store-value" procedure. This is the type Valueabove, represented as untyped REFs in Cedar (a REF is a garbage-collectable Cedar pointer). TheDataTypes will be discussed in the next section. Entities, strings, integers, and booleans are thetypes of values the system currently recognizes and allows as attribute values. More precisely, thesefour types are Entity, ROPE (the Cedar name for "heavy-duty" strings), REF INT, and REF BOOL.In the case of an entity-valued attribute, an attribute's type may be AnyDomainType or a specificdomain may be specified. The latter is highly preferred, as AnyDomainType is a loophole in thetype mechanism and limits the kinds of operations that can be performed automatically by thedatabase system or associated tools. We currently provide no mechanism to store compound Cedardata structures such as arrays, lists, or records in a database; the database system's data structuringmechanisms should be used instead. (Cypress query operations such as RelationSubset cannot becomposed upon data that appears as uninterpreted bits in the database. We return to this issue inSection 4.)Note that a Value may be either an Entity or a Datum. Some operations accept any Value, e.g.SetF; others require an Entity, e.g. NameOf. Others may require an Entity from a particular client-defined domain, e.g. a Person. We might think of the hierarchy of built-in and client defined typesand instances of values like this:Value type hierarchyDatabase representative of typeValue (REF ANY)ValueType Datum DatumType ROPE StringType INT IntType BOOL BoolType Entity AnyDomainType person Entity Person domain employee Entity Employee domain ... other client-defined entities ... ... other client-defined domains ...As Cedar doesn't have a good mechanism for defining type hierarchies or new types for client-defined domains, most Cypress operations simply take a REF ANY or an Entity as argument,performing further type checking at run-time.ЪНvОfЯpuТF pupu pupupТXuТFpuНMpНЇО_Т┤ПLТ┬НЇО\АТ┌ПFspТ┐ НЇОZґТ┘Т├П^sНЇОXxpТ sp spП)Т⌡НЇОVDspТЁТЄПHНЇОTТ▐Т░ПWНЇОQшТ█spspТ▌П'spspНЇОOїТ╒ ТёП;sp НЇОMrТєП=spНЇОK>ТкП&ТлП6НЇОI Т■П%Т∙П:НЇОFуТ÷ПMТ═НЇОD═Т╛ТґПEНЇОBlТ°П_Т²НЇО@7Т НЇО<\Т╘spspspТ╙spНЇО:'spТ┬spspТ┴spНЇО7СТ┘spТ├П6НЇО5ЎТП"НО/ДЧYО0;rТ─Н%ЮО/ДЧ─О0;rН+`О/ДЧпО0;ТНО.sТ─Н%ЮНО+рН%ЮТ НО)·Т─Н%ЮТ НО'iТ─Н%ЮТ НО%5Т─Н%ЮТНО#Т─Н%ЮТНО лpТ─ sН%ЮpТspНО≤Т─sН%ЮpТspНОcТ─П)Н%ЮТП(НЇО┤ТаТбПAНЇОSТыП(ТзspspНЇОТП-Ъ $Mь?QT3YMODEL LEVEL INTERFACE293.2 Transactions and segmentsIn this section we describe the basic operations to start up a database application's interaction withCypress. The client application's data is stored in one or more segments, accessed undertransactions. The Cypress system currently runs on the same machine as the client program,however transactions are implemented by the underlying file system which may reside on anothermachine. Data in remote segments may therefore be concurrently accessed by other instances ofCypress on other client machines.A transaction is a sequence of read and write commands. The system supports the property that theentire sequence of commands executes atomically with respect to all other data retrieval and updates,that is, the transaction executes as if no other transactions were in progress at the same time.Because there may in fact be other transactions accessing the same data at the same time, it ispossible that two transactions may deadlock, in which case one of them must be aborted. So theprice paid for concurrent access is that programs be prepared to retry aborted transactions.The database system provides the capability of accessing a database stored on the same machine asthe database client, using the Pilot file system (Redell et al [1979]), or on Alpine file servers (Brownet al [1983]). We currently permit only one transaction per segment per instance of the databasesoftware on a client machine. That is, data in remote segments may concurrently be updated byapplication programs under separate transactions, but on the same machine transactions are usedsimply to make application transactions on their respective segments independent. This transaction-per-segment scheme is a major simplification of the Cypress package. In addition, as we shall seepresently, nearly all Cypress procedures can automatically infer the appropriate segment andtransaction from the procedure arguments, avoiding the need to pass the transaction or segment forevery database operation. Calls to Initialize, DeclareSegment, and OpenTransaction start the database session. Atransaction is either passed in by the client, or created by the database package (the latter is just aconvenience feature). The operation MarkTransaction below forms the end of a databasetransaction and the start of a new one. The operation AbortTransaction may be used to abort atransaction. Data in a database segment may not be read or updated until the segment andtransaction have been opened. Clients must decide when to tell the system that a transaction iscomplete (with CloseTransaction), and must be prepared to deal with unsolicited notification thatthe current transaction has been aborted because of system failure or lock conflict.The client's interaction with the database system begins with a call to Initialize:ЪН"SОfЯpuТFpupuНG╘pНЇО_rТНЇО[:pТ²ПfНЇОYТПSТ НЇОVяТЮТАПIНЇОT²Т╚Т╛ПFНЇОRhТЁПKТЄНЇОP4ТП!НЇОLXТ├Т┤ПDНЇОJ#Т└П%t pТ┘П1НЇОGОТтП*ТуП6НЇОE╩ТдТеПFНЇОC├Т·ПFТ÷НЇОARТП\НЇО=vТ П^Т⌡НЇО;AТ█Т▌ПJНЇО9 ТґП<ТўП%НЇО6ыТ╞П^НЇО4єТҐТЎПEНЇО2pТ▓ Т⌠ПVНЇО0;Т║П,Т╒П6НЇО.ТЪПXТНЇО+рТ√ПVТ≈НЇО)·ТНЇО%бТ!spspТ"НЇО#▌Т²П`Т·НЇО!YТ ТspП"НЇО%Т╔П7spТіНЇОПТщП3ТчП&НЇО╪Т╦П?Т╧П!НЇО┤Т÷sp Т═П4НЇОSТПTНЇОwПHs &Ї0?QUшDESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL30Initialize: PROC[ nCachePages: CARDINAL_ 256, nFreeTuples: CARDINAL_ 32, cacheFileName: ROPE_ NIL ];Initialize initializes the database system and sets various system parameters: nCachePages tells thesystem how many pages of database to keep in virtual memory on the client's machine,nFreeTuples specifies the size to use for the internal free list of Entity and Relship handles, andcacheFileName is the name of the disk file used for the cache backing store. Any or all of thesemay be omitted in the call; they will be given default values. Initialize should be called before anyother operation; the schema declaration operations generate the error DatabaseNotInitialized if thisis violated.Before database operations may be invoked, the client must open the segment(s) in which the dataare stored. The location of the segment is specified by using the full path name of the file, e.g."[MachineName]SubDirectory>SegmentName.segment". Each segment has a uniquename, the name of a Cedar ATOM which is used to refer to it in Cypress operation. The name ofthe Cedar ATOM is normally, though not necessarily, the same as that of the file in which it isstored, except the extension ".segment" and the prefix specifying the location of the file is omitted inthe ATOM. If the file is on the local file system, its name is preceded by "[Local]". For example,"[Local]Foo" refers to a segment file on the local disk named Foo.database;"[Alpine]Baz" refers to a segment named Baz.segment on the directory onthe Alpine server. It is generally a bad idea to access database segments other than through thedatabase interface. However, because segments are physically independent and contain no referencesto other files by file identifier or explicit addresses within files, the segment files may be movedfrom machine to machine or renamed without effect on their contents. If a segment file in a set ofsegments comprising a client database is deleted, the others may still be opened to produce adatabase missing only that segment's entities and relationships. A segment is defined by theoperation DeclareSegment:DeclareSegment: PROC[ filePath: ROPE, segment: Segment, number: INT_ 0, readOnly: BOOL_ FALSE, version: Version_ OldOnly, nBytesInitial, nBytesPerExtent: LONG CARDINAL_ 32768] RETURNS [Segment];Segment: TYPE = ATOM;Version: TYPE = {NewOnly, OldOnly, NewOrOld};The version parameter to DeclareSegment defaults to OldOnly to open an existing file. The signalНvОfЯpuТF pupu pupupТXuТFpuНMpН хО_sТXН хО\АН хОZґН хОXxНЇОT² pТ▀Т▄П&spНЇОRhТ ТПJНЇОP4s pТ╔ТіП#spspНЇОMЪspТ ПKТ⌡НЇОKкТ▌П.Т▐s pНЇОI√Т▒ПFspТ▓НЇОGbТНЇОC├Т°ПNТ²НЇОARТўП8Т╞П+НЇО?ТПOТНЇО<ИТ∙spП4Т√НЇО:ЄТ╦ spП%Т╧П,НЇО8─Т─П+Т│П=НЇО6KТ∙sp Т√ПNНЇО4ТГП7ТХНЇО1ЦТ╡ПZНЇО/ўТ╟Т╠ПKНЇО-zТ┌ПMТ┐НЇО+EТЄ Т╣ПVНЇО)Т▐П*Т░П9НЇО&эТуП<ТжП!НЇО$╗ТДП]НЇО"sТ s pН хО≤sТXН хОcП3Н хО/П3Н хОЗП7Н хОфН хОЙН хОІП-НЇОзpТ┐sp s pspТ└Ъ M⌠?Q\xMODEL LEVEL INTERFACE31IllegalFileName is generated if the directory or machine name is missing from fileName, andFileNotFound is generated at the time a transaction is opened on the segment if the file does notexist. If version NewOnly is passed, a new segment file will be created, erasing any existing one. Inthis case, a number assigned to the segment by the database administrator must also be passed. Thisnumber is necessitated by our current implementation of segments (it specifies the section of the database address space inwhich to map this segment). Finally, the client program can pass version=NewOrOld to open a new orexisting segment file; in this case the segment number must also be passed, of course.The other parameters to DeclareSegment specify properties of the segment. If readOnly=TRUE,then writes are not permitted on the segment; any attempt to invoke a procedure which modifiesdata will generate the error ProtectionViolation. nBytesInitial is the initial size to assign to thesegment, and nBytesPerExtent is the incremental increase in segment size used when more space isrequired for data in the file.For convenience, a call is available to return the list of segments that have been declared in thecurrent Cypress session: GetSegments: PROC RETURNS[LIST OF Segment ];A transaction is associated with a segment by using OpenTransaction: OpenTransaction: PROC[ segment: Segment, userName, password: ROPE_ NIL, useTrans: Transaction_ NIL ];If useTrans is NIL then OpenTransaction establishes a new connection and transaction with thecorresponding (local or remote) file system. Otherwise it uses the supplied transaction. The sametransaction may be associated with more than one segment by calling OpenTransaction with thesame useTrans argument for each. The given user name and password, or by default the logged inuser, will be used if a new connection must be established.Any database operations upon data in a segment before a transaction is opened or after a transactionabort will invoke the Aborted signal. The client should catch this signal on a transaction abort,block any further database operations and wait for completion of any existing ones. Then the clientmay re-open the aborted transaction by calling OpenTransaction. When the remote transaction issuccessfully re-opened, the client's database operations may resume.Note that operations on data in segments under different transactions are independent. Normallythere will be one transaction (and one or more segments) per database application program. A clientmay find what transaction has been associated with a particular segment by callingН"SОfЯpuТFpupuНG╘pНЇО_spТзП.ТшspНЇО\АspТ╒П1ТёП$НЇОZґТ┐spПMНЇОXxТ┤spП6Т┬uНЇОVgТ┌Т┐ПeНЇОTVТ┼p Т▀spНЇОR"ТПVНЇОNFТ≤s pТ≥ spНЇОLТ╛П9ТґП%НЇОIщТ╣spspТІНЇОG╗Т▄spТ█ПAНЇОEtТНЇОA≤ТЄП.Т╣П4НЇО?dТН хО;┬sТXП,НЇО7╛pТП4spН хО3пsТXН хО1°Н хО/hН хО-3НЇО)WpТІspwpspТЇНЇО'#Т║П7Т╒П,НЇО$НТ╟Т╠П5spНЇО"╨Т┴spТ┼ПRНЇО ├ТП;НЇО╙Т└ПXТ┘НЇОuТЄТ╣spsp spП0НЇОAТ▀ПdНЇОТ П/spТ⌡НЇОьТПDНЇОЭТ╚ПEТ╛НЇО хТ─П"Т│ПBНЇО⌠ТПR ^ЇL?Q\©DESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL32TransactionOf: PROC [segment: Segment] RETURNS [Transaction];Transactions may be manipulated by the following procedures:MarkTransaction: PROC[trans: Transaction];AbortTransaction: PROC [trans: Transaction];CloseTransaction: PROC [trans: Transaction];MarkTransaction commits the current database transaction, and immediately starts a new one. Uservariables which reference database entities or relationships are still valid.AbortTransaction aborts the current database transaction. The effect on the data in segmentsassociated with the segment is as if the transactions had never been started, the state is as it was justafter the OpenTransaction call or the most recent MarkTransaction call. Any attempts to usevariables referencing data fetched under the transaction will invoke the NullifiedArgument error. Acall to OpenTransaction is necessary to do more database operations, and all user variablesreferencing database items created or retrieved under the corresponding transaction must be re-initialized (they may reference entities or relationships that no longer exist, and in any case they aremarked invalid by the database system).A simple client program using the database system might have the form, then:Initialize[];DeclareSegment["[Local]Test", $Test];OpenTransaction[$Test];...... database operations, including zero or more MarkTransaction calls ......CloseTransaction[TransactionOf[$Test]];3.3 Data schema definitionThe definition of the client's data schema is done through calls to procedures defined in this section.The data schema is represented in a database as entities and relationships, and although updates tothe schema must go through these procedures to check for illegal or inconsistent definitions, theschema can be read via the normal data operations described in the next section. Each domain,relation, etc., has an entity representative that is used in data operations which refer to that schemaitem. For example, we pass the domain entity when creating a new entity in the domain. The typesНvОfЯpuТF pupu pupupТXuТFpuНMpН хО_sТXП=НЇО[:pТП<Н хОW^sТXП*Н хОS┌П,Н хОOїП,НЇОKкpТ└ПLТ┘НЇОI√ТПMНЇОE╩spТрПMНЇОC├Т┴ПWТ┼НЇОARТҐ spТЎspНЇО?Т▄П,Т█sp НЇО<ИТМspТНПDНЇО:ЄТлП5ТмП*НЇО8─Т▌ПOТ▐НЇО6KТП'НЇО2pПLНґО.■sНґО,_П%НґО*+НґО'ВНґО%бpПIНґО#▌sНґО!YП'НЇОrНЇО'pТ├Т┤ПVНЇОРТ²П,Т·П-tpНЇОЎТ╩П]Т╪НЇО┴ТЄ Т╣tpПLНЇОUТ√ПgНЇО Т┐Пb4Mы?Q\2ъMODEL LEVEL INTERFACE33of schema items are:Domain, Relation, Attribute, Datatype, Index, IndexFactor: TYPE = Entity;Of course, since the schema items are entities, they must also belong to domains; there are pre-defined domains, which we call system domains, in the interface for each type of schema entity:DomainDomain, RelationDomain, AttributeDomain, DatatypeDomain, IndexDomain: Domain;There are also pre-defined system relations, which contain information about sub-domains, attributes,and indices. Since these are not required by the typical (application-specific) database client, wedefer the description of the system relations to Section 3.6. In general, any of the data schema may be extended or changed at any time; i.e., data operationsand data schema definition may be intermixed. However, there are a few specific orderingconstraints on schema definition we will note shortly. Also, the database system optimizes for betterperformance if the entire schema is defined before any data are entered. The interactive schema editingtool described in Section 7 allows the schema to be changed regardless of ordering constraints and existing data, byrecreating schema items and copying data invisibly to the user when necessary.All the data schema definition operations take a Version parameter which specifies whether theschema element is a new or existing one. The version defaults to allowing either (NewOrOld): i.e.,the existing entity is returned if it exists, otherwise it is created. This feature avoids separateapplication code for creating the database schema the first time the application program is run. DeclareDomain: PROC [name: ROPE, segment: Segment, version: Version_ NewOrOld, estRelations: INT_ 5] RETURNS [d: Domain];DeclareSubType: PROC[sub, super: Domain];DeclareDomain defines a domain with the given name in the given segment and returns itsrepresentative entity. If the domain already exists and version=NewOnly, the signal AlreadyExistsis generated. If the domain does not already exist and version=OldOnly, then NIL is returned.The parameter estRelations is used to estimate the largest number of relations in which entities ofthis domain are expected to participate.The client may define one domain to be a subtype of another by calling DeclareSubType. Thispermits entities of the subdomain to participate in any relations in which entities of thesuperdomains may participate. All client DeclareSubType calls should be done before declaringrelations on the superdomains (to allow some optimizations). The error MismatchedSegment isgenerated if the sub-domain and super-domain are not in the same segment.ЪН"SОfЯpuТFpupuНG╘pНЇО_ТН хО[:sТXПIНЇОW^pТ╦ПEТ╧НЇОU*Т╩Т╪t pП2Н хОQNsТXПSНЇОMrpТ┌ПYТ┐НЇОK>Т╣ТІПGНЇОI ТП=uНЇОE-pТ╔ТіПNНЇОBЫТРПPТСНЇО@еТ┬П6Т┴П0НЇО>░Т≥ПJuТ НЇО<ТЄТ╣ПcНЇО:nТПNНЇО6▓pТцП.ТдspП&НЇО4^Т▀Т▄ПMНЇО2)ТсТтПQНЇО/УТфТгПPТН хО,sТXП2Н хО)ДПHН хО& П)НЇО"-pТуТжsp spНЇОЬТ▓upТ⌠П0sНЇОдpТ╣П7ТІspspspНЇО░Т≈ spТ≤ПIНЇО[ТП(НЇОТ╘П>Т╙s pНЇОKТТПJНЇОТ╡ТЁs pП&НЇОБТОupx spНЇОўТПIЪ ^Їg@Q[є DESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL34DeclareRelation: PROC [ name: ROPE, segment: Segment, version: Version_ NewOrOld] RETURNS [r: Relation];DeclareAttribute: PROC [ r: Relation, name: ROPE, type: ValueType_ NIL, uniqueness: Uniqueness _ None, length: INT_ 0, link: {Linked, Unlinked, Colocated, Remote}_ yes, version: Version_ NewOrOld] RETURNS[a: Attribute];Uniqueness: TYPE = {NonKey, Key, KeyPart, OptionalKey};DeclareRelation defines a new or existing relation with the given name in the given segment andreturns its representative entity. If the relation already exists and version=NewOnly, the signalAlreadyExists is generated. If the relation does not already exist and version=OldOnly, then NILis returned.DeclareAttribute is called once for each attribute of the relation, to define their names, types, anduniqueness. If version=NewOrOld and the attribute already exists, Cypress checks that the newtype, uniqueness, etc. match the existing attribute. The error MismatchedExistingAttribute isgenerated if there is a discrepancy. The attribute name need only be unique in the context of itsrelation, not over all attributes. Note this is the only exception to the data model's rule that names be unique in adomain. Also note that we could dispense with DeclareAttribute altogether by passing a list into the DeclareRelationoperation; we define a separate procedure for programming convenience.The attribute type should be a ValueType, i.e. it may be one of the pre-defined types (IntType,StringType, BoolType, AnyDomainType) or the entity representative for a domain. For pre-defined types, the actual values assigned to attributes of the relationship instances of the relationmust have the corresponding type: REF INT, ROPE, REF BOOL, or Entity. If the attribute has adomain as type, the attribute values in relationships must be entities of that domain or some sub-domain thereof. The type is permitted to be one of the pre-defined system domains such as theDomainDomain, thereby allowing client-defined extensions to the data schema (for example, acomment for each domain describing its purpose). The attribute uniqueness indicates whether the attribute is a key of the relation. If its uniquenessis NonKey, then the attribute is not a key of the relation. If its uniqueness is OptionalKey, then thesystem will ensure that no two relationships in r have the same value for this attribute (if a value hasbeen assigned). The error NonUniqueKeyValue is generated if a non-unique key value results froma call to the SetP, SetF, SetFS, or CreateRelship procedures we define later. Key acts the same asOptionalKey, except that in addition to requiring that no two relationships in r have the same valuefor the attribute, it requires that every entity in the domain referenced by this attribute must bereferenced by a relationship in the relation: the relationships in the relation and the entities in theЪНvОfЯpuТF pupu pupupТXuТFpuНMpН хО_sТXН хО\АПRН хОYН хОVяП0Н хОT²П1Н хОRhПOН хОP4Н хОLXП7НЇОH|pТ▓Т⌠П"sp spНЇОFHТдПWТе НЇОDspТ≈П;spspТ≤sНЇОAъpТНЇО>spТ²ПUНЇО;оТўspТ╞П$НЇО9 ТБП5ТЦ spНЇО7fТёТєПPНЇО51Т┌П$uТ┐ПNНЇО3 Т╙ПUТ╚НЇО1ТПFНЇО-3pТ╞ spspТ╟П&sНЇО*ЪТьП#pТыНЇО(йТІП>ТЇП'НЇО&√Т─П#xТ│pxpНЇО$aТ╔ТіПEНЇО"-Т╙Т╚spПEНЇОЬspТщПMТчНЇОдТП1НЇОХТ█ s p Т▌ПDНЇОЄТ┌spП3Т┐s p НЇОТ┌П0spТ┐НЇОKТ┤spТ┬НЇОТ┌ spspТ┐spНЇОБs pТ┼ПDspТ▀НЇОўТІПLТЇНЇО yТ∙П2Т√П6√M 2>Q]ы;MODEL LEVEL INTERFACE35domain are in one-to-one correspondence. Finally, if an attribute's uniqueness is KeyPart, then thesystem will ensure that no two relationships in r have the same value for all key attributes of r,though two may have the same values for some subset of them.The length and link arguments to DeclareAttribute have no functional effect on the attribute, butare hints to the database system implementation. For StringType fields, length characters will beallocated for the string within the space allocated for a relationship in the database. There is noupper limit on the size of a string-valued attribute; if it is longer than length, it will be storedseparately from the relationship with no visible effect except for the performance of databaseapplications. The link field is used only for entity-valued fields; it suggests whether the databasesystem should link together relationships which reference an entity in this attribute. In addition, itcan suggest that the relationships referencing an entity in this attribute be physically co-located aswell as linked. Again, its logical effect is only upon performance, not upon the legal operations.DestroyRelation: PROC[r: Relation];DestroyDomain: PROC[d: Domain];DestroySubType: PROC[sub, super: Domain];Relations, domains, and subdomain relationships may be destroyed by calls to the above procedures.Destroying a relation destroys all of it relationships. Destroying a domain destroys all of its entitiesand also any relationships which reference those entities. Destroying a sub-domain relationship hasno effect on existing domains or their entities; it simply makes entities of domain sub no longereligible to participate in the relations in which entities of domain super can participate. Existingrelationships violating the new type structure are allowed to remain. Existing relations and domains may only bemodified by destroying them with the procedures above, with one exception: the operationChangeName (described in Section 3.4) may be used to change the name of a relation or domain.DeclareIndex: PROC [ relation: Relation, indexedAttributes: AttributeList, version: Version];DeclareIndex has no logical effect on the database; it is a performance hint, telling the databasesystem to create a B-Tree index on the given relation for the given indexedAttributes. The indexwill be used to process queries more efficiently. Each index key consists of the concatenated valuesof the indexedAttributes in the relationship the index key references. For entity-valued attributes,the value used in the key is the string name of the entity. The version parameter may be used as inother schema definition procedures, to indicate a new or existing index. If any of the attributes arenot attributes of the given relation then the signal IllegalIndex is generated.Н"SОfЯpuТFpupuНG╘pНЇО_Т░П(Т▒П+sp НЇО\АТЄ Т╣П%sptpspНЇОZґТП<НЇОVяТ·spsp spП0НЇОT²Т╒П6s pspНЇОRhТўПXТ╞НЇОP4Т╪ ТҐП=spНЇОMЪТБТЦПKНЇОKкТґspП9ТўНЇОI√Т Т⌡ПUНЇОGbТ╘Т╙ПRНЇОE-Т╟ПMТ╠Н хОARsТXП#Н хО=vН хО9 П)НЇО5ЎpТ┴ПLТ┼НЇО3┼Т░ПEТ▒П$НЇО1UТ∙Т√ПXНЇО/!Т╟ПTspТ╠НЇО,МТ╪ПEspuТҐНЇО*╦Т┌ПEpП)Т┐НЇО(└ТРПOТС НЇО&Os pТ≈П1Т≤П"Н хО"ssТXН хО ?ПJНЇОcpТ╞П-Т╟П)НЇО/Т≈П-spТ≤spНЇОЗТ▐ПQТ░НЇОфТ≥spП"Т П+НЇО▒Т┌ПAspНЇО]Т░ПHТ▒НЇО)ТП5sp "ЇБ?QY)DESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL36The optimal use of indices, links, and colocation, as defined by DeclareIndex and DeclareAttribute,is complex. It may be necessary to do some space and time analysis of a database application tochoose the best trade-off, and a better trade-off may later be found as a result of unanticipatedaccess patterns. Note, however, that a database may be rebuilt with different links, colocation, orindices, and thanks to the data independence our interface provides, existing programs will continueto work without change.If a relation is expected to be very small (less than 100 relationships), then it might reasonably bedefined with neither links nor indices on its attributes. In the typical case of a larger relation, oneshould examine the typical access paths: links are most appropriate if relationships that pertain toparticular entities are involved, indices are more useful if sorting or range queries are desired.B-tree indices are always maintained for domains; that is, an index contains entries for all of theentities in a domain, keyed by their name, so that sorting or lookup by entity name is quick. Stringcomparisons are performed in the usual lexicographic fashion.DeclareProperty: PROC [ relationName: ROPE, of: Domain, type: ValueType, uniqueness: Uniqueness_ None, version: Version_ NewOrOld] RETURNS [property: Attribute];DeclareProperty provides a shorthand for definition of a binary relation between entities of thedomain "of" and values of the specified type. The definitions of type and uniqueness are the sameas for DeclareAttribute. A new relation relationName is created, and its attributes are given thenames "of" and "is". The "is" attribute is returned, so that it can be used to represent the propertyin GetP and SetP defined in the next section.3.4 Basic operations on entities and relationshipsIn this section, we describe the basic operations on entities and relationships; we defer the operationson domains and relations to the next section.A number of error conditions are common to all of the procedures in this section. Since values arerepresented as REF ANYs, all type checking must currently be done at run-time. The procedures inthis section indicate illegal arguments by generating the errors IllegalAttribute, IllegalDomain,IllegalRelation, IllegalValue, IllegalEntity, and IllegalRelship, according to the type of argumentexpected. The error NILArgument is generated if NIL is passed to any procedure that cannot acceptNIL for that argument. The error NullifiedArgument is generated if an entity or relationship ispassed in after it has been deleted or rendered invalid by transaction abort or close. ЪНvОfЯpuТF pupu pupupТXuТFpuНMpНЇО_Т└ПAspТ┘spНЇО\АТ╗ПHТ╘НЇОZґТҐПPТЎНЇОXxТ╗П0Т╘П4НЇОVDТ▐Т░ПXНЇОTТНЇОP4Т║Т╒ПUНЇОMЪТ≥П:Т П.НЇОKкТ÷ПUТ═НЇОI√ТуПYТжНЇОE╩Т╟П_Т╠НЇОC├Т┴ПGТ┼НЇОARТП=Н хО=vsТXН хО;AП2Н хО9 П;Н хО6ыНЇО2ЩpТ╩Т╪ПHНЇО0хТ┼spspТ▀П5НЇО.■ТїspspТ╗НЇО,_Т┴ Т┼ПXНЇО*+ТspspНЇО#тrП2НЇОЬpТ│ПYТ┌НЇОдТП-НЇОХТ▌П1Т▐П2НЇОЄТ├ s pП6Т┤НЇОТЙП5ТКsНЇОKТЇП,pТ╦s pП#НЇОТ├ Т┤s pspП.НЇОБspТйspП*ТкНЇОўТПWЪ єMg>Q[єMODEL LEVEL INTERFACE37DeclareEntity: PROC[ d: Domain, name: ROPE_ NIL, version: Version_ NewOrOld] RETURNS [e: Entity];DeclareEntity finds or creates an entity in domain d with the given name. The name may beomitted if desired, in which case an entity with a unique name is automatically created. If versionis OldOnly and an entity with the given name does not exist, NIL is returned. If version is NewOnlyand an entity with the given name already exists, the signal NonUniqueEntityName is generated.DeclareRelship: PROC [ r: Relation, avl: AttributeValueList_ NIL, version: Version_ NewOrOld] RETURNS [Relship];DeclareRelship finds or creates a relship in r with the given attribute values. If version isNewOnly, a new relship with the given attribute values is generated. If version is OldOnly, therelship in r with the given attribute values is returned if it exists, otherwise NIL is returned. Ifversion is NewOrOld, the relship with the given attribute values is returned if it exists, otherwiseone is created. If the creation of a new relship violates the key constraints specified byDeclareAttribute, the signal NonUniqueAttributeValue is generated.DestroyEntity: PROC[e: Entity];DestroyEntity removes e from its domain, destroys all relationships referencing it, and destroys theentity representative itself. Any client variables that reference the entity automatically take on thenull value (Null[e] returns TRUE), and cause error NullifiedArgument if passed to database systemprocedures. After an entity is destroyed, its old name may be re-used in creating a new one.DestroyRelship: PROC[t: Relship];DestroyRelship removes t from its relation, and destroys it. Any client variables that reference therelationship automatically take on the null value, and will cause error NullifiedArgument ifsubsequently passed to database system procedures.SetF: PROC[t: Relship, a: Attribute, v: Value];SetF assigns the value v to attribute a of relationship t. If the value is not of the same type as theattribute (or a subtype thereof if the attribute is entity-valued), then the errorMismatchedAttributeValueType is generated. If a is not an attribute of t's relation, IllegalAttributeis generated.Н"SОfЯpuТFpupuНG╘pН хО_sТXН хО\АП9Н хОZґНЇОVяpТюП&spТаНЇОT²Т■ПAТ∙sНЇОRhpТ─spП3spТ│sНЇОP4pТ╠П=sp Н хОLXsТXН хОJ#ПHН хОGОНЇОD pТъspТЮП&spНЇОAъspТ╟Т╠П3spspНЇО?╙Т╧ spТ╨ПEspНЇО=vspТ╗spТ╘ПDНЇО;AТТ ПKНЇО9 spТsp Н хО51sТXНЇО1UpТ≤spП,Т≥П!НЇО/!ТєПFТ╔П!НЇО,МТ≥spspsp Т НЇО*╦ТлП*ТмП3Н хО&эsТXП!НЇО# pТ▓spТ⌠ПHНЇО лТП&ТП!spНЇО≤ТП2Н хО╪sТXП/НЇОЮpТ░sp spТ▒spП.НЇО╛ТІПCТЇНЇОwspТ┐spТ└spsНЇОCpТЪ╗ЇЭ>QXDESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL38GetF: PROC[t: Relship, a: Attribute] RETURNS [Value];GetF retrieves the value of attribute a of relationship t. If a is not an attribute of t's relation, errorIllegalAttribute is generated. The client should use the V2x routines described in the next section tocoerce the value into the expected type.If GetF is performed upon an attribute of a relationship whose value has never been assigned, aspecial undefined value is returned. The distinguished undefined value depends upon the type ofthe attribute. For example, for entity-valued attributes, it is NIL. For IntType attributes, it is the largest negativenumber. Clients of the database system should use the following procedures to deal with undefinedvalues: IsUndefined: PROC [v: Value] RETURNS [BOOL];MakeUndefined: PROC[d: DataType] RETURNS [Value];IsUndefined takes a value and indicates whether it is undefined, and MakeUndefined produces anundefined value of a particular type, suitable for use with SetF to make a previously definedattribute become undefined. SetFS: PROC [t: Relship, a: Attribute, v: ROPE];GetFS: PROC[t: Relship, a: Attribute] RETURNS [ROPE];GetFS and SetFS provide a convenient veneer on top of GetF and SetF that provide the illusionthat all relation attributes are string-valued. The effect is something like the Relational data model,and is useful for applications such as a relation displayer and editor that deal only with strings. Thesemantics of GetFS and SetFS depend upon the actual type of the value v of attribute a:typeGetFS returnsSetFS assigns attribute to beStringTypethe string vthe string vIntTypev converted to decimal stringthe string converted to decimal integerBoolType"TRUE" or "FALSE"true if "TRUE", false if "FALSE"a domain Dthe name of the ref'd entitythe entity with name v(or null string if v is NIL)(or NIL if v is null string)AnyDomainTypesame, but includes domain:the entity with the given domain and name:(or NIL if v is null string)The same signals generated by GetF and SetF, such as IllegalAttribute, can also be generated bythese procedures. The string NIL represents the undefined value. The signal NotFound is generatedin the last case above if no entity with the given name is found.НvОfЯpuТF pupu pupupТXuТFpuНMpН хО_sТXП5НЇО[:pТ▄ Т█spspspspНЇОYspТ┐П-Т└П*НЇОVяТП(НЇОRУТ╟spТ╠ПFНЇОPаТ╔ТіПOНЇОN▄ТєuПTТ╔НЇОLXТ°pП)Т²П0НЇОJ#ТН хОFHsТXП,Н хОDП1НЇО@7 pТ≥П9Т spНЇО>ТуП6ТжspНЇО;оТН хО7СsТXП0Н хО5ЎП5НЇО1ЦpТ÷spТ═spspНЇО/ўТ▓ПaТ⌠НЇО-zТ┤Т┬ПJНЇО+EТМТНspspП*sp sН хО'Ч.О'ivН`О'Ч О'iТXН-─О'ЧйО'iН хО%5s Н`Н-─Н хО#Н`Н-─П'Н хО лН`Н-─Н хО≤ Н`Н-─Н`ОcН-─Н хО/Н`Н-─П)Н`ОЗН-─НЇОpТ╙spsp sp Т╚НЇОЙТ┌Т┐spП-spНЇОІТПAЪ Mo>QX°3MODEL LEVEL INTERFACE39NameOf: PROC [e: Entity] RETURNS [s: ROPE];ChangeName: PROC [e: Entity, s: ROPE];NameOf and ChangeName retrieve or change the name of an entity, respectively. They generatethe signal IllegalEntity if e is not an entity.ChangeName should be used with caution. It is not quite equivalent to destroying and re-creating an entity with the newname but the same existing relationships referencing it. ChangeName is considerably faster than that, and furthermoreentity-valued variables which reference the entity are not nullified by ChangeName, though they would be byDestroyEntity. These features should be a help, not a hindrance. However, changing an entity name may invalidatereferences to the entity from outside the segment, e.g. in another segment or in some application-maintained file such as alog of updates. DomainOf: PROC[e: Entity] RETURNS [Domain];RelationOf: PROC[t: Relship] RETURNS [Relation];DomainOf and RelationOf can be used to find the entity representative of an entity's domain or arelationship's relation, respectively. The signal IllegalEntity is generated if e is not an entity. Thesignal IllegalRelship is generated if r is not a relationship.SegmentOf: PROC[e: Entity] RETURNS [Segment];SegmentOf returns the segment in which an entity is stored. It can be applied to domain, relation,or attribute entities.Eq: PROC [e1: Entity, e2: Entity] RETURNS [BOOL];Eq returns TRUE iff the same database entity is referenced by e1 and e2. This is not equivalent tothe Cedar expression "e1 = e2", which computes Cedar REF equality. If e1 and e2 are indifferent segments, Eq returns true iff they have the same name and their domains have the samename.Null: PROC [x: EntityOrRelship] RETURNS [BOOL];Null returns TRUE iff its argument has been destroyed, is NIL, or has been invalidated by abortionof the transaction under which it was created.GetP: PROC [e: Entity, aIs: Attribute, aOf: Attribute_ NIL] RETURNS [Value];SetP: PROC [e: Entity, aIs: Attribute, v: Value, aOf: Attribute_ NIL] RETURNS[Relship];GetP and SetP are convenience routines for a common use of relationships, to represent"properties" of entities. Properties allow the client to think of values stored in relationshipsЪН"SОfЯpuТFpupuНG╘pН хО_sТXП+Н хО\АП&НЇОYpТ═s pТ║П(НЇОVяТ spspНЇОSuТ└ПtТ┘НЇОQ+Т║ПGТ╒П/НЇОO=ТРП7yuП+ТСНЇОMOТ╙ПBТ╚П0НЇОKaТ┐П2Т└ПIНЇОIsТН хОE╩sТXП+Н хОC├П0НЇО?╙pТ≥s pП.Т НЇО=vТ²П3spТ·П)НЇО;AТspspН хО7fsТXП-НЇО3┼pТ█ПEТ▌НЇО1UТН хО-zsТXП1НЇО(йТ┼pspП/spspТ▀tp НЇО&√ТмТнspП*spspНЇО$aТ║spТ╒П3НЇО"-Н хОQsТXП/НЇО╒pТ∙Т√spП)spП%НЇОmТП.Н хО▒sТXПLН хО]ПWНЇОўpТТspПIНЇО yТХП%ТИП<╪Ї 2>Q]ыDESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL40referencing an entity as if they are directly accessible fields (or "properties") of the entity itself. Seethe figure on page 15 illustrating properties. GetP finds a relationship whose from attribute is equal to e,and returns that relationship's to attribute. The from attribute may be defaulted if the relation isbinary, it is assumed to be the other attribute of to's relation. If it is not binary, the current implementationwill find the "first" other attribute, where "first" is defined by the order of the original calls calls to DeclareAttribute.SetP defaults the from attribute similarly to GetP, but operates differently depending on whetherfrom is a key of the relation. Whether it is a key or not, any previous relationship that referenced ein the from attribute is automatically deleted. In either case, a new relationship is created whosefrom attribute is e and whose to attribute is v. SetP returns the relationship it creates for theconvenience of the client. GetP and SetP can generate the same errors as SetF and GetF, e.g. if eis not an entity or to is not an attribute. In addition, GetP and SetP can generate the errorIllegalProperty if to and from are from different relations. GetP generates the errorMismatchedPropertyCardinality if more than one relationship references e in the from attribute; ifno such relationships exist, it returns a null value of the type of the to attribute. SetP allows anynumber of existing relationships referencing e; it simply adds another one (when from is a key, ofcourse, there will always be one relationship). GetPList: PROC [e: Entity, to: Attribute, from: Attribute_ NIL] RETURNS [LIST OF Value];SetPList: PROC [e: Entity, to: Attribute, vl: LIST OF Value, from: Attribute_ NIL];GetPList and SetPList are similar to GetP and SetP, but they assume that any number ofrelationships may reference the entity e with their from attribute. They generate the signalMismatchedPropertyCardinality if this is not true, i.e. the from attribute is a key. GetPList returnsthe list of values of the to attributes of the relationships that reference e with their from attribute.Cedar has LISP-like list manipulation facilities. SetPList destroys any existing relationships that reference ewith their from attribute, and creates Length[vl] new ones, whose from attributes reference e andwhose to attributes are the elements of vl. GetPList and SetPList may generate any of the errorsthat GetF and SetF may generate, and the error IllegalProperty if to and from are from differentrelations.Note that the semantics of SetPList are not quite consistent with the semantics of SetP. SetPListreplaces the current values associated with a "property" with the new values (i.e., destroys and re-creates relationships); SetP adds a new property value, unless the aOf attribute is a key, in whichcase it replaces the current value. The semantics are defined in this way because this has proven themost convenient in our application programs.Examples of the use of the property procedures for data access can be found in Section 4.3.Properties are also useful for obtaining information about the data schema. For example, GetP[a,aRelationIs] will return the attribute a's relation, and GetPList[d, aTypeOf] will return all theЪНvОfЯpuТF pupu pupupТXuТFpuНMpНЇО_Т▌Т▐ПQuНЇО\АТ≤Т≥pspspsНЇОZґpТіspspТїП.НЇОXxТ┌П3sp Т┐uП/НЇОVDТ═П,Т║ПQНЇОTspТ╗ spspТ╘П.НЇОQшspТ┘ПDТ├sНЇОOїpТ╙spП$Т╚П5НЇОMrspТ╪ ТҐsp sp spspП,НЇОK>Т▄Т█ spspП!spsp sНЇОI pТиspП$spspНЇОFуspТ@spspspspНЇОD═spТ█П*spТ▌sp НЇОBltpТ°Т²П,spsp НЇО@7Т°П-spП#spТ²НЇО>ТП1Н хО:'sТXПXН хО7СПSНЇО3CpТЙspspspП$НЇО1ТОП'spspП%НЇО.зspТ┐Т└spspНЇО,іТ°Т²spП0spsp НЇО*ruТ░П%Т▒pspП3sНЇО(=pТў spspТ╞spspНЇО& Т°spТ²spspspНЇО#тТ°spspТ²spspspsp НЇО!═ НЇОПТ≥Т spП0spsНЇО╪tpТіП#ТїП9НЇО┤Т╔sptpП"spТіНЇОSТ└П#Т┘ПCНЇОТП,НЇОoТэПKТщНЇО ;Т═П>Т║sНЇОpТйspspТкЪ M ©?Q]L╙MODEL LEVEL INTERFACE41attributes that can reference domain d.E2V: PROC[e: Entity] RETURNS[v: Value];B2V: PROC[b: BOOLEAN] RETURNS[v: Value];I2V: PROC[i: LONG INTEGER] RETURNS[v: Value];S2V: PROC[s: ROPE] RETURNS[v: Value];The x2V routines convert the various Cedar types to Values. The conversion is not normallyrequired for ropes and entities since the compiler will widen these into the REF ANY type Value.V2E: PROC[v: Value] RETURNS[Entity];V2B: PROC[v: Value] RETURNS[BOOLEAN];V2I: PROC [v: Value] RETURNS[LONG INTEGER];V2S: PROC [v: Value] RETURNS[ROPE];The V2x routines convert Values to the various Cedar types. The MismatchedValueType error israised if the value is of the wrong type. It is recommended that these routines be used rather thanuser-written NARROWs, as the representation of Values may change. Also, NARROWs of opaque typesdon't yet work in the Cedar compiler.3.5 Query operations on domains and relationsIn this section we describe queries upon domains and relations: operations that enumerate entitiesor relationships satisfying some constraint.RelationSubset: PROC[ r: Relation, constraint: AttributeValueList_ NIL] RETURNS [RelshipSet];NextRelship: PROC[rs: RelshipSet] RETURNS [Relship];PrevRelship: PROC[rs: RelshipSet] RETURNS [Relship];ReleaseRelshipSet: PROC [rs: RelshipSet];ЪН"SОfЯpuТFpupuНG╘pНЇО_ТП%spН хОXБsТXП'Н хОVўП(Н хОTyП-Н хОREП%НЇОM∙pТоspП-spП!НЇОKaТ°П)Т²П7Н хОG┘sТXП$Н хОEQП%Н хОCП+Н хО@ХП#НЇО<8pТ≈spТ≤spП"spНЇО:Т▓П)Т⌠П;НЇО7пТ╞wpspТ╟uwuНЇО5⌡ТП%НЇО/DrП-НЇО*∙pТ⌡П#Т°П@НЇО(`ТП,Н хО$┘sТXН хО"PП3Н хО Н хО@П4Н хОdП4Н хО┬П)$ЇA>QSй╛DESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL42AttributeValueList: TYPE = LIST OF AttributeValue;AttributeValue: TYPE = RECORD [ attribute: Attribute, low: Value, high: Value_ NIL -- omitted where same as low or not applicable --];The basic query operation is RelationSubset. It returns a generator of all the relationships inrelation r which satisfy a constraint list of attribute values. The relationships are enumerated bycalling NextRelship repeatedly; it returns NIL when there are no more relationships. PrevRelshipmay similarly be called repeatedly to back the enumeration up, returning the previous relationship; itreturns NIL if the enumeration is at the beginning. ReleaseRelshipSet should be called when theclient is finished with the query.The constraint list may be NIL, in which case all of the relationships in r will be enumerated.Otherwise, relationships which satisfy the concatenation of constraints on attributes in the list will beenumerated. If an index exists on some subset of the attributes, the relationships will be enumeratedsorted on the concatenated values of those attributes. For a StringType, IntType, or TimeTypeattribute a of r, the contraint list may contain a record of the form [a, b, c] where the attributevalue must be greater or equal to b and less than or equal to c to satisfy the constraint. For anytype of attribute, the list may contain a record of the form [a, b] where the value of the attributemust exactly equal b. The Cedar ROPE literals "" and "\377" may be used in queries as aninfinitely large and infinitely small string, respectively. The signal MismatchedAttributeValueTypeis generated by RelationSubset if one of the low or high values in the list is of a different typethan its corresponding attribute.DomainSubset: PROC[ d: Domain, lowName, highName: ROPE_ NIL, searchSubDomains: BOOL_ TRUE, searchSegment: Segment_ NIL] RETURNS [EntitySet];NextEntity: PROC[EntitySet] RETURNS [Entity];PrevEntity: PROC[EntitySet] RETURNS [Entity];ReleaseEntitySet: PROC[EntitySet];ЪНvОfЯpuТF pupu pupupТXuТFpuНMpН хО_sТXП2Н хО\АН хОZґН хОXx Н хОVDПGНЇОQ■pТфТг s pП5НЇОO`ТІspПZНЇОM,Т°s pТ²spП(s НЇОJВpТ─ПUТ│НЇОHцТ≈spТ≤П*spНЇОF▌ТП"НЇОAъТйspП,spНЇО?╙Т┬П&Т┴ПCНЇО=vТ│П5Т┌П1НЇО;AТ╦Т╧П$s pspsНЇО9 pТґ spspТўП'spНЇО6ыТ·Т÷ spspП$НЇО4єТ═П<Т║spП!НЇО2pТгspspТхНЇО0;Т√Т≈П8sНЇО.pТїs pspsp Т╗НЇО+рТП!Н хО'ВsТXН хО%бН хО#▌Н хО!YН хО%Н хОПН хОП-Н хО9П-Н хО]П"ЪM?QVУMODEL LEVEL INTERFACE43DomainSubset enumerates all the entities in a domain. If lowName and highName are NIL, theentire domain is enumerated, in no particular order. Otherwise, only those entities whose names arelexicographically greater than lowName and less than highName are enumerated, in lexicographicorder. If searchSubDomains is TRUE, subdomains of d are also enumerated. Each subdomain issorted separately. The searchSegment argument is currently only used if d is one of the systemdomains, e.g. the Domain domain. It is used to specify which segment to search.Analogously to relation enumeration, NextEntity and PrevEntity may be used to enumerate theentities returned by DomainSubset, and ReleaseEntitySet should be called upon completion.GetDomainRefAttributes: PROC [d: Domain] RETURNS [AttributeList];This procedure returns a list of all attributes, of any relation defined in d's segment, which referencedomain d or one of its superdomains. The list does not include AnyDomainType attributes, whichcan reference any domain. GetDomainRefAttributes is implemented via queries on the dataschema. GetDomainRefAttributes is useful for application-independent tools; most specificapplications can code-in the relevant attributes.GetEntityRefAttributes: PROC [e: Entity] RETURNS [AttributeList];This procedure returns a list of all attributes in which some existing relationship actually referencese, including AnyDomainType attributes.3.6 System domains and relationsIn this section we describe what one might call the schema schema, the pre-defined system domainsand relations which constitute the data schema for client-defined domains and relations. The typicaldatabase application writer may skip this section, since the schema declaration operations defined inSection 3.3 are adequate when the data schema is completely defined and known at the time aprogram is written. The system domains and relations we describe in this section are most useful forgeneral-purpose tools (e.g. for displaying, querying, or dumping any database), where the tools mustexamine the data schema "on the fly".As noted earlier, the permanent repository for data describing user-defined data in a database is thedatabase's data schema, represented by schema entities and relationships. Schema entities aremembers of one of the pre-defined system domains: DomainDomain, RelationDomain,DatatypeDomain, and so on. Every client-defined domain, relation, or attribute contains arepresentative entity in these domains. Client-defined datatypes are not currently permitted, so theonly entities in the DataType domain are the pre-defined IntType, StringType, and BoolType.ЪН"SОfЯpuТFpupuНG╘pНЇО_spТ═Т║spspspНЇО\АТ┤Т┬ПHНЇОZґТ╙spspТ╚ НЇОXxТ╣ spspТІuНЇОVDТдpspП$sp ТеНЇОTТПPНЇОO`Тх Тиs ps pНЇОM,ТХspsp ТИН хОIPsТXПAНЇОD═pТ├Т┤П4spНЇОBlТ■spП/Т∙spНЇО@7ТХspП"ТИНЇО>ТspП;НЇО;оТП1Н хО7СsТXПAНЇО3CpТ≤П/Т≥П8НЇО1sТp sp sНЇО*╦rНЇО&эpТ⌠П4tpТ■НЇО$╗Т┴П'Т┼П>НЇО"sТ▒П)Т▓П<НЇО ?ТаПGТбНЇОТ┌ПUТ┐НЇОжТ▐ПAtpНЇО╒ТП%НЇОфТ▐Т░ПPНЇО▒ТДП-tpТЕП$НЇО]Т?П(tp sТ@НЇО)pТТПDНЇОТТ⌡ПeНЇО юТхТиspsps psp nЇ y>Q]▓+DESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL44The information about the client-defined domains and attributes are encoded by relationships in thedatabase. Domains participate in the system relation dSubType, which encodes a domain typehierarchy:dSubType: Relation; dSubTypeOf: Attribute; -- the domain in this attribute is a super-type of dSubTypeIs: Attribute; -- the domain in this attributeThe dSubType has one element per direct domain-subdomain relationship, it does not contain thetransitive closure of that relation. However, it is guaranteed to contain no cycles. That is, thedatabase system checks that there is no set of domains d1, d2, ... dN, N>1, such that d1 is a subtypeof d2, d2 is a subtype of d3, and so on to dN, and d1=dN. The dSubType may define a lattice asopposed to a tree, i.e. the sSubType attribute is not a key of the relation.The information about attributes is encoded as binary relations, one relation for each argument tothe DeclareAttribute procedure defining properties of the attribute. The names are easy toremember; for each argument, e.g. Foo, we define the aFoo relation, with attributes aFooOf andaFooIs. The aFooIs attribute is the value of that argument, and the aFooOf attribute is [the entityrepresentative of] the attribute it pertains to. Thus we have the following relations: aRelation: PUBLIC READONLY Relation; -- Specifies attribute - relation correspondence: -- [aRelationOf: KEY Attribute, aRelationIs: Relation] aRelationOf: PUBLIC READONLY Attribute; -- attribute whose relation we are specifying aRelationIs: PUBLIC READONLY Attribute; -- the relation of that attribute aType: PUBLIC READONLY Relation; -- Specifies types of relation attributes: -- [aTypeOf: KEY Attribute, aTypeIs: ValueType] aTypeOf: PUBLIC READONLY Attribute; -- the attribute aTypeIs: PUBLIC READONLY Attribute; -- domain or datatype of the attribute aUniqueness: PUBLIC READONLY Relation; -- Specifies attribute value uniqueness: -- [aUniquenessOf: KEY Attribute, aUniquenessIs: INT LOOPHOLE[Uniqueness]] aUniquenessOf: PUBLIC READONLY Attribute; -- the attribute aUniquenessIs: PUBLIC READONLY Attribute; -- INT for Uniqueness: 0=None, 1=Key, etc. aLength: PUBLIC READONLY Relation; -- Specifies length of attributes: -- [aLengthOf: KEY Attribute, aLengthIs: INT] aLengthOf: PUBLIC READONLY Attribute; -- the attribute aLengthIs: PUBLIC READONLY Attribute; -- INT corresponding to attribute's lengthЪНvОfЯpuТF pupu pupupТXuТFpuНMpНЇО_Т▌ПNТ▐НЇО\АТхП%ТиspНЇОZґ Н хОVяsТXН хОT²ПKН хОRhП8НЇОN▄pТ÷spПFТ═НЇОLXТаП1ТбП2НЇОJ#Т┬П$Т┴ОI√ОJ#ОI√ОJ#ОI√ОJ#ОI√ОJ#НЇОGОТ┬ОGbОGООGbОGОТ┴ОGbОGООGbОGООGbОGООGbОGОspНЇОE╩ТspП(НЇОAъТіП+ТїП7НЇО?╙ТРspП?ТСНЇО=vТ╙П!Т╚spspspНЇО;AspТ█spП2spТ▌НЇО9 ТПWН хО51sТXПXН хО2ЩП:Н хО0хПYН хО.■ПMН хО*+ПMН хО'ВП3Н хО%бП8Н хО#▌ПNН хО%ПQН хОППMН хО╪П>Н хО┤ПXН хОПGН хОЙП1Н хОІП:Н хО │ПU дM>Q]MODEL LEVEL INTERFACE45 aLink: PUBLIC READONLY Relation; -- Specifies whether attribute is linked: -- [aLinkOf: KEY Attribute, aLinkIs: INT] aLinkOf: PUBLIC READONLY Attribute; -- the attribute aLinkIs: PUBLIC READONLY Attribute; -- 0=unlinked, 1=linked, 2 =colocated The final set of system relations pertain to index factors. Each index on a relation is defined toinclude one or more attributes of a relation. For each attribute in the index, there is an index factorentity. For each index, there is an index entity. Each index factor is associated with exactly oneindex and exactly one attribute. Indices may have many index factors, however, and an attributemay be associated with more than one index factor, since attributes may participate in multipleindices. The two relations pertaining to indices map indices on to their index factors, and indexfactors to the attributes they index: ifIndex: PUBLIC READONLY Relation; -- Specifies the index factors for each index -- [ifIndexOf: KEY IndexFactor, ifIndexIs: Index] ifIndexOf: PUBLIC READONLY Attribute; -- the index factor ifIndexIs: PUBLIC READONLY Attribute; -- index of the factor ifAttribute: PUBLIC READONLY Relation; -- Specifies attribute index factor corresponds to -- [ifAttributeOf: KEY IndexFactor, ifAttributeIs: Attribute] ifAttributeOf: PUBLIC READONLY Attribute; -- the index factor ifAttributeIs: PUBLIC READONLY Attribute; -- the attribute this factor representsThe relations on attributes, index factors, and domains can be queried with the RelationSubset orGetPList operations. For example, GetP[a, aRelationIs] returns the attribute a's relation.GetPList[r, aRelationOf] returns the relation r's attributes. RelationSubset[dSubType,LIST[[dSubTypeIs, d]]] will enumerate all the dSubType relationships in which d is the subtype.As noted earlier, the data schema (attributes, relations, domains, indices, index factors, and relationspertaining to these) may only be read, not written by the database client. In order to ensure theconsistency of the schema, it must be written indirectly through the schema definition procedures:DeclareDomain, DeclareRelation, DeclareAttribute, and DeclareSubType. Attempts to performupdates through operations such as SetP result in the error ImplicitSchemaUpdate.3.7 ErrorsThe Cedar language provides a SIGNAL mechanism for returning control to the caller of aprocedure when an exceptional condition is identified. When a database system operation invokesan error, the SIGNAL Error is generated, with an error code indicating the type of error thatЪН"SОfЯpuТFpupuНG╘pН хО_sТXПLН хО\АП-Н хОZґП8Н хОXxПOНЇОT²pТ╠П-tpП&Т╡НЇОRhТ└П#Т┘ПEНЇОP4ТїПdНЇОMЪТ╚Т╛П@НЇОKкТфПVТгНЇОI√Т╠П5Т╡П-НЇОGbТП%Н хОC├sТXПRН хОARП5Н хО?П>Н хО<ИПAН хО8─П[Н хО6KПAН хО4ПAН хО1ЦПUНЇО.pТ°П;Т²s pНЇО+рspТspТ sp НЇО)·sТspТtspsНЇО'iТіpspspНЇО#▌Т▓П9Т⌠П/НЇО!YТ╗Т╘ПEНЇО%ТіТїПHНЇОПsТ╔psps p Ті НЇО╪ТП#spspНЇОer НЇО┴pТСspТТП3НЇОUТ║Т╒ПCНЇО Тя spТрПCЪ ,Їы?Q\2ЫDESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL46occured. The error code is a Cedar "enumerated type":Error: SIGNAL [code: ErrorCode];ErrorCode: TYPE = {AlreadyExists, -- Entity already exists and client said version=NewOnlyBadUserPassword, -- On an OpenTransactionDatabaseNotInitialized, -- Attempt to do operation without calling InitializeFileNotFound, -- No existing segment found with given nameIllegalAttribute, -- Attribute not of the given relship's Relation or not an attributeIllegalValueType, -- Type passed DeclareAttribute is not datatype or domainIllegalDomain, -- Argument is not actually a domainIllegalFileName, -- No directory or machine given for segmentIllegalEntity, -- Argument to GetP, or etc., is not an EntityIllegalRelship, -- Argument to GetF, or etc., is not a RelshipIllegalRelation, -- Argument is not a relationIllegalSegment, -- Segment passed to DeclareDomain, or etc., not yet declaredIllegalString, -- Nulls not allowed in ROPEs passed to the database systemIllegalSuperType, -- Can't define subtype of domain that already has entitiesIllegalValue, -- Value is not REF INT, ROPE, REF BOOL, or EntityIllegalValueType, -- Type passed DeclareAttribute is not datatype or domainImplicitSchemaUpdate, -- Attempt to modify schema with SetP, DeclareEntity, etc.InternalError, -- Impossible internal state (possibly bug or bad database)MismatchedProperty, -- aOf and aIs attribute not from the same relationMismatchedAttributeValueType, -- Value not same type as required (SetF)MismatchedExistingAttribute, -- Existing attribute is different (DeclareAttribute)MismatchedExistingSegment, -- Existing segment is different (DeclareSegment)MismatchedPropertyCardinality, -- Did GetP with aOf that is not a KeyMismatchedSegment, -- Attempt to create ref across segment boundary (SetF)MismatchedValueType, -- value passed V2E, V2I, etc. not of expected typeMultipleMatch, -- More than one relationship satisfied avl on DeclareRelship.NonUniqueEntityName, -- Entity in domain with that name already existsNonUniqueKeyValue, -- Relship already exists with that valueNotFound, -- Version is OldOnly but no such Entity, Relation, or etc foundNotImplemented, -- Action requested is not yet implementedNILArgument, -- Attempt to perform operation on NIL argumentNullifiedArgument, -- Entity or relationship has been deleted or invalidatedProtectionViolation, -- Read or write to segment not permitted this user.SegmentNotDeclared, -- Attempt to open transaction w/o DeclareSegmentServerNotFound -- File server does not exist or does not respond };In this report, the expression "generates the error X" means that the SIGNAL Error is generatedwith code=X. Unless otherwise specified, the client may CONTINUE from the signal, aborting theoperation in question. Signals should not be RESUMEd except by a wizard who knows the result ofproceeding with an illegal operation.ЪНvОfЯpuТF pupu pupupТXuТFpuНMpНЇО_ТП5tН хО[:sТXН хОYНЎОVяПGНЎОUП)НЎОS<ПMНЎОQqП:НЎОOїПVНЎОMэПKНЎОLП3НЎОJGП=НЎОH|П=НЎОF╡П>НЎОDГП.НЎОCПMНЎОARПJНЎО?┤ПMНЎО=╪П@НЎО;РПKНЎО:'ПPНЎО8]ПJНЎО6▓ПGНЎО4гПGНЎО2ЩПRНЎО12ПLНЎО/hПEНЎО-²ПJНЎО+рПHНЎО*ПMНЎО(=ПFНЎО&sП<НЎО$╗ПJНЎО"щП:НЎО!П<НЎОHПLНЎО}ПIНЎОЁПEНЎОХП@НЎОНЇОBpТ╟Т╠П3spНЇО Т■П)Т∙spНЇОыТ┌Т┐spП+НЇО ╔ТП%\M ^>QZґФ474. Application ExampleThis section provides a simple example of the use of Cypress. Section 4.1 introduces the example, adatabase of documents. Section 4.2 is a discussion of database design: the process of representingabstractions of real-world information structures in a database, somewhat specialized to the datastructures available in Cypress. In Section 4.3, a working program is illustrated.Our example is necessarily short; don't expect any startling revelations on these pages. We will tryto consider some of the most common cases, however.4.1 A database applicationWhat are the properties of a well-designed database? To a large extent these properties follow fromthe general properties of databases. For instance, we would like our databases to extend gracefullyas new types of information are added, since the existing data and programs are likely to be quitevaluable.It may be useful to consider the following point. The distinguishing aspect of information stored ina database system is that at least some of it is stored in a form that can be interpreted by the systemitself, rather than only by some application-specific program. Hence, one important dimension ofvariation among different database designs is in the amount of the database that is system-interpretable, i.e. the kinds of queries that can be answered by the system.As an example of variation in this dimension, consider the problem of designing a database fororganizing a collection of Mesa modules. In the present Mesa environment, this database wouldneed to include at least the names of all the definitions modules, program modules, configurationdescriptions, and current .Bcd files. A database containing only this information is little more than afile directory, and therefore the system's power to answer queries about information in this databaseis very limited. A somewhat richer database might represent the DIRECTORY and IMPORTS sectionsof each module as relationships, so that queries such as "which modules import interface Y?" can beanswered by the system. This might be elaborated further to deal with the use of individual typesand procedures from a definitions module, and so on. There may be a limit beyond which it isuseless to represent smaller objects in the database; if we aren't interested in answering queries like"what procedures in this module contain IF statements?", it may be attractive to represent the bodyof a procedure (or some smaller naming scope) as a text string that is not interpretable by thedatabase system, even though it is stored in a database. We shall illustrate design ideas with a database of information about documents. Our currentfacilities, which again are simply file directories, leave much to be desired. The title of a documentЪН;РО[{pНОSYqТ─НОO}pТ┬ПbТ┴НОMIТ≤Т≥ПMНОKТхТиПGНОH≥Т─ПSНОDЎpТ√ПeНОBCТ─П3НО;ЛrНО8pТ┼Т▀П\НО5эТ≈ Т≤ПYНО3їТ÷Т═ПVНО1sНО-≈pТ█ПbТ▌НО+cТ┬П#spП2Т┴ НО).Т╚ПaНО&ЗТЖП"ТВП9НО$еТ─ПLНО ИpТ©П6ТюП(НО╣ТЄТ╣ПGНО│Т╚П-Т╛П4НОLТ└П\Т┘НОТ█П3Т▌П2НОЦТ≥П2Т tptpНО╞Т┴П8Т┼П!tpНОzТ Т⌡ПJНОFТ╞П5Т╟П(НО Т■ Т∙П]НО щП(tpТ√П9НО╘ТдПXТеНОtТ─П8Н)TpТНО≤ТрТсП=НОdТ▐П"Т░ПEЪ БЇv>Q\∙ЧDESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL48on the printed page does not tell the reader where the document is stored or how to print a copy.Relationships between different versions of the same basic document are not explicit. Retrievals bycontent are impossible. Our goal here is not to solve all of these problems, but to start a design thathas the potential of dealing with some of them.4.2 Schema designEach document in our example database has a title and a set of authors. Hence we might representa collection of documents with a domain of entities whose name is the title of the document, and anauthor property specifying the authors:Document: Domain = DeclareDomain["Domain"];dAuthors: Property = DeclareProperty["author", Document, StringType];Here the authors' names are concatenated into a single string, using some punctuation scheme toallow the string to be decoded into the list of authors. This is a very poor database design because itdoes not allow the system to respond easily to queries involving authors; the system cannot parse theencoded author list.Note that in the above definition authors are strings, so anything is acceptable as an author. Thisweak typing has some flexibility: the database will never complain that it doesn't know the authoryou just attached to a certain document. However, the system is not helpful in catching errors whena new document is added to the database. If "Mark R. Brown" is mistakenly spelled "Mark R.Browne", then one of Mark's papers will not be properly retrieved by a later search. A step in thedirection of stronger type checking is to provide a separate domain for authors.To represent authors as entities, and to allow a variable number number of authors for a document,a better design would be:Document: Domain = DeclareDomain["Domain"];Person: Domain = DeclareDomain["Person"];author: Property = DeclareProperty["author", Document, Person];Incidentally, in the last line above we define a property rather than relation for brevity. Instead ofthe author property declaration we could have written:author: Relation = DeclareRelation["author"]; authorOf: Attribute = DeclareAttribute[author, "of", Document]; authorIs: Attribute = DeclareAttribute[author, "is", Person];Н)ОY█ptТF ptpt ptptpТXtТFptНpНjОQ╡Т⌡ПLТ°НjОO}Т▓ПKТ⌠НjОMIТ└П\Т┘НjОKТ─П/НjОDЎrНjО@БpТ▀П;Т▄П&НjО>ґТ┤П\Т┬НjОQ\O&DESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL50where a large number of relationships are expected to refer to the same entity, it is also more spaceefficient in our implementation.If an authorOrder attribute is defined, the client may wish to redefine the authorOf attribute sothat links (pointers) are not maintained between the Document entities and author relationships,instead defining a more space-efficient B-tree index on the [authorOf, authorOrder] pair:authorOf: Attribute = DeclareAttribute[ relation: author, name: "of", type: Document, link: FALSE];authorIndex: Index = DeclareIndex[author, LIST[[authorOf, authorOrder]]];The Cypress implementation will use this index to process any call of the formRelationSubset[author, LIST[[authorOf, x]]This call to RelationSubset will therefore enumerate authors of document x sorted by authorOrder.Cypress will also use the index in processing for GetPList[..., authorOf] as GetPList usesRelationSubset.This solution is also somewhat less than perfect, as it depends upon the fact that the Cypressimplementation orders relationships when an index exist; but indices are not intended to change thesemantics of the operations, only to improve performance. Probably the best solution, if theordering is important to the semantics of a database application, is to represent a list by a binary"next" relation connecting the entities in an ordering.Documents have other interesting properties. Some of these, for example the date on which thedocument was produced, are in one-to-one correspondence with documents. Such properties can bedefined by specifying a relation or property as being keyed on the document:publDate: Property = DeclareProperty["publDate", Document, StringType, Key];We are using the convention that domain names are capitalized and relation, attribute, and propertynames are not capitalized, both for the Cedar Mesa variable names and in the names used in thedatabase system itself. If and when the database system is better integrated with Cedar Mesa, the Cedar anddatabase names will be one and the same.We might wish to include additional information for particular kinds of documents, for exampleconference papers. Conference papers may participate in the same relations as other documents.For example, they have authors. In addition, we may want to define relations in which onlyconference papers may participate, for example a presentation relation which defines who presentedthe paper, and where. We can define a conference paper to be a sub-domain of documents, andЪН)О]"ptТF ptpt ptptpТXtТFptНpНjОUGТ▐П_Т░НjОSТ─НjОO6pТ╞u pП-Т╟ upНjОMТЄТ╣up upНjОJнТ─ПYН{ОFРuТXП'Н{ОDҐП@Н{О@TПIНjОНОdТ─эЇ#Ї>QDT╟DESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL52<==2U≈D`D`╪@╪@D`╩═╪@Cю╩═╩═CюCю╩═D`Cю╪@>U≈C`BтCQ4ЎПҐ╪Cl@CСЧCВч╩²g╪ClGҐ,╪іBхCK4Ў/ПҐ╪╩ю╩═D@D@> UтBтCZBПpBА Ґ▓Ґ3@Cз┐Cз┌CZ─╩▌щ─╪%~Cз┌─╪╦╪╦BДpBу Ґ╒Ґ;@╪⌠ю╪╪"Db≥CСЪ╪⌠╧>CVCHCHCB▓BhЮҐ3>Ґ▓CСЧClD╪╨h╩█П╪⌠╪─CСЧ─╪іҐ,BЫ$BPЮҐ;>Ґ╒╪%}╪%~╪╔─Dq"─Cз┌╪%}─>uV)CZBтCW2ҐЎЎПD@╩ю╩═D@╪═CQ2Ў═@ҐЎЎ/П╪╪⌠╪CE≤DrClC─╪─>╡V7C`CQ2Ґ+ЬҐЎAПЗCСЧ╪⌠ю╩²h╪"ClC─CСЧ─╪іBтCK2Ґ7ВЧҐЎAп╩юD@D`╩ю>ОV)CZҐ,BА$Ґ░Ґ3>BmПCз┌╪%}╩▌щ─╪╔─Cз┌Cз│─╪╦CHBу$Ґ░Ґ;>B]П╪Cl@Db≤CВч╪⌠╪─╪─?!VCH╪╦BhЮ╪ҐpҐ▓BлюClD╪╩█ПCE■CСЪClGҐ,CZBPЮҐЮҐ╒Bдю╪%~Cз┐Dq"─CZ─╪%~╪%~─?DUтBт╪і╪╗лЎПBПD╩ю╩═D@D@C`Ў═@╪ўлЎ/ПBХCЪ╪⌠╪CСЧDr╪╨l╪╪⌠╧?RU≈╪═Ґ+Ь╪ўлAПBПD╪⌠ю╪╪"Db≥CСЪ╪⌠╧BтCZҐ7Ь╪ЄлAпBХDD@D`╩ю╩ю?DUZҐ,╪іҐ░ҐЮBmПBлю╪%}╪%~╪╔─Dq"─Cз┌╪%}─CHCHҐ░Ґ*ЮB]ПBдюCl@CСЧCВч╩²g╪ClG?!U(╪╦╪╦╪ҐnҐ≈ BлбBmП╪╪⌠╪CE≤DrClC─╪─CZBтҐэҐ╞ BдбB]ПCз┐Cз┌CZ─╩▌щ─╪%~Cз┌─>ОU╪іҐ,╪╗нBПBAП╩юD@D`╩юC`╪ўнA_юBХBAпCСЧClD╪╨h╩█П╪⌠╪─CСЧ─>╡TВ╪═╪ўнBтBПBЎП╪Cl@Db≤CВч╪⌠╪─╪─CZҐ,╪ЄнBхBХBЎ/ПD@╩ю╩═D@>uU╪іBтҐэBПpBлбҐ▓╪%~Cз┐Dq"─CZ─╪%~╪%~─CH╪╦Ґ*эBДpBдбҐ╒CСЧ╪⌠ю╩²h╪"ClC─CСЧ─>CU(╪╦CHҐ≈ CB░BmПҐ3?Ъ╪⌠╪CСЧDr╪╨l╪╪⌠╧Bт╪іҐ╞ BЫЧB]ПҐ;@Cз┌╪%}╩▌щ─╪╔─Cз┌Cз│─> UZҐ,CZCW4AПҐ╩ЧD@D`╩ю╩ю╪═A_юCQ3ЧAпҐ╪ClD╪╩█ПCE■CСЪClG>rLwD`D`╪@╪@D`╩═╪@Cю╩═╩═CюCю╩═D`Cю╪@>RLwC`BтCQ4ЎПҐ╪Cl@CСЧCВч╩²g╪ClGҐ,╪іBхCK4Ў/ПҐ╪╩ю╩═D@D@>`LЄBтCZBПpBА Ґ▓Ґ3@Cз┐Cз┌CZ─╩▌щ─╪%~Cз┌─╪╦╪╦BДpBу Ґ╒Ґ;@╪⌠ю╪╪"Db≥CСЪ╪⌠╧>┐LФCHCHCB▓BhЮҐ3>Ґ▓CСЧClD╪╨h╩█П╪⌠╪─CСЧ─╪іҐ,BЫ$BPЮҐ;>Ґ╒╪%}╪%~╪╔─Dq"─Cз┌╪%}─>╣M CZBтCW2ҐЎЎПD@╩ю╩═D@╪═CQ2Ў═@ҐЎЎ/П╪╪⌠╪CE≤DrClC─╪─>РMC`CQ2Ґ+ЬҐЎAПЗCСЧ╪⌠ю╩²h╪"ClC─CСЧ─╪іBтCK2Ґ7ВЧҐЎAп╩юD@D`╩ю?/M CZҐ,BА$Ґ░Ґ3>BmПCз┌╪%}╩▌щ─╪╔─Cз┌Cз│─╪╦CHBу$Ґ░Ґ;>B]П╪Cl@Db≤CВч╪⌠╪─╪─?aLФCH╪╦BhЮ╪ҐpҐ▓BлюClD╪╩█ПCE■CСЪClGҐ,CZBPЮҐЮҐ╒Bдю╪%~Cз┐Dq"─CZ─╪%~╪%~─?└LЄBт╪і╪╗лЎПBПD╩ю╩═D@D@C`Ў═@╪ўлЎ/ПBХCЪ╪⌠╪CСЧDr╪╨l╪╪⌠╧?▓Lw╪═Ґ+Ь╪ўлAПBПD╪⌠ю╪╪"Db≥CСЪ╪⌠╧BтCZҐ7Ь╪ЄлAпBХDD@D`╩ю╩ю?└L:Ґ,╪іҐ░ҐЮBmПBлю╪%}╪%~╪╔─Dq"─Cз┌╪%}─CHCHҐ░Ґ*ЮB]ПBдюCl@CСЧCВч╩²g╪ClG?aL╪╦╪╦╪ҐnҐ≈ BлбBmП╪╪⌠╪CE≤DrClC─╪─CZBтҐэҐ╞ BдбB]ПCз┐Cз┌CZ─╩▌щ─╪%~Cз┌─?/KЕ╪іҐ,╪╗нBПBAП╩юD@D`╩юC`╪ўнA_юBХBAпCСЧClD╪╨h╩█П╪⌠╪─CСЧ─>РKв╪═╪ўнBтBПBЎП╪Cl@Db≤CВч╪⌠╪─╪─CZҐ,╪ЄнBхBХBЎ/ПD@╩ю╩═D@>╣KЕ╪іBтҐэBПpBлбҐ▓╪%~Cз┐Dq"─CZ─╪%~╪%~─CH╪╦Ґ*эBДpBдбҐ╒CСЧ╪⌠ю╩²h╪"ClC─CСЧ─>┐L╪╦CHҐ≈ CB░BmПҐ3?Ъ╪⌠╪CСЧDr╪╨l╪╪⌠╧Bт╪іҐ╞ BЫЧB]ПҐ;@Cз┌╪%}╩▌щ─╪╔─Cз┌Cз│─>`L:Ґ,CZCW4AПҐ╩ЧD@D`╩ю╩ю╪═A_юCQ3ЧAпҐ╪ClD╪╩█ПCE■CСЪClGRick CattellMark BrownrT7rQw2Qw2T7rT7▓T7▓Qw╩ю╩═D@D@RT7D@D`╩ю╩юrQ≈2Q≈D@╩ю╩═D@rQW╩юD@D`╩юQwT7D@D`╩ю╩юRQw╩ю╩═D@D@2TrT╩юD@D`╩ю2TWD@╩ю╩═D@РT7РQЇ╩ю╩═D@D@╡T7D@D`╩ю╩юрIврG▓G▓IврIвРIвРG╩ю╩═D@D@╡IвD@D`╩ю╩юрG7▓G7D@╩ю╩═D@рFВ╩юD@D`╩юrGrIвD@D`╩ю╩ю╡G╩ю╩═D@D@▓IЇрIЇ╩юD@D`╩ю▓IВD@╩ю╩═D@RIвRGW╩ю╩═D@D@IвD@D`╩ю╩ю,РVв,РT5╡T5╡Vв,РVв-Vв-T╩ю╩═D@D@,рVвD@D`╩ю╩ю,РT75╡T7D@╩ю╩═D@,РSВ╩юD@D`╩ю5▓T5▓VвD@D`╩ю╩ю5рT╩ю╩═D@D@5╡VЇ,РVЇ╩юD@D`╩ю5╡VВD@╩ю╩═D@1rVв1rTW╩ю╩═D@D@12VвD@D`╩ю╩ю-RJв-RH6H6Jв-RJв-rJв-rH╩ю╩═D@D@-2JвD@D`╩ю╩ю-RH76H7D@╩ю╩═D@-RGВ╩юD@D`╩ю5РH5РJвD@D`╩ю╩ю62H╩ю╩═D@D@6JЇ-RJЇ╩юD@D`╩ю6JВD@╩ю╩═D@1рJв1рHW╩ю╩═D@D@1▓JвD@D`╩ю╩юCypress DatabaseAn Analysis ofPriority Queues-2P≈-2Mв5РMв5РP≈-2P≈-RP≈-RMв╩ю╩═D@D@-P≈D@D`╩ю╩ю-2MВ5РMВD@╩ю╩═D@-2MЇ╩юD@D`╩ю5рMв5рP≈D@D`╩ю╩ю6Mв╩ю╩═D@D@5РPw-2Pw╩юD@D`╩ю5РPЇD@╩ю╩═D@1╡P≈1╡N╩ю╩═D@D@1rP≈D@D`╩ю╩юofofofofofisisis198219774ОIwEsЕыCА╒rҐ,ПЎ6Ґ;2ПCаr▌CЫ!CRЎ╪┴э╩░w╪ґA─CЫ!─╨≈к╡╩8я9╪ z╟D[<уCZT┬╪┴nЕ╪ЄҐ■юCК0Df-Bk@╪Є8hJEад╞Dыз├╩╡ DиЭ┌Cэ≈╩їТПCЖ>Cb╪і■╩▌н╪²Т─CЖ>─╨─pщ╩<▌CО─ ╩┴╛т╪+ЬDY}╪ъ╪ґBCv$Do┴CRЎ─╪ч─╩╦BM0Am`@Й ─Ґ6Sл╪ б╪²ТCYlDq2Cb─╪ а─4РOWEн(├Aя Bд4@©"─@╪є3╪;Х&CЧҐ' ╩╟O─╩╛▓BьыCЧ─╨8QDeз╪)s╗╩≈╚╧Bэ╘ЮCф з╩ю©ЎCЪ9D`B@B`╩ю9╦OEI┘|╪WЎЎ╙╪├й▄Ґ┐(?ЪЭCУФ╪°P╩÷╙╪ЧCcЁCУГ╨ҐУЛDo╞aҐ═И╪8╘:Ґ÷хAЗ─@╪ЯBьЮDO╟─DSnҐ''╪С─;НNsDо?K╩╪Щ,@ВлҐ╧░ҐЄQ A~┬─CЛr╪<╩√х╪!UCцЧ@CЛr─╩6И╒D[і┼@[╪Ў:`Ґ╨~ЮAвШю╪ Cc╡D`UCЧЪ╪°O╪ =#MрDш[У╩█oсҐ÷B╪є@уШBдо@CДЙ╪1A╩▓{─╪7`Cн©@CДИ─╩)ґЗDц[ЖB@─ Ў%÷═Ґ÷@═Ґ╡║─╪▌CдDi8Cч╚╪<ю╪█─4SUвEпh╪·VqЎ├АAIНBц# D@?T╪@╩÷Кю╚─D@╨0р©° Ў95─Ce ╞AW▓Ґ<|Ю╪Aн DC°─D]}Ў1Т╪9RUЇEл*@Е"╧Ў=1C[^ARКҐ├╡.CЪГAо─╪▄╩²√Ў0▄CЪХ╨4╪║■┼Ў▄ЦAF∙Bz с╩юю╛CЪюD`?T─╩ю.:U8╨?У\╩─╙B?АЬ?Хх©&ъ─╪Х─ҐpCмDlдBЩ█╪ХEуoDю╙BALЎ┐O©┼@я ─CЭ9BШ─╪2╩⌠fҐ─CЭ8*:T8╨74╞╩6Z┼ЎWЎ ЮҐ├╔CZ)╟╪D─Ґ8$CЦиDh─Bгэ╪DEл▓еDVс╘╪6АPCЭ ├BР]─╪╚PCЭ─BЩ░╪2Щ╩⌠<ҐsCЭ%√S7╨ p╩;,└╩╘хDо{C~'─╪Ь╪─AQ@DAЦюD^І─Ўўэ╪─FAі°╪╛╡Ґ└Ъю©┬╪╙ы░CЙEЗCЧ╩Bгэ╪8╩≈В─Ґ8#CЧ╪.Nв╨─pdDC┐AAoю>Ъ─Ў1ЪЎLх╪ф─Bp─DJ(юDXdҐ▐─╪д─Eюpc╪hҐ╪ЮҐ*╠■ADб─AС@CЧД─Ґ<э╩ЁЖ@╩╘9─Bц(CЧД*OW╨ёDWЗ0╪Єў╟╪÷ЪHCspCЮкЭ╪а─BШDU5@DMкҐЮ─╪а─EщmT╩#j≥CМе@D{nл╪ўn░╪8CЪ9─Ґ▐─╩╣в@╩ї°Bp─CЪ;─#ЙP8╨ўDЮpЖCЯтЮDдkҐ├Ю╪.─╪А─CoЛDc┬@CТ╦╪░─╪АEвЭШ╨╙sКЎІ│CPLCf≥░Cхз┌CЭ>─ҐД╩╙йю╩╡5BШ CЭ>─-Rx╩⌡q*CАд╙@iтюю,╛─╪ ─Cp╡Dc╨@CТ ╪▐L╪ Ddc─╪█Чю5V?C^?н╚?FїCС╪░╩°x@╪KCoЛ─CСSHвEЛеj╪▌╔╡Ґ┐к─©═─╪╪ПCы-&CЧМ─Bб(╪ъ─╩≤┬Ґ=э─CЧН─╨┼р╩≈Rз╩╣╨ЛDбQщCm`╪'рз╪─Aб═DCD]щ─Ў=Z╪─#НHВEи;DLN`╪;GПDFл≈Cc\`╪чCЪ>BoX╪║╩≥⌡─Ґ░╟CЪ?╨6C╩©KжCт@@╩ґуЄ╪≈f═CЕяМ╪─Ґ=ьCФ ─DgxBб#─╪─(oIЇEв:ЛDLQ:D@ЮХ╩█©*╪÷NпCл:CЪж─Ў═╩╩<@╩ёZ─AГ`CЪу─╨!²vCлQ9Bz@@?РBОБ`╪3bф╪бҐ░╗CЙ_DfdBoP╪а─ЯRВEдRQBжв╛ЎїFЎ√└BRп╗CЪы@AЦп╪ ┌@╩°ЧЎ0CЪы─╨<є║╪√в╛Ґ7,юBШЭAОБҐў/W╪─ЎўюCЭ)─Da@AQR╪─0SEрЫуCюе\ҐG@C]3ЙBQ+Ґ└]tCЪ┴BWP╪ж╩ ЕҐ╗╞CЪ┬╨.|К╪bўЎ▐жю└Ў(zB~2▄╪&юЎ0CЖ}юDcAЦп╪&─╞HЇEо2`CЫЄAчg─?А─BGW@Ґ+БCЪМAеП╪═─╩²ъ─Ў:CЪЛ╨.dю╪іпCXИ ╪3DКҐ<ш`BЕл ╪√@Ґ·CМ─DeўBaФ─╪√─╠IEфй┬CM]ШCCф░╪▄Ґ≤║юBм=ЗCЪШ─Ў╩ю╩Ўi╩║AD4CЪЭ╨7eDBм]ЭAмЪAФ╪─Ґ2┌╪Ў:CЫ_─Db ─AеФ╪isisrwD`D`╪@╪@D`╩═╪@Cю╩═╩═CюCю╩═D`Cю╪@RwC`BтCQ2ЎНҐЎClB─CСЩ─CВш@╩²h─╪─ClBҐ,╪іBхCK2Ў/ПҐЎ╩ю╩═D@D@`ЄBтCZBПqBА$Ґ▓Ґ3=Cз┌─Cз┌─CZ┐╩▌эю╪%} Cз┌Ю╪╦╪╦BДrBу$Ґ╒Ґ;=╪⌠Ў╪─╪$Db≈─CСЧ╪⌠Ў┐ФCHCHCB▓─BhДҐ3=Ґ▓CСЩюClB╪╨g─╩█Я╪⌠ЎCСЧ╪іҐ,BЫ%BPДҐ;=Ґ╒╪%}─╪%}─╪╔}Dq#@Cз┌Ю╪%} ╣ CZBтCW1─ҐЎЎПD@╩ю╩═D@╪═CQ1─Ў═0ҐЎЎ/П╪@╪⌠ЎCE≤─DrClB╪РC`CQ1─Ґ+ЗҐЎAПЗCСЩю╪⌠Ў╩²h`╪$ClBCСЧ╪іBтCK1─Ґ7ЫЧҐЎAп╩юD@D`╩ю/ CZҐ,BА%Ґ▌Ґ3=BmНCз┌─╪%}─╩▌эю╪╔}Cз┌ЮCз┌Ю╪╦CHBу%Ґ▌Ґ;=B]Н╪@ClBDb≈═CВэ╪⌠Ў╪aФCH╪╦BhД╪ҐnҐ▓BлцClB╪╩█ЯCE≥CСЧClBҐ,CZBPДҐэҐ╒Bдц╪%}─Cз┌─Dq#@CZ┐╪%} ╪%} └ЄBт╪і╪╗нЎПBПB╩ю╩═D@D@C`Ў═0╪ўнЎ/ПBХAЪ╪⌠ЎCСЧDr╪╨g╪╪⌠Ў▓w╪═Ґ+З╪ўнAПBПB╪⌠Ў╪─╪$Db≈─CСЧ╪⌠ЎBтCZҐ7З╪ЄнAпBХBD@D`╩ю╩ю└:Ґ,╪іҐ▌ҐэBmНBлц╪%}─╪%}─╪╔}Dq#@Cз┌Ю╪%} CHCHҐ▌Ґ*эB]НBдцClBCСЩ─CВэ╩²h─╪ClBa╪╦╪╦╪Ґm─Ґ≈BлцBmН╪@╪⌠ЎCE≤─DrClB╪CZBтҐшҐ╞BдцB]НCз┌─Cз┌─CZ┐╩▌эю╪%} Cз┌Ю/Е╪іҐ,╪╗н─BПBAП╩юD@D`╩юC`╪ўн─A_пBХBAпCСЩюClB╪╨g─╩█Я╪⌠ЎCСЧРв╪═╪ўн─BтBПBЎП╪@ClBDb≈═CВэ╪⌠Ў╪CZҐ,╪Єн─BхBХBЎ/ПD@╩ю╩═D@╣Е╪іBтҐшBПrBлцҐ▓╪%}─Cз┌─Dq#@CZ┐╪%}@╪%} CH╪╦Ґ*шBДrBдцҐ╒CСЩю╪⌠Ў╩²h`╪$ClBCСЧ┐╪╦CHҐ≈CB▓BmМҐ3<Ъ╪⌠Ґ─CСЧDr ╪╨g╪╪⌠ЎBт╪іҐ╞BЫ#ЧB]НҐ;=Cз┌─╪%}─╩▌эю╪╔}Cз┌ЮCз┌Ю`:Ґ,CZCW2AПҐҐЧD@D`╩ю╩ю╪═A_пCQ1ЧAпҐЎClB╪╩█Я@CE≥CСЩ░ClB,▓,▓В:В:,▓,╡,╡В╩ю╩═D@D@,rD@D`╩ю╩ю,▓:D@╩ю╩═D@,▓в╩юD@D`╩ю9РВ9РD@D`╩ю╩ю:2В╩ю╩═D@D@:В,▓В╩юD@D`╩ю:7D@╩ю╩═D@0р0рВ╩ю╩═D@D@0▓D@D`╩ю╩ю5╡5╡В╩ю╩═D@D@5rD@D`╩ю╩юR.ЇD`D`╪@╪@D`╩═╪@Cю╩═╩═CюCю╩═D`Cю╪@2.ЇC`BтCQ2ЎПҐЎClBCСЧCВэ╩²h╪ClC─Ґ,╪іBхCK2Ў/ПҐЎ╩ю╩═D@D@@.ТBтCZBПrBА$Ґ▓Ґ3>Cз┌─Cз┌CZ┐╩▌щ─╪%} Cз┌╪╦╪╦BДrBу$Ґ╒Ґ;>╪⌠Ў╪╪$Db≤CСЧ╪⌠╪─c/&CHCHCB▓BhЮҐ3=Ґ▓CСЧClD╪╨g╩█П╪⌠ЎCСЪ╪іҐ,BЫ$BPЮҐ;=Ґ╒╪%}─╪%~╪╔}Dq"─Cз┌Ю╪%~∙/ICZBтCW2ҐЎЎПD@╩ю╩═D@╪═CQ2Ў═@ҐЎЎ/П╪╪⌠╪CE≥DrClB╪р/WC`CQ2Ґ+ЬҐЎAПЗCСЩ─╪⌠ю╩²h─╪"ClBCСЪ╪іBтCK2Ґ7ВЧҐЎAп╩юD@D`╩ю/ICZҐ,BА$Ґ░Ґ3=BmПCз┌─╪%}╩▌эю╪╔─Cз┌ЮCз┌╪╦CHBу$Ґ░Ґ;=B]П╪─Cl@Db≈─CВч╪⌠Ў╪A/&CH╪╦BhД╪ҐnҐ▓BлбClB╪╩█ЯCE≤CСЧClC─Ґ,CZBPДҐэҐ╒Bдб╪%}─Cз┐Dq#@CZ─╪%} ╪%~d.ТBт╪і╪╗нЎПBПB╩ю╩═D@D@C`Ў═0╪ўнЎ/ПBХAЪ╪⌠ЎCСЧDr╪╨h╪╪⌠╪─r.Ї╪═Ґ+З╪ўнAПBПB╪⌠Ў╪╪$Db≤CСЧ╪⌠╪─BтCZҐ7З╪ЄнAпBХBD@D`╩ю╩юd.zҐ,╪іҐ▌ҐэBmНBлб╪%}─╪%~╪╔}Dq"─Cз┌Ю╪%~CHCHҐ▌Ґ*эB]НBдбClBCСЧCВэ╩²h╪ClC─A.H╪╦╪╦╪ҐnҐ≈ BлцBmП╪╪⌠╪CE≥DrClB╪CZBтҐэҐ╞ BдцB]ПCз┌─Cз┌CZ┐╩▌щ─╪%} Cз┌.%╪іҐ,╪╗нBПBAП╩юD@D`╩юC`╪ўнA_юBХBAпCСЧClD╪╨g╩█П╪⌠ЎCСЪр.╪═╪ўнBтBПBЎП╪─Cl@Db≈─CВч╪⌠Ў╪CZҐ,╪ЄнBхBХBЎ/ПD@╩ю╩═D@∙.%╪іBтҐэBПpBлцҐ▓╪%}─Cз┐Dq#@CZ─╪%} ╪%~CH╪╦Ґ*эBДpBдцҐ╒CСЩ─╪⌠ю╩²h─╪"ClBCСЪc.H╪╦CHҐ≈CB▓BmНҐ3=Ъ╪⌠ЎCСЧDr╪╨h╪╪⌠╪─Bт╪іҐ╞BЫ#ЧB]НҐ;>Cз┌─╪%}╩▌эю╪╔─Cз┌ЮCз┌@.zҐ,CZCW2AПҐҐЧD@D`╩ю╩ю╪═A_пCQ1ЧAпҐЎClB╪╩█ЯCE≤CСЧClC─?1D`D`╪@╪@D`╩═╪@Cю╩═╩═CюCю╩═D`Cю╪@>Р1C`BтCQ2ЎПҐЎCl@CСЧCВч╩²h╪ClC─Ґ,╪іBхCK2Ў/ПҐЎ╩ю╩═D@D@?1TBтCZBПpBА$Ґ▓Ґ3>Cз┐Cз┌CZ─╩▌щ─╪%~Cз┌╪╦╪╦BДpBу$Ґ╒Ґ;>╪⌠ю╪╪"Db≤CСЪ╪⌠╪─?#1├CHCHCB▓BhЮҐ3>Ґ▓CСЧClD╪╨h╩█П╪⌠╪─CСЪ╪іҐ,BЫ$BPЮҐ;>Ґ╒╪%}╪%~╪╔─Dq"─Cз┌╪%~?U1╘CZBтCW2ҐЎЎПD@╩ю╩═D@╪═CQ2Ў═@ҐЎЎ/П╪╪⌠╪CE≤DrClC─╪?▓1ЇC`CQ2Ґ+ЬҐЎAПЗCСЧ╪⌠ю╩²h╪"ClC─CСЪ╪іBтCK2Ґ7ВЧҐЎAп╩юD@D`╩ю?о1╘CZҐ,BА$Ґ░Ґ3>BmПCз┌╪%}╩▌щ─╪╔─Cз┌Cз┌╪╦CHBу$Ґ░Ґ;>B]П╪Cl@Db≤CВч╪⌠╪─╪@1├CH╪╦BhЮ╪ҐnҐ▓BлбClD╪╩█ПCE≤CСЪClC─Ґ,CZBPЮҐэҐ╒Bдб╪%~Cз┐Dq"─CZ─╪%~╪%~@$1TBт╪і╪╗нЎПBПB╩ю╩═D@D@C`Ў═@╪ўнЎ/ПBХAЪ╪⌠╪CСЧDr╪╨h╪╪⌠╪─@21╪═Ґ+Ь╪ўнAПBПB╪⌠ю╪╪"Db≤CСЪ╪⌠╪─BтCZҐ7Ь╪ЄнAпBХBD@D`╩ю╩ю@$0зҐ,╪іҐ░ҐэBmПBлб╪%}╪%~╪╔─Dq"─Cз┌╪%~CHCHҐ░Ґ*эB]ПBдбCl@CСЧCВч╩²h╪ClC─@0╗╪╦╪╦╪ҐnҐ≈ BлбBmП╪╪⌠╪CE≤DrClC─╪CZBтҐэҐ╞ BдбB]ПCз┐Cз┌CZ─╩▌щ─╪%~Cз┌?о0┘╪іҐ,╪╗нBПBAП╩юD@D`╩юC`╪ўнA_юBХBAпCСЧClD╪╨h╩█П╪⌠╪─CСЪ?▓0w╪═╪ўнBтBПBЎП╪Cl@Db≤CВч╪⌠╪─╪CZҐ,╪ЄнBхBХBЎ/ПD@╩ю╩═D@?U0┘╪іBтҐэBПpBлбҐ▓╪%~Cз┐Dq"─CZ─╪%~╪%~CH╪╦Ґ*эBДpBдбҐ╒CСЧ╪⌠ю╩²h╪"ClC─CСЪ?#0╗╪╦CHҐ≈ CB▓BmПҐ3=Ъ╪⌠╪CСЧDr╪╨h╪╪⌠╪─Bт╪іҐ╞ BЫ#ЧB]ПҐ;>Cз┌╪%}╩▌щ─╪╔─Cз┌Cз┌?0зҐ,CZCW2AПҐҐЧD@D`╩ю╩ю╪═A_юCQ1ЧAпҐЎClD╪╩█ПCE≤CСЪClC─?R'ВD`D`╪@╪@D`╩═╪@Cю╩═╩═CюCю╩═D`Cю╪@?2'ВC`BтCQ2ЎПҐЎCl@CСЧCВч╩²h╪ClC─Ґ,╪іBхCK2Ў/ПҐЎ╩ю╩═D@D@?@(4BтCZBПpBА"Ґ▓Ґ3>Cз┐Cз┌─CZ─╩▌щ@╪%~Cз┌╪╦╪╦BДpBу"Ґ╒Ґ;>╪⌠ю╪╪"Db≤CСЪ╪⌠╪─?c(fCHCHCB▓BhХҐ3>Ґ▓CСЧClB╪╨h╩█Я╪⌠╪─CСЧ╪іҐ,BЫ$BPХҐ;>Ґ╒╪%}╪%}─╪╔─Dq"юCз┌╪%~?∙(┴CZBтCW2ҐЎЎПD@╩ю╩═D@╪═CQ2Ў═0ҐЎЎ/П╪╪⌠ЎCE≤DrClC─╪?р(≈C`CQ2Ґ+ЗҐЎAПЗCСЧ╪⌠Ў╩²h╪$ClC─CСЧ╪іBтCK2Ґ7ЫЧҐЎAп╩юD@D`╩ю@(┴CZҐ,BА$Ґ▄Ґ3>BmПCз┌╪%}─╩▌щ─╪╔Cз┌Cз┌╪╦CHBу$Ґ▄Ґ;>B]П╪ClBDb≤CВэ╪⌠╪─╪@A(fCH╪╦BhЮ╪ҐoҐ▓BлбClD╪╩█ПCE≤CСЪClC─Ґ,CZBPЮҐчҐ╒Bдб╪%~Cз┌─Dq"─CZ│╪%~╪%~@d(4Bт╪і╪╗нЎПBПB╩ю╩═D@D@C`Ў═@╪ўнЎ/ПBХAЪ╪⌠╪CСЧDr╪╨h╪╪⌠╪─@r'В╪═Ґ+Ь╪ўнAПBПB╪⌠ю╪╪"Db≤CСЪ╪⌠╪─BтCZҐ7Ь╪ЄнAпBХBD@D`╩ю╩ю@d'╨Ґ,╪іҐ░ҐчBmПBлб╪%}╪%}─╪╔─Dq"юCз┌╪%~CHCHҐ░Ґ*чB]ПBдбCl@CСЧCВч╩²h╪ClC─@A'┬╪╦╪╦╪ҐnҐ≈BлбBmП╪╪⌠ЎCE≤DrClC─╪CZBтҐэҐ╞BдбB]ПCз┐Cз┌─CZ─╩▌щ@╪%~Cз┌@'e╪іҐ,╪╗нBПBAП╩юD@D`╩юC`╪ўнA_пBХBAпCСЧClB╪╨h╩█Я╪⌠╪─CСЧ?р'W╪═╪ўнBтBПBЎП╪ClBDb≤CВэ╪⌠╪─╪CZҐ,╪ЄнBхBХBЎ/ПD@╩ю╩═D@?∙'e╪іBтҐэBПtBлбҐ▓╪%~Cз┌─Dq"─CZ│╪%~╪%~CH╪╦Ґ*эBДtBдбҐ╒CСЧ╪⌠Ў╩²h╪$ClC─CСЧ?c'┬╪╦CHҐ≈ CB▒BmПҐ3=Ъ╪⌠╪CСЧDr╪╨h╪╪⌠╪─Bт╪іҐ╞ BЫ!ЧB]ПҐ;>Cз┌╪%}─╩▌щ─╪╔Cз┌Cз┌?@'╨Ґ,CZCW2AПҐҐЧD@D`╩ю╩ю╪═A_юCQ1ЧAпҐЎClD╪╩█ПCE≤CСЪClC─Rick CattellMark Brown-р2W-р/≈6▓/≈6▓2W-р2W-Р2W-Р/≈╩ю╩═D@D@-╡2WD@D`╩ю╩ю-р/Ї6▓/ЇD@╩ю╩═D@-р/w╩юD@D`╩ю6r/≈6r2WD@D`╩ю╩ю6╡/≈╩ю╩═D@D@6▓27-р27╩юD@D`╩ю6▓2wD@╩ю╩═D@2R2W2R/в╩ю╩═D@D@22WD@D`╩ю╩ю.,.)W6р)W6р,.,.2,.2)W╩ю╩═D@D@-Р,D@D`╩ю╩ю.)w6р)wD@╩ю╩═D@.)7╩юD@D`╩ю6╡)W6╡,D@D`╩ю╩ю6Р)W╩ю╩═D@D@6р+В.+В╩юD@D`╩ю6р,7D@╩ю╩═D@2╡+в2╡)W╩ю╩═D@D@2r+вD@D`╩ю╩юofofisis5р*вEн(├Aя Bд4@©"ю@╪є3╪;ГіCЧҐ'$╩╟O─╩╛░@BьыCЧю╨8QDeз╪)s╗╩≈╛9Bэ╘ЮCф Z╩ю©Ґ─CЪ9D`B─@B`╩ю:≤*≈EI┘|╪WЎЎ╙╪├ф▄Ґ┐(@@~CУФ╪°P╩÷╙╪CcЁCУЕ@╨ҐУЛDo╞aҐ═И╪8ї:Ґ÷хAЗ░@╪ЯBьэDO╟─DSoюҐ''╪Я@<н)СDо?K╩╪Щ,@ВлҐ╩░ҐЄQ A~x─CЛr╪<─╩√х╪!S─CцЧ@CЛr╩6И╒D[і┼@[╪Ў;`Ґ╨~ЮAвСю╪ Cc╟D`UCЪ╪°O╪ ю>)RDш[У╩█oсҐ÷B╪є@уШBдя@CДЙ╪1A╩▓{─╪7bCн©@CДХю╩)ґЗDц[ЖB@─ Ў%≈═Ґ÷@═Ґ╡╔─╪▌CцЧ─Di8Cч╛─╪<ю╪▌/0╦╨?У\╩─╙B?АЬ?Хх©&©─╪Х─ҐtCмDlц─BЩ█╪ХEуoDю╙BALЎ┐o©┼@я─CЭ9BШ|╪2╩⌠fҐ─CЭ8ю+/╦╨74╞╩6Z┼ЎWЎ ЮҐ├╔CZ)╟╪EҐ8(CЦхDhBгщ╪DEл▓еDVс╘╪6АPCЭ ├BР]─╪╚PCЭ─BЩ▄╪2Щ╩⌠<─ҐsCЭ&v.Ї╨ p╩;,└╩╘хDо{C~'─╪Ь╪─AQ@DAЦюD^І─Ўўэ╪FAі°╪╛╡Ґ└Ъю©┬╪╙ы░CЙEЗCЧ╩Bгь╪8╩≈ЬҐ8#CЧ╪.Н*W╨─pdDC┐AAoю─ЪЎ1ЪЎDх╪ф─Bp─DJ(юDXc─Ґ▐─╪фEюpc╪hҐ╪ЮҐ*Ї■ADб─AС@CЧД─Ґ<ж╩ЁЖ@╩╘9─Bц(CЧДю*Н*в╨ёDWЗ0╪Єў╟╪÷ЧHCspCЮк|╪а─BШ DU5@DMй─ҐЮ─╪аюEщmT╩#j≥CМе@D{n╪ўn░╪8└CЪ9─Ґ▐─╩╣в@╩ї°─Bp─CЪ:$й+╦╨ўDЮpЖCЯтЮDдкҐ├Ю╪.╪А─CoЛDc┬@CТЇ╪░─╪Б@EвЭШ╨╙sКЎІ│CPLCf≥░CхшCЭ>─ҐБ╩╙йю╩╡5@BШ CЭ> -Ь╩⌡q*CАд╙@hтюю.,─╪ ─CpЄDc╨@CТ╪▐L╪ Ddc─╪█Чю5V?I^?н╚?CїCС╪░╩°x@╪JCoЛ─CС@ConferencePapersub-domain of Documentwhich can participate in a "presentation" relation.AuthorrelationPresentationrelation8R≈EpєЭюўXNҐ ▀─Ў÷╞ю╪ЄБ─CаbCШЭBЪ0╪3І╩⌠@ҐпCШЩ ╨ёh╩║К╩ёщPD]▐─Cе`ю╪┘Aт╩©Ъ─D@D_Щ@╩ю; уD{u:C~╔r╪╞ЇЗBbsLBg,pBAнПCП:C{Ґ0l╩█ ─╪└ДCП: ╩≥UТ╪b[╪ёуNBмbBцqлAqH╪ҐнCлKDlД@BЪ0╪═~╩╟ФЪҐ<╪©s─BRб═Bo-═╪Ґ╪-Ы─ҐХDr╣юCр╪╪Ю=VУDIжWDiv╛╪╣Ы╣BRPBMc╪BN+ПC]йCВDAА╩║G@╪ФC]й╪T6╩>оFҐ ▒ю≤HAи(─BбЭ╪6√╪$─╪,"Dk}CХз─╪6√`=оэDs│BEIVп╪─иCрІ╦C@²dҐJBА4CЩ╛DR─╩ўП─╪TBА3─╩©┤Й╨╛є╗Ґ°▌Ь╪ЇҐ 8CfЬ╪╒6╪Ф╩ЎD^╦юCВ╪╒6>s!]Dо╒EФЖ▌╪ёФ╪┤═B{xCQ7pBыЬCЧ─DSB╩╟ ю╪ЪBыЖ╩;я╨ {Gю?©(БҐ┤8╪╡g░Ґл╪T╩ґЕ─DQ─CЩ╛Ґл─я.`DЦo╨*rn@\@Ў╚рҐ⌡X Ў)═─C@$╪─╩⌠─Cко─CШК─C@$╩&чEжДч╪╦ж≤Ґі═B\СЮBG?ю╪╦вCЗУDnю╪:i╪ ╪╦ьQ(ЪDфьн╨;▐TҐ°≤AИCщ╨ДCCмCu"╪/╩█ZюBГЮCЯпЮCu!╩Г└Ez├╦DuЬ┴DJd╪,_╪┤4П╪©эCШЙ─DlЫ─╪40─╪─╪©э ╛$ЮCТe^╩▌ФAИ▓юBео─Aуc`ЎФ═CхҐ─╪ґ─╩▄ё─Ў├╟CИR@CхЎ╩Ї2ТDihfBNЛpBлйxAe @ЎI`╪┼чCЯп─Dr╔─Ґ&╪.`╪┼щ!,$ Dб╚°╩wЫCRПТCWгТ@в5Ґ·уCэВ╪(╩▐├ю╪≥CвЩCэЖ─╩'▓XDс╡Bн:ьCK▓юBе`Ґ©bП╪7B─CИR─Ds\─AyP╪ґ═╪7B"b"їEI╟Ї╨╨@РCнЕCх-TҐ┼Ґ┌бЮCИm─╪7j╩■ь@╪*q─Cх√ЮCИm═╨╛a/DС%Ґ%к CWпPCSAf$─╪# CвЭ─Dpy@CfМ╪(╪#─$Д ╠EкZЎ╨≤<Ї╪≥r─CЬУ(Cpз@B@YCУ─╪≤@╩·∙ю╪Y─CgюCУ`╨0y═EF│ЦCжНЮDQ<└╪╦▓юҐ1w─╪▓─Cх√Dk'юCу▌─╪7i ╪▓`)÷ТE~≈5╩ц┬Co▌CДКрҐ┐·ю╪╨bCЫ╟─╪╟⌡╩╔b@╩╦∙COdCЫ╟`╨<╔мDвАдҐІЛ@Ap─BНХ═BЬ▀х╪ Ш─CgюDaj@CШі─╪≤@╪ Ш═Conferencedomainofatby3QQ╩≤Б└╨=°ЎЮҐ'√`╪?ы*CиІ ╪■є╪м╪bDb\CТ2─╪■єDГ;XEo╩%╩∙іDMi╗Ў■i═A`R╟AsґП╪)"╪!Щ@╪⌠ЄDp(Cч@╪)!юCuуC~═╗Ў╨╟Ў≤ЁpAcґPApрCо╨CД#─Cфz╩▓"ю╪щюCо╨1JА╩╘?√╩╒≈╪І│НAыЁпBYзХBB▌╗╪╙╪5ыЎюDsS═Cй&─╪╙═Djі╗DKл▄╪ЎQAевюBEBI-XCжчCч─ClL╩▐ь@╪!ЩюCжч0┌3╩─я╩╔ ┼╪╚B}hПBj╒пAы≤п╪ ╪≤CMОDq╦юCgЩ─╪ @Dк8РDBАД╪╦≤$BlB(BF²0AПw0CХUCй'AН`╩▄╛`╪5ь─CХU`/e⌠╩Є╩ірп╪≤.CEД3BеJпAH╟п╪─ҐИCрэ─Dkў═BП╪DЯB├CЕ╔ ╪╦3аh╪vCBЩ─DVЦюDKХ ╪Ґ@╪vEgD▌╩░~©=ІЎ│#ЮAЛw@Bw0CЭВҐ(╩╛╪╩╟!юBНвCЭЖЮ# ╨ВLDВUBи°═Ґ!'ьҐ=─Ў!▓═╪R─BСБDTDOҐ─╪R`EНчб╩С.Ґ ╪╘юhBaёAП╔`CШ┼╪Ґ─╩╘@╩ЄЮCBЭюCШ┼+ь╨$лЕDтдZҐ;' Ґя░Aя&─BN║═╪╩─BИ:DR] DPлҐф╪╩═Eэfr╩2b-A@ю─Ў9─ҐІ`CЭґ─Ґ╩╚О╩╟ЗBСА─CЭґ═ACM SIGMOD 1982The Cedar DBMS: APreliminary Report.87.5w6р5w6р87.87.287.25w╩ю╩═D@D@-Р87D@D`╩ю╩ю.5≈6р5≈D@╩ю╩═D@.5W╩юD@D`╩ю6╡5w6╡87D@D`╩ю╩ю6Р5w╩ю╩═D@D@6р8.8╩юD@D`╩ю6р8WD@╩ю╩═D@2▓872▓5Ї╩ю╩═D@D@2R87D@D`╩ю╩ю?77D`D`╪@╪@D`╩═╪@Cю╩═╩═CюCю╩═D`Cю╪@>Р77C`BтCQ2ЎПҐЎCl@CСЧCВч╩²h╪ClC─Ґ,╪іBхCK2Ў/ПҐЎ╩ю╩═D@D@?7tBтCZBПpBА$Ґ▓Ґ3>Cз┐Cз┌CZ─╩▌щ─╪%~Cз┌╪╦╪╦BДpBу$Ґ╒Ґ;>╪⌠ю╪╪"Db≤CСЪ╪⌠╪─?#7іCHCHCB▓BhЮҐ3>Ґ▓CСЧClD╪╨h╩█П╪⌠╪─CСЪ╪іҐ,BЫ$BPЮҐ;>Ґ╒╪%}╪%~╪╔─Dq"─Cз┌╪%~?U7иCZBтCW2ҐЎЎПD@╩ю╩═D@╪═CQ2Ў═@ҐЎЎ/П╪╪⌠╪CE≤DrClC─╪?▓7вC`CQ2Ґ+ЬҐЎAПЗCСЧ╪⌠ю╩²h╪"ClC─CСЪ╪іBтCK2Ґ7ВЧҐЎAп╩юD@D`╩ю?о7иCZҐ,BА$Ґ░Ґ3>BmПCз┌╪%}╩▌щ─╪╔─Cз┌Cз┌╪╦CHBу$Ґ░Ґ;>B]П╪Cl@Db≤CВч╪⌠╪─╪@7іCH╪╦BhЮ╪ҐnҐ▓BлбClD╪╩█ПCE≤CСЪClC─Ґ,CZBPЮҐэҐ╒Bдб╪%~Cз┐Dq"─CZ─╪%~╪%~@$7tBт╪і╪╗нЎПBПB╩ю╩═D@D@C`Ў═@╪ўнЎ/ПBХAЪ╪⌠╪CСЧDr╪╨h╪╪⌠╪─@277╪═Ґ+Ь╪ўнAПBПB╪⌠ю╪╪"Db≤CСЪ╪⌠╪─BтCZҐ7Ь╪ЄнAпBХBD@D`╩ю╩ю@$6ЗҐ,╪іҐ░ҐэBmПBлб╪%}╪%~╪╔─Dq"─Cз┌╪%~CHCHҐ░Ґ*эB]ПBдбCl@CСЧCВч╩²h╪ClC─@6х╪╦╪╦╪ҐnҐ≈ BлбBmП╪╪⌠╪CE≤DrClC─╪CZBтҐэҐ╞ BдбB]ПCз┐Cз┌CZ─╩▌щ─╪%~Cз┌?о6╔╪іҐ,╪╗нBПBAП╩юD@D`╩юC`╪ўнA_юBХBAпCСЧClD╪╨h╩█П╪⌠╪─CСЪ?▓6≈╪═╪ўнBтBПBЎП╪Cl@Db≤CВч╪⌠╪─╪CZҐ,╪ЄнBхBХBЎ/ПD@╩ю╩═D@?U6╔╪іBтҐэBПpBлбҐ▓╪%~Cз┐Dq"─CZ─╪%~╪%~CH╪╦Ґ*эBДpBдбҐ╒CСЧ╪⌠ю╩²h╪"ClC─CСЪ?#6х╪╦CHҐ≈ CB▓BmПҐ3=Ъ╪⌠╪CСЧDr╪╨h╪╪⌠╪─Bт╪іҐ╞ BЫ#ЧB]ПҐ;>Cз┌╪%}╩▌щ─╪╔─Cз┌Cз┌?6ЗҐ,CZCW2AПҐҐЧD@D`╩ю╩ю╪═A_юCQ1ЧAпҐЎClD╪╩█ПCE≤CСЪClC─56вEд?~BЮA3Ў╩аЎў■AЪ╩4CЪЮAз╟╪═╩²B─Ў%\CЪЮ╨<~Э╪═A3Ґ▐Ё@BчТgAжFЎдл╪Ў╔юCШ╪DacAZ`╪9Q6ВEэП╣CаИ`ҐЄ CYГчBL9@Ґ┬≥└CЪ╒BMp╪Ц╩⌡oҐ╡░CЪ╒ю╨$xZ╪Т╟Ў÷юю╒Ў'Ґ─ByV|╪ Ў%PCВ`DbҐ─Aзє╪ 4ж1EрCr╩Ёє┴Ґ²8─@PЪ─AюE─Cp√чCЪЩ@М─╪■╩÷'©─CЪЩю╨.├ДҐ:H▄Ґ`DUcfBc∙@╪█╩"╪зBvDJєDWЭ─Ґ┴Р╪з9Р0ЇEп┐╪BдЕuҐЮDR≤ЗBbН─╪▓┐^CЧ╡Bхь╪÷╩≈ъҐ7(CЧ╡@╨0Aч╩єNWҐ°Ъ@©└═Aб#Cp╒╪©─CЩlD`ы@М─╪@Nori Suzuki/^6≥╨ІYЗ╩█02BaGюAшП@AяS─Ґ*`╪g╪┌═Bф<Ds ─C}c─╪g@EDЁСDм03Cgs@╪6²лҐ*с Bз-═CВCC\Ж╪°Й╩▐P╪ё─CВC@-"5⌡╨└╔╒╨╨Є╪DC╙╩┌Еd╪6пDCН╪Й╪6ЛЎ7─Ds[Cию╪И─Eu<╗EQ├╟╪9-░DQНC`╩╧їCО≥C}`Ґ9д╩▄У─╪┌°─CО≤ю)└2Щ╨║Сd╨Ў≥7╪<xCшёBдЫ═Ў.ш╪ .╪⌡РCU▐DqaCd╪ .Eh█≈Dьи╒╪ ▄`CrїPAэИ─Bг5@CИ─CиAхx╩▄╔╪6ЛCИ@&a1H╩÷}M╪. мЎ0о─AI" AEщю@[╪z╪єbCe║Dp▄C[²╪zDb/√CкA╚Ў4< @В]юAAB@@~ОCУрCd╪╙q╩▌÷╪⌡РCУр%²0Ы╨6& ╩к*╪?п╗CО2юBМJю╪╘≥,╪,╪ЇЗCдоDn ─CH╪,Eл©хDзеAcҐ"▌Ґ9А@C]тCВ┘─C[·╪ _╩▐t╪єdCВ├ ш/x╨╞ц$╩║ФЮAvЫ─Ў(ж©E@Н╦╪┐─╪╣╙CбҐ─Dnr─CJT╪└EOА▓D`Сp@nд?б?ъЛЎҐєCЗтCH╪;1╩▒ъ─╪ЇЫCЗтofisFigure 4-1: A fragment of a simple database of documentsFigure 4-2: A fragment of a document database including conference papers,Н)О -ptТF ptpt ptptpТXtТFptНpНjОd2XM\д1iG(Н rО_В$qНрО[ЇНRО[вН,╡О[ЇН;рО[вН;╡ОZ7Н,▓ОZ7Н2ОZНRОZWЬxШ7ЬШ7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7ЬxШ7ЬШ7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7pН2ОUЬx Ш7ЬШ7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7ЬxШ7ЬШ7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Н@rОUWН@▓ОKв ЬЪШЬШ#Ш#Ш#Ш#Ш#ЬЪШЬШ#Ш#Ш#Ш#Ш#ЬЪШЬШ#Ш#Ш#Ш#Ш#ЬЪШЬШ#Ш#Ш#Ш#Ш#НRОVwНРОK≈ НРОJЬЪ ШЬШ#Ш#Ш#Ш#Ш#НОTвНrОJ≈Н.2ОWЇН.▓ОQ7Н.РОK≈Н3ОQwН32ОK≈Н2▓ОW≈НОQВНrОGЇШ7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Н╡ОTвН 2ОJ≈ЬxШ7ЬШ7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7ЬЪШЬШ#Ш#Ш#Ш#Ш#Ш#ЬxШ7ЬШ7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7ЬxШ7ЬШ7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7ЬxШ7ЬШ7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7НAО0вНA2О'W ЬЪШЬШ#Ш#Ш#Ш#Ш#ЬЪШЬШ#Ш#Ш#Ш#Ш#Н/RО2вН/rО,ЇН3РО,вН3rО2вШ7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7qНRО7ВНРО6WН rО7П3Н.РО<ЇН.╡О;Н.▓О#Н/рО!WШ7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7НRОW НРОЇpН.ОвН2rОвН7ОвШ7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7НРОН╡О.ВНRО-WЬЪШЬШ#Ш#Ш#Ш#Ш#ЬxШ7ЬШ7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7Ш7НAО6≈ Ш7Ш7Ш7Ш7Ш7Ш7Н/rО8ЇН3▓О8ЇqН рО?вП8Н rОПJXo EЩ1tu░APPLICATION EXAMPLE534.3 ExampleThe following program defines a small schema and database of persons and documents. It illustratesthe use of most of the procedures defined in Section 3.DocTestImpl: PROGRAM IMPORTS DB, IO, Rope =BEGIN OPEN IO, DBtty: IO.Handle_ CreateViewerStreams["VLTest1Impl.log"].out;Person, Conference: Domain;Thesis, ConferencePaper, Document: Domain;author: Relation; authorOf, authorIs: Attribute;presentation: Relation; presentationOf, presentationBy, presentationDate: Attribute;publDate: Attribute;rick, mark, nori: --Person-- Entity;cedarPaper, cypressDoc, thesis: --Document-- Entity;Initialize: PROC = BEGIN tty.PutF["Defining data dictionary...\n"]; -- Declare domains and make ConferencePapers and Theses be subtypes of Document: Person_ DeclareDomain["Person"]; Conference_ DeclareDomain["Conference"]; Document_ DeclareDomain["Document"]; ConferencePaper_ DeclareDomain["ConferencePaper"]; Thesis_ DeclareDomain["Thesis"]; DeclareSubType[of: Document, is: ConferencePaper]; DeclareSubType[of: Document, is: Thesis]; -- Declare publDate property of Document publDate_ DeclareProperty["publDate", Document, IntType]; -- Declare author relation between Persons and Documents author_ DeclareRelation["author"]; authorOf_ DeclareAttribute[author, "of", Document]; authorIs_ DeclareAttribute[author, "is", Person]; -- Declare presentation relation presentation_ DeclareRelation["presentation"]; presentationOf_ DeclareAttribute[presentation, "of", Document]; presentationBy_ DeclareAttribute[presentation, "by", Person]; presentationAt_ DeclareAttribute[presentation, "at", Conference]; END;НxО[5ptТF ptН;РpНОSZrТ─ НОO~pТ┐П<Т└П'НОMIТ─П7НОFBuТXНОDxНО@БНО=MП;НО9╦НО7МП*НО6#НО4XНО2▌НО0цП>НО.ЬНО-.П$НО+cП4НО'нНО&НО$9П,НО"nПRНО ёП"НОыП*НОП&НОDП4НОyП"НОўП4НОДП+НОП*НОOП;НО└П:НО╧П$НООП6НО$П4НО ZП"НО▐П0НОдПBНОЗП@НО/ПDНОdrЇ╪>Q\OЇDESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL54InsertData: PROC = BEGIN t: Relship; tty.PutF["Inserting data...\n"]; cedarPaper_ DeclareEntity[ConferencePaper, "The Cedar DBMS"]; cypressDoc_ DeclareEntity[Document, "Cypress DB Concepts & Facilities"]; thesis_ DeclareEntity[Thesis, "An Analysis of Priority Queues"]; sigmod_ DeclareEntity[Conference, "SIGMOD 81"]; rick_ DeclareEntity[Person, "Rick Cattell"]; mark_ DeclareEntity[Person, "Mark Brown"]; -- Note we can create entity and then set name... nori_ DeclareEntity[Person]; ChangeName[nori, "Nori Suzuki"]; -- Data can be assigned with SetP, SetF, or DeclareRelship's initialization list: t_ DeclareRelship[presentation,, NewOnly]; SetF[t, presentationtOf, cedarPaper]; SetF[t, presentationBy, mark]; SetF[t, presentationAt, sigmod]; []_ SetPList[cypressDoc, authorIs, LIST[rick, mark]]; -- the Cedar notation LIST[ ... ] defines a list []_ SetPList[cedarPaper, authorIs, LIST[rick, mark, nori]]; []_ DeclareRelship[author, LIST[[authorOf, thesis], [authorIs, mark]]]; []_ SetP[cypressDoc, publDate, I2V[1982]]; []_ SetP[thesis, publDate, I2V[1977]]; -- the I2V[...] calls needed because Cedar Mesa does not yet coerce INT to REF ANY -- Check that thesis can't be presented at conference: ok_ FALSE; t_ DeclareRelship[presentation]; SetF[t, presentationOf, thesis ! MismatchedAttributeValueType => {ok _ TRUE; CONTINUE}]; IF NOT ok THEN ERROR; END;DestroySomeData: PROCEDURE = -- Destroy one person entity and all frog entities BEGIN flag: BOOL_ FALSE; tty.Put[char[CR], rope["Deleting Rick from database..."], char[CR]]; DestroyEntity[DeclareEntity[Person, "Frank Baz", OldOnly]]; DestroyDomain[Frog]; END;PrintDocuments: PROC = -- Use DomainSubset with no constraints to enumerate all Documents BEGIN doc: -- Document -- Entity; authors: LIST OF Value; es: EntitySet; tty.PutF["Documents:\n\n"]; tty.PutF["Titleauthors\n"];Н)О\rptТF ptpt ptptpТXtТFptНpН{ОT≈uТXН{ОRлН{ОQП"Н{ОO7П?Н{ОMlПJН{ОK╒ПBН{ОIвП1Н{ОHП.Н{ОFBП,Н{ОDwП3Н{ОBґН{О@БП"Н{О?ПSН{О=MП,Н{О;┌П)Н{О9╦П"Н{О7МП$Н{О6"П7Н{О4XП4Н{О2█П=Н{О0бПIН{О.ЬП,Н{О--П(Н{О+cПVН{О)≤П8Н{О'мН{О&П"Н{О$8Н{О"nП=Н{О ёН{ОьН{ОCН{ОyП4Н{ОўН{ОЦПFН{ОП=Н{ОNН{О┐Н{ОНН{О$ПDН{О YН{О▌Н{ОдН{ОЫН{О/Н{ОdН6Ъ╗M 6▒]▄ьAPPLICATION EXAMPLE55 es_ DomainSubset[Document]; WHILE (doc_ NextEntity[es])#NIL DO tty.PutF["%g", rope[GetName[doc]]]; authors_ GetPList[doc, authorIs]; FOR al: LIST OF Entity_ NARROW[authors], al.rest UNTIL al=NIL DO tty.PutF["%g ", rope[GetName[al.first]]]] ENDLOOP; ENDLOOP; ReleaseEntitySet[es]; END;PrintPersonsPublications: PROC [pName: ROPE] = -- Use RelationSubset to enumerate publications written by person BEGIN p: Person_ DeclareEntity[Person, pName, OldOnly]; authorT: --author-- Relship; rs: RelshipSet; first: BOOL_ TRUE; IF p=NIL THEN {tty.PutF["%g is not a person!", rope[pName]]; RETURN}; tty.PutF["Papers written by %g are:\n", rope[pName]]; rs_ RelationSubset[author, LIST[[authorIs, p]]]; WHILE (authorT_ NextRelship[rs])#NIL DO IF first THEN first_ FALSE ELSE tty.Put[rope[", "]]; tty.Put[rope[GetFS[authorRS, authorOf]]]; ENDLOOP; tty.PutF["\n"]; ReleaseRelshipSet[rs]; END;tty.Put[rope["Creating database..."], char[CR]];Initialize[];DeclareSegment["[Local]Test", $Test, 1,, NewOnly];OpenTransaction[$Test];Initialize[];InsertData[];PrintDocuments[];PrintPersonsPublications["Mark Brown"];DestroySomeData[];PrintDocuments[];CloseTransaction[TransactionOf[$Test]];tty.Close[];END.ЪНgОWptТF ptН9АpНОO7uТXНОMlП$НОK║НwНОIвП%НОHПDНОFBП8НОDwНОB╛НО@БНО=MП.НО;┌ПCНО9ЇНО7МП3НО6"НО4XНО2█НО0бНО.ЬП;НО--П7НО+bП2НО)≤П)НО'мП8НО&П-НО$8НО"mНО ёНОьНОxП0НОўНОЦП2НОНОNНО┐НО╧НОНП'НО#НО YНО▌П'НОдНОdЪД хъ+oX,╟575. Data model design issuesA number of decisions were necessary in the design of the Cypress data model described in thispaper. A few of these decisions were made arbitrarily because no solution was obviously best. Forthe most part, however, the criteria of simplicity and utility discussed in Section 1, as we interpretthem for the applications we envision, clearly point towards the model we have developed. Thedecisions that led to the Cypress model chosen are discussed in this section.5.1 Relations and attributesThe Relational model, as described by Codd[1970], was the obvious starting point for the Cypressmodel. The paper by Codd is easily the most referenced paper in the database literature and theRelational model is widely acknowledged as simple yet reasonably powerful. There have actuallybeen a number of interpretations of "Relational model" in various implementations (such as SystemR by Astrahan et al [1976] and INGRES by Stonebraker et al [1976]). However, allimplementations share the most basic idea of a database as a set of relations whose columns areattributes and whose rows are tuples, and most of them share the idea that the tuple attribute valuesmay be strings, numbers, and booleans.The fundamental type constraint, which states that all the relationships in a relation have the samenumber and types of attributes, is almost the same in all data models defined since the Relationalmodel. The wording changes somewhat with the introduction of entities or type hierarchies, andsome additional constraints are added with the introduction of keys, names, and normalization. Wewill discuss these minor differences as we contrast the various data model features.5.2 Entities and domainsCodd [1979] introduced the idea of referential integrity: that attribute values come from domainssuch as "People" or "Parts." However, few implementations or theoretical studies of the Relationalmodel carry this idea through to enforcing that persons or parts with unique names actually existwhen referenced and that all references to these domains in a database are consistent. Thus, weintroduce the concept of an entity to provide the important function of recognizing the objects weare trying to represent in the database. The entity idea frees applications from the integritychecking necessary in the Relational model on strings and numbers that are being used as uniqueidentifiers for objects. We are used to the idea of objects as distinguished from their name,attributes, and relationships to other objects; the introduction of entities thus fulfills the simplicity(understandability) as well as utility criteria.ЪНG╘ОfЯpНЇО^оqТ─НЇОZСpТ╛ ТґПSНЇОX©Т┴П%Т┼П>НЇОV┼Т⌡ПfНЇОTVТўПNТ╞НЇОQшТ─ПMНЇОK>rНЇОGbpТ║П9Т╒П'НЇОE-Т· Т÷ПUНЇОBЫТїПQТ╗ НЇО@еТ┤Т┬ПQНЇО>░Т,ПQНЇО<\Т╞П,Т╟П3НЇО:'Т┌П@Т┐П%НЇО7╛Т─П&НЇО3пpТ√П-Т≈П7НЇО1°Т°П9Т²П)НЇО/hТ╙ПNТ╚НЇО-3Т┴Т┼ПSНЇО*╦Т─ПTНЇО$rНЇО ?pТ╔П#spТіНЇОТ▀П:Т▄П)НЇОжТіП[ТїНЇО╒Т╚П0Т╛П0НЇОmТ ПDТ⌡НЇО9ТщПQТч НЇОТ═ПPТ║НЇОпТжПMТвНЇО⌡Т═ПLТ║НЇО Т─П0Ъ XЇы=Г\2ЛDESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL58The introduction of entities has the disadvantage that it tends to "cast in stone" the decision todefine a particular real-world object as an entity as opposed to a datum value (or vice versa). Forexample, if it is decided that the publisher attribute of the author relation is a string datum (thename of the publisher), and later it is changed to be an entity instead, then programs referring tothe author relation must be modified. If a client uses the SetFS / GetFS operations, however, it ispossible to obtain or even change the publisher without knowing whether it is an entity or datumvalue. This feature allows an application additional data independence at the expense of ignoringknowledge of entity existence and entity types.The introduction of entities encodes more knowledge about the structure of the underlyinginformation than the Relational data model. We can use this knowledge to provide betterperformance, and we do so in the Cypress Database System. For example: (1) entities indicatewhere physical links are desirable, (2) it is not necessary to store or use artificial numbers to identifyobjects because unique entity names provide this, (3) entities (atoms) may be stored andmanipulated more efficiently than strings or integers (e.g., string matching person-names is moreexpensive than checking entity equality).Note that the Cypress data model includes the Relational model as a special case in two senses:1.If no domains are defined (i.e., all relationship fields are datum values), then we haveexactly the Relational model: there is no domain type checking (e.g., that a value is aperson's name as opposed to just a string). Any correspondence between strings in onerelation and strings in another, and their correspondence to objects, is left to the applicationprograms. 2.The Relational model can be exercised on top of the Cypress data model even in thepresence of entities by using only the translucent attribute operations. These operationstreat all fields as strings as in the Relational model, but entities and any underlying physicalstructures required by the implementation are automatically maintained as well. Forexample, a new entity may automatically be created by using SetFS on a relation tuple.Thus different users may examine and manipulate the same database as datum values(Relational model), links (graph model), or both (our model).The introduction of entities to the Relational model is now fairly widely accepted as a good idea,and Chen [1976] is probably most responsible for spreading this notion. Unfortunately, Chenintroduces entities in a framework which is more complicated than it needs to be. Entities extendthe representational capability of the Relational model in one basic way: they make it possible todistinguish between database items that represent objects and those that represent properties of (orrelationships between) objects. Chen uses entities for this basic function, as unique "atoms."ЪНvОfЯptТF ptpt ptptpТXtТFptНMpНЇО_ТЇПRТ╦НЇО\АТ∙П@Т√П$НЇОZґТ╚ПYТ╛ НЇОXxТ·ПMТ÷НЇОVDТ▄Т█ПQНЇОTТ·П?Т÷П!НЇОQшТ═ПbНЇОO`Т─П/НЇОK└pТЧП=ТЪНЇОIPТСПFТТНЇОGТґП(ТўП6НЇОDГТ│П'Т┌ПCНЇОB╡ТПTТНЇО@~ТЇПaНЇО>Т─П)НЇО9АpП_НUО6pНґТйПSТкНґО3пТ╩Т╪П;НґО1°ТЇПOТ╦НґО/hТ└Т┘ПIНґО,МНpТНUО)НґТкТлП>НґО&эТ╩ПOТ╪ НґО$╗Т└Т┘ПEНґО"sТМПPТННґО ?ТЇ Т╦ПLНґОТыПAТзНґО░Т─П=НЇОЄpТ║Т╒ПOНЇОТсПHТтНЇОKТ≥П(Т П:НЇОТ⌡ПcНЇОБТ≈Т≤ПHНЇОgТ─П_ЪЮM =Г[КDATA MODEL DESIGN ISSUES59However, Chen and others have combined this function with two other data model features:1.Treating entities as relationships, by allowing entities to have attributes just as relationshipsdo. Chen does this, and most others have followed his lead.2.Treating relationships as entities, by allowing attributes of relationships to reference otherrelationships as well as entities. Chen does not do this, but others (McLeod [1978], Codd[1979], Smith [1977b]) do, as do the older hierarchical and network models.Combining the basic idea of an entity as an atom and a relationship as a data record can lead tosome confusion. In the next two subsections we specifically discuss the merits of (1) and (2),respectively. 5.3 Entities as relationships: "attributes" of entitiesChen [1976] and others allow entities to have attributes. That is, they define an entity to have thefeatures of a relationship: entity-valued or datum-valued attributes. This definition divides theinformation about an entity into two classes: the information that is given by its attributes, and theinformation that is given by relationships. For example, age might be an attribute of a person,while the projects he works on might be represented by member relationships between persons andprojects. In many cases, the choice is not clear: should spouse or boss be attributes of persons orrelationships between persons? Should birthday be a quaternary relation between a person, month,date, and year, or should the birthmonth, birthdate, and birthyear be attributes of a person? Thesedecisions must be made at data definition time and changes later would necessitate changingapplication programs or providing some kind of translation mechanism. Applying the simplicity and utility criteria to the entity attribute question suggests that:1.[Utility] Entity attributes provide a short-hand making application programs and userinterfaces simpler: the age of a person can be obtained in one operation instead of two, theextra operation being fetching the relationship. There could also be a performance issuehere, but the database system can store relationships physically co-located with the entityabout as easily as it can co-locate attributes, so this is not an issue in practice.2.[Simplicity] Entity attributes introduce additional complexity, both in understandability andthe parsimony of the representation. For example, there are now two different mechanismsto represent most facts about entities. There are also indirect, but perhaps more annoying,effects: the syntax and semantics of the query language will be more complicated and/orverbose, if we must handle both cases.ЪН!dОfЯptТFptptptНG╘pНЇО^оТ─ПXНUОZСpНґТ⌠П/Т■П2НґОXxТ─П<НUОT²pНґТ╛П^НґОRhТ·П1Т÷П)НґОOМТ─ПKНЇОLpТ║Т╒ПEНЇОIщТиПVТйНЇОGbНёpТНЇО@еrТ─П8НЇО<ИpТ∙П?Т√П&НЇО:ЄТҐПWТЎНЇО8─Т┬Т┴ПLНЇО6KТІП0ТЇ spП#НЇО4Т░ spТ▒ПJНЇО1ЦТ≈П;spТ≤spНЇО/ўТ⌠П'spТ■П"НЇО-zТ█ПSТ▌НЇО+EТАП.ТБП-НЇО(йТ─ПEН8]pТНЇО$╗Т─П\НUО лpНґТТПLТУНґО≤Т│П8Т┌П%НґОcТґП1ТўП(НґО/Т╞ПTТ╟НґОЄТ─ПTНUОьpНґТ√ПDТ≈НґОєТ┬П<Т┴НґОoТ⌠П\НґО ;Т╙Т╚ПKНґО юТ─П&Ъ ~Ї y=Г]▓ DESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL60A solution we have not seen in the literature is to allow the best of both worlds, by providing ashorthand to obtain or assign in a single operation the entity properties stored as relationships, butretain relationships as the real underlying logical storage primitive. This line of thinking is themotivation for the introduction of properties in the Cypress model. The result is a model whoseutility and simplicity is an improvement on either extreme.We should note two variations on the idea of allowing entities to have attributes: list-valuedattributes and the characteristic/association scheme.A few data models allow list-valued attributes, rather than insisting that only single-valuedproperties be attributes of entities. For example, the projects a person works on would be anattribute of the person, and the persons working on a project would be an attribute of a project.Note, however, that these attributes of persons and projects are really representing the same fact.By representing the fact as attributes of the entities instead of as relationships the danger ofinconsistent data arises (unless yet another feature is added to the model to automatically maintainthe interdependencies). Serendipitously, the property mechanism we introduced as a shorthandsolves this problem too. The convenient list-valued properties are a veneer on top of the underlyingrelations, and the consistency of the database is retained at the level of facts stored as atomicrelationships. Another variation on the entity attribute feature is to categorize relations into two types:associations and characteristics (Pirotte [1977], Codd [1979]). Only entity values may be attributes ofassociations. Only datum values may be attributes of characteristics, except for the first attribute,which is always an entity (characteristic relations relate an entity to datum values that are its"characteristics"). However, because a real-world logical dependency may involve both entities anddatum values, it is also necessary in these models to allow relationships to be entities, so that thedatum values associated with a functional dependency can be expressed as characteristics of therelationship. In some cases, previous authors have further restricted associations and characteristicsto be binary relations. There doesn't seem to be any advantage to the association/characteristicscheme, and it was not adopted in the Cypress model.5.4 Relationships as entities: Allowing references to relationshipsSome data models introduce another feature to the entity/relationship idea: they allow relationshipsto act as entities in the sense that they can be referenced by other relationships. In the models theauthor knows of, this is done by eradicating all distinctions between entities and relationships. Thatis, there is only one "object" type of primitive, that can have attributes like a relationship, and canbe referenced elsewhere like an entity.НvОfЯptТF ptpt ptptpТXtТFptНMpНЇО_Т╗ПRТ╘НЇО\АТ∙Т√ПZНЇОZґТ╪ТҐПMНЇОXxТіПZТїНЇОUЩТ─П;НЇОR"pТяП>ТрП!НЇОOїТ─spНЇОKкpТП#ТП:НЇОI√ТеП^НЇОGbТ╗П0Т╘П1НЇОE-Т╙П'Т╚П<НЇОBЫТщП]ТчНЇО@еТ≈ПJТ≤НЇО>░ТиП6ТйП'НЇО<\Т─ Т│ПZНЇО:'ТкТлПCНЇО7╛ НёpТНЇО3пТП7ТП%НЇО1°spТ┤spП&spТ┬НЇО/hspТ╚spspТ╛НЇО-3ТвПTТьНЇО*ЪrТ▐pП0Т░НЇО(йТєspТ╔П@НЇО&√Т©П)ТюП6НЇО$aТ∙ПgНЇО"-Т╧Т╨ПUНЇО╡Т─П4НЇОrПDНЇО9pТ│ПeНЇОТ▌ПWТ▐НЇОпТ┘Т├spП7НЇО⌡Т▓П1Т⌠П6НЇО Т─П'ЪхMы>Г\2#DATA MODEL DESIGN ISSUES61The single object type has the attractiveness of simplicity. One still needs the same operationspresent before on relationships and on entities, but there is only one type to deal with.Unfortunately, it falls back a bit on the utility criterion, as we lose some features that theentity/relationship distinction was providing us. In addition to the obvious fact that the user can nolonger tell which data items are thought of as real-world objects, the system cannot tell thedifference and so cannot:1.automatically check that objects intended only as relationships are never referenced 2.perform optimizations that depend on knowing whether a database object can ever bereferenced elsewhere, or3.print the database in a simple linear or human-readable way, as it can when only entitiescan be referenced and all entities have names (or names can be invented).Consider the motivation for dropping the entity/relationship distinction. Some relationships, say apurchase relationship between a customer, part, and quantity of the part ordered, may act as anentity in and of itself. For example, the purchasing may take part in a commission relationshipbetween the purchase, a salesman, and a commission in dollars. If we drop the entity/relationshipdistinction, this kind of relationship can be added with no change to the existing data schema, asthe previously unreferenced purchase relationships can just as easily be treated as entities. Keepingthe entity/relationship distinction, such a change would require modifications to databaseapplication programs or at least the use of some intermediate interface to shield them from suchchanges (such as translucent attributes or views).On the other hand, we can argue that when we choose to treat a relationship as representing anabstract object in and of itself, we should then and only then introduce a domain to represent thatkind of event or transaction. Quite simply, that's what an entity is for: it says that we are thinkingof this database item as an object, that can participate in relationships.In a more practical and perhaps more convincing vein, not allowing explicit references to therelationships in a database permits a much simpler query language, since it need not deal withnesting of relations. Relationships referencing relationships provide a potential spaghetti ofinterconnections. In particular, as noted in earlier sections, we may still use a relational querylanguage in our data model, despite the introduction of the entities, names, domains, subtypes, andso on. This compatibility is possible exactly because of the dichotomy we introduced betweenrelationships (objects that may reference other objects but may not themselves be referenced), andentities (objects that may be referenced but may not reference others). We have a simple, two-levelstructure. Н!dОfЯptТFptptptНG╘pНЇО_ТюП0ТаП1НЇО\АТП#ТП6НЇОZґТНТОПGНЇОXxТ└ПRТ┘ spНЇОVDТХП+ТИspНЇОSиТ─НUОOїpНґПTНDдpТНUОKкНґТтП$ТуП.НґОIPТ─НUОEtpНґТєПBТ╔НґОBЫТ─ПIНЇО?pТ П<Т⌡П(НЇО<ИspТІТЇП@НЇО:ЄТ╣П5ТІs pНЇО8─Т√ПbНЇО6KТ╔ПEТіНЇО4Т▄П]Т█НЇО1ЦТ2П@Т3НЇО/ўТ╛П$ТґП<НЇО-3Т─П2НЇО)WpТґП[ТўНЇО'#Т⌠Т■ПMНЇО$НТ┤П3Т┬П5НЇО"sТ─ПJНЇО≤pТтП/ТуП.НЇОcТюП8ТаП&НЇО/ТП0ТП/НЇОЗТцП?ТдП$НЇОфТ▒Т▓ПHНЇО▒ТгПGТхНЇО]Т²Т·ПCНЇО)Т┤ПRТ┬НЇОў Н(pТ0Їg>Г[єDESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL62In applying the simplicity and utility criteria here, the choice is difficult. Our choice, to keep theentity/relationship distinction, was motivated by the observations that (1) dropping the distinctionresults in no fewer operations either in the database interface or the application program, it merelycondenses two types into one; (2) there is a loss of some integrity checking and data semantics bydropping the distinction; (3) a linear and human-readable notation of entities and relationships,using entity names, is possible; and (4) the query language is simplified by permitting only oneinformation-carrying element, relations.There is a variation on dropping the entity/relationship distinction that allows references torelationships only in a non-cyclic hierarchical fashion; this middle ground seems to be morecomplex and/or less powerful than either of the extreme positions, however.5.5 Lists and setsA few data models permit set values for relationship attributes. We discussed this in the previoussubsection in the dual form of multi-valued attributes of entities. Both have the same drawback inmaintaining consistency of the database. Both violate Codd's [1970] first normal form designed toavoid such inconsistencies.On the other hand, we have found it useful in database applications to have some mechanism torepresent the concept of a list, an ordering upon database entities or relationships. Almost none ofthe data models of which the author is aware provide any help in representing the concept of a list.The standard way to represent ordering in the Relational model is by adding another attribute tothe relation, specifying the ordinal position of the tuple. A list thus constructed can only beenumerated efficiently if an index is built upon the attribute, and it is quite awkward to insert newtuples in the middle of the list.We do not claim to have solved the list representation problem in the Cypress data model, either.However, in practice we have used the list representation our implementation provides: the ordermaintained on references to an entity. When a RelationSubset is executed with an entity-valuedattribute-value pair [a, e] as the constraint, the tuples that reference the entity are returned in aparticular order. This ordering is guaranteed by the group lists we will describe in Section 6. It isthe same order as the entities were specified in the call to SetPList, or in the order they werecreated if SetP or DeclareRelship calls were used. We are experimenting with an optional extraargument to SetF which specifies where in the list the new tuple should be inserted when a newreference to an entity is established:НvОfЯptТF ptpt ptptpТXtТFptНMpНЇО_Т²П5Т·П2НЇО\АТ╙ПBТ╚П"НЇОZґТ⌠ПeНЇОXxТ ПCТ⌡НЇОVDТдП&ТеП;НЇОTТЇП$Т╦П<НЇОQ■Т─П(НЇОM╧pТЬ ТЫПTНЇОK└ТХПQТИ НЇОI Т─ПKНЇОBlrНЇО>░pТ⌡ПZТ°НЇО<\Т░Т▒ПHНЇО:'Т°Т²ПDНЇО7╛Т─НЇО3пpТїП6Т╗П'НЇО1°Т▌spТ▐П9НЇО/hТ┬П&Т┴П>НЇО-3Т╔ПAТіНЇО*ЪТпП-ТяП3НЇО(йТ▐ПIТ░НЇО&OТ─П!НЇО"spТ⌡Т°ПOНЇО ?Т╒ТёП"s pНЇОТ═Т║u pП"НЇОжТўТ╞upПJНЇО╒Т▐ПIТ░НЇОmТ╨П#Т╩upНЇО9Т÷ upu pТ═П-НЇОТєupПNНЇО┴Т─П&Ъ ІMB>ГWиDATA MODEL DESIGN ISSUES63SetF: PROC[t: Relship, a: Attribute, v: Value, after: Relship_ NIL];Using this mechanism, our applications can define binary member relations as connectors to entitiesthat represent ordered (or unordered) sets. Elements can easily be added and removed from a setwith SetF or SetP, and the sets can easily be enumerated with RelationSubset.However, we have not advertised this feature in the description of the data model or the DBModelinterface because it is only a tentative solution. Not only does this solution depend upon theimplementation of the entity references via linked lists, but the feature is not accessible at all from ahigher-level Relational query language. More work is badly needed, to extend data models andquery languages to cover the concept of ordering in a clean and integrated way.5.6 Entity namesThe introduction of entity names to the data model is a comparatively easy choice. They easilysatisfy the criteria of simplicity and utility. What is less clear is the form in which they should beintroduced.For the applications we have encountered, nearly all real-world objects have human-meaningfulnames that are unique within their domain or can easily be made to be so: people, organizations,articles, programs, calendar years, or electronic messages. The natural real-world name is preferredto an internally generated identifier for the object, if the real-world name is guaranteed to beunique, because the name is the way in which a user will typically identify an object to thecomputer and represent the object outside the database.A number of applications use names that logically have multiple parts. The name of a person, forexample, might consist of the concatenation of a first, middle, and last name. Some applicationshave dependent names. A dependent name is a multiple-part name one of whose parts is anotherentity. The name for a file system subdirectory, for example, might be a two-part name consistingof the entity for its super-directory plus the string name of the subdirectory. The name of a wine,e.g. a 1979 Sebastiani Zinfandel, has three parts: the vintage year, the winery entity, and thevariety.The ubiquity of multi-part and dependent names easily satisfies our utility criteria. They probablyalso satisfy our simplicity criteria, but this is less obvious. Closer examination reveals that theimplementation of names must be reasonably complex in order to satisfy typical applications' needs.Different separators for the name parts and different conventions for their combination and sortorder may be required: e.g., "Lastname, FirstName Initial" for persons, or"SubDirectory>" for file system directories. Also, the data schema mechanismЪН!dОfЯptТFptptptНG╘pН хО_uТXПDНЇО[:pТ▐ Т░П/spП$НЇОYТ≥П`НЇОV┼Т─upupП-u pНЇОR╞pТ▌П3Т▐П-НЇОPzТгП3ТхП,НЇОNFТ┐ПiНЇОLТ╣ПRТІ НЇОI√Т─ПOНЇОBЫrНЇО?pТ╠Т╡П?НЇО<ИТ·П4Т÷П2НЇО:n НЇО6▓pТгП0ТхП-НЇО4^Т≈П"Т≤П?НЇО2)Т▓ПeНЇО/УТмП)ТнП7НЇО-юТжП.ТвП.НЇО+EТ─П7НЇО'ipТ⌠ Т■ПVНЇО%5Т╣ ТІПRНЇО#Т÷s pП0Т═НЇО лТ■ПIТ∙НЇО≤Т⌠П.Т■П6НЇОcТи ТйПUНЇОХНЇОpТ√П5Т≈П/НЇОьТеП)ТфП;НЇОєТ┤Т┬ПLНЇОoТІПKТЇНЇО ;ТФП;ТГНЇОТмП]Ъ ╦Ї ©>Г]LDESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL64must define the name in terms of independent existing relations. That is, one probably does notwant to think of the name components as "attributes" of an entity in the sense that relationshipshave attributes. The relation between wines and wineries or the relation between organizations andtheir parent organizations are queried independently but are also used in derivation of wine andorganization names.Our conclusion is that the data model should allow for a procedural specification of the namederivation so that names can automatically be updated when data change, rather than allowing somefixed name derivation primitives. This allows an arbitrary definition of names, just as views mayallow arbitrary relation definitions. It also removes the need for the database system to understandnames at all, since it treats the name function as a "black box." Until storage of proceduralinformation is easier in the Cedar programming environment, however, the name function has beenomitted from the implementation. One could imagine applications that use integers or dates as entity names rather than strings.Again, this variation could be handled by a procedural specification of the name derivation, and wefound insufficient demand to explicitly incorporate this into Cypress.Real-world objects can have more than one name, so it might be reasonable to allow this in thedata model as well. Multiple names were omitted from the Cypress model since the user can buildan alias relation on top of the system that is checked whenever names are looked up. The onlycommon example of aliases we have encountered are for person entities, so name aliasing does notsatisfy the utility criteria. However if multiple names are used widely it does make more sense toaugment the model. In that case it is still desirable for every entity to have a primary name toallow for correct operation of GetFS and SetFS.Another more difficult design decision for names in the data model is whether to allow null namesfor entities (Codd [1979], Kent [1978], Date [1981]). Without the guarantee that every entity has aunique identifier, a number of database operations become more complex in both semantics andimplementation: expression of queries, printing of entities, dumping of databases, cross-databasereferences (augments), data entry, and maintaining the correspondence between relational andentity-based database access (GetFS, SetFS). Unfortunately some applications do not requirenames. For example the transistors in an LSI layout may be represented as entities accessible onlythrough their relationships to connected entities in the layout. The best solution seems to be torequire that entities have names, but provide a default system facility for generating unique names.The GENSYM facility for generating unique atoms in LISP does this. The DeclareEntityprocedure in our implementation acts similarly. Thus the data model's invariants remain simple butadd no additional complexity to application programs not requiring names. НvОfЯptТF ptpt ptptpТXtТFptНMpНЇО_Т╔ПAТіНЇО\АТ╗ПSТ╘ НЇОZґТ▄П@Т█П#НЇОXxТ╠ПWТ╡НЇОUЩТ─НЇОR"pТфП8ТгП%НЇОOМТ┐П-Т└П4НЇОM╧ТіПXТї НЇОK└Т▌П)Т▐П<НЇОIPТнТоПHНЇОGТ▀ПVТ▄НЇОD═Т─Н" pТНЇО@еТвП#ТьП;НЇО>░Т┴П6Т┼П-НЇО<Т─ПFНЇО89pТґПZТўНЇО6Т┼Т▀ПMНЇО3пТ╘spТ╙П8НЇО1°Т⌠Т■ПDНЇО/hТ ПKТ⌡НЇО-3Т╟Т╠ПТ≤П&НЇО"sТ╠ПIТ╡НЇО ?ТЄП3Т╣П/НЇОТЙТКПAНЇОжТщupupТчП/НЇО╒Т░Т▒ПLНЇОmТіПcНЇО9Т▓П-Т⌠П7НЇОТЬПGТЫuНЇОпpТ└П9Т┘П*НЇОUТ─ПIН:ьrТM>ГYЩ0DATA MODEL DESIGN ISSUES655.7 Keys, normalization, and dependenciesAny kind of key mechanism is only an approximation to a description of arbitrarily complexdependency relationships between entities and datum values involved in relationships. Functionaland multi-valued dependencies and their implications for relational normalization have beenextensively studied in the literature (Codd [1970], Fagin [1977, 1981], Sadri & Ullman [1980]). Keyshave the advantage of simplicity over a more general, open-ended scheme requiring constraintchecking on a list of axioms on each database update: 80% of the checking can be handled with20% of the complexity. We are forced once more to apply our utility constraint: how complex akey mechanism would most database applications use? Uniqueness of entity names in domains?Single-attribute primary keys for relations? Multiple-attribute primary keys? Optional keys (uniqueif present)? We include all of these mechanisms in the Cypress data model, but not arbitraryassertions. Normalization is typically not enforced by a database system. The database administrator attemptsto design the data schema in a manner to minimize various anomalies, through normalization. Thesubject of database normalization, as noted in the previous paragraph, has been extensively studiedin the literature. It is my opinion that arbitrarily complex kinds of normalization and dependencieswill continue to be discovered. The easiest solution, therefore, is to take the extreme position:adopt the convention of normalizing databases as much as possible at the conceptual level. Wedefine functionally normalized to mean that relationships in the model are single irreducible facts.The result in practice is that most relations are binary; the physical database representation may infact join relations in storage for efficiency, but this optimization is not visible at the client'sconceptual level.Hall et al [1976], Biller [1979], and Schmidt & Swenson [1975] argue that the irreducible relationalform we are advocating is preferable to joining unrelated functional dependencies into a singlerelation. There are several arguments: (1) this is easier to understand because the relationalrepresentation matches the real-world dependencies, (2) if there is efficiency in actually joiningthem, this can be achieved by storing the join in the physical representation and defining the realrelations by views that are projections of this underlying relation, (3) this representation is more"restrictive" than any normal form that could be derived. The irreducible form has therefore beenused by convention, although not enforced, in the Cypress system applications. Features of thedatabase system and associated tools make this form easy to use.Our definition of irreducibilty is not the same as irreducibility to relations whose join can reproducethe original relation, as in Hall et al [1976] but rather what Biller [1979] calls s-irreducibility. Billerproves that our definition is more restrictive.We backed off one step from irreducibility to what we called "functional irreducibility:" in thisН!dОfЯptТFptptptНG╘pНЇО^оrТ─П)НЇОZСpТыПCТзНЇОX©ТіП3ТїП.НЇОV┼ТП[НЇОTVТ┘П%Т├П@НЇОR"ТтПGТуНЇОOМТ║П^НЇОM╧Т⌡П*Т°П5НЇОK└ТЄП.Т╣П-НЇОIPТ┬П]Т┴НЇОGТеТфП>НЇОD═ Н(pТНЇО@еТ∙Т√ПRНЇО>░Т█Т▌ПWНЇО<\Т∙ПFТ√НЇО:'Т┼ПCТ▀П"НЇО7СТюП,ТаП6НЇО5ЎТ÷П8Т═П(НЇО3┼Т÷П9Т═П+НЇО1UТ■П1Т∙П4НЇО/!ТБПSТЦНЇО,іТ─НЇО(йpТ⌡ПdНЇО&√ТхПXТиНЇО$aТрТсПPНЇО"-ТлТмПHНЇОЬТ·П1Т÷П2НЇОдТ╣ТІПRНЇО░Т░Т▒ПLНЇО[Т╧П[Т╨НЇОЮТ─П@НЇОpТ┘П#spТ├П5НЇОпТ█П>Т▌П.НЇОUТ─П/НЇО ypТўПZТ╞Ъ:Ї 2>Г]ыDESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL66form we allow two or more relationships to be combined into a single relationhip when they mustlogically all be present or all be absent for each external (real world) entity. In practice we findthat functional irreducibility differs from irreducibility only when we separate components of asingle real world value into its constituent parts. For example, the birthday relation given as anexample of a functionally irreducible 4th-order relation in Section 2.7 would have been a binaryrelation had the month, day, and year been combined into a single "date" value. Kent [1982]discusses the issue of combining or separating components of values or entity names.The last topic we cover in this section is "existence dependencies" between entities andrelationships, in particular the fact that DestroyEntity is defined to include the destruction ofrelationships that reference the entity. One could imagine other semantics:1.When an entity is destroyed, the attributes of relationships that reference it could becomeNIL.2.We could disallow the destruction of entities altogether, destroying only relationships.3.When two database applications share entities of a particular domain, e.g. both a messagesystem and a phone directory share information about people, deletion of an entity by oneapplication should only delete relationships pertaining to the entity for that application, notthe entity itself. Alternative (1) was ruled out on the basis of our utility criterion. For the database applications wehave and envision, the desired semantics is to destroy all information about an entity when theentity is destroyed. Alternative (2) is attractive, as it simplifies the model by reducing the numberof operations we must understand and implement. However, it was also ruled out on the basis ofour utility criterion; there are cases where an application program really needs to remove an entitycompletely from the database, e.g. when old data is purged. Furthermore, the author knows nosimple implementation for this alternative not requiring "garbage collection" of entities created butno longer used.Alternative (3) is an important issue, as the support of applications with overlapping databaseschemas is crucial. Of course, applications that share domains will have to be in agreement as towhich relations belong to whom anyway, and could delete only their own data. But a morepowerful mechanism that could delete the relevant data in one operation is desirable. The solutionto that problem, in the opinion of the author, is to use the data segmentation mechanisms weconsider further in Section 5.9. These mechanisms not only allow physical independence of theapplications, but deletion of the entity representative of a real-world object in one segment has noeffect on the entity or its relationships in another segment.НvОfЯptТF ptpt ptptpТXtТFptНMpНЇО_Т≤ПDТ≥НЇО\АТїПTТ╗НЇОZґТкП`НЇОXxТ╠П3Т╡spНЇОVDП`НЇОTТбПPТцНЇОQ■Т─ПTНЇОM╧pТ Т!ПPНЇОK└ТщПRТчНЇОI Т─ПLНUОE-pНґТ║Т╒П;НґОBЫНUО?НґТ─ПXНUО;AНґТёП2ТєП'НґО9 Т⌠Т■П=НґО6ыТ▐П_НґО4єТ─Н≥ТНЇО0хТ░ПfНЇО.■Т╪П[ТҐНЇО,_Т≈П(Т≤П>НЇО*+Т≥П/Т П0НЇО'ВТ∙ПSТ√НЇО%бТ╡П]НЇО#▌Т∙Т√ПLНЇО!YТ─НЇО}ТвП8ТьП'НЇОIТ║П?Т╒П#НЇОТуП7ТжП!НЇОЮТ█Т▌ПQНЇО╛ТеП"ТфП:НЇОwТІП^НЇОCТ ПNТ⌡НЇОТ─П=ЪXM г=ГZDDATA MODEL DESIGN ISSUES675.8 Generalization and type hierarchiesA wide variety of mechanisms have been forwarded in the literature for specifying types andsubtypes of data objects, or, equivalently, allowing the same object to participate in more than oneclass of relationship. These mechanisms have variously been called type hierarchies, type hierarchieswith multiple inheritance, type lattices, roles, and flavors.There are two major data modelling questions to address: how powerful a type-subtype mechanismis desirable, and whether it should apply to domains, relations, and/or datatypes. Both of thesechoices are difficult, and were made on the basis of the applications and schemas of the applicationswe envision. At least some sort of type lattice ranks high on our utility criterion, as many applications definerelations that are constrained to a subset of the entities of a type to which more general relationsalso apply. A database of documents for example, would separate those documents that areindividual works (books, articles, technical reports) from those that are collections (journals,conference proceedings, or collected books).Although we can construct examples where more complex type mechanisms such as roles or flavorsare desirable, for example treating a person entity as either a homeowner or employee or both, noneof the applications we envision would use this generality and the more complex mechanisms areharder to understand as well as more complex in their implementation. The addition of multiplesupertypes to the basic type hierachy mechanism, on the other hand, is a relatively simple conceptto understand and implement, and handles most data schemas the more complex mechanismshandle. Thus we arrive at the type hierarchy with multiple supertypes.Yet another variation on the type-subtype mechanism is to define subtypes by a predicate computedat run-time from data in the database (McLeod [1978]). For example, an entity would be defined tohave type mother if it has type person and also has a parent relation to one or more children.Computing types at run-time unfortunately introduces much of the complexity of arbitraryconstraint satisfaction tests earlier rejected in our database normalization disucssion. It also providesmore power than called for by our applications and the utility criterion. Subtypes computed bypredicate were therefore omitted from the Cypress data model. In their well-known paper on generalization (type hierarchies), Smith and Smith [1977] apply theconcept to all kinds of database objects, and we would naturally apply it to relations, domains, anddatatypes. This idea certainly satisfies our simplicity criterion, as it makes sense to applygeneralization universally in the data model if at all. In our implementation, however, only typehierarchies of relations are not allowed: these do not seem particularly useful to applications. Sinceuser-defined datatypes are not currently permitted, there is no need for a subtype mechanism forthem, either. However a subtype mechanism for datatypes does satisfy our simplicity and utilityН!dОfЯptТFptptptНG╘pНЇО_rТ─П'НЇО[:pТвП!ТьП:НЇОYТ∙ Т√ПYНЇОVяТ─ПHТ│НЇОT²Т─П=НЇОPаТ├Т┤ПGНЇОN▄Т╡П)ТЁП8НЇОLXТ┌ Т┐ПZНЇОJ#Т─НёТНЇОFHТ╟П<Т╠П'НЇОDТёП?ТєП%НЇОAъТЮП7ТАП"НЇО?╙ТП:ТП&НЇО=vТ─П,НЇО9 Т█П^НЇО7fТ─Т│ПQНЇО51Т╠Т╡ПWНЇО2ЩТёПJТєНЇО0хТ≥П0Т П2НЇО.■ТшП-ТэП)НЇО,_Т─ПGНЇО(└Т┤П@Т┬spНЇО&OТ─П7Т│П+НЇО$Т╨Т╩ПDНЇО!ФТ П9ТНЇО╡Т┐П1Т└П9НЇО}Т╟П6Т╠П)НЇОIТ─П=Н3gТНЇОmТґП`НЇО9Т░Т▒ПDНЇОТ ТПSНЇОпТ╘П!Т╙ПAНЇО⌡Т─ Т│ПZНЇОgТ╗П<Т╘П$НЇО 3Т╡ТЁП!spП#,Ї Л>Г^$DESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL68criteria when user-defined datatypes are defined. The hierarchy of relation types is difficult toimplement when multiple supertypes are allowed and attributes of relationships are stored in aphysically contiguous memory, because the multiple supertypes may define overlappingincompatible fields. Furthermore, the hierarchy of relation types seems to be of less utility.The effect of subdomains could be achieved by allowing relation attributes to accept one of a list oftypes instead of by using the predefined SubType relation to define a lattice of types, specifying the[one] least common domain for each attribute. These two alternative representations do not differmuch in flexibility of the type mechanism. The former might be better if we found it necessary inthe latter scheme to define a large number of "artificial" intermediate types in order to achieve thetype constraints we desire. However this has not been the case in our experience. The single typefor attributes might be simpler to understand, but the argument is not a convincing one. Thereforethe choice we made, to use the Subtype relation, was arbitrary.5.9 Access primitivesMost database management systems (INGRES and System R, for example) provide an interface totuples (relationships or entities) at a coarser grain than ours. They do not allow tuple-valuedvariables in a client program, on which operations such as GetF and SetF can be invoked to extractor assign particular values. Instead tuples are explicitly copied from a database into buffersallocated by the client, and explicitly copied back on an update. The difference between ourapproach and theirs is subtle, but it may have a major impact on the design of an application.Because the "handles" for the tuples in our scheme are garbage-collected, the client need not keeptrack of the number, logical source, allocation, or size of variables referencing database objects. One additional complexity is introduced by the granularity of database access in Cypress.Specifically, the problem is not a result of our choice of "call by reference" over the "call by value"in other systems, but that all of the updates to a particular tuple are not necessarily encapsulated ina single database call. In examining the interface to the implementation described in Section 3.4,the reader will note that relationship attributes can either be assigned by calling DeclareRelshipwith a list of attribute values, or by successive calls to SetF. The former is preferable, as itsometimes allows the database system to more efficiently update the data. In addition, the lattercomplicates the implementation and/or the rules for database system use, for example in the use ofthe surrogate relation optimization we discuss in Section 6. For now, however, we have retainedSetF in the implementation as a convenience to the client. In addition to the call by reference/value distinction, INGRES and System R differ from our designin providing a higher level of access to database clients: a query language. Of course, we plan theaddition of a Query level to Cypress (or multiple different query levels). The difference remains,НvОfЯptТF ptpt ptptpТXtТFptНMpНЇО_ТцПLТдНЇО\АТхП\ТиНЇОZґТeП2ТfП"НЇОXxТ─П_НЇОT²Т├Т┤ПXНЇОRhТ├ПCТ┤П#НЇОP4Т°ПbНЇОMЪТ▌Т▐ПCНЇОKкТ░ПeНЇОI√Т▐Т░ПSНЇОGbТ┴Т┼ПOНЇОE-Т─П?НЇО>вrНЇО:ШpТ≈П3Т≤П(НЇО8фТоПIТпНЇО6▓Т└Т┘П/upupНЇО4^ТИПГ\©'DATA MODEL DESIGN ISSUES69however, that we are willing to have clients access the database at the lower "navigational" level aswell. Our introduction of entities into the Relational model makes a navigational interfacecompatible with concurrent use at a higher level. The introduction of entities also makes possiblequery languages of a different style, e.g. more like predicate calculus, or using a "chain" of domainswith relations as connectors.5.10 Views, segments, and augmentsThere is little question that views are quite useful and also relatively easy to understand, and thussatisfy our utility and simplicity criterion. A more difficult question in the design of views is thepower of the view definition language: should an arbitrary programming language be allowed, or amore restricted specialized query language? We have essentially avoided this issue, by separatingthe definition of the query language from the definition of the data model itself. A particularchoice will have to be made in the second phase of development of the Model Level of Cypress.In addition to the utility of relational views as discussed in the literature, e.g. for data independence,they can be used to encode operations on entities in an object-oriented form. The operations ofhiring or firing an employee or sending a message can be invoked by storing a tuple into a relationwhose attributes are the arguments of this function. For example, if the operation of sending amessage takes two arguments, the message and the recipient, the actual operation would be invokedby storing a tuple in the Send view (relation) with the appropriate message entity and recipiententity as attributes. In general, we have taken a reasonably conservative philosophy in the design of the Cypress datamodel, integrating ideas that have separately been studied theoretically if not implemented instudies in the literature. This philosophy increases the probability of a practical implementation ofthe model. The introduction of augments is an area where we have violated the conservativephilosophy, however, because the functionality of augments seems so important to applications. Augments and segments have roots in the segments of System R (Astrahan et al [1976]). Oursegments are slightly more powerful than theirs, as we allow references across segment boundaries;augments are of course more powerful still. System R segments cannot be used for encapsulatingupdates to data or to combine private and public data. Relations cannot cross System R segmentboundaries.The use of augments to represent versions of data makes them similar to that of the "layers" ofGoldstein and Bobrow [1980] and the "hypothetical databases" of Stonebraker [1980]. None of thesemechanisms have been implemented on a database system scale at the time of this writing. Thesemantics of layers, hypothetical databases, and augments differ slightly at the conceptual level.Augments have the additional feature that they have semantics at a physical level: they can be usedН!dОfЯptТFptptptНG╘pНЇО_Т▓ПbТ⌠НЇО\АТЖТВПBНЇОZґТ°П*Т²П9НЇОXxТ┘Т├ПRНЇОVDТ─НЇОOМrП"НЇОLpТ°П=Т²П(НЇОIщТ╒П_ТёНЇОG╗Т┴П1Т┼П0НЇОEtТ╙П4Т╚П.НЇОC@ТюПRТа НЇОAТ─П]НЇО=/Т│Т┌ПMНЇО:ШТ╙ПNТ╚НЇО8фТ▀ПcНЇО6▓Т╡П9ТЁП'НЇО4^Т┴Т┼ПPНЇО2)Т╧ПRТ╨ НЇО/УТ─НТНЇО,ТєП&Т╔П:НЇО)ДТЮП[ТАНЇО'╟Т■ПTТ∙НЇО%|ТмТнП?НЇО#GТ─П^НG?ТНЇО ?ТйПIТкНЇОТ·П<Т÷П&НЇОжТ╔ПMТіНЇО╒Т╔ТіПMНЇОm НЇОeТЄП,Т╣П3НЇО1Т┐П\Т└НЇОЭТ╡ПOТЁ НЇО хТяПPТрНЇО⌠Т┴Т┼П'spЪзЇL?Q\©DESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL70for separating data that is physically independent in the face of software and hardware failures, andthe data may be distributed over machines.Transactions provide a mechanism to encapsulate updates to a database. A natural approach toproviding the capabilities of augments in a database system might be to transform transactions intopermanent, full-fledged objects. Perhaps in terms of the simplicity criterion, the elaboration oftransactions has some merit. However, the implementation of long-term and short-termencapsulation of data updates must be quite different and the system would at least require somehint as to which physical model to use for a particular update. We chose in the Cypress data modelto make the permanent versus temporary distinction show through to the client, because there seemsto be little or no utility in avoiding the distinction. The applications we envision requiretransactions and/or augments, but not interchangeably.We currently chose to implement segments rather than augments. A segment allows new data(entities or relationships) to be inserted, possibly referencing entities in other segments. However,data may not be deleted or modified in a different segment than it resides. Furthermore,applications must simulate the effect of relations crossing segment boundaries where desired (usingthe "namesakes" correspondence). Segments handle many of the applications we envision,combining orthogonal databases from different applications. A few applications require augments,however (e.g. a database of different versions of systems). Others are simplified by augments (e.g.,several databases of people with overlapping information).Augments add little or no conceptual complexity: they simply make an entity with a given nameunique throughout instead of existing on a segment basis. Subtractive augments also have someutility even where they currently seem unnecessary: e.g., we might want to make personalmodifications rather than simply additions to a public database. We conclude that both the utilityand simplicity criteria are satisfied by augments. The implementation of augments is considerablymore complex than segments, so was deferred. 5.11 SummaryIn this section we have explained the rationale for our choice of data model. The criteria for ourselection are simplicity and utility, viewed from the perspective of existing or envisioned databaseapplications. Surprisingly, the choice of data model features in Cypress has been reasonably clearcut. Examining the needs of actual applications rather than postulating potential uses has greatlysimplified the choice of model.We started with the relational data model, adding the concept of entities. Entities insure referentialintegrity: the constraint that relations be between objects of specified types. We introduce entitiesЪНvОfЯptТF ptpt ptptpТXtТFptНMpНЇО_Т▓Т⌠ПJНЇО\АТ─П*НЇОYТ╦ПGТ╧НЇОVяТ⌠ПDТ■НЇОT²ТдП!ТеПAНЇОRhТ4П*Т5П+НЇОP4Т╒П=ТёП#НЇОMЪТ│П?Т┌П$НЇОKкТ│ПNТ┌НЇОI√ТЗП*ТШП3НЇОGbТ─П6НЇОC├ТфП>ТгНЇОARТ═ПLТ║НЇО?ТРП2ТСП'НЇО<ИТ≤П(Т≥П;НЇО:ЄТП1ТП&НЇО8─Т÷П;Т═П&НЇО6KТ▓П.Т⌠П7НЇО4Т─П:НЇО0;Т÷ПSТ═ НЇО.Т╡П^НЇО+рТППKТЯ НЇО)·Т≤ПRТ≥НЇО'iТіП8s pТїНЇО%5Т─П,Н){ТНЇОчrТ─НЇОpТ⌡П3Т°П0НЇОнТіПMТїНЇО Т÷ПRТ═НЇОeТ╙П7Т╚spНЇО1Т─НЇОUТ┼ПJТ▀НЇО Т⌡ПPТ°bMы>Q\2DATA MODEL DESIGN ISSUES71in a way different from most other data models. Some models treat entities as relationships: thatis, they allow entities to have fields just like relationships. We rejected this approach as it providestwo redundant representations of information and thereby violates the simplicity criterion as wedefine it. Some models treat relationships as entities; that is, they allow references to relationshipsfrom other relationships. We rejected this approach because it results in a network "spaghetti" towhich a high-level query language cannot be applied.We augmented the basic entity-relationship model with features of high utility and little additionalcomplexity: relational keys, unique entity names, segments, and a hierarchy of types. We alsoprovide a limited mechanism to represent existence dependencies between data: relationships aredeleted when an entity they reference is deleted, but relationships and entities in separate segmentsare independent. The basic features of Cypress are present in one or more other data models,although this is probably the first model combining all of these ideas.Other data model features appear to have high utility, but more work is needed to provide a usefulimplementation of such features. Augments fall in this category. More complex (multi-part, multi-type) entity names would also be useful, but we know no sufficiently general and efficientimplementation. Cypress has a limited mechanism for representing lists and sets using relationshipsto represent membership, but a better mechanism would be desirable.The Query level of Cypress will provide relational views and a higher level access language. A fairamount of research work already exists in these areas, and Cypress provides the same basis as otherdatabase systems for query and view construction. The Query level has been deferred for now,however.Н!dОfЯptТFptptptНG╘pНЇО_Т≈П]Т≤НЇО\АТ█П@Т▌П)НЇОZґТаТбПCНЇОXxТ∙ПFТ√П"НЇОVDТ·П`Т÷НЇОTТ─П4НЇОP4Т≥П5Т П/НЇОMЪТ╨П+Т╩П4НЇОKкТ╗ПNТ╘НЇОI√Т░Т▒ПYНЇОGbТ╪ТҐПBНЇОE-Т─ПGНЇОARТ▀П?Т▄П#НЇО?Т█ПcНЇО<ИТТТУП=НЇО:ЄТ─П1Т│П4НЇО8─Т─ПCНЇО4єТ▄Т█ПJНЇО2pТ┼П6Т▀П-НЇО0;ТІПFТЇНЇО.dЇ-ю=Г:K╟736. Data model implementation issuesIn this section we describe important aspects of our implementation of the Cypress data modeldefined in the previous sections. In the first subsection, we give an overview of the Cypress designand the storage primitives with which we are dealing. Then we discuss a number of specificoptimizations we have found useful in the implementation. In the last subsections, we describe theimplementation of each of the major operations in more detail and summarize our results.The Cypress DBMS runs on personal computers, in the Cedar programming environment developedin the Computer Science Laboratory. It is written in the Cedar language, a descendent of Mesa(Mitchell et al [1979]) with changes aimed at making Cedar particularly convenient for developingprototype systems.Cypress is built in four levels: the Model level, which implements the data model; the Storage level,which provides basic storage allocation and access structures; the Segment level, which manages thedatabase system's virtual memory; and the File level, which provides transaction-based file access.The File level can be one of a variety of file systems that provide page-level transaction-based accessto disk files. We currently use the Pilot system for files on the database client's machine, and theAlpine file server for remote files. In the latter case, the Model, Storage, and Segment levels run onthe user's personal machine, and the File level on an Alpine file server.The Segment level may communicate with the File level by local or remote procedure call. The Filelevel provides procedures to:1.open, close, and abort transactions,2.open disk files under transactions, and3.read and write file pages.The Segment level provides an LRU cache of database pages from the various segments, reducingnetwork traffic when the File level resides on a different machine. The Segment level implementsthe segment abstraction, including a mapping from 32-bit database addresses to underlying filepages. The lower levels of Cypress (the Segment and File levels) will not be of central concern to us for thepurposes of this report. In the next subsection, we describe the Storage level interface, and in theremainder of Section 6 we discuss the Model level implementation.ЪНG╘ОfЯpНЇО^оqТ─П$НЇОZСpТхП4ТиП)НЇОX©Т▓ПCТ⌠П"НЇОV┼ТуТжПTНЇОTVТ∙П"Т√ПAНЇОR"Т─ПXНЇОNFТ┼П/Т▀П,НЇОLТЁП*ТЄП4НЇОIщТ╗П-Т╘П4НЇОG╗ТНЇОCмТ─Т│ПSНЇОA≤Т∙ПcНЇО?dТ╞ПDТ╟НЇО;┬Т├ПNТ┤НЇО9TТ÷ПeНЇО7Т┘ Т├П\НЇО4КТПIНЇО1Т┌Т┐ПMНЇО.зТ─НUО*ЪНґП$НUО'#НґП'НUО#GНґНЇОkТєП>Т╔НЇО7Т²Т·ПIНЇОТжП,ТвП2НЇОнНШТНЇОРТ│П[Т┌ НЇОЎТ·ПeНЇО┴Т─ПAЪЛЇB>QWижDESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL746.1 Storage level structuresThe underlying Storage level provides the physical data structures used by the Model level:recordtypes, group lists, and indices. There is little that is particularly new in the Storage level, ituses reasonably well-understood mechanisms (the design is much like the RSS level of System R,Astrahan et al [1976]).Recordtypes are the basic storage mechanism for data. A recordtype is a set of records with fieldsthat can be (1) fixed length blocks of words, (2) variable-length byte strings, or (3) references toother records. Recordtypes are manipulated using recordtype and field handles that describe whatthe Storage level needs to know to perform an operation on a recordtype or one of its fields,respectively. (Specifically, we need to know the byte length of records in a recordtype, and the byteposition and size for its fields.)Both entities and relationships are represented as records. Entities are represented as records whosefirst field is the name. Relationships are normally represented as records whose fields are theattributes of the relation. Each domain or relation maps to a particular recordtype.Every record has a unique 32-bit tuple identifier or TID, which uniquely defines it. The CypressTID for a record contains its segment number, the page number where it is stored in that segment,and its record number on that page. TIDs can be used to find a record relatively efficiently,normally in one page access. The record number on a page is mapped to a record through an arrayat the beginning of the page. A record could be moved to another page without changing allreferences to its TID, simply by entering a forward reference in this array, to its new location on anoverflow page. We do not currently use this feature, however. Groups are doubly-linked lists maintained through records, also known as parent-child sets (SystemR). A "parent" record resides at the head of the group. The other records in the list contain threepointers:next: the TID of the next record in the groupprev: the TID of the previous record in the groupparent: the TID of the parent recordGroups are declared by defining a group field of a recordtype. Every record referenced by one ofthese group fields is the parent of a group list containing all records which reference that record inthat group field.The Model level currently uses groups as follows. If an attribute a is an entity-valued attributedeclared with link=Linked (see DeclareAttribute), it is defined as a group field at the Storage level.Thus, a group list is maintained for each entity e referenced by attribute a of one or more records inНvОfЯprТF prpr prprpТXrТFprНMpНЇО_sТ─НЇО[:pТУП7ТЖП$НЇОYtТ╚ptpТ╛ПCНЇОVяТґП^НЇОT²Т─НЇОPаt pТ═П-Т║П+НЇОN▄ТЄ Т╣ПYНЇОLXТ╛П+Тґt ptpНЇОJ#ТмПNТнНЇОGОТ┬ПfНЇОE╩ТП"НЇОAъТ▐Т░ПYНЇО?╙Тн ТоПUНЇО=vТ─ПUНЇО9 Т╔П5tpТіНЇО7fТ■ПPТ∙НЇО51ТмТнПIНЇО2ЩТ┬ПOТ┴НЇО0хТфТгПDНЇО.■Т▄П3Т█П3НЇО,_Т─rП-pН5ТНЇО(└tpТіПCtТїpНЇО&OТ▌П_Т▐НЇО$НґО ?Т─П-НґОП1НґОжП$НЇОЗТ² Т·t pП4НЇОфТ√ПWТ≈НЇО▒Т─НЇОІТ╧Т╨П%upНЇО │Т└ u pupП'Т┘НЇОMТ─П0Т│upup M?Q] DATA MODEL IMPLEMENTATION ISSUES75a's relation. Those records (the relationships which reference e) are linked together, with the entitye at the head of the list. For example, an entity of type "person" might be at the head of a numberof group lists, one for the first attribute of the "author" relation, two for the first and secondattributes of the "friend" relation, one for the second attribute of the organization-member relation,and so on. We can quickly find all the author relationships referencing a particular person byfollowing the group list associated with the first author attribute. Group lists are updated by theSetF operation on entity-valued attributes, and are used by the RelationSubset operation to processa query when an attribute value list contains an entity-valued attribute.Indices are B-Trees with variable-length string keys indexing TID values. More than one index entrymay be present with the same key. Indices are maintained by the Model level for the names ofentities in a domain, using the TID to reference the record representing the entity. The B-Treeindices on names are updated by the ChangeName and DeclareEntity operations, and may be usedby the DomainSubset operation. Indices are also maintained as requested by the client forrelations; these are updated by the SetF operation, and are used in the implementation of theRelationSubset operation. We describe DomainSubset and RelationSubset in Section 6.8.6.2 Entities and relationshipsIt is worth noting that Cypress application programs reference database items via handles rather thanthe cursors provided by most database systems. A handle is returned by Cypress whenever anapplication program retrieves a relationship or entity from a database. Application programs mayhave any number of entity-valued or relationship-valued variables, each containing a handle thatuniquely identifies the database object it currently references. Each call to NextRelship, GetF, etc.,produces another such handle. In other database systems (e.g. INGRES or System R), references totuples are made through cursors, with a higher overhead than handles. Client programs may copywhole blocks of data from a client buffer into the database tuple that is at the current cursorposition, or vice versa.We do not claim that handles are any better than cursors; we emphasize the difference because iteffects the design of Cypress. Handles have the advantage of tighter coupling between theprogramming language and DBMS: database items simply appear as values in the programminglanguage. Handles have the disadvantage of requiring garbage collection to determine whichdatabase references are no longer in use. The client indicates this explicitly in a cursor-basedDBMS. As already discussed, the Model level represents both entities and relationships as records. Therecords may be of three internal types: virtual, surrogate, or stored. Virtual records are systemschema entities, e.g. DomainDomain or StringType. Stored records are schema or data records;ЪНMОfЯprТFprpТXrТFprНG╘pНЇО_upТ░П.Т▒upП&НЇО\АТ┘П[Т├НЇОZґТлП.ТмП4НЇОXxТ∙ПfНЇОVDТдП\ТеНЇОTТ╛ПdНЇОQшupТ├П+Т┤u pНЇОOїТ─ПIНЇОKкtpТ│П]НЇОI√ТўПFТ╞НЇОGbТЇП#Т╦П=НЇОE-Т├П$u pТ┤upНЇОBЫТГТХupПGНЇО@еТкП$upТлНЇО>░u pТ─upu pНЇО89sНЇО4^pТ├Т┤ПMtpНЇО2)ТхtpП9ТиНЇО/УТ╚П]Т╛НЇО-юТ©ТюП@НЇО+▄Т▐ПKТ░u pupНЇО)WТ┼П'Т▀П:НЇО'#Т²Т·ПHНЇО$НТнП2ТоП-НЇО"╨ТНЇОчТ╔П]ТіНЇО╙ТУПEТЖНЇОuТфПXНЇОAТзП6ТшП&НЇОТрП)ТсП8НЇОьТНЇОЭТ©ТюПLНЇО хТЇТ╦ПCНЇО⌠ТІupu pТЇДЇL>Q\©.DESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL76these are the Storage level records we described in Section 6.1. They may represent relations,attributes, domains, relationships, or entities. Surrogate records are used in conjunction with thesurrogate relation optimization, which we describe in Section 6.6.Note that a TID can uniquely define an entity, just as a [segment name, domain name, entity name]triple does. However, TIDs are used only inside Cypress and are never provided to clients. TheEntities (and Relships) returned to the client are pointers to records that contain the TID and otherinformation; the client may not access these data, and the database system keeps a pointer to thisrecord so that the record may later be modified.Keeping TIDs a "secret" in this way has a number of advantages. Note that we can find allreferences to records in running programs, as we keep a list of the record handles in use by clientsof the system. We can find all references to records within databases, as the group lists and indicescan quickly be traversed to find references to a record, and we do not store TIDs outside of groupsand indices. As a result, we can:1.invalidate references to a record when it is deleted,2.move a record and update all references to it (we do not yet do this), and3.re-use TIDs formerly belonging to deleted records.Among other things, these features allow us to get by with TIDs as short as 32 bits, as we need onlyas many TIDs as there are records in the largest possible database. (Actually slightly more TIDs,since there is internal fragmentation due to the fixed maximum number of records per page).We never use TIDs for references across segment boundaries, although they could in theory be usedfor such as TIDs contain a segment number. The lack of cross-segment references makes segmentsindependent, so that one segment can be destroyed or rebuilt without affecting others. It also avoidsthe needs for a common network database that maps segments to database address space.Destruction or inaccessibility of such a common database would make all segments inaccessible.6.3 ValuesThe choice was made to represent values as REF ANYs in Cedar. A REF ANY is a pointer to anobject whose type is determined at run-time, via a type code stored with the object. REF ANYshave some inconveniences and inefficiencies, particularly the overhead of using a pointer when it isnot required (e.g., with INTs) and the overhead of the run-time NARROW operation which coercesthe REF ANY to a particular type. However REF ANY seems the best solution since convenienceЪНvОfЯprТF prpr prprpТXrТFprНMpНЇО_ТмП0ТнП/НЇО\АТ╧ПCТ╨П!НЇОZґtТ─pП0НЇОVяТ┼ПGТ▀НЇОT²Т╙П*tpП,Т╚НЇОRhupТ├Т┤upП6tpНЇОP4ТїПZТ╗НЇОMЪТП0НЇОJ#ТлП3ТмП'НЇОGОТ√П?Т≈П%НЇОE╩Т▌П-Т▐П9НЇОC├Т░ПcНЇОARТ─П"НUО=vНґП5НUО9 НґПJНUО5ЎНґП2НЇО1ЦТ├П(Т┤П<НЇО/ўТїТ╗ПMНЇО-zТ─П[НЇО)·Т┴ПYТ┼НЇО'iТ∙Т√ПEНЇО%5Т┐П<Т└П*НЇО#ТТП7НЇО лТ─ПDtpНЇОAs НЇОepТ≤П+upupТ≥НЇО1Т╘ПLТ╙ upНЇОЭТ▌П=Т▐П'НЇО хТ▒Т▓upП$upНЇО⌠Т≥upТ upП*Ъ >ML?Q\©DATA MODEL IMPLEMENTATION ISSUES77and simplicity of the interface is important.Because only a few of the many datatypes made available to alpha clients of the original CedarDBMS were widely used, we implement only REF INT, REF BOOL, REF GreenwichMeanTime,ROPE, and Entity values. Some other types, e.g. pointers to Mesa records, are still used by internalprocedures but are not currently exercised by client programs. Note that in our system particular Relship or Entity variables all have the same Cedar type; i.e.,there is not a different programming language type for each domain or relation. Run-timeoperations are provided to fetch the domain or relation to which an entity or relationship belongs.In the associative programming language LEAP (Feldman and Rovner [1969]), this run-time typing is taken to theextreme of treating a relationship's relation not as its type, but as simply another field of the record: relationships arenot typed. If this approach were taken in our implementation, for example, RelationSubset would not need the first(relation) argument: the user could specify the desired relation as part of the AttributeValueList or omit it. The typelessrelationships would provide little or no additional utility in our system, however, and in fact may complicate the worldfor a typical application. The cost of complete typelessness does not seem to justify any utility it may have.The run-time typing of relationships, entities, and values means that a fair amount of the code inthe dozen Model level operations is concerned with error checking. If at the Query level weintroduce a compiler for database operations, we can save execution time by performing many ofthese type checks at compile-time. Fortunately the caching of schema information avoids databaseaccesses for most of this checking, so the current overhead is not overwhelming.The Storage level implements strings of arbitrary and variable length. The length hint supplied toDeclareAttribute is used to decide how much space to allocate in the record itself, but thecharacters are stored elsewhere if the field overflows. It is currently not efficient to store stringswith thousands of characters in Cypress if the strings are frequently updated, because the storageallocation function is not designed to deal efficiently with data chunks larger than a page or so.We are implementing a supplementary package to Cypress which provides efficient storage of theselarge text strings, such as the body of a document or program. The actual text is stored inconventional files; the file, position, and size of a text string is stored in the database where it isreferenced. The supplementary package also implements a log of all database updates so that adatabase client may replay or back up database actions, independent of the database transactionmechanism. 6.4 Caching the data schemaIn order to improve the performance of the database system, we cache information about the client'sdata schema in a quickly-accessible form. On the first reference to an attribute, for example, thesystem saves the type of value the attribute demands, its relation, and its uniqueness. On subsequentЪНMОfЯprТFprpТXrТFprНG╘pНЇО_Т─П-НЇО[:Т╣ПOТІНЇОYТ÷Т═uП)НЇОVяpТ┐Т└ПMНЇОT²Т─П>Н3gТНЇОPаТїП#upupТ╗НЇОN▄ТКП;ТЛНЇОLXТ≥П$Т П?НЇОJGrТаП^ТбНЇОHYТ√ПjТ≈НЇОFkТіП*ТїПIНЇОD}Т│П@Т┌П=НЇОB▐Т≈ПBТ≤П6НЇО@~Т─ПoНЇО<╒pТ║Т╒ПOНЇО:nТлП2ТмП*НЇО89Ті ТїПSНЇО6Т≈ Т≤ПWНЇО3пТ─ПPНЇО/УТ≤ПRТ≥НЇО-юupТЕТФПCНЇО+▄Т╚П7Т╛П0НЇО)WТ╙ПZТ╚НЇО'#ТЁТЄПHНЇО$НТ▌П.Т▐П2НЇО"╨ТуП'ТжП5НЇО ├ТїПaТ╗НЇОQТЄТ╣tpП!НЇОТ╨П%Т╩П:НЇОХ Н(ТНЇО▒sТ─НЇОІpТ├ПDТ┤НЇО │Т╙П*Т╚П9НЇОMТ─Т│ПHЪlЇ?Г]'DESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL78uses the type-checking performed by GetF and SetF can be performed without access to the dataschema stored in the database. The attribute cache information is flushed whenever anAbortTransaction or DestroyRelation call is invoked.Schema caches are also maintained for commonly-accessed information about domains and relations(subtypes of a domain, indices on a relation).The schema cache is distinct from the Segment level's LRU cache of data pages. Although theschema is cached just as any other data at the Segment level, we wish to avoid all database operationoverhead, for examining schema entities. The schema-caching optimization makes a considerableimprovement in Cypress performance: it gives a factor of ten speedup in GetF in nearly alldatabase applications.Since the Storage level does not know how to deal with system records such as the DomainDomainor IntType, the Model Level must make exceptions for these entities in the implementation of anumber of operations. There are currently a few limitations in the way this is done; for example theDomainDomain is not actually in the enumeration of DomainSubset[DomainDomain], and user-defined Relships may not reference system entities. GetDomainRefAttributes and DomainSubseton the DomainDomain and RelationDomain had to be coded specially, and so on. SinceDatatypes (which are system entities, not stored in the database) cannot be stored by the underlyingstorage level, integers are stored corresponding to IntType, StringType, and so on, and these aremapped to the system entities when passed to or from the client program.The data schema is stored in four underlying storage-level recordtypes. These recordtypes are thedomain recordtype, relation recordtype, attribute recordtype, and index recordtype. The domainrecordtype has as attributes the domain name and the recordtype handle used by the underlyingstorage level. The relation recordtype has the same two attributes, plus a special attribute whichindicates whether the surrogate relation optimization has been performed on the relation. Theattribute recordtype has several attributes, indicating each attribute's type, uniqueness, and relation,and, if applicable, their length and the index they participate in. Indices are represented in an indexrecordtype.There are some ordering constraints on schema definition, as noted in Section 3. All of theseconstraints could be removed by enough special-case code, including deletion of attributes. Wechose to pass the buck to the data schema editing tool described in Section 7.2 for now.6.5 Links and co-locationAs discussed in Section 6.1, relationships with entity-valued attributes declared with link=Linked areinserted in a doubly-linked list (a group) with the entity they reference at the head of the list. ThusНvОfЯprТF prpr prprpТXrТFprНMpНЇО_Т╔ТіupupП,НЇО\АТ'П-Т(П)НЇОZґuТ─pupНЇОVяТ⌠ПUТ■ НЇОT²ТП.НЇОPаТ╩ПOТ╪НЇОN▄Т┌ПHТ┐НЇОLXТ╩ПOТ╪НЇОJ#ТвПHТьup НЇОGОТ─НЇОDТ▌П6Т▐uНЇОAъpТ╣upП@ТІНЇО?╙Т┌ПLТ┐НЇО=vupТ╟П'upТ╠НЇО;AТ≤upП%upuНЇО9 pТЗupu pП-НЇО6ыupТ├ПBТ┤НЇО4єТ╡П4upu pТЁНЇО2pТ─ПHНЇО.■Т╔ТіПZНЇО,_ТдПTТе НЇО*+ТЇ Т╦ПOНЇО'ВТЁТЄПPНЇО%бТяПYТрНЇО#▌Т═П^Т║ НЇО!YТ└Т┘ПHНЇО% НЇОIТйПPТк НЇОТдП9ТеП&НЇОЮТ─ПXНЇО┴sНЇОўpТ┌ПHТ┐u pНЇО yТ┬П#Т┴ПE4M 2>Q]ы)DATA MODEL IMPLEMENTATION ISSUES79groups provide an efficient way to find all references to an entity via a particular attribute. Thereare three other possible values for the link hint: Unlinked, Colocated, and Remote.Colocated is the same as Linked, but an attempt is made to store the relationship which referencesan entity on the same file page as the entity that it references. It provides even faster access to anentity from a relationship or vice versa. Only one attribute of a relation can be declared colocated.Relationships which reference an entity in this attribute are colocated with the entity and with eachother.Colocation must be performed by DeclareRelship when it creates a new relationship for which avalue has been specified for the colocated attribute. (SetP calls DeclareRelship, so it achieves thesame result; but SetF causes no colocation, as the record has already been allocated.) WhenDeclareRelship is called to create a relationship with a colocated attribute a with value e:1.DeclareRelship attempts to store the new relationship on the same page where e is stored;2.if that page is full, DeclareRelship attempts to store the new relationship on the same pageas the most recently created relationship referencing e in a.3.if that page is also full, or there are no other relationships referencing e in a, then therelationship is stored anywhere.One can imagine a number of variations on this algorithm; we have not experimented with them atthe time of this writing. One might profitably reserve pages for relationships referencing an entityon the basis of an estimate of the space that will be required.NOTE: colocation is not yet implemented at the time of this writing. Relationships are simply placed on pages in theorder they are created. We currently achieve some approximation to colocation by dumping a segment in textual form,with all relationships that reference an entity grouped together, and then reconstructing the segment from the dump file. The string name of referenced entities are stored in Unlinked attributes, rather than using a grouplist. Thus, groups cannot be used to find an entity from an unlinked reference to it, nor vice versa.When an attribute is declared Unlinked, the database client typically declares an index on theattribute with DeclareIndex, thereby making access to a relationship reasonably fast (logarithmic inthe size of the relation instead of a single page access, but rarely more than a few page accesses). Inother cases, an index is better than groups. Indices could use less space if entity names are short:groups require three 32-bit TIDs per record. If TIDs are simply being compared for equality, e.g.for a relational join, the TIDs may be compared directly in B-tree pages rather than fetching thepages containing the records themselves.Note that when GetF is performed on an unlinked attribute, a B-Tree lookup must also beНMОfЯprТFprpТXrТFprНG╘pНЇО_Т·ПfНЇО\АТ─П(upupupНЇОYupТ▐upП8Т░ НЇОVяТ√Т≈ПRНЇОT²Т⌠П"Т■ПDНЇОRhТ∙ПeНЇОP4НЇОLXТ╙u pТ╚П*НЇОJ#Т≈П7upu pТ≤НЇОGОТьupТыП#upНЇОE╩uТ─pП>up upНUОAъНґu pТ▀П?upТ▄НUО>НґТ└Т┘u pП8НґО;оТ─П6upuНUО7СpНґТЇПKupupТ╦НґО5ЎТ─НЇО1ЦТ▒ПWТ▓НЇО/ўТ²Т·ПUНЇО-zТ─П?НЇО)·rpТ▓rП0Т⌠П?НЇО'█Т≈ПNТ≤П&НЇО%|Т⌠Т■П^ТНЇО!═pТ÷П5upТ═ НЇОkТ▌ПfНЇО7ТрupТсП7НЇОТ√upТ≈П/НЇОнТ┘ПTТ├НЇО Т·П?Т÷П&НЇОeТ²П-Т·П5НЇО1ТўП#Т╞П>НЇОЭТ─П(НЇО ТЙupТКП(dЇы?Q\23DESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL80performed, to map the entity name onto the entity record that is returned. If GetFS is used, thislookup is bypassed.Remote indicates that an attribute may reference entities in other segments (in a different segmentthan the relation). Remote attributes are currently treated much like Unlinked: the name is storedinstead of a physical link (remember we do not want links, which are based on TIDs, to crosssegment boundaries). Unlike Unlinked attributes, the segment and domain name must be stored inthe reference as well as the entity name. The Remote attribute link hint is not technically necessary,as the Model level could determine how to store an entity-valued attribute "on the fly." It greatlysimplifies the implementation, however.If an index is not declared on an unlinked or remote attribute, the RelationSubset operation willtake time linear in the size of the relation to process a query whose attribute value list asks for aparticular entity value for the attribute. An unlinked and unindexed entity-valued attribute wouldbe useful only if the relation is known to be of a small fixed size, or queries are never performed onthe attribute.A time comparison of three simple cases of entity-valued attributes follows: an attribute declaredlinked but not indexed, an attribute declared indexed but not linked, and an attribute that is neitherlinked nor indexed. We show the times for the three common operations of fetching the attribute,setting the attribute, and doing a DeclareRelship operation with the OldOnly option to find therelationship with a particular value for the attribute (this is equivalent to a RelationSubset andNextRelship). These and all other measurements were performed on the Xerox Dorado computer; see Section 8.2 fordetails. Operationlinkedindexedunlinked, unindexedGetF1 ms4 ms1 ms + N*.5 ms, N = domain sizeSetF7 ms40 ms4 msFetchRelship4 ms32 msabout N*.5 ms, N=domain size These measurements were performed on relationships whose pages were already in the Segmentlevel's cache, thus the "linked" column is near the ideal time one would obtain if records werecolocated. The difference between linked and colocated times depends on a particular application'sdata schema, of course. A page read and write both require approximately 60 ms. Thus GetF andSetF could take as much as 60 ms in the worst case. For typical applications, the payoff fromcolocation is much smaller than that, but still seems to produce more than a factor of two speedupin both GetF and SetF.If the surrogate relation optimization is applicable, the basic operations are still faster. GetF on alinked entity-valued attribute, for example, averages about 0.3 ms. This compares to 1 ms in theЪНvОfЯprТF prpr prprpТXrТFprНMpНЇО_Т═Т║П:up НЇО\АТ─НЇОYupТ Т⌡ПNНЇОVяТ▀upП,upНЇОT²ТдП$ТеП8НЇОRhТ░upТ▒П:НЇОP4Т─Т│upП2НЇОMЪТ ПYТ⌡ НЇОKкТ─П'НЇОGОТєtpТ╔П2u pНЇОE╩ТіТїПNНЇОC├ТєП;Т╔П(НЇОARТ└П*Т┘П<НЇО?Т─ НЇО;AТ╘ПcНЇО9 Т┼ПLТ▀НЇО6ыТ≤ПVТ≥ НЇО4єТЄТ╣u pupНЇО2pТЎПMТ©u pНЇО0;u prТ┤Т┬П\НЇО.pТ─Н═О*+sН─Н#ЮН,─ТН═О&OuН─pТ─Н#ЮН,─ТН═О$uН─pТ─Н#ЮН,─ТН═О!ФuН─pТ─Н#ЮН,─ТНЇОТфПRТгНЇОжТ©ТюПLНЇО╒Т∙ Т√ПXНЇОmТ▒П$Т▓П3upНЇО9upТ╨П#Т╩П7НЇОТ≤ПVТ≥НЇОпТupupНЇОТТёП^upТєНЇО юТ╛П]ТґЪ ЮM y>Q]▓ODATA MODEL IMPLEMENTATION ISSUES81above table. Note that the introduction of entities to the relational model allows the DBMS to make someintelligent guesses as to where to use colocation and links. By default, an attempt is made to linkand colocate relationships with the entities they reference. This may be overridden by the client, ofcourse.Our current database applications most frequently retrieve together all or most of the relationships,from a variety of relations, which reference a particular entity. Most implementations of theRelational model store the records of a relation contiguously. The relational arrangement results inmany more page reads than ours for the entity-centric access we find most common.6.6 Surrogate relationsThe surrogate relation optimization is used when DeclareAttribute is called to define the firstattribute of a relation, and: (1) the attribute is entity-valued, (2) it is a primary key of its relation,(3) its type is a domain with no sub-types, and (4) that domain does not yet have any entitiesdefined in it. The relation is then specially tagged as being a surrogate relation, and the 2ndthrough Nth attributes will be added to the domain's recordtype, i.e. the data will be stored in theentities rather than separate records. The relation itself will not exist as a recordtype, and anyrelationships in the relation will be represented as surrogate records. Thus the records that represententities may have fields in addition to the entity name, containing surrogate relation attributes.The data schema must record the relations for which the surrogate relation optimization has beenperformed, for internal use. This information can also be useful to select clients such as the dataschema update tool. When compared to colocation (i.e. first attribute declared Colocated), the surrogate relationoptimization is an improvement in two ways. First, a surrogate relationship uses less space (noadditional record and link overhead); this may allow information to be stored on the same page.The overhead of an additional page access (60 ms) can make a considerable difference in anoperation that takes less than 1 ms (GetF). Also, accessing the field directly rather than followingthe link to another record is somewhat (currently about .4 ms) faster even when the other record ison the same page.The effect of the surrogate relation optimization on Cypress performance is of course dependentupon its applicability to a particular application's data schema. In general, we find that the surrogateoptimization can be performed on about half the relations in the schema. For the electronic maildatabase application, construction of database entries runs about 30% faster with the surrogaterelation optimization enabled (instead of just colocation). Other operations, e.g. displaying aНMОfЯprТFprpТXrТFprНG╘pНЇО_Т─НШТНЇО[:ТяП8ТрП#НЇОYТ÷П1Т═П3НЇОVяТ▌ПBТ▐П$НЇОT²НЇОPаТ°П1Т²П4НЇОN▄ТАП"ТБП<НЇОLXТ∙П>Т√П'НЇОJ#Т─ПQНЇОCмsНЇО?ЯpТьП&Ты upНЇО=╪Т≤ПLТ≥НЇО;┬ТдПHТеНЇО9TТмПJТнНЇО7Т·Т÷tpП0НЇО4КТеП@ТфП#НЇО2ІТ└Т┘ПTНЇО0┌Т─ПbНЇО,іТ╚П7Т╛П)НЇО*rТіПAТїП#НЇО(=Т─Н?ТНЇО$aТП;upТНЇО"-ТаП!ТбП?НЇОЬТ╡ПFТЁНЇОдТчП<ТъНЇО░Т═П%upТ║П%НЇО[Т■ПJТ∙НЇО'Т─НЇОKТ╩ Т╪ПUНЇОТ│ПEТ┌П$НЇОБТёТєПAНЇОўТъП%ТЮП:НЇО yТРПBТСЇ 2?Q]ыDESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL82message, have equal or better performance improvement.We could allow database clients to specifically indicate when the surrogate relation optimizationshould be performed, as we do with links. The optimization appears desirable whenever possible,however, so this unnecessary. Note the restrictions mentioned earlier on the application of the surrogate relation. The restrictionthat a domain have no subtypes is made to simplify the problem of assigning field positions in therecordtypes. The restriction that the domain be empty is made to avoid reconstructing or markingexisting entities which would not have the field. The latter restriction is similar to one on relations,that attributes may only be added to a relation while it is empty. The schema editing tool described inSection 7 makes such restrictions invisible by copying the domain or relation when necessary.6.7 Basic operationsIn this subsection, we discuss more details of the basic operations on entities and relationships.DeclareEntity and DeclareRelship simply create a record in the underlying domain or relationrecordtype, updating any associated index entries. The DeclareEntity operation uses theDomainSubset operation to determine whether an entity with the given name already exists.DeclareRelship similarly uses RelationSubset to determine whether the given relationship alreadyexists, unless version is NewOnly.A small complication is introduced by the interaction of the surrogate relation optimization and theuse of indices. The attributes of relationships of a surrogate relation are stored as "attributes" ofentities in the target domain. Index entries reference the entities. This would suggest that we mustcreate index entries when the entities are created. The semantics of null values can be used toimprove efficiency, here: we need make no entries until values are actually assigned. This shouldnot be done until surrogate relationships are created and their attributes assigned values. GetF and SetF must make special checks for the surrogate relation optimization; when thisoptimization has been performed, the storage level "field handles" for attributes of the relationactually reference fields of the domain, in which the relation's attributes are stored. With SetF, aparticular constraint has currently been added: the key attribute of a record must be assigned before others, so that theModel level knows which entity in the domain is being referenced. Note this would not be a problem if we disallowedSetF, requiring that whole relationships be created or destroyed as units.Type checking is necessary only for one operation, SetF. If the domain sub-type hierarchy is notused, i.e., an entity stored in an entity-valued field is precisely of the domain required by theattribute, the check is fast. Furthermore, if type-checking is thwarted altogether, i.e., the attribute isНvОfЯprТF prpr prprpТXrТFprНMpНЇО_Т─П6НЇО[:ТгТхПYНЇОYТ╔ТіПWНЇОVяТ─Н$┐ТНЇОRУТ°ПUТ²НЇОPаТ≥П6Т П,НЇОN▄Т°П>Т²П#НЇОLXТ▐П[Т░ НЇОJ#Т╔ТіП*rП&НЇОGОТ─П]НЇОA≤sНЇО=╪pПbНЇО9АupТхu pТиП<НЇО7╛Т1П8up Т2НЇО5xupТКТЛП6НЇО3Cu pТ·upТ÷П'НЇО1Т─upНЇО-3Т∙П<Т√П(НЇО*ЪТ╚ПHТ╛НЇО(йТ▐ПYТ░НЇО&√ТЎtpТ©П-НЇО$aТ⌡П2Т°П1НЇО"-Т─П[НE⌠ТНЇОQТЬТЫПLНЇОТлТмПLНЇОХТ╩ПWrТ╪НЇОЄТ▐П.prП"Т░П'НЇОёТ▒ПtНЇО▒Т─ПJНЇОІpТёТєupП*НЇО │ТоПZТпНЇОMТ█ПhТ▌┼M?Q]DATA MODEL IMPLEMENTATION ISSUES83of type AnyDomainType, the check is even faster: the system need only check that the base type(i.e., entity-valued, string-valued, etc.) is correct. In the case that a check on the attribute's domaintype fails, SetF recursively searches up the hierarchy from the actual entity type looking for theattribute's type. It fails upon finding no more super-types. (Searching upward is faster thansearching downward for randomly-selected examples in the domain type lattice in the largestapplication schema we have so far.) More efficient schemes could be implemented if necessary, e.g., pre-computing the super-domains and redundantly storing the list with each domain.SetF must update group lists when they are being maintained for entity-valued attributes, asdescribed earlier. Conversely, if links are not maintained for an entity-valued attribute, GetF mustperform an index lookup to map the stored entity name into the entity handle returned to the client(GetFS need not do this lookup, however, as it is only required to return the name). SetF usesRelationSubset to determine whether key constraints are violated by the new attribute value.The algorithm for DestroyRelship is relatively simple. The Storage level operation to destroy therecord automatically deletes the record itself and removes it from the linked list maintained throughall records of its recordtype. Variable-length strings which have overflowed the space allocated inthe record (the length argument to DeclareAttribute) are stored in separate pseudo-records thatmust also be de-allocated. Also, any index entries for the destroyed Relship must be deleted, andthe relationship must be removed from any group lists in which it participates.DestroyEntity is similar to DestroyRelship, but any relationships that reference the entity must alsobe destroyed. There are three special cases of relationships referencing an entity:1.Surrogate relationships stored in the entity record itself must be destroyed; the commentsabout deleting variable-length strings and updating groups and indices apply as inDestroyRelship.2.Relationships linked to the entity via a Linked attribute may be found and deleted quickly.3.Relationships referencing the entity via an Unlinked attribute must be found by aRelationSubset operation on attributes that can reference an entity of the kind we aredeleting. A group list of these unlinked attributes is maintained in the database for eachdomain, to make this operation more efficient.The Eq operation returns TRUE iff its arguments have identical TIDs. If its arguments are fromdifferent segments they will have different TIDs, of course, as the segment numbers are stored as thehigh order bits of the TIDs. The correspondence between segment numbers and atoms ismaintained to implement the SegmentOf operation.НMОfЯprТFprpТXrТFprНG╘pНЇО_Т°upТ²П7НЇО\АТ√ПSТ≈НЇОZґТ╩upТ╪tpП:НЇОXxТзП_НЇОVDТППLТЯНЇОTТнП#rТоП.НЇОQшТ─ПNНЇОMЪupТИТЙП;НЇОKкТ°П-tpП+Т²upНЇОI√Т┴ПLТ┼НЇОGbupТ╛П0ТґupНЇОE-u pТ─ПNНЇОARТёu pТєП,НЇО?Т▌ПFТ▐НЇО<ИТїП7Т╗П-НЇО:ЄТюupТаupП,НЇО8─Т°Т²П:upНЇО6KТ─ПOНЇО2pupТ┼ Т▀upП:НЇО0;Т─ПTНUО,_НґТіТїП<НґО*+ТПRНґО'Вu pНUО$НґТ▀П)upТ▄НUО ?НґТП,upНґОu pТбП!ТцП'НґОжТ╔ПVТіНґО╒Т─П.НЇОфТ╘up Т╙upПBНЇО▒Т│Т┌ПSНЇО]ТЧТЪП9НЇО)Т─up Ъ&ЇБ>QY)+DESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL84The procedure GetAllRefAttributes is implemented using a special Storage level operation thatreturns all the groups in which an [entity] record participates. As unlinked attributes will not befound by this operation, they must be added to the list returned by GetAllRefAttributes, as well.6.8 Aggregate operationsIn this section, we discuss details of the DomainSubset and RelationSubset algorithms that havenot already been covered.The algorithm for DomainSubset is relatively simple. If a name or range of names is specified inthe call, the index for the domain is used; otherwise the linked list the Storage level providesthrough all the records of the domain recordtype is used. If it is requested that subdomains besearched, a DomainSubset operation is invoked on each in sequence. Whatever the method, theinformation about the enumeration is packaged up in the EntitySet returned so that NextEntity cansequence through the indices, lists, or domains as required.The algorithm for RelationSubset is somewhat more complex than DomainSubset. We are givenan AttributeValueList, composed of triples of the form [attribute, low, high] constraining the givenattribute to have a value greater or equal to low and less than or equal to high. The high value istypically omitted and is then assumed to equal low. The high value must be omitted for entity-valued attributes, since a range of values makes no sense in that case. RelationSubset must choosean efficient manner in which to find the relationships satisfying the list.The following strategies are used by RelationSubset, in this order:1.If the surrogate relation optimization has been performed on the relation, then (a) if a key-valued attribute is contrained to equal a particular entity in the attribute-value list passed toRelationSubset (the constraint list), we may return a single-element RelshipSet; (b)otherwise, we set a boolean in the RelshipSet (the one we will return) to indicate thatwhichever of the strategies 2, 3, and 4 are used below, NextRelship must convert theentities we obtain to surrogate relationships.2.If one of the attributes in the constraint list is entity-valued, then we use the group list forthe given entity value. That constraint is removed from the list, and the remaining reducedlist, is saved to be serially checked by NextRelship against records in the group list.3.If there is an index on one or more of the attributes in the constraint list, the indexcontaining the largest subset of the attributes is used to find the relationships satisfying thatsubset of the list. The remaining reduced list is checked by NextRelship, to filter therelationships enumerated from the index.ЪНvОfЯprТF prpr prprpТXrТFprНMpНЇО_Тв upП7ТьНЇО\АТ╞П@Т╟П$НЇОZґТ╚ПDup НЇОTVsТ─НЇОPzpТіТїupu pНЇОNFТ─НЇОJjpТ≤upТ≥ПCНЇОH6ТоП`НЇОFТІП0ТЇП0НЇОCмТ╙upТ╚П/НЇОA≤Т▐П8upТ░u pНЇО?dТ─П<НЇО;┬pТ≤u pТ≥upНЇО9TТ█upП"u Т▌ pНЇО7Т▒П.upupТ▓upНЇО4КТґТўupuptpНЇО2ІТ▄П<Т█u pНЇО0┌Т─ПKНЇО,іpП%u pНUО(йpНґТ▄Т█ПDНґО&√Т┤ПWТ┬ НґО$au pТДu pТЕП'u pНґО"-ТҐП#u pТЎНґОЬТоП'Тпu pНґОдТ─П.НUОХpНґТ┴Т┼u pП6НґОЄТ▄Т█П>tНґОpТ─П%u pП#НUОєpНґТгП8Тхu pНґОoТ┼П?Т▀П"НґО ;ТбП/Тцup НґОТ─П'u юM ©>Q]LDDATA MODEL IMPLEMENTATION ISSUES854.If all of the above strategies fail, the underlying storage-level operation to enumerate the listthrough all records of the relation's recordtype is invoked, and NextRelship serially filtersout the relationships satisfying the constraint list.The NextRelship operation enumerates the appropriate group, index, or recordtype as specified bythe RelshipSet that RelationSubset produced. As all three of these enumerations are bi-directionalat the Storage level, PrevRelship is a straightforward inverse of NextRelship. Note the slightcomplication in NextRelship and PrevRelship introduced by the surrogate relation optimization. Inthat case, the indices, group lists, or recordtypes can be scanned as usual, but refer to entities ratherthan the surrogate relationships which have been mapped to them. Surrogate relationships arecreated on-the-fly.The time required by the RelationSubset operation is of course dependent upon the path throughthe above algorithm taken, whether an index or group is scanned, and so forth. A typicalapplication averages about 7 ms for a variety of RelationSubset calls. Thanks to the schema cache,only about half of this time is spent examining the data schema to check the validity of the queryand determine which physical access path to use to process it.The time for NextRelship is typically 0.4 ms, and is nearly the same for a group, index, orrecordtype enumeration. Currently most of this time is for the Cedar allocation of the Relshiphandle itself! However, the NextRelship time will be much larger for a database applicationwithout a working set in the database page cache: the time to fetch pages will dominate.We will not discuss the MultiRelationSubset operation and Query level here, as they have not yetbeen constructed. One possible plan would be to (1) build a parser at the Query level to map textqueries into a tree representation, (2) make a major extension of the RelationSubset operation tooptimize access path selection over the entire query, (3) make a minor extension to RelshipSets(and NextRelship) to allow them to act upon nested relations (still producing a single relation at thetop level), and (4) build a Query-level formatter which prints the RelshipSet enumeration for theclient. 6.9 SummaryThe Cypress DBMS is built in four levels: the Model, Storage, Segment, and File levels; in thissection we have concentrated on the implementation of the Model level. We summarized theoptimizations made in that implementation:1.caching the data schema,2.use of B-tree indices upon entity names and relation attributes,НMОfЯprТFprpТXrТFprНG╘pНUО_НґТ┌П3Т┐П.НґО\АТ·Т÷П'upНґОZґТ─П%u puНЇОVяpТ·u pТ÷П<НЇОT²Т┘u pТ├u pПAНЇОRhТмu pТнП!upНЇОP4Т├u pu pП4Т┤НЇОMЪТ▌ПBТ▐П'НЇОKкТоП7ТпП&НЇОI√Т─НЇОE╩pТ≥u pП!Т НЇОC├ТНП%ТОП4НЇОARТ┼П1u pТ▀НЇО?Т·ПBТ÷НЇО<ИТ─П>НЇО9 pТчupП8Тъ НЇО6ыТЎПWТ©uНЇО4єpТк Тлu pП4НЇО2pТ─ПYНЇО.■pТ°urpП"Т²НЇО,_Т■Т∙ПPНЇО*+Т╔ ТіП8u pНЇО'ВТЇТ╦ПEu НЇО%бpТ├u pТ┤ПRНЇО#▌ТіТїП(u pНЇО!YНШpТНЇОsТ─ НЇО'pТІПOТЇНЇОРТсП5ТтП$НЇОЎТ─П*НUОБpНґНUОpНґП@ 8Ї ©>Q]L-DESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL863.use of "group" links through relationships referencing an entity4.co-locating relationships which reference the same entity on the same page, and5.storing relationships which reference an entity as surrogates in the entity itself.Caching the data schema is crucial to good performance; almost all operations must examine thedata schema to check the legality of the client's request or to decide how to perform the operation.The payoff can be as much as 90%.The payoff from the use of indices is variable, but they are crucial upon entity names and are oftenbeneficial upon relations. There is a trade-off between using indices and links on relations; indicescan be used on multiple attributes and use less space if the keys are short, but links are typically afactor of three faster.It is enlightening to observe the progressively better performance for the GetF operation on anentity-valued attribute that is (1) indexed, (2) linked, (3) colocated, or (4) surrogate. As just noted,links are typically a factor of three faster than an index, as at most one page (other than the page onwhich the relationship resides) is accessed. Colocation typically produces another factor of three orso, though this varies widely with database application. The surrogate relation optimization providesanother factor of two or so, by avoiding another tuple lookup (on the same page). The best time fora GetF is currently about .2 ms.In Section 5, we showed how the Cypress data model was designed to provide a higher-levelconceptual model, simplifying the development of database applications. In this section we haveshown that a higher-level data model can also be used to improve the performance of a databasesystem, by capitalizing on the additional knowledge of data semantics and interconnectivity. InSection 7 we will concentrate on the third advantage of a higher-level model: the more powerfultools and integration of database applications it enables.ЪНvОfЯprТF prpr prprpТXrТFprНMpНUО_НґТ─П@НUО[:pНґПOНUОW^pНґПSНЇОS┌pТЄП^НЇОQNТ∙П(Т√П<НЇОOТ─Н$┐pНЇОK>Т█ПPТ▌НЇОI Т√П8Т≈П.НЇОFуТ≤ПfНЇОD═Т─НЇО@еТеПJТфupНЇО>░Т≤ПbТ≥НЇО<\Т└П1Т┘П6НЇО:'Т≈ПfНЇО7СТ┬П9Т┴П-НЇО5ЎТ┌ПEТ┐НЇО3┼Т─upНЇО/ўТыТзПLНЇО-zТІТЇПOНЇО+EТ╚ПDТ╛НЇО)ТгТхПIНЇО&эТ╔ТіПCНЇО$╗Т─П:ЪХM$a?QC╙и877. Database environment and applications7.1 Database environmentAlong with the development of the Cypress DBMS, adding the Model level facilities to the formerCedar DBMS, we built a system named Squirrel to provide some general-purpose database tools andsome level of integration between database applications. Several applications of the database systemhave been developed. These applications include Walnut, a database of electronic messages, andHickory, a calendar/appointment database.Squirrel provides the end user with tools to perform a number of basic database operations. Thesetools include:1.A browsing window to examine database entities and relationships.2.An editing window to modify database entities and relationships.3.A simple query window to search databases.4.A facility to dump databases in textual form, and subsequently reload them. The externalform is human-readable text, and contains the database schema as well as the data.5.A facility for examining and modifying the database schema, automatically re-organizingexisting data for simple schema changes.These five basic functions may provide all a user requires for simple kinds of database applications.For example, for some personal databases (a wine database, and a database of phone numbers andaddresses) we have found the Squirrel tools useful in and of themselves. Squirrel is also used bydatabase application programmers to examine and modify a database in the process of testing anddebugging application programs.In addition to the facilities directly provided the end user, Squirrel provides facilities for applicationprograms. Squirrel's function in this regard is to encourage a consistent and integrated userinterface among the various applications. The goal is a confederation of database facilities asopposed to monolithic independent programs. Squirrel provides some convenient procedures forcommon database operations and Cedar Viewers operations, common conventions for the userinterface, and a mechanism for applications to communicate with one another when data isdisplayed and updated. НG╘ОfЯpНЇО^оqТ─П)НЇОX2rНЇОTVpТ Т⌡ПBНЇОR"Т└Т┘ПKНЇОOМТ▄П*Т█П;НЇОM╧ТІП[ТЇНЇОK>Т─П)НЇОGbpТ⌠Т■ПQНЇОDГТ─ НUО@еpНґПAНUО<╒pНґП@НUО8─pНґП*НUО4єpНґТ≤П-Т≥П,НґО2)Т─ПRНUО.MpНґТ©П*ТюП-НґО+рТ─П(НЇО'ВpТ▀ПeНЇО%бТ⌠Т■П@НЇО#▌Т÷П5Т═П-НЇО!YТ·ПHТ÷НЇОчТ─НЇОpТ┤П3Т┬П7НЇОнТАПNТБНЇО ТсТтПEНЇОeТ╡П,ТЁП1НЇО1ТзП8ТшНЇОЭТРП?ТСНЇО │Т─Н?pТЪ,Ї :>ГZяыDESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL88The user interface paradigm we use provides one Cedar Viewer on the screen per database entity,an object-oriented menu of commands upon a database entity, and a consistent interpretation ofuser selections on the screen. The paradigm is based upon three basic types of applicationwindows: displayers, editors, and queryers. A displayer displays a database entity, provides a menuof commands upon it, and shows the information the database contains about the entity. Forexample, for an electronic message displayer, the message's header and body would be displayed,along with commands such as Answer, Forward, and Delete. An editor looks much like a displayer,but allows the user a form with which to modify the information about the entity, and usually has adifferent set of commands. For example, a message editor is created in response to a NewForm orAnswer command in the Walnut system; the user fills in the fields and invokes the message editor'sSend or File command. A queryer also looks like a displayer and editor, but the user may fill inthe fields with values, boolean expressions of values, or other application-interpreted information;the queryer represents all entities in its domain which satisfy the constraints. When the userinvokes the Query command, the entities satisfying it are displayed and may be browsed or printed.Each database application program, such as Walnut or Hickory, registers itself with Squirrel bypassing procedures to be called when an event of interest to the application occurs. The applicationmay register a displayer, editor, or queryer procedure to be called when the user requests one for aparticular domain. Walnut registers such for the message domain, for example. An application mayalso register itself to be called when certain database relations are updated, so that it may update itsdisplay.Figure 7-1 illustrates a variety of types of displayers. Note how each application takes bestadvantage of the display for the particular type of entity involved. Figure 7-1a is a messagedisplayer, implemented by Walnut. Figure 7-1b shows a month displayer, implemented by Hickory.Figure 7-1c shows a picture displayer, implemented by a simple image application. Figure 7-1dshows a relation displayer, implemented by a data schema display package. Figure 7-1e shows a"whiteboard" displayer, used for spacially organizing and accessing entities. Figure 7-1f shows a"default" displayer which is invoked when no particular application deals with the given domain (inthis case, the Organization domain). Squirrel implements the default displayers, whiteboarddisplayers, and schema displayers.Figure 7-2 contrasts a displayer, editor, and queryer for messages.Figure 7-3 illustrates one way in which the collection of database applications may appear as anintegrated collection of facilities to the user, showing successive windows on the screen as the userbrowses from a "Whiteboard" display, to a "Message Set" on that whiteboard, to a "Message" inthe set, to the sender of the message. The user crosses application boundaries in going from onekind of entity to another, but the action to browse (pointing with the mouse and pushing its centerbutton) is the same throughout. НvОfЯpsТF psps pspspТXsТFpsНMpНЇО_Т²ПCТ·НЇО\АТІП?ТЇНЇОZґТФТГП<НЇОXxТ▒ t ptptptpТ▓П#НЇОVDТхП"ТиП9НЇОTТ╘П-Т╙П2НЇОQшТ└Т┘П*tpНЇОOїТ└ПIТ┘НЇОMrТ█ПSТ▌НЇОK>Т┤Т┬ПFНЇОI Т·Т÷tpПAНЇОFуТ╚П.Т╛П6НЇОD═ТсП*ТтП5НЇОBlТ┬Т┴ПHНЇО>░ТеП>tpТфНЇО<\Т┘ПYТ├НЇО:'Т▄П$Т█П@НЇО7СТ─П^Т│НЇО5ЎТ┤П7Т┬П1НЇО3┼НЇО/ўТБТЦП>НЇО-zТтПTТу НЇО+EТ┐П)Т└П6НЇО)Т╣ПRТІНЇО&эТ╚ПJТ╛НЇО$╗Т╡ПZТЁНЇО"sТ├П$Т┤П?НЇО ?ТШП%ТЭП7НЇОТ─П"НЇО/ПCНЇОSТ╡П+ТЁП5НЇОТ ПNТ⌡НЇОЙТєП)Т╔П4НЇОІТ║П+Т╒П6НЇО │Т▌П"Т▐ПAНЇОMТ─Н$┐ТДM>Г]>DATABASE ENVIRONMENT AND APPLICATIONS89Squirrel, Walnut, and Hickory will be more fully described in a future report. To put the databasework in context, however, we will summarize Squirrel in Section 7.2 and the applications in Section7.3. 7.2 Database toolsA Squirrel window on the screen provides the user with the basic database functions, such ascommiting or aborting a transaction, dumping or loading a database, or erasing portions of adatabase. The Squirrel window also allows the user to explicitly invoke a displayer, editor, orqueryer on a particular domain or entity. If no application has registered itself for the givendomain, Squirrel invokes its default application-independent displayer, editor, or queryer when theuser requests one.The default entity displayer shows the domain and name of the entity displayed at the top of aCedar Viewer window, and all the relationships in the database which reference that entity areshown as the main body of the window. An example of such a window is in Figure 7-3d. Therelationships are diplayed in the formrelation attribute1: value1 attribute2: value2 ... attributeN: valueNwhere relation is the relationship's relation and the attribute: value pairs specify the values of itsattributes. The attribute which references the displayer's entity is not shown, as it is normallyredundant (all of the relationships in the displayer for an entity have at least one attribute whichreference the entity or they would not be displayed). The other attributes are displayed in theobvious way for string, integer, and boolean values. For entity values, the name of the entityreferenced is displayed. In addition, for entity values, the user may select the entity with the center(yellow) button on the mouse, causing a displayer to be created on the screen for the selected entity.This selection with the yellow-button provides the basis for browsing, and is supported by Squirreldisplayers as well as application displayers.The default editor window also shows the domain and name of the entity being edited at the top ofthe window. However it differs from the default displayer in that an editable form is provided inthe body of the window for the entity, showing not only those relationships which already referencethe entity, but "blank" relationships for relations which could potentially reference an entity of itsdomain. A "blank" relationship appears as a relationship in a displayer, but the values are given asblank fields that can be filled in by the user by selecting the blank with the red mouse button andtyping. If the editor window is on a new entity (one that previously did not exist in the domain),then all the relationships shown will be blank ones. Special combinations of mouse buttons invokeЪНrОfЯpsТFpsps НG╘pНЇО_Т▀П?Т▄П$НЇО\АТ┴П4Т┼П/НЇОZґНШТНЇОR"rТ─НЇОNFpТмТнП=НЇОLТьП9ТыП#НЇОIщТгПUТх НЇОG╗ТмПKТнНЇОEtТ⌡ПGТ°НЇОC@Т─НЇО?dТ╡ПQТЁНЇО=/ТдТеПFНЇО:ШТіП4ТїП&НЇО8фТ─П&НґО4КuТПGНЇО1pТ∙upП(u Т√pНЇО.зТгПVТхНЇО,іТіП&ТїП>НЇО*rТ╩П:Т╪П&НЇО(=ТеП$ТфП;НЇО& Т┤П1Т┬П7НЇО#тТ│ПUТ┌НЇО!═Т∙П.Т√П5НЇОkТ─П-НЇО░Т├ПZТ┤НЇО[Т°ПOtpТ²НЇО'Т┤П=Т┬П&НЇОРТ·ПUТ÷НЇОЎТ┬ПQТ┴НЇО┴Т▒ПcНЇОUТ≈П5Т≤П.НЇО Т▌П%Т▐П=Ъ ьЇы>Г\2 DESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL90special commands on the blank relationships: creating a new blank relationship for a particularrelation, explanding the blank relationship to show the types expected of the fields, or specifyingwhether the system should automatically create an entity when a field value is filled in with anentity name that does not exist in the appropriate domain. Menu buttons at the top of the editorcan be used to change the name of an entity or merge it with another entity.The default queryer window has a form similar to an editor window, except that only a domainname is shown at the top of the window. The queryer window, unlike an editor window, representsany number of entities in a domain which satisfy a query. The query is specified by filling in theform fields with expressions that specify the desired values of the fields. The expression mayinclude boolean ORs (written as "|"), and also ranges of values (written using "~", e.g. "5~11").After the form has been filled in and the user uses the window's Query command, the queryeropens a new window on the screen displaying the names of the entities which satisfy the query.The client may scroll through the entities, or select one of them with the yellow mouse button toopen a displayer on it. Note that except for the form in which the answer is examined, this queryerwindow is similar to the Query-by-Example system of Zloof [1975].In addition to displayers and editors on ordinary data items, Squirrel implements special displayersand editors for domains and for relations. The displayer for a domain shows the attributes in thedata schema which can reference an entity from that domain, the sub-types and super-types of thatdomain, and the entities of the domain sorted by name. The user can scroll or yellow-select theentities. The editor for a domain shows only the sub-types and super-types, and allows the user tochange these. The editor will automatically copy entities and rename domains if necessary toachieve the effect of a requested change (because the underlying database system does not allowdefining sub-types of a domain that already contains entities). The displayer for a relation shows atable whose columns are labelled with the names, types, and uniqueness constraints of the relation'sattributes. An example of a relation displayer is shown in Figure 7-1d. The rows of the table showall of the relationships in the relation. Again, the user may scroll through the relationships, and mayyellow-select attribute values that are entities to open a displayer window. The editor for a relationshows only the attribute names, types, and uniquenesses, and allows the user to change these. Theuser may also delete attributes of the relation or create new ones; the relation editor willautomatically copy all the relationships into a new relation with the same name, since the underlyingdatabase system does not allow changing attributes of a relation after relationships exist.Squirrel and application programs support a common interpretation of mouse buttons for the user.This common interpretation is as follows:НvОfЯpsТF psps pspspТXsТFpsНMpНЇО_ТЇП+up Т╦П(НЇО\АТ╚П.Т╛П5НЇОZґТЇТ╦ПNНЇОXxТ≥Т ПBНЇОVDТ─ПLНЇОRhТ╟ПBТ╠НЇОP4Т┐ПUТ└ НЇОMЪТ√ПGТ≈НЇОKкТйТкПCНЇОI√Т╙П%Т╚П<НЇОGbТ╦П%Т╧П6НЇОE-Т╠Т╡ПIНЇОBЫТ═Т║ПDНЇО@еТ┌П9Т┐П+НЇО>░Т─ПAНЇО:ЄТ²П1Т·П3НЇО8─Т║Т╒ПSНЇО6KТ≈Т≤ПPНЇО4ТўПKТ╞НЇО1ЦТ√ Т≈ПUНЇО/ўТыП]НЇО-zТЇ Т╦ПTНЇО+EТ√ПeНЇО)Т▓ПRТ⌠НЇО&эТ┼П8Т▀П,НЇО$╗Т┌Т┐ПPНЇО"sТ▒Т▓ПIНЇО ?Т≤П^Т≥НЇОТП"ТП:НЇОжТ├ПJТ┤НЇО╒Т─П[НЇОфТ÷ПRТ═ НЇО▒Т─П)\MJ?QTаDATABASE ENVIRONMENT AND APPLICATIONS91ButtonInterpretation YellowOpen a new displayer on the entity at the current positionRedSelect the entity or datum value at the current cursor positionBlueExtend a selection made by red to the current positionCtrl-RedDelete the relationship at the cursor positionCtrl-BlueExtends the action of Ctrl-Red over a number of relationshipsShift-RedCopy the entity or datum value at the cursor into the current input focusShift-YellowExpand the selected entity in place (show more information)Shift-BlueExtend selection with Shift-RedOthersCurrently application-definedThe yellow button was dedicated to the "show me" interpretation because this was deemed the mostcommon operation upon a selection, to open up a new window on an entity. The user does notalways want to open a new window, however; this tends to proliferate windows on the screen. TheSquirrel windows and database applications currently follow the following convention for openingnew windows when a user yellow-selects an entity: 1.If the user has yellow-selected an entity in this window before, and the new displayerwindow thus created is still on the screen, we re-use that window, replacing the entity thatused to be displayed in that window with the selected one.2.Otherwise, we create a new entity displayer on the screen for the selected entity, in non-iconic form on the left-hand side of the user's display screen.The interpretation of the mouse buttons was chosen to be as compatible as possible with existinginterpretations in the Cedar Viewers environment. There is in fact some overlap. For example, onecan select an entity by selecting the entire window (or icon, if in iconic form) for its displayer. Itcan then be used by a command, e.g. to add it to a set of entities in another window.All of the operations afforded the user by Squirrel are also available to client programs, through aCedar Mesa interface called "Nut." The Nut interace is also the one through which applicationprograms register themselves with Squirrel, through the Register operation:Register: PROC[ domain: ROPE, display: DisplayProc_ NIL, -- to make displayer for entity in domain edit: EditProc_ NIL, -- to make editor for new or old entity in domain query: QueryProc_ NIL, -- to make queryer on domain create: CreateProc_ NIL, -- to create viewer for above (defaults to container) update: UpdateProc_ NIL, -- to call when database is updatedЪНrОfЯpsТFpsps НG╘pН`О_rН` pТН`О[:Н`П:Н`ОYН`П?Н`ОVяН`П6Н`ОT²Н`П.Н`ОRhН`П=Н`ОP4Н`ПIН`ОMЪН`П;Н`ОKк Н`Н`ОI√Н`НЇОE╩Т┬П0Т┴П0НЇОC├Т╚Т╛ПDНЇОARТ⌠tpТ■П+НЇО?Т╡ПXТЁНЇО<ИТ─П0uН,гuТpН юО9 НЮТЇПHТ╦ НЮО6ыТ└П/tpП'НЮО4єТ─П:Н юО0хНЮТ■Т∙ПMНЮО.■Т─П?НЇО*╦ТґТўПKНЇО(└Т┴ПcНЇО&OТ÷ПJТ═НЇО$Т─ПUНЇО ?Т·ПPТ÷НЇОТ╦П7Т╧П'НЇОжТ─П8up НґОЗuТНґОфНґО▒ПFНґО]ПIНґО)П5НґОТТГТХП0НґО юТП>Ъ ▌Ї y>Q]▓ЭDESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL92 ];7.3 Database applicationsOur first application of the Cypress DBMS was Walnut, a collection of facilities for sending,receiving, filing, and querying electronic messages. Walnut provides four kinds of Cedar Viewersvisible to the user:1.Control window: This viewer window is the one that appears when Walnut is started. Itprovides menu commands to fetch new mail, create a new message form (item 4 below)and create a new "message set" (item 2 below). The control window also reports whennew mail is available, or an error is recognized by the Walnut system.2.Message-set displayer: This window displays a list of messages, their senders, dates, andsubjects. There is a special "Active" message set into which new mail is normallyinserted. The viewer for this message set is automatically put on the screen, along withthe Walnut control window, when Walnut is started. The user may display many messagesets on the screen at the same time. Yellow-selecting one of the messages produces aninstance of item 3 below, a message displayer. A menu of commands at the top allowsremoving messages from the message set and/or adding them to other message sets.3.Message displayer: This window displays a message in the database. The menu ofcommands at the top includes Answer and Forward, that produce an appropriatelyinitialized instance of a message form (item 4 below), and Erase, which deletes themessage itself and removes it from all message sets. The user may yellow-select amessage field to see a database item named there. For example, selecting one of the"Categories" items causes the corresponding message sets to be displayed (whichenumerate messages on that subject or in that message set, which can in turn be selected).Selecting persons in the "To," "From," and "cc" fields causes the person to be displayed(phone number, office number, picture, or whatever the database happens to contain).4.Message editor: This window displays a message form which the user can edit. Some ofthe fields will be initialized according to whether the message editor window was createdby the "Answer," "Forward," or "New Form" commands. 5.Message queryer: This window also displays a message form which the user can edit. Itrepresents all the entities with the values the user specifies in the fields he fills in. Valueranges may be specified. For example, the user might ask for all the messages withsender "Cattell" from last week, containing the string "Cypress" somewhere in theНvОfЯpsТF psps pspspТXsТFpsНMpНґО_uТНЇОV┼rТ─НЇОR╞pТЦПTТДНЇОPzТўП<Т╞П%НЇОNFТ─Н юОJjНЮtТ▓ upПDТ⌠НЮОH6Т²ПCТ·НЮОFТ═Т║П;НЮОCмТ─ПFН юО?ЯНЮtТ·pП1Т÷НЮО=╪ТъП=ТЮНЮО;┬Т÷ПBТ═НЮО9TТ│Т┌П;НЮО7ТіТїП8НЮО4КТ═П9Т║НЮО2ІТ─ПPН юО.зНЮtТсpТтП&НЮО,іТМП@ТН НЮО*rТъП.ТЮП%НЮО(=ТъП9ТЮНЮО& Т╨П2Т╩П"НЮО#тТТП2НЮО!═Т└Т┘ПEНЮОkТ▒П6Т▓П"НЮО7Т─ПTН юО[НЮtТ█pТ▌П1НЮО'Т■ПMТ∙НЮОРТ─П3Н5БТН юОНЮtТ▓pТ⌠П*НЮОБТ▀Т▄ПNНЮОўТеП5ТфНЮО yТРПMТСЪ M 2>Q]ыDATABASE ENVIRONMENT AND APPLICATIONS93message body. When the user invokes the Get query command on the queryer, a newmessage set displayer appears on the screen containing the set of messages which satisfiedthe query. Although the messages in this message set are not actually stored in adatabase message set, the user may select and browse through messages in the windowjust as with any other message set. Walnut uses a special text logging package, for two purposes. The current Cypress implementationdoes not deal efficiently with large string-valued attributes that are frequently created and deleted(the storage allocator is oriented towards objects less than a page in size). The text logging packageallows Walnut to store the bodies of messages in a file, storing a pointer to the text body as arelationship connected to the message entity in the database. The text logging package is also usedto maintain a record of every database-updating operation performed by Walnut, e.g. receiving anew message or adding a message to a message set. The log may be replayed to reconstruct adatabase after a crash, or in the unlikely event that an entire segment is destroyed. The ability toreplay the log makes it unnecessary for Walnut to commit a database transaction after everyoperation. The text logging package used by Walnut is now being rewritten to incorporate it as anextension to the common database software, making it useful to all database applications.Another database application now in preliminary use is Hickory, a Calendar/Clock databaseapplication for recording appointments and reminding the user of them. Hickory implements"event," "event-set," "day," "month," and "year" entity displayers. Hickory makes use of thedatabase system hierarchy of domains to define a number of types of events, such as meetings,seminars, and trips. The user may enter particular events, or sets of events such as periodic events(e.g., a seminar that Hickory will automatically enter every Tuesday). When the client views aparticular day or month he can see the events scheduled for that day or month.A third application, "Whiteboards," has actually been integrated into Squirrel itself, because thefunctionality it provides is useful in conjunction with all applications. The Whiteboard packageprovides a mechanism to lay entities out in a tree-structured, spatial dimension. Consider threeways of moving around in a database by yellow-selection:1.Browsing in the network by selecting adjacent entities, e.g. selecting the sender of amessage to get a displayer on that person, or selecting some day in a month to get adisplayer on that day. This basic browsing functionality is provided by convention inSquirrel and all applications. Let's call this "ground" level browsing (Ground Squirrel).2.Browsing in the network by moving up and down a hierarchy of whiteboards whoseultimate leaf nodes are non-whiteboard entities. This adds a vertical dimension to (1),and is currently provided by the addition of Whiteboards to Squirrel. We might call this"tree" level browsing: although strictly the hierarchy could be a directed acyclic graph,ЪНrОfЯpsТFpsps НG╘pНЮО_Т╔ПJТіНЮО\АТ┼ПZНЮОZґТчП9ТъНЮОXxТ╞ПEТ╟ НЮОVDТ─П#Н'ТНЇОRhТ░ПBТ▒НЇОP4ТєП2Т╔П3НЇОMЪТ┬Т┴ПQНЇОKкТ╦Т╧ПSНЇОI√Т▌П,Т▐П8НЇОGbТ╞Т╟ПHНЇОE-Т╦П>Т╧НЇОBЫТ≥Т ПHНЇО@еТъП.ТЮП-НЇО>░Т▐П@Т░П"НЇО<\Т─ПYНЇО8─ТЫП6ТЗП#НЇО6KТыП*ТзП0НЇО4ТпП7ТяП&НЇО1ЦТҐП0ТЎП-НЇО/ўТ▒Т▓ПXНЇО-zТ©ТюПOНЇО+EТ─ПNНЇО'iТҐПNТЎНЇО%5Т╩П7Т╪П*НЇО#Т╧П[Т╨НЇО лТ─П8Н юОПНЮТтП$ТуП2НЮО╪Т╦П7Т╧НЮО┤Т╩ПHТ╪ НЮОSТ÷Т═П<Н юОwНЮТкП<ТлНЮОCТ╠Т╡ПEНЮОТ▄ПIТ█НЮОзТ╒П-ТёП-ЪTЇ⌠=Г\x#DESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL94it's easier to understand as trees (Tree Squirrel).3.Browsing in the network by moving in a two dimensional continuum rather than thediscrete vertical "chunks" provided by (2), as in Herot [1981]. All the database entitieswould be laid out in a two-dimensional plane, probably automatically according to their"closeness" (= the number or importance of the relationships between them). Zoomingwould be continuous rather than discrete as in (2). Let's call this kind of browsing"flying": unlike climbing in a tree, there are no discrete horizontal or vertical levels(Flying Squirrel).Only the first two kinds of browsing have been implemented, although some experimentation withthe third kind might prove it valuable.In addition to the applications already described, several database applications are underconsideration for future development:1.Whitepages. A database of people, organizations, phone numbers, addresses, and theirphotos. Note there are both public and private versions of whitepages, and the userwould like to see both public and private information superimposed.2.Program database. A database of Cedar Mesa program modules and interfaces, in whichthe user could query the locations of definitions and uses of procedures, types, andvariables. This application would be interfaced with the program editor and compiler toautomatically maintain the consistency of the database.3.Super notebook. A database of one-sentence to one-page ideas, interconnected andindexed in a database of logical dependencies, bibliographic references, project notes, etc.Again, this could be both a private notebook or a shared notebook. 7.4 SummaryWe have described some tools and applications built upon the Cypress DBMS. Applications havebeen in regular use for over a year, and have guided as well as demonstrated the utility of theCypress data model and implementation. In the design of database applications, we have tried toachieve some uniformity so as to present the user with a confederation of information managementfunctions rather than independent programs.The reader may see how the data model has influenced Cypress applications and tools. Theintroduction of entities to the data model enabled the object-based user interface paradigm. TheЪНvОfЯpsТF psps pspspТXsТFpsНMpНЮО_Т─П3Н юО[:НЮТеП@ТфНЮОYТіП+ТїП/НЮОVяТ║П-Т╒П*НЮОT²Т≥ПDТ НЮОRhТмП3ТнП"НЮОP4Тб ТцПOНЮОMЪТ─НЇОJ#Т≤Т≥ПFНЇОGОТ─П'НЇОDТ-П2Т.П(НЇОAъТ─П%Н юО=/НЮt pТЇТ╦ПIНЮО:ШТдП;ТеНЮО8фТ─ПCН юО4НЮtТ⌠pП>Т■НЮО1ЦТьТыП<НЮО/ўТ√Т≈П<НЮО-zТ─П7Н юО(йНЮtТХ pТИП6НЮО&√Т░ПPТ▒НЮО$aТ─ПBН=SrТНЇОТ─ НЇО/pТїПWТ╗НЇОЗТЇП$Т╦П;НЇОфТ÷П.Т═П2НЇО▒Т░ПIТ▒НЇО]Т─П+НЇО │ТуТжПGНЇОMТ╙П\Т╚Ъ M=Г]DATABASE ENVIRONMENT AND APPLICATIONS95information about the types of relationship attributes and their relation keys is used in the defaulteditor to check input and automatically create entities where required. The presence of entitynames and the distinction between entities and relationships greatly simplifies dumping andreloading databases in a linear and human-readable form.НrОfЯpsТFpsps НG╘pНЇО_Т°П:Т²П+НЇО\АТйПGТкНЇОZґТП.ТП-НЇОXxТ─П8~ЇVґ=Г^6DESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL96ЪНvОfЯpsТF psps pspspТXsТFpsНMpЪFM^о1i <%DATABASE ENVIRONMENT AND APPLICATIONS97ЪНrОfЯpsТFpsps НG╘p(Ї^оq <DESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL98ЪНvОfЯpsТF psps pspspТXsТFpsНMpЪFM^о1i <%DATABASE ENVIRONMENT AND APPLICATIONS99ЪНrОfЯpsТFpsps НG╘p(Ї^оq <DESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL100НvОfЯpsТF psps pspspТXsТFpsНMpЪFM^о1i <%DATABASE ENVIRONMENT AND APPLICATIONS101НrОfЯpsТFpsps НFЫp(Ї^оq <1018. Status and conclusions8.1 SummaryThis document has described the Model level of the Cypress Database Management System,including the data model, the background and motivation for choosing that model, the clientinterface to the system, its implementation, and the database environment and applications for whichit was implemented. The guiding principles in the design and implementation have been simplicityand utility for the set of applications we envision.The result is a model that includes features of the relational model and distillations of desirablefeatures of more recent semantic models. The model includes the concept of entities with uniquenames, a hierarchy of types of entities, types and uniqueness constraints on relation attributes,relational views, and a logical segmenting mechanism that can be used to facilitate physicaldistribution and independence of databases. This report discusses a number of issues in theimplementation of these features, which are not present in any existing database system to theauthor's knowledge. The Cypress data model alleviates the problems motivating its development,reducing the quantity of data modelling mechanism built anew for each application, and simplifyingthe sharing of databases between applications. The Cypress model has also enabled the developmentof general-purpose tools formerly impractical due to the lack of type information and integritychecking in the Cedar database system.8.2 Some resultsSome overall statistics on the performance of the initial implementation may be helpful here. Wedeveloped two benchmark programs, one write-intensive and one read-intensive, to examineperformance. Average times for the most common operations are roughly: 1 ms: GetF 1 ms: NameOf 0.5 ms: NextEntity 0.5 ms: NextRelship 5 ms: DomainSubset 7 ms: RelationSubset10 ms: SetF10 ms: ChangeNameThese times are approximately in order of decreasing frequency of calls by the benchmarks, andЪНFЫОfЯpНЇО^оqТНЇОXxr НЇОT²pТСТТПEНЇОRhТФПIТГНЇОP4Т┘Т├ПLНЇОMЪТ⌠Т■ПNНЇОKкТП4НЇОGОТ╩Т╪ПTНЇОE╩Т╔ТіПPНЇОC├ТьТыПFНЇОARТЭПEТЩНЇО?ТГПUТХНЇО<ИТяПZТрНЇО:ЄТ╡ТЁПLНЇО8─Т▐ПVТ░НЇО6KТ│Т┌ПJНЇО4ТсП1ТтП.НЇО1ЦТП&НЇО+▄rНЇО'╟pТ╒ПWТё НЇО%|ТПXНЇО#GТПGНґОk НґО7НґОНґОнНґО НґОeНґО1 НґОЭНЇО Т╦Т╧П>іЇы>Q\2иDESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL102include overhead at all levels of the database and file systems. The times were taken on the XeroxDorado, a personal super-computer with a micro-cycle time of about 60 ns. Note that since most ofthe Cypress operations are disk-limited, the times increase only somewhat for slower processors. Thetimes shown above vary widely with a particular application's data schema and access patterns, sothese numbers should be regarded as very rough averages. Some effects of particular optimizationsand schema changes were enumerated in Section 6. A significant result of our work is that the type checking required by the data model is not a largeoverhead in the Cypress implementation. Because we do not compile database accesses, we mustcheck in the implementation of every operation, e.g. SetF, that the arguments passed are of theproper and coordinated types. On a SetF, for example, we must check that: (1) the arguments are arelationship, attribute, and value, respectively; (2) the attribute is of the same relation as therelationship; (3) the value is of the same type as the attribute; and (4) that a key value constraintwould not be violated by the new value. The caching of information about attributes improves theperformance of the first three of these considerably. Without this caching, the GetF operation takesapproximately 8 times as long.A closer analysis of the time spent in a typical read operation, e.g. GetF, is enlightening. For ourbenchmark programs, the time breakdown was roughly as follows: 10% model level consistency checking and access path selection 20% storage level operation: actual read or update of data 50% waiting for disk operation (cache miss) 20% other overhead (page faults, garbage collection)These figures suggest that work on co-location strategies might be fruitful, since a fair portion of thetime is in disk operations. Note again, however, that statistics can vary widely with the particularapplication.8.3 Status and plansThe first implementation of the Model level was completed in December of 1981, and was exercisedand debugged through 1982. Approximately six man-months went into its development. Thisimplementation includes essentially all data model features except views and augments. Views havebeen deferred to the development of the Query level.Plans for the near future include development of more applications, continuing the work sketched inSection 7.НvОfЯpsТF psps pspspТXsТFpsНMpНЇО_Т⌠ПAТ■П"НЇО\АТ┴П4Т┼П.НЇОZґТ│Т┌ПKНЇОXxТ╚ПBТ╛НЇОVDТ∙П8Т√П*НЇОTТП2НЇОP4Т√Т≈ПEtpНЇОMЪТґТўПFНЇОKкТЎТ©ПSНЇОI√Т─ПaТ│НЇОGbТГП^ТХНЇОE-ТєП6Т╔П/НЇОBЫТ■Т∙ПAНЇО@еТ┼ПeНЇО>░ТНЇО:ЄТ°П#Т²ПBНЇО8─ТП>НґО4єП?НґО2pП<НґО0;П,НґО.П5НЇО*+Т┬Т┴ПSНЇО'ВТ╔П(ТіП=НЇО%бНЇОkrТНЇО░pТ┴Т┼ПHНЇО[ТцПUТдНЇО'Т▓П;Т⌠П'НЇОРТП4НЇОТ┤ПRТ┬НЇОБТ ╪M⌡>QYpРSTATUS AND CONCLUSIONS103AcknowledgementsNori Suzuki and Mark Brown participated in the design and implementation of the original CedarDatabase System. Peter Deutsch and Jerry Popek assisted in the design phase. Eric Bier assisted inthe initial implementation of the Model level, as well as providing a useful sounding board for theseideas. Willie-Sue Haugeland co-implemented Walnut. Jim Donahue developed Hickory. Willie-SueHaugeland, John Maxwell, and Jim Donahue have all helped with the Squirrel system. Mark Brownhas maintained and elaborated the Cypress Storage level and was simultaneously the central designerand implementor of the Alpine file system which Cypress depends on for remote data storage. Samuel Feldman, Dennis McLeod, Jim Donahue, Mark Brown, John Maxwell, Butler Lampson,William Kent, Ken Keller, Dushan Badal, and Peter Deutsch provided useful feedback on drafts ofall or part of this document as it evolved over last year. Kathi Anderson and Subhana Menis helpedprepare this report for publication.ЪН"ОfЯpsТF ps НFЫpНЇО_rНЇО[:pТ═ПXТ║НЇОYТ▀ПSТ▄НЇОVяТ┬ПUТ┴НЇОT²Т─П8Т│П'НЇОRhТ┌П1Т┐П-НЇОP4Т┘Т├ПFНЇОMЪТмПFТнТНЇОJ#ТфТгПFНЇОGОТ■П_НЇОE╩Т─Т│П]НЇОC├ТП$ЇC?>Q$лm1059. Annotated bibliographyAbrial, J. R. Data Semantics, in Klimbie, J. and Koffman, K., Database Management, North-Holland, 1974.Describes a data model based on binary relations. Relations that are N-ary even in functionally irreducible formmust be represented by the introduction of artificial entities to represent relationships. See also Bracchi et al [1976]and Senko [1976] for binary relation models.Armstrong, W. W. Dependency structures of data base relationships, Proceedings IFIP Congress,North-Holland, 1974.This was one of the first studies of functional dependencies and relational normalization after Codd [1970]. LeDoux& Parker [1982] summarize more recent work.Astrahan, M. M., et al. System R: Relational Approach to Database Management, ACMTransactions on Database Systems, 1, 2 (June 1976).This is one of the most widely known and successful implementations of the relational data model. Much of thedesign of the original Cedar DBMS was derived from "RSS level" of this system.Bachman, C. W. The Role Concept in Database Models, Proceedings 3rd International Conferenceon Very Large Databases, Tokyo, October 1977.Concerned with behavioral properites of database objects, the treatment of entities in multiple roles, and integratingdata models with programming languages. "Roles" for entities are actually more powerful than the sub-typehierarchy, although they are somewhat more complex.Beeri, C., Bernstein, P. A., and Goodman, N. A Sophisticate's Introduction to DatabaseNormalization Theory, Proceedings 4th International Conference on Very Large Data Bases, WestBerlin, West Germany, 1978.A discussion of relational normalization.Biller, H. On the notion of Irreducible Relations. Database Architecture, G. Bracchi and G.Nijssen, Eds. North-Holland, 1979.Proposes a semantic definition of the irreducible relational form described in this paper. Contrasts the definitionused in this paper with an earlier definition in terms of loss-less relational joins, showing our definition is morerestrictive.Bjorner, D. Formalization of Data Base Models. TR ID811, DCS, Tech. U. of Demark, Decemeber1978.The relational, hierarchical, and network models are sequentially formally defined. Both the data definition and datamodification/query are considered.НFЫОfЯpНЇО^оqТ─НЇОZ pТиП?rpНЇОW╔Т─ Н ЮОU*sТєПqН ЮОSіТ▐П[Т░Н ЮОQ╦Т─П,НЇОMpТ╚П/Т╛rpНЇОJ█Т─Н ЮОHsТ┼ПYТ▀Н ЮОF$Т─П+НЇОAupТ П6ТrНЇО>ЗТ─П!ptpН ЮО<sТ²ПFТ·П(Н ЮО:▒Т─ПNНЇО5БpТ≈П5rТ≤ НЇО3gТ─pН ЮО0ЛsТ∙ПjТ√Н ЮО/hТоПAТпП)Н ЮО-zТ─П3НЇО(йpТПKТНЇО&√ТЄrП;Т╣pНЇО$Т─Н ЮО!═sП)НЇОpТяП5rpНЇОъТ─П#Н ЮОdsТїПKТ╗П)Н ЮОЮТ╛ПoТґН ЮО\НЇОпpТ┌rП"pТ┐НЇО⌡Н ЮО sТ┤ПbТ┬Н ЮО °Т─П"ПЇ y=Г]▓МDESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL106Bobrow, D., and Goldstein, I. Representing Design Alternatives, Prooceedings of the Conference onArtificial Intelligence and the Simulation of Behavior, Amsterdam (July 1980). Also available as partof Xerox Palo Alto Research Center Report CSL-81-3.A description of the layer concept in the PIE system. Layers are similar in concept to the augments discussed inthis paper. However the basic data primitive is a Smalltalk object rather than relationships and entities, so the resultdoes not provide the power of a database system, e.g. a query language. An implementation of layers was built, andfeedback from that experience and the authors' applications built on it were invaluable in the implementation ofaugments.Bobrow, D. An Overview of KRL, a Knowledge Representation Language, Cognitive Science 1, 1,1977.Describes a knowledge representation language KRL, intended for artificial intelligence applications. Many of theideas in knowledge representation languages, most of which are present in KRL, are now being incorporated indatabase models (see Wong & Mylopoulos [1977]). With an implementation of these ideas such as Cypress, theresult is a system with much of the representational flexibility of knowledge representation languages without thedatabase system features they normally lack: performance, shared access, persistent storage, or large quantities of data.Bracchi, G., Paolini, P., and Pelagatti, G. Binary Logical Associations in Data Modelling,Proceedings IFIP TC-2 Working Conference on Modelling in Databa Base Management Systems,North-Holland, 1976.Another discussion of binary relation models, similar to Abrial et al [1974]. Presents a number of arguments in favorof binary over N-ary relations, although these arguments are in reference to 3rd normal form rather than theirreducible form described in the present paper.Brodie, M. L. Data types and databases, IFSM TR #37, University of Maryland, December 1978.Relates data types and data models. We do not directly include this idea in Cypress, although relational views canbe used to represent operations on object-oriented entity "data types", and the Squirrel interface is also orientedaround the entity types. The paper references Brodie's thesis on data types and other topics.Brodie, M. L., and Zilles, S. N., Eds. Proceedings of Pingree Park Workshop on Data Abstraction,Databases, and Conceptual Modelling, SIGMOD Record 11, 2 (February 1981).A collection of papers relating data modelling from the points of view of programming languages, artificialintelligence, and databases. The same concepts (e.g. hierarchies of types) have independently been studied in thesethree areas. The Pingree Park workshop provided a useful interchange of ideas. Brown, M., Cattell, R., Suzuki, N. The Cedar Database Management System: A PreliminaryReport, Proceedings ACM SIGMOD Conference 1981, Ann Arbor (April 1981).An overview of the Cedar DBMS as it existed prior to the introduction of the Cypress data model, Squirrel tools,and Pilot and Alpine file systems.Buneman, P., Frankel, R. FQL: A Functional Query Language, Proceedings of ACM SIGMODInternational Conference on the Management of Data, Boston, (May) 1979.НvОfЯpsТF psps pspspТXsТFpsНMpНЇО_Т▀Т▄П$rП!НЇО\АТ└Т┘pП0НЇОZґТ─П3Н ЮОX2sТ⌡Т°usПWН ЮОVўТ└Т┘ПeН ЮОU*Т┐П5Т└П>Н ЮОSіТ╚ПWТ╛Н ЮОR"НЇОM∙pТ▓П+Т⌠rpНЇОKaН ЮОHФsТ╔ПJТіП(Н ЮОGbТЁП>ТЄП.Н ЮОEчТ╛П/ТґП<Н ЮОDZТ╚Т╛П`Н ЮОBжТ┌ПHТ┐П1НЇО>JpТТПNНЇО<rТ©ПDТюpНЇО9АТ─Н ЮО7fsТ│ПBТ┌П4Н ЮО5БТаТбПcН ЮО4^Т─П0НЇО/яpТ░Т▒ПOН ЮО-VsТ▓ПsН ЮО+рТґПXТўН ЮО*NТ─П^НЇО%бpТ≈П(rП'Т≤НЇО#▌ТП#pП&Н ЮО!sТъП3ТЮП8Н ЮО▐Т√ПAТ≈П3Н ЮОТ─ПQНЇО~pТшП-ТэП*НЇОJТ─rП&pН ЮОоsТ≥ПLТ П$Н ЮОKТ─П"НЇО©pТ╣ТІrНЇО┼Т─П2pЪйMC=Г[х0BIBLIOGRAPHY107A "functional" data model and query language (see also Shipman[1981]).Cattell, R., Donahue, J., Haugelan, W., Maxwell, J. Integrating Database Applications in a PersonalComputing Environment, submitted to IFIP Conference on High-Performance Personal Computers,(July) 1983. This paper provides a more thorough discussion of the ideas behind integrating the database applications built on topof Cypress, using Squirrel.Chan, A., Danberg, S., Fox, S., Lin, W., Nori, A., Ries, D. Storage and Access Structures tosupport a Semantic Data Model, Proceedings International Conference on Very Large Data Bases.This is the only other implementation effort of which the author is aware under way to implement some of thefeatures of recent semantic data models. The implementation is of an adaptation of DAPLEX to the programminglanguage ADA (see Shipman [1981], Smith et al [1981]). Although the implementation was still under way at thetime of this writing, the design includes a number of the ideas used in our implementation, e.g. clustering of data onthe basis of entities. They do not maintain back-pointers to assist in updating entity references when data is movedor the entity is destroyed, instead using a level of indirection in an "entity directory".Chen, P. The Entity-Relationship Model - Towards a Unified View of Data, ACM Transactions onData Base Systems 1,1 (January 1976).This was the earliest widely-referenced work on extensions to the relational model. It introduced entities and entitytypes (domains), and showed how they could be integrated with relationships, relations, and values.Codd, E. F. A Relational Model of Data for Large Shared Data Banks, CACM 13, 6 (June 1970).This was the earliest widely-referenced work defining the relational model. It introduced relationships, relations(relationship types), values, and value types.Codd, E. F. Extending the Database Relational Model to Capture More Meaning, ACMTransactions on Data Base Systems 4,4 (December 1979).Codd assembles several proposed extensions to the relational model. The biggest contribution of this paper is inrecognizing that the operations on data are at least as important a component of the data model as the structuraldata definition, a fact most of the literature has ignored. Codd suggests such operations.Demers, A., Donahue, J., and Skinner, G. Data Types as Values: Polymorphism, Type-checking,Encapsulation, Conference Record 5th ACM Symposium on Principles of Programming Languages,1978.Propose some more powerful mechanisms for types in programming languages. Russel, the authors' language,supports these mechanisms (but is not yet implemented).Fagin, R. Multivalued dependencies and a new normal form for relational databases. ACMTransactions on Database Systems 2, 3, 1977.Fagin, R. A Normal Form for Relational Databases that is based on Domains and Keys. ACMTransactions on Database Systems 6, 3, 1981.Н%ґОfЯps НFЫpН ЮО_9sТ─ПFНЇОZґpТ└П4Т┘П0НЇОXxТ║Т╒rП6pНЇОVDТ─Н(pТН ЮОSиsТ│П1Т┌ПDН ЮОREТ─НЇОM╧pТгП(ТхП5НЇОK└Т─rП=pН ЮОI sТ╗Т╘П\Н ЮОG┘Т■ Т∙ПbН ЮОFТ²Т·ПUН ЮОD}Т┌П+Т┐ПKН ЮОBЫТ▀П=Т▄П8Н ЮОAuТ─ПZНЇО=╪pТ▀П!Т▄П)rНЇО;┬Т─ptpН ЮО9 sТ▐П,Т░ПJН ЮО7┴Т─ПcНЇО3пpТ▓П1Т⌠rptpН ЮО1UsТ╧Т╨П^Н ЮО/яТ─П.НЇО,pТ П?ТrНЇО)ДТ─П!ptpН ЮО'isТ╔П*ТіПGН ЮО%ЕТ÷П'Т═ПJН ЮО$aТ─П[НЇО ╘pТ╗Т╘ПDНЇОtТ╟rТ╠П6НЇО@pН ЮОеsТиПRТйН ЮОAТ─П7НЇО┬pТв ТьПKrНЇОTТ─П!tp НЇОxpТ╔ТіП:rНЇОDТ─П!tp xЇЩ=Г\"DESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL108The above two papers by Fagin describe two normal forms for databases, the second more restrictive than the first,and the first more restrictive than Codd's [1970].Feldman, J., & Rovner, P. An Algol-based Associative Language, CACM 12, 8 (August) 1969.The LEAP language described here has many of the properties of more recent data models, and some interestinglanguage-integrated ideas about access to the data (looping constructs and user-defined procedures for matchingtuples). LEAP uses binary relations.Hall, P., Oulett, J., & Todd, S. Relations and Entities, Proceedings of the IFIP TC-2 WorkingConference on Modelling in Data Base Management Systems, 1976.An earlier discussion of entities and the irreducible relations which Biller [1979] further formalizes.Hammer, M. & McLeod, D. The Semantic Data Model: A Modelling Mechanism for Data BaseApplications, ACM Transactions on Database Systems 6, 3 (September) 1981.A more recent summary of the SDM data model described in McLeod's PhD disseration [1978].Herot, C. The Spatial Data Management System. Proceedings International Conference on VeryLarge Data Bases, Rio de Janeiro, 1981.Describes a novel user interface to a database system allowing browsing in a spatial layout of entities.Israel, J., Mitchell, J., Sturgis, H. Separating Data from Function in a Distributed File System,Technical Report CSL-78-5, Xerox Palo Alto Research Center, 1978.Describes Juniper, the transaction-based file system on which the Cedar DBMS was constructed.Kapp, D., & Leben, J. IMS Programming Techniques, Van Nostrand, 1978.Describes IBM's IMS, the most widely used commercial database system, and it's access language DL/I. IMS uses aform of hierarchical data model, and comes in a number of versions (IMS/VS, IMS360) with somewhat differentfeatures.Katz, R. and Wong, E. Heterogenous Data Models - Part 1: Semantic Issues, ERL memoUCB/ERL m79/56, UC Berkeley, 1979.Discusses issues in providing an integrated database system composing database system components based on differentdata models. This is a hard and generally unsolved problem.Kent, W. Data and Reality, North-Holland, 1978.This book has an excellent thorough discussion of philosophical and epistemological aspects of entities, entity types,relations, and issues only briefly mentioned in most recent data model literature. There are little or no new ideashere, the purpose is to revisit questions inadequately studied elsewhere, e.g. "What is an entity?".Kent, W. Limitations of Record-based Information Models, ACM Transactions on DatabaseSystems, 4,1 (March 1979).A good summary of limitations of the relational model, and some of the advantages of more recent data models.НvОfЯpsТF psps pspspТXsТFpsНMpН ЮО_9sТ░Т▒ПUН ЮО]╣Т─П2НЇОYЭpП@rptpН ЮОW│sТ╒ТёПQН ЮОUЩТцusП$ТдП%Н ЮОTyТ─П%НЇОPаpТЎП:r Т©НЇОN▄Т─П7pН ЮОLsПgНЇОHYpПUНЇОF$p rП$prpН ЮОC╘sПYНЇО?ЯpТюТаrП,НЇО=╪Т─pН ЮО;AsПhНЇО7┴pТ╦П;Т╧П'НЇО5UТ─ПAН ЮО2зsП]НЇО/!prpН ЮО,іsТ├ПNТ┤П"Н ЮО+"ТїusП'Т╗П<Н ЮО)·НЇО%ЕpТКП#ТЛП0НЇО#╠Т─П"Н ЮО!6sТ│ПsН ЮО╡Т─П<НЇОЫp rpН ЮО~sТ√П[Т≈Н ЮОЗТ≥П;Т П9Н ЮОvТ─ПdНЇОЎpТРП:rТСНЇО┴pТ─rpН ЮО КsПm пM є=ГZgBIBLIOGRAPHY109Kent, W. Choices in Practical Data Desgin, Proceedings 8th International Conference on Very LargeDatabases, Mexico City, (September) 1982.Discusses some important unsolved issues in data modelling and schema design. One issue is whether an entityname composed of multiple parts or a relation with multiple attributes should be collapsed into a singlename/attribute or kept separate (examples are month/day/year, or city/state/country). Another issue is is whether toencode information as type or as data (for example, whether to include sex as a property of persons, or to declaredifferent subtypes of Person for men and women). Other issues are "nameless" entities and uniqueness of entitynames when there are several subtypes of a domain.Kent, W. The Entity Join, Proceedings 5th International Conference on Very Large Databases, 1979.Discusses the distinction between entities and their names.Kerschberg, L., Klug, A., Tsichritzis, D. A Taxonomy of Data Models, Systems for Large DataBases, P. Lockemann & F. Neuhold (eds), North-Holland, 1976.This paper is a brief survey of 23 data models along some global dimensions: graph-theoretic versus set-theoretic,mathematical foundation, terminology, and level of abstraction.King, R., McLeod, D. Semantic Database Models, Database Design, S. B. Yao, Ed., 1982.A recent survey of data models (see also Lochovsky & Tsichritzis [1982]).LeDoux, C., and Parker, D. Reflections on Boyce-Codd Normal Form. Proceedings 8thInternational Conference on Very Large Data Bases, Mexico City, 1982.A recent study of relational normalization.Lindgreen, P. Basic operations on information as a basis for data base design, Proceedings IFIPCongress, North Holland, 1974.A binary-relation data model.McLeod, D. A Semantic Database Model and its Associated Structured User Interface, PhD Thesis,EE & CS, MIT, 1978.Describes the SDM data model, including most of the ideas in the Cypress data model and some other ones, such asthe introduction of events.Mitchell, J., Maybury, W., Sweet, R. Mesa Language Manual. Xerox Palo Alto Research CenterReport CSL-79-3, 1979Describes Mesa 5.0, the language in which the Cedar database system was originally implemented. No reference isexternally available at the time of this writing for Cedar Mesa, the language in which the Cypress database system isimplemented. The Cedar Mesa language of course strongly influenced the design of the programmer's interface tothe Cypress data model.Mylopoulos, J., Bernstein, P., and Wong, H. A Preliminary Specification of TAXIS: A Languagefor Designing Information Systems, TR CCA-78-02 (January 1978).Integrates a number of the concepts discussed in recent data models, including generalization hierarchies andspecialization.ЪН%ґОfЯps НFЫpНЇО_Т┌Т┐П#rП6НЇО\АpТ─Н ЮОZfsТ╛ ТґП_Н ЮОXБТНП;ТОП-Н ЮОW^Т┘П)Т├ПLН ЮОUзТ∙П%Т√ПMН ЮОTVТєП$Т╔ПKН ЮОR╞Т─П2НЇОNсpТ┐Т└rП@pН ЮОLXsТ─П;НЇОH÷pТЄТ╣П-rНЇОFkpТ─П6Н ЮОCПsТєП9Т╔П9Н ЮОBlТ─П?НЇО>ЁpП0rpН ЮО<8sПIНЇО8─pТП*ТrНЇО6KТ─П1pН ЮО3пsП+НЇО0pТґПBТў rНЇО-ДpТ─Н ЮО+isНЇО'╟pТ┐П-Т└П2НЇО%|Т─Н ЮО#sТ┌П@Т┐П0Н ЮО!}Т─usНЇОдpТ═П3Т║П)НЇО░Т─Н ЮОsТ⌠Т■ПYН ЮО▒Т├П4Т┤ПAН ЮОТ≥ПNТ П!Н ЮО┬Т─НЇОпpТёТєПNНЇО⌡Т─П?Н ЮО sТуПiТжН ЮО ° лЇ y=Г]▓DESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL110Pirotte, A. "The Entity-Property-Association Model: An Information-Oriented Data Base Model",MBLE Report R343, (March) 1977.Another early data model.Quillian, M. R. Semantic Memory, in M. Minsky, (ed.), Semantic Information Processing, MITPress, 1968.This is the earliest widely-referenced work with semantic nets, which have been used widely in Artificial Intelligence.Semantic nets, as they are generally used, allow entities and relationships but lacked some capabilities the relationalmodel allows (e.g. queries on relations).Redell, D, et al. Pilot: An Operating System for a Personal Computer, Proceedings 7th Symposiumon Operating Systems Principles, Asilomar, (ACM order #534790) 1979.Describes the Pilot operating system, on which the Cedar programming environment and Cedar DBMS depend. ThePilot file system provides a local transaction-based access to data for the Cedar DBMS (Juniper, described by Israelet al [1979], provides a remote transaction-based file system).Rissanen, J. Independent Components of Relations, ACM TODS 2, 4 (December) 1977.A study of what Biller [1979] calls a-irreducible relational form, which is less restrictive than the irreducible form weuse.Roussopoulos, N., and Mylopoulos, J. Using Semantic Networks for Database Management,Proceedings 2nd International Conference on Very Large Databases, September 1975.Discusses a data model based on semantic networks (Quillian [1968]).Sadri, F., Ullman, J. The Interaction between Functional Dependencies and TemplateDependencies. Proceedings ACM SIGMOD Conference 1980, Santa Monica.Describes more complex kinds of dependencies and relational normal forms.Schmidt, H. A., & Swenson, J. R. On the Semantics of the Relational Data Model, in King, F.(ed.), Proceedings ACM SIGMOD Conference, San Jose, 1975.An early paper discussing shortcomings of the relational model.Senko, M. E. Data Structures and Data Accessing in Data Base Systems Past, Present, Future, IBMSystems Journal 16, 3 (1977a).A binary-relation data model with separate physical, conceptual, and user levels.Shipman, D. W. The Functional Data Model and the Data Language DAPLEX, ACM Transactionson Database Systems 6, 1 (March) 1981.Describes a data model, the functional data model, which is superficially quite different but actually very similar tothe Cypress model. The Functional data model takes an attractively simple point of view, decomposing relationshipsinto functions mapping values to values. Thus all the notation and terminology of mathematical functional notationis available for use. The "properties" described in this paper have some similarities to this idea, but Shipman makesthis the basis for the model.НvОfЯpsТF psps pspspТXsТFpsНMpНЇО_ТёПLТєНЇО\АТ─Н ЮОZfsНЇОVўpТ╪ТҐrpНЇОTyТ─Н ЮОQЧsТ┴ПiТ┼ Н ЮОPzТ∙ПlТ√ Н ЮОNЖТ─П)НЇОK>pТ▐П3Т░rНЇОI Т─pП%Н ЮОF▌sТ└ПTТ┘Н ЮОE Т▓ПCТ⌠П1Н ЮОC├Т─П?НЇО?нpП3rpН ЮО=SsТ┬ Т┴ПoН ЮО;оНЇО8pТМТНПAНЇО5БrТ─ПApН ЮО3CsПDНЇО/hpТEТFП9НЇО-3Т─rП(pН ЮО*∙sПIНЇО&╧pТ╚П2Т╛П*НЇО$┘Т─rП"pН ЮО!ФsП?НЇОpТ├П=Т┤П#НЇОжТ─Н ЮО8sПQНЇО\pТ┌ Т┐П=rНЇО(Т─tprН ЮОґsТ⌠П+Т■ПKН ЮО)Т┬ Т┴ПhН ЮО ╔Т▓usП(Т⌠П=Н ЮО Т└П'Т┘ПOН ЮО yТ─Ъ фM 2=Г]ыBIBLIOGRAPHY111Shoshani, A. CABLE: A Language Based on the Entity-Relationship Model, Lawrence BerkeleyLab, Berkeley, California, 1978.CABLE is a query language for Chen's Entity-Relationship model, based on chains of relationships between entities.For example, one might ask for all the people that are managers of departments that produce parts that are sold toCompany X. Because the chains seem very natural for expression of queries, we are considering a similar kind oflanguage for use in Cypress.Smith, J.M., and Smith, D.C. Data Base Abstractions: Aggregation and Generalization, ACMTransactions on Database Systems 2, 2 (June) 1977a.A discussion of the idea of hierarchies of types.Smith, J.M., and Smith, D.C. Integrated Specifications for Abstract Systems, TR UUCS-77-112,Computer Science, University of Utah, September 1977b.Concerned with combining structural and behavioral specifications.Smith, J., Fox, S., Landers, T. Reference Manual for ADAPLEX, Technical Report, ComputerCorporation of America, January 1981.Describes ADAPLEX, embedding the DAPLEX (Shipman[1981]) language in the Ada programming language.Stonebraker, M., et al. The Design and Implementation of INGRES, ACM Transaction onDatabase Systems 2, 3 (September 1976).INGRES is one of the two most widely known implementations of the relational data model (the other is System R,Astrahan et al [1976]).Stonebraker, M. Hypothetical Databases as Views, ACM Proceedings ACM SIGMOD 81, AnnArbor (April 1981).Further work on INGRES referenced above has suggested ways to define integrity constraints and hypotheticaldatabases through the use of views, although there may be problems with doing this as an "add-on". Hypotheticaldatabases are described in this reference.Sundgren, B. Conceptual foundation of the infological approach to data bases, Data BaseManagement, J. Klimbie and K Koffeman, Eds, North Holland, 1974.Early paper describing the infological data model, which has not been fleshed out to the degree of most of the othermodels discussed. The basic primitives are objects (entities) and their properties.Tsichritzis, D.C. LSL - A link and selector language, Proceedings ACM SIGMOD 76, 1976.A query language for a network model database.Tsichritzis, D., and Klug, A. (Eds). The ANSI/X3/SPARC DBMS Framework. Report of theStudy Group on Database Management Systems. Information Systems 3, 4 (1978).A comprehensive data model in the Entity-Relationship family.ЪН%ґОfЯps НFЫpНЇО_ТєТ╔ПCНЇО\АТ─Н ЮОZfsТ▐Т░ПbН ЮОXБТ█П?Т▌П3Н ЮОW^Т√Т≈ПRН ЮОUЇТ─НЇОQшpТвПEТьrНЇОOїТ─pН ЮОMsП1НЇОI-pТ╦Т╧ПQНЇОFЬТ─П6Н ЮОDZsПBНЇО@~pТЎПPТ©НЇО>JТ─П%Н ЮО;оsПaНЇО8pТНТОП/rНЇО5БТ─tpН ЮО3gsТ├П*Т┤ПEН ЮО1©Т─НЇО-ДpТхП2rТиpНЇО+╞Т─Н ЮО)4sТаПDТбП'Н ЮО'╟Т▓П2Т⌠П>Н ЮО& Т─П*НЇО"-pТПMТrНЇОЬ pТ─П5Н ЮО}sТ└u sТ┘ПNН ЮОжТ─psПAНЇОЗpП7rpН ЮО\sП.НЇО─pТЎПHТ© НЇОLТ─П-rp Н ЮОўsП= °Їg=Г[єЖDESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL112Tsichritzis, D., and Lochovsky, F. Data Models, Prentice-Hall, 1982.This book is probably the most extensive and up-to-date discussion of data models currently available. It deals withconceptual models rather than physical models and complete systems, since many of the models described have notbeen implemented. The book covers the relational, network, hierarchical, entity-relationship, binary, semanticnetwork, and infological data models.Wiederhold, G. Database Design, McGraw-Hill, New York, 1977.A good description of database systems from the point of view of implementation and physical access structures asopposed to the conceptual data model.Wiederhold, G., El-Masri, R. The Structural Model for Database Design, Proceedings of theInternational Conference on the Entity-Relationship Approach to Systems Analysis and Design, LosAngeles, (December) 1979.Describes the "structural" data model, further described in El-Masri's PhD dissertation. The structural modelclassifies relations according to their semantic use, much as in Codd's [1980] extensions of the relational model.Wong, H., and Mylopoulos, J. Two Views of Data Semantics: A Survey of Data Models inArtificial Intelligence and Database Management. INFOR 15, 3 (October 1977).Contrasts knowledge representation languages and data models.Zloof, M. M. Query by Example: The Invocation and Definition of Tables and Forms.Proceedings First International Conference on Very Large Data Bases, 1975.The first widely-referenced work on querying databases by filling out forms, an idea used in Squirrel queryerwindows.ЪНvОfЯpsТF psps pspspТXsТFpsНMpНЇО_Т─П$r pН ЮО\⌡sТ┴ПfТ┼Н ЮО[Т■П&Т∙ПIН ЮОY⌠ТчП&ТъПIН ЮОWКТ─П%НЇОTprpН ЮОQ■sТ≤П\Т≥Н ЮОOМТ─П%НЇОLpТРТСП.rНЇОIщТ╚П?Т╛pНЇОG╗Т─Н ЮОE-sТнПnН ЮОC├Т─ПrНЇО?╙pТжПRТвНЇО=vТ─П2rpН ЮО:ьsП=НЇО6ЭpТТП3НЇО4гrТ─ПCpН ЮО2LsТцП9ТдП4Н ЮО0╔xM0^>Г7ґў11310. Appendix: Axioms and formal definitionsThe definition of a database includes a set of domains D (the domain domain), a set of relations R(the relation domain), a set of attributes A (the attribute domain), and a set of datatypes T (thedatatype domain). We also define a subdomain function sd mapping D to D. The function sd mustdefine a partial ordering of D.We define the fundamental type constraint for a database:The Attribute Type Constraint. (a) Every relationship in a relation R must have the samenumber of elements. We assign identifiers for corresponding elements of the relationshipsbelonging to R, the attributes a1, a2, a3, ... aN. (b) For any of these attributes ai, the valueassociated with ai for every relationship in R must be an element of the same datatype ordomain di, or of a domain si in the transitive closure of sd applied to di.Because every relationship in a relation R has the same attributes, we may unambiguously refer tothese as simply R's attributes. Every relationship in R has a value of the same type associated withan attribute A, so we define a function at mapping A to the union of D and T, and call at(A) A'stype. Relation keysEach data schema includes a uniqueness function au mapping A to the set {none, keypart}. If arelation R has M attributes, of which some subset a1, a2, ... aN (where N < M) have au(ai) =keypart, then no more than one relationship in R is permitted to have the same value associatedwith attributes a1, a2, ... aN..NormalizationFor a relation R of order N, denote the predicate whose truth in the represented world correspondsto the presence of a relationship in the relation by Rp[a1, a2, ... aN]. The arguments ai correspond tothe attributes of R. We then define:A relation R is in irreducible form iff it cannot be split into relations R1, R2, ... Rk such thatfor all possible states of the represented world:Rp[x1, x2, ... xN] <-> R1p[xi1, ... xik] & ... & Rkp[xj1, ... xjl]where{xi1, ... xik} I {x1, x2, ... xN} ...{xj1, ... xjl} I {x1, x2, ... xN} ЪНFЫОfЯpНЇО^оqТ─П,НЇО[гpТ■П.Т∙rpП)rНЇОY⌠pТЇТ╦rpП0rpНЇОW^Т├П7rprprprpНЇОTЦТ─rpНЇОQ■pП9Н─ОNFsТмpП(sp ТнН─ОLТяП<ТрН─ОIщТ╟spsОIPtОIщsОIPtОIщsОIPtОIщsОIPtОIщspТ╠sОIPtОIщp Н─ОGлТфsОG?tОGлpspП(ТгН─ОEtТ─sОDГtОEtpsОDГuОEtprpsОDГuОEtpНЇОBpТ÷Т═spП7НЇО?нТ▓Т⌠spspП-НЇО=≥Т⌡sprprprprp rpspspНЇО;spНШsТpНЇО6ЭsТ─НЇО3ТpТ╙Т╚rprpП"НЇО1©ТаП2sО12tО1©sО12tО1©sО12tО1©pТбrpО12uО1©pНЇО/ўТ╟Т╠ПEНЇО-zТ─sО,МtО-zsО,МtО-zsО,МtО-zpНЇО){sНЇО&spТ▌Т▐ПRНЇО$>Т└П(Т┘ О$кuО$>pО#╠uО$>pО#╠uО$>pО#╠uО$>pО#╠uО$>p НЇО"-Т─П%НґОчpТ├s pП-ОQuОчpОQuОчpОQuОчpТ┤ НґОмТ─П1НёО~pОuО~pОЯuО~pТОЯuО~pОЯuО~prpОЯuОО~pОЯuО~pОЯuО~pvpvpОЯuОО~pОЯuО~pОЯuО~pНёОSН≥ОKОЎuОKpОЎuОKpvpОЎuОKpОЎuОKpОЎuОKpН≥ОfН≥О ^ОяuО ^pОяuО ^pvpОяuО ^pОяuО ^pОяuО ^pЬЇў>Q[]ЩDESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL114A relation is in functionally irreducible form iff (1) it is in irreducible form or (2) it is the naturalrelational join on a key attribute of two or more binary relations, and there is a dependency betweenthe other (non-joined) attributes a1, a2, ... aN such that the semantics of attribute ai is dependentupon the value of ai+1, for i = 1, 2, .. N-1.AxiomsBelow are the beginnings of an equational specification of the DB interface developed by JimDonahue of the Computer Science Lab. Currently missing are complete descriptions of the schemaoperations (DeclareDomain, DeclareRelation, DeclareAttribute, . . .), some of the detailed descriptionof the behavior of operations on erroneous arguments (the type-checking of RelationSubset, forinstance), and any discussion of segments, transactions and initialization. A complete description willappear in a forthcoming paper.In this style of specification, we present the semantics of the operations in terms of behaviorallyequivalent programs composed of sequences of Cypress operations. Since the only way you caninterrogate entities is through DomainSubset, the only important property of DeclareEntity is that itmay affect the value of a later invocation of DomainSubset. The equations specify this by statingthat certain sequences of Cedar statements are equivalent.In the following, we will use the abbreviation(s1; . . .; sn) THEN e1 ~ e2where s1, ..., sn are Cedar statements and e1 and e2 are Cedar expressions to mean that{ s1; ...; sn; RETURN[e1] } ~ { s1; ...; sn; RETURN[e2] }(Quite often in what follows, the equivalences will be between Cedar procedure bodies; if Cedarwere an expression language then the equivalences would be somewhat simpler to state.)Basic Operations on EntitiesThe fundamental property of entities is that no two entities with the same name and same domaincan exist (this is not true for relationships). The operations that manipulate entities include:DeclareEntity -- add (or look up) an entity in a particular domainDestroyEntity -- remove an entity from a domainNameOf -- give the name of an entityЪНvОfЯpuТF pupu pupupТXuТFpuНMpНЇО_Т╔spspТіП3НЇО\АТ┐П8Т└П-НЇОZґТ╟П#ОZ uОZґpОZ uОZґpОZ uОZґpТ╠ОZ uОZґpНЇОX°Т─ОXuОX°pНЇОTЦsНЇОQpТтПUТуНЇОNсТ▒П7Т▓П(НЇОL·Т┌ПfНЇОJjТкТлП>НЇОH6Т┌П;Т┐П-НЇОFТ─НЇОB%pТ╦Т╧ПVНЇО?ЯТ╨П\НЇО=╪Т░П1Т▒П4НЇО;┬ТёПbНЇО9TТ─П:НЇО4єpП.НШО/УpО/huО/УpТ О/huО/УpО/huО/УpvpО/huНЇО+ipТ─О*эuО+ipО*эuО+ipО*эuО+ipО*эuО+ipП#НШО&эpТО&OuО&эpО&OuО&эp О&OuО&эpvpО&OuО&эpО&OuО&эp О&OuО&эpНЇО ТЄТ╣ПKНЇОГТ─ПVНЇОвsНЇОоpТ°ПSТ²НЇО⌡Т─ПaНШОfТПBНШО2П/НШОЩП$rMІ>Q\U5APPENDIX115DomainOf -- give the domain of an entityEq -- compare two entitiesNull -- has an entity been destroyed?DomainSubset -- produce the subset of a domain with names in a given rangeNextEntity -- sequence through an entity setReleaseEntitySet -- free the storage used by entity set (affects performance only)DeclareEntityDeclareEntityThe basic operation on entities is DeclareEntity, which either creates a new entity in a particulardomain or returns a previously existing one. Its semantics is given in the following equations:1. Declare produces an entity with the right name and domain:(e: Entity = DeclareEntity[d, name, NewOnly]) THEN [ DomainOf[e], NameOf[e] ] ~ [ d, name ]2. NewOrOld is only a convenience:DeclareEntity[d, name, NewOrOld] ~{ e: Entity = DeclareEntity[d, name, OldOnly]; IF e = NIL THEN RETURN[DeclareEntity[d, name, NewOnly]] ELSE RETURN[e] }3. Declare OldOnly is the same as domain subset:DeclareEntity[d, name, OldOnly] ~ { es: EntitySet = DomainSubset[d, name]; e: Entity = NextEntity[es]; ReleaseEntitySet[es]; RETURN[e] }4. Declare NewOnly fails if the entity already exists:IF DeclareEntity[d, name, OldOnly] # NIL THEN DeclareEntity[d, name, NewOnly] ~IF DeclareEntity[d, name, OldOnly] # NIL THEN SIGNAL Error[AlreadyExists]5. Declare doesn't work on system domains:DeclareEntity[DomainDomain, name] ~ SIGNAL Error[ImplicitSchemaUpdate]DeclareEntity[RelationDomain, name] ~ SIGNAL Error[ImplicitSchemaUpdate]DeclareEntity[AttributeDomain, name] ~ SIGNAL Error[ImplicitSchemaUpdate]DeclareEntity[DataTypeDomain, name] ~ SIGNAL Error[ImplicitSchemaUpdate]DeclareEntity[IndexDomain, name] ~ SIGNAL Error[ImplicitSchemaUpdate]DeclareEntity[IndexFactorDomain, name] ~ SIGNAL Error[ImplicitSchemaUpdate]6. DeclareEntity doesn't work for NIL or null arguments:DeclareEntity[NIL, name] ~ SIGNAL Error[NILArgument]IF Null[d] THEN DeclareEntity[d, name] ~IF Null[d] THEN SIGNAL Error[NullifiedArgument]DestroyEntityDeclare may put something in the database; Destroy removes it.1. An entity that is destroyed will not be found:( d: Domain = DomainOf[e]; name: ROPE = NameOf[e]; DestroyEntity[e] ) THENЪН'ОfЯpuНFЫpНШО_ТП(НШО\АНШОZґП%НШОXxТППJНШОVDТП,НШОTТГТХП6НШОQшНЇОMЪsНЇОJВpТЁП"ТЄПAНЇОHцТ─П`Н `ОF$П=Н`ОDZТП2Н`ОB▐vpН `О?ЯТ─П"Н`О>&ТП!vН`О<\pП.Н`О:▒ТоПHТпН `О7СТ─П0Н`О6(ТvН`О4^pП)Н`О2⌠П@Н `О/УТ─П6Н`О.*ТшП>ТэvН`О,_pТПIН `О)аТ─П*Н`О'ВТП"vpП#Н`О&,П$vpП#Н`О$aП%vpП#Н`О"≈П$vpП#Н`О лП!vpП#Н`ОП'vpП#Н `ОcТ─П8Н`О≥ТvpН`ОнП'vН`ОpП/НЇО(sНЇО pТ─П>Н `О │ТП1Н`ОЇПJVЇp>Q\⌡ОDESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL116DeclareEntity[d, name, OldOnly] ~ NIL2. All relships that reference an entity are destroyed when the entity is destroyed:(SetF[rship, attr, e]; DestroyEntity[e]) THEN Null[rship] ~ TRUE3. Once destroyed, an entity becomes Null:(DestroyEntity[e]) THEN Null[e] ~ TRUE(DestroyEntity[e1]) THEN Eq[e1, e2] ~ Null[e2]4. Destroy doesn't work on NIL or null arguments (can't destroy the same entity twice):DestroyEntity[NIL] ~ SIGNAL Error[NILArgument]IF Null[e] THEN DestroyEntity[e] ~IF Null[e] THEN SIGNAL Error[NullifiedArgument]DomainSubsetDomainSubset returns an EntitySet that, if cycled through using NextEntity, contains all of theentities in the domain having names in the specified range, and only those entities.1. DomainSubset finds only those entities having names between low and high:( es: EntitySet = DomainSubset[d, low, high]; e: Entity = DeclareEntity[d, name, NewOnly] ) THENDomainSubset[d, low, high] ~IF name < low OR name > high THEN es ELSE DomainSubset[d, low, high]2. DomainSubset finds all those entities having names between low and high:( e: Entity = DeclareEntity[d, name, NewOnly] ) THENname >= low AND name <= high ~{ es: EntitySet = DomainSubset[d, low, high]; FOR next: Entity _ NextEntity[es], NextEntity[es] UNTIL next = NIL DO IF Eq[next, e] THEN {ReleaseEntitySet[es]; RETURN[TRUE]} ENDLOOP; ReleaseEntitySet[es]; RETURN[FALSE] }Equality of entitiesTwo entities are equal iff they are both null or their names are the same and they are in the samedomain.Eq[e1, e2] ~{ IF Null[e1] OR Null[e2] THEN RETURN[ Null[e1] AND Null[e2] ]; RETURN[ Rope.Equal[NameOf[e1], NameOf[e2]] AND Eq[DomainOf[e1], DomainOf[e2]]] }Basic Operations on RelationshipsRelationships are tuples; the basic operations on relationships include setting and fetching the valuesof fields and searching the database for all tuples whose fields have values in specified ranges. Theoperations that manipulate relationships include:НvОfЯpuТF pupu pupupТXuТFpuНMpН`О_ТvpН `О\wТ─ПTН`ОZґТП:vpН `ОXТ─П*Н`ОVDТvpН`ОTyП$vpН `ОQшТ─ПWН`ОPТvpН`ОNFП!vН`ОL{pП/НЇОH÷sНЇОDдpТлП9ТмП&НЇОB▐Т─ПTН `О?ЯПLН`О>&ТП-Н`О<\П4Н`О:▒vН`О8фpПDН `О6(Т─ПKН`О4^ТП4Н`О2⌠vН`О0хpП-Н`О.ЧПGН`О-3П<Н`О+i Н`О)·П'НЇО%бsТ─НЇО!ФpТ≤П@Т≥П"НЇО╡НШО@Т vНШОupП?НШО╚П0НШОЮП$НЇОsТ─П!НЇОЭpТ┴П\Т┼ НЇО хТ░П@Т▒П&НЇО⌠Т─П1ЪьML>Q\©МAPPENDIX117DeclareRelship -- add (or look up) a relationship in a particular relationDestroyRelship -- remove a relationship from a relationRelationOf -- give the relation of a relationshipEq -- compare two relationshipsNull -- has a relationship been destroyed?RelationSubset -- produce the subset of a relation with fields in a given range of valuesNextRelship -- sequence through a relationship setReleaseEntitySet -- free storage used by a relationship set (affects performance only)Unlike entities, it is possible to have the several tuples in the database with the same set of fieldvalues. (One can protect against this by declaring some of the attributes for a relation to be keys.Then checking is performed when declaring new relationships or setting the fields of existingrelationships to guarantee that no other tuple exists with the same value for a key attribute. Theequations given below ignore this additional complexity.) Allowing multiple tuples with the samevalues appears in the lack of an equation of the form "DeclareRelship followed by DeclareRelshipwith the same arguments and version OldOnly fails."DeclareRelshipMost of these equations closely parallel the specification of DeclareEntity.1. Declare produces a relationship with the proper values for each specified field:( init: AttributeValueList = LIST[ [a1, v1], ..., [an, vn] ]; rs: Entity = DeclareRelship[r, init] ) THEN GetF[ rs, ai ] ~ vi2. Declare NewOrOld is a convenience:DeclareRelship[r, list, NewOrOld] ~{ rs: DeclareRelship[r, list, OldOnly]; IF rs = NIL THEN RETURN[DeclareRelship[r, list, NewOnly]] ELSE RETURN[rs] }3. Again, Declare OldOnly is the same as the subset operation this time, though, itmay fail because of a multiple match:DeclareRelship[r, list, OldOnly] ~{ rset: RelshipSet = RelationSubset[r, list]; rs: Relship = NextRelship[rs]; IF NextRelship[rset] = NIL THEN { ReleaseRelshipSet[rs]; RETURN[rs] } ELSE { ReleaseRelshipSet[rset]; SIGNAL Error[MultipleMatch] } }4. Declare doesn't work on system domains:DeclareRelship[aRelation, list] ~ SIGNAL Error[ImplicitSchemaUpdate]DeclareRelship[aType, list] ~ SIGNAL Error[ImplicitSchemaUpdate]DeclareRelship[aUniqueness, list] ~ SIGNAL Error[ImplicitSchemaUpdate]DeclareRelship[aLength, list] ~ SIGNAL Error[ImplicitSchemaUpdate]DeclareRelship[aLink, list] ~ SIGNAL Error[ImplicitSchemaUpdate]DeclareRelship[dSubType, list] ~ SIGNAL Error[ImplicitSchemaUpdate]Н'ОfЯpuНFЫpНШО_ТПJНШО\АП7НШОZґП1НШОXxНШОVDП*НШОTТ┌ПAТ┐НШОQшТП2НШОOїТ╞Т╟П6НЇОL·Т╚ПXТ╛НЇОJjТїТ╗ПDНЇОH6ТЦТДП>НЇОFТ╘ПcНЇОCмТ╙ПSТ╚ НЇОA≤Т·Т÷ПCНЇО?dТ─П3НЇО;┬s НЇО8─pПLН `О5БpПSН`О4pТП=Н`О2LП=vpН `О/ўТ─П%Н`О-ДpТП"vН`О,pП'Н`О*NТпТяПLН `О'╟ТЗТШН8аО'YЧЖО(=О'╟Н`О%ЕТ─П%Н`О$pТП!vН`О"PpП-Н`О ├Н`О╩ПHН`ОППBН `ОRТ─П*Н`О┤pТvpП#Н`ОҐvpП#Н`ОРП"vpП#Н`О(vpП#Н`О]vpП#Н`О▓vpП# xЇK?QXюЬDESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL1185. DeclareEntity doesn't work for NIL or null arguments:DeclareRelship[NIL, list] ~ SIGNAL Error[NILArgument]IF Null[r] THEN DeclareRelship[r, list] ~IF Null[r] THEN SIGNAL Error[NullifiedArgument]DestroyEntityBecause duplicates are allowed, the effect of Destroy is somewhat different. Declaring a relshipNewOnly and destroying it has no effect if the relation is in the schema (note that the initializationof the fields of the relship is described below as applications of SetF).1. Destroying a newly created relationship has no effect:{ rs: Relship = DeclareRelship[r, [], NewOnly]; DestroyRelship[rs] } ~[] _ DeclareRelation[ NameOf[r], SegmentOf[r], OldOnly ]2. If an existing relationship is destroyed, then it will not be found:( rs: Relship = DeclareRelship[r, list, OldOnly]; DestroyRelship[rs] ) THENDeclareRelship[r, list, OldOnly] ~ NIL3. Once destroyed, an relationship becomes Null:(DestroyRelship[rs]) THEN Null[rs] ~ TRUE(DestroyRelship[rs1]) THEN Eq[rs1, rs2] ~ Null[rs2]4. Destroy doesn't work on NIL or null arguments (can't destroy the same entity twice):DestroyRelship[NIL] ~ SIGNAL Error[NILArgument]IF Null[rs] THEN DestroyRelship[rs] ~IF Null[rs] THEN SIGNAL Error[NullifiedArgument]RelationSubsetRelationSubset returns a RelshipSet that, if cycled through using NextRelship, contains all of therelationships in the relation having field values in the specified ranges.1. RelationSubset finds only relships satisfying the AttributeValueList:( init: AttributeValueList = LIST[ [a1, v1], . . ., [an, vn] ] search: AttributeValueList = LIST[ [a1, l1, h1], . . ., [an, ln, hn] ]; rset: RelshipSet = RelationSubset[ r, search ]; [] _ DeclareRelship[r, init, NewOnly ] ) THEN RelationSubset[ r, search ] ~ IF v1 < l1 OR v1 > h1 OR . . . vm < lm OR vm > hm THEN rset ELSE RelationSubset[ r, search ]2. And RelationSubset finds all relships satisfying the AttributeValueList:( init: AttributeValueList = LIST[ [a1, v1], . . ., [an, vn] ] search: AttributeValueList = LIST[ [a1, l1, h1], . . ., [an, ln, hn] ]; rs: DeclareRelship[r, init, NewOnly]; rset: RelshipSet = RelationSubset[ r, search ] ) THEN v1 >= l1 AND v1 <= h1 AND . . . vm >= lm AND vm <= hm ~ { FOR next: Relship _ NextRelship[rs], NextRelship[rs] UNTIL next = NIL DO IF Eq[ next, rs ] THEN { ReleaseRelshipSet[rs]; RETURN[TRUE] } ENDLOOP; ReleaseRelshipSet[rs]; RETURN[FALSE] }ЪНvОfЯpuТF pupu pupupТXuТFpuНMpН `О_Т─П8Н`О]KpТvpН`О[─П(vН`ОYІpП/НЇОVўsНЇОSіpТҐПAТЎНЇОQqТ⌠П=Т■П)НЇОO=Т─ПIН `ОL·pП9Н`ОJтpТПEvН`ОI pП8Н `ОFkТ─ПGН`ОD═pТПKН`ОBжП!vpН `О@7Т─П0Н`О>mpТП#vpН`О<╒П(vp Н `О:Т─ПWН`О89ТvpН`О6oП$vН`О4єpП0НЇО1°s НЇО.■pТЄПbНЇО,_Т─ПJН `О)аПHН`О'ВТП>Н`О&,ПIН`О$aП1Н`О"≈П/Н`О лvН`ОpП3Н`О7П,Н `О≥Т─ПKН`ОнТП>Н`ОПIН`О9П'Н`ОnП7Н`ОєП8vН`ОыpТУП)ТЖП$Н`ОТПBН`ОDН`О yП) ■M 2>Q]ыAPPENDIX119SetF and GetFSetF changes the fields of a tuple, GetF reads them. Here are also the axioms that describe thetype-checking performed on assignment.1. Setting the field of one relship changes its value for all equal relships (Eq for relships isessentially alias):{ SetF[rship1, attr, val]; RETURN[ GetF[rship2, attr] ] } ~{ oldVal: Value = GetF[rship2, attr]; SetF[rship1, attr, val]; RETURN[ IF Eq[rship1, rship2 ] THEN val ELSE oldVal ] }2. Setting a field with its current value is a no-op (except for errors):SetF[ rship, attr, GetF[rship, attr] ] ~{ IF Eq[RelationOf[rship], aRelation] THEN SIGNAL Error[ImplicitSchemaUpdate]; IF Eq[RelationOf[rship], aType] THEN SIGNAL Error[ImplicitSchemaUpdate]; IF Eq[RelationOf[rship], aLength] THEN SIGNAL Error[ImplicitSchemaUpdate]; IF Eq[RelationOf[rship], aUniqueness] THEN SIGNAL Error[ImplicitSchemaUpdate]; IF Eq[RelationOf[rship], aLink] THEN SIGNAL Error[ImplicitSchemaUpdate]; IF Eq[RelationOf[rship], ifIndex] THEN SIGNAL Error[ImplicitSchemaUpdate]; IF Eq[RelationOf[rship], ifAttribute] THEN SIGNAL Error[ImplicitSchemaUpdate]; [] _ GetF[rship, attr] }3. Declare NewOnly can be defined in terms of setting the fields one at a time:DeclareRelship[ r, LIST[ [a1, v1], . . ., [an, vn] ], NewOnly ] ~{ rship: Relship = DeclareRelship[ r, [], NewOnly ]; SetF[ rship, a1, v1 ]; . . .; SetF[ rship, an, vn ]; RETURN[rship] }4. GetF fails if the attribute belongs to the wrong relation:[] _ GetF[rship, attr] ~{ IF rship = NIL OR attr = NIL THEN SIGNAL Error[NILArgument]; IF Null[rship] OR Null[attr] THEN SIGNAL Error[NullifiedArgument]; { rel1: Relation = RelationOf[rship]; rel2: Relation = V2E[ GetP[ e: attr, aIs: aRelationIs, aOf: aRelationOf ] ]; IF NOT Eq[rel1, rel2] THEN SIGNAL Error[ IllegalAttribute ] } }The type-checking that goes on when a SetF is performed is fairly straightforward: If the value tobe assigned is from one of the primitive types, then the type of the attribute (found in the aTyperelation) must be identical. In the case of assigning entity values, the domain of the value must be asubtype of the domain that is the type of the attribute. We define this by a set of similar equationsfor each of the primitive types and one for the entity-valued case.5. Integer type-checking:{ rship: Relship = DeclareRelship[r, [], NewOnly]; SetF[ rship, attr, I2V[integer] ]; DestroyRelship[rship] } ~{ [] _ GetF[rship, attr]; { type: Entity = V2E[ GetP[ e: attr, aIs: aTypeIs, aOf: aTypeOf ] ]; IF NOT Eq[type, IntType] THEN SIGNAL Error[MismatchedAttributeValueType] }}ЪН'ОfЯpuНFЫpНЇО_sТ─НЇО\pТґП`НЇОYыТ─П&Н `ОW;ТиП+ТйП5Н`ОUpТ─Н`ОSіТП:vН`ОQшpП%Н`ОPН`ОNFП:Н `ОK╗Т─ПIН`ОIщТП'vН`ОHpПNН`ОFHПJН`ОD}ПLН`ОB╡ПPН`О@ХПJН`О?ПLН`О=SПPН`О;┬Н `О8ЙТ─ПOН`О7ТП@vН`О5UpП4Н`О3┼ПGН `О0ЛТ─П=Н`О/!ТvН`О-VpП>Н`О+▄ПDН`О)аП'Н`О'ВПQН`О&,ПDНЇО#$Т≤ПZТ≥НЇО ОТёПNТєНЇО╩Т┐П6Т└П1НЇО┤Т┼П!Т▀ПEНЇОRТ─ПCН `ОЄН`ОИТП2Н`ОП>vН`ОTpН`О┴ПFН`О©ТаП)ТбП' Їx>QY⌠ГDESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL1206. Boolean type-checking:{ rship: Relship = DeclareRelship[r, [], NewOnly]; SetF[ rship, attr, B2V[boolean] ]; DestroyRelship[rship] } ~{ [] _ GetF[rship, attr]; { type: Entity = V2E[ GetP[ e: attr, aIs: aTypeIs, aOf: aTypeOf ] ]; IF NOT Eq[type, BoolType] THEN SIGNAL Error[MismatchedAttributeValueType] }} 7. String type-checking:{ rship: Relship = DeclareRelship[r, [], NewOnly]; SetF[ rship, attr, S2V[string] ]; DestroyRelship[rship] } ~{ [] _ GetF[rship, attr]; { type: Entity = V2E[ GetP[ e: attr, aIs: aTypeIs, aOf: aTypeOf ] ]; IF NOT Eq[type, StringType] THEN SIGNAL Error[MismatchedAttributeValueType] }} 8. Time type-checking:{ rship: Relship = DeclareRelship[r, [], NewOnly]; SetF[ rship, attr, T2V[time] ]; DestroyRelship[rship] } ~{ [] _ GetF[rship, attr]; { type: Entity = V2E[ GetP[ e: attr, aIs: aTypeIs, aOf: aTypeOf ] ]; IF NOT Eq[type, TimeType] THEN SIGNAL Error[MismatchedAttributeValueType] }}9. Entity type-checking (AnyDomainType is a wild card):{ rship: Relship = DeclareRelship[r, [], NewOnly]; SetF[ rship, attr, E2V[entity] ]; DestroyRelship[rship] } ~{ [] _ GetF[rship, attr]; { type: Entity = V2E[ GetP[ e: attr, aIs: aTypeIs, aOf: aTypeOf ] ]; IF NOT (Eq[type, AnyDomainType] OR SubType[DomainOf[entity], type]) THEN SIGNAL Error[MismatchedAttributeValueType] }}RelationOfRelationOf simply gives the relation of a relationship. RelationOf[ DeclareRelship[ r, list ], NewOrOld ] ~ { [] _ DeclareRelship[ r, list, NewOrOld ]; RETURN[r] }Operations on the database schemaThe database schema is stored in a set of system domains and relations. The operations on theseobjects include:DeclareDomain -- add (or look up) a domainDeclareRelation -- add (or look up) a relationDeclareAttribute -- add (or look up) a field name of a relationDestroyDomain -- destroy a domain (and all of its entities)DestroyRelation -- destroy a relation (and all of its relationships)DeclareSubType -- define one domain to be a subtype of anotherDestroySubType -- remove the two domains from the dSubType relationНvОfЯpuТF pupu pupupТXuТFpuНMpН `О_Т─Н`О]KТП2Н`О[─П>vН`ОYІpН`ОWКПGН`ОV!Т╚П*Т╛П'Н `ОS┌Т─Н`ОQ╦ТП2Н`ОOМП=vН`ОN#pН`ОLXПGН`ОJ█Т≥Т ПPН `ОGОТ─Н`ОF$ТП2Н`ОDZП;vН`ОB▐pН`О@еПGН`О>ЗТёТєПOН `О<\Т─П7Н`О:▒ТП2Н`О8фП=vН`О6ЭpН`О51ПGН`О3gПHН`О1°П7НЇО.■s НЇО+▄pТ─П7НЇО)ТП6vНЇО'ipП;НЇО#▌sТ─П!НЇО ├pТ╔ТіПCНЇОQТ─НШОТП*НШОХП.НШОЄП?НШОП;НШОKПDНШОП>НШОБПCЪTM⌡>QYpХAPPENDIX121These operations behave much like DeclareEntity, DeclareRelship, DestroyEntity andDestroyRelship; it's just that they work on the system domains and relations.DeclareDomain/DestroyDomain1. DeclareDomain adds a new (empty) domain:( d: Domain = DeclareDomain[ name, segment, NewOnly ] ) THEN{ es: EntitySet = DomainSubset[d, NIL]; e: Entity = NextEntity[es]; ReleaseEntitySet[es]; RETURN[s] } ~ NIL2. Again, NewOrOld is a convenience:DeclareDomain[name, segment, NewOrOld] ~{ d: Domain = DeclareDomain[name, segment, OldOnly]; IF d = NIL THEN RETURN[DeclareDomain[name, segment, NewOnly]] ELSE RETURN[d] }3. Declare OldOnly is the same as domain subset on DomainDomain:DeclareDomain[name, segment, OldOnly] ~{ es: EntitySet = DomainSubset[d: DomainDomain, lowName: name, searchSegment: segment]; e: Entity = NextEntity[es]; ReleaseEntitySet[es]; RETURN[e] }4. Declare NewOnly fails if the entity already exists:([] _ DeclareDomain[name, segment, NewOrOld]) THENDeclareDomain[name, segment, NewOnly] ~ SIGNAL Error[AlreadyExists]5. Declare NewOnly changes DomainDomain:(d: Domain = DeclareDomain[name, segment, NewOnly]) THENDeclareDomain[name, segment, OldOnly] ~ d6. A domain that is destroyed will not be found:(name: ROPE = NameOf[d]; seg: Segment = SegmentOf[d]; DestroyDomain[d]) THENDeclareDomain[name, segment, OldOnly] ~ NIL7. Destroying a domain causes all of the entities in the domain to be destroyed:( es: EntitySet = DomainSubset[d, NIL]; DestroyDomain[d] ) THEN{ e: Entity = NextEntity[es]; ReleaseEntitySet[es]; RETURN[e] } ~ NIL8. Destroying a domain causes entities to become Null:( e: Entity = DeclareEntity[d, name]; DestroyDomain[d] ) THENNull[e] ~ TRUE9. Destroying a domain causes relationships that reference it to be destroyed:( SetF[rship, attr, e]; DestroyDomain[d] ) THEN Null[rship] ~ TRUE10. Destroy doesn't work on NIL or null arguments (can't destroy the domain twice):DestroyDomain[NIL] ~ SIGNAL Error[NILArgument]IF Null[d] THEN DestroyDomain[d] ~IF Null[d] THEN SIGNAL Error[NullifiedArgument]Н'ОfЯpuНFЫpНЇО_ТІП0ТЇП"НЇО\АТ─ПMНЇОYsН `ОVgpП+Н`ОT²ТП<Н`ОRрП'Н`ОQН`ОO=П%vpН `ОL·Т─П$Н`ОJтТП'vН`ОI pП4Н`ОG?П?Н`ОEtН `ОBжТ─П@Н`ОAТП&vН`О?ApП/Н`О=vП.Н`О;╚П@Н `О9 Т─П6Н`О7BТП2Н`О5xП&vpН `О2зТ─П(Н`О1ТП8Н`О/DП&vpН `О,іТ─П0Н`О*шТФ ТГПAН`О)ТП&vpН `О&sТ─ПPН`О$╗ТП?Н`О"щП@vpН `О ?Т─П6Н`ОtТП=Н`О╙vpН `ОТ─ПNН`ОAТПQXХDESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL122DeclareRelation/DestroyRelation1. DeclareRelation adds a new (empty) relation:( r: Relation = DeclareRelation[ name, segment, NewOnly ] ) THEN{ rs: RelshipSet = RelationSubset[r, NIL]; rship: Relation = NextRelship[rs]; ReleaseRelshipSet[rs]; RETURN[rship] } ~ NIL2. Again, NewOrOld is a convenience:DeclareRelation[name, segment, NewOrOld] ~{ r: Relation = DeclareRelation[name, segment, OldOnly]; IF r = NIL THEN RETURN[DeclareRelation[name, segment, NewOnly]] ELSE RETURN[r] }3. Declare OldOnly is the same as domain subset on RelationDomain:DeclareRelation[name, segment, OldOnly] ~{ es: EntitySet = DomainSubset[d: RelationDomain, lowName: name, searchSegment: segment]; e: Entity = NextEntity[es]; ReleaseEntitySet[es]; RETURN[e] }4. Declare NewOnly fails if the entity already exists:([] _ DeclareRelation[name, segment, NewOrOld]) THENDeclareRelation[name, segment, NewOnly] ~ SIGNAL Error[AlreadyExists]5. Declare NewOnly changes RelationDomain:(r: Relation = DeclareRelation[name, segment, NewOnly]) THENDeclareRelation[name, segment, OldOnly] ~ r6. A relation that is destroyed will not be found:(name: ROPE = NameOf[r]; seg: Segment = SegmentOf[r]; DestroyDomain[r]) THENDeclareRelation[name, segment, OldOnly] ~ NIL7. Destroying a domain causes all of the relships in the domain to be destroyed:( rs: RelshipSet = RelationSubset[r, NIL]; DestroyRelation[r] ) THEN{ rship: Relation = NextRelship[rs]; ReleaseRelshipSet[rs]; RETURN[rship] } ~ NIL8. Destroying a domain causes relships to become Null:( rship: Relation = DeclareRelship[r, [], NewOnly]; DestroyRelation[r] ) THEN Null[rship] ~ TRUE9. Destroy doesn't work on NIL or null arguments (can't destroy the relation twice):DestroyRelation[NIL] ~ SIGNAL Error[NILArgument]IF Null[r] THEN DestroyRelation[r] ~ IF Null[r] THEN SIGNAL Error[NullifiedArgument]DeclareAttributeThe important properties of DeclareAttribute are the changes made to the system relations aType,aLength, aUniqueness and aLink when a new attribute is declared. If a type, length, uniqueness orlink is specified when the attribute is looked up (Declare with version OldOnly), then theseadditional arguments are checked for consistency with the values stored in the relations. Note thatthere is no corresponding DestroyAttribute.ЪНvОfЯpuТF pupu pupupТXuТFpuНMpНЇО_sН `О\wpТ─П/Н`ОZґТП@Н`ОXБПMН`ОWП*vpН `ОTyТ─П$Н`ОR╞ТП)vН`ОPДpП8Н`ОOПAН`ОMOН `ОJ╠Т─ПBН`ОHФТП(vН`ОGpП1Н`ОEQП)Н`ОC├П?Н `О@ХТ─П6Н`О?ТП4Н`О=SП(vpН `О:ЄТ─П*Н`О8ЙТП<Н`О7П(vpН `О4│Т─П2Н`О2ІТЭ ТЩПAН`О0ЛТП(vpН `О.MТ─ПPН`О,┐ТПDН`О*╦ПLvpН `О(Т─П6Н`О&OТПMН`О$┘ vpН `О!ФТ─ПTН`О ТvpН`ОQТ≥П#vpТ НЇОusНЇОmpТ╗ПAТ╘НЇО9Т▒ПLТ▓НЇОТМП?ТННЇОпТ≥Т ПLНЇО⌡Т─П+Ъ *MT>QYЇAPPENDIX1231. DeclareAttribute adds a new attribute:( a: Attribute = DeclareAttribute[r, name, type, uniqueness, length, link, NewOnly] )THEN DeclareAttribute[r: r, name: name, version: OldOnly] ~ a2. DeclareAttribute changes the aType relation:( a: Attribute = DeclareAttribute[r, name, type, uniqueness, length, link, NewOnly] ) THENV2E[ GetP[ e: a, aIs: aTypeIs, aOf: aTypeOf ] ] ~ type3. DeclareAttribute changes the aUniqueness relation:( a: Attribute = DeclareAttribute[r, name, type, uniqueness, length, link, NewOnly] )THEN V2I[ GetP[ e: a, aIs: aUniquenessIs, aOf: aUniquenessOf ] ] ~ LOOPHOLE[uniqueness]4. DeclareAttribute changes the aLength relation:( a: Attribute = DeclareAttribute[r, name, type, uniqueness, length, link, NewOnly] )THEN V2I[ GetP[ e: a, aIs: aLengthIs, aOf: aLengthOf ] ] ~ length5. DeclareAttribute changes the aLink relation:( a: Attribute = DeclareAttribute[r, name, type, uniqueness, length, link, NewOnly] )THEN V2B[ GetP[ e: a, aIs: aLinkIs, aOf: aLinkOf ] ] ~ link6. Again, NewOrOld is a convenience:DeclareAttribute[r, name, type, uniqueness, length, link, NewOrOld] ~{ a: Attribute = DeclareAttribute[r, name, type, uniqueness, length, link, OldOnly]; IF a = NIL THEN RETURN[DeclareAttribute[r, name, type, uniqueness, length, link, NewOnly]] ELSE RETURN[a] }7. Declare OldOnly is the same as domain subset on AttributeDomain:DeclareAttribute[r: r, name: name, version: OldOnly] ~{ es: EntitySet = DomainSubset[d: AttributeDomain, lowName: name, searchSegment: SegmentOf[r]]; e: Entity = NextEntity[es]; ReleaseEntitySet[es]; RETURN[e] }8. Declare OldOnly checks any supplied type, length, link, uniqueness:( a: Attribute = DeclareAttribute[r, name, type, uniqueness, length, link, NewOnly] )THEN DeclareAttribute[r: r, name: name, type: type', version: OldOnly] ~IF NOT Eq[type', type] THEN SIGNAL Error[MismatchedExistingAttribute]ELSE DeclareAttribute[r: r, name: name, version: OldOnly]( a: Attribute = DeclareAttribute[r, name, type, uniqueness, length, link, NewOnly] )THEN DeclareAttribute[r: r, name: name, uniqueness: uniqueness', version: OldOnly]~ IF NOT uniqueness = uniqueness' THEN SIGNAL Error[MismatchedExistingAttribute] ELSE DeclareAttribute[r: r, name: name, version: OldOnly]( a: Attribute = DeclareAttribute[r, name, type, uniqueness, length, link, NewOnly] )THEN DeclareAttribute[r: r, name: name, length: length', version: OldOnly] ~IF NOT length = length' THEN SIGNAL Error[MismatchedExistingAttribute]ELSE DeclareAttribute[r: r, name: name, version: OldOnly]( a: Attribute = DeclareAttribute[r, name, type, uniqueness, length, link, NewOnly] )ЪН'ОfЯpuНFЫpН `О_Т─П)Н`О]KТПUН`О[─П:vpН `ОXБТ─П/Н`ОWТ·П*Т÷П0Н`ОUMТП0vpН `ОR╞Т─П5Н`ОPДТПUН`ОOПAvН`ОMOpН `ОJ╠Т─П1Н`ОHФТПUН`ОGП9vpН `ОD}Т─П/Н`ОB╡ТПUН`О@ХП5vpН `О>JТ─П$Н`О<ТПDvН`О:ЄpПTН`О8ЙН`О7ПQН`О5UН `О2ІТ─ПCН`О0ЛТП5vН`О/!pП2Н`О-VП/Н`О+▄П@Н `О(НТ─ПFН`О'#ТПUН`О%XПGvН`О#▌pПEН`О!цП9Н`О.ПUН`ОcПRН`О≥vpП%Н`ОнП+Н`ОП;Н`ОnПUН`ОєПKvН`ОыpПFН`ОП9Н`О yПU < ` 2:*]ыГDESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL124THEN DeclareAttribute[r: r, name: name, link: link', version: OldOnly] ~IF NOT link = link' THEN SIGNAL Error[MismatchedExistingAttribute]ELSE DeclareAttribute[r: r, name: name, version: OldOnly]9. Declare NewOnly fails if the entity already exists:([] _ DeclareAttribute[r, name, type, uniqueness, length, link, NewOrOld]) THENDeclareAttribute[r, name, type, uniqueness, length, link, NewOnly] ~SIGNAL Error[AlreadyExists]10. Declare doesn't work on NIL or null arguments:DeclareAttribute[NIL, name, type, uniqueness, length, link] ~SIGNAL Error[NILArgument]IF Null[r] THEN DeclareAttribute[r, name, type, uniqueness, length, link] ~IF Null[r] THEN SIGNAL Error[NILArgument]ЪНvОfЯpuТF pupu pupupТXuТFpuНMpН`О_ТПGvН`О]KpПBН`О[─П9Н `ОXБТ─П6Н`ОWТПOН`ОUMПCvН`ОS┌pН `ОPДТ─П2Н`ОOТП░П%Н"6О>9Ч ┼Н/юО>░ТНЇО<ИТ─П(Н#ЙО<▓ЧжН/юО<ИТНЇО;AТ─П.Н&ЮО:ЙЧЮН/юО;AНЇО9 Н.О9CЧ▓Н/юО9 ТНЇО7СТ─П%Н!GО7°ЧyН/юО7СТНЇО6KТ─П:Н-зО5ТЧФН/юО6KТНЇО4єТ─П,Н%└О4MЧ <Н/юО4єТНЇО2ЩТ─НbО2іЧ^Н/юО2ЩТНЇО1UТ─НО0ЧЧ╚Н/юО1UТНЇО/ўТ─Н╛О/WЧН/юО/ўТНЇО.Т─П/Н&╙О-╟Ч Н/юО.Т НЇО,_Т─П/Н)╪О,ЧН/юО,_Т НЇО*╦Т─П+Н#qО*aЧOН/юО*╦НЇО)НfО(╨ЧZН/юО)ТНЇО'iТ─НrО'ЧNН/юО'iТНЇО%бТ─П1Н(ШО%kЧеН/юО%бТ НЇО$Т─П3Н+pО#дЧPН/юО$ТНЇО"sТ─П-Н( О"ЧІН/юО"sТНЇО лТ─П7Н+XО uЧhН/юО лНЇО%НОнЧ╒Н/юО%НЇО}П#Н О&Ч╛Н/юО}ТНЇОжТ─П"Н зОЧФН/юОжНЇО/П8Н+ОьЧ╒Н/юО/ТНЇО┤Т─П'Н$ЩО0Ч цН/юО┤ТНЇОЮТ─П,Н&О┴Ч ╔Н/юОЮНЇО9П)Н%vОБЧ JН/юО9НЇО▒Н÷О:Ч!Н/юО▒ТНЇОЙТ─П%Н!О⌠Ч╟Н/юОЙТЪ▓ЇТ/≤[дЪ HELVETICAЪ HELVETICA Ъ HELVETICAЪ HELVETICAЪMATH Ъ HELVETICA Ъ TIMESROMAN ЪLOGOЪ TIMESROMAN Ъ TIMESROMANЪ TIMESROMAN Ъ TIMESROMANЪ TIMESROMAN Ъ TIMESROMAN Ъ TIMESROMANЪ HELVETICA Ъ HELVETICA Ъ TIMESROMANЪ HELVETICA Ъ HELVETICAЪ TIMESROMAN Ъ TIMESROMANЪ TIMESROMAN Ъ HELVETICA Ъ TIMESROMAN Ъ TIMESROMANЪ HELVETICA Ъ HELVETICAЪGACHA Ъ TIMESROMANЪ TIMESROMAN Ъ TIMESROMANЪ TIMESROMANЪ TIMESROMAN Ъ TIMESROMAN Ъ HELVETICA Ъ TIMESROMAN Ъ TIMESROMANЪ TIMESROMAN Ъ TIMESROMANЪ TIMESROMAN Ъ HELVETICA Ъ TIMESROMAN Ъ TIMESROMANЪ TIMESROMAN Ъ TIMESROMANЪ TIMESROMAN Ъ TIMESROMANЪ TIMESROMAN Ъ TIMESROMANЪ TIMESROMAN Ъ TIMESROMAN Ъ TIMESROMANЪ TIMESROMANЪMATH JТ nЧ!<&- o7ёG&БmЛtП{С┌2VЄЮ╪fдhщЦйЙ бСОШмР Їш e%$*ї1Ы9ЕAФI!OСWе_ДgФoИvм}З└ V█T▒Щ≤у═Тїў╣╪бзйЯрPв;NI(P 'Е/С7щ?ЕGОOЩW п` БiРq эz ы┐Й▀Е⌠P≤*·ЮірўПІ ы©вгмо╠вГъБГуО╪ВсЪ7' бЖ Й$*А2 щ;ЫBйDшFГHшJГLшNГP7U[⌠_e пnчvЭ~П├Й▌ ■R≥÷кі╛╠ЇЩЎекяШьъ÷Б<Иж╪╨жj/ПМЪЪ РjЛЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪModelLevelDesign.pressCattell18-May-83 10:05:48 PDT: