Entity-Relationship Diagrams (entity တွေနဲ့ ဆက်နွယ်မှုတွေကို ပြတဲ့ ပုံများ)

A3.2.2: Construct ERDs, including cardinality and modality of the relationships between entities.
မြန်မာလို: entity (database ထဲမှာ ဒေတာ သိမ်းမယ့် အရာ တစ်ခု) တွေကြားက relationship (entity တွေကြားက ဆက်နွယ်မှု) တွေရဲ့ cardinality (ဆက်နွယ်မှု တစ်ဖက်စီရဲ့ အများဆုံး အရေအတွက်) နဲ့ modality (ဆက်နွယ်မှုမှာ မဖြစ်မနေ ပါရမလား ဆိုတာ) ကို ထည့်ပြီး ERD တွေကို ကိုယ်တိုင် တည်ဆောက်နိုင်ရပါမယ်။

အဓိက အယူအဆများ

ERD ဆိုတာ ဘာလဲ

Entity-Relationship Diagram (ERD) ဆိုတာ table (database ထဲက ဇယား) တွေကို မတည်ဆောက်ခင် database (ဒေတာ သိမ်းဆည်းတဲ့ စနစ်) ရဲ့ ဖွဲ့စည်းပုံကို ပုံနဲ့ ဖော်ပြတဲ့ notation (ရေးဆွဲပုံ စနစ်) တစ်ခုပါ။ ERD က အောက်ပါတို့ကို ပြပါတယ်:

  • Entity တွေ (table တွေ ဖြစ်လာမယ့် လက်တွေ့ ကမ္ဘာက အရာတွေ)
  • Attribute တွေ (entity တစ်ခုစီမှာ ပါတဲ့ column (ဒေါင်လိုက် ကော်လံ) တွေ)
  • Relationship တွေ (entity တွေ အချင်းချင်း ဘယ်လို ချိတ်ဆက်နေလဲ)
  • Relationship တစ်ခုစီရဲ့ cardinality (တစ်ဖက်က ဘယ်နှစ်ခုက နောက်တစ်ဖက်က ဘယ်နှစ်ခုနဲ့ ချိတ်ဆက်လဲ)
  • Relationship တစ်ခုစီရဲ့ modality (ပါဝင်ဖို့ မဖြစ်မနေ လိုအပ်လား (mandatory)၊ မပါလည်း ရလား (optional))

Database Schemas မှာ လေ့လာခဲ့တဲ့ conceptual schema (entity တွေနဲ့ အဓိက ဆက်နွယ်မှုတွေကိုပဲ ပြတဲ့ အကြမ်းဖျင်း ဒီဇိုင်း) နဲ့ logical schema (table၊ column နဲ့ key တွေကို အသေးစိတ် ပြတဲ့ ဒီဇိုင်း) တွေအတွက် ERD က စံအဖြစ် သုံးတဲ့ ပုံပါ။ ERD ရှင်းရှင်းလင်းလင်း ရှိရင် developer (software ရေးသူ)၊ designer နဲ့ stakeholder (project နဲ့ သက်ဆိုင်သူ) တွေက ဒေတာ မရှိသေးခင်မှာ ပြင်ရတာ ကုန်ကျစရိတ် နည်းတဲ့ စာရွက်ပေါ်မှာ ဖွဲ့စည်းပုံကို သဘောတူညီနိုင်ပါတယ်။

ERD က အစီအစဉ် ဆွဲဖို့နဲ့ အချင်းချင်း ဆက်သွယ် ပြောဆိုဖို့ သုံးတဲ့ tool တစ်ခုပါ။ Entity တွေနဲ့ သူတို့ ဘယ်လို ဆက်နွယ်နေလဲဆိုတာကို စာမျက်နှာ တစ်ခုတည်းမှာ ပြပေးပြီး ဘယ် DBMS (database ကို စီမံတဲ့ software) ပေါ်မှာမှ မမူတည်ပါဘူး။ ဒါကြောင့် designer တွေ၊ developer တွေနဲ့ client (database ကို သုံးမယ့်သူ) က ဘာမှ မတည်ဆောက်ခင် ဖွဲ့စည်းပုံကို သဘောတူညီနိုင်ပါတယ်။ ERD ကို ဘာအတွက် သုံးလဲလို့ မေးခွန်းက မေးရင် သူ့သင်္ကေတတွေ ဘယ်လို ပုံစံရှိလဲ ဆိုတာကို မရေးပါနဲ့၊ သူ့ရည်ရွယ်ချက် (အစီအစဉ် ဆွဲခြင်း၊ abstraction (မလိုတဲ့ အသေးစိတ်ကို ဖယ်ပြီး အဓိကကိုပဲ ကြည့်ခြင်း)၊ အချင်းချင်း ဆက်သွယ် ပြောဆိုခြင်း၊ အဖွဲ့လိုက် ပူးပေါင်း ဆောင်ရွက်ခြင်း) အကြောင်းကို ရေးပါ။

Entity နဲ့ Attribute

Entity ဆိုတာ database က မှတ်တမ်း ထိန်းထားဖို့ လိုတဲ့ လက်တွေ့ ကမ္ဘာက အရာ တစ်ခုပါ၊ ဥပမာ Member (အသင်းဝင်)၊ Class (အတန်း)၊ Order (မှာယူမှု)၊ Vehicle (ယာဉ်)။ တကယ် တည်ဆောက်ပြီးသား database မှာ entity တစ်ခုက များသောအားဖြင့် table တစ်ခု ဖြစ်လာပြီး entity ရဲ့ instance (entity ထဲက တစ်ခုချင်းစီ၊ ဥပမာ member တစ်ယောက်) တစ်ခုစီက row (အလျားလိုက် အတန်း) တစ်ခု ဖြစ်လာပါတယ်။

Attribute ဆိုတာ entity တစ်ခုရဲ့ ဂုဏ်သတ္တိ တစ်ခုပါ၊ record (အချက်အလက် အများကြီး စုထားတဲ့ ဒေတာ တစ်ခု) တိုင်းမှာ ပါတဲ့ column တွေပါ။ Member entity မှာ MemberID၊ FirstName၊ Surname၊ DateOfBirth၊ MembershipTier ဆိုတဲ့ attribute တွေ ရှိနိုင်ပါတယ်။

ERD တွေမှာ entity တွေကို များသောအားဖြင့် entity နာမည် ထည့်ရေးထားတဲ့ စတုဂံ (rectangle) တွေနဲ့ ဆွဲပါတယ်။ Attribute တွေကိုတော့ ဘယ် notation ပုံစံကို သုံးလဲ ပေါ်မူတည်ပြီး စတုဂံထဲမှာ စာရင်းလိုက် ရေးတာ ဒါမှမဟုတ် စတုဂံနဲ့ ချိတ်ထားတဲ့ ဘဲဥပုံ (ellipse) တွေနဲ့ ဆွဲတာ လုပ်ပါတယ်။

