Changes
= Data Model =
A good way to design a data model is to create an [[https://de.wikipedia.org/wiki/Entity-Relationship-Modell|Entity-Relationship Diagram]]. It is recommended to do so in the scope of a Technical Design (see [https://wiki.augmensys.com/index.php?title=[HowTo:Design_a_Customizing#Requirement%20Supply%20Chain|Requirement Supply Chain]]).
== Object-oriented and relational ==
One can use relations and references to create n:m and 1:n connections and dependencies between such entities (e.g., the relationships between invoices, invoice items and products).
Properties with different data types can be modeled for every entity, and one such MetaClass can inherit the properties from another (e.g., there could be a MetaClass "SAFETY_INSTRUCTIONS" inheriting the "Filepath" property from a "DOCUMENT" MetaClass).
An important aspect in data modelling, especially for the representation in relational databases, is [https://en.wikipedia.org/wiki/Database_normalization|normalization].
== Basic data model ==
In contrast, a common mistake is to start designing the data model according to the workflow one is trying to customize. There are the following problems with that:
* The data is not [https://en.wikipedia.org/wiki/Database_normalization|normalized] correctly, because properties are not assigned to the "true" entity in the customer's process.
* As a consequence, there is redundancy in the data and the data model is inconsistent with reality, leading to conceptual problems when using the data later.
Also, {{UBIK}} comes with a lot of features one can apply to influence the behavior of (data on) the mobile client, ranging from inter-dependent tasks and work-packages to dynamic selective lists.
= Algorithm =
