GEIA-HB-927-2007 Implementation Guide for Common Data Schema for Complex Systems (Formerly TechAmerica GEIA-HB-927)《复杂系统共同数据模式执行指南》.pdf

《GEIA-HB-927-2007 Implementation Guide for Common Data Schema for Complex Systems (Formerly TechAmerica GEIA-HB-927)《复杂系统共同数据模式执行指南》.pdf》由会员分享，可在线阅读，更多相关《GEIA-HB-927-2007 Implementation Guide for Common Data Schema for Complex Systems (Formerly TechAmerica GEIA-HB-927)《复杂系统共同数据模式执行指南》.pdf（136页珍藏版）》请在麦多课文档分享上搜索。

1、 GEIA ENGINEERING BULLETIN GEIA-HB-927 Implementation Guide for Common Data Schema for omplex Systems CGEIA-HB-927 July 2007 GOVERNMENT ELECTRONICS AND INFORMATION TECHNOLOGY ASSOCIATION A Sector of the Electronic Industries Alliance Copyright Government Electronics provide a way for stakeholders to

2、 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 individual

3、 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 explicit

4、ly 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 the data m

5、odeler 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 guidelines for

6、 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 Data Modelin

7、g 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 present g

8、eneral 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 Copyright Government Electronics creating a form of Logical Data Model to support each data s

9、ource; 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 individual data sources; and modifying the form of the GE

10、IA-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 reusability; stability; flexibility; simplicity; elegance; extens

11、ibility; 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 illustrate the points that precede them. Some of these ex

12、amples 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 the existing schema are all necessary to achieve a prop

13、er modeling style. 3 Copyright Government Electronics 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 structure of data needed to represent useful and practical concepts within

