📌 Series: Database for Data Science : Bài 3 . Mô Hình Dữ Liệu Quan Hệ

Chào mừng các “loser” trở lại với vũ trụ “Database for Data Science” phiên bản “tự học không ai ép” từ Learning AI With Losers! 🎉 Lại là loser1 đây hehe..

Hành Trình Khám Phá Thế Giới Quan Hệ Dữ Liệu

Bạn đã bao giờ tự hỏi làm thế nào mà Amazon có thể nhớ mọi chi tiết về hàng triệu đơn hàng? Hay tại sao ngân hàng không bao giờ nhầm lẫn khi chuyển tiền giữa các tài khoản? Câu trả lời nằm ở một phát minh tuyệt vời cách đây hơn 50 năm: Mô hình dữ liệu quan hệ.

Trong hai bài viết trước, chúng ta đã xây dựng nền móng kiến thức về database. Hôm nay, chúng ta lại mò mẫm tiếp cái hành trình khám phá thế giới “dữ liệu quan hệ” 🧐 nghe có vẻ “cao siêu” nhưng thực ra cũng chỉ là mấy cái bảng với nhau thôi ấy mà! Đừng lo nếu bạn vẫn đang thấy “tẩu hỏa nhập ma” 🔥 với mấy thuật ngữ, vì chúng ta ở đây là để cùng nhau “lụt nghề” 🤣 một cách vui vẻ mà!

“Dữ liệu á? Nó như đống quần áo chưa giặt ấy. Mô hình quan hệ chính là cái tủ chia ngăn giúp chúng ta không bị ‘ngợp’ trong mớ hỗn độn đó!”

Nhấp Ngụm “Trà Đá Chanh Sả”: Nhìn Lại Quá Khứ “Hào Hùng” Của Dữ Liệu Quan Hệ

A Look Back: Lịch Sử và Sự Phát Triển của Mô Hình Dữ Liệu Quan Hệ

Năm 1970, một “loser” à nhầm, một nhà khoa học máy tính siêu cấp tên Edgar F. Codd (nghe tên thôi đã thấy “pro” rồi) tại IBM đã “vẽ” ra một cái ý tưởng mà sau này thay đổi cả thế giới dữ liệu. Chắc lúc đó ông ấy cũng không ngờ đứa con tinh thần của mình lại “trâu bò” đến vậy.

Hãy tưởng tượng cái thời mà dữ liệu nó cứ “tùm lum tà la” 😵 như mớ dây sạc điện thoại sau một tuần sử dụng. Muốn tìm một thông tin thôi mà các “coder” phải “vò đầu bứt tai” 🤔 viết code “toàn chưởng” 🤯 để biết nó nằm ở xó nào. Nghe thôi đã thấy “ám ảnh” 👻 rồi!

Ấy thế mà bác Codd lại nghĩ ra cái kiểu lưu trữ dữ liệu vào mấy cái bảng có liên hệ với nhau. Nghe thì có vẻ “dễ ẹc”, nhưng mà nó lại “mạnh mẽ” đến không ngờ. Đó chính là “Big Bang” của mô hình dữ liệu quan hệ đó anh em!

Từ cái ý tưởng trên giấy đó đến khi nó “bước ra ánh sáng” cũng gian nan lắm chứ bộ. Phải đến năm 1979, mấy “gã khổng lồ” Oracle mới “trình làng” cái hệ thống RDBMS thương mại đầu tiên. Lúc đó chắc họ “ăn mừng” 🎉 còn hơn cả chúng ta được “cú đêm” xem World Cup ⚽ ấy chứ!

Đến tận bây giờ, dù có bao nhiêu công nghệ “mới nổi”✨ như NoSQL hay Distributed SQL, thì cái mô hình “cổ điển” này vẫn cứ “ung dung” mà sống khỏe. Tại sao ư? Vì mấy cái nguyên tắc “cốt cán” của nó vẫn “chất”: dữ liệu phải “gọn gàng”✅, “đáng tin” và “hỏi gì cũng trả lời” được. Giống như mấy ông “loser” học lại bài cũ vẫn nhớ kiến thức căn bản ấy! 😉

“Mổ Xẻ” 🔪 Nội Thất Mô Hình Quan Hệ: Mấy Cái Tên Nghe ‘Quen Quen’ 🤔 Mà Cũng ‘Lạ Lạ’

1. Relations (Tables): Cái Bảng “Thần Thánh” ✨

Hãy bắt đầu với khái niệm nền tảng: Relations hay Tables (Bảng).

Tưởng tượng bạn đang quản lý một tiệm bánh nhỏ. Mỗi ngày, bạn có nhiều khách hàng đến mua với các đơn hàng khác nhau. Làm thế nào để theo dõi tất cả thông tin này?

Trong mô hình quan hệ, bạn sẽ tạo các bảng riêng biệt:

• Bảng KHÁCH_HÀNG lưu thông tin về khách
• Bảng SẢN_PHẨM chứa danh sách các loại bánh
• Bảng ĐƠN_HÀNG ghi lại các giao dịch

Cứ hình dung “relation” hay “table” (bảng) nó giống như một cái bảng Excel mà bạn hay dùng ấy. Nhưng mà nó có mấy cái “luật ngầm” mà bạn phải nhớ:

• Tên “oách xà lách”: Mỗi bảng phải có một cái tên “không đụng hàng” với ai khác. Giống như bạn đặt nickname cho mình trên mạng xã hội vậy đó.
• “Độc nhất vô nhị”: Không có hai hàng nào được “copy paste” giống nhau hoàn toàn. Mỗi hàng là một “cá thể” riêng biệt. Giống như mỗi chúng ta đều là một “loser” độc đáo vậy! 😂
• “Một mình một ô”: Mỗi ô trong bảng chỉ được chứa một giá trị duy nhất thôi. Đừng có nhét “tùm lum tà la” vào một ô nhé!
• “Cùng một giuộc”: Tất cả các giá trị trong cùng một cột phải có cùng một “kiểu” dữ liệu. Ví dụ, cột “Tuổi” thì chỉ được chứa số thôi, đừng có “lạc loài” chữ ✍️ vào đó.

Một relation giống như một hộp sắp xếp ngăn nắp – mỗi thứ đều có vị trí riêng, và bạn luôn biết chính xác nơi tìm kiếm thông tin mình cần.

2. Attributes (Columns): Mấy Cái “Nhãn Dán” 📌 Cho Dữ Liệu

“Attributes” hay cột nó giống như mấy cái “nhãn dán” để mô tả đặc điểm của dữ liệu trong bảng.

Ví dụ thực tế: Trong bảng NHÂN_VIÊN của một công ty:

• MaNV: Mã số nhân viên
• HoTen: Tên đầy đủ
• NgaySinh: Ngày tháng năm sinh
• ViTri: Chức vụ
• Luong: Mức lương

Tưởng tượng bạn đang mô tả một người. Bạn không thể nói “Tuổi của anh ấy là một con mèo” – điều đó vô nghĩa phải không? Tương tự, trong mô hình quan hệ, mỗi cột phải tuân theo một domain ( cái này loser1 sẽ giải thích ở dưới nha iu iu , loser1 gay vãi c…c sorry ae ) – tập các giá trị hợp lệ. Cột NgaySinh chỉ có thể chứa ngày tháng, không thể là văn bản hay âm thanh.

Định nghĩa không hình thức: Domain là tập hợp các giá trị mà một thuộc tính có thể nhận. Nó giống như kiểu “luật chơi” cho từng cột vậy. ( Hé lộ xíu cho ae )

3. Tuples (Rows): Nơi “Kể Chuyện” 📖 Của Dữ Liệu

“Tuples” hay hàng chính là nơi mà dữ liệu thực tế được “kể” lại 🗣️. Mỗi hàng đại diện cho một “thực thể” 👤 cụ thể. Kiểu hàng 1 là thông tin của loser1 , hàng 2 là thông tin của loser2 vậy đó có hiểu không ?

Trong bảng HỌC_SINH:

| MaHS | HoTen           | Lop  | DiemTB |
|------|-----------------|------|--------|
| 001  | Nguyễn Văn An   | 10A1 | 8.5    |
| 002  | Trần Thị Bình   | 10A2 | 9.0    |
| 003  | Lê Minh Châu    | 10A1 | 7.5    |

Mỗi hàng đại diện cho một học sinh cụ thể với đầy đủ thông tin. Hàng đầu tiên không phải là “Nguyễn Văn An và bạn bè của cậu ấy” – nó chỉ về một học sinh duy nhất.

Mấy ông “tuples” này cũng có “tính cách” riêng đó:

• “Không thích đụng hàng” 👯: Trong cùng một bảng, không có hai hàng nào được giống nhau “từ đầu đến chân” 👣. Tất nhiên Loser1 không đụng hàng content của Dad Con Thang Nào Cả
• “Sinh ra là thế” 👶: Sau khi đã “ra đời” 🐣, các giá trị trong một tuple thường không thay đổi (trừ khi bạn thực hiện thao tác cập nhật 🔄).-> Sinh ra là loser1 , cả đời là loser1 nên đừng kêu loser1 đổi tên cả nghe mà bùn
• “Nguyên tử” ⚛️: Mỗi giá trị trong một ô của tuple phải là “nguyên tử”, tức là không thể chia nhỏ hơn được nữa ✂️. -> Loser1 không có cắt ra thành Loser1 mini như Dora mini được đâu bro…..

Domains: “Khuôn Khổ” 🖼️ Cho Giá Trị Dữ Liệu

Định nghĩa không hình thức: “Domain” giống như cái “khuôn khổ” 🖼️ để xác định những giá trị nào là “chấp nhận được” 👍 cho một thuộc tính.Ví dụ, cột “Giới tính” thì domain của nó thường là {“Nam”, “Nữ”, “Khác”}. Bạn không thể nhập “Con mèo” vào cột này được.

