a relációs adatbázisok és az sql -...

AA rreelláácciióóss aaddaattbbáázziissookk ééssaazz SSQQLLII

SQL_foldi_halandoknak01.qxd 2/10/2009 11:37 AM

„A tudás egy kis része annak a tudatlanságnak,amit rendszerezünk és osztályozunk.”

– Ambrose Bierce

AA ffeejjeezzeett ttéémmaakköörreeii• Az adatbázisok fajtái• A relációs modell rövid története• A relációs adatbázisok felépítése• Miért hasznosak számunkra a relációs adatbázisok?• Összefoglalás

Mielõtt fejest ugranánk az SQL világába, nem árt, ha rendelkezünk némi háttérinformációvala relációs adatbázisokról, ezért elõször arról fogunk beszélni, hogy miért találták ki a relációsadatbázisokat, hogyan épülnek fel, és miért hasznosak a számunkra. Ez az az alap, amelyenbiztosan kell állnunk, hogy megérthessük az SQL lényegét, és tisztán lássuk, hogy mikéntaknázhatjuk ki legjobban az SQL képességeit.

AAzz aaddaattbbáázziissookk ffaajjttááii

Mit nevezünk adatbázisnak? Amint azt bizonyára tudjuk, az adatbázis adatok rendezettgyûjteménye, amellyel valamilyen szervezett dolgot vagy szervezési folyamatot modelle-zünk. Tulajdonképpen nem számít, hogy papírt vagy egy számítógépes programot haszná-lunk az adatok összegyûjtésére és tárolására: amíg az adatokat konkrét célra, valamilyenrendezett formában gyûjtjük és tároljuk, adatbázisról beszélhetünk. A továbbiakban perszeazt fogjuk feltételezni, hogy az adatgyûjtésre és az adatok kezelésére számítógépprogramothasználunk.

Az adatbázis-kezelés területén általánosságban kétféle adatbázis van használatban:mûveleti adatbázisok és elemzõ adatbázisok. Ma szerte a világon mûveleti adatbázisokképezik számos vállalat, szervezet és intézmény gerincét. Ezt a fajta adatbázist elsõsorbanmindennapi adatgyûjtésre, -módosításra és -kezelésre használják. A tárolt adatok dinami-

MMiitt jjeelleenntt aazz,, hhooggyy „„rreelláácciióóss””??

11


kus adatok, ami azt jelenti, hogy folyamatosan változnak, és mindig friss információkattükröznek. Az olyan szervezetek, mint az áruházak, a gyártócégek, a kórházak és klinikák,valamint a könyvkiadók mûveleti adatbázisokat használnak, mivel az adataik percrõlpercre változnak.

Ezzel szemben az elemzõ adatbázisok korábbról származó, adott idõponthoz kapcsolódóadatokat tárolnak és rendszereznek. Az elemzõ adatbázisok a változások irányának nyomonkövetésében hasznosak, valamint a hosszú idõ alatt összegyûjtött statisztikai adatok megjele-nítését, illetve a taktikai és stratégiai üzleti elõrejelzések készítését segítik. Az ilyen adatbázis-ok statikus adatokat tárolnak, vagyis az adatok soha (vagy csak nagyon ritkán) módosulnak,új adatok felvételére viszont gyakran sor kerülhet. Az elemzõ adatbázisokból kinyert infor-mációk általában nem naprakészek: egy adott idõpontban készített pillanatfelvételt mutatnakaz adatokról. Ilyen fajta adatbázist használnak például a kémiai laboratóriumok, a földmérõvállalatok, illetve a piackutató és -elemzõ cégek.

AA rreelláácciióóss mmooddeellll rröövviidd ttöörrttéénneettee

Az adatbázismodelleknek többféle típusa létezik. Egyeseket – például a hierarchikus éshálózati modelleket – csak régi rendszereken használnak, míg mások – például a relációsmodell – széles körben elterjedtek. Más könyvekben az objektum alapú, objektumrelációsés OLAP (online analytical processing, elektronikus elemzõ-feldolgozó) modellekkel istalálkozhatunk. Az SQL-szabvány bõvítményeket határoz meg ezeknek a modellekneka támogatására, és léteznek kereskedelmi adatbázisrendszerek, amelyek meg is valósítanakegyes bõvítményeket ezek közül. Mi azonban szigorúan a relációs modellre és a nemzetkö-zi SQL-szabvány magjára fogunk összpontosítani.

