Model Check

In this section we give an overview of how models created in the i-refactory modeller can be checked to find errors.

Automated model checks

PowerDesigner has a very important feature called model check, this examines your changes in the model and will warn (and sometimes autocorrect) you for inconsistency and mistakes. There are many default checks available. These checks are documented on the SybooksOnline pages.

As part of the i-refactory, additional checks are included; you can recognize these rules because the name starts with i-refact.

You can check your model in any of the following ways:

  1. Press F4 in a model
  2. Select menu Tools > Check Model
  3. Right-click the diagram background and select Check Model from the contextual menu

After you start the Model Check, a result list is displayed. It is required that reported errors are resolved and that warnings are carefully checked.

The i-refactory Model Checks contain a description that is shown after you press Help when you right-click on the error.

{info} SQL code and regular expressions in your model - for example in Business Rule Helpers or Attribute Value Constraints - are not checked. Any syntax errors there will result in an error in the Runtime environment. For example, during metadata import or during data consumption.

Automatic correction

It's possible to automatically correct a limited number of warnings and errors, but you always have to understand why it warns you before you apply the autocorrect function. You can apply a correction by right-clicking on the warning or error and selecting the Automatic correction option.

Manual correction

Most warnings and errors require manual intervention. You can apply a manual correction by right-clicking on the warning or error and selecting the Correct option.

Examples

Here are some examples of model checks warnings and errors that you can encounter when you run model checks on your model:

Model check errors in Technical Model and Logical Validation Model

Check Applies to Purpose Action to fix
Existence of collation Column Check if a collation is set for a column. Instead of specifying a collation, set the column to a datatype which supports Unicode (nvarchar). The automatic correction option removes the collation but does not change the datatype.
Timeline column should always have a timeline type / kind Column This check identifies timeline columns, where the timeline type/kind is empty. For any model other than a GDAL model check, the timeline type error is connected to the column. For a GDAL model, check the mapping from the CFM.
Column mapping is not allowed to a computed column Column mapping Checks if a mapping is created to a computed column and returns an error if one exists. Either remove the mapping or execute the automatic correction option. If the automatic correction option is chosen, the column is set to a normal column.
Existence of multiple mappings with the same source-target tables Entity mappings Check if multiple mappings exists between the same source and target entity. Manual remove one or more duplicate mappings.
Architecture layer not allowed to be empty/null Model Checks if the architecture layer code of a model is set. Set to proper value manually if empty.
Source or target tables used in mappings cannot be found Model not open If a model contains mappings, this check ensures that the models referenced in the mappings are opened. Otherwise exporting the metadata does not contain the proper mapping information. Open the relevant models.
Owner should not be empty Owner/schema Each table in a model should have an owner. Manually set the owner for those objects listed in the check.
Reference code uniqueness Reference Checks if the code of the reference is unique. Change the code of the reference manually.
Reference name uniqueness Reference Checks if the name of the reference is unique. Change the name of the reference manually.
Role name in collection is unique if duplicate parent reference exists Reference If two or more relations of the same type exist between 2 entities, then a parent role should be entered for these relationships. Otherwise they cannot be distinguished. Manually correct the relationship and add a parent role.

Model check errors in Central Facts Model

