Data modelling (DAMA-DMBOK2)

https://knobit.org/id/register/data-modelling

LCG purposes	Assessing the learner's knowledge or skill state
LCG purposes	Opening up a learning outcome
LCG purposes	Selecting an assessment task or learning activity
conforms to profile	https://oppekava.edu.ee/a/Knobitite_kirjeldamise_ja_seostamise_reeglid#LCG-KNOBIT-0.1
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
dcterms:identifier	SCOPE-1
dcterms:license	https://creativecommons.org/licenses/by/4.0/
dcterms:rights	Copyright 2026 Peep Küngas. Licensed under CC BY 4.0.
dcterms:title	Data modelling (DAMA-DMBOK2) en
owl:sameAs	https://bitbucket.org/reffa/ontology/skills/data-modelling
schema:license	https://creativecommons.org/licenses/by/4.0/
skos:note	audience: Data modellers, and AI models assessed by skill-tests 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

Items and references

Business drivers for data modelling edu:LearningOutcome

https://knobit.org/id/register/data-modelling#DM-1

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
includes knobit	Explains what data models are and why organisations build them
rdfs:label	Business drivers for data modelling en
schema:isPartOf	DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design
skos:notation	1.1

Dimensional modelling scheme edu:LearningOutcome

https://knobit.org/id/register/data-modelling#DM-10

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
includes knobit	Explains grain and additivity in dimensional models
includes knobit	Designs a star schema for a stated grain
includes knobit	Explains dimensional modelling
rdfs:label	Dimensional modelling scheme en
schema:isPartOf	DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design
skos:notation	1.3.4.2

Object-oriented modelling scheme (UML) edu:LearningOutcome

https://knobit.org/id/register/data-modelling#DM-11

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
includes knobit	Expresses a logical model as a UML class diagram
includes knobit	Explains UML class diagrams as a data modelling scheme
rdfs:label	Object-oriented modelling scheme (UML) en
schema:isPartOf	DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design
skos:notation	1.3.4.3

Fact-based modelling scheme edu:LearningOutcome

https://knobit.org/id/register/data-modelling#DM-12

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
includes knobit	Explains SBVR fact types and rule statements
includes knobit	Models data as fact types in a fact-based scheme
includes knobit	Explains fact-based modelling
rdfs:label	Fact-based modelling scheme en
schema:isPartOf	DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design
skos:notation	1.3.4.4

Time-based modelling schemes edu:LearningOutcome

https://knobit.org/id/register/data-modelling#DM-13

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
includes knobit	Designs a Data Vault model for auditable history
includes knobit	Explains time-based modelling schemes
rdfs:label	Time-based modelling schemes en
schema:isPartOf	DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design
skos:notation	1.3.4.5

NoSQL modelling schemes edu:LearningOutcome

https://knobit.org/id/register/data-modelling#DM-14

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
includes knobit	Designs a document structure for a stated access pattern
includes knobit	Explains NoSQL data modelling schemes
rdfs:label	NoSQL modelling schemes en
schema:isPartOf	DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design
skos:notation	1.3.4.6

Conceptual data model edu:LearningOutcome

https://knobit.org/id/register/data-modelling#DM-15

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
includes knobit	Explains generic and partitive concept relations
includes knobit	Derives the broader concept from the head of a definition
includes knobit	Explains hierarchical relations and the all-and-some test
includes knobit	Explains an entity type as the realisation of one business concept
rdfs:label	Conceptual data model en
schema:isPartOf	DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design
skos:notation	1.3.5.1

Logical data model edu:LearningOutcome

https://knobit.org/id/register/data-modelling#DM-16

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
includes knobit	Records the functional dependencies of an entity
includes knobit	Explains functional dependency
includes knobit	Explains candidate key and prime attribute
includes knobit	Explains third normal form
includes knobit	Explains attribute domains
includes knobit	Explains relationship cardinality and optionality
rdfs:label	Logical data model en
schema:isPartOf	DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design
skos:notation	1.3.5.2

Physical data model edu:LearningOutcome

https://knobit.org/id/register/data-modelling#DM-17

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
includes knobit	Recognises a physical domain differing from the logical domain
includes knobit	Explains the implementation options for subtypes
includes knobit	Explains referential integrity and referential actions
includes knobit	Explains exact and approximate numeric types
includes knobit	Explains index design from access paths
rdfs:label	Physical data model en
schema:isPartOf	DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design
skos:notation	1.3.5.3

Canonical model edu:LearningOutcome

https://knobit.org/id/register/data-modelling#DM-18

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
includes knobit	Maps an application model onto a canonical model
includes knobit	Explains canonical data models
rdfs:label	Canonical model en
schema:isPartOf	DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design
skos:notation	1.3.5.4

Views edu:LearningOutcome

https://knobit.org/id/register/data-modelling#DM-19

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
includes knobit	Designs views hiding physical structure from consumers
includes knobit	Explains views in physical design
rdfs:label	Views en
schema:isPartOf	DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design
skos:notation	1.3.5.5

Goals and principles of data modelling edu:LearningOutcome

https://knobit.org/id/register/data-modelling#DM-2

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
includes knobit	Explains what data models are and why organisations build them
rdfs:label	Goals and principles of data modelling en
schema:isPartOf	DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design
skos:notation	1.2

Partitioning edu:LearningOutcome

https://knobit.org/id/register/data-modelling#DM-20

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
includes knobit	Explains vertical and horizontal partitioning of tables
rdfs:label	Partitioning en
schema:isPartOf	DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design
skos:notation	1.3.5.6

Denormalisation edu:LearningOutcome

https://knobit.org/id/register/data-modelling#DM-21

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
includes knobit	Explains derived data and point-in-time snapshots
includes knobit	Recognises an unmanaged duplicate column
includes knobit	Explains controlled denormalisation
rdfs:label	Denormalisation en
schema:isPartOf	DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design
skos:notation	1.3.5.7

Normalisation edu:LearningOutcome

https://knobit.org/id/register/data-modelling#DM-22

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
includes knobit	Explains the insertion, update and deletion anomalies
includes knobit	Explains first normal form
includes knobit	Explains second normal form
includes knobit	Explains third normal form
includes knobit	Explains Boyce-Codd normal form
includes knobit	Explains multivalued dependency and fourth normal form
includes knobit	Explains join dependency and fifth normal form
includes knobit	Explains sixth normal form for temporal data
includes knobit	Explains domain-key normal form
rdfs:label	Normalisation en
schema:isPartOf	DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design
skos:notation	1.3.6

Abstraction edu:LearningOutcome

https://knobit.org/id/register/data-modelling#DM-23

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
includes knobit	Explains hierarchical relations and the all-and-some test
includes knobit	Explains supertype and subtype constraints
includes knobit	Explains the implementation options for subtypes
rdfs:label	Abstraction en
schema:isPartOf	DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design
skos:notation	1.3.7

Plan for data modelling edu:LearningOutcome

https://knobit.org/id/register/data-modelling#DM-24

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
includes knobit	Recognises a modelling scope with no boundary
includes knobit	Recognises model inputs the plan does not locate
includes knobit	Plans the deliverables of a modelling assignment
includes knobit	Recognises a guess recorded as fact
includes knobit	Recognises an uncovered lineage requirement
includes knobit	Explains the planning of data modelling work
rdfs:label	Plan for data modelling en
schema:isPartOf	DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design
skos:notation	2.1

Forward engineering - conceptual data modelling edu:LearningOutcome

https://knobit.org/id/register/data-modelling#DM-25

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
includes knobit	Chooses a modelling scheme and notation for an audience and purpose
includes knobit	Derives the broader concept from the head of a definition
includes knobit	Explains equivalence relations and preferred terms
includes knobit	Explains how to choose a modelling scheme and notation
rdfs:label	Forward engineering - conceptual data modelling en
schema:isPartOf	DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design
skos:notation	2.2.1.1

Forward engineering - logical data modelling edu:LearningOutcome

https://knobit.org/id/register/data-modelling#DM-26

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
includes knobit	Explains singular and unambiguous requirement statements
includes knobit	Records the functional dependencies of an entity
includes knobit	Resolves a many-to-many relationship into an associative entity
includes knobit	Explains attribute domains
includes knobit	Explains natural keys, surrogate keys and key stability
rdfs:label	Forward engineering - logical data modelling en
schema:isPartOf	DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design
skos:notation	2.2.1.2

Forward engineering - physical data modelling edu:LearningOutcome

https://knobit.org/id/register/data-modelling#DM-27

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
includes knobit	Recognises a surrogate key without natural-key uniqueness
includes knobit	Recognises a physical domain differing from the logical domain
includes knobit	Explains controlled denormalisation
includes knobit	Explains the implementation options for subtypes
includes knobit	Explains value sets held as reference data
includes knobit	Explains index design from access paths
includes knobit	Explains vertical and horizontal partitioning of tables
includes knobit	Explains views in physical design
rdfs:label	Forward engineering - physical data modelling en
schema:isPartOf	DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design
skos:notation	2.2.1.3

Reverse engineering edu:LearningOutcome

https://knobit.org/id/register/data-modelling#DM-28

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
includes knobit	Recognises an inferred structure presented as declared
includes knobit	Recognises reverse-engineered objects not marked as-is
includes knobit	Recognises a dead database object carried into the model
includes knobit	Recognises a guessed meaning written as a definition
includes knobit	Recognises a reverse-engineering source with no environment or date
includes knobit	Recognises a physical workaround lifted into the logical model
includes knobit	Reverse-engineers a logical model from a database schema
includes knobit	Explains forward and reverse engineering of data models
rdfs:label	Reverse engineering en
schema:isPartOf	DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design
skos:notation	2.2.2

Review the data models edu:LearningOutcome

https://knobit.org/id/register/data-modelling#DM-29

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
includes knobit	Recognises an incomplete data model scorecard
includes knobit	Recognises a scorecard score with no evidence
includes knobit	Recognises a review decision contradicting its total
includes knobit	Recognises a scorecard score contradicting the validator
includes knobit	Scores a data model against the Data Model Scorecard
includes knobit	Traces a logical-model anomaly to its structural cause
includes knobit	Explains data model review and the Data Model Scorecard
rdfs:label	Review the data models en
schema:isPartOf	DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design
skos:notation	2.3

Data modelling and data models edu:LearningOutcome

https://knobit.org/id/register/data-modelling#DM-3

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
includes knobit	Explains what data models are and why organisations build them
rdfs:label	Data modelling and data models en
schema:isPartOf	DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design
skos:notation	1.3.1

Maintain the data models edu:LearningOutcome

https://knobit.org/id/register/data-modelling#DM-30

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
includes knobit	Recognises a model change with no reason
includes knobit	Recognises a model change with no impact analysis
includes knobit	Recognises a change to a deployed structure with no migration
includes knobit	Releases a model change as a new model version
includes knobit	Recognises DDL older than its model
includes knobit	Recognises undetected drift between database and model
includes knobit	Explains data model versioning and change management
rdfs:label	Maintain the data models en
schema:isPartOf	DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design
skos:notation	2.4

Data modelling tools edu:LearningOutcome

https://knobit.org/id/register/data-modelling#DM-31

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
includes knobit	Selects the tools and repository for a modelling project
includes knobit	Explains forward and reverse engineering of data models
includes knobit	Explains the tools supporting data modelling
rdfs:label	Data modelling tools en
schema:isPartOf	DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design
skos:notation	3.1

Lineage tools edu:LearningOutcome

https://knobit.org/id/register/data-modelling#DM-32

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
includes knobit	Explains the tools supporting data modelling
rdfs:label	Lineage tools en
schema:isPartOf	DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design
skos:notation	3.2

Data profiling tools edu:LearningOutcome

https://knobit.org/id/register/data-modelling#DM-33

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
includes knobit	Explains the tools supporting data modelling
rdfs:label	Data profiling tools en
schema:isPartOf	DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design
skos:notation	3.3

Metadata repositories edu:LearningOutcome

https://knobit.org/id/register/data-modelling#DM-34

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
includes knobit	Selects the tools and repository for a modelling project
includes knobit	Explains the tools supporting data modelling
rdfs:label	Metadata repositories en
schema:isPartOf	DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design
skos:notation	3.4

Data model patterns edu:LearningOutcome

https://knobit.org/id/register/data-modelling#DM-35

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
includes knobit	Models a role as an association to the party playing it
includes knobit	Explains data model patterns and industry data models
rdfs:label	Data model patterns en
schema:isPartOf	DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design
skos:notation	3.5

Industry data models edu:LearningOutcome

https://knobit.org/id/register/data-modelling#DM-36

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
includes knobit	Explains reuse of external vocabularies
includes knobit	Explains data model patterns and industry data models
rdfs:label	Industry data models en
schema:isPartOf	DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design
skos:notation	3.6

Best practices in naming conventions edu:LearningOutcome

https://knobit.org/id/register/data-modelling#DM-37

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
includes knobit	Explains naming conventions for data model objects
rdfs:label	Best practices in naming conventions en
schema:isPartOf	DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design
skos:notation	4.1

Best practices in database design edu:LearningOutcome

https://knobit.org/id/register/data-modelling#DM-38

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
includes knobit	Sets the modelling standards a project follows
includes knobit	Explains referential integrity and referential actions
includes knobit	Explains index design from access paths
includes knobit	Explains access design for classified data
includes knobit	Explains database design principles
rdfs:label	Best practices in database design en
schema:isPartOf	DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design
skos:notation	4.2

Develop data modelling and design standards edu:LearningOutcome

https://knobit.org/id/register/data-modelling#DM-39

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
includes knobit	Recognises a modelling standard named but not chosen
includes knobit	Sets the modelling standards a project follows
includes knobit	Explains naming conventions for data model objects
includes knobit	Explains data modelling and design standards
rdfs:label	Develop data modelling and design standards en
schema:isPartOf	DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design
skos:notation	5.1.1

Types of data that are modelled edu:LearningOutcome

https://knobit.org/id/register/data-modelling#DM-4

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
includes knobit	Explains the types of modelled data
rdfs:label	Types of data that are modelled en
schema:isPartOf	DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design
skos:notation	1.3.2

Review data model and database design quality edu:LearningOutcome

https://knobit.org/id/register/data-modelling#DM-40

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
includes knobit	Recognises a model reviewed by its modeller
includes knobit	Recognises a review finding with no owner or action
includes knobit	Scores a data model against the Data Model Scorecard
includes knobit	Explains data model review and the Data Model Scorecard
rdfs:label	Review data model and database design quality en
schema:isPartOf	DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design
skos:notation	5.1.2

Manage data model versioning and integration edu:LearningOutcome

https://knobit.org/id/register/data-modelling#DM-41

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
includes knobit	Recognises a review of a version other than the one released
includes knobit	Recognises a breaking model change released as a minor version
includes knobit	Recognises a released model version with no baseline
includes knobit	Recognises a model change released without approval
includes knobit	Releases a model change as a new model version
includes knobit	Recognises undetected drift between database and model
includes knobit	Explains data model versioning and change management
rdfs:label	Manage data model versioning and integration en
schema:isPartOf	DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design
skos:notation	5.1.3

Data modelling metrics edu:LearningOutcome

https://knobit.org/id/register/data-modelling#DM-42

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
includes knobit	Scores a data model against the Data Model Scorecard
includes knobit	Explains data model review and the Data Model Scorecard
rdfs:label	Data modelling metrics en
schema:isPartOf	DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design
skos:notation	5.2

Entity edu:LearningOutcome

https://knobit.org/id/register/data-modelling#DM-5

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
includes knobit	Explains intensional definition by superordinate concept and delimiting characteristics
includes knobit	Explains an entity type as the realisation of one business concept
includes knobit	Explains data modelling notations
rdfs:label	Entity en
schema:isPartOf	DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design
skos:notation	1.3.3.1

Relationship edu:LearningOutcome

https://knobit.org/id/register/data-modelling#DM-6

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
includes knobit	Explains join dependency and fifth normal form
includes knobit	Explains relationship cardinality and optionality
includes knobit	Explains referential integrity and referential actions
includes knobit	Explains data modelling notations
rdfs:label	Relationship en
schema:isPartOf	DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design
skos:notation	1.3.3.2

Attribute and identifiers edu:LearningOutcome

https://knobit.org/id/register/data-modelling#DM-7

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
includes knobit	Explains candidate key and prime attribute
includes knobit	Explains natural keys, surrogate keys and key stability
includes knobit	Explains identifying and non-identifying relationships
rdfs:label	Attribute and identifiers en
schema:isPartOf	DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design
skos:notation	1.3.3.3

Domain edu:LearningOutcome

https://knobit.org/id/register/data-modelling#DM-8

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
includes knobit	Explains attribute domains
rdfs:label	Domain en
schema:isPartOf	DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design
skos:notation	1.3.3.4

Relational modelling scheme edu:LearningOutcome

https://knobit.org/id/register/data-modelling#DM-9

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
includes knobit	Explains functional dependency
includes knobit	Explains candidate key and prime attribute
includes knobit	Explains data modelling notations
rdfs:label	Relational modelling scheme en
schema:isPartOf	DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design
skos:notation	1.3.4.1

dm-knowledge-requirements Q1: singular and unambiguous data requirement statements edu:Question

https://knobit.org/id/register/data-modelling#I-1001