AA kkeezzddeetteekkA relációs adatbázis elve 1969-ben született meg, és azóta valószínûleg a legszélesebbkörben használt modellé vált az adatbázis-kezelésben. A relációs modell atyja, Dr. EdgarF. Codd (1923–2003) az IBM kutatójaként dolgozott az 1960-as években, és azt vizsgálta,hogy milyen új módszerekkel lehet nagy adatmennyiségeket kezelni. Az akkor létezõadatbázismodellekkel és -termékekkel elégedetlen volt, ami arra indította, hogy matemati-kai elvek és szerkezetek segítségével próbálja meg megoldani az elõtte álló tömérdek fel-adatot. Matematikusként szilárdan hitt benne, hogy a matematikának léteznek olyan ágai,amelyeket alkalmazva megoldhatók az olyan problémák, mint az adatismétlõdés (redun-dancia) kiküszöbölése, az adatok egységességének biztosítása, illetve annak leküzdése,hogy az adatbázisok szerkezete túlzottan függjön a fizikai megvalósítástól.

Dr. Codd hivatalosan 1970 júniusában, az A Relational Model of Data for Large SharedDatabases címû, mérföldkõnek számító munkájában1 mutatta be az általa kidolgozott újrelációs modellt. A modell a matematika két ágára támaszkodott: a halmazelméletre és

44 SQL-lekérdezések földi halandóknak

1 Communications of the ACM, 1970. június, 377-87. oldal


az elsõrendû predikátumlogikára. Maga a modell is a halmazelmélet egyik kulcsfogalma,a reláció kifejezés után kapta a nevét. (Széles körben elterjedt tévedés, hogy a relációsmodell neve onnan ered, hogy a relációs adatbázisok táblái között kapcsolatok állhatnakfenn. Most, hogy tudjuk az igazságot, nyugodtan alhatunk.) Szerencsére nem kell részlete-iben ismernünk a halmazelméletet vagy az elsõrendû predikátumlogikát ahhoz, hogy re-lációs adatbázisokat tervezhessünk és használhassunk. Ha megfelelõ adatbázis-tervezésimódszert követünk – például a Mike Hernandez Database Design for Mere Mortals(Addison-Wesley, 2004; magyarul: Adatbázis-tervezés: A relációs adatbázisok alapjairólföldi halandóknak. Kiskapu, 2004) címû könyvében ismertetett eljárásokat –, egészségesés hatékony adatbázis-szerkezetet alakíthatunk ki, amelyet bizalommal használhatunkmindenféle adat összegyûjtésére és kezelésére. (Nos rendben, természetesen egy kicsitazért muszáj értenünk a predikátumokhoz és a halmazelmélethez, ha bonyolultabbfeladatokat is meg szeretnénk oldani. A predikátumokkal – állításokkal vagy szûrõkkel;a „predikátum” valójában csak egy fellengzõs név – kapcsolatos alapvetõ tudnivalókata 6., a halmazelmélet alapjait pedig a 7. fejezetben tárgyaljuk.)

AA rreelláácciióóss aaddaattbbáázziisspprrooggrraammookkMegjelenése óta a relációs modell az alapja az RDBMS (relational database managementsystem, relációs adatbázis-kezelõ rendszer) néven ismert adatbázistermékeknek. Ilyenterméket számos gyártó készít, és az évek során a legkülönbözõbb iparágak és szerveze-tek vették át a használatát, akik sokféle környezetben alkalmazzák. Az 1970-es évekbena nagyszámítógépek olyan programokat használtak, mint az IBM által kifejlesztettSystem R vagy a Berkeley-i Kaliforniai Egyetemen megalkotott INGRES. A nagygépekhezkészített RDMBS rendszerek fejlesztése az 1980-as években olyan programokkal folytató-dott, mint az Oracle Corporation Oracle, illetve az IBM DB2 rendszere, a személyi számí-tógépeknek az 1980-as évek közepén bekövetkezett elterjedése pedig olyan programokatszült, mint az Ashton Tate dBase, az Ansa Software Paradox vagy a Microrim R:BASEszoftvere. Amikor az 1980-as évek végén, illetve az 1990-es évek elején nyilvánvalóvávált, hogy igény mutatkozik a PC-k közötti adatmegosztásra, megszületett az ügyfél–ki-szolgáló rendszerek elve, amelyet a központi helyen tárolt, közösen használható,könnyen kezelhetõ és biztonságossá tehetõ adatok ötlete kísért. Erre az elvre olyantermékek épültek, mint az Oracle Oracle 8i, valamint a Microsoft SQL Server rendszere.Körülbelül 1996 óta már abban az irányban is összehangolt erõfeszítéseket tesznek, hogyaz adatbázisok elérhetõségét az Interneten is biztosítsák. A szoftvergyártók komolyanveszik a kérdést, és olyan termékekkel igyekeznek válaszolni a kihívásokra, amelyekwebközpontúbbak: ilyen az Allaire cég Cold Fusion, a Sybase Sybase EnterpriseApplication Studio vagy a Microsoft Visual Studio programcsomagja. A webfejlesztésbenaz egyik legnépszerûbb adatbázis-kezelõ a MySQL AB nyílt forrású MySQL-je. Ezt eredeti-leg Linux rendszerû webkiszolgálókhoz tervezték, de már Microsoft Windows rendszere-ken futó változata is létezik.

