ELEJE Mindennapok Alapfogalmak Történet Relációs kezelés Adatmodellezés Modellezési technikák Fejlesztés Üzemeltetés Biztonság Minőség Jog Etika		Adatmodellezés Leképezés A fogalmi modellnek többféle leképezése lehet a logikai tervezés síkján, és ezen logikai szintű tervekhez ugyancsak többféle fizikai szintű terv tartozhat. Azaz a fogalmi-logikai-fizikai szintek hierarchikus, 1:N kapcsolatban állnak egymással. A logikai szintű tervezés nem a fogalmi modell átalakítása, "elrontása", hanem a fogalmi modell alapján történő tervezés, ezúttal már az alkalmazási (technikai, hatékonysági, hozzáférési) körülmények mérlegelése és figyelembe vétele mellett. Ugyancsak a fizikai szintű terv kialakítása nem a logikai szintű terv átalakítása, hanem az alkalmazandó technika sajátosságainak figyelembevételével megalkotott terv. A három szint, a fogalmi, logikai és fizikai szint megkülönböztetése, továbbá a modellezés és tervezés ezen szinteknek megfelelő tagolása létfontosságú. Áll vagy bukik rajta a végeredmény termék minősége, esetleg akár használhatósága. Ezen túl számos előnye van. Ezek közül néhány: változások hatása, fizikai adatfüggetlenség, általános és egyedi nézetek. Különös gondot kell fordítani a határesetek és határhelyzetek kezelésére. A három szintet alapul véve, két határhelyzet van, a fogalmi-logikai szintek és a logikai-fizikai szintek között. Az első eset a kevésbé problémás, ugyanis a fogalmi és a logikai szint világosan, jól elkülöníthető. A logikai és a fizikai szint határa a problémásabb, ugyanis a hatékonyság figyelembevételét logikai szintű tényezőként tartjuk számon, ugyanakkor a fizikai szintű megvalósítás igen komolyan visszahat erre. Változások hatása A legelső és talán legfontosabb előny, hogy három - különböző szintű - terv birtokában könnyebb szembenézni a valóság időnkénti óhatatlanul bekövetkező megváltozásával. Ha van világosan elkülönített három szintű tervünk, a változás hatása, illetve a változtatás igénye könnyebben, egyértelműbben és világosabban kezelhető. A változás ugyanis valamelyik szintet érinti a három közül, és elegendő az adott szintű tervet módosítani, és ezen következmények hatását továbbvezetni az alacsonyabb szintű tervben. (Vö. az ezredforduló dátumproblémájával - Y2K.) Fizikai adatfüggetlenség Ha valamilyen oknál fogva szükségessé válik egy, a fizikai szintet érintő változtatás, az a logikai tervet elvben nem érinti, a fogalmi modellünket pedig végképp nem. Sőt, nemcsak a logikai szintű tervet nem kell megváltoztatnunk, de alkalmazásszintű programjainkat sem. A modellezett valóság ugyanis ugyanaz marad akkor is, ha az adatbázis-kezelő eszközünket frissítjük, vagy akár kicseréljük. Ezt úgy is nevezik, hogy fizikai adatfüggetlenség. Halassy Béla megfogalmazása szerint: "Fizikai adatfüggetlenségről beszélünk akkor, ha az adatok elhelyezési, hozzáférési és ábrázolási módjában bekövetkező változáskor nincs szükség a programok módosítására." Codd a relációs adatbáziskezelőkkel szemben támasztott követelmények között ezt úgy fogalmazza meg az általános tulajdonságok között (RS-4), hogy az adatbázis-kezelő teljes adattartalmának - ahogy azt a felhasználók látják - nem szabad függnie a kiszolgálótól vagy eszköztől, amelyben az adatok bármely része elhelyezkedik. ("If a row of a base R-table is moved in any kind of storage by the DBMS, its information content as perceived by users remains unchanged, and therefore need not be changed. The entire information content of the DBMS as seen by users must not be dependent upon the site or equipment in which any of the data is located.") Sajnos a valóság nem feltétlenül ennyire tiszta és világos, ugyanis a "kompatibilitás", a "hordozhatóság", a "közös platform" stb. kifejezések és azok jelentéstartalma nem feltétlenül állják meg helyüket teljes mértékben, azaz a fizikai adatfüggetlenség elve sokszor nem érvényesül maradéktalanul, és ezért bizony igen sok esetben nem a fizikai szintű tervezés hiányosságai okolhatók. Szakirányú levelezési listákon a kérdések túlnyomó többsége valamely adatbázis-kezelő valamely verziójához kapcsolódik. Általános és egyedi nézetek Egy adatbázis elkészítésének csapatmunkájában részt vevő emberek három fő csoportba oszthatók. Van a vezető (menedzser), aki a megrendelő, és ilyen minőségében megfogalmazza a hivatalos elvárásokat. Van a fejlesztő (tervező), aki megpróbálja az elvárásokat megfelelően modellezni, majd arra a modellre felépíteni az adatbázist és az azt kezelő alkalmazásokat. A harmadik szereplő a tényleges felhasználó, akinek napi szinten kezelnie kell majd az alkalmazásokat. A három szereplő közül kettőnek általában nincs informatikai végzettsége, ami még nem lenne baj, de többnyire informatikai műveltsége sincs, ami viszont már baj. Ugyanis mind a vezető (a megrendelő pozíciójából) mind a felhasználó a saját egyéni elvárásait fogalmazza meg kizárólagosként, ráadásul a vezető az egész feladatot kizárólag projektként szemléli, és nem vesz tudomást arról, hogy vannak olyan részei, amelyek nem kezelhetők mennyiségi szemlélet alapján (pl. kétszer annyi ember esetén feleannyi idő). A fejlesztőt hajtja az idő- és gazdasági kényszer, és nincs ideje az érdemi, fogalmi szintű modellezésre... Holott az egyéni - jogos - elvárások egységbe foglalhatók. Az adatmodell ugyanis szervezeti szinten egységes és egyetlen - kellene legyen. Nincs ugyanis olyan felhasználási mód és cél, amely az egész adatbázist a maga teljességében, annak összes táblájával használná vagy használnia kellene. Olyan "felhasználó", akinek az egész adatmodellt egységes egészként és egyben kell látnia, kettő van: a tervező-fejlesztő és az üzemeltető. Ha azonban sikerül megalkotni egy egységes, jó adatmodellt, akkor abból az összes egyéni, egyedi elvárás, nézet levezethető. Ezt egy hasonlattal tudom a legjobban érzékeltetni. Legyen adott egy atlasz a Kárpát-medencéről. Ebben van (lehet) sokféle térkép: domborzati, vízrajzi, közlekedési, közigazgatási, geotermikus, időjárási stb. Egyetlen fajta térkép nincs benne egész bizonyosan: olyan, amelyik egyszerre mutatja mind a felsoroltakat. Nincs is rá szükség. Viszont a felsorolt térképeket nem lehetne elkészíteni, ha nem létezne az általános (virtuális) térképi modellje a Kárpát-medencének. Ezen általános - és teljes - modell alapján azonban elkészíthetők az "egyéni kívánságoknak" megfelelő szakmai nézetek. Hasonlóképpen: a jó adatmodell mint globális nézet alapján előállíthatók az egyéni, egyedi - parciális - nézetek a megfelelő igényeknek megfelelően, lehetővé téve a szűk szakmai igényeknek megfelelő, célszerű használatot. Az ANSI-SPARC architektúra Az, hogy három szinten kell szemlélni egy adatbázist, már nagyon régen kialakult. 1975-ben az ANSI (American National Standards Institute) SPARC (Standards Planning And Requirements Committee) bizottsága kiadta az ANSI-SPARC architektúra első változatát, amely már tartalmazza azt, hogy három szintet szükséges megkülönböztetni. Sajnos ez a három szint egész mást jelent ebben az esetben, mint a fentebb vázoltak, és nem is vált hivatalos szabvánnyá. Codd már többször idézett munkájában azt írja, hogy: "A bizottság egyik jelentésében alkalmazott három szint meghatározása szélsőségesen pontatlan, ezért számos módon értelmezhető." ("The definitions of the three levels supplied by the committee in a report were extremely imprecise, and therefore could be interpreted in numerous ways.") Ez a három szint a külső séma (external schema), a fogalmi séma (conceptual schema) és a belső séma (internal schema). A Codd-féle relációs modellben is szerepel a három szintű megközelítési mód, sőt meg is felelteti az ANSI-SPARC szinteket a relációs modellbeli szinteknek. Fontos azonban tisztán látnunk, hogy függetlenül az ANSI-SPARC három szintjétől és függetlenül attól, hogy Codd erről hogy vélekedik, nem ugyanarról van szó! Codd a három szint alatt a felhasználói nézeteket, az alaprelációkat és a tárolási adatszerkezeteket érti ("RS-5, The Three Level Architecture: A relational DBMS has a three-level architecture consisting of views, base relations, and storage representations.") Az ANSI-SPARC, illetve Codd háromszintű architektúrája a relációs kezelőkkel szemben támasztott követelmények megfogalmazásának része, amiről viszont fentebb volt szó, az az adatmodellezés területe. Igaz ugyan, hogy a kétféle terület kétféle felosztása nem lehet teljesen független egymástól, hiszen - végülis - ugyanarról a valóságról szól mindkettő: a világ egy bizonyos részét, annak működését adatokkal szeretnénk leírni, és ilymódon jellemezni további ismeretek SZELEKTÍV megszerzésének, illetve a hatékonyabb működtetés érdekében. Nagyon fontos azonban, hogy tisztán lássuk a különbséget. Ezt nemcsak a fogalmi pontosság igénye követeli meg, hanem sokkal inkább az a körülmény, miszerint a fogalmi pontosság a továbblépés, az eredményesség előfeltétele. Így tehát mindenképpen muszáj különbséget tennünk az általános adatbáziskezelés relációs modellje (szemben mondjuk a hálós modellel) és annak tulajdonságai, valamint adott konkrét terület (pl. felsőoktatási intézmény tanulmányi ügyvitele) adatmodellje között. A relációs kezelés modellje, illetve az ott alkalmazottak nem vihetők át egy az egyben a konkrét adatmodellezés területére. Ennek ellenére ezen keveredés számos változata a mai napig fel-felbukkan. "Az adatbázisok világában specifikálni kell egy szerkezetet, egy fogalmi vagy logikai sémát (DDL nyelven) (...) Különböző felhasználók (...) az adatbázisnak más-más fogalmi képét látják, részben azért, mert a menürendszerek alaposan elfedik az adatbázis igazi képét, részben pedig azért, mert a menüprogramok általában nem közvetlenül az adatbázishoz kapcsolódnak, hanem egy gazdanyelv + DML programhoz. (...) Az adatbázisnak az egyes felhasználó csoportok számára hozzáférhető részét nézetnek, zsargonban: vjú-nak (ang.: view) nevezzük. Lehet, hogy egy nézethez az adatbázis sémájának csak egy-egy alsémája (...) tartozik (...)" (Békéssy, 2005. p. 51.) A "fogalmi kép" nem lehet különböző, nem keverhető össze a nézet ("vjú") fogalmával. Ha nincs világosan megfogalmazott globális fogalmi modellünk, amelyik ráadásul megfelel a következőekben részletezett jósági követelményeknek, nem tudunk - mert nem lehetséges - jó adatbázist létrehozni, amint a megfelelő globális térképi modell nélkül nem lehet elkészíteni a különféle szaktérképeket (vetület, "vjú"). Létkérdés tehát a fogalmi, a logikai és a fizikai szint világos elhatárolása. Lásd még (a teljesség igénye nélkül): Codd E. F.: The Relational Model for Database Management - version 2. Addison-Wesley Publishing Company, h.n., 1990. Békéssy András -- Demetrovics János: Adatbázis-szerkezetek. Akadémiai Kiadó, Budapest, 2005.
		Vélemény Nincs és nem is lehet.

impresszum