Best Practices: Data Modeling

Estimated Reading Time:  7 minutes

Overview

Data Models are visual representations of an application's data. Like a building has a blueprint, your application has a data model. Data Models use tables, lines, and symbols to outline the application's data structure. Whether you're building or troubleshooting an application, data models are an important resource.

At the most basic level, data models have three parts:

• Entity: A real-world object, represented by a table.
• Attributes: Characteristics of the entity, represented by rows in the entity's table.
• Relationships: How the entities relate to each other, represented by lines and symbols.

The Purpose of Data Modeling

Building a data model helps you visualize the modularity of your application. Determining the relationships between your data helps you visualize your application. It helps you group data and determine which information passes between data sets. Data models can also help you organize your application into smaller modules. If efficiently modeled, you can even reuse these modules throughout other applications. It becomes a single source of truth.

Some benefits of data models include:

• Ensuring that the data objects created in Unqork align with the external database.

• Helping with database design at a conceptual, physical, and logical level.

• Helping to identify missing or redundant data.

• Making IT upgrades and maintenance cheaper and faster.

Types of Data Model

Data model creation is the process of deciding what type of data to capture, how to capture it, and how to store it. It's best practice to build your data model in stages.

The following data model types represent the different building stages:

1.

Conceptual Model

2.

Logical Model

3.

Physical Model

You'll start by creating a basic, Conceptual Model. As you start building out the specific data architecture, you'll add logic (Logical Model). You now have the structure for your physical database (Physical Model).

NOTE  All data models used in this article are built using Lucidchart.

Conceptual Model

A Conceptual Model is the simplest type of data model. To create a Conceptual Model, the data architects meet with the business stakeholders. Together they determine what data to capture and how to capture it.

As an example, look at a simple marketplace application. The entities are Customer, Transaction, and Product.

Logical Model

The Logical Model is more intricate than the Conceptual Model. Here you'll include the structure of the data objects and set relationships between them. You'll also flesh out the attributes of each entity.

Physical Model

The last stage of building a data model is the creation of the Physical Model. The Physical Model is thorough enough to use as your application's blueprint. You can also see this type of data model referred to as an entity-relationship diagram.

Data Modeling Symbols

Data models include more information than just the data objects. The symbols and styles used in the model convey more information. It's best practice to use these symbols and styles to help you read and create comprehensive data models.

Looking at a data model, you can determine the:

• Cardinality and ordinality

• Primary keys

• Foreign keys

• Data types

NOTE  There are other data model styles, but this list of styles is common to entity-relationship diagrams.

Cardinality and Ordinality

When looking at data models, you can see symbols on the relational lines. These symbols refer to the cardinality and ordinality.

• Cardinality: The maximum number of times an instance of an entity can relate to another entity.

• Ordinality: The minimum number of times an instance of an entity can relate to another entity.

A single customer can have many transactions. So, the customer entity can relate to the transaction entity many times. Conversely, a transaction can only relate to a single customer. One transaction doesn't have many customers, but one customer can have many transactions.

Look again at our earlier example to see how the data model represents this relationship. In the following image, the single vertical line near the Customer entity represents one. The symbol attached to the Transaction entity represents many.

Common Cardinality Symbols

The following are common cardinality symbols used in data models:

One

Many

One (and Only One)

Zero or One

One or Many

Zero or Many

Primary Keys

A Primary Key performs 2 functions:

• It ensures that an entity's records are unique.

• It links one entity's records to the records of another entity.

In a typical data model, you'll use a bold font format applied to your primary keys. In the Customer entity shown below, the customerEmail is the primary key.

Any data that uniquely identifies an entity can serve as the primary key. For a customer's account, email address and unique user ids are the most common primary keys.

Foreign Keys

Foreign keys refer to the attributes of one entity pointing to the primary key of another entity. They act as a cross-reference between entities. In a typical data model, it's best practice to use italics to represent foreign keys.

If you look at the Transaction entity, you can see customerEmail and productId data objects. These italicized data objects are your foreign keys.

Data Types

Some data models include an attribute's data type. It's best practice to display these data types in parentheses next to the data object. In Unqork, the data type might be any of the following:

• Text/String

• Number

• Boolean

• Array

• Object

Building Applications Based on Data Models

Now let's see how a data model can translate to an Unqork application. Say you build an Unqork application for an insurance client. The application lets a customer buy insurance products from their website. The client already has a database set up. So, the data coming out of your Unqork application must match the client's database.

You can use the earlier data model to guide you in your application creation. Here's the data model again for reference:

To create a secure application that collects this example's data, you'll use 10 modules. Four of these modules are front-end modules. The other 6 modules are API (application programming interface) and schema modules. The API and schema modules use remote execute functionality. These 6 modules work in the back-end to capture and transfer data. They also keep your application secure.

You can find all the modules in the following workspace: https://training.unqork.io/workspaces/5f8e40a7d2b8870237a2270c/applications/602d9f5a0167540a815ddc4f/modules.

NOTE  To this use case, you'll only review the front-end modules.

Create New Customer - Front End Module

The Create New Customer - Front Endmodule is where your customer creates their account. After your customer completes this module, they'll click Save. This module collects all attributes in the Customer entity. Note that the Email field serves as the primary key.

Create Product - Front End Module

Using the Create Product - Front Endmodule, you can create insurance products, assigning them a name and price.

After creating the product, the API module creates a submission ID for the product. The submission ID is the productId.

Create New Transaction - Front End Module

The Create New Transaction - Front Endmodule references the data collected in the previous modules. Using this data, the New Transaction module creates a new transaction.

First, your customer enters their email address (the primary key). If they haven't created an account yet, they're redirected to the Create Customer module.

If they already created an account, they see the product options. In the drop-down field, they select which policy to buy. The price field populates on selection of a policy.

When the customer clicks Purchase, the module creates the transaction ID. The transaction ID stores to the database.

Admin Dashboard Module

Finally, the Admin Dashboard module is where you find all your data. Your data model objects (Customer, Transaction, and Product) show in your dashboard. Go to the Transactions section to see your customerEmail and productId foreign keys.

Module Links

Here is the link to the workspace with all the modules for this application: https://training.unqork.io/workspaces/5f8e40a7d2b8870237a2270c/applications/602d9f5a0167540a815ddc4f/modules.

Or, here are the links to each module in this application:

Module	Link
Create New Customer - Front End	https://training.unqork.io/#/form/5ea9be9b154605020f1e3b85/edit
Create New Customer - API	https://training.unqork.io/#/form/5ea9fbac811bf80215fd68d6/edit
Customers - Schema	https://training.unqork.io/#/form/5ea9fbba811bf80215fd68d8/edit
Create Product - Front End	https://training.unqork.io/#/form/5eaa10ff154605020f1e3be5/edit
Create Product - API	https://training.unqork.io/#/form/5eaa111710b428020e383876/edit
Products - Schema	https://training.unqork.io/#/form/5eaa1135154605020f1e3be8/edit
Create New Transaction - Front End	https://training.unqork.io/#/form/5eaa1577d4a8b50214c3fded/edit
Checking Existing Customer - API	https://training.unqork.io/#/form/5eaa168a811bf80215fd68f1/edit
Create New Transaction - API	https://training.unqork.io/#/form/5eaa1ad4154605020f1e3bee/edit
Transactions - Schema	https://training.unqork.io/#/form/5eaa1b6a10b428020e38388b/edit
Admin Dashboard	https://training.unqork.io/#/form/5eab609e811bf80215fd6d76/edit