Check Applies to Purpose Action to fix
Columns in BK of subtyped Hub should be of the same type as columns in BK of supertype Hub BK key Checks if the columns in the business key of the subtyped hub are of the same datatype as columns in the business key of supertype hub. Correct the datatype.
Hub business key must contain one or more columns BK key This check ensures that the hub, has at least one business key column. Add at least one business key column.
Columns in the natural key are incorrect BK key / Link key The check ensures that columns in a hub or link have the proper stereotype and that columns that have the proper stereotype are all in the "natural key" of the hub/link. Use the autocorrect option. Columns may be removed from the anchor or added to the natural key.
Business Rule Helper does not have a Primary Key Business Rule Helper This check ensures that a Business Rule Helper object has a primary key. Add a primary key to the business rule helper.
Not all columns are stereotyped in the Business Rule Helper Entity Business Rule Helper columns This check ensures that all columns in the business rule helper entity have a stereotype. Use the autocorrect option. Or manually update the columns to the correct stereotype.
Column should have a mapping Column Columns in the model should be mapped. Add a mapping.
Structural Feature should have a stereotype Column Each column in the model should have a stereotype. Autocorrect is available for context tables. Columns in these table types will be set to Satellite Column if empty.
Satellites and foreign key links should be mapped from one source entity only Context tables (satellites, foreign key links) Context tables (satellites and foreign key links) should have only one source table mapped. Mapping more than one source table to a context table will result in loss of data. Remove one or more mappings.
Satellites and foreign key links should have exactly one driving relationship Context tables (satellites, foreign key links) This check ensures that satellites and foreign key links have exactly one driving relationship. Remove the incorrect relationship.
If the column has a mapping then at least all source key columns should be mapped DVSurrogateKey columns in context tables If a mapping exists from a source then at least all key columns of this source should be mapped. Add the missing mappings.
Foreign key link should have at least one reference to an anchor Foreign key link This check ensures that an FK Link has at least one non driving reference to an anchor. Add a non driving reference to a anchor.
Foreign key links has at least two outgoing references Foreign key link This check ensures that foreign key links have two or more references to other tables. Add an additional reference.
A hub should have one or more business keys as part of the alternate key Hub / Link This check ensures that a hub has one or more business keys as part of the alternate key. Add a business key.
If a satellite or foreign key link is related to the anchor then at least a unitemporal single active satellite or foreign key link should be related to the anchor as well Hub / Link Make sure the anchor (hub or link) at least has a relation to a unitemporal/single active satellite or foreign key link as well. Otherwise the existence flag on the anchor will not be properly set to true/false. Add a satellite or foreign key link to the hub or link.
No mastermapping present Hub / Link No mastermapping is found on the anchor. A mapping is a mastermapping if and only if the primary key columns of a source table are fully mapped to the business key columns of an anchor and this same source table is fully mapped to the surrogate key of a unitemporal/single active satellite or foreign key link. Map the primary key columns in the source table to the business key columns in the hub or link.
No satellite or foreign key link connected to the anchor Hub / Link This check warns for the fact that a anchor doesn't have a satellite or foreign key link connected to it. Add a satellite or foreign key link to the hub or link.
Subtype should have at least one subtype reference Hub / Link A subtype should have at least one subtype reference / relationship. Add a subtype reference/relationship
Too many mastermappings present Hub / Link More than one mastermapping is found on the anchor. A mapping is a mastermapping if and only if the primary key columns of a source table are fully mapped to the business key column of an anchor and this same source table is fully mapped to the surrogate key of a unitemporal/single active satellite or foreign key link. Remove the mastermapping and apply it correctly.
BK of subtyped Hub should have the same number of columns as BK of supertype Hub Key Business key of subtyped Hub should have the same number of columns as the business key of supertype Hub. Remove and create the subtype again
The key of a satellite must contain start_date and all non templated columns Key This check ensures that the alternative key of an Alternative Key satellite contains start_date and all non templated columns. Use the autocorrect option. Or remove and create the alternative key satellite again.
Index for Primary or Alternate Key is not as expected Key related indexes This check ensures that the Primary and Alternate Key index have the correct column list and are named as their counterpart key. Use the autocorrect option.
Key Root is not allowed to have any context Key root anchor This check ensures that a Key Root does not have any context. Remove the context attributes in the Key Root.
Key Root Link should be connected to other key-roots Key Root Link A key root link is only allowed to contain references to other key roots. Add a reference to an other key root to the key root link
Link key (LK) should contain at least two columns Link This check ensures that the link has a natural key that consists of at least two column, either 2 foreign keys or a foreign key and an attribute. Add another reference or a column to the link.
Source and target columns should have a comparable datatype Mapped columns Datatypes of source and target should be equal. Manually synchronize the datatype (either of source or target).
Non key attributes from source table are mapped to the natural key of a hub or link Mapped DVLinkReferenceColumn, DVLinkKeyColumn and BusinessKeyColumn columns in a hub or link Mappings from non key source attributes to a Hub or Link are suspect. They are although not necessarily wrong when used as integrity mappings. Correct the mapping.
Surrogate key column of a hub or link should not be mapped Mapped DVSurrogateKey columns of a hub or link It is not allowed to map to these columns. Use the autocorrect option. The mapping will be removed.
Metadata columns should not be mapped Mapped MetadataColumns These columns should not be mapped to from a historical staging model. Use the autocorrect option. The mapping will be removed.
Only one source table is allowed to map to both an anchor and a context table (satellite or foreign key link) Mapping Make sure only one source table is mapped to both an anchor and a satellite/foreign key link. The satellite or foreign key link should be a unitemporal/single active satellite/foreign key link. Other source tables may only be mapped to either the anchor (integrity mapping) or the satellites or foreign key links but not to both. With this check we assure that only one master mapping exists for an anchor. Correct the mapping.
Natural key subtype reference generated flag set to true Natural key subtype references Checks if the generate flag of the reference is set to false (enforcement of this relationship as a referential foreign key constraint is not required/desired). Use the autocorrect option.
Natural key subtype reference join incorrect, replicated columns differ from joined columns Natural key subtype references This check ensures that the natural join is complete with respect to the replication and joined columns. A column is replicated from the root. So the replicated column in the child should have the same source in the root as should the parent column. Use the autocorrect option.
Reference name or code incorrect Reference code and name Set the name and code of a reference to the correct value. Use the autocorrect option.
Link object should have a stereotype References A link object like a reference should have a stereotype. Manually correct (remove the object and recreate).
Reference join uses the wrong column in the child-table References of a link This check ensures that the join columns of a reference in a link only use columns classified as DVLinkReferenceColumns. Manually correct. Either repair the join conditions or remove the reference and the column from the link and create a new reference.
Satellite Block should contain at least one satellite column Satellite columns A satellite normally should have a column with stereotype SatelliteColumn. It is although possible that no context is available and the satellite is only use for tracking the existence of an anchor.
Satellite column should never be mandatory Satellite columns These columns should never be set to mandatory. Use the autocorrect option. The mandatory property will be set to false.
Virtual subtype is not supported Subtype anchors This check ensures that a subtype is not virtual / non persistent. Manually correct the error.
References from all links that are part of a subtype hierarchy should refer to the same hierarchy at all levels Subtype links This check ensures that references from all links in a sub / supertype hierarchy point to the same hubs / links (or their sub / supertypes) across a subtype hierarchy. Manually correct the error.
Subtype Reference incorrect - check script output window Subtype references This check ensures that the subtype reference is correct according to the business rules defined for modelling subtypes including their references. See the script output window for more details. Manually correct the error.
Subtype Reference should have a matching natural key reference and vice versa Subtype references This check ensures that a natural key reference and a normal reference exist for a subtype relationship. Use the autocorrect option.
Table with non-unique code Table This check ensures that all tables in the model have a unique code. Manually correct the error.
Classifier should have a stereotype Tables, Views All tables, views and other named classifiers should have a stereotype when modelling an UAM model. Manually correct (remove the object and recreate).
Timeline transaction columns should not be mapped Transaction timeline columns Not allowed to map to these columns. Manually remove the mappings.

