Database
 sql >> Cơ Sở Dữ Liệu >  >> RDS >> Database

Lược đồ ngôi sao so với Lược đồ bông tuyết

Trong hai bài trước, chúng ta đã xem xét hai mô hình kho dữ liệu phổ biến nhất:giản đồ hình sao và giản đồ bông tuyết. Hôm nay, chúng ta sẽ xem xét sự khác biệt giữa hai lược đồ này và chúng tôi sẽ giải thích khi nào thì tốt hơn nên sử dụng lược đồ này hoặc lược đồ kia.

Lược đồ hình sao và lược đồ bông tuyết là những cách để tổ chức các kho dữ liệu hoặc toàn bộ kho dữ liệu bằng cách sử dụng cơ sở dữ liệu quan hệ. Cả hai đều sử dụng bảng kích thước để mô tả dữ liệu được tổng hợp trong bảng dữ kiện .

Mọi người đều bán một thứ gì đó, có thể là kiến ​​thức, sản phẩm hoặc dịch vụ. Lưu trữ thông tin này, trong một hệ thống hoạt động hoặc trong một hệ thống báo cáo, cũng là một nhu cầu. Vì vậy, chúng tôi có thể mong đợi tìm thấy một số kiểu mô hình bán hàng bên trong kho dữ liệu của hầu hết mọi công ty.

Chúng ta hãy xem xét thêm mô hình bán hàng trong cả lược đồ ngôi sao và bông tuyết.

Giản đồ Ngôi sao



Đặc điểm rõ ràng nhất của giản đồ hình sao là các bảng thứ nguyên không được chuẩn hóa. Trong mô hình ở trên, fact_sales bảng lưu trữ dữ liệu tổng hợp được tạo từ (các) cơ sở dữ liệu hoạt động của chúng tôi. Các bảng màu xanh nhạt là bảng kích thước. Chúng tôi quyết định sử dụng năm thứ nguyên này vì chúng tôi cần tạo báo cáo bằng cách sử dụng chúng làm tham số. Chi tiết bên trong mỗi thứ nguyên cũng được xác định bởi nhu cầu báo cáo của chúng tôi.

Từ mô hình này, chúng ta có thể dễ dàng hiểu tại sao lược đồ này được gọi là 'lược đồ hình sao':nó trông giống như một ngôi sao, với các bảng kích thước bao quanh bảng dữ kiện trung tâm.

Lược đồ bông tuyết



Lược đồ bông tuyết này lưu trữ dữ liệu chính xác giống như giản đồ hình sao. Bảng dữ kiện có cùng kích thước như trong ví dụ giản đồ hình sao. Sự khác biệt quan trọng nhất là các bảng kích thước trong lược đồ bông tuyết được chuẩn hóa. Điều thú vị là quá trình chuẩn hóa bảng thứ nguyên được gọi là snowflaking.

Một lần nữa, về mặt hình ảnh, giản đồ bông tuyết gợi cho chúng ta nhớ đến tên gọi của nó, với một số lớp bảng kích thước tạo ra một hình dạng giống bông tuyết bất thường.

Sự khác biệt đầu tiên:Chuẩn hóa

Như đã đề cập, chuẩn hóa là điểm khác biệt chính giữa lược đồ hình sao và hình bông tuyết. Về điều này, có một số điều cần biết:

  • Lược đồ bông tuyết sẽ sử dụng ít không gian hơn để lưu trữ các bảng thứ nguyên. Điều này là do theo quy tắc, bất kỳ cơ sở dữ liệu chuẩn hóa nào cũng tạo ra ít bản ghi dư thừa hơn nhiều.
  • Mô hình dữ liệu không chuẩn hóa làm tăng nguy cơ xảy ra các vấn đề về tính toàn vẹn của dữ liệu. Những vấn đề này cũng sẽ làm phức tạp các sửa đổi và bảo trì trong tương lai.
  • Đối với những người lập mô hình dữ liệu có kinh nghiệm, giản đồ bông tuyết có vẻ được tổ chức hợp lý hơn so với giản đồ hình sao. (Đây là ý kiến ​​cá nhân của tôi, không phải là một sự thật khó hiểu. :))

