Các khái niệm cơ bản của Multidimensional Modeling

1. Fact table
Fact table có thể được hiểu như là bảng chứa các dữ liệu có tính chất đo lường (measurement). Một fact (hay còn gọi là measure) trong data warehouse được dùng để minh họa cho một trường (field/column) chứa một giá trị đo lường được và đóng một vai trò quan trọng với business. Trên thực tế, ta hay gặp nhất các fact ở dạng số (numeric) và có tính chất cộng (additive).
Dưới đây là một ví dụ đơn giản về một fact table:

Daily Sales Fact Table
Date Key (FK)
Product Key (FK)
Store Key (FK)
Quantity Sold
Dollar Sales Amount

Có thể dễ dàng nhận thấy fact table Daily Sales chỉ có 2 loại dữ liệu chính: Foreign Key và Fact. Date Key, Product Key, và Store Key là các foreign keys. Quantity Sold và Dollar Sales Amount là các fact (measure). Date Key, Product Key, và Store Key liên kết đến các dimension table tương ứng là Date, Product, Store. Ta sẽ nói về dimension table ở phần sau.
Với cách tổ chức như trên, việc tính tổng lượng hàng hóa bán ra hoặc tổng thu nhập khá là đơn giản. Ta chỉ việc thực hiện phép toán cộng trên các record là xong. Cũng không khác nhiều lắm so với việc dùng table trong operational database. Điều khác biệt ở đây là tốc độ và sự thuận tiện.
Do cấu trúc của fact table khá đơn giản chỉ chứa duy nhất foreign key và fact, ngoài ra không có bất cứ thông tin nào khác nên tốc độ truy cập bảng khá nhanh. Một kỹ thuật hay dùng là tạo index cho các foreign key. Một kỹ thuật nữa là xây dựng sẵn các aggregate tables để tính toán trước một đại lượng nào đó dựa trên fact table.

2. Fact grain
Fact grain (độ mịn) là một khái niệm để xác định mức độ chi tiết của thông tin chứa trong fact table. Một quy định bắt buộc khi thiết kế fact table là: Tất cả các record trong fact table phải có cùng độ mịn.
Hãy xét bảng Daily Sales ở trên. Fact grain hiện tại của nó là: một loại sản phẩm (product) được bán tại một cửa hàng (store) trong một ngày (date). Bảng có các record sau:

Date Key Product Key Store Key Quantity Sold $ Sales Amount
2009-11-01 ABC XYZ 400 2000
2009-11-02 ABC XYZ 300 1500
2009-11-02 DEF UVW 500 2500

Với độ mịn như trên và giả sử rằng giá trị đơn vị của một sản phẩm là $5, ta có thể nói như sau:
- Loại sản phẩm ABC được bán tại cửa hàng XYZ trong ngày 2009-11-01 với số lượng là 400, thu về khoản tiền $2000.
- Loại sản phẩm ABC được bán tại cửa hàng XYZ trong ngày 2009-11-01 với số lượng là 300, thu về khoản tiền $1500.
- Loại sản phẩm DEF được bán tại cửa hàng UVW trong ngày 2009-11-02 với số lượng là 500, thu về khoản tiền $2500.
Tất cả các record ở trên đều thỏa mãn điều kiện: một loại sản phẩm (product) được bán tại một cửa hàng (store) trong một ngày (date). Nếu ta muốn tính tổng số lượng hàng hóa bán ra trong ngày 2009-11-02 trên mọi cửa hàng và mọi sản phẩm, ta sẽ có được con số sau: 300 + 500 = 800. Nếu ta muốn tính tổng số tiền thu được từ cửa hàng ABC trong tuần đầu tiên của tháng 11 trên mọi loại sản phẩm, ta có: 2000 + 1500 = $3500.
Giả sử rằng ta thay đổi độ mịn của fact table như sau: một loại sản phẩm (product) được bán tại một cửa hàng (store) trong một tuần (date). Dữ liệu trong bảng sẽ bắt buộc phải thay đổi theo để phù hợp với fact grain:

Date Key Product Key Store Key Quantity Sold $ Sales Amount
2009-11-Week-1 ABC XYZ 700 3500
2009-11-Week-1 DEF UVW 500 2500

Có thể thấy rằng khi độ mịn giảm, cụ thể trong trường hợp này là từ ngày đến tuần, số lượng record trong bảng cũng thay đổi theo, đồng nghĩa với tốc độ truy cập nhiều khả năng sẽ nhanh hơn. Thế nhưng đơn vị thời gian nhỏ nhất mà ta có thể tính toán được bây giờ là tuần. Nếu người dùng muốn tính toán theo đơn vị ngày, yêu cầu này không thể thực hiện được.
Giả sử bây giờ ta tăng độ mịn của fact table như sau: một loại sản phẩm (product) được bán tại một cửa hàng (store) tại một thời điểm (date). Lúc này fact table sẽ chứa dữ liệu như sau:

Date Key Product Key Store Key Quantity Sold $ Sales Amount
2009-11-01 9 a.m ABC XYZ 150 750
2009-11-01 10 a.m ABC XYZ 250 1250
2009-11-02 8:30 a.m ABC XYZ 100 500
2009-11-02 12 p.m ABC XYZ 200 1000
2009-11-02 9:45 a.m DEF UVW 50 250
2009-11-02 1:00 p.m DEF UVW 400 2000
2009-11-02 2 p.m DEF UVW 50 250

Một cách trực quan mà nói, độ mịn tăng dẫn đến số lượng record tăng lên đáng kể. Điều này có thể ảnh hưởng đến tốc độ truy cập nhưng bù lại nó giúp cho người dùng có nhiều lựa chọn hơn. Chẳng hạn nếu ta muốn xem tổng doanh số bán hàng trong buổi sáng trên mọi cửa hàng và mọi sản phẩm, ta có công thức sau: 750 + 1250 + 500 + 250 = $2750. So sánh với doanh số bán hàng vào buổi chiều 1000 + 2000 + 250 = $3250, một giám đốc kinh doanh có thể rút ra kết luận rằng xem ra người tiêu dùng có xu hướng đi shopping nhiều hơn vào buổi chiều, nhất là giờ nghỉ trưa. Từ đó, vị giám đốc này có thể đưa ra quyết định tung ra một chiến dịch khuyến mãi mới như giảm giá 10% mặt hàng ABC đồng thời tặng kèm một suất ăn nhanh miễn phí ngay tại cửa hàng .

Tóm lại, fact grain là thành tố cơ bản của fact table. Xác định đúng fact grain là một công tác quan trọng bậc nhất trong việc xây dựng một mô hình đa chiều. Đây là công việc đòi hỏi người thiết kế phải là những Data Architect giàu kinh nghiệm và có hiểu biết sâu sắc về business domain đang làm.
3.Dimension table
Nếu như fact table chứa các FK (foreign key) và measure, thì dimesion table chứa các thông tin miêu tả nghiệp vụ. Trong không gian của mô hình đa chiều, các thông tin này được gọi là thuộc tính (attribute) của dimension. Còn khi được lưu trữ cụ thể trong một cơ sở dữ liệu quan hệ, các thông tin này chính là các columns của table.

Một nguyên tắc thiết kế của data warehouse là cố gắng đưa càng nhiều thông tin vào dimension thì càng tốt. Nói cách khác, ta tìm cách "làm phẳng" hay "phi chuẩn hoá 3NF" đối với một dimension table. Lấy Product dimension làm ví dụ. Ở source database, giả sử ta có 3 tables được thiết kế theo đúng tiêu chí của 3NF là Product, SubCategory, Category. Do cả 3 tables này đều cùng miêu tả một đối tượng là Product nên khi chuyển sang dimensional model, ta chỉ cần một Product dimension bao gồm luôn thông tin từ cả 3 tables nói trên.