dcterms:identifier	I-1001
rdfs:label	dm-knowledge-requirements Q1: singular and unambiguous data requirement statements en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q1 (1 points)
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
solvable with	set of Explains singular and unambiguous requirement statements

dm-knowledge-requirements Q2: business requirement versus design solution edu:Question

https://knobit.org/id/register/data-modelling#I-1002

dcterms:identifier	I-1002
rdfs:label	dm-knowledge-requirements Q2: business requirement versus design solution en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q2 (1 points)
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
solvable with	set of Distinguishes a business requirement from a design solution

dm-knowledge-requirements Q3: requirement type of a load timeliness expectation edu:Question

https://knobit.org/id/register/data-modelling#I-1003

dcterms:identifier	I-1003
rdfs:label	dm-knowledge-requirements Q3: requirement type of a load timeliness expectation en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q3 (1 points)
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
solvable with	set of Explains the data requirement types of the register

dm-knowledge-requirements Q4: purpose of requirement attributes and trace edu:Question

https://knobit.org/id/register/data-modelling#I-1004

dcterms:identifier	I-1004
rdfs:label	dm-knowledge-requirements Q4: purpose of requirement attributes and trace en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q4 (1 points)
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
solvable with	set of Explains requirement attributes and traceability

dm-knowledge-requirements Q5: point-in-time reproducibility of a published report edu:Question

https://knobit.org/id/register/data-modelling#I-1005

dcterms:identifier	I-1005
rdfs:label	dm-knowledge-requirements Q5: point-in-time reproducibility of a published report en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q5 (1 points)
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
solvable with	set of Explains current value, history and point-in-time reproducibility

dm-knowledge-requirements Q6: identity of a business thing such as a debit card edu:Question

https://knobit.org/id/register/data-modelling#I-1006

dcterms:identifier	I-1006
rdfs:label	dm-knowledge-requirements Q6: identity of a business thing such as a debit card en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q6 (1 points)
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
solvable with	set of Explains the identity of a business thing

dm-knowledge-requirements Q7: retention among the non-functional data concerns edu:Question

https://knobit.org/id/register/data-modelling#I-1007

dcterms:identifier	I-1007
rdfs:label	dm-knowledge-requirements Q7: retention among the non-functional data concerns en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q7 (1 points)
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
solvable with	set of Explains the non-functional data concerns

dm-knowledge-requirements Q8: questions a data requirements register must serve edu:Question

https://knobit.org/id/register/data-modelling#I-1008

dcterms:identifier	I-1008
rdfs:label	dm-knowledge-requirements Q8: questions a data requirements register must serve en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q8 (1 points)
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
solvable with	set of Explains the scope, events and questions a data register must state

dm-knowledge-requirements Q9: and-or ambiguity in a requirement statement edu:Question

https://knobit.org/id/register/data-modelling#I-1009

dcterms:identifier	I-1009
rdfs:label	dm-knowledge-requirements Q9: and-or ambiguity in a requirement statement en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q9 (1 points)
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
solvable with	set of Explains referential and logical ambiguity in natural-language statements

data-requirements C1a: identity gap named edu:Question

https://knobit.org/id/register/data-modelling#I-101

dcterms:identifier	I-101
rdfs:label	data-requirements C1a: identity gap named en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C1 (3 points)
solvable with	set of Recognises an uncovered identity requirement

dm-knowledge-requirements Q10: persistent identifier of a superseded requirement edu:Question

https://knobit.org/id/register/data-modelling#I-1010

dcterms:identifier	I-1010
rdfs:label	dm-knowledge-requirements Q10: persistent identifier of a superseded requirement en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q10 (1 points)
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
solvable with	set of Explains persistent identifiers

dm-knowledge-requirements Q11: what makes a data quality requirement verifiable edu:Question

https://knobit.org/id/register/data-modelling#I-1011

dcterms:identifier	I-1011
rdfs:label	dm-knowledge-requirements Q11: what makes a data quality requirement verifiable en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q11 (1 points)
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
solvable with	set of Explains verifiable requirement statements

dm-knowledge-requirements Q12: conflicting requirements in a register edu:Question

https://knobit.org/id/register/data-modelling#I-1012

dcterms:identifier	I-1012
rdfs:label	dm-knowledge-requirements Q12: conflicting requirements in a register en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q12 (1 points)
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
solvable with	set of Explains consistency within a requirements register

dm-knowledge-conceptual Q1: intensional definition of savings account edu:Question

https://knobit.org/id/register/data-modelling#I-1013

dcterms:identifier	I-1013
rdfs:label	dm-knowledge-conceptual Q1: intensional definition of savings account en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q1 (1 points)
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
solvable with	set of Explains intensional definition by superordinate concept and delimiting characteristics

dm-knowledge-conceptual Q2: generic versus partitive concept relations edu:Question

https://knobit.org/id/register/data-modelling#I-1014

dcterms:identifier	I-1014
rdfs:label	dm-knowledge-conceptual Q2: generic versus partitive concept relations en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q2 (1 points)
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
solvable with	set of Explains generic and partitive concept relations

dm-knowledge-conceptual Q3: SBVR fact type and rule statement edu:Question

https://knobit.org/id/register/data-modelling#I-1015

dcterms:identifier	I-1015
rdfs:label	dm-knowledge-conceptual Q3: SBVR fact type and rule statement en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q3 (1 points)
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
solvable with	set of Explains SBVR fact types and rule statements

dm-knowledge-conceptual Q4: data rules in Witt's business rule classification edu:Question

https://knobit.org/id/register/data-modelling#I-1016

dcterms:identifier	I-1016
rdfs:label	dm-knowledge-conceptual Q4: data rules in Witt's business rule classification en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q4 (1 points)
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
solvable with	set of Explains Witt's classification of business rules

dm-knowledge-conceptual Q5: rule enforcement on a platform that does not enforce keys edu:Question

https://knobit.org/id/register/data-modelling#I-1017

dcterms:identifier	I-1017
rdfs:label	dm-knowledge-conceptual Q5: rule enforcement on a platform that does not enforce keys en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q5 (1 points)
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
solvable with	set of Explains rule enforcement mechanisms and platform enforcement

dm-knowledge-conceptual Q6: all-and-some test for a hierarchical link edu:Question

https://knobit.org/id/register/data-modelling#I-1018

dcterms:identifier	I-1018
rdfs:label	dm-knowledge-conceptual Q6: all-and-some test for a hierarchical link en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q6 (1 points)
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
solvable with	set of Explains hierarchical relations and the all-and-some test

dm-knowledge-conceptual Q7: history note for a changed node meaning edu:Question

https://knobit.org/id/register/data-modelling#I-1019

dcterms:identifier	I-1019
rdfs:label	dm-knowledge-conceptual Q7: history note for a changed node meaning en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q7 (1 points)
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
solvable with	set of Explains scope notes and history notes

data-requirements C1b: access gap named edu:Question

https://knobit.org/id/register/data-modelling#I-102

dcterms:identifier	I-102
rdfs:label	data-requirements C1b: access gap named en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C1 (3 points)
solvable with	set of Recognises an uncovered sensitivity or access requirement

dm-knowledge-conceptual Q8: warrant for a proposed vocabulary node edu:Question

https://knobit.org/id/register/data-modelling#I-1020

dcterms:identifier	I-1020
rdfs:label	dm-knowledge-conceptual Q8: warrant for a proposed vocabulary node en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q8 (1 points)
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
solvable with	set of Explains warrant for vocabulary terms

dm-knowledge-conceptual Q9: label form conventions for card type labels edu:Question

https://knobit.org/id/register/data-modelling#I-1021

dcterms:identifier	I-1021
rdfs:label	dm-knowledge-conceptual Q9: label form conventions for card type labels en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q9 (1 points)
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
solvable with	set of Explains label form conventions for vocabularies

dm-knowledge-conceptual Q10: one characteristic of division per sibling array edu:Question

https://knobit.org/id/register/data-modelling#I-1022

dcterms:identifier	I-1022
rdfs:label	dm-knowledge-conceptual Q10: one characteristic of division per sibling array en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q10 (1 points)
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
solvable with	set of Explains characteristics of division and node labels

dm-knowledge-conceptual Q11: equivalence relation and preferred term edu:Question

https://knobit.org/id/register/data-modelling#I-1023

dcterms:identifier	I-1023
rdfs:label	dm-knowledge-conceptual Q11: equivalence relation and preferred term en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q11 (1 points)
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
solvable with	set of Explains equivalence relations and preferred terms

dm-knowledge-conceptual Q12: associative relation between lending concepts edu:Question

https://knobit.org/id/register/data-modelling#I-1024

dcterms:identifier	I-1024
rdfs:label	dm-knowledge-conceptual Q12: associative relation between lending concepts en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q12 (1 points)
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
solvable with	set of Explains associative relations

dm-knowledge-conceptual Q13: reusing an external payment purpose code set edu:Question

https://knobit.org/id/register/data-modelling#I-1025

dcterms:identifier	I-1025
rdfs:label	dm-knowledge-conceptual Q13: reusing an external payment purpose code set en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q13 (1 points)
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
solvable with	set of Explains reuse of external vocabularies

dm-knowledge-logical Q1: functional dependency between card and account edu:Question

https://knobit.org/id/register/data-modelling#I-1026

dcterms:identifier	I-1026
rdfs:label	dm-knowledge-logical Q1: functional dependency between card and account en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q1 (1 points)
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
solvable with	set of Explains functional dependency

dm-knowledge-logical Q2: candidate keys and prime attributes of an account holding edu:Question

https://knobit.org/id/register/data-modelling#I-1027

dcterms:identifier	I-1027
rdfs:label	dm-knowledge-logical Q2: candidate keys and prime attributes of an account holding en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q2 (1 points)
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
solvable with	set of Explains candidate key and prime attribute

dm-knowledge-logical Q3: deletion anomaly in a loan application entity edu:Question

https://knobit.org/id/register/data-modelling#I-1028

dcterms:identifier	I-1028
rdfs:label	dm-knowledge-logical Q3: deletion anomaly in a loan application entity en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q3 (1 points)
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
solvable with	set of Explains the insertion, update and deletion anomalies

dm-knowledge-logical Q4: first normal form and atomic values edu:Question

https://knobit.org/id/register/data-modelling#I-1029

dcterms:identifier	I-1029
rdfs:label	dm-knowledge-logical Q4: first normal form and atomic values en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q4 (1 points)
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
solvable with	set of Explains first normal form

data-requirements C1c: lineage gap named edu:Question

https://knobit.org/id/register/data-modelling#I-103

dcterms:identifier	I-103
rdfs:label	data-requirements C1c: lineage gap named en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C1 (3 points)
solvable with	set of Recognises an uncovered lineage requirement

dm-knowledge-logical Q5: second normal form and partial dependency edu:Question

https://knobit.org/id/register/data-modelling#I-1030

dcterms:identifier	I-1030
rdfs:label	dm-knowledge-logical Q5: second normal form and partial dependency en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q5 (1 points)
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
solvable with	set of Explains second normal form

dm-knowledge-logical Q6: third normal form and transitive dependency edu:Question

https://knobit.org/id/register/data-modelling#I-1031

dcterms:identifier	I-1031
rdfs:label	dm-knowledge-logical Q6: third normal form and transitive dependency en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q6 (1 points)
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
solvable with	set of Explains third normal form

dm-knowledge-logical Q7: Boyce-Codd normal form with overlapping keys edu:Question

https://knobit.org/id/register/data-modelling#I-1032

dcterms:identifier	I-1032
rdfs:label	dm-knowledge-logical Q7: Boyce-Codd normal form with overlapping keys en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q7 (1 points)
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
solvable with	set of Explains Boyce-Codd normal form

dm-knowledge-logical Q8: independent multivalued facts and fourth normal form edu:Question

https://knobit.org/id/register/data-modelling#I-1033

dcterms:identifier	I-1033
rdfs:label	dm-knowledge-logical Q8: independent multivalued facts and fourth normal form en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q8 (1 points)
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
solvable with	set of Explains multivalued dependency and fourth normal form

dm-knowledge-logical Q9: join dependency and fifth normal form edu:Question

https://knobit.org/id/register/data-modelling#I-1034

dcterms:identifier	I-1034
rdfs:label	dm-knowledge-logical Q9: join dependency and fifth normal form en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q9 (1 points)
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
solvable with	set of Explains join dependency and fifth normal form

dm-knowledge-logical Q10: sixth normal form for independently changing attributes edu:Question

https://knobit.org/id/register/data-modelling#I-1035

dcterms:identifier	I-1035
rdfs:label	dm-knowledge-logical Q10: sixth normal form for independently changing attributes en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q10 (1 points)
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
solvable with	set of Explains sixth normal form for temporal data

dm-knowledge-logical Q11: constraints implied by keys and domains edu:Question

https://knobit.org/id/register/data-modelling#I-1036

dcterms:identifier	I-1036
rdfs:label	dm-knowledge-logical Q11: constraints implied by keys and domains en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q11 (1 points)
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
solvable with	set of Explains domain-key normal form

dm-knowledge-logical Q12: one domain per attribute edu:Question

https://knobit.org/id/register/data-modelling#I-1037

dcterms:identifier	I-1037
rdfs:label	dm-knowledge-logical Q12: one domain per attribute en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q12 (1 points)
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
solvable with	set of Explains attribute domains

dm-knowledge-logical Q13: lossless-join decomposition of a payment entity edu:Question

https://knobit.org/id/register/data-modelling#I-1038

dcterms:identifier	I-1038
rdfs:label	dm-knowledge-logical Q13: lossless-join decomposition of a payment entity en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q13 (1 points)
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
solvable with	set of Explains lossless-join decomposition

dm-knowledge-logical Q14: dependency preservation in a BCNF decomposition edu:Question

https://knobit.org/id/register/data-modelling#I-1039

dcterms:identifier	I-1039
rdfs:label	dm-knowledge-logical Q14: dependency preservation in a BCNF decomposition en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q14 (1 points)
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
solvable with	set of Explains dependency preservation

data-requirements C1d: history gap named edu:Question

https://knobit.org/id/register/data-modelling#I-104

dcterms:identifier	I-104
rdfs:label	data-requirements C1d: history gap named en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C1 (3 points)
solvable with	set of Recognises undecided history requirements across the register

dm-knowledge-logical Q15: snapshot value versus derivable value edu:Question

https://knobit.org/id/register/data-modelling#I-1040

dcterms:identifier	I-1040
rdfs:label	dm-knowledge-logical Q15: snapshot value versus derivable value en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q15 (1 points)
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
solvable with	set of Explains derived data and point-in-time snapshots

dm-knowledge-logical Q16: disjoint and partial subtyping of accounts edu:Question

https://knobit.org/id/register/data-modelling#I-1041

dcterms:identifier	I-1041
rdfs:label	dm-knowledge-logical Q16: disjoint and partial subtyping of accounts en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q16 (1 points)
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
solvable with	set of Explains supertype and subtype constraints

dm-knowledge-logical Q17: cardinality and optionality of account and card edu:Question

https://knobit.org/id/register/data-modelling#I-1042

dcterms:identifier	I-1042
rdfs:label	dm-knowledge-logical Q17: cardinality and optionality of account and card en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q17 (1 points)
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
solvable with	set of Explains relationship cardinality and optionality

dm-knowledge-logical Q18: natural key kept beside a surrogate key edu:Question

https://knobit.org/id/register/data-modelling#I-1043

dcterms:identifier	I-1043
rdfs:label	dm-knowledge-logical Q18: natural key kept beside a surrogate key en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q18 (1 points)
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
solvable with	set of Explains natural keys, surrogate keys and key stability

dm-knowledge-logical Q19: chasm trap on an optional relationship path edu:Question

https://knobit.org/id/register/data-modelling#I-1044

dcterms:identifier	I-1044
rdfs:label	dm-knowledge-logical Q19: chasm trap on an optional relationship path en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q19 (1 points)
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
solvable with	set of Explains the connection, fan and chasm traps

dm-knowledge-logical Q20: one entity type per business concept edu:Question

https://knobit.org/id/register/data-modelling#I-1045

dcterms:identifier	I-1045
rdfs:label	dm-knowledge-logical Q20: one entity type per business concept en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q20 (1 points)
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
solvable with	set of Explains an entity type as the realisation of one business concept

dm-knowledge-physical Q1: what makes a denormalisation controlled edu:Question

https://knobit.org/id/register/data-modelling#I-1046

dcterms:identifier	I-1046
rdfs:label	dm-knowledge-physical Q1: what makes a denormalisation controlled en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q1 (1 points)
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
solvable with	set of Explains controlled denormalisation

dm-knowledge-physical Q2: constraints lost by rolling up subtypes edu:Question

https://knobit.org/id/register/data-modelling#I-1047

dcterms:identifier	I-1047
rdfs:label	dm-knowledge-physical Q2: constraints lost by rolling up subtypes en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q2 (1 points)
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
solvable with	set of Explains the implementation options for subtypes

dm-knowledge-physical Q3: referential action for payments referencing an account edu:Question

https://knobit.org/id/register/data-modelling#I-1048

dcterms:identifier	I-1048
rdfs:label	dm-knowledge-physical Q3: referential action for payments referencing an account en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q3 (1 points)
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
solvable with	set of Explains referential integrity and referential actions

dm-knowledge-physical Q4: exact decimal type for a euro balance edu:Question

https://knobit.org/id/register/data-modelling#I-1049

dcterms:identifier	I-1049
rdfs:label	dm-knowledge-physical Q4: exact decimal type for a euro balance en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q4 (1 points)
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
solvable with	set of Explains exact and approximate numeric types

data-requirements C1e: no question the data serves named edu:Question

https://knobit.org/id/register/data-modelling#I-105

dcterms:identifier	I-105
rdfs:label	data-requirements C1e: no question the data serves named en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C1 (3 points)
solvable with	set of Recognises a requirements register serving no stated question

dm-knowledge-physical Q5: null and three-valued logic in a predicate edu:Question

https://knobit.org/id/register/data-modelling#I-1050

dcterms:identifier	I-1050
rdfs:label	dm-knowledge-physical Q5: null and three-valued logic in a predicate en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q5 (1 points)
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
solvable with	set of Explains null semantics and three-valued logic

dm-knowledge-physical Q6: changeable value set held as reference data edu:Question

https://knobit.org/id/register/data-modelling#I-1051

dcterms:identifier	I-1051
rdfs:label	dm-knowledge-physical Q6: changeable value set held as reference data en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q6 (1 points)
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
solvable with	set of Explains value sets held as reference data

dm-knowledge-physical Q7: deriving indexes from access paths edu:Question

https://knobit.org/id/register/data-modelling#I-1052

dcterms:identifier	I-1052
rdfs:label	dm-knowledge-physical Q7: deriving indexes from access paths en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q7 (1 points)
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
solvable with	set of Explains index design from access paths

dm-knowledge-physical Q8: half-open validity periods in a versioned table edu:Question

https://knobit.org/id/register/data-modelling#I-1053

dcterms:identifier	I-1053
rdfs:label	dm-knowledge-physical Q8: half-open validity periods in a versioned table en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q8 (1 points)
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
solvable with	set of Explains history strategies and validity-period conventions

dm-knowledge-physical Q9: semi-additive month-end balance measure edu:Question

https://knobit.org/id/register/data-modelling#I-1054

dcterms:identifier	I-1054
rdfs:label	dm-knowledge-physical Q9: semi-additive month-end balance measure en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q9 (1 points)
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
solvable with	set of Explains grain and additivity in dimensional models

dm-knowledge-physical Q10: vertical split that keeps one entity edu:Question

https://knobit.org/id/register/data-modelling#I-1055

dcterms:identifier	I-1055
rdfs:label	dm-knowledge-physical Q10: vertical split that keeps one entity en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q10 (1 points)
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
solvable with	set of Explains vertical and horizontal partitioning of tables

dm-knowledge-physical Q11: consistency risk of documents stored by reference edu:Question

https://knobit.org/id/register/data-modelling#I-1056

dcterms:identifier	I-1056
rdfs:label	dm-knowledge-physical Q11: consistency risk of documents stored by reference en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q11 (1 points)
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
solvable with	set of Explains consistency of content stored by reference

dm-knowledge-physical Q12: no meaning in relational row or key order edu:Question

https://knobit.org/id/register/data-modelling#I-1057

dcterms:identifier	I-1057
rdfs:label	dm-knowledge-physical Q12: no meaning in relational row or key order en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q12 (1 points)
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
solvable with	set of Explains the absence of row order in relational tables

dm-knowledge-physical Q13: where to fix a defect in generated DDL edu:Question

https://knobit.org/id/register/data-modelling#I-1058

dcterms:identifier	I-1058
rdfs:label	dm-knowledge-physical Q13: where to fix a defect in generated DDL en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q13 (1 points)
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
solvable with	set of Explains generated artefacts and their single source of truth

dm-knowledge-physical Q14: one logical type rendering differently by SQL engine edu:Question

https://knobit.org/id/register/data-modelling#I-1059

dcterms:identifier	I-1059
rdfs:label	dm-knowledge-physical Q14: one logical type rendering differently by SQL engine en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q14 (1 points)
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
solvable with	set of Explains SQL dialect differences

data-requirements C1f: volume and retention gap named edu:Question

https://knobit.org/id/register/data-modelling#I-106

dcterms:identifier	I-106
rdfs:label	data-requirements C1f: volume and retention gap named en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C1 (3 points)
solvable with	set of Recognises an uncovered volume or retention requirement

dm-knowledge-physical Q15: currency minor units and amount scale edu:Question

https://knobit.org/id/register/data-modelling#I-1060

dcterms:identifier	I-1060
rdfs:label	dm-knowledge-physical Q15: currency minor units and amount scale en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q15 (1 points)
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
solvable with	set of Explains currency minor units

dm-knowledge-physical Q16: event timestamps and business dates edu:Question

https://knobit.org/id/register/data-modelling#I-1061

dcterms:identifier	I-1061
rdfs:label	dm-knowledge-physical Q16: event timestamps and business dates en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q16 (1 points)
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
solvable with	set of Explains time zones in timestamps and business dates

dm-knowledge-physical Q17: collation and the meaning of a key edu:Question

https://knobit.org/id/register/data-modelling#I-1062

dcterms:identifier	I-1062
rdfs:label	dm-knowledge-physical Q17: collation and the meaning of a key en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q17 (1 points)
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
solvable with	set of Explains collation and case or accent sensitivity

dm-knowledge-physical Q18: access design derived from data classification edu:Question

https://knobit.org/id/register/data-modelling#I-1063

dcterms:identifier	I-1063
rdfs:label	dm-knowledge-physical Q18: access design derived from data classification en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q18 (1 points)
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
solvable with	set of Explains access design for classified data

dm-knowledge-physical Q19: adding a mandatory column to a populated table edu:Question

https://knobit.org/id/register/data-modelling#I-1064

dcterms:identifier	I-1064
rdfs:label	dm-knowledge-physical Q19: adding a mandatory column to a populated table en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q19 (1 points)
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
solvable with	set of Explains schema migration and rollback

dm-knowledge-physical Q20: one artefact for every deployment environment edu:Question

https://knobit.org/id/register/data-modelling#I-1065

dcterms:identifier	I-1065
rdfs:label	dm-knowledge-physical Q20: one artefact for every deployment environment en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q20 (1 points)
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
solvable with	set of Explains environment-independent deployment

dm-knowledge-physical Q21: proving DDL by execution and detecting drift edu:Question

https://knobit.org/id/register/data-modelling#I-1066

dcterms:identifier	I-1066
rdfs:label	dm-knowledge-physical Q21: proving DDL by execution and detecting drift en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q21 (1 points)
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
solvable with	set of Explains testing DDL by execution and detecting drift

dm-knowledge-dmbok-ch5 Q1: purpose of building a data model edu:Question

https://knobit.org/id/register/data-modelling#I-1067

dcterms:identifier	I-1067
rdfs:label	dm-knowledge-dmbok-ch5 Q1: purpose of building a data model en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q1 (1 points)
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
solvable with	set of Explains what data models are and why organisations build them

dm-knowledge-dmbok-ch5 Q2: DMBOK type of modelled data for a loan application edu:Question

https://knobit.org/id/register/data-modelling#I-1068

dcterms:identifier	I-1068
rdfs:label	dm-knowledge-dmbok-ch5 Q2: DMBOK type of modelled data for a loan application en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q2 (1 points)
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
solvable with	set of Explains the types of modelled data

dm-knowledge-dmbok-ch5 Q3: zero-or-many in Information Engineering notation edu:Question

https://knobit.org/id/register/data-modelling#I-1069

dcterms:identifier	I-1069
rdfs:label	dm-knowledge-dmbok-ch5 Q3: zero-or-many in Information Engineering notation en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q3 (1 points)
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
solvable with	set of Explains data modelling notations

data-requirements C2a: duplicate retired, not deleted edu:Question

https://knobit.org/id/register/data-modelling#I-107

dcterms:identifier	I-107
rdfs:label	data-requirements C2a: duplicate retired, not deleted en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C2 (3 points)
solvable with	set of Recognises duplicate data requirements, Retires a superseded register entry instead of deleting it

dm-knowledge-dmbok-ch5 Q4: identifying relationship for repayment instalments edu:Question

https://knobit.org/id/register/data-modelling#I-1070

dcterms:identifier	I-1070
rdfs:label	dm-knowledge-dmbok-ch5 Q4: identifying relationship for repayment instalments en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q4 (1 points)
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
solvable with	set of Explains identifying and non-identifying relationships

dm-knowledge-dmbok-ch5 Q5: conformed dimensions across banking star schemas edu:Question

https://knobit.org/id/register/data-modelling#I-1071

dcterms:identifier	I-1071
rdfs:label	dm-knowledge-dmbok-ch5 Q5: conformed dimensions across banking star schemas en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q5 (1 points)
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
solvable with	set of Explains dimensional modelling

dm-knowledge-dmbok-ch5 Q6: UML class diagram versus entity-relationship model edu:Question

https://knobit.org/id/register/data-modelling#I-1072

dcterms:identifier	I-1072
rdfs:label	dm-knowledge-dmbok-ch5 Q6: UML class diagram versus entity-relationship model en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q6 (1 points)
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
solvable with	set of Explains UML class diagrams as a data modelling scheme

dm-knowledge-dmbok-ch5 Q7: elementary facts in fact-based modelling edu:Question

https://knobit.org/id/register/data-modelling#I-1073

dcterms:identifier	I-1073
rdfs:label	dm-knowledge-dmbok-ch5 Q7: elementary facts in fact-based modelling en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q7 (1 points)
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
solvable with	set of Explains fact-based modelling

dm-knowledge-dmbok-ch5 Q8: hubs, links and satellites in a Data Vault edu:Question

https://knobit.org/id/register/data-modelling#I-1074

dcterms:identifier	I-1074
rdfs:label	dm-knowledge-dmbok-ch5 Q8: hubs, links and satellites in a Data Vault en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q8 (1 points)
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
solvable with	set of Explains time-based modelling schemes

dm-knowledge-dmbok-ch5 Q9: aggregate-oriented modelling in a document store edu:Question

https://knobit.org/id/register/data-modelling#I-1075

dcterms:identifier	I-1075
rdfs:label	dm-knowledge-dmbok-ch5 Q9: aggregate-oriented modelling in a document store en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q9 (1 points)
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
solvable with	set of Explains NoSQL data modelling schemes

dm-knowledge-dmbok-ch5 Q10: canonical data model for system integration edu:Question

https://knobit.org/id/register/data-modelling#I-1076

dcterms:identifier	I-1076
rdfs:label	dm-knowledge-dmbok-ch5 Q10: canonical data model for system integration en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q10 (1 points)
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
solvable with	set of Explains canonical data models

dm-knowledge-dmbok-ch5 Q11: database view for restricted and joined access edu:Question

https://knobit.org/id/register/data-modelling#I-1077

dcterms:identifier	I-1077
rdfs:label	dm-knowledge-dmbok-ch5 Q11: database view for restricted and joined access en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q11 (1 points)
schema:learningResourceType	multiple_choice
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
solvable with	set of Explains views in physical design

dm-knowledge-dmbok-ch5 Q12: deliverables of a data modelling plan edu:Question

https://knobit.org/id/register/data-modelling#I-1078

dcterms:identifier	I-1078
rdfs:label	dm-knowledge-dmbok-ch5 Q12: deliverables of a data modelling plan en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q12 (1 points)
schema:learningResourceType	multiple_choice
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
solvable with	set of Explains the planning of data modelling work

dm-knowledge-dmbok-ch5 Q13: choosing a modelling scheme and notation edu:Question

https://knobit.org/id/register/data-modelling#I-1079

dcterms:identifier	I-1079
rdfs:label	dm-knowledge-dmbok-ch5 Q13: choosing a modelling scheme and notation en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q13 (1 points)
schema:learningResourceType	multiple_choice
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
solvable with	set of Explains how to choose a modelling scheme and notation

data-requirements C2b: paraphrase retired or recorded as a second source edu:Question

https://knobit.org/id/register/data-modelling#I-108

dcterms:identifier	I-108
rdfs:label	data-requirements C2b: paraphrase retired or recorded as a second source en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C2 (3 points)
solvable with	set of Recognises paraphrased data requirements, Retires a superseded register entry instead of deleting it

dm-knowledge-dmbok-ch5 Q14: what reverse engineering cannot recover alone edu:Question

https://knobit.org/id/register/data-modelling#I-1080

dcterms:identifier	I-1080
rdfs:label	dm-knowledge-dmbok-ch5 Q14: what reverse engineering cannot recover alone en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q14 (1 points)
schema:learningResourceType	multiple_choice
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
solvable with	set of Explains forward and reverse engineering of data models

dm-knowledge-dmbok-ch5 Q15: data model scorecard categories edu:Question

https://knobit.org/id/register/data-modelling#I-1081

dcterms:identifier	I-1081
rdfs:label	dm-knowledge-dmbok-ch5 Q15: data model scorecard categories en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q15 (1 points)
schema:learningResourceType	multiple_choice
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
solvable with	set of Explains data model review and the Data Model Scorecard

dm-knowledge-dmbok-ch5 Q16: semantic version of a breaking model change edu:Question

https://knobit.org/id/register/data-modelling#I-1082

dcterms:identifier	I-1082
rdfs:label	dm-knowledge-dmbok-ch5 Q16: semantic version of a breaking model change en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q16 (1 points)
schema:learningResourceType	multiple_choice
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
solvable with	set of Explains data model versioning and change management

dm-knowledge-dmbok-ch5 Q17: matching modelling tasks to tool types edu:Question

https://knobit.org/id/register/data-modelling#I-1083

dcterms:identifier	I-1083
rdfs:label	dm-knowledge-dmbok-ch5 Q17: matching modelling tasks to tool types en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q17 (1 points)
schema:learningResourceType	multiple_choice
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
solvable with	set of Explains the tools supporting data modelling

dm-knowledge-dmbok-ch5 Q18: party-role pattern and adapting an industry model edu:Question

https://knobit.org/id/register/data-modelling#I-1084

dcterms:identifier	I-1084
rdfs:label	dm-knowledge-dmbok-ch5 Q18: party-role pattern and adapting an industry model en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q18 (1 points)
schema:learningResourceType	multiple_choice
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
solvable with	set of Explains data model patterns and industry data models

dm-knowledge-dmbok-ch5 Q19: ISO/IEC 11179 decomposition of an attribute name edu:Question

https://knobit.org/id/register/data-modelling#I-1085

dcterms:identifier	I-1085
rdfs:label	dm-knowledge-dmbok-ch5 Q19: ISO/IEC 11179 decomposition of an attribute name en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q19 (1 points)
schema:learningResourceType	multiple_choice
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
solvable with	set of Explains naming conventions for data model objects

dm-knowledge-dmbok-ch5 Q20: database design principle served by access through views edu:Question

https://knobit.org/id/register/data-modelling#I-1086

dcterms:identifier	I-1086
rdfs:label	dm-knowledge-dmbok-ch5 Q20: database design principle served by access through views en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q20 (1 points)
schema:learningResourceType	multiple_choice
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
solvable with	set of Explains database design principles

dm-knowledge-dmbok-ch5 Q21: content and upkeep of a modelling standard edu:Question

https://knobit.org/id/register/data-modelling#I-1087

dcterms:identifier	I-1087
rdfs:label	dm-knowledge-dmbok-ch5 Q21: content and upkeep of a modelling standard en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q21 (1 points)
schema:learningResourceType	multiple_choice
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
solvable with	set of Explains data modelling and design standards

data-requirements C2c: retention against erasure kept with a reconciling condition edu:Question

https://knobit.org/id/register/data-modelling#I-109

dcterms:identifier	I-109
rdfs:label	data-requirements C2c: retention against erasure kept with a reconciling condition en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C2 (3 points)
solvable with	set of Recognises conflicting data requirements

data-requirements C3a: unsupplied value lists raised, not invented edu:Question

https://knobit.org/id/register/data-modelling#I-110

dcterms:identifier	I-110
rdfs:label	data-requirements C3a: unsupplied value lists raised, not invented en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C3 (2 points)
solvable with	set of Recognises a guess recorded as fact

data-requirements C3b: gross or net raised and the requirement not confirmed edu:Question

https://knobit.org/id/register/data-modelling#I-111

dcterms:identifier	I-111
rdfs:label	data-requirements C3b: gross or net raised and the requirement not confirmed en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C3 (2 points)
solvable with	set of Recognises a measure stated without unit or basis, Recognises a status contradicting the requirement's content

data-requirements I1a: two-claim requirement split edu:Question

https://knobit.org/id/register/data-modelling#I-112

dcterms:identifier	I-112
rdfs:label	data-requirements I1a: two-claim requirement split en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I1 (2 points)
solvable with	set of Recognises a data requirement making several claims

data-requirements I1b: misfiled currency rule moved edu:Question

https://knobit.org/id/register/data-modelling#I-113

dcterms:identifier	I-113
rdfs:label	data-requirements I1b: misfiled currency rule moved en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I1 (2 points)
solvable with	set of Recognises content filed under the wrong requirement

data-requirements I2: candidate rules captured as data-rule requirements edu:Question

https://knobit.org/id/register/data-modelling#I-114

dcterms:identifier	I-114
rdfs:label	data-requirements I2: candidate rules captured as data-rule requirements en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I2 (2 points)
solvable with	set of Recognises a business rule left inside another statement

data-requirements I3: out-of-scope statements reclassified edu:Question

