ISO/IEC 10728:1993

Information technology - Information Resource Dictionary System (IRDS) Services Interface

The services interface specified gives any program full access to all IRDS services. Defines the semantics of this interface, and also specifies the language bindings for ISO Pascal (ISO 7185). Language bindings for other ISO standard programming languages are provided as separate standards. Makes no assumptions about an implementation environment, and assumes no specific run-time or compile time interfaces. Details of the IRDS series of standards are to be found in ISO/IEC 10027.

Technologies de l'information — Interface de services du gestionnaire de ressources du système d'informations (IRDS)

General Information

• Status: Published
• Publication Date: 28-Apr-1993
• ICS: 35.240.01 - Application of information technology in general
• Technical Committee: ISO/IEC JTC 1/SC 32 - Data management and interchange
• Drafting Committee: ISO/IEC JTC 1/SC 32/WG 2 - MetaData
• Current Stage: 9093 - International Standard confirmed
• Start Date: 14-Jun-2022
• Completion Date: 30-Oct-2025

Relations

• Amended By: ISO/IEC 10728:1993/Amd 3:1996 - Information technology - Information Resource Dictionary System (IRDS) Services Interface - Amendment 3: CORBA IDL binding
• Effective Date: 06-Jun-2022
• Amended By: ISO/IEC 10728:1993/Amd 4:1998 - Information technology - Information Resource Dictionary System (IRDS) Services Interface - Amendment 4: RPC IDL binding
• Effective Date: 06-Jun-2022
• Amended By: ISO/IEC 10728:1993/Amd 2:1996 - Information technology - Information Resource Dictionary System (IRDS) Services Interface - Amendment 2: Ada language binding
• Effective Date: 06-Jun-2022
• Amended By: ISO/IEC 10728:1993/Amd 1:1995 - Information technology - Information Resource Dictionary System (IRDS) Services Interface - Amendment 1: C language binding
• Effective Date: 06-Jun-2022
• Parent: ISO/IEC 10728:1993/Amd 3:1996 - Information technology - Information Resource Dictionary System (IRDS) Services Interface - Amendment 3: CORBA IDL binding
• Effective Date: 15-Apr-2008
• Parent: ISO/IEC 10728:1993/Amd 4:1998 - Information technology - Information Resource Dictionary System (IRDS) Services Interface - Amendment 4: RPC IDL binding
• Effective Date: 15-Apr-2008
• Parent: ISO/IEC 10728:1993/Amd 1:1995 - Information technology - Information Resource Dictionary System (IRDS) Services Interface - Amendment 1: C language binding
• Effective Date: 15-Apr-2008
• Parent: ISO/IEC 10728:1993/Amd 2:1996 - Information technology - Information Resource Dictionary System (IRDS) Services Interface - Amendment 2: Ada language binding
• Effective Date: 15-Apr-2008

Overview

ISO/IEC 10728:1993 - Information technology - Information Resource Dictionary System (IRDS) Services Interface - specifies a programmatic services interface that gives any application full access to IRDS services. The standard defines the semantics of the services interface and provides the language binding for ISO Pascal (ISO 7185). It makes no assumptions about implementation environment or specific run‑time/compile‑time interfaces. ISO/IEC 10728 fits within the IRDS family described in ISO/IEC 10027.

Keywords: ISO/IEC 10728:1993, IRDS, Information Resource Dictionary System, services interface, Pascal binding, IRD Definition Level, IRD Level.

Key topics and technical requirements

• Services interface semantics: Defines how client programs interact with IRDS services regardless of external call interface or runtime.
• Language binding: Specifies the ISO Pascal (ISO 7185) binding for the services interface; bindings for other ISO languages are provided separately.
• Two levels of data: Distinguishes the IRD Definition Level (metadata, schema and dictionary content) and the IRD Level (actual IRD instances).
• Abstract and service data structures: Covers IRD tables, views and data types, including column types, object names and diagnostics areas.
• Service operations: Defines operational and level‑independent services such as Create/Drop IRD Definition, Open/Close IRDS, Prepare/Commit/Rollback, Get Diagnostics, Set Context, Add/Retrieve/Modify/Delete Objects, Open/Close Cursor, Working set management, Reference path management, and Schema validation.
• Version control and working sets: Concepts for object versions, working sets, basing and materialization, content status classes (uncontrolled / controlled / archived), and reference paths.
• Constraints and data integrity: Referential constraints, subtables/supertables, and general rules for constraint expression and enforcement.
• Conformance and implementation scope: Specifies conformance requirements and where implementation behavior is implementation‑defined vs. implementation‑dependent.

Applications and who uses it

ISO/IEC 10728:1993 is relevant to:

• Enterprise architects and data managers designing metadata and data dictionary systems.
• IRDS implementers and vendors building IRDS servers or client libraries.
• Database and configuration management tool developers integrating IRDS services for schema and version control.
• System integrators and standards teams seeking portable, language‑bound access to IRDS services. Practical benefits include consistent programmatic access to metadata, standardized versioning and working set semantics, and language portability via bindings.

Related standards

• ISO/IEC 10027 - IRDS Framework (context for the series)
• ISO 7185 - Pascal language (binding)
• ISO/IEC 9075 - SQL (database language references)
• ISO/IEC 10032 - Reference model of data management
• ISO 3166 - country codes (normative reference)

For organizations implementing IRDS or integrating metadata services, ISO/IEC 10728:1993 provides the standardized interface and semantics needed for interoperable, language‑bound access to IRD content.

Standards Content (Sample)

