Nervatura Object Model

Ver.No: {{=response.verNo}}

  1. Overview
  2. Objects
  3. Base objects
  4. Features
  5. Events
  6. Transaction
  7. Relations
  8. Group configuration
  9. Complex data types
  10. Other objects
  11. User interface objects
  12. Relations pyramid
  13. Objects relations


  1. Overview

    General data model, which can store all information generated during the operation of a classic organization. This includes all manufacturer, retailer and service companies (or government units) which operation can be defined and described within a GOODS (we want to sell or we supply) – CLIENT (we work for) - RESOURCE (we possess for the task) triangle.

    It is located between the applications, surfaces that are using and creating the data and the real data storage layer. It defines logical objects; data is stored in these freely defined attributes and in relations between them. Its flexible structure allows defining new properties or assigning events to our objects.

    The number of objects is minimal, their structure is simple. It has an easy to learn, perspicuous and usable logic. However it is capable to store the required data in structures. It ensures the possibility to attach defined type features of any kind to each object and also makes the objects linkable to each other arbitrarily.

    The data model is independent from data storage layer. In the functions of implementation the concrete data storage can be realized by any optional method or device but as a main requirement the user of the data model must not sense this at all.

  2. Objects

    Such pre-defined functional roles which can have any type of attributions, events can be attached to them as well as their elements can be attached to elements of other objects.
  3. Base objects

    CUSTOMER - all external partners of the company, including the buyer, consumer and supplier side
    PRODUCT - all raw materials, semi-finished and end-products that are related to our activity (as customer or vendor), produced by us as a manufacturer or offered as service
    TOOL, EMPLOYEE, PLACE resources which are available for executing the activity and they contribute to it. These can be human resources (EMPLOYEE), material devices, tools, machines (TOOL) or financial, potentially infrastructural conditions such as warehouses, bank account, petty cash (PLACE)

  4. Features

    All data that describes a given object, we want to attach to it as information. Some of them are pre-defined but further ones can freely be defined for any of the objects.

    When using the Nervatura Data Interface (NDI) a feature of an object which has not existed before- is automatically generated when the first value is given. If we create a new feature in this way then its type is unidentifiable thus it will be automatically text. However by defining the exact type of certain features, we could easily ensure that the stored data is correct.

    By using the DEFFIELD object we can define data storage features for other objects. Besides the classical data types (bool, integer, float, date, string, notes) these can contain list of values (valuelist), url links (urlink) or references to concrete components of other objects (customer, product, tool, employee, etc.).

    When using NDI, values of features defined in this way can be set in the object component with the name of the feature and can be queried as well.

    Through the FIELDVALUE object every defined feature of components of all objects can be queried.

  5. Events

    Extended, generally time and interval bound object features. With the help of events we can make the static features of an object into dynamic so the feature of a given component is able to take various values at different times. An event can also be valid for a period of time, so having a start and an end date. Optional number of supplementary data of a given object can be attached to it as well as it can be grouped.

    We can manage the events through the EVENT object. Beside the base object we can also assign events to projects.

  6. Transaction

    Transaction is such a sort of event to which at least two base objects are joined.

    An event is always attached to a given object. As a further event feature another base object can be granted but it's just an optional additional data in this case.
    In the transactions the relation between the base objects is an indispensable and essential component of the given event. The transaction doesn’t belong to any of the base objects but the base objects are joined to a transaction. From these some base objects might be optional components but at least two should be indispensable part of it.

    The most common object pair is the customer and product relationship (e.g.: offer, order, invoice) but any other combination is also possible, for example product-place (stock management), customer-tool (rental), employee-customer (worksheet) etc.

    We can link additional data to transactions just as to events, but in contrary to events, here we don’t use the features of the linked base object but we can declare own, additional data. Transactions can also be linked to each other or can "originate" from each other, for instance offer -> order -> inventory move -> invoice.

    The object of transactions is the TRANS which contains the main data of transactions as well as the single object relations. ITEM object contains PRODUCT lines linked to transactions, PAYMENT object contains financial settlements, MOVEMENT object contains warehouse and device movements.

  7. Relations

    There are several options to link single objects. Usually the object has the possibility of applying the one to one relation by default, if it is required so by its type. In case of need the additional data pointing to the proper type of object can also be generated at any time.
    For example we can set a customer type feature for CUSTOMER object wherewith we can link a given customer to another customer. With the same method one to many relations can also be set, so in this case we can also link our customer to some other customers. .

    If any linked customer is also linked to an other customer it results in a many to many relation.
    LINK object can also be used to set relations to objects. This way two objects can be linked without giving further object features.

  8. Group configuration

    Several options are available for grouping the objects. Using supplementary data, further to data storage opportunities allows also grouping to a certain degree.

    In the GROUPS object we can create groups by object types. If needed, further features can be defined for these groups. These can then be used for assignments of pre-defined values on a given object (for example type options), but through LINK object can also be used for creating classical one to many groups (for example customer of product groups).

    Actually the PROJECT object can be applicable as the extension of GROUPS object. Surely it is possible to set additional data features here as well but at PROJECT object temporal extension is also possible, just like it is in case of events vs. features. Optionally it can have start or end date, we can also link it to customers or places. Projects can also have their own events as well as any transaction can be linked to them.

  9. Complex data types

    When adding features to objects in some cases complex data feature setting is needed. Essentially these are such sub objects which possess own features. For example if we want to add address data to a customer then by setting the address we can give the city, the zip code or the name of the street as well.
    Some complex data types can be linked not only a single object but the same element can also be attached to many others. In some of them it is possible to define further additional data.

    One to many linked sub objects:
    ADDRESS, BARCODE, CONTACT, PRICE

    One to one linked sub objects:
    CURRENCY, PATTERN, RATE, TAX

  10. Other objects

    The objects of rights management, logging and other options:
    LOG, NUMBERDEF

  11. User interface objects

    These objects are not parts of the object model, they are not needed for recording the workflow data. However certain applications to ensure their own operation might require data storage possibilities.
    These objects are not or not fully supported by the functions of NDI, though they are available through the Nervatura Programming Interface (NPI). Nervatura Web Client (NWC) also uses some of them.

    Storage of data of Reports:
    UI_REPORT, UI_REPORTSOURCES, UI_REPORTFIELDS

    Settings of user interfaces:
    UI_MENU, UI_MENUFIELDS

    User rights, settings:
    UI_AUDIT, UI_USERCONFIG

    Regional settings:
    UI_LANGUAGE, UI_MESSAGE

    Printing:
    UI_PRINTQUEUE

  12. Relations pyramid

    For safe backup and restore go from top to the bottom.

    Level Additional data Objects
    level 1a no external link no GROUPS, NUMBERDEF
    level 1b yes* CURRENCY, TAX
    level 2a link to <= level 1 no DEFFIELD, PATTERN
    level 2b yes* CUSTOMER, EMPLOYEE, PLACE, PRODUCT
    level 3 link to <= level 2 yes* BARCODE, PRICE, PROJECT, RATE, TOOL
    level 4 link to <= level 3 yes* TRANS
    level 5 link to <= level 4 yes* EVENT, ITEM, MOVEMENT, PAYMENT
    level 6 link to <= level 5 yes* ADDRESS, CONTACT
    level 7 link to <= level 6 yes* LINK, LOG
    level 8 link to <= level 7 no FIELDVALUE
    *Backup with the FIELDVALUE (cross-references fields)
    Level Objects
    level 1 no external link UI_MENU, UI_LANGUAGE
    level 2a link to <= level 1 UI_MESSAGE
    level 2b link to <= NOM level 1 UI_REPORT, UI_AUDIT
    level 3 link to <= level 2b UI_MENUFIELDS, UI_REPORTFIELDS, UI_REPORTSOURCES
    level 4 link to <= NOM level 2 UI_USERCONFIG, UI_PRINTQUEUE
  13. Objects relations

    1. picture: A possible relational database plan of NOM objects.

    2. picture: A possible relational database plan of user interface objects.