1. fejezet • Mit jelent az, hogy "relációs"? 55


AA rreelláácciióóss aaddaattbbáázziissookk ffeellééppííttééssee

A relációs modellnek megfelelõen az adatok a relációs adatbázisokban relációkban táro-lódnak, amelyeket a felhasználó táblák formájában érzékel. Minden reláció egyedekbõl(tuple, rekord) és jellemzõkbõl (mezõ) épül fel. Ezen kívül a relációs adatbázisoknaktermészetesen más tulajdonságaik is vannak – ezekkel foglalkozunk az alábbiakban.

TTáábblláákkA táblák az adatbázisok fõ szerkezeti elemei. Minden tábla mindig egyetlen konkrét tárgyatábrázol. A rekordok és mezõk logikai sorrendje a táblán belül egyáltalán nem számít.Legalább egy mezõt – az úgynevezett elsõdleges kulcsot, amely egyedileg azonosítja a táblaegyes rekordjait– minden táblának tartalmaznia kell. (Az 1.1. ábrán például a CustomerIDa Customers tábla elsõdleges kulcsa.) Valójában a relációs adatbázisokban levõ adatoka táblák ez utóbbi két tulajdonságának köszönhetõen függetlenek attól, hogy fizikailagmiként tárolódnak a számítógépen. Ez a felhasználóknak elõnyös, mert így ahhoz, hogykinyerjenek egy adatot, nem kell ismerniük az adatot tároló rekord fizikai helyét.

11..11.. áábbrraa

Példa egy táblára

A tárgy, amelyet egy adott tábla ábrázol, egy objektum vagy egy esemény lehet. Ha a tárgyegy objektum, a tábla valami olyat ábrázol, ami „megfogható”: egy személyt, egy helyetvagy más fizikai dolgot. Objektumokként táblában ábrázolhatók például pilóták, termékek,gépek, hallgatók, épületek, berendezések, és így tovább. A típusától függetlenül mindenobjektumnak vannak olyan jellemzõi, amelyek adatként tárolhatók, és ezeket az adatokataztán szinte végtelen módon lehet feldolgozni. Erre a fajta táblára az 1.1. ábra mutat jelleg-zetes példát.

Amennyiben a tábla tárgya egy esemény, a tábla valami olyasmit ábrázol, ami egy adottidõpontban történt, illetve történik (majd), és olyan jellemzõi vannak, amelyeket rögzíteniszeretnénk. Ezeket a jellemzõket pontosan ugyanúgy tárolhatjuk adatként, és dolgozhatjukfel mint információt, mint azokban a táblákban, amelyek valamilyen konkrét objektumot



írnak le. Olyan eseményeket rögzíthetünk például, mint a bírósági tárgyalások, az osztalék-kifizetés, a laborleletek vagy egy földtani mérés. Az 1.2. ábrán például egy olyan eseménytábrázoló táblát láthatunk, amelyet életünk során mindnyájan átélünk – egy orvosi vizetet.

11..22.. áábbrraa

Eseményt ábrázoló tábla

MMeezzõõkkA mezõ az adatbázis legkisebb szerkezeti egysége, amely a hozzá tartozó tábla tárgyánakegy jellemzõjét írja le. A mezõk azok a szerkezetek, amelyek az adatokat ténylegesentárolják. A mezõkben levõ adatokat azután kinyerhetjük és információként megjeleníthet-jük, szinte bármilyen elképzelhetõ formában. Véssük az eszünkbe, hogy az adatokbólkinyert információk minõsége egyenesen arányos az idõ mennyiségével, amit arra fordí-tunk, hogy maguknak a mezõknek az adat- és szerkezeti következetességét biztosítsuk.A mezõk fontosságát nem lehet túlbecsülni.

Egy megfelelõen megtervezett adatbázisban minden mezõ kizárólag egyetlen értékettartalmaz, és a neve azonosítja a benne tárolt érték típusát. Így nagyon egyszerûvé válikaz adatok bevitele a mezõkbe: ha olyan nevû mezõket látunk, mint a FirstName (Kereszt-név), a LastName (Vezetéknév), a City (Város), a State (Állam/Megye) vagy a ZipCode(Irányítószám), pontosan tudni fogjuk, hogy milyen értéket kell írnunk az egyes mezõkbe,és az adatok rendezése (például állam szerint) vagy az összes olyan személy kikeresése,akinek a vezetékneve Viescas, ugyancsak könnyû lesz.

RReekkoorrddookkA rekord egy adott tábla tárgyának egy egyedi példányát jelképezi, amely a tábla adottsorában található összes mezõt tartalmazza, függetlenül attól, hogy az egyes mezõkbenszerepelnek-e értékek. A táblák meghatározásának módjából következik, hogy mindenrekordot egy egyedi érték azonosít a teljes adatbázisban, és ez az érték a rekord elsõdle-ges kulcs mezõjében tárolódik.