Định nghĩa hình thức: Cho một lược đồ quan hệ R(A1, A2, …, An), domain của thuộc tính Ai, ký hiệu là dom(Ai), là tập hợp tất cả các giá trị có thể xuất hiện trong cột Ai của bất kỳ thể hiện hợp lệ nào của quan hệ R. Nói một cách “khô khan” thì nó là tập hợp các giá trị mà thuộc tính đó được phép nhận.

Ví dụ sinh động:

• Domain của Giới tính: {Nam, Nữ, Khác}
• Domain của Điểm số: [0..10] (số thực từ 0 đến 10)
• Domain của Nhóm máu: {A, B, AB, O}

Domains giống như những chiếc hộp với nhãn dán rõ ràng. Bạn không thể đặt một chiếc giày vào hộp đựng trứng, đúng không? Cũng vậy, bạn không thể nhập “Mèo” vào cột “Nhóm máu”.

Việc xác định domain giúp chúng ta tránh được những sai sót “ngớ ngẩn” 🤔 khi nhập liệu.

Định Nghĩa “Cao Siêu”, Hình Thức (Formal Definition) cho Relation

Đây là phần “hóc búa” một chút, anh em nào thấy “lú” thì cứ từ từ nhé! Không ae khỏi xem cũng được …. loser1 ghét toán , loser1 hận toán 😂

Một quan hệ r(R) của một lược đồ R(A1, A2, …, An) được định nghĩa một cách hình thức như sau:

• Nó là một tập hợp các bộ r = {t1, t2, …, tm}.
• Mỗi bộ t lại là một danh sách có thứ tự gồm n giá trị t = {v1, v2, …, vn}.

Trong đó:

• Mỗi vi (giá trị thứ i trong bộ), với 1 ≤ i ≤ n, phải thuộc về miền dom(Ai) của thuộc tính Ai, hoặc có thể là null. Giá trị null ở đây có nghĩa là “không xác định” hoặc “không tồn tại”.

Nhận xét “toán học”: r(R) là một tập con của tích Descartes của tất cả các miền: r(R) ⊆ (dom(A1) × dom(A2) × … × dom(An)).

Giá trị thứ i của bộ t có thể được biểu diễn bằng t.Ai (truy cập theo tên thuộc tính) hoặc t[i] (truy cập theo vị trí).

Các khái niệm – Lược đồ của một quan hệ (Lược đồ Quan hệ):

Một lược đồ của một Quan hệ R, được biểu diễn bởi R(A1, A2, …, An), bao gồm:

• R: Tên của lược đồ (ví dụ: FACULTY, STUDENT, COURSE…).
• A1, A2, …, An: Các thuộc tính (các cột) của quan hệ.

Mỗi thuộc tính Ai sẽ nhận các giá trị thuộc về một miền giá trị nhất định, ký hiệu là dom(Ai) (ví dụ: dom(MÃKHOA) có thể là tập hợp các chuỗi ký tự, dom(NĂMTL) có thể là tập hợp các số nguyên).

Bậc của lược đồ chính là số lượng thuộc tính mà nó có.

Ví dụ: Lược đồ KHOA (MÃKHOA, TÊNKHOA, NĂMTL, PHÒNG, ĐIỆNTHOẠI, TRƯỞNGKHOA, NGÀYNHẬNCHỨC).

• Bậc của lược đồ KHOA là 7 (vì có 7 thuộc tính).
• Miền của thuộc tính MÃKHOA có thể là “String” (chuỗi ký tự).
• Miền của thuộc tính NĂMTL có thể là “Integer” (số nguyên).

Các khái niệm – Lược đồ cơ sở dữ liệu quan hệ:

Một lược đồ cơ sở dữ liệu quan hệ sẽ bao gồm một tập hợp các lược đồ quan hệ:

S = {R1, R2, …, Rn}

Ví dụ, một lược đồ cơ sở dữ liệu có thể bao gồm các lược đồ sau:

• GIÁOVIÊN (MÃGV, HỌTÊN, LƯƠNG, PHÁI, NGÀYSINH, SỐNHÀ, ĐƯỜNG, QUẬN, THÀNHPHỐ, GVQLCM, MÃBM)
• GV_ĐT (MÃGV, ĐIỆNTHOẠI)
• BỘMÔN (MÃBM, TÊNBM, PHÒNG, ĐIỆNTHOẠI, TRƯỞNGBM, MÃKHOA, NGÀYNHẬNCHỨC)
• KHOA (MÃKHOA, TÊNKHOA, NĂMTL, PHÒNG, ĐIỆNTHOẠI, TRƯỞNGKHOA, NGÀYNHẬNCHỨC)
• ĐỀTÀI (MÃĐT, TÊNĐT, KINHPHÍ, CẤPQL, NGÀYBĐ, NGÀYKT, MÃCĐ, GVCNĐT)
• CHỦĐỀ (MÃCĐ, TÊNCĐ)
• CÔNGVIỆC (MÃĐT, STT, TÊNCV, NGÀYBĐ, NGÀYKT)
• THAMGIAĐT(MÃGV, MÃĐT, STT, PHỤCẤP, KẾTQUẢ)