https://knobit.org/id/register/data-modelling#I-115

dcterms:identifier	I-115
rdfs:label	data-requirements I3: out-of-scope statements reclassified en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I3 (1 points)
solvable with	set of Recognises a statement outside the scope of data requirements

data-requirements I4a: absolute about collateral challenged edu:Question

https://knobit.org/id/register/data-modelling#I-116

dcterms:identifier	I-116
rdfs:label	data-requirements I4a: absolute about collateral challenged en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I4 (2 points)
solvable with	set of Recognises an absolute statement with its exception unasked

data-requirements I4b: when date of birth is mandatory resolved edu:Question

https://knobit.org/id/register/data-modelling#I-117

dcterms:identifier	I-117
rdfs:label	data-requirements I4b: when date of birth is mandatory resolved en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I4 (2 points)
solvable with	set of Recognises a mandatory attribute without its moment of obligation

data-requirements I5a: 'it' resolved edu:Question

https://knobit.org/id/register/data-modelling#I-118

dcterms:identifier	I-118
rdfs:label	data-requirements I5a: 'it' resolved en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I5 (2 points)
solvable with	set of Recognises a reference with several possible referents

data-requirements I5b: which date and whose named edu:Question

https://knobit.org/id/register/data-modelling#I-119

dcterms:identifier	I-119
rdfs:label	data-requirements I5b: which date and whose named en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I5 (2 points)
solvable with	set of Recognises a data requirement without a named subject

data-requirements I5c: 'accurate' made testable edu:Question

https://knobit.org/id/register/data-modelling#I-120

dcterms:identifier	I-120
rdfs:label	data-requirements I5c: 'accurate' made testable en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I5 (2 points)
solvable with	set of Recognises an unverifiable data requirement

data-requirements I5d: 'up to date where possible' bounded edu:Question

https://knobit.org/id/register/data-modelling#I-121

dcterms:identifier	I-121
rdfs:label	data-requirements I5d: 'up to date where possible' bounded en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I5 (2 points)
solvable with	set of Recognises untestable wording in a data requirement

data-requirements Q4: priorities, status and legacy statement sound edu:Question

https://knobit.org/id/register/data-modelling#I-122

dcterms:identifier	I-122
rdfs:label	data-requirements Q4: priorities, status and legacy statement sound en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q4 (0.5 points)
solvable with	set of Recognises a missing or meaningless requirement priority, Recognises a status contradicting the requirement's content, Recognises a guess recorded as fact

data-requirements Q2: identifiers permanent edu:Question

https://knobit.org/id/register/data-modelling#I-123

dcterms:identifier	I-123
rdfs:label	data-requirements Q2: identifiers permanent en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q2 (1 points)
solvable with	set of Recognises unstable requirement identifiers, Retires a superseded register entry instead of deleting it

data-requirements Q1: requirement types sound edu:Question

https://knobit.org/id/register/data-modelling#I-124

dcterms:identifier	I-124
rdfs:label	data-requirements Q1: requirement types sound en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q1 (0.5 points)
solvable with	set of Recognises a missing or wrong requirement type

dm-requirements-history C1: requirement silent on current versus past values while the register settles history edu:Question

https://knobit.org/id/register/data-modelling#I-125

dcterms:identifier	I-125
rdfs:label	dm-requirements-history C1: requirement silent on current versus past values while the register settles history en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C1 (2 points)
solvable with	set of Recognises a data requirement silent on current versus past values

dm-requirements-history C2: design solution restated as the need edu:Question

https://knobit.org/id/register/data-modelling#I-126

dcterms:identifier	I-126
rdfs:label	dm-requirements-history C2: design solution restated as the need en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C2 (2 points)
solvable with	set of Recognises a data requirement prescribing a design solution

dm-requirements-history C3: undefined qualifier raised, not defined by guess edu:Question

https://knobit.org/id/register/data-modelling#I-127

dcterms:identifier	I-127
rdfs:label	dm-requirements-history C3: undefined qualifier raised, not defined by guess en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C3 (1.5 points)
solvable with	set of Recognises an ambiguous business term in a data requirement

dm-requirements-history C4: requirements with no source or no locator edu:Question

https://knobit.org/id/register/data-modelling#I-128

dcterms:identifier	I-128
rdfs:label	dm-requirements-history C4: requirements with no source or no locator en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C4 (1.5 points)
solvable with	set of Recognises an unsourced data requirement

dm-requirements-history C5: regulatory requirement without rationale edu:Question

https://knobit.org/id/register/data-modelling#I-129

dcterms:identifier	I-129
rdfs:label	dm-requirements-history C5: regulatory requirement without rationale en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C5 (1.5 points)
solvable with	set of Recognises a missing rationale for a non-obvious requirement

dm-requirements-history C6: one word per thing, and cardholder kept apart edu:Question

https://knobit.org/id/register/data-modelling#I-130

dcterms:identifier	I-130
rdfs:label	dm-requirements-history C6: one word per thing, and cardholder kept apart en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C6 (2 points)
solvable with	set of Recognises inconsistent terminology across the register

dm-requirements-history C7: register with no purpose, exclusions or overlapping systems edu:Question

https://knobit.org/id/register/data-modelling#I-131

dcterms:identifier	I-131
rdfs:label	dm-requirements-history C7: register with no purpose, exclusions or overlapping systems en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C7 (2 points)
solvable with	set of Recognises a requirements register with unbounded scope

dm-requirements-history C8: register describing things and no events edu:Question

https://knobit.org/id/register/data-modelling#I-132

dcterms:identifier	I-132
rdfs:label	dm-requirements-history C8: register describing things and no events en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C8 (2 points)
solvable with	set of Recognises a requirements register describing no events

dm-requirements-history C9: missing and wrong term traces edu:Question

https://knobit.org/id/register/data-modelling#I-133

dcterms:identifier	I-133
rdfs:label	dm-requirements-history C9: missing and wrong term traces en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C9 (2 points)
solvable with	set of Recognises a missing or wrong requirement trace

Meaning of a measured quantity edu:Question

https://knobit.org/id/register/data-modelling#I-1801

dcterms:identifier	I-1801
rdfs:label	Meaning of a measured quantity en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:learningResourceType	multiple_choice
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
solvable with	set of Explains the meaning of a measured quantity

Hypothesis and counter-example edu:Question

https://knobit.org/id/register/data-modelling#I-1802

dcterms:identifier	I-1802
rdfs:label	Hypothesis and counter-example en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:learningResourceType	multiple_choice
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
solvable with	set of Explains the concepts of a hypothesis and a counter-example

Database structure edu:Question

https://knobit.org/id/register/data-modelling#I-1803

dcterms:identifier	I-1803
rdfs:label	Database structure en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:learningResourceType	multiple_choice
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
solvable with	set of Explains how database tables and relationships are structured

Function (dependency, argument, value of the function) edu:Question

https://knobit.org/id/register/data-modelling#I-1804

dcterms:identifier	I-1804
rdfs:label	Function (dependency, argument, value of the function) en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:learningResourceType	multiple_choice
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
solvable with	set of Explains a function as a dependency between two variables

Rules of definition edu:Question

https://knobit.org/id/register/data-modelling#I-1805

dcterms:identifier	I-1805
rdfs:label	Rules of definition en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:learningResourceType	multiple_choice
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
solvable with	set of Explains the rules for defining a concept

Proposition and truth value edu:Question

https://knobit.org/id/register/data-modelling#I-1806

dcterms:identifier	I-1806
rdfs:label	Proposition and truth value en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:learningResourceType	multiple_choice
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
solvable with	set of Explains the concepts of a proposition and its truth value

Class diagram notation edu:Question

https://knobit.org/id/register/data-modelling#I-1807

dcterms:identifier	I-1807
rdfs:label	Class diagram notation en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:learningResourceType	multiple_choice
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
solvable with	set of Names the notation of a UML class diagram

dm-planning C1: scope with no boundary edu:Question

https://knobit.org/id/register/data-modelling#I-2001

dcterms:identifier	I-2001
rdfs:label	dm-planning C1: scope with no boundary en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C1 (2 points)
solvable with	set of Recognises a modelling scope with no boundary

dm-planning C2: plan and config disagree on naming edu:Question

https://knobit.org/id/register/data-modelling#I-2002

dcterms:identifier	I-2002
rdfs:label	dm-planning C2: plan and config disagree on naming en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C2 (2 points)
solvable with	set of Recognises a modelling standard named but not chosen

dm-planning C3: model layers with no notation edu:Question

https://knobit.org/id/register/data-modelling#I-2003

dcterms:identifier	I-2003
rdfs:label	dm-planning C3: model layers with no notation en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C3 (2 points)
solvable with	set of Recognises a model layer planned with no notation

dm-planning C4: data rules not where the config says edu:Question

https://knobit.org/id/register/data-modelling#I-2004

dcterms:identifier	I-2004
rdfs:label	dm-planning C4: data rules not where the config says en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C4 (2 points)
solvable with	set of Recognises model inputs the plan does not locate

dm-planning C5: review planned by the modeller edu:Question

https://knobit.org/id/register/data-modelling#I-2005

dcterms:identifier	I-2005
rdfs:label	dm-planning C5: review planned by the modeller en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C5 (2 points)
solvable with	set of Recognises a model review planned by its modeller

dm-planning C6: shared folder with no versions or baseline edu:Question

https://knobit.org/id/register/data-modelling#I-2006

dcterms:identifier	I-2006
rdfs:label	dm-planning C6: shared folder with no versions or baseline en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C6 (2 points)
solvable with	set of Recognises a model with no repository or baseline

dm-planning I1: plans the term deposit mart deliverables edu:Question

https://knobit.org/id/register/data-modelling#I-2007

dcterms:identifier	I-2007
rdfs:label	dm-planning I1: plans the term deposit mart deliverables en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I1 (3 points)
solvable with	set of Plans the deliverables of a modelling assignment

dm-planning I2: scheme and notation per layer for its audience edu:Question

https://knobit.org/id/register/data-modelling#I-2008

dcterms:identifier	I-2008
rdfs:label	dm-planning I2: scheme and notation per layer for its audience en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I2 (2 points)
solvable with	set of Chooses a modelling scheme and notation for an audience and purpose

dm-planning I3: naming, definition and design standards set once edu:Question

https://knobit.org/id/register/data-modelling#I-2009

dcterms:identifier	I-2009
rdfs:label	dm-planning I3: naming, definition and design standards set once en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I3 (3 points)
solvable with	set of Sets the modelling standards a project follows

dm-planning I4: tools and a repository with tagged baselines edu:Question

https://knobit.org/id/register/data-modelling#I-2010

dcterms:identifier	I-2010
rdfs:label	dm-planning I4: tools and a repository with tagged baselines en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I4 (2 points)
solvable with	set of Selects the tools and repository for a modelling project

dm-model-review C1: scorecard missing a category, weights 95 edu:Question

https://knobit.org/id/register/data-modelling#I-2101

dcterms:identifier	I-2101
rdfs:label	dm-model-review C1: scorecard missing a category, weights 95 en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C1 (2 points)
solvable with	set of Recognises an incomplete data model scorecard

dm-model-review C2: full score with no evidence edu:Question

https://knobit.org/id/register/data-modelling#I-2102

dcterms:identifier	I-2102
rdfs:label	dm-model-review C2: full score with no evidence en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C2 (2 points)
solvable with	set of Recognises a scorecard score with no evidence

dm-model-review C3: model reviewed by its modeller edu:Question

https://knobit.org/id/register/data-modelling#I-2103

dcterms:identifier	I-2103
rdfs:label	dm-model-review C3: model reviewed by its modeller en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C3 (2 points)
solvable with	set of Recognises a model reviewed by its modeller

dm-model-review C4: approved below the threshold edu:Question

https://knobit.org/id/register/data-modelling#I-2104

dcterms:identifier	I-2104
rdfs:label	dm-model-review C4: approved below the threshold en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C4 (2 points)
solvable with	set of Recognises a review decision contradicting its total

dm-model-review C5: review finding with no owner or action edu:Question

https://knobit.org/id/register/data-modelling#I-2105

dcterms:identifier	I-2105
rdfs:label	dm-model-review C5: review finding with no owner or action en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C5 (2 points)
solvable with	set of Recognises a review finding with no owner or action

dm-model-review C6: full structural score against validator errors edu:Question

https://knobit.org/id/register/data-modelling#I-2106

dcterms:identifier	I-2106
rdfs:label	dm-model-review C6: full structural score against validator errors en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C6 (2 points)
solvable with	set of Recognises a scorecard score contradicting the validator

dm-model-review C7: review of a version other than the one released edu:Question

https://knobit.org/id/register/data-modelling#I-2107

dcterms:identifier	I-2107
rdfs:label	dm-model-review C7: review of a version other than the one released en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C7 (2 points)
solvable with	set of Recognises a review of a version other than the one released

dm-model-review I1: complete scorecard with evidence per category edu:Question

https://knobit.org/id/register/data-modelling#I-2108

dcterms:identifier	I-2108
rdfs:label	dm-model-review I1: complete scorecard with evidence per category en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I1 (2 points)
solvable with	set of Scores a data model against the Data Model Scorecard

dm-model-review I2: scores follow the validator, trace, definitions and profiling edu:Question

https://knobit.org/id/register/data-modelling#I-2109

dcterms:identifier	I-2109
rdfs:label	dm-model-review I2: scores follow the validator, trace, definitions and profiling en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I2 (2 points)
solvable with	set of Scores a data model against the Data Model Scorecard

dm-model-review I3: total and decision against the threshold edu:Question

https://knobit.org/id/register/data-modelling#I-2110

dcterms:identifier	I-2110
rdfs:label	dm-model-review I3: total and decision against the threshold en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I3 (2 points)
solvable with	set of Scores a data model against the Data Model Scorecard

dm-model-review I4: blocking findings with owner, action and due date edu:Question

https://knobit.org/id/register/data-modelling#I-2111

dcterms:identifier	I-2111
rdfs:label	dm-model-review I4: blocking findings with owner, action and due date en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I4 (2 points)
solvable with	set of Scores a data model against the Data Model Scorecard

dm-reverse-engineering C1: inferred relationship with no evidence or confidence edu:Question

https://knobit.org/id/register/data-modelling#I-2201

dcterms:identifier	I-2201
rdfs:label	dm-reverse-engineering C1: inferred relationship with no evidence or confidence en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C1 (2 points)
solvable with	set of Recognises an inferred structure presented as declared

dm-reverse-engineering C2: produced table not marked as-is edu:Question

https://knobit.org/id/register/data-modelling#I-2202

dcterms:identifier	I-2202
rdfs:label	dm-reverse-engineering C2: produced table not marked as-is en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C2 (2 points)
solvable with	set of Recognises reverse-engineered objects not marked as-is

dm-reverse-engineering C3: dead table lifted into the model edu:Question

https://knobit.org/id/register/data-modelling#I-2203

dcterms:identifier	I-2203
rdfs:label	dm-reverse-engineering C3: dead table lifted into the model en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C3 (2 points)
solvable with	set of Recognises a dead database object carried into the model

dm-reverse-engineering C4: guessed indicator meaning written as a definition edu:Question

https://knobit.org/id/register/data-modelling#I-2204

dcterms:identifier	I-2204
rdfs:label	dm-reverse-engineering C4: guessed indicator meaning written as a definition en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C4 (2 points)
solvable with	set of Recognises a guessed meaning written as a definition

dm-reverse-engineering C5: replica catalogue read with no date edu:Question

https://knobit.org/id/register/data-modelling#I-2205

dcterms:identifier	I-2205
rdfs:label	dm-reverse-engineering C5: replica catalogue read with no date en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C5 (2 points)
solvable with	set of Recognises a reverse-engineering source with no environment or date

dm-reverse-engineering C6: report copy lifted as a logical attribute edu:Question

https://knobit.org/id/register/data-modelling#I-2206

dcterms:identifier	I-2206
rdfs:label	dm-reverse-engineering C6: report copy lifted as a logical attribute en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C6 (2 points)
solvable with	set of Recognises a physical workaround lifted into the logical model

dm-reverse-engineering I1: entities, associative entity and keys recovered edu:Question

https://knobit.org/id/register/data-modelling#I-2207

dcterms:identifier	I-2207
rdfs:label	dm-reverse-engineering I1: entities, associative entity and keys recovered en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I1 (2 points)
solvable with	set of Reverse-engineers a logical model from a database schema

dm-reverse-engineering I2: declared and inferred relationships kept apart edu:Question

https://knobit.org/id/register/data-modelling#I-2208

dcterms:identifier	I-2208
rdfs:label	dm-reverse-engineering I2: declared and inferred relationships kept apart en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I2 (2 points)
solvable with	set of Reverse-engineers a logical model from a database schema

dm-reverse-engineering I3: dead conversion table left out edu:Question

https://knobit.org/id/register/data-modelling#I-2209

dcterms:identifier	I-2209
rdfs:label	dm-reverse-engineering I3: dead conversion table left out en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I3 (1 points)
solvable with	set of Reverse-engineers a logical model from a database schema

dm-reverse-engineering I4: unexplained column and code asked of the owner edu:Question

https://knobit.org/id/register/data-modelling#I-2210

dcterms:identifier	I-2210
rdfs:label	dm-reverse-engineering I4: unexplained column and code asked of the owner en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I4 (2 points)
solvable with	set of Reverse-engineers a logical model from a database schema

