THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
<== Back to Area 4 - Governance | Forward to Area 6 - Discovery
Area 5 provides detailed information about the structure and content of Assets. This includes structure of data, represented as schemas, reference data and models. This type of information makes the assets easier to use and provides guidance on how new assets should be implemented.
Figure 1 shows the package summary for area 5.
Figure 1: Summary of Area 5 packages |
Schema Elements
The schema used by data platforms to defined the structure of data assets are concrete physical artifacts, typically managed in a configuration management database. There are many approaches. XML and JSON documents have their schema built-into the data. Relational databases use their own Data Definition Language (DDL) for defining the data structures in the database.
For open metadata, we create an abstraction of these physical schema in order to understand the likely data elements stored in the data asset so we can govern them. Thus the open metadata types for schema do not exactly follow the physical schema structure but have enough detail to map the data elements. There should be enough information in the open metadata types, however, to regenerate a reasonable implementation of a physical schema of a particular type.
Schema Element shown in figure 2 describes the base definition for representing schema in metadata.
Figure 2: Schema Elements - the base definition for representing schema in metadata |
Asset Schema
Figure 3 shows the relationship between an access and a schema element. A physical data store may be made up of a hierarchy of Assets. Each of these Assets may point to the appropriate Schema Elements which are also typically organized in a hierarchy. Thus we can work with both assets and schema at different levels of granularity.
Figure 3: The relationship between Asset and Schema Element |
Schema Snippets
Developers can be aided in their work by having snippets of schema implementation that follow approved structures and naming conventions that they can include in their APIs and data structures. Figure 4 shows how these can be linked to a Schema Element. The Implementation Snippet is a Referenceable which means a link to an external reference (say a physical schema implementation in a source code repository) can be attached to it.
Figure 4: Snippets of schema implementations aid developers |
Schema Attributes
Schema typically have a hierarchical structure. Figure 5 provides for a structure of nested Schema Elements. These structures are further specialized later on this page for specific types of Asset.
Figure 5: Nested structures in metadata representations of schema |
Linked Schema Elements
Figure 5: Links between schema elements from different hierarchies |
Map Schema Elements
Figure 7 adds support for a map structure in a schema.
Figure 7: Maps in schema |
Derived Schema Elements
Derived Attributes (such as in relational views) are defined in figure 8.
Figure 8: Schema element for virtual resources |
The definitions so far cover all of the structures needed to support the metadata for a schema.
The next series of figures show specialized entities for different shapes of data that inherit from the Schema Element structures. They do not add attributes of new relationships, but change the entity type to make it easier for programs processing the metadata because the type name is more specific.
Tabular Schema
Figure 9 shows the the structure of a single table. This could be a file that is organized into columns.
Figure 9: Schema for tabular data |
Document Schema
Figure 10 shows the definitions for structured documents such as JSON or XML.
Figure 10: Schema for structured documents |
Object Schema
Figure 11 describes an object schema - such as the structure for a series of POJO Java objects.
Figure 11: Schema for object structures |
Graph Schema
Figure 12 describes the schema for a property graph.
Figure 12: Structures for property graphs |
Relational Schema
Figure 13 describes the parts of a relational schema. These are used in relational databases. There are multiple tables and views defined within the relational schema. The columns are within both the tables and views.
Figure 13: Parts of a relational schema |
Event Schema
Events are simple linear structures. They typically are defined in sets of related events. Figure 14 shows the parts of an event schema.
Figure 14: Schema for a collection of events |
API Schema
APIs exchange data structures and commands. The schema of the API is its interface definition. It is an access point for data and so it is important to understand and control what data is passing over an API. Figure 15 shows the structure of an API schema. The top level schema for the API lists the operations. Under that, each operation defines its requests and responses.
Figure 15: The structure of an API |
Model Elements
Models are used during the development of schema and their related software to provide templates and abstractions of the implementation. We add representations of models the the metadata repository to help organize and explain data assets - particularly when they are complex, or the schema is not available.
Figure 16 shows the definition of a model element ad its relationship to the part of the IT landscape that it describes. This is the base for many different types of models. Currently we only have solution blueprints defined. Their models follow on later on this page.
Figure 16: Base for model elements |
Solution Blueprints
Solution blueprints are models of an IT deployment. They show the way different processes and assets are used in combinations to deliver a solution.
Figure 17 shows the root definition of a solution blueprint.
Figure 17: Solution Blueprints |
Figure 18 covers the wiring of the blueprint
Figure 18: Data and control wiring in the solution blueprint |