Hãy chuyển sang điểm khác biệt chính thứ hai giữa hai lược đồ này.

Sự khác biệt thứ hai:Độ phức tạp của truy vấn

Trong hai bài viết đầu tiên của mình, chúng tôi đã trình bày một truy vấn có thể được sử dụng trên mô hình bán hàng để lấy số lượng tất cả các sản phẩm loại điện thoại được bán tại các cửa hàng ở Berlin trong năm 2016.

Truy vấn giản đồ hình sao trông giống như sau:

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_time ON fact_sales.time_id = dim_time.time_id
  INNER JOIN dim_store ON fact_sales.store_id = dim_store.store_id

WHERE 
  dim_time.action_year = 2016
  AND dim_store.city = 'Berlin'
  AND dim_product.product_type = 'phone'

GROUP BY 
  dim_store.store_id,
  dim_store.store_address

Để có được kết quả tương tự từ giản đồ bông tuyết, chúng ta phải sử dụng truy vấn sau:

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

Rõ ràng, truy vấn giản đồ bông tuyết phức tạp hơn. Vì bảng kích thước đã được chuẩn hóa nên chúng ta cần tìm hiểu sâu hơn để có được tên loại sản phẩm và thành phố. Chúng tôi phải thêm một JOIN khác cho mọi cấp độ mới bên trong cùng một thứ nguyên.

Trong lược đồ hình sao, chúng ta chỉ nối bảng dữ kiện với các bảng kích thước mà chúng ta cần. Tối đa, chúng tôi sẽ chỉ có một THAM GIA cho mỗi bảng thứ nguyên. Và nếu chúng ta không sử dụng bảng thứ nguyên, chúng ta thậm chí không cần bận tâm đến nó. Trong truy vấn giản đồ bông tuyết, chúng tôi không biết mình sẽ phải đi sâu đến mức nào để có được cấp thứ nguyên phù hợp, do đó, điều này làm phức tạp quá trình viết truy vấn.

Việc kết hợp hai bảng sẽ mất thời gian vì DMBS mất nhiều thời gian hơn để xử lý yêu cầu. dim_storedim_city các bảng được đặt gần nhau trong mô hình của chúng tôi, nhưng chúng có thể không được đặt ở bất kỳ đâu gần nhau trên đĩa. Có một khả năng tốt hơn là dữ liệu sẽ gần hơn về mặt vật lý trên đĩa nếu nó nằm trong cùng một bảng.

Về cơ bản, một truy vấn chạy dựa trên một kho dữ liệu giản đồ bông tuyết sẽ thực thi chậm hơn. Nhưng trong hầu hết các trường hợp, điều này sẽ không gây ra vấn đề gì:không quan trọng lắm nếu chúng tôi nhận được kết quả sau một phần nghìn giây hoặc một giây.

Tăng tốc mọi thứ

Để tăng tốc độ báo cáo, chúng tôi có thể:

  • Tổng hợp dữ liệu đến mức chúng tôi cần trong các báo cáo. Điều này sẽ nén dữ liệu đáng kể. Chúng tôi sẽ cần tạo các quy trình sẽ biến đổi dữ liệu trực tiếp của chúng tôi để phù hợp với cấu trúc giản đồ báo cáo (quy trình ETL).
  • Xây dựng khu vực lưu trữ trung tâm cho tất cả dữ liệu tổng hợp của công ty, không chỉ dữ liệu bán hàng.
  • Chỉ cung cấp cho người dùng dữ liệu họ cần để phân tích và báo cáo.

Lược đồ bông tuyết và sao:Bạn nên sử dụng cái nào?

Bây giờ chúng ta đã xem xét lý thuyết và tốc độ truy vấn, hãy đi thẳng vào trọng tâm của vấn đề:làm thế nào để bạn biết nên sử dụng lược đồ nào cho bất kỳ dự án nhất định nào?

