inflearn logo
inflearn logo

Học mô hình hóa dữ liệu dễ dàng: Từ cơ bản đến thiết kế bảng thực tế (DASP/DAP)

Bạn đã bao giờ cảm thấy bế tắc vì việc thiết kế bảng dữ liệu chưa? Đây là khóa học dành cho những ai từng trăn trở với những câu hỏi như: "Bảng này liệu có đúng không?", "Nên chọn cột nào làm PK (Khóa chính) đây?", "Kết nối các mối quan hệ như thế này có ổn không?" hay "Liệu khi thêm tính năng mới, mình có phải thiết kế lại bảng từ đầu không?".

(5.0) 2 đánh giá

7 học viên

Độ khó Cơ bản

Thời gian Không giới hạn

SQL
SQL
DBMS/RDBMS
DBMS/RDBMS
ERD
ERD
database-modeling
database-modeling
Data Architecture Semi-Professional
Data Architecture Semi-Professional
SQL
SQL
DBMS/RDBMS
DBMS/RDBMS
ERD
ERD
database-modeling
database-modeling
Data Architecture Semi-Professional
Data Architecture Semi-Professional

Bạn sẽ nhận được điều này sau khi học.

  • Cách phân tích yêu cầu và thiết kế bảng dữ liệu

  • Các khái niệm thiết yếu của 'Mô hình hóa dữ liệu logic' về thực thể, thuộc tính, mã định danh và mối quan hệ

  • Kiến thức để đạt được chứng chỉ DASP và DAP

  • Phương pháp thiết kế bảng cân nhắc đến hiệu suất

  • Ký hiệu để vẽ ERD (IE, Barker)

Thiết kế bảng của các bạn, liệu có ổn không?

  • Mỗi khi thiết kế đều cảm thấy bất an vì không chắc chắn

  • Muốn sửa đổi nhưng cấu trúc phức tạp đã bị rối tung lên rồi

  • Lặp lại chu kỳ thêm tính năng = thiết kế lại bảng

  • Mô hình hóa dữ liệu chưa từng được học một cách bài bản


Trong khóa học này, bạn sẽ học cách thiết kế bảng không chỉ dừng lại ở việc 'chỉ hoạt động'
mà còn có khả năng mở rộng và dễ dàng bảo trì.

Những trăn trở mà bất kỳ ai cũng gặp phải trong thực tế làm việc

Việc tạo ra một bảng có thể đáp ứng đúng yêu cầu của khách hàng là điều không hề dễ dàng.
Thật khó để tự mình phán đoán xem cấu trúc nào là phù hợp, thiết kế có dễ chỉnh sửa hay không, hay cấu trúc đó có khả năng mở rộng hay không..

Dù có tìm kiếm thử đi chăng nữa, mỗi tình huống thực tế đều khác nhau, và cuối cùng chỉ còn lại cảm giác bất an ngày càng lớn với câu hỏi: 'Liệu đây có phải là cách làm đúng không?'

Vấn đề thiết kế sẽ càng trở nên nghiêm trọng hơn theo thời gian

Lúc đầu thì có vẻ ổn đấy, nhưng mà...

Nhiều nhà phát triển cũng có trải nghiệm tương tự.
Trong giai đoạn đầu của dự án, họ tập trung vào việc tạo bảng nhanh chóng và triển khai các tính năng phát triển.
Vì dữ liệu còn ít và yêu cầu chưa cao nên mọi thứ dường như đều diễn ra suôn sẻ.

Tuy nhiên, khi thời gian trôi qua, dự án phát triển và độ phức tạp tăng lên,
cấu trúc bảng được tạo ra "chỉ để cho nhanh" ở giai đoạn đầu dần trở thành một trở ngại lớn.

Việc thêm một tính năng đơn giản cũng đòi hỏi phải sửa đổi nhiều bảng, các lỗi lặp đi lặp lại do vấn đề nhất quán dữ liệu và
cuối cùng, bạn sẽ phải hối hận rằng: "Giá như lúc đó mình thiết kế cẩn thận hơn...".


