\\ \\\u \‘_-l- m n p. /.’
`\m 6“: ‘II/
`(“1/ I!” _
`
`mess
`
`THE COMPUTER SOCIETY
`~THE COMPUTER SOCIETY
`OF THE IEEE
`~OF THE IEEE
`
`soc-um
`
`“\WQMCmm M
`
`+ THE INSTITUTE OF ELECTRICAL
`
`THE msm'urzos ELECTRICAL
`m mo ELECTRONICS emnussns. mc.
`•••• AND ELECTRONICS ENGINEERS, INC.
`
`

`

`The papers in this book comprise the proceedings of the meeting mentioned on the cover and title
`page. They reflect the authors' opinions and are published as presented and without change, in the
`interests of timely dissemination. Their inclusion in this publication does not necessarily constitute
`endorsement by the editors, Computer Society Press of the IEEE, or The Institute of Electrical and
`Electronics Engineers, Inc.
`
`'?J.y/&~
`OVGR_
`QP-
`7 . cr
`03
`1 7'1-
`
`Published by Computer Society Press of the IEEE
`1730 Massachusetts Avenue, N.W.
`Washington, D.C. 20036-1903
`
`Cover designed by Jack I. Ballestero
`
`Copyright and Reprint Permissions: Abstracting is permitted with credit to the source. Libraries are
`permitted to photocopy beyond the limits of U.S. copyright law for private use of patrons those articles
`in this volume that carry a code at the bottom of the first page, provided the per-copy fee indicated in
`the code is paid through the Copyright Clearance Center, 29 Congress Street, Salem, MA 01970.
`Instructors are permitted to photocopy isolated articles for noncommercial classroom use without fee.
`For other copying, reprint or republication permission, write to Director, Publishing Services, IEEE, 345
`E. 47th St., New York, NY 10017. All rights reserved. Copyright © 1988 by The Institute of Electrical
`and Electronics Engineers, Inc.
`
`Computer Society Order Number 827
`Library of Congress Number 87-83477
`IEEE Catalog Number 88CH2550-2
`ISBN 0-8186-0827-7 (paper)
`ISBN 0-8186-4827-9 (microfiche)
`ISBN 0-8186-8827-0 (case)
`SAN 264-620X
`
`Order from: Computer Society of the IEEE
`Terminal Annex
`Post Office Box 4699
`Los Angeles, CA 90080
`
`IEEE Service Center
`445 Hoes Lane
`P.O. Box 1331
`Piscataway, NJ 08855-1331
`
`Computer Society of the IEEE
`Avenue de Ia Tanche, 2
`B-1160 Brussels
`BELGIUM
`
`THE INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS, INC.
`
`•
`11!1!1!
`
`ii
`
`

`

`EDICf- An Enhanced Relational Data Dictionary:
`Architecture and Example
`
`James P. Davis, Senior Knowledge Engineer
`
`NCR Corporation
`General Purpose Systems Division
`3325 Platt Springs Road
`West Columbia, S.C. 29169
`
`Ronald D. Bonnell, Director
`
`Center for Machine Intelligence
`University of South Carolina
`Columbia, S.C. 29208
`
`ABSTRACT
`
`An integrated data dictionary for a rela(cid:173)
`tional DBMS provides a centraliZed mana~e­
`ment environment for maintaining informatiOn
`about the data in the database relations. How(cid:173)
`ever, current relational data dictionaries do not
`provide adequate facilities for the capture and
`representation of high-level semantic information
`about the enterprise whose data is stored in the
`tables of the database. This paper describes an
`approach for enhancing an integrated relational
`data dictionary in order to capture and faithfully
`present this high-level enterprise schema in a
`form which can be incorporated directly into the
`relational database system. The approach,
`referred to as EDICT, allows for the specifica(cid:173)
`tion of the enterprise schema for a database as
`an extension of the data dictionary by storing the
`schema as a set of normalized tables. In addi(cid:173)
`tion, it facilitates more effective use of existing
`data dictionaries by providing an extended
`meta-schema which describes the structure and
`use of the dictionary itself.
`
`1. lNTRODUCflON
`It has been more than fifteen years since the rela(cid:173)
`tional model was first introduced [CODD70], and in that
`time, many commercial DBMS products built around this
`model have become powerful tools for defining and
`managing data of interest to an organization or enterprise.
`Most, if not all, commercial products provide facilities for
`data acquisition (via forms), data management (via data
`dictionary) and data reporting (via reports).
`
`The data dictionary is arguably the most important
`facility of a DBMS in that it provides the capability of
`managing and maintaining the consistency and inte~rity of
`the data stored in the DBMS, as it is used and modified by
`a number of users simultaneously. For a given DBMS, a
`data dictionary generally provides data about both the logi(cid:173)
`callevel as well as the physical level.
`However, the data dictionaries of most commercial
`products are somewhat lacking in terms of the scope and
`the ~e of data that is made available for use in managing
`the mformation stored. First, many of the semantic con(cid:173)
`straints which are captured in the enterprise domain
`model are lost in the conversion to the DBMS schema
`tables. Second, most data provided by the data dictionary
`is useful for the system to manage the current state of the
`database, but is not much help in assisting the user in
`managing the underlying data model, or schema, as its
`evolves over time. Thus, the user or administrator must
`
`CH2550·2/88/0000/0184$01.00 © 1988 IEEE
`
`184
`
`this examination of an
`
`2.
`
`handle all schema mana~ement outside of the DBMS
`environment and then mcorporate changes manually.
`Third, for existing databases, the facilities for querying the
`data dictionary are limited, in that its internal structure,
`function, and use are opaque to the user; however, there
`are many instances when a user or application would like
`to query information about the dictionary catalogs them(cid:173)
`selves, and not what is in them.
`This paper presents an enhanced data dictionary facil(cid:173)
`ity, known as EDICT, which captures and represents addi(cid:173)
`tional knowledge of interest to the database user. EDICT
`is integrated into the DBMS, utilizes a single representa(cid:173)
`tional
`framework
`for capturing multiple
`levels of
`knowledge about the database, and utilizes a single query
`language to access its tables--that which is supJ.>orted by
`the DBMS (e.g., SQL). In addition, this paper Will discuss
`these extensiOns in the context of an information.architec(cid:173)
`ture which incorporates multiple levels of information into
`the enhanced dictionary.
`The basic premises for
`enhanced data dictionary are:
`to provide extended representation capabilities
`1.
`to existing data dictionaries in commercially
`available products;
`to allow knowledge about the enterprise schema
`to be captured and represented directly in the
`database itself, having the ability to be examined
`and utilized;
`to allow knowledge about the structure and
`inner workings of the data dictionary to be cap(cid:173)
`tured and represented directly in the database;
`to provide an environment for developing
`loosely-coupled knowledge base management
`systems (KBMS) which provide for the intelligent
`management and control of data and knowledge
`about data; and,
`to provide an environment, facilitated by the
`data dictionary, where
`the database design
`activity can be carried out by computer.
`The remaining sections of this paper are organized as
`follows. Section 2 discusses the data dictionary concept as
`applied in current commercial and research systems
`relevant to this paper. Section 3 presents the EDICT
`architecture and
`its components. Finally,
`the !aper
`presents an example database application an
`the
`corresponding schema tables under EDICT.
`the
`The discussion
`in
`this paper will use
`ANSI/SP ARC DAFTG database model as a point of
`reference for this discussion. In addition, the schemata
`presented are defined in terms of the E-R data model. It
`Is assumed that the reader is familiar with both.
`
`3.
`
`4.
`
`5.
`
`

