Master Data vs. Transactional Data

Spend any time in the world of master data management (MDM), and you’re likely to hear a definition of master data that goes something like this: “Master data is the core, non-transactional business data that is widely shared and rarely changes.” Master data refers to real-world entities like customers, products and locations, or, as we like to say, people, places and things.

Transactional data, on the other hand, is not core business data. It is not usually widely shared, and it changes frequently. TechTarget defines transactional data simply as, “…information collected from transactions,” which can refer to any number of events besides financial transactions:

• Shipping updates on orders
• Hours logged by workers in a timesheet
• Insurance claims
• Prescription orders from a physician
• Bank deposits and withdrawals
• Students registering for classes at a college or university
• Customer support case creation/closure

Generally speaking, transactional data is a record of any event where an exchange takes place. This can quickly become an overwhelming amount of information, so organizations usually choose a few important types of transactional data to focus on, like purchases made and hours worked.

Both master data and transactional data are essential for organizations looking to become more data-driven, especially for initiatives like customer 360. Master data provides useful context around transactional data, and transactional data records often point to master data like customer or product information. For best results, it’s important to properly manage both types of data to ensure they can be trusted for deriving insights.

How Is Transactional Data Managed?

The systems used to manage transactional data are aptly named transactional databases. These are specialized database management tools that excel at processing data rapidly while ensuring that records remain unique, intact, secure and accessible.

Transactional databases form the backbone of major industries such as banking and ecommerce. Without them, it’s difficult to imagine how these industries as they exist today would function. It’s not just that transactional databases must be fast to keep up with the daily onslaught of transactional data — they must also include automation features to cancel or reverse incomplete transactions or transactions that encounter errors in addition to failovers to ensure databases continue reliably processing data in the event of system failures (more on this in the next section).

There are many transactional database tools on the market, but some popular options include relational database management systems (RDBMS) such as:

• Microsoft SQL Server or Azure SQL
• MySQL
• Oracle Database
• MongoDB
• Amazon DynamoDB
• IBM Db2

ACID Properties of Transactional Data

Beyond the definition we considered earlier, transactional databases use a more technical definition of transactional data to determine how transactions should be processed. Known by the acronym ACID, this approach to defining transactions is designed to prevent data loss and consists of four properties:

• Atomicity: Transactions are an all-or-nothing affair, at least from a database’s perspective. Transactional databases usually need to complete a few steps before completing a single transaction. If any one of those steps fails during the process, it could cause inaccuracies in the data. Since ACID was developed to prevent this very thing, transactional databases are engineered to only consider a transaction successful if every step of the operation is successful.
• Consistency: Databases have rules! Transactions must adhere to the rules organizations put in place, and it’s the database’s job to make sure this happens. For instance, an ecommerce company might have business rules in place to prevent purchase transactions on products that are out of stock or that aren’t available for delivery to a certain region.
• Isolation: Sometimes, more than one transaction needs to interact with the same data simultaneously. The isolation property of ACID ensures this happens in an orderly fashion and that concurrent transactions don’t devolve into free-for-alls of one operation attempting to, for example, read a data record while another operation is trying to move it somewhere else or replace it. Rather, this property says that concurrent transactions must be processed one at a time; the database must finish processing the transaction it’s currently working on before it can move on to the next one.
• Durability: Once the database successfully completes a transaction, that record is permanently saved. Even if there’s a system failure — for example, as in the event of a power outage — transactional data that meets ACID standards won’t be lost.

Maintaining the integrity of transactional data is critical — especially for highly regulated industries like banking and finance that may need to preserve data integrity as a matter of regulatory compliance. ACID properties help ensure that databases handle transactions properly to achieve that goal.

Interactions Between Transactional and Master Data

We know that part of what makes master data master data is that it’s non-transactional, but what happens when master data and transactional data cross paths? This happens all the time, and it’s a normal and often necessary behavior for these different types of data to exhibit.

Consider what happens when a manufacturer, for example, places an order with one of its suppliers. The manufacturer sends a request for raw materials, money is exchanged and then the supplier creates a purchase order and gets to work on fulfilling the order. The transactional data record in this example might look like this: