Information & AI · Workplace data and databases
When customer and order tables are connected, how should identical names or customers with no orders be handled? Database terms help make those business conditions explicit. Start with row identity, then matching related rows, and finally grouping changes that must succeed together.
The guide introduces relational databases and standard SQL. Some details, including null handling, vary across products and configurations, so read the examples' premises. Displaying a table and correctly representing its customers or transactions are separate achievements.
Try this topic in a quizThis opens the setup screen with this subject and topic selected. Check the mode and question count before you start.
A customer row groups information about one customer; its columns hold item types such as an address. A standard SQL primary key uniquely identifies a row and has non-null values. Shared names and name changes illustrate why a person's name alone is often a poor identifier.
A stable customer ID referenced by orders separates display-name changes from identity. Repeating the same fact manually across many rows can create contradictions after partial updates. Deciding which table owns which subject's facts provides a foundation for reliable relationships.
An INNER JOIN returns matching row combinations. Joining customers to orders this way leaves customers with no orders out of the result. A LEFT JOIN preserves the left-side customers and supplies nulls in the right-side columns when an order match is absent.
Do not silently treat a null as zero sales or an empty string. How an absent match should be reported depends on the query's purpose. Joins can also expand row counts, so the number of result rows need not equal the number of customers originally selected.
Recording a transfer can involve reducing one balance and increasing another. Transaction atomicity makes grouped changes all-or-nothing. It prevents the intended operation from taking effect only in part, such as recording one side of a transfer without the other.
COMMIT finalizes a transaction; ROLLBACK cancels uncommitted changes. Completion, visibility to other work and recovery after media loss concern different guarantees. One success message should not be treated as evidence that every possible requirement has been met.
TRY & READ
Compare the choices before opening the answer and explanation. Reading an example does not save a test answer or score.
Example 1 · Workplace data and databases
Answer: Uniquely identify each row and contain no nulls
A primary key combines uniqueness with non-null values.
Check, not-null, unique, primary-key, foreign-key and deletion actions
Source checked: 2026-10-05Example 2 · Workplace data and databases
Answer: Keep the left row with nulls for right-side columns
A left outer join preserves left rows and supplies nulls for unmatched right columns.
Inner/left joins, unmatched rows and qualification
Source checked: 2026-10-05Example 3 · Workplace data and databases
Answer: Grouped changes take effect together or not at all
Atomicity treats grouped operations as all-or-nothing, avoiding partial effects.
Atomicity, permanent logging, visibility, COMMIT/ROLLBACK and savepoints
Source checked: 2026-10-05Source checked: 2026-10-05
Source checked: 2026-10-05
Source checked: 2026-10-05
Topics: Workplace data and databases. Range: Everyday knowledge, Broader knowledge, General knowledge. Difficulty: Basic, Standard. These are selected initially. You can change these on the setup screen.
Try this topic in a quizA test shows explanations after submission. Continuous challenge explains each answer. Review uses unresolved mistakes recorded on this device. Casual mode does not update learning records.
Only the page address is shared. Your saves and results are not included.