10

Click here to load reader

1144. 13.tétel

Embed Size (px)

Citation preview

Page 1: 1144. 13.tétel

1144-13. tétel Egy adott rendszer fejlesztésénél milyen szempontok alapján választaná ki az adatbáziskezelő rendszert, a fejlesztő eszközt, illetve a programozási nyelvet?

Információtartalom vázlata

–Eszközkörnyezet meghatározása– Adatbáziskezelők, fejlesztőeszközök előnyei, hátrányai

–Rendszerek működésének tervezése– A létrehozandó rendszer optimális működésének feltételei

–Alkalmazásfejlesztő eszközök– Fejlesztő eszközök összehasonlítása

Az adatbázis-kezelő rendszer (angolul Database Management System, DBMS) többfelhasználós, hálózatos környezetben, adatbázisokhoz való hozzáférést, rendszeres és a felhasználói folyamatok zavartalan működést biztosító szoftveralkalmazás

A nézeteket élesen megkülönböztetjük aszerint, hogy azok az adatbázisban tárolt adategységek lekérdezésével („manipulálásával”) vagy az adatszerkezetek változtatásával, kialakításával („definiálásával”) foglalkoznak. A két nézettípusnak eltérő nyelvezete van, illetve lehet, előbbit általában az adatlekérdező DML (Data Manipulation Language) nyelv, utóbbit az adatszerkezetet kialakító DDL (Data Definition Language) vezérli.

Az adatbázis-kezelők meghatározó része a logikai adatbázis kialakítására koncentrál. A logikai adatbázisokat szerkezetük, felépítési és működési sajátosságaik alapján különböztetjük meg, amelyet összefoglalóan, tömören adatmodellnek nevezünk. Értelemszerűen tehát az adatbázis-kezelőket az általuk kezelt, vezerélt, valamint megvalósított adatmodellek alapján osztályozzuk. Ennek megfelelően beszélhetünk relációs, objektumorientált, hálós, deduktív, illetve ezek elegyítéséből létrejött objektumrelációs, deduktív relációs adatbázis, deduktív objektumorientált adatbázis-kezelőkről, röviden és ilyen értelemben: adatbázisokról – bár az adatbázis szó elsősorban mindig a ténylegesen tárolt adathalmazra utal.

Gyártó (forgalmazó) és terméknév szerint

Oracle Corp. : Oracle Database, 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

Page 2: 1144. 13.tétel

Az adatbázisrendszerek előnyei

Az adatbázisrendszer mellett az adatkezelés másik fő variánsa a hagyományos fájlkezelő rendszer. Ez a fajta adatkezelési technikai is elterjedt, használata bizonyos esetekben előnyösebbnek bizonyul a DBS alkalmazásánál. A rendszerfejlesztő egyik fontos feladata a megfelelő adatkezelési módszer kiválasztása, annak eldöntése, hogy mikor érdemes DBS-t és mikor fájl kezelő rendszert használni. A döntés helyes meghozatalához ismerni kell mindkét rendszer előnyeit és hátrányait is.

A DBS-t illetően részben az előzőekben ismertetett fogalmakon alapulva az alábbi előnyök emelhetők ki:

Az egyedtulajdonságok, kapcsolatok és metaadatok egységes tárolási rendszere

Az adatbázis nem egy speciális alkalmazói programhoz készült, hanem tetszőlegesen sokfajta alkalmazói program is futhat rajta, több alkalmazói program adatait is összefogja. Ezért szokás az adatbázisban tárolt adatokat integrált adatoknak is nevezni. A normál fájlkezelésnél ezzel szemben rendszerint minden alkalmazói programhoz el kell készíteni a saját adatrendszerét.

Adatfüggetlenség

