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

Zpětná vazba

Bylo to užitečné ?

Ano Ne
Označili jste toto téma za neužitečné...
Mohli byste nám, prosím, říct, proč ? Děkujeme !
Děkujeme za vaši zpětnou vazbu.

Sdělte nám váš názor na toto téma.

Prosím, nepoužívejte toto pro otázky k podpoře.
Pro zákaznickou podporu, nás kontaktujte zde.

Zveřejnit komentář.