What's next?

After you've checked the physical data models, you can deploy the data models.

Constraint violation actions are applicable to certain constraint categories. Not all combinations of constraint categories and violation actions are allowed.

An attribute must have a value, whatever that value may be. It must not be NULL.

A data type of an attribute defines what value an attribute can hold. The data type specifies what type of mathematical, relational, or logical operations can be applied to it without causing an error.

An attribute datatype constraint is the most basic constraint type. It checks for the datatypes we support and have implemented.

For example, we check for string, length of string, integer, date, etc. In the following figure you can see the supported data types by PowerDesigner.

Image is omitted: Supported data types

Constraints can be violated and there are some actions that can be performed when a violation occurs. The possible actions are: EMPTY COLUMN, NO ACTION and SKIP ROW.

An attribute value constraint is an expression that is evaluated. The person who writes the expression is responsible for the correctness of it. The expression should be formulated in a positive way and lead to a Boolean answer. If the expression validates to True, than the value is correct.

Examples

  • The values in attribute X has to be bigger than 10: X > 10
  • The email address has to be in a certain pattern: email address LIKE '%_@_%.__%'

A Concept Integration Model is also a central facts model on which you place integration patterns. It is not required to create a concept integration model, but it can be very useful.

Every constraint is assigned to a constraint classification.