Az adatfüggetlenség kérdése az egyik legfontosabb jellemzője az adatkezelés fejlődésének. A 1950-es évek elején megírt adatkezelő programok egyik jellemzője volt, hogy a programkód teljes mértékben tükrözte az adatok tárolásának szerkezetét, hiszen a program szinte közvetlenül elérhette az adatokat. Ezt a fejlettségi szintet nevezik a teljes adatfüggőség korának. Ezt azt is jelentette, hogy ha megváltozott a fizikai struktúra, akkor át kellett írni a programot is. Mivel a hardware gyors fejlődése miatt erre gyakran szükség volt, a fejlődés következő lépcsőjében beépült egy fájlkezelő rendszer az operációs rendszerbe, s az alkalmazás már egy átdolgozott, áttranszformált képet kapott a fájlszerkezetről. A programban csak egy logikai adatszerkezetet kell definiálni, a fizikai szerkezetre való leképzést a konverter végzi.

A fizikai adatfüggetlenség azt jelenti, hogy a fizikai adatszerkezet, az elérési mód megváltoztatható anélkül, hogy a programot is módosítani kellene. A mai hagyományos fájlkezelésnél egy rekord szintű függetlenség valósul meg, hiszen a állományt sima rekordsorozatnak képzelhetjük el, pedig valójában nem az, ezzel szemben a rekord mezőit úgy kell megadni, ahogy azok fizikailag is megvalósulnak. Az adatfüggetlenség következő az adatbázisokban megvalósuló szintje a � � mezőszintű fizikai adatfüggetlenség, hiszen az adatbázisban az egy rekordba tartozó mezők is fizikailag szétszórtan helyezkedhetnek el az adathordozón.

Az adatfüggetlenség másik típusát logikai adatfüggetlenségnek nevezik, mely szintén megvalósul az adatbázisoknál. Ez alatt azt értjük, hogy a letárolt logikai adatmodell maga is bővíthető, illetve bizonyos mértékben módosítható, hogy az alkalmazói programokat módosítani kellene. Ha tehát egy objektumtípushoz egy újabb tulajdonságot kívánok letárolni, nem kell egyetlen egy meglévő alkalmazói programot sem módosítani.

Nagyobb adatabsztrakció

Page 3: 1144. 13.tétel

Az adatbáziskezelésnél az adatok a felhasználó szemszögéből tekintve adatmodellben tárolódnak, ezért a felhasználónak nem kell törődnie a fizikai tárolás részleteivel, s egy magasabb absztrakciós szinten értelmezheti az adatrendszert. A részletek rejtve maradnak a felhasználó és a programfejlesztő előtt is.

Adatmegosztás, párhuzamos hozzáférés

A DBMS felkészült az integrált adatokhoz történő osztott hozzáférések kezelésére. A hagyományos fájlkezelő alkalmazásoknál csak igen nagy ráfordítással tudnánk biztosítani a DBMS-ben megvalósított konkurens hozzáférést támogató koncepciót. Az adatmegosztás révén a helyigény is csökkenthető, és így mindenki a legaktuálisabb adatokhoz férhet hozzá.

Ellenőrzött redundancia

Mivel több alkalmazás is ugyanazt az adatbázist használja, ezért a felhasznált adatok is egy helyen, egy kézben összpontosulnak. A hagyományos fájl kezelésnél ha több alkalmazásnak is szüksége volt egy adatra, akkor az adat több fájlban is letárolásra került. Ez a redundancia számos hátránnyal járt, kezdve a felesleges helyfoglalástól a konzisztencia megőrzésének problémájáig.

Hozzáférési jogosultságellenőrzés, adatvédelem

A DBMS az operációs rendszerekhez hasonlóan nyilvántartja a jogosult felhasználókat. Ennek során nyilvántartja az azonosító nevet, a jelszót, a tulajdonában lévő adatokat, az engedélyezett műveleteket. Az adatvesztés okozta károk minimalizálására mind statikus mind dinamikus védelem használható. A statikus védelem egyik eszköze a mentés, a dinamikus védelemhez pedig a naplózás tartozik.

Optimalizált fizikai adatszerkezetek

A DBMS-ben implementálták mindazokat a hatékony adatstruktúrák kezelésére (mint hashing, indexelés, stb.) alkalmas algoritmusokat, melyekkel jelentősen javítható a műveletek hatékonysága, gyorsasága. Normál fájlkezelés esetén, nagyobb méretű adatszerkezetek esetén a programozónak kellene mindezen hatékonyabb adatstruktúrákat megvalósítania.

Integritási feltételek érvényesítése

