1. Kiindulási adatok
Az adattisztítás az adatelemzési feladatok egyik kihívása. Ez az anyag tükrözte azokat a fejlesztéseket és megoldásokat, amelyek a kataszteri értékképzésben az adatbázis elemzésének gyakorlati problémájának megoldása eredményeként merültek fel. Források itt .
A „B. függelék. A KS meghatározásának eredményei 5. A kataszteri érték meghatározásának módszerére vonatkozó információk 5.1. Összehasonlító megközelítés” című fájl „Összehasonlító modell total.ods” című fájlját vették figyelembe.
1. táblázat Az adatkészlet statisztikai mutatói a „Comparative model total.ods” fájlban
A mezők száma összesen, db. — 44
Összes iratszám, db. — 365 490
Teljes karakterszám, db. — 101 714 693
Egy rekord karaktereinek átlagos száma, db. — 278,297
Rekord karaktereinek szórása, db. — 15,510
Egy bejegyzés minimális karakterszáma, db. — 198
Maximális karakterszám egy bejegyzésben, db. — 363
2. Bevezető rész. Alapvető szabványok
A megadott adatbázis elemzése során feladat alakult ki a tisztítási fok követelményeinek meghatározására, hiszen – mint mindenki számára világos – a megadott adatbázis jogi és gazdasági következményekkel jár a felhasználók számára. A munka során kiderült, hogy a big data tisztítási fokára nincs konkrét követelmény. E tárgykörben a jogi normákat elemezve arra a következtetésre jutottam, hogy ezek mind lehetőségekből alakulnak ki. Vagyis megjelent egy bizonyos feladat, összeállítják a feladathoz az információforrásokat, majd egy adatállományt képeznek, és a létrehozott adatkészlet alapján eszközöket a probléma megoldásához. Az így kapott megoldások referenciapontok az alternatívák közötti választásban. Ezt az 1. ábrán mutattam be.
Mivel az esetleges szabványok meghatározásánál előnyösebb a bevált technológiákra hagyatkozni, ezért a pontban foglalt követelményeket választottam. , mert ezt a dokumentumot tartottam a legátfogóbbnak ebben a kérdésben. Ennek a dokumentumnak a szakasza különösen azt mondja: „Meg kell jegyezni, hogy az adatintegritási követelmények a kézi (papír) és az elektronikus adatokra egyaránt vonatkoznak.” (fordítás: „...az adatintegritási követelmények a kézi (papír) és az elektronikus adatokra egyaránt vonatkoznak”. Ez a megfogalmazás egészen konkrétan kapcsolódik az „írásbeli bizonyíték” fogalmához, a polgári perrendtartás 71. cikkének rendelkezései szerint. 70 CAS, APC 75. cikk, „írásban” 84 Polgári perrendtartás.
A 2. ábra egy diagramot mutat be a jogtudományban az információtípusokkal kapcsolatos megközelítések kialakulásáról.
Rizs. 2. Forrás .
A 3. ábra az 1. ábra mechanizmusát mutatja be, a fenti „Útmutató” feladataihoz. Az összehasonlításból könnyen belátható, hogy az információs rendszerek modern szabványaiban az információs integritás követelményeinek való megfelelés során alkalmazott megközelítések az információ jogi fogalmához képest jelentősen korlátozottak.
3. ábra
A megadott dokumentumban (Útmutató) a műszaki részhez való kapcsolódást, az adatfeldolgozási és -tárolási lehetőségeket jól igazolja egy idézet a 18.2 fejezetből. Relációs adatbázis: "Ez a fájlstruktúra eredendően biztonságosabb, mivel az adatokat nagy fájlformátumban tárolják, amely megőrzi az adatok és a metaadatok közötti kapcsolatot."
Valójában ebben a megközelítésben - a meglévő technikai lehetőségekből - nincs semmi rendellenes, és ez önmagában is természetes folyamat, hiszen a koncepciók bővülése a leginkább tanulmányozott tevékenységből - az adatbázis-tervezésből - származik. Másrészt azonban megjelennek olyan jogi normák, amelyek nem adnak kedvezményt a meglévő rendszerek műszaki képességeihez, például: .
Rizs. 4. Technikai képességek tölcsére ().
Ezekben a szempontokban világossá válik, hogy az eredeti adatkészletet (1. ábra) mindenekelőtt el kell menteni, másodsorban pedig annak alapját kell képeznie a további információk kinyeréséhez. Nos, példaként: a közlekedési szabályokat rögzítő kamerák mindenütt jelen vannak, az információfeldolgozó rendszerek kiszűrik a szabálysértőket, de más fogyasztóknak is felkínálhatók egyéb információk, például egy bevásárlóközpontba irányuló vásárlóáramlás szerkezetének marketingfigyeléseként. Ez pedig további hozzáadott érték forrása a BigDat használatakor. Elképzelhető, hogy a most, valahol a jövőben gyűjtött adathalmazoknak a ritka, 1700-as kiadások jelenlegi értékéhez hasonló mechanizmus szerint lesz értéke. Valójában az ideiglenes adatkészletek egyediek, és nem valószínű, hogy a jövőben megismétlődnek.
3. Bevezető rész. Értékelési szempontok
A feldolgozás során a következő hibaosztályozást dolgoztuk ki.
1. Hibaosztály (a GOST R 8.736-2011 alapján): a) szisztematikus hibák; b) véletlenszerű hibák; c) baklövés.
2. Multiplicitás szerint: a) mono torzítás; b) többszörös torzítás.
3. A következmények kritikussága szerint: a) kritikus; b) nem kritikus.
4. Az előfordulás forrása szerint:
A) Műszaki – a berendezés működése során fellépő hibák. Meglehetősen releváns hiba IoT rendszerek, a kommunikáció minőségét jelentős mértékben befolyásoló rendszerek, berendezések (hardver) esetében.
B) Kezelői hibák – hibák széles skálán mozognak, a beviteli hibáktól az adatbázis-tervezés műszaki specifikációiban előforduló hibákig.
C) Felhasználói hibák – itt vannak felhasználói hibák a teljes tartományban, az „elfelejtett elrendezéstől” egészen a mérőórák lábbal való összetévesztéséig.
5. Külön osztályba különítve:
a) az „elválasztó feladata”, vagyis a szóköz és a „:” (esetünkben), amikor megkettőződött;
b) összeírt szavak;
c) nincs szóköz a szervizkarakterek után
d) szimmetrikusan többszörös szimbólumok: (), "", "...".
Összességében az 5. ábrán bemutatott adatbázishibák rendszerezésével egy meglehetősen hatékony koordinátarendszer jön létre a hibakereséshez és az adattisztító algoritmus kidolgozásához ehhez a példához.
Rizs. 5. Az adatbázis szerkezeti egységeinek megfelelő tipikus hibák (Forrás: ).
Pontosság, tartomány integritása, adattípus, konzisztencia, redundancia, teljesség, többszörözés, üzleti szabályoknak való megfelelés, strukturális meghatározottság, adatok anomáliája, egyértelműség, időszerűség, adatintegritási szabályok betartása. (334. oldal. Adattárház alapjai informatikai szakemberek számára / Paulraj Ponniah. – 2. kiadás)
Zárójelben az angol szövegezés és az orosz gépi fordítás szerepel.
Pontosság. A rendszerben egy adatelemhez tárolt érték a megfelelő érték az adatelem előfordulásához. Ha van egy ügyfél neve és egy címe egy rekordban, akkor a cím az adott névvel rendelkező ügyfél helyes címe. Ha a 1000-as rendelési szám rekordjában 12345678 egységben találja a rendelt mennyiséget, akkor ez a mennyiség a rendelés pontos mennyisége.
[Pontosság. A rendszerben egy adatelemhez tárolt érték a megfelelő érték az adatelem előfordulásához. Ha az ügyfél neve és címe van tárolva egy rekordban, akkor a cím az adott névvel rendelkező ügyfél helyes címe. Ha a 1000-as rendelési szám rekordjában 12345678 egységben rendelt mennyiséget talál, akkor ez a mennyiség a rendelés pontos mennyisége.]
Domain integritása. Egy attribútum adatértéke a megengedett, meghatározott értékek tartományába esik. A gyakori példa a „férfi” és a „nő” megengedett értéke a nemi adatelemnél.
[Domain integritása. Az attribútum adatértéke az érvényes, meghatározott értékek tartományába esik. Egy általános példa a „férfi” és a „nő” érvényes értéke a nemi adatelemhez.]
Adattípus. Az adatattribútum értéke valójában az adott attribútumhoz meghatározott adattípusként tárolódik. Ha az áruháznév mező adattípusa „szöveg”-ként van definiálva, akkor a mező minden példánya tartalmazza az üzlet nevét szöveges formátumban, és nem numerikus kódokat.
[Adattípus. Az adatattribútum értéke valójában az adott attribútumhoz meghatározott adattípusként kerül tárolásra. Ha az üzletnév mező adattípusa "szöveg"-ként van definiálva, akkor ennek a mezőnek az összes példánya tartalmazza az üzlet nevét, amely szöveges formátumban jelenik meg, nem pedig numerikus kódokban.]
Következetesség. Az adatmező formája és tartalma több forrásrendszerben ugyanaz. Ha az egyik rendszerben az ABC termék termékkódja 1234, akkor ennek a terméknek a kódja minden forrásrendszerben 1234.
[Következetesség. Az adatmező formája és tartalma a különböző forrásrendszerekben azonos. Ha az egyik rendszeren az ABC termék termékkódja 1234, akkor az adott termék kódja minden forrásrendszeren 1234.]
Redundancia. Ugyanazt az adatot nem szabad egynél több helyen tárolni a rendszerben. Ha egy adatelemet hatékonysági okokból szándékosan több helyen tárolnak a rendszerben, akkor a redundanciát egyértelműen azonosítani és ellenőrizni kell.
[Redundancia. Ugyanazokat az adatokat nem szabad több helyen tárolni a rendszerben. Ha hatékonysági okokból egy adatelemet szándékosan több helyen tárolnak a rendszerben, akkor a redundanciát egyértelműen meg kell határozni és ellenőrizni kell.]
Teljesség. Egy adott attribútumhoz nincsenek hiányzó értékek a rendszerben. Például egy ügyfélfájlban minden ügyfél esetében érvényes értéknek kell lennie az „állapot” mezőben. A megrendelés részleteit tartalmazó fájlban a megrendelés minden részletét teljesen ki kell tölteni.
[Teljesség. Ehhez az attribútumhoz nincsenek hiányzó értékek a rendszerben. Például az ügyfélfájlnak minden ügyfélnél érvényes értékkel kell rendelkeznie az "állapot" mezőben. A rendelési adatfájlban minden rendelési adatrekordot teljesen ki kell tölteni.]
Megkettőzés. A rekordok többszörözése a rendszerben teljesen megoldott. Ha ismert, hogy a termékfájlban ismétlődő rekordok vannak, akkor az egyes termékekhez tartozó összes ismétlődő rekord azonosításra kerül, és kereszthivatkozás jön létre.
[Másolat. A rendszerben lévő rekordok megkettőzése teljesen megszűnt. Ha egy termékfájlról ismert, hogy ismétlődő bejegyzéseket tartalmaz, akkor az egyes termékekhez tartozó összes ismétlődő bejegyzés azonosításra kerül, és kereszthivatkozás jön létre.]
Üzletszabályzatnak való megfelelés. Az egyes adatelemek értékei megfelelnek az előírt üzleti szabályoknak. Aukciós rendszerben a kalapács vagy eladási ár nem lehet kevesebb, mint a kikiáltási ár. A banki hitelrendszerben a hitelegyenlegnek mindig pozitívnak vagy nullának kell lennie.
[Az üzletszabályzat betartása. Az egyes adatelemek értékei megfelelnek a megállapított üzleti szabályoknak. Aukciós rendszerben a kalapács vagy eladási ár nem lehet kevesebb, mint a kikiáltási ár. Egy banki hitelrendszerben a hitelegyenlegnek mindig pozitívnak vagy nullának kell lennie.]
Strukturális meghatározottság. Ahol egy adatelem természetesen egyedi komponensekre strukturálható, az elemnek tartalmaznia kell ezt a jól meghatározott szerkezetet. Például egy személy neve természetesen utónévre, középső kezdőbetűre és vezetéknévre oszlik. Az egyének nevének értékeit keresztnévként, középső kezdőbetűként és vezetéknévként kell tárolni. Az adatminőség ezen jellemzője leegyszerűsíti a szabványok betartatását és csökkenti a hiányzó értékeket.
[Strukturális bizonyosság. Ha egy adatelem természetes módon strukturálható egyedi komponensekre, akkor az elemnek tartalmaznia kell ezt a jól meghatározott szerkezetet. Például egy személy neve természetesen fel van osztva keresztnévre, középső kezdőbetűre és vezetéknévre. Az egyes nevek értékeit utónévként, középső kezdőbetűként és vezetéknévként kell tárolni. Ez az adatminőségi jellemző leegyszerűsíti a szabványok alkalmazását és csökkenti a hiányzó értékeket.]
Adat anomália. Egy mezőt csak arra a célra szabad használni, amelyre meghatározták. Ha a Cím-3 mező bármely lehetséges harmadik címsorhoz van megadva hosszú címeknél, akkor ezt a mezőt csak a harmadik címsor rögzítésére kell használni. Nem használható az ügyfél telefonszámának vagy faxszámának megadására.
[Adat-anomália. Egy mezőt csak arra a célra szabad használni, amelyre meghatározták. Ha az Address-3 mező bármely lehetséges harmadik címsorhoz van megadva hosszú címekhez, akkor ez a mező csak a harmadik címsor rögzítésére használható. Nem használható telefonszám vagy faxszám megadására az ügyfél számára.]
Világosság. Egy adatelem rendelkezhet a minőségi adat összes többi jellemzőjével, de ha a felhasználók nem értik egyértelműen a jelentését, akkor az adatelemnek nincs értéke a felhasználók számára. A megfelelő elnevezési konvenciók segítenek abban, hogy az adatelemek jól érthetők legyenek a felhasználók számára.
[Világosság. Egy adatelem rendelkezhet a jó adatok összes többi jellemzőjével, de ha a felhasználók nem értik egyértelműen a jelentését, akkor az adatelemnek nincs értéke a felhasználók számára. A helyes elnevezési konvenciók segítenek abban, hogy a felhasználók jól megértsék az adatelemeket.]
Időszerű. A felhasználók határozzák meg az adatok időszerűségét. Ha a felhasználók elvárják, hogy az ügyféldimenziós adatok ne legyenek egy napnál régebbi, akkor a forrásrendszerekben az ügyféladatok módosításait naponta kell alkalmazni az adattárházban.
[Időben. A felhasználók határozzák meg az adatok időszerűségét. Ha a felhasználók arra számítanak, hogy az ügyféldimenziós adatok nem régebbiek egy napnál, akkor a forrásrendszerekben az ügyféladatok módosításait naponta kell alkalmazni az adattárházban.]
Hasznosság. Az adattárház minden adatelemének meg kell felelnie a felhasználók gyűjtésének bizonyos követelményeinek. Egy adatelem lehet pontos és jó minőségű, de ha nincs értéke a felhasználók számára, akkor teljesen felesleges, hogy az adatelem az adattárházban legyen.
[Hasznosság. Az adattárban lévő minden egyes adatelemnek meg kell felelnie a felhasználói gyűjtemény bizonyos követelményeinek. Egy adatelem lehet pontos és jó minőségű, de ha nem ad értéket a felhasználóknak, akkor nem szükséges, hogy az adatelem az adattárházban legyen.]
Az adatintegritási szabályok betartása. A forrásrendszerek relációs adatbázisaiban tárolt adatoknak meg kell felelniük az entitásintegritási és hivatkozási integritási szabályoknak. A null-t elsődleges kulcsként engedélyező tábla nem rendelkezik entitásintegritással. A hivatkozási integritás kikényszeríti a szülő-gyermek kapcsolatok helyes kialakítását. Vevőtől rendelésig tartó viszonyban a hivatkozási integritás biztosítja, hogy az adatbázisban minden rendelésnél vevő legyen.
[Az adatintegritási szabályoknak való megfelelés. A forrásrendszerek relációs adatbázisaiban tárolt adatoknak meg kell felelniük az entitásintegritás és a hivatkozási integritás szabályainak. A null-t elsődleges kulcsként engedélyező tábla nem rendelkezik entitásintegritással. A hivatkozási integritás kikényszeríti a szülők és a gyermekek közötti kapcsolat helyes kialakítását. Vevő-megrendelés kapcsolatban a hivatkozási integritás biztosítja, hogy az adatbázisban minden megrendeléshez legyen vevő.]
4. Adattisztítás minősége
Az adattisztítás minősége meglehetősen problematikus kérdés a bigdatában. Annak a kérdésnek a megválaszolása, hogy milyen mértékű adattisztítás szükséges a feladat elvégzéséhez, alapvető minden adatelemző számára. A legtöbb aktuális problémában ezt minden elemző maga határozza meg, és nem valószínű, hogy ezt a szempontot kívülről bárki is értékelni tudja a megoldásában. Ám a jelen ügyben felmerülő feladat szempontjából ez a kérdés rendkívül fontos volt, hiszen a jogi adatok megbízhatóságának egybe kell irányulnia.
A szoftvertesztelési technológiák figyelembevétele a működési megbízhatóság meghatározásához. Manapság több mint ezek a modellek . Sok modell követeléskezelési modellt használ:
Fig. 6
A következőképpen gondolkodva: "Ha a talált hiba hasonló esemény, mint ebben a modellben, akkor hogyan lehet megtalálni a t paraméter analógját?" És összeállítottam a következő modellt: Képzeljük el, hogy a tesztelőnek egy rekord ellenőrzéséhez szükséges idő 1 perc (a kérdéses adatbázis esetében), majd az összes hiba megtalálásához 365 494 percre lesz szüksége, ami hozzávetőlegesen 3 év és 3 hónapos munkaidő. Mint tudjuk, ez nagyon sok munka, és az adatbázis ellenőrzésének költségei túl magasak lesznek az adatbázis fordítója számára. Ebben a reflexióban megjelenik a költségek közgazdasági fogalma, és az elemzés után arra a következtetésre jutottam, hogy ez egy meglehetősen hatékony eszköz. A közgazdaságtan törvénye alapján: „Az a termelési mennyiség (egységekben), amelynél a vállalat maximális profitját eléri, azon a ponton található, ahol egy új egységnyi kibocsátás előállításának határköltségét összehasonlítjuk azzal az árral, amelyet a vállalat megkaphat. egy új egységért.” Abból a feltevésből kiindulva, hogy minden későbbi hiba megtalálása a rekordok egyre több ellenőrzését igényli, ez költségtényező. Vagyis a tesztelési modellekben alkalmazott posztulátum a következő mintában kap fizikai értelmet: ha az i-edik hiba megtalálásához n rekordot kellett ellenőrizni, akkor a következő (i+1) hiba megtalálásához szükséges lesz. m rekord ellenőrzésére és egyúttal n
- Amikor az új hiba észlelése előtt ellenőrzött rekordok száma stabilizálódik;
- Amikor a következő hiba megtalálása előtt ellenőrzött rekordok száma nő.
A kritikus érték meghatározásához a gazdasági megvalósíthatóság fogalmához fordultam, amely ebben az esetben a társadalmi költségek fogalmával a következőképpen fogalmazható meg: „A hiba kijavításának költségeit azt a gazdálkodó szereplőt kell viselni, aki erre képes. a legalacsonyabb áron.” Egy ügynökünk van – egy tesztelő, aki 1 percet tölt egy rekord ellenőrzésével. Pénzben kifejezve, ha napi 6000 rubelt keres, ez 12,2 rubel lesz. (kb. ma). Továbbra is meg kell határozni az egyensúly második oldalát a gazdasági jogban. így érveltem. Egy létező hiba megköveteli, hogy az érintett személy, azaz az ingatlantulajdonos erőfeszítést tegyen annak kijavítására. Tegyük fel, hogy ehhez 1 napos intézkedés szükséges (kérelem benyújtása, javított dokumentum átvétele). Ekkor társadalmi szempontból a költségei megegyeznek a napi átlagfizetéssel. Átlagos felhalmozott fizetés a Hanti-Manszi Autonóm Körzetben 73285 dörzsölje. vagy 3053,542 rubel/nap. Ennek megfelelően egy kritikus értéket kapunk, amely egyenlő:
3053,542: 12,2 = 250,4 rekordegység.
Ez társadalmi szempontból azt jelenti, hogy ha egy tesztelő 251 rekordot ellenőrzött és egy hibát talált, az egyenértékű azzal, hogy a felhasználó maga javítja ki a hibát. Ennek megfelelően, ha a tesztelő 252 rekord ellenőrzésével egyenlő időt töltött a következő hiba megtalálására, akkor ebben az esetben jobb, ha a javítás költségét a felhasználóra hárítja.
Itt egy leegyszerűsített megközelítést mutatunk be, hiszen társadalmi szempontból figyelembe kell venni az egyes szakemberek által generált összes többletértéket, azaz az adókat és szociális befizetéseket is tartalmazó költségeket, de a modell egyértelmű. Ennek a kapcsolatnak a következménye a szakemberrel szemben támasztott követelmény: az IT-szakma szakemberének az országos átlagnál magasabb fizetést kell kapnia. Ha a fizetése kevesebb, mint a potenciális adatbázis-felhasználók átlagkeresete, akkor neki magának kell ellenőriznie a teljes adatbázist kézről-kézre.
A leírt kritérium alkalmazásakor az adatbázis minőségének első követelménye alakul ki:
I(tr). A kritikus hibák aránya nem haladhatja meg az 1/250,4 = 0,39938%-ot. Kicsit kevesebb, mint arany az iparban. És fizikai értelemben nem több, mint 1459 hibás rekord.
Gazdasági visszavonulás.
Valójában azáltal, hogy ilyen számú hibát követ el a nyilvántartásokban, a társadalom beleegyezik a következő összegű gazdasági veszteségbe:
1459*3053,542 = 4 455 118 rubel.
Ezt az összeget az határozza meg, hogy a társadalomnak nincsenek eszközei ezen költségek csökkentésére. Ebből az következik, hogy ha valaki rendelkezik olyan technológiával, amely lehetővé teszi, hogy a hibás rekordok számát például 259-re csökkentse, akkor ezzel a társadalom spórolhat:
1200*3053,542 = 3 664 250 rubel.
De ugyanakkor kérheti tehetségét és munkáját, nos, mondjuk - 1 millió rubelt.
Vagyis a szociális költségeket csökkentik:
3 664 250 – 1 000 000 = 2 664 250 rubel.
Ez a hatás lényegében a BigDat technológiák használatából származó hozzáadott érték.
De itt figyelembe kell venni, hogy ez társadalmi hatás, és az adatbázis tulajdonosa az önkormányzati hatóságok, az ingatlanhasználatból származó bevételük ebben az adatbázisban 0,3%-os arányban: 2,778 milliárd rubel/ év. És ezek a költségek (4 455 118 rubel) nem nagyon zavarják őt, mivel áthárítják őket az ingatlantulajdonosokra. És ebből a szempontból a Bigdata finomítóbb technológiáinak fejlesztőjének meg kell mutatnia, hogy képes meggyőzni az adatbázis tulajdonosát, és ehhez jelentős tehetség kell.
Ebben a példában a hibaértékelési algoritmust a megbízhatósági tesztelés során alkalmazott szoftverellenőrzés Schumann-modellje [2] alapján választottuk. Az interneten való elterjedtsége és a szükséges statisztikai mutatók beszerzésének lehetősége miatt. A módszert Monakhov Yu.M. „Az információs rendszerek funkcionális stabilitása”, lásd a spoiler alatt az ábrát. 7-9.
Rizs. 7 – 9 A Schumann-modell módszertana
Az anyag második része egy példát mutat be az adattisztításra, amelyben a Schumann-modell használatának eredményeit kapjuk.
Hadd mutassam be a kapott eredményeket:
A hibák becsült száma N = 3167 n.
C paraméter, lambda és megbízhatósági függvény:
17. ábra
Lényegében a lambda annak az intenzitásnak a tényleges mutatója, amellyel a hibákat az egyes szakaszokban észlelik. Ha megnézi a második részt, ennek a mutatónak a becslése óránként 42,4 hiba volt, ami nagyon hasonlít a Schumann-mutatóhoz. A fentiekben megállapítottuk, hogy a fejlesztő által talált hibák aránya nem lehet alacsonyabb, mint 1 hiba 250,4 rekordonként, percenként 1 rekord ellenőrzésekor. Innen származik a lambda kritikus értéke a Schumann-modellhez:
60 / 250,4 = 0,239617.
Vagyis a hibafeltárási eljárások elvégzésének szükségességét addig kell végrehajtani, amíg a lambda a meglévő 38,964-ről 0,239617-re nem csökken.
Vagy amíg az N (potenciális hibák száma) mínusz n (javított hibaszám) mutató az általunk elfogadott küszöbérték alá nem csökken - 1459 db.
Irodalom
- Monakhov, Yu. M. Információs rendszerek funkcionális stabilitása. 3 óra alatt 1. rész Szoftver megbízhatóság: tankönyv. juttatás / Yu. M. Monakhov; Vladim. állapot univ. – Vladimir: Izvo Vladim. állapot Egyetem, 2011. – 60 p. – ISBN 978-5-9984-0189-3.
- Martin L. Shooman: „Valószínűségi modellek a szoftver megbízhatóságának előrejelzéséhez”.
- Adattárház alapjai informatikai szakemberek számára / Paulraj Ponniah.—2. kiadás.
Forrás: will.com