Data Warehouses (ခွဲခြမ်းစိတ်ဖြာဖို့ ယခင် ဒေတာ သိုလှောင်ရုံများ)

A3.4.2: Explain the primary objectives of data warehouses in data management and business intelligence. A3.4.3: Explain the role of OLAP and data mining for business intelligence.
မြန်မာလို: A3.4.2: ဒေတာ စီမံခန့်ခွဲမှုနဲ့ business intelligence (ဆုံးဖြတ်ချက်တွေ ချဖို့ ဒေတာကို အသုံးချခြင်း) မှာ data warehouse (ခွဲခြမ်းစိတ်ဖြာဖို့ ယခင် ဒေတာ သိုလှောင်ရုံ) တွေရဲ့ အဓိက ရည်ရွယ်ချက်တွေကို ရှင်းပြနိုင်ရပါမယ်။ A3.4.3: business intelligence အတွက် OLAP (ဒေတာကို ခွဲခြမ်းစိတ်ဖြာဖို့ online စနစ်) နဲ့ data mining (ဒေတာ အများကြီးထဲက ပုံစံတွေကို ရှာဖွေခြင်း) ရဲ့ အခန်းကဏ္ဍကို ရှင်းပြနိုင်ရပါမယ်။

ဒီစာမျက်နှာ တစ်ခုလုံးက HL အဆင့်မှာပဲ အကဲဖြတ် စစ်ဆေးတဲ့ အကြောင်းအရာ ဖြစ်ပါတယ်။ SL (Standard Level) နဲ့ HL (Higher Level) ဆိုတာ IB Computer Science (နိုင်ငံတကာ ကျောင်းတွေမှာ သင်တဲ့ ကွန်ပျူတာသိပ္ပံ သင်ရိုး) သင်တန်းရဲ့ အဆင့်နှစ်ဆင့်ဖြစ်ပြီး HL အပိုင်းတွေက ပိုနက်နက်ရှိုင်းရှိုင်း လေ့လာရတဲ့ အပိုင်းတွေပါ။

အပိုင်း 1: Data Warehouses (ခွဲခြမ်းစိတ်ဖြာဖို့ ယခင် ဒေတာ သိုလှောင်ရုံများ၊ A3.4.2)

Data Warehouse ဆိုတာ ဘာလဲ

Data warehouse ဆိုတာ ရင်းမြစ် အများကြီးက ဒေတာတွေကို တစ်နေရာတည်းမှာ စုပေးတဲ့ ဗဟို သိုလှောင်ရာ ဖြစ်ပါတယ်။ ဥပမာ operational database (အဖွဲ့အစည်း တစ်ခုက နေ့စဉ် လုပ်ငန်းအတွက် သုံးတဲ့ database) တွေ၊ application log (application က ဖြစ်ခဲ့တာတွေကို အစဉ်လိုက် မှတ်ထားတဲ့ မှတ်တမ်း) တွေ၊ NoSQL (ပုံသေ table ပုံစံ မသုံးတဲ့ database) store တွေနဲ့ အပြင်ကနေ ပို့ပေးတဲ့ data feed (ဒေတာ စီးကြောင်း) တွေကနေ ဒေတာ ယူပါတယ်။ ဒီဒေတာတွေကို တသမတ်တည်း ဖြစ်တဲ့ ဒေတာ အစု တစ်ခုအဖြစ် ပေါင်းစည်းပြီး နေ့စဉ် transaction (အကုန်ဖြစ် ဒါမှမဟုတ် ဘာမှမဖြစ်တဲ့ database လုပ်ဆောင်ချက် အစု) တွေအတွက် မဟုတ်ဘဲ ခွဲခြမ်းစိတ်ဖြာမှု (analysis) အတွက် စီစဉ်ထားပါတယ်။

အကျော်ကြားဆုံး အဓိပ္ပာယ်ဖွင့်ဆိုချက်က ဒီနယ်ပယ်ရဲ့ ရှေ့ဆောင် ပညာရှင်တွေထဲက တစ်ယောက် ဖြစ်တဲ့ Bill Inmon ဆီက လာတာပါ: data warehouse ဆိုတာ စီမံခန့်ခွဲသူတွေရဲ့ ဆုံးဖြတ်ချက် ချမှတ်မှုကို ကူညီပေးတဲ့ subject-oriented (လုပ်ငန်း အကြောင်းအရာ အလိုက် စုထားတဲ့)၊ integrated (ရင်းမြစ် အမျိုးမျိုးက ဒေတာကို ပေါင်းစည်းထားတဲ့)၊ time-variant (အချိန်အလိုက် မှတ်တမ်းတွေ သိမ်းထားတဲ့) နဲ့ non-volatile (ထည့်ပြီးရင် မပြောင်းလဲတော့တဲ့) ဒေတာ အစု တစ်ခု ဖြစ်ပါတယ်။ လက်ရှိ syllabus (IB သင်ရိုးညွှန်းတမ်း) မှာ ဒီ property (ဂုဏ်သတ္တိ) လေးခုနဲ့ နောက်ထပ် နှစ်ခု ပါပြီး အားလုံးကို အောက်မှာ ရှင်းပြထားပါတယ်။

OLTP နဲ့ OLAP နှိုင်းယှဉ်ချက်

အဓိက ကွာခြားချက်က OLTP (Online Transaction Processing၊ နေ့စဉ် transaction လုပ်ငန်း) နဲ့ OLAP (Online Analytical Processing၊ ဒေတာကို ခွဲခြမ်းစိတ်ဖြာဖို့ online စနစ်) ကြားမှာပါ:

အချက်	OLTP (operational database)	OLAP (data warehouse)
Workload (လုပ်ရမယ့် အလုပ်)	သေးသေးလေး ဖတ်တာ၊ ရေးတာ (read၊ write) အများကြီး၊ တစ်ကြိမ်မှာ row (table ထဲက အလျားလိုက် အတန်း) တစ်ခုစီ	ကြီးကြီးမားမား ဖတ်တာ အနည်းငယ်၊ အများအားဖြင့် row သန်းပေါင်းများစွာကို ပေါင်းတာ ဒါမှမဟုတ် ပျမ်းမျှ ရှာတာ (aggregating)
အသုံးပြုသူ	နေ့စဉ် အလုပ်တွေ လုပ်နေတဲ့ လူတွေနဲ့ app တွေ (ငွေကိုင်တွေ၊ booking ကိုင်တဲ့ ဝန်ထမ်းတွေ၊ customer တွေ သုံးတဲ့ app တွေ)	Analyst (ဒေတာ ခွဲခြမ်းစိတ်ဖြာသူ) တွေ၊ manager တွေ၊ ဆုံးဖြတ်ချက် ချမှတ်သူတွေ
ဒေတာ ပုံစံ	3NF (normalisation ရဲ့ တတိယ အဆင့်) အထိ normalise (ဒေတာ ထပ်မနေအောင် table တွေကို စီစဉ်) လုပ်ထားတယ်	မြန်မြန် ဖတ်နိုင်အောင် စီထားတယ်: အများအားဖြင့် star schema (ကြယ်ပုံ schema၊ အောက်မှာ ရှင်းပြထားပါတယ်) ဖြစ်ပြီး ဒေတာ တချို့ကို တမင် ထပ်ထားတယ် (denormalised)
ဒေတာ ဘယ်လောက် နောက်ဆုံးရ ဖြစ်လဲ	တိုက်ရိုက် (live)၊ စက္ကန့်တိုင်း နောက်ဆုံး အခြေအနေအတိုင်း	နေ့စဉ် ဒါမှမဟုတ် နာရီတိုင်း load (ထည့်သွင်း) လုပ်ပြီး နှစ်ပေါင်းများစွာစာ မှတ်တမ်းဟောင်းတွေကို သိမ်းထားတယ်
Query (database ထဲက ဒေတာကို ရှာ၊ ပြင်ဖို့ ပေးတဲ့ အမိန့်) တစ်ခုမှာ ပါတဲ့ ဒေတာ ပမာဏ	row တစ်ခု ဒါမှမဟုတ် အနည်းငယ်	row သန်းပေါင်းများစွာ
ဒေတာ ပြင်ဆင်မှု	မပြတ် ဖြစ်နေတယ် (UPDATE, INSERT, DELETE)	ရှားတယ်: ဒေတာ အသစ်က အများအားဖြင့် bulk load (ဒေတာ အများကြီးကို တစ်ခါတည်း ထည့်ခြင်း) နဲ့ ရောက်လာတယ်
Index (ရှာတာ မြန်အောင် လုပ်ထားတဲ့ ညွှန်းစာရင်း)	row တစ်ခုချင်းကို မြန်မြန် ရှာဖို့ တည်ဆောက်ထားတယ်	row အစုလိုက် (range) တွေကို ဖတ်ပြီး မြန်မြန် ပေါင်းဖို့ တည်ဆောက်ထားတယ်
ဥပမာ	Harbour Run club ရဲ့ `Booking` table (database ထဲက ဇယား)	အဲဒီ club ရဲ့ warehouse ထဲက `FACT_BOOKING` table၊ ငါးနှစ်စာ booking တွေကို ခွဲခြမ်းစိတ်ဖြာဖို့ သုံးတယ်

အတိုချုပ်ပြောရရင် OLTP စနစ်က ဖြစ်ရပ်တွေကို ဖြစ်တဲ့အချိန်မှာပဲ တစ်ခုချင်း မှတ်တမ်းတင်ပါတယ်။ OLAP စနစ်ကတော့ ဖြစ်ရပ် အများကြီးကို အကျဉ်းချုပ်ဖို့ နောက်ကြောင်းပြန် ကြည့်ပါတယ်။ နှစ်ခုကို မတူတဲ့ အလုပ်တွေအတွက် ဒီဇိုင်းလုပ်ထားလို့ အများအားဖြင့် သီးခြား စနစ်နှစ်ခုအဖြစ် run ကြပါတယ်။

Data Warehouse ရဲ့ Property ခြောက်ခု

Warehouse ကို OLTP database နဲ့ ခွဲခြားပေးတဲ့ ထူးခြားချက် ခြောက်ခု ရှိပါတယ်။ ဇယားရဲ့ နောက်ဆုံး ကော်လံက တစ်ခုစီရဲ့ အခန်းကဏ္ဍကို ပြပါတယ်: အဖွဲ့အစည်းက သူ့ဒေတာကို သိမ်းပြီး ခွဲခြမ်းစိတ်ဖြာတဲ့အခါ အဲဒီ property က ဘာလုပ်နိုင်အောင် ကူညီပေးလဲ ဆိုတာပါ။

