คลังข้อมูลและการวางแผนทรัพยากรองค์กร | DWH และ ERP

ที่เก็บถาวร ข้อมูล กลาง : ประวัติศาสตร์ ED วิวัฒนาการ

ประเด็นสำคัญสองประการของเทคโนโลยีองค์กรในทศวรรษที่ 90 คือ i คลังข้อมูล และ ERP เป็นเวลานานแล้วที่สตรีมอันทรงพลังทั้งสองนี้เป็นส่วนหนึ่งของไอทีองค์กรโดยไม่เคยมีจุดตัดกัน มันเกือบจะเหมือนกับว่าพวกมันเป็นทั้งสสารและปฏิสสาร แต่การเติบโตของปรากฏการณ์ทั้งสองได้นำไปสู่การตัดกันอย่างหลีกเลี่ยงไม่ได้ ปัจจุบัน บริษัทต่าง ๆ กำลังเผชิญกับปัญหาว่าจะทำอย่างไรกับ ERP และ คลังข้อมูล. บทความนี้จะอธิบายว่าปัญหาคืออะไรและบริษัทต่างๆ จะแก้ไขอย่างไร

ที่จุดเริ่มต้น…

ในตอนแรกมี คลังข้อมูล. คลังข้อมูล มันเกิดมาเพื่อตอบโต้ระบบแอปพลิเคชันการประมวลผลธุรกรรม ในยุคแรกๆ การท่องจำของ ข้อมูล มันควรจะเป็นเพียงความแตกต่างของแอปพลิเคชันการประมวลผลธุรกรรม แต่ปัจจุบันมีวิสัยทัศน์ที่ซับซ้อนมากขึ้นเกี่ยวกับสิ่งที่ก คลังข้อมูล. ในโลกปัจจุบัน คลังข้อมูล มันถูกแทรกอยู่ในโครงสร้างที่สามารถเรียกว่าโรงงานข้อมูลองค์กร

โรงงานข้อมูลองค์กร (ซีไอเอฟ)

Corporate Information Factory มีส่วนประกอบทางสถาปัตยกรรมมาตรฐาน: การรวมรหัสและชั้นการแปลงที่รวมเอา i ข้อมูล ขณะที่ฉัน ข้อมูล พวกเขาย้ายจากสภาพแวดล้อมของแอปพลิเคชันไปยังสภาพแวดล้อมของ คลังข้อมูล ของ บริษัท; NS คลังข้อมูล ของบริษัทที่ฉัน ข้อมูล ประวัติโดยละเอียดและบูรณาการ NS คลังข้อมูล ขององค์กรทำหน้าที่เป็นรากฐานสำหรับสร้างส่วนอื่นๆ ทั้งหมดของสภาพแวดล้อม คลังข้อมูล; ที่เก็บข้อมูลการดำเนินงาน (ODS) ODS เป็นโครงสร้างแบบไฮบริดที่มีคุณลักษณะบางอย่างของ คลังข้อมูล และด้านอื่นๆ ของสภาพแวดล้อม OLTP ดาต้ามาร์ท ซึ่งแผนกต่างๆ สามารถมีเวอร์ชันของตัวเองได้ คลังข้อมูล; ก คลังข้อมูล การสำรวจที่นักคิดของบริษัทสามารถส่งคำถามได้ภายใน 72 ชั่วโมงโดยไม่มีผลเสียต่อ คลังข้อมูล; และหน่วยความจำเส้นใกล้ซึ่งใน ข้อมูล เก่าและ ข้อมูล สามารถเก็บรายละเอียดจำนวนมากได้ในราคาถูก

ที่ ERP รวมกับ THE โรงงานข้อมูลองค์กร

ERP รวมเข้ากับ Corporate Information Factory ในสองแห่ง โดยพื้นฐานแล้วเป็นแอปพลิเคชันพื้นฐานที่ให้ i ข้อมูล ของแอปพลิเคชันถึง คลังข้อมูล. ในกรณีนี้ i ข้อมูลที่สร้างขึ้นโดยเป็นผลพลอยได้จากกระบวนการทำธุรกรรม ถูกรวมเข้าด้วยกันและบรรจุลงใน คลังข้อมูล ของ บริษัท. ลิงค์ที่สองระหว่าง ERP และ CIF คือ ODS แท้จริงแล้ว ในหลายสภาพแวดล้อม ERP ถูกใช้เป็น ODS แบบคลาสสิก

ในกรณีที่ใช้ ERP เป็นแอปพลิเคชันพื้นฐาน สามารถใช้ ERP เดียวกันใน CIF เป็น ODS ได้ ไม่ว่าในกรณีใด หากจะใช้ ERP ในทั้งสองบทบาท จะต้องมีความแตกต่างที่ชัดเจนระหว่างทั้งสองเอนทิตี กล่าวอีกนัยหนึ่ง เมื่อ ERP มีบทบาทเป็นแอปพลิเคชันพื้นฐานและ ODS เอนทิตีสถาปัตยกรรมทั้งสองจะต้องแตกต่างกัน หากการใช้งาน ERP เพียงครั้งเดียวพยายามที่จะบรรลุทั้งสองบทบาทพร้อมกัน จะเกิดปัญหาในการออกแบบและการนำเฟรมเวิร์กนั้นไปใช้อย่างหลีกเลี่ยงไม่ได้

แยก ODS และแอปพลิเคชันพื้นฐาน

มีหลายสาเหตุที่นำไปสู่การแบ่งส่วนประกอบทางสถาปัตยกรรม บางทีจุดที่บอกได้มากที่สุดในการแยกส่วนประกอบต่างๆ ของสถาปัตยกรรมก็คือ แต่ละส่วนประกอบของสถาปัตยกรรมมีมุมมองของตัวเอง แอปพลิเคชันพื้นฐานมีจุดประสงค์ที่แตกต่างจาก ODS ลองซ้อนทับกัน

มุมมองแอปพลิเคชันพื้นฐานในโลกของ ODS หรือในทางกลับกันไม่ใช่วิธีที่ยุติธรรมในการทำงาน

ดังนั้น ปัญหาแรกของ ERP ใน CIF คือการตรวจสอบว่ามีความแตกต่างระหว่างแอปพลิเคชันพื้นฐานและ ODS หรือไม่

รูปแบบข้อมูลในองค์กร โรงงานข้อมูล

เพื่อให้เกิดการทำงานร่วมกันระหว่างส่วนประกอบต่างๆ ของสถาปัตยกรรม CIF จะต้องมีแบบจำลองของ ข้อมูล. โมเดลของ ข้อมูล ทำหน้าที่เป็นตัวเชื่อมระหว่างส่วนประกอบต่างๆ ของสถาปัตยกรรม เช่น แอปพลิเคชันพื้นฐานและ ODS โมเดลของ ข้อมูล พวกเขากลายเป็น "แผนที่ถนนทางปัญญา" เพื่อให้ได้ความหมายที่ถูกต้องจากองค์ประกอบทางสถาปัตยกรรมต่างๆ ของ CIF

ควบคู่ไปกับแนวคิดนี้ แนวคิดก็คือควรมีรูปแบบเดียวและใหญ่ ข้อมูล. แน่นอนต้องมีรูปแบบของ ข้อมูล สำหรับแต่ละส่วนประกอบ และนอกจากนี้ จะต้องมีเส้นทางที่เหมาะสมในการเชื่อมต่อโมเดลต่างๆ แต่ละส่วนประกอบของสถาปัตยกรรม – ODS แอปพลิเคชันพื้นฐาน คลังข้อมูล ของบริษัทเป็นต้น.. – ต้องการรูปแบบของตนเอง ข้อมูล. ดังนั้นจึงต้องมีคำจำกัดความที่ชัดเจนว่าโมเดลเหล่านี้เป็นอย่างไร ข้อมูล พวกเขาเชื่อมต่อซึ่งกันและกัน

ย้ายฉัน ข้อมูล ของวันที่ ERP คลังสินค้า

ถ้าต้นกำเนิดของ ข้อมูล เป็นแอปพลิเคชันพื้นฐานและ/หรือ ODS เมื่อ ERP แทรก i ข้อมูล ใน คลังข้อมูลการแทรกนี้ต้องเกิดขึ้นที่ระดับต่ำสุดของ "ความละเอียด" เพียงแค่สรุปหรือรวม i ข้อมูล เนื่องจากมาจากแอปพลิเคชันพื้นฐาน ERP หรือ ERP ODS ไม่ใช่สิ่งที่ถูกต้อง เดอะ ข้อมูล รายละเอียดที่จำเป็นใน คลังข้อมูล เพื่อเป็นพื้นฐานของกระบวนการ DSS เช่น ข้อมูล พวกเขาจะถูกเปลี่ยนรูปร่างใหม่ในหลาย ๆ ด้านโดยดาต้ามาร์ทและการสำรวจ คลังข้อมูล.

การกระจัดของ ข้อมูล จากสภาพแวดล้อมแอปพลิเคชันพื้นฐานของ ERP ไปจนถึง คลังข้อมูล ของ บริษัท เป็นไปในลักษณะที่ผ่อนคลายพอสมควร การย้ายนี้เกิดขึ้นประมาณ 24 ชั่วโมงหลังจากการอัพเดตหรือสร้างใน ERP ข้อเท็จจริงของการมีการเคลื่อนไหวที่ "เกียจคร้าน" ของ ข้อมูล ใน คลังข้อมูล ของบริษัทอนุญาตให้ ข้อมูล มาจาก ERP เพื่อ "ชำระ" ครั้งหนึ่งฉัน ข้อมูล ถูกเก็บไว้ในแอปพลิเคชันพื้นฐาน จากนั้นคุณสามารถย้ายได้อย่างปลอดภัย ข้อมูล ของ ERP ในองค์กร เป้าหมายอื่นที่สามารถบรรลุได้ด้วยการเคลื่อนไหว "ขี้เกียจ" ของ ข้อมูล เป็นเส้นแบ่งที่ชัดเจนระหว่างกระบวนการปฏิบัติงานกับ DSS ด้วยการเคลื่อนไหวที่ “รวดเร็ว” ของ ข้อมูล เส้นแบ่งระหว่าง DSS และการปฏิบัติงานยังคงคลุมเครือ

อิล มูวิเมนโต เดย ข้อมูล จาก ODS ของ ERP ถึง คลังข้อมูล ของบริษัทจะทำเป็นระยะ ๆ โดยปกติจะเป็นรายสัปดาห์หรือรายเดือน ในกรณีนี้ การเคลื่อนไหวของ ข้อมูล มันขึ้นอยู่กับความจำเป็นในการ "ทำความสะอาด" ของเก่า ข้อมูล นักประวัติศาสตร์ โดยธรรมชาติแล้ว ODS จะมี i ข้อมูล ซึ่งใหม่กว่ามาก ข้อมูล นักประวัติศาสตร์ที่พบใน คลังข้อมูล.

การกระจัดของ ข้อมูล ใน คลังข้อมูล แทบไม่เคยทำการ “ขายส่ง” (ในลักษณะผู้ค้าส่ง) คัดลอกตารางจากสภาพแวดล้อม ERP ไปยัง คลังข้อมูล มันไม่ได้ทำให้ความรู้สึก. วิธีการที่สมจริงกว่ามากคือการย้ายหน่วยที่เลือกของ ข้อมูล. เพียง ข้อมูล ซึ่งมีการเปลี่ยนแปลงตั้งแต่การปรับปรุงครั้งล่าสุดของ คลังข้อมูล เป็นตัวที่ควรย้ายเข้าไปอยู่ใน คลังข้อมูล. วิธีหนึ่งที่จะรู้ว่าคนไหน ข้อมูล มีการเปลี่ยนแปลงเนื่องจากการอัพเดทครั้งล่าสุดคือการดูการประทับเวลาของ ข้อมูล พบได้ในสภาพแวดล้อม ERP ตัวออกแบบเลือกการเปลี่ยนแปลงทั้งหมดที่เกิดขึ้นตั้งแต่การอัพเดตครั้งล่าสุด อีกวิธีหนึ่งคือการใช้เทคนิคการจับภาพการเปลี่ยนแปลง ข้อมูล. ด้วยเทคนิคเหล่านี้ จะมีการวิเคราะห์บันทึกและเทปบันทึกเพื่อกำหนดว่ารายการใด ข้อมูล จะต้องถูกย้ายจากสภาพแวดล้อม ERP ไปเป็นของ คลังข้อมูล. เทคนิคเหล่านี้ดีที่สุดเนื่องจากสามารถอ่านบันทึกและบันทึกเทปได้จากไฟล์ ERP โดยไม่ส่งผลกระทบต่อทรัพยากร ERP อื่นๆ

ภาวะแทรกซ้อนอื่น ๆ

หนึ่งในปัญหา ERP ใน CIF คือสิ่งที่เกิดขึ้นกับแหล่งที่มาของแอปพลิเคชันหรือ ai อื่น ข้อมูล ของ ODS ที่ต้องมีส่วนทำให้ คลังข้อมูล แต่ไม่ได้เป็นส่วนหนึ่งของสภาพแวดล้อม ERP ด้วยลักษณะที่ปิดของ ERP โดยเฉพาะ SAP ที่พยายามรวมคีย์จากแหล่งภายนอกของ ข้อมูล กับฉัน ข้อมูล ที่มาจาก ERP ในขณะที่ย้าย i ข้อมูล ใน คลังข้อมูลมันเป็นความท้าทายที่ยิ่งใหญ่ และความน่าจะเป็นที่ i ข้อมูล ของแอปพลิเคชันหรือ ODS นอกสภาพแวดล้อม ERP จะถูกรวมเข้าไว้ด้วยกัน คลังข้อมูล? อัตราเดิมพันสูงมากจริงๆ

หา ข้อมูล ประวัติศาสตร์จาก ERP

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

ERP และเมตาดาต้า

ข้อควรพิจารณาอื่นเกี่ยวกับ ERP และ คลังข้อมูล เป็นหนึ่งในข้อมูลเมตาที่มีอยู่ในสภาพแวดล้อม ERP เช่นเดียวกับข้อมูลเมตาที่ย้ายจากสภาพแวดล้อม ERP ไปยัง คลังข้อมูลข้อมูลเมตาจะต้องถูกย้ายในลักษณะเดียวกัน นอกจากนี้ ข้อมูลเมตาจะต้องแปลงเป็นรูปแบบและโครงสร้างที่จำเป็นสำหรับโครงสร้างพื้นฐาน คลังข้อมูล. มีความแตกต่างอย่างมากระหว่างข้อมูลเมตาการดำเนินงานและข้อมูลเมตา DSS ข้อมูลเมตาในการดำเนินงานเป็นส่วนใหญ่สำหรับนักพัฒนาและสำหรับ

โปรแกรมเมอร์. ข้อมูลเมตา DSS มีไว้สำหรับผู้ใช้ปลายทางเป็นหลัก ข้อมูลเมตาที่มีอยู่ในแอปพลิเคชัน ERP หรือ ODS จำเป็นต้องแปลง และการแปลงนี้ไม่ใช่เรื่องง่ายและตรงไปตรงมาเสมอไป

การจัดหาข้อมูล ERP

หากใช้ ERP เป็นผู้ให้บริการของ ข้อมูล ต่ออิลลินอยส์ คลังข้อมูล ต้องมีอินเทอร์เฟซที่มั่นคงซึ่งย้าย i ข้อมูล จากสภาพแวดล้อม ERP สู่สภาพแวดล้อม คลังข้อมูล. อินเทอร์เฟซต้อง:

• ▪ ใช้งานง่าย
• ▪ อนุญาตให้เข้าถึง ข้อมูล ของ ERP
• ▪หยิบความหมายของ ข้อมูล ที่กำลังจะย้ายไป คลังข้อมูล
• ▪ รู้ข้อจำกัดของ ERP ที่อาจเกิดขึ้นเมื่อเข้าใช้งาน ข้อมูล ของ ERP:
• ▪ ความสมบูรณ์ของการอ้างอิง
• ▪ ความสัมพันธ์แบบลำดับชั้น
• ▪ ความสัมพันธ์เชิงตรรกะโดยปริยาย
• ▪ข้อตกลงในการสมัคร
• ▪ โครงสร้างทั้งหมดของ ข้อมูล รองรับโดย ERP และอื่นๆ ...
• ▪ มีประสิทธิภาพในการเข้าถึง ข้อมูล, โดยการให้:
• ▪ การเคลื่อนไหวโดยตรงของ ข้อมูล
• ▪ การได้มาซึ่งการเปลี่ยนแปลง ข้อมูล
• ▪สนับสนุนการเข้าถึงทันเวลา ข้อมูล
• ▪ เข้าใจรูปแบบของ ข้อมูล, และอื่นๆ… อินเทอร์เฟซกับ SAP อินเทอร์เฟซสามารถมีได้สองประเภท แบบพื้นบ้านหรือแบบเชิงพาณิชย์ อินเทอร์เฟซเชิงพาณิชย์ที่สำคัญบางส่วน ได้แก่ :

• ▪ สศอ
• ▪ ไพรม์โซลูชั่น
• ▪ D2k และอื่นๆ… เทคโนโลยี ERP หลายรายการ การปฏิบัติต่อสภาพแวดล้อม ERP ราวกับว่ามันเป็นเทคโนโลยีเดียวถือเป็นความผิดพลาดครั้งใหญ่ มีเทคโนโลยี ERP มากมาย ซึ่งแต่ละเทคโนโลยีก็มีจุดแข็ง ผู้ขายที่รู้จักกันดีที่สุดในตลาดคือ:

• ▪ เอสเอพี
• ▪ ออราเคิล ไฟแนนเชียลส์
• ▪ พีเพิลซอฟท์
• เจดี เอ็ดเวิร์ดส์
• ▪ บ้าน SAP SAP เป็นซอฟต์แวร์ ERP ที่ใหญ่ที่สุดและครอบคลุมที่สุด แอปพลิเคชัน SAP ประกอบด้วยแอปพลิเคชันหลายประเภทในหลายพื้นที่ SAP มีชื่อเสียงในด้าน:

• ▪ ใหญ่มาก
• ▪ ยากและแพงมากในการดำเนินการ
• ▪ ต้องการคนจำนวนมากและที่ปรึกษาในการดำเนินการ
• ▪ ต้องการบุคลากรที่เชี่ยวชาญในการดำเนินการ
• ▪ ต้องใช้เวลามากในการนำไปใช้ นอกจากนี้ SAP ยังมีชื่อเสียงในด้านการจดจำ ข้อมูล อย่างใกล้ชิดทำให้บุคคลภายนอกพื้นที่ SAP เข้าถึงได้ยาก จุดแข็งของ SAP คือความสามารถในการบันทึกและจัดเก็บข้อมูลจำนวนมาก ข้อมูล. SAP เพิ่งประกาศความตั้งใจที่จะขยายการใช้งานไปยัง คลังข้อมูล. มีข้อดีและข้อเสียมากมายในการใช้ SAP ในฐานะผู้ขาย คลังข้อมูล. ข้อดีคือติดตั้ง SAP ไว้แล้ว และที่ปรึกษาส่วนใหญ่ก็คุ้นเคยกับ SAP อยู่แล้ว
  ข้อเสียของการมี SAP เป็นซัพพลายเออร์ของ คลังข้อมูล มีมากมาย: SAP ไม่มีประสบการณ์ในโลกของ คลังข้อมูล หาก SAP เป็นซัพพลายเออร์ของ คลังข้อมูลมีความจำเป็นต้อง "นำออก" ฉัน ข้อมูล จาก SAP al คลังข้อมูล. ตัวเลข ประวัติของระบบปิดของ SAP ไม่น่าจะง่ายที่จะได้รับ i จาก SAP ในนั้น (???) มีสภาพแวดล้อมดั้งเดิมมากมายที่ขับเคลื่อน SAP เช่น IMS, VSAM, ADABAS, ORACLE, DB2 และอื่นๆ SAP ยืนยันในแนวทางที่ “ไม่ได้คิดค้นขึ้นที่นี่” SAP ไม่ต้องการเป็นพันธมิตรกับผู้ขายรายอื่นเพื่อใช้หรือสร้าง คลังข้อมูล. SAP ยืนยันที่จะสร้างซอฟต์แวร์ของตัวเองทั้งหมด

แม้ว่า SAP จะเป็นบริษัทขนาดใหญ่และทรงอิทธิพล แต่ข้อเท็จจริงของการพยายามเขียนเทคโนโลยีของ ELT, OLAP, การดูแลระบบ และแม้กระทั่งโค้ดเบสของ ฐานข้อมูล มันบ้าไปแล้ว แทนที่จะมีทัศนคติที่ร่วมมือกับซัพพลายเออร์ คลังข้อมูล SAP ปฏิบัติตามแนวทางที่พวกเขา “รู้ดีที่สุด” มาอย่างยาวนาน ทัศนคตินี้ขัดขวางความสำเร็จที่ SAP สามารถทำได้ในด้านนี้ คลังข้อมูล.
SAP ปฏิเสธที่จะอนุญาตให้ผู้จำหน่ายภายนอกเข้าถึงผู้จำหน่ายของตนได้อย่างทันท่วงทีและสง่างาม ข้อมูล. สาระสำคัญของการใช้ คลังข้อมูล เข้าถึงได้ง่าย ข้อมูล. เรื่องราวทั้งหมดของ SAP ขึ้นอยู่กับการทำให้เข้าถึงได้ยาก ข้อมูล.
SAP ขาดประสบการณ์ในการจัดการกับ .ปริมาณมาก ข้อมูล; ในด้าน คลังข้อมูล มีปริมาณของ ข้อมูล ไม่เคยเห็นจาก SAP และจัดการกับจำนวนมากเหล่านี้ ข้อมูล คุณต้องมีเทคโนโลยีที่เหมาะสม เห็นได้ชัดว่า SAP ไม่ได้ตระหนักถึงอุปสรรคทางเทคโนโลยีที่มีอยู่เพื่อเข้าสู่สนาม คลังข้อมูล.
วัฒนธรรมองค์กรของ SAP: SAP ได้สร้างธุรกิจในการรับ i ข้อมูล จากระบบ แต่การทำเช่นนี้คุณต้องมีความคิดที่แตกต่างออกไป เดิมที บริษัทซอฟต์แวร์ที่เก่งในการรับข้อมูลเข้าสู่สภาพแวดล้อมนั้นไม่เก่งในการรับข้อมูลไปในทางอื่น หาก SAP สามารถสร้างสวิตช์ประเภทนี้ได้ จะเป็นบริษัทแรกที่ทำเช่นนั้น

กล่าวโดยย่อ เป็นเรื่องที่น่าสงสัยว่าบริษัทควรเลือก SAP เป็นซัพพลายเออร์ของหรือไม่ คลังข้อมูล. มีความเสี่ยงร้ายแรงในด้านหนึ่งและผลตอบแทนน้อยมาก แต่มีอีกเหตุผลหนึ่งที่ทำให้ท้อใจที่จะเลือก SAP เป็นซัพพลายเออร์ คลังข้อมูล. เพราะทุกบริษัทควรมีเหมือนกัน คลังข้อมูล ของบริษัทอื่นๆ ทั้งหมด? เดอะ คลังข้อมูล ถือเป็นหัวใจสำคัญของความได้เปรียบในการแข่งขัน ถ้าทุกบริษัทใช้เหมือนกันหมด คลังข้อมูล มันคงเป็นเรื่องยากแม้ว่าจะเป็นไปไม่ได้ก็ตามที่จะบรรลุความได้เปรียบในการแข่งขัน SAP ดูเหมือนจะคิดว่า คลังข้อมูล สามารถมองเห็นได้ว่าเป็นคุกกี้ และนี่เป็นอีกหนึ่งสัญญาณของความคิดของพวกเขาในการ "รับข้อมูลใน" แอปพลิเคชัน

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

สภาพแวดล้อมเหล่านี้รวมถึงกิจกรรมต่างๆ เช่น การดำเนินการกับพนักงานธนาคาร กระบวนการจองสายการบิน กระบวนการร้องเรียนเกี่ยวกับประกันภัย และอื่นๆ ยิ่งระบบการทำธุรกรรมมีประสิทธิภาพดีเท่าใด ความจำเป็นในการแยกระหว่างกระบวนการปฏิบัติงานกับ DSS (ระบบสนับสนุนการตัดสินใจ) ก็ยิ่งชัดเจนมากขึ้นเท่านั้น อย่างไรก็ตาม ด้วยระบบทรัพยากรบุคคลและบุคลากร คุณจะไม่เคยเผชิญกับธุรกรรมปริมาณมาก และแน่นอน เมื่อบุคคลได้รับการว่าจ้างหรือออกจากบริษัท นี่คือบันทึกการทำธุรกรรม แต่เมื่อเทียบกับระบบอื่นๆ ระบบ HR และบุคลากรไม่ได้มีการทำธุรกรรมมากนัก ดังนั้นในระบบทรัพยากรบุคคลและบุคลากรจึงไม่ชัดเจนว่าจำเป็นต้องมี DataWarehouse ระบบเหล่านี้เป็นการผสมผสานระหว่างระบบ DSS ในหลาย ๆ ทาง

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

PeopleSoft แตกต่างจาก SAP มากในแง่นี้ ด้วย SAP จำเป็นต้องมี คลังข้อมูล. ด้วย PeopleSoft มันไม่ชัดเจนทั้งหมด คลังข้อมูลเป็นตัวเลือกสำหรับ PeopleSoft

สิ่งที่ดีที่สุดที่สามารถพูดได้สำหรับ ข้อมูล PeopleSoft คือว่า คลังข้อมูล สามารถใช้เพื่อเก็บถาวร ข้อมูล ที่เกี่ยวข้องกับทรัพยากรบุคคลและบุคคลเก่า เหตุผลที่สองที่บริษัทต้องการใช้ คลังข้อมูล a

ข้อเสียของสภาพแวดล้อม PeopleSoft คือการอนุญาตให้เข้าถึงและเข้าถึงเครื่องมือวิเคราะห์ได้ฟรี ai ข้อมูล โดย PeopleSoft แต่นอกเหนือจากเหตุผลเหล่านี้ อาจมีบางกรณีที่ไม่ควรมีคลังข้อมูล ข้อมูล พีเพิลซอฟท์

สรุป

มีแนวคิดมากมายที่เกี่ยวข้องกับการสร้าง คลังข้อมูล ภายในซอฟต์แวร์ ERP
บางส่วนของเหล่านี้คือ:

• ▪ เป็นเรื่องที่สมเหตุสมผลที่จะมี คลังข้อมูล หน้าเหมือนใครในวงการ?
• ▪ ERP มีความยืดหยุ่นเพียงใด คลังข้อมูล ซอฟต์แวร์?
• ▪ ERP คลังข้อมูล ซอฟต์แวร์สามารถรองรับปริมาณของ ข้อมูล ซึ่งตั้งอยู่ใน "คลังข้อมูล อารีน่า"?
• ▪ การบันทึกร่องรอยที่ผู้ขาย ERP ทำคืออะไรเมื่อเผชิญกับ ai ที่ง่ายและราคาถูก ใช้เวลานาน ข้อมูล? (ประวัติผู้ขาย ERP เป็นอย่างไรในการส่งมอบของ ราคาไม่แพง ตรงเวลา เข้าถึงข้อมูลได้ง่าย)
• ▪ ผู้ขาย ERP มีความเข้าใจอย่างไรเกี่ยวกับสถาปัตยกรรม DSS และโรงงานผลิตข้อมูลองค์กร?
• ▪ ผู้จำหน่าย ERP เข้าใจวิธีรับ ข้อมูล ภายในสิ่งแวดล้อม แต่ยังเข้าใจวิธีการส่งออกหรือไม่
• ▪ ผู้จำหน่าย ERP เปิดรับเครื่องมือคลังข้อมูลมากน้อยเพียงใด?
  ต้องคำนึงถึงสิ่งเหล่านี้ทั้งหมดเมื่อพิจารณาว่าจะวางที่ใด คลังข้อมูล ซึ่งจะเป็นเจ้าภาพ i ข้อมูล ERP และอื่นๆ ข้อมูล. โดยทั่วไปแล้ว เว้นแต่จะมีเหตุผลที่น่าสนใจที่จะทำเช่นนั้น ขอแนะนำให้สร้างอาคาร คลังข้อมูล นอกสภาพแวดล้อมผู้จำหน่าย ERP บทที่ 1 ภาพรวมขององค์กร BI ประเด็นสำคัญ:
  ที่เก็บข้อมูลทำงานตรงกันข้ามกับสถาปัตยกรรมระบบธุรกิจอัจฉริยะ (BI):
  วัฒนธรรมองค์กรและไอทีสามารถจำกัดความสำเร็จของการสร้างองค์กร BI

เทคโนโลยีไม่ใช่ปัจจัยจำกัดสำหรับองค์กร BI อีกต่อไป ปัญหาสำหรับสถาปนิกและผู้วางแผนโครงการไม่ได้อยู่ที่ว่าเทคโนโลยีนั้นมีอยู่จริงหรือไม่ แต่อยู่ที่ว่าพวกเขาจะสามารถนำเทคโนโลยีที่มีอยู่ไปใช้ได้อย่างมีประสิทธิภาพหรือไม่

สำหรับหลายๆ บริษัท a คลังข้อมูล มีค่ามากกว่าการฝากแบบพาสซีฟเล็กน้อยที่กระจาย i ข้อมูล ให้กับผู้ใช้ที่ต้องการ NS ข้อมูล ถูกแยกออกจากระบบต้นทางและบรรจุลงในโครงสร้างเป้าหมายโดย คลังข้อมูล. ฉัน ข้อมูล พวกเขายังสามารถทำความสะอาดได้ด้วยความโชคดี อย่างไรก็ตามไม่มีการเพิ่มหรือรวบรวมมูลค่าเพิ่มเติมโดย ข้อมูล ในระหว่างกระบวนการนี้

โดยพื้นฐานแล้ว passive dw ให้เฉพาะ i ข้อมูล สะอาดและใช้งานได้กับสมาคมผู้ใช้ การสร้างข้อมูลและความเข้าใจในการวิเคราะห์ขึ้นอยู่กับผู้ใช้ทั้งหมด การตัดสินว่า DW (คลังข้อมูล) ไม่ว่าความสำเร็จจะเป็นเรื่องส่วนตัวหรือไม่ หากเราตัดสินความสำเร็จจากความสามารถในการรวบรวม ผสานรวม และทำความสะอาด i ข้อมูล องค์กรบนพื้นฐานที่คาดเดาได้ ใช่แล้ว DW นั้นประสบความสำเร็จ ในทางกลับกัน หากเราดูที่การรวบรวม การรวม และการใช้ประโยชน์จากข้อมูลขององค์กรโดยรวม DW ถือว่าล้มเหลว DW ให้ข้อมูลเพียงเล็กน้อยหรือไม่มีเลย เป็นผลให้ผู้ใช้ถูกบังคับให้ทำจึงสร้างไซโลข้อมูล บทนี้นำเสนอวิสัยทัศน์ที่ครอบคลุมเพื่อสรุปสถาปัตยกรรม BI (Business Intelligence) ขององค์กร เราเริ่มต้นด้วยคำอธิบายของ BI จากนั้นจึงเข้าสู่การอภิปรายเกี่ยวกับการออกแบบและพัฒนาข้อมูล ซึ่งต่างจากการให้ข้อมูลเพียงอย่างเดียว ข้อมูล ให้กับผู้ใช้ จากนั้นการสนทนาจะมุ่งเน้นไปที่การคำนวณมูลค่าของความพยายามด้าน BI ของคุณ เราสรุปโดยการกำหนดวิธีการที่ IBM จัดการกับข้อกำหนดทางสถาปัตยกรรม BI ขององค์กรของคุณ

คำอธิบายของสถาปัตยกรรมของ องค์กรของBI

ระบบข้อมูลที่เน้นการทำธุรกรรมที่ทรงพลังกลายเป็นลำดับของวันในองค์กรขนาดใหญ่ทุกแห่ง ซึ่งช่วยยกระดับสนามแข่งขันสำหรับองค์กรทั่วโลกได้อย่างมีประสิทธิภาพ

อย่างไรก็ตาม ความสามารถในการแข่งขันที่เหลืออยู่นั้นต้องการระบบที่เน้นการวิเคราะห์ซึ่งสามารถปฏิวัติความสามารถของบริษัทในการค้นพบและใช้ข้อมูลที่มีอยู่แล้ว ระบบการวิเคราะห์เหล่านี้มาจากความเข้าใจจากความมั่งคั่งของ ข้อมูล มีอยู่. BI สามารถปรับปรุงประสิทธิภาพของข้อมูลทั้งหมดทั่วทั้งองค์กร บริษัทต่างๆ สามารถปรับปรุงความสัมพันธ์ระหว่างลูกค้ากับซัพพลายเออร์ ปรับปรุงความสามารถในการทำกำไรของผลิตภัณฑ์และบริการ สร้างข้อตกลงใหม่และดีกว่า ควบคุมความเสี่ยง และท่ามกลางกำไรอื่นๆ อีกมากมายที่ลดค่าใช้จ่ายลงได้อย่างมาก ด้วย BI ในที่สุด บริษัทของคุณก็เริ่มใช้ข้อมูลลูกค้าเป็นทรัพย์สินในการแข่งขัน ต้องขอบคุณแอปพลิเคชันที่มีวัตถุประสงค์ทางการตลาด

การมีวิธีการทางธุรกิจที่ถูกต้องหมายถึงการมีคำตอบที่ชัดเจนสำหรับคำถามสำคัญๆ เช่น:

• ▪ ข้อใดของเรา ลูกค้า พวกเขาทำให้เรามีรายได้มากขึ้นหรือทำให้เราเสียเงิน?
• ▪ ที่ที่ดีที่สุดของเราอาศัยอยู่ ลูกค้า เกี่ยวกับ ร้านขายของ/ คลังสินค้า พวกเขาบ่อย?
• ▪ ผลิตภัณฑ์และบริการใดของเราที่สามารถขายได้อย่างมีประสิทธิภาพมากที่สุดและขายให้กับใคร?
• ▪ สินค้าอะไรที่สามารถขายได้อย่างมีประสิทธิภาพมากที่สุดและขายให้กับใคร?
• ▪ แคมเปญการขายใดประสบความสำเร็จมากกว่าและทำไม?
• ▪ ช่องทางการขายใดที่ได้ผลดีที่สุดสำหรับผลิตภัณฑ์ใด?
• ▪ เราจะปรับปรุงความสัมพันธ์ให้ดีที่สุดได้อย่างไร ลูกค้า? บริษัทส่วนใหญ่มี ข้อมูล หยาบเพื่อตอบคำถามเหล่านี้
  ระบบปฏิบัติการสร้างผลิตภัณฑ์ ลูกค้า และต้นทุนจำนวนมาก ข้อมูล ตั้งแต่จุดขาย การจอง การบริการลูกค้า และระบบสนับสนุนทางเทคนิค ความท้าทายคือการสกัดและใช้ประโยชน์จากข้อมูลนี้ หลายบริษัทได้กำไรจากเศษส่วนเล็กน้อยเท่านั้น ข้อมูล สำหรับการวิเคราะห์เชิงกลยุทธ์
  I ข้อมูล เหลือ มักจะรวมกับ i ข้อมูล การได้มาซึ่งแหล่งข้อมูลภายนอก เช่น รายงานของรัฐบาล และข้อมูลอื่นๆ ที่ซื้อมา เป็นเหมืองทองคำที่รอการสำรวจ และ ข้อมูล พวกเขาเพียงแค่ต้องได้รับการขัดเกลาในบริบทข้อมูลขององค์กรของคุณ

ความรู้นี้สามารถนำไปใช้ได้หลายวิธี ตั้งแต่การออกแบบกลยุทธ์องค์กรโดยรวมไปจนถึงการสื่อสารส่วนตัวกับซัพพลายเออร์ ผ่านทางศูนย์บริการทางโทรศัพท์ การออกใบแจ้งหนี้ อินเทอร์เน็ต และจุดอื่นๆ สภาพแวดล้อมทางธุรกิจในปัจจุบันเป็นตัวกำหนดว่า DW และโซลูชัน BI ที่เกี่ยวข้องมีวิวัฒนาการไปไกลกว่าการดำเนินโครงสร้างธุรกิจแบบดั้งเดิม ข้อมูล ซึ่งฉัน ข้อมูล ระดับอะตอมมาตรฐานและ "ฟาร์มดาว / ลูกบาศก์"

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

ตัวอย่างเช่น สมมติว่าคุณจัดอันดับของคุณ ลูกค้า ในประเภทความเสี่ยงสูงหรือต่ำ
ไม่ว่าข้อมูลนี้จะถูกสร้างขึ้นโดยโมเดลการขุดหรือวิธีอื่นๆ จะต้องใส่ข้อมูลนั้นลงใน DW และทำให้ทุกคนสามารถเข้าถึงได้โดยใช้เครื่องมือการเข้าถึงใดๆ เช่น รายงานคงที่ สเปรดชีต ตาราง หรือการประมวลผลการวิเคราะห์ออนไลน์ (OLAP)

อย่างไรก็ตาม ในปัจจุบัน ข้อมูลประเภทนี้ส่วนใหญ่ยังคงอยู่ในไซโล ข้อมูล ของบุคคลหรือหน่วยงานที่สร้างการวิเคราะห์ องค์กรโดยรวมมีการมองเห็นเพียงเล็กน้อยหรือไม่มีเลยสำหรับความเข้าใจ การผสมผสานเนื้อหาข้อมูลประเภทนี้เข้ากับ DW ขององค์กรของคุณเท่านั้นที่จะช่วยให้คุณขจัดไซโลข้อมูลและยกระดับสภาพแวดล้อม DW ของคุณได้
มีอุปสรรคสำคัญสองประการในการพัฒนาองค์กร BI
ประการแรก เรามีปัญหาขององค์กรและระเบียบวินัย
แม้ว่าเราจะไม่สามารถช่วยเหลือเกี่ยวกับการเปลี่ยนแปลงนโยบายองค์กรได้ แต่เราสามารถช่วยทำความเข้าใจองค์ประกอบของ BI ขององค์กร สถาปัตยกรรม และวิธีการที่เทคโนโลยีของ IBM ช่วยอำนวยความสะดวกในการพัฒนา
อุปสรรคที่สองที่ต้องเอาชนะคือการขาดเทคโนโลยีแบบบูรณาการและความรู้เกี่ยวกับวิธีการที่เรียกพื้นที่ BI ทั้งหมดแทนที่จะเป็นส่วนประกอบขนาดเล็ก

IBM กำลังตอบสนองต่อการเปลี่ยนแปลงในการรวมเทคโนโลยี เป็นความรับผิดชอบของคุณในการออกแบบอย่างใส่ใจ สถาปัตยกรรมนี้ต้องได้รับการพัฒนาด้วยเทคโนโลยีที่เลือกใช้เพื่อการผสานรวมที่ไร้รอยต่อ หรืออย่างน้อยที่สุดคือเทคโนโลยีที่เป็นไปตามมาตรฐานเปิด นอกจากนี้ ผู้บริหารบริษัทของคุณต้องตรวจสอบให้แน่ใจว่าองค์กร Bi ดำเนินการตามกำหนดเวลา และไม่ปล่อยให้มีการพัฒนาไซโลข้อมูลที่เกิดจากวาระการประชุมหรือเป้าหมายที่ให้บริการตนเอง
นี่ไม่ได้หมายความว่าสภาพแวดล้อม BI ไม่ไวต่อการตอบสนองต่อความต้องการและข้อกำหนดที่แตกต่างกันของผู้ใช้ที่แตกต่างกัน แต่หมายความว่าการดำเนินการตามความต้องการและข้อกำหนดของแต่ละบุคคลนั้นทำเพื่อประโยชน์ขององค์กร BI ทั้งหมด
คำอธิบายเกี่ยวกับสถาปัตยกรรมขององค์กร BI สามารถดูได้ที่หน้า 9 ในรูปที่ 1.1 สถาปัตยกรรมแสดงให้เห็นถึงการผสมผสานเทคโนโลยีและเทคนิคที่หลากหลาย
จากมุมมองแบบดั้งเดิม สถาปัตยกรรมประกอบด้วยส่วนประกอบคลังสินค้าต่อไปนี้

ชั้นอะตอม

นี่คือรากฐาน หัวใจของ Dw ทั้งหมด และดังนั้นจึงเป็นการรายงานเชิงกลยุทธ์
I ข้อมูล เก็บไว้ที่นี่จะรักษาความสมบูรณ์ทางประวัติศาสตร์รายงานของ ข้อมูล และรวมเมตริกที่ได้รับ เช่นเดียวกับการทำความสะอาด ผสานรวม และจัดเก็บโดยใช้แบบจำลองการขุด
การใช้สิ่งเหล่านี้ในภายหลังทั้งหมด ข้อมูล และข้อมูลที่เกี่ยวข้องได้มาจากโครงสร้างนี้ นี่คือแหล่งที่ยอดเยี่ยมสำหรับการขุด ข้อมูล และสำหรับรายงานที่มีการสืบค้น SQL แบบมีโครงสร้าง

เงินฝากการดำเนินงานของ ข้อมูล หรือรายงานฐานของ ข้อมูล(พื้นที่เก็บข้อมูลปฏิบัติการ (ODS) หรือการรายงาน ฐานข้อมูล.)

นี่คือโครงสร้างของ ข้อมูล ออกแบบมาโดยเฉพาะสำหรับการรายงานทางเทคนิค

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

พื้นที่การแสดงละคร

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

เดทมาร์ท.

สถาปัตยกรรมส่วนนี้แสดงถึงโครงสร้างของ ข้อมูล ใช้เฉพาะสำหรับ OLAP การมีอยู่ของ datamarts ถ้าฉัน ข้อมูล พวกมันถูกจัดเก็บไว้ในสคีมารูปดาวที่พวกเขาซ้อนทับ ข้อมูล หลายมิติในสภาพแวดล้อมเชิงสัมพันธ์ หรือในไฟล์ของ ข้อมูล กรรมสิทธิ์ที่ใช้โดยเทคโนโลยี OLAP เฉพาะ เช่น DB2 OLAP Server ไม่เกี่ยวข้อง

ข้อจำกัดเพียงอย่างเดียวคือสถาปัตยกรรมอำนวยความสะดวกในการใช้งาน ข้อมูล หลายมิติ
สถาปัตยกรรมยังรวมถึงเทคโนโลยีและเทคนิค Bi ที่สำคัญซึ่งมีความแตกต่างดังนี้:

การวิเคราะห์เชิงพื้นที่

Space เป็นข้อมูลโชคลาภสำหรับนักวิเคราะห์และมีความสำคัญอย่างยิ่งต่อการแก้ปัญหาที่สมบูรณ์ อวกาศสามารถแสดงข้อมูลเกี่ยวกับผู้คนที่อาศัยอยู่ในสถานที่หนึ่งๆ รวมถึงข้อมูลเกี่ยวกับสถานที่นั้นซึ่งสัมพันธ์กันทางกายภาพกับส่วนอื่นๆ ของโลก

ในการวิเคราะห์นี้ คุณต้องเริ่มต้นด้วยการผูกข้อมูลของคุณกับพิกัดละติจูดและลองจิจูด สิ่งนี้เรียกว่า "geocoding" และต้องเป็นส่วนหนึ่งของกระบวนการแยก แปลง และโหลด (ETL) ที่ระดับอะตอมของคลังสินค้าของคุณ

การทำเหมืองข้อมูล

การสกัด ข้อมูล ช่วยให้บริษัทของเราเพิ่มจำนวน ลูกค้าเพื่อคาดการณ์แนวโน้มการขายและเปิดใช้งานการจัดการความสัมพันธ์กับ i ลูกค้า (CRM) ท่ามกลางความคิดริเริ่ม BI อื่นๆ

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

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

ตัวแทน

มี "ตัวแทน" ที่หลากหลายเพื่อตรวจสอบลูกค้าในจุดต่างๆ เช่น ระบบปฏิบัติการของบริษัทและตัว dw ตัวแทนเหล่านี้สามารถเป็นโครงข่ายประสาทเทียมขั้นสูงที่ได้รับการฝึกอบรมเพื่อเรียนรู้เกี่ยวกับแนวโน้มในแต่ละจุด เช่น ความต้องการผลิตภัณฑ์ในอนาคตตามการส่งเสริมการขาย เครื่องมือตามกฎสำหรับการตอบสนองต่อ Dato ชุดของสถานการณ์หรือแม้กระทั่งตัวแทนธรรมดาที่รายงานข้อยกเว้นต่อผู้บริหารระดับสูง กระบวนการเหล่านี้มักเกิดขึ้นในเวลาจริง ดังนั้นจึงต้องดำเนินไปพร้อมกับการเคลื่อนไหวของกระบวนการอย่างแนบแน่น ข้อมูล. โครงสร้างทั้งหมดนี้ของ ข้อมูลเทคโนโลยีและเทคนิคช่วยให้แน่ใจว่าคุณจะไม่ใช้เวลาทั้งคืนในการสร้างองค์กรของ BI ของคุณ

กิจกรรมนี้จะพัฒนาเป็นขั้นเป็นตอนสำหรับจุดเล็กๆ
แต่ละขั้นตอนเป็นความพยายามของโครงการอิสระ และเรียกว่าการวนซ้ำใน BI dw หรือความคิดริเริ่มของคุณ การทำซ้ำอาจรวมถึงการนำเทคโนโลยีใหม่มาใช้ เริ่มต้นด้วยเทคนิคใหม่ เพิ่มเฟรมเวิร์กใหม่ ข้อมูล โหลด i ข้อมูล เพิ่มเติม หรือด้วยการขยายการวิเคราะห์ของสภาพแวดล้อมของคุณ ย่อหน้านี้จะกล่าวถึงในรายละเอียดเพิ่มเติมในบทที่ 3

นอกเหนือจากเฟรมเวิร์ก DW แบบดั้งเดิมและเครื่องมือ BI แล้ว ยังมีแง่มุมอื่นๆ ขององค์กร BI ของคุณที่คุณต้องออกแบบ เช่น:

จุดสัมผัสลูกค้า (ลูกค้าสัมผัส คะแนน)

เช่นเดียวกับองค์กรสมัยใหม่ใดๆ มีจุดติดต่อลูกค้าจำนวนมากที่ระบุถึงวิธีสร้างประสบการณ์ที่ดีให้กับองค์กรของคุณ ลูกค้า. มีช่องทางแบบดั้งเดิม เช่น ร้านค้า ผู้ให้บริการสวิตช์บอร์ด ไดเร็กต์เมล มัลติมีเดีย และโฆษณาสิ่งพิมพ์ รวมถึงช่องทางปัจจุบันอื่นๆ เช่น อีเมลและเว็บ ข้อมูล ผลิตภัณฑ์ที่มีจุดติดต่อจะต้องได้รับ ขนส่ง ทำความสะอาด แปรรูป และเติมที่โรงงาน ข้อมูล ของบีไอ

พื้นฐานของ ข้อมูล การเชื่อมโยงการดำเนินงานและผู้ใช้ (Operational

ฐานข้อมูลและชุมชนผู้ใช้)
ในตอนท้ายของจุดติดต่อของ ลูกค้า คุณจะพบกับพื้นฐานของ ข้อมูล แอปพลิเคชันของบริษัทและชุมชนผู้ใช้ NS ข้อมูล ที่มีอยู่ ข้อมูล ประเพณีที่ต้องกลับมารวมกันและรวมเข้ากับ ข้อมูล ไหลจากจุดสัมผัสเพื่อตอบสนองข้อมูลที่จำเป็น

นักวิเคราะห์ (นักวิเคราะห์)

ผู้รับผลประโยชน์หลักของสภาพแวดล้อม BI คือนักวิเคราะห์ เขาคือผู้ที่ได้รับประโยชน์จากการสกัดในปัจจุบันของ ข้อมูล การดำเนินงานรวมกับแหล่งที่มาที่แตกต่างกันของ ข้อมูล เสริมด้วยคุณสมบัติต่างๆ เช่น การวิเคราะห์ทางภูมิศาสตร์ (geocoding) และนำเสนอในเทคโนโลยี BI ที่ช่วยให้ขุดได้, OLAP, การรายงาน SQL ขั้นสูง และการวิเคราะห์ทางภูมิศาสตร์ อินเทอร์เฟซหลักสำหรับนักวิเคราะห์ในสภาพแวดล้อมการรายงานคือพอร์ทัล BI

อย่างไรก็ตาม นักวิเคราะห์ไม่ใช่คนเดียวที่ได้รับประโยชน์จากสถาปัตยกรรม BI
ผู้บริหาร สมาคมผู้ใช้ขนาดใหญ่ และแม้แต่หุ้นส่วน ซัพพลายเออร์ และ i ลูกค้า พวกเขาควรพบประโยชน์ใน BI ขององค์กร

วนกลับฟีด

สถาปัตยกรรม BI เป็นสภาพแวดล้อมการเรียนรู้ หลักการของการพัฒนาลักษณะเฉพาะคือการอนุญาตให้มีโครงสร้างถาวรของ ข้อมูล จะได้รับการอัปเดตโดยเทคโนโลยี BI ที่ใช้และโดยการกระทำของผู้ใช้ ตัวอย่างคือการให้คะแนนของลูกค้า

หากแผนกขายทำแบบจำลองการขุดคะแนนของลูกค้า เช่น การใช้บริการใหม่ แผนกขายไม่ควรเป็นเพียงกลุ่มเดียวที่ได้รับประโยชน์จากบริการ

แทนที่จะทำเช่นนั้น การทำเหมืองแบบจำลองควรดำเนินการโดยเป็นส่วนหนึ่งของการไหลของข้อมูลภายในองค์กร และคะแนนลูกค้าควรกลายเป็นส่วนหนึ่งของบริบทข้อมูลคลังสินค้าที่ผู้ใช้ทุกคนมองเห็นได้ IBM Suite ที่เน้น Bi-bI รวมถึง DB2 UDB, DB2 OLAP Server มีส่วนประกอบเทคโนโลยีที่สำคัญส่วนใหญ่ ซึ่งกำหนดไว้ในรูปที่ 1.1

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

การจัดเตรียมเนื้อหาข้อมูล (ให้ เนื้อหาข้อมูล)

การออกแบบ การพัฒนา และการปรับใช้สภาพแวดล้อม BI ของคุณเป็นงานที่น่ากังวล การออกแบบจะต้องรองรับความต้องการทางธุรกิจทั้งในปัจจุบันและอนาคต การเขียนแบบสถาปัตยกรรมต้องมีความครอบคลุมเพื่อรวมข้อสรุปทั้งหมดที่พบในขั้นตอนการออกแบบ การดำเนินการต้องยังคงมุ่งมั่นเพื่อจุดประสงค์เดียว: เพื่อพัฒนาสถาปัตยกรรม BI ตามที่นำเสนออย่างเป็นทางการในการออกแบบและเป็นไปตามข้อกำหนดทางธุรกิจ

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

อย่างไรก็ตาม การระบุองค์ประกอบ BI ของสถาปัตยกรรมของคุณมีความสำคัญด้วยเหตุผลสองประการ: คุณจะขับเคลื่อนการตัดสินใจเกี่ยวกับสถาปัตยกรรมทางเทคนิคที่ตามมาทั้งหมด
คุณจะสามารถวางแผนการใช้เทคโนโลยีบางอย่างได้อย่างมีสติ แม้ว่าคุณอาจไม่ต้องการเทคโนโลยีซ้ำอีกเป็นเวลาหลายเดือน

การเข้าใจความต้องการทางธุรกิจของคุณอย่างเพียงพอจะส่งผลต่อประเภทของผลิตภัณฑ์ที่คุณได้รับสำหรับสถาปัตยกรรมของคุณ
การออกแบบและพัฒนาสถาปัตยกรรมของคุณทำให้มั่นใจได้ว่าคลังสินค้าของคุณนั้น

ไม่ใช่เหตุการณ์สุ่ม แต่เป็นโฆษณาที่สร้างขึ้นอย่างรอบคอบ อุปรากร ของศิลปะแบบโมเสกผสมเทคโนโลยี

ออกแบบเนื้อหาข้อมูล

การออกแบบเริ่มต้นทั้งหมดต้องมุ่งเน้นและระบุองค์ประกอบ BI ที่สำคัญที่จำเป็นสำหรับสภาพแวดล้อมโดยรวมในปัจจุบันและอนาคต
การรู้ข้อกำหนดทางธุรกิจเป็นสิ่งสำคัญ

แม้กระทั่งก่อนที่การวางแผนอย่างเป็นทางการจะเริ่มขึ้น ผู้วางแผนโครงการมักจะสามารถระบุองค์ประกอบหนึ่งหรือสองส่วนได้ทันที
อย่างไรก็ตาม ความสมดุลของส่วนประกอบที่อาจจำเป็นสำหรับสถาปัตยกรรมของคุณนั้นหาไม่ได้ง่ายๆ ในระหว่างขั้นตอนการออกแบบ ส่วนหลักของสถาปัตยกรรมจะเชื่อมโยงเซสชันการพัฒนาแอปพลิเคชัน (JAD) กับการวิจัยเพื่อระบุความต้องการทางธุรกิจ

ในบางครั้งข้อกำหนดเหล่านี้สามารถมอบให้กับเครื่องมือสืบค้นข้อมูลและการรายงานได้
ตัวอย่างเช่น ผู้ใช้ระบุว่าหากต้องการทำให้รายงานปัจจุบันเป็นแบบอัตโนมัติ ผู้ใช้จะต้องสร้างด้วยตนเองโดยการรวมรายงานปัจจุบันสองฉบับและเพิ่มการคำนวณที่ได้มาจากการรวมกันของ ข้อมูล.
แม้ว่าข้อกำหนดนี้จะเรียบง่าย แต่ก็กำหนดฟังก์ชันคุณลักษณะบางอย่างที่คุณต้องรวมไว้เมื่อซื้อเครื่องมือการรายงานสำหรับองค์กรของคุณ

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

อย่างไรก็ตาม ยังมีธุรกิจประเภทอื่นๆ ที่เราต้องวางแผนด้วย เมื่อข้อกำหนดทางธุรกิจระบุไว้ในรูปแบบของคำถามเชิงกลยุทธ์ทางธุรกิจ ผู้วางแผนที่มีประสบการณ์จะแยกแยะข้อกำหนดด้านมิติข้อมูลและการวัด/ข้อเท็จจริงได้ง่าย

หากผู้ใช้ JAD ไม่รู้วิธีระบุความต้องการในรูปแบบของปัญหาทางธุรกิจ นักออกแบบมักจะให้ตัวอย่างเพื่อข้าม-เริ่มเซสชันการรวบรวมข้อกำหนด
นักวางแผนผู้เชี่ยวชาญสามารถช่วยให้ผู้ใช้เข้าใจไม่เพียงแค่ธุรกิจเชิงกลยุทธ์เท่านั้น แต่ยังรวมถึงวิธีการกำหนดรูปแบบด้วย
วิธีการรวบรวมข้อกำหนดจะกล่าวถึงในบทที่ 3; สำหรับตอนนี้ เราเพียงต้องการชี้ให้เห็นถึงความจำเป็นในการออกแบบสำหรับข้อกำหนด BI ทุกประเภท

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

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

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

แต่ข้อกำหนดใดบ้างที่ผู้ใช้หรือทีม Dw ไม่เข้าใจในทันที คุณต้องการการวิเคราะห์เชิงพื้นที่ (การวิเคราะห์เชิงพื้นที่) หรือไม่?
แบบจำลองการขุดของ ข้อมูล พวกเขาจะเป็นส่วนสำคัญในอนาคตของคุณหรือไม่? ใครจะรู้?

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

ปัญหาที่มากขึ้นเกิดขึ้นเมื่อผู้ออกแบบและนักพัฒนาไม่สามารถรับรู้ถึงการประยุกต์ใช้หนึ่งในเทคโนโลยีขั้นสูงแต่สำคัญเหล่านี้ได้
อย่างที่เราเคยได้ยินนักออกแบบพูดกันบ่อยๆ ว่า “ทำไมเราไม่เก็บมันไว้จนกว่าจะได้อย่างอื่นมาล่ะ? “พวกเขาสนใจเรื่องลำดับความสำคัญจริงๆ หรือแค่หลีกเลี่ยงข้อกำหนดที่พวกเขาไม่เข้าใจกันแน่? น่าจะเป็นสมมติฐานหลัง สมมติว่าทีมขายของคุณได้สื่อสารความต้องการทางธุรกิจตามที่ระบุไว้ในรูปที่ 1.3 ตามที่คุณเห็น ความต้องการนั้นอยู่ในกรอบของปัญหาทางธุรกิจ ความแตกต่างระหว่างปัญหานี้กับปัญหามิติทั่วไปคือระยะทาง ในกรณีนี้ ทีมขายต้องการทราบยอดขายรวมจากผลิตภัณฑ์ คลังสินค้า และรายเดือนเป็นรายเดือน ลูกค้า ซึ่งอาศัยอยู่ภายในระยะ 5 ไมล์จากโกดังที่พวกเขาซื้อของ

น่าเศร้าที่นักออกแบบหรือสถาปนิกสามารถเพิกเฉยต่อองค์ประกอบเชิงพื้นที่ได้โดยพูดว่า "เรามีลูกค้า ผลิตภัณฑ์ และ ข้อมูล ของเงินฝาก เว้นระยะห่างไว้จนกว่าจะมีการทำซ้ำอีกครั้ง

"คำตอบที่ไม่ถูกต้อง. ปัญหาทางธุรกิจประเภทนี้เป็นเรื่องของ BI มันแสดงถึงความเข้าใจที่ลึกซึ้งยิ่งขึ้นเกี่ยวกับธุรกิจของเราและพื้นที่การวิเคราะห์ที่แข็งแกร่งสำหรับนักวิเคราะห์ของเรา BI เป็นมากกว่าการสอบถามธรรมดาหรือการรายงานมาตรฐาน หรือแม้แต่ OLAP ไม่ได้หมายความว่าเทคโนโลยีเหล่านี้ไม่มีความสำคัญต่อ BI ของคุณ แต่โดยตัวมันเองไม่ได้เป็นตัวแทนของสภาพแวดล้อม BI

การออกแบบบริบทข้อมูล (การออกแบบสำหรับเนื้อหาข้อมูล)

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

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

ชุดนี้ของ ข้อมูล ใช้เพื่อรองรับการใช้งานในภายหลังของ ข้อมูล มิติที่ขับเคลื่อนด้วยประเด็นทางธุรกิจที่เราได้ระบุ เนื่องจากมีการสร้างเอกสารเพิ่มเติม เช่น การพัฒนาโครงการของ ข้อมูลเราจะเริ่มต้นด้วยการทำให้เป็นทางการเป็น i ข้อมูล พวกเขาแพร่กระจายในสิ่งแวดล้อม เราได้ยืนยันความต้องการที่จะเป็นตัวแทนของฉัน ข้อมูล ในมิติแบ่งพวกเขา (ตามความต้องการเฉพาะเจาะจง) ลงในดาต้ามาร์ท

คำถามต่อไปที่ต้องตอบคือ Data Mart เหล่านี้จะถูกสร้างอย่างไร
คุณสร้างดาวเพื่อรองรับลูกบาศก์ หรือแค่ลูกบาศก์ หรือแค่ดวงดาว? (หรือลูกบาศก์ขวา หรือดาวขวา) สร้างสถาปัตยกรรมสำหรับ data mart ที่ขึ้นต่อกันซึ่งต้องการชั้นอะตอมสำหรับทุกคน ข้อมูล ได้มา? อนุญาตให้ดาต้ามาร์ทอิสระซื้อกิจการ ข้อมูล จากระบบปฏิบัติการโดยตรง?

เทคโนโลยีคิวบ์ใดที่คุณจะพยายามสร้างมาตรฐาน

คุณมีเทพเจ้าจำนวนมาก ข้อมูล จำเป็นสำหรับการวิเคราะห์มิติหรือคุณต้องการคิวบ์ยอดขายทั่วประเทศรายสัปดาห์หรือทั้งสองอย่าง คุณสร้างออบเจกต์ที่ทรงพลัง เช่น DB2 OLAP Server สำหรับการเงินหรือคิวบ์ Cognos PowerPlay สำหรับองค์กรการขายของคุณ หรือทั้งสองอย่าง สิ่งเหล่านี้คือการตัดสินใจออกแบบสถาปัตยกรรมครั้งใหญ่ที่จะส่งผลต่อสภาพแวดล้อม BI ของคุณในอนาคต ใช่ คุณได้ระบุความต้องการสำหรับ OLAP แล้ว ตอนนี้คุณจะทำอย่างไรกับเทคนิคและเทคโนโลยีแบบนั้น?

เทคโนโลยีขั้นสูงบางอย่างส่งผลต่อการออกแบบของคุณอย่างไร? สมมติว่าคุณได้ระบุความต้องการเชิงพื้นที่ในองค์กรของคุณ ตอนนี้คุณต้องเรียกคืนรุ่นเขียนแบบสถาปัตยกรรมแม้ว่าคุณจะไม่ได้วางแผนที่จะสร้างส่วนประกอบเชิงพื้นที่เป็นเวลาหลายเดือนก็ตาม สถาปนิกต้องออกแบบในวันนี้โดยคำนึงถึงสิ่งที่จำเป็น คาดการณ์ความจำเป็นในการวิเคราะห์เชิงพื้นที่ที่สร้าง จัดเก็บ บำรุงรักษา และให้การเข้าถึง ข้อมูล เชิงพื้นที่ สิ่งนี้ควรเป็นข้อจำกัดเกี่ยวกับประเภทของเทคโนโลยีซอฟต์แวร์และข้อกำหนดเฉพาะของแพลตฟอร์มที่คุณสามารถพิจารณาได้ในปัจจุบัน เช่น ระบบการบริหารงานของ ฐานข้อมูล เชิงสัมพันธ์ (RDBMS) ที่คุณรักษาไว้สำหรับชั้นอะตอมของคุณต้องมีขอบเขตเชิงพื้นที่ที่แข็งแกร่ง สิ่งนี้จะช่วยให้มั่นใจถึงประสิทธิภาพสูงสุดเมื่อคุณใช้รูปทรงเรขาคณิตและวัตถุเชิงพื้นที่ในแอปพลิเคชันการวิเคราะห์ของคุณ หาก RDBMS ของคุณไม่สามารถจัดการไฟล์ ข้อมูล (เชิงพื้นที่เป็นศูนย์กลาง) ภายใน ดังนั้นคุณจะต้องสร้าง ฐานข้อมูล (เชิงพื้นที่เป็นศูนย์กลาง) ภายนอก สิ่งนี้ทำให้การจัดการปัญหาซับซ้อนและทำให้ประสิทธิภาพโดยรวมของคุณลดลง ไม่ต้องพูดถึงปัญหาเพิ่มเติมที่สร้างขึ้นสำหรับ DBA ของคุณ เนื่องจากพวกเขาน่าจะมีความเข้าใจพื้นฐานของ ข้อมูล เชิงพื้นที่อีกด้วย ในทางกลับกัน หากกลไก RDMBS ของคุณจัดการส่วนประกอบเชิงพื้นที่ทั้งหมด และเครื่องมือเพิ่มประสิทธิภาพนั้นรับรู้ถึงความต้องการพิเศษ (เช่น การจัดทำดัชนี) ของวัตถุเชิงพื้นที่ DBA ของคุณจะสามารถจัดการปัญหาด้านการจัดการได้อย่างง่ายดาย และคุณสามารถเพิ่มประสิทธิภาพสูงสุดได้

นอกจากนี้ คุณต้องปรับ staging area และ atomic environment layer เพื่อรวม address cleanup (a

องค์ประกอบสำคัญในการวิเคราะห์เชิงพื้นที่) เช่นเดียวกับการบันทึกวัตถุเชิงพื้นที่ในภายหลัง การสืบทอดรุ่นการออกแบบยังคงดำเนินต่อไปเมื่อเราได้แนะนำแนวคิดเรื่องความสะอาดของที่อยู่ ประการแรก แอปพลิเคชันนี้จะกำหนดประเภทของซอฟต์แวร์ที่คุณต้องการสำหรับความพยายาม ETL ของคุณ

คุณต้องการผลิตภัณฑ์เช่น Trillium เพื่อให้ที่อยู่ที่ชัดเจนหรือผู้จำหน่าย ETL ที่คุณเลือกเพื่อให้ฟังก์ชันดังกล่าวหรือไม่
สำหรับตอนนี้ สิ่งสำคัญคือคุณต้องชื่นชมระดับของการออกแบบที่ต้องทำให้เสร็จก่อนที่คุณจะเริ่มบำรุงรักษาคลังสินค้าของคุณ ตัวอย่างข้างต้นควรแสดงให้เห็นถึงการตัดสินใจในการออกแบบที่หลากหลายซึ่งต้องเป็นไปตามการระบุข้อกำหนดทางธุรกิจเฉพาะใดๆ เมื่อทำอย่างถูกต้อง การตัดสินใจในการออกแบบเหล่านี้จะส่งเสริมการพึ่งพาซึ่งกันและกันระหว่างโครงสร้างทางกายภาพของสภาพแวดล้อมของคุณ การเลือกใช้เทคโนโลยีที่ใช้ และกระแสการเผยแพร่เนื้อหาข้อมูล หากไม่มีสถาปัตยกรรม BI แบบดั้งเดิมนี้ องค์กรของคุณจะอยู่ภายใต้การผสมผสานที่ยุ่งเหยิงของเทคโนโลยีที่มีอยู่ ที่ดีที่สุดคือการถักทอเข้าด้วยกันอย่างหลวมๆ เพื่อให้เกิดความเสถียรที่ชัดเจน

รักษาเนื้อหาข้อมูล

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

ทีมของคุณเตรียมพร้อมเพียงพอหรือไม่? มีใครในทีม BI ของคุณเข้าใจภูมิทัศน์การวิเคราะห์อันกว้างใหญ่ที่มีอยู่ในสภาพแวดล้อม BI และเทคนิคและเทคโนโลยีที่จำเป็นในการรักษาภูมิทัศน์นั้นหรือไม่ มีใครในทีมของคุณที่สามารถบอกความแตกต่างในการสมัครขั้นสูง

การรายงานแบบคงที่และ OLAP หรือความแตกต่างระหว่าง ROLAP และ OLAP? สมาชิกในทีมของคุณคนใดคนหนึ่งรู้จักวิธีการขุดอย่างชัดเจนหรือไม่ และอาจส่งผลกระทบต่อคลังสินค้าอย่างไร หรือคลังสินค้าสามารถรองรับประสิทธิภาพการขุดได้อย่างไร สมาชิกในทีมเข้าใจถึงคุณค่าของ ข้อมูล เทคโนโลยีอวกาศหรือตัวแทน? คุณมีคนที่ชอบใช้เครื่องมือเฉพาะของเทคโนโลยี ETL vs Message Broker หรือไม่? ถ้ายังไม่มีก็ซื้อเลย BI มีขนาดใหญ่กว่าชั้นอะตอมปกติ, OLAP, สคีมาดาว และ ODS

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

