Մաքրել տվյալները, ինչպես ռոք, թուղթ, մկրատ խաղ: Սա խաղ է ավարտով, թե առանց ավարտի: Մաս 1. Տեսական

1. Նախնական տվյալներ

Տվյալների մաքրումը տվյալների վերլուծության առաջադրանքների առջեւ ծառացած մարտահրավերներից մեկն է: Այս նյութում արտացոլված էին կադաստրային արժեքի ձևավորման գործում տվյալների բազայի վերլուծության գործնական խնդրի լուծման արդյունքում առաջացած զարգացումները և լուծումները: Աղբյուրներն այստեղ «ՀԱՇՎԵՏՎՈՒԹՅՈՒՆ Թիվ 01/ՕԿՍ-2019 Խանտի-Մանսիյսկի ինքնավար օկրուգ - Ուգրայի տարածքում բոլոր տեսակի անշարժ գույքի (բացառությամբ հողամասերի) պետական ​​կադաստրային գնահատման արդյունքների մասին».

Դիտարկվել է «Հավելված Բ. ԿՍ 5-ի որոշման արդյունքներ. Կադաստրային արժեքի որոշման մեթոդի մասին տեղեկատվություն 5.1 Համեմատական ​​մոտեցում» ֆայլը «Համեմատական ​​մոդել total.ods» ֆայլը:

Աղյուսակ 1. «Համեմատական ​​մոդել total.ods» ֆայլի տվյալների շտեմարանի վիճակագրական ցուցանիշները.
Ընդհանուր դաշտերի քանակը, հատ: - 44
Գրառումների ընդհանուր քանակը, հատ. — 365 490
Նիշերի ընդհանուր քանակը, հատ: — 101 714 693
Գրառման մեջ նիշերի միջին քանակը, հատ: — 278,297
Գրառման մեջ նիշերի ստանդարտ շեղում, հատ. — 15,510
Գրառման մեջ նիշերի նվազագույն քանակը, հատ: - 198
Գրառման մեջ նիշերի առավելագույն քանակը, հատ: — 363

2. Ներածական մաս. Հիմնական ստանդարտներ

Նշված տվյալների բազան վերլուծելիս խնդիր է դրվել հստակեցնել մաքրման աստիճանի պահանջները, քանի որ, ինչպես բոլորին պարզ է, նշված տվյալների բազան իրավական և տնտեսական հետևանքներ է ստեղծում օգտագործողների համար։ Աշխատանքի ընթացքում պարզվել է, որ մեծ տվյալների մաքրման աստիճանի նկատմամբ կոնկրետ պահանջներ չկան։ Վերլուծելով այս հարցում իրավական նորմերը՝ հանգեցի այն եզրակացության, որ դրանք բոլորը ձևավորվում են հնարավորություններից։ Այսինքն՝ առաջացել է որոշակի առաջադրանք, առաջադրանքի համար կազմվում են տեղեկատվական աղբյուրներ, այնուհետև ձևավորվում է տվյալների բազա և ստեղծված տվյալների բազայի հիման վրա՝ խնդրի լուծման գործիքներ։ Ստացված լուծումները հղման կետեր են այլընտրանքներից ընտրելու հարցում: Ես սա ներկայացրել եմ Նկար 1-ում:



Քանի որ ցանկացած ստանդարտ որոշելու հարցում նախընտրելի է ապավինել ապացուցված տեխնոլոգիաներին, ես ընտրեցի ս.թ. «MHRA GxP տվյալների ամբողջականության սահմանումներ և ուղեցույց արդյունաբերության համար», քանի որ այս փաստաթուղթը ես համարեցի այս հարցի համար ամենաընդգրկունը։ Մասնավորապես, այս փաստաթղթում ասվում է, որ «Հարկ է նշել, որ տվյալների ամբողջականության պահանջները հավասարապես վերաբերում են ձեռքով (թղթային) և էլեկտրոնային տվյալներին»: (թարգմանություն՝ «...տվյալների ամբողջականության պահանջները հավասարապես կիրառվում են ձեռնարկի (թղթային) և էլեկտրոնային տվյալների նկատմամբ»): Այս ձևակերպումը բավականին կոնկրետ կապված է «գրավոր ապացույց» հասկացության հետ՝ Քաղաքացիական դատավարության օրենսգրքի 71-րդ հոդվածի դրույթներում, Արվեստ. 70 CAS, Art 75 APC, «գրավոր» Art. 84 Քաղաքացիական դատավարության օրենսգիրք.

Գծապատկեր 2-ում ներկայացված է իրավագիտության մեջ տեղեկատվության տեսակների նկատմամբ մոտեցումների ձևավորման դիագրամ:

