Data Model

The Data Model application enables the creation of blueprints for your databases using a data modeling method. This approach ensures that the model:

Accurately represents the real-world structure of your database.
Maintains platform independence by allowing custom attributes beyond platform-specific ones.

Models are essential for:

Defining data structures before the actual implementation: Clearly outline entities, attributes, and relationships during the design phase of the data solution change process.
Standardizing terminology: Ensuring that everyone in the organization understands and uses consistent definitions.
Tracking changes and alignment: Helping teams monitor whether models match real-world implementations.
Enhancing governance: Supporting compliance and decision-making by making data assets transparent and traceable.

General overview

Configuration with respect to data model layers: Conceptual - Logical - Physical Model

The Data model application can handle different types of data modes and manages the relationships between them. The core focus for blueprint implementation is on the logical and physical models, which define what needs to be managed.

The conceptual model is usually solved separately in other Dawiso applications, which cover broader definitions of business metadata applied for various use cases within Dawiso. For example, a business model could be in a simple way the business glossary application.

The linking of Data Model application objects to other business or technical metadata is typically a gradual process. It evolves according to the adoption and evolution of the customer’s data modeling methodology.

Tip

You can tailor the model to be more logical or more physical based on specific needs, thanks to configuration options, which include the customization of entity definitions (tables or views).

This allows for flexibility in structuring and managing data, such as defining specific physical properties of objects for the target platform.

Data Modeling: Common Challenges and Solutions

Data modeling is useful for structuring and managing data, but traditional methods often face the same challenges.

Challenge	Challenge description	Dawiso solution
Rigid models	When models are created before development, they usually aren’t flexible enough to adapt to fast development changes and hotfixes.	Dawiso supports iterative modeling, allowing models to be created before, during, or after developmentwithout risk of misalignment. This is achieved thanks to synchronization, ensuring that the model remains up-to-date throughout the development process., Workflow states that indicate if the object has been modeled and implemented., Validation checks that compare the model against the actual database and highlight discrepancies., Flexible environment customization, allowing additional attributes specific to the organization or technology.
Outdated models	When modeling happens simultaneously with development, changes might not be consistently reflected, leading to and, Loss of trust from business users and data analysts in the model.
Lack of updates	Once a database is implemented, updating the model often becomes an afterthought, leading to misalignment.
Collaboration issues	Many desktop modeling tools restrict access to a single user at a time, making parallel work difficult.	By being a web-based tool, Dawiso allows multiple users to work on models simultaneously.
Insufficient domain support	Many tools either do not support domain creation or do not encourage its use, leading to underutilized potential.	Dawiso promotes domain usage by simplifying creation through automatically generated domain candidates, making it easier to establish and manage domains.
Lack of attribute sharing	Traditional modeling tools often store models in separate files, preventing domain attributes from being shared across multiple models.	Dawiso enables shared domain attributes across models within the same space, ensuring reusability. Attributes are shared as embedded text, meaning any changes are reflected across all linked objects for consistency, while maintaining flexibility by allowing individual columns to have additional details.

Data Model object types

The Data Model application organizes information into three main categories of object types: models, domains, and codelists, each containing their own specific child objects (see diagram).

The Data Model application acts as a blueprint for your database, allowing you to structure it to fully match your reality.

Tip

This flexibility is especially evident in codelists, where object types are fully customizable. You can add, remove, or modify codelist types to serve as object labels based on your specific needs.

In our example application, the Sensitivity and Stereotype codelists are used, but the number of codelists can vary (you can add e.g., Historization Kind).

There can be fewer, more, or entirely different codelists depending on your use case.

The diagram below illustrates all available object types and their relations within the Data Model application. The hierarchy defines not only object paths, but also directly influences navigation in the left panel.

In this section, we will explain:

The purpose and structure of each object type
The attributes associated with these object types
The relations between these categories

inline-svg-1

Models

Models contain the following object types:

Object type	Description
Model Folder	Folder-type object that serves as a container for organizing and managing data models through a structured table format.
Data Model	Structured data model that defines entities and attributes.
Data Entity	Representation of a data object like a table, view, parquet file, or other dataset-like structure objects.
Data Attribute	Representation of a data attribute, such as a table column, view column, parquet file attribute, and other column-like data structures.
[Optional] Processing Unit	Representation of executable code components (procedure, macro, etc.) that require management, versioning, and sharing.

Domains

