SAE GEIA-HB-927-2007 Implementation Guide for Common Data Schema for Complex Systems (Formerly TechAmerica GEIA-HB-927).pdf

1、 SAE Technical Standards Board Rules provide that: “This report is published by SAE to advance the state of technical and engineering sciences. The use of this report is entirely voluntary, and its applicability and suitability for any particular use, including any patent infringement arising there

2、from, is the sole responsibility of the user.” SAE reviews each technical report at least every five years at which time it may be revised, reaffirmed, stabilized, or cancelled. SAE invites your written comments and suggestions. Copyright 2013 SAE International All rights reserved. No part of this p

3、ublication may be reproduced, stored in a retrieval system or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of SAE. TO PLACE A DOCUMENT ORDER: Tel: 877-606-7323 (inside USA and Canada) Tel: +1 724-776-497

4、0 (outside USA) Fax: 724-776-0790 Email: CustomerServicesae.org SAE WEB ADDRESS: http:/www.sae.org SAE values your input. To provide feedback on this Technical Report, please visit http:/www.sae.org/technical/standards/GEIAHB927 TECHNICAL REPORT GEIA-HB-927 Issued 2007-07 Implementation Guide for Co

5、mmon Data Schema for Complex Systems NOTICE This document has been taken directly from the original TechAmerica document and contains only minor editorial and format changes required to bring it into conformance with the publishing requirements of SAE Technical Standards. The release of this documen

6、t is intended to replace the original with the SAE International document. Any numbers established by the original document remain unchanged. The original document was adopted as an SAE publication under the provisions of the SAE Technical Standards Board (TSB) Rules and Regulations (TSB 001) pertai

7、ning to accelerated adoption of specifications and standards. TSB rules provide for (a) the publication of portions of unrevised specifications and standards without consensus voting at the SAE committee level, and (b) the use of the existing specification or standard format. TechAmerica Engineering

8、 Bulletin Implementation Guide for Common Data Schema for Complex Systems GEIA-HB-927 July 2007 GEIA-HB-927PLEASE! DONT VIOLATE THE LAW! This document is copyrighted by TechAmerica and may not be reproduced without permission. Organizations may obtain permission to reproduce a limited number of copi

9、es by entering into a license agreement with our distributors. For distributor information please see our web site www.techamerica.org/ or contact TechAmerica at 703-284-5355 TechAmerica Implementation Guide for Common Data Schema for Complex Systems GEIA-HB-927 Revision Description of change Date -

10、 Initial Release Jul 2007 GEIA-HB-927 TABLE OF CONTENTS TABLE OF CONTENTS .I TABLE OF FIGURES.III 1 PREFACE. 1 1.1 The Problem 1 1.2 Approach to Problem Solution 2 2 INTRODUCTION 2 3 DATA MODELING GUIDELINES. 3 3.1 Scope.4 3.2 General Requirements4 3.3 The Six Principles .5 3.4 Naming.8 3.5 Speciali

11、zation.8 3.6 Identity.8 3.7 Capitalization 9 3.8 Use of EXPRESS elements .9 3.9 Normalization17 3.10 Documentation 17 3.11 EXPRESS-G Diagrams 19 3.12 Data Modeling Guidelines References 23 4 DATA MODEL USAGE GUIDE 24 4.1 Modeling Philosophy 24 4.2 GEIA-STD-927 DATA MODEL CONCEPTS.27 4.3 Model Usage

12、Guide References .43 4.4 Acronyms.43 5 INTEGRATION PROCEDURE . 44 5.1 Purpose.44 5.2 Procedure Model.44 5.3 Description.46 5.4 Roles .46 5.5 Inputs .46 5.6 Entry Criteria46 5.7 Activities to Be Performed .46 5.8 Outputs.59 i GEIA-HB-927 5.9 Exit Criteria.60 5.10 Policies60 5.11 Standards.60 5.12 Mea

13、sures 60 5.13 Training .60 5.14 Tools .60 5.15 Tailoring.61 5.16 Acronyms.61 5.17 Integration Procedure Terms and Definitions .61 5.18 Template Forms 62 5.19 Disposition Definitions66 5.20 Integration Action Decision Matrix (Element Disposition) 66 5.21 Analysis Instructions provide a way for stakeh

14、olders to understand their needs in relation to the enterprise as a whole; and provide a continuous proactive means of identifying and successfully addressing key challenges for a complex system over time. 3. The third element is an evolved culture where enterprise-wide cooperation is the rule and i

