Quá trình tạo ER model bằng data modeling với case study cụ thể

Huy Bui

3,669

24-10-2022

Ở bài trước chúng ta đã tìm hiểu tổng quan về sơ đồ ERD, để biết quá trình tạo ER model cho chính tổ chức hoặc doanh nghiệp của mình, hãy tham khảo bài viết này của Cole nhé.

Trong bất kỳ doanh nghiệp nào, quản lý dữ liệu hiệu quả và chính xác là điều cần thiết để thành công. Điều này đòi hỏi dữ liệu phải được tổ chức theo cách rõ ràng, logic và dễ hiểu. Sơ đồ mối quan hệ thực thể (ERD) là một biểu diễn đồ họa của dữ liệu cho thấy mối quan hệ giữa các thực thể trong cơ sở dữ liệu.

Case study Quá trình tạo ER model: Mua sản phẩm của shop online

Trong thực tế, hiếm có việc tạo sơ đồ ER từ con số 0, nghĩa là bản thân trong tổ chức đó đã phải có quy trình nghiệp vụ sẵn rồi . Thường thì trong khi thay thế và mở rộng hệ thống hiện tại, người ta sẽ thu thập dữ liệu và những quy trình nghiệp vụ đã có và tạo sơ đồ ER (theo cách tiếp cận bottom up).

Để mô tả quá trình tạo ER model, Cole lấy ví dụ về 1 shop thu âm online đã có hệ thống vận hành rõ ràng giả định rằng có một hệ thống đang chạy, chúng ta sẽ tạo sơ đồ ER của màn hình mua sản phẩm của doanh nghiệp này (Hình 1)

Hình 1: Màn hình mua sản phẩm của shop thu âm online

Process cho đến khi hoàn thành sơ đồ ER

Để hoàn thành Quá trình tạo ER model gồm có 4 bước như sau:

Nắm vững quy tắc nghiệp vụ

Để mô tả sơ đồ ER 1 cách chính xác, đầu tiên chúng ta cần phải hiểu các quy tắc nghiệp vụ. Trước hết, chúng ta sẽ chỉnh sửa các công việc có thể nắm bắt được từ Hình 1. Ngoài ra, những thông tin có trong Hình 1, trong màn hình trước (Màn hình đặt hàng), sẽ cần bổ sung các hạng mục nhập vào như thế nào. Từ đó, chúng ta có thể biết được những công việc sau đấy.

Màn hình này là “màn hình xác nhận đặt hàng” của giai đoạn mà khách hàng thực hiện đặt hàng.

1 khách hàng trong 1 lần đặt hàng có thể đặt nhiều sản phẩm.
Trước khi đặt hàng, thông tin khách hàng (bao gồm địa chỉ) được đăng ký trước đó.
Có thể chọn phương pháp chuyển hàng từ 2 phương thức sau: “Chuyển hàng ngay” và “Lưu 10 ngày”
Có thể chỉ định địa chỉ giao hàng (tên người nhận hàng, mã bưu điện, địa chỉ, số điện thoại). Trường hợp không chỉ định gì thì địa chỉ của khách hàng đã đăng ký sẽ được chỉ định.
Có thể chọn phương thức chi trả từ 2 phương thức sau: “Trả tiền trực tiếp” và “Credit card”
Có thể chỉ định ngày giao hàng. Khi đó có thể chỉ định “Giờ” và “Ngày”
Tuy nhiên, cũng có những lúc không thể chỉ đọc màn hình. Trong trường hợp đó, cần phải hỏi người thiết kế/phát triển hệ thống này.

Đến đây, chúng ta có thể nắm được quy tắc nghiệp vụ được đọc từ Hình 1. Tạm thời ở bước chuẩn bị này, chúng ta đã nắm được tương đối cách vận hành của hệ thống.

Trích xuất entity

Hãy trích xuất các Entity (thực thể) ngay từ hình 1.

Entity (thực thể) là tập hợp của một loại dữ liệu mà có một mục đích nào đó, chúng được đặt tên sao cho biểu hiện rõ ràng mục đích đó.