The main purposes of the Generic Data Access Layer (GDAL) are to provide logical perspectives for data consumption and to manage CRUD actions.

A generic data access model is a virtual data model that acts as an interface bridge between consumer applications and the central fact storage.

Every attribute is assigned to an attribute classification.

An entity record constraint checks whether an attribute meets the requirements set by another attribute belonging to the same entity.

The main purpose of the Logical Validation Layer (LVL) is to transform the data received from external data sources to fit into the logical data model structure. It is also responsible for validating deliveries. The Logical Validation Layer is also known as the Historical Staging In (HSTGIN) Layer.

The logical validation model is the representation of a single external data source in a logical format. It represent how data delivered by a specific tenant should be transformed, temporalized and validated in the {popup}logical validation layer. The logical validation model is also known as Historical Staging model (HSTGIN).

Multi-active attributes are attributes that contain a business key to provide multiple context records at the same time. For example: a customer has multiple types of phone numbers. “Home”, “Work” and “Mobile”. In that case we add a dependent entity on customer with key “Phone Nbr Type”. This is to prepare for the CFPL multi-active key on customer.

The main purpose of the Technical Staging Layer (TSL) is to create a common starting point for further data processing. It receives data delivered from external data sources and temporally stores them in a database. The input data should be in a tabular format (rows and columns).

Bi-temporal attribute is an attribute that changes over time: they follow a valid timeline. For example, a Part may have a price valid for December and a price valid for January.

Every entity is assigned to an entity classification and to a parent entity classification. The possible values for entity classification are: ALTERNATE KEY CONTEXT, ATTRIBUTE CONTEXT, GENERALIZATION,HELPER, REFERENCE CONTEXT, STABLE, STABLE DEPENDENT and STABLE INDEPENDENT

Entity Set Constraint An entity set constraint can be used to perform a check concerning values of two or more attributes that belong to different entities or to perform a check concerning the value of an attribute with respect to a set of values.

A Set Constraint Helper is a helper in the logical validation model. It is the implementation of a set constraint. The helper returns the records of an entity for a given set constraint, where the instances of this entity do not meet the definition of this set constraint.

The business requirements describe how data should be delivered for the data consumers (end users or applications) in terms of concepts, relationships between concepts and constraints to validate the data. These requirements can be described in a logical data model, for example.

A Business Rule Helper is a helper in the central facts model. It is a set-based calculation of derived facts. You need to use a Business Rule Helper if you want to make a calculation and want to keep a transaction history of the results of this calculation. You use the existing entities from the central facts model as input. The results of the helper must be materialized in 'regular' fact entities, such as Anchors and Contexts, to make them accessible in the Generic Data Access Layer.

Closed Open means that the timeline is valid from (vanaf in Dutch) the supplied valid start date until - but not including - (tot in Dutch) the supplied valid end date. In practice, this means that the start date of a valid time record is equal to the end date of the previous valid time record.

You need to create context-based entities when a set of data may be delivered within the boundaries of a parent context. A context-based entity applies when:

  • At least 2 entities are delivered.
  • A context relationship exists between these 2 entities. One entity is the parent context of the other entity.
  • The parent context entity is delivered as a delta and the child entity is delivered as a full set.

You need to create context-based entities when a set of data may be delivered within the boundaries of a parent context. A context-based entity applies when:

  • At least 2 entities are delivered.
  • A context relationship exists between these 2 entities. One entity is the parent context of the other entity.
  • The parent context entity is delivered as a delta and the child entity is delivered as a full set.

The Management Model contains the PowerDesigner objects for the Unified Anchor Modelling (UAM). When a UAM object is created, a so-called PowerDesigner replica of the corresponding Management Model object is created. This means that certain properties such as metadata columns and column stereotypes are configured in the Management Model and cannot be changed. The replication settings specify which elements of an object can be changed after creating a replica from the template object. It is possible to override the replication settings of an UAM object and change a specific property.

The temporal atomic type describes the datatype of the temporal attributes|