Domains contain the following object types:

Object type	Description
Data Domain Folder	An overview object type designed for managing and standardizing data domains, which provides a list of data domains, Automatically identified domain candidates
Data Domain	Automatically created categorization of Entity Domains and Attribute Domains.
Entity Domain	Definition of a set of entities that share common characteristics, grouping them based on their functional or logical similarities.
Attribute Domain	Representation of a logical grouping of data, ensuring consistency across similar attributes.

Codelists

Codelists contain the following object types:

Object type	Description
Codelists Folder	Folder-type object for all available codelists, which can be used as attributes or features within both domains and models.
Code List	Set of predefined values that can be used as features or attributes in both models and domains.
Code List Value	Predefined value that can be used as a feature or attribute.

Relations between Data Model object types

The diagram below represents the relations between Models, Domains, and Codelists within the Data Model application.

inline-svg-2

Key Relations

Many-to-Many Relations:
- An object in a single domain can be associated with multiple models, and one model can reference objects from multiple domains.
- Similarly, codelists can be used across both models and domains, ensuring consistency in attribute classification.
Features/Attributes Flow:
- The arrows labeled “Features/Attributes” indicate that codelist values act as attributes or classifications within both models and domains.

Domain vs Model vs Scanned objects

Dawiso aligns different object types across three key contexts: the domain level, the data model level, and the scanned catalog level. This mapping ensures consistency and clarity when working with information at different abstraction/implementation levels.

inline-svg-3

Tip

To understand how objects in models reflect scanned objects using synchronization, see Data Model Workflow Logic.

The table below provides a complete mapping of object types across these contexts:

Domain	Model	Scanned Catalog
Data Domain	Model	Schema / Database / …
Entity Domain	Entity	Table / View / Parquet file / …
Attribute Domain	Attribute	Column / View Column / Parquet attribute / …
-	Processing unit	Procedure / Macro / Executable / …
For example:

An Entity Domain in the domain layer corresponds to an Entity in the model, which in turn maps to a Table, View, or Parquet file in the scanned catalog.

Data Model workflow logic

The workflow states indicate the alignment between scanned objects, documentation, and the model, helping users track the status of each object.

Implemented: The object is documented and reflected in the model, meaning it is fully integrated.
Valid for Implementation: The object is not documented, but it is reflected in the model.
Implemented Draft: The object is documented, but not yet reflected in the model, meaning it exists only conceptually.

Workflow State Inheritance

In the Data Model application, workflow state changes propagate down the hierarchy, ensuring consistency across related objects:

Changing a model’s workflow state will apply the same state to all its entities and attributes.
Changing an entity’s workflow state will apply the same state to all its attributes.

Tip

Workflow states do not restrict user access or permissions.

Editing rights are determined by space permissions, meaning users can modify objects based on their assigned access level, regardless of the object’s workflow state. This approach ensures that data analysts and other modelers always have access to all models within their designated space.

The prebuilt workflow is fully customizable to fit the client’s specific methodologies or needs.

Workflow Diagram

Below, you can see a diagram illustrating the workflow within the Data Model application.

Tip

To find this workflow diagram in your Data Model application, simply:

On any object, click on the workflow state.
Select Show workflow.

Adding a Data Model to your space

To start using the Data Model application, first add it to your space.

In your space, click in the top-right corner and select Add application.
Select the Data model application and choose your workflow.

Now we can move onto adding models, domains, codelists, and more.

Adding a Model

Let’s start with creating a model of your database or schema.

In your Data model app, click Create in the top navigation bar to add an object.
First, add an object with the Model Folder object type. This will serve as an organizational unit.
While in your Model Folder, click Create in the top navigation bar to add a Data Model object.

Tip

You can also create an object using the following ways:

In the top-right of your app, click.
In the left-side hierarchy click the three dots next to an object and select in the top-right corner and select Create object to add its child object.
In the object header click the three dots on the right side and select in the top-right corner and select Add child object.

Once you’ve created your model, there are three ways to add entities (tables, views, etc.) and attributes (columns).

Manually add entities and attributes directly in Dawiso
Link database scanned in Dawiso to your model
Import entities and attributes using an Excel file

Let’s take a closer look at these methods.

1. Manually Adding Entities and Attributes

Use the Create button in the top navigation bar to add individual Data Entity and Data Attribute objects. Keep in mind that Data Attributes are always child objects to Data Entities.