Với cách làm như vậy, dễ hiểu khi ta thấy có những dimension table có từ 50 đến 100 columns. Số lượng bản ghi trong một dimension table thường không nhiều. Trong ví dụ nói trên, Product dimension sẽ có cùng số lượng bản ghi như của Product table trong source database. Mỗi dimension table cũng có một primary key (PK) để xác định đính duy nhất của một bản ghi. Primary Key này sẽ được join với Foreign Key tương ứng nằm trên Fact table, và do đó kết nối Dimension và Fact với nhau.

Dimension table đóng một vai trò sống còn trong data warehouse. Do chúng chứa các thông tin miêu tả nghiệp vụ, nên đây là nguồn được dùng để sàng lọc dữ liệu, gộp nhóm, và tạo các nhãn trình bày. Trong ví dụ ở trên, nếu người dùng muốn xem tổng số tiền bán hàng theo tuần và loại hàng hóa, hiển nhiên fact table chỉ có thể cung cấp số liệu về số tiền thu được. Thông tin về loại hàng hóa chỉ có thể lấy được từ Product dimension, trong khi thông tin về thời gian cũng chỉ có thể tìm được trong Date dimension. Nói cách khác, người dùng tương tác với data warehouse chủ yếu là qua dimension table, còn fact table chỉ cung cấp các số liệu. Tuỳ theo cách nhìn của người dùng đối với nghiệp vụ, họ sẽ dùng các attributes của dimension hoặc là để sàng lọc dữ liệu, hoặc là để tạo ra các kết quả tổng hợp theo nhóm....vv

Các attributes của dimension table thường chứa dữ liệu dạng text và có tính rời rạc. Một attribute có thể chứa một miêu tả ngắn (10 - 15 ký tự) hoặc dài (30-50 ký tự), tên hàng, tên loại hàng, kiểu đóng gói, kích cỡ... vv. Mặc dù kích cỡ là một giá trị dạng số và dường như thích hợp cho fact table, nhưng về bản chất mà nói, nó mang tính miêu tả cho một hàng hóa cụ thể chứ không mang nhiều giá trị đo lường.

Các attributes trong một dimesion thường tạo thành các cây phân cấp (hierarchy). Trong Product dimension đã nói ở trên, Product là cấp thấp nhất (leaf level). Ngay phía trên là SubCategory, và trên cùng là Category. Một cách rất tự nhiên, người dùng có thể dễ dàng xem được tổng doanh thu của một Category rồi đi sâu xuống (drill down) xem sự phân bố của doanh thu theo các SubCategory trong cùng Category đó. Mức thấp nhất sẽ là doanh thu của từng Product trong một SubCategory. Quá trình ngược lại được gọi là drill up. Drill up/down là những thao tác thông dụng nhất của các ứng dụng data warehouse. Sở dĩ các thao tác này trở nên dễ dàng và nhanh chóng là do các thông tin về SubCategory và Category đã được đưa vào Product dimesion, hay nói cách khác, ta đã "làm phẳng" dimension này. Giả sử ta đua SubCategory và Category vào các dimesion tương ứng rồi liên kết chúng với Product dimension qua các foreign keys thích hợp. Cách làm không hề sai và thiết kế theo kiểu này được gọi là mô hình "bông tuyết" (snow flake) bởi hình dạng mà chúng tạo ra giống hệt một bông tuyết. Tuy nhiên, truy cập vào SubCategory và Category bây giờ phải được thực hiện trên 3 dimensions thay vì 1 như trước đây. Không kể đến việc người dùng sẽ phải làm nhiều thao tác hơn, tốc độ truy cập chắc chắn sẽ giảm đi đáng kể.

Có thể nói, trong thiết kế dimension table, ta hy sinh chuẩn 3NF để đổi lấy sự đơn giản và tốc độ. Đây có thể coi là một nguyên tắc vàng của dimensional modeling.
4. Star schema:
Với những kiến thức về fact table, fact grain, dimension table đã đề cập ở trên, khái niệm cuối cùng trong dimensional modeling, và cũng được cấu thành từ 3 khái niệm trên, là star schema. Khi ta liên kết fact table và dimension table lại với nhau dựa trên các Primary Key của dimension và Foreign Key tương ứng của fact, ta được một mô hình dữ liệu dạng hình sao - star schema.

