Relatsioonandmebaasi elemendid. Relatsioonandmebaaside põhimõisted. Relatsioonandmebaaside põhimõisted

SUHTELINE ANDMEBAAS JA SELLE OMADUSED. SUHTETABELITE VAHELISED SUHTED

Suhete andmebaas on omavahel ühendatud tabelite kogum, millest igaüks sisaldab teavet teatud tüüpi objektide kohta. Tabelirida sisaldab andmeid ühe objekti (näiteks toote, kliendi) kohta ja tabeli veerud kirjeldavad erinevaid omadusi need objektid - atribuudid (näiteks nimi, tootekood, klienditeave). Kirjetel, see tähendab tabeli ridadel, on sama struktuur - need koosnevad väljadest, mis salvestavad objekti atribuute. Iga väli, st veerg, kirjeldab ainult ühte objekti omadust ja sellel on rangelt määratletud andmetüüp. Kõigil kirjetel on samad väljad, ainult need kuvavad erinevaid teabe omadused objekti.

Relatsioonandmebaasis peab igal tabelil olema esmane võti - väli või väljade kombinatsioon, mis tuvastab tabeli iga rea ​​kordumatult. Kui võti koosneb mitmest väljast, nimetatakse seda kombineeritud võtmeks. Võti peab olema ainulaadne ja kirje kordumatult identifitseerima. Võtmeväärtust saab kasutada ühe kirje leidmiseks. Võtmeid kasutatakse ka andmebaasis oleva teabe korraldamiseks.

Relatsioonandmebaasi tabelid peavad vastama suhete normaliseerimise nõuetele. Suhete normaliseerimine on ametlik tabelite moodustamise piirangute aparaat, mis välistab dubleerimise, tagab andmebaasi salvestatute järjepidevuse ja vähendab andmebaasi haldamisega seotud tööjõukulusid.

Looge tabel Õpilane, mis sisaldab järgmisi välju: rühma number, täisnimi, õpilase õpilase number, sünniaeg, eriala segamine, õppejõu nimi. Sellisel teabe salvestamise korraldusel on mitmeid puudusi:

  • teabe dubleerimine (eriala ja teaduskonna nimi kordub iga õpilase kohta), seetõttu suureneb andmebaasi maht;
  • tabelis oleva teabe uuendamise protseduur on keeruline, kuna neid on vaja muuta tabeli kirjed.

Tabeli normaliseerimine on mõeldud nende puuduste kõrvaldamiseks. Seal on kolm normaalset suhtevormi.

Esimene tavaline vorm. Relatsioonitabel vähendatakse esimeseks normaalkujuks siis ja ainult siis, kui ükski selle rida ei sisalda ühelgi väljal rohkem kui ühte väärtust ja ükski selle põhiväljadest pole tühi. Niisiis, kui õpilaste tabelist on vaja teavet saada õpilase nime järgi, siis tuleks täisnime väli jagada perekonnanime, nime ja isanime osadeks.

Teine tavaline vorm... Relatsioonitabel on määratud teises tavavormis, kui see vastab esimese tavavormi nõuetele ja kõik selle esmase võtme hulka mittekuuluvad väljad on funktsionaalselt primaarvõtmega täielikult seotud. Tabeli teise normaalkuju viimiseks on vaja kindlaks määrata väljade funktsionaalne sõltuvus. Väljade funktsionaalne sõltuvus on sõltuvus, kui teabeobjekti puhul vastab võtmeatribuudi kindlale väärtusele ainult üks kirjeldava atribuudi väärtus.

Kolmas normaalne vorm. Tabel on kolmandas tavavormis, kui see vastab teise tavavormi nõuetele, ükski selle võtmeväline väli ei ole funktsionaalselt sõltuv ühestki muust võtmeväljast. Näiteks õpilaste tabelis (grupi number, täisnimi, hinnete raamatu number, sünniaeg, starosta) on kolm välja - hinnetelehe number, rühma number, starosta - transitiivses suhtes. Rühma number sõltub hinderaamatu numbrist ja ülemus sõltub rühma numbrist. Transitiivse sõltuvuse kõrvaldamiseks on vaja osa õpilastabeli väljadest üle kanda teise tabelisse Group. Tabelid on järgmisel kujul: õpilane (rühma number, täisnimi, hinnete raamatu number, sünniaeg), rühm (rühma number, juht).

Relatsioonitabelites on võimalikud järgmised toimingud:

  • Sama struktuuriga tabelite ühendamine. Tulemuseks on ühine tabel: kõigepealt esimene, siis teine ​​(liitmine).
  • Sama struktuuriga tabelite ristmik. Tulemus - valitakse need kirjed, mis on mõlemas tabelis.
  • Sama struktuuriga tabelite lahutamine. Tulemus - valitakse need kirjed, mida pole lahutatud.
  • Näide (horisontaalne alamhulk). Tulemus - valitakse kirjed, mis vastavad teatud tingimustele.
  • Projektsioon (vertikaalne alamhulk). Tulemuseks on seos, mis sisaldab mõningaid algsete tabelite välju.
  • Kahe tabeli Descartes'i korrutis Saadud tabelikirjed saadakse, ühendades esimese tabeli iga kirje teise tabeli iga kirjega.

Relatsioonitabelid võivad olla omavahel seotud, seetõttu saab andmeid hankida mitmest tabelist korraga. Tabelid on omavahel ühendatud, et lõpuks vähendada andmebaasi mahtu. Iga tabelipaari suhe on ette nähtud, kui neil on samad veerud.

On järgmisi tüüpe infolinke:

  • üks ühele;
  • üks mitmele;
  • palju-mitmele.

Üks-ühele suhtlemine eeldab, et esimese tabeli üks atribuut vastab ainult teise tabeli ühele atribuudile ja vastupidi.

Üks-mitmele suhe eeldab, et esimese tabeli üks atribuut vastab teise tabeli mitmele atribuudile.

Suhe mitmele-mitmele eeldab, et esimese tabeli üks atribuut vastab teise tabeli mitmele atribuudile ja vastupidi.

Suhteandmebaasid on praegu kõige levinumad, kuigi koos üldtunnustatud eelistega on neil ka mitmeid puudusi. Suhtlusmeetodi eelised hõlmavad järgmist:

Väikese kogumi abstraktsioonide olemasolu, mis muudavad suhteliselt lihtsaks enamiku ühiste teemavaldkondade modelleerimise ja võimaldavad täpseid vormilisi määratlusi, jäädes samas intuitiivseks;

Lihtsa ja samas võimsa matemaatilise aparaadi olemasolu, mis põhineb peamiselt hulkade teoorial ja matemaatiline loogika ning andes teoreetilise aluse suhtlusviisile andmebaaside korraldamisel;

Võimalus mitte-navigeerimisandmetega manipuleerida, ilma et oleks vaja teada andmebaaside konkreetset füüsilist korraldust välismälus.

Suhtesüsteemide levik võttis kaua aega. Kuigi selle valdkonna peamised teoreetilised tulemused saadi juba 70ndatel ja samal ajal ilmusid relatsiooniliste DBMS -ide esimesed prototüübid, kaua aega peeti võimatuks selliste süsteemide tõhusat rakendamist. Eespool märgitud eelised ning meetodite ja algoritmide järkjärguline kogunemine relatsiooniandmebaaside korraldamiseks ja haldamiseks viisid aga selleni, et 80ndate keskel tõrjusid relatsioonisüsteemid varakult DBMSid maailmaturult välja.

Praegu ei ole relatsiooniliste DBMS-ide kriitika peamine teema nende tõhususe puudumine, vaid mõned nendele süsteemidele omased piirangud (lihtsuse otsene tagajärg), kui neid kasutatakse niinimetatud mittetraditsioonilistes piirkondades (levinumad näited on disaini automatiseerimise süsteemid). ), mis nõuavad äärmiselt keerukaid andmestruktuure. Teine relatsiooniandmebaaside sageli täheldatud puudus on suutmatus domeeni semantikat piisavalt kajastada. Teisisõnu, suhtesüsteemides on teadmiste esitamise võimalused valdkonna semantilise eripära kohta väga piiratud. Kaasaegsed uuringud suhetesüsteemide valdkonnas on peamiselt pühendatud nende puuduste täpsele kõrvaldamisele.

Relatsioonandmebaaside põhimõisted on andmetüüp, domeen, atribuut, tuple, esmane võti ja seos.

Mõiste andmetüüp relatsioonandmemudelis on programmeerimiskeeltes andmetüübi mõistega täiesti vastav. Tavaliselt võimaldavad kaasaegsed relatsiooniandmebaasid salvestada märke, arvandmeid, bittringe, spetsialiseeritud arvandmeid (näiteks "raha"), aga ka spetsiaalseid "ajalisi" andmeid (kuupäev, kellaaeg, ajavahemik). Aktiivselt arendatakse lähenemisviisi relatsioonisüsteemide võimaluste laiendamiseks abstraktsete andmetüüpidega (näiteks Ingres / Postgres perekonna süsteemidel on vastavad võimalused).

Suhtemudeli andmestruktuurid. Relatsioonandmete mudel korraldab ja esitab andmeid tabelite või seoste kujul. Suhteline See on termin, mis pärineb matemaatikast ja tähistab lihtsat kahemõõtmelist tabelit. Relatsiooniline lähenemine andmebaaside loomisel kasutab suhteteooria terminoloogiat. Lihtsaim kahemõõtmeline tabel on määratletud kui suhtumine.