Property	အဓိပ္ပာယ်	အဖွဲ့အစည်းကို ဘာလုပ်နိုင်စေလဲ
Subject-oriented	application တွေ (ဝန်ထမ်း မှတ်တမ်း စနစ်၊ ငွေတောင်းခံ စနစ်၊ website) အလိုက် မဟုတ်ဘဲ လုပ်ငန်းရဲ့ subject (အကြောင်းအရာ) တွေ (Customer, Product, Sale) အလိုက် စုထားပါတယ်	Analyst တွေက subject တစ်ခုနဲ့ ဆိုင်တဲ့ ဒေတာ အားလုံးကို တစ်နေရာတည်းမှာ၊ သူတို့ မေးမယ့် မေးခွန်းတွေအတွက် စီထားတဲ့ ပုံစံနဲ့ တွေ့နိုင်ပါတယ်
Integrated	source system (ဒေတာ ရင်းမြစ် စနစ်) အများကြီးက ဒေတာကို သန့်စင်ပြီး၊ အားလုံး တူညီတဲ့ format နဲ့ code တွေအဖြစ် ပြောင်းပြီး တသမတ်တည်း ဖြစ်တဲ့ ဒေတာ အစု တစ်ခုအဖြစ် ပေါင်းစည်းထားပါတယ်	ရင်းမြစ် မတူတဲ့ ကိန်းဂဏန်းတွေကို ပေါင်းလို့၊ နှိုင်းယှဉ်လို့ ရပြီး report တိုင်းက ကိန်းဂဏန်း အတူတူကိုပဲ သုံးပါတယ်
Time-variant	record (အချက်အလက် အများကြီး စုထားတဲ့ ဒေတာ တစ်ခု) တစ်ခုစီကို အချိန် တစ်ခုနဲ့ တွဲပြီး ယခင် ဒေတာတွေကို သိမ်းထားပါတယ် (ဒီနေ့ ရောင်းအားတင် မဟုတ်ဘဲ နောက်ဆုံး 5 နှစ်စာ ရောင်းအား)	အပြောင်းအလဲ လမ်းကြောင်း (trend) တွေကို တိုင်းတာနိုင်ပြီး အတိတ်အကြောင်း မေးခွန်းကို အဲဒီတုန်းက ဒေတာ အတိုင်း ဖြေနိုင်ပါတယ်
Non-volatile	load လုပ်ပြီးသွားရင် နေ့စဉ် အလုပ်တွေကြောင့် ဒေတာ မပြောင်းလဲတော့ပါဘူး: user တွေက ဖတ်ပဲ ဖတ်ပြီး update မလုပ်ပါဘူး	အတိတ် မှတ်တမ်းတွေကို load လုပ်ခဲ့တဲ့ အတိုင်း ထားတာကြောင့် analyst တွေက လေ့လာနိုင်ပြီး နှစ်ပေါင်းများစွာအတွင်း ကာလတွေကို နှိုင်းယှဉ်နိုင်ပါတယ်
Append-only (အသစ်တွေကိုပဲ ထပ်ထည့်တဲ့)	ဒေတာ အသစ်ကို (ပြောင်းသွားတဲ့ record ရဲ့ version အသစ် အပါအဝင်) row အသစ်တွေအဖြစ် ထပ်ထည့်ပါတယ်၊ ရှိပြီးသား row တွေကို update မလုပ်၊ မဖျက်ပါဘူး။ Load တွေကို အများအားဖြင့် အစုလိုက် (bulk) လုပ်ပြီး အလုပ်ချိန် ပြင်ပမှာ လုပ်လေ့ ရှိပါတယ်	မှတ်တမ်းဟောင်းတွေ ကျန်ပါတယ် (customer ရဲ့ လိပ်စာဟောင်းက သူ့ order ဟောင်းတွေနဲ့ အတူ ရှိနေပါတယ်)၊ load လုပ်တာကလည်း မြန်တဲ့ bulk insert (အစုလိုက် ထည့်ခြင်း) ဖြစ်ပါတယ်
Optimised for query performance (query တွေ မြန်အောင် ဒီဇိုင်းလုပ်ထားတဲ့)	Index တွေ၊ partitioning (table တစ်ခုကို အပိုင်းတွေ ခွဲသိမ်းခြင်း၊ အများအားဖြင့် ရက်စွဲအလိုက် ခွဲပါတယ်)၊ ကြိုတွက်ထားတဲ့ အကျဉ်းချုပ် (summary) တွေနဲ့ denormalised table တွေ ပါပြီး အားလုံးကို ဒေတာ အများကြီးကို မြန်မြန် ဖတ်နိုင်ဖို့ ဒီဇိုင်းလုပ်ထားပါတယ်	row သန်းပေါင်းများစွာကို ပေါင်းတဲ့ query တွေက ရလဒ်ကို မြန်မြန် ပြန်ပေးလို့ analyst တွေက ဒေတာကို ကြည့်ရင်း စူးစမ်း ဆက်ရှာနိုင်ပါတယ်

ပထမ လေးခုက Inmon ရဲ့ မူရင်း အဓိပ္ပာယ်ဖွင့်ဆိုချက် (1992) ပါ။ Syllabus မှာ ခြောက်ခုလုံး ပါပါတယ်: နောက်ဆုံး နှစ်ခုက warehouse ဘယ်လို ကြီးထွားလာလဲ၊ query တွေ မြန်အောင် ဘယ်လို တည်ဆောက်ထားလဲ ဆိုတာကို ဖော်ပြပါတယ်။

Warehouse ကို ဘာကြောင့် တည်ဆောက်ကြလဲ

အဖွဲ့အစည်း တစ်ခုက warehouse တည်ဆောက်ရတဲ့ အဓိက အကြောင်းရင်းတွေက:

Single source of truth (တစ်ဖွဲ့လုံး သုံးတဲ့ မှန်ကန်တဲ့ ဒေတာ ရင်းမြစ် တစ်ခုတည်း)။ Report တိုင်းက သဘောတူထားတဲ့ ကိန်းဂဏန်း အစု တစ်ခုတည်းကို သုံးပါတယ်။ ကိုယ်ပိုင် format နဲ့ ဒေတာ သိမ်းထားတဲ့ operational system တစ်ဒါဇင်လောက်က report တွေကို ပေါင်းစပ်ရမယ့်အစား analyst တွေက နေရာ တစ်ခုတည်းကို query လုပ်ပါတယ်။
Historical analysis (ယခင် ဒေတာကို ခွဲခြမ်းစိတ်ဖြာခြင်း)။ သန့်စင်ပြီးသား၊ အချိန် မှတ်ထားတဲ့ (time-stamped) နှစ်ပေါင်းများစွာစာ ဒေတာ ရှိရင် “ငါးနှစ်အတွင်း ရောင်းအား ဘယ်လို ပြောင်းလဲခဲ့လဲ” လို့ မေးနိုင်ပါတယ်။ Operational database က ဒီမေးခွန်းကို အများအားဖြင့် မဖြေနိုင်ပါဘူး၊ ဘာလို့လဲဆိုတော့ သူက လက်ရှိ တန်ဖိုးတွေ (customer ရဲ့ ဒီနေ့ လိပ်စာ) ကိုပဲ သိမ်းထားပြီး record ဟောင်းတွေကို ဖယ်ရှားပြီး ဖြစ်နိုင်လို့ပါ။
Performance (စွမ်းဆောင်ရည်)။ Warehouse ကို row အများကြီး ပေါင်းတဲ့ query ကြီးတွေအတွက် ဖွဲ့စည်းထားပြီး index လုပ်ထားပါတယ်။ အဲဒီ query တွေကိုပဲ OLTP စနစ်ပေါ်မှာ run ရင် အဲဒီစနစ် ကိုင်တွယ်နေတဲ့ transaction တွေနဲ့ ပြိုင်ပြီး transaction တွေကို နှေးသွားစေနိုင်ပါတယ်။
Operational isolation (နေ့စဉ် လုပ်ငန်းနဲ့ ခွဲထားခြင်း)။ ခွဲခြမ်းစိတ်ဖြာမှုကို နေ့စဉ် အလုပ်နဲ့ သီးခြား ထားပါတယ်: ကြီးမားတဲ့ ခွဲခြမ်းစိတ်ဖြာရေး query တွေကို သီးခြား စနစ် တစ်ခုပေါ်မှာ run တာကြောင့် transaction တွေကို ကိုင်တွယ်နေတဲ့ live စနစ်နဲ့ resource (သုံးလို့ရတဲ့ ကွန်ပျူတာ အရင်းအမြစ်) တွေကို လုမသုံးရပါဘူး။
Data integration (ဒေတာ ပေါင်းစည်းခြင်း)။ Source system အမျိုးမျိုးက ဒေတာကို တစ်ယောက်ယောက် report run တိုင်း ပြင်ရမယ့်အစား load လုပ်တဲ့အချိန်မှာ တစ်ကြိမ်တည်း တသမတ်တည်း ဖြစ်အောင် လုပ်ပါတယ် (ငွေကြေး အမျိုးအစား ပြောင်းတာ၊ customer ID တွေကို ကိုက်ညီအောင် တွဲတာ၊ ရက်စွဲတွေကို format တစ်မျိုးတည်း ဖြစ်အောင် လုပ်တာ)။
Business intelligence (BI) ကို ကူညီပေးခြင်း။ BI ဆိုတာ ဆုံးဖြတ်ချက်တွေ ချဖို့ ဒေတာကို အသုံးချတာပါ။ Dashboard (အဓိက ကိန်းဂဏန်းတွေကို စုပြတဲ့ screen) တွေ၊ KPI (key performance indicator: လစဉ် ရောင်းအားလို လုပ်ငန်းက စောင့်ကြည့်တဲ့ အဓိက ကိန်းဂဏန်း) တွေ၊ အကြီးတန်း manager တွေအတွက် report တွေနဲ့ တစ်ကြိမ်တည်း လုပ်တဲ့ ခွဲခြမ်းစိတ်ဖြာမှုတွေ အားလုံးကို warehouse ပေါ်မှာ run ပါတယ်။

ETL Pipeline (ဒေတာ ထုတ်ယူ၊ ပြောင်းလဲ၊ ထည့်သွင်းတဲ့ လုပ်ငန်းစဉ်)

Warehouse က ETL process နဲ့ ဒေတာ ရယူပါတယ်: Extract, Transform, Load (ထုတ်ယူ၊ ပြောင်းလဲ၊ ထည့်သွင်း)။

flowchart LR
    Sources["<b>Source systems</b><br/>OLTP databases, app logs,<br/>customer records, outside feeds"]
    Staging["<b>Staging area</b><br/>raw data, not yet<br/>cleaned or converted"]
    Warehouse["<b>Data warehouse</b><br/>star schema,<br/>fact + dimension tables"]
    Sources -->|Extract| Staging
    Staging -->|Transform and Load: clean, convert, combine, write| Warehouse