Az 1.1. ábrán például minden rekord egy-egy különbözõ vásárlót jelöl a táblában, ésaz adatbázisban az egyes vásárlókat a CustomerID (Vásárlóazonosító) mezõ azonosítja.Amint említettük, az egyes rekordok a tábla adott sorában található összes mezõt tartal-



mazzák, és minden mezõ egy-egy tulajdonságát írja le a rekord által ábrázolt vásárlónak.A rekordok kulcsfontosságúak a táblakapcsolatok megértésében, mivel tudnunk kell,hogy egy tábla rekordjai milyen viszonyban állnak egy másik tábla rekordjaival.

KKuullccssookkA kulcsok különleges mezõk, amelyek meghatározott szerepet töltenek be az egyes táblák-ban. Ezt a szerepet a kulcs típusa határozza meg. Bár egy tábla többféle kulcsot tartalmaz-hat, mi csak a két legfontosabb típust tárgyaljuk: az elsõdleges kulcsot és az idegen kulcsot.

Az elsõdleges kulcs olyan mezõ vagy mezõcsoport, amely egyedileg azonosítja a táblábantalálható összes rekordot. (Ha az elsõdleges kulcs két vagy több mezõbõl áll, összetettelsõdleges kulcsról beszélünk.) Két oka van annak, hogy miért az elsõdleges kulcs a legfon-tosabb: az értéke egy konkrét rekordot azonosít a teljes adatbázisban, a mezõje pedigugyanott egy adott táblát. Az elsõdleges kulcsok emellett a tábla szintjén biztosítjáka következetességet, és segítenek kapcsolatokat kialakítani más táblákkal. Az adatbázisainkminden táblájának rendelkeznie kell elsõdleges kulccsal.

Az 1.3. ábrán látható AgentID (Ügynökazonosító) mezõ jó példa az elsõdleges kulcsra, mertegyedileg azonosítja az egyes ügynököket az Agents (Ügynökök) táblán belül, és a többszörszereplõ rekordok kiküszöbölésével gondoskodik a táblaszintû következetességrõl.A kulcsot ezenkívül arra is használjuk, hogy az Agents és az adatbázis más táblái (például –ahogy az ábrán láthatjuk – az Entertainers tábla) között kapcsolatokat alakítsunk ki.

11..33.. áábbrraa

Elsõdleges és idegen kulcsok

Amikor eldöntjük, hogy két táblát valamilyen módon összekapcsolunk, a kapcsolatotáltalában úgy hozzuk létre, hogy az elsõ tábla elsõdleges kulcsát lemásoljuk és beszúrjuka második táblába, ahol az idegen kulcs lesz. (Az idegen kulcs kifejezés onnan ered, hogya második táblának már van saját elsõdleges kulcsa, és az elsõ táblából átvett elsõdlegeskulcs a második tábla számára „idegen”.)



Az 1.3. ábrán egy jó példát láthatunk az idegen kulcsra. A példában az AgentID elsõdlegeskulcs az Agents táblában és idegen kulcs az Entertainers táblában. Amint láthatjuk,az Entertainers táblának már van egy elsõdleges kulcsa – az EntertainerID. Ebbena kapcsolatban az AgentID az a mezõ, amely megteremti az összefüggést az Agents ésaz Entertainers tábla között.

Az idegen kulcsok nem csak abból a nyilvánvaló szempontból fontosak, hogy segítenekkapcsolatot teremteni két tábla között, hanem azért is, mert biztosítják a kapcsolatszintûkövetkezetességet, vagyis a két tábla rekordjai mindig helyes kapcsolatban fognak állniegymással, mivel az idegen kulcs mezõ értékeinek a hivatkozott elsõdleges kulcs értékei-bõl kell származniuk. Az idegen kulcsok a rettegett „árva rekordokat” is segítenek elkerül-ni, amelyek klasszikus példája egy olyan rendelési rekord, amelyhez nem tartozik vásárló.Ha nem tudjuk, ki adta fel a rendelést, nem leszünk képesek feldolgozni azt, és természe-tesen kiszámlázni sem tudjuk, ami rontja a negyedéves eladási mutatóinkat.

NNéézzeettttáábblláákkA nézet vagy nézettábla olyan virtuális tábla, amely az adatbázis egy vagy több táblájánakmezõibõl épül fel. A nézettáblát alkotó táblákat alaptábláknak hívjuk. A relációs modellazért tekinti virtuálisnak (látszólagosnak) a nézettáblákat, mert azok adatai más táblákbólszármaznak. Maguk a nézettáblák nem tárolnak adatokat; az adatbázisban valójábana szerkezetük az egyetlen információ, ami tárolódik róluk.

