|
|
Relációs adatbáziskezelésA kezelők fejlődése és sajátosságaiA kezdet kezdetén Codd leszögezte, hogy a relációs elvű adatbáziskezelő az adattárolás és visszakeresés fizikai szintjét teljes egészében el kell rejtse a felhasználó elől. Ez nagyon helyes alapelv, szerintem az egyik oka a relációs adatbáziskezelés sikerének. Azonban van ennek is hátránya, mégpedig több okból. Ezen okok közül a legfontosabb az, hogy a logikai és a fizikai szint nehezebben választható szét, pontosabban sokkal inkább hatással vannak egymásra, mint mondjuk a fogalmi és a logikai szintek. (vö. Leképezések) A mai adadtbáziskezelők a fizikai szintet majdnem teljesen elrejtik a felhasználó elől. Felhasználó alatt most nem a végső felhasználót, az adatbázisra épülő alkalmazás kezelőjét, hanem az adatbázis létrehozóját, illetve kezelőporgramjainak fejlesztőjét értve. Az adatbáziskezelők fizikai szintű megoldásainak dokumentáltsága általában nem kielégítő, azok nehezen hozzáférhetők, és úgy tűnik, mintha erre a területre már nem igazán jutna kellő figyelem. A dokumentációk általában nem elegendőek ahhoz, hogy adott konkrét helyzetben kísérletezés nélkül el lehessen dönteni, hogy melyik a gyorsabb és/vagy energiatakarékosabb megoldás a lehetséges megoldások közül. Ugyancsak már Codd foglalkozik a lekérdezések adatbáziskezelők általi optimalizálásával is. Az egyes adatbáziskezelők ilyen irányú lehetőségei illetve korlátai talán még elmélyültebb ismeretét követelnék meg azoknak, mint a fizikai szintű műveletek ismerete. Megfigyelhető tehát egyrészt egy olyan fejlődési folyamat, amely a növekedő igények (mennyiség és teljesítmény vonatkozásában) kiszolgálását célozza, ugyanakkor, mintegy ezt ellensúlyozandó, olykor a legalapvetőbb elemek is hiányoznak vagy elégtelenek, mint pl. a kapcsolatok kezelése (elsődleges kulcs és idegen kulcs kapcsolat), különféle korlátok érvényesítésének lehetősége stb. Van olyan - közismert és jelentős piaci részesedésű - adatbáziskezelő, amelynek az alapértelmezett kezelőmotorja nem tudja lekezelni az idegen kulcs jelentette szerkezeti korlátokat. Kulcs, idegen kulcs, kapcsoló Ugyancsak nem magától értetődő a homogén 1:N kapcsolatok (fagráf), a homogén M:N kapcsolatok (darabjegyzék) megfelelő kezelése. A fa (1:N), illetve a háló (M:N) bejárása pedig nemcsak a kezelőkön, de magán az SQL-en is kifog, pedig mindkét eset alapvető fontosságú adatmodellezési, adatszerkezeti elem. Említendő még - az emberi ismerethiányon túl - az, hogy nincs igazán kiforrott és minden esetre általánosan - és jól - alkalmazható fejlesztési módszer. Úgy vélem, hogy ilyent elég nehéz lenne elképzelni is, hiszen az adatbázistervezési feladatok és igények (is) olyannyira szerteágazók és sokfélék lehetnek, hogy azok teljes körét egyetlen, általános fejlesztési módszerrel eredményesen lefedni nem igazán lehetséges, vagy legalábbis gazdaságosan nem. Ez azonban puszta sejtés, a probléma végiggondolása - érdemes lenne pedig - meghaladja a jelen jegyzet kereteit. Lásd még (a teljesség igénye nélkül): |
|
|||||||||||||||||||||||||||
VéleményNincs és nem is lehet. |
| impresszum |