Բրինձ. 2. Աղբյուր այստեղ.

Նկար 3-ը ցույց է տալիս Նկար 1-ի մեխանիզմը վերը նշված «Ուղեցույցի» առաջադրանքների համար: Համեմատության միջոցով հեշտ է տեսնել, որ տեղեկատվական համակարգերի ժամանակակից ստանդարտներում տեղեկատվության ամբողջականության պահանջները բավարարելիս կիրառվող մոտեցումները զգալիորեն սահմանափակ են տեղեկատվության իրավական հայեցակարգի համեմատ:

Նկար 3

Նշված փաստաթղթում (Ուղեցույց) տեխնիկական մասի հետ կապը, տվյալների մշակման և պահպանման հնարավորությունները լավ հաստատվում են 18.2 գլխի մեջբերումով: Հարաբերական տվյալների բազա. «Ֆայլի այս կառուցվածքն էապես ավելի ապահով է, քանի որ տվյալները պահվում են մեծ ֆայլի ձևաչափով, որը պահպանում է տվյալների և մետատվյալների միջև կապը»:

Փաստորեն, այս մոտեցման մեջ՝ առկա տեխնիկական հնարավորություններից, ոչ մի աննորմալ բան չկա և, ինքնին, սա բնական գործընթաց է, քանի որ հասկացությունների ընդլայնումը բխում է ամենաուսումնասիրված գործունեությունից՝ տվյալների բազայի ձևավորումից: Բայց, մյուս կողմից, հայտնվում են իրավական նորմեր, որոնք զեղչեր չեն նախատեսում գործող համակարգերի տեխնիկական հնարավորությունների վրա, օրինակ. GDPR - Տվյալների պաշտպանության ընդհանուր կանոնակարգ.

Բրինձ. 4. Տեխնիկական հնարավորությունների ձագար (Աղբյուր).

Այս առումներով պարզ է դառնում, որ սկզբնական տվյալների բազան (նկ. 1) պետք է, առաջին հերթին, պահպանվի, և երկրորդ՝ հիմք հանդիսանա դրանից լրացուցիչ տեղեկություններ քաղելու համար: Դե, որպես օրինակ. երթևեկության կանոնները գրանցող տեսախցիկները ամենուր են, տեղեկատվության մշակման համակարգերը ջնջում են խախտողներին, բայց այլ տեղեկատվություն կարող է առաջարկվել նաև այլ սպառողներին, օրինակ՝ որպես առևտրի կենտրոն հաճախորդների հոսքի կառուցվածքի մարքեթինգային մոնիտորինգ: Եվ սա լրացուցիչ հավելյալ արժեքի աղբյուր է BigDat-ն օգտագործելիս: Միանգամայն հնարավոր է, որ տվյալների հավաքածուները, որոնք հավաքագրվում են հիմա, ինչ-որ տեղ ապագայում, կունենան արժեք՝ համաձայն 1700 հազվագյուտ հրատարակությունների ներկայիս արժեքի նման մեխանիզմի: Ի վերջո, իրականում ժամանակավոր տվյալների հավաքածուները եզակի են և դժվար թե դրանք հետագայում կրկնվեն:

3. Ներածական մաս. Գնահատման չափանիշներ

Մշակման գործընթացում մշակվել է սխալների հետևյալ դասակարգումը.

1. Սխալների դաս (հիմնված ԳՕՍՏ Ռ 8.736-2011). ա) համակարգված սխալներ. բ) պատահական սխալներ. գ) սխալ.

2. Բազմապատկությամբ՝ ա) մոնո աղավաղում; բ) բազմակողմանի աղավաղում.

3. Ըստ հետևանքների կրիտիկականության՝ ա) կրիտիկական. բ) ոչ քննադատական:

4. Ըստ առաջացման աղբյուրի.

Ա) Տեխնիկական - սխալներ, որոնք տեղի են ունենում սարքավորումների շահագործման ընթացքում. Բավականին համապատասխան սխալ IoT համակարգերի, համակարգերի համար, որոնք զգալի ազդեցություն ունեն կապի որակի, սարքավորումների (ապարատային):

Բ) Օպերատորի սխալներ. լայն շրջանակի սխալներ՝ օպերատորի տառասխալներից մուտքագրման ժամանակ մինչև տվյալների բազայի նախագծման տեխնիկական բնութագրերի սխալները:

Գ) Օգտատիրոջ սխալներ. ահա օգտատերերի սխալներն ամբողջ միջակայքում՝ սկսած «մոռացել եմ փոխել դասավորությունը» մինչև մետրերը ոտքերի դիմաց սխալմամբ:

5. Առանձին դասի բաժանված.

ա) «անջատողի առաջադրանքը», այսինքն՝ բացատը և «:» (մեր դեպքում), երբ այն կրկնօրինակվել է.
բ) բառերը միասին գրված.
գ) սպասարկման նշաններից հետո բացատ չկա
դ) սիմետրիկորեն բազմակի նշաններ՝ (), «», «...»:

Նկար 5-ում ներկայացված տվյալների բազայի սխալների համակարգման հետ միասին ձևավորվում է բավականին արդյունավետ կոորդինատային համակարգ՝ սխալների որոնման և այս օրինակի համար տվյալների մաքրման ալգորիթմ մշակելու համար:

Բրինձ. 5. Տվյալների բազայի կառուցվածքային միավորներին համապատասխանող տիպիկ սխալներ (Աղբյուր. Օրեշկով Վ.Ի., Պակլին Ն.Բ. «Տվյալների համախմբման հիմնական հասկացությունները»).

Ճշգրտություն, տիրույթի ամբողջականություն, տվյալների տեսակ, հետևողականություն, ավելորդություն, ամբողջականություն, կրկնօրինակում, բիզնեսի կանոններին համապատասխանություն, կառուցվածքային հստակություն, տվյալների անոմալիա, հստակություն, ժամանակին, տվյալների ամբողջականության կանոնների պահպանում: (Էջ 334. Տվյալների պահեստավորման հիմունքներ ՏՏ մասնագետների համար / Paulraj Ponniah.-2nd ed.)

Ներկայացրեց անգլերեն ձևակերպումը և ռուսերեն մեքենայական թարգմանությունը փակագծերում:

Ճշգրտություն. Տվյալների տարրի համար համակարգում պահվող արժեքը տվյալների տարրի այդ առաջացման ճիշտ արժեքն է: Եթե ​​դուք ունեք հաճախորդի անուն և հասցե, որը պահվում է գրառումներում, ապա հասցեն հենց այդ անունով հաճախորդի համար է: Եթե ​​1000 պատվերի գրանցման մեջ գտնում եք պատվիրված քանակությունը որպես 12345678 միավոր, ապա այդ քանակն այդ պատվերի ճշգրիտ քանակն է:
[Ճշգրտություն. Տվյալների տարրի համար համակարգում պահվող արժեքը տվյալների տարրի այդ առաջացման ճիշտ արժեքն է: Եթե ​​դուք ունեք հաճախորդի անուն և հասցե, որը պահվում է գրառումում, ապա հասցեն ճիշտ հասցե է այդ անունով հաճախորդի համար: Եթե ​​1000 պատվերի գրանցման մեջ գտնում եք պատվիրված քանակությունը որպես 12345678 միավոր, ապա այդ քանակությունը հենց այդ պատվերի քանակն է:]

Դոմենի ամբողջականություն. Հատկանիշի տվյալների արժեքը ընկնում է թույլատրելի, սահմանված արժեքների միջակայքում: Ընդհանուր օրինակը գենդերային տվյալների տարրի համար «արական» և «իգական» թույլատրելի արժեքներն են:
[Դոմենի ամբողջականություն. Հատկանիշի տվյալների արժեքը ընկնում է վավեր, սահմանված արժեքների միջակայքում: Ընդհանուր օրինակ է «արական» և «իգական» արժեքները գենդերային տվյալների տարրի համար:]

Տվյալների տեսակը. Տվյալների հատկանիշի արժեքը իրականում պահվում է որպես տվյալ հատկանիշի համար սահմանված տվյալների տեսակ: Երբ խանութի անվան դաշտի տվյալների տեսակը սահմանվում է որպես «տեքստ», այդ դաշտի բոլոր օրինակները պարունակում են տեքստային ձևաչափով ցուցադրված խանութի անվանումը և ոչ թվային կոդերը:
[Տվյալների տեսակը. Տվյալների հատկանիշի արժեքը իրականում պահվում է որպես տվյալ հատկանիշի համար սահմանված տվյալների տեսակ: Եթե ​​խանութի անվան դաշտի տվյալների տեսակը սահմանվում է որպես «տեքստ», այս դաշտի բոլոր օրինակները պարունակում են խանութի անվանումը, որը ցուցադրվում է տեքստային ձևաչափով, քան թվային կոդերը:]

