Đề tài Xây dựng kho chứa dữ liệu

ụng sơ đồ bông tuyết. Trong sơ đồ loại này, các bảng Fact kết hợp được tạo ra một cách riêng biệt từ những bảng chứa dữ liệu chi tiết. Thêm vào với các bảng Fact chính, sơ đồ hình tuyết rơi còn chứa các bảng Fact riêng rẽ cho mỗi mức kết hợp, vì vậy không mắc lỗi trong việc lựa chọn các bản ghi chi tiết. Tuy nhiên sơ đồ hình tuyết rơi phức tạp hơn sơ đồ hình sao và thường đòi hỏi những câu lệnh SQL phức tạp hơn để nhận được câu trả lời. 5.1.3 Những vấn đề thiết kế lược đồ hình sao liên quan tới các phương tiện của hệ quản trị cơ sở dữ liệu quan hệ và kĩ thuật tối ưu. a/ Vấn đề kết hợp từng cặp 2 bảng Hệ quản trị cơ sở dữ liệu quan hệ không được thiết kế để dùng cho một tập lớn các câu truy vấn phức tạp có thể được đưa ra đối với một sơ đồ hình sao. Một cách cụ thể khả năng lấy được thông tin liên quan từ một số bảng trong một câu truy vấn đơn- được gọi là xử lí kết hợp - rất bị hạn chế. Một số hệ quản trị cơ sở dữ liệu quan hệ (RDBMS) chỉ có thể kết hợp 2 bảng tại một thời điểm. Nếu một sự kết hợp phức tạp liên quan tới nhiều hơn 2 bảng thì RDBMS cần phải tách câu truy vấn thành một chuỗi các cặp 2 bảng kết hợp với nhau. Đó không phải là hạn chế khắt khe nhất đối với những câu hỏi đơn giản được thực hiện bởi cơ sở dữ liệu OLTP tuy nhiên những kĩ thuật kết hợp như vậy không thể thực hiện một cách đầy đủ trong môi trường DW. Yêu cầu là liệt kê phần đóng góp của tất cả số lượng hàng bán được theo mỗi sản phẩm trong các thị trường, các loại và các giai đoạn khác nhau. Như vậy chúng ta phải kết hợp dữ liệu từ 4 bảng: SalesFact, Priod, Market, Product. Số lượng phép kết hợp được đánh giá là tăng theo hàm mũ so với số lượng các bảng được đem ra kết hợp nên trật tự kết hợp không còn là vấn đề quan trọng nhất, nó được tối ưu để có thể thực hiện trong một khoảng thời gian hợp lí. Sự kết hợp có nhiều thuật toán khác nhau. Mỗi thuật toán trong những thuật toán này cần được đánh giá cho mọi sự kết hợp. Chẳng hạn có 5 thuật toán kết hợp RDBMS, cần đánh giá 10!*5=18 triệu phép toán kết hợp cho một câu truy vấn liên quan tới 10 bảng. Con số này qua lớn khiến cho một số cơ sở dữ liệu không chạy những truy vấn cố gắng kết hợp quá nhiều bảng. Một RDBMS điển hình phải quyết định trật tự kết hợp từng cặp 2 bảng trước khi một truy vấn bắt đầu được thực hiện vì vậy việc thực hiện bị trễ đi một khoảng thời gian khá dài. b/ Vấn đề kết hợp đối với sơ đồ hình sao Vì số lượng các cặp bảng cần kết hợp với nhau thường quá lớn cho một sự đánh giá đầy đủ, rất nhiều RDBMS tối ưu hạn chế phép chọn dựa trên một tiêu chí cụ thể, thường là nhặt ra kết hợp các bảng liên quan trực tiếp với nhau. Đối với ví dụ trình bày ở trên thì việc kết hợp SalesFact với Perid thì tốt hơn là Product kết hợp với Market. Chiến lược này có vẻ có lí đối với sơ đồ OLTP truyền thống chứa một mạng phức tạp rất nhiều các bảng có quan hệ trực tiếp với nhau. Trong khi đó nó tỏ ra không hiệu quả lắm với DW vì trong sơ đồ hình sao chỉ có một bảng liên quan trực tiếp tới hầu hết các bảng còn lại đó là bảng Facts. Điều đó có nghĩa là bảng Facts là thành phần quan trọng nhất cho sự kết hợp đầu tiên. Nhưng kích thước của bảng Facts thường là lớn nhất nên chiến lược này tạo ra tập các bảng trung gian rất lớn. Điều này ảnh hưởng tới năng suất thực hiện truy vấn. Vấn đề công suất này là giả thiết rằng RDBMS có thể chọn được cặp 2 bảng kết hợp với nhau tốt nhất được đánh giá theo trật tự trong tập giới hạn các trật tự. Trong một RDBMS được tối ưu cho OLTP, truy vấn được phân tích và kế hoạch được lựa chọn dựa trên sự ước lượng độ lớn của bảng kết quả trung gian. Những ước lượng này dựa trên sự thống kê của bản thân dữ liệu và thường không được chính xác. Trong bất kì một môi trường tính toán nào, sự lan truyền về lỗi chỉ làm cho vấn đề trở nên tồi tệ thêm: nếu có một lỗi trong lần đánh giá đầu tiên thì lỗi này sẽ được nhân lên trong mỗi lần đánh giá mới tiếp theo vì vậy chỉ một lỗi nhỏ sẽ trở nên rất nghiêm trọng. Hiệu quả của mạng là ở chỗ RDBMS có thể gạt bỏ trật tự tối ưu nhất khi phải trả cái giá quá cao do lỗi xảy ra trong quá trình ước lượng chi phí. 5.2 Lược đồ bông tuyết - Snowflake Lược đồ bông tuyết là một sự mở rộng của sơ đồ hình sao tại đó mỗi cánh sao không phải là một bảng chiều mà là nhiều bảng. perKey month year quarter … Period SalesMonthly perKey prodKey mktKey dollars weight … prodKey product color model size … Product SalesWeekly perKey prodKey mktKey dollars weight … SalesDaily perKey prodKey mktKey values units … mktKey city state region … Markets countryKey … regionKey … Lược đồ bông tuyết Trong dạng sơ đồ này, mỗi bảng theo chiều của sơ đồ hình sao được chuẩn hóa hơn. Sơ đồ bông tuyết cải thiện năng suất truy vấn, tối thiểu không gian đĩa cần thiết để lưu trữ dữ liệu và cải thiện năng suất nhờ việc chỉ phải kết hợp những bảng có kích thước nhỏ hơn thay vì phải kết hợp những bảng có kích thước lớn lại không chuẩn hóa. Nó cũng làm tăng tính linh hoạt của các ứng dụng bởi sự chuẩn hóa và ít mang bản chất theo chiều hơn. Nó làm tăng số lượng các bảng và làm tăng tính phúc tạp của một vài truy vấn cần có sự tham chiếu tới nhiều bảng. Một vài công cụ đã che giấu người sử dụng đầu cuối sơ đồ cơ sở dữ liệu vật lí và cho phép họ có thể làm việc ở mức khái niệm. Những công cụ này đã ánh xạ những truy vấn của người sử dụng tới sơ đồ vật lí. Họ cần một bộ quản trị cơ sở dữ liệu để thực hiện công việc này một lần đầu tiên khi công cụ này được cài đặt. 5.3 Lược đồ kết hợp Là kết hợp giữa sơ đồ hình sao dựa trên bảng Fact và những bảng chiều không chuẩn hóa theo các chuẩn 1, 2, 3 và sơ đồ hình tuyết rơi trong đó tất cả các bảng chiều đều đã được chuẩn hóa. Trong sơ đồ loại này chỉ những bảng chiều lớn là được chuẩn hóa còn những bảng khác chứa một khối lượng lớn các cột dữ liệu chưa được chuẩn hóa. 5.4 Giải pháp cho vấn đề hiệu suất thực hiện của mô hình dữ liệu Tư tưởng cơ bản của việc tối ưu là chiến lược kết hợp các cặp bảng bằng cách lựa chọn chỉ các bảng có liên quan tới nhau ít nhất. Khi 2 bảng được kết hợp và không có cột nào liên kết 2 bảng đó với nhau sự kết hợp các hàng của 2 bảng được thực hiện. RDBMS không bao giờ coi tích Đề các như một phép kết hợp tốt, nhưng đối với sơ đồ hình sao những tích đề các này đôi khi cải thiện công suất truy vấn. Bởi vì bảng Fact trong sơ đồ hình sao có kích thước lớn hơn rất nhiều các bảng chiều mà sự kết hợp các cặp bảng được thực hiện đầu tiên với bảng Fact. Sự lựa chọn này là không hợp lí vì như vậy sẽ tạo ra các bảng trung gian rất lớn. Một tích đề các được thực hiện đầu tiên với tất cả các bảng chiều (bằng cách kết hợp các cặp bảng liên tiếp nhau) và sự kết hợp với bảng Fact được lùi lại cuối cùng. Lợi ích quan trọng là bảng Fact không tìm thấy dấu vết của nó trong bất kì một bảng kết quả trung gian nào. Chi phí lớn nhất là tạo ra tích Đề các cho tất cả các bảng chiều. Chi phí này ít tốn kém hơn việc tạo ra các bảng trung gian do kết hợp với bảng Fact. Sự tối ưu đơn giản không giải quyết được tất cả các vấn đề về năng suất thực hiện. Chiến lược này chỉ dùng được chỉ khi tích đề các của các hàng trong các bảng chiều được chọn ít hơn rất nhiều so với số lượng hàng trong bảng Fact. Như vậy việc kết hợp đề các này chỉ có ích cho những sự kết hợp có kích thước nhỏ. Nhưng DW liên quan tới những bảng có kích thước không nhỏ vì vậy một số nhà cung cấp dùng giải pháp sử dụng phần cứng và các phần mềm song song để giải quyết vấn đề này. Dùng hệ thống song song có thể làm giảm thời gian thực hiện một truy vấn đơn giản hoặc làm thêm một số công việc mà không làm thay đổi thời gian thực hiện công việc. Ngoài ra dùng các CPU gồm nhiều bộ vi xử lí cũng cải tiến được thời gian cho một câu truy vấn từ 500 giây xuống còn 50 giây. Cơ chế song song không tối ưu một cách đầy đủ các xử lí của sơ đồ hình sao. Dưới đây đưa ra một số sáng kiến để tăng công suất thực hiện của Red Brick. 5.4.1 STARjoin và STARindex Một phương pháp mới để xử lí các truy vấn phức tạp có hiệu quả đối với cơ sở dữ liệu DW là STARjoin: thực hiện kết hợp nhiều bảng một cách song song. RDBMS của RedBrick có thể kết hợp nhiều hơn 2 bảng trong một phép toán đơn, tốc độ nhanh. Thậm chí khi kết hợp 2 bảng, STARjoin cũng không thực hiện các phương pháp kết hợp được cài đặt bởi RDBMS OLTP truyền thống. Bản chất công nghệ này là sử dụng một bảng chỉ số làm cho các xử lí nhanh hơn được coi là công suất được áp dụng vào tất cả các sản phẩm của RDBMS. Các chỉ số được xác định dựa trên các cột được chọn của một bảng và khả năng lựa chọn của truy vấn bị hạn chế bởi các cột này, RDBMS có thể sử dụng bảng chỉ số này để xác định các hàng cần quan tâm nhanh hơn. Hệ quản trị cơ sở dữ liệu quan hệ của RedBrick hỗ trợ cách tạo ra chỉ số đặc biệt được gọi là STARindex làm công suất thực hiện tăng hơn rất nhiều. Nó khác với các cấu trúc index truyền thống như B_tree hay Bitmap. Nó được tạo ra trên một hoặc nhiều cột đóng vai trò là khoá ngoại của một bảng Fact. Không giống như các chỉ số truyền thống lưu trữ thông tin để dịch giá trị của một cột thành một danh sách các hàng với giá trị đó, một STARjoin chứa đựng thông tin nén liên kết các chiều của bảng Fact tới các hàng chứa các chiều này. Nó có hiệu quả về không gian vì vậy nó được xây dựng và duy trì rất nhanh. Nhờ có STARindex mà RDBMS có thể xác định được các hàng đích trong một bảng Fact cần thiết cho một tập các chiều cụ thể một cách nhanh chóng vì STARindex được tạo ra nhờ các khoá ngoại. Mọi kiểu truy vấn đều có thể sử dụng STARindex và kết hợp các bảng có quan hệ với nhau một cách nhanh nhất. Có một số điểm tương tự và một số điểm khác nhau cơ bản giữa STARindex và việc đánh chỉ số nhiều cột truyền thống. Thứ nhất là đánh chỉ số nhiều cột chỉ tham chiếu tới một bảng đơn, còn STARindex có thể tham chiếu tới nhiều bảng. Thứ hai là với phương pháp đánh chỉ số nhiều cột, nếu một mệnh đề WHERE của một câu truy vấn không bị ràng buộc trên tất cả các cột trong bảng chỉ số ghép thì bảng chỉ số đó không thể được sử dụng đầy đủ trừ khi các cột cụ thể đó là một tập con các cột chính. Thuật toán STARjoin có thể sử dụng sức mạnh và tính linh hoạt của STARindex để xác định tất cả các hàng được đòi hỏi trong một kết hợp cụ thể một cách hiệu quả. Chẳng hạn, thay vì tạo ra tích Đề các đầy đủ của các bảng chiều, STARjoin có thể dùng STARindex để kết hợp các bảng chiều với bảng Fact mà không tốn chi phí tạo ra tích Đề các. STARindex cho phép STARjoin xác định nhanh chóng khu vực nào của không gian tích Đề các chứa những hàng cần quan tâm. Thuật toán STARjoin có thể tạo ra tích Đề các của những vùng có các hàng cần thiết và bỏ qua những những vùng không có hàng nào. Xét ví dụ sau để thấy rõ điều đó. 5.4.2. Đánh chỉ số index theo kiểu Bitmap Một cách khác để tăng công suất thực hiện RDBMS là sử dụng kĩ thuật đánh chỉ số mới cho phép truy nhập nhanh, trực tiếp tới dữ liệu. Những chỉ số không trỏ tới dữ liệu được lưu trữ ở nơi khác mà tất cả dữ liệu được lưu trữ trong cấu trúc chỉ số này. Lực lượng dữ liệu: Nói chung, tệp chỉ số bitmap được dùng cho những truy vấn với dữ liệu lực lượng ít. Chẳng hạn, lực lượng của dữ liệu về mã bang là 51 (mã bang có thể nhận 1 trong 50 giá trị), lực lượng của thuộc tính về giới tính là 2 (gồm nam và nữ). Đối với những dữ liệu lực lượng ít, mỗi giá trị phân biệt có chỉ số bitmap của riêng nó bao gồm một bit cho mỗi hàng trong bảng. Có một bảng về người làm thuê gồm 10000 hàng chứa một cột ‘giới tính’ được đánh chỉ số bitmap cho giá trị này. Sự thể hiện của tệp chỉ số bitmap là một vector độ dài 10000 bit, mỗi bit tương ứng với bản ghi thoả mãn điều kiện giá trị của ‘giới tính’=’M’(con trai) thì là 1. Tệp chỉ số bitmap có thể trở nên cồng kềnh và thậm chí không phù hợp đối với dữ liệu có lực lượng lớn khi phạm vi giá trị của dữ liệu là lớn. Chẳng hạn, các giá trị như ‘thu nhập’ hoặc ‘tiền lợi tức’ có thể là một con số có giá trị không xác định. Một giải pháp dễ thấy là biểu diễn các loại dữ liệu này trong một khoảng giá trị ví dụ như khoảng giá trị từ 10$ tới 50$ và 51$ tới 100$. Nhưng cách này hạn chế khă năng của chỉ số bitmap và thường không hiệu quả hoặc không có nghĩa khi giải quyết những công việc trong thực tế. Một giải pháp khác là sử dụng cấu trúc chỉ số B_tree( cây nhị phân). Tuy nhiên, phương pháp này có thể làm tăng kích thước bởi vì khi khối lượng dữ liệu và số lượng các chỉ số tăng thì chúng đòi hỏi thường xuyên được duy trì khi dữ liệu được thêm vào, được cập nhật hay được xoá đi khỏi cơ sở dữ liệu. Cuối cùng, chỉ số B-tree có thể cải thiện một cách đáng kể công suất truy vấn nếu kiểu câu hỏi truy vấn được biết trước và tệp chỉ số được xây dựng để phản ánh đường dẫn truy nhập đã được biết trước. Nhưng B-tree có thể không hiệu quả đối với những câu truy vấn đặc biệt điển hình của các ứng dụng DW. SYBASE IQ đã sử dụng công nghệ độc quyền là Bit-Wise để xây dựng tệp chỉ số bitmap cho những dữ liệu có lực lượng lớn hơn 1000 giá trị phân biệt (so với công nghệ truyền thống là dưới 250 giá trị). Các loại chỉ số: SYBASE IQ với phiên bản đầu tiên cung cấp 5 kĩ thuật đánh chỉ số. Việc lựa chọn phương pháp nào là tuỳ thuộc vào lực lượng của dữ liệu và cách truy nhập vào dữ liệu như thế nào. Hầu hết đều áp dụng 2 chỉ số cho mỗi cột. Môt loại là mặc định được gọi là chỉ số chiếu nhanh (Fast Projection index) và một loại khác là chỉ số lực lượng thấp hoặc cao. Đối với dữ liệu có lực lượng thấp SYBASE IQ cung cấp: Low-fast index dùng cho những câu truy vấn liên quan tới các chức năng nhiều ngôi như SUM, AVERAGE và COUNTS Low disk index được dùng cho việc sử dụng không gian đĩa Tương tự đối với dữ liệu lực lượng lớn, SYBASE IQ cung cấp chỉ số High Group và High Non-Group. Cả hai đều hỗ trợ những truy vấn kết hợp và khôi phục nhưng High Group còn hỗ trợ những truy vấn loại Group By. 5.4.3. Column Local Storage Một phương pháp khác để cải tiến hiệu suất thực hiện truy vấn trong môi trường DW là của các nhà cung cấp các hệ thống song song. Cách tiếp cận này dựa trên việc lưu trữ dữ liệu đảo cột như kho dữ liệu đảo hàng truyền thống. Trong môi trường DW, đối với các truy vấn đặc biệt mục tiêu là phải lấy được nhiều giá trị từ nhiều cột khác nhau. Ví dụ, tính giá trị trung bình lương nhân viên trong một công ty thì kho dữ liệu đảo cột của trường lương đòi hỏi một DBMS chỉ đọc một bản ghi. Vì vậy, nếu DB hỗ trợ kho dữ liệu đảo cột thì giá trị của cột mong muốn từ nhiều hàng có thể được lưu trữ như một bản ghi vật lí đơn trong bộ nhớ và trong đĩa cứng. Lợi ích của kĩ thuật này rất rõ ràng- một thao tác vào/ra có thể lấy được một bản ghi dài bao gồm một tập con các cột. Kết hợp kĩ thuật này với RDBMS song song cải thiện được đáng kể công suất thực hiện. 5.5 Mô hình dữ liệu đa chiều Một cách để quan sát một mô hình dữ liệu nhiều chiều là nhìn nó như một hình khối. Hình sau thể hiện câu truy vấn theo bốn chiều: sản phẩm, thị trường, thời gian và đơn vị sản phẩm bán được. Máy tính Q1 T.Gian S.Phẩm 1200 1500 1800 2100 T.trường Q2 Q3 Q4 Sản phẩm Thị trường Thời gian Đơnvị Q2 Q1 Máy tính HaNoi Q1 1200 Máy tính HaNoi Q2 1500 Máy tính HaNoi Q3 1800 Máy tính HaNoi Q4 2100 Máy tính Nam Định Q1 1000 Máy tính Nam Định Q2 1100 . . . . . . . . . . . . Máy in Hai Phòng Q1 250 máy in Hai Phòng Q2 300 Mô hình dữ liệu đa chiều Bảng nằm bên trái chứa dữ liệu bán hàng chi tiết theo sản phẩm, thị trường và thời gian. Hình khối nằm bên phải mô tả số lượng hàng bán được theo các chiều- theo loại sản phẩm, theo thị trường và theo thời gian-với các biến đơn vị được tổ chức như là các tế bào trong các dãy. Hình khối này có thể được mở rộng bao gồm thêm một dãy khác-theo một chiều khác nữa là giá tiền-liên quan tới tất cả hoặc chỉ một vài chiều (giá tiền của một sản phẩm có thể hoặc không thay đổi theo thời gian hoặc không thay đổi từ thành phố này tới thành phố khác). Khối này được hỗ trợ tính toán ma trận cho phép khối này thể hiện cả dãy số tiền bán được đơn giản bằng cách thực hiện một phép toán ma trận trên tất cả các ô của dãy này. Thời gian trả lời một truy vấn nhiều chiều phụ thuộc vào số lượng các ô được thêm vào trong quá trình thực hiện. Khi số lượng chiều tăng thì số ô của khối này tăng theo cấp số mũ. Bên cạnh đó, những truy vấn đa chiều đều liên quan tới những dữ liệu ở mức cao và dữ liệu tổng. Vì vậy, giải pháp để xây dựng một cơ sở dữ liệu đa chiều có hiệu quả là phải kết hợp từ trước tất cả các tổng con logic và các tổng theo tất cả các chiều. Sự kết hợp trước này đặc biệt có giá trị khi các chiều mang tính phân cấp. Một cách để giảm kích thước của khối là quản lí một lượng dữ liệu thưa hơn một cách thích hợp. Một loại dữ liệu thưa khác được tạo ra khi có nhiều ô chứa dữ liệu bị lặp lại. Khả năng của cơ sở dữ liệu đa chiều bỏ qua các ô không có dữ liệu hoặc dữ liệu bị lặp lại có thể giảm được khá nhiều kích thước của khối và số lượng các xử lí. 5.7 ROLL_UP VÀ DRILL_DOWN Một trong những nguyên tắc nền tảng của cơ sở dữ liệu đa chiều là ý tưởng về tổng hợp dữ liệu. Các nhà quản lý ở các cấp bậc khác nhau yêu cầu các mức tổng hợp dữ liệu khác nhau để ra được những quyết định phù hợp. Muốn vậy, kho chứa phải có khả năng drill_down, cho phép điều chỉnh mức chi tiết, thậm chí đến tận dữ liệu tác nghiệp ban đầu. Roll_up là một kiểu tổng hợp thông dụng nhất. VI. TẠO LẬP CÁC KHO DỮ LIỆU Xây dựng kho dữ liệu là quá trình tích hợp dữ liệu từ các nguồn khác nhau vào một kho. Các nhà phân tích nghiệp vụ có thể truy vấn kho dữ liệu và sinh các báo cáo, biểu đồ để trợ giúp quá trình ra quyết định của họ. Một kho dữ liệu có thể chứa CSDL lớn toàn xí nghiệp hoặc có thể kết hợp một số hệ thống nhỏ (DM). Các nguồn dữ liệu bao gồm các hệ thống dữ liệu ở bên trong, hoặc bên ngoài của một tổ chức hay một xí nghiệp. Các hệ thống dữ liệu về một tổ chức được coi như các hệ thống dữ liệu bên trong, thường là những hệ thống thông tin có sẵn (Legacy System-LS). Đó là những hệ thống tác nghiệp, hỗ trợ các hoạt động nghiệp vụ như sản xuất, hay kinh doanh. Hệ thống này đã từng được phát triển, sử dụng các công nghệ có sẵn và vẫn phù hợp với các nhu cầu của kinh doanh hiện tại. Dữ liệu bên ngoài ( External Data): là dữ liệu không nằm trong các hệ thống tác nghiệp của tỏ chức đó, là những dữ liệu do người sử dụng đầu cuối yêu cầu để điền vào bức tranh tổng thể phục vụ các nhu cầu công việc của họ. 6.1 Phân tích các nguồn dữ liệu Các LS được phát triển xung quanh các vùng nghiệp vụ của cơ quan cầ xây dựng dự án. Các ứng dụng được phát triển với dữ liệu mà các dữ liệu này phù hợp với các nhu cầu khác nhau, với cùng một hệ thống dữ liệu nhưng với tên khác nhau, hoặc với các hệ thống đo lường khác nhau, định nghĩa dữ liệu thậm chí chúng có những yêu cầu về dữ liệu tương tự như nhau. Kết quả cuối cùng là các nguồn dữ liệu cần được đánh giá và các định nghĩa dựa vào Metadata để nhắm tới các vấn đề sau: -Xác định các nguồn, các cấu trúc file, các platform khác nhau. -Hiểu được dữ liệu nào có trong các hệ thống nguồn đang tồn tại, các định nghĩa về nghiệp vụ của dữ liệu, và bất kì các luật nghiệp vụ nào cho dữ liệu. -Phát hiện sự giao nhau về thông tin của các hệ thống khác nhau. -Quyết định dữ liệu tốt nhất trong các hệ thống, có thể cùng một dữ liệu của nhiều hơn một hệ thống. Mỗi hệ thống cần được đánh giá để quyết định hệ thống nào có dữ liệu rõ ràng và chính xác hơn. 6.2. Thu thập và tạo lập dữ liệu Một phần quan trọng của việc cài đặt kho dữ liệu là sử dụng những dữ liệu đã được tinh chế từ những hệ thống tác nghiệp và đưa chúng vào một khuôn dạng thích hợp cho các ứng dụng thông tin. Những công cụ này thực hiện tất cả các công việc chuyển đổi, tóm tắt những thay đổi quan trọng, những thay đổi về cấu trúc và những cô đọng cần thiết cho sự chuyển đổi dữ liệu riêng rẽ thành thông tin có thể được dùng trong những công cụ hỗ trợ quyết định. Các chức năng chính là: Loại bỏ những dữ liệu không mong muốn từ những cơ sở dữ liệu tác nghiệp; Chuyển đổi thành những tên gọi và những định nghĩa dữ liệu chung, tổng quát; Tính toán các tổng và dữ liệu đã được chuyển hóa; Thiết lập những mặc định cho các dữ liệu bị mất; Làm cho những thay đổi về định nghĩa dữ liệu nguồn trở nên thích hợp. Những công cụ này có thể tiết kiệm được một cách đáng kể thời gian và sức lực. Tuy nhiên nhiều công cụ có sẵn thường chỉ có ích cho việc tinh chế những dữ liệu đơn giản. Do đó việc phát triển những thủ tục tinh chế cho một số lĩnh vực ứng dụng là cần thiết cho việc tinh chế dữ liệu. Các công đoạn thực hiện bao gồm: Trích chọn dữ liệu; Lọc, tinh chế dữ liệu; Thẩm định dữ liệu; Gộp, kết tập dữ liệu; Tải dữ liệu vào kho; Lưu trữ và phát tán, phân phối dữ liệu Quá trình này thu thập và thiết lập các kho dữ liệu gồm những bước sau: Source Load Archive Target Extract Filter Validate Aggregate Merge Quá trình tạo lập dữ liệu của DW a/ Trích chọn dữ liệu (Etract): Trích chọn dữ liệu là một phép xử lí để lấy các dữ liệu đã được xác định trước ra khỏi các hệ thống tác nghiệp và các nguồn dữ liệu bên ngoài. Có thể trong các hệ thống dữ liệu gốc có một vài vấn đề như: không có đủ thông tin chi tiết về hệ thống. Khi đó, cần phải xoá đi những thông tin không chính xác, hoặc bổ sung cho đủ thông tin và mở rộng hệ thống làm việc để thu nhặt đầy đủ thông tin. Việc lưu trữ các biến động dữ liệu giúp ích cho quá trình nạp dữ liệu cụ thể có thể chỉ cập nhật phần bổ sung thay vì cập nhật toàn bộ dữ liệu (total refresh). Bước quan trọng là phải lập kế hoạch và tần suất tiến trình trích chọn dữ liệu. Mục đích của bước này là phải tối thiểu hoá các tác động lên các hệ thống và thi hành các tác vụ này trong một cửa sổ xử lý theo lô (batch window). Đối với các bảng dữ liệu khác nhau thì tần suất trích dữ liệu sẽ khác nhau. Việc trích dữ liệu còn phụ thuộc vào sự ảnh hưởng từ hệ thống nguồn và loại dữ liệu sẽ được trích. Có các công cụ và các chương trình tiện ích phục vụ cho quá trình trích chọn dữ liệu. Chẳng hạn, các trình tiện ích nạp nhanh để trích lấy dữ liệu, các phương tiện dễ dàng tái tạo lại cơ sở dữ liệu. Các vấn đề xung quanh việc trích chọn dữ liệu bao gồm cơ cấu thời gian trong đó dữ liệu được trích lấy và hiệu quả của việc trích chọn dữ liệu đó. Trong bất kì phương thức nào được chọn để trích lấy dữ liệu, Metadata cũng đóng vai trò quan trọng của quá trình xử lí. Metadata mẫu bao gồm các phần: các định nghĩa của hệ thống nguồn, các khuôn dạng vật lí, phương thức và bản liệt kê của sự trích chọn dữ liệu. Có thể dùng các công cụ hoặc tạo tài liệu bằng tay để thu được Metadata . b/ Lọc (Filter), làm sạch dữ liệu (Cleaning) Sau khi dữ liệu được trích chọn, nó được tinh chế thông qua các công việc lọc, làm sạch để thu dữ liệu dữ liệu không bị thay đổi và đúng với các dữ liệu nghiệp vụ. Quá trình trình lọc, làm sạch dữ liệu kiểm tra và sửa chữa các lỗi có thể có của dữ liệu để đảm bảo tính đúng đắn của dữ liệu. Công việc này bao gồm các thao tác dọn dẹp (scrub), thay đổi và tính toán lại dữ liệu. Làm sạch dữ liệu liên quan tới một số hoặc tất cả các tác vụ sau: kiểm tra tất cả các trường đơn lẻ hoặc các trường có liên kết chéo nhau, đưa ra và hợp nhất các bản ghi trùng nhau, thu nhặt sắp xếp lại các bản ghi giống nhau mà bị thiếu các khoá bình thường từ các hệ thống khác nhau. Có 5 bước để làm sạch dữ liệu: Chỉ ra được tiêu chí dữ liệu như thế nào được gọi là dữ liệu sạch. Chỉ ra được mối quan tâm của người sử dụng để kiểm tra và đánh giá dữ liệu ngay sau lần truy cập dữ liệu đầu tiên. Lập ra bản báo cáo về lỗi của dữ liệu nếu dữ liệu vi phạm tiêu chí trên. Tìm ra chiến lược để sửa các lỗi trên có thể làm bằng tay hoặc tự động. Tìm ra chiến lược lâu dài bằng cách sửa lại hệ thống thực hiện hoặc đưa ngược thông tin đó từ Data Warehouses vào hệ thống thực hiện. Các phương pháp làm sạch dữ liệu: Sắp xếp và làm sạch dữ liệu. Xác định các vùng và phạm vi. Các thuật toán thông minh. Logic mờ. Cho dù phương pháp nào được chọn đi nữa thì cũng cần phải lặp đi lặp lại các bước sửa lỗi cho hệ thống thi hành hoặc thực hiện lại quá trình làm sạch khác với một số dữ liệu vừa được làm sạch. Quá trình làm sạch liên quan đến các tác vụ: Kiểm tra các trường dữ liệu đơn lẻ và kiểm tra các trường có mối liên hệ với trường khác. Chỉ ra và tổng hợp các bản ghi trùng nhau cũng như sắp xếp lại các bản ghi giống hệt nhau bị thiếu khoá từ các hệ thống khác nhau. c/ Thẩm định (Validate) và chuyển đổi (Transforming) dữ liệu Tiếp theo, dữ liệu phải được kiểm tra, thẩm định để đảm chất lượng nhằm đáp ứng các yêu cầu phân tích phục vụ trợ giúp quyết định. Các công cụ hỗ trợ để thực hiện những công việc nêu trên dựa vào một tập các thông số đã được xác định trước, và có thể sử dụng logic mờ hoặc triển khai các thuật toán heuristic. Các thuật toán heuristic có tập luật mở rộng và mô phỏng suy diễn của con người để làm cho việc điều tra tiến hành được nhanh hơn. Trước khi có thể chuyển đổi dữ liệu, nên thiết lập hệ thống đo lường và chuẩn hoá các nghĩa trong nghiệp vụ. Mục đích của việc chuyển đổi và tích hợp là chuyển dữ liệu thành thông tin và làm cho chúng dễ hiểu và dễ sử dụng hơn đối với NSD đầu cuối. Mô hình dữ liệu đích có thể khác so v