A DBS keretén belül magában az adatbázisban tárolhatjuk az adatok között fennálló integritási szabályok formájában. Az adatbázis módosításakor automatikusan ellenőrzi a DBMS, hogy nem sérült-e meg az integritási szabály. Ha megsérülne, akkor nem hajlandó elfogadni a változtatást. Mivel mindezt a DBMS végzi, nem a felhasználói programnak nem kell törődnie az integritási problémák teljességével. A hagyományos fájlkezelésnél a programozó vállán volt minden felelőség.

Szabványosság, hatékonyság, rugalmasság

A szabványos adatmodellek és kezelő felületek, interfac-ek használatával az elkészült rendszer jobban érthetővé válik mások számára is, ezáltal későbbi fejlesztés, módosítások is könnyebbé válnak. A fejlesztő a DBMS-en keresztül jobban rákényszerül a szabványos eszközök használatára, mint a több szabadságot nyújtó normál fájlkezelésnél. Emellett az sem

Page 4: 1144. 13.tétel

elhanyagolható, hogy a DBMS-ekhez számos fejlesztő eszköz áll rendelkezésre, jelentősen megnövelve a fejlesztés hatékonyságát. A szükséges változtatások gyorsabban végrehajthatók, nagyobb rugalmasságot biztosítva a rendszernek.

A fájlrendszerek előnyei

A felsorolt előnyök ellenére vannak olyan esetek, amikor célszerűbb a normál fájlkezelést választani. Ennek elsősorban az az oka, hogy a biztonságos, hatékony adatbáziskezelés biztosítását meg kell fizetni a felhasználónak, mely többlet időt és többlet költséget is jelent. Ezért nem célszerű adatbázist használni, ha

Az alkalmazás, az adatrendszer viszonylag egyszerű, s nem várhatók változtatások az adatrendszerben, a jövőben sem. Ekkor felesleges beruházás a drágább DBMS beszerzése.

Az alkalmazás real-time követelményeket támaszt az adatrendszerrel szemben, azaz nagyon gyors adatkezelésre van szükség. Ez a DBMS összetettsége miatt nem biztosítható.

Egy felhasználós adatrendszer esetén, amikor konkurens hozzáférés nem fordulhat elő. Ekkor maga az alkalmazás kézben tudja tartani az adatintegritás megőrzését, az adathozzáférés biztosítását. Ugyan nagyobb időráfordítással, de költségkímélőbben meg lehet oldani a feladatot a normál fájlkezeléssel.

Ha a feltételek mérlegelésével megszületett a döntés, hogy DBS-t alkalmaznak, akkor kezdődhet el a DBS fejlesztésének igazán érdekes és izgalmas folyamata. Ennek során ki kell választani a megfelelő adatmodellt és DBMS-t, el kell készíteni a modellezett valóság megfelelő adatmodelljét, létre kell hozni az adatbázist és a szükséges alkalmazói programokat is. Végül a szakemberek hosszú együttes munkájának eredményeként megszülethet az igényelt adatbázis rendszer.

Adatbáziskezelõ rendszerek létrehozása

Adatbáziskezelõ rendszert alapvetõen kétféleképpen szoktak létrehozni. Az egyik módja, hogy egy programozó csoport valamelyik - többnyire harmadik generációs - programozási nyelvben (pl. C, Cobol) megírja a rendszert. A másik módszerben pedig egy már meglévõ rendszerben fejlesztik ki az új rendszert. Ehhez többnyire negyedik generációs nyelveket használnak. Ilyen típusú rendszerek a CASE (számítógép által támogatott szoftver fejlesztõ) rendszerek. A legtöbb adatbáziskezelõ rendszer rendelkezik ilyen CASE eszközökkel. Továbbá vannak alkalmazásfejlesztõ rendszerek is, például: QBE, POWER BUILDER, UNIFACE. A legismertebb adatbáziskezelõ rendszerek manapság az ORACLE, INGRES, SYBASE, INFORMIX. Ezek többnyire nagygépes környezetben mûködnek. Természetesen vannak PC-re íródott adatbáziskezelõ programrendszerek is, mint például: DBASE, CLIPPER, FOXPRO.

