GBDS common mistakes
GBDS · Understand the traps and how to avoid them.
Treating a business requirements document as a place to record the proposed solution ("we will build a dashboard with three tabs") instead of the business problem, stakeholders, and measurable outcomes it must satisfy.
Candidates with a technical background default to solution language because it feels concrete and testable, and they worry that describing needs without a design looks incomplete. Exam items that ask for the 'best requirement' or 'next elicitation step' then look ambiguous because the candidate is scoring answers against their own solution framing.
What to do instead
Before answering any requirements item, restate the need as problem + actor + outcome + measure, and classify each candidate answer as need, constraint, assumption, or design decision. Practise rewriting solution-flavoured statements into need statements until the classification is automatic.
Confusing a logical/conceptual data model with a physical schema - for example answering a question about entity relationships with column data types, indexes, or tablespace choices.
Candidates who work daily in one DBMS collapse the three model levels because in their tool the logical and physical layers are edited in the same diagram. Exam items deliberately test the boundary, especially around many-to-many resolution, subtypes, and abstraction.
What to do instead
Memorise the purpose of each level: conceptual (business concepts and relationships), logical (attributes, keys, cardinality, normalisation, no DBMS specifics), physical (types, indexes, storage, partitioning). For each practice item, name the level the question is operating at before reading the options.
Normalising to third normal form by reflex on every question, including items about deliberate denormalisation for reporting, history, or performance.
Training material emphasises normal forms as the 'correct' answer, so candidates treat 3NF as universally right and miss items that ask why a star schema, snapshot table, or type-2 dimension intentionally violates it.
What to do instead
Learn the trade-off explicitly: normalisation protects integrity and write efficiency; denormalisation trades redundancy for read performance and simplicity. On any design item, ask what the workload is (OLTP vs analytical), whether history must be preserved, and whether the redundancy is controlled by the load process.
Writing a query that returns the right rows but ignores NULL semantics - using NOT IN with a subquery that can produce NULL, or comparing a nullable column with = instead of IS NULL.
Test data rarely contains NULLs, so the behaviour never surfaces in day-to-day work. Candidates also mentally substitute 'empty' for NULL, which leads to assuming NOT IN and NOT EXISTS are interchangeable.
What to do instead
Treat NULL as unknown, not blank. Before finalising an answer, check every predicate on a nullable column, prefer NOT EXISTS over NOT IN when the subquery column is nullable, and remember that aggregates other than COUNT() skip NULLs while COUNT() does not.
Assuming a join and a filter are equivalent - writing an inner join with a predicate in the WHERE clause where a LEFT JOIN with the same predicate in the ON clause was required, silently dropping the unmatched rows.
The two forms look nearly identical and produce identical results for inner joins, so the habit is formed without feedback. Candidates also forget that a WHERE predicate on the outer side of an outer join removes the NULL-extended rows.
What to do instead
For every outer join, state in one sentence which side must be preserved. Put preservation predicates in ON, restriction predicates in WHERE, and verify by asking 'what happens to rows with no match?' Test with a small dataset that includes an unmatched parent.
Judging data quality only by completeness and accuracy while ignoring consistency, timeliness, uniqueness, and validity - and treating quality as a one-off cleanup rather than a governed, measured process.
Candidates equate 'quality' with 'no missing values and no typos' because those are the defects they see in source extracts. Exam items that describe conflicting values across systems or stale records then get misclassified as integration problems.
What to do instead
Learn the standard dimensions (completeness, accuracy, consistency, timeliness, uniqueness, validity) and, for each scenario, name the dimension violated and the metric that would detect it. Frame remediation as detect–measure–root cause–fix at source–monitor, not as a cleansing script.
Answering security items by choosing the strongest-sounding control (encrypt everything, restrict all access) rather than the control that fits the requirement, such as least privilege, segregation of duties, or data minimisation.
Candidates reason 'more security is always the safer answer', but exam items test fitness for purpose and the principle of least privilege; over-restriction breaks business processes and is scored as wrong.
What to do instead
For each security item, identify the asset, the threat, and the business constraint first, then select the control that addresses that threat with the least operational disruption. Know the difference between authentication, authorisation, encryption at rest and in transit, masking, and auditing, and which requirement each satisfies.
Designing an ETL answer that ignores idempotency and restartability - describing a load that appends rows or updates in place without a way to rerun it safely after failure.
Candidates describe the happy path because that is what they have built or read about; failure handling is rarely exercised in tutorials, so the concept does not come to mind under time pressure.
What to do instead
For every integration design, state the load pattern (full, incremental, change data capture, merge/upsert), the key used to detect change, and what happens on rerun. Mention staging, watermarks or high-water marks, and atomic swap or MERGE so a partial run leaves no duplicates.
Treating slowly changing dimensions as a single concept - failing to distinguish type 1 (overwrite), type 2 (versioned rows with effective dates and current flag), and type 3 (previous-value column) when the requirement is about history.
The names are similar and candidates remember 'SCD type 2 keeps history' without the mechanics, so they pick type 2 for requirements that only need correction of errors, or pick type 1 when audit history is explicitly required.
What to do instead
Memorise the decision rule: overwrite errors → type 1; need full history with as-of reporting → type 2 (surrogate key, effective/expiry dates, current flag); need only limited prior value → type 3. For each scenario, ask 'must we report the state as of a past date?' and answer from that.
Confusing measures and dimensions, or answering grain questions with the report layout rather than the fact table grain - leading to fan-out and double-counted totals.
Candidates think in terms of the finished report ('rows are products, columns are months') instead of the business event being counted, and they underestimate how a one-to-many join multiplies fact rows.
What to do instead
For every analytical design, declare the grain in one sentence ('one row per order line per day') before choosing measures. Keep additive measures in the fact, descriptive attributes in conformed dimensions, and check any many-to-many relationship for a bridge or factless fact table.
On delivery items, choosing the response that removes the obstacle fastest (skip the change control, absorb the scope silently, extend the deadline without escalation) rather than the one that follows governance and records the decision.
Candidates optimise for 'getting it done' and read escalation as failure or blame, so they avoid the option that documents and routes the issue even though that is the professionally correct answer.
What to do instead
Learn the standard sequence for scope, schedule, and risk changes: identify impact, quantify it, record it in the change log or risk register, escalate to the accountable owner, then act on the approved decision. When an item describes an unapproved change, look for the answer that formalises it, not the one that accommodates it.