Giai đoạn đầu

😊

  • "Chỉ cần chứa được dữ liệu là được rồi!"

  • Thiết kế mà không suy nghĩ kỹ

    Dồn tất cả các thuộc tính cần thiết vào một bảng duy nhất để phát triển nhanh chóng

  • Khi lượng dữ liệu ít thì có vẻ không có vấn đề gì


6 tháng sau

📉

  • Mỗi khi thêm tính năng mới đều cần sửa đổi cấu trúc bảng

  • Dữ liệu giống nhau bị trùng lặp ở nhiều bảng gây ra vấn đề về tính nhất quán

  • Truy vấn ngày càng trở nên phức tạp và hiệu suất bắt đầu chậm lại

Sau 1~2 năm

🚨

  • Để thêm một tính năng, số lượng nơi cần chỉnh sửa trở nên quá nhiều

  • Dữ liệu cần thiết phải lấy từ bảng nào, lúc nào cũng phải cân nhắc

  • Bất nhất dữ liệu thường xuyên xảy ra và mất nhiều thời gian để chỉnh sửa


Giải pháp: Mô hình hóa dữ liệu đúng cách (Thiết kế bảng)

Cùng một yêu cầu, thiết kế khác nhau

Ngay cả khi triển khai cùng một chức năng, kết quả sẽ hoàn toàn khác biệt tùy thuộc vào cách thiết kế.
Một bảng được thiết kế có tính đến khả năng mở rộng có thể dễ dàng đáp ứng ngay cả khi các yêu cầu thay đổi.

Ngược lại, những bảng được tạo ra mà không có sự cân nhắc kỹ lưỡng sẽ đòi hỏi nhiều chỉnh sửa ngay cả với những thay đổi nhỏ, và các vấn đề ngoài dự kiến sẽ liên tục phát sinh.

Ban đầu, sự khác biệt này rất khó nhận thấy. Bởi vì cả hai đều có vẻ hoạt động tốt.
Tuy nhiên, thời gian càng trôi qua, sự khác biệt đó sẽ thể hiện rõ qua tốc độ phát triển và độ khó khi bảo trì.

Khóa học này hướng dẫn cách thiết kế bảng có khả năng mở rộng.
Bạn sẽ học cách làm "đúng ngay từ đầu" thay vì tư duy "để sau này sửa cũng được".
Sau khi hoàn thành khóa học, bạn có thể nhìn vào yêu cầu và thiết kế cấu trúc có khả năng mở rộng.


📌Yêu cầu của khách hàng📌

  1. Tại căn tin, bạn có thể kiểm tra thực đơn hàng tuần.

  2. Thực đơn được cung cấp cho bữa trưa/tối từ thứ Hai đến thứ Sáu và đối với mỗi thực đơn

    Có thể kiểm tra thông tin của chuyên gia dinh dưỡng đã cung cấp thực đơn đó.

  3. Trong thực đơn bữa ăn, cơm và canh là thành phần bắt buộc, và có thể bao gồm nhiều món phụ khác nhau.

    Lượng calo cũng cần được quản lý.

  4. Cũng có trường hợp có các món phụ như sữa chua, kem và trái cây.

👎Mô hình được thiết kế thiếu suy nghĩ

👍Mô hình đã được cân nhắc kỹ lưỡng

Đặc điểm của bài giảng này

1. Học tập trung vào thực tiễn

Nội dung được cấu trúc để có thể áp dụng ngay vào thực tế thay vì chỉ là lý thuyết đơn thuần

  • Đưa ra những trăn trở thường gặp trong thực tế và phương pháp giải quyết

  • Sử dụng các ví dụ gần gũi với thực tế như hệ thống cho thuê sách, trung tâm mua sắm, v.v.

  • Học tập thông qua việc trực tiếp thực hiện theo các bước mô hình hóa dữ liệu