ไม่รู้จักแอปพลิเคชันเฉพาะของ BI - ตัวอย่างเช่น การทำเหมืองข้อมูล - จึงไม่ดีที่สุดที่สภาพแวดล้อม BI มักจะถูกจำกัดให้เป็นที่เก็บข้อมูลแบบพาสซีฟ อย่างไรก็ตาม การเพิกเฉยต่อเทคโนโลยีเหล่านี้ไม่ได้ลดความสำคัญและผลกระทบที่มีต่อความสามารถของระบบข่าวกรองธุรกิจในองค์กรของคุณ รวมถึงสินทรัพย์ข้อมูลที่คุณวางแผนจะส่งเสริม

การออกแบบต้องมีแนวคิดในการวาดภาพ และทั้งสองอย่างต้องใช้บุคคลที่มีความสามารถ นอกจากนี้ การวางแผนจำเป็นต้องมีปรัชญาของโรงเรือนและการปฏิบัติตามมาตรฐาน ตัวอย่างเช่น หากบริษัทของคุณได้สร้างมาตรฐานแพลตฟอร์มหรือระบุ RDBMS ที่ต้องการสร้างมาตรฐานทั่วทั้งแพลตฟอร์ม เป็นหน้าที่ของทุกคนในทีมที่จะต้องปฏิบัติตามมาตรฐานเหล่านั้น โดยทั่วไปแล้วทีมจะแสดงความต้องการมาตรฐาน (ต่อชุมชนผู้ใช้) แต่ทีมเองไม่เต็มใจที่จะปฏิบัติตามมาตรฐานที่กำหนดไว้ในด้านอื่นๆ ของบริษัท หรือแม้แต่ในบริษัทที่คล้ายคลึงกัน สิ่งนี้ไม่เพียงเป็นการเสแสร้งเท่านั้น แต่ยังทำให้บริษัทไม่สามารถใช้ประโยชน์จากทรัพยากรและการลงทุนที่มีอยู่ได้ ไม่ได้หมายความว่าไม่มีสถานการณ์ที่รับประกันแพลตฟอร์มหรือเทคโนโลยีที่ไม่ได้มาตรฐาน อย่างไรก็ตามความพยายามของคลังสินค้า

พวกเขาควรรักษามาตรฐานขององค์กรด้วยความหึงหวงจนกว่าข้อกำหนดทางธุรกิจจะกำหนดเป็นอย่างอื่น

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

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

ระเบียบวินัยยังเป็นหัวข้อที่ทั้งองค์กรจำเป็นต้องได้รับการแก้ไข และมักจะถูกกำหนดขึ้นและได้รับคำสั่งจากระดับผู้บริหาร
ผู้บริหารยินดีที่จะปฏิบัติตามแนวทางที่ออกแบบไว้หรือไม่? แนวทางที่สัญญาว่าจะสร้างเนื้อหาข้อมูลที่จะส่งมอบคุณค่าให้กับทุกด้านขององค์กรในท้ายที่สุด แต่อาจกระทบต่อวาระของแต่ละบุคคลหรือแผนก? จำคำกล่าวที่ว่า “การคิดทุกเรื่องสำคัญกว่าการคิดเรื่องเดียว” คำพูดนี้เป็นจริงสำหรับองค์กร BI

น่าเสียดายที่คลังสินค้าหลายแห่งมุ่งเน้นที่ความพยายามในการกำหนดเป้าหมายและส่งมอบคุณค่าให้กับแผนกใดแผนกหนึ่งหรือผู้ใช้เฉพาะ โดยไม่ค่อยคำนึงถึงองค์กรโดยรวม สมมติว่าผู้จัดการขอความช่วยเหลือจากทีมคลังสินค้า ทีมงานตอบสนองด้วยความพยายาม 90 วันที่ไม่เพียง แต่ส่งข้อกำหนดการแจ้งเตือนที่กำหนดโดยผู้บริหารเท่านั้น แต่ยังรับรองว่าทั้งหมด ข้อมูล เบสถูกผสมลงในระดับอะตอมก่อนที่จะนำเข้าสู่เทคโนโลยีลูกบาศก์ที่นำเสนอ
การเพิ่มทางวิศวกรรมนี้ทำให้มั่นใจได้ว่าองค์กรคลังสินค้าจะได้รับประโยชน์จาก ข้อมูล จำเป็นโดยผู้จัดการ
อย่างไรก็ตาม ผู้บริหารได้พูดคุยกับบริษัทที่ปรึกษาภายนอกที่เสนอใบสมัครที่คล้ายกันพร้อมจัดส่งภายในเวลาไม่ถึง 4 สัปดาห์

สมมติว่าทีมคลังสินค้าภายในมีความสามารถ ผู้จัดการมีทางเลือก ใครสามารถสนับสนุนระเบียบวินัยด้านวิศวกรรมเพิ่มเติมที่จำเป็นต่อการขยายสินทรัพย์ข้อมูลขององค์กร หรือสามารถเลือกสร้างโซลูชันของตนเองได้อย่างรวดเร็ว ดูเหมือนว่าตัวเลือกหลังนี้จะถูกเลือกบ่อยเกินไปและทำหน้าที่สร้างคอนเทนเนอร์ของข้อมูลที่เป็นประโยชน์ต่อคนส่วนน้อยหรือเฉพาะบุคคลเท่านั้น

เป้าหมายระยะสั้นและระยะยาว

สถาปนิกและผู้วางแผนโครงการต้องกำหนดวิสัยทัศน์ระยะยาวของสถาปัตยกรรมโดยรวมและแผนสำหรับการเติบโตขององค์กร BI การรวมกันของผลประโยชน์ระยะสั้นและการวางแผนระยะยาวเป็นสองด้านของความพยายามของ BI รายได้ระยะสั้นคือแง่มุมของ BI ที่เชื่อมโยงกับการวนซ้ำของคลังสินค้าของคุณ

นี่คือจุดที่นักวางแผน สถาปนิก และผู้สนับสนุนมุ่งเน้นไปที่การปฏิบัติตามข้อกำหนดทางธุรกิจที่เฉพาะเจาะจง ในระดับนี้ซึ่งมีการสร้างโครงสร้างทางกายภาพ ซื้อเทคโนโลยีและมีการนำเทคนิคต่างๆ มาใช้ พวกเขาไม่ได้ทำเพื่อตอบสนองความต้องการเฉพาะที่กำหนดโดยชุมชนผู้ใช้เฉพาะ ทุกอย่างเสร็จสิ้นโดยมีจุดประสงค์เพื่อตอบสนองความต้องการเฉพาะที่กำหนดโดยชุมชนเฉพาะ
อย่างไรก็ตาม การวางแผนระยะยาวเป็นอีกแง่มุมหนึ่งของ BI นี่คือจุดที่แผนและการออกแบบทำให้มั่นใจได้ว่าโครงสร้างทางกายภาพใดๆ ถูกสร้างขึ้น เทคโนโลยีที่เลือกและเทคนิคที่ทำสำเร็จโดยมุ่งเป้าไปที่องค์กร เป็นการวางแผนระยะยาวที่ให้ความสอดคล้องที่จำเป็นเพื่อให้แน่ใจว่ากำไรของบริษัทนั้นมาจากกำไรระยะสั้นที่พบ

ปรับความพยายาม BI ของคุณ

Un คลังข้อมูล โดยตัวมันเองไม่มีค่าโดยธรรมชาติ กล่าวอีกนัยหนึ่ง ไม่มีคุณค่าโดยธรรมชาติระหว่างเทคโนโลยีคลังสินค้าและเทคนิคการนำไปใช้งาน

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

บ่อยครั้งที่สถาปนิกและนักวางแผนพยายามใช้คุณค่ากับส่วนประกอบทางกายภาพและทางเทคนิคของคลังสินค้า ทั้งที่ความจริงแล้วมูลค่านั้นมีรากฐานมาจากกระบวนการทางธุรกิจที่ได้รับผลกระทบเชิงบวกจากคลังสินค้าและข้อมูลที่รวบรวมได้อย่างดี

ความท้าทายในการก่อตั้ง BI อยู่ที่นี้: คุณจะปรับการลงทุนอย่างไร หากตัวบ้านเองไม่มีมูลค่าที่แท้จริง ผู้วางแผนโครงการจะต้องตรวจสอบ กำหนด และกำหนดผลประโยชน์อย่างเป็นทางการให้กับบุคคลเหล่านั้นที่จะใช้คลังสินค้าเพื่อปรับปรุงกระบวนการทางธุรกิจเฉพาะหรือคุณค่าของข้อมูลที่ได้รับการคุ้มครอง หรือทั้งสองอย่าง

เพื่อให้เรื่องยุ่งยาก กระบวนการทางธุรกิจใดๆ ที่ได้รับผลกระทบจากความพยายามในคลังสินค้าอาจให้ประโยชน์ "มาก" หรือ "เล็กน้อย" ประโยชน์ที่สำคัญให้เมตริกที่จับต้องได้สำหรับการวัดผลตอบแทนจากการลงทุน (ROI) เช่น การหมุนเวียนสินค้าคงคลังเพิ่มขึ้นในช่วงเวลาหนึ่งหรือเพื่อลดต้นทุนการขนส่งต่อการจัดส่ง เป็นการยากกว่าที่จะกำหนดผลประโยชน์ที่ลึกซึ้ง เช่น การเข้าถึงข้อมูลที่ดีขึ้น ในแง่ของมูลค่าที่จับต้องได้

เชื่อมต่อโครงการของคุณเพื่อทำความรู้จักกับ คำขอทางธุรกิจ

บ่อยครั้งที่ผู้วางแผนโครงการพยายามเชื่อมโยงมูลค่าคลังสินค้ากับเป้าหมายองค์กรที่ไม่แน่นอน ด้วยการประกาศว่า "มูลค่าของคลังสินค้าขึ้นอยู่กับความสามารถของเราในการตอบสนองคำขอเชิงกลยุทธ์" เราจึงเปิดการสนทนาในลักษณะที่น่ายินดี แต่เพียงอย่างเดียวไม่เพียงพอที่จะตัดสินว่าการลงทุนในคลังสินค้าเหมาะสมหรือไม่ เป็นการดีที่สุดที่จะเชื่อมโยงตัวแทนคลังสินค้าเข้ากับข้อซักถามและบันทึกทางธุรกิจที่เฉพาะเจาะจง

วัด ROI

การคำนวณ ROI ในการตั้งค่าคลังสินค้าอาจเป็นเรื่องยากเป็นพิเศษ เป็นเรื่องยากโดยเฉพาะอย่างยิ่งหากเป็นผู้นำ

ของการทำซ้ำเฉพาะเป็นสิ่งที่จับต้องไม่ได้หรือวัดได้ง่าย การศึกษาชิ้นหนึ่งพบว่าผู้ใช้รับรู้ประโยชน์หลักสองประการของการริเริ่ม BI:

• ▪ สร้างความสามารถในการตัดสินใจ
• ▪ สร้างการเข้าถึงข้อมูล
  ประโยชน์เหล่านี้เป็นประโยชน์ที่นุ่มนวล (หรือไม่รุนแรง) เป็นเรื่องง่ายที่จะดูว่าเราสามารถคำนวณ ROI ตามผลประโยชน์ที่ยาก (หรือมากกว่า) เช่น ค่าขนส่งที่ลดลงได้อย่างไร แต่เราจะวัดความสามารถในการตัดสินใจที่ดีขึ้นได้อย่างไร
  นี่เป็นความท้าทายอย่างแน่นอนสำหรับผู้วางแผนโครงการเมื่อพวกเขาพยายามให้บริษัทลงทุนในคลังสินค้าโดยเฉพาะ การเพิ่มยอดขายหรือต้นทุนที่ลดลงไม่ใช่ประเด็นหลักที่ขับเคลื่อนสภาพแวดล้อม BI อีกต่อไป
  แต่คุณกำลังมองหาคำขอทางธุรกิจเพื่อการเข้าถึงข้อมูลที่ดีขึ้น เพื่อให้แผนกใดแผนกหนึ่งสามารถตัดสินใจได้เร็วขึ้น สิ่งเหล่านี้เป็นตัวขับเคลื่อนเชิงกลยุทธ์ที่มีความสำคัญต่อองค์กรเท่าๆ กัน แต่มีความคลุมเครือมากกว่าและยากต่อการระบุลักษณะเป็นเมตริกที่จับต้องได้ ในกรณีนี้ การคำนวณ ROI อาจทำให้เข้าใจผิดได้ หากไม่เกี่ยวข้องกัน
  ผู้ออกแบบโครงการต้องสามารถแสดงให้เห็นถึงคุณค่าที่จับต้องได้สำหรับผู้บริหารในการตัดสินใจว่าการลงทุนในการทำซ้ำเฉพาะนั้นคุ้มค่าหรือไม่ อย่างไรก็ตาม เราจะไม่เสนอวิธีการใหม่ในการคำนวณ ROI และเราจะไม่โต้แย้งหรือโต้แย้งใดๆ
  มีบทความและหนังสือมากมายที่กล่าวถึงพื้นฐานของการคำนวณ ROI มีการนำเสนอคุณค่าพิเศษ เช่น มูลค่าการลงทุน (VOI) ซึ่งเสนอโดยกลุ่มต่างๆ เช่น Gartner ที่คุณสามารถค้นคว้าได้ แต่เราจะเน้นไปที่ประเด็นหลักของ ROI หรือคุณค่าอื่นๆ ที่คุณต้องพิจารณาแทน ใช้ ROI นอกเหนือจากข้อโต้แย้งเกี่ยวกับผลประโยชน์ "ยาก" กับ "อ่อน" ที่เกี่ยวข้องกับความพยายามของ BI แล้ว ยังมีประเด็นอื่นๆ ที่ต้องพิจารณาเมื่อใช้ ROI ตัวอย่างเช่น:

ระบุถึงการประหยัดมากเกินไปสำหรับความพยายามของ DW ที่จะตามมา
สมมติว่าบริษัทของคุณย้ายจากสถาปัตยกรรมเมนเฟรมไปยังสภาพแวดล้อมแบบยูนิกซ์แบบกระจาย ดังนั้นการประหยัดใด ๆ ที่อาจ (หรืออาจไม่) รับรู้จากความพยายามนั้นไม่ควรนำมาประกอบกับคลังสินค้าแต่เพียงผู้เดียว (หากเป็นเช่นนั้น (?))

การไม่นับทุกอย่างมีราคาแพง และมีหลายสิ่งที่ต้องคำนึงถึง พิจารณารายการต่อไปนี้:

• ▪ ค่าใช้จ่ายในการเริ่มต้น รวมถึงความเป็นไปได้
• ▪ ค่าใช้จ่ายของฮาร์ดแวร์เฉพาะที่มีการจัดเก็บและการสื่อสารที่เกี่ยวข้อง
• ▪ ต้นทุนของซอฟต์แวร์ รวมถึงการจัดการ ข้อมูล และส่วนขยายไคลเอ็นต์/เซิร์ฟเวอร์ ซอฟต์แวร์ ETL เทคโนโลยี DSS เครื่องมือสร้างภาพ แอปพลิเคชันการจัดตารางเวลาและเวิร์กโฟลว์ และซอฟต์แวร์ตรวจสอบ
• ▪ ค่าออกแบบโครงสร้าง ข้อมูลด้วยการสร้างและเพิ่มประสิทธิภาพของ
• ▪ ต้นทุนการพัฒนาซอฟต์แวร์เกี่ยวข้องโดยตรงกับความพยายามของ BI
• ▪ ค่าใช้จ่ายในการช่วยเหลือที่บ้าน รวมถึงการเพิ่มประสิทธิภาพ รวมถึงการควบคุมเวอร์ชันของซอฟต์แวร์และการดำเนินการช่วยเหลือ ใช้ ROI แบบ “บิ๊กแบง” การสร้างคลังสินค้าเป็นความพยายามขนาดมหึมาเพียงครั้งเดียวนั้นล้มเหลว ดังนั้นการคำนวณ ROI สำหรับการริเริ่มขององค์กรขนาดใหญ่ก็เช่นกัน ข้อเสนอนี้น่าประหลาดใจ และผู้วางแผนยังคงใช้ความพยายามเพียงเล็กน้อยในการประเมินมูลค่าของความพยายามทั้งหมด เหตุใดนักวางแผนจึงพยายามให้มูลค่าเป็นตัวเงินในการริเริ่มธุรกิจ หากเป็นที่ทราบกันอย่างกว้างขวางและยอมรับว่าการประมาณการซ้ำๆ นั้นเป็นเรื่องยาก มันเป็นไปได้ยังไงกัน? เป็นไปไม่ได้ด้วยข้อยกเว้นบางประการ อย่าทำมัน ตอนนี้เราได้กำหนดสิ่งที่ไม่ควรทำเมื่อคำนวณ ROI แล้ว ต่อไปนี้เป็นจุดเล็กๆ น้อยๆ ที่จะช่วยให้คุณสร้างกระบวนการที่เชื่อถือได้ในการประเมินมูลค่าของความพยายามด้าน BI ของคุณ

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

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

กำหนดค่าใช้จ่าย ดังที่ได้กล่าวมาแล้ว จำเป็นต้องพิจารณาค่าใช้จ่ายจำนวนมาก นอกจากนี้ ค่าใช้จ่ายต้องไม่รวมถึงค่าใช้จ่ายที่เกี่ยวข้องกับการทำซ้ำแต่ละรายการเท่านั้น แต่ยังรวมถึงค่าใช้จ่ายที่เกี่ยวข้องกับการรับรองการปฏิบัติตามมาตรฐานขององค์กรด้วย

กำหนดผลประโยชน์ การเชื่อมโยง ROI กับข้อกำหนดทางธุรกิจที่เฉพาะเจาะจงอย่างชัดเจน เราควรจะสามารถระบุประโยชน์ที่จะนำไปสู่การปฏิบัติตามข้อกำหนดได้

ลดต้นทุนและผลประโยชน์ที่จะได้รับในอนาคตอันใกล้ เป็นวิธีที่ดีที่สุดในการประเมินมูลค่าของคุณตามมูลค่าปัจจุบันสุทธิ (NPV) แทนที่จะพยายามคาดการณ์มูลค่าในอนาคตของรายได้ในอนาคต

รักษาเวลาในการแบ่ง ROI ของคุณให้น้อยที่สุด มีการบันทึกไว้อย่างดีในระยะยาวว่ามีการใช้ใน ROI ของคุณ

ใช้สูตร ROI มากกว่าหนึ่งสูตร มีหลายวิธีในการทำนาย ROI และคุณควรวางแผนที่จะใช้อย่างน้อยหนึ่งวิธี รวมถึงมูลค่าปัจจุบันสุทธิ อัตราผลตอบแทนภายใน (IRR) และการคืนทุน

กำหนดกระบวนการที่ทำซ้ำได้ นี่เป็นสิ่งสำคัญสำหรับการคำนวณมูลค่าระยะยาว ควรบันทึกกระบวนการที่ทำซ้ำได้เพียงครั้งเดียวสำหรับลำดับย่อยของโครงการที่ตามมาทั้งหมด

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

คำถามเกี่ยวกับผลประโยชน์ ROI

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

• คุณจะให้คะแนนความเข้าใจเกี่ยวกับ ข้อมูล ตามโครงการนี้ของบริษัทคุณ?
• คุณจะให้คะแนนการปรับปรุงกระบวนการอันเป็นผลมาจากโครงการนี้อย่างไร
• คุณจะวัดผลกระทบของข้อมูลเชิงลึกและการอนุมานใหม่ๆ ที่มีอยู่ในการวนซ้ำนี้ได้อย่างไร
• อะไรคือผลกระทบของสภาพแวดล้อมคอมพิวเตอร์ใหม่และดีขึ้นอันเป็นผลมาจากสิ่งที่ได้เรียนรู้? หากคำตอบสำหรับคำถามเหล่านี้มีน้อย เป็นไปได้ว่าองค์กรไม่คุ้มกับการลงทุน คำถามที่มีคะแนนสูงชี้ให้เห็นถึงคุณค่าที่เพิ่มขึ้นอย่างมีนัยสำคัญ และควรใช้เป็นแนวทางสำหรับการตรวจสอบต่อไป ตัวอย่างเช่น คะแนนสูงสำหรับการปรับปรุงกระบวนการควรทำให้นักออกแบบตรวจสอบว่ากระบวนการได้รับการปรับปรุงอย่างไร คุณอาจพบว่ากำไรบางส่วนหรือทั้งหมดจับต้องได้ ดังนั้นจึงสามารถใช้มูลค่าเงินได้อย่างง่ายดาย รับประโยชน์สูงสุดจากการทำซ้ำครั้งแรกของ คลังสินค้า ผลตอบแทนที่ใหญ่ที่สุดจากความพยายามในองค์กรของคุณมักจะเกิดขึ้นซ้ำๆ สองสามครั้งแรก ความพยายามในช่วงต้นเหล่านี้สร้างเนื้อหาข้อมูลที่เป็นประโยชน์มากที่สุดสำหรับสาธารณะและช่วยสร้างรากฐานเทคโนโลยีสำหรับแอปพลิเคชัน BI ในภายหลัง โดยปกติแต่ละลำดับที่ตามมาของ ข้อมูล ของโครงการคลังสินค้าสร้างมูลค่าเพิ่มให้กับองค์กรโดยรวมน้อยลงเรื่อยๆ โดยเฉพาะอย่างยิ่งหากการวนซ้ำไม่ได้เพิ่มหัวข้อใหม่หรือตอบสนองความต้องการของชุมชนผู้ใช้ใหม่

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

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

แต่ขั้นตอนแรกเหล่านี้มีค่ามากที่สุด ดังนั้นผู้วางแผนโครงการจึงมักต้องปรับการลงทุนให้เหมาะสม
โครงการที่ทำหลังจากการริเริ่ม BI ของคุณอาจมีต้นทุนทางตรงต่ำกว่า (เมื่อเทียบกับโครงการแรก) แต่สร้างคุณค่าให้กับองค์กรน้อยลง

และเจ้าขององค์กรจำเป็นต้องเริ่มพิจารณาที่จะทิ้งงานสะสม ข้อมูล และเทคโนโลยีที่เกี่ยวข้องน้อยกว่า

การทำเหมืองข้อมูล : การสกัด ให้

ส่วนประกอบทางสถาปัตยกรรมจำนวนมากต้องการความหลากหลายของเทคโนโลยีและเทคนิคการขุดข้อมูล—
ตัวอย่างเช่น "ตัวแทน" ที่แตกต่างกันสำหรับการตรวจสอบจุดสนใจของ ลูกค้าระบบปฏิบัติการของบริษัท และสำหรับ dw เดียวกัน ตัวแทนเหล่านี้สามารถเป็นเครือข่ายประสาทขั้นสูงที่ได้รับการฝึกฝนเกี่ยวกับแนวโน้มหม้อ เช่น ความต้องการผลิตภัณฑ์ในอนาคตตามการส่งเสริมการขาย เอ็นจิ้นตามกฎสำหรับการตอบสนองต่อชุด Dato ของสถานการณ์ต่างๆ เช่น คำแนะนำในการวินิจฉัยทางการแพทย์และการรักษา หรือแม้แต่ตัวแทนธรรมดาที่มีบทบาทในการรายงานข้อยกเว้นต่อผู้บริหารระดับสูง โดยทั่วไปกระบวนการสกัดเหล่านี้ ข้อมูล si

ตรวจสอบตามเวลาจริง ดังนั้นพวกเขาจะต้องรวมเป็นหนึ่งเดียวกับการเคลื่อนไหวของ ข้อมูล Stessi.

การประมวลผลการวิเคราะห์ออนไลน์

การวิเคราะห์ออนไลน์

ความสามารถในการสไลซ์ ลูกเต๋า ทอย เจาะลึก และทำการวิเคราะห์
จะเป็นอย่างไร ถ้าอยู่ในขอบเขต ขอบเขตของชุดเทคโนโลยี IBM ตัวอย่างเช่น มีฟังก์ชันการประมวลผลเชิงวิเคราะห์ออนไลน์ (OLAP) สำหรับ DB2 ซึ่งนำการวิเคราะห์เชิงมิติมาไว้ในกลไกของ ฐานข้อมูล เดียวกัน .

ฟังก์ชันเพิ่มยูทิลิตี้เชิงมิติให้กับ SQL ในขณะที่เก็บเกี่ยวผลประโยชน์ทั้งหมดจากการเป็นส่วนหนึ่งของ DB2 อีกตัวอย่างหนึ่งของการรวม OLAP คือเครื่องมือแยกไฟล์ DB2 OLAP Analyzer Server เทคโนโลยีนี้ช่วยให้ลูกบาศก์ DB2 OLAP Server สามารถสแกนได้อย่างรวดเร็วและอัตโนมัติเพื่อค้นหาและรายงานค่าของ ข้อมูล ผิดปกติหรือคาดไม่ถึงสำหรับคิวบ์ใด ๆ ต่อนักวิเคราะห์การซื้อขาย และประการสุดท้าย ฟังก์ชัน DW Center ช่วยให้สถาปนิกสามารถตรวจสอบโปรไฟล์ของเซิร์ฟเวอร์ลูกบาศก์ DB2 OLAP ในฐานะส่วนปกติของกระบวนการ ETL เหนือสิ่งอื่นใด

การวิเคราะห์เชิงพื้นที่ การวิเคราะห์เชิงพื้นที่

ช่องว่างแสดงถึงครึ่งหนึ่งของจุดยึดเชิงวิเคราะห์ (การนำไฟฟ้า) ที่จำเป็นสำหรับภาพพาโนรามา
วิเคราะห์กว้างๆ (เวลาแทนอีกครึ่งหนึ่ง) ระดับอะตอมของคลังสินค้าที่แสดงในรูปที่ 1.1 รวมถึงรากฐานของเวลาและพื้นที่ การวิเคราะห์จุดยึดการประทับเวลาตามเวลาและการวิเคราะห์จุดยึดข้อมูลที่อยู่ตามพื้นที่ การประทับเวลาจะทำการวิเคราะห์ตามเวลา และข้อมูลที่อยู่จะทำการวิเคราะห์ตามช่องว่าง แผนภาพแสดง geocoding ซึ่งเป็นกระบวนการแปลงที่อยู่เป็นจุดในแผนที่หรือจุดในอวกาศ เพื่อให้สามารถใช้แนวคิดต่างๆ เช่น ระยะทางและภายใน/ภายนอกในการวิเคราะห์ได้ ซึ่งดำเนินการในระดับอะตอมและการวิเคราะห์เชิงพื้นที่พร้อมให้ใช้งานสำหรับนักวิเคราะห์ IBM จัดเตรียมส่วนขยายเชิงพื้นที่ซึ่งพัฒนาร่วมกับสถาบันวิจัยระบบสิ่งแวดล้อม (ESRI) ฐานข้อมูล DB2 เพื่อให้วัตถุเชิงพื้นที่สามารถรักษาไว้เป็นส่วนปกติของ ฐานข้อมูล เชิงสัมพันธ์ ฐานข้อมูล2

Spatial Extenders ยังมีส่วนขยาย SQL ทั้งหมดเพื่อใช้ประโยชน์จากการวิเคราะห์เชิงพื้นที่ ตัวอย่างเช่น ส่วนขยาย SQL ที่จะสืบค้น
ระยะห่างระหว่างตำแหน่งหรือจุดที่อยู่ภายในหรือภายนอกพื้นที่รูปหลายเหลี่ยมที่กำหนดเป็นมาตรฐานการวิเคราะห์ด้วย Spatial Extender ดูบทที่ 16 สำหรับข้อมูลเพิ่มเติม

ฐานข้อมูลเครื่องมือ -Resident Tools ฐานข้อมูล- ผู้พักอาศัย

DB2 มีคุณสมบัติ SQL BI-resident มากมายที่ช่วยในการแยกวิเคราะห์ เหล่านี้รวมถึง:

• ฟังก์ชันการเรียกซ้ำเพื่อทำการวิเคราะห์ เช่น "ค้นหาเส้นทางการบินที่เป็นไปได้ทั้งหมดจาก ซานฟรานซิสโก a นิวยอร์ก"
• ฟังก์ชันการวิเคราะห์สำหรับฟังก์ชันการจัดอันดับ สะสม คิวบ์และโรลอัพเพื่ออำนวยความสะดวกในงานที่ปกติจะเกิดขึ้นเฉพาะกับเทคโนโลยี OLAP ปัจจุบันกลายเป็นส่วนหนึ่งของเครื่องมือของ ฐานข้อมูล
• ความสามารถในการสร้างตารางที่มีผลลัพธ์
  ฉันเวนดิโทริดิ ฐานข้อมูล ผู้นำผสมผสานคุณสมบัติ BI มากขึ้นใน ฐานข้อมูล Stesso.
  ซัพพลายเออร์หลักของ ฐานข้อมูล พวกเขากำลังผสมคุณสมบัติ BI มากขึ้นใน ฐานข้อมูล Stesso.
  สิ่งนี้ให้ประสิทธิภาพที่ดีขึ้นและตัวเลือกการดำเนินการเพิ่มเติมสำหรับโซลูชัน BI
  คุณลักษณะและฟังก์ชันของ DB2 V8 ได้รับการกล่าวถึงโดยละเอียดในบทต่อไปนี้:
  สถาปัตยกรรมทางเทคนิคและพื้นฐานการจัดการข้อมูล (บทที่ 5)

• พื้นฐาน DB2 BI (บทที่ 6)
• ตารางแบบสอบถาม Materialized DB2 (บทที่ 7)
• ฟังก์ชัน DB2 OLAP (บทที่ 13)
• คุณลักษณะและฟังก์ชัน BI ที่ปรับปรุงแล้วของ DB2 (บทที่ 15) ระบบการนำส่งข้อมูลแบบง่าย ระบบจัดส่งสินค้าของ ข้อมูล ตัวย่อ

สถาปัตยกรรมที่แสดงในรูปที่ 1.1 ประกอบด้วยโครงสร้างต่างๆ มากมาย ข้อมูล ทางกายภาพ. หนึ่งคือคลังสินค้าของ ข้อมูล ปฏิบัติการ. โดยทั่วไป ODS เป็นแบบเชิงวัตถุ บูรณาการ และเป็นปัจจุบัน คุณจะสร้าง ODS เพื่อสนับสนุน เช่น สำนักงานขาย การขาย ODS จะเสริม ข้อมูล จากระบบต่างๆ มากมาย แต่จะเก็บไว้ เช่น ธุรกรรมของวันนี้เท่านั้น ODS สามารถอัปเดตได้หลายครั้งต่อวัน ในขณะเดียวกัน กระบวนการจะผลักดัน i ข้อมูล รวมเข้ากับแอปพลิเคชันอื่น ๆ โครงสร้างนี้ได้รับการออกแบบมาโดยเฉพาะเพื่อบูรณาการ ข้อมูล ปัจจุบันและไดนามิกและน่าจะเป็นผู้สมัครที่สนับสนุนการวิเคราะห์ตามเวลาจริง เช่น การจัดหาตัวแทนบริการ ลูกค้า ข้อมูลการขายปัจจุบันของลูกค้าโดยการดึงข้อมูลแนวโน้มการขายจากสินค้าคงคลัง โครงสร้างอื่นที่แสดงในรูปที่ 1.1 เป็นสถานะที่เป็นทางการสำหรับ dw ที่นี่ไม่เพียงแต่เป็นสถานที่สำหรับการบูรณาการที่จำเป็นเท่านั้น แต่ยังรวมถึงคุณภาพของ ข้อมูลและการเปลี่ยนแปลงของ ข้อมูล ของคลังสินค้าที่เข้ามา แต่ยังเป็นพื้นที่จัดเก็บที่เชื่อถือได้และชั่วคราวสำหรับ ข้อมูล แบบจำลองที่สามารถใช้ในการวิเคราะห์แบบเรียลไทม์ หากคุณตัดสินใจใช้ ODS หรือ staging area ซึ่งเป็นหนึ่งในเครื่องมือที่ดีที่สุดในการเติมโครงสร้างเหล่านี้ ข้อมูล การใช้แหล่งที่มาของการดำเนินงานที่แตกต่างกันคือแบบสอบถามแบบกระจายที่แตกต่างกันของ DB2 ความสามารถนี้จัดส่งโดยคุณสมบัติเสริมของ DB2 ที่เรียกว่า DB2 Relational Connect (เคียวรีเท่านั้น) และผ่าน DB2 DataJoiner (ผลิตภัณฑ์แยกต่างหากที่มอบความสามารถเคียวรี แทรก อัพเดต และลบไปยัง RDBMS ที่กระจายต่างกัน)

เทคโนโลยีนี้ช่วยให้สถาปนิกสามารถ ข้อมูล ผูก ข้อมูล ของการผลิตด้วยกระบวนการวิเคราะห์ ไม่เพียงแต่เทคโนโลยีจะสามารถปรับให้เข้ากับความต้องการในการจำลองแบบเสมือนใดๆ ก็ตามที่อาจเกิดขึ้นจากการวิเคราะห์ตามเวลาจริง แต่ยังสามารถเชื่อมต่อกับหลากหลาย ข้อมูล ยอดนิยม ได้แก่ DB2, Oracle, Sybase, SQL Server, Informix และอื่นๆ สามารถใช้ DB2 DataJoiner เพื่อเติมข้อมูลในโครงสร้าง ข้อมูล เป็นทางการ เช่น ODS หรือแม้แต่ตารางถาวรที่แสดงในคลังสินค้า ซึ่งออกแบบมาสำหรับการกู้คืนอย่างรวดเร็วของการอัปเดตทันทีหรือเพื่อขาย แน่นอนว่าโครงสร้างเหล่านี้เอง ข้อมูล สามารถเติมได้โดยใช้