Người（ai）……người giao dịch, tổ chức, người phụ trách, cương vị, khách hàng, người làm công, v.v
Vật（làm cái gì）……sản phẩm, sản phẩm tồn kho, tài nguyên, thành phẩm, kho hàng
Giá trị tài sản……giá cả, tiền mặt, thuế tiêu dùng, tiền tệ, v.v
Thời gian……calendar, ngày nhà máy làm việc, kế hoạch nhật trình tiêu chuẩn, quản lý thời kỳ, v.v
Giao dịch・Hoạt động・Hành vi（làm thế nào）……nhận đặt hàng, đơn đặt hàng, giao hàng, thừa nhận, bán hạ giá, xuất hàng, nhập hàng, v.v

Trong Hình 1, chúng ta có thể thấy có 6 trường danh mục sau: “Sản phẩm”, “Giao hàng”, “Thông tin khách hàng”, “Người nhận”, “Phương pháp chi trả”, “Chỉ định mong muốn nhận”.

Để cho dễ hiểu, việc tập hợp cùng một loại dữ liệu vào một nơi và phân loại thành các trường danh mục cũng tương tự như Entity. Như vậy, các trường danh mục hiển thị trên màn hình dễ dàng trở thành entity.

Bảng 1: Quyết định tên entity

Ngoài ra, hạng mục mà có trong các trường danh mục thì trong entity được gọi là “Thuộc tính”. Ví dụ, trong trường “Sản phẩm”, thì các hạng mục như “Tên sản phẩm”, “Format”, “Đơn giá (bao gồm thuế)” thì sẽ trở thành thuộc tính của entity “Sản phẩm”.

Thuộc tính biểu hiện tính chất và đặc tính của thực thể qua thông tin mà được mang trong thực thể. Đến đây, tạm thời chúng ta đã có thể trích xuất entity.

Hãy thử kiểm tra xem có dư thừa hay thiếu hụt trong các entity không

Check thừa thiếu Entity – Quá trình tạo ER model

Tuy nhiên, việc trích xuất entity không kết thúc tại đây. Sau đó, chúng ta cần phải check xem entity đã được trích xuất ra có thừa hay thiếu không?

Entity có bị thiếu không?
Có bao gồm các entity không cần thiết không?

Đề xác nhận xem có đưa ra entity không bị thiếu, hãy nhớ các quy tắc dưới đây.

Quy tắc 1: Việc tìm ra entity cũng giống như việc đưa ra các thứ liên quan đến “ai”, “làm cái gì”, “làm như thế nào”. Và nếu liên quan đến kinh doanh thì đương nhiên trong hành vi “làm gì” thì “tiền bạc” và “thời gian” cũng có thể được đưa vào..

Thế thì, chúng ta sẽ tạo 6 entity là “Sản phẩm”, “Phương pháp chuyển đi”, “Khách hàng”, “Người nhận”, “Phương pháp chi trả”, “Thời gian chỉ định giao hàng”, và hãy xem xét lại rằng liệu những entity này có thể hiện toàn bộ quy tắc nghiệp vụ mà đã nắm được ban đầu không. Trường hợp không thể biểu thị được thì đó là dấu hiệu entity đang bị thiếu ở đâu đó.

“Ai” là “Khách hàng”. “Làm gì” là “Mua hàng”. Nhưng chưa có entity biểu hiện hành vi “làm như thế nào”. Vì màn hình này là màn hình xác nhận đặt hàng nên không thể quên “Đặt hàng” là hành vi quan trọng nhất. Do đó, chúng ta sẽ thêm entity “Đặt hàng”.

Đến đây có thể biểu diễn được quy tắc nghiệp vụ là “Khách hàng” “Đặt hàng” “Sản phẩm”. Hơn nữa, nếu có thể sử dụng entity còn lại thì có thể biểu thị được toàn bộ quy tắc nghiệp vụ mà đã nắm được ban đầu.

