arabera Viktoria Kovacs 7 years ago
380
Honelako gehiago
Nagyon nehéz feladat a megfelelő relációs adatbázis kiválasztása egy cég/szervezet vagy akár egy magánszemély számára is, ugyanis a választáskor rengeteg szempontot szem előtt kell tartani. Az árak, valamint a teljesítmény mellett még rengeteg más olyan kritériumok is vannak, amiket figyelembe kell vennünk. Emellett ezek a kritériumok még nagyon összetettek is, hiszen számos aspektusuk van és sok-sok összetevőből állnak. A relációs adatbázis kiválasztásának széleskörű következményei vannak egy cég működését illetően, ugyanis ezek a döntések kb. 5-10 évre szólnak, amiket lehet, hogy sosem változtatnak meg. Ha nem megfelelő a választás, akkor a későbbiekben ez komoly, akár visszafordíthatatlan üzleti károkat is okozhat. Továbbá minden alkalmazottnak más-más igényei vannak az adatbáziskezelő rendszereket illetően, hogy ki melyiket szeretné használni. Ez pedig befolyásoló hatással lehet a személyzeti kérdésekre is, valamint a szoftverrendszerekre is. Ez a döntés azért is nagyon fontos, mert az informatikára elköltött pénzek jelentős része gyakran erre megy el. Természetesen még költenek nagyon sok más mindenre is (pl. virtualizáció), de erre költenek a legtöbbet. A relációs adatbázisoknak vannak olyan kötelezően elvárható és opcionális képességeik, amelyeket ezen döntés meghozatalakor fontos mérlegelni.
------------------------------------------------------------------
A gondolattérképet az előadás diák és a saját jegyzeteim felhasználásával készítettem. Ahol nincs megjelölve külön forrás, ott az ezekből származó információkat használtam fel.
------------------------------------------------------------------
Vannak olyan képességek, amelyekkel a relációs adatbázisoknak szinte kötelező rendelkezniük a zökkenőmentes működés érdekében.
Automatikus végrehajtási terv generátor.
A metaadatok összességét relációs adatbázisoknál Adatszótárnak (Data Dictionary) hívjuk. Metaadat nem más, mint adat az adatról, az adatbázisban található táblák, indexek, nézetek, és egyéb objektum típusok információi tartoznak ide.
Például indexek típussal rendelkeznek, és vannak táblaoszlopaik, amelyeket indexelnek, a nézetekhez az őket meghatározó SELECT-definíció tartozik,...stb.
Ezek az információk az adatbázisról központi, csak olvasható referencia táblákban (szótártáblák) tárolódnak, de a szótárnézetek is az adatszótár részei.
------------------------------------------------------------------
Forrás:
------------------------------------------------------------------
Szótárnézetek
ALL_kezdetű nézetek
Elérési útvonal: SQL Developer > Connections > Other users > SYS > Views > ALL_
Lekérdezéssel:
SELECT * FROM DICTIONARY
WHERE TABLE_NAME LIKE 'ALL%';
A csatolt linken a tábláról található kép.
DBA_kezdetű nézetek
Elérési útvonal: SQL Developer > Connections > Other users > SYS > Views > DBA_
Lekérdezéssel:
SELECT * FROM DICTIONARY
WHERE TABLE_NAME LIKE 'DBA%';
A csatolt linken a tábláról található kép.
USER_kezdetű nézetek
Elérési útvonal: SQL Developer > Connections > Other users > SYS > Views > USER_
Lekérdezéssel:
SELECT * FROM DICTIONARY
WHERE TABLE_NAME LIKE 'USER%';
A csatolt linken a tábláról található kép.
Szótártáblák
Datafile-ok táblája
Táblaterek táblája
Nézetek táblája
Elérési útvonal: SQL Developer > Connections > Other users > SYS > Tables > VIEW$
A csatolt linken a tábláról található kép.
Oszlopok táblája
Elérési útvonal: SQL Developer > Connections > Other users > SYS > Tables > COL$
A csatolt linken a tábláról található kép.
Indexek táblája
Elérési útvonal: SQL Developer > Connections > Other users > SYS > Tables > IND$
A csatolt linken a tábláról található kép.
Táblák táblája
Úgy tudjuk elérni SQL Developerben, hogy a Connections ablakban a saját kapcsolatunkra kattintunk, ott legörgetve megnyitjuk az Other Users mappát, és kiválasztjuk a SYS felhasználót, majd itt a Tables mappában megtaláljuk a TAB$ táblát.
A csatolt linken a tábláról található kép.
Az adatbázis kényszerek adatintegritási szabályok, amelyek a táblákra és azok oszlopaira vonatkoznak, vagy deklaratív adatintegritási szabályoknak is szokták hívni őket.
A kényszerek arra szolgálnak, hogy jellemezhessük, illetve korlátozhassuk az adatbázisaink tartalmát.
------------------------------------------------------------------
Forrás: Korábbi előadás diasorai (7. előadás)
------------------------------------------------------------------
Az ACID tulajdonság az adatbázisoktól elvárt képességeknek a halmazát jelenti.
------------------------------------------------------------------
Forrás: Korábbi előadás diasorai (4. előadás)
------------------------------------------------------------------
A tartósság azt jelenti, hogy ha egy tranzakció már jóváhagyásra került, akkor az végleges, tehát nem tud elveszni még egy áramszünet hatására sem.
Az izoláció azt jelenti, hogy megengedett a tranzakciók egy időben történő végrehajtódása, de az eredmény azonos lesz, mintha sorosan, azaz egymás után történtek volna meg a tranzakciók.
A konzisztencia az adatbázisoknak az a tulajdonsága, hogy tartalmukat a tranzakciók egyik konzisztens (érvényes) állapotából átvezetik egy másik érvényes állapotba.
Az atomicitás azt jelenti, hogy a tranzakció során végbement SQL folyamatok sorozatának vagy teljesen egészében érvényre kell hogy jusson, vagy pedig azoknak minden módosítása visszavonásra kell hogy kerüljön. Tehát nem lehet fele véglegesített, másik fele pedig visszavont.
Tranzakciónak nevezzük az SQL, azaz DML műveleteknek azon sorozatát, amely vagy teljes egészében érvényre jut, vagy pedig annak minden módosítása visszavonásra kerül.
A tranzakciók arra szolgálnak, hogy logikailag csoportosíthassuk a módosításainkat.
------------------------------------------------------------------
Forrás: Korábbi előadás diasorai (4. előadás)
------------------------------------------------------------------
DDL, DML, Query
Az adatbázis logikai szerkezetét tekintve, adatbázisunk táblákat, kényszereket, nézeteket, indexeket, stb.. tartalmaz.
Mivel az adatok vándorolnak egyik helyről a másikra, fontos a megbízható tranzakciókezelés két adatbáziskezelő között.
Adatbázis-szoftver közti kommunikáció
Tranzakciókezelés egy adatbáziskezelő rendszer, valamint egy másik szoftver között, mint például egy üzenetküldő rendszer.
Az üzenetküldő rendszer egy üzenettovábbító rendszer, amely ugyanolyan érdekes szoftver, mint az adatbáziskezelő, csak garantálni kell az adatok továbbítását, valamint azt, hogy az adatot a másik fél meg is kapja.
A megbízható tranzakció történhet az illető cég specifikus saját módján történő összeköttetéssel, vagy pedig XA protokollon keresztül.
Adatbázis-adatbázis közti kommunikáció
Különböző adatbáziskezelő
Két különböző adatbáziskezelő közötti adatátvitel az XA tranzakciók segítségével történik. Az XA protokoll egy ősrégi protokoll, amit még az IBM dolgozott ki. Jobb az az adatbáziskezelő rendszer, amely támogatja ezt az XA tranzakciót, ugyanis ezáltal elképzelhetővé válik a megbízható elosztott tranzakció.
Azonos adatbáziskezelő
Két Oracle adatbáziskezelő rendszer között az adatátvitel adatbázis link és kétfázisú jóváhagyási mechanizmus által történik.
Az adatbázis triggerek olyan képességek, ami által bizonyos programok maguktól végrehajtódnak az egyes események bekövetkeztekor, feltételezve azt, hogy a procedurális nyelv már rendelkezésre áll.
Egyéb triggerek
Post-INSERT triggerek
Az adatok beszúrás után hajtódnak végre, amelyeket gyakran a műveletek naplózása érdekében használjuk.
Pre-INSERT triggerek
Az adatok beszúrása előtt hajtódnak végre, amelyeket általában a beszúrás ellenőrzésére használunk.
Az SQL nyelv nagyszerű, de néha lehet nem elég. Az SQL nyelv egy nem procedurális nyelvnek felel meg.
Ez azt jelenti, hogy a felhasználó csak azt mondja meg, hogy mit akar. Azt, hogy ez hogyan, és milyen lépések sorozatával valósuljon meg, azt már a nyelvnek az értelmezője fogja meghatározni.
Szükségünk lehet bizonyos algoritmusokra és ezek tárolására az adatbázison belül, ezért szükségünk van a funkcionalitás kiterjesztésére.
------------------------------------------------------------------
Forrás: Online irodalom: Quittner Pál, Baksa-Haskó Gabriella: Adatbázisok, adatbázis-kezelő rendszerek
http://miau.gau.hu/avir/intranet/debrecen_hallgatoi/tananyagok/jegyzet/25-Adatbazisok.pdf
------------------------------------------------------------------
A funkcionalitás kiterjesztése történhet azáltal, hogy maga a gyártó fejleszt ilyen kiterjesztést, vagy pedig a felhasználó is kifejlesztheti a saját kiterjesztéseit (például új függvények bevezetése, amelyek kiszámolják az ÁFá-t vagy az SZJA-t).
A funkcionalitás kiterjesztésével a kényszerek halmaza is kibővíthető, továbbá az objektumorientált metódusok is procedurális nyelvben íródnak.
Az Oracle esetén két ilyen procedurális nyelv áll rendelkezésünkre.
SQL-en túlnyúló igények
Azoknak a cégeknek, illetve embereknek, akik használják az adatbázisokat lehetnek olyan igényeik, amelyek már túlmutatnak az SQL-en, de praktikusak lehetnek.
A funkcionalitás kiterjesztése történhet a gyártó által is, ha az adatbázison belül létezik procedurális lehetőség, vagy pedig ha nyílt forráskódú rendszerről beszélünk, akkor maga a felhasználó is kifejlesztheti a saját kiterjesztéseit.
Segédeszközök
Sokszor felmerülnek különböző igények a gyakorlatban, olyan feladatok hatékony elvégzésére is, amelyek nem SQL-ek.
Ilyen nem SQL igénynek számít az adatbetöltés és áthordozás is, melyek megvalósítására a gyakorlatban az Oracle esetén az SQL*Loader és az Oracle Data Dump eszközök nyújtanak segítséget.
Adatáthordozás
Igény lehet az adatok áthordozására is adatbázistáblákból bináris állományokba, majd ezeknek a visszatöltése ugyanabba, vagy egy teljesen másik adatbázisba.
Adatbetöltés
Ilyen igény lehet például az adatok betöltése az adatbázistáblákba, ami történhet különböző adattípusú fájlokból:
Az adatbetöltésre szolgáló SQL*Loader eszköz használatáról itt látható egy videó:
Üzenetek küldése/fogadása
Fájlok olvasása/írása
E-mailek küldése
Ütemezett feladatok végrehajtása
Java
Nem igazán vált be az Oracle adatbázison belül.
PL/SQL
Nagyon népszerű.
Szándékosan nem az elsők között került megemlítésre a hatékonyság, mint szempont, ugyanis a relációs adatbázisok választásánál gyakran eshetünk abba a korai hibába, hogy a performancia alapján döntünk.
Vannak olyan esetek, amikor ez nem jó, hiszen egy erősebb hardverarchitektúra használata néha több előnnyel jár, mint egy szuper nagy teljesítményűnek gondolt szoftver. Azért mert az adatbáziskezelőket illetően a magas teljesítmény szint a funkcionalitás rovására is mehet. Ha pedig azért gyorsabb egy rendszer, mert nem merevlemez-alapú, hanem a memóriában dolgozik, akkor ennek az a hátránya, hogy magasabb lesz az esélye a sérülékenységnek.
A legtöbb rendszer gyártója törekszik arra, hogy optimalizálja a teljesítményt, azaz az adatbáziskezelők hatékonysági mutatóit növeljék. Azt mondják, hogy az újabb szoftverek mindig gyorsabbak, de sajnálatos módon ez 100-nól 99 esetben nem igaz, mert mindig lassabban működnek egy kicsivel, mint a régebbi szoftver.
Az audit egy olyan adatbáziskezelő rendszerbeli eszköz, amely lehetővé teszi az adatbázis-adminisztrátornak, hogy kövesse az adatbázis erőforrásainak a használatát biztonsági célokból.
Mivel az audit opcionálisan eldönthető, ezért ha úgy döntünk, hogy legyen audit, akkor fontos, hogy az auditsor részletessége konfigurálható legyen.
Ez az auditsor magában foglalja azt, hogy a művelet milyen adatbázis-objektumokra volt hatással, ki hajtotta végre a műveletet és mikor. Fontos, hogy az audit működtetése nem lassíthatja számottevően a rendszert, de az auditeszközök legnagyobb hibája általában a teljesítménydegradáció.
Ha az auditálás mellett döntünk, akkor azt úgy kell csinálnunk, hogy hasznunk származzon belőle!
Hatalmas jelentősége van annak, hogyha egy rendszer szakember által monitorozható, ugyanis így kideríthető, hol vannak "dugulási", "elakadási" problémák a rendszerben, amelyeket aztán hangolással ki lehet küszöbölni.
Ha a működés még át is paraméterezhető úgy, hogy a szűk keresztmetszetek eltűnjenek vagy csupán enyhüljenek, akkor ebből már rengeteg előnyünk származhat.
Azonban fontos, hogy nyílt rendszerekről beszéljünk, azaz a monitorozhatóság SELECT utasításokkal kell, hogy történjen, annak érdekében, hogy a későbbiekben egyre több szakember tudja monitorozni a rendszert.
Automatikus monitorozás
Mivel manapság már egyre több adatbáziskezelő rendszert működtetünk, a szakembereknek nehéz folyamatosan odafigyelni rájuk, épp ezért nő az automatikus monitorozás jelentősége.
Az automatikus monitorozás azt jelenti, hogy a rendszerek saját magukat belülről is figyelik az szakemberek kívülről történő monitorozása mellett, és ha valami probléma, hiba lép föl a rendszer működésében, akkor az automatikusan riasztást küld.
Azok a rendszerek a legjobbak, amik a riasztás után nemcsak megoldást javasolnak a probléma kiküszöbölésére, hanem meg is oldják azt automatikusan.
Az Oracle esetében ezért az automatikus monitorozásért külön fizetni kell.
Akkor jó egy adatbáziskezelő rendszer, ha saját mentési programmal rendelkezik, amivel nem csak a mentés valósítható meg, hanem egyúttal a lementett adatok logikai ellenőrzése is. További előny az, hogyha ez a mentési program az adatbázis belsejébe van beépítve.
Fontos továbbá az is, hogy a mentési program biztosítsa az alábbi lehetőségeket:
Inkrementális
A teljes mentéssel szemben, az inkrementális mentés esetén csak azokat az adatváltoztatásokat menti le a rendszer, amelyek az utolsó mentés óta történtek.
Teljes
A teljes mentés azt jelenti, hogy az adatbázis minden objektumát, és azoknak a teljes adattartalmát képmásolati állományba vagy állományokba menti az adatbáziskezelő-rendszer.
A különböző cégeknél gyakran felmerül az a kérdés, hogy vajon kell-e félniük a rendszergazdáktól az adatbiztonságot illetően.
Ha félünk a DBA-k, valamint más rendszerek rendszergazdáinak a jogosultságaitól, akkor létezhet olyan megoldás, ahol semmilyen rendszergazda nem férhet hozzá az adatokhoz. Az Oracle adatbázis esetén ezt a fajta megoldást, Oracle Database Vaultnak nevezzük és az Orace Enterprise Edition-ben található meg.
Az Oracle Database Vaultról további információk a csatolt linken találhatók.
Oracle Database Vault
A csatolt linken három kép található az Oracle Database Vault kinézetéről.
A merevlemez-alapú adatbázisok esetében az adatok a fájlokban tárolódnak a merevlemezen.
Ez a tárolás komoly veszéllyel fenyeget, ugyanis így könnyebb hozzájutni az adatokhoz például eltulajdonítás által.
Fontos tehát megfontolni az adattitkosító szoftverek használatát az adatbázis-állományokra.
Az adattitkosítás egy olyan biztonsági technika, amely kódolja az olvasható adatokat az állományban. Tehát az adatbáziskezelők a korábban említett veszély ellen adattitkosítással védekeznek.
Ilyenkor az történik, hogy maga az INSERT utasítás már titkosítva ír, és ezt a titkosítást a SELECT utasítás tudja visszafejteni.
Oracle esetén ezeket az adattitkosító szoftvereket Transparent Data Encryption-nak és Oracle *Net Encryption-nak nevezik.
Oracle *Net Encyption
Transparent Data Encryption
A csatolt videón a Transparent Data Encryption szoftver felépítését és jellemzőit láthatjuk az Oracle Standard Edition esetén:
A teljes, azaz a 100%-os adatbiztonság biztosítása az adatbáziskezelőknél lehetetlen. De mégis ajánlatos a szoftver kiválasztása előtt néhány dolognak után nézni, annak érdekében, hogy ha nem is 100%-osan, de biztonságosabban érezhessünk magunkat, hiszen az adatlopások, feltörések nagyon veszélyesek tudnak lenni akár egy cég, akár egy magánszemély számára is.
Fontos utánanézni a alábbi dolgoknak:
Az idő elteltével nem csak összeomlásról vagy leállásról beszélhetünk a rendszert illetően, hanem akár adatvesztésről is (pl. lemezhiba miatt).
Ennek az adatvesztésnek a helyreállítási ideje kritikus is lehet, ugyanis jobb esetben egy néhány perc alatt megvan, de lehet olyan is, hogy több órába telik a teljes visszaállítás. Éppen ezért fontos szempont a helyreállítási módszer egyszerűsége, illetve fontos, hogy legyen megoldásunk arra is, ha valami kellemetlenebb meghibásodás, vagy akár többszörös hiba lép fel.
Az adatok könnyebb helyreállítása érdekében pillanatfelvételeket (snapshot-kat) szokott készíteni az adatbázisrendszer adott táblákról és nézetekről.
De sajnálatos módon olyan megoldás, ami minden esetben abszolút biztosan működik, olyan nincs.
A legoptimálisabb mentési mechanizmus olyan, hogy biztosítja egyszerre a restore-t és a recovery-t is.
Recovery
Legfrissebb állapotba való helyreállás.
Restore
Régi mentésre való visszaállás.
A ténylegesen várható veszélyeken kívül, illik felkészülni olyan szituációkra is, amelyet az ember egyáltalán nem gondolna:
-tűzvész
-árvíz
-földrengés
-terrortámadás
-stb.
Ezek ellene egyre többen a távoli adatbázis másolatokkal próbálnak védekezni.
Adatbázis-másolatok
Az adatbázis másolatok megoldhatják a hardverek és szoftverek közötti távoli tükrözést is, amely akár extra képességnek is számíthat az adatbázisoknál.
Oracle esetén a DataGuard tekinthető katasztrófatűrő megoldásnak. Az Oracle Data Guard magas rendelkezésre állást, adatvédelmet és katasztrófa okozta teljes helyreállítást biztosít.
A DataGuardról további információt a csatolt linken olvashattok.
Lineáris skálázhatóság
A terhelés vs. teljesítmény problémára, a lineáris skálázhatóság lenne egy jó megoldás. Ez a linearitás azt jelenti, hogy kétszer annyi hardverrel, kétszer annyi munka lenne elvégezve (egyre több számítógép a fürtben, ezeknek működése skálázható-e).
De sajnos ez csak egy álom.
Az Oracle esetén a skálázhatóságra a RAC (fürtözött számítógépek) lenne a megoldás, ugyanúgy mint a magas rendelkezésre állásnál is.
Terhelés vs. teljesítmény
A skálázhatóság esetében arra a kérdésre kell tudni válaszolni, hogy ha növekszik a terhelés, akkor ezzel párhuzamosan lehetséges-e a teljesítmény növelése.
De facto szabvány
A relációs adatbázisoknak a de facto szabványa az SQL, de ettől függetlenül még nem szabványosak annyira, hogy egyik szoftverből a másikba könnyen tudjanak a felhasználók adatot átvinni.
Ezen a szabványosításon belül, előnynek számít, ha a gyártó betartja az SQL szabványt és annak részleteit.
Ha a szabványtól eltérő utasításokat használnak, abból származhat előny is, de egyaránt kockázatosak is.
Azért kockázatosak, mert idő múltával, ha adatbáziskezelő váltásáról gondolkodunk, akkor nehéz lesz az adatokat átmásolni az egyik adatbáziskezelőből a másikba.
Továbbá megszűnhet akár a szabványokon túlmutató utasításokra vonatkozó támogatás is.
Manapság már egyre fontosabbá válik a 'High Availability', azaz a rendszer magas szintű rendelkezésre állásának a biztosítása.
Azonban még most is lennie kell valamiféle állásidőnek, ugyanis néhány szoftvernek, mint például az operációs rendszernek, az adatbáziskezelő rendszernek vagy az adatszótárnak a frissítése eléggé problémás tud lenni.
Az elérhetőséget alapvetően a teljes idő azon százalékában fejezik ki, mely alatt egy szolgáltatásnak működnie kell. Például: ha egy rendszer 99%-os elérhetőséggel rendelkezik, akkor az az idő 99%-ban elérhető lesz, míg a maradandó 1%-ban lesz csak elérhetetlen.
Az elérhetőség meghatározására a MTBF (mean time between failure) mutató nyújt segítséget, amely kiszámolja a meghibásodások közötti átlagos időtartamot.
A internet korában már azt várnák el az adatbázisoktól, hogy az év minden napján leállás nélkül működjenek, de sajnos ez lehetetlen.
------------------------------------------------------------------
Forrás: Online irodalom: Vágner Anikó, Juhász István: Adatbázis-adminisztráció, 2011
http://progmat.hu/tananyagok/adatbazis_adminisztracio/book.html
------------------------------------------------------------------
Öt kilences
Az öt kilences kifejezést szokták gyakran használni a magas elérhetőségű rendszerek leírására, ami 99,999%-os működést jelent. Az öt kilences olyan rendszereket ír le, amelyekek alapvetően 100%-osan elérhetőek, de természetesen néhány leállás elkerülhetetlen. Az 99,999%-os elérhetőség évi 5-6 perc leállást jelent, míg a 99%-os már évi 87,6 órát, azaz több mint 3 napot.
Oracle esetén a legjobb opció, ami magas rendelkezésre állási képességgel bír az a RAC, ami a fürtözött számítógépeket jelenti.
------------------------------------------------------------------
Forrás: Online irodalom: Vágner Anikó, Juhász István: Adatbázis-adminisztráció, 2011
http://progmat.hu/tananyagok/adatbazis_adminisztracio/book.html
------------------------------------------------------------------
Állásidő
A leállás minden cég számára nyomot hagy az üzleti tevékenységén és ez bármilyen méretű állásidő költséget is jelenthet. Ez a költség cégenként természetesen változik, de mindenki magának becsüli meg az állásidő költségét.
Amikor ezt becsüljük, akkor érdemes három tényezőt figyelembe venni:
Az állásidőnek alapvetően két fajtáját ismerjük: a betervezettet, amelyet általában előre bejelentenek, illetve a nem betervezettet, amelyet valamilyen hiba okoz. Természetesen a betervezett leállásnak kisebb állásidő költségei lehetnek, mint a hiba általinak.
------------------------------------------------------------------
Forrás: Online irodalom: Vágner Anikó, Juhász István: Adatbázis-adminisztráció, 2011
http://progmat.hu/tananyagok/adatbazis_adminisztracio/book.html
------------------------------------------------------------------
A jó adatbáziskezelő rendszert mindenhol megtaláljuk szerte a világban, ugyanis nagyon sok munkahelyen ugyanazt használják.
Az adatbáziskezelő kiválasztásakor nem az a lényeg, hogy a divatos rendszert válasszam, hanem az, hogy olyan rendszert használjak, ami elterjedt, rengeteg helyen használják már, ugyanis ez az elterjedtség számos előnnyel jár:
Jó adatbáziskezelő rendszer
Amikor döntés előtt állunk és el szeretnénk kerülni a kockázatot, akkor fontos, hogy olyan adatbáziskezelőt válasszunk, amit már több ezren, százezren használtak, hogy az esetleges problémákat, amivel mi is szembesülhetnénk már valaki más észrevegye előttünk és tudjunk belőle okulni.
Az a jó adatbáziskezelő szoftver, amit már nagyon sokan alkalmaztak. Fontos, hogy tájékozottak legyünk ezen a területen, tudjuk, hogy melyek a legjobb, legtöbb ember által használt szoftverek. Ha például internet bankingot akarok működtetni, akkor ezen a területen kell nézelődnöm. A telekommunikációs szektorban egyértelműen az Oracle adatbáziskezelő rendszere dominál, szinte "tarol" ebben a mezőnyben. Az olaj iparban pedig az IBM rendszerei dominálnak. Tehát elmondhatjuk, hogy minden ágazatnak van egy domináló szoftvere.
Ha valamilyen kételyünk támad a szoftvert illetően, akkor az interneten mindent megtalálunk. Ha például kapunk egy hibaüzenetet és begépeljük a Google-be, akkor találhatunk rá rengeteg megoldást.
Manapság azt szokták mondani, hogy a jó adatbáziskezelő rendszer olyan, mint a jó bor: minél öregebb, annál jobb. Azonban annak, hogy egy adatbáziskezelő idős, természetesen vannak hátrányai is, de általában jellemzőbbek az előnyök.
Bug
Sajnálatos módon minden szoftver bug-os, ami azt jelenti, hogy sokszor állhat fent számítógépes programhiba. Amikor ez előfordul, akkor a szoftver hibás eredményt ad és a tervezettől eltérően működik.
Ezzel a ténnyel minden adatbáziskezelő rendszer esetében meg kell barátkozni.
Régebben a Latin2 kódolás volt. Ma már az Unicode támogatása de-facto szabvánnyá vált.
Kódkonverzió
A jó adatbáziskezelőnek fontos, hogy át tudjon állni Unicode-ra. Ez a konverzió állásidő nélkül vagy pedig rövid állásidővel elvégezhető.
A kódkonverzió azért fontos, ha például egy cég sok nemzetközi kapcsolattal rendelkezik és megérkezik egy holland vevő, akkor valahogy muszáj átállni más kódolásra.
Unicode
Az Unicode-nak a legújabb szabványa a 9.0. Ennek a repertoárja 128.000 karakterből áll. A kódolás UTF-8 vagy pedig UTF-16 kódolásban történik.
A kettő közül a z UTF-8 kódolást szeretik jobban. A két kódolási fajta abban tér el, hogy egy karakter hány bájtot foglal.
UTF-8
Az amerikai karakterek 1 bájtosak, a magyar karakterek 2 bájtosak, az angol betűk 1 bájtosak, arabok 1 bájtosak, de a kínaiak és más ázsiai nyelveknél egy karakter 4 bájtos. Egy jó adatbáziskezelőnek UTF-8 kódolásúnak kell lennie.
Ha le szeretnénk írni azt, hogy Tamás, az 5 bájtot fog elfoglalni a memóriában.
UTF-16
Normál karakterek 2 bájt hosszúságúak, tehát a leggyakoriabbak 2 bájtosak, a többi pedig 4 bájtos. Ha le szeretnénk írni azt, hogy Tamás, UTF-16-os kódolással már 10 bájt helyet foglalna a memóriában, ami sokkal több. Ezért is jobb az UTF-8.
Először elég rémisztőnek hangzik az a dolog, hogy a cégem adatait vagy akár a saját adataimat a felhőben tároljam és ne a saját gépemen, de manapság már egyre elterjedtebb dolog. Erre szolgál a PaaS.
PaaS
A platformszolgáltatás (PaaS) teljes körű fejlesztési és üzembe helyezési környezetet biztosít a felhőben, mindazon erőforrásokkal együtt, amelyek lehetővé teszik, hogy az egyszerű felhőalapú alkalmazásoktól a kifinomult, felhőszolgáltatásokat használó nagyvállalati alkalmazásokig bármit elkészíthessen. Azaz a 'Platform as a Service' egy olyan felhőalapú szolgáltatás, amely Oracle adatbázis környezetet tud biztosítani.
De fontos, hogy ennek a gyakorlatban is nagyon működnie kell, ugyanis régebben voltak ezzel kapcsolatosan gondok. Például resetelődött magától a felhasználó jelszava, ami azt jelenti, hogy nem adták ki jól a rendszert, ugyanis ha resetelődött a jelszó, erre még nem volt kidolgozott megoldásuk. Idővel már ezt is kiküszöbölték, de még tavaly is volt példa egy hasonló problémára az egyik szolgáltatónál.
A felhő alapú adatbázisoknak azonban számos előnyei vannak:
A felhő alapú adatbázisokra nagyon jó példa a Microsoft Azure szolgáltatása, amelyet már saját magam is használtam.
Az csatolt videóban az Azure rövid bemutatása látható:
------------------------------------------------------------------
Forrás: Online irodalom: Mi a PaaS?
https://azure.microsoft.com/hu-hu/overview/what-is-paas/
------------------------------------------------------------------
Egy adatbáziskezelő rendszer annál jobb, minél több programozási nyelvet támogat.
Klasszikusok
A klasszikus programozási nyelvek támogatása beágyazott ("embedded") SQL technológiával történik.
Fortran
A Fortran egy olyan programozási nyelv, amelyet elsõsorban matematikai számítások (pl. mérnöki alkalmazások) megkönnyítésére fejlesztettek ki.
------------------------------------------------------------------
Forrás: Online irodalom:
http://nimbus.elte.hu/oktatasi_anyagok/fortran/02_miajo.html
------------------------------------------------------------------
Cobol
A COBOL magas szintűprogramozási nyelv, a COmmon Business Oriented Language elnevezés rövidítése.
PHP
A PHP (Hypertext Preprocessor) támogatása szintén előny, amely egy erőteljes szerver-oldali szkriptnyelv, jól alkalmazható dinamikus és interaktív weboldalak elkészítéséhez.
------------------------------------------------------------------
Forrás: Online irodalom: PHP alapok
http://web.progtanulo.hu/web-programozas-alapismeretek/3-szerver-oldali-mukodes/32-php-alapok
------------------------------------------------------------------
C, C#, .NET
Ennek a három programozási nyelvnek a támogatása szinte kötelező az adatbáziskezelő rendszerek számára. A C# a Microsoft által a .NET keretrendszer részeként kifejlesztett objektumorientált programozási nyelv.
JDBC
JDBC (Java Database Connectivity): egy API a Java programozási nyelvhez, amely támogatja bármely relációs adatbázishoz a hozzáférést.
A JDBC segít a felhasználóknak olyan Java applikációk megírásában, amelyek az alábbi három programozási tevékenységet segítik:
További információ a témához megtalálható a csatolt linken.
------------------------------------------------------------------
Forrás: Online irodalom: Lesson: JDBC Introduction
https://docs.oracle.com/javase/tutorial/jdbc/overview/
------------------------------------------------------------------
A mai világban az adatbázisokban már nem csak egyszerű adattípusú fájlokat tárolunk, mint például szöveg, dátum vagy számokat, hanem sokkal bonyolultabbakat is. Már elterjedté vált a térinformatikai adatok, képek és tetszőleges szövegeknek a tárolása is. Mint például:
XMLType: egy rendszer által definiált adattípus az XML fájlok kezelésére, az XML adattípusú dokumentumok a SELECT nyelvet bővítik ki,Az adatbáziskezelő rendszerek esetén az objektumorientáltság egyre fontosabb szerepet tölt be.
------------------------------------------------------------------
Forrás: Online irodalom:
https://docs.oracle.com/cd/B10501_01/appdev.920/a96616/arxml24.htm
https://docs.oracle.com/cd/A91202_01/901_doc/server.901/a88856/c14ordb.htm
------------------------------------------------------------------
Mobile Database
Az Embedded Database-nek valamilyen válfaja a Mobile Database, amely okostelefon és PDA alapú. Ezek nagyon gyakran omlanak össze, ezért távoli replikációkkal próbálják elkerülni az adatvesztést.
Embedded Database
Embedded Database: olyan szoftver, amely nem kliens szerver alapon működik, hanem egy alkalmazás össze van ötvözve az adatbáziskezelővel, az egész egy nagy .EXE program és kívülről nem is látszik ez az adatbázis. Továbbá nem is szükséges külön rendszergazda.
Ez a szoftver rendelkezik olyan felülettel, ahol a kommunikáció zajlik, ezek átköltöztethetőek egyik gépről a másikra. Általában a kisebb rendszereket látják el ilyen megoldással.
Platformok
Ha egy szoftver működik a Windowson, Linuxon, Solarison, AIX-en, valamint HP-UX és esetleg VMS platformokon is, akkor nagy előnnyel indul.
Az a jó szoftver, ahol a szoftver nem külön van megírva a Linux és a Windows operációs rendszerekre, hanem ahol egy szoftver van és "portolták", azaz átköltöztették az egyik platformról a másikra. Ez százszor jobb megoldás annál, hogy ha mindkettőre lenne külön-külön két szoftverem.
Az Oracle esetében minden fejlesztés egy platformon folyik, aztán ezt portolják. Ez a lehető legjobb technika, hiszen megkönnyíti a későbbi platformváltoztatásokat.
Virtualizáció
Fontos szempont az is, hogy az adatbáziskezelő támogassa a virtualizációt.
Az Oracle nem igazán jeleskedik ebben, a VMWare nagyon komoly vetélytársának számít.
Jelentős mértékben érdekellentétben is vannak az Oracle-ös technológiákkal, de együtt tudnak működni.
Azonban ez az együttműködés fáj az Oracle-nek, ezért gyakran jelentkeznek licenszelési problémák. A virtualizációt a gyakorlatban is támogatni kell, azaz az árazásban.
Hardverarchitektúra
Az a jó, hogyha egy adatbáziskezelő rendszer sok architektúrát támogat, mint például az Intel, SUN SPARC, HP, PA-RISC és IBM.
Sajnálatos módon minden szoftver bug-os, tehát a számítógépes programhibák elkerülhetetlenek, ezért számolni kell a szoftveres támogatás (support) díjával.
Ha a licensz díja kb. 10 millió forint, akkor a szoftvertámogatásra kb. 2-3 millióval kell számolnunk. A supportnak a díja már tartalmazza az új verziókat is a hibajavítások mellett.
Ha már léteznek programhibák, akkor a kérdés az, hogy van-e olyan ember, aki ezt kijavítsa? Ha van, akkor is számos tényezőt kell ezen kívül figyelembe venni, amelyek befolyásolhatják a support minőségét:
Szoftverfejlődés képessége, üteme
A felhasználói igények az idő elteltével folyamatosan változnak és bővülnek, éppen ezért fontos, hogy olyan adatbáziskezelő rendszert válasszunk, amelyet folyamatosan fejlesztenek.
A fejlesztést számos probléma gátolhatja:
Fontos, hogy milyen programozási nyelvet használtak egy szoftver létrehozásakor, ugyanis ha a kód ősrégi, akkor az már kevésbé fejleszthető.
Ez történt az Oracle esetében is, ami C-ben íródott, ezért a kód jelentős része régi. Ezt a hibát próbálják azzal ellensúlyozni, hogy rengetegen fejlesztik a szoftvert.
Az adatbáziskezelő rendszer költségei alatt értjük a licenszköltségeket, a support díját, a hardver, valamint az üzemeltető személyzet költségeit is.
Személyzet költségei
Fontos megemlíteni az adatbáziskezelő rendszerek üzemeltető személyzetének a költségeit is, gondolok itt a bérekre, valamint a különféle képzésekre. Egy 5 napos oktatás ma már kb. fél millió forintba kerül. Ezekre a képzésekre a béreken, valamint esetleg a más dolgokra elköltötteken lehet spórolni.
TCO (Total Cost of Ownership): egy olyan költségkalkulátor, amely egy eszköz birtoklásának a valós költségeit mutatja.
Ez a mutató felhívja a figyelmet arra, hogy egy döntéskor ne csak az adott termék/szolgáltatás árát figyeljük, hanem fontos azoknak a költségeknek a figyelembevétele is, amelyek majd a termék/szolgáltatás teljes élettartama alatt jelentkeznek.
Ezt a TCO mutatót használja az Oracle is, mely segítségével mindig levezeti azt, hogy az Oracle a legolcsóbb, de természetesen nem szabad megfeledkezni arról, hogy ez a mérés amerikai viszonylatban zajlik.
------------------------------------------------------------------
Forrás: Online irodalom: TCO költség kalkulátor
http://www.autostars.hu/tcoteszt/bemutatkozas
------------------------------------------------------------------
Hardverköltség
A licensz díjak és egyéb költségek mellett szükséges hardver költségek is vannak, amelyek leginkább szoftver-specifikusak, azaz a szoftverektől függ, hogy milyen hardvert igényelnek.
Károk okozta költségek
Azokkal a költségekkel is számolni kell, amelyek az esetleges adatvesztésből fakadnak.
Az adatvesztésből fakadó károk alatt olyan károkat lehet érteni, mint például:
Ezeknek az esélye csekély, viszont ha ténylegesen bekövetkezik akkor hatalmas, akár visszafordíthatatlan üzleti károkat is okozhat. Például az OTP Bank esetében néhány tranzakciónak az elvesztése az adatbázisból akár több milliárdos károkat is okozhatna.
Az is lehetséges, hogy nem keletezik adatvesztés, csak egyszerűen nem működik megfelelően a szoftver, tehát számolni kell a tervezett, vagy tervezetlen leállásokkal is.
Support
A licneszköltség mellett, olyan egyéb költségekkel is számolni kell, mint például a szoftveres támogatás éves díja. Első évben még nem kell ezért fizetni, ugyanis ezt a support díjat tartalmazza a licenszdíj, de azután minden évben külön kell fizetni érte. Ha a licensz díja kb. 10 millió forint, akkor a szoftvertámogatásra kb. 2-3 millióval kell számolnunk.
Licenszköltség
A licensz használati jogot jelent, amit meg kell vásárolni, azaz amikor licenszköltséget fizetünk, akkor azért fizetünk, hogy használhassuk a különböző dolgokat.
Jelen esetben, a licenszköltségekre többet fogunk költeni, mint akármi másra (hardverekre, szoftverekre).
A licenszköltségek esetén több milliós nagyságrendekről beszélhetünk, amely függ egyrészt a hardver méretétől, valamint a felhasználók számától is.
A licenszben különböző szoftverkiszerelések és opcionális elemek vannak. Ilyen szoftverkiszerelés például az Oracle Enterprise is.
Az opcionális elemek alatt olyan további elemeket értünk, amelyek plusz "szolgáltatást" nyújtanak számunkra. Ilyen például a Diagnostic Pack is, amely a monitorozást teszi lehetővé, valamint a Tuning Pack is, amely pedig az automatikus hangolást biztosítja a felhasználó számára.
Ha úgy döntünk, hogy ezekre a plusz elemekre szükségünk van, akkor ezekért külön-külön fizetni kell. Továbbá ha a felhőből szeretnénk szolgáltatást bérelni, vagy csak szimplán a saját gépünkön szeretnénk igénybe venni a szolgáltatást, akkor is licensz díjat kell fizetni.
