304315 data warehousingsci.feu.ac.th/supattanawaree/datawarehouse.pdfdata warehouse...

304315

Data Warehousing

อาจารยสุพฒันวรี ทิพยเจริญภาควิชาเทคโนโลยีสารสนเทศ คณะวิทยาศาสตรและเทคโนโลยี

มหาวทิยาลัยฟารอีสเทอรน

Chapter 1Introduction to

Data Warehouse



เนื้อหา1. องคกรและปญหาในการวิเคราะหขอมลู2. Business Integration ที่มาของ Data Warehouse3. คลังขอมูลคืออะไร4. การวิเคราะหขอมูลในคลังขอมูล

องคกรและปญหาในการวิเคราะหขอมูลจุดหมายขององคกรคือ การดําเนินกิจการขององคกรใหไดรับผลประโยชนสูงสุดตองมกีารบริหารงานที่ดี เที่ยงตรง ทรัพยกรเพียงพอ มีบคุลากรที่มีคุณภาพ รวดเร็วทันเหตุการณองคกรจําเปนตองเก็บบันทกึขอมลูที่เกี่ยวของกับกิจกรรมและผลที่เกิดจากการทํากิจกรรมขององคกรไว เพื่อนํามาวิเคราะหหาแนวทางในการดําเนินกิจกรรมขององคกรในอนาคต

องคกรและปญหาในการวิเคราะหขอมูล

Business Integration ทีม่าของ Data WarehouseBusiness Integration เปนแนวคิดทีจ่ะขจัดปยหาที่เกิดจากSilo-based System

การรวมกันนี้สามารถทําไดสองรูปแบบไดแก

1. Partial Business Integration2. Overall Business Integration

Partial Business Integration

คือการรวบรวมระบบโดยใหระบบเดมิยังคงไวแตเพิ่มขีดความสามารถในการติดตอสือ่สารแลกเปลี่ยนขอมูลระหวางระบบขององคกร ซึ่งการสื่อสารสามารถทําไดหลายรูปแบบ

Point to Point Business Integrationการสรางชองทางแลกเปลี่ยนขอมูลจุดสองจุดหมายถึงการเชื่อมโยงระหวางระบบสองระบบ ใหระบบทั้งสองสามารถติดตอกันได

Partial Business Integration

Middleware Business Integrationการพยายามลดสภาวะ Spaghetti Phenomenon ของการรวมระบบแบบ Point to Point โดยการนําเอา Hardware และ Software หรือกลุมของ Hardware Software มาทําหนาทีเปนตัวกลางในการแลกเปลี่ยนขอมูลระหวางระบบงานตางๆ ซีง่เรยีก H/W S/W เหลานั้นวา Middleware

Overall Business Integrationการออกแบบและพัฒนาระบบใหม โดยการรวมเอาเนื้อหาของ

ขอมูลทั้งหมดในองคกรใหเปนหนึ่งเดียว ไมแยกออกเปนสวนๆ หรือ การทําใหระบบทีม่ีอยูหลากหลายในองคกร รวมกันเปนระบบเดียวกัน เนื้อหาเดียวกันหลักการทํา Overall คือ การสรางระบบขอมูลใหมเพยีงหนึ่งเดียวแตสามารถทดแทนระบบงานเกาๆที่แยกเปนอิสระจากกันได

คลังขอมูลคืออะไรหลักการหรือวธิีการที่มาจากการทํา Overall

Business Integration ที่สามารถชวยใหการวิเคราะหขอมูลเพื่อทําการตัดสินใจ เพื่อการบริหารงานในองคกรเปนไปไดอยางมีประสิทธิภาพหลักการ หรือวิธีการและแนวทางแกปญหา เนื่องจากแตละองคกรจะมีความแตกตางกันมีความสามาถทําใหผูวิเคราะหขอมูล สามารถเลือกวิเคราะหขอมูลแบบเจาะลึก (drill down) หรือ แบบเปนภาพรวม (roll up)ไดอยางอิสระ

การคลังขอมูล (Data Warehousing)วิธีการเพื่อใหไดมาซึ่งขอมลู วิธีการสรางผลลัพธจากขอมลูที่มี รวมไปถึงวิธีการดูแลรักษา วิธีการปรับปรุงประสิทธิภาพ กระบวนการใน Data Warehousing ประกอบดวย

การรับขอมูล (Data Acquisition) การสถานะขอมูล (Data Staging) การจัดเก็บขอมูล (Data Store)

การเตรียมขอมูลเพื่อใชงาน (Data Provisioning)

การวิเคราะหขอมูลในคลังขอมูลในคลังขอมูลจะแบงออกเปนสองสวนคือ

ขอมูลเพื่อการปฏิบัติงาน เปนขอมูลทีเ่กิดจากการสั่งสมกิจกรรมและผลการปฏิบัติงานขององคกร ซึ่งผานระยะเวลาที่ยาวนาน หากจะนําขอมูลไปใช ตองผานกระบวนการประมวลผลกอน เปนการวิเคราะหขอมูลแบบ Query and Reportingขอมูลเพื่อการวิเคราะห เปนขอมูลทีเ่กิดจากการพยายามใชเครื่องมือที่มีอยูในการจัดการดานคํานวณ และรวบรวมขอมูลทีม่ีประโยชนตางๆใหอยูในรูปแบบที่พรอมตอการใชงาน โดยไมตองนํามาประมวลผลอีก เปนการวิเคราะหขอมูลแบบ Multidimensional Data Analysisทั้งสองสวนจะถูกนํามาใชใน Data Mining

การวิเคราะหขอมูลในคลังขอมูลQuery and ReportingMultidimensional Data AnalysisData Mining