Հետևողականություն. Տվյալների դաշտի ձևը և բովանդակությունը նույնն են բազմաթիվ աղբյուրների համակարգերում: Եթե ​​արտադրանքի ABC կոդը մեկ համակարգում 1234 է, ապա այս ապրանքի կոդը 1234 է յուրաքանչյուր աղբյուր համակարգում:
[Հետևողականություն. Տարբեր աղբյուրների համակարգերում տվյալների դաշտի ձևն ու բովանդակությունը նույնն են: Եթե ​​մեկ համակարգում արտադրանքի ABC կոդը 1234 է, ապա այդ արտադրանքի կոդը 1234 է յուրաքանչյուր աղբյուրի համակարգում:]

Ավելորդություն. Նույն տվյալները չպետք է պահվեն համակարգի մեկից ավելի վայրերում: Եթե ​​արդյունավետության նկատառումներից ելնելով տվյալների տարրը դիտավորյալ պահվում է համակարգի մեկից ավելի վայրերում, ապա ավելորդությունը պետք է հստակորեն բացահայտվի և ստուգվի:
[Ավելորդություն. Նույն տվյալները չպետք է պահվեն համակարգի մեկից ավելի վայրերում: Եթե ​​արդյունավետության նկատառումներից ելնելով տվյալների տարրը դիտավորյալ պահվում է համակարգի մի քանի վայրերում, ապա ավելորդությունը պետք է հստակ սահմանվի և ստուգվի:]

Ամբողջականություն. Համակարգում տվյալ հատկանիշի համար բացակայող արժեքներ չկան: Օրինակ, հաճախորդի ֆայլում յուրաքանչյուր հաճախորդի համար պետք է լինի «state» դաշտի վավեր արժեք: Պատվերի մանրամասների համար նախատեսված ֆայլում պատվերի յուրաքանչյուր մանրամասն գրառում պետք է ամբողջությամբ լրացված լինի:
[Լրիվություն. Այս հատկանիշի համար համակարգում բացակայող արժեքներ չկան: Օրինակ, հաճախորդի ֆայլը պետք է ունենա վավեր արժեք յուրաքանչյուր հաճախորդի համար «կարգավիճակ» դաշտի համար: Պատվերի մանրամասների ֆայլում յուրաքանչյուր պատվերի մանրամասն գրառում պետք է ամբողջությամբ լրացվի:]

Կրկնօրինակում. Համակարգում գրառումների կրկնօրինակումը լիովին լուծված է: Եթե ​​հայտնի է, որ ապրանքի ֆայլն ունի կրկնօրինակ գրառումներ, ապա յուրաքանչյուր ապրանքի բոլոր կրկնօրինակ գրառումները նույնացվում են և ստեղծվում է խաչաձև հղում:
[Կրկնօրինակ. Համակարգում գրառումների կրկնօրինակումը լիովին վերացվել է։ Եթե ​​հայտնի է, որ ապրանքի ֆայլը պարունակում է կրկնօրինակ գրառումներ, ապա յուրաքանչյուր ապրանքի բոլոր կրկնօրինակ գրառումները նույնացվում են և ստեղծվում է խաչաձև հղում:]

Համապատասխանություն բիզնեսի կանոններին: Յուրաքանչյուր տվյալների միավորի արժեքները համապատասխանում են սահմանված բիզնես կանոններին: Աճուրդային համակարգում մուրճը կամ վաճառքի գինը չի կարող պակաս լինել պահուստային գնից: Բանկային վարկային համակարգում վարկի մնացորդը միշտ պետք է լինի դրական կամ զրո:
[Բիզնեսի կանոնների պահպանում. Յուրաքանչյուր տվյալների տարրի արժեքները համապատասխանում են սահմանված բիզնես կանոններին: Աճուրդային համակարգում մուրճը կամ վաճառքի գինը չի կարող պակաս լինել պահուստային գնից: Բանկային վարկային համակարգում վարկի մնացորդը միշտ պետք է լինի դրական կամ զրո:]

Կառուցվածքային որոշակիություն. Այնտեղ, որտեղ տվյալների տարրը բնականաբար կարող է կառուցվածքավորվել առանձին բաղադրիչների, տարրը պետք է պարունակի այս լավ սահմանված կառուցվածքը: Օրինակ, անհատի անունը բնականաբար բաժանվում է անուն, միջին սկզբնատառ և ազգանուն: Անհատների անունների արժեքները պետք է պահվեն որպես անուն, միջին սկզբնատառ և ազգանուն: Տվյալների որակի այս հատկանիշը հեշտացնում է ստանդարտների կիրառումը և նվազեցնում բացակայող արժեքները:
[Կառուցվածքային որոշակիություն. Այն դեպքում, երբ տվյալների տարրը կարող է բնականաբար կառուցվածքավորվել առանձին բաղադրիչների, տարրը պետք է պարունակի այս լավ սահմանված կառուցվածքը: Օրինակ՝ մարդու անունը բնականաբար բաժանվում է անուն, միջին սկզբնատառ և ազգանուն։ Առանձին անունների արժեքները պետք է պահվեն որպես անուն, միջին սկզբնատառ և ազգանուն: Տվյալների որակի այս բնութագիրը պարզեցնում է ստանդարտների կիրառումը և նվազեցնում բացակայող արժեքները:]