ပုံထဲက စာတွေရဲ့ အဓိပ္ပာယ်: Source systems (ဒေတာ ရင်းမြစ် စနစ်တွေ: OLTP database တွေ၊ app log တွေ၊ customer record တွေ၊ အပြင်က ပို့ပေးတဲ့ ဒေတာ) ကနေ Extract လုပ်ပြီး Staging area (ယာယီ ထားရာ နေရာ: မသန့်စင်ရသေး၊ မပြောင်းလဲရသေးတဲ့ ကုန်ကြမ်း ဒေတာ) ထဲ ထည့်ပါတယ်။ ပြီးရင် Transform and Load (သန့်စင်၊ ပြောင်းလဲ၊ ပေါင်းစည်းပြီး ရေးထည့်) လုပ်ပြီး Data warehouse (star schema၊ fact table နဲ့ dimension table တွေ၊ အောက်မှာ ရှင်းပြထားပါတယ်) ထဲ ရောက်ပါတယ်။

Extract က ရင်းမြစ် တစ်ခုစီက raw data (မပြုပြင်ရသေးတဲ့ ကုန်ကြမ်း ဒေတာ) ကို copy ကူးယူပါတယ်။ အများအားဖြင့် ညဘက်မှာ လုပ်ပြီး တစ်ခါတလေ ဒေတာ အသစ် ရောက်လာသလောက် ဆက်တိုက် လုပ်ပါတယ် (streaming)။
Transform က ဒေတာကို သန့်စင်ပါတယ် (အမှားတွေနဲ့ ကွက်လပ်တွေကို ပြင်ပါတယ်)၊ ဘုံ format တွေအဖြစ် ပြောင်းပါတယ် (ရက်စွဲ format တူတူ၊ ငွေကြေး တူတူ)၊ တခြား field တွေကနေ တွက်ထုတ်ထားတဲ့ field (record တစ်ခုထဲက အချက်အလက် တစ်ကွက်) အသစ်တွေကို ထည့်ပါတယ်၊ ဥပမာ ရက်စွဲကနေ quarter (သုံးလပတ်) ကို တွက်ထည့်တာမျိုးပါ။ ပြီးတော့ ရင်းမြစ် မတူတဲ့ ဒေတာတွေကို ပေါင်းစည်းပါတယ်။
Load က ပြောင်းလဲပြီးသား row တွေကို warehouse ထဲ ရေးထည့်ပါတယ်။ အများအားဖြင့် fact table (ဖြစ်ရပ်တွေကို မှတ်တဲ့ အဓိက table၊ အောက်မှာ ရှင်းပြထားပါတယ်) တွေထဲကို row အသစ်တွေအဖြစ် ထပ်ထည့်ပါတယ်။

ပိုသစ်တဲ့ ပုံစံကွဲ တစ်ခုဖြစ်တဲ့ ELT က raw data ကို အရင် load လုပ်ပြီးမှ warehouse ရဲ့ တွက်ချက်နိုင်စွမ်းကို သုံးပြီး warehouse ထဲမှာပဲ transform လုပ်ပါတယ်။ အဆင့် သုံးဆင့်က အတူတူပဲ ဖြစ်ပြီး အစဉ်ပဲ မတူတာပါ။

Schema (database ဖွဲ့စည်းပုံ ဖော်ပြချက်) ပုံစံ: Star နဲ့ Snowflake

Warehouse အများစုက analyst တွေ query လုပ်တဲ့ table တွေကို denormalised (ဖတ်တာ မြန်အောင် ထပ်နေမှုကို တမင် ပြန်ထည့်ထားတဲ့) ပုံစံနဲ့ စီထားပါတယ်။ ဘာလို့လဲဆိုတော့ ခွဲခြမ်းစိတ်ဖြာရေး query တွေက row အများကြီး ဖတ်ရပြီး join (table တွေကို ချိတ်ဆက် ပေါင်းခြင်း) နည်းလေ ပိုမြန်လေ ဖြစ်လို့ပါ။ (တချို့ ဒီဇိုင်းတွေက normalised ဖြစ်တဲ့ ဗဟို သိုလှောင်ရာ တစ်ခုကို ထားပြီး အဲဒီကနေ ဒီ table တွေကို တည်ဆောက်ပါတယ်။) အသုံးများတဲ့ ပုံစံ နှစ်မျိုး ရှိပါတယ်:

Star schema: ဗဟိုမှာ fact table တစ်ခု ရှိပါတယ်။ ဒီ table မှာ ဒီဇိုင်းဆွဲသူတွေ ရွေးထားတဲ့ အသေးစိတ် အဆင့် တစ်ခုမှာ item တစ်ခုစီအတွက် row တစ်ခု ရှိပါတယ် (ဒီဥပမာမှာ အရောင်း တစ်ခုစီအတွက် row တစ်ခု ရှိပြီး တခြား warehouse တစ်ခုက booking တစ်ခုစီ ဒါမှမဟုတ် website စာမျက်နှာ ကြည့်တဲ့ အကြိမ် တစ်ခုစီအတွက် row တစ်ခု ထားနိုင်ပါတယ်)။ Fact table ကို fact တွေကို ဖော်ပြပေးတဲ့ dimension table (ဖော်ပြချက် table) တွေက ဝိုင်းထားပါတယ် (ဘယ်တုန်းက၊ ဘယ် customer၊ ဘယ် product၊ ဘယ်ဆိုင်):

erDiagram
    FACT_SALES }o--|| DIM_CUSTOMER : "by customer"
    FACT_SALES }o--|| DIM_DATE     : "on date"
    FACT_SALES }o--|| DIM_PRODUCT  : "of product"
    FACT_SALES }o--|| DIM_STORE    : "at store"
    FACT_SALES {
        int sale_id PK
        int customer_id FK
        date date_id FK
        int product_id FK
        int store_id FK
        decimal amount
        int quantity
    }
    DIM_CUSTOMER {
        int customer_id PK
        string name
        string city
        string region
        string country
    }
    DIM_DATE {
        date date_id PK
        int year
        int quarter
        int month
        string day_of_week
    }
    DIM_PRODUCT {
        int product_id PK
        string name
        string category
        string brand
    }
    DIM_STORE {
        int store_id PK
        string name
        string city
        string region
    }

ပုံထဲမှာ FACT_SALES ကို dimension table လေးခုက ဝိုင်းထားပါတယ်။ PK က primary key (row တစ်ခုချင်းကို ခွဲခြားပေးတဲ့ key) ဖြစ်ပြီး FK က foreign key (တခြား table ရဲ့ primary key ကို ညွှန်းတဲ့ column) ပါ။ မျဉ်းတွေပေါ်က စာတွေက အရောင်း တစ်ခုစီဟာ customer တစ်ယောက် (by customer)၊ ရက်စွဲ တစ်ခု (on date)၊ product တစ်ခု (of product) နဲ့ ဆိုင် တစ်ဆိုင် (at store) နဲ့ ချိတ်ဆက်နေတယ်လို့ ဆိုလိုပါတယ်။

Fact table က ကြီးပါတယ် (အရောင်း တစ်ခုစီအတွက် row တစ်ခု ဖြစ်လို့ row ဘီလီယံချီ ရှိနိုင်ပါတယ်)။ Dimension တစ်ခုစီက အများအားဖြင့် fact table ထက် အများကြီး သေးပြီး denormalised attribute (field ရဲ့ နောက်ထပ် နာမည်) တွေကို သိမ်းထားပါတယ် (ဥပမာ DIM_CUSTOMER မှာ မြို့၊ ဒေသ၊ နိုင်ငံနဲ့ အသက် အပိုင်းအခြား အားလုံးကို row တစ်ခုတည်းမှာ ထည့်ထားနိုင်ပါတယ်)။

Snowflake schema (နှင်းပွင့်ပုံ schema): dimension table တွေကိုယ်တိုင်ကို sub-table (table ခွဲ) တွေအဖြစ် normalise လုပ်ထားတဲ့ star schema ပါ (ဥပမာ DIM_CUSTOMER -> DIM_CITY -> DIM_COUNTRY)။ ဒီလို လုပ်ရင် မြို့ တစ်မြို့စီ ဒါမှမဟုတ် နိုင်ငံ တစ်နိုင်ငံစီရဲ့ အသေးစိတ်ကို တစ်ကြိမ်ပဲ သိမ်းရပါတယ်။ ဒါပေမယ့် query က သုံးတဲ့ အဆင့် တစ်ခုစီအတွက် JOIN တစ်ခု ပိုလိုလာပါတယ်။

Star schema တွေက ပိုအသုံးများပါတယ်။ ဘာလို့လဲဆိုတော့ ဖွဲ့စည်းပုံ ပိုရိုးရှင်းလို့ query ရေးရ ပိုလွယ်ပြီး BI tool တွေကိုလည်း သုံးရ ပိုလွယ်လို့ပါ။

အပိုင်း 2: OLAP နဲ့ Data Mining (A3.4.3)

OLAP (Online Analytical Processing၊ ဒေတာကို ခွဲခြမ်းစိတ်ဖြာဖို့ online စနစ်)

OLAP ဆိုတာ analyst တွေကို warehouse ရဲ့ ဒေတာကို interactive (user လုပ်သလို ချက်ချင်း တုံ့ပြန်တဲ့) ပုံစံနဲ့ စူးစမ်းကြည့်နိုင်စေတဲ့ software အမျိုးအစား ဖြစ်ပါတယ်။ အများအားဖြင့် ဒေတာကို dimension (ဒေတာကို ကြည့်တဲ့ ရှုထောင့်) အများကြီး ပါတဲ့ “cube” (အတုံး) တစ်ခုအဖြစ် ကြည့်ပြီး စူးစမ်းပါတယ်။ ဥပမာ product၊ နေရာနဲ့ အချိန် ဆိုတဲ့ dimension တွေပါ:

ပုံထဲက label တွေရဲ့ အဓိပ္ပာယ်: Product (categories) က ကုန်ပစ္စည်း (အမျိုးအစားအလိုက်)၊ Geography (regions) က ဒေသ (region အလိုက်)၊ Time (months) က အချိန် (လအလိုက်) ပါ။

Cube ရဲ့ cell (အကွက်) တစ်ခုစီမှာ စုစုပေါင်း တန်ဖိုး (aggregate) တစ်ခု ရှိပါတယ်၊ ဥပမာ Asia မှာ March 2026 အတွင်း ရောင်းခဲ့တဲ့ electronics (လျှပ်စစ် ပစ္စည်း) ရဲ့ စုစုပေါင်း ရောင်းအားလိုမျိုးပါ။ Analyst တွေက cube ကို operation (လုပ်ဆောင်ချက်) ငါးမျိုးနဲ့ စူးစမ်းကြည့်ပါတယ်:

Slice (တစ်ချပ် ဖြတ်ကြည့်ခြင်း): dimension တစ်ခုကို တန်ဖိုး တစ်ခုတည်းမှာ ပုံသေ ထားပါတယ် (March 2026 ပဲ)။
Dice (အတုံးငယ် ဖြတ်ယူခြင်း): dimension နှစ်ခု ဒါမှမဟုတ် နှစ်ခုထက် ပိုတဲ့ dimension တွေပေါ်မှာ တန်ဖိုးတွေကို တစ်ပြိုင်နက် ရွေးပါတယ် (Asia နဲ့ Europe၊ Q1 နဲ့ Q2 သုံးလပတ်၊ electronics ပဲ)။ ဒါကြောင့် cube အသေး တစ်ခု ရလာပါတယ်။
Drill down (အသေးစိတ်ထဲ ဆင်းကြည့်ခြင်း): dimension တစ်ခုကို ပိုအသေးစိတ်တဲ့ အဆင့်အထိ ချဲ့ကြည့်ပါတယ် (Q1 2026 -> January, February, March -> March ရဲ့ ရက် တစ်ရက်စီ)။
Roll up (အကျဉ်းချုပ် အဆင့်ကို တက်ကြည့်ခြင်း): dimension တစ်ခုကို အသေးစိတ် နည်းတဲ့ အဆင့်ကို တက်ကြည့်ပါတယ် (Asia + Europe + Americas -> ကမ္ဘာ တစ်ခုလုံး)။
Pivot (row နဲ့ column နေရာ လဲကြည့်ခြင်း): ဘယ် dimension တွေကို row အဖြစ် ပြပြီး ဘယ် dimension တွေကို column (ဒေါင်လိုက် ကော်လံ) အဖြစ် ပြမလဲ ဆိုတာကို လဲလှယ်ပါတယ်။

OLAP က interactive ဖြစ်ပြီး စူးစမ်းရှာဖွေတဲ့ သဘော ရှိပါတယ်။ သူ့အလုပ် အများစုက စုစုပေါင်း တန်ဖိုးတွေကို ပေါင်းတာနဲ့ နှိုင်းယှဉ်တာပါ။ Business intelligence dashboard တွေရဲ့ နောက်ကွယ်က နည်းပညာ ဖြစ်ပါတယ်၊ ဥပမာ ကုမ္ပဏီရဲ့ အမှုဆောင် အရာရှိချုပ်က SQL (Structured Query Language: database ကို မေးခွန်းမေးဖို့နဲ့ ပြင်ဆင်ဖို့ သုံးတဲ့ စံ language) မရေးဘဲ “ဒီသုံးလပတ်မှာ ဝင်ငွေ ဘယ်မှာ တိုးနေလဲ” ဆိုတာ ကြည့်ဖို့ ဖွင့်တဲ့ dashboard လိုမျိုးပါ။

OLAP ကို OLTP (online transaction processing) နဲ့ မကြာခဏ နှိုင်းယှဉ်ကြပါတယ်: database တစ်ခု လုပ်နိုင်တဲ့ မတူညီတဲ့ အလုပ် နှစ်မျိုး ဖြစ်ပါတယ်။ Data warehouse တွေကို OLAP အလုပ်တွေ လုပ်နိုင်ဖို့ ဒီဇိုင်းလုပ်ထားတာပါ။

Data Mining: ပုံစံတွေကို ရှာဖွေခြင်း

Data mining ဆိုတာ ဒေတာ အများကြီးထဲမှာ အသုံးဝင်တဲ့ ပုံစံ (pattern) တွေ၊ အုပ်စုတွေ ဒါမှမဟုတ် ပုံမှန်မဟုတ်တဲ့ record (anomaly) တွေကို algorithm (အယ်လ်ဂိုရီသမ်၊ ပြဿနာကို အဆင့်ဆင့် ဖြေရှင်းတဲ့ နည်းလမ်း) တွေ သုံးပြီး အလိုအလျောက် ရှာဖွေတာ ဖြစ်ပါတယ်။ ဒီစာမျက်နှာမှာ technique (နည်းလမ်း) ခြောက်မျိုးကို လေ့လာပါမယ်:

Technique	ဘာလုပ်လဲ	ဥပမာ
Classification (သိပြီးသား အမျိုးအစားတွေထဲ ခွဲထည့်ခြင်း)	record တစ်ခုစီကို သိပြီးသား အမျိုးအစား (category) အများကြီးထဲက တစ်ခုထဲ ထည့်ပါတယ်	label (မှန်ကန်တဲ့ အမျိုးအစား) တပ်ပြီးသား email တွေနဲ့ train (ဒေတာနဲ့ လေ့ကျင့်ပေး) လုပ်ထားတဲ့ model (ဒေတာကနေ သင်ယူပြီး ခန့်မှန်းပေးတဲ့ စနစ်) ကို သုံးပြီး email တစ်စောင်ကို “spam” (အလိုမရှိတဲ့ email) ဒါမှမဟုတ် “not spam” လို့ မှတ်တာ
Clustering (ဆင်တူတာတွေကို အုပ်စုဖွဲ့ခြင်း)	ကြိုတင် သတ်မှတ်ထားတဲ့ label တွေ မပါဘဲ record တွေကို ဆင်တူမှုအလိုက် အုပ်စုဖွဲ့ပါတယ်	marketing (စျေးကွက်ရှာဖွေရေး) အတွက် customer တွေကို ဝယ်ယူပုံ ဆင်တူတဲ့ အုပ်စုတွေ ခွဲတာ
Regression (ကိန်းဂဏန်း တန်ဖိုး ခန့်မှန်းခြင်း)	တခြား attribute တွေကနေ ကိန်းဂဏန်း တန်ဖိုး တစ်ခုကို ခန့်မှန်းပါတယ်	ရောင်းအား မတက်ခင်၊ မကျခင် အရင် တက်တတ်၊ ကျတတ်တဲ့ ကိန်းဂဏန်းတွေ (ဥပမာ ဆိုင်ရဲ့ website ကို လာကြည့်တဲ့ အကြိမ်ရေ) ကနေ နောက်လ ရောင်းအားကို ကြိုခန့်မှန်းတာ
Association-rule discovery (X ဝယ်ရင် Y ပါ ဝယ်တတ်တယ်ဆိုတဲ့ ပုံစံကို ရှာခြင်း)	“X ဝယ်တဲ့သူတွေက Y ကိုလည်း ဝယ်တယ်” ဆိုတဲ့ rule (စည်းမျဉ်း) မျိုးတွေကို ရှာပါတယ်	“ဆေးသုတ်ဆေး တစ်ဘူး ဝယ်တဲ့ customer တွေက တစ်ခေါက်တည်းမှာ ဆေးသုတ်တံတွေနဲ့ ကပ်ခွာတိပ် (masking tape) ကိုလည်း မကြာခဏ ဝယ်တတ်တယ်”
Sequential pattern discovery (အစဉ်လိုက် ဖြစ်တတ်တဲ့ ပုံစံကို ရှာခြင်း)	အစဉ် တစ်ခုအတိုင်း ဖြစ်တတ်တဲ့ ဖြစ်ရပ်တွေကို ရှာပါတယ်	“ဖုန်း ဝယ်တဲ့ customer တွေက 14 ရက်အတွင်း ဖုန်းအိတ် (case) ကို မကြာခဏ ဝယ်တတ်တယ်”
Anomaly detection (ပုံမှန်မဟုတ်တဲ့ record တွေကို ရှာခြင်း)	ပုံမှန် ပုံစံနဲ့ အရမ်း ကွာခြားတဲ့ record တွေကို ရှာပါတယ်	လိမ်လည်ထားတဲ့ card ငွေပေးချေမှု တစ်ခုကို flag (သတိပေး အမှတ်အသား) လုပ်တာ၊ စက်ရုံ sensor (ပတ်ဝန်းကျင် အပြောင်းအလဲကို ထောက်လှမ်းတဲ့ ကိရိယာ) ရဲ့ ဖတ်ချက်က ပုံမှန် အပိုင်းအခြားနဲ့ အဝေးကြီး ကွာနေတာကို ရှာတွေ့တာ

ပထမ လေးမျိုးက machine learning (ဒေတာကနေ သင်ယူတဲ့ စနစ်) technique တွေလည်း ဖြစ်ပါတယ် (A4၊ IB syllabus ရဲ့ machine learning အပိုင်း)။ ဒါကြောင့် ဒီခေါင်းစဉ်က database နဲ့ machine learning ကို ချိတ်ဆက်ပေးပါတယ်။ Anomaly detection ကို deviation detection (ပုံမှန်ကနေ သွေဖည်မှုကို ရှာခြင်း) လို့လည်း ခေါ်ပါတယ်။

Classification နဲ့ Clustering: အဓိက ကွာခြားချက်

Classification နဲ့ clustering ကို ရောထွေးလွယ်ပါတယ်။ အဓိက ကွာခြားချက်တွေက:

အချက်	Classification	Clustering
သင်ယူပုံ	Supervised (label တပ်ထားတဲ့ ဥပမာတွေကနေ သင်ယူခြင်း): record တစ်ခုစီမှာ သူ့ label (သူ့ရဲ့ မှန်ကန်တဲ့ အမျိုးအစား) ရှိပြီးသား training data (model သင်ယူဖို့ ပေးတဲ့ ဒေတာ) ကနေ သင်ယူပါတယ်	Unsupervised (label မပါတဲ့ ဒေတာကနေ သင်ယူခြင်း): ဒေတာမှာ label မပါပါဘူး
စတင်တဲ့အခါ ဘာရှိလဲ	ကြိုတင် သတ်မှတ်ထားတဲ့ class (အမျိုးအစား) အစု တစ်ခု (“spam” / “not spam”)	label မပါတဲ့ ဒေတာ၊ အုပ်စုတွေက record တွေ ဘယ်လောက် ဆင်တူလဲ ဆိုတာကနေ ပေါ်လာပါတယ်
Output (ရလဒ်)	record အသစ်တွေကို သိပြီးသား class တွေထဲ ထည့်ပေးတဲ့ model တစ်ခု	record တွေကို cluster (အုပ်စု) တွေအဖြစ် ခွဲထားတာ၊ cluster တစ်ခုစီရဲ့ အဓိပ္ပာယ်ကို လူတွေက နောက်မှ စဉ်းစား ဖော်ထုတ်ပါတယ်
အသုံးများတဲ့ နေရာ	Email spam filter တွေ၊ လိမ်လည်မှု ရှာဖွေခြင်း (fraud detection)၊ ပုံတွေကို label တပ်ခြင်း	Customer segmentation (customer တွေကို အုပ်စုတွေ ခွဲခြင်း)၊ စျေးကွက် သုတေသန၊ ဒေတာ အစု အသစ် တစ်ခုကို ပထမဆုံး ကြည့်တာ
Validation (ရလဒ်ကို စစ်ဆေးခြင်း)	Training မှာ မသုံးဘဲ ချန်ထားတဲ့ record တွေရဲ့ သိပြီးသား label တွေနဲ့ model ရဲ့ ခန့်မှန်းချက်တွေကို နှိုင်းယှဉ်ပါတယ်	Cluster တွေ အသုံးဝင်မဝင်ကို လူတွေက ဆုံးဖြတ်ပါတယ်။ နှိုင်းယှဉ်စရာ မှန်ကန်တဲ့ label တွေ မရှိလို့ စစ်ရ ပိုခက်ပါတယ်

