Ngày nay, các báo cáo và phân tích quan trọng như là nghiệp vụ chính vậy. Các bản báo cáo có thể được xây dựng lên từ dữ liệu trực tuyến; thường thì kiểu tiếp cận này sẽ hay dùng trong công ty vừa và nhỏ mà không có nhiều dữ liệu. Nhưng khi mọi thứ lớn lên hoặc lượng dữ liệu bắt đầu tăng lên nhanh chóng, đến lúc phải nghĩ đến vấn đề chia tách dữ liệu hệ thống hoạt động (operational systems) và hệ thống báo cáo (reporting system).
Trước khi giải quyết mô hình dữ liệu, chúng ta cần vài hiểu biết nền tảng về hệ thống. Chúng ta cần chia các hệ thống ra thành 2 danh mục: hệ thống hoạt động (operational system) và hệ thống báo cáo (reporting system). Hệ thống hoạt động thường gọi là OLTP. Các bạn có thể đọc bài Sự khác nhau giữa OLTP và OLAP. Hệ thống báo cáo và phân tích được biết đến là OLAP. OLTP hỗ trợ xử lý giao dịch trong nghiệp vụ kinh doanh. Chúng làm việc với dữ liệu “live” và cần độ chuẩn hoá cao vì nó cần phải tương tác với người dùng tốc độ nhanh. Ngược lại, mục đích chính của OLAP là phân tích. Các hệ thống này sử dụng để tổng hợp dữ liệu, thường được thiết kế theo cấu trúc phi chuẩn cho kho dữ liệu giống sơ đồ ngôi sao. (Phi chuẩn là gì? Đơn giản là giảm dư thừa dữ liệu cho tốc độ nhanh hơn)
Giờ chúng ta đã biết một chút về các hệ thống, hãy bắt đầu nào:
Data Warehouses và Data Marts
Một data warehouse (kho dữ liệu – DWH) là một hệ thống được dùng để lưu trữ thông tin cho việc phân tích và báo cáo. Data Marts là một tập con của data warehouses được dùng để lưu trữ thông tin cần thiết cho một phòng ban hoặc ngay cả một người dùng đơn lẻ. (Tưởng tượng DWH là một toà nhà, data marts là một văn phòng trong toà nhà).
Tại sao lại cần data marts? Tất cả các dữ liệu liên quan được lưu trữ trong công ty DWH. Đối với hầu hết người dùng, họ chỉ cần truy cập vào một tập con dữ liệu cụ thể, giống như bán hàng (sales), sản xuất (production), giao vận (logistic) hoặc marketing. Data marts quan trọng ở cả 2 mặt là bảo mật dữ liệu và tránh nhầm lẫn vì quá nhiều dữ liệu (chúng ta không muốn nhầm lẫn chúng hoặc làm việc với những dữ liệu không liên quan).
Có 2 cách tiếp cận để xây dựng data warehouse và data mart:
- Top-Down: Data mart được tạo từ data warehouse có trước.
- Bottom-Up: Data marts được tạo đầu tiên, sau đó kết hợp chúng lại thành data warehouse.
Quá trình ETL được sử dụng để thêm dữ liệu vào hệ thống OLAP. ETL là viết tắt cảu Extract, Transform và Load. Như tên của nó, chúng ta trích xuất (extract) dữ liệu từ một hoặc nhiều nguồn là các cơ sở dữ liệu hoạt động (OLTP), sau đó chuyển nó (transform) cho phù hợp với cấu trúc của datawarehouse, và load nó vào DWH.
Mô hình chiều dữ liệu (Dimensional modeling) là một phần của thiết kế data warehouse, kết của trong việc tạo mô hình chiều. Có 2 loại bảng tham gia vào:
- Các bảng dimension được sử dụng để mô tả dữ liệu mà chúng ta muốn lưu trữ. Ví dụ: một nhà bán lẻ muốn lưu trữ thời gian, cửa hàng, và nhân viên tham gia vào một hoá đơn. Mỗi một bảng dimension là một danh mục của chính nó (ngày tháng, nhân viên, cửa hàng) và có thể có một hoặc nhiều thuộc tính (attributes). Với mỗi một cửa hàng, chúng ta lưu chúng các thông tin như vị trí trong thành phố, vùng miền, tỉnh thành và quốc gia. Mỗi một ngày tháng chúng ta lưu năm, tháng, ngày trong tháng, ngày trong tuần…Điều này liên quan đến sự phân cấp của các thuộc tính trong bảng dimension.
Trong sơ đồ ngôi sao, chúng ta sẽ thường tìm một vài thuộc tính là tập con của các thuộc tính khác trong cùng 1 bản ghi. Sự dư thừa này nên rất thận trọng và giúp tăng hiệu năng tốt hơn. Chúng ta có thể dùng ngày tháng, vị trí, và chi nhánh bán hàng để tổng hợp (chính là transform trong ETL) và lưu trữ dữ liệu trong DWH. Trong mô hình dimension, nó rất quan trọng trong việc định nghĩa dimension đúng và phù hợp.
- Bảng Fact chứa dữ liệu mà chúng ta muốn thêm vào reports, tổng hợp trên các giá trị trong các bảng dimension. Một bảng fact chỉ có các cột lưu giá trị và các cột khoá ngoại tham chiếu đến bảng dimensions. Kết hợp tất cả các khoá ngoại và khoá chính trong bảng fact. Ví dụ, một bảng fact có thể lưu trữ một số lượng các hợp đồng và số lượng các nhân viên bán hàng từ các danh sách hợp đồng.
Với các thông tin này chúng ta có thể hiểu và xây dựng được sơ đồ ngôi sao.
Sơ đồ ngôi sao (Star Schema)
Sơ đồ ngôi sao là mô hình đơn giản nhất được sử dụng trong DWH. Bởi vì bảng fact là trung tâm của mô hình với các bảng dimension xung quanh nó, nó nhìn giống như một ngôi sao. Điều này rất rõ ràng khi bảng fact được bao quanh bởi 5 bảng dimension. Một biến thể của sơ đồ ngôi sao là sơ đồ con rết (centipede schema), nơi mà bảng fact được bao quanh bởi số lượng lớn các bảng dimension nhỏ.
Mô hình ngôi sao được sử dụng rộng rãi trong data marts. Chúng ta có thể kết hợp chung trong mô hình top-down. Chúng ta sẽ phân tích mô hình 2 ngôi sao và kết hợp chúng để tạo ra mô hình đơn giản.
Ví dụ sơ đồ ngôi sao (Star schema): Sales
Báo cáo bán hàng (sales reports) là một trong những báo cáo phổ biết nhất hiện nay. Như chúng ta đã nhắc đến ở trên, hầu hết các trường hợp chúng ta tạo ra báo cáo bán hàng từ hệ thống “live”. Nhưng khi kích thước dữ liệu hoặc nghiệp vụ làm cho chúng trở nên rườm rà, chúng ta sẽ phải xây dựng một data warehouse hoặc một data mart để sắp xếp lại quy trình. Sau khi thiết kế mô hình ngôi sao, một quá trình ETL sẽ lấy dữ liệu từ cơ sở dữ liệu hoạt động (OLTP), chuyển dữ liệu theo định dạng của DWH và bơm vào data warehouse.
Mô hình trình bày ở trên chứa một bảng fact (màu đỏ) và 5 bảng dimension (màu xanh). Các bảng này là:
- fact_sales –Bảng này chứa tham chiếu đến các bảng dimensions và thêm 2 thông tin chính (giá và số lượng bán). Chú ý là tất cả 5 khoá ngoại kết hợp với khoá chính của bảng.
- dim_sales_type –Bảng này là loại sales có duy nhất 1 thuộc tính “type_name”.
- dim_employee – Đây là bảng nhân viên, lưu thông tin cơ bản của nhân viên: họ tên và năm sinh.
- dim_product –Bảng này lưu danh sách sản phẩm với 2 thuộc tính (tên và loại sản phẩm).
- dim_time – Bảng này nắm giữ thời gian. Nó bao gồm 5 thuộc tính ngoài khoá chính. Mức thấp nhất là ngày (action_date). Thuộc tính action_week là số tuần trong năm (Ví dụ tuần đầu trong tháng 1 sẽ là 1; tuần cuối của tháng 12 sẽ là 52, etc.) Thuộc tính actual_month và thuộc tính actual_year lưu trữ tháng và năm bán hàng. Các hông tin này được lấy ra từ thuộc tính action_date. Thuộc tính action_weekday lưu trữ tên của ngày bán hàng.
- dim_store –Mỗi một cửa hàng sẽ lưu thành phố, vùng, tỉnh và quốc gia nơi mà nó đặt. Chúng ta có thể rõ ràng là mô hình ngôi sao được phi chuẩn.
Ví dụ mô hình ngôi sao: Supply Orders
Có nhiều sự tương đồng với mô hình sales ở trên:
Mô hình này tập trung lưu trữ lịch sử của hoá đơn. Chúng ta có một bảng fact và 4 bảng dimension. Các bảng dimension: dim_employee, dim_product và dim_time trích xuất thông tin giống như mô hình sales. Tuy nhiên các bảng dươi đây lại khác:
- fact_supply_order – chứa dữ liệu tổng hợp về hoá đơn.
- dim_supplier – là bảng chứa danh sách nhà cung cấp giống dim_store lưu trữ thông tin cửa hàng trong mô hình sales.
Điểm mạnh và yếu của mô hình ngôi sao.
Có nhiều điểm mạnh của mô hình ngôi sao. Bảng fact liên quan đến mỗi bảng dimension bởi một quan hệ, và chúng ta không cần bất cứ từ điểm bổ sung nào để mô tả các bảng dimension. Đơn giản là truy vấn và giảm thời gian thực thi. Chúng ta có thể tái hiện báo cáo trực tiếp từ hệ thống OLTP, nhúng câu lệnh sẽ phức tạp hơn và có thể ảnh hưởng đến hiệu năng chung của hệ thống. Ví dụ sau đây là câu truy vấn cho mô hình sales sẽ trả về số lượng của tất cả các loại điện thợi được bán ở các cửa hàng đặt tại 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_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
|
|
Điểm yếu nhất của mô hình ngôi sau là dư thừa. Mỗi bảng dimension lưu trũ tách rời, và đây là nguyên nhân của không chuẩn hoá. Trong ví dụ của chúng ta, thành phố thuộc về một vùng hoặc một tỉnh thành, chúng cũng thuộc về một đất nước; chúng ta không lưu trữ mối quan hệ như là một quy tắc của cơ sở dữ liệu, nhưng chúng ta cứ lặp lại nó. Nghĩa là chúng ta sẽ tốn nhiều dung lượng ổ đĩa và có rủi ro về toàn vẹn dữ liệu.
Mô hình thiên hà (Galaxy Schema)
Chúng ta có thể nhìn vào 2 mô hình trên như là 2 data mart, 1 là cho phòng bán hàng (sales) 2 là cho bộ phận nhà cung cấp (supply). Mỗi cái đó bao gồm chỉ một bảng fact và một vài bảng dimension. Nếu chúng ta muốn kết hợp 2 data mart vào làm một. Đây là kiểu mô hình chứa vài bảng fact và chia sẻ các bảng dimension nó được gọi là mô hình galaxy (galaxy schema). Chia sẻ các bảng dimension có thể giảm kích thước của cơ sở dữ liệu đặc biết là khi chia sẻ các bảng dimension có nhiều giá trị. Ý tưởng là các bảng dimension trong cả 2 data mart có chung 1 cách thức. Nếu không chúng ta sẽ phải căn chỉnh cho nó phù hợp với cả 2.
Một mô hình thiên hà (galaxy schema) được xây dựng lên với 2 ví dụ data mart, được hiển thị như hình:
Mô hình ngôi sao (star schema) là một cách tiếp cận để tổ chức data warehouse. Nó rất đơn giản và thường dùng trong data mart. Nếu bạn không phải lo về dung lượng ổ đĩa và chúng ta làm tốt phần toàn vẹn dữ liệu thì mô hình ngôi sao khả thi và là lựa chọn tốt. Nếu không thì các bạn nên nghĩ đến cách tiếp cận khác. Một trong số đó là mô hình bông tuyết (snowflake shema) chúng ta sẽ nói đến sau.
Trích nguồn từ: (vertabelo.com)
