Phân Tích Kho Dữ Liệu Trong Kinh Doanh: Sách Tham Khảo [PDF]

Zitiervorschau

ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH TRƯỜNG ĐẠI HỌC KINH TẾ - LUẬT

SÁCH THAM KHẢO

PHÂN TÍCH KHO DỮ LIỆU TRONG KINH DOANH Nhóm tác giả: ThS Hồ Trung Thành (chủ biên) ThS Triệu Việt Cường ThS Lê Thị Kim Hiền ThS Vũ Thúy Hằng ThS Lê Hoành Sử

NHÀ XUẤT BẢN ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH – 2016 1

2

LỜI NÓI ĐẦU Ngày nay, xu hướng ứng dụng công nghệ thông tin vào quản lý và vận hành các quy trình nghiệp vụ trong doanh nghiệp ngày càng phát triển nhanh chóng, đặc biệt là việc áp dụng các hệ thống thông tin trong quản lý và kinh doanh. Cụ thể, không thể không nhắc đến đó là hệ thống hoạch định nguồn lực doanh nghiệp (Enterprise Resource Planning - ERP). Việc ứng dụng hệ thống ERP trong doanh nghiệp sẽ tạo ra một lượng dữ liệu tác nghiệp hàng ngày rất lớn. Nếu nhìn từ khía cạnh tác nghiệp, điều này chưa thật sự quan trọng, tuy nhiên trong môi trường cạnh tranh giữa các doanh nghiệp, việc tận dụng những cơ hội dù nhỏ nhất cũng tạo nên sự khác biệt để đạt lợi thế cạnh tranh đó. Việc quản lý dữ liệu, thông tin và đưa ra những thống kê, báo cáo đóng vai trò rất quan trọng đối với mọi đơn vị, tổ chức và đặc biệt là các doanh nghiệp. Các thống kê báo cáo nhằm cung cấp các thông tin trực quan, chính xác, đầy đủ và kịp thời sẽ giúp các nhà quản trị trong việc đánh giá, dự báo tình hình, hoạch định chiến lược cũng như xây dựng chính sách, kế hoạch phát triển doanh nghiệp trong ngắn và dài hạn. Các con số, biểu mẫu thống kê là cơ sở quan trọng nhất để kiểm tra, đánh giá tình hình thực hiện các kế hoạch, chiến lược và chính sách đó. Tuy nhiên, phần lớn các dữ liệu phục vụ thống kê của các phần mềm quản lý thường rời rạc và chỉ ứng dụng cho các nghiệp vụ cụ thể, chưa hỗ trợ nhiều cho việc ra quyết định và trình diễn thông tin, tri thức một cách có ý nghĩa cho nhà quản trị. Để có thể chuyển dữ liệu tác nghiệp thành thông tin và tri thức hữu ích, các doanh nghiệp cần phải lựa chọn giải pháp, công cụ thích hợp để thực hiện. Giải pháp Business Intelligence (BI) đã và đang được ứng dụng ở rất nhiều quốc gia trên thế giới nói chung và tại Việt Nam nói riêng. Bằng cách tích hợp dữ liệu từ nhiều nguồn khác nhau vào kho dữ liệu và từ đó thực hiện phân tích dữ liệu và tạo báo cáo thống kê, BI cung cấp cho nhà quản trị cái nhìn tổng quan và toàn diện về doanh nghiệp. BI chuyển đổi dữ liệu tác nghiệp của doanh nghiệp thành các thông tin và tri thức trong quản lý và kinh doanh, giúp gắn kết với hoạt động kinh doanh trong nội bộ tổ chức và với các tổ chức đối tác bên ngoài. 3

Thực tế, bất kỳ hệ thống ERP nào cũng trang bị một hệ thống lập báo cáo sẵn có, tuy nhiên sẽ phát sinh vấn đề nếu dữ liệu ngày càng lớn: Dữ liệu quá lớn làm cho thời gian lập báo cáo, phân tích số liệu mất nhiều thời gian gây hao tốn chi phí vận hành, cũng như mất đi cơ hội kinh doanh khi thông tin không được cung cấp kịp thời. Bên cạnh đó ERP vốn là một hệ thống OLTP - được thiết kế phục vụ truy cập đồng thời, lượng giao dịch lớn nhưng không phù hợp cho việc phân tích, tổng hợp và lập báo cáo. Các công cụ tích hợp sẵn trong hệ thống ERP thường không đáp ứng được nhu cầu phân tích dữ liệu chuyên sâu của nhà quản trị. Hệ thống ERP không thể đáp ứng nhu cầu giám sát và cảnh báo cho các nhà quản trị khi tình hình kinh doanh đang gặp phải vấn đề để từ đó có những điều phối thích hợp, giảm thiểu rủi ro cho doanh nghiệp. Vậy giữa BI và ERP có mối liên hệ với nhau như thế nào? Dễ dàng nhận thấy ERP là nơi phát sinh nguồn dữ liệu tác nghiệp. Nếu ERP hỗ trợ cho quản lý tác nghiệp thì BI là giải pháp chuyển đổi dữ liệu tác nghiệp thành thông tin và tri thức, thực hiện các báo cáo phức tạp, đa chiều và có tính tổng hợp cao hỗ trợ cho nhà quản trị. Để giúp cho sinh viên hiểu rõ hơn ở góc độ thực hành về một giải pháp BI, nhóm tác giả đã cho ra đời tài liệu tham khảo Phân tích kho dữ liệu trong kinh doanh này với nội dung trình bày về việc thực hiện chi tiết những góc cạnh của giải pháp BI. Cụ thể hơn, tài liệu này được viết theo dạng tài liệu hướng dẫn chi tiết cho quá trình từng bước thực hiện từ khi xây dựng và khai thác giải pháp BI cho doanh nghiệp. Mặc dù nhóm biên soạn đã cố gắng để hoàn thiện tài liệu từ hình thức cho đến nội dung, tuy nhiên chắc sẽ không tránh khỏi những sai sót. Chính vì vậy, nhóm tác giả rất mong nhận được các ý kiến đóng góp để tài liệu ngày càng được hoàn thiện hơn. Mọi ý kiến xin gửi về địa chỉ mail: [email protected]. Xin chân thành cảm ơn. Nhóm tác giả 4

MỤC LỤC LỜI NÓI ĐẦU..............................................................................iii MỤC LỤC...................................................................................... v DANH MỤC TỪ VIẾT TẮT- THUẬT NGỮ TIẾNG ANH................................................................................. xi Chương 1: TỔNG QUAN VỀ GIẢI PHÁP BI ........................ 1 1.1. BI là gì ..................................................................................... 1 1.2. Kiến trúc BI ............................................................................ 3 1.3. Đạt lợi thế cạnh tranh với giải pháp BI ............................. 6 1.3.1. Cắt giảm chi phí nhân công............................................. 6 1.3.2. Giảm thiểu việc tắc nghẽn thông tin ............................... 7 1.3.3. Làm cho dữ liệu có khả năng thực thi ............................ 8 1.3.4. Các quyết định có chất lượng tốt hơn........................... 10 1.3.5. Các quyết định được đưa ra nhanh hơn........................ 10 1.3.6. Hướng tổ chức đến mục tiêu kinh doanh ..................... 11 1.4. Ai cần hệ thống BI? ............................................................. 12 1.4.1. Các yếu tố bên ngoài dẫn dắt tổ chức hướng tới BI .... 12 1.4.2. Các yếu tố bên trong dẫn dắt tổ chức hướng tới BI..... 13 1.5. Giới thiệu giải pháp BI của Oracle ................................... 14 1.5.1. Oracle Financial Analytics ........................................... 15 1.5.2. Oracle Sales Analytics................................................... 16 1.5.3. Oracle Marketing Analytics .......................................... 16 1.5.4. Oracle Service Analytics ............................................... 16 1.6. Giới thiệu giải pháp BI của Microsoft.............................. 17 Chương 2: KHO DỮ LIỆU VÀ PHÂN TÍCH DỮ LIỆU .... 22 2.1. Giới thiệu về kho dữ liệu .................................................... 22 2.1.1. Phân tích dữ liệu là gì? .................................................. 22 5

2.1.2. Định nghĩa kho dữ liệu .................................................. 23 2.1.3. Đặc điểm của dữ liệu trong kho dữ liệu ....................... 24 2.2. Lợi ích của kho dữ liệu trong kinh doanh ....................... 25 2.2.1. Tại sao cần kho dữ liệu? ................................................ 25 2.2.2. Lợi ích của kho dữ liệu .................................................. 26 2.3. Các xu hướng của kho dữ liệu ........................................... 28 2.4. Hệ hỗ trợ ra quyết định trong doanh nghiệp .................. 31 2.5. Mô hình mẫu kho dữ liệu ................................................... 32 Chương 3: GIỚI THIỆU DỰ ÁN KHO DỮ LIỆU............... 35 3.1. Giới thiệu dự án kho dữ liệu .............................................. 35 3.2. Tổng quan về quy trình thực hiện dự án ......................... 37 3.2.1. Lập kế hoạch dự án........................................................ 37 3.2.2. Xác định dự án và phạm vi ........................................... 37 3.2.3. Xác định yêu cầu nghiệp vụ .......................................... 41 3.2.4. Luồng công nghệ ........................................................... 43 3.2.5. Luồng dữ liệu ................................................................. 50 3.2.6. Luồng ứng dụng............................................................. 56 3.2.7. Triển khai và bảo trì....................................................... 56 Chương 4. THIẾT KẾ KHO DỮ LIỆU.................................. 59 4.1. Phương pháp luận thiết kế kho dữ liệu............................ 59 4.1.1. Phương pháp tiếp cận Top-Down................................. 59 4.1.2. Phương pháp tiếp cận Bottom-Up ................................ 60 4.1.3. So sánh ưu nhược điểm của hai phương pháp tiếp cận .......................................................................... 61 4.2. Mô hình dữ liệu đa chiều.................................................... 62 4.2.1. Bảng sự kiện (Fact Table) trong mô hình đa chiều ..... 64 4.2.2. Bảng chiều (Dimension Table) trong mô hình đa chiều ......................................................................... 67 4.2.3. Kết hợp Fact table và Dimenstion trong mô hình hình sao................................................................. 70 6

4.3. Thiết kế mô hình đa chiều trong lĩnh vực kinh doanh bán lẻ ......................................................................... 72 4.3.1. Bốn bước thiết kế mô hình dữ liệu đa chiều ................ 73 4.3.2. Xây dựng bảng chiều (Dimension Table) .................... 80 4.3.3. Truy vấn dữ liệu trong lược đồ hình sao (Star Schemas).............................................................. 91 4.3.4. Factless Fact Tables ....................................................... 92 4.3.5. Các khóa trong bảng sự kiện và bảng chiều ................ 93 4.3.6. Lược đồ hình bông tuyết (Snowflake Schemas).......... 98 4.4. Xây dựng nhà kho dữ liệu theo kiến trúc Bus ................ 99 4.5. Thiết kế nhà kho dữ liệu với CSDL Adventure Works.... 102 4.5.1. Giới thiệu CSDL mẫu Adventure Works................... 102 4.5.2. Phân tích quy trình nghiệp vụ bán hàng ..................... 103 4.5.3. Phân tích dữ liệu nguồn ............................................... 104 4.5.4. Xây dựng mô hình Data Warehouse .......................... 106 Chương 5: TÍCH HỢP DỮ LIỆU.......................................... 111 5.1. Tổng quan về tích hợp dữ liệu ......................................... 111 5.1.1. Khái niệm ..................................................................... 111 5.1.2. Phương pháp và công nghệ tích hợp dữ liệu.............. 112 5.2. T ch hợp ữ liệu với tiến trình ETL ............................... 117 5.2.1. r ch uất dữ liệu......................................................... 118 5.2.2. Chuyển đổi dữ liệu ...................................................... 122 5.2.3. Tải dữ liệu .................................................................... 123 5.2.4. ác vấn đề gặp phải khi t ch hợp dữ liệu và giải pháp ...................................................................... 123 5.3. Giới thiệu công nghệ SSIS................................................ 125 5.3.1. Import and Export Wizard .......................................... 126 5.3.2. SQL Server Data Tools ............................................... 126 5.3.3. Packages (gói) .............................................................. 127 7

5.3.4. Tasks (tác vụ) ............................................................... 127 5.3.5. Data flow (luồng dữ liệu) ............................................ 128 5.3.6. Sources (nguồn) ........................................................... 129 5.3.7. Destinations (đ ch) ....................................................... 130 5.3.8. Transformations (biến đổi dữ liệu) ............................. 130 5.4. Tích hợp dữ liệu với SSIS................................................. 132 5.4.1. Tạo một SSIS Project .................................................. 132 5.4.2. Tạo một Package ......................................................... 134 5.4.3. Luồng điều khiển (Control Flow) ............................... 137 5.4.4. Dòng dữ liệu (Data flow) ............................................ 145 5.4.5. Tải dữ liệu vào Data Warehouse ................................ 156 5.5. Thực hành SSIS với CSDL AdventureWorks .............. 162 Chương 6: PHÂN TÍCH DỮ LIỆU VÀ BÁO CÁO ........... 182 6.1. Tổng quan phân tích dữ liệu trong kinh doanh ........... 182 6.2. Kỹ thuật OLAP.................................................................. 184 6.2.1. Khái niệm OLAP ......................................................... 184 6.2.2. So sánh OLAP với OLTP ........................................... 186 6.2.3. Phân tích nhiều chiều................................................... 188 6.2.4. Mô hình dữ liệu nhiều chiều ....................................... 189 6.3. Phân tích dữ liệu với công nghệ SSAS ........................... 191 6.3.1. Công nghệ SSAS ......................................................... 191 6.3.2. ài đặt và sử dụng công nghệ SSAS .......................... 192 6.3.3. Xây dựng KPI trong phân tích dữ liệu với công nghệ SSAS......................................................... 199 6.4. Phân tích dữ liệu bằng ngôn ngữ MDX ......................... 202 6.4.1. Giới thiệu ngôn ngữ MDX .......................................... 202 6.4.2. Lịch sử phát triển MDX .............................................. 203 6.4.3. So sánh SQL với ngôn ngữ truy vấn nhiều chiều MDX ................................................................. 204 8

6.4.4. Cấu trúc câu truy vấn MDX ........................................ 205 6.4.5. Một số hàm thông dụng trong MDX .......................... 210 6.5. Phân tích dữ liệu bằng công cụ Microsoft Excel .......... 217 6.5.1. Hệ thống các báo cáo................................................... 218 6.5.2. Phân tích dữ liệu bằng công cụ của Microsoft Excel.... 219 6.6. Tạo và quản lý báo cáo bằng công nghệ SSRS ............. 229 6.6.1. Khái niệm ..................................................................... 229 6.6.2. ác bước thực hiện việc xây dựng một báo cáo ........ 230 6.6.3. Một số kết quả báo cáo bằng công nghệ SSRS ......... 237 Chương 7: CHỈ SỐ ĐO LƯỜNG HIỆU SUẤT KINH DOANH .................................................. 240 7.1. Tổng quan về KPI ............................................................. 240 7.2. Đặc điểm của KPIs ............................................................ 242 7.2.1. hước đo phi tài ch nh ................................................ 242 7.2.2. Đo lường thường xuyên .............................................. 242 7.2.3. Đối tượng sử dụng KPIs.............................................. 243 7.2.4. Điều chỉnh hoạt động kinh doanh ............................... 243 7.2.5. Gắn kết trách nhiệm rõ ràng........................................ 243 7.2.6. Ảnh hưởng tích cực của KPIs ..................................... 243 7.3. KPIs trong doanh nghiệp ................................................. 243 7.4. Xây dựng KPIs................................................................... 245 7.4.1. Nền tảng mối quan hệ cộng tác................................... 245 7.4.2. Sức mạnh của hoạt động tiếp xúc trực tiếp với khách hàng .................................................................. 246 7.4.3. Tích hợp các thước đo, báo cáo cải tiến hiệu quả hoạt động ............................................................. 247 7.4.4. Liên kết thước đo hiệu năng với chiến lược của công ty .................................................................. 247 7.4.5. Xác định tầm nhìn, sứ mệnh và chiến lược của tổ chức ......................................................................... 250 9

7.5. Triển khai KPIs trong phân tích dữ liệu ....................... 250 7.5.1. Dashboard .................................................................... 250 7.5.2. Báo cáo về các chỉ số đo lường hiệu năng ................. 252 7.5.3. Báo cáo đánh giá hiệu năng dành cho nhân viên....... 253 7.5.4. Một số thể loại KPIs ứng dụng trong phân tích ......... 257 7.6. Đánh giá hiệu quả KPIs.................................................... 258 Chương 8:

NHÀ KHO DỮ LIỆU TRONG THỜI ĐẠI BIG DATA ................................................ 261 8.1. Giới thiệu ............................................................................ 261 8.2. Giới thiệu về Big Data....................................................... 263 8.2.1. Tại sao quan tâm đến Big Data trong thời điểm hiện nay? ..................................................................... 263 8.2.2. Sự bùng nổ dữ liệu....................................................... 264 8.2.3. Một số đặc điểm của Big Data .................................... 265 8.3. Khi nào nên chọn Big Data và khi nào chọn kho dữ liệu? ...................................................................... 269 8.4. Tích hợp giữa Big Data và kho dữ liệu .......................... 271 8.4.1. Lớp dữ liệu ................................................................... 272 8.4.2. Các thuật toán phân tích dữ liệu ................................. 276 8.4.3. Lớp công nghệ ............................................................. 278 TÀI LIỆU THAM KHẢO....................................................... 281

10

DANH MỤC TỪ VIẾT TẮT- THUẬT NGỮ TIẾNG ANH Từ viết tắt

Giải thích

3NF

Third Normal Form

ATM

Automated Teller Machine

BI

Business Intelligence

BSC

Balanced Scorecard

CAT Scan

Computerized Axial Tomography Scan

CEO

Chief Executive Officer

CRM

Customer Relationship Management

CSDL

ơ sở dữ liệu

CSF

Critical Success Factors

DBA

Database Administrator

DTS

Data Transformation Services

DW

Data Warehouse

DWaaS

Data Warehouse as a Service

EAI

Enterprise Application Integration

EDR

Enterprise Data Replication

EII

Enterprise Information Integration

ER

Entity Relationship

ERD

Entity Relationship Diagram

ETL

Extracting Transforming and Loading

GPS

Global Positioning System

HRM

Human Resource Management

IDMS

Integrated Database Management System

IS

Information System 11

IT JSON

JavaScript Object Notation

KPI

Key Performance Indicator

KRI

Key Result Indicators

MBA

Master of Business Administration

MDM

Mobile Device Management

MDX

MultiDimensional eXpression

ODBC

Open Database Connectivity

OLAP

Online Analysis Processing

OLE DB OLTP PI

Object Linking and Embedding Database Online Transaction Processing Performance Indicators

POS

Point Of Sales

RAM

Random Access Memory

RDBMS

12

Information Technology

Relational Database Management System

RFID

Radio Frequency Identification

SCM

Supply Chain Management

SQL

Structured Query Language

SSAS

SQL Server Annalysis Services

SSDT

SQL Server Data Tools

SSIS

Server Integration Services

SSRS

SQL Server Reporting Services

Chương 1 TỔNG QUAN VỀ GIẢI PHÁP BI Thập kỷ vừa qua là một minh chứng cho một cuộc chạy đua trong kinh doanh: hàng loạt công nghệ thông tin (IT) đã được triển khai, đến nỗi một số chuyên gia ước tính rằng một nửa vốn trong kinh doanh được đầu tư cho IT. Sự phát triển của các công ty như SAP, Oracle, Microsoft, IBM, Cisco, Dell, Siebel và các khách hàng được tư vấn bởi họ đã xác nhận cho tính quy mô của cuộc chạy đua này. Hầu hết các khoản đầu tư là nhằm cải thiện các hệ thống quản lý giao dịch hằng ngày và có được các báo cáo nhanh chóng và chính xác hơn. Có một số tranh luận cho rằng những khoản đầu tư này là cần thiết để vận hành các doanh nghiệp kinh doanh hiện đại. Theo đó, từ kinh nghiệm khi làm việc và nói chuyện với các nhà kinh doanh và những người đứng đầu về IT tại các công ty lớn trong nhiều ngành công nghiệp khác nhau cho thấy rằng các công ty này vẫn giàu dữ liệu nhưng nghèo thông tin. Nói cách khác, các doanh nghiệp này thiếu hụt loại thông tin có khả năng thực thi và các công cụ phân tích cần thiết để cải thiện lợi nhuận và hiệu suất. Business intelligence (BI) là một câu trả lời cho nhu cầu này. Vậy BI là gì? Nó có kiến trúc như thế nào? Những lợi ích mà BI mang lại cho doanh nghiệp là gì? Chương 1 sẽ cung cấp câu trả lời cho các câu hỏi trên. 1.1. BI là gì Để tìm hiểu BI là gì, trước tiên chúng ta sẽ tìm hiểu xem BI không phải là gì. BI không phải là: Một sản phẩm riêng lẻ: Mặc dù có nhiều sản phẩm xuất sắc có thể giúp triển khai BI, BI không phải là một sản 1

phẩm có thể mua và cài đặt để giải quyết tất cả các vấn đề vượt quá khả năng của một tổ chức. Một công nghệ: Mặc dù các công cụ nhà kho dữ liệu và các kỹ thuật như các công cụ trích xuất và chuyển đổi dữ liệu (ETL), các máy chủ, ... thường được sử dụng để hỗ trợ các ứng dụng BI, tuy nhiên, BI không chỉ đơn thuần là công nghệ. Một phương pháp: Mặc dù một phương pháp hiệu quả là một yếu tố quan trọng cho sự thành công của BI, tuy nhiên cần kết hợp phương pháp với các giải pháp công nghệ và các thay đổi của tổ chức. Vậy thì BI là gì? BI kết hợp các sản phẩm, công nghệ và các phương pháp để tổ chức các thông tin chính mà quản lý cần để cải thiện lợi nhuận và hiệu suất. Rộng hơn nữa, BI là thông tin kinh doanh và các phân tích kinh doanh trong các quy trình kinh doanh chính sẽ dẫn tới những quyết định và các hành động, từ đó cải thiện hiệu suất kinh doanh. BI bao gồm các thông tin và phân tích kinh doanh: - Được sử dụng trong phạm vi của một quy trình nghiệp vụ chủ chốt; - Hỗ trợ các quyết định và hành động; - Định hướng để cải thiện hiệu suất kinh doanh.

Hình 0.1. Ý nghĩa của BI trong thực tiễn (Williams & Williams, 2006) 2

Dưới đây là một số định nghĩa khác về BI: Thuật ngữ Business Intelligence (BI) được sử dụng lần đầu tiên vào năm 1989 bởi Howard Dresner, một nghiên cứu viên tại tập đoàn Gartner. Theo đó, BI là một thuật ngữ chung dùng để mô tả một tập hợp các khái niệm và phương pháp nhằm cải thiện quá trình ra quyết định bằng cách sử dụng nhiều kỹ thuật thông tin khác nhau. Theo Turban và cộng sự (2008), BI có thể được xem như tập hợp của các ứng dụng và kỹ thuật để thu thập, lưu trữ, phân tích và cung cấp quyền truy cập vào dữ liệu để giúp người dùng là doanh nghiệp đưa ra quyết định kinh doanh tốt hơn. Các ứng dụng của BI bao gồm các hoạt động của các hệ thống hỗ trợ quyết định, truy vấn và báo cáo, phân tích xử lý trực tuyến (OLAP), phân tích thống kê, dự báo và khai thác dữ liệu. Carlo (2009) định nghĩa BI là một tập các mô hình toán học và các phương pháp phân tích nhằm khai phá dữ liệu có sẵn để tạo ra thông tin và tri thức hữu ích cho quá trình ra quyết định. Vậy tóm lại, có thể hiểu BI là một giải pháp hữu dụng trong việc hỗ trợ ra quyết định nhằm giúp tổ chức cải thiện lợi nhuận và hiệu suất bằng cách kết hợp các kỹ thuật xử lý thông tin một cách hiệu quả nhất. 1.2. Kiến trúc BI Kiến trúc của BI (hình 1.2) bao gồm ba thành phần chính:

Hình 0.2. Kiến trúc của BI (Carlo, 2009) 3

 Các nguồn dữ liệu (Data sources: operational systems, external data,..): là nơi tích hợp và thu thập các dữ liệu được lưu trữ trong các nguồn dữ liệu khác nhau, không đồng nhất về nguồn gốc và loại. Các nguồn dữ liệu đa phần được thu thập từ các hệ thống tác nghiệp nhưng cũng có thể bao gồm các tài liệu phi cấu trúc như email và các dữ liệu nhận được từ các nhà cung cấp bên ngoài. Do đó, vấn đề quan trọng là làm sao để thống nhất và tích hợp các nguồn dữ liệu khác nhau này.  Kho dữ liệu và kho dữ liệu theo chủ đề (Data Warehouse và Data Mart như logistics, marketing,…): Sử dụng các công cụ trích xuất và chuyển đổi như ETL (Extract - Transform - Load) để lưu trữ các nguồn dữ liệu khác nhau vào một CSDL chung nhằm hỗ trợ phân tích kinh doanh. Các CSDL đó thường được gọi là Data Warehouse và Data Mart.  Các phương pháp BI: Dữ liệu được trích xuất, xử lý lần cuối sau đó dùng để phục vụ cho các mô hình toán học và các phương pháp phân tích nhằm hỗ trợ việc ra quyết định. Trong một hệ thống BI, một số ứng dụng hỗ trợ ra quyết định có thể được thực hiện như: o Phân tích các (Multidimensional cubes)

khối

đa

chiều

o Phân tích chuỗi thời gian (Time series) o Khai phá dữ liệu (Data mining) o Mô hình tối ưu hóa (Optimization models) Mô hình tháp ở hình 1.3 cung cấp cho người đọc các thành phần chính tạo nên hệ thống BI. 4

Hình 0.3. Các thành phần chính của một hệ thống BI (Chaidez, 2008) Data exploration: Tại tầng ba của tháp bao gồm các công cụ nhằm thi hành những phân tích mang tính bị động, bao gồm hệ thống báo cáo và truy vấn cũng như các phương pháp thống kê. Bởi vì các nhà ra quyết định phải đưa ra giả thiết trước và sau đó sử dụng các công cụ phân tích để tìm ra câu trả lời hoặc xác minh lại giả thiết ban đầu của họ, do đó đây được coi là phương pháp mang tính bị động. Ví dụ, một nhà quản lý bán hàng của một công ty nhận thấy doanh thu bán hàng trong một khu vực bị giảm ở một nhóm khách hàng; khi đó anh ta có thể muốn xác nhận giả thiết của mình bằng cách sử dụng các công cụ khai thác và trực quan hóa và sau đó ứng dụng một kiểm định thống kê để xác định kết luận của mình có thích hợp với dữ liệu đưa ra hay không. Data mining: Tầng bốn bao gồm các phương pháp BI chủ động, mục đích là khai thác thông tin và tri thức từ dữ liệu. Các phương pháp này bao gồm các mô hình toán học cho nhận dạng mẫu, các kỹ thuật khai phá dữ liệu. Không giống như các công cụ ở tầng ba của tháp, các mô hình chủ 5

động không đòi hỏi các nhà ra quyết định đưa ra bất kỳ giả thiết nào để xác nhận sau đó; mục đích của các mô hình chủ động là mở rộng tri thức cho các nhà ra quyết định. Optimization: Các mô hình tối ưu hóa cho phép chúng ta xác định các giải pháp tốt nhất trong tập hợp các giải pháp được đưa ra. Decisions: đưa ra sự lựa chọn và áp dụng thực tế của một quyết định cụ thể. Ngay cả khi các phương pháp BI được áp dụng thành công, thì việc lựa chọn quyết định thuộc về các nhà ra quyết định, những người nắm bắt được những thông tin không có cấu trúc để hiệu chỉnh các kết luận thông qua việc sử dụng các mô hình toán học. Khi xem xét từ đáy tháp tới đỉnh tháp, dễ dàng nhận thấy các hệ thống BI cung cấp ngày càng nhiều hơn các công cụ cho phương pháp phân tích chủ động. Ở đáy tháp, các yêu cầu cần thiết được cung cấp bởi các chuyên viên hệ thống thông tin trong một tổ chức, thường được biết đến như những nhà quản trị cơ sở dữ liệu (Database Administrators). Các phân tích viên và các chuyên gia về các mô hình toán học và thống kê chịu trách nhiệm cho các nhiệm vụ ở tầng trung. Cuối cùng, các hoạt động của các nhà ra quyết định chịu trách nhiệm cho tầng cao nhất. 1.3. Đạt lợi thế cạnh tranh với giải pháp BI Giải pháp BI giúp doanh nghiệp đạt lợi thế cạnh tranh nhờ vào các lợi ích sau đây: 1.3.1. Cắt giảm chi phí nhân công Lợi ích hữu hình lớn nhất của BI là tiết kiệm thời gian và công sức bằng việc tạo ra các báo cáo chuẩn mực cho tổ chức. Đây hiếm khi được xem như là lợi ích lớn nhất. Tuy nhiên, vì lợi ích này có thể đo lường được nên thường được 6

xem xét như là một phần của việc đánh giá khi phải thực hiện một quyết định về việc triển khai BI; đây là cách dễ dàng nhất để chứng minh việc cần thiết phải triển khai hệ thống BI.. Các hệ thống BI giúp cắt giảm chi phí nhân công khi tạo ra báo cáo bởi chúng: - Tự động thu thập và sắp xếp dữ liệu; - Tự động tạo báo cáo; - Cung cấp các công cụ thiết kế báo cáo giúp việc tạo ra các báo cáo mới trở nên đơn giản hơn; - Cắt giảm chi phí đào tạo nhận công cần thiết cho việc phát triển và tạo báo cáo. 1.3.2. Giảm thiểu việc tắc nghẽn thông tin Hệ thống BI cho phép người sử dụng cuối trích lọc các báo cáo khi họ cần chúng thay vì phải nhờ vào những nhân viên của phòng IT hay tài chính chuẩn bị những báo cáo này. Hệ thống BI sẽ cho phép xác thực người dùng để thiết kế các báo cáo phù hợp với nhu cầu của họ. Các hệ thống BI làm giảm việc tắc nghẽn thông tin bởi chúng: - Cung cấp các biểu đồ cá nhân hóa, dựa trên vai trò của các nghiệp vụ mà thu thập các dữ liệu quan trọng nhất cho các nghiệp vụ hằng ngày; - Cho phép người sử dụng mở và chạy các báo cáo một cách tự chủ; - Cung cấp các tài liệu về các chỉ số hiệu suất (KPIs) và các thông tin khác; - Cho phép người dùng phân tích và phê chuẩn các dữ liệu mà không đòi hỏi các chuyên gia IT; 7

- Cho phép người dùng tạo ra các góc nhìn mới của dữ liệu như họ cần. 1.3.3. Làm cho dữ liệu có khả năng thực thi Chuyện gì sẽ xảy ra khi các nhân viên trong một tổ chức nhận quá nhiều dữ liệu, quá ít dữ liệu, dữ liệu quá cũ, dữ liệu quá chi tiết hay chỉ là các dữ liệu không phù hợp? Câu trả lời là không gì cả, không có gì xảy ra, mọi người chỉ lãng phí thời gian và các nguồn lực. Hầu hết các tổ chức sử dụng một lượng lớn các nguồn tài nguyên để tạo ra các báo cáo tiêu chuẩn được gửi cho toàn bộ nhân viên ở công ty. Để chắc chắn rằng mọi người có được mọi thông tin họ cần, tất cả các loại báo cáo được gửi cho nhân viên thường ở cấp độ quá chi tiết. Kết quả là nhân viên cảm thấy bị chôn vùi bởi một số lượng lớn thông tin mà không nhìn thấy được một bức tranh rõ ràng về tình trạng tổng quan. Hơn nữa, bởi vì phải đòi hỏi nhiều nỗ lực để xây dựng các báo cáo, cho nên các báo cáo này thường đến tay các nhân viên rất lâu sau khi chúng được xây dựng một cách phù hợp nhất. Tất cả những điều này có nghĩa là các hành động khắc phục và các cơ hội tiềm năng mà những dữ liệu này có thể đưa đến đã bị bỏ lỡ hoặc do quá trễ hoặc vì các nhân viên không nhận thấy hay đã mất quá nhiều thời gian để tìm thấy những xu hướng phù hợp trong “ma trận” thông tin. Tệ hơn nữa: nhiều nhân viên không được đào tạo và không đủ kiến thức để có thể phân tích các con số nhằm xác định các mối đe dọa và các cơ hội. Các hệ thống BI làm cho thông tin có khả năng thực thi (actionable) bởi chúng có thể: 8

- Cung cấp thông tin thông qua những góc nhìn thống nhất của dữ liệu nhờ vào các chỉ số KPIs được xây dựng và tính toán dựa trên một tập hợp các định nghĩa chuẩn hóa để tránh các trường hợp việc đo lường hiệu quả dựa trên các định nghĩa không nhất quán; - Cung cấp các thông tin đến từng phút (to-the-minute) trong các báo cáo thời gian thực cho thấy tình trạng kinh doanh ngay tại thời điểm hiện tại - không phải tại một góc nhìn lịch sử cách đây nhiều ngày hay nhiều tuần; - Cho phép người dùng tự chủ tìm kiếm và thiết kế các báo cáo thay vì phụ thuộc vào các chuyên viên của bộ phận IT; - Sử dụng các luật để nhấn mạnh các ngưỡng KPIs là tốt hay không; - Cung cấp các tài liệu tích hợp để giúp người dùng hiểu nghĩa và định nghĩa của KPIs; - Cung cấp các đường dẫn tới các hệ thống vận hành, giúp nó trở nên dễ dàng cho người dùng để có những hành động chính xác; - Chỉ cho thấy những dữ liệu thích hợp với từng người dùng cụ thể dựa trên vai trò của họ, giúp tránh trường hợp quá tải thông tin; - Trình bày dữ liệu ở cấp độ tổng quát, tập trung giúp các xu hướng tổng quan có thể dễ dàng được phát hiện và sau đó cho phép người sử dụng “khoan xuống” (drill-down) đến dữ liệu chi tiết; - Sử dụng hình ảnh trực quan làm nổi bật bản chất của dữ liệu như các biểu đồ, đồ thị và các đồng hồ đo. 9

1.3.4. Các quyết định có chất lượng tốt hơn Các quyết định cần thực hiện hàng ngày và như chúng ta đều biết, các quyết định có chất lượng rất khác nhau. Các quyết định tốt có thể cung cấp các lợi ích to lớn. Các quyết định xấu chẳng những không cung cấp các lợi ích mà chúng còn có thể là nguyên nhân dẫn đến sự thua lỗ của công ty. Các hệ thống BI giúp tạo ra các quyết định tốt hơn bằng cách: - Cung cấp cho các nhà ra quyết định các thông tin hữu ích, chính xác và cập nhật; - Cho phép người sử dụng khai thác dữ liệu cho các nghiên cứu xa hơn. Ở đây, thuật ngữ người ra quyết định (decision maker) cần được xem xét rộng hơn, không chỉ có các nhà quản lý mới ra quyết định. Thật vậy, quyết định ảnh hưởng đến một tổ chức hầu hết được thực hiện bởi những người trong toàn tổ chức, từ nhân viên bán hàng -những người đưa ra quyết định về chiết khấu của một khách hàng, cho tới các trợ lý mua hàng - những người ra quyết định mua những sản phẩm nhất định để lưu kho. 1.3.5. Các quyết định được đưa ra nhanh hơn Một quyết định sẽ có thể được đưa ra ngay tại thời điểm mà bạn có tất cả các thông tin phù hợp trong tay. Nói cách khác, nếu bạn có được các thông tin phù hợp nhanh bao nhiêu thì bạn có thể đưa ra quyết định nhanh bấy nhiêu. Sự quyết định nhanh chóng rất quan trọng bởi hai lý do: - Nó giúp tổ chức dễ dàng phản ứng lại với những mối đe dọa hay những cơ hội; - Nó giúp rút ngắn thời gian giữa suy nghĩ và hành động. Hầu hết mọi người sẽ đánh mất dòng suy nghĩ nếu họ cần phải đợi quá lâu cho các thông tin tiếp theo về vấn đề mà họ đang gặp phải. 10

Các hệ thống BI cho phép các quyết định nhanh chóng hơn vì: - Kết hợp các nguồn dữ liệu đa dạng trong các báo cáo phổ biến, nhờ vậy tiết kiệm thời gian cho người dùng từ việc kết hợp dữ liệu thủ công trong các bảng tính tách biệt. - Cung cấp các báo cáo phân tích và các khả năng tùy biến báo cáo cho phép người sử dụng nhanh chóng nhận dữ liệu mới hay kết hợp các dữ liệu khác nhau theo nhu cầu thay vì phải yêu cầu những báo cáo mới từ IT hoặc bộ phận tài chính. - Cung cấp hệ thống phản hồi giảm thiểu thời gian trả lời bằng cách sử dụng các dữ liệu đã được tập hợp trước hay các kỹ thuật khác cho việc thu thập dữ liệu nhanh chóng. 1.3.6. Hướng tổ chức đến mục tiêu kinh doanh Những tổ chức thành công nhất là những tổ chức thành công trong việc làm cho thành viên của nó đều hành động hướng đến mục tiêu chung. Các hệ thống BI giúp gắn kết tất cả các thành phần của tổ chức hướng tới các mục tiêu kinh doanh bằng cách: - Tập trung vào các định nghĩa về KPI. Các báo cáo BI không tính toán các chỉ số KPI sử dụng các truy vấn hay mã script một cách độc lập. Các báo cáo BI nhận giá trị KPI và định nghĩa về KPI thông qua một nơi lưu trữ tập trung và do đó tránh sự không nhất quán giữa các định nghĩa về KPI và các giá trị KPI. - Hướng dẫn trình bày thông tin sử dụng hình ảnh trực quan tiên tiến, ngưỡng tiêu chuẩn và KPI, vì vậy đảm bảo một giải thích chung của các chỉ số KPI. 11

- Cung cấp một nguồn duy nhất của thông tin. Tất cả các báo cáo tập hợp dữ liệu từ một nguồn - hệ thống BI. - Đẩy thông tin được chọn lựa đi khắp tổ chức. Bằng cách cho phép các tổ chức đẩy các chỉ số KPI và các thông tin tới những người sử dụng cuối, hệ thống BI giúp tập trung sự chú ý của nhân viên vào các yếu tố thành công quan trọng nhất. - Gắn các mục tiêu cho các giá trị KPI cho mỗi đơn vị của tổ chức để sử dụng khả năng đo lường để đạt được mục tiêu phía trước và vì vậy thúc đẩy tổ chức hướng về các mục tiêu đã được xác định. 1.4. Ai cần hệ thống BI? Bất kỳ tổ chức nào, nếu họ cần đạt được vị trí cạnh tranh tốt hơn và cần chia sẻ và phân tích các thông tin kinh doanh giữa nhiều bên quan tâm, thì đều cần BI. Tuy nhiên, một số tổ chức cần BI hơn những tổ chức còn lại và các yếu tố dẫn dắt tổ chức vào những nỗ lực hiện thực hóa BI được liệt kê dưới đây. Các yếu tố này có thể được phân loại thành các yếu tố bên trong và các yếu tố bên ngoài. Các yếu tố bên ngoài là các điều kiện, hoàn cảnh bên ngoài khả năng điều khiển của một tổ chức, ví dụ: các đối thủ cạnh tranh, các khách hàng, môi trường và chính phủ. Các yếu tố bên trong là các hoàn cảnh và các quy trình mà tổ chức có thể điều khiển được như: mua hàng, bán hàng, nhân sự… 1.4.1. Các yếu tố bên ngoài dẫn dắt tổ chức hướng tới BI Áp lực cạnh tranh: Một số công ty đang chịu sức ép cạnh tranh lớn từ các đối thủ cạnh tranh, đặc biệt là về các sản phẩm và dịch vụ phổ biến, dễ thay thế được bằng sản phẩm hay dịch vụ tương đương khác. 12

Tính biến động của thị trường: Trong các thị trường với nhu cầu thay đổi nhanh chóng của khách hàng và/hoặc sự thay đổi nhanh chóng của sản phẩm (ví dụ máy tính và các phụ kiện), sự tồn tại của một sản phẩm tùy thuộc vào tình hình thị trường và luôn luôn phải đảm bảo có đúng loại sản phẩm với đúng số lượng cần thiết và trên một mức giá đúng. Với một số mặt hàng các yếu tố này có thể hoàn toàn thay đổi chỉ qua một đêm. Các yêu cầu luật pháp: Một số công ty có sự hạn chế về sự hiểu biết luật pháp hoặc về khả năng cung cấp các loại báo cáo cần thiết theo đúng quy định của pháp luật. Do vậy BI hỗ trợ khả năng cung cấp các báo cáo theo đúng quy định của luật pháp nước sở tại. 1.4.2. Các yếu tố bên trong dẫn dắt tổ chức hướng tới BI Khối lượng dữ liệu: Khi dữ liệu được tổ chức thu thập càng nhiều thì càng cần xây dựng các hệ thống dùng cho việc trích lọc dữ liệu và sử dụng dữ liệu, bởi vì lượng dữ liệu thô ban đầu không thể sử dụng để đưa ra một phân tích chi tiết cho các quy trình động trong một tổ chức. Các công cụ là cần thiết để giúp tập hợp dữ liệu một cách nhanh chóng và thực hiện quá trình phân tích dữ liệu để có được một cái nhìn tổng quan về tình huống kinh doanh. Quá tải thông tin: Các tổ chức nhắm đến các hệ thống BI bởi vì họ có quá nhiều báo cáo. Các công cụ BI cho phép các tổ chức giảm số lượng báo cáo nhờ vào: - Sự kết hợp đa dạng các loại thông tin trên biểu đồ đơn lẻ (các dashboard); - Việc trình bày dữ liệu ở cấp độ tổng quát nhưng đồng thời giúp người dùng có khả năng tiếp cận dữ liệu ở mức chi tiết thông qua khả năng phân tích dữ liệu và sử dụng một số kỹ thuật như kỹ thuật khoan xuống (drill down). 13

Đội ngũ nhân viên lành nghề: Sự sẵn sàng của những nhân viên lành nghề trong công ty có ảnh hưởng lớn đến việc một tổ chức có quyết định triển khai hệ thống BI hay không và họ sẽ đầu tư bao nhiêu vào việc này. Một tổ chức với những người có khả năng kỹ thuật để xây dựng một hệ thống BI và những người có kinh nghiệm trong việc định nghĩa, triển khai và sử dụng nó thường sẽ triển khai hệ thống BI tốt hơn là những tổ chức không nắm giữ những khả năng này. Văn hóa: Một số công ty có văn hóa sử dụng dữ liệu một cách hết sức chủ động và có thể đo được mức độ chi tiết của mọi thứ mà họ làm; ngược lại một số công ty khác không thoải mái với việc công khai về dữ liệu - là một đòi hỏi bắt buộc để nhận được đầy đủ các lợi ích từ một hệ thống BI. Văn hóa tổ chức vì vậy có thể là sự cho phép hoặc là rào cản cho việc triển khai hệ thống BI thành công. Rút ngắn thời gian trả lời: Nếu một tổ chức càng nhanh chóng có được những phân tích dữ liệu sâu sắc để từ đó đưa ra những hành động kịp thời thì tổ chức đó sẽ có được càng nhiều lợi thế cạnh tranh. Các nhà quản lý thường xuyên mong muốn có được các thông tin theo thời gian thực càng nhanh càng tốt, và việc định hướng thực hiện các hệ thống BI có thể hỗ trợ các yêu cầu như vậy. 1.5. Giới thiệu giải pháp BI của Oracle Các ứng dụng Oracle BI là những giải pháp BI hoàn thiện được xây dựng từ trước nhằm cung cấp những hiểu biết trực quan, dựa trên vai trò, cho tất cả mọi người trong một tổ chức, từ những nhân viên tác nghiệp cho đến những nhà quản lý cấp cao; giúp các quyết định, các hành động và các quy trình nghiệp vụ tốt hơn. Được thiết kế cho những 14

môi trường không đồng nhất, những giải pháp này cho phép các tổ chức đạt được những hiểu biết sâu sắc từ nhiều nguồn dữ liệu và các ứng dụng bao gồm: Siebel, Oracle EBusines Suite, PeopleSoft và hệ thống bên thứ ba như SAP. Các ứng dụng Oracle BI được xây dựng trên phiên bản gói doanh nghiệp Oracle BI, một nền tảng BI toàn diện, tiên phong và dẫn đầu, cho phép các tổ chức nhận ra giá trị của một ứng dụng BI đã được đóng gói, như giúp triển khai nhanh chóng, tổng chi phí sở hữu thấp hơn (Total cost of Ownership) và được xây dựng theo các “thực hành tốt nhất” (best practices), trong khi cũng có khả năng mở rộng dễ dàng những giải pháp này cho những nhu cầu đặc biệt, hoặc xây dựng những ứng dụng BI tùy chỉnh hoàn thiện mà tất cả dựa trên một kiến trúc BI chung. Dưới đây là một số ứng dụng của Oracle BI. 1.5.1. Oracle Financial Analytics Phân tích tài chính giúp các nhà quản lý: - Trực tiếp cải thiện hiệu suất tài chính với những thông tin hoàn thiện, tức thời dựa trên các đóng góp dữ liệu về chi phí và doanh thu của các phòng ban; - Tăng dòng tiền thông qua việc quản lý hiệu quả các khoản phải nhận, phải thu và lưu kho; - Tạo ra các báo cáo tài chính chính xác và nhanh chóng giúp đảm bảo đạo luật Sarbanes-Oxley; - Tiếp cận các báo cáo tài chính theo chu kỳ nội bộ để xác định hiệu suất thực thi của kinh doanh; - Thúc đẩy quản lý ngân sách tốt hơn bằng cách cung cấp thông tin tài chính kịp thời cho các nhà quản lý bộ phận; 15

- Có cái nhìn rõ ràng hơn về các sổ kế toán tổng hợp và nhận được thông báo về các sự kiện có thể ảnh hưởng đến sức khỏe tài chính của doanh nghiệp. 1.5.2. Oracle Sales Analytics Phân tích các cơ hội theo đường ống dẫn có thể: - Giúp xác định các hành động đòi hỏi để đạt được các mục tiêu kinh doanh; - Cung cấp các phân tích các hành động có khả năng để tăng doanh số và rút ngắn chu trình bán hàng; - Giám sát tỷ lệ chiến thắng đối thủ và các độ đo thực thi để cải thiện tỷ lệ chiến thắng này; - Tăng tính chính xác của việc dự báo bán hàng và cải thiện khả năng đạt được chỉ tiêu doanh số. 1.5.3. Oracle Marketing Analytics - Theo dõi và đo lường sự hiệu quả của chiến dịch trong thời gian thực; - Đo lường sự trở lại của các chương trình tiếp thị để tối ưu hóa tiếp thị hỗn hợp và chi phí; - Hiểu nhu cầu của khách hàng, phát hiện ra các cơ hội tạo ra doanh thu mới; - Phát triển các khách hàng thân thiết, nâng cao hiệu quả tiếp thị. 1.5.4. Oracle Service Analytics - Cải thiện các cấp độ dịch vụ, xác định các cơ hội bán hàng và cải thiện mức độ thỏa mãn của khách hàng; - Am hiểu quy trình vận hành dịch vụ đại diện khách hàng (Customer Services Representatives - CSR) cho phép cải thiện hiệu suất, hiệu quả hoạt động, các chương trình huấn luyện và giữ chân khách hàng; 16

- Cung cấp kịp thời các số liệu hoạt động quan trọng, các cảnh báo, báo cáo cho các chuyên gia dịch vụ và quản lý cấp cao. 1.6. Giới thiệu giải pháp BI của Microsoft Microsoft tạo ra một tiêu chuẩn mới cho BI hiện đại bằng việc cung cấp những khả năng toàn diện đáp ứng nhu cầu của mọi người trong tổ chức: từ nhà quản lý - những người cần có những dữ liệu dễ hiểu thể hiện qua các cách thức trực quan hóa như biểu đồ, đồ thị, … đến những nhà phân tích kinh doanh tìm kiếm những công cụ mạnh mẽ để tùy chỉnh các báo cáo của họ, cho đến những nhân viên IT cần đảm bảo các công cụ BI của tổ chức và dữ liệu được bảo mật, kết nối và tích hợp. Dưới đây là phần giới thiệu về giải pháp BI được tích hợp trong bộ công cụ SQL Server 2012 của Microsoft. Những khả năng cụ thể của giải pháp BI trong SQL Server 2012 có thể kể đến là: Khai thác và trực quan hóa dữ liệu nhanh chóng: Khám phá những hiểu biết mới với tốc độ nhanh chóng dựa trên trình duyệt khai thác dữ liệu, ảo hóa và cách thức trình diễn, Power Pivot giúp những người sử dụng truy cập và trộn dữ liệu từ bất cứ nguồn nào, bao gồm cả Big Data, bằng cách chỉ sử dụng các công cụ quen thuộc. Các phân tích hiệu suất cao: Công cụ phân tích trong bộ nhớ (In-memory) cung cấp một bước nhảy vọt về hiệu năng khi tương tác với một số lượng dữ liệu rất lớn. Các khả năng In-memory được xây dựng ngay trong các công cụ phân tích SQL Server giúp người dùng sử dụng linh hoạt và dễ dàng. 17

Dữ liệu tin cậy, nhất quán: IT có thể kiểm soát và quản lý dữ liệu tốt hơn thông qua mô hình BI Semantic, cung cấp khung nhìn nhất quán qua các nguồn dữ liệu không đồng nhất. Quản lý dữ liệu gốc (master data): Duy trì dữ liệu gốc thông qua các cấu trúc tổ chức được sử dụng cho việc gắn kết các thực thể, tham chiếu dữ liệu và quản lý siêu dữ liệu (metadata). Bảo đảm tính sẵn sàng, bảo mật của dữ liệu: BI cũng bao gồm những khả năng cốt lõi của cơ sở dữ liệu theo chuẩn SQL Server cho các ứng dụng, bao gồm các hỗ trợ cốt lõi cho Windows Server và các quyền được định nghĩa cho từng người dùng. Các thành phần của SQL Server có liên quan đến Data Warehouse và BI.

Hình 0.4. Các thành phần của SQL Server SQL Server components, là các thành phần chính, nơi lưu trữ dữ liệu, thiết lập xử lý, bao gồm: - SQL Server Database Engine: làm nhiệm vụ lưu trữ và truy vấn dữ liệu quan hệ cho Data Warehouse. - SQL Server Analysis Services (SSAS): làm nhiệm vụ lưu trữ và truy vấn dữ liệu dạng Cube cho Data Warehouse. 18

- SQL Server Integration Services (SSIS): làm nhiệm vụ như một ETL, để nạp dữ liệu cho Data Warehouse. - SQL Server Reporting Services (SSRS): làm nhiệm vụ tạo báo cáo dựa trên dữ liệu của Database Engine hoặc SSAS. Tools, là những công cụ hỗ trợ cho việc quản lý và sử dụng các SQL Server components, bao gồm: - SQL Server Management Studio (SSMS): là giao diện đồ họa (GUI) để truy cập và quản lý SQL Server Database Engine, SSAS, SSIS và SSRS. - Business Intelligence Development Studio (BIDS): là công cụ dùng để tạo cấu trúc và thực thi tác vụ cho SSIS, SSAS, và SSRS. Sau đây chúng ta sẽ cùng tìm hiểu kỹ hơn về hai thành phần quan trọng SSIS và SSAS trong phiên bản 2012. SSIS có tiền thân là DTS (Data Transformation), một dịch vụ chuyển đổi dữ liệu trong SQL Server 2000 trở về trước. SSIS trong phiên bản 2012 giới thiệu các công cụ thể hiện dạng đồ họa như SSIS Designer thông qua BIDS và SQL Server Import and Export Wizard. Nó giúp tăng khả năng mở rộng bằng cách sử dụng các tác vụ tùy chỉnh, nguồn dữ liệu, nơi lưu giữ dữ liệu gửi tới và những biến đổi dữ liệu, những thay đổi về kiến trúc. Các tác vụ chính của SISS: - WMI Data Reader: truy vấn dữ liệu WMI (Windows Management Instrumentation). - WMI Event Watcher: lắng nghe các sự kiện WMI. - Hệ thống tập tin: thực hiện các hoạt động trên tập tin và thư mục trong hệ thống tập tin. 19

- Web Service: truy xuất Web Service. - XML: làm việc với các tài liệu XML. - Analysis Services Execute DDL: thực thi các tập lệnh DDL. - Data Mining Query: truy vấn dữ liệu cho các mô hình khai thác dữ liệu. Trong Microsoft SQL Server Analysis Service(SSAS) phiên bản 2012 còn hỗ trợ thêm chức năng khai thác thông tin (Business Intelligent), khả năng mở rộng gia tăng, tính sẵn có và bảo mật cho các giải pháp Business Intelligent song song với việc làm cho chúng dễ tạo, dễ triển khai và dễ quản lý hơn. Các trình thiết kế trong SSAS: - Data Source View Designer: cung cấp môi trường dựa trên kiểu biểu đồ, đơn giản để định nghĩa các bảng và các quan hệ trong Data Source View tới các đối tượng Analysis Service. - Cube Designer: hỗ trợ cho việc sử dụng thông tin phân tích, giao dịch, kịch bản tập lệnh MDX và các hàm chỉ số hoạt động chính KPI. - Data Mining Model Designer: được dùng để định nghĩa, xem và kiểm tra các cấu trúc khai phá, các mô hình khai phá trong BIDS. - Dimension Designer: dùng để duyệt qua các dữ liệu chức năng trong các chiều (dimension) và sửa đổi các đặc tính khác nhau của một dimension sẵn có như: các thuộc tính, sự phân cấp, các mối quan hệ giữa các thuộc tính. 20

- Những cải tiến của SSAS 2012 so với các phiên bản trước đối với khối dữ liệu, chiều dữ liệu và khai thác dữ liệu bao gồm: + Dữ liệu và siêu dữ liệu bây giờ chỉ được nạp vào bộ nhớ khi cần thiết, không giới hạn chiều dữ liệu. + Một vài tác vụ được thêm vào SSAS có thể được dùng để tạo một giải pháp khai phá dữ liệu hoàn hảo. Tóm lại, BI là một giải pháp giúp các doanh nghiệp tối ưu hóa lợi nhuận và hiệu suất. BI giúp doanh nghiệp đạt được lợi thế cạnh tranh, thông qua các lợi ích mà BI mang lại cho doanh nghiệp, bao gồm cả lợi ích hữu hình và lợi ích vô hình, trong đó có thể kể đến một số lợi ích như: cắt giảm chi phí nhân công, giúp tạo ra các quyết định nhanh chóng, chính xác hơn, hướng tổ chức đến mục tiêu chung. Câu hỏi 1. BI là gì? Nêu một số định nghĩa về BI. 2. Tại sao doanh nghiệp cần BI? Các lợi ích mà BI mang lại cho doanh nghiệp là gì? 3. Phân biệt SSIS và SSAS trong Microsoft SQL Server?

21

Chương 2 KHO DỮ LIỆU VÀ PHÂN TÍCH DỮ LIỆU Tài sản thông tin là tài sản vô cùng quý giá với bất kỳ doanh nghiệp nào, và bởi vì điều này, các tài sản này phải được lưu trữ và dễ dàng tiếp cận khi cần thiết. Tuy nhiên, việc có quá nhiều dữ liệu đã khiến cho việc trích lọc các thông tin quan trọng nhất trở nên khó khăn, nếu không muốn nói là không thể. Xem các kết quả tìm kiếm từ Google có thể thấy rằng phương trình “dữ liệu = thông tin” không phải lúc nào cũng đúng, việc có quá nhiều dữ liệu không đồng nghĩa với việc có quá nhiều thông tin. Vì vậy, sự ra đời của kho dữ liệu và các kỹ thuật phân tích dữ liệu là một bước phát triển nhảy vọt để giúp doanh nghiệp có thể có được những thông tin tốt nhất từ vô số dữ liệu mà họ có được từ các giao dịch hàng ngày. Chương này sẽ giới thiệu về kho dữ liệu và các phương pháp phân tích dữ liệu, các lợi ích mà kho dữ liệu mang lại cho doanh nghiệp cũng như các xu hướng của kho dữ liệu. 2.1. Giới thiệu về kho dữ liệu 2.1.1. Phân tích dữ liệu là gì? Phân tích dữ liệu là quá trình phát hiện ra những mối quan hệ có mối liên quan hoặc phụ thuộc lẫn nhau, các mô hình và các khuynh hướng mới (Patterns & Trends) bằng việc khảo sát một số lượng lớn dữ liệu được lưu trữ trong các kho (Repository) sử dụng các công nghệ về nhận dạng mẫu cũng như các kỹ thuật thống kê và toán học. Phân tích dữ liệu có thể hiểu là kỹ thuật “khoan dữ liệu” theo chiều sâu và tổng hợp dữ liệu theo chiều ngược lại, là quá trình xem xét dữ liệu dưới nhiều góc độ nhằm tìm ra các mối liên hệ giữa các thành phần dữ liệu và phát hiện ra những xu hướng, hình mẫu, kinh nghiệm quá khứ 22

tiềm ẩn trong kho dữ liệu. Vì vậy nó rất phù hợp với mục đích phân tích dữ liệu hỗ trợ việc điều hành và ra quyết định. Khó khăn trong phân tích dữ liệu cũng bao gồm cả việc dữ liệu quá lớn, rải rác khắp nơi trong doanh nghiệp. Mỗi phòng ban trong doanh nghiệp chịu trách nhiệm cho việc thực thi các quy trình khác nhau và do đó dữ liệu họ có được cũng rất khác nhau, thể hiện dưới nhiều dạng thức khác nhau như: file văn bản, excel … Không những thế trong thời đại dữ liệu ngày nay, có nhiều loại dữ liệu từ mạng xã hội, các kênh thông tin truyền thông, các video… cũng cần thiết để doanh nghiệp khai thác dữ liệu từ đó và mang đến các thông tin có giá trị cho doanh nghiệp. Do đó việc tập trung dữ liệu ở một nơi duy nhất, cũng như thống nhất cách thức lưu trữ dữ liệu và lưu trữ dữ liệu dưới nhiều dạng thức khác nhau là hết sức cần thiết cho doanh nghiệp, và giải pháp đó chính là kho dữ liệu. 2.1.2. Định nghĩa kho dữ liệu “Kho dữ liệu (Data Warehouse) là tập hợp của các CSDL tích hợp, hướng chủ đề, được thiết kế để hỗ trợ cho chức năng hỗ trợ ra quyết định trong đó mỗi đơn vị dữ liệu đều liên quan tới một khoảng thời gian cụ thể” (Han, Kamber , & Pei, 2011). Kho dữ liệu thường có dung lượng rất lớn, tới hàng trăm Gigabyte hay thậm chí hàng Terabyte dữ liệu được tổ chức, lưu trữ và phân tích phục vụ cho việc cung cấp các dịch vụ thông tin liên quan đến yêu cầu của một tổ chức nào đó. Kho dữ liệu phục vụ cho việc phân tích với kết quả mang tính thông tin cao. Các hệ thống thông tin thu thập, xử lý dữ liệu loại này còn được gọi là Hệ xử lý phân tích trực tuyến (OLAP). Một kho lưu trữ dữ liệu thường được sử dụng như là cơ sở cho một hệ thống hỗ trợ quyết định. Nó được thiết kế để khắc phục những vấn đề thường gặp phải khi một tổ chức cố gắng 23

thực hiện chiến lược phân tích có sử dụng cùng một cơ sở dữ liệu đã được sử dụng cho xử lý giao dịch trực tuyến. 2.1.3. Đặc điểm của dữ liệu trong kho dữ liệu Kho dữ liệu là một tập hợp dữ liệu có những tính chất sau: Dữ liệu có tính tích hợp Một kho dữ liệu là một khung nhìn thông tin ở mức toàn thể, thống nhất các khung nhìn khác nhau thành một khung nhìn của một chủ đề. Ví dụ, hệ thống OLTP truyền thống được xây dựng trên một vùng phục vụ việc kinh doanh. Một hệ thống bán hàng và Marketing có thể có chung một dạng thông tin về khách hàng, nhưng các vấn đề về tài chính thì lại cần một khung nhìn khác. Một kho dữ liệu sẽ có một khung nhìn toàn thể về một khách hàng, khung nhìn đó bao gồm các phần dữ liệu khác nhau từ tài chính đến Marketing. Tính tích hợp thể hiện ở chỗ dữ liệu tập hợp trong kho dữ liệu được thu thập từ nhiều nguồn và trộn ghép với nhau tạo thành một thể thống nhất. Dữ liệu gắn với thời gian và có tính lịch sử Một kho chứa dữ liệu bao hàm một khối lượng lớn dữ liệu mang tính lịch sử. Dữ liệu được lưu trữ thành một loạt các Snapshot, mỗi Snapshot phản ánh những giá trị của dữ liệu tại một thời điểm nhất định và thể hiện một khung nhìn của một vùng chủ đề trong một giai đoạn. Do vậy nó cho phép khôi phục lại lịch sử và so sánh một cách chính xác các giai đoạn khác nhau. Yếu tố thời gian đóng vai trò như một phần của khóa để bảo đảm tính đơn nhất và cung cấp đặc trưng về thời gian cho dữ liệu. Dữ liệu chỉ đọc Dữ liệu trong kho dữ liệu là dữ liệu chỉ đọc, có thể được kiểm tra và không được sửa đổi bởi người sử dụng. 24

Dữ liệu không biến động Thông tin trong kho dữ liệu được tải vào sau khi dữ liệu trong hệ thống điều hành được cho là quá cũ. Không biến động thể hiện ở chỗ: dữ liệu được lưu trữ lâu dài trong kho dữ liệu. Mặc dù có thêm dữ liệu mới nhập vào nhưng dữ liệu cũ trong kho vẫn không bị xóa, điều đó cho phép cung cấp thông tin về một khoảng thời gian dài, cung cấp đủ số liệu cần thiết cho các mô hình nghiệp vụ phân tích, dự báo. Dữ liệu tổng hợp và chi tiết Dữ liệu chi tiết là dữ liệu ở mức thấp nhất được lưu trữ trong kho dữ liệu. Dữ liệu tác nghiệp là dữ liệu thấp nhất trong một tổ chức, thường được thu thập từ các hoạt động nghiệp vụ diễn ra hằng ngày của tổ chức. Dữ liệu tổng hợp là dữ liệu ở mức tổng quan, được hình thành trên cơ sở tổng hợp từ các dữ liệu chi tiết. 2.2. Lợi ích của kho dữ liệu trong kinh doanh 2.2.1. Tại sao cần kho dữ liệu? Triển khai kho dữ liệu có thể giúp một công ty tránh được nhiều thách thức khác nhau. Trong một kỷ nguyên của cạnh tranh khốc liệt, thì việc chỉ đưa ra các quyết định đơn lẻ là không đủ. Cần phải đưa ra các quyết định đúng thời điểm bởi vì nếu quyết định đưa ra muộn, doanh nghiệp sẽ chứng kiến đối thủ cạnh tranh của mình vượt lên trong cuộc chạy đua marathon. Hãy giả định rằng một chuỗi các siêu thị không triển khai một kho dữ liệu và cuối cùng siêu thị nhận ra rằng rất khó khăn để phân tích các sản phẩm nào được bán, sản phẩm nào không, khi nào doanh số tăng, độ tuổi của các khách hàng - những người mua một sản phẩm chuyên dụng nào đó và một vài truy vấn khác. 25

Lý do để một công ty phải có kho dữ liệu là họ sẽ có thêm lợi thế. Nó nhắm đến việc có được các quyết định thông minh hơn bằng một cách thông minh hơn. Điều này là có thể nếu giám đốc điều hành chịu trách nhiệm cho các quyết định có được dữ liệu này theo ý của họ. Có một thời gian khi các quyết định dựa trên thực tế và quyết định dựa trên kinh nghiệm đều phổ biến. Đến thời điểm hiện tại, các quyết định dựa trên thực tế đã chiếm phần quan trọng hơn. Có một số câu hỏi chắc chắn được đưa ra cho một nhà quản lý hay giám đốc điều hành và anh ta phải trả lời câu hỏi này để có thêm được lợi thế cạnh tranh so với đối thủ. Các câu hỏi này sau đây có thể cần thiết cho sự tồn tại và phát triển của một doanh nghiệp: - Làm thế nào để tăng thị phần của công ty lên 5%? - Sản phẩm nào không bán chạy trên thị trường? - Công ty nào/đại lý nào cần sự giúp đỡ về các chính sách bán hàng? - Chất lượng của dịch vụ chăm sóc khách hàng như thế nào và cần cải tiến những điểm nào? Những câu hỏi này sẽ được trả lời một cách dễ dàng nhờ vào sự hỗ trợ của kho dữ liệu và các kỹ thuật phân tích dữ liệu. 2.2.2. Lợi ích của kho dữ liệu Kho dữ liệu cung cấp một lượng lớn thông tin trong các kho chứa (stockpiles) giúp người dùng dễ dàng phát hiện ra các sự thật về khách hàng hay sản phẩm, từ đó có thể dẫn đến những quyết định trong kinh doanh. Ví dụ, nếu bạn muốn phân tích một bộ phận cụ thể, ví dụ bộ phận bán hàng hoặc bộ phận tiếp thị, bạn có thể làm tốt hơn với dữ liệu được trích lọc từ kho dữ liệu. Một nghiên cứu vào năm 2010 của Forbes cho thấy “các vấn đề liên quan đến dữ liệu làm hầu hết các công ty tiêu tốn hơn 5 26

triệu đô mỗi năm”. Sử dụng kho dữ liệu có thể giúp đảm bảo rằng dữ liệu được phân tích là chính xác và nhất quán. Bởi vì việc xây dựng một kho dữ liệu có thể tiêu tốn nhiều chi phí, các doanh nghiệp và các công ty lớn thường là khách hàng chính. Tuy nhiên, các công ty nhỏ cũng có thể có được nhiều lợi ích quan trọng từ việc tạo ra các kho dữ liệu của chính mình. Trước hết, kho dữ liệu có thể lưu trữ các giá trị của công ty theo thời gian bằng cách lưu trữ những dữ liệu quan trọng tại cùng một nơi. Thay vì giữ dữ liệu ở nhiều nơi khác nhau như trong hệ thống CRM, các tài khoản xã hội, các bảng tính Excel, các nhà kinh doanh có thể lưu trữ dữ liệu vào một trung tâm dữ liệu duy nhất. Kết quả là họ có thể khai thác dữ liệu trung tâm này để nâng cao các quyết định chiến lược, mà không cần phải tập hợp từ các nguồn khác nhau. Nhà kho dữ liệu cũng tiết kiệm tiền vì doanh nghiệp có thể tìm kiếm dữ liệu mà không cần sự hỗ trợ từ bộ phận IT. Thứ hai, công ty có thể có được những lợi ích từ việc lưu trữ dữ liệu của họ cùng một định dạng. Vì dữ liệu từ các phòng ban khác nhau sẽ được chuẩn hóa, mỗi phòng ban sẽ tạo ra kết quả đồng bộ hóa với các phòng ban khác. Điều này đảm bảo chất lượng và tính đồng dạng của dữ liệu. Kết quả là doanh nghiệp có thể cảm thấy tin tưởng rằng dữ liệu của họ là chính xác, dẫn đến các quyết định kinh doanh hợp lý hơn. Thứ ba, kho dữ liệu có thể cải thiện BI. Bởi vì kho dữ liệu kết hợp thông tin từ nhiều quy trình nghiệp vụ khác nhau, người dùng có thể thấy tự tin rằng những quyết định của họ được đưa ra dựa trên các thông tin toàn diện. Kho dữ liệu có thể cung cấp một bức tranh của một công ty với các quy trình như tiếp thị, tài chính, quản lý kho, bán hàng… Điều này cho phép những nhân viên chủ chốt của các phòng ban đưa ra các quyết định chủ chốt dựa trên sự thật thay vì thông qua trực giác. 27

Tạp chí Forbes nhận định rằng “Trong khi có một sự thật rằng kho dữ liệu đã có nhiều năm, giá trị của nó vẫn tăng trưởng bởi vì nó đại diện cho tài sản quý giá của một công ty - dữ liệu về khách hàng và hiệu quả kinh doanh”. Ví dụ, dịch vụ chăm sóc sức khỏe sử dụng thông tin thu thập được từ nhà kho dữ liệu để chăm sóc cho khách hàng và cải thiện dịch vụ. Đội tiếp thị có thể sử dụng các thông tin nhận được từ nhà kho dữ liệu để chắc chắn rằng họ đang nhắm đúng các đặc điểm của khách hàng. Các nhà điều hành có thể sử dụng dữ liệu để sắp xếp lại các hoạt động hoặc tái đánh giá các sản phẩm. Tạp chí Wired nhận định rằng Google đã tiêu tốn nhiều năm làm việc để làm chủ thành công kho dữ liệu phức tạp. Google đầu tư vào việc kiểm soát tốt các trung tâm dữ liệu - tốc độ, sức mạnh, và kết nối tốt, đồng thời tiết kiệm tiền bằng cách không mua thêm những vật dụng không cần thiết, ví dụ như không mua thẻ đồ họa, và các máy này không bao giờ mở nguồn màn hình. Kho dữ liệu không chỉ giúp doanh nghiệp tiết kiệm thời gian và sức lực thông qua sự lưu trữ dữ liệu tập trung mà còn bảo đảm rằng dữ liệu được cung cấp chính xác hơn và đáng tin cậy hơn dữ liệu được thu thập từ các nguồn khác nhau. Vì vậy các doanh nghiệp thực sự mong muốn sử dụng công nghệ để đạt được lợi thế cạnh tranh nên xem xét xây dựng các kho dữ liệu của riêng mình. 2.3. Các xu hướng của kho dữ liệu Trước khi có iPhone và Xbox, trước cả Tweet hay “Like” Facebook đầu tiên, và cũng trước cả máy tính bảng và điện toán đám mây, đã có kho dữ liệu. Cách đây khoảng 30 năm, đã có trung tâm lưu trữ dữ liệu cho việc phân tích và hỗ trợ ra quyết định hướng dữ liệu trong kinh doanh. Kho dữ liệu vẫn giữ vững sức mạnh của nó nhờ vào bản chất của một kho dữ liệu tập trung - được cung cấp bởi hàng tá 28

hay hàng trăm cơ sở dữ liệu, các ứng dụng và các nguồn hệ thống khác - tiếp tục trở nên tốt nhất, thuận tiện nhất giúp cho các công ty có một cái nhìn toàn diện trên toàn bộ doanh nghiệp về tất cả các mặt: khách hàng, các chuỗi cung ứng, bán hàng và các nghiệp vụ khác. Vì lý do này, các doanh nghiệp đang có kho dữ liệu đã tiến hành nâng cấp và cập nhật chúng với các kỹ thuật như Hadoop và các tiến trình nhớ trong (in-memory), giúp tải dữ liệu lớn (big data) nhanh hơn gấp 10 lần hoặc 100 hay 1000 lần trước đây. Trong khi đó, các doanh nghiệp dựa trên các giải pháp phân tích dữ liệu từng phần trong quá khứ, thì hiện tại đang xây dựng các kho dữ liệu để có thể nhận được bức tranh hoàn thiện của doanh nghiệp. Nói cách khác, kho dữ liệu hiện nay không chỉ lớn hơn so với thời kỳ trước đây mà còn có thể truy cập nhanh hơn, hỗ trợ nhiều loại dữ liệu mới, phục vụ nhiều chức năng nghiệp vụ quan trọng, và có khả năng cung cấp các hiểu biết thực thi cho bất kỳ ai trong doanh nghiệp tại bất kỳ thời điểm và địa điểm nào. Tất cả những điều này làm cho kho dữ liệu hiện đại trở nên quan trọng hơn bao giờ hết để giúp kinh doanh nhanh chóng, tiên phong và đạt được lợi thế cạnh tranh. Dưới đây là các xu hướng và các cơ hội của kho dữ liệu theo một nghiên cứu từ Oracle: Việc dữ liệu hóa (datafication - một xu hướng kỹ thuật hiện đại chuyển đổi nhiều khía cạnh của cuộc sống thành dữ liệu máy tính và chuyển đổi từ dữ liệu thành các thông tin có giá trị) của các doanh nghiệp đòi hỏi các kho dữ liệu phải có nhiều khả năng hơn. Các thiết bị di động, các phương tiện mạng xã hội, các cảm biến mạng (ví dụ Internet of Things) và các nguồn khác đang tạo nên một sự phát triển mạnh mẽ của dữ liệu - một số có thể nói như một sự phun trào của dữ liệu. Các nhóm IT đã tìm ra giải pháp để ứng phó với những sự thay đổi này bằng cách thêm vào các khả năng mới cho các kho dữ liệu 29

để chúng có thể quản lý các kiểu dữ liệu mới, nhiều dữ liệu hơn và nhanh hơn trước. Sự kết hợp giữa vật lý và luận lý giúp cắt giảm chi phí. Câu trả lời cho datafication là không nên tiêu tốn nhiều tiền hơn cho các hệ thống này. Hay nói một cách khác, việc tăng dữ liệu lên 10 lần không nên trở thành tăng chi phí lên 10 lần. Vì vậy kho dữ liệu đang phát triển phải được củng cố thông qua sự kết hợp của công nghệ ảo hóa, sự cô đọng, cơ sở dữ liệu đa người dùng và các máy chủ được thiết kế để xử lý một lượng lớn dữ liệu và công việc. Hadoop tối ưu hóa môi trường kho dữ liệu. Chương trình mã nguồn mở Hadoop có khả năng vượt trội khi xử lý các tập dữ liệu rất lớn. Điều này làm Hadoop trở thành người bạn đồng hành tuyệt vời của kho dữ liệu tiêu chuẩn và giải thích tại sao một số lượng lớn các nhà quản lý kho dữ liệu đang sử dụng Hadoop để gánh vác một số công việc nặng nề nhất. Các chiến lược trải nghiệm khách hàng sử dụng các phân tích thời gian thực để cải thiện các chiến dịch tiếp thị. Kho dữ liệu đóng một vai trò quan trọng trong việc khởi đầu trải nghiệm khách hàng bởi vì chúng lưu trữ dữ liệu dùng cho việc xây dựng các góc nhìn toàn diện 360 độ về khách hàng. Một kho dữ liệu về thông tin của khách hàng có thể được sử dụng cho các phân tích về cảm xúc, cá nhân hóa, tự động tiếp thị, bán hàng và các dịch vụ khách hàng. Các hệ thống kỹ thuật đang trở thành một phương pháp ưa thích cho việc quản lý thông tin quy mô lớn. Nếu không cẩn thận, kho dữ liệu có thể trở thành một sự lắp ghép phức tạp của các mảnh riêng lẻ - các máy chủ, lưu trữ, phần mềm cơ sở dữ liệu, và các thành phần khác - nhưng trong tình huống này thì không. Các hệ thống kỹ thuật như Oracle Big Data Appliance và Oracle Exadata Database Machine được cấu hình trước và tối ưu hóa cho các công việc khác nhau, cung cấp độ thực thi cao nhất. 30

2.4. Hệ hỗ trợ ra quyết định trong doanh nghiệp Một hệ hỗ trợ ra quyết định là một tập tích hợp của các công cụ máy tính cho phép một nhà ra quyết định tương tác trực tiếp với máy tính để nhận các thông tin bổ ích trong việc tạo ra các quyết định bán cấu trúc và không có cấu trúc. Một số ví dụ về các quyết định có thể là việc thống nhất và đạt được các quyết định, mở rộng nhà máy, quản lý các hồ sơ về các quyết định sản phẩm mới và các quyết định tiếp thị. Công việc hàng ngày của một người quản lý gắn liền với nhiều hoạt động khác nhau, do tính chất phức tạp của môi trường kinh doanh, hàng ngày một nhà quản lý có thể sẽ phải đối mặt với nhiều vấn đề cùng lúc. Không những thế, các nhà quản lý còn phải thường tiếp xúc với nhiều đối tượng khác nhau cả bên trong và bên ngoài của tổ chức. Nhà quản lý thành công là ngừoi đưa ra được các quyết định sáng suốt và nhanh chóng để có thể giải quyết mọi việc một cách suôn sẻ, và hệ hỗ trợ ra quyết định là một giải pháp đắc lực giúp các nhà quản lý làm được điều này. Hệ hỗ trợ ra quyết định mang lại những thông tin quý giá, giúp cho các nhà quản lý có cái nhìn rõ ràng về vấn đề đang gặp phải để từ đó đưa ra những giải pháp đúng đắn. Ngày nay, nhờ sự sẵn sàng của phần cứng máy tính, sự ra đời của hệ thống quản trị cơ sở dữ liệu trong năm 1970 đã cung cấp phương tiện cho việc lưu trữ và quản lý lượng lớn dữ liệu, cũng như sự phát triển về các phần mềm chức năng trong hệ hỗ trợ ra quyết định, giúp hệ hỗ trợ ra quyết định ngày càng hoàn thiện hơn. Ngoài ra, nhiều MBA đã được đào tạo các kỹ thuật phân tích hiện đang là quản lý cấp trung và cấp cao của các tập đoàn - các MBA này có khả năng sử dụng các công cụ của hệ thống hỗ trợ ra quyết định. Vì vậy, trong hầu hết các tổ chức, nhà quản lý đều sử dụng máy tính dựa trên các ứng dụng xử lý dữ liệu. Điều này dẫn đến sự phát triển của hệ thống hỗ trợ quyết định trong kinh doanh. 31

Dưới đây là những khả năng mà hệ hỗ trợ ra quyết định có thể cung cấp: - Hỗ trợ ra quyết định trong tình huống bị lỗi cấu trúc, ví dụ như không đảm bảo độ chính xác do thiếu cấu trúc, vấn đề không được thể hiện đầy đủ, và cần sự trợ giúp máy tính để tiếp cận và xử lý khối lượng dữ liệu đồ sộ. - Trợ giúp để nhanh chóng có được kết quả định lượng cần thiết để đạt được quyết định. - Vận hành chế độ tùy biến cho phù hợp với nhu cầu hiện tại của người sử dụng. - Hỗ trợ các giai đoạn khác nhau của quá trình ra quyết định. - Thúc đẩy các quyết định chất lượng cao bằng cách khuyến khích các quyết định dựa trên sự kết hợp của các thông tin có sẵn và phán đoán của con người. - Cung cấp sự linh hoạt cần thiết trái ngược với một mô hình định trước - làm cho nó dễ dàng để phù hợp với phong cách ra quyết định của từng cá nhân. - Tạo thuận lợi cho việc thực hiện các quyết định mà thường xuyên có sự tham gia của nhiều bộ phận.

32

2.5. Mô hình mẫu kho dữ liệu

Hình Error! No text of specified style in document..1. Kho dữ liệu theo chủ đề doanh thu Hình 2.1 là mô hình mẫu kho dữ liệu theo chủ đề doanh thu. Kho dữ liệu này được thiết kế theo lược đồ hình sao (sẽ được trình bày chi tiết ở các chương tiếp theo), bao gồm một bảng chính (FactSalesMana) và các bảng sự kiện (DimKenhPP, DimSanPham, DimVungBH, DimTime), cho phép các nhà quản lý khai thác các thông tin liên quan đến doanh thu hàng bán theo sản phẩm, theo vùng hay kênh phân phối… Dưới đây là một số báo cáo được trích xuất từ kho dữ liệu trên: Kỳ Năm 2012

Năm 2012 Total Năm 2013

Năm 2013 Total Grand Total

Sản phẩm Số lượng NHÓM BÚT VIẾT 350,819,682 NHÓM DỤNG CỤ VP 30,776,930 NHÓM HỌC CỤ 13,292,493 NHÓM MỸ THUẬT 6,121,373 401,010,478 NHÓM BÚT VIẾT 443,871,334 NHÓM DỤNG CỤ VP 38,873,233 NHÓM HỌC CỤ 16,894,312 NHÓM MỸ THUẬT 7,706,771 507,345,650 908,356,128

Doanh thu Giá vốn Chi phí 794,656,565,847 587,945,145,530 142,706,592,190 173,741,532,648 129,476,423,402 31,155,217,192 38,900,876,241 28,943,685,100 6,980,977,775 71,697,371,957 52,972,396,692 12,844,855,555 1,078,996,346,693 799,337,650,724 193,687,642,712 1,055,171,002,148 832,849,658,943 152,851,885,377 230,466,610,588 183,193,202,455 33,260,578,365 51,880,590,576 41,185,808,900 7,512,649,791 94,638,483,000 74,583,091,600 13,650,881,879 1,432,156,686,313 1,131,811,761,898 207,275,995,412 2,511,153,033,006 1,931,149,412,622 400,963,638,124

Lãi gộp 206,711,420,317 44,265,109,246 9,957,191,141 18,724,975,265 279,658,695,969 222,321,344,312 47,273,408,319 10,694,781,820 20,055,391,560 300,344,926,011 580,003,621,980

Lợi nhuận 64,004,828,127 13,109,892,054 2,976,213,366 5,880,119,710 85,971,053,257 69,469,458,935 14,012,829,954 3,182,132,029 6,404,509,681 93,068,930,599 179,039,983,856

Hình Error! No text of specified style in document..2. Báo cáo các độ đo sản phẩm theo kỳ

33

Kỳ Năm 2012

Năm 2012 Total Grand Total

Sản phẩm Số lượng Doanh thu Giá vốn NHÓM BÚT VIẾT 350,819,682 794,656,565,847 587,945,145,530 BÚT BI 251,674,574 513,165,322,332 378,554,198,052 BÚT BUTTER GEL 2,556,302 9,514,233,533 7,105,567,689 BÚT CAO CẤP 77,632 3,949,847,286 2,928,843,175 BÚT GEL 41,235,757 133,530,109,218 99,606,158,169 BÚT LÔNG KIM 7,496,471 25,492,259,652 19,142,061,961 BÚT MÁY 2,449,252 44,951,574,537 33,620,675,121 RUỘT BÚT 45,329,694 64,053,219,289 46,987,641,363 NHÓM DỤNG CỤ VP 30,776,930 173,741,532,648 129,476,423,402 DỤNG CỤ VĂN PHÒNG 30,776,930 173,741,532,648 129,476,423,402 NHÓM HỌC CỤ 13,292,493 38,900,876,241 28,943,685,100 DỤNG CỤ HỌC TẬP 13,292,493 38,900,876,241 28,943,685,100 NHÓM MỸ THUẬT 6,121,373 71,697,371,957 52,972,396,692 BÚT LÔNG TÔ MÀU 1,604,033 17,283,102,613 12,715,914,024 BÚT SÁP 4,290,862 48,196,923,216 35,690,534,616 MÀU NƯỚC 226,478 6,217,346,128 4,565,948,052 401,010,478 1,078,996,346,693 799,337,650,724 401,010,478 1,078,996,346,693 799,337,650,724

Chi phí 142,706,592,190 92,247,575,680 1,712,898,749 709,310,009 23,944,550,027 4,561,317,557 8,045,035,936 11,485,904,232 31,155,217,192 31,155,217,192 6,980,977,775 6,980,977,775 12,844,855,555 3,106,867,526 8,624,937,447 1,113,050,582 193,687,642,712 193,687,642,712

Lãi gộp 206,711,420,317 134,611,124,280 2,408,665,844 1,021,004,111 33,923,951,049 6,350,197,691 11,330,899,416 17,065,577,926 44,265,109,246 44,265,109,246 9,957,191,141 9,957,191,141 18,724,975,265 4,567,188,589 12,506,388,600 1,651,398,076 279,658,695,969 279,658,695,969

Lợi nhuận 64,004,828,127 42,363,548,600 695,767,095 311,694,102 9,979,401,022 1,788,880,134 3,285,863,480 5,579,673,694 13,109,892,054 13,109,892,054 2,976,213,366 2,976,213,366 5,880,119,710 1,460,321,063 3,881,451,153 538,347,494 85,971,053,257 85,971,053,257

Hình Error! No text of specified style in document..3. Báo các chi tiết các sản phẩm năm 2012 Tóm lại, bằng việc tập trung dữ liệu vào một kho duy nhất kết hợp cùng với các phương pháp phân tích dữ liệu tiên tiến, kho dữ liệu đã góp phần quan trọng vào việc hỗ trợ doanh nghiệp khai thác tối đa lợi ích của thông tin để đưa ra các quyết định nhanh chóng, chính xác trong thời gian thực. Tuy kho dữ liệu đã ra đời từ lâu nhưng cho đến ngày nay vai trò của nó ngày càng quan trọng nhờ vào việc tiếp tục phát triển những kỹ thuật mới giúp lưu trữ được đa dạng dữ liệu với khối lượng dữ liệu vô cùng lớn, từ đó hỗ trợ tốt hơn cho doanh nghiệp trong thời điểm bùng nổ dữ liệu như hiện nay. Câu hỏi 1. Kho dữ liệu là gì? Sự khác biệt giữa kho dữ liệu và cơ sở dữ liệu quan hệ là gì? 2. Tại sao doanh nghiệp cần kho dữ liệu? Các lợi ích mà kho dữ liệu mang lại cho doanh nghiệp là gì? 3. Cho biết vai trò của nhà kho dữ liệu trong hệ hỗ trợ ra quyết định?

34

Chương 3 GIỚI THIỆU DỰ ÁN KHO DỮ LIỆU Triển khai kho dữ liệu (Data Warehouse) trong doanh nghiệp được xem như là dự án công nghệ thông tin có quy mô lớn và trải qua nhiều giai đoạn khác nhau. Để thành công, doanh nghiệp không những cần chú trọng đến khía cạnh kỹ thuật, mà yêu cầu về nghiệp vụ kinh doanh và người dùng cũng đóng vai trò rất quan trọng. Vì vậy, chương này sẽ giới thiệu tổng quan về các bước trong việc triển khai dự án kho dữ liệu và phân tích dữ liệu. 3.1. Giới thiệu dự án kho dữ liệu Việc triển khai thành công dự án nhà kho dữ liệu phụ thuộc rất nhiều vào việc tích hợp các quy trình, giai đoạn, công việc và thành phần khác nhau, trong đó cần phải có sự kết hợp giữa công nghệ thông tin và nghiệp vụ kinh doanh. Việc xây dựng nhà kho dữ liệu cần phải theo định hướng kinh doanh của tổ chức và đáp ứng yêu cầu nghiệp vụ. Theo hình 3.1, đầu tiên, dự án Data Warehouse cần tập trung vào việc lập kế hoạch cho dự án, và giai đoạn này giúp đánh giá mức độ sẵn sàng của tổ chức trong quá trình triển khai dự án, bao gồm nguồn nhân lực, quy trình nghiệp vụ và cơ sở hạ tầng. Kết quả của giai đoạn một là tài liệu xác định mục tiêu, phạm vi, nguồn lực, thời gian và kết quả cần đạt được. Giai đoạn hai sẽ xác định yêu cầu nghiệp vụ kinh doanh; trên thực tế thì giai đoạn một và hai có thể diễn ra song song, nhằm đảm bảo việc hoạch định dự án được xác định rõ ràng, cũng như phù hợp với các yêu cầu về khía cạnh kinh doanh và nghiệp vụ. Lý do là nhân viên tại các phòng ban và các yêu cầu nghiệp vụ kinh doanh có ảnh hưởng lớn đến các quá trình tiếp 35

theo trong dự án, như thiết kế, xây dựng và triển khai giải pháp. Vì vậy, kết quả đầu ra tại giai đoạn hai là bảng mô tả chi tiết về hoạt động nghiệp vụ và các yêu cầu, cũng như là các chuẩn đánh giá về khía cạnh người dùng đối với hệ thống sau khi dự án Data Warehouse đã triển khai thực tế.

Hình Error! No text of specified style in document..1. Vòng đời phát triển dự án Data Warehouse (Kimball & Ross, 2013) Sau khi yêu cầu nghiệp vụ đã được thu thập và phân tích, theo hình 3.1 thì bước tiếp theo sẽ bao gồm ba luồng song song,trong đó, luồng trên cùng liên quan đến khía cạnh kỹ thuật. Cụ thể đây là thiết kế kiến trúc kỹ thuật hình thành nền tảng kiến trúc trong việc tích hợp nhiều giải pháp công nghệ trong dự án Data Warehouse, và lựa chọn những giải pháp phù hợp với từng tổ chức khác nhau. Kết quả của giai đoạn này là danh sách các giải pháp, công nghệ của các tổ chức cung cấp giải pháp, ứng dụng kèm theo các chi tiết, đánh giá về từng giải pháp đó. Kế đến là luồng ở giữa đề cập đến luồng dữ liệu. Trong đó, toàn bộ các yêu cầu nghiệp vụ đã khảo sát và phân tích ở giai đoạn hai sẽ được mô hình hóa trong mô hình đa chiều. Từ đó, mô hình đa chiều sẽ được chuyển đổi thành kiến trúc vật lý; và 36

tại đây, các vấn đề liên quan đến chiến lược cải thiện tốc độ truy vấn (như bảng chỉ mục index, phân khu partition, tính toán tổng hợp aggregation …) cần được xem xét. Cuối cùng nhưng cũng không kém phần quan trọng là tiến trình ETL (Extracting Transforming and Loading) được thiết kế và phát triển. Kết quả của các giai đoạn này là các thiết kế bảng dữ liệu, ràng buộc, mối liên hệ và quá trình xử lý ETL để chuyển đổi dữ liệu từ các nguồn khác nhau vào Data Warehouse. Luồng giai đoạn dưới cùng đề cập đến luồng ứng dụng, đây là giai đoạn thiết kế và phát triển các ứng dụng Business Intelligence, cụ thể là các phân tích, báo cáo phục vụ cho hoạt động ra quyết định của nhà quản lý. Giai đoạn này cũng được phân tích, thiết kế dựa trên yêu cầu nghiệp vụ của từng phòng ban và từng đối tượng sử dụng. Sau khi ba luồng song song này được hoàn thành thì bước cuối cùng là triển khai thực tế và bảo trì và quan trọng hơn là đánh giá thành công của dự án Data Warehouse đối với việc đáp ứng yêu cầu hoạt động nghiệp vụ kinh doanh. Từ đó, những hạn chế, cải tiến sẽ được phân tích và tiến hành lập kế hoạch cho dự án Data Warehouse ở cấp độ cao hơn. 3.2. Tổng quan về quy trình thực hiện dự án 3.2.1. Lập kế hoạch dự án Tương tự như những dự án công nghệ thông tin khác, dự án Data Warehouse cũng cần được lên kế hoạch, cụ thể gồm 3 giai đoạn là xác định dự án Data Warehouse và phạm vi; tập trung vào hoạt động lập kế hoạch dự án và hoạch định nguồn nhân lực; xem xét các rủi ro khi triển khai dự án.

37

3.2.2. Xác định dự án và phạm vi Để xác định dự án Data Warehouse, cần trả lời các câu hỏi về ý nghĩa của việc xây dựng dự án này và việc cần phải bắt đầu từ đâu. Một trong những yếu tố quan trọng để đánh giá mức độ sẵn sàng của tổ chức khi thực hiện dự án, đặc biệt có liên quan đến công nghệ thông tin, phụ thuộc phần lớn vào ban quản lý/giám đốc điều hành của tổ chức đó. Trong trường hợp người quản lý hiểu rõ về lợi ích to lớn của dự án Data Warehouse trong việc tập hợp, lưu trữ, quản lý nguồn dữ liệu tin cậy và hệ thống các báo cáo, phân tích sẽ giúp ra quyết định kinh doanh tốt hơn, thì rất thuận lợi cho việc xác định dự án. Lý do là cần phải có một định hướng duy nhất đối với việc thực hiện dự án. Tuy nhiên, trên thực tế thì mỗi người quản lý sẽ có những nhu cầu khác nhau về thông tin cần phân tích, vì thế dự án cần phải ưu tiên sao cho những nhu cầu nào quan trọng nhất sẽ được thực hiện trước, với điều kiện là không đòi hỏi quá nhiều nguồn lực và thời gian. Một tình huống nữa cũng rất thường xảy ra, đó là người quản lý không am hiểu về nhu cầu phân tích dữ liệu, và không biết mình cần được cung cấp loại thông tin nào để ra quyết định. Tình huống này được xem là phức tạp nhất, bởi vì lúc này nhà điều hành không nhận ra giá trị mà hệ thống thông tin sẽ mang lại cho tổ chức, cho nên họ sẽ dễ dàng từ bỏ dự án và vì vậy mà tỷ lệ thất bại của dự án Data Warehouse sẽ rất cao. Năm yếu tố chính tạo nên nền tảng để xây dựng Data Warehouse thành công đó chính là: (1) Sự hợp tác, tài trợ từ ban điều hành/quản lý kinh doanh trong tổ chức nhờ vào tầm nhìn về các lợi ích tiềm năng to lớn của Data Warehouse, từ đó họ sẽ thuyết phục, chứng minh với các đối tượng khác về việc đầu tư vào dự án. (2) Nhà quản lý cần xác định Data Warehouse đóng vai trò là yếu tố thúc đẩy kinh doanh, để từ đó tổ chức có động lực, điều kiện để hoạt động kinh doanh tốt hơn. Lý do là Data Warehouse mang đến nhiều tri thức mới và hỗ trợ ra quyết định 38

đúng đắn, kịp thời. (3) DW sẽ đồng thời cải thiện mối quan hệ giữa các phòng IT và kinh doanh, bởi vì Data Warehouse giúp gắn kết các ứng dụng công nghệ thông tin nhằm đáp ứng nhu cầu kinh doanh thực tiễn của tổ chức. (4) Hình thành nhu cầu và thói quen ứng dụng các phân tích dữ liệu vào kinh doanh và (5) có khả năng thực hiện về mặt kỹ thuật khi triển khai trong tổ chức. 3.2.2.1. Phạm vi dự án và mục tiêu Sau khi nhận được sự đồng thuận của ban quản lý/điều hành công ty về dự án, bước tiếp theo cần phải xem xét về phạm vi dự án sao cho phù hợp với kinh phí xây dựng và triển khai. Đầu tiên, việc xác định phạm vi dự án cần được thực hiện bởi người đại diện của hai phòng ban chính là Hệ thống thông tin (Information System - IS) và Kinh doanh, bởi vì khi đã hiểu rõ các yêu cầu nghiệp vụ cần đáp ứng trong dự án Data Warehouse thì điều này sẽ giúp việc xác định phạm vi dự án hợp lý hơn. Cần lưu ý rằng, ngày chuyển giao sản phẩm và những sản phẩm/kết quả cần phải hoàn tất theo đúng thời hạn đã đưa ra. Thứ hai là phạm vi của dự án ban đầu cần phải được quản lý dễ dàng, và một gợi ý là nên bắt đầu dự án với quy mô nhỏ. Khái niệm “lifecycle” đề cập đến vòng lặp trong quá trình phát triển của Data Warehouse; trong đó, dự án nên bắt đầu với quy mô nhỏ, được thiết kế phù hợp với nhu cầu kinh doanh thay đổi của doanh nghiệp và thời gian xây dựng Data Warehouse khoảng từ bốn đến tám tháng. Vì vậy, cần xem xét đến hai yếu tố là số lượng hệ thống dữ liệu nguồn và số lượng người dùng để đảm bảo dự án thuộc quy mô nhỏ. Trong đó, dữ liệu nguồn được hiểu như là dữ liệu được lưu trữ ở một hệ thống bên ngoài và cần được chuyển đổi để đưa vào hệ thống đang xây dựng. Vì vậy, dữ liệu nguồn thuộc nhiều hệ thống lưu trữ khác nhau thì sẽ rất 39

phức tạp và cũng chính là nguyên nhân dẫn đến phạm vi của dự án khó được kiểm soát. Thứ ba là cần phải tập trung vào một dữ liệu nguồn để đáp ứng hoạt động phân tích trong một yêu cầu nghiệp vụ kinh doanh. Trước đây, dự án Data Warehouse được xây dựng để đáp ứng cho nhiều phòng ban hay quy trình nghiệp vụ khác nhau, chẳng hạn như phòng Kinh doanh và marketing và sản xuất, … với lý do là tiết kiệm thời gian và chi phí trong triển khai dự án. Tuy nhiên, phương pháp này sẽ gây lãng phí thời gian hơn và nhiều dữ liệu sẽ không được sử dụng hoặc không đáp ứng đủ nhu cầu phân tích. Hơn nữa, nếu như có bất kỳ nhu cầu thay đổi hay mở rộng Data Warehouse thì việc này sẽ khó khăn hơn vì ảnh hưởng đến hoạt động của nhiều phòng ban. Cho nên, phạm vi dự án chỉ nên tập trung vào một quy trình kinh doanh nhất định, như phân tích hóa đơn khách hàng hay hoạt động thanh toán chi trả … và hạn chế việc triển khai đồng thời nhiều dự án. Thứ tư là giới hạn số lượng người dùng truy cập vào Data Warehouse, trung bình thì chỉ nên có khoảng 25 người dùng có thể truy cập vào các phân tích mang tính quản trị, chiến lược. Thứ năm là hình thành các chỉ số đánh giá thành công của dự án Data Warehouse sau khi xác định được phạm vi của dự án. Mục đích là giúp các nhà quản lý, người triển khai, vận hành đều nắm rõ về những kỳ vọng trong quản trị kinh doanh đối với dự án. Tuy nhiên, những chỉ số này cần phải có khả năng dễ đo lường, dễ thống kê thành con số. 3.2.2.2. Phát triển và quản lý kế hoạch dự án Trong kế hoạch của dự án Data Warehouse cần xác định rõ tất cả các công việc có liên quan đến từng giai đoạn trong Lifecycle theo hình 3.1. Người quản lý dự án (project manager) cần ước lượng về thời gian và nguồn lực cho mỗi giai đoạn, và 40

chi tiết hơn là đối với từng công việc nhỏ trong từng giai đoạn, cũng như là khoảng thời gian trễ hạn chấp nhận được nhưng vẫn đảm bảo toàn bộ tiến trình dự án. Ngoài ra, việc thay đổi yêu cầu từ phía người sử dụng cũng là yếu tố làm chậm quá trình thực hiện dự án. Vì vậy, người quản lý có thể lựa chọn một số giải pháp như tăng thêm thời gian thực hiện và phạm vi của dự án hoặc vẫn giữ phạm vi dự án như ban đầu nhưng thêm một số thay đổi hoặc chuyển các yêu cầu mới cho phiên bản sau của sản phẩm. Tuy nhiên, tất cả những quyết định trên đều cần được xem xét và đồng thuận từ các cấp quản lý, ban điều hành và người sử dụng. 3.2.3. Xác định yêu cầu nghiệp vụ Hoạt động xác định yêu cầu nghiệp vụ đóng vai trò rất quan trọng từ khi bắt đầu dự án đến khi kết thúc. Việc xác định đúng yêu cầu nghiệp vụ sẽ có ảnh hưởng đến rất nhiều giai đoạn khác của dự án. Cụ thể là đối với giai đoạn hoạch định dự án thì yêu cầu nghiệp vụ giúp người quản lý dự án xác định dễ dàng hơn về phạm vi và mục tiêu dự án. Ngoài ra, yêu cầu nghiệp vụ rõ ràng và chi tiết sẽ giúp xác định những loại dữ liệu nào cần được lưu trữ trong Data Warehouse, các ràng buộc, cách thức được tổ chức lưu trữ và mức độ cập nhật thường xuyên. Vì vậy, giai đoạn này có ảnh hưởng lớn đến ba luồng giai đoạn tiếp theo là luồng công nghệ, luồng dữ liệu và luồng ứng dụng. Nếu như có bất kỳ sự thiếu sót nào về thu thập hay phân tích yêu cầu nghiệp vụ thì điều này sẽ gây ảnh hưởng lớn đến việc xây dựng kho dữ liệu, cụ thể là thiếu một vài trường dữ liệu hay định dạng dữ liệu sai, thậm chí là thiếu bảng lưu trữ dữ liệu. Bên cạnh đó, những sự thiếu sót còn ảnh hưởng đến chất lượng của ứng dụng và vì thế không đáp ứng đầy đủ yêu cầu của người sử dụng. Quan trọng hơn là điều đó có thể ảnh hưởng đến thời gian thực hiện dự

41

án nếu như những dữ liệu còn thiếu lại cần phải được sử dụng ngay trong dự án này. Để nắm rõ yêu cầu nghiệp vụ, trước tiên cần phỏng vấn đối tượng người dùng, cụ thể là về công việc, mục tiêu, những khó khăn và phương thức ra quyết định trong hiện tại, cũng như trong tương lai. Bên cạnh việc lấy yêu cầu từ người dùng của các phòng ban kinh doanh, cũng rất cần phỏng vấn nhân sự của bộ phận “IT” để nhận diện yêu cầu nghiệp vụ cùng với mức độ sẵn sàng của dữ liệu đáp ứng đối với yêu cầu đó. Có hai phương pháp cơ bản để thu thập yêu cầu và phân tích dữ liệu hoạt động, đó là phỏng vấn và thiết kế kết hợp người dùng (JAD - Join Application Design), trong đó phỏng vấn chia thành hai loại là phỏng vấn cá nhân và nhóm nhỏ. Ưu điểm của phương pháp phỏng vấn là có được sự đồng thuận của các bên tham gia cho nên đảm bảo được về chất lượng nguồn dữ liệu, và mọi cuộc phỏng vấn đều được ghi âm nên sẽ không có bất kỳ thông tin nào bị bỏ sót. Phương pháp thiết kế kết hợp người dùng là một hình thức phỏng vấn nhóm, trong đó một phiên làm việc JAD sẽ bao gồm một nhóm người phỏng vấn có số lượng giới hạn và chọn lọc, được tổ chức ở một nơi tách biệt cùng với các công cụ trợ giúp. Phương pháp này có ưu điểm là thúc đẩy việc phát triển ý tưởng, giảm thiểu thời gian thu thập thông tin nhờ vào việc sắp xếp thời gian thuận tiện để mọi người trong nhóm được phỏng vấn cùng một lúc. Kết quả của giai đoạn xác định yêu cầu bao gồm: (1) Các tài liệu mô tả yêu cầu nghiệp vụ. Sau khi bước khảo sát được hoàn tất, toàn bộ dữ liệu ghi nhận được trình bày dưới dạng tài liệu. Trong đó bao gồm các tài liệu mô tả yêu cầu (requirement document) như business requirement mô tả về sản phẩm/hệ thống/tính năng cần thực hiện để đạt được mục tiêu 42

kinh doanh/hoạt động của tổ chức; luồng xử lý quy trình, mô hình hóa và chỉ định các yếu tố có thể ảnh hưởng đến hệ thống; business rules and constraints mô tả chuẩn quy tắc cần tuân thủ về dữ liệu, quy trình, báo cáo,… các tài liệu này có thể được trình bày dưới dạng phát biểu hay mô hình hóa; table items trình bày các vấn đề cần được thảo luận thêm, được thể hiện dưới dạng danh sách câu hỏi mở hay các mục “action to be taken” (cần được nghiên cứu thêm); và parking lot items liệt kê các câu hỏi/chủ đề tuy không liên quan trực tiếp đến quá trình thu thập yêu cầu nhưng có liên quan đến dự án, có thể được sử dụng cho phần cải tiến, mở rộng hệ thống hoặc những việc khác nữa. (2) Ma trận ghi vết. Ma trận được trình bày trong file excel và thể hiện phần so sánh giữa các yêu cầu nghiệp vụ với từng mục tiêu của dự án. Vì vậy, ma trận này rất quan trọng cho việc rà soát lại toàn bộ thông tin đã thu thập được, cũng như chỉ ra những mục tiêu nào của dự án còn thiếu sót và chưa được thu thập thông tin. (3) Cập nhật lại kế hoạch dự án. Sau khi thực hiện các văn bản và rà soát ma trận, bước cuối cùng là cập nhật lại dự án nếu như quá trình lên kế hoạch bị sai sót hay chưa nhận diện đầy đủ các rủi ro phát sinh. 3.2.4. Luồng công nghệ 3.2.4.1. Thiết kế kiến trúc kỹ thuật Sau khi hoạt động xác định yêu cầu kinh doanh hoàn thành, bước tiếp theo là thiết kế những yếu tố luận lý và vật lý của Data Warehouse. Từ bản thiết kế này, các bước phân tách và di chuyển dữ liệu (extracting and transforming) sẽ được thực hiện, cùng với ước lượng chung về nhu cầu quản trị của Hệ quản trị cơ sở dữ liệu và giả định về chức năng của sản phẩm cuối cùng. 43

Mô hình dữ liệu đa chiều (dimensional modeling) là tên gọi của kỹ thuật thiết kế được sử dụng trong Data Warehouse, trong đó tập trung vào việc trình diễn dữ liệu trong một nền tảng cho phép tăng tốc độ truy xuất dữ liệu. Mỗi mô hình đa chiều đều được hình thành từ một bảng dữ liệu chứa nhiều khóa hay còn gọi là bảng sự kiện (fact table) và tập hợp các bảng có cấu trúc nhỏ hơn được gọi là bảng chiều (dimension tables). Mỗi bảng chiều sẽ chứa một khóa chính và gắn kết với khóa ngoại của bảng sự kiện theo mối liên hệ 1 - n. Có thể nói đây là cấu trúc của mô hình hình sao (Star schema), ngoài ra, bảng fact còn chứa thêm các cột dạng số, và được dùng để tính toán, tổng hợp, thống kê. Mô hình đa chiều sẽ được trình bày kỹ hơn trong chương tiếp theo. Lợi ích của mô hình đa chiều là cấu trúc đơn giản, thiết kế chuẩn và dễ dàng cho các thao tác viết câu lệnh truy xuất dữ liệu. Ngoài ra, cấu trúc này thể hiện các ràng buộc, các logic/quy tắc trong kinh doanh ở khía cạnh đơn giản nhất và giảm thiểu số lượng phép kết hợp giữa nhiều bảng khác nhau, vì vậy tốc độ truy vấn cũng nhanh hơn. Bên cạnh đó, cấu trúc này rất phù hợp cho việc mở rộng để đáp ứng với nhu cầu thay đổi trong hoạt động kinh doanh. Cụ thể là nếu như thêm nhiều bảng chiều nhằm mô tả cho bảng sự kiện thì cũng không làm ảnh hưởng đến những bảng chiều khác, cũng như là bảng sự kiện có sẵn. Trong quá trình tiến hành xây dựng các Data Mart, tại một thời điểm vẫn có thể triển khai đồng thời nhiều hoạt động xây dựng Data Mart riêng biệt. Và khi hoàn thành, các Data Mart vẫn có thể phối hợp với nhau và tạo nên Data Warehouse thống nhất. Mô hình đa chiều trên thực tế thường chứa bốn đến mười lăm bảng chiều, trong đó, bảng sự kiện chứa đựng dữ liệu quan sát thực tế và ghi nhận dưới kiểu con số, các thuộc tính thường là dạng chữ để mô tả các tính chất của đối tượng và các thuộc tính 44

dạng chữ này được lưu trữ trong các bảng chiều. Trong đó, bảng chiều “Thời gian” đóng vai trò quan trọng trong Data Warehouse, cụ thể là nó chứa các thuộc tính mô tả giá trị thời gian như ngày, tuần, tháng, quý, năm. Một số lưu ý được đề nghị như: (1) hạn chế việc thay đổi khóa chính của bảng chiều như Product hay Customer, thay vào đó là cập nhật mô tả (description) của đối tượng trên và có ba lựa chọn: hoặc là (loại 1) ghi nhận dữ liệu đè lên dữ liệu, cũ hoặc là (loại 2) tạo thêm một bảng chiều ghi nhận dòng dữ liệu mới, hoặc là (loại 3) tạo thêm thuộc tính chứa giá trị cũ và lưu dữ liệu mới. (2) Cũng có nhiều tình huống cần thay đổi bảng chiều thường xuyên hoặc định kỳ, khi đó nên sử dụng giải pháp loại 2 vì nó hỗ trợ tốt quá trình ghi nhận toàn bộ dữ liệu lịch sử thay đổi. 3.2.4.2. Lựa chọn và phát triển các ứng dụng phân tích Có hai khía cạnh cần xem xét khi lựa chọn sản phẩm là cần phải đáp ứng yêu cầu kinh doanh và kỹ thuật. Trên thực tế, nhiều dự án Data Warehouse tập trung nhiều vào khía cạnh kỹ thuật mà bỏ qua các yêu cầu nghiệp vụ. Vì vậy, trong quá trình kiểm tra thử (testing) và triển khai sử dụng thử nghiệm các tính năng của hệ thống, chúng đã không nhận được sự ủng hộ của người dùng. Tiếp theo, cần có những đánh giá về mặt kỹ thuật: (1) Nền tảng phần cứng cần phải có khả năng mở rộng và lưu trữ tốt, trong đó, có thể kết hợp nhiều nền tảng khác nhau bao gồm servers cho khu vực chuẩn bị dữ liệu, Data Mart và ứng dụng. (2) Nền tảng hệ quản trị cơ sở dữ liệu đối với Data Warehouse vừa và nhỏ thì cốt lõi là dữ liệu quan hệ. (3) Công cụ cho hoạt động chuẩn bị dữ liệu chiếm phần lớn chi phí trong Data Warehouse. (4) Cuối cùng là công cụ truy cập dữ liệu để hỗ trợ cho nhiều yêu cầu khác nhau. Quá trình lựa chọn bao gồm các hoạt động sau: 45

(1) Phát triển ma trận trong lựa chọn sản phẩm: Tất cả các yêu cầu về kinh doanh và kỹ thuật đều có mức độ quan trọng khác nhau, được đánh giá dưới dạng như “bắt buộc phải có” hoặc “có thì sẽ tốt” hay dùng con số từ 1 đến 5 như trong bảng 3.1. Dưới đây là của ma trận lựa chọn sản phẩm: Bảng Error! No text of specified style in document..1. Ma trận lựa chọn sản phẩm Feature Vùng chứa dữ liệu: -Hỗ trợ trích lọc dữ liệu từ nhiều nguồn dữ liệu và nền tảng Warehouse như RDBMS, IDMS, DB2 -Hỗ trợ chức năng copy và phát sinh dữ liệu lặp Metadata và chuẩn: -Lưu trữ metadata -Hỗ trợ TCP/IP, FPT

Feature Weight

Product 1

Product 2

…

85

85

85 25

(2) Lựa chọn nhà cung cấp dịch vụ: Có thể đưa ra một số tiêu chí để lựa chọn nhà cung cấp phù hợp như sau: Thứ nhất là có sự hỗ trợ như cung cấp tài liệu hướng dẫn/hỗ trợ sử dụng dành cho từng đối tượng khác nhau như người dùng ở phòng ban kinh doanh, người lập trình, người quản trị hệ thống, … Thứ hai là về vấn đề đào tạo và tư vấn, cần có những tư vấn viên hỗ trợ người dùng thao tác với hệ thống. Cuối cùng là sự hỗ trợ về mặt kỹ thuật để xử lý tất cả vấn đề về kỹ thuật phát sinh từ phía người dùng lẫn hệ thống.

46

(3) Thực hiện các nghiên cứu thị trường về nhà cung cấp dịch vụ: Mục tiêu của hoạt động này giúp cho tổ chức lựa chọn được nhà cung cấp dịch vụ phù hợp nhất. Tổ chức có thể tìm kiếm thông tin trên web, tham dự các buổi trình diễn “showcase” hoặc hội thảo “seminar”, … Sau đó, tổ chức cần chọn lọc lại danh sách phù hợp với yêu cầu nghiệp vụ và kỹ thuật của mình. Tiếp theo là đánh giá các nhà cung cấp thông qua hệ thống các câu hỏi nhằm tìm ra sự phù hợp của nhà cung cấp cho các yêu cầu của công ty, mở một cuộc đối thoại trực tiếp giữa các nhà cung cấp để tìm ra những điểm mạnh. (4) Lựa chọn nền tảng và giải pháp công nghệ trong dự án: Việc lựa chọn công nghệ phù hợp với tổ chức là một công việc khó khăn. Phần dưới đây sẽ trình bày một số yếu tố cần lưu ý trong quá trình lựa chọn nền tảng và giải pháp DBMS phù hợp: Đầu tiên, cần xem xét đến phạm vi hoạt động của tổ chức. Đối với một số công ty có quy mô lớn hơn luôn yêu cầu triển khai hệ thống Data Warehouse, nhằm đáp ứng nhu cầu của nhiều phòng ban, bao gồm cả tài chính, nhân sự, … Một số công ty triển khai đồng thời nhiều nền tảng Data Warehouse; ví dụ như RDBMS (relational database system) kết hợp với analytical DBMS (database system). Trong đó, những câu lệnh cập nhật dữ liệu hay truy vấn đơn giản sẽ được thực hiện với RDBMS; trong khi đó, OLAP (online analytical processing) và truy vấn phức tạp được thực hiện với analytical DBMS. Tùy theo vào quy mô của dự án, số lượng người dùng truy cập đồng thời và một số tiêu chí khác sẽ ảnh hưởng đến quyết định lựa chọn một trong những nền tảng là IBM DB2, SAP, Oracle, hoặc Microsoft,…

47

Một số nhận định cho rằng “Oracle là công cụ lưu trữ database tốt nhất trên thế giới” hay “DB2 là công cụ database tuyệt vời nhất được thiết kế” hay “SQL Server là không giới hạn”, … Có thể nói rằng, việc lựa chọn nền tảng không phải là vấn đề quan trọng, tuy nhiên có thể cân nhắc về thói quen sử dụng và chi phí đầu tư. Đồng thời có thể xem xét các nhà cung cấp giải pháp toàn diện như Oracle, IBM và Microsoft, để giảm thiểu việc sử dụng nhiều ứng dụng khác nhau từ nhiều nhà cung cấp khác nhau. Đối với Oracle, có thể chọn công cụ Oracle Exadata Database Machine, trong đó sử dụng Oracle Database 12c. Ưu điểm là giảm thiểu việc tích hợp up-front system và hỗ trợ công nghệ lưu trữ, tính toán và mạng tối ưu. Ngoài ra, đối với IBM DB2 thì có thể lựa chọn IBM PureData System for Analytics; hoặc lựa chọn Microsoft Azure SQL Data Warehouse có tích hợp với Microsoft SQL Server ecosystem. Một số tổ chức có quy mô nhỏ vẫn có thể lựa chọn nền tảng công nghệ đám mây Data Warehouse as a service (DWaaS). Với công nghệ này sẽ giúp giảm thiểu chi phí quản trị hệ thống, bản quyền, chi phí triển khai, … Một số dịch vụ như Amazon Redshift hay IBM dashDB cung cấp giải pháp toàn diện về Data Warehouse. Thứ hai là xem xét đến nhu cầu về độ sẵn sàng và tốc độ truy xuất nhanh chóng. Một số tổ chức mong muốn đạt được cả hai yêu cầu trên, vì vậy DwaaS không phải là lựa chọn tốt nhất bởi vì nó phụ thuộc quá nhiều vào mạng Internet. Thay vào đó là các giải pháp như IBM DB2 Analytics Accelerator add-on dành cho z/OS hoặc BLU Acceleration capabilities dành cho LUW. Bên cạnh đó, một số công cụ như IBM PureData, Teradata Active EDW and Oracle Exadata với ưu điểm là hoạt động quản trị và cải thiện tốc độ được hỗ trợ tối ưu. Ngoài ra, có thể xem xét IBM dashDB chuyên về xử lý dữ liệu phi cấu trúc và có tích hợp với IBM Cloudant, hỗ trợ tối ưu cho lưu trữ và truy cập 48

JSON và NoSQL data. Mặt khác, Microsoft Azure SQL Data Warehouse cung cấp khả năng phân tích nhiều loại dữ liệu, bao gồm dữ liệu quan hệ, bán cấu trúc được lưu trữ trong Hadoop và sử dụng ngôn ngữ Transact-SQL. Sau khi đã lựa chọn giải pháp DBMS phù hợp, kế đến là lựa chọn giải pháp cho ETL tool. Một số loại ETL tool được phân định như sau: ETL tools tập trung vào tiến trình extracting và loading, tuy nhiên cần tích hợp với công cụ chuyển đổi dữ liệu khác; ETL hoặc ETL tools chỉ chấp nhận một loại input và output nhất định, ví dụ như flat file hoặc vài thể loại đặc biệt nào khác; ETL tools chuyên thực hiện chuyển đổi dữ liệu nhưng có khuyết điểm là không hỗ trợ được nhiều định dạng dữ liệu đa dạng; và cuối cùng là ETL tools với đầy đủ ba tính năng nhưng đây cũng là công cụ có chi phí cao nhất. Việc xây dựng riêng công cụ ETL có thể lựa chọn một trong hai dạng là GUI-based và code-based. Trong đó, code-based tool được sử dụng rất phổ biến, chẳng hạn như Perl có thể được sử dụng là code-based ETL tool, và là ngôn ngữ tổng quát phù hợp với nhiều transaction code language thuộc nền tảng DBMS khác nhau như Oracle PL/SQL, Microsoft SQL Server T-SQL, … Ngoài ra, tổ chức có thể lựa chọn ETL tool có sẵn từ các nhà cung cấp dịch vụ và cân nhắc các yếu tố liên quan đến chi phí, bảo trì, hỗ trợ, đào tạo, … Cụ thể chúng ta có thể lựa chọn một số giải pháp như sau: Oracle Warehouse Builder (OWB) 11gR2, DB2 Infosphere Warehouse Edition 9.1 hay SQL Server Integration Services (SSIS) 2012 đã bao gồm ETL tool. Lưu ý là việc lựa chọn giải pháp ETL cần phải phù hợp với lựa chọn DBMS. Sau khi lựa chọn giải pháp ETL tool, bước cuối cùng là BI tools. Trong đó, BI tools có rất nhiều loại như reporting, desktop/traditional BI, multidimensional tool, data mining và 49

data visualization tool. Việc lựa chọn BI tools cần xem xét dựa trên yêu cầu của nghiệp vụ kinh doanh để đảm bảo các công cụ hỗ trợ tốt cho các hoạt động phân tích, lập báo cáo trong quá trình hỗ trợ ra quyết định. Một lưu ý cần xem xét khi lựa chọn BI tools là: giải pháp phải được thiết kế phù hợp với từng lĩnh vực kinh doanh, có khả năng truy cập ở bất kỳ lúc nào, bất kỳ vị trí nào và bởi bất kỳ thiết bị nào như điện thoại thông minh, máy tính bảng hay laptop, … Một số giải pháp được gợi ý sử dụng như SAP Business Intelligence, Oracle Hyperion system hay Oracle Business Intelligence enterprise edition, Microsoft Business Intelligence tools và tổ chức có thể lựa chọn phù hợp với sự lựa chọn nền tảng DBMS. 3.2.5. Luồng dữ liệu 3.2.5.1. Xây dựng mô hình dữ liệu đa chiều Một Data Mart có thể được xây dựng từ tập hợp bảng sự kiện, lấy ví dụ trong ngân hàng, Data Mart gồm tập hợp các bảng sự kiện liên quan đến hoạt động của tài khoản như rút tiền, gửi tiền, tính phí tháng, tổng số giao dịch, số lượng khách hàng trong hàng đợi. Hơn nữa, thiết kế Data Warehouse có nghĩa là xây dựng tập hợp Data Mart và bảng chiều; Data Mart có thể kết hợp việc xây dựng dữ liệu từ duy nhất một nguồn hoặc nhiều nguồn khác nhau cũng như có thể trùng lắp dữ liệu giữa các Data Mart khác nhau. (1) Liệt kê các Data Mart Bắt đầu với việc liệt kê tất cả Data Mart có dữ liệu từ một nguồn duy nhất. Tiếp theo, kết hợp nhiều Data Mart từ một nguồn dữ liệu thành một Data Mart từ nhiều nguồn khác nhau phù hợp với quy trình nghiệp vụ nhất định. Lấy ví dụ như dữ liệu của công ty viễn thông được phân thành các Data Mart như 50

sau: hóa đơn thanh toán của khách hàng, hóa đơn ghi nhận dịch vụ, báo cáo xử lý vấn đề, đơn yêu cầu sử dụng dịch vụ và thanh toán, danh sách nhân sự và thanh toán lương, hóa đơn mua hàng từ nhà cung cấp, quản lý kho sản phẩm, quản lý khách hàng. Có thể kết hợp quản lý khách hàng, kho sản phẩm, hóa đơn dịch vụ, báo cáo vấn đề trong Data Mart ghi vết hoạt động cung cấp dịch vụ. Bên cạnh đó, có thể kết hợp quản lý thanh toán của khách hàng, đơn yêu cầu sử dụng dịch vụ, ghi nhận khuyến mãi trong Data Mart quản lý mối quan hệ khách hàng (customer relationship management). (2) Liệt kê danh sách bảng chiều Danh sách Data Mart và bảng chiều có thể được xây dựng độc lập với nhau, nhưng để thuận lợi thì cần xây dựng Data Mart trước, sau đó là bảng chiều. Việc hình thành các bảng chiều không đòi hỏi nhiều phân tích chuyên sâu; mà ngược lại là liệt kê các chiều có thể liên kết với bảng sự kiện. Lấy ví dụ trong Data Mart về hóa đơn thanh toán của khách hàng bao gồm các bảng chiều như sau: khách hàng, thời gian, dịch vụ, chi nhánh,… (3) Xây dựng các điểm giao nhau Sau khi liệt kê danh sách Data Mart và bảng chiều cần có, bước tiếp theo là sắp xếp lên ma trận, trong đó dòng thể hiện các Data Mart và cột thể hiện bảng chiều. Tại mỗi ô giao nhau giữa Data Mart và bảng chiều, nếu như có tồn tại mối liên kết thì đánh dấu các vị trí này. Bảng Error! No text of specified style in document..2. Bảng các điểm giao nhau Customer billing

Time x

Customer x

Service x

Service Orders

x

x

x 51

Purchase orders

x

Bảng phân tích 3.2 sẽ giúp người đọc liệt kê tất cả Data Mart và bảng chiều có thể xảy ra và mối liên hệ giữa chúng. (4) Xây dựng bảng sự kiện: bao gồm 4 bước sau: Bước 1: Lựa chọn Data Mart: trong số danh sách Data Mart liệt kê, chọn một Data Mart bất kỳ và từ đó xây dựng bảng sự kiện. Bước 2: Khai báo khóa ngoại chiều dữ liệu sẽ mô tả từng dòng dữ liệu trong bảng sự kiện. Lấy ví dụ bảng sự kiện thể hiện tổng doanh thu hàng ngày của từng chi nhánh, việc xác định “hàng ngày”, “chi nhánh” chính là xác định khóa ngoại chiều dữ liệu. Việc xác định hợp lý các khóa ngoại chiều dữ liệu trong bảng sự kiện sẽ góp phần cho thiết kế đa chiều trong Data Mart tránh được các thiếu sót có thể xảy ra. Bước 3: Chọn bảng chiều sau khi đã xác định khóa ngoại chiều dữ liệu. Trong ví dụ về hóa đơn thanh toán của khách hàng, có thể chọn chiều dữ liệu là hóa đơn thanh toán của khách hàng mỗi tháng đối với từng dịch vụ cụ thể. Vì thế, bảng chiều có thể là khách hàng, dịch vụ, thời gian. Bước 4: Chọn bảng sự kiện chứa thông tin sự kiện. Ví dụ về hóa đơn thanh toán khách hàng, giả sử rằng có bảng chiều mô tả dịch vụ để xác định từng loại phí cho các loại dịch vụ khác nhau, vì vậy giá trị “sự kiện” có thể là số lượng sử dụng và giá trị của dịch vụ. 3.2.5.2. Xây dựng mô hình vật lý Kiến trúc đóng vai trò rất quan trọng trong quá trình xây dựng và phát triển dự án Data Warehouse. Bảng 3.3 thể hiện khung kiến trúc của Data Warehouse, các cột trình bày về dữ liệu, kỹ thuật và kiến trúc; các dòng thể hiện yêu cầu nghiệp vụ, mô hình kiến trúc, mô hình chi tiết và triển khai. 52

Mỗi cột trong bảng 3.3 xác định một vùng của kiến trúc, trong đó: (1) Vùng kiến trúc của dữ liệu: Nội dung của Data Warehouse là dữ liệu và cung cấp tất cả thông tin, tri thức thông qua báo cáo, biểu đồ, xu hướng,… để hỗ trợ ra quyết định. Vùng kiến trúc của dữ liệu là danh sách dữ liệu quan trọng và cần thiết trong kinh doanh, bản thiết kế logic và vật lý của dữ liệu, các tính toán tổng hợp, phân cấp,… được thiết kế theo nhu cầu kinh doanh. (2) Vùng kiến trúc kỹ thuật: bao gồm các quy trình và công cụ để thao tác dữ liệu. Vùng kiến trúc này sẽ trả lời cho câu hỏi “bằng cách nào” để lấy dữ liệu từ nhiều nguồn khác nhau, và đưa vào báo cáo theo chuẩn phục vụ cho yêu cầu nghiệp vụ cụ thể. Trong đó gồm hai phần chính là front room và back room, cụ thể là back room chịu trách nhiệm đối với việc thu thập và chuẩn bị dữ liệu và front room là chuyển đổi dữ liệu. (3) Kiến trúc hạ tầng: bao gồm tất cả nền tảng để lưu trữ toàn bộ dữ liệu và thực hiện xử lý, cụ thể là phần cứng và hệ điều hành. Bảng Error! No text of specified style in document..3. Khung kiến trúc của Data Warehouse Kỹ thuật (How)

Mức độ dữ liệu

Dữ liệu (What)

Back Room

Front Room

Yêu cầu nghiệp vụ và kiểm toán

Loại dữ liệu nào cần thiết và tốt hơn để ra quyết định? Loại dữ liệu nào về tài sản

Bằng cách nào để lấy dữ liệu, chuyển đổi để sẵn sàng cho các báo

Vấn đề nào trong kinh doanh là quan trọng nhất? Bằng cách nào để

Kiến trúc (How) Các yêu cầu về phần cứng và hệ thống quan trọng nhất?

53

Mô hình kiến trúc và văn bản

được trình bày trong báo cáo tài chính?

cáo phân tích?

đo lường chúng?

Mô hình đa chiều: đối tượng nào quan trọng nhất (bảng sự kiện và bảng chiều) và mối liên hệ giữa chúng?

Các yêu cầu về truy xuất dữ liệu của báo cáo trong khoảng thời gian nhất định? Dữ liệu được lưu trữ ở đâu?

Người dùng sẽ cần gì khi lấy thông tin từ các báo cáo? Cần phải tham gia khóa học, tập huấn như thế nào?

Dữ liệu được lấy ở đâu và xuất ra như thế nào? Hệ thống có đủ khả năng lưu trữ dữ liệu?

Tiếp theo, mỗi dòng trong bảng 3.3 xác định mức độ chi tiết của văn bản, bản vẽ tại nhiều cấp độ khác nhau. (1) Cấp độ yêu cầu nghiệp vụ: Đây là cấp độ không bàn về mặt kỹ thuật, bao gồm yêu cầu nghiệp vụ từ người dùng, kinh phí, các công nghệ hiện đại. (2) Cấp độ mô hình kiến trúc: Mô hình kiến trúc mô tả công nghệ cụ thể để đáp ứng cho yêu cầu nghiệp vụ, bao gồm: xác định việc tương tác giữa các công nghệ với nhau, quản trị hệ thống và nguồn nhân lực để đáp ứng nhu cầu triển khai, vận hành. (3) Cấp độ mô hình chi tiết: Xác định các mô hình chứa đựng thông tin hướng dẫn chi tiết cho quá trình triển khai, bao gồm chi tiết về chức năng cần hoàn thành tại mỗi giai đoạn. (4) Cấp độ triển khai: bao gồm định nghĩa ngôn ngữ lập trình, mã codes và phần mềm hỗ trợ. Kiến trúc của Back room bao gồm: 54

(1) Source systems: xác định các nguồn lưu trữ dữ liệu để cung cấp đầu vào cho Data Warehouse, bao gồm hệ thống client/server ERP, reporting instance, operational data store. (2) Data staging: bao gồm flat files, bảng quan hệ,… (3) Presentation server: xác định nơi mà dữ liệu được lưu trữ để phục vụ cho hoạt động truy xuất dữ liệu, hệ thống báo cáo và các ứng dụng khác. Kiến trúc của Front room bao gồm: (1) Access tool data store: là công cụ hỗ trợ truy xuất dữ liệu và có thể có server riêng để lưu trữ kết quả truy xuất dữ liệu và báo cáo chuẩn. (2) Reporting data store: Data Mart và application model phục vụ cho truy xuất báo cáo, mô hình phân tích dự báo. (3) Downstream system: lưu trữ dữ liệu mang tính lịch sử trong Data Warehouse, đó có thể là những phân tích, mô hình được thực hiện nhiều lần trong quá khứ nhưng cần lưu trữ để phục vụ cho hoạt động phân tích khác. 3.2.5.3. Thu thập dữ liệu Bước đầu tiên cần thực hiện là tạo ra sơ đồ mô tả quy trình từ lúc bắt đầu đến kết thúc, bao gồm việc trích lọc dữ liệu từ nhiều nguồn dữ liệu khác nhau, xác định dữ liệu và chuyển đổi dữ liệu vào Data Warehouse. Tiếp theo là kiểm tra, lựa chọn công cụ thu thập dữ liệu, và lên kế hoạch chi tiết về trình tự từng bảng cần được thực hiện chuyển đổi dữ liệu. Sau đó, khu vực xử lý (data staging area) là nơi mà dữ liệu thô sẽ được đưa vào, làm sạch, kết hợp, lưu trữ và xuất ra tại tầng trình diễn dữ liệu. Tuy nhiên, nhiều sự kiểm tra ràng buộc được thực hiện tại khu vực này. 55

Kế tiếp là xây dựng và kiểm tra việc chuyển đổi dữ liệu vào bảng chiều. Bắt đầu với bảng chiều tĩnh (static dimension table), có hai phương pháp để trích lọc dữ liệu từ nguồn dữ liệu: file hoặc stream. Nếu nguồn dữ liệu là hệ thống cũ lâu đời thì có thể sử dụng file; nhưng nếu sử dụng công cụ và dữ liệu lưu trữ trong cơ sở dữ liệu thì có thể dùng stream. Tiếp theo, việc chuyển đổi dữ liệu có thể là chuyển kiểu dữ liệu, xác định khóa và xác định mối liên hệ giữa các bảng chiều. Cuối cùng là chuyển dữ liệu vào bảng chiều thông qua bulk loader. Kế đến là xây dựng và kiểm tra việc chuyển đổi dữ liệu vào bảng sự kiện. Đầu tiên, trích lọc dữ liệu từ các bảng sự kiện lịch sử, tìm kiếm khóa của bảng sự kiện, xử lý giá trị null. Sau đó, dữ liệu trong bảng sự kiện cần được tái cấu trúc và thực hiện chuyển đổi dữ liệu từ nguồn. Trong đó, cần xác định và xử lý dữ liệu sai hay còn gọi là “random/noise values”, chuyển dữ liệu dạng chuỗi số liên tục thành các dạng số theo nhóm bằng phương pháp rời rạc hóa, chuyển dữ liệu dạng chuỗi thành dạng số, … Dữ liệu trong bảng sự kiện phức tạp hơn so với bảng chiều bởi tính cập nhật liên tục bao gồm thêm mới, chỉnh sửa, xóa dòng dữ liệu. Cho nên, việc chuyển đổi dữ liệu cần thực hiện tuần tự và tạo các log ghi nhận dữ liệu thay đổi. Ngoài ra, bảng sự kiện chứa lượng lớn dữ liệu, vì vậy cần tạo các index, thực hiện phân khu dữ liệu, và quá trình chuyển đổi dữ liệu có thể thực hiện đồng thời trên nhiều phân khu dữ liệu khác nhau. Bên cạnh đó, có thể thực hiện thêm các tính toán tổng hợp dựa trên bảng sự kiện và tạo cube tính toán. 3.2.6. Luồng ứng dụng Luồng ứng dụng bao gồm (1) đặc tả ứng dụng người dùng cuối và (2) phát triển ứng dụng người dùng cuối. Cụ thể là (1) xác định tập tiêu chuẩn, yêu cầu của các ứng dụng dành cho đối tượng người dùng cuối, đây được xem như là tập hợp các ứng dụng có liên kết chặt chẽ với nhau tạo nên hệ thống. Trong đó, 56

các đặc tả mô tả mẫu báo cáo, phương thức tính toán và thông số được thiết kế dựa trên bảng mô tả yêu cầu nghiệp vụ và đảm bảo có sự thống nhất giữa nhóm phát triển ứng dụng, người phân tích và người dùng cuối. Tiếp theo, (2) việc phát triển bao gồm cấu hình siêu dữ liệu và xây dựng các báo cáo dashboard, phân tích KPI, hoặc cao cấp hơn là những ứng dụng giúp đưa ra dự báo, phân tích mối quan hệ giữa các thành phần/yếu tố. 3.2.7. Triển khai và bảo trì Data Warehouse, sau quá trình xây dựng thành công, cần tập trung hơn vào việc hỗ trợ đối tượng người sử dụng thuộc phòng ban nghiệp vụ. Hoạt động này đóng vai trò không kém phần quan trọng trong dự án, nhờ vào hoạt động tập huấn và hướng dẫn sử dụng hệ thống, bao gồm thao tác các công cụ, dữ liệu và phân tích. Bên cạnh đó, việc quản lý Data Warehouse bao gồm quản trị hạ tầng kỹ thuật, cải thiện tốc độ truy xuất và tính toán dữ liệu, bảo trì dữ liệu và meta data. Ngoài ra, hoạt động đo lường và đánh giá Data Warehouse dựa trên các chỉ số đo lường thành công đã đặt ra ban đầu, đồng thời ghi nhận các quyết định đã thực hiện dựa trên các phân tích, mô hình, quy luật kết luận từ ứng dụng business intelligence. Hoạt động phát triển Data Warehouse được thực hiện theo quy trình Data Warehouse lifecycle: lên kế hoạch, xác định yêu cầu nghiệp vụ, hạ tầng kỹ thuật, thiết kế đa chiều, chuẩn bị và thu thập dữ liệu, thiết kế ứng dụng và phát triển, triển khai và đánh giá kết quả. Tóm lại Chương ba trình bày về các giai đoạn trong dự án xây dựng và triển khai Data Warehouse tại doanh nghiệp, bao gồm từ bước khởi đầu là hoạch định dự án để xác định rõ phạm vi, từ đó xác định yêu cầu nghiệp vụ cần phải đáp ứng. Tiếp theo, từ hoạt 57

động phân tích yêu cầu nghiệp vụ, tiến hành xây dựng thiết kế kiến trúc kỹ thuật, mô hình đa chiều và thiết kế vật lý của Data Warehouse. Ngoài ra, hoạt động thu thập và chuẩn bị dữ liệu được thực hiện nhằm chuyển đổi dữ liệu từ nhiều nguồn khác nhau vào Data Warehouse và đảm bảo theo một quy định, cấu trúc nhất định. Cuối cùng là hoạt động bảo trì hệ thống và đánh giá sau triển khai, cũng như việc lên kế hoạch cho những cải tiến cần thực hiện trong dự án tiếp theo. Câu hỏi 1.

Dự án triển khai kho dữ liệu trong doanh nghiệp là gì?

2.

Anh/chị hãy trình bày các giai đoạn chính trong triển khai dự án kho dữ liệu.

3.

Tại sao hai giai đoạn là xác định dự án và phạm vi và xác định yêu cầu nghiệp vụ có thể được thực hiện song song?

4.

Anh/chị hãy trình bày về luồng công nghệ, luồng dữ liệu và luồng ứng dụng trong dự án kho dữ liệu.

58

Chương 4 THIẾT KẾ KHO DỮ LIỆU Với xu hướng phát triển hiện nay, việc thu thập, khai thác và sử dụng dữ liệu một cách hiệu quả là một trong những yếu tố quan trọng quyết định sự phát triển của doanh nghiệp. Do đó việc xây dựng một kho dữ liệu riêng cho doanh nghiệp phục vụ phân tích, dự báo và tối ưu hóa quá trình ra quyết định là yêu cầu hết sức cấp thiết. Bên cạnh đó việc tối ưu hóa tốc độ truy vấn cho kho dữ liệu là điều kiện tiên quyết để triển khai một dự án kho dữ liệu hiệu quả. 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à mô hình dữ liệu đa chiều. Chương này sẽ tập trung chủ yếu vào nội dung thiết kế và xây dựng mô hình dữ liệu đa chiều và minh họa quá trình thiết kế nhà kho dữ liệu sử dụng cơ sở dữ liệu mẫu AdventureWorks. 4.1. Phương pháp luận thiết kế kho dữ liệu Từ những năm 1990, để khai thác và sử dụng dữ liệu một cách hiệu quả, các doanh nghiệp lớn đã bắt đầu quan tâm đến việc xây dựng kho dữ liệu phục vụ mục đích kinh doanh. Trong thực tiễn, mỗi doanh nghiệp đều có một phương pháp thiết kế kho dữ liệu riêng biệt tùy vào nhu cầu kinh doanh, các yêu cầu về chức năng, quy trình nghiệp vụ, … Tuy nhiên tất cả các phương pháp thiết kế kho dữ liệu đều dựa trên hai phương pháp luận thiết kế cơ bản là: Top-down và Bottom-up hoặc kết hợp cả hai. 4.1.1. Phương pháp tiếp cận Top-Down Phương pháp tiếp cận Top-Down được đề xuất bởi Bill Inmon. Ông đưa ra khái niệm Data Warehouse là nơi chứa tất cả 59

các thông tin cho toàn bộ doanh nghiệp. Theo ông, kho dữ liệu phải là cơ sở dữ liệu quan hệ đã được chuẩn hóa và chứa toàn bộ dữ liệu của doanh nghiệp ở mức chi tiết nhất. Các Data Mart phục vụ các nhu cầu kinh doanh khác nhau chỉ có thể được tạo ra sau khi đã có một Data Warehouse hoàn chỉnh. Do vậy, Data Warehouse được xem là trung tâm thông tin của doanh nghiệp CIF (Corporate Information Factory) và là nền tảng để triển khai Business Intelligence. Theo phương pháp tiếp cận này, quy trình bắt đầu bởi quá trình trích xuất (Extract), chuyển đổi (Transform) và tải dữ liệu (Load) từ nhiều nguồn dữ liệu khác nhau. Sau quá trình trích xuất và chuyển đổi, dữ liệu sẽ được đưa vào kho dữ liệu của doanh nghiệp EDW (Enterprise Data Warehouse). Các Data Mart được tạo thành từ việc tổng hợp dữ liệu từ kho dữ liệu và được duy trì như tập con của kho dữ liệu.

Hình 0.1. Phương pháp tiếp cận Top- down (George, 2012) 4.1.2. Phương pháp tiếp cận Bottom-Up Trong cách tiếp cận Bottom-Up do Ralph Kimball đề xuất, các Data Mart được tạo ra đầu tiên phục vụ nhu cầu báo cáo của doanh nghiệp. Một Data Mart sẽ tương ứng với một lĩnh vực kinh doanh đơn lẻ như bán hàng, tài chính… Các Data Mart sau đó được tích hợp để xây dựng một kho dữ liệu hoàn chỉnh. Ý tưởng trung tâm của phương pháp tiếp cận này là không cần phát triển một DW hoàn chỉnh ngay từ đầu và DW sẽ được hình 60

thành tăng dần theo thời gian từ các Data Mart độc lập. Quy trình bắt đầu bởi quá trình trích xuất, chuyển đổi và truyền dữ liệu (ETL) cho một hay nhiều Data Mart và dữ liệu sẽ được lưu trữ theo dạng lược đồ hình sao (Star schema) hoặc bông tuyết (Snowflakes), từ đó dữ liệu sẽ được phân tích, xử lý và tạo báo cáo.

Hình 0.2. Phương pháp tiếp cận Bottom- Up (George, 2012) 4.1.3. So sánh ưu nhược điểm của hai phương pháp tiếp cận Phương pháp tiếp cận Top-Down của Bill Inmon: Cơ sở dữ liệu được tổ chức theo mô hình cơ sở dữ liệu quan hệ (ER Model) và được chuẩn hóa theo luật chuẩn hóa như đối với cơ sở dữ liệu quan hệ thông thường (dạng chuẩn 3), do đó dữ liệu được nạp từ nguồn vào đích dễ dàng và ở dạng chuẩn 3 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. Phương pháp tiếp cận Bottom-up của Ralph Kimball: Cơ sở dữ liệu được lưu trữ dưới dạng phi chuẩn hóa bao gồm bảng dữ kiện (fact) chứa thông tin liên kết và các bảng chiều (dimension) đóng vai trò như là bảng tham chiếu lấy thông tin. Phương pháp tiếp cận này giúp cho các truy vấn của người dùng cuối có thể 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. Đây cũng là phương pháp tiếp cận theo hướng nghiệp vụ, nghĩa là ánh xạ trực tiếp từ quy trình nghiệp vụ của doanh nghiệp. 61

Bảng 0.1. So sánh giữa phương pháp tiếp cận của Inmon và Kimball Tiêu chuẩn so sánh

Inmon

Kimball

Thời gian xây dựng

Tốn nhiều thời gian

Tốn ít thời gian hơn

Bảo trì

Dễ dàng

Khó hơn do có thể bị trùng lặp dữ liệu

Chi phí

Chi phí xây dựng ban đầu lớn

Chi phí xây dựng ban đầu thấp

Thời gian

Thời gian khởi tạo dự án dài

Thời gian khởi tạo dự án ngắn hơn

Yêu cầu kỹ năng

Đội ngũ phát triển cần kỹ năng chuyên nghiệp

Không cần đội ngũ phát triển quá chuyên nghiệp

Yêu cầu tích hợp dữ liệu

Dữ liệu kinh doanh toàn bộ doanh nghiệp

Dữ liệu một lĩnh vực kinh doanh cụ thể

Trong xu hướng hiện tại, cách tiếp cận Bottom-Up của Kimball được sử dụng phổ biến hơn trong thực tiễn do các doanh nghiệp mong muốn bắt đầu một dự án BI vừa phải, tốn ít chi phí, thời gian triển khai nhanh và có thể đem lại hiệu quả thật sự. Việc xây dựng một kho dữ liệu cho toàn bộ doanh nghiệp đôi khi trở nên lãng phí vì dữ liệu không được khai thác một cách hiệu quả. Vì lý do này, tài liệu này sẽ tiếp cận theo hướng Bottom-Up do Kimball đề xuất. 4.2. Mô hình dữ liệu đa chiều Mô hình dữ liệu đa chiều (Demensiton model) là cơ sở nền tảng của phương pháp tiếp cận theo hướng Bottom-Up của Kimball. Ngày nay, mô hình dữ liệu đa chiều được sử dụng rộng rãi và là kỹ thuật thường được chọn trong phân tích dữ liệu bởi vì nó giải quyết hai yêu cầu đồng thời: 62

 Cung cấp dữ liệu một cách dễ hiểu nhất đối với người dùng doanh nghiệp.  Hiệu suất truy vấn nhanh. Mô hình dữ liệu đa chiều là một kỹ thuật đã có từ rất lâu dùng để xây dựng các cơ sở dữ liệu đơn giản. Trải qua nhiều thập kỷ triển khai trong thực tế, mô hình dữ liệu đa chiều được phát triển theo xu hướng đơn giản hóa về mặt cấu trúc để đảm bảo người dùng có thể dễ dàng hiểu được dữ liệu cũng như cho phép quá trình xử lý dữ liệu trở nên nhanh chóng và hiệu quả hơn. Đặt tình huống giả định giám đốc của một doanh nghiệp phát biểu rằng: “Chúng tôi bán các sản phẩm tại các thị trường khác nhau và đo hiệu suất theo thời gian”. Một nhà thiết kế mô hình dữ liệu đa chiều sẽ ghi nhận yêu cầu một cách cẩn thận để nhấn mạnh vào các yếu tố sản phẩm, thị trường và thời gian. Có thể xem dữ liệu doanh nghiệp là một khối dữ liệu (Cube) với các cạnh được dán nhãn sản phẩm, thị trường, và thời gian. Hãy thử tưởng tượng rằng chúng ta thực hiện cắt và chia nhỏ (slicing and dicing) khối dữ liệu thành từng khối lập phương đơn vị theo từng cạnh. Bên trong những khối lập phương đơn vị sẽ chứa dữ liệu về doanh số hoặc lợi nhuận theo sản phẩm, thị trường và thời gian. Việc biểu diễn mô hình dữ liệu đa chiều trừu tượng dưới dạng khối dữ liệu cụ thể, hữu hình sẽ giúp thiết kế trở nên dễ hiểu hơn. Một thiết kế bắt đầu đơn giản thì sẽ có cơ hội vẫn còn đơn giản khi hoàn chỉnh. Nếu một thiết kế ban đầu quá phức tạp, thì dĩ nhiên khi hoàn chỉnh nó sẽ càng phức tạp, điều này sẽ dẫn đến hiệu suất truy vấn chậm và nó sẽ bị người dùng từ chối sử dụng. Mặc dù mô hình dữ liệu đa chiều thường được thể hiện dưới dạng cơ sở dữ liệu quan hệ nhưng nó lại rất khác so với cấu trúc dữ liệu dạng chuẩn 3 ở mức độ chuẩn hóa dữ liệu. Dạng chuẩn 3 63

là cấu trúc chuẩn hóa cao nhất, trong đó dữ liệu được phân chia thành nhiều thực thể riêng biệt để loại bỏ sự dư thừa dữ liệu, còn mô hình dữ liệu đa chiều chấp nhận sự dư thừa dữ liệu nhằm mục đích tăng tốc độ truy vấn. Cấu trúc dạng chuẩn 3 (3NF) rất hữu ích trong việc lưu trữ các dữ liệu giao dịch vì các hoạt động Insert hoặc Update các record trong cơ sở dữ liệu chỉ thực hiện ở một nơi duy nhất. Tuy nhiên mô hình 3NF lại tỏ ra quá phức tạp cho các truy vấn BI. Người dùng khó có thể hiểu và kiểm soát cấu trúc phức tạp của các bảng dữ liệu. Hơn nữa, hầu hết các hệ quản trị cơ sở dữ liệu đều tỏ ra kém hiệu quả khi thực hiện truy vấn cấu trúc dữ liệu dạng chuẩn 3 (3NF). Sự phức tạp của các truy vấn và hiệu suất truy vấn chậm đã lấn át các ưu điểm của cơ sở dữ liệu dạng chuẩn 3. Vì vậy, trong lĩnh vực thiết kế nhà kho dữ liệu (DW) và giải pháp BI, mô hình dữ liệu đa chiều đã chiếu ưu thế hơn so cấu trúc dạng chuẩn 3 về tính trực quan, dễ hiệu và tốc độ truy vấn. 4.2.1. Bảng sự kiện (Fact table) trong mô hình đa chiều Bảng sự kiện trong mô hình đa chiều lưu trữ các dữ liệu đo lường hiệu quả của quá trình kinh doanh của tổ chức. Hãy tưởng tượng bạn đang thống kê các sản phẩm đang được bán tại một siêu thị bằng cách ghi nhận dữ liệu bán hàng bao gồm số lượng và doanh số bán hàng theo sản phẩm trong mỗi giao dịch tại quầy tính tiền. Số liệu của mỗi giao dịch sẽ bao gồm thời gian bán hàng, số lượng sản phẩm, doanh số, mã giao dịch, mã khách hàng, mã nhân viên….Các dữ liệu này chính là dữ liệu đo lường quá trình bán hàng và sẽ được lưu trữ trong bảng sự kiện (hình 4.3). Việc số liệu đo lường cho một sự kiện kinh doanh cụ thể sẽ chỉ tương ứng với một hàng duy nhất trong bảng sự kiện là một nguyên tắc nền tảng cho mô hình dữ liệu đa chiều. Tất cả các nguyên tắc khác đều được xây dựng trên nền tảng này. 64

Hình 0.3. Bảng sự kiện được xây dựng dựa trên sự kiện kinh doanh (Kimball & Ross, 2013) Trên thực tế, dữ liệu trong các bảng sự kiện thường ở dạng số (numeric) và có tính chất cộng (additive). Tính chất cộng rất quan trọng vì trong các ứng dụng BI, các bảng sự kiện thường bao gồm hàng nghìn, thậm chí hàng triệu dòng và số liệu tổng hợp được xử lý bằng cách cộng dữ liệu từ các dòng trong bảng này. Lấy ví dụ đơn giản về một Fact table thể hiện doanh số bán hàng hàng ngày như sau: Daily Sales Fact table Date Key (FK) Product Key (FK) Store Key (FK) Quantity Sold Dollar Sales Amount

Có thể dễ dàng nhận thấy trong Daily Sales Fact table chỉ có hai loại dữ liệu chính: foreign keys và dữ liệu sự kiện. Date Key, Product Key, và Store Key là các foreign keys. Quantity Sold và Dollar Sales Amount là các dữ liệu sự kiện (dữ liệu đo lường). 65

Date Key, Product Key và Store Key liên kết đến các Dimension table tương ứng là Date, Product, Store. (Khái niệm về Dimension table sẽ được trình bày ở phần dưới). Với cách tổ chức như trên, việc tính tổng lượng hàng hóa bán ra hoặc tổng thu nhập khá là đơn giản. Ta chỉ việc thực hiện phép toán cộng trên các dòng là xong. Điều này cũng không khác nhiều lắm so với việc dùng các bảng trong cơ sở dữ liệu nghiệp vụ. Điều khác biệt ở đây là tốc độ và sự thuận tiện. Do cấu trúc của bảng sự kiện khá đơn giản, chỉ chứa duy nhất foreign keys và dữ liệu sự kiện, ngoài ra không có bất cứ thông tin nào khác nên tốc độ truy cập bảng khá nhanh. Kỹ thuật thường được sử dụng là tạo index cho các foreign key. Độ mịn (grain) Mỗi hàng trong một bảng sự kiện tương ứng với một sự kiện được đo lường. Các dữ liệu trên mỗi hàng ở một mức độ chi tiết cụ thể nhất định được gọi là độ mịn (Fact grain). Fact grain là một khái niệm để xác định mức độ chi tiết của thông tin chứa trong Fact table, ví dụ như mỗi record thể hiện cho mỗi sản phẩm được bán trong một giao dịch bán hàng. Một trong những nguyên lý cốt lõi của mô hình dữ liệu đa chiều là tất cả các hàng trong một Fact table phải có cùng độ mịn. Hãy xét bảng Daily Sales ở trên. Fact grain hiện tại của nó là: một loại sản phẩm (product) được bán tại một cửa hàng (store) trong một ngày (date). Bảng có các record sau: Quantity Sold

Amount Sales($)

Date Key

Product Key

Store Key

2016-06-01

XYZ

ABC

400

2000

2016-06-02

XYZ

ABC

300

1500

2016-06-02

DEF

UVW

500

2500

66

Với độ mịn như trên và giả sử rằng giá trị đơn vị của một sản phẩm là $5, ta có thể nói như sau: - Loại sản phẩm ABC được bán tại cửa hàng XYZ trong ngày 2016-06-01 với số lượng là 400, thu về khoản tiền $2000. - Loại sản phẩm ABC được bán tại cửa hàng XYZ trong ngày 2016-06-02 với số lượng là 300, thu về khoản tiền $1500. - Loại sản phẩm DEF được bán tại cửa hàng UVW trong ngày 2016-06-02 với số lượng là 500, thu về khoản tiền $2500. Tất cả các record ở trên đều thỏa mãn điều kiện: một loại sản phẩm (product) được bán tại một cửa hàng (store) trong một ngày (date). Đây được gọi là độ mịn, hay mức độ chi tiết của Fact table (Fact grain). Nếu ta muốn tính tổng số lượng hàng hóa bán ra trong ngày 2016-06-02 trên mọi cửa hàng và mọi sản phẩm, ta sẽ có được con số sau: 300 + 500 = 800. Nếu ta muốn tính tổng số tiền thu được từ cửa hàng ABC trong tuần đầu tiên của tháng 06 trên mọi loại sản phẩm, ta có: 2000 + 1500 = $3500. 4.2.2. Bảng chiều (Dimension table) trong mô hình đa chiều Bảng chiều là được xem như là bạn đồng hành không thể thiếu của bảng sự kiện. Các bảng chiều chứa dữ liệu ngữ cảnh liên quan đến việc đo lường một sự kiện của quá trình kinh doanh. Nếu như Fact table chứa các FK (foreign keys) và dữ liệu đo lường, thì Dimension table chứa các thông tin miêu tả nghiệp vụ. Trong không gian của mô hình đa chiều, các thông tin này được gọi là thuộc tính (attribute) của bảng chiều. Còn khi được lưu trữ cụ thể trong một cơ sở dữ liệu quan hệ, các thông tin này chính là các cột của bảng. 67

Một nguyên tắc thiết kế của Data Warehouse là cố gắng đưa càng nhiều thông tin vào bảng chiều càng tốt. Nói cách khác, ta tìm cách “làm phẳng” hay “phi chuẩn hóa 3NF” đối với một bảng chiều. Lấy Product dimension làm ví dụ. Ở database nguồn, giả sử ta có ba bảng được thiết kế theo đúng tiêu chí của 3NF là Product, SubCategory, Category. Do cả ba bảng này đều cùng miêu tả một đối tượng là Product nên khi chuyển sang dimensional model, ta chỉ cần một Product dimension bao gồm luôn thông tin từ cả ba bảng nói trên. Với cách làm như vậy, một bảng chiều thường có nhiều cột và cũng không quá khó hiểu nếu ta thấy có những bảng chiều có từ 50 đến 100 cột. Số lượng record trong một Dimension table thường không nhiều. Trong ví dụ nói trên, Product dimension sẽ có cùng số lượng record như của bảng Product trong database nguồn. Mỗi Dimension table cũng có một primary key (PK) để xác định tính duy nhất của một record. Primary key này sẽ được kết (join) với Foreign key tương ứng nằm trên Fact table để kết nối hai bảng Dimension và Fact với nhau. Bảng chiều đóng vai trò sống còn trong Data Warehouse. Do chúng chứa các thông tin miêu tả nghiệp vụ, nên đây là nguồn được dùng để sàng lọc dữ liệu, gộp nhóm và tạo các nhãn trình bày. Trong ví dụ ở trên, nếu người dùng muốn xem tổng số tiền bán hàng theo tuần và loại hàng hóa, hiển nhiên bảng sự kiện chỉ có thể cung cấp số liệu về số tiền thu được. Thông tin về loại hàng hóa chỉ có thể lấy được từ Product dimension, trong khi thông tin về thời gian cũng chỉ có thể tìm được trong Date dimension. Nói cách khác, người dùng tương tác với Data Warehouse chủ yếu là qua các Dimension table, còn Fact table chỉ cung cấp các số liệu. 68

Hình 0.4. Minh họa về Product Dimension Các thuộc tính của bảng chiều thường chứa dữ liệu dạng text và có tính rời rạc. Một dữ liệu thuộc tính có thể chứa một miêu tả ngắn (10 - 15 ký tự) hoặc dài (30-50 ký tự), tên hàng, tên loại hàng, kiểu đóng gói, kích cỡ,... Các thuộc tính (attributes) trong một dimension thường tạo thành các cây phân cấp (hierarchy). Trong Product dimension đã nói ở trên, Product là cấp thấp nhất, phía trên là SubCategory, và trên cùng là Category. Một cách rất tự nhiên, người dùng có thể dễ dàng xem được tổng doanh thu của một Category rồi đi sâu xuống (drill down) xem sự phân bố của doanh thu theo các SubCategory trong cùng Category đó. Mức thấp nhất sẽ là doanh thu của từng Product trong một SubCategory. Quá trình ngược lại được gọi là drill up. Drill up/down là những thao tác thông dụng nhất của các ứng dụng Data Warehouse. Sở dĩ các thao tác này trở nên dễ dàng và nhanh chóng là do các thông tin về SubCategory và Category đã được đưa vào Product dimension, 69

hay nói cách khác, ta đã “làm phẳng” dimension này. Giả sử ta đưa SubCategory và Category vào các dimension tương ứng rồi liên kết chúng với Product dimension qua các foreign keys thích hợp. Cách làm không hề sai và thiết kế theo kiểu này được gọi là mô hình “bông tuyết” (snow flake) bởi hình dạng mà chúng tạo ra giống hệt một bông tuyết. Tuy nhiên, việc truy cập vào SubCategory và Category bây giờ phải được thực hiện trên ba chiều thay vì một như trước đây. Không kể đến việc người dùng sẽ phải làm nhiều thao tác hơn, tốc độ truy cập chắc chắn sẽ giảm đi đáng kể. Có thể nói, trong thiết kế bảng chiều, chúng ta đã hy sinh chuẩn 3NF để đổi lấy sự đơn giản và tốc độ. Đây có thể coi là một nguyên tắc vàng của mô hình đa chiều. 4.2.3. Kết hợp Fact table và Dimenstion table trong mô hình hình sao

Hình 0.5. Thiết kế dữ liệu theo hình mô hình hình sao (Kimball & Ross, 2013) Mỗi quá trình kinh doanh được biểu diễn bởi một mô hình đa chiều trong đó bao gồm một bảng sự kiện chứa số liệu đo lường các sự kiện được liên kết bao quanh bởi các bảng chiều chứa dữ liệu liên quan đến bối cảnh sự kiện đó xảy ra. Cấu trúc này giống hình ảnh một ngôi sao với bảng sự kiện ở trung tâm và các bảng chiều xung quanh nên được gọi là cấu trúc hình sao “Star schema”. Điều đầu tiên cần chú ý về Star schema là sự đơn giản và tính đối xứng. Nếu xét từ góc độ thuần túy nghiệp vụ, 70

thiết kế này gần với cái nhìn của người dùng cuối nhất về nghiệp vụ của họ. Trong nhiều trường hợp, đây chính là bức tranh chính xác của nghiệp vụ mà người dùng làm việc trong đó. Hơn nữa, việc giảm số lượng của các bảng và sử dụng các mô tả kinh doanh có ý nghĩa làm cho mô hình Star schema trở nên rất dễ hiểu, dễ quản lý và giảm thiểu khả năng xảy ra sai sót. Đi sâu hơn một chút, quá trình xây dựng một cơ sở dữ liệu quan hệ cho một ứng dụng rồi xây dựng Data Warehouse cho ứng dụng đó giống như một vòng tuần hoàn. Một trong những bước đầu tiên để xây dựng cơ sở dữ liệu quan hệ là phải xác định được mô hình quan hệ thực thể (Entity Relationship). Sau khi các thực thể và các mối quan hệ giữa chúng đã được xác định, chúng ta mới tiến hành xây dựng các bảng rồi chuẩn hóa dữ liệu để đạt chuẩn 3NF. Trong quá trình này, các thực thể có thể được phân nhỏ ra để tạo nên các bảng mới với các quan hệ 1N. Thông qua quá trình này, một mô hình ER với một lượng nhỏ thực thể ban đầu có thể phát triển thành một cơ sở dữ liệu lớn với hàng trăm bảng được kết nối với nhau qua các mối quan hệ 1-N hoặc 1-1. Một khối lượng thông tin như vậy rõ ràng là không hề dễ hiểu đối với người dùng cuối. Khi xây dựng một Data Warehouse theo dạng Star schema, ta lại thực hiện một quá trình đảo ngược khi biến một cơ sở dữ liệu phức tạp quay trở lại một dạng mô hình ER gần như ban đầu. Dĩ nhiên trong thực tế, một Star schema thường tập trung vào một phần nhỏ của cơ sở dữ liệu quan hệ. Do đó, từ một cơ sở dữ liệu ban đầu có thể xây dựng nhiều Star schema và mỗi Star schema sẽ tập trung vào một khía cạnh cụ thể của nghiệp vụ. Trong ví dụ trên, Product là một thực thể. Khi được đưa vào cơ sở dữ liệu quan hệ, nó được chuẩn hóa theo 3NF và tách ra thành ba bảng Product, SubCategory, Category. Khi đưa vào Data Warehouse, Product lại quay về hình dạng của thực thể Product ban đầu. 71

Do đó, khi xây dựng mô hình đa chiều, hãy tạm thời quên đi các bảng và các liên kết phức tạp trong database. Thay vào đó, hãy xác định các thực thể nghiệp vụ trước rồi đặt chúng trong những mối quan hệ với nhau. Về cơ bản đây chính là những gì mà người dùng muốn Data Warehouse làm được khi đầu tư vào xây dựng một ứng dụng như vậy. Do có tính đơn giản, nên Star schema là mô hình thiết kế đề cao tốc độ. Với số lượng ít hơn hẳn các bảng và các quan hệ giữa các bảng, việc truy cập dữ liệu trong bảng và thực hiện các phép liên kết giữa các bảng sẽ có tốc độ nhanh hơn rõ rệt. 4.3. Thiết kế mô hình đa chiều trong lĩnh vực kinh doanh bán lẻ Để hiểu rõ hơn về mô hình dữ liệu đa chiều, phần này sẽ trình bày cụ thể các bước thiết kế mô hình đa chiều trong lĩnh vực kinh doanh bán lẻ thông qua một tình huống cụ thể. Tình huống giả định là thực hiện thiết kế mô hình dữ liệu đa chiều cho một chuỗi cửa hàng bán lẻ bao gồm 100 cửa hàng phân bố ở một số tỉnh. Mỗi cửa hàng đều có đủ các bộ phận bao gồm thực phẩm, thực phẩm đông lạnh, sữa, thịt, sản xuất, bánh, hoa, và hỗ trợ sức khỏe/làm đẹp… Mỗi cửa hàng có khoảng 60.000 sản phẩm riêng biệt, mỗi sản phẩm được lưu kho với mỗi mã riêng biệt gọi là mã SKU (stock keeping units). Dữ liệu sẽ được thu thập tại một số vị trí khác nhau ở mỗi cửa hàng tạp hóa. Dữ liệu hữu ích nhất được thu tại máy tính tiền khi khách hàng mua sản phẩm. Hệ thống bán hàng POS sẽ quét mã vạch sản phẩm để ghi nhận số lượng sản phẩm bán tính toán thành tiền tại cửa trước của cửa hàng. Các dữ liệu khác được thu thập tại cửa sau của cửa hàng nơi các nhà cung cấp thực hiện việc giao hàng. Tại cửa hàng tạp hóa, quá trình quản lý có liên quan đến các hoạt động đặt hàng, lưu kho và bán các sản phẩm với mục tiêu 72

tối đa hóa lợi nhuận. Lợi nhuận của doanh nghiệp sẽ cao khi doanh thu bán sản phẩm cao và giảm thiểu chi phí giá vốn hàng bán, chi phí bán hàng và chi phí khác. Để đạt được doanh số tốt, doanh nghiệp phải thu hút càng nhiều khách hàng càng tốt trong một môi trường cạnh tranh cao. Một số các quyết định quản lý quan trọng nhất là quyết định về giá và chương trình khuyến mãi. Bộ phận tiếp thị ở trụ sở dành rất nhiều thời gian cho các chính sách giá và các chương trình khuyến mãi. Khuyến mãi tại một cửa hàng bao gồm các hoạt động giảm giá tạm thời, quảng cáo trên báo, hiển thị khuyến mãi tại cửa hàng và phát hành phiếu giảm giá. Cách trực tiếp và hiệu quả nhất để tạo ra một sự đột biến số lượng sản phẩm bán ra là thực hiện giảm giá. Khi thực hiện giảm giá, khuyến mãi ở mức độ hợp lý sẽ làm tăng doanh số, qua đó tăng lợi nhuận. Tuy nhiên nếu giảm giá, khuyến mãi quá nhiều có thể làm giảm lợi nhuận, thậm chí lỗ. Do đó việc phân tích dữ liệu bán hàng do tác động của giảm giá, khuyến mãi cũng hết sức có ý nghĩa đối với doanh nghiệp. Với dữ liệu giả định về chuỗi cửa hàng bán lẻ như trên, quá trình thiết kế mô hình dữ liệu đa chiều được thực hiện thông qua bốn bước như trình bày dưới đây. 4.3.1. Bốn bước thiết kế mô hình dữ liệu đa chiều Bước 1: Chọn lựa quy trình nghiệp vụ (Business process) Một quy trình nghiệp vụ là một hoạt động ở mức độ thấp được thực hiện trong một tổ chức, chẳng hạn như nhận đơn đặt hàng, hóa đơn, nhận thanh toán, xử lý các cuộc gọi, sinh viên đăng ký nhập học, hoặc xử lý yêu cầu của khách hàng. Khi thiết kế mô hình dữ liệu đa chiều, nhóm thiết kế cần khảo sát kỹ các quy trình nghiệp vụ của tổ chức thông qua các cuộc phỏng vấn. Hầu hết các nhà quản lý doanh nghiệp không trả lời trực tiếp câu hỏi: “Quy trình nghiệp vụ nào quan trọng mà họ thật sự quan tâm, cần phân tích và tổng hợp dữ liệu?”. Đôi khi người dùng 73

doanh nghiệp thích nói về ý tưởng, những yêu cầu về phân tích dữ liệu, báo cáo tổng hợp thay vì về quy trình nghiệp vụ. Do đó, nhóm phân tích cần có một kiến thức nhất định về quy trình nghiệp vụ, tổng hợp các thông tin thu thập được và thực hiện mô hình hóa các quy trình nghiệp vụ của doanh nghiệp. Nhóm phân tích cũng cần đào sâu nghiên cứu về dữ liệu và hệ thống quản lý điều hành của doanh nghiệp để xem xét khả năng đáp ứng các yêu cầu của doanh nghiệp. Bước đầu tiên trong việc thiết kế là xác định những quy trình nghiệp vụ cần mô hình hóa bằng cách kết hợp những hiểu biết về yêu cầu nghiệp vụ với nguồn dữ liệu hiện tại. Trong ví dụ về chuỗi cửa hàng bán lẻ, nhà quản lý muốn hiểu rõ hơn về hành vi mua của khách hàng bằng cách phân tích dữ liệu bán hàng thu thập từ hệ thống POS. Do đó, quá trình kinh doanh mà họ muốn mô hình hóa là các giao dịch bán lẻ POS. Dữ liệu này cho phép nhà quản lý có thể phân tích doanh số bán hàng của sản phẩm theo từng cửa hàng, theo ngày, theo các chương trình khuyến mãi, và theo từng giao dịch. Bước 2: Xác định độ mịn Xác định độ mịn (grain) nghĩa là xác định chính xác thông tin thể hiện trên một dòng của bảng sự kiện. Các mức độ mịn thể mức độ chi tiết liên quan đến dữ liệu đo lường của bảng sự kiện. Nó trả lời cho câu hỏi “Bạn mô tả một hàng duy nhất trong bảng sự kiện như thế nào?” Các mức độ mịn được xác định dựa trên các hoạt động thực tế và là bản ghi các sự kiện trong quá trình kinh doanh của doanh nghiệp. Có một số nhà thiết kế xem rằng bước xác định độ mịn là bước không quan trọng và do đó đã bỏ qua nó. Điều này là hoàn toàn sai lầm. Rất nhiều thiết kế thực tế đã mắc sai lầm lớn khi không thống nhất việc xác định độ mịn ngay từ đầu, dẫn đến sự mâu thuẫn trong thiết kế ở các bước tiếp theo. Tất cả thành viên 74

trong nhóm thiết kế phải thống nhất về mức độ chi tiết của bảng sự kiện. Trong trường hợp thực hiện tiếp các bước 3, bước 4 và phát hiện thiết kế về độ mịn không đúng, nhà thiết kế phải quay lại bước 2 để xác định độ mịn một cách chính xác và thực hiện lại bước 3 và bước 4 một lần nữa. Như vậy độ mịn phải được xác định ở mức chi tiết thế nào là hợp lý? Việc lưu trữ dữ liệu ở bảng sự kiện ở mức độ chi tiết nhất có thể (atomic grain) sẽ có nhiều ý nghĩa vì khi đó tất cả dữ liệu thu thập từ thực tế sẽ được ghi nhận ở mức chi tiết nhất. Mức độ chi tiết của độ mịn sẽ cho phép phân tích dữ liệu một cách linh hoạt tối đa nhất có thể và từ mức này có thể tổng hợp thành bất kỳ loại dữ liệu nào mà người dùng doanh nghiệp yêu cầu. Dĩ nhiên, bạn có thể khai báo độ mịn cho bảng sự kiện ở mức độ tổng quát hóa hơn, tuy nhiên nếu chọn độ mịn lớn, nhà thiết kế đã tự giới hạn mình ở mức độ chi tiết của dữ liệu. Mô hình dữ liệu đa chiều sẽ gặp vấn đề nếu người dùng muốn truy cập vào dữ liệu chi tiết hơn. Người dùng chắc chắn sẽ cảm thấy khó chịu khi bị chặn và không tiếp tục truy cập được vào các dữ liệu ở mức thấp nhất. Người dùng có thể dễ dàng tổng hợp dữ liệu từ dữ liệu chi tiết nhất, nhưng họ không thể tạo ra các dữ liệu chi tiết từ dữ liệu tổng hợp. Trong ví dụ về chuỗi bán lẻ, dữ liệu chi tiết nhất là một sản phẩm riêng biệt trên từng giao dịch POS. Mặc dù người dùng có thể không quan tâm đến việc phân tích các sản phẩm riêng rẽ trong một giao dịch POS cụ thể, bạn không thể dự đoán tất cả những yêu cầu mà họ sẽ muốn thông qua dữ liệu đó. Ví dụ, họ có thể muốn hiểu sự khác biệt trong bán hàng vào thứ hai so với ngày chủ nhật. Hoặc họ có thể muốn đánh giá xem liệu có nên lưu kho nhiều hơn đối với một số sản phẩm đặc thù của một số thương hiệu. Hoặc họ có thể muốn hiểu làm thế nào nhiều người 75

mua hàng đã sử dụng chương trình khuyến mãi giảm giá 50% vào sản phẩm dầu gội đầu, hoặc xác định các yếu tố ảnh hưởng làm giảm doanh thu khi có một sản phẩm cạnh tranh đang thực hiện những đợt khuyến mãi lớn… Mặc dù người dùng doanh nghiệp không yêu cầu truy vấn dữ liệu từ một giao dịch cụ thể, nhưng họ lại thường đặt ra những câu hỏi lớn mà chỉ có dữ liệu ở mức chi tiết mới có thể phân tích được. Không người dùng doanh nghiệp nào muốn bỏ tiền đầu tư hệ thống DW/BI nếu hệ thống đó chỉ có thể cung cấp những dữ liệu tổng hợp. Bước 3: Nhận dạng các chiều (Dimensions) Để nhận dạng các chiều của mô hình, cần trả lời câu hỏi, “Các nhà kinh doanh mô tả các dữ liệu thu được từ các sự kiện trong các quy trình nghiệp vụ như thế nào?” Nếu đã xác định được độ mịn, các chiều có thể dễ dàng được nhận ra bằng cách đặt các câu hỏi “ai (who), cái gì (what), ở đâu (where), khi nào (when), tại sao (why) và như thế nào (how)” liên quan đến sự kiện này. Các chiều thông thường có thể là ngày, sản phẩm, khách hàng, nhân viên và cửa hàng. Ngoài ra, một mô tả về độ mịn một cách chi tiết sẽ giúp xác định được các chiều cơ bản của bảng sự kiện. Sau đó nhà thiết kế sẽ có thêm các chiều khác nếu việc bổ sung các bảng chiều không làm thay đổi độ mịn của bảng sự kiện. Trường hợp khi thêm bảng chiều mà làm thay đổi độ mịn, thì bảng chiều đó phải bị loại bỏ hoặc chúng ta phải quay lại bước 2 để xem xét điều chỉnh lại độ mịn cho bảng sự kiện. Trong ví dụ về chuỗi bán lẻ, bạn có thể đặt các câu hỏi liên quan đến sự kiện bán hàng như ngày bán hàng, cửa hàng, nơi bán hàng, các sản phẩm được bán ra trong các chương trình khuyến mãi, nhân viên tính tiền tại quầy, người xử lý bán hàng hoặc là các phương pháp thanh toán. Như vậy các chiều của thiết kế bao gồm: ngày, sản phẩm, cửa hàng, khuyến mãi, nhân viên bán hàng và phương thức thanh toán. 76

Bước 4: Nhận dạng các dữ liệu sự kiện Các dữ liệu sự kiện được xác định thông qua việc trả lời câu hỏi, “Các quy trình nghiệp vụ được đo lường qua những yếu tố nào?”. Người dùng doanh nghiệp thường rất quan tâm đến việc phân tích các số liệu hiệu suất hoạt động. Tất cả các dữ liệu sự kiện trong một thiết kế phải phù hợp với độ mịn được xác định ở bước 2. Các dữ liệu sự kiện phải có thể phân tách để lưu trữ ở mức độ chi tiết được thiết kế ban đầu trong bảng sự kiện. Thông thường, các dữ liệu sự kiện phải có tính chất cộng (additive) để có thể tổng hơp số liệu ở mức cao hơn, ví dụ như số lượng đơn hàng, doanh số…Nhà thiết kế cần phải xem xét cả hai yếu tố là yêu cầu nghiệp vụ (Business requirements) của người dùng doanh nghiệp và nguồn dữ liệu thực tế (Data realities) để đưa ra quyết định liên quan đến bốn bước, như minh họa trong hình 4.6.

Hình 0.6. Hai yếu tố ảnh hưởng đến mô hình thiết kế dữ liệu đa chiều Trong ví dụ về chuỗi bán lẻ, các dữ liệu sự kiện được thu thập thông qua hệ thống POS bao gồm số lượng sản phẩm bán được, đơn giá gốc và giảm giá cho từng sản phẩm, doanh số bán hàng và tổng giảm giá. Doanh số bán hàng sẽ được tính bằng số lượng bán được nhân với đơn giá bán ròng (giá gốc trừ giảm giá) và tổng giảm giá sẽ được tính bằng giá giảm đơn vị nhân với số lượng bán. Nếu hệ thống POS có thể cung cấp giá vốn hàng bán, chi phí này có thể được lưu trữ trong dữ liệu “extended cost amount” trong bảng sự kiện (hình 4.7). 77

Hình 0.7. Dữ liệu sự kiện trong sơ đồ hình sao (Kimball & Ross, 2013) Derived Facts Trong thiết kế hình 4.7, lợi nhuận gộp (Extend Gross Profit Dollar Amount) có thể được tính toán bằng cách lấy doanh thu trừ chi phí (Extended sales Dollar Amount trừ cho Extended Cost Dollar Amount). Trong bảng sự kiện, các dữ liệu có thể tính toán được từ dữ liệu khác được gọi là Derived Facts. Trong thiết kế mô hình đa chiều, một câu hỏi đặt ra là liệu rằng có cần thiết phải lưu dữ liệu Derived Facts? Trong ví dụ về chuỗi bán lẻ, việc tính dữ liệu lợi nhuận khá đơn giản, tuy nhiên lời khuyên của các chuyên gia thiết kế là vẫn phải nên lưu dữ liệu lợi nhuận gộp để đảm bảo tính nhất quán trong quá trình ETL và loại bỏ khả năng lỗi trong quá trình tính toán. Chi phí thiệt hại khi kết xuất dữ liệu sai sẽ lớn hơn nhiều so với chi phí lưu trữ vốn gia tăng không đáng kể nếu thêm một cột. Việc lưu trữ lợi nhuận gộp đảm bảo tất cả người dùng và các ứng dụng BI được truy xuất trực tiếp từ một dữ liệu nhất quán. Vì lợi nhuận gộp có thể được tính từ dữ liệu liền kề trong một dòng của bảng sự kiện, một số ý kiến sẽ cho rằng bạn nên thực hiện các phép tính trong View. Đây là sẽ là một cách tiếp 78

cận hợp lý nếu tất cả người dùng truy cập dữ liệu qua View và không có trường hợp nào dùng một công cụ truy vấn trực tiếp dữ liệu bảng, như vậy cơ sở dữ liệu phải được thiết lập để mọi truy cập đều phải thông qua View. Ngoài ra, một số ý kiến cho rằng có thể thực hiện tính toán bên trong các ứng dụng BI. Thiết kế như vậy sẽ hợp lý nếu tất cả mọi người dùng đều sử dụng một công cụ phổ biến chung để truy cập dữ liệu, tuy nhiên điều này hiếm xảy ra trong thực tế. Đối với các số liệu không có tính chất cộng (additive), ví dụ như tỷ lệ phần trăm, thì chúng phải được tính toán trong ứng dụng BI. Sự kiện không có tính cộng (Non-Additive Facts) Tỷ suất lợi nhuận gộp biên (Gross margin) có thể được tính bằng cách chia lợi nhuận gộp cho doanh thu bán hàng. Lợi nhuận gộp là dữ liệu sự kiện không có tính cộng (Non-Additive Facts) vì nó không thể được tổng hợp theo bất kỳ chiều nào. Chúng ta có thể tính toán lợi nhuận gộp của bất kỳ sản phẩm, cửa hàng, hoặc ngày bằng cách tổng hợp các khoản doanh thu và chi phí riêng biệt tương ứng trước khi thực hiện phép chia. Đơn giá cũng là một Non-Additive Facts. Không giống như các dữ liệu sự kiện khác như doanh thu, tổng hợp đơn giá trên bất kỳ chiều nào đều cho kết quả vô nghĩa. Hãy xem xét một ví dụ đơn giản: 01 sản phẩm X có đơn giá $1 và 04 sản phẩm Y có đơn giá 50 cent. Bạn có thể tính tổng số lượng sản phẩm bán là 05 sản phẩm và bạn cũng tính tổng được doanh thu là 1 + 0,5x4= $3. Tuy nhiên nếu lấy tổng của các đơn giá $1 và $0,5 là $1,5 thì đây lại là một số vô nghĩa hoặc đơn giá trung bình là $ 0,75 cũng là số vô nghĩa. Đơn giá trung bình phải được tính bằng cách lấy tổng doanh thu chia cho số lượng 5 sản phẩm bán được, trường hợp này sẽ cho đơn giá trung bình là $0,6. Một câu hỏi đặt ra là liệu rằng có nên lưu trữ các dữ liệu Non-Additive Facts? Đây là một câu hỏi chính đáng vì các giá trị này không có 79

ý nghĩa khi phân tích hay tổng hợp dữ liệu, các giá trị này cũng không thể được in toàn bộ lên các báo cáo. Tuy nhiên, trong một số tình huống khác các Non-Additive Facts đôi khi lại có ý nghĩa phân tích khi lấy giá trị trung bình, ví dụ như dữ liệu nhiệt độ của hệ thống máy móc. 4.3.2. Xây dựng bảng chiều (Dimension table) Bảng chiều cung cấp các thông tin, ngữ cảnh cho bảng sự kiện, hay nói cách khác nó cung cấp thông tin cho tất cả số liệu thể hiện trong Data Warehouse. Dù có quy mô nhỏ hơn bảng sự kiện rất nhiều lần, các bảng chiều lại là trái tim và khối óc của Data Warehouse vì mọi hoạt động truy cập số liệu Data Warehouse đều phải thông qua chúng. 4.3.2.1. Chiều thời gian (Date Dimension) Chiều thời gian một chiều đặc biệt vì nó luôn tồn tại trong mô hình dữ liệu đa chiều vì hầu như tất cả quá trình kinh doanh đều đo hiệu quả hoạt động theo thời gian. Chiều thời gian còn được gọi là “Time Dimension”, tuy nhiên trong một số các thiết kế chiều thời gian cũng có thể được gọi là “Date Dimenssion” để thể hiện độ mịn nhỏ nhất theo thời gian là ngày (date). Không giống như hầu hết các chiều khác, chúng ta có thể xây dựng bảng chiều thời gian trước. Bảng chiều thời gian có thể bao gồm dữ liệu của 10 hoặc 20 năm với mỗi dòng đại diện cho 1 ngày, vì vậy bảng chiều thời gian có thể bao gồm lịch sử các dữ liệu được lưu trữ và một số năm trong tương lai. Bảng chiều chứa dữ liệu thời gian trong vòng 20 năm chỉ có khoảng 7.300 dòng, đó là một bảng có kích thước tương đối nhỏ. Trong ví dụ về chuỗi cửa hàng bán lẻ, bảng chiều thời gian có thể bao gồm các thuộc tính như trên hình 4.8.

80

Hình 4.8. Bảng chiều thời gian Trong bảng chiều thời gian, chỉ một vài thuộc tính là có thể tự sinh ra từ câu lệnh SQL (như thứ, ngày, tháng, quý, năm). Các trường dữ liệu còn lại (như ngày làm việc, ngày nghỉ, năm tài chính…) sẽ khác biệt tùy vào chính sách của quốc gia và chính sách của công ty (ví dụ Việt Nam có ngày Quốc lễ giỗ tổ Hùng Vương tính là ngày nghỉ, có công ty làm 5 ngày/tuần, công ty khác 6 ngày/tuần…). Chiều thời gian là chiều thông dụng và đặc biệt nhất trong dự án Data Warehouse. Thông thường chiều thời gian được tạo một lần vào đầu dự án và gần như ít thay đổi trong suốt vòng đời xây dựng, vận hành dự án đó (trừ khi chính sách công ty thay đổi, tăng lương giảm giờ làm, trước làm 6 ngày một tuần nay giảm xuống còn 5, hoặc nhà nước thêm một ngày quốc lễ mới). 81

Khoá chính của bảng chiều chỉ chứa giá trị có ý nghĩa định danh, tự nó không có giá trị gì cả. Tuy nhiên với chiều thời gian, rất nhiều dự án Data Warehouse lại gán giá trị có nghĩa cho khoá chính, mà cụ thể là giá trị kiểu YYYYMMDD (ví dụ 20160621 cho ngày 21, tháng 06, năm 2016). Về việc có cần thiết phải gán giá trị có nghĩa cho khóa thay thế này hay không còn nhiều tranh cãi, và mỗi bên đều đưa ra các ưu, nhược điểm cho các trường hợp cụ thể. Tuy nhiên, để dễ vận hành, các nhóm thiết kế thường gán cho khóa chính giá trị có ý nghĩa. (Hình 4.9).

Hình 0.8. Các dòng trong bảng chiều thời gian (Kimball & Ross, 2013) Sử dụng thuộc tính dạng cờ (Flags) hay dạng chữ? Theo ví dụ trên hình 4.9, thuộc tính ngày nghỉ lễ “Holiday Indicator”chỉ bao gồm hai giá trị đơn giản là ngày lễ (Holiday) hoặc không (Non-Holiday). Các thuộc tính của bảng chiều sẽ trở thành các nhãn trong các báo cáo khi thực hiện các truy vấn, do đó các nhãn có ý nghĩa như Holiday/Non-Holiday sẽ dễ hiểu hơn thay vì các giá trị khó hiểu dạng Flags như Y / N, 1/0, hoặc True / False. Hãy thử tưởng tượng nhà quản lý cần so sánh doanh số bán hàng của ngày nghỉ lễ so với ngày thường, các thuộc tính dạng chữ sẽ được chuyển thành các nhãn rất dễ hiểu trong các báo cáo. Thay vì giải mã cờ (Flags) 1/0 thành các nhãn dễ hiểu trong ứng dụng BI, phương án lưu trữ giá trị giải mã trong cơ sở dữ liệu sẽ được chọn vì khi đó các dữ liệu này sẽ nhất quán và sẵn sàng cho người dùng ở bất kể môi trường báo cáo nào hoặc ở các công cụ BI khác nhau. 82

Thời gian trong ngày là dữ liệu Dimension hay Fact? Trong nhiều trường hợp, thời gian trong bảng sự kiện cần được tính toán dưới mức ngày, ở mức giờ hoặc phút. Theo cách nghĩ thông thường chúng ta nghĩ ngay đến việc tạo một bảng chiều ở mức giờ hoặc phút tương ứng này. Tuy nhiên thực tế thì nó phải được tách ra khỏi bảng chiều thời gian vì cứ một năm có 8.760 giờ, 525.600 phút, 31.536.000 giây và nếu chọn độ mịn ở mức giây thì một năm sẽ có đến 31 triệu dòng, quá lớn cho bảng chiều thời gian và có thể gây lỗi cho cả Data Warehouse. Bảng chiều thời gian là bảng được truy xuất thường xuyên nhất, do đó sẽ tốt hơn nếu giữ bảng chiều thời gian ở một mức độ vừa phải và dễ quản lý. Nếu gặp phải tình hình trên chúng ta có thể tạo các bảng chiều 24h, 60 phút, 60 giây rồi kết hợp chúng với nhau. Hoặc có thể ghi luôn giá trị thời gian (kiểu datetime của database) vào bảng sự kiện và xem nó là một giá trị đặc biệt. 4.3.2.2. Chiều sản phẩm (Product Dimension) Bảng chiều sản phẩm mô tả mỗi SKU tại các cửa hàng. Mặc dù một cửa hàng điển hình có thể tích lưu kho đến 60.000 SKU, khi thống kê cho toàn bộ hệ thống theo các chương trình bán hàng khác nhau và các sản phẩm đã bán trước đây và hiện đã hết hàng, bảng chiều sẽ có số hàng lớn hơn nhiều, trong ví dụ này giả sử số dòng của bảng chiều khoảng 300.000 dòng. Dữ liệu trong bảng chiều sản phẩm thường có nguồn gốc từ Master Data của doanh nghiệp. Bảng chiều sản phẩm thể hiện nhiều thuộc tính mô tả của mỗi SKU. Hệ thống phân cấp hàng hóa là một nhóm thuộc tính quan trọng. Thông thường, cấp cao hơn của SKU riêng rẽ là thương hiệu (brand), trên thương hiệu là danh mục sản phẩm (subcategory, category) và tiếp đó là các phòng ban (department). Cấu trúc phân cấp sẽ có mối quan hệ một-nhiều và được thể hiện trong hình 4.10. 83

Hình 0.9. Các dòng trong bảng chiều sản phẩm (Kimball & Ross, 2013) Đối với mỗi SKU, tất cả các cấp của hệ thống phân cấp hàng hóa được xác định rõ ràng. Một số thuộc tính, chẳng hạn như mô tả SKU, là duy nhất. Trong trường hợp này, có 300.000 giá trị khác nhau trong cột mô tả SKU. Tuy nhiên đối với cột bộ phận, có lẽ chỉ có khoảng 50 giá trị khác biệt của thuộc tính bộ phận. Như vậy, trung bình, có 6.000 lần lặp lại của mỗi giá trị trong các thuộc tính bộ phận. Điều này là hoàn toàn bình thường và chúng ta cũng không cần phải tách biệt các giá trị lặp đi lặp lại trong cột bộ phận vào một bảng chuẩn hóa thứ hai để tiết kiệm không gian vì so với bảng sự kiện, bảng chiều sản phẩm sẽ chiếm không gian không quá nhiều. Nhiều thuộc tính trong bảng chiều sản phẩm không phải là một phần của hệ thống phân cấp hàng hóa, ví dụ như thuộc tính hình thức đóng gói dạng chai, túi, hộp, hoặc lon. Bất kỳ SKU nào đều có thể có một trong những giá trị này. Việc kết hợp các thuộc tính này với các thuộc tính trong hệ thống phân cấp hàng hóa đôi khi mang lại những ý nghĩa nhất định. Ví dụ, chúng ta muốn xem tất cả các SKU trong nhóm sản phẩm ngũ cốc đóng gói trong túi. Nói cách khác, chúng ta có thể truy vấn thông tin từ các cột cho dù cột đó có thuộc hệ thống phân cấp hàng hóa hay không. Thông thường bảng sản phẩm sẽ có nhiều hơn một hệ thống phân cấp. Bảng chiều sản phẩm cho trường hợp chuỗi cửa hàng bán lẻ được đề xuất như hình 4.11. 84

Hình 4.11. Bảng chiều sản phẩm Đào sâu các thuộc tính chiều (Drilling Down on Dimension Attributes) Sẽ không là quá nhiều nếu bảng chiều sản phẩm có đến hơn 50 thuộc tính mô tả. Mỗi thuộc tính đều có thể sẽ trở thành nguồn dữ liệu phong phú trong các báo cáo phân tích. Lấy ví dụ chúng ta muốn tạo môt báo cáo tính tổng doanh thu theo phòng ban. Theo như mô tả ở hình 4.12, nếu chúng ta muốn phân tích sâu hơn doanh thu theo các thuộc tính thương hiệu hoặc theo phân loại chất béo (Fat content) trong chiều sản phẩm, chúng ta có thể thực hiện drill down theo các thuộc tính này.

Hình 0.10. Thực hiện Drill down theo các thuộc tính của bảng chiều (Kimball & Ross, 2013) 85

4.3.2.3. Chiều cửa hàng (Store Dimension) Chiều cửa hàng mô tả đặc trưng của mỗi cửa hàng trong chuỗi cửa hàng. Không giống như dữ liệu về sản phẩm luôn có sẵn trong hệ thống dữ liệu của doanh nghiệp, dữ liệu cửa hàng thường không có sẵn. Hệ thống POS chỉ có thể cung cấp mã cửa hàng (store number) trong các giao dịch, do đó nhóm phát triển cần phải xây dựng bảng chiều cửa hàng dựa trên dữ liệu từ nhiều nguồn khác nhau. Thông thường có một phòng kinh doanh ở trụ sở sẽ cung cấp đầy đủ thông tin dữ liệu về các cửa hàng. Chiều cửa hàng cũng có thể được xem là chiều vị trí địa lý. Mỗi cửa hàng sẽ ở một vị trí nhất định và chúng ta có thể cuộn lên (roll up) dữ liệu theo các thuộc tính địa lý như quận huyện, mã bưu chính, thành phố, tỉnh…Đôi khi các thuộc tính địa lý lại được kết hợp với nhau, ví dụ như ở Mỹ, nhiều tiểu bang có tên thành phố trùng nhau, do đó thông thường nhà thiết kế sẽ thêm một thuộc tính City-State vào bảng chiều cửa hàng. Bên cạnh các thuộc tính về trị trí địa lý, bảng chiều cửa hàng cũng chứa các thông tin mô tả khác về cửa hàng như kiểu thiết kế sàn (floor plan type), photo processing type, finance services… Thiết kế bảng chiều cửa hàng được đề xuất như hình 4.13.

Hình 0.11. Bảng chiều cửa hàng 86

4.3.2.4. Chiều xúc tiến thương mại (Promotion Dimension) Chiều xúc tiến thương mại là chiều có nội dung thú vị nhất trong mô hình đa chiều ngành bán lẻ. Chiều xúc tiến thương mại mô tả các hình thức xúc tiến thương mại khi bán hàng. Chiều xúc tiến thương mại bao gồm chương trình giảm giá ngắn hạn, các hình ảnh quảng cáo ở lối đi trong cửa hàng, quảng cáo trên báo, mã giảm giá… Chiều xúc tiến thương mại còn gọi là chiều nhân quả (causal dimension) vì nó chứa các yếu tố ảnh hưởng đến sự thay đổi doanh số bán hàng. Các nhà phân tích kinh doanh rất quan tâm trong việc xác định xem liệu một chương trình khuyến mãi có hiệu quả hay không. Chương trình khuyến mãi được đánh giá dựa trên một hoặc nhiều các yếu tố sau: - Liệu doanh số bán hàng của một số mặt hàng có tăng đáng kể trong thời gian khuyến mãi hay không? Sự gia tăng này được tính toán dựa trên việc so sánh số liệu bán hàng trong thời gian khuyến mãi và số liệu trung bình trong những khoảng thời gian không khuyến mãi. - Liệu rằng có sự sụt giảm doanh số bán hàng ngay trước khi khuyến mãi hoặc sau thời gian khuyến mãi hay không? Vì nếu xảy ra điều này thì doanh số bán hàng thật sự không tăng mà chỉ là sự dịch chuyển thời gian bán hàng, và bạn đã phải tốn nhiều chi phí khuyến mãi mà kết quả không đem lại lợi ích tương xứng. - Liệu rằng có sự tăng doanh số bán hàng các sản phẩm thực hiện khuyến mãi nhưng sản phẩm khác gần đó trên kệ lại bị sụt giảm doanh số bán hàng tương ứng hay không? - Liệu rằng tất cả các sản phẩm trong danh mục khuyến mãi đều có doanh thu tăng trong khoảng thời gian trước, trong và sau khi khuyến mãi hay không (sản phẩm đang ở giai đoạn tăng trưởng)? 87

Ngoài hệ thống POS, các thông tin khuyến mãi còn được lấy từ nhiều nguồn dữ liệu khác nhau. Hệ thống quản lý giao dịch sẽ lưu trữ thông tin về giảm giá. Các mã giảm giá sẽ ghi nhận theo từng giao dịch vì khách hàng sẽ quyết định có sử dụng phiếu giảm giá hay không khi mua hàng. Dữ liệu về quảng cáo và các hình ảnh trưng bày tại cửa hàng sẽ phải liên kết với các nguồn khác.

Hình 0.12. Chiều khuyến mãi Các dữ liệu khuyến mãi đôi khi có liên quan chặt chẽ với nhau. Một chương trình giảm giá tạm thời thường đi đôi với những quảng cáo và các hình ảnh hiển thị thông tin giảm giá ở cuối lối đi trong cửa hàng. Vì lý do này nên trong bảng chiều xúc tiến thương mại, mỗi dòng sẽ là một sự kết hợp cửa nhiều hình thức khuyến mãi, quảng cáo khác nhau. Ví dụ như trong một năm, doanh nghiệp sẽ thực hiện 1000 quảng cáo, 5000 đợt giảm giá, 1000 hình ảnh trưng bày cuối lối đi trong cửa hàng nhưng sự kết hợp của ba hình thức này cũng chỉ tạo ra khoảng 10.000 dòng trong bảng chiều khuyến mãi. Trường hợp trong một đợt khuyến mãi, hầu hết cửa hàng sẽ chọn cả ba hình thức xúc tiến bán hàng đồng thời, nhưng chỉ có một vài cửa hàng chỉ 88

chọn hai hình thức, khi đó chương trình khuyến mãi này sẽ được thể hiện thành hai dòng trong bảng chiều xúc tiến thương mại, một cho sự kết hợp cả ba hình thức xúc tiến bán hàng và một đại diện cho sự kết hợp cả hai hình thức. Bảng chiều khuyến mãi đề xuất như trên hình 4.14. Đứng trên một quan điểm khác, chúng ta có thể lưu thông tin về các chương trình khuyến mãi theo cách tách bốn hình thức xúc tiến thương mại (giảm giá, quảng cáo, hiển thị ở cửa hàng, và phiếu giảm giá) vào các chiều riêng biệt hơn là kết hợp chúng thành một chiều xúc tiến thương mại. Sự lựa chọn tách hay gộp là tùy thuộc vào quan điểm của người thiết kế. Tuy nhiên việc kết hợp hay không bốn hình thức xúc tiến thương mại thành một bảng chiều đều có những ưu và khuyến điểm như sau: Ưu điểm của việc kết hợp: - Các hình thức xúc tiến thương mại thường có mối tương quan cao, do đó khi kết hợp các hình thức này trong một chiều sẽ không làm kích thước lên quá nhiều so với khi tách chúng ra thành các chiều riêng biệt. - Việc kết hợp sẽ cho thấy các chiều giảm giá, quảng cáo, hiển thị ở cửa hàng và phiếu giảm giá được sử dụng cùng nhau như thế nào. Tuy nhiên, bảng chiều lại không thể hiện được các cửa hàng hoặc các sản phẩm nào bị ảnh hưởng bởi các chương trình khuyến mãi; thông tin này sẽ được tìm thấy trong bảng sự kiện. Ưu điểm của việc tách riêng: - Việc tách riêng các hình thức xúc tiến thương mại thành các chiều khác nhau sẽ dễ hiểu hơn đối với doanh nghiệp vì các nhà quản lý, kinh doanh thường hay nói về các hình thức này một cách riêng biệt trong các cuộc phỏng vấn thu thập yêu cầu nghiệp vụ. 89

- Quản lý các hình thức xúc tiến thương mại ở các chiều khác nhau sẽ dễ hơn so với khi kết hợp chúng lại thành một chiều. Vấn đề Null Foreign Keys Thông thường, các giao dịch bán hàng có thể bao gồm các sản phẩm mà không có khuyến mãi vì không phải lúc nào người mua cũng mua sản phẩm khuyến mãi. Do đó bảng chiều xúc tiến thương mại phải có một hàng với giá trị là 0 hoặc -1 để thể hiện trạng thái không có khuyến mãi, để tránh vấn đề null Foreign Keys trong bảng sự kiện. Ràng buộc toàn vẹn sẽ bị vi phạm nếu trong bảng sự kiện có giá trị null trong cột được khai báo Foreign Keys liên kết với bảng chiều. Ngoài vấn đề ràng buộc toàn vẹn, Null Foreign keys còn là nguồn gốc cho sự rối rắm của người sử dụng vì không thể thực hiện phép kết hợp đối với giá trị null. Đôi khi chúng ta gặp phải giá trị null trong bảng chiều. Đây thường là kết quả khi một dòng của bảng chiều không có đầy đủ thông tin. Trong trường hợp này, chúng ta nên thay thế giá trị null bằng một chuỗi mô tả, chẳng hạn như “Unknown” hoặc “Not Applicable”, những chuỗi này có thể ẩn đi trong các báo cáo thông qua một số xử lý. Việc hạn chế giá trị null trong thiết kế sẽ giúp tránh những lỗi trong một số truy vấn cũng như làm chậm tốc độ truy vấn với giá trị null. 4.3.2.5. Các chiều khác trong mô hình chuỗi bán lẻ Bất kỳ thuộc tính mô tả về các giá trị trong bảng sự kiện đều có thể trở thành thông tin tham khảo để thêm một chiều vào thiết kế. Quyết định có thêm một bảng chiều vào thiết kế hay không phụ thuộc vào việc xác định độ mịn của bảng sự kiện. Ví dụ, có thể là thêm một nhân viên bán hàng được ghi nhận tương ứng với mỗi giao dịch. Chiều nhân viên bán hàng cũng có thể bao 90

gồm một số thuộc tính riêng liên quan đến một số đặc điểm chung của các nhân viên. Giống như chiều xúc tiến thương mại, chiều nhân viên bán hàng cũng có thể xảy ra trường hợp một giao dịch không có nhân viên bán hàng khi khách hàng mua hàng ở các quầy tự phục vụ. Đối với chiều phương thức thanh toán, vấn đề có lẽ sẽ phức tạp hơn. Nếu các cửa hàng có quy tắc cứng nhắc là chỉ cho phép khách hàng sử dụng một phương thức thanh toán cho mỗi giao dịch thì điều này sẽ làm cho thiết kế trở nên đơn giản, chúng ta chỉ cần thêm một bảng chiều phương thức thanh toán với một số phương thức thanh toán phổ biến như tiền mặt, thẻ tín dụng…Tuy nhiên trong thực tế, chiều phương thức thanh toán sẽ phức tạp hơn trong trường hợp khách hàng muốn thanh toán một giao dịch bằng nhiều phương thức thanh toán khác nhau, như vậy một giao dịch tương ứng với một dòng trong bảng sự kiện sẽ phải liên quan đến hơn hai phương thức thanh toán. Khi đó chúng ta phải có nhiều bảng chiều khác nhau, mỗi bảng chiều tương ứng với một phương thức thanh toán hoặc xử lý bằng cách thêm một bảng sự kiện riêng biệt cho mỗi phương thức thanh toán, khi đó mỗi dòng sẽ tương ứng với một phương thức thanh toán (như vậy các giao dịch với phương thức thanh toán khác nhau sẽ xuất hiện ở các bảng sự kiện riêng biệt). 4.3.3. Truy vấn dữ liệu trong lược đồ hình sao (Star Schemas) Với mô hình dữ liệu đa chiều trong ngành bán lẻ đã thiết kế ở trên, việc truy vấn dữ liệu sẽ được thực hiện như thế nào? Giả sử một người dùng doanh nghiệp quan tâm đến dữ liệu doanh số bán theo tuần trong tháng 1 năm 2013 cho loại sản phẩm đồ ăn nhẹ (Snacks) tại các cửa hàng tại vùng Boston. Như minh họa ở hình 4.15, ta sẽ thực hiện truy vấn với ràng buộc tháng và năm trong chiều thời gian, vùng cho chiều cửa hàng và loại sản phẩm cho chiều sản phẩm. 91

Hình 0.13. Truy vấn trong lược đồ hình sao (Kimball & Ross, 2013) 4.3.4. Factless Fact tables Có một câu hỏi quan trọng không thể được trả lời bằng lược đồ đã xây dựng ở trên là đối với các sản phẩm thuộc chương trình xúc tiến thương mại nhưng không bán được thì thế nào? Bảng sự kiện bán hàng chỉ ghi nhận những sản phẩm đã được bán. Một bảng sự kiện thể hiện sự ghi nhận dữ liệu của các chương trình xúc tiến thương mại (Promotion Coverage Facts) là cần thiết trong trường hợp này. Các khóa trong bảng Promotion Coverage Facts (hình 4.16) bao gồm ngày, sản phẩm, cửa hàng, loại khuyến mãi. Bảng sự kiện xúc tiến thương mại trông có vẻ giống bảng Sales Fact tuy nhiên độ mịn thì lại hoàn toàn khác. Một dòng trong bảng sự kiện xúc tiến thương mại sẽ tương ứng với mỗi sản phẩm được khuyến mãi ở mỗi cửa hàng trong mỗi ngày (hoặc tuần nếu thực hiện khuyến mãi cả tuần) bất kể các sản phẩm đó có được bán hay không. Với bảng sự kiện này, cho phép truy xuất các thông tin liên quan đến chương trình khuyến mãi độc lập với các sự kiện khác như việc sản phẩm khuyến mãi có được bán hay không. Bảng sự kiện này được gọi là Factless Fact table vì nó không chứa các số liệu có thể đo lường được mà 92

chỉ thể hiện các mối liên hệ giữa thông tin liên quan đến chương trình khuyến mãi như minh họa ở hình 4.16. Phép toán dùng chủ yếu trên bảng sự kiện này là phép đếm (count). Để dễ dàng trong tính toán, thiết kế sẽ có thể bao gồm một cột mang ý nghĩa thống kê, chẳng hạn như cột “promotion count” trong ví dụ này luôn luôn có giá trị là 1. Mục đích của việc thêm cột “promotion count” là để tránh việc đếm trên khóa foreign keys. Việc xác định các sản phẩm có khuyến mãi nhưng không bán được sẽ được thực hiện qua hai bước. Đầu tiên thực hiện truy vấn toàn bộ sản phẩm khuyến mãi từ bảng Promotion factless fact table ở một ngày nhất định. Sau đó xác định các sản phẩm bán được trong ngày đó từ dữ liệu bảng Sales Fact. Các sản phẩm khuyến mãi nhưng không bán được sẽ chính là các sản phẩm khác nhau giữa hai kết quả truy vấn này.

Hình 0.14. Bảng Promotion Coverage Facts (Kimball & Ross, 2013) 4.3.5. Các khóa trong bảng sự kiện và bảng chiều 4.3.5.1. Các khóa trong bảng chiều Về cơ bản các bảng chiều đều có cấu trúc vật lý như hình 4.17. Khóa chính của bảng chiều là trường dữ liệu (thường là 93

kiểu số) lưu những giá trị duy nhất, không có ý nghĩa, gọi là khóa thay thế (surrogate key). Khóa thay thế này được sinh ra trong hệ thống Data Warehouse thông qua quá trình ETL xử lý dữ liệu. Giá trị khóa này chỉ được tạo ra duy nhất trong nội tại Data Warehouse, các thao tác thay đổi bên ngoài đều bị cấm.

Hình 0.15. Cấu trúc bảng chiều (Kimball, 2004) Trước đây việc tạo ra giá trị khóa thay thế thường được phó mặc cho database dùng làm Data Warehouse, cụ thể là cho tính năng database trigger. Tuy nhiên càng ngày người ta càng nhận ra rằng việc dùng data trigger làm chậm cả tiến trình ETL nên đã hạn chế dùng nó. Việc dùng database tạo khoá chính cũng không được khuyến khích nữa vì khi đó Data Warehouse phải phụ thuộc một tiến trình khác từ bên ngoài, dễ gây mất đồng bộ (trong trường hợp database dùng làm Data Warehouse trong giai đoạn xây dựng hệ thống và giai đoạn triển khai khác nhau). Do đó hướng tiếp cận an toàn nhất vẫn là dùng chính luồng ETL để tạo ra giá trị cho khóa thay thế này. Một thành phần khác của bảng chiều là khóa chính của dữ liệu trong hệ thống nghiệp vụ, được gọi là khóa tự nhiên 94

(natural key), giá trị của khóa tự nhiên thường không phải vô nghĩa. Ví dụ như trong bảng Dimension Nhân viên sẽ có trường EMP_ID lưu mã nhân viên lấy từ hệ thống nghiệp vụ. Mặc dù trường EMP_ID cũng có thể dùng làm khóa chính cho bảng Dimension Nhân viên này nhưng khi thiết kế vẫn phải cung cấp cho bảng này một khóa thay thế (trong trường hợp phải nhập dữ liệu từ hai hệ thống khác nhau dẫn đến khóa tự nhiên có thể trùng nhau, hoặc trường hợp giá trị chiều bị thay đổi). Có ý kiến cho rằng các chiều đã có khóa tự nhiên có thể dùng làm khóa chính rồi, không nhất thiết phải dùng khóa thay thế kiểu số vô nghĩa nữa mà có thể dùng một giá trị có nghĩa nào đó như thời gian thay đổi, khi đó tập thuộc tính {khóa tự nhiên, thời gian thay đổi} chính là khóa chính của bảng chiều. Hướng tiếp cận này có thể có lợi trong một vài trường hợp nhưng lại bế tắc trong các tình huống sau: - Sai định nghĩa: Khóa thay thế, theo định nghĩa, tự bản thân nó không có ý nghĩa gì cả. Nếu như cố tình gán ý nghĩa cho khóa thay thế thì người thiết kế ETL phải thêm luồng xử lý để quản lý ý nghĩa các giá trị này, khiến cho việc xây dựng luồng ETL phức tạp hơn do đó cũng chạy lâu hơn. - Giảm hiệu năng: Thêm ý nghĩa cho khóa thay thế khiến các câu truy vấn từ người dùng cuối phải thêm điều kiện xác thực, khiến câu lệnh phức tạp hơn, truy vấn tốn tài nguyên và thời gian hơn so với phép so sánh hai giá trị kiểu số đơn thuần. Thành phần cuối cùng của bảng chiều, bên cạnh khóa chính và khóa tự nhiên, là một loạt các thuộc tính mô tả (desciptive attribute). Các thuộc tính mô tả có thể ở nhiều kiểu dữ liệu khác nhau và số lượng có thể rất lớn (đặc biệt với các chiều như khách hàng, nhân viên, sản phẩm…). Nhìn chung việc thiết kế ra 95

bảng chiều có hơn 100 thuộc tính mô tả cũng không có gì quá bất thường. Chỉ cần lưu ý làm sạch dữ liệu cẩn thận cho các thuộc tính này là được. Một lưu ý nhỏ là nên chú ý đến các thuộc tính mô tả có kiểu dữ liệu là kiểu số, vì tùy vào ý nghĩa, nó có thể lại là một thuộc tính đo đếm được và phải đặt vào bảng sự kiện. Thông tin mô tả chỉ được dùng để mô tả chứ không phải dùng để cộng dồn. Cũng không nên quá lo lắng vì trong 99% trường hợp giá trị này sẽ được phân ra là fact hay thuộc tính dimension ngay. 1% còn lại phân vào đâu cũng được và việc phân thuộc tính của chúng vào đâu không làm thay đổi ý nghĩa của thuộc tính, mà chỉ làm thay đổi cách xử lý thuộc tính đó 4.3.5.2. Khóa thay thế trong bảng sự kiện Mặc dù việc sử dụng khóa thay thế (Surrogate Keys) cho bảng chiều là yêu cầu bắt buộc, nhưng việc sử dụng Surrogate Keys cho bảng sự kiện ít quan trọng hơn. Khóa thay thế cho bảng sự kiện chỉ có ý nghĩa trong quá trình ETL. Có thể xem khóa chính trong bảng sự kiện chính là một tập hợp các khóa ngoại (foreign keys). Tuy nhiên, một khóa thay thế (surrogate keys) cho bảng sự kiện đôi khi cũng mang lại một số lợi ích nhất định. Tương tự như khóa thay thế trong bảng chiều, khóa thay thế trong bảng sự kiện chỉ nên theo dạng số nguyên đơn giản được gán theo thứ tự các dòng được tạo ra trong bảng sự kiện này. Mặc dù khóa thay thế trong bảng sự kiện không làm tăng hiệu suất truy vấn, nhưng nó cũng mang lại một số lợi ích như sau: - Nhận dạng duy nhất: Một hàng trong bảng sự kiện được truy xuất tức thì dựa vào khóa thay thế. Trong quá trình xử ETL, một hàng cụ thể được xác định mà không cần quan tâm đến các chiều dữ liệu. 96

- Ngừng và bắt đầu lại quá trình nạp dữ liệu: Khi một số lượng lớn hàng đang được nạp dữ liệu và được gán tuần tự khóa thay thế mà quá trình ngừng vì một lý do nào đó trước khi hoàn thành, DBA (Database Administrator) có thể xác định chính xác vị trí mà quá trình này dừng lại bằng cách tìm giá trị tối đa của khóa thay thế trong bảng. Từ đó, DBA có thể hoàn chỉnh quá trình nạp bằng cách xác định các dữ liệu đã được nạp và thực hiện tiếp tục quá trình nạp dữ liệu từ chính xác vị trí bị dừng. - Thay thế thao tác update dữ liệu bằng cách kết hợp delete và insert: Khóa thay thế trong bảng sự kiện sẽ trở thành khóa chính trong thiết kế vật lý do đó hoàn toàn có thể thay thế thao tác update một mẫu tin bằng thao tác delete và insert dữ liệu mới. Bước đầu tiên là thêm các dòng mới vào cơ sở dữ liệu với tất cả các foreign keys tương tự như hàng cần update. Sau đó thực hiện xóa dòng gốc sau khi đã hoàn thành việc cập nhật các thông tin vào các dòng mới thêm. Trong trường hợp cần cập nhật một tập hợp lớn mẫu tin, trình tự thực hiện này sẽ hiệu quả hơn so với việc sử dụng thao tác update cho từng mẫu tin. Nếu quá trình bị ngưng thì hoàn toàn có thể khôi phục được nhờ vào khóa thay thế như đã mô tả ở trên. - Sử dụng khóa thay thế trong liên kết giữa hai bảng sự kiện: Trong trường hợp thiết kế gồm nhiều bảng sự kiện có liên kết một - nhiều với nhau, thì bảng sự kiện ở phía một sẽ cần một khóa thay thế thay cho khóa tự nhiên (natural key). Lý luận tại sao cần phải thêm khóa thay thế tương tự như trường hợp sử dụng khóa thay thế cho bảng chiều. - Khóa tự nhiên rất hỗn độn và không thể đoán trước, trong khi khóa thay thế là các số nguyên rõ ràng và được gán trong quá trình ETL. 97

4.3.6. Lược đồ hình bông tuyết (Snowflake Schemas) Trong thiết kế phẳng theo lược đồ hình sao, bảng chiều là các bảng dữ liệu được phi chuẩn hóa. Tất cả dữ liệu phân cấp và các cấu trúc được chuẩn hóa của hệ thống nghiệp vụ được thiết kế lại về dạng phẳng. Dữ liệu trong bảng chiều, vì thế, là dư thừa và tương đương với dạng chuẩn 2 trong thiết kế database nghiệp vụ. Một bảng chiều có thể bao hàm nhiều hơn một cấu trúc phân cấp. Ví dụ chiều Cửa hàng có thể có cấu trúc cây theo phân cấp địa lý theo quản lý hành chính, vừa có cấu trúc cây theo phân cấp của nội bộ doanh nghiệp. Cả hai cây phân cấp này đều có thể nằm trong một cây phân cấp, với điều kiện ràng buộc duy nhất là dù ở cây phân cấp nào, giá trị của thuộc tính phân cấp luôn là duy nhất. Nếu một bảng chiều ở dạng chuẩn hóa,cấu trúc phân lớp sẽ được thể hiện dưới dạng lược đồ hình bông tuyết (hình 4.18). Chú ý rằng về mặt nội dung dữ liệu thì hai cách thể hiện này không khác gì nhau, tuy nhiên mỗi cách thể hiện lại có điểm lợi, điểm hại khi người dùng thao tác. Trường hợp bảng phẳng không chuẩn hóa sẽ gây ra tình trạng dư thừa dữ liệu, dễ gây ra sai sót mất đồng bộ giữa các bản ghi (lớp cha giống nhau nhưng thông tin của lớp cha lại khác nhau). Trường hợp của bảng chuẩn hóa lại gây giảm hiệu năng khi truy vấn dữ liệu (do phải liên kết nhiều bảng với nhau) và gây khó hiểu cho người dùng không am hiểu.

Hình 0.16. Lược đồ bông tuyết cho chiều Product (Kimball & Ross, 2013) 98

Mỗi khi thêm record mới vào bảng chiều, hệ thống phải gán cho record đó một khóa thay thế, đóng vai trò làm khóa chính cho bảng chiều. Trong môi trường Data Warehouse, cần thiết phải có tiến trình ETL quản lý giá trị khóa thay thế này cho mỗi bảng chiều (đơn giản nhất là tìm giá trị khóa cao nhất có sẵn trong bảng, cộng thêm 1 rồi gán cho khóa mới, tuy nhiên cách này bị hạn chế về hiệu năng). 4.4. Xây dựng nhà kho dữ liệu theo kiến trúc Bus Theo cách tiếp cận Bottom-Up do Ralph Kimball đề xuất, việc hình thành DW là một quá trình hình thành dần theo thời gian bằng cách tích hợp các mô hình dữ liệu đa chiều trong từng quy trình nghiệp vụ cụ thể trong doanh nghiệp với nhau và việc tích hợp này được thực hiện thông qua kiến trúc Bus. 4.4.1.1. Khái niệm cấu trúc Bus Thuật ngữ Bus có nguồn gốc từ ngành công nghiệp điện năng, sau đó nó trở thành thuật ngữ phổ biến trong ngành công nghiệp máy tính. Bus trong một máy tính là tiêu chuẩn giao tiếp kỹ thuật cho phép kết nối vào một ổ đĩa cứng, DVD, hoặc bất kỳ thẻ hoặc thiết bị khác. Bởi vì Bus là một tiêu chuẩn của máy tính, do đó các thiết bị ngoại vi có thể kết nối và làm việc cùng nhau, mặc dù chúng được sản xuất vào những thời điểm khác nhau và thuộc các nhà cung cấp khác nhau. Trong thiết kế DW cho doanh nghiệp, bạn có thể tưởng tượng mỗi doanh nghiệp sẽ có rất nhiều quy trình nghiệp vụ khác nhau và các quy trình này có thể gắn kết với nhà kho dữ liệu thông qua kiến trúc Bus. Như mô tả ở hình 4.19, các quy trình nghiệp vụ của doanh nghiệp có thể tích hợp dùng chung các chiều thời gian, sản phẩm, cửa hàng… trong một kiến trúc Bus. 99

Hình 0.17. Enterprise Data Warehouse Bus (Kimball & Ross, 2013) Các kiến trúc Bus cho kho dữ liệu doanh nghiệp cung cấp một cách tiếp cận hợp lý để phân tách nhiệm vụ xây dựng DW/BI cho doanh nghiệp. Hệ thống các bảng chiều và bảng sự kiện nên được chuẩn hóa và được hiểu một cách nhất quán trong toàn doanh nghiệp. Điều này sẽ giúp thiết lập khung kiến trúc dữ liệu. Sau đó có thể triển khai các mô hình đa chiều cho các quy trình nghiệp vụ riêng biệt miễn sao các mô hình này tuân thủ chặt chẽ khung kiến trúc chung. Khi mô hình đa chiều riêng biệt đã hoàn chỉnh, chúng có thể tích hợp với nhau dễ dàng. Kiến trúc Bus cho phép các nhà quản lý DW/BI đạt được cả hai mục tiêu: có một khung kiến trúc thiết kế tổng thể chung nhưng quá trình xây dựng DW đã được chia thành nhiều phần theo từng quy trình nghiệp vụ và có thể thực hiện dần theo thời gian trong thực tế. Các đội nhóm thiết kế khác nhau và có thể làm việc một cách độc lập miễn sao tuân thủ theo khung kiến trúc chung. 4.4.1.2. Ma trận Bus (Bus Matrix) Sau khi các quy trình nghiệp vụ riêng biệt được liệt kê, đôi khi bạn sẽ nhận ra các quy trình nghiệp vụ hợp nhất sẽ phức tạp 100

hơn. Mô hình đa chiều có nhiều ưu điểm về hiệu suất truy vấn và dễ sử dụng, tuy nhiên nó lại gây ra khó khăn trong quá trình triển khai vì quá trình ETL sẽ lớn dần với sự gia tăng các nguồn dữ liệu. Do đó, sẽ hợp lý hơn nếu bạn giải quyết cho từng quy trình nghiệp vụ đơn lẻ trước khi xử lý cho các quy trình nghiệp vụ hợp nhất phức tạp hơn. Lợi nhuận là một ví dụ điển hình của một quy trình nghiệp vụ hợp nhất, trong đó yếu tố doanh thu và chi phí riêng biệt được kết hợp từ các quy trình nghiệp vụ khác nhau để cung cấp một cái nhìn đầy đủ về lợi nhuận. Mặc dù mô hình đa chiều theo lợi nhuận rất thú vị, tuy nhiên bạn không nên xây dựng nó đầu tiên vì độ phức tạp của nó.

Hình 0.18. Ma trận Bus cho Retail Data Warehouse (Kimball & Ross, 2013) Các cột trong ma trận Bus đại diện cho các chiều phổ biến được sử dụng trong doanh nghiệp. Thông thường ta nên lập một danh sách các chiều quan trọng của tổ chức trước, sau đó thực hiện việc điền thêm ma trận từng chiều để đánh giá liệu một chiều mới thêm sẽ có thể liên kết với các quy trình nghiệp vụ 101

trong ma trận Bus hay không. Số hàng ma trận Bus và số cột sẽ khác nhau tùy thuộc vào tổ chức. Sau khi các quy trình cốt lõi và các chiều được xác định, bạn sẽ đánh dấu “X” vào các ô trong ma trận để thể hiện sự liên quan giữa các cột và các hàng. Quan sát theo từng hàng hoặc từng cột, bạn sẽ nhanh chóng nhận ra các mối quan hệ hợp lý và tác động lẫn nhau giữa các chiều và các quy trình nghiệp vụ quan trọng trong tổ chức. 4.5. Thiết kế nhà kho dữ liệu với CSDL AdventureWorks 4.5.1. Giới thiệu CSDL mẫu Adventure Works Cơ sở dữ liệu minh họa Adventure Works lấy bối cảnh trên dữ liệu của một công ty giả định có tên là Adventure Works Cycles. Đây là một công ty sản xuất đa quốc gia có quy mô lớn. Công ty sản xuất và kinh doanh xe đạp làm từ kim loại và các chất liệu tổng hợp. Thị trường của công ty này bao gồm cả khu vực Bắc Mỹ, Châu Âu và Châu Á. Trong khi trụ sở chính của công ty này lại được đặt ở Boyhell, Washinton gồm 290 nhân viên, công ty cũng có một vài nhóm nhân viên kinh doanh khu vực ở các thị trường hoạt động của mình. Vào năm 2000, công ty Adventure Works Cycles có mua lại một nhà máy sản xuất nhỏ là Importadores Neptuno ở Mexico. Nhà máy này tham gia sản xuất một vài thành phần thiết yếu trong toàn bộ dây chuyền sản xuất ra thành phẩm của công ty. Các thành phần được nhà máy sản xuất sẽ được chuyển tới trụ sở chính ở Bothell để lắp ráp thành thành phẩm. Năm 2011, Importadores Neptuno trở thành nhà máy duy nhất sản xuất và phân phối dòng sản phẩm xe đạp du lịch. Kết thúc một năm tài chính thành công, công ty Adventure Works Cycles đang tìm cách mở rộng thị phần bằng cách tập trung vào các hoạt động bán hàng cho các khách hàng quan trọng nhất của họ, mở rộng thông tin sản phẩm thông qua hệ thống website đồng thời giảm chi phí bán hàng bằng cách cắt giảm chi phí sản xuất. 102

Các schemas được sử dụng trong cơ sở dữ liệu Adventure Works: Bảng 0.2. Mô tả các schemas trong CSDL mẫu Adventure works Schema

Chứa các đối tượng liên quan tới

Số bảng

HumanResources

Nhân viên của công ty Adventure Works Cycles

6

Person

Tên và địa chỉ của khách hàng là các cá nhân, các nhà cung cấp và các nhân viên

13

Production

Các sản phẩm được sản xuất và bán bởi công ty Adventure Works Cycles

25

Purchasing

Các nhà cung cấp phụ tùng và các sản phẩm khác mà công ty mua

Sales

Các khách hàng và dữ liệu liên quan tới việc mua bán

5 18

4.5.2. Phân tích quy trình nghiệp vụ bán hàng Công ty Adventure Works Cycles có hai quy trình nghiệp vụ bán hàng chính là bán hàng qua kênh phân phối và bán hàng trực tiếp qua Internet. Đối với kênh bán hàng qua kênh phân phối, khách hàng của công ty là các đại lý (Reseller), quy trình bán hàng sẽ trải qua bốn bước:  Xử lý đơn đặt hàng: Sau khi nhận được đơn đặt hàng của đại lý, công ty sẽ kiểm tra điều kiện bán hàng (tồn kho, hạn mức tín dụng…). Nếu các điều kiện bán hàng thỏa mãn, công ty tiến hành tiếp nhận đơn hàng, ngược lại công ty thông báo từ chối cho khách hàng. 103

 Đóng gói, chuyển giao hàng hóa: Sau khi đơn hàng được chấp thuận, công ty tiến hành đóng gói và thực hiện giao hàng cho đại lý.  Lập hóa đơn, ghi nhận nợ: Dựa vào thông tin trên đơn đặt hàng và xuất kho công ty thực hiện lập hóa đơn bán hàng và gởi cho khách hàng, đồng thời ghi nhận khoản phải thu của khách hàng.  Thanh toán: Khi đến kỳ hạn, khách hàng thực hiện thanh toán đơn hàng. Công ty nhận thanh toán và ghi nhận giảm khoản phải thu tương ứng. Đối với kênh bán hàng qua kênh Internet, công ty bán hàng trực tiếp cho khách hàng thông qua website của công ty. Quy trình bán hàng sẽ trải qua hai bước:  Đặt hàng, thanh toán: khách hàng đặt hàng thanh toán trực tiếp tại website của công ty.  Giao hàng, xuất hóa đơn: công ty thực hiện giao hàng và xuất hóa đơn cho khách hàng. 4.5.3. Phân tích dữ liệu nguồn Từ việc xác định dữ liệu yêu cầu, các chiều thông tin cần thiết để hỗ trợ nhà quản trị trong việc nắm bắt được tình hình hoạt động bán hàng tương ứng với các yêu cầu đã được xác định được tóm tắt như sau: Để quan sát và nắm bắt được tình hình trong từng giai đoạn kinh doanh, cũng như so sánh việc kinh doanh giữa các khoảng thời gian, chiều thông tin cần được lấy bao gồm: thông tin về các sản phẩm, thời gian và số lượng, giá trị của các sản phẩm. Để dự báo được cơ hội kinh doanh qua việc nắm bắt hành vi mua sắm của khách hàng trong từng vùng miền, qua các đại lý trong cùng khu vực chiều thông tin cần được lấy gồm: thông tin về khách hàng, thông tin về các vùng miền, thông tin về các đại lý với các con số cụ thể. 104

Ngoài ra để xác định được các quyết định tiếp thị, khuyến mãi cũng như bán hàng cho phù hợp cần có thông tin về lý do chọn mua sản phẩm, các chương trình khuyến mãi giảm giá chiết khấu đặt biệt. Bảng 0.3. Mô tả các dữ liệu Master Data Đối tượng

Mô tả

Customer

Chứa các thông tin của khách hàng

Person

Thông tin chi tiết về khách hàng và các nhân viên công ty

StateProvice

Thông tin từng thành phố

SalesTerritory

Thông tin về các lãnh thổ, vùng miền

CountryRegion

Thông tin về các quốc gia

Product

Thông tin về sản phẩm của công ty

ProductSubCategory

Thông tin về loại sản phẩm

ProductCategory

Thông tin về nhóm loại sản phẩm

SpecialOffer

Thông tin về các chương trình khuyến mãi, giảm giá, chiết khấu đặc biệt

SalesReason

Chứa các lý do để khách hàng có thể chọn mua một sản phẩm

Bảng 0.4. Mô tả các dữ liệu Transaction Data

SalesOrderHeader

Chi tiết về từng đơn hàng của khách hàng, các giao dịch được thể hiện qua tổng số tiền mà khách hàng thanh toán cho đơn hàng, tổng số giá trị thuế mà khách hàng phải chi trả, nhân viên nào bán hàng, cách thức vận chuyển hàng hóa cho khách hàng được thể hiện theo từng vùng cụ thể.

SaleOrderDetail

Chứa dữ liệu chi tiết về quy trình bán hàng, các giao dịch được thể hiện với số lượng, giá thành, lượng tiền thanh toán của từng mặt hàng theo từng thời gian cụ thể nhất. 105

SalesPersonQuota History

Chi tiết doanh thu theo từng quý.

SalesOrderHeader SalesReason

Thông tin chi tiết ảnh hưởng của các lý do khách hàng chọn mua sản phẩm đến hoạt động mua hàng.

Qua việc phân tích các chiều cần thiết để thực hiện báo cáo, CSDL nguồn được sử dụng để xây dựng DW sẽ gồm các bảng như sau: - Các bảng thể hiện dữ liệu Master Data: là dữ liệu được sử dụng để xây dựng các bảng chiều trong Data Warehouse, trình bày ở bảng 4.3. - Các bảng thể hiện dữ liệu Transaction Data: là các dữ liệu giao dịch được sử dụng để xây dựng các bảng sự kiện trong Data Warehouse, trình bày ở bảng 4.4. Với các yêu cầu đặt ra, thông tin được lấy giúp người quản lý có thể xem cơ hội kinh doanh trong từng giai đoạn của chu kỳ kinh doanh theo từng vùng quốc gia, dễ dàng nắm bắt được xu hướng của các yếu tố quan trọng trong các chiều thông tin cần thiết để thiết kế vào mô hình DW. 4.5.4. Xây dựng mô hình Data Warehouse Qua việc khảo sát và mô tả cơ sở dữ liệu nguồn cần thiết để xây dựng DW, mô hình DW được đề xuất có dạng lược đồ bông tuyết - là dạng lược đồ mở rộng của lược đồ hình sao. Khóa của bảng sự kiện được tạo bởi các khóa của chiều. Với cấu trúc lược đồ dạng bông tuyết, một bảng chiều có thể là chiều chính hoặc chiều phụ, qua đó dữ liệu sẽ được thể hiện rõ hơn tại các cấp thông tin từ tổng quan đến chi tiết thông qua sự kết nối từ các nhánh chính đến các nhánh phụ trong lược đồ. Bốn bảng sự kiện sẽ thể hiện rõ được các con số ý nghĩa trong việc phân tích của nhà quản trị. Ý nghĩa của việc chọn mua 106

sản phẩm theo từng đơn đặt hàng thể hiện trong Fact Internet Sales Reason table, ý nghĩa cơ hội kinh doanh thông qua kênh bán hàng Internet thể hiện trong Fact Internet Sales table, thông tin về từng sản phẩm được bán tại các đại lý trong Fact Reseller table và tổng hợp thông tin bán hàng theo từng quý gồm ngày bán hàng, doanh thu trong Fact Sales Quota table. Trong các bảng chiều thể hiện các chiều thông tin mà nhà quản trị quan tâm về hoạt động bán hàng, có các loại bảng chiều như: DimCustomer, DimEmployee, DimProduct, DimProductSubCategory, DimProductCategory, DimSaleReason, DimGeography, DimSalesTerritory, DimPromotion, DimTime, DimReseller. Trong mô hình Data Warehouse đề xuất bao gồm 11 bảng chiều và 4 bảng sự kiện sẽ được mô tả trong bảng 4.5 và hình 4.21. Với các bảng chiều và sự kiện được thể hiện trên mô hình Data Warehouse, nhà quản trị có thể khai thác được các thông tin cần thiết về tình hình bán hàng của từng khu vực, từng quốc gia theo từng sản phẩm, loại sản phẩm, nhóm loại sản phẩm theo từng thời gian cụ thể cũng như sự tăng giảm doanh thu, lợi nhuận theo các chương trình khuyến mãi, giảm giá để từ đó có thể đưa ra các quyết định cho các cơ hội kinh doanh của doanh nghiệp. Bảng 0.5. Các bảng chiều và sự kiện trong mô hình Data Warehouse Đối tượng

Mô tả

DimCustomer

Thông tin chi tiết về khách hàng

DimEmployee

Thông chi chi tiết về nhân viên bán hàng

DimProduct

Thông tin về từng sản phẩm

DimProductSubCategory

Thông tin về loại sản phẩm 107

DimProductCategory

Thông tin về nhóm sản phẩm

DimSaleReason

Thông tin về các lý do mà khách hàng có thể chọn mua sản phẩm

Dim Geography

Thông tin về danh sách các thành phố của từng quốc gia

DimSaleTerritory

Thông tin về danh sách các quốc gia, khu vực, vùng lãnh thổ

DimPromotion

Thông tin các trạng thái sản phẩm sẽ được giảm giá, chiết khấu cụ thể

DimTime

Thông tin thời gian

DimReseller

Thông tin bán hàng ở các đại lý

FactReseller

Tổng hợp thông tin về từng sản phẩm được bán tại các đại lý bao gồm số lượng, đơn giá, giá trị, thuế, ... một cách chi tiết

FactInternetSales

Tổng hợp thông tin về từng sản phẩm được bán qua Internet gồm đơn giá, số lượng, giá trị,... một cách chi tiết

FactInternetSalesReason

Tổng hợp thông tin về lý do khách hàng chọn mua các sản phẩm của doanh nghiệp theo từng đơn đặt hàng

FactSalesQuota

Tổng hợp thông tin bán hàng theo từng quý gồm ngày bán hàng, doanh thu, ...

108

Hình 0.19. Mô hình Data Warehouse đề xuất cho nghiệp vụ bán hàng 109

Câu hỏi 1.

Trình bày khái niệm về mô hình dữ liệu đa chiều theo phương pháp tiếp cận Bottom-Up của Ralph Kimball.

2.

Trình bày bốn bước của quá trình thiết kế mô hình dữ liệu đa chiều.

3.

Trình bày và phân biệt giữa mô hình thiết kế dạng hình sao và bông tuyết?

4.

Trình bày về các khóa liên kết giữa bảng sự kiện và bảng chiều?

5.

Trình bày khái niệm về Bus Matrix trong thiết kế nhà kho dữ liệu?

6.

Từ mô hình nhà kho dữ liệu của cơ sở dữ liệu AdventureWorks hoàn chỉnh được xây dựng trong mục 4.5, hãy nhận dạng thiết kế này được tổng hợp từ các thiết kế dạng hình sao hay bông tuyết nào? Vẽ lại các thiết kế hình sao hoặc bông tuyết với từng bảng sự kiện và thiết lập Bus Matrix để tổng hợp các mô hình dữ liệu đa chiều (hình sao hoặc bông tuyết) vừa vẽ.

110

Chương 5 TÍCH HỢP DỮ LIỆU Chương này sẽ giới thiệu khái niệm về tích hợp dữ liệu, các phương pháp và công nghệ tích hợp dữ liệu. Trong đó tập trung trình bày chi tiết về công nghệ tích hợp dữ liệu ETL cũng như giới thiệu và hướng dẫn sử dụng công cụ SSIS để thực hiện tiến trình ETL. Phần cuối của chương là phần hướng dẫn chi tiết từng bước cách sử dụng công cụ SSIS để thực hiện trích xuất, chuyển đổi và tải dữ liệu cho Data Warehouse sử dụng cơ sở dữ liệu mẫu AdventureWorks. Trong phần trình bày về công cụ SSIS nhóm tác giả chỉ trình bày một phần nhỏ những nội dung cơ bản và quan trọng nhất về công cụ này, để hiểu biết sâu hơn đọc giả có thể tìm đọc thêm các tài liệu chuyên sâu về SSIS. 5.1. Tổng quan về tích hợp dữ liệu 5.1.1. Khái niệm Theo định nghĩa của IBM, tích hợp dữ liệu là sự phối hợp giữa kỹ thuật và quy trình kinh doanh để kết hợp dữ liệu từ các nguồn khác nhau và biến chúng trở thành các thông tin có ý nghĩa và giá trị. Một giải pháp tích hợp dữ liệu hoàn chỉnh sẽ cung cấp dữ liệu đáng tin cậy từ nhiều nguồn khác nhau.1 Theo dataintegration.info, tích hợp dữ liệu là quá trình kết hợp dữ liệu từ nhiều nguồn được lưu trữ sử dụng các công nghệ khác nhau thành một khối dữ liệu hợp nhất để cung cấp một cái nhìn thống nhất cho toàn bộ dữ liệu của doanh nghiệp.2 Như vậy, mặc dù có nhiều khái niệm khác nhau về tích hợp dữ liệu, tuy nhiên nhìn chung có thể hiểu tích hợp dữ liệu là một 1 2

http://www.ibm.com/analytics/us/en/technology/data-integration/ http://www.dataintegration.info/data-integration

111

quá trình chuyển đổi và kết hợp dữ liệu từ nhiều nguồn khác nhau để trở thành một khối dữ liệu duy nhất có giá trị và ý nghĩa. 5.1.2. Phương pháp và công nghệ tích hợp dữ liệu Tích hợp dữ liệu là một khuôn khổ (framework) các ứng dụng (applications), công cụ (tools), kỹ thuật (techniques), công nghệ (technologies) và dịch vụ quản lý (management services) nhằm cung cấp một cái nhìn thống nhất và nhất quán về dữ liệu kinh doanh của doanh nghiệp, các quy trình kinh doanh và người dùng doanh nghiệp (White, 2006).

Hình 0.1. Các thành phần của cấu trúc tích hợp dữ liệu (White, 2006) - Ứng dụng là các giải pháp được tùy chỉnh hoặc do nhà cung cấp phát triển sử dụng một hoặc nhiều công cụ tích hợp dữ liệu. - Công cụ là các giải pháp thương mại hỗ trợ một hoặc nhiều công nghệ tích hợp dữ liệu. Các công cụ này được sử dụng để xây dựng ứng dụng tích hợp dữ liệu. - Kỹ thuật là phương pháp tiếp cận độc lập để thực hiện tích hợp dữ liệu. 112

- Công nghệ sẽ thực hiện một hoặc nhiều các kỹ thuật tích hợp dữ liệu. - Dịch vụ quản lý sẽ hỗ trợ quản lý chất lượng dữ liệu, siêu dữ liệu, và các hoạt động của hệ thống tích hợp dữ liệu. 5.1.2.1. Kỹ thuật tích hợp dữ liệu

Hình 0.2. Các kỹ thuật tích hợp dữ liệu (White, 2006) Có ba kỹ thuật hay phương pháp tiếp cận chính được sử dụng cho việc tích hợp dữ liệu bao gồm: hợp nhất (consolidation), liên hiệp (federation) và lan truyền (propagation) (White, 2006). Hợp nhất dữ liệu - Data Consolidation: Trong phương pháp này dữ liệu được thu thập từ nhiều nguồn khác nhau và được tích hợp vào một nơi chứa dữ liệu duy nhất. Nơi lưu trữ dữ liệu này có thể là một nhà kho dữ liệu sử dụng để tạo các báo cáo và phân tích trong các ứng dụng kinh doanh thông minh (BI), hoặc kho lưu trữ nội dung có chứa thông tin phi cấu trúc như tài liệu, hình ảnh và các trang web. Phương pháp Data Consolidation thường có một độ chậm trễ giữa thời gian thực hiện các cập nhật trong hệ thống dữ liệu 113

nguồn và thời gian những bản cập nhật này được ghi nhận tại nơi lưu trữ hợp nhất. Tùy thuộc vào nhu cầu kinh doanh, thời gian trễ này có thể là một vài giây, vài giờ hoặc nhiều ngày. Thuật ngữ near-real-time (gần thời gian thực) thường được sử dụng để mô tả dữ liệu hợp nhất có độ trễ thấp như vài phút, hoặc có thể một vài giờ. Dữ liệu không có độ trễ được gọi là dữ liệu thời gian thực, nhưng điều này rất khó để đạt được khi sử dụng phương pháp Data Consolidation. Liên hiệp dữ liệu - Data Federation: Phương pháp này cung cấp một khung nhìn (view) ảo duy nhất từ nhiều nguồn dữ liệu khác nhau. Khi một ứng dụng kinh doanh truy vấn dữ liệu từ khung nhìn ảo, một công cụ dữ liệu sẽ thực hiện lấy dữ liệu từ các nguồn lưu trữ thích hợp, tích hợp lại để phù hợp với khung nhìn ảo và yêu cầu truy vấn, sau đó gửi kết quả truy vấn đến các ứng dụng kinh doanh. Theo định nghĩa, Data Federation luôn kéo (pull) dữ liệu từ nhiều nguồn dữ liệu khác nhau theo yêu cầu. Bất kỳ sự chuyển đổi dữ liệu cần thiết nào đều được thực hiện bằng cách lấy dữ liệu từ các tập tin nguồn. Tích hợp thông tin doanh nghiệp (Enterprise information integration - EII) là một ví dụ về công nghệ hỗ trợ phương pháp tiếp cận Data Federation. Lan truyền dữ liệu - Data Propagation: Phương pháp này thực hiện sao chép dữ liệu từ một nơi này đến nơi khác. Các ứng dụng này thường hoạt động trực tuyến và đẩy dữ liệu (push) đến vị trí cần sao chép. Việc cập nhật dữ liệu có thể được truyền (propagation) theo phương thức đồng bộ hoặc bất đồng bộ. Data Propagation có thể thực hiện cập nhật cho cả hệ thống dữ liệu nguồn hoặc dữ liệu đích. Bất kể loại phương thức đồng bộ nào được sử dụng, quá trình propagation cũng đảm bảo hoàn tất việc cung cấp các dữ liệu đến các mục tiêu. Sự đảm bảo này là một đặc điểm then chốt của phương thức Data propagation. Hầu hết các công nghệ truyền dữ liệu đồng bộ hỗ trợ trao đổi dữ liệu hai 114

chiều giữa một nguồn dữ liệu và dữ liệu đích. Tích hợp ứng dụng doanh nghiệp (enterprise application integration - EAI) và Tạo bảng sao dữ liệu doanh nghiệp (enterprise data replication EDR) là những công nghệ điển hình hỗ trợ cho Data propagation. 5.1.2.2. Công nghệ tích hợp dữ liệu Hiên nay có nhiều công nghệ tích hợp dữ liệu có thể thực hiện các kỹ thuật tích hợp dữ liệu nêu trên. Phần này đề cập ba công nghệ tích hợp phổ biến hiện nay: trích xuất, chuyển đổi và tải dữ liệu (Extract, Transform, Load - ETL); tích hợp thông tin doanh nghiệp (Enterprise information integration - EII); và tích hợp ứng dụng doanh nghiệp (Enterprise application integration - EAI). Công nghệ ETL (Extract, Load, Transform) Như tên gọi của nó, công nghệ ETL trích xuất dữ liệu từ các hệ thống dữ liệu nguồn, biến đổi nó để đáp ứng yêu cầu kinh doanh và tải các kết quả vào kho dữ liệu đích. Dữ liệu nguồn và đích thường là cơ sở dữ liệu và các tập tin, nhưng chúng cũng có thể là các loại dữ liệu khác. ETL hỗ trợ phương pháp tiếp cận dữ liệu hợp nhất (Data Consolidation) để tích hợp dữ liệu. Dữ liệu cũng có thể được trích xuất theo một mô hình kéo (Pull) điều khiển theo lịch trình (schedule-driven) hoặc mô hình đẩy (Push) điều khiển theo sự kiện (event-driven). Cách thức hoạt động kéo (Pull) hỗ trợ việc hợp nhất dữ liệu (Data Consolidation) và đặc biệt là được thực hiện theo lô (batch). Cách thức hoạt động đẩy (Push) được thực hiện trực tuyến bằng việc truyền dữ liệu thay đổi tới kho dữ liệu đích. Chuyển đổi dữ liệu bao gồm việc tái cấu trúc và tạo sự nhất quán dữ liệu. Dữ liệu sẽ được làm sạch và kết hợp lại. Tải dữ liệu có thể tạo ra các dữ liệu đích mới hoàn toàn hoặc thực hiện cập nhật dữ liệu đích. 115

Công nghệ EII (Enterprise Information Integration) EII cung cấp một khung nhìn (view) kinh doanh ảo của dữ liệu phân tán. Khung nhìn này có thể được sử dụng để thực hiện truy vấn theo nhu cầu các dữ liệu hoạt động kinh doanh. EII hỗ trợ một phương pháp tiếp cận data federation trong tích hợp dữ liệu. Mục tiêu của EII là để cho phép các ứng dụng có thể truy xuất dữ liệu phân tán giống như một cơ sở dữ liệu duy nhất. EII hỗ trợ cho các ứng dụng xử lý các khó khăn trong việc lấy các dữ liệu từ nhiều vị trí khác nhau, ở đó dữ liệu có thể khác nhau về mặt ngữ nghĩa, định dạng và có thể sử dụng các giao diện dữ liệu khác nhau. Các đặc trưng có thể phân biệt được khi đánh giá các sản phẩm EII bao gồm dữ liệu nguồn và đích được hỗ trợ các khả năng chuyển đổi, quản lý siêu dữ liệu, các khả năng cập nhật dữ liệu nguồn, các tùy chọn xác thực và bảo mật, hiệu suất và bộ nhớ đệm. Công nghệ EAI (Enterprise Application Integration) Hệ thống tích hợp ứng dụng EAI cho phép giao tiếp và trao đổi các dữ liệu giao dịch, thông điệp và dữ liệu với nhau sử dụng các giao tiếp tiêu chuẩn. Nó cho phép các ứng dụng để truy cập dữ liệu hoạt động một cách dễ dàng mà không cần biết vị trí hoặc định dạng của nó. EAI thường được sử dụng để xử lý giao dịch kinh doanh hoạt động theo thời gian thực. EAI là công nghệ hỗ trợ phương pháp tiếp cận lan truyền dữ liệu (data propagation) trong để tích hợp dữ liệu. Đứng trên quan điểm tích hợp dữ liệu, EAI có thể được sử dụng để vận chuyển dữ liệu giữa các ứng dụng và định tuyến dữ liệu sự kiện thời gian thực đến các ứng dụng tích hợp dữ liệu khác như một quá trình ETL. Tiếp cận đến ứng dụng nguồn và đích có thể được thực hiện thông qua các Web services, giao tiếp Microsoft.NET, Java Message Service (JMS)… 116

EAI được thiết kế để truyền một lượng nhỏ dữ liệu từ một ứng dụng này đến một ứng dụng khác. Sự lan truyền này có thể theo phương thức đồng bộ hoặc bất đồng bộ, nhưng gần như luôn luôn được thực hiện trong phạm vi của một giao dịch kinh doanh duy nhất. Trong trường hợp lan truyền bất đồng bộ, các giao dịch kinh doanh có thể được chia nhỏ thành nhiều giao dịch vật lý. Một ví dụ như một yêu cầu về du lịch được chia nhỏ riêng biệt nhưng có tính liên kết phối hợp thành các yêu cầu đặt vé máy bay, khách sạn và xe hơi. Chuyển đổi dữ liệu trong một hệ thống EAI tập trung theo hướng các cấu trúc giao dịch và thông điệp đơn giản và nó thường không thể hỗ trợ các cấu trúc dữ liệu phức tạp xử lý bởi các giải pháp ETL. Về vấn đề này, EAI không thể cạnh tranh với ETL. 5.2. Tích hợp dữ liệu v i ti n tr nh ETL Một tiến trình ETL (Extract-Load-Transform) sẽ được thực hiện qua ba bước: - Trích xuất: Dữ liệu nguồn từ rất nhiều nguồn khác nhau và có thể có rất nhiều cấu trúc dữ liệu khác nhau như nhiều loại cơ sở dữ liệu, từ file excel hay từ file thô. Vì thế nhiệm vụ chính của bước này là trích xuất dữ liệu từ hệ thống nguồn để xử lý. - Chuyển đổi: là quá trình rất phức tạp dùng để biến đổi dữ liệu nguồn, làm cho phù hợp và chuyển vào cơ sở dữ liệu đích. Đây là bước quan trọng nhất trong tiến trình ETL, nó thực hiện hầu hết các nhiệm vụ của tiến trình ETL. Ở bước này sẽ phải sử dụng các phép chuyển đổi như:  Chọn các cột dữ liệu phù hợp (chỉ chọn các cột cần thiết). 117

 Chuyển đổi dữ liệu. Ví dụ: chuyển giá trị 1 thành Nam hay ngược lại.  Tạo ra các cột tính toán mới. Ví dụ: Cột điểm trung bình.  Lọc dữ liệu và sắp xếp dữ liệu.  Thực hiện các phép tổng hợp (tính tổng các cột, đếm số dòng, tính trung bình).  Tạo ra các giá trị mới (tạo khóa tự tăng).  Tìm kiếm hay so sánh dữ liệu. - Tải dữ liệu: Đây là quá trình đẩy dữ liệu sau khi đã được chuyển đổi vào kho dữ liệu. Việc tải dữ liệu vào một nơi lưu trữ tập trung cho ph p các nhà phát triển có 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 đó. 5.2.1.

ích 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 thông tin quản lý để đ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. 118

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 sự kiện hay bảng chiều.  Tên CSDL nguồn (nếu nguồn gồm nhiều CSDL khác nhau).  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 (nếu dữ liệu nguồn và dữ liệu đích khác kiểu dữ liệu). Một ví dụ về bảng ánh xạ dữ liệu logic cho bảng DimCustomer, CSDL AdventureWorks được trình bày trên bảng 5.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, chúng ta phải tìm hiểu và nhận dạng các hệ thống dữ liệu 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 119

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ụ như ý 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. Bảng 0.1. Minh họa ánh xạ dữ liệu logic từ CSDL AdventureWorks AdventureWorks Database Bảng

Cột

AdventureWordsDW Bảng

Cột

Kiểu dữ liệu

CustomerKey

Int

CustomerID

GeographyKey

Int

FirstName

CustomerAlternate Key

Nvarchar (50)

MiddleName

FirstName

Nvarchar (50)

LastName

MiddleName

Nvarchar (50)

LastName

Nvarchar (50)

BirthDate

Datetime

Gender

MaritalStatus

Nchar(1)

Person.Email Address

EmailAddress

Gender

Nvarchar(1)

Person.Address

AddressLine1

EmailAddress

Nvarchar (50)

AddressLine

Nvarchar (120)

Sales.Customer

Person.Person

BirthDate HumanResources. Employee MaritalStatus

Person.Person Phone

Dim Customer

PhoneNumber

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. 120

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 thao 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, phươ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ụ: nếu lấy dữ liệu theo chu kỳ là 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 bao 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 khu vực xử lý (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 staging area (dựa vào khóa) hoặc đã bị thay đổi so với dữ liệu trong staging area. 121

5.2.2.

huy 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ả địa chỉ ở 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 1, TP Hồ Chí Minh. Nếu trong địa chỉ chỉ xác định là Quận 1, 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à TPHCM, 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à TPHCM - Đầ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 được phản ánh đầy đủ và chính xác. Như vậy, việc cần phải làm ở giai đoạn biến đổi dữ liệu là phải phát hiện ra 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 có thể dựa vào các chỉ số đo lường chất lượng dữ liệu. 122

5.2.3.

i 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, XML file, Spreadsheet... Yêu cầu của giai đoạn này có thể khác nhau đố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. Nếu như trong bước làm sạch dữ liệu, dữ liệu vẫn được giữ ở dạng chuẩn cao để bảo đảm tính nhất quán, thì ở bước tải 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. 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. 5.2.4.

ác v n

g p ph i khi tích hợp dữ liệu và gi i pháp

5.2.4.1. 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. 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ũng có một số khó khăn nhất định. Khó khăn đầu tiên là việc chuyển đổi cách cập nhật dữ liệu đã thường hay được sử dụng, đó là 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ệ 123

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: 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à 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 dữ liệu, 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 đề đối với dữ liệu giao dịch (transaction) khi dữ liệu quá lớn. Với mỗi sự thay đổi dữ liệu 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, chúng ta tạo các bảng sự kiện 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 sự kiện trong Data Warehouse. - Cách 4: lưu dữ liệu được cập nhật trong thời gian thực vào bộ nhớ đệ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 sự kiện và trong cả vùng nhớ đệm. 124

5.2.4.2. Vấn đề về không nhất quán dữ liệu khi thực hiện truy vấn Trong tình huống cần thực hiện một yêu cầu 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. Giả sử câu truy vấn này thực hiện như sau: tạo hai bảng tạm TEMP 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 TEMP , đưa tổng số tiền bán được vào bảng TEMP2, sau đó sẽ đưa ra bảng tổng kết. Vấn đề ở đây là nếu sau khi thực hiện việc đưa dữ liệu vào bảng TEMP1 nhưng chưa kịp đư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. 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ả hai dữ liệu. 5.3. Gi i thiệu công nghệ SSIS SQL Server Integration Service (SSIS) ra đời từ năm 2005, một trong các thành phần chính của Microsoft SQL Server Enterpise Edition. Tiền thân của SSIS là DTS (Data Transformation Services) có trong SQL Server 2000 trở về trước. Đây là công cụ dùng để thực hiện các tác vụ tích hợp dữ liệu (Data integration), là thành phần chính trong các ứng dụng Data Warehouse. 125

5.3.1. Import and export Wizard

Hình 0.3. Giao diện Import and Export Wizard Nếu bạn cần chuyển dữ liệu một cách nhanh chóng từ hầu như bất kỳ nguồn dữ liệu nào, bạn có thể sử dụng SSIS Import and Export Wizard (hình 5.3). Đây là công cụ thực hiện một cách nhanh chóng việc di chuyển và biến đổi dữ liệu. Bạn có thể nhanh chóng kiểm tra bất kỳ bảng bạn muốn chuyển, cũng như viết một truy vấn để lấy những dữ liệu mong muốn. 5.3.2. SQL Server Data Tools SQL Server Data Tools (SSDT) là công cụ trung tâm mà bạn sẽ phải dành phần lớn thời gian để nghiên cứu. Cũng giống các phần khác của SQL Server, nền tảng của công cụ này là giao diện Visual Studio (hình 5.4) và SSDT sẽ được cài đặt khi bạn cài đặt SQL Server. Điều hay nhất về công cụ này là nó không bị ràng buộc với bất kỳ SQL Server riêng biệt nào. Nói cách khác, 126

chúng sẽ không cần phải kết nối với SQL Server khi thiết kế một gói SSIS. Bạn có thể thiết kế các gói mà không cần kết nối với môi trường SQL Server và sau đó triển khai nó đến SQL Server mục tiêu hoặc hệ thống tập tin cần kết nối để chạy.

Hình 0.4. Giao diện tạo Package trong SSIS 5.3.3. Packages (gói) Khái niệm Package là một thành phần cốt lõi của SSIS. Về cơ bản, Packages là một tập hợp các tác vụ (Task) được thực hiện theo một trình tự. Các ràng buộc về độ ưu tiên giúp quản lý thứ tự các nhiệm vụ sẽ thực hiện. Package có thể được lưu vào SQL Server, cụ thể hơn, Package được lưu trong msdb hoặc package catalog của cơ sở dữ liệu. Nó cũng có thể được lưu dưới dạng một tập tin .dtsx theo định dạng XML. Kết quả thiết kế của một Package giống như được thể hiện trong hình 5.4 bên trên. 5.3.4.

asks (tác vụ)

Một Task là một tác vụ riêng rẽ để thực hiện một công việc. Task cung cấp các chức năng cho Package. Một Task có thể di chuyển một tập tin, tải một tập tin vào một cơ sở dữ liệu, gửi email, hoặc viết một tập hợp các đoạn mã .NET, đó chỉ là một vài trong số những chức năng Task có thể làm. Một số các Task thường dùng bao gồm: 127

- Bulk Insert Task: tải dữ liệu vào một bảng bằng cách sử dụng các lệnh SQL BULK INSERT. - Data Flow Task: đây là Task quan trọng nhất thực hiện việc tải (load) và chuyển dữ liệu đến OLE DB. - Execute Package Task: Cho phép bạn thực thi một Package từ bên trong một Package. - Execute Process Task: Thực thi một chương trình bên ngoài Package, ví dụ như một tách các file nén của bạn thành nhiều tập tin trước khi xử lý từng tập tin. Và còn nhiều Task khác như: Execute SQL Task, File System Task, FTP Task, Script Task, Send Mail Task, Analysis Services Processing Task, Web Service Task…. Bạn cũng có thể tự viết Task cho riêng mình hoặc tải Task từ các website cung cấp Task. Để viết được Task, bạn chỉ cần tìm hiểu mô hình đối tượng SSIS và biết VB.NET hoặc C #. Bạn cũng có thể sử dụng Script Task để thực hiện các tác vụ không có trong các Task có sẵn. 5.3.5. Data flow (luồng dữ liệu) Sau khi tạo Data Flow Task, quá trình thiết kế nó sẽ được thực hiện trong cửa sổ Data Flow trong SSDT. Trong khi luồng điều khiển (Control Flow) thực hiện xử lý các tiến trình chính của package, Data Flow sẽ xử lý việc chuyển đổi dữ liệu. Mỗi package có một luồng điều khiển duy nhất, nhưng có thể có nhiều luồng dữ liệu. Hầu như tất cả các thao tác với dữ liệu đều nằm trong phạm vi của Data Flow Task. Hình 5.5 là một ví dụ dòng dữ liệu, ở đây dữ liệu được lấy từ một nguồn OLE DB và được chuyển đổi trước khi được ghi vào một tập tin đích dạng flat file. Khi dữ liệu di chuyển qua từng bước của luồng dữ liệu, nó sẽ được chuyển đổi tùy theo các tác vụ chuyển đổi thực hiện ở từng bước. Trong ví dụ hình 5.5, một cột mới được thêm vào 128

trong khối chuyển đổi “Derived Column” và cột mới này sẽ có thể tiếp tục được chuyển đổi hoặc chuyển đến các đích mong muốn.

Hình 0.5. Data flow Bạn có thể thêm nhiều Data Flow Task trong luồng điều khiển. Bạn sẽ nhận thấy rằng sau khi bạn click vào mỗi Data Flow Task, màn hình sẽ chuyển sang giao diện thiết kế Data Flow và tên của “Data Flow Task” trong thiết kế luồng điều khiển sẽ hiển thị trong Combobox ở trên đầu giao diện thiết kế Data Flow. Bạn có thể chuyển đổi giữa các Data Flow Task dễ dàng bằng cách chọn các Data Flow Task từ Combo box trong giao diện thiết kế Data Flow. 5.3.6. Sou ces (nguồn) Sources là nơi bạn chỉ rõ vị trí của nguồn dữ liệu bạn sẽ lấy để đưa vào dòng dữ liệu. Sources thường được trỏ đến một trình quản lý kết nối (connection manager) trong SSIS. Sử dụng cách trỏ này, bạn có thể tái sử dụng các kết nối trong suốt quá trình thiết kế package vì khi cần thay đổi nguồn dữ liệu, bạn chỉ cần thay đổi kết nối ở một nơi duy nhất. Dưới đây là một số trong những Source thông dụng được sử dụng trong SSIS: 129

- OLE DB Source: kết nối đến gần như bất kỳ OLE DB nào như SQL Server, Access, Oracle, DB2… - Excel Source: nguồn nhận dữ liệu từ các bảng tính Excel. Nguồn này cũng cho ph p thực hiện truy vấn SQL với bảng tính Excel để chọn lọc dữ liệu mà bạn muốn trước khi đi vào dòng dữ liệu. - Flat File Source: kết nối tới một tập tin có chiều rộng cố định. - XML Source: lấy dữ liệu từ một nguồn theo định dạng XML. - ODBC Source (Open Database Connectivity): kết nối cơ sở dữ liệu mở, cho phép kết nối với các nguồn dữ liệu thông thường mà không sử dụng OLE DB. 5.3.7. Destinations ( ích) Bên trong luồng dữ liệu, Destinations là nơi nhận các dữ liệu từ các nguồn dữ liệu và từ khối biến đổi dữ liệu. Kiến trúc linh hoạt của nó cho phép gửi dữ liệu đến gần bất kỳ dạng dữ liệu nào như OLE DB, flat file….. Giống như Source, destinations được quản lý thông qua trình quản lý kết nối (connection manager). Một số destinations phổ biến trong SSIS có thể nói đến là: Excel Destination, Excel Destination, Excel Destination, SQL Server Destination. 5.3.8.

ansfo mations (biến

i dữ liệu)

Transformations là một thành phần quan trọng trong luồng dữ liệu, nó thực hiện nhiệm vụ biến đổi dữ liệu sang một định dạng mà bạn mong muốn. Ví dụ, bạn có thể muốn dữ liệu của bạn được sắp xếp và tổng hợp lại. Khi đó, hai Transformation có thể thực hiện nhiệm vụ này cho bạn. Ưu điểm của các biến đổi trong SSIS là chúng đều được thực hiện trong bộ nhớ RAM của 130

máy tính nên quá trình biến đổi được thực hiện cực kỳ hiệu quả. Bộ nhớ xử lý dữ liệu nhanh hơn nhiều so với đĩa cứng, và nếu đĩa cứng bị phân mảnh thì thời gian xử lý có thể bị kéo dài ra nhiều lần so với xử lý trên bộ nhớ. Dưới đây là một số trong các phép biến đổi phổ biến hay được sử dụng trong SSIS: - Aggregate: tổng hợp dữ liệu tương tự như câu lệnh GROUP BY trong T-SQL. - Conditional Split: tách dữ liệu dựa trên điều kiện nhất định được đáp ứng. Biến đổi này là tương tự như CASE statement trong T-SQL. - Data Conversion: chuyển đổi một cột từ kiểu dữ liệu này sang kiểu dữ liệu khác. Biến đổi này là tương tự như CAST statement trong T-SQL. - Derived Column: thực hiện tạo ra một cột mới từ một công thức. Ví dụ, bạn có thể sử dụng biến đổi này để tính toán một cột lợi nhuận dựa trên cột chi phí và giá bán. - Fuzzy Grouping: thực hiện làm sạch dữ liệu bằng cách dò tìm hàng có khả năng lặp. - Fuzzy Lookup: làm cho phù hợp và chuẩn hóa dữ liệu dựa trên logic mờ. Ví dụ, phép biến đổi này có thể đổi tên Jon thành John. - Lookup: thực hiện tìm kiếm dữ liệu để sau này sử dụng trong transformation khác. Ví dụ, bạn có thể sử dụng biến đổi này để tìm kiếm một thành phố dựa trên mã ZIP. - Multicast: gửi một bản sao của dữ liệu đến một nơi khác trong tiến trình xử lý và nó có thể được sử dụng để song song hóa dữ liệu. Ví dụ, bạn có thể muốn gửi cùng một tập hợp mẫu tin đến để hai bảng đồng thời. 131

- OLE DB Command: thực thi lệnh OLE DB cho mỗi hàng trong dòng dữ liệu. Nó có thể được sử dụng để chạy lệnh UPDATE hoặc DELETE bên trong luồng dữ liệu. - Row Count: lưu lại kết quả đếm số hàng từ dòng dữ liệu vào một biến để sau này sử dụng (sử dụng cho mục đích kiểm soát). - Script Component: sử dụng một Script để biến đổi dữ liệu. Ví dụ, bạn có thể sử dụng biến đổi này để áp dụng các nguyên tắc logic kinh doanh trong Data Flow. - Slowly Changing Dimension: kết hợp để thêm mới hoặc cập nhật dữ liệu có điều kiện khi thay đổi Dimension trong suốt quá trình tải dữ liệu lên Data Warehouse. - Sort: sắp xếp dữ liệu trong dòng dữ liệu của một cột nhất định và loại bỏ chính xác các dữ liệu bị lặp. - Union All: hợp nhất nhiều tập dữ liệu thành một tập hợp dữ liệu duy nhất. - Unpivot: chuyển dữ liệu từ một định dạng không chuẩn hóa thành dữ liệu quan hệ. 5.4. Tích hợp dữ liệu v i SSIS 5.4.1.

ạo một SSIS P oject

Quá trình tích hợp dữ liệu với SSIS bắt đầu bằng việc tạo một Project mới. Bạn không thể tạo một SSIS package trong SQL Server Data Tools (SSDT) nếu chưa tạo Project. SSDT là chương trình sử dụng để phát triển các SSIS package. Trong SQL Server 2012, SSDT chính là Visual Studio 2010 Shell. Bạn có thể mở SSDT từ nhóm chương trình SQL Server 20 2 hoặc mở nó trong bộ chương trình Visual Studio 20 2. 132

Một SSIS Project có thể bao gồm một hoặc nhiều SSIS package. Tất cả các công cụ trong Visual Studio đều dùng khái niệm “Project” để lưu trữ các file. Ví dụ, Reporting Services sử dụng project lưu trữ các báo cáo, VB.NET sử dụng project để giữ các file class VB.NET. Nhìn chung, bạn có thể sắp xếp một dự án kinh doanh mà bạn đang làm việc vào một project trên SSIS và bạn có thể đặt tên cho project của bạn, ví dụ như “Data Warehouse ETL”. Bên cạnh khái niệm “Project”, “Solution” (giải pháp) là một khái niệm lớn hơn. Một Solution có thể bao gồm một hay nhiều loại Project khác nhau. Ví dụ, bạn có một Solution gọi là “Enterprise Data Warehouse” với một SSRS (SQL Server Reporting Services) Project tên là “Data Warehouse reports”, một Project cho SSIS gọi là “Data Warehouse ETL”, và cuối cùng là Project cho C # là “SharePoint code”. Tất cả những Project có thể “sống chung dưới một mái nhà Solution” với nhau. Vì vậy nếu một nhà phát triển báo cáo (report developer ) thay đổi thiết kế trong Project của SSRS của mình, các nhà phát triển SSIS sẽ nhận biết được sự thay đổi đó. Để tạo một project mới trong SSIS, mở SSDT và thực hiện theo các bước sau: 1. Mở SQL Server Data Tools từ nhóm chương trình SQL Server 2012. 2. Click File  New  Project. 3. Chọn loại project là Business Intelligence Projects. 4. Chọn Integration Services Project từ danh sách templates. 5. Nhập tên của project và chọn đường dẫn lưu Project, và nhập tên cho Solution. 133

Hình 0.6. Giao diện tạo project trong SSIS 5.4.2.

ạo một Package

Để tạo ra Package, trước tiên cần tạo một Project. Sau khi tạo Project, một package tên là Package.dtsx được tự động tạo ra. Nếu muốn đổi tên, chúng ta chỉ cần kích chuột phải vào package trong cửa sổ Solution Explorer, chọn Rename và giữ lại phần mở rộng .dtsx (hình 5.7).

Hình 0.7. Giao diện tạo Package 134

Tạo và sử dụng Connection Managers Để thiết kế một Package, đầu tiên phải tạo kết nối bằng cách sử dụng chức năng Connection Manager trong SSIS. Một connection manager có thể được sử dụng một hoặc nhiều lần trong một Package. Để tạo connection manager, click phải lên cửa sổ connection manager nằm bên dưới màn hình trong SSDT và chọn New. Bất kỳ kết nối nào được dùng trong SSIS (kết nối đến file hay cơ sở dữ liệu) đều được chứa trong connection manager. Một số kết nối thông dụng được trình bày ở bảng 5.2 bên dưới. Bảng 0.2. Một số kết nối thông dụng trong SSIS Connection Manager Dạng thức k t nối

Connection Manager

Database

Sử dụng OLE DB Connection Manager cho Oracle, SQLServer, DB2 ADO NET và ODBC Connection Manager đến các nguồn dữ liệu ODBC và một số dạng thức kết nối OLE DB khác.

File

Sử dụng Flat File Connection Manager khi muốn tải các tập tin bằng cách sử dụng Task trong Data Flow. Ngoài ra cũng có một Connection Manager khác được gọi là File Connection Manager mà chúng ta có thể sử dụng nếu muốn đổi tên, xóa, hoặc thực hiện một số thao tác khác trên tập tin.

Excel

Excel Connection Manager - kết nối đến bảng tính Excel.

Internet Connection

Kết nối SMTP đến mail servers. Kết nối FTP Connection đến FTP servers. Kết nối HTTP đến websites hoặc web services. 135

Một khi chúng ta tạo một kết nối OLE DB, nó sẽ sẵn sàng để sử dụng ở bất kỳ đâu trong packgage. Nếu muốn, có thể tạo ra một kết nối có thể được sử dụng ở nhiều package khác nhau bằng cách tạo kết nối cho project. Để làm điều này, click chuột phải vào dòng Connection Managers trong của sổ Solution Explorer và chọn New Connection Manager. Khi đó dữ liệu nguồn có thể được nhiều Package sử dụng chung và có thể được thay đổi trong DBA sau này. Bằng cách tạo ra một kết nối dạng như vậy, chúng ta chỉ cần nhập mật khẩu một lần cho kết nối và nếu chúng ta thay đổi bất kỳ thông số kết nối nào, nó sẽ thay đổi trên toàn bộ các Package sử dụng kết nối đó. Nói chung, sử dụng Connection Manager chung cho một Project là cách tuyệt vời để quản lý kết nối cho dự án nếu chúng ta sẽ sử dụng lại kết nối đó một vài lần. Sử dụng và cấu hình Tasks Một package sẽ chẳng có giá trị gì nếu không có các Task. Task trong luồng điều khiển làm nhiệm vụ sắp xếp các tác vụ sẽ được thực hiện trong package. Ví dụ, một Task đảm nhiệm việc sao chép một tập tin từ một máy chủ trong khi một Task khác sẽ tải tập tin vào cơ sở dữ liệu. Để sử dụng một Task, chỉ cần kéo thả nó vào cửa sổ thiết kế của luồng điều khiển từ hộp công cụ.

Hình 0.8. Minh họa Task Sau khi các Task được cấu hình bằng cách nhấp đúp vào mỗi Task, bạn có thể thấy một cảnh báo màu vàng hoặc lỗi hiển thị màu đỏ trên các Task này. Sau khi cấu hình các Task, chúng ta có thể liên kết nó với các Task khác bằng cách sử dụng precedence constraints (ràng buộc thứ tự). Khi bạn click vào Task, bạn sẽ nhận thấy một mũi tên màu xanh (Precedence 136

constraints) chỉ xuống từ các Task, như trong hình 5.8. Precedence constraints điều khiển thứ tự thực hiện các Task trong Package, và bạn có thể sử dụng nó bằng cách k o mũi tên màu xanh lá cây đến các Task tiếp theo mà bạn muốn kết nối lại với nhau. Chi tiết về Precedence constraints sẽ được trình bày trong phần luồng điều khiển ở phần sau. Thực thi một Package Một khi Package đã sẵn sàng để thực thi, bạn có thể chạy nó trong chế độ gỡ lỗi (debug mode) bằng cách click chuột phải vào nó trong cửa sổ Solution Explorer và chọn Execute Package. Bằng cách chạy các package trong chế độ gỡ lỗi, bạn xem được cửa sổ log và các breakpoint (điểm dừng) sẽ giúp bạn xác định tại sao package không chạy được. Tuy nhiên, trong chế độ gỡ lỗi, bạn sẽ không thể sửa đổi Package. Để dừng chế độ gỡ lỗi, bấm nút Stop hoặc bấm vào menu Debug/Stop Debugging. 5.4.3. Luồng i u khi n ( ont ol Flow) 5.4.3.1. Sử dụng Precedence constraint Khi sử dụng các Task trong SSIS, bạn cần một công cụ để kết nối các Task lại với nhau. Precedence constraints sẽ thực hiện kết nối giữa các Task để kiểm soát thứ tự thực hiện của từng Task. Sau khi bạn tạo nhiều Task trong giao diện thiết kế luồng điều khiển, bạn có thể liên kết chúng lại với nhau bằng cách sử dụng các Precedence constraint. Khi bạn click vào Task, và bạn sẽ thấy một mũi tên màu xanh lá cây chỉ xuống; đó chính là Precedence constraint. Ví dụ, trong hình 5.9, bạn có thể thấy một Script Task với một mũi tên màu xanh lá cây ở bên dưới. Đây là mũi tên thể hiện thứ tự ưu tiên để kết nối với Task tiếp theo cần chạy sau khi Task hiện tại đã chạy xong. Những mũi tên sẽ điều khiển trình tự thực hiện của các Task trong package và chúng cũng kiểm soát xem liệu tất cả các Task đã được thực hiện hay chưa. 137

Hình 0.9. Precedence Constraint Để tạo một Precedence constraint, nhấp vào mũi tên màu xanh lá cây hướng ra từ Task và k o nó vào Task mà bạn muốn liên kết. Trong hình 5.10, bạn sẽ nhìn thấy một Precedence constraint thành công giữa hai Script Task. Với kết nối này, chỉ khi nào Script Task đầu tiên hoàn thành thì Script Task thứ hai mới bắt đầu chạy.

Hình 0.10. Kết nối 2 Task Các mũi tên precedence constraint có thể có màu sắc khác nhau để đại diện cho các lệnh khác nhau. Chúng cũng có thể có một biểu tượng “fx” để thể hiện cho một biểu thức, như trong hình 5.11. Tạo một biểu thức “fx” trên precedence constraint cho phép bạn kiểm soát việc thực hiện của từng gói. Ví dụ, bạn có thể muốn Task Script 1 thực hiện khi và chỉ khi bạn đang thực hiện xử lý có tính chu kỳ vào cuối tháng. Mỗi màu sắc tượng trưng cho một trạng thái khi một task thực thi:  Xanh lá cây = On Success  Đỏ = On Failure  Xanh dương = On Completion 138

Hình 0.11. Những mũi tên kết nối Task trong tab Data Flow trông giống như những precedence constraints trong Control Flow, tuy nhiên chúng không có cùng đặc tính giống như những kết nối trong Control Flow. Khi click vào một source hoặc transformation trong tab Data Flow, và bạn thấy một mũi tên màu xanh dương và màu đỏ chỉ xuống (như trong hình 5. 2). Các mũi tên màu xanh dương là dòng chảy của dữ liệu tốt, và mũi tên màu đỏ là dòng chảy của dữ liệu bị lỗi. Điều này cho phép dữ liệu lỗi có thể được tách riêng với dữ liệu tốt để gởi đến một nơi khác.

Hình 0.12. Dạng kết nối Các mũi tên trong Control Flow lại có tính năng khác hơn. Nếu bạn muốn một Task tiếp theo được thực hiện chỉ khi Task đầu tiên thực hiện bị lỗi, bạn có thể tạo ra precedence constraints với giá trị là “Success” (màu xanh) như bình thường. Sau đó thực hiện nhấp đúp vào mũi tên màu xanh để mở ra giao diện “Precedence Constraint Editor ”, bạn sửa lại trạng thái cho mũi tên là “Failure” và bấm “OK”, lúc này mũi tên sẽ chuyển thành màu đỏ và precedence constraints sẽ được chuyển thành “On Failure event” 139

5.4.3.2. Sử dụng Execute SQL task Khi tạo một Package SSIS, một trong những task thường được sử dụng nhất là Execute SQL Task. Task này dùng để insert, update, select hoặc truncate dữ liệu từ bảng trong SQL. Bất kỳ lệnh SQL thông dụng nào đều có thể được thực hiện bằng cách sử dụng task này. Bạn có thể sử dụng các thông số giống như một “store procedure” và thậm chí bạn có thể gọi một “store procedure” từ một task khác. Để thực hiện Execute SQL Task bạn phải kết nối tới cơ sở dữ liệu MS SQL bằng cách sử dụng connection manager. Nhấp đúp vào Execute SQL Task trong luồng điều khiển để mở giao diện Execute SQL Task Editor, bạn sẽ thấy có bốn chức năng trong khung bên trái: General, Parameter Mapping, Result Set, Expressions (hình 5.13).

Hình 0.13. Giao diện cấu hình Execute SQL Task 140

Trong danh mục General, hai thuộc tính đầu tiên là Name và Description. Các thông số này này không ảnh hưởng đến Task. Chúng được sử dụng cho mục đích dễ dàng phân biệt khi xem các Task trong Control Flow. Hai tùy chọn tiếp theo là TimeOut và CodePages. TimeOut là số giây tối đa mà Execute SQL Task chạy trong trường hợp bị lỗi. Nếu bạn gán giá trị 0 nghĩa là vô hạn. Thông số Code pages được thiết lập dựa trên các Code pages được sử dụng trên các máy chủ SQL. TypeConversionMode là tùy chọn mới trong SQL Server 2012. Tùy chọn này cho phép Execute SQL Task chuyển đổi kiểu dữ liệu trước khi lưu vào một biến. Trường hợp các kiểu dữ liệu của biến SSIS không phù hợp chính xác với các kiểu dữ liệu trong SQL Server, điều này có thể được xử lý bằng tùy chọn TypeConversionMode. Thiết lập thông số này là Allowed để cho phép Execute SQL Task chuyển đổi kiểu dữ liệu phù hợp với các biến khi cần thiết. Mục ResultSet là kiểu dữ liệu trả về từ câu lệnh SQL. Kết quả này có thể là None khi lệnh SQL không trả về dữ liệu, ví dụ như khi thực hiện lệnh Insert. Tập kết quả có thể là một hàng duy nhất (singe row). Hàng duy nhất này có thể được lưu trữ trong một biến kiểu chuỗi hoặc số nguyên. Nó cũng có thể là một tập hợp kết quả đầy đủ (full result set) hoặc XML, có thể được lưu trữ dưới dạng một biến đối tượng. Các biến này được đặc tả trong mục ResultSet. Để thiết lập, bạn click vào mục ResultSet, sau đó bấm nút “Add” để thêm. Bạn sẽ không thêm được nếu trong mục General mục ResultSet được thiết lập là None. Danh mục Parameter Mapping là nơi bạn thiết lập các thông số mà bạn muốn truyền vào truy vấn SQL. Các truy vấn SQL có thể xử lý nhiều thông số. Trong mục này bạn có thể tạo ra các ánh xạ tham số để kết nối các tham số trong lệnh SQL và các biến trong package. Ví dụ bạn có thể sử dụng Execute SQL Task để đếm dữ liệu trong một bảng và trả về kết quả là một số. Câu truy vấn SQL sẽ dạng như sau: 141

Select Count(*) as Counter From Production.Product Kết quả trả về sẽ là Counter, và bạn có thể gán cho nó trở thành một biến số nguyên bằng cách sử dụng Result Set đã trình bày ở trên, sau đó bạn có thể ánh xạ vào một biến trong Package. Nếu câu truy vấn SQL trả về kết quả nhiều hơn một dòng, bạn cần lưu trữ trong một biến đối tượng (object variable). Một khi dữ liệu được lưu dưới dạng một biến trong package, bạn có thể sử dụng biến này ở bất kỳ đâu trong package (trong các task hoặc biểu thức khác). Quay trở lại mục General, một thuộc tính tiếp theo mà bạn cần quan tâm đó là Connection Type. Hộp Connection Type sẽ xổ xuống 6 tùy chọn: Excel, OLE DB, ODBC, ADO, ADO.NET, SQLMobile. Mục connection được sử dụng để lấy dữ liệu từ các loại kết nối khác nhau bằng cách sử dụng ngôn ngữ SQL. Phần này sẽ trình bày về kết nối OLE DB để lấy dữ liệu từ bảng của SQL Server. Sau khi bạn chọn mục connection type là OLE DB, bạn có thể nhấp chọn một kết nối có sẵn (nếu bạn đã tạo sẵn kết nối sử dụng connection manager) trong mục connection. Tuy nhiên, nếu bạn thấy dòng có nghĩa là bạn chưa tạo kết nối. Bạn nhấp , cửa sổ tạo kết nối sẽ mở ra tương ứng tùy thuộc vào loại kết nối mà bạn chọn. Bước tiếp theo (hình 5.13) là chọn SQLSourceType. Có ba tùy chọn  Direct Input - Lệnh SQL trực tiếp gõ vào Execute SQL Task.  File Connection - Lệnh SQL được lưu trong một tập tin bên ngoài.  Variable - Lệnh SQL được lưu trữ trong biến của package. 142

Tùy chọn Direct Input là dễ sử dụng nhất. Sử dụng tùy chọn này cho phép bạn gõ lệnh SQL trực tiếp vào Execute SQL Task. Ưu điểm của phương pháp này là dễ dàng nhập các lệnh SQL nhưng bất lợi là các lệnh SQL không thể được thay đổi bên ngoài package. Vì vậy, việc bảo trì là khó khăn hơn và đòi hỏi các gói phải được thay đổi và tái bố trí lại. Điều này có thể gây phức tạp và tốn thời gian. Tùy chọn File Connection giúp bạn dễ dàng thay đổi các lệnh SQL từ bên ngoài của package. Vì vậy, khi nhu cầu kinh doanh thay đổi và bạn cần chọn dữ liệu khác cho package của mình thì khi đó bạn có thể thực hiện những thay đổi rất dễ dàng. Nhược điểm của cách làm này liên quan đến việc duy trì và bảo vệ các file của bạn. Hãy tưởng tượng: nếu một người nào đó vô tình xóa tất cả các file lệnh SQL mà package của công ty bạn sử dụng hàng ngày thì bất kỳ package nào có sử dụng những tập tin này đều sẽ không chạy được. Các tùy chọn Variable tương tự như Direct Input vì các biến được lưu trữ trong các package. Tuy nhiên, nhờ các file cấu hình, các biến cũng có thể dễ dàng được thay đổi bên ngoài package. Tuy hơi phức tạp hơn nhưng đây tùy chọn khắc phục được cả hai nhược điểm của hai tùy chọn trên. Sau khi bạn đã lựa chọn SQL source type, bạn sẽ có tùy chọn nhập trực tiếp câu lệnh SQL (nếu chọn Direct input), chọn tập tin kết nối, hoặc chọn một biến. Các tùy chọn hiển thị sẽ thay đổi tùy thuộc vào SQL source type mà bạn chọn. 5.4.3.3. Tạo Data flow Task Data Flow Task được sử dụng để chuyển dữ liệu từ một nguồn đến đích và dữ liệu có thể được biến đổi khi cần thiết. Các Data Flow Task có khả năng xử lý một lượng lớn dữ liệu. Các nguồn và đích có thể ở những dạng thức khác nhau như flat file hoặc cơ sở dữ liệu… 143

Bạn có thể sử dụng Data Flow Task để trích xuất dữ liệu từ một cơ sở dữ liệu và ghi vào một flat file hoặc để di chuyển dữ liệu từ một flat file tới một cơ sở dữ liệu. Điều này cho phép bạn nhận tập tin từ các nguồn bên ngoài và ghi dữ liệu này lên cơ sở dữ liệu. Bạn cũng có thể sử dụng Data Flow Task để di chuyển dữ liệu từ một cơ sở dữ liệu này sang một cơ sở dữ liệu khác. Công cụ transforms trong Data Flow cho phép bạn biến đổi dữ liệu khi bạn di chuyển nó từ một nguồn đến đích. Ví dụ, nếu bạn đang nhận được các flat file từ một nhà cung cấp và các dữ liệu không được định dạng chính xác (ví dụ số thẻ tín dụng cần phải có dấu gạch ngang), bạn có thể khắc phục điều đó trước khi ghi nó vào một cơ sở dữ liệu. Để tạo ra một dòng dữ liệu trong package, thực hiện bấm và kéo thả Data Flow Task từ hộp công cụ vào giao diện Control Flow. Sau đó click vào Data Flow Task để chuyển qua giao diện thiết kế Data Flow. Trường hợp có nhiều Data Flow trong package, bạn sẽ thấy một trình đơn xổ xuống ở phía trên cùng của màn hình hiển thị danh sách của tất cả các Data Flow trong package. Khi bạn chuyển qua màn hình thiết kế Data Flow, hộp công cụ bên trái cũng bị thay đổi. Lúc này nó sẽ hiển thị các công cụ có thể sử dụng để thiết kế trong Data Flow. Sau khi bạn kéo Task Source vào một luồng dữ liệu, có hai mũi tên xuất hiện từ phía dưới cùng của Task. Mũi tên màu xanh là các dữ liệu tốt, màu đỏ là các dữ liệu xấu. Nhấp đúp vào Source, bạn có thể mở giao diện Source Editor để thay đổi một số thông số, ví dụ như thay đổi vị trí của nguồn. Sau khi Source được thiết lập, bạn có thể kết nối nó với các Task transform sử dụng các công cụ transform trong hộp công cụ. Sau khi các Source và Transform được tạo ra, bạn có thể kéo một Destination từ hộp công cụ và kết nối transform ở bước biến đổi cuối cùng vào Destination. Nếu Data Flow không chứa bất 144

kỳ Transform nào, các Source có thể được kết nối trực tiếp đến Destination, đây đơn giản chỉ là cách di chuyển dữ liệu từ nơi này đến nơi khác mà không cần thay đổi dữ liệu. 5.4.4. Dòng dữ liệu (Data flow) 5.4.4.1. Trích xuất dữ liệu từ nguồn Source Assistant là một tính năng mới của SSIS hỗ trợ cho bạn cấu hình Source và connection manager. Trong giao diện thiết kế Data Flow, chọn Source Assistant từ SSIS Toolbox. Hình 5.14 thể hiện giao diện Source Assistant trong đó hiển thị một số nguồn dữ liệu mà bạn có thể chọn. Bạn cũng có thể tạo một kết nối mới bằng cách nhấn vào New trong hộp “Select connection manager”. Nếu có một Source đã được cài đặt nhưng nó lại không hiển thị trong mục này, bạn có thể bỏ tùy chọn “Show only installed source types”, khi đó tất cả các Source sẽ được hiển thị. Sau khi chọn các Source và Connection manager thích hợp, nhấp OK và một Source xuất hiện trong giao diện thiết kế Data Flow.

Hình 0.14. Giao diện Source Assistant 145

OLE DB Source Loại Source phổ biến nhất là OLE DB, nó có thể kết nối đến bất kỳ nguồn OLE DB (Object Linking and Embedding Database) nào, chẳng hạn như SQL Server, Oracle, hoặc DB2. Để cấu hình nguồn OLE DB, thêm OLE DB Source từ hộp SSIS tool box vào cửa sổ thiết kế Data Flow. Nhấp đúp vào nó để mở giao diện quản lý kết nối OLE DB Source Editor, thể hiện trong hình 5.15, chọn “connection manager of your OLE DB” từ danh sách xổ xuống. Bạn cũng có thể thêm một Connection manager mới bằng cách nhấn vào nút New. Tùy chọn chế độ truy cập dữ liệu “Data access mode” cho phép bạn chọn cách lấy dữ liệu từ nguồn như thế nào. Có bốn chế độ truy cập dữ liệu khác nhau: Table or view, Table name or view name variable, SQL command, hoặc SQL command from variable.

Hình 0.15. Giao diện OLE DB Source Editor Sau khi hoàn thành cấu hình mục connection manager, bạn có thể vào giao diện Columns để kiểm tra từng cột bạn cần sử 146

dụng từ bảng như trong hình 5. 6. Trong giao diện Columns, bạn có thể gán tên cho cột bằng cách gõ tên mới vào “Output Column”. Chú ý rằng bạn nên xem x t để lấy những cột nào cần sử dụng. Bạn sẽ có được hiệu suất tốt hơn khi truy vấn một tập dữ liệu nhỏ hơn. Bạn chỉ nên truy vấn các cột cần thiết trong bảng thay vì truy vấn toàn bộ bảng. Đôi khi các loại dữ liệu không tương thích có thể gây ra vấn đề chuyển đổi, và bạn có thể muốn gửi các lỗi đến một nơi khác trong dòng dữ liệu. Bạn có thể thực hiện điều này trong giao diện “Error Output”. Trên mỗi cột, bạn có thể quyết định nếu một lỗi xảy ra, sẽ xử lý bỏ qua hàng đó hay được chuyển hướng (redirect) hoặc dừng. Nếu bạn chọn bỏ qua, thì cột ứng với hàng lỗi được gán giá trị NULL. Nếu chọn chuyển hướng, hàng lỗi sẽ được gửi xuống theo mũi tên màu đỏ trong dòng dữ liệu ra khỏi các nguồn OLE DB.

Hình 0.16. Giao diện chọn Columns trong OLE DB Source Editor 147

5.4.4.2. Tải dữ liệu đến đích Sau khi bạn đã thiết lập nguồn để đưa các dữ liệu vào luồng dữ liệu, bạn cần một Task để đưa dữ liệu đến nơi cần thiết. Một Destination sẽ thực hiện công việc nhận dữ liệu từ các Source hay Tranformations và chuyển dữ liệu đến nơi lưu trữ dữ liệu mong muốn đã được cấu hình trong Connection manager. Sự khác biệt trong việc cấu hình Source và Destination là giao diện Mappings thể hiện trong hình 5.17. Giao diện Mappings sẽ xác định ánh xạ dữ liệu từ mỗi cột trong luồng dữ liệu đến các cột hiện có trong Destination. Mặc định, SSIS sẽ tự động ánh xạ các cột có cùng tên, tuy nhiên bạn có thể dễ dàng chỉnh lại ánh xạ dữ liệu bằng cách kéo thả các đường liên kết giữa các cột trong trường hợp các cột không cùng tên. Như thể hiện trong hình 5.17, các cột cùng tên không bắt buộc phải được sắp xếp theo thứ tự từ Source đến Destination. Bạn không thể cấu hình cho Destination nếu bạn chưa kết nối dữ liệu đầu vào cho nó. Để thực hiện kết nối, chọn Source hoặc một Transfommation và k o mũi tên màu xanh dương đến Destination. Nếu bạn muốn xuất dữ liệu lỗi của biến đổi, hãy sử dụng mũi tên màu đỏ.

Hình 0.17. Giao diện Mappings trong Destination 148

Sử dụng Destination assistant Destination assistant là một tính năng mới của SSIS hỗ trợ việc xác định Destination và Connection manager. Từ giao diện Data Flow, chọn Destination assistant từ SSIS Toolbox. Hình 5.18 thể hiện giao diện Destination assistant và các loại Destination mặc định. Ngoài việc lựa chọn loại Destination có sẵn, bạn cũng có thể tạo mới kết nối bằng cách sử dụng chức năng “New” trong hộp “Select connection managers”. Các cấu hình trong Destination Assistant tương tự như trong Source Assistant.

Hình 0.18. Giao diện Destination Asisstant OLE DB Destination

Hình 0.19. Giao diện cấu hình OLE DB Destination 149

Tùy chọn “Table or View - fast load” trong mục “Data access mode” cho ph p SSIS tải dữ liệu với số lượng lớn vào bảng mục tiêu của OLE DB Destination. Tùy chọn tải nhanh Fast Load chỉ hiển thị trong trường hợp cơ sở dữ liệu là SQL Server. Khi Fast Load được chọn, bạn có thêm các tùy chọn như Table Lock (khóa bảng khi tải dữ liệu), Rows Per Batch (chỉ định số dòng tải theo lô), và Maximum Insert Commit Size (kích thước tối đa của một lô trước khi thực hiện Commit, thông thường giá trị này là 10.000) (hình 5.19). 5.4.4.3. Chuyển đổi kiểu dữ liệu với Data Conversion transform Việc chuyển đổi dữ liệu trong SSIS tương tự như các chức năng CONVERT hoặc CAST trong lập trình T-SQL. Để cấu hình Transfomation này, trước tiên cần kết nối nó với một nguồn dữ liệu, sau đó k o “Data conversion” ở của sổ SSIS toolbox vào màn hình thiết kế Data Flow và nhấp đúp vào nó để mở giao diện cấu hình (hình 5.20). Trong giao diện này, thực hiện kiểm tra các cột bạn cần phải chuyển đổi và sử dụng trình đơn thả xuống Data Type để chọn loại dữ liệu muốn chuyển đổi.

Hình 0.20. Giao diện cấu hình Data Conversion Transformation 150

Trong mục “Data type”, format dữ liệu sẽ hiển thị khác với tên các kiểu dữ liệu trong SQL Server. Ví dụ kiểu dữ liệu trong SQL Server là varchar sẽ tương ứng với String [DT_STR] trong SSIS. Trong mục Output Alias, bạn có thể gán tên cột mới được tạo ra sau khi chuyển đổi. Nếu bạn không gán tên mới, nó có tên mặc định là “Copy of Column Name”, tuy nhiên bạn nên đặt tên cho cột đã được chuyển đổi để dễ dàng nhận biết trong các bước xử lý tiếp theo. 5.4.4.4. Sắp xếp dữ liệu sử dụng Sort Transform Sort Transform cho phép bạn sắp xếp các dữ liệu ở bất kỳ cột nào tại bất kỳ nơi nào trong Data Flow. Để sắp xếp dữ liệu, trước tiên thực hiện thêm Task Sort Transform vào màn hình thiết kế Data flow và kết nối với nguồn dữ liệu. Tiếp theo, mở giao diện Sort Transformation Editor (hình 5.21) và chọn các cột bạn muốn sắp xếp theo thứ tự. Bạn cũng có thể loại bỏ các cột không cho đi qua Transformation bằng cách bỏ chọn cột trong mục “Pass Through Column”. Bạn cũng có thể dùng tùy chọn “Remove rows with duplicate sort values” để loại bỏ hàng nếu có giá trị trùng với hàng trước đó.

Hình 0.21. Giao diện Sort Transformation 151

Sắp xếp dữ liệu trong SSIS là một trong những hoạt động cần thiết và thường xuyên. Điều này là do quá trình xử lý dữ liệu yêu cầu dữ liệu phải được sắp xếp trước khi được xử lý. Tuy nhiên bạn có thể sắp xếp dữ liệu với Sort Transform hoặc dùng ORDER BY trong OLE DB Source. Bạn nên tránh lạm dụng Sort Transform vì nó sẽ gây ảnh hưởng đến tốc độ xử lý dữ liệu. Nếu bạn sử dụng ORDER BY trong OLE DB Source, SSIS sẽ không biết được bạn đã thực hiện ORDER BY cho dữ liệu, do đó bạn phải thông báo với SSIS rằng dữ liệu đã được sắp xếp. Để thực hiện điều này, kích chuột phải vào Source và chọn “Show Advanced Editor”; sau đó chuyển qua tab “Input and Output Properties” và chọn “OLE DB Source Output”. Trong cửa sổ “Properties”, thay đổi thuộc tính IsSorted thành True như trong hình 5.22.

Hình 0.22. Giao diện Advance Editor cho OLE DB Source Sau đó, trong mục Output Columns, chọn cột bạn muốn sắp xếp trong câu lệnh SQL và thay đổi giá trị 152

SortKeyPosition là (hình 5.23) để sắp xếp theo thứ tự tăng dần. Giá trị -1 sẽ sắp xếp dữ liệu theo thứ tự giảm dần. Nếu bạn muốn sắp xếp nhiều cột, bạn có thể gán giá trị SortKeyPosition để chỉ định thứ tự ưu tiên sắp xếp trong câu lệnh ORDER BY với giá trị từ 1 trở đi. Nếu bạn muốn sắp xếp giảm dần, hãy gán giá trị -1 cho SortKeyPosition.

Hình 0.23. Gán thứ tự ưu tiên sắp xếp dữ liệu nguồn 5.4.4.5. Liên kết dữ liệu sử dụng Lookup Transform Các Lookup Transform cho phép bạn thực hiện tương tự như inner hay outer hash join, sự khác biệt duy nhất là các hoạt động xử lý dữ liệu xảy ra bên ngoài phạm vi của cơ sở dữ liệu. Biến đổi này được sử dụng trong nhiều tình huống khác nhau, nhưng thường sẽ được sử dụng trong một quá trình ETL để tải dữ liệu cho Data Warehouse. Ví dụ, bạn có thể tạo ra một bảng bằng cách liên kết dữ liệu từ hai nguồn dữ liệu riêng biệt sử dụng các loại database khác nhau. 153

Đôi khi sẽ có một số hàng sẽ không liên kết thành công. Ví dụ, trong dữ liệu của bạn sẽ có thể có một sản phẩm mà không có lịch sử mua hàng do đó dữ liệu trong bảng product sẽ không “match” với bảng Sale. SSIS hỗ trợ vấn đề này bằng việc có nhiều output cho Lookup Transform; bạn có thể cấu hình output cho hàng “match” và một output khác cho các hàng không “match” và bị lỗi. Cache Modes Lookup transform cung cấp một vài phương thức hoạt động trong đó có sự đánh đổi giữa hiệu suất và mức độ sử dụng tài nguyên. Để cấu hình Lookup Transform, nhấp đúp vào nó để mở giao diện “Lookup Transformation editor”. Hình 5.24 thể hiện giao diện cấu hình cho Lookup transform trong đó bạn có thể chọn “cache mode” và nguồn dữ liệu.

Hình 0.24. Giao diện cấu hình cho Lookup Transform Trong chế độ “fullcache”, một trong hai bảng bạn đang thực hiện “join” sẽ được load toàn bộ vào bộ nhớ, sau đó các hàng từ bảng còn lại lần lược được đưa vào bộ đệm (buffer) và quá trình 154

“join” được thực hiện. Tuy nhiên, trong trường hợp các bảng tham chiếu được sử dụng để lookup quá lớn để có thể cache tất cả cùng một lúc trong bộ nhớ của hệ thống. Trong những trường hợp như vậy sẽ có hai lựa chọn: cache từng phần (Partical cache) hoặc không cache (No cache). 5.4.4.6. Một số công cụ biến đổi dữ liệu khác SSIS cung cấp rất nhiều công cụ chuyển đổi dữ liệu mà trong phạm vi tài liệu này không thể giới thiệu toàn bộ một cách chi tiết. Các công cụ chuyển đổi khác sẽ được trình bày tóm tắt bên dưới đây. Aggregate transform: Task này thực hiện chức năng tổng hợp dữ liệu như tính Average, Sum, Count, Max, Min cho một cột dữ liệu và xuất kết quả. Bên cạnh đó, transform này còn cho phép thực hiện GROUP BY để chỉ định các nhóm muốn tổng hợp dữ liệu. Conditional Split transform: Biến đổi này thực hiện phân chia dữ liệu dựa tùy vào nội dung của dữ liệu thỏa mãn điều kiện đặt ra. Transform này thực hiện việc phân chia có điều kiện tương tự như một cấu trúc quyết định CASE trong ngôn ngữ lập trình. Dựa vào biểu thức điều kiện để phân chia dòng dữ liệu đến các output được chỉ định. Trường hợp dữ liệu không thỏa mãn bất kỳ điều kiện nào sẽ được chuyển ra theo output mặc định. Derived Column transform: Task này tạo ra các giá trị cho cột mới bằng cách áp dụng biểu thức toán học cho dữ liệu cột input. Biểu thức toán học có thể chứa bất kỳ sự kết hợp của các biến, hàm, toán tử và các cột ban đầu. Kết quả có thể được thêm vào dưới dạng một cột mới hoặc chèn vào một cột hiện có với giá trị thay thế. Merge Transformation: Biến đổi này kết hợp hai bộ dữ liệu đã được sắp xếp thành một tập dữ liệu duy nhất. Các hàng từ mỗi bộ dữ liệu được thêm vào đầu ra của Transform dựa trên các giá trị trong các cột. 155

Merge Join Transformation:Transform này tạo ra output bằng cách “join” hai bộ dữ liệu đã được sắp xếp sử dụng FULL, LEFT hoặc INNER join. Ví dụ, bạn có thể sử dụng một LEFT join để thực hiện kết bảng chứa dữ liệu thông tin sản phẩm và bảng chứa dữ liệu vùng/quốc gia nơi sản xuất sản phẩm đó. Bảng kết quả sẽ liệt kê tất cả sản phẩm và vùng/quốc gia sản xuất. Multicast Transformation: Transform này phân phối dữ liệu input đến nhiều output. Biến đổi này cũng tương tự như Conditional Split transform. Cả hai biến đổi đều chuyển một đầu thành nhiều đầu ra. Sự khác biệt là Multicast phân phối tất cả các hàng cho các output còn Conditional Split phân phối từng hàng thỏa điều kiện cho một ouput chỉ định. OLE DB Command transform: Transform này thực hiện chạy một câu lệnh SQL cho mỗi hàng trong một dòng dữ liệu. Ví dụ, bạn có thể chạy một câu lệnh SQL inserts, updates, hoặc deletes các hàng trong một bảng cơ sở dữ liệu. Row count transform: Biến đổi này thực hiện đếm hàng trong một dòng dữ liệu và ghi lại kết quả để sau này sử dụng kết hợp với một Execute SQL Task. Kết quả đếm phải được đặt vào một biến, mà sau đó có thể được sử dụng trong Control Flow để chèn vào một bảng kiểm tra. Union All transform: Hợp nhất tất cả các dữ liệu input trong Data Flow để thành một tập hợp đầu ra duy nhất. Nó tương tự như Merge Transform, nhưng không yêu cầu các dữ liệu đầu vào phải được sắp xếp. 5.4.5.

i dữ liệu vào Data Wa ehouse

5.4.5.1. Tải dữ liệu cho bảng Dimension Slowly Changing Dimension (SCD) là một công cụ giúp đơn giản hóa quá trình tải dữ liệu cho bảng Dimension. Trước đi sâu vào Slowly Changing Dimension Wizard, bạn cần hiểu một số thuật ngữ trước. SCD có thể tải dữ liệu cho ba loại Dimension: Type 0, Type và Type 2 như trình bày dưới đây: 156

 Type 0 (Fixed Attribute): Cột dạng này sẽ có giá trị cố định và không cho ph p người dùng thay đổi dữ liệu, việc thay đổi sẽ gây ra lỗi. Ví dụ như cột số chứng minh nhân dân… Ngay cả khi giá trị dữ liệu nguồn bị thay đổi thì sự thay đổi cũng sẽ không được cập nhật cho cột dạng Type 0.  Type 1 (Changing Attribute) cột dữ liệu được xử lý cập nhật nhưng không thực hiện theo dõi lịch sử thay đổi nghĩa là không cần tạo thêm dữ liệu để ghi nhận lịch sử thay đổi.  Type 2 (Historical Dimension) cột dữ liệu dạng Type 2 sẽ được theo dõi sự thay đổi. Khi có một cập nhật cho dữ liệu cột Type 2, dữ liệu sẽ cập nhật vào một record mới, và dữ liệu của record cũ vẫn được giữ lại và được ghi nhận là “outdated”. Một thuật ngữ nữa mà bạn cần làm quen là “inferred members”. Khi bạn tải dữ liệu cho một bảng sự kiện nhưng dữ liệu của bảng chiều tương ứng lại không tồn tại, ví dụ bạn tải mẫu tin giao dịch bán hàng vào bảng sự kiện nhưng dữ liệu sản phẩm tương ứng không tồn tại trong bảng chiều. Tình huống này có thể xảy ra khi bảng lấy dữ liệu sản phẩm từ một server và dữ liệu bán hàng từ một server khác, và server chứa dữ liệu sản phẩm tạm thời bị lỗi trong khi server chứa dữ liệu bán hàng vẫn hoạt động tốt. Khi đó dữ liệu bán hàng vẫn được cập nhật trong khi không cập nhật được bảng dữ liệu sản phẩm. Trong trường hợp này, quá trình tải dữ liệu vào bảng sự kiện sẽ tạo thêm một “stub record” (mẫu tin chưa có dữ liệu) trong bảng chiều. “Inferred members” chính là record được tạo ra trong bảng chiều trong tình huống này. Khi việc cập nhật dữ liệu cho bảng chiều từ nguồn đã được thông suốt, Transform sẽ thực hiện cập nhật cho bảng chiều theo dạng Type đã trình bày ở trên. 157

Hình 0.25. Giao diện Slowly changing Dimension Wizard Để sử dụng “Slowly Changing Dimension Wizard”, đầu tiên bạn nên tạo ra một kết nối Source và Destination Destination trong Connection Manager, sau đó tạo một Source trong Data Flow. Sau đó k o SCD Transform vào cửa sổ Data Flow và kết nối nó với Source. Sau khi kết nối nó với một Source hay một transform khác, bấm đúp vào biểu tượng SCD Transform để mở giao diện “Slowly Changing Dimension Wizard”. Giao diện đầu tiên (hình 5.25) chỉ định destination mà bạn muốn tải dữ liệu. Đầu tiên, chọn Destination connection manager, sau đó đến bảng dữ liệu và thực hiện ánh xạ cột dữ liệu nguồn đến cột dữ liệu đích. Cuối cùng, hãy chọn một cột làm business key. (Primary key từ bảng dữ liệu nguồn đôi khi còn được gọi là alternate key hoặc business key). 158

Trong giao diện tiếp theo (hình 5.26), chúng ta cần chỉ định Type (Fixed Attribute, Changing Attribute, Historical Attribute) cho mỗi cột trong bảng Dimension. Các cột Type 0,1 hoặc 2 đã được trình bày ở phần trên. Trong hình 5.26, cột List Price sẽ được chọn type là “Historical attribute” để ghi nhận lại lịch sử biến đổi giá.

Hình 0.26. Giao diện thiết lập Change type cho bảng Dimention Trong giao diện hình 5.26, nếu có bất kỳ cột nào được chọn giá trị Change Type là Historical attribute thì sẽ có một vài giao diện như hình 5.27 sẽ yêu cầu bạn thiết lập phương thức ghi nhận lịch sử thay đổi. Ở phần trên của giao diện cho phép bạn thiết lập một cột để ghi nhận các giá trị Expired, Active hay bất cứ tên gì bạn muốn. Ở phần dưới giao diện cho phép bạn thiết lập ngày bắt đầu và kết thúc để nhận dạng trạng thái của các dòng là Expired hay Active. Bạn cũng có thể không cần thiết lập ngay các giá trị này vì các thiết lập này có thể chỉnh sửa lại sau trong SCD Task. 159

Hình 0.27. Giao diện thiết lập tùy chọn Historical Attribute 5.4.5.2. Tải dữ liệu cho bảng Fact Việc tải dữ liệu cho bảng Fact nhìn chung dễ dàng hơn nhiều so với bảng Dimension. Thông thường chỉ cần thực hiện thêm mẫu tin vào bảng (insert) và không cần thực hiện thao tác xóa hoặc cập nhật cho các dòng. Trong bảng Fact, dữ liệu sẽ có chứa các khóa tự nhiên (Natural key hay còn còn gọi là Alternate key hoặc business key), đây là khóa giúp xác định mối liên hệ giữa bảng Dimenssion và bảng Fact. Tuy nhiên trong Data Warehouse, bảng Fact và bảng Dimension sẽ liên kết với nhau sử dụng khóa thay thế (surrogate key) như đã trình bày trong chương 4. Bạn sẽ phải thay thế các business key bằng các khóa thay thế sử dụng trong bảng Dimension. Bạn sẽ phải tra cứu business key trong bảng Dimension và tìm khóa thay thế tương ứng (surrogate key). Sau đó bảng Fact sẽ được lưu trữ theo khóa thay thế này. Việc tra cứu và tìm khóa thay thế để lưu vào nội dung bảng Fact được thực hiện nhờ Lookup Transforms. 160

Bạn có thể bổ sung thêm cột vào bảng Fact. Ví dụ, bạn có thể muốn thêm cột lợi nhuận trong bảng Fact, nhưng nguồn dữ liệu của bạn chỉ có cột chi phí Cost và cột giá bán SellPrice. Trong Data Flow bạn có thể sử dụng Derived Column Transform trong đó bạn thiết lập công thức tính lợi nhuận để tạo nên cột lợi nhuận mới. Một tác vụ khác cũng thường được sử dụng là tổng hợp dữ liệu từ bảng Fact. Bạn có thể tạo ra một bảng Fact với các cột là ProductID, Date, và SaleAmount. Để có dữ liệu doanh số bán hàng theo ngày (SaleAmount), bạn cần tổng hợp dữ liệu doanh số bán hàng cho mỗi sản phẩm theo ngày cho tất cả các khách hàng. Bạn có thực hiện điều này bằng cách sử dụng Aggregate Transform. Bạn sẽ phải thực hiện Group By theo ProductID, thiết lập toán tử Max cho cột ngày và Sum cho cột SaleAmount. Bạn cũng có thể thực hiện yêu cầu này bằng cách Group By trong câu lệnh SQL khi bạn lấy dữ liệu từ nguồn. Sau khi đã xử lý dữ liệu cần thiết và tra cứu khóa thay thế tương ứng, dòng dữ liệu sẽ được tải vào Data Warehouse sử dụng OLE DB Destination với cách ánh xạ cột dữ liệu tương ứng. Một quá trình tải dữ liệu cho bảng Fact được thể hiện như trên hình 5.28.

Hình 0.28. Tải dữ liệu cho bảng Fact 161

5.5. Thực hành SSIS v i CSDL AdventureWorks Phần này sẽ trình bày quá trình thực hiện tích hợp dữ liệu từ dữ liệu nguồn lấy từ cơ sở dữ liệu AdventureWorks vào Data Warehouse được thiết kế dạng bông tuyết (hình 5.29). Trong CSDL AdventureWorks, FactSalesQuota thể hiện hạn mức về doanh số đặt ra cho mỗi nhân viên theo thời gian. Đây là dữ liệu để đánh giá KPI của từng nhân viên bán hàng. Trong thiết kế DW trên hình 5.29, ở mỗi bảng chiều (DimEmployee, DimSalesTerritory, DimDate), các khóa thay thế (surrogate key) sẽ được gọi là Dimension Key và các khóa dự tuyển (candidate key) sẽ được gọi là Dimension AlternateKey. Các khóa thay thế là khái niệm quan trọng nhất trong nhà kho dữ liệu, vì nó cho phép theo dõi các lịch sử thay đổi cũng như tối ưu hóa cấu trúc dữ liệu để tăng hiệu suất. Thông thường, khóa thay thế trong bảng chiều sẽ được thiết lập thuộc tính auto-increment.

Hình 0.29. Thiết kế Data Warehouse cho bảng FactSalesQuota 162

5.5.1.1. Thực hiện ETL cho bảng Dimension Quá trình ETL cho các bảng Dimension bao gồm các mục tiêu sau: - Xác định khóa chính của dữ liệu nguồn và ánh xạ các khóa này vào các khóa thay thế. - Thực hiện biến đổi dữ liệu để sắp xếp và phần bổ dữ liệu nguồn vào cấu trúc các bảng Dimension. - Xử lý vấn đề thêm hoặc cập nhật các record cho bảng chiều khi dữ liệu nguồn bị thay đổi. Độ phức tạp của quá trình ETL cho bảng chiều tùy thuộc vào yêu cầu có cần theo dõi lịch sử thay đổi các dữ liệu khi thực hiện cập nhật cho bảng chiều hay không. Trong các tình huống phức tạp, việc cập nhật dữ liệu cho bảng chiều đòi hỏi tốn nhiều thời gian để phân tích, thiết kế và thử nghiệm nhằm mục đích theo dõi lịch sử thay đổi dữ liệu, cập nhật records có thuộc tính “inferred member” và nhiều tác vụ khác nữa. Hơn nữa, nếu bảng chiều có kích càng lớn và càng phức tạp thì các công việc xử lý, biến đổi sẽ càng phức tạp để đảm bảo theo dõi và ghi nhận lịch sử thay đổi của dữ liệu cũng như đảm bảo dữ liệu không bị lỗi. Như đã trình bày ở trên, SSIS có tích hợp một công cụ biến đổi dữ liệu gọi là Slowly Changing Dimension (SCD) để hỗ trợ thực hiện cấu hình từng bước trong quá trình tải dữ liệu cho bảng chiều. Đây cũng là công cụ hữu ích hỗ trợ việc tải dữ liệu cho các bảng chiều có các cột cần theo dõi lịch sử thay đổi dữ liệu. Phần này sẽ trình bày quá trình tích hợp dữ liệu trong trường hợp đơn giản cho bảng chiều không cần theo dõi lịch sử thay đổi. Một số bảng chiều như bảng Sales Territory chỉ có một vài cột và không có cột nào cần phải theo dõi lịch sử nên quá trích tích hợp dữ liệu sẽ không quá phức tạp. Bảng DimSalesTerritory sẽ lấy dữ liệu từ bảng [Sales].[SalesTerritory] trong CSDL AdventureWorkse. Bất kỳ sự thay đổi nào dữ liệu nào của ba cột 163

này đều sẽ được cập nhật vào bảng chiều. Các cột này sẽ được thiết lập thuộc tính “Changing attributes” để cho phép cập nhật dữ liệu từ nguồn.

Hình 0.30. Thiết kế Data Flow Trình tự thiết kế Data Flow (hình 5.30) để thực hiện ETL cho bảng DimSalesTerritory như sau: 1. Tạo một package có tên là ETL_DimSalesTerritory.dtsx trong project hiện tại hoặc tạo một project mới sau đó tạo package. 2. Tạo hai kết nối OLE DB trong project, một đến cơ sở dữ liệu AdventureWorks và một đến AdventureWorksDW để sử dụng cho mục đích trích xuất và tải dữ liệu ở các bước tiếp theo. 3. Kéo một Data Flow Task mới từ Toolbox vào luồng điều khiển, sau đó nhấp vào Data Flow Task để chuyển qua giao diện thiết kế Data Flow. 4. Thêm OLE DB Source vào giao diện thiết kế Data Flow, cấu hình OLE DB: trong mục Connection Manager kết nối AdventureWorks database, thiết lập chế độ data access là “Table or view.”, trong mục “Name of the table or the view” chọn [Sales]. [SalesTerritory] (hình 5.31). 164

Hình 0.31. Cấu hình kết nối cho OLE DB Source 5. Trong giao diện danh mục Columns, (hình 5.32), trong cột Output column, thay đổi tên cột TerritoryID thành SalesTerritoryAlternateKey, Name thành SalesTerritoryRegion và Group thành SalesTerritoryGroup để phù hợp hơn trong bảng DimSalesTerritory, click Ok để lưu thiết lập. 6. Thêm một Lookup Transformation vào Data Flow và kết nối với OLE DB Source như hình 5.30. Trong giao diện General của Lookup Transformation (hình 5.33), cấu hình như sau: Cache mode: Full catch, Connection type: OLE Connection Manager. Tiếp tục trong giao diện Connection, thiết lập OLE DB Connection Manager là AdventureWorks, mục “Use a table or a view thay đổi thành [Person].[CountryRegion].

Hình 0.32. Cấu hình Columns cho OLE DB Source 165

Hình 0.33. Thiết lập thông số cơ bản cho Lookup Transformation 7. Trong giao diện Columns của Lookup Transformation (hình 5.34), kéo thả để kết nối hai cột CountryRegionCode trong bảng Available Input Columns và Available Lookup Columns lại với nhau, sau đó chọn vào check box cột Name trong Available Lookup Columns. Thay đổi “Output Alias” cho cột „Name” thành SalesTerritoryCountry và nhấn Ok để lưu cấu hình. Kết thúc bước số 7, việc cấu hình để ánh xạ các cột của dữ liệu nguồn vào các cột trong bảng Dimension đã hoàn tất. Các bước tiếp theo là những bước cốt lõi của một quá trình xử lý sử dụng SCD Transformation. 8. Tiếp tục thêm Changing Dimension Transformation từ hộp công cụ và dòng dữ liệu và kết nối đầu ra của Lookup Transformation với SCD Transformation như thiết kế của hình 5.30. Khi kết nối với SCD, sẽ có một thông báo yêu cầu chọn lựa Output cho Lookup, chọn “Lookup Match Output” và nhấn OK. 166

Hình 0.34. Thiết lập Columns trong Lookup Transformation 9. Nhấp đúp vào SCD Transfomation để thực hiện cấu hình cho SCD. Trong giao diện chọn bảng Dimension để tải dữ liệu (hình 5.35), chọn Connection manager là AdventureWorksDW, mục Table or view chọn [dbo].[DimSalesTerritory] và trong cột SalesTerritoryAlternateKey thay đổi Key type là Business key.

Hình 0.35. Chọn bảng Dimension và khóa trong SCD Wizard 167

10. Trong giao diện tiếp theo của SCD wizard, thực hiện thiết lập Change Type cho các cột. Trong trường hợp của bảng DimSalesTerritory, cả ba cột đều có thể sẽ thay đổi giá trị nếu nguồn dữ liệu thay đổi, do đó chọn Change type là “changing attributes” (hình 5.36)

Hình 0.36. Thiết lập Change Type cho các cột của bảng Dimension 11. Giao diện tiếp theo giao diện hình 5.36 có tên gọi là “Fixed and Changing Attribute Options” sẽ cho phép bạn cấu hình những record nào sẽ cập nhật khi dữ liệu nguồn bị thay đổi. Trong trường hơp này, tùy chọn“Fixed attributes” sẽ chuyển sang màu xám vì trong giao diện hình 5.36 không có cột nào được chọn là “Fixed attributes”. Trong tùy chọn “Changing attributes”, bạn có thể chọn cập nhật giá trị thay đổi từ nguồn dữ liệu cho tất cả các record có candidate key giống nhau hoặc chỉ cập nhật cho record mới nhất. Tuy nhiên, không có sự khác biệt nào giữa hai tùy chọn này vì ứng với mỗi candidate key chỉ có một record duy nhất do không có cột nào được thiết lập thuộc tính “Historical” trong bảng này. Chúng ta bỏ qua tùy chọn này để chuyển sang giao diện tiếp theo. 168

12. Trong giao diện “Inferred Dimension Members” tiếp theo, bạn có thể kích hoạt tính năng hỗ trợ Inferred Members để tạo thêm một record tương ứng trong bảng chiều trong tình huống thực hiện tải dữ liệu cho bảng sự kiện mà dữ liệu tương ứng trong bảng chiều không tồn tại. 13. Sau khi kết thúc SCD wizard, đầu ra của SCD Transformation sẽ được tự động thiết lập một số kết nối tùy vào thiết lập của người dùng (hình 5.37)

Hình 0.37. Data Flow cho quá trình ETL bảng DimSalesTerritory 14. Do DimSalesTerritory là một bảng chiều khá đơn giản do đó chỉ có hai kết quả đầu ra. Output thứ nhất được gọi là New Output dùng để thêm các record mới vào bảng Dimension trong trường hợp candidate key từ nguồn dữ liệu không “match” với các khóa trong bảng chiều. Output thứ hai được gọi là Changing Attribute Updates Output, sẽ được sử dụng trong trường hợp nguồn dữ liệu thực hiện thay đổi giá trị các record cũ, lúc này OLE DB command được sử dụng như câu lệnh SQL UPDATE để cập nhật dữ liệu vào bảng chiều. 169

5.5.1.2. Thực hiện ETL cho bảng sự kiện Quá trình ETL cho bảng sự kiện thường đơn giản hơn so với bảng chiều vì bảng sự kiện thường chỉ có liên quan đến việc Insert dữ liệu, đôi khi là Update. Tuy nhiên, dữ liệu trong bảng sự kiện thường rất lớn, do đó bạn cần xử lý insert dữ liệu từng phần và xử lý tình huống Update trong một số trường hợp. Quá trình ETL cho bảng sự kiện thông thường bao gồm các nhiệm vụ sau: - Chuẩn bị dữ liệu nguồn phù hợp với độ mịn thiết kế của bảng sự kiện. - Xác định các khóa thay thế (surrogate keys) cho tất cả các chiều. - Tạo các record mới cho bảng sự kiện (hoặc cập nhật trong một số trường hợp). Quá trình ETL cho bảng FactSalesQuota tương đối dễ dàng thông qua các bước sau: 1. Tạo một package ETL_FactSalesQuota.dtsx.

mới

và

đặt

tên

là

2. Giống như phần ETL cho bảng Dimension, tạo hai kết nối một đến dữ liệu nguồn là Database AdventureWorks, một đến dữ liệu đích là AdventureWorksDW. 3. Tạo mới một Data Flow Task cho quá trình ETL và trong giao diện thiết kế Data Flow, thêm một OLE DB Source và đặt tên là Sales Quota Source. Cấu hình OLE DB Source để kết nối đến cơ sở dữ liệu AdventureWorks và thay đổi data access mode là SQL Command như trên hình 5.38. Thêm đoạn mã sau vào cửa sổ SQL command text:

170

SELECT QuotaDate, SalesQuota, NationalIDNumber as EmployeeNationalIDAlternateKey FROM Sales.SalesPersonQuotaHistory INNER JOIN HumanResources.Employee ON SalesPersonQuotaHistory.BusinessEntityID = Employee.BusinessEntityID

Hình 0.38. Cấu hình OLE DB Source thực hiện ETL bảng Fact 4. Để lấy được surrogate keys từ các bảng Dimension, sử dụng Lookup Transformation. Thêm một Lookup Transformation và kết nối đầu ra OLE DB Source đến đầu vào của Lookup Transformation và đổi tên lại thành LookupEmployee Key. Sau đó nhấp đúp vào Lookup Employee Key, trong mục General, cấu hình Cache mode là “Full cach” và Connection type là “OLEDB Connection manager”. Tiếp theo trong danh mục Connection, trong mục OLE DB Connection Manager chọn AdventureWorksDW và thêm đoạn mã sau để lấy ra các surrogate key tương ứng với các nhân viên đang làm việc. 171

SELECT EmployeeKey, EmployeeNationalIDAlternateKey FROM DimEmployee WHERE EndDate IS NULL 5. Tiếp tục cấu hình cho LookupEmployee Key, trong giao diện Columns kết nối cột EmployeeNationalIDAlternateKey từ “input columns” đến “lookup columns” và đánh dấu vào checkbox của EmployeeKey như hình 5.39 và nhấn OK để kết thúc.

Hình 0.39. Giao diện Column trong Lookup Transformation 6. Đối với cột DateKey, không cần thiết sử dụng công cụ Lookup vì DateKey là cột có giá trị nguyên (integer) theo dạng format YYYYMMDD. Vì thế, có thể dùng Derived column để tính giá trị Date Key cho bảng sự kiện. Thực hiện thêm mới Derived Column Transformation vào giao diện thiết kế Data Flow và kết nối với đầu ra (mũi tên xanh) của Task LookupEmployee Key. 7. Thực hiện cấu hình cho Derived Column Transformation như sau: tạo thêm ba cột mới với các biểu thức toán học như sau (hình 5.40): 172

 DateKey: YEAR([QuotaDate]) *10000 + MONTH([QuotaDate]) *100 + DAY([QuotaDate])  CalendarYear: (DT_I2) YEAR([QuotaDate])  CalendarQuarter: (DT_UI1) DATEPART(“q”,[QuotaDate])

Hình 0.40. Cấu hình Derived Column Transformation Sau bước 7, dữ liệu đã sẵn sàng để tải vào bảng Fact. Trường hợp nếu dữ liệu được trích xuất từ nguồn chỉ là các record mới thì bạn có thể dụng OLE DB Destionation để tải dữ liệu ngay vào bảng Fact. Tuy nhiên, trong trường hợp các dữ liệu nguồn bị chỉnh sửa và cần cập nhật lại dữ liệu cho bảng Fact thì chúng tra phải xác định record nào mới cần insert, record nào cũ cần update và xử lý dữ liệu một cách hợp lý. Các bước tiếp theo sẽ giải quyết vấn đề update hay insert. Để xử lý vấn đề update cho bảng Fact, tác vụ “Merge Join” sẽ được sử dụng để kết hợp các record từ nguồn dữ liệu và các 173

record hiện tại trong bảng Fact dựa vào khóa EmployeeKey, sau đó nhận dạng record nào đã tồn tại trong bảng Fact sẽ xử lý update, record nào không tồn tại sẽ xử lý insert. Trước khi thêm Merge Join, bạn cần thêm Sort Transformation để sắp xếp các record trước khi thực hiện kết hợp (Merge Join chỉ thực hiện được trên dữ liệu đã được sắp xếp).

Hình 0.41. Data Flow 8. Thêm một Sort Transformation vào Data Flow và kết nối nó với dòng dữ liệu màu xanh đầu ra của Derived Column Transformation (hình 5.41). Tiếp theo, thực hiện cấu hình cho Sort Transformation để sắp xếp dữ liệu đầu vào theo thứ tự ưu tiên các cột sau: EmployeeKey, CalendarYear, and CalendarQuarter (hình 5.42). CalendarYear và CalendarQuarter là hai cột quan trọng để xác định độ mịn của bảng Fact. 174

Hình 0.42. Giao diện cấu hình Sort Transformation 9. Thêm một OLE DB Source mới vào dòng dữ liệu và đặt tên là Sales Quota Fact, cấu hình OLE DB Source kết nối đến AdventureWorksDW đã thiết lập trong Connection Manager và sử dụng dòng lệnh SQL sau đây để lấy các dữ liệu cần thiết: SELECT EmployeeKey, CalendarYear, CalendarQuarter, SalesAmountQuota FROM dbo.FactSalesQuota ORDER BY 1,2,3 10. Trong câu lệnh SQL sử dụng ORDER BY (sắp xếp ba cột đầu tiên theo thứ tự), chúng ta phải cấu hình cho OLE DB Source nhận biết dữ liệu đi vào Data Flow đã được sắp xếp. Đầu tiên, sau khi cấu hình cho OLE DB Source, nhấn OK để lưu cấu hình. Sau đó click chuột phải lên “Sales Quota Fact” Task và click vào “Show Advance Editor”, trong cửa sổ “Input and Output”, nhấn vào đối tượng OLE DB Source Output và sau đó thay đổi thông số “IsSorted” thành True như trên hình 5.43. 175

Hình 0.43. Cấu hình nâng cao cho OLE DB Source Output 11. Tiếp tục mở rộng OLE DB Source Output, vào mục Output Columns và thay đổi các thông số như sau (hình 5.44): (a) Chọn cột EmployeeKey và thay đổi SortKeyPosition thành 1; (b) Cột CalendarYear và thay đổi SortKeyPosition thành 2; (c) Cột CalendarQuarter và thay đổi SortKeyPosition thành 3.

Hình 0.44. Cấu hình Output column cho Sales Quota Fact Source 176

12. Thêm một Merge Join Transformation vào Data Flow và kết nối với đầu ra của Sort Transformation. Khi kết nối, chọn loại kết nối là “Merge Join Left Input”, sau đó tiếp tục kết nối đầu ra của Sales Quota Fact Source vào Merge Join. Nhấp đúp vào Merger Join để cấu hình, bạn sẽ thấy ba cột EmployeeKey, CalendarYear và CalendarQuarter đã được kết nối sẵn. Thực hiện một số thay đổi như sau (hình 5.45): (a) John type là Left outer join; (b) Chọn vào checkbox các cột SalesQuota, EmployeeKey, DateKey, CalendarYear, CalendarQuarter và QuotaDate trong danh sách sort input và thay đổi Output Alias cho cột QuotaDate là Date; (c) Chọn vào checkbox cột SalesAmountQuota từ danh sách Sales Quota Fact và thay đổi Output Alias cho cột này thành SalesAmountQuota_Fact.

Hình 0.45. Cấu hình Merge Join Transformation 177

13. Bước tiếp theo là nhận dạng records nào là mới, record nào là cũ để thực hiện Insert hay Update. Tác vụ Conditional split được sử dụng để thực hiện việc này. Thực hiện thêm Conditional Split Transformation vào Data Flow và kết nối vào đầu ra của Merge Join Transformatiom. Sau đó cấu hình cho Conditional Split như sau (hình 5.46): (a) Thêm vào một Output mới tên New Fact Records v i điều kiện: ISNULL([SalesAmountQuota_Fact]). Nếu giá trị SalesAmountQuota từ bảng Fact là Null nghĩa là record tương ứng ở bảng Fact không tồn tại. (b) Thêm một Output thứ 2 tên là Fact Updates v i điều kiện: [SalesQuota] != [SalesAmountQuota_Fact]. (c) Thay đổi Default output name là No Changes.

Hình 0.46. Cấu hình cho Conditional Split Transformation 14. Thêm một OLE DB Destination vào Data Flow và đặt tên là Fact Inserts. Kết nối đầu ra của Conditional Split Transformation vào OLE DB Destination và khi có bảng thông báo hiển thị yêu cầu chọn ouput từ Conditional Split, hãy chọn New Fact Records output. Tiếp tục cấu hình cho Fact Inserts Destination và thay đổi OLE DB Connection Manager để kết nối đến AdventureWorksDW. Trong mục “Name of the table or 178

view”, chọn bảng [dbo].[FactSalesQuota]. Sau đó chuyển qua mục Mappings và thực hiện ánh xạ cột SalesQuota từ danh sách Available Input Columns đến SalesAmountQuota trong danh sách Available Destinations (hình 5.47). Các cột khác như EmployeeKey, DateKey, CalendarYear, CalendarQuarter đã được tự động ánh xạ. 15. Để thực hiện xử lý việc cập nhật dữ liệu cho bảng Fact, thêm OLE DB Command Transformation vào Data Flow và đổi tên thành Fact Updates. Kết nối dòng dữ liệu màu xanh đầu ra của Conditional Split đến Fact Updates Transformation và khi có thông báo chọn lựa Output hiển thị, chọn Fact Update output. Nhấp đúp vào OLE DB Command Transformation để thực hiện cấu hình. Trong mục Connection Manager, chọn AdventureWorksDW, trong tab “Component Properties” thêm đoạn mã sau vào mục SQLCommand: UPDATE dbo.FactSalesQuota SET SalesAmountQuota = ? WHERE EmployeeKey = ? AND CalendarYear = ? AND CalendarQuarter = ?

Hình 0.47. Giao diện Mappings của Fact Inserts Destination 179

16. Tiếp tục cấu hình cho OLE DB Command Transformation, chuyển qua tab Column Mappings và ánh xạ SalesQuota đến Param_0, Employee_Key đến Param_1, CalendarYear đến Param_2 và CalendarQuarter đến Param_3 như hình 5.48 và nhấn Ok để lưu cấu hình và kết thức quá trình thiết kế Data Flow. Quá trình thiết kế ETL cho bảng FactSalesQuota sau khi hoàn thành sẽ có dạng như hình 5.49.

Hình 0.48. Column Mappings cho Fact Updates Command

Hình 0.49. Thiết kế Data Flow thực hiện ETL cho bảng FactSalesQuota 180

Câu hỏi và bài tập 1.

Tích hợp dữ liệu là gì? Hiện nay có bao nhiêu phương pháp tiếp cận và công nghệ tích hợp dữ liệu phổ biến?

2.

Hãy trình bày các giai đoạn của tiến trình tích hợp dữ liệu ETL.

3.

Trình bày khái niệm về Task, Data Flow, Control Flow trong SSIS.

4.

Trình bày những khác biệt trong quá trình tải dữ liệu vào Data Warehouse giữa bảng Dimension và bảng Fact.

5.

Dựa vào hướng dẫn quá trình ETL trong mục 5.5, hãy tiếp tục thực hiện quá trình ETL để tải dữ liệu cho bảng DimEmployee trong thiết kế Data Warehouse hình 5.28.

181

Chương 7 CHỈ SỐ ĐO LƯỜNG HIỆU SUẤT KINH DOANH Key performace indicators (viết tắt là KPIs) là một thành phần quan trọng trong Business Intelligence do KPIs là một tập hợp rất nhiều chỉ số tạo nên thẻ điểm (scorecard) nhằm thể hiện nhiều khía cạnh khác nhau trong phân tích hoạt động kinh doanh, cụ thể là giá trị tài chính, hiệu năng, nguy cơ và tiềm năng. Chính vì vậy, KPIs có thể hỗ trợ tích cực đối với phân tích Business Intelligence. Thay vì Business Intelligence dashboard chỉ tập trung trình bày các bảng biểu, đồ thị, thì việc thể hiện thêm các giá trị KPIs sẽ giúp cảnh báo, nhắc nhở, theo dõi xem quá trình kinh doanh có điều gì bất thường hay đang trong quá trình ổn định. Nhờ có KPIs, một lần nữa, việc phân tích trở nên dễ dàng hơn với những con số cụ thể và phù hợp với từng nghiệp vụ kinh doanh. Từ đó, người quản lý có thể đánh giá sơ bộ về tình hình chung và đưa ra những quyết định cho hoạt động tương lai của doanh nghiệp. Chương này sẽ giới thiệu về KPIs và cách thức xây dựng KPIs trong doanh nghiệp để thúc đẩy hiệu quả hoạt động. 7.1. Tổng quan về KPIs KPIs là một công cụ hữu hiệu trong việc xác định và đo lường tất cả hoạt động kinh doanh, nghiệp vụ trong tổ chức. Nhiệm vụ của KPI là đảm bảo quá trình vận hành theo đúng mục tiêu và định hướng kinh doanh của tổ chức đó. Sau khi xác định sứ mệnh và mục tiêu kinh doanh, tổ chức cần đưa ra phương thức đo lường các hoạt động cần thực hiện để đạt được 240

mục tiêu đề ra, với mục đích cuối cùng là hoàn thành đúng về mặt thời gian và đúng yêu cầu. KPIs là thước đo định lượng phản ánh các yếu tố thành công (critical success factors) và đối với từng tổ chức khác nhau sẽ có KPIs riêng biệt. Khái niệm định lượng được hiểu như là dễ dàng xác định, thống kê, tính toán và trình bày bằng những con số. Đối với tổ chức hoạt động kinh doanh thì KPIs được thể hiện dưới dạng doanh số hay lợi nhuận bán hàng kỳ vọng theo từng tháng, từng quý, … Mặt khác, tổ chức giáo dục lại xây dựng KPIs là tỷ lệ sinh viên tốt nghiệp mỗi năm hay phần trăm sinh viên bỏ học tại các khóa, … Bên cạnh đó, trong cùng một tổ chức vẫn tồn tại nhiều KPIs khác nhau đối với từng phòng ban. Chẳng hạn như bộ phận kinh doanh xây dựng KPIs về mức độ tăng trưởng doanh thu hay hiệu quả kinh doanh từ các nhóm/dòng sản phẩm, bộ phận chăm sóc khách hàng đặt KPIs là thời gian trả lời các cuộc gọi tính theo đơn vị thời gian phút hay tỷ lệ khách hàng hài lòng khi sử dụng dịch vụ này. KPIs được định nghĩa dựa trên hai khái niệm: (1) lựa chọn các chỉ số đại diện cho hoạt động của doanh nghiệp, (2) có khả năng trình bày dưới dạng các con số thể hiện sự khác biệt giữa thực tế và mong đợi (Sanchez & Robert, 2010). Do KPIs là các thước đo hoạt động hiệu quả, vì thế KPIs cần được cập nhật liên tục để phù hợp với sự thay đổi về quy mô và phát triển của tổ chức và có thể được thay thế (Ghalayini & Noble, 1996). Đối với công ty có quy mô nhỏ như một chi nhánh ở một tỉnh thì KPIs là doanh thu bán hàng kỳ vọng tại chi nhánh đó. Đến khi phát triển thêm nhiều chi nhánh ở nhiều tỉnh, KPIs cần có sự thay đổi thành doanh thu bán hàng ở từng tỉnh để có thể so sánh mức độ hoàn thành giữa các khu vực địa lý khác nhau. Thực tế vẫn xảy ra nhiều trường hợp phải thay thế KPIs cũ không còn phù hợp với mục tiêu kinh doanh của tổ chức. Chẳng 241

hạn như khi bắt đầu giới thiệu sản phẩm mới thì doanh nghiệp đặt KPI là số lượng khách hàng đặt mua trên từng nhóm sản phẩm hay số lượng đơn hàng theo từng khoảng thời gian. Nhưng khi sản phẩm đã phát triển ở một thị trường trong một khoảng thời gian nhất định thì KPI cần được thay đổi để đánh giá sự hài lòng và tiếp tục dùng sản phẩm từ người tiêu dùng. Có thể thấy được là trong thời gian đầu tổ chức chỉ tập trung vào số lượng bán sản phẩm, và đo lường hiệu quả kinh doanh bằng doanh số. Tuy nhiên, khi sản phẩm tồn tại trên thị trường thì sẽ gặp nhiều sản phẩm thay thế hoặc của đối thủ cạnh tranh, lúc này KPI cần được điều chỉnh lại là mức độ hài lòng của khách hàng và tỷ lệ tiếp tục sử dụng sản phẩm. KPI càng cao thì càng thể hiện hoạt động kinh doanh càng tốt. Bởi vì tổ chức sẽ giảm được nhiều chi phí trong việc marketing, dịch vụ sau bán hàng, … 7.2. Đặc điểm của KPIs 7.2.1. Thước đo phi tài chính KPIs là các thước đo phi tài chính, không chỉ tập trung vào các con số liên quan đến tài chính được diễn đạt với những mệnh giá tiền bạc như dollar, pound, euros, … mà KPIs còn tập trung vào các chỉ số đánh giá chuyên sâu về hoạt động kinh doanh của doanh nghiệp như số lượng truy cập vào website bán hàng, thời gian xử lý đơn hàng tính theo đơn vị phút, … 7.2.2. Đo lường thường xuyên KPIs được đo lường thường xuyên, liên tục 24/7 hoặc mỗi ngày hoặc mỗi tuần. Tuy nhiên, không nên đặt ra KPIs với thời gian dài như mỗi tháng, mỗi quý, mỗi năm bởi vì với thời gian dài thì rất khó để đạt được mục tiêu. Cụ thể là, nếu đặt ra KPIs gần với thời gian hiện tại thì mỗi nhân viên sẽ có động lực và biết được chính xác họ cần làm gì để đạt được chỉ số đề ra. Tiếp 242

đó, mỗi ngày họ đều có thể so sánh giữa kết quả đạt được với yêu cầu ban đầu để nắm rõ xem hiệu quả hoạt động đã phù hợp hay chưa. Bên cạnh đó, kết quả trong quá khứ không được coi là KPIs mà chỉ được gọi là đánh giá hoạt động đã diễn ra. KPIs phải là thước đo của hiện tại và tương lai, chẳng hạn như số lượng khách hàng ghé thăm website trong tháng tới hay số lượng khách hàng tiếp tục mua những dòng sản phẩm … 7.2.3. Đối tượng sử dụng KPIs KPIs là công cụ hỗ trợ hoạt động quản trị hiệu quả, vì thế các nhà quản lý, điều hành, CEO sẽ là đối tượng trực tiếp theo dõi và điều chỉnh KPIs. 7.2.4. Điều chỉnh hoạt động kinh doanh Như đã đề cập ở 7.2.2 thì KPIs được đo lường thường xuyên để so sánh giữa thực tế và kỳ vọng ban đầu. Cho nên, nếu như thực tế không đạt được yêu cầu của kỳ vọng thì nhà quản lý cần điều chỉnh cách thức hoạt động để nâng cao hiệu quả kinh doanh và đạt được KPIs đề ra. 7.2.5. Gắn kết trách nhiệm rõ ràng KPIs cần được thiết kế chi tiết để ấn định cho từng cá nhân trong tổ chức. Vì thế, khi không đạt được kỳ vọng đặt ra thì nhà quản lý có thể quy trách nhiệm cho một cá nhân hay nhóm làm việc. 7.2.6. Ảnh hưởng tích cực của KPIs Khi đạt được một KPI, kết quả này sẽ ảnh hưởng tích cực đến KPIs khác. Chẳng hạn như số lượng khách hàng hài lòng với dịch vụ hỗ trợ khách hàng sẽ làm tăng sự hài lòng của người sử dụng, vì thế họ sẽ tin dùng những sản phẩm/dịch vụ của công ty hơn và kết quả là mức độ tăng trưởng doanh thu của tháng tiếp theo sẽ tăng so với tháng hiện tại. 243

7.3. KPIs trong doanh nghiệp KPIs chính là kim chỉ nam cho doanh nghiệp nhằm đảm bảo mọi hoạt động đều hướng tới mục tiêu và sứ mệnh của tổ chức. Cho dù sử dụng nhiều hay ít thì KPIs phải luôn phản ánh mục tiêu chung của doanh nghiệp và phải là chìa khóa để doanh nghiệp đạt đến thành công và phải có khả năng đo lường được. Quan trọng là doanh nghiệp cần xây dựng số lượng KPIs vừa đủ để dễ dàng tập trung và thực hiện. Hình 7.1 thể hiện sự thay đổi khi tổ chức áp dụng KPIs để đo lường kết quả của các quy trình hoạt động kinh doanh.

Hình Error! No text of specified style in document..1. Ảnh hưởng của KPI lên kết quả của hoạt động trong tổ chức (Parmenter, 2001) Trước khi áp dụng KPIs thì định hướng hoạt động của các nhóm làm việc có sự khác biệt và dễ đi chệch hướng so với chiến lược chung của tổ chức. Do mỗi nhóm được lãnh đạo bởi nhà quản lý riêng và giữa các nhà quản lý không thống nhất được mục tiêu, chiến lược kinh doanh của tổ chức nên việc tổ chức nhóm làm việc rất khó kiểm soát, dẫn đến hậu quả là chiến lược của tổ chức dễ gặp thất bại. Tuy nhiên, sau khi áp dụng KPIs thì hoạt động của các nhóm đã được điều chỉnh và theo đúng với chiến lược kinh doanh. Lý do là KPIs sẽ giúp các nhóm nhận diện rõ ràng xem họ cần phải đạt được chỉ tiêu gì, 244

con số là bao nhiêu, và từ đó các nhóm sẽ hình thành kế hoạch hoạt động nhằm đạt được chỉ tiêu đó. Kaplan và Norton đã đề nghị rằng không được áp dụng nhiều hơn 20 KPIs. Vì thế, quy luật 10/80/10 là một định hướng tốt cho doanh nghiệp (Parmenter, 2015). Cụ thể là nên xây dựng khoảng 10 KRIs (Key result indicators), 80 Pis (Performance indicators) và 10 KPIs trong một tổ chức. Trong khi KPIs sẽ cho nhà quản lý biết cần làm thế nào để tăng hiệu quả hoạt động, thì KRIs cung cấp cái nhìn chi tiết hay hướng dẫn cho những hoạt động cần thực hiện để đạt thành công, còn PIs sẽ liệt kê những việc cần làm. Có thể nói, KPIs tập trung vào đo lường chi tiết các hoạt động để đạt được thành công hay mục tiêu đề ra. Còn KRIs báo cáo dựa trên các kết quả của các hoạt động bằng cách nhìn lại và trình bày những gì đã diễn ra và PIs sẽ ghi vết những hoạt động cụ thể. Vậy KPIs không kết luận về những gì đã đạt được, nhưng KRIs thì có thể, vì thế không thể tách rời KPIs, KRIs và PIs. 7.4. Xây dựng KPIs Các nền tảng trong xây dựng và vận dụng KPI trong tổ chức (Parmenter, 2015). 7.4.1. Nền tảng mối quan hệ cộng tác Việc hình thành mối quan hệ cộng tác hiệu quả giữa các nhà quản lý doanh nghiệp, nhân viên, khách hàng và nhà cung cấp chính mang đến thành công trong cải tiến hiệu quả hoạt động kinh doanh. Cụ thể là: (1) Nếu như có bất kỳ sự thay đổi về văn hóa, các vấn đề liên quan đến tổ chức và cách thức triển khai, thực hiện sự thay đổi thì đều đòi hỏi sự rõ ràng và chấp thuận giữa các nhà quản lý doanh nghiệp. 245

(2) Hình thành và duy trì những người đại diện cho các hội, công đoàn, nhân viên. (3) Phát triển chiến lược giới thiệu và phổ biến KPIs đến đối tượng khác trong tổ chức. (4) Mở rộng khái niệm mối quan hệ cộng tác bao gồm cả đối tượng khách hàng và nhà cung cấp chính của tổ chức. 7.4.2. Sức mạnh của hoạt động tiếp xúc trực tiếp với khách hàng Để đạt đến thành công trong kinh doanh luôn đòi hỏi sức mạnh tập thể, hay nói cách khác chính những cá thể trong tổ chức, mà đặc biệt là nhân viên thực hiện hoạt động tiếp xúc trực tiếp với khách hàng sẽ góp phần đem đến sự hài lòng cho khách hàng khi sử dụng sản phẩm, dịch vụ. Những nhân viên làm việc trực tiếp với khách hàng, đối tác bên ngoài chính là cầu nối giữa doanh nghiệp và khách hàng, là đại diện cho hình ảnh, thương hiệu của doanh nghiệp. Giá trị của doanh nghiệp, văn hóa doanh nghiệp, chất lượng dịch vụ hay sản phẩm của doanh nghiệp được khách hàng đánh giá thông qua thái độ và hành vi của các nhân viên này. Doanh nghiệp cần nâng cao sự giao tiếp hiệu quả giữa các nhân viên, đặc biệt là nhân viên tiếp xúc trực tiếp với khách hàng, giúp họ hiểu được vị trí, vai trò của công việc đang thực hiện, văn hóa, hoạt động của tổ chức và giá trị sản phẩm/dịch vụ cần đem đến cho khách hàng. Kế đến là sự rõ ràng trong phân quyền để nhân viên có thể chủ động trong khắc phục sự cố có thể làm ảnh hưởng xấu đến KPI. Chẳng hạn như sắp đến kỳ hạn phải bàn giao sản phẩm của dự án, nhưng nhân viên không đủ thời gian để hoàn thành tất cả công việc. Vì vậy, họ có thể đề nghị làm thêm giờ, nhờ vả sự hỗ trợ của đồng nghiệp khác hay chủ động đề nghị có thể loại bỏ một số chức năng của dự án để 246

thực hiện đúng kỳ hạn bàn giao sản phẩm. Tổ chức cần phát triển tinh thần chịu trách nhiệm của các nhóm làm việc và cho phép mỗi nhóm xây dựng, triển khai các thước đo hiệu quả hoạt động. Vấn đề này rất quan trọng bởi vì khi nhận thức trách nhiệm rõ ràng thì nhân viên sẽ hoạt động hiệu quả hơn và nỗ lực để thực hiện cũng như ít để xảy ra sai sót. Đồng thời, việc quy rõ trách nhiệm sẽ góp phần để việc thưởng phạt được công bằng. 7.4.3. Tích hợp các thước đo, báo cáo cải tiến hiệu quả hoạt động Các nhà quản lý cần xây dựng hệ thống thước đo hiệu quả hoạt động và quy trình báo cáo rõ ràng để cập nhật nhanh chóng về tình hình kinh doanh. Báo cáo có thể thực hiện hàng ngày, hàng tuần hay hàng tháng tùy thuộc vào mức độ quan trọng của báo cáo. Tổ chức cần phát triển cũng như hiệu chỉnh chiến lược cải tiến quy trình và các thước đo hiệu năng đúng thời điểm. Việc thực hiện đúng lúc sẽ góp phần điều chỉnh hoạt động, quy trình và định hướng hiệu quả của các nhóm làm việc. Hệ thống báo cáo có thể thay đổi, cập nhật để thể hiện thông tin cụ thể, phù hợp với đối tượng sử dụng và hỗ trợ tích cực cho việc ra quyết định. Có thể nói, báo cáo và thước đo hiệu năng rất quan trọng cho nhà quản lý, chúng không chỉ giúp thể hiện kết quả của quá trình hoạt động, mà còn là cơ sở cho những quyết định thay đổi, cải tiến trong tổ chức. Hệ thống thước đo hiệu năng của tổ chức cũng cần được thay đổi theo hệ thống thước đo ở cấp độ nhóm làm việc. Có thể hiểu rằng, kết quả hoạt động của tổ chức chính là kết quả chung của tập hợp nhóm làm việc khác nhau. 7.4.4. Liên kết thước đo hiệu năng với chiến lược của công ty Thước đo hiệu năng sẽ trở nên vô nghĩa nếu như chúng không được gắn kết với mục tiêu chiến lược kinh doanh của tổ 247

chức và với các chỉ số thành công được đặt ra. Tổ chức sẽ thành công hơn khi xác định và truyền tải sứ mệnh, tầm nhìn, mục tiêu và giá trị tổ chức đến với nhà quản lý và nhân viên. Trong đó, CEO là những người quan trọng trong lãnh đạo, truyền đạt và thúc đẩy các giá trị trong tổ chức. Hình 7.2 thể hiện sự liên kết giữa các yếu tố thành công (critical success factors), balanced scorecard (BSC) và mục tiêu của tổ chức.

Hình Error! No text of specified style in document..2. Liên kết giữa KPI với CSFs, BSC và mục tiêu của tổ chức (Parmenter, 2015) Để xây dựng KPIs trong tổ chức thì cần phải thực hiện chiến lược toàn diện bao gồm xác định rõ sứ mệnh, tầm nhìn, giá trị của tổ chức, CSFs, BSC, KPIs, KRIs và PIs. Khi xây dựng chiến lược cần phải xem xét 6 khía cạnh trong BSC bao gồm: kết quả tài chính (các báo cáo tài chính như bảng cân đối kế toán, báo 248

cáo thu nhập, báo cáo lợi nhuận giữ lại và báo cáo lưu chuyển tiền tệ; các chỉ số tài chính như thu nhập trên cổ phần EPS, tỷ suất sinh lời trên tài sản ROA, …), sự hài lòng của khách hàng, học tập và phát triển, quy trình nghiệp vụ nội bộ tổ chức, sự hài lòng của nhân viên và môi trường cộng đồng. Việc thực hiện kiểm tra chéo giữa chiến lược với các khía cạnh của BSC sẽ giúp nhận diện một số nội dung bị bỏ sót. Thông thường, tổ chức chỉ tập trung vào các chỉ số tài chính và sự hài lòng của khách hàng, bởi vì đây là những con số thể hiện sự hiệu quả trong hoạt động kinh doanh. Bên cạnh đó, khía cạnh môi trường rất ít được quan tâm, nhưng yếu tố này cũng rất quan trọng trong việc xây dựng hình ảnh của công ty. Muốn phát triển bền vững thì doanh nghiệp phải quan tâm đến môi trường và cộng đồng xung quanh. Không thể nào vì sản xuất mà làm ảnh hưởng đến môi trường sống của người dân, chính điều đó sẽ tạo nên sự phản đối, phẫn nộ từ cộng đồng và làm giảm uy tín của công ty. Mặt khác, nhiều tổ chức rất coi trọng sự hài lòng của nhân viên và điều này được xếp mức độ ưu tiên chỉ sau sự hài lòng của khách hàng. Lý do là khách hàng là người sẽ mang đến lợi nhuận cho tổ chức, còn nhân viên chính là người tạo ra sản phẩm, dịch vụ và giá trị mà từ đó cũng đem đến lợi nhuận. Cho nên, tổ chức cần xây dựng văn hóa làm việc, các chế độ ưu đãi, học tập, đào tạo, … để thúc đẩy động lực làm việc của nhân viên. Việc xác định các yếu tố thành công cốt lõi CSFs rất quan trọng bởi vì nó đưa ra các yếu tố nhằm kết luận về hoạt động hiệu quả của tổ chức. Cho nên, tại bước đầu tiên, cần đề nghị một số yếu tố được xem là cốt lõi có thể ảnh hưởng đến sự thành công trong hoạt động của tổ chức. Tiếp theo, dựa trên những yếu tố đề nghị có thể rút gọn bằng cách xem xét yếu tố nào quan trọng hơn và có ảnh hưởng đến các khía cạnh của BSC. Quay trở lại với hình 7.2, các khía cạnh trong BSC có tác động đến CSFs 249

và vì thế CSFs phải bao phủ một hay một vài các thành phần của BSC. Một khi đã xác định CSFs thì việc hình thành KPIs sẽ trở nên rất dễ dàng. Nói cách khác, CSFs cần phải được xác định trước khi xây dựng KPIs. Đồng thời, phương pháp xây dựng BSC trong tổ chức cần được xác định rõ ràng và KPIs, PIs và KRIs phải gắn kết với nhau. 7.4.5. Xác định tầm nhìn, sứ mệnh và chiến lược của tổ chức Ba khái niệm: tầm nhìn (vision), sứ mệnh (mission) và chiến lược (strategy) thường xuyên bị nhầm lẫn. Sứ mệnh được xem như là ngọn hải đăng không giới hạn thời gian, thể hiện rõ lý do mà tổ chức tồn tại và làm gì để duy trì hoạt động. Một tuyên bố về sứ mệnh rõ ràng cần phải thể hiện mục tiêu của tổ chức, tổ chức sẽ làm gì và phục vụ ai và các nguyên tắc, giá trị nào là kim chỉ nam cho các hoạt động của tổ chức. Trong khi đó, tầm nhìn thể hiện điều mà tổ chức muốn đạt được trong tương lai. Khác với sứ mệnh, tầm nhìn xác định khoảng thời gian cụ thể trong tương lai cho các mục tiêu phát triển của tổ chức. Chiến lược là cách thức mà tổ chức sẽ thực hiện để đạt được tầm nhìn đề ra. Trong môi trường cạnh tranh gay gắt thì chiến lược kinh doanh sẽ giúp tổ chức giành được lợi thế cạnh tranh với đối thủ, giúp xác định nguồn lực thực hiện để đạt được kết quả mong muốn. Vì vậy, khi xây dựng chiến lược đo lường hiệu quả hoạt động, cần phải xuất phát từ tầm nhìn, sứ mệnh và chiến lược của công ty, từ đó hình thành các khía cạnh BSC, CSFs và KPIs. 7.5. Triển khai KPIs trong phân tích dữ liệu Hệ thống báo cáo cần phải phù hợp với yêu cầu của nhiều cấp độ khác nhau trong tổ chức và phải đáp ứng kịp thời cho hoạt động ra quyết định.

250

7.5.1. Dashboard Dashboard là dạng báo cáo tổng hợp của một hay nhiều bảng biểu và biểu đồ, trong đó mỗi bảng biểu, biểu đồ trả lời cho một câu hỏi, một nội dung duy nhất. Dashboard nên thể hiện trên một trang giấy để tiện theo dõi. Bên cạnh đó, trên dashboard cần phải thể hiện KPIs để giúp người đọc, cụ thể ở đây là nhà quản lý, dễ dàng nhận diện hoạt động kinh doanh có đi đúng hướng với mục tiêu đề ra ban đầu hay không và mức độ đáp ứng kỳ vọng như thế nào.

Hình Error! No text of specified style in document..3. Sự hài lòng của top 10% khách hàng (Parmenter, 2015) Một số ví dụ về dashboard được thể hiện ở hình 7.3 (trình bày về sự hài lòng của top 10% khách hàng về sản phẩm/dịch vụ) và hình 7.4 (thể hiện sự hài lòng của nhân viên). Trong mỗi dashboard đều thể hiện kết quả của phần phân tích, tổng hợp dữ liệu để trả lời một câu hỏi cụ thể; vì vậy, nếu như có hơn hai câu hỏi thì cần sử dụng hai dashboard khác nhau. Hơn nữa, vẫn có thể đặt hai dashboard gần nhau để so sánh và bản báo cáo sẽ gồm nhiều dashboard nhỏ với mỗi dashboard trả lời cho một câu 251

hỏi riêng biệt. Nên hạn chế sự rối rắm ở phần thể hiện thông tin trên dashboard, không nên quá lạm dụng việc trình bày quá nhiều trên cùng một dashboard. Khi sử dụng dashboard nên có phần mô tả về ý nghĩa của dashboard như là dashboard phục vụ cho đối tượng nào, bao lâu sử dụng một lần, trả lời cho câu hỏi nào, …

Hình Error! No text of specified style in document..4. Sự hài lòng của nhân viên (Parmenter, 2015) 7.5.2. Báo cáo về các chỉ số đo lường hiệu năng Báo cáo về các chỉ số đo lường hiệu năng thường được sử dụng thường xuyên nên đòi hỏi về độ chính xác và cập nhật thông tin mới liên tục. Như đã đề cập ở trên, KPIs cần được báo cáo 24/7 hoặc hàng ngày, hàng tuần, để nhà quản lý nhanh chóng nắm bắt thông tin mới nhất về tình hình hoạt động kinh doanh, cũng như là thực tế có đạt được kỳ vọng đặt ra hay không. Có một số dạng báo cáo như: (1) Báo cáo hàng ngày: 252

Đây là loại báo cáo thực hiện hàng ngày hay 24/7. Báo cáo này thường dành cho việc theo dõi tiến độ hoạt động liên tục. Chẳng hạn như báo cáo thống kê tình hình hoạt động của các chuyến bay cần được cập nhật liên tục, có thể là hàng giờ hoặc hàng ngày, để nhà quản lý nắm rõ trong một ngày có bao nhiêu chuyến bay bị trễ giờ, lý do là gì, đã trễ bao nhiêu phút, tập trung vào những chuyến bay nào … Từ đó, người quản lý sẽ có quyết định đối với các chuyến bay, số máy bay, …

Hình Error! No text of specified style in document..5. Thống kê hoạt động của các chuyến bay (Parmenter, 2015) Lợi ích của các loại báo cáo hàng ngày là cung cấp thông tin liên tục, kịp thời gian cho nhà quản lý kịp thời đưa ra những quyết định đối với hoạt động kinh doanh. Tuy nhiên, loại báo cáo này đòi hỏi dữ liệu phải được cập nhật liên tục và có độ chính xác cao. (2) Báo cáo hàng tuần và hàng tháng: Khác biệt với báo cáo hàng ngày thì báo cáo hàng tuần hoặc hàng tháng được tổng hợp, phân tích cuối mỗi tuần hay mỗi tháng. Thông thường, các dạng báo cáo này thuộc dạng tổng kết để đánh giá hoạt động của nghiệp vụ trong một khoảng thời gian tương đối dài, chẳng hạn như hàng tuần, hàng tháng. Trong khi đó, báo cáo hàng ngày tập trung vào báo cáo tình hình thực tế, 253

cho biết diễn biến các hoạt động theo từng khoảng thời gian ngắn để có thể kịp thời nắm bắt những rủi ro, sai sót, trục trặc. 7.5.3. Báo cáo đánh giá hiệu năng dành cho nhân viên (1) Balanced Scorecard dành cho các nhóm hoạt động (Team Balance Scorecard): Đây là dạng báo cáo rất phù hợp cho quản lý dự án, quản lý nhóm bán hàng … Lý do là báo cáo này trình diễn tất cả KPIs cần thiết để dự án hay mục tiêu hoạt động được thành công. Xét vị trí của người quản lý dự án công nghệ thông tin, để dự án được thành công, nghĩa là đáp ứng đúng kỳ hạn bàn giao sản phẩm cho khách hàng, thì họ cần phải phân rã các công việc để đến cuối cùng, đảm bảo hoàn thành được sản phẩm yêu cầu. Tương ứng với mỗi công việc đã được chia nhỏ đều phải nêu rõ thời gian thực hiện, chất lượng yêu cầu,… đây đều có thể là những KPIs dành cho từng nhóm làm việc. Việc xác định KPIs càng rõ ràng thì càng giúp các nhóm hiểu rõ cần thực hiện gì, trong khoảng thời gian như bao lâu và yêu cầu kết quả ra sao, cũng như góp phần thúc đẩy động lực làm việc của các thành viên. Không chỉ xác định KPIs mà người quản lý dự án còn phải đảm bảo rằng những KPIs đó sẽ phải được đáp ứng, vì thế không thể đặt quá nhiều KPIs hay chọn KPIs không phù hợp với năng lực và thời gian.

254

Hình Error! No text of specified style in document..6. Team balance scorecard dành cho các hoạt động trong doanh nghiệp (Nguồn: performancemagazine.org) (2) Báo cáo hoạt động của tổ chức dành cho nhân viên Đây là dạng báo cáo hàng tháng với các biểu tượng icon thể hiện các khía cạnh của BSC trong tổ chức. Nhìn vào báo cáo sẽ dễ dàng nhận diện được tất cả những điểm mạnh, điểm yếu và có thể từ đó làm nền tảng để so sánh với các đối thủ. Từ đó, người quản lý nắm được những khía cạnh cần phát huy để đạt được mục tiêu đề ra và nhắc nhở nhân viên cần phải phát huy tốt những điểm mạnh và khắc phục mặt yếu kém.

255

Hình Error! No text of specified style in document..7. Báo cáo hoạt động tổ chức (Parmenter, 2015) (3) Biểu đồ Có thể sử dụng biểu đồ thay thế cho các bảng biểu. Trên một biểu đồ có thể thể hiện thông tin rất ngắn gọn, dễ hiểu và không nhàm chán. Một số lưu ý khi sử dụng biểu đồ thay thế cho bảng biểu: - Không phải tất cả bảng biểu nào cũng có thể thay thế bằng biểu đồ. Lý do là biểu đồ thể hiện thông tin rất ngắn gọn nên sẽ dành cho những báo cáo với ít thông tin và người đọc chỉ tập trung vào kết quả thống kê, phân tích 256

cuối cùng. Tuy nhiên, nếu cần chi tiết và phân tích kỹ hơn thì bảng biểu vẫn là lựa chọn tốt hơn. - Nếu thông tin được trình bày dưới dạng con số phần trăm thì nên sử dụng biểu đồ hình tròn (pie chart). Ngoài ra, biểu đồ hình tròn rất phù hợp thể hiện tỷ lệ phần trăm giữa các thành phần.

Hình Error! No text of specified style in document..8. Biểu đồ đường thể hiện số lượng truy cập và tiền lương hoạt động (Parmenter, 2015) - Biểu đồ đường (line chart) và biểu đồ cột (bar chart) thể hiện các xu hướng thay đổi theo khoảng thời gian. Tuy nhiên, nếu xu hướng thay đổi ở tỷ lệ nhỏ hoặc nếu cần so sánh giữa nhiều xu hướng khác nhau thì nên chọn biểu đồ đường. Bởi vì biểu đồ cột chỉ dành cho so sánh tối đa là 3-4 xu hướng, vì nhiều hơn sẽ rất khó theo dõi và rối rắm. - Biểu đồ vùng (area chart) gần tương tự như biểu đồ đường, dùng để ghi vết các thay đổi theo thời gian giữa một hay nhiều nhóm, xu hướng. Nhưng biểu đồ vùng phù hợp hơn trong trường hợp cần so sánh những nhóm có 257

liên hệ với nhau trong một tổng thể chung, từ đó dễ dàng nhận diện sự thay đổi của nhóm này sẽ ảnh hưởng đến nhóm kia như thế nào. 7.5.4. Một số thể loại KPIs ứng dụng trong phân tích Việc trình bày các chỉ số KPIs phụ thuộc vào đối tượng sử dụng và nghiệp vụ kinh doanh cần phân tích. Tuy nhiên, có một số dạng KPIs được sử dụng như sau (Aspin, 2015): (1) KPI Value: thể hiện dưới dạng chỉ số/hình ảnh đại diện cho thực tế của hoạt động kinh doanh và đây cũng là KPIs được sử dụng phổ biến trong doanh nghiệp. Tuy nhiên, KPI value không chỉ được thể hiện ở mức độ cơ bản, mà đối với KPI tổng hợp ở cấp độ cao thì đòi hỏi thao tác chuẩn bị, truy xuất dữ liệu phức tạp. (2) KPI Goal: thể hiện mục tiêu và chiến lược của tổ chức. Cụ thể là, trước tiên tổ chức xác định chính xác mục tiêu và chiến lược cần đạt trong khoảng thời gian nhất định; sau đó các chỉ số đo lường kết quả sẽ được xác định theo tiêu chí dễ đo lường và phù hợp nhất với mục tiêu đó. KPI có thể là con số cụ thể cần đạt hay phần trăm tăng hay giảm trong hoạt động. Bên cạnh đó, KPI cần chi tiết nhằm diễn tả toàn bộ mục tiêu đã đặt ra. (3) KPI Status: thể hiện mức độ hoàn thành tốt/xấu, đạt/không đạt trong hoạt động của tổ chức. Thông thường, KPI status được trình bày dưới dạng ký hiệu/tín hiệu chẳng hạn như đèn giao thông. Mặt khác, KPI còn được trình bày dưới dạng hình ảnh thể hiện sự thành công/thất bại đối với một phân tích cụ thể. Ngoài ra, KPI có thể là ký hiệu thay đổi màu sắc nhằm đề cập đến mức độ tốt, trung bình hoặc kém (hoặc dưới mức tiêu chuẩn cho phép cũng như là vượt xa yêu cầu đặt ra ban đầu). Bên cạnh đó, con số màu sắc/cấp độ thể hiện trong KPI có thể ít hay nhiều tùy thuộc vào người phân tích, 258

ví dụ như rất cao, cao, trung bình, thấp và rất thấp trong phân tích số lượng sản phẩm xuất bán hay tồn kho. Vì vậy, trong KPI status cần xác định ba yếu tố là giá trị, mục tiêu và ngưỡng cho phép. Trong đó, ngưỡng cho phép được xem như là lá cờ trạng thái trong KPI. Cụ thể như người phân tích đặt ra mục tiêu kinh doanh sản phẩm cụ thể là 120 triệu USD, đồng thời xác định ngưỡng cho phép tối thiểu là 50 triệu USD và trên thực tế doanh thu là 100 triệu USD. Vì vậy, cần so sánh con số thực tế là 100 với ngưỡng thấp nhất 50 và cao nhất là 120, nếu như thấp hơn 50 thì không chấp nhận được và cao hơn 120 là vượt qua mức mong đợi. Mặt khác, người phân tích có thể thiết lập nhiều ngưỡng cho phép nhằm xác định con số thực tế nằm trong khoảng như thế nào trong mục tiêu đặt ra ban đầu. (4) KPI trend: thể hiện những con số/xu hướng của thực tế và được so sánh với kết quả trong quá khứ. Đây là dạng KPI theo đơn vị thời gian nhằm đánh giá hoạt động của tổ chức trong một chuỗi thời gian quan sát. Tương tự như KPI status, KPI trend cũng gồm giá trị, mục tiêu và ngưỡng cho phép. Người phân tích đo lường con số thực tế và so sánh với giá trị cụ thể trong quá khứ. Con số so sánh trong quá khứ có thể dao động từ 2 đến tối đa là 9 giá trị, nếu nhiều hơn sẽ gây rối rắm và có thể sử dụng phương thức khác để so sánh. 7.6. Đánh giá hiệu quả KPIs 12 đặc điểm để tạo nên bộ chỉ số hiệu năng hiệu quả bao gồm (Shen, 2013): - Vì là công cụ đo lường hiệu quả hoạt động, nên KPIs cần phải được thiết kế theo định hướng về sứ mệnh, mục tiêu và chiến lược kinh doanh của tổ chức. Không thể sử dụng 259

KPIs hoàn toàn khác biệt với chiến lược kinh doanh hay mục tiêu hoặc sứ mệnh của doanh nghiệp vì nó không thể đo lường chính xác kết quả hoạt động. Nếu sử dụng những KPIs như vậy sẽ đưa ra những quyết định sai lầm. - KPIs được thiết kế và thuộc quyền sở hữu của cá nhân hay nhóm làm việc để họ có thể chủ động triển khai và ghi nhận kết quả. Thông thường, KPIs được nhà quản lý thiết kế và triển khai cho nhân viên, còn nhân viên sẽ nhận các KPIs và cố gắng hoàn thành nó. - KPIs cần mang tính dự báo tương lai bởi vì nó được xem như là kim chỉ nam cho hoạt động của công ty. - KPIs phải thể hiện dữ liệu mang tính hành động, nghĩa là chứa đựng thông tin cho người sử dụng đo lường được hiệu quả hoạt động kinh doanh và cải thiện hoạt động trước khi quá trễ cũng như là tránh được thiệt hại, tổn thất trong tương lai. KPIs phải mang tính chất trách nhiệm, nghĩa là nhìn vào kết quả của KPIs thì có thể nhận biết được cá nhân hay nhóm nào hoạt động chưa tốt. Bên cạnh đó, KPIs phải được cập nhật thường xuyên để cho cá nhân hay nhóm có thể theo dõi và cải tiến kịp thời. - Thể hiện dưới dạng số ngắn gọn. - Dễ hiểu. - Tính liên kết được đánh giá cao khi các KPIs có thể liên kết với nhau để đánh giá tổng thể tất cả các mặt trong tổ chức. Nếu như có quá nhiều KPIs riêng biệt, không có liên hệ gì đến với những KPIs còn lại thì cần xem xét về tính phù hợp của những KPIs này. - KPIs là điều kiện khởi đầu cho mọi sự thay đổi. Như đã đề cập ở trên, KPIs thể hiện tình hình tốt hay xấu trong các hoạt động của tổ chức, vì thế nó sẽ là điều kiện kích 260

hoạt cho những cải tiến sau này nhằm đạt được yêu cầu được đặt ra. - KPI cần được định nghĩa rõ ràng về cách thức tính toán, ý nghĩa của con số đối với hoạt động kinh doanh. - KPIs cần mang ý nghĩa phù hợp với bối cảnh sử dụng, nghĩa là khi xây dựng KPIs cho phòng ban kinh doanh thì cần sử dụng chỉ số đo lường hiệu năng liên quan đến chất lượng dịch vụ/sản phẩm, khách hàng, … - KPIs có thể được thay đổi, thay thế theo thời gian để phù hợp với sự phát triển của công ty và của nhóm hay cá nhân. - KPIs cần mang tính chất khuyến khích và động viên nhân viên, không nên áp đặt KPIs quá khó hay vượt xa khả năng thực hiện của nhân viên. Kết luận Chỉ số đo lường hiệu quả hoạt động - KPIs - được xem như là kim chỉ nam cho hoạt động của tổ chức, nó giúp đo lường hiệu quả của tất cả hoạt động kinh doanh diễn ra hàng ngày và được thể hiện dưới dạng con số rất đơn giản. KPIs phần lớn dành cho nhà quản lý với mục đích là đo lường thường xuyên về tình hình hoạt động kinh doanh cũng như là chất lượng hoạt động của các nhóm làm việc. Từ đó, nhà quản lý sẽ có những quyết định kịp thời nhằm thay đổi, cải tiến quy trình để đáp ứng được yêu cầu đặt ra ban đầu. KPIs còn có ý nghĩa thúc đẩy hoạt động của các nhóm làm việc, là động lực và cơ sở để phát huy sự sáng tạo và phát triển cá nhân. Vì vậy, sử dụng KPIs phù hợp sẽ mang lại nhiều lợi ích cho tổ chức, cả về sự hài lòng của nhân viên và hoạt động kinh doanh. Câu hỏi 1.

KPIs là gì? Cho ví dụ.

2.

Tại sao tổ chức cần sử dụng KPIs? 261

3.

Trình bày các loại KPIs được sử dụng trong doanh nghiệp, cho ví dụ.

4.

Anh/chị hãy trình bày một số KPIs được sử dụng tại trong nghiệp vụ bán hàng (Sales), quản lý kho (Inventory management) của doanh nghiệp bán lẻ (Retailers).

262

Chương 8 NHÀ KHO DỮ LIỆU TRONG THỜI ĐẠI BIG DATA 8.1. Giới thiệu Một trong những lĩnh vực nghiên cứu và ứng dụng đang chiếm được sự chú ý trong lĩnh vực công nghệ thông tin và Internet trong thời gian gần đây là “Big Data” (dữ liệu lớn). Hai từ này kết hợp với nhau lần đầu tiên và được phổ biến rộng rãi trên tạp chí bởi công ty McKinsey & Co., và từ đó hình thành định nghĩa về Big Data đầu tiên bởi Doug Laney từ Công ty Gartner. Một trong những lý do cơ bản thúc đẩy “Big Data” trở thành lĩnh vực được quan tâm hiện nay là việc các nền tảng công nghệ đã phát triển và nổi lên trong thời gian gần đây, cung cấp khả năng xử lý dữ liệu với nhiều định dạng và cấu trúc mà không phải lo lắng về những hạn chế liên quan đến các hệ thống và nền tảng cơ sở dữ liệu truyền thống. Kho dữ liệu đã có nhiều bước phát triển để hỗ trợ quá trình ra quyết định nhờ vào khả năng có thể thu thập, lưu trữ và quản lý dữ liệu, áp dụng phương pháp truyền thống để thống kê và tạo ra các báo cáo, phân tích phục vụ cho nhà quản lý. Các dữ liệu thu thập trong một kho dữ liệu thường có cấu trúc và ít sự linh hoạt hơn so với sự thay đổi của dữ liệu trong sự phát triển hiện nay. Những tiền đề cơ bản cho điều này là do những nguồn dữ liệu cho một kho dữ liệu thường là từ cơ sở dữ liệu giao dịch của doanh nghiệp hay tổ chức. Điều này hoàn toàn phù hợp khi chúng ta nói về mô hình giao dịch dựa trên hoạt động tạo ra bởi khách hàng trong lĩnh 261

vực bán lẻ, tài chính hoặc các ngành công nghiệp. Ví dụ, doanh thu bán vé xem phim là một giao dịch đơn giản, và sự thành công của một bộ phim có thể được dựa trên doanh thu mà nó tạo ra sau khi công chiếu trên rạp vài tuần, và trong một giai đoạn sau đó là doanh thu từ băng đĩa hay các kênh bán hàng khác. Các báo cáo doanh thu này có thể đã không bao gồm đặc điểm nhân khẩu học của khách hàng, cảm tình của khách hàng, đánh giá và phản hồi về bộ phim hay các thông tin vĩ mô khác để giúp việc ra quyết định trong hệ thống kho dữ liệu truyền thống. Trong khi đó, việc ra quyết định sẽ hữu ích hơn nếu có thể tích hợp các dữ liệu có cấu trúc, bán cấu trúc, phi cấu trúc hoặc các hình thức khác của dữ liệu có thể tác động đến doanh thu từ một bộ phim. Hệ thống quản lý cơ sở dữ liệu quan hệ (RDBMS) và các gói phần mềm truyền thống thường gặp khó khăn trong việc xử lý khối lượng dữ liệu lớn và đa dạng các loại định dạng. Công việc này có thể đòi hỏi cách thức xử lý song song chạy trên hàng chục, hàng trăm, thậm chí hàng ngàn máy và đảm trách nhiều hoạt động phân tích phức tạp như hệ thống Hadoop. Các mô hình kinh doanh và cơ hội đi kèm cùng với sự phát triển dựa trên quy mô lớn của dữ liệu đòi hỏi các mô hình phân tích để trích xuất được thông tin từ số đông và lớn để làm cơ sở cá nhân hóa dịch vụ trong từng thời điểm. Thách thức này không chỉ có với các công ty công nghệ, mà các công ty đa quốc gia như P&G và Unilever, các công ty vừa và nhỏ cũng muốn các giải pháp có thể xử lý các loại dữ liệu đó. Thêm vào đó, họ cũng muốn lấy đầu ra từ xử lý dữ liệu lớn và đưa vào nền tảng phân tích hiện hữu của họ. Nhiều công ty lớn đầu tư vào các giải pháp công nghệ quản lý dữ liệu, cho phép xử lý khối lượng lớn dữ liệu trong một khoảng thời gian ngắn với nhiều định dạng với độ phức tạp khác nhau. Do đó, phần tiếp theo trong chương này sẽ thảo luận về việc xây dựng các kho dữ liệu và định hướng phát triển của chúng trong thời đại Big Data. 262

8.2. Giới thiệu về Big Data Năm 2001, nhà phân tích Doug Laney của META Group (tên hiện nay là Gartner) trong một báo cáo nghiên cứu của mình đã xác định những thách thức và cơ hội của việc tăng trưởng dữ liệu với ba chiều được đặc trưng bởi sự tăng dung lượng (số lượng dữ liệu), tốc độ (tốc độ dữ liệu vào và ra) và đa dạng (định dạng của các loại dữ liệu và nguồn dữ liệu), còn gọi là ba V (ba chữ V). Các ngành công nghiệp hiện nay sử dụng định nghĩa này như một tiêu chuẩn để phân loại Big Data. Big Data có thể được định nghĩa như là khối lượng dữ liệu lớn và có nhiều mức độ phức tạp khác nhau, tạo ra với tốc độ khác nhau, mức độ đa dạng của dữ liệu không rõ ràng, và không thể được xử lý bằng những công nghệ, phương pháp xử lý, thuật toán truyền thống. Dữ liệu được gọi là Big Data bao gồm dữ liệu do máy móc tạo ra như từ các hệ thống cảm biến, các nhà máy hạt nhân, tia X-quang và các thiết bị quét, động cơ máy bay và dữ liệu trên các phương tiện truyền thông mạng xã hội. Nó cũng bao gồm các nguồn tạo ra dữ liệu tồn tại trong tổ chức như các quy định, bán hàng, tiếp thị, mua sắm, tài chính, và các bộ phận nguồn nhân lực. 8.2.1. Tại sao phải quan tâm đến Big Data trong thời điểm hiện nay? Sự hứa hẹn được kỳ vọng ở Big Data là việc khai phá những dữ liệu lớn có thể hữu ích trong việc đạt được những hiểu biết quan trọng từ những hành vi duy nhất hoặc lặp đi lặp lại ẩn chứa trong dữ liệu. Quá trình khám phá này có thể được thực hiện như một quá trình mà máy tự quản lý (hay máy tự khám phá) với sự can thiệp tối thiểu của con người, làm cho việc phân tích đơn giản hơn và ít sai sót hơn. Ngay nay, với sự sẵn có của cơ sở hạ tầng kết hợp với các mô hình và nền tảng xử lý dữ liệu như 263

Hadoop và NoSQL, việc triển khai một giải pháp Big Data có thể đạt được với chi phí thấp và khả năng mở rộng cao hơn đáng kể so với các nền tảng quản lý dữ liệu truyền thống. Trong thực tế một phần dữ liệu của Big Data luôn hiện diện và đã được sử dụng trong việc ra quyết định thông qua việc thu thập, xử lý và phân tích bằng con người. Chẳng hạn việc tập hợp ý kiến, phản hồi, bình luận hay góp ý về một sản phẩm hay một đối thủ cạnh tranh được tập hợp và phân tích để cải tiến hay phát triển sản phẩm của công ty. Điều thay đổi và tạo ra tiếng vang với thời đại Big Data là khả năng xử lý các loại dữ liệu như vậy một cách tự động với tốc độ nhanh, khả năng mở rộng và có thể xử lý linh hoạt trong thời gian thực. 8.2.2. Sự bùng nổ dữ liệu Điều gì đã dẫn đến sự bùng nổ dữ liệu này? Một câu trả lời là sự đổi mới (innovation). Sự đổi mới đó đã làm thay đổi cách chúng ta tham gia vào kinh doanh, cung cấp dịch vụ, và cách đo lường liên quan đến giá trị và lợi nhuận. Ba xu hướng cơ bản đã định hình ra thế giới dữ liệu trong vài năm qua là sự chuyển đổi mô hình kinh doanh, toàn cầu hóa, và cá nhân hóa dịch vụ. Dưới đây sẽ trình bày chi tiết các điều này. - Sự chuyển đổi mô hình kinh doanh. Mô hình kinh doanh cơ bản đã được biến đổi bởi sự toàn cầu hóa và kết nối toàn cầu. Các công ty đã chuyển từ định hướng sản phẩm thành định hướng dịch vụ, trong đó giá trị của tổ chức theo quan điểm của khách hàng được đo bằng hiệu quả dịch vụ chứ không phải bởi tính hữu dụng của sản phẩm. Những biến đổi này đòi hỏi mỗi doanh nghiệp cần phải sản xuất nhiều dữ liệu hơn về sản phẩm và dịch vụ để phân tích và đáp ứng nhu cầu cho mỗi phân khúc và mỗi kênh khách hàng, và cũng cần nhiều dữ liệu từ mối liên hệ với khách hàng như: phương tiện truyền thông mạng xã hội, khảo sát, điều tra, diễn đàn, thông tin phản 264

hồi trực tiếp, trung tâm chăm sóc khách hàng, nghiên cứu thị trường và nhiều thứ khác. - Sự toàn cầu hóa. Toàn cầu hóa là một xu hướng quan trọng đã làm thay đổi nền thương mại thế giới một cách mạnh mẽ, từ sản xuất đến dịch vụ khách hàng. Toàn cầu hóa cũng đã tạo ra nhiều các định dạng dữ liệu và gia tăng tốc độ dữ liệu. - Cá nhân hóa dịch vụ. Chỉ số trưởng thành của việc chuyển đổi mô hình kinh doanh được đo bằng mức độ cá nhân hóa của các dịch vụ và giá trị cảm nhận của khách hàng từ việc chuyển đổi này. Đây là nguyên nhân chính thúc đẩy sự tăng trưởng của tốc độ dữ liệu khi từng cá nhân đều có thể trở thành người tạo ra dữ liệu. - Công nghệ và các nguồn dữ liệu mới. Với sự phát triển công nghệ thông tin trong những thập kỷ qua, ngày càng có nhiều dữ liệu xung quanh từ thiết bị di động, các loại cảm biến, các bảng ghi hệ thống (log file), phương tiện truyền thông xã hội và phương tiện truyền thông mới. Cùng với sự xuất hiện của mô hình kinh doanh mới và phát triển mạnh mẽ của công nghệ lưu trữ và xử lý dữ liệu trong thập kỷ qua đã mở đường cho việc tích hợp tất cả các dữ liệu của doanh nghiệp thành một nền tảng toàn diện, từ đó tạo ra một hệ hỗ trợ ra quyết định kinh doanh có ý nghĩa cao và mang tính ngữ cảnh. 8.2.3. Một số đặc điểm của Big Data Dung lượng dữ liệu (Data volume) Dung lượng dữ liệu được đặc trưng bởi lượng dữ liệu được tạo ra liên tục. Các kiểu dữ liệu khác nhau có kích thước khác nhau. Ví dụ, một văn bản blog chỉ một vài Kilobyte; cuộc gọi thoại hoặc các tập tin video có thể là một vài Megabyte; dữ liệu cảm biến, các bản ghi máy, và các dữ liệu từ chuỗi click chuột có thể bằng hàng Gigabyte. Trước đây, người nhân viên tạo ra 265

dữ liệu. Ngày nay, đối với một tổ chức nhất định thì khách hàng, đối tác, đối thủ cạnh tranh, và bất cứ ai khác đều có thể tạo ra dữ liệu. Dung lượng dữ liệu lớn là một đặc điểm quan trọng của Big Data, tuy nhiên nó chỉ là một khía cạnh chứ Big Data không phải là dung lượng dữ liệu lớn. Tốc độ dữ liệu (Data velocity) Với sự ra đời của Big Data, sự hiểu biết về tốc độ sản sinh dữ liệu là vô cùng quan trọng. Lý do cơ bản cho điều này xuất phát từ thực tế là trong những ngày đầu của xử lý dữ liệu, người ta đã thường phân tích dữ liệu theo lô, và tập hợp lại theo thời gian. Thông thường, dữ liệu được chia thành những gói có kích thước cố định và xử lý thông qua các lớp (layer) từ nguồn dữ liệu tới mục tiêu phân tích, và kết quả cuối cùng được lưu trữ trong một kho dữ liệu để sử dụng tiếp trong các báo cáo và phân tích. Trong trường hợp của Big Data, luồng dữ liệu đi vào một cách liên tục và các kết quả chỉ có ích khi được tập hợp lại và xử lý với độ trễ đủ ngắn. Điều này trở thành nhu cầu quan trọng đối với một hệ thống có thể thu nhận dữ liệu và xử lý với tốc độ cực cao, có khả năng mở rộng lớn và hoàn tất nhiệm vụ trong thời gian tương đối nhỏ. Các mô hình kinh doanh như Amazon, Facebook, Yahoo và Google, đã trở thành mô hình kinh doanh tiêu biểu cho các công ty hoạt động dựa trên nền web, trên thực tế bằng cách theo dõi nhấp chuột của khách hàng và trên các trang web khách truy cập có thể cung cấp cách sử dụng trình duyệt cá nhân và kinh nghiệm mua sắm.Trong quá trình này của dòng nhấp chuột, dữ liệu của hàng triệu lần nhấp chuột được thu thập từ người sử dụng tại mỗi giây, lượng thông tin được xử lý với khối lượng rất lớn. Tốc độ của dữ liệu được tạo bởi người dùng khi nhấp vào bất kỳ trang web nào là một ví dụ điển hình cho tốc độ sản sinh ra dữ liệu trong Big Data. 266

Một ví dụ điển hình của tốc độ dữ liệu đến từ một loạt các cảm biến như hệ thống GPS, hệ thống áp suất. Các dữ liệu được tạo ra từ các mạng cảm biến có thể dao động từ vài gigabyte mỗi giây đến terabyte mỗi giây. Ví dụ, một chuyến bay từ London tới New York tạo ra 650 TB dữ liệu từ các cảm biến động cơ máy bay. Cách phổ biến nhất để chia sẻ hình ảnh, âm nhạc, và các dữ liệu hiện nay là thông qua các thiết bị di động. Các khối lượng dữ liệu được truyền qua mạng di động cung cấp những hiểu biết để các nhà cung cấp nắm và quản lý năng lực của mạng di động của họ, số lượng dữ liệu xử lý ở mỗi công đoạn, thời gian trong ngày, các khu vực địa lý có liên quan, sử dụng nhân khẩu học, địa điểm, thời gian trễ, và nhiều thứ khác. Tốc độ sản sinh và di chuyển dữ liệu nếu không thể dự đoán trước đôi khi có thể gây ra sự sụp đổ của mạng di động. Một điều nữa trong Big Data là các trang web truyền thông xã hội khác nhau sản xuất và cung cấp dữ liệu ở tốc độ khác nhau và trong nhiều định dạng khác nhau. Trong khi Twitter được cố định ở 140 ký tự, Facebook, YouTube, Flickr có thể có bài viết với các kích cỡ khác nhau từ cùng một người dùng. Không chỉ là kích thước của bài viết quan trọng, biết được bao nhiêu lần bài viết được chuyển tiếp hoặc chia sẻ và bao nhiêu người theo dõi bài viết… là những dữ liệu cần được thu thập để xử lý toàn bộ tập dữ liệu. Đa dạng dữ liệu (Data variety) Big Data được tạo thành với nhiều định dạng, nhiều loại từ email đến tweets trên phương tiện truyền thông mạng xã hội, dữ liệu văn bản, dữ liệu âm thanh, hình ảnh, video hay các dữ liệu từ thiết cảm biến. Trong nhiều trường hợp, không thể kiểm soát định dạng dữ liệu đầu vào hoặc các cấu trúc dữ liệu được sản sinh ra. 267

Sự phức tạp của quá trình sản sinh dữ liệu cùng với sự đa dạng các định dạng dữ liệu làm cho siêu dữ liệu (metadata) trở nên quan trọng khi xử lý hình ảnh, âm thanh, video và các văn bản có dung lượng lớn. Sự không tồn tại của siêu dữ liệu có thể làm triệt tiêu khả năng xử lý dữ liệu cũng như gặp khó khăn trong việc tích hợp các kết quả của nó vào các kho dữ liệu.

Hình Error! No text of specified style in document..1. Các đặc điểm của Big Data Ngày nay, khi nói về các đặc điểm của Big Data, ngoài khía cạnh 3V (Volume - Velocity - Variety) ở trên người ta vẫn còn đề cập đến tính xác thực (Veracity) và tính giá trị (Value) của dữ liệu. Tính xác thực đề cập đến sự tin cậy của dữ liệu. Với nhiều loại dữ liệu lớn, chất lượng và độ chính xác rất ít được kiểm soát nhưng với kỹ thuật phân tích Big Data hiện nay cho phép làm việc với các loại dữ liệu với dung lượng lớn bù đắp cho sự thiếu chất lượng hay độ chính xác. Và giá trị là yếu tố quan trọng vì cho dù người ta có quyền truy cập vào khối dữ liệu lớn, nhưng nếu không thể biến nó thành giá trị thì khối dữ liệu cũng trở thành vô ích. Vì vậy, điều quan trọng là các doanh nghiệp phải biết khai thác và biến những hiểu biết thu được từ dữ liệu lớn 268

thành sáng kiến kinh doanh thì mới nhận được hiệu quả đầu tư của mình. 8.3. Khi nào nên chọn Big Data và khi nào chọn Kho dữ liệu? Có rất nhiều quan điểm và tranh luận về việc khi nào thì nên xây dựng hệ thống Big Data và khi nào thì nên xây dựng Kho dữ liệu? Nếu đang có Kho dữ liệu thì có nên xây dựng mới hệ thống Big Data không? Rất khó để có câu trả lời thống nhất cho từng câu hỏi này, mà cần phải xem xét yêu cầu kinh doanh của doanh nghiệp khi lựa chọn giải pháp. Trong khi có những trường hợp ngoại lệ cho mọi nguyên tắc, công nghệ Big Data và Kho dữ liệu được tối ưu hóa cho các mục đích khác nhau. Nói cách khác, mục đích là sử dụng các giải pháp Big Data hay Kho dữ liệu cho những gì nó đã được thiết kế để làm. Dưới đây sẽ trình bày sự so sánh giữa Big Data và Kho dữ liệu. Bảng Error! No text of specified style in document..1. So sánh giữa Công nghệ Big Data và Kho dữ liệu Yêu cầu kinh doanh

Kho dữ liệu Big Data

Khám phá những câu hỏi chưa biết Dữ liệu sạch, đồng nhất và chất lượng cao Đáp ứng nhanh, báo cáo tương tác, OLAP Dữ liệu thô, dữ liệu phi cấu trúc Phân tích các dữ liệu sơ bộ

- Khám phá những câu hỏi chưa biết. Công nghệ Big Data như Hadoop giúp nhận diện quy luật (hay mẫu, hình ảnh pattern recognition) và công việc “khám phá (discovery)” rất nhanh trong một môi trường dữ liệu lớn. Nhờ đó, có thể phát hiện những mối liên hệ, những câu hỏi chưa biết nhờ khai thác 269

các mối quan hệ tiềm ẩn bên trong tập dữ liệu lớn. Trong khi Kho dữ liệu cũng có thể làm công việc khám phá, nhưng cơ sở dữ liệu quan hệ và ngôn ngữ SQL không thể đủ tối ưu để phân tích và so sánh giữa các tập dữ liệu lớn và phi cấu trúc. - Dữ liệu sạch, đồng nhất và chất lượng cao. Dữ liệu được dùng trong các kho dữ liệu thường ở dạng có cấu trúc đã được làm sạch, đồng nhất và chất lượng cao. Nhiều kho dữ liệu cũng đã được tích hợp chức năng làm sạch dữ liệu bên trong. Các dữ liệu được sử dụng để phân tích phải có ý nghĩa cho người dùng cuối. Tuy nhiên, trong các môi trường Big Data, nhiều dữ liệu được cung cấp ở dạng “thô” (raw) hoặc định dạng phi cấu trúc, thậm chí rất nhiều dữ liệu rác từ các bộ phận thu thập dữ liệu tự động. Do đó, hệ thống Big Data thường được xây dựng để thực hiện nhiều công việc tiền xử lý, làm sạch và nâng cao chất lượng dữ liệu. - Đáp ứng nhanh, báo cáo tương tác, OLAP. Kho dữ liệu thường được biết đến như là giải pháp với sự đáp ứng nhanh và cung cấp các báo cáo tương tác. Công nghệ Big Data với đặc thù xử lý khối lượng dữ liệu lớn, đa dạng và phát sinh không ngừng, có thể không tạo ra được sự đáp ứng nhanh và cung cấp báo cáo tương tác như Kho dữ liệu. Dù vậy, với những công cụ trực quan mới, công nghệ dữ liệu lớn cũng đang tạo ra một sự thay thế thú vị để xuất các báo cáo trực tiếp trên nền tảng dữ liệu lớn. - Dữ liệu thô, dữ liệu phi cấu trúc. Công nghệ dữ liệu lớn được bổ trợ với việc xử lý dữ liệu thô, dữ liệu phi cấu trúc. Nó không chỉ xử lý một cách nhanh chóng mà còn có thể lưu dữ liệu với giá rẻ và tận dụng nó khi cần. Mặt khác, kho dữ liệu thường xuyên làm việc với dữ liệu tổng hợp (trong số đó có các dữ liệu đã được tổng hợp bằng công nghệ Big Data rồi cung cấp cho các kho dữ liệu). Quá trình “tổng hợp trễ” (late binding) giúp hệ thống Big Data vẫn giữ nguyên dữ liệu thô và xử lý nó để trích 270

xuất thông tin có giá trị tại thời điểm truy vấn. Đồng thời, nhờ lưu trữ dữ liệu thô này, nó vẫn có thể áp dụng các quy tắc khác nhau trong xử lý dữ liệu để trích ra các thông tin với các mục đích khác nhau. - Phân tích các dữ liệu sơ bộ. Dữ liệu được tiền xử lý trước khi nó được đưa vào lưu trữ trong kho dữ liệu hoặc hệ thống Big Data. Bạn cũng có thể khám phá dữ liệu trước khi nó được tải vào một môi trường khác. Hadoop trong hệ thống Big Data cung cấp một môi trường độc lập để lưu trữ và khai phá dữ liệu cấu trúc và phi cấu trúc, trong khi đối với kho dữ liệu thì việc mô hình hóa dữ liệu, thu thập, làm sạch và cấu trúc hóa dữ liệu thường được làm trước khi đưa vào kho dữ liệu. Do đó, có thể thấy rằng giải pháp kho dữ liệu và Big Data đều nhằm khai phá các giá trị và sự hiểu biết từ dữ liệu nhưng mỗi giải pháp có hướng trọng tâm vào mục đích sử dụng và khai thác đối tượng dữ liệu khác nhau. Nếu doanh nghiệp đã và đang đầu tư vào công nghệ kho dữ liệu truyền thống, hãy tiếp tục tận dụng nó cho những gì nó đã được thiết kế để làm. Nếu doanh nghiệp có yêu cầu kinh doanh đòi hỏi được phục vụ tốt hơn bằng công nghệ Big Data, có thể xem xét đến giải pháp tích hợp giữa hệ thống truyền thống và hệ thống dữ liệu mới để vừa tiếp tục khai thác hệ thống hiện hữu nhưng vẫn đáp ứng những yêu cầu kinh doanh mới của doanh nghiệp. Phần tiếp theo sẽ trình bày về việc tích hợp giữa Big Data và Kho dữ liệu. 8.4. Tích hợp giữa Big Data và Kho dữ liệu Trọng tâm của phần này là để thảo luận về sự tích hợp của Big Data và kho dữ liệu, những kỹ thuật có thể sử dụng và làm sao để khai thác ưu điểm của từng công nghệ. Làm thế nào để giải quyết sự phức tạp và không đồng nhất của công nghệ? Hiệu 271

suất và sự mở rộng của mỗi công nghệ là gì, và làm thế nào để duy trì hoạt động trong môi trường mới? Nếu chúng ta có một cuộc hành trình trở lại trong lịch sử và nhìn vào những kiến trúc - kỳ quan đã được xây dựng, chúng ta có thể tự hỏi làm thế nào các kiến trúc sư quyết định và vận dụng các định luật vật lý, và cách kết hợp tính chất hóa học của vật liệu để xây dựng một công trình kéo dài trong nhiều thế kỷ cho dù phải đáp ứng lượng khách viếng thăm khổng lồ và sự thay đổi khí hậu. Khi xây dựng các nhà kho dữ liệu mới, chúng ta cần phải có cách suy nghĩ toàn cục như các kiến trúc sư ngày xưa, và sẽ vừa giữ lại các định nghĩa và chức năng cơ bản của kho dữ liệu, nhưng cũng vừa phát triển một kiến trúc mới để không bị hạn chế bởi các ranh giới của một nền tảng duy nhất như RDBMS. Các thế hệ tiếp theo của kiến trúc nhà kho dữ liệu sẽ phức tạp từ việc triển khai kiến trúc vật lý, bao gồm vô số các công nghệ, và sẽ được dựa trên dữ liệu từ quan điểm tích hợp, cực kỳ linh hoạt và có khả năng mở rộng. Hình 8.2 minh họa các thành phần tổng quát sẽ là các khối xây dựng cơ bản của kho dữ liệu thế hệ tiếp theo, đó là sự tích hợp của tất cả các dữ liệu trong doanh nghiệp bao gồm cả Big Data. Cấp thấp nhất đại diện cho dữ liệu lớp, tầng tiếp theo đại diện các công nghệ sẽ được sử dụng trong việc tích hợp các dữ liệu trên nhiều loại và các nguồn dữ liệu khác nhau. Và lớp trên cùng đại diện lớp phân tích sẽ được sử dụng để hướng các nhu cầu biểu diễn trực quan của kết quả phân tích của thế hệ tiếp theo. Trong phần kế tiếp này sẽ giới thiệu sơ lược về các thành phần của các lớp này.

272

8.4.1. Lớp dữ liệu Như đã thảo luận trong phần trước, các kho dữ liệu thế hệ kế tiếp sẽ có dữ liệu từ toàn bộ doanh nghiệp và sẽ được tích hợp và trình bày cho người sử dụng với mục đích phân tích và ra quyết định kinh doanh. Các lớp dữ liệu trong nền tảng mới bao gồm những điều sau đây.

Hình Error! No text of specified style in document..2. Các thành phần của kho dữ liệu thế hệ mới (Krishnan, 2013) - Dữ liệu truyền thống (legacy data). Dữ liệu từ tất cả các hệ thống kế thừa và ứng dụng bao gồm các định dạng dữ liệu bán cấu trúc, lưu trữ trực tuyến hoặc bên ngoài (offline) có cấu trúc, và có thể được tích hợp vào các kiến trúc dữ liệu. Có rất nhiều trường hợp sử dụng cho loại dữ liệu này. Dữ liệu địa chấn, dữ liệu gió bão, dữ liệu điều tra dân số, dữ liệu quy hoạch đô thị, và các dữ liệu kinh tế xã hội là tất cả các hình thức dữ liệu đã được phân loại. - Dữ liệu giao dịch (OLTP). Dữ liệu từ hệ thống giao dịch truyền thống được đưa vào các kho dữ liệu. Do các vấn đề khả năng mở rộng, dữ liệu giao dịch thường được mô hình hóa ở 273

dạng có cấu trúc. Nền tảng dữ liệu mới có thể được sử dụng để tải toàn bộ dữ liệu để tiền xử lý hoặc xử lý ở bước thứ hai. Dữ liệu từ hệ thống ERP, SCM, CRM trong các hệ thống thông tin của doanh nghiệp thường được bỏ qua bước tiền xử lý, và các nhóm dữ liệu này có thể được sử dụng trong việc tạo ra một nền tảng dữ liệu phía sau (back-end data platform) để phân tích và tổ chức dữ liệu tại mỗi bước xử lý. - Dữ liệu phi cấu trúc. Nền tảng quản lý nội dung được định hướng nhiều hơn về sản xuất và lưu trữ nội dung, chẳng hạn như dữ liệu văn bản (text). Hầu hết các nội dung không được phân tích, và không có tiêu chuẩn kỹ thuật để tạo ra các số liệu phân tích về nội dung. Nội dung của bất kỳ văn bản nào thường đại diện cho bối cảnh mà nó được tạo ra và tổ chức sở hữu nó. Các nền tảng thế hệ tiếp theo sẽ cung cấp giao diện để khai thác các nội dung bằng cách điều hướng nó dựa trên các quy tắc xử lý xác định. Kết quả của việc xử lý dữ liệu nội dung có thể được tích hợp với công nghệ ngữ nghĩa và được sử dụng để giám sát và khai thác dữ liệu văn bản. - Dữ liệu video. Doanh nghiệp hoặc các cơ quan chính phủ cũng thường có nhu cầu khai thác dữ liệu dựa trên video. Có ba thành phần chính trong một video: nội dung, âm thanh và siêu dữ liệu liên quan. Các kỹ thuật xử lý và các thuật toán để khai phá loại dữ liệu này rất phức tạp. Tuy nhiên, các nền tảng dữ liệu mới cung cấp cơ sở hạ tầng cần thiết để xử lý các loại dữ liệu này. Kho dữ liệu thế hệ tiếp theo có thể tích hợp kiểu dữ liệu này và các phân tích liên quan vào kiến trúc kho dữ liệu. - Dữ liệu audio. Dữ liệu từ các trung tâm cuộc gọi đến hay trích xuất âm thanh từ video có chứa rất nhiều thông tin hữu ích về khách hàng, đối thủ cạnh tranh, đánh giá sản phẩm và nhiều thông tin khác. Trong khi các kho dữ liệu hiện tại có những hạn 274

chế về mặt xử lý và tích hợp loại dữ liệu này, các nền tảng dữ liệu mới và công nghệ đã cho phép xử lý các dữ liệu này liên tục và tích hợp nó vào kho dữ liệu. Dữ liệu âm thanh đã trích xuất có thể được xử lý và lưu trữ như dữ liệu theo ngữ cảnh với các siêu dữ liệu liên quan trong kho dữ liệu thế hệ tiếp theo. - Dữ liệu hình ảnh. Hình ảnh tĩnh mang theo rất nhiều dữ liệu mà có thể rất hữu ích trong các Cơ quan chính phủ (khoa học không gian địa lý), y tế (X-ray và CAT scan), và các lĩnh vực khác. Tích hợp dữ liệu này trong kho dữ liệu sẽ cung cấp nhiều lợi ích cho các doanh nghiệp lớn, nơi mà việc chia sẻ dữ liệu như vậy có thể dẫn đến những hiểu biết và tạo ra các cơ hội kinh doanh. - Dữ liệu số / mô hình / đồ thị. Bao gồm các dữ liệu cảm biến, dữ liệu thời tiết, dữ liệu thị trường chứng khoán, dữ liệu khoa học, RFID, dữ liệu vệ tinh di động, dữ liệu hành trình trên ô tô hay trên tàu, dữ liệu GPS, dữ liệu streaming video, và các dữ liệu khác ở dạng con số hoặc các đồ thị xảy ra và lặp đi lặp lại trong khoảng thời gian định kỳ. Xử lý loại dữ liệu này và tích hợp các kết quả với các kho dữ liệu sẽ cung cấp cơ hội để thực hiện các phân tích tương quan (correlation), phân tích cụm (cluster), hoặc các loại phân tích Bayesian, điều này sẽ giúp xác định các cơ hội dẫn tới tăng doanh thu, phân khúc khách hàng, và nhiều cơ hội khác nhằm giảm rủi ro kinh doanh và tối ưu hóa hiệu quả kinh doanh. - Phương tiện truyền thông mạng xã hội. Thông thường loại dữ liệu này đến từ các trang mạng xã hội như Facebook, LinkedIn, Twitter hoặc những kênh truyền thông mạng xã hội khác. Dữ liệu này có thể được mua từ nhà cung cấp bên thứ ba như Nielsen hoặc tự thu thập. Việc xử lý các dữ liệu này có thể được thực hiện bằng cách sử dụng các quy tắc máy học 275

(machine learning) và công nghệ ngữ nghĩa (senmatic). Đầu ra từ quá trình xử lý có thể được tích hợp vào kho dữ liệu mới. Các lớp dữ liệu bao gồm các tập dữ liệu thường có sẵn cho các tổ chức như là tài sản của họ hoặc từ các nguồn bên thứ ba. Làm thế nào để xử lý các loại dữ liệu này và làm thế nào để tích hợp vào hệ thống kho dữ liệu? Để trả lời những câu hỏi này, phần tiếp theo sẽ thảo luận về các thuật toán cơ bản cần phải được tích hợp vào các lớp kiến trúc xử lý và kỹ thuật. 8.4.2. Các thuật toán phân tích dữ liệu Các thuật toán được sử dụng trong phân tích dữ liệu ở hệ thống Big Data thường đa dạng và phức tạp. Việc xử lý dữ liệu trong Big Data thường được thực hiện thông qua nhiều bước. Nhìn chung, các bước xử lý dữ liệu thường được thực hiện theo thứ tự như trong hình 8.3.

Hình Error! No text of specified style in document..3. Các bước xử lý dữ liệu tổng quát Bước đầu tiên sau khi thu thập dữ liệu là thực hiện khám phá dữ liệu. Đây là nơi diễn ra quá trình xử lý phức tạp, đặc biệt là với dữ liệu phi cấu trúc. Để đẩy nhanh việc giảm độ phức tạp, có một số thuật toán đã phát triển và cải tiến trong các giải pháp thương mại hoặc mã nguồn mở. Một số giải thuật chính và hữu ích bao gồm: - Khai thác văn bản. Các thuật toán này có thể có sẵn như các giải pháp phần mềm thương mại hoặc được thiết kế và cải 276

tiến để phù hợp cho từng ứng dụng. Các giải thuật này có thể được tích hợp vào kiến trúc dữ liệu mới để khai thác dữ liệu văn bản. Trọng tâm chính của các thuật toán khai phá văn bản là để xử lý văn bản dựa trên các quy tắc kinh doanh do người dùng định nghĩa, trích xuất và tạo ra các thông tin giá trị (như ý kiến khách hàng, xu hướng tiêu dùng, …) từ nội dung của dữ liệu văn bản. Công nghệ ngữ nghĩa đóng một vai trò quan trọng trong việc tích hợp các dữ liệu trong kho dữ liệu. - Khai thác dữ liệu. Các thuật toán này có sẵn như là phần mềm thương mại từ các công ty như SAS và IBM, và triển khai mã nguồn mở như Mahout. Trọng tâm chính của các thuật toán khai thác dữ liệu là để sản xuất ra dữ liệu dựa trên các mô hình dữ liệu thống kê, làm việc trên phân nhóm dân số, phân cụm dữ liệu, và phân đoạn dựa trên kích thước và thời gian. Các dữ liệu đầu ra thường sâu và rộng, cung cấp một môi trường để thực hiện các vấn đề khai thác dữ liệu. - Xử lý nhận diện mô hình (nhận diện mẫu): Các thuật toán được phát triển cho xử lý nhận diện mô hình, trong đó bao gồm các mô hình từ dữ liệu thẻ tín dụng; dữ liệu POS; dữ liệu máy ATM; tín hiệu thị trường chứng khoán; dữ liệu cảm biến từ các tòa nhà, xe lửa, xe tải, xe ô tô, máy bay, tàu, vệ tinh, hình ảnh và âm thanh; dữ liệu mã hóa, và các ngôn ngữ tượng trưng. Ưu điểm của việc tích hợp dữ liệu này trong kho dữ liệu là có khả năng khai thác quy luật từ sự xuất hiện một lần hay toàn bộ dữ liệu để thiết lập một mô hình dự báo tốt hơn về hành vi. Các nền tảng thế hệ mới cung cấp khả năng lưu trữ cả dữ liệu thô và đầu ra từ quá trình xử lý để cung cấp một kiến trúc dữ liệu toàn diện. - Mô hình thống kê. Các thuật toán này là các mô hình sử dụng chủ yếu trong các dịch vụ tài chính và y tế nhằm tính toán số liệu thống kê để quản lý các phân khúc khách hàng. Các thuật toán này được tùy biến cho mọi tổ chức có sử dụng và tạo ra 277

chúng nhưng ngày nay không thể được tái sử dụng do kích thước của dữ liệu và sự phức tạp trong tính toán. Trong thế hệ tiếp theo của các kho dữ liệu, các mô hình này có thể được tính toán và điều khiển dựa trên các dữ liệu có sẵn trong kho dữ liệu bao gồm dữ liệu có cấu trúc, bán cấu trúc, phi cấu trúc, hoặc kết hợp của tất cả các loại trên. Những mô hình này có thể được phát triển như trên R 1 hay mô hình mã nguồn mở khác (trái ngược với kiến trúc đóng như SAS hoặc IBM SPSS). - Mô hình toán học. Các thuật toán này là các mô hình được sử dụng để dự đoán bệnh, dự báo thời tiết, phân tích gian lận, và các phân tích phi thống kê khác đòi hỏi mô hình toán học. Trong kho dữ liệu thế hệ kế tiếp, dữ liệu theo yêu cầu của các mô hình tính toán liên quan đều có sẵn trong các lớp xử lý của kho dữ liệu. Thế hệ tiếp theo của kiến trúc dữ liệu và hoạt động xử lý dữ liệu sẽ cần bao gồm các thuật toán được thảo luận trong phần này để giải quyết các loại xử lý dữ liệu, báo cáo và phân tích có được từ kho dữ liệu. Bây giờ chúng ta đã có các loại dữ liệu và các loại thuật toán liên quan, tiếp theo sẽ giới thiệu sơ lược về lớp công nghệ. 8.4.3. Lớp công nghệ Có nhiều loại giải pháp công nghệ khác nhau sẽ được sử dụng trong việc xây dựng kho dữ liệu thế hệ tiếp theo để hỗ trợ xử lý các loại dữ liệu cấu trúc, bán cấu trúc và phi cấu trúc hoặc Big Data. Nội dung chi tiết về các công nghệ này khá dài và nằm ngoài phạm vi của cuốn sách này. Ở đây chỉ điểm lại những công nghệ sẽ được tích hợp vào các kiến trúc không đồng nhất trong kho dữ liệu thế hệ tiếp theo, bao gồm:

1

278



RDBMS



Hadoop

R là một ngôn ngữ lập trình và môi trường phần mềm dành cho tính toán và đồ họa thống kê.



NoSQL



Giải pháp MDM



Các giải pháp siêu dữ liệu



Công nghệ ngữ nghĩa



Quy tắc máy học



Kỹ thuật thu thập và khám phá dữ liệu



Kỹ thuật trực quan hóa dữ liệu



Kỹ thuật phân tích và báo cáo

Những công nghệ này đều chứa đựng những thách thức khi tích hợp việc xây dựng các kiến trúc nền tảng vào các kho dữ liệu thế hệ kế tiếp. Mỗi công nghệ được liệt kê ở đây đều có hiệu suất, khả năng mở rộng và hạn chế riêng. Người phát triển hệ thống cần phải hiểu được đặc điểm của từng công nghệ và từ đó biết cách để kết hợp những thế mạnh của mỗi công nghệ nhằm tạo ra một nền tảng bền vững. Tóm lại, như được trình bày trong chương này, sự phát triển liên tục của công nghệ thông tin tạo ra nhiều nguồn dữ liệu, nhiều loại định dạng dữ liệu với khối lượng ngày càng lớn hơn và với tốc độ nhanh hơn. Do đó, nhu cầu khai phá và tận dụng các nguồn dữ liệu mới nhằm nâng cao hiệu quả trong việc ra quyết định không ngừng gia tăng. Việc tích hợp một kho dữ liệu hiện hữu với hệ thống Big Data trong tương lai sẽ tiếp tục được phát triển. Sự không đồng nhất của các loại dữ liệu và công nghệ khai phá sẽ vẫn là vấn đề luôn được cân nhắc khi thiết kế và xây dựng các kho dữ liệu trong tương lại. Trong cuốn sách tiếp theo, chúng tôi sẽ trình bày sâu hơn vào các công nghệ, các khía cạnh và những vấn đề liên quan đến Big Data và ứng dụng của nó trong kinh doanh. Câu hỏi 279

1. Vì sao Big Data trở thành chủ đề quan tâm trong những năm gần đây? 2. Những khó khăn và trở ngại gì khi triển khai dự án Big Data ở Việt Nam? 3. Big Data có thể được ứng dụng ở Việt Nam trong những lĩnh vực cụ thể nào?

280

281

TÀI LIỆU THAM KHẢO 1.

Adamson, C. (2006). Mastering Data Warehouse Aggregates: Solutions for Star Schema Performance. John Wiley & Sons.

2.

Aspin, A. (2015). SQL Server Reporting Services as a Business Intelligence Platform. Business Intelligence with SQL Server Reporting Services, 1-17.

3.

Badiozamany, S. (2010). Microsoft SQL Server OLAP Solution-A Survey.

4.

Bumgarner, V. (2013). Implementing Splunk: Big Data Reporting and Development for Operational Intelligence. Packt Publishing.

5.

Carlo, V. (2009). Business Intelligence: Data Mining and Optimization for Decision Making. Editorial John Wiley and Sons.

6.

Cawley, K. (2014, August 7). The Benefits of Having a Data Warehouse. Retrieved from CloudTweaks: http://cloudtweaks.com/2014/08/benefits-data-warehouse/.

7.

Chaidez, J. (2008). Business Intelligence & IT Governance. University of Illinois at Urbana - Champaign.

8.

Devi , U. V. (2009, May 13). Role of Decision Support System For Decision Making Process in Global Business Environment. Retrieved from Ezine Articles: http://ezinearticles.com/?Role-of-Decision-Support-SystemFor-Decision-Making-Process-in-Global-BusinessEnvironment&id=2315787.

9.

Foley, J. (2014, Marth 10). The Top 10 Trends In Data Warehousing. Retrieved from Forbes: http://www.forbes.com/sites/oracle/2014/03/10/the-top-10trends-in-data-warehousing/#489a466b1123.

282

10.

George, S. (2012, April). Inmon vs. Kimball: Which approach is suitable for your data warehouse? Retrieved from ComputerWeekly.com: http://www.computerweekly.com/tip/Inmon-vs-KimballWhich-approach-is-suitable-for-your-data-warehouse.

11.

Ghalayini, A. M., & Noble, J. S. (1996). The changing basis of performance measurement. International Journal of Operations & Production Management, 16(8), 63-80.

12.

Han, J., Kamber , M., & Pei, J. (2011). Data Mining: Concepts and Techniques. Elsevier.

13.

Inmon, B. (2005). Building the Data Warehouse, Fourth Edition. Wiley Publishing, Inc.

14.

Kimball, R. (2004). The Data WarehouseETL Toolkit: Practical Techniques for Extracting, Cleaning, Conforming, and Delive. Wiley.

15.

Kimball, R., & Ross, M. (2013). The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling, Third Edition. John Wiley & Sons, Inc.

16.

Knight, B., Knight, D., Davis, M., & Snyder, W. (2012). Knight's Microsoft SQL Server 2012 Integration Services 24Hour Trainer. Wrox Publisher.

17.

Knight, B., Veerman, E., Moss, J. M., , Davis, M., & Rock, C. (2012). Professional Microsoft SQL Server 2012 Integration Services. Wrox Publisher.

18.

Krishnan, K. (2013). Data warehousing in the age of big data. Morgan Kaufmann.

19.

Lloyd, J. (2011). Identifying Key Components of Business Intelligence Systems and Their Role in Managerial Decision making (Doctoral dissertation). Intel Corporation.

20.

Microsoft. (2015, 12). Multidimensional Model Databases. Retrieved from Microsoft TechNet: https://technet.microsoft.com/vi-vn/library/ms174953. 283

21.

Parmenter, D. (2001). Winning KPIs. MANAGEMENTAUCKLAND, 48(11), 100-101.

22.

Parmenter, D. (2015). Key performance indicators: developing, implementing, and using winning KPIs. John Wiley & Sons.

23.

Sanchez, H., & Robert, B. (2010). Measuring portfolio strategic performance using key performance indicators. Project Management Journal, 41(5), 64-73.

24.

Shen, J. (2013). Investigation of how to implement successful KPIs for organizations - based on an empirical study at an international organization.

25.

Tomic, D. (2006). Business Intelligence in Managerial Accounting. South East European Journal of Economics & Business (1840118X).

26.

Turley, P., Bruckner, R. M., Silva, T., Withee, K., & Paisley, G. (2012). Professional Microsoft SQL Server 2012 Reporting Services. Wiley.

27.

Vassiliadis, P., & Simitsis, A. (2009). Transformation, and Loading. Springer.

28.

White, C. (2006). A roadmap to enterprise data integration. IBM.

29.

Williams, S., & Williams , N. (2006). The Profit Impact of Business Intelligence. Morgan Kaufmann.

284

Extraction,