Star Schema vs Snowflake Schema: Khác biệt & Trường hợp sử dụng

Snowflake Schema là gì?

Snowflake schema là một cách khác để tổ chức dữ liệu. Trong schema này, các bảng dimension được tách thành các bảng phân dimension nhỏ hơn để dữ liệu được tổ chức và chi tiết hơn — giống như những bông tuyết trong một hồ lớn. 

Bố cục snowflake schema. Ảnh: Tác giả.

Hãy xem các đặc điểm chính của snowflake schema khiến nó khác biệt với những schema khác:

• Bảng dimension nhiều cấp: Chúng ta có thể chia nhỏ các bảng dimension thành các bảng cụ thể hơn. Ví dụ, nếu tôi muốn theo dõi vị trí cửa hàng, thay vì đưa tất cả chi tiết vị trí vào một bảng lớn, tôi có thể tách thành các bảng riêng cho quốc gia, bang/tỉnh và thành phố. Như vậy, mỗi bảng chỉ chứa thông tin cần thiết để giảm dư thừa và cải thiện tổ chức.
• Chuẩn hoá để tiết kiệm lưu trữ: Khác với star schema, snowflake schema tuân theo thiết kế chuẩn hoá, giúp tránh trùng lặp dữ liệu. Ví dụ, thay vì lặp lại danh mục sản phẩm như Electronics cho mọi sản phẩm, tôi có thể lưu danh mục ở một bảng riêng và liên kết với từng sản phẩm.
• Phù hợp với môi trường dữ liệu phức tạp: Snowflake schema hoạt động tốt nhất cho môi trường dữ liệu phức tạp vì nó dùng các bảng nhiều cấp để xử lý quan hệ rắc rối và cấu trúc dữ liệu phân cấp.

Hãy hiểu qua một sơ đồ snowflake schema đơn giản. Ở trung tâm là bảng fact, chứa dữ liệu đo lường. Nó kết nối tới các bảng dimension mô tả các fact, và các bảng dimension này tiếp tục phân nhánh thành các bảng phân dimension, tạo thành cấu trúc như bông tuyết. 

Ví dụ, ở đây tôi tách Product thành các bảng Manufacturer và Category và tách bảng Customer thành các bảng Transaction và Location :

Ví dụ snowflake schema. Ảnh: Tác giả.

Dưới đây là ví dụ SQL minh hoạ snowflake schema, trong đó bảng Product được chuẩn hoá thêm thành các bảng Category và Manufacturer:

-- Fact table remains the same
CREATE TABLE Sales (
    Sales_ID INT PRIMARY KEY,
    Product_ID INT,
    Customer_ID INT,
    Date_ID INT,
    Sales_Amount DECIMAL(10, 2),
    FOREIGN KEY (Product_ID) REFERENCES Products(Product_ID),
    FOREIGN KEY (Customer_ID) REFERENCES Customers(Customer_ID),
    FOREIGN KEY (Date_ID) REFERENCES Dates(Date_ID)
);

-- Dimension table: Product
CREATE TABLE Product (
    Product_ID INT PRIMARY KEY,
    Product_Name VARCHAR(100),
    Category_ID INT,
    Manufacturer_ID INT,
    FOREIGN KEY (Category_ID) REFERENCES Category(Category_ID),
    FOREIGN KEY (Manufacturer_ID) REFERENCES Manufacturer(Manufacturer_ID)
);

-- Sub-dimension table: Category
CREATE TABLE Category (
    Category_ID INT PRIMARY KEY,
    Category_Name VARCHAR(50)
);

-- Sub-dimension table: Manufacturer
CREATE TABLE Manufacturer (
    Manufacturer_ID INT PRIMARY KEY,
    Manufacturer_Name VARCHAR(100)
);

Truy vấn sau đây tính tổng doanh số theo danh mục sản phẩm. Dù có nhiều phép nối hơn so với star schema, nó tiết kiệm lưu trữ hơn:

SELECT cat.Category_Name, SUM(s.Sales_Amount) AS TotalSales
FROM Sales s
JOIN Product p ON s.Product_ID = p.Product_ID
JOIN Category cat ON p.Category_ID = cat.Category_ID
GROUP BY cat.Category_Name;

Ưu điểm và hạn chế của snowflake schema

Giống như star schema, snowflake schema cũng có những ưu điểm riêng. Hãy xem đó là gì:

• Ít dư thừa dữ liệu: Chuẩn hoá đảm bảo cùng một dữ liệu không được lưu nhiều lần, giảm trùng lặp.
• Lưu trữ hiệu quả cho tập dữ liệu lớn: Schema này tiết kiệm không gian lưu trữ bằng cách tránh dữ liệu lặp lại, lý tưởng để quản lý tập dữ liệu lớn.