Date Dimension
Date Key (PK)
Date attributes...

Store Dimension
Store Key (PK)
Store attributes...

Daily Sales Facts
Date Key (FK)
Product Key (FK)
Store Key (FK)
Facts...

Product Dimension
Product Key (PK)
Product attributes..


Không quá khó để thấy rằng star schema có thiết kế tương đối đơn giản và mang tính đối xứng. Nếu xét từ góc độ thuần túy nghiệp vụ, thiết kế này gần nhất với cái nhìn của người dung cuối về nghiệp vụ của họ. Trong nhiều trường hợp, đây chính là bức tranh chính xác của nghiệp vụ mà người dùng làm việc trong đó.

Thực ra nếu ta suy nghĩ sâu hơn một chút về quá trình xây dựng một cơ sở dữ liệu quan hệ cho một ứng dụng rồi xây dựng data warehouse cho ứng dụng đó, nó gần như tạo thành một vòng tuần hoàn. Những ai đã từng thiết kế cơ sở dữ liệu quan hệ - relational database - đều biết rằng một trong những bước đầu tiên là phải xác định được mô hình quan hệ - thực thể (Entity – Relationship). Sau khi các thực thể và các mối quan hệ giữa chúng đã được xác định, ta mới tiến hành xây dựng các table và column và rồi áp dụng chuẩn 3NF. Trong quá trình này, các thực thể có thể được phân nhỏ ra để tạo nên các table mới với các quan hệ 1-N. Các mối quan hệ đa chiều N-N trong mô hình E-R sẽ được thể hiện bằng một bảng trung gian với các quan hệ 1-N tương ứng. Bằng cách này, một mô hình E-R với một lượng nhỏ thực thể ban đầu có thể phát triển thành một cơ sỡ dữ liệu lớn với hàng trăm bảng được kết nối với nhau qua các mối quan hệ 1-N hoặc 1-1. Khối lượng thông tin như vậy rõ ràng là không hề dễ hiểu với người dùng cuối, vốn là những đối tượng hầu như không có chút khái niệm nào về database.

Khi xây dựng một data warehouse theo dạng star schema, một cách tự nhiên ta đã biến một cơ sở dữ liệu phức tạp quay trở lại một dạng mô hình E-R gần như ban đầu. Dĩ nhiên trong thực tế, một star schema thường tập trung vào một góc nhỏ của relational database. Do đó, từ một cơ sở dữ liệu ban đầu có thể xây dựng nhiều star schema, và mỗi star schema tập trung vào một khía cạnh cụ thể của nghiệp vụ. Trong ví dụ trên, Product là một thực thể. Khi được đưa vào cơ sở dữ liệu quan hệ, nó được chuẩn hóa theo 3NF và tách ra thành 3 bảng Product, SubCategory, Category. Khi đưa vào data warehouse, Product lại quay về hình dạng của thực thể Product ban đầu.

Một kinh nghiệm mà người viết bài này nhận thấy khi sử dụng nguyên tắc thiết kế dimensional modeling cho data warehouse hoặc cube là hãy cứ tạm thời quên đi các bảng biểu phức tạp trong database. Thay vào đó, hãy xác định các thực thể nghiệp vụ trước rồi đặt chúng trong những mối quan hệ với nhau. Về cơ bản đây chính là những gì mà người dùng muốn data warehouse làm được khi bỏ tiền ra để xây dựng một ứng dụng như vậy.

Do nó đơn giản, nên star schema là mô hình thiết kế đề cao tốc độ. Với số lượng ít hơn hẳn các table và relationship, việc truy cập dữ liệu trong table và thực hiện các phép toán join đạt tốc độ nhanh hơn rõ rệt.

Copy from fotech.org
Tác giả: Huy Nguyen