A nézettáblák lehetõvé teszik, hogy az adatbázisban tárolt információkat számos különféleszempontból tekintsük meg, ami nagy rugalmasságot nyújt az adatok kezelésében. Nézet-táblákat többféleképpen is létrehozhatunk – különösen akkor hasznosak, amikor több,egymással kapcsolatban álló táblára alapozzuk õket. Létrehozhatunk például egy olyannézettáblát, amelyik olyan információkat összegez, mint a Seattle belvárosában dolgozóácsok által ledolgozott órák teljes száma, vagy egy olyat, amelyik adott mezõk szerintcsoportosítja az adatokat. Ez utóbbi fajtára jó példa egy olyan nézettábla, amelyik egy adottterület államait veszi alapul, hogy megmutassa az egyes városokban az alkalmazottak teljesszámát. A nézettáblák jellemzõ felépítését az 1.4. ábrán láthatjuk.

Sok RDBMS program a nézettáblákat mentett lekérdezésként valósítja meg, és ezen a né-ven vagy egyszerûen lekérdezésként hivatkozik rájuk. A lekérdezések a legtöbb esetbenrendelkeznek a nézettáblák minden jellemzõjével, vagyis csupán a nevük az egyetlen kü-lönbség köztük. (Mi már gyakran morfondíroztunk rajta, hogy ehhez nem egy marketing-csapatnak van-e köze.) Fontos megjegyezni, hogy egyes gyártók már kezdik a valódi ne-vükön nevezni a lekérdezéseket, de mindegy, hogy a mi relációs adatbázis-kezelõnkhogy hívja õket, az adatbázisban valójában nézettáblákkal dolgozunk.

Könyvünk címe ettõl függetlenül SQL-lekérdezések földi halandóknak, miközben elsõsor-ban azt szeretné megtanítani, hogy miként építsük fel a nézettábláinkat. Ahogy a 2. feje-zetbõl majd megtudhatjuk, egy relációs adatbázist akkor tervezünk meg helyesen, ha



az adatainkat úgy bontjuk fel, hogy minden tárgyhoz vagy eseményhez egyetlen tábla tar-tozzon. Ugyanakkor többnyire összefüggõ tárgyakról vagy eseményekrõl szeretnénk in-formációt szerezni – mely vásárlók és milyen rendelést adtak fel, mely tanárok milyenórákat tartanak, és így tovább –, ehhez pedig nézettáblát kell létrehoznunk, és tudnunkkell, hogy milyen SQL kóddal érhetjük ezt el.

11..44.. áábbrraa

Példa egy nézettáblára

KKaappccssoollaattookkHa egy adott tábla rekordjai valamilyen módon egy másik tábla rekordjaihoz társíthatók,azt mondjuk, hogy a táblák között kapcsolat áll fenn. A kapcsolat megteremtésének módjaa kapcsolat típusától függ. Két tábla között háromféle kapcsolat állhat fenn: egy-az-egyhez,egy-a-többhöz (egy-a-sokhoz) vagy több-a-többhöz (sok-a-sokhoz) A kapcsolatok fajtáinakismerete létfontosságú ahhoz, hogy megértsük, hogyan mûködnek a nézettáblák, és hogymiként kell a többtáblás SQL-lekérdezéseket megtervezni és használni. (Errõl a III. részbentanulunk majd bõvebben.)

EEggyy--aazz--eeggyyhheezzKét tábla akkor áll egy-az-egyhez kapcsolatban, ha az elsõ tábla egy rekordja a másodiktábla egyetlen rekordjához kapcsolódik, és a második tábla egy rekordja is egyetlen rekord-dal áll kapcsolatban az elsõ táblából. Ebben a fajta kapcsolatban az egyik tábla elsõdlegestábla, míg a másik másodlagos tábla lesz. A kapcsolatot úgy hozzuk létre, hogy vesszük



az elsõdleges tábla elsõdleges kulcsát, és beszúrjuk azt a másodlagos táblába, ahol idegenkulcs lesz belõle. Ez a kapcsolatok különleges fajtája, mivel sok esetben az idegen kulcsegyben a másodlagos tábla elsõdleges kulcsaként is viselkedik.

Az egy-az-egyhez kapcsolatra az 1.5. ábrán láthatunk egy jellemzõ példát: itt az Agents(Ügynökök) az elsõdleges, a Compensation (Díjazás) pedig a másodlagos tábla. A két táblaközött olyan kapcsolat áll fenn, amelyben az Agents tábla egy-egy rekordja csak egy-egyrekordhoz kapcsolódik a Compensation táblában, és a Compensation tábla egy-egy rekordjais csak egy-egy rekordhoz társul az Agents táblából. Figyeljük meg, hogy az AgentID való-ban elsõdleges kulcs mindkét táblában, de egyben idegen kulcs a másodlagos táblában.

A kapcsolatban a vezetõ szerepet játszó elsõdleges tábla kijelölése teljesen tetszõleges.Az egy-az-egyhez kapcsolatok nem túl gyakoriak; általában akkor találkozunk velük, haegy táblát titkosítás végett két részre bontottak.

