CAN CSA-ISO IEC 10728-1995 Information Technology - Information Resource Dictionary System (IRDS) Services Interface.pdf

1、I NTERNATIONAL STANDARD ISO/IEC 10728 First edition 1993-04-1 5 (Reaffirmed 2004) Information technology - Information qesource Dictionary System (IRDS) Services Interface Technologies de Iinformation - lnterface de services du gestionnaire de ressources du s ysteme dinformations URDS) National Stan

2、dard of Canada CAN/CSA-ISO/IEC-lO728-95 International Standard ISO/IEC 10728:1993 has been adopted, without modification, as CAN/CSA-ISO/IEC- 10728-95, which has been approved as a National Standard of Canada by the Standards Council of Canada. February 1995 Reference number ISO/lEC 10728:1993(E) IS

3、O/IEC 10728: 1993 (E) Table of Contents Foreword Introduction 1 scope vi Vii 1 2 Normative references 3 Definitions and abbreviations 3.1 Terms defined or referenced in the lRDS Framework (ISO/EC 10027) and used in this International Standard 3.2 Terms defined in this International Standard 3.3 Data

4、 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 Diagrams 4.7 Specification of constraints

5、 - detail 4.7.1 Types of constmint 4.7.2 Overview of referential constraints 4.7.3 Optional one-to-many referent Codes for the representation of names of countries IS0 7185: 1990; Information Technology - Programming lunguuges - Pascal. ISO/IEC 9075: 1992; Information Technology - Database Languages

6、 - SQL. ISO/IEC 10027: 1990; Informarion Technology - Information Resource Dictionary System (IRDS) - Framework. ISO/IEC 10032: 1993; Information Technology - Reference Model of Data Management 1 ISO/lEC 10728:1993 (E) 0 ISO/IEC 3.2.6 context A working set established by default or by user request w

7、ithin which IRDS services are performed. 3 Definitions and abbreviations NOTE - SQL terns are not defmed here. When used in this International Standard, they have the meanings ascribed to them ISOEC 9075. All IRDS terns used in this International Standard are Mly defmed here or in ISO/IEC 10027. 3.2

8、.7 controlled A content stabs class that indicates dah that is stable and not subject to change. 3.1 Terms defined or referenced in the LRIDS Framework (ISOhEC 10027) and used in this International Standard 3.2.8 definition object: An object recorded at the IRD definition level that controls the dat

9、a which may be present at the IRD level. 3.2.9 dictionary: An IRD Definition or IRD The following terms are defined (or referenced) and used in the RDS Fmework. They are used in Same way in this International Standard. 3.2.10 environment table: A table that exists once in each IRD Definition, contro

10、lling the services provided on that RD Definition and any associated IRDs. 3.1.1. client 3.1.2 Information Resource Dictionary (IRD) 3.1.3 Information Resource Dictionary System (IRDS) 3.1.4 IRD definition 3.1.5 IRD definition level 3.1.6 IRD definition schema 3.1.7 IRDlevel 3.1.8 IRD schema 3.1.9 l

11、evel pair 3.1.10 real system 3.1.11 service 3.2 Terms defined in this International Standard 3.2.11 implementationdefined: Behaviour not defined by this International Standard, but which shall be precisely defined by any conforming implementation 3.2.12 implementation-dependent: Behaviour not define

12、d by this International Standard, and which an implementation is not required to define. Further, there is no requirement that such behaviour be consistent from case to case. 3.2.13 internal table: A table that exists once in each IRD Definition and each IRD, rows in which cannot be accessed by the

13、object-related services in clause 9. 3.2.14 IRD-specific table: A table that exists only in the IRD Definition or a specific IRD, as part of the representation of the data structuring rules of a defined data modelling facility. 3.2.15 IRD content status: A userdefined attribute of a working set. Eve

14、ry value of IRD content status belongs to one of the three predefined content status classes. Each object version takes its IRD content status from the working set that contains it. 3.2.14 IRD content status class: One of three predefined sets of IRD content statuses: uncontrolled, controlled and Wh

15、ere each term listed in this clause is introduced in ahkr clause of this International Standard, it ig printed in boId type- 3.2.17 RD object: An object recorded at the IRD level. 3.2.1 active: A state in which a dictionary is accessible to the Reactivate IRD service is applicable. 3.2.2 archwed: A

