3.5.1 Chuẩn bị dữ liệu
Trước khi chuyển đổi, bộ phận nghiệp vụ thực hiện làm sạch dữ liệu, bộ phận công nghệ thông tin của ngân hàng thực hiện kết xuất dữ liệu ra Cơ sở dữ liệu trung gian. Từ cơ sở dữ liệu trung gian này, bộ phận công nghệ thông tin của FPT chuyển đổi vào hệ thống SMLC. Người dùng nghiệp vụ của ngân hàng sẽ làm sạch dữ liệu bằng cách nhập thủ công vào hệ thống nguồn trước khi xuất. Sau mỗi lần chuyển đổi, nghiệp vụ BIDV đối chiếu rà soát dữ liệu theo báo cáo đối chiếu.
-I- Quy tắc 1: Kiểm tra các trường bắt buộc
Khóa luận tốt nghiệp Chiến lược chuyển đổi dữ liệu khách hàng tại ngân hàng BIDVvà đánh giá trên hệ thống SMLC
Hình 10. Các bước chuẩn bị dữ liệu
Kiểm thử trực tiếp từ giai đoạn chạy Mock trở đi sẽ sử dụng dữ liệu Production vì các lý do như sau:
a. Máy chủ UAT khơng thể có khả năng xử lý khối lượng dữ liệu Production. b. Chạy Mock cần sử dụng dữ liệu thực tế để ước tính thời gian chuyển đổi. Điều này để xác định hoặc lên kế hoạch cho “thời gian dừng để chuyển đổi” và các hoạt động liên quan khác trong quá trình chuyền đổi.
c. Mỗi lần chạy Mock trên các Schema khác nhau để đảm bảo khơng có sự can thiệp vào dữ liệu Production. Điều này có thể được kiểm sốt ở mức OS/ Database/ Application level.
3.5.2 Quy tắc kiểm tra dữ liệu
Tham khảo File mapping Template chuyển đổi Core Banking SIBS, hệ thống Kondor, Cadencie, Quản lý dự án - SGD3, Quản lý tài sản cầm cố thế chấp của BIDV để xuất dữ liệu và tải dữ liệu lên hệ thống SMLC và CLIMS.
File mapping Template được dùng chung cho các bên tham gia chuyển đổi dữ liệu để hiểu rõ các nội dung sau:
• Phạm vi dữ liệu được chuyển đổi.
• Các trường dữ liệu thực tế được chuyển đổi.
• Giá trị mặc định mà Core Banking SIBS hệ thống Kondor, Cadencie, Quản lý dự án - SGD3, Quản lý tài sản cầm cố thế chấp của BIDV hoặc SMLC và CLIMS sẽ sử dụng cho các trường cụ thể.
• Xác định quy tắc mà SMLC sẽ kiểm tra trong suốt quy trình.
Khóa luận tốt nghiệp Chiến lược chuyển đổi dữ liệu khách hàng tại ngân hàng BIDVvà đánh giá trên hệ thống SMLC
được cung cấp từ đội nghiệp vụ.
Mục đích kiểm tra các trường bắt buộc để đảm bảo cho việc sau khi chuyển đổi hệ thống có thể hoạt động tốt với bộ dữ liệu đã được xác định.
Trong quá trình kiểm tra quy tắc 1 sẽ có các trường hợp có thể xảy ra như đối với các trường dữ liệu bắt buộc nhưng lại khơng có thơng tin thì sẽ bị từ chối chuyển đổi và đẩy dữ liệu đó vào bảng dữ liệu lỗi.
Đoạn mã code cho Quy tắc 1: (đối với một trường hợp cụ thể là trường
CIF_NUMBER)
INSERT INTO MIG_VALIDATION_ERROR(ID, TABLE_NAME, COLUMN_NAME,
TABLE_ID, REF_KEY, RULE_ID, ERROR_MSG)
SELECT SEQ_MIG_VALIDATION_ERROR_ID.NEXTVAL, 'MIG_CU001_STG',
'CIF_NUMBER', ID, CIF_NUMBER, 1, 'CIF_NUMBER '||V_RULE1_MSG
FROM MIG_CU001_STG WHERE CIF_NUMBER IS NULL AND CUSTOMER_TYPE='I' AND CUSTOMER_TYPE='C' AND CUSTOMER_TYPE='CI';
Giải thích code: Neu như trường dữ liệu CIF_NUMBER bị rỗng (khơng có dữ liệu) thì sẽ đẩy vào bảng MIG_VALIDATION_ERROR (bảng chứa các thơng tin bị lỗi).
Sẽ đẩy vào bảng lỗi các thông tin như: Bảng lỗi là từ bảng MIG_CU001_STG, lỗi
ở trường CIF_NUMBER, số ID khách hàng ở bảng MIG_CU001_STG, số CIF_NUMBER là bao nhiêu, lỗi vi phạm là vi phạm quy tắc 1, và hiển thị lỗi là CIF_NUMBER khơng có giá trị.
-I- Quy tắc 2: Kiểm tra từng trường riêng biệt
Trường dữ liệu riêng biệt là trường có giá trị tuân theo quy định sau trong biểu mẫu chuyển đổi:
o Trường chỉ chấp nhận giá trị mặc định. Ví dụ: 'Y' / 'N'.
o Giá trị của các trường phải khớp mã dùng chung trong SMLC. Bất cứ mã
code nào khơng có trong SMLC cần phải bổ sung trước khi chuyển đổi, các mã khơng khớp thì được coi là khơng hợp lệ.
o Tuân theo các quy tắc khác được nêu trong tài liệu mapping chi tiết.
Cách xác định: Dựa trên biểu mẫu chuyển đổi dữ liệu đã được cung cấp từ đội nghiệp vụ.
Mục đích kiểm tra từng trường riêng biệt để đảm bảo cho việc sau khi chuyển đổi hệ thống có thể hoạt động tốt với bộ dữ liệu đã được xác định.
Trong quá trình kiểm tra quy tắc 2 sẽ có các trường hợp có thể xảy ra như đối với các trường dữ liệu không tuân thủ theo quy tắc nghiệp vụ thì sẽ bị từ chối chuyển đổi, đồng thời thực hiện cơng việc rà sốt xem bị thiếu code nào để bổ sung cho đợt chạy tiếp theo.
Đoạn mã code ví dụ cho Quy tắc 2: (đối với trường hợp cụ thể là trường COTR_OF_INCORP)
UPDATE MIG_CU001_STG OLD SET SML_COTR_OF_INCORP= (SELECT CODE_VALUE_ID FROM MIG_COMMON_CODE NEW WHERE
CODE_SET_CODE='COUNTRY' AND
OLD.COTR_OF_INCORP=NEW.CODE_VALUE_CODE);
INSERT INTO MIG_VALIDATION_ERROR(ID, TABLE_NAME, COLUMN_NAME, TABLE_ID, REF_KEY, RULE_ID, ERROR_MSG)
SELECT SEQ_MIG_VALIDATION_ERROR_ID.NEXTVAL, 'MIG_CU001_STG',
'COTR_OF_INCORP', ID, CIF_NUMBER, 2, 'COTR_OF_INCORP'||V_RULE2_MSG FROM MIG_CU001_STG WHERE COTR_OF_INCORP IS NOT NULL AND
SML_COTR_OF_INCORP IS NULL;
Giải thích code: Ban đầu phải cập nhật trường CODE_VALUE_ID của bảng mã dùng dùng nơi mà có code là COUNTRY.
Tiếp theo kiểm tra xem đối với COUNTRY đó liệu có trường ID nào từ bảng mã dùng chung hay khơng, nếu khơng thì sẽ báo cáo ra lỗi.
Lỗi được đẩy vào bảng lỗi các thông tin như: Bảng lỗi là từ bảng
MIG_CU001_STG, lỗi ở trường COTR_OF_INCOPR, số ID khách hàng ở bảng
MIG_CU001_STG, số CIF_NUMBER là bao nhiêu, Lỗi vi phạm là vi phạm quy tắc 2, và
hiển thị lỗi là COTR_OF_INCOPR khơng có giá trị dùng chung.
-I- Quy tắc 3: Kiểm tra liên kết theo hình bên dưới
Khóa luận tốt nghiệp Chiến lược chuyển đổi dữ liệu khách hàng tại ngân hàng BIDVvà đánh giá trên hệ thống SMLC
Chiến lược chuyển đổi dữ liệu khách hàng tại ngân hàng BIDVvà đánh giá trên hệ thơng SMLC Khóa luận tơt nghiệp
Hình 11. Kiểm tra liên kết dữ liệu
Trước khi chuyển đổi dữ liệu, đội IT chuyển đổi dữ liệu phải xem xét kỹ các liên kết để tránh các trường hợp sai sót xảy ra.
3.5.3 Quy trình chuyển đổi dữ liệu
Công việc chuyển đổi sẽ được thực hiện trên máy chủ Database Production
Hình 12. Lưu đồ xuất dữ liệu
Sau khi đẩy dữ liệu vào bảng tạm, đội IT ngân hàng sẽ tạo ra báo cáo QC2 về số
lượng bản ghi đã được đẩy vào bảng trung gian.
Bộ báo cáo QC2 dùng để đối chiếu với báo cáo QC1 để đảm bảo rằng số lượng
dữ liệu được đưa vào bản trung gian là khớp nhau và đầy đủ.
Bước 3: Đội ngũ chuyển đổi dữ liệu sẽ đẩy dữ liệu từ bảng trung gian vào bảng Hình 13. Quá trình cuyển đổi dữ liệu
Bước 1: Đội IT ngân hàng sẽ sử dụng nguồn Core Banking SIBS, Kondor, Cadencie, QLDA để xuất dữ liệu ra bảng trung gian (bảng Mid) để phục vụ dữ liệu cho công việc chuyển đổi. Việc xuất dữ liệu này cần tuân theo biểu mẫu phù hợp với mẫu cấu trúc mà hệ thống SMLC yêu cầu cũng như loại dữ liệu phù hợp trong phạm vi chuyển đổi.
Sau khi xuất dữ liệu thành công, đội IT ngân hàng sẽ tạo ra báo cáo QC1 về số lượng bản ghi đã được xuất thành công.
Bước 2: Đội IT ngân hàng sẽ đẩy toàn bộ những dữ liệu từ các hệ thống đã được xuất ra từ bước 1 vào bảng trung gian (bảng Mid)
trung gian).
Đoạn code thực thiện việc chuyển đổi dữ liệu từ bảng trung gian vào bảng Staging. INSERT INTO MIG_CU001_STG(CIF_NUMBER,HOST_LEGAL_NAME,LEGAL_NAME,CUST_NAME,SHO RT_NAM E,FIST_NAME,COTR_OF_INCORP,COTR_OF_OPER,DATE_OF_INCORP,DATE _OF_BIRTH,COTR_OF_BUSI_OPER,DATE_OF_BUSI_OPER,LISTED,BANK_ENTITY,NAT IONALITY,GENDER,MARITAL_STATUS,PRIMARY_ID_COTR,PRIMARY_ID_TYPE,PRIMA RY_ID_NUMBER,PRIMARY_ID_PLACE,PRIMARY_ID_DATE,SECOND_ID_COUNTRY,SE COND_ID_TYPE,SECOND_ID_NUMBER,SECOND_ID_DATE,DATE_CIF_CREATED,CLA SSIFICATION,INT_NAME,CUST_CONSTITUSION,TAX_CODE,SEGMENT_GOV,SEGMEN
T_BI DV, NATION_OF_I NVESTOR,INSIDER_CODE,RESIDENT_CODE,PRIVATE_ENTERP
RISE,INDUSTRY_TYPE,CUST_SECTOR,ECONOMIC_SECTOR,SBV_REFERENCE,COM
MODITY, PURPOSE,TERM_TYPE, ECONOMIC_AREA, REASON_FOR_OVD,REASON_FO
R_UNSECURED,CUSTOMER_TYPE,ADDRESS_FORMAT,ADDRESS_LINE1,ADDRESS_ LINE2,ADDRESS_LINE3,ADDRESS_LINE4,ADDRESS_LINE5,HOST_ADDRESS,REG_AD DRESS_COTR,REG_ADDRESS_PROVINCE,REG_ADDRESS_CITY,REG_ADDRESS_ST ATE,REG_ADDRESS_POSTCODE,WEBSITE,EMAIL,PHONE_FAX,PRIMARY_OFFICER_ NAME,PRIMARY_OFFICER_CODE,PRIMARY_OFFICER_BRANCH) SELECT CIF_NUMBER,HOST_LEGAL_NAME,LEGAL_NAME,CUST_NAME,SHORT_NAME,FIST_N AME,COTR_OF_INCORP,COTR_OF_OPER,DATE_OF_INCORP,DATE_OF_BIRTH,COTR _OF_BUSI_OPER,DATE_OF_BUSI_OPER,LISTED,BANK_ENTITY,NATIONALITY,GENDE R,MARITAL_STATUS,PRIMARY_ID_COTR,PRIMARY_ID_TYPE,PRIMARY_ID_NUMBER, PRIMARY_ID_PLACE,PRIMARY_ID_DATE,SECOND_ID_COUNTRY,SECOND_ID_TYPE, SECOND_ID_NUMBER,SECOND_ID_DATE,DATE_CIF_CREATED,CLASSIFICATION,INT _NAME,CUST_CONSTITUSION,TAX_CODE,SEGMENT_GOV,SEGMENT_BIDV,NATION_ OF_INVESTOR,INSIDER_CODE,RESIDENT_CODE,PRIVATE_ENTERPRISE,INDUSTRY_ TYPE,CUST_SECTOR,ECONOMIC_SECTOR,SBV_REFERENCE,COMMODITY,PURPOS E,TERM_TYPE,ECONOMIC_AREA,REASON_FOR_OVD,REASON_FOR_UNSECURED,C USTOMER_TYPE,ADDRESS_FORMAT,ADDRESS_LINE1,ADDRESS_LINE2,ADDRESS_L INE3,ADDRESS_LINE4,ADDRESS_LINE5,HOST_ADDRESS,REG_ADDRESS_COTR,RE G_ADDRESS_PROVINCE,REG_ADDRESS_CITY,REG_ADDRESS_STATE,REG_ADDRE SS_POSTCODE,WEBSITE,EMAIL,PHONE_FAX,PRIMARY_OFFICER_NAME,PRIMARY_ OFFICER_CODE,PRIMARY_OFFICER_BRANCH FROM MIG_CU001_MID;
Đối với các dữ liệu bị đẩy sang bảng lỗi cũng sẽ có một dấu hiệu là dữ liệu lỗi
Khóa luận tốt nghiệp Chiến lược chuyển đổi dữ liệu khách hàng tại ngân hàng BIDVvà đánh giá trên hệ thống SMLC
Giải thích code: Chuyển đổi các trường giá trị tương ứng từ bảng trung gian sang bảng Staging.
Sau khi đẩy dữ liệu vao bảng Staging, đội chuyển đổi dữ liệu sẽ xem luồng dữ liệu chạy từ luồng dữ liệu và đưa ra các đoạn lệnh tương ứng để phục vụ công việc chuyển đổi.
Giả sử: ID của khác hàng sẽ được đẩy như thế nào ? sau khi xem xét kĩ lưỡng luồng đi dữ liệu và phạm vi chuyển đổi, để tránh việc bị trùng lặp dữ liệu khi chuyển đổi dữ liệu thành 2 đợt, phải có đánh dấu cờ cho các dữ liệu đã được chuyển đổi để khơng chuyển đổi những dữ liệu đó tránh bị trùng lặp thì ID của khách hàng sẽ được lấy như sau:
Đoạn code:
MERGE INTO MIG_CU001_STG A USING SML_CUSTOMER B
ON (A.CIF_NUMBER = B.CIF_NUMBER) WHEN MATCHED THEN
UPDATE SET A.ID = B.ID;
UPDATE MIG_CU001_STG A SET ID= SML_CUSTOMER_ID_SEQ.NEXTVAL WHERE ID IS NULL;
Giải nghĩa đoạn code: Sử dụng bảng ID của khách hàng từ SML_CUSTOMER để cập nhật ID của bảng Staging (MIG_CU001_STG) theo CIF_NUMBER để cập nhật ID vào bảng MIG_CU001_STG. Và nếu đối với những số CIF_NUMBER chưa tồn tại ở bảng
SML_CUSTOMER tức là chưa có khách hàng tồn tại thì sẽ sinh ID theo quy tắc sinh
trường dữ liệu ID.
Mục đích là để khơng bị trùng lặp khách hàng giữa 2 đợt chuyển đổi.
Sau khi đẩy dữ liệu vào bảng Staging, đội ngũ chuyển đổi sẽ kiểm tra dữ liệu theo quy tắc 1 và 2 theo quy tắc kiểm tra dữ liệu bên trên.
Nếu dữ liệu không đáp ứng được theo các quy tắc kiểm tra, dữ liệu sẽ được đẩy sang bảng lỗi và sẽ được ghi chính xác lỗi gì theo quy tắc kiểm tra. Đồng thời đội ngũ chuyển đổi sẽ tạo báo cáo QC3 về số lượng bản ghi không đáp ứng được theo quy tắc kiểm tra dữ liệu.
Nếu dữ liệu đáp ứng được các quy tắc kiểm tra, dữ liệu sẽ được cân nhắc để chuyển đổi, đồng thời tạo ra báo cáo QC4 về số lượng bản ghi sẵn sàng chuyển đổi .
Bộ báo cáo QC3, QC4 sẽ được dùng để đối chiếu với báo cáo QC2 để đảm bảo toàn bộ các dữ liệu tải lên đã được kiểm tra.
Khóa luận tốt nghiệp Chiến lược chuyển đổi dữ liệu khách hàng tại ngân hàng BIDVvà đánh giá trên hệ thống SMLC
STG.ID=ERR.TABLE_IDAND TABLE_NAME='MIG_CU001_STG'));
Giải nghĩa code: sẽ cập nhật giá trị trường IS_CONVERT=’N’ (tức là No- đánh dấu không được chuyển đổi) Neu có tồn lại ID trùng với ID trong bảng lỗi và có đúng tên bảng lỗi là MIG_CU001_STG.
Mục đích: Khơng đẩy các dữ liệu bị lỗi, các dữ liệu không đáp ứng quy tắc chuyển đổi.
Đối với các loại đã được chuyển đổi từ đợt 1 cũng sẽ có đánh dấu trạng thái thông qua đoạn code sau:
UPDATE MIG_CU001_STG STG SET IS_CONVERT='P' WHERE
(EXISTS (SELECT 1 FROM SML_CUSTOMER PAS WHERE STG.ID=PAS.ID ));
Giải nghĩa đoạn code: sẽ cập nhật giá trị trường IS_CONVERT=’P’ (tức là Passed- đã được chuyển đổi) nếu mà ID của bảng Staging trùng với ID của bảng
SML_CUSTOMER.
Mục đích: Đánh dấu những dữ liệu đã được chuyển đổi từ lần trước, đã tồn tại trong hệ thống mới để không phục vụ cho đợt chuyển đổi này.
Bước 4: Đội ngũ chuyển đổi thực hiện chuyển dữ liệu hợp lệ sang hệ thống SmartLender và kiểm tra tính rằng buộc của dữ liệu (Quy tắc 3).
Đối với dữ liệu chuyển đổi thành công sẽ tạo ra báo cáo QC5 về số lượng dữ liệu đã chuyển đổi thành công và báo cáo QC7 là chi tiết đầy đủ dữ liệu chuyển đổi thành công.
Đối với dữ liệu chuyển đổi không thành công sẽ tạo ra báo cáo QC8 là chi tiết đầy đủ dữ liệu chuyển đổi không thành công
Đoạn code dùng để chuyển đổi dữ liệu sang hệ thống mới: Đẩy vào bảng SML_CUSTOMER
INSERT INTO SML_CUSTOMER A
(ID,VERSION_TI M E, LAST_U PDATE_DATE,CREATION_DATE, I D_TYPE
, I D_COUNTRY , BORROWER_STATUS_ID, BORROWER_TYPE_ID
,INCORPORATION_DATE,CLASSIFICATION_ID
,CUSTOMER_TYPE,WITH_BANK_SINCE_DATE,BACKEND_IND,AML_IND,RM_ID,BRAN CH ID,DIVISION ID,COMMENCEMENT YEAR,INDUSTRY ID,FIRST CREDIT GRANTE
D_DATE,NEXT_RM_ID,DEPRECATED,ORIG_GROUP_ID,MAS_INDUSTRY_ID,ACC_CRE ATED_DATE, RELATIONSH I P_SINCE_YEAR,FACILITY_GRANTED_DATE,HOLD_MAI L_I ND,INDUSTRY_RISK_ID,MAS_OWNER_CODE_ID,SM_IND,SEGMENT_ID
,CONFIDENTIAL_IND,SUSPENDED,BLACKLISTED,EAR_FLAG ,BANK_ENTITY
,CONVERT_IND,PEP_STATUS,CREATE_BY,LAST_UPDATE_BY,CIF_NUMBER,ID_NUM
BER
,CUSTOMER_NAME,OFFICE_TEL_NO,OFFICE_TEL_NO_EXT,FAX_NO,FAX_NO_EXT,E
MAIL,SALES_OFFR_CODE,SALES_OFFR_NAME,STATUS,CTO_CODE
,OFFICE_TEL_NO_AREA,AA_NO,SECONDARY_ID_NUMBER,NPL_STATUS,BW_CTO_C
ODE,NEXT_RM_CTO_CODE,CUSTOMER_SEGMENT_ID,ACTIVE_REPORT_VERSION)
SELECT ID, 0, SYSDATE ,SYSDATE
,SM L_PRIMARY_ID_TYPE, SM L_PRIMARY_ID_COTR, NULL
,SML_CUST_CONSTITUSION,DATE_OF_INCORP ,SML_CLASSIFICATION
,CUSTOMER_TYPE,NULL ,NULL ,NULL ,NULL ,NULL ,NULL ,NULL
,NULL ,NULL ,NULL ,'N' ,NULL ,NULL
,DATE_CIF_CREATED,NULL ,NULL ,NULL ,NULL ,NULL
,NULL ,SML_SEGMENT_BIDV,NULL ,NULL , NULL , NULL
,SML_BANK_ENTITY,NULL , NULL , 'SML' , 'SML'
,CIF_NUMBER,PRIMARY_ID_NUMBER,CUST_NAME , NULL , NULL , NULL ,
NULL , NULL, NULL ,NULL , NULL ,PRIMARY_0FFICER_C0DE , NULL
, NULL, NULL , NULL , NULL , NULL ,SML_SEGMENT_BIDV ,NULL
FROM MIG_CU001_STG B where CUSTOMER_TYPE='C' AND IS_CONVERT='Y';
Đẩy dữ liệu vào bảng SML_INDIVIDUAL_CUSTOMER
,SML_NATIONALITY ,NULL , NULL , NULL, NULL ,
NULL , NULL
,NUL , NULL ,NULL ,NULL ,NULL , NULL
,NULL , NUL L , NULL , NULL ,'SML' ,'SML' ,NULL ,FIST_NAME , NUL L
,NULL ,NULL , NULL , NULL , NULL
Khóa luận tốt nghiệp Chiến lược chuyển đổi dữ liệu khách hàng tại ngân hàng BIDVvà đánh giá trên hệ thống SMLC
INSERT INTO SML_INDIVIDUAL_CUSTOMER A
(ID,CREATION_DATE,LAST_UPDATE_DATE,SALUTATION_E_ID,SALUTATION_L_ID,GE NDER_ID
,MARITAL_STATUS_ID,DATE_OF_BIRTH,NO_OF_DEPENDENTS,COUNTRY_OF_CITIZE NSHIP_ID,COUNTRY_OF_RESIDENCY_ID,PR_STATUS,RACE_ID,HIGHEST_EDUCATIO N_ID,RES_OWNERSHIP_ID,RES_TYPE_ID,RES_SINCE_YEAR,FAMILY_REF_RELATION SHIP,HOME_TEL_NO,HOME_TEL_EXT,MOBILE_NO,FAMILY_REF_CONTACT_NO_EXT, FAMILY_REF_CONTACT_NO,HOME_TEL_NO_AREA,MOBILE_NO_AREA,EMPLOYEE_I D,CREATE_BY,LAST_UPDATE_BY,SALUTATION_SUFFIX_E,FIRST_NAME_E,LAST_NA ME_E,SALUTATION_SUFFIX_L,FIRST_NAME_L,LAST_NAME_L,OTHER_RACE,FAMILY_
REF_NAME)
SELECT ID,SYSDATE ,SYSDATE ,NULL , NULL
, LAST_UPDATE_DATE, PROFESSIONAL_PRACTICE_ID,COUNTRY_OF_INC_ID ,COUNTRY_OF_OPERATION_ID,NGO_MEMBER,S35_RELATED,MANAGEMENT_TYPE_ ID,LOCAL_EQUITY_PERC,PREMISE_OWNED,ANNUAL_INTEREST_RATE,MAX_DAYS_ OVERDUE,NRCC_ID,BOT_CUSTOMER_TYPE_ID,MANDATORY_INFO_UNAVAIL_IND,M ORE_THAN_50_PRCT_TURNOVR_IND,CREATE_BY,LAST_UPDATE_BY,NAME_E ,NAME_L ,SOURCE,HOST_CIF_NUMBER,ORIG_COUNTRY)
SELECT ID,SYSDATE ,SYSDATE ,NULL
,SML_COTR_OF_INCORP ,SML_COTR_OF_BUSI_OPER ,NULL ,NULL ,NULL
,NULL ,NULL ,NULL ,NULL ,NULL ,NULL ,NULL
,NULL ,'SML' ,'SML' ,HOST_LEGAL_NAME,NULL ,NULL ,NULL
,NULL
FROM MIG_CU001_STG B WHERE CUSTOMER_TYPE='C' AND IS_CONVERT='Y';
Đẩy dữ liệu vào bảng SML_ADDRESS
INSERT INTO SML_ADDRESS(ID
,VERSION_TIME,CREATION_DATE,LAST_UPDATE_DATE,CUSTOMER_ID,"TYPE",COU NTRY_ID,
STR_ADDRESS_FORMAT_ID, UNSTR_STATE_ID,ADDR_3,ADDR_4, PROVINCE ,ZIP_CODE
,STR_BLOCK,STR_STOREY,STR_UNIT,STR_BOX,STR_BUILDING,STR_STREET,STR_S
TATE ,UNSTR_CITY,SEQ_NO,CREATE_BY,LAST_UPDATE_BY,ADDR_1,ADDR_2)
SELECT SML_ADDRESS_ID_SEQ.nextval,0 ,SYSDATE ,SYSDATE ,ID
,'R' ,SML_REG_ADDRESS_COTR,SML_ADDRESS_FORMAT ,NULL ,NULL ,NULL
,SML_REG_ADDRESS_PROVINCE,REG_ADDRESS_POSTCODE,NULL ,NULL
,NULL ,NULL ,NULL ,NULL ,REG_ADDRESS_CITY ,NULL ,NULL ,'SML'
,'SML' ,NULL ,NULL
FROM MIG_CU001_STG B where IS_CONVERT='Y' ;
Bước 5: Kiểm tra trực tiếp.
Đội ngũ chuyển đổi sẽ kiểm tra trực tiếp trên hệ thống mới để xem các dữ liệu sau khi chuyển đổi có thành cơng hay khơng.
Tổng hợp các báo cáo sau đây sẽ được tạo ra trong q trình chuyển đổi:
• Báo cáo QC 1 - Số bản ghi đã được xuất ra từ hệ thống nguồn. Báo cáo này được tạo ra từ hệ thống nguồn của BIDV. Báo cáo này do IT của BIDV xây dựng và kết xuất.
• Báo cáo QC 2 - Số bản ghi đã được tải lên từ dữ liệu trung gian vào SMLC cho các bước tiếp theo. Báo cáo này do đội chuyển đổi xây dựng và kết xuất.
• Báo cáo QC 3 - Số bản ghi không vượt qua phần kiểm tra theo quy tắc 1 và 2 (bảng quy tắc chuyển đổi ở trên). Báo cáo này do đội chuyển đổi xây dựng và kết xuất.
FROM MIG_CU001_STG B WHERE CUSTOMER_TYPE='I' AND IS_CONVERT='Y';
• Báo cáo QC 4 - Số bản ghi đã kiểm tra và sẽ được chuyển đổi vào SMLC. Báo cáo này do đội chuyển đổi xây dựng và kết xuất.
• Báo cáo QC 5 - Số bản ghi đã chuyển đổi thành công trong SMLC. Báo cáo này do đội chuyển đổi xây dựng và kết xuất.
• Báo cáo QC 7 - Chi tiết bản ghi đã chuyển đổi thành công. Báo cáo này do đội chuyển đổi xây dựng và kết xuất.
• Báo cáo QC 8 - Chi tiết bản ghi chuyển đổi không thành công. Báo cáo này do đội chuyển đổi xây dựng và kết xuất.
3.6 Lược đồ quan hệ và dữ liệu cho việc chuyển đổi
3.6.1 Lược đồ quan hệ của khách hàng
Ta có thể xác định được các bảng có liên kết chi tiết với việc chuyển đổi về phân hệ khách hàng thông qua biểu đồ sau:
Field Defination SMLC Field
Name nI d
Field
Type DataType Leng th
Dec
imal Remark Mf
O
Validation Screen Field
Name Location atapplication ClassUDF Common Code UDF SetDB Table/ ColumrDB
Listed or
Not Checkbox CHAR
1 Default: No M Listed or Not View
Customer
Bank Entity CCL VAR
CHA 60 Default:VIETNAM. BIDV - M Bank Entity ViewCustomer
Nationality X DDL VAR
CHA κ> Γnrr.n⅞ιn. Cr⅛-ΓΓ>I INTRV Õ Nationality ViewCustomer UNTRY CO SMLjNDlVIDUALeCUSTOM COUNTRYeOFeCIT
Gender X DDL VAR
CHA ẽõ CommonGENDER Cxxfe: O Gender ViewCustomer GENDER SMLjNDlVIDUALeCUSTOM GENDEReID
Marrtal
SUtua × CCL VARCHA 60 CommonIiAHlIAL-SIAILIS________ Code: O Marrul SUtus ViewCustomer eSTATUSMARITAL SMLjNDlVIDUALeCUSTOM MARITALeSTATUSe PrimaryJD Country x DDL VAR CHA R2 60 To define the ID is issue from which country U Issued
Country ViewCustomer DeUiIs
CO
UNTRY SMLeCUSTOMER IDeCOUNTRY PrimaryJ
DeType DDL VARCHA
R2
ẽõ I' Ccte = ~r and if is New IC
format default "IN"
Else default 'OΓ M Type View Customer Deuils - Demographic
IDTYPE SMLeCUSTOMER IDeTYPE PrimaryJ DeN umber x Alph a VARCHA R2 40 Individual customer Storeas ID Number, for M Number View Customer Deuils SVLeCUSTOMER IDeNUMB ER
Khóa luận tốt nghiệp Chiến lược chuyển đổi dữ liệu khách hàng tại ngân hàng BIDVvà đánh giá trên hệ thống SMLC
Hình 14. Biểu đồ ERP khách hàng
Nguyễn Hồng Hiệp - K17HTTTB Trang 45
Chiến lược chuyển đổi dữ liệu khách hàng tại ngân hàng BIDVvà đánh giá trên hệ thông SMLC Khóa luận tơt nghiệp
Từ bảng liên kết dữ liệu trên ta có thể thấy được bảng chính lưu trữ thơng tin khách hàng là bảng SML_CUSTOMER.
Ngồi ra có các bảng phụ khác như:
• SML_INDIVIDUAL_CUSTOMER: dùng để lưu trữ thơng tin khách hàng cá nhân.
Bảng này sẽ được kết nối với bảng SML_CUSTOMER thông qua ID dùng chung giữa 2 bảng.
• SML_ADDRESS: dùng để lưu trữ thông tin về địa chỉ của khách hàng.
Bảng này sẽ được kết nối với bảng SML_CUSTOMER thông qua trường ID_CUSTOMER của bảng SML_ADDRESS với ID của bảng chính.
• SML_COMPANY_CUSTOMER: dùng để lưu trữ thơng tin về cơng ty của khách hàng thuộc nhóm khách hàng doanh nghiệp hoặc tổ chức tín dụng.
Bảng này sẽ được kết nối với bảng SML_CUSTOMER thông qua ID dùng chung giữa 2 bảng.
• SML_CUSTOMER_CONTACT: dùng để lưu thơng tin người liên hệ khác nếu cần.
Bảng này sẽ được lưu trữ độc lập.
• SML_CUSTOMER_WORKPLACE: dùng để lưu trữ nơi làm việc của khách
hàng.
Bảng này sẽ được kết nối với bảng SML_CUSTOMER thông qua ID dùng chung giữa 2 bảng.
÷ Thơng qua việc xác định các liên kết này, đội ngũ chuyển đổi có thể tìm các