00. Metadata Terminology

---

CWM (Common Warehouse Metamodel)

The Common Warehouse Metamodel (CWM) is a specification that describes metadata interchange among data warehousing, business intelligence, knowledge management and portal technologies. The Pentaho metadata model is in compliance with the CWM™ specification. For more information, please see the CWM Resource Page.

Domain

A metadata Domain is a Pentaho term representing all of the business objects created, stored and used in the metadata layer. A domain may consist of one or more connections, one or more models, security information, business tables, business views, categories, columns and concepts. You can create and save multiple Pentaho metadata domains using the Pentaho Metadata Editor.

A metadata domain is accessed by a Pentaho BI server by exporting (or publishing) the domain to a file named metadata.xmi, and placing the file in the Pentaho solutions repository at the root of a solution's directory structure.

Connection

A Connection represents one database's connection information, and acts as the parent in the hierarchy for all physical tables and physical columns that are defined for that database. Pentaho metadata models can connect to most common relational databases using JDBC.

Physical Table

A Physical Table is an object that represents table information mapped directly to a table from your database (or connection).

Physical Column

A Physical Column is an object that represents column information mapped directly to a column from a table in your database (or connection).

Business Model

A Business Model contains all of the logical, abstract business objects and relationships that model your physical database objects in such a way that underlying changes to the physical database objects have minimal impact on your business, your business intelligence application, and your end users. There can be multiple business models in a single domain. A business model currently supports just one database connection, and consists of business tables, relationships, and a single business view.

Business Table

A Business Table is the logical representation of a physical table. This is the layer in the model that insulates your applications and users from database changes. The business table models your physical table, so changes to the database only require changes to this layer in the metadata model, and NOT to the hundreds of reports, dashboards, transformations, etc. your users have created against this data.

Business Column

A Business Column is the logical representation of a physical column. See Business Table for further description.

Note that a business column can have a business table as its parent, or a business category as its parent. They represent the same physical column regardless of which type of parent they have, but serve different purposes. A business column as child of a business table is modeling the physical column, and plays a part in describing the relationships between the business tables (think primary / foreign key relationships). A business column as a child of a business category is representing a column for applications and users to consume, and as such may have a richer set of properties.

Business Relationship

A Business Relationship describes a relationship between two tables. This means determining key column matches between two tables, as well as the 1:1, 1:N, N:N relationship.

Business relationships need to be defined for all modeled tables that have such relationships.

Business Category

A Business Category is a bucket to hold a logical grouping of business columns. Note that the business columns added to a particular business category can come from multiple, different business tables. A business category does not have any relationship to the business tables defined in the model, even though you can create a business category from a business table (a convenience feature). Business categories are independent, relatively featureless buckets used primarily for organizing your business columns in a fashion that is more intuitive to your users.

Business View

The Business View is a collection of business categories that represents the "view" of your model, typically consumed by your end users. Each model can have one and only one business view. Business views are made up of a logically (logically relevant to your organization or end-users) organized business categories and business columns.

Property (Properties)

A Property represents a metadata attribute that will help richly describe your data. A "property" has an identifier (a key into a map actually) and a value. An example property might be "font" (the identifier), with a value of "Arial" (the value).

Concept

A concept is a collection of properties. A "property" has an identifier (a key into a map actually) and a value. This collection of properties is the map of attributes that you wish to apply to a particular business object, such as a business column or business table. The concept IS the metadata you define for your business objects.

Each business object (physical table, business table, columns, etc.) has its own concept whose properties override all other InheritedConcept or ParentConcept concepts.

A business object may or may not have an InheritedConcept, depending on the object and its level in the model hierarchy. For more details about about the model hierarchy and inheritance, review the metadata business model overview.

Concepts can also be defined independent of any business object, and can be structured in an inheritance hierarchy for better organization and management of your metadata. These independent concepts can then be applied to one or more business objects as a ParentConcept.

Parent Concept

A Parent Concept is an independently defined, reusable concept that you can apply to a business object. While each business object has its own collection of properties, you can use a parent concept to add a pre-defined additional set of properties to the business object. If there is any overlap in properties between the parent concept and the business object's own concept, the business object's own concept will be used first.

Inherited Concept

An Inherited Concept is a collection of properties that a business object will be assigned from a related business object. For instance, a business column is related to a physical column, so a business column will inherit any and all concept properties from the physical column. For more details about about the model hierarchy and inheritance, review the metadata model overview.