နှစ်ခုလုံးက record တွေကို အုပ်စုတွေထဲ ထည့်ပါတယ်။ ကွာခြားချက်က အုပ်စုတွေကို ကြိုတင် သတ်မှတ်ထားလား (classification)၊ ဒါမှမဟုတ် ဒေတာထဲကနေ ရှာတွေ့တာလား (clustering) ဆိုတာပါ။

လက်တွေ့မှာ Data Mining: အဆင့်ဆင့် ရှင်းပြထားတဲ့ အခြေအနေ သုံးခု

Customer segmentation (clustering)။ အဝတ်အထည် လက်လီ ရောင်းတဲ့ လုပ်ငန်း တစ်ခုက သူ့ customer တွေကြားမှာ သဘာဝအတိုင်း ဖြစ်နေတဲ့ အုပ်စုတွေကို ရှာချင်ပါတယ်။ Customer တစ်ယောက်စီရဲ့ ဝယ်ယူမှု မှတ်တမ်း၊ website ကြည့်ပုံ (browsing pattern) နဲ့ အသက်၊ နေရာလို အချက်အလက်တွေကို clustering algorithm တစ်ခုကို ပေးပါတယ်။ Algorithm က အုပ်စု ငါးစု ရှာတွေ့ပြီး marketing အဖွဲ့က အုပ်စု တစ်ခုစီကို ကြည့်ပြီး နာမည်ပေးပါတယ်: လျှော့ဈေး ရှာသူတွေ၊ ရံဖန်ရံခါ လက်ဆောင် ဝယ်သူတွေ၊ premium (အဆင့်မြင့်) ပစ္စည်းတွေကို ပုံမှန် ဝယ်တဲ့ သစ္စာရှိ customer တွေ၊ အားကစား ဝတ်စုံ ဝယ်သူတွေနဲ့ ရာသီအလိုက်ပဲ လာကြည့်တတ်သူတွေ။ ပြီးတော့ အဖွဲ့က အုပ်စု (segment) တစ်ခုစီအတွက် သီးခြား campaign (ကြော်ငြာ လှုပ်ရှားမှု) တစ်ခုစီ စီစဉ်ပါတယ်။

Fraud detection (anomaly detection)။ ဘဏ် တစ်ခုရဲ့ လိမ်လည်မှု ရှာဖွေရေး စနစ်က card ကိုင်သူ တစ်ယောက်စီရဲ့ ပုံမှန် သုံးစွဲပုံကို သင်ယူပါတယ်။ အဲဒီ ပုံစံနဲ့ အရမ်းကွာတဲ့ ငွေပေးချေမှု (တခြား နိုင်ငံမှာ၊ ပမာဏ အများကြီး ပိုများတာ၊ ပုံမှန် မဝယ်တဲ့ ဆိုင် အမျိုးအစား) ကို ထပ်စစ်ဖို့ flag လုပ်ပါတယ်။ ဒီစနစ်မှာ “fraud” (လိမ်လည်မှု) ဒါမှမဟုတ် “legitimate” (တရားဝင်) လို့ label တပ်ထားတဲ့ ငွေပေးချေမှုတွေ မလိုပါဘူး: customer တစ်ယောက်စီရဲ့ ပုံမှန် ပုံစံကို သင်ယူပြီး အဲဒီ ပုံစံရဲ့ အပြင်ဘက် အဝေးကြီးမှာ ရှိတဲ့ ငွေပေးချေမှု (outlier) တွေအတွက် သတိပေးချက် ထုတ်ပါတယ်။

Online သင်တန်းမှာ စောစော သတိပေးခြင်း (sequential pattern discovery)။ Online သင်ယူရေး platform တစ်ခုက ကျောင်းသားတွေ အလုပ်တွေ လုပ်တဲ့ အစဉ်ထဲက ပုံစံတွေကို သူ့ record တွေထဲမှာ ရှာပါတယ်။ အပတ်စဉ် quiz နှစ်ခုကို ဆက်တိုက် လွတ်သွားပြီး နောက် သင်တန်း video တွေကို ဖွင့်မကြည့်တော့တဲ့ ကျောင်းသားတွေက တစ်လအတွင်း သင်တန်းကို မကြာခဏ ထွက်သွားတတ်တာကို တွေ့ပါတယ်။ အခု platform က ဒုတိယ quiz လွတ်သွားတာနဲ့ ကျောင်းသားကို ပြန်လိုက်မီအောင် ကူညီဖို့ အချိန် ရှိနေသေးချိန်မှာပဲ ကျောင်းသားရဲ့ ဆရာကို သတိပေးပါတယ်။

Business Intelligence: အားလုံးကို ပေါင်းစပ်ကြည့်ခြင်း

Business intelligence (BI) ဆိုတာ ဆုံးဖြတ်ချက်တွေ ချဖို့ ဒေတာကို အသုံးချတာရဲ့ ယေဘုယျ အမည် ဖြစ်ပါတယ်။ ပုံမှန် BI စနစ် တစ်ခုက ဒီစာမျက်နှာရဲ့ အပိုင်း သုံးပိုင်းကို ပေါင်းစပ်ထားပါတယ်:

သန့်စင်ပြီး၊ ပေါင်းစည်းထားပြီး၊ ယခင် မှတ်တမ်းတွေ ပါတဲ့ ဒေတာရဲ့ ရင်းမြစ် အဖြစ် data warehouse။
Analyst တွေ စူးစမ်းနေစဉ် စုစုပေါင်း တန်ဖိုးတွေကို ပေါင်းပေး၊ နှိုင်းယှဉ်ပေးတဲ့ interactive tool အဖြစ် OLAP။
ဒေတာကို ကြည့်ရုံနဲ့ သတိထားမိဖို့ ခက်တဲ့ ပုံစံတွေကို ရှာပေးတဲ့ data mining algorithm တွေ။

ရလဒ်တွေက dashboard (manager တွေအတွက် အဓိက ကိန်းဂဏန်းတွေကို ပြတဲ့ screen) တွေ၊ report (ဥပမာ လစဉ် KPI report) တွေနဲ့ predictive model (ဥပမာ နောက်သုံးလပတ် ရောင်းအား ခန့်မှန်းချက်) တွေမှာ ပေါ်လာပြီး manager တွေက ဆုံးဖြတ်ချက် ချဖို့ အဲဒါတွေကို သုံးပါတယ်။

OLAP နဲ့ data mining ရဲ့ အခန်းကဏ္ဍ မတူပါဘူး။ OLAP က analyst ကို ဒေတာကို interactive ပုံစံနဲ့ စူးစမ်းနိုင်စေပါတယ်: ဘယ် စုစုပေါင်း တန်ဖိုးတွေကို ကြည့်မလဲ သူတို့ကိုယ်တိုင် ရွေးပြီး အဲဒီ တန်ဖိုးတွေထဲမှာ ဆက်သွား ကြည့်ပါတယ် (drill down လုပ်တာ၊ slice လုပ်တာ)။ Data mining ကတော့ ပုံစံတွေကို ရှာပေးတဲ့ ဒါမှမဟုတ် ခန့်မှန်းချက် ထုတ်ပေးတဲ့ algorithm တွေကို run ပါတယ်၊ ဥပမာ customer အုပ်စုတွေ၊ rule တွေ၊ ပုံမှန်မဟုတ်တဲ့ record တွေ ဒါမှမဟုတ် နောက်လ ရောင်းအား စတာတွေပါ။ စုစုပေါင်း တန်ဖိုးတွေကို ကြည့်ရုံနဲ့ သတိထားမိဖို့ ခက်တဲ့ ပုံစံတွေလည်း ပါပါတယ်။ နှစ်ခုက အတူတူ အလုပ်လုပ်နိုင်ပါတယ်: data mining ရှာတွေ့ထားတဲ့ ပုံစံ တစ်ခုကို analyst က OLAP သုံးပြီး အဲဒီ ပုံစံ နောက်ကွယ်က record တွေထဲ drill down လုပ်ကာ စစ်ကြည့်နိုင်ပါတယ်။

အဆင့်ဆင့် ရှင်းပြထားတဲ့ ဥပမာများ

ဥပမာ 1: လုပ်ငန်း တစ်ခုတည်းအတွက် OLTP နဲ့ OLAP

Harbour Run အားကစား club မှာ database နှစ်မျိုးလုံး ရှိပါတယ်:

OLTP database (operational၊ နေ့စဉ် လုပ်ငန်းသုံး):

အရင် စာမျက်နှာတွေက Booking table ပါ၊ လက်ရှိ ဖြစ်နေတဲ့ (live) booking တွေကို သိမ်းထားပါတယ်။
Website က booking အသစ်တွေ လက်ခံဖို့ သုံးပြီး ဝန်ထမ်းတွေက “နောက် အတန်းမှာ ဘယ်သူတွေ ပါလဲ” လို့ ရှာကြည့်ဖို့ သုံးပါတယ်။
3NF အထိ normalise လုပ်ထားပြီး foreign key တွေကို စစ်ဆေးပါတယ်၊ ACID (transaction တစ်ခုရဲ့ အာမခံချက် လေးခု) transaction တွေကို သုံးပြီး ဒေတာက စက္ကန့်တိုင်း နောက်ဆုံး အခြေအနေအတိုင်း ဖြစ်ပါတယ်။

OLAP warehouse (analytical၊ ခွဲခြမ်းစိတ်ဖြာရေးသုံး):

လုပ်ခဲ့သမျှ booking အားလုံးကို (အခုဆိုရင် နှစ်ပေါင်း အတော်များများစာ) သိမ်းထားတဲ့ FACT_BOOKING table တစ်ခု ရှိပြီး denormalised dimension table တွေ ဖြစ်တဲ့ DIM_MEMBER, DIM_CLASS နဲ့ DIM_DATE တို့နဲ့ join လုပ်ထားပါတယ်။ Member တစ်ယောက်ရဲ့ tier (အသင်းဝင် အဆင့်) ပြောင်းတိုင်း DIM_MEMBER မှာ row အသစ် တစ်ခု တိုးလာတာကြောင့် tier ဟောင်းက booking ဟောင်းတွေနဲ့ အတူ ကျန်နေပါတယ်။
Club ရဲ့ manager တွေက “မနှစ်က ဘယ်အပတ်က အလုပ်အများဆုံးလဲ”၊ “ဘယ် နည်းပြတွေက member တွေကို အကောင်းဆုံး ဆက်ထိန်းထားနိုင်လဲ”၊ “Premium membership က လစဉ် ဘယ်လို တိုးလာလဲ” ဆိုတဲ့ မေးခွန်းတွေကို ဖြေဖို့ သုံးပါတယ်။
OLTP database ကနေ ညတိုင်း load လုပ်ပါတယ်၊ ရှိပြီးသား row တွေကို update မလုပ်ဘဲ row အသစ်တွေကို ထပ်ထည့်ပါတယ်။
Star schema အဖြစ် စီထားပြီး row အစုလိုက်တွေကို ဖတ်ပြီး ပေါင်းတဲ့ query တွေအတွက် index အများကြီး ပါပါတယ်။

