Adatbázis kezelő rendszer

Az adatbázis -kezelő rendszer vagy DBMS ( angolul : Data Base Management System vagy DBMS) olyan szoftver, amely lehetővé teszi az adatbázisok kezelését . Ez azt jelenti, hogy ezen a programon keresztül használhatja, konfigurálhatja és kivonhatja a tárolt információkat . A felhasználók az információkhoz speciális lekérdező és jelentéskészítő eszközökkel, vagy erre a célra szolgáló alkalmazásokon keresztül férhetnek hozzá.

Ezek a rendszerek módszereket biztosítanak az adatok integritásának megőrzésére, a felhasználók adatokhoz való hozzáférésének kezelésére, valamint az információk helyreállítására, ha a rendszer megsérül. Lehetővé teszik az adatbázis információinak különböző formátumokban történő megjelenítését. A legtöbb tartalmaz jelentésgenerátort. Tartalmazhatnak egy grafikus modult is, amely lehetővé teszi az információk grafikonokkal és táblázatokkal történő bemutatását.

Az adatokhoz általában lekérdezési nyelveken, magas szintű nyelveken keresztül lehet hozzáférni, amelyek leegyszerűsítik az alkalmazások létrehozásának feladatát. Leegyszerűsítik a lekérdezéseket és az információk megjelenítését is. A DBMS lehetővé teszi az adatokhoz való hozzáférés szabályozását, integritásának biztosítását, az egyidejű hozzáférés kezelését, az adatok helyreállítását rendszerhiba után és biztonsági másolatok készítését. Az adatbázisok és kezelési rendszereik minden üzleti területen nélkülözhetetlenek, és gondosan kell kezelni őket.

Bevezetés

Az adatbázisok általában kizárólag erre a területre szánt számítógépeken futnak. A szükséges funkciók miatt általában többprocesszoros , sok memóriával rendelkező számítógépeken futnak .

Adattároláshoz rendelkezhet saját lemezrendszerekkel vagy közvetlenül csatolt tárolóval ( DAS ), csatlakozhat tárolóhálózathoz ( SAN ) vagy hálózati tárolórendszerhez ( NAS ).

Vannak hardveres gyorsítók , amelyeket nagy tranzakciófeldolgozó rendszerekben használnak. A DBMS minden adatkezelő alkalmazás középpontjában áll. A DBMS-ek szabványos operációs rendszereken alapulnak ezen funkciók végrehajtására.

Előzmények

Az adatbázisokat az elektronikus számítógépek kezdete óta használják. Ellentétben a modern rendszerekkel, amelyek nagyon különböző adatokra és igényekre alkalmazhatók, az eredeti rendszerek többsége meghatározott adatbázisokra összpontosított, és úgy tervezték, hogy a rugalmasság elvesztése árán gyorsítsanak fel. Az eredeti DBMS-ek csak olyan nagy szervezetek számára voltak elérhetőek, amelyek megengedhették maguknak a szükséges összetett számítógépeket.

Navigációs rendszerek (1960)

A számítógépek felgyorsulásával és kapacitásával megjelentek az általános célú adatbázis-rendszerek; az 1960-as évek közepén néhány rendszer már használatban volt. Felkelt az érdeklődés egy szabvány iránt, és Charles Bachman – az egyik első termék, az Integrated Data Store (IDS) szerzője – megalapította a Database Task Groupot a CODASYL -on belül, amely a COBOL létrehozásáért és szabványosításáért felelős csoport. 1971-ben adták ki szabványukat, amely a "CODASYL megközelítés" néven vált ismertté, és hamarosan megjelentek az ezen a vonalon alapuló termékek.

A CODASYL stratégiája a hálózati adatkészleten keresztüli kézi navigáción alapult. Az adatbázis indításakor a program egy hivatkozást adott vissza az adatbázis első rekordjára, amely viszont más adatokra mutató mutatókat tartalmazott. Egy adott rekord megtalálásához a programozónak követnie kellett a mutatókat, amíg el nem érte a keresett rekordot.

Az olyan egyszerű kérdések megválaszolásához, mint a „minden ember megkeresése Japánban”, a programnak át kellett mennie az összes adaton a megfelelő rekordok kiválasztásához. Nem létezett olyan, hogy „keres” vagy „talál”, ami ma már elfogadhatatlan, de azokban az időkben, amikor az adatokat szalagon tárolták, nem volt megvalósítható a gyakorlatban.