Chapter 2สถาปตยกรรมคลังขอมลู

Data Warehouse Architecture



เนื้อหา1. สวนประกอบตางๆของคลังขอมูล และสถาปตยกรรมของคลังขอมูล2. สถาปตยกรรมของ Data Warehouse3. สถาปตยกรรมแบบตางๆของคลังขอมูล4. ทางเลือกและแนวทางในการพัฒนาคลังขอมูล

สวนประกอบตางๆของคลังขอมูลประกอบดวย 3 องคประกอบหลักสวนของการนําขอมูลเขา (Input)สวนของการประมวลผล (Process)สวนของการนําผลลัพธออกแสดง (Output)

Data Acquisition System ทําหนาที่เปนผูรับขอมูลมาจากภายนอก ทั้งภายในและภายนอกองคกรขอมูลจะตองทําการตรวจสอบความถูกตองกอนในขั้นตน ทําหนาที่เปนผูติดตอใหกับผูใชขอมูล

Data Staging Areaทําหนาที่เปนเสมอืนดานศลุกากรของคลงัขอมลู เปนที่พักและตรวจตราขอมลูในรายละเอียดจาก Data Acquisition Systemขอมูลจะถูกดําเนนิการโดยกระบวนการหลายๆอยางเพื่อทําใหขอมูลนัน้พรอมสําหรับการนําไปเก็บไวที่ Data Warehouse Database

Data Warehouse Databaseถูกใชเพื่อเกบ็บนัทึกขอมูลตางๆ ที่จําเปนสําหรับการวิเคราะหขอมูลขององคกร กระบวนการตางๆที่ทําใน Data Acquisition System และ Data Staging Area ถือเปนกระบวนการที่ทําเพื่อใหขอมูลสามารถเก็บบันทกึใน Data Warehouse Database ไดอยางถูกตอง ในขณะที่ผลลพัธตางๆที่ตองการสามารถดึงไดจาก Data Warehouse Database เชนเดยีวกัน Data Model และ Data Warehouse Database เปรียบเสมือนเปนหัวใจของ Data Warehouse

Data Warehouse Databaseขอมูลจะมีความแตกตางจากระบบสารสนเทศทั่วๆไป คือ Data Warehouse นัน้ขอมลูที่เก็บไวจะมลีกัษณะของการเก็บแบบตลอดไป ไมแกไขขอมูลหากไมจําเปนหากมีการเปลี่ยนแปลงขอมลู จะเปนลกัษณะของการเพิ่มเตมิเขาไปและปลอยใหขอมลูตวัเดิม มีสภาพเปนประวัติศาสตรของขอมูลตัวปจจุบนัแทน

Data Provisioning Area หรือ Data Martทําหนาที่ในการบันทึก ขอมูลและผลลัพธตางๆที่จําเปนสําหรับการวิเคราะหขอมูล ซึ่งขอมูลจาก Data Warehouse จะถูกดงึและประมวลผลแลวนําผลที่ไดมาเกบ็ไวที่ Data Provisioning Area วึ่งโครงสรางของขอมลูอาจจะมีลกัษณะคลายกับใน Data Warehouse Database หรืออาจจะเปนโครงสรางขอมูลที่เหมาะสมสําหรับการนําขอมูลไปใชงานData Mart ตัวหนึง่เสมอืน การตัดเอาบางสวนของ Data Warehouse Database มาวางไว เพื่อตอบสนองการใชงานของบางกลุมเทานั้น

End Users Terminalเปนสวนที่ทําหนาที่ดึงเอาขอมูลที่ไดถูกเตรียมไวใน Data Provisioning Area หรือแมแต Data Warehouse Database เพื่อนาํเสนอผลลพัธที่ใชสําหรับการวิเคราะหขอมลู ทําหนาที่ออกรายงาน Simple Reporting Tools หรือ Multi Dimensional Tools หรือ Data Mining Tools กได

Meta data Repositoryทําหนาทีเปนพืน้ที่ที่ใชสําหรับเก็บขอมูลตางๆที่จําเปนสําหรับการควบคุมการทํางานและควบคุมขอมูลในคลงัขอมลู ซึ่งเรียกวา Metadata โดยจะมีขอมลูที่เกี่ยวกับขอมลูตางๆใน Data Acquisition System, Data Warehouse Databaseและ Data Martเปรียบเสมอืนไดวาเปน สมอง ของคลงัขอมูล ที่ทําหนาที่จดจําและควบคุมการทํางานของคลังขอมูล

สถาปตยกรรมแบบตางๆของคลังขอมูลCentralized Data Warehouse Database ArchitectureDistributed Data Warehouse Database ArchitectureMixed Data Warehouse Development

Centralized Data Warehouse Database Architectureรูปแบบของสถาปตยกรรมของคลังขอมูลที่ Data Warehouse Database ถูกเก็บเปนกลุมกอนเดียวไมไดมีการแยกหรือวากระจาย ออก ขอดี

การรักษาความปลอดภัย และ บํารุงรักษาทําไดงาย สามารถสรางความเปนปกแผนของขอมูลไดงายที่สุด

ขอเสียมีความเสี่ยงในการไดรับความเสียหายมากกวาสถาปตยกรรมแบบอื่นๆในการออกแบบและสรางทําไดยากที่สุด

Distributed Data Warehouse Database Architectureสถาปตยกรรมของ Data Warehouse ที่มีการกระจายออก โดยอาจจะอยูบน Disk ตัวเดียวกันหรือคนละตัวก็ไดเพื่อสรางความคลองตัวในการใชงานขอดี