လုပ်ငန်း တစ်ခုတည်းမှာ နှစ်ခုလုံး လိုပါတယ်။ ယခင် ဒေတာ ခွဲခြမ်းစိတ်ဖြာမှုကို live booking စနစ်ပေါ်မှာ တိုက်ရိုက် run ရင် နေ့စဉ် လုပ်ငန်းတွေကို နှေးသွားစေနိုင်ပါတယ်။ Live booking တွေကို warehouse ပေါ်မှာ run ရင်လည်း ကောင်းကောင်း အလုပ် မလုပ်ပါဘူး: warehouse ရဲ့ ဒေတာက တစ်ရက်အထိ ဟောင်းနေနိုင်ပြီး write (ဒေတာ ရေးထည့်ခြင်း) သေးသေးလေးတွေ အများကြီးအတွက် တည်ဆောက်ထားတာ မဟုတ်လို့ပါ။

ဥပမာ 2: Clustering နဲ့ Classification

Online ဟင်းချက် သင်တန်းကျောင်း တစ်ခုက live video အတန်းတွေ ပြုလုပ်ပြီး သူ့ member တွေကို ပိုနားလည်ချင်ပါတယ်။

Classification ဥပမာ: member ဝင်တဲ့အခါ ဖြေချင်မှ ဖြေရတဲ့ ဟင်းချက် quiz ကို ဖြေတဲ့ member တွေကို “beginner” (အစပြုသူ)၊ “improving” (တိုးတက်လာသူ) ဒါမှမဟုတ် “confident” (ယုံကြည်မှု ရှိသူ) လို့ label တပ်ပါတယ်။ Classification model က label တပ်ထားတဲ့ ဒီ member တွေကနေ လူတွေ book လုပ်တဲ့ အတန်းတွေနဲ့ သူတို့ရဲ့ အဆင့်ကြား ဆက်စပ်ပုံကို သင်ယူပါတယ်။ ပြီးရင် quiz မဖြေဘဲ ကျော်သွားတဲ့ member အသစ် တစ်ယောက်စီကို အဲဒီ member book လုပ်တဲ့ အတန်းတွေကို ကြည့်ပြီး အဆင့် သုံးဆင့်ထဲက တစ်ဆင့်ထဲ ထည့်ပေးပါတယ်။ Model ကို train မလုပ်ခင်ကတည်းက label တွေကို သိထားပြီး ဖြစ်ပါတယ်။

Clustering ဥပမာ: ကျောင်းက ဘယ်အုပ်စုကိုမှ ကြိုမသတ်မှတ်ထားပါဘူး။ Clustering algorithm က member တွေကို သူတို့ book လုပ်တဲ့ အတန်းတွေ၊ ဟင်းချက်တဲ့ နေ့နဲ့ အချိန်တွေ၊ ဘယ်လောက် မကြာခဏ ပြန်လာလဲ ဆိုတာတွေနဲ့ အုပ်စုဖွဲ့ပြီး (ဥပမာ) cluster ငါးခု ထုတ်ပေးပါတယ်။ ကျောင်းရဲ့ ဝန်ထမ်းတွေက နောက်မှ cluster တစ်ခုစီကို ကြည့်ပြီး ဖော်ပြပါတယ် (“အုပ်စု 1: အချိန်ကုန်သက်သာတဲ့ ဟင်းတွေ လိုချင်တဲ့ ရုံးဖွင့်ရက် ညနေ ဟင်းချက်သူတွေ၊ အုပ်စု 2: စနေ၊ တနင်္ဂနွေ မုန့်ဖုတ်သူတွေ၊ …”)။ အုပ်စုတွေက ကြိုပေးထားတဲ့ label မပါဘဲ ဒေတာထဲကနေ ပေါ်လာတာပါ။

ဥပမာ 3: ချို့ယွင်းနေတဲ့ Solar Array ကို ရှာတွေ့ခြင်း

ကျောင်းခရိုင် တစ်ခုမှာ ကျောင်း ငါးကျောင်းရဲ့ ခေါင်မိုးတွေပေါ်မှာ အရွယ်အစား တူတဲ့ solar panel (နေရောင်ခြည် စွမ်းအင်ပြား) တွေ တပ်ထားပါတယ်။ ကျောင်း တစ်ကျောင်းစီရဲ့ panel အစုကို array လို့ ခေါ်ပါတယ်။ Array တစ်ခုစီက တစ်ရက်မှာ ထုတ်ပေးတဲ့ လျှပ်စစ် ပမာဏကို kilowatt-hour (kWh) နဲ့ တိုင်းပြီး ညတိုင်း ခရိုင်ရဲ့ data warehouse ထဲ load လုပ်ပါတယ်။ ဒီမှာ လေးရက်စာ ဒေတာ ရှိပါတယ်:

နေ့	ရာသီဥတု	Ash Road	Bay View	Cedar Hill	Dune Park	Elm Grove
Mon	Sunny	212	208	215	210	206
Tue	Cloudy	96	94	99	95	93
Wed	Sunny	209	211	140	207	212
Thu	Sunny	214	210	138	213	209

ဇယားထဲမှာ Mon၊ Tue၊ Wed၊ Thu က တနင်္လာ၊ အင်္ဂါ၊ ဗုဒ္ဓဟူး၊ ကြာသပတေး နေ့တွေ ဖြစ်ပြီး Sunny က နေသာတဲ့နေ့၊ Cloudy က တိမ်ထူတဲ့နေ့ပါ။ ကျောင်း နာမည် ကော်လံတွေထဲက ဂဏန်းတွေက kWh ပါ။

ပုံသေ ကန့်သတ်ချက်က မှားယွင်းတဲ့ သတိပေးချက်တွေ ပေးပါတယ်။ “Array တစ်ခုက 150 kWh ထက် နည်းရင် သတိပေးပါ” ဆိုတဲ့ rule မျိုးက ဘာမှ မမှားတဲ့ တိမ်ထူတဲ့ အင်္ဂါနေ့မှာ ကျောင်း ငါးကျောင်းလုံးအတွက် သတိပေးပါတယ်။ Array တစ်ခု ဘယ်လောက် ထုတ်ပေးသင့်လဲ ဆိုတာက အဲဒီနေ့ရဲ့ ရာသီဥတုပေါ် မူတည်ပါတယ်။

Array တစ်ခုစီကို အဲဒီနေ့က တခြား array တွေနဲ့ နှိုင်းယှဉ်ပါ။ ကျောင်းတွေက တစ်ခုနဲ့ တစ်ခု နီးနီးမှာ ရှိပြီး ရာသီဥတု အတူတူ ကြုံရတာကြောင့် ဘယ်နေ့မှာမဆို သူတို့ရဲ့ array တွေက ပမာဏ အတူတူနီးပါး ထုတ်ပေးသင့်ပါတယ်။ ခရိုင်က array တစ်ခုစီက ထုတ်ပေးတဲ့ ပမာဏကို အဲဒီနေ့က ကျန်တဲ့ array လေးခုရဲ့ ပျမ်းမျှနဲ့ နှိုင်းယှဉ်ပြီး အဲဒီ ပျမ်းမျှထက် 15% ထက် ပိုနည်းနေတဲ့ array ကို flag လုပ်ပါတယ်။ အင်္ဂါနေ့မှာ array တိုင်းက တခြား array တွေနဲ့ 5% အတွင်းမှာ ရှိလို့ ဘာကိုမှ flag မလုပ်ပါဘူး။ ဗုဒ္ဓဟူးနေ့မှာ Cedar Hill က 140 kWh ထုတ်ပေးခဲ့ပြီး ကျန်တဲ့ လေးခုရဲ့ ပျမ်းမျှ 210 kWh ထက် သုံးပုံတစ်ပုံလောက် နည်းပါတယ်။ ကြာသပတေးနေ့မှာလည်း ကွာဟချက်က အတူတူလောက်ပါပဲ။ Cedar Hill ကို နှစ်ရက်လုံး flag လုပ်ပါတယ်။

Flag တစ်ခုဆိုတာ တစ်ယောက်ယောက်က စစ်ကြည့်သင့်တယ်လို့ ဆိုလိုတာပါ။ စက်ပြင်ဆရာ တစ်ယောက်က Cedar Hill ကို သွားကြည့်ပြီး panel တန်း တစ်တန်းမှာ cable တစ်ချောင်း ချောင်နေတာကို တွေ့ပါတယ်။ အကယ်၍ အကြောင်းရင်းက မွန်းလွဲပိုင်းတိုင်း ခေါင်မိုးကို အရိပ်ထိုးနေတဲ့ အဆောက်အအုံ အသစ် တစ်ခု ဖြစ်ခဲ့ရင် အဲဒီကစပြီး ထုတ်လုပ်မှု နည်းတာက Cedar Hill အတွက် ပုံမှန် ဖြစ်သွားမှာပါ။ ဒါဆိုရင် flag တစ်ခုတည်းကို နေ့တိုင်း ထပ်မပေါ်အောင် ခရိုင်က အဲဒီ array ဆီက မျှော်လင့်တဲ့ ပမာဏကို ချိန်ညှိရပါလိမ့်မယ်။

Cut-off (flag လုပ်မယ့် သတ်မှတ်ချက်) ရွေးတာက တစ်ခုရရင် တစ်ခုလျှော့ရတဲ့ ချိန်ဆမှု (trade-off) ပါ။ ပိုတင်းကျပ်တဲ့ rule (တခြား array တွေထက် 5% နည်းရင် flag လုပ်တာ) က ချို့ယွင်းချက် သေးသေးလေးတွေကို ပိုစောစော ရှာတွေ့ပေမယ့် ဖုန်နည်းနည်းပဲ တက်နေတဲ့ array တွေဆီကိုပါ စက်ပြင်ဆရာတွေကို လွှတ်ရပါတယ်။ ပိုလျော့တဲ့ rule (40% နည်းမှ flag လုပ်တာ) ဆိုရင် အလကား သွားရတဲ့ အကြိမ် နည်းပေမယ့် 33% နဲ့ 35% နည်းခဲ့တဲ့ Cedar Hill ကို လွတ်သွားမှာပါ။

Record တစ်ခုစီကို သူ့ကိုယ်ပိုင် အခြေအနေမှာ ပုံမှန် ဖြစ်တာနဲ့ နှိုင်းယှဉ်တဲ့ ဒီ အယူအဆကိုပဲ card လိမ်လည်မှု၊ network (ကွန်ရက်) ပေါ်က ပုံမှန်မဟုတ်တဲ့ traffic (ဒေတာ စီးဆင်းမှု) နဲ့ ပျက်ဖို့ စလာတဲ့ စက်တွေကို ရှာတွေ့ဖို့ သုံးပါတယ်။

Quick Check (အမြန် စစ်ဆေးမေးခွန်း)