2. Tài liệu giảng dạy có hệ thống

Ôn tập hoàn hảo với tài liệu PPT dài 700 trang

  • Nội dung tóm tắt trọng tâm giúp dễ dàng nắm bắt khái niệm

  • Tài liệu tham khảo có thể xem lại bất cứ lúc nào

3. Ai cũng có thể thực hành dễ dàng

Có thể bắt đầu ngay mà không cần chuẩn bị đặc biệt

  • Chỉ cần giấy và bút là đủ, công cụ chỉ là tùy chọn

  • Thực hành trên ERD Cloud dựa trên nền tảng web mà không cần cài đặt riêng

  • Giải thích cả ký hiệu Barker và ký hiệu IE

Cấu trúc khóa học (Mục lục chi tiết)

1. Bắt đầu bài giảng cơ bản về mô hình hóa dữ liệu

Giới thiệu khóa học: Bạn đã bao giờ cảm thấy bế tắc trong quá trình thiết kế bảng chưa?

  • Nội dung sẽ được đề cập trong bài giảng

  • Khóa học này dành cho ai? (Feat. Các nhà phát triển cần thiết kế DB và những người mới bắt đầu mô hình hóa)

  • Cấu trúc bài giảng

  • Kiến thức tiền đề để tham gia khóa học


Cách nâng cao hiệu quả công việc và năng suất phát triển

  • Thiết kế mô hình dữ liệu là gì?

  • Chúng tôi không quản lý ERD

  • Thiết kế như thế này thì sau này sẽ vất vả lắm đấy

Kiểm tra mức độ hiểu biết về mô hình hóa dữ liệu của tôi

  • Câu đố 1 : Câu hỏi Đúng/Sai

  • Câu đố 2: Đoán số lượng bảng

2. Bước đầu tiên để mô hình hóa dữ liệu

Các bước từ phân tích yêu cầu đến tạo bảng

  • Các bước mô hình hóa dữ liệu giải thích qua dự án cá nhân (Toy Project)

  • Phân tích/Định nghĩa yêu cầu

  • Thiết lập lĩnh vực chủ đề

  • Mô hình hóa dữ liệu khái niệm

  • Mô hình hóa dữ liệu logic

  • Mô hình hóa dữ liệu vật lý

  • Liệu có thể đơn giản hóa các bước mô hình hóa dữ liệu không?

Ký hiệu mô hình hóa dữ liệu (Barker, IE)

  • Ký hiệu Barker/IE cho mô hình hóa dữ liệu

  • Ký hiệu thực thể

  • Ký hiệu thuộc tính

  • Ký hiệu định danh

  • Ký hiệu mối quan hệ

  • Ký hiệu Subtype