`

`2. THE DATA DICfiONARY CONCEPT
`The data dictionary has been discussed in [ATRESOJ,
`[HAWR85], and other sources, as a repository for data,
`from both logical and physical levels of the database sys(cid:173)
`tem. This information 1s useful in describing the contents,
`organization and use of data stored in the database.
`However, one major aspect for the use of the data
`dictionary is during the schema design process [TSIC82,
`KAHN85, JARK86J. Here, the data dictionary is used to
`document functions and data classes, along with relation(cid:173)
`ships and behavior of data in the enterprise. This is useful
`for purposes of more effective communication among
`designers, users, and administrators. Most data dictionaries
`do not directly support this activity.
`There has been much work in the area of extending
`the ideas of what information can and should be captured
`in the data dictionary, and how this additional information
`can be used.
`The basic premise for most work in this area involves
`the definition of multiple levels of abstraction, with distinc(cid:173)
`tions between data, meta-data, schema, and meta-schema.
`Generally, the descriptions at the higher levels defines the
`structure of the level just below it; i.e., a level is the inten(cid:173)
`sion and the level below it is the extension. The most not(cid:173)
`able work in this area is the proposed ANSI/SP ARC
`reference model for DBMS architecture [BURN86].
`The ANSI/SPARC DBMS reference model, pro(cid:173)
`posed by the batabase Architecture Framework Task
`Group (DAFTG), presents a multilayered architecture for
`descnbing the definition and use of data in a DBMS. The
`description of data is at four levels--application data, appli(cid:173)
`cation schema, data dictionary schema, and data model
`schema--where each level is the extension (i.e., the "data")
`of the level above it and is the intension (i.e., the
`
`"schema") of the level below it. Furthermore, the levels are
`self-describing, in that each level's intension is itself stored
`as part of its extension. This is presented in the context of
`te ANSI/SP ARC 3-schema architecture.
`This architecture is referenced and used in [MARK83,
`MARK87], where the management of metadata is handled
`by defining operators which facilitate dynamic modification
`of the data and schemata via changing the contents of the
`corresponding intension descriptions.
`The EDICT approach is very similar to the DAFTG
`architecture; in fact, it conforms to it where appropriate.
`The major distinction between DAFTG and EDICT is
`that (as will be shown) the DAFTG model doesn't concern
`itself with data and schema descriptions which are outside
`the context of the DBMS environment. The EDICT archi(cid:173)
`tecture is primarily concerned with incorporating the
`enterprise schema into the data dictionary. The enterprise
`schema is independentof any DBMS implementation and,
`as such, is an enhancement to the DAFTG architecture.
`A similar approach to DAFTG is presented in
`[GOLD85] for IRDS, which is also a multilevel self(cid:173)
`describing data architecture. Other ideas for the inclusion
`of semantic information into the definition and manage(cid:173)
`ment functions of a data dictionary are presented in
`[BRAT83, MART83, RUSP83]. EDICT shares the same under(cid:173)
`lying representation for schema modeling--the Entity(cid:173)
`Relationship Data model [CHEN76].
`
`3. ARCHITECfURE
`EDICT is a multilayered architecture for facilitating
`the development and management of information in a
`relational DBMS; however, the architecture is generic
`enough such that it could be applied to other types of
`DBMS's.
`
`DICTIONARY
`
`MET A-SCHEMA
`
`intension
`
`extension
`
`ENTERPRISE
`META-SCHEMA
`
`DICTIONARY
`
`SCHEMA
`
`intension
`
`T intension
`
`j extension
`
`intension
`
`extension
`
`extensio
`
`REAL
`
`" ENTERPRISE
`acquisition
`SCHEMA
`v
`
`mapping
`
`... CONCEPTUAL
`SCHEMA
`"
`
`_ ...
`
`mapping
`y
`
`INTERNAL
`
`SCHEMA
`
`intension
`
`extension
`
`DATA I
`
`DICTIONARY
`META-SCHEMA
`TABLES
`
`DICTIONARY
`SCHEMA
`TABLES
`
`ENTERPRISE
`META-SCHEMA
`TABLES
`
`CONCEPTUAL
`SCHEMA
`TABLES
`
`DBMS-INDEPENDENT
`
`-
`DBMS DEPENDENT
`
`DBMS WORLD
`
`Figure 1. EDler Architecture and Components
`
`185
`
`

