🔥 Truncate vs Delete trong SQL
🚀 Truncate:
- ❌ Không hỗ trợ
WHERE - ⚡ Xoá toàn bộ bảng, cực nhanh
- 🔒 Không rollback nếu không nằm trong transaction
- 🔁 Reset AUTO_INCREMENT
- 💤 Không gọi trigger, không log chi tiết
🛠️ Delete:
- ✅ Có
WHERE, xoá có điều kiện - 🐌 Chậm hơn vì log đầy đủ
- ♻️ Rollback được trong transaction
- 🔢 Không reset AUTO_INCREMENT
- 📣 Gọi trigger và cập nhật chỉ mục
💡 Mẹo nhớ:
👉 Dọn sạch bảng → dùng TRUNCATE
👉 Xoá có điều kiện → dùng DELETE
🔑 Primary Key vs 🔗 Foreign Key
🔑 Primary Key:
- 🧍 Định danh duy nhất bản ghi
- 🚫 Không được NULL
- 1 bảng chỉ có 1 PK
- 📌 Dùng để JOIN nhanh, ổn định
🔗 Foreign Key:
- 🔁 Tham chiếu tới PK của bảng khác
- ✅ Có thể NULL (tuỳ logic)
- ✅ Có thể có nhiều FK trong 1 bảng
- 🔄 Giữ mối quan hệ giữa bảng
📘 Ví dụ:
students(id)→ 🔑grades(student_id)→ 🔗 tham chiếustudents.id
🔗 Các loại JOIN – Mối quan hệ êm đẹp giữa các bảng
- Các loại JOIN – Mối quan hệ êm đẹp giữa các bảng🤝 INNER JOIN: Chỉ lấy bản ghi khớp ở cả hai bảng👈 LEFT JOIN: Giữ tất cả dòng bên trái, bên phải có thể NULL👉 RIGHT JOIN: Giữ tất cả dòng bên phải, bên trái có thể NULL🌐 FULL OUTER JOIN: Lấy tất cả bản ghi, khớp thì nối, không khớp thì NULL
📌 WHERE vs HAVING – Đừng nhầm nhé!
🔍 WHERE: Lọc từng dòng trước khi GROUP BY
🎯 HAVING: Lọc theo nhóm dữ liệu đã tổng hợp
🧪 Ví dụ:
```– WHERE: lọc trước
SELECT * FROM orders WHERE price > 100;
– HAVING: lọc nhóm
SELECT customer_id, COUNT()
FROM orders
GROUP BY customer_id
HAVING COUNT() > 5;```
⚙️ 🔍 Index – Tăng tốc truy vấn như tên lửa
✅ Ưu điểm:
- 🚀 SELECT nhanh hơn rõ rệt
- 📊 Hỗ trợ tốt
WHERE,JOIN,ORDER BY
⚠️ Nhược điểm:
- 🐌 Chậm INSERT, UPDATE, DELETE
- 📦 Tốn không gian lưu trữ
🧠 Kinh nghiệm:
- Chỉ index cột thường truy vấn hoặc join
- Tránh index cột ít giá trị phân biệt (low cardinality)
🔄 🔐 Transaction – Giao dịch không bao giờ sai nếu hiểu ACID
🔷 ACID là gì?
- ⚛️ Atomicity:
Tất cả hoặc không có gì.
Một giao dịch phải được thực hiện trọn vẹn hoặc không thực hiện gì cả – nếu lỗi, phải rollback toàn bộ. - 🧮 Consistency:
Dữ liệu luôn hợp lệ.
Trước và sau giao dịch, dữ liệu luôn tuân theo các ràng buộc đã định nghĩa trong schema. - 🚪 Isolation:
Không ảnh hưởng các giao dịch khác.
Các transaction chạy song song sẽ không can thiệp vào nhau. - 💾 Durability:
Không mất dữ liệu sau khi commit.
Dữ liệu đã commit sẽ được lưu vĩnh viễn, kể cả khi hệ thống gặp sự cố.
🧱 DDL là gì? (Data Definition Language)
- Là các lệnh thay đổi cấu trúc cơ sở dữ liệu:
Ví dụ:CREATE,ALTER,DROP,TRUNCATE, v.v. - Thường auto-commit:
Không nằm trong giao dịch, không thể rollback → nếu lỗi xảy ra sau đó, DDL vẫn được thực hiện. - Trộn DDL vào giao dịch dễ phá vỡ tính Atomicity của ACID.
📊 DML là gì? (Data Manipulation Language)
- Là các lệnh thao tác dữ liệu:
Ví dụ:INSERT,UPDATE,DELETE,SELECT. - Hỗ trợ transaction đầy đủ:
Có thể rollback nếu có lỗi xảy ra.
🧨 Ví dụ lỗi khi trộn DDL + DML trong MySQL
START TRANSACTION; CREATE TABLE orders (id INT); -- ⚠️ Auto-commit ngay tại đây INSERT INTO orders VALUES (1); -- Giao dịch mới bắt đầu lại ROLLBACK;
Giải thích:
Lệnh CREATE TABLE đã được commit ngay khi chạy.
Nếu INSERT sau đó bị lỗi và bị rollback, thì bảng orders vẫn tồn tại → phá vỡ tính nguyên tử của giao dịch.
🧪 Thành phần | Giải thích dễ nhớ |
📥 📦 Tạo bảng không cần CREATE TABLE
👉 Cách 1: CREATE TABLE AS
CREATE TABLE active_users AS SELECT * FROM users WHERE status = 'active';
👉 Cách 2: VIEW
CREATE VIEW active_users AS SELECT * FROM users WHERE status = 'active';
** Làm thế nào để thay đổi kiểu dữ liệu của cột trong PostgreSQL ? **
Dùng lệnh ALTER TABLE ... ALTER COLUMN ... SET DATA TYPE.
🔹 Ví dụ:
Giả sử bảng sinh_vien có cột tuoi kiểu VARCHAR, cần đổi sang INTEGER:
ALTER TABLE sinh_vien ALTER COLUMN tuoi SET DATA TYPE INTEGER;
13. Làm thế nào để tạo cơ sở dữ liệu trong PostgreSQL ?
Dùng lệnh CREATE DATABASE.
🔹 Ví dụ:
CREATE DATABASE quan_ly_sinh_vien;
** Có những kiểu bảng phân vùng nào trong PostgreSQL?**
PostgreSQL hỗ trợ 2 kiểu chính:
1️⃣ Phân vùng theo dải (Range Partitioning):
→ Dữ liệu chia theo khoảng giá trị.
🔹 Ví dụ:
sql
CREATE TABLE don_hang (
id SERIAL,
ngay DATE,
so_luong INT
) PARTITION BY RANGE (ngay);2️⃣ Phân vùng theo danh sách (List Partitioning):
→ Dữ liệu chia theo danh sách giá trị cụ thể.
🔹 Ví dụ:
CREATE TABLE khach_hang (
id SERIAL,
ten VARCHAR(100),
quoc_gia VARCHAR(50)
) PARTITION BY LIST (quoc_gia);** Sequence trong PostgreSQL là gì?**
🔄 Sequence là đối tượng tạo số tự động – thường dùng để sinh PRIMARY KEY.
🔹 Ví dụ:
```sql
CREATE SEQUENCE san_pham_seq START 1;
CREATE TABLE san_pham (
id INT DEFAULT nextval(‘san_pham_seq’),
ten VARCHAR(100)
);```
** WAL (Write-Ahead Logging) là gì?**
🧠 WAL là cơ chế ghi log trước khi ghi vào DB.
→ Dùng để phục hồi dữ liệu khi xảy ra sự cố.
🔹 Ví dụ:
Khi bạn INSERT dữ liệu vào khach_hang, PostgreSQL ghi vào WAL trước, rồi mới ghi xuống đĩa.
Các cấp độ Isolation trong Transaction (PostgreSQL)
1️⃣ Read Uncommitted – Mức thấp nhất
📌 Lý thuyết:
Transaction có thể đọc dữ liệu chưa được commit từ transaction khác → gây ra Dirty Read.
Không đảm bảo độ tin cậy. Hầu hết hệ quản trị không hỗ trợ mức này.
🧪 Ví dụ: Dirty Read
-- Transaction 1: Cập nhật dữ liệu nhưng chưa commit BEGIN; UPDATE khach_hang SET so_du = 10000 WHERE id = 1; -- Chưa COMMIT hoặc ROLLBACK -- Transaction 2: Đang ở mức READ UNCOMMITTED SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED; BEGIN; SELECT so_du FROM khach_hang WHERE id = 1; -- Kết quả: 10000, dù T1 chưa commit COMMIT; -- Transaction 1 rollback ROLLBACK;
🔍 Giải thích:
T2 đọc dữ liệu T1 chưa commit. Sau đó T1 rollback → dữ liệu T2 vừa đọc bị mất → sai lệch
2️⃣ Read Committed – Mặc định của PostgreSQL
📌 Lý thuyết:
Chỉ cho phép đọc dữ liệu đã commit.
Tránh được Dirty Read, nhưng vẫn gặp Non-repeatable Read và Phantom Read.
🧪 Ví dụ: Non-repeatable Read
-- Transaction 1: Bắt đầu transaction BEGIN; SELECT so_du FROM khach_hang WHERE id = 1; -- Kết quả: 5000 -- Transaction 2: Update rồi commit BEGIN; UPDATE khach_hang SET so_du = 8000 WHERE id = 1; COMMIT; -- Transaction 1: Đọc lại SELECT so_du FROM khach_hang WHERE id = 1; -- Kết quả: 8000 COMMIT;
🔍 Giải thích:
T1 đọc cùng 1 bản ghi 2 lần → kết quả khác nhau → Non-repeatable Read
3️⃣ Repeatable Read – Ổn định giá trị đã đọc
📌 Lý thuyết:
Cùng 1 bản ghi đã đọc sẽ luôn trả về cùng 1 giá trị trong suốt transaction.
Tránh được Dirty Read và Non-repeatable Read, nhưng không tránh được Phantom Read.
🧪 Ví dụ A: Tránh Non-repeatable Read
-- Transaction 1: Cô lập lặp lại (Repeatable Read) BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ; SELECT so_du FROM khach_hang WHERE id = 1; -- Kết quả: 5000 -- Transaction 2: Update rồi commit BEGIN; UPDATE khach_hang SET so_du = 7000 WHERE id = 1; COMMIT; -- Transaction 1: Đọc lại SELECT so_du FROM khach_hang WHERE id = 1; -- Kết quả: vẫn là 5000 (giá trị snapshot lúc bắt đầu transaction) COMMIT;
🔍 Giải thích:
T2 cập nhật nhưng T1 vẫn thấy dữ liệu cũ → ✅ ổn định đọc → tránh được Non-repeatable Read
🧪 Ví dụ B: Phantom Read
-- Transaction 1: Bắt đầu
BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ;
SELECT * FROM khach_hang WHERE so_du > 4000;
-- Kết quả: 2 dòng
-- Transaction 2: Thêm bản ghi phù hợp điều kiện
BEGIN;
INSERT INTO khach_hang (ten, so_du) VALUES ('Phong', 6000);
COMMIT;
-- Transaction 1: Đọc lại
SELECT * FROM khach_hang WHERE so_du > 4000;
-- Kết quả: 3 dòng → có thêm khách hàng 'Phong'
COMMIT;🔍 Giải thích:
T2 thêm dòng mới thỏa điều kiện truy vấn → T1 truy vấn lại thấy dòng “ma” → Phantom Read
4️⃣ Serializable – Chặt chẽ nhất
📌 Lý thuyết:
Mô phỏng như các transaction chạy tuần tự, đảm bảo tránh hoàn toàn:
- Dirty Read
- Non-repeatable Read
- Phantom Read
⛔ Đổi lại, cần nhiều khóa hơn, dễ bị chặn → hiệu suất chậm.
🧪 Ví dụ: Ngăn Phantom Read
-- Transaction 1
BEGIN ISOLATION LEVEL SERIALIZABLE;
SELECT * FROM khach_hang WHERE so_du > 5000;
-- Transaction 2
BEGIN;
INSERT INTO khach_hang (ten, so_du) VALUES ('Phong', 6000);
-- Gây lỗi hoặc bị chặn do xung đột phạm vi
COMMIT;
-- Transaction 1
SELECT * FROM khach_hang WHERE so_du > 5000;
-- Trả về: Không có dòng mới
COMMIT;🔍 Giải thích:
T2 bị chặn hoặc thất bại vì T1 đã “khóa phạm vi truy vấn” → ✅ không xảy ra Phantom Read
🎯 Ghi nhớ nhanh 4 mức Isolation
- Read Uncommitted:
Chấp nhận mọi rủi ro → dễ sai → thường không dùng - Read Committed (Default):
An toàn vừa đủ cho CRUD phổ thông - Repeatable Read:
Ổn định kết quả đã đọc, nhưng bị Phantom Read - Serializable:
An toàn tuyệt đối, giả lập chạy tuần tự, nhưng chậm hơn
🔄 Phi chuẩn hóa dữ liệu (Data Denormalization) là gì?
Phi chuẩn hóa là quá trình gộp dữ liệu từ nhiều bảng chuẩn hóa thành một bảng duy nhất, hoặc thêm các trường dữ liệu cần thiết vào bảng đã chuẩn hóa để:
- Giảm số lần JOIN khi truy vấn
- Tăng tốc độ đọc dữ liệu
Hiểu đơn giản, ta chấp nhận lưu trữ dư thừa một phần để đổi lấy hiệu suất truy vấn nhanh hơn.
Phù hợp cho hệ thống thiên về đọc dữ liệu nhiều (read-heavy) như:
- Data Warehouse
- OLAP (phân tích dữ liệu)
- Dashboard thời gian thực
✅ Ưu điểm của phi chuẩn hóa
- Truy vấn nhanh hơn do ít hoặc không cần JOIN
- Dễ viết truy vấn, dữ liệu cần thiết có thể nằm gọn trong một bảng
- Thích hợp cho báo cáo tài chính, phân tích, hoặc dashboard phản hồi nhanh
❌ Nhược điểm
- Dữ liệu trùng lặp, dễ gây không nhất quán nếu cập nhật sai
- Tốn nhiều dung lượng lưu trữ hơn
- Khó bảo trì và cập nhật hơn nếu dữ liệu được ghi hoặc sửa đổi thường xuyên
🧪 Ví dụ minh họa
Thay vì chia dữ liệu thành 3 bảng riêng biệt: khach_hang, san_pham, don_hang, ta có một bảng phi chuẩn hóa như sau:
| id | ten_khach | dia_chi | san_pham | so_luong | |----|-----------|---------|-------------|----------| | 1 | Nam | Hà Nội | Laptop | 1 | | 2 | Huy | HCM | Điện thoại | 2 | | 3 | Nam | Hà Nội | Bàn phím | 1 |
Dễ thấy khách hàng “Nam” bị lặp lại → nhưng đổi lại, khi cần thống kê theo khách hàng, địa chỉ và sản phẩm, không cần JOIN thêm bảng nào.
📌 Khi nào nên dùng phi chuẩn hóa?
- Khi hệ thống cần truy vấn rất nhanh, ưu tiên tốc độ đọc hơn tính gọn gàng dữ liệu
- Khi hệ thống có lượng đọc lớn, nhưng ghi/cập nhật ít
- Khi JOIN phức tạp gây chậm hệ thống, và truy vấn hay bị “nghẽn” do nhiều bảng
Một số ví dụ cụ thể:
- Kho dữ liệu (Data Warehouse)
- Hệ thống phân tích OLAP
- Dashboard tài chính thời gian thực
🔍 So sánh Chuẩn hóa và Phi chuẩn hóa
Chuẩn hóa (Normalization):
- Mục tiêu: loại bỏ trùng lặp, đảm bảo tính nhất quán dữ liệu
- Truy vấn cần JOIN → tốc độ đọc chậm hơn
- Tối ưu khi ghi/cập nhật nhiều
- Phù hợp với hệ thống OLTP (Online Transaction Processing), ví dụ như CRM, ngân hàng, thương mại điện tử
Phi chuẩn hóa (Denormalization):
- Mục tiêu: tăng hiệu suất truy vấn, giảm JOIN
- Chấp nhận một mức dữ liệu dư thừa có kiểm soát
- Phù hợp khi đọc nhiều – ghi ít, ví dụ hệ thống phân tích, báo cáo, Data Lake
💡 Kinh nghiệm thực tế
- Giai đoạn đầu hệ thống nên thiết kế chuẩn hóa để dữ liệu sạch, dễ kiểm soát, tránh lỗi logic
- Khi hệ thống lớn lên và phát sinh vấn đề truy vấn chậm do JOIN nhiều, có thể phi chuẩn hóa chọn lọc
- Phi chuẩn hóa không nên lạm dụng – chỉ áp dụng với những trường/truy vấn “nóng” thường xuyên
- Nếu phi chuẩn hóa, cần có cơ chế đồng bộ dữ liệu rõ ràng để tránh mâu thuẫn
Khoá trong SQL ?
🔑 1. Primary Key – Khóa chính
- Là cột (hoặc nhiều cột) dùng để xác định duy nhất mỗi dòng.
- Không được trùng ❌, không được null 🚫.
- Ví dụ:
State_Codetrong bảngUS_Stateslà Primary Key (e.g. TX, GA).
🎯 2. Candidate Key – Khóa ứng viên
- Là những cột có thể dùng làm Primary Key.
- Một bảng có thể có nhiều Candidate Key.
- Ví dụ: Cả
State_CodevàState_Nameđều là Candidate Key trongUS_States.
🧩 3. Superkey – Khóa siêu cấp
- Là bất kỳ tập cột nào giúp xác định duy nhất hàng 🧠.
- Có thể chứa thêm cột không cần thiết.
- Ví dụ:
{State_Code, Region}vẫn xác định duy nhất → là Superkey (nhưng không tối giản nên không phải Candidate Key).
🔄 4. Alternate Key – Khóa thay thế
- Là Candidate Key không được chọn làm Primary Key.
- Dùng như backup hoặc bảo vệ dữ liệu.
- Ví dụ: Nếu
State_Codelà Primary Key thìState_Namelà Alternate Key.
🌉 5. Foreign Key – Khóa ngoại
- Là cột tham chiếu đến Primary Key của bảng khác.
- Tạo liên kết giữa các bảng & đảm bảo dữ liệu hợp lệ.
- Ví dụ:
State_Codetrong bảngVoterslà Foreign Key → tham chiếu tớiUS_States.
🌍 6. Natural Key – Khóa tự nhiên
- Có ý nghĩa thực tế ngoài đời 🌐.
- Dễ hiểu, dễ nhớ.
- Ví dụ:
State_Code(TX, GA),Customer_Email,ISBN.
🔐 7. Surrogate Key – Khóa thay thế hệ thống
- Không có ý nghĩa thực tế ❎.
- Được hệ thống tạo tự động (ID tăng dần, UUID…).
- Ví dụ:
State_ID,Book_IDtrong bảng có thể là surrogate key.
🎯 Khi nào dùng?
- Natural Key: Dữ liệu thực tế ổn định → dùng được luôn.
- Surrogate Key: Khi không có key tự nhiên ổn định, hoặc cần đơn giản hóa quan hệ.
🧱 8. Simple Key – Khóa đơn
- Là khóa (thường Primary/Candidate) chỉ gồm 1 cột duy nhất.
- Ví dụ:
Customer_Emaildùng để xác định duy nhất → là Simple Key.
🧱🧱 9. Composite Key – Khóa phức hợp
- Là khóa gồm nhiều cột kết hợp lại để xác định duy nhất hàng.
- Ví dụ:
{Coffee_Type, Cup_Size}trong bảngCoffee_Options.
🧱🌉 10. Compound Key – Khóa ghép có khóa ngoại
- Là Composite Key mà ít nhất 1 cột là Foreign Key.
- Xuất hiện trong bảng trung gian (many-to-many).
- Ví dụ:
{Student_ID, Course_ID}trong bảngStudent_Course.{Customer_ID, Account_ID}trongCustomer_Account.
🧠 11. Intelligent Key – Khóa thông minh
- Là Natural Key có cấu trúc gồm nhiều phần có ý nghĩa.
- Người dùng có thể “đọc key là hiểu”.
- Ví dụ:
- Mã sản phẩm:
CLS-JIG-001→ Classic Jigsaw #001. - Mã khách hàng:
19900325-001→ sinh ngày 25/03/1990, người thứ 1.
- Mã sản phẩm:
📝 Ghi nhớ nhanh:
- Primary Key → Duy nhất, không null 🛡️
- Candidate Key → Ứng viên sáng giá cho PK 🏆
- Superkey → Rộng hơn Candidate Key 🧃
- Alternate Key → Không được chọn nhưng vẫn xịn 😎
- Foreign Key → Cầu nối giữa bảng 🌉
- Natural Key → Ý nghĩa thực tế 🌍
- Surrogate Key → Do hệ thống sinh ra 🎲
- Simple Key → 1 cột là đủ 🔹
- Composite Key → Nhiều cột kết hợp 🔷
- Compound Key → Composite có Foreign Key 🧷
- Intelligent Key → Mã có logic dễ hiểu 🧠
Common Table Expressions (CTE)
```WITH TopCustomers AS (
SELECT customer_id, SUM(total_amount) AS total_spent
FROM orders
GROUP BY customer_id
)
SELECT customer_id, total_spent
FROM TopCustomers
WHERE total_spent > 1000000;
~~~
📘 Giải thích
WITH TopCustomers AS (...): định nghĩa một bảng tạm logic trong phiên truy vấn.- Truy vấn cuối cùng lọc khách hàng có tổng chi tiêu vượt 1 triệu.
- Ưu điểm:
- Tách biệt logic từng bước → dễ đọc, dễ bảo trì.
- Hỗ trợ đệ quy (với
RECURSIVE). - Hiệu năng tốt hơn subquery trong nhiều tầng lồng.
Subquery (Truy vấn lồng nhau)
```SELECT customer_id, total_spent
FROM (
SELECT customer_id, SUM(total_amount) AS total_spent
FROM orders
GROUP BY customer_id
) AS Sub
WHERE total_spent > 1000000;
~~~
📘 Giải thích
- Phần
SELECT ... FROM (...)là một truy vấn con được dùng làm bảng tạm. - Ngắn gọn, dễ viết với truy vấn đơn.
- Nhược điểm:
- Dễ rối và khó bảo trì nếu có nhiều lớp subquery.
- Có thể hiệu năng thấp với dữ liệu lớn.
View (Bảng ảo)
```CREATE VIEW CustomerOrders AS
SELECT c.name, o.order_date, o.total_amount
FROM customers c
JOIN orders o ON c.id = o.customer_id;
Sau đó:
SELECT * FROM CustomerOrders WHERE total_amount > 1000000;
~~~
📘 Giải thích
- View là bảng ảo chứa sẵn logic truy vấn, giúp tái sử dụng nhiều nơi.
- Không lưu dữ liệu → mỗi truy vấn đều tính lại từ đầu.
- Ưu điểm:
- Quản lý logic nghiệp vụ tập trung.
- Dễ chia sẻ giữa các báo cáo.
- Nhược điểm: Dễ lỗi nếu schema gốc thay đổi.
Temporary Table (Bảng tạm)
```CREATE TEMPORARY TABLE TempSales AS
SELECT product_id, SUM(quantity) AS total_sold
FROM order_details
GROUP BY product_id;
Sau đó:
SELECT * FROM TempSales WHERE total_sold > 100;
~~~
📘 Giải thích
- Bảng tạm chỉ tồn tại trong phiên làm việc hiện tại.
- Phù hợp xử lý dữ liệu trung gian hoặc ETL.
- Ưu điểm:
- Tăng hiệu năng khi cần lưu kết quả trung gian.
- Nhược điểm:
- Tự động xóa khi phiên kết thúc.
- Khó debug nếu chưa kết thúc phiên.
Materialized View (View vật lý hóa)
```CREATE MATERIALIZED VIEW MonthlySales AS
SELECT DATE_TRUNC(‘month’, order_date) AS month,
SUM(total_amount) AS monthly_total
FROM orders
GROUP BY month;
Cập nhật:
REFRESH MATERIALIZED VIEW CONCURRENTLY MonthlySales;
~~~
📘 Giải thích
- Khác với View, Materialized View lưu kết quả ra đĩa.
- Truy vấn rất nhanh vì không tính lại mỗi lần.
- Ưu điểm:
- Tối ưu với hệ thống báo cáo, dashboard.
- Nhược điểm:
- Cần refresh thủ công hoặc theo lịch.
- Tốn dung lượng lưu trữ.
Window Function là gì ?
✅ Khái niệm
Window Function là hàm cho phép tính toán tổng hợp theo từng nhóm (partition)
⚠️ Nhưng không làm mất chi tiết từng dòng như GROUP BY.
🧠 Lợi ích chính
- Giữ nguyên từng dòng dữ liệu.
- Cho phép các phép toán như: tổng, trung bình, đếm, xếp hạng, v.v.
- Dễ xử lý các bài toán như cộng dồn, xếp hạng, so sánh giữa các dòng liên tiếp…
🔧 Cấu trúc chung
```<window_function>(...) OVER (
PARTITION BY <column>
ORDER BY <column>
ROWS BETWEEN ... AND ...
)
~~~</column></column></window_function>
🧮 Các Window Function phổ biến trong phân tích dữ liệu
ROW_NUMBER()
→ Đánh số thứ tự dòng trong từng nhóm
→ Không quan tâm giá trị trùng, luôn tăng đều (1, 2, 3,…)RANK()
→ Xếp hạng theo thứ tự, cho phép trùng hạng, nhưng nhảy số
→ Ví dụ: hạng 1, 2, 2, 4 (bỏ hạng 3)DENSE_RANK()
→ Xếp hạng không nhảy số khi trùng hạng
→ Ví dụ: hạng 1, 2, 2, 3 (không bỏ hạng)LAG(column, offset)
→ Truy xuất giá trị ở dòng trước
→ Dùng để tính biến động, so sánh với dòng trước đó (default offset = 1)LEAD(column, offset)
→ Truy xuất giá trị ở dòng sau
→ Dùng để dự báo, so sánh xu hướng, hoặc đối chiếu với dòng tiếp theo
Mô hình dữ liệu (Data Modeling)
📘 Mô Hình Dữ Liệu Khái Niệm (Conceptual Data Model)
- 💡 Là mô hình trừu tượng và tổng quan về dữ liệu trong hệ thống.
- 🎯 Tập trung vào các thực thể chính và mối quan hệ cơ bản.
- ❌ Không đi sâu vào chi tiết kỹ thuật.
- 💬 Trong Entity Framework: là một phần của EDM – mô tả các đối tượng và quan hệ cần tương tác.
- 📦 Gồm:
- Các loại thực thể (entity types).
- Các mối quan hệ (associations).
- Mỗi thực thể có tên, khóa định danh và thuộc tính.
- 🛍️ Ví dụ:
- “Khách hàng” (Customers)
- “Sản phẩm” (Products)
- “Đơn hàng” (Orders)
- Mối quan hệ: “Khách hàng có nhiều đơn hàng”, “Đơn hàng có nhiều sản phẩm”
- 🔄 Là cầu nối giữa yêu cầu nghiệp vụ và thiết kế kỹ thuật.
🧮 Mô Hình Dữ Liệu Logic và Vật Lý
Mô Hình Logic (Logical Data Model)
- 🧱 Phát triển từ mô hình khái niệm.
- 🔍 Bổ sung chi tiết kỹ thuật: kiểu dữ liệu, ràng buộc, quy tắc nghiệp vụ.
- 🧑💻 Vẫn giữ độc lập với nền tảng CSDL cụ thể.
- 🔄 Tổ chức dữ liệu logic, tối ưu chuẩn hóa và truy vấn.
Mô Hình Vật Lý (Physical Data Model)
- 🔧 Chi tiết nhất để triển khai cơ sở dữ liệu trên hệ QTCSDL cụ thể.
- 📋 Gồm: bảng, cột, chỉ mục, khóa ngoại, trigger, partition…
- 📊 Quyết định hiệu suất vận hành: lưu trữ, phân vùng, tối ưu truy vấn.
- 🔄 Duy trì tính nhất quán từ thiết kế ban đầu đến triển khai thực tế.
🗺️ Mô Hình ERD và Ứng Dụng Trong Thiết Kế Cơ Sở Dữ Liệu
- 🧾 ERD (Entity-Relationship Diagram) là sơ đồ trực quan hóa mô hình ER.
- 👓 Trực quan hóa thực thể, thuộc tính và mối quan hệ giữa chúng.
- 🔄 Mối quan hệ giữa ER và ERD:
- ER: mô hình hóa dữ liệu.
- ERD: công cụ biểu diễn và truyền đạt mô hình ER.
🧱 Thành Phần ERD:
- 🧍♂️ Thực thể (Entities): các đối tượng trong hệ thống cần lưu thông tin.
- 🧾 Thuộc tính (Attributes): đặc điểm của thực thể.
- 🔗 Mối quan hệ (Relationships): liên kết và tương tác giữa các thực thể (1-1, 1-N, N-N).
⚙️ Ứng Dụng:
- 🔍 Phân tích yêu cầu nghiệp vụ.
- 🧑💻 Thiết kế cơ sở dữ liệu.
- 📡 Giao tiếp giữa BA – Dev – DB Designer.
- 🛠️ Hướng dẫn tạo bảng và kết nối trong DBMS.
RDBMS là gì?
Hệ quản trị cơ sở dữ liệu quan hệ – lưu dữ liệu dưới dạng bảng có liên kết qua khóa.
Data Mart là gì?
Là phần nhỏ của kho dữ liệu (Data Warehouse), tập trung cho 1 phòng ban cụ thể.