เปนคลังขอมูลทีม่ีสถาปตยกรรมที่สามารถสรางไดงายกวา Centralized Data Warehouse เปนสถาปตยกรรมที่สามารถกระจายความเสี่ยงในกรณีที่อาจจะเกิดความเสียหายขึ้นกับระบบไดดี

ขอเสีย มีโอกาสที่ขอมูลอาจจะขาดความเปนอนัหนึ่งอันเดียวกันการรักษาความปลอดภยัทําไดยากกวา Centralized Data Warehouse

การพัฒนาคลังขอมลูดวยหลักการพัฒนาจากบนลงลาง ( Top-Down )

เปนหลกัการที่เหมาะสมในการใชเพื่อพฒันา Centralized Data Warehouse โดยยึดถือแนวทางที่จะทําใหได Data Warehouse รวมของทั้งองคกืรในคราวเดียว โดยเริ่มพัฒนาจะเริมจากการวิเคราะหธุรกจิองคกรทั้งหมด และ ออกแบบ Data Model ที่เปนภาพรวมของธุรกิจทั้งหมดขององคกร แลวจึงคอยๆวิเคราะหถึง Input และ Output ขององคกรเพื่อพฒันา Data Mart ตอไป

การพัฒนาคลังขอมลูดวยหลักการพัฒนาจากบนลงลาง ( Top-Down )ขอดี

Data Model ที่ไดจะเปน Data Model ในอุดมคติที่สามารถอธิบายธุรกิจขององคกรไดอยางถูกตองเปนหนึ่งเดียว เหลืองานเพิ่มเติมนอยกวาเมื่อพัฒนาเสร็จไมจําเปนตองรักษาความสอดคลองของขอมูล

ขอเสีย มคีวามยากในการออกแบบ และตนทุนสูง มีขอจาํกัดมาก มีขนาดใหญตองใชเวลา งบประมาณ และกําลังคนจํานวนมาก

การพัฒนาคลังขอมลูดวยหลักการพัฒนาจากลางขึ้นบน (Bottom - Up)จะตรงขามกับแบบ Top-Down จะเริ่มจากการวิเคราะหและออกแบบผลลพัธและขอมูลนําเขาทีละสวนแลวจึงออกแบบ Data Model ทีละสวนไปพรอมๆกนักับการอกแบบ Data Acquisition System ,Data Staging และ Data Mart จากนัน้จึงคอยๆทํากระบวนการพัฒนาแบบเดียวกันนีจ้นกวาจะครบทุกๆ Data Mart ที่จําเปนจะตองมีขององคกรหลังจากนัน้จึงอาจจะมกีานําเอาขอมูลที่มอียูในแตละ Data mart มารวมกนัเพื่อออกแบบและสราง Data Model และ Data Warehouse Database ของทั้งองคกรในภายหลัง

การพัฒนาคลังขอมลูดวยหลักการพัฒนาจากลางขึ้นบน (Bottom - Up)ขอดี

ผูใชงานสามารถใชงานไดอยางรวดเร็ว การพัฒนา Data Mart แตละตัวมีความซับซอนนอยกวาแบบ Central ตนทุนและเวลาที่ใชสําหรับการออกแบบและสราง Data Mart แตละตัวนอยกวาที่ใชการออกแบบแบบ Top-Down

ขอเสีย การควบคุมความซ้ําซอนของขอมูลทาํไดยากกวาแบบ Top-Down กระบวนการตางๆใน Data Warehouse อาจมกีารนําเขาขอมูลมากเกินความจําเปนการนํามารวมกันของ Data Mart ทําไดยากและใชเวลานานมาก

Mixed Data Warehouse Developmentเปนการพัฒนาระบบ Data Warehouse โดยแยกขอมลูออกเปนสวนๆ แลวพิจารณษเลอืกวิธกีารวิเคราะหและออกแบบ ที่เหมาะสมสําหรับขอมลูแตละสวน แลวจึงนําเอาสวนที่ไดพฒันาแลวมารวมกนัในภายหลัง

Chapter 3การวิเคราะหธุรกิจขององคกรและการแบงขอบเขตเนื้อหาขอมูล

Business Content Analysis and Subject Area



เนื้อหา1. การศึกษากิจกรรมขององคกร2. Business Process Diagram (BP)3. Subject Area4. Case Study

สวนประกอบตางๆของคลังขอมูลประกอบดวย 3 องคประกอบหลักสวนของการนําขอมูลเขา (Input)สวนของการประมวลผล (Process)สวนของการนําผลลัพธออกแสดง (Output)

Business Content AcquisitionData Warehouse ตองอาศัย User Requirements และการตอบสนองเรื่องราวการดําเนินกิจการขององคกร (Process) การไดมาของขอมูล (Input) การใชงานขอมูลได (Output)ซึ่งรวมทั้งสามสวนเรียกวา Business Content

การศึกษา Output ขององคกรถือเปนกระบวนการที่งายที่สุดในสามสวน ตองพจิารณาวาผลลัพธที่ไดนาํไปใชเพื่ออะไร ความหมายของแตละหนวยของสารสนเทศ(Information) ขอเท็จจริง End User เปนผูที่ทราบถึงความหมายและการใชงานของ Output ตางๆควรมีการแบงหนาที่ของทีมในการสัมภาษณ End User เนือ่งจากมหีลายกลุมตองสราง Output Template เพื่อความมมีาตรฐาน

การศึกษา Input ขององคกรถัดจากการพิจารณา Output คือการสํารวจหา Input วามีอะไรบาง หาไดจาก ผูรวบรวมขอมูล ทีมงานสรางระบบตางๆ Input จะชวยบอก data source

