Mga Pangunahing Gawain sa Disenyo ng Database

1.1 Panimula

Ang pagdidisenyo ng isang database ay medyo katulad ng pagdidisenyo ng arkitektura ng isang proyekto ng Java. Maaari mong ilagay ang lahat ng data sa isang pares ng mga talahanayan, o maaari kang bumuo ng isang magandang istraktura ng data mula sa mga schema at dose-dosenang mga talahanayan.

Narito ang mga gawain na karaniwang kinakaharap ng isang developer kapag nagdidisenyo ng isang database:

1. Tinitiyak na ang lahat ng kinakailangang impormasyon ay nakaimbak sa database.
2. Tinitiyak ang posibilidad na makakuha ng data sa lahat ng kinakailangang kahilingan.
3. Pagbabawas ng redundancy at pagdoble ng data.
4. Tinitiyak ang Integridad ng Database
5. Pag-optimize ng bilis ng pag-access ng data

Ang pangunahing bagay na dapat tandaan ay hindi ka makakagawa ng perpektong istraktura ng database, dahil. ito, tulad ng iyong code, ay patuloy ding magbabago. May tatlong bagay na dapat mong tandaan kapag nagdidisenyo ng iyong istraktura ng database:

1. Ang istraktura ay dapat na sapat na mabuti.
2. Dapat may lohika sa lahat ng bagay na mauunawaan ng ibang tao.
3. Ang maagang pag-optimize ay ang ugat ng lahat ng kasamaan.

Hindi mo kailangang gawin ang pinakamahusay na istraktura ng database sa mundo. Magbabago pa rin siya. Ang iyong gawain ay upang matiyak na pagkatapos ng 20 pagbabago sa istraktura ng iyong database, ito ay sapat na madaling malaman ito.

Malamang sa mga unang taon ng iyong trabaho, walang magtitiwala sa iyo na magdisenyo ng base mula sa simula. Gagawa ka ng mga pagbabago sa isang umiiral nang schema. Kailangan mong subukang maunawaan batay sa kung anong mga prinsipyo ang isinaayos at sundin ang mga ito . Sa kanilang charter, hindi sila umakyat sa monasteryo ng ibang tao.

Huwag i-optimize ang database hanggang sa kinakailangan. Kung ang talahanayan ay mayroon lamang ilang daang mga hilera, malamang na ang DBMS ay itago ito sa memorya at mga query sa cache dito.

Sa kabilang banda, dapat mong mapabilis ang gawain ng mahahalagang kahilingan sa sampu o kahit daan-daang beses. At magiging maganda kung alam mo kung paano gawin ito. Paano nila nasasabi sa high school sa unang taon? "Kalimutan mo ang lahat ng itinuro sa iyo sa paaralan..."

Kung alam mo kung ano ang database normalization, pagkatapos ay nagmamadali akong pasayahin ka, sa iyong trabaho ay malamang na haharapin mo ang de-normalization . Wala nang mas mahalaga para sa mga santuwaryo ng proyekto kaysa sa bilis ng database. At kung, upang mapabilis ang pagpili ng data mula sa database, kailangan mong pagsamahin ang 200 (!) Table sa isa (na may napakalaking redundancy), kakailanganin mong gawin ito.

1.2 Disenyo ng Aklatan

Sumisid tayo sa paksa ng kaunti at isipin ang tungkol sa disenyo ng database gamit ang isang bagay na kasing simple ng isang tipikal na aklatan ng aklat.

Ang pangunahing gawain ng anumang aklatan ay ang pagproseso ng pondo ng libro. Madaling makilala ang tatlong pangunahing grupo ng mga user ng system: reader, librarian, administrator . Ang aktibidad ng bawat isa ay ipinapakita sa isang use case diagram.

Sa ngayon, ang ilang mga entidad at relasyon ng hinaharap na database ay maaaring makilala:

Sa diskarteng ito, hindi malinaw kung paano ikonekta ang mambabasa sa aklat (ang mambabasa ay walang arity sa "pag-isyu / pagtanggap" na relasyon. Kung ang libro ay may ilang mga kopya, maaari itong maibigay sa ilang mga mambabasa. Kahit na kung ang isang libro ay nauunawaan bilang isang kopya, pagkatapos ay kapag nai-save sa talahanayan ng mga libro ng kasalukuyang mambabasa, magiging imposible na makakuha ng impormasyon tungkol sa kung sino (at kung gaano karaming beses) kinuha ang aklat na ito nang mas maaga.

Ang solusyon ay maaaring ang pagpapakilala ng isang karagdagang entity - isang card para sa pag-isyu ng isang libro. Kapag ang libro ay ibinigay sa mambabasa, ang isang card ay nilikha, at kapag ang libro ay ibinigay, isang kaukulang marka ay inilalagay dito. Sa tulong ng mga card na ito, natutukoy ang mga utang ng bawat user at kinakalkula ang mga istatistika sa paggamit ng mga libro. Kapag nagbu-book ng literatura ng mambabasa, sinimulan din ang isang card; kung ang nai-book na literatura ay hindi kinuha ng mambabasa sa loob ng isang tiyak na panahon, ang card ay masisira. May limitasyon sa bilang ng mga aklat na maaaring i-book ng isang mambabasa.

Kapag pumipili ng panitikan, tinitingnan ng gumagamit ang katalogo ng panitikan na may kakayahang i-filter ang mga resulta ng paghahanap ayon sa may-akda, pamagat, taon ng publikasyon.

Posibleng kalkulahin ang mga istatistika para sa lahat ng mga aklat sa aklatan, habang ang bilang ng mga naibigay na kopya ng aklat para sa isang takdang panahon. Maaari mo ring itakda ang pinakamababang bilang ng mga instance ng libro kung saan isinagawa ang pagkalkula. Batay sa mga istatistikang ito, ang mga hindi nagamit na aklat ay tinanggal mula sa aklatan.

Ang mga sumusunod na pangunahing entidad ng lugar ng paksa ay maaaring makilala:

• user (mga librarian at administrator);
• mambabasa;
• silid ng pagbabasa;
• aklat;
• card ng pagpapalabas ng libro;
• book booking card.

Ang binagong ER-diagram ng database ay ipinapakita sa figure.

Ayon sa mga kaso ng paggamit na ipinapakita sa Figure 1, dapat ipatupad ng database ang mga sumusunod na query (hindi isang kumpletong listahan):

• magpakita ng mga aklat na tumutugma sa mga tinukoy na kundisyon;
• ipakita ang mga user na may mga card para sa pag-isyu ng mga aklat na hindi naisara sa oras (ang librarian ay naghahanap ng mga may utang);
• ipakita ang lahat ng mga libro na tumutugma sa mga card sa pagpapahiram ng libro ng user na hindi isinara sa oras (dumating ang user sa library para sa mga bagong libro - kailangan mong makita kung siya ay isang may utang at ipaalam sa kanya ang tungkol dito);
• tanggalin ang lahat ng booking card na ginawa mahigit N segundo ang nakalipas;
• ipakita ang lahat ng mga aklat na nauugnay sa hindi nakasarang mga card ng reservation ng libro ng tinukoy na user (nag-order ang mambabasa ng mga libro at pumunta sa library para sa kanila - kailangang makuha ng librarian ang listahang ito upang maibigay ito).

1.3 Pagbuo ng iskema

Upang bumuo ng schema ng data, dapat mo munang dagdagan ang ER diagram ng mga detalye ng mga entity (pinuhin ito). Minsan, sa parehong oras, posible na makahanap ng mga pagkakamali sa pagbuo ng isang diagram ng ER - sa gawaing ito, natagpuan na ang libro ay kailangang "kahit papaano" na konektado sa silid ng aklatan.

Magagawa ito sa pamamagitan ng paglalagay ng kinakailangang "numero ng bulwagan" sa aklat, gayunpaman, sa pamamaraang ito, ang parehong aklat ay kailangang ilarawan sa database nang maraming beses (kung ito ay nangyayari sa iba't ibang mga bulwagan). Ang isang mas tamang diskarte ay ang pagpapakilala ng karagdagang entity na "paglalagay ng libro". Ang figure ay nagpapakita ng isang ER diagram na may idinagdag na entity at props.

Ang diagram ng ER sa itaas ay sumasalamin sa mga pangunahing talahanayan, mga relasyon at mga katangian; sa batayan nito, maaari kang bumuo ng isang modelo ng database. Walang pamantayan para sa diagram ng ER, ngunit mayroong ilang mga notasyon (Chen, IDEFIX, Martin, atbp.), ngunit hindi mahanap ang pamantayan o ang mga notasyon para sa modelo ng domain. Gayunpaman, sa kurso ng pagbuo ng naturang diagram, ang mga pangunahing field (panlabas at panloob) ay kinakailangang naka-highlight, kung minsan ay mga index at mga uri ng data.

Sa kasong ito, sa sumusunod na diagram:

• para sa mga link, ang notasyon ni Martin ("crow's feet" ay ginagamit);
• ang mga talahanayan ay ipinapakita bilang mga parihaba na nahahati sa 3 mga seksyon:
• pangalan ng talahanayan;
• panloob na mga susi (minarkahan ng isang marker);
• ang natitirang mga patlang, habang ang mga ipinag-uutos ay minarkahan ng isang marker.

Sa pagbuo ng modelong ito, nagkaroon ng pagnanais na sumali sa talahanayan ng mga administrator sa talahanayan ng mga librarian - idagdag ang talahanayan ng mga gumagamit, gayunpaman:

• ang administrator ay hindi nauugnay sa isang partikular na silid (kailangan mong punan ang kaukulang field na may mga null value);
• malamang na magpapalubha ito sa pamamahagi ng mga karapatan sa pag-access - ngayon lamang ang administrator ng database (na gumagana sa pamamagitan ng isang espesyal na panel ng DBMS at walang account sa system na binuo) ang may access sa talahanayan ng mga administrator. Gayunpaman, kapag sumali sa mga talahanayan, ang mga query ng user ay mangangailangan ng access sa bagong talahanayan.

Sa paggawa ng diagram na ito, nakita at naitama ang isang depekto sa diagram ng ER - isang talahanayan ang idinagdag librarians_roomsna pinagsasama ang mga librarian at bulwagan. Ito ay kinakailangan dahil ang isang librarian ay maaaring magtrabaho sa ilang silid, ngunit maraming librarian ang maaaring magtrabaho sa parehong silid.

Kapag nagdidisenyo ng mga database, dapat ay marunong kang mangatwiran kahit man lang tulad ng halimbawa sa itaas. Kung sa tingin mo ay nagtagumpay ka, pumunta pa tayo: mas maraming teorya.