UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

The design of semantic database model SDBM Xie, Linchi 1987

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata


831-UBC_1987_A4_6 X53.pdf [ 6.06MB ]
JSON: 831-1.0096830.json
JSON-LD: 831-1.0096830-ld.json
RDF/XML (Pretty): 831-1.0096830-rdf.xml
RDF/JSON: 831-1.0096830-rdf.json
Turtle: 831-1.0096830-turtle.txt
N-Triples: 831-1.0096830-rdf-ntriples.txt
Original Record: 831-1.0096830-source.json
Full Text

Full Text

THE  DESIGN  OF  SEMANTIC  DATABASE  MODEL  SDBM  by LINCHI X1E B.Sc. Shanghai Jiao Tong  A THESIS SUBMITTED IN  University  PARTIAL FULFILLMENT O F  THE REQUIREMENTS FOR THE DECREE O F MASTER O F SCIENCE ( BUSINESS ADMINISTRATION )  in THE FACULTY O F GRADUATE STUDIES Faculty of  We  C o m m e r c e and Business  accept this thesis as to  the  required  Administration  conforming  standard  THE UNIVERSITY O F BRITISH C O L U M B I A Febuary  1987  © Linchi Xie, 1987  In presenting this thesis in partial fulfilment of the requirements for an advanced degree at The University of British Columbia, I agree that the Library shall make it freely available for reference and study. I further agree that permission for extensive copying of this thesis for scholarly purposes may be granted by the Head of my Department or by his or her representatives. It is understood that copying or publication of this thesis for financial gain shall not be allowed without my written permission.  Faculty of  C o m m e r c e and Business  The University of British Columbia 2075 Wesbrook Place Vancouver, Canada V6T 1W5 Date: Febuary 1987  Administration  ii  ABSTRACT  This design.  thesis  The  discussion  domain  of  concerned  this  with  research  is  thesis assesses a number of  models  semantic  and  data  inadequacy  reviews  modelling  of  the  conceptualization that the  mainly  is carried out at the conceptual  The data  is  several  general  modelling  principles  of  to  modelling  related  data  to  modelling  database and  the  level.  Based  conceptualization  data  restricted  serious  basic  research.  semantic  on  and  these  data  shortcomings mechanisms  findings,  modelling  the  and  of  the  conventional  developed thesis  develops  in current  identifies the  the  two-view  of data modelling. The basic idea behind the two-view conceptualization is  conceptual structure of the  applications  being  modelled should be  separated  from  its external data representation.  A new The  semantic  database  model,  SDBM,  is designed  based  on the  conceptualization.  model makes a clear separation between the conceptual structure and its external data  representation.  It offers  window  mechanism  provide  database  models  to  a data model  operations.  type the  One  mechanism  conceptual of  the  to  deal  structure,  major  with and  extensions  of  the  data  representation,  a transaction the  current  mechanism semantic  is that with SDBM the specialization relationship is just a special case of  that can be specified  among SDBM  windows.  A formal  and informal  semantics  syntax  of  comparisons between SDBM and a closely-related  SDBM  are given  in the  a to  data  constraints  thesis along with  semantic data model, Taxis.  iii  TABLE  OF  CONTENTS  Page  ABSTRACT  ii  TABLE O F C O N T E N T S  iii  ACKNOWLEDGEMENTS  :  vi  1. I N T R O D U C T I O N  1  1.1  OBJECTIVES  1  1.2  APPROACH  3  1.3  PREVIOUS W O R K  5  1.4  THESIS OUTLINE  8  2. REVIEW O F DATA M O D E L L I N G 2.1  2.2  SEMANTIC M O D E L L I N G  10  PROBLEMS OF THE RELATIONAL DATA  MODEL  10  2.1.1  TUPLE ORIENTATION  10  2.1.2  SEMANTIC O V E R L O A D I N G  12  2.1.3  ATOMIC  13  2.1.4  NORMALIZATION  15  2.1.5  RELIANCE O N  16  2.1.6  GENERALIZATION/SPECIALIZATION  18  2.1.7  REQUIREMENT O F H O M O G E N E I T Y  19  2.1.8  AGGREGATION  20  DOMAINS  USER-CONTROLLED IDENTIFIERS  SEMANTIC EXTENSIONS T O THE RELATIONAL DATA M O D E L 2.2.1  EXTRA CONSTRAINTS  2.2.2  SEMANTIC CLASSIFICATION  2.2.3  THE ENTITY-RELATIONSHIP  2.2.4  CONCLUSIONS  21 22  O F RELATIONS APPROACH  23 23 24  iv  3.  REVIEW OF SEMANTIC  DATA  MODELLING  25  3.1  BASIC PRINCIPLE  25  3.2  OBJECT ORIENTATION  25  3.3  DATA ABSTRACTION  ;  3.3.1  CLASSIFICATION  3.3.2  AGGREGATION  28  3.3.3  GENERALIZATION/SPECIALIZATION  30  3.3.4  ASSOCIATION  32  '.  3.4  SEMENTIC INTEGRITY  3.5  APPLICATION  CONSTRAINTS  29  32  OF DATA TYPES  35  3.5.1  USE OF THE DATA TYPE C O N C E P T  36  3.5.2  DATA TYPE STRUCTURES  37  4. THE C O N C E P T U A L I Z A T I O N 4.1  27  THE UNDERLYING  OF DATA  MODELLING  PHILOSOPHY  38 38  4.2 THE TWO-VIEW C O N C E P T U A L I Z A T I O N  38  4.2.1  A GENERAL DESCRIPTION  39  4.2.3  S D B M OBJECTS  40  4.2.3  S D B M RELATIONSHIPS  44  4.2.4  S D B M PROPERITIES  47  4.2.5  S D B M TYPE C O N C E P T  47  4.2.6  SDBM WINDOW  49  4.2.7  AN  CONCEPT  EXTENSION T O  SPECIALIZATION  5. OVERVIEW O F S D B M  MECHANISM  51 54  5.1  SOME NOTATION CONVENTIONS  55  5.2  S D B M TYPE SYSTEM  56  5.2.1  ELEMENTARY DATA TYPES  56 NUMERIC  56 B O O L E A N S  57  V  5.3 CHARACTERS  58 ENUMERATION  59  5.2.2  STRUCTURED DATA TYPES  59  5.2.3  ABSTRACT DATA TYPES  63  5.2.4  SUBTYPE HIERARCHIES  66  SDBM WINDOW  SYSTEM  72  5.3.1  SDBM SUBWINDOW  5.3.2  CONSTRAINTS A M O N G  5.4 S D B M TRANSACTION  HIERARCHY WINDOWS  SYSTEM  83 85  5.4.1 TRANSACTION AS ABSTRACTION OPERATION  86  5.4.2  TRANSACTION  DESIGNATOR  87  5.4.3  TRANSACTION  BODY  89 ASSIGNMENT  91 CREATION  91  94  DESTRUCTION INSERTION  94 MODIFICATION  97 DELETION  99 RETRIEVAL  100 C O M P O U N D STATEMENT  102 C O N D I T I O N A L  102 ITERATION  STATEMENT  STATEMENT  103 ABORT STATEMENT 5.5  82  104  EXPRESSIONS  5.6 OPERATIONS O N MULTI-VALUED  104 PROPERTIES  106  5.6.1 ADDITION  107  5.6.2  REMOVAL  107  5.6.3  MODIFICATION  108  vi  6. A N  APPLICATION  EXAMPLE OF S D B M  6.1  A HYPOTHETICAL  6.2  A SDBM  6.3  TRANSACTIONS  6.4  SUMMARY  110  PROJECT M A N A G E M E N T  PROJECT M A N A G E M E N T FOR END  SYSTEM  DATABASE  111 112  USER OPERATIONS  121 124  7. C O N C L U S I O N S  125  BIBLIOGRAPHY  129  APPENDIX A. SYNTAX OF S D B M  135  APPENDIX  B. C O M P A R A S O N S  BETWEEN S D B M A N D  TAXIS  148  B. 1 SIMILARITIES  148  C. 2 DIFFERENCES  148  vi  ACKNOWLEDGEMENTS  I am at  the  deeply  University  involved  to  his guidance I  interest  people w h o  Columbia.  Here,  sincere thanks  encourgement.  learnt  also have  wish  so  to  helped  have helped through  I can  only  mentioned  my  those  graduate  who  study  have  been  much  to  my  supervisor Prof.  I truely appreciate from  his  database  his time and course  which  Robert efforts  has  C . Goldstein  for  in  supervising  my  greatly  stimulated  my  to  thank make  like  to  thank  I can always resort to  correct  Yair  the  thesis  more  complete.  M s . Grace  Wong  who  Deep  thanks to  of serious thoughts  study  to  many typos  this final version more  My  Prof.  Wand  for  his  insightful  comments  Many  thanks  to  on my  the  thesis,  third  reader  Fowler.  I would  pains  many  in database research.  Mr. Albert  easier.  British  express my  and  have  I which  of  to  in my thesis work.  I wish  study.  indebted  at  her and  for  help. Thanks  English language  have  made  also to errors  my  stay  M s . Mackie  in my  thesis  in  Canada  Chase  who  draft, which  much took makes  intelligible.  my friend  Kefeng Xu who  typed  part of this thesis. W e  share a lot  as well as many not-so-serious jokes.  University  of  International Development Agency.  British  Columbia  is financially  supported  by  the  Canadian  1  INTRODUCTION  1.  OBJECTIVES  1.1  It to  has been  the  application-minded  interested entities,  in  the  their  conceptual directly  devoted  modelling  a  result  of  their  tools  a  of  tools  to  real  the  for  world  database  database design should  computer  relationships,  for  been  has the  proposed.  the  RM/T  [1980]), the & McLeod  recognition,  applications and  be  oriented  expert. The application-minded  their  which  are  changes.  design should  A  of  goal  capturing  of  be  described  based on  in  more user is  terms  of  data  models  as  real world  entities  as  Therefore,  few  effort  the  to  past  so-called  more  of  the  few  years  semantic  examples (Chen  model  DAPLEX data model  are  the  [1976]),  meaning of  (Codd  [1979]),  (Shipman  Data Semantic  Semantic the  many  data  data models can. A large number  model  data  during  amount  conventional  Entity-Relationship  [1976]),  this  considerable  modelled than the  the  user than  modelling  attributes,  modelling  have  that the  as possible.  As  data  recognized  of  [1982]), and the  data  modelling.  the  'real'  Model  world  model  being models  (Abrial (Smith  [1974]), &  (Mylopoulos  Semantic Data M o d e l  have  Semantic  semantic data  data model  Hierarchy  TAXIS  researchers  Smith et  (Hammer  [1981]). From their work, a set of concepts, mechanisms, and methodologies  developing  database-based  information  systems  at  the  conceptual  level  al  have  for  been  established.  At the in  same time,  programming  types,  data  concepts have  also  and  have  languages.  Consider  procedural  abstractions,  found  been  many important concepts and methodologies  extensive  applied  to  use  for  in  databases  example control  the in  the  structures,  database the  data  typing and  of  data  been  concept,  exception  design. Software  development  have  developed  abstract  handling.  engineering modelling  data These  concepts tools  and  2  techniques (Brodie models  are  not  et  al [1984]). The  just  are the integration  data models.  for  programming to  offer  investigation one  have  objects,  of  consider the properties  provide  revelant  two  among  world.  objects,  developed semantic data  are database programming  languages  which  and  and  are  For  the  modelling  models.  to  1  have  properites.  data  alternatives  for  be  and  and  to  offer  incorporating  most  greater  important  in terms  of two  in  to  a  certain  be  represented the  SDBM  to  SDBM  windows  properties.  It  is  window also  our  On  the  external  view  external  is introduced to  see part  conceptual  conceptualization  this  correspondence  him  the  side,  On  is designed for  allows  this  other  computer.  concept  specify  of  in  objects. These  the  appropriate  window  flexibility  different views. O n  This is the  concept  complete,  user, an S D B M SDBM  in  computer.  type  be  provided. The  structure.  is designed  aspect  be modelled as a collection of  The  modelling  designer,  relationships,  and  The  data modelling  data is represented in  sides must  For  data  interrelated  properties  how  (Semantic JJataBase Model), we will investigate  data  such correspondence. For the  'real'  recently  database designs  'real' w o r l d  relationships, and  these  of  conceptualization of  representation.  between  the  other  focus is on  objects,  data  than  relationships,  side, the  many  and semantic data modelling concepts. S D B M  conceptual view  is the  side, we  objects  semantic  language constructs  aspects  Rather, they  designing S D B M  conceptualizing  a clearer  certain  is that  of data models and programming languages.  In this thesis, through alternatives  result  to of  structure  that  differentiates  and  the  our approach from the previous work.  We hierarchy that  will in  also investigate  conceptualization  ^he  separation  databases. However, most  has greater  model,  the  modelling of  ability  than  data modelling  of  between  all, we  the  type  are interested  existing data models. W e  is sound through  the  hierarchy  in providing  a data  will demonstrate  design of  the  refers to the part of the real world  model  that  our  semantic database  SDBM.  'real' world  window  that we are interested in.  3  APPROACH  1.2  This  thesis  conventional  starts  data  our  attention  used  and  is  do  world. as  on  the  not  to  domain  intend  to  CAD/CAM  regularly  and  formatted  fall into our  Within  limit  the  the  research  to  even  the  model  more  in  capable  modelling  that  modelling  methodology  research is restricted  our  data  is  of  What  to  we  student  are  in  For  general  modelling  manageable  which  future.  data from  managed  include  of  a  problems  same  in  current  registration  range,  we  aspect  is  of  of  By that, the  'real'  applications  such  data  databases.  data, personnel  widely  reason  data modelling.  special purpose  many  the  is currently  the  every  interested  of  that  can  Examples  be  which  data, payroll  data,  data.  this perspective, semantic data modelling through  and  constraints  mechanisms  data  are  data modelling  procedures.  realm  are identified inherent  this  'What  to  used  exclude  office  modelling  and inventory  be  make  and  order  relational  of  For example, we  question  In  the  expected  manageablity,  the  models?'.  focus  we  with  that  are  analyzing the and  data modelling  through  necessary at  analyzing  the  implications  its  conceptual  problems of  inablity level.  of  to  the  relational  some of  provide  its  the  These problems  data  presumptions  basic  set  model  up  modelling the  major  target of this research.  To  overcome  DataBase M o d e l ) mechanisms programming  In concepts concept  this  of  identified  problems,  is designed, primarily this  model  come  from  for  the  two  a semantic purpose major  database  of  SDBM  (Semantic  database design. The  underlying  disciplines,  model  semantic  data  models  and  languages.  research,  including of  these  semantic  object  transaction,  etc.  data  orientation, They  are  modelling  is  classification, the  basic  viewed  as  aggregation, tools  for  a  set  of  well-established  generalization,  organizing  and  objects, and are essential to almost all the semantic data models developed  and  the  manipulating  recently.  4  SDBM the  most  is designed to  elementary  relationships  and  units  be  a management  that  properties.  facility  can be operated Objects,  conceptual world  related to  each other;  may  relationships,  be viewed  and possibly different  We  will actually specify the conceptual structure  computer  the  system  some  a data  construction  automatic  and  type  facility.  mechanisms  to  is  analysis  a major  of  the  may modify  the  research,  structure  The  through  The  cause of  record  because  is only  the  SDBM  component  its  structure our  part  of  problems record data  part of the type  The typed.  In  constructs  system  develop  objects  provides data  form  the  views  may  be  requirements  a window  concept.  concept.  is  handled  some  types.  are  world.  this w i n d o w  data  built-in  This  by  integrating  data  facility  model,  modelling  it  is  mainly  and the way it  story.  structure  types.  lie  investigation The  in  the  is, therefore,  Certain  clear  problems. To  that  types  enables  real  is used. The latter reveals  that  underlying  important  the  way the  the  cause of  and  certain  inter-component  record problems,  we  structures, or  we  alternative  trouble  data  is taken  with  relational  the  data  in  record  modelling  computer data representations.  record  designed. This  the  solve these  and look for some completely different  further  the  data  problems is that objects are confusingly mixed up with their Namely,  conceptually,  together  angles; different  will  SDBM  complex  relational  may abandon the record structure  this  of the 'real'  varieties, we  aspect of  create  conceptual  properties  different  are,  semantic integrity enforcements.  Through structure  these  data representation  other  which  viewers (users) may have different  information  The  c o p e with  from  for  into  details. To  objects  o n . Two  conceptual world which is the conceptual counterpart  This  for  kind  data structure of  record  constraints  is being permits  can  be  used.  complex  specified  as  definition.  advantages  of  static  type-checking  are  S D B M , every denotable value has a type.  recognized  by  designing  SDBM  to  Every expression can be statically  be type  5  checked. facility.  A  generalization/specialization  Type  hierarchy  rules  exist  mechanism is used in data type  In through  addition  to  window  checking.  relationship  The  static  constraints,  behavioral  Window  aspect  the  of  most  the  a database. The S D B M conceptually  SDBM  also  provided  correctness  also is  of  in  the  SDBM  specification.  type  Aggregation  construction.  enforces  primarily  semantic  used  for  integrity  referential  constraints constraints,  constraints.  database  is  that  by  can  Several  to  SDBM be  is constructed  operations. languages  modelled  units  transaction  meaningful  is  and window  basic operation  programming  the  checking  and uniqueness  manipulate  from  check  type-checking,  to  borrowed  to  construction  considered  smallest  be  mechanism  used  by  the  from statements  sequence  enchance  transactions  the  control  which  end which  are  user  to  are  the  mechanisms  expressiveness  of  are SDBM  transactions.  In summary, the modelling  problems  approach taken  of  the  relational  in this  data model  semantic  data modelling  research. Then  formed.  Based  conceptualization,  on  this  mechanisms are re-interpreted a  semantic  database  model,  research is to  the  and some SDBM,  and the  two-view  several  conceptualization  fundamental  through  semantic  basic mechanisms used in  necessary modelling  is designed  first identify the  data  of  mechanisms integration  the  semantic  current  data modelling  modelling  the  data  concepts  are added. of  these  is and  Finally,  concepts  and mechanisms.  1.3 PREVIOUS WORK A has  considerable  influenced  modelling  the  amount design of  methodologies.  argues  the  related  work.  relative  of  This  advantages  prior  SDBM. section of  research  work  in  Usually, such research work identifies  SDBM  by  previous pointing  work  out  data  modelling  results in new related  to  shortcomings  this of  models thesis  some  area or and  closely  6  In  his  semantics The  paper,  in a mathematical  model  semantics. in  landmark  is  rather  Hammer,  model  abstract  and  Schmidt,  and  databases (Hammer  researchers to  [1976]),  purposes  executable.  Subsequently,  based  on  SDM  DIAL.  However,  TAXIS  applied  the  tool  (McLeod they &  data  type  &  applies the  [1978]).  Berkowitz system  system  mechanisms.  only  [1981]).  a database [1980]).  is  not  the  The  The  data  concepts  is one  the  of  first  concept to  focuses on the  the  logical  data  a very  is  language  type  concept  together  with  limited  concept  database design and  model  programming  integrated  provides  Moreover,  [1974]).  data type  data type  His model  data  specifications.  Hammer  developed  of  understanding  of  Brodie  of  data  number  not  computer  DIAL  which  is  supported  is by  features  from  data  of  types  and  type  and  semantic data models that are most  and for  Galileo. information  uniformly  to  TAXIS system  all the  is  a  database  design  aspects of  and  directly  related to  the  programming  is based on  language  the  data the  concept  data modelling (Mylopoulos  mechanism  language.  Well-known  cannot  be  structure  directly  of  TAXIS is inheritance.  techniques  for  the  TAXIS is not  data  type  et  of  in  in TAXIS everything  is an object  concept of class will be explained in Section 3.3.  a  class which  is  al [1980]). Therefore,  database  fundamental programming  programming  applied. TAXIS provides very simple data structures.  is available. In addition,  of  SDBM  provides  classes. The  a typed  checking  design of  which  concept  have classes such as metaclasses, data classes, and transaction  The  for  applicability  (Weber[1976]).  which  databases (Brodie  data type  modelling  2  [1978]),  modelling  and binary relationships (Abrial  as a conceptual  identified  the  are not separated.  2  framework  we  the  The  The two are  Weber  (Schmidt  of  (Hammer  construction  class  is viewed  investigated  and Hammer designed a semantic data model, S D M , for  documentation  modelling.  Abrial  based on entities  of data expressed in denotational  McLeod  type  Semantics',  develop a semantic data model  specification and verification properties  'Data  Only the  and therefore  languages tuple  data  everything  7  is  grouped  model and  into  simple  may  classes.  Although  because of  be  excessive  such  scarcity of in  certain  approach is conceptual  overloading  the  some  sole  purpose  of  conceptually  different  designer  in  determining  maintains  no  class. is,  clear  from  always  only through  Galileo database  therefore,  Galileo  enforcement to  the  for  of  is  between  of  and  built  do  structure  abstract  of  possible  types  of  the  class.  not  'real'  concept.  Each  and they  the  type  It  compared with many other  with  former interest  world. data  benefits system  construct  have  is  specified  such  has  a tuple  related  are  database  a  TAXIS unique  type.  to  each  of  of  into  static  a strongly  type  That other  Galileo. The  typed  checking.  A  hierarchy  in  type  two  different  extents data  implicitly  and  on  3  types.  the  The  same type  established  database  information classes have  systems. to  be  In  specified  programming  language.  out It  is  type,  hierarchy  through  addition,  data  be the  manually  of  automatic detrimental referential along  with  that Galileo is not a very  complex  semantic data models.  That is, two sets of associated instances. A set of associated instances are usually managed in terms of a class in most semantic data models. 3  an  classes  Moreover,  rules. Such implicitness is believed to  database  desirable  the  type  to  is designed  model.  a  aiways  the  its class hierarchy.  to  different  makes  functions.  data  is  The  can be  processing procedures in Galileo. Finally, it is worth pointing it  is not  directly  their  Rather,  modelling  problems  the  [1985]).  must  hierarchy  reliable  objects  the  it  a class is restricted  type,  utilizes  aspect of  of  class  data  For example, in a TAXIS program  apparently  (Ablano  into  of  another  tuple  It  One  define  and  the  Ablatio  classes  Galileo type  development  constraints  by  is not  different  except  to  to  constructs,  class concept.  associated with  intensional  Galileo, it  is  type  language.  mechanism  Galileo specifies the  the  which are single-valued  programming  With  of  type  is designed  generalization  of  conceptual  have values  properties  circumstances.  latter  separation  Finally, in TAXIS the  objects  and  the  approach  basic modelling  classes  the  a uniform  when  8  From is  their  our  point  underlying  distinction  of view, the  most  conceptualization  between  the  serious problem  of  data  conceptual structure  with these semantic  modelling.  (objects,  They  have  relationships,  not  data  models  made  and properties)  a  clear  and  their  external data representations. W e will elaborate this point later on.  1.4  THESIS  As  OUTLINE  usual,  presented the  The  this  first  chapter  has  research approach to  the  reasons  for  chapter  identifying  the  semantic  modelling  problems  problems  with  some  its  extensions. These problems  3  modelling.  of  summarizes Specific  semantic  a  review  direct  several  of  data  the  of  conventional  associated with  most  models  important  are  not  basic modelling mechanisms for the design of  Chapter the  basic  4  gives  concepts  windows.  The  a description such  chapter  as also  originating  the  research,  be taken, and discussed the related previous work.  next  Chapter  provides  given  of  our  objects,  the  relational  set  features  discussed.  modelling.  up of  It  data  the  focuses  on  model  and  goal for  current  SDBM.  semantic  These features  provide  data some  SDBM.  conceptualization  properties,  discusses  data  the  of  data modelling.  relationships,  specialization  data  It  types,  mechanism  explains  roles,  and  on  the  based  conceptualization and proposes some extensions to this mechanism.  In major  Chapter  parts, the  system. construct English.  Syntax  5,  an  SDBM is  overview type  given  APPENDIX A.  formal  syntax  SDBM  system, the  informally  are also given informally A  of  of  by  is  SDBM using  written  The  window  prototypes.  both through  SDBM,  given.  overview  is  system, and the The  semantics  examples and through in  divided  context-free  into  SDBM of  transaction  each  explanation  grammar,  is  three  syntactic in  provided  plain in  9  Chapter example structures  is of  6 gives highly the  an example  simplified  in  of  using  order  to  model. In APPENDIX  SDBM  to  design  emphasize  the  B, we compare  the  a hypothetical  underlying  database.  principles  database model,  and  SDBM,  The basic  and  the  of  this  data model, TAXIS.  Finally, research.  Chapter  7  concludes  the  thesis  by  summarizing  the  contributions  10  2. REVIEW OF DATA MODELLING  2.1 SEMANTIC MODELLING PROBLEMS OF THE RELATIONAL DATA MODEL There general.  are  serious  semantic  problems  For obvious reasons, the  basically  oriented  level, their  towards  modelling  models but  the  ability  focus attention  associated  with  hierarchical data model  computer  is limited. on the  instead  In this  of  conventional  and the  the  human  paper, we  will  relational data model  network user.  not  data  models  in  data model  At  the  are  conceptual  consider these two  data  only.  2.1.1 TUPLE ORIENTATION The relation  relational  is  a  processing sometimes With  file  purposes they  tuples,  mental  flat  data  not the  transformation  computer  with  has  tuples  (primarily  are  both  model  database  representation,  relation  its  rows".  as  because  directly  from  the  related  the  to  designer  human tuples.  of  the and  problem The  as  its  modelling  Although current  primitives the  tuples  transformation  in  the  primitives, is  user  For  discussion, relationships of this type  example,  in  a relational  of  may as  complicated  Basically,  excellent the  human  such  relationships between relations (or tuples) and conceptual primitives. following  are  architecture  database  domain  primitive.  for  to  objects, by  the  domain. effect to  As part of a tuple.  2.  As a single tuple.  a  their  complex  As will be seen in  the  are not one-to-one mappings.  database, a 'real'  world  object  may  be  represented  any of the following ways: 1.  data  computer),  problem have  a  " O n e difference between a relation and a flat file is that rows have no order in a relation while in a flat file they do. However, this difference is not significant in our discussion.  in  11  This  3.  As a collection of tuples within a relation.  4.  As a Join of tuples from two  suggests  implication relations relation as  a  of  that this  a  tuple  may  fact,  let  us take  a look  at  describing  certain  aspects of  each with  tuples  may describe the research  team  different  member.  aspects  may  not  relations.  represent  of  However,  capable of  the  same  the  an  a relational  employee.  database  another  database  obtaining  object.  employee  employee as a superisor and  relational data model is not just  or  or even more  relation  and keeping the it  is  relational  representation  objects suffers from the 1.  A  property  describes of  properties  of  an  may  describe based  him  on  the  knowledge that they are  impossible  object  several  and  for  it  to  carry  stored data.  relationships  between  same problems. or  a  relationship  an object.  coexistence in  always  of  of  the  For example, a  system  responsibilities such as that for the cross relation consistency of the  The  illustrate  consisting  objects.  management  Therefore,  To  That  by  be  is, a property  a tuple.  represented  may  For example,  embeding  the  represented  as  or a relationship an  one-to-many  relationship  into  the  represented  in  part  of  a  tuple  that  is expressed in relationship tuple  on  terms  is  almost  the  'many'  side. 2.  A  property  example,  or  if has  separate  tuple  he  to  representing  database  relevant  the  tuples  the information  is  be  must a  user might  knows  relationship  COLOR  relation  of  a  a  used  existence  know of  because the  In if  relationship not  be  multi-valued  created. be  may  fact,  property  of  for  many-to-many  the  several  relational  separate  he  database  relationship.  object  tuples  tuples.  PART,  is desired. The  existence of  a relationship,  on this kind of  any  normalization  with  separate  a  For  separate  relationship, worst  may  be  a  implication that  the  such a relationship. O r even if may  have  simply  difficulty  does  not  in  traversing  explicitly  keep  12  Such and  the  a non-one-to-one human  conceptual  relationship primitives  may  database user because he is unable to objects.  The  relationships kind of  primitives among  he  can  For example, the  Notice  inserting two  that  disagreement  some  data  modelling  difficulties  for  primitives  the  relational  are  may be  unit of  much  less  obtained  meaningful  as the  tuples  side effect  creation and destruction  is modelled by two  between and  of  is the tuple  this  in  the  tuples, then it can only be created as  tuples.  certain  depending  relational  cause  manipulate  tuples. The desired result  manipulation.  result of  also  the  directly manipulate objects and relationships  directly  relational database. If an object the  between  conclusions  on  the  of  the  interpretation  above of  discussion  the  relational  may  be  subject  representation  of  to  objects,  relationships, and properties.  Also is  notice  a concept  identified  believe  that  above  anything  that because the can't  by  that can't that  properties,  rigorously  adopting be  designers and  be  concept of  the  as well  relationships.  defined),  view  represented  by  that  should  and users to constraints presented in the  2.1.2  SEMANTIC  not  we  try  different relation. construct  angle,  to  avoid  corresponds to  tendencies  unnecessarily  fact,  the  this  problems  an object  and  However,  in  perceiving  adapt  human  we  objects, designers  relational data model.  data model  has only  one construct,  tuple). This fact is often quoted as evidence of the such  able  defined (In  OVERLOADING  The relational  However,  well  considered an object.  certain to  be  always  is not  have  is not  may  a tuple  a tuple  as users do  We  an object  simplicity  does  we  see  will  This is sometimes  not that  always such  lead  simplicity  simplicity of the  to  the  relational data model.  a  good  result.  can  cause  difficulty  called 'semantic overloading'  is used for many purposes:  the relation (and consequently,  Viewing in  from  a  interpreting  a  (McLeod [1978]). That  it  is, a single  13  1.  To record the existence of  2.  To describe properties of an  3.  To model relationships between  A user may have difficulty used  objects. object. objects.  in determining which of  the  above purposes a given relation  is  for.  2.T.3 ATOMIC DOMAINS By only  definition,  have atomic  relations means  are that  the  required  domain  are associated with this 1.  Multi-valued properties instance, third  data  domains. And to  usually the  relational  to  must  at  properties  least,  in  the  third  entry  relation  can  database behaves properly,  the  normal  of  form.  a  'Atomic  domain'  non-hierarchical. Several  are  difficult  to  accomodate.  are phenomena that are confronted a part  normal  each  problems  restriction.  may  form,  have  the  Conceptually,  first  the  more  relational to  than  one  Unfortunately,  frequently  in the  color.  In  either  introduces  data model  order  multi-valued  real world.  to  remain  an  extra  in  For the  relation  a relation.  approach is not  always desirable.  For example,  the  Conceptually,  we  relation  P(NAME, SIZE, SUPPLIER, has to  relations  SIZE, SUPPLIER) and P2(NAME,  because  would  COLOR)  be broken into two  PKNAME, just  that  non-decomposable and  or adds more attributes  part  specifies  ensure that a relational  be,  be  model  prefer  of  the  the  multi-valued single-table  additional  problems  associated  constraint  between  the  attribute  NAME  of the relation P2).  nature  COLOR) of  COLOR  representation. with  the  attribute  This  referential of  the  attribute. approach integrity  relation  also  (e.g. P1  and  introduces  the the  integrity NAME  14  The have  to  second know  relations  2.  the  created  occur).  Finally,  would  approach  has  maximum in  this  this  only  number  way  domain  approach  express.  For  (domain two  is  whose  major  of  could  limited  very  attribute to  reasons,  we  would  example,  of  objects.  If  are  It  to  computer  automatically,  if  object  simply does not The relational reals, few be  and  data types changed.  to  represent in  addition,  domains.  Therefore,  domains  and  different  properties  values  an  of  of  are  taken  and  The  attribute  DEPT as a collection by the  enforce  referential  allowed.  certain  domain • of  departments  uses very few types of  are static  In  to  relational of  as  data  department objects,  semantic  the  integrity  integrity can be solved relational  data  model  have such a capability.  data model  characters)  specify  problem  domains  we  relation  as a collection  modelling  precisely  For example, the  the view  be viewed in  natural.  constraints.  3.  interested  may  impossible  the  of  could  is  think about  in  could think  we  the  way we  different ways. First, we  latter approach is more helps  the  the  DEPT  values  attributes.  domain  could treat  Alternatively,  we  Conceptually,  objects)  we  character strings. This is, in fact,  model.  null  natural.  the  all,  objects:  relationships.  DEPT in two  b.  like  is close to  STUDENT(STDNO,NAME,DEPT,YEAR),  and  of  can have. Secondly,  (many  model  Under certain circumtances, it For  First  several singled-valued  directly  attribute to directly model a collection of a.  sparse  symmetrical  values  applications.  values a property  be  not  prefer a single multi-valued  Object  very  desired  may  varieties  that they  no  subsequently  the  abstraction behavioural  properties.  have  have  to  have  symbolic strings (e.g. integers,  of  real  prefined  The the  result same  properties.  operations  mechanism semantics  world  is can is  which  These  can  provided  to  not  attached  that  be two  behavioural  not  structure to  conceptually  semantics.  For  15  example,  if  the  part  SIZE  and  the  employee  AGE are  both  defined  on  the  domain of two-digit integers, such illegal operations as AGE greater than SIZE is perfectly  in the  relational data model.  NORMALIZATION  2.1.4  It  has been realized that despite the  particular A  legitimate  care has to  relational  be taken to  database  design  apparent simplicity of  prevent  theory  a relational  called  the  relational data model,  database from  normalization  was  behaving  introduced  abnormally.  for  this  very  purpose.  In a sense, relational data  (e.g.  functional  normalization increases the ability to  dependencies).  undesirable. W e will elaborate this  The deletion  relational  However,  point  normalization theory  anomalies,  and  modification  conceptually  anomalies,  be  eliminated  of  principle  the  of  is  irrelevant  dictates that anomalies, including  basic principles underlying the  and  it  or  even  below.  synthesis. There are two equivalence  capture certain meanings of  minimal  through  relational  redundancy.  insertion anmalies, decomposition  normalization, the  Our  argument  is  or  principle  that  all  these  data  model  does  not  concepts are basically data-processing oriented. 1.  Decomposition  and  handicaped  by  what  structure  data  decomposes associated relations  or with  are  the  are  data  the  its  relational less  recommended structure.  computer  of  is  An  In  normalization at  a 'real'  because the  the world  Neither  addition, theory  conceptual object  does there  itself.  the object being modelled.  user he  are For  level,  is often  normalizing such a relation tends to  correspond to  relational  application-minded  using.  structure.  meaningful  information  process of  which d o not  limited  synthesizes  usually  contains certain and the  its  synthesis  care  example,  since not  in  care  whether  semantic  is  it  problems normalized  a relation normalized  which form  split it into several realtions  16  2.  Equivalence  is  equvalence et  al.  also  is the  [1977],  and Ullman  basically  oriented  towards  the  computer.  the  universal  lossless join  property  under  Rissanen [1977],  Beeri et  al. [1980], Maier  [1983]). To the  human  user, two  The  basic  relation  et  criterion  assumption  al. [1979], Maier  tables are usually not  of (Aho  [1983]  equivalent  to  one  table. 3.  Minimal the  redundency  conceptual  example levels  the of  as well structure should  2.1.5  to  the  ON  a  relationships  (Kent  user-controlled  and  lower  level  that  the  purpose  User-controlled  is  often  different  data  may  not  desired,  angles  processing  of  the  or  at  purposes  be  It  so  at  because the  for  different  the  redundencies.  processing  should  be  side  processing  involved  designed  can  relational  may  in  fact  be  relational terms  of  internal  data  side  The  data  integrity  user.  IDENTIFIERS  of  can  in  facilitated.  names  semantic  or  symbolic  information.  For  references  example,  by symbolic names that are chosen at the  objective  in  database designer  and  hidden from the  user-controlled  amount  user  efficient  and completely  model,  user's  data  system  on  of  be  achieved  consciousness. Kent  [1979]). See also (Date  identifiers  data  kinds  manipulation  the  data  the  for  some  USER-CONTROLLED  expected  from  level, but  so that analysis and design on the  computer  considerable  selection  1.  is  are all represented  the  this subject  and  for  relational  redundancy  viewed  even  considerable  constructs  the  data-processing  data  be  eliminate  point  as interpretation  convey  careful  is  manipulation  the  redundancy.  key  meaninful  RELIANCE  Whether  only  there  be left to  In  can  The  may  Furthermore,  new data  Obviously,  at  Conceptual  person  detail.  introduce  semantically  level.  same  normalization  normalization.  is desirable  depends  on  has given  the  an  [1983]). The problems  are  used  objects  and  user's  discretion.  database  designer's  extensive  discussion  of  associated with reliance  on  are summarized as follows. symbolic  identifiers  may  be  subject  to  changes.  For example,  a  17  supplier number any of  more  and  a journal  such  may change for some reason. A person may not decide  to  change  name. W h e n  changes,  though  conceptually  insertion  operation  following  a  problems  with  approach.  First,  deletions  of  symbolic  may  semantic  be  system  to  tell  replaced  him  number.  Such  kind  may  if  we  with  a  be  have  usually  references  called  not.  Consider  want  to  supplier database  for  know  information when,  the is  for  an  object  so  the  the  who  matter  generated.  result  in  references  which  instance,  is  the  we  circumstances, a 'dangling reference' does no  Let contracts  us consider is to  a different  situation  there  a  For do  has  with  the  certain  each not been  an  least find  two  all  the  insertions and  is no  way or  for we  the have  except  report  and  part,  for  This  is  sometimes we  whether  deleted  his  on,  if  care  bankrupt.  and  insertion,  objects.  desirable  goes  from  Under  only the the such  harm.  be recorded. Obviously, a contract  Of course, we only consider the static state of transitions are not within our consideration. 5  proper  non-existent  or  where  still exists. In this case, a 'dangling reference'  to  properties  obviously  supplier  user  at  identical  case.  database  are  number  to  as keys,  allowed  deletion  sometimes  part-supplier  the  of  when  be  used  person's  has  is to  in  the  For example,  name  accomplished through  that  result  his  see a change  are  not  There  for  do  is,  be  difficult  person  the  usually  operation.  changed  supplier still  are  is  as  only  reference'  example  who  for  ambiguities  could  'dangling  it  possible to  identifiers  has to  deletion  introduced.  different  semantic  symbolic  change  Second,  example, personnel archives Symbolic  of  identifiers  done.  ambiguities  is also quite  legitmate,  data model. This  this  It  user-controlled  relational  occurences  2.  it.  like  the  information  can exist  is highly  the system to  on  purchasing  only if the  supplier  undesirable .  be modelled.  5  Dynamic  18  The  problem  is that the  relational  data model  provides no  alternatives  for  specifying such constraints. 3.  The  database designer can have  relation  or  and the the  attribute  perception  choice  perception  of of  interpretation 4.  because of  identifiers,  arbitrariness  In  reality,  can  different  instance,  Robert  Different  identifiers  and  part-#.  control  strong  interaction  conversely can  create  serious  problems  key needs to  Jackson  may  and  in  the  a  the  for  identifiers  objects  can  also  affect  can quite  a  different  affect the  semantic  be  Bob  relational  above  used  when,  to  for  conceptual level.  example,  represent  Jackson could different  data  real  arbitrary' on the  a user  view  be derived.  may even be from  Because the  between  identifiers  result  identifier  attribute.  identifiers  joinability,  selecting a proper  being modelled. Perception of  latter  or  in  keys is made, it is often  that uses an alternative 5.  the  and  The  of a relation  Even if a choice of This  of  objects  objects.  difficulty  model  world  refer  the to  the  domains, for only  possiblities  same object.  example,  depends must  same  on  be  For  person. part-name  domains  banned  in  to the  relational database.  2.1.6  GENERALIZATION/SPECIALIZATION  The relational statement  also  data model is not  applies  to  generalization/specialization. two  the The  an effective  modelling problems  of  representation  the  involved  important  can  be  tool  in  some cases. This  conceptual  categorized  into  mechanism the  of  following  parts. 1.  The  relational  by  introducing  data  model  extra  can  relations.  handle But  certain this  is  machine-controlled both  artificial  specialization and  6  potentially  Machine-controlled specialization refers to specilization that can be obtained through evaluating some expressions, for example, first order logic expressions, against a group objects, usually in a relation. 6  of  19  problematic  when  data  integrity  is  concerned.  In  fact,  as  the  number  of  specializations increases, the approach can result in unbearable data redundancies. For  this  view  reason, the  concept  can  concept  only  of  provide  relational limited  model the additional specialities of 2.  It  will  be  controlled  very by  difficult  the  User-controlled  user  case,  we  to  be  'wholesaler'.  Therefore,  we  still want  the  to  it  However,  is  that  can  by  the  to  only  the  impossible  to  manually  maintain  the  For  some  data  to  But  in  the  information is meant at  integrity  the  and  model.  example,  extra  classify it. semantic  specified  relational  necessary. have  be  beings can understand what  have  computer  often  want  Probably only human  used.  For example,  modelled  is  wholesalers.  be  a subset with the relational view.  specialization  may  we  help.  for  specialization  PART-SUPPLIER  view may  about here  same  constraint  by  time, that a  wholesaler is a supplier.  2.1.7  REQUIREMENT  Kent horizontal the  identifies  HOMOGENEITY  two  assumptions  and vertical homogeneity  situation  where  homogeneity same  OF  kind  refers of  each tuple to  the  of  in  in  data (Kent  a given  situation  information  underlying  where  each  tuple.  [1979]).  relation in  the  a  representation,  Horizontal  homogeneity  contains  a relation  For  relational  real  the  a given world  namely refers  same fields; and attribute  user,  allows  these  to  vertical  only  the  constraints  are  undesirable, because in reality counter examples are abundant.  For instance, a patient patient, make  we much  noticing becomes  obviously d o sense  that more  in  relation may have an attribute  not  want  this  to  have  different  this  case,  permitting  problematic  when  attribute  at  relations  for  null  values  there  is  all. O n male  For a male  PREGNANT-OR-NOT.  the  and  might  female  cause  nonhomogeneity  other  hand,  patients.  interpreting  associated  with  it It  does is  worth  difficulty. an  not  It  attribute  20  which  we  might  want  to  use as an  often  be used as employee identifiers.  might  not  quite this  assigned either  possibly situation  relation,  have in  creating  to  employees or to formats  number  of  new  uniform  of  ways  departments,  representation is being new  unit  with  an  only  which  modelled. More even  bears  awkward  as  little  The  adding However,  use two data  identifier  format.  relational a  new  none  data  model  attribute, of  departments can  creating  them  handle a  provides  new  a  good  one for employees and another  integrity  might  For example, company cars  Here employees and  attributes,  resemblance to  problems  different  departments.  etc.  introduce  may  problems  the  but  conceptual  arise when For a more  we  try  create  structure  to  detailed  also  of  a  what  assign cars to discussion on  a  this  [1979]).  AGGREGATION  The another flow  not  structure  subject, see (Kent  2.1.8  we  such  numbers  corporation, some employees  phenomenon.  identifiers.  identifiers,  conceptual solution. For example, if we for  example, social security  [1979]).  is also a c o m m o n  different  a  For  But in a multi-national  have social security numbers (Kent  Vertical nonhomogeneity can be  identifier.  relational  important  data  model  data abstraction  diagrams obtained from  relationships  is  between  not  effective  process, aggregation.  information  different  a very  levels of  tool  we  For example, when  needs analysis, we a data flow  when  obviously want  want  to  model  recording to  diagram. Here, a level(n)  preserve  data the  diagram can  be viewed as an aggregation of several level(n + 1) diagrams.  With the  relational data model, a special relation R( D I A G R A M , S U B D I A G R A M )  may of  be  created. In  DIAGRAM.  each tuple  of  this  relation,  SUBDIAGRAM  is an immediate  subdiagram  21  There modelling are  are  in  to  levels  are  level  of  of can  be  it  our  its  maintained B  easily  is  a  relationships  First  between  associated with  of  all,  different  no  such  difficulty arises because diagrams  attributes.  the  of  Finally,  in  to  However,  attributes.  relational  subdiagram  violated.  approach.  be  unique  by  the  this  may  example,  own  All  with  that  homogeneous  the  discussion  should  be  mentioned  could  be  expanded  paper  has  Moreover, may  can  neither it should  not  such  different  explicit.  For example, it is awkward  discussion  criteria  In  has  and  conclude  discussion  model  and  associated  C,  it  Thirdly, model.  then  A  is  cases  express the  is  For a  example,  information  query,  at all each  integrity  if  A  of  is  C.  retrieval  'find all the  are  that  semantic  subdiagram  levels  levels  common  certain  data  certain  different  the  a  This  will  be  subdiagrams  of  A'.  To  so.  direct  have  be  B  difficulties  Secondly, specialities  to  cannot  inconvienent.  This  data.  aggregation  constraint  further  not  assumed  subdiagram  model,  is  four  accommodate.  constraints  diagram  least  process  hidden  difficult  at  as  be  so  be  interpretetaions  by  enough  the further  about  and  problems  is  looked  the  from  are  of  all  nor  different  subjective  the of  sense.  For  example, primary  intention  the  angles. and  data  any  composite  above criticisms  generally  relational  in  points.  with  them  some  the  exhaustive listed  associated  that the at  problems not  accommodate  naturalness  by different  list  elaborating  mentioned  when  modelling  above  space to  also be  simplicity  semantic  that  made  sound  of  The a  keys. to  do  relational  data  Some of  our  may  subject  to  people.  2.2 SEMANTIC EXTENSIONS TO THE RELATIONAL DATA MODEL  Ever  since  Codd  Data Banks' ( C o d d scrutiny the  of  database  previous  published  [1970]), the  his  article  relational  researchers. There  sections  but  also  many  'A  Relational  data model  are not  only  extensions  Model  of  Data for  has been subjected considerable  which  aim  at  criticisms  to  Large Shared the  substantial  as presented  enhancing  the  in  semantic  22  modelling  power  commenting  of  on  this data m o d e l . In this  how  these  section, I will  extensions achieve this  goal  briefly  and what  with the approaches are. This section will only  cover the  direct  data  the  construct  model.  model  are  more  detail.  2.2.1  EXTRA  To model of  By still  'direct relations  is too real  choices  extent,  world,  in  the  the  many  correctly  solving  the  semantic  to  be  add  some  fact, much work Astrahan [1976],  In  mean  The  relational  this  to  next  designer  possible  alternatives. the  integrity  kinds  of  constraint  additional  problems  extensions of  of  the  semantic  of  approach,  integrity  associated  the  relational  extended  data  data  modelling  R (Astrahan  which  handle both  uses  query  static restrictions,  dynamic restrictions,  Although  in  as  the  et  al.  SQL  to  the  user  relational  data  constraint  e.g. attribute SEX can only  variety  and  difficult  usually  faces  a natural model  way  appears  Eswaran  it.  In  [1975],  [1976]).  there  express  the  great  mechanisms to  et al [1974],  specified  [1976])  because  subtle  by  a predicate  database schema, and enforced  language  automatically  is an  constraints.  has two  assertion  integrity The  by  the  constraint  system  can  values 'F' and ' M ' , and  e.g. the specification of a trigger.  this approach proves to  integrity such  the  very  database  (Stonebraker  are  capture  database. Therefore,  integrity  constraints  problems  make  the  of  to  Hammer & M c L e o d  For example,  System  model  the  semantic  DBMS.  in  of  problems  [1975],  above  somtimes  in this direction  Hammer & M c L e o d  the  Similiarly,  intension  in the  model  reviews  has  has to  Assertions can be stated  semantic  chapter  model  database  has been done  type  data  facility.  subsystem  basic  use such a general  interpreting  of  to  tuples.  general. In order  among  difficulties  and  we  the  by  CONSTRAINTS  some  the  extension',  summarize this work  problems, those  it  can  associated  be very powerful  not with  solve  many  the  tuple  and flexible  other  problems  representation.  in dealing with some of  the  relational  Furthermore,  it  data is  a  23  piece-meal  approach.  unnecessarily be to  2.2.2  Constraints  and  increased conceptual  let more constraints  SEMANTIC  the  data  difficulty  be directly  CLASSIFICATION  in  model  using  are  the  separated.  model.  can  investigated  This  be  the  OF  &  2.  Those that model multi-valued  3.  Those that capture relationships explains  However, as  relational  data  eliminate  to  various  as  how  in  out  by  pointed relations  model  ways  in  should  capturing  any previously identified  THE  important  Chen  [1976].  been  traditionally be  more  its conceptual the  Swenson  helpful  view.  model.  of  view  it  As far as the  Except for  Schmid & Swenson [1975]. conceptual  view  which  stimulated  considerable  is  which  [1975]  relations  Wiederhold  [1977]  categories: objects).  objects.  used,  can  be  it  does  [1978], nor  semantic  does  it  associated with not  extend  information.  some  profound in  relational  extension  from  two  of  really the  semantic  provide  power  Moreover,  minor  and  the  work  relational  data  angles, 1) its  it  any  of  the  does  not  it  part  far-reaching.  done  It  entity-relationship  is very of  the  is  this  ER model  model.  ER model  the  To  some  and  view  it 2)  significant  proposal  is its  conceptual  has  However,  is nothing  close to  approach.  by Peter  data structure  is concerned, there  differences, significant  is the  model. The original  different  data structure  the  data model  entity-relationship  However, the  interest  and  objects.  McLeod  the  as a direct to  among  be  classify relations so that some  objects (autonomous  characteristics of  more  is called the  viewed  would  APPROACH  extension  His model  approach  to  problems at all.  ENTITY-RELATIONSHIP  Another  about  Schmid  Those that describe the existence of  guideline  would  captured.  classification of relations into the following  approach  lead  RELATIONS  1.  primitives.  2.2.3  clearly  better  may  expressed in the data m o d e l .  The second approach is characterized by its attempt to semantics  A  This  of  underlying that  extent,  has many  24  recently model.  proposed It  semantic  is also very  data  interesting  database tool, has gained wide  The major 7.  models to  can be  notice  representation  Rigid  The structure  distinction  aid, be  of the ER model  originally  of  viewed  sets which  the ER  proposed  as a  is the same as the relational identified  for the  them  and  Relationships.  from  participating  The  ER model  explicitly  in further relationships. This  necessary nor convenient.  Richness.  The ER model  and flexible  as relationships.  In fact,  to  as follows:  flat table. Therefore, problems  Objects  and prohibits  is neither  but not rich  either.  between  relationships  3. Lack  ER model,  linked  still exist.  Distinction  defines  indirectly  acceptance in system analysis and design (Chen [1981]).  data model, namely a two-dimentional  2.  the  or  problems associated with the ER model are identified  7a6/e Representation.  tuple  that  directly  the value  contains atomic  It  in its original  enough. does  form  For example,  not  allow  of entity attributes  it  entity  can only  is a g o o d does  sets  database  not allow  to  attributes  be attribute  be taken  from  design to  domains,  so-called value  symbolic strings.  2.2.4 CONCLUSIONS In data  this  model.  section,  W e have  In conclusion,  semantic  data  relational  data  modelling  tool  modelling, model.  briefly  although it  None  is  reviewed  this  earlier  handicapped  of them  to  is sufficient  some  direct  research some to  to capture the semantics of real world  extensions  has contributed  extent  by  its  of  the  a great  close  tie  be used as a satisfactory applications.  relational deal with  to the  conceptual  25  3.  This chapter is does not focus principles  that  REVIEW  devoted  to  OF  SEMANTIC  a discussion  DATA  of  semantic  on individual semantic data models, are  common  to  many  of  MODELLING  these  data modelling. The discussion  but rather on the data  models.  In  basic concepts and  the  following,  these  concepts and principles are discussed in turn.  3.1  BASIC  The objects.  GUIDELINE  human Database  application  into  transformation  conceptual  primitives  design  a  is  structures  but  in the  objects,  transformation  particular reverse  are  to  a  from data  direction. One of  properties,  and  the  conceptual  model.  Using  the  objectives  relationships  between  representation  a  database of  the  of  is  an  also  a  data modelling  activity is to reduce these mental transformation as much as possible.  3.2  OBJECT  ORIENTATION  In semantic data modelling, 'object' is considered the most basic modelling construct. An  object  have been  is  any thing that  used to  & Smith [1976], Kent  [1979],  instance 'object'  in  us.  In the  mean the same thing. Abrial  Shipman [1981],  and  Codd  (Mylopoulos  is used  interests  and  Brodie  [1979]  use  et  [1980]),  al.  in this paper as the  'entity',  [1974],  the  others  (Tsichritzis  terms  Berild & Nachmens [1977], Smith  [1984] use while  and  most  data modelling literature, different  term 'object'.  choose  the  & Lochovsky  Chen  [1976],  term  'token',  [1982]).  The  for term  basic modelling construct. The term 'entity' is  used to mean the real world thing to be modelled.  Based  on  the  observation  implications for data processing,  that  objects  may  be  different  researchers generally classify  in  objects  nature  and  in  into categories.  their Abrial  26  distinguishes  between  represents  physically  while  a  an  abstract  between  a  independent on the the  existing  thing,  represents  abstract for  objects  a concept  a  of  other  objects, whereas the  of  some other  a regular  (Codd  [1979]),  object  object  a  such  and  any  weak  (Abrial  example,  regular  deletion In  and  object  existence of  objects.  concrete  (Chen  [1974]).  part,  a  as date. [1976]).  existence  concrete  supplier, Chen  A  of  A  object  or  an  employee,  makes  the  distinction  regular  a weak  object object  may  is  exist  dependent  (or objects). The data processing implication is that  object  may  cascade  Codd  proposes to  to  cause deletion  classify objects  of  into  all the  related  weak  characteristic, associative,  and kernel objects.  To are  human  the  world  characteristics  entity,  is that  beings, the of  properties  there  should  existence of  that  object.  are their  be  If  an object we  define  is manifested  by  attributes  characteristics  conceptual modelling  a one-to-one  as  counterparts.  correspondence  between  its  properties of  O n e important  entities  of  which  the  a  real  principle  real  world  and objects in the database.  We  should  construct.  An  emphasize that  object  is  correspondence,  which  This  indicates  principle  correspondingly in the the  model  principle  must  cannot  be  that  be  be  well  implementation integrity  paper the  controlled  the so  such  term  modelling  'object'  world.  an  entity  in  the  than  at the  conceptual level.  one  The in  'real'  order  entity  to  consistency principle  as insertion  principle this  it  of  definition  world,  the  as a  there  Of  'real'  deletion  one-to-one of  objects.  should  be  world.  Finally,  in this  redundancy may  of  different  access  course, such redundancy  synchronization possible  modelling  Moreover, each object  Physically, certain  required.  and  makes and  in  used  achieve optimization  same data may be that  is  representing that entity.  more  one-to-one  problems  the  over-emphasied, is inherent  For example, in  copies of  this  of  for  represent  desirable.  of  this  model one object  not  strategies, multiple  serious  entity  is being discussed only  sometimes  must  an  in  to  are  ensured.  eliminate  anomalies, and  to  some some  The very extent  27  the  referential  Another set-oriented  referenced its  the  important  the object  concept of  data model  distinguished  as  integrity problem, of  by  some  directly  symbolic  collection of  such as the intrinsic  as a unit.  name.  other  This  relational  important  avoids  the  the  objects  problem  serious data modelling  referential  object  no  a final  is  as  data  directly  tuples.  following  problem,  thought  for  modelling  data  the of  a  identity  by  does not  aspect  allows  any  While in a can only  object  an object  is not  unique  is that  relationships  specifying  to  that  the  an  to the  identifiers  come back to this  be be  same and  point  a  later  are asserted elimination  object  of  cannot  be  relationships.  semantic  the  (tuples)  This contributes  orientation,  semantic  models, while  is that  identity.  objects  unchangeable  identifiers.  object  and  abstraction  object  in any  as  identity  of  example,  data modelling  in the  The  on  is the object  problems. W e will  symbolic  longer participates  mean that conventional  objects  their  comment  orientation  conventional  of  integrity  deleted until it  As  instead  object implication  in Section 4.2.3. A further consequence of between  orientation  relational data model two  properties,  An  data model.  data  of  should  be  modelling  deal with  data former  it  it  semantic  principle,  that this  although does  objects. The difference  modelling does  clarified  is  that  indirectly  data  the  latter  through  modelling  is  not  between  manipulates  constructs  discussed  such  in  the  section.  3.3 DATA ABSTRACTION Data relevant  to  either with different levels  abstraction the  abstraction  respect  detail. in  a  application  applications  of  is  to  the need  These  process being  in  irrelevant  modelled are retained.  applications different  needs  which  have  databases. Furthermore,  at hand  details.  to  Different  undoutedly like  or  details  suppressed  Relevant details can be a particuliar  users  motivated  any other  are  also the  abstraction  group need  explicit  to  of  and  details  understood  users. Clearly, access  application  different of  data  process, data abstraction  is  28  a very As  effective  soon  from  way  as we  them  of  reducing  understand  and then  the  a group  represent  mental of  load  on  phenomena, we  such abstraction with  with a symbolic name. Thereafter, we  only need to  going  back  information.  most  semantic  through  all  data  the  detailed  models  to  both  provide  abstract  a concept refer to  The  data  database designers and users.  basic  abstraction  the  revelant  which  information  is usually  identified  this symbolic name instead  of  mechanisms that  in  are:  are  classification,  used  aggregation,  generalization, and a s s o c i a t i o n . 7  CLASSIFICATION  3.3.1  As mentioned It  is  noticed  properties. object  that  Based  or  which  common  properties  other  may  are used as basic share  common  classes  is  for  considered  some  properties,  short.  as  a  shared by objects  properties  relationship  these  objects  This  Precisely, classification is defined  objects,  the  objects  on  classes,  classification.  before,  of  between  these  a particular  higher  are  model  particularly  we  objects  can  group  process  as a form level  the  of  By  type  the  real world.  some  into  categories  in  classification,  of objects  currently  is  the  —  called  a collection  of  relevant  in a class while  Classification establishes an  objects  common  (mechanism)  abstraction  object.  by the  ignored.  collection of  to  commonalities,  grouping  are kept  objects  constructs  all  instance-of  existing in the  database  and a class denoted by the name of the class.  The term 'class' 'object  type',  etc.  has several synonyms such as 'entity set', 'entity class',  Unfortunately,  'class',  'set',  and  'type'  do  not  usually  thing. To avoid any confusion I will use 'class' through  this paper to  classified  classes  objects . 8  One  of  the  distinctive  features  of  This is not to be confused with the association between two abstraction mechanism will be explained in Section 3.3.4. 7  is  that  'entity  mean  the  type', same  mean a collection they  are  of  persistent.  sets. Association as an  The concept of class defined here can be found in various semantic data models proposed recently. As will be seen in the next chapter, the class concept is less powerful than the S D B M window concept in terms of data modelling ability. 8  29  Namely, they exist even after a program invocation has terminated.  Some result  semantic  an object  class  its  instances.  properties.  rather  CHARACTER-STRING as  models  also  allow  classification  is a metaclass. A metaclass is an abstraction  share some c o m m o n to  data  Note  than  be applied  to  classes. The  of a collection of object  that the properties  instances of a object  object  class  ALPHBETIC-STRING  Notice  here  that  a  classes  that are to be abstracted  class.  with  specific  to  A n example  and object  character  string  is  which belong  of a metaclass is  class  NUMERIC-STRING  not  an  instance  of  CHARACTER-STRING as defined.  AGGREGATION  3.3.2  Sometimes would  rather  abstraction form  of  a relationship  ignore  these  among  objects  several  objects  and refer  only  may become  so important  to the relationship.  that w e  Clearly, this  is an  process. It is usually called aggregation. Formally, aggregation is defined to be a abstraction  in which  a relationship  among  objects  is regarded  as a higher-level  object, with lower-level details suppressed.  Thus, with this abstraction, an object relationship an  object  between  may be viewed in two different ways: first as a  an identity and a set of lower-level objects (attributes) and second as  in its o w n right  (Date  [1983]).  Some  semantic data models. There are basically three 1.  Cartesian aggregation which example, object STUDENT-NO,  refinements  of aggregation  are made  forms of aggregation ( C o d d [1979]).  views an object  as an aggregate  of properties. For  STUDENT may be considered to be an aggregate NAME,  in  SEX, and ADDRESS.  Aggregation  of this  of  kind  properties  is originally  addressed by (Smith & Smith [1977]). 2.  Part aggregation  which  views  an object  as an aggregate  of  its  example, a P C may be viewed as a part aggregation of a monitor, a  C P U and a  disk  drive.  This  aggregation  can be  applied  parts. For a keyboard,  recursively  to  30  generate  a part  aggregation  maintain  relationships  hierarchy.  Part  objects,  i.e.  among  aggregations focus on describing objects 3.  Cover  aggregation  possibly some may  refers  heterogenerous  kind  of  of  aggregation definition  its where  of  into  is  not  the structure  aggregation.  machine-understandable.  of  For this  cover  well  is  still  another from  kind  of  the  concept  a collection  For example,  This  the  Semantic  force  and personnel.  is  may  of with  a task  First  is explicitly  grouping  reason,  Cartesian  in accordance  aggregation.  its members  aggregation,  the aggregation  of  object,  defined.  user-controllable grouping (Hammer & M c L e o d  There  together  [1983]).  of  Secondly,  whereas  of ships, planes, tanks  characteristics  useful to  properties.  a higher-level (Date  are primarily  hierarchies,  by their  aggregation  members  part  the grouping  criterion  as a cover  are two important  structure  to  objects  membership  be viewed  There  which  aggregations  of  all, the  unlike  Cartesian  specified or  Data  may  in the not  Model  be  calls  it  it  is  [1979]).  statistical defined  aggregation,  here.  This  though  somewhat  different  concept  is usually  supported  in most data models by providing some built-in functions, e.g. M A X , M I N , etc.  3.3.3 GENERALIZATION/SPECIALIZATION Generalization considered viewed  is a form  at a generic  as  generalization,  a  level.  generic many  of With  object.  individual  abstraction  in which  the generalization  This  abstraction  differences  between  a set of  generalized to a more  in their  differences.  generic  object  class  establishes objects  STAFF,  objects  mechanism, an object  this is similar to generating a superset. For example, object be  similar  an  is-a  is also  may also be  relationship.  By  are suppressed. In set theory, class D O C T O R  and NURSE can  if we are not particularly  interested  31  Generalization subclass  hierarchy  hierarchy  properties  the  Therefore of  data  and  be  when  corresponds  knowledge.  rigorous  can  the to  it  one  modelling.  data  that often  is  database widely  well-bounded,  specific  indicate the for  the  are  term  characteristics The  this  almost  totally  ignores  concept new  relevant of  the  should data  classes.  This  and  process  our  one  models  hierarchy. the  be  This  called  object  acquire  of  fail  is  importance  specialization, the  object  classes.  downwards, and  reverse  Because  a  the to  inherent  provide  a  especially true  of  of  generalization.  of  generalization,  database  i.e. from generic  'specialization'  are  the  database.  In  with  respect  the  to  other  application  concepts to  distinguished  classes are defined. They have no  are inherent of  to  also  Cartesian aggregation.  of  'generalization'  symmetrical  extension  we  conventional  modelling  can work  structure  exactly  ways  for  hierarchy,  applied  the  is the  in which  conceptual  important  is  However,  'generate'  The  order  specialization important  to  generalization  that generalization  we therefore  concepts.  the  a  mechanism  focus exclusively on  design, it  used  specify  surprising  which  Theories like normalization  In  of  mechanism  model  to  generalization  is not  consistent  relational  repeated  different  words,  conceptual  more  only  of  the  extension  and  Several  in specialization. There are at least the following  specialization is a subset  to  implications  generalization  structure.  is  of  the  very  four: generic  class. The if  specialization inherits class  PERSON  property  height  has  too,  all the  a if  properties  property  called  from the height,  class CHILD is specified  generic class.  then to  be  class  For example,  CHILD  a specialization  will  have  of  class  PERSON. Values  of  values.  For instance, if values of  10, The  then  inherited  values of  properties  CHILD'S height  specialization may  a GUARDIAN  must  property  have which  be  specializations  PERSON'S must  additional  height  of  class PERSON  generic  are specified to  also be less than  properities.  the  have.  less  than  10.  For instance,  may not  be  property  class CHILD has  32  ASSOCIATION  3.3.4  This is a concept which  a  collection  association, the its member  introduced  of  member  properties  objects  Brodie . is  considered  are explicitly  At  not  the  exist  set  at  association of of  object  In  of  level,  useful  member  object  the  a  higher  differentiated  level from  class STUDENT has property  set  which  directly  of is  class  related  I  section,  even  Here  object  PERSON. to  have  the  abstraction set  the  object.  in By  properties  of  necessary  say that,  in  of  PEOPLE  objects  person  basic  generalization  and  association.  a  property  properties  STUDENTS  but  is  an  PEOPLE is an association have  properties  whereas  such  PERSON  as have  objects.  four  for  have  respect,  as a whole,  reviewed  constructs  STD#, and  its member  this  may  SNAME,  may  are related to  Here,  set  briefly  aggregation,  we  STUDENTS  example is that set object  related to each individual  classification, or  level.  objects. Another  instances  this  namely  the  student  POPULATION properties  as  of  objects.  STUDENT-REPRESENTATIVE and AVERAGE-AGE which do  Association is a form  9  of a set object  For example, each member AGE.  by M .  powerful  concepts  data  of  These  data  abstraction,  concepts  modelling  tool  —  and  how  semantic  the  provision  provide semantic  hierarchy.  3.4  SEMANTIC  Another constraints  constraint  important  are  representing  INTEGRITY  aspect  modelled.  semantic  CONSTRAINTS  Data  integrity  of  data  models  models  differ  constraints.  what  dramatically  This  section  in  reviews  major  of  integrity  means  semantic  concepts. Association is one of  for  integrity  issues in semantic data modelling.  He claims that sets are fundamental modelling primitives of his set concept (Brodie [1983]). 9  is  three  33  A database can be viewed as a repository be  viewed  as  a  collection  that may happen in the a methodology viewpoint.  for  As  of  constraints  of  that  data values and a database schema can  restrict  database. Therefore, to  values  some extent,  specifying constraints. The following  will  be  seen,  this  view  that  clarifies  may  a data model  discussion will  the  exist  difference  and  changes  is nothing  but  be pursued from  this  between  conventional  data  modelling and semantic data modelling.  In conventional concepts. world  data modelling,  Usually, a database schema is more  situation,  generated  while  from  integrity  a given  constraints  schema to  'semantic  integrity constraint'  accuracy, correctness, or validity  With  with  the  data  constraints  data  model  be  must  be  must  specified  constraints .  For  assertions  explicit  10  implicit  are  constraint  example,  is  possible the  database  constraints.  into meaningful refer  to  reflecting states  The  structures.  separate the  that  former  In this  any database constraint  real  can is  be  more  paper,  the  that ensures  of data in the database.  different  semantic  Some are  within some  the  a  relation  kind  of  constraints  constraints. one  meet  accurately  are  integrity constraints  inseparable  part  of  may  have  a data  third  can  be  that  an  inherent  constraint  that  The  is  are kind  mechanisms  specified of  derived  constraint.  with  constraints from  either  They  relational  Constraints  are  certain are  different  model.  of that data model. For example, that tuples in the  unique using  that  constructs  model.  are called inherent  the  is used to  a specific data model,  relationships  integrity constraints  concerned with  restrict  those  concerned with organizing modelling term  database schema and  called first  implicit  explicit  order  logic  constraints.  inherent  that  and/or  An  explicit  constraints.  Viewing we  see  integrity 1 0  that  a data model one  major  constraints  In some literature,  as a methodology  difference  have been  between  built  this kind of  into  for  data  organizing models  data models. The  lies  semantic in  what  relational  integrity and  data  constraints are called semantic integrity  constraints,  how  semantic  model  has very  constraints.  34  few  inherent  constraints. Most semantic integrity  constraints  have to  be externally specified.  Often, many kinds of. semantic integrity constraints cannot possibly be specified.  To have  overcome  the  modelling  proposed many external  shortcomings  of  semantic modelling  the  relational  facilities. W e  data  model,  researchers  have seen examples of  this  kind in INGRES and System R.  With  most  incorporating course,  semantic  in  there  the  data  semantic  is a trade-off  models, data  in  however,  models  doing  a  so. O n  more  greater one  data  semantics  variety  side,  we  of  inherent  are  modelling.  They  of  semantic integrity constraints are of  are  domain  constraints,  cardinality  captured  by  constraints.  Of  increasing our  model certain data semantics. O n the other side, we are narrowing the  Several types  are  to  modelling realm.  special interest  constraints,  ability  to  semantic data  uniqueness  constraints,  referential constraints, and inheritance constraints.  A the with basic  domain  literature, the  constraint  the  term  adjective  mechanism  abstraction  refers  'type  the  restriction  constraint'  'semantic'  provide  employed  between  to  by  properties  is also used.  facilities  these  and  o n values that  to  models  primitive  Almost all the  enforce is  types  a property  to  these  provide  such  as  data models  kinds  of  additional  integer  can have.  and  In  prefixed  constraints.  The  levels  data  of  character.  In  this  on  the  way, underlying domains can be associated with distinct semantics.  In  database  literature,  a  cardinality  cardinality of  relationships between  that  related  can  be  to  an  constraint  usually  refers  classes. Cardinality is the  object  in  another  object  class  to  a  restriction  number of objects in an class and  vice  versa.  This  type  constraint is often extensively studied in semantic data models that directly deal with relationships, for  example, in the  Binary Semantic Data model  (Abrial  [1974]). It  show that uniqueness constraints are a special case of cardinality constraints.  of  binary  is easy to  35  Referential restriction  constraints  requires  referenced objects new object must  or  that  (Chen  example,  In various  is automatically  object  on  has  an existing object.  the  'dangling  referenced  references'  other  extensions  in  refers  the  to  all the  most  (Codd  relational of  referenced  not  or  (Codd  properties its  developed  constraint  [1979])  being  all of  a  objects  take place. This  [1979], Date  data  superclass. This  semantic data  This  referenced  dependency  of  .  then  data model, some referential  inheritance of  must  1  by insertion  be allowed to  constraints  properties  recently  In these models, the  should not  constraint  handle this type  constraint  enforced  to  object  1  objects,  U p o n insertion, all the  removal, the  and deletion  existence  each subclass inherits  and Galileo.  existing  restriction  database, and upon  called  inheritance  the  exist. 'Dangling references' may be caused either  rules have been developed to  An  to  Otherwise, insertion  also  [1976]).  an  by removal of  by any object. is  if  must  be already in the  constraint  refer  constraint integrity [1981]).  abstraction.  kind  of  For  constraint  models, such as TAXIS  is specified whenever the  database structure  is  specified.  The different  approach taken from  primitives,  recent  abstraction system. (Rowe  data  and constraints  usually approach them  APPLICATION  In  conventional  structures,  data models  3.5  the  by semantic  OF  years, more  capabilities  Systems  DATA  such  data models  models. within  Most  in  modelling  semantic  an integrated  data models  framework,  is  considerably  present  while  the  modelling  conventional  separately.  TYPES  and  developed as TAXIS  more in  attention  has been  programming  (Mylopoulos  et  languages al  [1980]),  paid to  to the  Galileo  [1979]), and INGRES (Stonebraker et al [1976]) all provide  types. This section gives a brief  the  application  database (Ablano  of  data  management  [1985]),  some applications of  RIGEL data  review of such applications.  ^ h e n we say 'A is referenced by B', we mean that to A must exist if B exists in the database. 1  constraints  maintain  integrity of a database,  36  3.5.1  USE  OF  THE  The concept the  purpose  DATA  of  of  Recently, this  around  data  amount  especiallly  the  data type  aggregation  and  data  types  also specify  One  of  the  that  example,  semantics  being  distinctive  advantage  of  behavioral  type,  semantics,  of  view,  which can be specified by the for  the  verification  of  desired structure  The  the  use of  developed  in  concern  data type  programming  type,  of  provided  data  to  terms  of  types  are  be  some  extensions  directly  as At  provided  constraints, can  to  to  are:  centered  generalization,  for  same data  can  data  the  time,  objects.  be  is that defined  established  Another  database  design  is  that  embedded  within  a  data  a database design. From  types  with  type.  the  operations,  data  is  the  be  of  mechanism.  database specifications  semantics of those  such  for and  development  structures  participating  concept  specific  structural  apply  abstraction  each  type  can  data types.  domain  data  with  with  database  by  are  e.g. of  that  mechanisms  with  behavioral  this  semantics  designer.  a database specification. To  includes the  verification,  concept in the database context  operations  associated  data  data  applying data types to  with the  abstract  be  effective  demonstrated  Abstraction  hierarchy  in  very  abstract  can  1 2  applying  can be integrated  point  has  constraints, a  a  the data type  certain  integrity  desirable  the  of  many advantages of  For  is  research  abstraction.  encapsulation  semantic  uniformly.  of  it  a database. The  their  program  abstraction  uses of  and  readability,  because  The primary  data  program  languages  in the  concept  of  developed in programming  has been considered fundamental  the  specification  certain  was originally  reliability,  basically  a considerable  database context.  CONCEPT  The concept  languages,  concept,  for  the  improving  processing efficiency. programming  TYPE  and has no  concept  that a database  inconsistencies has not  makes it  languages. Such  prove  possible to techniques  been an easy task.  apply verification  include  specification  theoretical  techniques models  like  By encapsulation abstraction, we mean that the user of the abstraction does not need to know the hidden information in order to use the abstraction and he/she is not allowed to directly use or manipulate the hidden information. 1  2  37  operational of  such  semantics,  application  denotational  semantics,  and axiomatic  semantics. Two examples  done  Brodie  and the work  are the work  by  [1978]  by  Wong  [1981]. for  the validation  constraints  of a database. The data type  concept  and data objects. Typechecking techniques  provides  a means to  associated with  relate  data types  have  proven to be o n e of the best mechanisms for ensuring database correctness.  3.5.2 DATA TYPE STRUCTURES  Data from  type  structures  each other.  booleans,  provided  Some offer  and enumerations.  only  by  different  semantic  very  primitive  types  A few examples  RIGEL, ADAPLEX, and GALILEO provide the  notion  of  class which,  persistent extent,  In  have argued  that type  They  also  clear  separation  may  have  separation  pointed of  multiple of types  a serious flaw  kind.  extents.  many  more  3  (Buneman  recently  Separation This  is  DIAL,  & Atkinson  of  often  to provide  developed types  [1986]),  more  data models  and classes  desireable  relationship  strings, such as support  associated with a  in  many  Buneman  between  have  indicates  of role is explained in Section 4.2.3.  data  models.  not maintained that  situations.  by semantic  roles  and Atkinson  general  a  a data  type  However,  such  data models. This is  the fact that a r o l e one role. That  and types.  clear in the discussion of our conceptualization of data modelling.  The concept  character  objects.  can be used to model more than  be a many-to-many  significantly  and G E M . Others  in many semantic data models. They do not support  could  differ  as integers,  is a special data type  and classes is usually not supported  can have several types and a type say there  before,  and class may be separated  out that this  paper  models  a richer set of data types. All these models  as mentioned  published  such  are TAXIS,  namely an associated collection of  a recently  data  It will  1  3  is to  become  38  In  this  4.  THE  chapter,  we  conceptualization which of  will  the  be  will  be  specified  underlying  THE  UNDERLYING  THE  In We  in  detail  to  in chapter  philosophy  The 'real' world  4.2  explain applied  explanation, because the  4.1  CONCEPTUALIZATION  of  the  5. our  In section 4.1  of  approach.  chapters,  conventional  a review  assessed  the  analysis, we  constructs  and  to  shortcomings,  is there  constructs  mechanisms  of  we  data  find  modelling  fundamental  Before  which  of  the  is  we  model, give a  presented  elaboration  principles that are to  explaining  conceptualization means.  a  more are  data  This  SDBM,  statement  without  of this  any  statement.  data models to modelling  question  to  cause  inadequate?"  Tracing  stem  from  in these  models  some of  their  assertion,  let  practice was  data modelling  fundamental  shortcomings  is not  data modelling  (relational  conventional  is e m b e d d e d  In other words, it  further  the  mechanisms. A natural  that most  modelling,  methodology.  or  of  data modelling  was  roots,  database  chapter,  statement  modelling.  exists in the database.  of  particular  this  data  PHILOSOPHY  semantic data modelling. The ability  these  The  of  semantic  rest of this chapter is, in fact, the  two  In  MODELLING  conceptualization a  the  analysed.  DATA  of  CONCEPTUALIZATION  discussed both  our design  TWO-VIEW  previous  OF  in  provided.  particular)  modell the  'real'  shortcomings  of  ask therefore  is "With  or  the  is  these  just  relational respect some  to  their  conceptualization  corresponding  building  world  because  shortcomings  inadequate  and their  particular  it  the  and  constructs  modelling but  the  blame.  this  us  describe  what  our  two-view  39  4.2.1  A  GENERAL  DESCRIPTION  Conceptually, one 'real'  side,  we  the  are actually  two  the  database to  resemble the  want  world  is  relationships  there  considered  among  these  identically-named  conventional guiding  On  technology  objects.  concepts  is  the  of  Unfortunately, ln other  consist  we  that  other  the  words,  These in  these side,  computer. can  not  should  We  have  symbolic strings  matter  and  must built  their not  into  constraints which  how  the  input are  concepts  and  representation the  data model  with  we  be  conciousness of as an inherent  their  are  directly  these  concepts  concepts kinds the  of  must  the  designer of  the  both  discuss the  below. The  modelled by  in of  the  including  in  the  the  user and the  computer.  and the  of  strings, objects,  computer.  properties  clearly  the  current  symbolic  description  be  and  separated. The user.  data model  can be as naturally  and  from  objects,  strings  part  On  differences  constrained  indispensable for  symbolic  properties,  models  using various  the  modelling.  be discussed in detail  represent  our conceptualization, we will  interpretation  data  and output between the  used,  data  as closely as possible. The their  must  that  without  are natural in the 'real' world  To further clarify and present our  they  depend on  realize  in  objects,  developed  concepts  are absolutely  no  be  world  of  fundamental  to  accomplish this  However,  must  'real'  set  previously  we  and relationships and for  separation  a  fundamental  properties,  relationships  of  aspects involved  data models and semantic data models will  principle  database.  to  different  Rather,  it  so that  many  concepts in  detail  modelled.  relevant  of several existing semantic modelling mechanisms.  40  4.2.3  SDBM  The  OBJECTS  concept  semantic  data  one-to-one  of  an  models.  of  object  objects,  these  To  to  and  this section  the  type  of  sequentially,  discuss the role  the  fundamental entities  same  principle  in  is structured  objects.  the  type  has been  describe  Chen  between  basically  the  Because  discussion  is  'real'  it  is  that  defined  there  world  and  in  other  should  be  objects  in  existence of  is difficult  be  better  to  objects, the  present  understood  the  after  the  naming  discussion the  a the  in such a way that several aspects of  it  may  as  on  reading  of  section.  The term it  the  is  concept will be discussed. They include the  aspects  the entire  object  Naturally,  correspondence  database. The rest of SDBM  SDBM  the  used the  an  used in  way  term  of  in  to  SDBM data  which  object,  us first  describe the  models with various  a relation  describe the  let  attribute  different  relates  function  that  an entity  is similar to  that  used  to  concept  meanings.  a domain  of  role.  Codd  used  (Codd  [1970]).  plays in a relationship  (Chen  [1976]).  The has of  role  a similar certain  roles  concept  meaning when  properties  object.  SDBM,  interrelated  through  and another  object  roles, e.g. the  Now,  let  has  been  it  a set  is used in the of  objects.  is, a role  roles at the  In  type  of  and objects. That  may play many  two  in S D B M  objects their  can  theatrical  There  roles.  not  directly  For example,  in  a  A  many-to-many objects  role  is an  relationship and  related  to  each  consider that objects  other.  an object  [1977].  It  abstraction between  a specific  object  characterize that Rather,  plays  they  are  a student  role  can be interrelated  through  these  takes the course.  us go back to the used  context.  Daya  roles played by an object  plays a course role. The two student  is  Bachman and  be played by various  same time. All the are  by  semantic  consideration of the data  models  object  primarily  for  type. The concept of the  purpose  of  object  reducing  41 complexity  and  increasing  understandability.  Unlike  have no type. This conceptualization is supported We  believe that this is a more  models,  objects  Engineer  object  Shareholder  and  roles  type,  object  type.  been  Employee But  in  and  the  data  models,  SDBM  objects  look at objects. In most existing data  mixed object  fact  other  by the following considerations:  natural way to  have  an  any  they  up.  For  type,  a  are  just  example, Manager  different  we  could  object roles.  have  type,  An  an  and  object  a  may  assume all these roles. The  abstraction  object  type  function  concept  can  be  demonstrate this contention There  is  several  a restriction object  hierarchy.  Our  undesirability  Now, object  we  classes  different  through  using  function  the  role  semantic  these of  data  classes  model  must  objects  be  that in  pinpoints  an  a  this  provided concept.  design of object  same  restriction  and  the  We  will  SDBM.  may  class  by  belong  to  generalization highlights  its  played by  an  in modelling data.  turn to  discuss the  between the role of  notions, although  existence of from  an object  in S D B M the  an S D B M  the  object  and the  object.  The role  itself. W e should also clarify  the  existence of that object. They are  two  existence of  an object  is manifested  In a sense, the role concept does indirectly  by the  roles  model the existence of  objects.  From not  instructor. entity  other  but  specification  in Chapter 5 when we present the  conceptualization  played by that object.  does  obtained  has been conceptualized differently  relationship  SDBM  in  constraint  still  a  data  exist.  modelling  point  For example, an  object  The person, the student, exists  purpose, an object  even  without  needs to  of  view, may  and the  playing  without  appear to  instructor  these  roles.  play at least one role to  are still intersted in the corresponding entity.  playing be  any  role,  an  object  a person, a student,  simply and  an  are all roles. Obviously, in reality an But  in  data  modelling,  for  practical  exist, which in fact implies that we  42  Another characteristic that ought existence. entire  We  have  From  this  elimination leads  of  us to two  objects  they  objects not  data  our  be  conceptual  differentiation  two  level, a specific object  infer  that  constraint,  in  conceptually  objects.  for  the  of  in  when  level, ln  fact  the  can have only  one  SDBM  two  objects  can  This  uniqueness  differentiating  two  objects.  sometimes  us with  implemented,  database.  differentiatable.  However,  provides  are  never  we the  we  know  Syntactically, do  that  potential  to  not  are  also  maintain  that  however to  two  make  different  syntactically  the  constraint  We  need  they  lead to  SDBM syntactic  objects. The  distinguish  them  in  future.  Physically, an S D B M invisible  they  may  to be  the  object  database  realized  The  existence  creation. The act of binding  to  an  to when  and  some  unique other  for  object  various the  can not  permitted  object  no  in  internal  longer  with  role  plays  instruction.  entire  identifiers  which  database, or or  any  other  user.  starts  A  character string  the  the  an  explicit  object  that  played role.  by The  instruction  at the  be created. O n c e an object roles.  terminated with an explicit destruction  object  means. These  be accessed by the  SDBM  each  creation also assigns a role to  a role, an object  assigned  de-assigned  of  may be represented with an internal  user  through  physical constructs should not  be  can  views  differentiated,  between  is  we  duplications  be  differences  conceptual  object  may play identical roles and their external data representations  conceptual  must  the  SDBM  allowed.  same. This conceptual  certain clarify  may  level. At this  uniqueness constraint,  may be exactly the  the  discussion exclusively to  existence is not  same, even though  any  our  paper is presented at this  existence. Multiple  the  limited  to be emphasized is the uniqueness of  an  of  same time.  is created, it object  existence  of  object Without  can  then  can  also  be  an  object  is  43  Now, many  we  pathological  these two between SDBM  objects  object  string.  implications  the  relational  data  model  are  in chapter 2 that  caused  by  confusion  naming. In S D B M , we maintain an explicit  and symbolic strings. To make our  internal that  level, such  Firstly, they  database  in  S D B M objects. W e have identified  point  clear, we  will  of  distinction  discuss issues  of  naming at three levels.  Notice  strings.  naming of  concepts, objects and their  At the  for  discuss the  are  an S D B M symbolic  invisible  user. Secondly, they  each object  in the  entire  object  strings  to  the  may be represented with  are  significantly  database user  different  and  are generated automatically  can  from  not  by the  an internal external  be  symbolic symbolic  accessed  computer  by  and are  the  unique  database. Thirdly, their structure, syntax, etc. are irrelevant  at  the other levels.  At the object so,  to  we  conceptual level, an S D B M  object  has no name. That is, we do  a specific symbolic string throughout  isolate  an  object  from  any  the  life time  possible relationships  it  of  the  may  be  from any roles it may be playing. W e also separate an object from  At the number of forms.  external data representation level, an S D B M legitimate  record. The structure Notice  that  synonyms as often  In student may  the  rest  a student  bind an  By not  participating  doing in  and  its properties.  can be identified with any  symbolic strings. These symbolic strings are bound to various syntactic  For example, an object  itself.  object  object.  not  of  may be  identified  symbolic identifiers  here  multiple  for  identifiers  by a number, an object  for  an  an alphabetic string, or a  is differentiated  object  do  not  from  the  necessarily  object  refer  to  mentioned.  of  this  object.  have several different  paper, Because  we  may  loosely  an object  can  call  an  object  play several roles  playing at  the  the  of  a  same time,  it  'names'. However, this is only for expository purposes.  role  44  4.2.3  SDBM  RELATIONSHIPS  Another section  fundamental  discusses  properties  which  concept, the relationship their  this can  concept. be  fundamental concept.  which  more  modelling  conceptual  because  of  its  major  are forced  to  example, the to  model  binary  may be the  In  SDBM,  For  basic they  et  the  relationship.  objects.  concept  Like the  of  modelling  of  different  types  of  This object  SDBM  correspondence applies to  vs. binary  modelling  object  the  SDBM  relationships,  relationships. The criteria for  construct  are  modelling  are highly subjective. O n one side, most  al  with  arbitrary  primitive  [1976]). For  On  concept it is the  the  instance,  other  the  the  binary  side,  simplicity  and  appropriate  n-ary  data  deciding  it is argued that  most  the  relational  relationship  relationships which we a student  example,  adopt  in  smaller  relationships  is  to  [1976]).  discuss  SDBM  for  relationship  model  uses  is  n-ary  binary one  approach  are not  may  be  that  that  interested  takes a course taught relationship, we  is  by  takes  we  in. Consider, for  a professor.  may arbitrarily  a student  sometimes  In  order  break it  into  two  course,  and  the  a  relationship between the first relationship and a professor.  we  similar  of  two  construct.  is primitive.  approach  on  n-ary  conciseness.  relation the  the  relationship with the  relationships.  other  as  relationship where  this  will  one-to-one  focuses  issue of  disadvantage  introduce  section  between  representations.  (Braochi  relationships as its basic  The  the  binary relationship is the modelling  relationship  next  of  section  accuracy, even though  because the  favored  suitable  the  as a special type  principle  first consider the  is  is  The  viewed  This  existence, and their  We  concept  An  the  n-ary  the  n-ary  relationship  relationship  that  can  approach  be  but  is said to used  to  characterized  with be  the  primitive  reconstruct by  restriction if  the  "irreducible  we n-ary  that  are not  the  n-ary  interested  relationship.  relations"  (Hall  This et  al  45  We  believe  that  a data model  characteristics  differently.  One  properties  of  their  A binary  in  different  three  own. ways.  should  important  For  be  able to  characteristic  relationship  expository  of  without  model  relationships  its own  purposes,  let  us  students take courses. O n e way to  model this relationship  it  student  were  a  identifies  property.  courses  STUDENT which  That  taken  is,  by  identifies  the  the  object  student,  students  and  enrolled  will  the  in the  relationships  is whether  properties  again  use  is to treat  have  course  the  the  the  will  different  they  can be  have  modelled  example  that  relationship as if  property  object  with  COURSE  have  course. Obviously, these  the  which property  'properties'  are  multi-valued.  Relationships many-to-many)  A the  very  student  with  different  kinds  of  important object  conceptual  and  Another way to  the  constraint  course  object  model the  first approach to  relationship  establish the  Obviously, it does not does  not  (e.g.  one-to-one  and  have  its  own  is that must  is to  relationship  It  exist.  such a relationship SDBM  has  to  exist  provided  the  both proper  treat  it  between  as an S D B M this object  object,  and  then  and the student as  and the course object.  make much sense to properties.  for  is observed.  well as the relationship between this object  it  characteristics  can all be modelled this way.  mechanisms to ensure that this constraint  use the  functional  simply  model the  relationship  in such a way if  complicates data manipulation  without  any  approach,  no  gain.  The object  will  window " 1  the 1  third be  approach created  through  window  to  is  similar  to  represent  the  the  relationship.  which the relationship  concept  is  discussed.  It  " T h e S D B M concept of window will  second  approach. In  fact,  But this  with  this  approach  can be seen. This approach will  will  be  demonstrated  that  be explained in Section 4.2.6.  this  only  creates a  be clarified  approach  and  after the  46  second approach also have different  For the  binary  relationships with  the  and  relationship  the  approach.  appearing  relationship  of  interest  mentioned  existence  of  computer. properties  To of  appropriate  We  has  computer  related  been  properties  and  a  participating the  objects.  number, must  in these  modelled  existence  binary  with  This  of  relationship,  A  relationship  of  the  (n>2)  relationships, in  each participating in  the  case  of  fact  object  the  third  relationships themselves, because  SDBM  obects. With  respect  to  this  as modelled with binary relationships.  the  necessary  n-ary  between  a pseudo-object  SDBM  relationship  condition we  These properties  relationship.  must  must  are  explicitly  those  can  be  be  which  depends  on  the  checked  by  the  modify have  terminated  appropriate  been  through  dedicated modifying  too.  to  that  object  the  specific  be  aware  and the existence of  believe  or  any  second approach is used, we  relationships in S D B M  objects.  establish  important  student student  interested  previously,  properties,  is  an object  a  the  representing  It  as an object  However, we are not  As  the  own  relationship with several binary relationships  approach, we can view all the  to  their  second and third approach are used. W h e n the  represent  the  implications for database manipulation.  modelling  conceptual  the  has an age,  distinguish  courses  ignore their differences. For the  between  the  existence  of  a relationship.  relationship  as an example. W e would he  difference  he  through  naturally  user, they  the  name,  properties  is natural. Take  think that he has a name, he has  has degrees, and  from  object  age,  he  takes courses. Although  etc.,  the  are all properties of the  user student.  can  choose  the to  47  4.2.4  SDBM  PROPERTIES  The S D B M be  the  relationship  relationship  The  property  can be viewed  between  discussed in the  important  an  as a special kind of  SDBM  object  and  a  previous section is between  characteristics  of  a symbolic  symbolic two  string  relationship.  It is defined  string  SDBM  or  strings.  to The  objects.  participating  in  a property  can  be  summarized as follows: The  1.  existence of  conceptual always  constraint  hold  existence of  for  a property  A symbolic string  3.  Not  any  only  certain  type  and window  constructs  —  representations data type  of  the  and the  As  of  relationship  as the  should  be  allowed  are permitted.  the  relationships,  discussion of and  conceptual strcture.  properties.  presents the  exist.  They are  Therefore,  the  objects  will  words,  the  two  In  other  the  object.  a  specific  For  property,  specified with the  conceptual now  concept of the  before, objects,  we  have  to  relationships  resort and  to  symbolic  properties  accuracy of  to  exists.  structure  turn  to  The next section discusses the  the  mechanisms  to  We  either  to  between  existence of  the  symbolic strings. The conveyance is bilateral computer  object  eternal.  SDBM  SDBM  and  its basic  addressing concept  data  of  SDBM  window.  CONCEPT  mentioned  semantics  long  be  system.  section following  4.2.5. S D B M TYPE  the  to  object.  patterns  have focused on  objects,  on  as  an  string  symbolic  is considered  depends only on the  is not  symbolic  string  imposed  properties  2.  So far, we  The  a symbolic  the  user. To  structure  ensure  symbolic  the  strings  and  all  for  data  to  be  conveyed  user to  the  computer  have  from the  to  strings  such provide  conveyance, we certain  manipulation.  need  semantics  through or  from certain  for  the  48  conceptual structure.  Let defined these  us  S D B M data types are designed to  define  the  concept  of  data  type.  In  programing  by a symbolic name, a set of data o b j e c t s data  objects,  specification of  and  the  a data type  possible  value  be such a mechanism.  1  5  ,  a set of  bindings.  must contain the following  a name for the  2.  a syntactic specification for symbolic strings of the  3.  a  of  operations of the  the  refer to  for  manipulating  that can directly  data  any virtual  name  operations.  data  operations that  definition  type  is  manipulate  requires  that  the  the  only  elements:  manipulate  type  data  objects  of  the  syntactic  the  type.  They  representation  of  are  symbolic  strings  type.  term  The  a  type  operations  In S D B M , we that  This three  1.  set  languages,  The  of  use the object  concept does  of  not  data type  as defined above. W e should emphasize  necessarily refer  to  the  physical  computer.  They  may  computers.  a type  name  is an abstraction  dictates  the  of  symbolic  the  syntactic  patterns  and  specification the  and the  operations  that  set may  of be  allowed.  In  SDBM,  the  Therefore, distinctive  name  equivalence  rule  is adopted  semantics are associated with the  for  the  data type  S D B M data type  data type  MILE and data type WEIGHT may both be defined on the  with  same  the  syntactic  specification.  But  they  are  not  comparable  different semantics are associated with them. W e will discuss more in the  next  chapter when  equivalence  name. For example, same set of in  about  SDBM,  integers because  S D B M data types  their syntax and semantics are described.  D o not be confused with S D B M objects. The term data object here refers to a run-time grouping of one or more pieces of data in a virtual computer. Alternatively, can be viewed as a container for data values. 1  test.  5  it  49  4.2.6  SDBM  WINDOW  CONCEPT  So far, we have constructed and  properties.  We  also  a conceptual world  introduced  the  SDBM  consisting of  data  type  objects,  concept  relationships,  which  is  used  to  structure symbolic strings for the purpose of external data representation and manipulation. We  have  structure  not  yet  among  answered  objects,  conceptual structure  questions  relationships,  and its external  such  as "How  and properties?"  can we  specify  and "How  the  can we  conceptual  integrate  data representation?". The SDBM window  the  concept is  developed to answer these questions. This is probably the most important concept of the Semantic DataBase Model, SDBM.  More  specifically,  the  following  functions  will  be  accomplished  by  the  window  concept. To  1.  provide  a  window  through  which  certain  aspect  of  SDBM  objects  or  relationships can be seen (accessed) and manipulated. 2.  To  describe  and  maintain  the  structure  among  objects,  relationships,  and  properties. 3.  To model the persistence of objects, relationships, and properties.  We will further clarify this concept below. To begin with, it is impractical, even though  possible, to manage objects  individually  because of the following three reasons. First, the number of objects in a database may be enormous. Second, there may be differences between every two objects. Third, each object may play a variety of roles. Thus, we need to treat them in groups. This is accomplished through  using SDBM windows. That is, a window specifies certain properties which we are  interested in and which are allowed to be accessed and manipulated. Through this window, only syntax  objects of  that  have these  symbolic  strings  properties  permitted  can be accessed to  describe  and  properties  manipulated. The specific as  well  as  relationships through SDBM windows is specified with the SDBM type system.  objects  and  50  From  the  conventional  maybe appear to therefore,  the  Although At  this  be the  same  as  we  result of the  similarities do point,  semantic  data  modelling  applying the  class  concept  used  at least three  of  view,  an  classification mechanism to  exist between these two  can identify  point  in  many  existing  concepts, there  differences  SDBM  window  objects  and is,  semantic  data  models.  are conceptual differences.  between  the  window  concept  and  the class concept.  First, a w i n d o w are  grouped  through The the seen  together  a window,  only  is not  an object  because of  we  requirement  may  is that  container  the  access  homogeneous and  properties  example used in Section 2.1.7. With through  the  window  as a class is. Second,  PATIENT . 1 6  properties  manipulate of  every  SDBM, We  two  object both  will  P R E C N A N T - O R - N O T and male patients without  allowed  among  compared  SDBM  with  the  properties,  total  the  number  of  number objects  of or  objects have  by  with  the  them.  different  same  objects  However, properties.  abstraction.  Take  female and male patients can all be  be  property  shared  in a class  able  to  see  this property.  such variations relationships  female  with  Although variations are  should  that  patients  can  be be  relatively  small  seen from  that  window.  The  third  relationships  difference  may  be  seen  SDBM window through  that  a  seen through  same window. This will the  is  class  contains  windows,  only  though  they  objects may  while not  be demonstrated in Section 5.3 where the  are presented. From now  a window  the  role  of  o n , we will  that window.  call the  Apparently,  it  be  both  objects  and  seen through  the  syntax and semantics of abstraction of satisfies the  properties  definition  of  the role concept given in Section 4.2.2.  As  identified  before,  SDBM  window's  other  function  W h e n we say that object A can be seen through accessed or manipulated through that window. 1  6  is to  a window,  describe and maintain  the  we mean that A can be  51  conceptual between  structure .  windows.  interrelationships deletion  of  operations. A explicitly.  An  1 7  In  that  an  SDBM, do  object  roles  specify what  to  affect  from  the  of  the  through  convey  SDBM  a window  window  can survive  mapping relevant data to  To  the  the view concept  latter  insertion  kind  semantics  windows  are  and  an  object  into  interrelationships  behavior of  of  insertions  the or  to  divided the that  the into  relationship two  kinds,  windows do  or  affect  and should  the these  be specified  external data representation deletions.  concept supports the after  a program  some internally  notion  invocation  of  Rather,  we  of  explicitly  persistence. Anything seen  is terminated.  argue the  definition  For example, a view  is that a window  EXTENSION  TO  This  is done  by  persisitent data types.  differences  between the window  in conventional data models. First, a S D B M window  specification.  AN  is related  of  of  a conventional view  may  be  the  result  of  usually contains additional information  elsewhere, whereas a view is usually derived from  4.2.7  function  is called a reference  rely on the  database specification. The  difference  between  windows,  conclude this section, we  database  the  this  is intended.  Finally, the  the  not  relationship  aspect of  relationships  In S D B M , we do not  relevant  of  important  SPECIALIZATION  some other  concept and  is an integrated is usually  a retrieval.  not  part  in  the  The second  that can not  be  obtained  information.  MECHANISM  In Section 3.3.3, we discussed the specialization mechanism which is used as a major tool  to  enhance the  semantic  modelling  ability  models. TAXIS applies this mechanism uniformly  Clearly, different using the  views of the  same thing  in to  many  recently  developed  semantic  data  all the aspects of data modelling.  are supported  by this  mechanism. However,  conceptualization presented in this paper, we can easily pinpoint  the  limitation  A conceptual structure is a structure consisting of objects, properties, and relationships and is the conceptualization of the 'real' world being modelled. 1  7  of  52  the  specialization mechanism. A major  all the  different  hierarchy. differ  views  The  implication  only in the  completely  generated of  levels of  different  real world  time.  student  Here the  specialization  of  modelled  many  TAXIS,  by  a  the  TAXIS  specialization of of  can  not  is  apparent  specialization  that  mechanism.  To  investigate the relationship  For three  From  different  different  data  real  on  the  the  has  to  and the  by  of  thing  may be viewed  from  employee  nor  example, be  to  created,  For same  employee a be  effectively  model  such  which  should  fact  with be  EMPLOYEE relation. W h e n the  a  number  database specification can become very complex.  discuss  extend what  between windows  W1  and  the  modelling  extensions and  W2,  ability  should  be  provided  introduced,  by  the  we  first  objects.  an  object  S can  be  related  to  them  in  ways:  If S can be seen through  W 1 , it may be seen through  Type 3.  If S can be seen through  W 1 , it will  o n , we  will  such  a  call these  way  that  relationships  they  objects.  In other words, they  For  type  constraints,  type  of  subwindow  at the  cannot  Type 2.  individual  mechanism.  is the  W 1 , it will  in  the  and an employee  If S can be seen through  now  specialization same  this  phenomena  For  same  views  modelled  world  models.  relation  should  windows  the mechanism is that  Typy 1.  defined  This  two  we  to  different  effectively  StudentEmployee  such specializations increases, the  It  be  important  STUDENT  be  can act as a student  semantic  relation  must  is that two  a specialization of  This  is inherent  detail. The fact that an object  an object  existing  which  mechanism  limitation  is neither  the  the  information  student.  both  with  this  angles  example, in the  limitation  1  hierarchy  concept  can  provides  the be  are  not  constraints.  oriented  described to  subwindow with give  the  Notice that  towards  hierarchy  windows  W2. W2.  these  constrants  instead  of  are  towards  windows.  will  specialization  an object  W2.  be seen through  are constraints among  SDBM  a means  be seen through  a more  be  used  to  mechanism. detailed  view  model  it.  The  SDBM  by  adding  53  to  the  object  important  property  subwindows group of  information  of  are  the  not  objects  objects  of  SDBM  dealing  with  seen  which  the  may  with  its  be  subwindow different  restriction  through  not  that  seen  through  hierarchy  is that  objects. objects  superwindows.  Rather,  an  they  seen from  More  its  superviews. SDBM  are  window  modelling  a subwindow  detailed  The  on  and  the  form  discussion  most its  same  a subset  the  SDBM  subwindow hierarchy will be given in Section 5.3.2.  Type  2  constraints  For  example, a student  not  be an instructor.  level.  Rather,  from  two  multiple  it  object  varies with  For  the  most  the  common  among  these  may also be an instructor.  Therefore, the  aspects. At roles.  are  constraint  individual window  objects.  level,  a specific object,  we  In  SDBM,  roles  the are  types  But, another  cannot be definitely  specify  different  three  Type  of  student  constraints. object  specified at the  2 constraints  possibility  for  are object  window modelled to  play  corresponding  data  may have a policy stating  that  assumed with  an  may  manipulations.  An  example of  a full-time exclusion window  student constraint  level.  Section 5.3.3.  The  Type 3 constraints  can not between  is that a university  be a university administrator. two  specific S D B M  windows. construct  Type  3  provided  A Type 3 constraint  constraints for  this  can  be  purpose will  is actually an  enforced be  at  desribed  the in  54  5. OVERVIEW OF SDBM  In  this  Various attack  chapter,  we present  considerations the  effective  of the design  modelling  way of  problems  modelling  model.  Compared  distinct  and novel features.  models.  an overview  with  the  other  In the previous  of  of  model  that  w e outlined  and to  available  semantic  1.3, we pointed  database  data  from  supports  orientation  and data  subwindow  hierarchy.  has  been made  but  more effective  This  the conceptualization  abstraction.  this  also  important  of semantic data supports feature  the  more  relational  data  SDBM  has several  of some  behind  relevant  the design of  chapter.  modelling,  type  e.g., object  hierarchy  is that greater  semantic data modelling  a  and the  modelling  activities  power  in a different  and natural way.  is  intended  languages.  reason,  The model  However, the most  database programming For  features  possible by conceptualizing  research  programming  many well-developed  the  out shortcomings  SDBM.  is designed to present  models,  S D B M . W e will summarize the novelties of our approach in the last  SDBM  model,  addressed. S D B M  data  than  developed  In section  the semantic  are also  relational  world  recently  chapter,  SDBM  the  real  of  At  to  the  be  a  moment,  preliminary we  do  not  language. Rather, it is intended  some  very  important  features  part  of  attempt  further to  study design  in  database  SDBM  as a  to be a semantic database m o d e l  such  as  database  designer  8  .  specifiable  exception handling facilities are not provided.  The difference between database programming languages and semantic data models is one of emphasis: a database programming language is a set of constructs for specifying the objects and procedures involved in an information system, whereas a semantic data model is a set of constructs for building a representation of the structure of the 'real' world, along with the necessary operations to manipulate that representation (King & M c L e o d [1985]). 1 8  1  55  In  the  window SDBM  following,  system.  Every S D B M  transaction  both  the  we  facility  syntax  will  discuss  the  SDBM  schema specification  consists  will be described. In this  and the  semantic,  type  system,  and then  the  of these  two parts.  Finally, the  chapter,  are informal.  In  the specification  APPENDIX  A,  SDBM  of the S D B M ,  a  formal  syntax  is  of  SDBM  syntax  in  provided.  5.1 SOME NOTATION CONVENTIONS The this  following  notation  conventions  are used  in the prototypes  chapter.  Upper case :  indicates  an S D B M  keyword  which  is to be typed  in  verbatim  by the user. indicates  Braces { } :  an  optional  repetition.  repeated zero or more Brace Plus { } +  Brackets [ ]  indicates  a repetition.  or more  times.  indicates  an optional  The  symbol  inside  may be  times. The symbol  alternative.  inside  may be repeated one  The symbol  inside  may have  must  have  one  by the  right  zero or one occurrence. Bracket Plus [ ] +  indicates  an  alternative.  The  symbol  inside  occurrence.  < >  indicates  Vertical bar | :  indicates an alternative. indicates  a nonterminal  that  the  left  symbol.  side  is  to  be  replaced  side.  To to  increase readability,  nonterminal  delimit  in the syntax, we always add some kinds of prefix  symbols to indicate  a terminal  symbol.  their  usage. In the case of ambiguity,  or  postfix  " " are used to  56  5.2 S D B M  TYPE  SYSTEM  in this paper, the two-view To  realize  support  such  a two-view  conceptualization  data representations  is the S D B M  type  conceptualization is used throughout in the computer,  and a mechanism to support  system which  is discussed in this  the design of S D B M .  w e need  a mechanism to  conceptual structures. The former  section. The latter  will  be discussed  BOOLEAN,  CHARACTER,  in section 5.3.  5.2.1 ELEMENTARY  The and  built-in  DATA  elementary  ENUMERATION.  other  more  TYPES  They  complex  SDBM  data  types  are the elementary  data types.  include data  Each elementary  NUMERIC,  types  data  that  type  will  be used  has certain  to  built-in  construct operations  that are permissible with them. N U M E R I C  A SDBM The prototype TYPE  NUMERIC data type of S D B M NUMERIC  is specified in a way similiar to C O B O L picture data type  ( <NumericTypeID>= <NumericRange>  declaration is  NUMERIC WITH { OR <NumericRange>  }  )  <NumericRange>:=  The following  <NumericConstant>..<NumericConstant>  are some examples.  clause.  57  5-1.  Example TYPE  ( Salary=  NUMERIC WITH  10000..99999 )  TYPE  ( Height=  NUMERIC WITH  0..99.99  TYPE  ( Temperature=  In the above distinguish  it  from  'Temperature' data  type  declaration  window  and transaction  values  number  with  two digits  integer  data  type  which  Like any other type  The  -99..99  examples, each type declarations  are numeric-type  whose  NUMERIC WITH  identifiers.  are between before  the decimal  could  assume  declarations.  0..99.99  and two digits positive  after;  positive  declares  value  integer  a positive  and -99..99  or negative  'TYPE' to  'Salary', 'Height', and  declares a five-digit  and 99999;  either  )  is preceded with a keyword  10000..99999  10000  )  real  declares an  with  two digits.  declaration, the declaration is enclosed in parentheses ( ).  operations  defined  operations, and the relational  for NUMERIC  data  type  are the assignment,  the  arithmetic  operations. B O O L E A N S  A  boolean  straightforward. Example  value  can  be  either  'TRUE'  or  'FALSE'.  The  specification  is  For instance 5-2.  TYPE  ( True=  TYPE  ( B= BOOLEAN WITH  The prototype TYPE  of,  BOOLEAN WITH  of B O O L E A N  {TRUE} )  {TRUE,FALSE}  )  data type declaration is  ( <BooleanTypeID>=  BOOLEAN WITN  "{"TRUE|FALSE|TRUE,FALSE|FALSE,TRUE"}"  ) There BOOLEAN  is  no  data type  ordering  defined  for  BOOLEAN  data  type.  The  operations  include the assignment and the logic operations ( A N D , O R ,  on  NOT).  a  58 C H A R A C T E R S  A  character  data  type  consists  of  data  objects  that  have  a string  of  characters as  their values. This data type specifies certain desired format of character strings. 5-3.  Example  it  C H A R A C T E R WITH A ( 1 0 )  TYPE  ( Name=  TYPE  ( Addressnum=  TYPE  ( Student#=  Notice  that  although  is not a numeric  indicates  C H A R A C T E R WITH  ) 9 ( 4 ) ) X(11) )  C H A R A C T E R WITH  'Addressnum' is a four-digit  number. That  an alphabetic  string  is, the arithmetic  with  with length of 11. The prototype TYPE  For example  a length  number,  operations  which  is indicated  by 9(4),  d o not apply to it. 'A(10)'  of 10. X(11) represents an alphanumeric  string  of CHARACTER data type declaration is  (<CharacterTypeID>= <CharacterPicture>  C H A R A C T E R WITH {OR < C h a r a c t e r P i c t u r e > }  ) <CharacterPicture>:=  X(<Integer>)|9(<Integer>)| A(<Integer>)|<CharacterList>  <CharacterList>:= < Q u a t e L i st>:=  {[A|X|9|<QuateList>] } +  "<Character>{<Character>}"  The above syntax indicates that a character data type variants  which  telephone  are separated  numbers  +  by the  keyword  O R . This  can be defined is desirable  for  are to be recorded s o that w e d o not have to write  code for each phone  number.  <Character>  is defined in APPENDIX A.  to have several example down  when  the area  59 E N U M E R A T I O N S  An  enumeration  is a list  eliminate  some  of distinctive  potential  values.  ambiguities,  Usually, these  order.  To  SDBM.  Some declaration examples of the ENUMERATION  TYPE  ( S e x = ENUMERATION  TYPE  ( A  = ENUMERATION  The enumeration  TYPE  ordering  will  not  are in a certain be  considered  in  data type are  5-4.  Example  small number  the  values  data type  WITH  WITH  {Male,Female}  {High,Medium,Low}  is specially useful when  "{"  )  a data object  of values. The prototype of the enumeration  ( <EnumerationTypeID>=  )  data type  ENUMERATION  can only take on a  declaration is  WITH  < E n u m e r a t i o n L i s t > "}"  ) The  basic  operations  on the ENUMERATION  relational  operations.  operators  because no ordering  the S D B M  5.2.2  ENUMERATION  STRUCTURED  A structured A  structured  declared  The relational  data  of  operations listed  data  type  not  include  do  values  is provided  are the assignment less-than  and  in the current  and the  greater-than  specification of  data type.  DATA TYPES  data type  data types.  type  is a data object  can be  Currently,  constructed  the only  which from  structured  is an aggregate of other elementary data  type  or  any  supported  data objects.  other  previously  by S D B M  is the  S D B M record data type.  An  SDBM  improvement ordinary  record  data  type  has been introduced  record data type.  is  similar  to  an ordinary  in order to eliminate  record  data  some problems  Let us first use an example to demonstrate  type.  However,  associated with the the concept.  60 Example TYPE  5-5.  ( Date=  RECORD WITH Month:Monthtype, Day:Daytype, Year:Yeartype; BEGIN Month LT 13 AND Month GT 0, IF Month EQ 1 OR 5 OR 7 OR 8 OR  10 OR 12  THEN Day L E 31 ELSE I F Month EQ 2 THEN Day L E 28 OR 29 E L S E Day L E 30 END IF ENDIF END  ) In taken  to  . incorrect the must  above  example,  represent input  will  date description  a  SDBM  record  chronological  be rejected  when  is protected.  type  date.  'Date' This  defines  data  it goes through  'Monthtype',  type type  a set of values guarantees  TYPE  prototype  declaration is  ( <RecordTypeID>= RECORD WITH [VARIANT|COMMON  can be that any  integrity  of  'Daytype', and 'Yeartype' are data types that  of the S D B M record data type  [  (almost)  checking. Therefore  be declared previously.  The  that  ]  <ComponentDeclaration>{, [VARIANT|COMMON] <ComponentDeclaration>};]  [ BEGIN <ConstraintAssertion>{,  61  < C o n s t r a i n t A s s e r t ion>} END  ]  ) <ComponentDeclaration>:= <ComponentID>:<TypeSpec i f i c a t ion>[MULTIPLE|OPTIONAL]  <TypeSpec i f i c a t ion>:=<TypeDef i n i t i o n > | < S u b t y p e D e fi n t ion>| <TypeID>  The part is  SDBM  record  and constraint declared  declaration  part. In the c o m p o n e n t  which  heterogeneous.  data type  is  The  composed  components  of of  a this  can  be  divided  into  two  part which is ended with  number  of  named  structure  can be  parts,  component  a record  components  declared to  that  have  structure  are  any  usually  previously  declared data type.  The keyword one  SDBM  record  MULTIPLE.  value of the  If  structure  can signify  a component  that certain  is specified to  same type. Because the  be multi-valued,  the  specified  with  structure  is  SDBM the  that  record  keyword it  can  collection  of  common.  Components  follow  either  structure.  records  of  COMMON  But some of  structure  have  several  different  VARIANT  its  Another variants.  syntactic  appear under or  allows  OPTIONAL.  the are,  are multi-valued  it can take  role modelled by an S D B M window  syntactically homogeneous, certain components may not Therefore,  components  important  types. keyword by  than  may not  be  make any sense with some objects.  components  This  more  with  to  be  optional,  of  the  feature  kind  of  record  of  them  have  All  COMMON  default,  or  common  SDBM  structure some  all  the  specifies  that  records  these records may have components that are different  is  record  components  components to  which  from  a in  do  not  of  the  others.  Such record variants are specified by giving several component-id and Component-declaration pairs  which  are  record structure  placed  under  the  keyword  VARIANT.  For  example,  an  employee  payroll  may have two variants because permanent employees are paid monthly  and  62  temporary  employees are paid  hourly.  5-6.  Example  TYPE ( Employee= RECORD WITH COMMON EmpID: Dept:  Integer, DeptName,  VARIANT EmpType: { P e r m a n e n t } MonthlyRate:  Ratel,  StartDate: Date, VARIANT EmpType: { T e m p o r a r y } , HourlyRate:  Rate2,  OvertimeRate:  Rate3  ) In on  the  constraint  components  first-order for the  logic.  or  part which  among  Constraint  components  are  and  is enclosed by  expressed.  assertions are separated  by  BEGIN...END,  Constraints  a c o m m a ','  are  all  which  constraints  specified  is a  in  shorthand  logic operator A N D .  To  simplify  specification,  expressions are allowed on the eliminate any potential  The SDBM  is optional  constraints  type  system  an  IF..THEN...ELSE  right side of  structure  specified here apply only to deals with  domain  the value of  constraints  are two  basic operations  defined  for  the  the  and, to  SDBM  sign.  certain  Boolean to  structure.  data type.  Namely,  degree,  the  cardinality  declaration part.  record data type. O n e is  component selection operation (or the dot operation) whose syntax is <VariablelD>.<ComponentlD>  and  ENDIF is used  IF..THEN...ELSE  constraints. The constraints on objects are specified in the w i n d o w  There  introduced  a relational operation  syntactic ambiguity associated with the  only  is  the  63  It selects the designated component The  other  operation  from the record  is the assignment  record of identical data type.  which  bound  assign  to the variable  the value  <VariablelD>.  of a record  to  another  For example  Recordl = Record2 assigns the value of Record2 to R e c o r d l .  Here variable  Recordl  and variable  Record2 have  been declared to be of the same record data type.  5.2.3 A B S T R A C T  An  DATA  abstract  TYPES  data  type  is a new data  type  defined  by the database  designer  that  includes: 1.  o n e or more  data type  2.  a set of abstract  definitions.  operations  o n the defined  data  types.  usually defined with several pieces of programs (procedures 3.  In Type)  Encapsulation of type  SDBM,  concept.  we provide  Example ADT  a facility  The following  abstract data type  definition  These operations are or functions).  and operations.  which  will  support  is an example  that  illustrates  the above  A D T (Abstract  the specification  of an S D B M  'Datel'.  5-7.  ( Datel  = TYPE D a t e ADTOP  LOCAL;  Compare(d1:Date,d2:Date): IS  ENUMERATION WITH  {L,S,EN-  ACTION: FUNCTION TYPE  Compare  (T IS NUMERIC WITH 1 9 7 6 0 0 0 0 . . 2 0 0 0 0 0 0 0 ) ;  VARIABLE x,y:  T;  BEGIN x=  Data  d1.Year*10000+d1.Month*100+d1.Day,  64  y=  d2.Year*1 0000+d2.Month*100+d2.Day  IF  x EQ  THEN IF  y  S  compare  x GT  y  THEN c o m p a r e = IF  x LT  THEN END  r  "L",  y  compare=  FUNCTION  "E"  compare  ) The above  declaratation,  TYPE. type to  declaration  The  logical  of the  which their former  (syntactic  the  of  the  abstract  structure)  of  ADT  Operations  a single  above  the  keyword  data type  is given  'Datel'  defined  is  are  result  is  defined  returned  to  are declared after the  the ADT operation  be  either  explicitly.  In  functions  the  latter  LOCAL  for  or case,  declaration, there  is a keyword  the  encapsulation  achieved.  Therefore, only  the be  no  result  obtained  abstraction  through  is  dedicated  language  structure  or  Notice model  implementation. Ordinary subprogram facilities such as those in PASCAL are not illegal accesses to  data  permitted  keyword  data type  type  prevent  the  ADTOP  In or  the more  explicitly.  internal  can  with  keyword  procedures.  operations from accessing the  encapsulation  after  the  are given along with  declaration excludes any other 'Date'.  ADT. In  course must be previously declared. The operations that are  than one result are returned  In  definition  recognized by  for ADT Operations. Parameters of  types.  case,  A D T can be  internal components of the data type  is short data  type  structure  'Date' which of  access the  an S D B M  the  internal  structure,  even though  'Date'. This of  the  data  that  such  design  and  sufficient  these facilities can be  to  used  to produce data types with new operations.  The details of actions performed  ADT operations are specified after  the  by one or more operations are defined.  keyword  ACTION.  In this  part,  65  Let us explain the ADT operation  ' C o m p a r e ' . This operation  is used to  compare  dates. If the first date is later than the second date, character 'L' is returned. are  the  same,  returned  to  be  ' S ' is of  returned.  an  subtype of the  built-in  the  'Date'  data  type  Arithmetic  data type  are  prototype  'E'  of  data  type.  declared  performed  the  is  returned.  This  ENUMERATION  been  these comparsons, appropriate  The  earlier,  enumeration  have  operations  If  on  to  enumeration  type  we  define  dates  the  is defined  value  to  be  W e assume that all the components  1 9  be  them,  Therefore,  If the  two  numeric  and  the  and  of  results  are  the  same  compared.  data  a of  type.  Based  on  characters are assigned to the A D T operation.  SDBM  ADT  declaration  is  as  follows.  For  more  detail,  see  APPENDIX A. ADT  (<ADTID>= TYPE  <TypeID>  ADTOP  [LOCAL];  [<ADTFunctionOP>|<ADTProcedureOP>] {, +  [<ADTFunctionOP>|<ADTProcedureOP>] }; +  ACTION: <ADTProcedureOrFunction>  ) <ADTFunc t i onOP>: = <ADTFunct ionID>(<Funct i o n P a r a m e t e r s > ) : < T y p e S p e c i f i c a t i o n >  <ADTProcedureOP>:= <ADTProcedureID>(<ProcedureParameters>)  Though be  accessable  generally speaking the from  special operations not want  to  case, keyword  1  9  outside  to  the  internal  ADT  structure  definition,  a data structure. W e d o  eliminate  the  LOCAL  must  ordinary not  operations  of  an abstract  sometimes  not  want  defined  be specified. This will  for  to  we  only  hide the  data type want  structure  that data type  make the structure  The concept of subtype will be discussed in next section.  to  should  not  add several and we  in S D B M .  In  do this  of the ADT and  66  the  operations  data type  5.2.4  SUBTYPE  (Ingalls  Ada  a  of  The  to  t'  of  derived  SDBM.  classes  of  type  this  and  of  (or  is,  any  operation  applicable  to  the  the ADT.  name  of  whose  by  data type t is  between  Structurally, data types 'compatible' two  type  of  t  if  supported  (Birtwistle  hierarchy  Simula 67,  values  Smalltalk,  a value of  [1973]),  concept has  been  and Galileo as follows. t'  can be  type  Galileo is  above. However,  hierarchy  of  a mechanism  Galileo used  to  Its extensional aspect is dealt with by hierarchy  Galileo  of  permitted.  the  the  been  example, can be defined  the  of  67  set  differences  of  instance the following  type  Galileo, for  hierarchy  has  Simula  that defined  SDBM,  two  as  short)  Galileo. The type  supported  of  for  S D B M is similar to  type  hierarchies among  such  the data type  Galileo. With  is that  a  its class hierarchy.  windows.  hierarchy  and  for  a subtype  of  the  type  models  hierarchy  structural  Conceptually,  approach  Consider for  That  [1980]),  concept  hierarchy concept  hierarchy  establishes type with  another  intensional aspect of  inclusion  outside.  data  where a value of  conceptual  with the  or  is a specialization or  The type  that  give  hierarchy  used in any context  both  hierarchy  languages  concept  are similar. The type  are  subtype  [1978]), Ada (Wegner  facility  constrained.  visible  will also be applicable to  programming  Smalltalk  Data type  structure  HIERARCHIES  concept  several  is  the  <TypelD>  The by  on  does  adopts  not  a mechanism  based on their  structure.  structures  have  may  necessarily define  very  that  there and deal the the  automatically  O n e flaw associated different  data type examples defined in Galileo.  semantics.  67  5-8.  Example TYPE  (  Company  :=  (  Name  : STRING  AND A d d r e s s AND  AND  Person  :=  (  Phone  Name  : Address  : PhoneNumber)  : STRING  AND  Address  : Address  AND  Phone  AND  BirthDate  : PhoneNumber : Date)  )  type  Obviously,  the data  type  'Company'.  With  SDBM,  and the  related  'Person' type  hierarchies  specifies  it  hierarchy  rules which will be explained  Let  us  first  look  at  should  data  the  are established  structures later  type  not be considered  are  in this  hierarchy  a subtype  when  compatible  of the data  the designer  according  to  explicitly  SDBM  type  section.  related  to  elementary  data  types. The  prototype is: TYPE  ( <SubtypeID>  I S <TypeID>  [ WITH  <ElementaryTypePicture>  ]  ) <ElementaryTypePicture>:=  <Numer i c R a n g e > | <BooleanPicture>| <CharacterPicture>| <EnumerationPicture>  Where  <TypelD>  elementary  data types  ENUMERATION. constraint relationship  must  which  They  be  a  previously  declared  can be used here. They cannot  specifies  be used  a subset  can not be established.  or  are NUMERIC,  as subtypes.  of values  type  of  subtype BOOLEAN,  ID.  <TypelD>;  built-in  CHARACTER, and  <ElemenaryTypePicture>  type  Four  otherwise  is in fact the  a  subtype  68  Notice A subtype it  that  an elementary  and its supertype  in a different  way, every  permissible operations of  values  permitted  subtype  declaration  does  are the same data type variable  declared  in terms  of the subtype  as that of the supertype. t o the supertype.  not introduce of type will  a new data  equivalence. T o put  have  the same  However, it takes its values from  The following  are several  type.  examples  of  set of  a subset elementary  data type hierarchy declarations. Example 5-9. TYPE  ( ManagerSalary  TYPE  ( Open  TYPE  ( GradStudent#  IS S a l a r y  WITH  30000..99999  )  IS BOOLEAN ) IS S t u d e n t *  WITH  "95-"XXXXXX ) TYPE  We certain  ( Sex IS ENUMERATION WITH  n o w clarify the S D B M  extent,  in S D B M  record type  the type  {M,F} )  hierarchy concept with several examples. To a  hierarchy is a convenient  way of creating data types. For  example Example 5-10. TYPE  ( Time  IS  Date  WITH  Hour  : (+99,NUMERIC)  )  TYPE  ( Am  IS Time WITH BEGIN Hour  L E 12  END )  TYPE  ( SpringDate  I S D a t e WITH  Month:  )  IS MonthType WITH 3..5  69  In the first example, the data type additional to  component  be a subtype  Hour which  of NUMERIC.  'Time' is defined  is defined The data  to be a data type  by the data type type  'Date'  used  above  5.2.2. In the second example, the data type  ' A m ' is defined  with the additional  be less than  constraint  that  Hour  of ' A m ' is equivalent to the following  must  HourType which  'Date'  is assumed  is defined  in Section  to be the data type  12. Structurally,  with  'Time'  the declaration  declaration  Example 5-11. TYPE  ( Am  = RECORD WITH Month: Day:  MonthType,  DayType,  Year:  YearType,  Hour:  HourType;  BEGIN Hour Month IF  L E 12, L E 12,  Month  EQ  1 OR 5 OR 7  OR 8 OR  10 OR 12  THEN Day L E 31 ELSE  I F Month  EQ 2  THEN Day L E 28 OR 29 E L S E Day L E 30 END I F ENDIF END )  These  t w o declarations  are, however,  not equivalent.  In the latter  case,  no type  hierarchy is established. That is, the data type ' A m ' declared in the latter example is not a subtype  of 'Time'.  It is a different  data type  with the same structure.  W e can make the  latter a subtype of Time by explicitly adding 'IS Time' to the declaration.  70  Example TYPE  5-12.  ( Am  IS Time  WITH Month: MonthType, Day: D a y T y p e , Year:  YearType,  Hour: HourType;  BEGIN Hour  L E 12,  Month IF  L E 12,  Month EQ  1 OR  5 OR  7  OR  8 OR  10 OR  12  THEN Day L E 31 ELSE  I F Month EQ 2 THEN Day L E 28 OR  29  ELSE Day L E 30 ENDIF ENDIF END )  It  is apparent  economical components type  does  that  the declaration  of  A m in  Example  5-10 has the advantage of  representation. Namely, it occupies much less space because only need  to be declared.  not affect  the type  In S D B M ,  the order  hierarchy. Therefore,  of components  the above  the additional  in a record  declaration  is more  data  flexible  in that it can have its components in any order.  ln  SDBM,  a record subtype  ST is obtained  by adding  information  to a record  T. Information can be added in any of three ways. First, the information that  the set of  components  information  can be added  information  can be  component  so that  added  of  ST contains  by simply through  the new data  adding  the set of components more  redefining type  constraint  the  data  is the subtype  can be added so of T. Second, the  assertions  type  of  type  an  of the original  to T. Third, the existing o n e . This  record third  71  approach these two  has been  illustrated  the  last  example  in  Example 5-10. Any combination  of  will also produce a subtype.  In summary, we are  with  necessary  have the  conditions  following  but  not  rules to  sufficient.  determine  They  are  the  subtype hierarchies. These  used  in  SDBM  to  check  the  correctness of the type hierarchy declaration. 1.  For any type t,  <t,  2.  For any numeric  t>  2  0  data type  t1 and t2,  <t1,  t2>  only if the  of type t1 is a subset of the numeric value set of type 3.  For any boolean data type  t1 and t2,  <t1,  t2>  only  of type t1 is a subset of boolean value set of type 4.  For any set  5.  character  data  For any  enumeration  For any S D B M the following a.  If  data  If  t2,  significance  expected. complex  then The  is  of  a  the  a type reverse,  t1  t2>  if the  boolean value set  t2. only  if  the  character  value  and  t2,  t1  <t1,  t2>  only  if  the  enumeration  enumeration value set of type  and t2,  <t1,  t2>  only  must  be  if  at  t2.  least one  of  of  t2,  then  c2  a component  of  t1  assertion  of  t2,  then  c2  must  be  a  constraint  tl.  type  value  on  type  of c1 must be a subtype of the data type of c2.  constraint  however,  database software  T h i s notation subtype of b. 2 0  <t1,  t2.  conditions is satisfied.  the data type c2  t1  data type  hierarchy  First, it facilitates type checking. The type type  t2,  is a subset of the  record  assertion of  The  and  type  c2 is a component  and b.  t1  value set  of type t1 is a subset of character value set of type t2.  value set of type t1 6.  type  numeric  can  be  summarized  hierarchy ensures that if type t1  can  be  used  in  is  not  true.  This  an incremental  is borrowed from  concept  any  context  property  where makes  in  easier  t2  value  to  <a,  b>  means that type a is a  of is  develop  basis, because once a system is verified  (Albano [1985]).  parts.  is a subtype  a type it  three  and  72  validated  for  may  introduced  be  modelling types  data at a more  ability  in terms  equivalence  in of  on. it  type  this  ( HEIGHT=  MILE  can  of  In fact,  NUMERIC  type  HEIGHT  are  operations  like  declared  with  the  Therefore,  As a final  WINDOW  comment,  with  uses the  data name  For examle,  deals  But  type  mechanism.  hierarchy  WITH  may  for  implications  are  detected. For  not  Data  equivalent.  types  example,  the  that  are  width  and  as follows:  10..100  )  root are equivalent. of  the  contribute  SDBM  they  10..50 )  WITH  specification it  be  be equivalent  database. to  records, the  more  Third, the It  makes  reliable  structural  part  notion  the  of  the  specification  database and the  for the type checking of type  hierarchies.  described the  S D B M type  data type  symbolic values that can be used to objects)  types.  software constraint  SYSTEM  In Section 5.2, we  describe  semantic  semantics  that S D B M  which  )  can  I S NUMERIC  enhances  readable.  accomplish the  data  data types with a c o m m o n  also  only  the  are always different.  MILE +HEIGHT  ( LENGTH  assertion part have different  of  any subtype  increases  distinctive  before  definitions  numeric  TYPE  SDBM  concept  associate  WITH 0 . . 1 0 0  ( WIDTH I S NUMERIC  and  to  data of  WITH 0 . . 1 0 0 0 )  TYPE  development.  to  two  for  hierarchy  have mentioned  a rectangular can be declared to  any two  concise  and  be  hierarchy  system  any  TYPE  equivalent  a set  rule,  type  a means  equivalence. W e  ( M I L E = NUMERIC  illegal  set of  provides  the  is guaranteed  declaration:  Therefore,  5.3  Second,  TYPE  Both  type  that  rule. With  in the following  length  later  general level, it  and  a set  with  of  the  operations external  database functions,  properties  and  data  describe certain for  manipulating representation  however, we  relationships  system. An S D B M  among  roles played by an object these aspect  values. The of  also need mechanisms to objects,  to  specifies a  model  the  SDBM  database.  describe  persistence  of  (or type To  objects, objects,  73  and  to  SDBM of  open  a channel  window  the  SDBM  constructs  For  window  concept, this  purpose,  this  several  section  examples  are informal.  The relevant  data types are also defined.  TYPE  to  communicate  with  will  further  clarify  the  the database. The the basic  concept  specific  syntactic  concept.  explanations  Example  user  system is such a mechanism. Section 4.2.6 has outlined  that support  this  for the database  Window  will  'Student'  be used and w i n d o w  in this  section. O f course, all the  'Course'  are declared  as follows.  5-13.  (StudentType=  RECORD  WITH StdNo:  StudentNumber,  StdName: DeptName: CrsNo:  StudentName, DepartmentName,  CourseNumber  (MULTIPLE),  Section:  SectionNumber  Address:  Address,  PhoneNo:  PhoneNumber  (MULTIPLE),  ) TYPE  (CourseType=  RECORD  WITH CrsNo:  CourseNumber,  CrsTitle:  CourseTitle,  DeptName:  DepartmentName,  Credit:  CourseCredit  ) TYPE  ( C o u r s e S e c t i o n T y p e = RECORD  WITH CrsNo:  CourseNumber,  Section:  SectionNumber,  Instructor: StdNo:  ) TYPE  (DepartmentType=  RECORD  WITH  InstructorName,  StudentNumber  (MULYIPLE)  74  DeptName:  DepartmentName,  Director:  DirectorName,  Address:  WINDOW  (Student=  TYPE:  Address  StudentType;  REFERENCE:  Department(DeptName=  DeptName);  RELATIONSHIP: T a k e ( C o u r s e S e c t i o n ( CrsNo=CrsNo, Sect ion=Sect ion ) ) <-->  IsTaken,  BelongTo(Department( DeptName=  DeptName )  ) <--> KEY:  WINDOW  (Course=  TYPE:  Have;  StdNo  CourseType;  REFERENCE:  Department(DeptName=DeptName);  RELATIONSHIP:  IsOffered(Department( DeptName=  DeptName  ) ) <-->  Offer,  Have(CourseSect ion(CrsNo=CrsNo, ) <--> KEY:  WINDOW  BelongTo;  CrsNo  ( C o u r s e S e c t i o n = TYPE: C o u r s e S e c t i o n T y p e ; REFERENCE: C o u r s e RELATIONSHIP:  (CrsNo=  CrsNo);  BelongTo(Course(CrsNo=CrsNo, ) <--> H a v e , IsTaken(Student(StdNo=StdNo, ) <-->  Take;  75  KEY:  CrsNo,Section  ) WINDOW  (Department=  TYPE:  DepartmentType;  RELATIONSHIP:  KEY:  Have(Student)  <—>  BelongTo,  Offer(Course)  <—>  IsOffered;  DeptName  ) Several points be  defined  in  an  need to SDBM  be  elaborated.  window  seen of  TYPE attribute  through data  that window.  type  CourseType  2  1  .  part  used in the  declaration  part  record  data  aspects  of  of  the  type  used  objects  the  are called attributes  window  attribute  is  in  a  of  the  of  the  are  required  transaction  SDBM  In  schema.  property  that  of  the the  must for  this  that  may  RELATIONSHIP,  which must  objects.  be  call the and  must  values  that  of  might  data  type  and  their  occur in  discussed later  the  on.  The  specified in the  type  component  therefore  REFERENCE,  object  have values  windows  be previously  window TYPE,  will  describe an  object  have  confusion  paper, we  SDBM  used to  different  potential  declaration  describe  attributes  REFERENCE,  a Student  object  eliminate  SDBM  can be  example,  SDBM window  to  are TYPE,  values  Course  identifiers  of the  Interrelationships the  type  data types. This is to  declaration  data type  what  and  are four  subsequently.  Therefore,  StudentType Different  corresponding variable  defines  all, there  specification. They  and KEY. W e explain these attributes  The  First of  to  of  an  descibe  RELATIONSHIP,  SDBM certain  and KEY  window.  affect  declaration  part.  In  necessary  because  insertions other in  or  words,  SDBM  deletions references  objects  and  of  objects  must  be  symbolic  need declared strings  be  specified  explicitly. are  in This  explicitly  W h e n we say that a Student object must have values of data type StudentType, we mean that only the values of data type StudentType can be used to describe the object playing the role of a student. 2  1  76  differentiated. of  the  Such  declaration  referenced w i n d o w  create  or  insert  specify  how  an  is accomplished through  are listed after the  object  with  references should  that can identify the  window  the  data type  transmissions  be  specific objects  identifier  in the  provided.  constraints,  a window  REFERENCE that  For  the  window in  database  given in the  that  data  window  Identifiers  In order to successfully  These identifiers  so  attribute.  designer  purpose, certain  may be  attribute.  example,  REFERENCE  keyword REFERENCE.  established. For this in  corresponding to are  reference  the  property  we  following  be components of  are  Course  also  identifiers  parentheses  must  types  must  secured have  and  the  value  following  reference: REFERENCE: Where  the  Department(DeptName=DeptName)  identifier  Department  DeptName  and the identifier  window  Course.  These  optional,  which  indicates  The  specific  before  the  sign •' = '  DeptName after the  identifiers  are  not  not  every  object  of  the  REFERENCE  identify  a property  of  sign ' = ' must be a property  necessarily  that  implications  must  keys.  depends attribute  on for  The  REFERENCE  some  other  database  window  idenfier of attribute  object  to  operations  is  exist.  will  be  discussed later when we descibe the S D B M transaction.  The  RELATIONSHIP  attribute  is  objects. Let us explain this attribute RELATIONSHIP:  used  to  explicitly  establish  with an example taking from  ) <-->  object  symbolic  string  Take'  and a CourseSection object.  through  which  a  Example 5-13.  Student  object  Section)  IsTaken;  is  the  identifier  for  a  CourseSection in the is  to  establish  a  relationship  relationship  In the inner parentheses, the symbolic string  identifies  of  property  CourseSection objects,  the  between  parentheses identifies  CourseSection object. a  between  Take(CourseSection(CrsNo= CrsNo, Section=  The  relationships  symbolic string  with  an  'CrsNo' 'CrsNo'  a  Student  the  window  object,  i.e.  a  before  the  '= '  after  the  '= '  77  represents  a property  of  Student  objects.  It  is not  necessary for  these  two  identifiers  be identical as in this case. But they must have the same data type. 'Section = the  same  parentheses  can  be  interpreted  similarly.  establish a specific relationship  between two  or  window  inserted  property be  into  value  the  Student  is modified,  passed to  the  its  new  C r s N o and Section, appropriate found,  a  specific  when  CrsNo  its  property  CrsNo value  Based on  will  be  identified  string  'IsTaken'  after  established.  the  by 'Take' but views it from for  two  different  angles. O n one side, he/she is 'taking'  section  is  explicitly define two  Although both  the  'taken' different  there  'Take'  by  are  between  established,  an  two  a student  'IsTaken'  student.  and  are  object  value  used  is created  or/and  Section property  Section  value  will  CourseSection properties If  no  such an object  relationship  will  identifies  the  same  is be  relationship  Namely, a relationship  a course section. O n the specifying  'Take  <-->  as  between  a course section, can be viewed  Through  to  from  other  side,  IsTaken',  we  views of the same relationship.  relationship  relationship  a  a student  Section' in  will be discussed in Chapter 6.  reverse direction.  objects,  course  between  the  and  Otherwise,  '<-->'  two  a  example  sign  property  be retrieved.  established. M o r e detailed implications for data manipulation  Symbolic  identifiers  the values of  CourseSection object will  relationship  property  objects. Whenever a Student  or  CourseSection window.  These  to  identifiers  for  and  'IsTaken'  the  a relationship,  we  relationship  and a course section. In fact,  relationship  is  do in  not  need  order  to  to  establish  establish  once a 'Take' relationship  automatically  established, because they  permits  relationship  are  the is  actually  the same relationship.  The and  specification  Example 5-13  a CourseSection object  between a student We  in  give  establishing  this a  to  be  and a department  restriction relationship  in  the is  the  established from  either  between  side.  However,  can only be established through specification  controlled  by  only the  to  the  demonstrate  database  a Student  designer.  the  relationship  Student  that The  object  the  window. way  of  information  78  requirement may shows that in the real world the relationship that a student belongs to a department  is established  when  is created.  Therefore, it is  the  also  student  natural  to  is registered have  the  instead  above  of when  the  restriction. The  department  RELATIONSHIP  attribute is optional.  Let  us  discuss  the  RELATIONSHIP  attribute.  that  satisfied  must  attribute,  be  however,  relationship.  existence  difference  The REFERENCE by an object  specifies  It states that  the  between  attribute  if it is to  semantic  KEY attribute  representations  of objects  must not conflict with the components window.  is  used  from  external convenience.  impose  associated  specifying  They are not  the  the  semantic  in the  window.  constraint  for  Identifiers  the  WINDOW  constraint  uniqueness used  constraint,  internally to  [ I S <WindowID> WITH TYPE:  keys  in  identify objects.  | = ]  SDBM  the  +  <Relationships>;]  <KeyIDs>]  ) <References>:=<WindowID>(<PropertyPairs>){, <WindowID>(<PropertyPairs>)}  data  KEY attribute be  are  solely  for  The KEY attribute is  <References>;]  [RELATIONSHIP:  a  when seen through that  <TypeID>{,<TypeID>};  [REFERENCE:  [KEY:  of  must exist.  on  after the  prototype of the SDBM class declaration is (<WindowID>  existence  objects.  listed  properties of objects  the  integrity constraint  participating objects  uniqueness  and  The RELATIONSHIP  also optional.  The  attribute  data type declaration. In other words, they must  and therefore the  REFERENCE  the existence of  seen through a window.  of the data type  Apart  to  exist  exist two  But the existence of a relationship will not affect  The  specifies  integrity  for a relationship to  the  79  <PropertyPairs>:=<PropertyID>=<PropertyID>  {,  <PropertyID>=<PropertyID> <Relationships>:=<Relationship>  }  {,<Relationship>}  <Relationship>:=<Relat ionshipID>(<WindowID>[(<PropertyPai rs>)] ) <KeyIDs>:= Notice associated  <--><RelationshipID>  <PropertyID>{,<PropertyID>}  that  with  in  the  multiple  above data  SDBM  types.  collections of properties with different  window  This  syntax  reflects  the  specification, real world  a window  phenonmena  can that  be two  symbolic appearance may be abstracted to the same  conceptual role. Let us use a familiar example that an employer could be an individual, a corporation, or a government one hand, if  organization. This fact  we are interested  can be modelled  in individuals, corporations,  and we can treat them as different  in two  and government  ways. On  organizations  roles and model them with different windows, we can  model the fact with an employer window which has a single data type. We then insert corresponding  individual  objects,  corporation  objects,  or  government  organization  2  2  objects  into the employer window.  On  the  corporations,  other and  hand,  if  governments  we  are  not  as objects,  particularly the  fact  interested  can be  window that has multiple data types. For example:  2 2  T h e 'insert' operation will be explained in Section  in  modelled  treating with  individuals, an employer  80  WINDOW  ( Employer=  TYPE:  PersonEmployerType, CompanyEmployerType, GovernmentEmployerType  ) Let of  us take  a course  example have  a look  can be modelled  5-13, w e have  its o w n properties.  properties  at h o w the fact  of students  in S D B M .  in fact  that a student  in a certain  For convenience, we call this  modelled  S o , they  is enrolled  enrollment.  are modelled  But there  with  and courses. In the following  fact  enrollment. In  an enrollment  the binary  relationship  examples, enrollments  section  does not  through the  with their o w n  properties will be discussed.  It is apparent can  that  an enrollment  be treated as an object  can be viewed  from  t w o different  angles. First, it  and declared as follows.  Example 5-14. TYPE  ( E n r o l l m e n t T y p e = RECORD  WITH StuName:  StudentName,  StdNo:  StudentNumber,  CrsNo:  CourseNumber,  Section: Grade:  SectionNumber,  Grade  )  WINDOW  ( E n r o l l m e n t = TYPE: E n r o l l m e n t T y p e ; REFERENCE: S t u d e n t ( S t d N o= Course(CrsNo= KEY:  StdNo), CrsNo);  StdNo,CrsNo,Section  ) The CrsNo,  above declaration defines  Enrollment  Section, and Grade. The existence  existence  of the corresponding  Student  objects  to have properties  of an Enrollment  object  object  and the Course  StdName, StdNo,  is dependent  object.  This  o n the  approach is  81  similar to  that of the  Alternatively, course  object.  generate  object  is  seen.  ourselves  window.  Here,  to  we  objects  this concept  of  creating  'window'  restricted  among  through  seeing  different  through  object  the  certain  for  discussed  SDBM  the  of  a student  and a  can  simply  we  the  object  same  student  window  kind  concept  through  object  enrollment,  SDBM  window  can also be viewed  the following  of  the  aspects of  the  the  aggregation  have  extend  kinds  as an aggregation  new  we  only to  a  which  Although  proceed  of  Example  data model.  we can view an enrollment  Instead  a new  course  relational  the  objects so  that  window.  and  the  concept,  we  through  the  relationships  Let us  explain  declaration.  5-15.  WINDOW ( E n r o l l m e n t = TYPE: StdNo  OF  Student,  CrsNo  OF  Course,  Section: Grade:  SectionNumber,  Grade;  AGGREGATE: S t u d e n t , Course ) The this  difference  SDBM  there  will  some  window be  no  already  existing  will  of  aggregation.  Notice must  that also  between  the be  In  this  case,  is not  simply  These characteristics  a  following in  new  that  StdNo, the  belong  to  this  CrsNo,  keyword and  Example  objects.  declaration the  In  Section, OF is  and  indicates used  to  single  It  may have  underlying  5-14 other  object  that  words,  from  Grade are that  the  establish  own and  of  which  external  Furthermore, its  is  is a new view  windows  of that window.  objects.  any  of  indicates  window  two  set  in  Keyword TYPE defines the  and a specific object  not  declaration  have from  aggregation.  putting together do  the  AGGREGATE  properties  defined  and  create  All we  the  identifier  property  not  Keyword  construct  window a  does  objects.  used to  declaration  objects.  a specific aggregation  aggregation too.  be  this  declaration  enrollment  objects the  between  view given.  property the  link  such an  characteristics can not  be  82 obtained in  from them.  the TYPE  part  Rather, they  must  be explicitly  of the A G G R E G A T I O N  specified. In S D B M , they  W I N D O W . The detailed  are declared  syntax  of aggregation is  between  a W I N D O W and  given in APPENDIX A.  SDBM  5.3.1  In its  SUBWINDOW  SDBM,  objects.  HIERARCHY  an instance  SDBM  relationship  supports  a  three  is simply level  a relationship  instance  hierarchy,  metawindow.  The metawindow-window  hierarchy, however,  one  metawindow,  of  built-in  WINDOW,  which  every  This levels  of  Instance little  restriction, instance  complex  use. Second,  metawindow  On  through  hierarchy  is not a defect  are sufficient  relationships above these three  practical  object  however,  the other  a more  of the model  Example TYPE  of  is declared  for two reasons. First,  most  the S D B M  as an  data  three  processing phenomena.  type  system  partially  renders  a  subwindow concept provides a mechanism to give an  by adding to the object  information  which  can not be seen  example to clarify the specification of the  hierarchy.  5-16.  ( GradStudentType  IS S t u d e n t T y p e  WITH  AdvisorName: AdvisorPhone:  PersonName, PhoneNo  ) WINDOW  is only  levels are both beyond our comprehension and of  its superwindows. W e use the following  S D B M subwindow  window  and  facility unnecessary.  hand, the S D B M  detailed view  window,  in S D B M .  for modelling  the existence  definition  object,  is trivial in S D B M . There  specific  instance. It is not possible to define new metawindows  i.e.  ( GradStudent  IS Student TYPE:  WITH  GradStudentType;  83  ) A  subwindow  specified  after  for  subwindow  this  subtype  of  hierarchy  is  specified  with  keyword  keyword WITH. The semantics of hierarchy  data type  to  be  StudentType.  hierarchy  can  determine  assuming  that  each  concepts  and  therefore  established,  We  do  the  subwindow  is  associated  type  should  be  this  not  IS.  The  definition  data  hierarchy  need to  type  design  changed be  attributes clarified.  GradStudentType  SDBM  in  automaticly,  a way  because  with  a  unique  window.  They  separated.  In  SDBM,  subwindow  that  are  Firstly,  must  be  the  a  subtype  otherwise  we  are  different  two  relationships  must  are  be  explicitly declared.  Secondly, GradStudent.  the  Additional  RELATIONSHIP Additional of  attrbute  Student  to w i n d o w  as  generated to  of  window  between  objects  is inherited  window  it  also  soon  be  subwindow  When  inserted  is  also  exist  Student  declared to inherited  through  is  inherited  window by  by  window  subwindows.  window  GradStudent.  The  GradStudent.  The  GradStudent. Extra KEY attribute  We  relationship  seen through  an object  into  AMONG  KEY attribute may be  added  identified  The  last  to  model  section Type  is verified,  window  internal  routines  Student.  Upon  Student  be  GradStudent can also be seen  is successfully inserted into w i n d o w  window  will  deletion  of  an  GradStudent, object  from  if such cascade is allowed.  WINDOWS  Section 4.2.7, we pointed  mechanism  be  also be deleted from w i n d o w  CONSTRAINTS  windows.  may  by w i n d o w  as the  Student.  GradStudent, it will  mechanism.  window can  Student  ensure that every object  through  In  of  GradStudent.  Finally,  5.3.2  attribute  REFERENCE attributes  relationships  window  will  REFERENCE  that  out  the  there  described 1 constraints,  are the  limitations three  specialization as a data  different  SDBM  namely  of  the  types  subwindow constraints  of  constraints  hierarchy that  if  an  modelling among  which  is  the  object  is seen  84  in  the first  window  it  must  be seen  in the second window.  This  section  presents the  constructs for modelling Type 2 and Type 3 constraints.  In S D B M , the construct MAYBE is used to record Type 2 constraints.  Let us consider  an example. Example WINDOW  4-17. ( Student  IS Person, MAYBE  Instructor  WITH  TYPE:  StudentType  ) The also  declaration  plays  the  role  specifies that of  specifies that an object IS constraints  MAYBE  an  instructor  and MAYBE  The  SDBM  symmetrical construct both  nature  of  constraints  a student  after  Insertion  By using  is only  an appropriate  Statement Type  2  plays the  will  keyword  different  a student permitted  SDBM be  it  a student  MAYBE,  the  he/she  must  declaration  also  at the same time.  implications  automatically  Insertion  will  window  of  ' b e c o m e s ' a person. With  Statement  in  Section  have  the  Notice that  for the semantics of  to ' b e c o m e ' an instructor.  explained  constraints,  is specified with the Instructor  the role  and an instructor  have very  the IS constraint,  constraint, only  person.  an object  may be a student  data manipulation. With the  a  If  It ' b e c o m e s '  is successfully executed.  same  Because  effect  or if the construct  if  the  of  the  MAYBE  is specified with the  windows.  A example.  Type  3  constraint  is declared  with  the keyword  ISNOT.  Consider  the  following  85 Example  5-18.  WINDOW  ( Student  IS  Person,  MAYBE  Instructor,  ISNOT A d m i n i s t r a t o r TYPE:  WITH  Student  ) The  above  university the  declaration  administrator.  system  will  first  enforces  Eveiy time check  if  it  an object is already  before the system allows an object object  5.4  SDBM  TRANSACTION  modification.  enforcement  completed intact.  defined  into  in the Administrator  can not  the Student  window. it will  SDBM  by performing  system is to be useful, at least four  creation, object provides  removal, object  these  four  be a  window,  In other  words,  first check if the  into  insertion  the above  and object  a different  basic operations  2 3  with  adequate typechecking and adequate window affected  only  successfully. Otherwise, the operation Besides  value  operations  four  operations,  will  window,  deletion.  Object  or in other  Object deletion is to delete an object  from  must  retrieval, and object automatic  integrity  constraint checking.  after these two kinds of checking are be aborted  two additional  because of our conceptualization of data modelling  are object object  be inserted  student  to play the role of a student,  database state can be permanently  kept  is to  a full-time  SYSTEM  provided. They are object  value  The  that  plays the role of an administrator and vice versa.  If a database management be  the policy  insertion  words, a window  to  and the database will be operations  on which is to  give  insert  SDBM  window. That is, it will no longer play the role described by that  also be  is built.  an already  a new role  so that it will  should  to  the  They  existing object.  not be seen in that  window.  Without causing any confusion, we use object values to mean values that are used to describe certain properties of an object. 2  3  86 Object DESTROY  creation  statement;  modification the  is  done  certain  a set  operation view,  by  is  such  primitive. terminates database transaction  such  operation  to  directly  by  statement;  the  statement.  In  is done by the  need  changes to  to  the  be  of  is  important  them.  not  only  primitive  effect  reflect  if  on  be it  the  changes  to  the  and  by  the  object  insertion  together  terms  such a set of Moreover,  achieves  database.  object  integrated  conceptually  either  statement;  addition,  database. In  to  destruction  is  value  done  by  DELETE statement.  'macro' effect  not  object  RETRIEVE  in the  is  any  CREATE  retrieval  operations  should  operation  the  MODIFY  meaningful  interested  without  value  the  constructed  An  by  and deletion  of  conceptually  is usually only  done  object  INSERT statement  Often  is  its  world  system provides a behavioral abstraction facility  order  to  from  desired we  the but  also  effect  user  such an  user's  want  being  effect  abstraction, the  operations. H o w  meaningful  Conceptually,  'real'  of  in  point  conceptually  successfully changes  modelled.  allowing definition  of  to  The  of  or the  SDBM  conceptually  primitive operations.  As stated our  before, the  conceptualization  programming transaction  of  language.  system  to  major  data  modelling  For this SDBM.  objective  of  and  reason, we  Rather,  the  this research is to SDBM  have  is  not  transaction  not  make an investigation  designed  attempted  to  constructs  are  to  be  provide  a  of  database  a sophiscated  centered  around  the  basic behavioral operations such as those mentioned at the beginning of this section.  5.4.1  TRANSACTION  An languages.  SDBM  AS A N  transaction  ABSTRACTION  closely  OPERATION  resembles  The specification allows a user to  the  subprogram  understand  concept  it without  in  digging  implemented. The syntax of a transaction declaration consists of the following 1.  the  name of the transaction;  2.  the arguments, their order, and their data types;  programming  into  how  it  is  four aspects:  87  3.  the results, their order, and their data types;  4.  the body of the transaction.  The  syntax  subprogram  of  is  borrowed  PASCAL-like  from  the  typical  programming  syntax  languages.  for  The  the  parameter  prototype  of  transmission  the  transaction  declaration is  TRANSACTION ( < T r a n s a c t i o n D e s i g n a t o r > <Transact ionBody> ) Below, be  we  will  first address issues  related to  TransactionDesignator. Its  semantics will  clarified. In section 5.4.3, we will discuss TransactionBody in detail.  5.4.2  TRANSACTION  The for  DESIGNATOR  TransactionDesignator gives  the  database  identification  of  manipulation the  a means to  and  transaction  data  is  formal  an  SDBM  parameters  parameters  are  transaction together  further  their  separated  into  designates  parameters that are not  results to  be returned.  When must  be  window  a formal  parameter  is  previously declared in the is legal.  a transaction  returned  accomplished  from by  the  and  specifies data  manipulation.  giving  each  The  transaction  identifier.  designator,  with  be  simply  (pre-defined set of operations) a unique  In  to  identify  following  the  type  identifiers  IN  parameters  modifiable  given SDBM  transaction  or  window  and  OUT  identifier identifiers. parameters.  is  a  set  of  These  formal  The  former  by the transaction, while the latter designates  a type type  or  a window,  or w i n d o w  the  type  system. Any  or  the  window  declared type  or  88  The  prototype  of the  transaction designator specification is  <TransactionID>([<ParameterDefinition>{, <ParameterDefinition>}])  S D B M transactions can be procedural operations which are specified when OUT  parameter  or  when  there  operations  are specified when  uniformly.  <ParameterDefinition> [IN]  are  more  there  than  one  is exactly one  O U T parameter O U T parameter.  there  definitions. But  they  is no  Functional  are specified  is specified as follows.  <ParameterID>:<TypeIDOrWindowID>  or OUT  For  IN parameters, keyword  Below, SDBM  <ParatemerID>:<TypeIDOrWindowID>  we  make  transaction  some  facility.  outside.  IN may be  further  comments  Firstly, all the  Secondly,  omitted.  the  transaction  invisible  The  correspondence between the actual parameters and the formal  and  formal  used. That into the This  parameter is, when  formal  method  is  the  addition,  objects  justified  persistent  value  transaction window  of  the  may  identifier,  because objects  are  transmission-by-result  always  method formal  have the  for  transaction  parameter and the  modifying  final  the  no  parameters  are  parameters according to  lists. Thirdly,  given  their  when  in  the  value of  rather  database  than  globally That will  system  modifying accessible. is, when  be  parameters.  copied Finally,  parameter is specified to  to  the  transaction  and  transaction  is  called.  parameters is established  transmission-by-value the  primary  variables  local to  the  OUT  actual  method  actual parameter  the  For the  of  respective positions in the  parameters, the  the  the  actual parameter cannot be modified  parameter  formal  IN  is called,  is used.  formal  the  designator  parameters are local to  are  by pairing actual and formal  actual  formal  about  is copied  by the transaction. concern  is  parameters,  call is terminated,  the  parameter.  When  with  a transaction.  transaction actual  is  the the  Fourthly,  <TypelDOrWindowlD>  In  is  a a  have objects as its values. For such  89  a formal object.  parameter, the value of the actual parameter is in fact a pointer  However, h o w such binding is implemented should not  TRANSACTION  5.4.3  parts,  definition  type  some specific  be a concern of the user.  BODY  A Transaction Body, corresponding to three  to  declaration,  variable  the  body of  declaration  and  a subprogram definition, statements.  The  consists of  prototype  of  the  declaration part, then the variable declaration part,  and  is [<TypeDeclaration>] [ < V a r i a b l e D e c l a r a t ion>] BEGIN <Statements> END  We  will first describe the type  finally the statement  part in turn. The prototype  of the type declaration part is  <TypeDeclaration>:= TYPE  <TypeID> [=<TypeDefinition>|<SubtypeDefinition>] {, +  <TypeID> [=<TypeDef i n i t ion>|<SubtypeDef i n i t i o n > ] } +  The  prototype  of the variable declaration is  VARIABLE < V a r i a b l e L i s t > : < T y p e S p e c i f i c a t i o n > | < W i n d o w I D > { , <VariableList>:<TypeSpecification>|<WindowID>};  This variables  part can  with a type  be  is  provided  declared, type  identifier  not  directly  ease  model  the  design  variables and  and an object  variable usually has objects of does  to  the  an object  object  of  SDBM  transactions.  variables. A type  variable is defined with a w i n d o w  specified w i n d o w but  Two  variable identifier.  kinds  is specified An  as its values. However, if the  an aggregation of  two  or  more  of  object window  objects, the value  90  of  the object  variable  is this  some existing objects or their  aggregation.  In effect,  an object  variable  is a surrogate of  aggregations. T w o issues should be clarified. They are scope  rules and initialization.  In  SDBM,  (static)  only within their declared  transaction  inside  transaction  scope  a  the and  both  database an  formal design  immediately upon  data  are always  visible  and local.  are only  visible  inside  They  are  destroyed  the transaction.  when  Object  the  variables  objects are permanent and global.  parameters  and variables, uninitialized  because the computer  uninitialized-value.  Temporary  data are always globally visible. All the variables  are temporary  and they  are no exception even though  For  are straightforward.  and persistent  transaction  is terminated  rules  In  SDBM,  all  cannot the  creation to be NULL, which  values could  distinguish  parameters  between and  indicates that they  be dangerous to an initialized-value  variables  are  initialized  have not been  purposely  bound to anything.  The major part of a transaction is a set of statements. These statements are used to accomplish  database  manipulation  functions.  Some  make changes to persistent  data in an S D B M  a database. Others  control  provide  facilities  statements  provide  actions  database and actions that necessary to define  that  retrieve  data  a conceptually  | <TransactionCallStatement>  <CreateStatement>  | <DestroyStatement>  <InsertStatement>  | <ModifyStatement>  <DeleteStatement>  | <RetrieveStatement>  <AbortStatement>  |  | | |  |  <CompoundStatement>  | <ConditionalStatement>  from  meaningful  transaction. S D B M statements are listed as follows. <AssignmentStatement>  actually  |  <IterationStatement>|<AddStatement>|<RemoveStatement>  91  Below, we will discuss these different  types of statements  in turn. ASSIGNMENT  The syntax of the assignment operation is < A s s i g n m e n t S t a t e m e n t s :=  Assignment is the operation object.  It is defined  in S D B M  PASCAL.  The meaning  specified  by  <VariableID>=<Expression>  used to change the binding between  to have a meaning  of  the above  < Expression >  is copied  syntax to  variable  o n the left  data type the  SDBM  is typed,  both  side  specific data  have  can the operation  assignment  the result  pass type  the result  of  objects)  seen through  the right  must  the window  left to bind to that object  can only  of  types.  as that  of  Only  to  and the statement  the S D B M  in  expression  and no explicit  o n the right  when  both  the type  of PASCAL.  be bound  statement  result  is  be used as a statement.  expression  checking. W h e n  has the same semantics  window,  the value  <VariablelD>  returned. Therefore, an S D B M assignment operation  Because  similar to the assignment  is that  variable  a value and a data  causes  and the  sides have the same  is an S D B M  When  a specific  side  the type  object  the object  data  type,  is an S D B M  (or aggregate variable  of  on the  (or aggregate of objects). CREATION  The prototype CREATE  of <CreateStatement>  <VariableID>  INTO  is <WindowID> WITH  (<PropertyValueList>)  This given  built-in  operation  primitive  creates  a new object  by <ClassValueList>. Conceptually, variable  value. provide  This  variable,  which  some operational  could  be viewed  whose  <VariablelD>  as a container  convenience. For example, we often  will of  component  values are  have the object objects,  as its  is specified  need to do some  to  additional  92  operations it from  on the  the  object  database each time we  In order to <VariablelD> window  must  must  of  have been by  window  in  the  will  S D B M will  check the  revelant  objects.  If  be  RELATIONSHIP  their  the  one  of  arribute  then  no  window  is  on  before  that  CreateStatement  specified  will  not and  objects  will  attribute  a new has  does  will  object  been  be  to  the  some  established  can  declared  have its  effect  be seen through  W e will use the following  affect  be  a  the  the  propagated  property  through  of  of  any  object. all its  The  to  the  to  the  be  the  objects. legitimate  establish  the  it  window,  generalizations  determine NULL  creation.  Finally,  successful  referenced the  set to  object  namely  examples to further explain the  of  be any a  superwindows).  all its generalized windows.  two  and  Notice  should  execution (or  use  If  be searched to  the  database,  created. to  be  key  system will  retrieve  will  been  violates  in  dedicated  will  conform  that  object  values will  result  creation  to  object  object  window  the  CreateStatement  is specified, the  are  of  KEY attribute has  permanent  properties  the  must  variable  an S D B M  an  new  as the  of  statement  no  other  created for  retrieve  Firstly, variable  be an object  if the  create  property  exist,  in some  not  window,  creating If  to  execution  the  search fails, corresponding  relationship  that  Namely, it will  them  appropriate  RELATIONSHIP  reiterated  Thirdly,  have to  be satisfied.  <PropertyValueList>  attempt  REFERENCE attribute.  existence. If the  therefore  Values in  Any  must  transaction  data values given in the value list of any  relationship,  several conditions  Secondly, the  schema.  is defined, we  it.  uniqueness constraints  rejected.  such variable  declared in the  <WindowlD>.  SDBM  constraints  the  need  <WindowlD>.  also check the  specified  If no  create a new object,  designated  data type  subsequently.  CreateStatement.  93  Example 5-19. CREATE  x INTO (  Student  WITH  StdNo="lOl1", StdName="Gary  Utter",  DeptName="Computer  Science",  CrsNo="CPSC5l1", Section="00l", Address= Phone=" )  CREATE  y INTO C o u r s e  WITH  ( CrsNo="Comm534", CrsTitle="System  Analysis",  DeptName="Commerce", Credit="1.5"  ) Let us explain the first example. exists  and all the data  is currently  playing  the role  Utter,  his department  phone  number  relationship CrsNo we  type  requirements of a student.  is Computer  is 224-6578.  If the Department  object  are met, an object His student  Science,  number  his address  If the course CPSC511  named will  'Computer  be created. This  is 1011, his name  is 4460  W12th.  exists and it has section  d o not know  what  x will be bound t o this  have value course object.  NULL  section  which  indicates  he 'takes'.  After  he 'takes' the creation  object is Gary  V a n . , and his 001, then the  that he takes CPSC511 in Section 001 will be established. Otherwise,  and Section will  Science'  n o course  properties section or  is completed,  variable  94 DESTRUCTION  The prototype  DESTROY  This  built-in  longer  behavioral primitive,  the  must  desired  database.  from  the entire  which  reverses the effect  database. That  be seen in any window.  conditions  is  <VariableID>  destroys an object no  of <DestroyStatement>  In order  As long  Second, as there  the object  <VariablelD>  is not referenced  is an object  an object  to destroy an object  be satisfied. First, the variable  object.  is, when  of the CREATE  referencing  is destroyed, it can  from  must  a database, two  be already  by any other  the object  from  statement,  bound  to  objects  in the  somewhere  in the  database, the DESTROY statement will be aborted.  When will  an object  is destroyed from  be terminated. Viewed from  a database, all the relationships it participates in  a related object  side,  the effect  is that certain values of  properties that are dedicated to establish the relationship will be modified into  When  the DESTORY  statement  is completed  successfully, the variable  NULL.  <VariablelD>  will be bound to NULL. INSERTION  The prototype  INSERT  of < lnsertStatement> is  <VariableID>(<VarID>{,<VarID>}) INTO <WindowID>  [WITH  (<PropertyValueList>)]  This  built-in  That is, the object  behavioral  primitive  is given a different  inserts  may have the same data type  object  into  a different  window.  role with this operation. The additional data values  needed are given by <PropertyValueList>. window  an existing  <PropertyValueList>  is optional because the new  as the original one. ln this case, all the necessary  95  values are already in the database, and we need not In order  to  insert  an object  First of all, the variable variable  of  the  before  execution,  inserted. object  Such  Such  angles. Thirdly, constraint Any  on  before  the the  attempt  to  window,  REFERENCE  InsertStatement  to  which  means that  when  the  establish  to  certain exists.  of  the  if  the  any.  referenced  attribute  established. a  is  new  not,  system  objects. not  on  the  it  is an examples of the  to  values  be  will  has no effect  the  in  Secondly,  object  to  be  creation  and  from  a  the  different  uniqueness  be rejected.  Fourthly,  SDBM  will  data  will  be  statement  be  established  a  the  in  the  NULL  value,  rejected.  Finally,  may  properties  Notice  check  given  returns  those  InsertStatement.  value  schema.  of  on the  the  SDBM  the  insertion  established.  object  of  view  will  retrieval  INSERT  be an  also check the  use  the  be satisfied.  as object  specified  will  INSERT statement.  The following  want  structure,  exist, an  relationship will  If  to  such  must  statement.  <WindowlD>.  key constraint  specified,  Based  we  has been  does  relationship  relationship can be established or  must  format  bound  operations  conceptual  The  object  be  which  the  The  window  InsertStatement  that violates  the  no  object  to  of  already  KEY attribute  referenced  Otherwise,  must  an S D B M  changes  relationships,  data type  achieved through  the  several conditions  <WindowlD>.  the  locates the  attribute, retrieve  be  if  by  <VarID>  an object  RELATIONSHIP  relationships  object  execution  permanent  to  can be  binding  insert  making  relevant  variable  a binding  retrieval.  conform  window,  again in this  must be declared in the transaction to  designated  must the  a different  <VariablelD>  window  <PropertyValueList>  into  specify them  if that  cause  new  dedicated  the no  to  appropriate matter  successful execution  of  a an  96  Example 5-20. INSERT X 1 ( X ) INTO G r a d S t u d e n t WITH ( AdvisorName="Jim  Jackson",  AdvisorPhone=  ) In 1011  this  when  student  example, variable it was created  x is already bound  earlier  is also a graduate  in Example  student  to a student  5-19. The above  whose student statement  number is  shows  that  this  with an advisor whose name is Jim Jackson and phone  number is 228-9990.  It  is time  to  further  variable  and the S D B M  through  the binding  window  and the object.  type.  For instance  window  Student.  clarify  the concept  object ".  In S D B M ,  2  between This  the variable  we want  not specify the insertion statement  between  and the w i n d o w  example,  to  binding  the variable-object  is because every  in the previous  When  of  insert  variable  variable  binding  the object  belongs  is bound  into  to  window  transaction  is always achieved  and the binding  in S D B M x  the S D B M  between the  to  exactly one  an object  through  GradStudent, we can  as follows.  Example 5-21. INSERT x INTO G r a d S t u d e n t WITH ( AdvisorName="Jim  Jackson",  AdvisorPhone='  ) If forced we it  specification, we have to choose between  can dynamically change the typing will  we keep  2  to use the above  be a variable of w i n d o w  lose  all the benefits  the type  GradStudent. In this  expected  of variable  "This type of binding will  of x so that  from  x. However,  static this  data  choice  be called variable-object  after  two choices. First,  the execution  case, typing.  SDBM  is no longer  The second  is also awkward  binding.  of this  statement typed and  alternative  is to  because w e can not  97  retain  access  another  to  the  object  through  window  GradStudent  any  more  unless  we  make  retrieval.  Therefore,  x1(x) is used in the insertion  and variable x1 must declaration  part  it is bound  Variable x is as described above,  be declared to be a variable of w i n d o w  of the transaction.  established through  statement.  window  With  this  mechanism,  GradStudent  in the variable  a new variable-object  GradStudent. Of course, the object  binding  is the same o n e . This  is  time  to object variable x1. M O D I F I C A T I O N  The S D B M existing object.  ModifyStatement The prototype  is primarily  values of an  of the ModifyStatement is  <VariableID>.<PropertyID>=  <NewValue>:=  designed to change the property  <NewValue>  "<CharacterStr ing>"|<Expression>  <CharacterString>  is  defined  in  APPENDIX  A.  <Expression>  will  be  explained  in  designated  in  Section 5.4.4.  Modification the  prototype  is accomplished  by <VariablelD>  which  indicates  <VariablelD>.  N e w values are obtained  In order be type  satisfied. of  to  First  the  or through  property  to  new  a local  modified.  object  of the object The  by directly  variable  object  relevant  must  Secondly, the uniqueness constraint  conform  a modification data types to  the  to be modified.  is  specified values  evaluation of an expression in the case of  all, various value  be  either  successfully accomplish of  modifying  serves as a surrogate  <PropertylD>  <CharacterString>  the  through  operation,  designated  in the case of  < Expression>.  several conditions  must  be consistent.  type  of  by  must  For example, the  <VariablelD>.<PropertylD>.  specified by the KEY attribute  may be affected  by the  98 operation, specified  because in to  specified. violated object. that  be  any  the  referential  operation. That  new  advisor  exists.  student  Finally,  the  ans  start .a new one.  Let  purpose of  allowed  to  be  uniqueness constraint specified  is, an object  relationships among objects through for  is  constraint  For example, a graduate  the  property  a KEY. Therefore, the  Thirdly, by the  SDBM  must  the  MODIFY  be  checked,  to  when if  attribute  it  it  is  is so  may  be  reference a non-existing  his advisor. W e  statement  even  REFERENCE  may be modified  may change  the  by  modified,  can  be  have to used to  make  sure  modify  the  modifying values of those properties that are dedicated  establishing relationships. In this  case, we terminate  an old  relationship  us take a look at an example.  E x a m p l e 5-22. x1.AdvisorName= " L a r r y After this operation, the object  Peters" bound to x1 through  its role as the graduate  will  have Larry Peters as his advisor. It should be emphasized that only the  of  an  object  permanent. through the  The  variable value  is of  modified a type  with  the  variable  or  ModifyStatement an  object  variable  an assignment. Such modification, however, is temporary  transaction.  The  modification  statement  can  be  and  considered  such  can  be  student  property  modification simply  an  extension  is  modified  and only has effect as  value  within to  the  assignment statement discussed in Section  Notice  that the  modification  statement  changes have been made. Its effect window  changed so that the  dedicate  certain  object  will  create a new  object  no  is to get the property value of an object will  look  relationship, existing relationship  may be established.  not  different, may  or when  be terminated  the  property  and a new  matter  what  in a certain happens  to  relationship  99 DELETION  The  prototype  of  < DeleteStatement>  is  DELETE <VariableID> <VariableID> problem any  of  other  designates the  insertion, objects  in  deletion the  object  of  to  be deleted from  an object  database. This  requires that  is essential to  it  a window. is not  prevent  Symmetric to  currently  the  the  referenced  by  database from  having  specializations is referenced by any other  objects  'dangling references'.  It  is also required  because will if  of  the  inheritance  propagate to it  has  no  because  it  student,  the  time.  he  If  therefore  that none rule  of  of  its  the  SDBM  all its specializations. An alternative  specialization. However, we  is  more role  natural.  of  a  ceases to  cease to  Deletion  of  window  For  example,  graduate  be  believe  student,  a student,  he  must  that  the  deletion that  role  also ceases  an  object  will  not  destroy  the  initialized  object  RELATIONSHIP  DESTORY  value,  variable will not  to  be  be  the  P H D student  object only  allowed  role  at  a graduate  from  a window  will  of  a  plays  object  the  Deletion  object  should  The  some aspects of  as the  cascade  object.  destroyed. Deleting an object  effect  an  of  the  a  same  student,  and  be  the  be a P H D student.  is explicitly  the  an of  database until it  When  of  is that a variable can be deleted  suppose and  hierarchy. The deletion  an i.e.  will  still only  in  means that  no longer be seen.  attribute  is concerned, the  DELETE  statement  has the  same  statement.  object NULL.  will  That  set is, the  indicate any object.  the  variable  designated  variable-object  binding  by is  <VariablelD>  terminated  so  to  its  that  the  100 RETRIEVAL  The  SDBM  RetrieveStatement is straightforward. The prototype is  RETRIEVE  <VariableID>[.<PropertyID> <VariableID>.<PropertyID> [ WHERE  When  some  window  variable  identifier  dot  is a w i n d o w  '.'  should  (<Expression>)  property  values  be followed property  TO < V a r i a b l e I D > { , TO < V a r i a b l e I D >  ]  of an object  are t o be retrieved,  by a dot and the w i n d o w  selection  }]  operator .  Below  2 5  property  the object  identifier.  are t w o examples  Here  of the  RetrieveStatement. Example 5-23. RETRIEVE WHERE  x.StdName  TO stdname, x . A d d r e s s  TO  stdaddress  ( x.StdNo='1234' )  RETRIEVE  x WHERE  RETRIEVE  x.Phone  The 'Address'  first  retrieval  of object  ( x.StdNo='1234'  TO s t d p h o n e  statement  x whose  )  will  student  search  number  the values  of  properties  'StdName' and  is 1234. The values obtained will  be stored  in variable stdname and variable stdaddress, respectively. Also as a result of this  operation,  object variable x will b e bound to the retrieved object through  The  second retrieveal statement  will  retrieve  a Student  the w i n d o w  object  Student.  whose student  number  is 1234. If such a student exists, it will be bound to the variable x.  D o not confuse this operation with the record component selection. In record c o m p o n e n t selection, the variable identifier before the dot must be bound to an S D B M record type instead of an S D B M object through a window. 2  5  101  The  third the  retrieval  bound  to  points  in regard to  of the  SDBM  First,  statement  variable x  2  this  will  retrive  the  value  and assign the value to  6  example should  be  must  have  been  a specific set of  aborted.  The  RetrieveStatement.  be made  previously  in order  declared  be  objects  binding Only  may  those  obtained  objects retrieved.  that  to  need the WHERE clause any more.  property  identifier  designated by the variable  identifier.  Third,  variable  property  Phone  retrieved  student  result.  The  of  the  object  additional  to  further clarify the  an  object  dot  of  stdphone window  phone  must  be  Student.  number.  The  for  if  variable  semantics  operator  used  property  a single  RetrieveStatement  clause  to  of  after the  will the  keyword  object  we  window  same  data  type  as  the  to  store  the  value  of  the  itself  will  a specific  execution  expression bound  to  window  the  used  statement  selection  WHERE  of  be consistent with the  have is  a  been  must  to  otherwise  Boolean  has  the dot  retrieval  using  x  declared  This  Student,  the  variable  have been bound  window  through  Obviously,  following  be  it must  evaluate  do  the  be  be  to  Second,  true will  seen through  WHERE not  'Phone'  RetrieveStatement.  x  or  property  the variable stdphone. Three  Student. And upon the execution of this statement object  of  be  will  not  further  return  an  explicit  discussed in  Section  5.5.  Apparently, queries. More sequence different  powerful  control  data manipulation  facilities  sequence  control  ConditionalStatement, and  2  6  For short, object  which  will  be  alone  functions  can only  in  answers to  very  SDBM.  detail They  subsequently. are  There  are  mean the object  three  CompoundStatement,  IterationStatement.  x will be used to  simple  are achieved by combining it with some  discussed in  facilities  provide  that is bound to variable x.  102 C O M P O U N D  STATEMENT  The prototype  of the CompoundStatement is  BEGIN <Statements> END  A  compound  statement  is a sequence of  and END and are arranged in the separated  by  commas. A  was a single statement. a  transaction  order in which they are to  compound The  incrementally.  statement  compound The  statements which  is treated  statement  internal  in  may  an  be  SDBM  transaction  CONDITIONAL  A  conditional  sequences statement  of  changed  without  it  define  altering  its  principle.  STATEMENT  statement  statement  is  one  execution.  that  A  provides  conditional  alternation statement  in S D B M transaction construction. Its prototype  IF  as if  database designer to  overall effects. This concept is in fact an application of the aggregation  BEGIN  be executed. Statements are  enables the  structure  are enclosed with  of  is  two  also  or  more  treated  as  different a  single  is  <Expression>  THEN  <statement>  [ELSE  <statement>]  ENDIF  The  execution  sequence is controlled  by  a test  on  the  Boolean expression. If  the  expression is evaluated to be true, the statement  after THEN is evaluated; if the expression  is  specification, the  evaluated  to  be  false  and  there  is an  ELSE  executed; otherwise, the conditional statement or  ELSE must  conditional  be a single statement  statement  is  ended  with  after  is entirely skipped. The statement  or something that is treated the  statement  keyword  ENDIF  which  ELSE  after THEN  as single statement. is  used  to  is  eliminate  The any  103  syntatic  ambiguity. ITERATION  There are two  STATEMENT  kinds of  <ForStatement>  To  suit  statement provides  database  from  iteration  | <WhileStatement>  applications,  programming  iteration  statements:  SDBM  languages  has  with  a  borrowed little  two  modification.  over all objects of a window. The prototype  FOR  EACH < V a r i a b l e I D >  different  kinds  of  iteration  kind  of  iteration  One  of the statement  is  DO  <Statement> This as the each  statement  resembles counter-controlled  FOR statement object  of  a  in FORTRAN  window,  repetition  in  programming  and A L G O L . The difference  whereas  FOR  statement  in  languages such  is that this iteration  programming  languages  is over is  over  integers.  Three  points  <VariablelD>  are  worth  mentioning  is  to  each object  executed  Third,  the  FOR  statement.  First,  variable  must be declared in the variable declaration part of the transaction to  object variable. Second, the iteration bound  about  and  statement  the  of  the  binding  <Statement>  is unconditional. That is, variable  window can  not  must  a single statement, e.g. a c o m p o u n d  The other  type  of  iteration  <Statement>  DO  turn.  be  For each object,  changed  by  be a single statement  the  statement  execution  of  will  be  <StatementlD> the  or something that  statement.  is treated as  statement.  statement  a specified condition. The prototype  WHILE < E x p r e s s i o n >  in  <VariablelD>  be an  provides a facility  of the statement is:  to  terminate  the  iteration  on  104  In  the  evaluated  WhileStatement, the  first.  Otherwise,  If  the  it  is  expression, wich  evaluated  WhileStatement will  to be  be  must  true,  be  a Boolean expression, will  statement  skipped. Each  time  < Statement >  after  statement  is  be  executed.  <Statement>  is  executed, the expression is re-evaluated. A B O R T STATEMENT  As  stated  previously,  we  handling  facility  in  However,  execution  of  SDBM.  an S D B M  do  transaction  not  if  intend  to  provide  need  at  least  we  certain condition  a  one  can not  user-specifiable  exception  mechanism  stop  to  the  be satisfied. AbortStatement  is provided for this purpose. Its syntax is simple. <AbortStatement>:=  The specified  meaning and  of  this  undo whatever  ABORT  statement  is  that  it  has been done.  will  stop  U p o n the  the  transaction  completion  of  wherever  it  this statement,  is the  database should be in the same state as if the transaction had never been executed.  5.5  EXPRESSIONS  Viewed are  one  as a programming  of  the  statements when  basic  language, S D B M  syntactic  a value needs to  constituents  precedence  basic of  issues  SDBM  associated  of  SDBM  oriented. Expressions  statements.  be computed. The formal  is given in APPENDIX A and will not  The  is basically statement  syntax  They of  are  used  in  S D B M expressions  be repeated here.  with  SDBM  operators, and typing  of  expressions SDBM  are  the  syntactic  form,  the  expressions. Below, we discuss these  issues in turn.  SDBM arithmetic,  expression are constructed boolean, and relational  in the mixed syntactic form with the infix  operations  and the  prefix  form  for  transaction  form  for  calls and  105  ADT  operation  In  calls.  SDBM  expressions,  the  following  operations  including  EQ (equality),  equal  to),  LT (less  than),  AND  (conjunction),  including  +  OR  (addition),  including - (negation) operation  and  -  NE (inequality),  LE (less  (inclusive  than  *  are  permitted.  C T (greater  or  disjunction),  (subtraction),  and +  operations  equal  and  to),  NOT  (multiplication),  (absolute value), the dot  are  relational  than),  CE (greater  Boolean  operations  (negation), and  They  /  arithmetic  (division),  than  or  including operations  unary  operations  operation, transaction calls, and ADT  calls.  Following  the  convention  precedence of these operations  of  many  programming  languages,  SDBM  defines  the  as f o l l o w s . 2 7  EQ NE GT GE  +  LT  -  +  /  LE  OR  -  AND  Lowest  Priority  above  precedence  The indicated  in  the  *  grammar,  NOT  ADT  Call  Dot  Operator  Highest  is the  incorporated  into  the  of  an  precedence  grammar  Priority  for  expression  SDBM can  be  expressions. As changed  with  parentheses.  SDBM be in  statically SDBM  expressions are typed. That determined  are well  at  compilation  typed. Therefore,  is, every S D B M time  there  of will  S D B M expression that has been type checked to  expression has a type  an S D B M be  no  schema.  which  Syntactically, expressions  execution-time  type  errors  with  be syntactically correct.  + and - operations that have the same precedence as the OR operation are binary operation. 2  7  can  an  106  To SDBM  conclude this section, we  expressions. The following  Example  make a further  two  discussion of  the  dot  operator used in  examples are used for this purpose.  5-24.  y= x.DeptName z= x.BelongTo In the first example, the dot is  already  DeptName must  bound  to  a  Student  of  object.  In the  the  be declared to  object.  have the  In  the  second  x.BelongTo  will  return  x.  The  object  example, the  In data  properties  in  multi-valued  that  participates  a  operator  department  object  MULTI-VALUED  2.1.3,  that  we  property  SDBM.  Such  properties  many-to-many  dot  is  will  the  domains  must  not  relationships  only  between  will  return  is then  is in  used  which  the  of  for  the  student  property  variable y  DeptName of  the  relationship  relationship  the  value  assigned to  property  the  selection. Here, variable x  which student  selection,  BelongTo with x  belongs  to.  object In  the  be bound to variable z. Variable z must have  Department.  PROPERTIES  identified  properties  property  as the  the  department  ON  value  same data type  be an object variable of  Section  model  here  x. DeptName  example, the  an object  returned  OPERATIONS  5.6  object,  example,  returned  been declared to  operator is used for  inadequency be  of  atomic.  We,  are specified with provide objects  a  the  natural  and symbolic  the  restriction  therefore, keyword  description string  in  the  permit  multi-valued  MULTIPLE. of  values  relational  In  SDBM,  one-to-many but  and  also provide  a  natural description of one-to-many and many-to-many relationships between objects.  However, 'real' of  world,  we  multi-valued  at  the  same  have to  deal with  properties.  is only valid  for  time  For  we  improve  some  example,  the  difficulties the  modelling  of  static  structures  associated with the  modification  operation  single-valued properties. This section discusses  of  the  behavioral aspect  defined  in  operations  Section provided  107  for  manipulating  multi-valued  properties.  ADDITION  5.6.1  A  new  value may need to  an employee joins an additional ADD  be  added to  project.  a multi-valued  property,  The syntax of this operation  [<VariableID>|"<CharacterStrings>"]  for  example,  when  is as follows:  TO  +  <WindowVar i a b l e I D > . < P r o p e r t y I D > Where  <VariablelD>  property If  the  an  should  <PropertylD> property  existing  is a REFERENCE  object  so  the  the  value  Otherwise, the  relationship  requirement  the following  two  can not  added  have to  the  same  new value to be  be  established.  must  property.  data  type  as  the  a specific value of that data  also  lead  added  If  the  to  an  be established. The KEY constraint  must  The A D D statement  must  type.  lead  to  is  a  property existing  object.  be checked,  if  is illustrated  in  5-25.  ADD  "'Blue','Yellow'"  TO  the  first  and  it  t.Project  variable should  x  has  be  the  already to  a Part  TO  y.Color  data  type  bound  to  used a  to  define  value  of  the  that  Project  type.  In  property the  of  second  object.  REMOVAL  To property. has  be  the  can  is specified with the  example, variable y is bound  5.6.2  to  x  Employee  then  reference  ADD  in  to  examples:  Example  Where  declared  property,  that  property,  unique  been  and should be already bound  RELATIONSHIP  the  have  only  remove  a value from  a property  For example, an employee one  disassociate the  color  instead  employee from  of the  reverses the  may drop two  as  project  effect  a project,  recorded and correct  of  or we  previously. the  color  adding  that value to  may find  out  Therefore, information  the  that a  part  want  to  recorded  for  we  108  the  part. These desired operations can be expressed as follows: E x a m p l e 5-26. REMOVE  p  REMOVE  "Yellow"  Where to  FROM  t.Project FROM  y.Color  p is a variable that has the same data type  a value  object  indicating  the project  to be removed.  as the project Variable t  property  is b o u n d  and is bound  to the Employee  and variable y is bound t o the Part object.  The  syntax of the REMOVE statement is:  REMOVE  [<VariableID>|"<CharacterStrings>"]  +  FROM  <Var i a v l e I D > . < P r o p e r t y I D > Where  <VariablelD>  meaning  as defined  statement  will  <StringList>,  ;  in  terminate  statement will terminate  Section  5.6.1.  a reference(s).  If If  and  the property the property  <PropertylD> is  a  have  REFERENCE  the same  property,  this  property,  this  is a RELATIONSHIP  a relationship(s), t o o .  MODIFICATION  5.6.3  The  modification  operation  operation  There  a single value  only  to  be defined  in Section  assignment  for  <VariablelD>,  in this  section  and the modification  can be operated o n . The syntax  is an extension  operation  in Section  of the modification  multi-valued properties is: <VariableID>.<PropertyID>= NULL|"<StringList>"|<VariableID>.<PropertyID>  The following  are three examples of the modification operation:  of the  operation  109  Example  5-27.  x.Color= NULL x.Color=  "'yellow','White','Black'"  y.Project= As have  the  result  of  z.Project this  a NULL value, which  first  means that we  has. The second amodification black. With  the  modification,  the  do  multi-valued  not  indicates that the  third modification,  object  y will  know  part  property  what  has three  have the  color(s)  color  of  the  part  parts object  colors, yellow, white,  same project  will x  and  values as object  z  has.  The  modification  operation  discussed  here  REFERENCE, and RELATIONSHIP properties as the has. From now modification  statement.  on, we will  not  has  the  same  implications  for  KEY,  modification operation discussed in Section  make difference  between assignment statement  and  110  6. AN APPLICATION EXAMPLE OF SDBM In  chapter  5, we  outlined  the  database model, S D B M . To further use to  SDBM  SDBM  principles of and  their  project  model  itself,  of  and the  a proposed semantic  underlying  rationale, we  manage information  shall  related  namely  using S D B M to design databases is the  same as that used  the  modelling  two-view  conceptualization  data abstraction. The design of S D B M  of  data  and  databases begins with identifying  the  objects  roles.  Constraints external  data  Others  are  are  classified  representation related  to  modelled with S D B M the same objects  The  the  of  management system.  basic methodology  design  clarify  design a database. The database is designed to  a hypothetical  The to  to  basic elements and structures  into  categories.  aspect, and  objects,  windows.  roles,  Some  therefore and  constraints  should  their  Then, these windows  be  structures  are  modelled and  is carried  possible roles that we  out  through  are interested  studying  related  with  SDBM  therefore  are  to  objects  and  the  types. naturally  are refined so that different views  may be generated according to the different access  refinement  only  of  requirements.  roles  they  in should be identified, and then the  play. All  the  relationships or  constraints are analysed and classified.  The  further  with,  the  most  with  or  without  refinement general added  is accomplished through  situations detail,  are  more  considered to  the specialization mechanism. To begin generate windows  specialized windows  detail is arrived at. The same process is also applied to the  data representation  that are related to  the  of  the  database contents  are  at  desired  S D B M types that serve to  provide  data representation. The mechanism of  until  level. Then, the  and maintain  generated  this  semantic integrity aggregation  constraints  is also used in  111  the  design  allowing the  of  an object  user to  In  SDBM  database. The  window  (or  this  the  a type)  chapter, system.  we  will  Then,  first  more  to  give  actual design. Because the  of  participate (or  will  this  mechanism  in certain  be  to  For example, some data types will  demonstrated  relationship without  description added,  make the  not  of  where  system is used only to  have tried  is  by  forcing  type).  a general  detail  in a concrete manner, we  possible.  application  know the details of that w i n d o w  management through  an S D B M  the  hypothetical  project  necessary, when  we  go  demonstrate the features  of  example as simple and short as  be defined  if they are obvious and if  no  confusion is caused.  A  6.1  HYPOTHETICAL  A  large  manufacturing  operations.  Some  department  may  Other projects  For it  PROJECT M A N A G E M E N T  projects install  company are  an  are contracted from  normal  operations,  is divided functionally  the  into  often  launched  electronic  SYSTEM  internally.  accounting  from  For  each  company  individual departments to  Sometimes, finished,  their  employees, individual department.  extra  people  employment  and  other  departments. W h e n the  is  a team the  are  of  hired  terminated.  permanent  project  besides  example,  system  for  the  the  its  normal  computer  service  department  of  finance.  organizational  structure.  Namely,  such as administration,  A different  employees  is  structure set  up  finance,  marketing,  is adopted for by  project  assigning employees  project.  employees will A  For  has an ordinary  several departments  project,  projects  outside clients.  engineering consulting, R&D, and manufacturing. management.  undertakes  be  specially In  this  called  employee  for  a  chapter, permanent of  the  project. we  call  When these  the  people  employees. They company  must  is completed, they will go back to their own  are  project  is  temporary hired  belong  to  departments.  by a  112  For only  each project  a permanent  principal  team, there  employee w h o  is a principal  manager.  has completed  It  is the  his/her training  company's policy  period  manager. A teams may also have an assistant manager w h o  is allowed  could  to  that be a  be a temporary  employee.  Permanent employees be  paid  are  outside  restriction  AN  objects, we and most  start  terminated  of  properties, with  that  restricted  client  roles  the  their  the  different these  (views)  of  simplifying  ceases  to  exist.  most  specifications:  To  A  knowledge  roles of  objects.  define  both  not  temporary  of  allow  be  within  them  will  any  employee  North  America.  demonstration.  team  will  be  projects, which  A  contract  dissovled if  includes  employee for a  information of  objects  simplify Here,  the  SDBM  requirements  the  conceptual  project  the  assigning  project.  the  definition  employees,  database  roles  analysis  structure  management  and proceed to  general roles, because many other  mechanism.  and  DATABASE  necessary  basic  to the  and hiring a temporary  roles. To of  work,  does  locations  is assigning employees to  all  department  overtime  company  and relationships. To design the  among  own  at the same time.  purpose  the  have the  identifying  general  specialization  if  interest  so that we  considered  projects  the  assume  constraints  kinds of  The  PROJECT M A N A G E M E N T  us  completed  projects.  employee to a project  SDBM  Let  with  for  The operation  6.2  rates vary  solely  is terminated.  their  For their  have  project  by  projects.  we  will  monthly  their  clients,  project  a permanent  paid  by  than two  is  be  are  hourly  and  on more  For This  paid  hourly  to work  employees  analyse the  projects  and  can be we  been  consisting  database in  process, we  schema,  has  of  SDBM,  relationships  begin  with  the  clients  may  be  through  the  derived have  to  give  two  113  1.  the conceptual objects, the  2.  properties,  of the application  and relationships  to be modelled. This concerns h o w  among  objects  are viewed  conceptually by  user.  the  computer  represented  The former with by defining  Let  structure  data  representation.  in computer  That  is  how  the  conceptual  structure  is  processable symbolic strings.  is specified by using  the S D B M  window  concept  and the latter is dealt  proper data types in S D B M .  us start with  employee  objects. W e want to record  the ID, name, address, and  phone number for each employee. These employees can be modelled as follows. TYPE  ( EmployeeType  = RECORD  WITH EmpID:  EmpID,  EmpName:  EmpName,  Address:  EmpAddress,  Phone#:  Phone#  )  WINDOW  ( Employee  = TYPE: KEY:  EmployeeType; ID  ) The To  meaning  of data types  give an example, we define  TYPE  ( Phone#  EmpID, EmpName, EmpAddress, and Phone# are obvious.  data type  = CHARACTER  Phone#.  WITH  '('999')  '999'-'9999  OR  999'-'9999 )  The legitimate taken phone  into  telephone  consideration  numbers.  numbers that  it  are for example  (604) 228-8651  may not be necessary to record  and 224-1973. W e have the area code  for local  114  Assume name,  that  w e are interested  code, category,  start-date,  in the following  end-date, budget,  information  and total  cost  about  each  project:  its  to date. The following  are the definitions of the corresponding data type and window. TYPE  ( ProjectType  = RECORD  WITH PjtName:  PjtName,  PjtCode:  PjtCode,  Category:  PjtCategory,  Start-Date: End-Date: Budget: Cost:  Date,  Date,  Money,  Money;  ) WINDOW  ( Project  = TYPE: KEY:  ProjectType; PjtCode  ) Data type TYPE  PjtCategory can be defined as an enumeration data type.  ( PjtCategory=  ENUMERATION WITH {Consulting,  Repair,  Manufacturing,  Research}  ) To Other  model  interesting  client  objects, w e assume that  information  includes  client  each client will  name,  address,  be assigned a special ID.  and phone#.  following specification. TYPE  ( ClientType  = RECORD  WITH CltlD:  ClientID,  CltName: Address: Phone#:  )  ClientName, ClientAddress, Phone#  W e have the  115  WINDOW  ( Client=  TYPE: KEY:  ClientType; ID  ) Among  the data types  ClientID,  ClientName, ClientAddress, and Phone#, ClientAddress  is the most  interesting.  ClientAddress can be modelled  Its definition  must take  into consideration the difference  with  the S D B M  between  record  data  type.  the American postal code  and the Canadian postal code. TYPE  ( Address=  RECORD No  WITH : IntegerNo,  Street  :  City  CityName,  :  StreetName,  VARIANT State  :  Country  StateName, : {U.S.A.},  PostalCode  : USCode,  VARIANT Province Country  : :  PostalCode  ProvinceName, {Canada}, :  CanadianCode;  ) Postal  TYPE  codes  ( USCode  are defined  as  follows.  = C H A R A C T E R WITH  9(5)  ) TYPE  ( CanadianCode  = C H A R A C T E R WITH  9A9'  '9A9  ) The above specification dictates state  names  that if the country  and use the American postal  is U.S.A., w e must write American  codes, and if the country  write Canadian provincial names and use the Canadian postal codes.  is Canada,  w e must  116  So  far, we have  been  concerned  with  details are needed. Let us consider project  There are t w o types internal  projects,  w e need  to  know  at a very  general  level.  More  objects in a further step.  of projects. They are internal  properties defined for project TYPE  information  the names  of  projects  and contract  their  clients  IS P r o j e c t T y p e  WITH  in  projects. For  addition  to  those  in include  client  objects in general.  ( InternalProjectType  CltName:  InternalClientName  ) WINDOW  ( InternalProject TYPE:  IS P r o j e c t  WITH  InternalProjectType  ) For ID,  contract  client  projects,  name, contract  additional  properties  c o d e , and amount  which  of money.  we are interested Contract projects  can be modelled  as follows. TYPE  ( ContractProjectType CltlD:  IS P r o j e c t T y p e  WITH  ClientID,  CltName:  ContractClientName,  ContractCode: Amount:  ContractCode,  Money;  ) WINDOW  ( ContractProject TYPE:  IS P r o j e c t  WITH  ContractProjectType;  REFERENCE:  Client(CltID=CltID)  )  In This  the definition  constraint  of w i n d o w  ContractProject,  states that a contract  project  must  w e have  given  a referential  have at least o n e outside  constraint.  client  if it is  117  to  be created  destroyed  roles  At the same  time,  an outside  client  object  cannot be  if it has at least o n e contract with the company.  Now, objects,  in the database.  w e consider  when  viewed  at the same  some  from  time.  employee or a temporary  For temporary WINDOW  different  different  roles  of an employee.  angles,  For example,  an employee  in our case,  Like  any other  may appear  an employee  real  to play  world  different  may be a permanent  one, a trainee or a manager.  employees, the corresponding object  ( TemporaryEmployee TYPE:  class can be defined as follows.  IS Employee  WITH  EmployeeType  ) Here, same  the data  as that  necessary  of window  to add more  demonstrates concept.  representation  the flexibility  For a permanent started working TYPE  Employee. details  Here, data type  aspect This  in order  gained  from  of w i n d o w  TemporaryEmployee  is an example to generate separating  which  illustrates  a specialization. This  the type  concept  is exactly the that  it  is not  example  and the  window  EmployeeType has two sets of instances.  employee, we need to know  his/her deparment  and the date  for the company.  ( PermanentEmployeeType  IS EmployeeType  DeptName:  DepartmentName,  Start-Date:  WITH  Date  ) WINDOW  ( PermanentEmployee TYPE  IS  Employee  WITH  : PermenentEmpoyeeType  ) TYPE  also  ( DepartmentName=  ENUMERATION  WITH  {Administration,  Finance,  Marketing,  he/she  118  Engineering  Consulting,  R&D,  Manufacturing}  Among properties property  permanent  that that  employees,  an employee he/she  some  are newly  and a permanent  has a permanent  employee  hired  trainees.  In  employee  has, a trainee  as his/her  supervisor.  addition  to the  has a special  Let us first  define  those employees w h o are not trainees. WINDOW  ( Nontrainee IS  PermanentEmployee,  ISNOT T r a i n e e TYPE:  WITH  PermanentEmployeeType  )  TYPE  ( T r a i n e e T y p e IS PermanentEmployeeType Supervisor:  WITH  EmpID  ) WINDOW  ( Trainee  IS Permanentemployee TYPE:  WITH  TraineeType;  REFERENCES: N o n t r a i n e e ( E m p I D = S u p e r v i s o r )  ) In  the above  he/she must  definition, w e have specified constraints  be a permanent  that  the supervisor must  exist,  employee, and he/she must not be another trainee. A special  group of non-trainees are the principal managers of projects. They are defined as follows. TYPE  ( ManagerType  IS PermanentEmployeeType PjtCode:  WITH  ProjectCode,  ) WINDOW  ( Manager  IS  PermanentEmployee,  ISNOT T r a i n e e TYPE:  WITH  ManagerType;  REFERENCE:  Project(PjtCode=PjtCode)  119  ) Obviously, managed  the existence  of  exists. All the objects  let  us define  is  specified  properties  a collection to  be  the  a manager  we have so far dealt  of more  abstract  relationship  that  of an assignment  can only  include  objects an  employee  make with  which  sense  if  the project  are somewhat  to be  concrete. N o w ,  are assignments. An assignment  employee  is  assigned  to  ID, employee name, project  a  project.  The  code, and date  of the assignment. TYPE  ( AssignmentType=  RECORD WITH EmpName: EmpID:  EmpName,  EmpID,  ProjectCode: Date:  ProjectCode,  Date  ) WINDOW  ( Assignment = TYPE:  AssignmentType;  REFERENCE:  Employee(EmpID=  Empld),  Project(PjtCode= KEY:  EmpID,  ProjectCode);  ProjectCode  )  Conceptually, object object  an Assignment object  and a project must  assignment  to  exist be  object.  in  order  is defined  W e enforce to  an aggregation  have of  that  the  to be an aggregation  both  the employee  assignment.  an employee  object  Alternatively,  object  we  and a project  of an employee and the  project  can define object  an  without  creating any new object.  We permanent  notice  that  assigning  a  temporary  employee. To assign a temporary  employee  employee  is  different  from  assigning  a  is to hire him or her for a project.  He or she may be hired for several projects at the same time. Assume that the temporary  120  employee may  be  is paid  by hour  different  and that  for different  the minimum  projects.  assignment with the additional property TYPE  rate  For simplicity,  is $3 per hour.  temporary-hiring  The hourly  rate  is defined to be an  Rate.  ( TemporaryHiringType  IS A s s i g n m e n t T y p e  Rate:  WITH  Rate;  ) WINDOW  (  TemporaryHiring  IS Assignment TYPE:  WITH  TemporaryHiringType  )  and data type  Rate is defined to be  TYPE  ( Rate  Another interesting  = NUMERIC  Though represented example include  a  a project project  employees  in  )  team which  is the result of assigning  It is reasonable to assume that a project  has only  one team and  only for one project.  this by  3..99  concept is that of a project  employees to a project. a team is formed  WITH  one-to-one single  object,  we  suggests  notice  their  that  a project  conceptual  and its team  differences.  may be  Consider  may exist before a team is created for it. Properties of the team  code, the  relationship  project  team.  AssistantManager property  name,  Because  principal a  team  manager, may  is signified to be optional.  not  assistant have  manager, an  object  and number  assistant  for  manager,  of the  121  TYPE  ( TeamType=  RECORD  WITH ProjectCode:  ProjectCode,  ProjectName:  ProjectName,  PrincipalManager:  EmpID,  AssistantManager:  EmpID  NoOfEmployees:  (OPTIONAL),  Integer  ) WINDOW  ( Team=  TYPE:  TeamType;  REFERENCE: Manager(Empld=  PrincipalManager),  Manager(EmpID=  AssistantManager),  Project(PjtCode= KEY:  ProjectCode);  ProjectCode  ) The hypothetical  data  types  project  and windows management  declared  database.  above  This  part  formed is  the  sufficient  basic to  structure  establish  of  an  the  empty  database in the computer.  However, we also need to define  several operations in order to  manipulate  SDBM  be  transaction  6.3  the  database.  database  operations  can  defined  with  the  SDBM  facility.  TRANSACTIONS  F O R E N D USER  As we pointed  OPERATIONS  out previously, transactions  are the only  means for the end user to  operate o n an S D B M database. Transactions are designed to ensure that certain behavioural constraints are observed when the database is altered by the end user. In this section, we will define several e n d user operations in terms of transactions.  First  of  all, w e will  team. To complete assigned to more into  define  the operation  of  assigning  an employee  to  a  project  such an operation, w e must first test that the employee has not been than two teams. If this  the corresponding  window.  is true,  The number  of  a proper employees  object  is created and inserted  in the corresponding  project  122  team  must  also be increased by one.  TRANSACTION  ( Assign  ( i d : EmpID, n:  EmpName,  pc:  ProjectCode,  d:  Date,  OUT  a:  Assignment  );  VARIABLE i:  Integer,  x:  Assignment,  t:  Team;  BEGIN Count(id, i ) , IF  i GT  3  THEN  ABORT  ELSE  CREATE (  X  WITH  EmpName=n, EmpID=id, ProjectCode=pc, Date=d  RETRIEVE  ),  t  WHERE  ( ProjectCode=pc),  t.NoOfEmployee=  (t.NoOfEmployee  +  1)  END  ) Of another been the  course, we transaction  assigned to. database.  assume that the  Count This  is called to  is a very  project find out  simple  has been how  transaction.  initiated.  In  many teams the In  fact  it  does  the  transaction  Assign,  employee  has already  not  anything  alter  in  123  TRANSACTION  ( Count  ( i d : EmpID,  OUT  i : Integer  );  VARIABLE y:  Assignment;  BEGIN i = 0, RETRIEVE  y WHERE  W H I L E y NE N U L L  (EmpID=id), DO  BEGIN i =i +1 RETRIEVE  y  WHERE  (EmpID=id)  END END  ) More what of  kind  realistically, when of employee  employee  temporary  should  w e assign an employee  team, we usually  he/she is. Therefore, the assignment operations  also  be defined.  employee, which is defined  TRANSACTION  to a project  Consider  for example  the operation  as follows.  ( HireTemporary  ( i d : EmpID, n: ta: ph:  EmpName, EmpAddress, Phone#,  p:  ProjectCode,  d:  Date,  r : Ra t e ) ;  VARIABLE a:  AssignmentType,  e:  Employee,  te:  special to that  TemporaryEmployee,  th: TemporaryHiring;  of  know kind  hiring  a  124  BEGIN CREATE  e WITH ( ID=id, Name=n, Address=ta, Phone#=ph),  INSERT  t e ( e ) INTO  TemporaryEmployee,  Assign(id,n,p,d,a), INSERT  t h ( a ) INTO WITH  TemporaryHiring  ( Rate=r)  END  )  6.4  SUMMARY  In  this  demonstrate database  chapter, the concept,  model  hypothetical the structure,  S D B M . Although  appear to be fragmented. the model.  a  many  project  management  and the modelling examples  O u r goal in this  have been  database  is  methodology given  to  of the semantic  in chapter  chapter is to give a more  designed  5, they may  coherent  picture of  125  CONCLUSIONS  7.  In  this  thesis, we  models,  particularly  recently  proposed  model,  SDBM,  SDBM model  have addressed the  the  relational  semantic  data  data models.  is designed offer  to  attack  the  of  all,  we  we  model directly  believe  see  their  nor  relationships  computer reflected Viewed  that  computer  data by  from  data  because  window the  this  also  discussed  investigation,  of  the  data  among  the  features  a semantic  of  database  these  a more  concept SDBM  should  be  representations.  We  objects  and  window  in  a  that Rather,  data point,  the  viewed  relationships situation  general  of  the  relational  data  semantic data models. The rest of  modelling  real world  computer  primarily  this  way  different  from  other  data  What  is more  important is that  conceptualization.  and  representations.  problems  is simple and effective.  Roles can be modelled with S D B M SDBM  on  over other  data  modelling  properties,  mapping  see  itself  reflects this  objects,  one-to-one  Based  have  data  ideas presented in this thesis.  conceptualize  models. The conceptualization  We  We  modelling  some improvements  chapter will summarize some major  our  model.  associated with conventional  is developed.  and to  First  shortcomings  is  to  be  be their  or  a role windows.  class  concept  is  modelled.  From  it  can  Roles  is not be  that  certain  Notice that there  built  of  other on  conceptually different from the class concepts of other  a  the  nor  can  are similarities  different  data  by  we  of  these directly  of  objects.  properties.  between  models.  the  However,  conceptualization,  semantic data models.  a  properties,  be  aspects  is  side,  reflected and  side,  image  a collection  semantic  one  other  objects,  should  of  From  This  directly  are  is an abstraction  concept  sides.  objects.  roles  representations.  two  these  realize that  should it  among  from  it  is  126  As  mentioned  before,  we  envision  that  there  exists  consisting of objects, properties, and relationships, which the  'real' world.  which an  O p e n a window.  is characterized  object  another  or  a  role  have seen, the  Clearly,  being  underlying  the  Open played  structure  concept  of  these  objects,  while  the  properties.  another  window  by  same  the  as a whole  window  semantic data models. Talking about we find that 'instances' of  of  in  instances of  instances of  the  in  a different  object.  No  manifest  direction,  and  how  extends  the  a class as in other  can be either  a class  of  concept  other to  object  concept  in  one  role of  result  of  different  or  the  several roles data  subtype  applying external  our  other  objects  semantic  data  Based concept  on  our  and the  possible to  semantic  concepts. models.  However,  this  from  in  SDBM  conceptualization. This  see  roles  we  An  extension  of  class  data models  the  for  object  external  among be  user.  concepts  found  in  is always rigidly  tied  data representations  rigidity  is  SDBM  object  can  the  other  can only  the  such  of  in  object  removed  as  have  concept  in a  totally greatly  ability.  we  investigated  concept. The type vision  separation model  different  However,  conceptualization,  display our  data  hierarchy.  we  or relationships  semantic data models, an object  representations.  window  should be explicit  also  if these roles have compatible  two-view  enhances the data modelling  a  is  semantic data models. In other  terms  it  SDBM  many  either  semantic data models,  objects. Therefore, S D B M accommodates views which are more flexible  The  of  This part is a role  could  matter  world  correspondence  structure.  These properties  or  is the same.  SDBM  an S D B M w i n d o w  structure  is a one-to-one  see some part of  by a collection  relationship.  possibly  We  a conceptual  of  the  between  should has not  'real'  the  support  concept world  type  the  the in  SDBM  between  is actually  being modelled. W e  concept  and the window  many-to-many  been supported  relationship  relationship  by many recently  the  type  a tool to  make  found  that  concept  between  there  and that  these  two  proposed semantic  data  127  We  have developed the  demonstrated  that  this  SDBM  separation  enhanced  modelling  power.  constraints  into  categories,  two  so that such separation is built and  this  Following  many-to-many  such  those  separation,  associated  with  into  relationship we  and  It  give  classify  types  it.  has been the  semantic  those  model integrity  associated  with  windows.  Secondly, a database design methodology presented.  This  (Mylopoulos  et  methodology al  [1980]).  specialization.  However,  general  It  their  level. own.  The  identification analyse  with  design  process. In  relationships  Like  unlike  starts  of  the  TAXIS,  TAXIS,  objects an  this  that  expands  that  approach both  proposed  promotes just  general  and  conceptually  needs  all the  start  to  Thus, we  expect  improve the database specification because of the enhanced modelling  Thirdly,  because the  model  techniques in programming  Finally,  several  conceptualization of external  is flexible  The MAYBE  new  modelling  tool  for  SDBM  ISNOT  are  might be played by the such  as  INSERT  with  multi-valued  are  this  a  on role  objects  and  approach  will  power.  checking  database applications.  introduced  record data type  most  to  support  our  is developed as the basic  roles. As demonstrated  in  examples, this  data  in modelling various situations.  relationships among windows  and  constructs  data modelling. The S D B M  through  system, well-established type  languages can be readily introduced to  data representation  structure  has a built-in type  the  of  significant  roles for that  TAXIS  concept  with  go  interesting  in  the  not  identify them.  also  conceptualization is  does  also  among  two-view  methodology  database  process, we  our  methodology  are  SDBM  may exist  design  our our  based on  and  introduced  to  same object.  DELETE  properties,  are  been  model For the  also  several  have  the  constraints  between  constructs  different  roles  same purpose, dynamic modelling  introduced.  behavioral  investigated. As a result,  To  cope  operations  are  with  the  provided.  difficulty They  like that  constructs associated  can  add  a  128  value  to  the  property.  We  additional  details.  Due implemented  property, have  to  the  conceptualization user specifiable is not  pointed  time on  remove  computer.  value  that the  constraint,  can be  the It  from  handling  the  property,  specialization  semantic  should  realized internally.  exceptional  supported.  out  a  facility  be It at  process may  database interesting  should the  and  model to  also be  conceptual  modify be  interesting level.  multi-valued  carried out  SDBM  investigate  a  has  how to  without  not  our  been  two-view  investigate  Currently,  such  the  facility  129  BIBLIOGRAPHY  Ablano,  A.  et al [1985], 'Galileo: A Strongly TODS, Vol.10, No.2, 1985.  Typed  Interactive  and  [1974], 'Data Semantics'. In Klimbie, MANAGEMENT, North-Holland, 1974.  Adiba,  M.,  Delobel, C , and Leonard, M . [1976], 'A Unified Approach for Modelling in Logical Data Base Design', In Nijssen, G . M . (Ed.), MODELLING IN DATA BASE MANAGEMENT SYSTEMS, North-Holland, 1976.  A.V., Been, C. and Ullman, J.D. [1977], 'The theory of joins in (Extended Abstract)', Proc. of 18th Annual Symposium Computer Science, Oct. 1977.  Astrahan, M . M . , et al. [1976], 'System R: A Relational Approach ACM TODS, Vol.1, N o . 2 , 1976. Bachman,  Benci,  C W . [1977], 'The Role C o n c e p t in Database Very Large Data Bases, Tokyo, Japan, O c t o b e r  to  Models', 1977.  K.L.  H.,  Birtwistle,  Bracchi,  DATA  Relational Databases on Foundation of  Data Base  Proc.  E., Bodart, F., Bogaert, H., and Cabanes, A. [1976], 'Concepts for Conceptual Schema', In Nijssen, G . M . (Ed.), MODELLING MANAGEMENT SYSTEMS, North-Holland, 1976.  Bernstein,  (Eds.),  ACM  J.R.  Biller,  Koffman,  Language',  Abrial,  Aho,  J.W.  Conceptual  of  Management',  Int.  the IN  Conf.  on  Design of a DATA BASE  P.A., Swenson, J.R. and Tsichritzis, D.C. [1975], 'A Unified Approach to Functional Dependencies and Relations', Proc. of ACM SIGMOD Int. Conf. on the Mgt of Data, San Jose C A , May 1975. Glatthaar, W . and N e u h o l d , E.J. [1976], ' O n the Semantics of Data Bases: the Semantics of Data Manipulation Languages', In Nijssen, G . M . (Ed.), MODELLING IN DATA BASE MANAGEMENT SYSTEMS, North-Holland, 1976. C M . , Dahl, O.J., Myhrhang, Petrocelli, 1973. G.  B.,  Nygaard,  K.  [1973],  SIMULA  BEGIN,  New  York,  Paolini, P. and Pelagatti, G. [1976], 'Binary Logical Associations in Data Modelling', in Nijssen, G . M . (Ed.) MODELLING IN DATA BASE MANAGEMENT SYSTEMS, North-Holland, 1976.  Brodie, M.L. [1978], 'Specification  and Verification  of  Data Base Semantic  Integrity', Technical  130  Report  CSRG-91,  Univ. of Toronto,  April  1978.  Brodie,  M.L [1981], 'Association: A Database Abstraction for Semantic Modelling', In ENTITY-RELATIONSHIP APPROACH TO INFORMATION MODELLING AND ANALYSIS, C h e n , P.P.(Eds.), North-Holland, 1981.  Brodie,  M.L., Mylopoulos, J. and Springer-Verlag, 1984.  Buneman,  Schmidt,  J.W.  [1984],  ON  CONCEPTUAL  P. and Atkinson, M . [1986], 'Inheritance and Persistence in Languages', Proc. of ACM SIGMOD Int. Conf. on Washington, D . C , 1986.  Database Programming the Mgt. of Data,  Chen,  P.P. [1976], T h e Entity Relationship TODS, Vol.1, N o . 1 , 1976.  Chen,  P.P. [1981], ENTITY-RELATIONSHIP APPROACH ANALYSIS, North-Holland, 1981.  Codd,  E.F.  Codd,  E.F. [1971a], ' A Data Base Sublanguage Found on ACM SIGFIDET Workshop on Data Description, C A , 1971.  Codd,  E.F. [1971b], 'Further Normalization of the Data Base Relational M o d e l ' , (Ed.), DATA BASE SYSTEMS, Prentice Hall, 1971.  Codd,E.F.  Codd,  Codd,  [1970], 'A Realtional Vol.13, No.6, 1970.  Model  [1971c], 'Normalization Data SIGFIDET Workshop on Data  E.F.  M o d e l : Toward  MODELLING,  for  Large  TO  a Unifying  INFORMATION  Shared  Data  Base Structure: A Description, Access,  'Recent Investigation North Holland, 1974.  in  of  Data',  MODELLING  Banks',  Comm.  In  Brief Tutorial', Proc. of ACM and Control, San Diego, 1971.  Relational  Sublanguages',  Data  In  Systems',  Rustin,  Codd,  E.F. [1979], 'Extending the Database Relational ACM TODS. Vol.4, No.4, Dec. 1979.  More  DATABASE  Model  to  Capture  R.  Information  Klimbie,  TO  ACM,  Rustin, R.  E.F. [1974b], 'Seven Steps to Rendezvous with the Casual User', In al. (Eds.), DATA BASE MANAGEMENT, North Holland, 1974.  INTRODUCTION  AND  of  Codd,  Date, C.J. [1983], AN  ACM  the Relational Calculus', Proc. of Access, and Control, San Diego  [1971d], 'Relational Completeness of Data Base (Ed.), DATA BASE SYSTEMS, Prentice Hall, 1971.  E.F. [1974a], Processing'74,  View  J.W. et  Meaning'.  SYSTEM, Vol.11, Addison-Wesley,  1983.  131  Eswaran,  Fagin,  Fagin,  Fagin,  K.P. and Chamberlin, D.D. [1975], 'Functional Specifications of a Subsystem for DAtabase Integrity', Proc. of Int. Conf. on Very Large Data Bases, Framingham M A , USA, Sept. 1975.  R.  [1975], 'The Decomposition Versus the Synthetic Approach to Database Design', Proc. of Int. Conf. on Very Large Data Bases, Tokyo, Japen, October 1977.  R.  [1977], 'Multivalued Dependencies and a Databases', ACM TODS, Vol.2, No.3, 1977.  R.  New  Normal  [1981], 'A Normal Form for Relational Databases That Keys', ACM TODS, Vol.6, No.3, 1981.  Form  for  Is Based on  Relational  Domains  and  Falkenberg,  E. [1976a], 'A Uniform Approach to Data Base Management', In Nijssen, C M . (Ed.), MODELLING IN DATA BASE MANAGEMENT SYSTEMS, North-Holland, 1976  Falkenberg,  E. [1976b], 'Concepts for Modelling Information', In Nijssen, C M . MODELLING IN DATA BASE MANAGEMENT SYSTEMS, North-holland, 1976.  Goldstein,  R.C. [1985], 1985.  Hall,  P.,  DATABASE:  TECHNOLOGY  AND  Owlett, J. and Todd, S. [1976], 'Relations MODELLING IN DATA BASE MANAGEMENT  Hammer,  MANAGEMENT,  & Sons,  and Entities', In Nijssen, G . M . SYSTEMS, North-Holland, 1976.  (Ed.),  M . M . and Berkowitz, B. [1980], 'DIAL: A Programming Language for Data Intensive Applications', Proc. of ACM SIGMOD Int. Conf. on the Mgt. of Data, , 1980.  Hammer,  M . M . and M c L e o d , D.J. [1975], system', Proc. of Int. Conf. on Sept. 1975.  Hammer,  M . M . and M c L e o d , D.J. [1976], Proc. of Second Int. Conf. on  Hammer,  M . and M c l e o d , D. [1981], 'Database Description M o d e l ' , ACM TODS, Vol.6, No.3, 1981.  Ingalls,  John Wiley  (Ed.),  'Semantic Integrity in a Relational Data Base Very Large Data Bases, Framingham M A , USA,  'A Framework for Data Base Semantic Integrity', Software Eng., San Francisco, Oct. 1976. with S D M : A Semantic  D.H. [1978], 'The Smalltalk-76 Programming Systems: Design and Conf. Record of the 5th Annual ACM Symposium on Principles Languages, Tucson, Arizona, 1978.  Database  Implementation', of Programming  Kambayashi, Y., Tanaka, K. and Yajima, S. [1978], 'Problems of Relational Database Design', In Yao, S.B. and Navathe, S.B. (Eds.), DATA BASE DESIGN TECHNIQUES I: REQUIREMENTS AND LOGICAL STRUCTURE, Springer-Verlag, 1978. Kent,  W.  [1977],  'Entities  and  Relationships  in  Information',  In  Nijssen,  CM.,  (Ed.),  132  ARCHITECTURE North-Holland, Kent, W .  AND 1977.  [1979], 'Limitations 1979.  MODELS  of  IN  DATA  BASE  MANAGEMENT  Record-Based Information M o d e l s ' . ACM  SYSTEMS,  TODS,  Vol.4, N o . 1 ,  King,  R. and M c l e o d , D. [1982], 'The Event Database Specification M o d e l ' , Proc. 2nd Int. Conf. on Databases: Improving Usability and Responsiveness. Jerusalem, Israel, June 1982.  King,  R.  King,  R.  Kroenke,  and M c L e o d , D. [1984], 'A Database Design', In Brodie, Springer-Verlag, 1984. and M c L e o d , D. [1985], OF DATABASE DESIGN, D . M . [1983], DATABASE 2nd ed., SRA, 1983.  Unified M.L. et  'Semantic Data M o d e l s ' , In VOL. I, Pretice-Hall, 1985. PROCESSING:  King, B. and Sonke, S. [1984], 'A Semantic Maier,  D.  [1983], THE THEORY  M o d e l and M e t h o d o l o g y for al. (Eds.), ON CONCEPTUAL  Yao,  FUNDATIONALS,  OF RELATIONAL  DATABASES,  B.A. [1983], 'A User-oriented Conceptual Schema M o d e l Supporting Design Strategy', University of Illinois unpublished Ph.D. Thesis. 1983.  McCee,  W . C . [1976], ' O n No.4, 1976.  McLeod,  Criteria  for  Data  Model  of at  Evaluation',  ,  1984.  Science Press,  D.J. [1976b], 'High Level Expression of Semantic Relational Data Base System, Technical Report Science, MIT, Cambridge M A , Sept. 1976.  ACM  TODS,  J., Berstein, P.A. and W o n g , H.K.T. [1980], 'A Language Facility for Database-intensive Applications'. ACM TODS, Vol.5, No.2, June 1980.  Pratt, T.W.  [1984], PROGRAMMING Prentice-Hall, 1984.  J. [1977], 'Independent 1977.  Components  DESIGN  of  AND  Vol.1,  ACM Salt  Integrity Specifications in a TR-165, Lab. for Computer  Mylopoulos,  LANGUAGES:  1983.  Data Base with a Urbana-Champaign,  D.J. [1976a], 'High Level Domain in a Relational Data Base System', Proc. of SIGPLAN/SIGMOD Conf. on Data: Abstraction, Definition, and Structure, Lake City, March 1976.  McLeod,  Rissanen,  PRINCIPLES  IMPLEMENTATION,  Trend and  Computer  Manalo,  User  S.B. (Ed.),  DESIGN,  Data Language', IEEE 84,  Conceptual MODELLING,  IMPLEMENTATION,  Relations', ACM  TODS,  Vol.2,  Designing  (2nd  ed.),  No.4,  Dec.  133  Rowe,  L. and Shoens, K. [1979], 'Data Abstraction, Views and Updates in RICEL', ACM SIGMOD Int. Conf. on the Mgt. of Data, Boston M A , 1979.  Proc.  of  Schmid,  H.A. and Swenson, J.R. [1975], ' O n the Semantics of the Relational Data M o d e l ' , Proc. A C M S I G M O D Int. Conf. on the Management of Data, San Jose, 1975.  Schmid,  H.A. [1977], 'An Analysis of Some Concepts for Conceptual M o d e l s ' , In Nijssen, G.M. (Ed.), ARCHITECTURE AND MODELS IN DATA BASE MANAGEMENT SYSTEMS, North-Holland, 1977.  Schmidt,  J.W., [1978], 'Type Concepts for Bases, Haifa, Israel, 1978.  Shipman,  D.W. [1982], 'The Functional Vol.6, N o . 1 , 1982.  Smith,  J . M . and ACM  Steuert,  Smith, TODS,  Database Definition',  Model  C P . [1977], 'Database Vol.2, No.2, 1977  and the  Proc.  of  Data Language  Abstractions:  Int.  Conf. on  DAPLEX', ACM  Aggregation  and  Data  TODS,  Generalization',  J. and Goldman, J. [1974], 'The Relational Data Management System: A Perspective', Proc. of A C M SIGFIDET Workshop on Data Description, Access, and Control. 1974.  Stonebraker,  M.R. [1974], 'High Level Integrity Assurance in Relational Data Base Management Systems', Elec. Research Lab. Report ERL-M473, Univ. of California, Berkeley C A , Aug. 1974.  Stonebraker,  M . , W o n g , E., kreps, P. and Held, G . [1976], 'The of INGRES', ACM TODS, Vol.1, No.3, 1976.  Stonebraker,  M.R. [1984], 'Adding Semantic Knowledge Brodie, M . L et al (Eds.), ON CONCEPTUAL  Tsichritzis, D.C. and Tsur,  Lochovsky, F.H. [1982], DATA  Ullman,  Weber,  J.D. [1983], PRINCIPLES Press, 1983. H.  OF  DATABASE  Implementation  to a Relational Database System', In MODELLING, Springer-Verlag, 1984.  MODELS,  S. and Zaniolo, C. [1984], ' A n Implementation M o d e l on a Relational Back-end'. Proc. Vol.14, No.2, June 1984.  Design and  of of  Prentice-Hall,  GEM--Supporting SIGMOD, 1984  SYSTEMS,  (2nd  ed.),  1982 a Semantic Data annual meeting.  Computer  Science  [1976], ' A Semantic M o d e l of Integrity Constraints on a Relational Data BAse', In Nijssen, G . M . (Ed.), MODELLING IN DATA BASE MANAGEMENT SYSTEMS, North-Holland, 1976.  134  Wegner,  P. [1980], 'Programming with Ada: A n Introduction Examples', Englewood Cliffs, N.J., Prentice-Hall, 1980.  Wiederhold, Wong,  G. [1977], DATABASE  DESIGN ,McGraw  by  Means  of  Graduated  Hill, 1977.  H.K.T. [1981], 'Design and Verification of Integrity Information Systems Technical Report CGSRG-129, Univ. of Toronto, April 1981.  Using TAXIS',  APPENDIX  A. SYNTAX O F S D B M  <Letter>:= A|B|C|D|E|F|G|H|l|j|K|L|M|N|0|P|Q|R|S|T|U|V|W|X|Y|Z a|b|c|d|e|f|g|h|i|j|k|l|m|n|o|p|q|r|s|t|u|vfw|x|y|z <Digit>:=  0 j1 | 2 | 3 | 4|5|6|7|8|9  <LetterOrDigit>:=  <Letter>  | <Digit>  <SpecialCharacter>:= +  |-|*l/l-M;l#ls|t|{|}|[|]|,lB|)|(| I  <Character>:= < L e t t e r O r D i g i t >  | <SpecialCharacter>  < C h a r a c t e r S t r ing>:= < C h a r a c t e r > { < C h a r a c t e r > } <Ident i f ier>:=  <Letter>{<LetterOrDigit>}  <KeyWord>:=NUMERIC BEGIN IS  | CHARACTER | END | NULL  | WITH  ACTION  | I SNOT  | ADT | TYPE  | MULTIPLE  TRANSACTION  | BOOLEAN  | VARIANT  | MAYBE  | ADTOP  | OPTIONAL  | DELETE  | RETRIEVE  CREATE  | TO | WINDOW  WHERE | I F | THEN  | KEY | OF | INTO | INSERT |  | DESTROY |  | REFERENCE  | ELSE  | LOCAL |  | FUNCTION |  | OUT | IN | VARIABLE  MODIFY  | COMMON  | ENDIF  DO  | WHILE  OR  | NOT | <--> | ADD | REMOVE  | RELATIONSHIP | FOR | EACH |  | GT | GE | L T | L E | EQ | NE | AND  <UnsignedInteger>:=  <Digit>{<Digit>}  <PositiveInteger>:=  <UnsignedInteger>  | TRUE  | FALSE  | +<UnsignedInteger>  <Negativelnteger>:=  <Integer>:=  -<Digit>{<Digit>}  <PositiveInteger>  | <Negativelnteger>  <UnsignedReal>:=<Digit>{<Digit>}.{<Digit>}  <Real>:=  <UnsignedReal>  <Number>:=  <Real>  <Constant>:=  | +<UnsignedReal>  | <Integer>  <UnsignedInteger>  | <UnsignedReal>  "<CharacterString>"  <SignedConstant>:=  <SDBMSchema>:=  | -<UnsignedReal>  <Number>  |  | NULL  | "<CharacterString>"  | NULL  <TypeDeclarat ionPart> <WindowDeclarat ionPart> [  <TransactionDeclarationPart>  ]  <TypeDeclarationPart>:= <TypeDeclaration> {  <TypeDeclaration>:=  TYPE  <TypeDeclaration> }  ( <TypeID> [  = <TypeDefinition>  |  <SubtypeDefintion>  ]  +  ) <TypeDefinition>:=  <AnyTypeID>:=  <AnyTypeID>  NUMERIC  | BOOLEAN  ENUMERATION  <TypeConstraint>:=  WITH < T y p e C o n s t r a i n t >  | CHARACTER  | RECORD  |  | <TypeID>  <NumericRanges>|<BooleanPicture> <CharacterPictures>| <EnumerationPicture>| <RecordPicture>  |  <NumericRanges>:=  <NumericRange>:=  <NumericRange>  {OR  <NumericRange>}  <Number>..<Number>  <BooleanPicture>:=  "{"TRUE|FALSE|TRUE,FALSE|FALSE,TRUE"}"  <CharacterPictures>:= <CharacterPicture> {OR  <CharacterPicture>}  <CharacterPicture>:=<NumericCharacter>  |  <AlphabeticCharacter>  |  <AlphanumericCharacter>  <Numer i c C h a r a c t e r > : =  9(<Integer>)  <Alphabet icCharacter>:=  A(<Integer>)  <AlphanumericCharacter>:=  <CharacterList>:=  <QuateList>:=  X(<Integer>)  {[A|X|9|<QuateList>] } +  +  "<Character>{<Character>}"  <Enumerat i o n P i c t u r e > : =  "{"<EnumerationLi st>"}"  <EnumerationList>:=  <CharacterString>{,  <RecordStructure>:=  [[VARIANT|COMMON]  <CharacterString>}  <ComponentAndTypePair>  {,  [VARIANT|COMMON] <ComponentAndTypePair> [BEGIN <ConstraintAssertion>{, <ConstraintAssertion>}  };]  END]  <ComponentAndTypePai  r>: =  <ComponentID>:<TypeSpec i f i c a t ion>[MULTIPLE|OPTIONAL]  <ComponentID>:=<Identifier>  <TypeSpecification>:=<TypeID>|<TypeDefinition>| <SubtypeDef i n i t i o n >  <ConstraintAssertion>:=  <ComplexAssertion>| <SimpleAssert  ion>  <SimpleAssert ion>: = <ConTerm>  <BoonleanOperator>:=  {<BoonleanOperator>  AND  | OR  <ConTerm>}  | NOT  <ConTerm>:=<Element> {<RelationalOperator>  <RelationalOPerator>:=  <ConPrimary>:=  GE  | GT  |  LE  | LT  ( <ConstraintAssertion> <CompoentID>  <ComplexAssertion>:=  <Element>}  | EQ  | NE  ) |  | <Constant>  IF <ConstraintAssertion> THEN  <ConstraintAssertion>  [ ELSE  <ConstraintAssertion>  ]  ENDIF  <SubtypeDefinition>:=  IS  <TypeDefinition>  <ADTDe f i n i t i o n > : = ADT(<ADTID>=TYPE  <TypeID>  ADTOP  [LOCAL];  [<ADTFunctionOP>|<ADTProcedureOP>]  {,  [<ADTFunctionOP>|<ADTProcedureOP>] }; +  139  ACTION: <ADTProcedureOrFunction> )  <ADTFunctionOP> : = <ADTFunct ionID>(<Funct i o n P a r a m e t e r s > ) : < T y p e S p e c i f i c a t ion>  <ADTFunct ionID>:=  <ADTID>:=  <Identifier>  <Identifier>  <Funct ionParameters>:=<ParameterID>:<TypeSpec i f i c a t i o n > { ,  <ParameterID>:<TypeSpec i f i c a t i o n > }  <ParameterID>:=  <Identifier>  <ADTProcedureOP>:=<ADTProceureID>(<ProcedureParameters>)  <ADTProcedureID>:=  <Identifier>  <ProcedureParameters>:=  [OUT]<ParameterID>:<TypeSpec i fi c a t ion>{, [OUT]<ParameterID>:<TypeSpec i f i c a t i o n > }  <ADTProcedureOrFunct ion>:= <ADTProcedure>|<ADTFunct ion>|<Procedure>| <Function> <ADTProcedure>:=  PROCEDURE  <ADTProcedureID> <Body>  END  <Body>:=  PROCEDURE  <ADTProcedureID>  [ <ADTTypeDeclarationPart> [  <ADTVariableDeclaration>  ] ]  <ADTStatementPart>  <ADTTypeDeclarationPart>:=  TYPE < A D T T y p e D e c l a r a t i o n > { ,  140  <ADTTypeDeclaration>} <ADTTypeDeclaration>:=  <TypeID> [=  <TypeDefinition>  |  <SubtypeDefinition> ]  +  <ADTVar i a b l e D e c l a r a t i o n P a r t > : = VARIABLE < V a r i a b l e L i s t > : < T y p e I D > { , <VariableList>:<TypeID>} <ADTStatementPart>:=  BEGIN <ADTStatement>{, <ADTStatement>} END  <ADTStatement>:=  <ADTAssignment>|<ADTPrecedureCall>| <ADTCompound>|<ADTCondition>| <ADTIteration>  <ADTAssignment>:=  <VariableID>=<ADTExpression>| <FunctionID>=<ADTExpression>  <ADTPrecedureCall>:=  <PrecedureID>([<ActualParameter>{, <ActualParameter>}])  <ActualParameter>:=  <ADTVariab1e>  | <SignedConstant>  <ADTVariable>:=  <ADTVariableID>|<ADTVariableID>.<ComponentID>  <ADTVariableID>:=  <VariableID>  <ADTCompound>:=  BEGIN <ADTStatement>{, <ADTStatement>} END  <ADTCondition>:=  IF <ADTExpression> THEN  <ADTStatement>  [ELSE  <ADTStatement>]  ENDIF  <ADTIteration>:=  <ADTFor>:=  FOR  <ADTFor>|<ADTWhile>  <VariableID>=<Initial>  TO < F i n a l >  DO  <ADTStatement>  <Initial>:=  <Final>:=  <Integer>  <Integer>  <ADTWhile>:=  WHILE  < A D T E x p r e s s i o n > DO <ADTStatement>  <ADTExpression>:=  <ADTTerm>  <RelationalOperator>  <ADTTerm>  <ADTTerm>  <ADTTerm>:=  <ADTUnaryTerm>  <AddingOperator>  <ADTUnaryTerm>  <ADTUna r y T e r m >  <AddingOperator>:=  <ADTUnaryTerm>:=  +|-|OR  <ADTFactor>|+<ADTFactor>|-<ADTFactor>  <ADTFactor>:=<ADTPrimary>  <MultiplyingOperator>  <ADTPrimary>  <MultiplyingOpeator>:=  <ADTPrimary>:=  NOT  *|/|AND  <ADTElement>|<ADTElement>  <ADTElement>:= ( < A D T E x p r e s s i o n > ) | < A D T V a r i a b l e > | <FunctionCall>|<ADTFunctionCall>  <ADTPrimar  <FunctionCall>:=  <FunctionID>([<ActualParameter>{, <ActualParameter>}])  <ADTFunctionCall>:=  <ADTFunctionID>([<ActualParameter>{, <ActualParameter>}])  <ADTFunction>:=  FUNCTION  <ADTFunctionID> <Body>  END  <Procedure>:=  FUNCTION  PROCEDURE  <ADTFunctionID>  <PocedureID> <Body>  END  <Function>:=  PROCEDURE  FUNCTION  <ProcedureID>  <FunctionID> <Body>  END  <WindowDeclarat  FUNCTION  <FunctionID>  ionPart>:=<WindowDeclaration> {<WindowDeclarat ion>}  <WindowDeclaration>:=  <SimpleWindowDeclaration>| <AggregateWindowDeclarat ion>  <SimpleWindowDeclaration>:= WINDOW  (<WindowID>  [ I S <WindowID> [TYPE:  WITH  <References>;]  [RELATIONSHIP: <KeyIDs>]  ) <WindowID>:=  <KeyID>:=  <Identifier>  <PropertyID>  +  <TypeID>{,<TypeID>;]  [REFERENCE:  [KEY:  | =]  {,<PropertyID>  }  <Relationships>;  <PropertyID>:=  <Identifier>  <References>:=<WindowID>(<PropertyPairs>){, <WindowID>(<PropertyPairs>)}  <PropertyPairs>:=<PropertyID>=<PropertyID>{, <PropertyID>=<PropertyID>}  <Relationships>:=<Relationship>{,  <Relationship>}  <Relationship>:= <RelationshipID>(<(WindowID>[(PropertyPairs>)] )  <--><RelationshipID>  <AggregateWindowDeclaration WINDOW  (<WindowID>= T Y P E :  <AggregateTypeDefinition>{, <AggregateTypeDefinition>};  AGGREGATE:  <WindowID>, <WindowID>{, <WindowID>}  <AggregateTypeDef i ni t ion>: = <ComponentID>  [OF <WindowID>|: < T y p e S p e c i f i c a t i o n > ]  <Transact ionDeclarationPart>:= <TransactionDeclaration> { < T r a n s a c t i o n D e c l a r a t ion>}  <TransactionDeclaration>:= TRANSACTION  (<TransactionDesignator> <TransactionBody>  ) <TransactionDesignator>:= <TransactionID> ([<ParameterDefinitionList>])  +  <TransactionID>:=  <Identifier>  <ParameterDef i n i t i o n L i st>:=  <ParameterDef i n i t ion>{, <ParameterDef i n i t i o n > }  <ParameterDefinition>:=  <OUTParameter>  | <INParameter>  <OUTParameter>:=  OUT  <ParameterID>:<TypeIDOrWindowID>  <INParameter>:=  [IN]  <ParameterID>:<TypeIDOrWindowID>  <TypeIDOrWindowID>:=  <TypID>  <Transact ionBody>:=  | <WindowID>  [<TransactionTypeDeclaration>] [<TransactionVariableDefinition>] BEGIN <Statement>{, <Statement>} END  <TransactionTypeDeclaration>:= TYPE  <TypeID> [=<TypeDefinition>|<SubtypeDefinition>] {, +  <TypeID> [=<TypeDef i n i t i o n > | < S u b t y p e D e f i n i t i o n > ] } +  < V a r i a b l e D e c l a r a t ion>: = VARIABLE  <VariableList>:  <TypeSpecification>|<WindowID>{,  <Var i a b l e L i s t > :  <TypeSpec i f i c a t ion>|<WindowID>};  <VariableList>:=  <VariableID>:=  <Statement>:=  <VariableID>{,  <VariableID>}  <Identifier>  <AssignmentStatement> |  <CreateStatement>  | <DestroyStatement>  <InsertStatement>  | <ModifyStatement>  <DeleteStatement>  | <RetrieveStatement>  <AbortStatement>  | | |  |  <CompoundStatement>  | <ConditionalStatement>  <IterationStatement> <ADTProcedureCall> <RemoveStatement>  |  |<TransactionCall>|  | <AddStatement>  |  |  <Multi-valuedPropertyModi fyStatement>  <AssignemntStatement>:=  <Var i a b l e I D > = < E x p r e s s i o n >  <CreateStatement>:= CREATE  <VariableID>  INTO  <WindowID>  WITH  < P r o p e r t y V a l u e L i st>)  <PropertyValueList>:=  <PropertyValuePair>{, < P r o p e r t y V a l u e P a i r>}  < P r o p e r t y V a l u e P a i r>: = <PropertyID>="<CharacterStr  ings>"|<VariableID>  <CharacterStrings>:= '<CharacterString>'{,'<CharacterString>'  <DestroyStatement>:=  DESTROY  <VariableID>  <InsertStatement>:= INSERT  <VariableID>(<VarID>{,<VarID>}) INTO  <WindowID>  [ WITH  (<PropertyValueList>)]  <VarID>:=  <Identifier>  <Modi f y S t a t e m e n t > : = <VariableID>.<PropertyID>=  <NewValue>  146  <NewValue>:=  "<CharacterString>" | <Expression>  <DeleteStatement>:=  DELETE < V a r i a b l e I D >  <RetrieveStatement>:= RETRIEVE < V a r i a b l e I D > [ . < P r o p e r t y I D > <VariableID>.<PropertyID>  TO < V a r i a b l e I D > { , TO  [ WHERE < E x p r e s s i o n > <AbortStatement>:=  <VariableID>}]  ]  ABORT  <AddStatement>:= ADD [ < V a r i a b l e I D > | " < C h a r a c t e r S t r i n g s > " ] TO  +  <VariableID>.<PropertyID>  <RemoveStatement>:= REMOVE [ < V a r i a b l e I D > | " < C h a r a c t e r S t r i n g s > " ] FROM  +  <VariableID>.<PropertyID>  <Mult i - v a l u e d P r o p e r t y M o d i f y S t a t e m e n t > : = <VariableID>.<PropertyID>= NULL|"<CharacterStrings>"|<VariableID>.<PropertyID> <CompoundStatement>:=  BEGIN <Statement>  { ,  <Statement> } END <ConditionalStatement>:=  IF <Expression> THEN <Statement> [ ELSE  <Statement>  ]  ENDIF <IterationStatement>:=<ForStatement>I<WhileStatement> <Forstatment>:=  FOR EACH < V a r i a b l e I D > DO <Statement>  <WhileStatement>:=  WHILE < E x p r e s s i o n >  DO  <Statement>  <Expression>:=<Term>  <Term>:=<UnaryTerm>  <UnaryTerm>:=  <Factor>:=  { < R e l a t i o n a l O p e r a t o r > <Term>}  {<AddingOperator>  <Factor>  <Primary>  | +<Factor>  |  <UnaryTerm>}  -<Factor>  { < M u l t i p l y i n g O p e r a t o r > <Primary>}  <Primary>:=  NOT  <Element>  <Element>:=  (<Expression>)  |  <Elenemt> | <VariableID>  <VariableID>.<ComponentID> <VariableID>.<PropertyID> <ADTFunctionalCall>  |  | |  | <Constant>  <Transact ionCall>:= <Transact ionID>(<ActuralParameter>{, <ActuralParameter>})  148  APPENDIX  B.1  B.  COMPARASONS  BETWEEN  SDBM  TAXIS  SIMILARITIES  SDBM  Modelling primitives There  can  TAXIS  are objects. be  Modelling primitives There  are  constraints.  among  objects.  Objects have properties.  Objects have  Object  property  dependency  constraints  can  be  Object  are  objects.  dependency  property  constraints  expressed with assertions.  Relationships exist between objects.  Relationships exist between  Basic  operations  are  available,  Basic  deletion,  including  insertion,  modification,  Variables  and retrieval.  may  be  operations  as  object  surrogates in transactions.  Variables  and  are  can  be  objects.  are  available,  insertion,  modification,  used  constraints  properties.  expressed with assertions.  including  B.2  AND  deletion,  retrieval.  used  as  object  surrogates in transactions.  DIFFERENCES  SDBM  Objects data  have  no  TAXIS  types.  representation  is  The  external  handled  Objects are categorized into classes.  by  windows.  Instance  hierarchy is trivial.  Instance  hierarchy is extensively  used.  Dependency  (reference)  constraints  Dependency constraints always exist.  exist only if specified explicitly.  Many-to-many  relationships  two  may  objects  directly  without  artificial  construct.  The  established  introducing  an  of  a  relationships must  objects  through  creating  from  of  references  is  The  the  existence  of  differentiated  relationships.  Semantics  Many-to-many two  associated with can  the  be  name  explicitly  existence  Semantics of  a  Properties can be multi-valued.  Specialization  mechanism  special  constraint  windows  of an object.  are  is  used  extensively  external  constraints  are  can  are  definitions.  differentiated  A window  to  have  the  not  existence  syntactic  of  name implied  combination  of  the  a class.  Specialization relationship  mechanism that  can  is the be  only  specified  Only data type is the TAXIS class.  constraints  are  specified  transactions.  Data  type  more  one  than  Intra-relation through  up. They are all Taxis classes.  and a data  with  the be  from  can  used  of  can  more  than one data type window.  from  is  data  Intra-data-type  specified within data type  be  refences  among classes.  objects.  types  a  diffeent  representations of  Data  object  Properties must be single-valued.  only  among  the  windows.  third  associated with  properties  types  of  relationship  through  expressed.  Data  a  between established  relationships.  relationship  specify  be  (class).  existence  different  between  be  types  and  classes  are  mixed  150  Objects  and  symbolic  explicitly  differentiated.  strings  are  Symbolic  strings  are  treated  as  types  are  not  objects.  Abstract  Abstract data types are supported.  data  supported.  The the  underlying two-view  Appropriate to  support  conceptualization  is  conceptualization.  constructs  are  The two-view fully  conceptualization  supported.  introduced  this conceptualization.  S D B M is typed.  TAXIS is not  typed.  is  not  


Citation Scheme:


Citations by CSL (citeproc-js)

Usage Statistics



Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            async >
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:


Related Items