การพิจารณาความซ้ําซอนของ Input และ Outputจําเปนที่จะตองนาํทั้งสองสวนมาหาความซ้ําซอน เพื่อเปนการลดภาระในการดูแลขอมูลชดุเดียวกันในหลายๆที่ ซึ่งอาจกอใหเกดิความไมสอดคลองกนัของขอมูลไดลดจํานวนขอมลูที่ตองดแูลใหนอยที่สุด แตมีประสิทธิภาพสูงสุดในการวิเคราะหขอมลู

Business Process Diagram (BP)เปนแผนภาพที่ใชเพื่อแสดงความสัมพนัธระหวางกระบวนการทํางาน Input และ Output เห็นกจิกรรมทั้งหมดตั้งแตการเขามาของขอมูลจนกระทั่งไดผลลัพธ (End-to-End Activities)ขององคกรมีจดุประสงคคือ

เพื่อศึกษา Process ขององคกร โดยใช Input และ Output ที่ไดรวบรวมไว เพื่อเปนตนทางในการสราง BP เพื่อจําลองภาพของ Process ขององคกรไดเพื่อใชเปนเครื่องมือสื่อสารระหวางผูสรางคลังขอมูล และผูใชงาน

เปนสวนที่ทําหนาที่ดึงเอาขอมูลที่ไดถูกเตรียมไวใน Data Provisioning Area หรือแมแต Data Warehouse Database เพื่อนาํเสนอผลลพัธที่ใชสําหรับการวิเคราะหขอมลู ทําหนาที่ออกรายงาน Simple Reporting Tools หรือ Multi Dimensional Tools หรือ Data Mining Tools ก็ได

Business Process Diagram (BP)

Case Studyดูเอกสารประกอบ

Subject Areaเปนการแบงเนือ้หาของธุรกิจ (Business Subject Area) ขององคกร เปนขั้นตอนตอจากากรศึกษา Output และ Input ขององคกรแบงเปน Subject Area ทําใหสามารถมองภาพของธุรกิจขององคกรไดละเอียดมากขึ้น ละเอียดกวาการมองภาพของ Business เปนภาพรวมใหญทั้งหมด

Chapter 4แบบจาํลองขอมลูสาํหรับคลังขอมลู

Data Modeling for Data Warehouse



เนื้อหา1. แบบจําลองขอมูล2. Relational Data Model3. Dimensional Data Model4. Case Study

แบบจําลองขอมูลหมายถึง สิ่งใดสิ่งหนึ่งที่จําลองหรือแสดงขอเท็จจริง ของสิ่งใดสิ่งหนึ่งที่มีอยูจริงในโลก หากแตมคีุณสมบตัิบางประการที่ตางกันออกไปจากวัตถุจริง เชนในแงของขนาดหรือความสามารถ แบบจําลองปจจุบันที่นิยมสําหรับ Data Warehouse มีอยู 2 แบบคอื

Relational Data ModelDimensional Data Model

Relational Data Model->Staging Database และ Data Warehouse DatabaseDimensional Data Model -> Data Mart

แนวทางการสรางแบบจําลองขอมูลในคลังขอมูล

ยึดหลัก Iterative Process เริ่มจากการพัฒนา Logical Data Model แลวจึงเริ่มพัฒนา Physical Data Model

Logical Data Model

กระบวนการมีดังนี้1. ศึกษาความตองการของผูใชงาน รวมถึงเรื่องราวขอเท็จจริงตางๆของ

องคกร2. ออกแบบ Logical Data Model3. ตรวจสอบ Logical Data Model ที่ไดออกแบบไว ตรวจสอบ

รวมกับผูใชงานขอมลู รวมถึงการใหผูใชไดทดลองนําขอมลูที่มีอยูไปใชงาน

Physical Data Model

กระบวนการมีดังนี้1. ศึกษาและพิจารณา Logical Data Model ที่สมบูรณแลว ตามที่

ไดออกแบบไวเพื่อหาแนวทางในการสราง Physical Data Model

2. สราง Physical Data Model3. ทดสอบ Physical Data Model โดยทดลองนําเอาตัวอยาง

ขอมลูไปวิเคราะหตามวิธีการตางๆ

Relational Data Model1. การออกแบบ Logical Relational Data Model ดวยหลักการ

Abstractionทําได 4 แนวทางคือ

Classification AbstractionAggregation AbstractionAssociation AbstractionGeneralization Abstraction หรือ Specialization Abstraction

Classification Abstractionกระบวนการจัดกลุมหรือจัดประเภทของสิ่งของตางๆ (วัตถุ) ใหอยูในกลุมเดียวกัน (คลาส) อาศัยหลักการที่วา ภายในขอบเขตของความสนใจ (โดเมน) หนึ่งๆ วัตถุที่มีคุณสมบตัิเหมือนกัน ถือวาเปนวัตถุชนิดเดียวกัน (คลาสเดียวกัน)คุณสมบัติหมายถึง Attributesคุณสมบัตใินการแยกแยะวัตถุ ใหมีความแตกตางกันจากวัตถุตัวอื่นๆคือ Primary key

Aggregation Abstractionคือ กระบวนการหาความสัมพันธระหวาง คลาส ในลกัษณะการรวมกันของ คลาสที่แตกตางกนัชดุหนึ่งเพื่อสรางใหเกดิคลาสใหม คือ การแสดงการเปนสวนประกอบของคลาสชุดหนึ่งในคลาสตัวหนึ่ง

