Objective and core distinction
A transactional workload records operational events and changes current data. An analytical workload commonly reads historical observations or measures to answer a broader question. The same organization may need both. ACID describes important transaction properties:atomicity treats a unit as all-or-nothing, consistency concerns valid states, isolation concerns concurrent work, and durability concerns retaining committed results. These properties are not four words for speed. They also do not select a database service by themselves. Identify the unit of work, the relevant state and whether the concern is before, during or after commit. Keep the business requirement distinct from the fact that software must actually implement it correctly.
Worked example
Fictional case:a equipment-lending club records one checkout and a matching reduction in available stock as an explicitly atomic unit. If the checkout cannot be completed, the club does not want inventory to remain reduced for a loan that does not exist. The required final outcome is neither change committed. That is atomicity at the stated boundary, not a claim that every SQL error automatically triggers the same engine behavior. After a valid checkout does commit, the club wants the committed result to remain after a restart:a durability concern. Now a second reader examines stock while checkouts occur. Avoiding inconsistent concurrent observations introduces an isolation concern. Each question names a different condition.
Changed condition and misconception
At month end, the club asks which equipment categories were used most frequently over the previous year. That request groups historical activity and is analytical; it is not another checkout transaction. A summary may help planning while omitting individual operational detail needed for returns. Similarly, a transaction’s scope does not automatically include earlier separate committed work. Undoing a failed checkout should not erase unrelated prior loans. Avoid the opposite overgeneralization too:NoSQL does not mean no transactions. Later we examine the documented logical-partition boundary for Cosmos DB for NoSQL rather than treating an entire product category as incapable of ACID behavior.
Transfer check
Transfer check:a fictional delivery transaction commits successfully, then its service restarts. A colleague proposes rerunning all deliveries because committed work is supposedly only temporary. Which distinction should you explain? Check basis:the question concerns durability after commit, not whether the earlier unit had multiple steps or whether a historical trend report is available. State the committed result that should remain and keep unrelated transactions outside the discussion. Then classify a second request for totals by quarter as analysis. Explain why using the same source data does not make these two workload questions identical. The linked practice supplies separate cases and boundary conditions.
Try it, then explain it.
Complete a short set without looking at the example. After each answer, explain which evidence or rule supports your decision and why the alternatives do not fit.
Sources & authorship
Original OpenExam explanations and examples. References support the concepts; they are not the source of copied questions. Independent educator review is pending.
Explore analytical data processing - Training | Microsoft LearnDatabase Transactions and Optimistic Concurrency Control - Azure Cosmos DB | Microsoft LearnExplore transactional data processing - Training | Microsoft Learn