dm-reverse-engineering I5: report copy table kept physical edu:Question

https://knobit.org/id/register/data-modelling#I-2211

dcterms:identifier	I-2211
rdfs:label	dm-reverse-engineering I5: report copy table kept physical en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I5 (1 points)
solvable with	set of Reverse-engineers a logical model from a database schema

dm-maintenance C1: model change with no reason edu:Question

https://knobit.org/id/register/data-modelling#I-2301

dcterms:identifier	I-2301
rdfs:label	dm-maintenance C1: model change with no reason en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C1 (2 points)
solvable with	set of Recognises a model change with no reason

dm-maintenance C2: deprecated column with no impact analysis edu:Question

https://knobit.org/id/register/data-modelling#I-2302

dcterms:identifier	I-2302
rdfs:label	dm-maintenance C2: deprecated column with no impact analysis en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C2 (2 points)
solvable with	set of Recognises a model change with no impact analysis

dm-maintenance C3: change of meaning released as a minor version edu:Question

https://knobit.org/id/register/data-modelling#I-2303

dcterms:identifier	I-2303
rdfs:label	dm-maintenance C3: change of meaning released as a minor version en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C3 (2 points)
solvable with	set of Recognises a breaking model change released as a minor version

dm-maintenance C4: deployed column renamed with no migration edu:Question

https://knobit.org/id/register/data-modelling#I-2304

dcterms:identifier	I-2304
rdfs:label	dm-maintenance C4: deployed column renamed with no migration en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C4 (2 points)
solvable with	set of Recognises a change to a deployed structure with no migration

dm-maintenance C5: release with no baseline edu:Question

https://knobit.org/id/register/data-modelling#I-2305

dcterms:identifier	I-2305
rdfs:label	dm-maintenance C5: release with no baseline en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C5 (2 points)
solvable with	set of Recognises a released model version with no baseline

dm-maintenance C6: change released without approval edu:Question

https://knobit.org/id/register/data-modelling#I-2306

dcterms:identifier	I-2306
rdfs:label	dm-maintenance C6: change released without approval en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C6 (2 points)
solvable with	set of Recognises a model change released without approval

dm-maintenance I1: column drop released as a major version edu:Question

https://knobit.org/id/register/data-modelling#I-2307

dcterms:identifier	I-2307
rdfs:label	dm-maintenance I1: column drop released as a major version en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I1 (2 points)
solvable with	set of Releases a model change as a new model version

dm-maintenance I2: reason and impact including the regulatory return edu:Question

https://knobit.org/id/register/data-modelling#I-2308

dcterms:identifier	I-2308
rdfs:label	dm-maintenance I2: reason and impact including the regulatory return en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I2 (2 points)
solvable with	set of Releases a model change as a new model version

dm-maintenance I3: expand-and-contract migration with rollback edu:Question

https://knobit.org/id/register/data-modelling#I-2309

dcterms:identifier	I-2309
rdfs:label	dm-maintenance I3: expand-and-contract migration with rollback en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I3 (2 points)
solvable with	set of Releases a model change as a new model version

dm-maintenance I4: baseline tag and the plan's approver edu:Question

https://knobit.org/id/register/data-modelling#I-2310

dcterms:identifier	I-2310
rdfs:label	dm-maintenance I4: baseline tag and the plan's approver en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I4 (2 points)
solvable with	set of Releases a model change as a new model version

dm-design-schemes C1: star schema for card authorisations edu:Question

https://knobit.org/id/register/data-modelling#I-2401

dcterms:identifier	I-2401
rdfs:label	dm-design-schemes C1: star schema for card authorisations en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C1 (2 points)
solvable with	set of Designs a star schema for a stated grain

dm-design-schemes C2: Data Vault for customers and accounts from two sources edu:Question

https://knobit.org/id/register/data-modelling#I-2402

dcterms:identifier	I-2402
rdfs:label	dm-design-schemes C2: Data Vault for customers and accounts from two sources en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C2 (2 points)
solvable with	set of Designs a Data Vault model for auditable history

dm-design-schemes C3: document per account-month for the mobile statement edu:Question

https://knobit.org/id/register/data-modelling#I-2403

dcterms:identifier	I-2403
rdfs:label	dm-design-schemes C3: document per account-month for the mobile statement en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C3 (2 points)
solvable with	set of Designs a document structure for a stated access pattern

dm-design-schemes C4: view over partitioned balance history edu:Question

https://knobit.org/id/register/data-modelling#I-2404

dcterms:identifier	I-2404
rdfs:label	dm-design-schemes C4: view over partitioned balance history en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C4 (2 points)
solvable with	set of Designs views hiding physical structure from consumers

dm-design-schemes C5: loans and collateral as a UML class diagram edu:Question

https://knobit.org/id/register/data-modelling#I-2405

dcterms:identifier	I-2405
rdfs:label	dm-design-schemes C5: loans and collateral as a UML class diagram en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C5 (2 points)
solvable with	set of Expresses a logical model as a UML class diagram

dm-design-schemes C6: account holding as fact types edu:Question

https://knobit.org/id/register/data-modelling#I-2406

dcterms:identifier	I-2406
rdfs:label	dm-design-schemes C6: account holding as fact types en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C6 (2 points)
solvable with	set of Models data as fact types in a fact-based scheme

dm-design-schemes C7: card customer record onto the canonical party model edu:Question

https://knobit.org/id/register/data-modelling#I-2407

dcterms:identifier	I-2407
rdfs:label	dm-design-schemes C7: card customer record onto the canonical party model en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C7 (2 points)
solvable with	set of Maps an application model onto a canonical model

party-taxonomy C1: person and organisation as kinds of party edu:Question

https://knobit.org/id/register/data-modelling#I-401

dcterms:identifier	I-401
rdfs:label	party-taxonomy C1: person and organisation as kinds of party en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C1 (2 points)
solvable with	set of Recognises a link failing the all-and-some test

party-taxonomy C2 and C3: customer and supplier as roles edu:Question

https://knobit.org/id/register/data-modelling#I-402

dcterms:identifier	I-402
rdfs:label	party-taxonomy C2 and C3: customer and supplier as roles en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C2 (4 points)
schema:isPartOf	C3 (3 points)
solvable with	set of Recognises a link failing the all-and-some test, Models a role as an association to the party playing it

party-taxonomy I2: generalisation constraints and role cardinality edu:Question

https://knobit.org/id/register/data-modelling#I-403

dcterms:identifier	I-403
rdfs:label	party-taxonomy I2: generalisation constraints and role cardinality en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I2 (3 points)
solvable with	set of Models a role as an association to the party playing it, Recognises undeclared subtype constraints

party-taxonomy Q1: no gratuitous derived classes edu:Question

https://knobit.org/id/register/data-modelling#I-404

dcterms:identifier	I-404
rdfs:label	party-taxonomy Q1: no gratuitous derived classes en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q1 (1 points)
solvable with	set of Recognises a node without warrant

taxonomy-from-definitions C1 and C3: broader concept from the definition head edu:Question

https://knobit.org/id/register/data-modelling#I-405

dcterms:identifier	I-405
rdfs:label	taxonomy-from-definitions C1 and C3: broader concept from the definition head en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C1 (4 points)
schema:isPartOf	C3 (4 points)
solvable with	set of Derives the broader concept from the head of a definition

taxonomy-from-definitions C2: synonyms resolved edu:Question

https://knobit.org/id/register/data-modelling#I-406

dcterms:identifier	I-406
rdfs:label	taxonomy-from-definitions C2: synonyms resolved en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C2 (2 points)
solvable with	set of Recognises a synonym kept as a separate node, Derives the broader concept from the head of a definition

taxonomy-from-definitions C4: justified polyhierarchy edu:Question

https://knobit.org/id/register/data-modelling#I-407

dcterms:identifier	I-407
rdfs:label	taxonomy-from-definitions C4: justified polyhierarchy en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C4 (2 points)
solvable with	set of Recognises an unjustified polyhierarchy

taxonomy-from-definitions C5: part-of kept out of the hierarchy edu:Question

https://knobit.org/id/register/data-modelling#I-408

dcterms:identifier	I-408
rdfs:label	taxonomy-from-definitions C5: part-of kept out of the hierarchy en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C5 (2 points)
solvable with	set of Recognises a part-of link in a kind-of hierarchy

taxonomy-from-definitions C6: roots with their missing broader concepts edu:Question

https://knobit.org/id/register/data-modelling#I-409

dcterms:identifier	I-409
rdfs:label	taxonomy-from-definitions C6: roots with their missing broader concepts en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C6 (2 points)
solvable with	set of Recognises a structural error in a taxonomy hierarchy, Derives the broader concept from the head of a definition

taxonomy-from-definitions C7: no extra kind-of links edu:Question

https://knobit.org/id/register/data-modelling#I-410

dcterms:identifier	I-410
rdfs:label	taxonomy-from-definitions C7: no extra kind-of links en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C7 (2 points)
solvable with	set of Recognises a link failing the all-and-some test

dm-taxonomy-notes C1: one label for customer and general ledger account edu:Question

https://knobit.org/id/register/data-modelling#I-411

dcterms:identifier	I-411
rdfs:label	dm-taxonomy-notes C1: one label for customer and general ledger account en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C1 (1.5 points)
solvable with	set of Recognises an ambiguous node label

dm-taxonomy-notes C2: catch-all node given a scope note edu:Question

https://knobit.org/id/register/data-modelling#I-412

dcterms:identifier	I-412
rdfs:label	dm-taxonomy-notes C2: catch-all node given a scope note en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C2 (1 points)
solvable with	set of Recognises a node with an unclear boundary and no scope note

dm-taxonomy-notes C3: overlapping segments given reciprocal scope notes edu:Question

https://knobit.org/id/register/data-modelling#I-413

dcterms:identifier	I-413
rdfs:label	dm-taxonomy-notes C3: overlapping segments given reciprocal scope notes en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C3 (1.5 points)
solvable with	set of Recognises overlapping sibling nodes without reciprocal scope notes

dm-taxonomy-notes C4: segment widened in place given a history note edu:Question

https://knobit.org/id/register/data-modelling#I-414

dcterms:identifier	I-414
rdfs:label	dm-taxonomy-notes C4: segment widened in place given a history note en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C4 (1.5 points)
solvable with	set of Recognises a meaning change without a history note

dm-taxonomy-notes C5: sibling labels of mixed form edu:Question

https://knobit.org/id/register/data-modelling#I-415

dcterms:identifier	I-415
rdfs:label	dm-taxonomy-notes C5: sibling labels of mixed form en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C5 (1 points)
solvable with	set of Recognises inconsistent node label forms

dm-taxonomy-notes C6: system name and jargon as node labels edu:Question

https://knobit.org/id/register/data-modelling#I-416

dcterms:identifier	I-416
rdfs:label	dm-taxonomy-notes C6: system name and jargon as node labels en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C6 (1.5 points)
solvable with	set of Recognises an abbreviation, jargon or system name as a node label

dm-taxonomy-notes C7: payment nodes combining reach and settlement speed edu:Question

https://knobit.org/id/register/data-modelling#I-417

dcterms:identifier	I-417
rdfs:label	dm-taxonomy-notes C7: payment nodes combining reach and settlement speed en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C7 (1.5 points)
solvable with	set of Recognises a compound node combining two characteristics

dm-taxonomy-notes C8: value segment mixed with legal-form segments edu:Question

https://knobit.org/id/register/data-modelling#I-418

dcterms:identifier	I-418
rdfs:label	dm-taxonomy-notes C8: value segment mixed with legal-form segments en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C8 (1.5 points)
solvable with	set of Recognises siblings divided by mixed characteristics

dm-taxonomy-notes C9: named banks as nodes edu:Question

https://knobit.org/id/register/data-modelling#I-419

dcterms:identifier	I-419
rdfs:label	dm-taxonomy-notes C9: named banks as nodes en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C9 (1 points)
solvable with	set of Recognises an instance placed as a concept node

dm-taxonomy-notes C10: credit assessment and agreement document under Loan edu:Question

https://knobit.org/id/register/data-modelling#I-420

dcterms:identifier	I-420
rdfs:label	dm-taxonomy-notes C10: credit assessment and agreement document under Loan en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C10 (1.5 points)
solvable with	set of Recognises an associative relationship shown as a hierarchy

dm-taxonomy-notes C11: parent and children disagreeing edu:Question

https://knobit.org/id/register/data-modelling#I-421

dcterms:identifier	I-421
rdfs:label	dm-taxonomy-notes C11: parent and children disagreeing en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C11 (1 points)
solvable with	set of Recognises non-reciprocal hierarchy links

dm-taxonomy-notes C12: home equity mortgage beside Mortgage edu:Question

https://knobit.org/id/register/data-modelling#I-422

dcterms:identifier	I-422
rdfs:label	dm-taxonomy-notes C12: home equity mortgage beside Mortgage en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C12 (1 points)
solvable with	set of Recognises uneven levels of specificity among siblings

dm-taxonomy-notes C13: home-grown purpose list and copied activity classification edu:Question

https://knobit.org/id/register/data-modelling#I-423

dcterms:identifier	I-423
rdfs:label	dm-taxonomy-notes C13: home-grown purpose list and copied activity classification en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C13 (2 points)
solvable with	set of Recognises a home-grown copy of an existing vocabulary

dm-taxonomy-notes C14: node deleted while accounts refer to it edu:Question

https://knobit.org/id/register/data-modelling#I-424

dcterms:identifier	I-424
rdfs:label	dm-taxonomy-notes C14: node deleted while accounts refer to it en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C14 (1.5 points)
solvable with	set of Recognises a taxonomy node deleted while data still refers to it

dm-taxonomy-notes C15: retired product id reused for a new product edu:Question

https://knobit.org/id/register/data-modelling#I-425

dcterms:identifier	I-425
rdfs:label	dm-taxonomy-notes C15: retired product id reused for a new product en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C15 (1.5 points)
solvable with	set of Recognises a node code reused for a different concept

logical-model C1: insertion anomaly traced to the collateral repeating group edu:Question

https://knobit.org/id/register/data-modelling#I-501

dcterms:identifier	I-501
rdfs:label	logical-model C1: insertion anomaly traced to the collateral repeating group en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C1 (4 points)
solvable with	set of Recognises an insertion anomaly in a logical data model, Recognises a repeating group in an entity, Traces a logical-model anomaly to its structural cause

logical-model C1: update anomaly traced to the branch transitive dependency edu:Question

https://knobit.org/id/register/data-modelling#I-502

dcterms:identifier	I-502
rdfs:label	logical-model C1: update anomaly traced to the branch transitive dependency en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C1 (4 points)
solvable with	set of Recognises an update anomaly in a logical data model, Recognises a transitive dependency between non-key attributes, Traces a logical-model anomaly to its structural cause

logical-model C1: deletion anomaly traced to the snapshot held nowhere else edu:Question

https://knobit.org/id/register/data-modelling#I-503

dcterms:identifier	I-503
rdfs:label	logical-model C1: deletion anomaly traced to the snapshot held nowhere else en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C1 (4 points)
solvable with	set of Recognises a deletion anomaly in a logical data model, Traces a logical-model anomaly to its structural cause

logical-model C2: many-to-many resolved into an associative entity edu:Question

https://knobit.org/id/register/data-modelling#I-504

dcterms:identifier	I-504
rdfs:label	logical-model C2: many-to-many resolved into an associative entity en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C2 (2 points)
solvable with	set of Resolves a many-to-many relationship into an associative entity

logical-model C3a: assessment snapshots kept and marked, not removed edu:Question

https://knobit.org/id/register/data-modelling#I-505

dcterms:identifier	I-505
rdfs:label	logical-model C3a: assessment snapshots kept and marked, not removed en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C3 (2 points)
solvable with	set of Recognises a stored derivable attribute

logical-model I1a: collateral repeating group becomes its own entity edu:Question

https://knobit.org/id/register/data-modelling#I-506

dcterms:identifier	I-506
rdfs:label	logical-model I1a: collateral repeating group becomes its own entity en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I1 (2 points)
solvable with	set of Recognises a repeating group in an entity, Replaces a repeating group with a dependent entity

logical-model I1b: CUSTOMER.address split edu:Question

https://knobit.org/id/register/data-modelling#I-507

dcterms:identifier	I-507
rdfs:label	logical-model I1b: CUSTOMER.address split en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I1 (2 points)
solvable with	set of Recognises an attribute holding several facts

logical-model I2a: branch attributes moved to a Branch entity edu:Question

https://knobit.org/id/register/data-modelling#I-508

dcterms:identifier	I-508
rdfs:label	logical-model I2a: branch attributes moved to a Branch entity en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I2 (2 points)
solvable with	set of Recognises a transitive dependency between non-key attributes, Decomposes an entity along a functional dependency without loss

logical-model I2b: functional dependencies written down edu:Question

https://knobit.org/id/register/data-modelling#I-509

dcterms:identifier	I-509
rdfs:label	logical-model I2b: functional dependencies written down en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I2 (2 points)
solvable with	set of Records the functional dependencies of an entity

logical-model I3: stored derivable attributes removed or given a derivation edu:Question

https://knobit.org/id/register/data-modelling#I-510

dcterms:identifier	I-510
rdfs:label	logical-model I3: stored derivable attributes removed or given a derivation en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I3 (2 points)
solvable with	set of Recognises a stored derivable attribute