The main purposes of the Central Facts Layer (CFL) is to store data historically. It can also integrate data from different sources. The Central Facts Layer is also known as Central Facts Persistency Layer (CFPL)

The central facts persistence implementation model is the representation of facts in an anchorized data model with the ability to integrate multiple logical models.

In the context of i-refactory, data transformation refers to operations involved in turning raw data readily useful and closer to the business requirements.

Integration patterns are used to integrate entities from different data models. If two or more entities from different data models share the same business key, you can use the Integration Pattern named Key Root. It is a good practice to capture integration patterns in a separate model, named Concept Integration Model.

An attribute is mandatory when its value can not be empty (NULL).

A Physical Data Model (PDM) represents how data will be implemented in a specific database.

{note} The i-refactory uses four PDMs: technical staging model, logical validation model, central facts model and generic access model. Each one of these models is implemented as an additional database, which is used to store data from external and internal data sources.

Reverse engineering is the process of reconstructing a physical and/or Entity Relationship (ER) model from an existing data source. The purpose of reverse engineering is to avoid manual work as much as possible.

Architecture layer

The core of the i-refactory architecture has four layers: TSTGIN, LVL, CFL and GDAL. There are also two auxiliary layers: UCLVL and EXT.

If an entity has one or more attributes that changes over time and you want to keep track of when a attribute is valid at a certain transaction time, then you have a special case of a regular dependent entity, called bi-temporal entity. The bi-temporal entity stores historical data with two timelines. The primary key of the bi-temporal entity is composed by the primary key of the parent entity and the valid start date attribute. The attribute that changes over the valid time is called a bi-temporal attribute.

If an entity has one or more attributes that changes over time and you want to keep track of when a attribute is valid at a certain transaction time, then you have a special case of a regular dependent entity, called bi-temporal entity. The bi-temporal entity stores historical data with two timelines. The primary key of the bi-temporal entity is composed by the primary key of the parent entity and the valid start date attribute. The attribute that changes over the valid time is called a bi-temporal attribute.

A delivery agreement is a contract between a Tenant and a Logical Implementation Model or Generic Data Access model. An agreement has a duration. The delivery agreement set the architecture layer (interface) where the data should be ingested as well as the default settings to be applied to the deliveries.

A dependency mapping is a mapping between a helper (or BR helper) and a source entity used in the query of the helper. The helper and the source entity must belong to the same model.

  • Default dependency is set on entity level (source entity to helper entity)
  • To allow lineage on attribute level, via the Mapping editor, you could manually add the dependency on attribute level.

An Independent Entity is an entity that implements an Anchor for a Business Key that ‘stands alone’ e.g. that does not contain a reference to another Entity.

An Independent Entity is an entity that implements an Anchor for a Business Key that ‘stands alone’ e.g. that does not contain a reference to another Entity.

A Logical Data Model (LDM) matches the language, structure and quality of the business, regardless of the physical data implementation. The Logical Data Model reflects the business requirements.

A delivery may be considered as "untrusted" if deletes of data in the Logical Validation Layer have taken place and the processing of new deliveries cannot 100% rely (trust) on having enough statistics and data available to detect logical deletes, to determine the exact delta and to execute set based validations.

A delivery may be considered as "untrusted" if deletes of data in the Logical Validation Layer have taken place and the processing of new deliveries cannot 100% rely (trust) on having enough statistics and data available to detect logical deletes, to determine the exact delta and to execute set based validations.

A Dependent Entity is an entity that implements an Anchor for a Business Key that ‘depends’ in its existence on another Entity. A Dependent Entity contains Business Key fields of which at least one is a foreign key (FK).

A Dependent Entity is an entity that implements an Anchor for a Business Key that ‘depends’ in its existence on another Entity. A Dependent Entity contains Business Key fields of which at least one is a foreign key (FK).

The transaction time in i-refactory is different from what is commonly understood by transaction time. Transaction time is usually seen as the moment when a fact was stored in the database. In the i-refactory, the transaction time is the time, as dictated by the source system, not by the i-refactory database.

The Attribute type links the attribute to one of the existing interfaces.

Computed columns are columns whose content is computed from values in other columns in the table.

Functional date A functional date or time is a point in time and is defined by a user. An example is an order date or date of birth.