INTERNATIONAL
lSO/IEC
STANDARD
First edition
1993-04-15
Information technology - Information
Resource Dictionary System (IRDS)
Services Interface
Technologies de I’informa tion - Interface de Services du gestionnaire de
ressources du Systeme d’informations (IRDS)
Reference number
ISO/IEC 10728: 1993 (E)
Table of Contents
vi
Forew ord
Vii
Introduction
1 scope
Normative references
3 Definitions and abbreviations
3.1 Terms defined or referenced in the IRDS Framework (ISO/IEC 10027)
and used in this International Standard
3.2 Terms defined in this International Standard
3.3 Data Item Name abbreviations
4 Conventions
4.1 Specification of concepts and facilities
4.2 Specification of data structures
4.3 Specification of constraints - overview
4.4 Specification of Service data structures
4.5 Specification of Services
4.6 Data Structure Diagmm
4.7 Specification of constraints - detail
4.7.1 Types of constraint
4.7.2 Overview of referential constraints
4.7.3 Optional one-to-many referential constraint
4.7.4 Required uni-directional one-to-many referential constraint
Required uni-directional one-to-one referential constraint
4.7.5
Self-referencing tables
4.7.6
Required bi-directional referential constraint
4.7.7
Mutually-exclusive referential constraints
4.7.8
4.7.9 Subtables
4.7.10 Principles for expressing constraints
4.8 Working Set Diagrams
5 IRDS concepts and facilities
5.1 IRDS Environment concepts
5.2 Categories of table
5.3 Overview of IRD Definition tables
0 ISQ/IEC 1993
All rights reserved. No part of this publication may be reproduced or utilized in any form or by
any means, electronie or mechanical, including photocopying and microfilm, without Permission
.- -
in writing from the publisher.
ISOAEC Copyright Office l Case Postale 56 l CH-1 211 Genbve 20 l Switzerland
Printed in Switzerland
ISO/IEC 10728: 1993 (E)
0 ISO/IEC
5.4 Overview of IRD tables
Overview
5.4.1
Intemal and common tables
5.4.2
IRD-specific tables
5.4.3
5.5 Data and the objects to which the datarefers
Definition objects comprising data modehing facility
5.5.1
Definition objects dependent on an IRD Schema Group
5.5.2
Content of IRD tables
5.5.3
Accessibility of tables to users
5.5.4
5.6 Version Control concepts
Objects and Versions of Objects
5.6.1
Working Sets
5.6.2
Working sets and users
5.6.3
Basing one working set on another
5.6.4
Materialization of a working set
5.6.5
5.6.6 References from one working set to another
References to multiple Versions of an Object
5.6.7
5.6.8 Context
5.6.9 IRD content status
5.6.10 References in the IRD
5.6.11 Granularity of Version Control
5.6.12 Access control
5.7 Naming facilities
5.7.1 Names
5.7.2 IRDS names
Variation name
5.7.3
5.7.4 Working set name and working set version name
5.8 Definable limits and installation defaults
Implementation-defined limits
5.8.1
5.8.2 Installation defaults
5.9 Creating and dropping IRDs
5.10 IRD Schema modification
5.11 Other added value functionality
Audit attributes
5.11.1
IRDS content modules 25
5.11.2
5.11.3 System-maintained values
6 Abstract data structures
6.1 IRD Definition Level
6.1.1 IRD Definition Level data structure
6.1.2 IRD Definition Level Schema
6.1.2.1 Schema IRD Definition
6.1.3 IRD Definition Level Domains
6.1.3.1 Domain SQL Name
6.1.3.2 Domain IRDS Key
6.1.3.3 Domain Char Data
6.1.3.4 Domain Cardinal
6.1.3.5 Domain Boolean
6.1.4 IRD Definition Level Tables
6.1.4.1 Table IRD Object
6.1.4.2 Table IRD Working Set
6.1.4.3 Table IRD Object Version
6.1.4.4 Table IRD Reference Path
6.1.4.5 Table IRDS User
6.1.4.6 Table Implementation Limits
6.1.4.7 Table IRDS Dictionary
6.1.4.8 Table IRD Schema Group
6.1.4.9 Table IRD Schema
6.1.4.10 Table IRD SchemaReference
6.1.4.11 Table IRD Data Type Descriptor
6.1.4.12 Table IRD Domain
. . .
lll
0 ISO/lEc
ISO/IEC 10728: 1993 (E)
6.1.4.13 Table IRD Table
6.1.4.14 Table IRD View
6.1.4.15 Table IRD Column
6.1.4.16 Table IRD View Table Usage
6.1.4.17 Table IRD View Column Usage
6.1.4.18 Table IRD Table Constraint
6.1.4.19 Table IRD Key Column Usage
6.1.4.20 Table IRD Referential Constraint
6.1.4.21 Table IRD Check Constraint
6.1.4.22 Table IRD Check Table Usage
6.1.4.23 Table IRD Check Column Usage
6.1.4.24 Table IRD Assertion
6.1.4.25 Table IRD Module
6.1.4.26 Table IRD Content Status
6.1.4.27 Table Installation Default
6.1.4.28 Table IRD Working Set Privilege
6.1.5 IRD Definition Level Views
6.1.5.1 View All SQL Names
6.1.5.2 View IRD Object Version
6.1.5.3 View IRD Working Set
6.1.5.4 View IRD Reference Path
IRD Definition Level Change Control
6.1.6
6.1.7 IRD Definition Level Initial Contents
6.2 IRD Level
RD Level data structure
6.2.1
IRD Level Initial Contents
6.2.2
6.3 IRD General Rules
Use of primary key
6.3.1
6.3.2 References and content Status
Resolution of references
6.3.3
Resolution of references within a version path
6.3.4
References depending on a reference path
6.3.5
Reference paths and Version paths
6.3.6
Services concepts and facilities
7.1 Levels and parallelism
7.2 Access to IRDS data via Database Services Processor
7.2.1 Prevention of cinxmvention of IRDS security and integrity
7.2.2 Access to IRDS Data using a Standard Database Language
7.3 Connecting an application to the IRDS Services Interface Processor
7.3.1 Sessions and transactions
IRDS users and Privileges
7.3.2
7.4 Object selection
7.5 Sets and cufsors
7.6 Diagnos tics
7.7 Version control
7.8 Operations on Abstract Data Structures
8 Service data structures
8.1 Basic data constants
8.1.1 Name Length Limits
8.1.2 Attribute Length Limits
8.1.3 Control ldentifier Length Limits
8.1.4 Data Types
8.1.5 IRD Content Status Classes
8.1.6 Close Type Parameter
8.2 Service data types
iv
0 ISO/IEC ISO/IEC 10728: 1993 (E)
8.2.1 Column data types
8.2.2 Object Names
8.2.3 Control Identifiers
8.2.4 Diagnostics Area
8.2.5 Service Return Code
8.2.6 Column List Parameters
9 Service Formats and Descriptions
9.1 Operational Services
Create IRD Definition Service 75
9.1.1
9.1.2 Drop IRD Definition Service 75
Open IRDS Service 76
9.1.3
9.1.4 Prepare Service 77
9.1.5 Commit Service 77
9.1.6 Rollback Service 78
Close IRDS Service 78
9.1.7
Get Diagnostics Service 78
9.1.8
9.2 Level independent services
9.2.1 Set Context Service
9.2.2 Add Object Service
Open Cursor Service 81
9.2.3
Retrieve Object Service 82
9.2.4
F
92 -3 Modify Object Service
Delete Object Service 84
9’2 . . 6
b
Declassify Object Service 8s
92 .7
9’2 e I +i Reclassify Object Service
9’2 q Glose Cursor Service
Create Working Set Service 87
9:2h
9.2.11 Drop Working Set Service
9.2.1.L odify Content Status Service
9.2.13 Create Reference Path Service
9.2.M Modify Weference Path Service
9.2.15 Dmp Reference Path Service
Definition4 Level specific services
Create IRD Service
Drop RD Service 92
Deactivate IRD Service
Reactiva D Service
Validate Schema Group Service 94
9.4 Sequence sf permitted Service invocation 95
9.4.1 Specification of valid sequences of IODS Service invocations 95
9.4.2 General rules 95
10 Conformance 97
Annexes
A - State classes and subclasses
A.1 State classes
A.2 State subclasses
A.3 State record
B - User-defined tables 103
ISO/IEC 10728: 1993 (E)
0 ISO/IEC
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form the
specialized System for worldwide standardization. National bodies that are members of ISO or IEC participate in the
development of International Standards through technical committees established by the respective organization to deal
with particular Gelds of technical activity. ISO and IEC technical committees collaborate in Gelds of mutual interest. Other
international organizations, govemmental and non-govemmental, in liaison with ISO and IEC, also take part in the work.
In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1. Draft
International Standards adopted by the joint technical committee arc circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
International Standard ISO/IEC 10728 was prepared by Joint Technical Committee ISO/IEC JTC 1, Infomtion teclz-
nology, Sub-Committee SC 21, Infomtion retrieval, transfer- and mmuzgement for open Systems interconnection (OSI).
Annex A forms an integral part of this International Standard. Annex B is for information only.
vi
ISO/IEC 10728: 1993 (E)
0 ISO/IEC
Introduction
This International Standard is one of a series of International Standards on Information Resource Dictionary Systems.
ISO/IEC 10027 defines the context within which this International Standard is to be applied.
vii
0 ISO/IEC
ISO/IEC 10728: 1993 (E)
. . .
Vlll
INTERNATIONAL STANDARD 0 ISO/IEC
ISOiIEC 10728:1993 (E)
Information technology - Information Resource Dictionary
System (IRDS) Services Interface
1 Scope Normative references
The IRDS series of International Standards specifies a The following Standards containprovisions which, through
reference in this text, constitute provisions of this
Software tool that tan be used to describe and potentially
International Standard. At the time of publication, the
control an enterprise’s information resources. It defines the
editions indicated were valid. All standards are subject to
structure and part of the content of the data to be maintained
at the IRD Definition Level, and the structure of the data revision, and Parties to agreements based on this
International Standard are encouraged to investigate the
to be maintained at the IRD Level. It also defines the
Services to be provided for maintaining and retrieving data possibility of applying the most recent editions of the
Standards listed below. Members of IEC and ISO maintain
at both levels. Further details of the IRDS series of
Standards are to be found in ISO/IEC 10027. registers of currently valid International Standards.
This International Standard specifies a Services Interface ISO 3 166: 1988; Codes for the representation of names of
that gives any program full access to all IRDS services, countries
through whatever extemal cal1 interface is provided by the
language in which the program is written. The body of this ISO 7 185: 1990; Information Technology - Programming
International Standard defines the semantics of this
languages - Pascal.
interface, and also specifies the language bindings for ISO
Pascal (ISO 7185). Language bindings for other ISO
ISO/lEC 9075: 1992; Information Technology - Database
Standard programming languages are provided as separate
Languages - SQL.
Standards.
ISO/IEC 10027: 1990; Information Technology -
This International Standard makes no assumptions about
Information Resource Dictionary System (IRDS) -
an implementation environment, and assumes no specific
Framework.
nm-time or compile-time interfaces.
ISO/IEC 10032: 1993; Information Technology -
Reference Model of Data Management