Sok ilyen problémára megoldást találtak. A gyártó Prime egy CODASYL-re igazított DBMS-t hozott létre bináris fák alapján, amely lerövidítette a navigációt a rekordtól a rekordig, alternatív hozzáférési útvonalakat biztosítva. Nagyon világos lekérdezési nyelvet is biztosított. Valójában nincs ok arra, hogy a normalizálási koncepciókat miért ne lehetne alkalmazni a CODASYL adatbázisokra, de a CODASYL végül nagyon összetett volt, és sok erőfeszítést és gyakorlatot igényelt egy hasznos alkalmazás létrehozásához.

1968-ban az IBM-nek is volt saját adatbázis-kezelője, IMS néven . Ez egy szoftver volt, amelyet az Apollo programhoz fejlesztettek ki a System/360-on. Az IMS a CODASYL-hez hasonló koncepciókkal rendelkezett, de szigorú adatsorrendi hierarchiát alkalmazott, szemben a CODASYL hálózati struktúrájával. Mindkét fogalom később az adatokhoz való hozzáférés módja miatt bekerült a navigációs adatbázisok fogalmába, valójában Bachman 1973-ban Turing-díjat kapott A programozó mint böngésző című írásáért . ]

Relációs rendszerek (1970)

Példa egy táblázatra a relációs modellben .

Edgar Codd az IBM-nél dolgozott, azon perifériairodák egyikében, amelyek főként merevlemezek fejlesztésével foglalkoztak. Elégedetlen voltam a CODASYL navigációs modellel, főleg a keresési művelet hiánya miatt. 1970-ben írt néhány cikket, amelyek egy új megközelítést vázoltak fel, amely az "Adatok relációs modellje a nagy megosztott adatbankok számára" című dokumentumban csúcsosodott ki. ]

Ebben a cikkben egy új rendszert fedezett fel nagy adatbázisok tárolására és kezelésére. Ahelyett, hogy tetszőleges típusú rekordokat láncolt listában tárolt volna, mint a CODASYL-ben, Codd ötlete az volt, hogy rögzített méretű rekordokat használjon. A láncolt lista nagyon gyenge hatékonyságú ritka adatok tárolásakor, ahol a rekord egyes adatai üresen maradhatnak. A relációs modell ezt úgy oldja meg, hogy az adatokat normalizált táblákra – vagy kapcsolatokra – osztja fel, ahol az opcionális elemeket a főtáblából kinyertük, így azok csak szükség szerint foglalnak helyet. Ebben a relációs modellben a kapcsolódó rekordok egy „kulccsal” vannak összekapcsolva.

Az adatbázisok általános felhasználása lehet a felhasználók névjegyzékének vezetése, nevük, hozzáférési információik, címük és telefonszámuk. A navigációs megoldásban az összes adat egyetlen rekordban található, és a nem használt szolgáltatások egyszerűen nem lennének az adatbázisban. A relációs megoldásban egy felhasználói táblában, egy telefon- és egy címtáblázatban normalizálnák az adatokat, amelyekbe a telefon és a cím beépítése esetén rekordok kerülnének.

Az összes információ egyeztetése a kulcsa ennek a rendszernek. A relációs modellben az információ egy része kulcsként használatos, amely egyértelműen azonosít egy adott rekordot. Amikor egy felhasználóra vonatkozó információkat gyűjtenek, az opcionális táblázatokban szereplő információk az adott kulcs használatával történő kereséssel érhetők el. Például, ha a felhasználónév egyedi, akkor a rendszer a felhasználó címét és telefonszámát a felhasználónévvel együtt tárolja jelszóként. Ezeknek az információknak egyetlen rekordba történő összeállítása olyasvalami, amire a hagyományos nyelveket nem szánják.

Ahogy a navigációs megközelítéshez olyan programok szükségesek, amelyek rekordokat gyűjtenek, a relációs megközelítés is megköveteli ezeket. A Codd megoldása a szükséges ciklusokra egy halmazorientált nyelven alapul, amely javaslat később a mindenütt jelen lévő SQL-ben kristályosodik ki. Javaslatot tett az algebra egy ágának, a sorszámításnak nevezett ágának alkalmazására, és megmutatta, hogy ezzel az adatbázison az összes tipikus művelet elvégezhető, az adathalmazok egyszerű kinyerése mellett.

