@prefix dcterms: .
@prefix edu: .
@prefix knobit: .
@prefix owl: .
@prefix rdfs: .
@prefix register: .
@prefix schema: .
@prefix skos: .
a edu:LearningOutcome ;
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 ;
dcterms:identifier "DM-1" ;
dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 1.1"@en ;
skos:notation "1.1" ;
edu:includesKnobit knobit:K-901 ;
schema:isPartOf .
a edu:LearningOutcome ;
rdfs:label "Dimensional modelling scheme"@en ;
dcterms:description "Fact and dimension tables, grain, star and snowflake schemas, conformed dimensions and facts."@en ;
dcterms:identifier "DM-10" ;
dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 1.3.4.2"@en ;
skos:notation "1.3.4.2" ;
edu:includesKnobit knobit:K-659,
knobit:K-671,
knobit:K-905 ;
schema:isPartOf .
a edu:LearningOutcome ;
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 ;
dcterms:identifier "DM-11" ;
dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 1.3.4.3"@en ;
skos:notation "1.3.4.3" ;
edu:includesKnobit knobit:K-581,
knobit:K-906 ;
schema:isPartOf .
a edu:LearningOutcome ;
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 ;
dcterms:identifier "DM-12" ;
dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 1.3.4.4"@en ;
skos:notation "1.3.4.4" ;
edu:includesKnobit knobit:K-351,
knobit:K-582,
knobit:K-907 ;
schema:isPartOf .
a edu:LearningOutcome ;
rdfs:label "Time-based modelling schemes"@en ;
dcterms:description "Data Vault (hubs, links, satellites) and Anchor Modeling, which keep history by design."@en ;
dcterms:identifier "DM-13" ;
dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 1.3.4.5"@en ;
skos:notation "1.3.4.5" ;
edu:includesKnobit knobit:K-672,
knobit:K-908 ;
schema:isPartOf .
a edu:LearningOutcome ;
rdfs:label "NoSQL modelling schemes"@en ;
dcterms:description "Document, column-family, graph and key-value stores, and how modelling for them differs."@en ;
dcterms:identifier "DM-14" ;
dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 1.3.4.6"@en ;
skos:notation "1.3.4.6" ;
edu:includesKnobit knobit:K-673,
knobit:K-909 ;
schema:isPartOf .
a edu:LearningOutcome ;
rdfs:label "Conceptual data model"@en ;
dcterms:description "High-level concepts and their relationships, in the business's terms, independent of technology."@en ;
dcterms:identifier "DM-15" ;
dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 1.3.5.1"@en ;
skos:notation "1.3.5.1" ;
edu:includesKnobit knobit:K-253,
knobit:K-422,
knobit:K-451,
knobit:K-570 ;
schema:isPartOf .
a edu:LearningOutcome ;
rdfs:label "Logical data model"@en ;
dcterms:description "Entities, attributes, keys and relationships in detail, normalised, independent of a platform."@en ;
dcterms:identifier "DM-16" ;
dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 1.3.5.2"@en ;
skos:notation "1.3.5.2" ;
edu:includesKnobit knobit:K-532,
knobit:K-551,
knobit:K-552,
knobit:K-556,
knobit:K-562,
knobit:K-567 ;
schema:isPartOf .
a edu:LearningOutcome ;
rdfs:label "Physical data model"@en ;
dcterms:description "The design for a particular platform - tables, columns, types, keys, constraints and indexes."@en ;
dcterms:identifier "DM-17" ;
dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 1.3.5.3"@en ;
skos:notation "1.3.5.3" ;
edu:includesKnobit knobit:K-617,
knobit:K-652,
knobit:K-653,
knobit:K-654,
knobit:K-657 ;
schema:isPartOf .
a edu:LearningOutcome ;
rdfs:label "Canonical model"@en ;
dcterms:description "A shared model of data exchanged between systems, independent of each system's own model."@en ;
dcterms:identifier "DM-18" ;
dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 1.3.5.4"@en ;
skos:notation "1.3.5.4" ;
edu:includesKnobit knobit:K-583,
knobit:K-910 ;
schema:isPartOf .
a edu:LearningOutcome ;
rdfs:label "Views"@en ;
dcterms:description "Virtual tables that simplify queries, restrict access or present data without storing it again."@en ;
dcterms:identifier "DM-19" ;
dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 1.3.5.5"@en ;
skos:notation "1.3.5.5" ;
edu:includesKnobit knobit:K-674,
knobit:K-911 ;
schema:isPartOf .
a edu:LearningOutcome ;
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 ;
dcterms:identifier "DM-2" ;
dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 1.2"@en ;
skos:notation "1.2" ;
edu:includesKnobit knobit:K-901 ;
schema:isPartOf .
a edu:LearningOutcome ;
rdfs:label "Partitioning"@en ;
dcterms:description "Splitting tables vertically or horizontally, for performance or management."@en ;
dcterms:identifier "DM-20" ;
dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 1.3.5.6"@en ;
skos:notation "1.3.5.6" ;
edu:includesKnobit knobit:K-660 ;
schema:isPartOf .
a edu:LearningOutcome ;
rdfs:label "Denormalisation"@en ;
dcterms:description "Deliberately reintroducing redundancy for performance, kept consistent by a stated mechanism."@en ;
dcterms:identifier "DM-21" ;
dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 1.3.5.7"@en ;
skos:notation "1.3.5.7" ;
edu:includesKnobit knobit:K-565,
knobit:K-601,
knobit:K-651 ;
schema:isPartOf .
a edu:LearningOutcome ;
rdfs:label "Normalisation"@en ;
dcterms:description "The normal forms from first to sixth, Boyce-Codd and domain-key, and the anomalies they remove."@en ;
dcterms:identifier "DM-22" ;
dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 1.3.6"@en ;
skos:notation "1.3.6" ;
edu:includesKnobit knobit:K-553,
knobit:K-554,
knobit:K-555,
knobit:K-556,
knobit:K-557,
knobit:K-558,
knobit:K-559,
knobit:K-560,
knobit:K-561 ;
schema:isPartOf .
a edu:LearningOutcome ;
rdfs:label "Abstraction"@en ;
dcterms:description "Generalisation and specialisation, supertypes and subtypes, and choosing a level of abstraction."@en ;
dcterms:identifier "DM-23" ;
dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 1.3.7"@en ;
skos:notation "1.3.7" ;
edu:includesKnobit knobit:K-451,
knobit:K-566,
knobit:K-652 ;
schema:isPartOf .
a edu:LearningOutcome ;
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 ;
dcterms:identifier "DM-24" ;
dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 2.1"@en ;
skos:notation "2.1" ;
edu:includesKnobit knobit:K-001,
knobit:K-004,
knobit:K-031,
knobit:K-119,
knobit:K-130,
knobit:K-912 ;
schema:isPartOf .
a edu:LearningOutcome ;
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 ;
dcterms:identifier "DM-25" ;
dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 2.2.1.1"@en ;
skos:notation "2.2.1.1" ;
edu:includesKnobit knobit:K-032,
knobit:K-422,
knobit:K-456,
knobit:K-913 ;
schema:isPartOf .
a edu:LearningOutcome ;
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 ;
dcterms:identifier "DM-26" ;
dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 2.2.1.2"@en ;
skos:notation "2.2.1.2" ;
edu:includesKnobit knobit:K-151,
knobit:K-532,
knobit:K-534,
knobit:K-562,
knobit:K-568 ;
schema:isPartOf .
a edu:LearningOutcome ;
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 ;
dcterms:identifier "DM-27" ;
dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 2.2.1.3"@en ;
skos:notation "2.2.1.3" ;
edu:includesKnobit knobit:K-610,
knobit:K-617,
knobit:K-651,
knobit:K-652,
knobit:K-656,
knobit:K-657,
knobit:K-660,
knobit:K-911 ;
schema:isPartOf .
a edu:LearningOutcome ;
rdfs:label "Reverse engineering"@en ;
dcterms:description "Recovering a data model from an existing database, and forward engineering a model into DDL."@en ;
dcterms:identifier "DM-28" ;
dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 2.2.2"@en ;
skos:notation "2.2.2" ;
edu:includesKnobit knobit:K-1101,
knobit:K-1102,
knobit:K-1103,
knobit:K-1104,
knobit:K-1105,
knobit:K-1106,
knobit:K-1131,
knobit:K-914 ;
schema:isPartOf .
a edu:LearningOutcome ;
rdfs:label "Review the data models"@en ;
dcterms:description "Reviewing models with peers and stakeholders against criteria, and improving them continuously."@en ;
dcterms:identifier "DM-29" ;
dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 2.3"@en ;
skos:notation "2.3" ;
edu:includesKnobit knobit:K-1001,
knobit:K-1002,
knobit:K-1004,
knobit:K-1006,
knobit:K-1031,
knobit:K-531,
knobit:K-915 ;
schema:isPartOf .
a edu:LearningOutcome ;
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 ;
dcterms:identifier "DM-3" ;
dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 1.3.1"@en ;
skos:notation "1.3.1" ;
edu:includesKnobit knobit:K-901 ;
schema:isPartOf .
a edu:LearningOutcome ;
rdfs:label "Maintain the data models"@en ;
dcterms:description "Keeping models current as requirements and implementations change, including their lineage."@en ;
dcterms:identifier "DM-30" ;
dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 2.4"@en ;
skos:notation "2.4" ;
edu:includesKnobit knobit:K-1201,
knobit:K-1202,
knobit:K-1204,
knobit:K-1231,
knobit:K-802,
knobit:K-826,
knobit:K-916 ;
schema:isPartOf .
a edu:LearningOutcome ;
rdfs:label "Data modelling tools"@en ;
dcterms:description "Tools that draw models, hold their definitions, and forward and reverse engineer databases."@en ;
dcterms:identifier "DM-31" ;
dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 3.1"@en ;
skos:notation "3.1" ;
edu:includesKnobit knobit:K-034,
knobit:K-914,
knobit:K-917 ;
schema:isPartOf .
a edu:LearningOutcome ;
rdfs:label "Lineage tools"@en ;
dcterms:description "Tools that capture where data comes from and how it is transformed."@en ;
dcterms:identifier "DM-32" ;
dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 3.2"@en ;
skos:notation "3.2" ;
edu:includesKnobit knobit:K-917 ;
schema:isPartOf .
a edu:LearningOutcome ;
rdfs:label "Data profiling tools"@en ;
dcterms:description "Tools that examine existing data to discover its actual structure, values and rules."@en ;
dcterms:identifier "DM-33" ;
dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 3.3"@en ;
skos:notation "3.3" ;
edu:includesKnobit knobit:K-917 ;
schema:isPartOf .
a edu:LearningOutcome ;
rdfs:label "Metadata repositories"@en ;
dcterms:description "Repositories that hold models and their definitions for reuse and impact analysis."@en ;
dcterms:identifier "DM-34" ;
dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 3.4"@en ;
skos:notation "3.4" ;
edu:includesKnobit knobit:K-034,
knobit:K-917 ;
schema:isPartOf .
a edu:LearningOutcome ;
rdfs:label "Data model patterns"@en ;
dcterms:description "Reusable structures for recurring problems, such as party and role."@en ;
dcterms:identifier "DM-35" ;
dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 3.5"@en ;
skos:notation "3.5" ;
edu:includesKnobit knobit:K-421,
knobit:K-918 ;
schema:isPartOf .
a edu:LearningOutcome ;
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 ;
dcterms:identifier "DM-36" ;
dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 3.6"@en ;
skos:notation "3.6" ;
edu:includesKnobit knobit:K-458,
knobit:K-918 ;
schema:isPartOf .
a edu:LearningOutcome ;
rdfs:label "Best practices in naming conventions"@en ;
dcterms:description "Consistent names for model objects, built from standard parts, with agreed abbreviations."@en ;
dcterms:identifier "DM-37" ;
dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 4.1"@en ;
skos:notation "4.1" ;
edu:includesKnobit knobit:K-919 ;
schema:isPartOf .
a edu:LearningOutcome ;
rdfs:label "Best practices in database design"@en ;
dcterms:description "Designing for performance and ease of use, reusability, integrity, security and maintainability."@en ;
dcterms:identifier "DM-38" ;
dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 4.2"@en ;
skos:notation "4.2" ;
edu:includesKnobit knobit:K-033,
knobit:K-653,
knobit:K-657,
knobit:K-856,
knobit:K-920 ;
schema:isPartOf .
a edu:LearningOutcome ;
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 ;
dcterms:identifier "DM-39" ;
dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 5.1.1"@en ;
skos:notation "5.1.1" ;
edu:includesKnobit knobit:K-002,
knobit:K-033,
knobit:K-919,
knobit:K-921 ;
schema:isPartOf .
a edu:LearningOutcome ;
rdfs:label "Types of data that are modelled"@en ;
dcterms:description "Category, resource, business event and detail transaction data."@en ;
dcterms:identifier "DM-4" ;
dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 1.3.2"@en ;
skos:notation "1.3.2" ;
edu:includesKnobit knobit:K-902 ;
schema:isPartOf .
a edu:LearningOutcome ;
rdfs:label "Review data model and database design quality"@en ;
dcterms:description "Formal review of models and designs against the standards and requirements."@en ;
dcterms:identifier "DM-40" ;
dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 5.1.2"@en ;
skos:notation "5.1.2" ;
edu:includesKnobit knobit:K-1003,
knobit:K-1005,
knobit:K-1031,
knobit:K-915 ;
schema:isPartOf .
a edu:LearningOutcome ;
rdfs:label "Manage data model versioning and integration"@en ;
dcterms:description "Versioning models, recording changes, and integrating models from several sources."@en ;
dcterms:identifier "DM-41" ;
dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 5.1.3"@en ;
skos:notation "5.1.3" ;
edu:includesKnobit knobit:K-1007,
knobit:K-1203,
knobit:K-1205,
knobit:K-1206,
knobit:K-1231,
knobit:K-826,
knobit:K-916 ;
schema:isPartOf .
a edu:LearningOutcome ;
rdfs:label "Data modelling metrics"@en ;
dcterms:description "Measuring model quality, notably with the Data Model Scorecard and its categories."@en ;
dcterms:identifier "DM-42" ;
dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 5.2"@en ;
skos:notation "5.2" ;
edu:includesKnobit knobit:K-1031,
knobit:K-915 ;
schema:isPartOf .
a edu:LearningOutcome ;
rdfs:label "Entity"@en ;
dcterms:description "The thing about which data is kept; its aliases across schemes, its graphic representation and its definition."@en ;
dcterms:identifier "DM-5" ;
dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 1.3.3.1"@en ;
skos:notation "1.3.3.1" ;
edu:includesKnobit knobit:K-251,
knobit:K-570,
knobit:K-903 ;
schema:isPartOf .
a edu:LearningOutcome ;
rdfs:label "Relationship"@en ;
dcterms:description "Associations between entities; their aliases and notation, cardinality and optionality, arity (unary, binary, ternary) and foreign keys."@en ;
dcterms:identifier "DM-6" ;
dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 1.3.3.2"@en ;
skos:notation "1.3.3.2" ;
edu:includesKnobit knobit:K-559,
knobit:K-567,
knobit:K-653,
knobit:K-903 ;
schema:isPartOf .
a edu:LearningOutcome ;
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 ;
dcterms:identifier "DM-7" ;
dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 1.3.3.3"@en ;
skos:notation "1.3.3.3" ;
edu:includesKnobit knobit:K-552,
knobit:K-568,
knobit:K-904 ;
schema:isPartOf .
a edu:LearningOutcome ;
rdfs:label "Domain"@en ;
dcterms:description "The set of values an attribute may take, defined by data type, format, list, range or rule."@en ;
dcterms:identifier "DM-8" ;
dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 1.3.3.4"@en ;
skos:notation "1.3.3.4" ;
edu:includesKnobit knobit:K-562 ;
schema:isPartOf .
a edu:LearningOutcome ;
rdfs:label "Relational modelling scheme"@en ;
dcterms:description "Relations, keys and normalisation as a modelling scheme, and its notations."@en ;
dcterms:identifier "DM-9" ;
dcterms:source "DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design, 1.3.4.1"@en ;
skos:notation "1.3.4.1" ;
edu:includesKnobit knobit:K-551,
knobit:K-552,
knobit:K-903 ;
schema:isPartOf .
a edu:Question ;
rdfs:label "dm-knowledge-requirements Q1: singular and unambiguous data requirement statements"@en ;
dcterms:identifier "I-1001" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-151 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-requirements Q2: business requirement versus design solution"@en ;
dcterms:identifier "I-1002" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-152 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-requirements Q3: requirement type of a load timeliness expectation"@en ;
dcterms:identifier "I-1003" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-153 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-requirements Q4: purpose of requirement attributes and trace"@en ;
dcterms:identifier "I-1004" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-154 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-requirements Q5: point-in-time reproducibility of a published report"@en ;
dcterms:identifier "I-1005" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-155 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-requirements Q6: identity of a business thing such as a debit card"@en ;
dcterms:identifier "I-1006" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-156 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-requirements Q7: retention among the non-functional data concerns"@en ;
dcterms:identifier "I-1007" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-157 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-requirements Q8: questions a data requirements register must serve"@en ;
dcterms:identifier "I-1008" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-158 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-requirements Q9: and-or ambiguity in a requirement statement"@en ;
dcterms:identifier "I-1009" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-159 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "data-requirements C1a: identity gap named"@en ;
dcterms:identifier "I-101" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-127 ] ;
schema:isPartOf register:data-modelling,
.
a edu:Question ;
rdfs:label "dm-knowledge-requirements Q10: persistent identifier of a superseded requirement"@en ;
dcterms:identifier "I-1010" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-160 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-requirements Q11: what makes a data quality requirement verifiable"@en ;
dcterms:identifier "I-1011" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-161 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-requirements Q12: conflicting requirements in a register"@en ;
dcterms:identifier "I-1012" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-162 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-conceptual Q1: intensional definition of savings account"@en ;
dcterms:identifier "I-1013" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-251 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-conceptual Q2: generic versus partitive concept relations"@en ;
dcterms:identifier "I-1014" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-253 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-conceptual Q3: SBVR fact type and rule statement"@en ;
dcterms:identifier "I-1015" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-351 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-conceptual Q4: data rules in Witt's business rule classification"@en ;
dcterms:identifier "I-1016" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-355 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-conceptual Q5: rule enforcement on a platform that does not enforce keys"@en ;
dcterms:identifier "I-1017" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-356 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-conceptual Q6: all-and-some test for a hierarchical link"@en ;
dcterms:identifier "I-1018" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-451 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-conceptual Q7: history note for a changed node meaning"@en ;
dcterms:identifier "I-1019" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-452 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "data-requirements C1b: access gap named"@en ;
dcterms:identifier "I-102" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-129 ] ;
schema:isPartOf register:data-modelling,
.
a edu:Question ;
rdfs:label "dm-knowledge-conceptual Q8: warrant for a proposed vocabulary node"@en ;
dcterms:identifier "I-1020" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-453 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-conceptual Q9: label form conventions for card type labels"@en ;
dcterms:identifier "I-1021" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-454 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-conceptual Q10: one characteristic of division per sibling array"@en ;
dcterms:identifier "I-1022" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-455 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-conceptual Q11: equivalence relation and preferred term"@en ;
dcterms:identifier "I-1023" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-456 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-conceptual Q12: associative relation between lending concepts"@en ;
dcterms:identifier "I-1024" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-457 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-conceptual Q13: reusing an external payment purpose code set"@en ;
dcterms:identifier "I-1025" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-458 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-logical Q1: functional dependency between card and account"@en ;
dcterms:identifier "I-1026" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-551 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-logical Q2: candidate keys and prime attributes of an account holding"@en ;
dcterms:identifier "I-1027" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-552 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "short_answer" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-logical Q3: deletion anomaly in a loan application entity"@en ;
dcterms:identifier "I-1028" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-553 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-logical Q4: first normal form and atomic values"@en ;
dcterms:identifier "I-1029" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-554 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "data-requirements C1c: lineage gap named"@en ;
dcterms:identifier "I-103" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-130 ] ;
schema:isPartOf register:data-modelling,
.
a edu:Question ;
rdfs:label "dm-knowledge-logical Q5: second normal form and partial dependency"@en ;
dcterms:identifier "I-1030" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-555 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-logical Q6: third normal form and transitive dependency"@en ;
dcterms:identifier "I-1031" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-556 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-logical Q7: Boyce-Codd normal form with overlapping keys"@en ;
dcterms:identifier "I-1032" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-557 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-logical Q8: independent multivalued facts and fourth normal form"@en ;
dcterms:identifier "I-1033" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-558 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-logical Q9: join dependency and fifth normal form"@en ;
dcterms:identifier "I-1034" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-559 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-logical Q10: sixth normal form for independently changing attributes"@en ;
dcterms:identifier "I-1035" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-560 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-logical Q11: constraints implied by keys and domains"@en ;
dcterms:identifier "I-1036" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-561 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-logical Q12: one domain per attribute"@en ;
dcterms:identifier "I-1037" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-562 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-logical Q13: lossless-join decomposition of a payment entity"@en ;
dcterms:identifier "I-1038" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-563 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-logical Q14: dependency preservation in a BCNF decomposition"@en ;
dcterms:identifier "I-1039" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-564 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "data-requirements C1d: history gap named"@en ;
dcterms:identifier "I-104" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-131 ] ;
schema:isPartOf register:data-modelling,
.
a edu:Question ;
rdfs:label "dm-knowledge-logical Q15: snapshot value versus derivable value"@en ;
dcterms:identifier "I-1040" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-565 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-logical Q16: disjoint and partial subtyping of accounts"@en ;
dcterms:identifier "I-1041" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-566 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-logical Q17: cardinality and optionality of account and card"@en ;
dcterms:identifier "I-1042" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-567 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-logical Q18: natural key kept beside a surrogate key"@en ;
dcterms:identifier "I-1043" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-568 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-logical Q19: chasm trap on an optional relationship path"@en ;
dcterms:identifier "I-1044" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-569 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-logical Q20: one entity type per business concept"@en ;
dcterms:identifier "I-1045" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-570 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-physical Q1: what makes a denormalisation controlled"@en ;
dcterms:identifier "I-1046" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-651 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-physical Q2: constraints lost by rolling up subtypes"@en ;
dcterms:identifier "I-1047" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-652 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-physical Q3: referential action for payments referencing an account"@en ;
dcterms:identifier "I-1048" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-653 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-physical Q4: exact decimal type for a euro balance"@en ;
dcterms:identifier "I-1049" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-654 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "data-requirements C1e: no question the data serves named"@en ;
dcterms:identifier "I-105" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-132 ] ;
schema:isPartOf register:data-modelling,
.
a edu:Question ;
rdfs:label "dm-knowledge-physical Q5: null and three-valued logic in a predicate"@en ;
dcterms:identifier "I-1050" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-655 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-physical Q6: changeable value set held as reference data"@en ;
dcterms:identifier "I-1051" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-656 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-physical Q7: deriving indexes from access paths"@en ;
dcterms:identifier "I-1052" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-657 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-physical Q8: half-open validity periods in a versioned table"@en ;
dcterms:identifier "I-1053" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-658 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-physical Q9: semi-additive month-end balance measure"@en ;
dcterms:identifier "I-1054" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-659 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-physical Q10: vertical split that keeps one entity"@en ;
dcterms:identifier "I-1055" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-660 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-physical Q11: consistency risk of documents stored by reference"@en ;
dcterms:identifier "I-1056" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-661 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-physical Q12: no meaning in relational row or key order"@en ;
dcterms:identifier "I-1057" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-662 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-physical Q13: where to fix a defect in generated DDL"@en ;
dcterms:identifier "I-1058" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-851 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-physical Q14: one logical type rendering differently by SQL engine"@en ;
dcterms:identifier "I-1059" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-852 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "data-requirements C1f: volume and retention gap named"@en ;
dcterms:identifier "I-106" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-128 ] ;
schema:isPartOf register:data-modelling,
.
a edu:Question ;
rdfs:label "dm-knowledge-physical Q15: currency minor units and amount scale"@en ;
dcterms:identifier "I-1060" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-853 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-physical Q16: event timestamps and business dates"@en ;
dcterms:identifier "I-1061" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-854 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-physical Q17: collation and the meaning of a key"@en ;
dcterms:identifier "I-1062" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-855 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-physical Q18: access design derived from data classification"@en ;
dcterms:identifier "I-1063" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-856 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-physical Q19: adding a mandatory column to a populated table"@en ;
dcterms:identifier "I-1064" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-857 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-physical Q20: one artefact for every deployment environment"@en ;
dcterms:identifier "I-1065" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-858 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-physical Q21: proving DDL by execution and detecting drift"@en ;
dcterms:identifier "I-1066" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-859 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-dmbok-ch5 Q1: purpose of building a data model"@en ;
dcterms:identifier "I-1067" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-901 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-dmbok-ch5 Q2: DMBOK type of modelled data for a loan application"@en ;
dcterms:identifier "I-1068" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-902 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-dmbok-ch5 Q3: zero-or-many in Information Engineering notation"@en ;
dcterms:identifier "I-1069" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-903 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "data-requirements C2a: duplicate retired, not deleted"@en ;
dcterms:identifier "I-107" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-121,
knobit:K-135 ] ;
schema:isPartOf register:data-modelling,
.
a edu:Question ;
rdfs:label "dm-knowledge-dmbok-ch5 Q4: identifying relationship for repayment instalments"@en ;
dcterms:identifier "I-1070" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-904 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-dmbok-ch5 Q5: conformed dimensions across banking star schemas"@en ;
dcterms:identifier "I-1071" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-905 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-dmbok-ch5 Q6: UML class diagram versus entity-relationship model"@en ;
dcterms:identifier "I-1072" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-906 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-dmbok-ch5 Q7: elementary facts in fact-based modelling"@en ;
dcterms:identifier "I-1073" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-907 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-dmbok-ch5 Q8: hubs, links and satellites in a Data Vault"@en ;
dcterms:identifier "I-1074" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-908 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-dmbok-ch5 Q9: aggregate-oriented modelling in a document store"@en ;
dcterms:identifier "I-1075" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-909 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .
a edu:Question ;
rdfs:label "dm-knowledge-dmbok-ch5 Q10: canonical data model for system integration"@en ;
dcterms:identifier "I-1076" ;
edu:solvableWith [ a edu:KnobitSet ;
edu:memberKnobit knobit:K-910 ] ;
schema:isPartOf register:data-modelling,
;
schema:learningResourceType "multiple_choice" ;
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 .