0 ISO/IEC
ISO/IEC 10728: 1993 (E)
3.2.6 context: A working set established by default or by
Definitions and abbreviations
user request within which IRDS Services are performed.
NOTE - SQL tenns a= not defiied hexe. When used in this International
Standard, they have the meanings ascribed to them in ISO/IEC 9075. All
3.2.7 controlled: A content Status class that indicates data
IRDS tenns used in this International Standard are fully defined hexe or
that is stable and not subject to Change.
in ISO/IEC 10027.
3.2.8 definition Object: An Object recorded at the IRD
definition level that controls the data which may be present
3.1 Terms defined or referenced in the IRDS
at the IRD level.
Framework (ISO/IEC 10027) and used
in this International Standard
3.2.9 dictionary: An IRD Definition or IRD
The following terms are defined (or referenced) and used
3.2.10 environment table: A table that exists once in each
in the IRDS Framework. They are used in the Same way in
IRD Definition, controlling the Services provided on that
this International Standard.
IRD Definition and any associated IRDs.
3.1.1 client
3.2.11 implementation-defined: Behaviour not defined by
this International Standard, but which shall be precisely
3.1.2 Information Resource Dictionary (IRD)
defined by any conforming implementation
3.1.3 Information Resource Dictionary System (IRDS)
3.2.12 implementation-dependent: Behaviour not defined
by this International Standard, and which an
3.1.4 IRD definition
implementation is not required to define. Further, there is
no requirement that such behaviour be consistent ffom case
3.1.5 IRD definition level
to case.
3.1.6 IRD definition Schema
3.2.13 intemal table: A table that exists once in each IRD
Definition and each IRD, rows in which cannot be accessed
3.1.7 IRD level
by the Object-related services in clause 9.
3.1.8 IRD Schema
3.2.14 IRD-specific table: A table that exists only in the
IRD Definition or a specific IRD, as part of the
3.1.9 level pair
representation of the data structuring rules of a defined data
modehing facility.
3.1.10 real System
3.2.15 IRD content Status: A user-defined attribute of a
3.1.11 Service
working set. Every value of IRD content Status belongs to
one of the three predefined content Status classes. Esch
Object version takes its IRD content Status from the
3.2 Terms defined in this International
working set that contains it.
Standard
3.2.16 IRD content Status class: One of three predefined
Where each term listed in this clause is introduced in a later
sets of IRD content statuses: uncontrolled, controlled and
clause of this International Standard, it is printed in bold
archived.
wpe*
3.2.17 IRD Object: An Object recorded at the IRD level.
3.2.1 active: A state in which a dictionary is accessible to
all relevant IRDS Services. When an IRD is not active, only
3.2.18 IRD Schema Group: A collection of one or more
the Reactivate IRD Service is applicable.
IRD Schemas that completely defines what may exist at
any time in an IRD.
3.2.2 archived: A content Status class that indicates data
that is no longer in active use.
3.2.19 IRDS database: An IRD definition and zero or
more IRDs.
3.2.3 attribute: A characteristic of an Object.
3.2.20 IRDS environment: An operational instance of an
3.2.4 common table: A table that exists in each IRD
implementation of the IRDS Services Interface managing
Definition and each IRD.
an IRDS database.
3.2.5 content module: A collection of objects introduced
into an IRD Definition or XRD at the same time and from
the source, identified by a module name that indicates the
Source of the module.
0 ISO/IEc
3.2.32 reference path: A directed association from one
3.2.21 IRDS name: A name optionally assigned when an
working set to another which allows an Object Version in
Object is added to an IRD or a definition Object is added to
the first working set to reference Object Versions in the
an IRD definition. If specified, the combination of IRDS
second working set. A reference path aIlows references
name, Variation name, working set name and working set
only in the direction in which it is specified.
version name shaIl be unique.
3.2.33 referenced table: The table to which the reference
3.2.22 IRDS session: A temporary association between an
is made in a referential constmint.
IRDS user and an IRDS environment, during which the
former requests Services and the latter performs them.
3.2.34 referencing table: The table from which the
3.2.23 IRDS User: An individual or group authorized to reference is made in a referential constraint.
use the IRDS.
3.2.35 subtable: Let SUBT and SUPERT be tables. SUBT
3.2.24 level independent service: A Service that is equally is defined to be a subtable of SUPERT if and only if every
applicable to the IRD Definition level and the IRD level. row of SUBT corresponds to one and only one row of
SUPmT, and each row of SUPERT corresponds to at most
one row of SUBT. SUPERT is defined to be a supertable
3.2.25 level specific Service: A Service which only applies
of SUBT.
either to the IRD Definition level or to the IRD level, but
not both.
3.2.36 supertable: A table that has at least one subtable
3.2.26 materialization (of a working Set): That collection (see definition of subtable).
of Object Versions that tan be in the working table of a
cursor opened on that working set. 3.2.37 uncontrolled: A content Status class that indicates
data that is not stable.
3.2.27 name: A string of characters used to distinguish
objects, either alone or i n combination with other names. 3.2.38 Variation name: A name used to identify
significantly different variants of objects with the same
3.2.28 non-versionable (of an Object type): Indicates that RDS name.
only one version of an Object of that type may exist at any
time, in a non-versionable working set; of a working set, 3.2.39 versionable (of an Object type): Indicates that more
indicates that the working set may not be based on another than one Version of an Object of that type may exist at the
working set or be used as the basis foranother working set. Same time, in different working Sets; of a working set,
indicates that the working set may not contain objects of
non-versienable Object types, may be based on another
3.2.29 Object: concept or thing of interest to an
AnY
working set and may be used as the basis for another
enterprise.
working set.
3.2.30 Object type: A class of objects all of whose attributes
3.2.40 working set: A collection of Versions of either
belong to a common set of attribute types.
definition objects or IRD objects, defined by an IRDS user
as a unit for the purposes of Change management, content
3.2.31 Object Version: A record of the information about
Status specification and access control.
an Object that is current for some period of time in some
information processing context.

