Mục tiêu của data-warehouse

Một Data Warehouse phải đảm bảo được các mục tiêu sau:
Truy cập dễ dàng:
Thông tin lưu trữ trong data warrehouse phải trực quan và dễ hiểu đối với người dùng. Nói cách khác, dữ liệu nên được trình bày thông qua các tên gọi quen thuộc và gần gũi với nghiệp vụ của người dùng.

Qua một số dự án đã làm tôi thấy có thể phân chia businiess user ra 2 loại. Người dùng cấp thấp chủ yếu thao tác trên các thông tin chi tiết. Chẳng hạn như nhập số liệu về một khách hàng, theo dõi các giao dịch của khách hàng cụ thể đó... Report cho dạng công việc kiểu này thường là thông tin chi tiết về một khách hàng, hoặc một danh sách các khách hàng. Những report kiểu này có thể lấy ra trực tiếp từ operational database.

Người dùng cấp cao lại chủ yếu xử lý dữ liệu ở mức độ tổng hợp, để từ đó phân tích rồi đưa ra các quyết định mang tính định hướng cho nghiệp vụ. Họ không quan tâm đến một khách hàng cụ thể nào cũng như không cần phải để ý cả một danh sách 1000 khách hàng. Thay vào đó, cái làm họ bận tâm là số lượng khách hàng sử dụng dịch tăng/giảm 25% trong quý IV so với quý III cùng năm và tăng/giảm 45% so với cùng quý IV năm ngoái. Từ các thông số này, họ mới đưa ra quyết định sẽ làm gì để cải thiện tình hình hoặc đặt ra mục tiêu tăng trưởng 30% cho quý IV năm tới. Đây là đối tượng chủ yếu của Data Warehouse.

Do vậy, thông tin cho loại đối tượng này càng dễ hiểu và gần với thực tế càng tốt. Một ví dụ dễ thấy là thay vì sử dụng các code, data warehouse nên thể hiện thông tin bằng các description hoặc name.

Một điều nữa cần bàn đến là tốc độ truy cập data warehouse phải nhanh. Do phải xử lý một số lượng lớn bản ghi cùng một lúc, performance là một trong những yêu cầu phải có của một dw. Đây là nơi mà các kỹ thuật tuning database được dịp phát huy hết công suất: query tuning, query hints, indexes, parallel processing, partition, materialized views....

Riêng bản thân tôi nghĩ, đối với những người xây dựng dw, đây là mảnh đất tốt để nâng cao khả năng làm việc với database lên mức expert. Mặc dù không chính thức bắt buộc, nhưng phần lớn những người làm dw tốt đều có kiến thức rất sâu về database. Nhiều người thậm chí còn ở mức DB Administrator. Với nhu cầu về dữ liệu càng lúc càng lớn như hiện nay, sở hữu nhiều kỹ năng tốt cùng một lúc có thể đem lại cho bạn nhiều lựa chọn và lợi thế hơn trong thị trường việc làm.

Thông tin nhất quán:

Dữ liệu trong một data warehouse nhìn chung thường đến từ nhiều nguồn khác nhau. Do vậy, cùng một thông tin nhưng các nguồn khác nhau có thể trình bày nó theo các kiểu khác nhau, thậm chí còn sai lệch ít nhiều. Một ví dụ đơn giản là cùng khách hàng tên Huy Nguyen, database A lưu trữ thông tin này trong 2 trường First_Name và Last_Name, trong khi database B có thể chỉ có một trường duy nhất Ho_va_Ten. Một cái tên công ty như International Business Trading trong database A được thể hiện đầy đủ như trên, nhưng trong database B có khi lại được trình bày dưới dạng viết tắt như Intl. Biz Trading.

Một đặc điểm nữa của dữ liệu database là không có database nào chứa dữ liệu sạch 100%. Cho dù có là dữ liệu của một công ty hàng đầu về IT như Google, Amazon, Microsoft... đảm bảo vẫn có lỗi. Database càng to càng dễ có dữ liệu không sạch. Một ví dụ dễ thấy là một trường Description có thể chứa các ký tự điều khiển CR LF. Điều này xảy ra khi người dùng nhấn Enter nhiều lần để tạo ra các đoạn văn bản trong cùng một ô area box. Nhiều lúc dữ liệu sai xuất hiện trong database là do lỗi lập trình. Tôi đã gặp một trường hợp như sau. Một trường datetime trong Oracle database có giá trị hẳn hoi (not null) nhưng không sao convert được sang kiểu varchar2. Tìm hiểu một hồi mới thấy trong một số bản ghi, giá trị thực của trường đó là... vô định, tức là dữ liệu thì có nhưng nó không mang một giá trị cụ thể nào. Lý do có lẽ là một Java developer nào đó khi tạo lập một Date instance .... quên mất không assign một giá trị nào cho đối tượng đó. Do vậy, đối tượng thì có nhưng giá trị thực trong nó thì vô định. Về mặt kỹ thuật mà nói, điều này vẫn hợp lệ nên vẫn được chèn vào database. Chỉ khi nào convert dữ liệu thì lỗi này mới xuất hiện, nếu không nó sẽ "nằm im" trong suốt cả vòng đời của ứng dụng mà không ai biết.

