This International Standard specifies rules and guidelines for constructing data definitions. This International Standard describes only the semantic structure of data definitions and does not prescribe the format of definitions. These definition rules and guidelines apply to data as well as to the writing of definitions of other types of data structures, such as entity types, entities, relationships, attributes, object types (or classes), objects, segments, composite code entries, and messages. The definition rules and guidelines in this International Standard do not always apply to definitions of terms in vocabularies and language dictionaries. There is a difference between the rules that apply to language dictionaries and the rules that apply to data dictionaries. For example, a term in a language dictionary may have multiple definitions, while a definition in a data dictionary is unique in the dictionary and has only one meaning. Many data definitions contain terms that themselves need to be defined (such as "charge", "allowance", "delivery", etc.). Some of these terms may have different definitions in different industries. Therefore, most data dictionaries need to be accompanied by a glossary of terms for definitions. Indicate the field of use of each term in the glossary. GB/T 18391.4-2001 Information technology Specification and standardization of data elements Part 4: Rules and guidelines for writing data definitions GB/T18391.4-2001 Standard download decompression password: www.bzxz.net
This standard specifies the rules and guidelines for building data definitions. This standard only introduces the semantic structure of data definitions and does not specify the format of definitions. These definition rules and guidelines apply to data and also to the definition of other types of data structures, such as entity types, entities, relationships, attributes, object types (or classes), objects, segments, combined code entries and messages. The definition rules and guidelines in this standard do not always apply to the definitions of terms in vocabularies and language dictionaries. There is a difference between the rules that apply to language dictionaries and the rules that apply to data dictionaries. For example, a term in a language dictionary may have multiple definitions, while a definition in a data dictionary is unique in the dictionary and has only one meaning. Many data definitions contain terms that need to be defined themselves (such as "charge", "allowance", "delivery", etc.). Some of these terms may have different definitions in different industries. Therefore, most data dictionaries need to be accompanied by a glossary of terms for definition. In the glossary, indicate the field of use of each term.