Q1. Data warehouse ကို အကောင်းဆုံး ဖော်ပြထားတာက ဘယ်ဟာလဲ။

Q2. ဒီထဲက ဘယ်ဟာက OLAP workload လဲ။

Q3. အောက်ပါတို့ထဲက data warehouse ရဲ့ property မဟုတ်တာက ဘယ်ဟာလဲ။

Q4. Classification နဲ့ clustering ကြားက အဓိက ကွာခြားချက်က ဘာလဲ။

Q5. ရေ ကုမ္ပဏီ တစ်ခုက အိမ်တိုင်းရဲ့ ရေသုံးစွဲမှုကို နာရီတိုင်း မှတ်တမ်းတင်ပါတယ်။ ဖတ်ချက်တွေထဲက ဘယ်ဟာကိုမှ label မတပ်ထားပါဘူး။ ကုမ္ပဏီက အိမ် တစ်အိမ်စီရဲ့ ဖတ်ချက်တွေကို အဲဒီအိမ်ရဲ့ ပုံမှန် ပုံစံနဲ့ နှိုင်းယှဉ်ပြီး ပုံမှန်နဲ့ အဝေးကြီး ကွာနေတဲ့ အိမ် အနည်းငယ်ကို ရှာပါတယ်၊ ဥပမာ တစ်ညလုံး ရေ စီးနေတာမျိုးပါ၊ အဲဒါက ရေယိုနေတာ ဖြစ်နိုင်ပါတယ်။ ဒီလို ပုံမှန်မဟုတ်တဲ့ record တွေကို ဘယ် data-mining technique က ရှာဖော်ပေးသလဲ။

Q6. Business analyst တစ်ယောက်ကို dimension အများကြီး ပါတဲ့ data cube ကို interactive ပုံစံနဲ့ slice လုပ်ပြီး drill down လုပ်ကြည့်နိုင်စေတဲ့ နည်းပညာက ဘာလဲ။

Technique ကို ခွဲခြားပါ

အခြေအနေ တစ်ခုစီအတွက် data-mining technique ကို ဖော်ပြပါ။ အဖြေကို အောက်ပါ English စကားလုံးတွေထဲက တစ်ခုနဲ့ ရိုက်ထည့်ပါ: classification, clustering, regression, association, sequential, anomaly။

အခြေအနေ	Technique
ပြီးခဲ့တဲ့ ငါးနှစ်စာ ရောင်းအား ဒေတာကနေ နောက်သုံးလပတ်ရဲ့ ဝင်ငွေကို ခန့်မှန်းခြင်း။
Streaming service (အင်တာနက်ကနေ ဗီဒီယို တိုက်ရိုက် ကြည့်ရတဲ့ ဝန်ဆောင်မှု) တစ်ခုရဲ့ ကြည့်ရှုသူတွေကို ကြိုတင် သတ်မှတ်ထားတဲ့ အုပ်စု မရှိဘဲ သူတို့ ကြည့်တဲ့ အစီအစဉ် အမျိုးအစားတွေအလိုက် အုပ်စုဖွဲ့ခြင်း။
Web server ရဲ့ log ထဲမှာ ဒီရက်ပိုင်း ပုံမှန် request (တောင်းဆိုမှု) တွေနဲ့ အရမ်းကွာတဲ့ entry (မှတ်တမ်း တစ်ကြောင်း) ကို flag လုပ်ခြင်း။
စူပါမားကတ်မှာ စတော်ဘယ်ရီ ဝယ်တဲ့သူတွေက တစ်ခေါက်တည်းမှာ နို့ခရင်မ် (cream) ကိုလည်း ဝယ်တတ်တာကို ရှာတွေ့ခြင်း။
ဥယျာဉ်မှူးတွေ မှတ်ပြီးသား ဓာတ်ပုံတွေနဲ့ train လုပ်ထားတဲ့ model ကို သုံးပြီး ပျိုးပင်ငယ် ဓာတ်ပုံ တစ်ပုံက ကျန်းမာတဲ့ အပင်လား၊ ရောဂါရနေတဲ့ အပင်လား ဆုံးဖြတ်ခြင်း။
Product တစ်ခုရဲ့ review (သုံးသပ်ချက်) တွေကို ဖတ်ပြီးနောက် basket (ဈေးခြင်း) ထဲ ထည့်တဲ့ ဈေးဝယ်သူတွေက သုံးရက်အတွင်း ပြန်လာပြီး ဝယ်တတ်တာကို ရှာတွေ့ခြင်း။

Fill in the Blanks (ကွက်လပ် ဖြည့်ခြင်း)

Data warehouse နဲ့ business intelligence အကြောင်း ဖော်ပြချက်ကို ပြည့်စုံအောင် ဖြည့်ပါ။ စာကြောင်းတွေက English လို ဖြစ်လို့ ကွက်လပ်တွေကို English စကားလုံးနဲ့ ရိုက်ထည့်ပါ:

WAREHOUSE AND BUSINESS INTELLIGENCE
===================================
Analysts and managers read a warehouse's data but do not change it
once it is loaded. This property is called .

The pipeline that extracts data from many sources, then cleans and
converts it before loading it into the warehouse, is called .

The interactive software that lets analysts slice, dice and drill
down into the warehouse's data is called .

The broader practice of finding patterns automatically is called
.

The general name for using data to support decisions is
.

စာကြောင်းတွေရဲ့ အဓိပ္ပာယ် (____ က ကွက်လပ်ပါ):
Analyst တွေနဲ့ manager တွေက warehouse ရဲ့ ဒေတာကို load လုပ်ပြီးရင် ဖတ်ပဲ ဖတ်ပြီး မပြောင်းလဲပါဘူး။ ဒီ property ကို ____ လို့ ခေါ်ပါတယ်။
ရင်းမြစ် အများကြီးကနေ ဒေတာကို ထုတ်ယူပြီး warehouse ထဲ load မလုပ်ခင် သန့်စင်၊ ပြောင်းလဲပေးတဲ့ pipeline ကို ____ လို့ ခေါ်ပါတယ်။
Analyst တွေကို warehouse ရဲ့ ဒေတာကို slice၊ dice နဲ့ drill down လုပ်နိုင်စေတဲ့ interactive software ကို ____ လို့ ခေါ်ပါတယ်။
ပုံစံတွေကို အလိုအလျောက် ရှာဖွေတဲ့ ပိုကျယ်ပြန့်တဲ့ နည်းလမ်းကို ____ လို့ ခေါ်ပါတယ်။
ဆုံးဖြတ်ချက်တွေ ချဖို့ ဒေတာကို အသုံးချတာရဲ့ ယေဘုယျ အမည်က ____ ပါ။

Spot the Error (အမှား ရှာခြင်း)

ကျောင်းသား တစ်ယောက်က data warehouse အကြောင်း ပြန်လှန်လေ့ကျင့်ဖို့ မှတ်စု ရေးထားပါတယ်။ Line တစ်ကြောင်း မှားနေပါတယ်။ အမှားပါတဲ့ line ကို ရွေးပါ၊ ပြီးရင် မှန်ကန်တဲ့ ပြင်နည်းကို ရွေးပါ။

1A data warehouse is subject-oriented, integrated, time-variant, and non-volatile 2It is optimised for analytical queries rather than transactional updates 3Its rows are updated one at a time, as each sale or booking happens 4The ETL pipeline loads it from operational source systems 5OLAP is the interactive layer used by business analysts to query the warehouse

Line တွေရဲ့ အဓိပ္ပာယ်: (1) Data warehouse က subject-oriented၊ integrated၊ time-variant နဲ့ non-volatile ဖြစ်ပါတယ်။ (2) Transaction update တွေအတွက် မဟုတ်ဘဲ ခွဲခြမ်းစိတ်ဖြာရေး query တွေအတွက် optimise လုပ်ထားပါတယ်။ (3) အရောင်း ဒါမှမဟုတ် booking တစ်ခုစီ ဖြစ်တိုင်း သူ့ row တွေကို တစ်ခုချင်း update လုပ်ပါတယ်။ (4) ETL pipeline က operational source system တွေကနေ ဒေတာကို load လုပ်ပေးပါတယ်။ (5) OLAP က business analyst တွေ warehouse ကို query လုပ်ဖို့ သုံးတဲ့ interactive အလွှာ ဖြစ်ပါတယ်။

Line 3 အတွက် မှန်ကန်တဲ့ ပြင်နည်းကို ရွေးပါ:

အယူအဆကို ဖော်ထုတ်ပါ

စနစ် တစ်ခုက ပြီးဆုံးသွားတဲ့ order တွေကို 7 နှစ်စာ သိမ်းထားပါတယ်။ Row တစ်ခုချင်း update မလုပ်ပါဘူး၊ မနက်တိုင်း 02:00 မှာပဲ bulk load တွေကို လက်ခံပြီး analyst တွေက ရေရှည် trend တွေကို စောင့်ကြည့်ဖို့ သုံးပါတယ်။ ဘယ်လို စနစ် အမျိုးအစားကို ဖော်ပြနေတာလဲ။

Term ကို English လို ရိုက်ထည့်ပါ (ဥပမာ OLTP database)။

အိမ်မွေး တိရစ္ဆာန် ဆိုင် တစ်ဆိုင်ရဲ့ ဒေတာ အဖွဲ့က ငါးကန် (aquarium) ဝယ်တဲ့ customer တွေရဲ့ 60% က တစ်ခေါက်တည်းမှာ ငါးစာကိုလည်း ဝယ်တာကို တွေ့ပါတယ်။ ဒီ rule ကို ဘယ် data-mining technique က ရှာတွေ့ခဲ့တာလဲ။

Technique ရဲ့ နာမည်ကို English လို ရိုက်ထည့်ပါ။

Practice Exercises (လေ့ကျင့်ခန်းများ)

လေ့ကျင့်ခန်း တစ်ခုစီရဲ့ ရှေ့မှာ အဆင့် ([Core] စသဖြင့်)၊ ခေါင်းစဉ် link နဲ့ [4 marks] လို mark allocation (မေးခွန်း တစ်ခုစီအတွက် ပေးတဲ့ အမှတ်) ပါပါတယ်။ အမှတ်တွေက IB စာမေးပွဲ ပုံစံအတိုင်းပါ: IB သင်တန်း မတက်တဲ့သူတွေကတော့ အဖြေကို ဘယ်လောက် အသေးစိတ် ရေးရမလဲ ပြတဲ့ လမ်းညွှန်အဖြစ် သုံးနိုင်ပါတယ်။

Core (အခြေခံ အဆင့်၊ HL)