Տվյալների անոմալիա. Դաշտը պետք է օգտագործվի միայն այն նպատակի համար, որի համար այն սահմանված է: Եթե ​​«Հասցե-3» դաշտը սահմանված է երկար հասցեների ցանկացած հնարավոր երրորդ տողի համար, ապա այս դաշտը պետք է օգտագործվի միայն երրորդ գիծը գրանցելու համար: Այն չպետք է օգտագործվի հաճախորդի համար հեռախոսահամար կամ ֆաքս մուտքագրելու համար:
[Տվյալների անոմալիա. Դաշտը պետք է օգտագործվի միայն այն նպատակի համար, որի համար այն սահմանված է: Եթե ​​Հասցե-3 դաշտը սահմանված է երկար հասցեների ցանկացած հնարավոր երրորդ հասցեի տողի համար, ապա այս դաշտը պետք է օգտագործվի միայն երրորդ հասցեի տողը գրանցելու համար: Այն չպետք է օգտագործվի հաճախորդի համար հեռախոսահամար կամ ֆաքս մուտքագրելու համար:]

Պարզություն. Տվյալների տարրը կարող է ունենալ որակյալ տվյալների բոլոր մյուս բնութագրերը, բայց եթե օգտվողները հստակ չեն հասկանում դրա իմաստը, ապա տվյալների տարրը արժեք չունի օգտագործողների համար: Անվանման ճիշտ կոնվենցիաները օգնում են օգտվողներին լավ հասկանալի դարձնել տվյալների տարրերը:
[Պարզություն. Տվյալների տարրը կարող է ունենալ լավ տվյալների բոլոր մյուս բնութագրերը, բայց եթե օգտվողները հստակ չեն հասկանում դրա իմաստը, ապա տվյալների տարրը արժեք չունի օգտագործողների համար: Անվանման ճիշտ կոնվենցիաներն օգնում են օգտվողներին լավ հասկանալի դարձնել տվյալների տարրերը:]

Ժամանակին. Օգտագործողները որոշում են տվյալների արդիականությունը: Եթե ​​օգտվողներն ակնկալում են, որ հաճախորդի չափման տվյալները մեկ օրից ավելի հին չեն, ապա սկզբնական համակարգերում հաճախորդների տվյալների փոփոխությունները պետք է ամեն օր կիրառվեն տվյալների պահեստում:
[Ժամանակին. Օգտագործողները որոշում են տվյալների արդիականությունը: Եթե ​​օգտատերերն ակնկալում են, որ հաճախորդի չափումների տվյալները մեկ օրից ոչ ավելի վաղեմություն ունեն, սկզբնական համակարգերում հաճախորդների տվյալների փոփոխությունները պետք է կիրառվեն տվյալների պահեստում ամեն օր:]

Օգտակարություն. Տվյալների պահեստում տվյալների յուրաքանչյուր տարր պետք է բավարարի օգտագործողների հավաքագրման որոշ պահանջներ: Տվյալների տարրը կարող է լինել ճշգրիտ և որակյալ, բայց եթե այն արժեք չունի օգտատերերի համար, ապա բոլորովին ավելորդ է, որ տվյալ տարրը լինի տվյալների պահեստում:
[Կոմունալ. Տվյալների պահեստի յուրաքանչյուր տարր պետք է բավարարի օգտագործողի հավաքածուի որոշ պահանջներ: Տվյալների տարրը կարող է լինել ճշգրիտ և բարձրորակ, բայց եթե այն արժեք չի տալիս օգտվողներին, ապա պարտադիր չէ, որ տվյալ տարրը լինի տվյալների պահեստում:]

