Ang isang relasyon ay isang lohikal na relasyon sa pagitan ng mga entity. Ang bawat relasyon ay dapat tawaging pandiwa o pariralang pandiwa. Ang pangalan ng relasyon ay nagpapahayag ng ilang hadlang o panuntunan sa negosyo at ginagawang mas madaling basahin ang diagram. Bilang default, ang pangalan ng koneksyon ay hindi ipinapakita sa diagram. Sa lohikal na antas, maaari kang magtatag ng isa-sa-maraming pagkakakilanlan na relasyon, marami-sa-maraming relasyon, at isa-sa-maraming hindi nagpapakilalang relasyon. Ang isang relasyon ay isang lohikal na antas ng konsepto kung saan ang isang dayuhang susi ay tumutugma sa pisikal na antas. Sa ERwin, ang mga relasyon ay kinakatawan ng limang pangunahing piraso ng impormasyon:

● uri ng koneksyon (pagkilala, hindi pagtukoy, kumpleto/hindi kumpletong kategorya, hindi partikular na koneksyon);

● parent entity;

● child (dependent) entity;

● kapangyarihan ng komunikasyon (cardinality);

● pagiging katanggap-tanggap ng mga walang laman (null) na halaga.

Tinutukoy ng IDEFIX ang pagitan ng mga umaasa at independiyenteng entity. Ang uri ng isang entity ay natutukoy sa pamamagitan ng kaugnayan nito sa iba pang mga entity. Ang isang pagkakakilanlan na relasyon ay itinatag sa pagitan ng isang independiyenteng (magulang) at umaasa (anak) na entity. Ang umaasang entity ay kinakatawan ng isang parihaba na may mga bilugan na sulok. Kapag naitatag ang isang pagkakakilanlan na relasyon, ang mga katangian ng pangunahing susi ng parent entity ay awtomatikong ililipat sa pangunahing key ng child entity. Ang operasyong ito ng pagdaragdag ng mga attribute sa isang child entity kapag gumagawa ng isang relasyon ay tinatawag na attribute migration. Sa child entity, ang mga bagong attribute ay minarkahan bilang foreign key - FK.

Kapag naitatag ang isang hindi nagpapakilalang relasyon, nananatiling independyente ang child entity, at ang mga pangunahing pangunahing katangian ng parent na entity ay kasama sa mga hindi pangunahing katangian ng child entity. Ang isang hindi nagpapakilalang relasyon ay ginagamit upang i-link ang mga independiyenteng entity. Upang tukuyin ang mga relasyon sa ERwin, pipiliin mo ang uri ng relasyon, pagkatapos ay gamitin ang mouse upang piliin ang mga entity ng magulang at anak. Ang link na nagpapakilala ay inilalarawan bilang isang solidong linya; hindi nagpapakilala - may tuldok na linya. Ang mga linya ay nagtatapos sa isang tuldok sa gilid ng child entity.

Cardinality - nagsisilbing ipahiwatig ang ratio ng bilang ng mga instance ng parent entity sa bilang ng mga instance ng bata.

Mayroong apat na uri ng mga entity:

· ang pangkalahatang kaso kapag ang isang instance ng parent entity ay tumutugma sa 0, 1 o maraming instance ng child entity; hindi minarkahan ng anumang simbolo;

· ang simbolong P ay minarkahan ang kaso kapag ang isang instance ng parent entity ay tumutugma sa 1 o maraming instance ng child entity (zero value ay hindi kasama);

· minarkahan ng simbolong Z ang kaso kapag ang isang instance ng parent entity ay tumutugma sa 0 o 1 instance ng child entity (maraming value ang hindi kasama);

· isang numero ang nagmamarka ng kaso ng isang eksaktong tugma, kapag ang isang instance ng parent entity ay tumutugma sa isang paunang natukoy na bilang ng mga instance ng child entity.

· ang pagtanggap ng mga walang laman (NULL) na halaga sa mga hindi nagpapakilalang relasyon ay inilalarawan ni ERwin bilang isang walang laman na brilyante sa arko ng relasyon mula sa gilid ng parent na entity.

Ang pangalan ng koneksyon sa lohikal na antas ay isang pandiwa na nag-uugnay sa mga entity. Ang pangalan ng pisikal na link (na maaaring iba sa pangalan ng lohikal na link) para sa ERwin ay nangangahulugang ang hadlang o pangalan ng index. Upang ipakita ang pangalan ng relasyon, pumili ng opsyon mula sa menu: Format/Pagpapakita ng Relasyon/ Parirala ng Pandiwa.

Tinutukoy ng ilang entity ang isang buong kategorya ng mga bagay na may parehong uri. Sa ERwin, sa kasong ito, nilikha ang isang entity upang tukuyin ang kategorya at para sa bawat elemento ng kategorya, at pagkatapos ay ipinakilala ang isang relasyon sa pagkakategorya para sa kanila. Ang parent entity ng isang kategorya ay tinatawag na supertype, at ang mga anak nito ay tinatawag na subtype.

Halimbawa, ang entity na "papasok na dokumento" ay maaaring parehong isang kahilingan at isang order. Ang una at pangalawa ay may magkaiba, bahagyang magkakapatong na hanay ng mga katangian (ang pinakamababang intersection ng mga subtype ay ang pangunahing key). Ang karaniwang bahagi ng mga katangiang ito, kabilang ang pangunahing susi, ay inilalagay sa supertype na entity ng "papasok na dokumento". Ang iba't ibang bahagi (halimbawa, data tungkol sa nilalaman, nagpadala) ay inilalagay sa mga subtype na entity.

Sa isang supertype na entity, ipinakilala ang isang katangian ng discriminator na nagbibigay-daan sa iyong makilala sa pagitan ng mga partikular na pagkakataon ng isang entity - isang subtype.

Depende sa kung ang lahat ng posibleng subtype na entity ay kasama sa modelo, ang kategoryang relasyon ay kumpleto o hindi kumpleto.

Figure 1.4 - Halimbawa ng isang hindi kumpletong hanay ng mga kategorya

Figure 1.5 - Halimbawa ng kumpletong hanay ng mga kategorya

3. Ang isang entity ay maaaring maging isang pangkalahatang entity sa anumang bilang ng mga relasyon sa pagkakategorya.

4. Ang mga katangian ng pangunahing susi ng entity ng kategorya ay dapat tumugma sa mga katangian ng pangunahing susi ng pangkalahatang entity.

5. Ang lahat ng mga instance ng isang entity ng kategorya ay may parehong halaga ng discriminator, at ang lahat ng mga instance ng iba pang mga kategorya ay dapat na may iba't ibang mga halaga ng discriminator (tingnan ang Fig. 4 at Fig. 5).

Mga tungkulin.

Ang pangalan ng tungkulin (functional na pangalan) ay isang kasingkahulugan para sa isang foreign key attribute na nagsasaad kung anong papel ang ginagampanan ng attribute sa isang child entity. Bilang default, tanging ang pangalan ng tungkulin ang ipinapakita sa listahan ng katangian. Upang ipakita ang buong pangalan ng isang katangian (kapwa ang functional na pangalan at ang pangalan ng tungkulin), piliin ang Format/Entity Display mula sa menu ng konteksto at pagkatapos ay paganahin ang opsyon na Rolename/Attribute. Ang buong pangalan ay ipinapakita bilang ang functional na pangalan at ang batayang pangalan, na pinaghihiwalay ng isang tuldok. Tinukoy ang pangalan ng tungkulin sa tab na Rolename ng dialog box ng Relasyon. Tinatawag ang window na ito sa pamamagitan ng pag-double click sa linya ng koneksyon.

Kinakailangang gumamit ng mga pangalan ng tungkulin kapag ang dalawa o higit pang mga katangian ng parehong entity ay tinukoy sa parehong saklaw, i.e. mayroon silang parehong hanay ng mga kahulugan, ngunit magkaibang kahulugan.

Mga pagtatanghal.

Ang mga view, o, kung minsan ay tinatawag ang mga ito, pansamantala o nagmula na mga talahanayan, ay mga object ng database kung saan ang data ay hindi permanenteng nakaimbak, tulad ng sa isang talahanayan, ngunit dynamic na nabuo kapag ang view ay na-access. Ang isang view ay hindi maaaring umiiral sa sarili nitong, ngunit tinukoy lamang sa mga tuntunin ng isa o higit pang mga talahanayan. Ang paggamit ng mga view ay nagbibigay-daan sa taga-disenyo ng database na magbigay sa bawat user o grupo ng mga user ng ibang view ng data, na lumulutas sa mga problema sa kadalian ng paggamit at seguridad ng data.

Paglalarawan ng interface ng ERwin. Ang CASE interface ng ERwin ay binubuo ng tatlong pangunahing bahagi. Ang una ay ang pangunahing menu at mga toolbar.

Ang mga pindutan sa mga toolbar ay sumasalamin sa ilan sa mga pangunahing utos sa pangunahing menu. I-save, buksan, lumikha ng bagong file, isang panel na may mga pindutan upang taasan o bawasan ang sukat ng display ng modelo, isang switch sa pagitan ng pisikal at lohikal na modelo, isang switch sa pagitan ng mga naka-imbak na display, isang panel para sa pag-edit ng estilo, laki at kulay ng mga font, isang panel na may mga tool para sa pagbuo ng mga geometric na hugis at ilang mga auxiliary toolbar (Larawan 5.3).

kanin. 5.3.

Ang pangalawa ay Model Explorer. Naglalaman ito ng tatlong tab: Modelo, Mga Lugar ng Paksa at Mga Domain. Ang pinakakaraniwang ginagamit na tab sa Model Explorer ay ang tab na Mga Domain o Modelo (na naglalaman ng lahat ng mga bagay at modelo). Sa Mga Domain ang mga domain ay ipinapakita, at sa Mga Lugar ng Paksa - ang mga ipinapakitang lugar (Larawan 5.4).

kanin. 5.4.