Relationship၊ Cardinality နဲ့ Modality

Relationship ဆိုတာ entity နှစ်ခုကြားက အဓိပ္ပာယ်ရှိတဲ့ ချိတ်ဆက်မှု တစ်ခုပါ၊ ဥပမာ “Member တစ်ယောက်က Booking (ကြိုတင် စာရင်းပေးမှု) တစ်ခုကို လုပ်တယ်“၊ “Class တစ်ခုမှာ Booking တွေ ရှိတယ်“။ Relationship တိုင်းမှာ အရေးကြီးတဲ့ ဂုဏ်သတ္တိ နှစ်ခု ရှိပါတယ်:

Cardinality: ဘက်တစ်ဖက်စီမှာ ပါနိုင်တဲ့ instance အရေအတွက်ရဲ့ အများဆုံး:

Cardinality သင်္ကေတ အဓိပ္ပာယ်
One-to-one (1:1) (တစ်ခုနဲ့ တစ်ခု) 1, 1 A ရဲ့ instance တစ်ခုက B ရဲ့ instance အများဆုံး တစ်ခုနဲ့ပဲ ချိတ်ဆက်ပြီး B ဘက်ကလည်း အဲဒီအတိုင်းပါပဲ။ ဥပမာ: စာသင်ခန်း တစ်ခန်းစီမှာ interactive whiteboard (ထိတွေ့ပြီး သုံးလို့ရတဲ့ smart ဘုတ်) အများဆုံး တစ်ခုပဲ ရှိပြီး whiteboard တစ်ခုစီကို စာသင်ခန်း တစ်ခန်းထဲမှာပဲ တပ်ဆင်ထားပါတယ်။
One-to-many (1:M) (တစ်ခုနဲ့ အများ) 1, M A ရဲ့ instance တစ်ခုက B ရဲ့ instance အများကြီးနဲ့ ချိတ်ဆက်နိုင်ပေမယ့် B တစ်ခုစီက A တစ်ခုနဲ့ပဲ ပြန်ချိတ်ပါတယ်။ ဥပမာ: coach (နည်းပြ) တစ်ယောက်က class အများကြီးကို သင်ပေးပါတယ်၊ class တစ်ခုစီမှာ coach တစ်ယောက်ပဲ ရှိပါတယ်။
Many-to-many (M:M) (အများနဲ့ အများ) M, M A တစ်ခုစီက B အများကြီးနဲ့ ချိတ်ဆက်နိုင်ပြီး B တစ်ခုစီကလည်း A အများကြီးနဲ့ ချိတ်ဆက်နိုင်ပါတယ်။ ဥပမာ: ကျောင်းသား တစ်ယောက်က course (သင်တန်း) အများကြီး တက်ပါတယ်၊ course တစ်ခုစီမှာ ကျောင်းသား အများကြီး ရှိပါတယ်။

Modality: ဘက်တစ်ဖက်စီမှာ ပါဝင်ရမယ့် အနည်းဆုံး ပမာဏ:

Modality အဓိပ္ပာယ်
Mandatory (မဖြစ်မနေ ပါရတဲ့) Instance တိုင်း ပါဝင်ရပါမယ်။ ဥပမာ: booking တိုင်းမှာ member တစ်ယောက် မဖြစ်မနေ ရှိရပါမယ်၊ member မရှိတဲ့ booking ဆိုတာ မဖြစ်နိုင်ပါဘူး။
Optional (မပါလည်း ရတဲ့) ပါဝင်ဖို့ မလိုအပ်ပါဘူး။ ဥပမာ: member တစ်ယောက်မှာ booking သုည ခု ရှိနိုင်ပါတယ်၊ ဘာမှ book မလုပ်ရသေးတဲ့ member အသစ်လည်း member ပါပဲ။

Relationship ကို ပြည့်ပြည့်စုံစုံ ဖော်ပြရင် ဘက်တစ်ဖက်စီမှာ ဘယ်နှစ်ခု (cardinality) ရော မဖြစ်မနေ လိုအပ်လား (modality) ပါ ပြောရပါတယ်။ ရှေးကျတဲ့ စာအုပ်နဲ့ ရှင်းပြချက် အများစုက cardinality ကိုပဲ ပြပေမယ့် row တစ်ခုက ဘာနဲ့မှ မချိတ်ဘဲ ရှိနိုင်လား ဆိုတာကို ပြောပြတာက modality ပါ။

Crow’s-Foot Notation (ကျီးကန်း ခြေထောက်ပုံ သင်္ကေတနဲ့ ဆွဲတဲ့ စနစ်)

လုပ်ငန်းခွင်မှာ တွင်တွင်ကျယ်ကျယ် သုံးတဲ့ ERD notation တစ်ခုက crow’s foot ပါ။ “Many” (အများ) ကို ပြဖို့ သုံးတဲ့ ခွ သုံးခွ ပါတဲ့ “crow’s foot” (ကျီးကန်း ခြေထောက်) သင်္ကေတကို အစွဲပြုပြီး နာမည်ပေးထားတာပါ။ Relationship line ရဲ့ အစွန်း တစ်ဖက်စီမှာ သင်္ကေတ နှစ်ခုစီ ပါပါတယ်: တစ်ခုက cardinality (one ဒါမှမဟုတ် many) အတွက်၊ နောက်တစ်ခုက modality (mandatory ဒါမှမဟုတ် optional) အတွက်ပါ။ အဲဒီ သင်္ကေတ နှစ်ခုကို တစ်တွဲတည်းအဖြစ် entity ဘက်ကနေ အပြင်ဘက်ကို ဖတ်သွားပါ။

Line အစွန်းက သင်္ကေတပုံသဏ္ဌာန်CardinalityModality
||အပြိုင် မျဉ်းတို နှစ်ချောင်းတစ်ခု (1)mandatory
|oမျဉ်းတို + စက်ဝိုင်းတစ်ခု (1)optional
>|crow's foot + မျဉ်းတိုအများ (M)mandatory
>ocrow's foot + စက်ဝိုင်းအများ (M)optional

Entity နဲ့ အနီးဆုံး သင်္ကေတက cardinality (one ဒါမှမဟုတ် many) ကို ပြပါတယ်၊ entity နဲ့ ပိုဝေးတဲ့ သင်္ကေတက modality (mandatory အတွက် မျဉ်းတို၊ optional အတွက် စက်ဝိုင်း) ကို ပြပါတယ်။

