Data element
In data management, a data element is an atomic data unit that is derived from operational reality as an information requirement in a given context (be it company-wide - be it limited to the area of a project ) and its content is determined (according to).
For example, the description contains the following information: A data item
- is identified by a data element name,
- has a data element definition appropriate to the intended use ; what does the data element mean?
- has one or more representation terms ; where, in which data class (es) does it occur?
- optionally has a list of the permitted values ,
- optionally has a list of synonyms in other metadata directories
Data elements do not contain any data , but merely describe which data fields can appear in the specific data records , what they mean and which formal conditions apply to them. This “ metadata ” is used automatically or through manual entries in the context of software development for data design and for the declaration of the data to be processed in the program code .
Data elements can be discovered and analyzed by manually or semi-automatically inspecting application programs, files or even textual solution specifications (such as requirement specifications or functional specifications ) and evaluating found formulations for their relevance.
In a different meaning , for example, attributes / variables are also referred to as 'data elements' when declaring them in certain programming languages . The term is also used colloquially in part synonymously for data field .
Data element definition
A data element definition is a prose description of the data element that describes the semantics or meaning of the data element.
A good definition is
- Precise
- That is, it is formulated in words with a precise meaning. Words with multiple meanings ( homonyms ) should be avoided.
- Concise
- A definition should be as short as possible.
- Not circular
- The term that is being defined should not be used in the definition itself.
- Clearly
- The definition should distinguish a data element from other data elements without overlapping.
Data elements can be identifying (e.g. the customer number uniquely identifies a specific customer), partially identifying (e.g. the article number and the customer number for an order) or descriptive (e.g. the color of a person's eyes).
Data item names
In a formal data dictionary there is often a requirement that no two data elements have the same data element name. However, in some data dictionaries there are ways to change the data element name, e.g. B. to qualify with a module prefix for one of several application modules.
In a database-supported data dictionary, the fully qualified data element name becomes a primary key or alternative key of a data element table.
Purpose and application of data elements (example)
For example, the following data elements can exist in a company data model:
- Cost centre
- Customer advisor number
- Customer number
- Post Code
- Date of birth
In the u. a. Tables for each data element contain a unique data element identifier, the associated domain , a short, medium and long description, as well as a link to the verbal definition and explanation in the company data model documentation. The domain is required if table columns are to be derived from the data element. The field names are defined here in the data element and are e.g. B. read from the form generator here.
In a project-related database design, table columns, in particular key columns ( primary key , secondary key ), relate, if possible, to a data element from the overall model. The relationship between the list of all data elements and the list of all table columns does not necessarily have to be 1: 1. A table that contains data about cost accounting documents can be: B. have, among other things, two table columns:
- Sender cost center
- Recipient cost center
which both refer to the same data element cost center . In addition, this data element is normally used in numerous other places in the data model , e.g. B. used in various database tables. In order to identify these locations / uses, a proof of use is usually available, for example in the form of a data dictionary .
A data element catalog as in the following example is part of the system documentation. It makes sense to add it as an appendix to the IT concept .
Data element ID | domain | Name (long) | Designation (mean) | Bez (short) | Explanation (long text) |
---|---|---|---|---|---|
DEKst | Num (10) | Cost centre | Cost center | Kst | intern.UDM.intranet / cost center |
DEKube | Num (10) | Customer advisor number | KuBeraterNr | Cup | intern.UDM.intranet / customer advisor |
DEKnd | Num (15) | Customer number | customer | Customer | intern.UDM.intranet / customer |
In some software packages, e.g. At SAP , for example , the data elements are kept in an 'active' data dictionary , the contents of which are used during the execution of the program, for example to display field names in screen masks in an individually selectable language.
See also
- ISO / IEC 11179 specification metadata directory
Web links
- Association for Enterprise Integration
- ISO / IEC 11179 standards (see ISO / IEC 11179-3: 2003 clause March 3, 1936)