Տվյալների ամբողջականության կանոնների պահպանում: Աղբյուրի համակարգերի հարաբերական տվյալների շտեմարաններում պահվող տվյալները պետք է պահպանվեն միավորի ամբողջականության և հղումային ամբողջականության կանոններին: Ցանկացած աղյուսակ, որը թույլատրում է null-ը որպես հիմնական բանալի, չունի էության ամբողջականություն: Հղման ամբողջականությունը ստիպում է ճիշտ հաստատել ծնող-երեխա հարաբերությունները: Հաճախորդ-պատվեր փոխհարաբերություններում հղման ամբողջականությունը ապահովում է հաճախորդի առկայությունը տվյալների բազայում յուրաքանչյուր պատվերի համար:
[Համապատասխանություն տվյալների ամբողջականության կանոններին. Աղբյուրային համակարգերի հարաբերական տվյալների շտեմարաններում պահվող տվյալները պետք է համապատասխանեն սուբյեկտի ամբողջականության և հղումային ամբողջականության կանոններին: Ցանկացած աղյուսակ, որը թույլ է տալիս null-ը որպես հիմնական բանալի, չունի էության ամբողջականություն: Հղման ամբողջականությունը ստիպում է ճիշտ հաստատել հարաբերությունները ծնողների և երեխաների միջև: Հաճախորդ-պատվեր հարաբերություններում, հղումային ամբողջականությունը երաշխավորում է, որ հաճախորդը գոյություն ունի տվյալների բազայի յուրաքանչյուր պատվերի համար:]

4. Տվյալների մաքրման որակը

Տվյալների մաքրման որակը բավականին խնդրահարույց խնդիր է bigdata-ում: Հարցին պատասխանելը, թե տվյալների մաքրման ինչ աստիճան է անհրաժեշտ առաջադրանքը կատարելու համար, հիմնարար է յուրաքանչյուր տվյալների վերլուծաբանի համար: Ընթացիկ խնդիրների մեծ մասում յուրաքանչյուր վերլուծաբան ինքն է դա որոշում, և դժվար թե դրսից որևէ մեկը կարողանա գնահատել այս կողմը իր լուծման մեջ: Բայց այս դեպքում առաջադրված առաջադրանքի համար այս խնդիրը չափազանց կարևոր էր, քանի որ իրավական տվյալների հավաստիությունը պետք է ձգվեր մեկին:

Հաշվի առնելով ծրագրային ապահովման փորձարկման տեխնոլոգիաները՝ գործառնական հուսալիությունը որոշելու համար: Այսօր այս մոդելներից ավելին կան 200. Մոդելներից շատերը օգտագործում են պահանջների սպասարկման մոդել.

Բրինձ. 6

Մտածելով հետևյալ կերպ. «Եթե հայտնաբերված սխալը նման իրադարձություն է այս մոդելի ձախողման իրադարձությանը, ապա ինչպե՞ս գտնել t պարամետրի անալոգը»: Եվ ես կազմեցի հետևյալ մոդելը. Եկեք պատկերացնենք, որ փորձարկողից մեկ գրառումը ստուգելու ժամանակը 1 րոպե է (խնդրի տվյալների բազայի համար), այնուհետև բոլոր սխալները գտնելու համար նրան կպահանջվի 365 րոպե, ինչը մոտավորապես 494 տարի և 3 է։ ամիսների աշխատանքային ժամանակ. Ինչպես հասկանում ենք, սա շատ մեծ ծավալի աշխատանք է, և տվյալների բազայի ստուգման ծախսերը չափազանց մեծ կլինեն այս տվյալների բազան կազմողի համար: Այս արտացոլման մեջ ի հայտ է գալիս ծախսերի տնտեսական հայեցակարգը և վերլուծությունից հետո ես եկա այն եզրակացության, որ սա բավականին արդյունավետ գործիք է։ Հիմնվելով տնտեսագիտության օրենքի վրա. «Արտադրության ծավալը (միավորներով), որով ձեռք է բերվում ընկերության առավելագույն շահույթը, գտնվում է այն կետում, որտեղ արտադրանքի նոր միավորի արտադրության սահմանային արժեքը համեմատվում է այն գնի հետ, որը կարող է ստանալ այս ընկերությունը: նոր միավորի համար»։ Ելնելով այն պոստուլատից, որ յուրաքանչյուր հաջորդ սխալ գտնելը պահանջում է գրառումների ավելի ու ավելի շատ ստուգում, սա ծախսերի գործոն է: Այսինքն՝ թեստավորման մոդելներում ընդունված պոստուլատը ֆիզիկական իմաստ է ստանում հետևյալ օրինաչափությամբ. եթե i-րդ սխալը գտնելու համար անհրաժեշտ էր ստուգել n գրառում, ապա հաջորդ (i+3) սխալը գտնելու համար անհրաժեշտ կլինի. ստուգել մ գրառումները և միաժամանակ n<m. Այս պոստուլատը, թեստավորման մոդելներում, ձևակերպվում է հիմնականում այն ​​պահանջով, որ հայտնաբերված սխալները պետք է գրանցվեն, բայց չուղղվեն, որպեսզի ծրագրակազմը փորձարկվի իր բնական վիճակում, այսինքն՝ խափանումների հոսքը միատեսակ լինի: Համապատասխանաբար, մեր դեպքում, գրառումների ստուգումը կարող է բացահայտել միատարրության երկու տարբերակ.