At ang pangatlo ay ang lugar na direktang inilaan para sa paglikha ng isang object model, kung saan ang lahat ng mga object ng modelo ay nilikha at na-edit. Ang mga bookmark ay lilitaw sa ibaba na may mga pangalan ng mga naka-imbak na naka-imbak na mga display (Mga Naka-imbak na Display) (Larawan 5.5).

kanin. 5.5.

Ang ERwin ay may dalawang antas ng representasyon ng data ng modelo: lohikal at pisikal. Antas ng lohika- ito ay isang abstract na view ng data, kung saan ang data ay ipinakita sa hitsura nito sa totoong mundo, halimbawa, "Customer", "Workshop" o "Pangalan ng empleyado". Ang mga modelong bagay na kinakatawan sa lohikal na antas ay tinatawag na mga entity at katangian. Ang isang modelo ng lohikal na data ay maaaring itayo sa ibabaw ng isa pang lohikal na modelo, tulad ng isang modelo ng proseso. Ang modelo ng lohikal na data ay pangkalahatan at hindi nauugnay sa isang partikular na pagpapatupad ng DBMS.

Pisikal na modelo ang data, sa kabaligtaran, ay nakasalalay sa partikular na DBMS, sa katunayan ay isang salamin ng katalogo ng system. Ang pisikal na modelo ay naglalaman ng impormasyon tungkol sa lahat ng mga object ng database. Dahil walang mga pamantayan para sa mga object ng database (halimbawa, walang pamantayan para sa mga uri ng data), ang pisikal na modelo ay nakasalalay sa partikular na pagpapatupad ng DBMS. Dahil dito, maraming magkakaibang pisikal na modelo ang maaaring tumugma sa parehong lohikal na modelo. Kung sa isang lohikal na modelo ay hindi mahalaga kung anong partikular na uri ng data ang mayroon ang isang katangian, kung gayon sa isang pisikal na modelo mahalaga na ilarawan ang lahat ng impormasyon tungkol sa mga partikular na pisikal na bagay - mga talahanayan, haligi, index, pamamaraan, atbp. Paghahati ng modelo sa lohikal at pisikal na nagbibigay-daan sa iyo upang malutas ang maraming mahahalagang gawain.

Ang ERwin ay may ilang antas ng pagpapakita ng diagram: antas ng entity, antas ng katangian, antas ng kahulugan, antas ng pangunahing key at antas ng icon. Maaari kang lumipat sa pagitan ng unang tatlong antas gamit ang mga pindutan sa toolbar. Maaari kang lumipat sa iba pang mga antas ng display gamit ang menu ng konteksto na lilitaw kung "mag-click" ka sa anumang lugar sa diagram na hindi inookupahan ng mga modelong bagay. Sa menu ng konteksto, piliin ang Display Level at pagkatapos ay ang gustong antas ng display. Binibigyang-daan ka ng ERwin na iugnay ang malaki at maliit na mga icon sa isang entity. Kapag lumilipat sa antas ng icon, isang malaking icon ang ipinapakita. Upang magpakita ng maliit na icon, piliin ang Entity Display/Entity Icon sa menu ng konteksto. Isang maliit na icon ang ipapakita sa kaliwa ng pangalan ng entity sa lahat ng antas ng display ng modelo.

Itakda ang kulay at font. Mayroong ilang mga paraan upang itakda ang font at kulay ng mga bagay sa ERwin. Una, upang itakda ang kulay at font ng isang bagay, gamitin ang Font at Color Toolbar, na matatagpuan sa ilalim ng pangunahing panel. Upang i-edit ang font at kulay ng isang partikular na bagay, mag-right click sa isang entity o relasyon at piliin ang Font ng Bagay at Kulay... mula sa pop-up na menu upang buksan ang dialog ng Font/Color Editor, kung saan ang pangalan, paglalarawan at tinukoy ang mga komento ng entity. Sa dialog ng Font/Color Editor, maaari kang pumili ng font at itakda ang laki, istilo at kulay nito, itakda ang kulay ng fill (Fill Color property, para lang sa mga entity) at kulay ng linya (Outline Color property, para lang sa mga entity).

Kapag gumagawa ng mga totoong modelo ng data, ang bilang ng mga entity at attribute ay maaaring nasa daan-daan. Para sa mas maginhawang trabaho sa malalaking modelo, nagbibigay ang ERwin mga subset ng modelo (Mga Lugar ng Paksa), kung saan maaaring isama ang mga karaniwang entity ayon sa paksa. Ang isang subset ng modelo ay maaaring magsama ng isang arbitrary na hanay ng mga entity, relasyon, at komento sa text. Upang lumikha, magtanggal o mag-edit ng mga subset ng modelo, kailangan mong tawagan ang dialog ng Mga Lugar ng Paksa (Mga Lugar ng Modelo/Subject... menu), kung saan ipinapahiwatig mo ang pangalan ng subset at ang mga entity na kasama dito. Ang lahat ng mga pagbabagong ginawa sa anumang Subject Area ay awtomatikong makikita sa pangkalahatang modelo. Ang parehong entity ay maaaring isama sa ilang Subject Areas.

Naka-imbak na Display- isang representasyon ng isang subset ng modelo, na nagpapakita ng isang partikular na aspeto ng istraktura ng data. Ang isang Lugar ng Paksa ay maaaring magsama ng maraming nakaimbak na pagmamapa. Kasama sa naka-imbak na display ang parehong mga entity at relasyon gaya ng Subject Area, ngunit maaaring magkaiba ang posisyon ng mga ito sa screen, sa iba't ibang antas, sa iba't ibang scale, at sa iba't ibang kulay ng object o background.

Upang lumikha ng nakaimbak na display, gamitin ang dialog ng Stored Displays (Format ng menu/Mga Setting ng Stored Display...). Upang lumipat sa pagitan ng mga naka-imbak na view, gamitin ang mga tab sa ibaba ng diagram.

Ang mga pangunahing bahagi ng isang ERwin diagram ay mga entity, attribute, at relasyon. Ang bawat entity ay isang set ng magkakatulad na indibidwal na mga bagay na tinatawag na mga pagkakataon. Ang bawat kopya ay indibidwal at dapat ay naiiba sa lahat ng iba pang mga kopya. Ang isang katangian ay nagpapahayag ng isang tiyak na katangian ng isang bagay. Mula sa punto ng view ng database (pisikal na modelo), ang isang entity ay tumutugma sa isang talahanayan, isang halimbawa ng isang entity ay tumutugma sa isang hilera sa talahanayan, at isang katangian ay tumutugma sa isang haligi ng talahanayan.

Paglikha ng lohikal na modelo ng data para sa paksang "Custom-made furniture". Ang nilikha na lohikal na modelo ay inuulit ang istraktura ng dinisenyo na IC. Upang lumikha ng isang entity sa lugar para sa paglikha ng mga modelo ng object, kailangan mong (pagkatapos matiyak na ikaw ay nasa antas ng lohikal na modelo: ang paglipat sa pagitan ng lohikal at pisikal na modelo ay ang drop-down na listahan sa kanang bahagi ng toolbar ) “click” sa entity button sa toolbar ( ERwin Toolbox) Q , pagkatapos ay “click” sa lugar sa diagram kung saan mo gustong ilagay ang bagong entity. Sa pamamagitan ng pag-right-click sa isang entity at pagpili sa Entity Properties... mula sa pop-up menu, maaari mong buksan ang Entity dialog, na tumutukoy sa pangalan, paglalarawan, at komento ng entity (halimbawa, pangalan ng entity - supplier, paglalarawan - data ng supplier). Tinutukoy ang bawat entity gamit ang isang paglalarawan ng teksto sa tab na Kahulugan. Ang Note, Note 2, Note 3, UDP (User Defined Properties) na mga bookmark ay ginagamit upang magdagdag ng mga karagdagang komento sa entity. Ang susunod na hakbang ay ang paglikha ng mga katangian ng entity. Gaya ng nakasaad sa itaas, ang bawat katangian ay nag-iimbak ng impormasyon tungkol sa isang partikular na ari-arian ng isang entity, at ang bawat instance ng isang entity ay dapat na natatangi. Ang isang katangian o pangkat ng mga katangian na nagpapakilala sa isang entity ay tinatawag na pangunahing susi. Upang lumikha ng mga katangian, mag-right-click sa entity at piliin ang Mga Katangian... mula sa menu na lilitaw Ang dialog ng Mga Katangian. Kung nag-click ka sa Bagong... na buton, pagkatapos ay sa dialog na Bagong Katangian na lalabas, tukuyin ang pangalan ng katangian, ang pangalan ng column na naaayon dito sa pisikal na modelo, at ang domain (halimbawa, ang pangalan ng katangian ay ang pangalan ng supplier). Gagamitin ang domain ng katangian kapag tinutukoy ang uri ng column sa antas ng pisikal na modelo. Para sa mga pangunahing katangian ng pangunahing key, sa tab na Pangkalahatan ng dialog na Mga Katangian, dapat kang gumawa ng marka sa window ng pagpili ng Pangunahing Key.

Upang magpakita ng icon ng katangian, piliin ang item na Display ng Entity sa menu ng konteksto at paganahin ang opsyon na Icon ng Katangian sa cascade menu. Ang isang maliit na icon ay ipapakita sa kaliwa ng pangalan ng katangian sa antas ng katangian ng pagpapakita ng modelo. Ang pangalan ng entity ay ipinapakita sa itaas ng rectangle na naglalarawan sa entity, ang listahan ng mga attribute ng entity ay ipinapakita sa loob ng rectangle. Ang listahan ay nahahati sa isang pahalang na linya, sa itaas kung saan ay ang mga pangunahing pangunahing katangian, sa ibaba kung saan ay ang mga hindi pangunahing katangian. Ang mga katangian ay dapat na pinangalanan sa isahan at may malinaw na kahulugan ng semantiko. Ang pagsunod sa panuntunang ito ay nagpapahintulot sa amin na bahagyang malutas ang problema ng normalisasyon ng data na nasa yugto na ng pagtukoy ng mga katangian. Halimbawa, ang paggawa ng attribute ng Supplier Phones sa Supplier entity ay sumasalungat sa mga kinakailangan sa normalization dahil ang attribute ay dapat atomic, ibig sabihin, hindi naglalaman ng maraming value. Ayon sa syntax ng IDEF1X, ang pangalan ng katangian ay dapat na natatangi sa loob ng modelo (at hindi lamang sa loob ng entity!). Ang bawat instance ng isang entity ay dapat na natatangi at naiiba sa iba pang mga katangian. Ang susunod na hakbang sa paglikha ng isang modelo ay ang magtatag ng mga ugnayan sa pagitan ng mga entity. Ang bawat relasyon ay dapat na tinatawag na pandiwa o pariralang pandiwa (Relationship Verb Phrases Fig. 5.6). Ang pangalan ng relasyon ay nagpapahayag ng ilang hadlang o panuntunan sa negosyo at ginagawang mas madaling basahin ang diagram, halimbawa:

Ang bawat CUSTOMER ORDER;

BAWAT ORDER AY DESIGN.

kanin. 5.B. Pangalan ng Relasyon - Mga Parirala ng Pandiwa ng Relasyon

Para gumawa ng bagong koneksyon:

• ilagay ang cursor sa gustong button sa tool palette (pagkilala o hindi pagkilala sa koneksyon) at pindutin ang kaliwang pindutan ng mouse;
• Mag-click muna sa magulang at pagkatapos ay sa child entity. Kapag naitatag ang mga ugnayan sa pagitan ng mga entity, ang mga pangunahing pangunahing katangian ng parent na entity ay migrate bilang mga dayuhang susi sa child entity. Bilang default, ang pangalan ng koneksyon ay hindi ipinapakita sa diagram. Upang ipakita ang pangalan, sa menu ng konteksto na lilitaw kung mag-left-click ka sa anumang lugar sa diagram na hindi inookupahan ng mga modelong bagay, piliin ang item na Display ng Relasyon at paganahin ang opsyon ng Verb Phrase sa menu ng konteksto.

Ang lohikal na modelo ng data ng lugar ng paksa na "Furniture to order" ay ipinapakita sa Fig. 5.7.

kanin. 5.7.

Ang kumpletong modelo ng katangian ay kumakatawan sa data sa ikatlong normal na anyo at kasama ang lahat ng mga entity, mga katangian at mga relasyon at ipinakita sa Fig. 5.8.

Sa antas ng entity, ang modelo ay ipinakita sa Fig. 5.9.

Sa Fig. Ipinapakita ng Figure 5.10 ang modelo ng data sa antas ng kahulugan.

kanin. 5.8.

kanin. 5.E. Layer ng Entity ng Modelo ng Data

Kakailanganin namin ang konsepto ng isang anomalya - isang pagkakaiba sa pagitan ng mga hadlang sa integridad ng konsepto at lohikal (pati na rin ang pisikal) na mga schema ng data. Ang layunin ng normalisasyon ay tiyak na alisin ang mga anomalyang lumalabas kapag ang data ay na-on, na-update, at tinanggal.

Ang apat na unang normal na anyo (mas tiyak, una, pangalawa, pangatlo at Boyce-Codd) ay pinagsama sa isang grupo dahil ang kanilang mga kahulugan ay batay sa klasikal na konsepto ng isang function na tinukoy sa isang diagram ng relasyon at sa teorama ni Heath.

Dalawa pang normal na anyo (ikaapat at ikalima) ang binagong paggamit functional dependencies. Huling normal na anyo- domain-key - nagmamarka ng pagbabalik sa pinanggalingan - isang lohikal na diskarte sa relational theory.

Isang praktikal na paraan ang irerekomenda para sa pagkuha ng base diagram sa unang apat na normal na anyo, halos palaging nagbubunga ng huling bersyon ng diagram. Ang katumpakan ng konstruksiyon na ito ay kailangang ma-verify sa pamamagitan ng mga pormal na pamamaraan, ibig sabihin, kailangan ang mga heuristic technique at normalization theory.

Talakayin muna natin ang tinatanggap na paraan ng paglalahad ng materyal sa normalisasyon. Natural, magpapatuloy tayo mula sa teorya ng normalisasyon na binuo sa loob ng balangkas ng modelo ng relational data. Gayunpaman, ipinakita ng karanasan na sa gayong pagtatanghal, ang mga nagsisimula ay nahihirapang maunawaan ang pinakamahalagang konsepto ng isang anomalya, na tinukoy bilang ilang katangian ng "pagkakamali" ng pagmamapa ng isang konseptwal na modelo ng negosyo sa isang modelo ng database. kaya lang

Gagamitin namin ang pagmamapa mula sa relational model hanggang sa entity-relationship model na alam mo na at pag-aaralan ang normalization sa ER model. Papayagan ka nitong gamitin ang mga semantika na kinakailangan upang gumana sa mga anomalya.

Pag-isipan nating muli ang tungkol sa mga koneksyon sa pagitan ng mga relasyon, koneksyon sa pagitan ng mga relasyon, at mga dayuhang susi.

5.1 Mga relasyon at dayuhang susi

Ginalugad ng mga nakaraang kabanata ang mga konsepto ng pag-uugnay ng mga entity at ang mga ugnayan sa pagitan nila. Malinaw nating makilala ang mga ito. Ang konsepto ng isang koneksyon ay hindi algebraic sa kalikasan, dahil ang mga koneksyon ay aktibo. Sa mga pagpapatupad, ang mga koneksyon ay nagtatakda ng istraktura ng database at nagpapatakbo sa panahon ng pagmamanipula ng data at mga pagbabago sa schema. Ang koneksyon ay isang algebraic na konsepto. Ang kahulugan ng data na nakuha kapag gumagawa ng isang koneksyon ay ganap na nakasalalay sa developer. Ang kahulugan ng koneksyon ay mahigpit na tinukoy ng kunwa na negosyo.

Ang semantika ng mga koneksyon ay medyo binuo. Bilang karagdagan sa kapangyarihan ng mga dulo, ang mga katangiang tulad ng sapilitan at pagkakakilanlan ay ginagamit. Sa relational na modelo, hindi sila maaaring ipahayag nang direkta (walang ganoong mga salita). Samakatuwid, isasaalang-alang namin ang mga unang normal na anyo sa loob ng balangkas ng modelong "entity-relasyon".

Ang mga ugnayan sa pagitan ng mga relasyon/entity sa parehong relational na modelo at ER diagram ay nabuo sa pamamagitan ng referential integrity constraint na tinatawag na "Foreign Key" (dinaglat na FK).

Upang hindi makalikha ng maling impresyon sa kahirapan ng relational model bilang imposibilidad ng pagpapatupad ng isang bagay, tandaan natin na sa loob nito ang n: m na koneksyon ay kinakatawan sa pamamagitan ng dalawang 1: n koneksyon, at ang mga kumplikadong koneksyon ay maaaring imodelo sa iba't ibang paraan. Kahit na ang mga pinagsama-sama ay maaaring kinakatawan sa anumang paraan sa pamamagitan ng pagpapakilala ng mga entity na naglalarawan sa kanilang komposisyon. Ang ganitong mga modelo ay maaaring epektibong maipatupad sa isang programa, ngunit malamang na hindi ito maginhawa para sa mga tao. Ang mga posibilidad para sa pagmomodelo ng mga istruktura ng data sa loob ng relational na modelo ay medyo malawak ngunit, siyempre, hindi walang limitasyon.

Talakayin natin ang isang pangkalahatang diskarte sa pagsusuri ng mga istruktura na tatalakayin pa gamit ang halimbawa ng dalawang magkakaugnay na entity na "Empleyado" at "Kagawaran", na inilalarawan sa Figure 5.1. Sa kaliwa ay isang opsyon na may nagpapakilalang koneksyon, sa kanan ay may hindi nagpapakilalang koneksyon.

kanin. 5.1. Halimbawa ng isa-sa-maraming relasyon

Nais kong ipaalala muli sa iyo na napagkasunduan naming isaalang-alang ang mga halimbawa tulad ng inilarawan sa teksto, at hindi tulad ng nangyayari o maaaring mangyari sa buhay. Ang limitasyong ito ay kinakailangan upang ang impormasyon ay madama ng lahat at palaging sa parehong paraan.

Sa parehong bersyon ng scheme, ang bawat empleyado ay itinalaga sa isa sa mga departamento. Mayroon kaming relasyon (“sa-marami” sa panig ng relasyong “Empleyado”). Para sa ugnayang "Empleyado", hindi ka makakapili ng deptno ng numero ng departamento na wala sa listahan ng mga departamento (ang entity na "Kagawaran"). Ang isang departamento ay maaaring wala, isa, dalawa o higit pang empleyado.

Napansin namin na may katulad na halimbawa (seksyon 2.2.7) na lumitaw ang isang kabalintunaan na sitwasyon. Ang direktor ay itinalaga sa ilang departamento, at ang pinuno ng departamentong ito ay nasa ilalim ng direktor at sa parehong oras ay magiging kanyang boss. Ngunit marahil ang mga departamento ay mga sentro ng gastos, at nagpasya silang iugnay ang suweldo ng direktor sa mga gastos ng isa sa mga departamento. Sa aming mga halimbawa ng pagsasanay, hindi ka dapat mag-abala sa mga naturang detalye, maliban kung, siyempre, ang kabaligtaran ay nakasaad. Sa simula pa lang, dapat kang masanay sa pag-iisip tungkol sa panig ng negosyo, bukod sa iba pang mga bagay, ngunit kapag nilutas ang mga problema sa edukasyon, hindi mo dapat palawakin ang mga gawain sa pagsusuri ng mga posibleng opsyon.

Ano ang pagkakaiba sa pagitan ng mga diagram sa Figure 5.1? Ang pagkakakilanlan ng koneksyon ay nag-iisip sa iyo na ang empleyado ay una at pangunahin bilang isang miyembro ng departamento. Ang isang koneksyon na hindi nagpapakilala ay nangangahulugan na ang kaakibat ng departamento ay minarkahan bilang isang bagay na pangalawang kahalagahan.

