1. Database Design là gì?
Database Design là quá trình thiết kế cách tổ chức, lưu trữ và liên kết dữ liệu trong một hệ thống sao cho dữ liệu có cấu trúc hợp lý, hạn chế trùng lặp không cần thiết, bảo đảm tính toàn vẹn và hỗ trợ các truy vấn mà application cần thực hiện.
Khi xây dựng backend, developer thường bắt đầu từ những chức năng như đăng ký tài khoản, tạo sản phẩm, đặt hàng hoặc thanh toán. Nhưng mỗi chức năng đều phụ thuộc vào cách database được thiết kế.
Ví dụ, với chức năng tạo order, cần trả lời những câu hỏi:
- Một order thuộc về user nào?
- Một order có thể chứa nhiều sản phẩm không?
- Thông tin sản phẩm và giá bán cần được lưu ở đâu?
- Nếu sản phẩm bị ngừng kinh doanh, order cũ có còn xem được không?
- Nếu hai request cùng mua sản phẩm cuối cùng trong kho, làm thế nào tránh bán vượt số lượng tồn?
Database design thường bao gồm ba góc nhìn có liên quan:
Conceptual design xác định những thực thể nghiệp vụ và mối quan hệ giữa chúng. Ví dụ, hệ thống có User, Product, Order và Payment.
Logical design chuyển những thực thể và mối quan hệ thành các bảng, column, key và constraint. Ở giai đoạn này, developer quyết định orders cần user_id, còn quan hệ giữa orders và products được biểu diễn như thế nào.
Physical design quan tâm đến cách triển khai trên database cụ thể: kiểu dữ liệu, index, cách tối ưu query, phân vùng, lưu trữ và những yếu tố vận hành khác.
Khi học, nên bắt đầu từ nghiệp vụ và logical design trước. Nếu chưa biết dữ liệu cần biểu diễn thế nào, việc chọn index hay tối ưu query cũng chưa có nền tảng vững chắc.
2. Entity, Attribute và Relationship
Entity là một thực thể mà hệ thống cần lưu trữ thông tin. Trong ứng dụng bán hàng, User, Product, Order và Payment là những entity thường gặp.
Attribute là các thuộc tính mô tả entity. Chẳng hạn, Product có tên, giá bán, trạng thái và thời điểm tạo; User có email, tên hiển thị và trạng thái tài khoản.
Relationship mô tả cách những entity liên hệ với nhau. Một user có thể tạo nhiều order, một order có thể chứa nhiều product, còn một payment có thể gắn với một order theo mô hình thanh toán đã chọn.
Khi chuyển những khái niệm này thành database, mỗi entity thường được biểu diễn bằng một bảng. Tuy nhiên, không phải mọi đối tượng trong bài toán đều cần một bảng riêng. Một thông tin chỉ được tạo ra để phục vụ tính toán tạm thời có thể không cần lưu trữ. Ngược lại, một khái niệm nghiệp vụ có vòng đời hoặc quan hệ riêng, chẳng hạn Order Item hay Payment Attempt, thường nên được mô hình hóa rõ ràng.
3. Relationship Cardinality – Một quan hệ có bao nhiêu bản ghi?
Một trong những quyết định quan trọng nhất trong database design là xác định cardinality, tức số lượng bản ghi ở hai phía có thể liên quan với nhau như thế nào.
One-to-One (1:1)
One-to-one là quan hệ trong đó một bản ghi ở bảng A liên kết với tối đa một bản ghi ở bảng B, và ngược lại.
Ví dụ, mỗi user có tối đa một profile chứa thông tin mở rộng:
users
- id
- email
profiles
- id
- user_id
- date_of_birth
- bioMỗi profile thuộc về một user. Nếu business rule yêu cầu mỗi user chỉ có tối đa một profile, profiles.user_id cần unique constraint.
Ví dụ SQL:
CREATE TABLE profiles (
id BIGINT GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
user_id BIGINT NOT NULL UNIQUE,
bio TEXT,
FOREIGN KEY (user_id) REFERENCES users(id)
);Cú pháp sinh ID ở đây theo PostgreSQL; MySQL có thể dùng AUTO_INCREMENT. Phần quan hệ thông qua foreign key và unique constraint thể hiện cùng một ý tưởng thiết kế.
Chỉ có foreign key là chưa đủ để tạo quan hệ 1:1. Nếu user_id không unique, một user có thể có nhiều profile, và quan hệ thực tế đã trở thành one-to-many.
One-to-Many (1)
One-to-many là quan hệ một bản ghi ở bảng cha có thể liên kết với nhiều bản ghi ở bảng con.
Ví dụ, một user có thể tạo nhiều order, nhưng mỗi order chỉ thuộc về một user trong mô hình thông thường:
User 1 ───── N OrdersThiết kế:
users
- id
- email
orders
- id
- user_id
- status
- total_amountTrong quan hệ one-to-many, foreign key thường nằm ở bảng phía many, tức orders.user_id.
CREATE TABLE orders (
id BIGINT GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
user_id BIGINT NOT NULL,
status VARCHAR(20) NOT NULL,
total_amount DECIMAL(12, 2) NOT NULL,
FOREIGN KEY (user_id) REFERENCES users(id)
);Cách này cho phép mỗi order trỏ đến một user cụ thể. Nếu user_id là NOT NULL, mỗi order bắt buộc phải có user liên kết. Nếu cho phép NULL, database có thể lưu order chưa gắn với user, miễn là nghiệp vụ cho phép điều đó.
Many-to-Many (N)
Many-to-many là quan hệ mà nhiều bản ghi ở bảng A có thể liên kết với nhiều bản ghi ở bảng B.
Ví dụ, một order có nhiều product và một product có thể xuất hiện trong nhiều order.
Không nên đặt product_id đơn lẻ trong orders, vì một order có nhiều sản phẩm. Cũng không nên thêm các cột như product_1, product_2, product_3, vì số lượng sản phẩm không cố định và cấu trúc sẽ khó mở rộng.
Cách phổ biến là dùng bảng trung gian:
orders
- id
products
- id
- name
order_items
- order_id
- product_id
- quantity
- unit_priceorder_items biểu diễn quan hệ giữa order và product. Mỗi row cho biết một sản phẩm được đưa vào một order với số lượng và giá cụ thể.
4. Self-Referencing Relationship – Một bảng tham chiếu chính nó
Một số mô hình có quan hệ giữa các bản ghi thuộc cùng một loại entity. Ví dụ:
- Danh mục cha và danh mục con.
- Nhân viên và người quản lý.
- Bình luận và bình luận trả lời.
- Cấu trúc cây gồm các node.
Có thể sử dụng self-referencing foreign key, trong đó một column của bảng tham chiếu đến primary key của chính bảng đó.
Ví dụ với danh mục:
CREATE TABLE categories (
id BIGINT GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
name VARCHAR(100) NOT NULL,
parent_id BIGINT NULL,
FOREIGN KEY (parent_id)
REFERENCES categories(id)
);Một category có thể là danh mục gốc với parent_id = NULL, hoặc thuộc một category cha khác.
5. Tổng kết
Database Design & Relationships là nền tảng để xây dựng một database có cấu trúc hợp lý, dữ liệu nhất quán và có thể phát triển cùng application.
Cần hiểu rõ entity, attribute, cardinality và optionality trước khi quyết định cách tổ chức bảng. Primary key xác định bản ghi; foreign key thiết lập quan hệ và bảo vệ referential integrity; unique constraint và các constraint khác thực thi những quy tắc quan trọng của dữ liệu.
Bài viết khác
Database Normalization – 1NF, 2NF, 3NF & Denormalization
1. Database Normalization là gì? Database Normalization (chuẩn hóa dữ liệu) là quá trình tổ chức dữ liệu thành các bảng và quan hệ hợp lý nhằm giảm dư thừa không cần thiết, tránh dữ liệu mâu thuẫn và duy trì tính toàn vẹn của database. Khi thiết kế database, nếu lưu tất cả thông […]
PostgreSQL / MySQL
1. PostgreSQL và MySQL là gì? PostgreSQL và MySQL là hai hệ quản trị cơ sở dữ liệu quan hệ (Relational Database Management System – RDBMS), được sử dụng để lưu trữ, truy vấn và quản lý dữ liệu cho các ứng dụng. Tuy cùng thuộc nhóm relational database, PostgreSQL và MySQL có sự khác […]
Sanity Testing(Kiểm thử sự hợp lý)
Sanity Testing là gì? Trong quá trình phát triển và vận hành một dự án phần mềm, hoạt động lập trình không bao giờ dừng lại ở lần phát hành đầu tiên. Sau khi nhận được phản hồi từ đội ngũ QC hoặc người dùng thực tế, các lập trình viên sẽ liên tục tiến […]
Laravel Routing & Controllers
Laravel Routing và Controllers là gì? 1. Laravel Routing là gì? Laravel Routing (định tuyến trong Laravel) là cơ chế xác định cách ứng dụng tiếp nhận và xử lý HTTP request dựa trên những thông tin như HTTP method và URL. Một route có thể chuyển request đến Controller, thực thi Closure (hàm ẩn […]
Functional Testing (Kiểm thử chức năng)
1.Functional Testing (Kiểm thử chức năng) là gì? Trong bức tranh toàn cảnh của ngành phát triển phần mềm, mục tiêu cuối cùng của mọi ứng dụng công nghệ là giải quyết các bài toán nghiệp vụ cho con người. Dù một hệ thống có kiến trúc mã nguồn siêu việt, giao diện bắt mắt […]
PHP & Laravel Fundamentals
PHP là gì? — Ngôn ngữ lập trình phía máy chủ và vai trò trong phát triển web PHP là gì? PHP (viết tắt của PHP: Hypertext Preprocessor) là một ngôn ngữ lập trình phía máy chủ, thường được sử dụng để xây dựng website và ứng dụng web động. Trong mô hình phát […]
Khoá học lập trình game con rắn cho trẻ em 
