Xively's data model

When using the Xively platform, you model your connected product business in Blueprint. The Blueprint model provides the foundation for the platform to deliver advanced IoT services such as security and connected product management via the Xively management app.

Defining the data model for a connected product system is an important initial design step.

The Xively "Blueprint" database

The Blueprint database is an object database. Conceptually, the objects can be represented as JSON objects. Each object has a unique identifier in the form of a GUID.
The types of objects (entities) in the Blueprint database are:

  • channels
  • devices
  • end-users
  • organizations (called "groups" in the Xively management app)

A connected product system's Blueprint schema is defined by templates and custom fields.
Templates are used to represent different types of devices, users, and organizations (groups). For example, you would typically define a device template for each type of product in your connected product system. Similarly, a user template would be defined for each type of user, and an organization template for each level in the organization hierarchy.

The organization (group) hierarchy represents the structure of objects in your application's business domain. The hierarchy can be five levels deep, with no set limit on the number of children for a parent. Typically, the top-level organization is used to represent a customer of the connected-product company, and lower level organizations represent how a customer of the connected product company groups and manages the connected products. For example, if the connected product is a thermostat, the top level organization could represent a thermostat company's customer, and the child organizations could represent the locations where the thermostat are installed (such as homes), the next child level organizations could represent the floors in the home, the next the rooms, etc.

Data from device sensors is sent over channels. Typically, each sensor belonging to a particular device has its own channel, but channels also may be used by applications to partition message traffic, for example by flags in the message payload. It is an application decision how many channels make sense for the connected product system.

Custom fields allow you to extend the Blueprint model by adding custom fields to Blueprint entities. You define the data types, whether the fields are required, and any default values. Custom fields are added to entities by adding them to the template for the entity.

The Xively management app can be used to configure and maintain the Blueprint schema for your connected product system. The schema also can be managed through the API.

Using your own databases with Xively

If the Blueprint model needs to be extended with custom entities, an external database can be used. The database can be relational or non-relational, depending on application requirements.
For example, if your connected product system is collecting data from devices, and you want to model that data with a custom schema that aligns with other business systems, you could define tables with that schema in an external relational database, and deposit data collected from devices into these tables.

Blueprint and external databases can be linked with foreign keys. For example, a one-to-many relationship between a Blueprint entity and an external entity can be represented by using a foreign key in the external database, where the foreign key is the Blueprint entity ID (the UUID). For a one-to-many relationship from the external database to Blueprint, the foreign key would be on the Blueprint side, so it would be defined as a custom field for the Blueprint entity.

Updated 3 years ago

Xively's data model


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.