Kezdőlap > Előadás

Előadás DB 2. fejezet RELÁCIÓS ADATBÁZISOK 2.1. Kifejezések és meghatározások A relációs adatbázisok fejlesztése az 1960-as évek végén kezdődött, ekkor jelentek meg az első munkák, amelyek a szakemberek által ismert módszerek alkalmazásának lehetőségeit taglalták az adatok táblázatos formában történő formalizálására. Egyes szakértők ezt a módszert az információs döntési táblázatoknak, mások táblázatos algoritmusoknak nevezték. A relációs adatbázisok teoretikusai az információs adatszolgáltatás táblázatos módszerét adatlogikai modelleknek nevezték. A relációs adatbázisok elméletének megalapítója Dr. E. F. Codd, az IBM munkatársa volt, aki 1970. június 6-án publikálta az „A Relational Model of Data for Large Shared Data Banks” című cikket. Ebben a cikkben használták először a „relációs adatmodell” kifejezést, amely a relációs adatbázisok kezdetét jelentette. A relációs adatbázis-elmélet az 1970-es években alakult ki. az USA-ban Dr. E. F. Codd, a halmazelmélet matematikai apparátusára támaszkodott. Bebizonyította, hogy bármilyen adathalmaz ábrázolható kétdimenziós táblázatok formájában speciális típus, amelyet a matematika relációkként ismer. Tól angol szó„reláció” „kapcsolat”) és a „relációs adatmodell” elnevezés jött létre. Jelenleg az adatbázisok (DB-k) tervezésének elméleti alapja a relációs algebra matematikai apparátusa (lásd az 1.2 alfejezetet). Így a relációs adatbázis az objektumokról szóló információ (adat), kétdimenziós tömbök - táblák formájában -, amelyeket bizonyos kapcsolatok egyesítenek. Az adatbázis egy táblából is állhat. A relációs adatbázisok további tanulmányozása előtt nézzük meg az elméletben és a gyakorlatban használt fogalmakat és definíciókat. Adatbázis táblázat- egy kétdimenziós tömb, amely információkat tartalmaz az objektumok egy osztályáról. A relációs algebra elméletében kétdimenziós tömböt (táblázatot) hívnak hozzáállás. A táblázat a következő elemekből áll: mező, cella, rekord (2.1. ábra). Mező az adatbázis-objektumokat jellemző attribútumok egyikének értékeit tartalmazza. A táblázat mezőinek száma megfelel az adatbázis-objektumokat jellemző attribútumok számának. 22 Sejt tartalmazza a megfelelő mező konkrét értékét (egy objektum attribútuma). Rekord- táblázat sor. Tartalmazza az összes olyan tulajdonság értékét, amely egy objektumot jellemzi. A rekordok (sorok) száma megfelel azoknak az objektumoknak, amelyek adatait a táblázat tartalmazza. Az adatbáziselméletben a kifejezés felvétel megfelel a koncepciónak mag- az ÉS kapcsolat által összekapcsolt attribútumok sorozata. A gráfelméletben gépkocsi-kíséret egy irányított gráf egyszerű ágát jelenti - egy fát. táblázatban A 2.1 bemutatja a relációs adatbázisok fejlesztésének elméletében és gyakorlatában használt fogalmakat. A relációs adatbázisok optimális szerkezetének felépítéséhez szükséges egyik fontos fogalom a kulcs, vagy kulcsmező fogalma. Kulcsfontosságú Olyan mezőt kell figyelembe venni, amelynek értékei egyedileg meghatározzák a táblázat összes többi mezőjének értékét. Például az „Útlevélszám” vagy „Adófizető azonosítószám (TIN)” mező egyértelműen meghatározza bármely egyedi(egy vállalkozás HR osztályai vagy számviteli osztályai számára megfelelő adatbázis-táblázatok összeállításakor).
23

Egy táblázat kulcsa nem egy, hanem több mező is lehet. Ebben az esetben egy mezőkészlet csak akkor lehet lehetséges táblakulcs, ha két időfüggetlen feltétel teljesül: az egyediség és a minimálisság. Minden olyan mezőt, amely nem része az elsődleges kulcsnak, a tábla nem kulcsmezőjének nevezzük.

Egyediség kulcs azt jelenti, hogy egy adatbázistábla egy adott időpontban nem tartalmazhat két különböző rekordot, amelyek ugyanazokkal a kulcsmezőértékekkel rendelkeznek. Az egyediség feltételének teljesítése kötelező. Állapot minimalizmus kulcsmezők azt jelenti, hogy csak a kiválasztott mezők értékeinek kombinációja felel meg az adatbázistábla rekordjainak egyediségére vonatkozó követelményeknek. Ez azt is jelenti, hogy a kulcsban szereplő mezők közül egyik sem zárható ki belőle az egyediség megsértése nélkül. A több mezőből álló adatbázistábla kulcsának kialakításakor a következő rendelkezéseket kell követnie: ne vegyen fel a kulcstáblázatba olyan mezőket, amelyek értékei önmagukban egyedileg azonosítják a táblázat rekordjait. Például ne hozzon létre olyan kulcsot, amely az „útlevélszám” és az „adófizetői azonosítószám” mezőket is tartalmazza, mivel ezen attribútumok mindegyike egyedileg azonosíthatja a táblázatban szereplő rekordokat; A kulcsban nem szerepelhet nem egyedi mező, azaz olyan mező, amelynek értékei megismételhetők a táblázatban. Minden táblának tartalmaznia kell legalább egy lehetséges kulcsot, amely a következőképpen van kiválasztva elsődleges kulcs. Ha a táblázatban vannak olyan mezők, amelyek mindegyikének értéke egyedileg azonosítja a rekordokat, akkor ezek a mezők felfoghatók alternatív billentyűk. Például, ha elsődleges kulcsként az adófizető azonosító számát választja, akkor az útlevélszám lesz az alternatív kulcs. 2.2. Relációs adatbázis-táblázatok normalizálása A relációs adatbázis egymáshoz kapcsolódó táblák halmaza. Az egy fájlban vagy egy adatbázisban lévő táblák száma számos tényezőtől függ, amelyek közül a legfontosabbak: az adatbázis-felhasználók összetétele, az információk integritásának biztosítása (különösen fontos többfelhasználós esetén információs rendszerek ah), a legkisebb szükséges memória és a minimális adatfeldolgozási idő biztosítása. 24

A relációs adatbázisok tervezésénél ezeket a tényezőket a táblák normalizálásának és a köztük lévő kapcsolatok létrehozásának módszereivel lehet figyelembe venni.

A táblázatok normalizálása olyan módszereket képvisel, amelyek egy adatbázistáblát több táblára osztanak, amelyek általában megfelelnek a fent felsorolt követelményeknek. A táblázat normalizálása a tábla szerkezetének szekvenciális megváltoztatása, amíg az eleget nem tesz a normalizálás utolsó formájának követelményeinek. A normalizálásnak összesen hat formája van:

(Tovább

A normálformák leírásánál a következő fogalmakat használjuk: „mezők közötti funkcionális függés”; „teljes funkcionális függés a mezők között”; „mezők közötti többértékű funkcionális függés”; „mezők közötti tranzitív funkcionális függés”; „mezők közötti kölcsönös függetlenség”. Funkcionális függőség Az A és B mezők között egy olyan kapcsolat, amelyben A bármely értéke bármely időpontban az összes lehetséges közül az egyetlen B értéknek felel meg. A funkcionális kapcsolatra példa az adózó azonosítószáma és az útlevele száma közötti kapcsolat. Teljes funkcionális függőség az összetett A mező és a B mező között egy olyan függőség, amelyben B mező funkcionálisan az A mezőtől függ, és funkcionálisan nem függ az A mező egyetlen részhalmazától sem. Többértékű funkcionális függőség mezők között a következőképpen van meghatározva. Az A mező többértékű B mezőt definiál, ha az A mező minden értékéhez létezik a B mező megfelelő értékeinek „jól definiált halmaza”. Például, ha figyelembe vesszük a tanulói teljesítmények táblázatát egy iskolában, amely tartalmazza a „ Tárgy” mezők (A mező) és „Értékelés” (B mező), akkor B mezőben van egy „jól definiált” elfogadható értékkészlet: 1, 2, 3, 4, 5, azaz a „Tárgy” mező minden értékéhez tartozik egy többértékű „jól definiált értékkészlet” az „Értékelés” mezőhöz. Tranzitív funkcionális függőség az A és C mező között Létezik, ha C mező funkcionálisan 25 B mezőtől függ, és B mező funkcionálisan az A mezőtől függ; ebben az esetben nincs A mező funkcionális függése a B mezőtől. Kölcsönös függetlenség a területek között a következőképpen van meghatározva. Több mező egymástól független, ha egyik sem függ funkcionálisan a másiktól. Első normál forma. Egy táblázat akkor és csak akkor van első normál formában, ha egyik mező sem tartalmaz egynél több értéket, és egyik kulcsmező sem üres. Az első normál forma a relációs adatmodell alapja. A relációs adatbázis bármely táblája automatikusan az első normál formában van, különben definíció szerint ez egyszerűen nem lehetséges. Egy ilyen táblázat nem tartalmazhat olyan mezőket (attribútumokat), amelyek több mezőre (attribútumra) oszthatók. A nem normalizált táblázatok általában azok, amelyeket eredetileg nem a bennük lévő információk számítógépes feldolgozására szántak. Például a táblázatban. A 2.2. ábra a Fémvágógépek Kísérleti Kutatóintézete (ENIMS) által kiadott „Univerzális fémvágó gépek” című referenciakönyv táblázatának egy részletét mutatja. Ez a táblázat a következő okok miatt nincs normalizálva. 1. Olyan sorokat tartalmaz, amelyek egy mezőben több értéket tartalmaznak egy cellában: „Legnagyobb feldolgozási átmérő, mm” és „Orsó forgási sebessége, ford./perc”. 2. Egy mező – „Teljes méretek (hossz x szélesség x magasság), mm” három mezőre osztható: „Hossz, mm”, „Szélesség, mm” és „Magasság, mm”. Az ilyen felosztás megvalósíthatóságát indokolhatja a területek vagy a foglalt térfogatok utólagos számításának szükségessége. A forrástáblát át kell alakítani az első normál formára. Ehhez a következőket kell tennie: ossza fel a „Legnagyobb feldolgozási átmérő, mm” és „Orsó fordulatszáma, fordulatszám” mezőket több mezőre az egy cellában található értékek számának megfelelően;

A „Teljes méretek (hossz x szélesség x magasság), mm” mező három mezőre oszlik: „Hossz, mm”, „Szélesség, mm”, „Magasság, mm”. Ennek a táblázatnak a kulcsmezője lehet a „Gépmodell” vagy „Tételszám” mező. A táblázat normál űrlaptípussal rendelkezik. 2.3. Nézzünk egy másik példát. ábrán. A 2.2. ábrán a teszt- és vizsgalap nyomtatvány egy töredéke látható, amelyet az előző példához hasonlóan eredetileg nem számítógépes feldolgozásra szántak. Tegyük fel, hogy egy adatbázist szeretnénk létrehozni a teszt és a vizsgamenet eredményeinek automatizált feldolgozásához
27

teszt és vizsgalap tartalmával. Ehhez az űrlap tartalmát adatbázistáblákká alakítjuk. A mezők közötti funkcionális függőség feltételeinek való megfelelés szükségessége alapján legalább két tábla létrehozása szükséges (2.3. ábra) (a kulcsmezők mindegyik táblázatban félkövérrel vannak kiemelve). Az első táblázat egy adott tantárgyból az egyes tanulók által teljesített teszt (vizsga) eredményét tartalmazza. A második táblázat egy adott tantárgyból meghatározott tanulócsoport tesztjének (vizsgájának) végeredményét tartalmazza. Az első táblázatban a kulcsmező a „Hallgató neve”, a második táblázatban pedig a „Diszciplina” mező. A táblázatokat a „Diszciplina” és a „Csoportkód” mezőkkel kell összekapcsolni.

A bemutatott táblaszerkezetek teljes mértékben megfelelnek az első normál forma követelményeinek, de a következő hátrányok jellemzik őket: új adatok táblákhoz való hozzáadása megköveteli az összes mező értékének megadását; Az egyes táblázatok minden sorában ismétlődő értékeket kell megadni a „Diszciplina”, „A tanár teljes neve”, „Csoportkód” mezőkhöz. Következésképpen a táblázatok ilyen összetétele és felépítése esetén az információk egyértelmű redundanciája van, ami természetesen további memóriamennyiséget igényel. A felsorolt hátrányok elkerülése érdekében szükséges a táblázatokat második vagy harmadik normálformára redukálni. Második normál forma. Egy tábla akkor van második normál formában, ha megfelel az első normál forma követelményeinek, és minden olyan mezője, amely nem szerepel az elsődleges kulcsban, funkcionálisan teljes mértékben az elsődleges kulcstól függ. 28

Ha egy táblázatnak van egy egyszerű elsődleges kulcsa, amely csak egy mezőből áll, akkor az automatikusan második normál formában van.

Ha az elsődleges kulcs összetett, akkor a táblázat nem feltétlenül második normál formában van. Ezután két vagy több táblára kell osztani, hogy az elsődleges kulcs egyértelműen azonosítsa az értéket bármely mezőben. Ha a táblában van legalább egy olyan mező, amely nem függ az elsődleges kulcstól, akkor további oszlopokat kell tartalmaznia az elsődleges kulcsban. Ha nincsenek ilyen oszlopok, akkor új oszlopot kell hozzáadnia. Ezen, a második normálalakot meghatározó feltételek alapján az összeállított táblázatok jellemzőire vonatkozóan a következő következtetések vonhatók le (lásd 2.3. ábra). Az első táblázatban nincs közvetlen kapcsolat a kulcsterület és a „Tanár neve” mező között, mivel egy tárgyból különböző tanárok tehetnek tesztet vagy vizsgát. A táblázatban csak az összes többi mező és a „Fegyelem” kulcsmező között van teljes funkcionális függés. Hasonlóképpen, a második táblázatban nincs közvetlen kapcsolat a kulcsmező és a „Tanár neve” mező között. Az adatbázis optimalizálása érdekében, különösen a szükséges memóriamennyiség csökkentése érdekében, mivel minden rekordban meg kell ismételni a „Diszciplina” és a „Tanár neve” mezők értékét, módosítani kell a adatbázis - konvertálja az eredeti táblákat második normál formára. A táblázatok összetételét a módosított adatbázis-struktúrában az ábra mutatja. 2.4. Az átalakított adatbázis-struktúra hat táblából áll, amelyek közül kettő össze van kötve (a kulcsmezők mindegyik táblában félkövérrel vannak kiemelve). Minden táblázat megfelel a második normálforma követelményeinek. Az ötödik és a hatodik tábla mezőiben duplikált értékek találhatók, de mivel ezek az értékek szöveges adatok helyett egész számok, az információk tárolásához szükséges teljes memória jelentősen kisebb, mint az eredeti táblázatokban (lásd 2.1. ábra). . Ezen túlmenően az új adatbázis-struktúra lehetővé teszi a táblázatok különböző szakemberek (a menedzsment szolgáltatási részlegek) általi kitöltését. Az adatbázis-táblázatok további optimalizálása a harmadik normál formátumba hozásukhoz vezet. Harmadik normál forma. Egy táblázat akkor van harmadik normál formában, ha megfelel a második normálforma definíciójának, és egyik nem kulcsmezője sem függ funkcionálisan más nem kulcsmezőtől. 29

Azt is mondhatjuk, hogy egy táblázat harmadik normál formában van, ha második normál formában van, és minden nem kulcsmező tranzitív módon nem függ az elsődleges kulcstól. A harmadik normálforma követelménye, hogy minden nem kulcs mező csak az elsődleges kulcstól függ, és független egymástól. E követelményeknek megfelelően az adatbázistáblák részeként (lásd 2.3. ábra) a harmadik normálforma tartalmazza az első, második, harmadik és negyedik táblát. Ahhoz, hogy az ötödik és hatodik táblázatot a harmadik normál formába hozzuk, egy új táblázatot hozunk létre, amely információkat tartalmaz azon tantárgyak összetételéről, amelyekből tanulócsoportokban tartanak vizsgákat vagy teszteket. Kulcsként létrehozunk egy „Számláló” mezőt, amely beállítja a táblázat rekordszámát, mivel minden rekordnak egyedinek kell lennie. 30

Ennek eredményeként egy új adatbázis-struktúrát kapunk, amelyet az ábra mutat be. 2.5 (a kulcsmezők mindegyik táblázatban félkövérrel vannak kiemelve). Ez a struktúra hét olyan táblázatot tartalmaz, amelyek megfelelnek a harmadik normálforma követelményeinek.

A Boyce normál formája Codd. Egy tábla csak akkor Boyce-Codd normál formában van, ha a mezői közötti funkcionális függés egy lehetséges kulcstól való teljes funkcionális függőséggé csökken. E definíció szerint az adatbázis-struktúrában (lásd 2.4. ábra) minden tábla megfelel a Boyce-Codd normálforma követelményeinek. Az adatbázistáblák további optimalizálását csökkenteni kell a táblák teljes dekompozíciójáig. Teljes táblázatbontás tetszőleges számú vetületének ilyen gyűjteményét nevezik, amelyek kombinációja teljesen egybeesik a táblázat tartalmával. A vetítés egy olyan táblázat másolata, amely nem tartalmazza az új táblázat egy vagy több oszlopát. Negyedik normál forma. A negyedik normálforma az ötödik normálforma speciális esete, amikor a teljes dekompozíciónak két vetület uniójának kell lennie.

Nagyon nehéz olyan táblázatot találni, amely negyedik normálformában van, de nem felel meg az ötödik normálforma definíciójának.

Ötödik normál forma. Egy táblázat akkor és csak akkor van ötödik normál formában, ha minden teljes dekompozíciójában minden vetület tartalmaz egy lehetséges kulcsot. Az a táblázat, amelynek nincs teljes bontása, szintén ötödik normálforma. A gyakorlatban az adatbázistáblák optimalizálása a harmadik normál formával végződik. A táblázatok negyedik és ötödik normálformára való redukálása véleményünk szerint pusztán elméleti érdek. A gyakorlatban ez a probléma megoldható egy új tábla létrehozásához szükséges lekérdezések fejlesztésével. 2.3. Táblák közötti kapcsolatok tervezése A forrásadatbázis-táblázatok normalizálásának folyamata lehetővé teszi az információs rendszer optimális struktúrájának létrehozását - olyan adatbázis kialakítását, amely a legkevesebb memóriaerőforrást igényel, és ennek eredményeként legkevesebb időt információkhoz való hozzáférést. Ugyanakkor egy forrástábla több részre osztása megköveteli az információs rendszerek tervezésének egyik legfontosabb feltételének teljesítését - az információk integritásának biztosítását az adatbázis működése során. Az eredeti táblák normalizálásának fenti példájában (lásd 2.3. ábra) két táblából végül hét táblázatot kaptunk a harmadik és negyedik normálformára redukálva. Ahogy a gyakorlat azt mutatja, a valós termelésben és az üzleti életben az adatbázisok többfelhasználós rendszerek. Ez vonatkozik mind az adatok külön táblákban történő létrehozására és karbantartására, mind az információk döntéshozatali felhasználására. A fent tárgyalt példában egy valóban működő egyetemi, főiskolai oktatási folyamatirányítási rendszerben a tanulmányi csoportok kezdeti megalakítását a felvételi bizottságok végzik a felvételi vizsgák eredménye alapján történő beiratkozáskor. Az egyetemeken a hallgatók csoportjainak összetételére vonatkozó információk további karbantartása a dékáni hivatalra, a főiskolákon pedig az oktatási osztályokra vagy megfelelő struktúrákra van bízva. Az akadémiai tudományágak csoportos összetételét más szolgálatok vagy szakemberek határozzák meg. Az oktatói személyzettel kapcsolatos információkat a humánerőforrás osztályokon állítják elő. A teszt- és vizsgaidőszak eredményeire a dékáni hivatal és a tanszékvezetők számára szükség van, így a 32 sikeres hallgató ösztöndíj odaítéléséről, illetve a sikertelen hallgatók „ösztöndíjból való eltávolításáról” szóló döntéshez is. Bármely adatbázistáblázatban végrehajtott változtatásnak meg kell felelnie az összes többi tábla megfelelő módosításának. Ez az adatbázis integritásának biztosításának a lényege. A gyakorlatban ezt a feladatot adatbázistáblák közötti kapcsolatok létrehozásával hajtják végre. Fogalmazzuk meg a táblák közötti kapcsolatok létrehozásának alapvető szabályait. 1. Válassza ki a fő és az alárendelt táblákat két összekapcsolt táblából. 2. Válasszon ki egy kulcsmezőt minden táblázatban. A főtábla kulcsmezőjét ún elsődleges kulcs. Az alárendelt tábla kulcsmezőjét ún idegen kulcs. 3. A csatolt táblamezőknek azonos adattípussal kell rendelkezniük. 4. A következő típusú kapcsolatok jönnek létre a táblák között: „egy az egyhez”; "egy a sokhoz"; „sok-sok”: egy-egy kapcsolat jön létre azokban az esetekben, amikor a főtábla egy adott sora az utódtábla csak egy sorához van társítva bármikor; Egy-a-többhöz kapcsolat akkor jön létre, ha egy adott sor a fő táblában egy adott időpontban

33 az altábla több sorához van társítva; ebben az esetben az alárendelt tábla bármely sora csak a főtábla egy sorához kapcsolódik; A sok a sokhoz kapcsolat akkor jön létre, ha a főtábla egy adott sora bármikor az alárendelt tábla több sorához van társítva, és ugyanakkor az alárendelt tábla egy sora a fő tábla több sorához kapcsolódik. táblázat. Ha módosítja az elsődleges kulcs értékét a főtáblában, a következő viselkedés lehetséges a függő táblánál. Lépcsőzetes. Amikor a fő táblában az elsődleges kulcs adatai megváltoznak, a függő táblában a megfelelő idegenkulcs-adatok megváltoznak. Minden meglévő kapcsolat megmarad. Korlátozás. Ha megpróbálja megváltoztatni egy olyan elsődleges kulcs értékét, amelyhez sorok vannak társítva egy függő táblában, a módosítások elutasításra kerülnek. Csak azokat az elsődleges kulcsértékeket szabad megváltoztatni, amelyekhez nincs kapcsolat a függő táblával. Létrehozás (Kapcsolat). Amikor az elsődleges kulcs adatai megváltoznak, az idegen kulcs értéke NULL lesz. A függő tábla sorainak tulajdonjogával kapcsolatos információk elvesznek. Ha több elsődleges kulcsértéket módosít, a függő tábla több olyan sorcsoportot hoz létre, amelyek korábban a módosított kulcsokhoz voltak társítva. Ezek után lehetetlen meghatározni, hogy melyik sor melyik elsődleges kulcshoz volt társítva. ábrán. A 2.6. ábra az ábrán bemutatott adatbázis táblái közötti kapcsolatok diagramjait mutatja be. 2.5. Biztonsági kérdések 1. Határozza meg az adatbázistábla következő elemeit: mező, cella, rekord. 2. Mit jelentenek a „kulcs” és „kulcsmező” fogalmak? 3. Melyik kulcsmezőt nevezzük elsődleges kulcsnak és melyiket idegen kulcsnak? 4. Mi a folyamata az adatbázistáblák normalizálásának? 5. Milyen öt normál adatbázis-táblázatot ismer? 6. Határozza meg a következő típusú kapcsolatokat az adatbázistáblák között: „egy az egyhez”; "egy a sokhoz"; "sok a sok". relációs adatbázis logikai modellje relációs adatbázis objektumokba. A probléma megoldásához az adatbázis-tervezőnek tudnia kell: a) a relációs adatbázisnak elvileg milyen objektumai vannak; b) milyen objektumokat támogat az adatbázis megvalósításához kiválasztott DBMS.