Khi đã có thể trích xuất entity mà biểu thị “Hành vi” là “Đặt hàng”, hãy nhớ quy tắc như tiếp theo đây.

Quy tắc 2: Entity mà đang biểu thị giao dịch/hoạt động/hành vi (làm thế nào) đồng thời cũng thường mang “thực thể rõ ràng chi tiết”.

Ví dụ, entity như đặt hàng, nhận đặt hàng, giao hàng, nhập hàng, xuất kho, nhập kho thường mang “thực thể rõ ràng chi tiết”.

Trong entity mà đang giải quyết ở đây cũng có entity “Đặt hàng” nên có thể cần thêm entity “Chi tiết đặt hàng” mới. Bây giờ chúng ta cần xác nhận xem “Chi tiết đặt hàng” được biểu thị ở đâu trên màn hình.

Hình 3 phần tương ứng với các chi tiết đặt hàng của màn hình mua hàng hóa

Trong một lần đặt hàng thì bao gồm nhiều chi tiết đặt hàng. Hoặc có thể nói là entity “Đặt hàng” tương ứng với một lần đặt hàng, còn entity “Chi tiết đặt hàng” là entity mà đã chia thành từng sản phẩm đặt hàng của một lần đặt hàng.

Đến đây, trong trường hợp có nhiều sản phẩm trong một lần đặt hàng thì hãy nhớ rằng phải có entity “Chi tiết đặt hàng” kết hợp với entity “Đặt hàng”.

Lưu ý thêm – Quá trình tạo ER model

Hơn nữa, mặc dù là bổ sung nhưng khi trích xuất entity, chúng ta cũng có thể đặt câu hỏi như sau:

Các dữ liệu sản phẩm chi tiết như “Never Too Much/ Luther Vandross, 1.470 Yên” được biểu thị trong trường “Sản phẩm” thì phải giải quyết như thế nào? Cái này cũng là entity sao?

Khi đó chúng ta cần nhớ quy tắc sau: “Ví dụ cụ thể của entity (gọi là instance) không phải là entity”. Vì lý do này nên “Sản phẩm” mà đang biểu thị và tập hợp “dữ liệu của sản phẩm một cách chi tiết” sẽ trở thành entity.

Hơn nữa, ở đây cũng cần phải nhớ thêm một điều nữa là entity có thể phân biệt rạch ròi thành 2 loại. Những cái có thể phân loại thành “Hành vi” được gọi là “Entity hệ event”. Mặt khác, những cái mà không ăn khớp (không thể thành động từ) được gọi là “Entity hệ resource” được giải quyết với tư cách là “Tài sản” mà là đối tượng của “Hành vi”.

Lần này, entity mà đã trích xuất có thể phân loại như dưới đây.

entity hệ event……”Đặt hàng”, “Chi tiết đặt hàng”Chú ý 1
entity hệ resource……”Sản phẩm”, “Khách hàng”, “Người nhận”, “Phương thức chi trả”, “Phương thức giao hàng”, “Thời gian chỉ định giao hàng”

Chú ý: Trong “Chi tiết đặt hàng” có vẻ không thể hiện hành vi, nhưng vì entity “Chi tiết đặt hàng” là entity tồn tại song song với entity “Đặt hàng” nên nó cũng giống với phân loại “Đặt hàng”. Do đó, cả “Chi tiết đặt hàng” và “Đặt hàng” đều được phân loại thành entity hệ event.

Xác nhận xem có entity không cần thiết hay không

Tiếp theo, chúng ta sẽ xác nhận xem có entity không cần thiết hay không. Để xác minh rằng có bao gồm những phần tử không quan trọng hay không? Hãy ghi nhớ những điều dưới đây.

Quy tắc 1: Trong trường hợp chỉ có một instance của entity thì đó không thể là entity.

Entity “Sản phẩm”, entity “Khách hàng”, entity “Đặt hàng”, entity “Chi tiết đặt hàng” mỗi loại đều có các instance. Trong các cửa hàng thông thường thì đều bán “nhiều sản phẩm”, có “nhiều khách hàng” ghé thăm, từ khách hàng có “nhiều đơn đặt hàng”. Trong một lần đặt hàng thì cũng có “nhiều chi tiết đặt hàng”.