logical-model I4a: employed and self-employed subtypes edu:Question

https://knobit.org/id/register/data-modelling#I-511

dcterms:identifier	I-511
rdfs:label	logical-model I4a: employed and self-employed subtypes en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I4 (2 points)
solvable with	set of Recognises attributes inapplicable to some instances, Introduces subtypes for attributes applying to only some instances

logical-model I4b: subtype constraints declared edu:Question

https://knobit.org/id/register/data-modelling#I-512

dcterms:identifier	I-512
rdfs:label	logical-model I4b: subtype constraints declared en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I4 (2 points)
solvable with	set of Recognises undeclared subtype constraints

logical-model I5: unstable meaningful key replaced, natural key kept edu:Question

https://knobit.org/id/register/data-modelling#I-513

dcterms:identifier	I-513
rdfs:label	logical-model I5: unstable meaningful key replaced, natural key kept en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I5 (1 points)
solvable with	set of Recognises an unstable or meaningful primary key

logical-model Q1: no relationship contradicts a rule edu:Question

https://knobit.org/id/register/data-modelling#I-514

dcterms:identifier	I-514
rdfs:label	logical-model Q1: no relationship contradicts a rule en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q1 (0.5 points)
solvable with	set of Recognises a relationship contradicting its data rule

logical-model C4: many-to-many not left unresolved edu:Question

https://knobit.org/id/register/data-modelling#I-515

dcterms:identifier	I-515
rdfs:label	logical-model C4: many-to-many not left unresolved en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C4 (1 points)
solvable with	set of Recognises an unresolved many-to-many relationship

logical-model Q3: redundant relationship removed edu:Question

https://knobit.org/id/register/data-modelling#I-516

dcterms:identifier	I-516
rdfs:label	logical-model Q3: redundant relationship removed en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q3 (0.5 points)
solvable with	set of Recognises a redundant relationship

dm-logical-integrity C1: advisor determinant that is not a key (BCNF) edu:Question

https://knobit.org/id/register/data-modelling#I-517

dcterms:identifier	I-517
rdfs:label	dm-logical-integrity C1: advisor determinant that is not a key (BCNF) en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C1 (2 points)
solvable with	set of Recognises a non-superkey determinant in a 3NF entity

dm-logical-integrity C2: dependencies lost by the routing split and by the answer's own split edu:Question

https://knobit.org/id/register/data-modelling#I-518

dcterms:identifier	I-518
rdfs:label	dm-logical-integrity C2: dependencies lost by the routing split and by the answer's own split en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C2 (2 points)
solvable with	set of Recognises a functional dependency lost in a decomposition

dm-logical-integrity C3: lossy split of card issue on the role code edu:Question

https://knobit.org/id/register/data-modelling#I-519

dcterms:identifier	I-519
rdfs:label	dm-logical-integrity C3: lossy split of card issue on the role code en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C3 (2 points)
solvable with	set of Recognises a lossy decomposition

dm-logical-integrity C4: broker join dependency decomposed, signatory authority kept whole edu:Question

https://knobit.org/id/register/data-modelling#I-520

dcterms:identifier	I-520
rdfs:label	dm-logical-integrity C4: broker join dependency decomposed, signatory authority kept whole en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C4 (2 points)
solvable with	set of Recognises a join dependency kept in one entity

dm-logical-integrity C5: connection trap in the broker commission report edu:Question

https://knobit.org/id/register/data-modelling#I-521

dcterms:identifier	I-521
rdfs:label	dm-logical-integrity C5: connection trap in the broker commission report en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C5 (2 points)
solvable with	set of Recognises a connection trap

dm-logical-integrity C6: fan trap between card and card transaction edu:Question

https://knobit.org/id/register/data-modelling#I-522

dcterms:identifier	I-522
rdfs:label	dm-logical-integrity C6: fan trap between card and card transaction en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C6 (1 points)
solvable with	set of Recognises a fan trap

dm-logical-integrity C7: chasm trap through the optional advisor edu:Question

https://knobit.org/id/register/data-modelling#I-523

dcterms:identifier	I-523
rdfs:label	dm-logical-integrity C7: chasm trap through the optional advisor en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C7 (1 points)
solvable with	set of Recognises a chasm trap

dm-logical-integrity I1: card settings as name-value rows, waived product features kept edu:Question

https://knobit.org/id/register/data-modelling#I-524

dcterms:identifier	I-524
rdfs:label	dm-logical-integrity I1: card settings as name-value rows, waived product features kept en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I1 (2 points)
solvable with	set of Recognises attributes held as name-value rows

dm-logical-integrity I2: loan attributes on the instalment (partial dependency) edu:Question

https://knobit.org/id/register/data-modelling#I-525

dcterms:identifier	I-525
rdfs:label	dm-logical-integrity I2: loan attributes on the instalment (partial dependency) en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I2 (1 points)
solvable with	set of Recognises a partial dependency on a composite key

dm-logical-integrity I3: branch languages and accessibility features in one entity (4NF) edu:Question

https://knobit.org/id/register/data-modelling#I-526

dcterms:identifier	I-526
rdfs:label	dm-logical-integrity I3: branch languages and accessibility features in one entity (4NF) en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I3 (1 points)
solvable with	set of Recognises independent multi-valued facts in one entity

dm-logical-integrity I4: loan histories split, exchange rate kept together edu:Question

https://knobit.org/id/register/data-modelling#I-527

dcterms:identifier	I-527
rdfs:label	dm-logical-integrity I4: loan histories split, exchange rate kept together en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I4 (2 points)
solvable with	set of Recognises independently changing histories in one entity

dm-logical-integrity I5: polymorphic complaint subject edu:Question

https://knobit.org/id/register/data-modelling#I-528

dcterms:identifier	I-528
rdfs:label	dm-logical-integrity I5: polymorphic complaint subject en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I5 (1 points)
solvable with	set of Recognises a polymorphic association

dm-logical-integrity I6: retail customer and card holder overlap edu:Question

https://knobit.org/id/register/data-modelling#I-529

dcterms:identifier	I-529
rdfs:label	dm-logical-integrity I6: retail customer and card holder overlap en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I6 (1 points)
solvable with	set of Recognises overlapping entities

dm-logical-integrity I7: direct debit mandates split by country edu:Question

https://knobit.org/id/register/data-modelling#I-530

dcterms:identifier	I-530
rdfs:label	dm-logical-integrity I7: direct debit mandates split by country en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I7 (1 points)
solvable with	set of Recognises one entity split by value into several

dm-logical-integrity I8: account domains and closing-date rule not implied by keys and domains edu:Question

https://knobit.org/id/register/data-modelling#I-531

dcterms:identifier	I-531
rdfs:label	dm-logical-integrity I8: account domains and closing-date rule not implied by keys and domains en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I8 (2 points)
solvable with	set of Recognises a constraint implied by neither keys nor domains

dm-logical-integrity I9: card limit amount with two meanings edu:Question

https://knobit.org/id/register/data-modelling#I-532

dcterms:identifier	I-532
rdfs:label	dm-logical-integrity I9: card limit amount with two meanings en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I9 (1 points)
solvable with	set of Recognises an attribute with several meanings

dm-logical-integrity I10: business customer identified only by a system key, complaint reference kept edu:Question

https://knobit.org/id/register/data-modelling#I-533

dcterms:identifier	I-533
rdfs:label	dm-logical-integrity I10: business customer identified only by a system key, complaint reference kept en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I10 (2 points)
solvable with	set of Recognises an entity identified only by a system-assigned key

physical-model C1: deliberate snapshot kept, not reported as a duplicate edu:Question

https://knobit.org/id/register/data-modelling#I-601

dcterms:identifier	I-601
rdfs:label	physical-model C1: deliberate snapshot kept, not reported as a duplicate en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C1 (3 points)
solvable with	set of Recognises an unmanaged duplicate column

physical-model C2: logical defect routed upstream, not fixed here edu:Question

https://knobit.org/id/register/data-modelling#I-602

dcterms:identifier	I-602
rdfs:label	physical-model C2: logical defect routed upstream, not fixed here en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C2 (3 points)
solvable with	set of Recognises an attribute holding several facts, Routes a defect to the deliverable responsible for it

physical-model C3: mixed grain found and resolved edu:Question

https://knobit.org/id/register/data-modelling#I-603

dcterms:identifier	I-603
rdfs:label	physical-model C3: mixed grain found and resolved en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C3 (2 points)
solvable with	set of Recognises a fact table of mixed grain

physical-model I1: unenforced constraints kept and checked edu:Question

https://knobit.org/id/register/data-modelling#I-604

dcterms:identifier	I-604
rdfs:label	physical-model I1: unenforced constraints kept and checked en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I1 (2 points)
solvable with	set of Recognises a declared constraint the target platform does not enforce

physical-model I2a: surrogate key without natural-key uniqueness edu:Question

https://knobit.org/id/register/data-modelling#I-605

dcterms:identifier	I-605
rdfs:label	physical-model I2a: surrogate key without natural-key uniqueness en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I2 (2 points)
solvable with	set of Recognises a surrogate key without natural-key uniqueness

physical-model I2b: versioned dimension referenced by business key edu:Question

https://knobit.org/id/register/data-modelling#I-606

dcterms:identifier	I-606
rdfs:label	physical-model I2b: versioned dimension referenced by business key en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I2 (2 points)
solvable with	set of Recognises a reference to a versioned table by business key alone

physical-model I3: rolled-up subtypes given a discriminator and a check edu:Question

https://knobit.org/id/register/data-modelling#I-607

dcterms:identifier	I-607
rdfs:label	physical-model I3: rolled-up subtypes given a discriminator and a check en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I3 (2 points)
solvable with	set of Recognises rolled-up subtypes losing conditional constraints

physical-model I4a: FLOAT for money edu:Question

https://knobit.org/id/register/data-modelling#I-608

dcterms:identifier	I-608
rdfs:label	physical-model I4a: FLOAT for money en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I4 (2 points)
solvable with	set of Recognises binary floating point used for an exact quantity

physical-model I4b: sentinel date replaced edu:Question

https://knobit.org/id/register/data-modelling#I-609

dcterms:identifier	I-609
rdfs:label	physical-model I4b: sentinel date replaced en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I4 (2 points)
solvable with	set of Recognises a sentinel value standing in for null

physical-model I5a: copied branch name edu:Question

https://knobit.org/id/register/data-modelling#I-610

dcterms:identifier	I-610
rdfs:label	physical-model I5a: copied branch name en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I5 (2 points)
solvable with	set of Recognises an unmanaged duplicate column

physical-model I5b: stored sum without derivation edu:Question

https://knobit.org/id/register/data-modelling#I-611

dcterms:identifier	I-611
rdfs:label	physical-model I5b: stored sum without derivation en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I5 (2 points)
solvable with	set of Recognises a stored derived or summary value

physical-model Q1a: validity periods consistently bounded edu:Question

https://knobit.org/id/register/data-modelling#I-612

dcterms:identifier	I-612
rdfs:label	physical-model Q1a: validity periods consistently bounded en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q1 (2 points)
solvable with	set of Recognises inconsistent validity periods in a versioned table

physical-model Q1b: one current version per customer edu:Question

https://knobit.org/id/register/data-modelling#I-613

dcterms:identifier	I-613
rdfs:label	physical-model Q1b: one current version per customer en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q1 (2 points)
solvable with	set of Recognises history kept without its constraints checked

dm-physical-postgres C1: destructive referential actions changed, schedule-line cascade kept edu:Question

https://knobit.org/id/register/data-modelling#I-614

dcterms:identifier	I-614
rdfs:label	dm-physical-postgres C1: destructive referential actions changed, schedule-line cascade kept en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C1 (2 points)
solvable with	set of Recognises a referential action destroying what should survive

dm-physical-postgres C2: soft-deleted customers and the constraints edu:Question

https://knobit.org/id/register/data-modelling#I-615

dcterms:identifier	I-615
rdfs:label	dm-physical-postgres C2: soft-deleted customers and the constraints en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C2 (2 points)
solvable with	set of Recognises a soft delete the constraints do not understand

dm-physical-postgres C3: index set derived from access paths edu:Question

https://knobit.org/id/register/data-modelling#I-616

dcterms:identifier	I-616
rdfs:label	dm-physical-postgres C3: index set derived from access paths en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C3 (2 points)
solvable with	set of Recognises an index set not derived from access paths

dm-physical-postgres C4: savings rate history, email overwrite kept edu:Question

https://knobit.org/id/register/data-modelling#I-617

dcterms:identifier	I-617
rdfs:label	dm-physical-postgres C4: savings rate history, email overwrite kept en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C4 (2 points)
solvable with	set of Recognises an overwrite where history is required

dm-physical-postgres I1: branch merged into account edu:Question

https://knobit.org/id/register/data-modelling#I-618

dcterms:identifier	I-618
rdfs:label	dm-physical-postgres I1: branch merged into account en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I1 (1 points)
solvable with	set of Recognises logical entities merged into one table

dm-physical-postgres I2: overdraft terms split without an enforced one-to-one edu:Question

https://knobit.org/id/register/data-modelling#I-619

dcterms:identifier	I-619
rdfs:label	dm-physical-postgres I2: overdraft terms split without an enforced one-to-one en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I2 (1 points)
solvable with	set of Recognises a lossy or unconstrained vertical split

dm-physical-postgres I3: card transactions in clone tables by year edu:Question

https://knobit.org/id/register/data-modelling#I-620

dcterms:identifier	I-620
rdfs:label	dm-physical-postgres I3: card transactions in clone tables by year en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I3 (1 points)
solvable with	set of Recognises an entity split into clone tables by value

dm-physical-postgres I4: customer subtypes rolled down with no supertype edu:Question

https://knobit.org/id/register/data-modelling#I-621

dcterms:identifier	I-621
rdfs:label	dm-physical-postgres I4: customer subtypes rolled down with no supertype en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I4 (1 points)
solvable with	set of Recognises rolled-down subtypes losing supertype constraints

dm-physical-postgres I5: product group hierarchy as a path string edu:Question

https://knobit.org/id/register/data-modelling#I-622

dcterms:identifier	I-622
rdfs:label	dm-physical-postgres I5: product group hierarchy as a path string en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I5 (1 points)
solvable with	set of Recognises a hierarchy encoded redundantly

dm-physical-postgres I6: loan document held on a file share by path edu:Question

https://knobit.org/id/register/data-modelling#I-623

dcterms:identifier	I-623
rdfs:label	dm-physical-postgres I6: loan document held on a file share by path en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I6 (1 points)
solvable with	set of Recognises content held outside the database by reference

dm-physical-postgres I7: meaningful loan_id printed as the loan number edu:Question

https://knobit.org/id/register/data-modelling#I-624

dcterms:identifier	I-624
rdfs:label	dm-physical-postgres I7: meaningful loan_id printed as the loan number en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I7 (1 points)
solvable with	set of Recognises a surrogate value with meaning, reused or renumbered

dm-physical-postgres I8: undeclared standing-order foreign key edu:Question

https://knobit.org/id/register/data-modelling#I-625

dcterms:identifier	I-625
rdfs:label	dm-physical-postgres I8: undeclared standing-order foreign key en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I8 (1 points)
solvable with	set of Recognises an undeclared foreign key

dm-physical-postgres I9: account status list fixed in a CHECK, debit/credit check kept edu:Question

https://knobit.org/id/register/data-modelling#I-626

dcterms:identifier	I-626
rdfs:label	dm-physical-postgres I9: account status list fixed in a CHECK, debit/credit check kept en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I9 (2 points)
solvable with	set of Recognises a changeable value list fixed in the DDL

dm-physical-postgres I10: current address read from key order edu:Question

https://knobit.org/id/register/data-modelling#I-627

dcterms:identifier	I-627
rdfs:label	dm-physical-postgres I10: current address read from key order en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I10 (1 points)
solvable with	set of Recognises a business fact held in physical row order

dm-physical-postgres I11: month-end measures without additivity edu:Question

https://knobit.org/id/register/data-modelling#I-628

dcterms:identifier	I-628
rdfs:label	dm-physical-postgres I11: month-end measures without additivity en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I11 (1 points)
solvable with	set of Recognises a measure without stated additivity

dm-physical-postgres I12: nullable channel on the payment volume join edu:Question

https://knobit.org/id/register/data-modelling#I-629

dcterms:identifier	I-629
rdfs:label	dm-physical-postgres I12: nullable channel on the payment volume join en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I12 (1 points)
solvable with	set of Recognises a nullable foreign key on a reporting join path

dm-physical-postgres I13: null meaning no ATM limit edu:Question

https://knobit.org/id/register/data-modelling#I-630

dcterms:identifier	I-630
rdfs:label	dm-physical-postgres I13: null meaning no ATM limit en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I13 (1 points)
solvable with	set of Recognises a null with a business meaning

ddl-review C1a and Q1b: fixes routed upstream, no hand edits edu:Question

https://knobit.org/id/register/data-modelling#I-801

dcterms:identifier	I-801
rdfs:label	ddl-review C1a and Q1b: fixes routed upstream, no hand edits en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C1 (3 points)
schema:isPartOf	Q1 (2 points)
solvable with	set of Routes a defect to the deliverable responsible for it, Recognises generated SQL edited by hand

ddl-review C1b and C1c: objects in the SQL and not in the model edu:Question

