Skip to content

Transactions vs Positions

Synonyms

There are different terms used for these. For example:

  • Transactions vs Positions
  • Stock Variables vs Flow Variables
  • Level Variables

See also

Understanding Transactional and Positional Data in Fact Tables

When talking about Fact tables, you may have heard us making a distinction between transactional data and positional data, or flow variables and stock variables.

Transactional Data (Flows)

What is it?

Transactional data in fact tables can be compared to a 'flow'. It's like the water flowing in a river, constantly moving and changing. This data records specific events or transactions as they occur, capturing every detail at that moment.

Characteristics

  • Dynamic: Changes with every event or transaction.
  • Detailed: Provides granular information about each transaction.
  • Time-Specific: Tied to the exact moment it happens.

Example

Imagine a coffee shop. Each time a customer buys a coffee, that's a transaction. In the fact table, every coffee sale is logged with details like time of sale, type of coffee, quantity, and price.

Positional Data (Stocks)

What is it?

Positional data is more like a 'stock' in a warehouse. It's a snapshot of a situation at a specific point in time, showing the accumulation or result of various flows (transactional data).

Characteristics

  • Stable: Represents a state at a particular moment, not constantly changing.
  • Aggregated: Summarizes information from multiple transactions.
  • Snapshot: Provides a broader view of the situation at a specific time.

Example: Coffee Shop

Using the coffee shop scenario, the positional data would be the inventory level of coffee beans at the end of the day. It's the result of all the day's coffee sales and any new stock received, giving a summary (or stock) of what's left in the store.

Example for Transactional Data: Project Management

In project management, we use transactional data records for most of our day-to-day work: Tasks, Orders, Meeting Minutes, etc.

For example, a task in planio could say: "add a filter on top right". It describes the incremental change to the current state, i.e. the delta.

This transactional approach is essential for estimation, planning, dependency management, and more.

But once a project is finished, most of these transactional artifacts are not so interesting anymore. For example, we hardly go back to read a meeting minutes of a meeting that was held 6 months back.

Example for Positional Data: Solution Design

The solution design describes the current state of a client solution (at least ideally). This is crucial for onboarding new team members, providing a reference for future changes, and ensuring consistency in understanding and implementation.

For example, for a new team member starting to work on a client solution, it is not so important if we first used the Power BI connector and then migrated to a DWH. He only needs to know the current state, namely that we are using a DWH.

For this reason, we separate clearly between Planio (Transactional Data) and the Solution Design in https://doc.pwrp.pro (Reference Documentation).