11..55.. áábbrraa

Példa egy-az-egyhez kapcsolatra

EEggyy--aa--ttööbbbbhhöözzHa két tábla egy-a-többhöz kapcsolatban áll, akkor az elsõ tábla egy rekordja a másodiktábla több rekordjához is kapcsolódhat, de a második tábla egy rekordja csak egyetlenrekorddal állhat kapcsolatban az elsõ táblából. Ezt a kapcsolatot úgy hozzuk létre, hogyvesszük a kapcsolat „egy” oldalán álló tábla elsõdleges kulcsát, és beszúrjuk azt a „több”oldalon levõ táblába, ahol idegen kulcs lesz belõle.

Az egy-a-többhöz kapcsolatra az 1.6. ábrán láthatunk egy jellemzõ példát: itt az Entertainers(Elõadók) tábla egy-egy rekordja több rekordhoz kapcsolódik az Engagements (Rendezvé-nyek) táblában, de az Engagements tábla egy-egy rekordja csak egyetlen rekordhoz társulaz Entertainers táblából. Ahogy nyilván kitaláltuk, az Engagements tábla idegen kulcsaaz EntertainerID.



11..66.. áábbrraa

Példa egy-a-többhöz kapcsolatra

TTööbbbb--aa--ttööbbbbhhöözzKét tábla akkor áll több-a-többhöz kapcsolatban, ha az elsõ tábla egy rekordja a másodiktábla több rekordjához kapcsolódik, és a második tábla egy rekordja is több rekorddal állkapcsolatban az elsõ táblából. Ezt a kapcsolatot helyesen úgy hozzuk létre, hogy létreho-zunk egy úgynevezett kapcsoló táblát. Ennek a táblának a segítségével egyszerûen társít-hatunk rekordokat az egyik táblából a másik tábla rekordjaihoz, és a kapcsoló tábla arrólis gondoskodik, hogy a kapcsolódó adatok hozzáadása, törlése vagy módosítása soránsemmilyen gond ne lépjen fel. A kapcsoló táblát úgy határozzuk meg, hogy lemásoljuka kapcsolatban részt vevõ mindkét tábla elsõdleges kulcsát, és ezek segítségével alkotjukmeg az új tábla szerkezetét. A kulcsmezõk két jól elkülöníthetõ szerepet töltenek be:együttesen a kapcsoló tábla összetett elsõdleges kulcsát adják, külön-külön pedig idegenkulcsokként viselkednek.

11..77.. áábbrraa

Feloldatlan több-a-többhöz kapcsolat



Ha egy több-a-többhöz kapcsolat nem megfelelõen jött létre, feloldatlan kapcsolatrólbeszélünk. Erre az 1.7. ábrán láthatunk egy világos példát. Itt a Customers (Megrendelõk)tábla egy-egy rekordja az Entertainers tábla több rekordjához kapcsolódhat, és az Enter-tainers tábla egy-egy rekordja is a Customers tábla több rekordjához.

A kapcsolat a több-a-többhöz viszonyban rejlõ probléma miatt lesz feloldatlan. A kérdésez: miként társíthatjuk egyszerûen az elsõ tábla rekordjait a második tábla rekordjaihoz?Ha a kérdést az 1.7. ábrán látható táblák szerint fogalmazzuk újra, a probléma ez lesz:hogyan társíthatunk egy megrendelõt több elõadóhoz vagy egy adott elõadót több meg-rendelõhöz? (Ha egy szórakoztatóügynökséget vezetünk, bizonyára azt reméljük, hogyidõvel minden megrendelõ több elõadót is leköt, illetve az egyes elõadók fellépéseire istöbben lesznek kíváncsiak.) Beszúrjuk pár megrendelõ mezõjét az Entertainers táblába?Vagy adjunk néhány elõadómezõt a Customers táblához? Mindkét megoldás számos prob-lémát eredményez, amikor a kapcsolódó adatokkal dolgozunk, elsõsorban az adatokkövetkezetessége terén. A problémára az a megoldás, hogy a korábban ismertetett módonlétrehozunk egy kapcsoló táblát, amellyel megfelelõen feloldhatjuk a több-a-többhöz kap-csolatot. A megoldás gyakorlati megvalósítását az 1.8. ábra mutatja.

11..88.. áábbrraa

Megfelelõen feloldott több-a-többhöz kapcsolat

Az 1.8. ábrán a kapcsoló táblát úgy hoztuk létre, hogy vettük a CustomerID mezõt a Cus-tomers táblából, valamint az EntertainerID mezõt az Entertainers táblából, és ezekbõl alkot-tuk meg az új táblát. Az adatbázis más tábláihoz hasonlóan a kapcsoló táblának is saját ne-