[Core] Warehouses and OLAP (HL) [2 marks] နှင်းလျှောစီး အပန်းဖြေ စခန်း (ski resort) တစ်ခုမှာ lift (တောင်ပေါ် တက်တဲ့ ကြိုးဆွဲ ထိုင်ခုံ) တစ်ခုစီရဲ့ ဂိတ်တွေက lift pass (lift စီးခွင့် ကတ်) scan လုပ်တိုင်းကို resort ရဲ့ လက်မှတ် စနစ်ထဲမှာ မှတ်တမ်းတင်ပြီး ညတိုင်း အဲဒီနေ့ရဲ့ scan တွေကို data warehouse ထဲ copy ကူးပါတယ်။ Resort ရဲ့ စီမံကိန်း ရေးဆွဲသူတွေက သူတို့ရဲ့ report တွေကို လက်မှတ် စနစ်ပေါ်မှာ မဟုတ်ဘဲ warehouse ပေါ်မှာ run ရတဲ့ အကြောင်းရင်း နှစ်ခုကို Outline (အကျဉ်းချုပ် ဖော်ပြပါ)။
[Core] Warehouses and OLAP (HL) [4 marks] Data warehouse ရဲ့ property ခြောက်ခုထဲက လေးခုကို State (ဖော်ပြပါ)၊ ပြီးရင် တစ်ခုစီအတွက် စာကြောင်း တစ်ကြောင်းနဲ့ အကျဉ်းချုပ် ပေးပါ။
[Core] Warehouses and OLAP (HL) [4 marks] OLTP workload နဲ့ OLAP workload ကြားက ကွာခြားချက်ကို Distinguish (အရာ နှစ်ခု ဒါမှမဟုတ် ပိုများတဲ့ အရာတွေကြားက ကွာခြားချက်ကို ရှင်းရှင်းလင်းလင်း ပြပါ) လုပ်ပြီး တစ်ခုစီအတွက် ဥပမာ တစ်ခုစီ ပေးပါ။

Extension (တိုးချဲ့ အဆင့်၊ HL)

[Extension] Warehouses and OLAP (HL) [6 marks] နိုင်ငံ 12 နိုင်ငံမှာ ဆိုင်ခွဲတွေ ဖွင့်ထားတဲ့ စူပါမားကတ် လုပ်ငန်းစု တစ်ခုအတွက် data warehouse ရဲ့ အဓိက ရည်ရွယ်ချက်တွေကို Explain (ရှင်းပြပါ)။
[Extension] Warehouses and OLAP (HL) [4 marks] အပြင်ထွက် ခရီးသုံး ပစ္စည်း အဟောင်းတွေ (တဲ၊ ကျောပိုးအိတ်၊ ဖိနပ်ရှည်) ရောင်းဝယ်တဲ့ online ဈေးကွက် တစ်ခုက သူ့ listing (ရောင်းဖို့ တင်ထားတဲ့ ပစ္စည်း စာရင်း) တွေနဲ့ အရောင်းတွေကို data warehouse ထဲမှာ သိမ်းထားပြီး data mining နဲ့ လုပ်ချင်တဲ့ အလုပ် နှစ်ခု ရှိပါတယ်။ အလုပ် A: moderator (စည်းကမ်း စစ်ဆေးသူ) တွေက ယခင် listing 50,000 ကို စစ်ပြီးသား ဖြစ်ပြီး တစ်ခုစီကို “allowed” (ခွင့်ပြု) ဒါမှမဟုတ် “breaks the rules” (စည်းကမ်း ချိုးဖောက်) လို့ မှတ်ထားပါတယ် (8,000 ခန့်ကို “breaks the rules” လို့ မှတ်ထားပါတယ်)၊ ကုမ္ပဏီက listing အသစ် တစ်ခုစီကို တင်လိုက်တာနဲ့ ဒီ အုပ်စု နှစ်စုထဲက တစ်စုထဲ ထည့်ချင်ပါတယ်။ အလုပ် B: marketing အဖွဲ့က ဝယ်သူ တစ်ယောက်စီရဲ့ ဝယ်ယူမှုတွေ၊ ပေးတဲ့ ဈေးနှုန်းတွေနဲ့ ဈေးဝယ်တဲ့ အချိန်တွေကို သုံးပြီး ဘယ်လို ဝယ်သူ အမျိုးအစားတွေ site ကို သုံးလဲ ဆိုတာကို အမျိုးအစားတွေ ကြိုမသတ်မှတ်ဘဲ သိချင်ပါတယ်။ အလုပ် တစ်ခုစီအတွက် သင့်တော်တဲ့ data-mining technique ကို identify (ဖြစ်နိုင်တဲ့ အဖြေတွေထဲက ရွေးပြီး ဖော်ပြပါ) လုပ်ပြီး သင့်ရွေးချယ်မှုကို justify (ဘာကြောင့် ရွေးတာလဲ အကြောင်းပြချက်နဲ့ ပြပါ) လုပ်ပါ။
[Extension] Warehouses and OLAP (HL) [4 marks] Online ဂိမ်း ကုမ္ပဏီ တစ်ခုက လိမ်ညာ ကစားတဲ့ software (cheating software) သုံးနေနိုင်တဲ့ account တွေကို ရှာချင်ပါတယ်။ သူ့ data warehouse ထဲမှာ ပွဲစဉ် သန်းပေါင်းများစွာ ရှိပေမယ့် လိမ်ညာ ကစားတယ်လို့ အတည်ပြုခဲ့ဖူးတဲ့ account က လက်ချိုးရေလို့ ရလောက်အောင်ပဲ ရှိပါတယ်။ ဒီပြဿနာအတွက် anomaly detection က classification ထက် ဘာကြောင့် ပိုသင့်တော်လဲ Explain လုပ်ပြီး flag လုပ်ခံရတဲ့ account ကို ပိတ်ပင် (ban) မလုပ်ခင် ဘာကြောင့် လူ တစ်ယောက်က စစ်ဆေးသင့်လဲ outline လုပ်ပါ။

Challenge (စိန်ခေါ်မှု အဆင့်၊ HL)

[Challenge] Warehouses and OLAP (HL) [6 marks] ဆေးရုံ အများကြီး ပိုင်ဆိုင်တဲ့ ဆေးရုံ လုပ်ငန်းစု ကြီး တစ်ခုမှာ business intelligence ကို ကူညီဖို့ data warehouse၊ OLAP tool တွေနဲ့ data mining တို့ ဘယ်လို ပူးပေါင်း အလုပ်လုပ်လဲ Discuss (အမြင် အမျိုးမျိုးကို ချိန်ဆပြီး ဆွေးနွေးပါ)။ သုံးခုလုံး ပေါင်းပြီး ကူညီပေးနိုင်မယ့် ဆုံးဖြတ်ချက်တွေရဲ့ တိကျတဲ့ ဥပမာတွေကို ထည့်ပြောပါ။
[Challenge] Warehouses and OLAP (HL) [6 marks] ထောက်ခံသူ 3,000 ယောက်နဲ့ ရန်ပုံငွေ ရှာတဲ့ platform တစ်ခုတည်းပဲ ရှိတဲ့ ပရဟိတ အဖွဲ့ သေးသေး တစ်ခုက data warehouse တည်ဆောက်ဖို့ ရင်းနှီးသင့်သလား၊ ဒါမှမဟုတ် သူ့ operational database ကို တိုက်ရိုက် query လုပ်တာနဲ့ပဲ လုံလောက်မလား Evaluate (အားသာချက်နဲ့ အားနည်းချက်တွေကို ချိန်ဆပြီး အကဲဖြတ်ပါ)။ ဒေတာ ပမာဏ၊ query ရဲ့ ရှုပ်ထွေးမှု၊ ကုန်ကျစရိတ်နဲ့ ရရှိမယ့် အကျိုးကျေးဇူး တို့ကို ထည့်ပြောပါ။

IB CS လေ့လာနေသူတွေအတွက် မှတ်ချက်: A3.4.2 (warehouse) နဲ့ A3.4.3 (OLAP နဲ့ data mining) က HL အပိုင်းတွေ ဖြစ်ပါတယ်။ စာအုပ်ဟောင်းတွေမှာ technique တချို့ကို တခြား နာမည်တွေနဲ့ ခေါ်ပါတယ်: syllabus က regression လို့ ခေါ်တာကို “forecasting” (ကြိုတင် ခန့်မှန်းခြင်း) လို့ ခေါ်ပြီး anomaly detection ကို “deviation detection” လို့ ခေါ်ပါတယ်။ အဲဒီ စာအုပ်တွေမှာ syllabus မှာ မပါတဲ့ link analysis (ဆက်နွယ်မှုတွေကို ခွဲခြမ်းစိတ်ဖြာခြင်း) နဲ့ data matching (ကိုက်ညီတဲ့ ဒေတာတွေကို ရှာတွဲခြင်း) ကိုလည်း ထည့်ထားပါတယ်။ Data warehouse ရဲ့ ရည်ရွယ်ချက်တွေကို ရှင်းပြဖို့ ရည်ရွယ်ချက် တစ်ခုစီကို နာမည် အရင် ပြောပြီးမှ ချဲ့ပြီး ရှင်းပြပါ။

ဆက်စပ် ခေါင်းစဉ်များ

အရင် ခေါင်းစဉ်: Alternative Databases (အခြား database ပုံစံများ)။ Relational database (table တွေ ချိတ်ဆက်ထားတဲ့ database) မဟုတ်တဲ့ database တွေနဲ့ အထူး ရည်ရွယ်ချက်အတွက် database နည်းလမ်းတွေကို ပိုကျယ်ကျယ် ကြည့်တဲ့ နောက်ခံ အကြောင်းအရာပါ။
ဆက်စပ် ခေါင်းစဉ်: Normalisation။ Warehouse တွေက တမင် denormalise လုပ်ပါတယ် (normalisation ရဲ့ ဆန့်ကျင်ဘက် လမ်းကြောင်း)၊ denormalisation ကို အကဲဖြတ်တဲ့ အပိုင်း (A3.2.7) ကိုလည်း ကြည့်ပါ။
ဆက်စပ် ခေါင်းစဉ်: Transactions and Views။ Materialised view (ရလဒ်ကို သိမ်းထားတဲ့ view) တွေက ဒီ အယူအဆကိုပဲ database တစ်ခုတည်းအတွင်းမှာ အသေးစား သုံးပါတယ်: ဖတ်တဲ့အခါ မြန်အောင် အကျဉ်းချုပ် တစ်ခုကို ကြိုတွက်ထားပါတယ်။
နောက် ခေါင်းစဉ် (HL): Distributed Databases။ အကြီးဆုံး warehouse တွေက သူတို့ ဒေတာကို server အများကြီးပေါ်မှာ ဖြန့်ထားတာကြောင့် distributed database (နေရာ အများမှာ ခွဲသိမ်းထားတဲ့ database) တွေလည်း ဖြစ်ပါတယ်။
Machine Learning: Types of Learning မှာ classification၊ clustering နဲ့ association rule တွေ (A4.3.2, A4.3.4, A4.3.5) ကို လေ့လာနိုင်ပြီး Training and Evaluating မှာ linear regression (ဒေတာကြား မျဉ်းဖြောင့် ဆွဲပြီး ခန့်မှန်းခြင်း၊ A4.3.1) ကို လေ့လာနိုင်ပါတယ်။