Data Modeling & ERD Reading

Tại sao PM cần biết ERD

Nhiều PM hỏi feature đơn giản nhưng schema underlying lại bắt engineering rewrite migration tốn 2 tuần. Đọc được ERD = ra quyết định "feasibility-aware" trước khi commit timeline.

Core concepts

• Entity — table (vd: users, orders).
• Attribute — column.
• Primary key (PK) — định danh duy nhất một row.
• Foreign key (FK) — link sang entity khác.
• Cardinality — 1:1, 1:N, N:M.
• Normalization — 1NF/2NF/3NF, tránh redundancy.

Ví dụ — E-commerce simplified

users (id PK, email, name, created_at)
orders (id PK, user_id FK, total, status, created_at)
order_items (id PK, order_id FK, product_id FK, qty, price)
products (id PK, name, price, stock)

Cardinality: 1 user — N orders. 1 order — N order_items. 1 product — N order_items.

Notation

• Crow's foot — chân chim cho "many", thẳng cho "one".
• UML — số 0..1, 1, *, 1..*.

PM scenario thực tế

Feature "user có thể có nhiều địa chỉ giao hàng". Trước khi viết PRD, vẽ ERD nháp:

users (id, ...) — 1:N — addresses (id, user_id FK, label, street, ...)
orders (id, user_id, shipping_address_id FK)

Decision: cho phép xóa address khi đã có order trỏ tới? Soft-delete vs hard-delete? Đây là conversation chuẩn giữa PM và engineer.

Common pitfalls

• Bỏ qua junction table cho N:M (vd: users ↔ roles).
• Nhồi nhiều info vào 1 column (anti-pattern "kitchen sink").
• Không nghĩ tới audit table (history of changes).