Entities

Overview

Entities are the high-level business objects in your enterprise. For example, employee, product, purchase order, or department.

In MarkLogic Data Hub, you can use MarkLogic's Entity Services to create models of your business entities and to generate code scaffolding, database configurations, index settings, and validations based on those models. Entity Services handles the model definition and entity instance documents through API calls. If you use your own abstract entities, you must provide this framework.

Note: MarkLogic strongly recommends that you use Entity Services unless you have specific needs that it cannot address.

An entity model is comprised of entity types.

An entity type is a data type to which each record of your data will be standardized, so that data from all sources can be viewed and used uniformly. An entity type is comprised of entity properties.
An entity property is a data field in a record of your data.
An entity instance is a copy of the entity type structure, which is added to your data record during mapping and then populated with values from the raw data.
An entity feature is a data characteristic of an entity type that you can add to implement special functions. An entity feature can be defined in an entity type and a step.

All the data about an entity is consolidated in a single record, which contains the standardized entity instance, the original raw data, the provenance and lineage, and other metadata. The provenance and lineage information includes the changes that occurred from the raw data to the most recent entity instance.

Note: An entity model is not required to ingest your raw data. However, it is required to configure your mapping.

See:

Modeling with Hub Central

Entity Model Validation

Only valid entity models are loaded into the MarkLogic Server instance. A valid entity model meets the following requirements:

info/baseUri in the model must have a value that is a valid URI.
The model must pass the Entity Services validation function es:model-validate.

If the entity model is valid and loaded, Data Hub creates the following in the STAGING and FINAL databases:

schema files:
- /entities/YourEntityName.entity.json. The validated entity model returned by es:model-validate.
- /entities/YourEntityName.entity.schema.json. The entity model as a JSON schema for use in XDMP validation (xdmp.jsonValidate).
- /entities/YourEntityName.entity.xsd. The entity model as a XSD schema for use in XDMP validation (xdmp.validate).
a TDE template (/tde/YourEntityName-YourEntityVersion.tdex) with the following permissions:
- read permissions for the data-hub-operator
- update permissions for the data-hub-developer
- default permissions allowed to the user who loaded the entity model to MarkLogic Server
Important: In MarkLogic 10 and later versions, a user assigned to the admin role only must be explicitly given read access to view the TDE template.

If a TDE template with the same URI already exists but is not in the ml-data-hub-tde collection, a new TDE template will not be created.

Guidance on Mapping Multiple Entities from a Single Source

The topics below illustrate how to create different types of entity relationships using the Hub Central one-to-many modeling and mapping tools.

Creating a 1:1 Relationship

You can create a 1:1 relationship between entities when an entity instance is related to a single other entity instance.

For example, the Customer entity is related to the BabyRegistry entity, and each customer maintains a single baby registry. The relationship is 1:1.

Here are the modeled entities before defining the 1:1 relationship:

Customer

customerId  integer

firstName   string

lastName    string

BabyRegistry

babyRegId   integer

arrivalDate date

To model the 1:1 relationship, define a property in one of the participating entities that points to the related entity. The other entity in the relationship is untouched.

Here, the BabyRegistry property is defined in the Customer entity:

Customer

customerId integer

firstName  string

lastName   string

created    BabyRegistry

Alternatively, a Customer property can be defined in the BabyRegistry entity:

BabyRegistry

babyRegId   integer

arrivalDate date

createdBy   Customer

Which entity the one chooses to hold the property may be based on the lifecycle or complexity of the entities involved.

When defining the mapping, point to the related entity's primary key to establish the relationship. Here is how the mapping is defined when the reference property is in the Customer entity:

Customer

customerId  /CustomerID

firstName   /Name/FirstName

lastName    /Name/LastName

created   /BabyRegistry/BabyRegistryId

Here is how it is defined when the reference property is in the BabyRegistry entity:

BabyRegistry

babyRegId   /BabyRegistry/BabyRegistryId

arrivalDate /BabyRegistry/Arrival_Date

createdBy   /CustomerID

Creating a N:1 Relationship

You can create a N:1 relationship between entities when one or more entity instances are related to one instance of another entity.

In our example, the Order entity is related to the Customer entity, and each customer can create multiple orders. Each order is associated with a single customer. The relationship is N:1.

Here are the modeled entities before defining the 1:N relationship:

Customer

customerId  integer

firstName   string

lastName    string

Order

orderId       integer

timestamp     dateTime

To model the 1:N relationship, create a property on the many (N) side of the relationship that points to the other entity. In our example, the Order is on the many side, so we create a property in Order that points to Customer:

Order

orderId       integer

timestamp     dateTime

orderedBy     Customer

When defining the mapping, the user points the property on the many side to the other entity's primary key. In our example, the Order property will point to the Customer primary key:

Order

orderId          /Orders/OrderId

timestamp        /Orders/DateAndTime

orderedBy        /CustomerID

Creating an N:M Relationship

You can create an N:M relationship between entities when an entity instance is related to one or more instances of another entity and vice-versa.

In our example, the Order and Product entities are related. An order can have one or more products and a product can be part of one or more orders. The relationship is N:M.

Here are the modeled entities before defining the relationship:

Order

orderId       integer

timestamp     dateTime

Product

productId     integer

name          string

To model the N:M relationship, you define a property in one of the participating entities that points to the related entity. Similar to the 1:1 case above, the relationship can be modeled by defining a property in either of the participating entities. (The other entity in the relationship is left untouched.)

Here, a Product property is defined in the Order entity:

Order

orderId       integer

timestamp     dateTime

includes      Product    yes

The cardinality of the property is also marked as multiple.

Alternatively, an Order property can be defined in the Product entity:

Product

productId     integer

name          string

isPartOf      Order      yes

Which entity the user chooses to hold the property may be based on the lifecycle or complexity of the entities involved.

When defining the mapping, point to the related entity's primary key to establish the relationship. Here is how the mapping is defined when the reference property is in the Order entity:

Order

orderId          /Orders/OrderId

timestamp        /Orders/DateAndTime

includes         /Orders/Products/ProductId

Here is how it is defined when the reference property is in the Product entity:

Product

productId        /Orders/Products/ProductId

name             /Orders/Products/Name

isPartOf         /Orders/OrderId

Because the relationship is N:M, the properties in the resulting entity instances will have arrays as their datatypes, and the arrays will hold one or more values based on the number of related entities.