The technical model (also known as Technical Staging In model: TSTGIN) is a representation of how exactly one delivery from a specific data source will be processed in the technical staging layer.

Generalization is the process of extracting shared characteristics from two or more classes (hyponyms), and combining them into a generalized superclass (hypernym). For example: an 'employee' and a 'customer' are both 'persons'.

The Mapping Editor provides a graphical interface for creating and viewing mappings between models. It provides a global view of all the mappings related to the entities of a given model, allowing you to quickly identify those which are mapped and not mapped.

When a certain fact can change over time and you need to capture when that fact is valid in the real world, you can add a valid start date and a valid end date to the entity.

A valid time tells us in which period a record is valid. While a functional date represents just one point in time, the valid time has a begin and an end date, for example:

  • For Order item 123, a Retail price of 10.00 was valid from 2019-01-01 to 2019-06-01.
  • For Order item 123, a Retail price of 12.00 was valid from 2019-06-01 to 2020-01-01.

Alternate key is an attribute or a group of attributes whose values uniquely identify every record in an entity, but which is not the primary key

Candidate key

A candidate key consists of one or more attributes and meets the following requirements:

  • Unique: The value of the key defines uniquely one instance of a concepts. There are no double values.
  • Non-volatile: (Almost) doesn't change.
  • Minimal: Contains only the elements needed.

There are two kinds of candidate keys:

  • primary key
  • alternative key

Normalization is the process of decomposing tables in a database in order to reduce data redundancy and improve data integrity.

A strongly typed model is a model in which each all attributes have a predefined data type, for example: integers, doubles, date.

Surrogate Key A surrogate key is a system generated unique identifier that does not have any contextual or business meaning.

Business Key

A business key is an unique identifier that has business meaning and exists in the real world outside of the database. It consists of a column or a set of columns that already exists in a table. A business key is also known as a natural key

A Key Root Hub is an integration concept that must be used when the exact same business concept or independent business key occurs in different models. The Hubs for this independent business key in the different UAM models are all subtypes of the Keyroot Hub.

A relationship shows how two entities are related to one another. For example, a customer can place an order, and a order can have a customer.

Every Attribute has an atomic type (data type) which is linked to the attribute type of that attribute.

The cardinality shows how many instances of an entity can take place in a relationship.

The cardinality shows how many instances of an entity can take place in a relationship.

An enumeration consists of the list of values that a given attribute should adhere to.

{example} An order can have different statuses, such as shipped,packing,created anddone. Other statuses are not allowed.

Foreign Key

A foreign key is an attribute or a set of attributes that refers to the primary key of another entity. The original entity containing the primary key is called the 'parent' entity and the entity containing the foreign key is called the 'child' entity.

A natural key is an unique identifier that has business meaning and exists in the real world outside of the database. It consists of an column or a set of columns that already exists in a table. A natural key is also known as a business key

The primary key is an assigned key that consists of a minimal set of attributes to uniquely specify an instance of a record. The attribute or a combination of attributes should meet the following characteristics:

  • Unique: The attribute values of the key uniquely identify one instance of a concept. There are no duplicate instances.
  • Non-volatile: The key does not change.
  • Mandatory: All values are filled; there are no NULL values.

It is good practice to choose a primary key that also meet the following characteristic:

  • Safe: Doesn't contain private or sensitive information, such as a social security number.

Constraints are related to the other elements depending of the type of the constraint. Certain constraints are associated to attributes, entities, helper entities, unique keys or relationships between entities.

An attribute may be assigned to one or more entities (ex: acm_exists_ind) and an entity may have several attributes

Each layer may have one or more interfaces. The amount of interfaces depend on how many tenants and delivery agreements have been configured.

Namespace is what in the terminology of SQL Server is called database schema.|

A Delivery is a container that holds the specification of what is actually pushed to the i-refactory platform. This specification consists of a list of entities.

A Delivery is a container that holds the specification of what is actually pushed to the i-refactory platform. This specification consists of a list of entities.

Key Root A Key Root is a central repository for Business Keys. A Key Root ensures that similar records out of different data sources are identified by both the same Business Key as the Surrogated Key.

Context

