ACCT20007 Chap.3 Data, Databases and ERDs
Data, Databases and ERDs
Database analysis separates resource-changing economic events from the information events that authorise and record them. This chapter uses entities, keys, relationships, cardinality and associative records to preserve business meaning.
It also applies atomicity, consistency, isolation and durability to failures that leave related accounting updates incomplete or conflicting.
An economic event changes the flow of a scarce resource controlled by the entity. An information event prepares, approves, communicates or records that change. A picking list may authorise warehouse work, but dispatch is the point when goods leave.
Treating the first record as the second can trigger premature billing even when both documents are technically complete.
The database view stores reusable facts once and links them through stable identifiers. Customer descriptions belong with the customer, item descriptions with inventory and transaction-specific quantities with the event line. Keys should remain stable when names or addresses change.
When two entities have a many-to-many relationship, an associative entity preserves event attributes rather than hiding repeated values in a master record.
Cardinality translates a real business rule into minimum and maximum participation. Each booking may require exactly one registered customer, while one customer may create many bookings.
A wrong minimum permits orphan events; a wrong maximum blocks legitimate activity or encourages duplicate masters. State the real rule first, then test zero, one and many cases at both ends.
Transaction properties protect behaviour after the structure is correct. Atomicity makes related updates complete or roll back together, isolation controls concurrent actions and durability preserves committed results.
Test a design with a bad case: interrupt the update midway, submit two requests at once or try to create an orphan. A sound database rule rejects or reverses the defect while retaining legitimate transactions and evidence for review.
Required fields and foreign keys do not prove that entered facts are true. They establish structural completeness and relationship integrity.
Accuracy still needs validation against authorised source evidence, while validity needs proof that the event should exist.
Many-to-many bridges often hold quantity, price, status or timing. Those attributes belong to the relationship event, not either master entity.
Correct placement preserves historical transaction facts when current master descriptions change.
Connect technical behaviour to the accounting record. An orphan sale affects attribution, a partial payment update affects customer balance and cash evidence, and weak isolation can promise the same inventory twice.
Use negative testing. Try a missing key, duplicate ID, interrupted update and concurrent request.
Record whether the system rejects, rolls back or reports each defect and whether legitimate activity remains possible.
Keys support traceability when they are unique, stable and controlled. Reusing identifiers or building them from mutable descriptions can join unrelated events and make later correction ambiguous.
Database controls need exception evidence.
A rejected foreign key or duplicate ID should enter a queue with source, time and responsible resolver so structural protection does not silently discard legitimate activity.
For revision, translate every diagram into plain business rules before checking notation. State the minimum and maximum participation at both ends, locate attributes on the event or master that owns them and test one invalid case.
Follow with an interrupted or concurrent transaction scenario. This sequence exposes whether the proposed structure and transaction behaviour preserve the intended accounting meaning.
What this chapter covers
- 01
Economic events
- 02
Information events
- 03
Database view
- 04
Entities and keys
- 05
ERD cardinality
- 06
Associative entities
- 07
ACID properties
Worked example · free
Repair impossible booking cardinality
- 1Each booking must link to exactly one registered customer.
- 1A customer may have zero bookings initially and many later.
- 2Enforce a non-null foreign key and referential integrity.
- 1Monitor rejected orphan records.
Key terms
- Economic Event
- An economic event transfers or changes a controlled scarce resource.
- Cardinality
- Cardinality states minimum and maximum participation in a relationship.
- Atomicity
- Atomicity makes related transaction updates complete together or roll back together.
Data, Databases and ERDs FAQ
How do economic and information events differ?
An economic event changes a resource flow, such as goods leaving or cash arriving. An information event prepares, authorises or records that activity, such as creating a picking list. Systems should link both without treating preparation as fulfilment.
Why does cardinality matter for accounting control?
Cardinality encodes business rules about what records may exist and how they relate. A wrong minimum can permit orphan transactions, while a wrong maximum can block legitimate repeat activity and encourage duplicate master records or overwriting.
When is an associative entity needed?
Use one when two entities have a many-to-many relationship and the event needs its own attributes. A sale line can connect sales and inventory items while storing transaction-specific quantity, price and status without duplicating master descriptions.
Exam move
For each ERD, narrate the business rule in ordinary language before reading symbols. Test zero, one and many cases at both ends. Then invent one bad transaction the current rule permits. For ACID, diagnose a concrete failure instead of memorising four words without behaviour.
Working through Data, Databases and ERDs in ACCT20007? Sia is AskSia’s AI Accounting tutor — ask any ACCT20007 Data, Databases and ERDs question and get a clear, step-by-step explanation grounded in how ACCT20007 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
