The fundament of any application is a model of the data that it manages. An application can manage many different kinds of data, we call a kind of data a model. A model describes some data entity that your application deals with. If you are accustomed to databases a model is the equivalent of a table or if you’re an Excel-user the equivalent is a sheet. Just like a sheet in Excel has cells and database-table has columns an Appivo-model has a number of attributes. Each attribute has a type, common types are strings, dates and numbers. We will go into more details about this below.

When you start building an app your model page will be empty.

Description of fields:

Fields
Description
Counters
Counters can be used in conjunction with Data Models.They are useful when managing data that needs to automatically increment, like invoice numbers or order numbers.
+ New Model
New Model adds a new model to the visual model builder canvas.
Layout
Layout automatically adjusts the layout and zoom level in an attempt to optimize the layout.
Manual layout controls
Manual layout zooms in/out or snaps to the center of the graphical model layout. Grab the canvas with your mouse to move it.
List
List switches between the graphical model depiction and a simple list of models.

To add a new model, click New Model and fill in the fields in the dialog box.

Description of fields:

Fields
Description
Name*
Enter the name of the model. Model names must be unique within an app. The model name contains alphanumeric characters and no spacing.
Type
Type
Data is a model type that stores specific inputs or attributes.
Document is a model type that stores files like images or attachments.
Model Creation
Model can be created in three ways:
-From Scratch – This allows the developer to completely define a model
-From Template – This allows the developer to choose from predefined templates like Customer, Order and OrderRow.
-From Import – This allows the developer to extend other applications by linking to data models of Extensible applications.

required*

Data Modelling

When building an application we need to describe to the platform what our data looks like. That is how a developer defines an application data structure, and is very similar in concept to database tables. A kind of data, like a car has a set of properties – a car will have a make, a model and year model and potentially several more properties – each of these properties in turn have a kind – integer, date, string etc. Her’s an example of a model describing a car, with its attributes listed:

One of think of model as a recipe for describing the data we want to manage. We call an actual piece of data a record. A record is of a certain kind i.e belonging to a model. Here is an example of a record of our cars.

Consider this analogy of a spreadsheet as a model where each column is an attribute and each row is a record and each cell would be an attribute value for a specific record. The columns have names and types, just like an attribute and the rows have values – just like a record.

ManufacturerModelYearModelAcquired
FordMustang200508/20/2005
VolvoV90201805/05/2018
AudiRS6202012/24/2020
MercedesS500201010/10/2010

A model can have a large number of attributes, there is a limit but it depends on the type of columns being used. The most important limitation is that of record-size as a single record cannot occupy more than 64Kb of data, typically most space is consumed by strings.

Aside the attributes that you add to your model the system enforces a set of system attributes, they are:

NameData typeDescription
idIDThe primary key – serves as globally unique identifier for a record.
created_atDate & TimeDate & Time for when the record was created.
updated_atDate & TimeDate & Time for when the record was last updated.
ververThe records version-number, increments by one every time the record is updated.

Models (Data)

A model of type Data consists of one or more developer-defined attributes. An attribute is the smallest piece of data that we manage, an attribute is a property of something bigger – a model. Attribute names must consist of letters and numbers (no spaces or symbols), and must be unique within a Data Model. When we add the first model, we can see the beginning of a model relationship diagram. Each attribute has a name, type, required status and default value, in addition to other characteristics that can vary amongst attribute types.

To manage attributes, edit the model then drag the appropriate attribute type from the right-hand menu.

If your application needs to store documents – binaries such as images, videos, word-documents etc then you can make use of document models. A document model is a model that aside from being able to store attributes just like ordinary models also stores a binary.

Attribute

An attribute is the smallest piece of data that we manage, an attribute is a property of something bigger – a model. Attribute names must consist of letters and numbers (no spaces or symbols), and must be unique within a Data Model.

Attribute Types

There are a number of attribute types:

String

String represents a piece of text that can hold up to 8000 characters.

String

Description of fields:

Fields
Description
Name
Enter the name of characters like ABCxyz1223&$#.
Required
Marking this field makes this attribute mandatory when entering input for this model.
Secret
Marking this field means that the value will never be visible to the outside world. It can only be accessed internally – in back end code.
Personal
Marking this field indicates that this attribute holds Personal Identifiable Information (PII).
Type
Use the type field to change the attribute type if necessary.
Maximum Size
Enter the maximum size, up to 8000 characters.
Default Value
This input will be displayed as a default value for this attribute and will be included when saving new records of this model unless changed.

Integer