5.2 Mga uri ng komunikasyon. Pagkilala at hindi pagkilala, sapilitan at opsyonal na mga relasyon

Ang pagtukoy at hindi pagtukoy ng mga uri ng relasyon (tingnan ang Figure 5.1) ay hindi nauugnay sa teorya ng relational database, ngunit sa IDEF1X modeling standard kung saan nakabatay ang ERwin (aka AllFusion Data Modeller).

Kung ang isang dayuhang key ay lumikha ng isang umaasa (mahina) na entity, ipapasa ito sa pangkat ng mga katangian na bumubuo sa pangunahing susi ng entity na iyon. Sa kasong ito, nabuo ang isang pagkilala sa koneksyon. Ito ay palaging sapilitan.

Ang isang hindi nagpapakilalang relasyon ay ginagamit upang ikonekta ang dalawang malakas na entity. Ipinapasa nito ang susi sa lugar na hindi pangunahing katangian.

Para sa isang hindi nagpapakilalang relasyon, maaari mong tukuyin ang mandatory (ang buong relasyon, hindi ang katapusan nito). Kung ang relasyon ay kinakailangan (sa ERwin ito ang No Nulls flag), ang mga foreign key attribute ay makakatanggap ng NOT NULL flag, ibig sabihin ay hindi pinapayagan ang mga null value. Para sa isang opsyonal na relasyon (Nulls Allowed), ang foreign key ay maaaring NULL.

Pagkatapos nating makilala ang wikang SQL sa "SQL Language", gamit ang direktang engineering, posibleng makabuo ng SQL script na lumilikha ng fragment ng database schema. Ngunit kahit ngayon, kung medyo pamilyar ka na sa SQL, sa pamamagitan ng pagpunta sa Tools > Forward Engineer/Schema Generation, at pagkatapos ay pag-click sa Preview na button, tingnan ang nabuong text.

Bakit tayo gagamit ng mas kumplikadong modelo ng entity-relationship kapag isinasaalang-alang ang normalisasyon, sa halip na limitahan ang ating sarili sa klasikong diskarte sa loob ng relational na modelo? Pagkatapos ng lahat, ang pagdaragdag ng mga konsepto ng malakas at mahihinang entity, pagtukoy ng mga relasyon, mandatory at opsyonal na hindi pagtukoy na mga relasyon ay makabuluhang nagpapalubha sa mga semantika ng modelo ng data.

Ang pagpapakilala ng limang mas mataas na antas ng konsepto sa itaas ay nagbibigay ng isang wika na mas mahusay na sumasalamin sa mga tampok ng problema at samakatuwid ay mas naiintindihan ng developer. Papayagan ka nitong mabilis at walang pormal na pagbabagong makuha ang orihinal na schema ng relational base sa halos kumpletong anyo (mamaya ay ipahahayag namin ang ideyang ito nang mas tumpak: "sa ikatlong normal na anyo o Boyce-Codd normal na anyo").

Upang magtatag ng mga relasyon sa pagitan ng mga entity at lumikha ng mga dayuhang key, ang ERwin ay nagbibigay ng kakayahang hatiin ang mga uri ng relasyon sa ilang mga opsyon:

• pagtukoy ng relasyon - isang relasyon na tumutukoy sa isa-sa-isang pagsusulatan sa pagitan ng isang instance ng isang entity at isang solong instance ng isang nauugnay na entity at, bilang panuntunan, ay naglalarawan ng 1:1 na relasyon, ngunit kapag nagpapatupad ng isang nakakadena na pangunahing key, ito maaaring magpatupad ng one-to-many na relasyon (1:JV);
• non-identifying relationship - isang relasyon na nagpapatupad ng isa-sa-maraming uri ng relasyon (1 :N), sa pamamagitan ng kumakatawan sa isang dayuhang susi sa isang nauugnay na entity bilang isang simpleng katangian na maaaring sumailalim sa ilang mga karagdagang paghihigpit kumpara sa mga ordinaryong katangian ng impormasyon;
• maramihang relasyon - isang relasyon na nagpapatupad ng many-to-many (L G:M) na uri ng relasyon, ay kinakatawan lamang sa antas ng lohikal na modelo, na naglalarawan ng koneksyon sa pagitan ng mga entity, ngunit nang hindi gumagawa ng mga dayuhang key sa mga kaugnay na entity;
• categorization - isang relasyon na nagsisiguro sa pag-uugnay ng isang entity-community sa mga entity-categories gamit ang one-to-one (1:1) na uri ng relasyon at sabay na lumilikha ng foreign primary key sa mga entity-category na nauugnay sa pangunahing susi ng entity-komunidad.

Kapag gumagawa ng relasyon sa pagitan ng dalawang entity, piliin lang ang icon ng uri ng relasyon, at pagkatapos ay sunud-sunod na ituro ang magulang at mga nauugnay na entity. Gagawa ito ng relasyon at, kung papayagan ng uri ng relasyon, gagawa ng mga kinakailangang foreign key sa nauugnay na entity. Sa kaso kapag hindi tinukoy ng developer ang pangunahing key ng parent na entity at nakapagtatag ng isang relasyon, halimbawa, isang hindi nagpapakilala, hindi mangyayari ang paglikha ng isang foreign key, ngunit sa sandaling ang pangunahing key ay na tinukoy sa pangunahing entity, agad itong ipapakita sa nauugnay na entity ng isang foreign key alinsunod sa koneksyon sa pagitan ng mga entity na ito na umiiral sa modelo.

Ang tool na ERWin, kapag nagtatatag ng mga ugnayan sa pagitan ng mga entity, ay tumutukoy sa dalawang uri ng mga entity:

• parent - ay isang batayang entity na ang pangunahing susi ay maaaring lumipat sa isang nauugnay na entity;
• child - tinukoy ng isang entity na, kapag may koneksyon, tumatanggap ng foreign key na nabuo mula sa migrating primary key ng parent entity.

Ang dibisyong ito ay mukhang medyo lohikal, dahil, batay sa mga kakaibang koneksyon ng gusali at ang lohika ng lugar ng paksa, ang impormasyong inilarawan ng parent entity ay pinagsama-samang may kaugnayan sa data na inilarawan ng child entity. Halimbawa, kung isasaalang-alang ang ugnayan sa pagitan ng mga entity na "Customer" at "Order", isang partikular na customer, na kinakatawan ng isang instance ng entity na "Customer", pinagsasama (pinagsasama-sama) ang hanay ng mga order na ginawa niya sa electronic store.

zine. Bilang resulta, ang entity na "Order" na nauugnay sa entity na "Customer" ay maaaring ituring bilang isang bata, at ang entity na "Client" bilang isang magulang.

Ang paglalarawan ng mga relasyon ay naglalaman, kumpara sa mga entity at katangian, ng mas maliit na bilang ng mga katangian na kailangang ilarawan, ngunit sila rin, at kung minsan ay mas mahalaga, dahil pinapayagan ka nitong ilarawan at i-configure ang mga tuntunin sa integridad ng referential, na tinitiyak, kapag ipinatupad sa ang database, ang kawastuhan ng imbakan ng data . Ang isa sa mga katangian ay ang pangalan ng koneksyon, na ginagamit sa modelo ng database at tinutukoy ang pangunahing kahulugan ng koneksyon na itinatag sa pagitan ng mga entity (Larawan 3.15).

kanin. 3.15. Pangunahing paglalarawan ng komunikasyon sa ERWin

Ang column na "Pangalan" sa paglalarawan ng koneksyon ay nagbibigay sa developer ng pagkakataong tumukoy ng pangalan na nagpapakita ng semantikong kahulugan ng koneksyon. Ito ay isang mahalagang bahagi ng modelo, na nagbibigay-daan sa iyo upang hindi malabo na maunawaan ang kakanyahan at kahulugan ng itinatag na koneksyon, na, sa huli, ay dapat makatulong upang maayos na gawing normal ang modelo ng database, tama na muling pamamahagi ng mga indibidwal na katangian sa pagitan ng mga entity.

Mahalagang maunawaan na ang mga pangalan ng mga relasyon ay dapat, kung maaari, natatangi sa loob ng buong modelo ng database, at hindi lamang sa antas ng isang indibidwal na diagram. Ang pagkakaroon ng magkaparehong mga pangalan ng mga link ay maaaring humantong sa kawalan ng kakayahang matukoy nang tama ang kaukulang link at sa huli ay bumuo ng isang epektibong modelo. Ang iba pang mga katangian na naglalarawan sa ugnayan sa pagitan ng mga entity ay matatagpuan sa dialog box sa ibaba ng listahan ng mga relasyon ng modelo at naglalaman ng mga panuntunan para sa cardinality (cardinality), pagpapalit ng pangalan sa nabuong foreign key (role) at pagtiyak ng referential integrity.

Ang tatlong pinakamahalagang pangunahing katangian ng isang koneksyon (Larawan 3.16), na bumubuo sa pangunahing kakanyahan ng koneksyon, ay inilarawan sa unang tab na "General" at kumakatawan sa uri ng koneksyon, ang pangalan ng koneksyon, cardinality (kapangyarihan) . Ang mga parameter ng komunikasyon na ito ay dapat palaging tinukoy at inilarawan nang tama. Bilang karagdagan sa pangalan ng koneksyon, ang natitirang mga katangian ay ililipat sa panahon ng naaangkop na pagbabago sa pisikal na modelo, at pagkatapos ay sa database.

Tinutukoy ng unang katangian ng isang koneksyon ang uri nito (Figure 3.17): pagkilala o hindi pagkilala. Kasabay nito, sa pamamagitan ng pagpili ng naaangkop na uri ng relasyon, ang developer ay may pagkakataon (para sa isang hindi nagpapakilalang relasyon) na tukuyin ang kawalan ng isang instance ng parent entity, sa gayon ay nagpapahintulot sa foreign key na tukuyin ang walang laman na halaga na "NULL ”.

