Data-Dictionary

A Data Dictionary - German called data dictionary, data catalog or something fuzzier data directory - is a catalog of metadata that contains the definitions and presentation rules for all application data of a company and the relationships between the various data objects, so that the database is structured redundancy-free and uniform. It is an application of a specific data model.

In a relational database, a data dictionary is a set of tables and views that are in queries ( for example with the SQL language ) read only ( read-only ). The data dictionary is structured as a database, but does not contain application data, but the metadata, that is, data that describe the structure of the application data (and not the content itself). Building and maintaining such a data catalog are usually carried out using an interactive dialog, or from a data definition language (DDL).

Active, passive and integrated Data Dictionaries

An active data dictionary reflects at any time the current status of the detailed data model. Changes to the structure of a database can be done directly in the maintenance interface of the Data Dictionary, or by other means, such as a command interpreter to a DDL. Regardless of how these changes take place, the timeliness of an active data dictionary is always automatically guaranteed.

In a passive data dictionary this synchronicity is not given. Changes to the structure of the DBMS must be nachgepflegt manually in the Data Dictionary (DD ) if the desired and is economically feasible. In particular, DD products for modeling and documentation of the conceptual data model suffer from this problem.

Interfaces between humans and software

A data dictionary can be queried via the following interfaces:

• User interface Data designers, modelers
• Application programmer
• End
• Database administrator

• Compiler / Precompiler
• Integrated Development Environment (IDE ) for integration of the data dictionary in the sense of CASE
• Application programs
• Berichts-/Formulargeneratoren
• Query Optimizer
• Integrity Constraint Enforcer

Classification of Data Dictionaries, after modeling level

In the development and maintenance of data models of different modeling levels are distinguished:

• Conceptual level (usually based on an application area, in business computer science often enterprise-wide or even across companies )
• Logical level
• Physical plane in which the conceptual / logical data model is mapped and implemented based on a specific DBMS.

According to the different levels of data modeling can be distinguished according to support these model planes the Data Dictionaries. The Data Dictionaries differ depending on the level of this nature, content and data types of the necessary metadata, but also in terms of their features and analysis options.

Data Dictionary for conceptual / logical data modeling

At a data dictionary for conceptual / logical data modeling include:

• Definition of the entities, data elements and the relationships between entities
• Business definitions and explanations thereof

In addition to establishing the basic data objects or elements and their relationships typically also detailed descriptive texts are stored at the level of the respective entities, which are linked to each other by hyperlinks technique. When an organization builds an enterprise-wide data model ( UWDM ), information on application-oriented semantics for data type and data presentation are compiled for each data element. The semantic information to define the exact meaning of a data element and are formulated as continuous text. The presentation rules specify how data items are stored ( such as data type such as integer, text, maximum length of text input format, output format, range of values ​​as checking rule, static or dynamic quantity, etc.). This first form is often not included in the functionality of a DBMS as a standard feature. Must therefore be used here often isolated solutions. However, these represent in terms of a passive DBMS data dictionary dar. changes to the conceptual data model can not be automatically transferred to the physical data model of the DBMS.

Under ISO / IEC 10027 (see below) specifications have been drawn up to allow a vendor-and platform-independent exchange of information resources between different Data Dictionaries.

A data catalog can be used as a glossary, by information objects / entities, data elements / attributes and relationships / Relationships are considered as terms whose definitions are stored in the respective part of the description. The data dictionary can be developed into full ontologies, or classes, or business process models. If in addition to the data structure also describes the methods for data transformation, it is called a repository.

Data Dictionary for physical data modeling

At a data dictionary for physical data modeling include details of:

• Tables and data fields
• Primary and foreign key relationships
• Constraints, such as test information
• Stored Procedures and Triggers
• Access credentials ( username, roles )
• Physical database structure, such as memory allocations and indices
• Reference and reference

This form is available in each DBMS as an active data dictionary, however, is not always visible to the application programmer. Where such a data dictionary is not visible, it still forms the database structure as a database schema, however, is stored in hidden system tables. On each access to the database, the DBMS system software reads the database schema in order to identify the structure and the location of the requested data.

Function of the data dictionary in the application development

It makes sense in any case, is the integration of metadata from the data dictionary in the Integrated Development Environment (IDE). However, beyond a for the needs of the application programming suitably constructed and visible data dictionary is a necessary condition for the dynamic and generic programming of forms and reports.

The functions for the conceptual and physical data modeling are often not integrated in a data dictionary. Even more serious, detailed changes to the database architecture are not reflected back into the conceptual data model. Either is a time-consuming manual aftercare necessary, or timeliness of the documented data model is lost.

A data dictionary that is both integrated into the database, the program development environment and data modeling tools, fulfilled a variety of functions:

• It describes all the persistent data of an application area, eg in the form of an enterprise-wide data model
• Due to the Data Dictionary data screens can be generated automatically (see generative programming).
• The structure of a database table can be read by a program.
• Programs can read the data types and structures of tables that have not yet even exist at the time of the draft program. With a suitable language support a static fixed data definition is obsolete in the program text. Thus, the data dictionary is a central tool in application development when it comes to decouple data definition and modeling of program development.

Cross-application data consistency

One of the advantages of a well-defined data dictionary is the consistency of the data elements defined over different tables in a database. For example, several tables can contain the data element TelefonNr; with a data dictionary can be assured that all tables refer to the same data element. Thus, a database-wide consistency and a reference for all table fields and data elements to be achieved.

BNF syntax for writing Data Dictionaries ( DD)

- Context: Data Flow Diagram (DFD ), ERM, system modeling

A DD can be written in its coarse structure in the BNF notation and consists of several definitions which are respectively in a row. In a definition of an assignment is written in the form:

The left of the assignment there is a non- atomic term. To the right of the assignment there is a rule. A rule consists of a combination of atomic and non-atomic terms. Repetitions are possible. Circular definitions are not allowed, recursions allowed, however.

Example:

See also: Backus -Naur Form (BNF, EBNF ), syntax diagrams

However, a representation in this form allows only to show the metanotions and their relationships. In the application development of the individual metanotion usually support is of a variety of additional information such as

• Technical description in ordinary language
• Domain Values
• Field descriptions ( short, medium and long text ) for the form design
• Information whether the data element may be empty (eg NULL)
• References to check tables
• Etc.

Therefore, the BNF notation can indeed serve to list the entities and represent the relationships between them. For a more in-depth documentation and attribution feingliederige the BNF notation is usefully supported by an actual DD instrument.