tabel on relatsioonimudeli peamine andmestruktuuri tüüp (objekt). Tabeli struktuuri määrab populatsioon veerud. Tabeli iga rida sisaldab vastavas väärtuses ühte väärtust veerg. Tabelis ei saa olla kahte identset rida. Ridade koguarv ei ole piiratud.

Veerg vastab mõnele andmeühikule - atribuut, mis on lihtsaim andmestruktuur. Tabelis ei saa määratleda mitut üksust, rühma või korduvat rühma, nagu eespool käsitletud võrgu- ja hierarhiamudelites. Tabeli igas veerus peab olema nimi vastav andmeelement (atribuut).

Tabeli veergu vastava atribuudi väärtustega kutsutakse domeen, ja stringid erinevate atribuutide väärtustega - tupp.

Relatsioonitabel-seos. Joonisel fig. 9 on illustreeriv relatsioonitabel-suhe R... Formaalne määratlus suhe R (relatsioonitabel) tugineb selle ideele domeenid D mina, (veerud) ja tuples K j (read). Domeenide komplektidel (D i) määratletud seos R on alamhulk Domeenide Descartes'i (otsene) produkt D 1 * D 2 *… .. * D n

Tabel-seos(vt joonis 1) sisaldab veerge, kus on andmeelementide nimed - atribuudid (A 1, A 2, ...). D -atribuutide väärtused on tabeli sisuosas ning moodustavad ridade ja veergude. Paljud atribuutide väärtused ühes veerus moodustavad ühe domeen D i... Paljud atribuutide väärtused ühel real moodustavad ühe korteež Et j. Suhtumine R moodustub tellitud hulgast tuples.

R = (Кj), J = 1 m Кj = (d 1j, d 2 j,… d nj),

kus n on suhte domeenide arv; määratleb suhte mõõde;

j on tuple number;

m on numbrite koguarv kutsutud suhetes kaasnumber suhe.

Joonis 9. Suhteline tabel-suhete illustratsioon

Domeen. Kõige üldisemal kujul määratakse domeen kindlaks, määrates kindlaks teatud põhiandmetüübi, kuhu domeeni elemendid kuuluvad, ja suvalise loogiline väljend mida rakendatakse andmetüübi elemendile. Kui selle loogilise avaldise väärtus on tõene, on andmeüksus domeenielement.

Domeeni mõiste kõige õigem intuitiivne tõlgendus on domeeni kui vastuvõetava võimaliku väärtuste kogumi mõistmine seda tüüpi... Näiteks on meie näites domeeninimed määratletud tähemärkide põhitüübi järgi, kuid selle väärtused võivad sisaldada ainult neid stringe, mis võivad nime esindada (eriti sellised stringid ei saa alata pehme märgiga).

Samuti tuleks märkida domeenikontseptsiooni semantilist koormust: andmeid peetakse võrreldavateks ainult siis, kui need kuuluvad samasse domeeni. Meie näites on domeenid "Tühjad numbrid" ja "Grupinumbrid" täisarvu tüüpi, kuid pole võrreldavad. Pange tähele, et enamik relatsioonilisi DBMS -e ei kasuta domeeni mõistet, kuigi Google V.7 seda juba toetab.

Suhte skeem, andmebaasi skeem. Suhteskeem on nimeline paaride komplekt (atribuudi nimi, domeeninimi (või tüüp, kui domeeni mõistet ei toetata)). Suhteskeemi aste või "ariteet" on selle komplekti kardinaalsus. Näite suhte aste on KUUS, see tähendab 6-astmeline. Kui kõik ühe suhte atribuudid on määratletud erinevates domeenides, on mõistlik kasutada atribuutide nimetamiseks vastavate domeenide nimesid (unustamata muidugi, et see on lihtsalt mugaval viisil nimetamine ega välista domeeni ja atribuudi eristamist). DB skeem (struktuurses mõttes) on nimega seostatud skeemide kogum.

Nimekirja, mis annab relatsioonitabelite nimed, nende atribuudid (allajoonitud võtmed) ja võõrvõti definitsioonid, nimetatakse relatsioonilise andmebaasi skeem. See on relatsioonilise andmebaasi olelustsükli etapi loomise esialgne tulemus. Näide:

TÖÖLINE [ TÖÖTAJA ID, NIMI, TUNNIMÄÄR, OSKUSTÜÜP, SVPV-ID]

Võõrad võtmed: SKILL-TÜÜP, millele viitab OSKUS

SVPV-ID viitas TÖÖTAJALE

ÜLESANNE [ TÖÖTAJA ID, BLDG-ID, START-DATE, PÄEVADE ARV]

Võõrad võtmed: WORKER-ID viitas WORKER

BLILG-ID, millele viitab BVILDING

BVILDING [ BLDG-ID, ADRESS, TYPE, QLTY-LEVEL, STATVS]

OSKUS [ OSKUS- TÜÜP, BONUS-MÄÄR, TUNDID NÄDALAS]

