Mô hình dữ liệu là gì? Là nhà phát triển Talend, chúng tôi thấy họ mỗi ngày và chúng tôi nghĩ rằng chúng tôi biết họ là gì:
- Một định nghĩa cấu trúc của dữ liệu hệ thống kinh doanh.
- Một đại diện đồ họa của dữ liệu kinh doanh.
- Một nền tảng dữ liệu để xây dựng các giải pháp kinh doanh.
Đây có thể là tất cả các tuyên bố đúng nhưng tôi muốn đề xuất rằng chúng đều là các định nghĩa không liên quan vì riêng biệt, chúng không đạt được gốc, mục đích hoặc mục tiêu của mô hình dữ liệu thực sự là gì.
OK sau đó, những gì là một mô hình dữ liệu? Tôi nghĩ đó là nhiều thứ, và một điều cụ thể. Đối với tôi, một mô hình dữ liệu là một nền tảng cấu trúc được thể hiện dưới dạng một đặc tính đồ họa được xác định rõ ràng của một hệ thống thông tin kinh doanh.
Bạn nghĩ sao? Điều đó giống như các định nghĩa ở trên, phải không? Không hẳn vậy. Định nghĩa này bao gồm tất cả các yếu tố vào một mục đích duy nhất: một phương tiện để xác định, về mặt cấu trúc, thông tin về trường hợp sử dụng kinh doanh, không chỉ là dữ liệu của nó.
>> Đọc thêm:
KHÓA HỌC DATA WAREHOUSE : TỔNG HỢP, CHUẨN HÓA VÀ XÂY DỰNG KHO DỮ LIỆU TRONG DOANH NGHIỆP
KHÓA HỌC DATA MODEL – THIẾT KẾ MÔ HÌNH DỮ LIỆU TRONG DOANH NGHIỆP
LỘ TRÌNH TRỞ THÀNH DATA ENGINEER CHO NGƯỜI MỚI BẮT ĐẦU
DATA ENGINEER LÀ GÌ? CÔNG VIỆC CHÍNH CỦA DE? CÁC KỸ NĂNG CẦN THIẾT
Trong Phần 1 của loạt bài viết này, tôi đã cô đọng một lịch sử 50 năm của mô hình hóa dữ liệu thành khoảng bốn đoạn ngắn. Chắc chắn, tôi đã bỏ qua một vài bit, nhưng tôi tin rằng việc hiểu làm thế nào chúng ta đạt được những gì chúng ta biết về mô hình hóa dữ liệu là kết quả của bài học kinh nghiệm và cải thiện đạt được từ những người đi trước. Ngày nay, hầu hết các công ty sử dụng các mô hình dữ liệu để giúp xác thực các yêu cầu – một giá trị kinh doanh thực sự – nhưng tôi thường tự hỏi liệu họ có hiểu làm thế nào để làm điều đó đúng không. Trong nhiều trường hợp, ảo tưởng về một mô hình dữ liệu bền được cho là bởi thực tế là có một, mà không biết hoặc xác nhận chắc chắn nếu nó đúng.
Là một người thực hành kiến trúc dữ liệu và thiết kế cơ sở dữ liệu, tôi đã thấy rất nhiều mô hình dữ liệu xấu mà tôi buộc phải đề xuất rằng hầu hết các mô hình dữ liệu có thể sai ở một mức độ nào đó. Tôi đã thấy nhiều cái tốt, nhưng làm thế nào để bạn biết nếu một mô hình dữ liệu là tốt hay xấu? Tại sao chúng ta nên quan tâm? Chừng nào dữ liệu vào và ra khỏi nó, điều đó có đủ tốt không? Câu trả lời là không! Đối với các mô hình dữ liệu phải tốt, hoặc tuyệt vời, chúng phải đảm bảo sự thành công của các hệ thống kinh doanh chống lại và / hoặc hợp tác với chúng. Mô hình dữ liệu là bản chất của doanh nghiệp và do đó phải toàn diện, không thể tin được và có khả năng phục hồi.
Động lực của việc có một mô hình dữ liệu tốt là do đó rõ ràng. Khi bạn bắt đầu đưa dữ liệu vào và lấy dữ liệu ra bằng các công cụ ETL / ELT như Talend Studio , điều này sẽ trở nên rõ ràng (với hầu hết chúng ta). Tôi nghĩ rằng một mô hình dữ liệu là một trong ba yếu tố kỹ thuật thiết yếu của bất kỳ dự án phần mềm nào. Hai cái còn lại là mã ứng dụng và giao diện người dùng.
Bạn cũng đọc trong Phần 1 về phương pháp Vòng đời phát triển cơ sở dữ liệu (DDLC), mà mọi mô hình dữ liệu tôi thiết kế tuân theo. Phương pháp này đã phục vụ tốt cho tôi và tôi đánh giá cao nó cho bất kỳ nhóm phát triển cơ sở dữ liệu nghiêm túc nào. Hiểu và áp dụng quy trình này có thể hợp lý hóa, tự động hóa và cải thiện bất kỳ triển khai và bảo trì mô hình dữ liệu nào. Tuy nhiên, có nhiều hơn cho quá trình này mà chúng ta cần khám phá. Hãy để tôi chia sẻ một số thực tiễn tốt nhất bổ sung có thể thúc đẩy mô hình dữ liệu chính xác, đáng tin cậy và chính xác cho doanh nghiệp của bạn.
Mô hình hóa dữ liệu Thực tiễn tốt nhất
Nhiều mô hình dữ liệu được thiết kế bằng cách sử dụng một quá trình trong đó trình tạo mô hình tạo ra một logic và sau đó là một mô hình vật lý . Thông thường, các mô hình logic mô tả các thực thể và thuộc tính và các mối quan hệ ràng buộc chúng cung cấp một biểu diễn rõ ràng về mục đích kinh doanh của dữ liệu. Các mô hình vật lý sau đó triển khai mô hình logic dưới dạng bảng, cột, kiểu dữ liệu và chỉ mục cùng với các quy tắc toàn vẹn dữ liệu ngắn gọn. Các quy tắc này xác định khóa chính và khóa ngoài và giá trị mặc định. Ngoài ra, các khung nhìn, kích hoạt và các thủ tục được lưu trữ có thể được xác định để hỗ trợ thực hiện theo yêu cầu. Mô hình vật lý cũng xác định phân bổ lưu trữ trên đĩa dựa trên các tùy chọn cấu hình cụ thể được cung cấp bởi hầu hết các hệ thống máy chủ (như Oracle, MS SQL Server, MySQL, v.v.).
Đủ công bằng, phải không? Tuy nhiên, nhiều lần tôi đã tham gia vào cuộc tranh luận sôi nổi về sự khác biệt giữa mô hình Logic và mô hình khái niệm. Nhiều người đề nghị với tôi rằng chúng giống nhau, cả hai đều thể hiện các thực thể và thuộc tính của dữ liệu kinh doanh. Tôi không thể không đồng ý nhiều hơn! Các khái niệm mô hình nhằm cung cấp bối cảnh như sự hiểu biết về kinh doanh của dữ liệu, không phải là một kỹ thuật. Tất cả các bên liên quan có thể hiểu một mô hình khái niệm và nhiều cuộc đấu tranh với các Thực thể và Thuộc tính. Tôi tin rằng mô hình khái niệm, được thực hiện đúng, là công cụ tốt nhất để truyền thông về dữ liệu kinh doanh cho mọi người tham gia. Tôi thích sử dụng các khía cạnh của ngôn ngữ mô hình thống nhất (UML) như cách của tôi để lập sơ đồ một mô hình khái niệm và để giữ cho nó đơn giản, không bị sa lầy với các chi tiết. Tôi sẽ để lại cho các mô hình logic và vật lý trong đó các chi tiết đó là thiết yếu và tinh tế.
Các doanh nghiệp doanh nghiệp, thường có số lượng lớn các hệ thống ứng dụng, đưa ra mức độ quan tâm cao hơn khi mô hình hóa dữ liệu. Tôi đã thấy rằng ngay cả các mô hình khái niệm, logic và vật lý đơn giản là không đủ. Vì vậy, tôi giới thiệu với bạn: mô hình dữ liệu tổng thể (hoặc ít nhất là sự thích ứng của tôi với nó!).
Mục đích của mô hình dữ liệu tổng thể là xác định và trừu tượng các silo dữ liệu trong một doanh nghiệp kinh doanh, từ đó mô tả những gì tồn tại hoặc cần thiết, nơi chúng liên quan với nhau và cách tổ chức chúng để sử dụng hiệu quả nhất ở mức cao nhất.
Bốn lớp quy trình mô hình hóa dữ liệu
Với tiềm năng cho bốn loại mô hình dữ liệu khác nhau trong một doanh nghiệp, tôi đề xuất quy trình mô hình hóa dữ liệu sau sẽ được thực hiện theo các lớp, từ trên xuống, để định nghĩa, sàng lọc hiểu biết và các tính năng thiết kế cụ thể. Vai trò chính trong mỗi cấp độ xác định ai và nơi họ tham gia vào quá trình.
Mô hình dữ liệu toàn diện
Lớp tổng thể thể hiện một cảnh quan trừu tượng của các silo dữ liệu trên toàn doanh nghiệp. Mô hình dữ liệu này tạo cơ hội để thiết lập quản trị dữ liệu kinh doanh rộng rãi, do đó cho phép hiểu rõ hơn về tất cả các mối quan hệ dữ liệu vốn có của doanh nghiệp. Chúng được dự định để kết hợp dữ liệu từ bất kỳ ứng dụng, nội bộ hoặc bên ngoài. Tôi sử dụng biểu đồ bong bóng để lập sơ đồ mô hình dữ liệu tổng thể. Đây là cách tôi làm điều đó.
Biểu đồ bong bóng: Silo dữ liệu
Biểu đồ bong bóng là một thành phần của các bong bóng đơn giản đại diện cho các silo dữ liệu độc đáo. Các dòng (được gọi là liên kết) kết nối hai bong bóng (và chỉ hai) chỉ ra rằng một số mối quan hệ tồn tại giữa chúng. Về cơ bản, mỗi bộ sưu tập bong bóng (thường được thiết kế với một “trung tâm” có “nan hoa” tỏa ra), thể hiện một tập hợp các silo dữ liệu cụ thể được xác định trong toàn doanh nghiệp; không hơn không kém. Dưới đây là một số chi tiết đặc điểm kỹ thuật:
Các liên kết màu xanh đặc cho thấy mối quan hệ trực tiếp giữa hai silo dữ liệu. Các liên kết màu đỏ nét đứt cho thấy mối quan hệ gián tiếp giữa hai silo dữ liệu. Các liên kết màu xanh chấm chấm biểu thị mối quan hệ mở rộng giữa hai silo dữ liệu. Sử dụng các liên kết này một cách chủ quan, vì chúng có thể đại diện cho nhiều mối quan hệ (sẽ được xác định trong lớp khái niệm). Đơn giản, họ xác định rằng một mối quan hệ tồn tại.
Biểu đồ bong bóng xác định bộ sưu tập cụ thể của thông tin kinh doanh. Mục tiêu là xác định, đơn giản hóa và củng cố thông tin vắng mặt của bất kỳ ứng dụng, triển khai hoặc chi tiết kỹ thuật nào mà
nó có thể hỗ trợ.
Lợi thế của mô hình dữ liệu tổng thể là tất cả khán giả có thể hiểu được bối cảnh dữ liệu doanh nghiệp trong một chế độ xem đơn giản nhưng toàn diện, cung cấp một điểm khởi đầu linh hoạt để xác định và chèn bất kỳ dữ liệu mới nào vào mô hình với giới hạn hoặc có thể không làm gián đoạn các mô hình dữ liệu cơ bản thảo luận dưới đây).
Dưới đây là một ví dụ về những gì một mô hình dữ liệu tổng thể được xác định đầy đủ có thể trông như thế nào. In chúng trên máy in lớn và đặt chúng lên tường. Nhiều cuộc trò chuyện hữu ích có thể có trong việc kiểm tra những điều này và chúng có thể trở thành một tài sản hiệu quả, có giá trị cho doanh nghiệp của bạn.
Mô hình dữ liệu khái niệm
Kiến trúc thông tin UML
- Được bảo vệ , nơi các giá trị được xác định trước.
- Công khai , nơi các giá trị có thể thay đổi.
- Riêng tư , nơi các giá trị đã hạn chế sử dụng.
Các đối tượng phần tử được kết nối trực tiếp với nhau được coi là có một số “liên kết” được biểu thị bằng một liên kết màu xám và nhãn có mục đích. Các hiệp hội này, sử dụng biểu tượng kim cương trên thành phần Parent, thể hiện các mối quan hệ:
- Đơn giản (không có kim cương).
- Dùng chung (kim cương mở).
- Hợp chất (kim cương rắn).
Một phần tử con cũng có thể là “điều hướng”, được biểu thị bằng ký hiệu mũi tên được xác định thêm bằng số lượng quan hệ (0. * = 0 đối với nhiều người, v.v.).
Hoàn thành sơ đồ UML, các phần tử có thể có các liên kết tự tham gia, đó là các đặc điểm cụ thể mở rộng định nghĩa của đối tượng cha và / hoặc “liên kết” giữa các đặc điểm cụ thể. Các phần mở rộng cụ thể không đại diện cho một lớp hoặc một khái quát nhưng xác định các đặc điểm thích hợp được gọi ra nhằm mục đích hiểu rõ hơn về silo dữ liệu trừu tượng. Sự kết nối của các đặc điểm cụ thể với một yếu tố được biểu thị bằng một liên kết màu đỏ và nhãn có mục đích. Ngoài ra, các đặc tính phần tử có thể kết nối với các đặc điểm phần tử khác của cùng một đối tượng cha được biểu thị bằng các liên kết màu lục tương tự như các khái quát liên quan.
Các mối quan hệ này cũng có thể là “điều hướng”, được biểu thị bằng một biểu tượng mũi tên mở, tùy chọn, sau đó được xác định thêm bằng một số lượng quan hệ (0. * = 0 đối với nhiều người, v.v.).
Mô hình dữ liệu khái niệm mô tả các yếu tố dữ liệu cụ thể bằng cách sử dụng một phép ẩn dụ dựa trên lớp, được lập biểu đồ tốt nhất bằng cách sử dụng UML, giải thích thêm về các silo dữ liệu tổng thể trừu tượng. Mục tiêu này là để xác định, tinh chỉnh và giảm thiểu thông tin kinh doanh, vẫn không tin vào bất kỳ ứng dụng, quy tắc thực hiện hoặc chi tiết kỹ thuật nào và cũng để gói gọn các chi tiết còn sót lại của mô hình tổng thể.
Một lần nữa, in nó ra lớn và lưu ý rằng mô hình này đại diện cho một giao diện chung dựa vào mã ứng dụng nào có thể được viết mà không có các mô hình dữ liệu logic hoặc vật lý theo sau. Ưu điểm này cũng có thể đưa ra một điểm xác nhận trước đó các mô hình dữ liệu tiếp theo được tạo ra. Xác nhận mô hình UML với cả kỹ thuật phần mềm và các bên liên quan là một cột mốc quan trọng trong quy trình mô hình hóa dữ liệu. Dưới đây là một ví dụ về việc lựa chọn mô hình dữ liệu khái niệm có thể trông như thế nào. Lưu ý rằng mô hình này có các yếu tố phụ xác định các khía cạnh cụ thể của yếu tố chính, làm rõ các đặc điểm độc đáo và định kỳ.
Mô hình dữ liệu logic
Lớp logic biểu thị một cấu trúc trừu tượng của thông tin ngữ nghĩa được tổ chức theo các thực thể miền (đối tượng dữ liệu logic), thuộc tính của chúng và các mối quan hệ cụ thể giữa chúng. Mô hình dữ liệu này được lấy từ các đối tượng phần tử của mô hình khái niệm và xác định các chi tiết thích hợp (khóa / thuộc tính) cộng với các mối quan hệ giữa các thực thể mà không liên quan đến bất kỳ công nghệ lưu trữ máy chủ cụ thể nào. Các thực thể có thể biểu diễn một phần tử, một phần của một phần tử hoặc nhiều phần tử khi cần thiết để đóng gói các cấu trúc dữ liệu phù hợp. Mô hình dữ liệu lôgic đóng gói các thực thể cấu trúc và các bộ bản ghi được xác định trong mô hình khái niệm, thêm các thuộc tính cụ thể do đó cho phép hiểu rõ hơn về dữ liệu liên quan. Đây là cách tôi làm điều đó:
ERD
Các sơ đồ mối quan hệ thực thể (ERD) mô tả các thực thể nhận dạng duy nhất có khả năng tồn tại độc lập, do đó đòi hỏi một tập hợp tối thiểu của thuộc tính nhận dạng duy nhất được gọi là khóa chính (PK). Khi một thực thể con được liên kết với một số thực thể cha, tính toàn vẹn dữ liệu tham chiếu cần được thực thi thông qua việc sử dụng một thuộc tính nhận dạng trong thực thể con khớp với (các) thuộc tính PK cha được gọi là khóa ngoại (FK). Nhưng tất cả các bạn đều biết về những điều này.
Cardinality chỉ có hai quy tắc: số lượng hàng tối thiểu và tối đa cho mỗi thực thể có thể tham gia vào mối quan hệ trong đó ký hiệu gần nhất với thực thể là số lượng tối đa. Việc chỉ định cardinality cho một bộ bản ghi cũng gợi ý rằng mối quan hệ là tùy chọn hoặc bắt buộc, hỗ trợ thiết kế cho mô hình dữ liệu vật lý.
Lưu ý một vài điều ở đây. Tôi đã sử dụng màu sắc để thể hiện các khu vực chức năng khác nhau có thể ánh xạ tới các mô hình khái niệm và tổng thể. Tôi cũng đã kết hợp mối quan hệ “ảo” giữa ENTITY_D và ENTITY_C (được hiển thị dưới dạng liên kết màu xám nhạt ).
Điều này xác định rằng một mối quan hệ logic tồn tại; tuy nhiên, cấu trúc giữa hai thực thể này cộng với ENTITY_B đại diện cho một tham chiếu vòng tròn , đây là điều cần tránh hoàn toàn trong mô hình vật lý. Ngoài ra, lưu ý rằng có một vài thuộc tính xác định một mảng các giá trị. Trong mô hình logic, điều này là ổn, vì nó đơn giản hóa và hợp lý hóa mô hình – chỉ cần đảm bảo bình thường hóa chúng trong mô hình vật lý.
Mô hình dữ liệu vật lý
Lớp vật lý đại diện cho một thành phần của các tạo phẩm hệ thống máy chủ (các đối tượng dữ liệu vật lý) có nguồn gốc từ một mô hình dữ liệu logic cùng với cấu hình lưu trữ mong muốn của nó. Mô hình dữ liệu này kết hợp các bảng, cột, loại dữ liệu, khóa, ràng buộc, quyền, chỉ mục, dạng xem và chi tiết về các tham số phân bổ có sẵn trên kho lưu trữ dữ liệu (xem blog của tôi Ngoài Vault dữ liệu để biết thêm về lưu trữ dữ liệu). Các tạo phẩm chủ này đại diện cho mô hình dữ liệu thực tế mà ứng dụng phần mềm được xây dựng. Mô hình dữ liệu vật lý gói gọn tất cả các tạo phẩm này từ các thực thể và thuộc tính được xác định trong chế độ dữ liệu logic cuối cùng cho phép ứng dụng truy cập để lưu trữ và truy xuất dữ liệu thực tế. Đây là cách tôi làm điều đó.
SDM
Mô hình thiết kế lược đồ (vật lý) (SDM) xác định các đối tượng cụ thể liên quan đến hệ thống thông tin cơ sở dữ liệu. Tôi sẽ cho rằng hầu hết độc giả của tôi biết nhiều hơn về mô hình dữ liệu này so với ba mô hình trước đó, vì vậy tôi sẽ tránh mô tả các cấu trúc. Tôi thích gọi nó là SDM để nó không bị nhầm lẫn với thuật ngữ ERD được sử dụng rộng rãi hơn ( không phải là mô hình dữ liệu vật lý). Thay vào đó, SDM cung cấp một tài liệu tham khảo kỹ thuật thường được ghi chép bằng cả sơ đồ đồ họa và tài liệu từ điển dữ liệu. Cung cấp một tài liệu tham khảo chi tiết, quan trọng cho mọi đối tượng cơ sở dữ liệu được triển khai trong SDM, tài liệu này nên kết hợp mục đích của chúng, quy tắc toàn vẹn tham chiếu và thông tin quan trọng khác về bất kỳ hành vi dự định nào. Đây là một cấu trúc tốt tôi sử dụng:
- Tên và định nghĩa đối tượng (bảng / khung nhìn)
- Tên tệp tạo / sửa đổi đối tượng SQL
- Lĩnh vực kinh doanh và sử dụng chức năng
- Phiên bản / mức toàn vẹn
- Cột / kiểu dữ liệu / kích thước
- Không có khả năng
- Giá trị mặc định
- Khóa chính
- Khóa ngoại
- Chìa khóa kinh doanh tự nhiên
- Ràng buộc độc đáo
- Kiểm tra các ràng buộc
- Các chỉ mục duy nhất và không duy nhất (phân cụm và không phân cụm)
- Kiểm soát các luồng (khi thiết kế / sử dụng phức tạp thêm có liên quan)
- Bình luận hữu ích
- Thay đổi lịch sử
Một từ điển dữ liệu SDM tham chiếu các đối tượng theo thứ tự abc theo tên để dễ sử dụng. Vì hầu hết các mô hình dữ liệu vật lý được chuẩn hóa cao, các quy tắc toàn vẹn tham chiếu nên được gọi ra cho mỗi bảng. Tôi đã thấy nhiều cách để đối phó với các quy tắc này, đặc biệt là khi thực thi các tập lệnh đối tượng SQL đối với một lược đồ hiện có. Đơn giản chỉ cần tắt kiểm tra tính toàn vẹn, chạy các tập lệnh, sau đó bật lại hoạt động. Đủ dễ dàng, nhưng tôi không phải là người hâm mộ phương pháp này, vì nó dễ bị lỗi.
Thay vào đó, tôi dành thời gian để hiểu các tham chiếu cụ thể cho tất cả các bảng và gán mức độ toàn vẹn cho mỗi bảng. Một mức toàn vẹn bảng xác định thứ tự phân cấp của mối quan hệ bảng cha / con. Nói tóm lại, mức toàn vẹn của bảng dựa trên bất kỳ tham chiếu FK nào đối với (các) bảng cha. Ví dụ:
- Một bảng không có bảng cha là L0 (mức 0), mức cao nhất.
- Một bảng có ít nhất một bảng cha là L1 (cấp 1).
- Một bảng có ít nhất một bảng cha nhưng bảng cha đó có bảng cha L0 là L2 (hoặc mức 2).
- Một bảng có nhiều bảng cha có các bảng cha có các mức khác nhau là L + 1 (cấp +1), mức thấp nhất.
- tức là: cha mẹ A là L0, cha mẹ B là L1, vì vậy bảng con là L2or: cha mẹ A là L1, cha mẹ B là L4, vì vậy bảng con là L5
- Và như vậy.
Lưu ý : L0 là mức cao nhất vì không có bảng cha; mức thấp nhất được xác định bởi mô hình dữ liệu vật lý. Phương pháp này cũng loại bỏ tiềm năng tạo ra các tham chiếu vòng tròn (một thực tiễn thiết kế mô hình dữ liệu xấu, IMHO).
Mô hình dữ liệu vật lý là một mô hình được thực hiện. Tôi thích sử dụng các kịch bản tạo đối tượng SQL hoặc SOCS cho việc triển khai này. Sử dụng phương pháp này, tôi phát hiện ra rằng DDLC cho bất kỳ mô hình dữ liệu vật lý nào có thể được tách rời thành một quy trình độc lập rất mong muốn và khó đạt được. Ý tưởng là tạo một tệp SOCS cho một đối tượng cơ sở dữ liệu chính (bảng, dạng xem, kích hoạt hoặc thủ tục được lưu trữ). Các tập lệnh này chứa các kiểm tra thông minh để xác định các câu lệnh SQL nào sẽ được áp dụng (thả, tạo, thay đổi, v.v.) và có thể, thông qua các công tắc và đối số được truyền vào tài khoản cho vòng đời được thảo luận trong blog trước của tôi, đó là:
- Một bản cài đặt mới dựa trên phiên bản hiện tại của lược đồ.
- Áp dụng nâng cấp để thả / tạo / thay đổi các đối tượng DB nâng cấp một phiên bản lên phiên bản tiếp theo.
- Di chuyển dữ liệu khi xảy ra nâng cấp đột phá (như chia bảng hoặc nền tảng).
Các tệp SOCS này kết hợp các thực tiễn tốt nhất cũng như bao gồm (của bạn có thể khác nhau):
- Quy ước đặt tên nhất quán
- Bảng tên tất cả các mũ
- Tên cột tất cả chữ thường
- Xem tên tất cả các trường hợp lạc đà
- Tên tệp SOCS kết hợp tên đối tượng
- PK cột đơn sử dụng số nguyên có kích thước phù hợp
- Loại bỏ dữ liệu dư thừa / trùng lặp (bộ dữ liệu)
- Xóa bỏ tất cả các tham chiếu chính của Thông tư (nơi có thể xảy ra Cha mẹ> Con> Cha mẹ)
- Tệp SOCS đơn cho mỗi đối tượng
- Các tệp SOCS chứa các phần tiêu đề / mục đích / lịch sử nhất quán phù hợp với từ điển dữ liệu này
- Định dạng SQL cung cấp khả năng đọc và bảo trì
Thông tin chi tiết về việc triển khai SOCS của tôi nằm ngoài phạm vi của blog này. Có lẽ tôi có thể bị thuyết phục để viết về điều này vào lúc khác. Phản hồi và câu hỏi của bạn được chào đón.
Tại sao mô hình dữ liệu của bạn?
Một bản tóm tắt ngắn gọn về các lớp này giúp hiểu được mục đích của chúng, cách chúng hỗ trợ và khác biệt với nhau trong quá trình mô hình hóa. Hãy nhìn vào bảng này để thấy:
>> Đọc thêm:
KHÓA HỌC DATA WAREHOUSE : TỔNG HỢP, CHUẨN HÓA VÀ XÂY DỰNG KHO DỮ LIỆU TRONG DOANH NGHIỆP
KHÓA HỌC DATA MODEL – THIẾT KẾ MÔ HÌNH DỮ LIỆU TRONG DOANH NGHIỆP
LỘ TRÌNH TRỞ THÀNH DATA ENGINEER CHO NGƯỜI MỚI BẮT ĐẦU
DATA ENGINEER LÀ GÌ? CÔNG VIỆC CHÍNH CỦA DE? CÁC KỸ NĂNG CẦN THIẾT