Association Abstractionคือ การบรรยายความสัมพนัธระหวางคลาสตางๆ ที่เราสนใจ ซึ่งเปนความสัมพนัธที่แตกตางจากกรณีของ Aggregation Abstraction เพราะ Association Abstraction จะบอกความเกี่ยวพันของ คลาส คูหนึ่งที่ไมใชการประกอบขึ้น แตเปนความสัมพนัธที่คลาสทั้งสองนัน้มีระดับของคลาสในระดับเดียวกัน

Generalization Abstraction คือ กลุมของ วัตถุ อาจเรียกวา เซต เราสามารถเรียก คลาส วาเปน เซตของวัตถุกระบวนการของเซตไดแก union , intersection

Subject AreaSubject Area ที่ใชใน Logical Data Model ที่เรียกวา Logical Subject Area Subject Area ที่ใชใน Physical Data Model ที่เรียกวา Physical Subject AreaSubject Area ประกอบดวย

ขอมูลที่เลาเรื่องราวของกิจกรรมและความเปนไปขององคกร->Relational Data Model ขอมูลเพื่อการใชงาน-> Dimensional Data Model

3.2-3.3-3.4 ศึกษาจาก Case Study

OLAP and Cubes ดูเอกสารประกอบ

Chapter 5การออกแบบระบบการรบัขอมูลในคลงัขอมูลData Acquisition Design



เนื้อหาData Acquisition

ทําไมตอง Data Acquisition ขอควรคํานึในการออกแบบระบบ Data Acquisition การรักษาความปลอดภัยในการสงขอมูล ระบบการเตรียมขอมูลของผูที่สงขอมูล

การออกแบบและสรางชุดขอมูล (Data Acquisition File) การวิเคราะหขอมูลกอนการออกแบบ Data Acquisition file หลักการออกแบบรูปแบบของ Data Acquisition File

Data Acquisition ทําหนาที่ในสวนของการรับขอมูลในระบบคลังขอมูล โดยสามารถรับขอมูลไดจากทั้งภายในและภายนอกขององคกรได

ทําไมตองมี Data Acquisition เพื่อทําหนาที่ในการรับขอมูลและเตรียมขอมูลในเบื้องตน เพื่อใหพรอมสําหรับการนําไปใชตอไปใน Data Staging Areaหนาที่ของ Data Acquisition คือ

ตรวจสอบแกไขขอมูลที่มีขอผิดพลาดเบื้องตนทําใหขอมูลไมมีสิ่งแปลกปลอมทีอาจทําใหระบบคลังขอมูลเกิดความผิดพลาดในการทํางาน ระบุไดวาใครเปนผูที่สงขอมูลเขามายังระบบ รวมถึงวัน และ เวลาที่ขอมูลเขามาสูระบบ ในกรณีที่เนื้อหาของขอมูลมีความผิดพลาดอยางใดอยางหนึ่ง ตองสามารถแจงกลับไปยังผูสงขอมูลไดดวย

ทําไมตองมี Data Acquisition เริ่มตนคือ การรับขอมูลมีหนาที่แรกคือ ตรวจสอบวามีผูสงขอมูลดังกลาวเปนผูไดรับสิทธิ์ ในการสงขอมูลหรือไม ถาไมใช ขอมูลที่ถูกสงตอมาตองถูกผลักดัน (Rejected) ออกไป ในกรณีที่ผูสงขอมูลเปนผูมีสิทธิ์ถูกตอง สิ่งที่ระบบตองทําตอไปคือ การตรวจสอบวาขอมูลที่สงมานั้นมีสิ่งแปลกปลอมหรือไมระบบตองสามารถกําจัดขอมูลดังกลางและแจงสิ่งผิดปกติที่พบ กลับไปยังผูสงขอมูล ใหตรวจสอบและแกไขขอผิดพลาด และสงขอมูลกลับมาใหม แตถาขอมูลไมมีสิ่งแปลกปลอมใดๆสิ่งที่ตองทําตอไปคือการตรวจสอบวาขอมูลมีความถูกตองในเบื้องตนหรือไม

ทําไมตองมี Data Acquisition ถาไมถูกตอง ระบบจะแจงกลับไปยังผูสงขอมูลใหสงมาใหม แตถาขอมูลมีความถูกตองดีอยูแลว ระบบจะเขาสูกระบวนการโดนยายขอมูลไปยังสวนอื่นๆของระบบตอไปสรุป หนาที่หลักของ Data Acquisition คือ การทําใหขอมูลที่สงมาจากแหลงขอมูล สามารถถึงปลายทาง ซึ่งหมายถึงคลังขอมูลไดอยางถูกตอง และไมกอใหเกิดผลเสียหายตอระบบอันเกิดจากการผิดพลาดในการรับขอมูล

ขอควรคํานึงในการออกแบบระบบ Data Acquisition1. วิธีการสงขอมูล

- มีหลายวิธีเชนการสงขอมูลจากตนทางเปนกระดาษเพื่อใหเจาหนาที่ปลายทางการสงขอมูลผานทางสื่อ Online ตางๆ

การสงขอมูล Online มี 2 แนวหลักๆ คือ การสงขอมูลผานระบบปด (Closed Loop Submission System) และ การสงขอมูลผานทางระบบเปด (Opened Loop Submission System)

การสงขอมูลผานทางระบบปด การสงขอมูลไปยังระบบที่ประกอบไปดวย โครงสรางพื้นฐานทางการสื่อสารที่เปนสวนตัวสําหรับผูสงและผูรับเทานั้น โดยไมเปดสูสาธารณะ และไมใชโครงสรางพื้นฐานที่เปนสาธารณะตองการความเร็วและความคลองตัวในการสงขอมูลตองการรักษาความลับของขอมูลที่มีความสําคัญตองลงทุนสูง การขยายระบบใหมีขอบเขตใหญขึ้นหรือเปดสูสาธารณะเปนไปไดยาก

