realizată de Zsolt Vajda 7 ani în urmă
237
Mai multe ca aceasta
El kell döntenünk, hogy ingyenes vagy fizetős adatbázis kezelőt választunk, ha fizetőset, akkor melyiket, melyek azok a lehetőségek, amelyek mindegyik adatbázis kezelőben benne vannak, és hol vannak esetleg azok a pluszok, amelyek miatt a fizetős rendszerek többet nyújtanának. Ingyenes esetén nagyobb a kockázata annak, hogy adatokat veszítsünk, kisebb legyen a rendelkezésre állás. Fontos megjegyezni, hogy az ingyenes adatbázis kezelő rendszerek esetében is van költség.. Magasabb árú adatbázis kezelő rendszer esetén jobbak a lehetőségeink, rendelkezésünkre állhatnak luxus lehetőségek.
Az embereknek eleinte általában a szoftver árának és a performanciának (működési sebességnek) a megnézése jut eszébe először, ezek közül az ár valóban meghatározó elem, a performancia kevésbé, az egyes adatbázis kezelő rendszerek működési sebességének összehasonlítására léteznek ugyan módszerek, de ez egy összetettebb kérdés, nem igazán lehet egyértelműen igazságot tenni.
Az adatbázis kezelő kiválasztása az esetek többségében évtizedes következményekkel jár, ugyanis nem cserélgethetjük kis időközönként a cégünk által használt adatbázis kezelő rendszereket.
A döntés személyzeti kérdéseket is befolyásolja, hiszen a választott adatbázis kezelőhöz értő szakembereket kell alkalmazni.
A kérdés fontosságát mutatja, hogy az informatikára költött pénzek nagy részét gyakran az adatbázis kezelőre fordítják. Ez azonban nem mindig igaz, például abban az esetben, ha egy bank egy „kulcsrakész” SAP rendszert vezet be, akkor az Oracle adatbázis licenszek költsége jóval kisebb lesz az SAP rendszer költségeihez képest. Amennyiben nem kulcsrakész szoftvert veszünk, hanem házon belüli fejlesztés céljából szerzünk be adatbázis kezelő rendszert, akkor biztos, hogy egy nagyságrenddel nagyobb összeget költünk adatbázis kezelő rendszerre, mint például hardverre.
Ahol nincs külön forrás megjelölve, ott az előadás diái és az előadáson elhangzottak alapján dolgoztam.
Úgy tűnik, hogy sajnos elkerülhetetlenek, bug-ok minden adatbázis kezelő rendszerben vannak, még a legjobbakban is.
A „support” általában borsos áron történik
Jellemzően nemcsak a hibajavításokat, hanem az új verziókat is fedi a support-díj .
Hányan és hány problémát oldanak meg a termék gyártójánál? A mi problémánkat jellemzően megoldják-e és ha igen, mennyi idő alatt?
A megoldási módszer is lényeges, hiszen érzékeny adatokat tárolunk. Ki férhet hozzá a hiba felderítése során? Nem szerencsés, ha a megoldáshoz el kellene küldenem a gyártónak a teljes adatbázist, hiszen értékes adatokat tárolok benne.
Ha már vannak hibák, kritikus kérdés, hogy van-e aki javítsa őket?
Az Oracle C-ben íródott, ami ma már inkább rossz tulajdonság, mint jó, és a kód jelentős része igen „dohos”. Ezt próbálják ellensúlyozni azzal, hogy rengetegen fejlesztik. (Jobb lett volna, ha Java-ban fejlesztik ki, de ezen már késő bánkódni).
Egyre több rendszert működtetünk. Egyes cégeknél több száz adatbáziskezelő rendszer működik. Nem tudnak a rendszergazdák mindegyikre folyamatosan odafigyelni.
Az igazán jó rendszerek nemcsak riasztanak, hanem megoldást is javasolnak, sőt esetleg a javasolt változtatást meg is teszik automatikusan.
Oracle esetén ez külön fizetős opció, és mindenféle automatával van teletűzdelve az adatbáziskezelő rendszer.
A jó rendszerek saját magukat figyelik belülről
A jó rendszereket elsősorban nem kívülről figyelik („polling”), hanem azok saját magukat figyelik belülről, és riasztanak minket, ha baj van. Erre még nincs egységes szóhasználat, de gyakran „Server Generated Alert System” a neve.
Az adatbázis sebessége ugyan nem a legfontosabb kiválasztási kritérium, de annak mégis hatalmas jelentősége van, ha egy rendszer nagyon precízen monitorozható, és kideríthető róla, hogy hol van a szűk-keresztmetszete. Ha ezután még át is paraméterezhető a működés, úgy, hogy a „bottleneck” eltűnjön, vagy csupán enyhüljön, az már főnyeremény.
Ezáltal ugyanis harmadik fél is gyártani tud monitoring eszközt (nyílt rendszerek).
A mentés elvégezhető legyen online, a rendszer nem állhat le a mentés miatt.
Mindent mentsek, vagy csak azt, ami tegnap óta változott.
Hatékony (valószínűleg párhuzamosítható) mentési módszer kell.
Ezzel nemcsak lementhető, hanem egyúttal logikailag ellenőrizhető az adatok tartalma. Előny az, ha ez a program az adatbázis kezelő rendszer belsejébe van beleépítve és nem egy független szoftver.
Az adatbázis kezelő rendszerek zsargonjában auditálásnak nevezik az adatbázis-használat figyelését biztonsági célokból, az adatlopástól tartunk. Azt kell tudnunk, hogy melyik felhasználó mikor milyen műveleteket hajtott végre.
Lehet auditálni úgy is, hogy az hasznavehetetlen.
Az auditálás konfigurálható kell hogy legyen: Opcionálisan eldönthető, hogy legyen audit , vagy ne, ezt azért kell eldönteni, mert az audit lassítja a rendszert. Ha van audit, akkor konfigurálható kell hogy legyen annak a részletessége, hiszen minél részletesebb, annál lassabb. Az auditálás működtetése nem lassíthatja számottevően az adatbáziskezelő rendszert.
Az Oracle adatbázis esetén ezt a megoldást Oracle Database Vaultnak nevezzük.
A merevlemez-alapú adatbázisoknál az adatok a merevlemezen fájlokban tárolódnak. Komoly kockázat, hogy ezeket a fájlokat esetleg ellopják és így jutnak hozzá az adatokhoz. Ezt a komoly adatbázis kezelők úgy védik ki, hogy a fájlban már titkosított módon tárolódnak az adatok. Ilyenkor az INSERT utasítás „titkosítva ír”, és a SELECT utasítás fejti azt vissza.
Aki tehát SQL művelettel fér hozzá az adatokhoz, azt ez a titkosítás „nem érinti”. Ugyanilyen titkosítás létezhet a kliens-szerver kommunikáció (hálózati kommunikáció) során is
A „High Availability” egyre fontosabbá válik, egyre gyakrabban van szükségünk 7*24 órás rendelkezésre állásra.
Persze valamiféle állásidőnek manapság még ilyenkor is mindenképpen lennie kell. Például az „5 kilences” rendelkezésre állás (vagyis a 99.999%-os rendelkezésre állás) azt jelenti, hogy évente kb. 5-6 percet állunk csupán. Ez nagyon nehezen teljesíthető, de nem lehetetlen, a valóságban azért ennél több állásidő szokott lenni, általában évi 1 óra állásidővel is elégedettek szoktak lenni.
Problémás a következő szoftverek frissítése: operációs rendszer, adatbázis kezelő rendszer, adatszótár: ezek előre bejelentett állásidők.
Oracle esetén például a RAC opció a legfőbb magas rendelkezésre állási képesség.
Nem betervezett (valamilyen hiba miatt)
Betervezett (előre bejelentett)
A sebesség mellett legalább olyan fontos kérdés, hogy ha növekszik a terhelés, tudjuk-e ehhez igazodva növelni a teljesítményt .
Oracle esetén a RAC lenne a válasz a skálázhatóságra is.
Ideális a lineáris skálázhatóság lenne: kétszer annyi hardverrel kétszer annyi munka elvégzése, azonban a lineáris skálázhatóság szinte csak álom.
A performancia messze nem a legfontosabb, sajnos a korai fázisban mégis sokan ez alapján választanak. Ha a sebesség kiemelkedően fontos, akkor is csak a releváns terheléseket vegyük figyelembe!
Minden újabb verzióról azt mondják, hogy gyorsabb, mint a megelőző verzió, közben rendszerint lassabb, hiszen egyre több funkció kerül az új verziókba.
Az Oracle ugyan rendre megnyeri a „performancia versenyeket”, de ez nem jelentős információ, ugyanis egy erősebb hardver ellensúlyozhatja a szoftver hatékonyságát, illetve azt is figyelembe kell venni, hogy leginkább a funkcionalitás rovására válik 1-1 adatbázis kezelő rendszer gyorssá, máskor azért gyors egy adatbáziskezelő, mert memóriában dolgozik, és nem merevlemez-alapú.
Ez persze sérülékenyebbé teszi, sokkal nagyobb esélye van a tranzakcióvesztésnek ráadásul szinte mindegyik adatbáziskezelő rendszer gyártója kozmetikázza a hatékonysági számait.
Előbb utóbb nemcsak összeomlik egy szoftver, hanem adatvesztés is történhet (pl. lemezhiba miatt), a lemezt tükrözhetjük ugyan, de még így is meghibásodhat mind a kettő, vagy akár a felhasználó tévedésből is törölhet egy fájlt.
Nemcsak a ténylegesen várható veszélyekre illik felkészülni, hanem olyan katasztrófa-helyzetekre, amelyek szinte kizártnak tűnnek: tűzvész, árvíz, földrengés, terrortámadás.
Oracle esetén a DataGuard a katasztrófatűrő megoldás.
Aki katasztrófák ellen is védekezni akar (egyre többen), azok távoli adatbázis-másolatokat szeretnének működtetni, ezt megoldhatja valamilyen hardveres vagy szoftverek távoli tükrözés is, de lehet ez akár az adatbázis kezelő rendszer extra képessége is.
Abszolút bombabiztos megoldás mégsem nem létezik, bármikor történhet annyi szerencsétlenség egy időben, hogy adatvesztés történjen.
Nemcsak a legegyszerűbb hibák, hanem a kellemetlenebb meghibásodások, esetleg többszörös hibák esetére is kell valami forgatókönyv.
Fontos, hogy a helyreállítás könnyű feladat legyen, ne hibázzunk közben.
A helyreállítás ideje is kritikus (esetleg a helyreállítás ideje alatt nem lehet használni a rendszert): a jó eset manapság néhány perc, a nem jó eset több óra.
Az adatbázis kezelő rendszernek olyan mentési mechanizmus kell, amely biztosítja nemcsak a régi mentésre való visszaállást („Restore”), hanem a legfrissebb állapotba való helyreállást is („Recovery”).
Oracle Data Pump
SQL*Loader
Adatok igény szerinti áthordozása adatbázistáblákból bináris állományokba és később ezek visszatöltése ugyanabba, vagy másik adatbázisba
Adatok betöltése az adatbázistáblákba
XML állományokból
Excell táblákból
CSV („Comma Separated Values”) fájlokból
szöveges fix formátumú állományokból
A több millió adatbázis felhasználó cégnek (esetleg embernek) gyakran van olyan közös igénye, amely túlmutat az SQL-en, de mégis praktikus.
Ilyen például az ütemezett feladatok végrehajtása (például az adatbázis kezelő rendszerben minden éjszaka történjen valamiféle ellenőrzés), email-ek küldése , fájlok olvasása/írása , üzenetek küldése és fogadása.
Nyílt forráskódú adatbázis kezelő rendszer esetén ez lehet közösségi fejlesztés is: a felhasználók is gyárthatnak ilyeneket, amelyeket aztán közkinccsé tehetnek.
Amennyiben létezik procedurális lehetőség az adatbázison belül, akkor rendszerint a gyártó biztosít ilyen kiterjesztéseket, tehát az adatbázis kezelő gyártója készít ilyen szolgáltatásokat, amelyeket a felhasználóik számára rendelkezésre bocsát.
Igen hasznos egy olyan képesség, hogy bizonyos programok maguktól végrehajtódnak (elsülnek) egyes események bekövetkeztekor.
Hanem például olyanok, amelyek bejelentkezéskor, vagy például a teljes rendszer elindulása vagy leállása esetén futnak le és tesznek előkészületeket, vagy lezáró munkálatokat.
Ezekkel jellemzően a jobb adatbázis kezelők rendelkeznek.
Adatok beszúrása után hajtódnak végre. Ezeket gyakran a művelet naplózása érdekében alkalmazzuk.
Adatok beszúrása előtt hajtódnak végre, jellemzően a beszúrás ellenőrzéseként használjuk.
Az SQL nyelv nagyszerű (rengetegen ismerik, nem procedurális, vagyis azt mondom meg neki, hogy mit kell megtalálni, és nem azt, hogy hogyan), de mégis akadnak esetek, amikor más kéne.
Kevésbé vált be az Oracle adatbázison belül.
Rendelkezésre áll az Oracle esetében, rendkívül népszerű.
Szükségünk lehet algoritmusokra is, és ezek adatbázison belüli tárolására.
A kényszerek halmaza is kibővíthető így
Megvalósítható lenne például, hogy ne lehessen nagyobb a fizetés, mint az azonos osztályban lévő többiek fizetése.
A felhasználó kifejlesztheti a saját kiterjesztéseit
Például készíthetnék egy ÁFA nevű függvényt, ami ugyanúgy működne, mint például az átlag, így SELECT-ben is használhatnám.
Maga a gyártó is fejleszthet ilyen kiterjesztéseket
Két és négy byte-os kódokat is tartalmaz.
UCS-2
Az UTF-16 régebbi változata, két byte-os kódkészlet, 65000 karaktert tartalmazott.
Az adatbázis kezelő rendszerek ezt preferálják, az amerikai karakterek egy byte-osak, a többi hosszabb, tehát például a magyar ékezetes karakterek két byte-osak, a kínai és japán írásjelek 4 byte-osak.
A Unicode egy de-facto szabvánnyá vált, támogatása szinte kötelező. A Unicode legújabb szabványa 9.0. Ebben 128.000 jelből áll a „repertoár” (régen ezt „Character Set”-nek nevezték volna, de ez most nem polkorrekt, ugyanis például a kínai és japán írásjeleket nem lehet karaktereknek nevezni, a repertoár szó általánosabb, ezért ezt használhatjuk).
Idővel egyre jelentősebb előnnyé válik majd az, hogy nemcsak a saját géptermünkben működtethetjük, hanem bérelhetünk a felhőben is ilyen szolgáltatást: „Platform as a Service”, vagyis PaaS: tehát egy Oracle adatbázis környezetet tudnak például biztosítani.
A PaaS nemcsak elméleti lehetőség kell, hogy legyen, hanem a gyakorlatban is olajozottan kell működnie.
Az adatbázisokban manapság már nemcsak szöveget, számokat és dátumokat tárolunk, hanem mindenféle egyéb dolgokat is: Képek, tetszőleges szöveg, térinformatikai adatok, stb.
Képesség a felhasználó által definiált adattípusok bevezetésére.
Először definiáljuk, hogy milyen szerkezetű lesz az xml dokumentum, ennek köszönhetően később a feldolgozás is hatékony lesz. Ha szabadon választott xml formátumot engedélyezünk, az megnehezíti a feldolgozást.
Az SQL nyelv önmagában nem elegendő, hiszen nem arra találták ki, hogy xml dokumentumokkal dolgozzon, ezért a gyártóknak nem szabványos elemeket is alkalmazniuk kell az xml feldolgozásának érdekében. Az Oracle képes feldolgozni az xml formátumú adatokat.
Olyan szoftver, ami nem kliens-szerver alapon működik, hanem egy alkalmazás össze van ötvözve az adatbázis kezelővel, kívülről nem is látszik maga az adatbázis, nem igényel a szoftver külön adatbázis kezelő rendszergazdát.
Általában kis rendszereket látnak el ilyen megoldásokkal.
Mobile Database
Az "Embedded Database" egy válfaja a "Mobile Database” : okostelefonokra, PDA-kon futó rendszerekre gyártják, ez például egy utazó ügynök esetében lehet hasznos, akinek nincs folyamatos kapcsolata a központi adatbázissal, hanem lokálisan viszi be az adatokat a hordozható eszközébe, amely időnként felcsatlakozik a központi adatbázisra, és átadja az adatokat.
Ez azt jelenti, hogy nem fordulhat elő az, hogy egy alkalmazást csak azért a nulláról újra kelljen tesztelni pusztán azért, mert átköltöztetem egyik platformról a másikra, hiszen ebben az esetben soha nem költöztetnénk az alkalmazást.
A platformváltás oka lehet egy előre nem látható dolog is, a jó adatbázis kezelő olyan, ahol a szoftver nem külön van megírva Windowsra és külön Linuxra, hanem egy szoftver van, amit át lehet „költöztetni” egyik gépről a másikra, abból, hogy egy platformon fejlesztenek, az is következik, hogy a bug is mindig ugyanott van, és következetesen viselkedik.
Ebben az Oracle az élen jár, hiszen ott egy platformon fejlesztenek (Linuxon), és innen visznek át mindent később a többi platformra.
A data szervereknek manapság uralkodó platformja a Linux, de a Windows-os szerverek száma is jelentős. Ezen kívül természetesen még mindig vannak, akik az Intel alapú architektúrákkal szemben a régi nagygépes technológiákat részesítik előnybe, számukra fontos, hogy az adatbázis kezelő fusson Solaris, AIX, HP-UX, esetleg VMS operációs rendszereken is. (Oracle a VMS operációs rendszeren is fut.)
A virtualzicáiót nem csak elméletben támogatja, hanem baráti árazással is. Például VMWARE virtuális gépen, és egyéb virtuális platformokon is működik az adatbázis kezelő. Ebben az Oracle nem jeleskedik, ugyanis a VMWARE virtuális megoldásai jelentős érdekellentétben vannak az Oracle technológiákkal, az együttműködés megvalósulhatna ugyan, de az kedvezőtlen lenne az Oracle számára, ebből kifolyólag az Oracle licenszelési politikája rendkívül ellenséges VMWARE esetén.
Hanem Intel, SUN SPARC, Hewlett Packard PA-RISC, és különböző IBM hardverarchitektúrákon is működik.
Beágyazott SQL ("Embedded SQL") technológiával támogatja a hagyományos programozási nyelveket, ezt úgy kell elképzelni, hogy például a C kód írása közben beírom, hogy „exec sql”, az ez utáni részbe írhatom az SQL szabályok szerinti kódot, amit egy fordító segítségével változtat C kóddá.
Példa: https://docs.microsoft.com/en-us/sql/odbc/reference/embedded-sql-example
Ezen keresztül kell relációs adatbázisokhoz hozzáférni, SQL utasításokat eljuttatni az adatbázis felé.
Voltak korábban olyan relációs adatbázis kezelő rendszerek, amelyek saját nyelvet használtak, de ezek mára eltűntek, a maiak mind SQL-t használnak, így ennek a nyelvnek több millió ismerője van. Azonban ez nem jelenti az, hogy a programok változtatás nélkül migrálhatóak az adatbázis kezelők között, a relációs adatbázis kezelő rendszerek szabványosítása ugyanis még nem ért el erre a szintre.
Az Oracle azonban gyakran alkalmaz olyan megoldásokat, amelyek túlmutatnak a szabványon, ennek az a hátránya, hogy az így fejlesztett alkalmazásokat nem tudjuk egyszerűen átvinni egy másik gyártó rendszerébe, ez komoly költségekkel jár, sok időt vesz igénybe. A nem szabványos fejlesztése másik kockázata, hogy később megszűnhet a támogatásuk (a jobb adatbázis kezelő gyártókra azonban nem jellemző, hogy megszüntetnek korábban még létező opciókat).
Nemcsak egy adatbázison belül kell megbízhatóan kezelnie a tranzakciókat, hanem két adatbázis kezelő rendszer között is: az adatok áramolnak a rendszerek között, ennek megbízhatónak kell lennie, nem fordulhat elő adatvesztés.
Például az adatbázis kezelő rendszer és egy üzenetküldő rendszer között („Messaging System”: üzenettovábbító rendszer, lényege, hogy megbízhatóan befogadja és továbbítsa az adatokat, garantálja, hogy a másik fél elolvasta).
XA protokoll
Rendszerint XA protokollon közlekednek az adatok.
Két különböző gyártó rendszere között
Ez jóval bonyolultabb. Az adatbázis kezelőnél nagy fegyvertény, ha birtokában van ennek a képességnek; az Oracle esetében egy nagyon lassú folyamat.
XA tranzakciók támogatása
Az IBM dolgozta ki. Két különböző gyártó rendszere közötti adatátvitel általában XA protokoll szerint történik.
Két azonos adatbázis kezelő rendszer közötti megbízható adatátvitel
Például Oracle esetén az adatbázis link (database link): az ilyenkor futó szoftverkódot elosztott tranzakciónak (distributed transaction) nevezik és az elosztott tranzakciót úgynevezett kétfázisú jóváhagyási mechanizmussal hagyhatjuk jóvá), ezt viszonylag könnyű megoldani.
Az elterjedtség és a kiforrottság között van összefüggés, ami azonban nem függvényszerű, ugyanis léteznek kiforrott, de kevésbé elterjedt rendszerek, és vannak néhány éve bevezetett, de széles körben használt adatbázis kezelők is.
Szükség esetén könnyű új munkatársat (elcsábíthatunk embereket a konkurenciától), külső konzultánst találni (nem kell külföldről drágán szakértőt hívni). Jelentősen megkönnyíti a tapasztalatcserét is.
Egy kiforrott, sokak által már használt adatbázis kezelő esetében amennyiben hibaüzenetet kapok, arra elég rákeresni a Google-n, és rengeteg információhoz juthatok róla, míg egy ismeretlen adatbázis kezelő esetén az elsők között szembesülök egy problémával, és rengeteg időmbe, illetve energiámba kerül a probléma elhárítása.
Ha például internet banking üzemeltetéséhez keres szoftvert egy cég, akkor irreleváns számára, hogy az adott szoftver mennyire megbízható teljesítményt nyújt a telekommunikációs szektorban.
Ha olyan szoftvert választunk, amit mások már ugyanolyan célokra használtak, akkor náluk valószínűleg már fölmerült az az igény, ami nálunk is jelentkezni fog, így a szoftver gyártójának már volt ideje reagálni az adott igényre.
Ezért olyan adatbázis kezelőt kell választanunk, amelynél nem mi fogjuk először megtapasztalni a hibát, tehát sokan használják már, ennek köszönhetően azt a problémát, amivel szembesülünk valószínűleg már korábban is tapasztalták.
Ez egy meghatározó kérdés, főleg annak tükrében, hogy az esetek többségében az informatikai költségek nagyobb részét adatbázis kezelő rendszerre költik.
Total Cost of Ownership, a rendszerek birtoklásának a teljes költségét mutatja meg (amerikai bérekkel számolva).
Többek között a bérre, és képzésekre fizetett összeg. Egyes adatbázis kezelő rendszerek annyira automatizáltak, hogy kevés üzemeltető szükséges hozzájuk, míg kevésbé automatizált adatbázis kezelők működtetéséhez jelentősen több alkalmazottra lesz szükségünk.
Gyakran jelentősen függ attól, hogy milyen adatbázis kezelő rendszert használunk, egyesek ugyanis olcsó hardvereken is futnak, léteznek azonban olyan adatbázis kezelő rendszerek, amelyek drága gépeket igényelnek.
Évente minden cégnél történik legalább egy-két tervezetlen állásidő, tervezett pedig ennél jóval több. Ezeknek is megvannak az üzleti kárai.
A tervezett állásidő esetén kisebb az üzleti kockázat, hiszen előre be tudják jelenteni. Az előre be nem jelentett leállás ennél nagyobb problémát okozhat.
Elvárható, hogy ilyen ne történjen a szoftver hibájából. Előfordulhatnak azonban például lemez meghibásodások, hálózati megakadások, amelyek problémákhoz vezethetnek, de főleg a fájlok elvesztése okozhat súlyos adatvesztési problémákat. Akármilyen erősen védett a rendszer ezek ellen, akkor is előfordulhat annyi egy időben bekövetkezett meghibásodás, hogy adatvesztés forduljon elő.
Például egy bank esetében óriási bizalomvesztéssel járna akár néhány tranzakció elvesztése az adatbázisból. Ennek ugyan kicsi a valószínűsége, de hatalmas üzleti kárt okoz, ha bekövetkezik, így ezt is a költség részének kell tekinteni.
Az olcsó, ingyenes adatbázis kezelő rendszerek esetében magas support díjat kell fizetni.
A licenszet jellemzően a felhasználók számától, vagy a hardver méretétől teszik függővé a gyártók, ez milliós-tízmilliós-százmilliós nagyságrendet jelent a hardvermérettől függően, továbbá függ a processzorok számától, alternatív felhasználók számától.
Rengeteg opcionális elem van (pl. Diagnostic Pack), ezek is befolyásolják a költséget.