Feltételezzük tehát, hogy a DBMS választásáról az informatikai projektmenedzser már meghozta a döntést és egyeztette az adatbázis megrendelőjével, pl. A DBMS meg van adva. Az adatbázis-tervezőnek át kell tekintenie a dokumentációt, amely leírja a kiválasztott DBMS által támogatott SQL dialektust. Ez az előadás feltételezi, hogy az Oracle 9i DBMS-t választották, bár az anyag túlnyomó többsége bármely ipari relációs DBMS-ben található objektumokra vonatkozik.

Megjegyzés. A DBMS kiválasztásáról. A DBMS kiválasztása több szempontú kiválasztási probléma, és ebben a kurzusban nem tárgyaljuk. Emlékeztetni kell arra, hogy egy DBMS általában csak egy adatmodellt támogat: relációs, hierarchikus, hálózati, többdimenziós, objektumorientált, objektumrelációs. A kivétel néhány DBMS. Például ADABAS, Software AG (hálózati és relációs modellek) vagy Oracle 9i, Oracle Inc. (relációs és objektum-relációs modellek). Általában egy DBMS kiválasztásakor, minden más lehetőség mellett, megpróbálnak egy adatbázist létrehozni egy DBMS-en, amely iparági szabványnak vallja magát.

A relációs adatbázis-objektumok hierarchiáját az SQL szabványok írják elő, különös tekintettel az SQL-92 szabványra, amelyre az előadás anyagának bemutatásakor hangsúlyt fektetünk. Ezt a szabványt szinte minden modern DBMS támogatja, beleértve az asztaliakat is. A relációs adatbázis-objektumok hierarchiája az alábbi ábrán látható.

A legalacsonyabb szinten vannak azok a legkisebb objektumok, amelyekkel egy relációs adatbázis működik - oszlopok (oszlopok) és sorok. Ezek viszont táblázatokba és nézetekbe vannak csoportosítva.

Megjegyzés. Az előadás keretében az attribútumok, oszlopok, oszlopok és mezők szinonimáknak minősülnek. Ugyanez vonatkozik a „string”, „record” és „tuple” kifejezésekre is.

A táblázatok és nézetek, amelyek az adatbázis logikai struktúrájának fizikai megjelenítését jelentik, sémává vannak összeállítva. Több sémát gyűjtünk össze katalógusokba, amelyeket aztán fürtökbe lehet csoportosítani. Meg kell jegyezni, hogy az SQL-92 szabvány egyik objektumcsoportja sem kapcsolódik az információ fizikai tárolására szolgáló struktúrákhoz a számítógép memóriájában.

Rizs. 8.1.

A relációs adatbázisban az ábrán látható objektumok mellett indexek, triggerek, események, tárolt parancsok, tárolt eljárások és számos egyéb is létrehozható. Most térjünk át a relációs adatbázis-objektumok meghatározására.

A relációs adatbázis alapvető objektumai

A fürtök, címtárak és sémák nem kötelező elemei a szabványnak, így a relációs adatbázis-szoftverkörnyezetnek.

A fürt olyan könyvtárak csoportja, amelyek egyetlen kapcsolaton keresztül érhetők el egy adatbázis-kiszolgálóval (DBMS szoftverkomponens).

A gyakorlatban az eljárás könyvtár létrehozása a DBMS egy adott operációs platformon való megvalósítása határozza meg. A katalógus sémák csoportjaként értendő. A gyakorlatban egy könyvtárat gyakran egy fizikai adatbázishoz társítanak, mint fizikai fájlok gyűjteményét operációs rendszer, amelyeket az ő neve azonosít.

Az adatbázis-tervező számára a séma egy teljes adatbázis kapcsolatainak átfogó logikai reprezentációja. SQL kifejezéssel a séma a relációs adatbázis tábláinak, nézeteinek és egyéb szerkezeti elemeinek tárolója. Az adatbáziselemek elhelyezését az egyes sémákban teljes mértékben az adatbázis-tervező határozza meg.

Táblázatok és nézetek létrehozásához nincs szükség sémára. Ha csak egy logikai adatbázis telepítését tervezi, akkor egyértelmű, hogy megteheti séma nélkül is. Ha azonban ugyanazt a DBMS-t kívánja használni több adatbázis támogatására, akkor az adatbázis-objektumok sémákba való megfelelő rendszerezése sokkal könnyebbé teheti az adatbázisok karbantartását. A gyakorlatban egy sémát gyakran egy adott felhasználó objektumaihoz társítanak egy fizikai adatbázisban.