မူလ ERD ပုံစံ ဖြစ်တဲ့ Chen notation (Peter Chen၊ 1976) မှာ entity တွေကို စတုဂံ၊ သူတို့ကြားက relationship တွေကို စိန်ပုံ (diamond) နဲ့ attribute တွေကို ဘဲဥပုံ (ellipse) တွေနဲ့ ဆွဲပါတယ်။ Cardinality ကို line တွေပေါ်မှာ label (1၊ M ဒါမှမဟုတ် N) အဖြစ် ရေးပြီး တချို့ ပုံစံတွေမှာ mandatory ပါဝင်မှုကို မျဉ်းနှစ်ထပ်နဲ့ ပြပါတယ်။ Relationship တစ်ခုစီက နာမည်ပေးလို့ရတဲ့ ပုံသဏ္ဌာန် တစ်ခု ဖြစ်လာပေမယ့် ပုံကြီးတွေမှာ crow’s foot ထက် နေရာ ပိုယူပါတယ်။

Crow’s-Foot ပုံကို ဖတ်နည်း 

   MEMBER ||---------------o< BOOKING

အစွန်း တစ်ဖက်စီက သင်္ကေတတွေက နောက်တစ်ဖက် အစွန်းက entity တစ်ခုနဲ့ အဲဒီ အစွန်းက entity ဘယ်နှစ်ခု တွဲလဲ ဆိုတာကို ပြောပြပါတယ်:

  • MEMBER အစွန်း (||): BOOKING ဘက်ကနေ MEMBER ဘက်ကို ကြည့်ရင် member တစ်ယောက် အတိအကျ၊ mandatory ပါ: booking တိုင်းက member တစ်ယောက်တည်းနဲ့ အတိအကျ သက်ဆိုင်ရပါမယ်။
  • BOOKING အစွန်း (o<၊ စက်ဝိုင်းနဲ့ crow’s foot): MEMBER ဘက်ကနေ BOOKING ဘက်ကို ကြည့်ရင် booking အများ၊ optional ပါ: member တစ်ယောက်မှာ booking ဘယ်နှစ်ခုမဆို ရှိနိုင်ပြီး သုည ခုလည်း ဖြစ်နိုင်ပါတယ်။

စကားလုံးနဲ့ ပြောရရင်: “Member တစ်ယောက်မှာ booking သုည ခု ဒါမှမဟုတ် အများကြီး ရှိပါတယ်၊ booking တစ်ခုစီက member တစ်ယောက်တည်းနဲ့ အတိအကျ သက်ဆိုင်ပါတယ်။”

ဒါက modality “many ဘက်မှာ optional၊ one ဘက်မှာ mandatory” ဖြစ်တဲ့ one-to-many (1:M) relationship တစ်ခုပါ။ လက်တွေ့ database တွေမှာ အရမ်း အဖြစ်များတဲ့ ပုံစံပါ။

Many-to-Many ကို Junction Table နဲ့ ဖြေရှင်းခြင်း

Many-to-many relationship တွေကို relational database (table တွေ ချိတ်ဆက်ထားတဲ့ database) ထဲမှာ တိုက်ရိုက် သိမ်းလို့ မရပါဘူး။ “ဒီ member က ဒီ class တွေ အားလုံးနဲ့ ချိတ်ဆက်ထားတယ်” ဆိုတာကို row တစ်ခုတည်းထဲမှာ သေသေသပ်သပ် ထည့်ဖို့ နည်းလမ်း မရှိပါဘူး။ စံ ဖြေရှင်းနည်းက အဓိက entity နှစ်ခုကြားမှာ junction table (entity နှစ်ခုကြားမှာ ထားပြီး ချိတ်ပေးတဲ့ table၊ linking၊ bridge ဒါမှမဟုတ် associative table လို့လည်း ခေါ်ပါတယ်) တစ်ခု ထည့်တာပါ။

MEMBER နဲ့ CLASS ကြားက many-to-many က အောက်ပါအတိုင်း ဖြစ်လာပါတယ်:

   MEMBER ||---o< BOOKING >o---|| CLASS

BOOKING က အလယ်မှာ ရှိပြီး အထဲဘက်ကို ညွှန်နေတဲ့ one-to-many relationship နှစ်ခု ဖြစ်လာပါတယ်။ BOOKING table မှာ အောက်ပါတို့ ပါပါတယ်:

  • သူ့ကိုယ်ပိုင် primary key (row တစ်ခုချင်းကို ခွဲခြားပေးတဲ့ key) ဖြစ်တဲ့ BookingID
  • MEMBER ကို ညွှန်းတဲ့ foreign key (တခြား table ရဲ့ primary key ကို ညွှန်းတဲ့ column) ဖြစ်တဲ့ MemberID
  • CLASS ကို ညွှန်းတဲ့ foreign key ဖြစ်တဲ့ ClassID
  • booking ကိုယ်တိုင် ကို ဖော်ပြတဲ့ attribute တွေ (BookedOn၊ Status)

Relational database မှာ M:M relationship ကို junction table တစ်ခုအဖြစ် အကောင်အထည် ဖော်ပါတယ်။

ERD တစ်ခု တည်ဆောက်တဲ့ အဆင့်များ

ERD တစ်ခုကို Construct (ကိုယ်တိုင် တည်ဆောက်ပါ) လုပ်ခိုင်းတဲ့ မေးခွန်း (“Construct an ERD for this scenario”) အတွက် စိတ်ချရတဲ့ လုပ်ငန်းစဉ် တစ်ခုပါ:

  1. Scenario (မေးခွန်းမှာ ပေးထားတဲ့ အခြေအနေ) ကို နှစ်ခါ ဖတ်ပါ။ Noun (နာမ်) တိုင်း (entity ဖြစ်နိုင်တဲ့ အရာတွေ) နဲ့ verb (ကြိယာ) တိုင်း (relationship ဖြစ်နိုင်တဲ့ အရာတွေ) ကို မျဉ်းသားပါ။
  2. Entity တွေကို ရွေးပါ။ Noun တွေကို အုပ်စုခွဲပါ: သီးခြား table တစ်ခု လိုမယ့် အရာတွေက entity တွေပါ။ နောက် entity တစ်ခုကို ဖော်ပြရုံ သက်သက်ပဲ ဖြစ်တဲ့ အရာတွေက attribute တွေပါ။
  3. Entity တစ်ခုစီအတွက် box (အကွက်) တစ်ခု ဆွဲပြီး နာမည် ပေးပါ (အနည်းကိန်း noun ကို စာလုံးကြီး အားလုံးနဲ့ ရေးတာက အသုံးများတဲ့ convention (အများ လိုက်နာတဲ့ ထုံးစံ) ပါ: MEMBER၊ CLASS)။
  4. Box တစ်ခုစီထဲမှာ အဓိက attribute တွေကို စာရင်းလိုက် ရေးပါ၊ အနည်းဆုံး primary key ကိုတော့ ထည့်ပါ။
  5. စာထဲမှာ ပါတဲ့ relationship တစ်ခုစီအတွက် entity နှစ်ခုကြားမှာ line တစ်ကြောင်း ဆွဲပြီး အဲဒီ line ပေါ်မှာ verb phrase (ကြိယာ စကားစု) တစ်ခု ရေးပါ (makes (လုပ်တယ်)၊ belongs to (သက်ဆိုင်တယ်)၊ has (ရှိတယ်)၊ assigned to (တာဝန်ပေးထားတယ်))။
  6. အစွန်း တစ်ဖက်စီမှာ cardinality ကို ဆုံးဖြတ်ပါ။ “X တစ်ခု ရှိရင် Y ဘယ်နှစ်ခု ရှိနိုင်လဲ” နဲ့ “Y တစ်ခု ရှိရင် X ဘယ်နှစ်ခု ရှိနိုင်လဲ” လို့ မေးကြည့်ပါ။
  7. အစွန်း တစ်ဖက်စီမှာ modality ကို ဆုံးဖြတ်ပါ။ “ပါဝင်ဖို့ မဖြစ်မနေ လိုအပ်လား၊ ဒါမှမဟုတ် သုည ခု ဖြစ်နိုင်လား” လို့ မေးကြည့်ပါ။
  8. M:M relationship တွေ ရှိရင် ဖြေရှင်းပါ: FK (foreign key) နှစ်ခုနဲ့ သူ့ကိုယ်ပိုင် attribute တွေ ပါတဲ့ entity အသစ် ဖြစ်တဲ့ junction table တစ်ခု ထည့်ပါ။
  9. ပုံကို စကားလုံးနဲ့ ပြန်ဖတ်ပြီး scenario နဲ့ ကိုက်ညီလား စစ်ပါ။

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

