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.
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.
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.
Entity Model Validation
Only valid entity models are loaded into the MarkLogic Server instance. A valid entity model meets the following requirements:
info/baseUriin the model must have a value that is a valid URI.
- The model must pass the Entity Services validation function
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
/entities/YourEntityName.entity.schema.json. The entity model as a JSON schema for use in XDMP validation (
/entities/YourEntityName.entity.xsd. The entity model as a XSD schema for use in XDMP validation (
- a TDE template (
/tde/YourEntityName-YourEntityVersion.tdex) with the following permissions:
Important: In MarkLogic 10 and later versions, a user assigned to the admin role only must be explicitly given
readpermissions for the data-hub-operator
updatepermissions for the data-hub-developer
- default permissions allowed to the user who loaded the entity model to MarkLogic Server
readaccess to view the TDE template.
If a TDE template with the same URI already exists but is not in the
ml-data-hub-tdecollection, 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:
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:
Alternatively, a Customer property can be defined in the BabyRegistry entity:
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:
Here is how it is defined when the reference property is in the BabyRegistry entity:
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:
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:
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:
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:
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:
includes Product yes
The cardinality of the property is also marked as multiple.
Alternatively, an Order property can be defined in the Product entity:
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:
Here is how it is defined when the reference property is in the Product entity:
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.