Data Modeling

Definition

Custom schema specification for data validation, storage, and UI presentation.

Example Use Cases

• Admin wants to add a field for “Location” to the Article entity in this content management system. This field should be required, meaning the object cannot be published until the field contains a value.

• Admin wants users to specify the product a prospect has inquired about in their lead management system. The value should be a lookup field which allows the user to search the product database for the correct product. Additionally, the field should repeat, so that the user can add more than one product in the event a prospect inquires about more than one.

Modeling-Based Apps

Several genres of applications are fundamentally based on data storage:

• Content management
• Customer relationship management
• Customer data platforms

Most all of these systems have default models of some kind, and they all allow the extension of those models for a customers specific requirements.

• Custom Field Types in Salesforce

The extension of a model means the specification of additional values (called “fields,” “properties,” or “attributes”), with the following details:

• Data typing, usually from a set list of possible types which can be simple or complex (serialized)
• Validation, again usually from a set of possible validations for each data type
• Repetition, so that more than one value can be stored
• Output format, a typed data format for usage in template or other delivery logic

Additionally, some of these might be custom:

• Custom property types, which usually involve custom UI elements and custom serialized storage
• Custom validation, which normally maps to executable server-side code

UI-Modeling vs. Code-Modeling

There are two major patterns for model specification:

• UI-based, where a user creates and edits properties from an interface
• Code-first, where the models are written as code – either actual source code or file-based configuration – and deployed. This requires root access.

Clearly, code-first modeling cannot be considered “user extensible.”

UI modeling is user-extensible, but comes with its own problems and limitation, primarily around lack of versioning and environment synchronization.

See: The Benefits of Files.

Some systems offer user-extensible modeling with import/export or other kinds of synchronization:

• Multiple environment management in Contentful
• Exporting and importing data in Optimizely Content Cloud, specifically with the “Automatically export dependent content types” option

The Problem of Custom Model Types

Most content management systems allow a developer to define custom property types. These can be comprised of:

• UI element with optional client-side validation logic
• Serialization/deserialization
• Server-side validation logic
• Typed value representation

Without root access custom property types basically consists of a client-side UI element that serializes itself, prior to submission.

Serialization could be into a known format (a specified JSON representation, for example), so just to a “blind” string that the system stores as such.

Server-side validation is likely not possible as the application would likely have to deserialize the submission and turn it into a typed object. If there was a specified JSON format into which the value was serialized, the application might be able to deserialize into a simple object and validate, but this would be subject to the limitations of non-root code.

Practices for User Extensibility: Data Modeling

• Allow modeling from the UI

• Provide a synchronization system whereby changes can be moved between environments. At least import/export, but rather provide an automated migration system where changes can be “published” to other environments.

• Specify a standard serialization format

• Allow custom property type specification by allow custom UI elements with serialization tools which simplify translation to the standard serialization format

• Allow server-side validation on the standard serialization format