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


Was this helpful?

Yes No
You indicated this topic was not helpful to you ...
Could you please leave a comment telling us why? Thank you!
Thanks for your feedback.

Post your comment on this topic.

Please do not use this for support questions.
For customer support, please contact us here.

Post Comment