อีกหนึ่งเทคโนโลยีสำคัญที่ออกแบบมาเพื่อการจำลองแบบ ข้อมูล, IBM DataPropagator เชิงสัมพันธ์ (DataPropagator เป็นผลิตภัณฑ์แยกต่างหากสำหรับระบบส่วนกลาง DB2 UNIX, Linux, Windows และ OS/2 รวมถึงบริการจำลองแบบของ ข้อมูล เป็นคุณสมบัติมาตรฐาน)
อีกวิธีในการเคลื่อนย้าย ข้อมูล การดำเนินงานทั่วทั้งองค์กรคือตัวรวบรวมแอปพลิเคชันขององค์กรหรือที่เรียกว่า Message Broker เทคโนโลยีเฉพาะนี้ช่วยให้สามารถควบคุมการกำหนดเป้าหมายและการย้ายที่ไม่มีใครเทียบได้ ข้อมูล รอบบริษัท. IBM มีเมสเสจโบรคเกอร์ที่ใช้กันอย่างแพร่หลาย MQSeries หรือรูปแบบต่างๆ ของผลิตภัณฑ์ที่มีข้อกำหนดสำหรับ E-commerce, IBM WebSphere MQ
สำหรับการสนทนาเพิ่มเติมเกี่ยวกับวิธีการใช้ประโยชน์จาก MQ เพื่อสนับสนุนคลังสินค้าและสภาพแวดล้อม BI โปรดไปที่ เว็บไซต์ ของหนังสือ สำหรับตอนนี้ พอจะกล่าวได้ว่าเทคโนโลยีนี้เป็นวิธีที่ดีเยี่ยมในการจับภาพและการแปลง (โดยใช้ MQSeries Integrator) ข้อมูล คัดเลือกผู้ปฏิบัติงานเป้าหมายสำหรับโซลูชัน BI เทคโนโลยี MQ ได้รับการผสานรวมและจัดทำเป็นแพ็คเกจใน UDB V8 ซึ่งหมายความว่าตอนนี้สามารถจัดการคิวข้อความได้ราวกับว่าเป็นตาราง DB2 แนวคิดของข้อความคิวเชื่อมและจักรวาลของ ฐานข้อมูล เชิงสัมพันธ์มุ่งสู่สภาพแวดล้อมที่มีประสิทธิภาพในการส่งมอบ ข้อมูล.

เวลาแฝงเป็นศูนย์ เวลาแฝงเป็นศูนย์

เป้าหมายเชิงกลยุทธ์สูงสุดสำหรับ IBM คือการวิเคราะห์เวลาแฝงเป็นศูนย์ ตามที่กำหนดโดย
Gartner ซึ่งเป็นระบบ BI จะต้องสามารถอนุมาน นำเข้า และให้ข้อมูลสำหรับนักวิเคราะห์ตามความต้องการได้ แน่นอนว่าความท้าทายคือวิธีการผสม ข้อมูล ปัจจุบันและเรียลไทม์พร้อมข้อมูลทางประวัติศาสตร์ที่จำเป็น เช่น i ข้อมูล แนวโน้ม/รูปแบบที่เกี่ยวข้อง หรือข้อมูลเชิงลึกที่แยกออกมา เช่น การทำโปรไฟล์ลูกค้า

ข้อมูลดังกล่าวรวมถึง เช่น การระบุ ลูกค้า ความเสี่ยงสูงหรือต่ำหรือผลิตภัณฑ์ใด i ลูกค้า พวกเขามักจะซื้อหากมีชีสในตะกร้าสินค้าอยู่แล้ว

การได้รับเวลาแฝงเป็นศูนย์นั้นขึ้นอยู่กับกลไกพื้นฐานสองประการ:

• สหภาพที่สมบูรณ์ของ ข้อมูล ซึ่งวิเคราะห์ด้วยเทคนิคที่กำหนดขึ้นและด้วยเครื่องมือที่สร้างขึ้นโดย BI
• ระบบจัดส่งของ ข้อมูล มีประสิทธิภาพเพื่อให้แน่ใจว่าการวิเคราะห์ตามเวลาจริงพร้อมใช้งานจริง ข้อกำหนดเบื้องต้นเหล่านี้สำหรับเวลาแฝงเป็นศูนย์ไม่ต่างไปจากเป้าหมายสองข้อที่ IBM กำหนดไว้และอธิบายไว้ข้างต้น ข้อต่อที่แน่นของ ข้อมูล เป็นส่วนหนึ่งของโปรแกรมบูรณาการที่ไร้รอยต่อของไอบีเอ็ม และสร้างระบบการจัดส่งของ ข้อมูล ประสิทธิภาพนั้นขึ้นอยู่กับเทคโนโลยีที่มีอยู่อย่างสมบูรณ์ซึ่งทำให้กระบวนการจัดส่งง่ายขึ้น ข้อมูล. ดังนั้น สองในสามเป้าหมายของ IBM จึงมีความสำคัญต่อการบรรลุเป้าหมายที่สาม IBM กำลังพัฒนาเทคโนโลยีของตนอย่างตั้งใจเพื่อให้แน่ใจว่าเวลาแฝงเป็นศูนย์นั้นเป็นจริงสำหรับความพยายามในคลังสินค้า สรุป/สังเคราะห์ องค์กร BI ของคุณมีแผนงานสำหรับการสร้างสภาพแวดล้อมของคุณ
  ซ้ำๆ จะต้องปรับเปลี่ยนให้สอดคล้องกับความต้องการของธุรกิจของคุณทั้งในปัจจุบันและอนาคต หากไม่มีวิสัยทัศน์ทางสถาปัตยกรรมที่กว้างไกล การทำซ้ำในคลังสินค้าจะเป็นเพียงการดำเนินการตามยถากรรมของคลังสินค้ากลาง ซึ่งสร้างองค์กรขนาดใหญ่ที่ให้ข้อมูลเพียงเล็กน้อยเท่านั้น อุปสรรค์แรกสำหรับผู้นำโครงการคือการปรับการลงทุนที่จำเป็นเพื่อทำให้องค์กร BI เติบโตได้อย่างไร แม้ว่าการคำนวณ ROI จะยังคงเป็นหลักสำคัญของความสำเร็จของสินค้าคงคลัง แต่การคาดการณ์ให้แม่นยำนั้นยากขึ้น สิ่งนี้นำไปสู่วิธีการอื่นๆ ในการพิจารณาว่าคุณได้รับคุ้มค่ากับเงินที่จ่ายไปหรือไม่ ตัวอย่างเช่น Value on Investment2 (VOI) ได้รับการจัดหาเพื่อเป็นโซลูชัน เป็นหน้าที่ของสถาปนิก ข้อมูล และผู้วางแผนโครงการจงใจสร้างและให้ข้อมูลแก่สมาคมผู้ใช้ ไม่ใช่เพียงแค่ให้บริการเท่านั้น ข้อมูล. มีความแตกต่างกันอย่างมากระหว่างคนทั้งสอง ข้อมูลเป็นสิ่งที่สร้างความแตกต่างในการตัดสินใจและประสิทธิผล ค่อนข้างฉัน ข้อมูล พวกเขากำลังสร้างบล็อกสำหรับการได้รับข้อมูลนั้น

แม้ว่าจะวิพากษ์วิจารณ์แหล่งที่มาก็ตาม ข้อมูล เพื่อตอบสนองความต้องการทางธุรกิจ สภาพแวดล้อม BI ควรมีบทบาทมากขึ้นในการสร้างเนื้อหาข้อมูล เราต้องดำเนินการตามขั้นตอนเพิ่มเติมเพื่อชำระล้าง รวม แปลง หรือสร้างเนื้อหาข้อมูลที่ผู้ใช้สามารถดำเนินการได้ จากนั้นเราต้องตรวจสอบให้แน่ใจว่าการกระทำและการตัดสินใจเหล่านั้นสะท้อนให้เห็นในสภาพแวดล้อมของ BI หากสมเหตุสมผล หากเราปล่อยคลังสินค้าให้ให้บริการเฉพาะบน ข้อมูลโปรดมั่นใจได้ว่าการเชื่อมโยงผู้ใช้จะสร้างเนื้อหาข้อมูลที่จำเป็นในการดำเนินการ สิ่งนี้ทำให้มั่นใจได้ว่าชุมชนของพวกเขาจะสามารถตัดสินใจได้ดีขึ้น แต่องค์กรประสบปัญหาจากการขาดความรู้ที่พวกเขาใช้ ตัวเลข การที่สถาปนิกและผู้วางแผนโครงการริเริ่มโครงการเฉพาะในสภาพแวดล้อม BI พวกเขายังคงรับผิดชอบต่อองค์กรโดยรวม ตัวอย่างง่ายๆ ของคุณลักษณะสองด้านของการวนซ้ำของ BI มีอยู่ในแหล่งที่มา ข้อมูล. ทั้งหมด ข้อมูล ที่ได้รับสำหรับคำขอเชิงพาณิชย์เฉพาะจะต้องบรรจุในชั้นอะตอมชั้นแรก ซึ่งช่วยให้มั่นใจถึงการพัฒนาสินทรัพย์ข้อมูลขององค์กร ตลอดจนจัดการ ตอบสนองคำขอของผู้ใช้เฉพาะที่กำหนดไว้ในการทำซ้ำ

คลังข้อมูลคืออะไร?

คลังข้อมูล เป็นหัวใจของสถาปัตยกรรมระบบสารสนเทศมาตั้งแต่ปี 1990 และสนับสนุนกระบวนการข้อมูลโดยนำเสนอแพลตฟอร์มแบบบูรณาการที่แข็งแกร่งของ ข้อมูล ประวัติที่ใช้เป็นพื้นฐานสำหรับการวิเคราะห์ในภายหลัง เดอะ คลังข้อมูล พวกเขาให้ความสะดวกในการรวมเข้ากับโลกของระบบแอปพลิเคชันที่เข้ากันไม่ได้ คลังข้อมูล มีการพัฒนาจนกลายเป็นแฟชั่น คลังข้อมูล จัดระเบียบและจดจำ i ข้อมูล จำเป็นสำหรับข้อมูลและกระบวนการวิเคราะห์บนพื้นฐานของมุมมองทางโลกทางประวัติศาสตร์อันยาวนาน ทั้งหมดนี้เกี่ยวข้องกับความพยายามอย่างมากและต่อเนื่องในการก่อสร้างและบำรุงรักษา คลังข้อมูล.

แล้วก.คืออะไร คลังข้อมูล? คลังข้อมูล และ:

• ▪ หัวเรื่อง
• ▪ ระบบบูรณาการ
• ▪ การเปลี่ยนแปลงของเวลา
• ▪ ไม่ลบเลือน (ไม่ยกเลิก)

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

คำจำกัดความที่แท้จริงของ a คลังข้อมูล สมควรได้รับการอธิบายอย่างละเอียดเนื่องจากมีแรงจูงใจที่สำคัญและความหมายแฝงที่อธิบายถึงลักษณะของคลังสินค้า

ปฐมนิเทศสาขาวิชา หัวข้อ

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

โลกของการดำเนินงานได้รับการออกแบบมาสำหรับแอปพลิเคชันและฟังก์ชันต่างๆ เช่น สินเชื่อ เงินฝากออมทรัพย์ บัตรธนาคาร และทรัสต์สำหรับสถาบันการเงิน โลกของ dw ถูกจัดระเบียบตามหัวข้อหลัก เช่น ลูกค้า ผู้ขาย สินค้า และกิจกรรม การจัดตำแหน่งตามหัวข้อต่างๆ ส่งผลต่อการออกแบบและการใช้งาน ข้อมูล พบใน dw ที่สำคัญที่สุด หัวข้อหลักจะส่งผลต่อส่วนที่สำคัญที่สุดของโครงสร้างหลัก

โลกของแอปพลิเคชันได้รับอิทธิพลจากทั้งการออกแบบฐานข้อมูลและการออกแบบกระบวนการ โลกของ dw มุ่งเน้นไปที่การสร้างแบบจำลองโดยเฉพาะ ข้อมูล และในการออกแบบของ ฐานข้อมูล. การออกแบบกระบวนการ (ในรูปแบบคลาสสิก) ไม่ได้เป็นส่วนหนึ่งของสภาพแวดล้อม dw

ความแตกต่างระหว่างทางเลือกของการประยุกต์ใช้กระบวนการ/ฟังก์ชันและการเลือกหัวเรื่องยังถูกเปิดเผยเป็นความแตกต่างในเนื้อหาของ ข้อมูล ในระดับที่ละเอียด เดอะ ข้อมูล del dw ไม่รวม i ข้อมูล ซึ่งจะไม่ใช้การประมวลผล DSS ขณะใช้งาน

มุ่งเน้นการดำเนินงาน ข้อมูล มีฉัน ข้อมูล เพื่อตอบสนองความต้องการด้านการทำงาน/การประมวลผลทันที ซึ่งอาจมีหรือไม่มีการใช้งานใดๆ สำหรับนักวิเคราะห์ DSS
อีกหนึ่งวิธีสำคัญที่แอพพลิเคชั่นเชิงปฏิบัติสำหรับ ข้อมูล แตกต่างจาก ข้อมูล ของ dw อยู่ในรายงานของ ข้อมูล. ฉัน ข้อมูล ผู้ดำเนินการรักษาความสัมพันธ์อย่างต่อเนื่องระหว่างสองตารางขึ้นไปตามกฎทางธุรกิจที่ใช้งานอยู่ เดอะ ข้อมูล ของ dw span สเปกตรัมของเวลา และรายงานที่พบใน dw มีมากมาย กฎการค้าหลายฉบับ (และรายงานหลายฉบับของ ข้อมูล ) แสดงในสต็อกของ ข้อมูล ระหว่างสองตารางขึ้นไป

(สำหรับคำอธิบายโดยละเอียดเกี่ยวกับความสัมพันธ์ระหว่าง ข้อมูล ได้รับการจัดการใน DW โปรดดูที่หัวข้อเทคโนโลยีในประเด็นนั้น)
ไม่มีมุมมองอื่นใดนอกจากความแตกต่างพื้นฐานระหว่างตัวเลือกแอปพลิเคชันการทำงาน/กระบวนการและตัวเลือกหัวเรื่อง มีความแตกต่างที่สำคัญระหว่างระบบปฏิบัติการและ ข้อมูล และ DW

การบูรณาการ การบูรณาการ

สิ่งสำคัญที่สุดของสภาพแวดล้อม dw คือ i ข้อมูล ที่พบใน dw ถูกรวมเข้าด้วยกันอย่างง่ายดาย เสมอ. โดยไม่มีข้อยกเว้น สาระสำคัญของสภาพแวดล้อม dw คือ i ข้อมูล ที่มีอยู่ภายในขอบเขตของคลังสินค้ามาบูรณาการ

การบูรณาการเผยให้เห็นตัวเองในรูปแบบต่างๆ มากมาย - ในข้อตกลงที่ระบุสอดคล้องกัน, ในการวัดตัวแปรที่สอดคล้องกัน, ในโครงสร้างรหัสที่สอดคล้องกัน, ในคุณลักษณะทางกายภาพของ ข้อมูล สม่ำเสมอ เป็นต้น

ในช่วงหลายปีที่ผ่านมา ผู้ออกแบบแอพพลิเคชั่นต่างๆ ได้ทำการตัดสินใจมากมายเกี่ยวกับวิธีการพัฒนาแอพพลิเคชั่น สไตล์และการตัดสินใจออกแบบเฉพาะบุคคลของแอปพลิเคชันของนักออกแบบนั้นถูกเปิดเผยในร้อยวิธี: ความแตกต่างในการเข้ารหัส โครงสร้างหลัก ลักษณะทางกายภาพ ระเบียบการระบุตัวตน และอื่นๆ ความสามารถโดยรวมของนักออกแบบแอปพลิเคชันจำนวนมากในการสร้างแอปพลิเคชันที่ไม่สอดคล้องกันนั้นเป็นตำนาน รูปที่ 3 แสดงความแตกต่างที่สำคัญที่สุดบางประการในการออกแบบแอปพลิเคชัน

การเข้ารหัส: การเข้ารหัส:

ผู้ออกแบบแอปพลิเคชันได้เลือกการเข้ารหัสฟิลด์ – เพศ – ในหลายวิธี นักออกแบบแทนเพศด้วยตัว "m" และ "f" นักออกแบบอีกคนแทนเพศเป็น "1" และ "0" นักออกแบบอีกคนแทนเพศเป็น "x" และ "y" นักออกแบบอีกคนแสดงถึงเพศเป็น "ชาย" และ "หญิง" ไม่สำคัญว่าเพศจะเข้าสู่ DW ได้อย่างไร ตัว “M” และ “F” อาจเป็นตัวแทนที่ดีพอๆ กัน

สิ่งสำคัญคือไม่ว่าจะมาจากแหล่งใดของฟิลด์เพศ ฟิลด์นั้นจะมาถึงใน DW ในสถานะรวมที่สอดคล้องกัน ดังนั้น เมื่อฟิลด์ถูกโหลดลงใน DW จากแอปพลิเคชันที่มีการแสดงภายนอกในรูปแบบ “M” และ “F” ข้อมูล ต้องแปลงเป็นรูปแบบ DW

การวัดคุณสมบัติ: การวัด คุณลักษณะ:

ผู้ออกแบบแอปพลิเคชันได้เลือกที่จะวัดไปป์ไลน์ด้วยหลากหลายวิธีในช่วงหลายปีที่ผ่านมา นักออกแบบร้าน i ข้อมูล ของท่อเป็นเซนติเมตร ผู้ออกแบบแอปพลิเคชันอื่นจัดเก็บไฟล์ ข้อมูล ของท่อหน่วยเป็นนิ้ว ผู้ออกแบบแอปพลิเคชันอื่นจัดเก็บไฟล์ ข้อมูล ของท่อ ล้านลูกบาศก์ฟุตต่อวินาที และนักออกแบบอีกคนหนึ่งเก็บข้อมูลไปป์ไลน์ในรูปหลา ไม่ว่าจะมาจากแหล่งใดก็ตาม เมื่อข้อมูลไปป์ไลน์มาถึง DW จะต้องวัดด้วยวิธีเดียวกัน

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

ไม่ว่าอาร์กิวเมนต์การออกแบบจะเป็นเช่นไร ผลลัพธ์ก็เหมือนกัน – i ข้อมูล ต้องจัดเก็บไว้ใน DW ในลักษณะที่ไม่เหมือนใครและเป็นที่ยอมรับทั่วโลก แม้ว่าระบบปฏิบัติการพื้นฐานจะจัดเก็บ i ข้อมูล.

เมื่อนักวิเคราะห์ DSS ดูที่ DW นักวิเคราะห์ควรให้ความสำคัญกับการใช้ประโยชน์จาก ข้อมูล ซึ่งอยู่ในคลังสินค้า

มากกว่าที่จะสงสัยเกี่ยวกับความน่าเชื่อถือหรือความสอดคล้องของ ข้อมูล.

ความแปรปรวนของเวลา

ทั้งหมด ข้อมูล ใน DW นั้นมีความแม่นยำในบางช่วงเวลา คุณสมบัติพื้นฐานนี้ของ ข้อมูล ใน DW นั้นแตกต่างจาก ข้อมูล พบได้ในสภาพแวดล้อมการทำงาน เดอะ ข้อมูล ของสภาพแวดล้อมการทำงานมีความแม่นยำเท่ากับ ณ เวลาที่เข้าถึง กล่าวอีกนัยหนึ่ง ในสภาพแวดล้อมการทำงานเมื่อมีการเข้าถึงยูนิต ข้อมูลคาดว่าจะสะท้อนค่าที่แม่นยำ ณ เวลาที่เข้าถึง ทำไมฉัน ข้อมูล ใน DW มีความถูกต้องในบางช่วงเวลา (เช่น ไม่ใช่ "ตอนนี้") ข้อมูล ที่พบใน DW คือ “ความแปรปรวนของเวลา”
ความแปรปรวนของเวลา ข้อมูล โดย DW ถูกอ้างถึงในหลายวิธี
วิธีที่ง่ายที่สุดคือฉัน ข้อมูล ของตัวแทน DW ข้อมูล เป็นเวลานาน - ห้าถึงสิบปี ระยะเวลาที่แสดงสำหรับสภาพแวดล้อมการทำงานนั้นสั้นกว่าค่าปัจจุบันในปัจจุบันมากถึงหกสิบเก้าสิบ
แอปพลิเคชันที่ต้องทำงานได้ดีและต้องพร้อมใช้งานสำหรับการประมวลผลธุรกรรมจำเป็นต้องนำเงินจำนวนขั้นต่ำ ข้อมูล หากพวกเขาอนุญาตให้มีความยืดหยุ่นในระดับใดก็ได้ แอปพลิเคชันสำหรับการปฏิบัติงานจึงมีระยะเวลาสั้น เช่น หัวข้อการออกแบบแอปพลิเคชันเสียง
วิธีที่สอง 'ความแปรปรวนของเวลา' ที่ปรากฏใน DW คือในโครงสร้างหลัก โครงสร้างหลักแต่ละโครงสร้างใน DW ประกอบด้วยองค์ประกอบเวลา เช่น วัน สัปดาห์ เดือน เป็นต้น ไม่ว่าโดยปริยายหรือโดยชัดแจ้ง องค์ประกอบเวลามักจะอยู่ที่ด้านล่างของคีย์ที่ต่อกันซึ่งพบใน DW ในโอกาสเหล่านี้ องค์ประกอบเวลาจะมีอยู่โดยปริยาย เช่น กรณีที่ไฟล์ทั้งหมดถูกทำซ้ำเมื่อสิ้นเดือนหรือไตรมาส
วิธีที่ XNUMX การแสดงความแปรปรวนของเวลาคือ i ข้อมูล ของ DW ที่เพิ่งลงทะเบียนถูกต้องไม่สามารถอัพเดทได้ เดอะ ข้อมูล ของ DW นั้นเป็นสแนปช็อตชุดยาว เพื่อวัตถุประสงค์ในทางปฏิบัติทั้งหมด แน่นอนว่าหากถ่ายภาพสแน็ปช็อตไม่ถูกต้อง คุณสามารถแก้ไขสแน็ปช็อตได้ แต่สมมติว่าถ่ายภาพสแน็ปช็อตอย่างถูกต้องแล้ว ภาพเหล่านั้นจะไม่เปลี่ยนแปลงทันทีที่ถ่ายภาพ ในบาง

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

ไม่ระเหย

ลักษณะสำคัญประการที่ XNUMX ของ DW คือไม่ผันผวน
การอัปเดต การแทรก การลบ และการเปลี่ยนแปลงจะทำเป็นประจำในสภาพแวดล้อมการปฏิบัติงานโดยบันทึกทีละรายการ แต่การจัดการขั้นพื้นฐานของ ข้อมูล ที่จำเป็นใน DW นั้นง่ายกว่ามาก มีการดำเนินการเพียงสองประเภทเท่านั้นที่เกิดขึ้นใน DW – การโหลดครั้งแรกของ ข้อมูล และเข้าถึง ข้อมูล. ไม่มีการอัพเดทของ ข้อมูล (ในความหมายทั่วไปของการอัปเดต) ใน DW เป็นการดำเนินการประมวลผลตามปกติ มีผลที่ตามมาอย่างมากของความแตกต่างพื้นฐานระหว่างการประมวลผลเชิงปฏิบัติการและการประมวลผล DW ในระดับการออกแบบ ข้อควรระวังเกี่ยวกับการอัปเดตข้อขัดข้องไม่ใช่ปัจจัยใน DW เนื่องจากการอัปเดตของ ข้อมูล มันไม่ได้ดำเนินการ ซึ่งหมายความว่าในระดับทางกายภาพของการออกแบบ เสรีภาพสามารถนำมาใช้เพื่อเพิ่มประสิทธิภาพการเข้าถึง ข้อมูลโดยเฉพาะอย่างยิ่งในการจัดการกับหัวข้อของการทำให้เป็นมาตรฐานและการทำให้เป็นปกติทางกายภาพ ผลที่ตามมาอีกประการหนึ่งของความเรียบง่ายในการทำงานของ DW คือเทคโนโลยีพื้นฐานที่ใช้ในการเรียกใช้สภาพแวดล้อม DW การต้องรองรับการอัปเดตแบบบันทึกต่อบันทึกทางออนไลน์ (ซึ่งมักจะเป็นกรณีของการประมวลผลเชิงปฏิบัติการ) เทคโนโลยีจำเป็นต้องมีรากฐานที่ซับซ้อนมากภายใต้ความเรียบง่ายที่ชัดเจน
เทคโนโลยีที่รองรับการสำรองและกู้คืน ธุรกรรม และความสมบูรณ์ของไฟล์ ข้อมูล และการตรวจจับการหยุดชะงักและการแก้ไขนั้นค่อนข้างซับซ้อนและไม่จำเป็นสำหรับการประมวลผล DW ลักษณะของ DW การวางแนวการออกแบบ การรวม ข้อมูล ภายใน DW ความแปรปรวนของเวลาและความสะดวกในการจัดการ ข้อมูลทั้งหมดนี้นำไปสู่สภาพแวดล้อมที่แตกต่างจากสภาพแวดล้อมการทำงานแบบคลาสสิกเป็นอย่างมาก แหล่งที่มาเกือบทั้งหมด ข้อมูล ของ DW คือสภาพแวดล้อมการดำเนินงาน เป็นเรื่องน่าดึงดูดใจที่จะคิดว่ามีความซ้ำซ้อนมากมาย ข้อมูล ระหว่างสองสภาพแวดล้อม
แน่นอนว่าความประทับใจแรกที่หลายคนมีคือความซ้ำซากจำเจ ข้อมูล ระหว่างสภาพแวดล้อมการทำงานและสภาพแวดล้อมของ

นามสกุล DW การตีความดังกล่าวเป็นเพียงผิวเผินและแสดงให้เห็นถึงการขาดความเข้าใจในสิ่งที่เกิดขึ้นใน DW
แน่นอนว่ามีความซ้ำซ้อนขั้นต่ำ ข้อมูล ระหว่างสภาพแวดล้อมการทำงานกับ i ข้อมูล ของ DW พิจารณาสิ่งต่อไปนี้: I ข้อมูล พวกเขาจะถูกกรอง Dato ที่คุณเปลี่ยนจากสภาพแวดล้อมการทำงานเป็นสภาพแวดล้อม DW มากมาย ข้อมูล พวกเขาไม่เคยออกไปนอกสภาพแวดล้อมการทำงาน เท่านั้นที่ฉัน ข้อมูล ซึ่งจำเป็นสำหรับการประมวลผล DSS ค้นหาทิศทางในสภาพแวดล้อม

▪ ขอบฟ้าเวลาของ ข้อมูล มันแตกต่างกันมากจากสภาพแวดล้อมหนึ่งไปยังอีกสภาพแวดล้อมหนึ่ง เดอะ ข้อมูล ในสภาพแวดล้อมการทำงานมีความสดใหม่มาก เดอะ ข้อมูล ใน DW พวกเขาเก่ากว่ามาก จากมุมมองของไทม์ฮอไรซัน มีการทับซ้อนกันน้อยมากระหว่างสภาพแวดล้อมการทำงานและ DW

▪ DW ประกอบด้วย ข้อมูล บทสรุปที่ไม่เคยอยู่ในสิ่งแวดล้อม

▪ I ข้อมูล ได้รับการเปลี่ยนแปลงขั้นพื้นฐานเมื่อเปลี่ยนไปรูปที่ 3 แสดงให้เห็นว่าส่วนใหญ่ ข้อมูล จะถูกแก้ไขอย่างมีนัยสำคัญหากมีการเลือกและย้ายไปยัง DW กล่าวอีกนัยหนึ่งส่วนใหญ่ของ ข้อมูล มันมีการเปลี่ยนแปลงทั้งทางร่างกายและจิตใจเมื่อมันถูกย้ายเข้าสู่ DW จากมุมมองของการผสมผสานนั้นไม่เหมือนกัน ข้อมูล อยู่ในสภาพแวดล้อมการทำงาน ด้วยปัจจัยเหล่านี้ ความซ้ำซ้อนของ ข้อมูล ระหว่างสองสภาพแวดล้อมเป็นเหตุการณ์ที่เกิดขึ้นไม่บ่อย ซึ่งนำไปสู่ความซ้ำซ้อนน้อยกว่า 1% ระหว่างสภาพแวดล้อมทั้งสอง โครงสร้างของคลังสินค้า DW มีโครงสร้างที่แตกต่างกัน มีบทสรุปและรายละเอียดหลายระดับที่แบ่งเขต DW
องค์ประกอบต่างๆ ของ DW คือ:

• เมตาดาต้า
• ให้ รายละเอียดปัจจุบัน
• ให้ รายละเอียดเก่า
• ให้ สรุปเล็กน้อย
• ให้ สรุปอย่างมาก

ความกังวลหลักสำหรับฉัน ข้อมูล รายละเอียดปัจจุบัน เป็นข้อกังวลหลักเนื่องจาก:

• I ข้อมูล รายละเอียดปัจจุบันสะท้อนให้เห็นถึงเหตุการณ์ล่าสุดซึ่งเป็นที่สนใจเสมอและ
• i ข้อมูล ข้อมูลรายละเอียดปัจจุบันมีจำนวนมากเนื่องจากถูกเก็บไว้ที่ระดับความละเอียดต่ำสุดและ
• i ข้อมูล รายละเอียดปัจจุบันมักถูกเก็บไว้ในหน่วยความจำดิสก์ซึ่งเข้าถึงได้รวดเร็ว แต่มีราคาแพงและซับซ้อนจาก I ข้อมูล รายละเอียดเก่ากว่า ข้อมูล ซึ่งเก็บไว้ในหน่วยความจำบางส่วนของ มวล. มีการเข้าถึงเป็นระยะ ๆ และจัดเก็บในระดับรายละเอียดที่เข้ากันได้กับ ข้อมูล รายละเอียดปัจจุบัน แม้ว่าจะไม่บังคับให้จัดเก็บบนสื่อบันทึกข้อมูลสำรอง เนื่องจากมีปริมาณมาก ข้อมูล รวมเข้ากับการเข้าถึงเป็นระยะ ๆ ของ ข้อมูลสื่อเก็บข้อมูลสำหรับ ข้อมูล รายละเอียดที่เก่ากว่ามักจะไม่เก็บไว้ในดิสก์ เดอะ ข้อมูล สรุปง่ายๆก็คือ ข้อมูล ซึ่งกลั่นจากรายละเอียดระดับต่ำที่พบจนถึงระดับรายละเอียดปัจจุบัน DW ระดับนี้จะถูกเก็บไว้ในหน่วยความจำดิสก์เกือบตลอดเวลา ปัญหาของงานออกแบบที่นำเสนอต่อสถาปนิกของ ข้อมูล ในการสร้าง DW ระดับนี้คือ:

• การสรุปข้างต้นทำในหน่วยเวลาใด
• เนื้อหาแอตทริบิวต์เล็กน้อยจะสรุปเนื้อหาของ ข้อมูล ระดับต่อไปของ ข้อมูล ที่พบใน DW คือของ ข้อมูล สรุปอย่างมาก เดอะ ข้อมูล สรุปได้อย่างกะทัดรัดและเข้าถึงได้ง่าย เดอะ ข้อมูล บางครั้งการสรุปอย่างสูงมักพบในสภาพแวดล้อม DW และกรณีอื่นๆ ข้อมูล สิ่งที่เป็นนามธรรมสูงจะพบได้นอกกำแพงของเทคโนโลยีที่โฮสต์ DW (ไม่ว่าในกรณีใดฉัน ข้อมูล สรุปอย่างสูงเป็นส่วนหนึ่งของ DW โดยไม่คำนึงถึงที่ i ข้อมูล เป็นที่อยู่อาศัย) องค์ประกอบสุดท้ายของ DW คือองค์ประกอบข้อมูลเมตา ในหลาย ๆ ด้านข้อมูลเมตาอยู่ในมิติที่แตกต่างจากที่อื่น ข้อมูล ของ DW เนื่องจากข้อมูลเมตาไม่มีข้อมูลใดๆ Dato นำมาจากสภาพแวดล้อมการทำงานโดยตรง ข้อมูลเมตามีบทบาทพิเศษและสำคัญมากใน DW ข้อมูลเมตาใช้เป็น:

• ไดเร็กทอรีเพื่อช่วยนักวิเคราะห์ DSS ค้นหาเนื้อหาของ DW
• คู่มือการทำแผนที่ ข้อมูล ว่าฉัน ข้อมูล ได้รับการเปลี่ยนจากสภาพแวดล้อมการทำงานเป็นสภาพแวดล้อม DW
• คำแนะนำเกี่ยวกับอัลกอริทึมที่ใช้สำหรับการสรุประหว่าง i ข้อมูล รายละเอียดปัจจุบัน ei ข้อมูล สรุปเล็กน้อย i ข้อมูล โดยสรุปแล้ว Metadata มีบทบาทที่ใหญ่กว่ามากในสภาพแวดล้อม DW มากกว่าที่เคยมีมาในสภาพแวดล้อมการปฏิบัติงาน สื่อเก็บรายละเอียดแบบเก่า สามารถใช้เทปแม่เหล็กเพื่อจัดเก็บของแบบนั้นได้ ข้อมูล. มีสื่อเก็บข้อมูลหลากหลายประเภทที่ควรพิจารณาสำหรับการจัดเก็บสื่อเก่า ข้อมูล ของรายละเอียด ขึ้นอยู่กับปริมาณของ ข้อมูลความถี่ในการเข้าถึง ต้นทุนของเครื่องมือ และประเภทของการเข้าถึง เป็นไปได้ทั้งหมดว่าเครื่องมืออื่นๆ จะต้องการรายละเอียดระดับเก่าใน DW การไหลของข้อมูล มีการไหลตามปกติและคาดเดาได้ของ ข้อมูล ภายใน DW
  I ข้อมูล พวกเขาเข้าสู่ DW จากสภาพแวดล้อมการทำงาน (หมายเหตุ: มีข้อยกเว้นที่น่าสนใจบางประการสำหรับกฎนี้ อย่างไรก็ตาม เกือบทั้งหมด ข้อมูล ป้อน DW จากสภาพแวดล้อมการทำงาน) ตัวเลข นั่นฉัน ข้อมูล พวกเขาเข้าสู่ DW จากสภาพแวดล้อมการทำงาน มันจะถูกแปลงตามที่อธิบายไว้ข้างต้น ให้คุณป้อน DW, i ข้อมูล ป้อนรายละเอียดระดับปัจจุบันตามที่แสดง มันอยู่ที่นั่นและใช้จนกระทั่งหนึ่งในสามเหตุการณ์เกิดขึ้น:

• บริสุทธิ์
• สรุป และ/หรือ ▪เป็นกระบวนการล้าสมัยภายใน DW ย้าย i ข้อมูล รายละเอียดปัจจุบัน ข้อมูล รายละเอียดเก่าตามอายุ ข้อมูล. กระบวนการ

การสรุปใช้รายละเอียดของ ข้อมูล เพื่อคำนวณ ข้อมูล ระดับสรุปเล็กน้อยและสรุปมากของ ข้อมูล. มีข้อยกเว้นบางประการสำหรับโฟลว์ที่แสดง (จะกล่าวถึงในภายหลัง) อย่างไรก็ตาม สำหรับคนส่วนใหญ่แล้ว ข้อมูล พบได้ใน DW ซึ่งเป็นกระแสของ ข้อมูล มันเป็นตัวแทน

การใช้คลังข้อมูล

ไม่น่าแปลกใจที่ระดับต่างๆของ ข้อมูล ภายใน DW พวกเขาไม่ได้รับการใช้งานในระดับที่แตกต่างกัน ตามกฎแล้วยิ่งระดับการสรุปสูงเท่าไรก็ยิ่งมีมากขึ้นเท่านั้น ข้อมูล พวกเขาใช้
การใช้งานหลายอย่างเกิดขึ้นใน ข้อมูล สรุปในขณะที่เก่า ข้อมูล รายละเอียดแทบไม่เคยใช้เลย มีเหตุผลที่ดีที่จะเปลี่ยนองค์กรไปสู่กระบวนทัศน์การใช้ทรัพยากร สรุปเพิ่มเติม i ข้อมูลก็ยิ่งไปถึงเร็วและมีประสิทธิภาพมากขึ้นเท่านั้น ข้อมูล. ถ้าก ร้านขายของ พบว่ามันทำการประมวลผลระดับรายละเอียดของ DW เป็นจำนวนมาก จากนั้นจึงใช้ทรัพยากรเครื่องจำนวนมากตามไปด้วย เพื่อประโยชน์สูงสุดสำหรับทุกคนในการดำเนินการสรุประดับสูงเช่นนี้โดยเร็วที่สุด

สำหรับร้านค้าจำนวนมาก นักวิเคราะห์ DSS ในสภาพแวดล้อมก่อน DW ได้ใช้ ข้อมูล ในระดับของรายละเอียด หลายประการมาถึงที่ ข้อมูล รายละเอียดดูเหมือนผ้าห่มรักษาความปลอดภัย แม้ว่าจะมีการสรุประดับอื่นๆ ก็ตาม หนึ่งในกิจกรรมสถาปนิกของ ข้อมูล คือการปลดผู้ใช้ DSS จากการใช้งานอย่างต่อเนื่อง ข้อมูล ในระดับต่ำสุดของรายละเอียด มีแรงจูงใจสองประการสำหรับสถาปนิก ข้อมูล:

• การติดตั้งระบบปฏิเสธการชำระเงิน ซึ่งผู้ใช้ปลายทางเป็นผู้ชำระค่าทรัพยากรที่ใช้ไป e
• ซึ่งบ่งชี้ว่าสามารถรับเวลาตอบสนองที่ดีมากได้เมื่อมีพฤติกรรมด้วย i ข้อมูล อยู่ในระดับสูงของการสรุปในขณะที่เวลาตอบสนองที่ไม่ดีมาจากพฤติกรรมของ ข้อมูล ในระดับต่ำของ การพิจารณาอื่น ๆ มีข้อควรพิจารณาเกี่ยวกับการก่อสร้างและการจัดการ DW อื่นๆ อีกสองสามข้อ
  ข้อพิจารณาประการแรกคือเรื่องของดัชนี เดอะ ข้อมูล ในการสรุปในระดับที่สูงขึ้น พวกเขาสามารถจัดทำดัชนีได้อย่างอิสระ ในขณะที่ i ข้อมูล

ที่ระดับรายละเอียดที่ต่ำกว่า พวกมันมีขนาดใหญ่มากจนสามารถจัดทำดัชนีได้ไม่มาก จากโทเค็นเดียวกัน i ข้อมูล ที่รายละเอียดระดับสูงสามารถปรับโครงสร้างใหม่ได้ค่อนข้างง่าย ในขณะที่ปริมาณของ ข้อมูล ที่ระดับล่างนั้นมีขนาดใหญ่มากจนฉัน ข้อมูล ไม่สามารถตกแต่งใหม่ได้ง่ายๆ ดังนั้นรูปแบบของ ข้อมูล และงานอย่างเป็นทางการที่ทำโดยการออกแบบเป็นการวางรากฐานสำหรับ DW ที่นำไปใช้กับรายละเอียดระดับปัจจุบันเกือบทั้งหมด กล่าวอีกนัยหนึ่งกิจกรรมการสร้างแบบจำลองของ ข้อมูล ใช้ไม่ได้กับระดับการสรุปในเกือบทุกกรณี การพิจารณาโครงสร้างอีกประการหนึ่งคือการแบ่งย่อยของ ข้อมูล โดย DW.

พาร์ติชั่นสามารถทำได้สองระดับ - ที่ระดับ ฐานข้อมูล และในระดับแอปพลิเคชัน ในการแบ่งระดับ ฐานข้อมูล, ฐานข้อมูล ได้รับแจ้งเกี่ยวกับหน่วยงานและควบคุมพวกเขาตามนั้น ในกรณีของแผนกระดับแอปพลิเคชัน เฉพาะโปรแกรมเมอร์เท่านั้นที่ทราบถึงแผนกต่างๆ และความรับผิดชอบในการดูแลระบบจะตกเป็นของเขา

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

ความผิดปกติ

ในขณะที่ส่วนประกอบของ คลังข้อมูล ทำงานตามที่อธิบายไว้เกือบทั้งหมด ข้อมูลมีข้อยกเว้นที่เป็นประโยชน์บางประการที่ต้องกล่าวถึง ข้อยกเว้นคือของ ข้อมูล บทสรุปสาธารณะ (ข้อมูลสรุปสาธารณะ) เหล่านี้คือ ข้อมูล สรุปที่ได้คำนวณออกมาจาก คลังข้อมูล แต่พวกมันถูกใช้โดยสังคม เดอะ ข้อมูล บทสรุปสาธารณะจะถูกจัดเก็บและจัดการใน คลังข้อมูลแม้ว่าตามที่กล่าวไว้ข้างต้นพวกเขาจะคิดออก นักบัญชีทำงานเพื่อผลิตรายไตรมาสดังกล่าว ข้อมูล เช่น รายได้ ค่าใช้จ่ายรายไตรมาส กำไรรายไตรมาส และอื่นๆ งานที่ทำโดยนักบัญชีเป็นสิ่งภายนอก คลังข้อมูล. อย่างไรก็ตามฉัน ข้อมูล ถูกใช้ “ภายใน” ภายในบริษัท – จาก การตลาด, การขาย ฯลฯ ความผิดปกติอีกประการหนึ่งซึ่งจะไม่กล่าวถึงก็คือ ข้อมูล เอสเทอนี

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

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

สรุป

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

• รายละเอียดเก่า
• รายละเอียดปัจจุบัน
• ให้ สรุปเล็กน้อย
• ให้ ข้อมูลเมตาที่สรุปอย่างสูงก็เป็นส่วนสำคัญของ คลังข้อมูล. เชิงนามธรรม แนวคิดของการจัดเก็บของ ข้อมูล ได้รับความสนใจอย่างมากและกลายเป็นกระแสของยุค 90 เมื่อไม่นานมานี้ ทั้งนี้ เนื่องมาจากความสามารถของ คลังข้อมูล เพื่อก้าวข้ามข้อจำกัดของระบบสนับสนุนการจัดการ เช่น ระบบสนับสนุนการตัดสินใจ (DSS) และระบบสารสนเทศสำหรับผู้บริหาร (EIS) แม้ว่าแนวคิดของ คลังข้อมูล ดูมีแนวโน้มดี ใช้ i คลังข้อมูล อาจเป็นปัญหาได้เนื่องจากกระบวนการคลังสินค้าขนาดใหญ่ แม้จะมีความซับซ้อนของโครงการคลังสินค้าของ ข้อมูลซัพพลายเออร์และที่ปรึกษาจำนวนมากที่สต็อก ข้อมูล ให้เหตุผลว่าการจัดเก็บของ ข้อมูล ปัจจุบันไม่มีปัญหา อย่างไรก็ตาม ในช่วงเริ่มต้นของโครงการวิจัยนี้ แทบจะไม่มีการวิจัยที่เป็นอิสระ เข้มงวด และเป็นระบบเลย ดังนั้นจึงเป็นเรื่องยากที่จะพูดว่า เกิดอะไรขึ้นจริงในอุตสาหกรรมเมื่อสร้างขึ้น คลังข้อมูล. การศึกษานี้สำรวจแนวปฏิบัติด้านคลังสินค้าของ ข้อมูล ผู้ร่วมสมัยซึ่งมีจุดมุ่งหมายเพื่อพัฒนาความเข้าใจยิ่งขึ้นเกี่ยวกับการปฏิบัติของออสเตรเลีย การทบทวนวรรณกรรมเป็นบริบทและรากฐานสำหรับการศึกษาเชิงประจักษ์ มีผลการวิจัยจำนวนหนึ่ง ประการแรก การศึกษานี้เปิดเผยกิจกรรมที่เกิดขึ้นในระหว่างการพัฒนาของ คลังข้อมูล. ในหลายพื้นที่ i ข้อมูล รวบรวมยืนยันการปฏิบัติรายงานในวรรณคดี ประการที่สอง เรื่องและปัญหาที่อาจส่งผลกระทบต่อการพัฒนาของ คลังข้อมูล ถูกระบุโดยการศึกษานี้ ในที่สุด ผลประโยชน์ที่ได้รับจากองค์กรของออสเตรเลียที่เกี่ยวข้องกับการใช้ คลังข้อมูล ได้รับการเปิดเผย

บทที่ 1

บริบทการค้นหา