Codd cikke két berkeley-i ember, Eugene Wong és Michael Stonebraker kezébe került. Elindítottak egy INGRES nevű projektet egy hallgatói programozású földrajzi adatbázis projektre elkülönített forrásból. 1973-tól kezdve az INGRES elkészítette első tesztverzióit, amelyek 1979-ben álltak készen az általános használatra. Az INGRES több szempontból is nagyon hasonlított az IBM System R -re, beleértve a QUEL néven ismert adatelérési nyelvet is. Idővel az INGRES átvette az SQL szabványt.

Az IBM elkészítette a relációs modell – PRTV – tesztimplementációját és a termelési modellt – a Business System 12 – mindkettőt leállították. A Honeywell megírta az MRDS-t a Multics számára, és két új implementáció is megjelenik: Alphora Dataphor és Rel . A legtöbb más úgynevezett relációs DBMS megvalósítás valójában SQL DBMS.

Az 1970 - es években a Michigani Egyetem megkezdte a MICRO információkezelő rendszer fejlesztését DL Childs elméleti adatmodellje alapján. A Micro -t nagy mennyiségű adat kezelésére használták az Egyesült Államok kormányának Munkaügyi Minisztériumában. A nagyszámítógépen a Michigan Terminal System segítségével futott . 1998 - ig gyártották .

SQL rendszerek (1970-es évek vége)

Az IBM az 1970-es évek elején kezdett dolgozni egy prototípuson, amely lazán Codd koncepcióira épült, System R-nek nevezve. Az első verzió 1974-ben vagy 1975-ben készült el, így elkezdett dolgozni többtáblás rendszereken, amelyekben az adatokat véletlenszerűen le lehetett bontani. hogy a rekordban lévő összes információt (amelyek egy része nem kötelező) nem kell egyetlen nagy darabban tárolni. A következő többfelhasználós verziókat tesztelték a felhasználók 1978-ban és 1979-ben, amikorra egy SQL nyelvet szabványosítottak. A Codd ötletei működőképesnek és jobbnak bizonyultak a CODASYL-nél, és elindították az IBM-et a System R valódi éles verziójának kifejlesztésében, amely SQL/DS, majd később Database 2 (DB2) néven ismert.

Az INGRES technikusai közül sokan biztosak voltak a rendszer kereskedelmi sikerében, és saját céget alapítottak a fejlesztés kereskedelmi forgalomba hozatalára, de SQL interfésszel. A Sybase -t , Informix -et , a NonStop SQL -t és magát az INGRES-t az eredeti INGRES származékaiként árulták az 1980-as években. Még a Microsoft SQL Server - je is a Sybase-en alapul, tehát az INGRES-en. Egyedül Larry Ellison – az Oracle alapítója – kezdett új utat az IBM System R-ről szóló cikke alapján, és megelőzte az IBM-et azzal, hogy 1978-ban piacra hozta első verzióját.

A Stonebraker az INGRES tanulságait alkalmazta egy új adatbázis – a Postgres – kifejlesztésében, amely ma PostgreSQL néven ismert. A PostgreSQL-t számos kritikus alkalmazáshoz használják (az .org és az .info domain-nyilvántartások használják elsődleges tárhelyükre, valamint a nagyvállalatok és pénzintézetek).

Svédországban Codd cikke létrehozta a Mimer SQL adatbázist az Uppsalai Egyetemen . 1984-ben ezt a projektet független vállalattá konszolidálták. Az 1980-as évek elején a Mimer bevezette a tranzakciókezelést, hogy robusztussá tegye az alkalmazásokat, ezt az ötletet sok más adatbázis-kezelő rendszer is átvette.

Objektum-orientált rendszerek (1980)

Az 1980-as években az objektum-orientált programozás térnyerése befolyásolta az információk adatbázisokban való kezelését. A programozók és tervezők elkezdték az adatbázisokban lévő adatokat objektumként kezelni. Ez azt jelenti, hogy ha egy személy adatai szerepelnek az adatbázisban, akkor az illető attribútumai, mint a cím, telefonszám és életkor a személyhez tartozónak minősülnek, nem idegen adatok. Ez lehetővé teszi az objektumok és attribútumok közötti kapcsolatok létrehozását, nem pedig az egyes mezők között.

