Relációs adatbázis-kezelő
A Wikipédiából, a szabad lexikonból.
A relációs adatbázis-kezelő egy olyan adatbázis-kezelő rendszer (angol rövidítéséből: RDBMS), amelynek logikai adatbázisát szoftverkomponensei kizárólag a relációs adatmodellek elvén épülnek fel, illetve kérdezhetőek le. Más, divatos szavakkal kifejezve: az RDBMS kizárólag az relációs adatmodell alapú megközelítést támogatja. Amennyiben más adatmodell is kiszolgálható ilyen rendszerrel, úgy a kapcsolódó adatmodell függvényében objektumrelációs, illetve deduktív relációs adatbázisról beszélhetünk. A relációs adatbázis-kezelők szabványos adathozzáférési és adatdefiníciós nyelve az SQL.
[szerkesztés] Jelenleg elérhető termékek
Gyártó (forgalmazó) és terméknév szerint (2006-os állapot):
- Oracle Corp.: Oracle, BerkeleyDB
- IBM: DB/2, Informix, Illustra
- Microsoft: MS-SQL
- SyBase: SyBase (korábban System NN -- NN helyén egy verzió állt)
- Borland: FireBird (korábban, illetve Borland termékeknél InterBase)
- Computer Associates (CA): Ingres, Jasmine
- Progress: ObjectStore
- SAP: MaxDB
- Novell: FLAIM
Nyílt forráskódban elérhető adatbázis-kezelők (2006-os állapot):
- BerkeleyDB
- Derby (ugyanaz, mint IBM Cloudscape, Sun Java DB)
- FireBird (ugyanaz, mint InterBase)
- FLAIM
- Ingres (ugyanaz, mint openIngres)
- MaxDB (ugyanaz, mint SAPDB)
- mySQL
- postgreSQL
- SQLite
[szerkesztés] Kiegészítés
[szerkesztés] Codd szabályai
Edgar F. Codd (akit Tednek becéztek) 12 szabály néven elhíresült 13 megállapítása a relációs adatbázis-kezelők legfontosabb ismérveit rögzítik. Ted Codd 1985-ben a Computerworld c. újság október 14-i és 21-i számában, két részletben foglalta össze a relációs adatbázis-kezelők legfontosabb tulajdonságait, adottságait és szükségszerűségeit, amelyet azóta számosan idéztek és dolgoztak fel; tananyaggá lett.
Az alábbiakban Chris J. Date tolmácsolásában ismerhetjük meg e szabályokat:
[szerkesztés] A 0. szabály
Ahhoz, hogy egy rendszer relációsnak, adatbázisnak, és kezelő rendszernek legyen nevezhető, elfogadható - a rendszernek a relációkkal foglalkozó adottságait (kizárólag) az adatbázis kezelésére kell használnia.
[szerkesztés] 1. Az egységes megjelenésű információ szabálya
Ez a szabály egyszerűen csak annyit ír elő, hogy az adatbázisban szereplő összes információt egy, és csak egy megadott formában lehet ábrázolni, nevezetesen a sorokba szedett táblázatokon belül egy-egy oszlop pozícióban. (vízszintes és függőleges koordinátarendszerben – a ford.)
[szerkesztés] 2. Garantált lokalizálhatóság szabálya
Ez a szabály lényegében az elsődleges kulcs alapkövetelményének megfogalmazása másképpen. Azt mondja ki, hogy az adabázisban minden egyes skaláris értékre logikailag úgy kell hivatkozni, hogy megadjuk az azt tartalmazó táblázat és az oszlop nevét, valamint a megfelelő sor (azt tartalmazó sor) elsődleges kulcsának az értékét.
[szerkesztés] 3. A NULL értékek egységes kezelése
Az adabázis-kezelő rendszernek (DBMS) olyan módszerrel kell támogatnia a „hiányzó és nem felhasználható információt” amely egységes, és eltér az összes „rendes” érték kezelésétől (például numerikus értékek esetében, „nullától vagy más számtól különböző”-ként), továbbá független az adattípustól. Ebbe az is beletartozik, hogy ezeknek a reprezentációknak a kezelését a szoftvernek módszeresen kell végeznie.
[szerkesztés] 4. A relációs modell alapján aktív online katalógust kell üzemben tartani
A rendszernek támogatnia kell egy online, beépített katalógust, amely a szokásos lekérdező nyelvet használó feljogosított felhasználók előtt nyitva áll.
[szerkesztés] 5. A teljeskörű „adatnyelv” szabálya
A rendszernek legalább egy olyan relációs nyelvet kell támogatnia, amelynek
- (a) lineáris a szintaxisa,
- (b) interaktívan és alkalmazási programokon belül is lehet használni, továbbá
- (c) támogatja az adat definiáló műveleteket (beleértve az adatok megjelenítési képeinek meghatározására szolgálókat), az adatmódosító (manipulációs) műveleteket (frissítés és visszakeresés is), biztonsági és jósági (integritási) korlátokat, valamint a tranzakció kezelési műveleteket (begin, commit, és rollback: elkezdés, jóváhagyás és visszagörgetés).
[szerkesztés] 6. A nézetek frissítésének szabálya
A rendszernek képesnek kell lennie az adatok elméletileg frissíthető minden nézetének frissítésére.
[szerkesztés] 7. Magas szintű beszúrás, frissítés és törlés
A rendszernek támogatnia kell az INSERT, UPDATE, és DELETE (új adat, módosítás, törlés) operátorok halmaz szintű, egyidejű működését.
[szerkesztés] 8. Fizikai szintű adatfüggetlenség
A fizikai adatfüggetlenség akkor áll fenn, ha az alkalmazások (programok) és a felhasználók adatelérési módja független az adatok tényleges (fizikai) tárolási és elérési módjától.
[szerkesztés] 9. Logikai szintű adatfüggetlenség
Logikai adatfüggetlenség akkor áll fenn, ha az adatbázis logikai szerkezetének megváltoztatása nem igényli az adatbázist használó alkalmazások (programok) megváltoztatását.
[szerkesztés] 10. Jóság (integritás) függetlenség
Az adatok jóságának (érvényességének) korlátait az adatfeldolgozási programoktól függetlenül kell tudni meghatározni, és azokat katalógusban kell nyilvántartani. Legyen lehetséges a szóban forgó korlátokat - úgy és amikor szükséges - megváltoztatni, anélkül hogy a meglévő alkalmazásokat szükségtelen módon zavarnánk.
[szerkesztés] 11. Elosztástól való függetlenség
A meglévő alkalmazások működése zavartalan kell, hogy maradjon
- (a) amikor sor kerül az adatbázis kezelő szoftver elosztott változatásnak bevezetésére a rendszerben
- (b) amikor a meglévő elosztott adatokat a rendszer újra szétosztja
[szerkesztés] 12. Megkerülhetetlenség szabálya =
Ha a rendszernek van egy alacsony szintű (egyszerre egy rekordot érintő) interfésze, akkor azt az interfészt ne lehessen a rendszer megkerülésére használni, például a relációs biztonsági vagy jósági (integritás védelmi) korlátok megsértésével.
[szerkesztés] Források
- E.F. Codd: Is Your DBMS Really Relational?, ComputerWorld, 1985. október 14.
- E.F. Codd: Does Your DBMS Run by the Rules?, ComputerWorld, 1985. október 21.
- C.J. Date: An Introduction to Database Systems, (5. kiadás) 389 – 393 oldal.
Based on work by 