แนวคิดของคลังข้อมูลได้รับการเปิดเผยอย่างกว้างขวางและกลายเป็นกระแสที่เกิดขึ้นในทศวรรษ 90 (McFadden 1996, TDWI 1996, Shah and Milstein 1997, Shanks et al. 1997, Eckerson 1998, Adelman and Oates 2000) ดังจะเห็นได้จากจำนวนบทความเกี่ยวกับคลังข้อมูลที่เพิ่มขึ้นในสิ่งพิมพ์ทางการค้า (Little and Gibson 1999) หลายบทความ (เช่น Fisher 1995, Hackathorn 1995, Morris 1995a, Bramblett and King 1996, Graham et al. 1996, Sakaguchi and Frolick 1996, Alvarez 1997, Brousell 1997, Clarke 1997, McCarthy 1997, O' Donnell 1997, Edwards 1998, TDWI 1999) ได้รายงานถึงประโยชน์ที่สำคัญต่อองค์กรที่ดำเนินการ คลังข้อมูล. พวกเขาสนับสนุนทฤษฎีของตนด้วยหลักฐานโดยสังเขปของการดำเนินการที่ประสบความสำเร็จ ตัวเลขผลตอบแทนจากการลงทุน (ROI) ที่สูง และยังให้แนวทางหรือระเบียบวิธีในการพัฒนา คลังข้อมูล

(Shanks et al. 1997, Seddon and Benjamin 1998, Little and Gibson 1999) ในกรณีที่รุนแรง เกรแฮมและคณะ (1996) รายงานผลตอบแทนเฉลี่ยจากการลงทุนสามปีที่ 401%

อย่างไรก็ตาม วรรณกรรมปัจจุบันส่วนใหญ่มองข้ามความซับซ้อนที่เกี่ยวข้องกับการดำเนินโครงการดังกล่าว โครงการของ คลังข้อมูล โดยปกติแล้วจะซับซ้อนและมีขนาดใหญ่ ดังนั้นจึงมีความเป็นไปได้สูงที่จะล้มเหลวหากไม่ได้รับการควบคุมอย่างระมัดระวัง (Shah and Milstein 1997, Eckerson 1997, Foley 1997b, Zimmer 1997, Bort 1998, Gibbs and Clymer 1998, Rao 1998) พวกเขาต้องการทั้งทรัพยากรบุคคลและการเงิน เวลา และความพยายามจำนวนมหาศาลในการสร้างสิ่งเหล่านี้ (Hill 1998, Crofts 1998) เวลาและเครื่องมือทางการเงินโดยทั่วไปคือประมาณสองปีและสองถึงสามล้านดอลลาร์ตามลำดับ (Braly 1995, Foley 1997b, Bort 1998, Humphries et al. 1999) เวลาและเครื่องมือทางการเงินนี้จำเป็นสำหรับการควบคุมและรวบรวมแง่มุมต่างๆ ของคลังข้อมูล (Cafasso 1995, Hill 1998) นอกเหนือจากการพิจารณาฮาร์ดแวร์และซอฟต์แวร์แล้ว ฟังก์ชันอื่นๆ ซึ่งแตกต่างจากการแยกส่วน ข้อมูล ถึงขั้นตอนการโหลดของ ข้อมูล, ความจุของหน่วยความจำสำหรับจัดการการอัปเดตและเมตา ข้อมูล สำหรับการฝึกอบรมผู้ใช้ต้องได้รับการพิจารณา

ในเวลาที่โครงการวิจัยนี้เริ่มต้นขึ้น มีงานวิจัยทางวิชาการน้อยมากที่ดำเนินการในด้านคลังข้อมูล โดยเฉพาะในออสเตรเลีย เห็นได้ชัดจากความขาดแคลนของบทความที่เผยแพร่บนคลังข้อมูลโดยวารสารหรืองานเขียนทางวิชาการอื่น ๆ ในเวลานั้น งานเขียนเชิงวิชาการที่มีอยู่มากมายบรรยายถึงประสบการณ์ของสหรัฐฯ การขาดการวิจัยทางวิชาการในด้านคลังข้อมูลทำให้เกิดความต้องการการวิจัยที่เข้มงวดและการศึกษาเชิงประจักษ์ (McFadden 1996, Shanks et al. 1997, Little and Gibson 1999) โดยเฉพาะการศึกษาวิจัยเกี่ยวกับกระบวนการดำเนินงานของ คลังข้อมูล จำเป็นต้องทำเพื่อขยายความรู้ทั่วไปเกี่ยวกับการดำเนินการของ คลังข้อมูล และจะทำหน้าที่เป็นพื้นฐานสำหรับการศึกษาวิจัยในอนาคต (Shanks et al. 1997, Little and Gibson 1999)

ดังนั้น จุดประสงค์ของการศึกษานี้คือการตรวจสอบสิ่งที่เกิดขึ้นจริงเมื่อองค์กรดำเนินการและใช้ i คลังข้อมูล ในออสเตรเลีย โดยเฉพาะอย่างยิ่ง การศึกษานี้จะเกี่ยวข้องกับการวิเคราะห์กระบวนการทั้งหมดของการพัฒนา คลังข้อมูลโดยเริ่มจากการริเริ่มและการออกแบบผ่านการออกแบบและการนำไปใช้ และการใช้งานที่ตามมาภายในองค์กรของออสเตรเลีย นอกจากนี้ การศึกษายังจะนำไปสู่การปฏิบัติในปัจจุบันโดยการระบุพื้นที่ที่สามารถปรับปรุงการปฏิบัติต่อไป และสามารถลดหรือหลีกเลี่ยงความไร้ประสิทธิภาพและความเสี่ยงได้ นอกจากนี้ยังจะใช้เป็นพื้นฐานสำหรับการศึกษาอื่น ๆ คลังข้อมูล ในออสเตรเลียและจะเติมเต็มช่องว่างที่มีอยู่ในวรรณคดี

คำถามการวิจัย

การวิจัยนี้มีวัตถุประสงค์เพื่อศึกษากิจกรรมที่เกี่ยวข้องกับการดำเนินงานของ คลังข้อมูล และการใช้งานโดยองค์กรของออสเตรเลีย โดยเฉพาะอย่างยิ่งมีการศึกษาองค์ประกอบเกี่ยวกับการวางแผนโครงการ การพัฒนา การดำเนินงาน การใช้งาน และความเสี่ยงที่เกี่ยวข้อง ดังนั้นคำถามของการวิจัยนี้คือ:

“แนวทางปฏิบัติในปัจจุบันของ คลังข้อมูล ที่ออสเตรเลีย?”

เพื่อให้ตอบคำถามนี้ได้อย่างมีประสิทธิภาพ จำเป็นต้องมีคำถามการวิจัยย่อยจำนวนหนึ่ง โดยเฉพาะอย่างยิ่ง มีการระบุคำถามย่อยสามข้อจากวรรณกรรม ซึ่งนำเสนอในบทที่ 2 เพื่อเป็นแนวทางในโครงการวิจัยนี้: คลังข้อมูล โดยองค์กรของออสเตรเลีย? ปัญหาที่พบคืออะไร?

ประโยชน์ที่ได้รับคืออะไร?
ในการตอบคำถามเหล่านี้ มีการใช้การออกแบบการวิจัยเชิงสำรวจโดยใช้แบบสำรวจ จากการศึกษาเชิงสำรวจ คำตอบของคำถามข้างต้นยังไม่สมบูรณ์ (Shanks et al. 1993, Denscombe 1998) ในกรณีนี้ จำเป็นต้องมีการวิเคราะห์สามเหลี่ยมเพื่อปรับปรุงคำตอบสำหรับคำถามเหล่านี้ อย่างไรก็ตาม การสืบสวนจะเป็นรากฐานที่มั่นคงสำหรับงานตรวจสอบคำถามเหล่านี้ในอนาคต การอภิปรายโดยละเอียดเกี่ยวกับเหตุผลและการออกแบบวิธีการวิจัยมีการนำเสนอในบทที่ 3

โครงสร้างโครงการวิจัย

โครงการวิจัยนี้แบ่งออกเป็นสองส่วน ได้แก่ การศึกษาบริบทของแนวคิดคลังข้อมูลและการวิจัยเชิงประจักษ์ (ดูรูปที่ 1.1) ซึ่งแต่ละส่วนจะกล่าวถึงด้านล่าง

ส่วนที่ XNUMX: การศึกษาตามบริบท

งานวิจัยส่วนแรกประกอบด้วยการทบทวนวรรณกรรมปัจจุบันเกี่ยวกับคลังข้อมูลประเภทต่างๆ ได้แก่ ระบบสนับสนุนการตัดสินใจ (DSS) ระบบสารสนเทศสำหรับผู้บริหาร (EIS) กรณีศึกษาของ คลังข้อมูล และแนวคิดของ คลังข้อมูล. นอกจากนี้ ผลของฟอรั่มบน คลังข้อมูล และกลุ่มการประชุมผู้เชี่ยวชาญและผู้ปฏิบัติงานที่นำโดยกลุ่มวิจัย Monash DSS มีส่วนสนับสนุนในขั้นตอนนี้ของการศึกษาซึ่งมีวัตถุประสงค์เพื่อให้ได้ข้อมูลเชิงลึกเกี่ยวกับการปฏิบัติของ คลังข้อมูล และเพื่อระบุความเสี่ยงที่เกี่ยวข้องกับการรับเลี้ยงบุตรบุญธรรม ในช่วงเวลาของการศึกษาบริบทนี้ ความเข้าใจในพื้นที่ปัญหาได้ถูกสร้างขึ้นเพื่อเป็นฐานความรู้สำหรับการตรวจสอบเชิงประจักษ์ในภายหลัง อย่างไรก็ตาม นี่เป็นกระบวนการต่อเนื่องในขณะที่มีการศึกษาวิจัย

ตอนที่ II: การวิจัยเชิงประจักษ์

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

ผลการวิเคราะห์ของ ข้อมูล สร้างภาพรวมของแนวทางปฏิบัติด้านคลังข้อมูลในออสเตรเลีย

ภาพรวมของคลังข้อมูล

แนวคิดของคลังข้อมูลได้รับการพัฒนาด้วยการปรับปรุงเทคโนโลยีคอมพิวเตอร์
มีจุดมุ่งหมายเพื่อเอาชนะปัญหาที่พบโดยกลุ่มสนับสนุนแอปพลิเคชัน เช่น ระบบสนับสนุนการตัดสินใจ (DSS) และระบบสารสนเทศสำหรับผู้บริหาร (EIS)

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

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

การใช้คำจำกัดความนี้ Inmon ชี้ให้เห็นว่า i ข้อมูล อาศัยอยู่ใน คลังข้อมูล จะต้องมีคุณสมบัติ 4 ประการดังต่อไปนี้

• ▪ เรื่องที่มุ่งเน้น
• ▪ แบบบูรณาการ
• ▪ ไม่ลบเลือน
• ▪ ผันแปรไปตามกาลเวลา โดย Inmon เชิงหัวเรื่องหมายความว่า i ข้อมูล ใน คลังข้อมูล ในพื้นที่องค์กรที่ใหญ่ที่สุดที่เคยมีมา

กำหนดไว้ในแบบจำลอง ข้อมูล. ตัวอย่างเช่นทั้งหมด ข้อมูล เกี่ยวกับ ลูกค้า บรรจุอยู่ในสาขาวิชา ลูกค้า. ในทำนองเดียวกันทั้งหมด ข้อมูล ที่เกี่ยวข้องกับผลิตภัณฑ์มีอยู่ในหัวข้อผลิตภัณฑ์

โดยอินทิเกรตอินมอนหมายความว่าผม ข้อมูล จากแพลตฟอร์ม ระบบ และสถานที่ต่าง ๆ มารวมกันและจัดเก็บไว้ในที่เดียว ดังนั้น ข้อมูล ที่คล้ายกันจะต้องแปลงเป็นรูปแบบที่สอดคล้องกันเพื่อให้สามารถเพิ่มและเปรียบเทียบได้ง่าย
ตัวอย่างเช่น เพศชายและเพศหญิงจะแสดงด้วยตัวอักษร M และ F ในระบบหนึ่ง และอีกระบบหนึ่งแทนด้วย 1 และ 0 ในการผสานรวมอย่างถูกต้อง ต้องแปลงรูปแบบหนึ่งหรือทั้งสองรูปแบบเพื่อให้ทั้งสองรูปแบบเท่ากัน ในกรณีนี้ เราสามารถเปลี่ยน M เป็น 1 และ F เป็น 0 หรือในทางกลับกัน เชิงหัวเรื่องและเชิงบูรณาการระบุว่า คลังข้อมูล ได้รับการออกแบบมาเพื่อให้วิสัยทัศน์การทำงานและแนวขวางของ ข้อมูล โดยบริษัท.

โดยที่ไม่ลบเลือนเขาหมายความว่าฉัน ข้อมูล ใน คลังข้อมูล ยังคงสอดคล้องและอัปเดตของ ข้อมูล ไม่จำเป็น แทน การเปลี่ยนแปลงใด ๆ ใน ข้อมูล ต้นฉบับถูกเพิ่มเข้าไป ฐานข้อมูล เดล คลังข้อมูล. ซึ่งหมายความว่านักประวัติศาสตร์ของ ข้อมูล บรรจุอยู่ใน คลังข้อมูล.

สำหรับตัวแปรที่มีเวลา Inmon ระบุว่า i ข้อมูล ใน คลังข้อมูล มีตัวบ่งชี้จังหวะเสมอ ei ข้อมูล โดยปกติพวกเขาจะข้ามขอบฟ้าเวลาที่แน่นอน ตัวอย่างเช่น ก
คลังข้อมูล สามารถมีคุณค่าทางประวัติศาสตร์ 5 ปีของ ลูกค้า ตั้งแต่ปี 1993 ถึง 1997 ความพร้อมใช้งานของประวัติศาสตร์และอนุกรมเวลาของ ข้อมูล ช่วยให้คุณวิเคราะห์แนวโน้ม

Un คลังข้อมูล เขาสามารถรวบรวมของเขาเอง ข้อมูล จากระบบ OLTP จากจุดกำเนิด ข้อมูล ภายนอกองค์กรและ/หรือโดยโครงการระบบดักพิเศษอื่นๆ ข้อมูล.
I ข้อมูล สารสกัดสามารถผ่านกระบวนการทำความสะอาดได้ ในกรณีนี้ i ข้อมูล ถูกแปลงและรวมเข้าด้วยกันก่อนที่จะถูกเก็บไว้ใน ฐานข้อมูล เดล คลังข้อมูล. แล้วฉัน ข้อมูล

พักอาศัยอยู่ภายใน ฐานข้อมูล เดล คลังข้อมูล มีให้สำหรับการเข้าสู่ระบบของผู้ใช้ปลายทางและเครื่องมือการกู้คืน การใช้เครื่องมือเหล่านี้ทำให้ผู้ใช้สามารถเข้าถึงมุมมองแบบบูรณาการขององค์กรของ ข้อมูล.

I ข้อมูล พักอาศัยอยู่ภายใน ฐานข้อมูล เดล คลังข้อมูล จัดเก็บไว้ทั้งในรูปแบบรายละเอียดและสรุป
ระดับของการสรุปอาจขึ้นอยู่กับลักษณะของ ข้อมูล. ฉัน ข้อมูล รายละเอียดอาจประกอบด้วย ข้อมูล ปัจจุบันและ ข้อมูล นักประวัติศาสตร์
I ข้อมูล จริงไม่รวมอยู่ใน คลังข้อมูล จนกระทั่งฉัน ข้อมูล ใน คลังข้อมูล มีการปรับปรุงใหม่
นอกจากการจัดเก็บแล้ว ข้อมูล ตัวเอง ก คลังข้อมูล มันยังสามารถเก็บของประเภทต่างๆ Dato เรียกว่า METADATA อธิบาย i ข้อมูล อยู่ในพระองค์ ฐานข้อมูล.
ข้อมูลเมตามีสองประเภท: ข้อมูลเมตาการพัฒนาและข้อมูลเมตาการวิเคราะห์
ข้อมูลเมตาการพัฒนาใช้เพื่อจัดการและทำให้กระบวนการแยกข้อมูล ล้างข้อมูล ทำแผนที่ และอัปโหลดเป็นไปโดยอัตโนมัติ ข้อมูล ใน คลังข้อมูล.
ข้อมูลที่มีอยู่ในข้อมูลเมตาของการพัฒนาสามารถประกอบด้วยรายละเอียดของระบบปฏิบัติการ รายละเอียดขององค์ประกอบที่จะดึงข้อมูล แบบจำลอง ข้อมูล เดล คลังข้อมูล และกฎทางธุรกิจสำหรับการแปลงข้อมูล ข้อมูล.

ข้อมูลเมตาประเภทที่สอง ที่เรียกว่าข้อมูลเมตาการวิเคราะห์ช่วยให้ผู้ใช้สามารถสำรวจเนื้อหาของ คลังข้อมูล เพื่อค้นหา ข้อมูล ที่มีอยู่และความหมายที่ชัดเจนในเงื่อนไขที่ไม่ใช่ทางเทคนิค

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

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

น่าเสียดายที่เครื่องมือที่มีอยู่จำนวนมากมีข้อมูลเมตาของตัวเอง และปัจจุบันยังไม่มีมาตรฐานดังกล่าว

อนุญาตให้เครื่องมือคลังข้อมูลรวมข้อมูลเมตานี้ เพื่อแก้ไขสถานการณ์นี้ ผู้จำหน่ายเครื่องมือคลังข้อมูลชั้นนำหลายรายได้จัดตั้ง Meta Data Council ซึ่งต่อมาได้กลายเป็น Meta Data Coalition

เป้าหมายของความร่วมมือนี้คือการสร้างชุดข้อมูลเมตามาตรฐานที่ช่วยให้เครื่องมือคลังข้อมูลต่างๆ สามารถแปลงข้อมูลเมตาได้
ความพยายามของพวกเขาส่งผลให้เกิด Meta Data Interchange Specification (MDIS) ซึ่งจะอนุญาตให้มีการแลกเปลี่ยนข้อมูลระหว่างไฟล์เก็บถาวรของ Microsoft และไฟล์ MDIS ที่เกี่ยวข้อง

การมีอยู่ของ ข้อมูล ทั้งแบบสรุป/จัดทำดัชนีและแบบละเอียด ทำให้ผู้ใช้สามารถทำการ DRILL DROWN (การเจาะ) จาก ข้อมูล จัดทำดัชนีเป็นรายละเอียดและในทางกลับกัน การมีอยู่ของ ข้อมูล ประวัติโดยละเอียดช่วยให้สามารถสร้างการวิเคราะห์แนวโน้มเมื่อเวลาผ่านไป นอกจากนี้ ข้อมูลเมตาของการวิเคราะห์ยังสามารถใช้เป็นไดเร็กทอรีเดล ฐานข้อมูล เดล คลังข้อมูล เพื่อช่วยให้ผู้ใช้ค้นหา i ข้อมูล จำเป็น.

เมื่อเปรียบเทียบกับระบบ OLTP ด้วยความสามารถในการรองรับการวิเคราะห์ของ ข้อมูล และการรายงาน, การ คลังข้อมูล ถูกมองว่าเป็นระบบที่เหมาะสมกว่าสำหรับกระบวนการข้อมูล เช่น การสร้างและตอบคำถามและการจัดทำรายงาน ส่วนถัดไปจะเน้นความแตกต่างของทั้งสองระบบโดยละเอียด

คลังข้อมูล ต่อต้านระบบ OLTP

ระบบข้อมูลจำนวนมากภายในองค์กรมีไว้เพื่อสนับสนุนการดำเนินงานในแต่ละวัน ระบบเหล่านี้เรียกว่า OLTP SYSTEMS บันทึกธุรกรรมรายวันที่อัปเดตอย่างต่อเนื่อง

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

ซึ่งแตกต่างจากระบบ OLTP ซึ่งสร้างขึ้นสำหรับกระบวนการตามธุรกรรมและเหตุการณ์ คลังข้อมูล ถูกสร้างขึ้นเพื่อให้การสนับสนุนกระบวนการตามการวิเคราะห์ ข้อมูล และกระบวนการตัดสินใจ

โดยปกติจะทำได้โดยการรวม i ข้อมูล จาก OLTP และระบบภายนอกที่หลากหลายใน "คอนเทนเนอร์" เดียวของ ข้อมูลตามที่กล่าวไว้ในส่วนก่อนหน้า

แบบจำลองกระบวนการคลังข้อมูล Monash

รูปแบบกระบวนการสำหรับ คลังข้อมูล Monash ได้รับการพัฒนาโดยนักวิจัยจาก Monash DSS Research Group และอ้างอิงจากวรรณกรรมของ คลังข้อมูล, ประสบการณ์ในการพัฒนาระบบสนับสนุนสาขาต่างๆ , ปรึกษาหารือกับผู้จำหน่ายแอปพลิเคชันเพื่อใช้งานบน คลังข้อมูลว่าด้วยกลุ่มผู้เชี่ยวชาญในการใช้งาน คลังข้อมูล.

ขั้นตอนคือ: การเริ่มต้น การวางแผน การพัฒนา การดำเนินงาน และการอธิบาย แผนภาพอธิบายลักษณะการวนซ้ำหรือวิวัฒนาการของการพัฒนา a คลังข้อมูล ดำเนินการโดยใช้ลูกศรสองทางที่วางระหว่างขั้นตอนต่างๆ ในบริบทนี้ "วนซ้ำ" และ "วิวัฒนาการ" หมายความว่า ในแต่ละขั้นตอนของกระบวนการ กิจกรรมการนำไปใช้สามารถเผยแพร่ย้อนกลับไปยังขั้นตอนก่อนหน้าได้เสมอ นี่เป็นเพราะลักษณะของโครงการ คลังข้อมูล ซึ่งผู้ใช้ปลายทางร้องขอเพิ่มเติมเมื่อใดก็ได้ ตัวอย่างเช่น ในระหว่างขั้นตอนการพัฒนาของกระบวนการ คลังข้อมูลหากผู้ใช้ปลายทางร้องขอขนาดหัวเรื่องหรือพื้นที่ใหม่ ซึ่งไม่ได้เป็นส่วนหนึ่งของแผนเดิม จะต้องเพิ่มเข้าไปในระบบ สิ่งนี้ทำให้เกิดการเปลี่ยนแปลงในโครงการ ผลลัพธ์คือทีมออกแบบต้องเปลี่ยนข้อกำหนดของเอกสารที่สร้างขึ้นในระหว่างขั้นตอนการออกแบบ ในหลายกรณี สถานะปัจจุบันของโครงการต้องย้อนกลับไปที่ขั้นตอนการออกแบบซึ่งต้องมีการเพิ่มและจัดทำเอกสารข้อกำหนดใหม่ ผู้ใช้ต้องสามารถดูเอกสารเฉพาะที่ได้รับการตรวจสอบและการเปลี่ยนแปลงที่เกิดขึ้นในขั้นตอนการพัฒนา เมื่อสิ้นสุดวงจรการพัฒนานี้ โปรเจกต์จำเป็นต้องได้รับการตอบรับที่ดีจากทั้งทีมพัฒนาและผู้ใช้ ข้อเสนอแนะจะถูกใช้ซ้ำเพื่อปรับปรุงโครงการในอนาคต

วางแผนกำลังการผลิต
dw มีแนวโน้มที่จะมีขนาดใหญ่มากและเติบโตเร็วมาก (Best 1995, Rudin 1997a) เนื่องจากจำนวน ข้อมูล ประวัติศาสตร์ที่พวกเขารักษาจากระยะเวลาของพวกเขา การเจริญเติบโตยังสามารถเกิดจาก ข้อมูล ส่วนเสริมที่ผู้ใช้ร้องขอเพื่อเพิ่มมูลค่าของ ข้อมูล ที่พวกเขามีอยู่แล้ว ดังนั้นข้อกำหนดในการจัดเก็บสำหรับ ข้อมูล สามารถปรับปรุงได้อย่างมีนัยสำคัญ (Eckerson 1997) ดังนั้นจึงจำเป็นอย่างยิ่งที่จะต้องดำเนินการวางแผนกำลังการผลิต เพื่อให้มั่นใจว่าระบบที่จะสร้างขึ้นสามารถเติบโตได้ตามความต้องการที่เพิ่มขึ้น (Best 1995, LaPlante 1996, Lang 1997, Eckerson 1997, Rudin 1997a, Foley 1997a)
ในการวางแผนสำหรับการขยายขนาดคลังข้อมูล เราต้องทราบการเติบโตของขนาดคลังสินค้าที่คาดไว้ ประเภทของคำถามที่น่าจะสร้างขึ้น และจำนวนผู้ใช้ปลายทางที่ได้รับการสนับสนุน (Best 1995, Rudin 1997b, Foley 1997a) การสร้างแอปพลิเคชันที่ปรับขนาดได้ต้องใช้การผสมผสานระหว่างเทคโนโลยีเซิร์ฟเวอร์ที่ปรับขนาดได้และเทคนิคการออกแบบแอปพลิเคชันที่ปรับขนาดได้ (Best 1995, Rudin 1997b ทั้งสองอย่างนี้จำเป็นในการสร้างแอปพลิเคชันที่ปรับขนาดได้สูง เทคโนโลยีเซิร์ฟเวอร์ที่ปรับขนาดได้ทำให้การเพิ่มที่เก็บข้อมูล หน่วยความจำ และ CPU เป็นเรื่องง่ายและประหยัดต้นทุน ลดประสิทธิภาพ (Lang 1997, Telephony 1997)

มีสองเทคโนโลยีเซิร์ฟเวอร์ที่ปรับขนาดได้หลัก: การประมวลผลหลายรายการแบบสมมาตร (SMP) และการประมวลผลแบบคู่ขนานขนาดใหญ่ (MPP) ) (IDC 1997, Humphries et al. 1999) โดยทั่วไปเซิร์ฟเวอร์ SMP จะมีโปรเซสเซอร์หลายตัวที่ใช้หน่วยความจำ บัสระบบ และทรัพยากรอื่นๆ ร่วมกัน (IDC 1997, Humphries et al. 1999) สามารถเพิ่มโปรเซสเซอร์เพิ่มเติมเพื่อเพิ่มประสิทธิภาพได้ อาจ การคำนวณ อีกวิธีในการเพิ่ม อาจ การคำนวณของเซิร์ฟเวอร์ SMP คือการรวมเครื่อง SMP จำนวนมาก เทคนิคนี้เรียกว่าการจัดกลุ่ม (Humphries et al. 1999) ในทางกลับกัน เซิร์ฟเวอร์ MPP มีโปรเซสเซอร์หลายตัว แต่ละตัวมีหน่วยความจำ ระบบบัส และทรัพยากรอื่นๆ ของตัวเอง (IDC 1997, Humphries et al. 1999) โปรเซสเซอร์แต่ละตัวเรียกว่าโหนด เพิ่มขึ้นใน อาจ สามารถคำนวณหาค่าได้

การเพิ่มโหนดเพิ่มเติมให้กับเซิร์ฟเวอร์ MPP (Humphries et al. 1999)

จุดอ่อนของเซิร์ฟเวอร์ SMP คือการดำเนินการอินพุต-เอาต์พุต (I/O) มากเกินไปอาจทำให้ระบบบัสแออัด (IDC 1997) ปัญหานี้ไม่เกิดขึ้นภายในเซิร์ฟเวอร์ MPP เนื่องจากแต่ละโปรเซสเซอร์มีระบบบัสของตัวเอง อย่างไรก็ตาม การเชื่อมต่อระหว่างกันระหว่างแต่ละโหนดมักจะช้ากว่าระบบบัส SMP มาก นอกจากนี้ เซิร์ฟเวอร์ MPP ยังเพิ่มความซับซ้อนให้กับนักพัฒนาแอปพลิเคชัน (IDC 1997) ดังนั้น ตัวเลือกระหว่างเซิร์ฟเวอร์ SMP และ MPP อาจได้รับอิทธิพลจากหลายปัจจัย รวมถึงความซับซ้อนของแอปพลิเคชัน อัตราส่วนราคา/ประสิทธิภาพ ปริมาณงานที่ต้องการ แอปพลิเคชัน dw ที่ป้องกัน และขนาดที่เพิ่มขึ้นของเซิร์ฟเวอร์ ฐานข้อมูล ของ dw และในจำนวนผู้ใช้ปลายทาง

สามารถใช้เทคนิคการออกแบบแอปพลิเคชันที่ปรับขนาดได้จำนวนหนึ่งในการวางแผนกำลังการผลิต หนึ่งใช้รอบระยะเวลาการรายงานต่างๆ เช่น วัน สัปดาห์ เดือน และปี มีระยะเวลาการแจ้งเตือนต่างๆ, the ฐานข้อมูล สามารถแบ่งออกเป็นกลุ่มที่จัดการได้ (Inmon et al. 1997) อีกเทคนิคหนึ่งคือการใช้ตารางสรุปที่สร้างขึ้นโดยการสรุป ข้อมูล da ข้อมูล รายละเอียด ดังนั้นฉัน ข้อมูล บทคัดย่อมีขนาดกะทัดรัดกว่ารายละเอียดซึ่งต้องการพื้นที่หน่วยความจำน้อยกว่า ดังนั้น ข้อมูล สามารถเก็บรายละเอียดต่างๆ ไว้ในหน่วยจัดเก็บข้อมูลที่มีราคาไม่แพง ซึ่งช่วยประหยัดพื้นที่จัดเก็บได้มากขึ้น แม้ว่าการใช้ตารางสรุปจะช่วยประหยัดพื้นที่ในการจัดเก็บ แต่ก็ต้องใช้ความพยายามอย่างมากในการทำให้ตารางเป็นปัจจุบันและสอดคล้องกับความต้องการทางธุรกิจ อย่างไรก็ตาม เทคนิคนี้ใช้กันอย่างแพร่หลายและมักใช้ร่วมกับเทคนิคก่อนหน้า (Best 1995, Inmon 1996a, Chauduri และ Dayal
1997)

การกำหนด คลังข้อมูล สถาปัตยกรรมทางเทคนิค ความหมายของเทคนิคสถาปัตยกรรม dw

ผู้ใช้งานดาต้าแวร์เฮาส์ในยุคแรกๆ มองเห็นถึงการใช้งานดาต้าแวร์เฮาส์แบบรวมศูนย์ที่ทุกคน ข้อมูลรวมทั้งฉัน ข้อมูล ภายนอกมารวมเป็นหนึ่งเดียว
พื้นที่เก็บข้อมูลจริง (Inmon 1996a, Bresnahan 1996, Peacock 1998)

ประโยชน์หลักของแนวทางนี้คือผู้ใช้ปลายทางสามารถเข้าถึงมุมมองทั่วทั้งองค์กรของ ข้อมูล องค์กร (Ovum 1998) ข้อดีอีกอย่างคือมีมาตรฐานของ ข้อมูล ทั่วทั้งองค์กร ซึ่งหมายความว่ามีเพียงเวอร์ชันเดียวหรือคำจำกัดความสำหรับคำศัพท์แต่ละคำที่ใช้ในข้อมูลเมตาของที่เก็บ (Flanagan และ Safdie 1997, Ovum 1998) ในทางกลับกัน ข้อเสียของวิธีนี้คือมีราคาแพงและยากต่อการสร้าง (Flanagan and Safdie 1997, Ovum 1998, Inmon et al. 1998) ไม่นานหลังจากสถาปัตยกรรมสตอเรจ ข้อมูล การรวมศูนย์กลายเป็นที่นิยม แนวคิดของการขุดส่วนย่อยที่เล็กที่สุดของเทพเจ้าได้พัฒนาขึ้น ข้อมูล เพื่อรองรับความต้องการของการใช้งานเฉพาะ (Varney 1996, IDC 1997, Berson and Smith 1997, peacock 1998) ระบบขนาดเล็กเหล่านี้ได้รับมาจากระบบที่ใหญ่กว่า คลังข้อมูล รวมศูนย์ พวกเขามีชื่อว่า คลังข้อมูล แผนกพนักงานหรือดาต้ามาร์ทพนักงาน สถาปัตยกรรม data mart ที่ขึ้นต่อกันเรียกว่าสถาปัตยกรรมแบบสามชั้น โดยที่ชั้นแรกประกอบด้วย คลังข้อมูล รวมศูนย์ที่สองประกอบด้วยเงินฝากของ ข้อมูล แผนกและสามประกอบด้วยการเข้าถึง ข้อมูล และด้วยเครื่องมือวิเคราะห์ (Demarest 1994, Inmon et al. 1997)

ดาต้ามาร์ทมักจะสร้างขึ้นหลังจาก คลังข้อมูล แบบรวมศูนย์ถูกสร้างขึ้นเพื่อตอบสนองความต้องการของหน่วยงานเฉพาะ (White 1995, Varney 1996)
ดาต้ามาร์ทสโตร์ i ข้อมูล ที่เกี่ยวข้องกับหน่วยเฉพาะ (Inmon et al. 1997, Inmon et al. 1998, IA 1998)

ข้อดีของวิธีนี้คือจะไม่มี Dato ไม่รวมและฉัน ข้อมูล จะมีความซ้ำซ้อนน้อยลงภายใน data mart เนื่องจากทั้งหมด ข้อมูล มาจากการฝากเงินของ ข้อมูล แบบบูรณาการ. ข้อดีอีกประการหนึ่งคือจะมีการเชื่อมโยงน้อยลงระหว่างดาต้ามาร์ทแต่ละแห่งและแหล่งที่มา ข้อมูล เนื่องจากดาต้ามาร์ทแต่ละแห่งมีแหล่งที่มาเพียงแหล่งเดียว ข้อมูล. บวกกับสถาปัตยกรรมนี้ ผู้ใช้ปลายทางยังสามารถเข้าถึง ข้อมูล

องค์กร บริษัท วิธีนี้เรียกว่าวิธีจากบนลงล่าง ซึ่งดาต้ามาร์ทถูกสร้างขึ้นหลังจาก คลังข้อมูล (นกยูง 1998, ก๊อฟ 1998).
ความจำเป็นในการแสดงผลตั้งแต่เนิ่นๆ เพิ่มมากขึ้น บางองค์กรได้เริ่มสร้างดาต้ามาร์ทอิสระ (Flanagan and Safdie 1997, White 2000) ในกรณีนี้ดาต้ามาร์ทจะได้รับ ข้อมูล ตรงจากพื้นฐานของ ข้อมูล OLTP และไม่ใช่ OLTP จากที่เก็บข้อมูลแบบรวมศูนย์และแบบรวม ดังนั้นจึงไม่จำเป็นต้องใช้ที่เก็บส่วนกลาง

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

ดาต้ามาร์ททุกแห่งต้องจัดเก็บทั้งหมด ข้อมูล ที่จำเป็นในเครื่องเพื่อไม่ให้มีผลกระทบต่อระบบ OLTP สิ่งนี้ทำให้ฉัน ข้อมูล พวกมันถูกเก็บไว้ในดาต้ามาร์ทที่แตกต่างกัน (Inmon et al. 1997) ข้อเสียอีกประการหนึ่งของสถาปัตยกรรมนี้คือนำไปสู่การสร้างการเชื่อมต่อที่ซับซ้อนระหว่างดาต้ามาร์ทและแหล่งข้อมูล ข้อมูล ซึ่งปฏิบัติและควบคุมได้ยาก (Inmon et al. 1997)

ข้อเสียอีกประการหนึ่งคือผู้ใช้ปลายทางอาจไม่สามารถเข้าถึงภาพรวมข้อมูลของบริษัทได้เนื่องจาก i ข้อมูล ของดาต้ามาร์ทที่แตกต่างกันไม่ได้ถูกรวมเข้าด้วยกัน (Ovum 1998)
ข้อเสียอีกประการหนึ่งคืออาจมีคำจำกัดความมากกว่าหนึ่งคำสำหรับคำศัพท์แต่ละคำที่ใช้ในดาต้ามาร์ทที่สร้างความไม่สอดคล้องกันของข้อมูล ข้อมูล ในองค์กร (Ovum 1998)
แม้จะมีข้อเสียที่กล่าวถึงข้างต้น แต่ดาต้ามาร์ทแบบสแตนด์อโลนยังคงดึงดูดความสนใจจากหลายองค์กร (IDC 1997) ปัจจัยหนึ่งที่ทำให้พวกเขาน่าสนใจคือพวกเขาพัฒนาได้เร็วกว่าและใช้เวลาและทรัพยากรน้อยลง (Bresnahan 1996, Berson and Smith 1997, Ovum 1998) ดังนั้นจึงทำหน้าที่เป็นแบบทดสอบที่สามารถใช้ในการระบุข้อดีและ/หรือข้อบกพร่องในการออกแบบได้อย่างรวดเร็ว (Parsaye 1995, Braly 1995, Newing 1996) ในกรณีนี้ ส่วนที่จะดำเนินการในโครงการนำร่องต้องมีขนาดเล็กแต่มีความสำคัญต่อองค์กร (Newing 1996, Mansell-Lewis 1996)

โดยการตรวจสอบต้นแบบ ผู้ใช้และผู้บริหารสามารถตัดสินใจได้ว่าจะดำเนินการต่อหรือหยุดโครงการ (Flanagan และ Safdie 1997)
หากการตัดสินใจดำเนินการต่อ ควรสร้างดาต้ามาร์ทสำหรับอุตสาหกรรมอื่นทีละรายการ มีสองทางเลือกสำหรับผู้ใช้ปลายทางตามความต้องการในการสร้าง data matrs อิสระ: แบบบูรณาการ/แบบรวมศูนย์ และแบบไม่รวม (Ovum 1998)

ในวิธีแรก ดาต้ามาร์ทใหม่แต่ละอันควรสร้างขึ้นจากดาต้ามาร์ทและโมเดลปัจจุบัน ข้อมูล ใช้โดยบริษัท (Varney 1996, Berson and Smith 1997, Peacock 1998) จำเป็นต้องใช้แบบจำลอง ข้อมูล ขององค์กรหมายความว่าต้องแน่ใจว่ามีคำจำกัดความเพียงคำเดียวสำหรับคำศัพท์แต่ละคำที่ใช้ในดาต้ามาร์ท และเพื่อให้แน่ใจว่าดาต้ามาร์ทต่างๆ สามารถรวมเข้าด้วยกันเพื่อให้ภาพรวมของข้อมูลองค์กร (Bresnahan 1996) วิธีนี้เรียกว่าวิธีจากล่างขึ้นบน (Bottom-up method) และจะใช้ได้ดีที่สุดเมื่อมีข้อจำกัดเกี่ยวกับวิธีการทางการเงินและเวลา (Flanagan and Safdie 1997, Ovum 1998, peacock 1998, Goff 1998) ในวิธีที่สอง data mart ที่สร้างขึ้นสามารถตอบสนองความต้องการของหน่วยเฉพาะเท่านั้น ตัวแปรของ data mart รวมศูนย์คือ คลังข้อมูล จัดจำหน่ายซึ่ง ฐานข้อมูล มิดเดิลแวร์เซิร์ฟเวอร์ฮับใช้เพื่อรวมดาต้ามาร์ทจำนวนมากเข้าไว้ในที่เก็บข้อมูลเดียว ข้อมูล จัดจำหน่าย (ขาว 1995) ในกรณีนี้ ผม ข้อมูล ธุรกิจกระจายอยู่ในดาต้ามาร์ทหลายแห่ง คำขอของผู้ใช้จะถูกส่งต่อไปยัง ฐานข้อมูล มิดเดิลแวร์เซิร์ฟเวอร์ฮับซึ่งแยกทั้งหมด ข้อมูล ร้องขอโดย data mart และป้อนผลลัพธ์กลับไปยังแอปพลิเคชันของผู้ใช้ปลายทาง วิธีนี้ให้ข้อมูลทางธุรกิจแก่ผู้ใช้ปลายทาง อย่างไรก็ตาม ปัญหาของดาต้ามาร์ทอิสระยังไม่หมดไป มีสถาปัตยกรรมอีกแบบหนึ่งที่สามารถนำมาใช้ได้ซึ่งเรียกว่า คลังข้อมูล เสมือน (สีขาว 1995) อย่างไรก็ตาม สถาปัตยกรรมนี้ ซึ่งแสดงในรูปที่ 2.9 ไม่ใช่สถาปัตยกรรมการจัดเก็บข้อมูล ข้อมูล จริงเนื่องจากไม่ได้ย้ายโหลดจากระบบ OLTP ไป คลังข้อมูล (ดีมาเรสต์ 1994).

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

ข้อมูล ประวัติและภาพรวมของข้อมูลบริษัทตั้งแต่ i ข้อมูล เนื่องจากระบบ OLTP ที่แตกต่างกันไม่ได้ถูกรวมเข้าด้วยกัน ดังนั้นสถาปัตยกรรมนี้จึงไม่สามารถตอบสนองการวิเคราะห์ของ ข้อมูล เช่น การทำนาย

การเลือกแอปพลิเคชันการเข้าถึงและการกู้คืนข้อมูล ข้อมูล

วัตถุประสงค์ในการสร้างก คลังข้อมูล คือการถ่ายทอดข้อมูลไปยังผู้ใช้ปลายทาง (Inmon et al. 1997, Poe 1996, McFadden 1996, Shanks et al. 1997, Hammergren 1998); แอ็พพลิเคชันการเข้าถึงและการกู้คืนอย่างน้อยหนึ่งรายการ ข้อมูล จะต้องจัดให้มี จนถึงปัจจุบัน มีแอพพลิเคชั่นดังกล่าวมากมายให้ผู้ใช้เลือกใช้ (Hammergren 1998, Humphries et al. 1999) แอปพลิเคชันที่เลือกกำหนดความสำเร็จของความพยายามในคลังสินค้า ข้อมูล ในองค์กรเนื่องจากแอปพลิเคชันเป็นส่วนที่มองเห็นได้ชัดเจนที่สุดของ คลังข้อมูล ให้กับผู้ใช้ปลายทาง (Inmon et al. 1997, Poe 1996) ก. ให้ประสบความสำเร็จ คลังข้อมูลต้องสามารถรองรับกิจกรรมการวิเคราะห์ข้อมูลได้ ข้อมูล ของผู้ใช้ปลายทาง (Poe 1996, Seddon and Benjamin 1998, Eckerson 1999) ดังนั้นจึงต้องมีการระบุ "ระดับ" ของสิ่งที่ผู้ใช้ปลายทางต้องการ (Poe 1996, Mattison 1996, Inmon et al. 1997, Humphries et al. 1999)

โดยทั่วไป ผู้ใช้ปลายทางสามารถแบ่งออกได้เป็น 1996 ประเภท ได้แก่ ผู้ใช้ระดับผู้บริหาร นักวิเคราะห์ธุรกิจ และผู้ใช้ระดับสูง (Poe 1999, Humphries et al. 1999) ผู้ใช้ระดับผู้บริหารต้องเข้าถึงชุดรายงานที่กำหนดไว้ล่วงหน้าได้ง่าย (Humphries et al. 1996) รายงานเหล่านี้สามารถเข้าถึงได้ง่ายด้วยการนำทางเมนู (Poe 1999) นอกจากนี้ รายงานควรนำเสนอข้อมูลโดยใช้การแสดงกราฟิก เช่น ตารางและแม่แบบ เพื่อถ่ายทอดข้อมูลอย่างรวดเร็ว (Humphries et al. 1996) นักวิเคราะห์ธุรกิจที่อาจไม่มีความสามารถด้านเทคนิคในการพัฒนารายงานตั้งแต่เริ่มต้นด้วยตัวเอง จำเป็นต้องสามารถปรับเปลี่ยนรายงานปัจจุบันให้ตรงกับความต้องการเฉพาะของตนได้ (Poe 1999, Humphries et al. 1996) ในทางกลับกัน ผู้ใช้ระดับสูงคือประเภทของผู้ใช้ปลายทางที่มีความสามารถในการสร้างและเขียนคำขอและรายงานตั้งแต่เริ่มต้น (Poe 1999, Humphries et al. XNUMX) พวกเขาเป็นคนที่

พวกเขาสร้างความสัมพันธ์สำหรับผู้ใช้ประเภทอื่น (Poe 1996, Humphries et al. 1999)

เมื่อกำหนดความต้องการของผู้ใช้ปลายทางแล้ว จะต้องเลือกแอปพลิเคชันการเข้าถึงและการกู้คืน ข้อมูล ที่มีอยู่ทั้งหมด (Poe 1996, Inmon et al. 1997)
การเข้าถึง ข้อมูล และเครื่องมือดึงข้อมูลสามารถแบ่งออกได้เป็น 4 ประเภท ได้แก่ เครื่องมือ OLAP เครื่องมือ EIS/DSS เครื่องมือสืบค้นและรายงาน และเครื่องมือขุดข้อมูล

เครื่องมือ OLAP อนุญาตให้ผู้ใช้สร้างการสืบค้นเฉพาะกิจเช่นเดียวกับที่สร้างบน ฐานข้อมูล เดล คลังข้อมูล. นอกจากนี้ ผลิตภัณฑ์เหล่านี้ยังช่วยให้ผู้ใช้สามารถเจาะลึกจาก ข้อมูล ทั่วไปถึงรายละเอียด

เครื่องมือ EIS/DSS ให้การรายงานสำหรับผู้บริหาร เช่น การวิเคราะห์ "จะเกิดอะไรขึ้นถ้า" และการเข้าถึงรายงานที่ขับเคลื่อนด้วยเมนู รายงานควรกำหนดไว้ล่วงหน้าและรวมเข้ากับเมนูเพื่อการนำทางที่ง่ายขึ้น
เครื่องมือสืบค้นและการรายงานช่วยให้ผู้ใช้สร้างรายงานที่กำหนดไว้ล่วงหน้าและเฉพาะเจาะจงได้

เครื่องมือการทำเหมืองข้อมูลใช้เพื่อระบุความสัมพันธ์ที่สามารถให้แสงสว่างใหม่เกี่ยวกับการดำเนินการที่ถูกลืม ข้อมูล ของคลังข้อมูล

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

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

จัดหาให้ในราคาที่ถูกลงผ่านการลดต้นทุนการฝึกอบรม

2.4.3 คลังข้อมูล ขั้นตอนการดำเนินงาน

ขั้นตอนนี้ประกอบด้วยสามกิจกรรม: คำจำกัดความของกลยุทธ์การรีเฟรชข้อมูล การควบคุมกิจกรรมคลังข้อมูล และการจัดการความปลอดภัยของคลังข้อมูล

คำจำกัดความของกลยุทธ์การรีเฟรชข้อมูล

หลังจากโหลดครั้งแรก i ข้อมูล ใน ฐานข้อมูล ของคลังข้อมูลต้องได้รับการรีเฟรชเป็นระยะเพื่อทำซ้ำการเปลี่ยนแปลงที่ทำกับ ข้อมูล ต้นฉบับ ดังนั้นคุณต้องตัดสินใจว่าจะรีเฟรชเมื่อใด ควรกำหนดเวลารีเฟรชบ่อยแค่ไหน และจะรีเฟรชอย่างไร ข้อมูล. ขอแนะนำให้รีเฟรช ข้อมูล เมื่อระบบสามารถออฟไลน์ได้ อัตราการรีเฟรชถูกกำหนดโดยทีมพัฒนาตามความต้องการของผู้ใช้ มีสองวิธีในการรีเฟรชคลังข้อมูล: การรีเฟรชแบบเต็มและการอัปโหลดการเปลี่ยนแปลงอย่างต่อเนื่อง

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

อีกวิธีหนึ่งคือการอัปโหลดการเปลี่ยนแปลงอย่างต่อเนื่อง สิ่งนี้จะเพิ่มฉัน ข้อมูล ที่มีการเปลี่ยนแปลงตั้งแต่รอบการรีเฟรชคลังข้อมูลครั้งล่าสุด การระบุเรกคอร์ดใหม่หรือที่เปลี่ยนแปลงช่วยลดจำนวนได้อย่างมาก ข้อมูล ซึ่งจะต้องเผยแพร่ไปยังคลังข้อมูลในการอัพเดทแต่ละครั้งเท่านั้น ข้อมูล จะถูกเพิ่มใน ฐานข้อมูล ของคลังข้อมูล

มีอย่างน้อย 5 วิธีที่สามารถใช้เพื่อถอน i ข้อมูล ใหม่หรือดัดแปลง เพื่อให้ได้กลยุทธ์การรีเฟรชวิดีโอที่มีประสิทธิภาพ ข้อมูล การผสมผสานของวิธีการเหล่านี้ที่ดึงการเปลี่ยนแปลงทั้งหมดในระบบอาจมีประโยชน์

วิธีแรกซึ่งใช้การประทับเวลาจะถือว่าทุกคนได้รับมอบหมาย ข้อมูล แก้ไขและอัปเดตการประทับเวลาเพื่อให้คุณสามารถระบุทั้งหมดได้อย่างง่ายดาย ข้อมูล แก้ไขและใหม่ อย่างไรก็ตาม วิธีการนี้ยังไม่ได้ใช้กันอย่างแพร่หลายในระบบปฏิบัติการส่วนใหญ่ในปัจจุบัน
วิธีที่สองคือการใช้ไฟล์เดลต้าที่สร้างโดยแอปพลิเคชันซึ่งมีเฉพาะการเปลี่ยนแปลงที่ทำกับ ข้อมูล. การใช้ไฟล์นี้ยังขยายรอบการอัปเดต อย่างไรก็ตามวิธีนี้ยังไม่ได้ถูกนำมาใช้ในหลาย ๆ แอปพลิเคชัน
วิธีที่สามคือการสแกนไฟล์บันทึก ซึ่งมีข้อมูลที่คล้ายกับไฟล์เดลต้า ข้อแตกต่างเพียงอย่างเดียวคือไฟล์บันทึกถูกสร้างขึ้นสำหรับกระบวนการกู้คืนและอาจเข้าใจได้ยาก
วิธีที่สี่คือการแก้ไขรหัสแอปพลิเคชัน อย่างไรก็ตาม โค้ดแอปพลิเคชันส่วนใหญ่นั้นเก่าและเปราะบาง ดังนั้นจึงควรหลีกเลี่ยงเทคนิคนี้
วิธีสุดท้ายคือการเปรียบเทียบ i ข้อมูล แหล่งที่มาด้วยไฟล์หลัก dei ข้อมูล.

การตรวจสอบกิจกรรมคลังข้อมูล

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

นอกจากนี้ การตรวจสอบคลังข้อมูลยังสามารถใช้เพื่อระบุประเภทการสืบค้น ขนาด จำนวนการสืบค้นต่อวัน เวลาตอบสนองการสืบค้น ภาคที่เข้าถึง และจำนวน ข้อมูล แปรรูป. วัตถุประสงค์อีกประการหนึ่งของการตรวจสอบคลังข้อมูลคือการระบุ ข้อมูล ที่ไม่ได้ใช้งาน เหล่านี้ ข้อมูล สามารถลบออกจากคลังข้อมูลเพื่อปรับปรุงเวลา

การตอบสนองการดำเนินการค้นหาและควบคุมการเติบโตของ ข้อมูล ซึ่งอาศัยอยู่ภายใน ฐานข้อมูล ของคลังข้อมูล

การจัดการความปลอดภัยของคลังข้อมูล

คลังข้อมูลประกอบด้วย ข้อมูล บูรณาการ สำคัญ ละเอียดอ่อนที่สามารถเข้าถึงได้ง่าย ด้วยเหตุนี้จึงควรได้รับการปกป้องจากผู้ใช้ที่ไม่ได้รับอนุญาต วิธีหนึ่งในการใช้การรักษาความปลอดภัยคือการใช้ฟังก์ชัน del DBMS เพื่อกำหนดสิทธิ์ที่แตกต่างกันให้กับผู้ใช้ประเภทต่างๆ ด้วยวิธีนี้ จะต้องรักษาโปรไฟล์การเข้าถึงสำหรับผู้ใช้แต่ละประเภท อีกวิธีในการรักษาความปลอดภัยคลังข้อมูลคือการเข้ารหัสตามที่เขียนไว้ใน ฐานข้อมูล ของคลังข้อมูล การเข้าถึง ข้อมูล และเครื่องมือดึงข้อมูลต้องถอดรหัส ข้อมูล ก่อนนำเสนอผลงานสู่ผู้ใช้

2.4.4 คลังข้อมูล ขั้นตอนการปรับใช้

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

การฝึกอบรมผู้ใช้

ควรทำการฝึกอบรมผู้ใช้ก่อนเข้าใช้งาน ข้อมูล ของคลังข้อมูลและการใช้เครื่องมือดึงข้อมูล โดยทั่วไป เซสชันควรเริ่มต้นด้วยการแนะนำแนวคิดของพื้นที่เก็บข้อมูล ข้อมูล, เนื้อหาของคลังข้อมูล, เมตา ข้อมูล และคุณสมบัติพื้นฐานของเครื่องมือ จากนั้น ผู้ใช้ขั้นสูงอาจศึกษาตารางทางกายภาพและคุณลักษณะของผู้ใช้เครื่องมือเข้าถึงและดึงข้อมูล

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

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

วัตถุประสงค์ของการฝึกอบรมผู้ใช้คือเพื่อทำความคุ้นเคยกับการเข้าถึง ข้อมูล และเครื่องมือในการดึงข้อมูลตลอดจนเนื้อหาของคลังข้อมูล อย่างไรก็ตาม ผู้ใช้บางคนอาจรู้สึกท่วมท้นไปด้วยจำนวนข้อมูลที่ให้ในระหว่างเซสชันการฝึกอบรม จากนั้นจำเป็นต้องทำเซสชันทบทวนหลายครั้งเพื่อการสนับสนุนอย่างต่อเนื่องและเพื่อตอบคำถามเฉพาะ ในบางกรณี กลุ่มผู้ใช้จะถูกสร้างขึ้นเพื่อให้การสนับสนุนประเภทนี้

การรวบรวมความคิดเห็น

เมื่อคลังข้อมูลเปิดตัวแล้ว ผู้ใช้สามารถใช้ i ข้อมูล อยู่ในคลังข้อมูลเพื่อวัตถุประสงค์ต่างๆ ส่วนใหญ่นักวิเคราะห์หรือผู้ใช้จะใช้ i ข้อมูล ในคลังข้อมูลสำหรับ:

1. 1 ระบุแนวโน้มของบริษัท
2. 2 วิเคราะห์โปรไฟล์การซื้อของ ลูกค้า
3. 3 แยก i ลูกค้า เอ็ดฉัน
4. 4 ให้บริการที่ดีที่สุดแก่ ลูกค้า – ปรับแต่งบริการ
5. 5 กำหนดกลยุทธ์ การตลาด
6. 6 สร้างราคาที่สามารถแข่งขันได้สำหรับการวิเคราะห์ต้นทุนและช่วยควบคุม
7. 7 สนับสนุนการตัดสินใจเชิงกลยุทธ์
8. 8 ระบุโอกาสที่จะเกิดขึ้น
9. 9 ปรับปรุงคุณภาพของกระบวนการทางธุรกิจในปัจจุบัน
10. 10 ตรวจสอบผลกำไร

ตามทิศทางการพัฒนาของคลังข้อมูล สามารถดำเนินการทบทวนระบบหลายชุดเพื่อรับข้อเสนอแนะ

ทั้งโดยทีมพัฒนาและชุมชนผู้ใช้ปลายทาง
ผลลัพธ์ที่ได้สามารถนำไปพิจารณาในการพัฒนารอบต่อไป

เนื่องจากคลังข้อมูลมีวิธีการที่เพิ่มขึ้น จึงจำเป็นอย่างยิ่งที่จะต้องเรียนรู้จากความสำเร็จและข้อผิดพลาดของการพัฒนาก่อนหน้านี้

2.5 สรุป

ในบทนี้มีการกล่าวถึงแนวทางที่มีอยู่ในวรรณคดี ในส่วนที่ 1 ได้มีการกล่าวถึงแนวคิดของคลังข้อมูลและบทบาทของมันในวิทยาศาสตร์การตัดสินใจ ส่วนที่ 2 อธิบายความแตกต่างที่สำคัญระหว่างคลังข้อมูลและระบบ OLTP ส่วนที่ 3 กล่าวถึงโมเดลคลังข้อมูล Monash ซึ่งใช้ในส่วนที่ 4 เพื่ออธิบายกิจกรรมที่เกี่ยวข้องในกระบวนการพัฒนาคลังข้อมูล การอ้างสิทธิ์เหล่านี้ไม่ได้มาจากการวิจัยที่เข้มงวด สิ่งที่เกิดขึ้นในความเป็นจริงอาจแตกต่างอย่างมากจากสิ่งที่รายงานในวรรณกรรม อย่างไรก็ตาม ผลลัพธ์เหล่านี้สามารถใช้เพื่อสร้างสัมภาระพื้นฐานที่เน้นแนวคิดของคลังข้อมูลสำหรับการวิจัยนี้

บทที่ 3

วิธีวิจัยและออกแบบ

บทนี้จะกล่าวถึงวิธีการวิจัยและการออกแบบสำหรับการศึกษานี้ ส่วนแรกแสดงมุมมองทั่วไปของวิธีการวิจัยที่มีอยู่สำหรับการดึงข้อมูล นอกจากนี้ จะมีการกล่าวถึงเกณฑ์สำหรับการเลือกวิธีที่ดีที่สุดสำหรับการศึกษาหนึ่งๆ ในส่วนที่ 2 จะกล่าวถึงสองวิธีที่เลือกด้วยเกณฑ์ข้างต้น หนึ่งในนั้นจะถูกเลือกและนำไปใช้ด้วยเหตุผลที่กำหนดไว้ในส่วนที่ 3 ซึ่งเหตุผลของการยกเว้นเกณฑ์อื่น ๆ จะถูกกำหนดไว้เช่นกัน ส่วนที่ 4 นำเสนอโครงการวิจัย และส่วนที่ 5 บทสรุป

3.1 การวิจัยในระบบสารสนเทศ

การวิจัยระบบสารสนเทศไม่ได้จำกัดอยู่เพียงขอบเขตของเทคโนโลยีเท่านั้น แต่ยังต้องขยายไปถึงเป้าหมายเชิงพฤติกรรมและองค์กรด้วย
เราเป็นหนี้สิ่งนี้กับวิทยานิพนธ์ของสาขาวิชาต่างๆ ตั้งแต่สังคมศาสตร์ไปจนถึงธรรมชาติวิทยา สิ่งนี้นำไปสู่ความต้องการวิธีการวิจัยบางอย่างที่เกี่ยวข้องกับวิธีการเชิงปริมาณและคุณภาพเพื่อใช้สำหรับระบบสารสนเทศ
วิธีการวิจัยที่มีอยู่ทั้งหมดมีความสำคัญ ที่จริงแล้วนักวิจัยหลายคน เช่น Jenkins (1985), Nunamaker และคณะ (1991) และ Galliers (1992) ให้เหตุผลว่าไม่มีวิธีการสากลที่เฉพาะเจาะจงสำหรับการดำเนินการวิจัยในสาขาต่างๆ ของระบบสารสนเทศ ในความเป็นจริงแล้ววิธีการหนึ่งอาจเหมาะสำหรับการวิจัยเฉพาะ แต่ไม่เหมาะสำหรับผู้อื่น สิ่งนี้ทำให้เราจำเป็นต้องเลือกวิธีการที่เหมาะสมกับโครงการวิจัยของเราโดยเฉพาะ: สำหรับตัวเลือกนี้ Benbasat et al. (1987) กล่าวว่า ควรพิจารณาลักษณะและวัตถุประสงค์ของการวิจัย

3.1.1 ลักษณะของการวิจัย

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

3.1.1.1 การวิจัยเชิงบวก

การวิจัยเชิงบวกเรียกอีกอย่างว่าการศึกษาทางวิทยาศาสตร์หรือเชิงประจักษ์ มันพยายามที่จะ: "อธิบายและคาดการณ์ว่าจะเกิดอะไรขึ้นในโลกสังคมโดยดูที่ความสม่ำเสมอและความสัมพันธ์ระหว่างเหตุและผลระหว่างองค์ประกอบที่ประกอบกันเป็น" (Shanks et al 1993)

การวิจัยแบบโพสิทิวิสต์ยังโดดเด่นด้วยความสามารถในการทำซ้ำ การทำให้เข้าใจง่าย และการหักล้าง นอกจากนี้ การวิจัยในเชิงบวกยอมรับการมีอยู่ของความสัมพันธ์เบื้องต้นระหว่างปรากฏการณ์ที่ศึกษา
ตาม Galliers (1992) อนุกรมวิธานเป็นวิธีการวิจัยที่รวมอยู่ในกระบวนทัศน์เชิงบวก ซึ่งไม่ได้จำกัดเพียงแค่นี้ ในความเป็นจริงมีการทดลองในห้องปฏิบัติการ การทดลองภาคสนาม กรณีศึกษา การสาธิตทฤษฎีบท การคาดคะเน และการจำลอง เมื่อใช้วิธีการเหล่านี้ นักวิจัยยอมรับว่าปรากฏการณ์ที่ศึกษาสามารถสังเกตได้อย่างเป็นกลางและเข้มงวด

3.1.1.2 การวิจัยเชิงตีความ

Neuman (1994) อธิบายการวิจัยเชิงตีความ ซึ่งมักเรียกว่าปรากฏการณ์วิทยาหรือต่อต้านการมองโลกในแง่บวกว่าเป็น "การวิเคราะห์อย่างเป็นระบบเกี่ยวกับความหมายทางสังคมของการกระทำผ่านการสังเกตโดยตรงและละเอียดของผู้คนในสถานการณ์ทางธรรมชาติ เพื่อให้ได้ความเข้าใจและ การตีความว่าผู้คนสร้างและรักษาโลกทางสังคมของพวกเขาอย่างไร” การศึกษาเชิงตีความปฏิเสธข้อสันนิษฐานที่ว่าปรากฏการณ์ที่สังเกตสามารถสังเกตได้อย่างเป็นกลาง ในความเป็นจริงพวกเขาขึ้นอยู่กับการตีความอัตนัย นอกจากนี้ ผู้วิจัยเชิงตีความไม่ได้กำหนดความหมายเบื้องต้นเกี่ยวกับปรากฏการณ์ที่พวกเขาศึกษา

วิธีนี้รวมถึงการศึกษาแบบอัตนัย/เชิงโต้แย้ง การวิจัยเชิงปฏิบัติการ การศึกษาเชิงพรรณนา/เชิงตีความ การวิจัยในอนาคต และการแสดงบทบาทสมมติ นอกเหนือจากแบบสำรวจและกรณีศึกษาเหล่านี้อาจรวมอยู่ในแนวทางนี้ เนื่องจากเกี่ยวข้องกับการศึกษาบุคคลหรือองค์กรในสถานการณ์ที่ซับซ้อนในโลกแห่งความเป็นจริง

3.1.1.3 การวิจัยเชิงวิจารณ์

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

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

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

3.1.2 วัตถุประสงค์ของการวิจัย

ร่วมกับธรรมชาติของการวิจัย วัตถุประสงค์สามารถใช้เป็นแนวทางแก่ผู้วิจัยในการเลือกวิธีการวิจัยเฉพาะ ขอบเขตของโครงการวิจัยมีความสัมพันธ์อย่างใกล้ชิดกับตำแหน่งของการวิจัยที่เกี่ยวข้องกับวงจรการวิจัยซึ่งประกอบด้วยสามขั้นตอน: การสร้างทฤษฎี การทดสอบทฤษฎี และการปรับแต่งทฤษฎี ดังนั้น ตามโมเมนตัมที่เกี่ยวข้องกับวงจรการวิจัย โครงการวิจัยสามารถมีจุดประสงค์เชิงอธิบาย พรรณนา เชิงสำรวจ หรือเชิงทำนาย

3.1.2.1 การวิจัยเชิงสำรวจ

การวิจัยเชิงสำรวจมีวัตถุประสงค์เพื่อตรวจสอบหัวข้อใหม่ทั้งหมดและกำหนดคำถามและสมมติฐานสำหรับการวิจัยในอนาคต การวิจัยประเภทนี้ใช้ในการสร้างทฤษฎีเพื่อให้ได้ข้อมูลอ้างอิงเบื้องต้นในพื้นที่ใหม่ โดยปกติแล้วจะใช้วิธีการวิจัยเชิงคุณภาพ เช่น กรณีศึกษาหรือการศึกษาปรากฏการณ์วิทยา

อย่างไรก็ตาม ยังเป็นไปได้ที่จะใช้เทคนิคเชิงปริมาณ เช่น การสำรวจเชิงสำรวจหรือการทดลอง

3.1.3.3 การค้นหาเชิงพรรณนา

การวิจัยเชิงพรรณนาได้รับการออกแบบเพื่อวิเคราะห์และอธิบายรายละเอียดเกี่ยวกับสถานการณ์เฉพาะหรือแนวปฏิบัติขององค์กร สิ่งนี้เหมาะสำหรับการสร้างทฤษฎีและยังสามารถใช้เพื่อยืนยันหรือท้าทายสมมติฐาน การวิจัยเชิงพรรณนามักเกี่ยวข้องกับการใช้การวัดและตัวอย่าง วิธีการวิจัยที่เหมาะสม ได้แก่ การสำรวจและการวิเคราะห์ภูมิหลัง

3.1.2.3 การวิจัยเชิงอธิบาย

การวิจัยเชิงอธิบายพยายามอธิบายว่าทำไมสิ่งต่างๆ จึงเกิดขึ้น มันสร้างจากข้อเท็จจริงที่ได้รับการศึกษาแล้วและพยายามค้นหาสาเหตุของข้อเท็จจริงเหล่านั้น
ดังนั้น การวิจัยเชิงอธิบายจึงมักสร้างขึ้นจากการวิจัยเชิงสำรวจหรือเชิงพรรณนา และเป็นส่วนเสริมของการทดสอบและการปรับแต่งทฤษฎี การวิจัยเชิงอธิบายมักใช้กรณีศึกษาหรือวิธีการวิจัยแบบสำรวจ

3.1.2.4 การวิจัยเชิงป้องกัน

การวิจัยเชิงป้องกันมีวัตถุประสงค์เพื่อทำนายเหตุการณ์และพฤติกรรมที่สังเกตได้ซึ่งกำลังศึกษาอยู่ (Marshall and Rossman 1995) การทำนายเป็นการทดสอบความจริงทางวิทยาศาสตร์มาตรฐาน การวิจัยประเภทนี้โดยทั่วไปจะใช้การสำรวจหรือการวิเคราะห์ข้อมูล ข้อมูล นักประวัติศาสตร์ (หยิน 1989)

การอภิปรายข้างต้นแสดงให้เห็นว่ามีวิธีการวิจัยที่เป็นไปได้จำนวนหนึ่งที่สามารถนำมาใช้ในการศึกษาเฉพาะได้ แต่ทั้งนี้ต้องมีวิธีการเฉพาะที่เหมาะสมกว่าวิธีอื่นสำหรับโครงการวิจัยประเภทใดประเภทหนึ่ง (Galliers 1987, Yin 1989, De Vaus 1991) ดังนั้นนักวิจัยทุกคนจำเป็นต้องประเมินจุดแข็งและจุดอ่อนของวิธีการต่างๆ อย่างรอบคอบ เพื่อจะได้นำวิธีการวิจัยที่เหมาะสมที่สุดมาใช้กับโครงการวิจัย (Jenkins 1985, Pervan and Klass 1992, Bonomia 1985, Yin 1989, Himilton and Ives 1992)

3.2. วิธีการค้นหาที่เป็นไปได้

โครงการนี้มีวัตถุประสงค์เพื่อศึกษาประสบการณ์ขององค์กรในออสเตรเลียกับ i ข้อมูล จัดเก็บด้วยการพัฒนาของ คลังข้อมูล. ตัวเลข ที่ปัจจุบันยังขาดการวิจัยในด้านคลังข้อมูลในออสเตรเลีย โครงการวิจัยนี้ยังอยู่ในช่วงทฤษฎีของวงจรการวิจัยและมีวัตถุประสงค์เชิงสำรวจ การสำรวจประสบการณ์ในองค์กรของออสเตรเลียที่ใช้คลังข้อมูลจำเป็นต้องตีความสังคมจริง ดังนั้นสมมติฐานทางปรัชญาที่เป็นรากฐานของโครงการวิจัยจึงเป็นไปตามการตีความแบบดั้งเดิม

หลังจากตรวจสอบวิธีการที่มีอยู่อย่างเข้มงวดแล้ว วิธีการวิจัยที่เป็นไปได้สองวิธีได้รับการระบุ: การสำรวจและกรณีศึกษา ซึ่งสามารถใช้สำหรับการวิจัยเชิงสำรวจ (Shanks et al. 1993) Galliers (1992) ระบุถึงความเหมาะสมของวิธีการทั้งสองนี้สำหรับการศึกษาเฉพาะนี้ในอนุกรมวิธานฉบับปรับปรุงของเขา โดยกล่าวว่าวิธีการเหล่านี้เหมาะสำหรับการสร้างทฤษฎี ส่วนย่อยสองส่วนต่อไปนี้จะกล่าวถึงรายละเอียดแต่ละวิธี

3.2.1 วิธีการวิจัยเชิงสำรวจ

วิธีการวิจัยเชิงสำรวจมาจากวิธีการสำรวจสำมะโนโบราณ การสำรวจสำมะโนเป็นการรวบรวมข้อมูลจากประชากรทั้งหมด วิธีนี้มีราคาแพงและไม่สามารถทำได้โดยเฉพาะอย่างยิ่งหากมีประชากรจำนวนมาก ดังนั้น เมื่อเปรียบเทียบกับการสำรวจสำมะโนประชากรแล้ว การสำรวจมักมุ่งเน้นไปที่การรวบรวมข้อมูลสำหรับจำนวนเล็กน้อยหรือกลุ่มตัวอย่างของตัวแทนประชากร (Fowler 1988, Neuman 1994) ตัวอย่างสะท้อนถึงจำนวนประชากรที่ดึงออกมา โดยมีระดับความแม่นยำที่แตกต่างกันไป ขึ้นอยู่กับโครงสร้าง ขนาด และวิธีการเลือกตัวอย่างที่ใช้ (Fowler 1988, Babbie 1982, Neuman 1994)

วิธีการสำรวจหมายถึง "ภาพรวมของการปฏิบัติ สถานการณ์ หรือมุมมอง ณ เวลาใดเวลาหนึ่ง ซึ่งดำเนินการโดยใช้แบบสอบถามหรือการสัมภาษณ์ ซึ่งการอนุมานอาจเป็น
ที่สร้างขึ้น” (Galliers 1992:153) [การถ่ายภาพสแนปช็อตของการปฏิบัติ สถานการณ์ หรือมุมมอง ณ เวลาใดเวลาหนึ่ง ถ่ายโดยใช้แบบสอบถามหรือการสัมภาษณ์ ซึ่งสามารถทำการอนุมานได้] การสำรวจเกี่ยวข้องกับการรวบรวมข้อมูลเกี่ยวกับแง่มุมบางประการของการศึกษาจากผู้เข้าร่วมจำนวนหนึ่งโดยการถามคำถาม (Fowler 1988) แบบสอบถามและการสัมภาษณ์เหล่านี้ ซึ่งรวมถึงการสัมภาษณ์ทางโทรศัพท์แบบตัวต่อตัวและการสัมภาษณ์แบบมีโครงสร้าง เป็นเทคนิคการรวบรวมเช่นกัน ข้อมูล ใช้ในการสำรวจ (Blalock 1970, Nachmias and Nachmias 1976, Fowler 1988) สามารถใช้การสังเกตและการวิเคราะห์ได้ (Gable 1994) จากวิธีการสะสมพระทั้งหมดนี้ ข้อมูลการใช้แบบสอบถามเป็นเทคนิคที่ได้รับความนิยมมากที่สุดเพราะช่วยให้มั่นใจได้ว่า ข้อมูล

ที่รวบรวมมีโครงสร้างและรูปแบบดังนั้นจึงอำนวยความสะดวกในการจำแนกข้อมูล (Hwang 1987, de Vaus 1991)

ในการวิเคราะห์ i ข้อมูลกลยุทธ์การสอบสวนมักใช้เทคนิคเชิงปริมาณ เช่น การวิเคราะห์ทางสถิติ แต่ก็สามารถใช้เทคนิคเชิงคุณภาพได้เช่นกัน (Galliers 1992, Pervan

และ Klass 1992, Gable 1994) โดยปกติแล้วฉัน ข้อมูล ที่รวบรวมมาใช้เพื่อวิเคราะห์การกระจายตัวและรูปแบบของการเชื่อมโยง (Fowler 1988)

แม้ว่าการสำรวจโดยทั่วไปจะเหมาะสมสำหรับการวิจัยที่เกี่ยวข้องกับคำถาม 'อะไร' (อะไร) หรือได้มาจากสิ่งนั้น เช่น 'เท่าไหร่' และ 'เท่าไหร่' พวกเขาสามารถถามผ่านคำถาม 'ทำไม' (Sonquist and Dunkelberg 1977, Yin 1989) จากข้อมูลของ Sonquist และ Dunkelberg (1977) การวิจัยเชิงสอบถามมุ่งเป้าไปที่สมมติฐานที่ท้าทาย การประเมินโครงการ การอธิบายประชากร และการพัฒนาแบบจำลองพฤติกรรมของมนุษย์ นอกจากนี้ แบบสำรวจยังสามารถใช้เพื่อศึกษาความคิดเห็น เงื่อนไข ความคิดเห็น ลักษณะเฉพาะ ความคาดหวังของประชากร และแม้กระทั่งพฤติกรรมในอดีตหรือปัจจุบัน (Neuman 1994)

แบบสำรวจช่วยให้ผู้วิจัยค้นพบความสัมพันธ์ระหว่างประชากร และผลลัพธ์ที่ได้มักจะเป็นข้อมูลทั่วไปมากกว่าวิธีอื่นๆ (Sonquist and Dunkelberg 1977, Gable 1994) การสำรวจช่วยให้นักวิจัยสามารถครอบคลุมพื้นที่ทางภูมิศาสตร์ที่ใหญ่ขึ้นและเข้าถึงผู้ตอบแบบสอบถามจำนวนมาก (Blalock 1970, Sonquist และ Dunkelberg 1977, Hwang and Lin 1987, Gable 1994, Neuman 1994) สุดท้ายนี้ การสำรวจสามารถให้ข้อมูลที่ไม่มีในที่อื่นหรือในรูปแบบที่จำเป็นสำหรับการวิเคราะห์ (Fowler 1988)

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

การศึกษา (Yin 1989, de Vaus 1991, Gable 1994, Denscombe 1998) ข้อเสียอีกประการหนึ่งคือ การดำเนินการสำรวจอาจมีค่าใช้จ่ายสูงมากในแง่ของเวลาและทรัพยากร โดยเฉพาะอย่างยิ่งหากเกี่ยวข้องกับการสัมภาษณ์แบบตัวต่อตัว (Fowler 1988)

3.2.2. วิธีวิจัยแบบสืบเสาะ

วิธีการวิจัยแบบสืบเสาะเกี่ยวข้องกับการศึกษาเชิงลึกของสถานการณ์เฉพาะภายในบริบทโลกแห่งความเป็นจริงในช่วงเวลาที่กำหนด โดยไม่มีการแทรกแซงจากผู้วิจัย (Shanks & C. 1993, Eisenhardt 1989, Jenkins 1985) โดยหลักแล้ววิธีนี้ใช้เพื่ออธิบายความสัมพันธ์ระหว่างตัวแปรที่กำลังศึกษาในสถานการณ์เฉพาะ (Galliers 1992) การสืบสวนอาจเกี่ยวข้องกับกรณีเดียวหรือหลายกรณี ขึ้นอยู่กับปรากฏการณ์ที่วิเคราะห์ (Franz and Robey 1987, Eisenhardt 1989, Yin 1989)

วิธีการวิจัยเชิงสอบถาม หมายถึง “การสอบถามเชิงประจักษ์ที่ศึกษาปรากฏการณ์ร่วมสมัยภายในบริบทที่แท้จริงของมัน โดยใช้แหล่งข้อมูลหลายแหล่งที่รวบรวมจากหนึ่งหรือหลายเอนทิตี เช่น บุคคล กลุ่ม หรือองค์กร” (Yin 1989) ไม่มีการแบ่งแยกที่ชัดเจนระหว่างปรากฏการณ์และบริบทของมัน และไม่มีการควบคุมการทดลองหรือการบิดเบือนตัวแปร (Yin 1989, Benbasat et al. 1987)

เทคนิคการสะสมพระมีหลากหลาย ข้อมูล ที่สามารถนำไปใช้ในวิธีการสืบค้น ซึ่งรวมถึงการสังเกตโดยตรง การทบทวนบันทึกเอกสารสำคัญ แบบสอบถาม การทบทวนเอกสาร และการสัมภาษณ์แบบมีโครงสร้าง มีเทคนิคการเก็บเกี่ยวที่หลากหลาย ข้อมูลการสืบสวนทำให้นักวิจัยสามารถจัดการกับทั้งสองอย่างได้ ข้อมูล เชิงคุณภาพและเชิงปริมาณในเวลาเดียวกัน (Bonoma 1985, Eisenhardt 1989, Yin 1989, Gable 1994) เช่นเดียวกับกรณีของวิธีการสำรวจ ผู้วิจัยเชิงสำรวจจะทำหน้าที่เป็นผู้สังเกตการณ์หรือนักวิจัย และไม่ใช่ผู้เข้าร่วมในองค์กรที่กำลังศึกษาอยู่

Benbasat และคณะ (1987) ยืนยันว่าวิธีการสืบค้นมีความเหมาะสมเป็นพิเศษสำหรับการสร้างทฤษฎีการวิจัยซึ่งเริ่มต้นด้วยคำถามการวิจัยและต่อด้วยการศึกษา

ของทฤษฎีในระหว่างกระบวนการรวบรวม ข้อมูล. ยังเหมาะสมกับเวทีอีกด้วย

ของการสร้างทฤษฎี Franz และ Robey (1987) แนะนำว่าวิธีการสืบค้นยังสามารถใช้สำหรับขั้นตอนทฤษฎีที่ซับซ้อนได้ ในกรณีนี้ ตามหลักฐานที่รวบรวมได้ ทฤษฎีหรือสมมติฐานที่กำหนดจะได้รับการตรวจสอบหรือหักล้าง นอกจากนี้ แบบสำรวจยังเหมาะสำหรับการวิจัยเกี่ยวกับคำถาม 'อย่างไร' หรือ 'ทำไม' (Yin 1989)

เมื่อเปรียบเทียบกับวิธีการอื่นๆ การสำรวจช่วยให้ผู้วิจัยสามารถรวบรวมข้อมูลที่จำเป็นได้อย่างละเอียดมากขึ้น (Galliers 1992, Shanks et al. 1993) นอกจากนี้ การสำรวจยังช่วยให้ผู้วิจัยเข้าใจธรรมชาติและความซับซ้อนของกระบวนการที่ศึกษา (Benbasat et al. 1987)

มีข้อเสียเปรียบหลักสี่ประการที่เกี่ยวข้องกับวิธีการสำรวจ ประการแรกคือการไม่มีการหักเงินที่ได้รับการควบคุม อัตวิสัยของผู้วิจัยสามารถเปลี่ยนแปลงผลลัพธ์และข้อสรุปของการศึกษาได้ (Yin 1989) ข้อเสียประการที่สองคือขาดการควบคุมการสังเกต ต่างจากวิธีการทดลองตรงที่นักวิจัยสอบถามไม่สามารถควบคุมปรากฏการณ์ที่ศึกษาได้เมื่อถูกตรวจสอบในบริบทตามธรรมชาติ (Gable 1994) ข้อเสียประการที่สามคือการขาดความสามารถในการจำลองแบบ เนื่องจากผู้วิจัยไม่น่าจะสังเกตเห็นเหตุการณ์เดียวกัน และไม่สามารถยืนยันผลการศึกษาเฉพาะเรื่องได้ (Lee 1989) ท้ายที่สุด เนื่องจากผลที่ตามมาจากไม่สามารถทำซ้ำได้ จึงเป็นการยากที่จะสรุปผลลัพธ์ที่ได้จากการสืบสวนอย่างน้อยหนึ่งครั้ง (Galliers 1992, Shanks et al 1993) อย่างไรก็ตาม ปัญหาทั้งหมดนี้ไม่สามารถผ่านพ้นไปได้ และในความเป็นจริง ผู้วิจัยสามารถลดขนาดลงได้โดยการใช้การกระทำที่เหมาะสม (Lee 1989)

3.3. ปรับระเบียบวิธีวิจัย บุญธรรม

จากวิธีวิจัยที่เป็นไปได้ XNUMX วิธีในการศึกษาครั้งนี้ ถือว่าวิธีสำรวจมีความเหมาะสมที่สุด การสอบสวนถูกยกเลิกหลังจากการพิจารณาอย่างรอบคอบเกี่ยวกับสิ่งที่เกี่ยวข้อง

ข้อดีและจุดอ่อน ความเหมาะสมหรือไม่เหมาะสมของแต่ละวิธีสำหรับการศึกษานี้มีดังต่อไปนี้

3.3.1. วิธีการวิจัยที่ไม่เหมาะสม ของการสอบถาม

วิธีการสอบถามต้องมีการศึกษาเชิงลึกเกี่ยวกับสถานการณ์เฉพาะภายในองค์กรตั้งแต่หนึ่งองค์กรขึ้นไปในช่วงเวลาหนึ่ง (Eisenhardt 1989) ในกรณีนี้ระยะเวลาอาจเกินกรอบเวลาที่กำหนดสำหรับการศึกษาครั้งนี้ เหตุผลอีกประการหนึ่งที่ไม่ใช้วิธีการสำรวจคือผลลัพธ์อาจประสบจากการขาดความเข้มงวด (Yin 1989) ความส่วนตัวของผู้วิจัยสามารถมีอิทธิพลต่อผลลัพธ์และข้อสรุปได้ อีกเหตุผลหนึ่งก็คือ วิธีนี้เหมาะกว่าสำหรับการวิจัยคำถามประเภท 'อย่างไร' หรือ 'ทำไม' (Yin 1989) ในขณะที่คำถามวิจัยสำหรับการศึกษาครั้งนี้เป็นคำถามประเภท 'อะไร' สุดท้ายแต่ไม่ท้ายสุด เป็นเรื่องยากที่จะสรุปข้อค้นพบจากการสืบสวนเพียงครั้งเดียวหรือสองสามครั้ง (Galliers 1992, Shanks et al. 1993) จากเหตุผลนี้ จึงไม่ได้เลือกวิธีการวิจัยเชิงสำรวจเนื่องจากไม่เหมาะสมกับการศึกษาครั้งนี้

3.3.2. ความสะดวกของวิธีการค้นหาของ ตรวจสอบ

เมื่อดำเนินการวิจัยนี้ องค์กรของออสเตรเลียยังไม่ยอมรับแนวทางปฏิบัติด้านคลังข้อมูลอย่างกว้างขวาง ดังนั้นจึงไม่มีข้อมูลมากนักเกี่ยวกับการนำไปปฏิบัติภายในองค์กรของออสเตรเลีย ข้อมูลที่มีอยู่มาจากองค์กรที่ได้ดำเนินการหรือใช้ คลังข้อมูล. ในกรณีนี้ วิธีการวิจัยเชิงสำรวจมีความเหมาะสมที่สุดเนื่องจากช่วยให้ได้รับข้อมูลที่ไม่มีอยู่ในที่อื่นหรืออยู่ในรูปแบบที่จำเป็นสำหรับการวิเคราะห์ (Fowler 1988) นอกจากนี้ วิธีการวิจัยเชิงสำรวจยังช่วยให้ผู้วิจัยได้รับข้อมูลเชิงลึกที่ดีเกี่ยวกับแนวทางปฏิบัติ สถานการณ์ หรือมุมมองในช่วงเวลาใดเวลาหนึ่ง (Galliers 1992, Denscombe 1998) จำเป็นต้องมีภาพรวมเพื่อเพิ่มความรู้เกี่ยวกับประสบการณ์คลังข้อมูลของออสเตรเลีย

นอกจากนี้ Sonquist และ Dunkelberg (1977) ระบุว่าผลการวิจัยเชิงสำรวจมีลักษณะทั่วไปมากกว่าวิธีอื่นๆ

3.4. การออกแบบการวิจัยเชิงสำรวจ

การสำรวจแนวปฏิบัติด้านคลังข้อมูลดำเนินการในปี พ.ศ. 1999 ประชากรเป้าหมายถูกสร้างขึ้นโดยองค์กรของออสเตรเลียที่สนใจการศึกษาด้านคลังข้อมูล เนื่องจากพวกเขาอาจได้รับแจ้งเกี่ยวกับ ข้อมูล ที่พวกเขาจัดเก็บและสามารถให้ข้อมูลที่เป็นประโยชน์สำหรับการศึกษานี้ได้ ประชากรเป้าหมายได้รับการระบุผ่านการสำรวจเบื้องต้นของสมาชิกชาวออสเตรเลียทั้งหมดของ Data Warehousing Institute (Tdwi-aap) เนื้อหาในส่วนนี้จะกล่าวถึงการออกแบบขั้นตอนการวิจัยเชิงประจักษ์ของการศึกษาวิจัยนี้

3.4.1. เทคนิคการเก็บเกี่ยว ข้อมูล

จากเทคนิคสามวิธีที่มักใช้ในการวิจัยเชิงสำรวจ (เช่น แบบสอบถามทางไปรษณีย์ การสัมภาษณ์ทางโทรศัพท์ และการสัมภาษณ์ส่วนตัว) (Nachmias 1976, Fowler 1988, de Vaus 1991) ได้มีการนำแบบสอบถามทางไปรษณีย์มาใช้ในการศึกษานี้ เหตุผลแรกในการเลือกใช้อย่างหลังก็คือ มันสามารถเข้าถึงประชากรที่กระจัดกระจายทางภูมิศาสตร์ได้ (Blalock 1970, Nachmias and Nachmias 1976, Hwang and Lin 1987, de Vaus 1991, Gable 1994) ประการที่สอง แบบสอบถามทางไปรษณีย์เหมาะสำหรับผู้เข้าร่วมที่มีการศึกษาสูง (Fowler 1988) แบบสอบถามทางไปรษณีย์สำหรับการศึกษานี้ส่งถึงผู้สนับสนุนโครงการคลังข้อมูล ผู้อำนวยการ และ/หรือผู้จัดการโครงการ ประการที่สาม แบบสอบถามทางไปรษณีย์มีความเหมาะสมเมื่อมีรายชื่อผู้รับจดหมายที่ปลอดภัย (Salant และ Dilman 1994) ในกรณีนี้ TDWI สมาคมคลังข้อมูลที่เชื่อถือได้ได้จัดเตรียมรายชื่ออีเมลของสมาชิกในออสเตรเลีย ข้อดีอีกประการหนึ่งของแบบสอบถามทางไปรษณีย์มากกว่าแบบสอบถามทางโทรศัพท์หรือการสัมภาษณ์ส่วนตัวคือช่วยให้ผู้ตอบตอบตอบได้แม่นยำยิ่งขึ้น โดยเฉพาะอย่างยิ่งเมื่อผู้ตอบต้องอ่านบันทึกหรืออภิปรายคำถามกับบุคคลอื่น (Fowler 1988)

ข้อเสียที่อาจเกิดขึ้นอาจต้องใช้เวลาในการทำแบบสอบถามทางไปรษณีย์ โดยปกติแล้ว การสำรวจทางไปรษณีย์จะดำเนินการตามลำดับนี้: จดหมายทางไปรษณีย์ รอการตอบกลับ และส่งการยืนยัน (Fowler 1988, Bainbridge 1989) ดังนั้นเวลาทั้งหมดอาจนานกว่าเวลาที่จำเป็นสำหรับการสัมภาษณ์ส่วนตัวหรือการสัมภาษณ์ทางโทรศัพท์ อย่างไรก็ตาม สามารถทราบเวลารวมได้ล่วงหน้า (ฟาวเลอร์ 1988, เดนส์คอมบ์ 1998) เวลาที่ใช้ในการสัมภาษณ์ส่วนตัวไม่สามารถทราบล่วงหน้าได้ เนื่องจากการสัมภาษณ์แต่ละครั้งจะแตกต่างกันไป (Fowler 1988) การสัมภาษณ์ทางโทรศัพท์สามารถทำได้เร็วกว่าแบบสอบถามทางไปรษณีย์และการสัมภาษณ์ส่วนตัว แต่อาจมีอัตราการไม่ตอบกลับสูง เนื่องจากคนบางคนไม่ว่าง (Fowler 1988) นอกจากนี้ การสัมภาษณ์ทางโทรศัพท์โดยทั่วไปยังจำกัดอยู่เพียงรายการคำถามสั้นๆ (Bainbridge 1989)

จุดอ่อนอีกประการหนึ่งของแบบสอบถามทางไปรษณีย์คืออัตราการไม่ตอบกลับที่สูง (Fowler 1988, Bainbridge 1989, Neuman 1994) อย่างไรก็ตาม มีการใช้มาตรการตอบโต้โดยการเชื่อมโยงการศึกษานี้กับสถาบันคลังข้อมูลที่เชื่อถือได้ (เช่น TDWI) (Bainbridge 1989, Neuman 1994) ซึ่งส่งจดหมายเตือนสองฉบับไปยังผู้ที่ไม่ตอบกลับ (Fowler 1988, Neuman 1994) และยังรวมถึงจดหมายเพิ่มเติมอีกฉบับด้วย อธิบายวัตถุประสงค์ของการศึกษา (Neuman 1994)

3.4.2. หน่วยการวิเคราะห์

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

3.4.3. ตัวอย่างการสำรวจ

“รายชื่อผู้รับจดหมาย” ของผู้เข้าร่วมการสำรวจได้มาจาก TDWI จากรายการนี้ มีการคัดเลือกองค์กรของออสเตรเลีย 3000 แห่งเป็นพื้นฐานในการสุ่มตัวอย่าง จดหมายเพิ่มเติมอธิบายโครงการและวัตถุประสงค์ของการสำรวจ พร้อมด้วยกระดาษคำตอบและซองชำระเงินล่วงหน้าสำหรับการส่งคืนแบบสอบถามที่กรอกเสร็จแล้วถูกส่งไปยังกลุ่มตัวอย่าง จากองค์กร 3000 แห่ง มี 198 แห่งตกลงที่จะเข้าร่วมในการศึกษาวิจัยนี้ คาดว่าจะได้รับคำตอบจำนวนเล็กน้อยเช่นนี้ Dato องค์กรในออสเตรเลียจำนวนมากที่ยอมรับหรือปรับใช้กลยุทธ์คลังข้อมูลภายในองค์กรของตน ดังนั้นประชากรเป้าหมายในการศึกษาครั้งนี้จึงมีเพียง 198 องค์กรเท่านั้น

3.4.4. เนื้อหาของแบบสอบถาม

โครงสร้างของแบบสอบถามขึ้นอยู่กับแบบจำลองคลังข้อมูลของ Monash (ตามที่กล่าวไว้ก่อนหน้านี้ในส่วนที่ 2.3) เนื้อหาของแบบสอบถามอยู่บนพื้นฐานของการวิเคราะห์วรรณกรรมที่นำเสนอในบทที่ 2 สำเนาของแบบสอบถามที่ส่งไปยังผู้เข้าร่วมการสำรวจสามารถพบได้ในภาคผนวก B แบบสอบถามประกอบด้วยหกส่วน ซึ่งเป็นไปตามขั้นตอนของแบบจำลองที่ครอบคลุม หกย่อหน้าต่อไปนี้จะสรุปเนื้อหาของแต่ละส่วนโดยย่อ

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

ส่วน B: จุดเริ่มต้น
คำถามในส่วนนี้เกี่ยวข้องกับงานเริ่มต้นคลังข้อมูล คำถามที่ถูกถามเกี่ยวกับผู้ริเริ่มโครงการ ผู้ค้ำประกัน ทักษะและความรู้ที่จำเป็น วัตถุประสงค์การพัฒนาคลังข้อมูล และความคาดหวังของผู้ใช้ปลายทาง

หมวด C: การออกแบบ
ส่วนนี้ประกอบด้วยคำถามที่เกี่ยวข้องกับกิจกรรมการวางแผน คลังข้อมูล. โดยเฉพาะอย่างยิ่ง คำถามเกี่ยวกับขอบเขตการดำเนินการ ระยะเวลาของโครงการ ต้นทุนของโครงการ และการวิเคราะห์ต้นทุน/ผลประโยชน์

หมวด D: การพัฒนา
ในส่วนการพัฒนามีคำถามเกี่ยวกับกิจกรรมการพัฒนาของ คลังข้อมูล: การรวบรวมข้อกำหนดของผู้ใช้ปลายทาง แหล่งที่มาของ ข้อมูลแบบจำลองเชิงตรรกะของ ข้อมูลต้นแบบ การวางแผนกำลังการผลิต สถาปัตยกรรมทางเทคนิค และการเลือกเครื่องมือพัฒนาคลังข้อมูล

หมวด E: การดำเนินการ
คำถามการดำเนินงานที่เกี่ยวข้องกับการดำเนินงานและการขยายของ คลังข้อมูลว่าจะพัฒนาไปอย่างไรในระยะต่อไปของการพัฒนา ที่นั่น คุณภาพของข้อมูลกลยุทธ์การรีเฟรชของ ข้อมูลรายละเอียดของ ข้อมูล, ความสามารถในการปรับขนาดของ คลังข้อมูล และประเด็นด้านความปลอดภัยของ คลังข้อมูล เป็นหนึ่งในประเภทของคำถามที่ถาม

หมวด F: การพัฒนา
ส่วนนี้มีคำถามที่เกี่ยวข้องกับการใช้ คลังข้อมูล โดยผู้ใช้ปลายทาง ผู้วิจัยมีความสนใจในวัตถุประสงค์และประโยชน์ของการ คลังข้อมูลกลยุทธ์การทบทวนและการฝึกอบรมที่นำมาใช้และกลยุทธ์การควบคุมของ คลังข้อมูล เป็นลูกบุญธรรม

3.4.5. อัตราการตอบสนอง

แม้ว่าการสำรวจทางไปรษณีย์จะถูกวิพากษ์วิจารณ์ว่ามีอัตราการตอบกลับต่ำ แต่ก็มีมาตรการเพื่อเพิ่มอัตราการส่งคืน (ตามที่กล่าวไว้ก่อนหน้านี้ในส่วน 3.4.1) คำว่า 'อัตราการตอบกลับ' หมายถึงเปอร์เซ็นต์ของคนในกลุ่มตัวอย่างการสำรวจเฉพาะที่ตอบแบบสอบถาม (Denscombe 1998) สูตรต่อไปนี้ใช้ในการคำนวณอัตราการตอบกลับสำหรับการศึกษานี้:

จำนวนคนที่ตอบ
อัตราการตอบกลับ = ——————————————————————————– X 100 จำนวนแบบสอบถามที่ส่งทั้งหมด

3.4.6. การทดสอบนักบิน

ก่อนส่งแบบสอบถามไปยังกลุ่มตัวอย่าง คำถามจะถูกตรวจสอบโดยการทดสอบนำร่อง ตามที่ Luck and Rubin (1987), Jackson (1988) และ de Vaus (1991) แนะนำ วัตถุประสงค์ของการทดสอบนำร่องคือการเปิดเผยสำนวนและคำถามที่น่าอึดอัดใจและคลุมเครือซึ่งยากต่อการตีความ เพื่อชี้แจงคำจำกัดความและคำศัพท์ที่ใช้ และเพื่อระบุเวลาโดยประมาณที่ต้องใช้ในการตอบแบบสอบถาม (Warwick and Lininger 1975, Jackson 1988, Salant และดิลมาน 1994) การทดสอบนำร่องดำเนินการโดยการเลือกวิชาที่มีลักษณะคล้ายกับวิชาสุดท้าย ตามที่ Davis e. แนะนำ โคเซนซา (1993) ในการศึกษานี้ มีการเลือกผู้เชี่ยวชาญด้านคลังข้อมูลจำนวน XNUMX รายเป็นหัวข้อนำร่อง หลังจากการทดสอบนำร่องแต่ละครั้ง มีการแก้ไขที่จำเป็น จากการทดสอบนำร่องที่ดำเนินการ ผู้เข้าร่วมมีส่วนร่วมในการปรับแต่งและรีเซ็ตเวอร์ชันสุดท้ายของแบบสอบถาม

3.4.7. วิธีวิเคราะห์โดย ให้

I ข้อมูล ของการสำรวจที่รวบรวมจากแบบสอบถามปลายปิดวิเคราะห์โดยใช้โปรแกรมโปรแกรมทางสถิติที่เรียกว่า SPSS คำตอบจำนวนมากถูกวิเคราะห์โดยใช้สถิติเชิงพรรณนา แบบสอบถามจำนวนหนึ่งถูกส่งคืนไม่สมบูรณ์ สิ่งเหล่านี้ได้รับการปฏิบัติด้วยความเอาใจใส่มากขึ้นเพื่อให้แน่ใจว่าฉัน ข้อมูล การหายไปไม่ได้เป็นผลมาจากข้อผิดพลาดในการป้อนข้อมูล แต่เนื่องจากคำถามไม่เหมาะสำหรับผู้ลงทะเบียน หรือผู้ลงทะเบียนตัดสินใจที่จะไม่ตอบคำถามเฉพาะเจาะจงอย่างน้อยหนึ่งข้อ คำตอบที่ขาดหายไปเหล่านี้ถูกละเว้นในระหว่างการวิเคราะห์ ข้อมูล และถูกเข้ารหัสเป็น '- 9' เพื่อให้แน่ใจว่าจะถูกแยกออกจากกระบวนการวิเคราะห์

ในการเตรียมแบบสอบถาม คำถามปิดจะถูกกำหนดไว้ล่วงหน้าโดยกำหนดตัวเลขให้กับแต่ละตัวเลือก แล้วจึงนำเบอร์ไปเตรียมการ ข้อมูล ระหว่างการวิเคราะห์ (Denscombe 1998, Sapsford และ Jupp 1996) ตัวอย่างเช่น มีหกตัวเลือกที่ระบุไว้ในคำถามที่ 1 ของส่วน B: คณะกรรมการ ผู้บริหารระดับสูง แผนกไอที หน่วยธุรกิจ ที่ปรึกษา และอื่นๆ ในไฟล์ของ ข้อมูล ของ SPSS ตัวแปรถูกสร้างขึ้นเพื่อระบุ 'ผู้ริเริ่มโครงการ' โดยมีป้ายค่า 1 ป้าย: '2' สำหรับ 'คณะกรรมการ', '1' สำหรับ 'ผู้บริหารระดับสูง' และอื่นๆ ถนน การใช้มาตราส่วน Likertin ในคำถามแบบปิดบางข้อยังช่วยให้ระบุตัวตนได้อย่างง่ายดายด้วยการใช้ค่าตัวเลขที่สอดคล้องกันที่ป้อนลงใน SPSS สำหรับคำถามที่มีคำตอบโดยสังเขปซึ่งไม่ได้แยกจากกัน แต่ละตัวเลือกจะถือเป็นตัวแปรเดียวที่มีป้ายกำกับค่าสองป้าย: '2' สำหรับ 'ทำเครื่องหมาย' และ 'XNUMX' สำหรับ 'ไม่ได้ทำเครื่องหมาย'

คำถามเปิดได้รับการปฏิบัติแตกต่างจากคำถามปิด คำตอบสำหรับคำถามเหล่านี้ไม่ได้ถูกป้อนลงใน SPSS แต่กลับถูกวิเคราะห์ด้วยมือ การใช้คำถามประเภทนี้ช่วยให้เราได้รับข้อมูลเกี่ยวกับความคิดที่แสดงออกอย่างอิสระและประสบการณ์ส่วนตัวของผู้ตอบแบบสอบถาม (Bainbridge 1989, Denscombe 1998) หากเป็นไปได้ จะมีการจำแนกประเภทของคำตอบ

สำหรับการวิเคราะห์ของ ข้อมูลใช้วิธีการวิเคราะห์ทางสถิติง่ายๆ เช่น ความถี่ของการตอบสนอง ค่าเฉลี่ย ส่วนเบี่ยงเบนมาตรฐาน และค่ามัธยฐาน (Argyrous 1996, Denscombe 1998)
การทดสอบแกมมาทำงานได้ดีในการรับการวัดเชิงปริมาณของความสัมพันธ์ระหว่าง ข้อมูล อันดับ (Norusis 1983, Argyrous 1996) การทดสอบเหล่านี้มีความเหมาะสมเนื่องจากลำดับที่ใช้ไม่ได้มีหลายประเภทและสามารถแสดงเป็นตารางได้ (Norusis 1983)

3.5 ซอมมาริโอ

ในบทนี้ จะกล่าวถึงวิธีการวิจัยและการออกแบบที่นำมาใช้สำหรับการศึกษานี้

การเลือกวิธีการวิจัยที่เหมาะสมที่สุดสำหรับการศึกษาเฉพาะเรื่องจะนำมาพิจารณาด้วย
การพิจารณากฎเกณฑ์จำนวนหนึ่ง รวมถึงลักษณะและประเภทของการวิจัย ตลอดจนข้อดีและจุดอ่อนของแต่ละวิธีที่เป็นไปได้ (Jenkins 1985, Benbasat et al. 1097, Galliers and Land 1987, yin 1989, Hamilton and ives 1992, Galliers 1992, นอยมาน 1994) เนื่องจากขาดความรู้และทฤษฎีที่มีอยู่เกี่ยวกับการนำคลังข้อมูลมาใช้ในออสเตรเลีย การศึกษาวิจัยนี้จึงจำเป็นต้องมีวิธีการวิจัยเชิงตีความที่มีความสามารถในการสำรวจเพื่อสำรวจประสบการณ์ขององค์กรในออสเตรเลีย วิธีการวิจัยที่เลือกได้รับเลือกเพื่อรวบรวมข้อมูลเกี่ยวกับการปรับใช้แนวคิดคลังข้อมูลโดยองค์กรของออสเตรเลีย เลือกแบบสอบถามทางไปรษณีย์เป็นเทคนิคการรวบรวม ข้อมูล. เหตุผลของวิธีการวิจัยและเทคนิคการรวบรวม ข้อมูล จะถูกเลือกไว้ในบทนี้ นอกจากนี้ ยังได้อภิปรายเกี่ยวกับหน่วยการวิเคราะห์ กลุ่มตัวอย่างที่ใช้ เปอร์เซ็นต์ของคำตอบ เนื้อหาของแบบสอบถาม การทดสอบก่อนของแบบสอบถาม และวิธีการวิเคราะห์ของแบบสอบถาม ข้อมูล.

การออกแบบไฟล์ คลังข้อมูล:

การรวมความสัมพันธ์ของเอนทิตีและการสร้างแบบจำลองมิติ

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

ตรวจสอบในกรณีศึกษาและระบุถึงผลกระทบที่สำคัญหลายประการกับผู้ปฏิบัติงาน

คลังข้อมูล

Un คลังข้อมูล โดยปกติแล้วจะถูกกำหนดให้เป็น "การรวบรวมข้อมูลเชิงหัวเรื่อง บูรณาการ แปรผันตามเวลา และไม่ลบเลือน เพื่อสนับสนุนการตัดสินใจของฝ่ายบริหาร" (Inmon และ Hackathorn, 1994) เชิงหัวเรื่องและบูรณาการบ่งชี้ว่า คลังข้อมูล ได้รับการออกแบบมาเพื่อข้ามขอบเขตการทำงานของระบบ Legaci เพื่อเสนอมุมมองแบบบูรณาการ ข้อมูล.
ตัวแปรเวลาส่งผลกระทบต่อลักษณะทางประวัติศาสตร์หรืออนุกรมเวลาของ ข้อมูล ในไม่ คลังข้อมูลซึ่งทำให้สามารถวิเคราะห์แนวโน้มได้ ไม่ระเหย บ่งชี้ว่า คลังข้อมูล มันไม่ได้รับการอัพเดตอย่างต่อเนื่องเช่น ฐานข้อมูล ของ OLTP แต่จะมีการอัปเดตเป็นระยะด้วย ข้อมูล มาจากแหล่งภายในและภายนอก ที่ คลังข้อมูล ได้รับการออกแบบมาโดยเฉพาะสำหรับการค้นหาแทนที่จะอัปเดตความสมบูรณ์และประสิทธิภาพการทำงาน
แนวคิดในการจัดเก็บ i ข้อมูล ไม่ใช่เรื่องใหม่ แต่เป็นหนึ่งในจุดประสงค์ด้านการจัดการของ ข้อมูล ตั้งแต่อายุหกสิบเศษ (The Martin, 1982)
I คลังข้อมูล พวกเขาเสนอโครงสร้างพื้นฐาน ข้อมูล สำหรับระบบสนับสนุนการจัดการ ระบบสนับสนุนการจัดการประกอบด้วยระบบสนับสนุนการตัดสินใจ (DSS) และระบบข้อมูลผู้บริหาร (EIS) DSS คือระบบสารสนเทศที่ใช้คอมพิวเตอร์ซึ่งได้รับการออกแบบมาเพื่อปรับปรุงการตัดสินใจของมนุษย์ โดยทั่วไป EIS คือระบบการจัดส่งของ ข้อมูล ซึ่งทำให้ผู้นำธุรกิจสามารถเข้าถึงมุมมองได้อย่างง่ายดาย ข้อมูล.
สถาปัตยกรรมทั่วไปของก คลังข้อมูล ตอกย้ำบทบาทของ คลังข้อมูล ในการสนับสนุนการจัดการ พร้อมทั้งนำเสนอโครงสร้างพื้นฐาน ข้อมูล สำหรับ EIS และ DSS อัล คลังข้อมูล สามารถเข้าถึงได้โดยตรงผ่านการสอบถาม ที่ ข้อมูล รวมอยู่ใน คลังข้อมูล อยู่บนพื้นฐานของการวิเคราะห์ข้อกำหนดข้อมูลการจัดการและได้รับจากแหล่งที่มาสามแห่ง ได้แก่ ระบบเดิมภายใน ระบบเก็บข้อมูลเพื่อวัตถุประสงค์พิเศษ และแหล่งข้อมูลภายนอก ที่ ข้อมูล ในระบบเดิมภายใน สิ่งเหล่านี้มักจะซ้ำซ้อน ไม่สอดคล้องกัน คุณภาพต่ำ และจัดเก็บในรูปแบบที่แตกต่างกัน ดังนั้นจึงต้องปรับยอดและล้างข้อมูลก่อนจึงจะสามารถโหลดลงใน

คลังข้อมูล (อินมอน, 1992; McFadden, 1996) ที่ ข้อมูล มาจากระบบจัดเก็บข้อมูล ข้อมูล เฉพาะกิจและจากแหล่งที่มา ข้อมูล ภายนอกมักใช้เพื่อเพิ่ม (อัพเดต แทนที่) i ข้อมูล จากระบบเดิม

มีเหตุผลที่น่าสนใจหลายประการในการพัฒนา คลังข้อมูลซึ่งรวมถึงการตัดสินใจที่ดีขึ้นผ่านการใช้ข้อมูลเพิ่มเติมอย่างมีประสิทธิผล (Ives 1995) การสนับสนุนสำหรับการมุ่งเน้นไปที่ข้อตกลงทั้งหมด (Graham 1996) และการลดลงของ ข้อมูล สำหรับ EIS และ DSS (Graham 1996, McFadden 1996)

การศึกษาเชิงประจักษ์เมื่อเร็วๆ นี้พบว่า โดยเฉลี่ยแล้ว ผลตอบแทนจากการลงทุนสำหรับ คลังข้อมูล 401% หลังจากสามปี (Graham, 1996) อย่างไรก็ตาม การศึกษาเชิงประจักษ์อื่นๆ ของ คลังข้อมูล พบปัญหาสำคัญ ได้แก่ ความยากในการวัดและกำหนดผลประโยชน์ ขาดวัตถุประสงค์ที่ชัดเจน ประเมินวัตถุประสงค์ต่ำไป และความซับซ้อนของกระบวนการจัดเก็บผลประโยชน์ ข้อมูลโดยเฉพาะเรื่องแหล่งที่มาและความสะอาดของ ข้อมูล. การจัดเก็บผม ข้อมูล ถือได้ว่าเป็นวิธีการแก้ปัญหาการบริหารจัดการ ข้อมูล ระหว่างองค์กร การจัดการของ ข้อมูล ในฐานะทรัพยากรทางสังคม ยังคงเป็นหนึ่งในปัญหาสำคัญในการจัดการระบบข้อมูลทั่วโลกเป็นเวลาหลายปี (Brancheau et al. 1996, Galliers et al. 1994, Niederman et al. 1990, Pervan 1993)

แนวทางการจัดการที่เป็นที่นิยม ข้อมูล ในยุคแปดสิบเป็นการพัฒนาแบบจำลอง ข้อมูล ทางสังคม. แบบอย่าง ข้อมูล โซเชียลได้รับการออกแบบเพื่อให้มีพื้นฐานที่มั่นคงสำหรับการพัฒนาระบบแอปพลิเคชันใหม่และ ฐานข้อมูล และการสร้างใหม่และบูรณาการระบบเดิม (Brancheau et al.

1989, Goodhue และคณะ 1988:1992, คิมและเอเวอเรสต์ 1994) อย่างไรก็ตาม แนวทางนี้มีปัญหามากมาย โดยเฉพาะอย่างยิ่งความซับซ้อนและต้นทุนของแต่ละงาน รวมถึงการใช้เวลานานในการสร้างผลลัพธ์ที่จับต้องได้ (Beynon-Davies 1994, Earl 1993, Goodhue et al. 1992, Periasamy 1994, Shanks 1997 ).

Il คลังข้อมูล เป็นฐานข้อมูลแยกต่างหากที่อยู่ร่วมกับฐานข้อมูลเดิมแทนที่จะแทนที่ จึงทำให้คุณสามารถกำกับการบริหารจัดการของ ข้อมูล และหลีกเลี่ยงการสร้างระบบเดิมขึ้นมาใหม่ซึ่งมีค่าใช้จ่ายสูง

แนวทางที่มีอยู่ในการออกแบบข้อมูล

คลังสินค้า

กระบวนการสร้างและปรับปรุงก คลังข้อมูล ควรเข้าใจมากกว่าว่าเป็นกระบวนการวิวัฒนาการมากกว่าวงจรการพัฒนาของระบบแบบดั้งเดิม (Desio, 1995, แชงค์ส, โอดอนเนล และอาร์นอตต์ 1997a ) มีกระบวนการมากมายที่เกี่ยวข้องกับโครงการ คลังข้อมูล เช่นการเริ่มต้น การวางแผน ข้อมูลที่ได้รับจากข้อกำหนดที่ถามจากผู้จัดการบริษัท แหล่งที่มา การเปลี่ยนแปลง การทำความสะอาด ข้อมูล และการซิงโครไนซ์จากระบบเดิมและแหล่งอื่น ๆ ข้อมูล; ระบบการนำส่งที่อยู่ระหว่างการพัฒนา การตรวจสอบของ คลังข้อมูล; และความไร้สติของกระบวนการวิวัฒนาการและการสร้างก คลังข้อมูล (Stinchi, O'Donnell และ Arnott 1997b) ในบันทึกนี้ เราจะเน้นไปที่วิธีการวาด ข้อมูล เก็บไว้ในบริบทของกระบวนการอื่นๆ เหล่านี้ มีแนวทางที่นำเสนอหลายประการเกี่ยวกับสถาปัตยกรรม คลังข้อมูล ในวรรณคดี (Inmon 1994, Ives 1995, Kimball 1994 McFadden 1996) แต่ละวิธีการเหล่านี้มีการทบทวนโดยสรุปพร้อมการวิเคราะห์จุดแข็งและจุดอ่อน

แนวทางของอินมอน (1994) สำหรับ คลังข้อมูล ออกแบบ

Inmon (1994) เสนอขั้นตอนวนซ้ำ XNUMX ขั้นตอนในการออกแบบ คลังข้อมูล (ดูรูปที่ 2) ขั้นตอนแรกคือการออกแบบเทมเพลต ข้อมูล สังคมเพื่อทำความเข้าใจว่าฉันเป็นอย่างไร ข้อมูล พวกเขาสามารถบูรณาการข้ามพื้นที่การทำงานภายในองค์กรโดยการแยก ข้อมูล เก็บในพื้นที่ แบบอย่าง ข้อมูล มันถูกสร้างขึ้นมาเพื่อการจัดเก็บ ข้อมูล ที่เกี่ยวข้องกับการตัดสินใจได้แก่ ข้อมูล นักประวัติศาสตร์และรวมไปถึง ข้อมูล หักและรวมแล้ว ขั้นตอนที่สองคือการระบุสาขาวิชาสำหรับการนำไปปฏิบัติ สิ่งเหล่านี้ขึ้นอยู่กับลำดับความสำคัญที่กำหนดโดยองค์กรใดองค์กรหนึ่ง ขั้นตอนที่สามเกี่ยวข้องกับการวาดภาพ ฐานข้อมูล สำหรับสาขาวิชา ให้ใส่ใจเป็นพิเศษในการรวมรายละเอียดในระดับที่เหมาะสม Inmon แนะนำให้ใช้แบบจำลองเอนทิตีและความสัมพันธ์ ขั้นตอนที่สี่คือการระบุระบบต้นทาง ข้อมูล จำเป็นและพัฒนากระบวนการเปลี่ยนแปลงเพื่อจับภาพ ทำความสะอาด และจัดรูปแบบ i ข้อมูล.

จุดแข็งของแนวทางของอินมอนก็คือโมเดล ข้อมูล สังคมเป็นพื้นฐานสำหรับการบูรณาการของ ข้อมูล ภายในองค์กรและการวางแผนสนับสนุนการพัฒนาซ้ำของ คลังข้อมูล. ข้อบกพร่องคือความยากและต้นทุนในการออกแบบแบบจำลอง ข้อมูล สังคม ความยากในการทำความเข้าใจโมเดลของเอนทิตีและความสัมพันธ์ที่ใช้ในทั้งสองโมเดลนั้น ข้อมูล ทางสังคมและของนั้น ข้อมูล จัดเก็บตามสาขาวิชาและความเหมาะสมของ ข้อมูล ของการวาดภาพของ คลังข้อมูล เพื่อการตระหนักถึง ฐานข้อมูล สัมพันธ์กันแต่ไม่ใช่เพื่อ ฐานข้อมูล หลายมิติ

Ives' (1995) แนวทางสู่ คลังข้อมูล ออกแบบ

Ives (1995) เสนอแนวทางสี่ขั้นตอนในการออกแบบระบบสารสนเทศซึ่งเขาเชื่อว่าสามารถนำไปใช้กับการออกแบบ คลังข้อมูล (ดูรูปที่ 3) แนวทางนี้มีพื้นฐานมาจากวิศวกรรมสารสนเทศเพื่อการพัฒนาระบบสารสนเทศเป็นอย่างมาก (Martin 1990) ขั้นตอนแรกคือการกำหนดวัตถุประสงค์ ปัจจัยสำคัญและความสำเร็จ และตัวบ่งชี้ประสิทธิภาพหลัก กระบวนการทางธุรกิจที่สำคัญและข้อมูลที่จำเป็นได้รับการสร้างแบบจำลองเพื่อนำเราไปสู่แบบจำลอง ข้อมูล ทางสังคม. ขั้นตอนที่สองเกี่ยวข้องกับการพัฒนาสถาปัตยกรรมที่กำหนด ข้อมูล จัดเก็บตามพื้นที่ ฐานข้อมูล di คลังข้อมูลส่วนประกอบทางเทคโนโลยีที่จำเป็น ชุดการสนับสนุนองค์กรที่จำเป็นในการนำไปใช้และดำเนินการด้วย คลังข้อมูล. ขั้นตอนที่สามประกอบด้วยการเลือกแพ็คเกจซอฟต์แวร์และเครื่องมือที่จำเป็น ขั้นตอนที่สี่คือการออกแบบและก่อสร้างโดยละเอียด คลังข้อมูล. อีฟส์ตั้งข้อสังเกตว่าการจัดเก็บ ข้อมูล มันเป็นกระบวนการทำซ้ำที่มีข้อจำกัด

จุดแข็งของแนวทางของ Ives คือการใช้เทคนิคเฉพาะเพื่อกำหนดความต้องการข้อมูล การใช้กระบวนการที่มีโครงสร้างเพื่อสนับสนุนการบูรณาการของ คลังข้อมูลการเลือกฮาร์ดแวร์และซอฟต์แวร์ที่เหมาะสม และการใช้เทคนิคการนำเสนอที่หลากหลายสำหรับ คลังข้อมูล. ข้อบกพร่องของมันมีความซับซ้อน อื่นๆ ได้แก่ ความยากในการพัฒนาหลายระดับ ฐานข้อมูล all'interno del คลังข้อมูล ในเวลาและค่าใช้จ่ายอันสมควร

แนวทางของคิมบอลล์ (1994) คลังข้อมูล ออกแบบ

Kimball (1994) เสนอขั้นตอนวนซ้ำ XNUMX ขั้นตอนในการออกแบบ คลังข้อมูล (ดูรูปที่ 4) แนวทางของเขาทุ่มเทให้กับการออกแบบโซโลเป็นพิเศษ คลังข้อมูล และการใช้แบบจำลองมิติตามความต้องการของแบบจำลองเอนทิตีและความสัมพันธ์ Kimball วิเคราะห์แบบจำลองมิติเหล่านั้นเนื่องจากผู้นำธุรกิจจะเข้าใจธุรกิจได้ง่ายขึ้น มีประสิทธิภาพมากขึ้นเมื่อต้องรับมือกับคำปรึกษาที่ซับซ้อน และการออกแบบ ฐานข้อมูล ทางกายภาพมีประสิทธิภาพมากขึ้น (Kimball 1994) คิมบอลล์ตระหนักดีว่าการพัฒนาของ คลังข้อมูล มันเป็นการวนซ้ำ และนั่น คลังข้อมูล ตารางที่แยกจากกันสามารถรวมเข้าด้วยกันได้โดยแบ่งออกเป็นตารางที่มีขนาดทั่วไป

ขั้นตอนแรกคือการระบุสาขาวิชาที่ต้องการทำให้สมบูรณ์แบบ ขั้นตอนที่สองและสามเกี่ยวข้องกับการสร้างแบบจำลองมิติ ในขั้นตอนที่สอง มาตรการจะระบุสิ่งที่น่าสนใจในสาขาวิชาและจัดกลุ่มเป็นตารางข้อเท็จจริง ตัวอย่างเช่น ในหัวข้อการขาย การวัดดอกเบี้ยอาจรวมถึงจำนวนสินค้าที่ขายและดอลลาร์เป็นสกุลเงินในการขาย ขั้นตอนที่สามเกี่ยวข้องกับการระบุมิติซึ่งเป็นวิธีการจัดกลุ่มข้อเท็จจริง ในพื้นที่หัวเรื่องการขาย มิติที่เกี่ยวข้องอาจรวมถึงสินค้า สถานที่ และรอบระยะเวลา ตารางข้อเท็จจริงมีคีย์หลายส่วนเพื่อเชื่อมโยงกับตารางไดเมนชันแต่ละตาราง และโดยทั่วไปจะประกอบด้วยข้อเท็จจริงจำนวนมาก ในทางตรงกันข้าม ตารางไดเมนชันจะมีข้อมูลที่อธิบายเกี่ยวกับไดเมนชันและคุณลักษณะอื่นๆ ที่สามารถใช้เพื่อจัดกลุ่มข้อเท็จจริงได้ ตารางข้อเท็จจริงและมิติที่นำเสนอที่เกี่ยวข้องจะก่อให้เกิดสิ่งที่เรียกว่าสคีมาดาวเนื่องจากรูปร่างของมัน ขั้นตอนที่สี่เกี่ยวข้องกับการสร้าง ฐานข้อมูล หลากหลายมิติเพื่อให้เกิดลวดลายดาวที่สมบูรณ์แบบ ขั้นตอนสุดท้ายคือการระบุระบบต้นทาง ข้อมูล จำเป็นและพัฒนากระบวนการเปลี่ยนแปลงเพื่อจับภาพ ทำความสะอาด และจัดรูปแบบ i ข้อมูล.

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

แนวทางสู่ข้อมูลของ McFadden (1996) การออกแบบคลังสินค้า

McFadden (1996) เสนอแนวทางห้าขั้นตอนในการออกแบบ คลังข้อมูล (ดูรูปที่ 5)
แนวทางของเขามีพื้นฐานมาจากการสังเคราะห์แนวคิดจากวรรณกรรมและมุ่งเน้นไปที่การออกแบบเพียงเรื่องเดียว คลังข้อมูล. ขั้นตอนแรกเกี่ยวข้องกับการวิเคราะห์ความต้องการ แม้ว่าจะไม่ได้กำหนดข้อกำหนดทางเทคนิคไว้ แต่บันทึกของ McFadden จะระบุเอนทิตี ข้อมูล ข้อมูลจำเพาะและคุณลักษณะ และอ้างอิงถึงผู้อ่าน Watson และ Frolick (1993) สำหรับการรวบรวมข้อกำหนด
ในขั้นตอนที่สอง แบบจำลองความสัมพันธ์เอนทิตีได้รับการออกแบบมาเพื่อ คลังข้อมูล และตรวจสอบโดยผู้นำทางธุรกิจ ขั้นตอนที่สามประกอบด้วยการพิจารณาการแมปจากระบบเดิมและแหล่งที่มาภายนอก คลังข้อมูล. ขั้นตอนที่สี่เกี่ยวข้องกับกระบวนการในการพัฒนา การใช้งาน และการซิงโครไนซ์ ข้อมูล ใน คลังข้อมูล. ในขั้นตอนสุดท้าย การส่งมอบระบบได้รับการพัฒนาโดยเน้นที่อินเทอร์เฟซผู้ใช้เป็นพิเศษ McFadden ตั้งข้อสังเกตว่าโดยทั่วไปแล้วกระบวนการวาดภาพจะเป็นการวนซ้ำ

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

ความยากลำบากในการทำความเข้าใจเอนทิตีและแบบจำลองความสัมพันธ์ที่ใช้ในการออกแบบ คลังข้อมูล.

ไม่ใช่เฉพาะคนใกล้ตัวเท่านั้นที่เลือกเรา