`

`EDICT is defined as enhancements to existing rela(cid:173)
`tion3'-~ data dictionary f3'-cilities! through the definition of
`addittonal schemata which are mtegrated into the diction(cid:173)
`ary proper.
`FT' re 1 presents the architecture, which has horizon(cid:173)
`tal an vertical dimensions. The horizontal dimension
`~bows the flow of knowledge during the process of design(cid:173)
`mg a database--from
`the acquisition of enterprise
`knowledge into an enterprise schema (such as can be
`developed using the E-R model), through the mapping to
`the conceptual schema (which is the relational model) to
`finally mapping to the internal schema (which is the under(cid:173)
`lying storage structures and indexes).
`The vertical dimension shows the levels of abstraction
`between data and the associated schema which defines its
`structure, a.t the level just above it. The conceptual
`schema defmes the structure of the enterprise which is
`capable of bein~ rep~esented in the u~derlying relational
`data model. It IS denved from a mappmg of the enterprise
`schema (e.g., an E-R diagram) according to a methodol(cid:173)
`ow such as [DUMP81, BONN84]. The E-R model is not
`directly represente~ in the DBMS, but its mapping to the
`conceptual schema IS.
`The descriptions of the conceptual schema are kept in
`the dictionary schema (i.e., data dictionary or system cata(cid:173)
`logs). The dictionary schema contains data about the con(cid:173)
`ceptual, internal, and external schemata (the applicability of
`~he ~~erntfl schema is ~ot considered in this paper, but is
`1mphc1tly mcorporated mto the EDICT architecture).
`l!P to this point, the EDICT architecture is compati(cid:173)
`ble w1th DAFfG, but now EDICT makes a distinction
`between the dictionary schema and the dictonary meta(cid:173)
`schema. The dictionary meta-schema contains data which
`de~ines the structure and use of the dictionary schema.
`Th1s goes beyond the notion of having a self-describing
`schema, but it may be a matter of interpretation as to
`whether the dictonary meta-schema should be a distinct
`level or not. However, there is considerable value in hav(cid:173)
`ing this meta-schema available for query by users or afpli(cid:173)
`cations (RTI85), such that the structure and definition o the
`data dictionary can be understood.
`It should be noted that the DAFfG's data model
`schema level is not covered in this paper, but is implicit in
`the EDICT architecture. Most commercial data dic(cid:173)
`tionaries incorporate some portion of this schema (i.e.,
`capturing portions of the relational semantics in the rela(cid:173)
`tional tables of the data dictionary).
`However, a schema which is more useful, under the
`premises discussed at the outset of this paper, is that of
`the enterprise meta-schema. This schema allows
`the
`"essence" of the enterprise schema, captured in a OHMS(cid:173)
`independent semantic data model (such as the E-R
`model), to be represented and preserved in the underlying
`DBMS data model.
`Thus, the EDICT architecture could be considered a
`subset as well as a superset of the DAFfG reference
`model--a subset in that It deals explicitly with most of the
`components of the intension-extension dimension, and a
`superset in that it defines an additional level in the point(cid:173)
`of-vie~ dimension for the modeling of the enterprise
`domam.
`
`In the following descriptions of the EDICT com(cid:173)
`ponent~, t~e E-R data model is used to represent the
`semantic mtent of each of the schemata. With each
`schema, t~e E-R
`representation is mapped
`to
`its
`correspondmg representation in the relational model. The
`schemata presented are by no means complete but are
`shown with enough detail to illustrate the concept~.
`~t should be . noted, as a general principle, that the
`relattonal model IS less expressive than the E-R model
`and, as such, cannot retain the full semantic intent from
`the E-R model--thus, information is lost in the mapping.
`In the context _of EDICT, the enterprise meta-schema
`serves the functton of preserving some of these semantics
`which would otherwise be lost.
`
`3.1. Enterprise and Conceptual Schemata
`. The en!erprise sche~a captures the objects and asso(cid:173)
`.
`CIB;tions whtch are 9f mterest to the S_{>ecific enterprise
`bemg modeled. In this paper, the enterpnse modeling pro(cid:173)
`~edure is used to capture information about the enterprise
`m te~ms ~f the cons~ructs of th~ E~R model--entity sets,
`relattonsh1p sets, attnbutes, cardmahty, etc. The enterprise
`schema is 3: ~epre~entation whic_h .is independent of any
`DBMS-specific enVIronment. This IS mapped to a specific
`DBM~ environment via the logical data model supported(cid:173)
`-relattonal tables. The enterprise schema exists as data in
`the enterprise meta-schema
`tables of the supporting
`relational DBMS. The schema shown in Figure 2 is for a
`food-coop example discussed in the next section.
`
`Figure 2. E-R Model of Enterprise Schema
`
`The enterprise schema is mapped to a relational
`schema, which is the conceptual schema for a relational
`database. In a DBMS environment, the relation schemes
`are created, and the user must enter the data instances.
`The relational schema for Figure 2 is shown below:
`SUPPLIERS(~. ADDR)
`ITEMS( INAME)
`MEMBERS(~. MAD DR, BALANCE, SPOUSE_ MNAME)
`DELIVER( SNAME, ~. PRICE)
`ORDER( MNAME, INAME, ORDER _NO, QTY)
`
`186
`
`

