@prefix edu: . @prefix dcterms: . @prefix skos: . @prefix rdfs: . @prefix schema: . # Generated by knobit-development/export_knobits.py from the register; do not edit. # Conforms to LCG-KNOBIT 0.1. Metamodel: bitbucket.org/reffa/ontology, metamodel/ a schema:Dataset ; dcterms:identifier "SCOPE-1" ; dcterms:title "Data modelling (DAMA-DMBOK2)"@en ; dcterms:description "Recognising and repairing defects in data-modelling deliverables, from data requirements to generated DDL: the competence the data-modelling skill applies in its build stages (requirements, conceptual, logical, physical, DDL), and that skill-tests assesses. The business glossary moved to metadata-management, data rules and data quality rules to data-quality (SKLZ-164)."@en ; skos:note "domain: Data management, data modelling and design (DAMA-DMBOK2 chapter 5)"@en ; skos:note "level: CDMP Practitioner: the Data Modeling and Design specialist exam of the Certified Data Management Professional (DAMA International), pass mark 70%"@en ; skos:note "audience: Data modellers, and AI models assessed by skill-tests"@en ; edu:graphRelevance ; edu:graphRelevance ; edu:graphRelevance ; schema:license ; dcterms:rights "Copyright 2026 Peep Küngas. Licensed under CC BY 4.0." ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-101" ; rdfs:label "Recognises a data requirement making several claims"@en ; skos:prefLabel "Recognises a data requirement making several claims"@en ; skos:altLabel "Not singular (data requirement)"@en ; skos:definition "The statement makes two or more testable claims, usually joined by \"and\", \"as well as\" or a comma. Half gets built and the whole gets signed off."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "data requirement with several claims"@en ; edu:expectedResult "The requirement and the separate claims it should be split into"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `DR-001` \"Every payment must record the payment value date and notify the regulator within thirty days.\" Acceptable: `DR-001` \"Every payment must record its value date.\" The notification deadline is an activity rule (row 3), recorded separately."@en ; edu:assessmentMethod "skill-tests task: Loan application data requirements (data requirement capture skills)"@en ; dcterms:source "Review checklist 01-requirements, row 1; 29148 5.2.5 (singular); `REQ-004`"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-102" ; rdfs:label "Recognises a data requirement prescribing a design solution"@en ; skos:prefLabel "Recognises a data requirement prescribing a design solution"@en ; skos:altLabel "Solution instead of need (data requirement)"@en ; skos:definition "The statement names a table, column, index, datatype, system field or screen. The design is frozen before modelling and the need behind it is lost."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "data requirement prescribing a design solution"@en ; edu:expectedResult "The design element named and the business requirement behind it"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `DR-008` \"Create a payment table with an index on the payment number column.\" Acceptable: \"Payments staff must be able to find a payment by its payment reference.\" The proposed table and index go in `rationale`."@en ; edu:assessmentMethod "skill-tests task: Loan application data requirements (data requirement capture skills)"@en ; dcterms:source "Review checklist 01-requirements, row 2; 29148 5.2.5 (appropriate: implementation-free); `REQ-012`"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-103" ; rdfs:label "Recognises a statement outside the scope of data requirements"@en ; skos:prefLabel "Recognises a statement outside the scope of data requirements"@en ; skos:altLabel "Not a data requirement (data requirement)"@en ; skos:definition "The statement is about a process, a deadline, a person's duty, performance or usability. The schema cannot satisfy it; at most it can record the data that shows whether it was met."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "process, deadline, duty or performance statement"@en ; edu:expectedResult "The statement and whose requirement it is instead"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: \"Payments must be processed efficiently.\" \"A payment must be settled within one working day.\" Acceptable: \"Every payment must record the date on which it was settled.\" The one-working-day duty becomes an activity rule at stage 3 with `enforcement: out-of-scope`."@en ; edu:assessmentMethod "skill-tests task: Loan application data requirements (data requirement capture skills)"@en ; dcterms:source "Review checklist 01-requirements, row 3; 29148 5.2.5 (appropriate); Witt"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-104" ; rdfs:label "Recognises an ambiguous business term in a data requirement"@en ; skos:prefLabel "Recognises an ambiguous business term in a data requirement"@en ; skos:altLabel "Ambiguous term (data requirement)"@en ; skos:definition "A business word that has two meanings in the organisation, or a qualifier nobody has defined. Two readers would select different records."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "ambiguous business term"@en ; edu:expectedResult "The term and its competing meanings"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: \"Store the address of every active customer.\" (active since when? by which measure?) Acceptable: \"Store the address of every customer who holds an open account.\" Or keep active customer, mark it for the glossary and add an `open_question` until it is defined."@en ; edu:assessmentMethod "skill-tests task: Loan application data requirements (data requirement capture skills)"@en ; dcterms:source "Review checklist 01-requirements, row 4; 29148 5.2.5 (unambiguous)"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-105" ; rdfs:label "Recognises untestable wording in a data requirement"@en ; skos:prefLabel "Recognises untestable wording in a data requirement"@en ; skos:altLabel "Vague or unbounded wording (data requirement)"@en ; skos:definition "Words that cannot be tested: appropriate, relevant, as needed, where possible, timely, up to date, user-friendly, etc., and/or, including but not limited to."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "vague or unbounded wording"@en ; edu:expectedResult "The words no test can check and what would make them testable"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: \"Payment data must be kept up to date where possible.\" Acceptable: \"A change of account status must be recorded no later than one working day after the decision.\""@en ; edu:assessmentMethod "skill-tests task: Loan application data requirements (data requirement capture skills)"@en ; dcterms:source "Review checklist 01-requirements, row 5; 29148 5.2.7"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-106" ; rdfs:label "Recognises an unverifiable data requirement"@en ; skos:prefLabel "Recognises an unverifiable data requirement"@en ; skos:altLabel "Not verifiable (data requirement)"@en ; skos:definition "Nobody could design a test that passes or fails the requirement. Common in `data-quality` requirements with no measure, threshold or reference."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "data requirement with no possible test"@en ; edu:expectedResult "The requirement and the measure, threshold or reference it lacks"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: \"Customer addresses must be accurate.\" Acceptable: \"Every customer's residential address must match an address in the national address register, checked at onboarding and at each KYC review.\""@en ; edu:assessmentMethod "skill-tests task: Loan application data requirements (data requirement capture skills)"@en ; dcterms:source "Review checklist 01-requirements, row 6; 29148 5.2.5 (verifiable)"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-107" ; rdfs:label "Recognises a reference with several possible referents"@en ; skos:prefLabel "Recognises a reference with several possible referents"@en ; skos:altLabel "Vague reference (data requirement)"@en ; skos:definition "it, this, they, the same, the above, the relevant date with more than one possible referent."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "pronoun or reference in a data requirement"@en ; edu:expectedResult "The reference and its candidate referents"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: \"When a card is linked to an account, it must have an open status.\" (the card or the account?) Acceptable: \"When a card is linked to an account, the account must have status Open.\""@en ; edu:assessmentMethod "skill-tests task: Loan application data requirements (data requirement capture skills)"@en ; dcterms:source "Review checklist 01-requirements, row 7; 29148 5.2.7 (vague pronouns)"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-108" ; rdfs:label "Recognises a data requirement without a named subject"@en ; skos:prefLabel "Recognises a data requirement without a named subject"@en ; skos:altLabel "Subject not named (data requirement)"@en ; skos:definition "The statement does not say which thing the data belongs to, or which of several dates, amounts or parties it means."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "data requirement without its thing, date, amount or party"@en ; edu:expectedResult "The requirement and the thing, date or party it must name"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: \"The date must be recorded.\" Acceptable: \"Every payment must record its booking date, the date on which the entry is posted to the account.\""@en ; edu:assessmentMethod "skill-tests task: Loan application data requirements (data requirement capture skills)"@en ; dcterms:source "Review checklist 01-requirements, row 8; 29148 5.2.5 (complete)"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-109" ; rdfs:label "Recognises a measure stated without unit or basis"@en ; skos:prefLabel "Recognises a measure stated without unit or basis"@en ; skos:altLabel "Measure without unit or basis (data requirement)"@en ; skos:definition "An amount, area, count or rate with no unit, currency, precision, inclusion rule (gross/net, with/without VAT) or reference period."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "amount, count or rate without unit, precision or basis"@en ; edu:expectedResult "The measure and its missing unit, currency, precision or basis"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: \"Record the payment amount.\" `DR-005` \"Payment payments are recorded in the ledger currency.\" with the currency itself still unknown Acceptable: \"Every payment must record the amount credited or debited in the account's currency, as an ISO 4217 code, to two decimal places.\" `DR-005` stays `draft` until its `open_question` is answered."@en ; edu:assessmentMethod "skill-tests task: Loan application data requirements (data requirement capture skills)"@en ; dcterms:source "Review checklist 01-requirements, row 9; 29148 5.2.5 (complete); Stage 1"@en ; edu:appliesKnowledge ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-110" ; rdfs:label "Recognises a data requirement silent on current versus past values"@en ; skos:prefLabel "Recognises a data requirement silent on current versus past values"@en ; skos:altLabel "Time not stated (data requirement)"@en ; skos:definition "The requirement does not say whether the business needs only the current value or also what the value was at an earlier date. This decides history, effective dating and SCD strategy."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "data requirement without its time perspective"@en ; edu:expectedResult "The requirement and the question of current value or history"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: \"Record the customer's address.\" Acceptable: \"Record the customer's address as it was on a payment's value date, so a past statement can be reproduced with the address in force at the time.\""@en ; edu:assessmentMethod "skill-tests task: Loan application data requirements (data requirement capture skills)"@en ; dcterms:source "Review checklist 01-requirements, row 10; Stage 1 (time)"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-111" ; rdfs:label "Recognises an absolute statement with its exception unasked"@en ; skos:prefLabel "Recognises an absolute statement with its exception unasked"@en ; skos:altLabel "Absolute without the exception (data requirement)"@en ; skos:definition "every, always, never, exactly one, all stated with nobody having asked when it is not true. Usually the optional side has been assumed mandatory because the sample data always had a value."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "every, always, never or exactly-one statement"@en ; edu:expectedResult "The absolute and the case it may not hold for"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: \"Every account has one account holder.\" Acceptable: \"Every sole account has exactly one account holder. A joint account has at least two.\" (both sourced, or the second as an `open_question`)"@en ; edu:assessmentMethod "skill-tests task: Loan application data requirements (data requirement capture skills)"@en ; dcterms:source "Review checklist 01-requirements, row 11; Stage 1 (hunt for the exceptions); 29148 5.2.5 (correct)"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-112" ; rdfs:label "Recognises a mandatory attribute without its moment of obligation"@en ; skos:prefLabel "Recognises a mandatory attribute without its moment of obligation"@en ; skos:altLabel "Mandatory at creation not distinguished (data requirement)"@en ; skos:definition "\"Mandatory\" or \"required\" with no indication of when: at creation, before a status change, or eventually. Batch loads and integrations break on the difference."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "mandatory requirement without its moment"@en ; edu:expectedResult "The requirement and the moment it applies at: creation, status change or eventually"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Product data spreadsheet: \"Customer date of birth … Mandatory: TRUE\" Acceptable: \"A natural-person customer must have a date of birth before an account is opened for them; a prospect record may be created without one.\""@en ; edu:assessmentMethod "skill-tests task: Loan application data requirements (data requirement capture skills)"@en ; dcterms:source "Review checklist 01-requirements, row 12; Stage 1 (rules: both directions and optionality)"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-113" ; rdfs:label "Recognises a business rule left inside another statement"@en ; skos:prefLabel "Recognises a business rule left inside another statement"@en ; skos:altLabel "Candidate rule not captured (data requirement)"@en ; skos:definition "A rule stated in the source or by a stakeholder survives only inside a `data-item` statement, a spreadsheet column or a meeting note, instead of as its own `type: data-rule` requirement. Stage 3 formalises requirements, so it will never see it. An empty `rules` list is expected at stage 1 and is not this defect."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "rule buried in a data-item statement, cell or note"@en ; edu:expectedResult "The buried rule as its own data-rule requirement"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Spreadsheet row IBAN, Business rules column: \"Every account has an IBAN. No two accounts share an IBAN.\", captured as one `data-item` requirement \"Every account has an IBAN.\" Acceptable: `data-item` \"Every account must be identified by its IBAN.\" plus two `data-rule` requirements in the source's words: \"Each account has exactly one IBAN.\" and \"An IBAN is never assigned to more than one account.\" Stage 3 formalises both and fills `rules`."@en ; edu:assessmentMethod "skill-tests task: Loan application data requirements (data requirement capture skills)"@en ; dcterms:source "Review checklist 01-requirements, row 13; Stage 1 (candidate rules); `03-data-rules.md` row 18"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-114" ; rdfs:label "Recognises content filed under the wrong requirement"@en ; skos:prefLabel "Recognises content filed under the wrong requirement"@en ; skos:altLabel "Content attached to the wrong requirement (data requirement)"@en ; skos:definition "A rule, note or value in the source belongs to a different requirement than the one it is filed under. Typical in spreadsheets where rows were inserted or sorted."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "rule, note or value under the wrong requirement"@en ; edu:expectedResult "The content and the requirement it belongs to"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Spreadsheet row Account type carries the rule \"Must be a valid ISO 4217 code\", which is about Account currency in the next row Acceptable: The ISO 4217 rule moved to the Account currency requirement; Account type gets its own candidate rule (its value comes from the product catalogue) or none."@en ; edu:assessmentMethod "skill-tests task: Loan application data requirements (data requirement capture skills)"@en ; dcterms:source "Review checklist 01-requirements, row 14; 29148 5.2.5 (correct)"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-115" ; rdfs:label "Recognises an unsourced data requirement"@en ; skos:prefLabel "Recognises an unsourced data requirement"@en ; skos:altLabel "Unsourced (data requirement)"@en ; skos:definition "No `source.document` and no `source.stakeholder`, or a document with no `locator`. An unsourced requirement can never be safely dropped, because nobody knows whom to ask."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "requirement without document, locator or stakeholder"@en ; edu:expectedResult "The requirement and the source it needs"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `DR-002` \"Each payment carries a settlement currency.\" with no source Acceptable: `source: {document: \"Payments Handling Process v3.2\", locator: \"§5.3\", stakeholder: \"Finance\", captured: 2026-09-04}`"@en ; edu:assessmentMethod "skill-tests task: Loan application data requirements (data requirement capture skills)"@en ; dcterms:source "Review checklist 01-requirements, row 15; Stage 1 (where requirements come from); `REQ-005`"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-116" ; rdfs:label "Recognises a missing or meaningless requirement priority"@en ; skos:prefLabel "Recognises a missing or meaningless requirement priority"@en ; skos:altLabel "Priority missing or meaningless (data requirement)"@en ; skos:definition "No priority, or every requirement is `must`. Test: if this were the only thing not delivered, would the release be cancelled?"@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "requirement priority"@en ; edu:expectedResult "The requirements whose priority is missing or uniformly must"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `DR-003` with no priority; a register in which 40 of 42 requirements are `must` Acceptable: Priorities that survive the cancellation test, with `must` reserved for the ones that do."@en ; edu:assessmentMethod "skill-tests task: Loan application data requirements (data requirement capture skills)"@en ; dcterms:source "Review checklist 01-requirements, row 16; 29148 5.2.8 (priority); `REQ-006`"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-117" ; rdfs:label "Recognises a missing or wrong requirement type"@en ; skos:prefLabel "Recognises a missing or wrong requirement type"@en ; skos:altLabel "Type missing or wrong (data requirement)"@en ; skos:definition "No `type`, a value outside the seven in the schema, or a type that does not match the statement. The type decides where the requirement lands later."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "requirement type"@en ; edu:expectedResult "The requirement and the type its statement implies"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `DR-009` \"Payment volumes reach ninety thousand rows a year.\" with `type: reporting` Acceptable: `type: volume`. A requirement for a report becomes one requirement per question the report answers (row 32), each typed by what it asks for."@en ; edu:assessmentMethod "skill-tests task: Loan application data requirements (data requirement capture skills)"@en ; dcterms:source "Review checklist 01-requirements, row 17; 29148 5.2.8 (type); `REQ-013`, `REQ-014`"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-118" ; rdfs:label "Recognises a status contradicting the requirement's content"@en ; skos:prefLabel "Recognises a status contradicting the requirement's content"@en ; skos:altLabel "Status contradicts content (data requirement)"@en ; skos:definition "`confirmed` with an unanswered `open_question`, `confirmed` with no steward sign-off, or no status at all. A confirmed status is a sign-off; one that did not happen is worse than none."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "requirement status"@en ; edu:expectedResult "The status and the open question or missing sign-off it contradicts"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `DR-005` `status: confirmed` with `open_question: \"Is the ledger currency the account currency or the group currency?\"`; `DR-010` with no status Acceptable: `DR-005` held at `draft` until Finance answers; `DR-010` given `status: draft` until Legal confirms it."@en ; edu:assessmentMethod "skill-tests task: Loan application data requirements (data requirement capture skills)"@en ; dcterms:source "Review checklist 01-requirements, row 18; Stage 1; `REQ-007`, `REQ-009`"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-119" ; rdfs:label "Recognises a guess recorded as fact"@en ; skos:prefLabel "Recognises a guess recorded as fact"@en ; skos:altLabel "Guess recorded as fact (data requirement)"@en ; skos:definition "A gap in the source filled with a plausible value and no `open_question`. Also: a requirement reverse-engineered from an existing schema or sample data, recorded as a business need."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "filled-in gap or reverse-engineered requirement"@en ; edu:expectedResult "The guessed content and the open question it should be"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: \"Payment references are unique.\" taken from a unique index in the legacy database, `stakeholder: Payments Ops`, `status: confirmed` Acceptable: `source.document: \"existing system: PAYMENTS_DB DDL\"`, `status: draft`, `rationale: \"describes current behaviour, not confirmed as a business need\"`, plus an `open_question` for Payments Ops."@en ; edu:assessmentMethod "skill-tests task: Loan application data requirements (data requirement capture skills)"@en ; dcterms:source "Review checklist 01-requirements, row 19; Stage 1 (record what you did not get)"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-120" ; rdfs:label "Recognises a missing rationale for a non-obvious requirement"@en ; skos:prefLabel "Recognises a missing rationale for a non-obvious requirement"@en ; skos:altLabel "No rationale where one is needed (data requirement)"@en ; skos:definition "A requirement whose reason is not obvious — regulatory, contractual, or one that a stakeholder supplied as a solution — has no `rationale`. Nobody can later tell whether it can be dropped."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "regulatory, contractual or solution-supplied requirement without rationale"@en ; edu:expectedResult "The requirement and the rationale it needs"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `DR-010` \"Retention of closed payment records is seven years.\" with no rationale Acceptable: `rationale: \"Statutory retention period for payment records; Legal, 2026-09-04.\"`"@en ; edu:assessmentMethod "skill-tests task: Loan application data requirements (data requirement capture skills)"@en ; dcterms:source "Review checklist 01-requirements, row 20; 29148 5.2.8 (rationale)"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-121" ; rdfs:label "Recognises duplicate data requirements"@en ; skos:prefLabel "Recognises duplicate data requirements"@en ; skos:altLabel "Duplicate (data requirement)"@en ; skos:definition "Two requirements with the same statement. Two IDs will be traced, prioritised and tested separately, and will drift apart."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "requirements with identical statements"@en ; edu:expectedResult "The duplicate pair and the one to retire"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `DR-006` and `DR-007`, both \"Every payment must record the date on which the payment was instructed.\" Acceptable: Keep `DR-006`; set `DR-007` to `retired` with `superseded_by: DR-006`."@en ; edu:assessmentMethod "skill-tests task: Loan application data requirements (data requirement capture skills)"@en ; dcterms:source "Review checklist 01-requirements, row 21; 29148 5.2.6 (consistent); `REQ-010`"@en ; edu:appliesKnowledge ; edu:followedBy ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-122" ; rdfs:label "Recognises paraphrased data requirements"@en ; skos:prefLabel "Recognises paraphrased data requirements"@en ; skos:altLabel "Paraphrase (data requirement)"@en ; skos:definition "Two requirements that say the same thing in different words, often from different stakeholders or documents. The script finds close wording; a person finds the same need described differently."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "requirements stating one need in different words"@en ; edu:expectedResult "The paraphrase pair and the one to retire"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `DR-011` \"…the date on which the payment was instructed by the payer\" alongside `DR-006`; the first half of `DR-001` says the same again Acceptable: One requirement; the second stakeholder or document recorded in `rationale` or a YAML comment, and the others retired with `superseded_by`."@en ; edu:assessmentMethod "skill-tests task: Loan application data requirements (data requirement capture skills)"@en ; dcterms:source "Review checklist 01-requirements, row 22; 29148 5.2.6 (consistent); `REQ-011`"@en ; edu:appliesKnowledge ; edu:followedBy ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-123" ; rdfs:label "Recognises conflicting data requirements"@en ; skos:prefLabel "Recognises conflicting data requirements"@en ; skos:altLabel "Conflict (data requirement)"@en ; skos:definition "Two requirements that cannot both be met, or that give the same thing two different values, units or sources. Usually a missing condition or scope."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "requirements both of which cannot be met"@en ; edu:expectedResult "The conflicting pair and the condition or scope reconciling them"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `DR-010` \"keep closed payment records for seven years\" and a privacy requirement \"delete a counterparty's personal data on request\" Acceptable: Both kept, with the condition that reconciles them written into each: personal data not needed for the statutory record is erased on request; the rest is kept for seven years and then erased."@en ; edu:assessmentMethod "skill-tests task: Loan application data requirements (data requirement capture skills)"@en ; dcterms:source "Review checklist 01-requirements, row 23; 29148 5.2.6 (consistent)"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-124" ; rdfs:label "Recognises inconsistent terminology across the register"@en ; skos:prefLabel "Recognises inconsistent terminology across the register"@en ; skos:altLabel "Inconsistent terminology (data requirement)"@en ; skos:definition "The same thing under different words in different requirements (payer, counterparty, account holder used interchangeably), or one word for two things. Stage 2 will either merge things that differ or split one thing in two."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "one thing under several words, or one word for several things"@en ; edu:expectedResult "The variant words and the term to agree with the steward"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `DR-004` speaks of the disputes specialist and `DR-12` of payments handlers, and nothing says whether they are one role or two Acceptable: One word per thing across the register, chosen with the steward; the variants listed for stage 2 as synonyms."@en ; edu:assessmentMethod "skill-tests task: Loan application data requirements (data requirement capture skills)"@en ; dcterms:source "Review checklist 01-requirements, row 24; 29148 5.2.6 (comprehensible)"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-125" ; rdfs:label "Recognises a requirements register with unbounded scope"@en ; skos:prefLabel "Recognises a requirements register with unbounded scope"@en ; skos:altLabel "Scope not bounded (data requirement)"@en ; skos:definition "Nothing says what the data is for, what is out of scope, or which existing systems hold overlapping data. Requirements keep arriving and none can be declined."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "register without stated purpose, exclusions or overlapping systems"@en ; edu:expectedResult "The missing purpose, exclusions and overlapping systems"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: A payments mart register with no statement of whether card transactions or payments from the correspondent-banking channel are in scope Acceptable: A scope note in the project (purpose, in, out, overlapping systems) and out-of-scope requests recorded as `status: rejected` with a reason."@en ; edu:assessmentMethod "skill-tests task: Loan application data requirements (data requirement capture skills)"@en ; dcterms:source "Review checklist 01-requirements, row 25; 29148 5.2.6 (complete); Stage 1 (scope and purpose)"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-126" ; rdfs:label "Recognises a requirements register describing no events"@en ; skos:prefLabel "Recognises a requirements register describing no events"@en ; skos:altLabel "Only things, no events (data requirement)"@en ; skos:definition "Requirements describe nouns and their attributes, and nothing about what happens to them: status changes, reopenings, payments, corrections, cancellations. Events carry most volume, history and temporal rules."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "register describing only things"@en ; edu:expectedResult "The things whose events, changes and corrections are missing"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Twelve requirements about account attributes, none about how an account becomes dormant or blocked, or what a status change must record Acceptable: \"Every change of account status must record the date, the new status and the reason.\" \"Every payment reversal must record …\""@en ; edu:assessmentMethod "skill-tests task: Loan application data requirements (data requirement capture skills)"@en ; dcterms:source "Review checklist 01-requirements, row 26; Stage 1 (the events)"@en ; edu:appliesKnowledge ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-127" ; rdfs:label "Recognises an uncovered identity requirement"@en ; skos:prefLabel "Recognises an uncovered identity requirement"@en ; skos:altLabel "Identity not covered (data requirement)"@en ; skos:definition "For a significant thing, nothing says how the business tells one from another, who assigns the identifier, whether it can change, and whether it can be reused. Reused identifiers silently corrupt history."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "significant thing without identification requirements"@en ; edu:expectedResult "The thing and its missing identifier, assigner, change and reuse rules"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Account requirements that never say whether an account number can be reused after the account is closed Acceptable: \"An account is identified by its IBAN, assigned by the bank at opening; it does not change and is not reused after the account is closed.\" (with source)"@en ; edu:assessmentMethod "skill-tests task: Loan application data requirements (data requirement capture skills)"@en ; dcterms:source "Review checklist 01-requirements, row 27; Stage 1 (identity)"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-128" ; rdfs:label "Recognises an uncovered volume or retention requirement"@en ; skos:prefLabel "Recognises an uncovered volume or retention requirement"@en ; skos:altLabel "Volume and retention not covered (data requirement)"@en ; skos:definition "A significant thing with no volume, growth or retention requirement, or a retention period with no end-of-life action (delete, anonymise, archive)."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "significant thing without volume, growth or end-of-life action"@en ; edu:expectedResult "The thing and its missing volume, growth or retention action"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Payments have a retention requirement (`DR-010`); accounts and payment advice documents have none Acceptable: One `volume` and one `retention` requirement per significant thing, each saying what happens at the end of the period."@en ; edu:assessmentMethod "skill-tests task: Loan application data requirements (data requirement capture skills)"@en ; dcterms:source "Review checklist 01-requirements, row 28; 29148 5.2.6 (complete); Stage 1 (volumes, growth and retention)"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-129" ; rdfs:label "Recognises an uncovered sensitivity or access requirement"@en ; skos:prefLabel "Recognises an uncovered sensitivity or access requirement"@en ; skos:altLabel "Sensitivity and access not covered (data requirement)"@en ; skos:definition "Personal, confidential or regulated data with no `access` requirement, so classification, masking and row-level access are designed later from guesswork."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "personal or regulated data without access requirement"@en ; edu:expectedResult "The data and the access requirement it needs"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Customer personal identification codes mentioned in a data-item requirement and nowhere else Acceptable: \"A customer's personal identification code is visible only to staff servicing that customer's accounts.\" `type: access`, sourced to the data protection policy."@en ; edu:assessmentMethod "skill-tests task: Loan application data requirements (data requirement capture skills)"@en ; dcterms:source "Review checklist 01-requirements, row 29; Stage 1 (sensitivity and access)"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-130" ; rdfs:label "Recognises an uncovered lineage requirement"@en ; skos:prefLabel "Recognises an uncovered lineage requirement"@en ; skos:altLabel "Source and ownership not covered (data requirement)"@en ; skos:definition "No `lineage` requirement says where the data for a thing comes from, who owns it, and how often it arrives."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "thing without source, owner and arrival frequency"@en ; edu:expectedResult "The thing and its missing lineage"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: A customer risk rating required, with no requirement saying whether it is calculated in the AML screening system or entered by the relationship manager Acceptable: \"The customer risk rating is loaded daily from the AML screening system, which is its system of record.\" `type: lineage`."@en ; edu:assessmentMethod "skill-tests task: Loan application data requirements (data requirement capture skills)"@en ; dcterms:source "Review checklist 01-requirements, row 30; 29148 5.2.6 (complete); Stage 1 (sources and ownership)"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-131" ; rdfs:label "Recognises undecided history requirements across the register"@en ; skos:prefLabel "Recognises undecided history requirements across the register"@en ; skos:altLabel "History need not settled (data requirement)"@en ; skos:definition "Row 10 across the register: for each significant thing, nobody has answered whether a past report must be reproducible exactly as published."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "register-wide reproducibility of past reports"@en ; edu:expectedResult "The significant things whose history need is undecided"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Rate, status and address requirements with no statement either way Acceptable: One answer per thing, recorded as a requirement or as an `open_question` that blocks the logical model."@en ; edu:assessmentMethod "skill-tests task: Loan application data requirements (data requirement capture skills)"@en ; dcterms:source "Review checklist 01-requirements, row 31; Stage 1 (time)"@en ; edu:dependsOnKnobit ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-132" ; rdfs:label "Recognises a requirements register serving no stated question"@en ; skos:prefLabel "Recognises a requirements register serving no stated question"@en ; skos:altLabel "No question the data must answer (data requirement)"@en ; skos:definition "The register lists data items but no question, report or decision they serve, so grain, measures and temporality cannot be derived and nobody can say a requirement is unnecessary."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "register without questions, reports or decisions"@en ; edu:expectedResult "The missing questions the data must answer"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Thirty `data-item` requirements and no reporting need Acceptable: \"As of any month end, report the number of open accounts and their total ledger balance, by product.\""@en ; edu:assessmentMethod "skill-tests task: Loan application data requirements (data requirement capture skills)"@en ; dcterms:source "Review checklist 01-requirements, row 32; Stage 1 (questions the data must answer)"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-133" ; rdfs:label "Recognises a missing or wrong requirement trace"@en ; skos:prefLabel "Recognises a missing or wrong requirement trace"@en ; skos:altLabel "Trace missing or wrong (data requirement)"@en ; skos:definition "A confirmed `must` requirement that no business term (stage 2) and, later, no physical column realises: the business asked, everyone agreed, nothing was built. Also a `terms` link to a term that does not realise the requirement, which passes every script check and traces the need to the wrong thing."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "trace from requirement to term or column"@en ; edu:expectedResult "The confirmed requirement nothing realises, or the wrong trace"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `DR-004` (disputes specialist), `must`, `confirmed`, `terms: []`. `DR-002` (settlement currency) citing `BT-002` Payment Payment Value Date Acceptable: `DR-004` citing the Disputes Specialist term, carried through to a column, or deliberately deferred with a reason. `DR-002` citing `BT-007` Settlement Currency."@en ; edu:assessmentMethod "skill-tests task: Loan application data requirements (data requirement capture skills)"@en ; dcterms:source "Review checklist 01-requirements, row 33; `REQ-008`, `TRC-001`"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-134" ; rdfs:label "Recognises unstable requirement identifiers"@en ; skos:prefLabel "Recognises unstable requirement identifiers"@en ; skos:altLabel "Requirement identity not stable (data requirement)"@en ; skos:definition "Missing or malformed IDs, renumbering, or requirements deleted instead of retired. A signed-off document elsewhere may already cite the ID."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "requirement identifiers"@en ; edu:expectedResult "The missing, malformed, renumbered or deleted identifiers"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `DR-12`; spreadsheet rows Overdraft limit and Interest rate type with no requirement number Acceptable: `DR-012`; every source row given an ID; obsolete requirements set to `retired` with `superseded_by`, never removed."@en ; edu:assessmentMethod "skill-tests task: Loan application data requirements (data requirement capture skills)"@en ; dcterms:source "Review checklist 01-requirements, row 34; 29148 5.2.8 (identification); `REQ-001`, `REQ-003`, `REQ-016`"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-310" ; rdfs:label "Recognises a constraint claimed by a rule and missing from the schema"@en ; skos:prefLabel "Recognises a constraint claimed by a rule and missing from the schema"@en ; skos:altLabel "Rule claims schema enforcement it does not have (data rule)"@en ; skos:altLabel "Logical constraint lost on the way down (physical model)"@en ; skos:altLabel "Rule marked `constraint` with no constraint in the SQL (generated DDL)"@en ; skos:definition "`enforcement: constraint` where the physical model carries no matching constraint."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "rule whose enforcement is claimed as a schema constraint"@en ; edu:expectedResult "The rule and the absent constraint, with where to add it or how to make the enforcement honest"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: A mandatory rule whose column is `nullable: true` Acceptable: Either the column is `NOT NULL`, or the rule's enforcement is honestly `dq-check` (`ANO-010`)"@en ; edu:assessmentMethod "skill-tests task: Loan application data rules (data rule anomaly skills)"@en ; dcterms:source "Shared-URI copy of data-quality Q-210 (Review checklist 02-data-rules (data-quality), row 10)"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-313" ; rdfs:label "Recognises a declared constraint the target platform does not enforce"@en ; skos:prefLabel "Recognises a declared constraint the target platform does not enforce"@en ; skos:altLabel "Rule lost to a non-enforcing platform (data rule)"@en ; skos:altLabel "Constraint the platform does not enforce (physical model)"@en ; skos:altLabel "Constraint the platform does not enforce, with no check (data quality rule)"@en ; skos:altLabel "`-- NOT ENFORCED` read as a guarantee (generated DDL)"@en ; skos:definition "Snowflake and Databricks accept constraint syntax and enforce none of it, so every rule marked `constraint` there is unenforced."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "constraint declared on Snowflake, Databricks or another non-enforcing target"@en ; edu:expectedResult "The constraint, the fact nothing enforces it, and the data quality check it needs"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `enforcement: constraint` on a Snowflake target, with nothing else Acceptable: A DQ rule citing it as well, so the load is the guarantee and the check reports breaches (`DQR-017`)"@en ; edu:assessmentMethod "skill-tests task: Loan application data rules (data rule anomaly skills)"@en ; dcterms:source "Shared-URI copy of data-quality Q-213 (Review checklist 02-data-rules (data-quality), row 13)"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-401" ; rdfs:label "Recognises an ambiguous node label"@en ; skos:prefLabel "Recognises an ambiguous node label"@en ; skos:altLabel "Ambiguous node label (taxonomy)"@en ; skos:definition "A label that means different things to different readers, with no qualifier or more specific name to tell the meanings apart."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "node label with several readings"@en ; edu:expectedResult "The label and the qualifier distinguishing its meanings"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Account under Product and Account under Finance (customer account and general ledger account) Acceptable: Customer account and General ledger account; or qualifiers: Account (customer), Account (general ledger)"@en ; edu:assessmentMethod "skill-tests task: Party taxonomy (data taxonomy skills); skill-tests task: Taxonomy from business term definitions (broader/narrower only)"@en ; dcterms:source "Review checklist 02-conceptual-taxonomies, row 1; z39.19: 5.3.1, 6.2.1"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-402" ; rdfs:label "Recognises a node with an unclear boundary and no scope note"@en ; skos:prefLabel "Recognises a node with an unclear boundary and no scope note"@en ; skos:altLabel "Unclear boundary without a scope note (taxonomy)"@en ; skos:definition "A node whose boundary is not obvious from its label has no scope note saying what belongs there and what does not. Catch-all nodes such as Other are the most common case."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "node without scope note"@en ; edu:expectedResult "The node and the scope note it needs"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Other products, with nothing saying what belongs there Acceptable: Product not elsewhere classified, with the scope note \"products that are not loans, cards or deposits; reviewed at each release\""@en ; edu:assessmentMethod "skill-tests task: Party taxonomy (data taxonomy skills); skill-tests task: Taxonomy from business term definitions (broader/narrower only)"@en ; dcterms:source "Review checklist 02-conceptual-taxonomies, row 2; z39.19: 6.2.2"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-403" ; rdfs:label "Recognises overlapping sibling nodes without reciprocal scope notes"@en ; skos:prefLabel "Recognises overlapping sibling nodes without reciprocal scope notes"@en ; skos:altLabel "Overlapping siblings without reciprocal scope notes (taxonomy)"@en ; skos:definition "Two siblings whose meanings overlap in everyday use, where neither scope note refers to the other, so the same case is classified two ways."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "overlapping siblings"@en ; edu:expectedResult "The siblings and their reciprocal scope notes"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: SME customer and Corporate customer, with nothing saying where one ends (a company with 60 million EUR turnover and 200 staff fits both) Acceptable: Corporate customer: \"legal person with annual turnover above 50 million EUR; for smaller legal persons see SME customer\"; SME customer: \"...; for larger see Corporate customer\""@en ; edu:assessmentMethod "skill-tests task: Party taxonomy (data taxonomy skills); skill-tests task: Taxonomy from business term definitions (broader/narrower only)"@en ; dcterms:source "Review checklist 02-conceptual-taxonomies, row 3; z39.19: 6.2.2.1"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-404" ; rdfs:label "Recognises a meaning change without a history note"@en ; skos:prefLabel "Recognises a meaning change without a history note"@en ; skos:altLabel "Change of meaning without a history note (taxonomy)"@en ; skos:definition "A node's meaning or scope was changed in place, with no note of when and how, so data classified before and after the change looks comparable when it is not."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "node changed in place"@en ; edu:expectedResult "The node and the history note recording when and how"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Segment Retail widened to include sole traders by editing its definition Acceptable: Change recorded in a history note: \"From 2026-01-01 includes sole traders; before that, natural persons only\""@en ; edu:assessmentMethod "skill-tests task: Party taxonomy (data taxonomy skills); skill-tests task: Taxonomy from business term definitions (broader/narrower only)"@en ; dcterms:source "Review checklist 02-conceptual-taxonomies, row 4; z39.19: 6.2.3"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-405" ; rdfs:label "Recognises a node without warrant"@en ; skos:prefLabel "Recognises a node without warrant"@en ; skos:altLabel "Node without warrant (taxonomy)"@en ; skos:definition "A node appears in no source document, is not used by the business and is not required by the organisation. Nobody asked for it, so nobody can confirm what it means."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "node no source, user or organisation asked for"@en ; edu:expectedResult "The node and its missing warrant"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Hybrid customer, which appears in no requirement, document or conversation Acceptable: Every node traceable to a business term with `source_requirements`, or to a documented business decision; otherwise removed"@en ; edu:assessmentMethod "skill-tests task: Party taxonomy (data taxonomy skills); skill-tests task: Taxonomy from business term definitions (broader/narrower only)"@en ; dcterms:source "Review checklist 02-conceptual-taxonomies, row 5; z39.19: 5.3.5, 6.1"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-406" ; rdfs:label "Recognises inconsistent node label forms"@en ; skos:prefLabel "Recognises inconsistent node label forms"@en ; skos:altLabel "Inconsistent label form (taxonomy)"@en ; skos:definition "Labels are not noun phrases (a verb or a lone adjective), or siblings use different forms: singular and plural, with and without the head noun, different capitalisation."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "sibling labels of mixed form"@en ; edu:expectedResult "The labels and the noun-phrase form to use"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Account → Current, Savings accounts, Close loan Acceptable: Account → Current account, Savings account, Loan account"@en ; edu:assessmentMethod "skill-tests task: Party taxonomy (data taxonomy skills); skill-tests task: Taxonomy from business term definitions (broader/narrower only)"@en ; dcterms:source "Review checklist 02-conceptual-taxonomies, row 6; z39.19: 6.3-6.5, 6.7"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-407" ; rdfs:label "Recognises an abbreviation, jargon or system name as a node label"@en ; skos:prefLabel "Recognises an abbreviation, jargon or system name as a node label"@en ; skos:altLabel "Abbreviation, jargon or system name as label (taxonomy)"@en ; skos:definition "The label is an abbreviation only insiders know, internal jargon, a system or table name, or a department name."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "insider label"@en ; edu:expectedResult "The label and the plain term"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Party → CRM_PARTY, KYC-2, Retail Banking Dept Acceptable: Party → Natural person, Legal person; KYC recorded as a synonym of Customer due diligence"@en ; edu:assessmentMethod "skill-tests task: Party taxonomy (data taxonomy skills); skill-tests task: Taxonomy from business term definitions (broader/narrower only)"@en ; dcterms:source "Review checklist 02-conceptual-taxonomies, row 7; z39.19: 6.6.3, 6.6.4"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-408" ; rdfs:label "Recognises a compound node combining two characteristics"@en ; skos:prefLabel "Recognises a compound node combining two characteristics"@en ; skos:altLabel "Compound node that should be split (taxonomy)"@en ; skos:definition "A node combines two independent characteristics in one label, so every combination needs its own node and the taxonomy multiplies."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "node combining two independent characteristics"@en ; edu:expectedResult "The two characteristics to split"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Customer → Online private customer, Online business customer, Branch private customer, Branch business customer Acceptable: Split into two facets: legal form (Private customer, Business customer) and channel (Online, Branch)"@en ; edu:assessmentMethod "skill-tests task: Party taxonomy (data taxonomy skills); skill-tests task: Taxonomy from business term definitions (broader/narrower only)"@en ; dcterms:source "Review checklist 02-conceptual-taxonomies, row 8; z39.19: 7.5, 7.6"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-409" ; rdfs:label "Recognises siblings divided by mixed characteristics"@en ; skos:prefLabel "Recognises siblings divided by mixed characteristics"@en ; skos:altLabel "Mixed characteristics without node labels (taxonomy)"@en ; skos:definition "Siblings under one parent are divided by different characteristics. Each array should be divided on one characteristic, stated by a node label. A node label names the characteristic; it is not a concept."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "siblings without a node label"@en ; edu:expectedResult "The characteristics mixed and the node labels needed"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Customer → Private customer, Business customer, Online customer, Premium customer (legal form, channel and value mixed) Acceptable: Customer → [by legal form] Private customer, Business customer; [by value segment] Standard customer, Premium customer; channel handled separately"@en ; edu:assessmentMethod "skill-tests task: Party taxonomy (data taxonomy skills); skill-tests task: Taxonomy from business term definitions (broader/narrower only)"@en ; dcterms:source "Review checklist 02-conceptual-taxonomies, row 9; z39.19: 5.3.4, 7.7, 8.3.5"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-410" ; rdfs:label "Recognises a synonym kept as a separate node"@en ; skos:prefLabel "Recognises a synonym kept as a separate node"@en ; skos:altLabel "Synonym as a separate node (taxonomy)"@en ; skos:definition "The same concept appears as two nodes under different names: synonyms, spelling variants or near-synonyms the business treats as one."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "synonym node"@en ; edu:expectedResult "The synonym pair and the preferred term"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Client under Retail and Customer under Party Role, with the same definition Acceptable: One node, Customer; client recorded as a synonym on its business term"@en ; edu:assessmentMethod "skill-tests task: Party taxonomy (data taxonomy skills); skill-tests task: Taxonomy from business term definitions (broader/narrower only)"@en ; dcterms:source "Review checklist 02-conceptual-taxonomies, row 10; z39.19: 5.3.2, 8.2"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-411" ; rdfs:label "Recognises a link failing the all-and-some test"@en ; skos:prefLabel "Recognises a link failing the all-and-some test"@en ; skos:altLabel "Fails the all-and-some test (taxonomy)"@en ; skos:definition "The child is not a kind of the parent always and in every context. \"Every child is a parent\" is only sometimes true."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "kind-of link true only sometimes"@en ; edu:expectedResult "The link and the context in which it fails"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Party → Person → Customer (a company can also be a customer, and a person is not always one) Acceptable: Party Role → Customer, Supplier; Party plays a Party Role"@en ; edu:assessmentMethod "skill-tests task: Party taxonomy (data taxonomy skills); skill-tests task: Taxonomy from business term definitions (broader/narrower only)"@en ; dcterms:source "Review checklist 02-conceptual-taxonomies, row 11; z39.19: 8.3.1"@en ; edu:appliesKnowledge ; edu:appliesKnowledge ; edu:followedBy ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-412" ; rdfs:label "Recognises an instance placed as a concept node"@en ; skos:prefLabel "Recognises an instance placed as a concept node"@en ; skos:altLabel "Instance as a node (taxonomy)"@en ; skos:definition "Named individual things appear as nodes. In a data model they are data, not concepts."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "named individual as node"@en ; edu:expectedResult "The instance and the concept it belongs to"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Bank → Swedbank, SEB, LHV Acceptable: Bank as a concept; individual banks held as reference data records"@en ; edu:assessmentMethod "skill-tests task: Party taxonomy (data taxonomy skills); skill-tests task: Taxonomy from business term definitions (broader/narrower only)"@en ; dcterms:source "Review checklist 02-conceptual-taxonomies, row 12; z39.19: 8.3.2"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-413" ; rdfs:label "Recognises a part-of link in a kind-of hierarchy"@en ; skos:prefLabel "Recognises a part-of link in a kind-of hierarchy"@en ; skos:altLabel "Part-of treated as kind-of (taxonomy)"@en ; skos:definition "A whole-part link sits in a kind-of hierarchy. Z39.19 allows part-of hierarchies only for a few cases: body systems, geographic locations, disciplines and hierarchical social structures."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "whole-part link as kind-of"@en ; edu:expectedResult "The link and its place outside the hierarchy"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Loan → Fixed-rate loan, Repayment instalment; Loan agreement → Repayment schedule Acceptable: Repayment instalment linked to Repayment schedule by an \"is part of\" relationship. Partitive hierarchy where Z39.19 allows it, for the branch network: Estonia → Harju County → Tallinn"@en ; edu:assessmentMethod "skill-tests task: Party taxonomy (data taxonomy skills); skill-tests task: Taxonomy from business term definitions (broader/narrower only)"@en ; dcterms:source "Review checklist 02-conceptual-taxonomies, row 13; z39.19: 8.3.3"@en ; edu:appliesKnowledge ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-414" ; rdfs:label "Recognises an unjustified polyhierarchy"@en ; skos:prefLabel "Recognises an unjustified polyhierarchy"@en ; skos:altLabel "Unjustified polyhierarchy (taxonomy)"@en ; skos:definition "A node has several parents, and at least one of them fails the all-and-some test (row 11): the second parent is a context, an aspect or a department, not a broader kind."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "node with a non-generic second parent"@en ; edu:expectedResult "The parent failing all-and-some and the relation it should be"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Collateral under Lending, Risk and Legal Acceptable: Covered bond under both Bond and Secured debt instrument: every covered bond is both"@en ; edu:assessmentMethod "skill-tests task: Party taxonomy (data taxonomy skills); skill-tests task: Taxonomy from business term definitions (broader/narrower only)"@en ; dcterms:source "Review checklist 02-conceptual-taxonomies, row 14; z39.19: 8.3.4"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-415" ; rdfs:label "Recognises an associative relationship shown as a hierarchy"@en ; skos:prefLabel "Recognises an associative relationship shown as a hierarchy"@en ; skos:altLabel "Associative relationship shown as a hierarchy (taxonomy)"@en ; skos:definition "The child is related to the parent (a process, a document, a use, a cause) but is not a kind or a part of it. It belongs in a relationship, not in the hierarchy."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "associated concept placed as child"@en ; edu:expectedResult "The link and the relationship to record instead"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Loan → Credit assessment, Loan disbursement, Loan agreement document Acceptable: Loan → Secured loan, Unsecured loan; Credit assessment related to Loan by \"assesses\""@en ; edu:assessmentMethod "skill-tests task: Party taxonomy (data taxonomy skills); skill-tests task: Taxonomy from business term definitions (broader/narrower only)"@en ; dcterms:source "Review checklist 02-conceptual-taxonomies, row 15; z39.19: 8.4"@en ; edu:appliesKnowledge ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-416" ; rdfs:label "Recognises non-reciprocal hierarchy links"@en ; skos:prefLabel "Recognises non-reciprocal hierarchy links"@en ; skos:altLabel "Links not reciprocal (taxonomy)"@en ; skos:definition "The two directions of a link disagree. In this schema a hierarchy is recorded twice, as `parent` on the concept and as `children` in the taxonomy; compare them."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "parent and children records disagreeing"@en ; edu:expectedResult "The disagreeing links"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: CC-005 has `parent: CC-001`, but the taxonomy lists CC-005 under CC-002 Acceptable: `parent` and `children` agree for every link"@en ; edu:assessmentMethod "skill-tests task: Party taxonomy (data taxonomy skills); skill-tests task: Taxonomy from business term definitions (broader/narrower only)"@en ; dcterms:source "Review checklist 02-conceptual-taxonomies, row 16; z39.19: 8.1"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-417" ; rdfs:label "Recognises uneven levels of specificity among siblings"@en ; skos:prefLabel "Recognises uneven levels of specificity among siblings"@en ; skos:altLabel "Uneven level of specificity (taxonomy)"@en ; skos:definition "Siblings sit at different levels of detail, usually because a node skipped its real parent. A node with a single child is a common sign of a missing or redundant level."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "siblings at different levels"@en ; edu:expectedResult "The skipped or redundant level"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Loan → Mortgage, Consumer loan, Home equity mortgage (a kind of mortgage) Acceptable: Loan → Mortgage → Home equity mortgage; Loan → Consumer loan"@en ; edu:assessmentMethod "skill-tests task: Party taxonomy (data taxonomy skills); skill-tests task: Taxonomy from business term definitions (broader/narrower only)"@en ; dcterms:source "Review checklist 02-conceptual-taxonomies, row 17; z39.19: 11.1.7"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-418" ; rdfs:label "Recognises a home-grown copy of an existing vocabulary"@en ; skos:prefLabel "Recognises a home-grown copy of an existing vocabulary"@en ; skos:altLabel "Home-grown copy of an existing vocabulary (taxonomy)"@en ; skos:definition "An internal list is built where an established external classification exists, or an external one is copied without a record of its authority, version and mapping."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "internal list duplicating an external classification"@en ; edu:expectedResult "The external vocabulary with its authority, version and mapping"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Currencies typed in as an internal list; ISO 4217 codes pasted into the model in 2019 with no version Acceptable: Currency classified by ISO 4217, with authority ISO, version and valid-from date recorded, and a mapping kept for any internal codes"@en ; edu:assessmentMethod "skill-tests task: Party taxonomy (data taxonomy skills); skill-tests task: Taxonomy from business term definitions (broader/narrower only)"@en ; dcterms:source "Review checklist 02-conceptual-taxonomies, row 18; z39.19: 11.1.1, 10.9.2"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-419" ; rdfs:label "Deleted or reused node (taxonomy)"@en ; skos:prefLabel "Deleted or reused node (taxonomy)"@en ; skos:definition "A node is deleted while data still refers to it, or its id or code is reused for a different concept."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "taxonomy"@en ; edu:expectedResult "A finding that names the defective taxonomy element and the defect"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Retired product code P-17 reused for a new product Acceptable: Old node kept with `status: retired` and `superseded_by`; new node gets a new id"@en ; edu:assessmentMethod "skill-tests task: Party taxonomy (data taxonomy skills); skill-tests task: Taxonomy from business term definitions (broader/narrower only)"@en ; dcterms:source "Review checklist 02-conceptual-taxonomies, row 19; z39.19: 11.3.1, 11.4.4"@en ; schema:supersededBy ; schema:supersededBy ; schema:creativeWorkStatus "superseded" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-420" ; rdfs:label "Recognises a structural error in a taxonomy hierarchy"@en ; skos:prefLabel "Recognises a structural error in a taxonomy hierarchy"@en ; skos:altLabel "Structural error (taxonomy)"@en ; skos:definition "The hierarchy contains a cycle, a node that is not a concept in the model, or no declared root. Validator: `CON-008`, `CON-009`, `CON-010`, `CON-016`."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "cycle, non-concept node or missing root"@en ; edu:expectedResult "The cycle, stray node or missing root"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Current account → Payment account → Current account; `children: [CC-099]` where CC-099 does not exist Acceptable: Decide which is broader, or merge them if they are synonyms; add CC-099 to `concepts` before referencing it"@en ; edu:assessmentMethod "skill-tests task: Party taxonomy (data taxonomy skills); skill-tests task: Taxonomy from business term definitions (broader/narrower only)"@en ; dcterms:source "Review checklist 02-conceptual-taxonomies, row 20; z39.19: 11.4.6"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-501" ; rdfs:label "Recognises an insertion anomaly in a logical data model"@en ; skos:prefLabel "Recognises an insertion anomaly in a logical data model"@en ; skos:altLabel "Insertion anomaly (logical model)"@en ; skos:definition "A fact cannot be recorded without also recording another fact it does not depend on, because it has no entity of its own."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "insertion anomaly in a logical data model"@en ; edu:expectedResult "The fact that cannot be recorded and the unrelated fact it would need"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Branch name held only on Account, so a newly opened branch cannot be recorded until an account is serviced there Acceptable: Branch as a reference entity keyed by Branch Identifier; Account carries only the identifier (cause: row 9)"@en ; edu:assessmentMethod "skill-tests task: Loan application logical model (normalisation anomaly skills)"@en ; dcterms:source "Review checklist 03-logical, row 1; Codd 1971; Fagin 1981; E&N 14.1.2; C&B"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-502" ; rdfs:label "Recognises an update anomaly in a logical data model"@en ; skos:prefLabel "Recognises an update anomaly in a logical data model"@en ; skos:altLabel "Update anomaly (logical model)"@en ; skos:definition "One fact is stored in several rows, so a change must be repeated and a partial change leaves the data contradicting itself."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "update anomaly in a logical data model"@en ; edu:expectedResult "The fact stored more than once and the rows a change would have to reach"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Account holder address held on every Account; the customer moves and three of their five accounts are updated Acceptable: Address held once on Party; Account reaches it through Account Holder"@en ; edu:assessmentMethod "skill-tests task: Loan application logical model (normalisation anomaly skills)"@en ; dcterms:source "Review checklist 03-logical, row 2; Codd 1971; E&N 14.1.2; C&B"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-503" ; rdfs:label "Recognises a deletion anomaly in a logical data model"@en ; skos:prefLabel "Recognises a deletion anomaly in a logical data model"@en ; skos:altLabel "Deletion anomaly (logical model)"@en ; skos:definition "Deleting one fact deletes another that should have survived."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "deletion anomaly in a logical data model"@en ; edu:expectedResult "The deletion and the fact that would be lost with it"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Branch BIC held only on Account; the branch's last account is closed and purged and the BIC goes with it Acceptable: Branch holds the BIC; Account references Branch"@en ; edu:assessmentMethod "skill-tests task: Loan application logical model (normalisation anomaly skills)"@en ; dcterms:source "Review checklist 03-logical, row 3; Codd 1971; Fagin 1981; E&N 14.1.2; C&B"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-504" ; rdfs:label "Recognises a repeating group in an entity"@en ; skos:prefLabel "Recognises a repeating group in an entity"@en ; skos:altLabel "Repeating group (logical model)"@en ; skos:definition "Numbered or listed attributes for the same property, or one attribute holding a list. The fourth instance has nowhere to go and every query needs one predicate per copy."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "repeating group in an entity"@en ; edu:expectedResult "The entity and the numbered or listed attributes that repeat one property"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Account with Holder 1 Party Identifier, Holder 2 Party Identifier, Holder 3 Party Identifier Acceptable: Account Holder (Account, Party, holder role, start date) (`LOG-017`)"@en ; edu:assessmentMethod "skill-tests task: Loan application logical model (normalisation anomaly skills)"@en ; dcterms:source "Review checklist 03-logical, row 4; Codd 1970 §1.4; S&W 2.6"@en ; edu:appliesKnowledge ; edu:followedBy ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-505" ; rdfs:label "Recognises an attribute holding several facts"@en ; skos:prefLabel "Recognises an attribute holding several facts"@en ; skos:altLabel "Several facts in one attribute (logical model)"@en ; skos:definition "An attribute whose value is parsed: an aggregate the business sorts or matches by part, or a code whose segments carry meaning. When the meaning of a segment changes, every value is wrong."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "attribute holding several facts"@en ; edu:expectedResult "The attribute and the separate facts its value contains"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Account Identifier (the IBAN) as one Text although reports group by bank identifier; product code CUR-TLN-2026-0042 parsed for product family, branch and year Acceptable: Country code, check digits, bank identifier and account number as separate attributes; Product Code kept opaque, with product family, branch and year as attributes of their own"@en ; edu:assessmentMethod "skill-tests task: Loan application logical model (normalisation anomaly skills)"@en ; dcterms:source "Review checklist 03-logical, row 5; S&W 2.5.1, 5.3.1–5.3.3"@en ; edu:appliesKnowledge ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-506" ; rdfs:label "Recognises an attribute with several meanings"@en ; skos:prefLabel "Recognises an attribute with several meanings"@en ; skos:altLabel "One attribute, several meanings (logical model)"@en ; skos:definition "An attribute whose meaning, format or unit depends on another attribute's value, or which merges things the business treats as different."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "attribute whose meaning depends on another attribute"@en ; edu:expectedResult "The attribute and the attribute or value its meaning varies with"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Party Identifier holding isikukood for persons and registrikood for companies; Instalment Amount meaning the principal portion or the interest portion depending on Portion Type Acceptable: A Party Identifier entity with Identifier Type from a value set, each type with its own format rule; principal portion and interest portion as separate attributes"@en ; edu:assessmentMethod "skill-tests task: Loan application logical model (normalisation anomaly skills)"@en ; dcterms:source "Review checklist 03-logical, row 6; S&W 5.3.4"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-507" ; rdfs:label "Recognises attributes held as name-value rows"@en ; skos:prefLabel "Recognises attributes held as name-value rows"@en ; skos:altLabel "Attributes held as data (EAV) (logical model)"@en ; skos:definition "An entity whose rows are name-value pairs holding what should be attributes. Each property loses its type, domain, optionality and relationships, and nothing stops two rows giving the same property two values. A specific form of row 30."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "entity of name-value pairs (EAV)"@en ; edu:expectedResult "The name-value entity and the properties that should be typed attributes"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Account Property (Account, Property Name, Property Value), with account status, interest rate type and overdraft limit all as Text Acceptable: Explicit attributes on Account or its subtypes (rows 16, 19). If the properties are open-ended by business decision (a product catalogue where the business adds product features weekly), record that with a waiver, and keep a Property Definition entity holding each property's type, unit and value set"@en ; edu:assessmentMethod "skill-tests task: Loan application logical model (normalisation anomaly skills)"@en ; dcterms:source "Review checklist 03-logical, row 7; Karwin, Entity-Attribute-Value; Fagin 1981"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-508" ; rdfs:label "Recognises a partial dependency on a composite key"@en ; skos:prefLabel "Recognises a partial dependency on a composite key"@en ; skos:altLabel "Partial dependency (2NF) (logical model)"@en ; skos:definition "In an entity with a composite key, a non-key attribute depends on only part of the key."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "partial dependency on a composite key"@en ; edu:expectedResult "The non-key attribute and the part of the key it depends on"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Instalment keyed by (Loan Identifier, Instalment Number) carries Loan Maturity Date, which depends on Loan Identifier alone Acceptable: Loan Maturity Date on Loan; Instalment holds only facts about the instalment (`LOG-019`)"@en ; edu:assessmentMethod "skill-tests task: Loan application logical model (normalisation anomaly skills)"@en ; dcterms:source "Review checklist 03-logical, row 8; Codd 1971; Kent 1983; S&W 2.7"@en ; edu:appliesKnowledge ; edu:followedBy ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-509" ; rdfs:label "Recognises a transitive dependency between non-key attributes"@en ; skos:prefLabel "Recognises a transitive dependency between non-key attributes"@en ; skos:altLabel "Transitive dependency (3NF) (logical model)"@en ; skos:definition "A non-key attribute depends on another non-key attribute rather than on the key."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "transitive dependency between non-key attributes"@en ; edu:expectedResult "The non-key determinant and the attributes that depend on it"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Account carries Branch Identifier and Branch Name; the name depends on the identifier, not on the account Acceptable: Branch reference entity; or, if the name must stay as it was when the account was opened, `derivation` saying so (`LOG-018`)"@en ; edu:assessmentMethod "skill-tests task: Loan application logical model (normalisation anomaly skills)"@en ; dcterms:source "Review checklist 03-logical, row 9; Codd 1971; Kent 1983; S&W 2.7"@en ; edu:appliesKnowledge ; edu:followedBy ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-510" ; rdfs:label "Recognises a stored derivable attribute"@en ; skos:prefLabel "Recognises a stored derivable attribute"@en ; skos:altLabel "Stored derivable attribute (logical model)"@en ; skos:definition "An attribute whose value can be computed from other attributes, stored and writable alongside them, so the stored and computed values can disagree."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "stored derivable attribute"@en ; edu:expectedResult "The attribute, the attributes it is computed from, and whether it is a snapshot instead"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Balance with Ledger Balance Amount, Hold Amount and Available Balance Amount all captured; Repayment Schedule with Total Repayment Amount alongside its instalments Acceptable: Available balance derived, with `derivation` and the rule cited (available balance = ledger balance − holds); total repayment stored only as the amount contracted, with `derivation` saying it is not recomputed (see data rules row 6)"@en ; edu:assessmentMethod "skill-tests task: Loan application logical model (normalisation anomaly skills)"@en ; dcterms:source "Review checklist 03-logical, row 10; S&W 2.5.3"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-511" ; rdfs:label "Recognises a non-superkey determinant in a 3NF entity"@en ; skos:prefLabel "Recognises a non-superkey determinant in a 3NF entity"@en ; skos:altLabel "Determinant that is not a key (BCNF) (logical model)"@en ; skos:definition "An attribute or set of attributes determines another but is not a candidate key. Usually hides behind overlapping composite keys, so the entity is in 3NF and still has update anomalies."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "determinant that is not a candidate key"@en ; edu:expectedResult "The determinant, what it determines, and the overlapping candidate keys it hides behind"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Arrears Assignment (Loan, Product Family, Collections Officer), key (Loan, Product Family); each officer works on one product family, so moving an officer means updating every assignment Acceptable: Collections Officer holds its Product Family; Loan Collections Assignment (Loan, Collections Officer); the constraint lost by the split goes to row 15"@en ; edu:assessmentMethod "skill-tests task: Loan application logical model (normalisation anomaly skills)"@en ; dcterms:source "Review checklist 03-logical, row 11; Codd 1974; S&W 13.3"@en ; edu:appliesKnowledge ; edu:followedBy ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-512" ; rdfs:label "Recognises independent multi-valued facts in one entity"@en ; skos:prefLabel "Recognises independent multi-valued facts in one entity"@en ; skos:altLabel "Independent multi-valued facts in one entity (4NF) (logical model)"@en ; skos:definition "One entity records two or more independent lists about the same thing, so each new item in one list needs a row for every item in the other."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "independent multi-valued facts in one entity"@en ; edu:expectedResult "The two independent lists and the entity that combines them"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Branch Capability (Branch, Product, Language), where the products a branch may sell and the languages its staff serve in are unrelated Acceptable: Branch Product Authorisation (Branch, Product) and Branch Service Language (Branch, Language)"@en ; edu:assessmentMethod "skill-tests task: Loan application logical model (normalisation anomaly skills)"@en ; dcterms:source "Review checklist 03-logical, row 12; Fagin 1977; Kent 1983; S&W 13.4"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-513" ; rdfs:label "Recognises a join dependency kept in one entity"@en ; skos:prefLabel "Recognises a join dependency kept in one entity"@en ; skos:altLabel "Join dependency (5NF) (logical model)"@en ; skos:definition "A three-way entity that can be rebuilt from its pairwise projections because of a cyclic business rule, kept as one entity; or the reverse, three pairwise entities joined as if the rule held when it does not."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "join dependency in a three-way entity"@en ; edu:expectedResult "The three-way entity and the cyclic rule that does or does not make it decomposable"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Branch Channel Product as one entity, although the rule is that a branch offers every product it is authorised for through every channel it operates; one new authorisation needs a row per channel Acceptable: Three entities (Branch Channel, Channel Product, Branch Product) when the cyclic rule holds, recorded as a data rule; the three-way entity when it does not"@en ; edu:assessmentMethod "skill-tests task: Loan application logical model (normalisation anomaly skills)"@en ; dcterms:source "Review checklist 03-logical, row 13; Fagin 1979; Kent 1983; S&W 13.4"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-514" ; rdfs:label "Recognises a lossy decomposition"@en ; skos:prefLabel "Recognises a lossy decomposition"@en ; skos:altLabel "Lossy decomposition (spurious rows) (logical model)"@en ; skos:definition "An entity is split so that joining the parts back produces rows that never existed. The split is lossless only if the shared attributes are a key of at least one part."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "lossy decomposition of an entity"@en ; edu:expectedResult "The split, the shared attributes that are not a key, and an example spurious row"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Account Holder split into (Account, Holder Role) and (Party, Holder Role) and joined on Holder Role: two accounts each with one joint holder give four holdings Acceptable: Keep (Account, Party, Holder Role) whole, or split only on attributes that are a key of one side"@en ; edu:assessmentMethod "skill-tests task: Loan application logical model (normalisation anomaly skills)"@en ; dcterms:source "Review checklist 03-logical, row 14; Heath 1971; E&N 14.1.4, ch. 15"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-515" ; rdfs:label "Recognises a functional dependency lost in a decomposition"@en ; skos:prefLabel "Recognises a functional dependency lost in a decomposition"@en ; skos:altLabel "Dependency lost in decomposition (logical model)"@en ; skos:definition "After a split, a dependency spans two entities and no key in either one enforces it. Typical after a BCNF split (row 11)."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "functional dependency lost in a decomposition"@en ; edu:expectedResult "The dependency that now spans two entities and that no key enforces"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: After row 11's split, nothing says a loan has only one collections officer per product family Acceptable: Either stay in 3NF with a waiver naming the accepted anomaly, or record the dependency as a data rule with `enforcement: application` or `dq-check`"@en ; edu:assessmentMethod "skill-tests task: Loan application logical model (normalisation anomaly skills)"@en ; dcterms:source "Review checklist 03-logical, row 15; Rissanen 1977; E&N ch. 15"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-516" ; rdfs:label "Recognises attributes inapplicable to some instances"@en ; skos:prefLabel "Recognises attributes inapplicable to some instances"@en ; skos:altLabel "Inapplicable attributes (missing subtype) (logical model)"@en ; skos:definition "Optional attributes that are optional because they do not apply to some instances, not because the value is unknown. A null then means two things, and the attribute cannot be made mandatory where it should be."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "attributes inapplicable to some instances of an entity"@en ; edu:expectedResult "The attributes, the instances they do not apply to, and the missing subtype"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Account with interest rate, maturity date and arrears day count, all `required: false` because none applies to a current account Acceptable: Loan Account and Current Account as subtypes with a discriminator; Loan Interest Rate required on Loan Account, with a value-set code for \"not yet fixed\" (`LOG-013`)"@en ; edu:assessmentMethod "skill-tests task: Loan application logical model (normalisation anomaly skills)"@en ; dcterms:source "Review checklist 03-logical, row 16; Codd 1979; E&N 14.1.3"@en ; edu:appliesKnowledge ; edu:followedBy ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-517" ; rdfs:label "Recognises an unstable or meaningful primary key"@en ; skos:prefLabel "Recognises an unstable or meaningful primary key"@en ; skos:altLabel "Unstable or meaningful key (logical model)"@en ; skos:definition "The key can change, be reused or be unknown when the row is created, or it carries meaning that can change. Every reference to the row breaks when it does."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "unstable or meaningful primary key"@en ; edu:expectedResult "The key and how it can change, be reused, be unknown or carry meaning"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Account keyed on branch code plus sequence: a branch merger renumbers the branches and with them every key; Party keyed on name Acceptable: Account keyed on its IBAN, assigned once and never reused; Branch Identifier as a plain attribute; where no stable natural key exists, say so and record the matching rule (`LOG-005`, `LOG-020`, `LOG-021`, `LOG-027`)"@en ; edu:assessmentMethod "skill-tests task: Loan application logical model (normalisation anomaly skills)"@en ; dcterms:source "Review checklist 03-logical, row 17; Codd 1970; Codd 1979; S&W ch. 6"@en ; edu:appliesKnowledge ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-518" ; rdfs:label "Recognises an entity identified only by a system-assigned key"@en ; skos:prefLabel "Recognises an entity identified only by a system-assigned key"@en ; skos:altLabel "System-assigned key only (logical model)"@en ; skos:definition "The entity's only identifier is a number the system assigns, and nothing the business uses to tell instances apart is recorded as `natural_key`. Nothing then stops the same thing being recorded twice. A surrogate key is a physical decision in this skill. A specific form of row 17."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "entity with only a system-assigned key"@en ; edu:expectedResult "The entity and the business identifier it lacks as a natural key"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Party with `primary_key: [Party Id]` and no `natural_key`; the same company registered twice under two ids Acceptable: `primary_key` and `natural_key` on the business identifier (registry code, personal identification code); where none exists, say so and record the duplicate-matching rule as a data rule with an enforcement"@en ; edu:assessmentMethod "skill-tests task: Loan application logical model (normalisation anomaly skills)"@en ; dcterms:source "Review checklist 03-logical, row 18; Karwin, ID Required; S&W ch. 6"@en ; edu:appliesKnowledge ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-519" ; rdfs:label "Recognises undeclared subtype constraints"@en ; skos:prefLabel "Recognises undeclared subtype constraints"@en ; skos:altLabel "Undeclared subtype constraints (logical model)"@en ; skos:definition "A supertype with subtypes and nothing saying whether an instance can belong to more than one subtype (disjoint or overlapping) or to none (total or partial)."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "supertype without declared subtype constraints"@en ; edu:expectedResult "The supertype and the undeclared disjointness or completeness"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Party → Person, Organisation, with nothing saying whether a sole trader (FIE) is one, the other, both or neither Acceptable: Stated as disjoint and total; FIE modelled as a Person with a business role; the discriminator's value set lists exactly the subtypes (`LOG-013`)"@en ; edu:assessmentMethod "skill-tests task: Loan application logical model (normalisation anomaly skills)"@en ; dcterms:source "Review checklist 03-logical, row 19; E&N 4.3"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-520" ; rdfs:label "Recognises independently changing histories in one entity"@en ; skos:prefLabel "Recognises independently changing histories in one entity"@en ; skos:altLabel "Independent histories in one entity (6NF) (logical model)"@en ; skos:definition "In an entity that keeps history, attributes that change independently share one row and one validity period, so a change to any one repeats all the others and \"when did X change?\" needs consecutive rows compared."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "independent histories sharing one validity period"@en ; edu:expectedResult "The attributes that change independently and share one validity period"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Account Version (Account, valid from, account status, interest rate, servicing branch) Acceptable: One history per group of attributes that change together: Account Status History, Account Interest Rate History, each with its own validity"@en ; edu:assessmentMethod "skill-tests task: Loan application logical model (normalisation anomaly skills)"@en ; dcterms:source "Review checklist 03-logical, row 20; DDL 2014"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-521" ; rdfs:label "Recognises an unresolved many-to-many relationship"@en ; skos:prefLabel "Recognises an unresolved many-to-many relationship"@en ; skos:altLabel "Unresolved many-to-many (logical model)"@en ; skos:definition "An N:M relationship left in the model. Its facts (dates, shares, roles) have nowhere to live, and they are usually requirements not yet captured."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "unresolved many-to-many relationship"@en ; edu:expectedResult "The relationship and the facts that have nowhere to live"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Account N:M Party \"is held by\", with holder role and start date in nobody's attributes Acceptable: Account Holder associative entity with holder role and start date (`LOG-010`)"@en ; edu:assessmentMethod "skill-tests task: Loan application logical model (normalisation anomaly skills)"@en ; dcterms:source "Review checklist 03-logical, row 21; C&B; this skill"@en ; edu:appliesKnowledge ; edu:followedBy ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-522" ; rdfs:label "Recognises a polymorphic association"@en ; skos:prefLabel "Recognises a polymorphic association"@en ; skos:altLabel "Polymorphic association (logical model)"@en ; skos:definition "One reference attribute pointing to different entities depending on the value of a type attribute. There is no single parent, so the relationship has no cardinality, no optionality and no rule, and the physical model cannot declare a foreign key. A specific form of row 6."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "polymorphic association"@en ; edu:expectedResult "The reference attribute, its type attribute and the entities it points to"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Case Note with Owner Id and Owner Type (`ACCOUNT`, `PAYMENT`, `PARTY`) Acceptable: One relationship per parent (Case Note → Account, Case Note → Payment), each with its rule, plus a rule that exactly one is set; or a supertype the parents share, only if they pass row 27's test (`LOG-012` when Owner Id has the `foreign-key` role; review only otherwise)"@en ; edu:assessmentMethod "skill-tests task: Loan application logical model (normalisation anomaly skills)"@en ; dcterms:source "Review checklist 03-logical, row 22; Karwin, Polymorphic Associations; E&N ch. 4 (union types)"@en ; edu:appliesKnowledge ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-523" ; rdfs:label "Recognises a connection trap"@en ; skos:prefLabel "Recognises a connection trap"@en ; skos:altLabel "Connection trap (logical model)"@en ; skos:definition "A fact inferred from a path of two relationships that never recorded it."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "connection trap on a path of two relationships"@en ; edu:expectedResult "The path and the fact it is wrongly read to state"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Branch authorised for Product, Account is of a Product; \"which branch opened this account\" answered by joining through the product Acceptable: Account Opening (Account, Branch) records the fact; the inference is valid only under the cyclic rule in row 13"@en ; edu:assessmentMethod "skill-tests task: Loan application logical model (normalisation anomaly skills)"@en ; dcterms:source "Review checklist 03-logical, row 23; Codd 1970 §2.1.4"@en ; edu:appliesKnowledge ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-524" ; rdfs:label "Recognises a fan trap"@en ; skos:prefLabel "Recognises a fan trap"@en ; skos:altLabel "Fan trap (logical model)"@en ; skos:definition "Two one-to-many relationships fan out from the same entity, and a question about how their many sides relate cannot be answered."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "fan trap"@en ; edu:expectedResult "The entity with two one-to-many relationships and the question they cannot answer"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Branch 1:N Account Manager and Branch 1:N Account: which account manager services which account? Acceptable: Branch 1:N Account Manager 1:N Account, so the path carries the fact"@en ; edu:assessmentMethod "skill-tests task: Loan application logical model (normalisation anomaly skills)"@en ; dcterms:source "Review checklist 03-logical, row 24; Howe; C&B"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-525" ; rdfs:label "Recognises a chasm trap"@en ; skos:prefLabel "Recognises a chasm trap"@en ; skos:altLabel "Chasm trap (logical model)"@en ; skos:definition "A path exists, but an optional relationship on it breaks it for some instances, so they silently drop out of every query that follows the path."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "chasm trap"@en ; edu:expectedResult "The path, the optional relationship on it, and the instances that drop out"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Branch 1:N Account Manager 1:N Account with Account → Account Manager optional: accounts opened online have no path to a branch and vanish from branch totals (row 24's fix can create this) Acceptable: A direct Account → Branch relationship, or a direct-channel branch, so every account reaches exactly one"@en ; edu:assessmentMethod "skill-tests task: Loan application logical model (normalisation anomaly skills)"@en ; dcterms:source "Review checklist 03-logical, row 25; Howe; C&B"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-526" ; rdfs:label "Recognises a redundant relationship"@en ; skos:prefLabel "Recognises a redundant relationship"@en ; skos:altLabel "Redundant relationship (logical model)"@en ; skos:definition "Two paths between the same entities state the same fact, so they can disagree."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "redundant relationship"@en ; edu:expectedResult "The two paths that state the same fact"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Payment → Account → Party (account holder), plus a direct Payment → Party meaning the same person Acceptable: Remove the direct relationship; keep it only if it means something else (the counterparty who instructed the payment, who need not be the account holder), named so and with its own rule"@en ; edu:assessmentMethod "skill-tests task: Loan application logical model (normalisation anomaly skills)"@en ; dcterms:source "Review checklist 03-logical, row 26; C&B"@en ; edu:appliesKnowledge ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-527" ; rdfs:label "Recognises overlapping entities"@en ; skos:prefLabel "Recognises overlapping entities"@en ; skos:altLabel "Overlapping entities (logical model)"@en ; skos:definition "Two entities whose meanings overlap, so the same thing can be recorded in both, and a change reaches only one."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "overlapping entities"@en ; edu:expectedResult "The two entities and the things that can be recorded in both"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Retail Customer and Account Holder Party as separate kernel entities with the same attributes Acceptable: One Party entity; customer and account holder as roles. Test: could one instance belong to both entities with the same key and meaning?"@en ; edu:assessmentMethod "skill-tests task: Loan application logical model (normalisation anomaly skills)"@en ; dcterms:source "Review checklist 03-logical, row 27; Date & McGoveran 1994"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-528" ; rdfs:label "Recognises one entity split by value into several"@en ; skos:prefLabel "Recognises one entity split by value into several"@en ; skos:altLabel "One entity split by value (logical model)"@en ; skos:definition "Entities with the same structure and meaning, differing only by a value that should be data: a year, a region, a product line. Every new value needs a model change, and every question across values needs a union. A specific form of row 27; the attribute form (Balance Q1 … Balance Q4) is row 4."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "entities split by a value that should be data"@en ; edu:expectedResult "The entities and the value that should be an attribute"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Payment 2025, Payment 2026; Account Tallinn, Account Tartu Acceptable: One Payment entity, the year derived from Payment Value Date; if volume needs a split, it is physical partitioning"@en ; edu:assessmentMethod "skill-tests task: Loan application logical model (normalisation anomaly skills)"@en ; dcterms:source "Review checklist 03-logical, row 28; Karwin, Metadata Tribbles; Date & McGoveran 1994"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-529" ; rdfs:label "Recognises a relationship contradicting its data rule"@en ; skos:prefLabel "Recognises a relationship contradicting its data rule"@en ; skos:altLabel "Relationship contradicts its data rule (logical model)"@en ; skos:definition "The relationship's cardinality, optionality or identifying flag says something different from the data rule it cites."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "relationship contradicting its data rule"@en ; edu:expectedResult "The relationship, the rule it cites and the cardinality or optionality that differs"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `BR-007: each payment is posted to exactly one account`, but `LR-004` has `parent_optional: true` Acceptable: Read each relationship aloud as a sentence and compare it with the rule word for word (`LOG-011`, `LOG-029` find a missing link; a mismatch needs a person)"@en ; edu:assessmentMethod "skill-tests task: Loan application logical model (normalisation anomaly skills)"@en ; dcterms:source "Review checklist 03-logical, row 29; this skill (05-logical.md §4c)"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-530" ; rdfs:label "Recognises a constraint implied by neither keys nor domains"@en ; skos:prefLabel "Recognises a constraint implied by neither keys nor domains"@en ; skos:altLabel "Constraint not implied by keys and domains (DKNF) (logical model)"@en ; skos:definition "A constraint that neither a key nor an attribute's domain enforces. Each one is a way in for rows 1–3."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "constraint not implied by keys and domains"@en ; edu:expectedResult "The constraint and why no key or domain enforces it"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Account Closed Indicator typed Text; Account Status Code with no value set; \"a currency code has 3 characters\" only in a description Acceptable: Domain given by `logical_type`, `length` and `value_set`; every remaining constraint is a key or a data rule with an enforcement (`LOG-007`, `LOG-009`, `LOG-014`, `LOG-028`)"@en ; edu:assessmentMethod "skill-tests task: Loan application logical model (normalisation anomaly skills)"@en ; dcterms:source "Review checklist 03-logical, row 30; Fagin 1981"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-601" ; rdfs:label "Recognises an unmanaged duplicate column"@en ; skos:prefLabel "Recognises an unmanaged duplicate column"@en ; skos:altLabel "Unmanaged duplicate column (physical model)"@en ; skos:definition "A column copied from another table to save a join, with nothing keeping the copy equal to the original. The update anomaly the logical model removed, put back."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "column copied to save a join"@en ; edu:expectedResult "The copy, the original and what keeps them equal"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `account.holder_name` copied from `party.name` for the account-servicing screen, no `derivation`, no DQ rule; the holder changes name and old accounts show the old one Acceptable: `derivation` names the source column and the mechanism that refreshes it, and a `consistency` DQ rule compares the two; or a view instead of a column. A copy meant to keep the value as at account opening is not a copy: the logical model says so (logical row 9)"@en ; edu:assessmentMethod "skill-tests task: Loan application physical model on Snowflake (physical design anomaly skills)"@en ; dcterms:source "Review checklist 04-physical, row 1; Codd 1971; Kent 1983; E&N 1.6.1; C&B; S&W 12.6"@en ; edu:dependsOnKnobit ; edu:appliesKnowledge ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-602" ; rdfs:label "Recognises logical entities merged into one table"@en ; skos:prefLabel "Recognises logical entities merged into one table"@en ; skos:altLabel "Tables merged (physical model)"@en ; skos:definition "Two logical entities, usually a parent or reference entity and its child, stored as one table. One kind of fact can no longer be recorded without the other, and deleting the last child deletes the parent."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "parent and child merged"@en ; edu:expectedResult "The merged entities and the facts they now tie together"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `account` absorbs `branch` (`branch_id`, `branch_name`); a newly opened branch cannot be recorded until an account is serviced there, and deleting the last account serviced there deletes the name Acceptable: `ref_branch` stays the system of record; a merged structure exists only as a dimension or view built from it"@en ; edu:assessmentMethod "skill-tests task: Loan application physical model on Snowflake (physical design anomaly skills)"@en ; dcterms:source "Review checklist 04-physical, row 2; Codd 1971; Kent 1983; Fagin 1981; C&B; S&W 12.6"@en ; edu:dependsOnKnobit ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-603" ; rdfs:label "Recognises a stored derived or summary value"@en ; skos:prefLabel "Recognises a stored derived or summary value"@en ; skos:altLabel "Stored derived or summary value (physical model)"@en ; skos:definition "A column or table holding a value computed from other stored data, written separately from its inputs, so the two can disagree. The physical form of logical row 10."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "stored computed column or table"@en ; edu:expectedResult "The value, its inputs and the derivation or check it needs"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `loan.total_repayment_amount` kept by the application alongside `instalment`; an instalment is corrected and the total is not. `account_balance_monthly_total` reloaded nightly, with nothing saying as of when Acceptable: A generated column or a view; otherwise `derivation` naming the rule and the refresh mechanism, and a DQ rule comparing stored and computed values. A summary table carries its as-of timestamp"@en ; edu:assessmentMethod "skill-tests task: Loan application physical model on Snowflake (physical design anomaly skills)"@en ; dcterms:source "Review checklist 04-physical, row 3; C&B (\"design representation of derived data\"); E&N 17.7; S&W 12.6"@en ; edu:dependsOnKnobit ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-604" ; rdfs:label "Recognises a lossy or unconstrained vertical split"@en ; skos:prefLabel "Recognises a lossy or unconstrained vertical split"@en ; skos:altLabel "Lossy or unconstrained vertical split (physical model)"@en ; skos:definition "One entity split into two tables for width or access, where the tables do not share the key, or the one-to-one relationship between them is not enforced. Joining back produces rows that never existed, or one row gets two extensions. A dependency spanning both parts has no key to enforce it."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "table split without shared key or enforced one-to-one"@en ; edu:expectedResult "The split and its missing key or constraint"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `account` and `account_interest_terms`, the second with its own surrogate and joined on the product code: two accounts on one product give four rows. Or `account_interest_terms.account_id` with an FK but no unique constraint Acceptable: Both tables keyed on `account_id`; in the extension the primary key is also the foreign key, so one-to-one is enforced; whether the extension is optional is stated"@en ; edu:assessmentMethod "skill-tests task: Loan application physical model on Snowflake (physical design anomaly skills)"@en ; dcterms:source "Review checklist 04-physical, row 4; Heath 1971; Rissanen 1977; S&W 12.6; E&N 17.7"@en ; edu:dependsOnKnobit ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-605" ; rdfs:label "Recognises an entity split into clone tables by value"@en ; skos:prefLabel "Recognises an entity split into clone tables by value"@en ; skos:altLabel "Horizontal split into clone tables (physical model)"@en ; skos:definition "One entity stored as several tables with the same columns, split by a value: a year, a region, a status. Uniqueness and foreign keys cannot span them, a change to the split value means moving the row, and every question across values needs a union. The physical form of logical row 28."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "clone tables"@en ; edu:expectedResult "The tables and the value to make a column"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `payment_2025`, `payment_2026`; `payment_identifier` unique in each but not across both; `payment_hold` cannot reference \"a payment\"; a corrected value date moves the payment between tables Acceptable: One `payment` table partitioned by `payment_value_date` in `physical_options`, keys and foreign keys unchanged. Where separate tables are unavoidable (an archive), their predicates are disjoint and written down, and uniqueness across them is a DQ rule"@en ; edu:assessmentMethod "skill-tests task: Loan application physical model on Snowflake (physical design anomaly skills)"@en ; dcterms:source "Review checklist 04-physical, row 5; Karwin, Metadata Tribbles; Date & McGoveran 1994; S&W 12.6"@en ; edu:dependsOnKnobit ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-606" ; rdfs:label "Recognises rolled-up subtypes losing conditional constraints"@en ; skos:prefLabel "Recognises rolled-up subtypes losing conditional constraints"@en ; skos:altLabel "Subtypes rolled up, conditional constraints lost (physical model)"@en ; skos:definition "Supertype and subtypes in one table. Columns that are mandatory for one subtype become nullable for all, so the database accepts a row missing a value its subtype requires, and accepts values on rows they do not apply to."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "supertype and subtypes in one table"@en ; edu:expectedResult "The columns whose subtype obligation is lost, and the discriminator or check needed"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `account` holds both loan accounts and current accounts; `loan_maturity_date` nullable for all rows, so a loan account without a maturity date loads, and so does a current account with one Acceptable: `CHECK ((account_type_code = 'LOAN' AND loan_maturity_date IS NOT NULL) OR (account_type_code <> 'LOAN' AND loan_maturity_date IS NULL))` citing the rule; on platforms that do not enforce CHECK, a DQ rule. Each subtype-only column's `comment` says which subtype it applies to"@en ; edu:assessmentMethod "skill-tests task: Loan application physical model on Snowflake (physical design anomaly skills)"@en ; dcterms:source "Review checklist 04-physical, row 6; E&N 9.2; S&W 11.3; Codd 1979 §2.3"@en ; edu:dependsOnKnobit ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-607" ; rdfs:label "Recognises rolled-down subtypes losing supertype constraints"@en ; skos:prefLabel "Recognises rolled-down subtypes losing supertype constraints"@en ; skos:altLabel "Subtypes rolled down, supertype constraints lost (physical model)"@en ; skos:definition "One table per subtype and none for the supertype. Uniqueness across subtypes cannot be declared, nothing stops one instance appearing in two subtype tables, and a relationship to the supertype has no single table to reference, so it becomes a polymorphic association (logical row 22)."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "one table per subtype"@en ; edu:expectedResult "The lost cross-subtype uniqueness and supertype reference"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `person` and `organisation`, no `party`; `account_holder.party_id` cannot have a foreign key; nothing stops one id being used in both tables Acceptable: A `party` table with the shared key; `person` and `organisation` keyed by `party_id` with an FK to it; exclusivity enforced by carrying the discriminator into each subtype's key, or by a DQ rule"@en ; edu:assessmentMethod "skill-tests task: Loan application physical model on Snowflake (physical design anomaly skills)"@en ; dcterms:source "Review checklist 04-physical, row 7; E&N 9.2; S&W 11.3"@en ; edu:dependsOnKnobit ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-608" ; rdfs:label "Recognises a hierarchy encoded redundantly"@en ; skos:prefLabel "Recognises a hierarchy encoded redundantly"@en ; skos:altLabel "Hierarchy encoded redundantly (physical model)"@en ; skos:definition "A recursive relationship stored as a path string or nested-set numbers. The structure is held many times over, moving one node rewrites all its descendants, and no foreign key checks the encoding. A specific form of row 3."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "path string or nested-set encoding"@en ; edu:expectedResult "The encoding and what keeps it consistent"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `branch.path = '/1/4/17/'` with no foreign key on the parts; moving branch 4 under another region rewrites every row below it, and a mistyped path loads Acceptable: `parent_branch_id` with a foreign key as the system of record; a path, nested set or closure table only as a derived structure with `derivation` and a DQ rule. A closure table has foreign keys on both columns"@en ; edu:assessmentMethod "skill-tests task: Loan application physical model on Snowflake (physical design anomaly skills)"@en ; dcterms:source "Review checklist 04-physical, row 8; Karwin, Naive Trees; S&W 12.6; Codd 1971"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-609" ; rdfs:label "Recognises content held outside the database by reference"@en ; skos:prefLabel "Recognises content held outside the database by reference"@en ; skos:altLabel "Data held outside the database by reference (physical model)"@en ; skos:definition "A column holding a file path or URL to content the database does not control. Deleting the row leaves the file, deleting the file leaves the row, a rollback restores one and not the other, and backups of the two are not taken at the same moment. A deletion anomaly across two stores."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "file path or URL column"@en ; edu:expectedResult "The column and the consistency the database cannot guarantee"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `loan_document.file_path = '\\\\fs01\\loans\\2026\\...\\agreement.pdf'`; the share is reorganised and the paths point nowhere Acceptable: An object-store key whose lifecycle is tied to the row through one service, a DQ rule that every key resolves, and a statement of which store is the system of record; or a BLOB column where the volume allows it"@en ; edu:assessmentMethod "skill-tests task: Loan application physical model on Snowflake (physical design anomaly skills)"@en ; dcterms:source "Review checklist 04-physical, row 9; Karwin, Phantom Files"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-610" ; rdfs:label "Recognises a surrogate key without natural-key uniqueness"@en ; skos:prefLabel "Recognises a surrogate key without natural-key uniqueness"@en ; skos:altLabel "Surrogate key without natural-key uniqueness (physical model)"@en ; skos:definition "A system-generated primary key added and the natural key not made a unique constraint. Nothing then stops the same thing being recorded twice. The physical form of logical row 18."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "surrogate primary key"@en ; edu:expectedResult "The natural key to make unique"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `party` with `party_id` as identity primary key and `registry_code` with no unique constraint; a reload registers every company again Acceptable: `uk_party_registry_code` (with the identifier type, where the logical model has one); `PHY-020` adds the surrogate, the unique constraint is added by hand (`ANO-012` when a uniqueness rule claims schema enforcement, `PHY-016` for type-2 dimensions)"@en ; edu:assessmentMethod "skill-tests task: Loan application physical model on Snowflake (physical design anomaly skills)"@en ; dcterms:source "Review checklist 04-physical, row 10; Karwin, ID Required; S&W 6.3; Codd 1979 §4"@en ; edu:dependsOnKnobit ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-611" ; rdfs:label "Recognises a surrogate value with meaning, reused or renumbered"@en ; skos:prefLabel "Recognises a surrogate value with meaning, reused or renumbered"@en ; skos:altLabel "Surrogate value with meaning, reused or renumbered (physical model)"@en ; skos:definition "A surrogate key whose value is shown to people, built from business data, reused after a delete, or renumbered to close gaps. Every reference held outside the table, in a file, a report or a letter, then points at the wrong row. Codd's surrogates are never shown to users and never controlled by them. A specific form of logical row 17."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "exposed or recycled surrogate value"@en ; edu:expectedResult "The surrogate and where its value escapes"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `account_id` printed on customer letters and renumbered after a purge; `loan_key` built as date plus sequence Acceptable: Identity or sequence values never reused, never displayed and with gaps accepted; the number customers see is a separate natural-key column with its own unique constraint"@en ; edu:assessmentMethod "skill-tests task: Loan application physical model on Snowflake (physical design anomaly skills)"@en ; dcterms:source "Review checklist 04-physical, row 11; Codd 1979 §4; Karwin, Pseudokey Neat-Freak; S&W 6.3"@en ; edu:dependsOnKnobit ; edu:appliesKnowledge ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-612" ; rdfs:label "Recognises an undeclared foreign key"@en ; skos:prefLabel "Recognises an undeclared foreign key"@en ; skos:altLabel "Undeclared foreign key (physical model)"@en ; skos:definition "A logical relationship implemented as a column with no foreign key, usually \"for load speed\" or \"the ETL checks it\". Rows referencing nothing load, and so do deletions that leave them. A specific form of row 14."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "relationship column without foreign key"@en ; edu:expectedResult "The column and the foreign key to declare"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `payment.account_id` with no foreign key; an account is purged and its payments point nowhere Acceptable: A `foreign_keys` entry for every logical relationship, citing it in `logical_relationship`; where the platform does not enforce it, see row 15 (`PHY-007` checks the declared ones; a missing one is review only: compare each `LR-` with the foreign keys citing it)"@en ; edu:assessmentMethod "skill-tests task: Loan application physical model on Snowflake (physical design anomaly skills)"@en ; dcterms:source "Review checklist 04-physical, row 12; Karwin, Keyless Entry; Codd 1979 §2.1; E&N 5.2, 6.2; S&W 11.6"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-613" ; rdfs:label "Recognises a referential action destroying what should survive"@en ; skos:prefLabel "Recognises a referential action destroying what should survive"@en ; skos:altLabel "Referential action deletes or erases what should survive (physical model)"@en ; skos:definition "`ON DELETE CASCADE` or `SET NULL` on a relationship whose child has a life of its own. A deletion anomaly made automatic: deleting one fact silently deletes or erases another."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "ON DELETE CASCADE or SET NULL"@en ; edu:expectedResult "The action and the child to keep"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `fk_payment_account` with `on_delete: cascade`: purging a closed account deletes its payments and holds. `fk_payment_authorised_by` with `set null`: deleting a user erases who authorised the payment Acceptable: `on_delete: restrict` by default; `cascade` only for children that cannot exist without the parent (an instalment with its repayment schedule), with the data rule cited"@en ; edu:assessmentMethod "skill-tests task: Loan application physical model on Snowflake (physical design anomaly skills)"@en ; dcterms:source "Review checklist 04-physical, row 13; Codd 1979 §2.1; E&N 6.2; Codd 1971"@en ; edu:dependsOnKnobit ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-614" ; rdfs:label "Logical constraint lost on the way down (physical model)"@en ; skos:prefLabel "Logical constraint lost on the way down (physical model)"@en ; skos:definition "A data rule with `enforcement: constraint`, or a logical `required`, key or value set, that no physical object enforces: a required attribute on a nullable column, a unique rule with no unique constraint, a value set with no foreign key or CHECK. Each one is a way in for invalid rows."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "physical model"@en ; edu:expectedResult "A finding that names the defective physical model element and the defect"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `BR-007: each account has exactly one IBAN`, `enforcement: constraint`, but `account.account_identifier` is nullable and not unique Acceptable: `NOT NULL` and a unique constraint, each citing `BR-007`; a rule no constraint can enforce changed to `enforcement: dq-check` with a DQ rule (`ANO-010`, `ANO-012`, `ANO-007`, `DQR-007`, `PHY-009`)"@en ; edu:assessmentMethod "skill-tests task: Loan application physical model on Snowflake (physical design anomaly skills)"@en ; dcterms:source "Review checklist 04-physical, row 14; Fagin 1981; E&N 6.2; S&W 14.5; this skill"@en ; schema:supersededBy ; schema:creativeWorkStatus "superseded" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-615" ; rdfs:label "Constraint the platform does not enforce (physical model)"@en ; skos:prefLabel "Constraint the platform does not enforce (physical model)"@en ; skos:definition "A primary key, unique or foreign key declared on Snowflake or Databricks, which accept the syntax and check nothing, with no DQ rule doing the checking. The constraint documents the intent and enforces nothing."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "physical model"@en ; edu:expectedResult "A finding that names the defective physical model element and the defect"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `uk_dim_account_nk` on Snowflake and no `uniqueness` DQ rule; a rerun load duplicates every version Acceptable: Constraint kept (emitted `NOT ENFORCED`, still read by optimisers and BI tools), plus a `uniqueness` or `integrity` DQ rule per constraint citing it in `backs`, and an inferred-member row for each dimension so facts never need an orphan key (`DQR-017`, `DQR-018`)"@en ; edu:assessmentMethod "skill-tests task: Loan application physical model on Snowflake (physical design anomaly skills)"@en ; dcterms:source "Review checklist 04-physical, row 15; this skill (08-ddl.md); Fagin 1981"@en ; schema:supersededBy ; schema:creativeWorkStatus "superseded" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-616" ; rdfs:label "Recognises a changeable value list fixed in the DDL"@en ; skos:prefLabel "Recognises a changeable value list fixed in the DDL"@en ; skos:altLabel "Value list fixed in the DDL (physical model)"@en ; skos:definition "A value set implemented as `CHECK (... IN (...))` or an enum type although the business changes it. Adding a value needs a migration, a retired value cannot be forbidden for new rows while kept for old ones, and the labels live nowhere. A specific form of row 17: the domain is held in the schema rather than as data."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "CHECK or enum value list"@en ; edu:expectedResult "The list and the reference table to hold it"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `CHECK (account_status_code IN ('OPN','DOR','CLS'))`; the bank adds `BLK` for blocked accounts and rows are rejected until a release Acceptable: `ref_account_status` with code, label and validity dates, and a foreign key to it; `CHECK` lists only for value sets fixed by definition (an alethic rule, such as Y/N)"@en ; edu:assessmentMethod "skill-tests task: Loan application physical model on Snowflake (physical design anomaly skills)"@en ; dcterms:source "Review checklist 04-physical, row 16; Karwin, 31 Flavors; Fagin 1981"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-617" ; rdfs:label "Recognises a physical domain differing from the logical domain"@en ; skos:prefLabel "Recognises a physical domain differing from the logical domain"@en ; skos:altLabel "Physical domain differs from the logical domain (physical model)"@en ; skos:definition "A datatype, length, scale, character set or nullability that admits values the logical domain forbids, or cuts off values it allows. Includes a foreign key typed differently from the key it references."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "column type, length, scale or nullability"@en ; edu:expectedResult "The column and the values it wrongly admits or cuts off"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `account_currency_code VARCHAR(50)`: `'EUR'`, `'eur'` and `'EUR '` all load. `account_identifier VARCHAR(10)` for a logical length of 20. `payment.account_id INTEGER` referencing `BIGINT`. A date as `VARCHAR`. A name column in a character set that cannot hold õ, ä, ö, ü, š, ž Acceptable: `CHAR(3)` with an uppercase-letters check; lengths at least the logical ones; foreign-key types identical to the referenced key; `DATE`; a Unicode character set (`PHY-008`, `PHY-023`)"@en ; edu:assessmentMethod "skill-tests task: Loan application physical model on Snowflake (physical design anomaly skills)"@en ; dcterms:source "Review checklist 04-physical, row 17; Codd 1970; S&W 11.4; E&N 17.7"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-618" ; rdfs:label "Recognises binary floating point used for an exact quantity"@en ; skos:prefLabel "Recognises binary floating point used for an exact quantity"@en ; skos:altLabel "Approximate number for an exact quantity (physical model)"@en ; skos:altLabel "Money in binary floating point (generated DDL)"@en ; skos:definition "`FLOAT`, `REAL` or `DOUBLE` for money, areas, shares or anything compared for equality or totalled. Totals do not tie and equality tests fail. A specific form of row 17."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "FLOAT, REAL or DOUBLE for money or totals"@en ; edu:expectedResult "The column and the exact decimal type it needs"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `payment_amount FLOAT`: the sum over payments differs from the statement total by cents. `loan_interest_rate REAL`: a repayment schedule rebuilt from it does not reproduce the instalments Acceptable: `NUMERIC(12,2)` for euro amounts, `NUMERIC(9,6)` for interest rates, scale as the business states it; floating point only for quantities that are approximate by nature (a model's risk score)"@en ; edu:assessmentMethod "skill-tests task: Loan application physical model on Snowflake (physical design anomaly skills)"@en ; dcterms:source "Review checklist 04-physical, row 18; Karwin, Rounding Errors; S&W 11.4"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-619" ; rdfs:label "Sentinel value in place of null, or null with a business meaning (physical model)"@en ; skos:prefLabel "Sentinel value in place of null, or null with a business meaning (physical model)"@en ; skos:definition "A real-looking value standing for \"unknown\" or \"not applicable\", or a null that means something specific and different in different tables. Sentinels pass every constraint and end up in totals and averages. A specific form of logical row 6 at the physical level."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "physical model"@en ; edu:expectedResult "A finding that names the defective physical model element and the defect"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `account_opening_date = '1900-01-01'` when unknown; `branch_id = -1`; open-ended validity as `NULL` in one table and `9999-12-31` in another Acceptable: `NULL` for unknown. Where a value is required, one project-wide convention recorded in config (open-ended `valid_to`), and a dimension's unknown member as a labelled row that every query sees, not a magic number in a measure"@en ; edu:assessmentMethod "skill-tests task: Loan application physical model on Snowflake (physical design anomaly skills)"@en ; dcterms:source "Review checklist 04-physical, row 19; Karwin, Fear of the Unknown; Codd 1979 §2.3"@en ; schema:supersededBy ; schema:supersededBy ; schema:creativeWorkStatus "superseded" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-620" ; rdfs:label "Recognises a business fact held in physical row order"@en ; skos:prefLabel "Recognises a business fact held in physical row order"@en ; skos:altLabel "Meaning held in physical order (physical model)"@en ; skos:definition "A business fact read from row order, insertion order or the order of generated key values rather than from a column. It changes with parallel loads, sequence caching, reorganisation or migration."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "fact read from row or key order"@en ; edu:expectedResult "The fact and the column to hold it"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: \"The current address is the one with the highest `address_id`\"; \"payments in order of booking\" read from identity order Acceptable: `booked_at`, `valid_from` or a version number as columns, and the current row identified by its data"@en ; edu:assessmentMethod "skill-tests task: Loan application physical model on Snowflake (physical design anomaly skills)"@en ; dcterms:source "Review checklist 04-physical, row 20; Codd 1970 §1.2"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-621" ; rdfs:label "Recognises an index set not derived from access paths"@en ; skos:prefLabel "Recognises an index set not derived from access paths"@en ; skos:altLabel "Index set not derived from access paths (physical model)"@en ; skos:definition "Indexes missing where foreign keys, natural keys and stated access paths need them; indexes duplicated or overlapping; a non-unique index where the rule says unique. The last is a specific form of row 14; the rest are performance defects."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "index set of a table"@en ; edu:expectedResult "Missing, duplicate or wrongly non-unique indexes against the access paths"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `payment.account_id` unindexed, so deleting an account scans and locks `payment`; an index on every column; `ix_party_registry_code` non-unique Acceptable: An index for each foreign key (`PHY-022`), each natural-key unique constraint, and each access path in the requirements, each index's `comment` citing which; speculative ones marked provisional"@en ; edu:assessmentMethod "skill-tests task: Loan application physical model on Snowflake (physical design anomaly skills)"@en ; dcterms:source "Review checklist 04-physical, row 21; Karwin, Index Shotgun; C&B (\"design file organisations and indexes\"); S&W 12.4; E&N 17.7"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-622" ; rdfs:label "Recognises an overwrite where history is required"@en ; skos:prefLabel "Recognises an overwrite where history is required"@en ; skos:altLabel "Overwrite where history is required (physical model)"@en ; skos:definition "A table updated in place although a data rule or requirement needs past states. Audit columns (`updated_at`, `updated_by`) record only the last change and are not history."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "table updated in place"@en ; edu:expectedResult "The table and the history strategy it needs"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `account` updated in place, `updated_at` taken as its history; last year's interest-rate report cannot be reproduced Acceptable: A history strategy chosen per table from the `temporal` rules (06-physical.md: effective dating, SCD type 2, history table, bi-temporal) and recorded in the table's `comment`"@en ; edu:assessmentMethod "skill-tests task: Loan application physical model on Snowflake (physical design anomaly skills)"@en ; dcterms:source "Review checklist 04-physical, row 22; S&W 15.2–15.3; DDL 2014 ch. 17"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-623" ; rdfs:label "Recognises inconsistent validity periods in a versioned table"@en ; skos:prefLabel "Recognises inconsistent validity periods in a versioned table"@en ; skos:altLabel "Overlapping, gapped or inconsistently bounded validity periods (physical model)"@en ; skos:definition "In a table with validity periods, two versions of one key valid at the same time (contradiction), consecutive identical versions (circumlocution), gaps nobody meant, or closed intervals in one table and half-open in another. A point-in-time join then returns two rows or none."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "validity periods"@en ; edu:expectedResult "Overlaps, unintended gaps or mixed bounds, and the convention to apply"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `dim_account` versions 2026-01-01..2026-06-30 and 2026-06-01..9999-12-31: a payment on 2026-06-15 joins both and is counted twice; two rows with `is_current = true` Acceptable: Half-open intervals `[valid_from, valid_to)` project-wide; a unique constraint on natural key plus `valid_from`; DQ rules for no overlap and exactly one current row per key (`PHY-015`, `PHY-016`)"@en ; edu:assessmentMethod "skill-tests task: Loan application physical model on Snowflake (physical design anomaly skills)"@en ; dcterms:source "Review checklist 04-physical, row 23; DDL 2014 ch. 13; S&W 15.4"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-624" ; rdfs:label "Recognises a reference to a versioned table by business key alone"@en ; skos:prefLabel "Recognises a reference to a versioned table by business key alone"@en ; skos:altLabel "Reference to a versioned table by business key alone (physical model)"@en ; skos:definition "A foreign key or join to a table with versions that names the business key and not the version, or a code resolved through today's reference data. Each row multiplies by the number of versions, or past rows change meaning when the reference data does."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "join or foreign key to a versioned table"@en ; edu:expectedResult "The reference and the version key it needs"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `fact_payment.account_identifier` joined to `dim_account` on `account_identifier`: one payment becomes three; `customer_segment_code` resolved through today's `ref_customer_segment`, so a 2025 report changes after the segment boundaries are widened Acceptable: The fact references the version key valid at the event date (`account_key`); reference tables carry validity, and the fact stores the code valid at the time"@en ; edu:assessmentMethod "skill-tests task: Loan application physical model on Snowflake (physical design anomaly skills)"@en ; dcterms:source "Review checklist 04-physical, row 24; S&W 15.7, 16.6; DDL 2014 ch. 13"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-625" ; rdfs:label "Recognises a soft delete the constraints do not understand"@en ; skos:prefLabel "Recognises a soft delete the constraints do not understand"@en ; skos:altLabel "Soft delete the constraints do not understand (physical model)"@en ; skos:definition "Rows marked deleted but still present, with keys and foreign keys unaware of the mark. The deleted row blocks a valid insert, or uniqueness is dropped and active duplicates load, and active rows reference deleted ones."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "deleted flag ignored by keys"@en ; edu:expectedResult "The keys and foreign keys unaware of the flag"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `party.is_deleted`; the unique constraint on `registry_code` includes deleted rows, so the company cannot be registered again; payments keep pointing at a deleted party Acceptable: Uniqueness over active rows only (a filtered unique index where the dialect has one, otherwise a DQ rule); a rule on what may reference a deleted row; views that expose active rows; or deleted rows moved to a history table"@en ; edu:assessmentMethod "skill-tests task: Loan application physical model on Snowflake (physical design anomaly skills)"@en ; dcterms:source "Review checklist 04-physical, row 25; S&W 15.5; this skill (`conventions.soft_delete`)"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-626" ; rdfs:label "Recognises a fact table of mixed grain"@en ; skos:prefLabel "Recognises a fact table of mixed grain"@en ; skos:altLabel "Mixed grain (physical model)"@en ; skos:definition "A fact or wide table whose rows mean different things, or whose columns are true at different grains. Measures at the coarser grain repeat on every finer row and are counted again when summed."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "fact or wide table"@en ; edu:expectedResult "The grains mixed and the measures double counted"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `fact_account_balance` with one row per payment carrying `ledger_balance_amount`, which is per account per day: an account with three payments in a day reports three times its balance Acceptable: A grain sentence, and every column true at that grain; `fact_payment` at payment grain and daily balances on `fact_account_balance_daily` (`PHY-013`, `PHY-028`)"@en ; edu:assessmentMethod "skill-tests task: Loan application physical model on Snowflake (physical design anomaly skills)"@en ; dcterms:source "Review checklist 04-physical, row 26; C&B (\"Data Warehousing Design\": choosing the grain); E&N 29.3; S&W 16.6"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-627" ; rdfs:label "Recognises a measure without stated additivity"@en ; skos:prefLabel "Recognises a measure without stated additivity"@en ; skos:altLabel "Measure without stated additivity (physical model)"@en ; skos:definition "A semi-additive measure (a balance, an open count) or a non-additive one (a ratio) stored without saying how it may be aggregated. A BI tool sums it, and the result is wrong and looks right."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "semi-additive or non-additive measure"@en ; edu:expectedResult "The measure and how it may be aggregated"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `arrears_ratio` summed across products; month-end `account_ledger_balance_amount` summed across months Acceptable: `comment` stating additive, semi-additive (not across time) or non-additive; numerator and denominator stored instead of the ratio (`PHY-014`)"@en ; edu:assessmentMethod "skill-tests task: Loan application physical model on Snowflake (physical design anomaly skills)"@en ; dcterms:source "Review checklist 04-physical, row 27; C&B (\"Data Warehousing Design\": choosing the facts); S&W 16.6"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-628" ; rdfs:label "Recognises a nullable foreign key on a reporting join path"@en ; skos:prefLabel "Recognises a nullable foreign key on a reporting join path"@en ; skos:altLabel "Nullable foreign key on a join path (physical model)"@en ; skos:definition "A nullable foreign key that reports reach through with an inner join. Rows with a null drop out of every such report without an error: the physical form of the chasm trap (logical row 25)."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "nullable foreign key joined inner"@en ; edu:expectedResult "The rows dropping out and the join to use"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `fact_account_opening.branch_key` null for accounts opened online; every report by branch loses them. `loan.collections_officer_id` null until an arrears case is assigned; loans newly in arrears are missing from the workload report Acceptable: In a dimensional model, an \"Unknown\" or \"Not applicable\" member and the foreign key `NOT NULL`; in a normalised model, the nullability kept, the reporting views using outer joins, and the logical model checked against logical row 25"@en ; edu:assessmentMethod "skill-tests task: Loan application physical model on Snowflake (physical design anomaly skills)"@en ; dcterms:source "Review checklist 04-physical, row 28; Howe; C&B (\"Problems with ER Models\"); Codd 1979 §2.3"@en ; edu:dependsOnKnobit ; edu:appliesKnowledge ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-705" ; rdfs:label "Recognises history kept without its constraints checked"@en ; skos:prefLabel "Recognises history kept without its constraints checked"@en ; skos:altLabel "History kept, its constraints not checked (data quality rule)"@en ; skos:definition "A table with validity periods or a current-row flag, on a platform where no key can express \"no two versions of one key overlap\" or \"exactly one current row per key\", and no DQ rule checks either. Point-in-time joins then return two rows or none."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "versioned table on a non-enforcing platform"@en ; edu:expectedResult "The missing overlap and one-current checks"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `dim_account` with `valid_from`/`valid_to`, unique on `(account_identifier, valid_from)` only; two overlapping versions load, and a payment on the overlap is counted twice Acceptable: Two set checks: no overlapping periods per `account_identifier`, exactly one `is_current = TRUE` per `account_identifier`; `dimension: consistency`, threshold 100 %"@en ; edu:assessmentMethod "skill-tests task: Loan application data quality rules on Snowflake (DQ rule anomaly skills)"@en ; dcterms:source "Shared-URI copy of data-quality Q-305 (Review checklist 03-dq-rules (data-quality), row 5; DDL 2014 ch. 13; this skill (06-physical.md))"@en ; edu:dependsOnKnobit ; edu:appliesKnowledge ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-801" ; rdfs:label "Recognises generated SQL edited by hand"@en ; skos:prefLabel "Recognises generated SQL edited by hand"@en ; skos:altLabel "Generated SQL edited by hand (generated DDL)"@en ; skos:definition "A file in `08-ddl/` that regeneration does not reproduce byte for byte. The header says `DO NOT HAND-EDIT`; look for the edit anyway — an added constraint, a reordered statement, a tweaked type, a comment. From here the model and the database tell different stories and nothing mechanical can say which is right."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "generated DDL file"@en ; edu:expectedResult "The hand edit and the model change replacing it"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `ck_fact_payment_settled_le_instructed` added straight into `01_create_tables.sql` after a deploy failure; the next regeneration drops it, nobody notices for two releases, and over-settled payments load again Acceptable: The check added to `fact_payment.check_constraints` in `physical-model.yaml` and the DDL regenerated; `diff -r 08-ddl /tmp/ddl-check` empty, and that diff run in CI"@en ; edu:assessmentMethod "skill-tests task: Generated DDL review, Postgres and Snowflake (DDL review skills)"@en ; dcterms:source "Review checklist 05-ddl, row 1; BCBS 239; Humble & Farley 2010"@en ; edu:appliesKnowledge ; edu:followedBy ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-802" ; rdfs:label "Recognises DDL older than its model"@en ; skos:prefLabel "Recognises DDL older than its model"@en ; skos:altLabel "DDL older than the model (generated DDL)"@en ; skos:definition "Generated SQL that predates the last change to `physical-model.yaml`. The model is the truth, so the SQL is a faithful rendering of an earlier truth, and a reviewer who reads only the SQL is reviewing last month's design."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "generated DDL"@en ; edu:expectedResult "The stale file and the regeneration needed"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `loan_arrears_day_count` added to `dim_account` two commits ago; `08-ddl/postgres/01_create_tables.sql` has no such column and the stage-8 review passes Acceptable: Regeneration for every configured dialect in the same commit as the model change, so the SQL is never a separate decision"@en ; edu:assessmentMethod "skill-tests task: Generated DDL review, Postgres and Snowflake (DDL review skills)"@en ; dcterms:source "Review checklist 05-ddl, row 2; this skill (08-ddl.md)"@en ; edu:appliesKnowledge ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-803" ; rdfs:label "Recognises an object in the SQL missing from the model"@en ; skos:prefLabel "Recognises an object in the SQL missing from the model"@en ; skos:altLabel "Object in the SQL that is not in the model (generated DDL)"@en ; skos:definition "A table, view, index, sequence or trigger in `08-ddl/` with no counterpart in the model. It was added for one urgent reason and is now invisible to every later review, every other dialect and every new environment."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "table, view, index, sequence or trigger"@en ; edu:expectedResult "The object and its place in the model"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `ix_fact_payment_value_date_key` created by hand on Postgres to rescue a month-end report; it is in no other target's output and in no model, and the next environment is built without it Acceptable: The index in the model's `indexes`, so it appears in every target's output — commented out where the engine has none (row 13) — and in the ERD"@en ; edu:assessmentMethod "skill-tests task: Generated DDL review, Postgres and Snowflake (DDL review skills)"@en ; dcterms:source "Review checklist 05-ddl, row 3; BCBS 239; this skill"@en ; edu:appliesKnowledge ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-804" ; rdfs:label "Recognises generator warnings carried without a decision"@en ; skos:prefLabel "Recognises generator warnings carried without a decision"@en ; skos:altLabel "Header warnings carried, not closed (generated DDL)"@en ; skos:definition "A non-empty `-- Warnings raised while generating this file` block with nothing about it in the review record. Each line is a decision the model left to the generator. Also look for a header stripped on the way into version control."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "header warnings block"@en ; edu:expectedResult "Each warning and its closure"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: The header carries `index 'ix_dim_party_notes' covers dim_party.relationship_manager_notes, a BLOB/TEXT column; MySQL needs an explicit prefix length ... it will not run without editing the model`, and the file is signed off as reviewed Acceptable: Every warning closed — the model changed, or the warning quoted in the handover with who accepted it and why. A warning is not a style note; it is the only record that something was decided for you"@en ; edu:assessmentMethod "skill-tests task: Generated DDL review, Postgres and Snowflake (DDL review skills)"@en ; dcterms:source "Review checklist 05-ddl, row 4; this skill (08-ddl.md)"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-805" ; rdfs:label "Rule marked `constraint` with no constraint in the SQL (generated DDL)"@en ; skos:prefLabel "Rule marked `constraint` with no constraint in the SQL (generated DDL)"@en ; skos:definition "A live data rule with `enforcement: constraint` whose constraint is nowhere in the generated DDL, because it was never carried into the physical model. The rule register says the database guarantees it; the database has never heard of it, and no DQ rule covers it either."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "generated DDL"@en ; edu:expectedResult "A finding that names the defective generated DDL element and the defect"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `BR-005: a loan's maturity date is after its opening date`, `enforcement: constraint`; `dim_account` has no matching `ck_` in any dialect's output and no DQ rule cites `BR-005` Acceptable: `ck_dim_account_maturity_after_opening` in the model's `check_constraints` and in the SQL; or the rule moved to `enforcement: dq-check` with a DQ rule citing it (`TRC-006`, `DQR-007`)"@en ; edu:assessmentMethod "skill-tests task: Generated DDL review, Postgres and Snowflake (DDL review skills)"@en ; dcterms:source "Review checklist 05-ddl, row 5; this skill (03-data-rules.md)"@en ; schema:supersededBy ; schema:creativeWorkStatus "superseded" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-806" ; rdfs:label "Recognises a configured dialect left unregenerated"@en ; skos:prefLabel "Recognises a configured dialect left unregenerated"@en ; skos:altLabel "One target regenerated, several deployed (generated DDL)"@en ; skos:definition "`model-config.yaml` naming several dialects and `08-ddl/` holding one fresh directory. The stale ones are where the design actually breaks, because the differences between engines are exactly what rows 7–14 are about."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "configured dialect output"@en ; edu:expectedResult "The stale or missing dialect directory"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `dialects: [postgres, snowflake]`; Postgres regenerated, `08-ddl/snowflake/` three model versions old and still missing `payment_status_code` entirely Acceptable: `--dialect all --no-timestamp` in one pass, every directory in the same commit, and the review repeated per dialect"@en ; edu:assessmentMethod "skill-tests task: Generated DDL review, Postgres and Snowflake (DDL review skills)"@en ; dcterms:source "Review checklist 05-ddl, row 6; this skill (08-ddl.md)"@en ; edu:appliesKnowledge ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-807" ; rdfs:label "`-- NOT ENFORCED` read as a guarantee (generated DDL)"@en ; skos:prefLabel "`-- NOT ENFORCED` read as a guarantee (generated DDL)"@en ; skos:definition "On Snowflake and Databricks every primary key, unique constraint and foreign key is documentation: the syntax is accepted and nothing is checked. Look for a key the design quietly relies on with no DQ rule behind it, and for a load that assumes referential integrity it will not get."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "generated DDL"@en ; edu:expectedResult "A finding that names the defective generated DDL element and the defect"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Snowflake target; `uk_dim_account_nk` emitted `-- NOT ENFORCED` with no `uniqueness` DQ rule. A rerun of the nightly load inserts a second current version of every account, and every payment joins twice Acceptable: The constraint kept — the optimiser and the BI layer read it — and a `uniqueness` DQ rule naming it in `backs`, plus an unknown-member row so an unmatched `account_key` is visible rather than orphaned (`DQR-017`, `DQR-018`)"@en ; edu:assessmentMethod "skill-tests task: Generated DDL review, Postgres and Snowflake (DDL review skills)"@en ; dcterms:source "Review checklist 05-ddl, row 7; this skill (08-ddl.md); ISO 9075"@en ; schema:supersededBy ; schema:creativeWorkStatus "superseded" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-808" ; rdfs:label "Recognises a CHECK constraint parsed and ignored"@en ; skos:prefLabel "Recognises a CHECK constraint parsed and ignored"@en ; skos:altLabel "CHECK parsed and silently ignored (generated DDL)"@en ; skos:definition "MySQL before 8.0.16 parses `CHECK` and ignores it, which is worse than rejecting it. `--mysql-version 5.7` makes the generator emit them commented out with a header note; without the flag they are emitted live and read as enforced."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "CHECK on MySQL before 8.0.16"@en ; edu:expectedResult "The checks to cover by data quality rules"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: MySQL 5.7 target generated without `--mysql-version`; `ck_fact_payment_status_code` listing `PND`, `SET`, `RTN` deploys cleanly, enforces nothing, and a changed feed loads `SETT` for a month before a report notices Acceptable: `--mysql-version 5.7`, the checks commented out so no reader believes otherwise, and a `validity` DQ rule for `payment_status_code` for as long as that target is in scope"@en ; edu:assessmentMethod "skill-tests task: Generated DDL review, Postgres and Snowflake (DDL review skills)"@en ; dcterms:source "Review checklist 05-ddl, row 8; this skill (08-ddl.md); ISO 9075"@en ; edu:appliesKnowledge ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-809" ; rdfs:label "Recognises an expression running on one engine only"@en ; skos:prefLabel "Recognises an expression running on one engine only"@en ; skos:altLabel "Expression that only runs on one engine (generated DDL)"@en ; skos:definition "Check-constraint and default expressions pass through verbatim — the generator orders the column clauses per dialect (Oracle and Snowflake want `DEFAULT` before `NOT NULL`) but it cannot translate an expression. Look for vendor functions, regex operators, `||` versus `+`, and date arithmetic."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "check or default expression"@en ; edu:expectedResult "The vendor-specific expression and its portable form"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `ck_fact_payment_reference` written as `payment_reference ~ '^[A-Z0-9]{8,24}$'`; it generates on all five targets and deploys only on Postgres. `COALESCE(valid_to_date, 'infinity')` in `ck_dim_account_version_dates` fails everywhere but Postgres Acceptable: Portable expressions only — comparisons, `BETWEEN`, `IN`, `IS NULL`, `LENGTH`: `LENGTH(payment_reference) BETWEEN 8 AND 24` as the constraint and the pattern as a `validity` DQ rule; a closed end date instead of `'infinity'`"@en ; edu:assessmentMethod "skill-tests task: Generated DDL review, Postgres and Snowflake (DDL review skills)"@en ; dcterms:source "Review checklist 05-ddl, row 9; ISO 9075; this skill (08-ddl.md)"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-810" ; rdfs:label "Recognises a truncated identifier taken as the real name"@en ; skos:prefLabel "Recognises a truncated identifier taken as the real name"@en ; skos:altLabel "Truncated identifier taken as the real name (generated DDL)"@en ; skos:definition "A header warning that a name was over the target's limit and was emitted with an 8-character hash suffix. The hashed form is the name in the database, and it is what appears in the constraint-violation message that operations has to interpret at 3am."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "hashed identifier"@en ; edu:expectedResult "The real database name and the model change avoiding it"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Oracle 11g target (`--oracle-max-identifier 30`); `ix_fact_payment_account_key_value_date_key_status_code` emitted as `ix_fact_payment_accou_a91c4f2e`, which exists in no document anyone can search Acceptable: `conventions.abbreviations` in `model-config.yaml` applied consistently (`acct`, `val`, `sts` — never sometimes one and sometimes another) and the name shortened in the model until the warning is gone (`PHY-010`)"@en ; edu:assessmentMethod "skill-tests task: Generated DDL review, Postgres and Snowflake (DDL review skills)"@en ; dcterms:source "Review checklist 05-ddl, row 10; this skill (08-ddl.md)"@en ; edu:appliesKnowledge ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-811" ; rdfs:label "Recognises a reserved word used as an identifier"@en ; skos:prefLabel "Recognises a reserved word used as an identifier"@en ; skos:altLabel "Reserved word as an identifier (generated DDL)"@en ; skos:definition "A table or column name that is reserved on one of the configured targets. It can quote cleanly on four engines and fail on the fifth, or deploy everywhere and break the first hand-written query."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "table or column name"@en ; edu:expectedResult "The name, the engine reserving it and its replacement"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: A `dim_party` column named `current` for the current relationship owner: reserved in ISO 9075 and in Postgres Acceptable: `is_current_relationship`, with the reserved-word check run against every configured dialect rather than only the development one (`PHY-012`)"@en ; edu:assessmentMethod "skill-tests task: Generated DDL review, Postgres and Snowflake (DDL review skills)"@en ; dcterms:source "Review checklist 05-ddl, row 11; ISO 9075; this skill"@en ; edu:appliesKnowledge ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-812" ; rdfs:label "Recognises a type meaning something else on another engine"@en ; skos:prefLabel "Recognises a type meaning something else on another engine"@en ; skos:altLabel "Type that silently means something else (generated DDL)"@en ; skos:definition "One modelled type rendering to a different meaning per engine. `TIMESTAMP` is a row-version counter in T-SQL (emitted `DATETIME2(6)`) and 32-bit, 2038-bounded and session-time-zone-converting in MySQL (emitted `DATETIME`); `BOOLEAN` becomes `NUMBER(1)` on Oracle and `TINYINT(1)`, which accepts 42, on MySQL; Databricks collapses `VARCHAR(n)` to `STRING`."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "modelled type rendered per engine"@en ; edu:expectedResult "The type and its meaning on each engine"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `is_business_day BOOLEAN` on MySQL becomes `TINYINT(1)` with no check and a loader writes `2` for a half day. `account_number VARCHAR(20)` on Databricks accepts a 34-character value, and the joins to `fact_payment` start missing Acceptable: A check constraint for the 0/1 domain wherever the engine has no boolean, and the modelled length kept as a DQ rule on every target that does not enforce it — the header note says which ones those are"@en ; edu:assessmentMethod "skill-tests task: Generated DDL review, Postgres and Snowflake (DDL review skills)"@en ; dcterms:source "Review checklist 05-ddl, row 12; ISO 9075; this skill (08-ddl.md)"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-813" ; rdfs:label "Recognises an index the target engine cannot create or run"@en ; skos:prefLabel "Recognises an index the target engine cannot create or run"@en ; skos:altLabel "Index that cannot exist, or will not run (generated DDL)"@en ; skos:definition "Snowflake has no `CREATE INDEX` at all, so index definitions come out commented out and the real lever is a clustering key. MySQL cannot index a `TEXT`/`BLOB` column without a prefix length, and the script will fail at that statement."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "index definition"@en ; edu:expectedResult "The index and the engine-specific lever to use"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Snowflake; `ix_dim_account_number_current` commented out, no `cluster_by` set, and every point lookup on `dim_account` scans it. MySQL; `relationship_manager_notes` (`TEXT`) left in an index after the generator warned Acceptable: `physical_options.snowflake: {cluster_by: [account_number]}` and the Databricks equivalent — as the sample model has them — and the notes column bounded to a `VARCHAR` in the model, or removed from the index"@en ; edu:assessmentMethod "skill-tests task: Generated DDL review, Postgres and Snowflake (DDL review skills)"@en ; dcterms:source "Review checklist 05-ddl, row 13; this skill (08-ddl.md)"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-814" ; rdfs:label "Recognises a foreign-key cycle taken as resolved"@en ; skos:prefLabel "Recognises a foreign-key cycle taken as resolved"@en ; skos:altLabel "Foreign-key cycle fallback treated as resolved (generated DDL)"@en ; skos:definition "The header note saying all tables are created first and every foreign key added afterwards as `ALTER TABLE`. The script runs; the design does not. Two tables each mandatory to the other cannot be loaded without deferring a constraint, and not every engine can defer one."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "foreign keys added after table creation"@en ; edu:expectedResult "The cycle and the load order or deferral it needs"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `dim_account.primary_card_key` → `dim_card` and `dim_card.account_key` → `dim_account`, both `NOT NULL`; the DDL deploys and the first load has no row it can insert first Acceptable: One direction made optional, or the \"primary card\" relationship moved into its own table. The cycle is resolved in the logical model, not worked around in the load (the header note is a prompt, not a solution)"@en ; edu:assessmentMethod "skill-tests task: Generated DDL review, Postgres and Snowflake (DDL review skills)"@en ; dcterms:source "Review checklist 05-ddl, row 14; ISO 9075; this skill (08-ddl.md)"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-815" ; rdfs:label "Money in binary floating point (generated DDL)"@en ; skos:prefLabel "Money in binary floating point (generated DDL)"@en ; skos:definition "`FLOAT`, `REAL` or `DOUBLE PRECISION` on anything that is money — an amount, a balance, a rate applied to money, a quantity that is summed and then reconciled. 0.01 has no exact binary representation, so the total depends on the order of the rows and the ledger never agrees twice."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "generated DDL"@en ; edu:expectedResult "A finding that names the defective generated DDL element and the defect"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `instructed_amount DOUBLE PRECISION`; the daily settlement total differs from core banking by a few cents, and by a different few cents after the table is repartitioned Acceptable: `DECIMAL(14,2)` as the sample model has it, and `DECIMAL`/`NUMERIC` for every amount and for `loan_interest_rate` (e.g. `DECIMAL(7,5)`). `FLOAT` only for a statistic nobody reconciles, such as a propensity score"@en ; edu:assessmentMethod "skill-tests task: Generated DDL review, Postgres and Snowflake (DDL review skills)"@en ; dcterms:source "Review checklist 05-ddl, row 15; IEEE 754; ISO 9075"@en ; schema:supersededBy ; schema:creativeWorkStatus "superseded" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-816" ; rdfs:label "Recognises one decimal scale for every currency"@en ; skos:prefLabel "Recognises one decimal scale for every currency"@en ; skos:altLabel "One scale for every currency (generated DDL)"@en ; skos:definition "`DECIMAL(n,2)` on an amount column in a table that is not single-currency. ISO 4217's minor-unit table is not a constant 2: JPY has 0, KWD and BHD have 3. Two decimals silently round a dinar instruction and store two meaningless zeros on a yen one."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "amount column in a multi-currency table"@en ; edu:expectedResult "The column and the scale its currencies need"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `fact_payment.instructed_amount DECIMAL(14,2)` with `account_currency_code` ranging over ISO 4217; a KWD payment of 12.345 is stored as 12.35 and the original instruction can no longer be reproduced Acceptable: Scale set to the widest minor unit in scope (`DECIMAL(16,3)`), the per-currency minor-unit digits held in the currency reference table, and a DQ rule that an amount's minor units match its currency. Or the single-currency scope stated in the column `comment`, so the next reviewer knows `2` was a decision"@en ; edu:assessmentMethod "skill-tests task: Generated DDL review, Postgres and Snowflake (DDL review skills)"@en ; dcterms:source "Review checklist 05-ddl, row 16; ISO 4217"@en ; edu:dependsOnKnobit ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-817" ; rdfs:label "Recognises a length taken from sample data"@en ; skos:prefLabel "Recognises a length taken from sample data"@en ; skos:altLabel "Length taken from the sample, not the domain (generated DDL)"@en ; skos:definition "A `VARCHAR`/`CHAR` sized from the data that happened to be loaded in development. An IBAN is up to 34 characters, a BIC is 8 or 11, a SEPA party name is 70. Too short truncates on some engines and errors on others, and a truncated IBAN is a payment to nobody."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "VARCHAR or CHAR length"@en ; edu:expectedResult "The column and the length its domain standard sets"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `dim_account.account_number VARCHAR(20)` on a mart that will also hold non-Estonian accounts: correct for every Estonian IBAN and 14 characters short of a Maltese one Acceptable: Either `VARCHAR(34)` from the standard with the 20-character Estonian form as a DQ rule scoped to Estonian IBANs, or `VARCHAR(20)` with the Estonia-only scope written in the column `comment` and in the rule. What is not acceptable is a length nobody chose"@en ; edu:assessmentMethod "skill-tests task: Generated DDL review, Postgres and Snowflake (DDL review skills)"@en ; dcterms:source "Review checklist 05-ddl, row 17; ISO 13616; this skill"@en ; edu:dependsOnKnobit ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-818" ; rdfs:label "Point in time without a zone, business date with a clock (generated DDL)"@en ; skos:prefLabel "Point in time without a zone, business date with a clock (generated DDL)"@en ; skos:definition "Two mirror-image defects. An event timestamp with no offset is ambiguous twice a year and incomparable across a bank that books in more than one zone. A business date — value date, booking date, maturity date, due date — stored as a timestamp invites a time component nobody means and makes date equality quietly fail."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "generated DDL"@en ; edu:expectedResult "A finding that names the defective generated DDL element and the defect"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `created_at TIMESTAMP` with no zone on `dim_account`, written by jobs in two regions. And `payment_value_date` as a `TIMESTAMP`, so `= DATE '2026-03-31'` matches none of the rows loaded at 23:30 Acceptable: `TIMESTAMP WITH TIME ZONE` for event times, or UTC with the convention stated in the column `comment` and nowhere else; `DATE` for `payment_value_date`, `loan_maturity_date` and `valid_from_date`/`valid_to_date`, as the sample model has them"@en ; edu:assessmentMethod "skill-tests task: Generated DDL review, Postgres and Snowflake (DDL review skills)"@en ; dcterms:source "Review checklist 05-ddl, row 18; ISO 8601; ISO 9075"@en ; schema:supersededBy ; schema:supersededBy ; schema:creativeWorkStatus "superseded" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-819" ; rdfs:label "Recognises a collation changing what a key means"@en ; skos:prefLabel "Recognises a collation changing what a key means"@en ; skos:altLabel "Collation that changes what a key means (generated DDL)"@en ; skos:definition "The case and accent sensitivity of the columns in a key, which on most engines comes from a server or database default nobody chose here. Case-insensitive makes an IBAN and its lower-case form one key; case- and accent-sensitive makes `Mägi` and `Magi` two parties. Either can be right; an unexamined default cannot."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "key column collation"@en ; edu:expectedResult "The collation and the case or accent sensitivity the key needs"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: SQL Server with the usual case-insensitive database collation: `uk_dim_party_reference` treats `ee-00412` and `EE-00412` as one party, and a migration from a case-sensitive source merges two customers into one with no error Acceptable: Identifiers normalised on load (IBAN upper-cased, spaces removed) so the key does not depend on collation, and the collation named in `physical_options` for the engines that accept it — making the key's meaning a decision in the model rather than a server setting"@en ; edu:assessmentMethod "skill-tests task: Generated DDL review, Postgres and Snowflake (DDL review skills)"@en ; dcterms:source "Review checklist 05-ddl, row 19; UTS #10; ISO 9075"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-820" ; rdfs:label "Recognises a default inventing a business fact"@en ; skos:prefLabel "Recognises a default inventing a business fact"@en ; skos:altLabel "Default that invents a business fact (generated DDL)"@en ; skos:definition "A `DEFAULT` on a business column rather than a technical one. `CURRENT_DATE` on a value date fabricates a date when the feed omits one; `0` on an amount turns \"unknown\" into \"zero\", and the zero then sums into a total that reconciles; `'OPN'` on a status decides a business state on the loader's behalf."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "DEFAULT on a business column"@en ; edu:expectedResult "The default and the null or rule replacing it"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `settled_amount DECIMAL(14,2) DEFAULT 0`: unsettled payments arrive as zero, the settlement total reconciles to the cent, and the missing settlements are invisible in exactly the figure someone reports Acceptable: `settled_amount` nullable with no default and a completeness DQ rule over the payments that should have settled. Defaults only on `created_at`/`updated_at` and on identity columns — and note the generator rejects a column that declares both `identity: true` and a `default`"@en ; edu:assessmentMethod "skill-tests task: Generated DDL review, Postgres and Snowflake (DDL review skills)"@en ; dcterms:source "Review checklist 05-ddl, row 20; ISO 9075; Kimball 2013"@en ; edu:dependsOnKnobit ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-821" ; rdfs:label "Recognises a restricted column without access design"@en ; skos:prefLabel "Recognises a restricted column without access design"@en ; skos:altLabel "Restricted column with no access design (generated DDL)"@en ; skos:definition "A column classified `restricted` or `confidential` in the model, created by a plain `CREATE TABLE`. The generator deliberately emits no `GRANT`, role, masking policy or row-level security, so the finding is never \"the SQL is missing them\" — it is that nothing else covers them and the table is about to exist where everyone can read it."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "classified column"@en ; edu:expectedResult "The column and the grants, masking or row security it needs"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `dim_party.birth_date` and a card number column, both `restricted`, created in `rpdm` with no masked view, no role and nothing in the handover; a full PAN sitting in an analytics schema forty analysts can query Acceptable: The restricted columns listed in the handover with the access design each needs — a masked view, a separate role, the PAN truncated to the last four digits or left in the card system — written and reviewed as its own script. The classifications drive that conversation; they do not generate it"@en ; edu:assessmentMethod "skill-tests task: Generated DDL review, Postgres and Snowflake (DDL review skills)"@en ; dcterms:source "Review checklist 05-ddl, row 21; PCI DSS v4.0; this skill (08-ddl.md)"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-822" ; rdfs:label "Recognises greenfield DDL aimed at a populated database"@en ; skos:prefLabel "Recognises greenfield DDL aimed at a populated database"@en ; skos:altLabel "Greenfield DDL run against a populated database (generated DDL)"@en ; skos:definition "`08-ddl/` handed to a release for an environment that already has data. This output builds a schema from nothing. The changes that look smallest in the diff are the ones that need a backfill plan — a nullable column tightened to `NOT NULL`, a widened or narrowed type, a split column — and on Databricks `ALTER TABLE ... ADD CONSTRAINT` validates the existing rows and fails on the first violation."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "generated DDL for a release"@en ; edu:expectedResult "The changes needing a backfill and a migration"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `account_number` tightened to `NOT NULL` in the model and the regenerated DDL given to the release; 3 % of migrated accounts have no IBAN, the deploy fails halfway, and the schema is left with half its constraints applied Acceptable: The regenerated DDL diffed against the previous version as the statement of intent, and the migration hand-written for that diff where deployment lives (Flyway, Liquibase, dbt, Alembic) with backfill and rollback — then verified by rebuilding an empty database from the generated DDL and comparing it with the migrated one"@en ; edu:assessmentMethod "skill-tests task: Generated DDL review, Postgres and Snowflake (DDL review skills)"@en ; dcterms:source "Review checklist 05-ddl, row 22; Ambler & Sadalage 2006; this skill (08-ddl.md)"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-823" ; rdfs:label "Recognises a drop script used as a rollback"@en ; skos:prefLabel "Recognises a drop script used as a rollback"@en ; skos:altLabel "Drop script used as a migration rollback (generated DDL)"@en ; skos:definition "`99_drop_tables.sql` in a release runbook's rollback step. It drops the tables in reverse dependency order, which is a rollback for a greenfield deploy into a scratch or CI database. Anywhere else it is a data-loss procedure with a reassuring filename."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "drop script in a runbook"@en ; edu:expectedResult "The data it would remove and the real rollback"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: The runbook for a `fact_payment` change says \"on failure, run `99_drop_tables.sql` and redeploy\"; run against the warehouse it removes four years of payments and every dimension they pointed at Acceptable: `99_drop_tables.sql` used only to rebuild the CI scratch database. The migration's rollback is written with the migration, and the runbook names the restore point for every step that cannot be reversed"@en ; edu:assessmentMethod "skill-tests task: Generated DDL review, Postgres and Snowflake (DDL review skills)"@en ; dcterms:source "Review checklist 05-ddl, row 23; this skill (08-ddl.md); Humble & Farley 2010"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-824" ; rdfs:label "Recognises an environment baked into the script"@en ; skos:prefLabel "Recognises an environment baked into the script"@en ; skos:altLabel "Environment baked into the script (generated DDL)"@en ; skos:definition "A schema or database name hard-wired so the reviewed artefact cannot build dev, test and production — which ends in somebody editing the SQL per environment, and so in row 1. Also the generator's warning that `model-config.yaml` and the model disagree about the schema."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "hard-wired schema or database name"@en ; edu:expectedResult "The name and the configuration replacing it"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `schema: rpdm_dev` in the model; the production deploy is the same file with a `sed` in the pipeline, and the staging deploy is a copy somebody kept Acceptable: `schema: rpdm` in the model, with the environment supplied at generation time via `--schema`/`--database` or at deploy time by the session's search path; and the config/model disagreement warning closed rather than carried"@en ; edu:assessmentMethod "skill-tests task: Generated DDL review, Postgres and Snowflake (DDL review skills)"@en ; dcterms:source "Review checklist 05-ddl, row 24; Humble & Farley 2010; this skill (08-ddl.md)"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-825" ; rdfs:label "Recognises SQL reviewed without being run"@en ; skos:prefLabel "Recognises SQL reviewed without being run"@en ; skos:altLabel "SQL that has been read and never run (generated DDL)"@en ; skos:definition "A `.sql` signed off by reading it. Most engines do not wrap DDL in one transaction, so a script that fails on statement 40 of 60 leaves a half-built schema that looks deployable and is not. The review cannot find a failure the engine has never been asked for."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "unexecuted DDL"@en ; edu:expectedResult "The execution test it needs"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Five dialects generated, Postgres run locally, and the Oracle and Databricks scripts approved by reading them; the Oracle deploy stops at the first check constraint over a `BOOLEAN`-derived `NUMBER(1)` column Acceptable: Every configured dialect executed against an empty database — a container or a scratch schema — in CI, with the drop script run afterwards. The gate for this stage is a green run, not a careful read"@en ; edu:assessmentMethod "skill-tests task: Generated DDL review, Postgres and Snowflake (DDL review skills)"@en ; dcterms:source "Review checklist 05-ddl, row 25; Humble & Farley 2010; BCBS 239"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-826" ; rdfs:label "Recognises undetected drift between database and model"@en ; skos:prefLabel "Recognises undetected drift between database and model"@en ; skos:altLabel "Drift between the database and the model never detected (generated DDL)"@en ; skos:definition "Nothing that compares the deployed catalogue with the current generated DDL. Hotfix indexes, emergency nullability changes and a column someone added under incident pressure accumulate in production, and the model stops describing the thing people actually query — while continuing to look right, which is what makes it dangerous."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "deployed catalogue"@en ; edu:expectedResult "The missing comparison with the generated DDL"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `ix_fact_payment_status_code` added in production during an incident eighteen months ago. It exists in no environment's DDL and in no model, and the next rebuild of the mart is slow for reasons nobody can reconstruct Acceptable: A scheduled comparison of the deployed catalogue (`information_schema`, or the engine's own schema-compare tooling) with the generated DDL, each difference closed deliberately — into the model, or out of the database — and the comparison's result part of the stage-8 evidence"@en ; edu:assessmentMethod "skill-tests task: Generated DDL review, Postgres and Snowflake (DDL review skills)"@en ; dcterms:source "Review checklist 05-ddl, row 26; BCBS 239; Humble & Farley 2010"@en ; edu:appliesKnowledge ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-531" ; rdfs:label "Traces a logical-model anomaly to its structural cause"@en ; skos:prefLabel "Traces a logical-model anomaly to its structural cause"@en ; skos:definition "Links an insertion, update or deletion anomaly to the defect that produces it, such as a repeating group or a transitive dependency, so the repair removes the cause."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Traces"@en ; edu:targetObject "structural cause of a logical-model anomaly"@en ; edu:expectedResult "Each anomaly paired with the dependency, group or missing entity that causes it"@en ; edu:assessmentCriterion "Names, for each reported anomaly, the structural cause it comes from, and fixes the cause rather than the symptom"@en ; edu:assessmentMethod "skill-tests task: Loan application logical model (normalisation anomaly skills)"@en ; dcterms:source "Stage 5 reference (references/05-logical.md) and the skill-tests logical-model task"@en ; edu:appliesKnowledge ; edu:followedBy ; edu:followedBy ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-532" ; rdfs:label "Records the functional dependencies of an entity"@en ; skos:prefLabel "Records the functional dependencies of an entity"@en ; skos:definition "Writes down which attributes determine which, from the business rules, so that every normal-form judgement rests on stated dependencies."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Records"@en ; edu:targetObject "functional dependencies of an entity"@en ; edu:expectedResult "The entity's functional dependencies written as determinant -> dependents"@en ; edu:assessmentCriterion "Every dependency the business rules imply is written down, read from the rules and not from the attribute names"@en ; edu:assessmentMethod "skill-tests task: Loan application logical model (normalisation anomaly skills)"@en ; dcterms:source "Stage 5 reference (references/05-logical.md) and the skill-tests logical-model task"@en ; edu:appliesKnowledge ; edu:appliesKnowledge ; edu:followedBy ; edu:followedBy ; edu:followedBy ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-533" ; rdfs:label "Decomposes an entity along a functional dependency without loss"@en ; skos:prefLabel "Decomposes an entity along a functional dependency without loss"@en ; skos:definition "Repairs a normal-form violation by moving the determinant and its dependents into an entity of their own, losslessly and preserving dependencies."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Decomposes"@en ; edu:targetObject "entity with a partial, transitive or non-key dependency"@en ; edu:expectedResult "Two or more entities that join back to exactly the original rows and keep every dependency enforceable"@en ; edu:assessmentCriterion "The shared attributes are a key of one part, no dependency is left spanning two entities, and the dependent attributes move with their determinant"@en ; edu:assessmentMethod "skill-tests task: Loan application logical model (normalisation anomaly skills)"@en ; dcterms:source "Stage 5 reference (references/05-logical.md) and the skill-tests logical-model task"@en ; edu:appliesKnowledge ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-534" ; rdfs:label "Resolves a many-to-many relationship into an associative entity"@en ; skos:prefLabel "Resolves a many-to-many relationship into an associative entity"@en ; skos:definition "Turns a many-to-many relationship into an entity of its own so that its facts (roles, dates, shares) have a place."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Resolves"@en ; edu:targetObject "unresolved many-to-many relationship"@en ; edu:expectedResult "An associative entity carrying the relationship's facts, with cardinality stated in both directions"@en ; edu:assessmentCriterion "The facts of the relationship live on the associative entity, its cardinality is stated both ways, and attributes duplicated elsewhere to stand in for it are removed"@en ; edu:assessmentMethod "skill-tests task: Loan application logical model (normalisation anomaly skills)"@en ; dcterms:source "Stage 5 reference (references/05-logical.md) and the skill-tests logical-model task"@en ; edu:appliesKnowledge ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-535" ; rdfs:label "Replaces a repeating group with a dependent entity"@en ; skos:prefLabel "Replaces a repeating group with a dependent entity"@en ; skos:definition "Moves numbered or listed attributes into an entity of their own, so any number of occurrences can be recorded."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Replaces"@en ; edu:targetObject "repeating group in an entity"@en ; edu:expectedResult "A dependent entity with its own identifier, one row per occurrence"@en ; edu:assessmentCriterion "Every repeated property moves to the new entity, which has its own identifier and no fixed upper limit"@en ; edu:assessmentMethod "skill-tests task: Loan application logical model (normalisation anomaly skills)"@en ; dcterms:source "Stage 5 reference (references/05-logical.md) and the skill-tests logical-model task"@en ; edu:appliesKnowledge ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-536" ; rdfs:label "Introduces subtypes for attributes applying to only some instances"@en ; skos:prefLabel "Introduces subtypes for attributes applying to only some instances"@en ; skos:definition "Replaces optional attributes that are optional only because they do not apply to some instances with subtypes, so a null no longer means two things."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Introduces"@en ; edu:targetObject "subtypes for inapplicable attributes"@en ; edu:expectedResult "Subtypes carrying the attributes that apply to them, each mandatory where it applies"@en ; edu:assessmentCriterion "Each attribute sits on the subtype it applies to and can be mandatory there; the exclusivity is written down"@en ; edu:assessmentMethod "skill-tests task: Loan application logical model (normalisation anomaly skills)"@en ; dcterms:source "Stage 5 reference (references/05-logical.md) and the skill-tests logical-model task"@en ; edu:appliesKnowledge ; edu:followedBy ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-551" ; rdfs:label "Explains functional dependency"@en ; skos:prefLabel "Explains functional dependency"@en ; skos:definition "A dependency X -> Y holds when each value of X determines exactly one value of Y."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "functional dependency"@en ; edu:expectedResult "A dependency X -> Y holds when each value of X determines exactly one value of Y"@en ; edu:assessmentCriterion "States the definition and lists the functional dependencies of a sample entity from its business rules, not from its attribute names"@en ; edu:assessmentMethod "Written question with sample entities"@en ; dcterms:source "Normalisation theory and relational design (Codd, Fagin, Date), as used by the stage 5 reference and review checklist"@en ; edu:dependsOnKnobit ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-552" ; rdfs:label "Explains candidate key and prime attribute"@en ; skos:prefLabel "Explains candidate key and prime attribute"@en ; skos:definition "A candidate key is a minimal set of attributes that determines all others; a prime attribute belongs to a candidate key."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "candidate key and prime attribute"@en ; edu:expectedResult "A candidate key is a minimal set of attributes that determines all others; a prime attribute belongs to a candidate key"@en ; edu:assessmentCriterion "Finds every candidate key of a sample entity from its dependencies and classifies its attributes as prime or non-prime"@en ; edu:assessmentMethod "Written question with sample entities"@en ; dcterms:source "Normalisation theory and relational design (Codd, Fagin, Date), as used by the stage 5 reference and review checklist"@en ; edu:dependsOnKnobit ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-553" ; rdfs:label "Explains the insertion, update and deletion anomalies"@en ; skos:prefLabel "Explains the insertion, update and deletion anomalies"@en ; skos:definition "The three anomalies and the redundancy that produces them."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "insertion, update and deletion anomalies"@en ; edu:expectedResult "The three anomalies and the redundancy that produces them"@en ; edu:assessmentCriterion "Defines each anomaly and gives an example of each in a sample entity"@en ; edu:assessmentMethod "Written question with sample entities"@en ; dcterms:source "Normalisation theory and relational design (Codd, Fagin, Date), as used by the stage 5 reference and review checklist"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-554" ; rdfs:label "Explains first normal form"@en ; skos:prefLabel "Explains first normal form"@en ; skos:definition "Every attribute holds one atomic value and no property repeats."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "first normal form"@en ; edu:expectedResult "Every attribute holds one atomic value and no property repeats"@en ; edu:assessmentCriterion "Classifies sample entities as in or not in 1NF and names the violation"@en ; edu:assessmentMethod "Written question with sample entities"@en ; dcterms:source "Normalisation theory and relational design (Codd, Fagin, Date), as used by the stage 5 reference and review checklist"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-555" ; rdfs:label "Explains second normal form"@en ; skos:prefLabel "Explains second normal form"@en ; skos:definition "No non-prime attribute depends on part of a candidate key."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "second normal form"@en ; edu:expectedResult "No non-prime attribute depends on part of a candidate key"@en ; edu:assessmentCriterion "Classifies sample entities with composite keys as in or not in 2NF and names the partial dependency"@en ; edu:assessmentMethod "Written question with sample entities"@en ; dcterms:source "Normalisation theory and relational design (Codd, Fagin, Date), as used by the stage 5 reference and review checklist"@en ; edu:dependsOnKnobit ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-556" ; rdfs:label "Explains third normal form"@en ; skos:prefLabel "Explains third normal form"@en ; skos:definition "No non-prime attribute depends transitively on a candidate key."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "third normal form"@en ; edu:expectedResult "No non-prime attribute depends transitively on a candidate key"@en ; edu:assessmentCriterion "Classifies sample entities as in or not in 3NF and names the transitive dependency"@en ; edu:assessmentMethod "Written question with sample entities"@en ; dcterms:source "Normalisation theory and relational design (Codd, Fagin, Date), as used by the stage 5 reference and review checklist"@en ; edu:dependsOnKnobit ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-557" ; rdfs:label "Explains Boyce-Codd normal form"@en ; skos:prefLabel "Explains Boyce-Codd normal form"@en ; skos:definition "Every determinant is a superkey; why a 3NF entity can still have anomalies."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "Boyce-Codd normal form"@en ; edu:expectedResult "Every determinant is a superkey; why a 3NF entity can still have anomalies"@en ; edu:assessmentCriterion "Finds the BCNF violation in a 3NF entity with overlapping candidate keys"@en ; edu:assessmentMethod "Written question with sample entities"@en ; dcterms:source "Normalisation theory and relational design (Codd, Fagin, Date), as used by the stage 5 reference and review checklist"@en ; edu:dependsOnKnobit ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-558" ; rdfs:label "Explains multivalued dependency and fourth normal form"@en ; skos:prefLabel "Explains multivalued dependency and fourth normal form"@en ; skos:definition "Independent multi-valued facts of one thing belong in separate entities."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "multivalued dependency and fourth normal form"@en ; edu:expectedResult "Independent multi-valued facts of one thing belong in separate entities"@en ; edu:assessmentCriterion "Classifies sample entities as in or not in 4NF and names the independent multivalued dependencies"@en ; edu:assessmentMethod "Written question with sample entities"@en ; dcterms:source "Normalisation theory and relational design (Codd, Fagin, Date), as used by the stage 5 reference and review checklist"@en ; edu:dependsOnKnobit ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-559" ; rdfs:label "Explains join dependency and fifth normal form"@en ; skos:prefLabel "Explains join dependency and fifth normal form"@en ; skos:definition "When a three-way entity is the join of its projections, and the cyclic rule that makes it so."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "join dependency and fifth normal form"@en ; edu:expectedResult "When a three-way entity is the join of its projections, and the cyclic rule that makes it so"@en ; edu:assessmentCriterion "Decides for sample three-way entities whether a cyclic rule holds and whether the entity should be decomposed"@en ; edu:assessmentMethod "Written question with sample entities"@en ; dcterms:source "Normalisation theory and relational design (Codd, Fagin, Date), as used by the stage 5 reference and review checklist"@en ; edu:dependsOnKnobit ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-560" ; rdfs:label "Explains sixth normal form for temporal data"@en ; skos:prefLabel "Explains sixth normal form for temporal data"@en ; skos:definition "Attributes that change independently over time get their own validity periods."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "sixth normal form"@en ; edu:expectedResult "Attributes that change independently over time get their own validity periods"@en ; edu:assessmentCriterion "Groups the attributes of a sample history entity by when they change and justifies the split"@en ; edu:assessmentMethod "Written question with sample entities"@en ; dcterms:source "Normalisation theory and relational design (Codd, Fagin, Date), as used by the stage 5 reference and review checklist"@en ; edu:dependsOnKnobit ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-561" ; rdfs:label "Explains domain-key normal form"@en ; skos:prefLabel "Explains domain-key normal form"@en ; skos:definition "Every constraint follows from keys and domains."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "domain-key normal form"@en ; edu:expectedResult "Every constraint follows from keys and domains"@en ; edu:assessmentCriterion "Classifies sample constraints as implied by keys and domains or not, and says how each other one is enforced"@en ; edu:assessmentMethod "Written question with sample entities"@en ; dcterms:source "Normalisation theory and relational design (Codd, Fagin, Date), as used by the stage 5 reference and review checklist"@en ; edu:dependsOnKnobit ; edu:dependsOnKnobit ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-562" ; rdfs:label "Explains attribute domains"@en ; skos:prefLabel "Explains attribute domains"@en ; skos:definition "An attribute has one meaning, one type and one set of allowed values."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "attribute domain"@en ; edu:expectedResult "An attribute has one meaning, one type and one set of allowed values"@en ; edu:assessmentCriterion "Names the domain of each attribute of a sample entity and finds the attribute whose meaning varies"@en ; edu:assessmentMethod "Written question with sample entities"@en ; dcterms:source "Normalisation theory and relational design (Codd, Fagin, Date), as used by the stage 5 reference and review checklist"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-563" ; rdfs:label "Explains lossless-join decomposition"@en ; skos:prefLabel "Explains lossless-join decomposition"@en ; skos:definition "A split is lossless only if the shared attributes are a key of at least one part."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "lossless-join decomposition"@en ; edu:expectedResult "A split is lossless only if the shared attributes are a key of at least one part"@en ; edu:assessmentCriterion "Decides for sample decompositions whether joining back produces spurious rows"@en ; edu:assessmentMethod "Written question with sample entities"@en ; dcterms:source "Normalisation theory and relational design (Codd, Fagin, Date), as used by the stage 5 reference and review checklist"@en ; edu:dependsOnKnobit ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-564" ; rdfs:label "Explains dependency preservation"@en ; skos:prefLabel "Explains dependency preservation"@en ; skos:definition "After a split, every dependency should still be enforceable within one entity."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "dependency preservation"@en ; edu:expectedResult "After a split, every dependency should still be enforceable within one entity"@en ; edu:assessmentCriterion "Decides for sample decompositions which dependencies are preserved"@en ; edu:assessmentMethod "Written question with sample entities"@en ; dcterms:source "Normalisation theory and relational design (Codd, Fagin, Date), as used by the stage 5 reference and review checklist"@en ; edu:dependsOnKnobit ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-565" ; rdfs:label "Explains derived data and point-in-time snapshots"@en ; skos:prefLabel "Explains derived data and point-in-time snapshots"@en ; skos:definition "A derivable value can be computed and need not be stored; a snapshot keeps a value as it stood and is not derived."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "derived data and point-in-time snapshot"@en ; edu:expectedResult "A derivable value can be computed and need not be stored; a snapshot keeps a value as it stood and is not derived"@en ; edu:assessmentCriterion "Classifies sample attributes as derivable, snapshot or base data and says what each derivation reads"@en ; edu:assessmentMethod "Written question with sample entities"@en ; dcterms:source "Normalisation theory and relational design (Codd, Fagin, Date), as used by the stage 5 reference and review checklist"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-566" ; rdfs:label "Explains supertype and subtype constraints"@en ; skos:prefLabel "Explains supertype and subtype constraints"@en ; skos:definition "Disjoint or overlapping, total or partial subtyping, and what each allows."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "supertype and subtype constraints"@en ; edu:expectedResult "Disjoint or overlapping, total or partial subtyping, and what each allows"@en ; edu:assessmentCriterion "States the disjointness and completeness of sample subtypings from their business rules"@en ; edu:assessmentMethod "Written question with sample entities"@en ; dcterms:source "Normalisation theory and relational design (Codd, Fagin, Date), as used by the stage 5 reference and review checklist"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-567" ; rdfs:label "Explains relationship cardinality and optionality"@en ; skos:prefLabel "Explains relationship cardinality and optionality"@en ; skos:definition "Minimum and maximum participation of each end of a relationship, read in both directions."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "relationship cardinality and optionality"@en ; edu:expectedResult "Minimum and maximum participation of each end of a relationship, read in both directions"@en ; edu:assessmentCriterion "States the cardinality and optionality of sample relationships in both directions from their rules"@en ; edu:assessmentMethod "Written question with sample entities"@en ; dcterms:source "Normalisation theory and relational design (Codd, Fagin, Date), as used by the stage 5 reference and review checklist"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-568" ; rdfs:label "Explains natural keys, surrogate keys and key stability"@en ; skos:prefLabel "Explains natural keys, surrogate keys and key stability"@en ; skos:definition "What makes a key stable and meaningless, and why a natural key is kept as a unique identifier."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "natural key, surrogate key and key stability"@en ; edu:expectedResult "What makes a key stable and meaningless, and why a natural key is kept as a unique identifier"@en ; edu:assessmentCriterion "Classifies sample keys as stable or not and meaningful or not, and says which to keep as natural keys"@en ; edu:assessmentMethod "Written question with sample entities"@en ; dcterms:source "Normalisation theory and relational design (Codd, Fagin, Date), as used by the stage 5 reference and review checklist"@en ; edu:dependsOnKnobit ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-569" ; rdfs:label "Explains the connection, fan and chasm traps"@en ; skos:prefLabel "Explains the connection, fan and chasm traps"@en ; skos:definition "How a path of relationships can state a fact that was never recorded, lose a question, or drop instances."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "connection, fan and chasm traps"@en ; edu:expectedResult "How a path of relationships can state a fact that was never recorded, lose a question, or drop instances"@en ; edu:assessmentCriterion "Names the trap on sample paths of two relationships and what each lets a reader wrongly conclude"@en ; edu:assessmentMethod "Written question with sample entities"@en ; dcterms:source "Normalisation theory and relational design (Codd, Fagin, Date), as used by the stage 5 reference and review checklist"@en ; edu:dependsOnKnobit ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-570" ; rdfs:label "Explains an entity type as the realisation of one business concept"@en ; skos:prefLabel "Explains an entity type as the realisation of one business concept"@en ; skos:definition "An entity type realises one glossary concept; its instances differ by values, not by type."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "entity type and business concept"@en ; edu:expectedResult "An entity type realises one glossary concept; its instances differ by values, not by type"@en ; edu:assessmentCriterion "Decides for sample entity pairs whether they are one concept, two, or one split by a value"@en ; edu:assessmentMethod "Written question with sample entities"@en ; dcterms:source "Normalisation theory and relational design (Codd, Fagin, Date), as used by the stage 5 reference and review checklist"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-423" ; rdfs:label "Recognises a taxonomy node deleted while data still refers to it"@en ; skos:prefLabel "Recognises a taxonomy node deleted while data still refers to it"@en ; skos:altLabel "Deleted or reused node (taxonomy)"@en ; skos:definition "A node is deleted while data still refers to it, or its id or code is reused for a different concept."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "deleted node with referencing data"@en ; edu:expectedResult "The node and the data still classified under it"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Retired product code P-17 reused for a new product Acceptable: Old node kept with `status: retired` and `superseded_by`; new node gets a new id"@en ; edu:assessmentMethod "skill-tests task: Party taxonomy (data taxonomy skills); skill-tests task: Taxonomy from business term definitions (broader/narrower only)"@en ; dcterms:source "Review checklist 02-conceptual-taxonomies, row 19; z39.19: 11.3.1, 11.4.4"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-424" ; rdfs:label "Recognises a node code reused for a different concept"@en ; skos:prefLabel "Recognises a node code reused for a different concept"@en ; skos:altLabel "Deleted or reused node (taxonomy)"@en ; skos:definition "A node is deleted while data still refers to it, or its id or code is reused for a different concept."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "reused node code"@en ; edu:expectedResult "The code and its two concepts"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Retired product code P-17 reused for a new product Acceptable: Old node kept with `status: retired` and `superseded_by`; new node gets a new id"@en ; edu:assessmentMethod "skill-tests task: Party taxonomy (data taxonomy skills); skill-tests task: Taxonomy from business term definitions (broader/narrower only)"@en ; dcterms:source "Review checklist 02-conceptual-taxonomies, row 19; z39.19: 11.3.1, 11.4.4"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-629" ; rdfs:label "Recognises a sentinel value standing in for null"@en ; skos:prefLabel "Recognises a sentinel value standing in for null"@en ; skos:altLabel "Sentinel value in place of null, or null with a business meaning (physical model)"@en ; skos:definition "A real-looking value standing for \"unknown\" or \"not applicable\", or a null that means something specific and different in different tables. Sentinels pass every constraint and end up in totals and averages. A specific form of logical row 6 at the physical level."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "real-looking value meaning unknown or not applicable"@en ; edu:expectedResult "The sentinel and the null or status column replacing it"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `account_opening_date = '1900-01-01'` when unknown; `branch_id = -1`; open-ended validity as `NULL` in one table and `9999-12-31` in another Acceptable: `NULL` for unknown. Where a value is required, one project-wide convention recorded in config (open-ended `valid_to`), and a dimension's unknown member as a labelled row that every query sees, not a magic number in a measure"@en ; edu:assessmentMethod "skill-tests task: Loan application physical model on Snowflake (physical design anomaly skills)"@en ; dcterms:source "Review checklist 04-physical, row 19; Karwin, Fear of the Unknown; Codd 1979 §2.3"@en ; edu:dependsOnKnobit ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-630" ; rdfs:label "Recognises a null with a business meaning"@en ; skos:prefLabel "Recognises a null with a business meaning"@en ; skos:altLabel "Sentinel value in place of null, or null with a business meaning (physical model)"@en ; skos:definition "A real-looking value standing for \"unknown\" or \"not applicable\", or a null that means something specific and different in different tables. Sentinels pass every constraint and end up in totals and averages. A specific form of logical row 6 at the physical level."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "null meaning something specific"@en ; edu:expectedResult "The null, its meaning, and the explicit value or column stating it"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `account_opening_date = '1900-01-01'` when unknown; `branch_id = -1`; open-ended validity as `NULL` in one table and `9999-12-31` in another Acceptable: `NULL` for unknown. Where a value is required, one project-wide convention recorded in config (open-ended `valid_to`), and a dimension's unknown member as a labelled row that every query sees, not a magic number in a measure"@en ; edu:assessmentMethod "skill-tests task: Loan application physical model on Snowflake (physical design anomaly skills)"@en ; dcterms:source "Review checklist 04-physical, row 19; Karwin, Fear of the Unknown; Codd 1979 §2.3"@en ; edu:dependsOnKnobit ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-827" ; rdfs:label "Recognises an event timestamp stored without a time zone"@en ; skos:prefLabel "Recognises an event timestamp stored without a time zone"@en ; skos:altLabel "Point in time without a zone, business date with a clock (generated DDL)"@en ; skos:definition "Two mirror-image defects. An event timestamp with no offset is ambiguous twice a year and incomparable across a bank that books in more than one zone. A business date — value date, booking date, maturity date, due date — stored as a timestamp invites a time component nobody means and makes date equality quietly fail."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "event timestamp"@en ; edu:expectedResult "The column and the zone-aware type it needs"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `created_at TIMESTAMP` with no zone on `dim_account`, written by jobs in two regions. And `payment_value_date` as a `TIMESTAMP`, so `= DATE '2026-03-31'` matches none of the rows loaded at 23:30 Acceptable: `TIMESTAMP WITH TIME ZONE` for event times, or UTC with the convention stated in the column `comment` and nowhere else; `DATE` for `payment_value_date`, `loan_maturity_date` and `valid_from_date`/`valid_to_date`, as the sample model has them"@en ; edu:assessmentMethod "skill-tests task: Generated DDL review, Postgres and Snowflake (DDL review skills)"@en ; dcterms:source "Review checklist 05-ddl, row 18; ISO 8601; ISO 9075"@en ; edu:dependsOnKnobit ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-828" ; rdfs:label "Recognises a business date stored with a time of day"@en ; skos:prefLabel "Recognises a business date stored with a time of day"@en ; skos:altLabel "Point in time without a zone, business date with a clock (generated DDL)"@en ; skos:definition "Two mirror-image defects. An event timestamp with no offset is ambiguous twice a year and incomparable across a bank that books in more than one zone. A business date — value date, booking date, maturity date, due date — stored as a timestamp invites a time component nobody means and makes date equality quietly fail."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "value, booking or due date stored as a timestamp"@en ; edu:expectedResult "The column and the date type it needs"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `created_at TIMESTAMP` with no zone on `dim_account`, written by jobs in two regions. And `payment_value_date` as a `TIMESTAMP`, so `= DATE '2026-03-31'` matches none of the rows loaded at 23:30 Acceptable: `TIMESTAMP WITH TIME ZONE` for event times, or UTC with the convention stated in the column `comment` and nowhere else; `DATE` for `payment_value_date`, `loan_maturity_date` and `valid_from_date`/`valid_to_date`, as the sample model has them"@en ; edu:assessmentMethod "skill-tests task: Generated DDL review, Postgres and Snowflake (DDL review skills)"@en ; dcterms:source "Review checklist 05-ddl, row 18; ISO 8601; ISO 9075"@en ; edu:dependsOnKnobit ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-151" ; rdfs:label "Explains singular and unambiguous requirement statements"@en ; skos:prefLabel "Explains singular and unambiguous requirement statements"@en ; skos:definition "One testable claim per requirement, about a named subject, with one reading and no unasked exceptions (ISO/IEC/IEEE 29148)."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "singular and unambiguous requirement"@en ; edu:expectedResult "One testable claim per requirement, about a named subject, with one reading and no unasked exceptions (ISO/IEC/IEEE 29148)"@en ; edu:assessmentCriterion "Classifies sample statements as singular and unambiguous or not and names the defect"@en ; edu:assessmentMethod "Written question with sample data requirements"@en ; dcterms:source "Data-management practice used by the stage 1 reference and review checklist"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-152" ; rdfs:label "Distinguishes a business requirement from a design solution"@en ; skos:prefLabel "Distinguishes a business requirement from a design solution"@en ; skos:definition "A business requirement says what the business must know; a solution names a table, column, type or screen."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Distinguishes"@en ; edu:targetObject "business requirement and design solution"@en ; edu:expectedResult "A business requirement says what the business must know; a solution names a table, column, type or screen"@en ; edu:assessmentCriterion "Classifies sample statements as requirement or solution and restates each solution as its requirement"@en ; edu:assessmentMethod "Written question with sample data requirements"@en ; dcterms:source "Data-management practice used by the stage 1 reference and review checklist"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-153" ; rdfs:label "Explains the data requirement types of the register"@en ; skos:prefLabel "Explains the data requirement types of the register"@en ; skos:definition "The requirement types the register allows and the later stage each one lands in."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "data requirement types"@en ; edu:expectedResult "The requirement types the register allows and the later stage each one lands in"@en ; edu:assessmentCriterion "Types sample statements correctly"@en ; edu:assessmentMethod "Written question with sample data requirements"@en ; dcterms:source "Data-management practice used by the stage 1 reference and review checklist"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-154" ; rdfs:label "Explains requirement attributes and traceability"@en ; skos:prefLabel "Explains requirement attributes and traceability"@en ; skos:definition "What each attribute records and why a requirement without it cannot be managed."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "source, priority, status, rationale and trace of a requirement"@en ; edu:expectedResult "What each attribute records and why a requirement without it cannot be managed"@en ; edu:assessmentCriterion "Fills in and checks the attributes of sample requirements"@en ; edu:assessmentMethod "Written question with sample data requirements"@en ; dcterms:source "Data-management practice used by the stage 1 reference and review checklist"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-155" ; rdfs:label "Explains current value, history and point-in-time reproducibility"@en ; skos:prefLabel "Explains current value, history and point-in-time reproducibility"@en ; skos:definition "When the business needs only the current value, past values, or a past report reproduced exactly."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "temporal data need"@en ; edu:expectedResult "When the business needs only the current value, past values, or a past report reproduced exactly"@en ; edu:assessmentCriterion "Classifies sample needs by their temporal requirement and names the consequence for history design"@en ; edu:assessmentMethod "Written question with sample data requirements"@en ; dcterms:source "Data-management practice used by the stage 1 reference and review checklist"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-156" ; rdfs:label "Explains the identity of a business thing"@en ; skos:prefLabel "Explains the identity of a business thing"@en ; skos:definition "How a thing is told apart, who assigns its identifier, and whether it can change or be reused."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "identity of a business thing"@en ; edu:expectedResult "How a thing is told apart, who assigns its identifier, and whether it can change or be reused"@en ; edu:assessmentCriterion "States the identity rules a sample thing needs"@en ; edu:assessmentMethod "Written question with sample data requirements"@en ; dcterms:source "Data-management practice used by the stage 1 reference and review checklist"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-157" ; rdfs:label "Explains the non-functional data concerns"@en ; skos:prefLabel "Explains the non-functional data concerns"@en ; skos:definition "Volume and growth, retention and end of life, classification and access, source and ownership."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "volume, retention, sensitivity and lineage"@en ; edu:expectedResult "Volume and growth, retention and end of life, classification and access, source and ownership"@en ; edu:assessmentCriterion "Names the concerns a sample register leaves uncovered"@en ; edu:assessmentMethod "Written question with sample data requirements"@en ; dcterms:source "Data-management practice used by the stage 1 reference and review checklist"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-158" ; rdfs:label "Explains the scope, events and questions a data register must state"@en ; skos:prefLabel "Explains the scope, events and questions a data register must state"@en ; skos:definition "What the data is for, what happens to the things it describes, and which questions it must answer."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "scope, events and questions of a data register"@en ; edu:expectedResult "What the data is for, what happens to the things it describes, and which questions it must answer"@en ; edu:assessmentCriterion "Names the scope, events and questions missing from a sample register"@en ; edu:assessmentMethod "Written question with sample data requirements"@en ; dcterms:source "Data-management practice used by the stage 1 reference and review checklist"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-159" ; rdfs:label "Explains referential and logical ambiguity in natural-language statements"@en ; skos:prefLabel "Explains referential and logical ambiguity in natural-language statements"@en ; skos:definition "Pronouns with several referents and and-or clauses without precedence give a statement two readings."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "ambiguity in statements"@en ; edu:expectedResult "Pronouns with several referents and and-or clauses without precedence give a statement two readings"@en ; edu:assessmentCriterion "Finds and resolves the ambiguities in sample statements"@en ; edu:assessmentMethod "Written question with sample data requirements"@en ; dcterms:source "Data-management practice used by the stage 1 reference and review checklist"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-160" ; rdfs:label "Explains persistent identifiers"@en ; skos:prefLabel "Explains persistent identifiers"@en ; skos:definition "Identifiers are never reused or renumbered; an entry leaving use is retired with its identifier, not deleted."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "persistent identifier"@en ; edu:expectedResult "Identifiers are never reused or renumbered; an entry leaving use is retired with its identifier, not deleted"@en ; edu:assessmentCriterion "Decides for sample changes whether identity is preserved"@en ; edu:assessmentMethod "Written question with sample data requirements"@en ; dcterms:source "Data-management practice used by the stage 1 reference and review checklist"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-161" ; rdfs:label "Explains verifiable requirement statements"@en ; skos:prefLabel "Explains verifiable requirement statements"@en ; skos:definition "A requirement a test can pass or fail, with measures, units, thresholds and references stated."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "verifiable requirement"@en ; edu:expectedResult "A requirement a test can pass or fail, with measures, units, thresholds and references stated"@en ; edu:assessmentCriterion "Rewrites sample statements so a test could fail them"@en ; edu:assessmentMethod "Written question with sample data requirements"@en ; dcterms:source "Data-management practice used by the stage 1 reference and review checklist"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-162" ; rdfs:label "Explains consistency within a requirements register"@en ; skos:prefLabel "Explains consistency within a requirements register"@en ; skos:definition "No two requirements say the same thing or contradict each other."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "consistency of a register"@en ; edu:expectedResult "No two requirements say the same thing or contradict each other"@en ; edu:assessmentCriterion "Finds duplicates, paraphrases and conflicts in a sample register"@en ; edu:assessmentMethod "Written question with sample data requirements"@en ; dcterms:source "Data-management practice used by the stage 1 reference and review checklist"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-251" ; rdfs:label "Explains intensional definition by superordinate concept and delimiting characteristics"@en ; skos:prefLabel "Explains intensional definition by superordinate concept and delimiting characteristics"@en ; skos:definition "A definition naming the superordinate concept and the characteristics delimiting it from its siblings (ISO 704)."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "intensional definition"@en ; edu:expectedResult "A definition naming the superordinate concept and the characteristics delimiting it from its siblings (ISO 704)"@en ; edu:assessmentCriterion "Writes and checks sample definitions in this form"@en ; edu:assessmentMethod "Written question with sample business terms"@en ; dcterms:source "Shared-URI copy of metadata-management M-351 (Data-management practice used by the stage 2 reference and review checklist)"@en ; edu:dependsOnKnobit ; edu:dependsOnKnobit ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-253" ; rdfs:label "Explains generic and partitive concept relations"@en ; skos:prefLabel "Explains generic and partitive concept relations"@en ; skos:definition "Kind-of and part-of relations between concepts in a concept system."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "generic and partitive relation"@en ; edu:expectedResult "Kind-of and part-of relations between concepts in a concept system"@en ; edu:assessmentCriterion "Classifies sample concept pairs as generic, partitive or neither"@en ; edu:assessmentMethod "Written question with sample business terms"@en ; dcterms:source "Shared-URI copy of metadata-management M-353 (Data-management practice used by the stage 2 reference and review checklist)"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-351" ; rdfs:label "Explains SBVR fact types and rule statements"@en ; skos:prefLabel "Explains SBVR fact types and rule statements"@en ; skos:definition "Fact types relate glossary terms; rule statements constrain fact types."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "SBVR fact type and rule statement"@en ; edu:expectedResult "Fact types relate glossary terms; rule statements constrain fact types"@en ; edu:assessmentCriterion "Writes sample rules as a fact type and a rule statement"@en ; edu:assessmentMethod "Written question with sample data rules"@en ; dcterms:source "Shared-URI copy of data-quality Q-251 (Data-management practice used by the stage 3 reference and review checklist)"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-355" ; rdfs:label "Explains Witt's classification of business rules"@en ; skos:prefLabel "Explains Witt's classification of business rules"@en ; skos:definition "Data rules (constraints, derivations, data-update rules) versus activity and party rules."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "business rule classification"@en ; edu:expectedResult "Data rules (constraints, derivations, data-update rules) versus activity and party rules"@en ; edu:assessmentCriterion "Classifies sample rules and says which belong in the data model"@en ; edu:assessmentMethod "Written question with sample data rules"@en ; dcterms:source "Shared-URI copy of data-quality Q-255 (Data-management practice used by the stage 3 reference and review checklist)"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-356" ; rdfs:label "Explains rule enforcement mechanisms and platform enforcement"@en ; skos:prefLabel "Explains rule enforcement mechanisms and platform enforcement"@en ; skos:definition "Schema constraint, data quality check, application or ETL, and which platforms enforce declared constraints."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "rule enforcement mechanism"@en ; edu:expectedResult "Schema constraint, data quality check, application or ETL, and which platforms enforce declared constraints"@en ; edu:assessmentCriterion "Assigns sample rules a mechanism and says what each target platform actually enforces"@en ; edu:assessmentMethod "Written question with sample data rules"@en ; dcterms:source "Shared-URI copy of data-quality Q-256 (Data-management practice used by the stage 3 reference and review checklist)"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-451" ; rdfs:label "Explains hierarchical relations and the all-and-some test"@en ; skos:prefLabel "Explains hierarchical relations and the all-and-some test"@en ; skos:definition "Generic, instance and whole-part relations, and the test that a child is always a kind of its parent (ANSI/NISO Z39.19)."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "hierarchical relation and all-and-some test"@en ; edu:expectedResult "Generic, instance and whole-part relations, and the test that a child is always a kind of its parent (ANSI/NISO Z39.19)"@en ; edu:assessmentCriterion "Classifies sample links and applies the all-and-some test to them"@en ; edu:assessmentMethod "Written question with sample taxonomies"@en ; dcterms:source "Data-management practice used by the stage 4 reference and review checklist"@en ; edu:dependsOnKnobit ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-452" ; rdfs:label "Explains scope notes and history notes"@en ; skos:prefLabel "Explains scope notes and history notes"@en ; skos:definition "Notes fixing a node's boundary and recording changes of its meaning."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "scope note and history note"@en ; edu:expectedResult "Notes fixing a node's boundary and recording changes of its meaning"@en ; edu:assessmentCriterion "Writes scope and history notes for sample nodes"@en ; edu:assessmentMethod "Written question with sample taxonomies"@en ; dcterms:source "Data-management practice used by the stage 4 reference and review checklist"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-453" ; rdfs:label "Explains warrant for vocabulary terms"@en ; skos:prefLabel "Explains warrant for vocabulary terms"@en ; skos:definition "Literary, user and organisational warrant justifying a node."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "warrant"@en ; edu:expectedResult "Literary, user and organisational warrant justifying a node"@en ; edu:assessmentCriterion "States the warrant of sample nodes or finds its absence"@en ; edu:assessmentMethod "Written question with sample taxonomies"@en ; dcterms:source "Data-management practice used by the stage 4 reference and review checklist"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-454" ; rdfs:label "Explains label form conventions for vocabularies"@en ; skos:prefLabel "Explains label form conventions for vocabularies"@en ; skos:definition "Noun phrases, consistent number and form, no insider abbreviations or system names."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "label form"@en ; edu:expectedResult "Noun phrases, consistent number and form, no insider abbreviations or system names"@en ; edu:assessmentCriterion "Corrects the labels of a sample vocabulary"@en ; edu:assessmentMethod "Written question with sample taxonomies"@en ; dcterms:source "Data-management practice used by the stage 4 reference and review checklist"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-455" ; rdfs:label "Explains characteristics of division and node labels"@en ; skos:prefLabel "Explains characteristics of division and node labels"@en ; skos:definition "Siblings divided on one characteristic, named by a node label."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "characteristic of division"@en ; edu:expectedResult "Siblings divided on one characteristic, named by a node label"@en ; edu:assessmentCriterion "Groups sample siblings by characteristic and names the node labels"@en ; edu:assessmentMethod "Written question with sample taxonomies"@en ; dcterms:source "Data-management practice used by the stage 4 reference and review checklist"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-456" ; rdfs:label "Explains equivalence relations and preferred terms"@en ; skos:prefLabel "Explains equivalence relations and preferred terms"@en ; skos:definition "Synonyms and variants of one concept under one preferred term."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "equivalence relation"@en ; edu:expectedResult "Synonyms and variants of one concept under one preferred term"@en ; edu:assessmentCriterion "Groups sample terms by concept and picks the preferred term"@en ; edu:assessmentMethod "Written question with sample taxonomies"@en ; dcterms:source "Data-management practice used by the stage 4 reference and review checklist"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-457" ; rdfs:label "Explains associative relations"@en ; skos:prefLabel "Explains associative relations"@en ; skos:definition "Relations between concepts that are neither kind-of nor part-of."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "associative relation"@en ; edu:expectedResult "Relations between concepts that are neither kind-of nor part-of"@en ; edu:assessmentCriterion "Tells associative from hierarchical relations in sample pairs"@en ; edu:assessmentMethod "Written question with sample taxonomies"@en ; dcterms:source "Data-management practice used by the stage 4 reference and review checklist"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-458" ; rdfs:label "Explains reuse of external vocabularies"@en ; skos:prefLabel "Explains reuse of external vocabularies"@en ; skos:definition "Adopting an established classification with its authority, version and mapping."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "external vocabulary"@en ; edu:expectedResult "Adopting an established classification with its authority, version and mapping"@en ; edu:assessmentCriterion "Finds the external vocabulary a sample list duplicates and records its reuse"@en ; edu:assessmentMethod "Written question with sample taxonomies"@en ; dcterms:source "Data-management practice used by the stage 4 reference and review checklist"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-651" ; rdfs:label "Explains controlled denormalisation"@en ; skos:prefLabel "Explains controlled denormalisation"@en ; skos:definition "A copy or merge kept consistent by a stated mechanism and checked."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "controlled denormalisation"@en ; edu:expectedResult "A copy or merge kept consistent by a stated mechanism and checked"@en ; edu:assessmentCriterion "Decides for sample denormalisations what keeps them consistent"@en ; edu:assessmentMethod "Written question with sample physical tables"@en ; dcterms:source "Data-management practice used by the stage 6 reference and review checklist"@en ; edu:dependsOnKnobit ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-652" ; rdfs:label "Explains the implementation options for subtypes"@en ; skos:prefLabel "Explains the implementation options for subtypes"@en ; skos:definition "Roll up, roll down or one table per type, and the constraints each loses."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "subtype implementation"@en ; edu:expectedResult "Roll up, roll down or one table per type, and the constraints each loses"@en ; edu:assessmentCriterion "Chooses an implementation for sample subtypings and names the constraints to restore"@en ; edu:assessmentMethod "Written question with sample physical tables"@en ; dcterms:source "Data-management practice used by the stage 6 reference and review checklist"@en ; edu:dependsOnKnobit ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-653" ; rdfs:label "Explains referential integrity and referential actions"@en ; skos:prefLabel "Explains referential integrity and referential actions"@en ; skos:definition "Foreign keys, and what cascade, set-null and restrict do to children."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "referential integrity"@en ; edu:expectedResult "Foreign keys, and what cascade, set-null and restrict do to children"@en ; edu:assessmentCriterion "Chooses the referential action for sample relationships"@en ; edu:assessmentMethod "Written question with sample physical tables"@en ; dcterms:source "Data-management practice used by the stage 6 reference and review checklist"@en ; edu:dependsOnKnobit ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-654" ; rdfs:label "Explains exact and approximate numeric types"@en ; skos:prefLabel "Explains exact and approximate numeric types"@en ; skos:definition "Decimals hold exact values; binary floating point cannot hold 0.01."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "numeric type"@en ; edu:expectedResult "Decimals hold exact values; binary floating point cannot hold 0.01"@en ; edu:assessmentCriterion "Chooses the numeric type for sample quantities"@en ; edu:assessmentMethod "Written question with sample physical tables"@en ; dcterms:source "Data-management practice used by the stage 6 reference and review checklist"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-655" ; rdfs:label "Explains null semantics and three-valued logic"@en ; skos:prefLabel "Explains null semantics and three-valued logic"@en ; skos:definition "What a null means, and how predicates evaluate to UNKNOWN."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "null semantics"@en ; edu:expectedResult "What a null means, and how predicates evaluate to UNKNOWN"@en ; edu:assessmentCriterion "Predicts how sample predicates treat nulls"@en ; edu:assessmentMethod "Written question with sample physical tables"@en ; dcterms:source "Data-management practice used by the stage 6 reference and review checklist"@en ; edu:dependsOnKnobit ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-656" ; rdfs:label "Explains value sets held as reference data"@en ; skos:prefLabel "Explains value sets held as reference data"@en ; skos:definition "Changeable value sets live in reference tables, not in CHECK lists."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "changeable value set kept as reference data"@en ; edu:expectedResult "Changeable value sets live in reference tables, not in CHECK lists"@en ; edu:assessmentCriterion "Decides for sample value sets where they live"@en ; edu:assessmentMethod "Written question with sample physical tables"@en ; dcterms:source "Data-management practice used by the stage 6 reference and review checklist"@en ; edu:dependsOnKnobit ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-657" ; rdfs:label "Explains index design from access paths"@en ; skos:prefLabel "Explains index design from access paths"@en ; skos:definition "Indexes derived from foreign keys, natural keys and stated access paths."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "index design"@en ; edu:expectedResult "Indexes derived from foreign keys, natural keys and stated access paths"@en ; edu:assessmentCriterion "Derives an index set from sample access paths"@en ; edu:assessmentMethod "Written question with sample physical tables"@en ; dcterms:source "Data-management practice used by the stage 6 reference and review checklist"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-658" ; rdfs:label "Explains history strategies and validity-period conventions"@en ; skos:prefLabel "Explains history strategies and validity-period conventions"@en ; skos:definition "Effective dating, SCD type 2, history tables and bi-temporal designs, with half-open validity periods."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "history strategy"@en ; edu:expectedResult "Effective dating, SCD type 2, history tables and bi-temporal designs, with half-open validity periods"@en ; edu:assessmentCriterion "Chooses a history strategy for sample needs and checks sample periods for overlap and gaps"@en ; edu:assessmentMethod "Written question with sample physical tables"@en ; dcterms:source "Data-management practice used by the stage 6 reference and review checklist"@en ; edu:dependsOnKnobit ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-659" ; rdfs:label "Explains grain and additivity in dimensional models"@en ; skos:prefLabel "Explains grain and additivity in dimensional models"@en ; skos:definition "One row means one thing; measures are additive, semi-additive or non-additive."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "grain and additivity"@en ; edu:expectedResult "One row means one thing; measures are additive, semi-additive or non-additive"@en ; edu:assessmentCriterion "States the grain of sample fact tables and the additivity of their measures"@en ; edu:assessmentMethod "Written question with sample physical tables"@en ; dcterms:source "Data-management practice used by the stage 6 reference and review checklist"@en ; edu:dependsOnKnobit ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-660" ; rdfs:label "Explains vertical and horizontal partitioning of tables"@en ; skos:prefLabel "Explains vertical and horizontal partitioning of tables"@en ; skos:definition "Splitting a table by columns or rows, and what keeps the parts one entity."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "table partitioning"@en ; edu:expectedResult "Splitting a table by columns or rows, and what keeps the parts one entity"@en ; edu:assessmentCriterion "Decides for sample splits whether they stay lossless and constrained"@en ; edu:assessmentMethod "Written question with sample physical tables"@en ; dcterms:source "Data-management practice used by the stage 6 reference and review checklist"@en ; edu:dependsOnKnobit ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-661" ; rdfs:label "Explains consistency of content stored by reference"@en ; skos:prefLabel "Explains consistency of content stored by reference"@en ; skos:definition "Files outside the database are not covered by its transactions or backups."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "content stored by reference"@en ; edu:expectedResult "Files outside the database are not covered by its transactions or backups"@en ; edu:assessmentCriterion "Names the consistency risks of sample by-reference designs"@en ; edu:assessmentMethod "Written question with sample physical tables"@en ; dcterms:source "Data-management practice used by the stage 6 reference and review checklist"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-662" ; rdfs:label "Explains the absence of row order in relational tables"@en ; skos:prefLabel "Explains the absence of row order in relational tables"@en ; skos:definition "A table is a set: order carries no meaning unless held in a column."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "row order in a relational table"@en ; edu:expectedResult "A table is a set: order carries no meaning unless held in a column"@en ; edu:assessmentCriterion "Finds facts in sample designs read from row or key order"@en ; edu:assessmentMethod "Written question with sample physical tables"@en ; dcterms:source "Data-management practice used by the stage 6 reference and review checklist"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-851" ; rdfs:label "Explains generated artefacts and their single source of truth"@en ; skos:prefLabel "Explains generated artefacts and their single source of truth"@en ; skos:definition "Generated files are rebuilt from the model and never edited; every fix goes to the deliverable owning the decision."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "generated artefact"@en ; edu:expectedResult "Generated files are rebuilt from the model and never edited; every fix goes to the deliverable owning the decision"@en ; edu:assessmentCriterion "Routes sample fixes to the model, configuration, rule or deployment"@en ; edu:assessmentMethod "Written question with sample generated DDL"@en ; dcterms:source "Data-management practice used by the stage 8 reference and review checklist"@en ; edu:dependsOnKnobit ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-852" ; rdfs:label "Explains SQL dialect differences"@en ; skos:prefLabel "Explains SQL dialect differences"@en ; skos:definition "Types, identifier limits, reserved words, indexes and constraint enforcement differ by engine."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "SQL dialect difference"@en ; edu:expectedResult "Types, identifier limits, reserved words, indexes and constraint enforcement differ by engine"@en ; edu:assessmentCriterion "Predicts how sample DDL renders and behaves on each engine"@en ; edu:assessmentMethod "Written question with sample generated DDL"@en ; dcterms:source "Data-management practice used by the stage 8 reference and review checklist"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-853" ; rdfs:label "Explains currency minor units"@en ; skos:prefLabel "Explains currency minor units"@en ; skos:definition "ISO 4217 minor units range from 0 to 3, so one scale does not fit every currency."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "currency minor unit"@en ; edu:expectedResult "ISO 4217 minor units range from 0 to 3, so one scale does not fit every currency"@en ; edu:assessmentCriterion "States the scale sample currency columns need"@en ; edu:assessmentMethod "Written question with sample generated DDL"@en ; dcterms:source "Data-management practice used by the stage 8 reference and review checklist"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-854" ; rdfs:label "Explains time zones in timestamps and business dates"@en ; skos:prefLabel "Explains time zones in timestamps and business dates"@en ; skos:definition "Event timestamps need a zone; business dates have no time of day."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "time zone and business date"@en ; edu:expectedResult "Event timestamps need a zone; business dates have no time of day"@en ; edu:assessmentCriterion "Chooses the type for sample temporal columns"@en ; edu:assessmentMethod "Written question with sample generated DDL"@en ; dcterms:source "Data-management practice used by the stage 8 reference and review checklist"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-855" ; rdfs:label "Explains collation and case or accent sensitivity"@en ; skos:prefLabel "Explains collation and case or accent sensitivity"@en ; skos:definition "Collation decides which values compare equal, and so what a key means."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "collation"@en ; edu:expectedResult "Collation decides which values compare equal, and so what a key means"@en ; edu:assessmentCriterion "Chooses the collation for sample key columns"@en ; edu:assessmentMethod "Written question with sample generated DDL"@en ; dcterms:source "Data-management practice used by the stage 8 reference and review checklist"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-856" ; rdfs:label "Explains access design for classified data"@en ; skos:prefLabel "Explains access design for classified data"@en ; skos:definition "Grants, masking and row-level security derived from data classification."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "access design"@en ; edu:expectedResult "Grants, masking and row-level security derived from data classification"@en ; edu:assessmentCriterion "Designs access for sample classified columns"@en ; edu:assessmentMethod "Written question with sample generated DDL"@en ; dcterms:source "Data-management practice used by the stage 8 reference and review checklist"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-857" ; rdfs:label "Explains schema migration and rollback"@en ; skos:prefLabel "Explains schema migration and rollback"@en ; skos:definition "Changes to a populated database need migrations and backfills; dropping tables is not a rollback."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "schema migration"@en ; edu:expectedResult "Changes to a populated database need migrations and backfills; dropping tables is not a rollback"@en ; edu:assessmentCriterion "Plans the migration and rollback for sample changes"@en ; edu:assessmentMethod "Written question with sample generated DDL"@en ; dcterms:source "Data-management practice used by the stage 8 reference and review checklist"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-858" ; rdfs:label "Explains environment-independent deployment"@en ; skos:prefLabel "Explains environment-independent deployment"@en ; skos:definition "One reviewed artefact builds every environment from configuration."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "environment-independent deployment"@en ; edu:expectedResult "One reviewed artefact builds every environment from configuration"@en ; edu:assessmentCriterion "Finds environment-specific content in sample scripts"@en ; edu:assessmentMethod "Written question with sample generated DDL"@en ; dcterms:source "Data-management practice used by the stage 8 reference and review checklist"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-859" ; rdfs:label "Explains testing DDL by execution and detecting drift"@en ; skos:prefLabel "Explains testing DDL by execution and detecting drift"@en ; skos:definition "DDL is proven by running it, and the deployed catalogue compared with the model."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "DDL testing and drift detection"@en ; edu:expectedResult "DDL is proven by running it, and the deployed catalogue compared with the model"@en ; edu:assessmentCriterion "Designs the execution test and drift check for sample deployments"@en ; edu:assessmentMethod "Written question with sample generated DDL"@en ; dcterms:source "Data-management practice used by the stage 8 reference and review checklist"@en ; edu:dependsOnKnobit ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-135" ; rdfs:label "Retires a superseded register entry instead of deleting it"@en ; skos:prefLabel "Retires a superseded register entry instead of deleting it"@en ; skos:definition "Keeps a duplicate, paraphrased or reversed entry under its identifier, retired and pointing to its successor, so citations to it stay valid."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Retires"@en ; edu:targetObject "superseded requirement, rule or check"@en ; edu:expectedResult "The entry kept with status retired and superseded_by its successor"@en ; edu:assessmentCriterion "The entry is kept under its own identifier, marked retired, and points to its successor; nothing is deleted or renumbered"@en ; edu:assessmentMethod "skill-tests task: Loan application data requirements (data requirement capture skills)"@en ; dcterms:source "Graded on its own by the stage 1 skill-tests task; no review-checklist row names it"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-421" ; rdfs:label "Models a role as an association to the party playing it"@en ; skos:prefLabel "Models a role as an association to the party playing it"@en ; skos:definition "Replaces kind-of links that fail all-and-some for roles (customer, supplier) with the party-role pattern."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Models"@en ; edu:targetObject "role misplaced as a subclass"@en ; edu:expectedResult "Role classes linked to the party by association and grouped under a role superclass"@en ; edu:assessmentCriterion "Roles are not subclasses of the party; a role superclass holds the shared role attributes; cardinality lets a party hold several roles over time"@en ; edu:assessmentMethod "skill-tests task: Party taxonomy (data taxonomy skills); skill-tests task: Taxonomy from business term definitions (broader/narrower only)"@en ; dcterms:source "Graded on its own by the stage 4 skill-tests task; no review-checklist row names it"@en ; edu:appliesKnowledge ; edu:appliesKnowledge ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-422" ; rdfs:label "Derives the broader concept from the head of a definition"@en ; skos:prefLabel "Derives the broader concept from the head of a definition"@en ; skos:definition "Builds a taxonomy from definitions by reading each definition's superordinate concept."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Derives"@en ; edu:targetObject "broader concept of a defined term"@en ; edu:expectedResult "Kind-of links taken from the head of each definition, with the quoted basis"@en ; edu:assessmentCriterion "Each broader concept is the head of the definition, resolved through listed synonyms, never taken from the term's name or other terms it mentions"@en ; edu:assessmentMethod "skill-tests task: Party taxonomy (data taxonomy skills); skill-tests task: Taxonomy from business term definitions (broader/narrower only)"@en ; dcterms:source "Graded on its own by the stage 4 skill-tests task; no review-checklist row names it"@en ; edu:appliesKnowledge ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-641" ; rdfs:label "Routes a defect to the deliverable responsible for it"@en ; skos:prefLabel "Routes a defect to the deliverable responsible for it"@en ; skos:definition "Sends a defect back to where it was made, so the source of truth is corrected and the fix survives regeneration."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Routes"@en ; edu:targetObject "defect found downstream of its source"@en ; edu:expectedResult "A finding raised against the stage, model, configuration or rule owning the defect, not fixed in place"@en ; edu:assessmentCriterion "Every fix is routed to the deliverable owning it; nothing upstream is restructured downstream, and no generated file is edited by hand"@en ; edu:assessmentMethod "skill-tests task: Loan application physical model on Snowflake (physical design anomaly skills)"@en ; dcterms:source "Graded on its own by the stage 6 skill-tests task; no review-checklist row names it"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-901" ; rdfs:label "Explains what data models are and why organisations build them"@en ; skos:prefLabel "Explains what data models are and why organisations build them"@en ; skos:definition "A data model represents data as the organisation understands it or wants it; it formalises requirements, defines scope and retains knowledge, and serves as a common vocabulary."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "data model and its purpose"@en ; edu:expectedResult "A data model represents data as the organisation understands it or wants it; it formalises requirements, defines scope and retains knowledge, and serves as a common vocabulary"@en ; edu:assessmentCriterion "States the purpose, goals and business drivers of data modelling and tells them from distractors"@en ; edu:assessmentMethod "Multiple-choice question in the style of the CDMP Data Modeling and Design exam"@en ; dcterms:source "DAMA-DMBOK2 chapter 5, section 1.1-1.3.1"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-902" ; rdfs:label "Explains the types of modelled data"@en ; skos:prefLabel "Explains the types of modelled data"@en ; skos:definition "Category, resource, business event and detail transaction data, and how each appears in a model."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "type of modelled data"@en ; edu:expectedResult "Category, resource, business event and detail transaction data, and how each appears in a model"@en ; edu:assessmentCriterion "Classifies sample data as category, resource, business event or detail transaction data"@en ; edu:assessmentMethod "Multiple-choice question in the style of the CDMP Data Modeling and Design exam"@en ; dcterms:source "DAMA-DMBOK2 chapter 5, section 1.3.2"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-903" ; rdfs:label "Explains data modelling notations"@en ; skos:prefLabel "Explains data modelling notations"@en ; skos:definition "Information Engineering, Barker, IDEF1X, Chen, UML and fact-based notations, and how each shows entities, relationships, cardinality and keys."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "data modelling notation"@en ; edu:expectedResult "Information Engineering, Barker, IDEF1X, Chen, UML and fact-based notations, and how each shows entities, relationships, cardinality and keys"@en ; edu:assessmentCriterion "Reads the same sample model in two notations and names each symbol"@en ; edu:assessmentMethod "Multiple-choice question in the style of the CDMP Data Modeling and Design exam"@en ; dcterms:source "DAMA-DMBOK2 chapter 5, section 1.3.3, 1.3.4.1"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-904" ; rdfs:label "Explains identifying and non-identifying relationships"@en ; skos:prefLabel "Explains identifying and non-identifying relationships"@en ; skos:definition "Whether a child entity's key includes its parent's key, and dependent versus independent entities."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "identifying and non-identifying relationship"@en ; edu:expectedResult "Whether a child entity's key includes its parent's key, and dependent versus independent entities"@en ; edu:assessmentCriterion "Classifies sample relationships as identifying or non-identifying and gives the child's key"@en ; edu:assessmentMethod "Multiple-choice question in the style of the CDMP Data Modeling and Design exam"@en ; dcterms:source "DAMA-DMBOK2 chapter 5, section 1.3.3.3"@en ; edu:dependsOnKnobit ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-905" ; rdfs:label "Explains dimensional modelling"@en ; skos:prefLabel "Explains dimensional modelling"@en ; skos:definition "Fact and dimension tables, star and snowflake schemas, conformed dimensions and facts."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "dimensional model"@en ; edu:expectedResult "Fact and dimension tables, star and snowflake schemas, conformed dimensions and facts"@en ; edu:assessmentCriterion "Identifies the facts, dimensions and conformed dimensions of a sample star schema and says when to snowflake"@en ; edu:assessmentMethod "Multiple-choice question in the style of the CDMP Data Modeling and Design exam"@en ; dcterms:source "DAMA-DMBOK2 chapter 5, section 1.3.4.2"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-906" ; rdfs:label "Explains UML class diagrams as a data modelling scheme"@en ; skos:prefLabel "Explains UML class diagrams as a data modelling scheme"@en ; skos:definition "Classes, attributes, associations and generalisation as a data modelling scheme, and how they differ from entity-relationship models."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "UML class diagram"@en ; edu:expectedResult "Classes, attributes, associations and generalisation as a data modelling scheme, and how they differ from entity-relationship models"@en ; edu:assessmentCriterion "Translates a sample entity-relationship fragment into a class diagram and names what changes"@en ; edu:assessmentMethod "Multiple-choice question in the style of the CDMP Data Modeling and Design exam"@en ; dcterms:source "DAMA-DMBOK2 chapter 5, section 1.3.4.3"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-907" ; rdfs:label "Explains fact-based modelling"@en ; skos:prefLabel "Explains fact-based modelling"@en ; skos:definition "Modelling elementary facts and the roles objects play in them, from which entities and attributes are derived."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "fact-based modelling (ORM and FCO-IM)"@en ; edu:expectedResult "Modelling elementary facts and the roles objects play in them, from which entities and attributes are derived"@en ; edu:assessmentCriterion "Expresses sample business statements as elementary facts with their roles and constraints"@en ; edu:assessmentMethod "Multiple-choice question in the style of the CDMP Data Modeling and Design exam"@en ; dcterms:source "DAMA-DMBOK2 chapter 5, section 1.3.4.4"@en ; edu:dependsOnKnobit ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-908" ; rdfs:label "Explains time-based modelling schemes"@en ; skos:prefLabel "Explains time-based modelling schemes"@en ; skos:definition "Hubs, links and satellites; anchors, attributes, ties and knots; history kept by design."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "Data Vault and Anchor Modeling"@en ; edu:expectedResult "Hubs, links and satellites; anchors, attributes, ties and knots; history kept by design"@en ; edu:assessmentCriterion "Places the parts of a sample source model into hubs, links and satellites, and says what Anchor Modeling does differently"@en ; edu:assessmentMethod "Multiple-choice question in the style of the CDMP Data Modeling and Design exam"@en ; dcterms:source "DAMA-DMBOK2 chapter 5, section 1.3.4.5"@en ; edu:dependsOnKnobit ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-909" ; rdfs:label "Explains NoSQL data modelling schemes"@en ; skos:prefLabel "Explains NoSQL data modelling schemes"@en ; skos:definition "Document, column-family, graph and key-value stores, and modelling by aggregate and access path rather than by normalisation."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "NoSQL data model"@en ; edu:expectedResult "Document, column-family, graph and key-value stores, and modelling by aggregate and access path rather than by normalisation"@en ; edu:assessmentCriterion "Chooses a store type for sample access patterns and sketches the aggregate"@en ; edu:assessmentMethod "Multiple-choice question in the style of the CDMP Data Modeling and Design exam"@en ; dcterms:source "DAMA-DMBOK2 chapter 5, section 1.3.4.6"@en ; edu:dependsOnKnobit ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-910" ; rdfs:label "Explains canonical data models"@en ; skos:prefLabel "Explains canonical data models"@en ; skos:definition "A shared model of the data exchanged between systems, independent of each system's own model."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "canonical data model"@en ; edu:expectedResult "A shared model of the data exchanged between systems, independent of each system's own model"@en ; edu:assessmentCriterion "Says for sample integrations when a canonical model helps and what it contains"@en ; edu:assessmentMethod "Multiple-choice question in the style of the CDMP Data Modeling and Design exam"@en ; dcterms:source "DAMA-DMBOK2 chapter 5, section 1.3.5.4"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-911" ; rdfs:label "Explains views in physical design"@en ; skos:prefLabel "Explains views in physical design"@en ; skos:definition "Virtual tables that simplify queries, restrict access or present data without storing it again."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "database view"@en ; edu:expectedResult "Virtual tables that simplify queries, restrict access or present data without storing it again"@en ; edu:assessmentCriterion "Chooses where a view replaces a stored table or denormalisation in a sample design"@en ; edu:assessmentMethod "Multiple-choice question in the style of the CDMP Data Modeling and Design exam"@en ; dcterms:source "DAMA-DMBOK2 chapter 5, section 1.3.5.5, 2.2.1.3"@en ; edu:dependsOnKnobit ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-912" ; rdfs:label "Explains the planning of data modelling work"@en ; skos:prefLabel "Explains the planning of data modelling work"@en ; skos:definition "Scope, standards and schedule of modelling work, and its deliverables: diagram, definitions, issues and open questions, lineage."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "data modelling plan"@en ; edu:expectedResult "Scope, standards and schedule of modelling work, and its deliverables: diagram, definitions, issues and open questions, lineage"@en ; edu:assessmentCriterion "Lists the deliverables and decisions a sample modelling assignment needs"@en ; edu:assessmentMethod "Multiple-choice question in the style of the CDMP Data Modeling and Design exam"@en ; dcterms:source "DAMA-DMBOK2 chapter 5, section 2.1"@en ; edu:dependsOnKnobit ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-913" ; rdfs:label "Explains how to choose a modelling scheme and notation"@en ; skos:prefLabel "Explains how to choose a modelling scheme and notation"@en ; skos:definition "The scheme fits the data and its use; the notation fits the audience reading the model."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "choice of modelling scheme and notation"@en ; edu:expectedResult "The scheme fits the data and its use; the notation fits the audience reading the model"@en ; edu:assessmentCriterion "Chooses and justifies a scheme and notation for sample situations"@en ; edu:assessmentMethod "Multiple-choice question in the style of the CDMP Data Modeling and Design exam"@en ; dcterms:source "DAMA-DMBOK2 chapter 5, section 2.2.1.1"@en ; edu:dependsOnKnobit ; edu:dependsOnKnobit ; edu:dependsOnKnobit ; edu:dependsOnKnobit ; edu:dependsOnKnobit ; edu:dependsOnKnobit ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-914" ; rdfs:label "Explains forward and reverse engineering of data models"@en ; skos:prefLabel "Explains forward and reverse engineering of data models"@en ; skos:definition "Generating a database from a model, and recovering a model from an existing database with the judgement recovery needs."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "forward and reverse engineering"@en ; edu:expectedResult "Generating a database from a model, and recovering a model from an existing database with the judgement recovery needs"@en ; edu:assessmentCriterion "Lists what a reverse-engineered model of a sample database cannot recover by itself"@en ; edu:assessmentMethod "Multiple-choice question in the style of the CDMP Data Modeling and Design exam"@en ; dcterms:source "DAMA-DMBOK2 chapter 5, section 2.2.2, 3.1"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-915" ; rdfs:label "Explains data model review and the Data Model Scorecard"@en ; skos:prefLabel "Explains data model review and the Data Model Scorecard"@en ; skos:definition "Peer and stakeholder review against criteria, and the scorecard categories: correctness, completeness, scheme, structure, abstraction, standards, readability, definitions, consistency, data."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "data model review and scorecard"@en ; edu:expectedResult "Peer and stakeholder review against criteria, and the scorecard categories: correctness, completeness, scheme, structure, abstraction, standards, readability, definitions, consistency, data"@en ; edu:assessmentCriterion "Scores a sample model against the scorecard categories and justifies two of the scores"@en ; edu:assessmentMethod "Multiple-choice question in the style of the CDMP Data Modeling and Design exam"@en ; dcterms:source "DAMA-DMBOK2 chapter 5, section 2.3, 5.1.2, 5.2"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-916" ; rdfs:label "Explains data model versioning and change management"@en ; skos:prefLabel "Explains data model versioning and change management"@en ; skos:definition "Versions, change records, merging models from several sources, and keeping models current with their implementations."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "data model versioning"@en ; edu:expectedResult "Versions, change records, merging models from several sources, and keeping models current with their implementations"@en ; edu:assessmentCriterion "Plans the versioning and change record for a sample model change"@en ; edu:assessmentMethod "Multiple-choice question in the style of the CDMP Data Modeling and Design exam"@en ; dcterms:source "DAMA-DMBOK2 chapter 5, section 2.4, 5.1.3"@en ; edu:dependsOnKnobit ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-917" ; rdfs:label "Explains the tools supporting data modelling"@en ; skos:prefLabel "Explains the tools supporting data modelling"@en ; skos:definition "Modelling, lineage, data profiling and metadata repository tools, and what each contributes."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "data modelling tools"@en ; edu:expectedResult "Modelling, lineage, data profiling and metadata repository tools, and what each contributes"@en ; edu:assessmentCriterion "Matches sample modelling tasks to the tool type that supports them"@en ; edu:assessmentMethod "Multiple-choice question in the style of the CDMP Data Modeling and Design exam"@en ; dcterms:source "DAMA-DMBOK2 chapter 5, section 3.1-3.4"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-918" ; rdfs:label "Explains data model patterns and industry data models"@en ; skos:prefLabel "Explains data model patterns and industry data models"@en ; skos:definition "Reusable structures for recurring problems, and industry models as starting points adapted rather than adopted whole."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "data model pattern and industry model"@en ; edu:expectedResult "Reusable structures for recurring problems, and industry models as starting points adapted rather than adopted whole"@en ; edu:assessmentCriterion "Names the pattern a sample problem calls for and what to adapt in an industry model"@en ; edu:assessmentMethod "Multiple-choice question in the style of the CDMP Data Modeling and Design exam"@en ; dcterms:source "DAMA-DMBOK2 chapter 5, section 3.5, 3.6"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-919" ; rdfs:label "Explains naming conventions for data model objects"@en ; skos:prefLabel "Explains naming conventions for data model objects"@en ; skos:definition "Names built from object, property and representation terms with class words and an agreed abbreviation list (ISO/IEC 11179)."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "naming convention"@en ; edu:expectedResult "Names built from object, property and representation terms with class words and an agreed abbreviation list (ISO/IEC 11179)"@en ; edu:assessmentCriterion "Names the attributes of a sample entity by the convention and corrects non-conforming names"@en ; edu:assessmentMethod "Multiple-choice question in the style of the CDMP Data Modeling and Design exam"@en ; dcterms:source "DAMA-DMBOK2 chapter 5, section 4.1, 5.1.1"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-920" ; rdfs:label "Explains database design principles"@en ; skos:prefLabel "Explains database design principles"@en ; skos:definition "Designing for performance and ease of use, reusability, integrity, security and maintainability."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "database design principle"@en ; edu:expectedResult "Designing for performance and ease of use, reusability, integrity, security and maintainability"@en ; edu:assessmentCriterion "Evaluates a sample design against each principle"@en ; edu:assessmentMethod "Multiple-choice question in the style of the CDMP Data Modeling and Design exam"@en ; dcterms:source "DAMA-DMBOK2 chapter 5, section 4.2"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-921" ; rdfs:label "Explains data modelling and design standards"@en ; skos:prefLabel "Explains data modelling and design standards"@en ; skos:definition "What standards cover (naming, notation, definitions, deliverables, review criteria) and how they are kept."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "data modelling standard"@en ; edu:expectedResult "What standards cover (naming, notation, definitions, deliverables, review criteria) and how they are kept"@en ; edu:assessmentCriterion "Drafts the table of contents of a modelling standard and says who maintains it"@en ; edu:assessmentMethod "Multiple-choice question in the style of the CDMP Data Modeling and Design exam"@en ; dcterms:source "DAMA-DMBOK2 chapter 5, section 5.1.1"@en ; edu:dependsOnKnobit ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-001" ; rdfs:label "Recognises a modelling scope with no boundary"@en ; skos:prefLabel "Recognises a modelling scope with no boundary"@en ; skos:altLabel "Scope with no boundary"@en ; skos:definition "A scope listing what is in and nothing that is out."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "modelling scope listing only what is in"@en ; edu:expectedResult "The scope and what is out of it, with the owner of what is out"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `scope: \"payments\"` Acceptable: \"Payment, account, party; out: card authorisations (owned by AS-002)\""@en ; edu:assessmentMethod "Review of the seeded eval project (reffa/skills, data-modelling/evals/files/review-project/00-plan/modelling-plan.yaml); Not yet assessed: a skill-tests task for it is to be designed (SKLZ-121)"@en ; dcterms:source "Review checklist 00-planning-standards, row 1 (DMBOK §2.1)"@en ; edu:appliesKnowledge ; edu:followedBy ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-002" ; rdfs:label "Recognises a modelling standard named but not chosen"@en ; skos:prefLabel "Recognises a modelling standard named but not chosen"@en ; skos:altLabel "Standard named but not chosen"@en ; skos:definition "A convention left open, or the plan and `model-config.yaml` disagreeing."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "convention left open or contradicting the model configuration"@en ; edu:expectedResult "The open or contradicting convention and the one value to choose"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `naming: \"iso-11179 or snake-case (to be decided)\"` Acceptable: `naming: model-config.yaml#conventions.naming` = `iso-11179`"@en ; edu:assessmentMethod "Review of the seeded eval project (reffa/skills, data-modelling/evals/files/review-project/00-plan/modelling-plan.yaml); Not yet assessed: a skill-tests task for it is to be designed (SKLZ-121)"@en ; dcterms:source "Review checklist 00-planning-standards, row 2 (DMBOK §6; 11179-5)"@en ; edu:appliesKnowledge ; edu:appliesKnowledge ; edu:followedBy ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-003" ; rdfs:label "Recognises a model layer planned with no notation"@en ; skos:prefLabel "Recognises a model layer planned with no notation"@en ; skos:altLabel "Layer with no notation"@en ; skos:definition "A deliverable layer with no notation stated."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "deliverable layer without a stated notation"@en ; edu:expectedResult "The layer and a notation fitting its audience"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `notation: {conceptual: \"concept map\"}`; logical and physical missing Acceptable: IE for logical and physical"@en ; edu:assessmentMethod "Review of the seeded eval project (reffa/skills, data-modelling/evals/files/review-project/00-plan/modelling-plan.yaml); Not yet assessed: a skill-tests task for it is to be designed (SKLZ-121)"@en ; dcterms:source "Review checklist 00-planning-standards, row 3 (DMBOK §2.1; Hoberman)"@en ; edu:appliesKnowledge ; edu:appliesKnowledge ; edu:followedBy ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-004" ; rdfs:label "Recognises model inputs the plan does not locate"@en ; skos:prefLabel "Recognises model inputs the plan does not locate"@en ; skos:altLabel "Inputs not located"@en ; skos:definition "The plan does not say where the glossary and the rules live, or says something `model-config.yaml` `sources:` does not."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "glossary or rules the plan does not point to"@en ; edu:expectedResult "The input and where it lives, agreeing with the configured sources"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `inputs: {glossary: \"the team's glossary spreadsheet\", data_rules: null}` Acceptable: The metadata and data-quality projects, the same paths as `sources:`"@en ; edu:assessmentMethod "Review of the seeded eval project (reffa/skills, data-modelling/evals/files/review-project/00-plan/modelling-plan.yaml); Not yet assessed: a skill-tests task for it is to be designed (SKLZ-121)"@en ; dcterms:source "Review checklist 00-planning-standards, row 4 (DMBOK §2.1)"@en ; edu:appliesKnowledge ; edu:followedBy ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-005" ; rdfs:label "Recognises a model review planned by its modeller"@en ; skos:prefLabel "Recognises a model review planned by its modeller"@en ; skos:altLabel "Review by the modeller"@en ; skos:definition "The reviewer is the modeller, or no review is planned."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "plan naming the modeller as reviewer or no review"@en ; edu:expectedResult "An independent reviewer and the review at each release"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `roles: {modeller: \"Mart K.\", reviewer: \"Mart K.\"}` Acceptable: An independent reviewer; stage 6 at every release"@en ; edu:assessmentMethod "Review of the seeded eval project (reffa/skills, data-modelling/evals/files/review-project/00-plan/modelling-plan.yaml); Not yet assessed: a skill-tests task for it is to be designed (SKLZ-121)"@en ; dcterms:source "Review checklist 00-planning-standards, row 5 (DMBOK §6)"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-006" ; rdfs:label "Recognises a model with no repository or baseline"@en ; skos:prefLabel "Recognises a model with no repository or baseline"@en ; skos:altLabel "No repository or baseline"@en ; skos:definition "Nowhere the versions are kept and tagged."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "plan keeping no versions"@en ; edu:expectedResult "The repository and the tagging of baselines"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `tools: {repository: null}` Acceptable: `repository: \"git: reffa/models\", tags: model-`"@en ; edu:assessmentMethod "Review of the seeded eval project (reffa/skills, data-modelling/evals/files/review-project/00-plan/modelling-plan.yaml); Not yet assessed: a skill-tests task for it is to be designed (SKLZ-121)"@en ; dcterms:source "Review checklist 00-planning-standards, row 6 (DMBOK §6 (versioning))"@en ; edu:appliesKnowledge ; edu:appliesKnowledge ; edu:followedBy ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-1001" ; rdfs:label "Recognises an incomplete data model scorecard"@en ; skos:prefLabel "Recognises an incomplete data model scorecard"@en ; skos:altLabel "Scorecard incomplete"@en ; skos:definition "A category missing, or weights not totalling 100."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "scorecard missing a category or with weights not totalling 100"@en ; edu:expectedResult "The missing category and the weights restored to 100"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: Nine categories; \"How well does the metadata match the data?\" missing; weights total 90 Acceptable: All ten categories, weights 100"@en ; edu:assessmentMethod "Review of the seeded eval project (reffa/skills, data-modelling/evals/files/review-project/06-review/model-review.yaml); Not yet assessed: a skill-tests task for it is to be designed (SKLZ-121)"@en ; dcterms:source "Review checklist 06-model-review, row 1 (Scorecard)"@en ; edu:appliesKnowledge ; edu:followedBy ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-1002" ; rdfs:label "Recognises a scorecard score with no evidence"@en ; skos:prefLabel "Recognises a scorecard score with no evidence"@en ; skos:altLabel "Score with no evidence"@en ; skos:definition "A category scored with nothing to show why."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "category score nothing supports"@en ; edu:expectedResult "The evidence the score needs, or a lower score"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: \"How good are the definitions?\" 10/10, `evidence: null` Acceptable: \"28 of 31 definitions pass the 11179-4 checklist; LA-007 duplicates LA-006\""@en ; edu:assessmentMethod "Review of the seeded eval project (reffa/skills, data-modelling/evals/files/review-project/06-review/model-review.yaml); Not yet assessed: a skill-tests task for it is to be designed (SKLZ-121)"@en ; dcterms:source "Review checklist 06-model-review, row 2 (Scorecard; DMBOK §2.3)"@en ; edu:appliesKnowledge ; edu:followedBy ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-1003" ; rdfs:label "Recognises a model reviewed by its modeller"@en ; skos:prefLabel "Recognises a model reviewed by its modeller"@en ; skos:altLabel "Reviewed by the modeller"@en ; skos:definition "The reviewer named in the review is the modeller named in the plan."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "review whose reviewer is the plan's modeller"@en ; edu:expectedResult "An independent reviewer"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `reviewer: \"Mart K.\"`, plan `modeller: \"Mart K.\"` Acceptable: Reviewer from another team"@en ; edu:assessmentMethod "Review of the seeded eval project (reffa/skills, data-modelling/evals/files/review-project/06-review/model-review.yaml); Not yet assessed: a skill-tests task for it is to be designed (SKLZ-121)"@en ; dcterms:source "Review checklist 06-model-review, row 3 (DMBOK §6)"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-1004" ; rdfs:label "Recognises a review decision contradicting its total"@en ; skos:prefLabel "Recognises a review decision contradicting its total"@en ; skos:altLabel "Decision contradicts the total"@en ; skos:definition "Approved below the threshold."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "approval below the threshold"@en ; edu:expectedResult "Rejection, or the findings fixed and re-scored"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `total: 71`, `threshold: 80`, `decision: approved` Acceptable: `rejected`, or the findings fixed and re-scored"@en ; edu:assessmentMethod "Review of the seeded eval project (reffa/skills, data-modelling/evals/files/review-project/06-review/model-review.yaml); Not yet assessed: a skill-tests task for it is to be designed (SKLZ-121)"@en ; dcterms:source "Review checklist 06-model-review, row 4 (Scorecard; DMBOK §2.3)"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-1005" ; rdfs:label "Recognises a review finding with no owner or action"@en ; skos:prefLabel "Recognises a review finding with no owner or action"@en ; skos:altLabel "Finding with no owner or action"@en ; skos:definition "A finding nobody will act on."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "finding nobody is to act on"@en ; edu:expectedResult "The owner, the action and its due date"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: RV-002 `owner: null` Acceptable: Owner and action, due before release"@en ; edu:assessmentMethod "Review of the seeded eval project (reffa/skills, data-modelling/evals/files/review-project/06-review/model-review.yaml); Not yet assessed: a skill-tests task for it is to be designed (SKLZ-121)"@en ; dcterms:source "Review checklist 06-model-review, row 5 (DMBOK §6)"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-1006" ; rdfs:label "Recognises a scorecard score contradicting the validator"@en ; skos:prefLabel "Recognises a scorecard score contradicting the validator"@en ; skos:altLabel "Score contradicts the validator"@en ; skos:definition "Full marks where the validator reports errors in that category's subject."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "full marks where the validator reports errors in the category's subject"@en ; edu:expectedResult "The score lowered and the errors cited as evidence"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: \"How structurally sound?\" 15/15 while `validation/` reports duplicate attribute LA-006/LA-007 and a missing key Acceptable: 9/15, evidence citing the errors"@en ; edu:assessmentMethod "Review of the seeded eval project (reffa/skills, data-modelling/evals/files/review-project/06-review/model-review.yaml); Not yet assessed: a skill-tests task for it is to be designed (SKLZ-121)"@en ; dcterms:source "Review checklist 06-model-review, row 6 (DMBOK §2.3)"@en ; edu:appliesKnowledge ; edu:appliesKnowledge ; edu:followedBy ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-1007" ; rdfs:label "Recognises a review of a version other than the one released"@en ; skos:prefLabel "Recognises a review of a version other than the one released"@en ; skos:altLabel "Version under review not the one released"@en ; skos:definition "The reviewed version differs from the version in the change log being released."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "reviewed model version differing from the released one"@en ; edu:expectedResult "A review of the version being released"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `model_version: \"1.2.0\"`; change log releasing 1.3.0 Acceptable: Review of 1.3.0"@en ; edu:assessmentMethod "Review of the seeded eval project (reffa/skills, data-modelling/evals/files/review-project/06-review/model-review.yaml); Not yet assessed: a skill-tests task for it is to be designed (SKLZ-121)"@en ; dcterms:source "Review checklist 06-model-review, row 7 (DMBOK §6 (versioning))"@en ; edu:appliesKnowledge ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-1101" ; rdfs:label "Recognises an inferred structure presented as declared"@en ; skos:prefLabel "Recognises an inferred structure presented as declared"@en ; skos:altLabel "Inference presented as declared"@en ; skos:definition "An inferred key, relationship or code list with no evidence or confidence."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "inferred key, relationship or code list with no evidence or confidence"@en ; edu:expectedResult "The evidence, the confidence and the confirmation still needed"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: RE-001 \"account N:1 party\", `evidence: null`, `confidence: null` Acceptable: \"party_id matches party.id on 100% of 412,000 rows; no FK declared\", high, unconfirmed"@en ; edu:assessmentMethod "Review of the seeded eval project (reffa/skills, data-modelling/evals/files/review-project/reverse/reverse-engineering.yaml); Not yet assessed: a skill-tests task for it is to be designed (SKLZ-121)"@en ; dcterms:source "Review checklist reverse-engineering, row 1 (P&B; C&C)"@en ; edu:appliesKnowledge ; edu:followedBy ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-1102" ; rdfs:label "Recognises reverse-engineered objects not marked as-is"@en ; skos:prefLabel "Recognises reverse-engineered objects not marked as-is"@en ; skos:altLabel "As-is not marked as-is"@en ; skos:definition "Reverse-engineered objects without `status: as-is` and their source."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "recovered object with no as-is status or source"@en ; edu:expectedResult "The as-is status and the source system on every object"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `produced` lists PT-004 with no status Acceptable: `status: as-is`, `source: AS-001` on every object"@en ; edu:assessmentMethod "Review of the seeded eval project (reffa/skills, data-modelling/evals/files/review-project/reverse/reverse-engineering.yaml); Not yet assessed: a skill-tests task for it is to be designed (SKLZ-121)"@en ; dcterms:source "Review checklist reverse-engineering, row 2 (DMBOK §2.2.2)"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-1103" ; rdfs:label "Recognises a dead database object carried into the model"@en ; skos:prefLabel "Recognises a dead database object carried into the model"@en ; skos:altLabel "Dead object carried forward"@en ; skos:definition "An object with no rows or no reads lifted into the model."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "object with no rows or reads lifted into the model"@en ; edu:expectedResult "The object listed as dead and left out"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `tmp_payment_bak`, 0 rows, last write 2019, lifted to LE-006 Acceptable: Listed under dead objects, not lifted"@en ; edu:assessmentMethod "Review of the seeded eval project (reffa/skills, data-modelling/evals/files/review-project/reverse/reverse-engineering.yaml); Not yet assessed: a skill-tests task for it is to be designed (SKLZ-121)"@en ; dcterms:source "Review checklist reverse-engineering, row 3 (P&B)"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-1104" ; rdfs:label "Recognises a guessed meaning written as a definition"@en ; skos:prefLabel "Recognises a guessed meaning written as a definition"@en ; skos:altLabel "Guessed meaning written as a definition"@en ; skos:definition "A column nobody could explain given a definition anyway."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "column definition nobody could source"@en ; edu:expectedResult "The column under unknowns, with the data owner to ask"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `acct_flags.flag_7` defined \"fraud flag\"; no source Acceptable: In `unknowns`, asked of the Account data owner"@en ; edu:assessmentMethod "Review of the seeded eval project (reffa/skills, data-modelling/evals/files/review-project/reverse/reverse-engineering.yaml); Not yet assessed: a skill-tests task for it is to be designed (SKLZ-121)"@en ; dcterms:source "Review checklist reverse-engineering, row 4 (C&C (design recovery); DMBOK)"@en ; edu:appliesKnowledge ; edu:followedBy ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-1105" ; rdfs:label "Recognises a reverse-engineering source with no environment or date"@en ; skos:prefLabel "Recognises a reverse-engineering source with no environment or date"@en ; skos:altLabel "Source not dated"@en ; skos:definition "A catalogue read with no environment or date."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "catalogue read with no environment or date"@en ; edu:expectedResult "The environment and the date of the read"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: `sources: [{system: AS-001, catalogue: information_schema}]` Acceptable: \"production information_schema, 2026-10-30\""@en ; edu:assessmentMethod "Review of the seeded eval project (reffa/skills, data-modelling/evals/files/review-project/reverse/reverse-engineering.yaml); Not yet assessed: a skill-tests task for it is to be designed (SKLZ-121)"@en ; dcterms:source "Review checklist reverse-engineering, row 5 (DMBOK §2.2.2)"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-1106" ; rdfs:label "Recognises a physical workaround lifted into the logical model"@en ; skos:prefLabel "Recognises a physical workaround lifted into the logical model"@en ; skos:altLabel "Physical workaround lifted to logical"@en ; skos:definition "A copy, a report-specific index or a packed flag turned into a logical attribute."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "copy, reporting index or packed flag turned into a logical attribute"@en ; edu:expectedResult "The structure kept physical with its derivation and the business need in the logical model"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: LA-016 \"Payment Handler Workload Index For Reporting\" from PE-016 Acceptable: Stays physical with `derivation`; logical holds the business need"@en ; edu:assessmentMethod "Review of the seeded eval project (reffa/skills, data-modelling/evals/files/review-project/reverse/reverse-engineering.yaml); Not yet assessed: a skill-tests task for it is to be designed (SKLZ-121)"@en ; dcterms:source "Review checklist reverse-engineering, row 6 (P&B; DMBOK)"@en ; edu:appliesKnowledge ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-1201" ; rdfs:label "Recognises a model change with no reason"@en ; skos:prefLabel "Recognises a model change with no reason"@en ; skos:altLabel "Change with no reason"@en ; skos:definition "A change citing no requirement, issue or rule."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "change citing no requirement, issue or rule"@en ; edu:expectedResult "The requirement, issue or rule behind the change"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: MC-031 \"renamed payment_identifier\", `reason: null` Acceptable: `reason: DR-013`"@en ; edu:assessmentMethod "Review of the seeded eval project (reffa/skills, data-modelling/evals/files/review-project/maintenance/change-log.yaml); Not yet assessed: a skill-tests task for it is to be designed (SKLZ-121)"@en ; dcterms:source "Review checklist maintenance-versioning, row 1 (DMBOK §2.4)"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-1202" ; rdfs:label "Recognises a model change with no impact analysis"@en ; skos:prefLabel "Recognises a model change with no impact analysis"@en ; skos:altLabel "Change with no impact analysis"@en ; skos:definition "A change to an object others read, with nothing on who reads it."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "change to an object others read with no impact recorded"@en ; edu:expectedResult "The consumers affected, from lineage"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: MC-032 drops PE-016, `impact: null` Acceptable: `impact: [RP-03]` from metadata-management `--impact`"@en ; edu:assessmentMethod "Review of the seeded eval project (reffa/skills, data-modelling/evals/files/review-project/maintenance/change-log.yaml); Not yet assessed: a skill-tests task for it is to be designed (SKLZ-121)"@en ; dcterms:source "Review checklist maintenance-versioning, row 2 (DMBOK §2.4; ITIL)"@en ; edu:appliesKnowledge ; edu:followedBy ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-1203" ; rdfs:label "Recognises a breaking model change released as a minor version"@en ; skos:prefLabel "Recognises a breaking model change released as a minor version"@en ; skos:altLabel "Breaking change in a minor version"@en ; skos:definition "A removal, retype or change of meaning released as minor or patch."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "removal, retype or change of meaning in a minor or patch version"@en ; edu:expectedResult "A major version for the breaking change"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: MC-032 drops PE-016 in 1.3.0 (from 1.2.0) Acceptable: 2.0.0"@en ; edu:assessmentMethod "Review of the seeded eval project (reffa/skills, data-modelling/evals/files/review-project/maintenance/change-log.yaml); Not yet assessed: a skill-tests task for it is to be designed (SKLZ-121)"@en ; dcterms:source "Review checklist maintenance-versioning, row 3 (SemVer)"@en ; edu:appliesKnowledge ; edu:followedBy ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-1204" ; rdfs:label "Recognises a change to a deployed structure with no migration"@en ; skos:prefLabel "Recognises a change to a deployed structure with no migration"@en ; skos:altLabel "No migration for a deployed structure"@en ; skos:definition "A change to a deployed table with no migration and transition."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "deployed table changed with no migration or transition"@en ; edu:expectedResult "A migration with a transition period (expand and contract)"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: MC-032 `migration: null` Acceptable: Expand-contract: column kept read-only for one release, then dropped"@en ; edu:assessmentMethod "Review of the seeded eval project (reffa/skills, data-modelling/evals/files/review-project/maintenance/change-log.yaml); Not yet assessed: a skill-tests task for it is to be designed (SKLZ-121)"@en ; dcterms:source "Review checklist maintenance-versioning, row 4 (A&S)"@en ; edu:appliesKnowledge ; edu:followedBy ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-1205" ; rdfs:label "Recognises a released model version with no baseline"@en ; skos:prefLabel "Recognises a released model version with no baseline"@en ; skos:altLabel "Version with no baseline"@en ; skos:definition "A released version with no tag to rebuild it from."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "version with no tag to rebuild it from"@en ; edu:expectedResult "The baseline the version is rebuilt from"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: 1.3.0 `baseline: null` Acceptable: `baseline: \"git tag model-1.3.0\"`"@en ; edu:assessmentMethod "Review of the seeded eval project (reffa/skills, data-modelling/evals/files/review-project/maintenance/change-log.yaml); Not yet assessed: a skill-tests task for it is to be designed (SKLZ-121)"@en ; dcterms:source "Review checklist maintenance-versioning, row 5 (DMBOK §6)"@en ; edu:appliesKnowledge ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-1206" ; rdfs:label "Recognises a model change released without approval"@en ; skos:prefLabel "Recognises a model change released without approval"@en ; skos:altLabel "Change not approved"@en ; skos:definition "A change released with no approver."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Recognises"@en ; edu:targetObject "change with no approver"@en ; edu:expectedResult "The approver the plan names"@en ; edu:assessmentCriterion "Flags the deficient case and passes the acceptable one. Deficient: MC-033 `approved_by: null` Acceptable: The approver named in the plan"@en ; edu:assessmentMethod "Review of the seeded eval project (reffa/skills, data-modelling/evals/files/review-project/maintenance/change-log.yaml); Not yet assessed: a skill-tests task for it is to be designed (SKLZ-121)"@en ; dcterms:source "Review checklist maintenance-versioning, row 6 (ITIL; DMBOK §6)"@en ; edu:appliesKnowledge ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-031" ; rdfs:label "Plans the deliverables of a modelling assignment"@en ; skos:prefLabel "Plans the deliverables of a modelling assignment"@en ; skos:definition "A plan naming scope and boundary, the layers to deliver and their audiences, inputs, roles, review and schedule"@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Plans"@en ; edu:targetObject "modelling assignment"@en ; edu:expectedResult "A plan naming scope and boundary, the layers to deliver and their audiences, inputs, roles, review and schedule"@en ; edu:assessmentCriterion "Given a retail banking modelling request (a new savings product), the plan bounds the scope, names every deliverable layer with its audience, locates the glossary and rules, and plans an independent review"@en ; edu:assessmentMethod "Not yet assessed: a skill-tests task for it is to be designed (SKLZ-121)"@en ; dcterms:source "DAMA-DMBOK2 chapter 5, element(s) DM-24: a performance at CDMP Practitioner level"@en ; edu:appliesKnowledge ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-032" ; rdfs:label "Chooses a modelling scheme and notation for an audience and purpose"@en ; skos:prefLabel "Chooses a modelling scheme and notation for an audience and purpose"@en ; skos:definition "The scheme and notation chosen per layer, with the audience and purpose that decide it"@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Chooses"@en ; edu:targetObject "modelling scheme and notation for a deliverable"@en ; edu:expectedResult "The scheme and notation chosen per layer, with the audience and purpose that decide it"@en ; edu:assessmentCriterion "For a card-payments warehouse a dimensional scheme for the marts, IE for the logical and physical models and a concept map for business readers, each justified by its audience; not one notation for everything"@en ; edu:assessmentMethod "Not yet assessed: a skill-tests task for it is to be designed (SKLZ-121)"@en ; dcterms:source "DAMA-DMBOK2 chapter 5, element(s) DM-25: a performance at CDMP Practitioner level"@en ; edu:appliesKnowledge ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-033" ; rdfs:label "Sets the modelling standards a project follows"@en ; skos:prefLabel "Sets the modelling standards a project follows"@en ; skos:definition "Naming, abbreviation, definition and design rules chosen once and recorded in the model configuration"@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Sets"@en ; edu:targetObject "modelling standards of a project"@en ; edu:expectedResult "Naming, abbreviation, definition and design rules chosen once and recorded in the model configuration"@en ; edu:assessmentCriterion "The standards fix one naming convention and abbreviation list, a definition rule and the design principles the physical model must keep (keys, nullability, history), and the model configuration says the same"@en ; edu:assessmentMethod "Not yet assessed: a skill-tests task for it is to be designed (SKLZ-121)"@en ; dcterms:source "DAMA-DMBOK2 chapter 5, element(s) DM-39, DM-38: a performance at CDMP Practitioner level"@en ; edu:appliesKnowledge ; edu:appliesKnowledge ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-034" ; rdfs:label "Selects the tools and repository for a modelling project"@en ; skos:prefLabel "Selects the tools and repository for a modelling project"@en ; skos:definition "The modelling, generation and repository tools, with where versions and baselines are kept"@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Selects"@en ; edu:targetObject "modelling tools and repository"@en ; edu:expectedResult "The modelling, generation and repository tools, with where versions and baselines are kept"@en ; edu:assessmentCriterion "Tools cover modelling, DDL generation and lineage, and a repository with tagged baselines is named"@en ; edu:assessmentMethod "Not yet assessed: a skill-tests task for it is to be designed (SKLZ-121)"@en ; dcterms:source "DAMA-DMBOK2 chapter 5, element(s) DM-31, DM-34: a performance at CDMP Practitioner level"@en ; edu:appliesKnowledge ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-1031" ; rdfs:label "Scores a data model against the Data Model Scorecard"@en ; skos:prefLabel "Scores a data model against the Data Model Scorecard"@en ; skos:definition "A score per scorecard category with evidence, a total against the threshold and a decision that follows it"@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Scores"@en ; edu:targetObject "data model under review"@en ; edu:expectedResult "A score per scorecard category with evidence, a total against the threshold and a decision that follows it"@en ; edu:assessmentCriterion "Scores a retail payments logical model in all ten categories with evidence for each (definitions checked, validator errors cited), totals it, and approves or rejects by the agreed threshold"@en ; edu:assessmentMethod "Not yet assessed: a skill-tests task for it is to be designed (SKLZ-121)"@en ; dcterms:source "DAMA-DMBOK2 chapter 5, element(s) DM-29, DM-40, DM-42: a performance at CDMP Practitioner level"@en ; edu:appliesKnowledge ; edu:appliesKnowledge ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-1131" ; rdfs:label "Reverse-engineers a logical model from a database schema"@en ; skos:prefLabel "Reverse-engineers a logical model from a database schema"@en ; skos:definition "An as-is logical model with declared and inferred structures separated, dead objects and unknowns listed"@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Reverse-engineers"@en ; edu:targetObject "deployed database schema"@en ; edu:expectedResult "An as-is logical model with declared and inferred structures separated, dead objects and unknowns listed"@en ; edu:assessmentCriterion "From a core-banking account schema recovers entities, keys and relationships, marks each inferred one with its evidence and confidence, leaves dead tables out and asks the data owner about unexplained columns"@en ; edu:assessmentMethod "Not yet assessed: a skill-tests task for it is to be designed (SKLZ-121)"@en ; dcterms:source "DAMA-DMBOK2 chapter 5, element(s) DM-28: a performance at CDMP Practitioner level"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-1231" ; rdfs:label "Releases a model change as a new model version"@en ; skos:prefLabel "Releases a model change as a new model version"@en ; skos:definition "A change log entry with reason, impact, semantic version, migration, baseline and approval"@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Releases"@en ; edu:targetObject "model change"@en ; edu:expectedResult "A change log entry with reason, impact, semantic version, migration, baseline and approval"@en ; edu:assessmentCriterion "Dropping a deployed column read by a regulatory report is released as a major version with the report in its impact, an expand-and-contract migration, a tagged baseline and the approver the plan names"@en ; edu:assessmentMethod "Not yet assessed: a skill-tests task for it is to be designed (SKLZ-121)"@en ; dcterms:source "DAMA-DMBOK2 chapter 5, element(s) DM-30, DM-41: a performance at CDMP Practitioner level"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-671" ; rdfs:label "Designs a star schema for a stated grain"@en ; skos:prefLabel "Designs a star schema for a stated grain"@en ; skos:definition "A fact table at the stated grain with additive measures and conformed dimensions"@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Designs"@en ; edu:targetObject "business process and its grain"@en ; edu:expectedResult "A fact table at the stated grain with additive measures and conformed dimensions"@en ; edu:assessmentCriterion "For card transactions at one row per authorised transaction: the fact holds amount and fee at that grain, dimensions for date, card, merchant and account are conformed, and no measure is at a coarser grain"@en ; edu:assessmentMethod "Not yet assessed: a skill-tests task for it is to be designed (SKLZ-121)"@en ; dcterms:source "DAMA-DMBOK2 chapter 5, element(s) DM-10: a performance at CDMP Practitioner level"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-672" ; rdfs:label "Designs a Data Vault model for auditable history"@en ; skos:prefLabel "Designs a Data Vault model for auditable history"@en ; skos:definition "Hubs for business keys, links for relationships and satellites for changing descriptive data with load dates and sources"@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Designs"@en ; edu:targetObject "integration layer needing full history"@en ; edu:expectedResult "Hubs for business keys, links for relationships and satellites for changing descriptive data with load dates and sources"@en ; edu:assessmentCriterion "For customers and accounts from two source systems: hubs on the customer and account business keys, a link for holding, satellites per source with load date and record source; nothing overwritten"@en ; edu:assessmentMethod "Not yet assessed: a skill-tests task for it is to be designed (SKLZ-121)"@en ; dcterms:source "DAMA-DMBOK2 chapter 5, element(s) DM-13: a performance at CDMP Practitioner level"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-673" ; rdfs:label "Designs a document structure for a stated access pattern"@en ; skos:prefLabel "Designs a document structure for a stated access pattern"@en ; skos:definition "Documents shaped by the reads they serve, with the duplication and its update rule stated"@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Designs"@en ; edu:targetObject "NoSQL document store and its access pattern"@en ; edu:expectedResult "Documents shaped by the reads they serve, with the duplication and its update rule stated"@en ; edu:assessmentCriterion "For a mobile banking statement read by account and month: one document per account-month embedding its transactions, with the duplicated account name and how it is refreshed stated"@en ; edu:assessmentMethod "Not yet assessed: a skill-tests task for it is to be designed (SKLZ-121)"@en ; dcterms:source "DAMA-DMBOK2 chapter 5, element(s) DM-14: a performance at CDMP Practitioner level"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-674" ; rdfs:label "Designs views hiding physical structure from consumers"@en ; skos:prefLabel "Designs views hiding physical structure from consumers"@en ; skos:definition "Views giving consumers a stable business-shaped interface"@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Designs"@en ; edu:targetObject "physical model and its consumers"@en ; edu:expectedResult "Views giving consumers a stable business-shaped interface"@en ; edu:assessmentCriterion "A view presents current account balances with business names over the partitioned history tables, so that reports survive a change of partitioning"@en ; edu:assessmentMethod "Not yet assessed: a skill-tests task for it is to be designed (SKLZ-121)"@en ; dcterms:source "DAMA-DMBOK2 chapter 5, element(s) DM-19: a performance at CDMP Practitioner level"@en ; edu:appliesKnowledge ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-581" ; rdfs:label "Expresses a logical model as a UML class diagram"@en ; skos:prefLabel "Expresses a logical model as a UML class diagram"@en ; skos:definition "Classes, attributes, associations with multiplicities and generalisations equivalent to the model"@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Expresses"@en ; edu:targetObject "logical data model"@en ; edu:expectedResult "Classes, attributes, associations with multiplicities and generalisations equivalent to the model"@en ; edu:assessmentCriterion "The loan and collateral entities become classes with typed attributes, the many-to-many becomes an association class, and multiplicities match the relationship cardinalities"@en ; edu:assessmentMethod "Not yet assessed: a skill-tests task for it is to be designed (SKLZ-121)"@en ; dcterms:source "DAMA-DMBOK2 chapter 5, element(s) DM-11: a performance at CDMP Practitioner level"@en ; edu:appliesKnowledge ; edu:appliesKnowledge ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-582" ; rdfs:label "Models data as fact types in a fact-based scheme"@en ; skos:prefLabel "Models data as fact types in a fact-based scheme"@en ; skos:definition "Elementary fact types with roles, uniqueness and mandatory constraints"@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Models"@en ; edu:targetObject "business statements about data"@en ; edu:expectedResult "Elementary fact types with roles, uniqueness and mandatory constraints"@en ; edu:assessmentCriterion "From 'each account is held by at least one customer' and 'a customer may hold several accounts': the fact type customer holds account, with the uniqueness spanning both roles and the account role mandatory"@en ; edu:assessmentMethod "Not yet assessed: a skill-tests task for it is to be designed (SKLZ-121)"@en ; dcterms:source "DAMA-DMBOK2 chapter 5, element(s) DM-12: a performance at CDMP Practitioner level"@en ; edu:appliesKnowledge ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-583" ; rdfs:label "Maps an application model onto a canonical model"@en ; skos:prefLabel "Maps an application model onto a canonical model"@en ; skos:definition "Each application attribute mapped to a canonical attribute, with gaps and transformations stated"@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Maps"@en ; edu:targetObject "application data model"@en ; edu:expectedResult "Each application attribute mapped to a canonical attribute, with gaps and transformations stated"@en ; edu:assessmentCriterion "A card system's customer record mapped onto the bank's canonical party model: every field mapped or stated as a gap, code values translated, and nothing invented in the canonical model for one application"@en ; edu:assessmentMethod "Not yet assessed: a skill-tests task for it is to be designed (SKLZ-121)"@en ; dcterms:source "DAMA-DMBOK2 chapter 5, element(s) DM-18: a performance at CDMP Practitioner level"@en ; edu:appliesKnowledge ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-1801" ; rdfs:label "Explains the meaning of a measured quantity"@en ; skos:prefLabel "Explains the meaning of a measured quantity"@en ; skos:altLabel "Selgitab mõõtarvu tähendust"@en ; skos:definition "Explains that a number with its unit states how many units of measure a magnitude contains (3 m = three metres)."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "the meaning of a measured quantity (a number and a unit together state a magnitude)"@en ; edu:expectedResult "An explanation of the meaning of a measured quantity, with an example"@en ; edu:assessmentCriterion "Explains the meaning of a given measured quantity (number + unit) and tells the number from the unit"@en ; edu:assessmentMethod "Multiple-choice question"@en ; dcterms:source "Copy of k12 knobit K12-1044 of the Estonian national curriculum register matemaatika (product k12-curriculum, skills/knobits/k12/matemaatika.yaml), Põhikooli RÕK lisa 5, I kooliaste, Mõõtmine, õpitulemus 4; fingerprint translated from Estonian"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-1802" ; rdfs:label "Explains the concepts of a hypothesis and a counter-example"@en ; skos:prefLabel "Explains the concepts of a hypothesis and a counter-example"@en ; skos:altLabel "Selgitab hüpoteesi ja vastunäite mõistet"@en ; skos:definition "Explains that a hypothesis is a conjecture that needs checking and that one counter-example refutes a general statement, whereas examples do not prove it."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "hypothesis and counter-example"@en ; edu:expectedResult "An explanation of hypothesis and counter-example"@en ; edu:assessmentCriterion "Tells a hypothesis from a proven statement and states what a counter-example proves"@en ; edu:assessmentMethod "Multiple-choice question"@en ; dcterms:source "Copy of k12 knobit K12-82024 of the Estonian national curriculum register grok-matemaatika-eesmargid (product k12-curriculum, skills/knobits/k12/grok-matemaatika-eesmargid.yaml), GRÕK lisa 5, lai matemaatika, õpiväljund 4; fingerprint translated from Estonian"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-1803" ; rdfs:label "Explains how database tables and relationships are structured"@en ; skos:prefLabel "Explains how database tables and relationships are structured"@en ; skos:altLabel "Selgitab andmebaasi tabelite ja seoste ülesehitust"@en ; skos:definition "Explains the structure of a relational database; does not cover creating a database."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "the structure of a database (table, column, primary key, relationship)"@en ; edu:expectedResult "An explanation of the structure of a database, with an example"@en ; edu:assessmentCriterion "Explains the meaning of a table, a column, a primary key and a relationship, and draws a simple two-table schema"@en ; edu:assessmentMethod "Multiple-choice question"@en ; dcterms:source "Copy of k12 knobit K12-69062 of the Estonian national curriculum register grok-l9-informaatika-1 (product k12-curriculum, skills/knobits/k12/grok-l9-informaatika-1.yaml), GRÕK lisa 9, Informaatika, Tarkvaraarendus, LO-69021; fingerprint translated from Estonian"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-1804" ; rdfs:label "Explains a function as a dependency between two variables"@en ; skos:prefLabel "Explains a function as a dependency between two variables"@en ; skos:altLabel "Selgitab funktsiooni kui sõltuvust kahe muutuja vahel"@en ; skos:definition "Explains the dependency between two quantities, the argument and the value of the function, including a dependency given by a table, a formula or a graph."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "the function (dependency, argument, value of the function)"@en ; edu:expectedResult "An explanation of the concept of a function, with an example"@en ; edu:assessmentCriterion "Explains that each value of the argument corresponds to exactly one value of the function, and gives a real-life example"@en ; edu:assessmentMethod "Multiple-choice question"@en ; dcterms:source "Copy of k12 knobit K12-3075 of the Estonian national curriculum register matemaatika (product k12-curriculum, skills/knobits/k12/matemaatika.yaml), Põhikooli RÕK lisa 5, III kooliaste, Algebra, õpitulemus 8 (LO-3028); fingerprint translated from Estonian"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-1805" ; rdfs:label "Explains the rules for defining a concept"@en ; skos:prefLabel "Explains the rules for defining a concept"@en ; skos:altLabel "Selgitab mõiste defineerimise reegleid"@en ; skos:definition "Explains how a concept is delimited by a definition - the nearest superordinate concept and the distinguishing characteristic; does not cover writing a definition."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "the rules for defining a concept (nearest superordinate concept and distinguishing characteristic)"@en ; edu:expectedResult "An explanation of the rules of definition"@en ; edu:assessmentCriterion "Names the parts of a definition and two common errors (too broad, circular definition)"@en ; edu:assessmentMethod "Multiple-choice question"@en ; dcterms:source "Copy of k12 knobit K12-11128 of the Estonian national curriculum register pk-valikained (product k12-curriculum, skills/knobits/k12/pk-valikained.yaml), Põhikooli RÕK, Teadusliku mõtlemise alused, III kooliaste, õpiväljund 11053; fingerprint translated from Estonian"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-1806" ; rdfs:label "Explains the concepts of a proposition and its truth value"@en ; skos:prefLabel "Explains the concepts of a proposition and its truth value"@en ; skos:altLabel "Selgitab loogikalause ja tõeväärtuse mõistet"@en ; skos:definition "Explains what a proposition is and which truth values it has; does not cover logical operations."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Explains"@en ; edu:targetObject "a proposition and its truth value"@en ; edu:expectedResult "An explanation that a proposition is a statement that is either true or false, with an example and a counter-example"@en ; edu:assessmentCriterion "Tells a proposition from other sentences (a question, a command, an expression with an unknown)"@en ; edu:assessmentMethod "Multiple-choice question"@en ; dcterms:source "Copy of k12 knobit K12-8017 of the Estonian national curriculum register matemaatika (product k12-curriculum, skills/knobits/k12/matemaatika.yaml), GRÕK lisa 8, valikkursus „Loogika“, õppe-eesmärk 4; fingerprint translated from Estonian"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:Knobit ; dcterms:identifier "K-1807" ; rdfs:label "Names the notation of a UML class diagram"@en ; skos:prefLabel "Names the notation of a UML class diagram"@en ; skos:altLabel "Nimetab UML klassidiagrammi tähiseid"@en ; skos:definition "Names the meaning of the class diagram's symbols; does not cover interpreting a diagram."@en ; edu:knobitType ; edu:contextFunction ; edu:creationMethod ; edu:graphRelevance ; edu:graphRelevance ; edu:graphRelevance ; edu:actionVerb "Names"@en ; edu:targetObject "the notation of a UML class diagram (class, attribute, operation, association, multiplicity)"@en ; edu:expectedResult "A list of the meanings of the symbols"@en ; edu:assessmentCriterion "Matches at least five symbols with their correct meaning"@en ; edu:assessmentMethod "Multiple-choice question"@en ; dcterms:source "Copy of k12 knobit K12-80061 of the Estonian national curriculum register grok-l15-ainevaldkondade-ulesed-valikkursused-5 (product k12-curriculum, skills/knobits/k12/grok-l15-ainevaldkondade-ulesed-valikkursused-5.yaml), GRÕK lisa 15, valikkursus „Rakenduste loomise ja programmeerimise alused“, õpiväljund 80028 (rida 2639); fingerprint translated from Estonian"@en ; schema:creativeWorkStatus "accepted" ; schema:isPartOf ; edu:conformsToProfile . a edu:LearningOutcome ; dcterms:identifier "LO-1" ; rdfs:label "Captures atomic, sourced and testable data requirements"@en ; dcterms:description "Stage 1 (Requirements) of the data-modelling skill: Captures atomic, sourced and testable data requirements; produces 01-requirements/requirements.yaml."@en ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit . a edu:LearningOutcome ; dcterms:identifier "LO-4" ; rdfs:label "Builds a conceptual model and its taxonomies"@en ; dcterms:description "Stage 2 (Conceptual model and taxonomies) of the data-modelling skill: Builds a conceptual model and its taxonomies; produces 02-conceptual/conceptual-model.yaml."@en ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit . a edu:LearningOutcome ; dcterms:identifier "LO-5" ; rdfs:label "Derives a normalised logical data model and traces anomalies to their causes"@en ; dcterms:description "Stage 3 (Logical model) of the data-modelling skill: Derives a normalised logical data model and traces anomalies to their causes; produces 03-logical/logical-model.yaml."@en ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit . a edu:LearningOutcome ; dcterms:identifier "LO-6" ; rdfs:label "Designs a physical data model for the target platform without introducing anomalies"@en ; dcterms:description "Stage 4 (Physical model) of the data-modelling skill: Designs a physical data model for the target platform without introducing anomalies; produces 04-physical/physical-model.yaml."@en ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit . a edu:LearningOutcome ; dcterms:identifier "LO-8" ; rdfs:label "Generates DDL per target dialect and reviews it against model, engine, data and deployment"@en ; dcterms:description "Stage 5 (DDL) of the data-modelling skill: Generates DDL per target dialect and reviews it against model, engine, data and deployment; produces 05-ddl//."@en ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit . a edu:LearningOutcome ; dcterms:identifier "LO-9" ; rdfs:label "Plans a modelling assignment with a bounded scope, chosen standards and notations, located inputs and an independent review"@en ; dcterms:description "Planning and modelling standards (standalone activity) of the data-modelling skill: Plans a modelling assignment with a bounded scope, chosen standards and notations, located inputs and an independent review; produces 00-plan/modelling-plan.yaml."@en ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit . a edu:LearningOutcome ; dcterms:identifier "LO-10" ; rdfs:label "Reviews a data model against the Data Model Scorecard, with evidence, an independent reviewer and a decision that follows the score"@en ; dcterms:description "Stage 6 (Model review) of the data-modelling skill: Reviews a data model against the Data Model Scorecard, with evidence, an independent reviewer and a decision that follows the score; produces 06-review/model-review.yaml."@en ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit . a edu:LearningOutcome ; dcterms:identifier "LO-11" ; rdfs:label "Reverse-engineers an as-is model from a database, separating what is declared from what is inferred"@en ; dcterms:description "Reverse engineering (standalone activity) of the data-modelling skill: Reverse-engineers an as-is model from a database, separating what is declared from what is inferred; produces reverse/reverse-engineering.yaml."@en ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit . a edu:LearningOutcome ; dcterms:identifier "LO-12" ; rdfs:label "Releases model changes with reasons, impact, semantic versions, migrations, baselines and approval"@en ; dcterms:description "Maintenance and versioning (standalone activity) of the data-modelling skill: Releases model changes with reasons, impact, semantic versions, migrations, baselines and approval; produces maintenance/change-log.yaml."@en ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit . a edu:Question ; dcterms:identifier "I-501" ; rdfs:label "logical-model C1: insertion anomaly traced to the collateral repeating group"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit , , ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-502" ; rdfs:label "logical-model C1: update anomaly traced to the branch transitive dependency"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit , , ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-503" ; rdfs:label "logical-model C1: deletion anomaly traced to the snapshot held nowhere else"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit , ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-504" ; rdfs:label "logical-model C2: many-to-many resolved into an associative entity"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-505" ; rdfs:label "logical-model C3a: assessment snapshots kept and marked, not removed"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-506" ; rdfs:label "logical-model I1a: collateral repeating group becomes its own entity"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit , ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-507" ; rdfs:label "logical-model I1b: CUSTOMER.address split"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-508" ; rdfs:label "logical-model I2a: branch attributes moved to a Branch entity"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit , ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-509" ; rdfs:label "logical-model I2b: functional dependencies written down"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-510" ; rdfs:label "logical-model I3: stored derivable attributes removed or given a derivation"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-511" ; rdfs:label "logical-model I4a: employed and self-employed subtypes"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit , ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-512" ; rdfs:label "logical-model I4b: subtype constraints declared"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-513" ; rdfs:label "logical-model I5: unstable meaningful key replaced, natural key kept"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-514" ; rdfs:label "logical-model Q1: no relationship contradicts a rule"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-515" ; rdfs:label "logical-model C4: many-to-many not left unresolved"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-516" ; rdfs:label "logical-model Q3: redundant relationship removed"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-101" ; rdfs:label "data-requirements C1a: identity gap named"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-102" ; rdfs:label "data-requirements C1b: access gap named"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-103" ; rdfs:label "data-requirements C1c: lineage gap named"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-104" ; rdfs:label "data-requirements C1d: history gap named"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-105" ; rdfs:label "data-requirements C1e: no question the data serves named"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-106" ; rdfs:label "data-requirements C1f: volume and retention gap named"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-107" ; rdfs:label "data-requirements C2a: duplicate retired, not deleted"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit , ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-108" ; rdfs:label "data-requirements C2b: paraphrase retired or recorded as a second source"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit , ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-109" ; rdfs:label "data-requirements C2c: retention against erasure kept with a reconciling condition"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-110" ; rdfs:label "data-requirements C3a: unsupplied value lists raised, not invented"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-111" ; rdfs:label "data-requirements C3b: gross or net raised and the requirement not confirmed"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit , ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-112" ; rdfs:label "data-requirements I1a: two-claim requirement split"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-113" ; rdfs:label "data-requirements I1b: misfiled currency rule moved"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-114" ; rdfs:label "data-requirements I2: candidate rules captured as data-rule requirements"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-115" ; rdfs:label "data-requirements I3: out-of-scope statements reclassified"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-116" ; rdfs:label "data-requirements I4a: absolute about collateral challenged"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-117" ; rdfs:label "data-requirements I4b: when date of birth is mandatory resolved"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-118" ; rdfs:label "data-requirements I5a: 'it' resolved"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-119" ; rdfs:label "data-requirements I5b: which date and whose named"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-120" ; rdfs:label "data-requirements I5c: 'accurate' made testable"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-121" ; rdfs:label "data-requirements I5d: 'up to date where possible' bounded"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-122" ; rdfs:label "data-requirements Q4: priorities, status and legacy statement sound"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit , , ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-123" ; rdfs:label "data-requirements Q2: identifiers permanent"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit , ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-124" ; rdfs:label "data-requirements Q1: requirement types sound"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-401" ; rdfs:label "party-taxonomy C1: person and organisation as kinds of party"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-402" ; rdfs:label "party-taxonomy C2 and C3: customer and supplier as roles"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit , ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-403" ; rdfs:label "party-taxonomy I2: generalisation constraints and role cardinality"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit , ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-404" ; rdfs:label "party-taxonomy Q1: no gratuitous derived classes"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-405" ; rdfs:label "taxonomy-from-definitions C1 and C3: broader concept from the definition head"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-406" ; rdfs:label "taxonomy-from-definitions C2: synonyms resolved"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit , ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-407" ; rdfs:label "taxonomy-from-definitions C4: justified polyhierarchy"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-408" ; rdfs:label "taxonomy-from-definitions C5: part-of kept out of the hierarchy"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-409" ; rdfs:label "taxonomy-from-definitions C6: roots with their missing broader concepts"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit , ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-410" ; rdfs:label "taxonomy-from-definitions C7: no extra kind-of links"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-601" ; rdfs:label "physical-model C1: deliberate snapshot kept, not reported as a duplicate"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-602" ; rdfs:label "physical-model C2: logical defect routed upstream, not fixed here"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit , ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-603" ; rdfs:label "physical-model C3: mixed grain found and resolved"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-604" ; rdfs:label "physical-model I1: unenforced constraints kept and checked"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-605" ; rdfs:label "physical-model I2a: surrogate key without natural-key uniqueness"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-606" ; rdfs:label "physical-model I2b: versioned dimension referenced by business key"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-607" ; rdfs:label "physical-model I3: rolled-up subtypes given a discriminator and a check"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-608" ; rdfs:label "physical-model I4a: FLOAT for money"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-609" ; rdfs:label "physical-model I4b: sentinel date replaced"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-610" ; rdfs:label "physical-model I5a: copied branch name"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-611" ; rdfs:label "physical-model I5b: stored sum without derivation"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-612" ; rdfs:label "physical-model Q1a: validity periods consistently bounded"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-613" ; rdfs:label "physical-model Q1b: one current version per customer"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-801" ; rdfs:label "ddl-review C1a and Q1b: fixes routed upstream, no hand edits"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit , ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-802" ; rdfs:label "ddl-review C1b and C1c: objects in the SQL and not in the model"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-803" ; rdfs:label "ddl-review C2a and C2b: unenforced keys on Snowflake, enforced on Postgres"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-804" ; rdfs:label "ddl-review C2c: CREATE INDEX on Snowflake"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-805" ; rdfs:label "ddl-review C3a: binary floating point for money"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-806" ; rdfs:label "ddl-review C3b: one scale for every currency"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-807" ; rdfs:label "ddl-review I1a: constraint rule absent from the SQL"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-808" ; rdfs:label "ddl-review I1b: configured dialect unrendered"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-809" ; rdfs:label "ddl-review I2a: truncated identifier"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-810" ; rdfs:label "ddl-review I2b: CHECK ignored on MySQL 5.7"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-811" ; rdfs:label "ddl-review I3a: IBAN length from the sample"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-812" ; rdfs:label "ddl-review I3b: value date as a timestamp"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-813" ; rdfs:label "ddl-review I4a: DEFAULT 0 on a settled amount"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-814" ; rdfs:label "ddl-review I4b: restricted column without access design"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-815" ; rdfs:label "ddl-review I5a: greenfield DDL against a populated table"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-816" ; rdfs:label "ddl-review I5b: drop script as rollback"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-817" ; rdfs:label "ddl-review Q1a: schema name baked in"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1001" ; rdfs:label "dm-knowledge-requirements Q1: singular and unambiguous data requirement statements"@en ; schema:text "In ISO/IEC/IEEE 29148 terms, what do the qualities 'singular' and 'unambiguous' require of a data requirement statement in a retail bank's requirements register? (a) It is one sentence long, and it uses only words already defined in the glossary; (b) It names one target table, and each value it mentions has an agreed datatype; (c) It comes from one stakeholder, and that stakeholder has confirmed its exact wording; (d) It makes one testable claim, and every reader takes it to mean the same single thing"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1002" ; rdfs:label "dm-knowledge-requirements Q2: business requirement versus design solution"@en ; schema:text "A product owner asks: 'Add a column OVERDRAFT_FLAG CHAR(1) to the ACCOUNT table.' Which restatement records this as a business data requirement rather than a design solution? (a) The overdraft flag must be stored as a one-character code on every account row.; (b) The account maintenance screen must show an overdraft field for each account.; (c) The ACCOUNT table must hold an overdraft indicator taking the values Y and N.; (d) The bank must know, for each current account, whether an arranged overdraft is in place."@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1003" ; rdfs:label "dm-knowledge-requirements Q3: requirement type of a load timeliness expectation"@en ; schema:text "A stakeholder states: 'The card transaction feed is loaded within one working day of the source extract, for at least 99% of rows.' Which requirement type does it take in the register, and where is it picked up later? (a) lineage; it is recorded as the source and arrival frequency of the card transaction data; (b) data-quality; it becomes a timeliness check at data-quality stage 3 citing the requirement; (c) data-rule; it is formalised as an SBVR fact type and rule statement at data-quality stage 2; (d) volume; it is used to size the card transaction table and its growth in the physical model"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1004" ; rdfs:label "dm-knowledge-requirements Q4: purpose of requirement attributes and trace"@en ; schema:text "Which pairing of a requirement attribute in a data requirements register with its purpose is correct? (a) Status: records how important the requirement is, so delivery can be ordered under pressure; (b) Trace: links the requirement to the terms and columns that realise it, so an unbuilt need shows; (c) Priority: records whether the steward has signed off, so the requirement may be built; (d) Rationale: names the stakeholder who supplied the requirement, so questions reach the right person"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1005" ; rdfs:label "dm-knowledge-requirements Q5: point-in-time reproducibility of a published report"@en ; schema:text "A bank must be able to re-run last quarter's regulatory arrears report on its loan book and obtain exactly the figures it submitted, even after loan data has since been corrected with back-dated changes. Which temporal need does this express? (a) An audit trail only, which last-updated timestamp and user columns on each loan provide; (b) Past values only, which valid-from and valid-to dates on each loan version fully satisfy; (c) Reproducing a past report exactly, which needs values both as they were valid and as they were recorded; (d) Current values only, since the report can be recomputed from today's corrected loan data"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1006" ; rdfs:label "dm-knowledge-requirements Q6: identity of a business thing such as a debit card"@en ; schema:text "When capturing data requirements for debit cards, which set of questions establishes how the business identifies a card? (a) When the card was issued, when it expires, and which statuses it passes through in its life; (b) Which system generates the card table's key, and what datatype and length the key column has; (c) How one card is told from another, who assigns that identifier, and whether it can change or be reused; (d) Which customer holds the card, which account it draws on, and which branch issued it"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1007" ; rdfs:label "dm-knowledge-requirements Q7: retention among the non-functional data concerns"@en ; schema:text "Which of these statements is a retention requirement, as distinct from a volume, sensitivity or lineage requirement? (a) Savings account records are expected to grow from two to three million within three years.; (b) Closed savings account records are kept for eight years after closure and then anonymised.; (c) Savings account balances are confidential and visible only to holders and servicing staff.; (d) Savings account data arrives daily from the core banking system, owned by the deposits unit."@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1008" ; rdfs:label "dm-knowledge-requirements Q8: questions a data requirements register must serve"@en ; schema:text "Why does good practice ask a loan requirements register to state the questions the data must answer, such as 'As of a given date, how many loans were more than 90 days in arrears?' (a) A stated question fixes the report layout, so the physical tables can be designed around it early; (b) A stated question forces out grain, measures and temporality, and shows which requirements are unneeded; (c) A stated question replaces the need to record the events that happen to loans during their life; (d) A stated question sets the scope boundary, so overlapping systems need not be listed separately"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1009" ; rdfs:label "dm-knowledge-requirements Q9: and-or ambiguity in a requirement statement"@en ; schema:text "A requirement reads: 'A standing order is cancelled when the account is closed or the customer requests cancellation and no payment is pending.' Why does it have more than one reading? (a) The statement does not say who is notified when the standing order is cancelled by the bank; (b) The statement makes two claims, the cancellation and the check that no payment is pending; (c) The and-or clause has no stated grouping, so 'no payment is pending' may qualify one or both conditions; (d) 'Standing order' is a business term, and any business term is ambiguous until it is defined"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1010" ; rdfs:label "dm-knowledge-requirements Q10: persistent identifier of a superseded requirement"@en ; schema:text "Requirement DR-014, cited in a signed-off loan origination specification, has been superseded by DR-031. What does the principle of persistent identifiers require for DR-014? (a) It is overwritten with the text of DR-031, and both identifiers then share that text; (b) It is deleted, and its identifier is freed so the next captured requirement can use it; (c) It stays in the register under its identifier, marked retired, and points to DR-031; (d) It is deleted, and DR-031 is renumbered DR-014 so that existing citations still resolve"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1011" ; rdfs:label "dm-knowledge-requirements Q11: what makes a data quality requirement verifiable"@en ; schema:text "A requirement reads: 'Customer postal addresses must be accurate.' What must be added to make it verifiable, so that a test could pass or fail it? (a) A named enforcement mechanism, such as a CHECK constraint on the postcode column of the address table; (b) A measure, a reference to compare against and a threshold, such as a 98% match to the national address register; (c) A named owner, a priority and a document locator for the stakeholder statement it was taken from; (d) Glossary definitions of 'customer' and 'postal address', with the synonyms the business uses for each"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1012" ; rdfs:label "dm-knowledge-requirements Q12: conflicting requirements in a register"@en ; schema:text "In a card register, DR-040 says 'A credit card has exactly one primary cardholder' and DR-057 says 'A credit card may have two primary cardholders.' They cannot both be met. What usually explains such a conflict, and what should be done? (a) Different priorities; keep whichever requirement is a must and drop the one that is a should; (b) An error in one statement; keep the more recently captured requirement and delete the older one; (c) Two stakeholders paraphrasing one need; retire one requirement and point it to the other one; (d) A missing condition or scope, such as card product; ask the stakeholders and state the condition in each"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1013" ; rdfs:label "dm-knowledge-conceptual Q1: intensional definition of savings account"@en ; schema:text "Which definition of 'savings account' is an intensional definition in the ISO 704 sense? (a) An account such as an instant-access saver, a fixed-term deposit or a children's savings account; (b) A deposit account that pays interest on its balance and restricts how often funds may be withdrawn; (c) An account in the core banking system whose product code lies between SAV-100 and SAV-199; (d) Something a customer opens in order to put money aside, rather than to make daily payments"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1014" ; rdfs:label "dm-knowledge-conceptual Q2: generic versus partitive concept relations"@en ; schema:text "Which pair of banking concepts stands in a generic (kind-of) relation, rather than a partitive (part-of) or other relation? (a) Check digits of an IBAN and the IBAN itself; (b) Repayment instalment and repayment schedule; (c) Residential mortgage loan and secured loan; (d) Loan and the collateral securing it"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1015" ; rdfs:label "dm-knowledge-conceptual Q3: SBVR fact type and rule statement"@en ; schema:text "In SBVR, how does the fact type 'customer holds account' relate to the rule statement 'It is obligatory that each current account is held by at least one customer'? (a) The fact type relates glossary terms; the rule statement constrains that fact type; (b) The fact type is a draft rule; the rule statement replaces it once a steward approves it; (c) The fact type defines the term account; the rule statement defines the term customer; (d) The fact type is the relationship; the rule statement is the foreign key implementing it"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1016" ; rdfs:label "dm-knowledge-conceptual Q4: data rules in Witt's business rule classification"@en ; schema:text "Under Witt's classification of business rules, which of these is a data rule, and so belongs in the data model or its data quality checks? (a) A payment over 15 000 EUR must be approved by a second staff member before it is released.; (b) A loan's outstanding principal equals the disbursed amount less the principal repaid to date.; (c) Only a branch manager may waive the early repayment fee on a fixed-rate consumer loan.; (d) A customer complaint must be answered within fifteen business days of the day it arrives."@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1017" ; rdfs:label "dm-knowledge-conceptual Q5: rule enforcement on a platform that does not enforce keys"@en ; schema:text "The rule 'no two accounts share an IBAN' is to be enforced by a unique constraint, and the target platform is Snowflake. What follows? (a) Snowflake enforces the unique constraint at load time, so no further check is required; (b) Snowflake rejects unique constraint syntax, so the rule must move into the loading job; (c) Snowflake records the unique constraint but does not enforce it, so a data quality check must; (d) Snowflake enforces the constraint only on rows inserted after it has been declared"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1018" ; rdfs:label "dm-knowledge-conceptual Q6: all-and-some test for a hierarchical link"@en ; schema:text "A lending taxonomy places 'Fixed-rate mortgage' under 'Mortgage'. What does the all-and-some test check for this link? (a) That all fixed-rate mortgages in the current portfolio are held by some customer of the bank; (b) That every fixed-rate mortgage is always a mortgage in every context, while only some mortgages are fixed-rate; (c) That every mortgage has some fixed-rate period, and all mortgages share one product code; (d) That all mortgages and some fixed-rate mortgages share the same set of attributes in the data model"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1019" ; rdfs:label "dm-knowledge-conceptual Q7: history note for a changed node meaning"@en ; schema:text "In a taxonomy of account closure reasons, the node 'Dormancy closure' was widened in 2025 to cover accounts unused for two years instead of five. Which note should record this, and why? (a) No note; the definition is updated, since the earlier meaning no longer applies to new closures; (b) A scope note stating what now belongs under the node, so that staff apply the new boundary; (c) A history note stating when and how the meaning changed, so data before and after is not compared as like; (d) A new sibling node instead, since a changed meaning always needs a new node and identifier"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1020" ; rdfs:label "dm-knowledge-conceptual Q8: warrant for a proposed vocabulary node"@en ; schema:text "A node 'Crypto savings account' is proposed for the bank's account type taxonomy. It appears in no source document, no staff or customers use the term, and no policy requires it. What follows in terms of warrant? (a) It has no literary, user or organisational warrant, so nobody can confirm its meaning and it is not added; (b) It has organisational warrant, since the taxonomy owner proposed it on the bank's behalf; (c) It has user warrant, since customers could start to use the term once a product launches; (d) Warrant concerns only the label form, so the node may be added if its label is a noun phrase"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1021" ; rdfs:label "dm-knowledge-conceptual Q9: label form conventions for card type labels"@en ; schema:text "Which set of sibling labels in a card type taxonomy follows the label form conventions for controlled vocabularies? (a) Debit card; Credit; Issue prepaid card; (b) Debit card; Credit card; CARD_PREPAID; (c) Debit card; Credit card; Prepaid card; (d) Debit cards; Credit card; Prepaid card"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1022" ; rdfs:label "dm-knowledge-conceptual Q10: one characteristic of division per sibling array"@en ; schema:text "Under 'Loan', a taxonomy has the siblings 'Secured loan', 'Unsecured loan', 'Fixed-rate loan' and 'Variable-rate loan'. What does the principle of one characteristic of division per array call for? (a) Two new concepts, 'Loan security' and 'Loan rate type', placed as subtypes of the concept 'Loan'; (b) No change, since all four siblings pass the all-and-some test against their parent 'Loan'; (c) Four compound nodes such as 'Secured fixed-rate loan', one for each combination of the two; (d) Two arrays, each under a node label naming its characteristic, such as 'by security' and 'by rate type'"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1023" ; rdfs:label "dm-knowledge-conceptual Q11: equivalence relation and preferred term"@en ; schema:text "Staff in different teams call the same thing a 'standing order', a 'recurring transfer' and an 'SO'. How should a controlled vocabulary treat these? (a) As one concept whose label joins all three names, so that every team finds its own word; (b) As three sibling nodes under 'Payment instruction', each with a scope note pointing to the others; (c) As one concept under one preferred term, with the other two recorded as non-preferred equivalents; (d) As three concepts linked by associative relations, since each team uses its own name for it"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1024" ; rdfs:label "dm-knowledge-conceptual Q12: associative relation between lending concepts"@en ; schema:text "Which pair of lending concepts is linked by an associative relation, rather than by a generic or a partitive one? (a) Mortgage loan and property valuation report; (b) Secured loan and residential mortgage loan; (c) Buy-to-let mortgage and mortgage loan; (d) Mortgage loan agreement and its early repayment clause"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1025" ; rdfs:label "dm-knowledge-conceptual Q13: reusing an external payment purpose code set"@en ; schema:text "The payments team wants its own list of payment purpose codes, although ISO 20022 publishes an external purpose code set. What does reuse of an external vocabulary involve? (a) Building the internal list first, and mapping it to the external set once the codes have settled; (b) Copying the current external codes into a CHECK constraint, so that the list can no longer drift; (c) Adopting the external codes but relabelling them in the bank's own words, for readability; (d) Adopting the external code set and recording its authority, the version used and any mapping to local codes"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1026" ; rdfs:label "dm-knowledge-logical Q1: functional dependency between card and account"@en ; schema:text "In CARD(card_number, account_number, expiry_date), the business rule is that each card is issued on exactly one account. In what sense does card_number functionally determine account_number? (a) card_number and account_number together identify each row of CARD and no smaller set does; (b) Each card_number value is associated with exactly one account_number value, by business rule; (c) In the sample extract, no card_number has yet appeared with more than one account_number; (d) Each account_number value is associated with exactly one card_number value, by business rule"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1027" ; rdfs:label "dm-knowledge-logical Q2: candidate keys and prime attributes of an account holding"@en ; schema:text "ACCOUNT_HOLDING(account_no, iban, party_id, holder_role, start_date) has these functional dependencies, taken from the business rules: account_no -> iban; iban -> account_no; {account_no, party_id} -> holder_role, start_date. List every candidate key of ACCOUNT_HOLDING, and classify each attribute as prime or non-prime."@en ; schema:learningResourceType "short_answer" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1028" ; rdfs:label "dm-knowledge-logical Q3: deletion anomaly in a loan application entity"@en ; schema:text "A single LOAN_APPLICATION entity records each application together with the applicant's employer name and employer address. Which of these is a deletion anomaly? (a) Withdrawing the only application naming an employer also removes the only record of its address; (b) Correcting an employer's address means changing every application naming that employer; (c) Recording a new employer's address is impossible until an applicant from it applies; (d) Deleting an application leaves loan offers that refer to it pointing at no application"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1029" ; rdfs:label "dm-knowledge-logical Q4: first normal form and atomic values"@en ; schema:text "Which condition must an entity meet to be in first normal form? (a) Every attribute is atomic, so composite values such as an IBAN must always be split into parts; (b) Every attribute has a datatype and a length, and is either mandatory or optional for all rows; (c) Every non-key attribute depends on the whole of the primary key, not on just part of it; (d) Every attribute holds a single atomic value, and no property is held as a repeating group"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1030" ; rdfs:label "dm-knowledge-logical Q5: second normal form and partial dependency"@en ; schema:text "ACCOUNT_HOLDER has the key {account_no, party_id} and the attributes holder_role, holding_start_date and account_currency_code. Why is it not in second normal form? (a) account_currency_code depends on account_no alone, which is only part of the candidate key; (b) holding_start_date may be unknown, so the key does not determine it for every row; (c) holder_role depends on party_id alone, because a party has a single role at the bank; (d) account_currency_code depends on another non-key attribute of the entity rather than on the key"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1031" ; rdfs:label "dm-knowledge-logical Q6: third normal form and transitive dependency"@en ; schema:text "CURRENT_ACCOUNT is keyed by account_no and holds branch_code and branch_name, where each branch code has exactly one branch name. Which statement is correct? (a) It violates 3NF: branch_name depends on the key only through branch_code, a non-prime attribute; (b) It violates 2NF: branch_name depends on part of the key, so Branch needs an entity of its own; (c) It is in 3NF: every attribute is determined by account_no, whether directly or through another; (d) It violates 1NF: branch_code and branch_name together form a repeating group of branch facts"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1032" ; rdfs:label "dm-knowledge-logical Q7: Boyce-Codd normal form with overlapping keys"@en ; schema:text "CUSTOMER_ADVISER(customer_id, product_line, adviser_id) follows two rules: each customer has one adviser per product line, and each adviser works in exactly one product line. Which statement is correct? (a) It is not in 2NF, because adviser_id depends on only part of the key {customer_id, product_line}; (b) It is not in 3NF, because product_line depends transitively on the key through adviser_id; (c) It is in BCNF, because every attribute belongs to at least one candidate key of the entity; (d) It is in 3NF but not in BCNF, because adviser_id determines product_line and is not a superkey"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1033" ; rdfs:label "dm-knowledge-logical Q8: independent multivalued facts and fourth normal form"@en ; schema:text "CUSTOMER_CONTACT_INTEREST(customer_id, phone_number, product_interest) records a customer's phone numbers and the products the customer has shown interest in. The two lists are independent of each other. What follows? (a) It violates no functional dependency, so it is in 4NF once it has been shown to be in BCNF; (b) Each phone number determines the product interests, so phone_number should become the key; (c) It has a join dependency, so it must be split into its three pairwise projections; (d) It holds two independent multivalued dependencies, so 4NF puts phones and interests in separate entities"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1034" ; rdfs:label "dm-knowledge-logical Q9: join dependency and fifth normal form"@en ; schema:text "ADVISER_PRODUCT_BRANCH records which adviser sells which product at which branch. The bank's rule is: if an adviser works at a branch, the branch offers a product, and the adviser is licensed for that product, then the adviser sells it at that branch. What does fifth normal form say about this entity? (a) It equals the join of its three pairwise projections, so it should be replaced by those three entities; (b) It is already in 5NF, because no functional dependency holds among its three attributes; (c) It holds independent multivalued facts, so two entities keyed by adviser are enough; (d) It should stay one entity, because a three-way fact can never be rebuilt from pairs of facts"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1035" ; rdfs:label "dm-knowledge-logical Q10: sixth normal form for independently changing attributes"@en ; schema:text "CUSTOMER_HISTORY keeps one row per change, with one validity period, for a customer's postal address, risk rating and marketing consent, which change independently of each other. What does sixth normal form suggest? (a) Give each independently changing attribute its own entity with its own validity period; (b) Keep only the current values, since the change history can be read from the audit log; (c) Split the history by calendar year, so each year's validity periods are stored apart; (d) Keep one row per change, but add a column recording which of the attributes changed"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1036" ; rdfs:label "dm-knowledge-logical Q11: constraints implied by keys and domains"@en ; schema:text "Domain-key normal form requires every constraint to follow from keys and domains. Which constraint on a SAVINGS_ACCOUNT entity meets that condition? (a) A notice account's withdrawal date falls at least 30 days after its notice date; (b) The interest rate is a decimal from 0 to 20 percent, and no two savings accounts share an IBAN; (c) The withdrawals in a calendar month do not exceed the limit set by the account's product; (d) The account's closing date, when present, falls on or after the account's opening date"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1037" ; rdfs:label "dm-knowledge-logical Q12: one domain per attribute"@en ; schema:text "A LOAN entity has an attribute limit_value that holds an amount in euro for credit lines but a number of months for payment holidays, depending on product_type. Which principle does this break, and what follows? (a) An attribute depends on the key; limit_value depends on product_type and needs its own entity; (b) An attribute has one datatype; storing both as a decimal makes the attribute acceptable; (c) An attribute is atomic; the value must be split into an amount part and a unit part; (d) An attribute has one domain; since its meaning and unit vary with another value, it must be split"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1038" ; rdfs:label "dm-knowledge-logical Q13: lossless-join decomposition of a payment entity"@en ; schema:text "PAYMENT(payment_id, account_no, value_date, amount, beneficiary_iban) is split into P1(payment_id, account_no, value_date, amount) and P2(value_date, beneficiary_iban). What happens when P1 and P2 are joined back on value_date? (a) Rows that never existed appear, because value_date is not a key of either part; (b) Every original row comes back, but some dependencies can no longer be enforced; (c) Some payments are lost, because the join drops rows whose value date is repeated; (d) Nothing is lost, because every attribute of PAYMENT appears in one of the two parts"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1039" ; rdfs:label "dm-knowledge-logical Q14: dependency preservation in a BCNF decomposition"@en ; schema:text "To reach BCNF, CUSTOMER_ADVISER(customer_id, product_line, adviser_id), in which each customer has one adviser per product line and each adviser works in one product line, is split into ADVISER(adviser_id, product_line) and CUSTOMER_ADVISER(customer_id, adviser_id). Joining them gives back exactly the original rows. Which statement is correct? (a) The split loses the rule that each adviser works in one product line, as adviser_id is not a key; (b) The split preserves every dependency, since each can still be derived by joining the two parts; (c) The split is lossy, since product_line is no longer stored with customer_id in a single entity; (d) The split is lossless, but the rule of one adviser per customer per product line now spans both entities"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1040" ; rdfs:label "dm-knowledge-logical Q15: snapshot value versus derivable value"@en ; schema:text "Each LOAN_PAYMENT row stores the interest rate that applied on its payment date, copied from the loan at posting time; LOAN keeps only its current rate. LOAN also stores total_repaid, the sum of its payments. How should these two stored values be classified? (a) Both are derived data, since each was computed from another stored value when it was written; (b) Both are snapshots, since each records a value as it stood when its row was last written; (c) The payment's rate is a snapshot, not derived data; total_repaid is derivable and need not be stored; (d) The payment's rate is derivable from the loan's rate; total_repaid is a snapshot of payments"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1041" ; rdfs:label "dm-knowledge-logical Q16: disjoint and partial subtyping of accounts"@en ; schema:text "Account has the subtypes Current account, Savings account and Loan account. No account is of two subtypes, and the bank also has internal suspense accounts that are none of them. Which constraints does this subtyping have? (a) Disjoint and partial: an account belongs to at most one subtype and may belong to none; (b) Overlapping and partial: an account may belong to several of the subtypes or to none of them; (c) Disjoint and total: an account belongs to exactly one subtype, so suspense accounts are excluded; (d) Overlapping and total: an account belongs to at least one of the subtypes and possibly more"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1042" ; rdfs:label "dm-knowledge-logical Q17: cardinality and optionality of account and card"@en ; schema:text "The rules say: 'A card is issued on exactly one account' and 'An account may have no cards, or many.' How are the cardinality and optionality of the Account-Card relationship read? (a) One-to-one; each card has one account, so each account can be issued only one card; (b) One-to-many; cards are mandatory for each account, and the account is optional for each card; (c) Many-to-many; a card may move between accounts, and an account may have many cards; (d) One-to-many; the account is mandatory for each card, and cards are optional for each account"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1043" ; rdfs:label "dm-knowledge-logical Q18: natural key kept beside a surrogate key"@en ; schema:text "The bank gives its ACCOUNT table a system-generated surrogate primary key. What should happen to the IBAN, the account's natural key? (a) It stays recorded and is declared unique, since only it stops one account being stored twice; (b) It becomes the foreign key in child tables, since staff can read and recognise its value; (c) It is kept but not constrained, since natural keys can change and would then break inserts; (d) It is dropped, since the surrogate key now identifies each account uniquely on its own"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1044" ; rdfs:label "dm-knowledge-logical Q19: chasm trap on an optional relationship path"@en ; schema:text "Every account is held at a branch, but the model records this only through advisers: each Account may be managed by one Adviser (optional), and each Adviser works at exactly one Branch. A report counts accounts per branch by following Account to Adviser to Branch. Which trap does this path contain, and with what effect? (a) A fan trap: two one-to-many relationships fan out from Adviser, so accounts are counted twice; (b) A connection trap: the path implies each adviser manages every account at the branch; (c) No trap: each account reaches at most one branch, so the counts per branch are correct; (d) A chasm trap: accounts with no adviser silently drop out, so branch totals are understated"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1045" ; rdfs:label "dm-knowledge-logical Q20: one entity type per business concept"@en ; schema:text "A model has the entities LOAN_2024, LOAN_2025 and LOAN_2026, with identical attributes, one for each year of origination. What follows from the principle that an entity type realises one business concept? (a) They are one concept split by a value; origination year should be an attribute of one Loan entity; (b) They are three concepts, since loans of each year were sold under different product terms; (c) They are subtypes of Loan, since each one holds a distinct subset of the bank's loans; (d) They are one concept, but each year needs its own entity to keep the loan terms' history"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1046" ; rdfs:label "dm-knowledge-physical Q1: what makes a denormalisation controlled"@en ; schema:text "To avoid a join, a reporting table copies the customer's segment from CUSTOMER onto every ACCOUNT row. What makes this a controlled denormalisation? (a) The column is read-only to users, so only the nightly load can ever change the copied value; (b) A stated mechanism keeps the copy equal to the original, and a check detects any difference; (c) The copy is described in the data dictionary, so readers know which column is the original; (d) The logical model is denormalised in the same way, so the physical copy follows the design"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1047" ; rdfs:label "dm-knowledge-physical Q2: constraints lost by rolling up subtypes"@en ; schema:text "Party, with the subtypes Person and Organisation, is implemented as one PARTY table holding the columns of both (roll-up). Which constraint is lost and must be restored by other means? (a) Uniqueness of the party identifier across persons and organisations can no longer be declared; (b) A foreign key from ACCOUNT_HOLDER to the party no longer has a single table to reference; (c) One party can now be stored as both a person row and an organisation row in two tables; (d) A column mandatory for one subtype, such as a person's date of birth, cannot be declared NOT NULL"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1048" ; rdfs:label "dm-knowledge-physical Q3: referential action for payments referencing an account"@en ; schema:text "PAYMENT has a foreign key to the ACCOUNT it was posted to. Payments have a life of their own and must be kept for audit. Which referential action on that foreign key fits? (a) Cascade: deleting an account deletes its payments, so no payment refers to a missing account; (b) Set null: deleting an account blanks the payment's account but keeps the payment row; (c) None: the ETL checks account references, so the database need not declare a foreign key; (d) Restrict: an account with payments cannot be deleted, so no payment is removed or orphaned"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1049" ; rdfs:label "dm-knowledge-physical Q4: exact decimal type for a euro balance"@en ; schema:text "Why should a euro current account balance be stored as DECIMAL(18,2) rather than as DOUBLE PRECISION? (a) Binary floating point rounds every value to whole units, so cents are lost on each posting; (b) Binary floating point cannot hold balances above about two billion without overflowing; (c) Binary floating point cannot hold most decimal fractions, such as 0.10, exactly, so totals drift; (d) Binary floating point takes more storage than a decimal holding the same number of digits"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1050" ; rdfs:label "dm-knowledge-physical Q5: null and three-valued logic in a predicate"@en ; schema:text "A query selects loans WHERE arrears_days <> 0. How does SQL treat loans whose arrears_days is null? (a) They cause the query to fail, since comparing a value with null raises a run-time error; (b) They are excluded, since comparing null with 0 yields UNKNOWN, which a WHERE clause rejects; (c) They are included, since a null is not equal to 0, so the predicate evaluates to TRUE; (d) They are excluded, since the database treats a null in a numeric column as the value 0"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1051" ; rdfs:label "dm-knowledge-physical Q6: changeable value set held as reference data"@en ; schema:text "The bank's list of account closure reasons changes a few times a year, and a retired reason must stay valid on old accounts but be refused for new closures. Where should the value set live? (a) In a database enum type, since enum values compare faster and take less storage; (b) In a reference table with validity dates, referenced by a foreign key from the account; (c) In a CHECK constraint listing the current codes, amended by a migration for each change; (d) In the application's settings only, since the database need not know the valid codes"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1052" ; rdfs:label "dm-knowledge-physical Q7: deriving indexes from access paths"@en ; schema:text "On what basis should the indexes of a physical CARD_TRANSACTION table be chosen? (a) From its foreign keys, its natural-key unique constraints and the access paths the requirements state; (b) From every column of the table, so that any future query can be answered from an index; (c) From the primary key only, adding others once performance problems appear in production; (d) From every column used in a WHERE clause of any query written against the table so far"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1053" ; rdfs:label "dm-knowledge-physical Q8: half-open validity periods in a versioned table"@en ; schema:text "A versioned INTEREST_RATE table records each rate with a validity period. Why are half-open periods [valid_from, valid_to) the preferred convention? (a) Each version ends exactly where the next begins, so every date falls in exactly one version; (b) Both end dates belong to the version, so a rate is valid on its last day as on its first; (c) The start date is excluded from the version, so a new rate takes effect the following day; (d) The end date of the current version can be left empty, so no flag is needed to find it"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1054" ; rdfs:label "dm-knowledge-physical Q9: semi-additive month-end balance measure"@en ; schema:text "A fact table holds one row per savings account per month end, with the measure end_of_month_balance. How may this measure be aggregated? (a) Summed across every dimension, because a balance is a numeric amount like any other measure; (b) Summed across months for one account, but not across accounts, as currencies may differ; (c) Summed across accounts for one month, but not across months; over time it is averaged or taken at period end; (d) Never summed, because a balance is a non-additive measure, like an interest rate or a ratio"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1055" ; rdfs:label "dm-knowledge-physical Q10: vertical split that keeps one entity"@en ; schema:text "A wide CUSTOMER table is split vertically into CUSTOMER_CORE and CUSTOMER_MARKETING for access reasons. What keeps the two tables one entity? (a) Both carry the same primary key, and the one-to-one relationship between them is enforced; (b) Both are partitioned on the same column, so matching rows sit in the same partition; (c) Both carry the customer's name, so the rows can be matched again when they are joined; (d) Both sit in the same tablespace and are loaded by the same nightly job, in one run"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1056" ; rdfs:label "dm-knowledge-physical Q11: consistency risk of documents stored by reference"@en ; schema:text "Signed loan agreements are kept as PDF files on a file server, and LOAN_AGREEMENT holds each file's path. Which consistency risk follows? (a) The database copies each file into its own storage on insert, which doubles the space used; (b) The files are outside the database's transactions and backups, so a row and its file can diverge; (c) The path acts as a foreign key, so a file cannot be deleted while a row still refers to it; (d) The path column cannot be indexed, so finding a loan's agreement needs a full table scan"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1057" ; rdfs:label "dm-knowledge-physical Q12: no meaning in relational row or key order"@en ; schema:text "A team finds a customer's first account as the one with the lowest generated account_id. Why is this unsafe? (a) The query is correct, but sorting a large ACCOUNT table by its key is expensive to run; (b) The lowest key is reliable only when the table has a clustered index on account_id; (c) Generated keys follow insertion order, but accounts may be inserted out of business order; (d) A table is an unordered set, and generated key values carry no guaranteed business order"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1058" ; rdfs:label "dm-knowledge-physical Q13: where to fix a defect in generated DDL"@en ; schema:text "A reviewer finds that the generated DDL for the LOAN table lacks a check that the loan term is positive. Where should the fix be made? (a) In a patch script run after the generated DDL, kept beside it in the model repository; (b) In the deployed database, after which the DDL is reverse-engineered back into the file; (c) In the physical model, or in the rule behind it, and the DDL is then regenerated from it; (d) In the generated DDL file itself, with a comment noting that the change was made by hand"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1059" ; rdfs:label "dm-knowledge-physical Q14: one logical type rendering differently by SQL engine"@en ; schema:text "The physical model gives a column the logical type Timestamp. Why can the DDL generator not emit the type name TIMESTAMP unchanged on every target engine? (a) It stores a date only on most engines, so the time of day must be held in a second column; (b) It is reserved on every engine, so it must always be quoted wherever it is used as a type; (c) It exists only on Oracle, so the other engines need a character column to hold the value; (d) Its meaning differs: a row-version counter in SQL Server, a 32-bit type ending in 2038 in MySQL"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1060" ; rdfs:label "dm-knowledge-physical Q15: currency minor units and amount scale"@en ; schema:text "A PAYMENT table holds amounts in any ISO 4217 currency. Why is DECIMAL(18,2) a poor type for the amount? (a) Minor units range from 0 to 3 digits, so Kuwaiti dinar amounts need three decimals; (b) Two decimals are too few for any currency once interest is calculated on the amount; (c) Every currency has two minor-unit digits, but conversion needs four for exchange rates; (d) ISO 4217 requires amounts to be stored as integers in minor units, never as decimals"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1061" ; rdfs:label "dm-knowledge-physical Q16: event timestamps and business dates"@en ; schema:text "Which typing of temporal columns fits a bank that books payments in more than one time zone? (a) Both as timestamps with an offset, so the value date is kept to the second like the event; (b) The authorisation time as a timestamp with offset, the value date as a date with no time; (c) The authorisation time as a date, the value date as a timestamp with booking offset; (d) Both as timestamps without zone, converted to the server's local time when loaded"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1062" ; rdfs:label "dm-knowledge-physical Q17: collation and the meaning of a key"@en ; schema:text "The IBAN column is the natural key of ACCOUNT. Why does the column's collation matter? (a) It decides the order in which rows are stored, so it fixes which IBAN is read first; (b) It decides which characters may be stored, so it rejects lower-case letters in an IBAN; (c) It decides the storage size of each character, so it fixes the column's maximum length; (d) It decides which values compare equal, so a case-insensitive one makes two spellings one key"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1063" ; rdfs:label "dm-knowledge-physical Q18: access design derived from data classification"@en ; schema:text "A customer's tax identification number is classified restricted in the model. Where does its access design come from, and what does it contain? (a) From encryption: an encrypted column needs no grants, masking or row-level rules; (b) From the application: the database grants all roles, and the screens hide the column; (c) From the classification: role grants, masking for those not cleared, and row-level rules; (d) From the CREATE TABLE script: the generator adds a grant for each restricted column"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1064" ; rdfs:label "dm-knowledge-physical Q19: adding a mandatory column to a populated table"@en ; schema:text "A new NOT NULL column is to be added to the populated LOAN table in production. What does a safe change require? (a) Regenerating the CREATE TABLE script and redeploying it, since it now contains the column; (b) Adding the column as NOT NULL in one step, since the engine fills the existing rows with nulls; (c) A migration that adds the column, backfills existing rows, then tightens it, with a tested rollback; (d) Running the drop script first to clear the table, keeping the old create script as rollback"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1065" ; rdfs:label "dm-knowledge-physical Q20: one artefact for every deployment environment"@en ; schema:text "What does environment-independent deployment require of the reviewed DDL for the deposits schema? (a) One artefact builds dev, test and production, with schema and database names from configuration; (b) One artefact with the production schema name hard-wired, edited for the others when deployed; (c) One artefact for production only, with dev and test copied by hand from its catalogue; (d) One copy of the DDL per environment, each reviewed separately before it is deployed there"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1066" ; rdfs:label "dm-knowledge-physical Q21: proving DDL by execution and detecting drift"@en ; schema:text "How is generated DDL for a card schema shown to be correct, and how is later drift detected? (a) By validating the model against its schema, which proves the DDL so that drift cannot occur; (b) By running it once on the development engine, and by reverse-engineering production yearly; (c) By running it on each target engine, and by comparing the deployed catalogue with the model; (d) By a peer reading the SQL before release, and by checking the change log after incidents"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1067" ; rdfs:label "dm-knowledge-dmbok-ch5 Q1: purpose of building a data model"@en ; schema:text "According to DAMA-DMBOK2, which is a primary reason an organisation such as a retail bank builds data models? (a) To decide indexes and storage early, so performance is fixed before requirements are gathered; (b) To generate application code for transaction systems directly from the entity definitions; (c) To replace the business glossary, since the entity and attribute definitions make it redundant; (d) To formalise and communicate data requirements in a shared vocabulary, and to retain that knowledge"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1068" ; rdfs:label "dm-knowledge-dmbok-ch5 Q2: DMBOK type of modelled data for a loan application"@en ; schema:text "DAMA-DMBOK2 distinguishes category, resource, business event and detail transaction data. Which type is a customer's loan application? (a) Category data, used to classify customers and loans, such as into market segments; (b) Resource data, a basic profile of something needed to run the bank's lending process; (c) Detail transaction data, a high-volume record of activity such as card authorisations; (d) Business event data, created while an operational process such as lending is under way"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1069" ; rdfs:label "dm-knowledge-dmbok-ch5 Q3: zero-or-many in Information Engineering notation"@en ; schema:text "In Information Engineering (crow's foot) notation, how is 'an account has zero, one or many cards' shown at the card end of the relationship? (a) Two bars across the line; (b) A circle next to a crow's foot; (c) A circle next to a bar; (d) A bar next to a crow's foot"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1070" ; rdfs:label "dm-knowledge-dmbok-ch5 Q4: identifying relationship for repayment instalments"@en ; schema:text "Repayment instalments are numbered 1, 2, 3 within each loan's repayment schedule. Which relationship does INSTALMENT have to REPAYMENT_SCHEDULE, and what is its key? (a) Non-identifying: its key is the instalment number alone, with a mandatory foreign key to the schedule; (b) Identifying: its key is the instalment number alone, as an instalment cannot exist without a schedule; (c) Identifying: its key is the schedule's key plus the instalment number, so it is a dependent entity; (d) Non-identifying: its key is the schedule key plus the due date, so it is an independent entity"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1071" ; rdfs:label "dm-knowledge-dmbok-ch5 Q5: conformed dimensions across banking star schemas"@en ; schema:text "A bank builds a card spending star schema and a payments star schema, both analysed by customer and by date. What does using conformed dimensions mean here? (a) Each fact table has its own customer dimension, normalised into a snowflake of related tables; (b) Each fact table has its own dimensions shaped to its needs, but loaded from the same source system; (c) Both fact tables use one customer and one date dimension, with the same keys, attributes and meaning; (d) Both fact tables are merged into one fact table at the same grain, keyed by customer and date"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1072" ; rdfs:label "dm-knowledge-dmbok-ch5 Q6: UML class diagram versus entity-relationship model"@en ; schema:text "How does a UML class diagram used as a data modelling scheme differ from an entity-relationship diagram? (a) A class diagram is limited to physical design and cannot express a conceptual model; (b) A class can carry operations as well as attributes, which an ER entity does not; (c) A class diagram cannot show generalisation, so subtypes are drawn as associations; (d) A class diagram cannot express multiplicity, so cardinality goes into separate notes"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1073" ; rdfs:label "dm-knowledge-dmbok-ch5 Q7: elementary facts in fact-based modelling"@en ; schema:text "In fact-based modelling such as ORM or FCO-IM, how is the statement 'Customer C-104 holds account A-2207' treated? (a) As a rule statement constraining Customer, which a foreign key will later enforce; (b) As a row of an Account entity whose holder_customer_id attribute has the value C-104; (c) As an instance of an elementary fact type in which Customer and Account each play a role; (d) As an attribute value of Customer, since attributes are identified before any facts"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1074" ; rdfs:label "dm-knowledge-dmbok-ch5 Q8: hubs, links and satellites in a Data Vault"@en ; schema:text "A loan origination source model is loaded into a Data Vault. Where do the loan's business key, the loan-customer association and the loan's changing interest terms go? (a) The business key to a hub, the association to a link, and the changing terms to a satellite; (b) All three into one wide hub table, with a load date and a record source on every row; (c) The business key to a satellite, the association to a hub, and the changing terms to a link; (d) The business key to a hub, the association to a satellite, and the changing terms to a link"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1075" ; rdfs:label "dm-knowledge-dmbok-ch5 Q9: aggregate-oriented modelling in a document store"@en ; schema:text "A mobile banking app reads a customer's profile, accounts and last ten transactions in a single call. How does document store modelling typically approach this? (a) Normalise to 3NF first, then store each entity as its own collection linked by references; (b) Design an aggregate for the access path, embedding what is read together, with controlled duplication; (c) Use a graph store, since any data with relationships between entities is best kept as a graph; (d) Store every attribute as a key-value pair, so any combination can be read without a schema"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1076" ; rdfs:label "dm-knowledge-dmbok-ch5 Q10: canonical data model for system integration"@en ; schema:text "A bank integrates its core banking, card and CRM systems through a message bus. What is a canonical data model in this setting? (a) The core banking system's model, adopted by the card and CRM systems as the master structure; (b) A shared model of the exchanged data, independent of each system's own model, that each maps to; (c) The union of the three systems' models, keeping every attribute each system currently holds; (d) A physical database holding a copy of all the data exchanged between the three systems"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1077" ; rdfs:label "dm-knowledge-dmbok-ch5 Q11: database view for restricted and joined access"@en ; schema:text "Branch staff may see account balances but not customers' tax identifiers, and analysts want accounts joined to their holders. What can a database view provide here without storing the data again? (a) A virtual table presenting only the permitted columns and the joined data, computed at query time; (b) A stored copy of the joined data, refreshed each night, so that analysts' queries run faster; (c) A physical partition of each table, so that each role reads only the rows of its partition; (d) A trigger-maintained summary table, so that balances are ready without a join being run"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1078" ; rdfs:label "dm-knowledge-dmbok-ch5 Q12: deliverables of a data modelling plan"@en ; schema:text "DAMA-DMBOK2 lists the deliverables a data modelling plan should provide for. Which set matches it? (a) The diagram, definitions of its objects, issues and open questions, and lineage; (b) The diagram, the DDL scripts, the test data and the deployment runbook; (c) The diagram, a data quality dashboard, the service levels and access rights; (d) The diagram, the project budget, the staffing plan and the tool licences"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1079" ; rdfs:label "dm-knowledge-dmbok-ch5 Q13: choosing a modelling scheme and notation"@en ; schema:text "A bank needs a model of its deposit products for business stakeholders to validate, and a separate model for analysing monthly balances. Which choice follows the principle that the scheme fits the data and its use, and the notation fits the audience? (a) A dimensional scheme for both, since business stakeholders also read reports on deposit balances; (b) A physical relational model in IDEF1X for both, so that one notation is used across the bank; (c) A relational conceptual model in a simple notation for the business, and a dimensional scheme for analysis; (d) A UML class diagram for the business audience, since UML is the most widely known notation"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1080" ; rdfs:label "dm-knowledge-dmbok-ch5 Q14: what reverse engineering cannot recover alone"@en ; schema:text "A legacy card system's database is reverse-engineered from its catalogue. What can the catalogue not supply by itself? (a) The declared primary keys and indexes, which reverse engineering ignores by design; (b) The tables, columns and datatypes, which must be re-entered from vendor documents; (c) The column lengths and nullability, which a catalogue records only for new tables; (d) Undeclared foreign keys, the meaning of cryptic columns, and which objects are still in use"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1081" ; rdfs:label "dm-knowledge-dmbok-ch5 Q15: data model scorecard categories"@en ; schema:text "Reviewing a loan model, a reviewer finds that entity definitions are vague, and profiling shows a field documented as mandatory is empty in 30% of rows. Under which Data Model Scorecard categories are these two findings scored? (a) The quality of the definitions, and how well the metadata matches the data; (b) The capture of requirements, and consistency with the enterprise model; (c) The adherence to naming standards, and the readability of the diagram; (d) The completeness of the model, and how structurally sound the model is"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1082" ; rdfs:label "dm-knowledge-dmbok-ch5 Q16: semantic version of a breaking model change"@en ; schema:text "Under semantic versioning of a released deposits model, which change calls for a new major version? (a) Correcting a typing error in the definition of account closure reason; (b) Removing the column dormant_since from ACCOUNT, which downstream reports read; (c) Adding an optional marketing_consent_date column to the CUSTOMER entity; (d) Adding a value to the extensible list of account closure reasons in use"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1083" ; rdfs:label "dm-knowledge-dmbok-ch5 Q17: matching modelling tasks to tool types"@en ; schema:text "Which pairing of a data modelling task with the type of tool that supports it is correct? (a) Recording which reports read the loan balance column: a modelling tool's diagram editor; (b) Finding actual null rates and value distributions in a legacy account table: a data profiling tool; (c) Generating DDL for a new card schema from its physical model: a metadata repository; (d) Showing where customer addresses come from and where they flow to: a data profiling tool"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1084" ; rdfs:label "dm-knowledge-dmbok-ch5 Q18: party-role pattern and adapting an industry model"@en ; schema:text "A bank must record that one party can be a customer, a guarantor on a loan and an employee at the same time. Which pattern addresses this, and how should an industry model that contains it be used? (a) An associative entity per pair of roles; build from scratch, as industry models are generic; (b) The party-role pattern; adopt the industry model whole, as it reflects industry practice; (c) The party-role pattern; take the industry model as a starting point and adapt it to the bank; (d) Subtypes Customer, Guarantor and Employee of Party; adopt the industry model whole"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1085" ; rdfs:label "dm-knowledge-dmbok-ch5 Q19: ISO/IEC 11179 decomposition of an attribute name"@en ; schema:text "Under an ISO/IEC 11179 naming convention, how does the attribute name 'Account Ledger Balance Amount' decompose? (a) Object class Account, qualifier Ledger, property Balance, representation term Amount; (b) Object class Account, qualifier Balance, property Ledger, representation term Amount; (c) Object class Account Ledger, property Amount, representation term Balance; (d) Object class Ledger, qualifier Account, property Balance, representation term Amount"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1086" ; rdfs:label "dm-knowledge-dmbok-ch5 Q20: database design principle served by access through views"@en ; schema:text "Branch staff are given access to account data only through views and roles, never directly to base tables. Which DMBOK2 database design principle does this serve most directly? (a) Integrity: business rules are enforced, so the data is correct and meaningful; (b) Security: data is protected, and access is granted by need rather than by default; (c) Reusability: structures can serve several applications without being copied; (d) Maintainability: the data can be changed at a cost proportional to its value"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1087" ; rdfs:label "dm-knowledge-dmbok-ch5 Q21: content and upkeep of a modelling standard"@en ; schema:text "What should a bank's data modelling and design standard cover, and how should it be kept? (a) The DDL of every approved table, kept in the standard so projects can copy it unchanged; (b) The modelling tool's default settings, kept as shipped so that nobody need agree conventions; (c) The entity definitions of each project, kept by that project's lead modeller for reference; (d) Naming, notation, definitions, deliverables and review criteria, versioned and kept by an owner"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-125" ; rdfs:label "dm-requirements-history C1: requirement silent on current versus past values while the register settles history"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-126" ; rdfs:label "dm-requirements-history C2: design solution restated as the need"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-127" ; rdfs:label "dm-requirements-history C3: undefined qualifier raised, not defined by guess"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-128" ; rdfs:label "dm-requirements-history C4: requirements with no source or no locator"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-129" ; rdfs:label "dm-requirements-history C5: regulatory requirement without rationale"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-130" ; rdfs:label "dm-requirements-history C6: one word per thing, and cardholder kept apart"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-131" ; rdfs:label "dm-requirements-history C7: register with no purpose, exclusions or overlapping systems"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-132" ; rdfs:label "dm-requirements-history C8: register describing things and no events"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-133" ; rdfs:label "dm-requirements-history C9: missing and wrong term traces"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-411" ; rdfs:label "dm-taxonomy-notes C1: one label for customer and general ledger account"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-412" ; rdfs:label "dm-taxonomy-notes C2: catch-all node given a scope note"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-413" ; rdfs:label "dm-taxonomy-notes C3: overlapping segments given reciprocal scope notes"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-414" ; rdfs:label "dm-taxonomy-notes C4: segment widened in place given a history note"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-415" ; rdfs:label "dm-taxonomy-notes C5: sibling labels of mixed form"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-416" ; rdfs:label "dm-taxonomy-notes C6: system name and jargon as node labels"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-417" ; rdfs:label "dm-taxonomy-notes C7: payment nodes combining reach and settlement speed"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-418" ; rdfs:label "dm-taxonomy-notes C8: value segment mixed with legal-form segments"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-419" ; rdfs:label "dm-taxonomy-notes C9: named banks as nodes"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-420" ; rdfs:label "dm-taxonomy-notes C10: credit assessment and agreement document under Loan"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-421" ; rdfs:label "dm-taxonomy-notes C11: parent and children disagreeing"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-422" ; rdfs:label "dm-taxonomy-notes C12: home equity mortgage beside Mortgage"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-423" ; rdfs:label "dm-taxonomy-notes C13: home-grown purpose list and copied activity classification"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-424" ; rdfs:label "dm-taxonomy-notes C14: node deleted while accounts refer to it"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-425" ; rdfs:label "dm-taxonomy-notes C15: retired product id reused for a new product"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-517" ; rdfs:label "dm-logical-integrity C1: advisor determinant that is not a key (BCNF)"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-518" ; rdfs:label "dm-logical-integrity C2: dependencies lost by the routing split and by the answer's own split"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-519" ; rdfs:label "dm-logical-integrity C3: lossy split of card issue on the role code"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-520" ; rdfs:label "dm-logical-integrity C4: broker join dependency decomposed, signatory authority kept whole"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-521" ; rdfs:label "dm-logical-integrity C5: connection trap in the broker commission report"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-522" ; rdfs:label "dm-logical-integrity C6: fan trap between card and card transaction"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-523" ; rdfs:label "dm-logical-integrity C7: chasm trap through the optional advisor"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-524" ; rdfs:label "dm-logical-integrity I1: card settings as name-value rows, waived product features kept"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-525" ; rdfs:label "dm-logical-integrity I2: loan attributes on the instalment (partial dependency)"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-526" ; rdfs:label "dm-logical-integrity I3: branch languages and accessibility features in one entity (4NF)"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-527" ; rdfs:label "dm-logical-integrity I4: loan histories split, exchange rate kept together"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-528" ; rdfs:label "dm-logical-integrity I5: polymorphic complaint subject"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-529" ; rdfs:label "dm-logical-integrity I6: retail customer and card holder overlap"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-530" ; rdfs:label "dm-logical-integrity I7: direct debit mandates split by country"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-531" ; rdfs:label "dm-logical-integrity I8: account domains and closing-date rule not implied by keys and domains"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-532" ; rdfs:label "dm-logical-integrity I9: card limit amount with two meanings"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-533" ; rdfs:label "dm-logical-integrity I10: business customer identified only by a system key, complaint reference kept"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-614" ; rdfs:label "dm-physical-postgres C1: destructive referential actions changed, schedule-line cascade kept"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-615" ; rdfs:label "dm-physical-postgres C2: soft-deleted customers and the constraints"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-616" ; rdfs:label "dm-physical-postgres C3: index set derived from access paths"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-617" ; rdfs:label "dm-physical-postgres C4: savings rate history, email overwrite kept"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-618" ; rdfs:label "dm-physical-postgres I1: branch merged into account"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-619" ; rdfs:label "dm-physical-postgres I2: overdraft terms split without an enforced one-to-one"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-620" ; rdfs:label "dm-physical-postgres I3: card transactions in clone tables by year"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-621" ; rdfs:label "dm-physical-postgres I4: customer subtypes rolled down with no supertype"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-622" ; rdfs:label "dm-physical-postgres I5: product group hierarchy as a path string"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-623" ; rdfs:label "dm-physical-postgres I6: loan document held on a file share by path"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-624" ; rdfs:label "dm-physical-postgres I7: meaningful loan_id printed as the loan number"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-625" ; rdfs:label "dm-physical-postgres I8: undeclared standing-order foreign key"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-626" ; rdfs:label "dm-physical-postgres I9: account status list fixed in a CHECK, debit/credit check kept"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-627" ; rdfs:label "dm-physical-postgres I10: current address read from key order"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-628" ; rdfs:label "dm-physical-postgres I11: month-end measures without additivity"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-629" ; rdfs:label "dm-physical-postgres I12: nullable channel on the payment volume join"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-630" ; rdfs:label "dm-physical-postgres I13: null meaning no ATM limit"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-818" ; rdfs:label "dm-ddl-review-deploy C1: DDL older than its model"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-819" ; rdfs:label "dm-ddl-review-deploy C2: SQL approved by reading, never executed"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-820" ; rdfs:label "dm-ddl-review-deploy C3: production index in no model, no drift comparison"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-821" ; rdfs:label "dm-ddl-review-deploy I1: header warning carried without a decision"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-822" ; rdfs:label "dm-ddl-review-deploy I2: regex check running on one engine only"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-823" ; rdfs:label "dm-ddl-review-deploy I3: reserved word as a column name"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-824" ; rdfs:label "dm-ddl-review-deploy I4: BOOLEAN meaning four things on five engines"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-825" ; rdfs:label "dm-ddl-review-deploy I5: mandatory foreign-key cycle taken as resolved"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-826" ; rdfs:label "dm-ddl-review-deploy I6: collation deciding what the IBAN key means"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-827" ; rdfs:label "dm-ddl-review-deploy I7: event timestamp without a zone, value date as a timestamp"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2401" ; rdfs:label "dm-design-schemes C1: star schema for card authorisations"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2402" ; rdfs:label "dm-design-schemes C2: Data Vault for customers and accounts from two sources"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2403" ; rdfs:label "dm-design-schemes C3: document per account-month for the mobile statement"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2404" ; rdfs:label "dm-design-schemes C4: view over partitioned balance history"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2405" ; rdfs:label "dm-design-schemes C5: loans and collateral as a UML class diagram"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2406" ; rdfs:label "dm-design-schemes C6: account holding as fact types"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2407" ; rdfs:label "dm-design-schemes C7: card customer record onto the canonical party model"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2001" ; rdfs:label "dm-planning C1: scope with no boundary"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2002" ; rdfs:label "dm-planning C2: plan and config disagree on naming"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2003" ; rdfs:label "dm-planning C3: model layers with no notation"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2004" ; rdfs:label "dm-planning C4: data rules not where the config says"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2005" ; rdfs:label "dm-planning C5: review planned by the modeller"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2006" ; rdfs:label "dm-planning C6: shared folder with no versions or baseline"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2007" ; rdfs:label "dm-planning I1: plans the term deposit mart deliverables"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2008" ; rdfs:label "dm-planning I2: scheme and notation per layer for its audience"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2009" ; rdfs:label "dm-planning I3: naming, definition and design standards set once"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2010" ; rdfs:label "dm-planning I4: tools and a repository with tagged baselines"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2101" ; rdfs:label "dm-model-review C1: scorecard missing a category, weights 95"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2102" ; rdfs:label "dm-model-review C2: full score with no evidence"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2103" ; rdfs:label "dm-model-review C3: model reviewed by its modeller"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2104" ; rdfs:label "dm-model-review C4: approved below the threshold"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2105" ; rdfs:label "dm-model-review C5: review finding with no owner or action"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2106" ; rdfs:label "dm-model-review C6: full structural score against validator errors"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2107" ; rdfs:label "dm-model-review C7: review of a version other than the one released"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2108" ; rdfs:label "dm-model-review I1: complete scorecard with evidence per category"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2109" ; rdfs:label "dm-model-review I2: scores follow the validator, trace, definitions and profiling"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2110" ; rdfs:label "dm-model-review I3: total and decision against the threshold"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2111" ; rdfs:label "dm-model-review I4: blocking findings with owner, action and due date"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2201" ; rdfs:label "dm-reverse-engineering C1: inferred relationship with no evidence or confidence"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2202" ; rdfs:label "dm-reverse-engineering C2: produced table not marked as-is"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2203" ; rdfs:label "dm-reverse-engineering C3: dead table lifted into the model"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2204" ; rdfs:label "dm-reverse-engineering C4: guessed indicator meaning written as a definition"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2205" ; rdfs:label "dm-reverse-engineering C5: replica catalogue read with no date"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2206" ; rdfs:label "dm-reverse-engineering C6: report copy lifted as a logical attribute"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2207" ; rdfs:label "dm-reverse-engineering I1: entities, associative entity and keys recovered"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2208" ; rdfs:label "dm-reverse-engineering I2: declared and inferred relationships kept apart"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2209" ; rdfs:label "dm-reverse-engineering I3: dead conversion table left out"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2210" ; rdfs:label "dm-reverse-engineering I4: unexplained column and code asked of the owner"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2211" ; rdfs:label "dm-reverse-engineering I5: report copy table kept physical"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2301" ; rdfs:label "dm-maintenance C1: model change with no reason"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2302" ; rdfs:label "dm-maintenance C2: deprecated column with no impact analysis"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2303" ; rdfs:label "dm-maintenance C3: change of meaning released as a minor version"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2304" ; rdfs:label "dm-maintenance C4: deployed column renamed with no migration"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2305" ; rdfs:label "dm-maintenance C5: release with no baseline"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2306" ; rdfs:label "dm-maintenance C6: change released without approval"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2307" ; rdfs:label "dm-maintenance I1: column drop released as a major version"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2308" ; rdfs:label "dm-maintenance I2: reason and impact including the regulatory return"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2309" ; rdfs:label "dm-maintenance I3: expand-and-contract migration with rollback"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-2310" ; rdfs:label "dm-maintenance I4: baseline tag and the plan's approver"@en ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1801" ; rdfs:label "Meaning of a measured quantity"@en ; schema:text "What does the measured quantity 3 m mean? (a) 3 is the unit and m is the number; (b) the measured magnitude contains three metres; (c) m means three kilograms; (d) 3 m is always the same as 3 cm"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1802" ; rdfs:label "Hypothesis and counter-example"@en ; schema:text "What does one counter-example to the statement \"every prime number is odd\" prove? (a) the statement mostly holds; (b) the statement is false; (c) the statement is unproven; (d) the example proves nothing"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1803" ; rdfs:label "Database structure"@en ; schema:text "What is the primary key of a table for? (a) it identifies each row uniquely; (b) it sets the colour of a column; (c) it deletes the table; (d) it counts the columns"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1804" ; rdfs:label "Function (dependency, argument, value of the function)"@en ; schema:text "Which example describes a dependency in which each value of the argument corresponds to one value of the function? (a) height and weight of the whole class on one day; (b) the length of a side of a rectangle and its area, when the other side is 5; (c) one person's height and their favourite numbers; (d) two arbitrary numbers"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1805" ; rdfs:label "Rules of definition"@en ; schema:text "Which description consists of the main parts of a definition? (a) the nearest superordinate concept and the distinguishing characteristic; (b) only the name of the concept; (c) repeating the concept; (d) only an example"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1806" ; rdfs:label "Proposition and truth value"@en ; schema:text "Which is a proposition? (a) What time is it?; (b) Do the exercise!; (c) 17 is a prime number.; (d) x + 2 = 5"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a edu:Question ; dcterms:identifier "I-1807" ; rdfs:label "Class diagram notation"@en ; schema:text "What does a rectangle divided into three parts show in a UML class diagram? (a) the class name, its attributes and its operations; (b) starting a program; (c) a database table; (d) user input"@en ; schema:learningResourceType "multiple_choice" ; edu:solvableWith [ a edu:KnobitSet ; edu:memberKnobit ] ; schema:isPartOf . a schema:CreativeWork ; dcterms:identifier "REF-1" ; dcterms:title "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design"@en ; dcterms:publisher "DAMA International" ; schema:version "2nd edition, revised (DMBOK2/RE)" ; skos:note "target level: CDMP Practitioner: the Data Modeling and Design specialist exam of the Certified Data Management Professional (DAMA International), pass mark 70%"@en . a edu:LearningOutcome ; dcterms:identifier "DM-1" ; rdfs:label "Business drivers for data modelling"@en ; dcterms:description "Why organisations model data - a common vocabulary, retained knowledge about data and systems, and formal structures for building and integrating systems."@en ; skos:notation "1.1" ; dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 1.1"@en ; edu:includesKnobit ; schema:isPartOf . a edu:LearningOutcome ; dcterms:identifier "DM-2" ; rdfs:label "Goals and principles of data modelling"@en ; dcterms:description "Formalising data requirements, defining scope, and retaining knowledge, as the goals a data model serves."@en ; skos:notation "1.2" ; dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 1.2"@en ; edu:includesKnobit ; schema:isPartOf . a edu:LearningOutcome ; dcterms:identifier "DM-3" ; rdfs:label "Data modelling and data models"@en ; dcterms:description "What a data model is - symbols and text representing data as the organisation understands it or wants it to be - and its role as documentation and as a communication tool."@en ; skos:notation "1.3.1" ; dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 1.3.1"@en ; edu:includesKnobit ; schema:isPartOf . a edu:LearningOutcome ; dcterms:identifier "DM-4" ; rdfs:label "Types of data that are modelled"@en ; dcterms:description "Category, resource, business event and detail transaction data."@en ; skos:notation "1.3.2" ; dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 1.3.2"@en ; edu:includesKnobit ; schema:isPartOf . a edu:LearningOutcome ; dcterms:identifier "DM-5" ; rdfs:label "Entity"@en ; dcterms:description "The thing about which data is kept; its aliases across schemes, its graphic representation and its definition."@en ; skos:notation "1.3.3.1" ; dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 1.3.3.1"@en ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; schema:isPartOf . a edu:LearningOutcome ; dcterms:identifier "DM-6" ; rdfs:label "Relationship"@en ; dcterms:description "Associations between entities; their aliases and notation, cardinality and optionality, arity (unary, binary, ternary) and foreign keys."@en ; skos:notation "1.3.3.2" ; dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 1.3.3.2"@en ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; schema:isPartOf . a edu:LearningOutcome ; dcterms:identifier "DM-7" ; rdfs:label "Attribute and identifiers"@en ; dcterms:description "Properties of an entity; keys by construction (simple, compound, composite, surrogate) and by function (super, candidate, primary, alternate); identifying and non-identifying relationships."@en ; skos:notation "1.3.3.3" ; dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 1.3.3.3"@en ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; schema:isPartOf . a edu:LearningOutcome ; dcterms:identifier "DM-8" ; rdfs:label "Domain"@en ; dcterms:description "The set of values an attribute may take, defined by data type, format, list, range or rule."@en ; skos:notation "1.3.3.4" ; dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 1.3.3.4"@en ; edu:includesKnobit ; schema:isPartOf . a edu:LearningOutcome ; dcterms:identifier "DM-9" ; rdfs:label "Relational modelling scheme"@en ; dcterms:description "Relations, keys and normalisation as a modelling scheme, and its notations."@en ; skos:notation "1.3.4.1" ; dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 1.3.4.1"@en ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; schema:isPartOf . a edu:LearningOutcome ; dcterms:identifier "DM-10" ; rdfs:label "Dimensional modelling scheme"@en ; dcterms:description "Fact and dimension tables, grain, star and snowflake schemas, conformed dimensions and facts."@en ; skos:notation "1.3.4.2" ; dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 1.3.4.2"@en ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; schema:isPartOf . a edu:LearningOutcome ; dcterms:identifier "DM-11" ; rdfs:label "Object-oriented modelling scheme (UML)"@en ; dcterms:description "UML class diagrams as a data modelling scheme and how they differ from entity-relationship models."@en ; skos:notation "1.3.4.3" ; dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 1.3.4.3"@en ; edu:includesKnobit ; edu:includesKnobit ; schema:isPartOf . a edu:LearningOutcome ; dcterms:identifier "DM-12" ; rdfs:label "Fact-based modelling scheme"@en ; dcterms:description "Object Role Modeling and Fully Communication Oriented Information Modeling, which model facts rather than entities and attributes."@en ; skos:notation "1.3.4.4" ; dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 1.3.4.4"@en ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; schema:isPartOf . a edu:LearningOutcome ; dcterms:identifier "DM-13" ; rdfs:label "Time-based modelling schemes"@en ; dcterms:description "Data Vault (hubs, links, satellites) and Anchor Modeling, which keep history by design."@en ; skos:notation "1.3.4.5" ; dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 1.3.4.5"@en ; edu:includesKnobit ; edu:includesKnobit ; schema:isPartOf . a edu:LearningOutcome ; dcterms:identifier "DM-14" ; rdfs:label "NoSQL modelling schemes"@en ; dcterms:description "Document, column-family, graph and key-value stores, and how modelling for them differs."@en ; skos:notation "1.3.4.6" ; dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 1.3.4.6"@en ; edu:includesKnobit ; edu:includesKnobit ; schema:isPartOf . a edu:LearningOutcome ; dcterms:identifier "DM-15" ; rdfs:label "Conceptual data model"@en ; dcterms:description "High-level concepts and their relationships, in the business's terms, independent of technology."@en ; skos:notation "1.3.5.1" ; dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 1.3.5.1"@en ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; schema:isPartOf . a edu:LearningOutcome ; dcterms:identifier "DM-16" ; rdfs:label "Logical data model"@en ; dcterms:description "Entities, attributes, keys and relationships in detail, normalised, independent of a platform."@en ; skos:notation "1.3.5.2" ; dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 1.3.5.2"@en ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; schema:isPartOf . a edu:LearningOutcome ; dcterms:identifier "DM-17" ; rdfs:label "Physical data model"@en ; dcterms:description "The design for a particular platform - tables, columns, types, keys, constraints and indexes."@en ; skos:notation "1.3.5.3" ; dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 1.3.5.3"@en ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; schema:isPartOf . a edu:LearningOutcome ; dcterms:identifier "DM-18" ; rdfs:label "Canonical model"@en ; dcterms:description "A shared model of data exchanged between systems, independent of each system's own model."@en ; skos:notation "1.3.5.4" ; dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 1.3.5.4"@en ; edu:includesKnobit ; edu:includesKnobit ; schema:isPartOf . a edu:LearningOutcome ; dcterms:identifier "DM-19" ; rdfs:label "Views"@en ; dcterms:description "Virtual tables that simplify queries, restrict access or present data without storing it again."@en ; skos:notation "1.3.5.5" ; dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 1.3.5.5"@en ; edu:includesKnobit ; edu:includesKnobit ; schema:isPartOf . a edu:LearningOutcome ; dcterms:identifier "DM-20" ; rdfs:label "Partitioning"@en ; dcterms:description "Splitting tables vertically or horizontally, for performance or management."@en ; skos:notation "1.3.5.6" ; dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 1.3.5.6"@en ; edu:includesKnobit ; schema:isPartOf . a edu:LearningOutcome ; dcterms:identifier "DM-21" ; rdfs:label "Denormalisation"@en ; dcterms:description "Deliberately reintroducing redundancy for performance, kept consistent by a stated mechanism."@en ; skos:notation "1.3.5.7" ; dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 1.3.5.7"@en ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; schema:isPartOf . a edu:LearningOutcome ; dcterms:identifier "DM-22" ; rdfs:label "Normalisation"@en ; dcterms:description "The normal forms from first to sixth, Boyce-Codd and domain-key, and the anomalies they remove."@en ; skos:notation "1.3.6" ; dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 1.3.6"@en ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; schema:isPartOf . a edu:LearningOutcome ; dcterms:identifier "DM-23" ; rdfs:label "Abstraction"@en ; dcterms:description "Generalisation and specialisation, supertypes and subtypes, and choosing a level of abstraction."@en ; skos:notation "1.3.7" ; dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 1.3.7"@en ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; schema:isPartOf . a edu:LearningOutcome ; dcterms:identifier "DM-24" ; rdfs:label "Plan for data modelling"@en ; dcterms:description "Scope, standards and schedule of modelling work, and its deliverables - diagram, definitions, issues and open questions, lineage."@en ; skos:notation "2.1" ; dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 2.1"@en ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; schema:isPartOf . a edu:LearningOutcome ; dcterms:identifier "DM-25" ; rdfs:label "Forward engineering - conceptual data modelling"@en ; dcterms:description "Choosing a scheme and notation, collecting the highest-level concepts and activities, incorporating enterprise terminology, obtaining sign-off."@en ; skos:notation "2.2.1.1" ; dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 2.2.1.1"@en ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; schema:isPartOf . a edu:LearningOutcome ; dcterms:identifier "DM-26" ; rdfs:label "Forward engineering - logical data modelling"@en ; dcterms:description "Analysing information requirements and existing documentation, adding associative entities and attributes, assigning domains and keys."@en ; skos:notation "2.2.1.2" ; dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 2.2.1.2"@en ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; schema:isPartOf . a edu:LearningOutcome ; dcterms:identifier "DM-27" ; rdfs:label "Forward engineering - physical data modelling"@en ; dcterms:description "Resolving logical abstractions, adding attribute details and reference data objects, assigning surrogate keys, denormalising, indexing and partitioning for performance, creating views."@en ; skos:notation "2.2.1.3" ; dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 2.2.1.3"@en ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; schema:isPartOf . a edu:LearningOutcome ; dcterms:identifier "DM-28" ; rdfs:label "Reverse engineering"@en ; dcterms:description "Recovering a data model from an existing database, and forward engineering a model into DDL."@en ; skos:notation "2.2.2" ; dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 2.2.2"@en ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; schema:isPartOf . a edu:LearningOutcome ; dcterms:identifier "DM-29" ; rdfs:label "Review the data models"@en ; dcterms:description "Reviewing models with peers and stakeholders against criteria, and improving them continuously."@en ; skos:notation "2.3" ; dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 2.3"@en ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; schema:isPartOf . a edu:LearningOutcome ; dcterms:identifier "DM-30" ; rdfs:label "Maintain the data models"@en ; dcterms:description "Keeping models current as requirements and implementations change, including their lineage."@en ; skos:notation "2.4" ; dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 2.4"@en ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; schema:isPartOf . a edu:LearningOutcome ; dcterms:identifier "DM-31" ; rdfs:label "Data modelling tools"@en ; dcterms:description "Tools that draw models, hold their definitions, and forward and reverse engineer databases."@en ; skos:notation "3.1" ; dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 3.1"@en ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; schema:isPartOf . a edu:LearningOutcome ; dcterms:identifier "DM-32" ; rdfs:label "Lineage tools"@en ; dcterms:description "Tools that capture where data comes from and how it is transformed."@en ; skos:notation "3.2" ; dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 3.2"@en ; edu:includesKnobit ; schema:isPartOf . a edu:LearningOutcome ; dcterms:identifier "DM-33" ; rdfs:label "Data profiling tools"@en ; dcterms:description "Tools that examine existing data to discover its actual structure, values and rules."@en ; skos:notation "3.3" ; dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 3.3"@en ; edu:includesKnobit ; schema:isPartOf . a edu:LearningOutcome ; dcterms:identifier "DM-34" ; rdfs:label "Metadata repositories"@en ; dcterms:description "Repositories that hold models and their definitions for reuse and impact analysis."@en ; skos:notation "3.4" ; dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 3.4"@en ; edu:includesKnobit ; edu:includesKnobit ; schema:isPartOf . a edu:LearningOutcome ; dcterms:identifier "DM-35" ; rdfs:label "Data model patterns"@en ; dcterms:description "Reusable structures for recurring problems, such as party and role."@en ; skos:notation "3.5" ; dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 3.5"@en ; edu:includesKnobit ; edu:includesKnobit ; schema:isPartOf . a edu:LearningOutcome ; dcterms:identifier "DM-36" ; rdfs:label "Industry data models"@en ; dcterms:description "Prebuilt models for an industry, used as a starting point and adapted rather than adopted whole."@en ; skos:notation "3.6" ; dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 3.6"@en ; edu:includesKnobit ; edu:includesKnobit ; schema:isPartOf . a edu:LearningOutcome ; dcterms:identifier "DM-37" ; rdfs:label "Best practices in naming conventions"@en ; dcterms:description "Consistent names for model objects, built from standard parts, with agreed abbreviations."@en ; skos:notation "4.1" ; dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 4.1"@en ; edu:includesKnobit ; schema:isPartOf . a edu:LearningOutcome ; dcterms:identifier "DM-38" ; rdfs:label "Best practices in database design"@en ; dcterms:description "Designing for performance and ease of use, reusability, integrity, security and maintainability."@en ; skos:notation "4.2" ; dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 4.2"@en ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; schema:isPartOf . a edu:LearningOutcome ; dcterms:identifier "DM-39" ; rdfs:label "Develop data modelling and design standards"@en ; dcterms:description "Standards for naming, notation, definitions, deliverables and review, and how they are kept."@en ; skos:notation "5.1.1" ; dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 5.1.1"@en ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; schema:isPartOf . a edu:LearningOutcome ; dcterms:identifier "DM-40" ; rdfs:label "Review data model and database design quality"@en ; dcterms:description "Formal review of models and designs against the standards and requirements."@en ; skos:notation "5.1.2" ; dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 5.1.2"@en ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; schema:isPartOf . a edu:LearningOutcome ; dcterms:identifier "DM-41" ; rdfs:label "Manage data model versioning and integration"@en ; dcterms:description "Versioning models, recording changes, and integrating models from several sources."@en ; skos:notation "5.1.3" ; dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 5.1.3"@en ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; edu:includesKnobit ; schema:isPartOf . a edu:LearningOutcome ; dcterms:identifier "DM-42" ; rdfs:label "Data modelling metrics"@en ; dcterms:description "Measuring model quality, notably with the Data Model Scorecard and its categories."@en ; skos:notation "5.2" ; dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 5.2"@en ; edu:includesKnobit ; edu:includesKnobit ; schema:isPartOf .