Az adatbázis létrehozását mindig az adbázistervezés elõzi meg. Gondosan fel kell mérni az adott cég igényeit, meg kell fogalmazni a problémákat. Egy adatbázist manapság körülbelül egy-két hónap alatt fejlesztenek ki. Ennek körülbelül 70-75%-a a tervezésre megy el, 10-15%-a a programozásra és a maradék a tesztelésre. Alapos tervezés nélkül ugyanis a rendszer átláthatatlan lesz, nagyon nehéz lesz a késõbbiekben módosítani.

Page 5: 1144. 13.tétel

Az adatbázistervezés, az adatok jellegének vizsgálata és a köztük levõ kapcsolatok alapos elemzése után következhet az adatmodell létrehozása.

Adatmodellezés

Az adatmodellezés tehát az adatállományok tervezésének korszerû módszere. Az adatmodellezéssel az a célunk, hogy egy információs rendszer adatait és az adatok között fennálló kapcsolatokat következetesen ábrázolva, elõsegítsük a számítógépes információ-feldolgozást. Az adathalmaz és az adathalmaz elemei között fennálló kapcsolatok struktúrált leírását adatmodellnek nevezzük. Az adatmodellek -mint ahogy a nevükbõl is következik-, általában nem írják le teljesen és hûen a modellezett rendszerben található adatokat és azok kapcsolatait, hanem azoknak csak egy részét. Egy kielégítõ modellnek teljesítenie kell bizonyos feltételeket: átfogónak kell lennie, azaz minden lehetséges adatot és minden lehetséges kapcsolatot tudnia kell ábrázolni és kezelni; le kell tudnia írni a valóság általános, lényeges és tartós összefüggéseit; redundanciamentesnek kell lennie, azaz minden adatot lehetõleg csak egyszer tartalmazzon; következetesnek kell lennie; valamint az alkalmazott hardverrel és szoftverrel összhangban levõnek kell lennie

Az adatmodell nemcsak felsorolása a fileban tárolt mezõknek, hanem az adatok jelentését is tartalmazza. Így az adatmodellben

világosan megkülönböztethetõk az ábrázolt dolgok és a dolgok tulajdonságai; pontosan meghatározott, hogy melyek az ábrázolandó dolgok olyan tulajdonságai,

amelyekkel a dolgok egyértelmûen azonosíthatók; valamint az adatmodell expliciten definiálja az ábrázolt dolgok közötti kapcsolatokat.

Az adatmodell a valóság egy szeletének a leképezését jelenti. A valós világhoz képest az adatmodellek tartalmaznak bizonyos megszorításokat és egyszerûsítéseket, sõt még a modellezõ személyétõl függõ vonásokat is. Egy adatmodell úgy viszonyul a valósághoz, mint a térkép az általa ábrázolt tájhoz: a térképrajzolónak egyszerûsíteni kell, ki kell jelölnie a térkép széleit, és el kell döntenie, hogy mit is akar egyáltalán a térképen feltüntetni. Ugyanígy, az adatmodell kialakításakor a rendszerszervezõnek is el kell döntenie, hogy melyek a modelljében az ábrázolandó információelemek, és ki kell választania a dolgok között fennálló lényeges kapcsolatok közül azokat, amelyeket be akar a modellbe építeni. A lényeges információelemek és a modellben ábrázolandó kapcsolatok kiválasztása párhuzamosan történik.

Egy adatmodell a következõ elemeket tartalmazza:

egyed, tulajdonság, kapcsolat.

Vagyis:

Egyedek a valóság olyan dolgai, amelyek más dolgoktól megkülönböztethetõk, azaz az egyed a valós világban létezõ, fogalmi vagy fizikai léttel rendelkezõ dolog, amelyet tulajdonságokkal akarunk leírni. (pl. dolgozó, tanuló, vevõ, autó, stb.) Ugyanaz a dolog többféle egyednek is tekinthetõ (pl. egy személy lehet dolgozó), de a képviselt

Page 6: 1144. 13.tétel

konkrét elemek halmazát egyedhalmaznak nevezzük. (a vevõ, mint egyedhalmaz az összes vevõt tartalmazza)