kanin. 3.16. Pangunahing katangian ng komunikasyon sa RZh Win

Karaniwan, kapag nagtatatag ng isang hindi nagpapakilalang relasyon, ang Null Option ay nakatakda sa Nulls Not Allowed. Ito ay tinutukoy ng mga kakaibang gawain sa data, ayon sa kung saan ang isang child data instance ay dapat na nauugnay sa isang magulang na instance. Ngunit kung minsan may mga kaso kapag hindi ito sinusunod. Bilang isang patakaran, ang sitwasyong ito ay lumitaw kapag ang mga bagay ng paksang lugar na pinagsama ng relasyon na ito ay katumbas at imposibleng malinaw na matukoy ang priyoridad ng paglitaw ng isang halimbawa ng isang partikular na nilalang. Pagkatapos ay itinakda ang halaga na "Null Allowed", tulad ng ipinapakita sa halimbawa (tingnan ang Fig. 3.17).

Dahil ang isa-sa-isa at isa-sa-maraming mga koneksyon ay nauugnay at ang mga pagkakaiba sa mga ito ay nasa kapangyarihan lamang at ilang mas mahigpit na kinakailangan, ang paglipat sa pagitan ng mga ganitong uri ng koneksyon ay maaaring gawin sa loob ng dialog box ng mga setting ng koneksyon, ang paglipat ng koneksyon mula sa ang "Hindi" uri ng pagkilala" upang i-type ang "Pagkilala". Sa kasong ito, hindi magiging available ang Null Option

para sa setup. Ito ay ipinaliwanag sa pamamagitan ng katotohanan na kapag ang isang pagtukoy na relasyon ay itinatag, ang dayuhang susi na nakuha sa isang entity ng bata ay ang pangunahing susi, at ayon sa mga panuntunan sa pagbuo ng database, ang pangunahing susi ay hindi maaaring mag-imbak ng isang walang laman na halaga. Samakatuwid, ang nagreresultang foreign key ay nakatakda sa Null Not Allowed.

Ang isa pang katangian na ginagawang posible na lumipat mula sa isa-sa-isang relasyon patungo sa isa-sa-maraming relasyon at sa kabaligtaran ay ang cardinality. Ang pagtatatag ng cardinality (kapangyarihan) ng isang koneksyon sa loob ng "Cardinality" at "Cardinality Value" na mga katangian ay nagtatakda ng mga patakaran para sa pagpuno ng mga pagkakataon ng isang child entity (Fig. 3.18). Mayroong apat na opsyon sa cardinality na tinutukoy ng ERWin:

• Zero, Isa o Higit pa (zero, isa o marami) - para sa isang child entity, anumang bilang ng mga instance na nauugnay sa isang instance ng parent entity ay posible, kabilang ang opsyon na walang instance;
• (P) Isa o Higit pa - ang bilang ng mga instance ng isang child entity na nauugnay sa isang instance ng isang parent na entity ay maaaring anuman, ngunit kapag gumagawa ng isang instance sa isang parent na entity, ang mga instance ay dapat na mayroon na sa child entity, na nangangailangan ng pagtatakda ng "Null Option" parameter " sa value na "Nulls Allowed", na nagpapahintulot sa null value na "NULL" na maimbak sa foreign key na nakuha sa pagtatatag ng relasyon;
• (Z) Zero o One - ang isang one-to-one na relasyon ay tinukoy, na nagpapahintulot sa pagkakaroon ng hindi hihigit sa isang instance ng data sa isang child entity;
• Cardinality Value - tumutukoy sa eksaktong bilang ng mga kaugnay na instance sa child entity, na maaari lamang makamit sa pamamagitan ng pagtatakda ng "Null Option" sa "Nulls Allowed", unang paggawa ng mga instance sa child entity, at pagkatapos ay pag-link sa kanila sa isang instance sa parent entity .

Bilang resulta ng pagpapakita ng cardinality (kapangyarihan) ng koneksyon sa modelo, ang alphanumeric na pagtatalaga nito ay ipapakita sa diagram. Kung ang opsyon sa cardinality (power) ay pinili sa opsyon na "Isa o marami", ang titik na "P" ay ipapakita, sa kaso ng cardinality "Zero o isa" - ang titik na "Z", sa kaso ng pagtukoy isang eksaktong numerical na halaga - ang tinukoy na halaga, sa iba pang mga opsyon walang mga marka na ipapakita sa modelo.

Ang isa pang katangian ng isang koneksyon ay inilarawan bilang pangunahing isa - ang semantikong nilalaman ng koneksyon (Larawan 3.19), na tinutukoy ng anyo ng pandiwa.

Ang paglalarawan na ito, tulad ng sa lahat ng mga modelo ng database sa anumang antas ng pagtatanghal, ay nagpapakita ng kakaibang pakikipag-ugnayan ng mga pagkakataon ng entity alinsunod sa mga katangian ng lugar ng paksa. Ang paglalarawan ay dapat na isang pariralang nagsasaad ng kaugnayan ng isang parent na entity instance sa isang child entity instance, o vice versa, na kumakatawan sa isang expression na naglalaman ng action verb.

Kapag naitatag ang isa-sa-isa at isa-sa-maraming relasyon, gaya ng tinalakay sa itaas, ang pangunahing susi ng parent na entity ay lumilipat sa child entity, na lumilikha ng kaukulang foreign key (Figure 3.20). Kadalasan, lalo na kapag gumagamit ng convention ng pagbibigay ng pangalan para sa mga elemento ng modelo, ang magkaparehong pangunahing key sa iba't ibang entity ay maaaring magkaroon ng parehong mga pangalan, na nagiging sanhi ng ilang mga paghihirap kapag nagtatatag ng mga relasyon, na nagreresulta sa pangangailangang ipakita ang mga dayuhang key na may mga pangalan na naroroon na sa entity. Ang isa pang opsyon kapag kinakailangang gamitin ang mekanismo ng pagbibigay ng pangalan ng isang pangunahing panuntunan sa paglilipat ay maaaring ang katangiang naglalarawan sa kaukulang foreign key ay kailangang mas tumpak ang pagkakasulat.

Ang solusyon sa mga problemang ito ay ipinapatupad sa pamamagitan ng mekanismong "Pangalan ng Tungkulin", kung saan tinukoy ng developer ang pangalan ng katangian para sa foreign key, dahil dapat itong kinakatawan sa modelo ng database at, bilang resulta, pagbabago sa database. Ang lugar na "Impormasyon ng Pangalan ng Tungkulin" ay naglalaman ng dalawang column:

• Migrated Attribute - nagpapakita ng attribute ng parent entity na kinakatawan ng foreign key sa nauugnay na child entity (hindi mababago);
• Pangalan ng Tungkulin—Isinasaad ang bagong foreign key attribute name value na dapat gamitin bilang kapalit ng migrating attribute name.

Ang pagtukoy sa gustong pangalan ng attribute sa column na "Role Name" ay hahantong sa pagpapalit ng pangalan ng foreign key attribute at kasunod na paggamit ng bagong attribute name sa lahat ng elemento ng database model kung saan kinakailangan.

Ang pagtukoy sa mga tuntunin sa integridad ng referential (Figure 3.21) ay isang hakbang sa pisikal na pagmomodelo ng database. Ito ay dahil sa ang katunayan na ang mga indibidwal na panuntunan para sa ilang mga DBMS ay maaaring hindi magagamit. Gayunpaman, ang ERwin ay nagbibigay ng kakayahang tukuyin ang mga tuntunin sa integridad ng referential para sa mga relasyong nabuo sa yugto ng lohikal na pagmomodelo. Sa yugtong ito, inaalok ang developer ng maximum na hanay ng mga panuntunan:

• Wala (absent) - isang panuntunan na ipinapalagay ang anumang pagkilos ng user nang hindi naaapektuhan ang iba pang elemento ng database;
• Walang Aksyon (walang aksyon) - isang panuntunan na ipinapalagay ang mga pagkilos na tinukoy ng developer;
• Paghigpitan (ipagbawal) ang isang panuntunan na nagbabawal sa pagsasagawa ng operasyon sa data kung totoo ang kundisyon ng pagsubok;
• Cascade - isang panuntunan na nagsasagawa ng mga sunud-sunod na pagkilos sa nauugnay na data alinsunod sa pagkilos na isinagawa sa data kung saan tinukoy ang panuntunang ito;
• Set Null - isang panuntunan na nagtatakda ng foreign key value sa NULL para sa mga kaugnay na pagkakataon;
• Itakda ang Default - Isang panuntunan na nagtatakda ng default na halaga na tinukoy para sa foreign key ng nauugnay na instance.

Ang mga panuntunan sa integridad ng sanggunian ay naglalayong tiyakin ang kawastuhan ng mga operasyon na may data kapag binago ang mga ito. Kaya, ang mga patakarang ito ay dapat sundin kung ang mga operasyon ay ipinatupad sa database, ngunit ang pagdaragdag, pagbabago at pagtanggal ng data. Ang ERWin ay nagpapatupad ng referential integrity constraint operations sa maximum na posible, na isinasaalang-alang ang pagpapatupad ng mga nauugnay na operasyon hindi lamang para sa mga pangunahing kaso na nakakaapekto sa mga pagbabago sa database, kundi pati na rin para sa mga operasyon na hindi dapat magkaroon ng makabuluhang pagbabago sa database. Bilang resulta, hinihiling sa developer na tukuyin ang mga panuntunan sa integridad ng referential kapag nagsasagawa ng mga pagkilos sa data kapag binabago ang mga instance ng data sa mga entity ng magulang at anak. Kasunod nito, ang lahat ng mga pagkilos na ito, kung hindi ibinigay ang mga ito sa DBMS, ay mako-convert sa mga awtomatikong execution program modules (triggers) at maiuugnay sa mga pagkilos na isinagawa sa data. Kung ang DBMS ay naglalaman ng mga tinukoy na referential integrity actions, ang mga ito ay idedeklara ng kaukulang mga panuntunan kapag naglalarawan ng mga talahanayan ng data.