Các khái niệm – Ghi chú “Nhỏ Nhưng Có Võ”:

• Lược đồ quan hệ R có n thuộc tính: R(A1, A2, …, An)
• Một thể hiện cụ thể của quan hệ R: r, q, s (giống như các bảng dữ liệu thực tế)
• Một bộ trong quan hệ: t, u, v (một hàng dữ liệu cụ thể)
• Miền của thuộc tính A: Dom(A)
• Giá trị của thuộc tính A trong bộ t: t.A hoặc t[A]

Keys: Đảm Bảo Tính Toàn Vẹn và Mối Quan Hệ Dữ Liệu

“Keys” là một khái niệm “xịn sò” ✨ hơn một chút, nhưng nó lại đóng vai trò cực kỳ quan trọng trong việc đảm bảo tính toàn vẹn và mối quan hệ giữa các bảng.

Primary Keys (Khóa Chính): “Chứng Minh Thư” Của Mỗi Bản Ghi

• Hãy tưởng tượng trong lớp học 🏫 có hai bạn tên giống nhau. Làm sao để thầy cô phân biệt được? Đó là nhờ “số báo danh” 🔖 hay “mã số học sinh” 🆔 đúng không? Trong cơ sở dữ liệu, “primary key” cũng đóng vai trò tương tự. Nó là một hoặc một nhóm thuộc tính mà giá trị của nó xác định duy nhất mỗi hàng trong một bảng.

Hãy xem xét một tình huống thực tế: Trong một lớp học có hai bạn cùng tên “Nguyễn Thị Hương”. Làm thế nào để phân biệt? Đó là lúc primary key xuất hiện!

Primary key giống như số CMND/CCCD – nó đảm bảo mỗi người là duy nhất. Trong bảng SINH_VIÊN, MaSV là primary key:

| MaSV   | HoTen              | NgaySinh  |
|--------|-------------------|------------|
| SV0001 | Nguyễn Thị Hương  | 15/04/2000 |
| SV0002 | Nguyễn Thị Hương  | 22/07/2001 |

Dù hai sinh viên trùng tên, chúng ta vẫn phân biệt được họ nhờ MaSV.

• Định nghĩa không hình thức: Khóa chính là một hoặc một tập hợp các thuộc tính dùng để xác định duy nhất mỗi bản ghi trong một bảng. Nó giống như “căn cước công dân” 🛂 của mỗi hàng vậy. Không được trùng lặp 🚫 và không được để trống (NULL) ❌.
• Định nghĩa hình thức: Cho lược đồ quan hệ R(A1, A2, …, An), một tập hợp con K là tập con của {A1, A2, …, An} được gọi là khóa chính nếu nó thỏa mãn hai điều kiện:
  1. K là một siêu khóa của R (tức là với mọi t1, t2 thuộc r, nếu t1 khác t2 thì t1(K) khác t2(K) với mọi bộ t1, t2 trong bất kỳ thể hiện nào của R).
  2. Không có tập con thực sự nào của K là siêu khóa của R. (Tính tối thiểu)
     Ngoài ra, các thuộc tính tạo nên khóa chính không được phép nhận giá trị NULL.

Foreign Keys: Liên Kết Các Bảng

“Foreign key” là “cầu nối” 🌉 giữa các bảng. Nó là một hoặc một nhóm thuộc tính trong một bảng mà nó tham chiếu đến “primary key” 🔑 của một bảng khác. Nhờ có “foreign key” mà chúng ta có thể thiết lập mối quan hệ 🤝 giữa các bảng.

Ví dụ thực tế từ một trường học:

• Bảng GIÁO_VIÊN có primary key là MaGV
• Bảng LỚP_HỌC có foreign key GiaoVienChuNhiem tham chiếu đến MaGV

GIÁO_VIÊN:
| MaGV | HoTen           | Bộ môn      |
|------|-----------------|-------------|
| GV01 | Trần Minh Châu  | Toán        |
| GV02 | Lê Hoàng Nam    | Lý          |

LỚP_HỌC:
| MaLop | TenLop | GiaoVienChuNhiem |
|-------|--------|------------------|
| L01   | 10A1   | GV01             |
| L02   | 10A2   | GV02             |

Khi nhìn vào lớp 10A1, tôi biết ngay cô Trần Minh Châu là giáo viên chủ nhiệm – đó là sức mạnh của mối quan hệ!

Điều thú vị là foreign key có thể chứa giá trị NULL. Ví dụ, một lớp học mới thành lập có thể chưa có giáo viên chủ nhiệm.