An integer represents a positive or negative numeric value that is not a fraction or decimal. For example -2147483648 to 2147483647 or unsigned values from 0 to 4294967295.

Integer

Description of fields:

Fields
Description
Name
Enter the numbers.
Required
Marking this field makes this attribute mandatory when entering input for this model.
Secret
Marking this field means that the value will never be visible to the outside world. It can only be accessed internally – in back end code.
Personal
Marking this field indicates that this attribute holds Personal Identifiable Information (PII).
Type
Use the type field to change the attribute type if necessary.
Unsigned
Selecting this option means that the number carries no sign and can only be positive, which doubles the range of positive integers that can be held.
Default Value
This input will be displayed as a default value for this attribute and will be included when saving new records of this model unless changed.

Float

Float represents a floating point value, or to put it simply, it’s a decimal number. This is a normalized, double precision floating point number that can hold up to approximately 15 decimal digits.

Float

Description of fields:

Fields
Description
Name*
Enter a decimal number.
Required
Marking this field makes this attribute mandatory when entering input for this model.
Secret
Marking this field means that the value will never be visible to the outside world. It can only be accessed internally – in back end code.
Personal
Marking this field indicates that this attribute holds Personal Identifiable Information (PII).
Type
Use the type field to change the attribute type if necessary.
Decimals*
Enter the number of decimals to the right of the decimal point.
Unsigned
Selecting this option means that the number carries no sign and can only be positive, which doubles the range of positive integers that can be held.
Default Value
This input will be displayed as a default value for this attribute and will be included when saving new records of this model unless changed.

*required

Boolean

Boolean represents a binary value, stating true or false.

Boolean

Description of fields:

Fields
Description
Name
Enter a binary value.
Required
Marking this field makes this attribute mandatory when entering input for this model.
Secret
Marking this field means that the value will never be visible to the outside world. It can only be accessed internally – in back end code.
Personal
Marking this field indicates that this attribute holds Personal Identifiable Information (PII).
Type
Use the type field to change the attribute type if necessary.
Default Value
This input will be displayed as a default value for this attribute and will be included when saving new records of this model unless changed.

Date

Date represents a calendar date without an associated time.

Date

Description of fields:

Fields
Description
Name
Enter calendar date.
Required
Marking this field makes this attribute mandatory when entering input for this model.
Secret
Marking this field means that the value will never be visible to the outside world. It can only be accessed internally – in back end code.
Personal
Marking this field indicates that this attribute holds Personal Identifiable Information (PII).
Type
Use the type field to change the attribute type if necessary.
Default Value
This input will be displayed as a default value for this attribute and will be included when saving new records of this model unless changed.
-No Value
-Current Date
-Specific Value

Time

Time represents a time without a date.

Time

Description of fields:

Fields
Description
Name
Enter a time without a date.
Required
Marking this field makes this attribute mandatory when entering input for this model.
Secret
Marking this field means that the value will never be visible to the outside world. It can only be accessed internally – in back end code.
Personal
Marking this field indicates that this attribute holds Personal Identifiable Information (PII).
Type
Use the type field to change the attribute type if necessary.
Default Value
This input will be displayed as a default value for this attribute and will be included when saving new records of this model unless changed.
-No Value
-Current Time
-Specific Value

Date and Time

Date and Time represents a calendar date and a time.

Date and Time

Description of fields:

Fields
Description
Name
Enter a calendar date and a time.
Required
Marking this field makes this attribute mandatory when entering input for this model.
Secret
Marking this field means that the value will never be visible to the outside world. It can only be accessed internally – in back end code.
Personal
Marking this field indicates that this attribute holds Personal Identifiable Information (PII).
Type
Use the type field to change the attribute type if necessary.
Default Value
This input will be displayed as a default value for this attribute and will be included when saving new records of this model unless changed.
-No Value
-Current date & time
-Specific Value

State

State represents a value that defines users’ value.

State

Description of fields:

Fields
Description
Name
Enter the users’ defined value.
Required
Marking this field makes this attribute mandatory when entering input for this model.
Secret
Marking this field means that the value will never be visible to the outside world. It can only be accessed internally – in back end code.
Personal
Marking this field indicates that this attribute holds Personal Identifiable Information (PII).
Type
Use the type field to change the attribute type if necessary.
Default Value
This input will be displayed as a default value for this attribute and will be included when saving new records of this model unless changed.
Add State
Use the Add State button to add predefined values. For example, State attributes can be used to define stages of a process such as:
-Open
-In-Progress
-Closed

Coordinate