Kapag bumubuo ng isang marami-sa-maraming koneksyon, ang developer ay may pagkakataon na tukuyin ang isang minimum na hanay ng mga katangian ng koneksyon, kabilang ang pagtukoy sa semantic load. Walang iba pang mga patakaran at katangian ang itinatag para sa ganitong uri ng koneksyon, dahil kapag lumipat sa isang pisikal na modelo, ang naturang koneksyon ay dapat na gawing normal at kinakatawan ng isa-sa-maraming mga koneksyon (Larawan 3.22).

• kapag tinukoy ang isang koneksyon sa unang pagkakataon, piliin ang icon ng koneksyon at sunud-sunod na pumili ng isang entity ng komunidad at isa sa mga entity ng kategorya;
• Gamit ang parehong icon ng link ng pagkakategorya, ikonekta ang natitirang mga entity ng kategorya sa pamamagitan ng sunud-sunod na pagpili ng isang graphic na elemento at ang susunod na entity ng kategorya.

Bilang resulta ng pagsasagawa ng mga pagkilos na ito, ang modelo ng database ay magkakaroon ng representasyon ng relasyon na katulad ng halimbawa sa itaas (tingnan ang Larawan 3.22).

Mayroong dalawang uri ng mga relasyon sa pagkakategorya, ang isa ay dapat matukoy kapag nagtatatag ng ganitong uri ng relasyon (Larawan 3.23). Upang ipahiwatig ang mga pagkakaiba sa uri ng koneksyon sa pagkakategorya, ang pagtatalaga ng isang graphic na elemento ay ipapakita sa dalawang linya o isang linya (Talahanayan 3.1).

Para sa link ng categorization mismo, walang ibang mga katangian ang tinukoy, at binibigyan lamang ng pagkakataon ang developer na tingnan ang istruktura ng link ng categorization (Figure 3.24). Ginagawang posible ng paglalarawang ito na makita kung aling mga entity ng kategorya ang tinutukoy ng mga subtype, at kung aling entity-komunidad ang kinakatawan ng isang supertype.

Ang mga koneksyon mismo mula sa elemento ng graphical categorization sa mga entity ay isa-sa-isang koneksyon, at, bilang panuntunan, ang mga nakapirming katangian ay tinukoy para sa kanila. Ang developer ay binibigyan ng pagkakataon na tukuyin lamang ang semantic na nilalaman ng mga relasyon, ang pangalan ng foreign key attribute at ang referential integrity rules.

kanin. 3.24. Paglalarawan ng kaugnayan sa pagkakategorya sa EHRI

• Ang isang detalyadong talakayan ng mga tuntunin sa integridad ng referential ay tinatalakay sa Seksyon 3.2.

Ang paglikha ng mga modernong sistema ng impormasyon ay isang kumplikadong gawain, ang solusyon na nangangailangan ng paggamit ng mga espesyal na pamamaraan at tool. Hindi kataka-taka na kamakailan sa mga system analyst at developer ay nagkaroon ng malaking pagtaas ng interes sa CASE (Computer-Aided Software/System Engineering) - mga teknolohiya at tool ng CASE na ginagawang posible na mai-systematize at i-automate nang husto ang lahat ng mga yugto ng pagbuo ng software.

Ang aklat na inaalok sa mambabasa ay isang praktikal na gabay sa paglikha ng mga sistema ng impormasyon gamit ang epektibong pagsusuri, disenyo at mga tool sa pagbuo ng code mula sa teknolohiyang PLATINUM - BPwin at ERwin. Naglalaman din ito ng paglalarawan ng mga pamamaraan ng pagsusuri sa istruktura at disenyo ng mga modelo ng data sa lawak na kinakailangan para sa praktikal na gawain. Ang aplikasyon ng mga pamamaraan ay inilalarawan sa mga halimbawa.

Ang aklat ay isinulat batay sa personal na karanasan ng may-akda na nakuha habang gumagawa ng mga sistema ng impormasyon, nagbibigay ng mga lektura at pagsasagawa ng mga praktikal na klase sa mga teknolohiya ng CASE at mga tool ng CASE sa Training Center ng kumpanya ng Interface Ltd. Ito ay tinutugunan sa mga espesyalista sa larangan ng teknolohiya ng impormasyon: mga analyst ng system, mga tagapamahala ng proyekto, mga developer - at maaari ding maging kapaki-pakinabang para sa mga undergraduate at graduate na mga mag-aaral na nag-aaral ng mga pangunahing kaalaman sa pagsusuri ng system at disenyo ng mga sistema ng impormasyon.

Aklat:

Ang isang relasyon ay isang lohikal na relasyon sa pagitan ng mga entity. Ang bawat relasyon ay dapat na tinatawag na pandiwa o pariralang pandiwa (Relationship Verb Phrases) (Fig. 2.20). Ang pangalan ng relasyon ay nagpapahayag ng ilang hadlang o panuntunan sa negosyo at ginagawang mas madaling basahin ang diagram, halimbawa:

Bawat CLIENT <размещает> MGA ORDER;

Bawat ORDER <выполняется> EMPLEYADO.

kanin. 2.20. Pangalan ng Relasyon - Mga Parirala ng Pandiwa ng Relasyon

Ipinapakita ng koneksyon kung aling mga order ang inilagay ng customer at kung aling empleyado ang tumutupad sa order. Bilang default, ang pangalan ng koneksyon ay hindi ipinapakita sa diagram. Upang ipakita ang pangalan, sa menu ng konteksto na lilitaw kung mag-left-click ka sa anumang lugar sa diagram na hindi inookupahan ng mga object ng modelo, piliin ang Display Options/Relationship at pagkatapos ay paganahin ang opsyon na Verb Phrase.

Sa lohikal na antas, maaari kang magtatag ng isa-sa-maraming nagpapakilalang relasyon, marami-sa-maraming relasyon, at isa-sa-maraming hindi nagpapakilalang relasyon (ayon sa pagkakabanggit, ito ang mga pindutan mula kaliwa hanggang kanan sa tool palette).

Tinutukoy ng IDEF1X ang pagitan ng dependent at independent entity. Ang uri ng isang entity ay natutukoy sa pamamagitan ng kaugnayan nito sa iba pang mga entity. Ang isang nagpapakilalang relasyon ay itinatag sa pagitan ng isang independiyenteng (magulang na dulo ng relasyon) at umaasa (bata na dulo ng relasyon) na entity. Kapag iginuhit ang isang pagkakakilanlan na relasyon, awtomatikong iko-convert ng ERwin ang child entity sa isang umaasang entity. Ang umaasang entity ay kinakatawan ng isang parihaba na may mga bilugan na sulok (entity Umorder sa Fig. 2.21). Ang isang instance ng isang umaasang entity ay tinukoy lamang sa pamamagitan ng kaugnayan nito sa parent entity, iyon ay, sa istraktura sa Fig. 2.21 Ang impormasyon tungkol sa isang order ay hindi maaaring ilagay at walang kabuluhan kung walang impormasyon tungkol sa kliyente na naglagay nito. Kapag naitatag ang isang pagkakakilanlan na relasyon, ang mga katangian ng pangunahing susi ng parent entity ay awtomatikong ililipat sa pangunahing key ng child entity. Ang operasyong ito ng pagdaragdag ng mga attribute sa isang child entity kapag gumagawa ng isang relasyon ay tinatawag na attribute migration. Sa child entity, ang mga bagong attribute ay minarkahan bilang foreign key - (FK).

kanin. 2.21. Isang pagtukoy ng ugnayan sa pagitan ng isang independiyente at umaasa na talahanayan

Sa hinaharap, kapag bumubuo ng isang database schema, ang pangunahing key attribute ay makakatanggap ng NOT NULL attribute, na nangangahulugang imposibleng gumawa ng entry sa talahanayan ng mga order nang walang impormasyon tungkol sa numero ng customer.

Kapag naitatag ang isang hindi nagpapakilalang relasyon (Figure 2.22), nananatiling independyente ang child entity, at ang mga pangunahing pangunahing katangian ng parent na entity ay lumilipat sa mga hindi pangunahing bahagi ng parent na entity. Ang isang hindi nagpapakilalang relasyon ay ginagamit upang i-link ang mga independiyenteng entity.

kanin. 2.22. Relasyon na hindi nagpapakilala

Instance ng entity Empleyado maaaring umiral nang hiwalay sa anumang pagkakataon ng isang entity Kagawaran, ibig sabihin, ang isang empleyado ay maaaring magtrabaho sa isang organisasyon nang hindi nakarehistro sa anumang departamento.

Ang isang nagpapakilalang koneksyon ay ipinapakita sa diagram bilang isang solidong linya na may makapal na tuldok sa dulo ng bata ng koneksyon (tingnan ang Fig. 2.21), ang isang hindi nagpapakilala ay ipinapakita bilang isang may tuldok na linya (Larawan 2.22).

Para gumawa ng bagong koneksyon:

ilagay ang cursor sa nais na button sa tool palette (pagkilala o hindi pagkilala sa koneksyon) at i-click ang kaliwang pindutan ng mouse (Larawan 2.2);

Mag-click muna sa magulang at pagkatapos ay sa child entity.

Maaaring baguhin ang hugis ng linya ng komunikasyon. Upang gawin ito, kailangan mong kunin ang nais na linya ng koneksyon gamit ang mouse at ilipat ito mula sa isang lugar hanggang sa ang linya ay magsimulang magmukhang mas mahusay.

Button sa tool palette

Naaayon sa link na nagpapakilala, pindutan

Many-to-many na relasyon at button

Tumutugon sa isang hindi nagpapakilalang relasyon.

Upang i-edit ang mga katangian ng isang relasyon, mag-right click sa relasyon at piliin ang Relationship Editor mula sa menu ng konteksto.

Sa tab na Pangkalahatan ng dialog na lalabas, maaari mong itakda ang kapangyarihan, pangalan at uri ng koneksyon (Larawan 2.23).