Định nghĩa không hình thức: Khóa ngoại là một hoặc một tập hợp các thuộc tính trong một bảng mà giá trị của nó phải khớp với một giá trị tồn tại trong khóa chính 🔑 của một bảng khác (hoặc có thể là NULL nếu thuộc tính đó cho phép NULL). Nó giống như “địa chỉ nhà” 🏠 để liên kết đến thông tin ở bảng khác.

Định nghĩa hình thức: Cho hai lược đồ quan hệ R1(A1, A2, …, An) với khóa chính PKR1 và R2(B1, B2, …, Bm). Một tập hợp các thuộc tính FK là tập con của {B1, B2, …, Bm} được gọi là khóa ngoại tham chiếu đến R1 nếu:

Các thuộc tính trong FK có cùng miền với các thuộc tính tương ứng trong PKR1.

Với mọi bộ t2 trong thể hiện của R2, giá trị của t2(FK) phải bằng giá trị của t1(PKR1) cho một số bộ t1 trong thể hiện của R1, hoặc t2(FK) là NULL (nếu các thuộc tính trong FK cho phép NULL).

Maintaining Data Integrity: Mấy Cái “Luật Lệ” 👮 Để Dữ Liệu Luôn “Ngon Lành” 👍

Tổng Quan Về Các Ràng Buộc Toàn Vẹn

Để đảm bảo dữ liệu của chúng ta luôn “sạch đẹp” ✨ và “đáng tin” ✅, chúng ta cần phải có những “luật lệ” 📜 gọi là “integrity constraints” (ràng buộc toàn vẹn). Chúng giống như hàng rào bảo vệ, ngăn chặn việc nhập dữ liệu không hợp lệ và duy trì chất lượng của thông tin được lưu trữ.

Domain Constraints: Xác Thực Giá Trị Thuộc Tính

Mấy cái ràng buộc này nó giống như mấy anh “bảo vệ” 🛡️ đứng ở cổng của từng cột dữ liệu, chỉ cho phép những giá trị “hợp lệ” ✅ mới được “vào” 🚶. Chúng ta đã nói ở trên rồi nên không nhắc lại nữa nhé! 😉

Ví dụ thực tế chi tiết:

1. Hệ thống quản lý bệnh viện:
   • Tuổi bệnh nhân: Số nguyên từ 0 đến 120
   • Nhóm máu: Chỉ có thể là ‘A’, ‘B’, ‘AB’, ‘O’ (với Rh+ hoặc Rh-)
   • Nhiệt độ cơ thể: Từ 35.0°C đến 42.0°C
2. Hệ thống thương mại điện tử:
   • Giá sản phẩm: Số dương (không âm) với tối đa 2 chữ số thập phân
   • Số lượng tồn kho: Số nguyên không âm
   • Mã giảm giá: Chuỗi ký tự alphanumeric có độ dài từ 5 đến 10
3. Hệ thống quản lý giáo dục:
   • Điểm số học sinh: Từ 0 đến 10 (hoặc từ 0 đến 100, tùy thuộc vào thang điểm)
   • Năm tốt nghiệp: Năm hợp lệ, không lớn hơn năm hiện tại
   • Mã số sinh viên: Chuỗi ký tự có định dạng cụ thể (ví dụ: “SV” + 8 chữ số)

Ứng dụng trong SQL:

CREATE TABLE Học_Sinh (
    MãHS VARCHAR(10) PRIMARY KEY,
    Tên VARCHAR(50) NOT NULL,
    Tuổi INT CHECK (Tuổi >= 6 AND Tuổi <= 18),
    ĐiểmTrungBình DECIMAL(3,1) CHECK (ĐiểmTrungBình >= 0 AND ĐiểmTrungBình <= 10),
    Email VARCHAR(100) CHECK (Email LIKE '%@%.%'),
    LớpHọc VARCHAR(10) CHECK (LớpHọc IN ('10A', '10B', '11A', '11B', '12A', '12B'))
);

Domain constraints hoạt động như một “bảo vệ cửa” tại mỗi cột dữ liệu, ngăn chặn những giá trị không hợp lệ ngay từ khi chúng cố gắng xâm nhập vào cơ sở dữ liệu. Nhờ vậy, bạn sẽ không bao giờ phải đối mặt với những trường hợp phi lý như học sinh 50 tuổi hay điểm thi -5 điểm.

Entity Integrity: Tầm Quan Trọng của Khóa Chính

Cái này thì liên quan đến “primary key” 🔑. Nó đảm bảo rằng mọi bảng đều phải có một “primary key” và không có giá trị nào trong “primary key” được phép là NULL ❌. Nếu không có “primary key” hoặc có giá trị NULL thì coi như mỗi hàng không có “tên tuổi” 👤 gì cả, rất dễ gây ra nhầm lẫn ❓.

Ví dụ chi tiết:

1. Hệ thống quản lý bệnh viện: Tưởng tượng một hệ thống không áp dụng entity integrity, nơi mã bệnh nhân (MãBN) có thể là NULL: MãBN Tên Tuổi BN001 Nguyễn Văn A 45 NULL Trần Thị B 30 BN003 Lê Văn C 55 NULL Phạm Thị D 25 Làm thế nào để xác định chính xác bệnh nhân khi cần cập nhật thông tin? Làm sao để lưu trữ đơn thuốc cho bệnh nhân “NULL”? Hậu quả có thể rất nghiêm trọng: thuốc kê sai người, xét nghiệm nhầm bệnh nhân, v.v.
2. Hệ thống ngân hàng: Trong một bảng Tài_Khoản, mã tài khoản phải là duy nhất và không được để trống:

CREATE TABLE Tài_Khoản (
SốTàiKhoản VARCHAR(16) PRIMARY KEY, 
TênChủTàiKhoản VARCHAR(100) NOT NULL, 
SốDư DECIMAL(12,2) NOT NULL DEFAULT 0.00, 
NgàyMởTàiKhoản DATE NOT NULL );

Khi hệ thống áp dụng entity integrity, mọi giao dịch đều được gắn với một tài khoản xác định, giúp theo dõi dòng tiền chính xác và tránh mất mát tài chính.

Entity integrity là nền tảng cho việc xác định và truy xuất dữ liệu một cách đáng tin cậy. Khi mỗi bản ghi đều có một “căn cước” riêng biệt và không thể trùng lặp, việc quản lý và khai thác dữ liệu trở nên đơn giản và chính xác hơn nhiều.

Referential Integrity: Quản Lý Mối Quan Hệ Giữa Các Bảng

Cái này thì liên quan đến “foreign key” 🔗. Nó đảm bảo rằng mối quan hệ 🤝 giữa các bảng luôn “khăng khít” . Giá trị của “foreign key” ở một bảng phải khớp với giá trị của “primary key” 🔑 ở bảng mà nó tham chiếu đến (hoặc có thể là NULL). Nếu không có cái ràng buộc này thì có thể xảy ra tình trạng “con rơi con rớt” – tức là có dữ liệu ở bảng này nhưng lại không tìm thấy thông tin liên quan ở bảng kia 🤔.

Khi có vi phạm tính toàn vẹn tham chiếu (ví dụ, bạn cố gắng xóa 🗑️ một bản ghi ở bảng cha mà vẫn còn bản ghi con tham chiếu đến nó), hệ thống thường có mấy cách xử lý sau:

1. REJECT (RESTRICT) : Không cho phép thực hiện thao tác gây ra vi phạm 🛑.

CREATE TABLE Đơn_Hàng (
    MãĐơnHàng INT PRIMARY KEY,
    MãKháchHàng INT NOT NULL,
    NgàyĐặt DATE NOT NULL,
    TổngTiền DECIMAL(10,2) NOT NULL,
    FOREIGN KEY (MãKháchHàng) REFERENCES Khách_Hàng(MãKháchHàng)
    ON DELETE RESTRICT
    ON UPDATE RESTRICT
);

Tình huống thực tế: Khi một nhân viên cố gắng xóa thông tin của khách hàng “Nguyễn Văn A” (MãKH = 1001) từ bảng Khách_Hàng, nhưng khách hàng này đã có 5 đơn hàng trong bảng Đơn_Hàng.

Kết quả: Hệ thống sẽ hiển thị thông báo lỗi: “Không thể xóa khách hàng vì đã có đơn hàng liên quan.”

Lợi ích: Ngăn chặn việc mất dữ liệu quan trọng về lịch sử đơn hàng, đảm bảo dữ liệu được lưu trữ đầy đủ.

2. CASCADE ⛓️: Tự động xóa 🗑️ (hoặc cập nhật 🔄) các bản ghi liên quan ở bảng con.

CREATE TABLE Chi_Tiết_Đơn_Hàng (
    MãChiTiết INT PRIMARY KEY,
    MãĐơnHàng INT NOT NULL,
    MãSảnPhẩm INT NOT NULL,
    SốLượng INT NOT NULL,
    FOREIGN KEY (MãĐơnHàng) REFERENCES Đơn_Hàng(MãĐơnHàng)
    ON DELETE CASCADE
);

Tình huống thực tế: Khi phát hiện một đơn hàng giả mạo (MãĐH = 5001) cần phải xóa khỏi hệ thống.

Kết quả: Khi xóa đơn hàng này từ bảng Đơn_Hàng, tất cả các bản ghi liên quan trong bảng Chi_Tiết_Đơn_Hàng cũng sẽ tự động bị xóa.

Lợi ích: Duy trì tính nhất quán dữ liệu, tránh tình trạng “chi tiết đơn hàng mồ côi” không gắn với đơn hàng nào.

3. SET NULL ➡️ NULL: Đặt giá trị của khóa ngoại ở các bản ghi con thành NULL ∅.