การสงขอมูลผานทางระบบเปด คือการสงขอมูลไปยังระบบที่เปดสูสาธารณะ เพื่อใชทรัพยากรตางๆในระบบสาธรารณะรวมกับระบบอื่นๆ เพื่อการสงขอมูล การสงขอมูลลักษณะนี้มีความยืดหยุนสูงงายตอการปรับเขากับระบบตางๆ และลงทุนต่ํา แตเนื่องจากการใชทรัพยากรรวมกับระบบตางๆ ตองใหความสําคัญกับเรื่องการรักษาความปลอดภัยของขอมูลเปนพิเศษ

ทําไมตองมี Data Acquisition การเลือกวิธการสงขอมูล เปนหนาที่ของผูออกแบบระบบ Data Acquisition ตองคํานึงถึงสิ่งตอไปนี้

การมีวิธีการสงขอมูลมากวาวิธีการเดียวยอมเปนสิ่งที่ดี ชวยไมใหเกิดความลาชา ซึ่งอาจกอใหเกิดผลเสียตอการวิเคราะหขอมูลได

ขั้นตอนในการสงขอมูล ในการสงขอมูล ทุกครั้งผูสงจะตองทําการแสดงตนกอน ไดแก user name และ password หรือใชระบบ Smart Card หลังจากนั้นก็จะทําการตรวจสิทธิในการสงขอมูลของผูสงขอมูลใหเปนที่ยอมรับในปจจุบันขั้นตอนนี้หากเปนระบบใหญจะใชเวลานานหากมีการสงขอมูลบอยครั้งในแตละวันอาจจะเกิดความไมสะดวก จึงไดมีระบบ Single Sign On System ซึ่งเปนระบบที่มีคุณสมบัติยินยอมใหผูสงขอมูลสามารถแสดงตนเพียงครั้งเดียวจนกวาผูสงขอมูลจะออก (Sign Off)

การตรวจสอบความถกูตองของขอมูลที่ไดรับดวย Validation Rules

พิจารณาความถูกตอง จําแนกได 2 แบบ คือ1. ความถูกตองในแงขอจํากัดตางๆ2. ความถูกตองในแงเนื้อหาขอมูลData Acquisition System จะใช Validation Rules ตางๆที่ไดกําหนดแลว เพื่อตรวจสอบความถูกตองของขอมูลโดย Validation Rules นั้นจะมีลักษณะเปนเงื่อนไขที่กําหนดใหกระทําการอยางใดอยางอหนึ่ง เมื่อเกิดขอผิดพลาดกับขอมูลที่สนใจ โดยที่เมื่อใดก็ตามที่ขอมูลถูกสงมาถึง Validation Rules ที่เกี่ยวของกับตัวขอมูลนั้นจะถูกเรียกมาใชงานอัตโนมัติ

ระบบการสื่อสารโตตอบกับผูสงขอมูล กรณีการสงขอมูลมีความถูกตองเปนปรกติ ระบบควรจะสื่อสารใหผูสงขอมูลทราบดวย เชนเดียวกันหากมีความผิดพลาดเกิดขึ้นก็ควรที่จะสื่อสารบอกใหผูสงไดทราบดวย

การรักษาความปลอดภัยในการสงขอมูล การรักษาความปลอดภัยของระบการสงขอมูล

มีการแตงตั้งผูตรวจสอบการรับขอมูลจากผูสง (Certificate Authority CA) ใชเทคโนโลยี Public Key Infrastructure ใชเทคโนโลยี Digital Signature

การรักษาความปลอดภัยของขอมูลมีการเขารหัส Encoding และกระบวนการถอดรหัส Decoding

ใชไดกับทั้งแบบ On Line และ Off Line System

การออกแบบและสรางชุดขอมูล(Data Acquisition File ) เพื่อ การสงขอมูล

การวิเคราะหขอมูลกอนการออกแบบ Data Acquisition File หลักการออกแบบ Data Acquisition File

สิ่งที่ตองคํานึงถึงในการออกแบบรูปแบบของ Data Acquisition File การอออกแบบโครงสรางขอมูลใน Data Acquisition File

หลักการพื้นฐายในการเลือกขอมูลเพื่อการสราง Data Acquisition File หลักการออกแบบ Data Acquisition File สําหรับ Entity ที่มีความสัมพันธกันแบบ One to One Relationship หลักการออกแบบ Data Acquisition File สําหรับ Entity ที่มีความสัมพันธกันแบบ One to Many Relationshipหลักการออกแบบ Data Acquisition File สําหรับ Entity ที่มีความสัมพันธกันแบบ Many to Many Relationship

การวิเคราะหขอมูลกอนการออกแบบ Data Acquisition File

ชุดขอมูล (Data Acquisition File) เปนชุดขอมูลที่จะถูกเตรียมโดยผูสงขอมูล และถือเปนแหลงเริ่มตนของที่มาของขอมูล ตองมีการวิเคราะหวาควรจะมีขอมูลใดอยูใน Data Acquisition File บางมีขั้นตอนการพิจารณาดังนี้

พิจารณา BP แยกเปนกลุม Subject Area

หลักการออกแบบ Data Acquisition File

สิ่งที่ตองคํานึงถึงในการออกแบบรูปแบบของ Data Acquisition FileData Acquisition File เปรียบเสมือน แบบฟอรม ที่ระบบสงใหกับแหลงขอมูลภายนอก กรอกขอมูลแลวกลับเขามาสูตนเอง