`

`3.2. Dictionary Schema
`The dictionary schema is the schema which captures
`the information required by a given DBMS to manage the
`conceptual schema. This is the defining structure for the
`particular DBMS's data dictionary, and as such, is depen(cid:173)
`dent on the implementation and organization of the
`DBMS being used--this is in terms of what "data" about
`the data is captured and represented by the DBMS.
`
`(1 ,1)
`
`(1 , 1)
`
`RELATION( ~. RELOWNER, RELATTS, RELWID , RELSPEC, RELSTAT, ... )
`ATTRIBUTE( ATTRELID, ATTOWNER, ATTID, ATTNAME, ATTFRMT, ... )
`INDEXES( IRELIDP, IOWNERP, IRELIDI, IRELSPECI, ... )
`TREE( TREEREi:iD,"TREEOWNER, TREEID, TREETYPE, ... )
`PROTECT( PRORELID, PRORELOWN, PROUSER, PROTREE, ... )
`INTEGRITIES( INTRELID, INTRELOWNER, INTTREE, ... )
`
`3.3. Enterprise Meta-Schema
`The enterprise meta-schema captures the objects and
`associations which are directly modeled using the E-R
`data model--explicitly as a self-describing E-R model (i.e.,
`an E-R model of the E-R model itself). This E-R
`representation captures and expresses the concepts and
`structure, as well as the objects and associations, mherent
`in the E-R semantic data model and its use.
`Figure 4 depicts this representation of a partial enter(cid:173)
`prise meta-schema. Additional information which would
`be kept in this schema would be information about
`synonyms, keys, etc. Several new notational constructs are
`used, as defined in [DA VI87]. The ") )xoR" construct
`denotes that an attribute is either associated with an entity
`set or a relationship set, but not both and not neither. The
`integer numbers beside the diamond constructs indicate
`the ordering of entity sets in the context of the relationship
`that they participate in.
`
`10
`
`Flgure 3. E-R Model of Dictionary Schema
`
`The dictionary schema forms the basis of the data dic(cid:173)
`tionary system catalogs. The approach in this paper
`extends these catalogs by incorporating not only data
`about the data (hence meta-data), where knowledge about
`the the data in terms of the external, conceptual, and
`internal schemas of the ANSI reference model is kept, but
`also incorpor~tes knowledge about t_he underlying ente;(cid:173)
`prise schema, mdependent of the logical model, stored m
`tables.
`Note that the dictionary schema is closely coupled to
`the particular DBMS being used, whereas the enterprise
`meta-schema and the enterprise schema are not.
`The tables defined for the meta-data, as supported in
`a version of the Ingrest DBMS, are shown below (note
`that this is a partial dictionary schema):
`
`Figure 4. E-R Model of Partial Enterprise Meta-Schema
`
`This schema captures the information in the specifi(cid:173)
`cation and use of the E-R model and, as such, is a schema
`which is independent of any connection to a particular
`DBMS environment or logical data model. In other words,
`this schema captures information which is not connected
`with how data or meta-data will be organized, either logi(cid:173)
`cally or physically, in any given DBMS.
`Even though this schema captures concepts which are
`independent of any DBMS, it must be capable of being
`represented in the underlying DBMS; thus, the enterprise
`meta-schema is mapped to a set of relational tables
`according
`to a well-understood algorithm
`[DUMP81,
`BONN84]. These tables are defined below.
`
`187
`
`

`

`ENTITY SETS( ESET NAME, ESET TYPE)
`' RElATIONSHIP SETs( RSET NAME, RSET_ARrrY, RSET_TYPE)
`ATTRIBUTES( ATTR NAME, ATTR_DOMAIN, ATTR_KEYNESS)
`ESET ATTR( ATTR NAME, ESET NAME)
`RSET-ATTR( ATTR NAME, RSET NAME)
`BINARY RElATIONSHIP( RSET NAME, FJRST ESET NAME,
`SECOND_ESET NAME, DEP_TYPE,
`-
`MIN CARD, MAX CARD,
`FJRST- ROLENAME, SECOND _ROLENAME)
`
`It should be noted that the choice of the E-R model
`as the basis of this meta-schema is due to the preference
`of the authors; other semantic data modeling formalisms
`could be used instead. Also, the other part of enterprise
`analysis, transaction anal¥sis [TSIC82], where queries on the
`database are examined, IS not considered in the scope of
`this paper.
`
`3.4. Dictionary Meta-Schema
`The dictionary meta-schema is the schema used to
`capture and represent the meta-data about the structure
`and organization of the dictionary schema (i.e., the data
`dictionary or system catalogs). This schema presents
`knowledge about the organization and definition of the
`components of the data dictionary of a specific DBMS
`once mapped to tables. The E-R representation for this
`schema is shown in Figure 5.
`
`ID
`
`E
`
`(1,N)
`
`(0,1)
`
`(O. N )
`
`Figure 5. E-R Model of Dictionary Meta-Schema
`
`The correspondin~ relational tables for the dictionary
`meta-schema are giVen below:
`
`CATALOG( CAT_NAME, CAT_TABWID, CAT_TABSTORAGE,
`CAT TAB DEFIN)
`COLUMN( COL NAME, COL_FORMAT,-COL_DEFIN, CAT_NAME)
`STATUS BIT( SBIT NAME, SBIT_VALUE, SBIT_DEFIN, COL_NAME)
`CATALOG_KEY( COL NAME, KEY_ELEMENT_NO, CAT_NAME,
`CK_KEYPARTS)
`
`188
`
`4. EXAMPLE
`An example can be used to best illustrate how the
`EDICf approach can be used to enhance the data diction(cid:173)
`ary. A food-coop database, after (ULLM82] is to be set up,
`which keeps track of the members of the coop, the sup(cid:173)
`pliers, items ordered, etc. The E-R model of the enter(cid:173)
`prise schema was shown in Figure 2; the corresponding
`relational tables, instantiated with data, are shown below.
`
`SUPPLIERS
`
`sname
`
`Sunshine Produce
`Purity Foodstuffs
`Tasti Supply Co.
`
`saddress
`16 River St.
`180 Industrial Rd.
`17 River Dr.
`
`ITEMS
`
`Ina me
`granola
`unbleached flour
`whey
`sunflower seeds
`lettuce
`
`MEMBERS
`
`mname
`Brooks, B.
`Field, W.
`Robin, R.
`Hart, W.
`Field, S.
`
`maddr
`7 Apple Rd.
`43 Cherry Ln.
`12 Heather Rd.
`7 Apple Rd.
`43 Cherry Ln.
`
`balance
`10.50
`0
`-123.45
`-43.00
`.25.00
`
`spouse_ mname
`Hart, W.
`Field, S.
`
`Brooks, B.
`Field, W.
`
`sname
`Sunshine Produce
`Sunshine Produce
`Sunshine Produce
`Purity Foodstuffs
`Purity Foodstuffs
`Tasti Supply Co.
`
`DELIVER
`
`lname
`granola
`lettuce
`sunflower seeds
`whey
`granola
`lettuce
`
`ORDER
`
`price
`1.29
`.89
`1.09
`.70
`1.25
`.79
`
`mname
`Brooks, B.
`Brooks, B.
`Robin, R .
`Hart, W.
`Robin, R .
`Robin, R .
`
`I name
`
`granola
`unbleached flour
`granola
`whey
`sunflower seeds
`lettuce
`
`order_no
`1042
`1042
`1045
`1044
`1039
`1039
`
`qty
`Sboxes
`10 lbs.
`3 boxes
`Sibs.
`21bs.
`8 heads
`
`The dictionary schema is instantiated with the meta(cid:173)
`data concerning this database. This schema is demon(cid:173)
`strated based on information published about the structure
`of the system catalogs for a version of the Ingrest DBMS
`(DUER83]. Two of these tables are shown below for the
`dictionary schema of Figure 3:.
`
`

`

