 |
| Data modeling process workflow |
Mô hình hóa dữ liệu là một quá trình lên kế hoạch một cấu trúc để biểu diễn cách thông tin và mối quan hệ giữa các thông tin sẽ được lưu trữ trong hệ thống của bạn.
Bài viết này sẽ giới thiệu ngắn gọn về mô hình hóa dữ liệu, cũng như ba loại mô hình dữ liệu tiến bộ: conceptual data modeling (mô hình dữ liệu khái niệm), logical data modeling (mô hình dữ liệu logic), and physical data modeling (mô hình dữ liệu vật lý). Những mô hình dữ liệu này đạt được điều gì? Ai nên tham gia vào việc tạo ra chúng? Chúng được tạo ra như thế nào?
Mô hình dữ liệu là gì?
Mô hình dữ liệu là một quá trình giúp bạn hiểu được các cấu trúc, hình thức, và các mối quan hệ của thông tin. Giống như bất kỳ mô hình nào, nó là phiên bản đơn giản hóa và không hoàn hảo của thực tế. Nhưng với công việc cẩn thận và xem xét, một mô hình dữ liệu được thiết kế tốt sẽ có khả năng phản ứng với sự thay đổi và xử lý các yêu cầu trong tương lai.
Tại Sao Mô Hình Dữ Liệu Quan Trọng?
Việc tạo ra một mô hình dữ liệu là một bước quan trọng trong phát triển ứng dụng. Mô hình dữ liệu sẽ buộc đội ngũ của bạn phải đưa ra quyết định về dữ liệu nào là cần thiết và cách thu thập cũng như cấu trúc nó.
Thực tế, bạn có thể nghĩ về một mô hình dữ liệu như một “tập hợp quyết định”, khẳng định và giả định. Ngay cả khi một cái gì đó được mô hình hóa không chính xác, những giả định đó vẫn được ghi lại, và giúp đội ngũ trong tương lai hiểu lý do tại sao nó được mô hình hóa như vậy. Với nền tảng thông tin này, đội ngũ trong tương lai có thể xem xét cẩn thận hơn liệu việc thay đổi có phải là phương án hành động đúng hay không.
Conceptual vs Logical vs Physical Data Modeling
Có ba cấp độ mô hình dữ liệu truyền thống. Không phải đội ngũ nào cũng sẽ nhất thiết tuân theo cả ba một cách nghiêm ngặt. Thường thì cả ba – mô hình dữ liệu khái niệm, logic và vật lý – được nén lại thành một bài tập mô hình hóa.
Tuy nhiên, việc phân chia quy trình thành ba cấp độ này có thể rất giá trị. Mỗi bước thiết lập nền tảng cho bước tiếp theo:
- Conceptual – the “what” model
- Logical – the “how” of the details
- Physical – the “how” of the implementation
Mỗi cấp độ của mô hình dữ liệu khái niệm, vật lý và logic có thể liên quan đến các vai trò khác nhau từ đội ngũ của bạn.
Conceptual Data Model
Mô hình dữ liệu khái niệm có thể được coi là mô hình dữ liệu “bảng trắng”. Mô hình này không đi vào chi tiết “how” một chút nào.
Đối với mô hình này, điều quan trọng là tập trung vào việc ghi lại tất cả các loại dữ liệu (hay “thực thể”) mà hệ thống sẽ cần. Ngoài các thực thể, một mô hình dữ liệu khái niệm cũng sẽ ghi lại:
- Thuộc tính: các thuộc tính riêng lẻ của một thực thể. Ví dụ, một thực thể “người” có thể có “tên” và “kích thước giày”. Một thực thể “địa chỉ” có thể có “mã bưu chính” và “thành phố”.
- Mối quan hệ: cách một thực thể kết nối với các thực thể khác. Ví dụ, một thực thể “người” có thể có một hoặc nhiều “địa chỉ”.
Cùng với các thực thể, thuộc tính và mối quan hệ của chúng, một mô hình khái niệm cũng có thể:
- Tổ chức phạm vi: các thực thể nào được bao gồm, nhưng cũng là những thực thể nào không được bao gồm một cách rõ ràng.
- Định nghĩa khái niệm / quy tắc kinh doanh: Ví dụ, các thực thể người có được phép có nhiều địa chỉ không? Còn nhiều email thì sao? Họ có cần phải có một định danh duy nhất không?
Mô hình dữ liệu khái niệm thường được tạo ra bởi các kiến trúc sư cùng với các bên liên quan trong kinh doanh và các chuyên gia lĩnh vực.
Conceptual Data Model Example
Có nhiều “ngôn ngữ” để mô tả một mô hình dữ liệu khái niệm. Nhưng miễn là nó được tài liệu hóa theo cách dễ tiếp cận, nó có thể đơn giản như các hộp và mũi tên.
Dưới đây là một ví dụ về một sơ đồ khái niệm liên quan đến hai thực thể cốt lõi: lộ trình du lịch (và các lịch trình liên quan của nó) và hãng hàng không:
Mặc dù những điều này có thể trông giống như các bảng trong một cơ sở dữ liệu quan hệ, giai đoạn mô hình hóa khái niệm quá sớm để đưa ra quyết định về cách dữ liệu sẽ được lưu trữ. Quyết định đó đến sau: nó có thể là các bảng, tài liệu JSON, nút đồ thị, tệp CSV, blockchain, hoặc bất kỳ số lượng phương tiện lưu trữ nào khác.
Logical Data Model
Mô hình dữ liệu logic là bước tiếp theo, khi các bên liên quan đã đồng ý về một mô hình khái niệm.
Bước này liên quan đến việc điền vào các chi tiết của mô hình khái niệm. Vẫn còn quá sớm để chọn một hệ quản trị cơ sở dữ liệu cụ thể, nhưng bước này có thể giúp bạn quyết định loại cơ sở dữ liệu nào để sử dụng (quan hệ, tài liệu, v.v.). Ví dụ, nếu bạn quyết định sử dụng mô hình quan hệ, thì đã đến lúc quyết định những bảng nào sẽ tạo ra. Nếu bạn quyết định sử dụng tài liệu, thì đã đến lúc định nghĩa các bộ sưu tập.
Hãy quyết định các chi tiết của từng trường/cột và mối quan hệ cá nhân. Điều này bao gồm các loại dữ liệu, kích thước, chiều dài, mảng, đối tượng lồng nhau, v.v.
Mô hình logic thường được tạo ra bởi các kiến trúc sư và nhà phân tích kinh doanh.
Logical Data Model Example
Ví dụ, nếu chọn mô hình quan hệ, mô hình logic có thể trông như thế này:
Tuy nhiên, với một cơ sở dữ liệu tài liệu, lịch trình có thể được mô hình hóa như một phần của lộ trình, trực tiếp. Không cần khóa ngoại, nhưng vẫn hữu ích để nghĩ về nó như một thực thể con riêng biệt. Vì vậy, mô hình logic đó có thể trông như thế này:
Trong trường hợp của một lịch trình, có kích thước nhỏ và hữu hạn, việc nhúng vào cùng một bộ sưu tập là hợp lý. Trong trường hợp, ví dụ, một người dùng đăng bài trên mạng xã hội, điều này không giới hạn, nên việc mô hình hóa trong các bộ sưu tập riêng biệt là hợp lý.
Physical Data Model
hi một mô hình logic đã được xác định, đã đến lúc thực sự triển khai nó vào một cơ sở dữ liệu thực.
Nếu bạn quyết định sử dụng mô hình quan hệ, các tùy chọn bao gồm SQL Server, Oracle, PostgreSQL, MySQL, v.v. Tuy nhiên, nếu quy trình mô hình hóa của bạn cho thấy mô hình dữ liệu của bạn có khả năng thay đổi thường xuyên để thích ứng với các yêu cầu mới, bạn vẫn có thể xem xét việc sử dụng cơ sở dữ liệu tài liệu. Một trong những lựa chọn tốt nhất cho điều này là Couchbase, một cơ sở dữ liệu tài liệu “NoSQL” hỗ trợ các khái niệm quan hệ quen thuộc như JOIN, giao dịch ACID và dữ liệu JSON linh hoạt.
Mô hình dữ liệu vật lý nên bao gồm:
- Một hệ quản trị cơ sở dữ liệu cụ thể (Couchbase, chẳng hạn)
- Cách dữ liệu được lưu trữ (Trên đĩa/RAM/hybrid/v.v. Couchbase có bộ nhớ đệm tích hợp để cung cấp tốc độ của RAM với độ bền của đĩa)
- Cách để giải quyết các bản sao, phân đoạn, phân vùng, v.v. (Đối với Couchbase, việc phân đoạn và phân vùng là tự động. Việc sao chép là một hộp thả xuống để chọn số lượng bản sao bạn muốn).
Mô hình dữ liệu vật lý thường được tạo ra bởi các DBA và/hoặc nhà phát triển.
Physical Data Model Example
Dưới đây là một ví dụ về mô hình vật lý cho Couchbase:
 |
