Transactional Data Tables are named as such as they contain data that describes the details of events, transactions and historical happenings. In the image below, we see the transaction children and grand-children of each of the five parent or Master tables at the top of each data family (or stack). Where Master Tables tend to have a smaller number of records, Transactional Data Tables tend to have far more records. This makes sense as one employee will earn multiple paychecks, one vendor will sell us multiple goods and a single customer may make multiple purchases from us.

When considering the architectural design (Data Model) of your Ninox database, it is important to consider the activities of an entity (as represented in the Transaction Tables) versus the parties of an entity (as represented in the Master Tables). It is also important to identify those transactional tables (the children in the image above) that themselves are parents. In the schema above, we see that each transactional child table (Invoice Header, PO Header, Item Master, Journals and Timecard Header) we see that each of these tables, while a child to the parent of the family have their own children tables, each of which containing content that further describes the details of the transactions defined in their parent.

The Master/Transactional table relationships of many common entities are demonstrated in the image below.

For each row in the image above, it is clear how a single entity as represented in the Master Table could the source of multiple transactional events to be represented in the Transaction Table.

Revision: 4
Last modified: 2019/03/31


Était-ce utile?

Oui Non
Vous avez indiqué que ce sujet ne vous a pas été utile ...
Pouvez-vous SVP laisser un commentaire nous disant pourquoi? Merci!
Merci pour vos commentaires.

Laissez votre avis sur ce sujet.

SVP ne pas utiliser pour des questions de support technique.
Pour le support à la clientèle, SVP nous contacter ici