2.2.3.1. Phương pháp thiết kế.
Với kiến trúc kho dữ liệu đề xuất và căn cứ khối lượng dữ liệu, kho dữ liệu sẽ được xây dựng theo phương pháp tổng hợp của 2 cách tiếp cận và được phát triển theo nhu cầu cụ thể của từng giao đoạn. Cụ thể như sau:
Xây dựng kho dữ liệu quan hệ ban đầu gồm các dữ liệu cần thiết cho kho dữ liệu cục bộ đầu tiên.
Xây dựng kho dữ liệu cục bộ đầu tiên.
Khi nhu cầu kinh doanh phát sinh. Tiến hành bổ sung dữ liệu cần thiết cho kho dữ liệu cục bộ mới vào kho dữ liệu.
Xây dựng kho dữ liệu cục bộ tiếp theo.
Quá trình trên thực hiện lặp để đảm bảo kho dữ liệu phát triển và đáp ứng nhu cầu kinh doanh ở từng giai đoạn. Ngoài ra, theo tài liệu “Mastering Data Warehouse Design” Wiley Publishing phát hành thì để đảm tính hiệu quả kho dữ liệu nên được thiết lập qua 08 bước sau:
Lựa chọn dữ liệu phù hợp : yêu cầu, phạm vi, nguồn dữ liệu…
Thêm thông tin thời gian vào dữ liệu: do OTLP là hệ thống phản ánh dữ liệu hiện trạng còn kho dữ liệu là dữ liệu phản ánh quá trình thời gian.
Thêm thông tin tính toán dữ liệu: các thông tin hỗ trợ việc xử lý thông tin như ngày làm việc hoặc ngày nghỉ, ngày thuộc tuần nào? Tháng nào.. mục đích phục vụ việc cải thiện hiệu suất.
Quyết định mục độ chi tiết của dữ liệu sẽ đẩy vào kho dữ liệu.
Thực hiện việc tính toán các dữ liệu tổng hợp và lưu trữ sẵn sàng để phục vụ truy vấn dữ liệu.
Gộp các thực thể có chung mục đích để tối ưu hệ thống.
Tạo mảng dữ liệu theo nhu cầu kinh doanh về phân tích dữ liệu.
Phân chia dữ liệu. 2.2.3.2. Kiến trúc kho dữ liệu.
Để đáp ứng các yêu cầu đặt ra về việc sử dụng và vận hành kho dữ liệu. NLV đề xuất sử dụng kiến trúc kho dữ liệu với vùng đệm làm sạch dữ liệu và kho dữ liệu cục bộ.
40
Hình 2. 8: Kiến trúc kho dữ liệu Ocean Bank.
Kiến trúc kho dữ liệu sẽ gồm:
Nguồn dữ liệu: chiết suất lấy từ hệ thống giao dịch core banking và file dữ liệu (do Ban kế toán xây dựng).
Vùng đệm: là vùng hệ thống bảng tạm để thực hiện việc làm sạch, tích hợp và thêm giá trị thời gian vào dữ liệu. Và thực hiện việc sao lưu dữ liệu.
Kho dữ liệu: Sau khi dữ liệu đã được làm sạch sẽ được nạp vào kho dữ liệu. Sau đó thêm các dữ liệu phục vụ cho tính toán và dữ liệu tổng hợp theo yêu cầu phân tích. Sử dụng cơ sở dữ liệu quan hệ.
Kho dữ liệu cục bộ: Là cơ sở dữ liệu tổ chức theo mô hình chiều với dữ liệu được nạp từ kho dữ liệu trung tâm.
Người dùng: là người sử dụng đầu cuối sử dụng dữ liệu. Lí do chọn kiến trúc trên cho kho dữ liệu:
Vùng đệm: Giúp đơn giả hóa và lưu nhất ký xử lý của quá trình ETL dữ liệu vào kho. Do vùng đệm đã thực hiện các công việc phức tạp trong việc tính toán và đảm bảo tính nhất quán của dữ liệu.
Kho dữ liệu cục bộ: được tổ chức theo mô hình chiều giúp đơn giản và dễ dàng cho người dùng sử dụng. Ẩn đi sự phức tạp và giảm sự ảnh hưởng đến việc sử dụng của người dùng khi kho dữ liệu thay đổi.
Để đảm bảo tính chính xác và hiệu năng hệ thống. Kho dữ liệu sẽ định kỳ làm mới 01 lần/ ngày. Hệ thống sẽ tiến hành lấy dữ liệu từ nguồn core đẩy vào kho dữ liệu sau quá trình đóng ngày cũ và mở ngày mới. Mô hình chiết xuất dữ liệu như hình dưới đây.
41
Hình 2. 9: Mô hình giải pháp luồng dữ liệu.
2.2.3.3. Nguồn dữ liệu cho kho dữ liệu cho việc chiết xuất.
Thông qua việc làm rõ yêu cầu của kho dữ liệu ở mục 2.2.1 và mục 2.2.3 ta đã xác định được các thực thể dữ liệu cần được đẩy vào kho dữ liệu từ dữ liệu nguồn và chi tiết nguồn dữ liệu như bảng dưới. (adsbygoogle = window.adsbygoogle || []).push({});
Thực thể Nguồn Bảng dữ liệu chiết xuất Khóa
CIF Core Banking sttm_customer Customer_no
BRANCH Core Banking Ot_branch Branch_code
MAIN_BRANCH Core Banking it_main_sub Sub_branch BRN_DISTRICT,
BRN_CITY,
BRN_TERRITORY, BRN_REGION
Core Banking Ot_branch Branch_code
CIF_CLASS Core Banking OJB_Customer_Class Customer_no ACC_CLASS Core Banking Sttm_account_class Account_class TD_ACCOUNT Core Banking Sttm_customer_account Account_no RATE Core Banking ICTMS_PR_INT_UDEVALS Product_code,
aclass, ccy, eff_dt, rate_code, branch.
LSNB Core Banking ICTMS_LSNB Product_code,
aclass, ccy_code, eff_dt, rate_code, branch.
PRODUCT Core Banking Sttm_product_code Product_code ACC_LOAN Core Banking cltb_account_apps_master Account_number CONTRACT Core Banking Sttm_contract_master Contract_ref_no GL_CODE Core Banking GLTM_GLMASTER gl_code
42
Dữ liệu tham khảo cần bổ sung vào kho dữ liệu để nhằm mục đích tra cứu và xác thực tính đứng đắn của dữ liệu như bộ tính lãi product code và danh sách phân loại tài khoản. Vì việc xác định lãi suất của một tài khoản khi mở sẽ phụ thuộc vào phân loại tài khoản, bộ lãi suất.
Dữ liệu tham
khảo Nguồn Bảng dữ liệu chiết xuất Ghi chú Product_code Core Banking ICTMS_PR_INT_UDEVALS Sự thay đổi về lãi suất Working day Core Banking STTM_LCL_HOLIDAY Ngày làm việc hay nghỉ Rate_tranfer Core Banking ICTM_ACC_UDEVALS Tỉ giá quy đổi theo loại tiền LSNB Core Banking IT_LSNB Lãi suất nội bộ cho việc
mua bán vốn trong nội bộ. Hình 2. 11: Bảng danh sách dữ liệu tham khảo đẩy vào kho dữ liệu.
Ngoài ra chúng cần làm rõ các quan hệ giữa các thực thể. Việc đặc tả các quan hệ giữa các thực thể dữ liệu trong core banking đã được mô tả tại hình 2.3. 2.2.3.4. Xử lý dữ liệu chuyển đổi và nạp vào kho.
Sự khác biệt lớn nhất giữa mô hình dữ liệu nghiệp vụ và mô hình dữ liệu kho dữ liệu đó là thời gian. Với mô hình dữ liệu nghiệp vụ thì dữ liệu luôn miêu tả về trạng thái hiện tại của doanh nghiệp (mang tính thời điểm) còn với kho dữ liệu thì theo quan điểm dữ liệu gắn liền với thời gian (mang tính lịch sử). Do vậy khi thiết kế kho ta cần chú ý việc thêm và các thành phần thời gian tới các thực thể có thể thay đổi. Giải pháp sử dụng là bổ sung thêm cột dữ liệu xác định thời gian của dữ liệu và với mỗi khi thuộc tính của thực thẻ thay đổi ta sẽ thêm một bản ghi mới vào kho dữ liệu. Qua đó đảm bảo tính nhất quán về dữ liệu cho kho. Xem xét yêu cầu và mô hình nghiệp vụ thì dữ liệu đẩy vào kho dữ liệu ngoài một số dữ liệu bất biến theo thời gian như: số tài khoản, số CIF, lãi suất, lsnb… thì còn một số dữ liệu có khẳ năng thay đổi chậm như: phân loại khách hàng (khách hàng trong quá khứ là doanh nghiệp siêu nhỏ nhưng hiện tại có thể là doanh nghiệp vừa và nhỏ). Để đảm bảo kho dữ liệu lưu giữ chính xác thông tin và đưa ra dữ liệu nhất quán trong quá khứ thì phải có mốc để xác định chính xác giá trị dữ liệu ứng với thời điểm quá khứ.
Chiều Thuộc tính Thay đổi Tần suất cập nhập
Thuộc tính bổ sung CIF Class Phân loại khách hàng Có Tháng MonthYear Khu vực Branch Phân loại khu vực Có Tháng MonthYear Main Branch Trực thuộc chi nhánh Có Tháng MonthYear CCy Loại tiền của TK Không
Account_Class Phân loại tk Không
Product_code Bộ tính lãi suất Có Ngày Dữ liệu tham khảo Hình 2. 12: Bảng danh sách dữ liệu chiều thay đổi theo thời gian.
43
Hình 2. 13: Thêm thành phần thời gian vào dữ liệu.
Theo yêu cầu về dự án, dữ liệu phân tích chi tiết nhất chính là số dư tài khoản tại ngày. Nên thay vì lưu toàn bộ dữ liệu giao dịch thì dữ liệu trong kho sẽ được tổng hợp theo số dư tài khoản theo ngày. Quá trình xử lý tại vùng đệm sau đó đẩy vào kho:
Đầu vào: Dữ liệu thông tin tài khoản trên core banking vào cuối ngày.
Đầu ra: Thông tin tài khoản được đẩy vào bảng trung gian gồm số tài khoản, ngày, lãi suất… với huy động là bảng it_lsnb_tdcasa_daily, cho vay là bảng it_lsnb_tckt_cl_daily.
Hình 2. 14: Bảng dữ liệu chính trong kho.
Việc tạo và duy trì các kết nối giữa các thực thể được sử dụng với khóa đại diện. Thông thường, mỗi bảng đều có một khoá chính dùng định danh cho từng dòng của nó. Khoá này có thể tạo bởi 1 hay nhiều cột. Trong dữ liệu nguồn, khoá này là không thống nhất, và có thể mang nhiều kiểu khác nhau, cũng có thể được tạo tự động bởi cơ sở dữ liệu nguồn. Trong kho dữ liệu, khoá này gọi là khoá tự nhiên. Vì những lí do trên đây, khoá tự nhiên của dữ liệu nguồn không thể được sử dụng trong một hệ thống chung của kho dữ liệu. Thay vào đó, người (adsbygoogle = window.adsbygoogle || []).push({});
ta sử dụng khoá đại diện, với các đặc điểm sau:
Chỉ bao gồm 1 cột: Đơn giản cho phép kết
44
Tạo bởi gói ETL trong lúc nạp dữ liệu: Thống nhất giữa nhiều nguồn dữ
liệu.
2.2.3.5. Tạo thêm các dữ liệu tính toán.
Để cải thiện tốc độ truy vấn của kho dữ liệu. Ta sẽ bổ sung thêm 02 loại dữ liệu sau:
Dữ liệu phục vụ việc tính toán it_timE. IT_TIME CALENDAR_YEAR_CAL_YEAR_CODE NUMBER CALENDAR_YEAR_END_DATE DATE CALENDAR_YEAR_TIME_SPAN NUMBER CALENDAR_YEAR_DESCRIPTION VARCHAR2(2000) CALENDAR_YEAR_NAME VARCHAR2(25) CAL_YEAR_NUMBER NUMBER CAL_YEAR_START_DATE DATE CALENDAR_QUART_CAL_QUARTER_CO NUMBER CALENDAR_QUARTER_END_DATE DATE CALENDAR_QUARTER_TIME_SPAN NUMBER CALENDAR_QUARTER_DESCRIPTION VARCHAR2(2000) CALENDAR_QUARTER_NAME VARCHAR2(25) CAL_QUARTER_NUMBER NUMBER QUARTER_OF_YEAR NUMBER CAL_QUARTER_START_DATE DATE CALENDAR_MONTH_CAL_MONTH_CODE NUMBER CALENDAR_MONTH_END_DATE DATE CALENDAR_MONTH_TIME_SPAN NUMBER CALENDAR_MONTH_DESCRIPTION VARCHAR2(2000) CALENDAR_MONTH_NAME VARCHAR2(25) CAL_MONTH_NUMBER NUMBER CAL_MONTH_START_DATE DATE MONTH_OF_QUARTER NUMBER MONTH_OF_YEAR NUMBER DAY_DATE DATE DAY_DAY_CODE NUMBER DAY_START_DATE DATE DAY_END_DATE DATE DAY_TIME_SPAN NUMBER
45 JULIAN_DATE NUMBER DAY_DESCRIPTION VARCHAR2(2000) DAY_NAME VARCHAR2(25) DAY_OF_CAL_WEEK NUMBER DAY_OF_CAL_MONTH NUMBER DAY_OF_CAL_QUARTER NUMBER DAY_OF_CAL_YEAR NUMBER
Dữ liệu tổng hợp theo yêu cầu báo cáo bảng ojb_objective
Hình 2. 15: Tạo thêm dữ liệu tính toán, tổng hợp.
Dữ liệu phục vụ việc tính toán bổ sung thêm bảng thông tin về thời gian (it_time_day) sẽ trả về thông tin chi tiết của một ngày là thuộc tuần nào? Tháng nào? Quý nào? Năm nào? Là ngày làm việc hay ngày nghỉ.
Dữ liệu tổng hợp là việc tính trước dữ liệu tổng hợp theo tháng ứng phân loại tài khoản, phân loại khách hàng, loại tiền..
2.2.3.6. Tạo phân cấp dữ liệu.
Qua xem xét dữ liệu và yêu cầu kinh doanh, kho dữ liệu sẽ bao gồm các phân cấp dữ liệu như sau:
Phân cấp về khu vực địa lý.
Phân cấp về loại tiền.
Phân cấp về phòng giao dịch, chi nhánh.
Phân cấp về loại tài khoản.
46 2.2.3.7. Mô hình dữ liệu kho.
Kho được tổ chức theo mỗi hình dữ liệu quan hệ như gồm loại bảng:
Bảng dữ liệu chiều: như thông tin khách hàng, tài khoản, loại tiền…
Bảng dữ liệu phục vụ tính toán: bảng thời gian.
Bảng dữ liệu tổng hợp.
Bảng dữ liệu tham khảo.
Việc quản lý và duy trì quan hệ trong kho dữ liệu được tổ chức thông qua một khóa đại diện thay vì sử dụng khóa có sẵn từ hệ thống hay khóa theo bộ mã tiêu chuẩn quốc tế. Việc sử dụng khóa đại diện kiểu number giúp việc truy vấn hệ thống nhanh hơn và đảm bảo việc nhất quán cùng một dữ liệu trên OLTP nhưng tại 2 thời điểm khác nhau lại có các thuộc tính xem xét khác nhau.
47 CUST_ACCOUNTS PK,FK2 CUSTOMER_NO PK,FK1 EFFECTIVE_DATE PK,FK1 ACCOUNT_CLASS BRANCH_CODE CUST_AC_NO CUST_NO CCY AC_OPEN_DATE DR_GL CR_GL PRODUCT_CODE CCY PK,FK1 CUSTOMER_NO PK,FK1 ACCOUNT_CLASS PK,FK1 EFFECTIVE_DATE CCY_CODE CCY_NAME COUNTRY ACCOUNT_CLASS PK ACCOUNT_CLASS PK EFFECTIVE_DATE DESCRIPTION DEFAULT_TENOR_DAYS DEFAULT_TENOR_MONTHS DEFAULT_TENOR_YEARS CLOSE_ON_MATURITY TDCASA_BALANCE PK,FK2,FK3 CUSTOMER_NO PK,FK3 EFFECTIVE_DATE PK,FK3 ACCOUNT_CLASS DAY_TO_RUN ACCTNO CURRENCY AC_BRANCH RATE LSNB CUR_BALANCE CUSTOMER PK CUSTOMER_NO CUSTOMER_TYPE CUSTOMER_NAME1 ADDRESS NATIONALITY LOCAL_BRANCH UNIQUE_ID_VALUE BRANCH PK,FK1 CUSTOMER_NO PK,FK1 ACCOUNT_CLASS PK,FK1 EFFECTIVE_DATE BRN_CODE BRN_NAME BRN_ADDR PARENT_BRANCH BRN_STRESS BRN_CITY BRN_CONTRY CONTRACT_MASTER PK,FK1,FK3 CUSTOMER_NO PK,FK1,FK3 ACCOUNT_CLASS PK,FK1,FK3 EFFECTIVE_DATE BRANCH CONTRACT_REF_NO PRODUCT COUNTERPARTY CURRENCY BOOKING_DATE VALUE_DATE MATURITY_DATE VERSION_NO GLTM_GLMASTER PK GL_CODE GL_DESC PARENT_GL EFFECTIVE_DATE PRODUCT_ACCROLE GL_CODE PRODUCT_CODE ROLE_TYPE STATUS ACCOUNT_HEAD ACCOUNT_APPS_MASTER PK,FK1 ACCTNO PK,FK2,FK3 CUSTOMER_NO PK,FK2,FK3 ACCOUNT_CLASS PK,FK2,FK3 EFFECTIVE_DATE ACCOUNT_NUMBER BRANCH_CODE CUSTOMER_ID PRODUCT_CODE VALUE_DATE MATURITY_DATE AMOUNT_FINANCED TCKT_BALANCE PK ACCTNO DAY_TO_RUN PRODUCT_CODE CURRENCY AC_BRANCH RATE LSNB CUR_BALANCE GL_COE
Hình 2. 17: Thiết kế CSDL của kho dữ liệu.