16、content status class that indicates data that is no longer in active use. 3.2.3 attribute: A characteristic of an object. relevant RDS Services. When an RD iS not active, Ody 3-2-18 IRD Schema that completely defines what may exist at any time in an IRD. 3.2.19 RDS database: An IRD definition and ze

17、ro or more IRDs. Schema G: A collection of one or 3.2.4 common table: A table that exists in each aU, Definition and each IRD. 3.2.20 lRDS environment: An operational instance of an implementation of the IRDS Services Interface managing an IRDS database. 3.2.5 content module: A collection of objects

18、 introduced into an IRD Definition or IRD at the same time and from the source, identified by a module name that indicates the source of the module. 2 0 ISO/IEC ISO/IEC 10728:1993 (E) 3.2.21 IRDS name: A name optionally assigned when an object is added to an IRD or a definition object is added to an

19、 IRD definition. If specified, the combination of RDS name, variation name, working set name and working set version name shall be unique. 3.2.22 lRDS session: A temporary association between an IRDS user and an IRDS environment, during which the former requests services and the latter performs them

20、. 3.2.23 IRDS user: An indvidual or group authorized to use the IRDS. 3.2.24 level independent service: A service that is equally applicable to the IRD Definition level and the IRD level. 3.2.25 level specific service: A service which only applies either to the lRD Definition level or to the IRD lev

21、el, but not both. 3.2.32 reference path: A directed association from one working set to another which allows an object version in the first working set to reference object versions in the second working set. A reference path allows references only in the direction in which it is specified. 3.2.33 re

22、ferenced table: The table to which the reference is made in a referential constraint. 3.2.34 referencing table: The table from which the reference is made in a referential constraint. 3.2.35 subtable: Let SUBT and SUPERT be tables. SUBT is defined to be a subtable of SUPERT if and only if every TOW

23、of SUBT corresponds to one and only one row of SUPERT, and each row of SUPERT corresponds to at most one row of SUBT. SUPERT is defined to be a supertable of SUBT, 3.2.36 supertable: A table that has at least one subtable (see definition of subtable). 3.2.37 uncontrolled: A content status class that

24、 indicates data that is not stable. 3.2.38 variation name: A name used to identify significantly different variants of objects with the Same lRDS name. 3.2.39 versionable (of an object type): Indicates that more than one version of an object of that type may exist at the same time, in different work

25、ing sets; of a worlang set, indicates that the working set may not contain objects of non-versionable object types, may be based on another working set and may be used as the basis for another working set. 3.2.40 working set: A collection of versions of either definition obcts or IRD objects, define

26、d by an IRDS user as a unit for the purposes of change management, content status specification and access control. 3.2.24 materialization (of a working set): That collection of object versions that can be in the working table of a cursor opened on that worlung set. 3.2.27 name: A string of characte

27、rs used to distinguish objects, either alone or in cornbination with other names. 3.2.28 non-versionable (of an object type): Indicates that only one version of an object of that type may exist at any time, in a non-versionable working set; of a working set, indicates that the working set may not be

28、 based on another working set or be used as the basis for another worhng set. 3.2.29 object: Any concept or thing of interest to an enterprise. 3.2.30 objecttype: A class of objects all of whose attributes belong to a common set of attribute types. 3.2.31 object version: A record of the information

29、about an object that is current for some period of time in some information processing context. 3 ISO/EC 10728:1993 (E) 3.3 Data Item Name abbreviations The following list describes all of the abbreviations that are used in naming the columns of the SQL tables and the corresponding Pascal constants,

30、 types and variables: Add Arch Atr CIS Cntl Col Cur curr DCS Def Dflt Dflts Dic Dom Id Imp Ind Inst Int Ird Len Lim Maht Max Min Mod Nat Num Obj Ref Ret Scrn Sess SN Str Tran Txt Ucntl Val VX Ver Wg WS SeF spec = added = archived = attribute = class = controlled =column = cmr = current = IRD content

31、 status = definition = default = defaults = domain = identifier = implementation = indicator = installation = integer = Information Resource Dictionary = length = limit =maintained = maximum =minimum = modified = national = number =object = reference = return = schema = separator = session = specifi

32、cation = service = string = tmnsaction = text = uncontrolled = value = variation = version = working = working set = dictionary 4 0 ISO/IEC ISO/IEC 10728:1993 (E) 4 Conventions 45 Specification of services This clause describes the conventions used within this International standard to describe the

