Phân tích đánh giá các hướng nghiên cứu đã có của các tác giả trong và ngoài nước liên quan đến Đề tài; nêu những vấn đề còn tồn tại; chỉ ra những vấn đề mà Đề tài cần tập trung, nghiên cứu giải quyết

MỞ ĐẦU: Trình bày lí do chọn đề tài, mục đích, đối tượng và phạm vi nghiên cứu. TỔNG QUAN: Phân tích đánh giá các hướng nghiên cứu đã có của các tác giả trong và ngoài nước liên quan đến đề tài; nêu những vấn đề còn tồn tại; chỉ ra những vấn đề mà đề tài cần tập trung, nghiên cứu giải quyết. NGHIÊN CỨU THỰC NGHIỆM HOẶC LÍ THUYẾT: Trình bày cơ sở lí thuyết, lí luận, giả thiết khoa học và phương pháp nghiên cứu đã được sử dụng trong khoá luận . TRÌNH BÀY, ĐÁNH GIÁ BÀN LUẬN VỀ CÁC KẾT QUẢ: Mô tả ngắn gọn công việc nghiên cứu khoa học đã tiến hành, các kết quả nghiên cứu khoa học hoặc kết quả thực nghiệm. Đối với các đề tài ứng dụng có kết quả là sản phẩm phần mềm phải có hồ sơ thiết kế, cài đặt, ... theo một trong các mô hình đã học (UML, ...) KẾT LUẬN: Trình bày những kết quả đạt được, những đóng góp mới và những đề xuất mới. Phần kết luận cần ngắn gọn, không có lời bàn và bình luận thêm. HƯỚNG PHÁT TRIỂN: Kiến nghị về những hướng nghiên cứu tiếp theo. DANH MỤC TÀI LIỆU THAM KHẢO: Chỉ bao gồm các tài liệu được trích dẫn, sử dụng và đề cập tới để bàn luận trong khoá luận . PHỤ LỤC. Kho dữ liệu Tổng quan về kho dữ liệu Khái niệm Khái niệm kho dữ liệu (data warehouse) lần đầu tiên được đưa ra bởi hai kiến trúc sư người Ireland của công ty IBM là Barry Devlin và Paul Murphy năm 1988. Từ đó đến nay, khái niệm kho dữ liệu hầu như không có nhiều thay đổi. Theo Barry Devlin và Paul Murphy, kho dữ liệu được hiểu là: “Một nhà kho luận lí chứa tất cả những thông tin cần thiết phục vụ cho các báo cáo nghiệp vụ” (Pentaho Solutions – Trang 111). Các nhu cầu thực tế của kho dữ liệu Kho dữ liệu là một cơ sở dữ liệu được thiết kế đặc biệt cho các nhu cầu liên quan đến việc hỗ trợ ra quyết định. Từ góc nhìn của người dùng, kho dữ liệu mang lại những lợi ích sau: Dữ liệu lưu trữ tập trung tại một nơi Thông tin luôn được cập nhật: Thông tin từ nhiều nguồn được cập nhật định kì vào kho. Truy xuất nhanh: Kho dữ liệu được thiết kế đặc biệt cho việc truy xuất nhanh với khối lượng thông tin lớn. Không giới hạn kích thước Lưu mọi thông tin lịch sử: Toàn bộ lịch sử dữ liệu được lưu vết, phục vụ việc phân tích số liệu theo thời gian. Dễ hiểu: Kho dữ liệu được mô hình hoá dựa trên những thuật ngữ nghiệp vụ, gần gũi và dễ hiểu. Rõ ràng và đồng nhất: Dữ liệu được hợp nhất và thống nhất dựa trên các khái niệm nghiệp vụ. Dữ liệu chuẩn hoá: Tất cả dữ liệu được chuẩn hoá theo một chuẩn chung. Các đặc trưng của kho dữ liệu Kho dữ liệu có các đặc trưng sau đây (theo Bill Inmon): Hướng chủ thể (subject oriented): Tất cả các thực thể và sự kiện liên quan đến một chủ thể được kết nối với nhau. Biến thiên theo thời gian: Tất cả các thay đổi trên dữ liệu được theo dõi để thể hiện sự biến đổi theo thời gian. Tính ổn định (non-volatile): Khi dữ liệu được lưu vào kho, nó sẽ không bao giờ bị ghi đè hoặc xoá. Với nhiều kiến trúc cao cấp, tính chất này không được duy trì trên từng phần nhưng về tổng thể cần được bảo đảm. Tính tích hợp: Kho dữ liệu chứa dữ liệu được tích hợp từ nhiều hệ thống nguồn sau khi đã được làm sạch và chuẩn hoá. Kho dữ liệu được xây dựng nhằm mục đích: Bảo đảm hiệu suất hoạt động của hệ thống sản xuất không bị gián đoạn bởi các truy vấn dạng đặc biệt dạng phân tích. Các truy vấn loại này vốn có thời gian truy vấn lâu trên lượng dữ liệu lớn. Bảo đảm các thông tin không bị thay đổi trong khi người dùng cuối truy vấn. Kiến trúc kho dữ liệu Các kiến trúc chính Kiến trúc chung của một kho dữ liệu thường gồm nhiều vùng chứa dữ liệu (data store) nhỏ. Những vùng chứa dữ liệu này được phân loại dựa trên cấu trúc bao gồm (Building a DW – With examples in SQL Server – Trang 29-39): Vùng xử lí (staging area): Là vùng chứa dữ liệu chuẩn bị cho việc biến đổi dữ liệu thu được từ nguồn trước khi chuyển qua các vùng chứa dữ liệu khác trong kho dữ liệu. Trong các hình vẽ, vùng này được viết tắt là “staging” hay “STG”. Vùng chứa dữ liệu dạng chuẩn hoá (normalized data store): Là vùng chứa dữ liệu trung gian sau khi đã được biến đổi và tích hợp từ nhiều nguồn khác nhau. Trong vùng này, dữ liệu được lưu trữ ở dạng chuẩn cao, thường là dạng chuẩn 3. Dữ liệu trong vùng này đã sẵn sàng được nạp vào vùng kho dữ liệu đầu cuối mà không cần nhiều biến đổi phức tạp. Trong các hình vẽ, vùng này được viết tắt là NDS. Vùng chứa dữ liệu hoạt động (operational data store): Là vùng chứa dữ liệu dạng lai (hybrid) giữa vùng dữ liệu chuẩn hoá và cơ sở dữ liệu hoạt động (operational database). Mục đích của nó ngoài việc hỗ trợ cho việc nạp dữ liệu vào kho dữ liệu đầu cuối, còn được dùng như là cơ sở dữ liệu hoạt động tập trung (centralized). Kho dữ liệu đầu cuối, còn gọi là vùng dữ liệu đa chiều (dimesional data store): Là vùng kho dữ liệu đầu cuối, phía người dùng. Trong vùng này, dữ liệu được lưu trữ dưới dạng mô hình hoá đa chiều (dimensional modeling) nhằm hỗ trợ các ứng dụng hay truy vấn dạng phân tích đầu cuối. Trong các hình vẽ, vùng này được viết tắt là DDS, DW hay DWH. Kho dữ liệu có rất nhiều loại kiến trúc. Từ đơn giản nhất, chỉ gồm một kho dữ liệu đầu cuối, đến rất phức tạp, bao gồm nhiều kho dữ liệu trung gian, được sử dụng trong những hệ thống lớn. Tuy nhiên, hầu hết các kiến trúc đều dựa trên 3 kiến trúc chung phổ biến sau: Kiến trúc DDS đơn (single DDS) chỉ bao gồm kho dữ liệu đầu cuối và một vùng xử lí. Kiến trúc NDS+DDS là kiến trúc bao gồm vùng xử lí, vùng dữ liệu chuẩn hoá, và kho dữ liệu đầu cuối. Kiến trúc ODS+DDS tương tự như kiến trúc NDS+DDS nhưng sử dụng vùng dữ liệu hoạt động thay cho vùng dữ liệu chuẩn hoá. Mỗi kiến trúc đều có những ưu điểm và nhược điểm riêng. Sau đây, chúng ta sẽ phân tích sơ qua từng kiến trúc. Kiến trúc DDS đơn Hình 1.2.1.1-1: Kiến trúc kho dữ liệu dạng DDS đơn Kiến trúc DDS đơn là một trong những dạng kiến trúc đơn giản nhất của kho dữ liệu. Kiến trúc này có thành phần chính là một kho dữ liệu trung tâm. Dữ liệu từ nhiều hệ thống nguồn được nạp vào vùng xử lí thông qua một gói ETL (Extract-Transform-Load: Rút trích-Biến đổi-Nạp – Xem chương 3). Gói ETL này sẽ rút trích dữ liệu từ nhiều nguồn khác nhau, thực hiện một số phép biến đổi dữ liệu đơn giản. Dữ liệu sau đó được chứa trong vùng xử lí. Dữ liệu trong vùng xử lí sau khi được xử lí sơ bộ sẽ được biến đổi thông qua một gói ETL khác để đưa vào kho dữ liệu đầu cuối. Quá trình biến đổi này bao gồm nhiều công đoạn từ việc làm sạch, chuẩn hoá dữ liệu đến việc quản lí chất lượng và lịch sử thay đổi của dữ liệu. Kho dữ liệu đầu cuối chứa những dữ liệu đã được biến đổi, chuẩn hoá, và lưu trữ dưới dạng mô hình đa chiều, sẵn sàng phục vụ cho các ứng dụng đầu cuối. Ưu điểm: Kiến trúc đơn giản. Ít công đoạn xử lí. Thuận lợi khi xây dựng những kho dữ liệu nhỏ. Nhược điểm: Không hỗ trợ việc tạo ra nhiều kho dữ liệu phục vụ cho nhiều mục đích khác nhau dựa trên dữ liệu sẵn có. Nếu có nhu cầu chỉ cần sử dụng một phần của kho dữ liệu (data-mart) thì phải xây dựng một gói ETL khác phục vụ quá trình này. Không tái sử dụng được gói ETL đã làm. Mỗi một quy trình rút trích-biến đổi-nạp cho từng thành phần trong kho dữ liệu đầu cuối được thực hiện độc lập. Việc này gây khó khăn cho việc xây dựng những kho dữ liệu lớn. Kiến trúc NDS+DDS Hình 1.2.1.2-1: Kiến trúc kho dữ liệu dạng NDS+DDS Đây là một kiến trúc khá phổ biến. Kiến trúc này tương tự như kiến trúc DDS đơn, nhưng có thêm một vùng chứa dữ liệu trung gian là vùng chứa dữ liệu chuẩn hoá NDS. Dữ liệu sau khi được làm sạch, thay vì đưa thẳng vào kho dữ liệu đầu cuối, nó được lưu trong vùng chứa dữ liệu trung gian. Vùng chứa dữ liệu trung gian đóng vai trò như là một cơ sở dữ liệu tập trung, đã được chuẩn hoá, bao gồm cả dữ liệu lịch sử. Việc nạp vào kho dữ liệu đầu cuối sẽ không cần qua công đoạn làm sạch và quản lí chất lượng dữ liệu nữa. Ưu điểm: Lưu trữ dữ liệu tập trung đã được làm sạch. Chứa dữ liệu lịch sử. Sẵn sàng cho việc nạp vào nhiều kho dữ liệu đầu cuối. Tái sử dụng được các gói ETL. Nhược điểm: Kiến trúc phức tạp Tốn thêm không gian lưu trữ. Thời gian thực hiện một chu kì nạp dữ liệu lâu hơn so với kiến trúc DDS đơn. Vùng chứa dữ liệu trung gian không được tận dụng vào mục đích khác. Kiến trúc ODS+DDS Hình 1.2.1.3-1: Kiến trúc kho dữ liệu dạng ODS+DDS Kiến trúc này có nhiều điểm tương đồng với kiến trúc NDS+DDS. Như trong hình vẽ, thay vì sử dụng một vùng dữ liệu chuẩn hoá làm vùng dữ liệu trung gian, người ta sử dụng một vùng dữ liệu hoạt động thay cho nó. Vùng dữ liệu hoạt động này cũng là một cơ sở dữ liệu dạng chuẩn hoá cao. Tuy nhiên, nó không lưu dữ liệu lịch sử. Vùng dữ liệu hoạt động có cấu trúc nghiêng về dạng cơ sở dữ liệu phục vụ giao tác (OLTP) nhiều hơn. Nó đóng vai trò như là một cơ sở dữ liệu tập trung mà ở đó, ứng dụng đầu cuối cho phép khai thác trên nó. Có thể thấy những ưu điểm và nhược điểm của nó so với kiến trúc NDS+DDS như sau: Ưu điểm: Lưu trữ dữ liệu tập trung đã được làm sạch. Tận dụng làm cơ sở dữ liệu tập trung phục vụ giao tác cho ứng dụng đầu cuối. Nhược điểm: Không chứa dữ liệu lịch sử. Các gói ETL để đưa dữ liệu từ vùng dữ liệu hoạt động vào kho dữ liệu đầu cuối phức tạp hơn. Vùng dữ liệu hoạt động có thể bị gián đoạn khi nạp kho dữ liệu. Không tái sử dụng được các gói ETL. Trong nội dung của cuốn khoá luận này, nội dung sẽ tập trung vào kiến trúc NDS+DDS. Vùng xử lí Hình 1.2.2-1: Vùng xử lí Thông thường, trong tất cả các kiến trúc kho dữ liệu, luôn có một vùng chứa dữ liệu gọi là vùng xử lí. Dữ liệu được chuyển từ nhiều nguồn vào vùng xử lí mà không thông qua (hoặc rất ít) công đoạn xử lí nào. Hẳn nhiên, có thể nạp trực tiếp dữ liệu từ nguồn vào kho dữ liệu đầu cuối. Tuy vậy, việc sử dụng một vùng xử lí có các lợi ích sau: Giảm thiểu tối đa thời gian rút trích dữ liệu từ nguồn. Việc này nhằm tránh gián đoạn đến hoạt động của các cơ sở dữ liệu nguồn. Thông thường, người ta sẽ sao chép y nguyên dữ liệu nguồn vào vùng này. Khi sử dụng các vùng xử lí độc lập cho từng nguồn, cho phép thao tác trên một tập hợp nhỏ các dữ liệu mà ta cần sử dụng, thay vì truy vấn toàn bộ dữ liệu nguồn. Vùng xử lí nếu được cài đặt chỉ mục hợp lí, sẽ hỗ trợ việc nạp dữ liệu vào kho dữ liệu nhanh hơn. Vùng xử lí cho phép phục hồi sau sự cố. Dữ liệu khi đã được nạp vào vùng xử lí, có thể được xem là an toàn. Trong quá trình nạp dữ liệu vào kho dữ liệu, nếu bị gián đoạn do sự cố, quá trình nạp dữ liệu dễ dàng được phục hồi bằng cách nạp tiếp dữ liệu đang nạp từ vùng này. Bởi vì trong mỗi lần nạp, dữ liệu ở vùng xử lí không bị thay đổi, nên hoàn toàn không ảnh hưởng đến quá trình nạp. Nếu nạp trực tiếp từ nguồn, nơi dữ liệu thay đổi thường xuyên, quá trình nạp phải được làm lại từ đầu, bao gồm cả việc loại bỏ các dữ liệu đang nạp dở dang. Vùng xử lí có thể lưu trữ dữ liệu dài hạn, như là một cơ sở dữ liệu trung gian. Nhưng thông thường, người ta sẽ xoá đi sau mỗi lần nạp dữ liệu. Đặc biết đối với các kiến trúc cấp cao như NDS+DDS hay ODS+DDS, việc lưu trữ dữ liệu trong vùng xử lí sau mỗi công đoạn nạp là hoàn toàn không cần thiết. Cấu trúc của dữ liệu vùng xử lí như sau: Đối với dữ liệu nguồn là cơ sở dữ liệu: Dữ liệu trong vùng xử lí là tất cả các bảng chứ dữ liệu cần thiết cho việc nạp dữ liệu, nhưng chỉ chứa các cột dữ liệu cần thiết mà thôi. Các bảng được loại bỏ các ràng buộc khoá chính, khoá ngoại và chỉ mục. Việc này nhằm tăng tốc cho sao chép dữ liệu nguồn. Để tránh việc dữ liệu không nhất quán, các gói ETL cần được thiết kế cẩn thận để giải quyết việc này. Đối với dữ liệu nguồn là dạng tập tin: Đơn giản chỉ cần sao chép nó đến máy chủ. Cơ sở dữ liệu chuẩn hoá Hình 1.2.3-1: Cơ sở dữ liệu chuẩn hoá. Đối với kiến trúc NDS+DDS, vùng chứa dữ liệu dạng chuẩn hoá, còn được gọi là cơ sở dữ liệu chuẩn hoá đóng vai trò là một cơ sở dữ liệu tập trung. Cơ sở dữ liệu này có các đặc điểm sau: Là nơi tập trung dữ liệu từ nhiều nguồn. Tất cả dữ liệu này đều đã được làm sạch. Cơ sở dữ liệu được tổ chức ở dạng chuẩn hoá cao, nhằm bảo đảm chất lượng dữ liệu, các ràng buộc toàn vẹn trên dữ liệu cũng như tính nhất quá của dữ liệu. Các thông tin về lịch sử của dữ liệu được lưu lại toàn bộ ở đây. Nếu dữ liệu nguồn không chứa thông tin lịch sử, gói ETL dùng biến đổi dữ liệu vào cơ sở dữ liệu chuẩn hoá sẽ đảm nhận việc bổ sung các dữ liệu lịch sử. Thường là ngày tháng khi lấy dữ liệu. Nếu dữ liệu nguồn chứa thông tin lịch sử, gói ETL dùng biến đổi dữ liệu sẽ chuyển đổi các thông tin lịch sử tương ứng từ nguồn vào cơ sở dữ liệu chuẩn hoá. Các thông tin này cho phép nắm bắt lịch sử dữ liệu tại một nơi tập trung duy nhất. Cấu trúc của cơ sở dữ liệu chuẩn hoá rất gần với cấu trúc của kho dữ liệu đầu cuối, tuy nhiên được tổ chứ ở dạng chuẩn cao. Việc này giúp tăng tốc cho các tính toán số liệu trong khi nạp các dữ kiện vào kho dữ liệu. Dữ liệu sau mỗi lần nạp thành công vào cơ sở dữ liệu chuẩn hoá, sẽ được xoá trong vùng xử lí. Khi quá trình nạp dữ liệu bị gián đoạn, quá trình nạp dữ liệu được thực hiện tiếp tục trên những dữ liệu chưa được nạp thành công, tức là vẫn còn dữ liệu trên vùng xử lí. Kho dữ liệu đầu cuối Hình 1.2.4-1: Kho dữ liệu đầu cuối Trong một hệ thống kho dữ liệu, kho dữ liệu đầu cuối là thành phần quan trọng nhất, ở đó, dữ liệu được tổ chức theo một cấu trúc đặc biệt: mô hình đa chiều (dimensional). Đây là cấu trúc dạng tối ưu phục vụ truy vấn đầu cuối cho các ứng dụng phân tích như OLAP, khai thác dữ liệu, Đây là kiểu cấu trúc dựa trên mô hình khối đa chiều (multi-dimension cube). Mỗi khối đa chiều là bao gồm một bảng dữ kiện (fact) và các bảng chiều (dimension). Dữ kiện là các độ đo, các số liệu được tính toán từ các chiều. Cấu trúc dữ liệu này có đặc trưng là phi chuẩn hoá (denormalized). Đây là một đặc trưng quan trọng của kho dữ liệu mô hình hoá đa chiều. Cấu trúc và phương pháp mô hình hoá đa chiều được đề cập trong Chương 2 - Mô hình hoá sử dụng lược đồ hình sao. Nói một cách tóm tắt, kho dữ liệu đầu cuối nhằm mục đích sau: Tăng tốc tối đa thời gian truy vấn trên các dữ liệu dạng phân tích. Dữ liệu truy vấn trên kho dữ liệu cho tốc độ rất cao. Ở những hệ thống lớn, với nhiều nguồn dữ liệu, một câu truy vấn chạy trực tiếp trên dữ liệu nguồn có thể mất hàng giờ đồng hồ, nhưng khi chạy trên hệ thống kho dữ liệu chỉ mất vài phút. Việc rút ngắn thời gian như vậy là rất đáng kể. Ngoài ra, nó còn giúp hạn chế việc gián đoạn hoạt động của các hệ thống nguồn. Hỗ trợ phân tích các thay đổi mang tính lịch sử trên dữ liệu. Kho dữ liệu được tổ chức để theo dõi toàn bộ các thay đổi của dữ liệu. Vì vậy, các phân tích dữ liệu theo dòng thời gian là đặc biệt nhanh chóng và hiệu quả. Đối với những truy vấn có được phát biểu dưới dạng tương tự nhau, câu truy vấn SQL/MDX trên kho dữ liệu có rất ít khác biệt. Các truy vấn phát biểu dạng này cũng dễ hiểu và gần gũi người dùng cuối. Chẳng hạn: câu truy vấn “Tương quan tỉ lệ sinh viên đậu/rớt trong năm nay so với các năm trước?” và “Tương quan giữa thời gian sử dụng hệ thống học tập trực tuyến và điểm số của sinh viên?” là những câu truy vấn có cấu trúc tương tự nhau. Hỗ trợ xây dựng khối OLAP nhanh, hiệu quả. OLAP là một trong những ứng dụng đầu cuối phổ biến trong việc sử dụng hệ thống kho dữ liệu. Khối OLAP mặc dù có thể xây dựng trên cơ sở dữ liệu thông thường, nhưng nếu được xây dựng trên kho dữ liệu, sẽ giảm thiểu thời gian xây dựng khối và tăng tốc các truy vấn OLAP. Các thách thức đối với kho dữ liệu Việc xây dựng kho dữ liệu là một công việc phức tạp và đòi hỏi nhiều vấn đề cần được nghiên cứu kĩ càng trước khi cài đặt. Đối với kho dữ liệu, nhưng thách thức sau đây luôn được đặt lên hàng đầu: Chất lượng dữ liệu Thách thức lớn nhất là việc quản lí chất lượng dữ liệu. Bởi vì bản thân các hệ thống nguồn thường không bao giờ không bị lỗi trên dữ liệu, việc xây dựng kho dữ liệu bảo đảm cung cấp đầy đủ thông tin và nhiều ý nghĩa là liên hệ sống còn đến tính hiệu quả của kho dữ liệu. Quản lí chất lượng dữ liệu bao gồm: Dữ liệu trùng lắp: Xảy ra khi cùng một dữ liệu được ghi nhiều lần vào kho, nhưng không thể theo dõi được do thiếu các ràng buộc khoá. Dữ liệu không đầy đủ: Dữ liệu thiếu trong quá trình nhập liệu, chẳng hạn sinh viên thiếu thông tin về địa chỉ tạm trú/thường trú. Việc này làm giảm hiệu quả của các phân tích đầu cuối. Dữ liệu sai: Là trường hợp dữ liệu bị lỗi chẳng hạn như lỗi đánh máy, lỗi chính tả, chữ hoa, chữ thường Xung đột dữ liệu: Đây là trường hợp cùng một dữ liệu nhưng được lưu trữ trên nhiều bảng hoặc thậm chí nhiều nguồn khác nhau, nhưng không nhất quán. Siêu dữ liệu không rõ nghĩa: Thường là do cùng một đối tượng dữ liệu nhưng khác kiểu dữ liệu hoặc sai lệch về ngữ nghĩa của dữ liệu trên các nguồn khác nhau. Chẳng hạn cùng tên cột, cùng bảng, nhưng trên 2 nguồn khác nhau có ngữ nghĩa hoàn toàn khác nhau. Thiếu dữ liệu: Là trường hợp dữ liệu lẽ ra phải có để bảo đảm toàn vẹn (tham chiếu), nhưng không tìm thấy các dữ liệu này ở nơi khác. Dữ liệu NULL: Đây là dạng dữ liệu rất chung chung và tối nghĩa. Nó cần được dịch ra để phù hợp với ngữ cảnh. Khối lượng dữ liệu và hiệu suất hoạt động Nếu như lượng dữ liệu trung bình cho mỗi cơ sở dữ liệu khoảng vài đến vài chục Gigabyte, dữ liệu trong kho dữ liệu có thể lên đến vài chục Terabyte, thậm chí còn được tính bằng đơn vị Petabytes (1Petabytes = 1024Terabytes). Điều này là hoàn toàn dễ hiểu vì 2 lí do sau: Dữ liệu được mô hình hoá đa chiều, tổ chức dưới dạng phi chuẩn (denormalized) khiến cho khối lượng dữ liệu trùng lắp tăng đáng kể. Dữ liệu lịch sử được lưu lại ở mức chi tiết nhất có thể, theo thời gian, sẽ tăng lên rất nhanh. Đối với lượng dữ liệu lớn như vậy, các đề nghị sau cần được xem xét để tăng hiệu suất hoạt động cho kho: Xây dựng hệ thống vật lý độc lập nguồn: Việc này làm giảm tải xử lí cho hệ thống nguồn. Tuy rằng việc tổ chức trên cùng một hệ thống vật lí với hệ thống nguồn cho phép tăng thời gian nạp, ngược lại, lại làm giảm hiệu suất hoạt động của chính hệ thống nguồn. Hơn nữa, các hệ thống nguồn nằm rải rác thì không thể tổ chức một hệ thống kho dữ liệu phân tán trên đó được. Cài đặt chỉ mục: Hoạt động chính của kho dữ liệu là việc đọc dữ liệu hơn là ghi dữ liệu lên đó. Các câu truy vấn chủ yếu tốn thời gian ở việc tìm kiếm dữ liệu. Cài đặt chỉ mục hợp lí là phương pháp hiệu quả để tăng tốc truy vấn. Các truy vấn thường dùng cần được phân tích cho việc cài đặt chỉ mục. Chỉ mục dạng bitmap: Đây là dạng chỉ mục rất hiệu quả đối với những bảng có số lượng các giá trị rời rạc (cardinality) thấp. Xem xét việc cài đặt chỉ mục dạng này cũng làm tăng đáng kể hiệu suất truy vấn. Dữ liệu tổng hợp (Aggregation): Có thể xem xét việc tiền xử lí các dữ kiện, chẳng hạn như xây dựng các bảng trung gian, chứa các dữ liệu được tổng hợp (sum, count, average) ở độ mịn cao. Nắm bắt các thay đổi trên dữ liệu Việc nạp dữ liệu từ nguồn vào vùng xử lí thoạt nhìn có vẻ đơn giản. Nhưng không hẳn như vậy. Người ta không thể mỗi lần nạp dữ liệu đều sao chép toàn bộ dữ liệu từ nguồn vào vùng xử lí. Đây là việc làm rất tốn kém và không hiệu quả. Thay vào đó, người ta cố gắng nắm bắt được các thay đổi trên dữ liệu, bao gồm các dữ liệu mới và các dữ liệu cũ vừa bị thay đổi. Có 4 kĩ thuật nắm bắt thay đổi dữ liệu nguồn, được chia làm 2 loại chính: Kĩ thuật xâm nhập (intrusive): Là các kĩ thuật ở đó cần thực hiện truy vấn trên dữ liệu nguồn mà gây ảnh hưởng đến hiệu suất hoạt động của nó. Bao gồm: Nắm bắt thay đổi dựa trên dữ liệu nguồn: Là kĩ thuật nắm bắt thay đổi dựa trên chính các thuộc tính trong dữ liệu nguồn. Dựa trên nhãn thời gian: dựa vào các nhãn thời gian có sẵn trên dữ liệu nguồn như nhãn thêm, nhãn sửa Dựa trên định danh tự động tăng: chỉ nắm bắt được thay đổi của dữ liệu mới. Nắm bắt thay đổi dựa trên trigger: Bằng cách cài đặt thêm trigger vào cơ sở dữ liệu nguồn. Các dữ liệu lịch sử này được lưu riêng, cho phép hệ thống kho dữ liệu truy vấn để rút trích dữ liệu mới hoặc đã thay đổi. Nắm bắt thay đổi dựa trên ảnh chụp dữ liệu (snapshot): Đây là kĩ thuật mà ở đó, vùng xử lí lưu lại toàn bộ dữ liệu của lần nạp trước như là một ảnh chụp dữ liệu. Dữ liệu ở lần nạp sau được so sánh với dữ liệu trước để so sánh thay đổi trước khi quyết định sẽ lấy dữ liệu nào. Kĩ thuật này được sử dụng đối với dữ liệu nguồn thiếu thông tin lịch sử, và tránh việc phải thay đổi hệ thống nguồn (bằng trigger). Kĩ thuật phi xâm nhập (non-intrusive): Là các kĩ thuật không gây ảnh hưởng đến hiệu suất hoạt độn của dữ liệu nguồn. Nắm bắt thay đổi dựa trên log: Trên mỗi hệ thống nguồn, có thể sử dụng có sẵn (đối với cơ sở dữ liệu) hay cài đặt một chương trình ghi log, quản lí toàn bộ lịch sử thay đổi của nguồn. Yêu cầu người dùng thay đổi Cũng giống như mọi dự án phần mềm khác, việc xây dựng hệ thống có thể bảo đảm được cho việc thay đổi yêu cầu người dùng trong tương lai là thách thức rất lớn. Các xu hướng xây dựng kho dữ liệu Kho dữ liệu ảo Kho dữ liệu thời gian thực Kho dữ liệu phân tích Mô hình hoá sử dụng lược đồ hình sao Như đã đề cập ở chương 1, việc tối ưu hoá tốc truy vấn cho kho dữ liệu là điều kiện tiên quyết cho hiệu quả triển khai một dự án kho dữ liệu. Vì vậy cấu trúc cơ sở dữ liệu của kho dữ liệu cần được tổ chức theo một mô hình đặc trưng riêng. Đó là phương pháp mô hình hoá đa chiều. So sánh phương pháp mô hình hoá của Bill Inmon và Ralph Kimball Việc tổ chức dữ liệu trong cơ sở dữ liệu của kho dữ liệu được tiếp cận theo 2 hướng sau: Phương pháp mô hình hoá dạng chuẩn hoá của Bill Inmon (lược đồ bông tuyết): Cơ sở dữ liệu được tổ chức dưới dạng chuẩn hoá, tuân theo luật chuẩn hoá như đối với cơ sở dữ liệu quan hệ thông thường (dạng chuẩn 3). Ưu điểm: Dữ liệu được nạp từ nguồn vào đích dễ dàng. Dạng chuẩn cao giúp bảo đảm các ràng buộc toàn vẹn của dữ liệu, tránh trùng lắp. Nhược điểm: Việc kết các bảng để cho ra kết quả truy vấn mong muốn phức tạp Đòi hỏi người dùng phải hiểu được cấu trúc tổ bên dưới của kho dữ liệu. Tốc độ truy vấn chậm do việc kết các bảng có kích thước lớn. Phương pháp mô hình hoá đa chiều của Ralph Kimball (lược đồ hình sao): Cơ sở dữ liệu được lưu trữ dưới dạng phi chuẩn hoá. Bao gồm bảng dữ kiện (fact) chứa thông tin các giao tác và các bảng chiều (dimension) đóng vai trò như là bảng tham chiếu lấy thông tin. Các bảng này đều được lưu dưới dạng chuẩn thấp (dạng chuẩn 1 hoặc 2) Ưu điểm: Truy vấn người dùng cuối dễ dàng được thực hiện mà không đòi hỏi người dùng phải hiểu rõ về cấu trúc của kho dữ liệu. Thiết kế hướng nghiệp vụ, là ánh xạ trực tiếp từ quy trình nghiệp vụ của doanh nghiệp. Tốc độ truy vấn cao. Nhược điểm: Dữ liệu nguồn cần phải được phi chuẩn hoá (denormalized) và bảo đảm ràng buộc toàn vẹn trong quá trình nạp dữ liệu vào kho. Trùng lắp dữ liệu nhiều, khiến cho kích thước kho lớn (Trong điều kiện công nghệ hiện nay, đây không hẳn là một trở ngại lớn!) Xu hướng hiện tại, đa số các dự án trên kho dữ liệu được cài đặt dưới dạng mô hình hoá đa chiều bằng lược đồ hình sao do hiệu suất hoạt động vượt trội của nó. Các nhược điểm của mô hình dạng này không phải là trở ngại lớn. Trong nội dung của luận văn này, chúng ta chỉ bàn đến các thiết kế dựa trên lược đồ hình sao. Lược đồ hình sao Như đã nói ở trên, phương pháp mô hình hoá đa chiều với lược đồ hình sao thể hiện những ưu điểm vượt trội của mình. Bởi vì kho dữ liệu được thiết kế cho mục đích đọc nhiều hơn là ghi trên nó, đặc biệt, nó không phải là cơ sở dữ liệu phục vụ giao tác (OLTP), việc tránh dư thừa dữ liệu là không cần thiết. Hình 2.2-1: Lược đồ hình sao. Lược đồ hình sao được gọi theo mô hình của nó. Như mô tả trong hình vẽ, lược đồ hình sao bao gồm một bảng trung tâm gọi là bảng dữ kiện. Bảng này tham chiếu đến các bảng xung quanh, gọi là bảng chiều. Bảng chiều và bảng dữ kiện Để hiểu một cách đơn giản cho khái niệm bảng chiều và bảng dữ kiện, ta hãy xem xét ví dụ sau: Hệ thống của trường ghi lại việc “Một sinh viên SV vào trang web Moodle của khoa để xem thông tin của một môn học MH vào lúc 12h trưa ngày 06/06/2006, thời gian truy cập 60 giây.” Ta xem mỗi lần sinh viên vào trang web môn học được xem như một giao tác. Như vậy, hệ thống đã ghi nhận có một giao tác, liên quan đến các đối tượng sau: Sinh viên SV Môn học MH, 12h trưa Ngày 06/06/2006 Ở đây, ta có một ngữ cảnh liên quan đến 4 đối tượng trên, và một con số đo thời gian 60 giây. Các đối tượng tham gia vào giao tác, hay là ngữ cảnh của giao tác đó, được gọi là chiều. Con số thể hiện một độ đo của một giao tác gọi là dữ kiện của giao tác đó. Ở đây, con số 60giây là dữ kiện của giao tác truy cập trang web trên. Ta có thể vẽ một lược đồ hình sao như sau: Hình 2.2.1-1: Ví dụ lược đồ hình sao Các đặc trưng của lược đồ hình sao Xem xét cấu trúc một lược đồ hình sao như sau: Hình 2.2.2-1: Cấu trúc lược đồ hình sao Tất cả các dòng trong bảng dữ kiện được lưu với độ mịn thấp nhất có thể. Độ mịn là mức độ chi tiết của dữ liệu. Một dữ kiện được tính theo ngày có độ mịn thấp hơn dữ kiện được tính theo giờ Độ mịn của dữ kiện được xác định bằng độ mịn của các chiều liên quan. Tất cả các độ đo trong bảng dữ kiện có thể được cuộn lên (roll-up) hoặc gom nhóm theo chiều. Chẳng hạn có thể tính doanh thu theo tháng, năm, gom nhóm theo sản phẩm, Truy vấn trên lược đồ hình sao (Cần bổ sung các so sánh truy vấn giữa lược đồ hình sao và lược đồ chuẩn hoá) Kiến trúc buýt Để đưa ra thiết kế chính xác cho kho dữ liệu, người ta sử dụng ma trận kiến buýt (bus matrix) (Ralph Kimball - The Data Warehouse Toolkit). Đây là một bảng mô tả mối liên hệ giữa các nghiệp vụ với các đối tượng liên quan. Hình 2.4-1: Ma trận kiến trúc buýt Bảng trên đây mô tả mối liên hệ giữa các nghiệp vụ: Các dòng: Thể hiện các nghiệp vụ Các cột: Thể hiện các đối tượng Các ô: Mô tả một đối tượng có liên quan đến nghiệp vụ đó hay không. Bằng việc phân tích yêu cầu người dùng và đưa ra được ma trận kiến trúc buýt, có thể dễ dàng xây dựng lược đồ hình sao cho kho dữ liệu trong dó: Các dòng: Là các bảng dữ kiện. Các cột: Là các bảng chiều. Chú ý rằng các bảng dữ kiện khác nhau có thể cùng tham chiếu đến một chiều. Các chiều này được gọi là các chiều chuẩn (conformed dimension) Các nguyên tắc thiết kế Có một số nguyên tắc chung khi thiết kế kho dữ liệu như sau: Sử dụng khoá đại diện: Thông thường, mỗi bảng đều có một khoá chính dùng định danh cho từng dòng của nó. Khoá này có thể tạo bởi 1 hay nhiều cột. Trong dữ liệu nguồn, khoá này là không thống nhất, và có thể mang nhiều kiểu khác nhau, cũng có thể được tạo tự động bởi cơ sở dữ liệu nguồn. Chẳng hạn môn học TTH-294 là một khoá chính. Trong kho dữ liệu, khoá này gọi là khoá tự nhiên. Vì những lí do trên đây, khoá tự nhiên của dữ liệu nguồn không thể được sử dụng trong một hệ thống chung của kho dữ liệu. Thay vào đó, người ta sử dụng khoá đại diện, với các đặc điểm sau: Chỉ bao gồm 1 cột: Đơn giản cho phép kết Là số nguyên không âm: Tăng tốc cho việc đánh số chỉ mục và kết bảng Tạo bởi gói ETL trong lúc nạp dữ liệu: Thống nhất giữa nhiều nguồn dữ liệu. Quy tắc đặt tên và kiểu Để dễ hiểu cho người dùng cuối trong khi truy vấn, người ta sử dụng các quy tắc sau: Đặt tên bảng có chứa tiền tố (fct_ cho bảng dữ kiện, dim_ cho bảng chiều, lkp_ cho bảng tìm kiếm) Tất cả các khoá của chiều được đặt tên theo tên bảng với hậu tố _key Tất cả khoá của các chiều sử dụng số nguyên không âm nhỏ nhất có thể. Tên của các cột phải có ý nghĩa, tránh viết tắt. Sử dụng những tên chuẩn cho các cột theo dõi (xem mục 2.5.4) Độ mịn và mức tổng hợp Đối với việc lưu dữ liệu ở nhiều độ mịn, quy tắc duy nhất: Lưu với độ mịn thấp nhất có thể. Đối với việc tổng hợp dữ liệu: Tất cả các dữ kiện có nhu cầu truy xuất trong khi truy vấn cần được tính toán sẵn ở mức thấp nhất. Tránh việc phải tính toán lại trong quá trình truy vấn đầu cuối. Chẳng hạn: Truy vấn đầu cuối có mục tiêu phải tính được thời gian truy cập của từng lượt truy cập, trong khi dữ liệu nguồn chỉ lưu thời gian bắt đầu và kết thúc của một truy cập. Như vậy, cần phải tính sẵn thời gian truy cập để lưu vào bảng dữ kiện thay vì lưu thời gian bắt đầu và kết thúc riêng! Ngày giờ Thời gian là một đối tượng đặc biệt trong kho dữ liệu. Chi tiết việc nạp chiều thời gian (bao gồm ngày và giờ) được mô tả trong Chương 3 – Tích hợp dữ liệu. Một số chú ý sau: Độ mịn được đặt ở mức thấp nhất có thể theo yêu cầu của người dùng. Lưu riêng ngày và giờ trong ngày thành 2 chiều khác nhau. Sử dụng giờ chuẩn quốc tế. Sử dụng khoá thông minh cho ngày giờ, với định dạng: YYYYMMDD hay HHMMSS. Ở đây ta không sử dụng khoá đại diện vì việc sử dụng khoá chính cho chiều thời gian cho phép phân vùng (partitioning) dữ liệu theo thời gian. Hơn nữa, chiều thời gian là chiều được nạp độc lập với các chiều khác. Khoá vô danh Mỗi bảng chiều có một dòng với khoá đại diện là 0, các trường khác đặt giá trị mặc định. Dòng này mô tả trạng thái nạp một dữ kiện vào bảng dữ kiện nhưng không tìm thấy đối tượng tương ứng với dữ kiện đó trong chiều mà nó tham chiếu tới. Việc này giúp tránh dữ liệu NULL ở khoá ngoại bảng dữ kiện, đồng thời mang ý nghĩa rõ ràng cho người dùng cuối rằng: “không tìm thấy đối tượng liên quan đến ngữ cảnh đang có!” Tích hợp dữ liệu Khái niệm Hệ thống tích hợp dữ liệu, hay còn gọi là hệ thống ETL (Extract-Load-Transform) là một hệ thống được thiết kế để làm các nhiệm vụ sau: Kết xuất dữ liệu từ các hệ thống nguồn. Kiểm tra chất lượng dữ liệu và các tiêu chuẩn toàn vẹn. Biến đổi dữ liệu để dữ liệu từ nhiều hệ thống có thể được sử dụng cùng nhau. Nạp dữ liệu vào một dạng trung gian cho phép các nhà phát triển cho thể xây dựng ứng dụng và người dùng cuối có thể ra quyết định dựa trên dữ liệu và ứng dụng đó. Các bước tiến hành của quá trình tích hợp dữ liệu Kết xuất dữ liệu: Một công ty hoặc tổ chức thông thường cần nhiều hệ thống tin học để điều khiển hoạt động của mình. Ví dụ: hệ thống quản lý bán hàng, quản lý kho, quản lý nhân viên, quản lý sản phẩm... Những hệ thống này có thể không tương thích về mặt logic hoặc vật lý, điều này gây ra những khó khăn cho việc tích hợp dữ liệu. Những khó khăn đó có thể do các hệ thống khác nhau về: Hệ quản trị CSDL. Hệ điều hành. Phần cứng. Các giao thức truyền thông tin giữa nguồn dữ liệu và bên ngoài. Như vậy, với những nguồn dữ liệu khác nhau, để tích hợp dữ liệu vào kho dữ liệu, ta phải xây dựng các quy tắc ánh xạ dữ liệu từ dữ liệu nguồn đến kho dữ liệu. Với kiến trúc và tính chất của nguồn dữ liệu khác nhau, đòi hỏi phải xây dựng một bảng ánh xạ vật lý từ dữ liệu được lưu trữ ở nguồn đến kho dữ liệu. Trước khi xây dựng một bảng ánh xạ vật lý, ta cần một bảng ánh xạ dữ liệu logic từ các trường của nguồn dữ liệu đến các trường của bảng trong kho dữ liệu. Cấu trúc của một bảng ánh xạ dữ liệu logic phải bao gồm các thông tin sau: + Tên bảng đích: tên vật lý của bảng trong kho dữ liệu. + Tên cột đích: tên cột trong bảng trong kho dữ liệu. + Loại bảng: xác định đó là bảng fact, bảng chiều hay bảng chiều con. + SCD: xác định loại chiều thay đổi chậm (Slowly Changing Dimension), dùng để lưu lịch sử dữ liệu. + CSDL nguồn: tên CSDL phía nguồn. + Tên bảng nguồn: tên bảng phía nguồn. + Tên cột nguồn: tên cột trong bảng phía nguồn. + Biến đổi: cách xử lý logic đối với dữ liệu nguồn để đưa về cùng định dạng với dữ liệu đích. Phép biến đổi này thường được viết bằng mã giả SQL. Ví dụ về bảng ánh xạ dữ liệu logic: Hình 1 Để có được một bảng ánh xạ dữ liệu logic như vậy, sau khi hoàn tất công đoạn phân tích yêu cầu và thiết kế kho dữ liệu, ta phải tìm hiểu và nhận dạng các hệ thống nguồn đáp ứng các yêu cầu dữ liệu của kho dữ liệu, phân tích cấu trúc của hệ thống nguồn đó thông qua lược đồ CSDL, xác định các khóa, loại dữ liệu, mối quan hệ giữa các bảng,... và phân tích chính bản thân dữ liệu để tìm hiểu các lỗi tiềm tàng của dữ liệu và cách khắc phục. Ví dụ: + Ý nghĩa và cách khắc phục đối với các trường dữ liệu null + Các trường ngày tháng không đúng định dạng chuẩn. Sau khi hoàn tất bảng ánh xạ dữ liệu logic, ta sẽ xây dựng bảng ánh xạ dữ liệu vật lý dựa trên kiến trúc, cách lưu trữ và cấu trúc của dữ liệu nguồn và dữ liệu đích. Trong phạm vi của khóa luận, nhóm chỉ tiến hành tìm hiểu trên các nguồn dữ liệu khác nhau về cấu trúc và cách lưu trữ. Cụ thể là tích hợp dữ liệu trên nhiều CSDL và tập tin khác nhau. Trong quá trình tích hợp dữ liệu, việc lấy tất cả dữ liệu từ nguồn rất mất thời gian và không cần thiết, do đó ta chỉ lấy những dữ liệu mới từ nguồn mà kho dữ liệu chưa cập nhật hoặc những dữ liệu được thay đổi ở nguồn sau khi cập nhật vào kho dữ liệu. Quá trình lấy dữ liệu như vậy được gọi là lắng nghe và kết xuất dữ liệu thay đổi. Có nhiều phương pháp để nhận biết sự thay đổi ở dữ liệu nguồn để cập nhật vào kho dữ liệu. Sau đây là các phương pháp thường được sử dụng: + Sử dụng cột kiểm tra (audit columns): được thêm vào cuối của mỗi bảng để lưu dữ liệu về ngày giờ cập nhật hoặc điều chỉnh một dòng dữ liệu. Dữ liệu của cột kiểm tra này thường được cập nhật bởi trigger hoặc ứng dụng người dùng cuối. Rủi ro của phương pháp này là kho dữ liệu có thể cập nhật thiếu dữ liệu nếu cột kiểm tra bị cập nhật sai. + Sử dụng log scraping và sniffing: sử dụng các bảng log của các giao tác làm thay đổi dữ liệu để kiểm tra sự thay đổi. + Sử dụng các kết xuất thời gian: cũng giống như phương pháp sử dụng cột kiểm tra, phuoưng pháp này sử dụng trường ngày tạo (hoặc cập nhật) để lấy dữ liệu mới thêm vào theo chu kỳ. Ví dụ: lấy dữ liệu theo chu kỳ là 1 ngày thì lúc lấy dữ liệu sẽ chọn hết tất cả những dòng dữ liệu có ngày tạo (hoặc ngày cập nhật) là ngày trước ngày cập nhật một ngày. Rủi ro của phương pháp này là nếu quá trình kết xuất dữ liệu bị lỗi vào một ngày nào đó thì dữ liệu ngày đó sẽ không bào giờ được lấy lại nữa, do vậy cần có các cơ chế lấy lại dữ liệu trong những trường hợp lỗi.   + Kỹ thuật loại trừ: lưu một bản sao của phiên bản trước vào vùng lưu trữ (staging area), khi kết xuất dữ liệu từ nguồn, ta chỉ tìm các dòng dữ liệu chưa có trong vùng lưu trữ (dựa vào khóa) hoặc đã bị thay đổi so với dữ liệu trong vùng lưu trữ. Biến đổi dữ liệu: Biến đổi dữ liệu thực chất là việc kiểm tra dữ liệu và đề ra các tiêu chuẩn cho biết dữ liệu có thể được sử dụng trong kho dữ liệu hay không và đưa ra các giải pháp biến đổi phù hợp. Dữ liệu được đưa vào data warehouse phải là dữ liệu chính xác. Tính chính xác được hiểu là dữ liệu phải có những tính chất sau: + Đúng đắn: dữ liệu phải mô tả trung thực đối tượng mà nó phản ánh. Ví dụ: dữ liệu mô tả những căn nhà ở Tp.Hồ Chí Minh thì bắt buộc trong địa chỉ phải chứa tên thành phố là Hồ Chí Minh. + Không mơ hồ: xác định rõ ý nghĩa của đối tượng được mô tả. Ví dụ: dữ liệu về dân số ở quận Thủ Đức, Tp Hồ Chí Minh. Nếu trong địa chỉ chỉ xác định là quận Thủ Đức, thì nó có thể là một địa danh khác ở đâu đó, điều này gây ra mơ hồ, không rõ nghĩa. + Nhất quán: các giá trị và mô tả dữ liệu phải sử dụng một quy ước thống nhất để biểu diễn. Ví dụ Tp Hồ Chí Minh, nếu quy ước viết tắt là Tp.HCM, thì trong tất cả các thể hiện của CSDL Tp Hồ Chí Minh đều phải được biểu diễn là Tp.HCM + Đầy đủ: thể hiện ở hai điểm: các trường dữ liệu không phải là null và các giá trị suy biến phản ánh đầy đủ và chính xác. Như vậy, vệc cần phải làm ở giai đoạn biến đổi dữ liệu là phải phát hiện dữ liệu không chính xác để có bước xử lý thích hợp. Và để đánh giá chất lượng dữ liệu, người ta dựa vào các độ đo chất lượng dữ liệu. Yếu tố đầu tiên cần được xây dựng trong quá trình làm sạch dữ liệu là một bảng fact gọi là bảng sự kiện lỗi (error event table) và các chiều của nó. Mỗi một lỗi hay vấn đề phát sinh trong quá trình làm sạch dữ liệu được lưu thành một dòng trong bảng fact. Lược đồ của bảng sự kiện lỗi: Hình 2 + Chiều ngày tháng (date dimension) là chiều chuẩn đại diện cho trường ngày tháng. + Chiều screen chứa thông tin về bước kiểm tra chất lượng dữ liệu (thông thường việc kiểm tra tính đúng đắn của dữ liệu được chia ra làm nhiều bước, mỗi bước được gọi là một screen). Mục đích của bảng này để mô tả screen đó làm gì và được áp dụng khi nào, ngoài ra còn có các định nghĩa về các lỗi thường gặp, cách ứng phó khi gặp lỗi (cho qua, từ chối dữ liệu hay dừng toàn bộ hệ thống để phân tích lỗi)và độ nghiêm trọng của lỗi (severity score),... + Chiều khối (batch) chứa thông tin về khối dữ liệu và dòng (row) dữ liệu sinh ra lỗi trong khối đó. Người ta thường phân loại việc kiểm tra chất lượng dữ liệu thành 4 nhóm: + Kiểm tra theo cột thuộc tính: bao gồm các bước kiểm tra giá trị null trong những cột yêu cầu giá trị, kiểm tra giá trị số nằm ngoài khoảng quy ước, độ dài của trường quá dài hoặc quá ngắn (không mong đợi), kiểm tra giá trị cột ngoài tập giá trị định sẵn hoặc không theo khuôn mẫu, kiểm tra lỗi chính tả.   + Kiểm tra theo cấu trúc dữ liệu: kiểm tra các bảng dữ liệu có các khóa chính và khóa tham chiếu đảm bảo ràng buộc tham chiếu. + Kiểm tra dữ liệu có đúng với các quy tắc nghiệp vụ hay giá trị của dữ liệu suy biến có đúng hay không. Sơ đồ mô tả việc kiểm tra dữ liệu qua các screen: Hình 3 Để nâng cao tốc độ kiểm tra tính đúng đắn của dữ liệu, người ta tìm cách lập lịch để các screen có thể chạy song song. Nạp dữ liệu Ở giai đoạn này, hệ thống ETL sẽ chuyển dữ liệu đã được kết xuất và xử lý đến data warehouse. Dữ liệu đã được xử lý không chỉ là cơ sở dữ liệu mà còn là các dạng dữ liệu khác như flat file, tài liệu XML, bảng tính,... Yêu cầu của giai đoạn này thay đổi đối với mỗi hệ thống. Hệ thống có thể lựa chọn ghi đè dữ liệu theo từng tuần hoặc theo giờ. Các hệ thống phức tạp hơn có thể lưu các lịch sử dữ liệu thay đổi trong data warehouse. Cấu trúc chiều: Tất cả các chiều cần được tổ chức vật lí sao cho có ít thành phần nhất có thể. Người ta thường gắn thêm một thuộc tính không có ý nghĩa thực tế để làm khoá đại diện (surrogate) bên cạnh khoá tự nhiên (natural key) của nó. Cấu trúc của một chiều thông thường như sau: Bình thường, với mỗi khoá tự nhiên sẽ ứng với một khoá đại diện (1-1), nhưng khi cần theo dõi dữ liệu mang tính lịch sử, mỗi khoá tự nhiên có thể ứng với nhiều khoá đại diện (xem SCD Type 2 sẽ được đề cập bên dưới) Các thuộc tính trong mỗi chiều thường không chứa số. Vì các thuộc tính mang giá trị số hầu như chắc chắn là các fact. Trong khoảng 2% các trường hợp, có thể rất khó đưa ra quyết định một trường chứa giá trị số thực ra có phải là fact hay không (ví dụ giá sản phẩm). Trong trường hợp này, cần xác định: Yêu cầu người dùng Thuộc tính này có phải dạng SCD Type 2 hay không (nếu là SCD Type 2, đây là fact) Nạp các chiều phẳng và các chiều bông tuyết: Nếu như bước làm sạch dữ liệu, dữ liệu vẫn được giữ ở dạng chuẩn cao (dạng bông tuyết) để bảo đảm tính nhất quán, thì ở bước nạp dữ liệu, dữ liệu sẽ được giảm dạng chuẩn (dạng phẳng) để giúp tăng tối đa tốc độ truy vấn và kết xuất dữ liệu. Vì thế, người ta thường cố gắng tránh tổ chức các chiều dạng bông tuyết. Dữ liệu có phân cấp theo nhiều cách khác nhau đối với cùng một chiều (chẳng hạn chiều sản phẩm phân cấp theo vùng địa lí hay theo vùng tiếp thị). Để làm phẳng, mọi thuộc tính liên quan đến các cách phân cấp này đều được lưu trong cùng một chiều. Chiều thời gian (bao gồm cả ngày-tháng): Đây là một chiều rất quan trọng vì được dùng hầu như trong mọi bảng fact. Bởi vì tính chất quan trọng của nó, chiều thời gian thường được tổ chức đặc biệt và không có nguồn nhập. Chiều này thường được dùng chung (dạng tham chiếu) cho nhiều chiều khác. Cấu trúc của chiều thời gian thường tổ chức như sau: Có một số chú ý sau đối với chiều thời gian: Chiều thời gian thường được phân vùng vật lý do tính chất lịch sử của nó. Việc này làm tăng tốc độ cập nhật của dữ liệu. Chiều ngày-tháng thường là một bảng vật lí cơ bản. Nếu cần chiều tháng, sẽ sử dụng khoảng chặn ngày đầu tháng-cuối tháng để tổ chức. Nếu cần tính chi tiết ở mức giờ, phút, giây, để bảo đảm không bị tràn, người ta thường sử dụng thêm một thuộc tính nhãn thời gian. Các chiều lớn: thường là các chiều được tạo thành từ nhiều nguồn, nhiều hệ thống khác nhau, do nhu cầu cần phải dữ lại quá nhiều thông tin. Để giảm kích thước các chiều lớn, người ta cần làm các bước sau: Loại bỏ trùng lắp Chuẩn hoá dữ liệu Hợp nhất Quá trình này được mô tả trong hình sau: Vấn đề lựa chọn phân tách/hợp nhất chiều: Nếu hai chiều có tương quan với nhau, người ta thường cố gắng tổ chức thành hai chiều độc lập và sử dụng bảng fact để mô tả mối tương quan đó, thay vì hợp nhất thành một chiều. Nếu việc roll-up một chiều cho ra chiều còn lại (chẳng hạn product và brand), thì nhất thiết không được tách thành hai chiều. Các trường hợp còn lại, cần cân nhắc yêu cầu của người dùng. Chiều nhập vai (role-playing dimension): Là chiều được gắn nhiều lần vào cùng một bảng fact nhưng với các vai trò khác nhau. Ví dụ điển hình là chiều thời gian. Đối với chiều nhập vai, người ta thường tổ chức một chiều. Các chiều tham chiếu từ bảng fact là các view được tạo ra từ chiều chung đó. Nạp các chiều suy biến: Chiều suy biến là chiều dẫn xuất từ bảng fact mà không chứa thuộc tính nào (còn gọi là chiều rỗng). Chiều suy biến thường chỉ chứa một khoá tự nhiên để lưu vết các giao tác. Nạp các chiều thay đổi chậm (Slowly Changing Dimension – SCD): Là chiều có thuộc tính thay đổi giá trị rất chậm theo thời gian vì một lí do nào đó. Có 3 loại: SCD loại 1 (ghi đè): đây là loại chiều không cần lưu lại lịch sử thay đổi. Chỉ việc ghi đè lên bản ghi cũ. SCD loại 2 (dữ liệu lịch sử hết hiệu lực): đây là loại chiều cần lưu lại lịch sử. Thay vì ghi đè lên chiều cũ, người ta tạo ra một dòng mới với cùng khoá tự nhiên nhưng khác khoá đại diện. Lúc đó, chỉ cần thay đổi tham chiếu từ bảng fact. SCD loại 3 (dữ liệu lịch sử còn hiệu lực): đây là trường hợp các giá trị lịch sử vẫn còn hiệu lực sử dụng đồng thời với các giá trị mới. Thay vì tạo thêm một dòng mới trong bảng chiều, người ta tạo thêm các cột mới để lưu vết. Thông thường, người ta tránh sử dụng loại 2 vì nó làm thay đổi cấu trúc của hệ thống. Hơn nữa, việc xác định tính hiệu lực của dữ liệu thường được quy định trong nghiệp vụ và được lưu như là một thuộc tính bình thường của chiều đó. Nạp chiều đến sau và sửa lỗi dữ liệu: Dữ liệu đến sau là những dữ liệu thay đổi sau khi đã xây dựng DW. Dữ liệu này phân ra làm 2 loại: Dữ liệu cần sửa đổi: do phát hiện sai sót (về thời gian) trong quá trình xây dựng DW. Dữ liệu cập nhật theo thời gian thực: do tính chất thời gian thực, dữ liệu đang được truy vấn là dữ liệu cũ, và dữ liệu được cập nhật là dữ liệu mới nhưng chưa được nạp vào hệ thống. (xem phần 4) Các chiều đến sau cần được nạp vào DW bằng một hệ thống ETL độc lập và cần được kiểm tra kĩ trên hệ thống thử nghiệm vì việc này ảnh hưởng sâu sắc đến hệ thống. Dữ liệu cần sửa đổi do phát hiện lỗi sai (về thời gian) được sửa theo 3 bước sau: Thêm một bản ghi mới với các thông tin cập nhật cho thuộc tính tương ứng, ứng với mốc thời gian cần thay đổi. Xác định từ mốc thời gian đó, tất cả các thay đổi xảy ra về sau nó và ghi đè bằng các giá trị mới của thuộc tính Cập nhật lại khoá ngoại cho bảng fact tất cả các bản ghi tham chiếu đến các bản ghi đã thay đổi trong chiều đó. Nạp chiều đa giá trị và bảng cầu nối: Các chiều đa giá trị là các chiều có quan hệ n-n đến bảng fact. Trong trường hợp này, cần phải tạo bảng cầu nối và bảng phân nhóm (để tránh quan hệ n-n đến bảng fact). Ví dụ: Nạp các chiều phân cấp không đều (Ragged Hierarchies): Các chiều phân cấp không đều là các chiều được phân cấp cha-con theo độ sâu không xác định. Ví dụ: nhân viên-quản lí. Để giải quyết dạng cây phân cấp này, có 2 giải pháp: Đệ quy: Đây là cách tổ chức trực quan, quen thuộc đối với CSDL quan hệ thông thường. Ưu điểm: Toàn bộ cây phân cấp được tổ chức chỉ trong một chiều. Việc quản lí (di chuyển, thay đổi) trong cây phân cấp được thực hiện dễ dàng Nhược điểm: Câu SQL truy vấn phức tạp và hiệu suất kém Chỉ có thể thể hiện được cây phân cấp mà mỗi con chỉ có 1 cha Nếu một chiều tồn tại nhiều cách phân cấp, không thể chuyển đổi được giữa các cách phân cấp này Nếu chiều này là SCD loại 2, việc quản lí là rất khó khăn. Bảng cầu nối phân cấp: Ưu điểm: Dễ dàng truy vấn với SQL Dễ dàng tổng quát hoá cho những cây phức tạp Cho phép chuyển đổi giữa các dạng phân cấp. Dễ dàng thích ứng với SCD loại 2 Nhược điểm Cần biểu diễn mọi quan hệ cha-con (đa cấp) trong cây. Do đó số bản ghi trong bảng cầu nối rất lớn. Không trực quan như kiểu đệ quy Khi áp dụng SCD loại 2 đối với chiều, cần cập nhật bảng cầu nối. Nạp chiều văn bản đối với dạng fact văn bản: Đôi lúc có những yêu cầu mà ở đó fact là dạng text. Chẳng hạn khi quy định điểm số dạng A, B, C, D. Đối với trường hợp này, để theo dõi các thay đổi để đưa ra giá trị fact liên quan, người ta chọn hướng tiếp cận tương tự với SCD loại 3. Các vấn đề gặp phải khi xây dựng hệ thống tích hợp dữ liệu và giải pháp Vấn đề cập nhật dữ liệu trong thời gian thực Ngày nay, các quyết định trong kinh doanh cần được đưa ra nhanh, phù hợp với sự thay đổi liên tục của thị trường, do đó các hệ thống hỗ trợ ra quyết định cũng cần phải đáp ứng được sự thay đổi liên tục của dữ liệu, đó là lý do của việc xuất hiện nhu cầu cập nhập dữ liệu trong thời gian thực của data warehouse. Tuy nhiên, việc xây dựng hệ thống ETL để cập nhật dữ liệu theo thời gian thực có một số khó khăn nhất định. Khó khăn đầu tiên là từ việc chuyển đổi cách cập nhật dữ liệu như trước đây - cập nhật dữ liệu theo lô (batch). Với cách cập nhật dữ liệu này, người ta lập lịch để xử lý các dữ liệu mới theo thời gian cố định (theo ngày, theo tháng,...) và người ta thường chọn thời gian thấp điểm của hệ thống để tiến hành việc cập nhật (có thể là lúc nửa đêm, khi hệ thống có ít người sử dụng). Tuy nhiên, với việc cập nhật dữ liệu theo thời gian thực, dữ liệu được cập nhật liên túc bất kể tình trạng của hệ thống, điều này gây ra sự quá tải đối với hệ thống vào một số thời điểm nhất định. Người ta đã đề xuất một số giải pháp cho vấn đề này như sau: + Cách 1: đây là cách đơn giản nhất, thay vì cập nhật dữ liệu theo thời gian thực, ta điều chỉnh tần suất cập nhật dữ liệu. Ví dụ trước đây là 1 lần một tuần, bây giờ đổi thành 1 lần một ngày, hoặc 3 lần một ngày. + Cách 2: cập nhật từng phần nhỏ. Bất kể khi nào phát sinh sự kiện chỉnh sửa hoặc thêm các trường vào dữ liệu giao tác, ta đều tiến hành song song việc cập nhật dữ liệu tương ứng vào các bảng của data warehouse. Tuy nhiên, điều này gây ra nhiều vấn đề về giao tác (transaction) khi dữ liệu quá lớn. Với mỗi giao tác sẽ phải tiến hành hai thao tác cập nhật dữ liệu thay vì chỉ một như trước đây, và khi dữ liệu quá lớn, sẽ phải mất thêm thời gian chờ. + Cách 3: cập nhật từng phần nhỏ và xoay vòng. Cách giải quyết này có thể giải quyết vấn đề dữ liệu lớn trong data warehouse. Thay vì thêm hoặc sửa dữ liệu trực tiếp trong data warehouse, ta tạo các bảng fact có cùng cấu trúc như trong data warehouse nhưng chỉ lưu dữ liệu trong ngày hoặc giờ hiện tại (không lưu dữ liệu lịch sử), Sau một chu kỳ sẽ tiến hành cập nhật dữ liệu này vào các bảng fact trong data warehouse. + Cách 4: lưu dữ liệu được cập nhật trong thời gian thực vào vùng đệm (cache), sau một chu kỳ định sẵn sẽ tiến hành cập nhật vào data warehouse. Mỗi khi có một truy vấn trên data warehouse, hệ thống sẽ truy vấn đồng thời trên các bảng fact và trong cả vùng đệm. Vấn đề về mô hình hóa dữ liệu: đối với các dữ liệu tổng hợp. Ví dụ dữ liệu tổng hợp theo chiều thời gian, thì những dữ liệu này có thể bị bất đồng bộ hóa với dữ liệu được cập nhật trong thời gian thực. Thật ra đây cũng không hẳn là vấn đề, bởi vì về bản chất dữ liệu bình thường và dữ liệu theo thời gian thực là giống nhau, vấn đề là ở chỗ một số ứng dụng người dùng cuối sử dụng kỹ thuật catch và cho rằng dữ liệu sẽ được cập nhật sau một khoảng thời gian nào đó đối với kỹ thuật cũ, cho nên chỉ cần lưu ý vấn đề này là được. Vấn đề về không nhất quán dữ liệu khi thực hiện truy vấn. Ví dụ:                 Hình 4 Đây là một truy vấn gồm nhiều câu lệnh SQL, mục địch là để tính toán số tiền bán ra của mỗi loại hàng hóa và phần trăm của số tiền đó trên tổng số doanh thu. Câu truy vấn này thực hiện như sau: tạo 2 bảng tạm TEMP1, và TEMP2, đưa dữ liệu về số lượng tiền của mỗi loại hàng hóa vào bàng TEMP1, đưa tổng số tiền bán được vào bảng TEMP2, sau đó sẽ đưa ra bảng tổng kết như khung hình bên phải. Vấn đề ở đây là nếu sau khi thực hiện việc đưa dữ liệu vào bảng TEMP1 và chưa kịp dưa dữ liệu vào bảng TEMP2 thì xảy ra hiện tượng không đồng nhất dữ liệu, điều này có nghĩa là tổng số phần trăm bên khung nhìn bên phải sẽ không bằng 100%. Các giải pháp cho vấn đề này được đề xuất như sau: + Cách 1:sử dụng cách tiếp cận “gần thời gian thực” (near real-time): thực hiện việc cập nhật dữ liệu trong một chu kỳ nhất định, và không cho phép việc thực hiện truy vấn trong thời gian cập nhật dữ liệu. + Cách 2: tách dữ liệu được tổng hợp trong thời gian thực và dữ liệu lịch sử và lưu trong vùng nhớ cache, như vậy sẽ tránh được trường hợp dữ liệu không nhất quán. Khi thực hiện truy vấn, ta sẽ thực hiện truy vấn đồng thời trên cả 2 dữ liệu. Cảnh báo thời gian thực: các hệ thống cảnh báo được sử dụng trong data warehouse chủ yếu để gửi các báo cáo đến người dùng sau khi load dữ liệu trong mỗi chu kỳ. Tuy nhiên đối với các hệ thống data warehouse hoạt động trong thời gian thực, hệ thống cảnh báo được sử dụng để thông báo khi mà điều kiện đặt ra được đáp ứng. Các giải pháp đặt ra cho vấn đề thông báo theo thời gian thực: + Lập lịch theo vòng n phút (n-Minute Cycle Schedule): chú ý rằng cần phải xác định ngưỡng thấp nhất của vòng lặp, vì ở một giới hạn nào đó, có thể xảy ra một số vấn đề về khả năng chịu tải của hệ thống hoặc lần cảnh báo sau bắt đầu trước khi lần cảnh báo trước kết thúc, điều này gây ra trùng cảnh báo. + Thông báo bằng cách theo dõi và chặn (trigger) theo thời gian thực: đặt các chặn (trigger) để kiểm tra mỗi khi có sự thay đổi dữ liệu để cảnh báo. Về phương pháp này, cần chú ý về giới hạn của phần cứng và bộ nhớ để đáp ứng các xử lý liên tục. Phần mềm tích hợp dữ liệu mã nguồn mở Kettle Giới thiệu tổng quan: Giới thiệu: Kettle là phần mềm mã nguồn mở dùng để xây dựng các hệ thống tích hợp dữ liệu. Kettle bao gồm nhân tích hợp dữ liệu và giao diện đồ họa cho phép người dùng định nghĩa các biến đổi (transformation) và các công việc (job – bao gồm các bước biến đổi được tiến hành tuần tự hoặc song song). Kettle bao gồm các công cụ và tiện ích sau: Spoon: IDE đồ họa cho việc tạo các biến đổi (transformation) và các công việc (job) cho Kettle. Kitchen: công cụ command-line để chạy các công việc (job) của Kettle. Pan: công cụ command-line để chạy các biến đổi (transformation) của Kettle. Carte: đóng vai trò làm máy chủ khi chạy các biến đổi và các công việc của Kettle trên một máy khác. Một số khái niệm trong Kettle: Bước (step): là một hoạt động cụ thể trên một hoặc nhiều luồng dữ liệu. Ví dụ: Access Input dùng để lấy dữ liệu từ tập tin access, Sort rows dùng để sắp xếp các dòng trong luồng dữ liệu vào, value mapper dùng để ánh xạ dữ liệu, Trong mỗi bước ta có thể định nghĩa các thuộc tính để xử lý dữ liệu đi vào bước đó, các thuộc tính này được gọi là siêu dữ liệu (metadata) Các bước có thể được nối với nhau qua các cầu nối gọi là các hop. Các hop này được xem như là những “đường ống” để chuyển dữ liệu từ bước (step) này qua bước khác. Biến đổi (transform): bao gồm các bước, siêu dữ liệu tương ứng với từng bước và các hop. Công việc (job): bao gồm một hoặc nhiều biến đổi. Ví dụ: khi nạp dữ liệu có lược đồ hình sao, việc đầu tiên ta cần xây dựng một biến đổi để kết xuất dữ liệu từ hệ thống nguồn, xây dựng các biến đổi để nạp từng bảng chiều và bảng fact. Công việc (job) được dùng để đặt các biến đổi đó lại với nhau theo một thứ tự thích hợp để có thể thực hiện việc nạp dữ liệu. Một số bước thường dùng và các chú ý trong Kettle: Table input: Chức năng: lấy dữ liệu từ một cơ sở dữ liệu sử dụng một kết nối đã được cấu hình và câu lệnh SQL. Cấu hình: Cấu hình Mô tả Step name Tên bước, tên của mỗi bước là duy nhất trong mỗi biến đổi Connection Các cấu hình kết nối CSDL để đọc dữ liệu SQL Câu lệnh SQL dùng để đọc dữ liệu từ kết nối đã được cấu hình ở trên Enable lazy convertion Khi được kích hoạt, quá trình lấy dữ liệu sẽ tránh những thao tác ép kiểu không cần thiết để tăng tốc độ. Replace variables in script? Khi được kích hoạt, quá trình lấy dữ liệu sẽ đặt các tham số từ bước trước đó vào câu lệnh SQL tại những dấu “?” lần lượt theo thứ tự của tham số. Insert data from step Khi được kích hoạt, câu lệnh SQL sẽ được phép sử dụng dữ liệu từ bước xác định trước để lấy dữ liệu từ kết nối đã được cấu hình sẵn. Execute for each row? Khi được kích hoạt, quá trình lấy dữ liệu được tiến hành cho mỗi dòng dữ liệu được nạp vào từ bước trước đó Limit size Giới hạn số dòng dữ liệu được đọc từ CSDL, 0 có nghĩa là đọc tất cả các dòng. Modified java script: Chức năng: bước này cho phép ta sử dụng cú pháp và các hàm javascript để biến đổi dữ liệu. Cấu hình: Compatibility mode? Khi được kích hoạt, javascript sẽ sử dụng engine phiên bản 2.5; nếu không thì sẽ sử dụng phiên bảng 3.0 Chú ý: ở bước này, tên các trường dữ liệu của bước trước được xem như các hằng số, các biến được định nghĩa mới có thể được thêm vào dữ liệu đầu ra của bước. Hàm javascript được chạy mỗi khi có một dòng (record) đi vào bước này. Filter rows: Chức năng: lọc dữ liệu dựa trên điều kiện Cấu hình: Cấu hình Mô tả Send ‘true’ data to step Dữ liệu đúng với điều kiện được chuyển đến bước này. Send ‘false’ data to step Dữ liệu không đúng với điều kiện được chuyển đến bước này. Chú ý: các bước mà dữ liệu “đúng” và “sai” được chuyển đến phải được nối với bước hiện tại thông qua các hop. Dimension lookup/ update: Chức năng: dùng để cập nhật dữ liệu cho các bảng có chiều thay đổi chậm loại 1 hoặc loại 2. Cấu hình: Cấu hình Mô tả Technical key field Khóa chính (primary key) của bảng chiều. Version field Đánh dấu phiên bảng của dòng dữ liệu trong chiều thay đổi chậm Date range start field Ngày bắt đầu có hiệu lực của dòng dữ liệu Table daterange end Ngày cuối cùng có hiệu lực của dòng dữ liệu Keys Khóa tự nhiên được sử dụng trong dữ liệu nguồn Field Chứa thông tin của chiều Chú ý: + Khi thực thi, trước hết bước này sẽ tìm dữ liệu trong bảng chiều tương ứng với các khóa được xác định trong mục cấu hình “Key fields”. Nếu không tìm thấy dữ liệu yêu cầu, dữ liệu mới sẽ được thêm (insert) vào bảng chiều. Ngược lại, dữ liệu tìm thấy sẽ được so sánh với các dữ liệu đưa vào và tiến hành cập nhật (update) hay thêm (insert) tùy thuộc vào loại chiều thay đổi chậm được xác định trên mỗi trường dữ liệu. + Việc cấu hình chiều thay đổi chậm được tiến hành ở mục “Lookup/ Update fields”, với các trường có chiều thay đổi chậm loại một, ở mục “Type of dimension update” sẽ được thiết lập giá trị là “Update”. Giá trị “Insert” được thiết lập cho các trường có chiều thay đổi chậm loại 2. Các giá trị còn lại như “Last version”, “Date of last insert”, để xác định các thông tin kèm theo chiều thay đối chậm. Combination lookup/ update: Chức năng: sử dụng để tìm hoặc sinh khóa chính với các trường tìm kiếm tương ứng. Trước tiên, bước này sẽ tìm kiếm dữ liệu trong bảng được xác định thông qua các trường “Connection” và “Target table” với các thông tin khóa tìm kiếm ứng với thông tin được đưa vào. Nếu tìm thấy sẽ trả về khóa chính tương ứng, nếu không sẽ phát sinh khóa chính mới và thêm (insert) một dòng dữ liệu vào bảng, nội dung những dòng dữ liệu này chỉ bao gồm thông tin khóa và các trường dữ liệu được sử dụng để tìm kiếm ở trên, các trường còn lại có giá trị null hoặc giá trị mặc định của trường đó. Cấu hình: Cấu hình Mô tả Dimension field Trường tìm kiếm trong bảng chiều Field in stream Trường dữ liệu tương ứng với trường tìm kiếm trong bảng chiều Chú ý: + Việc kết hợp nhiều trường để tìm kiếm có thể làm tốc độ xử lý chậm lại. Trong trường hợp này, ta có thể đánh dấu tùy chọn “Use hashcode” để thêm giá trị băm tương ứng vào bảng, như vậy quá trình tìm kiếm trên nhiều chiều thực chất chỉ còn tìm kiếm trên giá trị băm. + Do ở bước này chỉ thêm mới giá trị khóa chính và các giá trị tìm kiếm, nên thường được đi kèm với bước “Update” đằng sau để cập nhật các trường không phải trường tìm kiếm. Update: Chức năng: tìm kiếm các dòng trong bảng sử dụng một hoặc nhiều khóa tìm kiếm kết hợp. Nếu dòng dữ liệu được tìm thấy, dữ liệu sẽ được so sánh với các giá trị tương ứng ở trường cập nhật, nếu dữ liệu khác nhau sẽ tiến hành cập nhật. Cấu hình: Cập nhật Mô tả The key(s) to look up the value(s) Các khóa được sử dụng để tìm kiếm Update fields Các trường dữ liệu sẽ được so sánh với dữ liệu đưa vào và tiến hành cập nhật nếu có giá trị khác nhau. Xây dựng kho dữ liệu phục vụ các hệ thống học tập trực tuyến Mô tả yêu cầu ứng dụng Yêu cầu của ứng dụng thử nghiệm là xây dựng một hệ thống tích hợp dữ liệu từ nhiều nguồn vào kho dữ liệu phục vụ cho nhu cầu phân tích dữ liệu của các hệ thống học tập trực tuyến. Hệ thống cho phép mở rộng để đưa dữ liệu từ các nguồn chưa được hỗ trợ vào kho dữ liệu. Các yêu cầu phân tích dữ liệu đối với các hệ thống học tập trực tuyến: Có 2 nhu cầu khi phân tích hệ thống giảng dạy trực tuyến: Xem xét hiệu quả của hệ thống đối với người học: + Phân tích mối quan hệ của thời gian sinh viên tham gia hệ thống đối với kết quả học tập trong từng môn học (kết quả được đánh giá theo từng học kỳ). + Phân tích mối quan hệ của tần suất sinh viên tham gia hệ thống đối với kết quả học tập trong từng môn học . + Phân tích mối quan hệ của thời gian giáo viên tham gia hệ thống đối với kết quả học tập của sinh viên trong môn học đó. + Phân tích mối quan hệ của tần suất giáo viên tham gia hệ thống đối với kết quả học tập của sinh viên trong môn học đó. + Phân tích (thời gian, tần suất, tỉ lệ) các hoạt động mà sinh viên tham gia trong hệ thống và sự liên quan đến kết quả học tập. Xem xét hiệu năng sử dụng của hệ thống để phân phối lại các bài học vào các thời điểm thích hợp. + Phân tích thời lượng truy cập vào hệ thống theo thời gian. + Phân tích tỷ lệ truy cập vào các chức năng của hệ thống theo thời gian. Ma trận kiến trúc buýt: Ma trận mô tả các nghiệp vụ và ngữ cảnh liên quan: Ngữ cảnh Thời gian Người dùng Học phần Chức năng Nghiệp vụ Khảo sát thời gian sử dụng hệ thống x x x x Khảo sát tần suất truy cập hệ thống x x x x Khảo sát kết quả học tập x x Kiến trúc của ứng dụng Ứng dụng thử nghiệm xây dựng dựa trên kiến trúc NDS+DDS, với mô hình như sau: Với yêu cầu cho phép mở rộng để đưa dữ liệu từ các nguồn khác nhau vào kho dữ liệu, hệ thống tích hợp dữ liệu được thiết kế để việc mở rộng là thuận tiện nhất. Ở đây CSDL chuẩn hóa, kho dữ liệu và quá trình tích hợp dữ liệu từ CSDL chuẩn hóa vào kho dữ liệu là chung cho tất cả các loại nguồn dữ liệu. Với một loại nguồn dữ liệu sẽ có cấu trúc vùng xử lý khác nhau, quá trình tích hợp dữ liệu từ dữ liệu nguồn vào vùng xử lý và từ vùng xử lý vào CSDL chuẩn hóa khác nhau. Thiết kế kho dữ liệu Vùng xử lí Moodle Hệ thống Moodle có khoảng 200 bảng dữ liệu. Tuy nhiên để lấy dữ liệu cho data warehouse được thiết kế ở trên ta chỉ sử dụng các bảng và các trường sau: Hình 5.3.1.1-1. Vùng xử lí cho dữ liệu nạp từ Moodle Ở đây có một số chú ý đối với dữ liệu trong vùng xử lí của Moodle: Trường full_path_name của bảng stg_course_categories là khoá tự nhiên sinh ra trong quá trình rút trích dữ liệu. Lí do là dữ liệu nguồn không có khoá tự nhiên khác với định danh hệ thống. Việc tạo ra khoá tự nhiên nhằm tránh xung đột về dữ liệu. Vùng xử lí chỉ bao gồm khoá tự nhiên và các thuộc tính cần thiết, không bao gồm khoá chính, khoá ngoại hay chỉ mục, nhằm tăng tốc quá trình sao chép dữ liệu từ nguồn. Những bảng có trường last_update là những bảng không chứa thông tin lịch sử thay đổi của nguồn. last_update là trường do hệ thống ETL tạo ra trong quá trình rút trích nhằm ghi nhận các thay đổi này. Các bảng khác sử dụng trường timemodified trong dữ liệu nguồn để ghi nhận thay đổi từ nguồn. Kết quả học tập Dữ liệu về kết quả học tập, học kỳ, năm học không có trong moodle. Cho nên nếu muốn phân tích các vấn đề liên quan tới các dữ liệu này, người dùng cần phải nhập dữ liệu bằng file excel có cấu trúc như sau (do ứng dụng bao đóng quy định): Dữ liệu kết quả học tập: file excel với cột 1 chứa mã khóa học (có header là CourseID), cột 2 là mã sinh viên (có header là StudentID), cột 3 là điểm (có header là Value) Hình 5.3.1.2-1. Cấu trúc tập tin chứa kết quả học tập Dữ liệu học kỳ, năm học File excel với cột 1 chứa số thứ tự học kỳ trong năm học (có header là TermNumber), cột 2 chứa tên học kỳ (có header là TermName), cột 3 chứa năm bắt đầu năm học (có header là AcademicYear), cột 4 chứa tên năm học (có header là AcademicYearName), cột 5 và cột 6 chứa ngày bắt đầu và ngày kết thúc học kỳ (có header lần lượt là BeginDate và EndDate). Ngày tháng có định dạng năm/tháng/ngày (YYYY/mm/DD) Hình 5.3.1.3-1. Cấu trúc tập tin chứa thông tin các học kì, năm học Cơ sở dữ liệu chuẩn hoá Lược đồ Cơ sở dữ liệu chuẩn hoá được tổ chức dưới dạng chuẩn 3, như hình dưới đây: Các diễn giải liên quan đến thiết kế Các thuộc tính category_full_path và parent_category_full_path là các khoá tự tạo trong quá trình trích xuất dữ liệu từ nguồn đưa vào vùng xử lí như đã trình bày bên trên. (Xem mục 5.3.1.1. Moodle) Các thuộc tính last_update của các bảng là thời gian cập nhật dòng dữ liệu lần cuối cùng từ nguồn. Đối với các bảng mà dữ liệu nguồn có lưu lịch sử thay đổi, last_update là giá trị thời gian của cột tương ứng trong bảng đó. Đối với các bảng mà dữ liệu nguồn không lưu lịch sử thay đổi, sử dụng thời điểm rút trích dữ liệu cho thuộc tính last_update. Đặc tả cơ sở dữ liệu Nds_modules: lưu trữ thông tin về các mô đun trong hệ thống Tên thuộc tính Kiểu giá trị Ý nghĩa module_name varchar Tên mô đun website hệ thống nguồn (khóa chính) module_description text Mô tả mô đun last_update datetime Thời điểm cập nhật cuối cùng Nds_categories: lưu trữ thông tin về nhóm các khóa học Tên thuộc tính Kiểu giá trị Ý nghĩa category_full_path varchar Khoá tự nhiên của nhóm khoá học, tạo ra bằng cách ghép nối tên các nhóm khoá học từ nó lên đến nút gốc trên cây phân cấp, ngăn cách bằng dấu ‘;’ parent_category_full_path varchar Khoá tự nhiên của nhóm môn học cha. category_name varchar Tên nhóm khóa học category_description text Mô tả nhóm khóa học depth tinyint Độ sâu của nhóm khoá học trên cây phân cấp. last_update datetime Thời điểm cập nhật cuối cùng Nds_courses: lưu trữ thông tin về khóa học Tên thuộc tính Kiểu giá trị Ý nghĩa course_code varchar Mã khóa học category_full_name varchar Nhóm khoá học. Khoá ngoại tham chiếu đến bảng nds_categories term_number tinyint Thứ tự học kỳ year_number int Năm học course_name varchar Tên khóa học course_description text Mô tả khóa học course_start_date datetime Ngày bắt đầu khóa học course_created_date datetime Ngày khởi tạo khóa học trong hệ thống last_update datetime Thời điểm cập nhật cuối cùng Nds_terms: lưu trữ thông tin về học kỳ Tên thuộc tính Kiểu giá trị Ý nghĩa term_number int Thứ tự học kỳ trong năm học year_number tinyint Năm học, tham chiếu đến bảng nds_academic_years term_name varchar Tên học kỳ begin_date date Ngày bắt đầu học kỳ end_date date Ngày kết thúc học kỳ last_update datetime Thời điểm cập nhật cuối cùng Nds_academic_years: Tên thuộc tính Kiểu giá trị Ý nghĩa year_number int Năm học academic_year_name varchar Tên năm học last_update datetime Thời điểm cập nhật cuối cùng Nds_role: lưu trữ thông tin vai trò người dùng trong hệ thống Tên thuộc tính Kiểu giá trị Ý nghĩa role_name varchar Tên vai trò role_description text Mô tả vai trò last_update datetime Thời điểm cập nhật cuối cùng Nds_users: lưu trữ thông tin người dùng Tên thuộc tính Kiểu giá trị Ý nghĩa user_name varchar Tên đăng nhập của người dùng description text Mô tả người dùng first_name varchar Họ người dùng last_name varchar Tên thật người dùng email varchar Email người dùng phone_1 varchar Số điện thoại người dùng phone_2 varchar Số điện thoại người dùng institution varchar Tên cơ quan department varchar Tên phòng ban address varchar Địa chỉ người dùng city varchar Thành phố người dùng đang ở last_update timestamp Thời điểm sửa đổi cuối cùng Nds_actions:lưu trữ thông tin các thao tác trong hệ thống Tên thuộc tính Kiểu giá trị Ý nghĩa action_name varchar Tên thao tác action_description text Mô tả thao tác last_update datetime Thời điếm cập nhật cuối cùng Nds_logs: lưu trữ thông tin log của hệ thống Tên thuộc tính Kiểu giá trị Ý nghĩa course_code varchar Mã khóa học, tham chiếu đến bảng nds_courses user_name varchar Mã người dùng, tham chiếu đến bảng nds_users module_name varchar Tên mô đun, tham chiếu đến bảng nds_modules action_name varchar Tên hoạt động, tham chiếu đến bảng nds_actions access_time datetime Thời điểm truy cập vào hệ thống last_update datetime Thời điểm cập nhật cuối cùng Nds_results: lưu trữ thông tin kết quả học tập Tên thuộc tính Kiểu giá trị Ý nghĩa course_code varchar Mã khóa học, tham chiếu đến bảng nds_courses user_name varchar Tên người dùng, tham chiếu đến bảng nds_users grade float Điếm số của người dùng với khóa học tương ứng last_update datetime Thời điểm cập nhật cuối cùng Nds_role_assignments: lưu thông tin về vai trò của người dùng ở một khóa học trong hệ thống. Tên thuộc tính Kiểu giá trị Ý nghĩa user_name varchar Tên người dùng, tham chiếu đến bảng nds_users course_code varchar Mã khóa học, tham chiếu đến bảng nds_courses role_name varchar Tên vai trò, tham chiếu đến bảng nds_roles last_update datetime Thời điểm cập nhật cuối cùng Kho dữ liệu đầu cuối Lược đồ cơ sở dữ liệu Các diễn giải liên quan đến thiết kế Bảng category_bridge được tạo ra nhằm khử truy vấn đệ quy trên nhóm khoá học. Đây là cây phân cấp không giới hạn độ sâu. Chẳng hạn: Có cây phân cấp đệ quy không giới hạn độ sâu như sau: Hình 5.3.3.1-1. Cây phân cấp không giới hạn độ sâu. Bảng cầu nối được tạo ra có nội dung như sau: Hình 5.3.3.1-2. Bảng cầu nối được tạo ra Ở đây, mỗi dòng trong bảng cầu nối mô tả một quan hệ cha con. Mỗi dòng cho biết các thông tin sau: manager_key: khoá đại diện của cha employee_key: khoá đại diện của con nest_level: độ sâu từ cha đến con. is_top/is_bottom: cho biết con có phải là nút gốc/nút lá của cây hay không. Bảng dim_role_group và role_group_bridge được tạo ra để giải quyết tình trạng dữ kiện đa trị (multivalued fact). Ở đây, mỗi một người dùng ghé thăm một trang môn học nào đó, người dùng đó có thể đóng một hoặc nhiều vai trò (role) trong. Chẳng hạn một người có thể vừa là sinh viên, vừa là trưởng nhóm. Thuộc tính role_count cho biết số lượng vai trò trong nhóm đó. Thuộc tính weighting_factor là trọng số, xác định mức độ tham gia của một vai trò trong một nhóm vai trò nào đó. Thuộc tính này nhằm tránh tình trạng thống kê kép. Được tính theo công thức sau: weighting_factor = 1 / role_count Đặc tả cơ sở dữ liệu Các bảng chiều: dim_date: chiều ngày tháng, sử dụng đơn vị học kỳ, năm học Tên thuộc tính Kiểu giá trị Ý nghĩa date_key Int Khoá chính (Khoá đại diện) date_alternate_key date Ngày tháng đầy đủ day_number_of_week tinyint Thứ tự ngày trong tuần day_name_of_week varchar Tên ngày trong tuần day_number_of_month tinyint Thứ tự ngày trong tháng day_number_of_term smallint Thứ tự ngày trong học kỳ week_number_of_term tinyint Thứ tự tuần trong học kỳ month_number_of_year tinyint Thứ tự tháng trong năm month_name_of_year varchar Tên tháng year_number tinyint Năm term_name varchar Tên học kì term_number smallint Thứ tự học kỳ trong năm academic_year_name varchar Tên năm học (vd: 2007-2008) academic_year smallint Năm bắt đầu của năm học is_weekend tinyint Có phải là ngày cuối tuần hay không? is_holiday tinyint Có phải là ngày nghỉ hay không? last_update timestamp Thời điểm sửa đổi cuối cùng dim_time: chiều thời gian Tên thuộc tính Kiểu giá trị Ý nghĩa time_key int Khoá chính (Khoá đại diện) time_alternate_key time Thời gian đầy đủ hour tinyint Giờ minute tinyint Phút second tinyint Giây dim_user: Chiều người dùng Tên thuộc tính Kiểu giá trị Ý nghĩa user_key int Khoá chính (Khoá đại diện) user_business_key varchar Khóa tự nhiên của người dùng trong CSDL chuẩn hóa user_name varchar Tên đăng nhập của người dùng user_description text Mô tả người dùng first_name varchar Họ người dùng last_name varchar Tên thật người dùng email varchar Email người dùng phone_1 varchar Số điện thoại người dùng phone_2 varchar Số điện thoại người dùng institution varchar Tên cơ quan department varchar Tên phòng ban address varchar Địa chỉ người dùng city varchar Thành phố người dùng đang ở last_update timestamp Thời điểm sửa đổi cuối cùng dim_role: chiều vai trò người dùng Tên thuộc tính Kiểu giá trị Ý nghĩa role_key int Khoá chính (Khoá đại diện) role_business_key varchar Khóa tự nhiên của vai trò trong CSDL chuẩn hóa role_name varchar Tên vai trò role_description text Mô tả vai trò valid_from date Ngày bắt đầu có hiệu lực của vai trò (ở trường hiện tại), dùng để quản lý chiều thay đổi chậm loại 2 valid_to date Ngày kết thúc có hiệu lực của vai trò (ở trường hiện tại), dùng để quản lý chiều thay đổi chậm loại 2 version tinyint Phiên bản, dùng để quản lý chiều thay đổi chậm loại 2 is_current varchar Vai trò ở trường hiện tại có đang được sử dụng hay không, dùng để quản lý chiều thay đổi chậm loại 2 last_update datetime Thời điểm sửa đổi cuối cùng dim_course: chiều học phần Tên thuộc tính Kiểu giá trị Ý nghĩa course_key int Khoá chính (Khoá đại diện) course_business_key varchar Khóa tự nhiên của khóa học trong CSDL chuẩn hóa course_code varchar Mã khóa học course_name varchar Tên khóa học course_description text Mô tả khóa học course_start_date datetime Ngày bắt đầu khóa học course_created_date datetime Ngày khởi tạo khóa học trong hệ thống term_number tinyint Thứ tự học kỳ trong năm học term_name varchar Tên học kỳ academic_year smallint Năm bắt đầu năm học academic_year_name varchar Tên năm học category_key int Mã nhóm khóa học last_update datetime Thời điểm cập nhật cuối cùng dim_role_group: chiều nhóm vai trò Tên thuộc tính Kiểu giá trị Ý nghĩa role_group_key int Khóa chính (khóa đại diện) natural_key varchar Khóa tự nhiên của nhóm vai trò trong CSDL chuẩn hóa role_count int Số lượng vai trò trong nhóm role_group_bridge: bảng cầu nối giữa chiều vai trò và chiều nhóm vai trò Tên thuộc tính Kiểu giá trị Ý nghĩa role_group_key int Mã nhóm vai trò role_key int Mã vai trò weighting_factor float Trọng số, có giá trị là 1/role_count (bảng dim_role_group) dim_junk_activity: chiều chức năng của hệ thống Tên thuộc tính Kiểu giá trị Ý nghĩa activity_key int Khóa chính (khóa đại diện) module_name varchar Tên mô đun của chức năng action_name varchar Tên hoạt động last_update datetime Thời điểm cập nhật cuối cùng lkp_category: bảng tìm kiếm nhóm khóa học Tên thuộc tính Kiểu giá trị Ý nghĩa category_key int Khóa chính (khóa đại diện) category_business_key varchar Khóa tự nhiên của nhóm khóa học trong CSDL chuẩn hóa category_name varchar Tên nhóm khóa học category_description text Mô tả nhóm khóa học last_update datetime Thời điểm cập nhật cuối cùng category_bridge: bảng cầu nối nhóm khóa học. Tên thuộc tính Kiểu giá trị Ý nghĩa parent_category_key int Mã khóa học cha (mỗi khóa học cha chứa nhiều khóa học con) child_category_key int Mã khóa học con nest_level tinyint Số tầng phân cấp is_top tinyint Có là quan hệ cha-con ở trên cùng hay không is_bottom tinyint Có là quan hệ cha-con ở dưới cùng hay không Chú thích: Bảng cầu nối này nhằm mục đích khử truy vấn đệ quy cho cây phân cấp với độ sâu không giới hạn. Các bảng dữ kiện: fct_traffic: dữ kiện thống kê về truy cập trên hệ thống Tên thuộc tính Kiểu giá trị Ý nghĩa date_key int Khoá ngoại tham chiếu bảng dim_date time_key int Khoá ngoại tham chiếu bảng dim_time user_key int Khoá ngoại tham chiếu bảng dim_user activity_key int Khoá ngoại tham chiếu bảng dim_activity course_key int Khóa ngoại tham chiếu bảng dim_course role_group_key int Khóa ngoại tham chiếu bảng dim_role_group duration int Thời gian truy cập tính theo giây view_count int Số lượt truy cập last_update datetime Thời điểm sửa đổi cuối cùng fct_grade: Dữ kiện thống kê về kết quả học tập của sinh viên trong từng môn học. Tên thuộc tính Kiểu giá trị Ý nghĩa user_key int Khoá ngoại tham chiếu bảng dim_user course_key int Khoá ngoại tham chiếu bảng dim_course grade tinyint Điểm của sinh viên trong khóa học tương ứng. last_update datetime Thời điểm cập nhật cuối cùng Phân cấp các chiều: Chiều ngày Năm học àHọc kì àTuần àNgày Chiều giờ Thời điểm trong ngày àGiờ àPhút Chiều học phần Nhóm học phần à Nhóm học phần con à Học phần Chiều chức năng Mô đun à Chức năng Hoạt động à Chức năng Thiết kế hệ thống tích hợp dữ liệu Rút trích dữ liệu – ETL cho vùng xử lí Hình 5.4.1-1. Giai đoạn rút trích dữ liệu cho vùng xử lí. Ở giai đoạn này, dữ liệu chủ yếu được sao chép nguyên trạng từ nguồn vào vùng xử lí. Quá trình này trải qua các gia đoạn chính dựa trên thuật toán sau: Kiểm tra các bảng trong vùng xử lí có trống hay không. Nếu không có dữ liệu: Thực hiện rút trích dữ liệu từ nguồn. Nếu dữ liệu nguồn có thông tin lịch sử: Truy vấn lấy dữ liệu có ngày giờ thay đổi sau ngày giờ last_update trong vùng dữ liệu chuẩn hoá. Ngượclại, thực hiện truy vấn toàn bộ từ dữ liệu nguồn và dữ liệu trong vùng cơ sở dữ liệu chuẩn hoá để so sánh. Chỉ lấy ra những dòng dữ liệu mới hoặc có thay đổi để đưa vào vùng xử lí. Trường last_update được tạo ra trong giai đoạn này, lưu ngày tháng hiện hành đối với các bảng không chứa thông tin lịch sử. Ngược lại, ngưng không rút trích. Hình 5.4.1-2. Quá trình rút trích dữ liệu Biến đổi dữ liệu – ETL cho cơ sở dữ liệu chuẩn hoá Hình 5.4.2.1-Giai đoạn biến đổi dữ liệu đưa vào vùng CSDL chuẩn hoá Quy trình biến đổi dữ liệu để đưa dữ liệu từ vùng xử lí vào cơ sở dữ liệu chuẩn hoá được thực hiện qua các bước chính sau: Nạp các bảng không chứa khoá ngoại (các bảng không bị ràng buộc khoá ngoại đến bảng khác): Đưa dữ liệu trong vùng xử lí vào cơ sở dữ liệu chuẩn hoá. Nếu hoàn tất, xoá dữ liệu trong vùng xử lí. Nạp các bảng chứa khoá ngoại. Tìm kiếm khoá ngoại trên những chiều tham chiếu đến. Đưa dữ liệu trong vùng xử lí vào cơ sở dữ liệu chuẩn hoá. Nếu hoàn tất, xoá dữ liệu trong vùng xử lí. Hình 5.4.2-2. Các bước chính đưa dữ liệu vào CSDL chuẩn hoá. Hình 5.4.2-3. Các bước chính đưa dữ liệu vào từng bảng trong CSDL chuẩn hoá. Nạp dữ liệu – ETL cho kho dữ liệu Hình 5.4.3-1. Giai đoạn nạp dữ liệu vào kho dữ liệu đầu cuối Quy trình biến đổi và nạp dữ liệu vào kho dữ liệu dựa trên thuật toán sau: Nạp các bảng chiều: Kiểm tra nếu bảng dim_date và dim_time được nạp hay chưa: Nếu chưa nạp thì thực hiện nạp 2 bảng này. Ngược lại, nếu đã nạp thì qua bước tiếp theo. Thực hiện cập nhật dữ liệu cho chiều ngày tháng nếu có. Thực hiện nạp dữ liệu cho các bảng chiều. Thực hiện nạp dữ liệu cho các bảng cầu nối. Thực hiện nạp các bảng dữ kiện: Hình 5.4.3-2. Các bước chính nạp dữ liệu vào kho dữ liệu Hình 5.4.3-3. Nạp các bảng chiều. Hình 5.4.3-4. Nạp các bảng dữ kiện. Xây dựng ứng dụng đóng gói Triển khai ứng dụng Các phần mềm đi kèm: Trước khi sử dụng ứng dụng, cần cài đặt các gói phần mềm sau: Java Runtime Environment – JRE 6u15 trở lên. .NET Framework Runtime 4.0 trở lên. Cài đặt Sử dụng