Ezután a relációs adatbázis-objektumok az Oracle 9i relációs DBMS-rendszerében kerülnek bevitelre. Ezt a megközelítést azért fogadták el, mert a tervezés relációs adatbázis fizikai modellje egy adott megvalósítási környezethez kerül végrehajtásra.

Az Oracle 9i-ben a séma kifejezést a felhasználó által létrehozott összes adatbázis-objektum leírására használják. Minden új felhasználóhoz automatikusan új séma jön létre.

A relációs adatbázisok fő objektumai közé tartozik a tábla, a nézet és a felhasználó.

A táblázat a relációs adatbázisok alapvető szerkezete. Egy adattárolási egységet – egy relációt – képvisel. A táblát az adatbázisban egyedi neve azonosítja, amely tartalmazza a felhasználó azonosítását. A táblázat lehet üres vagy állhat sorok halmazából.

A Nézet egy elnevezett, dinamikusan karbantartott DBMS-kijelölés egy vagy több adatbázistáblából. A lekérési operátor korlátozza a felhasználó számára látható adatokat. A DBMS általában garantálja a nézet relevanciáját – minden alkalommal generálódik, amikor a nézetet használják. Néha nézetek ún virtuális asztalok.

A felhasználó olyan objektum, amely képes más adatbázis-objektumok létrehozására vagy használatára, és DBMS-funkciók végrehajtását kérheti, mint például egy munkamenet megszervezése, az adatbázis állapotának megváltoztatása stb.

Az objektumok azonosításának és elnevezésének megkönnyítése érdekében az adatbázis támogatja az olyan objektumokat, mint a szinonimák, sorozatok és .

Szinonimája ( Szinonima)- Ezt alternatív név egy relációs adatbázis objektuma (álneve), amely lehetővé teszi, hogy hozzáférjen ehhez az objektumhoz. A szinonimák lehetnek általánosak vagy magánjellegűek. A megosztott szinonimák lehetővé teszik az adatbázis összes felhasználójának, hogy a megfelelő objektumra az álnevén hivatkozzon. A szinonimák lehetővé teszik egy objektum teljes minősítésének elrejtését az adatbázisban a végfelhasználók elől.

A Sequence egy adatbázis-objektum, amely lehetővé teszi egyedi számok (számok) sorozatának létrehozását többfelhasználós aszinkron hozzáférésben. Jellemzően a sorozatelemek a táblázatelemek (sorok) egyedi számozására szolgálnak az adatmódosítási műveletekben.

Felhasználó által meghatározott adattípusok (Felhasználó által meghatározott adattípusok) a felhasználó által definiált attribútumtípusok (tartományok), amelyek különböznek a DBMS által támogatott (beépített) típusoktól. Meghatározásuk a beépített típusok alapján történik. Felhasználó által meghatározott adattípusok a DBMS-környezet azon részét alkotják, amely az objektumorientált paradigma szerint van megszervezve.

Az adatokhoz való hatékony hozzáférés biztosítása érdekében a relációs DBMS-ek számos egyéb objektumot támogatnak: index, táblaterület, fürt, szakasz.

Az index egy adatbázis-objektum, amelyet az adatlekérési teljesítmény javítására és az elsődleges kulcs egyediségének szabályozására hoztak létre (ha a táblához meg van adva). A teljesen indextáblák (index-rendszerű táblák) egyidejűleg táblaként és indexként is működnek.

Asztalterület vagy terület ( Asztalterület) az adatbázis egy elnevezett része, amely a táblák és indexek memóriafoglalására szolgál. Az Oracle 9i-ben ez az operációs rendszer fizikai fájljainak logikai neve. Minden adattároló adatbázis-objektum megfelel néhánynak asztalterek. A legtöbb adatot nem tároló adatbázis-objektum az adatszótárban található, amely a SYSTEM táblaterületen található.

A fürt egy olyan objektum, amely meghatározza az adatok több vagy egy táblában történő tárolásának módját. A fürt használatának egyik feltétele, hogy több tábla közös kulcsmezőkkel rendelkezzen, amelyeket ugyanabban az SQL-parancsban használnak. A fürtözött oszlopok vagy táblák általában a következő néven vannak tárolva az adatbázisban hash táblázatok(azaz speciális módon).

A partíció egy adatbázis-objektum, amely lehetővé teszi, hogy egy objektumot adatokkal különböző alobjektumok gyűjteményeként ábrázoljon. asztalterek. Így, szakaszolás lehetővé teszi nagyon nagy táblák elosztását több merevlemez között.

Az adatok speciális módon történő feldolgozásához vagy megvalósításához hivatkozási integritás támogatása adatbázis objektumok használatosak: tárolt eljárás, függvény, parancs, trigger, időzítő és köteg (Oracle). Ezekkel az adatbázis-objektumokkal az adatok úgynevezett rekordfeldolgozását végezheti el. Az adatbázis-alkalmazások szempontjából a sorfeldolgozás az adatok soronkénti szekvenciális visszakeresése, feldolgozása, majd a következő sor feldolgozása.

Ezek a relációs adatbázis objektumok programok, pl. futtatható kód. Ezt a kódot általában szerveroldali kódnak nevezik, mert az a számítógép hajtja végre, amelyre a relációs adatbázismotor telepítve van. Az ilyen kód tervezése és fejlesztése a relációs adatbázis-tervező feladatai közé tartozik.

A tárolt eljárás egy adatbázis-objektum, amely speciális adatbázis-programozási nyelvekből (például SQLWindows vagy PL/SQL) származó SQL-parancsok és/vagy utasítások elnevezett halmazát képviseli.

A függvény egy adatbázis-objektum, amely SQL-parancsok és/vagy speciális adatbázis-programozási nyelvi operátorok elnevezett halmazát képviseli, amely végrehajtásakor egy értéket ad vissza – egy számítás eredményét.

A parancs egy elnevezett SQL utasítás, amelyet előre lefordítanak és tárolnak az adatbázisban. A parancsfeldolgozási sebesség nagyobb, mint a megfelelő SQL utasításé, mert fázisok nem hajtódnak végre elemzéseés összeállítás.

A trigger egy adatbázis-objektum, amely egy speciális tárolt eljárás. Ez az eljárás automatikusan lefut, amikor egy trigger esemény bekövetkezik (például mielőtt egy sort beszúrna a táblázatba).

Az időzítő abban különbözik a triggertől, hogy a tárolt eljárás triggereseménye egy időzítő esemény.

A csomag egy adatbázis-objektum, amely változók, eljárások és függvények elnevezett, strukturált halmazából áll.

Az elosztott relációs DBMS-eknek speciális objektumai vannak: pillanatkép és adatbázishivatkozás.

A pillanatkép (Snapshop) egy távoli adatbázisban lévő tábla helyi másolata, amelyet a tábla vagy a lekérdezés eredményének replikálására (replikálására) használnak. A pillanatképek módosíthatók vagy csak olvashatók lehetnek.

Az adatbázishivatkozás vagy távoli adatbázishivatkozás olyan adatbázis-objektum, amely lehetővé teszi a távoli adatbázisban lévő objektumok elérését. Az adatbázis-hivatkozás neve durván szólva úgy is felfogható, mint egy távoli adatbázis paramétereinek elérésére szolgáló hivatkozás.

Az adathozzáférés-szabályozás hatékony kezelése érdekében az Oracle támogatja a szerepkör-objektumot.

A szerepkör egy adatbázis-objektum, amely a felhasználókhoz, a felhasználók kategóriáihoz vagy más szerepkörökhöz rendelhető jogosultságok elnevezett halmaza.

A relációs adatbázisok alapfogalmai

A relációs adatbázisok főbb fogalmai a következők:

adattípus

elsődleges kulcs és
hozzáállás.

Először is mutassuk meg e fogalmak jelentését a MUNKAVÁLLALÓ kapcsolat példáján keresztül,

4.1. ábra. Fogalmak hierarchiája az EMPLOYEES adatbázisban

Adattípus

Az adattípus fogalma a relációs adatmodellben teljesen megfelel a programozási nyelvek adattípusának. A modern relációs adatbázisok jellemzően karakterek, numerikus adatok, bitsorok, speciális numerikus adatok (például pénz), valamint speciális időbeli adatok (dátum, idő, időintervallum) tárolását teszik lehetővé.

Domain

A tartomány fogalma inkább az adatbázisokra vonatkozik, bár van némi analógiája egyes programozási nyelvek altípusaival. A tartományt legáltalánosabb formájában úgy határozzuk meg, hogy megadunk valamilyen alapadattípust, amelyhez a tartomány elemei tartoznak, és egy tetszőleges logikai kifejezést alkalmazunk az adattípus elemére. Ha ennek a logikai kifejezésnek a kiértékelése igazat ad vissza, akkor az adatelem egy tartományelem. A tartomány fogalmának leghelyesebb intuitív értelmezése az, hogy a tartományt egy adott típusú megengedett potenciális értékkészletként értelmezzük. Például a példánkban szereplő domain nevek a karakterláncok alaptípusán vannak definiálva, de értékei csak olyan karakterláncokat tartalmazhatnak, amelyek egy nevet képviselhetnek (az ilyen karakterláncok nem kezdődhetnek puha jel). Figyelembe kell venni a tartományfogalom szemantikai terhelését is: az adatokat csak akkor tekintjük összehasonlíthatónak, ha ugyanahhoz a tartományhoz tartoznak. Példánkban a Skip Numbers és Group Numbers tartományok értékei egész típusúak, de nem hasonlíthatók össze.

Kapcsolati séma, adatbázisséma

