曝光臺 注意防騙 網曝天貓店富美金盛家居專營店坑蒙拐騙欺詐消費者

"natural" keys. The AIXM uses natural keys for the following reasons:
• The AIXM is intended for data exchange between loosely coupled systems. By not relying on artificial
identifiers, which would be system specific, the internal workings of a source or destination system
need not be known. This is important because data may originate from a number of sources.
• Changing an internal identifier in one system will not have an impact on other systems.
• The process of identifying the fields that constitute natural keys helped determine which AICM entities
should be regarded as AIXM features, and which should be regarded as properties of features.
Typically if an entity did not have an obvious natural key it was incorporated into another feature
that did. Grouping entities in this way helped avoid having to create complicated "artificial natural"
keys, such as it would have been the case for timesheets (for example).
Ideally, a feature's natural key would never change, but it is possible for this to happen. For example, a
DME, which is uniquely identified by its position (amongst other things), could be resurveyed to a
greater degree of accuracy, which would affect its natural key. The AIXM contains a mechanism for
handling this aspect of natural keys - for details, see section 5.1.4.2.
The AIXM also makes provision for surrogate keys - see section 3.4. Surrogate keys may be useful in
the case of data being exchanged between parties who have agreed on the form and the source of the
keys, and when the values of those keys are persistent.
Edition Number: 4.5 3
AIXM PRIMER
2.3. Feature-Entity Correspondence and Complex Properties
For every AIXM feature (cf. Chapter 3 for the definition of "AIXM feature") there exists a corresponding
entity1 in the entity-relationship data model, but the converse is not true.
Through the imposition of natural keys, it became clear that some entities should be regarded as complex
properties of other entities. Within the AIXM Schema, such entities have been implemented as complex
local elements of the appropriate feature type.
For example, the VOR_TIMESHEET entity corresponds to the <Vtt> child element in the declaration
of the VorType, having as type TimetableNavaidType (which is a complex type).
In addition, not all entities in the AIXM entity-relationship data model are supported by the AIXM
Schema. This is the case mainly for entities that model elements of the Integrated Aeronautical Information
Package, such as AIP, NOTAM, AIC, AIP Supplements. The purpose of including them into the
entity-relationship model was to show the relationships which exist between these documents and the
so-called 'tabular data' (or 'structured data').
The eAIP2 Project is looking into defining XML DTDs for these documents. The essential difference
between AIXM and the eAIP is that AIXM focuses on the exchange of the structured aeronautical information,
while the eAIP focuses on the exchange of the AIP document content, which is at 80% free
textual information (no structure, no type).
Future versions of AIXM are expected to include a definition for the currently unsupported entity,
TWY_INTERSECTION. For the moment, this entity should be regarded as a 'placeholder', an indication
of future work that needs to be done.
Note that Obstacle in Airspace, which has been removed from the AICM in edition 3.3, still exists in
the AIXM Snapshot Schema. It has been considered useful to preserve it in Snapshot messages, in case
a data provider would like to communicate the list of all obstacles in a given FIR/UIR. This would be
useful for AIP production, as there exist a table of En-route obstacles in ENR 5.4. It is intended to restore
it to a later version of the AICM
Appendix A contains mappings for entity-to-feature correspondence.
There exist one important difference between the naming conventions for AIXM XML elements and
the name of the corresponding entity in AICM. Short abbreviations of three letters are used as feature
names, instead of the name of the AICM entity. The purpose was to reduce the typing effort of the programmers
that will have to write code, frequently referring to feature names. Where available, 3 letter
ICAO abbreviations have been used, such as for VOR, DME, ILS, MLS, NDB, RWY, etc.
Further details on AIXM naming conventions are given in chapter 3.
2.4. Data Types
Within the conceptual model all data types were based on domains, which specify valid content for
particular kinds of value by restricting numbers to a particular range or text to a particular length etc.
Every AICM domain has an equivalent data type in AIXM, although they were implemented in varying
ways. Some, namely:
　
中國航空網 www.k6050.com
航空翻譯 www.aviation.cn
本文鏈接地址：AIXM_Primer_4.5(4)