Entity “Phương thức giao hàng” thì thế nào? Ở cửa hàng này, chúng ta có thể chọn từ hai tuỳ chọn “Có 10 ngày để dự trữ” và “Vận chuyển ngay lập tức” trong “Đơn vị đặt hàng” (đối với một lần đặt hàng). Sau đó, vì có hai trong số những tùy chọn là “Gửi ngay” và “10 ngày dự trữ” như là instance của phân loại đặt hàng nên xử lý như đối với entity cũng được.

Tương tự như vậy, bởi vì entity “Phương thức thanh toán” cũng có 2 sự lựa chọn là “Thanh toán khi giao hàng” và “Credit card” nên cũng xử lý nó như một entity.

Thế còn entity ” Điểm gửi đến” sẽ như thế nào? “Địa chỉ của bản thân khách hàng đặt hàng”. Vì “Điểm gửi đến” mà khách hàng nhập vào có thể xử lý với tư cách là instance nên với tư cách là entity cũng được.

Tuy nhiên, entity này tùy vào cách xử lý instance thì cũng có thể trở nên không cần thiết. Tóm lại, “Dù đặt hàng sau đó, vì cũng có khả năng sử dụng dữ liệu đó với nhiều khách hàng nên không cho phép khách hàng nhập lại dữ liệu giống nhau, và nếu xử lý instance dựa vào quy tắc là “cung cấp cơ chế có thể tham chiếu đến dữ liệu nhập vào của quá khứ” thì cái này tồn tại với tư cách là entity hệ resource mà có liên quan đến entity “Khách hàng”.

Mặt khác, nếu mà xử lý là có việc khách hàng chỉ định “Điểm gửi đến” riêng là “địa chỉ của bản thân khách hàng đặt hàng” trong một đơn vị đặt hàng thì không xử lý với tư cách là entity hệ resource. Vì “Điểm gửi đến” được nhập ở đây là dữ liệu nhập vào đơn vị đặt hàng nên sẽ bao gồm thông tin “Điểm gửi đến” trong entity “Đặt hàng”, đây lại là entity hệ event với tư cách là thuộc tính.

Lần này, chúng ta sẽ xử lý thông tin bao gồm trong trường “Điểm gửi đến” (Tên điểm gửi đến, mã số bưu điện, địa chỉ, số điện thoại) với tư cách là thuộc tính của entity “Đặt hàng”. Do đó, entity “Điểm gửi đến” không cần đến.

Hãy ghi nhớ quy tắc sau.

Quy tắc 2: Chúng ta phải tham chiếu một cách thích hợp với quy tắc nghiệp vụ, có những thực thể không thể không phù hợp với quy tắc nghiệp vụ.

Và cuối cùng là entity “Ngày chỉ định giao hàng”. Đây không hẳn là chọn ngày giao hàng theo sự thuận tiện của khách hàng. Đây là hình thức chọn từ “Ngày đã được quyết định trước” và “Thời gian đã được quyết định trước”. Tóm lại, cũng có thể xử lý với tư cách là 1 entity là entity “Ngày chỉ định giao hàng”, hoặc có thể tách mục đích với tư cách là entity, cách xử lý phân tách thành 2 entity như dưới đây cũng được.

Entity “Ngày chỉ định giao hàng”
Entity “Thời gian làm việc”

Như vậy, chúng ta đã có thể trích xuất 8 entity là “Sản phẩm”, “Khách hàng”, “Đặt hàng”, “Chi tiết đặt hàng”, “Phương thức giao hàng”, “Phương thức thanh toán”, “Ngày làm việc”, “Thời gian làm việc”.

Vì vậy, thêm y nguyên các hạng mục có trên màn hình vào thuộc tính của các entity, và hãy trích xuất sơ đồ ER (Hình 4).