14、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 SUPERTYPE OF (ONEOF(male, female); . END_ENTITY; ENTITY male SUBTYPE OF (per

15、son); . 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 be cases where we do not know or care about a persons sex, but still wan

16、t 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 Copyright Government Electronics however, such a generalization would not be useful becau

17、se 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 necessary 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 re

18、main 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 rule 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“

19、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 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 speci

20、fied 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-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 follo

21、wing six principles shall be observed. NOTE 1: These principles are adapted from “Developing high quality data models.“ The reader should consult that document for details, explanations, and additional examples. 5 Copyright Government Electronics vehicle_id: OPTIONAL STRING; (* the identifier of the

22、 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 in the shared

23、 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 to a vehicle

24、*) . 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; Ho

25、wever, a products price may change over time and there may be different prices for different markets, so the following EXPRESS code would be a better representation of this concept: ENTITY product; product_code: STRING; . END_ENTITY; ENTITY product_price; the_product: product; the_market_segment: ma

26、rket_segment; price: currency_amount; END_ENTITY; 6 Copyright Government Electronics The entities a, b, . share attributes, rules or other characteristics that are captured in the schema; There may be situations where it is known that an object is one of a or b, . but it is not known which one it is

27、. EXAMPLE: It may be known that an object is a person, but not whether the person is a male or female. Multiple inheritance should be used sparingly. Uses of multiple inheritance will be scrutinized carefully during validation and verification reviews of the schema. 3.6 Identity EXPRESS considers ea

28、ch instance of an EDT to have an “identity“ separate from all other instances. Two separately created instances retain separate identities even if all their attributes have identical values. This feature of the language, while quite powerful, can be confusing to people who are reading or implementin

29、g the schema. Therefore, it is best to avoid the situation where two instances of an EDT: have the same values for all attributes; are not interchangeable. 8 Copyright Government Electronics NOTE 1: It is not clear if it will be necessary to use constants for this purpose. Giving a name to an arbitr

30、ary-appearing value that has some conceptual significance and never changes; EXAMPLE: Mathematical constants such as e and would qualify under this case. Physical constants might qualify if it is strongly believed that they will not change during the life cycle of the GEIA-STD-927 schema. NOTE 2: Wh

31、ile physical constants conceptually never change, the values may be revised due to improvements in mans ability to measure them, or other scientific advances. Giving a name to a value that appears more than once in the schema. Since constants are conceptually values that never change, they should no

32、t be used for values that change infrequently, but do change. They should also not be used for values that do not change for a given set of users but may be different for other sets of users, since many different groups of users may be operating off of the same version of the GEIA-STD-927 schema. 9

33、Copyright Government Electronics therefore, use of a constant in an exchange context based on ISO 10303-21 requires that both sender and receiver have copies of the schema in which the constant is defined. 3.8.3 Named Types Named types shall be used for the following purposes: 1. Defining SELECT and

34、 ENUMERATION types; NOTE 1: The EXPRESS language requires that SELECT and ENUMERATION types be defined as named types. 2. Giving names to collection types where such collections have conceptual significance and appear in more than one place in the schema; EXAMPLE 1: A real-valued three-dimensional v

35、ector may be defined in EXPRESS as follows: TYPE real_vector_3d = ARRAY 1:3 OF REAL; END_TYPE; 3. Giving names to simple types where such names have conceptual significance and appear in more than one place in the schema; EXAMPLE 2: Assume that several attributes of the same or different entities ar

36、e length measures and are defined to be real numbers, as shown below: ENTITY pipe; diameter: REAL; length: REAL; END_ENTITY; ENTITY duct; width: REAL; height: REAL; length: REAL; END_ENTITY; Then those attributes should instead point to a defined type for length measure, as shown below. TYPE length_

37、measure = REAL; END_TYPE; ENTITY pipe; diameter: length_measure; length: length_measure; END_ENTITY; ENTITY duct; width: length_measure; height: length_measure; length: length_measure; END_ENTITY; 10 Copyright Government Electronics EXAMPLE 3: Assume that several attributes of the same or different

38、entities are counts and are defined to be positive integers, as shown below. ENTITY physical_object; number_of_cycles: INTEGER; WHERE WR1: number_of_cycles = 0; END_ENTITY; ENTITY vehicle; number_of_seats: INTEGER; WHERE WR1: number_of_seats = 0; END_ENTITY; Then those attributes should instead poin

39、t to a defined type for positive integer, as shown below. TYPE positive_integer = INTEGER; WHERE WR1: SELF = 0; END_TYPE; ENTITY physical_object; number_of_cycles: positive_integer; END_ENTITY; ENTITY vehicle; number_of_seats: positive_integer; END_ENTITY; 5. Giving names to subsets of other named t

40、ypes where such subsets have conceptual significance and appear in more than one place in the schema. EXAMPLE 4: Suppose that the type positive_real is already defined as follows: TYPE positive_real = REAL; WHERE WR1: SELF = 0; END_TYPE; Assume that several attributes of the same or different entiti

41、es are distance values and point to type positive_real. Then those attributes should point to the following defined type for distance instead: TYPE distance = positive_real; END_TYPE; 11 Copyright Government Electronics . END_ENTITY; ENTITY b; . END_ENTITY; TYPE sel = SELECT(a,b); The declaration fo

42、r sel is roughly equivalent to: ENTITY sel; ABSTRACT SUPERTYPE OF (ONEOF(a,b); END_ENTITY; One major difference between SELECT types and supertypes is that one cannot declare subtypes of SELECT types. SELECT types should be used sparingly. A SELECT type may be appropriate if: 1. The members of the S

43、ELECT type already appear in separate subtype/supertype hierarchies, and changing the SELECT type to an abstract supertype would result in multiple inheritance; 2. The members of the select type do not share any conceptual similarities worthy of putting them into a subtype/supertype hierarchy; 12 Co

44、pyright Government Electronics END_TYPE; ENTITY documentation; item_documented: documentable_item; documentation: STRING; END_ENTITY; The entities system, design, shape_aspect, tolerance and process probably do not have enough in common to warrant making them subtypes of a common supertype. 3. Some

45、members of the select type are not EDTs. NOTE: EXPRESS requires that all members of a subtype/supertype hierarchy be EDTs. 3.8.5 Subtypes and Supertypes A supertype X shall not be declared as abstract unless every instance at X falls into at least one known subtype of X. Abstract supertypes shall no

46、t be used to enforce business rules. EXAMPLE: See the example in Clause 3.2.1. Care should be taken to properly specify the constraints on the subtypes. NOTE: The ONEOF operator is often overlooked. 3.8.6 Simple Datatypes Simple datatypes shall not contain structured information, except as specifica

47、lly called for in the data architecture. EXAMPLE 1: The following is wrong: person; name: STRING; (* should be in the format last name, comma, space, first name, space, middle name *) END_ENTITY; Instead, the attribute name should be broken down into its constituents. ENTITY person; last_name: STRIN

48、G; first_name: STRING; middle_name: OPTIONAL STRING; END_ENTITY; EXAMPLE 2: The data architecture may specify that dates are to be represented as strings in accordance with ISO 8601 1. 13 Copyright Government Electronics c,p: REAL; END_ENTITY; Instead, write: ENTITY ent; c: REAL; p: REAL; END_ENTITY

49、; 3.8.9 Functions and Procedures A function or procedure should be defined whenever the same code, or code that is conceptually similar appears in more than one place in the schema. Function calls should also be substituted for subexpressions in complex nested expressions. NOTE: In traditional EXPRESS usage (e.g., in the Application Interpreted Model of a typical STEP Application Protocol), very complex nested expressions occur abundantly in WHERE clauses. 3.8.10 Rules EXPRESS has two kinds of rules: local rules and global rules. Lo