ve van: Engagements (Rendezvények). Az Engagements tábla jó példa egy olyan táblára,amely egy eseményrõl tárol információkat. Láthatjuk például, hogy az 1003-as elõadó (JV& the Deep Six) a 10001-es megrendelõnél (Doris Hartwig) lépett fel február 23-án. A kap-csoló tábla igazi elõnye, hogy lehetõvé teszi, hogy a kapcsolatban részt vevõ mindkét táb-lából tetszõleges számú rekord között teremtsünk kapcsolatot. Ahogy a példa is mutatja,most már egyszerûen összekapcsolhatunk egy adott megrendelõt tetszõleges elõadókkalvagy egy adott elõadót akárhány megrendelõvel.

Ahogy korábban mondtuk, a kapcsolatok megértése nagyon fontos ahhoz, hogy hatékonytöbbtáblás SQL-lekérdezéseket írjunk, ezért amikor elérünk a könyv III. részéhez, érdemesvisszalapozni ide, és felfrissíteni az emlékezetünket.

MMiiéérrtt hhaasszznnoossaakk sszzáámmuunnkkrraa aa rreelláácciióóss aaddaattbbáázziissookk??

De miért is kell törõdnünk azzal, hogy megértsük a relációs adatbázisokat? Miért érdekeljenminket, hogy milyen környezetben kezeljük az adatainkat? És egyáltalán: miért hasznosakszámunkra a relációs adatbázisok? Nos, ideje, hogy megvilágosítsuk az elménket, és fejestugorjunk a mélyvízbe!

Az idõ, amit a relációs adatbázisok tanulmányozására fordítunk, olyan befektetés, amiegyértelmûen megtérül. Aktív tudásra kell szert tennünk a relációs adatbázisokkal kapcso-latban, mivel ma ez a legszélesebb körben elterjedt adattárolási modell. Felejtsük el, amitkorábban olvastunk a témáról vagy amit Huba az informatikai részlegrõl mondott nekünk– a cégek és különféle szervezetek által gyûjtött és kezelt adatok túlnyomó többségét relá-ciós adatbázisokban tárolják. A modellnek valóban léteznek bõvítései, a relációs adatbázi-sokat kezelõ programok ma már objektumközpontú megoldásokat is alkalmaznak, ésaz ilyen adatbázisok mára teljesen beépültek a Világháló szövetébe, de nem számít, hogycsûrjük-csavarjuk, aprítjuk és fûszerezzük, ezek az adatbázisok ettõl még relációs adat-bázisok maradnak. A relációs modell 35 éve velünk él, a szerepe csak egyre erõsödik, ésbelátható idõn belül nem lesz, ami felváltsa.

Szinte minden ma használt kereskedelmi adatbázis-kezelõ szoftver relációs alapokonnyugszik (bár Dr. Codd, C.J. Date és Fabian Pascal komolyan megkérdõjeleznék, hogybármelyik kereskedelmi megvalósítás valóban relációs-e!). Ha adatbázisokkal dolgozunk,és sikert szeretnénk elérni, tudnunk kell, hogyan kell megtervezni egy relációs adatbázist,és hogyan kell azt megvalósítani valamelyik népszerû RDBMS programban – ráadásulazóta, hogy oly sok cég folytat üzleti tevékenységet az Interneten, némi webfejlesztésitapasztalat sem árt.

A relációs adatbázisok gyakorlati ismerete több szempontból is a segítségünkre lehet. Minéltöbbet tudunk például a relációs adatbázisok tervezésérõl, annál könnyebben tudunk majdegy adott adatbázishoz felhasználói alkalmazásokat fejleszteni. Meg fogunk lepõdni, milyen



egyszerûvé válik az RDBMS programunk használata – mivel értjük, hogy mire szolgálnakaz egyes eszközei, és hogyan használhatjuk azokat a leghatékonyabban. Gyakorlati isme-reteinknek akkor is jó hasznát vesszük, amikor az SQL használatát igyekszünk elsajátítani,hiszen az SQL a relációs adatbázisok létrehozásának és kezelésének szabványos nyelve.

HHooggyyaann ttoovváábbbb??Már értjük, hogy miért fontos megismerkednünk a relációs adatbázisokkal, de azt is lát-nunk kell, hogy az adatbázisok elmélete és az adatbázisok tervezése két különbözõ dolog.Az adatbázisok elméletét azok az elvek és szabályok alkotják, amelyeken a relációs adat-bázismodell alapul: ez az, amit az iskolák szentélyeiben oktatnak, és amit a valóság sötétbugyraiban gyorsan el kell hajítanunk. Az elmélet persze fontos, mert nélküle nem készít-hetnénk szerkezetileg helyes relációs adatbázisokat, és az adatbázisaink adatain végzettmûveletek eredménye sem lenne megjósolható. Ezzel szemben viszont az adatbázisoktervezése azokat a strukturált folyamatokat foglalja magába, amelyek révén egy relációsadatbázis felépül. A helyes adatbázis-tervezési módszerek ismerete elengedhetetlen ahhoz,hogy pontos és következetes adatokat tartalmazó adatbázisokat hozzunk létre, illetve hogya kinyert információk is a lehetõ legpontosabbak és legfrissebbek legyenek.