Tuple, suhe. Antud seose skeemile vastav koopia on paaride komplekt (atribuudi nimi, väärtus, mis sisaldab ühte seose skeemi kuuluva atribuudi nime ühe esinemise. "Väärtus" on selle atribuudi (või andmetüübi, kui domeenikontseptsiooni ei toetata.) Seega langeb tuple aste või "ariteet" ehk elementide arv selles kokku vastava seoskeemi "ariteediga".

Suhtumine Kas samade suhete skeemile vastavate numbrite komplekt. Mõnikord, et mitte segadusse sattuda, ütlevad nad "relatsiooniskeem" ja "seosejuht", mõnikord nimetatakse seose skeemi seose pealkirjaks ja suhet liigituste kogumina kehaks suhe. Tegelikult on suhte skeemi mõiste programmeerimiskeeltes struktureeritud andmetüübi kontseptsioonile kõige lähemal. Oleks üsna loogiline lubada suhete skeemi eraldi määratlemist ja seejärel üht või mitut seost selle skeemiga.

Relatsioonandmebaasides see aga nii ei ole. Selliste andmebaaside seose skeeminimi on alati sama, mis vastava eksemplari suhte nimi. Klassikalistes relatsiooniandmebaasides muudetakse pärast andmebaasiskeemi määratlemist ainult eksemplari suhteid. Neis võivad ilmuda uued liigid ja olemasolevaid saab kustutada või muuta. Kuid paljud rakendused võimaldavad muuta ka andmebaasi skeemi: määratleda uusi ja muuta olemasolevaid seoskeeme. Tavaliselt nimetatakse seda andmebaasi skeemi areng.

Tavaline igapäevane suhte esitusviis on tabel, mille pealkiri on seose diagramm ja read on eksemplari suhte tuples; sel juhul nimetavad atribuutide nimed selle tabeli veerud. Seetõttu ütlevad nad mõnikord "tabeli veergu", mis tähendab "suhte atribuut". Kui jõuame relatsiooniliste andmebaaside korraldamise ja haldustööriistade praktiliste küsimusteni, kasutame seda ühist terminoloogiat. Seda terminoloogiat kasutab enamik kommertssuhete DBMS -e.

Relatsioonandmebaas on seoste kogum, mille nimed on samad, mis andmebaasiskeemi seoskeemide nimed.

Nagu näete, on relatsiooniliste andmemudelite struktuurilistel põhikontseptsioonidel (peale domeeni mõiste) väga lihtne intuitiivne tõlgendus, kuigi relatsiooniliste andmebaaside teoorias on need kõik määratletud absoluutselt formaalselt ja täpselt.

Suhtetabeli võti. Tuplesid ei tohi sees korrata suhete tabelid ja seega peab neil olema kordumatu tunnus - esmane võti.Üks või mitu atribuuti, mille väärtused unikaalselt identifitseerivad tabelirea võti tabelid.

Esmane võti nimetatakse lihtne , kui see koosneb ühest atribuudist või komposiit, kui see koosneb mitmest atribuudist. Lisaks esmasele võtmele võib seos sisaldada ka sekundaarsed võtmed.

Sekundaarne võti – see on võti, mille väärtusi saab korrata erinevates tuplemärkides. Neid saab kasutada sama sekundaarse võtme väärtusega ridade rühma otsimiseks.

Väline võti - see on ühest tabelist pärit atribuutide kogum, mis on teise (või sama) tabeli võti. Välisvõtmed pakuvad olulisi suhteid tabelite vahel. Neid kasutatakse ühe tabeli andmete sidumiseks teise tabeli andmetega. Välisvõti atribuutidel ei pea olema samad nimed, mis võtmeatribuutidel, millele need vastavad.


Sarnane teave.


Selle artikliga alustame uut tsüklit, mis on pühendatud andmebaasidele, kaasaegsetele andmetele juurdepääsu ja töötlemise tehnoloogiatele. Selle tsükli jooksul plaanime kaaluda kõige populaarsemaid töölaua- ja serverihaldussüsteeme. andmebaasid(DBMS), andmetele juurdepääsu mehhanismid (OLD DB, ADO, BDE jne) ja utiliidid andmebaasidega töötamiseks (haldustööriistad, aruannete genereerijad, graafiliste andmete esitamise tööriistad). Lisaks plaanime pöörata tähelepanu andmete Internetis avaldamise meetoditele, aga ka sellistele populaarsetele andmete töötlemise ja säilitamise meetoditele nagu OLAP (On-Line Analytical Processing) ja andmeladude loomisele (Data Warehousing).

Selles artiklis vaatleme andmebaasihaldussüsteemide aluseks olevaid põhimõisteid ja põhimõtteid. Arutleme relatsiooniliste andmete mudeli, kontseptsiooni üle referentsiaalne terviklikkus ja andmete normaliseerimise põhimõtteid, samuti andmete kujundamise tööriistu. Seejärel räägime teile, mis on DBMS, milliseid objekte saab andmebaasides sisaldada ja kuidas neile objektidele taotlusi esitatakse.

Relatsioonandmebaaside põhimõisted

Alustame DBMS -i põhimõistetest ja lühikesest sissejuhatusest relatsiooniliste andmebaaside teooriale - tänapäeval kõige populaarsemale andmete salvestamise viisile.

Suhteandmete mudel

Suhteandmete mudel pakkus välja tuntud andmebaasiuurija dr. E.F. Codd 1969. aastal, kui ta töötas koos IBM -iga. Selle mudeli põhimõisted avaldati esmakordselt 1970. aastal (A Relational Model of Data for Large Shared Data Banks, CACM, 1970, 13 N 6).

Relatsioonandmebaas on andmeladu, mis sisaldab kahemõõtmeliste tabelite komplekti. Sellise hoidla haldamiseks vajalike tööriistade komplekti nimetatakse relatsiooniliste andmebaaside haldussüsteem (RDBMS)... RDBMS võib sisaldada utiliite, rakendusi, teenuseid, teeke, rakenduste loomise tööriistu ja muid komponente.

Mis tahes relatsiooniandmebaasi tabel koosneb stringid(nimetatud ka rekordeid) ja veerud(nimetatud ka veerised). Selles tsüklis kasutame mõlemat terminipaari.

Tabeli ridad sisaldavad teavet selles esitatud faktide (või dokumentide või inimeste, ühesõnaga, sama tüüpi objektide) kohta. Veeru ja rea ​​ristumiskohas on tabelis sisalduvate andmete konkreetsed väärtused.

Tabelite andmed vastavad järgmistele põhimõtetele:

  1. Iga rea ​​ja veeru ristumiskohas sisalduv väärtus peab olema aatomiline(st mitte jagatud mitmeks väärtuseks).
  2. Samas veerus olevad andmeväärtused peavad olema sama tüüpi, mis on antud DBMS -is kasutamiseks saadaval.
  3. Iga tabeli kirje on ainulaadne, see tähendab, et tabelis pole kahte kirjet, mille väljade väärtused oleksid täiesti identsed.
  4. Igal väljal on ainulaadne nimi.
  5. Tabeli väljade järjestus ei oma tähtsust.
  6. Sissekannete jada pole samuti oluline.

Hoolimata asjaolust, et tabeliridasid loetakse järjestamata, võimaldab iga andmebaasihaldussüsteem selle seast sorteerida valikutes olevaid ridu ja veerge kasutaja soovitud viisil.

Kuna tabeli veergude järjestus ei ole asjakohane, viidatakse neile nime järgi ja need nimed on antud tabeli jaoks kordumatud (kuid ei pea olema kogu andmebaasis ainulaadsed).

Nüüd teame, et relatsiooniandmebaasid koosnevad tabelitest. Mõne teoreetilise kontseptsiooni illustreerimiseks ja näidete loomiseks peame valima mingisuguse andmebaasi. Et mitte "ratast leiutada", kasutame Microsoftiga kaasas olevat NorthWindi andmebaasi SQL Server ja Microsoft Access.

Nüüd vaatame tabelitevahelisi seoseid.

Võtmed ja lingid

Heitkem pilk tabelisse Kliendid NorthWindi andmebaasist (oleme sealt eemaldanud väljad, mis ei ole tabelite vaheliste seoste illustreerimiseks asjakohased).

Kuna tabeli read on järjestamata, vajame iga rea ​​kordumatuks tuvastamiseks veergu (või mitme veeru komplekti). Sellist veergu (või veergude komplekti) nimetatakse esmane võti (esmane võti). Iga tabeli esmane võti peab sisaldama iga rea ​​jaoks unikaalseid, mitte tühje väärtusi.

Kui primaarvõtmel on mitu veergu, nimetatakse seda kombineeritud esmane võti (kombineeritud esmane võti).

Tüüpiline andmebaas koosneb tavaliselt mitmest seotud tabelist. Tellimuste tabeli fragment.

Selle tabeli väli CustomerID sisaldab selle tellimuse esitanud kliendi identifikaatorit. Kui meil on vaja välja selgitada tellimuse esitanud ettevõtte nimi, peame otsima tabeli Kliendid väljalt CustomerID sama kliendi -ID väärtuse ja lugema leitud real ettevõtte välja nime CompanyName. Teisisõnu, peame kliendi ID välja järgi linkima kaks tabelit - kliendid ja tellimused. Nimetatakse veergu, mis osutab mõnele teisele selle kirjega seotud tabeli kirjele välisvõti (välisvõti). Nagu näete, on tabeli Tellimused puhul võõrvõti veerg CustomerID (joonis 1).

Teisisõnu, välisvõti on veerg või veergude kogum, mille väärtused vastavad teise tabeli olemasolevatele esmaste võtmete väärtustele.

Seda tabelite vahelist seost nimetatakse suhtlemine (suhe). Seos kahe tabeli vahel luuakse, määrates ühe tabeli võõrvõti väärtused teise primaarvõtme väärtustele.

Kui iga klient tabelis Kliendid saab esitada ainult ühe tellimuse, väidetakse, et need kaks tabelit on omavahel seotud üks ühele (üks-ühele suhe). Kui iga klient tabelis Kliendid saab esitada null, üks või mitu tellimust, siis väidetakse, et need kaks tabelit on omavahel seotud üks mitmele (üks-mitmele suhe) või suhte kaudu meister-detail... Sarnaseid seoseid tabelite vahel kasutatakse kõige sagedamini. Sel juhul nimetatakse tabelit, mis sisaldab võõrvõtit üksikasjalik tabel ja kutsutakse esile tabel, mis sisaldab esmast võtit, mis määratleb võimalikud välisvõti väärtused põhilaud.

Seotud tabelite rühma nimetatakse skeem Andmebaas ( andmebaasi skeem). Teavet tabelite, nende veergude (nimed, andmetüüp, väljade pikkus), primaar- ja võõrvõtmete, aga ka muude andmebaasiobjektide kohta nimetatakse metaandmed (metaandmed).

Mis tahes manipuleerimist andmebaasides olevate andmetega, näiteks andmete valimist, sisestamist, kustutamist, värskendamist, metaandmete muutmist või valimist, nimetatakse soovi korral andmebaasi ( päring). Tavaliselt koostatakse päringud keeles, mis võib olla standardne erinevate DBMS -ide jaoks või spetsiifiline konkreetsele DBMS -ile.

Viidatud terviklikkus

Oleme juba eespool öelnud, et mis tahes tabeli esmane võti peab selle tabeli jaoks sisaldama unikaalseid mittetühje väärtusi. See avaldus on üks reeglitest referentsiaalne terviklikkus (referentsiaalne terviklikkus). Mõned (kuid mitte kõik) DBMS -id saavad juhtida primaarvõtmete ainulaadsust. Kui DBMS kontrollib primaarvõtmete ainulaadsust, genereerib DBMS diagnostika sõnumi, mis sisaldab tavaliselt fraasi, kui proovite määrata primaarvõtme väärtusele, mis on juba mõnes teises kirjes esmase võtme rikkumine... Seejärel saab selle teate rakendusele edastada, mille abil lõppkasutaja andmetega manipuleerib.

Kui kaks tabelit on seosega seotud meister-detail, väline võti detail- tabel peaks sisaldama ainult neid väärtusi, mis on esmaste võtmeväärtuste hulgas juba olemas meister- tabelid. Kui DBMS ei kontrolli välisvõti väärtuste õigsust, võime rääkida viite terviklikkuse rikkumisest. Sel juhul kustutame tabelist Kliendid kirje, millega on seotud vähemalt üks kirje detail- kirje tabelis Tellimused, toob see kaasa asjaolu, et tellimuste tabelis on kirjed kellegi tundmatu tehtud tellimuste kohta. Kui DBMS kontrollib võõrvõtmete väärtuste õigsust, siis kui proovite määrata välisvõti väärtust, mis puudub põhitabeli esmaste võtmete väärtustest, või kustutades või muutes põhitabeli kirjeid, viite terviklikkuse rikkumise korral loob DBMS diagnostilise teate, mis tavaliselt sisaldab fraasi välisvõtme rikkumine, mille saab hiljem kasutajarakendusse üle kanda.

Enamik kaasaegseid DBMS -e nagu Microsoft Access 97, Microsoft Access 2000 ja Microsofti SQL Server 7.0 on võimeline täitma viite terviklikkuse reegleid, kui neid on andmebaasis kirjeldatud. Sel eesmärgil kasutavad sellised DBMS -id erinevaid andmebaasiobjekte (arutame neid veidi hiljem). Sel juhul summutatakse kõik katsed viite terviklikkuse reegleid rikkuda, samal ajal genereerides diagnostikateateid või erandeid ( andmebaasi erandid).

Sissejuhatus andmete normaliseerimisse

Andmete koostamise protsess on metaandmete määratlemine vastavalt selle infosüsteemi eesmärkidele, milles tulevast andmebaasi kasutatakse. Üksikasjad domeenianalüüsi tegemise, olemite ja suhete diagrammide loomise kohta ( ERD - olemite ja suhete diagrammid) ja andmemudelid jäävad selle tsükli reguleerimisalast välja. Nende küsimuste huvilised võivad viidata näiteks C.J.Date'i raamatule "Introduction to Database Systems" ("Dialectics", Kiev, 1998).

Selles artiklis käsitleme ainult ühte andmete kujundamise aluspõhimõtet - põhimõtet normaliseerimine.

Normaliseerimine on andmete ümberkorraldamise protsess, kõrvaldades korduvad rühmad ja muud vastuolud andmete salvestamisel, et viia tabelid vormi, mis võimaldab andmete järjepidevat ja õiget redigeerimist.

Normaliseerimisteooria põhineb normaalvormide kontseptsioonil. Tabel on antud tavavormis, kui see vastab teatud nõuetele. Teoreetiliselt on normaalseid vorme viis, kuid praktikas kasutatakse tavaliselt ainult kolme esimest. Pealegi on kaks esimest tavalist vormi sisuliselt vaheetapid andmebaasi teisendamiseks kolmandaks tavavormiks.

Esimene tavaline vorm

Illustreerime normaliseerimisprotsessi näitega, kasutades NorthWindi andmebaasi andmeid. Oletame, et registreerime järgmises tabelis kõik tellitud tooted. Selle tabeli ülesehitus on järgmine (joonis 2).

Et tabel vastaks esimesele normaalsele vormile, peavad kõik selle välja väärtused olema aatomilised ja

kõik rekordid on ainulaadsed. Seetõttu on igasugune relatsioonitabel, sealhulgas tabel Tellitud tooted, määratluse järgi juba esimesel tavalisel kujul.

See tabel sisaldab aga ülearuseid andmeid, näiteks kordub iga tellitud toote puhul kirjes sama klienditeave. Andmete koondamine põhjustab modifikatsioonide kõrvalekaldeid andmetega seotud probleemid mis tekivad kirjete lisamisel, muutmisel või kustutamisel. Näiteks tabeli OrderedProducts andmete muutmisel võivad ilmneda järgmised probleemid:

  • Konkreetse kliendi aadressi saab andmebaasis sisaldada ainult siis, kui klient on tellinud vähemalt ühe toote.
  • Tellitud toote kirje kustutamine kustutab samaaegselt teabe tellimuse enda ja selle esitanud kliendi kohta.
  • Kui jumal hoidku, kui klient on aadressi muutnud, peate uuendama kõik tema tellitud toodete andmed.

Mõnda neist probleemidest saab lahendada andmebaasi teisendamisega teine ​​normaalne vorm.

Teine tavaline vorm

Relatsioonitabel on väidetavalt sees teine ​​normaalne vorm kui see on esimesel tavalisel kujul ja selle võtmeväljadeta täiesti sõltuv kogu primaarvõtmest.

Tabel OrderedProducts on esimesel, kuid mitte teisel tavalisel kujul, kuna väljad CustomerID, Address ja OrderDate sõltuvad ainult väljast OrderID, mis on osa komposiitprimaarvõtmest (OrderID, ProductID).

Esimeselt tavaliselt vormilt teisele üleminekuks peate toimima järgmiselt.

  1. Tehke kindlaks, millistesse osadesse saab esmase võtme jaotada, nii et mõned võtmevabad väljad sõltuvad ühest neist osadest ( need osad ei pea olema ühes veerus!).
  2. Looge iga sellise võtmeosa ja sellest sõltuvate väljade rühma jaoks uus tabel ja teisaldage need sellesse tabelisse. Endise primaarvõtme osast saab siis uue tabeli esmane võti.
  3. Eemaldage algsest tabelist väljad, mis on teisaldatud muudesse tabelitesse kui need, mis muutuvad võõrvõtmeteks.

Näiteks selleks, et viia tabel OrderedProducts teisele tavalisele vormile, teisaldate väljad CustomerID, Address ja OrderDate uude tabelisse (nimetagem seda OrdersInfo), muutes välja OrderID uue tabeli esmaseks võtmeks (joonis 3). .

Selle tulemusel näevad uued tabelid välja sellised. Tabelid, mis on teisel, kuid mitte kolmandal tavalisel kujul, sisaldavad siiski andmete muutmise kõrvalekaldeid. Need on näiteks tabeli OrdersInfo puhul:

  • Konkreetse kliendi aadressi saab andmebaasis sisaldada alles siis, kui klient on tellinud vähemalt ühe toote.
  • Tellimuse kirje kustutamine tabelis OrdersInfo kustutab kliendi enda kirje.
  • Kui klient on aadressi muutnud, tuleb uuendada mitmeid kirjeid (kuigi reeglina on neid vähem kui eelmisel juhul).

Nende kõrvalekallete kõrvaldamiseks minge lehele kolmas normaalne vorm.

Kolmas normaalne vorm

Relatsioonitabel on väidetavalt sees kolmas normaalne vorm kui see on teisel tavavormil ja kõik selle võtmevabad väljad sõltuvad ainult primaarvõtmest.

Tabel OrderDetails on juba kolmandal tavalisel kujul. Väli, mis ei ole võtmetähtsusega Kogus, sõltub täielikult kombineeritud primaarvõtmest (tellimuse ID, toote ID). Tabel OrdersInfo ei ole aga kolmandal tavalisel kujul, kuna see sisaldab võtmeväliste väljade vahelist sõltuvust (seda nimetatakse mööduv sõltuvus- mööduv sõltuvus) - väli Aadress sõltub väljast CustomerID.

Teiselt tavavormilt kolmandale liikumiseks peate järgima neid samme:

  • Määrake kõik väljad (või väljarühmad), millest teised väljad sõltuvad.
  • Looge iga sellise välja (või väljade rühma) ja sellest sõltuva väljade rühma jaoks uus tabel ja teisaldage need sellesse tabelisse. Väljast (või väljade rühmast), millest sõltuvad kõik muud teisaldatud väljad, saab uue tabeli esmane võti.
  • Eemaldage teisaldatud väljad algsest tabelist, jättes ainult need, mis muutuvad võõrvõtmeteks.

Tabeli OrdersInfo teisendamiseks kolmandaks tavavormiks looge uus tabel Kliendid ja teisaldage sinna väljad CustomerID ja Aadress. Kustutame algsest tabelist välja Aadress ja jätame välja KliendiID - nüüd on see võõrvõti (joonis 4).

Niisiis, pärast algse tabeli teisendamist kolmandaks tavavormiks on kolm tabelit - kliendid, tellimused ja tellimuse üksikasjad.

Normaliseerimise eelised

Normaliseerimine eemaldab andmete koondamise, mis võimaldab vähendada salvestatud andmete hulka ja vabaneda ülalkirjeldatud kõrvalekalletest. Näiteks pärast ülalkirjeldatud andmebaasi teisendamist kolmandaks tavavormiks ilmnevad järgmised parandused:

  • Kliendiaadressi teavet saab andmebaasi salvestada, isegi kui see on ainult potentsiaalne klient kes pole veel ühtegi tellimust esitanud.
  • Saate kustutada tellitud tooteteabe, kartmata klientide ja tellimuste andmete kustutamist.

Kliendi aadressi või tellimuse registreerimise kuupäeva muutmine nõuab nüüd ainult ühe kirje muutmist.

Kuidas andmebaase kujundatakse

Tavaliselt sisaldavad kaasaegsed DBMS -id tööriistu, mis võimaldavad luua tabeleid ja võtmeid. Samuti on olemas utiliidid, mis tarnitakse DBMS -ist eraldi (ja teenindavad isegi mitut erinevat DBMS -i korraga), mis võimaldavad teil luua tabeleid, võtmeid ja linke.

Teine võimalus tabelite, võtmete ja seoste loomiseks andmebaasis on nn Data Definition Language (DDL) skripti kirjutamine; sellest räägime veidi hiljem.

Lõpuks on veel üks viis, mis muutub üha populaarsemaks, spetsiaalsete tööriistade kasutamine, mida nimetatakse CASE-tööriistadeks (CASE tähistab arvutipõhist süsteemitehnikat). CASE-tööriistu on mitut tüüpi, kuid andmebaaside loomiseks kasutatakse kõige sagedamini olemite-suhete diagramme (E / R diagramme). Nende vahendite abil saab nn loogiline andmemudel, mis kirjeldab selles registreeritavaid fakte ja objekte (sellistes mudelites nimetatakse tabelite prototüüpe olemiteks ja välju nende atribuutideks. Pärast olemite vaheliste suhete loomist, atribuutide määratlemist ja normaliseerimise sooritamist toimub nn. füüsiline andmebaasipõhine andmemudel, mis määratleb kõik tabelid, väljad ja muud andmebaasi objektid. Pärast seda saate selle loomiseks genereerida kas andmebaasi ise või DDL -skripti.

Hetkel kõige populaarsemate CASE tööriistade loend.

Tabelid ja väljad

Tabeleid toetavad kõik relatsioonilised DBMS -id ja andmeid saab nende väljadele salvestada erinevad tüübid... Kõige tavalisemad andmetüübid.

Indeksid

Varem rääkisime esmase ja välisvõtme rollist. Enamikus relatsioonilistes DBMSides rakendatakse võtmeid, kasutades objekte, mida nimetatakse indeksiteks, mida saab määratleda kirjenumbrite loendina, mis näitab, millises järjekorras need avaldada.

Me juba teame, et relatsioonitabelite kirjed on järjestamata. Sellest hoolimata on igal kirjel teatud ajahetkel andmebaasi failis täpselt määratletud füüsiline asukoht, kuigi see võib muutuda andmete redigeerimise ajal või DBMS-i enda "sisemise tegevuse" tagajärjel.

Oletame, et mingil ajahetkel salvestati tabelis Kliendid olevad kirjed selles järjekorras.

Oletame, et tahame, et need andmed oleksid tellitud väljal CustomerID. Tehnilisi üksikasju välja jättes võime öelda, et selle välja indeks on kirjete numbrite jada, mille kohaselt neid tuleks kuvada, see tähendab:

1,6,4,2,5,3

Kui soovime kirjeid aadressivälja järgi järjestada, on kirjete numbrite jada erinev:

5,4,1,6,2,3

Indeksite salvestamine nõuab oluliselt vähem ruumi kui tabeli enda sorteeritud versioonide salvestamine.

Kui meil on vaja leida andmeid klientide kohta, kelle kliendi ID algab tähemärkidega „BO”, saame indeksite abil leida nende kirjete asukoha (antud juhul 2 ja 5 (ilmselgelt indeksis lähevad nende kirjete numbrid rida) ja seejärel lugege teist ja viiendat kirjet, selle asemel, et kogu tabel läbi vaadata, seega lühendab indeksite kasutamine andmete hankimise aega.

Oleme juba rääkinud asjaolust, et kirjete füüsiline asukoht võib muutuda kasutajate andmete redigeerimise protsessis, samuti andmebaasifailidega manipuleerimise tulemusel, mille on teinud DBMS ise (näiteks andmete tihendamine, prügi kogumine) , jne.). Kui samal ajal on indeksis vastavaid muudatusi, nimetatakse seda toetab ja selliseid indekseid kasutatakse enamikes kaasaegsetes DBMSides. Selliste indeksite rakendamine toob kaasa asjaolu, et iga tabeli andmete muutmine toob kaasa sellega seotud indeksite muutmise ja see pikendab DBMS -i selliste toimingute tegemiseks kuluvat aega. Seetõttu peaksite sellise DBMS -i kasutamisel looma ainult need indeksid, mida tõesti vaja on, ja juhinduma sellest, milliseid päringuid kõige sagedamini ette tuleb.

Piirangud ja reeglid

Enamik kaasaegseid serveripoolseid DBMS-e sisaldab spetsiaalseid objekte, mida nimetatakse piirangud(piirangud) või reeglid(reeglid). Need objektid sisaldavad teavet väljade võimalikele väärtustele kehtestatud piirangute kohta. Näiteks sellist objekti kasutades saate määrata antud väljale maksimaalse või minimaalse väärtuse ning pärast seda ei luba DBVS seda tingimust mitte täitvat kirjet andmebaasi salvestada.

Lisaks andmete muutmisvahemiku seadistamisega seotud piirangutele on ka viitepiiranguid (näiteks klientide ja tellimuste tabelite vahelise peamise detaili suhet saab rakendada piiranguna, mis nõuab välja CustomerId väärtuse ( välisvõti) tabelis Tellimused on üks juba olemasolevatest tabeli Kliendid välja CustomerId väärtustest.

Pange tähele, et mitte kõik DBMS -id ei toeta piiranguid. Sellisel juhul saate reeglite sarnase funktsionaalsuse rakendamiseks kasutada teisi objekte (näiteks käivitajaid) või salvestada need reeglid selle andmebaasiga töötavatesse kliendirakendustesse.

Esindus

Peaaegu kõik relatsioonilised DBMS -id toetavad vaateid. See objekt on virtuaalne tabel, mis pakub andmeid ühest või mitmest reaalsest tabelist. Tegelikkuses ei sisalda see mingeid andmeid, vaid kirjeldab ainult nende allikat.

Sageli luuakse sellised objektid keeruliste päringute salvestamiseks andmebaasidesse. Tegelikult on vaade salvestatud taotlus.

Vaadete loomine enamikus kaasaegsetes DBMSides toimub spetsiaalsete visuaalsete vahenditega, mis võimaldavad ekraanil kuvada vajalikke tabeleid, luua nende vahel seoseid, valida kuvatavaid välju, kehtestada kirjetele piiranguid jne.

Sageli kasutatakse neid objekte andmete turvalisuse tagamiseks, näiteks lubades nendega andmeid vaadata ilma otsest juurdepääsu tabelitele andmata. Lisaks võivad mõned vaateobjektid tagastada erinevaid andmeid, sõltuvalt näiteks kasutaja nimest, mis võimaldab tal saada ainult huvipakkuvaid andmeid.

Päästikud ja salvestatud protseduurid

Käivitatava koodi salvestamiseks kasutatakse käivitajaid ja salvestatud protseduure, mida toetab enamus kaasaegseid serveripoolseid DBMS -e.

Salvestatud protseduur on eriline protseduur, mida teostab andmebaasiserver. Salvestatud protseduurid on kirjutatud protseduurikeeles, mis sõltub konkreetsest DBMS -ist. Nad saavad üksteisele helistada, lugeda ja muuta tabelite andmeid ning neid saab helistada kliendirakendusest, mis töötab andmebaasiga.

Tavaliselt kasutatakse salvestatud protseduure tavaliste ülesannete täitmisel (näiteks bilansi tasakaalustamine). Neil võib olla argumente, tagastusväärtusi, veakoode ja mõnikord ridade ja veergude komplekte (mõnikord nimetatakse neid andmekogumiteks). Viimast tüüpi protseduure ei toeta siiski kõik DBMS -id.

Päästikud sisaldavad ka käivitatavat koodi, kuid erinevalt protseduuridest ei saa neid kliendirakendusest ega salvestatud protseduurist välja kutsuda. Päästik on alati seotud konkreetse tabeliga ja käivitatakse siis, kui selle tabeli redigeerimise ajal toimub sündmus, millega see on seotud (näiteks kirje sisestamine, kustutamine või värskendamine).

Enamikus DBMS -ides, mis toetavad käivitajaid, saate määratleda mitu käivitajat, mida sama sündmuse toimumisel täita, ja määrata täitmise järjekord.

Esmaste võtmete genereerimise objektid

Väga sageli genereerib esmased võtmed DBMS ise. See on mugavam kui nende genereerimine kliendirakenduses, kuna mitme kasutaja töö puhul on võtmete genereerimine DBMS-i abil ainus viis topeltvõtmete vältimiseks ja nende järjepidevate väärtuste saamiseks.

Erinevad DBMS -id kasutavad võtmete genereerimiseks erinevaid objekte. Mõni neist objektidest salvestab täisarvu ja reeglid, mille alusel genereeritakse järgmine väärtus, tavaliselt päästikute abil. Selliseid objekte toetatakse näiteks Oracle'is (antud juhul nimetatakse neid järjestusteks) ja IB andmebaasis (antud juhul nimetatakse neid generaatoriteks).

Mõned DBMS -id toetavad primaarvõtmete eritüüpi välju. Kirjete lisamisel täidetakse sellised väljad automaatselt järjestikuste väärtustega (tavaliselt täisarvudega). Microsoft Accessi ja Microsoft SQL Serveri puhul nimetatakse selliseid välju identiteediväljadeks ja Corel Paradoxi puhul automaatse lisamise väljadeks.

Kasutajad ja rollid

Andmetele volitamata juurdepääsu vältimine on suur probleem, millega tegeletakse erinevaid viise... Lihtsaim on kas kogu tabeli või mõne selle välja paroolikaitse (seda mehhanismi toetab näiteks Corel Paradox).

Praegu on populaarsem teine ​​viis andmete kaitsmiseks - kasutajate (kasutajate) nimekirja koostamine koos nimede (kasutajanimed) ja paroolidega (paroolid). Sel juhul kuulub iga andmebaasi objekt kindlale kasutajale ja see kasutaja annab teistele kasutajatele loa selle objekti andmete lugemiseks või muutmiseks või objekti enda muutmiseks. Seda meetodit kasutatakse kõikides serverites ja mõnes töölaua DBMS -is (näiteks Microsoft Access).

Mõned DBMS-id, peamiselt serveripoolsed, ei toeta mitte ainult kasutajate loendit, vaid ka rolle. Roll on privileegide kogum. Kui konkreetne kasutaja saab ühe või mitu rolli ja koos nendega kõik selle rolli jaoks määratud õigused.

Andmebaasipäringud

Andmete muutmine ja valimine, metaandmete muutmine ja mõned muud toimingud viiakse läbi päringute abil. Enamik kaasaegseid DBMS -e (ja mõned rakenduste arendamise tööriistad) sisaldavad tööriistu selliste päringute genereerimiseks.

Üks võimalus andmetega manipuleerimiseks on "näitepäringud" (QBE). QBE on tööriist tabelite visuaalseks linkimiseks ja päringutulemuses kuvatavate väljade valimiseks.

Enamikus DBMS -ides (välja arvatud mõned töölauad) on QBE abil päringu visuaalse ülesehitamise tulemuseks päringuteksti genereerimine spetsiaalse päringukeele SQL (Structured Query Language) abil. Saate oma päringu kirjutada ka otse SQL -is.

Kursorid

Päringu tulemuseks on üsna sageli ridade ja veergude komplekt (andmekogum). Erinevalt relatsioonitabelist on selline ridade komplekt järjestatud ja nende järjekorra määrab algne päring (ja mõnikord ka indeksite olemasolu). Seetõttu saame määrata sellise komplekti praeguse rea ja sellele osuti, mida nimetatakse kursoriks (kursoriks).

Enamik kaasaegseid DBMS-e toetab niinimetatud kahesuunalisi kursoreid, mis võimaldavad teil saadud andmestiku kaudu nii edasi kui tagasi liikuda. Kuid mõned DBMS -id toetavad ainult ühesuunalisi kursoreid, mis liiguvad edasi ainult andmestiku kaudu.

SQL keel

Struktureeritud päringukeel (SQL) on mitteprotseduuriline keel, mida kasutatakse andmebaasipäringute koostamiseks enamikes kaasaegsetes DBMS-is ja mis on praegu valdkonna standard.

Keele mitteprotseduuriline olemus tähendab, et saate selles täpsustada, mida andmebaasiga teha tuleb, kuid te ei saa kirjeldada selle protsessi algoritmi. Kõik SQL -päringute töötlemise algoritmid on loodud DBMS -i enda poolt ega sõltu kasutajast. SQL -keel koosneb operaatorite komplektist, mille võib jagada mitmesse kategooriasse:

  • Andmete määratluskeel (DDL) on andmete määratluskeel, mis võimaldab teil andmebaasides objekte luua, kustutada ja muuta
  • Andmete manipuleerimise keel (DML) on andmehalduskeel, mis võimaldab teil olemasolevate andmebaasiobjektide andmeid muuta, lisada ja kustutada
  • Andmekontrolli keeled (DCL) - keel, mida kasutatakse kasutajaõiguste haldamiseks
  • Transaction Control Language (TCL) - keel operaatorirühmade tehtud muudatuste haldamiseks
  • Kursori juhtimiskeel (CCL) - operaatorid kursori määratlemiseks, SQL -avalduste ettevalmistamiseks täitmiseks ja mõned muud toimingud.

Lisateavet SQL keele kohta leiate selle sarja ühest järgmisest artiklist.

Kasutaja määratud funktsioonid

Mõned DBMS-id lubavad kasutada kasutaja määratud funktsioone (UDF-User-Defined Functions). Need funktsioonid salvestatakse tavaliselt välistesse teekidesse ja need tuleb andmebaasi registreerida, pärast mida saab neid päringutes, käivitites ja salvestatud protseduurides kasutada.

Kuna kasutaja määratud funktsioonid on raamatukogudes, saab neid luua mis tahes arendustööriista abil, mis võimaldab teil luua teegid selle platvormi jaoks, millel antud DBMS töötab.

Tehingud

Tehing on andmeoperatsioonide rühm, mis tehakse kas kõik koos või tühistatakse koos.

Tehingu lõpuleviimine (sidumine) tähendab, et kõik tehingusse kaasatud toimingud on edukalt lõpule viidud ja nende töö tulemus on andmebaasi salvestatud.

Tehingu tagasipööramine tähendab seda, et kõik juba tehtud toimingud, mis on tehingu osa, pööratakse tagasi ja kõik andmebaasi objektid, mida need toimingud mõjutavad, tagastatakse nende algsesse olekusse. Tehingute tagasipööramise võimaluse rakendamiseks toetavad paljud DBMS -id logifailidesse kirjutamist, võimaldades teil tagasipööramise ajal algseid andmeid taastada.

Tehing võib koosneda mitmest pesastatud tehingust.

Mõned DBMS-id toetavad kahefaasilist sidumist-protsessi, mis võimaldab tehinguid sooritada mitme andmebaasiga, mis kuuluvad samasse DBMS-i.

Hajutatud tehingute (st erinevate DBMSide hallatavate andmebaaside kaudu toimuvate tehingute) toetamiseks on olemas erilised vahendid nimetatakse tehingute jälgimiseks.

Järeldus

Selles artiklis arutasime relatsioonilise DBMS -i loomise põhimõisteid, andmete kujundamise aluspõhimõtteid ja rääkisime ka sellest, milliseid objekte saab andmebaasides luua.

Järgmises artiklis tutvustame oma lugejatele populaarsemaid töölaua DBMS -e: dBase, Paradox, Access, Visual FoxPro, Works ja arutame nende peamisi funktsioone.

Arvuti vajutage 3 "2000

Avaleht> Loeng

DB loeng 2. peatükk SUHTLIKUD ANDMEBAASID 2.1. Mõisted ja määratlused Relatsioonandmebaaside väljatöötamine algas 1960. aastate lõpus, kui ilmusid esimesed tööd, milles arutati spetsialistile tuttavate vormistatud andmete esitamise meetodite kasutamise võimalusi tabelite kujul. Mõned eksperdid nimetasid seda teabe esitamise viisi otsustabeliteks, teised tabelialgoritmideks. Relatsioonandmebaaside teoreetikud nimetasid teabe esitamise tabeliviisi dataloogilisteks mudeliteks. Relatsioonandmebaaside teooria rajajaks peetakse IBMi töötajat dr. EF Codd, kes avaldas 6. juunil 1970 artikli "Suhteliste andmepankade andmete relatsioonimudel" "A Relational Model of Data for Suured jagatud andmepangad ". Selles artiklis kasutati esimest korda mõistet "relatsiooniandmete mudel", mis pani aluse relatsiooniandmebaasidele. Suhete andmebaasi teooria töötati välja 1970ndatel. USA -s dr E. F. Codd, tuginedes hulkade teooria matemaatilisele aparaadile. Ta tõestas, et mis tahes andmekogumit saab esitada kahemõõtmeliste eritabelite kujul, mida matemaatikas tuntakse seostena. Ingliskeelsest sõnast "relatsioon" "relatsioon") ja sealt tuli nimi "relatsiooniandmete mudel". Praegu on andmebaaside (DB) kujundamise teoreetiline alus relatsioonalgebra matemaatiline aparaat (vt punkt 1.2). Seega on relatsiooniline andmebaas informatsioon (andmed) objektide kohta, mis on esitatud kahemõõtmeliste massiivide - tabelite kujul, mida ühendavad teatud lingid. Andmebaas võib koosneda ka ühest tabelist. Enne kui jätkame relatsiooniliste andmebaaside uurimist, kaaluge teoorias ja praktikas kasutatavaid termineid ja definitsioone. Andmebaasi tabel- kahemõõtmeline massiiv mis sisaldab teavet ühe klassi objektide kohta. Relatsioonalgebra teoorias nimetatakse kahemõõtmelist massiivi (tabelit) suhtumine. Tabel koosneb järgmistest elementidest: väli, lahter, kirje (joonis 2.1). Väli sisaldab ühe andmebaasi objekte iseloomustava atribuudi väärtusi. Tabeli väljade arv vastab andmebaasi objekte iseloomustavate märkide arvule. 22 Kamber sisaldab vastava välja spetsiifilist väärtust (ühe objekti atribuut). Salvestamine- laua rida. See sisaldab kõigi märkide väärtusi, mis iseloomustavad ühte objekti. Kirjete (ridade) arv vastab objektide arvule, mille andmed on tabelis. Andmebaasiteoorias mõiste salvestamine vastab kontseptsioonile cor-tezh- atribuutide jada, mis on omavahel seotud suhtega AND (JA). Graafikuteoorias korteež tähendab suunatud graafi - puu - lihtsat haru. Tabel 2.1 näitab relatsiooniliste andmebaaside arendamise teoorias ja praktikas kasutatavaid termineid. Üks olulisi mõisteid, mida on vaja relatsiooniandmebaaside optimaalse struktuuri loomiseks, on võtme ehk võtmevälja mõiste. Võti kaalutakse välja, mille väärtused määravad üheselt kõigi teiste tabeli väljade väärtused. Näiteks väli "Passi number" või "Maksumaksja identifitseerimisnumber (TIN)" määratleb unikaalselt iga üksikisiku tunnused (personaliosakondade või ettevõtte raamatupidamisosakonna vastavate andmebaasitabelite koostamisel).
23

Tabeli võti võib olla mitte üks, vaid mitu välja. Sel juhul võib väljade komplekt olla tabeli võimalikuks võtmeks ainult siis, kui on täidetud kaks ajast sõltumatut tingimust: ainulaadsus ja minimaalsus. Iga välja, mis ei kuulu esmase võtme hulka, nimetatakse tabelis mittevõtmeväljaks.

Ainulaadsus võti tähendab, et andmebaasi tabel ei saa igal ajal sisaldada kahte erinevat kirjet, millel on samad võtmevälja väärtused. Ainulaadsuse tingimuse täitmine on kohustuslik. Seisukord minimaalsus võtmeväljad tähendab, et ainult valitud väljade väärtuste kombinatsioon vastab andmebaasitabeli kirjete ainulaadsuse nõuetele. See tähendab ka seda, et ühtegi võtmes sisalduvat välja ei saa unikaalsust rikkumata sellest välja jätta. Mitmest väljast koosneva andmebaasi tabeli võtme moodustamisel on vaja juhinduda järgmistest sätetest: te ei tohiks võtmesse lisada tabelivälju, mille väärtused ise tuvastavad tabelis olevad kirjed ainulaadselt. Näiteks ei tohiks te luua võtit, mis sisaldab samaaegselt välju "passi number" ja "maksumaksja identifitseerimisnumber", kuna kõik need atribuudid suudavad tabelis kirjeid kordumatult tuvastada; võtmesse ei saa lisada mitteunikaalset välja, see tähendab välja, mille väärtusi saab tabelis korrata. Igal tabelil peab olema vähemalt üks võimalik võti, mis valitakse kui esmane võti. Kui tabelis on väljad, mille väärtused määratlevad kirjed ainulaadselt, võib neid välju võtta kui alternatiivsed võtmed. Näiteks kui valite esmaseks võtmeks maksumaksja identifitseerimisnumbri, on passi number alternatiivne võti. 2.2. Relatsioonandmebaaside tabelite normaliseerimine Relatsioonandmebaas on üksteisega seotud tabelite kogum. Tabelite arv ühes failis või ühes andmebaasis sõltub paljudest teguritest, millest peamised on: andmebaasi kasutajate koosseis, teabe terviklikkuse tagamine (eriti oluline mitme kasutaja puhul infosüsteemid ah), tagades minimaalse nõutava mälu ja minimaalse töötlemisaja. 24

Nende teguritega arvestamine relatsiooniliste andmebaaside kujundamisel viiakse läbi tabelite normaliseerimise ja nende vaheliste seoste loomise meetoditega.

Tabelite normaliseerimine on viis ühe andmebaasi tabeli jagamiseks mitmeks tabeliks, mis üldiselt vastavad ülaltoodud nõuetele. Tabeli normaliseerimine on järjestikune muutus tabeli struktuuris, kuni see vastab viimase normaliseerimisvormi nõuetele. Kokku on kuus normaliseerimisvormi:
    esimene normaalne vorm (First Normal Form - 1NF); teine ​​normaalvorm (teine ​​normaalne vorm - 2NF); kolmas normaalvorm (kolmas normaalvorm - ЗNF); tavavorm Boyes - Codd (Brice - Codd Normal Form -BCNF); neljas normaalne vorm (Foirth Tavaline vorm - 4NF); viies normaalne vorm või tavaline projektsioonivorm - ühendused (viies normaalvorm - 5NF või PJ / NF ).
Tavaliste vormide kirjeldamisel kasutatakse järgmisi mõisteid: "funktsionaalne sõltuvus väljade vahel"; "Täielik funktsionaalne sõltuvus väljade vahel"; "Mitme väärtusega funktsionaalne sõltuvus valdkondade vahel"; "Transitiivne funktsionaalne sõltuvus valdkondade vahel"; "Vastastikune sõltumatus valdkondade vahel". Funktsionaalne sõltuvus väljade A ja B vahel nimetatakse suhet, milles iga A väärtus igal ajahetkel vastab ühele B väärtusele kõikidest võimalikest. Funktsionaalse suhte näide on maksumaksja identifitseerimisnumbri ja passi numbri vaheline seos. Täielik funktsionaalne sõltuvus liitvälja A ja välja B vahel nimetatakse sõltuvuseks, milles väli B sõltub funktsionaalselt väljast A ja ei sõltu funktsionaalselt ühegi välja A alamhulgast. Mitmeväärtuslik funktsionaalne sõltuvus määratakse väljade vahel järgmisel viisil... Väli A määratleb välja B mitmeti, kui välja A iga väärtuse jaoks on väljale B vastavate väärtuste "täpselt määratletud komplekt". Näiteks kui arvestame kooli-Le õpilase edenemise tabelit, mis sisaldab "väljad (väli A) ja" Skoor "(väli B), siis on väljal B lubatud väärtuste" täpselt määratletud komplekt ": 1, 2, 3, 4, 5, see tähendab, et välja "Subject" iga väärtuse jaoks on väljale "Score" mitme väärtusega "täpselt määratletud" väärtuste kogum. Transitiivne funktsionaalne sõltuvus väljade A ja C vahel On olemas, kui väli C funktsionaalselt sõltub 25 väljast B ja väli B funktsionaalselt sõltub väljast A; sel juhul puudub välja A funktsionaalne sõltuvus väljast B. Vastastikune sõltumatus valdkondade vahel on määratletud järgmiselt. Mitmed valdkonnad on teineteisest sõltumatud, kui ükski neist ei ole funktsionaalselt teisest sõltuv. Esimene tavaline vorm. Tabel on esimesel tavalisel kujul siis ja ainult siis, kui ükski välja ei sisalda rohkem kui ühte väärtust ja ükski võtmeväli ei ole tühi. Esimene normaalne vorm on relatsiooniandmete mudeli alus. Relatsioonandmebaasi mis tahes tabel on automaatselt esimesel tavalisel kujul, vastasel juhul pole see lihtsalt määratluse järgi võimalik. Selline tabel ei tohiks sisaldada välju (omadusi), mida saaks jagada mitmeks väljaks (tunnuseks). Normaaleerimata on reeglina tabelid, mis ei olnud algselt ette nähtud neis sisalduva teabe arvutitöötluseks. Näiteks tabelis. 2.2 näitab tabeli fragmenti teatmeteosest "Universaalsed metallilõikamismasinad", mille on välja andnud Metalli lõikamise tööpinkide eksperimentaalne uurimisinstituut (ENIMS). Seda tabelit ei normaliseerita järgmistel põhjustel. 1. See sisaldab ridu, mille ühes lahtris on mitu ühe välja väärtust: "Töötlemise suurim läbimõõt, mm" ja "Spindli pöörlemissagedus, p / min". 2. Üks väli - " mõõtmed(pikkus x laius x kõrgus), mm "võib jagada kolmeks väljaks:" Pikkus, mm "," Laius, mm "Ja" Kõrgus, mm ". Sellise jaotuse otstarbekust saab põhjendada vajadusega teha hilisemaid pindalade või hõivatud mahtude arvutusi. Algne tabel tuleks teisendada esimeseks tavaliseks vormiks. Selleks on vaja: jagada väljad "Maksimaalne töötlemisläbimõõt, mm" ja "Spindli pöörlemissagedus, p / min" mitmeks väljaks vastavalt ühes lahtris sisalduvate väärtuste arvule;
26

Väli "Üldmõõtmed (pikkus x laius x kõrgus), mm", jagatud kolmeks väljaks: "Pikkus, mm", "Laius, mm", "Kõrgus, mm". Selle tabeli võtmeväli võib olla väli „Masinamudel” või „Ei. 2.3. Võtame teise näite. Joonisel fig. 2.2 näitab testi tulemuste lehe fragmenti, mis, nagu eelmises näites, polnud algselt mõeldud arvutitöötluseks. Oletame, et tahame luua andmebaasi testi ja eksami tulemuste automatiseeritud töötlemiseks vastavalt
27

testi ja eksamilehe sisuga. Selleks muudame vormi sisu andmebaasi tabeliteks. Lähtudes vajadusest täita väljade vahelise funktsionaalse sõltuvuse tingimusi, on vaja moodustada vähemalt kaks tabelit (joonis 2.3) (iga tabeli võtmeväljad on paksus kirjas). Esimene tabel sisaldab konkreetse aine iga õpilase testi (eksami) sooritamise tulemusi. Teine tabel sisaldab konkreetse õppeaine konkreetse õpilasrühma testi (eksami) sooritamise lõpptulemusi. Esimeses tabelis on võtmeks väli "Õpilase täisnimi" ja teises tabelis väli "Distsipliin". Tabelid peavad olema lingitud väljadega "Distsipliin" JA "Grupikood".

Esitatud tabelistruktuurid vastavad täielikult esimese normaalvormi nõuetele, kuid neid iseloomustavad järgmised puudused: uute andmete lisamine tabelitesse nõuab kõigi väljade väärtuste sisestamist; iga tabeli reale on vaja sisestada väljade "Distsipliin", "Õpetaja täisnimi", "Rühma kood" korduvad väärtused. Järelikult on sellise tabelite koosseisu ja nende ülesehituse korral selge teabe koondamine, mis muidugi nõuab lisamälu. Loetletud puuduste vältimiseks on vaja tabelid viia teisele või kolmandale tavalisele vormile. Teine tavaline vorm. Tabel on teises tavavormis, kui see vastab esimese tavavormi nõuetele ja kõik selle esmase võtme hulka mittekuuluvad väljad sõltuvad täielikult primaarvõtmest. 28

Kui tabelil on lihtne esmane võti, mis koosneb ainult ühest väljast, siis on see automaatselt teisel tavavormil.

Kui esmane võti on liit, on tabel valikuliselt teises tavavormis. Seejärel tuleb see jagada kaheks või enamaks tabeliks selliselt, et esmane võti tuvastaks mis tahes välja väärtuse unikaalselt. Kui tabelis on vähemalt üks väli, mis ei sõltu primaarvõtmest, tuleb primaarvõtmele lisada täiendavad veerud. Kui selliseid veerge pole, peate lisama uue veeru. Nende tingimuste põhjal, mis määravad teise normaalkuju, saab koostatud tabelite omaduste kohta teha järgmised järeldused (vt joonis 2.3). Esimeses tabelis puudub otsene seos võtmevaldkonna ja välja "Õpetaja täisnimi" vahel, kuna sama aine soorituse või eksami saavad sooritada erinevad õpetajad. Tabelis on täielik funktsionaalne sõltuvus ainult kõigi teiste väljade ja võtmevälja "Distsipliin" vahel. Samamoodi ei ole teises tabelis otsest seost võtmevälja ja välja "Õpetaja täisnimi" vahel. Andmebaasi optimeerimiseks, eelkõige vajaliku mälumahu vähendamiseks seoses vajadusega korrata igas kirjes väljade "Distsipliin" ja "Õpetaja nimi" väärtusi, on vaja muuta andmebaasi struktuuri - teisendada algsed tabelid teiseks normaalvormiks. Muudetud andmebaasi struktuuri tabelite koostis on näidatud joonisel fig. 2.4. Teisendatud andmebaasi struktuur koosneb kuuest tabelist, millest kaks on omavahel ühendatud (iga tabeli võtmeväljad on paksus kirjas). Kõik tabelid vastavad teise normaalvormi nõuetele. Viiendal ja kuuendal tabelil on väljadel topeltväärtused, kuid arvestades, et need väärtused on tekstiandmete asemel täisarvud, on teabe salvestamiseks vajaliku mälu kogumaht palju väiksem kui algsetes tabelites (vt joonis 2.1). ). Lisaks annab andmebaasi uus struktuur võimaluse täita tabeleid erinevate spetsialistide poolt (haldusteenuste osakonnad). Andmebaasitabelite edasine optimeerimine taandub nende viimisele kolmandale tavavormile. Kolmas normaalne vorm. Tabel on kolmandas tavavormis, kui see vastab teise tavavormi määratlusele ja ükski selle võtmeväline väli ei sõltu funktsionaalselt ühestki teisest võtmeväljast väljast. 29

Samuti võite öelda, et tabel on kolmandal normaalkujul, kui see on teisel tavavormil ja iga mittevõtmeväli ei sõltu ajutiselt primaarvõtmest. Kolmas tavalise vormi nõue on see, et kõik võtmevabad väljad sõltuvad ainult primaarvõtmest, mitte üksteisest. Nende nõuete kohaselt kuuluvad andmebaasi tabelite osana (vt joonis 2.3) esimene, teine, kolmas ja neljas tabel kolmandasse normaalkuju. Viienda ja kuuenda tabeli viimiseks kolmandasse tavavormi loome uue tabeli, mis sisaldab teavet ainete koosseisu kohta, mille jaoks eksameid või kontrolltöid õpilaste rühmades korraldatakse. Võtmena loome välja “Loendur”, mis määrab tabelis kirje arvu, kuna iga kirje peab olema kordumatu. kolmkümmend

Selle tulemusel saame uue andmebaasi struktuuri, mis on näidatud joonisel fig. 2.5 (iga tabeli võtmeväljad on paksus kirjas). See struktuur sisaldab seitset tabelit, mis vastavad kolmanda normaalvormi nõuetele.

Boyce'i tavaline vorm on Codd. Tabel on tavalises Boyce-Codd vormis ainult siis, kui selle väljade vaheline funktsionaalne sõltuvus on taandatud täielikuks funktsionaalseks sõltuvuseks võimalikust võtmest. Vastavalt seda määratlust andmebaasi struktuuris (vt joonis 2.4) vastavad kõik tabelid Boyes-Codd tavavormi nõuetele. Andmebaasitabelite edasine optimeerimine peaks taanduma tabelite täielikuks lagunemiseks. Laua täielik lagunemine nimetatakse sellist suvalise arvu oma projektsioonide kogumit, mille seos langeb täielikult kokku tabeli sisuga. Projektsioon on tabeli koopia, mis ei sisalda ühte või mitut uue tabeli veergu. Neljas normaalne vorm. Neljas normaalne vorm on viienda normaalvormi erijuhtum, kui täielik lagunemine peab olema kahe projektsiooni liit.
31

On väga raske leida tabelit, mis oleks neljandal normaalkujul, kuid ei vastaks viienda normaalvormi määratlusele.

Viies normaalne vorm. Tabel on viiendal normaalkujul siis ja ainult siis, kui kõik projektsioonid sisaldavad võimalikku võtit igas selle deko-asendis. Tabel, millel puudub täielik lagunemine, on samuti viiendal normaalkujul. Praktikas jõuab andmebaasi tabelite optimeerimine kolmandale normaalvormile. Tabelite taandamine neljandaks ja viiendaks normaalvormiks on meie arvates puhtalt teoreetiline huvi. Praktikas saab selle probleemi lahendada päringute väljatöötamisega uue tabeli loomiseks. 2.3. Tabelitevaheliste suhete kujundamine Andmebaasi esialgsete tabelite normaliseerimise protsess võimaldab teil luua infosüsteemi optimaalse struktuuri - arendada välja andmebaas, mis nõuab kõige vähem mäluressursse ja annab seetõttu lühima aja teabe saamiseks. Samas eeldab ühe allikatabeli jagamine mitmeks infosüsteemide projekteerimisel ühe olulisema tingimuse täitmist - teabe terviklikkuse tagamist andmebaasi toimimise ajal. Ülaltoodud näites algsete tabelite normaliseerimise kohta (vt joonis 2.3) saime kahest tabelist lõpuks seitse tabelit, mis on vähendatud kolmandaks ja neljandaks normaalvormiks. Nagu näitab praktika, on tegelikus tootmises ja äris andmebaasid mitme kasutaja süsteemid. See kehtib nii eraldi tabelites andmete loomise ja säilitamise kui ka teabe kasutamise kohta otsuste tegemisel. Eespool käsitletud näite puhul toimivad ülikooli või kolledži tõeliselt toimivas haridusprotsesside juhtimissüsteemis õpperühmade esialgse moodustamise vastuvõtukomisjonid, kes taotlejaid registreerivad sisseastumiseksamite tulemuste põhjal. Edasine teabe säilitamine üliõpilaste koosseisude kohta ülikoolides antakse dekanaatidele ja kolledžites haridusosakondadele või asjakohastele struktuuridele. Akadeemiliste erialade koosseisu rühmades määravad teised teenistused või spetsialistid. Teave õppejõudude kohta moodustatakse personaliosakondades. Testi- ja eksamisessioonide tulemused on vajalikud dekanaadi ja osakondade juhatajatele, sealhulgas otsuste tegemiseks stipendiumide andmise kohta 32 edukale üliõpilasele või ebaõnnestunud üliõpilaste "stipendiumist taganemisele". Mis tahes muudatused andmebaasi mis tahes tabelites peavad leidma piisava muudatuse kõigis teistes tabelites. See on andmebaasi terviklikkuse tagamise põhiolemus. Praktikas täidetakse seda ülesannet, luues seoseid andmebaasi tabelite vahel. Sõnastame tabelite vaheliste suhete loomise põhireeglid. 1. Valige kahest lingitud tabelist ülem ja alam. 2. Valige igas tabelis võtmeväli. Põhitabeli võtmevälja nimetatakse esmane võti. Alamtabeli võtmevälja nimetatakse välisvõti. 3. Seotud tabeli väljad peavad olema sama tüüpi. 4. Tabelite vahel luuakse järgmist tüüpi lingid: "üks ühele"; Üks mitmele; Palju-mitmele: üks-ühele suhe luuakse siis, kui põhitabeli konkreetne rida on igal ajal seotud ainult ühe alamtabeli reaga; üks-mitmele suhe luuakse juhtudel, kui põhitabeli konkreetne rida igal ajal
33 on seotud mitme tabeli reaga; sel juhul seotakse alamtabeli mis tahes rida ainult ühe põhitabeli reaga; seos "palju-mitmele" luuakse juhtudel, kui põhitabeli konkreetne rida on igal ajal seotud mitme tabeli reaga ja samal ajal on üks alltoodud tabeli rida seotud mitme reaga põhilaud. Põhitabeli väärtuse muutmisel põhitabelis on võimalikud järgmised sõltuva tabeli käitumisviisid. Kaskaad. Kui põhitabeli esmased võtmeandmed muutuvad, muutuvad vastavas tabelis olevad välisvõti andmed. Kõik olemasolevad ühendused säilitatakse. Piira. Kui proovite muuta sõltuva tabeli ridadega seotud primaarvõtme väärtust, loobutakse muudatustest. Lubatud on muuta ainult neid esmase võtme väärtusi, mille jaoks pole sõltuvate tabelitega ühendust loodud. Asutamine (suhe). Kui primaarvõtme andmed muutuvad, seatakse võõrvõti nullväärtusele (NULL). Sõltuva tabeli rea omaniku teave on kadunud. Kui muudate mitut primaarvõtme väärtust, moodustatakse sõltuvate tabelis mitu ridade rühma, mis olid varem muudetud võtmetega seotud. Pärast seda on võimatu kindlaks teha, milline rida millise primaarvõtmega seostati. Joonisel fig. 2.6 näitab joonisel fig. 2 näidatud andmebaasi tabelite vaheliste ühenduste skeeme. 2.5. Kontrollküsimused 1. Andke määratlused andmebaasi tabeli järgmistele elementidele: väli, lahter, kirje. 2. Mida tähendavad mõisted "võti", "võtmeväli"? 3. Millist võtmevälja nimetatakse primaarvõtmeks ja millist võõrvõtmeks? 4. Kuidas toimub andmebaasitabelite normaliseerimine? 5. Milliseid viit andmebaasi tabelite tavalist vormi teate? 6. Määrake andmebaasi tabelite vahel järgmised seoste tüübid: "üks ühele"; Üks mitmele; Paljud-paljudele.