Az évtized során a másik nagy figyelem a hozzáférés sebességének és megbízhatóságának növelése volt. 1989-ben a Wisconsini Egyetem két professzora egy ACM konferencián publikált egy előadást, amelyben felvázolta az adatbázis-teljesítmény javítására szolgáló módszereiket. Az ötlet az volt, hogy a fontos – és legkeresettebb – információkat egy kis ideiglenes adatbázisban reprodukálják, a fő adatbázisra mutató hivatkozásokkal. Ez azt jelentette, hogy a kis adatbázisban sokkal gyorsabban lehetett keresni, mint a nagyban. Javult teljesítménye az indexelés bevezetéséhez vezetett, amely minden DBMS-be beépült.

NoSQL Systems (2000)

A 21. század új trendet hozott az adatbázisok terén: a NoSQL-t. Ez az irányzat a klasszikustól jelentősen eltérő, nem relációs vonalat vezetett be. Általában nem igényelnek rögzített sémákat, denormalizált adatok tárolásával elkerülik az összekapcsolási műveleteket , és vízszintes méretezésre készültek. Legtöbbjük besorolható kulcsérték-tárolókként vagy dokumentum-orientált adatbázisokként .

Az utóbbi időben nagy igény mutatkozik a partíciótűrő elosztott adatbázisokra, de a CAP-tétel szerint nem lehet olyan elosztott rendszert elérni, amely egyszerre biztosít konzisztenciát, rendelkezésre állást és partíciótűrést. Egy elosztott rendszer egyszerre csak kettőnek tud eleget tenni a három megszorításból. Emiatt sok NoSQL-adatbázis az úgynevezett esetleges konzisztenciát használja a rendelkezésre állási és particionálási tolerancia biztosítására, az adatkonzisztencia maximális szintjével.

A népszerű alkalmazások közé tartozik a MongoDB , a MemcacheDB , a Redis , a CouchDB , a Hazelcast , az Apache Cassandra és a HBase , amelyek mindegyike nyílt forráskódú.

XML Systems (2010)

Az XML-adatbázisok a NoSQL-adatbázisok egy részhalmazát alkotják. Mindegyikük az XML tárolási formátumot használja, amely nyitott, ember és gép által is olvasható, és széles körben használják az interoperabilitás érdekében.

Ebben a kategóriában a következőket találjuk: BaseX, eXist, MarkLogic Server, MonetDB/XQuery, Sedna.

Összetevők

• Az adatbázismotor elfogadja a többi DBMS alrendszertől érkező logikai kéréseket, átalakítja azokat fizikai megfelelőjükre, és hozzáfér a tárolóeszközön lévő adatbázishoz és adatszótárhoz.
• Az adatdefiníciós alrendszer segít az adatszótár létrehozásában és karbantartásában, valamint meghatározza az adatbázist támogató fájlstruktúrát.
• Az adatkezelési alrendszer segíti a felhasználót abban, hogy információkat adjon hozzá, módosítson és töröljön az adatbázisból, valamint a lekérdezést az információk kinyeréséhez. Az adatkezelési alrendszer jellemzően a felhasználó elsődleges interfésze az adatbázishoz. Lehetővé teszi a felhasználó számára, hogy logikai szempontból határozza meg információigényét.
• Az alkalmazásépítési alrendszer olyan segédprogramokat tartalmaz, amelyek segítik a felhasználókat az alkalmazásfejlesztésben. Általában adatbeviteli képernyőket, programozási nyelveket és interfészeket biztosít.
• Az adminisztrációs alrendszer olyan funkciókkal segíti az adatbázis kezelését, mint a tárolás és visszakeresés, a biztonságkezelés, a lekérdezések optimalizálása, a párhuzamosság-vezérlés és a változáskezelés.

Modellezési nyelvek

Minden DBMS által támogatott adatbázisnak megfelelően modellezett sémákkal kell rendelkeznie. Az adatbázisok történeti fejlődésével egy időben különböző modelleket alkalmaztak. A DBMS elvárja, hogy egy bizonyos modell egyszerű módon hozzáférjen az adatbázishoz. Ezek a modellek a következők:

• Hierarchikus
• Hálózatban
• relációs
• többdimenziós
• tárgyakból

Fordított listákat is alkalmaztak.