Trong entity “Sản phẩm”, chúng ta sẽ định nghĩa “Tên sản phẩm”, “Format”, “Đơn giá (bao gồm thuế) mà được phân loại trong trường “Sản phẩm” với tư cách là thuộc tính.

”Mã số đặt hàng”, “Ngày tháng năm đặt hàng” sẽ là thuộc tính của entity “Đặt hàng”. Trong entity hệ event như là entity “Đặt hàng” cần phải bao gồm thuộc tính mà ghi lại event (hành vi) đã phát sinh như là “Ngày tháng năm đặt hàng”.

”Mã số chi tiết đặt hàng”, “Số lượng”, “Giá cả” sẽ là thuộc tính của entity “Chi tiết đặt hàng”. Ngoài ra, khi hạng mục “No” trên hình 1 sẽ để nguyên thành tên thuộc tính, vì sẽ biết ngay được có mã số là gì nên sẽ thành “Mã số chi tiết đặt hàng”.

Trong entity “Ngày làm việc”, chúng ta sẽ thêm “Flag ngày làm việc” vào với tư cách là thuộc tính nhằm phân biệt là có phải ngày làm việc hay không.

Hơn nữa, vì “Số tiền từng phần”, “Tổng số tiền”, “Tiền ship”, “Thuế tiêu dùng” đang được xử lý trong một đơn vị đặt hàng nên chúng ta sẽ thêm vào entity “Đặt hàng”.

Thiết định các mối quan hệ

Đây là bước cuối cùng. Chúng ta sẽ liên kết nhóm entity đã trích xuất với nhau tạo thành “các mối quan hệ”. Trước tiên, chúng ta cần thiết định “Khóa chính”.

“Khóa chính” được thiết định nhằm đảm bảo tính duy nhất của instance. Ví dụ, trong entity “Sản phẩm” tồn tại nhiều instance (sản phẩm chi tiết) nhưng có tồn tại duy nhất không? Để giải quyết vấn đề này, chúng ta sẽ thêm các thuộc tính sau đây vào entity “Sản phẩm”: “Tên sản phẩm”, “format (ví dụ CD hay analog record)”, “Giá (bao gồm phí)”.

Thế thì, “Tên sản phẩm” có trở thành khóa chính được không? Vì chắc chắn rằng cùng tên sản phẩm thì tồn tại sản phẩm có format khác nhau nên không thể đảm bảo tính duy nhất. Thế thì, “Tên sản phẩm” và “Format” kết hợp lại thành khóa chính (gọi là khóa phức hợp) có được không? Nhìn qua thì có vẻ được.

Nhưng sau đó chúng ta thấy rằng khóa phức hợp gồm “Tên sản phẩm” và “Format” không đảm bảo tính duy nhất. Ví dụ, cũng có thể vừa thay đổi sự đại diện của “Tên sản phẩm”, vừa chi tiết hóa thêm nữa analog record của “Format” thành loại 30cm LP, EP. Nếu như vậy thì việc định trước instance một cách duy nhất với tư cách khóa chính là không thể.

Như vậy, việc thiết định thuộc tính mà cũng có thể suy nghĩ về việc thay đổi nào đó thành khóa chính là không khuyến khích. Bởi vậy, trong entity “Sản phẩm” chúng ta sẽ thêm thuộc tính mới là “ID của sản phẩm”.

Cũng giống như thế, chúng ta cũng thiết định khóa chính cho các entity khác.

Trong entity “Ngày làm việc”, chỉ cần thuộc tính “Ngày tháng năm” là có thể đảm bảo tính duy nhất rồi, và vì không có ý định thay đổi ý nghĩa ngày tháng nên có thể lấy luôn làm khóa chính.

Thực ra, entity “Chi tiết sản phẩm” khác với những entity khác. Các entity khác tự nó có thể tồn tại (gọi là entity không phụ thuộc). Nhưng entity “Chi tiết đặt hàng” là entity tồn tại khi entity “Đặt hàng” tồn tại (gọi là entity phụ thuộc). Ngoài ra, khi đó entity “Đặt hàng” được gọi là entity cha, còn entity “Chi tiết đặt hàng” được gọi là entity con. Không có cha thì cũng không tồn tại con, nên mới gọi như vậy.