Tuy nhiên, bên cạnh các ưu điểm, cũng có vài hạn chế. Ví dụ, truy vấn có thể chậm hơn vì có nhiều phép nối giữa các bảng. Ngoài ra, cấu trúc nhiều cấp khó thiết kế và bảo trì hơn so với các schema đơn giản như star schema. Vì vậy, chỉ nên dùng nếu bạn có đội ngũ DBA giàu kinh nghiệm.

Tôi khuyến nghị xem khóa học Database Design nếu bạn muốn tìm hiểu thêm về cách cấu trúc dữ liệu hiệu quả cho phân tích. 

Sử dụng cách tiếp cận lai (Hybrid)

Trong các dự án thực tế, thường sử dụng cả hai mẫu ở những lớp khác nhau để kết hợp điểm mạnh của mỗi cách tiếp cận:

• Giữ cấu trúc chuẩn hoá hơn (snowflake) ở lớp kho để đảm bảo nhất quán và dễ bảo trì
• Xuất các data mart dạng ngôi sao hoặc view phi chuẩn hoá cho BI và báo cáo

Cách này giúp đội ngũ cân bằng giữa tính toàn vẹn và quản trị dữ liệu với khả năng tiêu thụ phân tích nhanh, đơn giản.

Star Schema vs Snowflake Schema

Cả star và snowflake schema đều được dùng rộng rãi trong kho dữ liệu, nhưng đặc điểm riêng khiến chúng phù hợp với các nhu cầu khác nhau. Hãy xem chúng khác nhau ra sao về cấu trúc, hiệu năng, yêu cầu lưu trữ và trường hợp sử dụng.

Cấu trúc

Trong star schema, tất cả các bảng dimension kết nối trực tiếp với một bảng fact trung tâm. Điều này có nghĩa toàn bộ dữ liệu tham chiếu của bạn chỉ cách dữ liệu chính một bước, giúp dễ hiểu và làm việc.

Ngược lại, snowflake schema chia các bảng dimension thành các bảng phân dimension nhỏ, cụ thể hơn. Ví dụ, bạn có thể có các bảng riêng cho quốc gia, bang/tỉnh và thành phố thay vì một bảng vị trí. Mặc dù tạo ra cấu trúc có tổ chức và chi tiết hơn, nó cũng đòi hỏi nhiều kết nối (join) hơn để truy cập dữ liệu — là lý do chính khiến snowflake schema phức tạp hơn star schema.

Hiệu năng

Về tốc độ, star schema thường tốt hơn. Vì tất cả bảng dimension kết nối trực tiếp với bảng fact, truy vấn thường cần ít phép nối hơn, nghĩa là hiệu năng nhanh hơn. Giả sử bạn muốn phân tích doanh số theo khu vực — trong trường hợp này, bạn có thể dùng star schema để truy xuất dữ liệu với xử lý tối thiểu.

Ngược lại, snowflake schema thường chậm hơn vì bạn phải nối qua nhiều bảng để truy xuất dữ liệu. Mỗi phép nối thêm thời gian xử lý, khiến snowflake kém hiệu quả hơn cho các tác vụ cần kết quả truy vấn nhanh.

Khóa học Joining Data in SQL là phần mở đầu tuyệt vời để học cách nối bảng, áp dụng lý thuyết tập quan hệ và làm việc với truy vấn lồng.

Yêu cầu lưu trữ

Star schema tốn nhiều không gian lưu trữ hơn vì lưu thông tin dư thừa trong các bảng dimension. Ví dụ, nếu nhiều sản phẩm thuộc cùng một danh mục, tên danh mục sẽ lặp lại cho mỗi sản phẩm, làm tăng nhu cầu lưu trữ.

Tuy nhiên, snowflake schema chuẩn hoá dữ liệu để mọi thông tin chỉ được lưu một lần. Ví dụ, thay vì lặp lại tên danh mục, chúng được lưu trong bảng riêng và liên kết với bảng sản phẩm bằng khoá ngoại. Thiết kế này tiết kiệm không gian, phù hợp với tập dữ liệu lớn.

Trường hợp sử dụng

Star schema lý tưởng cho hệ thống xử lý phân tích trực tuyến (OLAP), báo cáo và tác vụ business intelligence. Sự đơn giản khiến chúng hoàn hảo cho các tình huống cần tốc độ và dễ sử dụng, như tạo dashboard nhanh hoặc báo cáo doanh số.