Công cụ mô hình hóa dữ liệu (ERwin DA# ERDCloud)

  • ERwin DA# ERDCloud

  • Thực hành ERDCloud

3. Thực thể [Bảng]: Những thông tin nào nên được đưa vào bảng?

Thực thể là gì

  • Khái niệm thực thể

  • Bảng? Thực thể? Chúng khác nhau như thế nào?

Cách trích xuất thực thể từ các yêu cầu

  • Làm thế nào để trích xuất thực thể (entity)?

  • Cốt lõi của mô hình hóa dữ liệu 'Trích xuất Entity'

  • [Thực hành] Hướng dẫn trích xuất Entity

Kiểm tra xem thực thể đã được trích xuất 'tốt' hay chưa

  • Liệu ý nghĩa của thực thể đã được gán một cách rõ ràng chưa

  • Có phải là đối tượng cần quản lý hay không

  • Có đang tạo thành một tập hợp hay không

  • Liệu nó có đang bị phụ thuộc vào quy trình nghiệp vụ hay không

  • Có mang tính độc lập hay không

  • Liệu có đang trích xuất thực thể theo từng màn hình hay không

Phân loại thực thể giúp bạn biết được loại dữ liệu nào đang được lưu trữ

  • Thực thể cũng có tính chất riêng

  • Bí quyết để thiết kế bảng hiệu quả: Phân loại thực thể theo đặc tính

  • Lợi ích của việc phân loại thực thể

4. Thuộc tính [Cột]: Không phải tất cả các cột trong yêu cầu đều được thêm vào.

Thuộc tính là gì

  • Khái niệm thuộc tính

  • Thành phần của thuộc tính

Phân loại thuộc tính giúp phát triển truy vấn dễ dàng hơn

  • Lý do phân loại thuộc tính

  • Thuộc tính cơ bản

  • Thuộc tính quan hệ

  • Thuộc tính trích xuất/Thuộc tính trùng lặp

  • Thuộc tính hệ thống

Thiết kế thuộc tính đặc biệt mà nhiều nhà phát triển bỏ lỡ

  • Thuộc tính đặc biệt

  • Đa trị thuộc tính

  • Thuộc tính phức hợp

  • Thuộc tính loại trừ (Exclusive Attribute)

  • Thuộc tính mã (Code Attribute)

Phương pháp rút trích thuộc tính

  • Bí quyết tìm ra những thuộc tính thực sự cần thiết

  • [Thực hành] Hướng dẫn rút trích thuộc tính

5. Định danh [PK]: Hãy chọn những cột như thế này làm PK.

Định danh là gì

  • Khái niệm về định danh

  • Đặc điểm của định danh (식별자)

  • Phân loại định danh

Mã định danh nhân tạo thường được sử dụng dưới dạng 'Số OO'

  • Định danh bản chất và Định danh nhân tạo (feat. Chủ ngữ thật và Chủ ngữ giả)

  • Các loại định danh thường được sử dụng theo đặc điểm của từng thực thể

  • Nên sử dụng định danh bản thể hay định danh nhân tạo?

Phương pháp lựa chọn mã định danh

  • [Thực hành] Các bước lựa chọn định danh

  • Những lưu ý khi lựa chọn thực thể định danh

Những câu chuyện khác nhau liên quan đến định danh

  • Nếu vô điều kiện tạo ra bằng định danh nhân tạo thì sao?

  • Hình thức thuộc tính mã sản phẩm (000000121 vs GOD000121 vs 121)

  • Thói quen suy nghĩ về dữ liệu thực tế (case data)

6. Mối quan hệ [FK]: Kết nối giữa các bảng - Join

Quan hệ là gì

  • Khái niệm quan hệ

  • Mối quan hệ và Join

Các thành phần của quan hệ (Bậc quan hệ, Tính tùy chọn của quan hệ, Tên quan hệ)

  • Các thành phần của quan hệ

  • Bậc của quan hệ (1:1 / 1:M / M:N)

  • Tính chọn lọc của mối quan hệ (Tùy chọn / Bắt buộc)

  • Tên quan hệ

Bí quyết để kết nối các mối quan hệ một cách dễ dàng

  • Ý nghĩa ẩn giấu của đường kẻ mối quan hệ

  • Quan hệ phụ thuộc

  • Quan hệ tham chiếu

  • Mối quan hệ định danh và Mối quan hệ không định danh

  • Tổng hợp quan hệ phụ thuộc/tham chiếu và quan hệ định danh/không định danh

Các mối quan hệ phức tạp gặp trong thực tế (Đa hình, Đệ quy, Loại trừ, BOM)

  • Các mối quan hệ đa dạng

  • Mối quan hệ đa chiều (Đa quan hệ)

  • Mối quan hệ đệ quy (= Mối quan hệ vòng lặp)

  • Mối quan hệ loại trừ (= Mối quan hệ Arc)

  • Quan hệ BOM

Phương pháp rút trích quan hệ

  • [Thực hành] Làm theo các bước rút trích quan hệ 1

  • [Thực hành] Các bước xác định mối quan hệ 2

Những câu chuyện khác nhau liên quan đến quan hệ

  • Có cần thiết lập ràng buộc khóa ngoại (FK) không? (feat. Công ty tôi không tạo FK)

  • Trường hợp không cần kết nối đường quan hệ

  • Kết nối quan hệ để cải thiện hiệu suất

7. Subtype: Cách quản lý các thực thể tương tự một cách chiến lược

Subtype và Supertype

  • Khái niệm Subtype/Supertype

  • Đặc điểm Subtype/Supertype

Trong tình huống nào thì nên sử dụng subtype?

  • Lý do sử dụng subtype

  • Những tình huống cần trích xuất subtype

Phương pháp rút trích subtype

  • [Thực hành] Hướng dẫn rút trích Subtype

  • Những lưu ý khi rút trích subtype

Tạo bảng cho thực thể bao gồm subtype

  • 3 loại kiểu tạo bảng của thực thể bao gồm subtype

  • Loại 1. Cấu trúc Subtype

  • Loại 2. Cấu trúc bảng tích hợp

  • Loại 3. Cấu trúc bảng riêng biệt

  • Tiêu chí lựa chọn kiểu tạo bảng

8. Chuẩn hóa và Phi chuẩn hóa: Cấu trúc hoàn hảo vs Hiệu suất nhanh chóng

Chuẩn hóa là gì

  • Khái niệm chuẩn hóa

  • Tại sao phải thực hiện chuẩn hóa?

  • Ưu điểm và nhược điểm của chuẩn hóa

Chuẩn hóa dạng 1 - Hãy tách biệt những thứ trùng lặp!

  • Định nghĩa chuẩn hóa dạng 1 (1NF)

  • Vấn đề khi không thực hiện chuẩn hóa dạng 1 (1NF)

  • [Thực hành] Chúng ta cùng cải thiện nhé?

Chuẩn hóa 2 - Phải phụ thuộc hoàn toàn vào tất cả các thuộc tính định danh!

  • Định nghĩa chuẩn hóa lần 2 (2NF)

  • Vấn đề khi không thực hiện chuẩn hóa dạng 2

  • [Thực hành] Chúng ta cùng cải thiện nhé?

Chuẩn hóa 2 - Có quan hệ phụ thuộc giữa các thuộc tính không phải khóa?

  • Định nghĩa chuẩn hóa dạng 3 (3NF)

  • Vấn đề khi không thực hiện chuẩn hóa dạng 3 (3NF)

  • [Thực hành] Chúng ta cùng cải thiện nhé?

Phản chuẩn hóa (Phi chuẩn hóa) là gì

  • Khái niệm bán bình thường hóa (Denormalization)

  • Những điều cần kiểm tra bắt buộc trước khi thực hiện phản chuẩn hóa!

  • Ưu điểm và nhược điểm của phản chuẩn hóa (Denormalization)

3 phương pháp phản chuẩn hóa (phi chuẩn hóa) để cải thiện hiệu suất

  • Tạo cột trùng lặp

  • Tạo bảng trùng lặp

  • Chia tách bảng

9. Quản lý mã chung và lịch sử

Mã dùng chung

  • Mã dùng chung là gì?

  • Lý do sử dụng mã (code)

  • Những lưu ý khi thiết kế mã chung

Phương pháp thiết kế mã chung

  • [Thực hành] Phương pháp thiết kế mã chung 1

  • [Thực hành] Phương pháp thiết kế mã chung 2

  • Mã chung VS Mã riêng lẻ

Quản lý lịch sử

  • Lịch sử là gì?

  • Trong tình huống OO, việc quản lý lịch sử là bắt buộc.

  • [Thực hành] Phương pháp thiết kế lịch sử 1

  • [Thực hành] Phương pháp thiết kế lịch sử 2

Khuyến nghị cho
những người này

Khóa học này dành cho ai?

  • 'Nhà phát triển' cần thiết kế bảng DB theo từng lĩnh vực nghiệp vụ

  • 'Người mô hình hóa mới vào nghề', người cần thực hiện mô hình hóa dữ liệu trong khi phải trăn trở về cấu trúc tổng thể.

  • Dành cho những ai đang hướng tới mục tiêu đạt được chứng chỉ DASP, DAP!

Cần biết trước khi bắt đầu?

  • Khái niệm về Join trong SQL

  • Hiểu biết cơ bản về truy vấn Select ~ From ~ Where

Xin chào
Đây là Archix

Xin chào 👋

Tôi là Archix, hiện đang làm việc với tư cách là Data Architect tại một công ty nước ngoài.

Xuất thân là một nhà phát triển Back-end, tôi đã đạt được các chứng chỉ SQLP 🎖 và DAP 🎖 để bước đi trên con đường của một chuyên gia dữ liệu. Hiện tại, tôi đang làm việc vì mục tiêu quản lý dữ liệu tốt hơn bằng cách hỗ trợ các nhà phát triển tối ưu hóa mô hình dữ liệu và tinh chỉnh truy vấn (query tuning).

Trải qua nhiều dự án và quá trình vận hành, tôi đã nhận ra một điều rõ ràng rằng: Một hệ thống có thiết kế vững chắc sẽ không bao giờ bị lung lay. Ngược lại, một hệ thống có thiết kế không tốt sẽ khiến các vấn đề nhỏ lặp đi lặp lại, cuối cùng dẫn đến việc lãng phí nguồn lực không cần thiết.

Vì đã từng có kinh nghiệm làm việc với tư cách là một nhà phát triển, tôi đã trực tiếp trải qua những tình huống như vậy, và tôi muốn truyền tải những nội dung có thể áp dụng ngay vào thực tế bằng cách lồng ghép những kinh nghiệm đó vào bài giảng.

Trong tương lai, tôi dự định sẽ tiếp tục hoạt động tích cực để truyền bá tầm quan trọng của việc mô hình hóa dữ liệu trên nhiều phương diện khác nhau.

Sau khi hoàn thành toàn bộ khóa học, nếu bạn có bất kỳ thắc mắc nào về vị trí DA (Phân tích dữ liệu) hay định hướng nghề nghiệp, đừng ngần ngại liên hệ với tôi qua email dưới đây kèm theo xác nhận "hoàn thành khóa học". Tôi sẽ cố gắng hỗ trợ bạn trong khả năng có thể.

📩cherish1058@naver.com

Cảm ơn bạn.

Thêm

Chương trình giảng dạy

Tất cả

37 bài giảng ∙ (9giờ 42phút)

Tài liệu khóa học:

Tài liệu bài giảng
Ngày đăng: 
Cập nhật lần cuối: 

Đánh giá

Tất cả

2 đánh giá

5.0

2 đánh giá

  • cherish10588578님의 프로필 이미지
    cherish10588578

    Đánh giá 2

    Đánh giá trung bình 4.0

    5

    100% đã tham gia

    • bbyyydd님의 프로필 이미지
      bbyyydd

      Đánh giá 5

      Đánh giá trung bình 4.6

      5

      100% đã tham gia

      Trong quá trình phát triển, có những lúc tôi phải thiết kế bảng, và sau khi nghe bài giảng, nhiều phần thắc mắc của tôi dường như đã được giải tỏa. Trên hết, tôi đã từng rất vất vả khi viết truy vấn do thiết kế bảng sai, nên câu nói rằng không phải do năng lực viết truy vấn của tôi kém đã an ủi tôi rất nhiều ㅠㅠ

      Khóa học tương tự

      Khám phá các khóa học khác trong cùng lĩnh vực!

      Ưu đãi có thời hạn

      51.480 ₫

      35%

      1.652.503 ₫