> For the complete documentation index, see [llms.txt](https://docs.eximee.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.eximee.com/documentation/documentation-en/budowanie-aplikacji/model-danych/dobre-praktyki-przy-tworzeniu-modelu-danych.md). # 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, follow the technical standards below: | Aspect | Rule | Example (Good) | Example (Bad) | | -------------------- | ----------------------------------------------------------------------- | ----------------------- | ------------------ | | **Format** | Use camelCase, a single language (English), no PL characters or spaces. | `startDateOfEmployment` | `Start_Date` | | **Boolean logic** | Start with `is` or `has`. | `isPoliticallyExposed` | `is_pep` | | **The "of" pattern** | Use the "of" construction for clarity of context. | `countryOfResidence` | `residenceCountry` | | **Identifiers** | Avoid generic `id`. Add business context. | `customerId` | `id` | ### Principles for designing structure and development The following rules define the approach to the model architecture and its evolution over time: | Rule | Description and business rationale | | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Hierarchy and structure** | The tree structure must reflect 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 model readability. | | **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 separate field dynamically fed by a provider. | | **Avoid 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`), to maintain technological consistency. | | **YAGNI strategy** | Do not model structure "for later". Add only the fields that are actually required at the current stage of the process. An excessive model makes analytics harder. | | **Reusability** | When designing a new structure, treat existing models in other applications as a reference point. Keep consistent naming for the same concepts across the entire organization. | | **Requirement updates** | With every modification of the BPMN process (e.g. adding or removing a step) or form (e.g. adding 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 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 of type `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`null, takes priority. | ## 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 | | ------------------------- | ----------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Missing form binding | The "Data model key" was not set in the component. | Data is not being 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 when launched it will retrieve the existing value from the model. | | Typos and name mismatches | Typing names manually 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 invalid and will cause an error preventing the form from launching. | In repeatable 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 This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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, and the optional `goal` query parameter: ``` GET https://docs.eximee.com/documentation/documentation-en/budowanie-aplikacji/model-danych/dobre-praktyki-przy-tworzeniu-modelu-danych.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.