Trong việc bảo đảm tính duy nhất của entity “Chi tiết đặt hàng”, không phải chỉ có “Mã chi tiết đặt hàng”, mà cũng cần kết hợp với “Mã đặt hàng” là khóa chính của entity cha “Đặt hàng”, cần phải bao gồm trong khóa chính của entity “Chi tiết đặt hàng”. Hãy ghi nhớ điều sau.

Quy tắc: Trường hợp entity phụ thuộc, trong khóa chính của entity con có bao gồm khóa chính của entity cha.

Sau đây hãy thiết lập mối quan hệ giữa các entity.

Mối quan hệ (relationship) không phải chỉ bao gồm những biểu thị của đối tượng và chủ thể “Ai”, “Làm cái gì”, “Làm thế nào” mà quan trọng là ghi rõ sự kết hợp với “số lượng mối quan hệ tương ứng” là “1:1”, “1:n”, “n:n”. “Số lượng mối quan hệ tương ứng” này được gọi là cardinality (mức độ số lượng nhiều).

Khi suy nghĩ về mối quan hệ, không giải quyết tất cả các entity trong một lần, mà làm với một bộ 2 entity từ đặc tính liên quan là “Ai”, “Làm gì”, “Làm như thế nào”, vừa phải xác nhận việc “Đối với mỗi một entity, thì có thể xác nhận bao nhiêu entity khác?”, vừa thiết định số lượng mối quan hệ giữa chúng.

Ví dụ, chúng ta hãy xem xét mối quan hệ giữa entity “Khách hàng” và entity “Đặt hàng”.

Trường hợp nhìn entity “Đặt hàng” từ entity “Khách hàng”: “Một khách hàng thực hiện nhiều lần đặt hàng” → Quan hệ là “Khách hàng và Đặt hàng” ＝ “1:n”

Trường hợp nhìn entity “Khách hàng” từ entity “Đặt hàng”: “Khách hàng của một lần đặt hàng là một người” → Quan hệ là “Đặt hàng và Khách hàng” ＝ “1:1”

Do đó, chúng ta có biểu hiện như sau. (Hình 6)

Mối quan hệ là “Khách hàng:Đặt hàng = 1:n”

Hãy thiết định mối quan hệ trong toàn bộ entity giống như trên. Ngoài ra, hãy nhớ một điều như sau: Mối quan hệ giữa entity mà biểu hiện “Chủ thể” như “Người”, “Tổ chức”, “Khách hàng” và entity biểu hiện “Hành vi” như “Nhận đặt hàng”, “Đặt hàng”, “Giao hàng” là mối quan hệ “1:n” nếu hướng tới “Hành vi” từ “Chủ thể”.

Cuối cùng chúng ta hoàn tất Quá trình tạo ER model như sau (Hình 7)

Cuối cùng, từ định nghĩa các entity, chúng ta tạo DDL (Data Definition Language: ngôn ngữ định nghĩa dữ liệu, tóm lại là câu CREATE TABLE), và thực hiện trong cơ sở dữ liệu.

>> Xem thêm: 20 câu hỏi phỏng vấn data modeling để hiểu rõ thêm về các định nghĩa xoay quanh ERD và mô hình hóa dữ liệu

Tóm tắt

Vậy là trong bài viết này, Cole đã cùng các bạn trải nghiệm quá trình tạo và mô tả sơ đồ ER. Hy vọng, bạn đọc đã thu được các kiến thức tối thiểu cần trong quá trình tạo ER model (quá trình lên ý tưởng) và áp dụng được vào trong công việc của mình. Dù sao chăng nữa, để cảm nhận được sơ đồ ER một cách sâu sắc, chúng ta phải chính tay tạo nên nó.

>> Làm quen với ER model trong Khóa học data analyst – học BA cùng Cole