Discover structure
Extract entities, attributes, PK/FK, and 1:1 or 1:N relationships from meeting notes.
erd-schema.mdDay 3 · Data Normalization, ERD & Integrity
From business
language to trusted
data structures.
Today, we converted business concepts from meetings into entities and relationships, standardized inconsistent terminology, and traced both schema-change impacts and data-integrity risks.
What did we do today?
We used Codex as a data modeler, terminology steward, change-impact analyst, and design auditor.
Extract business concepts → ERD → Standardize terms → Trace change → Record decisions → Defend against exceptions
We derived core entities such as User, Expert, Reservation, and Payment, along with PKs, FKs, and cardinalities, from meeting notes. We unified inconsistent project terminology into a standard glossary and reverse-traced how a reservation-approval policy change affects the database, APIs, and screens. Finally, we recorded the rationale and alternatives behind design choices and discovered concurrency and referential-integrity failure scenarios.
Data-Design Flow at a Glance
Each output is not an isolated document. Together, they strengthen the data model step by step.
Standardize terms
Unify inconsistent labels such as Member, User, and Customer into one standard.
project-glossary.mdAnalyze change impact
Trace how database-state and process changes affect API responses and screen UI.
change-impact-report.mdRecord design decisions
Preserve the background, alternatives, rejection rationale, and approvers behind normalization choices.
design-decision-log.mdDesign exception scenarios
Address concurrency conflicts, duplicate reservations, and referential-integrity collapse.
edge-case-analysis.mdSix Key Concepts
These are the data-design concepts directly addressed by the course goals and Codex labs.
Define managed business objects as entities and their characteristics as attributes.
A PK uniquely identifies a row; an FK creates relationships and referential integrity across tables.
1:1, 1:N, and N:M translate real business rules into data relationships.
Separate data logically to reduce duplication and update anomalies while balancing query and operating costs.
Link planning terms, API names, and database columns to one standard concept to reduce translation errors.
Data rules must survive failures such as duplicate reservations, references to deleted users, and concurrent payments.
Day 3 Lab Map
Focus on which input file became which verifiable output.
Task 1
Resolve gaps in data-structure understanding
Data Modeler
INPUT
day3_meeting_notes.mdOUTPUT
erd-schema.md + Mermaid ERDTask 2
Standardize project terminology
Terminology Steward
INPUT
fragmented-terms.mdOUTPUT
project-glossary.mdTask 3
Share schema-change impact
Impact Analyst
INPUT
schema-change-request.mdOUTPUT
change-impact-report.mdMission 1
Record design decisions
Architecture Decision Recorder
INPUT
tech-design-meeting.mdOUTPUT
design-decision-log.mdMission 2
Discover data exception scenarios
Integrity & Edge-Case Auditor
INPUT
database-schema.mdOUTPUT
edge-case-analysis.mdHow Far Does Change Propagate?
A reservation-confirmation process change does not end with one column update.
① Business Rule
Move from immediate confirmation and payment to payment after expert approval.
② Database
Split reservation status into states such as Awaiting Approval and define transition rules.
③ API
Synchronize request/response fields, status codes, and approval or rejection actions.
④ UI & Test
Update buttons, status displays, guidance text, and normal or exception test cases.
Original Prompts Used
These are the five original English prompts used in the Day 3 Codex labs.
Task 1 · Data structure & Mermaid ERD
Please analyze the provided meeting minutes from a data structure perspective to derive key entities and relationships, and write a data structure definition and Mermaid ERD code.
Task 2 · Standard project glossary
Please analyze terms such as 'Member/User/Customer/Member' and 'Counselor/Expert/Teacher/Counselor' that are used interchangeably throughout the project and create a dictionary of standard project terms in the form of a Markdown table.
Task 3 · Schema change impact
Please fill out the API specifications, DB schema, screens, and change sharing reports that are affected as the reservation confirmation process has been changed to 'Awaiting Approval' status and 'Payment after expert approval'.
Mission 1 · Design Decision Log
Please extract normalization and database structure design decisions from the meeting and create a Design Decision Log that includes decision items, background reasons, alternatives reviewed, approvers, and possible future changes.
Mission 2 · Edge-case analysis
Please derive edge case exception scenarios for data consistency violations that may occur in the currently defined User, Expert, Reservation, and Payment table structures and suggest improvement measures.