https://knobit.org/id/register/data-modelling#I-802

dcterms:identifier	I-802
rdfs:label	ddl-review C1b and C1c: objects in the SQL and not in the model en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C1 (3 points)
solvable with	set of Recognises an object in the SQL missing from the model

ddl-review C2a and C2b: unenforced keys on Snowflake, enforced on Postgres edu:Question

https://knobit.org/id/register/data-modelling#I-803

dcterms:identifier	I-803
rdfs:label	ddl-review C2a and C2b: unenforced keys on Snowflake, enforced on Postgres en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C2 (3 points)
solvable with	set of Recognises a declared constraint the target platform does not enforce

ddl-review C2c: CREATE INDEX on Snowflake edu:Question

https://knobit.org/id/register/data-modelling#I-804

dcterms:identifier	I-804
rdfs:label	ddl-review C2c: CREATE INDEX on Snowflake en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C2 (3 points)
solvable with	set of Recognises an index the target engine cannot create or run

ddl-review C3a: binary floating point for money edu:Question

https://knobit.org/id/register/data-modelling#I-805

dcterms:identifier	I-805
rdfs:label	ddl-review C3a: binary floating point for money en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C3 (2 points)
solvable with	set of Recognises binary floating point used for an exact quantity

ddl-review C3b: one scale for every currency edu:Question

https://knobit.org/id/register/data-modelling#I-806

dcterms:identifier	I-806
rdfs:label	ddl-review C3b: one scale for every currency en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C3 (2 points)
solvable with	set of Recognises one decimal scale for every currency

ddl-review I1a: constraint rule absent from the SQL edu:Question

https://knobit.org/id/register/data-modelling#I-807

dcterms:identifier	I-807
rdfs:label	ddl-review I1a: constraint rule absent from the SQL en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I1 (2 points)
solvable with	set of Recognises a constraint claimed by a rule and missing from the schema

ddl-review I1b: configured dialect unrendered edu:Question

https://knobit.org/id/register/data-modelling#I-808

dcterms:identifier	I-808
rdfs:label	ddl-review I1b: configured dialect unrendered en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I1 (2 points)
solvable with	set of Recognises a configured dialect left unregenerated

ddl-review I2a: truncated identifier edu:Question

https://knobit.org/id/register/data-modelling#I-809

dcterms:identifier	I-809
rdfs:label	ddl-review I2a: truncated identifier en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I2 (2 points)
solvable with	set of Recognises a truncated identifier taken as the real name

ddl-review I2b: CHECK ignored on MySQL 5.7 edu:Question

https://knobit.org/id/register/data-modelling#I-810

dcterms:identifier	I-810
rdfs:label	ddl-review I2b: CHECK ignored on MySQL 5.7 en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I2 (2 points)
solvable with	set of Recognises a CHECK constraint parsed and ignored

ddl-review I3a: IBAN length from the sample edu:Question

https://knobit.org/id/register/data-modelling#I-811

dcterms:identifier	I-811
rdfs:label	ddl-review I3a: IBAN length from the sample en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I3 (2 points)
solvable with	set of Recognises a length taken from sample data

ddl-review I3b: value date as a timestamp edu:Question

https://knobit.org/id/register/data-modelling#I-812

dcterms:identifier	I-812
rdfs:label	ddl-review I3b: value date as a timestamp en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I3 (2 points)
solvable with	set of Recognises a business date stored with a time of day

ddl-review I4a: DEFAULT 0 on a settled amount edu:Question

https://knobit.org/id/register/data-modelling#I-813

dcterms:identifier	I-813
rdfs:label	ddl-review I4a: DEFAULT 0 on a settled amount en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I4 (2 points)
solvable with	set of Recognises a default inventing a business fact

ddl-review I4b: restricted column without access design edu:Question

https://knobit.org/id/register/data-modelling#I-814

dcterms:identifier	I-814
rdfs:label	ddl-review I4b: restricted column without access design en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I4 (2 points)
solvable with	set of Recognises a restricted column without access design

ddl-review I5a: greenfield DDL against a populated table edu:Question

https://knobit.org/id/register/data-modelling#I-815

dcterms:identifier	I-815
rdfs:label	ddl-review I5a: greenfield DDL against a populated table en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I5 (2 points)
solvable with	set of Recognises greenfield DDL aimed at a populated database

ddl-review I5b: drop script as rollback edu:Question

https://knobit.org/id/register/data-modelling#I-816

dcterms:identifier	I-816
rdfs:label	ddl-review I5b: drop script as rollback en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I5 (2 points)
solvable with	set of Recognises a drop script used as a rollback

ddl-review Q1a: schema name baked in edu:Question

https://knobit.org/id/register/data-modelling#I-817

dcterms:identifier	I-817
rdfs:label	ddl-review Q1a: schema name baked in en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	Q1 (2 points)
solvable with	set of Recognises an environment baked into the script

dm-ddl-review-deploy C1: DDL older than its model edu:Question

https://knobit.org/id/register/data-modelling#I-818

dcterms:identifier	I-818
rdfs:label	dm-ddl-review-deploy C1: DDL older than its model en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C1 (2 points)
solvable with	set of Recognises DDL older than its model

dm-ddl-review-deploy C2: SQL approved by reading, never executed edu:Question

https://knobit.org/id/register/data-modelling#I-819

dcterms:identifier	I-819
rdfs:label	dm-ddl-review-deploy C2: SQL approved by reading, never executed en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C2 (2 points)
solvable with	set of Recognises SQL reviewed without being run

dm-ddl-review-deploy C3: production index in no model, no drift comparison edu:Question

https://knobit.org/id/register/data-modelling#I-820

dcterms:identifier	I-820
rdfs:label	dm-ddl-review-deploy C3: production index in no model, no drift comparison en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	C3 (2 points)
solvable with	set of Recognises undetected drift between database and model

dm-ddl-review-deploy I1: header warning carried without a decision edu:Question

https://knobit.org/id/register/data-modelling#I-821

dcterms:identifier	I-821
rdfs:label	dm-ddl-review-deploy I1: header warning carried without a decision en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I1 (2 points)
solvable with	set of Recognises generator warnings carried without a decision

dm-ddl-review-deploy I2: regex check running on one engine only edu:Question

https://knobit.org/id/register/data-modelling#I-822

dcterms:identifier	I-822
rdfs:label	dm-ddl-review-deploy I2: regex check running on one engine only en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I2 (2 points)
solvable with	set of Recognises an expression running on one engine only

dm-ddl-review-deploy I3: reserved word as a column name edu:Question

https://knobit.org/id/register/data-modelling#I-823

dcterms:identifier	I-823
rdfs:label	dm-ddl-review-deploy I3: reserved word as a column name en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I3 (2 points)
solvable with	set of Recognises a reserved word used as an identifier

dm-ddl-review-deploy I4: BOOLEAN meaning four things on five engines edu:Question

https://knobit.org/id/register/data-modelling#I-824

dcterms:identifier	I-824
rdfs:label	dm-ddl-review-deploy I4: BOOLEAN meaning four things on five engines en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I4 (2 points)
solvable with	set of Recognises a type meaning something else on another engine

dm-ddl-review-deploy I5: mandatory foreign-key cycle taken as resolved edu:Question

https://knobit.org/id/register/data-modelling#I-825

dcterms:identifier	I-825
rdfs:label	dm-ddl-review-deploy I5: mandatory foreign-key cycle taken as resolved en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I5 (2 points)
solvable with	set of Recognises a foreign-key cycle taken as resolved

dm-ddl-review-deploy I6: collation deciding what the IBAN key means edu:Question

https://knobit.org/id/register/data-modelling#I-826

dcterms:identifier	I-826
rdfs:label	dm-ddl-review-deploy I6: collation deciding what the IBAN key means en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I6 (2 points)
solvable with	set of Recognises a collation changing what a key means

dm-ddl-review-deploy I7: event timestamp without a zone, value date as a timestamp edu:Question

https://knobit.org/id/register/data-modelling#I-827

dcterms:identifier	I-827
rdfs:label	dm-ddl-review-deploy I7: event timestamp without a zone, value date as a timestamp en
schema:isPartOf	Data modelling (DAMA-DMBOK2)
schema:isPartOf	I7 (2 points)
solvable with	set of Recognises a time zone dropped from a timestamp

DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design schema:CreativeWork

https://knobit.org/id/register/data-modelling#REF-1

dcterms:identifier	REF-1
dcterms:publisher	DAMA International
dcterms:title	DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (revised), chapter 5: Data Modeling and Design en
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

Used by