ICS35.040
National Standard of the People's Republic of China
GB/T18391.4—-2001
idtISO/1EC11179-4:1995
Information technology
Specification and standardization of data elements--Part 4: Rules and guidelines for the formulation of data definitions2001-07-16Promulgated
People's Republic of China
General Administration of Quality Supervision, Inspection and Quarantine
2002-03-01Implementation
GB/T 18391.4—2001
ISO/IECForeword
Cited Standards
Summary of Data Definition Rules and Guidelines
Appendix A (Informative Appendix)
References
GB/T18391.4—2001
This standard is equivalent to the international standard ISO/IEC11179-4:1995 "Information technology part: Rules and guidelines for the preparation of data definitions". Specification and standardization of data elements
GB/T18391, under the general title "Specification and standardization of information technology data elements", includes the following parts: - Part 1, Framework for specification and standardization of data elements; Part 2: Classification of data elements;
Part 3: Basic attributes of data elements;
- Part 4: Rules and guidelines for the preparation of data definitions; - Part 5: Principles for naming and identification of data elements; Part 6: Registration of data elements.
Appendix A of this standard is a prompt appendix.
This standard is proposed and managed by China Standard Research Center. The drafting unit of this standard is China Standard Research Center. The main drafters of this standard are Liu Zhiting, Xing Liqiang, Feng Wei and Li Xiaolin. Chapter 4
GB/T 18391.4—2001
ISO/IEC Foreword
The International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) are specialized standardization organizations worldwide. National organizations that are members of ISO or IEC participate in the development of international standards through various technical committees. Technical committees are formed by related organizations that participate in technical activities in various professional fields. ISO and IEC technical committees cooperate in areas of common interest. Official and non-official international organizations that have ties with ISO and IEC may also participate in this work. In the field of information technology, ISO and IEC have established a joint technical committee, namely ISO/IEC JTC1. Draft international standards adopted by the joint technical committee are submitted to national groups for voting. The publication of an international standard requires at least 75% of the national groups participating in the voting to vote in favor.
International Standard ISO/IEC11179-4 was drafted by the Data Management and Exchange Subcommittee (SC32) of the Joint Technical Committee for Information Technology (ISO/IECJTC1). 1SO/IEC11179, under the general title "Information Technology - Specification and Standardization of Data Elements", includes the following parts: Part 1: Framework for Specification and Standardization of Data Elements; - Part 2: Classification of Data Elements;
- Part 3: Basic Attributes of Data Elements; - Part 4: Rules and Guidelines for Writing Data Definitions; - Part 5: Principles for Naming and Identifying Data Elements; - Part 6: Registration of Data Elements.
Appendix A of this standard is for reference only.
GB/T18391.4—2001
The purpose of data element definition is to define the meaning of data elements. In order to ensure quality and consistency, this standard proposes rules and guidelines for standardizing the structure of data element definitions.
Accurate and clear data element definition is one of the most important factors to ensure data sharing. When two or more parties exchange data, it is crucial that the meaning of the data is accurately consistent. One of the main carriers for transmitting the meaning of data is the data element definition. Therefore, each data element must have a standardized definition that can be clearly understood by each user. Unstandardized data element definitions will cause misunderstandings and unclear meanings, and often prevent people from communicating successfully. This standard consists of two parts: rules and guidelines. These rules and guidelines apply to the preparation of data element definitions used in information processing systems and information exchange. To comply with the standard, rules are mandatory and verifiable: guidelines are principles to be followed. For rules, objective test criteria can be formulated. Conformity with guidelines can be evaluated by reasonableness judgment. The names of data elements in this standard do not follow a special syntax. "Data element" means "data element type", and short terms are more convenient to use.
1 Scope
National Standard of the People's Republic of China
Information technology-Specification and standardization of data elements--Part 4: Rules and guidelines for the formulation of data definitionsGB/T18391.4—2001
idtISO/IEC11179-4:1995
This standard specifies the rules and guidelines for constructing data element definitions. This standard only introduces the semantic structure of data element definitions and does not specify the format of the definitions.
These definition rules and guidelines apply to data elements and also to the definition of other types of data structures, such as entity types, entities, relations, attributes, object types (or classes), objects, segments, combined code entries and messages. The definition rules and guidelines in this standard do not always apply to the definitions of terms in vocabularies and language dictionaries. There is a difference between the rules applicable to language dictionaries and the rules applicable to data dictionaries. For example, a term in a language dictionary may have multiple definitions, while a definition in a data dictionary is unique in the dictionary and has only one meaning. Many data element definitions contain terms that themselves need to be defined (such as charge, allowance, delivery, etc.). Some of these terms may have different definitions in different industries. Therefore, most data dictionaries need to be accompanied by a glossary of terms for definitions. Indicate the field of use of each term in the glossary. 2 Referenced standards
The provisions contained in the following standards constitute the provisions of this standard through reference in this standard. At the time of publication of this standard, the versions shown are valid. All standards will The parties using this standard should explore the possibility of using the latest versions of the following standards. GB/T10112-1999 Principles and methods of terminology work (neqISO704:1997) GB/T15237.1-2000 Vocabulary of terminology work Part 1: Theory and application (eqvISO1087-12000) GB/T5271.4-2000 Information technology vocabulary Part 4: Organization of data (egvISO/IEC2382-4:1987) GB/T14805-1993 For administration, commerce and transport Application-level syntax rules for electronic data interchange in the industry (idtISO97351988) GB/T1.6-1997 Guidelines for standardization work Unit 1: Rules for drafting and expressing standards Part 6: Provisions for writing terminology standards (neqISO10241:1992)
GB/T18391.3—20011
Information technology Specification and standardization of data elements Part 3: Basic attributes of data elements (idtISO/IEC11179-3:1994)
ANSIX3.172-1990 , American National Standard Dictionary of Information Systems (ANDIS) 3 Definitions
This standard applies the following definitions.
3.1 Attribute attribute
A characteristic of an object or entity.
Approved by the General Administration of Quality Supervision, Inspection and Quarantine of the People's Republic of China on July 16, 2001 and implemented on March 1, 2002
GB/T18391.4—2001
3.2 Concept concept
An idea abstracted from the common characteristics of a group of objects. 3.3 data data
A formal representation of facts, concepts and instructions suitable for communication, interpretation or processing by manual or automatic means. 3.4 data dictionary datadictionary
A database for data and other data structures: a database for storing metadata (ANSIX 3.172-1990). See data element dictionary.
3.5 data element dataelement
A data unit that is defined, identified, represented and allowed values ​​by a set of attributes. 3.6 data element dictionary data elementdictionary An information resource that lists and defines all relevant data elements. It is synonymous with data dictionary. NOTE: Data element dictionaries can have different levels, for example, ISO/IEC committee level, international association level, industry sector level, company level, application system level. 3.7 definition definition
A word or phrase that expresses the essential characteristics of a person or thing, or a class of people or things: a statement of the meaning of a word or phrase that answers the question "What is X?" or "What does X belong to?" 【Webster's New World English Dictionary, 3rd edition, 1986]. 3.8 Domain domain
A set of possible data values ​​for an attribute (ANSIX3.172-1990). 3.9 Name name
The basic way people identify things and concepts. Summary of data definition rules and guidelines
: For the convenience of users, the rules and guidelines listed in this chapter do not contain explanations. The purpose is to make this standard easy to use based on understanding. Chapter 5 gives rules and guidelines with explanations and examples to ensure that people understand their exact meaning. 4.1 Rules
Data definitions should:
a) be unique (in any data dictionary where this definition appears); b) be stated in singular form;
c) state what the concept is, rather than what it is not; d) be stated in descriptive phrases or sentences; e) only use abbreviations that are generally understood by people; f) not add different data element definitions or refer to lower-level concepts in the description. 4.2 Guidelines
Data definitions should:
a) state the basic meaning of the concept;
b) be accurate and unambiguous;
c) be concise;
d) be able to stand alone;
e) not include theoretical explanations, functional descriptions, scope information or procedural information in the description;
f) avoid interdependencies;
g) related definitions use the same terminology and consistent logical structure. 5 Requirements
5.1 Prerequisites
GB/T18391.4—2001
Data elements exist and are used for specific purposes. Different uses will require different forms of expression of certain rules and guidelines. For example, different relevant environments usually require different levels of characterization of data element definitions. 5.3a) lists examples where different definitions require different levels of characterization. 5.3a) "State the basic meaning of the concept" depends on the relevant environment. The main characteristics necessary to express the basic meaning of a particular definition vary according to the level of generalization or specialization of the data element. Such main characteristics should take into account the association of object classes, properties and modifiers related to the concept being analyzed. The main and basic characteristics of a definition such as "airport" in the commercial air transportation industry may be specific, but they are also appropriate as a general definition in different relevant contexts. For a discussion of the relationship between concepts in different relevant contexts and how to use characteristics to distinguish between different concepts, see ISO/IEC 10112. Definitions should be written so that they are easy to understand for users and data sharers.
5.2 Rules
In order to make the rules for the structure of normalized data element definitions easy to understand, the following are given with explanations and examples. Each rule is followed by a brief explanation of its meaning. After the explanation, there are some examples. Each explanation is accompanied by good examples and, where necessary, common bad examples to illustrate the writing errors of the definition. To show the difference between good examples and bad examples, the examples are followed by explanations of the reasons.
Data definitions should:
a) be unique (in any data dictionary where this definition appears). Note: Each definition must be distinguished from any other definition (in the dictionary) to ensure specificity. One or more characteristics expressed in the definition must distinguish the concept being defined from other concepts. Example: "Shipping Date" "Receipt Date" 1) Good definition:
"Shipping Date" - the date the supplier sends the goods. "Receipt Date" - the date the consignee receives the goods. 2) Bad definition:
"Shipping Date" - the date the goods are delivered. "Receipt Date" - the date the goods are delivered. Reason: The definition "Date of Delivery of Goods" cannot be used for both "Shipping Date" and "Receipt Date". Each definition must be different.
b) Be described in singular form.
Note: The concept expressed in the data definition must be expressed in singular form (except when the concept itself is plural). Example: "article number"
1) Good definition:
A reference number that identifies an article. (A reference number that identifies an article.) 2) Bad definition:
A reference number that identifies articles. (Reference number identifying articles.) Reason: The bad definition uses the plural "articles", which is unclear because it can be understood that an "article number" refers to multiple articles. c) It is necessary to explain what the concept is, rather than just stating what it is not. Explanation: When writing a definition, simply stating what the concept is not does not provide a unique definition of the concept. Example: "Total freight"
1) Good definition:
The total amount of expenses incurred by the shipper to transport the goods from one place to another. 2) Bad definition:
All expenses unrelated to packaging, documents provided, loading, unloading and insurance. Reason: The bad definition does not clearly state the meaning of this data. 3
GB/T18391.4—2001
d) Describe in a descriptive phrase or sentence (in most languages). Note: (in most languages) A ​​phrase must be used to form an accurate definition that includes the essential characteristics of the concept. One or more synonyms cannot be simply stated, nor can the names be simply repeated in a different order. If a descriptive phrase is not sufficient, a complete, grammatically correct sentence should be used.
Example: "Agent Name"
1) Good definition:
The name of the party authorized to represent another party. 2) Bad definition:
Representative.
Reason: "Representative" is a synonym for the name of this data element and is not suitable for use as a definition. e) Only abbreviations that are generally understood by people can be used. Note: The understanding of the meaning of abbreviations, including abbreviations and initials, is usually limited to specific environments. The same abbreviation may cause misunderstanding or confusion in different environments. Therefore, to avoid ambiguity, the full name should be used in the definition instead of abbreviations. If the abbreviation is a commonly understood word, such as "ie" and "eg", or the abbreviation is easier to understand than the full name of the compound word and it has been adopted as a word in itself, such as "radar" standing for "radio detecting and ranging", such abbreviation can be used in the definition as an exception. All abbreviations must be stated the first time they appear. Example 1: "tidal height"
1) Good definition:
The vertical distance from mean sea level (MSL) to a specific tide level. 2) Bad definition:
The vertical distance from MSL to a specific tide level. The vertical distance from a horizontal plane. Reason: The bad definition is unclear because the abbreviation MSL is not widely understood and some users may need to refer to other sources to determine its meaning. Without a full name, the term may be difficult to find or not found at all in a glossary. Example 2 "density measurement unit"
1) Good definition:
The unit used to measure the density of a substance, expressed in mass per unit volume (mpu) (for example, pounds per cubic foot; grams per cubic meter).
2) Bad definition:
The unit used to measure the density of a substance, expressed in mpu (for example, pounds per cubic foot, kilograms per cubic meter). Reason: mpuAbbreviations that are not commonly used may not be understood by some users. The abbreviations should be written in full. f) Do not include different data element definitions or references to lower-level concepts in the statement. Note: Secondary data element definitions or related concepts should not appear in the primary data element definition. Definitions of terms should be written using the vocabulary of related terms. If secondary data element definitions are required, they can be used as a note, attached to the end of the main definition text or as a separate entry in the dictionary. Related definitions can be obtained through relationship attributes (e.g., cross-references). Example 1: "Sample Type Code"
1) Good definition:
A code that identifies the type of sample.
2) Bad definition;
A code that identifies the type of sample collected. A sample is a small sample collected for a test. It can be used as an actual sample for a test or as a surrogate sample for quality control. A quality control sample is a surrogate sample used to check the results of the actual sample. Reason: The bad definition embeds two definitions that are not related to the current definition. They are the definition of "sample" and the definition of "quality control sample".
Example 2: "Issuing bank documentary credit number" 1) Good definition:
GB/T18391.4—2001
The number assigned to a documentary credit by an issuing bank. 2) Bad definition:
The number assigned to a documentary credit by an issuing bank. A documentary credit is a document in which a bank states that it has issued a documentary credit, against which a beneficiary can be paid, accepted or negotiated on certain terms and conditions without the need to produce security documents and other items such as bills of exchange. Reason: The bad definition contains another concept definition, which is the glossary of the recipient. 5.3 Guidelines (Guiding Principles)
Data definitions should:
a) State the basic meaning of the concept.
Explanation: All basic characteristics that describe the concept should appear in the definition of the corresponding characteristic level of the relevant environment. Non-basic characteristics should be avoided. Whether the level needs to be subdivided depends on the requirements of the system users and the environment. Example 1: "Consignment loading number" (intended context: any form of transport) 1) Good definition:
Specifies the loading order of a consignment in a transport vehicle or transport equipment. 2) Bad definition:
Specifies the loading order of a consignment on a truck. Reason: In the intended context, consignments can be transported by various modes, such as trucks, ships or freight trains. Consignments are not limited to truck transportation.
Example 2: "Invoice total"
1) Good definition:
The total of the charges on the invoice.
2) Bad definition:
The total of all charges listed on the invoice, taking into account deductions such as discounts and rebates on the one hand and insurance, transportation, handling and other charges on the other hand. Reason: Bad definitions include content that is irrelevant to the subject. b) The definition is not comprehensive.
Explanation: The exact meaning and explanation of the concept being defined should be clear in the definition. The definition should be clear enough so that there is only one interpretation.
Example: "Date of Receipt"
1) Good definition:
The date on which the consignee receives the goods.
2) Bad definition:
The date on which the specific goods are delivered.
Reason: The bad definition does not specify what determines "delivery of goods". "Delivery of goods" can be understood as the act of unloading the product at the intended destination, or it can be understood as the location where the customer actually receives the product. It is possible that the customer does not receive the product that has been unloaded at the yard at all, or the customer may receive it several days after the product is unloaded at the yard. c) Concise.
Explanation: The definition should be concise and easy to understand, and should avoid the use of irrelevant qualifying phrases such as "for the purpose of this data dictionary" and "the term to be described is".
Example: "Character set name"
1) Good definition:
The name given to a set of phonetic or ideographic symbols, and data is encoded with these symbols. 5
2) Bad definition:
GB/T18391.4—2001
Name given to a group of phonetic or ideographic symbols, data is encoded with these symbols. The purpose of this data dictionary, as used elsewhere, is the ability of system hardware and software to process encoded data in multiple versions. Reason: In the bad definition, all phrases after "data is encoded with these symbols" are irrelevant restrictive phrases. d) Can stand alone.
Explanation: The meaning of the concept can be reflected in the definition itself. To understand the meaning of the definition, no additional explanation or citation is required. Example: "The name of the city where the school is located"
1) Good definition:
The name of the city where the school is located. bZxz.net
2) Bad definition:
See "School location".
Reason: A bad definition cannot stand alone, it needs the help of another definition (school location) to understand the meaning of this definition. e) Do not include theoretical explanations, functional specifications, scope information, or procedural information in the statement. Note: Although they are usually necessary, such statements should not be included in the definition itself because they contain information that is irrelevant to the meaning of the definition. If they are considered useful, such statements can be listed as different data element attributes (GB/T 18391.3). They are used to explain the listed definition and should not be part of the definition (for example, if a data element uses miles instead of kilometers, the reason should not be explained in the definition).
Functional statements such as "this data element should not be used for" should not appear in the definition. Procedural comments, such as "this data element is used in conjunction with data element XXX", should not appear in the definition, but should be used as specified in GB/T 18391.3. "Related data reference" and "Relationship type" should be used. Example: "Data field label"
1) Good definition:
Data field label for index, subject call table, query, database, etc. 2) Bad definitions:
Data field identifiers for indexes, thesauri, queries, databases, etc. Data field identifiers are used for information units such as abstracts, columns in tables, etc.
Reason: Bad definitions contain statements of function. Statements starting with "Data field identifiers are used for . . ." must be removed from the definition. If such statements are necessary, they should be placed in other attributes. E) Avoid interdependencies.
Explanation: Two definitions should not define themselves in terms of each other. Nor should a definition use the definition of another concept as its own definition. This would result in the definition of one concept being appended to the other, or vice versa, the definition of another concept being appended to the one already given.
Example: Two data elements with bad definitions 1) "Employee ID number" - a number assigned to each employee. 2) "Employee" - a person corresponding to an employee ID number. Reason: Each definition refers to the other definition in its meaning. Each definition does not specify the meaning. g) Related definitions use the same terminology and a consistent logical structure. Note: For similar or related definitions, the same terms and syntax should be used. Example: The example in Rule 5.2a) above also illustrates this point. Both definitions are related to related concepts and therefore should have the same logical structure and similar terms.
1) Shipment date - the date on which the supplier sends the goods. 2) Receipt date - the date on which the consignee receives the goods. Reason: Using the same terms and syntax facilitates understanding. Otherwise, the user will not know whether the use of synonymous terms and changed syntax means something different.
ISO Standards Manual 10, Data Processing -
GB/T18391.4—2001
Appendix A
(Indicative Appendix)
References
- Glossary, 1982
TRADE/WP.4/R.765/Add.1, United Nations Economic and Social Council, 1991.7.3030303 Guidance (Guiding Principles)
Data definitions should:
a) State the basic meaning of the concept.
Explanation: All basic characteristics that describe the concept should appear in the definition of the corresponding characteristic level for the relevant environment. Non-basic characteristics should be avoided. Whether to subdivide the level depends on the requirements of the system users and the environment. Example 1: "Consignment Loading Sequence Number" (Intended Environment: Any Mode of Transport) 1) Good definition:
Indicates the loading sequence number of a consignment in a transport vehicle or transport equipment. 2) Bad definition:
Indicates the loading sequence number of a consignment on a truck. Reason: In the intended environment, a consignment can be transported by various modes, such as trucks, ships, or freight trains. Consignments are not limited to truck transportation.
Example 2: "Invoice Total"
1) Good definition:
The total of the charges on the invoice.
2) Bad definition:
The total of all charges listed on the invoice, minus amounts such as discounts and rebates on the one hand, and insurance, transportation, handling and other charges on the other hand. Reason: Bad definitions include content that is irrelevant to the subject. b) Definitions are not comprehensive.
Explanation: The exact meaning and interpretation of the concept being defined should be clear in the definition. Definitions should be clear enough to allow only one interpretation.
Example: "Date of receipt"
1) Good definition:
The date on which the consignee receives the goods.
2) Bad definition:
The date on which the specific goods are delivered.
Reason: Bad definitions do not specify what determines "delivery of goods". "Delivery of goods" can be understood as the act of unloading the product at the intended destination, or as the location where the customer actually receives the product. It is possible that the customer never receives the product that has been unloaded at the yard, or that the customer receives it a few days after the product has been unloaded at the yard. c) Concise.
Explanation: The definition should be concise and easy to understand, and should avoid using irrelevant qualifying phrases such as "for the purpose of this data dictionary" and "the term to be described is".
Example: "Character set name"
1) Good definition:
The name given to a set of phonetic or ideographic symbols, and data is encoded with these symbols. 5
2) Bad definition:
GB/T18391.4—2001
The name given to a set of phonetic or ideographic symbols, and data is encoded with these symbols. The purpose of this data dictionary, as used elsewhere, is the ability of system hardware and software to process encoded data in multiple versions. Reason: In the bad definition, all phrases after "the data is encoded with these symbols" are irrelevant qualifying phrases. d) Can stand alone.
Explanation: The meaning of the concept can be reflected in the definition itself. To understand the meaning of the definition, no additional explanation or citation is needed. Example: "The name of the city where the school is located"
1) Good definition:
The name of the city where the school is located.
2) Bad definition:
See "School location".
Reason: A bad definition cannot stand alone, it needs the help of another definition (school location) to understand the meaning of this definition. e) Do not add theoretical explanations, functional descriptions, scope information or procedural information to the statement. Explanation: Although they are usually necessary, such statements should not be included in the definition itself because they contain information that is irrelevant to the meaning of the definition. If they are considered useful, such statements can be listed as different data element attributes (GB/T18391.3). They are used to explain the listed definition and should not be part of the definition (for example: if a data element uses miles instead of kilometers, the reason should not be explained in the definition).
Functional statements such as "this data element should not be used for" should not appear in the definition. Procedural comments, such as "this data element is used together with data element XXX", should not appear in the definition. Instead, "related data reference" and "relationship type" should be used as specified in GB/T18391.3. Example: "data field tag"
1) Good definition:
Data field tag for index, subject table, query, database, etc. 2) Bad definition:
Data field tag for index, subject table, query, database, etc. Data field tag is used for information units such as abstracts and columns in tables.
Reason: Bad definitions contain statements of function. Statements starting with "data field tag is used for .." must be removed from the definition. If such a statement is necessary, it should be placed in other attributes. E) Avoid mutual dependence.
Explanation: Two definitions should not define themselves based on each other. A definition should not use the definition of another concept as its own definition. Because this will lead to the addition of another concept when defining one concept; conversely, when defining another concept, the original concept is added.
Example: Two data elements with poor definitions 1) "Employee ID number" - the number assigned to each employee. 2) "Staff" - the person corresponding to the staff ID number. Reason: The meaning of each definition refers to another definition. Each definition does not specify the meaning. g) Related definitions use the same terms and consistent logical structure. Explanation: For similar or related definitions, the same terms and syntax should be used. Example: The example in rule 5.2a) above also illustrates this point. Both definitions are related to related concepts, so they should have the same logical structure and similar terms.
1) Shipping date - the date when the supplier sends the goods. 2) Receipt date - the date when the consignee receives the goods. Reason: Using the same terms and syntax is conducive to understanding. Otherwise, users do not know whether the use of synonymous terms and changed syntax means something different.
ISO Standards Manual 10, Data Processing -
GB/T18391.4—2001
Appendix A
(Indicative Appendix)
References
- Glossary, 1982
TRADE/WP.4/R.765/Add.1, United Nations Economic and Social Council, 1991.7.303 Guidance (Guiding Principles)
Data definitions should:
a) State the basic meaning of the concept.
Explanation: All basic characteristics that describe the concept should appear in the definition of the corresponding characteristic level for the relevant environment. Non-basic characteristics should be avoided. Whether to subdivide the level depends on the requirements of the system users and the environment. Example 1: "Consignment Loading Sequence Number" (Intended Environment: Any Mode of Transport) 1) Good definition:
Indicates the loading sequence number of a consignment in a transport vehicle or transport equipment. 2) Bad definition:
Indicates the loading sequence number of a consignment on a truck. Reason: In the intended environment, a consignment can be transported by various modes, such as trucks, ships, or freight trains. Consignments are not limited to truck transportation.
Example 2: "Invoice Total"
1) Good definition:
The total of the charges on the invoice.
2) Bad definition:
The total of all charges listed on the invoice, minus amounts such as discounts and rebates on the one hand, and insurance, transportation, handling and other charges on the other hand. Reason: Bad definitions include content that is irrelevant to the subject. b) Definitions are not comprehensive.
Explanation: The exact meaning and interpretation of the concept being defined should be clear in the definition. Definitions should be clear enough to allow only one interpretation.
Example: "Date of receipt"
1) Good definition:
The date on which the consignee receives the goods.
2) Bad definition:
The date on which the specific goods are delivered.
Reason: Bad definitions do not specify what determines "delivery of goods". "Delivery of goods" can be understood as the act of unloading the product at the intended destination, or as the location where the customer actually receives the product. It is possible that the customer never receives the product that has been unloaded at the yard, or that the customer receives it a few days after the product has been unloaded at the yard. c) Concise.
Explanation: The definition should be concise and easy to understand, and should avoid using irrelevant qualifying phrases such as "for the purpose of this data dictionary" and "the term to be described is".
Example: "Character set name"
1) Good definition:
The name given to a set of phonetic or ideographic symbols, and data is encoded with these symbols. 5
2) Bad definition:
GB/T18391.4—2001
The name given to a set of phonetic or ideographic symbols, and data is encoded with these symbols. The purpose of this data dictionary, as used elsewhere, is the ability of system hardware and software to process encoded data in multiple versions. Reason: In the bad definition, all phrases after "the data is encoded with these symbols" are irrelevant qualifying phrases. d) Can stand alone.
Explanation: The meaning of the concept can be reflected in the definition itself. To understand the meaning of the definition, no additional explanation or citation is needed. Example: "The name of the city where the school is located"
1) Good definition:
The name of the city where the school is located.
2) Bad definition:
See "School location".
Reason: A bad definition cannot stand alone, it needs the help of another definition (school location) to understand the meaning of this definition. e) Do not add theoretical explanations, functional descriptions, scope information or procedural information to the statement. Explanation: Although they are usually necessary, such statements should not be included in the definition itself because they contain information that is irrelevant to the meaning of the definition. If they are considered useful, such statements can be listed as different data element attributes (GB/T18391.3). They are used to explain the listed definition and should not be part of the definition (for example: if a data element uses miles instead of kilometers, the reason should not be explained in the definition).
Functional statements such as "this data element should not be used for" should not appear in the definition. Procedural comments, such as "this data element is used together with data element XXX", should not appear in the definition. Instead, "related data reference" and "relationship type" should be used as specified in GB/T18391.3. Example: "data field tag"
1) Good definition:
Data field tag for index, subject table, query, database, etc. 2) Bad definition:
Data field tag for index, subject table, query, database, etc. Data field tag is used for information units such as abstracts and columns in tables.
Reason: Bad definitions contain statements of function. Statements starting with "data field tag is used for .." must be removed from the definition. If such a statement is necessary, it should be placed in other attributes. E) Avoid mutual dependence.
Explanation: Two definitions should not define themselves based on each other. A definition should not use the definition of another concept as its own definition. Because this will lead to the addition of another concept when defining one concept; conversely, when defining another concept, the original concept is added.
Example: Two data elements with poor definitions 1) "Employee ID number" - the number assigned to each employee. 2) "Staff" - the person corresponding to the staff ID number. Reason: The meaning of each definition refers to another definition. Each definition does not specify the meaning. g) Related definitions use the same terms and consistent logical structure. Explanation: For similar or related definitions, the same terms and syntax should be used. Example: The example in rule 5.2a) above also illustrates this point. Both definitions are related to related concepts, so they should have the same logical structure and similar terms.
1) Shipping date - the date when the supplier sends the goods. 2) Receipt date - the date when the consignee receives the goods. Reason: Using the same terms and syntax is conducive to understanding. Otherwise, users do not know whether the use of synonymous terms and changed syntax means something different.
ISO Standards Manual 10, Data Processing -
GB/T18391.4—2001
Appendix A
(Indicative Appendix)
References
- Glossary, 1982
TRADE/WP.4/R.765/Add.1, United Nations Economic and Social Council, 1991.7.304—2001
The name given to a set of phonetic or ideographic symbols by which data are encoded. The purpose of this data dictionary, as elsewhere, is to handle the encoded data in multiple versions, as is the capability of system hardware and software. Reason: In a bad definition, all phrases after "the data are encoded by these symbols" are irrelevant qualifying phrases. d) Can stand alone.
Explanation: The meaning of the concept is reflected in the definition itself. No additional explanation or citation is needed to understand the meaning of the definition. Example: "The name of the city where the school is located"
1) Good definition:
The name of the city where the school is located.
2) Bad definition:
See "School location".
Reason: A bad definition cannot stand alone and requires the help of another definition (school location) to understand its meaning. e) Do not add theoretical explanations, functional descriptions, scope information, or procedural information to the statement. Note: Although they are often necessary, such statements should not be included in the definition itself because they contain information that is irrelevant to the meaning of the definition. If they are considered useful, such statements can be listed as different data element attributes (GB/T18391.3). They are used to explain the definition listed, but should not be part of the definition (for example, if a data element uses miles instead of kilometers, the reason should not be explained in the definition).
Functional statements such as "this data element should not be used for" should not appear in the definition. Procedural comments, such as "this data element is used in conjunction with data element XXX" should not appear in the definition, but should be used as specified in GB/T18391.3. "Related data reference" and "Relationship type" should be used. Example: "Data field label"
1) Good definition:
Data field label for index, subject query, query, database, etc. 2) Bad definition:
Data field label for index, subject vocabulary, query, database, etc. Data field label is used for information units such as abstracts, columns in tables, etc.
Reason: A bad definition contains a statement of function. Statements starting with "The data field identifier is used for .." must be removed from the definition. If such a statement is necessary, it should be placed in other attributes. E) Avoid interdependence.
Explanation: Two definitions should not define themselves in terms of each other. A definition should not use the definition of another concept as its own definition. This would result in the definition of one concept being appended to the other concept; conversely, the definition of another concept being appended to the concept that was already given.
Example: Two data elements with bad definitions 1) "Employee ID number" - the number assigned to each employee. 2) "Staff" - the staff member corresponding to the staff ID number. Reason: Each definition refers to the other definition in its meaning. Each definition does not specify the meaning. g) Related definitions use the same terminology and consistent logical structure. Explanation: For similar or related definitions, the same terminology and syntax should be used. Example: The example in rule 5.2a) above also illustrates this point. Both definitions are related to related concepts and therefore should have the same logical structure and similar terms.
1) Shipment date - the date on which the supplier sends the goods. 2) Receipt date - the date on which the consignee receives the goods. Reason: Using the same terms and syntax facilitates understanding. Otherwise, the user does not know whether the use of synonymous terms and changed syntax means something different.
ISO Standard Manual 10, Data Processing -
GB/T18391.4—2001
Appendix A
(Suggestive Appendix)
References
-Glossary, 1982
TRADE/WP.4/R.765/Add.1, United Nations Economic and Social Council, 1991.7.304—2001
The name given to a set of phonetic or ideographic symbols by which data are encoded. The purpose of this data dictionary, as elsewhere, is to handle the encoded data in multiple versions, as is the capability of system hardware and software. Reason: In a bad definition, all phrases after "the data are encoded by these symbols" are irrelevant qualifying phrases. d) Can stand alone.
Explanation: The meaning of the concept is reflected in the definition itself. No additional explanation or citation is needed to understand the meaning of the definition. Example: "The name of the city where the school is located"
1) Good definition:
The name of the city where the school is located.
2) Bad definition:
See "School location".
Reason: A bad definition cannot stand alone and requires the help of another definition (school location) to understand its meaning. e) Do not add theoretical explanations, functional descriptions, scope information, or procedural information to the statement. Note: Although they are often necessary, such statements should not be included in the definition itself because they contain information that is irrelevant to the meaning of the definition. If they are considered useful, such statements can be listed as different data element attributes (GB/T18391.3). They are used to explain the definition listed, but should not be part of the definition (for example, if a data element uses miles instead of kilometers, the reason should not be explained in the definition).
Functional statements such as "this data element should not be used for" should not appear in the definition. Procedural comments, such as "this data element is used in conjunction with data element XXX" should not appear in the definition, but should be used as specified in GB/T18391.3. "Related data reference" and "Relationship type" should be used. Example: "Data field label"
1) Good definition:
Data field label for index, subject query, query, database, etc. 2) Bad definition:
Data field label for index, subject vocabulary, query, database, etc. Data field label is used for information units such as abstracts, columns in tables, etc.
Reason: A bad definition contains a statement of function. Statements starting with "The data field identifier is used for .." must be removed from the definition. If such a statement is necessary, it should be placed in other attributes. E) Avoid interdependence.
Explanation: Two definitions should not define themselves in terms of each other. A definition should not use the definition of another concept as its own definition. This would result in the definition of one concept being appended to the other concept; conversely, the definition of another concept being appended to the concept that was already given.
Example: Two data elements with bad definitions 1) "Employee ID number" - the number assigned to each employee. 2) "Staff" - the staff member corresponding to the staff ID number. Reason: Each definition refers to the other definition in its meaning. Each definition does not specify the meaning. g) Related definitions use the same terminology and consistent logical structure. Explanation: For similar or related definitions, the same terminology and syntax should be used. Example: The example in rule 5.2a) above also illustrates this point. Both definitions are related to related concepts and therefore should have the same logical structure and similar terms.
1) Shipment date - the date on which the supplier sends the goods. 2) Receipt date - the date on which the consignee receives the goods. Reason: Using the same terms and syntax facilitates understanding. Otherwise, the user does not know whether the use of synonymous terms and changed syntax means something different.
ISO Standard Manual 10, Data Processing -
GB/T18391.4—2001
Appendix A
(Suggestive Appendix)
References
-Glossary, 1982
TRADE/WP.4/R.765/Add.1, United Nations Economic and Social Council, 1991.7.30
Tip: This standard content only shows part of the intercepted content of the complete standard. If you need the complete standard, please go to the top to download the complete standard document for free.