CREATE TABLE Nhân_Viên (
    MãNV INT PRIMARY KEY,
    Tên VARCHAR(50) NOT NULL,
    MãPhòngBan INT,
    FOREIGN KEY (MãPhòngBan) REFERENCES Phòng_Ban(MãPhòngBan)
    ON DELETE SET NULL
);

Tình huống thực tế: Công ty tiến hành tái cơ cấu và giải thể phòng Marketing (MãPB = 3).

Kết quả: Khi xóa phòng Marketing khỏi bảng Phòng_Ban, tất cả nhân viên thuộc phòng này sẽ có MãPhòngBan được đặt thành NULL, chỉ ra rằng họ “chưa được phân công” vào phòng ban nào.

Lợi ích: Giữ lại thông tin nhân viên để có thể dễ dàng phân công lại họ vào các phòng ban khác trong tương lai.

4. SET DEFAULT ➡️ DEFAULT: Đặt giá trị của khóa ngoại ở các bản ghi con thành một giá trị mặc định nào đó ⚙️.

CREATE TABLE Sản_Phẩm (
    MãSP INT PRIMARY KEY,
    Tên VARCHAR(100) NOT NULL,
    MãDanhMục INT DEFAULT 1,
    FOREIGN KEY (MãDanhMục) REFERENCES Danh_Mục(MãDanhMục)
    ON DELETE SET DEFAULT
);

Tình huống thực tế: Cửa hàng quyết định loại bỏ danh mục “Sách giáo khoa” (MãDM = 5).

Kết quả: Khi xóa danh mục này, tất cả sản phẩm thuộc danh mục “Sách giáo khoa” sẽ được chuyển sang danh mục mặc định “Chưa phân loại” (MãDM = 1).

Lợi ích: Đảm bảo không có sản phẩm nào bị “thất lạc” trong hệ thống, luôn có một danh mục để phân loại.

Bảng tóm tắt hành vi ràng buộc toàn vẹn tham chiếu:

Tính toàn vẹn tham chiếu là yếu tố then chốt để duy trì tính nhất quán và chính xác giữa các bảng có liên quan trong cơ sở dữ liệu. Các tùy chọn xử lý khác nhau cung cấp sự linh hoạt dựa trên yêu cầu cụ thể của ứng dụng.

Relations and Tuples: Mấy Cái Đặc Điểm “Nhỏ Mà Có Võ” 💪

Để nhớ lâu hơn về “relations” và “tuples”, hãy “khắc cốt ghi tâm” ❤️ mấy cái đặc điểm này nhé:

Relations (Bảng):

• Phải có một cái tên “không lẫn đi đâu được” 🏷️.
• Không được có hai hàng “sinh đôi” 👯 giống hệt nhau 🚫.
• Mỗi ô chỉ chứa “một mẩu” 🤏 thông tin thôi 📦.
• Cả cột phải cùng “một dòng máu” 🧬 (cùng kiểu dữ liệu).
• Mỗi cột có một cái “biệt danh” 🏷️ riêng.
• Thứ tự của cột ↕️ và hàng ↔️ “không quan trọng lắm đâu” 😌.

Tuples (Hàng):

• Phải là “hàng độc” 🥇, không được trùng với hàng khác trong cùng một bảng 🚫.
• Là một dãy các giá trị có thứ tự 🔢 (thứ tự của các cột quan trọng).
• Một khi đã “xuất hiện” ✨ thì thường không thay đổi (trừ khi được cập nhật 🔄).
• Các giá trị bên trong phải là “nguyên tử” ⚛️.

Những đặc điểm này là nền tảng cho định nghĩa chính thức của mô hình quan hệ, đảm bảo tính nhất quán logic và tính toàn vẹn dữ liệu của nó. Việc thứ tự của các hàng không quan trọng cho phép cơ sở dữ liệu tối ưu hóa việc thực hiện truy vấn mà không ảnh hưởng đến ý nghĩa logic của dữ liệu. Tính duy nhất của các tuples đảm bảo rằng mỗi bản ghi đại diện cho một đối tượng riêng biệt.

The Relational Model in Practice: Ví Dụ Liên Quan Đến Khoa Học Dữ Liệu

Mô hình dữ liệu quan hệ được ứng dụng rộng rãi trong nhiều lĩnh vực, và khoa học dữ liệu không phải là ngoại lệ. Hãy xem xét một vài ví dụ về cách mô hình này được sử dụng trong thực tế :  