Tulajdonságnak nevezzük a valóság dolgainak azon jellemzõit, amelyekkel az egyedeket leírjuk. (pl. autónál tulajdonság a típus, szín, rendszám, stb. A típus értékei lehetnek: BMW, Opel, stb.) Az egyedek a tulajdonságértékeikkel azonosíthatók.

Kapcsolatnak nevezzük az egyedek közötti viszonyok fogalmi tükörképeit. Objektumok közötti viszony pl. az, hogy a munkás a kft. dolgozója. Ennek egy konkrét elõfordulása pl. Kovács János a Zabhegyezõ kft. dolgozója.

Ezen felsorolt adatmodell-elemek mindegyikének három szintje van:

Belsõ, vagy fizikai szint: az adatok fizikai elhelyezését és fizikai elérési módját írja le. Azaz leírja a tárolás és az elérés módját. A tárolási mód megadja, hogy melyik lemezen fizikailag hol helyezkednek el az adatbázis adott rekordjai és azt, hogy milyen konverziót kell ahhoz elvégezni, hogy az adat a felhasználóknak megfelelõ formájú legyen. Az elérési mód megadja, hogy hogyan, milyen sorrendben követik egymást a rekordok, hogyan érhetjük el õket. Tipikus elérési módok: fizikai sorrendben, valamilyen mezõ szerint rendezve, közvetlenül indexek alapján.

Külsõ szint (view-k): melyek azt írják le, hogyan látják az egyes felhasználók az adatbázist. (view= alséma, szûkített adatbázis, amely az adatbázis rekordjait tartalmazza, de nem az összes mezõvel.)

Koncepcionális szint (fogalmi adatbázis): mely azt írja le, hogy logikailag egységbe vonva, hogyan néz ki ténylegesen az adatbázis. Azaz leírja. hogyan néznének ki az adatok, ha mindenki mindent láthatna belõlük. Ezt a leírást szoktuk az adatbázis sémájának nevezni. Ez tartalmazza a koncepcionális szint összes rekordtípusának tartalmi leírását, de az adatfüggetlenség érdekében nem tartalmazza az adatok helyét és a hozzáférési módot. Ugyancsak ez a szint írja le, milyen kapcsolatok vannak az egyes rekordok között. A kapcsolat leírásának módja az adatmodelltõl függ.

Még két fogalmat kell tisztáznunk a továbbiak miatt:

Séma (típus): a konkrétan létezõ egyedek, tulajdonságok, kapcsolatok absztrakciója. Az egyedek bizonyos tulajdonságtípusaik alapján halmazokba rendezõdnek. Egy-egy halmaz neve az egyed típusa, a halmazba tartozó egyedek az elõfordulások, megfelelõ tulajdonság elõfordulásokkal. Ez a szint tartalmazza az egyedtípusok tartalmi leírását, de az adatfüggetlenség érdekében nem tartalmazza az adatok helyét és a hozzáférési módot. Ugyancsak ez a szint írja le, hogy milyen kapcsolatok vannak az egyedek (rekordok) között. A kapcsolatok leírásának módja az adatmodelltõl függ.

Elõfordulás: konkrétan létezõ egyed, tulajdonságérték, kapcsolat.

Adatfüggetlenség

Mivel ugyanazon adatokat több felhasználó és több program is használhatja, az adatokat és a programokat - amennyire lehetséges - függetleníteni kell egymástól: ha például valamelyik programban a rekordokat kibõvítjük egy mezõvel, akkor ne kelljen a többi programot megváltoztatni. Az adatok fizikai leírását külön kell választani a programok által látott adatszerkezettõl. Ez az adatfüggetlenség. Az adatfüggetlenségnek két fokozata van:

fizikai adatfüggetlenségrõl beszélünk, ha a programok vagy felhasználók információkérései gyakorlatilag függetlenek az adatok tárolási és elérési módjától;

Page 7: 1144. 13.tétel

logikai adatfüggetlenségrõl beszélünk, ha az adatbázis logikai szerkezetében létrehozott változások az adatbázist felhasználó programokat nem befolyásolják.

A tényleges adatfüggetlenség e kettõ együttes megvalósulása.