Data modeling
Data modeling is the process by which data elements arrive into your application in a format that makes sense for your business and are then processed, reported on, and stored. The data model defines the types and structures of data in your application and standardizes how data elements relate to one another. Data models are also critical tools for communication between business stakeholders who define requirements for the data needed and created by business processes, and the system architects who act upon the requirements to build the application.
For example, your data model might represent the data used by your application to retrieve data about textbooks. The application passes the textbook ISBNs to a service that returns a list of titles and editions and then formats the results so sales representatives can both process orders using titles and easily switch between editions. If you import data for your Textbooks data type on a regular basis, you can define a default mapping between the ISBN field in a .csv file and ISBN field in your data type.
You need the following components to model data:
- Fields: Properties that store and format data in your application
- Data objects: Categories of data that have fields, field mappings, and connections to data sources
In the following image, click the + icons to learn about each component of the data model.
Data storage
Supplemental case processing data often exists outside of data objects, such as user preferences entered during case processing that influence the case lifecycle. The system needs to know a location in which to store that data. It is best practice to create a data class with the same name as the case type to store data that is not found in existing data objects instead of storing it on the work object, such as a case.
For example, a user in the LibraryReservation case type has their patron information stored in the Patron data object, which includes their name, e-mail address, phone number, and library card number. During case processing, they are presented with a choice to enable audio assistance for a reservation process. The application developer stores the single-value data from this boolean selection in a data object with the same name as the case type, in this case, LibraryReservation.
Consider as an analogy, a train that hauls containers as the work object. The containers represent supplemental case processing data that does not belong to a data object. You want to move that data around and share it but cannot effectively if it is saved inside the work object. To maximize reuse and portability, save data that does not exist in a data object in a data class with the same name as the case type with which it is associated, such as LibraryReservation in the previous example.
In the following image, click the + icons to learn more about storing data that exists outside data objects.
Data modeling best practices
A developer should verify the data model with a Lead System Architect before creating data objects or properties. Establishing the data model before creating and working with data saves future development time and minimizes the volume of errors that might impact application performance.
Addition of data through a UI view
While you can create portions of your data model while creating a view, developers can miss the larger picture of how data may interact and be reused across different components of the application. It is best practice to create the data model by using the Data Explorer first, keeping reuse and inheritance in mind.
You can use the Configure a view screen to add new fields as needed throughout the application's update life cycle. For example, the data model in your application includes a reusable data object named Customer that aggregates customer information such as First Name, Last Name, and Address. For a patch release, specifications require that the application gathers the customer's account number. You may choose to add this field in the Configure a view screen.
In the center of the following image, slide the vertical line to show the difference between adding a field through the Configure a view screen and on the Data model screen.
Check your knowledge with the following interaction:
This Topic is available in the following Module:
Want to help us improve this content?