Lakas ng komunikasyon (Cardinality) - nagsisilbing tukuyin ang ratio ng bilang ng mga instance ng parent entity sa bilang ng mga instance ng bata.

Mayroong apat na uri ng kapangyarihan (Larawan 2.24):

ang pangkalahatang kaso kung saan ang isang instance ng parent entity ay tumutugma sa 0, 1, o maraming instance ng child entity ay hindi minarkahan ng anumang simbolo;

minarkahan ng simbolong P ang kaso kapag ang isang instance ng parent entity ay tumutugma sa 1 o maraming instance ng child entity (zero value ay hindi kasama);

ang simbolo Z ay minarkahan ang kaso kapag ang isang instance ng parent entity ay tumutugma sa 0 o 1 instance ng child entity (maraming value ay hindi kasama);

Ang numero ay nagmamarka ng kaso ng isang eksaktong tugma, kapag ang isang instance ng parent na entity ay tumutugma sa isang paunang natukoy na bilang ng mga instance ng child entity.

kanin. 2.23. Dialog ng Relationship Editor

Bilang default, ang simbolo na kumakatawan sa lakas ng link ay hindi ipinapakita sa diagram. Upang ipakita ang pangalan, sa menu ng konteksto na lilitaw kung mag-left-click ka sa anumang lugar sa diagram na hindi inookupahan ng mga object ng modelo, piliin ang Display Options/Relationship at pagkatapos ay paganahin ang Cardinality na opsyon.

Pariralang Pandiwa- isang pariralang nagpapakilala sa ugnayan ng magulang at anak. Para sa isang one-to-many na relasyon, pagkilala o hindi pagkakakilanlan, sapat na upang tukuyin ang isang pangalan na nagpapakilala sa relasyon mula sa magulang sa anak na entity (Magulang-sa-Anak). Para sa isang many-to-many na relasyon, dapat na tukuyin ang mga pangalan ng Parents-to-Child at Child-to-Magulang.

kanin. 2.24. Mga pagtatalaga ng kapangyarihan

Uri ng koneksyon (pagkilala/hindi pagkilala). Para sa isang hindi nagpapakilalang relasyon, maaari mong tukuyin ang Nulls. Sa kaso ng isang ipinag-uutos na relasyon (No Nulls), kapag bumubuo ng isang database schema, ang foreign key attribute ay makakatanggap ng NOT NULL attribute, sa kabila ng katotohanan na ang foreign key ay hindi magiging bahagi ng primary key ng child entity. Sa kaso ng isang opsyonal na relasyon (Nulls Allowed), ang foreign key ay maaaring NULL. Ang isang opsyonal na relasyon na hindi nagpapakilala ay minarkahan ng isang transparent na brilyante sa bahagi ng parent entity (tingnan ang Figure 2.22).

kanin. 2.25. Tab ng Rolename/RI Actions ng dialog ng Relationship Editor

Sa tab na Kahulugan, maaari kang magbigay ng mas kumpletong kahulugan ng relasyon upang ma-refer ito sa hinaharap.

Sa tab na Rolename/RI Actions, maaari mong itakda ang pangalan ng tungkulin at mga panuntunan sa integridad ng referential.

Pangalan ng tungkulin (functional name) - isa itong kasingkahulugan para sa foreign key attribute na nagsasaad kung anong papel ang ginagampanan ng attribute sa isang child entity.

kanin. 2.26. Mga pangalan ng dayuhang pangunahing tungkulin

Sa halimbawang ipinapakita sa Fig. 2.26, talaga Empleyado dayuhang susi Numero ng departamento ay may functional na pangalan na "Where Works" na nagsasaad kung anong papel ang ginagampanan ng attribute na ito sa entity. Bilang default, tanging ang pangalan ng tungkulin ang ipinapakita sa listahan ng katangian. Upang ipakita ang buong pangalan ng katangian (kapwa ang functional na pangalan at ang pangalan ng tungkulin), sa menu ng konteksto na lilitaw kung mag-left-click ka sa anumang lugar sa diagram na hindi inookupahan ng mga modelong object, piliin ang Display Options/Entities at pagkatapos ay paganahin ang Rolename/ opsyon na Attribute (Fig. 2.25). Ang buong pangalan ay ipinapakita bilang ang functional na pangalan at ang batayang pangalan na pinaghihiwalay ng isang tuldok (tingnan ang Larawan 2.26).

Kinakailangang gumamit ng mga pangalan ng tungkulin kapag ang dalawa o higit pang mga katangian ng parehong entity ay tinukoy sa parehong saklaw, iyon ay, mayroon silang parehong saklaw, ngunit magkaibang kahulugan. Sa Fig. 2.27 kakanyahan Nagbebenta ng pera naglalaman ng impormasyon tungkol sa isang currency exchange act kung saan dalawang currency ang kasangkot - ibinebenta at binili. Ang impormasyon tungkol sa mga pera ay nakapaloob sa entity Pera. Samakatuwid, ang mga entidad Nagbebenta ng pera At Pera dapat na naka-link nang dalawang beses at ang pangunahing susi ay - Numero ng pera dapat lumipat sa entity ng dalawang beses Pera bilang isang dayuhang susi. Kinakailangang makilala ang mga katangiang ito, na naglalaman ng impormasyon tungkol sa bilang ng naibenta at binili na pera (mayroon silang magkaibang kahulugan), ngunit tumutukoy sa parehong entity Pera (may karaniwang hanay ng mga halaga). Sa halimbawa sa Fig. 2.27 mga katangian ang nakatanggap ng mga pangalan ng tungkulin Nabenta At Binili.

kanin. 2.27. Ang kaso ng mga mandatoryong pangalan ng tungkulin

Ang isa pang halimbawa ng ipinag-uutos na pagpapangalan ng tungkulin ay recursive na koneksyon(minsan ay tinatawag na "fish hook") kapag ang parehong entity ay parehong magulang at anak sa parehong oras. Kapag tinutukoy ang isang recursive na relasyon, dapat na lumipat ang attribute bilang foreign key sa mga hindi pangunahing attribute ng parehong entity. Ang isang katangian ay hindi maaaring lumitaw nang dalawang beses sa parehong entity sa ilalim ng parehong pangalan, kaya dapat itong matanggap ang pangalan ng tungkulin. Sa Fig. 2.26 kakanyahan Empleyado naglalaman ng pangunahing katangian ng key Numero ng tauhan. Ang impormasyon tungkol sa manager ng empleyado ay nakapaloob sa parehong entity, dahil nagtatrabaho ang manager sa parehong organisasyon. Upang sumangguni sa manager ng isang empleyado, dapat kang lumikha ng recursive na relasyon (sa Fig. 2.26 ang koneksyon ay manager/subordinate) at magtalaga ng pangalan ng tungkulin ("Manager"). Tandaan na ang isang recursive na relasyon ay maaari lamang maging hindi pagkakakilanlan. Kung hindi, ang foreign key ay kailangang maging bahagi ng pangunahing key at makatanggap ng NOT NULL attribute kapag bumubuo ng schema. Ito ay magiging imposible na bumuo ng isang hierarchy - ang puno ng pag-uulat ay dapat na may ugat - isang empleyado na hindi nag-uulat sa sinuman sa loob ng organisasyon.

Ang command/follow na relasyon ay ipinapakita sa Fig. 2.26 ay nagbibigay-daan sa iyo upang mag-imbak ng isang puno-tulad ng hierarchy ng subordination ng mga empleyado. Ang ganitong uri ng recursive na komunikasyon ay tinatawag hierarchical recursion at tumutukoy sa isang relasyon kung saan ang isang pinuno (isang instance ng isang parent entity) ay maaaring magkaroon ng maraming subordinates (instances ng isang child entity), ngunit ang isang subordinate ay may isang lider lamang (Figure 2.28).

Hierarchical recursion Recursion ng network

kanin. 2.28. Subordination ng mga instance ng entity sa hierarchical at network recursion

Ang isa pang uri ng recursion ay recursion ng network, kapag ang isang pinuno ay maaaring magkaroon ng maraming subordinates at, sa kabaligtaran, ang isang subordinate ay maaaring magkaroon ng maraming tagapamahala. Tinutukoy ng network recursion ang isang web ng mga ugnayan sa pagitan ng mga pagkakataon ng isang entity ng magulang at anak. Ito ang kaso kapag ang isang entity ay nasa isang many-to-many na relasyon sa sarili nito. Upang malutas ang isang many-to-many na relasyon, kailangan mong gumawa ng bagong entity (many-to-many na relasyon ay tatalakayin nang detalyado sa ibaba).

kanin. 2.29. Halimbawang pagpapatupad ng network recursion

Sa Fig. Isinasaalang-alang ng 2.29 ang isang halimbawa ng pagpapatupad ng network recursion. Ang istraktura ay nagpapakita ng mga relasyon ng pamilya sa pagitan ng mga miyembro ng pamilya sa anumang kumplikado. Katangian Uri ng relasyon maaaring kumuha ng mga kahulugang "ama-anak", "ina-anak", "lolo-apo", "biyenang-babae", "biyenan", atbp. Mula noong isang pamilya Ang relasyon ay palaging nag-uugnay sa dalawang tao, mula sa kakanyahan Kamag-anak ni K. kakanyahan pagkakamag-anak dalawang link sa pagkakakilanlan ang itinatag na may mga pangalan ng tungkulin na "Senior" at "Junior". Ang bawat miyembro ng pamilya ay maaaring nauugnay sa sinumang iba pang miyembro ng pamilya, bukod dito, ang parehong pares ng mga kamag-anak ay maaaring konektado sa pamamagitan ng iba't ibang uri ng mga relasyon sa pamilya.