A relációs séma párok elnevezett halmaza attribútum neve, domain név(vagy írja be, ha a domain koncepció nem támogatott). Egy relációs séma foka vagy aritása ennek a halmaznak a hatalma. A MUNKAVÁLLALÓK reláció foka négyes, azaz 4 éves. Ha egy reláció összes attribútuma különböző tartományokon van definiálva, akkor célszerű a megfelelő tartományok nevét használni az attribútumok elnevezésére (természetesen emlékezve arra, hogy ez csak egy kényelmes elnevezési mód, és nem szünteti meg a a tartomány és az attribútum fogalma). Az adatbázisséma (strukturális értelemben) elnevezett kapcsolati sémák halmaza.

Tuple, reláció

Egy adott relációs sémának megfelelő tuple párok halmaza attribútum neve, értéke, amely a relációs sémához tartozó attribútumnevek egy-egy előfordulását tartalmazza. Az érték az attribútum tartományának érvényes értéke (vagy adattípus, ha a tartománykoncepció nem támogatott). Így a sor foka vagy aritása, i.e. a benne lévő elemek száma egybeesik a megfelelő relációs séma aritásával. Egyszerűen fogalmazva, a tuple egy adott típusú elnevezett értékek gyűjteménye. A reláció egyetlen relációs sémának megfelelő sorok halmaza. Néha a félreértések elkerülése végett sémarelációt és példányrelációt mondanak, néha egy reláció sémáját a reláció fejének, a relációt mint sorok halmazát pedig a reláció törzsének nevezik. Valójában a relációs séma fogalma áll a legközelebb a strukturális adattípus fogalmához a programozási nyelvekben. Teljesen logikus lenne megengedni, hogy külön definiáljunk egy relációs sémát, majd egy vagy több relációt azzal a sémával. Ez azonban nem általános gyakorlat a relációs adatbázisokban. Egy reláció séma neve az ilyen adatbázisokban mindig megegyezik a megfelelő példányreláció nevével. A klasszikus relációs adatbázisokban az adatbázisséma meghatározása után csak a példánykapcsolatok módosulnak. Új sorok jelenhetnek meg bennük, a meglévők pedig törölhetők vagy módosíthatók. Számos megvalósításban azonban lehetőség van az adatbázisséma megváltoztatására is: új relációs sémák definiálására és meglévő relációs sémák módosítására. Ezt általában adatbázisséma evolúciónak nevezik. A reláció szokásos hétköznapi ábrázolása egy tábla, amelynek fejléce a reláció sémája, a sorok pedig a példányreláció sorai; ebben az esetben az attribútumnevek az adott tábla oszlopait nevezik meg. Ezért néha azt mondják, hogy táblázat oszlop, ami relációs attribútumot jelent. Amikor áttérünk a relációs adatbázisok és kezelőeszközök rendszerezésének gyakorlati kérdéseire, ezt a mindennapi terminológiát fogjuk használni. Ezt a terminológiát követi a legtöbb kereskedelmi relációs DBMS. A relációs adatbázis kapcsolatok halmaza, amelyek neve megegyezik az adatbázissémában lévő kapcsolatsémák nevével. Mint látható, a relációs adatmodell strukturális alapfogalmai (kivéve a tartomány fogalmát) nagyon egyszerű intuitív értelmezést kapnak, bár a relációs adatbázisok elméletében ezek mind abszolút formálisan és pontosan meghatározottak.

A kapcsolatok alapvető tulajdonságai

Most térjünk ki a relációk néhány fontos tulajdonságára, amelyek a korábban megadott definíciókból következnek.

Nincsenek ismétlődő sorok

Az a tulajdonság, hogy a relációk nem tartalmaznak ismétlődő sorokat, a relációnak sorok halmazaként való definíciójából következik. IN klasszikus elmélet halmazok, értelemszerűen minden halmaz különböző elemekből áll. Ez a tulajdonság azt jelenti, hogy minden kapcsolatnak van egy úgynevezett elsődleges kulcsa - olyan attribútumok halmaza, amelyek értékei egyedileg határozzák meg a relációt. Minden reláció esetében legalább az attribútumok teljes halmaza rendelkezik ezzel a tulajdonsággal. Az elsődleges kulcs formális meghatározásakor azonban biztosítani kell annak minimálisságát, pl. Az elsődleges kulcs attribútumainak halmaza nem tartalmazhat olyan attribútumokat, amelyek a fő tulajdonság befolyásolása nélkül eldobhatók – egyedileg azonosítva a leírót. Az elsődleges kulcs fogalma rendkívül fontos az adatbázis integritásának fogalmával kapcsolatban. A jövőre nézve megjegyezzük, hogy az RDBMS számos gyakorlati megvalósításában megsérthető a lekérdezések végrehajtásakor implicit módon generált köztes relációk sorainak egyedisége. Az ilyen kapcsolatok nem halmazok, hanem multihalmazok, ami bizonyos esetekben lehetővé teszi bizonyos előnyök elérését, de néha komoly problémákhoz vezet.

A sorok sorrendjének hiánya

Egy reláció sorai rendezetlenségének tulajdonsága annak a következménye is, hogy a példányrelációt sorok halmazaként határozzuk meg. A reláció soraira vonatkozó sorrend fenntartásának követelményének hiánya további rugalmasságot biztosít a DBMS-nek, amikor adatbázisokat tárol a külső memóriában, és amikor lekérdezéseket hajt végre az adatbázisban. Ez nem mond ellent annak, hogy adatbázis-lekérdezés megfogalmazásakor, például SQL-ben, megkövetelheti, hogy az eredményül kapott táblázatot egyes oszlopok értékeinek megfelelően rendezzék. Egy ilyen eredmény általában véve nem egy reláció, hanem a sorok rendezett listája.

Az attribútumok sorrendjének hiánya

A relációk attribútumai nincsenek rendezve, mivel a relációs séma definíció szerint párok halmaza attribútum neve, domain név. Ha egy relációs sorban egy attribútumértékre hivatkozunk, mindig az attribútum nevét használjuk. Ez a tulajdonság elméletileg lehetővé teszi például a meglévő kapcsolatok sémáinak módosítását nemcsak új attribútumok hozzáadásával, hanem a meglévő attribútumok eltávolításával is. A legtöbb létező rendszer azonban nem teszi lehetővé ezt a lehetőséget, és bár a relációs attribútumok sorrendje nem kifejezetten kötelező, az attribútumok sorrendjét a relációs séma definíciójának lineáris alakjában gyakran használják az attribútumok implicit rendezéseként. .

Az attribútumértékek atomitása

Az összes attribútum értéke atomi. Ez a tartomány definíciójából következik, mint egy egyszerű adattípus potenciális értékkészlete, pl. A domain értékek nem tartalmazhatnak több értéket (kapcsolatokat). Általában azt mondják, hogy a relációs adatbázisokban csak a normalizált vagy az első normál formában ábrázolt kapcsolatok megengedettek. ábrán látható egy lehetséges példa a nem normalizált arányra. 4.2.1.

4.2.1. ábra. RÉSZLETEK reláció nem normalizált formában

4.2.2. ábra. Normalizált hozzáállás ALKALMAZOTTAK

Azt mondhatjuk, hogy itt bináris relációnk van, a DEPARTMENTS attribútum értékei relációk. Figyeljük meg, hogy az eredeti ALKALMAZOTTAK reláció a RÉSZLETEK reláció normalizált változata (lásd 4.2.2. ábra). A normalizált kapcsolatok képezik az adatbázis-szervezés klasszikus relációs megközelítésének alapját. Vannak bizonyos korlátai (nem kényelmes minden információt lapos táblázatok formájában bemutatni), de jelentősen leegyszerűsítik az adatkezelést. Vegyünk például két azonos sorbeillesztési operátort:

Jelentkezzen Kuznyecov alkalmazott (3000-es igazolvány, 115 000 fizetés) a 320-as osztályra, és Kuznyecov alkalmazott (3000-es igazolvány, 115000-es fizetés) a 310-es osztályra. Ha az alkalmazottak adatait ALKALMAZOTT relációként jelenítik meg, akkor mindkét nyilatkozat végrehajtásra kerül. tuple a MUNKAVÁLLALÓK vonatkozásában). Ha a nem normalizált DEPARTMENTS relációval dolgozik, akkor az első operátor egy sor hozzáadását eredményezi, a második operátor pedig a 310-es elsődleges kulcsú leíró DEPARTMENT attribútumának többszörös értékéhez ad hozzá Kuznyecov-információkat.

Relációs adatmodell

Amikor az előző részekben a relációs adatbázisok alapfogalmairól beszéltünk, nem támaszkodtunk semmilyen konkrét megvalósításra. Ezek a megfontolások egyformán vonatkoztak minden olyan rendszerre, amelynek felépítése során relációs megközelítést alkalmaztak. Más szóval, az úgynevezett relációs adatmodell fogalmait használtuk. Az adatmodell olyan általános fogalmakat és jellemzőket ír le, amelyekkel minden konkrét DBMS-nek és az általuk kezelt adatbázisnak rendelkeznie kell, ha ezen a modellen alapul. Az adatmodell lehetővé teszi az egyes megvalósítások összehasonlítását egyetlen közös nyelv használatával. Bár az adatmodell fogalma általános, és beszélhetünk hierarchikus, hálózati, valamilyen szemantikai stb. adatmodellek esetében meg kell jegyezni, hogy ezt a fogalmat a relációs rendszerekkel kapcsolatban vezették be, és ebben az összefüggésben használják a leghatékonyabban. A hasonló modellek közvetlen alkalmazására tett kísérletek a kapcsolat előtti szervezetekre azt mutatják, hogy a relációs modell számukra túl nagy, a posztkapcsolati szervezetek számára pedig kicsinek bizonyul.

Általános jellemzők