`RElATION
`
`relid
`suppliers
`items
`members
`deliver
`orders
`
`rei owner
`jd
`jd
`jd
`jd
`jd
`
`relatts
`
`2
`1
`3
`3
`4
`
`relwid
`40
`20
`44
`44
`48
`
`rei spec
`5
`5
`5
`5
`5
`
`relstat
`0600134
`0600134
`0600134
`0600134
`0600134
`
`...
`...
`...
`...
`...
`...
`
`attrelid
`suppliers
`suppliers
`items
`members
`members
`members
`deliver
`deliver
`deliver
`orders
`orders
`orders
`orders
`
`A'ITRIBUTE
`
`attrowner
`jd
`jd
`jd
`jd
`jd
`jd
`jd
`jd
`jd
`jd
`jd
`jd
`jd
`
`attld
`
`1
`2
`1
`1
`2
`3
`1
`2
`3
`1
`2
`3
`4
`
`attname
`sname
`saddress
`iname
`mname
`maddr
`balance
`sname
`ina me
`price
`name
`ina me
`order no
`qty
`
`attrrmt
`32 (character)
`32 (character)
`32 (character)
`32 (character)
`32 (character)
`5 (money)
`32 (character)
`32 (character)
`5 (money)
`32 (character)
`32 (character)
`30 (integer)
`30 (integer)
`
`...
`
`...
`...
`...
`...
`...
`...
`...
`...
`...
`...
`...
`...
`...
`
`ENTITY SETS
`
`eset name
`suppliers
`items
`members
`
`eset_type
`regular entity set
`regular entity set
`regular entity set
`
`Populating the ESET ATTR and RSET ATTR tables with
`data from the example is intuitive, and thus is omitted.
`An instantiated dictionary meta-schema is shown
`below for the food-coop example. This schema is signifi(cid:173)
`cant in that it allows users or applications to query for
`information about the structure of the data dictionary
`itself.
`
`CATALOG KEY
`
`col name
`relid
`attrelid
`attrowner
`
`key_element_no
`
`1
`2
`
`cat_name
`relation
`attribute
`attribute
`
`ck _ keyparts
`
`1 pan
`2pans
`2 pans
`
`col name
`relstat
`relstat
`relstat
`rclstat
`reistat
`relstat
`
`cat name
`
`relation
`relation
`relation
`relation
`relation
`attribute
`attribute
`attribute
`
`The important additions for enhancing the data dic(cid:173)
`tionary for this database come with instantiation of the
`enterprise and dictionary meta-schemata. The enterprise
`meta-schema provides information about the initial enter(cid:173)
`prise model, and the semantic constraints associated with
`It, which can not be captured in the relational schema. The
`enterprise meta-schema allows this information to be
`preserved.
`
`sbit name
`s_catalog
`s_noupdt
`s_protups
`s_ integ
`s concur
`s view
`
`sblt_value
`0000001
`0000002
`0000004
`0000010
`0000020
`0000040
`
`STATUS_BIT
`
`sblt_defin
`table is a system catalog
`no updates allowed on table
`"protect" catalog reference
`"integ" catalog reference
`concurrency control via page lock
`user table is a view
`
`RELATIONSHIP SETS
`
`rset_name
`deliver
`orders
`married_to
`
`rset_arity
`binary
`binary
`unary
`
`rset_type
`regular relationship set
`regular relationship set
`regular relationship set
`
`A 'ITRIBUTES
`
`attr_name
`name
`address
`balance
`item
`sname
`sad dress
`order no
`quantity
`price
`
`attr domain
`alphanumeric
`alphanumeric
`real number
`alphanumberic
`alphanumeric
`alphanumeric
`integer
`integer
`real number
`
`attr _ keyness
`
`key
`non-key
`non-key
`key
`key
`non-key
`non-key
`non-key
`non-key
`
`BINARY_ RElATIONSHIP
`
`col name
`relid
`ret owner
`relatts
`relwid
`relstat
`attrelid
`attrowner
`attid
`
`col _format
`c12
`c2
`i2
`i2
`i4
`cl2
`c2
`i2
`
`COLUMN
`
`col_defin
`database table name
`table owner (2 letter code)
`number of columns in table
`tuple row width (bytes)
`status bits for table
`table name to which column belongs
`owner of table
`column number in table
`
`rset_name
`deliver
`orders
`married to
`
`lst_ename
`suppliers
`members
`members
`
`lnd_ename
`items
`items
`members
`
`deptype
`
`existence
`
`min_card
`0:1
`0:1
`1:0
`
`max_card
`M:N
`M:N
`1:1
`
`1st rlname
`
`2nd rlname
`
`spouse
`
`189
`
`