assesses learning outcome	Data modelling knowledge: Terms, rules and the conceptual model (CDMP-style questions)
assesses learning outcome	Data modelling knowledge: DMBOK2 chapter 5: schemes, levels, activities and governance (CDMP-style questions)
schema:hasPart	C1 (3 points)
schema:hasPart	C2 (3 points)
schema:hasPart	C3 (2 points)
schema:hasPart	I1 (2 points)
schema:hasPart	I2 (2 points)
schema:hasPart	I3 (1 points)
schema:hasPart	I4 (2 points)
schema:hasPart	I5 (2 points)
schema:hasPart	Q1 (0.5 points)
schema:hasPart	Q2 (1 points)
schema:hasPart	Q4 (0.5 points)
schema:hasPart	C1 (3 points)
schema:hasPart	C2 (3 points)
schema:hasPart	C3 (2 points)
schema:hasPart	I1 (2 points)
schema:hasPart	I2 (2 points)
schema:hasPart	I3 (2 points)
schema:hasPart	I4 (2 points)
schema:hasPart	I5 (2 points)
schema:hasPart	Q1 (2 points)
schema:hasPart	C1 (2 points)
schema:hasPart	C2 (2 points)
schema:hasPart	C3 (2 points)
schema:hasPart	I1 (2 points)
schema:hasPart	I2 (2 points)
schema:hasPart	I3 (2 points)
schema:hasPart	I4 (2 points)
schema:hasPart	I5 (2 points)
schema:hasPart	I6 (2 points)
schema:hasPart	I7 (2 points)
schema:hasPart	C1 (2 points)
schema:hasPart	C2 (2 points)
schema:hasPart	C3 (2 points)
schema:hasPart	C4 (2 points)
schema:hasPart	C5 (2 points)
schema:hasPart	C6 (2 points)
schema:hasPart	C7 (2 points)
schema:hasPart	Q1 (1 points)
schema:hasPart	Q10 (1 points)
schema:hasPart	Q11 (1 points)
schema:hasPart	Q12 (1 points)
schema:hasPart	Q13 (1 points)
schema:hasPart	Q2 (1 points)
schema:hasPart	Q3 (1 points)
schema:hasPart	Q4 (1 points)
schema:hasPart	Q5 (1 points)
schema:hasPart	Q6 (1 points)
schema:hasPart	Q7 (1 points)
schema:hasPart	Q8 (1 points)
schema:hasPart	Q9 (1 points)
schema:hasPart	Q1 (1 points)
schema:hasPart	Q10 (1 points)
schema:hasPart	Q11 (1 points)
schema:hasPart	Q12 (1 points)
schema:hasPart	Q13 (1 points)
schema:hasPart	Q14 (1 points)
schema:hasPart	Q15 (1 points)
schema:hasPart	Q16 (1 points)
schema:hasPart	Q17 (1 points)
schema:hasPart	Q18 (1 points)
schema:hasPart	Q19 (1 points)
schema:hasPart	Q2 (1 points)
schema:hasPart	Q20 (1 points)
schema:hasPart	Q21 (1 points)
schema:hasPart	Q3 (1 points)
schema:hasPart	Q4 (1 points)
schema:hasPart	Q5 (1 points)
schema:hasPart	Q6 (1 points)
schema:hasPart	Q7 (1 points)
schema:hasPart	Q8 (1 points)
schema:hasPart	Q9 (1 points)
schema:hasPart	Q1 (1 points)
schema:hasPart	Q10 (1 points)
schema:hasPart	Q11 (1 points)
schema:hasPart	Q12 (1 points)
schema:hasPart	Q13 (1 points)
schema:hasPart	Q14 (1 points)
schema:hasPart	Q15 (1 points)
schema:hasPart	Q16 (1 points)
schema:hasPart	Q17 (1 points)
schema:hasPart	Q18 (1 points)
schema:hasPart	Q19 (1 points)
schema:hasPart	Q2 (1 points)
schema:hasPart	Q20 (1 points)
schema:hasPart	Q3 (1 points)
schema:hasPart	Q4 (1 points)
schema:hasPart	Q5 (1 points)
schema:hasPart	Q6 (1 points)
schema:hasPart	Q7 (1 points)
schema:hasPart	Q8 (1 points)
schema:hasPart	Q9 (1 points)
schema:hasPart	Q1 (1 points)
schema:hasPart	Q10 (1 points)
schema:hasPart	Q11 (1 points)
schema:hasPart	Q12 (1 points)
schema:hasPart	Q13 (1 points)
schema:hasPart	Q14 (1 points)
schema:hasPart	Q15 (1 points)
schema:hasPart	Q16 (1 points)
schema:hasPart	Q17 (1 points)
schema:hasPart	Q18 (1 points)
schema:hasPart	Q19 (1 points)
schema:hasPart	Q2 (1 points)
schema:hasPart	Q20 (1 points)
schema:hasPart	Q21 (1 points)
schema:hasPart	Q3 (1 points)
schema:hasPart	Q4 (1 points)
schema:hasPart	Q5 (1 points)
schema:hasPart	Q6 (1 points)
schema:hasPart	Q7 (1 points)
schema:hasPart	Q8 (1 points)
schema:hasPart	Q9 (1 points)
schema:hasPart	Q1 (1 points)
schema:hasPart	Q10 (1 points)
schema:hasPart	Q11 (1 points)
schema:hasPart	Q12 (1 points)
schema:hasPart	Q2 (1 points)
schema:hasPart	Q3 (1 points)
schema:hasPart	Q4 (1 points)
schema:hasPart	Q5 (1 points)
schema:hasPart	Q6 (1 points)
schema:hasPart	Q7 (1 points)
schema:hasPart	Q8 (1 points)
schema:hasPart	Q9 (1 points)
schema:hasPart	C1 (2 points)
schema:hasPart	C2 (2 points)
schema:hasPart	C3 (2 points)
schema:hasPart	C4 (2 points)
schema:hasPart	C5 (2 points)
schema:hasPart	C6 (1 points)
schema:hasPart	C7 (1 points)
schema:hasPart	I1 (2 points)
schema:hasPart	I10 (2 points)
schema:hasPart	I2 (1 points)
schema:hasPart	I3 (1 points)
schema:hasPart	I4 (2 points)
schema:hasPart	I5 (1 points)
schema:hasPart	I6 (1 points)
schema:hasPart	I7 (1 points)
schema:hasPart	I8 (2 points)
schema:hasPart	I9 (1 points)
schema:hasPart	C1 (2 points)
schema:hasPart	C2 (2 points)
schema:hasPart	C3 (2 points)
schema:hasPart	C4 (2 points)
schema:hasPart	C5 (2 points)
schema:hasPart	C6 (2 points)
schema:hasPart	I1 (2 points)
schema:hasPart	I2 (2 points)
schema:hasPart	I3 (2 points)
schema:hasPart	I4 (2 points)
schema:hasPart	C1 (2 points)
schema:hasPart	C2 (2 points)
schema:hasPart	C3 (2 points)
schema:hasPart	C4 (2 points)
schema:hasPart	C5 (2 points)
schema:hasPart	C6 (2 points)
schema:hasPart	C7 (2 points)
schema:hasPart	I1 (2 points)
schema:hasPart	I2 (2 points)
schema:hasPart	I3 (2 points)
schema:hasPart	I4 (2 points)
schema:hasPart	C1 (2 points)
schema:hasPart	C2 (2 points)
schema:hasPart	C3 (2 points)
schema:hasPart	C4 (2 points)
schema:hasPart	I1 (1 points)
schema:hasPart	I10 (1 points)
schema:hasPart	I11 (1 points)
schema:hasPart	I12 (1 points)
schema:hasPart	I13 (1 points)
schema:hasPart	I2 (1 points)
schema:hasPart	I3 (1 points)
schema:hasPart	I4 (1 points)
schema:hasPart	I5 (1 points)
schema:hasPart	I6 (1 points)
schema:hasPart	I7 (1 points)
schema:hasPart	I8 (1 points)
schema:hasPart	I9 (2 points)
schema:hasPart	C1 (2 points)
schema:hasPart	C2 (2 points)
schema:hasPart	C3 (2 points)
schema:hasPart	C4 (2 points)
schema:hasPart	C5 (2 points)
schema:hasPart	C6 (2 points)
schema:hasPart	I1 (3 points)
schema:hasPart	I2 (2 points)
schema:hasPart	I3 (3 points)
schema:hasPart	I4 (2 points)
schema:hasPart	C1 (2 points)
schema:hasPart	C2 (2 points)
schema:hasPart	C3 (1.5 points)
schema:hasPart	C4 (1.5 points)
schema:hasPart	C5 (1.5 points)
schema:hasPart	C6 (2 points)
schema:hasPart	C7 (2 points)
schema:hasPart	C8 (2 points)
schema:hasPart	C9 (2 points)
schema:hasPart	C1 (2 points)
schema:hasPart	C2 (2 points)
schema:hasPart	C3 (2 points)
schema:hasPart	C4 (2 points)
schema:hasPart	C5 (2 points)
schema:hasPart	C6 (2 points)
schema:hasPart	I1 (2 points)
schema:hasPart	I2 (2 points)
schema:hasPart	I3 (1 points)
schema:hasPart	I4 (2 points)
schema:hasPart	I5 (1 points)
schema:hasPart	C1 (1.5 points)
schema:hasPart	C10 (1.5 points)
schema:hasPart	C11 (1 points)
schema:hasPart	C12 (1 points)
schema:hasPart	C13 (2 points)
schema:hasPart	C14 (1.5 points)
schema:hasPart	C15 (1.5 points)
schema:hasPart	C2 (1 points)
schema:hasPart	C3 (1.5 points)
schema:hasPart	C4 (1.5 points)
schema:hasPart	C5 (1 points)
schema:hasPart	C6 (1.5 points)
schema:hasPart	C7 (1.5 points)
schema:hasPart	C8 (1.5 points)
schema:hasPart	C9 (1 points)
schema:hasPart	C1 (4 points)
schema:hasPart	C2 (2 points)
schema:hasPart	C3 (2 points)
schema:hasPart	C4 (1 points)
schema:hasPart	I1 (2 points)
schema:hasPart	I2 (2 points)
schema:hasPart	I3 (2 points)
schema:hasPart	I4 (2 points)
schema:hasPart	I5 (1 points)
schema:hasPart	Q1 (0.5 points)
schema:hasPart	Q3 (0.5 points)
schema:hasPart	C1 (2 points)
schema:hasPart	C2 (4 points)
schema:hasPart	C3 (3 points)
schema:hasPart	I2 (3 points)
schema:hasPart	Q1 (1 points)
schema:hasPart	C1 (3 points)
schema:hasPart	C2 (3 points)
schema:hasPart	C3 (2 points)
schema:hasPart	I1 (2 points)
schema:hasPart	I2 (2 points)
schema:hasPart	I3 (2 points)
schema:hasPart	I4 (2 points)
schema:hasPart	I5 (2 points)
schema:hasPart	Q1 (2 points)
schema:hasPart	C1 (4 points)
schema:hasPart	C2 (2 points)
schema:hasPart	C3 (4 points)
schema:hasPart	C4 (2 points)
schema:hasPart	C5 (2 points)
schema:hasPart	C6 (2 points)
schema:hasPart	C7 (2 points)
schema:isPartOf	Recognises a modelling scope with no boundary
schema:isPartOf	Recognises a modelling standard named but not chosen
schema:isPartOf	Recognises a model layer planned with no notation
schema:isPartOf	Recognises model inputs the plan does not locate
schema:isPartOf	Recognises a model review planned by its modeller
schema:isPartOf	Recognises a model with no repository or baseline
schema:isPartOf	Plans the deliverables of a modelling assignment
schema:isPartOf	Chooses a modelling scheme and notation for an audience and purpose
schema:isPartOf	Sets the modelling standards a project follows
schema:isPartOf	Selects the tools and repository for a modelling project
schema:isPartOf	Recognises an incomplete data model scorecard
schema:isPartOf	Recognises a scorecard score with no evidence
schema:isPartOf	Recognises a model reviewed by its modeller
schema:isPartOf	Recognises a review decision contradicting its total
schema:isPartOf	Recognises a review finding with no owner or action
schema:isPartOf	Recognises a scorecard score contradicting the validator
schema:isPartOf	Recognises a review of a version other than the one released
schema:isPartOf	Recognises a data requirement making several claims
schema:isPartOf	Recognises a data requirement prescribing a design solution
schema:isPartOf	Recognises a statement outside the scope of data requirements
schema:isPartOf	Scores a data model against the Data Model Scorecard
schema:isPartOf	Recognises an ambiguous business term in a data requirement
schema:isPartOf	Recognises untestable wording in a data requirement
schema:isPartOf	Recognises an unverifiable data requirement
schema:isPartOf	Recognises a reference with several possible referents
schema:isPartOf	Recognises a data requirement without a named subject
schema:isPartOf	Recognises a measure stated without unit or basis
schema:isPartOf	Recognises a data requirement silent on current versus past values
schema:isPartOf	Recognises an inferred structure presented as declared
schema:isPartOf	Recognises reverse-engineered objects not marked as-is
schema:isPartOf	Recognises a dead database object carried into the model
schema:isPartOf	Recognises a guessed meaning written as a definition
schema:isPartOf	Recognises a reverse-engineering source with no environment or date
schema:isPartOf	Recognises a physical workaround lifted into the logical model
schema:isPartOf	Recognises an absolute statement with its exception unasked
schema:isPartOf	Recognises a mandatory attribute without its moment of obligation
schema:isPartOf	Recognises a business rule left inside another statement
schema:isPartOf	Reverse-engineers a logical model from a database schema
schema:isPartOf	Recognises content filed under the wrong requirement
schema:isPartOf	Recognises an unsourced data requirement
schema:isPartOf	Recognises a missing or meaningless requirement priority
schema:isPartOf	Recognises a missing or wrong requirement type
schema:isPartOf	Recognises a status contradicting the requirement's content
schema:isPartOf	Recognises a guess recorded as fact
schema:isPartOf	Recognises a missing rationale for a non-obvious requirement
schema:isPartOf	Recognises a model change with no reason
schema:isPartOf	Recognises a model change with no impact analysis
schema:isPartOf	Recognises a breaking model change released as a minor version
schema:isPartOf	Recognises a change to a deployed structure with no migration
schema:isPartOf	Recognises a released model version with no baseline
schema:isPartOf	Recognises a model change released without approval
schema:isPartOf	Recognises duplicate data requirements
schema:isPartOf	Recognises paraphrased data requirements
schema:isPartOf	Recognises conflicting data requirements
schema:isPartOf	Releases a model change as a new model version
schema:isPartOf	Recognises inconsistent terminology across the register
schema:isPartOf	Recognises a requirements register with unbounded scope
schema:isPartOf	Recognises a requirements register describing no events
schema:isPartOf	Recognises an uncovered identity requirement
schema:isPartOf	Recognises an uncovered volume or retention requirement
schema:isPartOf	Recognises an uncovered sensitivity or access requirement
schema:isPartOf	Recognises an uncovered lineage requirement
schema:isPartOf	Recognises undecided history requirements across the register
schema:isPartOf	Recognises a requirements register serving no stated question
schema:isPartOf	Recognises a missing or wrong requirement trace
schema:isPartOf	Recognises unstable requirement identifiers
schema:isPartOf	Retires a superseded register entry instead of deleting it
schema:isPartOf	Explains singular and unambiguous requirement statements
schema:isPartOf	Distinguishes a business requirement from a design solution
schema:isPartOf	Explains the data requirement types of the register
schema:isPartOf	Explains requirement attributes and traceability
schema:isPartOf	Explains current value, history and point-in-time reproducibility
schema:isPartOf	Explains the identity of a business thing
schema:isPartOf	Explains the non-functional data concerns
schema:isPartOf	Explains the scope, events and questions a data register must state
schema:isPartOf	Explains referential and logical ambiguity in natural-language statements
schema:isPartOf	Explains persistent identifiers
schema:isPartOf	Explains verifiable requirement statements
schema:isPartOf	Explains consistency within a requirements register
schema:isPartOf	Explains intensional definition by superordinate concept and delimiting characteristics
schema:isPartOf	Explains generic and partitive concept relations
schema:isPartOf	Recognises a constraint claimed by a rule and missing from the schema
schema:isPartOf	Recognises a declared constraint the target platform does not enforce
schema:isPartOf	Explains SBVR fact types and rule statements
schema:isPartOf	Explains Witt's classification of business rules
schema:isPartOf	Explains rule enforcement mechanisms and platform enforcement
schema:isPartOf	Recognises an ambiguous node label
schema:isPartOf	Recognises a node with an unclear boundary and no scope note
schema:isPartOf	Recognises overlapping sibling nodes without reciprocal scope notes
schema:isPartOf	Recognises a meaning change without a history note
schema:isPartOf	Recognises a node without warrant
schema:isPartOf	Recognises inconsistent node label forms
schema:isPartOf	Recognises an abbreviation, jargon or system name as a node label
schema:isPartOf	Recognises a compound node combining two characteristics
schema:isPartOf	Recognises siblings divided by mixed characteristics
schema:isPartOf	Recognises a synonym kept as a separate node
schema:isPartOf	Recognises a link failing the all-and-some test
schema:isPartOf	Recognises an instance placed as a concept node
schema:isPartOf	Recognises a part-of link in a kind-of hierarchy
schema:isPartOf	Recognises an unjustified polyhierarchy
schema:isPartOf	Recognises an associative relationship shown as a hierarchy
schema:isPartOf	Recognises non-reciprocal hierarchy links
schema:isPartOf	Recognises uneven levels of specificity among siblings
schema:isPartOf	Recognises a home-grown copy of an existing vocabulary
schema:isPartOf	Deleted or reused node (taxonomy)
schema:isPartOf	Recognises a structural error in a taxonomy hierarchy
schema:isPartOf	Models a role as an association to the party playing it
schema:isPartOf	Derives the broader concept from the head of a definition
schema:isPartOf	Recognises a taxonomy node deleted while data still refers to it
schema:isPartOf	Recognises a node code reused for a different concept
schema:isPartOf	Explains hierarchical relations and the all-and-some test
schema:isPartOf	Explains scope notes and history notes
schema:isPartOf	Explains warrant for vocabulary terms
schema:isPartOf	Explains label form conventions for vocabularies
schema:isPartOf	Explains characteristics of division and node labels
schema:isPartOf	Explains equivalence relations and preferred terms
schema:isPartOf	Explains associative relations
schema:isPartOf	Explains reuse of external vocabularies
schema:isPartOf	Recognises an insertion anomaly in a logical data model
schema:isPartOf	Recognises an update anomaly in a logical data model
schema:isPartOf	Recognises a deletion anomaly in a logical data model
schema:isPartOf	Recognises a repeating group in an entity
schema:isPartOf	Recognises an attribute holding several facts
schema:isPartOf	Recognises an attribute with several meanings
schema:isPartOf	Recognises attributes held as name-value rows
schema:isPartOf	Recognises a partial dependency on a composite key
schema:isPartOf	Recognises a transitive dependency between non-key attributes
schema:isPartOf	Recognises a stored derivable attribute
schema:isPartOf	Recognises a non-superkey determinant in a 3NF entity
schema:isPartOf	Recognises independent multi-valued facts in one entity
schema:isPartOf	Recognises a join dependency kept in one entity
schema:isPartOf	Recognises a lossy decomposition
schema:isPartOf	Recognises a functional dependency lost in a decomposition
schema:isPartOf	Recognises attributes inapplicable to some instances
schema:isPartOf	Recognises an unstable or meaningful primary key
schema:isPartOf	Recognises an entity identified only by a system-assigned key
schema:isPartOf	Recognises undeclared subtype constraints
schema:isPartOf	Recognises independently changing histories in one entity
schema:isPartOf	Recognises an unresolved many-to-many relationship
schema:isPartOf	Recognises a polymorphic association
schema:isPartOf	Recognises a connection trap
schema:isPartOf	Recognises a fan trap
schema:isPartOf	Recognises a chasm trap
schema:isPartOf	Recognises a redundant relationship
schema:isPartOf	Recognises overlapping entities
schema:isPartOf	Recognises one entity split by value into several
schema:isPartOf	Recognises a relationship contradicting its data rule
schema:isPartOf	Recognises a constraint implied by neither keys nor domains
schema:isPartOf	Traces a logical-model anomaly to its structural cause
schema:isPartOf	Records the functional dependencies of an entity
schema:isPartOf	Decomposes an entity along a functional dependency without loss
schema:isPartOf	Resolves a many-to-many relationship into an associative entity
schema:isPartOf	Replaces a repeating group with a dependent entity
schema:isPartOf	Introduces subtypes for attributes applying to only some instances
schema:isPartOf	Explains functional dependency
schema:isPartOf	Explains candidate key and prime attribute
schema:isPartOf	Explains the insertion, update and deletion anomalies
schema:isPartOf	Explains first normal form
schema:isPartOf	Explains second normal form
schema:isPartOf	Explains third normal form
schema:isPartOf	Explains Boyce-Codd normal form
schema:isPartOf	Explains multivalued dependency and fourth normal form
schema:isPartOf	Explains join dependency and fifth normal form
schema:isPartOf	Explains sixth normal form for temporal data
schema:isPartOf	Explains domain-key normal form
schema:isPartOf	Explains attribute domains
schema:isPartOf	Explains lossless-join decomposition
schema:isPartOf	Explains dependency preservation
schema:isPartOf	Explains derived data and point-in-time snapshots
schema:isPartOf	Explains supertype and subtype constraints
schema:isPartOf	Explains relationship cardinality and optionality
schema:isPartOf	Explains natural keys, surrogate keys and key stability
schema:isPartOf	Explains the connection, fan and chasm traps
schema:isPartOf	Explains an entity type as the realisation of one business concept
schema:isPartOf	Expresses a logical model as a UML class diagram
schema:isPartOf	Models data as fact types in a fact-based scheme
schema:isPartOf	Maps an application model onto a canonical model
schema:isPartOf	Recognises an unmanaged duplicate column
schema:isPartOf	Recognises logical entities merged into one table
schema:isPartOf	Recognises a stored derived or summary value
schema:isPartOf	Recognises a lossy or unconstrained vertical split
schema:isPartOf	Recognises an entity split into clone tables by value
schema:isPartOf	Recognises rolled-up subtypes losing conditional constraints
schema:isPartOf	Recognises rolled-down subtypes losing supertype constraints
schema:isPartOf	Recognises a hierarchy encoded redundantly
schema:isPartOf	Recognises content held outside the database by reference
schema:isPartOf	Recognises a surrogate key without natural-key uniqueness
schema:isPartOf	Recognises a surrogate value with meaning, reused or renumbered
schema:isPartOf	Recognises an undeclared foreign key
schema:isPartOf	Recognises a referential action destroying what should survive
schema:isPartOf	Logical constraint lost on the way down (physical model)
schema:isPartOf	Constraint the platform does not enforce (physical model)
schema:isPartOf	Recognises a changeable value list fixed in the DDL
schema:isPartOf	Recognises a physical domain differing from the logical domain
schema:isPartOf	Recognises binary floating point used for an exact quantity
schema:isPartOf	Sentinel value in place of null, or null with a business meaning (physical model)
schema:isPartOf	Recognises a business fact held in physical row order
schema:isPartOf	Recognises an index set not derived from access paths
schema:isPartOf	Recognises an overwrite where history is required
schema:isPartOf	Recognises inconsistent validity periods in a versioned table
schema:isPartOf	Recognises a reference to a versioned table by business key alone
schema:isPartOf	Recognises a soft delete the constraints do not understand
schema:isPartOf	Recognises a fact table of mixed grain
schema:isPartOf	Recognises a measure without stated additivity
schema:isPartOf	Recognises a nullable foreign key on a reporting join path
schema:isPartOf	Recognises a sentinel value standing in for null
schema:isPartOf	Recognises a null with a business meaning
schema:isPartOf	Routes a defect to the deliverable responsible for it
schema:isPartOf	Explains controlled denormalisation
schema:isPartOf	Explains the implementation options for subtypes
schema:isPartOf	Explains referential integrity and referential actions
schema:isPartOf	Explains exact and approximate numeric types
schema:isPartOf	Explains null semantics and three-valued logic
schema:isPartOf	Explains value sets held as reference data
schema:isPartOf	Explains index design from access paths
schema:isPartOf	Explains history strategies and validity-period conventions
schema:isPartOf	Explains grain and additivity in dimensional models
schema:isPartOf	Explains vertical and horizontal partitioning of tables
schema:isPartOf	Explains consistency of content stored by reference
schema:isPartOf	Explains the absence of row order in relational tables
schema:isPartOf	Designs a star schema for a stated grain
schema:isPartOf	Designs a Data Vault model for auditable history
schema:isPartOf	Designs a document structure for a stated access pattern
schema:isPartOf	Designs views hiding physical structure from consumers
schema:isPartOf	Recognises history kept without its constraints checked
schema:isPartOf	Recognises generated SQL edited by hand
schema:isPartOf	Recognises DDL older than its model
schema:isPartOf	Recognises an object in the SQL missing from the model
schema:isPartOf	Recognises generator warnings carried without a decision
schema:isPartOf	Rule marked `constraint` with no constraint in the SQL (generated DDL)
schema:isPartOf	Recognises a configured dialect left unregenerated
schema:isPartOf	`-- NOT ENFORCED` read as a guarantee (generated DDL)
schema:isPartOf	Recognises a CHECK constraint parsed and ignored
schema:isPartOf	Recognises an expression running on one engine only
schema:isPartOf	Recognises a truncated identifier taken as the real name
schema:isPartOf	Recognises a reserved word used as an identifier
schema:isPartOf	Recognises a type meaning something else on another engine
schema:isPartOf	Recognises an index the target engine cannot create or run
schema:isPartOf	Recognises a foreign-key cycle taken as resolved
schema:isPartOf	Money in binary floating point (generated DDL)
schema:isPartOf	Recognises one decimal scale for every currency
schema:isPartOf	Recognises a length taken from sample data

48 more in the RDF.