A relációs adatmodell legáltalánosabb értelmezése a Data, aki szinte minden könyvében reprodukálja (különböző finomításokkal). Date szerint a relációs modell három részből áll, amelyek a relációs megközelítés különböző aspektusait írják le: a strukturális részből, a manipulációs részből és a holisztikus részből. A modell strukturális része kimondja, hogy a relációs adatbázisokban az egyetlen adatstruktúra a normalizált n-áris reláció. Valójában ennek az előadásnak az előző két részében pontosan a relációs modell strukturális komponensének fogalmait és tulajdonságait vizsgáltuk. A modell manipulációs része megerősíti a relációs adatbázisok kezelésének két alapvető mechanizmusát - a relációs algebrát és a relációs kalkulust. Az első mechanizmus főleg a klasszikus halmazelméletre épül (néhány finomítással), a második pedig az elsőrendű predikátumszámítás klasszikus logikai apparátusán. A következőkben ezeket a mechanizmusokat nézzük meg részletesebben, de egyelőre csak annyit jegyezünk meg, hogy a relációs modell manipulációs részének fő funkciója, hogy egy adott relációs adatbázis-nyelv relációját mérje: egy nyelvet relációsnak nevezünk. ha nem kevesebb kifejezőképessége és ereje van, mint a relációs algebra vagy a relációs kalkulus.

Entitás és referencia integritás

Végül a relációs adatmodell szerves része két alapvető integritási követelményt rögzít, amelyeket minden relációs DBMS-nek támogatnia kell. Az első követelményt entitás integritási követelménynek nevezzük. Objektum vagy entitás való világ relációs adatbázisokban relációk sorainak felelnek meg. Konkrétan a követelmény az, hogy bármely reláció bármely sorának megkülönböztethetőnek kell lennie a reláció bármely többi sorától, azaz. más szóval minden kapcsolatnak rendelkeznie kell elsődleges kulccsal. Ahogy az előző részben láttuk, ez a követelmény automatikusan teljesül, ha a relációk alapvető tulajdonságai nem sérülnek a rendszerben. A második követelményt hivatkozási integritási követelménynek nevezik, és valamivel összetettebb. Nyilvánvaló, hogy ha a relációkat normalizáljuk, akkor a való világ összetett entitásai egy relációs adatbázisban több reláció több soraként jelennek meg. Képzeljük el például, hogy a DEPARTMENT entitást egy relációs adatbázisban kell ábrázolnunk a DTD_NUMBER (részlegszám), DTD_COL (alkalmazottak száma) és DTD_COTR (részlegi alkalmazottak halmaza) attribútumokkal. Minden alkalmazottnál el kell tárolnia a SOTR_NUMBER (alkalmazotti szám), a SOTR_NAME (alkalmazott neve) és a SOTR_ZARP (alkalmazotti fizetés) számokat. Amint azt hamarosan látni fogjuk, a megfelelő adatbázis megfelelő kialakításával két kapcsolat jelenik meg benne: RÉSZLETEK (DEPARTMENT_NUMBER, DEPARTMENT_COUNTY) (elsődleges kulcs - DEPARTMENT_NUMBER) és ALKALMAZOTTAK (CORPORATE_NUMBER, COTR_NAME, COTR_ZARP, COTR_DEPARTMENT_NUMBER) (TR_NUMBER kulcs) ). Mint látható, a SOTR_DEPARTMENT_NOM attribútum nem azért jelenik meg az EMPLOYEE relációban, mert az osztályszám az alkalmazott saját tulajdona, hanem csak azért, hogy szükség esetén vissza lehessen állítani a teljes OSZTÁLY entitást. Az STR_DEPARTMENT_NOM attribútum értékének az EMPLOYEES reláció bármely sorában meg kell egyeznie a DEPARTMENT_NOM attribútum értékével a DEPARTMENTS reláció valamelyik tulajában. Az ilyen attribútumot idegen kulcsnak nevezzük, mivel értékei egyedileg jellemzik a valamely más reláció sorai által képviselt entitásokat (azaz elsődleges kulcsuk értékeit adják meg). Azt mondják, hogy egy reláció, amelyben egy idegen kulcs van definiálva, egy megfelelő relációra hivatkozik, amelyben ugyanaz az attribútum az elsődleges kulcs. A hivatkozás integritási követelménye, vagy idegenkulcs-követelmény, hogy minden hivatkozási relációban megjelenő idegenkulcs-értékhez a hivatkozott relációban legyen egy sor ugyanazzal az elsődleges kulcs értékkel, vagy az idegen kulcs értékének teljesen definiálatlannak kell lennie (pl. nem jelezve semmit). Példánkban ez azt jelenti, hogy ha egy alkalmazotthoz osztályszámot adnak meg, akkor ennek a részlegnek léteznie kell. A DBMS-nek támogatnia kell az entitás- és hivatkozási integritási megszorításokat. Egy entitás integritásának megőrzéséhez elegendő gondoskodni arról, hogy egyetlen relációban se legyenek azonos elsődleges kulcs értékű sorok. A hivatkozási integritással a dolgok egy kicsit bonyolultabbak. Nyilvánvaló, hogy egy hivatkozási kapcsolat frissítésekor (új sorok beszúrása vagy idegen kulcs értékének módosítása a meglévő sorokban) elegendő gondoskodni arról, hogy hibás idegen kulcsértékek ne jelenjenek meg. De mi a helyzet egy sor eltávolításával egy hivatkozott relációból? Itt három megközelítés létezik, amelyek mindegyike támogatja a hivatkozási integritást. Az első megközelítés a hivatkozott sor törlésének megtiltása (azaz először törölnie kell a hivatkozási sorokat, vagy ennek megfelelően módosítania kell az idegen kulcs értékeit). A második megközelítésben, amikor egy hivatkozott sor törlésre kerül, az összes hivatkozott sor automatikusan meghatározatlan idegenkulcs-értékkel rendelkezik. Végül a harmadik megközelítés (lépcsőzetes törlés) az, hogy amikor egy leírót törölünk egy hivatkozott relációból, az összes hivatkozó tuple automatikusan törlődik a hivatkozási relációból. A kiforrott relációs DBMS-ekben általában meg lehet választani, hogyan kell fenntartani a hivatkozási integritást az egyes idegen kulcs-definíciós helyzetekben. Természetesen egy ilyen döntés meghozatalához elemezni kell egy adott alkalmazási terület követelményeit.

A relációs adatbázisok terminológiája és alapfogalmai

Szinte minden szoftvertermék, amelyet a 70-es évek vége óta hoztak létre, a relációs megközelítésen alapul:

1. Az adatok meghatározott szabályok szerint rendezett kétdimenziós táblázatokban jelennek meg.

2. Az adatokkal való munkavégzéshez a felhasználó operátorokat kap, amelyek segítségével az eredeti lekérdezések - lekérdezések - alapján új táblák jönnek létre.

Relációs adatbázisok– egyetlen adattár, amelyet egyedileg azonosítanak, majd sok felhasználó használ. Az adatok módosítása és hozzáadása az adatbázishoz nincs hatással az alkalmazásra.

Adatbázis-kezelő rendszer– szoftvercsomag, amellyel a felhasználók adatbázist definiálhatnak és karbantarthatnak, valamint ellenőrzött hozzáférést hajthatnak végre.

A relációs adatbázisok alapfogalmai:

1. Koncepció adattípus a relációs adatmodellben teljesen megfelel a programnyelvi adattípus fogalmának. A modern relációs adatbázisok jellemzően karakterek, numerikus adatok, bitkarakterláncok, speciális numerikus adatok (például „pénz”), valamint speciális „időbeli” adatok (dátum, idő, időintervallum) tárolását teszik lehetővé.

2. A relációs modell matematikai koncepción alapul hozzáállás, melynek fizikai ábrázolása egy táblázat, vagyis egy relációt nevezhetünk oszlopokból és sorokból álló lapos táblázatnak.

3. Díszkíséret, egy adott relációs sémának megfelelő (attribútumnév, érték) párok halmaza, amely a relációs sémához tartozó minden egyes attribútumnév egy-egy előfordulását tartalmazza.

4. Attribútum– táblázat oszlop, adatbázis fájl mező. Az attribútumértékek egy relációtáblázatban csak egy meghatározott típusú funkcionális függéssel rendelkezhetnek egymástól, nevezetesen, egy tetszőleges sor összes értékének egyénileg csak egy oszlop vagy oszlopcsoport értékétől kell függnie - ugyanaz az egész kapcsolatra. Az ilyen oszlopot vagy oszlopcsoportot kulcsoszlopnak, a benne lévő attribútumértékeket pedig kulcsoknak nevezik.

5. Domain– egy vagy több attribútum érvényes értékeinek halmaza.

6. A kapcsolat mértéke a benne lévő attribútumok száma határozza meg. Egy attribútummal rendelkező reláció 1-es fokozatú, és unáris relációnak nevezzük. A két attribútummal rendelkező kapcsolatot binárisnak, a három attribútummal rendelkező kapcsolatot háromtagúnak, a több attribútummal rendelkező kapcsolatot n-árisnak nevezzük.

7. A kapcsolatok kardinalitása– a relációban található sorok száma. Ez a jellemző minden sorszám eltávolításakor vagy hozzáadásakor változik.

8. A fentiek alapján egy relációs adatbázis kapcsolatokból áll, amelyek szerkezetét speciális, normalizálásnak nevezett módszerekkel határozzuk meg.

9. Ebben a vonatkozásban ne legyenek ismétlődő sorok, a fogalom bevezetésre kerül relációs kulcsok minden egyes relációs sor egyedi azonosítása egy vagy több attribútum értéke alapján.