Hierarchikus struktúra

Példa hierarchikus adatbázis-modellre

A hierarchikus struktúrát az első nagyszámítógépek DBMS-ében használták . A rekordok közötti kapcsolatok fastruktúrát alkotnak. Ez a szerkezet egyszerű, de rugalmatlan, mivel a kapcsolatok az 1:n típusra korlátozódnak. Az IBM IMS rendszere és a Raima RDM Mobile példája több hierarchiával rendelkező adatbázisra ugyanazon az adatkészleten. Az RDM Mobile egy új beágyazott adatbázis-konstrukció mobil számítógépes hálózatokhoz. A hierarchikus struktúrát ma elsősorban földrajzi információk tárolására használják.

A hierarchikus adatbázismodellnek van egy sémája, amelyben az adatok fastruktúrába vannak rendezve. Ez a struktúra lehetővé teszi a szülő/gyermek kapcsolatok ábrázolását: minden szülőnek több gyermeke is lehet, de minden gyermeknek csak egy szülőtől kell származnia (1:N kapcsolatként ismert). Egy adott rekord minden attribútuma egy entitástípushoz van társítva. Ezt a modellt az IBM készítette 1960-ban.

Egy adatbázisban az entitástípus a tábla általános kifejezése. Minden egyes rekord sorként, minden attribútum pedig oszlopként jelenik meg. A típusú entitások 1:N megfeleltetések segítségével kapcsolódnak egymáshoz.

Jelenleg a legszélesebb körben használt hierarchikus adatbázisok az IBM IMS és a Microsoft Windows Registry .

Hálózati struktúra

Hálózati adatbázis modell

Ez a struktúra összetettebb kapcsolatokat tartalmaz, mint a hierarchikus. Minden rekordhoz több kapcsolat is tartozik, amelyeket különböző utak követhetnek. Más szóval, a modell N:N kapcsolatokat tesz lehetővé.

A hálózati modell az objektumok és kapcsolataik ábrázolásának rugalmas módja. Megkülönböztető tulajdonsága, hogy a sémának – amelyet ívekkel összekapcsolt csomópontok halmazának tekintünk – nincsenek korlátozások.

A modell feltalálója Charles Bachman volt, a szabványt 1969-ben a CODASYL adta ki.

Relációs szerkezet

Példa táblázatokra és összefüggésekre.

A relációs struktúra ma a legelterjedtebb. Nagyszámítógépekben , közepes számítógépekben és mikroszámítógépekben használják. Tárolja az adatokat sorokban (tuples) és oszlopokban (attribútumok). Ezek a táblázatok közös kulcsokkal kapcsolhatók egymáshoz. Amikor 1972-ben az IBM-nél dolgozott, EF Codd kitalálta ezt a szerkezetet. A modellt a felhasználó számára nem könnyű megismerni, mivel a táblázatok összetett kombinációját igényelheti.

Többdimenziós szerkezet

4 dimenziót képviselő kockák egy többdimenziós adatbázisban

A többdimenziós struktúra hasonlóságokat mutat a relációs modellel, de a két sor-oszlop dimenzió helyett N dimenzióval rendelkezik. Ez a szerkezet egy táblázatos megjelenést kölcsönöz. Könnyen karbantartható és érthető, mivel a naplók tárolása ugyanúgy történik, ahogyan megtekintik. Nagy teljesítménye az online tranzakcióelemző feldolgozás (OLAP) legnépszerűbb adatbázisává tette.

Objektumorientált szerkezet

Példa objektumokat és öröklődéseket tartalmazó adatbázisra

Az objektum-orientált struktúra az objektum-orientált nyelvek paradigmáját követve készült. Ily módon természetes módon támogatja a grafikus, képi, hang- és szöveges adattípusokat. Ezt a struktúrát széles körben használják a multimédiás alkalmazások webalkalmazásaiban.

Az objektum-orientált szerkezetű DBMS bevezetése előtt a multimédiás adatok tárolása a fájlrendszeren alapult az adatok rendszerezésére, tárolására és feldolgozására. A fájlfeldolgozás nehézkes, drága és rugalmatlan. Az adatredundancia a fájlfeldolgozás hátránya, mivel a független fájlok duplikált fájlokat hoznak létre, amelyek a szükséges helyet foglalják el. További hátránya az integráció hiánya és a karbantartás nehézsége. Ezt úgy oldották meg, hogy objektum orientációt alkalmaztak az adatokra.