15、ndividual contributions are encouraged and efficiently managed. Working within an integrated environment based on these three elements will provide a common frame of reference in which sophisticated relationships across technical domains, and between these domains and a systems affordability, can be

16、 explicitly identified and analyzed. The key to realizing gains from the combined elements is the data schema, which is essential to integrating the disparate data sets in use by complex system program offices and other related enterprises. 2 Introduction The purpose of this handbook is to provide t

17、he data modeler with the modeling conventions, philosophy and guidelines used during development of the GEIA-STD-927 schema; and the integration process used to integrate existing best-in-class standard data models into the GEIA-STD-927 schema. Most importantly, the handbook provides tailoring guide

18、lines for the data modeler to use in applying the GEIA-STD-927 schema and mapping tables to a practical application for an existing program. The Handbook is organized into four sections: Data Modeling Guidelines, Data Model Usage Guide, Integration Procedure, and Schema Tailoring Guidelines. The Dat

19、a Modeling Guidelines establish modeling conventions and guidelines followed during the development of the GEIA-STD-927 schema. The section was expanded as a result of lessons learned during the project, liaisons with other groups developing schemas, and other input into the program. The Guidelines

20、present general requirements for schema development, a set of principles to be followed, conventions to be used when naming data concepts, the use of supertype/subtype hierarchies, a recommended use of the Express 2 GEIA-HB-927 language constructs, and good graphical layout practice. It is intended

21、to provide guidance for maintaining the Common Data Schema and for schema development efforts. The purpose of the Data Model Usage Guide is to enable the user of the GEIA-STD-927 Data Model to understand how their legacy data source information fits into the GEIA-STD-927 Data Model. After a brief ov

22、erview of the modeling philosophy, this section presents various data model concepts and how they are approached. For each of these concepts, this section discusses typical representations in other models, the representation in the GEIA-STD-927 Schema, and related concepts. The Integration Procedure

23、 section describes the activities used to integrate best-in-class standard data models into the GEIA-STD-927 Common Data Schema. An overview of the process is followed by detailed descriptions of each step of the work. A formal description approach is used, with a common template being used for all

24、process steps. Key concepts in each Activity description include Roles to be filled, Inputs to the Activity, the Implementation steps and the Activity Outputs. The procedures defined in this section are used to perform the schema integrations and are referenced in the following section on schema tai

25、loring. Section 6, Schema Tailoring Guidelines, provides a strategy whereby the GEIA-STD-927 Schema can be transitioned to practical application for an existing DoD program. The Schema Tailoring Guidelines address identifying data sources and the logical concepts contained within those sources; crea

26、ting a form of Logical Data Model to support each data source; identifying areas where the GEIA-STD-927 Schema is relevant and performing the analysis necessary to map the data sources to the Schema; creating an Extended Abstract Model that takes into account all of the concepts represented by the i

27、ndividual data sources; and modifying the form of the GEIA-STD-927 Schema as necessary to facilitate the implementation of the Schema with a practical software application. 3 Data Modeling Guidelines A good data model should have the following attributes: completeness; non-redundancy; data reusabili

28、ty; stability; flexibility; simplicity; elegance; extensibility; effectiveness as a communication tool. This section provides some guidance in achieving the above attributes, but it ultimately is up to the modeler to ensure that they are met. The examples that appear in this section were chosen to i

29、llustrate the points that precede them. Some of these examples may, for simplicity, violate other points in the document. Therefore, an understanding of this entire section, an understanding of decisions made during analysis (which is captured in the analysis documentation form) and familiarity with

30、 the existing schema are all necessary to achieve a proper modeling style. 3 GEIA-HB-927 Conventions Used in this Section EXPRESS code is displayed in the Courier font. Ellipses (.) are used when portions of an EXPRESS definition are irrelevant to the example and therefore omitted. Intended Audience

31、 This section is intended primarily for use by data modelers who are involved in developing or tailoring the GEIA-STD-927 top level schema. It may also be of interest to system architects, software developers and project managers. Familiarity with the fundamentals of data modeling and an understandi

32、ng of the EXPRESS modeling language are assumed. 3.1 Scope This section establishes modeling conventions and guidelines to be followed during the development of the GEIA-STD-927 top level schema. The following is within the scope of this document: Modeling rules, conventions and guidelines for the G

33、EIA-STD-927 top level schema. The following are outside the scope of this document: An introduction to information modeling; An introduction to the EXPRESS modeling language. 3.2 General Requirements 3.2.1 Perspective of the Schema The perspective of the schema shall be the specification of the stru

