Data Resource Management and Data Modeling
Domain 1 - Data resource management and data modeling
This domain tests whether you can turn a business narrative into a 概念データモデル (conceptual data model) and then govern it with データ標準化 and a リポジトリ. Questions usually give a paragraph of operations and ask for entities, relationships, cardinalities, or the correct standardization rule.
Core rules
- An entity is something of interest with independent identity; an attribute describes it. If a supposed attribute repeats or has attributes of its own, it is probably an entity.
- Model 1:n with a foreign key on the n side; model m:n with an associative entity (関連実体) that can carry its own attributes such as 適用開始日.
- 汎化/特化 (supertype/subtype) captures shared attributes and exclusive roles; state whether subtypes are disjoint or overlapping.
- データ標準化 fixes naming, domain, format, code system and unit. Codes should follow a defined system (e.g., ISO 3166 country codes, JIS prefecture codes) and carry a validity period if values can change.
- The リポジトリ holds metadata: entity and attribute definitions, domains, CRUD matrices, lineage, version history. It is the single authority when names conflict.
Worked example
"Each employee belongs to exactly one department; each department has exactly one manager, who is an employee; employees are assigned to projects for a period."
Employees–departments is 1:n, so 部門コード is a foreign key in 社員. Department manager is 1:1 from department to employee: implement it as 部門.管理者社員番号 referencing 社員, not as an attribute of 社員, or you cannot express a manager who manages one department. Assignments are m:n, so create 配置(社員番号, プロジェクトコード, 開始日, 終了日) keyed by 社員番号 + プロジェクトコード + 開始日, because an employee can return to the same project later.
Traps
Storing repeating groups as 項目1, 項目2 columns; writing 1:1 where the relationship is 1:0..1; dropping history; keeping synonyms (顧客/取引先) without standardizing; and assuming a code value is never reused.