10. Szuperkulcs– egy attribútum vagy attribútumok halmaza, amely egyedileg azonosítja egy adott reláció sorát.

11. Potenciális kulcs– egy szuperkulcs, amely nem tartalmaz olyan részhalmazt, amely egyben ennek a relációnak a szuperkulcsa is. Egy adott R reláció K potenciális kulcsának két tulajdonsága van:

· Egyediség. Az R reláció minden sorában a K kulcs értéke egyedileg azonosítja azt a sort.

· Irreducibilitás. A K kulcs egyetlen érvényes részhalmaza sem rendelkezik egyediség tulajdonsággal.

12. Elsődleges kulcs– egy jelölt kulcs, amelyet a reláción belüli sorok egyedi azonosítására választanak ki, a fennmaradó ki nem választott kulcsok alternatív kulcsok. Ha az elsődleges kulcs egy mezőből áll, akkor egyszerűnek, ha több mezőből áll, összetettnek nevezzük.

13. Másodlagos (idegen) kulcs (VC)- ezek egy vagy több attribútum egy reláción belül, amelyek egy bizonyos reláció potenciális kulcsának felelnek meg, és keresési vagy csoportosítási jellemzőkként működnek. Az elsődleges kulccsal ellentétben a másodlagos kulcs értéke a fájl több rekordjában megismételhető, azaz nem egyedi. Ha egy rekord egyetlen példánya megtalálható az elsődleges kulcs értékével, akkor a másodlagos kulcs több példányt is megtalálhat.

14. Hozzáállás egy relációs sémának megfelelő sorok halmaza.

15. Alapvető hozzáállás– egy reláció, amelynek sorai fizikailag az adatbázisban vannak tárolva.

16. Beadványok– alapvető relációkon végzett egy vagy több relációs művelet dinamikus eredménye valamilyen más reláció létrehozása céljából. A nézet egy virtuális kapcsolat, amely valójában nem létezik az adatbázisban, de egy egyedi felhasználó kérésére jön létre, amikor a kérelem beérkezik. A nézetek nagyobb adatbiztonságot tesznek lehetővé, és lehetőséget adnak a tervezőnek a felhasználói modell testreszabására.

17. A kapcsolatok alapvető tulajdonságai:

· Egy reláció neve eltér a relációs séma összes többi relációjának nevétől.

· Minden relációs cella csak egy elemi (oszthatatlan) értéket tartalmaz.

· Minden attribútumnak egyedi neve van.

· Az attribútumértékek ugyanabból a tartományból származnak.

· Minden sor egyedi, azaz. Nem lehetnek ismétlődő sorok.

· Az attribútumok sorrendje nem számít.

· Elméletileg a sorok sorrendje egy relációban nem számít. (A gyakorlatban azonban ez a sorrend jelentősen befolyásolhatja a hozzáférés hatékonyságát.)

Date szerint a relációs modell három részből áll, amelyek a relációs megközelítés különböző aspektusait írják le: a strukturális részből, a manipulációs részből és a holisztikus részből.

1. A modell felépítése normalizált kapcsolatokon alapul, figyelembe véve a relációs adatbázis alapfogalmait.

2. A modell manipulációs része a relációs adatbázisok kezelésének két alapvető mechanizmusát erősíti meg - a relációs algebrát és a relációs kalkulust.

3. Integritás b(az angol integrity - intactness, inviolability, safety, integrity) alatt az adatok mindenkori helyességét értjük.

3. szakasz „Adatbázisok”

1. Információs támogatás automatizált rendszerek.

Az automatizált rendszer (AS) információs támogatása - dokumentumformák, osztályozók, szabályozási keretek és megvalósított megoldások összessége az AS-ben a működése során felhasznált információk mennyiségére, elhelyezésére és létezési formáira vonatkozóan

A GOST 24.205-80 szerint az automatizált vezérlőrendszer információs támogatásának leírásának a következő szakaszokból kell állnia:

az információs támogatás megszervezésének elvei;

információgyűjtés és -továbbítás szervezése;

osztályozási és kódolási rendszer kiépítése;

gépen belüli információs bázis szervezése;

gépen kívüli információs bázis szervezése.

Az „információs támogatás” kifejezést különböző összefüggésekben, különböző funkciókkal és tevékenységtípusokkal kapcsolatban széles körben használják, félreérthetően értelmezik és vitatható. Amellett, hogy ez a kifejezés az információs struktúrákat jelöli, ez gyakran egy adott társadalmi-gazdasági objektum szükségleteihez szükséges információk biztosításának folyamatát jelenti.

A számítógépes központok hálózatának információs támogatása magában foglalja az adattömböket, azok leírásának, gyűjtésének, tárolásának és kiadásának eszközeit, amelyek együttesen létrehozzák legjobb körülmények között a központosított integrált információfeldolgozás érdekében kollektív hozzáférést biztosítanak a sok előfizető számára közös adatokhoz, növelik a kapott információk megbízhatóságát és megbízhatóságát.

Az automatizált rendszer információs támogatása dokumentumformák, osztályozók, szabályozási keretek és megvalósított megoldások összessége az automatizált rendszerben a működése során felhasznált információk mennyiségére, elhelyezésére és létezési formáira vonatkozóan (GOST 34.003-90 („Automatizált rendszerek. Kifejezések). és meghatározások”)).

IO – totalitás egységes rendszer információk osztályozása, kódolása, egységes dokumentációs rendszerek, a szervezetben keringő információáramlás mintái, adatbázisok felépítésének módszertana.

Ez az alrendszer az információk időben történő bemutatására és a vezetői döntéshozatalra készült. A vállalati információs rendszer egy adott objektum információs modellje. Az IO létrehozásához világosan meg kell értenie az irányítási rendszer céljait és célkitűzéseit, funkcióit; dokumentumáramlási rendszer megvalósítása; az információ mozgásának azonosítása az előfordulásuk pillanatától a különböző irányítási szinteken történő felhasználásig; az információk osztályozásának és kódolásának elérhetősége és használata; információs tömbök létrehozása számítógépes adathordozón; információs modellek létrehozásának módszertanának ismerete.

Az IR megszervezése során szisztematikus megközelítéssel biztosítják az egységes információs bázis kialakítását; szabványos adatcsere-séma kialakítása a rendszer különböző szintjei között és az egyes szinteken belül; egységes rendszer szervezése az információk karbantartására és tárolására; a megoldandó feladatok ellátása kiindulási adatokkal;

Az IO fő funkciói a termelés és a gazdasági tevékenységek előrehaladásának figyelemmel kísérése, a szabályozott paraméterek állapotának és a meghatározott módoktól való eltérésének azonosítása és rögzítése; a kezelt objektumok állapotát tükröző elsődleges dokumentumok feldolgozásának előkészítése; automatizált adatfeldolgozás biztosítása; megvalósítása közvetlen és visszacsatolás a menedzsment objektumai és alanyai között.

Az automatizált információs rendszerek mesterséges intelligenciája gépen kívüli és gépen belüli MI-ből áll.

Az extra-gép magában foglalja a műszaki és gazdasági információk osztályozási és kódolási rendszerét; dokumentációs rendszer; információs folyamatábra (dokumentumfolyamat: elsődleges, eredő, normatív és referencia dokumentumok).

A gépen belüli információk adattömböket tartalmaznak a gépi adathordozón és egy programot az adatokhoz való hozzáférés megszervezésére.

A gépen kívüli információ olyan információ, amelyet egy személy technikai eszköz (dokumentumok) nélkül észlel.

Az osztályozás alatt az információelemek halmazának feltételes részhalmazokra való felosztását értjük hasonlóság vagy eltérés alapján.

2. DBMS és adatbázis-alkalmazások.

Az adatbázis-kezelő rendszer (DBMS) olyan nyelvi és szoftvereszközök halmaza, amelyek biztosítják az adatbázisok létrehozásának és használatának kezelését.

A modern DBMS a következőkből áll:

kernelek - a DBMS programok részei, amelyek felelősek a memóriában lévő adatok kezeléséért és a naplózásért; Adatbázis nyelvi feldolgozó, adatok lekéréséhez és módosításához szükséges lekérdezések optimalizálása, adatbázis létrehozása;

Futásidejű támogatási alrendszerek, amelyek értelmezik a DBMS felhasználói felületet létrehozó adatkezelő programokat;

Szolgáltatási programok (külső segédprogramok), amelyek egyéb képességeket biztosítanak az információs rendszerek karbantartásához.

A DBMS fő funkciói a következők

Külső memóriában tárolt adatok kezelése;

A címre feltöltött adatok kezelése RAM lemez gyorsítótár használata; Események és változások naplózása, adatbázis-mentés és hiba utáni helyreállítás;

Adatbázis-kezelő nyelvek támogatása (adatdefiníciós nyelv, adatkezelési nyelv);

DBMS besorolások

Számos kritérium alapján lehet besorolni egy DBMS-t.

Az adatmodellre épülő DBMS-ek a következők:

Hierarchikus DBMS, Hálózati DBMS, Relációs DBMS, Objektumorientált DBMS, Objektumrelációs DBMS. Jelenleg az utolsó 2 típust használják komoly projektekben. DBMS az eloszlás mértéke szerint. Helyi (az DBMS csak egy számítógépen található) Elosztott (a DBMS egyes részei 2 vagy több számítógépen is elhelyezkedhetnek).

Adatbázis alkalmazások

Az adatbázis-alkalmazásokat, ahogy a neve is sugallja, úgy tervezték, hogy valamilyen adatforrással – adatbázissal (DB) – kölcsönhatásba lépjenek. Az interakció magában foglalja az adatok fogadását, meghatározott formátumban történő megjelenítését a felhasználó számára, a programban megvalósított üzleti algoritmusoknak megfelelő szerkesztését, valamint a feldolgozott adatok visszaküldését az adatbázisba.