Snowflake schema thường được dùng cho phân tích tài chính hoặc hệ thống quản lý quan hệ khách hàng (CRM). Việc tổ chức phân cấp chi tiết và tiết kiệm lưu trữ quan trọng hơn tốc độ truy vấn trong các trường hợp này.

Bảng so sánh

Dưới đây là so sánh nhanh giữa star và snowflake schema để giúp bạn quyết định cái nào phù hợp nhất với nhu cầu dữ liệu. Tôi đã làm nổi bật các khác biệt chính trong bảng này, tập trung vào cấu trúc, hiệu năng, lưu trữ và trường hợp sử dụng:

Chọn Schema phù hợp

Khi nào dùng star schema

Nếu mục tiêu chính của bạn là tổ chức dữ liệu đơn giản và nhanh chóng, star schema sẽ rất phù hợp. Dùng trong các trường hợp sau:

• Nếu bạn đang xây dựng mô hình ngữ nghĩa cho công cụ BI (ví dụ, Power BI) và muốn số lượng bảng và quan hệ ít. Nó hỗ trợ lọc/nhóm trực quan và thường hoạt động tốt cho biểu đồ tương tác.
• Nếu bạn muốn chạy các truy vấn đơn giản như tìm tổng doanh số theo khu vực, hãy dùng star schema. Vì tất cả bảng dimension kết nối trực tiếp với bảng fact, nó tránh phức tạp không cần thiết và cho kết quả nhanh hơn.
• Bạn cũng có thể dùng star schema khi ưu tiên tốc độ. Nó giảm số lượng phép nối, nên truy vấn chạy nhanh hơn. Tôi từng dùng để tạo nhiều báo cáo doanh số, tiết kiệm rất nhiều thời gian so với các thiết kế khác.
• Nếu tập dữ liệu của bạn nhỏ đến trung bình, sự dư thừa của star schema sẽ không phải vấn đề. Dù có dữ liệu lặp, nó vẫn hoạt động tốt mà không làm quá tải lưu trữ.

Khi nào dùng snowflake schema

Snowflake schema phù hợp hơn để biểu diễn phân cấp và dữ liệu tham chiếu dùng chung, đặc biệt khi nhiều thuộc tính dimension lặp lại trên nhiều hàng. Dùng trong các trường hợp sau:

• Khi các dimension của bạn có phân cấp rõ ràng (ví dụ, Quốc gia → Bang/Vùng → Thành phố) và bạn muốn mô hình hoá các cấp đó tách biệt thành các bảng.​
• Nếu bạn muốn kiểm soát chặt chẽ dữ liệu tham chiếu dùng chung (ví dụ, danh sách chuẩn như danh mục, nhà sản xuất hoặc địa lý) để giảm trùng lặp và dễ giữ định nghĩa nhất quán trong toàn kho dữ liệu.
• Bạn cũng có thể dùng snowflake schema nếu dữ liệu thay đổi thường xuyên, như cập nhật tên khu vực. Nó đảm bảo cập nhật nhất quán trên toàn bộ dữ liệu liên quan để giảm lỗi và công sức bảo trì.
• Nếu phân tích của bạn liên quan đến nhiều cấp dữ liệu, snowflake schema có thể giúp bạn tổ chức và biểu diễn các mối quan hệ này một cách rõ ràng.

Lựa chọn schema trong kho dữ liệu đám mây

Trong nhiều kho dữ liệu đám mây hiện đại, lưu trữ tương đối rẻ so với tính toán. Điều đó có nghĩa “thêm lưu trữ” từ các dimension phi chuẩn hoá thường kém quan trọng hơn chi phí tính toán để quét và nối dữ liệu.

Khi chọn giữa star và snowflake, hãy cân nhắc mô hình giá của nền tảng (tính toán so với lưu trữ), mức độ đồng thời truy vấn, và liệu bạn có thể dùng cache/view vật hoá để giảm chi phí truy vấn hay không.

Lời kết

Trong bài viết này, tôi đã trình bày sự khác biệt giữa star và snowflake schema, điểm mạnh và thời điểm dùng mỗi loại. Hy vọng bạn đã có hiểu biết rõ ràng và mẹo thực tiễn cho công việc! Nếu muốn học thêm, hãy xem các tài nguyên trên DataCamp:

• Khóa học Introduction to Data Modeling in Snowflake sẽ giúp bạn xây nền tảng làm việc với Snowflake. 
• Khóa học Data Modeling in Power BI để tổ chức và quản lý dữ liệu trong Power BI.
• Lộ trình kỹ năng Associate Data Engineer in  SQL để nâng cao kỹ năng SQL của bạn.