การออกแบบโครงสรางขอมูล ใน Data Acquisition File จําเปนที่จะตองมีการสรางโครงสรางที่ถูกตอง ที่สามารถบอกเลาขอเท็จจริงทั้งในแงเนื้อหาของขอมูล การใชขอมูล และ การออกแบบเพื่อทําใหเกิดความสมบูรณของขอมูลสําหรับผูใชงาน

หลักการพื้นฐายในการเลือกขอมูลเพื่อการสราง Data Acquisition File

สิ่งที่ตองคํานึงถึงอันดับแรกคือขอมูลที่ตองการใหแหลงขอมูลสงมาให ตองเปนขอมูลที่มีอยูจริง และมีความเปนไปได สําหรับแหลงขอมูลที่จะจัดหา ขอมูลที่สงมาควรเปนขอมูลดิบ เทานั้น ไมใชขอมูลที่เกิดจาการคํานวณ

Installment AgreementInstallment Action

หลักการออกแบบ Data Acquisition File สําหรับ Entity ที่มีความสมัพันธกันแบบ One to One Relationship

จะใชวิธีการยุบรวมทุกๆ attribute ของ entity ที่มีความสัมพันธกันไวใน Data Acquisition File เดียวกัน

หลักการออกแบบ Data Acquisition File สําหรับ Entity ที่มีความสมัพันธกันแบบ One to Many Relationship

Parent-Child Presentationเนนไปที่การแสดง Parent Entity เปนหลัก โดยให Child Entity เปนรายละเอียดยอยๆซึ่งมีไดมากกวา 1 รายการสําหรับแตละหนึ่ง Parent Entity

Referencing Presentation มีไวเพื่อแสดงขอมูลที่มีความสัมพันธแบบ One to Many Relationship ซึ่งมีโอกาสที่ Entity ในฝง Many อาจจะไมไดขึ้นกับ Entity ในฝง One เลยยึดแนวทางเดียวกับการออกแบบ Relational Database โดยการเพิ่ม Foreign Key ที่อางอิง ไปยัง Entity ฝง One เขาไปยัง Entity ฝง Many

หลักการออกแบบ Data Acquisition File สําหรับ Entity ที่มีความสมัพันธกันแบบ Many to Many Relationship

สามารถแสดงในรูปแบบของ Association Entity ซึ่งเปน Entity ที่สรางขึ้นมาเพื่อเก็บ Primary key ของ Entity ที่มีความสัมพันธกัน แตในการออกแบบ Data Acquisition File จะใชหลักการที่แตกตางกันออกไป เพราะสามารถใชหลักการ Referencing Presentation ที่ใชสําหรับ One to Many Relationship กับความสัมพันธเชิง Many to Many ไดเชนดียงกัน

หลักการออกแบบ Data Acquisition File สําหรับ Entity ที่มีความสมัพันธกันแบบ Generalization

จะมีการรวมเอาขอมูลทีเปน Super Class และ Sub Class เขาเปนขอมูลเนื้อเดียวกันใน Data Acquisition File

Chapter 6พื้นที่พักขอมูล

Data Staging Area



เนื้อหาData Staging Area คืออะไรกิจกรรมตางๆที่เกิดขึ้นบน Data Staging Areaแนวทางและ ทางเลือกสําหรับการออกแบบ

Data Staging Area คืออะไรData Model เนนใหสามารถสื่อถึงเรื่องราวขององคกรโดยผานการนําเสนอความสัมพันธระหวางขอมูลตางๆData Acquisition File เนนการสะดวกตอการจัดสง ไมไดเนนที่การแสดงความเปนจริงของขอมูลเทากับ Data Model ภายใน Data Staging Area ประกอบดวย การตรวจสอบความถูกตองของขอมูลในเบื้องตน สํารองขอมูลขอมูลจะถูกสงเขา Data Acquisition Subsystem กอนเปนจุดแรกจากนั้นก็จะเขาสู Data Staging Area เปนจุดถัดไป

Data Staging Area คืออะไร

Data Acquisition->Data Staging Area->Data Warehouse Database

Data Staging Area คืออะไรData Staging Area เปนสวนที่ติดตออยูกับทั้ง Data Acquisition และ Data Warehouse Database การตรวจสอบความถูกตองสอดคลองกันระหวางขอมูลที่ไดรับมา กับขอมูลที่มีอยูใน Data Warehouse Database สามารถทําไดในภายใน Data Staging Area ในทางกลับกัน Data Acquisition System สามารถทําไดเพียงการตรวจสอบความถูกตองของขอมูลไดเบื้องตนเทานั้น ไมสามารถตรวจสอบใน Warehouse database ได

กิจกรรมตางๆทีเ่กดิขึ้นบน Data Staging Area การตรวจสอบความถูกตองของขอมูลกอนการ Load เขาสู Data Warehouse Database

ความถูกตองในแงของการมีคาของขอมูล (Data Consistency) ความถูกตองในแงของคาตางๆที่เปนไปไดของขอมูล (Possible Values) ความถูกตองในแงของความสัมพันธของขอมูล (Data Relationship)

การทําหนาที่ Temporary Backup

ความถูกตองในแงของการมคีาของขอมูล (Data Consistency)Data Staging Area จะทําหนาที่ตรวจสอบวาขอมูลที่เขามามี Cardinality ของ Field ตางๆตรงตามที่กําหนดไวใน Data Model หรือไมพิจารณา Mandatory หรือ Optional

ความถูกตองในแงของคาตางๆที่เปนไปไดของขอมูล(Possible Values)