ဥပမာ 1: Entity သုံးခုနဲ့ Junction Table တစ်ခု

ရပ်ရွာ အားကစား အသင်း Harbour Run က member တွေ၊ coach တွေ သင်ပေးတဲ့ class တွေနဲ့ သူတို့ကို ချိတ်ပေးတဲ့ booking တွေကို မှတ်တမ်း ထိန်းဖို့ database တစ်ခု လိုချင်ပါတယ်။ Scenario အရ:

  • Member တစ်ယောက်စီက class အများကြီးကို book လုပ်နိုင်ပါတယ်၊ class တစ်ခုစီကိုလည်း member အများကြီးက book လုပ်နိုင်ပါတယ်။
  • Booking တိုင်းက member တစ်ယောက်တည်းနဲ့ရော class တစ်ခုတည်းနဲ့ပါ အတိအကျ သက်ဆိုင်ပါတယ်။
  • Member တစ်ယောက်မှာ booking သုည ခု ရှိနိုင်ပါတယ် (book မလုပ်ရသေးတဲ့ member အသစ်)။
  • Class တစ်ခုမှာ booking သုည ခု ရှိနိုင်ပါတယ် (ဘယ်သူမှ book မလုပ်ရသေးတဲ့ class အသစ်)။

Crow’s-foot ERD:

erDiagram
    MEMBER ||--o{ BOOKING : "makes"
    CLASS  ||--o{ BOOKING : "is booked in"
    MEMBER {
        int MemberID PK
        string FirstName
        string Surname
        date DateOfBirth
        string MembershipTier
    }
    CLASS {
        string ClassID PK
        string Title
        string Coach
        datetime StartsAt
    }
    BOOKING {
        string BookingID PK
        int MemberID FK
        string ClassID FK
        date BookedOn
        string Status
    }

ပုံထဲက makes က “(member က booking ကို) လုပ်တယ်”၊ is booked in က “(class ကို booking ထဲမှာ) book လုပ်ထားတယ်” လို့ ဆိုလိုပါတယ်။ PK က primary key၊ FK က foreign key ဖြစ်ပြီး int (ကိန်းပြည့်)၊ string (စာသား)၊ date (ရက်စွဲ)၊ datetime (ရက်စွဲနဲ့ အချိန်) တွေက column တစ်ခုစီရဲ့ data type (ဒေတာ အမျိုးအစား) တွေပါ။

ပြန်ဖတ်ကြည့်ခြင်း:

  • Member တစ်ယောက်မှာ booking သုည ခု ဒါမှမဟုတ် အများကြီး ရှိပါတယ်၊ booking တစ်ခုစီက member တစ်ယောက်တည်းနဲ့ အတိအကျ သက်ဆိုင်ပါတယ်။ (1:M၊ M ဘက်မှာ optional၊ 1 ဘက်မှာ mandatory)
  • Class တစ်ခုမှာ booking သုည ခု ဒါမှမဟုတ် အများကြီး ရှိပါတယ်၊ booking တစ်ခုစီက class တစ်ခုတည်းအတွက် အတိအကျ ဖြစ်ပါတယ်။ (ပုံစံ အတူတူပါပဲ၊ ဘယ်ညာ ပြောင်းပြန် ဖြစ်နေတာပဲ ကွာပါတယ်)
  • 1:M relationship နှစ်ခု ပေါင်းလိုက်တော့ MEMBER နဲ့ CLASS ကြားက many-to-many relationship ကို ဖြေရှင်းပေးပါတယ်။ BOOKING junction table မှာ သူ့ကိုယ်ပိုင် attribute တွေ (BookedOn၊ Status) လည်း ရှိပါတယ်။ ဒါက table နှစ်ခုကို ချိတ်ပေးရုံ သက်သက် မဟုတ်ဘဲ booking ဆိုတဲ့ တကယ့် အရာ တစ်ခုကို မှတ်တမ်းတင်နေတယ် ဆိုတဲ့ လက္ခဏာပါ။

ဥပမာ 2: 1:1 Relationship တစ်ခု

ရပ်ရွာ ဥယျာဉ် တစ်ခုက သူ့မြေကို plot (မြေကွက်) တွေ ခွဲထားပါတယ်။ ဥယျာဉ်ရဲ့ စည်းမျဉ်းအရ plot တစ်ကွက်စီမှာ shed (ပစ္စည်း ထားတဲ့ တဲ) အများဆုံး တစ်လုံးပဲ ရှိခွင့်ရှိပြီး shed တစ်လုံးစီက plot တစ်ကွက်တည်းပေါ်မှာ အတိအကျ ရှိပါတယ်။ Plot အများကြီးမှာ shed မရှိပါဘူး။

erDiagram
    PLOT ||--o| SHED : "may have"
    PLOT {
        string PlotID PK
        int AreaSqM
        string Section
    }
    SHED {
        int ShedID PK
        string PlotID FK, UK
        string Material
        date LastInspected
    }

ပုံထဲက may have က “ရှိနိုင်တယ်” လို့ ဆိုလိုပါတယ်။ UK ကို အောက်မှာ ရှင်းပြထားပါတယ်။

ပြန်ဖတ်ကြည့်ခြင်း:

  • Plot တစ်ကွက်မှာ shed သုည ဒါမှမဟုတ် တစ်လုံး ရှိပါတယ် (shed ဘက်မှာ optional: plot အများကြီးမှာ shed မရှိပါဘူး)။
  • Shed တစ်လုံးက plot တစ်ကွက်တည်းပေါ်မှာ အတိအကျ ရှိပါတယ် (mandatory)။
  • Cardinality: 1:1။ Modality: တစ်ဖက်မှာ optional၊ နောက်တစ်ဖက်မှာ mandatory။
  • SHED ထဲမှာ PlotID က unique (တန်ဖိုး မထပ်ရ) ဖြစ်ပါတယ် (UK လို့ မှတ်ထားပါတယ်၊ unique key (တန်ဖိုး မထပ်ရတဲ့ key) ပါ)။ ဒါက relationship ကို one-to-one ဖြစ်အောင် ထိန်းထားတာပါ: ဒါ မရှိရင် plot တစ်ကွက်မှာ shed အများကြီး ရှိနိုင်ပါတယ်။

1:1 relationship တွေက ရှားပါတယ်။ အများအားဖြင့် entity နှစ်ခုကို table တစ်ခုတည်း ပေါင်းလို့ ရနိုင်တယ်ဆိုတဲ့ လက္ခဏာပါ။ ခိုင်လုံတဲ့ အကြောင်းပြချက် ရှိမှသာ သီးခြား ခွဲထားပါတယ်: security policy (လုံခြုံရေး မူဝါဒ) မတူတာ၊ access pattern (ဒေတာကို ဝင်သုံးတဲ့ ပုံစံ) မတူတာ၊ ဒါမှမဟုတ် တစ်ဖက်မှာ ပါဝင်မှုက ရှားလို့ ပေါင်းထားရင် row အများစုက null (တန်ဖိုး မရှိကြောင်း ပြတဲ့ အမှတ်အသား) ဖြစ်နေမှာမို့လို့ပါ။

ဥပမာ 3: စကားလုံးတွေကနေ Cardinality နဲ့ Modality ကို ဆုံးဖြတ်ခြင်း

စာအုပ်ဆိုင် သေးသေးလေး တစ်ဆိုင်ရဲ့ database က AUTHOR (စာရေးသူ)၊ BOOK (စာအုပ်) နဲ့ PUBLISHER (ထုတ်ဝေသူ) ကို မှတ်တမ်း ထိန်းပါတယ်။ Business rule (လုပ်ငန်းရဲ့ စည်းမျဉ်း) တွေက:

  • စာအုပ်တိုင်းကို author အနည်းဆုံး တစ်ယောက်က ရေးထားပြီး co-author (တွဲရေးသူ) အများကြီး ရှိနိုင်ပါတယ်။
  • စာအုပ်တိုင်းကို publisher တစ်ခုတည်းက အတိအကျ ထုတ်ဝေပါတယ်။
  • Author တစ်ယောက်စီက စာအုပ် အနည်းဆုံး တစ်အုပ် ရေးထားပါတယ် (မဟုတ်ရင် database ထဲမှာ ပါမှာ မဟုတ်ပါဘူး)။
  • Publisher တစ်ခုစီက စာအုပ် အနည်းဆုံး တစ်အုပ် ထုတ်ဝေထားပါတယ်။

Relationship တွေကို စနစ်တကျ တစ်ခုချင်း စစ်ကြည့်ပါ:

Relationship A အစွန်း B အစွန်း Cardinality Modality
AUTHOR writes BOOK (AUTHOR က BOOK ကို ရေးတယ်) author တစ်ယောက်က စာအုပ် အများကြီး ရေးပါတယ် စာအုပ် တစ်အုပ်ကို author အများကြီး ရေးပါတယ် M:M နှစ်ဖက်လုံး mandatory
PUBLISHER issues BOOK (PUBLISHER က BOOK ကို ထုတ်ဝေတယ်) publisher တစ်ခုက စာအုပ် အများကြီး ထုတ်ဝေပါတယ် စာအုပ် တစ်အုပ်မှာ publisher တစ်ခုပဲ ရှိပါတယ် 1:M နှစ်ဖက်လုံး mandatory

AUTHOR နဲ့ BOOK ကြားက M:M အတွက် junction table တစ်ခု လိုပါတယ်၊ အဲဒါကို AUTHORSHIP လို့ ခေါ်ပါမယ်:

erDiagram
    AUTHOR    ||--|{ AUTHORSHIP : "writes"
    BOOK      ||--|{ AUTHORSHIP : "has authors"
    PUBLISHER ||--|{ BOOK       : "issues"
    AUTHOR {
        int AuthorID PK
        string FullName
    }
    PUBLISHER {
        int PubID PK
        string PubName
    }
    BOOK {
        int BookID PK
        string Title
        int PubID FK
        int Year
    }
    AUTHORSHIP {
        int AuthorID PK, FK
        int BookID PK, FK
        int Position
    }

ပုံထဲက writes က “ရေးတယ်”၊ has authors က “author တွေ ရှိတယ်”၊ issues က “ထုတ်ဝေတယ်” လို့ ဆိုလိုပါတယ်။ PK, FK ဆိုတာ အဲဒီ column က primary key ရဲ့ အစိတ်အပိုင်းလည်း ဖြစ်၊ foreign key လည်း ဖြစ်တယ်လို့ ဆိုလိုပါတယ်။

AUTHORSHIP table မှာ Position ဆိုတဲ့ နောက်ထပ် attribute တစ်ခု ပါပါတယ်။ အဲဒါက စာအုပ် တစ်အုပ်မှာ author တစ်ယောက်စီက ပထမ၊ ဒုတိယ ဒါမှမဟုတ် တတိယ co-author ဖြစ်လားဆိုတာကို မှတ်ပါတယ်။ ဒီလို attribute အတွက် ဒီ table က သဘာဝကျတဲ့ နေရာပါ၊ ဘာလို့လဲဆိုတော့ အဲဒါက author တစ်ယောက်တည်း ဒါမှမဟုတ် စာအုပ် တစ်အုပ်တည်းအကြောင်း မဟုတ်ဘဲ author နဲ့ စာအုပ်ရဲ့ တွဲဖက်မှု အကြောင်း အချက်အလက် ဖြစ်လို့ပါ။

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

Q1. ERD ရဲ့ အဓိက အခန်းကဏ္ဍက ဘာလဲ။

Q2. Relationship တစ်ခုမှာ ပါဝင်မှုက mandatory လား optional လား ဆိုတာကို ဘယ်ဂုဏ်သတ္တိက ဖော်ပြသလဲ။

Q3. ကျောင်း တစ်ကျောင်းမှာ ကျောင်းသား တစ်ယောက်စီက class အများကြီးမှာ စာရင်းသွင်း တက်ရောက်နိုင်ပြီး class တစ်ခုစီမှာ ကျောင်းသား အများကြီး ရှိပါတယ်။ STUDENT နဲ့ CLASS ကြားက relationship ရဲ့ cardinality က ဘာလဲ။

Q4. ကျောင်း တစ်ကျောင်းမှာ ကျောင်းသားတွေနဲ့ club (အသင်း) တွေ ရှိပြီး သူတို့ကြားမှာ many-to-many relationship ရှိပါတယ်။ ဒီ relationship ကို relational schema (database ဖွဲ့စည်းပုံ ဖော်ပြချက်) မှာ ဖော်ပြတဲ့ စံနည်းလမ်းက ဘာလဲ။

Q5. Crow's-foot notation PLOT ||---o| SHED က ဘယ်လို relationship မျိုးကို ဖော်ပြသလဲ။

Q6. ပြည့်စုံတဲ့ ERD တစ်ခုက relationship တိုင်းအတွက် ဘယ်ဂုဏ်သတ္တိတွေကို ပြသင့်သလဲ။

Relationship အမျိုးအစားကို ဆုံးဖြတ်ပါ

Online သင်ကြားရေး platform သေးသေးလေး တစ်ခုက STUDENT၊ COURSE နဲ့ ENROLMENT (စာရင်းသွင်းမှု) ကို သိမ်းထားပါတယ်။ Business rule တစ်ခုစီကို ဖတ်ပြီး cardinality ကို ဆုံးဖြတ်ပါ။

Scenario တစ်ခုစီအတွက် cardinality (1:1၊ 1:M ဒါမှမဟုတ် M:M) ကို ရိုက်ထည့်ပါ။ M ကို English စာလုံးနဲ့ ရိုက်ပါ။

အခြေအနေCardinality
ကျောင်းသား တစ်ယောက်က course အများကြီး တက်နိုင်ပါတယ်၊ course တစ်ခုစီမှာ စာရင်းသွင်းထားတဲ့ ကျောင်းသား အများကြီး ရှိပါတယ်။
Enrolment record တစ်ခုစီက ကျောင်းသား တစ်ယောက်တည်းနဲ့ အတိအကျ သက်ဆိုင်ပါတယ်၊ ကျောင်းသား တစ်ယောက်မှာ enrolment record အများကြီး ရှိနိုင်ပါတယ်။
Enrolment record တစ်ခုစီက course တစ်ခုတည်းအတွက် အတိအကျ ဖြစ်ပါတယ်၊ course တစ်ခုမှာ enrolment record အများကြီး ရှိနိုင်ပါတယ်။
ကျောင်းသား တစ်ယောက်စီကို student ID card တစ်ကတ်တည်း အတိအကျ ထုတ်ပေးပါတယ်၊ ID card တစ်ကတ်စီက ကျောင်းသား တစ်ယောက်တည်းနဲ့ အတိအကျ သက်ဆိုင်ပါတယ်။
Course တစ်ခုစီကို instructor (သင်ကြားသူ) တစ်ယောက်က သင်ပါတယ်၊ instructor တစ်ယောက်က course အများအပြား သင်နိုင်ပါတယ်။

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

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

ERD VOCABULARY
==============
A real-world thing that the database needs to track is called an
, in the implemented database it normally becomes a table.

A property of an entity (a column on the resulting table) is called an
.

The maximum number of instances on each side of a relationship
is called the , one or many.

Whether participation is required (mandatory) or not (optional)
is called the .

A many-to-many relationship is resolved in the schema using a
 that holds a foreign key to each of the two
main entities.

စာကြောင်းတွေရဲ့ အဓိပ္ပာယ် (____ က ကွက်လပ်ပါ):
Database က မှတ်တမ်း ထိန်းထားဖို့ လိုတဲ့ လက်တွေ့ ကမ္ဘာက အရာ တစ်ခုကို ____ လို့ ခေါ်ပါတယ်၊ တည်ဆောက်ပြီးသား database မှာ အဲဒါက များသောအားဖြင့် table တစ်ခု ဖြစ်လာပါတယ်။
Entity တစ်ခုရဲ့ ဂုဏ်သတ္တိ (ရလာတဲ့ table ပေါ်က column တစ်ခု) ကို ____ လို့ ခေါ်ပါတယ်။
Relationship တစ်ခုရဲ့ ဘက်တစ်ဖက်စီမှာ ရှိနိုင်တဲ့ instance အရေအတွက်ရဲ့ အများဆုံးကို ____ လို့ ခေါ်ပါတယ်၊ one ဒါမှမဟုတ် many ပါ။
ပါဝင်မှုက မဖြစ်မနေ လိုအပ်လား (mandatory) မလိုအပ်ဘူးလား (optional) ဆိုတာကို ____ လို့ ခေါ်ပါတယ်။
Many-to-many relationship ကို schema မှာ ____ တစ်ခုနဲ့ ဖြေရှင်းပါတယ်၊ အဲဒီ table မှာ အဓိက entity နှစ်ခုစီကို ညွှန်းတဲ့ foreign key တစ်ခုစီ ပါပါတယ်။

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

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

1Cardinality describes the maximum number of instances on each side of a relationship 2Modality describes whether participation is mandatory or optional 3A many-to-many relationship can be stored directly in a relational database without a junction table 4A 1:1 relationship is rare, often the two entities could be merged into one table 5An ERD is a design tool, used before the database is built

Line တွေရဲ့ အဓိပ္ပာယ်: (1) cardinality က relationship တစ်ခုရဲ့ ဘက်တစ်ဖက်စီမှာ ရှိနိုင်တဲ့ instance အရေအတွက်ရဲ့ အများဆုံးကို ဖော်ပြတယ်၊ (2) modality က ပါဝင်မှုဟာ mandatory လား optional လား ဆိုတာကို ဖော်ပြတယ်၊ (3) many-to-many relationship ကို junction table မပါဘဲ relational database ထဲမှာ တိုက်ရိုက် သိမ်းလို့ ရတယ်၊ (4) 1:1 relationship က ရှားတယ်၊ အများအားဖြင့် entity နှစ်ခုကို table တစ်ခုတည်း ပေါင်းလို့ ရနိုင်တယ်၊ (5) ERD က database ကို မတည်ဆောက်ခင် သုံးတဲ့ design tool တစ်ခုပါ။

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

Cardinality ကို ရှာဖော်ပါ

"ရိုးရှင်းအောင် လုပ်ထားတဲ့ စာပေ database တစ်ခုမှာ စာအုပ် တစ်အုပ်စီကို author တစ်ယောက်တည်းက အတိအကျ ရေးထားပါတယ်။ Author တစ်ယောက်စီက စာအုပ် အများကြီး ရေးထားနိုင်ပါတယ်။"

AUTHOR နဲ့ BOOK ကြားက relationship ရဲ့ cardinality ကို ရိုက်ထည့်ပါ (1:1၊ 1:M ဒါမှမဟုတ် M:M ပုံစံကို သုံးပါ)။

"အိမ် တစ်လုံးစီမှာ ရေမီတာ အများဆုံး တစ်လုံး ရှိပြီး ရေမီတာ တစ်လုံးစီကို အိမ် တစ်လုံးတည်းမှာ အတိအကျ တပ်ဆင်ထားပါတယ်။"

HOUSE နဲ့ WATER_METER ကြားက relationship ရဲ့ cardinality ကို ရိုက်ထည့်ပါ (1:1၊ 1:M ဒါမှမဟုတ် M:M ပုံစံကို သုံးပါ)။

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

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

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

  1. [Core] ERDs [4 marks] Database တစ်ခုကို ဒီဇိုင်း ဆွဲပြီး တည်ဆောက်ရာမှာ entity-relationship diagram ရဲ့ ရည်ရွယ်ချက်ကို Explain (ရှင်းပြပါ)။ Diagram ကို ဘာအတွက် သုံးလဲ (ဥပမာ အစီအစဉ် ဆွဲခြင်း၊ abstraction၊ stakeholder တွေနဲ့ ဆက်သွယ် ပြောဆိုခြင်း၊ နောင်မှာ ဆက်ချဲ့ခြင်း) ဆိုတာကို ရေးပါ၊ သူသုံးတဲ့ သင်္ကေတတွေ အကြောင်း မရေးပါနဲ့။

  2. [Core] ERDs [2 marks] ဆေးခန်း တစ်ခုမှာ PATIENT (လူနာ) နဲ့ APPOINTMENT (ချိန်းဆိုမှု) table တွေ ရှိပါတယ်။ လူနာ တစ်ယောက်ရဲ့ ပထမဆုံး appointment ကို ချိန်းတဲ့အခါ အဲဒီ လူနာကို PATIENT ထဲ ထည့်ပါတယ်၊ ပြီးတော့ လူနာ တစ်ယောက်မှာ appointment အများကြီး ရှိနိုင်ပါတယ်၊ appointment တစ်ခုစီက လူနာ တစ်ယောက်တည်းအတွက် အတိအကျ ဖြစ်ပါတယ်။ PATIENT နဲ့ APPOINTMENT ကြားက relationship ရဲ့ cardinality နဲ့ modality ကို State (ဖော်ပြပါ)။

  3. [Core] ERDs [3 marks] စာအုပ်ဆိုင် တစ်ဆိုင်က customer (ဝယ်သူ) တွေကို စာအုပ် ရောင်းပါတယ်။ Customer တစ်ယောက်စီက order (မှာယူမှု) အများကြီး မှာနိုင်ပါတယ်၊ order တစ်ခုစီကို customer တစ်ယောက်တည်းက အတိအကျ မှာပါတယ်။ Cardinality နဲ့ modality ပါဝင်အောင် CUSTOMER နဲ့ ORDER ကြားက relationship ကို ပြတဲ့ ERD တစ်ခုကို Construct လုပ်ပါ။

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

  1. [Extension] ERDs [4 marks] ရပ်ရွာ အားကစား အသင်း တစ်ခုက member တွေ၊ class တွေနဲ့ booking တွေကို မှတ်တမ်း ထိန်းပါတယ်။ Member တစ်ယောက်စီက class အများကြီး book လုပ်နိုင်ပါတယ်၊ class တစ်ခုစီကိုလည်း member အများကြီးက book လုပ်နိုင်ပါတယ်၊ booking တစ်ခုစီက member တစ်ယောက်နဲ့ class တစ်ခုအတွက် အတိအကျ ဖြစ်ပါတယ်။ Many-to-many relationship ကို junction table သုံးပြီး ဖြေရှင်းထားတဲ့ ERD တစ်ခုကို Construct လုပ်ပါ။ အစွန်း တိုင်းမှာ cardinality နဲ့ modality ကို ထည့်ပါ။

  2. [Extension] ERDs [5 marks] ရပ်ရွာ makerspace (ကိရိယာတွေ မျှသုံးပြီး ပစ္စည်း ဖန်တီးတဲ့ အလုပ်ရုံ) တစ်ခုက သူ့ member တွေကို laser cutter နဲ့ 3D printer လို machine (စက်) တွေကို သုံးခွင့် ပေးပါတယ်၊ ဒါပေမယ့် စက် တစ်လုံးစီအတွက် induction (စက်ကို ဘယ်လို သုံးရမလဲ သင်ပေးတဲ့ လေ့ကျင့်ပေးမှု အတို) ပြီးမှသာ သုံးခွင့် ရပါတယ်။ Member တစ်ယောက်က စက် အများကြီးအတွက် induction ရနိုင်ပြီး စက် တစ်လုံးစီမှာလည်း induction ရပြီးသား member အများကြီး ရှိနိုင်ပါတယ်၊ ဝင်ခါစ member၊ ရောက်ခါစ စက်နဲ့ အလုပ် စဝင်ခါစ technician (စက်တွေကို ကျွမ်းကျင်တဲ့ ဝန်ထမ်း) တွေမှာ induction တစ်ခုမှ မရှိသေးတာ ဖြစ်နိုင်ပါတယ်။ Makerspace က induction တစ်ခုစီရဲ့ ရက်စွဲနဲ့ ဘယ် technician က ပေးခဲ့လဲ ဆိုတာကို မှတ်တမ်း တင်ပါတယ်၊ technician တစ်ယောက်က induction အများကြီး ပေးနိုင်ပါတယ်။ Many-to-many relationship ရှိရင် ဖြေရှင်းပြီး ERD ကို Construct လုပ်ပါ၊ အစွန်း တစ်ဖက်စီမှာ cardinality နဲ့ modality ကို ထည့်ပါ။

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

  1. [Challenge] ERDs [6 marks] Online အစားအသောက် မှာယူတဲ့ platform တစ်ခုက customer တွေ၊ restaurant (စားသောက်ဆိုင်) တွေ၊ menu item (menu ထဲက ဟင်းပွဲ) တွေနဲ့ order တွေကို ချိတ်ဆက်ပေးပါတယ်။ Customer တစ်ယောက်က order အများကြီး မှာနိုင်ပါတယ်၊ order တစ်ခုစီက restaurant တစ်ဆိုင်တည်းက အတိအကျ ဖြစ်ပါတယ်၊ order တစ်ခုစီမှာ menu item တစ်ခု ဒါမှမဟုတ် တစ်ခုထက် ပိုပါပါတယ်၊ menu item တစ်ခုစီက restaurant တစ်ဆိုင်တည်းနဲ့ အတိအကျ သက်ဆိုင်ပါတယ်၊ menu item တစ်ခုတည်းက order အများကြီးမှာ ပါနိုင်ပါတယ်။ Entity လေးခုလုံး (လိုအပ်တဲ့ junction table တွေ အပါအဝင်) ပါပြီး cardinality နဲ့ modality ကို ပြထားတဲ့ ပြည့်စုံတဲ့ ERD တစ်ခုကို Construct လုပ်ပါ။

  2. [Challenge] ERDs [6 marks] Software-development team တစ်ခု သုံးတဲ့ database ကို မှတ်တမ်းတင် ဖော်ပြဖို့အတွက် crow’s-foot notation ကို Chen notation နဲ့ နှိုင်းယှဉ်ပြီး အားသာချက်နဲ့ အားနည်းချက်တွေကို Discuss (အမြင် အမျိုးမျိုးကို ချိန်ဆပြီး ဆွေးနွေးပါ)။ ဖတ်ရလွယ်မှု၊ cardinality နဲ့ modality ကို ဖော်ပြနိုင်စွမ်း၊ နောက်ပိုင်း ပြောင်းလဲမှုတွေကို diagram က ဘယ်လောက် လွယ်လွယ်ကူကူ လက်ခံနိုင်လဲ ဆိုတာတွေကို ထည့်ပြောပါ။

Exam-Style (စာမေးပွဲ ပုံစံ မေးခွန်း)

  1. [Exam-Style] ERDs [5 marks] ရုပ်ရှင်ပွဲတော် တစ်ခုရဲ့ database က venue (ပြသမယ့် နေရာ) တွေ၊ film (ရုပ်ရှင်) တွေနဲ့ ရုပ်ရှင် တစ်ကားစီရဲ့ screening (ပြသမှု) တွေကို အောက်ပါ ERD အတိုင်း မှတ်တမ်း တင်ပါတယ်:

    erDiagram
    VENUE ||--o{ SCREENING : "hosts"
    FILM  ||--o{ SCREENING : "is shown at"
    VENUE {
        int VenueID PK
        string VenueName
        int Seats
    }
    FILM {
        int FilmID PK
        string Title
        int RunningMins
    }
    SCREENING {
        int ScreeningID PK
        int VenueID FK
        int FilmID FK
        datetime StartsAt
    }

    ပုံထဲက hosts က “(venue က screening ကို) လက်ခံ ပြသတယ်”၊ is shown at က “(film ကို screening မှာ) ပြတယ်” လို့ ဆိုလိုပါတယ်။

    • (a) ERD မှာ ပြထားတဲ့ FILM နဲ့ SCREENING ကြားက relationship ကို cardinality နဲ့ modality ပါဝင်အောင် Describe (ဖော်ပြရှင်းပြပါ)။ [2]
    • (b) ပွဲတော်က screening တချို့ကို မိတ်ဆက်ပေးဖို့ guest speaker (ဖိတ်ကြားထားတဲ့ ဟောပြောသူ) တွေကို ဖိတ်ပါတယ်။ Speaker တစ်ယောက်စီက screening အနည်းဆုံး တစ်ခုကို မိတ်ဆက်ပေးပြီး အများကြီးလည်း မိတ်ဆက်ပေးနိုင်ပါတယ်၊ screening တစ်ခုမှာ speaker အများဆုံး တစ်ယောက်ပဲ ရှိပြီး screening အများကြီးမှာ speaker မရှိပါဘူး။ SPEAKER entity ကို ထည့်တဲ့ ERD အပိုင်းကို အစွန်း နှစ်ဖက်လုံးမှာ cardinality နဲ့ modality ပါဝင်အောင် Construct လုပ်ပါ။ [2]
    • (c) Speaker မရှိတဲ့ screening ကို SCREENING ထဲက row တစ်ခုက ဘယ်လို မှတ်တမ်းတင်လဲ ဆိုတာကို Outline (အကျဉ်းချုပ် ဖော်ပြပါ)။ [1]

IB CS (IB Computer Science သင်ရိုး) လေ့လာသူတွေအတွက် မှတ်ချက်: ERD တစ်ခုကို construct လုပ်တဲ့အခါ (A3.2.2) relationship တိုင်းရဲ့ အစွန်း နှစ်ဖက်လုံးမှာ cardinality နဲ့ modality ကို ပေးပြီး many-to-many relationship တစ်ခုစီကို junction table နဲ့ ဖြေရှင်းပါ။ Relationship တိုင်းအတွက် cardinality ရော modality ပါ ဖော်ပြတာကို လေ့ကျင့်ပါ။

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

  • အရင် လေ့လာထားရမယ့် ခေါင်းစဉ်: Database Schemas (database ဖွဲ့စည်းပုံ ဖော်ပြချက်များ): ERD တွေက conceptual schema နဲ့ logical schema တွေအတွက် စံအဖြစ် သုံးတဲ့ ပုံတွေပါ။
  • ဆက်စပ် ခေါင်းစဉ်: Relational Database Fundamentals (relational database ရဲ့ အခြေခံများ): ERD တွေက ပုံနဲ့ ပြတဲ့ relational ဝေါဟာရ (entity၊ attribute၊ relationship အမျိုးအစား) တွေပါ။
  • နောက်ထပ် လေ့လာမယ့် ခေါင်းစဉ်: Data Types and Keys (ဒေတာ အမျိုးအစားများနဲ့ key များ): ERD တစ်ခုကို ပြည့်စုံတဲ့ logical schema အဖြစ် ဖြည့်စွက်ပေးတဲ့ column type တွေနဲ့ key ရွေးချယ်မှုတွေပါ။
  • ဆက်စပ် ခေါင်းစဉ်: Normalisation (ဒေတာ ထပ်မနေအောင် table တွေကို စီစဉ်ခြင်း): ERD တစ်ခုကို ဒေတာ ထပ်နေမှု နည်းတဲ့ 3NF (normalisation ရဲ့ တတိယ အဆင့်) ဒီဇိုင်း ဖြစ်အောင် ပြင်ဆင်ပေးတဲ့ လုပ်ငန်းစဉ်ပါ။
  • နောက်ပိုင်းမှာ: SQL Queries (SQL query များ): SQL query တွေထဲက JOIN clause (table တွေကို ချိတ်ပြီး ဒေတာ တွဲယူတဲ့ အပိုင်း) တွေက ERD ပေါ်က relationship line တွေအတိုင်း လိုက်သွားပါတယ်။

© EduCS.me. ကွန်ပျူတာသိပ္ပံ ပညာရေးအတွက် အရင်းအမြစ်တွေ စုထားတဲ့ နေရာပါ။ EduCS is an independent educational resource. It is not affiliated with, or endorsed by, the International Baccalaureate Organization. (EduCS ဟာ သီးခြား ပညာရေး အရင်းအမြစ်တစ်ခုပါ။ International Baccalaureate Organization နဲ့ ဆက်စပ်မှု မရှိသလို သူတို့ရဲ့ ထောက်ခံချက်လည်း မရှိပါဘူး။) ဆက်သွယ်ရန်

Just the Docs နဲ့ တည်ဆောက်ထားပါတယ်။