Ha teljes vállalatra kiterjedõ adatbázisokat szeretnénk tervezni és létrehozni, webes alapúinternetes üzleti adatbázisokat akarunk fejleszteni, vagy adattárakat kívánunk üzemeltetni,célszerû megfontolni az adatbázisok elméletének tanulmányozását. Ez akkor is érvényes, haaz említett területek egyikében sem akarunk elmerülni, csak elismert adatbázis-szakértõvészeretnénk válni. Mindenki másnak, aki relációs adatbázisokat tervez és készít különbözõrendszerekre (és úgy véljük, õk teszik ki e könyv olvasóinak nagy többségét), a helyes adat-bázis-tervezési módszerek alapos ismerete elegendõ. Ne feledjük, hogy egy adatbázist meg-tervezni viszonylag könnyû, de megvalósítani azt egy adott RDBMS programban egy adottrendszerre már teljesen más tészta (amit más könyvekbõl sajátíthatunk el).

A piacon számos jó könyvet találunk az adatbázis-tervezésrõl. Egyesek, például MikeHernandez Database Design for Mere Mortals címû könyve (Addison-Wesley, 2004; ma-gyarul: Adatbázis-tervezés: A relációs adatbázisok alapjairól földi halandóknak. Kiskapu,2004) csak az adatbázis-tervezés módszertanával foglalkoznak, míg mások, például C.J.Date An Introduction to Database Systems (Addison-Wesley, 2003) címû mûve, keverikaz elméletet és a gyakorlati tervezést. (Arra viszont fel kell hívnunk a figyelmet, hogyaz elméleti könyvek általában nem könnyû olvasmányok.) Miután eldöntöttük, hogy mi-lyen irányban szeretnénk továbbhaladni, válasszuk ki és vegyük meg a megfelelõ könyve-ket, fogjunk egy csésze dupla eszpresszót (vagy ha más kedvenc italunk van, akkor azt),és merüljünk el bennük. Ha már általánosságban magabiztosan mozgunk a relációs adat-bázisok körében, rá fogunk jönni, hogy mélyebben meg kell ismerkednünk az SQL-lel is– ezért olvassuk ezt a könyvet.



ÖÖsssszzeeffooggllaallááss

A fejezetet a ma használatos adatbázisok különbözõ típusainak rövid ismertetésével kezd-tük. Megtudtuk, hogy a dinamikus adatokkal dolgozó vállalatok és intézmények mûveletiadatbázisokat használnak, és így biztosítják, hogy a kinyert információk mindig a lehetõlegfrissebbek és legpontosabbak legyenek, míg a statikus adatokat kezelõ szervezetekelemzõ adatbázisokat alkalmaznak.

Ez után röviden áttekintettük a relációs adatbázismodell történetét. Elmeséltük, hogya modellt Dr. E. F. Codd alkotta meg a matematika egyes ágaira alapozva, és hogya modell már több mint 35 éve létezik. Adatbázis-kezelõ programokat, ahogy ma ismerjükõket, különféle számítógépes környezetekhez készítenek, a teljesítményük, a hatékony-ságuk és a képességeik köre pedig az 1970-es évek óta folyamatosan nõ. A nagygépektõlaz asztali és webes alkalmazásokig sok-sok vállalat gerincét RDBMS programok képezik.

Ezt követõen a relációs adatbázisok felépítését vizsgáltuk. Bemutattuk az alapvetõ összete-võiket, és röviden elmagyaráztuk a szerepüket. Tanultunk a kapcsolatok három lehetségestípusáról, és megértettük, miért fontosak, nem csak magának az adatbázis szerkezeténeka szempontjából, hanem abból a szempontból is, hogy miként segítik az SQL mûködésé-nek jobb megértését.

Végül elmagyaráztuk, hogy milyen hasznunk származik a relációs adatbázisok tanulmányo-zásából, és hogy miként kell megtervezni õket. Most már tudjuk, hogy a ma használatosadatbázisok közül a relációs adatbázisok a legelterjedtebbek, és szinte minden adatbázis-kezelõ szoftver mögött, amivel találkozhatunk, egy relációs adatbázis áll. Ezen kívül arról isképet kaptunk, hogy merre haladhatunk, ha kicsit többet szeretnénk tudni a relációs adat-bázisok elméletérõl és tervezésérõl.

A következõ fejezetben arra tanulunk meg néhány módszert, hogy miként finomhangol-hatunk meglevõ adatbázis-szerkezeteket.



a relációs adatbázisok és az sql -...

Documents