Tiêu chuẩn iso tr 09007 1987 scan

TECHNICAL REPORT 9007 Published 1987-07-01 INTERNATIONAL ORGANlZATlON FOR STANDARDIZATION Information terminology information MEXAYHAPO,QHAfl OPTAHM3A~MR i-l0 CTAHAAPTM3A~M~*ORGANISATlON INTERNATIONALE DE NORMALlSATlON processing systems - Concepts and for the conceptual schema and the base IS0 (the International Organization for Standardization) is a worldwide federation of national standards bodies (IS0 member bodies) The work of preparing International Standards is normally carried out through IS0 technical committees Each member body interested in a subject for which a technical committee has been established has the right to be represented on that committee International organizations, governmental and non-governmental, in liaison with ISO, also take part in the work The main task of IS0 technical committees is to prepare International Standards In exceptional circumstances a technical committee may propose the publication of a technical report of one of the following types : - type 1, when the necessary support within the technical committee cannot be obtained for the publication of an International Standard, despite repeated efforts; - type 2, when the subject is still under technical development requiring wider exposure; - type 3, when a technical committee has collected data of a different kind from that which is normally published as an International Standard (“state of the art”, for example) Technical reports are accepted for publication directly by IS0 Council Technical reports types and are subject to review within three years of publication, to decide if they can be transformed into International Standards Technical reports type not necessarily have to be reviewed until the data they provide is considered no longer valid or useful ISO/TR 9007 was prepared by Technical Committee ISO/TC 97, information processing systems The reasons which led to the decision to publish this document in the form of a technical report type are explained in the Preface Ref No ISO/TR 9007 : 1987 (E) U D&81.3.02 Descriptors: International data processing, Organization Printed in Switzerland information interchange, for Standardization, factual data bases, basic concepts 1987 l Price based on 120 pages *I r4f t:.’ ‘,;” ; ISO/TR 9007 : 1987 (E) 0.1 PURPOSE OF THE REPORT It is expected that future data base management systems will include a component for handling conceptual schemata This Report explains the roles and concepts for a conceptual schema with the intention of providing a framework for discussion and for the design of conceptual schema languages The rules described in the conceptual schema control to a large extent what may or may not happen in an information system and a data base Therefore this Report is not limiting its attention to the conceptual schema alone, but also considers basic concepts for the aechanl sum Involved in manipulatiw a conceptual schema and a data base This Report as suppliers is aimed at designer8 of information systems and data bases as well of conceptual schema facilities The provided framework will pre- pare the way for eventual standardization in the area of data base management describe any particular method for using such facllhowever, It does not, In the meantime, the general principles in this Report can be used to ities evaluate emerging DBMS facilltleso and associated languages described The approaches are intended to be explanatory only and are not standard conceptual schema language 0.2 in appendices to the Report ipso facto candidates for a STRUCTUREOF THEi REPORT The main body of the Report (chapters one through four) tal concepts and terminology for the conceptual schema, involved in manipulating them and the mechanisms contains the fundamenthe information base, mentions the origins of some one gives an introduction to the subject, and discusses some major topics In particular, ideas developed in the Report, it explains what a conceptual scheam is used for, its roles, aad requirements for a conceptual schema facility Chapter provides definitionsof the concepts fundamental concepts, Chapter two explain8 and tenas and develops some of the consequences of those concepts and deflnitlons Both static and dynamic aspects of the information system are considered Some readers may wish to skip this chapter on the first reading and explained some aspect8 of implementation In particular, Chapter three discusses are formulated for the contents and scope of a conceptual schema, ciples information system architecture based on three levels is outlined , Chapter four reviews for data bases The approaches detail to the Report in appendices some approaches to selected information modelling for illustration are prln- and an and manipulation outlined in more ISO/TR 9007 : 1987 (E) Severs1 appendices have Appendix A gives a glossary Appendix B provides ling been added of the an example to the Repmt terms as follows: and definitions situation to be described in information model- approaches Appendix a syntax C gives conceptual schema languages Appendix D outlines Appendix E demonstrates Appendix F discusses Appendix G elaborates schemata Appendix exaaplea notation H presents of pemissi for Binary Predicate on expressing dynamic H-ary Logic rules interacting thought Od action descriptions STATUS OF THE REPORT This Report grammar8 of example approaches and Elementary Interpreted ble defining e Entity-Attribute-Relatianship 0.3 is to be used Relationship approaches approachem and constraint8 with information in conceptual systems an IS0 Technical Report of tppe It fs the Working Group’cr its Program of Work As such it is a statement of view on concepts for conceptual schemata and inforthe rapid development in data base technology and mation bases Considering also takingi into account the requirments for diatriapplication8 pomible, buted data base systems and related data camwnication facilities, periodic revisions of the Report are to be expected first response to ita of the Uorklng Group’s current 0.4,.A REFERENCES [l) MURRAY, 3.A.H et al ‘The Oxford English Dictionary’ with Clarendon Press, 1933 - 1977 supplements, ISO/TR 9007 : 1987 (E) 1.1 1.2 1.3 1.4 Chapter INTRODUCTION TO THE CONCEPTUALSCHEMA AND THE wFO&MTION BASE The ANSI/SPARC framework The universe of discourse Describing the universe of discourse Static and dynamic aspects of a conceptual schema and information base Interaction between the real world and an information system The roles of users and information processors Guideline8 for the description of a universe of discourse Guidelines for the contents of a conceptual schema* Roles for a conceptual schema Requirements for a conceptual schema facility References 1.5 1.6 1.7 1.8 1.9 1.10 1.11 Chapter FUNDAMENTALSFOR A CONCEPTUALSCHEMAAND AN INFORMATION BASE 2.1 General concepts and definitions 2.2 Basic concepts and definitions for actions on the conceptual schema and infotmatioa base 2.3 The behaviour of an information processor schema 2.4 Xnserting a conceptual schema - the minimal conceptual 2.5 Behaviour rules for the environment 2.6 Static and dynamic rules and constraints 2.7 Expressing tules and constraints 2.8 Co-ordination of permissible actions 2.9 References Chapter 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 Chspter SOME CONCEPTSAND PRINCIPLES FOR IMPLEMENTATION Principles for the contents and scope of a conceptual schema Principles for the description of a universe of discourse Abstract syntax for a conceptual schema and information base Semantics of a conceptual schema and information base Principles for the composition of conceptual schemata The Three Level Architecture Information Resource Dictionary Systems (IRDS) Model The conceptual schema in the context of current DBMS implementation Correspondence of the Three Level Architecture for information systems and the Reference Model for Open Systems Interconnection References OF SOMEMODELLING APPROACHES Introduction Review of some approaches 4.2.1 Entity attribute relationship approaches 4.2.2 Binary and elementary n-ary relationship approaches 4.2.3 Interpreted predicate logic approaches 4.3 Translation of approaches to current data base technology OVERVIEW 4.1 4.2 6.4 References 9 10 11 13 13 14 15 16 17 18 19 21 21 28 31 33 34 34 36 38 44 45 45 47 50 51 51 53 58 59 60 61 63 63 64 66 66 67 68 70 ISO/TR 9007 : 1987 (E) Appendix A Appendix B B.1 8.2 B.3 Appendix GLOSSARY OF TERMINOLOGY M DEFINITIONS 71 EXAMPLE UNIVERSE OF DISCOURSE Introduction Rules, etc Some things for the universe of discourse and happenings in the relevant entity world C THE PASCAL SYNTAX NOTATION D, THE ENTITY - ATTRIBUTE - RELATIONSHIP Emphasis of the approaches Primitive concepts of the approaches* D.2.1 The basic concepts D.2.2 Abstraction concepts 0.2.3 Characteristics of relationships D.3 Grammar and semantics 0.4 Graphic formalism Appendix 81 APPROACHES D.1 D.2 D Hodelling 0.5.1 Some pragmatic modelling rules 0.5.2 Formal rules for mdelling D Example conceptual schema D.6.1 Graphic representation D.6.2 Language example D.7 Check list for the conceptual schema 0.8 Mapping of an EAR conceptual schema to a network schema and a relational data base schema D.9, References Appendix 83 83 84 84 84 86 91 93 94 94 95 96 96 97 99 data base E TIiE BINARY RELATIONSHIP APPROACHES E.1 E.2 E.3 77 77 77 79 Emphasis of the approaches Primitive concepts of the approaches Grammar and semantics E.3.1 The language and its relation to the universe of discourse E.3.2 Formal syntax E.3.3 Semantics E.4 Graphic formalism E.4.1 Linguistic object types E.4.2 Binary relationship types E.4.3 Constraints having a diagrammatic representation E.4.4 Some examples of the graphic formalism symbols E.5 Xodelling E.6 Example conceptual scheme E.6.1 Graphic representation E.6.2 Language example E.7 Check list for the conceptual schema E.8 References 102 104 105 105 107 111 111 113 115 117 117 118 118 119 121 122 122 123 131 134 ISO/TR 9007 : 1987 (E) Appendix F THE INTERPRETED PREDICATE LOGIC APPROACHES F.1 Emphasis of the approaches F.2 Primitive concepts of the approaches P.3 Grammar and semantics F.3.1 Abstract syntax F.3.2 Concrete syntax P.3.3 Semantics F.4 Graphic formalism P.S Modelling F.S.l Cla8sification of axioms P.5.2 Gonstruct8 P Example conceptual schema F.6.1 Graphic representation F.6.2 Language example F.7.Xh&ck list for the conceptual schema F.8 References 135 135 136 137 137 139 142 142 143 143 146 154 154 155 166 169 Appendix G EXAMPLES OF DYNAMIC RULE DESCRIPTION G.L Introduction G.2 State-oriented descriptions 6.3 State-oriented description of rules in the example conceptual schema 6.4 State independent rules in action-oriented descriptions G.5 State dependent rules in action-oriented descriptions G.6 Action-oriented description of rules in the example conceptual schema 171 171 171 Appendix 177 177 178 H EXAMPLES OF CO-ORDINATING H.1 8.2 H.3 R.4 PERMISSIBLE ACTIONS Interaction between environment and information system Some implementation considerations for permissible actions Describing pemissible actions in the example conceptual schema References 171 172 173 173 179 184 ISO/TR 9007 : 1987 (E) THE HELSINKI PRINCIPLE These utterances utterances [l]: are’ to be interpreted (recursively) as international English depends upon the prior existence hy meaningful exchange of utterances set of semantic and syntactic rules The recipients of of an agreed the utterances must use only these rules to interpret the received utif it is to mean the same as that which was meant by the terances, utterer (IS0 TC97/SCS/WG3 - Helsinki "THE METAPHOROF THE SEARCHLI(XTS" on universes of discourse 1978) This page intentionally left blank lSO/TR 9007 : 1987 E) CHAPTERhe INTRODUCTIONTO THE CONCEPTUALSCHEMAAND THE INFORMATIONBASE .-o -1 1.1 THE ANSI/SPARC FRAMEWORK The reports of the ANSI/XB/SPARC DBSG [l, 21 identified tual schema in the context of a three-schema framework for the need for a concepdata base management SyStelllSe Subsequent papers [3, 4, 5, 6, 71 have emphasized the importance of a conceptual schema to users and designers of data base systems In this context, a conceptual schema comprises a unique central description of the various informathe description of what tion contents that may be in a data base This includes such as changes and retrievals, actions, are permissible on the information The data base itself may be implemented in any one of a number of posscontent programs may view the data in a variety ible ways Users and application of by an external schema Each external schema is therefore ways each described storage structure that derived from the common conceptual schema The physical by an internal schema that is also may be in use at any given time is described derived from the conceptual schema on the meaning of the The conceptual view, as meant by ANSI/SPARC, concentrates It is the conceptual schema that describes this view The external informatioL that represent the information to views concentrate on the forms - the data These are described in the external schemata The internal view the outside concentrates on the internal physical representation of the data inside the computer system and is described in the internal schema Such a three-schema framework is widely, but not yet universally, accepted It is assumed in this report Furthermore, it may be noted that the conceptual schema concept is valuable in other environments than a three-schema framework schema also plays a key role in It is widely acknowledged that the conceptual One may therefore ask whether it should systems analysis and data base design Should the conceptual schema be primarily an enbe biased to one or the other or should it serve as a from the systems analysis, terprise model, resulting data base design? We believe focal point between user views and the physical that it should play both roles in the next generation of DBMS We believe the data base user will benefit from the clear separation of the information meaning from the external data representation and the internal physiA clear methodology for producing a conceptual schema cal data storage layout of an information system to improve his systems would help the implementor it into data base design in even if a manual step of translating analysis, terms of an existing DBMSwere then required ISO/TR 9007 : 1987 (I3 the conceptual schema in broad terms Resides, the The ANSI reports introduced is sometimes used for data base aspects which are not term "conceptual schema" Therefore, elaboration of the conceptual schema's objecat all ConceptuaL form, and content is needed What a conceptual schema must intives, roles, which appropriate modelling concepts are to be used in it, and the exact clude, are the major subjects of this Report role it plays in data bases, 1.2 THE UNIVERSE OF DISCOURSE systems were often designed so as to provide all In the past, data processing However, users with the same set of capabilities or functions this uniform functional view is not adequate to construct today's data base systems A different functional requirements concursingle data base may support quite or at different times, during its existence rently, is that common data is The prime characteristic of the data base environment By sharing common data, these shared between many users of a single system users establish a dialogue with each other through the system Clearly, if this communication is to be useful and reliable there must be some common understanding of the information represented by the data Since it may happen that must refer to something extertwo users never meet, this common understanding must be recorded and in order to nal to both of them This common understanding establish a dialogue a common predefined established grammar is needed We will call those things and happenings to which the common understanding of the universe of discourse Universes of disthe represented information refers or abstract like the organizational course may be concrete like an inventory, They even may be hypothetical like Wonderland which structure of an enterprise was visited by Alice In this Report of discourse we will take an (informal) naive realism approach to universes is perceived as containing real and abstract The typical universe of discourse objects, which we will call entities It can be perceived as also containing classes of entities, e.g persons, departments, and dates This classification is based on similarity and takes into account characteristics common to several The selection of characteristics for grouping the entities into entities the choices will be made pragmatically, based on the classes is arbitrary; purpose of the universe of discourse Some general properties to which entities adhere, that classify entitfes, that in the universe of discourse are also perceived associate entities, etc., a person may be assigned to no more than one (e.g persons are not departments, These may be informally described as "classifications", "rules", department) about the state of affairs and behaviour of entities in "laws" or "constraints" the universe of discourse what is considered to be part of the universe of discourse will be In general, the selected things and happenings may change with time-dependent, that is, time This will be equally true for the classifications, rules, laws, etc; howit is likely that the rate of change of these will be relatively slow ever, compared with that of the former 10 ISO/TR 9007 : 1987 E) onstrates the principle with numbers through all times only one of them: The uniqueness of registration In accordance with the above mentioned requirement, the example in appendix F, section F.69 demands that for all days of the universe of discourse the recorded registration number of a car must be that of its initial registration (axioms simultaneous change of the initial 66 and 89) However, so far nothing prevents registration number together with a corresponding change of all recorded inforOld and New and the mechanism mation about the same car With the predicates described in section G.2 dynamic rules for the impossibility to change registration numbers can be expressed as follows: For all R For all R' For all c For all d (If R -Is record Gf c On -d & ,Id R & Not K = & R' 1; record of c On -d & Few R' Then R N Denotations:(Registration:c) = R" N Denotztions:(Registration:c)) This rule requires that a non-empty record for some car on some day can never be changed with respect to registration number* Mind that it only prevents it does not provide for consistent history as required for history distortion; The latter is taken care of by axioms 66 and 89 any one information base state It should be remarked that above we assume the records of section F.6 in appendix F to be sentences in the information base If this is not desirable, we have to introduce sentences about records for which we can apply the same considerations G.4 STATE INDEPENDENT RULES IN ACTION-ORIENTED DESCRIPTIONS A state independent rule determines the actions that are permissible, irrespective of the state of the conceptual schema and information base they are applied useful is to A kind of state independent rule which seems to be particularly This means that for any action to be the grouping together of basic actions permissible according to this rule it must contain all of those basic actions of the basic actions constituting the rule, or none of them Thus, ifany involved in the rule occura given permissible action, then all other remaining constituents of that rule must necessarily also occur They need not and they may be interspersed appear in the same order as specified in the rule, among other basic actions use a procedural notation to denote For the purpose of this chapter we will using command statements that possibly contain formal parameters basic actions, which have to be replaced by actual occurrences in order to activate the proper with formal parameters, possibly Groupings of basic command statements, actions express dynamic rules as discussed above and will be denoted as follows: together bc bc 0.0 bc end 172 n ISO/TR where bc bc stand n' meters, h to basic t at refer l ee Referring to pressed by: the first for command statements, actions example in chapter together INSERT (person INSERT (person end Additional examples can be found possibly 2, section 2.7, with formal the rule 9007 : 1987 EI para- may be ex- WORKSFOR department), HAS salary) in section Ge6 G.5 STATE DEPENDENT RULES IN ACTION-ORIENTED DESCRIPTIONS A state dependent rule determines which actions may be applied to a given of the conceptual schema and informati.on base in order to be permissible set of actions permissible with respect to a state dependent rule is tionally dependent on the current state This means that, for any action the current state must satisfy a permissible according to such a rule, ified criterion Whether the criterion is satisfied or not is dependent aCtlOnSe performance of previous A state dependent rule is expressed that the action is only permissible evaluates to true In order to express where test Referring to the last examples use the following example may possibly in chapter spec- on the means state notation: test command statement and command statement only-if not and not al%mERT Additional we will such rules, only-if allow by a test and a command statement It if the test applied to the current state The functo be \ have formal 2, section 2.79 parameters the rule is denoted by: (person-l MARITAL-STATE 'married') (person-2 MARITAL-STATE 'married‘) (person IS MARRIED TO person) can be found in section Ge6 G.6 ACTION-ORIENTED DESCRIPTION OF RULES IN THE EXAMPLE CONCEPTUALSCHEMA to the example of appendix B may The following description of dynamics applied of statics in the approaches given in previous apsupplement the descriptions pendices In order not to overload notation with trivialities but to concentrate some obvious rules are omitted, emgo that a manufacturer on relevant aspects, that garages and persons must exist when they must exist when he produces cars, etc It is hoped that the example sell or buy cars, that these cars must exist, by such rules a simple (though provides enough evidence to make its completion possibly boring) exercise Also omitted is a description of the tests and functions occurring in the tests 173 ISO/TR 9007 : 1987 E) that are used in the dynamic rules below The verbal description of the in appendix B should make clear enough what is meant by the formulations here However, a complete list of basic command statements as suggested pendix B is given explicitly in order to show how they are used in the rules Please note that not all basic command statements may be used and others may be used only if some of them may only occur together, conditions are satisfied The respective rules are stated below as rules Command statements for basic example given ap- by dynamic freely; certain dynamic actions INSERT INSERT INSERT INSERT INSERT (MANUFACTURER manuf) (PERMISSION-TO-OPERATEmanuf) (MANUFACTURER manuf OPERATING) (CAR-MODELmodel, MANUF-BY manuf, (CAR, IS-OF model, HAS serial-no, INSERT INSERT INSERT INSERT INSERT INSERT INSERT INSERT manuf HAS reg-no) (CAR serial-no (CAR reg-no DESTROYEDdate) HAS fuel-cons-spec), MADE-BY manuf, PRODUCED-INprod-year) (GARAGE garage) (PERSONperson) (TRANS.OWN-TO-GARAGE owner, (TRANS.OWN-TO-PERSON owner, (owner garage, person, reg-no, reg-no, date) date), OWNS-CARreg-no) (FUEL-CONSUMPTION-RATEmax-cons, year) DELETE (PERMISSION-TO-OPERATE manuf) DELETE (GARAGE garage) DELETE (CAR reg-no) DELETE (PERSONperson) DELETE (TRANS.OWN-TO-GARAGE owner, DELETE (TRANS.OWN-TO-PERSON owner, DELETE (owner OWNS-CARreg-no) DELETE (owner OWNED-CARreg-no) garage, person, reg-no, reg-no, date) date), MODIFY (MANUFACTURER manuf OPERATING) TO (MANUFACTURER manuf NON-OPERATING) MODIFY (owner OWNS-CARreg-no) TO (owner OWNED-CARreg-no) Dynamic rules In order to facilitate comparison with the verbal conceptual schema in section under the appropriate B, the dynamic rules are grouped together used there B.2 of appendix headlines Manufacturers of cars: may be in operThe static rule "no more than five manufacturers in this framework ation at any time" may be expressed dynamically "INSERT (MANUFACTURER manuf)" by requiring that the basic action may be applied only if the number of manufacturers in the information base is less than five We ommit here - and in the sequel the action-oriented reformulation of the static rules Remark: only-if allow 174 (PERMISSION-TO-OPERATE manuf) INSERT (MANUFACTURER manuf OPERATING)., ISO/TR 9007 : 1987 E) only-if allow for all reg-no not wIF(MANUFACcER (manuf OWNS-CARreg-no) manuf OPERATING) TO (MANUFACTURER manuf NON-OPERATING) only-if allow (MANUFACTURERmanuf NON-OPERATING) DELETE (PERMISSION-TO-OPERATEmanuf) only-if prod-year = this-year = previous-year and this-month = 'January‘ or prod-year INERT (CAR, IS-OF model, HAS sxal-no, MADE-BY manuf, PRODUCED-IN prod-year) Cars: allow together INSERT (CAR, IS-OF model, HAS serial-no, MADE-BY manuf, PRODUCED-IN prod-year), INSERT (CAR serial-no manuf HAS reg-no), INSERT (manuf OWNS-CARreg-no) end only-if date(CAR reg-no DESTROYEDdate) and today = '31 December' al= DELETE (CAR reg-no) AT LEAST YEARS BEFORE today together DELETE (CAR reg-no), for all owner if (owner OWNS-CARreg-no) -then DEL!XE (owner OWNS-CARreg-no), for all owner if (owner OWNED-CARreg-no) then DELETE (owner OWNED-CARreg-no), for all garage if (TRANS.OWN-TO-GARAGE owner, garage, reg-no, date) -then DELETE (TRANS.OWN-TO-GARAGE owner, garage, reg-no date), for all person if (TRANS.OWN-TO-PERSON owner, person, reg-no, date) -then DELETE (TRANS.OWN-TO-PERSON owner, person, reg-no, date) end Car models: only-if allow for all manuf not (CAR-MODELmodel MANUF-BY manuf) ?%ERT (CAR-MODELmodel, MANUF-BY manuf, HAS fuel-cons-spec) Fuel consumption: The first interaction two sentences state that is not treated static in this The third rules approach sentence describes an Garages: only-if allow for all reg-no not (garage DELETE (GARAGE garage) OWNS-CARreg-no) 175 ISO/TR 9007 : 1987 U3 Persons: only-if for all reg-no not (person and for all reg-no not (person ali-o'-;;mETE (PERSON person) OWNS-CARreg-no) OWNED-CARreg-no) Car ownership: Here no dynamic Transfer rules are specified of ownership: only-if allow not (GARAGE owner) INSERT (TRANS.OWN-TO-GARAGEowner, garage, reg-no, date) only-if allow not (MANUFACTURERowner) INSERT (TRANS-OWN-TO-PERSONowner, person, reg-no, date) together INSERT (TRANS-OWN-TO-GARAGEowner, garage, reg-no, date), MODIFY (owner OWNS-CARreg-no) TO (owner OWNED-CARreg-no), INSERT (garage OWNS-CARreg-no) end together if not then IN* MODIFY INSERT end 176 (PERSON person) INSERT (PERSON person), (TRANS-OWN-TO-PERSONowner, person, reg-no, date), (owner OWNS-CARreg-no) TO (owner OWNED-CARreg-no), (person OWNS-CARreg-no) ISO/TR 9007 : 1987 (El H.1 INTERACTION BETWEENENVIRONMENTAND INFORMATION SYSTEM An example may help information system The external to discuss the interactions between the environment and the event "GARAGE garage is reported to the information system this information in the Information name of the new garage: IS ESTABLISHED" The message contains a command to insert base, and an input-sentence stating the EXEC ESTABLISH-TRADING-GARAGE NEW GARAGEgarage.' command: input-sentence: As, according to a new garage, no the permissible triggered (figure or rules appendix B, no constraints other events are needed to fulfil The permissible action asked for H.l.) are relevant for establishthe command condition for action therefore will be Garage + Int.Ev Trading mExt.Ev GARAGEgarage Is Established w Et!; Figure According to lities exist: rules H.1 and constraints In the information A garage In the first sentence Therefore the the internal case, of that no static Int.Ev Gaaid ESTABLISH-TRADING-GARAGE the garage-name base the new garage name is 1-w already or dynamic must be unique is not known in the rules will Two possibi- yet known information be violated base by inserting the GARAGEgarage TRADING0 will actually insert the sentence, causing information processor in an outgoing event "GARAGE TRADING", which may be reported message In the second case insertion of the sentence would violate a static rule to the the information processor effect that garage-names must be unique Consequently will refuse the insertion of the sentence and will report the refusal as an internal event "GARAGE REFUSED" 177 ISO/TR 9007 : 1987 E) H.2 SOME IMPLEMENTATION CONSIDERATIONS FOR PERMISSIBLE ACTIONS During this permissible the permissible action rules and constraints, It of recognizes the input action (and actually already before the execution of itself) the information processor deals with a number of as already stated in section 2.8 of chapter 2: the reporting of the event and the reception sentence according to recognition rules; It evaluates the permissible action state command condition and triggers or keeps the command condition the actual in a wait- After triggering the permissible action it performs the permissible action itself according to prescriptive rules e& pressed in the action description of the permissible action manipulating the conceptual schema and information base; It checks the manipulation of the conceptual schema and information base according to the appropriate static and dynamic rules and constraints for the conceptual schema and authorization rules; information base, and the appropriate It possibly reports one or more appropriate internal according to the prescriptive rules for the internal It possibly prescriptive generates rules for an outgoing message the outgoing message events events; according to Some authors (e.g [l]) consider the rules mentioned under 1, 2, 3, 5, and and the various prescriptive rules - as rules for the recognition rules, the permissive static and dynamic rules for the information interactions; rules in the special sense, as discussed are separately dealt with (cf 2.6) They therefore consider the information processor chapter 2, section monitor of two parts: the dynamics monitor and the transition sisting figure H.2) the base in con(see takes care of the interactive part of the permissible The dynamics monitor it according it processes to the recognition rules, That is, the action command condition rules and the prescriptive rules for the permissible action and the appropriate internal events and outgoing messages, if any To this the dynamics monitor can consult the conceptual schema directly However, it Therefore it is impossible for cannot consult the information base directly permissible actions to pass sentences accompanying internal events through the of the information base, these sentences being needed for command condition subsequent permissible action During the execution of the transition monitor information base an permissible commands for action the dynamics monitor passes elementary actions to manipulate to the The transition monitor manipulates the information base as a reaction to the commands given by the dynamics monitor and according to the static and dynamic rules and constraints of the conceptual schema and information base 178 ISO/TR 9007 : 1987 E) monitor Figure H.2 Gross architecture for an information system Other sources (e.g [2]) not distinguish between such a dynamics monitor and reason being that the distinction between the the principal transition monitor, various classes of rules is rather arbitrary They also conceive the inforto access all of the conceptual schema and information base mation processor whenever appropriate H.3 DESCRIBING PERMISSIBLE ACTIONS IN TUE EXAMPLE CONCEPTUALSCHEMA In this section we informally describe some permissible actions to deal with the interactions for the example of appendix B As it is our intention only to between events, command conditions, and permissible show the dependencies we refrain from fully listing all additional rules and constraints actions, in appendix G might suffice for that purpose For Such rules as explained of basic command statements given in appendix G, example, we use the list what actions are performed by the various permissible section 6.6, to indicate For the sake of simplicity in the demonstration, all external events actions are thought to be accompanied with an appropriate input message; all internal events imply an appropriate outgoing message sentence actually is inserted in the In some permissible actions the input information base - as e.g in permissible action In other cases, an input the input sentence sentence gives a reason for manipulating other sentences; action and 10 itself is not reproducible thereafter, - e.g in permissible Permissible action is an example where the input sentence itself is inserted, but also causes the insertion of an additional sentence Permissible action generation of an is an example where an external event sets off the possible outgoing message Permissible action 11 is an example by an internal event only of an permissible action that is triggered EXTERNAL EVENTS: EXT-1: EXT-2: EXT-3: EXT-4: PERMISSION-TO-OPERATE FOR MANUFACTURERmanuf MANUFACTURERmanuf IS OPERATING MANUFACTURERmanuf CEASES OPERATION CAR-MODEL model, MANUF-BY manuf, HAS fuel-cons-spec 179 I I ISO/TR 9007 : 1987 E) EXT-5: CAR, IS-OF model, HAS serial-no, MADE-BY manuf, PRODUCED-IN year-of-prod0 EXT-6: EXT-7: EXT-8: EXT-9: EXT-10: EXT-11: EXT-12: EXT-13: EXT-14: CAR reg-no IS DESTROYEDAT date FUEL-CONSUMPTION-RATE IS max-cons FOR year GARAGEgarage IS ESTABLISHED GARGAEgarage CEASES TRADING CAR reg-no IS TRANSFERREDFROMmanuf TO garage AT date CAR reg-no IS TRANSFERREDFROMgarage TO person, AT date CAR reg-no IS TRANSFERREDFROM person, TO garage AT date, CAR reg-no IS TRANSFERREDFROM person, @ TO person, oeo AT date IT IS NOWdate l INTERNAL EVENTS: INT-1: INT-2: INT-3: INT-4: INT-5/6: INT-7/8: INT-9: INT-10: INT-11: INT-12: INT-13: INT-14: INT-15: INT-16: INT-17: INT-18: INT-19: INT-20: MANUFACTURERmanuf ALLOWEDOPERATING MANUFACTURERmanuf NOT ALLOWEDOPERATING MANUFACTURERmanuf NON-OPERATING MANUFACTURERmanuf NOT ALLOWEDTO STOP OPERATING CAR-MODEL model IS ACCEPTED/REFUSED CAR MADE BY manuf HAS serial-no IS REGISTERED/REFUSED CAR reg-no REGISTERED DESTROYEDdate CAR reg-no HISTORY DELETED FUEL-CONSUMPTION-RATE FOR year IS max-cons MANUFACTURERmanuf EXCEEDEDFUEL-CONSUMPTION-RATE max-cons WITH average IN year GARAGEgarage TRADING GARAGEgarage TRADING REFUSED GARAGEgarage NOT TRADING GARAGEgarage REFUSED TO STOP TRADING CAR reg-no IS NOW OWNEDBY manuf CAR reg-no IS OWNEDBY garage CAR reg-no IS NOW OWNEDBY person, TRANSFER OF CAR reg-no IS REJECTED PERMISSIBLE ACTIONS: PERMISSIBLE ACTION 1: ESTABLISH-OPERATING-MANUFACTURER Command condition: EXT-1 and EXT-2 Additional manuf of EXT.1 = manuf of EXT-2 rules: INSERT (MANUFACTURERmanuf OPERATING) Actions: Internal events PERMISSIBLE ACTION 2: Command condition: Additional rules: If manuf INSERTED then INT-1 else INT-2 MANUFACTURER-CEASES-OPERATION EXT.3 and INT-1 INT-17 -and (not for all and (INT-9 INT-17: -xg-no or reg-no 180 or (INT-17 of INT-17 = reg-no of INT-17 = reg-no of INT-9 of INT-18 or INT-18))) ISO/TR 9007 : 1987 (El MODIFY (MANUFACTURERmanuf OPERATING) TO (MANUFACTURERmanuf NON-OPERATING) Actions: Internal events: If manuf NON-OPERATING then INT-3 else INT-4 Remark: The command condition together with the additional rules imply that the manufacturer either never has owned a car (not INT-17), or any car owned (INT-17) should either be sold (INT-18 where reg-no of INT-17 = reg-no of INT-18) or be destroyed (INT-9 where reg-no of INT-9 = reg-no for one INT-17 of INT-17) Note, that each car owned is responsible with accompaning reg-no Comparable remarks could be made for the other permissible action descriptions L PERMISSIBLE ACTION 3: ESTABLISH-CAR-MODEL Command condition: EXT.4 and INT-1 Additional manuf of EXT.4 = manuf of INT-1 rules: INSERT (CAR-MODEL model, Actions: Internal events: PERMISSIBLE ACTION 4: MANUF-BY manuf, HAS fuel-cons-spec) IF CAR-MODELmodel INSERTED then INT-5 else INT-6 REGISTER-CAR Command condition: EXT.5 and INT-5 Additional model of EXT.5 = model of INT-5 rules: INSERT (CAR IS-OF model, HAS serial-no, MADE-BY manuf, PRODUCED-IN year of prod) - Generate reg-no INSERT (CAR serial-no manuf, HAS reg-no) Actions: Internal events: PERMISSIBLE ACTION 5: If CAR HAS reg-no -then INT-7 else INT-8 REGISTER-CAR-DESTROYED Command condition: EXT.6 and INT-7 Additional reg-no of EXT-6 = reg-no rules: INSERT (CAR reg-no Actions: Internal events: PERMISSIBLE ACTION 6: Command condition: of INT-7 DESTROYEDAT date) INT-9 FORGET-CAR-HISTORY EXT.14 and INT-9 181 ISO/TR 9007 : 1987 E) Additional rules: date of EXT.14 = 310dec-current-year and f= all INT-9: current-year = year-of-destruction + Dura tion: EXT-14: day Acti ons: IS-OF model, HAS serial-no, DELETE (CAR reg-no, MADE-BY manuf, PRODUCED-IN year of prod, DESTROYEDdate) for all owner if (owner OWNS-CAR reg-no) -then DELETE (owner OWNS-CARreg-no) for all owner ifowner OWNED-CARreg-no) -then DELETE (owner OWNED-CARreg-no) for all garage if (TRANS-OWN-TO-GARAGE owner, garage, reg-no, date) then DELETE (TRANS-OWN-TO-GARAGE owner, garage, reg-no, date) for all person ff(TRANS-OWN-TO-PERSON owner, person, reg-no, date) then DELETE (TRANS.OWN-TO-PERSON owner, person, reg-no, date) if TRANSFER-GARAGE-PERSempty and TRANSFER-PERS-PERS empty then DELETE (PERSON pea Internal events: PERMISSIBLE ACTION 7: INT-10 ESTABLISH-MAX-RATE Command condition: EXT-7 Actions: INSERT (FUEL-CONSUMPTION-RATE max-cons, Internal events: PERMISSIBLE ACTION 8: INT-11 ESTABLISH-AVERAGE-RATE Command condition: EXT.14 and INT-7 Additional date of EXT-14 = 310Jan-current-year and yzr of INT-11 = current-year - and for a= INT-7: year of INT-7 = year - rules: Duration: EXT-14: Actions: for Internal and INT-11 of INT-lle day all MANUFACTURERmanuf: for all CAR with prod-year = current-year RETRIEVE (CIS-OF model) RETRIEVE (MODEL HAS fuel-cons-spec) - establish average - events: if then 182 year) average > FUEL-CONSUMPTION-RATEmax-cons of current-year - INT-12 foTMANUFACTURER manuf - ISO/TR PERMISSIBLE ACTION-g: ESTABLISH-TRADING-GARAGE Command condition: EXT.80 Actions: INSERT (GARAGE garage TRADING) Internal events PERMISSIBLE ACTION 10: Command condition: Additional rules: If garage INSERTED then INT-13 else INT-lb GARAGE-CEASES-TRADING EXT.9 and INT-13 INT-18 -and (not for and (INT-9 or INT-19))) or (INT-18 all INT-18: reg-no of INT-18 or reg-no of INT-18 = reg-no = reg-no events: PERMISSIBLE ACTION 11: If garage DELETED then INT-15 else INT-16 MANUFACTURER-OWNS-CAR Command condition: INT-7 Actions: INSERT (manuf OWNS-CARreg-no) Internal events PERMISSIBLE ACTION 12: Command condition: Additional of INT-9 of INT-19 DELETE (GARAGE garage) Actions: Internal 9007 : 1987 (E) rules: INT-17 CAR-DISTRIBUTED-TO-GARAGE EXT.10 and INT-13 reg-no and INT-17 of EXT-10 = reg-no of INT-17 garage of EXT-10 = garage of INT-13 INSERT (TRANS.OWN-TO-GARAGEowner, Actions: garage, reg-no, date) MODIFY (manuf OWNS-CARreg-no) TO (manuf OWNED-CARreg-no) Internal events: PERMISSIBLE ACTION 13: If garage OWNSCAR then INT-18 else INT-20@ CAR-SOLD-BY-GARAGE-TO-PERSONS Command condition: EXT.11 and INT-18 Additional reg-no rules: of EXT.11 = reg-no of INT-18 183 ISO/TR 9007 : 1987 (E) Actions: for all person, if person UNKNOWN then INSERT (PERSON person) INSERT (TRANS.OWN-TO-PERSON garage, Internal events: PERMISSIBLE ACTION 14: Command condition: rules: Additional Internal events: PERMISSIBLE ACTION 15: EXT.12 and INT-13 person, (TRANS-OWN-TO-GARAGEperson, If garage OWNSCAR then INT-18 else INT-20 CAR-SOLD-BY-PERSONS-TO-PERSONS Additional reg-no Internal H.4 of INT-18 person, reg-no, date) If person OWNSCAR then INT-19 else INT-20 REFERENCES PI VI 184 of EXT.13 = reg-no for all person, TfFrson UNKNOWN then INSERT (PERSON person) INSERT (TRANS-OWN-TO-PERSONperson, events: date) and INT-19 reg-no of EXT.12 = reg-no of INT-19 garage of EXT-12 = garage of INT-13 EXT-13 and INT-18 Actions: garage, reg-no, CAR-SOLD-BY-PERSONS-TO-GARAGE Command condition: rules: date) If person OWNSCAR then INT-19 else INT-20 for all INSERT Actions: person, reg-no, HECKENROTH,H., TARDIEU, H., ESPINASSE, B outils 'Modsles et pour la conception de la cingmatique d'un syst2me d'information', Rapport de recherche IRIA 310, CETE d'Aix, Grasce, Universit6 d'Aix - Marseille, 1980 van GRIETHUYSEN, J.J 'Notation Methods for an Information Internal Report, N.V PHILIPS, Model' 1978, 1981 This page intentionally left blank This page intentionally letI blank