33、facilities of ms. These conventions are not themselves a subject of this standard. Several different specification conventions are used, for different purposes. clause 9, tfie services to be supported by an WS specified using a combination of Pascal (IS0 7185) and English- 4.6 Data Structure Diagram

34、s 4.1 Within clause 5, diagrams are used, in conjunction with English description, to introduce some of the concepts and facilities that are formally defined later in this IntemationaI Standard. Two types of diagram are used Specification of concepts and facilities The Data Structure Diagrams used i

35、n clause 5 illustrate tables and the constraints between the tables. A table is bY a rectangular box. Chstmints between the tables are represented by lines between the boxes. Each line is considered to have two halves, each half associated with the box to which it is a) Data Structure Diagrams, desc

36、ribed in 4.6; directly connected. b) Working Set Diagrams, described in 4.8. 4.7 Specification of constraints - detail 4.2 Specification of data structures 4.7.1 Types of constraint In clause 6, the data structures to be managed by an lRDS Services Processor are speclfied using Database Language SQL

37、 (XSOE 9075). The following types of constraint are used within the formal data specification in clause 6: In general, this involves the use of tables to represent object types and columns to represent attribute types; certain data is atso requiI.ed for control purposes. The use of SQL as a definiti

38、on formalism in this International Standard does not imply any specific implementation approach. The user of the services provided at the IRDS Services Interface Sees the data only in the terms defined in clause 8. 43 Specification of constraints - overview a) Primary key constraints - which identif

39、y the primary key of each table. b) Uniqueness constraints - which identify combinations of columns within a table whose values must be unique, when not wholly or partially null. c) Referential constraints - which identify the dependencies of one table on another. d) Check constraints - which allow

40、the specification of many additional general constraints on the values or combinations of values which may appear in one or more rows in one or more tables. Constraints on the possible values, or combinations of values, which may appear in the lRD are specified once only wherever possible. In order

41、of preference, each constraint is specified: In addition to their specification in 6, referential constraints are also illustrated diagrammatically in clause 5. The rest of tlus clause describes the diagramming a) witin the formal data in clause 6; conventions used for different types of referential

42、 constraint and the SQL syntax used to represent each type. b) in the description of the relevant table, in clause 6; c) in the description of the services that can be used to change the data, in clause 9. 4*7.2 Overview Of referential constraints It is necessary to explain the type of referential c

43、onstraints me specification of anstrain a row in which any of these columns is null is considered not to reference table A; Optional at referenced table - if a row may exist in table A without being referenced from any row in table B; Required at referencing table - if the referencing columns in tab

44、le B may not be null. Every row in table B must reference a row in table A. Required at referenced table - if arow in table A may exist only if there is a correspondmg row in table B that references it. The following basic constructs are used within the Data Structure Diagram to illustrate these con

45、straints. Each half of the line that represents the constraint is treated separately in illustrating the characteristics of the constraint at each table. a) Solid line - the constraint is Tequired at that table; b) Dashed line - the constraint is optional at that table; c) “Crows feet” at end of lin

46、e - represents a one-to-many constraint. (Crows feet are not allowed at both ends of a line.) d) No “crows feet” at either end - represents a one-to-one constraint. The diagrammatic representations of some of the various constraint types listed above are now illustrated. In each case, an example is

47、also given of how the relevant constraint would be expressed in clause 6, using SQL with or without accompanying English description. 4.73 Optional one-to-many referential constraint Figure 1 - Optional referential constraint Table 1 shows the corresponding SQL syntax. Table 1 : SQL corresponding to

48、 Figure 1 CREATE TABLE A (A1 IRDS-KEY PRIMARY KEY) CREATE TABLE B (81 IRDS-KEY PRIMARY KEY, 82 IRE-KEY CONSTRAt NT constraint-name REFERENCES A ON DELETE referential-action ) In table 1 and similar tables, IICDS-KEY represents the name of a domain (see ISO/IE 9075) which is used throughout the table

49、s defined in clause 6. It is used here solely to make these examples look as similar as possible to the SQL used in clause 6. The SQL syntax used in clause 6 will normally contain an ON DELETE clause, similar to that shown in Table 1. This clause specifies additional information that is not shown in the diagm - namely the action to be taken when an attempt is made to delete a row in table A that is referenced by a row in table B. For an optional referential constraint, as shown in table 1, the referential action can be one of the following: a) RESTRICT - (cannot be specified explici