Nói vậy để thấy, trước khi được đưa vào data warehouse, dữ liệu cần phải được làm sạch và đảm bảo về chất lượng. Có làm sạch rồi thì việc đồng nhất dữ liệu mới trở nên dễ dàng. Một nguyên tắc đơn giản được đặt ra cho quá trình này là:
- Nếu dữ liệu có cùng tên, chúng bắt buộc phải cùng chỉ đến một thực thể.
- Ngược lại, nếu dữ liệu chỉ đến các thực thể khác nhau, chúng phải được đặt tên khác nhau.

Đây chính là những công việc chủ đạo của quá trình ETL (Extract - Transform - Load).

Thích nghi với thay đổi:
Thay đổi là điều không thể tránh khỏi cho bất cứ ứng dụng nào, không riêng gì data warehouse. Do vậy, data warehouse cần phải được thiết kế để xử lý những thay đổi có thể xảy ra. Nói vậy có nghĩa là khi có thay đổi mới, dữ liệu cũ trong data vẫn phải được bảo tồn tính đúng đắn.

Bảo mật:
Dữ liệu trong data warehouse đến từ nhiều nguồn khác nhau, do vậy hiển nhiên việc bảo đảm những thông tin không lộ ra ngoài là một yêu cần thiết yếu. Để lộ dữ liệu của một database đã là cực kỳ nghiêm trọng. Để lộ dữ liệu từ nhiều database là thảm họa.

Hỗ trợ ra quyết định:
Đây có thể nói là mục tiêu quan trọng nhất của doanh nghiệp khi xây dựng data warehouse. Mặc dù có những trường hợp xây dựng một cơ sở dữ liệu tập trung để thu thập data từ nhiều nguồn khác nhau, nhưng tôi cho rằng những trường hợp như vậy nên gọi là data integration (tích hợp dữ liệu) chứ không phải data warehouse. Một doanh nghiệp trước khi xây dựng data warehouse, nên tự đặt câu hỏi liệu data warehouse đó có giúp ích gì trong việc ra quyết định kinh doanh của doanh nghiệp không.

Lý thuyết về các hệ hỗ trợ quyết định (Decision Support System) thì có lẽ đủ để viết mấy quyển sách dày hàng trăm trang. Tôi còn nhớ hồi đi học ở khoa Công nghệ đã từng được học một môn như vây, nhưng chỉ dừng ở mức lý thuyết. Đến khi đi làm về data warehouse, mới dần dần nắm bắt được thế nào là một DSS. Nói một cách nôm na trong phạm vi của data warehouse, người ta muốn dựa vào thông tin để từ đó thấy được cần phải làm những gì để kinh doanh đạt kết quả tốt nhất.

Công cụ gần nhất và dễ dùng nhất là dựa trên các báo cáo (report) và phân tích. Kinh nghiệm của tôi cho thấy người dùng thường tạo ra các trend report để thể hiện xu hướng hoạt động thay đổi như thế nào theo thời gian. Đây là một chỉ số quan trọng và thông dụng trong nhiều tổ chức. Các KPI (Key Performance Indicators) có lẽ được xây dựng dựa trên thực tế này. Một kiểu report nữa hay gặp là dashboard, trong đó thực ra là chứa rất nhiều reports liên quan với nhau được thể hiện dưới dạng các biểu đồ (chart). Lợi thế của dashboard là nó rất trực quan, nhìn vào đó người ta có thể ngay lập tức hình dung được tình hình hoạt động của công ty.

Với data warehouse, người dùng có thể dễ dàng xây dựng các report như trên. Đồng thời, từ data warehouse, người ta có thể xây dựng các cube mà không tốn quá nhiều công sức. Dựa trên cube, các công cụ phân tích sẽ được dùng để phân tích dữ liệu cực kỳ nhanh chóng và trực quan.

Thành công:
Hiển nhiên sản phẩm được tạo ra cũng phải hướng đến thành công. Trong trường hợp của data warehouse, nó phải đem lại giá trị thực tế cho người dùng như đã nói ở trên và phải được dùng liên tục thì mới được coi là thành công. Việc có hay không có Data Warehouse trong một tổ chức hoàn toàn không mang tính bắt buộc. Không có data warehouse, người ta vẫn có thể tạo ra report nhưng dĩ nhiên mất nhiều công sức hơn. Để được công nhận, giá trị business mà data warehoue đem lại phải lớn hơn công sức và tiền của bỏ ra đầu tư vào nó.

Trong nhiều tổ chức, business user ban đầu thường không hề có chút ý niệm về data warehouse hoặc thậm chí hoài nghi về nó. Nhưng một khi người dùng đã quen với nó, người ta sẽ thích nó và muốn ngày càng có nhiều dữ liệu hơn trong data warehouse đơn giản bởi vì nó cung cấp rất nhiều lựa chọn và hỗ trợ ra quyết định khá tốt. Đó gọi là thành công.
copy from fotech.org
Tác giả: Huy Nguyen