• Lưu trữ dữ liệu khách hàng: Một cơ sở dữ liệu có thể chứa một bảng “Khách hàng” với các thuộc tính như Mã khách hàng (primary key), Tên, Địa chỉ, Email. Các đơn hàng của khách hàng có thể được lưu trữ trong một bảng “Đơn hàng” với thuộc tính Mã đơn hàng (primary key) và Mã khách hàng (foreign key tham chiếu đến bảng “Khách hàng”). Thông tin về sản phẩm có thể được lưu trữ trong bảng “Sản phẩm” với Mã sản phẩm (primary key) và các thuộc tính liên quan. Mối quan hệ giữa các bảng này (khách hàng đặt đơn hàng, đơn hàng bao gồm các sản phẩm) cho phép chúng ta kết hợp dữ liệu từ các bảng khác nhau để phân tích hành vi mua hàng của khách hàng.
• Quản lý dữ liệu thí nghiệm: Trong một thí nghiệm khoa học, chúng ta có thể có một bảng “Thí nghiệm” với Mã thí nghiệm (primary key) và các thông tin chung về thí nghiệm. Các bảng khác có thể lưu trữ các biến số đo lường (ví dụ: bảng “Biến số” với Mã biến số, Tên biến số) và các kết quả quan sát (ví dụ: bảng “Quan sát” với Mã quan sát, Mã thí nghiệm (foreign key), Mã biến số (foreign key), Giá trị). Mô hình quan hệ giúp tổ chức dữ liệu một cách logic, cho phép dễ dàng truy vấn và phân tích mối quan hệ giữa các yếu tố khác nhau của thí nghiệm.
• Tổ chức phản hồi khảo sát: Dữ liệu từ các cuộc khảo sát có thể được tổ chức bằng mô hình quan hệ. Một bảng “Người trả lời” có thể chứa thông tin về người tham gia (Mã người trả lời – primary key, Thông tin nhân khẩu học). Một bảng “Câu hỏi” có thể lưu trữ danh sách các câu hỏi (Mã câu hỏi – primary key, Nội dung câu hỏi). Bảng “Phản hồi” có thể liên kết người trả lời với câu trả lời của họ (Mã phản hồi – primary key, Mã người trả lời – foreign key, Mã câu hỏi – foreign key, Câu trả lời). Điều này cho phép các nhà khoa học dữ liệu phân tích phản hồi theo các nhóm nhân khẩu học khác nhau.

Trong mỗi ví dụ này, mối quan hệ giữa các bảng (thông qua foreign keys) cho phép chúng ta kết hợp các tập dữ liệu khác nhau để thực hiện các phân tích phức tạp, chẳng hạn như kết hợp dữ liệu khách hàng với lịch sử mua hàng của họ để xác định các mẫu mua hàng. Mô hình quan hệ cung cấp một cách có cấu trúc để tổ chức các loại dữ liệu đa dạng mà chúng ta thường gặp trong khoa học dữ liệu, tạo điều kiện thuận lợi cho việc truy vấn và phân tích hiệu quả.

Looking Forward: Tương Lai “Sáng Lạng” ✨? Mô Hình Quan Hệ Trong Thế Giới Khoa Học Dữ Liệu 💡

Một trong những lý do khiến mô hình quan hệ vẫn “hot hòn họt” 🔥 trong khoa học dữ liệu là vì sự phổ biến của SQL (Structured Query Language) 💬 – cái ngôn ngữ “thần thánh” để “nói chuyện” với các cơ sở dữ liệu quan hệ. Biết SQL thì bạn có thể “moi móc” , “xào nấu” dữ liệu một cách “chuyên nghiệp” 😎.

Ngoài ra, mô hình quan hệ còn hỗ trợ các thuộc tính ACID (Atomicity, Consistency, Isolation, Durability) 💪, đảm bảo dữ liệu luôn “chắc chắn như bắp” .

Tuy rằng mấy cái NoSQL cũng đang nổi lên như “diều gặp gió” , nhưng mô hình quan hệ vẫn là “trùm cuối” cho những dữ liệu có cấu trúc rõ ràng và cần phân tích “kỹ càng” 🧐.

Conclusion: Củng Cố Hiểu Biết Về Cơ Sở Dữ Liệu Quan Hệ

Chúng ta vừa cùng nhau khai phá mô hình dữ liệu quan hệ, một viên gạch nền tảng trong thế giới khoa học dữ liệu. Nếu bạn đã theo dõi đến đây, xin chúc mừng! Bạn không chỉ tiếp thu kiến thức mà còn đang rèn luyện tư duy dữ liệu một cách bài bản. 🚀

Nhưng đừng dừng lại ở lý thuyết! Kiến thức chỉ thực sự có ý nghĩa khi bạn áp dụng nó vào thực tế. Hãy tiếp tục mày mò, thực hành, thử nghiệm, và đừng ngại đặt câu hỏi. AI và Data Science là cuộc chơi của những kẻ dám kiên trì, dám sai và dám sửa.

🔜 Trong bài viết tiếp theo, chúng ta sẽ tiếp tục hành trình với một chủ đề cực kỳ thú vị, giúp bạn tiến xa hơn trên con đường master Database for Data Science. Bạn đã sẵn sàng chưa? Hẹn gặp lại trong bài viết tiếp theo! 💡🔥

📢 Theo dõi Learning AI With Losers ngay để không bỏ lỡ bất kỳ bài viết nào! 🚀💙

🔖 Hashtags:
#LearningAIWithLosers #DatabaseForDataScience #RelationalModel #SQL #DataScience