# Best practices for creating a data model ## Introduction to data modeling When creating a data model for an application in Eximee, you should follow principles that will make the system easier to maintain and ensure data consistency across the entire organization. A well-designed model is the foundation of efficient information flow between the user interface and the process engine. ### Key naming standards An effective data model should be intuitive. When designing keys, apply the following technical standards: | Aspect | Rule | Example (Good) | Example (Bad) | | -------------------- | ------------------------------------------------------------------ | ----------------------- | ------------------ | | **Format** | Use camelCase, one language (English), no PL characters or spaces. | `startDateOfEmployment` | `Data_Rozpoczecia` | | **Logic (Boolean)** | Start with `is` or `has`. | `isPoliticallyExposed` | `czy_pep` | | **The "of" pattern** | Use "of" constructions for clarity of context. | `countryOfResidence` | `residenceCountry` | | **Identifiers** | Avoid a generic `id`. Add business context. | `customerId` | `id` | ### Rules for designing structure and development The following rules define the approach to the model architecture and its evolution over time: | Rule | Description and business justification | | --------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Hierarchy and structure** | The tree structure must correspond to the natural hierarchy of business data. Group fields into semantic objects (e.g. `customerData.name` or `registerAddress`). This makes it easier to map entire structures to services and increases the readability of the model. | | **Data vs Calculations** | Store source data (e.g. dates), not variable or derivable values (e.g. age). If a calculation is necessary, add it as a neighboring field dynamically populated by the provider. | | **Avoiding duplication** | Before adding a field, check whether similar information already exists. Different objects (e.g. addresses) should share the same internal key names (e.g. `streetName`), in order to maintain technological consistency. | | **YAGNI strategy** | Do not model structure "just in case". Add only those fields that are actually required at the current stage of the process. An excessive model makes analysis harder. | | **Reusability** | When designing a new structure, treat existing models in other applications as a point of reference. Keep consistent naming of the same concepts across the entire organization. | | **Updating requirements** | Whenever you modify a BPMN process (e.g. add or remove a step) or a form (e.g. add a new data section), perform an impact analysis on the data model. Lack of synchronization is the most common cause of errors. | ### Documentation and technical parameters The data model in Eximee is not only a structure, but also metadata that facilitates integration and maintenance: | Parameter | Rule and best practices | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Attribute `docs`** | Document the business meaning and the context of keys and providers. In the application documentation, use full dot notation (e.g. `customerData.address.street`). | | **Value `defaultValue`** | Allows assigning a default value (e.g. the flag `false`) when the sources do not provide data. This prevents errors such as `null pointer`. | | **Multiplicity** | Parameters must precisely reflect the business logic. For required fields `Min=1`. For lists of unlimited length, use `Max=null`. | | **Source logic** | Document the order and mappings of providers. Remember - the first source that returns a value other than `null`, takes precedence. | ## Common mistakes and how to avoid them Below is an overview of the most common mistakes made when creating and using a data model - their causes, effects, and how to avoid them. | Error | Cause | Effect | Solution | | -------------------------------- | -------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | No link to the form | The "Data model key" was forgotten to be set in the component. | Data is not saved (the field is empty after refresh). | Set the key in the component properties by entering the exact field key from the data model. After saving the form, the component will save its value to that field, and on launch it will retrieve the existing value from the model. | | Typos and naming inconsistencies | Manually entering names in the "Data model key" option. | The component will not connect to the correct field in the data model - the value will not be saved to the model. | "Use the copy icon next to the key in the data model. | | Incorrect use of arrays | Omitting index notation (e.g. `products.price`). | Syntax without \[] or an index is incorrect and will cause an error that prevents the form from running. | In repeating sections, use the notation `products[].price`. | | Invisible data model | No artifact in the application. | The model has not been initialized. | Use the "Initialize data model" button in the application's "Data model" tab. | --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.eximee.com/documentation/documentation-en/budowanie-aplikacji/model-danych/dobre-praktyki-przy-tworzeniu-modelu-danych.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.