2. Linking a Scanned Database

The second method allows you to link the newly created model to a real schema or database that was scanned in Dawiso.

In the right-panel, find the Implemented as section.
Click on and select your database.
The Is Model Of relation will be automatically applied.

3. Import Entities and Attributes Using Excel

Import an Excel file with all entities and attributes. For more information, see the Object import & exportarticle.

Creating Relations (Entity Relations Diagram)

On your Data Entity and Data Attributes object pages, you will find entity relation diagrams which visualize the connection between various entities and attributes.

You can customize the diagram to fit your needs by adding more relations or editing the diagram.

To add a new relation:

Find the Foreign Key section and click in its corner.
Find the object you want to create a connection to and select the relation type: foreign key parent or foreign key child.

Tip

Dawiso allows you to find objects using their unique object URLs. This provides precise object identification, especially when multiple objects share the same name.

In our example, we added a foreign key parent.

Editing a diagram

Dawiso allows you to make changes to an existing diagram and save it as a new diagram without altering the original.

You can save your new diagram in two ways:

In a Diagram Folder: Create a Diagram Folder object and place it where you want to store and categorize your diagrams.
Without a Folder: Save the diagram directly, but it will not be categorized and will appear in the left hierarchy without a designated folder.

When creating a Diagram Folder, you can place it on the same level as other Folder object types or directly under the model to which the diagram belongs.

Once you have your folders, you can start editing your diagrams:

Switch to the Edit mode (top-left corner).
Make your changes. You can add annotations, add existing objects to the diagram, etc.
Click Save as new to save your changes.

Tip

For more information on working with diagrams, refer to our article on Diagrams.

Data Domains

Once your model is fully created, it is time to create Domains. We will create Attribute Domains that gather all columns of the same name in one list, which allows you to:

Create and spread the same description attribute (definition or rules) as embedded text to all of them instead of manually adding descriptions to each column. Any changes will be reflected automatically in all descriptions using the embedded text.
Check all data types against the modeled data type to make sure there aren’t any discrepancies. In case of discrepancies, you can use mass edit to change all incorrect columns.

First, let’s learn how to create domains.

In your Data model app, click Create in the top navigation bar to add an object.
Create an object with the Data Domain Folderobject type, which serves two main functions:
- It generates a list of frequent attributes, in other words attribute domain candidates.
- It contains a list of Data Domains which categorize attribute domains.

The list of domain candidates is ordered according to the number of appearances.

Attribute Domain Candidates

Once attribute domain candidates are selected and accepted, users can assign alternative names to each attribute domain. This feature enhances flexibility in synchronization by allowing multiple recognized names for the same domain attribute.

You have a database with a Party_Id column. However, the domain uses a business name like Party Identification or Party ID, which don’t match the column name.

To make sure the column is associated with the right domain, we can add the column name to the domain’s alternative names.

Alternative names: Client_Id, Party_Id

Tip

Alternative names are separated by commas. For example, Client_Id, Party_Id are two alternative names for the same domain.

Domain Synchronization Process

The synchronization process ensures that domain attributes remain aligned with attributes in the model. To maintain consistency across objects:

During synchronization, all domain attributes are added to corresponding attributes in the model.
Synchronization can be triggered manually or scheduled to run at regular intervals.
If a value assigned to a domain is manually modified after synchronization, the attribute will become desynchronized, meaning it no longer follows the domain standard.
Column can be deleted from the domain and become desynchronized.

Model alignment: Ensuring quality & monitoring

Data Model documentation overview

The Data Model application provides you with key insights into the current state of the objects, ensuring visibility into ingestion processes, object statuses, model quality, and ownership details.

When you first select your app within your space, or when you click on the app name in the top-left corner, you will access the Data Model application’s overview.

Tip

All overview sections are fully customizable, allowing users to tailor the displayed information based on their specific needs.

Objects Overview Tab

Provides a list of all objects in this application within the current space.

Model Quality Tab

Provides a quick overview of:

Domain Coverage: Tracks the percentage of columns with domains.
Implementation Gaps: Identifies how many objects have been implemented but not documented.
Modeling Gaps: Shows how many objects have been modeled but not implemented.

Here, you will also find a table with discrepancies, which highlights differences between the domains, models, and reality.

Ownership Tab

Displays a summary of key roles (architects, stewards, analysts).
Includes a table listing objects you are responsible for.