A Context is a temporal table with a transaction start and end date. The Context tracks all changes of the context attributes related to a business key in the transaction time. This means that every change of an attribute value in a source system leads to a new record in the Context. The old record is end dated with the load date and the new record is start dated with the load date.

Hyponym is a term that denotes a subcategory of a more general class. For example: 'cat' and 'dog' are a hyponyms of 'animal'.

A mapping establishes relationships between concepts of separate data models. It creates a link between entities and attributes from a source model to related entities and attributes in the target model. A source model should precede the target model in the i-refactory architecture.

oasi_bk is an abbreviation for One Attribute Set Interface (OASI) with business keys. A normal view in the generic data access layer (GDAL) consists of the surrogate key, foreign key and attributes. The oasi_bk-view in the GDAL is a view where the business key(s) are also shown.

A subtype is a subgroup of an entity. You can create a subtype if a group of instances share some attributes and relationships that only exist for that group. For example, entity Customer can have a subtype Company and a subtype Person. They share the common attribute customer number, and can have some attributes of their own. Such as birth date for a Person. The entity Customer is called a supertype.

A subtype:

  • inherits all attributes of the supertype
  • inherits all relationships of the supertype
  • usually has one or more own attributes
  • can have subtypes of its own

Anchor: Independent Entity

An Independent Entity is an entity that implements an Anchor for a Business Key that ‘stands alone’ e.g. that does not contain a reference to another Entity.

Anchor: Dependent Entity

A Dependent Entity is an entity that implements an Anchor for a Business Key that ‘depends’ in its existence on another Entity.

A domain will help you to identify the types of information in your model. It defines the set of values for which a column is valid. A domain can specify a data type, length, precision, mandatoriness, check parameters, and business rules. It can be applied to multiple columns, which makes it easier to standardize data characteristics for columns in different tables.

Each interface may have one or more entities and one entity belongs to only one interface. An entity belongs to an i-refactory data model.

Each interface may have one or more entities and one entity belongs to only one interface. An entity belongs to an i-refactory data model.

A helper entity creates a derived entity and can be used when you need to transform, filter, or calculate data. The purpose of a helper differs per model:

  • Technical model: a helper is used to transform data.
  • Logical validation model: a helper is an implementation of a set constraint (Set Constraint Helper).
  • Central facts model: a helper is used for a set-based calculation of derived facts (Business Rule Helper).

HSTGIN is the abbreviation of Historical STaging IN. It is an older term to indicate the Logical Validation Model or Logical Validation Layer.

A schema is a set of database objects, such as tables, views, triggers, stored procedures, etc. In some databases a schema is called a namespace. A schema always belongs to one database. However, a database may have one or multiple schema's. A database administrator (DBA) can set different user permissions for each schema.

Each database represents tables internally as <schema_name>.<table_name>, for example tpc_h.customer. A schema helps to distinguish between tables belonging to different data sources. For example, two tables in two schema's can share the same name: tpc_h.customer and complaints.customer.

A Tenant is a delivering party for a dataset or datarecord as agreed in the Delivery Agreement.

TSTGIN is the abbreviation of Technical STaging IN. It is an older term to indicate the Technical Model or Technical Staging Layer.

An index organizes data in a way that improves the speed of data retrieval from a database. To maintain the index data structure, there is a cost of additional writes and storage space.

An index organizes data in a way that improves the speed of data retrieval from a database. To maintain the index data structure, there is a cost of additional writes and storage space.

The acronym CRUD stands for create, read, update, and delete. These are the four basic functions of persistent storage.

OLAP is a acronym for Online Analytical Processing. OLAP is category of software tools which provide analysis of data for business decisions. It uses complex queries to analyze aggregated historical data from OLTP systems.The primary objective is data analysis and not data processing.

OLTP is a acronym for Online transaction processing. OLTP captures, stores, and processes data from transactions in real time. Its primary objective is data processing and not data analysis.

A hub or independent entity is an entity that implements an Anchor for a business key that ‘stands alone’ e.g. that does not contain a reference to another entity. An independent entity contains business key fields, that show up as alternate key (AK), and the primary key (PK) is its surrogate key (ID).

A key is a combination of one or more attributes of an entity that uniquely defines one instance of that entity.