34、cture of data needed to represent useful and practical concepts within the GEIA-STD-927 domain, not a description of the structure of the real world. EXAMPLE 1: Suppose we wish to model the concepts of “person,“ “male“ and “female.“ We can write the following in EXPRESS: ENTITY person ABSTRACT SUPER

35、TYPE OF (ONEOF(male, female); . END_ENTITY; ENTITY male SUBTYPE OF (person); . END_ENTITY; ENTITY female SUBTYPE OF (person); . END_ENTITY; By declaring person to be an abstract supertype, we enforce the rule that every person is either male or female. This is true in the real world, but there may b

36、e cases where we do not know or care about a persons sex, but still want to store information about that person in the GEIA-STD-927 data store. The above declarations would make that impossible. So it is better to remove the “ABSTRACT“ keyword from the person entity declaration. 4 GEIA-HB-927 EXAMPL

37、E 2: The schema for a chemical database might consist of ATOM and MOLECULAR_BOND entity data types. We know from physics that atoms actually are made up of subatomic particles (electrons, protons, neutrons, etc.). However, for the purpose of a chemical database, it may be more useful to represent me

38、thane as four hydrogen atoms bonded to one carbon atom, rather than a configuration of m electrons, n neutrons and p protons. 3.2.2 Understandability to Domain Experts The schema should be understandable to domain experts. Terms from information modeling, computer science, information technology, da

39、tabase technology, etc., should be avoided. NOTE: This does not rule out the need to brief the domain experts on the EXPRESS modeling language or provide them with human or written guidance on how to read the schema. 3.2.3 Generality The entities in the schema should be generic enough so the schema

40、context is as broad as possible while still meeting requirements. However, they should not be so generic as to be meaningless. EXAMPLE 1: A person may be a child of another person, a spouse of another person, an employee of another person, the teacher of another person, etc. These relationships coul

41、d all be made subtypes of a single relationship called “person_person_relationship“; however, such a generalization would not be useful because person_person_relationship carries no meaning by itself. A rule shall be embedded in the schema if and only if one of the following holds: The rule is neces

42、sary to ensure the integrity or meaningfulness of the data; There is some other clear benefit to having the rule and the rule is likely to remain in force throughout the life of the GEIA-STD-927 schema. NOTE 1: Another way of thinking about this is: Can you imagine a possible world in which this rul

43、e does not hold? If you can, it may be better not to embed it in the schema. EXAMPLE 2: The rule “An employee must have a home phone number“ probably does not meet the first condition. One might think that it meets the second criterion, but some employees may not have a true home phone number only a

44、 cell phone number. So it may be best to leave this rule out of the schema and enforce it through some other means. NOTE 2: There is no specified design life for the GEIA-STD-927 program and its schema. NOTE 3: Business rules for a particular organization may be stored as data (in which case a meta-

45、business rule schema is needed) or embedded in the software that makes updates to a GEIA-STD-927 data store. 3.3 The Six Principles The following six principles shall be observed. NOTE 1: These principles are adapted from “Developing high quality data models.“ The reader should consult that document

46、 for details, explanations, and additional examples. 5 GEIA-HB-927 Principle 1: Candidate attributes should be analyzed to determine whether they represent relationships to other entity data types. EXAMPLE 1: Consider the following EXPRESS code: ENTITY engine; vehicle_id: OPTIONAL STRING; (* the ide

47、ntifier of the vehicle on which the engine is currently mounted, or null if it is not mounted to a vehicle *) . END_ENTITY; ENTITY vehicle; vehicle_id: STRING; (* the unique identifier of the vehicle *) . UNIQUE UR1: vehicle_id; END_ENTITY; There is a relationship between engine and vehicle implicit

48、 in the shared attribute vehicle_id. The vehicle_id attribute should be removed from engine and replaced with a link. The following EXPRESS code represents this concept: ENTITY engine; mounted_on: OPTIONAL vehicle; (* the vehicle on which the engine is currently mounted, or null if it is not mounted

49、 to a vehicle *) . END_ENTITY; ENTITY vehicle; vehicle_id: STRING; (* the unique identifier of the vehicle *) . UNIQUE UR1: vehicle_id; END_ENTITY; EXAMPLE 2: A product has a price attribute, which is represented in EXPRESS as follows: ENTITY product; product_code: STRING; price: currency_amount; . END_ENTITY; However, a products price may change over time and there may be different prices for differe