Mô hình dữ liệu khái niệm, logic và vật lý (Conceptual vs logical vs physical data models)
Bởi Sonny Rivera, Chuyên gia Phân tích Cấp cao tại ThoughtSpot
Mô hình dữ liệu khái niệm (conceptual data model) là gì?
Mô hình dữ liệu khái niệm (Conceptual Data Model – CDM) hoạt động ở cấp độ cao, cung cấp một cái nhìn tổng thể về nhu cầu dữ liệu của tổ chức. Nó định nghĩa một góc nhìn rộng và đơn giản hóa về dữ liệu mà doanh nghiệp sử dụng hoặc dự định sử dụng trong các hoạt động hàng ngày. Lập mô hình dữ liệu khái niệm (conceptual data modeling) nhằm tạo ra sự hiểu biết chung về doanh nghiệp bằng cách nắm bắt các khái niệm cốt lõi của một quy trình kinh doanh (business process). Những khái niệm cốt lõi này thường được thể hiện trong Sơ đồ Quan hệ Thực thể (Entity Relationship Diagram – ERD) và các định nghĩa thực thể (entity definitions) đi kèm.
Việc phát triển một mô hình dữ liệu khái niệm (conceptual data model) giúp đội ngũ và các bên liên quan hiểu được những yếu tố cốt lõi và bức tranh tổng thể – loại dữ liệu bạn đang làm việc và cách các thực thể dữ liệu (data entities) khác nhau liên kết với nhau. Ngoài ra, nó tạo ra sự hiểu biết chung về quy trình kinh doanh (business process) và một ngôn ngữ chung cho tất cả các thành viên kỹ thuật và phi kỹ thuật. Trong khi nhiều đội dữ liệu gặp khó khăn trong việc giao tiếp và xây dựng niềm tin với các bên liên quan, CDM có thể giúp thúc đẩy giao tiếp hiệu quả.
Sự hiểu biết chung (Shared understanding)
Mô hình dữ liệu khái niệm (conceptual data models) sử dụng thuật ngữ định hướng kinh doanh đơn giản để mô tả và định nghĩa các đối tượng dữ liệu (data objects) và mối quan hệ giữa chúng, tạo ra một ngôn ngữ chung mà cả các bên liên quan kỹ thuật và phi kỹ thuật đều có thể hiểu. Chúng cũng cung cấp các biểu diễn trực quan (visual representations) dễ hiểu hơn so với tài liệu viết, đặc biệt đối với các mối quan hệ phức tạp. Sự hiểu biết chung về quy trình kinh doanh (business process) này rất quan trọng để xây dựng niềm tin và sự tự tin của các bên liên quan.
Giao tiếp và hợp tác (Communication and collaboration)
Mô hình khái niệm (conceptual models) có thể là điểm tập trung cho các cuộc thảo luận giữa các bên liên quan, đội dữ liệu và các phòng ban khác nhau, thúc đẩy sự hợp tác (collaboration) và niềm tin. Ngoài ra, chúng có thể giúp làm rõ yêu cầu (requirements), xác định khoảng trống (gaps) hoặc sự dư thừa (redundancies), và thúc đẩy sự đồng thuận về các quy tắc và chính sách kinh doanh (business rules and policies). Nói tóm lại, giao tiếp và hợp tác dẫn đến niềm tin, điều mà bạn sẽ cần khi đưa ra các quyết định quan trọng về chi phí (cost), giao hàng (delivery), và chức năng (functionality).
[Hình ảnh: Figure 1 – Example conceptual data model-hotel reservations]
| Định nghĩa (Definitions) | ||
|---|---|---|
| Thực thể (Entity) | Mô tả (Description) | Mối quan hệ (Relationships) |
| Khách sạn (Hotel) | Phải có nhiều phòng (Must have many rooms) Có thể có nhiều khách hàng (May have many customers) | |
Lưu ý: Khách hàng và khách có luôn là một? (customer and the guest always one-and-the-same?)
Mô hình dữ liệu logic (logical data model) là gì?
Mô hình dữ liệu logic (Logical Data Model – LDM) chứa đựng các biểu diễn (representations) định nghĩa đầy đủ các mối quan hệ trong dữ liệu, bổ sung chi tiết và cấu trúc của các thực thể cốt lõi (essential entities). Điều quan trọng cần lưu ý là LDM không phụ thuộc vào nền tảng dữ liệu (data platform agnostic) vì nó tập trung vào nhu cầu kinh doanh (business needs), tính linh hoạt (flexibility), và khả năng di động (portability).
LDM bao gồm các thuộc tính cụ thể (specific attributes) của mỗi thực thể, các mối quan hệ giữa các thực thể (relationships between entities), và số lượng mối quan hệ (cardinality of those relationships). Nó cung cấp cho đội ngũ của bạn một khung công tác (framework) vững chắc để tuân theo khi xây dựng hệ thống, và có thể được sử dụng để lập kế hoạch và triển khai hiệu quả các kho dữ liệu đám mây (cloud data warehouses), kho dữ liệu nhỏ (data marts), cơ sở dữ liệu ứng dụng (application databases), hoặc tập dữ liệu phân tích dữ liệu (data analysis datasets).
Trong mô hình dữ liệu khái niệm (conceptual data model), các thực thể và mối quan hệ đã được định nghĩa. Bước tiếp theo là sử dụng các thực hành tốt nhất trong lập mô hình dữ liệu (data modeling best practices) để chuyển từ mô hình dữ liệu khái niệm sang mô hình dữ liệu logic (logical data model); thông thường cần thực hiện các bước sau:
- Định nghĩa các mối quan hệ thực thể (entity relationships) và đảm bảo rằng các mối quan hệ này chính xác bằng cách xác nhận với các bên liên quan. Mẹo chuyên nghiệp: Các thực thể thường chỉ liên quan đến một vài thực thể khác, vì vậy nhiều mối quan hệ có thể cho thấy vấn đề thiết kế (design issue). Ví dụ, trong Hình 3, thực thể Khách sạn (Hotel) được kết nối với thực thể Phòng (Room) thông qua mối quan hệ “Có” (Has).
- Định nghĩa số lượng mối quan hệ (cardinality of relationships) bằng cách xác định số lượng phiên bản của một thực thể liên quan đến các phiên bản trong thực thể liên quan. Các số lượng phổ biến nhất là một-một (one-to-one), một-nhiều (one-to-many), và nhiều-nhiều (many-to-many). Số lượng cũng có thể là tùy chọn (optional). Ví dụ, trong Hình 3, bạn có thể thấy mối quan hệ một-nhiều (one-to-many) giữa thực thể Khách sạn (Hotel) và Phòng (Room). Điều này thường được đọc là “một Khách sạn có nhiều Phòng.”
- Xác nhận mô hình (validate the model) bằng cách kiểm tra mô hình dữ liệu logic (logical data model) với các yêu cầu kinh doanh (business requirements). Điều này bao gồm kiểm tra với các bên liên quan, người dùng cuối (end-users), và các nhà phát triển (developers) để đảm bảo mô hình thể hiện chính xác dữ liệu cần thiết và các mối quan hệ của nó.
- Lặp lại và tinh chỉnh (iterate and refine) để đạt giá trị kinh doanh tối ưu. Lập mô hình (modeling) thường là một quá trình lặp lại, vì vậy bạn có thể cần tinh chỉnh hoặc cập nhật mô hình dữ liệu logic (logical data model) dựa trên phản hồi (feedback).
[Hình ảnh: Figure 3 – Logical Data Model]
Đảm bảo chất lượng (Quality assurance)
Bằng cách xác định lỗi hoặc sự không nhất quán (errors or inconsistencies) trong giai đoạn đầu của phát triển hệ thống (system development), mô hình dữ liệu logic (logical data models) góp phần nâng cao chất lượng dữ liệu (data quality), độ tin cậy (reliability), và giảm chi phí (lower cost). LDM cũng xác nhận các yêu cầu kinh doanh (business requirements) bằng cách điều chỉnh cấu trúc dữ liệu (data structure) với nhu cầu kinh doanh (business needs).
Tất nhiên, các lợi ích khác có thể áp dụng cho tổ chức của bạn, nhưng hãy nhớ rằng lập mô hình dữ liệu logic (logical data modeling) rất quan trọng để hiểu dữ liệu tốt hơn từ góc độ kinh doanh (business perspective), cải thiện giao tiếp giữa các bên liên quan (communication among stakeholders), và tạo nền tảng vững chắc cho thiết kế cơ sở dữ liệu vật lý (physical database design).
Mô hình dữ liệu vật lý (physical data model) là gì?
Mô hình dữ liệu vật lý (Physical Data Model – PDM) là một mô hình dữ liệu (data model) đại diện cho các đối tượng dữ liệu quan hệ (relational data objects). Nó mô tả việc triển khai cụ thể theo công nghệ (technology-specific) và cơ sở dữ liệu (database-specific) của mô hình dữ liệu và là bước cuối cùng trong việc chuyển đổi từ mô hình dữ liệu logic (logical data model) sang cơ sở dữ liệu hoạt động (working database). Một mô hình dữ liệu vật lý (physical data model) bao gồm tất cả các chi tiết vật lý cần thiết để xây dựng một cơ sở dữ liệu (database).
[Hình ảnh: Physical Data Model]
Để tạo một mô hình dữ liệu vật lý (physical data model), bạn thường cần thực hiện các bước sau:
- Định nghĩa các mối quan hệ giữa bảng cha và bảng con (parent and child tables). Điều này được thực hiện bằng cách tạo một thuộc tính khóa ngoại (foreign key – FK) trong bảng con tham chiếu đến thuộc tính khóa chính (primary key – PK) của bảng cha.
- Xác minh các bảng ở dạng chuẩn 3NF (3rd Normal Form) để đảm bảo loại bỏ sự dư thừa dữ liệu (data redundancy) và đảm bảo tính toàn vẹn dữ liệu (data integrity). Điều này có thể liên quan đến việc tách hoặc gộp các bảng theo nguyên tắc chuẩn hóa 3NF (3NF normalization principles) và khả năng cụ thể của nền tảng dữ liệu (data platform). Trong Hình 4, một bảng có tên Khách sạn_Khách hàng (Hotel_Customer) đã được thêm vào để xử lý mối quan hệ nhiều-nhiều (many-to-many) giữa Khách sạn (Hotel) và Khách hàng (Customer).
- Định nghĩa các chỉ mục (indexes) và phân vùng (partitions) bằng cách xác định các thuộc tính được sử dụng phổ biến nhất để sắp xếp (sorting), lọc (filtering), và nối bảng (join tables). Việc tối ưu hóa chỉ mục và phân vùng thay đổi rất nhiều tùy theo nền tảng dữ liệu (data platform) và trường hợp sử dụng (use case), vì vậy đây thường là một quá trình lặp lại. Tốt nhất là áp dụng nguyên tắc KISS (giữ mọi thứ đơn giản – keep it simple smarty) khi bắt đầu tối ưu hóa chỉ mục và phân vùng.
- Triển khai các ràng buộc bảng (table constraints) bằng cách định nghĩa các khóa chính (primary keys), khóa duy nhất (unique keys), kiểm tra giá trị rỗng/không rỗng (null/not-null checks), và các ràng buộc logic khác trên bảng. Các ràng buộc logic (logical constraints) được xác định trong LDM cũng nên được thể hiện trong thiết kế dữ liệu vật lý (physical data design) ngay cả khi nền tảng dữ liệu không áp dụng các ràng buộc đó. Mẹo chuyên nghiệp: Các nền tảng dữ liệu đám mây hiện đại (modern cloud data platforms) thường không áp dụng tất cả các ràng buộc dù chúng có thể được định nghĩa. Mặc dù các ràng buộc có thể không được áp dụng, chúng vẫn có giá trị vì được sử dụng bởi các ứng dụng và công cụ phân tích (analytics tools) để đảm bảo tính toàn vẹn dữ liệu (data integrity), tạo phân tích dữ liệu phức tạp (complex data analysis), và cải thiện hiệu suất (performance).
- Triển khai các khía cạnh lập trình (programmability aspects) của mô hình dữ liệu bằng cách tạo các chế độ xem (views), thủ tục lưu trữ (stored procedures), trình kích hoạt (triggers), luồng dữ liệu (streams), và tác vụ (tasks). Tùy thuộc vào độ phức tạp của nền tảng dữ liệu (data platform), bạn có thể cần triển khai các chế độ xem (views – bảng ảo dựa trên truy vấn), thủ tục lưu trữ (stored procedures – nhóm câu lệnh phân tích SQL được biên dịch trước), trình kích hoạt (triggers – hành động tự động phản hồi các sự kiện), luồng dữ liệu (Streams – nhập dữ liệu gần thời gian thực), và tác vụ (Tasks – đường ống dữ liệu tự động).
- Xác nhận mô hình và tiêu chuẩn (model validation and standards) nên được xác nhận với các bên liên quan để đảm bảo rằng PDM đáp ứng các yêu cầu kinh doanh (business requirements) được định nghĩa trong mô hình logic (logical model).
[Hình ảnh: Figure 4 – Physical Data Model]
Hiệu quả triển khai (Implementation efficiency)
Mô hình dữ liệu vật lý (physical data models) cung cấp một kế hoạch chi tiết (blueprint) để triển khai cơ sở dữ liệu (database implementation), giúp các quản trị viên cơ sở dữ liệu (database administrators) và kỹ sư phần mềm (software engineers) thiết kế cơ sở dữ liệu vật lý (physical database) một cách hiệu quả và hiệu quả. Điều này cuối cùng giúp tiết kiệm thời gian, tiền bạc và tài nguyên (saves time, money, and resources).
Khả năng mở rộng và chuẩn bị cho tương lai (Scalability and future-proofing)
Một mô hình dữ liệu vật lý (physical data model) được thiết kế tốt giúp quản lý các thay đổi không thể tránh khỏi khi doanh nghiệp của bạn phát triển và tiến hóa dễ dàng hơn nhiều. PDM cung cấp một kế hoạch chi tiết (blueprint) và khung công tác có khả năng mở rộng (scalable framework) có thể đáp ứng các nguồn dữ liệu mới (new data sources), quy tắc kinh doanh (business rules), hoặc tích hợp hệ thống (system integrations), dẫn đến giảm độ phức tạp hệ thống (system complexity), giảm rủi ro lỗi thời (obsolescence risk), và tăng tốc độ ra thị trường (market speed).
So sánh mô hình dữ liệu khái niệm, logic và vật lý (Comparison of conceptual, logical, and physical data models)
Bảng 1 tóm tắt các mô hình dữ liệu khái niệm (conceptual data models), logic (logical data models), và vật lý (physical data models) được mô tả ở trên.
| Mô tả (Description) | Mô hình dữ liệu khái niệm (Conceptual Data Model) | Mô hình dữ liệu logic (Logical Data Model) | Mô hình dữ liệu vật lý (Physical Data Model) |
|---|---|---|---|
| Mô hình cấp cao hiển thị dữ liệu sẽ được lưu trữ và các mối quan hệ giữa các dữ liệu đó (A high-level model that shows what data is to be stored and the relationships among those data) | Mô hình chi tiết hơn hiển thị cách hệ thống sẽ được triển khai bởi nền tảng dữ liệu (A more detailed model shows how the system will be implemented by a of the data platform) | Mô hình dữ liệu cấp thấp mô tả cách dữ liệu sẽ được lưu trữ và truy cập trong phương tiện lưu trữ vật lý (A low-level data model that describes how data will be stored and accessed in the physical storage medium) | |
| Mục đích (Purpose) | Cung cấp cái nhìn tổng thể về dữ liệu cần có trong hệ thống (To provide a big-picture view of what data should be present in the system) | Cung cấp cấu trúc logic của dữ liệu cần thiết cho tổ chức (To provide a logical structure of the data needed by the organization) | Cung cấp cái nhìn chi tiết về cách dữ liệu sẽ được thiết kế vật lý để tối ưu hiệu suất và chi phí (To give a detailed view of how the data will be physically designed for optimal performance and costs) |
| Trọng tâm (Focus) | Yêu cầu dữ liệu cho quy trình kinh doanh (Data requirements for the business process) Tạo sự hiểu biết chung giữa các nhóm (Creating a shared understanding between teams) | Sắp xếp cấu trúc dữ liệu để đáp ứng nhu cầu kinh doanh (Organizing the data structure to meet the business needs) Giao tiếp và hợp tác (Communication and collaboration) Đảm bảo chất lượng (Quality assurance) | Thiết kế dữ liệu vật lý (Physical data design) Khả năng mở rộng (Scalability) Tối ưu chi phí (Cost optimization) Chuẩn bị cho tương lai và khả năng tương thích (Future-proofing and interoperability) Độ bền (Resilience) |
| Đối tượng/người dùng mục tiêu (Intended audience/roles) | Các bên liên quan kinh doanh (Business stakeholders), Kỹ sư phân tích (Analytics engineers) và Kiến trúc sư dữ liệu (data architects) | Kỹ sư phân tích (Analytics engineers), Kiến trúc sư dữ liệu (data architects), Nhà phân tích (analysts), và Nhà thiết kế (designers) | Quản trị viên cơ sở dữ liệu (DBAs), Nhà phát triển (developers), và Kỹ sư hệ thống (system engineers) |
Kết luận
Khi lập mô hình dữ liệu (data modeling), việc hiểu rõ các mô hình dữ liệu khái niệm (conceptual data models), logic (logical data models), và vật lý (physical data models) là rất quan trọng để xây dựng các tài sản dữ liệu (data assets) hiệu quả, có thể mở rộng (scalable), và đáng tin cậy (reliable). Mặc dù một số người có thể chọn bỏ qua lập mô hình dữ liệu (data modeling) vì cho rằng làm việc với dữ liệu trong lưới hoặc Excel đơn giản và tương tự hơn, họ đã bỏ lỡ cơ hội tối đa hóa lợi tức đầu tư (ROI) của mình.
Lập mô hình dữ liệu (data modeling) nên được thực hiện theo cách nhanh nhẹn (agile) và được phát hành theo từng giai đoạn (incremental releases), giúp giảm thời gian đưa ra thị trường (time to market) và chi phí (costs). Đây là một khoản đầu tư kinh doanh giá trị (business investment) đảm bảo thành công hiện tại và tương lai của tổ chức bạn. Trong lĩnh vực dữ liệu, câu nói cổ “trả tôi bây giờ, hoặc trả tôi sau” thực sự là “trả tôi bây giờ, hoặc trả tôi gấp 10 lần sau.”
Trong dự án dữ liệu tiếp theo của bạn, hãy tự hỏi bản thân một vài câu hỏi:
- Tôi đang xây dựng tài sản dữ liệu tiếp theo (data asset) hay chỉ là nợ kỹ thuật tiếp theo (tech debt)?
- Các bên liên quan và tôi có sự hiểu biết chung về quy trình kinh doanh (business process) và mô hình (model) không?
- Mô hình của chúng tôi có hỗ trợ phân tích tự phục vụ (self-service analytics) để tạo ra giá trị lớn hơn không?
- Chất lượng dữ liệu (data quality) được cải thiện có nâng cao niềm tin và sự tự tin vào tôi hoặc đội ngũ của tôi không?
- Chúng tôi có thể giảm độ phức tạp (complexity) và chuẩn bị cho tương lai (future-proof) tài sản dữ liệu (data assets) của mình không?
Vì vậy, hãy bắt đầu và xây dựng một sản phẩm dữ liệu (data product) đẳng cấp thế giới để tạo ra giá trị kinh doanh (business value) và làm hài lòng các bên liên quan của bạn!
Trải nghiệm cách ThoughtSpot có thể biến mô hình dữ liệu (data models) của bạn thành phân tích thân thiện với người dùng, được hỗ trợ bởi AI (AI-powered analytics). Bắt đầu dùng thử miễn phí 14 ngày của bạn ngay hôm nay và chứng kiến sự thay đổi cho chính bạn.
Liên hệ BSD 0918 339 689 để tìm hiểu thêm về mô hình dữ liệu. Tìm hiểu về phương pháp tiếp cận và triển khai nền tảng dữ liệu và phân tích dữ liệu vào cho môi trường của doanh nghiệp bạn