Coordinates represent values from the geographic coordinate system, longitude and latitude.

Coordinate

Description of fields:

Fields
Description
Name
Enter the geographic coordinate system.
Required
Marking this field makes this attribute mandatory when entering input for this model.
Secret
Marking this field means that the value will never be visible to the outside world. It can only be accessed internally – in back end code.
Personal
Marking this field indicates that this attribute holds Personal Identifiable Information (PII).
Type
Use the type field to change the attribute type if necessary.
Default Value
This input will be displayed as a default value for this attribute and will be included when saving new records of this model unless changed.

✰Note: A model can have a large number of attributes but there is a limit that depends on the type of attributes being used. The most important limitation is that a single record cannot contain more than 64KB of data. Typically, most space is consumed by strings.

Relationship

Our car model has an attribute called “Make” which represents the manufacturer of the car, what if we wanted to manage more details regarding the manufacturers ? We could ofcourse add more attributes for providing manufacturer details to our car model, like this. We will continue with our car model as an example.

Lets add the new attributes for our car record, it would look like this:

Now consider a case where we have hundreds or thousands of car records in our application, each record would state that ManufacturerCountry-attribute is USA if the Manufacturer-attribute is Ford. Seems redundant, doesn’t it ? As a general rule of thumb one should avoid such constructs when defining data models. Imagine that Ford would move all its manufacturing to say Canada, all those car records with Ford as manufacturer would now need to be updated – inconvenient. So how should one go about modeling such a thing ? Let us break up our car model in two models – Car and Manufacturer (imagine you have two excel-sheets – one for manufacturers and one for cars):

We have now split out the manufacturer attributes and placed them in its own model “Manufacturer” and we have introduced a connection between the two models – a relation. A relation has a few properties, or constraints if you will. A relation describes how one model relates to another, let’s look at a few examples to make it clear:

  • A car is made by one manufacturer but a manufacturer may make many cars
  • A country can have many car manufacturers and a car manufacturer can have factories in many countries.

Each end of the relationship has a cardinality. The cardinality dictates how many records can be at either end of the relationship, as the examples above describe this depends on the nature of our data. The Appivo platform has the following cardinalities:

Each end of the relationship has a cardinality. The cardinality dictates how many records can be at either end of the relationship, as the examples above describe this depends on the nature of our data. The Appivo platform has the following cardinalities:

Cardinality
Description
Zero to one
There can be one record or no record.
One
There must be exactly one record.
Zero to many
There can be any number of records, including no records at all.
One to many
There can be any number of records but at least one.

If you think of a relationship as a connection between two models we need to name the ends of that connection. Here’s an example to illustrate the point:

Let’s say we have two models Car and Person. We want to model that a Car is always owned by a Person and that a Person may own many cars. Since it is ownership that we are modeling here we will could name the ends of the relation like this:

From the Persons point of view – he/she has a set of OwnedCars and from the Cars perspective it is Owned. The names of the relation ends have several uses, for instance when building queries.

Ownership

Finally, there’s a concept of ownership in a relation, this is not to be mixed up with the fact that we had car ownership as an example above. The right way to think of ownership in terms of a relation is instead whether a record of a model can exist on its own, without being related to the other model.

In our example above a Car doesn’t necessarily have to be owned by a Person and a Person doesn’t have to own a Car – though it should be said that this is a decision that you as the application developer will have to make as it depends on what rules you want to enforce in your application.

Lets take another example to see where ownership is needed. Consider a case where we are modeling invoices, a trivial model of an invoice could look like this:

We have two models – the Invoice model which keeps the data you would typically find in the top part of an invoice – invoice-number, customer and probably an adress etc. The other model represents the individual rows of the invoice – each row mentions an article, a quantity of that article and the unit price of the article. This is a common way to model invoices. The purpose of this example was to illustrate the concept of ownership however. Remember that earlier we said ownership is a way to declare whether records of a model can exist on their own or not. So lets ask ourselves a couple of questions:

  • Can an Invoice exist without having any InvoiceRows ? Most likely an invoice will always have rows but it seems OK for it to exist without any.
  • Can an InvoiceRow without being related to an Invoice ? No, this makes no sense at all – the invoice row by itself is fairly meaningless.

So having the answers to these questions we can conclude that there appears to be an ownership aspect in this model – Invoice owns InvoiceRows as they cannot exist by themselves. There is a functional aspect of this ownership – when you delete an Invoice the system will automatically delete the related InvoiceRows since they are not allowed to exist by themselves without violating the rule that we created.





Up Next

No Topics.