This documentation is for an older version of GoodData. Go to the latest version.

Create a Logical Data Model

Once you have created a physical data model (PDM), use it to generate a logical data model (LDM).

The LDM represents relationships between data objects in a workspace. The LDM provides a layer of abstraction so that you do not have to interact directly with the relational model of your database using SQL. The relational model is represented by the PDM.

Learn how the PDM Is Transformed to the LDM

When a declarative definition of the LDM is generated, certain rules are applied that affect how LDM entities are created based on the PDM. Understanding these rules will help you adjust your database and make the process of generating the LDM smoother and more accurate.

Default Configuration

By default, entities for the LDM are derived from the PDM based on data types assigned to table columns and referential integrity in the database.

LDM Entity	Expected Database Entity
Dataset	Table, view
Attribute	`CHAR`-like, `INT` columns
Fact	`NUMERIC`-like columns
Date dataset	`DATE`, `TIMESTAMP` (`TZ`) columns
Grain	`PRIMARY KEY`
Reference	`FOREIGN KEY`

Note

Date and timestamp table columns must be of the DATE or TIMESTAMP (TZ) data type to be imported as a date dataset. String columns cannot be imported as date datasets.

The default configuration has the following limitations:

It always reads the whole PDM; you cannot select just a part of the PDM to read.
It cannot detect advanced LDM entities such as attribute labels.
It cannot generate facts from columns with the INT data type.
It cannot generate grains and references if referential integrity is not maintained in the database.
It cannot generate proper LDM entities (such as facts, labels, and so on) from columns with incorrectly defined data types.

To overcome these limitations, use the naming conventions in your database to make sure that PDM entities are identified and interpreted correctly regardless of the column data types and referential integrity.

Database Naming Conventions

Use the following naming conventions to name objects in your database:

Entity	Name Format	Example
Table/view (standard)	`tablePrefix__baseName`	`gd_table__customer`
View	`viewPrefix__baseName`	`gd_view__customer`
Label	`labelPrefix__attributeBaseName__labelBaseName`	`ls__country_id__country_name`
Fact	`factPrefix__baseName`	`f__sales_amount`
Grain	`grainPrefix__baseName`	`gr__id_customer_pk`
Reference	`referencePrefix__tableBaseName__referenceBaseName`	`r__customer__surname`
Workspace Data Filter	`wdfPrefix__baseName`	`wdf__region`

The prefixes (tablePrefix, labelPrefix, and so on) are not case-sensitive.

Workspace Data Filter is used to filter data in workspaces. To learn more, go to Workspace Data Filters. Attributes and labels are not generated for columns that have been filtered using the workspace data filter.

Separators

In the table above, a double underscore (__) is used as a separator between prefixes and entity names, or between separate sections of reference names and label names. Note that in an API request for generating the LDM, you can define any string as a separator.

We recommend that the string you want to use as a separator be as unique as possible. Consider the situation when you use an underscore (_) as a separator and you have a column named referencePrefix_table_1_fk_column. This column name cannot be split into three sections as it would be required (prefix, referencedTable, referencedColumn).

Naming Conventions vs. Referential Integrity

Do not apply the naming conventions to the columns that are used as or are included in a primary key or a foreign key in your database. Such columns will be interpreted as grains and references based on referential integrity.

Entity Names in the Generated LDM

In the generated LDM, entity names and descriptions are generated based on the corresponding column names. To make an entity name more human-readable, the following happens when the entity name is injected into the LDM:

The prefix is removed from the name.
The first character is upper-cased.
Any non-alphanumeric character is replaced by a space.

Column Name in PDM	Entity ID in LDM	Entity Name in LDM
`gd_table__customer`	`customer`	`Customer`
`customer.f__amount`	`customer.amount`	`Amount`
`customer.ls__customer_key__customer_name`	`customer.customer_name`	`Customer name`
`customer.region_name` (attribute)	`attr.customer.region_name`	`Region name`

Duplicate label IDs may be generated for different columns in the same table in the database (and eventually for different labels in the corresponding dataset in the LDM).

For example, both lineitem.ls__customer_id__url and lineitem.ls__supplier_id__url will be transformed into lineitem.url.

While an LDM with duplicate label IDs can be generated, publishing this LDM will fail.

To avoid this situation, make sure that the base label names distinguish from each other, for example:

Use lineitem.ls__customer_id__customer_url instead of lineitem.ls__customer_id__url so that the label ID is generated as lineitem.customer_url.
Use lineitem.ls__supplier_id__supplier_url instead of lineitem.ls__supplier_id__url so that the label ID is generated as lineitem.supplier_url.

Generate LDM Automatically

Generating the LDM automatically is suitable for quick onboarding and exploring the content of your database or if your database is prepared for building analytics and does not contain the complex analytical scenarios.

You may generate your LDM using on of the following methods:

Create LDM Manually

For complex analytical scenarios, you may need to create an LDM manually in the LDM modeler.

Generate a Physical Data Model Using the API

Generate a Logical Data Model In the LDM Modeler