Đôi khi việc hiển thị dữ liệu mẫu cùng với mô hình vật lý sẽ rất hữu ích.
Sự khác biệt giữa các mô hình dữ liệu: Conceptual, Logical, and Physical
Mỗi mô hình là một bước cần thiết trong hành trình xây dựng một mô hình dữ liệu hữu ích cho ứng dụng của bạn. Mô hình dữ liệu khái niệm là cấp độ cao nhất, vì vậy nó ít chi tiết nhất. Mô hình dữ liệu logic yêu cầu tư duy chi tiết hơn về việc triển khai mà không thực sự thực hiện bất cứ điều gì. Cuối cùng, mô hình dữ liệu vật lý dựa trên các yêu cầu từ mô hình dữ liệu logic để tạo ra một cơ sở dữ liệu thực tế.
Ưu điểm của việc lập mô hình dữ liệu
Các lợi ích của việc trải qua quy trình lập mô hình dữ liệu đều liên quan đến giao tiếp:
- Giao tiếp ngắn hạn giữa các bên liên quan để đưa ra quyết định về những gì quan trọng, quy tắc kinh doanh là gì và cách thực hiện chúng.
- Giao tiếp dài hạn thông qua các thông số kỹ thuật cơ sở dữ liệu có thể được sử dụng để kết nối dữ liệu của bạn với các dịch vụ khác thông qua ETL (Couchbase có thể giúp bạn giảm số lượng ETL, vì có nhiều dịch vụ tích hợp sẵn để giúp giải quyết các trường hợp sử dụng ngày càng mở rộng của bạn – truy vấn, tìm kiếm văn bản, bộ nhớ đệm, phân tích, sự kiện, đồng bộ di động).
- Giao tiếp để giúp đội ngũ của bạn dễ dàng xác định dữ liệu bị hỏng hoặc không chính xác hơn.
Nhược điểm của việc lập mô hình dữ liệu
Có chi phí liên quan đến việc mô hình hóa dữ liệu.
- Đó có thể là một quá trình tiềm ẩn kéo dài. Nó cũng có thể dễ bị ảnh hưởng bởi tư duy theo mô hình thác nước (ví dụ: một lỗi phát hiện trong quá trình mô hình hóa dữ liệu logic có thể kích hoạt việc làm lại hoàn toàn quá trình mô hình hóa khái niệm).
- Một mô hình quan hệ vật lý có thể cứng nhắc và khó thay đổi một khi mô hình dữ liệu vật lý đã được tạo ra (đặc biệt là trong môi trường sản xuất).
- Mô hình tài liệu vật lý dễ thay đổi bất cứ lúc nào, nhưng phụ thuộc vào lớp ứng dụng để thực thi các ràng buộc và kiểu dữ liệu.
Nếu bạn bắt đầu quá trình mô hình hóa logic với một cơ sở dữ liệu tài liệu trong tâm trí, bạn có thể tránh được thời gian chu kỳ và thu được lợi ích linh hoạt. (Trừ khi bạn biết rằng mô hình dữ liệu và yêu cầu của bạn không thay đổi nhiều, ví dụ: một lần mỗi năm).