Kung ang isang attribute ay na-migrate bilang foreign key sa higit sa isang level, ang buong pangalan ng foreign key (role name + base attribute name) ay ipapakita sa unang level, at ang role name lang ang ipinapakita sa pangalawa o higit pa. mga antas. Sa Fig. Ipinapakita ng Figure 2.30 ang isang istraktura ng data na naglalaman ng isang entity pangkat, kakanyahan Manlalaro, na nag-iimbak ng impormasyon tungkol sa mga manlalaro ng bawat koponan, at ang entidad layunin, naglalaman ng impormasyon tungkol sa mga layunin na nai-score ng bawat manlalaro. Banyagang pangunahing katangian Numero ng koponan kakanyahan Manlalaro may pangalan ng papel na "Aling koponan ang kanyang nilalaro".

kanin. 2.30. Lumilipat ng mga pangalan ng tungkulin

Sa susunod na antas, mahalagang layunin, tanging ang pangalan ng tungkulin ng kaukulang foreign key attribute ang ipinapakita (Anong team ang nilalaro niya).

Ang mga panuntunan sa integridad ng referential (RI) ay mga lohikal na konstruksyon na nagpapahayag ng mga panuntunan sa negosyo para sa paggamit ng data at kumakatawan sa mga panuntunan sa pagpapasok, pagpapalit at pagtanggal. Kapag bumubuo ng schema ng database batay sa mga opsyon sa lohikal na modelo na tinukoy sa tab na Rolename/RI Actions, bubuo ng mga panuntunan sa integridad ng deklaratibong referential, na dapat ireseta para sa bawat relasyon, at mga trigger na nagtitiyak ng integridad ng referential. Ang mga nag-trigger ay mga program na pinapagana kapag may ipinapatupad na insert, replace, o delete command (INSERT, UPDATE, o DELETE). Sa Fig. 2.30 mayroong isang pagkakakilanlan na ugnayan sa pagitan ng mga entity Koponan At Manlalaro. Ano ang mangyayari kung tatanggalin mo ang isang utos? Instance ng entity Manlalaro hindi maaaring umiral nang walang utos (pangunahing key attribute Saang team siya naglalaro? Numero ng koponan hindi maaaring kunin ang halagang NULL), samakatuwid, kailangan mong ipagbawal ang pagtanggal ng isang koponan habang mayroon itong hindi bababa sa isang manlalaro (upang tanggalin ang isang koponan, kailangan mo munang tanggalin ang lahat ng mga manlalaro), o agad na tanggalin ang lahat ng mga manlalaro kasama ang koponan. Ang ganitong mga tuntunin sa pagtanggal ay tinatawag na "paghihigpit" at "kaskad" (Parent RESTRICT at Parent CASCADE, tingnan ang Fig. 2.25). Tandaan na ang mga entity Manlalaro At layunin, sa turn, ay konektado din sa pamamagitan ng isang link sa pagkakakilanlan at kung ang isang koponan ay tinanggal sa isang kaskad, ang lahat ng mga manlalaro sa koponan at ang lahat ng mga layunin na kanilang nai-iskor ay tatanggalin. Ang pagpapatupad ng isang utos na magtanggal ng isang hilera ay maaaring aktwal na humantong sa pagtanggal ng libu-libong mga hilera sa database, kaya dapat mong gamitin ang cascade delete na panuntunan nang may pag-iingat. Kung nakatakda ang isang panuntunan sa paghihigpit sa pagtanggal, kung susubukan mong tanggalin ang isang koponan na mayroong kahit isang manlalaro, magbabalik ng error ang relational na DBMS server.

Sa Fig. 2.26 isang opsyonal na relasyong hindi nagpapakilala sa pagitan ng mga entity Kagawaran At Empleyado. Instance ng entity Empleyado maaaring umiral nang walang sanggunian ng departamento (foreign key attribute Saan siya nagtatrabaho? Numero ng departamento maaaring NULL). Sa kasong ito, posibleng magtakda ng panuntunan para sa pagtatakda nito sa zero - SET NULL. Kapag nagde-delete ng departamento, ang foreign key attribute ng entity Empleyado - Saan siya nagtatrabaho? Numero ng departamento magiging NULL. Nangangahulugan ito na kapag ang isang departamento ay tinanggal, ang empleyado ay nananatiling nagtatrabaho sa organisasyon nang hindi nakatalaga sa anumang departamento at ang impormasyon tungkol sa kanya ay nai-save.

Posibleng magtakda ng dalawa pang panuntunan sa pagtanggal (kung sinusuportahan ng DBMS):

SET DEFAULT - kapag nagtatanggal, ang foreign key attribute ay itinalaga ng default na halaga. Halimbawa, kapag ang isang koponan ay tinanggal, ang mga manlalaro ay maaaring ilipat sa ibang koponan.

WALA - kapag tinanggal, hindi nagbabago ang halaga ng foreign key attribute. Ang rekord tungkol sa manlalaro ay "nakabitin sa hangin," ibig sabihin, ito ay tumutukoy sa isang koponan na wala na. Ang sitwasyong ito ay tipikal para sa "flat" na mga talahanayan. Halimbawa, kung ang impormasyon ng manlalaro at koponan ay naka-imbak sa mga dbf file, maaari mong tanggalin ang entry ng koponan nang hindi nalalaman ng file ng mga manlalaro ang anumang bagay tungkol sa katotohanang wala ang katumbas na koponan. Samakatuwid, sa mga desktop o file server system, ang functionality na nagpapatupad ng referential integrity rules ay ipinapatupad sa client application.

Kinokontrol ng mga panuntunan sa pagtanggal kung ano ang mangyayari sa database kapag ang isang row ay tinanggal. Katulad nito, kontrolin ang mga panuntunan sa pagpasok at pag-update kung ano ang mangyayari sa database kung ang mga row ay binago o idinagdag. Halimbawa, maaari kang magtakda ng panuntunan na nagbibigay-daan sa iyong magdagdag ng bagong koponan kung naka-enroll lang ang kahit isang manlalaro dito. Ang nais na pag-uugali ay maaaring makamit sa pamamagitan ng mga sumusunod na aksyon:

Itakda ang lakas ng ugnayan sa pagitan ng mga entity Koponan At Manlalaro, katumbas ng "Isa o higit pa" - 1 o higit pa (uri P). Ipinapalagay na ang isang pagkakakilanlan na relasyon ay naitatag.

Italaga ang RI trigger action na "Parent Insert-CASCADE" para kapag may nalikhang bagong row sa table Koponan kahit isang row ay awtomatikong ginawa sa child table Manlalaro.

Italaga ang pagkilos ng RI trigger na "Parent Delete-CASCADE" sa koneksyon upang kapag ang isang row ay tinanggal mula sa talahanayan Koponan ang kaukulang row o row mula sa table Manlalaro ay tinanggal din.

Awtomatikong nagtatalaga ang ERwin ng default na halaga ng integridad ng referential sa bawat relasyon bago ito idagdag sa diagram. Ang mga RI mode na itinalaga ng ERwin bilang default (ipinapakita sa Talahanayan 2.4) ay maaaring baguhin sa Referential Integrity Default na editor, na tinatawag sa pamamagitan ng pag-click sa RI Defaults button sa Target Server dialog (Server/Target Server menu).

Talahanayan 2.4. Ang mga halaga ng RI ay itinalaga bilang default sa ERwin, pati na rin ang mga posibleng mode para sa bawat uri ng komunikasyon

Link ng pagkakakilanlan	Nulls Allowed	Non-identifying relationship (No Nulls)	Pangkategoryang koneksyon
Bata Tanggalin ang Mga posibleng mode	RESTRICT, CASCADE, WALA	RESTRICT, CASCADE, WALA, SET NULL, SET DEFAULT		RESTRICT, CASCADE,
WALA
Child Delete Default Modes	WALA	WALA	WALA	WALA
Child Insert Posibleng mga mode	RESTRICT, CASCADE,		RESTRICT, CASCADE, WALA, SET DEFAULT	RESTRICT, CASCADE,
WALA	WALA
Child Insert Default Modes	PAGHIHIGPIT	SET NULL	PAGHIHIGPIT	PAGHIHIGPIT
Child Update Posibleng mga mode	RESTRICT, CASCADE, WALA	RESTRICT, CASCADE, WALA, SET NULL, SET DEFAULT	RESTRICT, CASCADE, WALA, SET DEFAULT	RESTRICT, CASCADE, WALA
Mga Default na Mode ng Pag-update ng Bata	PAGHIHIGPIT	SET NULL	PAGHIHIGPIT	PAGHIHIGPIT
Magulang Tanggalin Posibleng mga mode	RESTRICT, CASCADE, WALA	RESTRICT, CASCADE, WALA, SET NULL, SET DEFAULT	RESTRICT, CASCADE, WALA, SET DEFAULT	RESTRICT, CASCADE,
WALA
Magulang Tanggalin ang Mga Default na Mode	PAGHIHIGPIT	SET NULL	PAGHIHIGPIT	CASCADE
Parent Insert Posibleng mga mode	RESTRICT, CASCADE, WALA	RESTRICT, CASCADE, WALA, SET NULL, SET DEFAULT	RESTRICT, CASCADE, WALA, SET DEFAULT	RESTRICT, CASCADE, WALA
Mga Default na Mode ng Pagpasok ng Magulang	WALA	WALA	WALA	WALA
Magulang Update Posibleng mga mode	RESTRICT, CASCADE, WALA	RESTRICT, CASCADE, WALA, SET NULL, SET DEFAULT	RESTRICT, CASCADE, WALA, SET DEFAULT	RESTRICT, CASCADE, WALA
Mga Default na Mode ng Pag-update ng Magulang	PAGHIHIGPIT	SET NULL	PAGHIHIGPIT	CASCADE

Many-to-many na komunikasyon ay posible lamang sa antas ng lohikal na modelo ng data. Sa Fig. Ang Figure 2.31 sa itaas ay nagpapakita ng isang halimbawa ng isang many-to-many na relasyon. Ang isang doktor ay maaaring makakita ng maraming mga pasyente, ang isang pasyente ay maaaring gamutin ng ilang mga doktor. Ang ganitong koneksyon ay ipinahiwatig ng isang solidong linya na may dalawang tuldok sa mga dulo.