1. Երբ նոր սխալի հայտնաբերումից առաջ ստուգված գրառումների թիվը կայունանում է.
2. Երբ հաջորդ սխալը գտնելուց առաջ ստուգված գրառումների թիվը կաճի:

Կրիտիկական արժեքը որոշելու համար ես դիմեցի տնտեսական իրագործելիության հայեցակարգին, որն այս դեպքում, օգտագործելով սոցիալական ծախսերի հայեցակարգը, կարելի է ձևակերպել հետևյալ կերպ. դա ամենացածր գնով»։ Մենք ունենք մեկ գործակալ՝ փորձարկող, ով 1 րոպե է ծախսում մեկ ձայնագրությունը ստուգելու համար։ Դրամական արտահայտությամբ, եթե դուք օրական վաստակում եք 6000 ռուբլի, ապա դա կկազմի 12,2 ռուբլի: (մոտավորապես այսօր): Մնում է որոշել տնտեսական իրավունքում հավասարակշռության երկրորդ կողմը։ Ես այսպես պատճառաբանեցի. Գոյություն ունեցող սխալը կպահանջի, որ շահագրգիռ անձը ջանքեր գործադրի այն շտկելու համար, այսինքն՝ գույքի սեփականատերը: Ենթադրենք, սա պահանջում է 1 օր գործողություն (ներկայացրեք դիմում, ստացեք շտկված փաստաթուղթ): Հետո սոցիալական տեսանկյունից նրա ծախսերը կհավասարվեն օրական միջին աշխատավարձին։ Միջին հաշվարկված աշխատավարձը Խանտի-Մանսի Ինքնավար Օկրուգում «Խանտի-Մանսիյսկի ինքնավար օկրուգ-Ուգրայի սոցիալ-տնտեսական զարգացման արդյունքները 2019 թվականի հունվար-սեպտեմբեր ամիսներին» 73285 ռուբ. կամ 3053,542 ռուբլի/օր: Ըստ այդմ, մենք ստանում ենք կրիտիկական արժեք, որը հավասար է.
3053,542: 12,2 = 250,4 միավոր գրառումներ:

Սա նշանակում է, որ սոցիալական տեսանկյունից, եթե փորձարկողը ստուգել է 251 գրառում և գտել մեկ սխալ, դա հավասարազոր է նրան, որ օգտատերը ինքն է ուղղում այս սխալը: Համապատասխանաբար, եթե փորձարկիչը ժամանակ է ծախսել, որը հավասար է 252 գրառումների ստուգմանը հաջորդ սխալը գտնելու համար, ապա այս դեպքում ավելի լավ է ուղղման արժեքը տեղափոխել օգտվողին:

Այստեղ ներկայացված է պարզեցված մոտեցում, քանի որ սոցիալական տեսանկյունից անհրաժեշտ է հաշվի առնել յուրաքանչյուր մասնագետի կողմից առաջացած ողջ լրացուցիչ արժեքը, այսինքն՝ ծախսերը, ներառյալ հարկերը և սոցիալական վճարները, բայց մոդելը պարզ է: Այս հարաբերությունների հետևանքն է մասնագետների համար հետևյալ պահանջը. ՏՏ ոլորտի մասնագետը պետք է միջին հանրապետականից բարձր աշխատավարձ ունենա։ Եթե ​​նրա աշխատավարձը ցածր է տվյալների բազայի պոտենցիալ օգտագործողների միջին աշխատավարձից, ապա նա ինքը պետք է ձեռնամուխ եղավ ստուգել տվյալների ամբողջ բազան։

Նկարագրված չափանիշն օգտագործելիս ձևավորվում է տվյալների բազայի որակի առաջին պահանջը.
I(tr). Կրիտիկական սխալների բաժինը չպետք է գերազանցի 1/250,4 = 0,39938%: Մի քիչ պակաս, քան զտում ոսկին արդյունաբերության մեջ. Իսկ ֆիզիկական առումով սխալներով ոչ ավելի, քան 1459 գրառում։

Տնտեսական նահանջ.

Փաստորեն, գրառումներում նման քանակի սխալներ թույլ տալով, հասարակությունը համաձայնում է տնտեսական կորուստների չափով.

1459*3053,542 = 4 ռուբլի:

Այս գումարը որոշվում է նրանով, որ հասարակությունը չունի այդ ծախսերը նվազեցնելու գործիքներ։ Հետևում է, որ եթե ինչ-որ մեկն ունի տեխնոլոգիա, որը թույլ է տալիս նվազեցնել սխալներով գրառումների թիվը, օրինակ՝ 259-ի, ապա դա թույլ կտա հասարակությանը խնայել.
1200*3053,542 = 3 ռուբլի:

Բայց միևնույն ժամանակ նա կարող է խնդրել իր տաղանդն ու աշխատանքը, լավ, ասենք՝ 1 միլիոն ռուբլի։
Այսինքն՝ սոցիալական ծախսերը կրճատվում են.

3 – 664 = 250 ռուբլի:

Ըստ էության, այս էֆեկտը BigDat տեխնոլոգիաների օգտագործման հավելյալ արժեքն է:

Բայց այստեղ պետք է հաշվի առնել, որ սա սոցիալական էֆեկտ է, և տվյալների բազայի սեփականատերը մունիցիպալ իշխանություններն են, նրանց եկամուտը այս տվյալների բազայում գրանցված գույքի օգտագործումից 0,3% տոկոսադրույքով կազմում է՝ 2,778 միլիարդ ռուբլի/: տարին։ Եվ այս ծախսերը (4 ռուբլի) նրան այնքան էլ չեն անհանգստացնում, քանի որ դրանք փոխանցվում են գույքի սեփականատերերին։ Եվ, այս առումով, Bigdata-ում ավելի կատարելագործվող տեխնոլոգիաներ մշակողը պետք է ցույց տա այս տվյալների բազայի սեփականատիրոջը համոզելու ունակություն, և նման բաները զգալի տաղանդ են պահանջում:

Այս օրինակում սխալների գնահատման ալգորիթմն ընտրվել է հուսալիության փորձարկման ժամանակ ծրագրային ապահովման ստուգման Շումանի մոդելի [2] հիման վրա։ Համացանցում տարածվածության և անհրաժեշտ վիճակագրական ցուցանիշներ ստանալու հնարավորության շնորհիվ: Մեթոդաբանությունը վերցված է Մոնախով Յու.Մ. «Տեղեկատվական համակարգերի ֆունկցիոնալ կայունությունը», տես նկ. 7-9.

Բրինձ. 7 – 9 Շումանի մոդելի մեթոդիկա





Այս նյութի երկրորդ մասում ներկայացված է տվյալների մաքրման օրինակ, որում ստացվում են Շումանի մոդելի օգտագործման արդյունքները։
Ներկայացնեմ ստացված արդյունքները.
Սխալների գնահատված թիվը N = 3167 n:
Պարամետր C, լամբդա և հուսալիության գործառույթ.

Նկար 17

Ըստ էության, լամբդան ինտենսիվության փաստացի ցուցանիշ է, որով սխալները հայտնաբերվում են յուրաքանչյուր փուլում: Եթե ​​նայեք երկրորդ մասին, ապա այս ցուցանիշի գնահատումը կազմում էր ժամում 42,4 սխալ, ինչը բավականին համեմատելի է Շումանի ցուցանիշի հետ: Վերևում որոշվեց, որ ծրագրավորողի կողմից սխալներ գտնելու արագությունը պետք է լինի 1 սխալից ոչ ցածր 250,4 գրառումների համար՝ րոպեում 1 գրառում ստուգելիս: Այսպիսով, Լամբդայի կրիտիկական արժեքը Շումանի մոդելի համար.

60 / 250,4 = 0,239617:

Այսինքն՝ սխալների հայտնաբերման ընթացակարգերի իրականացման անհրաժեշտությունը պետք է իրականացվի այնքան ժամանակ, քանի դեռ լամբդան՝ առկա 38,964-ից, իջնի մինչև 0,239617։

Կամ մինչև N ցուցիչը (սխալների հավանական թիվը) մինուս n (սխալների շտկված թիվը) իջնի մեր ընդունված շեմից՝ 1459 հատ:

Գրականություն

1. Մոնախով, Յու. Մ. Տեղեկատվական համակարգերի ֆունկցիոնալ կայունություն. 3 ժամում Մաս 1. Ծրագրային հուսալիություն՝ դասագիրք. նպաստ / Յու. Մ. Մոնախով; Վլադիմիր. պետություն համալսարան – Վլադիմիր՝ Իզվո Վլադիմ. պետություն Համալսարան, 2011. – 60 p. – ISBN 978-5-9984-0189-3 ։
2. Մարտին Լ. Շուման, «Հավանական մոդելներ ծրագրային ապահովման հուսալիության կանխատեսման համար»:
3. Տվյալների պահեստավորման հիմունքները ՏՏ մասնագետների համար / Paulraj Ponniah.-2nd ed.

Մաս երկրորդ. Տեսական

Source: www.habr.com