คาที่เปนไปไดของขอมูล (Possible Values) คือ ขอจํากัดของคาที่จะมีอยูใน Field ใด Field หนึ่งของขอมูล แบงออกไดเปน 2 ประเภท

Universal Possible Value มีอยูหลายชนิด เชน วันที่ เดือน สกุลเงิน ประเทศSystem-Based Values เปนคาที่เปนไปไดตางๆที่ระบบจําเปนจะตองมี เชนชนิดสินคาตางๆที่จําหนายในรานคา อาจจะมีตางๆกันไปตามแตละองคกร

Data Staging Area จะมีหนาที่ในการตรวจสอบคาของขอมูลที่ไดรับมาจาก Data Acquisition Subsystem วามีคาที่ตรงกับคาใดที่ระบุไวใน Possible Value หรือไม

ความถูกตองในแงของความสมัพันธของขอมูล (Data Relationship)

ตองทําหนาที่ตรวจสอบความถูกตองในความสัมพันธ เชน ขอมูลตัวหนึ่งมีความสัมพันธกับขอมูลอีกตัวหนึ่งอยางไรบาง ตรงกับที่ไดทําในแบบจําลองหรือไมยกตัวอยางความสัมพันธแบบ Foreign key เปนตน

การทําหนาที่ Temporary Backup เมื่อขอมูลมาถึงคลังขอมูล จะมีการรอนําเขาขอมูล ETL (Extract-Transform - Load )กระบวนการนี้ใชเวลานาน ยิ่งหากมีระบบใหญData Staging Area จะทําหนาที่เปนสวนสํารองขอมูลชั่วคราว (Temporary Backup) เพื่อสํารองขอมูลขณะที่กระบวนการนําเขาขอมูลดําเนินอยู ถาหากเกิดความผิดพลาดในกระบวนการนําเขาขอมูล ระบบจะเริ่มตนกระบวนการนําเขาใหมดวยขอมูลที่สํารองไว และเมื่อกระบวนการเสร็จสิ้น ขอมูลสํารองจะถูกกําจัดออกจาก Data Staging Area

การทําหนาที่ Temporary Backup การแบง Data Area และ Back up Area อาจจะเปน Disk ตัวเดียวกัน หรือแยกกันคนละตัวก็ได แตเพื่อความปลอดภัยมากที่สุด ควรมีการแยกออกเปน Disk คนละตัวมากกวา เพราะมีโอกาสที่จะเกิดความผิดพลาดขึ้นกับ Disk ทั้งหมดได ซึ่งอาจจะทําให Data Area และ Back up Area เสียหายทั้งคู หาอยูใน Disk เดียวกัน

แนวทางและทางเลือกสําหรับการออกแบบ Data Staging Area กับกระบวนการ ETL

กระบวนการ ETL ประกอบไปดวย 3 กระบวนการคือExtract คือกระบวนการในการดึงขอมูลออกจาก SourceTransform คือกระบวนการแปลงขอมูลจากโครงสรางเดิมที่กําหนดไวใน Source ใหอยูในรูปแบบโครงสรางตามที่ไดกําหนดใน DestinationLoad คือ การนําขอมูลที่เปลี่ยนแปลงรูปแบบแลวไปเก็บไวใน Destination (Data Warehouse)


กระบวนการ ETL มีสองแนวทางใหเลือกแนวทางแรกคือ การออกแบบโครงสรางขอมูลใหมีลักษณะ แบบเดียวกันกับโครงสรางขอมูลของ Data Acquisition Systemแนวทางที่สองคือ การออกแบบโครงสรางขอมูลใหมีลักษณะแบบเดียวกับ Data Warehouse Database การออกแบบของ Data Staging Area ทั้งสองแบบจะสงผลกระทบตอการออกแบบกระบวนการทํางานของ ETL

การออกแบบโครงสรางขอมูลใหมีลักษณะ แบบเดยีวกันกับโครงสรางขอมูลของ Data Acquisition System

การออกแบบโครงสรางขอมูลใหมีลักษณะแบบเดยีวกับ Data Warehouse Database


ทั้งสองแนวทางจะเกิด ETL ขึ้นสองครั้งถาหากออกแบบ Data Staging Area ใหรับโครงสรางขอมูลแบบ Data Acquisition System ระบบจะตองเสียเวลามากขึ้นในการยายขอมูลจาก Data Staging Area เขาไปยัง Data Warehouse Databaseถาหากออกแบบ Data Staging Area ใหรับโครงสรางขอมูลแบบ Data Warehouse Database ระบบจะตองเสียเวลามากขึ้นในการยายขอมูลจาก Data Acquisition System เขาไปยัง Data Staging Area


ในระบบที่มีการตรวจสอบความถูกตองของขอมูลที่มีปริมาณมากและซับซอน และมีโอกาสที่ขอมูลผิดพลาดสูงนั้น ระบบอาจจําเปนตองอานขอมูลจาก Data Warehouse Database เปนจํานวนมาก อาจจะซ้ําหลายครั้ง ดังนั้นกรณีนี้จึงควรมีการออกแบบโครงสรางขอมูลใหมีลักษณะแบบเดียวกับ Data Warehouse Database เพื่อความสะดวกในการตรวจสอบ ทําหยัดเวลาไดมาก


แตหากระบบที่มีขอมูลเขาที่มีปริมาณมากและความถี่สูงแตไมมีความซับซอนในการตรวจสอบมากนัก ควรมีการออกแบบโครงสรางขอมูลใหมีลักษณะแบบเดียวกับ Data Acquisition System เพื่อลดปญหาการรอเขามาของขอมูลซึ่งกอใหเกิดปญหาการเกิดคอขวดในการเขามาของขอมูลได