Lekérdezési nyelvek

Az adatbázis-lekérdezési és jelentési nyelvek lehetővé teszik az adatbázis lekérdezését, az adatok elemzését és frissítését az egyes felhasználók jogosultságai alapján. Felügyeli az adatbázis biztonságát is, hogy megakadályozza az adatok megtekintését, törlését vagy módosítását az illetéktelen hozzáférést. A kulcsok használatával a teljes adatbázishoz vagy annak egy részéhez való hozzáférés engedélyezett. Például egy alkalmazotti adatbázis tartalmazhatja az összes munkavállalói adatot, de a felhasználók csak egy csoportja tekintheti meg a bérszámfejtést, míg mások csak a munkahelyi előzményeket és egészségügyi adatokat vagy megkereséseket tekinthetik meg.

Ha a DBMS lehetőséget ad az adatbázis elérésére, frissítésére, illetve lekérdezésére, akkor személyes adatbázisok létrehozását is lehetővé teszi. Azonban nem lenne képes nyomon követni a szükséges műveleteket vagy ellenőrzéseket, amelyek egy nagy szervezet adatbázisához szükségesek. Ezek a vezérlők csak akkor érhetők el, ha egy segédprogram figyeli az adatok elérését és frissítéseit.

Építészet

A DBMS architektúrája meghatározza összetevőit (beleértve azok működési leírását is) és azok interfészeit. Más fogalmakkal foglalkozik, mint az adatbázis-architektúra. A DBMS fő összetevői a következők:

• Külső interfészek : az SGDB-vel való kommunikációt jelenti mindkét irányban (I/O) és annak összes funkcióját. Befolyásolhatják az adatbázist vagy a DBMS működését, például:
  • közvetlen műveletek az adatbázissal: típusok meghatározása, biztonsági szintek hozzárendelése, adatfrissítés, adatbázis lekérdezés...
  • a DBMS működésével kapcsolatos műveletek: biztonsági mentés és visszaállítás, összeomlás utáni helyreállítás, biztonsági figyelés, tárkezelés, helyfoglalás, konfiguráció figyelés, teljesítményfigyelés, hangolás...
  • a külső interfészeket használhatják a felhasználók (pl. rendszergazdák), vagy olyan programok, amelyek API-n keresztül kommunikálnak.
• Nyelvtolmács vagy processzor : A legtöbb műveletet adatbázis-nyelv használatával hajtják végre. Vannak nyelvek az adatok meghatározásához, adatkezeléshez (pl. SQL), a biztonsági szempontok meghatározásához stb. Az adott nyelvű utasítások a megfelelő interfészen keresztül kerülnek be a DBMS-be. A kifejezések az említett nyelven (akár lefordítva, akár értelmezve) a műveletek kibontása céljából kerülnek feldolgozásra, hogy azokat a DBMS végrehajthassa.
• Lekérdezésoptimalizáló : elvégzi az egyes kérdések optimalizálását, és kiválasztja a leghatékonyabb cselekvési tervet a végrehajtásához.
• Adatbázis motor – A szükséges műveleteket hajtja végre az adatbázison, jellemzően magas szinten képviselve azt.
• Tárolási mechanizmus : Lefordítja a műveleteket alacsony szintű nyelvre az adatok eléréséhez. Egyes architektúrákon a tárolási mechanizmus be van építve az adatbázismotorba.
• Tranzakciós motor : a helyesség és megbízhatóság elérése érdekében a DBMS belső műveleteinek nagy részét a tranzakciókba zárva hajtják végre. A tranzakciók a DBMS-en kívül is megadhatók a műveletek csoportjának beágyazásához. A tranzakciós motor követi a tranzakciók lebonyolítását, és az általa felállított szabályok szerint kezeli azok végrehajtását (pl. egyidejűség ellenőrzése és végrehajtása vagy törlése).
• A DBMS kezelése és működése : számos egyéb összetevőt tartalmaz, amelyek a DBMS kezelési és működési vonatkozásaival foglalkoznak, mint például a teljesítményfigyelés, a tárkezelés, a tárolási térképek.

Lásd még

• Adatbázis
• adattár
• melléklet: Relációs adatbázis-kezelő rendszerek összehasonlítása