`

`cat name
`relation
`attribute
`indexes
`tree
`integrities
`
`CATALOG
`
`cat tabwld
`52
`35
`33
`120
`33
`
`cat_ tabstorage
`hash
`hash
`hash
`hash
`hash
`
`cat_ tab_ denn
`describes how each table is stored in database
`describes information about columns in tables
`contains info. on secondary indexes
`contains query trees needed for query optimization
`contains info. on table integrity constraints
`
`5. SUMMARY
`This paper has presented EDICT--an architecture for
`an enhanced data dictionary facility for a relational
`DBMS. An example using Ingrest was also presented for a
`small application.
`The EDICT architecture was shown to be highly
`compatible with the ANSI/SP ARC DAFfG database
`reference model, with some additions. The main distinc(cid:173)
`tions of the EDICT approach are:
`1. The enterprise schema, captured via the use of a
`semantic data model, can be stored in the
`DBMS through the use of an enterprise meta(cid:173)
`schema. This facilitates having greater insight
`into the semantics of the enterprise which aren't
`available in the relational representation alone.
`Furthermore, it would be possible to perform
`schema evolution at the semantic level, which is
`closer to the representation that humans use,
`rather than in a logical data model that lacks
`semantic notational constructs (this notion of
`schema evolution is outside the scope of this
`paper, but has been considered by others, such
`as [MARK87J).
`2. The existing system catalogs (i.e., the dictionary
`schema) can be more effectively used by having
`descriptions of their structure and meanin~ avail(cid:173)
`able to users and applications. This is facilitated
`by the dictionary meta-schema.
`In the context of the EDICT architecture, the
`enhanced dictionary is actually composed of the
`dictionary schema, the dictionary meta-schema,
`the enterprise meta-schema. All are
`and
`represented in the same underlying data model
`supported by the DBMS, and all can be queried
`usmg the same query language supported by the
`DBMS.
`The EDICT architecture was demonstrated for a
`relational DBMS, but is also valid for hierarchical or
`network-based DBMS's as well. In addition, the E-R
`model was used for defining the enterprise meta-schema,
`but any high-level semantic data model could be used.
`It should be noted that, in the example presented,
`EDICT was not shown to be self-describing, after the
`fashion of DAFTG (BURN86, MARK87] (i.e., schema tables
`which contain data about themselves). But the schemata
`could be self-describing, where it makes sense to do so,
`provided that the supportin~ DBMS allows self-describing
`of a schema (such as the dzctionary schemain this paper).
`Most commercial DBMS products don't allow this, but 1t
`appears that Oraclet does provide the ability for a user to
`extend the data dictionary (ORAC86). This is a part of
`further investigation.
`
`3.
`
`The EDICT architecture is the basis of research in
`the areas of loosely-coupled knowledge base management
`systems, and in the development of model-based reasoning
`to perform log1cal database design [DA VISS].
`systems
`Endowing EDICT with the capability to reason about the
`state of its schemata is the subject of further research.
`
`6. BIBLIOGRAPHY
`[ATRE80]
`Atre, S., Data Base: Structured Techniques for Design,
`Performance, and Management, John Wiley and Sons,
`Inc., 1980.
`[BONN84]
`Bonnell, RD., Tower-1632 Ingres Relational DBMS
`Course Notes, NCR Corporation, 1984.
`[BURN86]
`Burns, T., E. Fong, D. Jefferson, R Knox, L Mark,
`C. Reedy, L Reich, N. Roussopoulos, and W.
`Truszkowski, "Reference Model for DBMS Standardi-
`zation",
`·
`SIGMOD Record, VoL 15, No. 1, March 1986.
`[BRAT83]
`Brathwaite, K. S., "An Implementation of a Data Dic(cid:173)
`tionary to Support Databases Designed Using the
`Entity-Relationship (E-R) Approach", in Davis, C.G.,
`et al ( eds. ), Entity-Relationshzp Approach to Software
`Engineering, ER Institute, 1983, pp. 393-410.
`[CHEN76]
`Chen, P.P., ''The Entity-Relationship Model: Toward
`a Unified View of Data", ACM Trans. Database Sys(cid:173)
`tems 1, pp. 9-36.
`[CODD70]
`Codd, E.F., "A Relational Model For Large Shared
`Data Banks", Comm. ACM 13, 1970, pp. 377-387.
`[DAVI85J
`DaVIs, J.P., and RD. Bonnell, "DBA - An Expert
`DataBase Assistant: Architecture and Specificauon",
`Center for Machine Intelligence, University of South
`Carolina, USCMI Report #85-30, 1985.
`[DAVI87J
`DaVIs, J.P., and RD. Bonnell, "Role Representation
`in the E-R Model", Center for Machine Intelligence,
`University of South Carolina, USCMI Report #87-40,
`1987.
`[DUER83]
`Duerr, S., "INGRES System Catalogs", from RTI
`Application Notes #9, c 1983, Relational Technology
`Inc.
`
`tlngres is a trademark of Relational Technology Inc.
`
`t Oracle is a trademark of Oracle Corporation
`
`190
`
`

`

`[DUMP81]
`Dumpala, S.R., and S.K. Arora, "Schema Translation
`Using the Entity-Relationship Approach", in Chen
`P.P (ed.) Entity-.RelationshipApproach to /nformatio~
`Modeling and Analysis, ER Institute, 1981 pp. 583-
`608.
`'
`[GOLD85l
`Goldfine, A, 'The Information Resource Dictionary
`System", Proceedings of 4th Conference on the E-R
`Approac