Az adatforrás lehet maga az adatbázis vagy közönséges fájlok - szöveg, táblázatok stb. De itt megvizsgáljuk az adatbázisokkal működő alkalmazásokat.

Maga az alkalmazás tartalmaz egy mechanizmust az adatok fogadására és küldésére, egy mechanizmust az adatok belső megjelenítésére ilyen vagy olyan formában, egy felhasználói felületet az adatok megjelenítéséhez és szerkesztéséhez, valamint üzleti logikát az adatok feldolgozásához.

Az adatok fogadásának és küldésének mechanizmusa kapcsolatot biztosít az adatforrással (gyakran közvetetten). Tudnia kell, hová kell mennie, és milyen kommunikációs protokollt kell használnia a kétirányú adatáramlás biztosításához.

A belső adatreprezentációs motor az adatbázis-alkalmazások magja. A kapott adatokat az alkalmazásban tárolja, és az alkalmazás más részei kérésére elérhetővé teszi.

A felhasználói felület lehetővé teszi az adatok megtekintését és szerkesztését, valamint az adatok és az alkalmazás egészének kezelését.

Egy alkalmazás üzleti logikája a programban megvalósított adatfeldolgozó algoritmusok halmaza.

Az alkalmazás és maga az adatbázis között van egy speciális szoftver(szoftver), amely összeköti a programot és az adatforrást, és vezérli az adatcsere folyamatát. Ezt a szoftvert az adatbázis méretétől, a rendszer által megoldott feladatoktól, a felhasználók számától, valamint az alkalmazás és az adatbázis összekapcsolásának módjától függően nagyon sokféleképpen lehet megvalósítani. A köztes szoftver megvalósítható alkalmazási környezetként, amely nélkül egyáltalán nem fog működni, vagy az alkalmazás által elért illesztőprogramok és dinamikus könyvtárak halmaza integrálható magába az alkalmazásba. Végül, ez lehet egyetlen távoli szerver, amely több ezer alkalmazást szolgál ki.

Az adatforrás egy adattárház (maga az adatbázis) és az adatokat kezelő DBMS, amely biztosítja az adatok integritását és konzisztenciáját.

3. A relációs adatbázisok modern fogalma.

Alapvető relációs adatbázis-fogalmak

Mielőtt ezeket a lépéseket részletesen megvizsgálnánk, tekintsük át a relációs adatbázisok alapfogalmait. A relációelméletben az egyik fő a kapcsolat fogalma. Matematikailag az arányt a következőképpen határozzuk meg. Legyen adott n D1,D2,...,Dn halmaz. Ekkor R egy reláció ezeken a halmazokon, ha R az alak rendezett halmazainak halmaza , ahol d1 a D1 eleme, d2 a D2 eleme, ..., dn a Dn eleme. Ebben az esetben az űrlap készletei soroknak, a D1,D2,...,Dn halmazokat pedig tartományoknak nevezzük. Minden sor a tartományukból kiválasztott elemekből áll. Ezeket az elemeket attribútumoknak, értékeikat attribútumértékeknek nevezzük. A 9-a ábra a kapcsolat grafikus ábrázolását mutatja be különböző nézőpontokból.

Könnyen belátható, hogy a reláció a való világ valamely entitásának (jelen esetben a „részlet” entitásnak) a tükörképe, az adatfeldolgozás szempontjából pedig egy táblázat. A tuple egy sor egy táblázatban, vagy ennek megfelelően egy rekord. Az attribútum egy táblázat oszlopa vagy egy mező egy rekordban. A tartomány egyfajta általánosított típusként jelenik meg, amely a rekord mezőtípusainak forrása lehet. Így a következő kifejezések hármasai egyenértékűek:

reláció, táblázat

sor, húr, lemez

attribútum, oszlop, mező.

A relációs adatbázis olyan kapcsolatok gyűjteménye, amelyek minden szükséges információt tartalmaznak, és amelyeket különféle kapcsolatok egyesítenek.

Egy adott sor (sor, rekord) egyedi azonosítására használható attribútumot (vagy attribútumkészletet) elsődleges kulcsnak nevezünk. Az elsődleges kulcs nem tartalmazhat további attribútumokat. Ez azt jelenti, hogy ha egy tetszőleges attribútumot kizárunk az elsődleges kulcsból, a fennmaradó attribútumok nem lesznek elegendőek az egyes sorok egyedi azonosításához. Az elsődleges kulcshoz való hozzáférés felgyorsítása érdekében minden adatbázis-kezelő rendszer (DBMS) rendelkezik egy indexelés nevű mechanizmussal. Durván szólva, az index egy fordított falista, amely az egyes elsődleges kulcsok rekordjának valódi helyére mutat. Természetesen az indexeket eltérő módon implementálják a különböző DBMS-ekben (a helyi DBMS-ekben általában külön fájlok formájában), azonban a felépítésük elvei azonosak.

Lehetőség van kapcsolatok indexelésére az elsődleges kulcstól eltérő attribútumok használatával. Ezt az indextípust másodlagos indexnek nevezik, és a hozzáférési idő csökkentésére szolgál, amikor egy relációban adatot talál, valamint rendezésre. Így, ha maga a reláció semmilyen módon nincs rendezve, és tartalmazhat néhány sor törlése után fennmaradó sorokat, akkor az index (helyi DBMS-eknél - az indexfájl) éppen ellenkezőleg, rendezve lesz.

Az adatok hivatkozási integritásának megőrzése érdekében sok DBMS rendelkezik úgynevezett idegen kulcsok mechanizmusával. Ennek a mechanizmusnak az a jelentése, hogy egy reláció egy bizonyos attribútuma (vagy attribútumcsoportja) egy hivatkozást rendel egy másik reláció elsődleges kulcsához; ezáltal erősítve az alá-fölérendeltségi kötelékeket e kapcsolatok között. Ebben az esetben azt a relációt, amelynek elsődleges kulcsára egy másik reláció idegen kulcsa hivatkozik, mesterrelációnak vagy fő relációnak nevezzük; és azt a relációt, amelyből a link származik, részletrelációnak vagy alárendelt relációnak nevezzük. Egy ilyen hivatkozás hozzárendelése után a DBMS képes automatikusan felügyelni a kapcsolatok közötti kapcsolatok „nem megsértésének” problémáit, nevezetesen:

ha olyan alárendelt táblába próbálunk beszúrni egy rekordot, amelynél az idegen kulcs nem egyezik a főtáblában (például még nincs ilyen elsődleges kulccsal rendelkező rekord), a DBMS hibát generál;

ha olyan rekordot próbál meg törölni a főtáblából, amelynek elsődleges kulcsa legalább egy hivatkozást tartalmaz a slave táblából, akkor a DBMS is hibát generál.

Ha megpróbálja megváltoztatni egy olyan rekord elsődleges kulcsát a fő táblában, amely legalább egy hivatkozást tartalmaz a slave táblából, akkor a DBMS szintén hibát generál.

KIEGÉSZÍTÉS

A relációs adatbázisok alapfogalmai

A relációs adatbázisok alapfogalmai az adattípus, tartomány, attribútum, sor, elsődleges kulcs és reláció.

Adattípus

Koncepció adattípus a relációs adatmodellben teljesen megfelel a programnyelvi adattípus fogalmának. A modern relációs adatbázisok jellemzően karakterek, numerikus adatok, bitkarakterláncok, speciális numerikus adatok (például „pénz”), valamint speciális „időbeli” adatok (dátum, idő, időintervallum) tárolását teszik lehetővé. A relációs rendszerek képességeinek absztrakt adattípusokkal való bővítésének megközelítése meglehetősen aktívan fejlődik (például az Ingres/Postgres család rendszerei rendelkeznek a megfelelő képességekkel). Példánkban háromféle adattal van dolgunk: karakterláncokkal, egész számokkal és "pénzzel".

Domain

Koncepció domain specifikusabb az adatbázisokra, bár van némi analógiája egyes programozási nyelvek altípusával. A tartományt legáltalánosabb formájában úgy határozzuk meg, hogy megadunk valamilyen alapadattípust, amelyhez a tartomány elemei tartoznak, és egy tetszőleges logikai kifejezést alkalmazunk az adattípus elemére. Ha ennek a logikai kifejezésnek a kiértékelése igazat ad vissza, akkor az adatelem egy tartományelem.

A tartomány fogalmának leghelyesebb intuitív értelmezése az, hogy a tartományt egy adott típusú megengedett potenciális értékkészletként értelmezzük. Például a példánkban a "Nevek" tartomány a karakterláncok alaptípusán van definiálva, de értékei csak olyan karakterláncokat tartalmazhatnak, amelyek egy nevet képviselhetnek (különösen, az ilyen karakterláncok nem kezdődhetnek lágy karakterrel).

Figyelembe kell venni a tartományfogalom szemantikai terhelését is: az adatokat csak akkor tekintjük összehasonlíthatónak, ha ugyanahhoz a tartományhoz tartoznak. Példánkban a "Gap Numbers" és a "Group Numbers" tartományértékek egész típusúak, de nem összehasonlíthatók. Vegye figyelembe, hogy a legtöbb relációs DBMS nem használja a tartomány fogalmát, bár az Oracle V.7 már támogatja.

Relációs adatbázisok. Alapfogalmak, kapcsolati tulajdonságok, adatmodell, relációs műveletek és számítás

A relációs adatbázis alapvető objektumai

A relációs adatbázisok terminológiája és alapfogalmai