Xem xét sử dụng giản đồ bông tuyết :

  • Trong kho dữ liệu. Vì nhà kho là Trung tâm dữ liệu của công ty nên chúng tôi có thể tiết kiệm rất nhiều không gian theo cách này.
  • Khi bảng thứ nguyên yêu cầu một lượng lớn dung lượng lưu trữ. Trong hầu hết các trường hợp, bảng dữ kiện sẽ là bảng chiếm phần lớn không gian. Chúng có thể cũng sẽ phát triển nhanh hơn nhiều so với bảng thứ nguyên. Nhưng có một số trường hợp không áp dụng. Ví dụ:các bảng thứ nguyên có thể chứa rất nhiều thuộc tính thừa nhưng cần thiết. Trong ví dụ của chúng tôi, chúng tôi đã sử dụng thành phố để mô tả thành phố nơi đặt cửa hàng. Điều gì sẽ xảy ra nếu chúng ta muốn có một mô tả chi tiết hơn về thành phố, bao gồm dân số, mã bưu điện, dữ liệu nhân khẩu học, v.v.? Mô tả các thứ nguyên phụ khác - ví dụ: cửa hàng , vùng , tiểu bang quốc gia - với nhiều thuộc tính hơn sẽ biến dim_store bảng kích thước thành một bảng lớn với rất nhiều dư thừa.
  • Nếu bạn sử dụng các công cụ yêu cầu giản đồ bông tuyết trong nền. (May mắn thay, hầu hết các công cụ hiện đại hỗ trợ cả giản đồ và thậm chí cả giản đồ thiên hà.)

Cân nhắc sử dụng giản đồ sao :

  • Trong marts dữ liệu. Data mart là tập hợp con dữ liệu được đưa ra khỏi kho dữ liệu trung tâm. Chúng thường được tạo cho các phòng ban khác nhau và thậm chí không chứa tất cả dữ liệu lịch sử. Trong cài đặt này, tiết kiệm dung lượng lưu trữ không phải là ưu tiên.

    Mặt khác, giản đồ sao đơn giản hóa việc phân tích. Đây không chỉ là về hiệu quả truy vấn mà còn về việc đơn giản hóa các hành động trong tương lai cho người dùng doanh nghiệp. Họ có thể hiểu cơ sở dữ liệu và biết cách viết truy vấn, nhưng tại sao lại phức tạp hóa mọi thứ và thêm nhiều phép nối nếu chúng ta có thể tránh được? Người dùng doanh nghiệp có thể có một truy vấn mẫu kết hợp bảng dữ kiện với tất cả các bảng thứ nguyên. Sau đó, họ chỉ cần thêm các lựa chọn và nhóm thích hợp. (Cách tiếp cận này gần với bảng tổng hợp của Excel.)

  • Nếu bạn sử dụng các công cụ yêu cầu giản đồ hình sao trong nền. (Một lần nữa, điều này thường không phải là một vấn đề.)

Cả giản đồ hình sao và giản đồ bông tuyết đều là các mô hình quan hệ được sử dụng để tổ chức các kho dữ liệu và / hoặc các siêu thị dữ liệu. Cho dù chúng giống nhau đến đâu, chúng đều thể hiện hai cách tiếp cận khác nhau và có những lợi ích và bất lợi riêng. Cá nhân tôi sẽ sử dụng lược đồ bông tuyết khi triển khai kho dữ liệu (để tiết kiệm dung lượng lưu trữ) và với lược đồ hình sao cho các siêu thị dữ liệu (để giúp người dùng doanh nghiệp dễ dàng hơn).


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Làm thế nào để thực hiện câu lệnh IF trong SQL?

  2. Một lý do khác để sử dụng gợi ý NOEXPAND trong phiên bản doanh nghiệp

  3. Các chỉ số chính của thiết kế vấn đề

  4. Mọi thứ bạn cần biết về Chuẩn hóa cơ sở dữ liệu

  5. Sự cố cập nhật bị mất trong các giao dịch đồng thời