30 phút data modeling - miêu tả ER

Mở đầu

Trong bài viết này, chúng ta sẽ lấy một ví dụ sơ đồ ER trong thực tế, làm thử process cho đến khi thực hiện trong RDBMS, từ đó chúng ta có thể học tập các kiến thức tối thiểu cần thiết cho việc mô tả sơ đồ ER.

Chủ đề là mua sản phẩm của shop online

Trong nghiệp vụ thực tế, hiếm có việc tạo sơ đồ ER từ chỗ không tồn tại một hệ thống nào cả. Có lẽ trong khi thay thế và mở rộng hệ thống hiện tại, tôi nghĩ rằng việc “thu thập data từ màn hình và bảng biểu đã có và tạo sơ đồ ER (cách tiếp cận bottom up)” có rất nhiều.

Do đó, trong bài viết này, giả định rằng có một hệ thống đang chạy, mỗi chúng ta sẽ tạo sơ đồ ER của màn hình mua sản phẩm của shop thu âm online (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

Cho đến khi hoàn thành sơ đồ ER, có 4 process. (Hình 2)

Hình 2: Trong 4 process để tạo sơ đồ ER, hãy xem trình tự chi tiết các process

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

Trước hết, chúng ta hãy hiểu các quy tắc nghiệp vụ. Tại đây, đầu tiên chúng ta sẽ chỉnh sửa các 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.

Vì vậy, các việc sau chúng ta có thể biết được.

• 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”

Trong thực tế, 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ụ mà được đọc từ Hình 1. Tạm thời việc chuẩn bị là OK.

Trích xuất entity

Hãy trích xuất các thực thể ngay lập tức từ hình 1.

Entity là gì?

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

_Tiền bạc _……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

Entiry là tập hợp cùng một loại dữ liệu và mang một mục đích nào đó, đặt tên sao cho biểu hiện rõ ràng mục đích đó.

Trong Hình 1, chúng ta có thể thấy có 6 category 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à tập hợp thành category là rất tự nhiên. Mặt khác, entity là “tập hợp cùng một loại dữ liệu và mang một mục đích nào đó”. Tóm lại, có thể lấy category này làm entity. Như vậy, category (phân loại) hiển thị màn hình dễ dàng trở thành entity.

Tên các entity sẽ là “tên gần với việc biểu hiện sự rõ ràng của mục đích và phải dễ hiểu”. (Bảng 1)

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

Ngoài ra, hạng mục mà có trong category thì trong entity được gọi là “Thuộc tính”. Ví dụ, trong category “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 là biểu hiện tính chất và đặc tính của entity qua thông tin mà được mang trong entity.　Đế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

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ó dư thừa hay thiếu hụt không?

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

Entity có bị thiếu 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.

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 có business 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. Cũng có người tự tin nói là nếu nhìn vào sơ đồ ER thì có thể hiểu được nghiệp vụ nhưng vì sơ đồ ER là biểu đồ dựa theo mối quan hệ "người" và "vật" mà xuất hiện trong business nên tôi nghĩ điều đó là đúng.

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”, hãy xác nhận xem có thể biểu thị 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 thị đượ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.

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)

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ì đang bao gồm nhiều chi tiết đặt hàng. Hoặc có thể nói là entity "Đặt hàng" là entity đối 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".

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 CD 1,470Yên" được biểu thị trong category "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. Nói ngược lại là những thứ mà tập hợp các instance là entity.

Vì lý do này nên "Sản phẩm" mà đang biểu hiện 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 mà bổ sung ăn khớp với biểu hiện là "làm gì" vào sau tên entity (có thể thành động từ), tóm lạ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". Ngoài ra, cái trước được gọi là "hệ transaction", cái sau được gọi là "hệ master".

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ú ý 1: trong "Chi tiết đặt hàng" có vẻ không hợp 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.

Tiếp theo, chúng ta sẽ xác nhận xem có entity không cần thiết hay không.

**Có bao gồm hay không các entity không cần thiết? **

Để 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.

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. Không giới hạn ở shop record online này, 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 tuỳ chọn là "Gửi ngay" và "10 ngày dự trữ" như là instane 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" “Điểm gửi đến” trong đơn vị đặt hàng thì có chỉ trong trường hợp muốn chỉ định vào từng “Điểm gửi đến” thì mới cho khách hàng nhập vào. 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 rule 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ẽ trở thành bao gồm thông tin “Điểm gửi đến” trong entity “Đặt hàng” mà là entity hệ event với tư cách là thuộc tính.

Cách xử lý instance như thế này là rule nghiệp vụ chính xác. Địa chỉ của bản thân khách hàng được khách hàng đăng ký, dù trong trường hợp đã chỉ định “Điểm gửi đến” riêng, nhưng có quản lý nó với tư cách là thông tin liên quan đến “Khách hàng” không, hay có quản lý với tư cách là dữ liệu dùng 1 lần, tùy vào rule nghiệp vụ.

Lần này, chúng ta sẽ xử lý thông tin bao gồm trong entity “Đ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.

Chúng ta phải tham chiếu một cách thích hợp với rule nghiệp vụ, có những thực thể không thể không suy nghĩ đến rule 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 “Ngày làm việc”
• 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 category “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".

Hình 4: entity mà đã được trích xuất (bao gồm các thuộc tính)

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 mà đã có thể trích xuất với nhau trong "các mối quan hệ". Trước tiên, chúng ta cần thiết định "Khóa chính".

Để thiết lập các mối quan hệ, chúng ta cần thiết lập "Khóa chính" cho các entity.

"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 30cmLP, 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ể.

Trải qua tương lai như thế thì 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 goị 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.

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.

Hình 5 là sơ đồ ER mà đã thiết định toàn bộ khóa chính.

Hình 5: các entity mà "khóa chính" được thiết lập

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

Mối quan hệ (relation ship) không phải chỉ bao gồm sự biểu hiện 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ình 6 thiết lập cardinality (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 sơ đồ ER như sau (Hình 7).

Hình 7: sơ đồ ER đã hoàn thành

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.

Tóm tắt

Lần này, chúng ta đã trải nghiệm quá trình tạo mô tả sơ đồ ER, và thu được các kiên thức tối thiểu cần để tạo sơ đồ ER (quá trình lên ý tưởng). 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ó. Sau đó, tự nhiên chúng ta sẽ có suy nghĩ là "Tôi muốn tạo sơ đồ ER nhiều hơn nữa nhưng không có chủ đề nào hay nữa hay sao?". Nếu như thế thì nó sẽ trở thành thứ đã đóng lại. Chắc chắn là tự chúng ta có thể tìm ra nhiều sách vở và thông tin liên quan đến sơ đồ ER.

Lần này, các thuộc tính bên trong entity được quyết định một cách tương đối và đơn giản, mối quan hệ bên trong entity cũng là "1:n". Nhưng trong thực tế, trong quá trình tạo sơ đồ ER, trong entity có pha trộn nhiều thuộc tính trùng lặp, mối quan hệ bên trong entity cũng có "n:n". Để giải quyết vấn đề này, chúng ta cần thực hiện "Tiêu chuẩn hóa". Thực ra entity "Chi tiết sản phẩm" mà chúng ta đã tạo ra trong lần này chính là kết quả của việc thực hiện "Tiêu chuẩn hóa".

Tuy nhiên, trong phạm vi bài viết này, chúng ta sẽ không bàn tới việc "Tiêu chuẩn hóa" mà để dành cho một bài viết khác.