0 ISO/IEC
ISO/EC 10728: 1993 (E)
Data Item Name abbreviations
3.3
The following list describes all of the abbreviations that are
used in naming the columns of the SQL tables and the
corresponding Pascal constants, types and variables:
= added
Add
= archived
Arch
Ati- = attribute
= class
Cis
Cntl = controlled
Col = column
= cursor
Cur
= current
Curr
Des = IRD content status
= definition
Def
Dflt = default
Dflts = defaults
Die = dictionary
Dom = domain
= identifier
Id
= implementation
Imp
Ind = indicator
= installation
Inst
= integer
Int
Ird = Information Resource Dictionq
Len = length
= limit
Lim
Main t = maintained
= maximum
Max
Min = minimum
Mod = modified
= national
Nat
Num = number
.
= Object
QbJ
= reference
Ref
Ret = return
Sem = schema
= separater
SeP
= session
Sess
= specification
spec
SN = service
= stling
St.l=
= transaction
Tran
Txt = text
Ucntl = uncontrolled
= value
Val
= Variation
Var
Ver = Version
= working
Wkg
= working set
Ws
ISO/IEC 10728: 1993 (E)
0 ISO/IEC
4.5 Specification of services
4 Conventions
In clause 9, the Services to be supported by an IRDS arc
This clause describes the conventions used within this
specified using a combination of Pascal (ISO 7185) and
International Standard to describe the facilities of an IRDS.
English.
These conventions are not themselves a subject of this
Standard. SeveraI different specification conventions arc
used, for different purposes.
4.6 Data Structure Diagrams
The Data Structure Diagams used in clause 5 illustrate
4.1 Specification of concepts and facilities
tables and the constraints between the tables. A table is
Within clause 5, diagrams arc used, in conjunction with rePresented bY a rectangularbox.
English description, to introduce some of the concepts and
Constmints between the tables are represented by lines
facilities that are formally defined later in this International
between the boxes. Esch line is considered to have two
Standard. Two types of diagram are used:
halves, each half associated with the box to which it is
directly connected.
a) Data Structure Diagrams, described in 4.6;
b) Working Set Diagrains, described in 4.8.
4.7 Specification of constraints - detail
4.2 Specifkation of data structures
4.7.1 Types of constraint
In clause 6, the data structures to be managed by an IRDS
The following types of constmint are used within the
Services Processor are specified using Database Language
formal data specification in clause 6:
SQL (ISO/IEC 9075).
a) Primary key constmints - which identify the primary
In general, this involves the use of tables to represent Object
key of each table.
types and columns to represent attribute types; certain data
is also required for control purposes.
b) Uniqueness constraints - which identify
combinations of columns within a table whose
The use of SQL as a definition formalism in this
values must be unique, when not wholly or partially
International Standard does not imply any specific
null.
implementation approach. The user of the Services
provided at the IRDS Services Interface sees the data only
c) Referential constraints - which identify the
in the terms defined in clause 8.
dependencies of one table on another.
d) Check constraints - which allow the specification of
4.3 Specification of constraints - overview
many additional general constraints on the values or
combinations of values which may appear in one or
Constmints on the possible values, or combinations of
more rows in one or more tables.
values, which may appear in the IRD are specified once
only wherever possible. In Order of preference, each
In addition to their specification in clause 6, referential
constraint is specified:
constraints are also illustrated diagmmmatically in clause
5. The rest of this clause describes the diagramming
a) within the formal data specification, in clause 6;
conventions used for different types of referential
constraint and the SQL syntax used to represent each type.
b) in the description of the relevant table, in clause 6;
4.7.2 Overview of referential constraints
c) in the description of the Services that tan be used to
Change the data, in clause 9.
It is necessary to explain the type of referential constrGnts
used before describing their representation.
The specification of constraints is described in detail in 4.7.
A referential constraint exists between two tables A and B
if at all times the values of some specified column or
4.4 Specification of Service data structures
combination of columns, when not null, in each row in
table B shall be equal to the values of a corresponding
In clause 8, the formats of the data structures associated
combination (in terms of number and data type) of columns
with each Service are described using Pascal (ISO 7185).
in one and only one row in table A. Such constmints arc
further qualified as follows:
0 ISO/IEC
ISO/IEC 10728: 1993 (E)
if only a Single row in table B may
a) One-to-one -
reference any one row in table A.
b) One-to-many - if more than one row in table B tan
reference the same row in table A.
Orthogonal to the above classification of constraints, the
following classification may also be made:
Figure 1 - Optional referential constraint
c) Optional at referencing table - if any of the columns
in table B, which are used to reference table A, may
Table 1 Shows the corresponding SQL Syntax.
be null; a row in which any of these columns is null
is considered not to reference table A;
Table 1: SQL corresponding to Figure 1
d) Optional at referenced table - if a row may exist in
table A without being referenced from any row in
CREATE TABLE A
table B;
(Al IRDS KEY PRIMARY KEY)
-
e) Required at referencing table - if the referencing
CREATE TABLE B
columns in table B may not be null. Every row in
(BI IRDS KEY PRIMARY KEY,
-
table B must reference a row in table A.
82 IRDS KEY
-
f) Required at referenced table - if arow in table A may
exist only if there is a corresponding row in table B
CONSTRAINT constraint-name
that references it. REFERENCES A
ON DELETE referential-action )
The following basic constructs are used within the Data
Structure Diagram to illustrate these constraints. Esch half
of the line that represents the constraint is treated separately
In table 1 and similar tables, IRDS KEY represents the
in illustrating the characteristics of the constraint at each
name of a domain (see ISO/IEC 9075) which is used
table.
throughout the tables defined in clause 6. It is used here
solely to make these examples look as similar as possible
a) Solid line - the constraint is required at that table; to the SQL used in clause 6.
The SQL syntax used in clause 6 will normally contain an
b) Dashed line - the constraint is optional at that table;
ON DELETE clause, similar to that shown in Table 1. This
clause specifies additional information that is not shown in
“Crow’s feet” at end of line - represents a
C>
the diagram - namely the action to be taken when an attempt
one-to-many constraint. (Crow’s feet are not
is made to delete a row in table A that is referenced by a
allow ed at both ends of a line.)
row in table B.
d) No “crow’s feet” at either end - represents a
For an optional referential constraint, as shown in table 1,
one-to-one constraint.
the referential action tan be one of the following:
The diagrammatic representations of some of the various
a) RESTRICT - (cannot be specified explicitly, but is
constraint types listed above are now illustrated. In each
implied if ON DELETE clause is not specified)
case, an example is also given of how the relevant
which means the deletion will not be allowed;
constraint would be expressed in clause 6, using SQL with
or without accompanying English description.
b) CASCADE - which means the referencing rows
will also be deleted.
4.73 Optional one-to-many referential constraint
c) SET NULL - which means the referencing
Figure 1 illustrates the simplest (in terms of its SQL
columns will be nullified, thus removing the
specification) constraint - an optional one-to-many
reference, but the row itself will not be deleted.
referential constraint.
0 ISO/IEc
4.7.4 Required uni-directional one-to-many referential Table 3 Shows an example of the SQL syntax to specify the
constraint
constraint illustrated in figure 3. The addition of a
uniqueness constraint on column B2 enforces the
Figure 2 illustrates a required uni-directional one-to-many
sinnularitv of the constraint.
referential constraint. The solid half of the line connected
to box B illustrates that this constraint is required from B
Table 3 - SQL corresponding to figure 3
to A.
CREATE TABLE A
(Al IRDS KEY PRIMARY KEY)
-
CREATE TABLE B
(Bl IRDS KEY PRIMARY KEY,
-
B2 IRDS KEY NOT NULL
CONSTl%!hNT constraint-name
REFERENCES A
ON DELETE referential-action,
Figure 2 - Required referential constraint (one to
many) UNIQUE (B2) )
Table 2 Shows an example of the SQL syntax to specify the
constraint illustrated in figure 2. The addition of the NOT
4.7.6 Self-referencing tables
NULL clause on the referencing column B2 makes the
constraint required from table B to table A.
Table 2 - SQL corresponding to figure 2
CREATE TABLE A
(Al IRDS KEY PRIMARY KEY)
-
Figure 4 - Self-referencing constraint
CREATE TABLE B
Note that in any of the above cases A and B may be the
(BI IRDS KEY PRIMARY KEY,
-
same table, in which case the line representing the
B2 IRDS KEY NOT NULL constraint is drawn as a circular arc between two points on
-
the same box, as in figure 4, and the SQL referential
CONSTRAINT constraint-name
constraint is between two columns, or groups of columns,
REFERENCES A
in the same table, as in table 4.
ON DELETE referential-action )
Table 4: SQL corresponding to Figure 4
Because of the NOT NULL clause, SET NULL is not a
valid referential action for a required referential constraint.
CREATE TABLE A
(Al IRDS KEY PRIMARY KEY
-
4.7.5 Required uni-directional one-to-one referential
A2 IRDS KEY
constraint -
CONSTRAINT constraint-name
REFERENCES A
ON DELETE referential-action )
4.7.7 Required bi-directional referential constraint
Figure 5 illustrates the diagramming convention for a
required bi-directional one-to-many referential constmint.
Figure 3 - Required referential constraint (one to
one)
Figure 3 illustrates a required uni-directional one-to-one
referential constraint. The removal of the crows feet from
the line indicates in the diagram that this constraint is
one-to-one.
Figure 5 - Required bi-directional referential
Figure 6 - Type 1 mutually-exclusive constraints
constraint
The following Syntax may be used to enforce these
constraints at the IRD Definition Level only. At the IRD
Table 5 - SQL corresponding to figure 5
Level, such constraints are identified declaratively in
tables.
CREATE TABLE A
(Al IRDS KEY PRIMARY KEY Table 6 - SQL corresponding to figure 6
-
CONSTRAINT constraint-name
CHECK (Al IN (SELECT B2 FROM B) )
CREATE TABLE A
(Al IRDS KEY PRIMARY KEY)
-
CREATE TABLE B
(Bl IRDS KEY PRIMARY KEY,
-
CREATE TABLE C
(Cl IRDS KEY PRIMARY KEY)
-
82 IRDS KEY NOT NULL
CONST%AINT constraint-name
CREATE TABLE B
REFERENCES A
(BK IRDS KEY PRIMARY KEY,
-
ON DELETE referential-action )
BI IRDS KEY
CONSTRAINT constraint-name
The SQL above is identical to that in table 2, except for the REFERENCES A
ON DELETE referential action,
addition of a check clause, to make the constraint be
required from the referenced table to the referencing table.
B2 IRDS KEY
Note that, since the constGnts are mutual, rows cannot be
CONSTmAINT constraint-name
inserted in A without setting the check constraint off until
REFERENCES C
at least one corresponding row has been inserted in B.
ON DELETE referential action ,
A required bi-directional one-to-one referential constraint
CONSTRAINT constraint-name
is represented in a similar fashion. The only differente
CHECK
would be the removal of the “crow’s feet” in the figure, and
(
(Bl IS NULL AND B2 IS NOT NULL)
the addition of a uniqueness constraint in the SQL for table
OR
B:
(B2 IS NULL AND Bl IS NOT NULL)
UNIQUE (B2), )
)
4.78 Mutually-exclusive referential constraints
Figure 6 illus trates required uni-directional referential
In some circumstances, two or more of the constraints
constraints. As discussed previously, other kinds of
described above may be mutually exclusive: one or other
constraint exist. The syntax for required bi-directional
of the two constraints shall be satisfied, but not both. This
constraints would require the same CHECK clause to be
is represented by an arc drawn across the relevant lines, as
added to the referencing table. To support optional
shown in figure 6. Here each row in table B shall at all times
referential constraints, the CHECK Statement shown
contain either a valid reference to a row in table A, or a
should be replaced by the following:
valid reference to a row in table C. This example,
designated Type 1, Shows the mutual exclusivity consmint
CHECK (BI IS NULL OR B2 IS NULL)
applying at the referring table.
If one or both of the referential constraints is one-to-one, it
will be necessary to add corresponding uniqueness
constraints in table B:
UNIQUE (Bl) ,
UNIQUE (B2),
0 ISO/IEC
To support more than two referential constraints, Note that the format of the CHECK clause actually used to
express the exclusivity of the constraints may differ from
corresponding attributes B3, B4, etc. would be introduced,
with the appropriate modifications to the CHECK clause. that shown here, depending on the circumstances.
Similar diagrams and Syntax could be developed for
required uni-directional constraints, or optional
constraints, but neither is actually used in clause 6.
Combinations of Type 1 and Type 2 constraints are also
possible, in which case the SQL will be a combination of
the two approaches.
4.7.9 Subtables
Figure 7 - Type 2 mutually-exclusive constraints
Let SUPERT and SUBT be tables. SUBT is defined to be
The reverse Situation may also occur, as shown in figure 7.
a subtable of SUPERT if and only if every row of SUBT
Here each row in table A may be referenced either by rows
corresponds to one and only one row of SUPERT, and each
in table B or by rows in table C, but not both. In this case,
row of SUPERT corresponds to at most one row of SUBT.
designated Type 2, the mutual exclusivity occurs at the
SUPERT is defined to be a supertable of SUBT.
referenced table. The constraints illustrated in figure 7 arc
required bi-directional referential constraints.
A supertable may have more than one subtable. To clarify
this case, let the rows of table A represent a set of objects
As with Type 1 constraints, the following syntax may be
and let the rows of tables B and C represent further sets of
used to implement these constraints at the IRD Definition
objects. If the sets of objects represented by the rows of
Level.
tables B and C arc both subsets of the set of objects
represented by the rows of table A, then tables B and C are
subtables of table A.
Table 7 - SQL corresponding to Figure 7
CREATE TABLE A
(Al IRDS KEY PRIMARY KEY,
A2 CHARNOT NULL
CHECK (A2 IN (‘B’,‘C’) ),
*Ir Ic
UNIQUE (Al, A2),
CONSTRAINT constraint-name
CHECK ( ( SELECT COUNT (*) FROM B
WHERE Al =Bl ) Figure 8 - Subtables
+ ( SELECT COUNT (*) FROM C
WHERE Al=Cl )
Figure 8 illustrates this, in the case where the Sets of objects
=
1)
represented by tables B and C are disjoint. Note that use of
)
this diagramming convention does not necessarily imply
that every row in A corresponds to a row in table B or table
CREATE TABLE B
C. If this additional requirement does hold, the Situation is
(BK IRDS KEY PRIMARY KEY,
identical to that represented by figure 7, and the SQL
Bl IRDS-KEY NOT NULL,
representation will be identical to that given there;
B2 CHARNOT NULL
CHECK (B2=‘B’), othenvise the SQL given in table 7 applies, but with the
CONSTRAINT constraint-name
NOT NULL constraint removed from column A2 of table
FOREIGN KEY (Bl, B2)
A, and the last line of the CHECK constraint changed to
REFERENCES A (Al, A2)
‘<= 1’.
)
CREATE TABLE C
(CK IRDS KEY PRIMARY KEY,
Cl IRDS-KEY NOT NULL,
C2 CHARNOT NULL
CHECK (C2=‘C’),
CONSTRAINT constraint-name
FOREIGN KEY (Cl, C2)
REFERENCES A (Al, A2)
ISO/IEC 10728: 1993 (E) 0 ISO/IEC
4.7.10 Frinciples for expressing constraints
A constraint with no sub-queries is preferred to
applied when
The following general principles have been
a constraint with a sub-query;
in this International S tandard:
specifying constraints
ii) When choosing between two constraints with
a) CHECK and referential constraints are named;
sub-queries, the more concise expression is
used;
b) When specifying referential constraints between
tables, the following rules arc applied:
Consistent techniques are used wherever possible to
express particular types of constraint:
i) When a 1:M relationship exists between two
tables, the referential constraint is specified
e) Where the approach dictated by the above principles
from the many to the one;
conflicts with that taken in the SQL Definition
Schema (ISO 9075), the SQL approach is taken
ii) When a 1: 1 relationship is optional at one table,
wherever possible.
but mandatory at the other, the table at which
the relationship is mandatory is considered
4.8
Working Set Diagrams
dependent on the other (independent) table, and
the constraint is specified from the dependent
The Working Set Diagrains used in clause 5 illustrate
table to the independent table;
working sets and the two sorts of path from one working
set to another. A working set is represented an ellipse,
bY
iii) If a 1:M relationship is mandatory at both tables,
and a path from one working set to another a line. The
bY
in addition to the referential constraint from the
arrow along a line indicates the direction of the reference,
many to the one, a CHECK constraint is
and the label on or near the line indicates the type of
specified in the reverse direction.
reference.
iv) If a 1: 1 relationship is mandatory at both tables,
a CHECK constraint is used in one direction,
Oldest
not only for consistency with the 1:M case, but
also because a second referential constraint
would require additional columns for the
foreign key. This is because the manner in
based
which tables have been specified as distinct
on
subtypes of IRD OBJECTJERSION does
I
not aIlow primary key values in different tables
reference path
to match.
Newest
NOTE - Such 1: 1 relationships in the IRDS occur only in conjunction with
other Elationships with which they are mutually exclusive. If this were
not the case, there would be no need for separate tables.
Figure 9 - Working set diagram conventions
When deciding in which direction to specify the
referential constraint, the function of the two
In figure 9, working set B was created based on working
tables in question is considered, also the impact
set A. There is a reference path from working set C to
of referential actions. Where possible, the
working set B.
constraint is specified so that all mutually
exclusive constraints act in the same direction
A reference path allows references only in the direction of
with relation to the table at which the exclusivity
the arrow. In figure 9, Object Versions in Working Set C tan
exists.
refer to Object Versions in Working Set B, but Object
Versions in Working Set B tan NOT refer to Object Versions
c) There are often several ways to express a logical
in Working Set C.
constraint as a CHECK constraint, perhaps
involving different columns and/or tables. When
deciding how to specify a constraint, the following
is the Order of preference:
0 ISO/IEC ISO/IEC 10728 : 1993 (E)
One IRD Definition and its associated IRD Schema Groups
5 IRDS concepts and facilities
and IRDs arc part of an IRDS environment. An IRDS
Services Interface Processor (see ISO/IEC 10027) may
This International Standard supports a set of facilities
interact with any number of IRD Definitions. However, an
several of which are outlined in ISO/IEC 10032 and in
IRDS user may interact with only one IRD Definition and
ISO/IEC 10027. The facilities are categorized as follows:
its associated IRD Schema Groups and IRDs in one IRDS
Session.
a) data modelling facilities;
An IRDS Services Interface Processor in an IRDS
b) version control facilities;
environment may use the Services of a Database Services
Processor. Esch Database Services Processor conforms to
c) naming facilities;
a specific data modelling facility.
d) facilities for establishing limits and defaults;
5.2 Categories of table
e) other added value facilities.
One of the aims of this International Standard is to have as
These facilities are supported by data which is recorded in
much parallelism between the two level pairs as possible.
the tables for the IRD Definition Level (see ISO/IEC
For each level pair, the content of the tables is categorized
10027).
as follows:
The term Object is used in this International Standard to
a) Intemal tables: those associated with Object
refer to that which is represented by a row in a table or
management and Version control, that exist once in
tables. Every Object is either a definition Object or an IRD
each IRD Definition and IRD;
Object, depending on whether it is represented by rows in
tables at the definition level or IRD level.
b) Environment tables: those that exist once in each
IRD Definition, controlling the Services provided on
Services are provided by an IRDS Services Interface
that IRD Definition and any associated IRDs;
Processor (see ISO/IEC 10027) to retrieve and maintain the
data in these IRD Definition tables. The IRD Definition
c) IRD-specific tables: those that exist only in the IRD
tables are defined in clause 6. The concepts for the Services
Definition or a specific IRD, including those that
are defined in clause 7, the Service data structures in clause
embody the data structuring rules of a defined data
8 and the Services themselves in clause 9.
modelling facility (see ISO 10032); for the IRD
Definition this data modehing facility is that of SQL
It is important to distinguish between the defining
(Iso/lEc 9075).
mechanism and that which is defined. The IRD Definition
tables are defined in clause 6 of this International Standard
d) Common tables: those that exist once in each IRD
using SQL Schema Definition Statements (see ISO/IEC
Definition and IRD, associated with naming, version
9075) as the defining mechanism.
control and other common facilities;
The defined mechanism in the IRD Definition tables is
Table 8 Shows in tabular form some relevant characteristics
used in turn for the IRD Level pair as a defining
of these categories.
mechanism. In this International Standard, the defined
mechanism is the data modelling facility supported by the
Table 8 - Characteristics of table categories
SQL Schema Definition Statements. A data modelling
facility is a set of rules for structuring a collection of
persistent data and an associated set of data manipulation
Category Row Versienable Shared
rules (see ISO/lEC 10032).
represents across
Object IRD’s
5.1 IRDS Environment concepts
Intemal No No No
Multiple IRD Definitions may exist in one real system;
Environment Yes No YeS
each IRD Definition is independent of any other IRD
Definitions. Esch IRD Definition may contain the
IRD-specific Yes
Optional No
definitions of Zero, one or more IRD Schema Groups. For
each IRD Schema Group, there exists Zero or one IRD.
Common Yes No No
Hence multiple IRDs may exist in one real system. Esch
IRD is structured according to the data modelling facility
defined in a Single IRD Schema Group.
0 ISO/IEC
ISO/IEC 10728 : 1993 (E)
The sequence of the IRD Definition tables in this list is
In this International Standard tables arc sometimes referred
based on the categories defined in 5.2 above, and then on
to using terms other than the categories described above:
the referential constraints between pairs of tables. In
for example, Referencing and Referenced tables (see
general, if table B references table A then table A precedes
4.7.2,), and Supertable and Subtable (see 4.7.9). Such
table B in the sequence. The sequence in the above list is
concepts arc independent of the categorization above.
used in clause 6.
5.3 Overview of IRD Definition tables Within the SQL text in clause 6, and in direct references to
it elsew here, names of tables and columns are in upper case,
The data
...