A relációs adatmodell E. Codd vezette be: 1970 A Relational Model of Data for Large Shared Data Banks. Communications of ACM, 13(6). 377-387. 1982 Relational Databases: A Practical Foundation for Productivity. Communication of ACM, 109-117. legelterjedtebb adatmodell napjainkban népszerőségét annak köszönheti, hogy nagyon egyszerő deklaratív nyelvvel rendelkezik az adatok kezelésére, illetve lekérdezésére. értékorientált, ez ahhoz vezet, hogy a relációkon értelmezett mőveletek eredményei szintén relációk.
A relációs adatmodell értelmezése Legyenek D,, D, K D halmazok. 1 2 n R egy reláció a D,, D, K D halmazokon, ha 1 2 n R D D K D 1 2 n Relációs adatmodell szempontjából D i az A i attribútum értékeinek tartománya (doméniuma). D i lehet egész számok halmaza, karaktersorok halmaza, valós számok halmaza stb. n a reláció foka.
Egy ilyen relációt táblázatban ábrázolhatunk: R A 1... A j... A n r 1 a 11... a 1j... a 1n M r i a i1... a ij... a in M r m a m1... a mj... a mn ahol a ij D j. a táblázat sorai a reláció elemei. a tábla megnevezést is használják a reláció helyett.
Jelöljés: R (A 1, A 2,..., A n ). A reláció nevét és a reláció attribútumainak a halmazát együtt relációsémának nevezzük. példa: Diákok (BeiktSzám, Név, SzületésiDátum, CsopKod) reláció: BeiktSzám Név SzületésiDátum CsopKod 67908 Nagy Ödön 1975-DEC-13 512 68799 Kiss Csaba 1971-APR-20 541 68820 Papp József 1973-JAN-6 521
példa: Könyvek (ISBN, Szerzı, Cím, Kiadó, KiadÉv) reláció: ISBN Szerzı Cím Kiadó KiadÉv 35463526 C. J. Date An Introduction to Database Addison- 2005 Systems Wesley 45344534 Paul Helman The Science of Database IRWIN 1994
A relációs adatmodell tulajdonságai 1. A tábla nem tartalmazhat két teljesen azonos sort, azaz két sor legalább egy attribútum konkrét értékében el kell hogy térjen egymástól. 2. Kulcs értelmezése: egy S attribútumhalmaz az R reláció kulcsa, ha: R relációnak nem lehet két sora, melynek értékei megegyeznek az S halmaz minden attribútumára. S egyetlen valódi részhalmaza sem rendelkezik a) tulajdonsággal. Példa: Diákok esetén BeiktSzám. több attribútum is lehet, amelyek értéke egyedi minden egyes elıfordulásra nézve, akkor több kulcsjelöltrıl beszélhetünk; kulcsjelöltek közül egyet elsıdleges kulcsnak kell kijelölni.
ha nincs olyan tulajdonság, amelynek értéke egyedi lenne, akkor több tulajdonság értéke együtt fogja jelenteni az elsıdleges (összetett) kulcsot. Az 1. tulajdonság mindig kell legyen elsıdleges kulcs, ha más nem, a teljes sor mindig egyedi. Elsıdleges kulcs értéke soha nem lehet null vagy üres. 3. A táblázat sorainak a sorrendje lényegtelen. 4. A táblázat oszlopaira vagyis az attribútumokra a nevükkel hivatkozunk, tehát két attribútumnak nem lehet ugyanaz a neve. 5. A táblázat oszlopainak a sorrendje lényegtelen.
Relációs adatbázis séma meghatározása Relációs adatbázis séma: az adatbázist alkotó relációk sémájának az összessége. A relációkban tárolt konkrét értékek alkotják a relációs adatbázist. Egy helyes relációs adatbázis sémát több módszerrel is kaphatunk: az egyed/kapcsolat diagramot átírjuk relációsémákká, egy létezı relációs adatbázis sémát normalizálás segítségével normál formára hozzuk, Object Definition Language segítségével megtervezett objektum-orientált adatbázis szerkezetet átírunk relációsémákká UML
Az egyed/kapcsolat diagramok átírása relációs modellé 1. Egyedhalmaz reláció. (egyedhalmaz attribútumai a reláció attribútumai lesznek) 2. Kapcsolat reláció (kulcsok attribútumok) 3. Közös kulcsú relációk összevonása.
2. Kapcsolat reláció (kulcsok attribútumok) Legyen egy kapcsolat az E 1, E 2,..., E m egyedhalmazok között. Legyenek K 1, K 2,..., K m az E 1, E 2,..., E m kulcs attribútumai, ahol K. i E i Relációs modell relációnak attribútumai a K 1, K 2,..., K m lesz. Ha a kapcsolatokhoz attribútumokat rendeltünk az E/K diagramon, a relációs modell relációjában a kulcsok mellett a kapcsolat attribútumai is szerepelnek.
3. Közös kulcsú relációk összevonása: Ha két relációnak van egy közös kulcsjelöltje, a két relációt összevonjuk és helyettesítjük egy relációval. Elınyök: kevesebb helyet foglal a reláció, a lekérdezések hamarabb megválaszolhatók, nincsenek annyira szétdarabolva az összetartozó adatok.
példa: nagykereskedı cég egyszerősített adatbázisa. 1. Egyedhalmaz reláció. Az egyedhalmazok kulcsai a relációk kulcsai lesznek, és ezt aláhúzással jelöljük a relációs modell relációi esetében is. (1) Alkalmazottak (SzemSzám, Név, Fizetés) (2) Managerek (SzemSzám) (3) Részlegek (RészlegID, Név, Helység) (4) Szállítók (SzállID, Név, Helység, UtcaSzám) (5) ÁruCsoportok (CsopID, Név) (6) Áruk (ÁruID, Név, MértEgys, MennyRakt) (7) Vevık (VevıID, Név, Helység, UtcaSzám, Mérleg) (8) Szerzıdések (SzerzıdID, Dátum, Részletek) (9) Tételek (TételID, Dátum)
2. Kapcsolat reláció (kulcsok attribútumok) (10) Dolgozik(SzemSzám, RészlegID) (11) Irányít (SzemSzám, RészlegID) (12) Árul (CsopID, RészlegID) (13) Tartozik (CsopID, ÁruID) (14) Szállít (SzállID, ÁruID, Ár) (15) Elhelyez (VevıID, SzerzıdID) (16) Tartalmaz (SzerzıdID, TételID) (17) Szerepel (TételID, ÁruID, RendMenny, SzállMenny)
nagyon fontos, hogy a kapcsolatokból kapott relációk kulcs attribútumait helyesen határozzuk meg egy relációnak több kulcsjelöltje is lehet, a tervezı dönti el, hogy melyiket választja. Ha a kapcsolat bináris (E 1 és E 2 egyedhalmazok között) E 1 nek K 1 a kulcsa, E 2 nek K 2 a kulcsa,
Irányelvként elfogadhatjuk a következıket: 1:1 típusú kapcsolatok esetén lehet a K 1 vagy a K 2 is kulcsjelölt. Példa: a Managerek és Részlegek egyedhalmazok közötti Irányít kapcsolat esetén a SzemSzám és a RészlegID is lehet kulcs. 1: n típusú kapcsolat E 1 és E 2 (itt az n) között, akkor a kapcsolatnak megfelelı reláció kulcsjelöltje a K 2. Példa: a Részlegek és Alkalmazottak egyedhalmazok között a Dolgozik kapcsolat 1: n típusú, a Dolgozik relációnak a relációs adatmodellben a kulcsa a SzemSzám. n: m típusú kapcsolat áll fenn E 1 és E 2 egyedhalmazok között, akkor a kapcsolatnak megfelelı relációnak kulcsjelöltje összetett kulcs lesz, a K 1 és a K 2 egyesítése. Példa: a Szállítók és Áruk közötti Szállít kapcsolat n: m típusú, így a kulcs összetett, SzállID és ÁruID együtt.
az E/K az_egy specializáló kapcsolataihoz nem készítünk relációkat, az általános egyedhalmazhoz egy olyan relációt készítünk, amelynek a sémája tartalmazza az egyedhalmaz attribútumait. minden alosztályban megismételjük az általános egyedhalmaz kulcsát. tehát a specializáló kapcsolatokat burkolt formában az a tény fejezi ki, hogy a kapcsolódó egyedeknek ugyanazok a kulcsértékei. Példa: a Managerek reláció fogja azon alkalmazottak személyi számait tárolni, akik managerek. A személyi számukat tároljuk, biztosít minket arról, hogy a managerek is alkalmazottak, megtaláljuk az Alkalmazottak relációban a személyi szám segítségével.
3. Közös kulcsú relációk összevonása: Alkalmazottak és Dolgozik közös kulcsa SzemSzám, az Alkalmazottak relációt kiegészítjuk a RészlegID-al. Alkalmazottak (SzemSzám, Név, Fizetés, RészlegID) Hasonlóan: ÁruCsoportok (CsopID, Név, RészlegID) Áruk (ÁruID, Név, MértEgys, MennyRakt, CsopID) Szerzıdések (SzerzıdID, Dátum, Részletek, VevıID) Tételek (TételID, Dátum, SzerzıdID)
Részlegek és Irányít közös kulcsa a RészlegID, a Részlegek relációt kiegészítjük a managere személyi számával, átkereszteljük ManSzemSzám-á Részlegek (RészlegID, Név, Helység, ManSzemSzám) Kérdés: - ha az egyik részlegnek épp nincs managere a ManSzemSzám attribútumnak nullértéket használunk. A NULL érték nem 0 (zéró), nem üres karaktersor, hanem egy speciális érték.
Az összetett kulcsú Szállít és Szerepel nem vonható össze más relációkkal, mivel ezek m: n típusú kapcsolatokat modellálnak. Az összevont relációkon kívül még megmaradt relációk ahhoz, hogy az adatbázisséma teljes legyen a közös kulcsú relációk összevonása után: Managerek (SzemSzám) Szállítók (SzállID, Név, Helység, UtcaSzám) Vevık (VevıID, Név, Helység, UtcaSzám, Mérleg) Szállít (SzállID, ÁruID, Ár) Szerepel (TételID, ÁruID, RendMenny, SzállMenny) A Managerek relációt esetleg elhagyhatnánk, ha nincs olyan managerünk, aki nem irányít részleget. Ha minden manager irányít egy részleget, akkor megtaláljuk ıket a Részlegek relációban.