Trong một bài viết trước, chúng ta đã thảo luận về mô hình giản đồ hình sao. Lược đồ bông tuyết nằm bên cạnh lược đồ sao về tầm quan trọng của nó trong việc lập mô hình kho dữ liệu. Nó được phát triển ngoài lược đồ sao, và nó mang lại một số lợi thế so với người tiền nhiệm của nó. Nhưng những lợi thế này đi kèm với cái giá phải trả. Trong bài viết này, chúng ta sẽ thảo luận về thời điểm và cách sử dụng giản đồ bông tuyết.
Lược đồ bông tuyết
Tên của giản đồ bông tuyết xuất phát từ thực tế là các bảng thứ nguyên phân nhánh và trông giống như một bông tuyết. Khi nhìn vào mô hình ở trên, chúng ta sẽ nhận thấy đó là một bảng dữ kiện được bao quanh bởi một số bảng thứ nguyên, một số trong số đó thực hiện phân nhánh đã nói ở trên. Không giống như giản đồ hình sao, các bảng thứ nguyên trong lược đồ bông tuyết có thể có các danh mục riêng.
Ý tưởng thống trị đằng sau giản đồ bông tuyết là các bảng kích thước được chuẩn hóa hoàn toàn. Mỗi bảng kích thước có thể được mô tả bằng một hoặc nhiều bảng tra cứu. Mỗi bảng tra cứu có thể được mô tả bằng một hoặc nhiều bảng tra cứu bổ sung. Điều này được lặp lại cho đến khi mô hình được chuẩn hóa hoàn toàn. Quá trình chuẩn hóa bảng kích thước giản đồ hình sao được gọi là snowflaking.
Bạn sẽ nghe rất nhiều về chuẩn hóa trong bài viết này. Chuẩn hóa là gì? Về cơ bản, đó là tổ chức cơ sở dữ liệu theo cách giảm thiểu dư thừa và bảo vệ tính toàn vẹn của dữ liệu. Hãy xem bài đăng này để tìm hiểu thêm về chuẩn hóa và không chuẩn hóa.
Ví dụ về giản đồ bông tuyết:Mô hình bán hàng
Trước đây, chúng tôi đã sử dụng giản đồ sao để lập mô hình một bộ phận bán hàng hư cấu - đây sẽ giống như một trung tâm dữ liệu được sử dụng để theo dõi các hoạt động và kết quả bán hàng. Mô hình có năm kích thước: sản phẩm , thời gian , cửa hàng , bán hàng loại và nhân viên . Trong fact_sales bảng, giá và số lượng được lưu trữ và nhóm lại dựa trên các giá trị trong bảng thứ nguyên. Để có thêm thông tin mới, hãy xem mô hình bán hàng theo giản đồ sao bên dưới:
Đây là mô hình tương tự được tổ chức như một giản đồ bông tuyết:
dim_employee và dim_sales_type bảng thứ nguyên giống hệt như trong mô hình giản đồ hình sao vì chúng đã được chuẩn hóa.
Mặt khác, chúng tôi đã áp dụng quy tắc chuẩn hóa cho phần còn lại của bảng thứ nguyên.
dim_product bảng kích thước từ giản đồ sao được chia thành hai bảng trong mô hình bông tuyết. dim_product_type bảng đã được thêm vào để tham chiếu loại đối sánh trong dim_product bàn. Sử dụng điều này, chúng tôi đã tránh được một số vấn đề về toàn vẹn dữ liệu.
Thật hợp lý khi giả sử rằng chúng tôi đã chèn tất cả tên sản phẩm và các loại liên quan của chúng như một phần của quy trình ETL, nhưng giả sử chúng tôi cần thêm nhiều tên và loại sản phẩm hơn. Trong giản đồ sao, chúng tôi có thể nhập nhầm loại sản phẩm vào bảng. Trong giản đồ bông tuyết:
- Nếu gặp tên loại sản phẩm mới, chúng tôi có thể thêm một loại sản phẩm mới và sau đó liên kết loại đó với một bản ghi mới được thêm vào. Tuy nhiên, điều này có thể dẫn đến việc người dùng nhập sai thông tin, giống như trong giản đồ hình sao.
- Chúng tôi có thể kiểm tra xem tên sản phẩm mà chúng tôi muốn thêm đã tồn tại hay chưa. Nếu vậy, chúng tôi có thể lấy ID của nó; nếu không, một cảnh báo sẽ xuất hiện hỏi chúng tôi có muốn thêm sản phẩm mới và loại có liên quan hay không.
dim_store bảng kích thước từ giản đồ hình sao được biểu thị bằng 5 bảng trong giản đồ bông tuyết. Những điều này phân chia các thuộc tính thành phố, khu vực, tiểu bang và quốc gia được lưu trữ trong dim_store bàn. Việc chuẩn hóa bảng này không chỉ tránh được nguy cơ toàn vẹn dữ liệu mà còn tiết kiệm được một số không gian đĩa.
dim_time thứ nguyên được biểu thị bằng năm bảng. Chúng ta có thể nghĩ đến dim_week , dim_month , dim_year và dim_weekday bảng dưới dạng từ điển mô tả dim_time bàn.
dim_week , dim_month , dim_year và dim_weekday bảng là bốn thứ bậc khác nhau được sử dụng để mô tả thứ nguyên thời gian của chúng ta. Chúng tôi có thể thêm nhiều thứ nguyên hơn như phần tư hoặc các bảng liên quan khác nếu chúng tôi cần. Trong ví dụ này, dim_month là một từ điển chứa 12 tháng; chỉ từ không gian này, chúng ta không có cách nào biết được tháng đó thuộc về năm nào; đó là chức năng của dim_year bàn.
Ví dụ về giản đồ bông tuyết:Mô hình đơn đặt hàng cung cấp
Kho dữ liệu khác mà chúng tôi đã thảo luận là dành cho các đơn đặt hàng cung cấp. Ý tưởng là lưu trữ và tổng hợp tất cả dữ liệu đặt hàng cung cấp cho bốn thứ nguyên sau: sản phẩm , thời gian , nhà cung cấp và nhân viên . Một lần nữa, chúng ta sẽ xem xét giản đồ sao có liên quan:
Chuyển đổi nó thành giản đồ bông tuyết, chúng tôi nhận được mô hình sau:
Các quy tắc chuẩn hóa tương tự như các quy tắc được mô tả cho mô hình bán hàng đã được sử dụng trên dim_product , dim_time và dim_supplier bảng kích thước.
Ưu điểm và nhược điểm của giản đồ bông tuyết
Có hai ưu điểm chính vào giản đồ bông tuyết:
- Chất lượng dữ liệu tốt hơn (dữ liệu có cấu trúc hơn, do đó các vấn đề về tính toàn vẹn của dữ liệu được giảm thiểu)
- Khi đó, ít dung lượng đĩa hơn được sử dụng trong một mô hình không chuẩn hóa
Điểm bất lợi đáng chú ý nhất đối với mô hình bông tuyết là nó yêu cầu các truy vấn phức tạp hơn. Những truy vấn này, với số lượng liên kết tăng lên, có thể làm giảm hiệu suất đáng kể.
Chúng tôi sẽ viết lại cùng một truy vấn được sử dụng trong bài viết giản đồ hình sao cho mô hình bán hàng giản đồ bông tuyết. Dưới đây là truy vấn cần thiết để trả về số lượng của tất cả các loại sản phẩm kiểu điện thoại đã bán tại các cửa hàng ở Berlin trong năm 2016:
SELECT dim_store.store_address, SUM(fact_sales.quantity) AS quantity_sold FROM fact_sales INNER JOIN dim_product ON fact_sales.product_id = dim_product.product_id INNER JOIN dim_product_type ON dim_product.product_type_id = dim_product_type.product_type_id INNER JOIN dim_time ON fact_sales.time_id = dim_time.time_id INNER JOIN dim_year ON dim_time.year_id = dim_year.year_id INNER JOIN dim_store ON fact_sales.store_id = dim_store.store_id INNER JOIN dim_city ON dim_store.city_id = dim_city.city_id WHERE dim_year.action_year = 2016 AND dim_city.city = 'Berlin' AND dim_product_type.product_type_name = 'phone' GROUP BY dim_store.store_id, dim_store.store_address
Lược đồ Starflake
Lược đồ bông tuyết là sự kết hợp của lược đồ bông tuyết và sao. Chúng ta có thể xem nó như một giản đồ bông tuyết có một số bảng kích thước không được chuẩn hóa. Khi được sử dụng đúng cách, lược đồ starflake có thể đưa ra cách tiếp cận tốt nhất của cả hai thế giới. Rõ ràng, phần bông tuyết của mô hình sẽ tiết kiệm dung lượng đĩa, trong khi phần hình sao sẽ cải thiện hiệu suất.
Mô hình trên về cơ bản là mô hình bông tuyết với dim_time bàn. Vì lược đồ này làm giảm số lượng kết nối truy vấn cần thiết, nên nó có thể cải thiện hiệu suất. Mặt khác, chúng tôi sẽ không mất một lượng đáng kể dung lượng ổ đĩa, vì hầu hết các thuộc tính bảng và thuộc tính khóa ngoại đều chia sẻ int loại.
Lược đồ Thiên hà
Trong kho dữ liệu, giản đồ thiên hà là khi hai hoặc nhiều bảng dữ kiện chia sẻ một hoặc nhiều bảng thứ nguyên. Một lý do để sử dụng lược đồ này là để tiết kiệm dung lượng ổ đĩa. Chúng tôi đã tạo một giản đồ thiên hà mẫu bên dưới:
Ở đây, chúng tôi có hai bảng dữ kiện, fact_sales và fact_supply_order , chia sẻ trực tiếp bảng ba thứ nguyên:dim_product , dim_employee và dim_time . Lưu ý rằng ngay cả dim_store và dim_supplier chia sẻ cùng một bảng tra cứu, dim_city .
Chúng tôi sẽ tiết kiệm không gian theo cách này, nhưng chúng tôi phải lưu ý một số điều trước khi kết hợp hai siêu thị dữ liệu (trong trường hợp này là đơn đặt hàng bán và cung cấp) thành một giản đồ thiên hà:
- Có bất kỳ logic nào đằng sau việc kết hợp chúng không? Ví dụ: Cả hai kho dữ liệu có được sử dụng bởi cùng một bộ phận không?
- Chúng tôi có chắc chắn rằng chúng tôi cần chính xác cùng một thứ nguyên và chi tiết cho cả hai siêu thị dữ liệu?
Lược đồ bông tuyết thường được sử dụng trong mô hình dữ liệu. Nó có thể là sự lựa chọn đúng đắn trong những tình huống mà dung lượng ổ đĩa quan trọng hơn hiệu suất. Nếu chúng ta muốn có sự cân bằng giữa tiết kiệm không gian và hiệu suất, chúng ta có thể sử dụng lược đồ starflake. Tuy nhiên, sự phù hợp phù hợp cho bất kỳ vấn đề cụ thể nào phụ thuộc vào nhiều thông số. Đây là một trong những lĩnh vực trong CNTT mà chúng ta có thể ‘chơi’ với các yếu tố để đưa ra giải pháp tốt nhất.
