داده ها را مانند بازی سنگ، کاغذ، قیچی پاک کنید. آیا این یک بازی با پایان است یا بدون پایان؟ بخش 1. نظری

1. داده های اولیه

پاکسازی داده ها یکی از چالش های پیش روی وظایف تجزیه و تحلیل داده ها است. این مطالب منعکس کننده تحولات و راه حل هایی بود که در نتیجه حل یک مشکل عملی تجزیه و تحلیل پایگاه داده در شکل گیری ارزش کاداستر به وجود آمد. منابع اینجا "گزارش شماره 01/OKS-2019 در مورد نتایج ارزیابی کاداستر ایالتی انواع املاک و مستغلات (به استثنای قطعات زمین) در قلمرو منطقه خودمختار Khanty-Mansiysk - Ugra".

فایل "مدل مقایسه ای total.ods" در "پیوست ب. نتایج تعیین KS 5. اطلاعات در مورد روش تعیین ارزش کاداستر 5.1 رویکرد مقایسه ای" در نظر گرفته شد.

جدول 1. شاخص های آماری مجموعه داده در فایل "مدل مقایسه ای total.ods"
تعداد کل فیلدها، عدد. - 44
تعداد کل رکوردها، عدد. — 365 490
تعداد کل کاراکترها، عدد. — 101 714 693
میانگین تعداد کاراکترها در یک رکورد، عدد. — 278,297
انحراف استاندارد کاراکترها در یک رکورد، عدد. — 15,510
حداقل تعداد کاراکترها در یک ورودی، عدد. - 198
حداکثر تعداد کاراکترها در یک ورودی، عدد. - 363

2. بخش مقدماتی. استانداردهای اساسی

در حین تجزیه و تحلیل پایگاه داده مشخص شده، وظیفه تعیین الزامات درجه تصفیه تشکیل شد، زیرا همانطور که برای همه روشن است، پایگاه داده مشخص شده عواقب حقوقی و اقتصادی را برای کاربران ایجاد می کند. در طول کار، مشخص شد که هیچ الزامات خاصی برای درجه تمیز کردن داده های بزرگ وجود ندارد. با تحلیل هنجارهای حقوقی در این موضوع به این نتیجه رسیدم که همگی از احتمالات شکل گرفته اند. یعنی یک کار مشخص ظاهر شده است، منابع اطلاعاتی برای کار جمع آوری می شود، سپس یک مجموعه داده تشکیل می شود و بر اساس مجموعه داده ایجاد شده، ابزارهایی برای حل مشکل ایجاد می شود. راه حل های به دست آمده نقاط مرجع در انتخاب از بین گزینه ها هستند. من این را در شکل 1 ارائه کردم.



از آنجایی که در تعیین هر استانداردی، ترجیحاً تکیه بر فناوری های اثبات شده است، الزامات مندرج در "تعریف و راهنمای یکپارچگی داده های MHRA GxP برای صنعت"، زیرا این سند را جامع ترین برای این موضوع دانستم. به طور خاص، در این بخش، این بخش می گوید: «لازم به ذکر است که الزامات یکپارچگی داده ها به طور یکسان برای داده های دستی (کاغذی) و الکترونیکی اعمال می شود. (ترجمه: "... الزامات یکپارچگی داده ها به طور یکسان برای داده های دستی (کاغذی) و الکترونیکی اعمال می شود"). این صورت بندی کاملاً به طور خاص با مفهوم "ادله کتبی" در مفاد ماده 71 قانون آیین دادرسی مدنی ، ماده 70 در ارتباط است. 75 CAS، ماده 84 APC، هنر "نوشته". XNUMX قانون آیین دادرسی مدنی.

شکل 2 نمودار شکل گیری رویکردها به انواع اطلاعات در فقه را نشان می دهد.

برنج. 2. منبع اینجا.

شکل 3 مکانیسم شکل 1 را برای وظایف "راهنمای" فوق نشان می دهد. با مقایسه، به راحتی می توان دریافت که رویکردهای مورد استفاده در هنگام برآوردن الزامات یکپارچگی اطلاعات در استانداردهای مدرن برای سیستم های اطلاعاتی در مقایسه با مفهوم حقوقی اطلاعات به طور قابل توجهی محدود است.

عکس. 3

در سند مشخص شده (راهنما)، اتصال به بخش فنی، قابلیت های پردازش و ذخیره داده ها، با نقل قول از فصل 18.2 به خوبی تأیید شده است. پایگاه داده رابطه ای: "این ساختار فایل ذاتا امن تر است، زیرا داده ها در قالب فایل بزرگی نگهداری می شوند که رابطه بین داده ها و ابرداده ها را حفظ می کند."

در واقع، در این رویکرد - از قابلیت های فنی موجود، هیچ چیز غیر عادی وجود ندارد و به خودی خود، این یک فرآیند طبیعی است، زیرا گسترش مفاهیم از بیشترین فعالیت مورد مطالعه - طراحی پایگاه داده ناشی می شود. اما، از سوی دیگر، هنجارهای قانونی به نظر می رسد که تخفیف هایی را در مورد قابلیت های فنی سیستم های موجود ارائه نمی دهد، به عنوان مثال: GDPR - مقررات عمومی حفاظت از داده ها.

برنج. 4. قیف قابلیت های فنی (منبع).

در این جنبه ها، مشخص می شود که مجموعه داده اصلی (شکل 1) اول از همه باید ذخیره شود و ثانیاً مبنایی برای استخراج اطلاعات اضافی از آن باشد. خوب، به عنوان مثال: دوربین‌هایی که قوانین ترافیک را ضبط می‌کنند همه جا هستند، سیستم‌های پردازش اطلاعات متخلفان را از بین می‌برند، اما اطلاعات دیگری نیز می‌تواند به سایر مصرف‌کنندگان ارائه شود، برای مثال، به عنوان نظارت بازاریابی بر ساختار جریان مشتریان به یک مرکز خرید. و این منبع ارزش افزوده اضافی در هنگام استفاده از BigDat است. این کاملاً ممکن است که مجموعه داده‌هایی که اکنون جمع‌آوری می‌شوند، در جایی در آینده، بر اساس مکانیزمی مشابه ارزش نسخه‌های نادر 1700 در زمان کنونی ارزش داشته باشند. از این گذشته، در واقع، مجموعه داده های موقت منحصر به فرد هستند و بعید است در آینده تکرار شوند.

3. بخش مقدماتی. معیارهای ارزیابی

در طول فرآیند پردازش، طبقه بندی زیر از خطاها ایجاد شد.

1. کلاس خطا (بر اساس GOST R 8.736-2011): الف) خطاهای سیستماتیک. ب) خطاهای تصادفی؛ ج) اشتباه

2. با کثرت: الف) تحریف تک; ب) چند اعوجاج.

3. با توجه به بحرانی بودن پیامدها: الف) بحرانی; ب) انتقادی نیست.

4. بر اساس منبع وقوع:

الف) فنی - خطاهایی که در حین کار با تجهیزات رخ می دهد. یک خطای نسبتاً مرتبط برای سیستم های اینترنت اشیا، سیستم هایی با درجه قابل توجهی تأثیر بر کیفیت ارتباطات، تجهیزات (سخت افزار).

ب) خطاهای اپراتور - خطاهایی در طیف وسیعی از اشتباهات تایپی اپراتور در حین ورود تا خطا در مشخصات فنی طراحی پایگاه داده.

ج) خطاهای کاربر - در اینجا خطاهای کاربر در کل محدوده از "فراموش کردن تغییر طرح" تا اشتباه متری برای پا وجود دارد.

5. به یک کلاس جداگانه جدا شده است:

الف) «وظیفه جداکننده»، یعنی فاصله و «:» (در مورد ما) زمانی که تکرار شد.
ب) کلماتی که با هم نوشته شده اند.
ج) بدون فاصله پس از سرویس کاراکترها
د) چند نماد متقارن: ()، ""، "...".

روی هم رفته، با سیستم سازی خطاهای پایگاه داده ارائه شده در شکل 5، یک سیستم مختصات نسبتا موثر برای جستجوی خطاها و توسعه یک الگوریتم پاکسازی داده برای این مثال شکل می گیرد.

برنج. 5. خطاهای معمولی مربوط به واحدهای ساختاری پایگاه داده (منبع: Oreshkov V.I., Paklin N.B. "مفاهیم کلیدی تلفیق داده ها").

دقت، یکپارچگی دامنه، نوع داده، سازگاری، افزونگی، کامل بودن، تکراری بودن، انطباق با قوانین تجاری، قطعیت ساختاری، ناهنجاری داده ها، وضوح، به موقع، رعایت قوانین یکپارچگی داده ها. (صفحه 334. اصول انبارداری داده برای متخصصان فناوری اطلاعات / Paulraj Ponniah. — 2nd ed.)

عبارت انگلیسی و ترجمه ماشینی روسی در داخل پرانتز ارائه شده است.

دقت. مقدار ذخیره شده در سیستم برای یک عنصر داده، مقدار مناسب برای آن رخداد عنصر داده است. اگر شما یک نام مشتری و یک آدرس ذخیره شده در یک رکورد دارید، آدرس آدرس صحیح مشتری با آن نام است. اگر در ثبت سفارش 1000 مقدار سفارش داده شده را 12345678 عدد یافتید، آن مقدار، مقدار دقیق آن سفارش است.
[دقت. مقدار ذخیره شده در سیستم برای یک عنصر داده، مقدار صحیح برای آن رخداد عنصر داده است. اگر نام و آدرس مشتری در یک رکورد ذخیره شده است، آدرس آدرس صحیح مشتری با آن نام است. اگر در ثبت سفارش 1000 مقدار سفارش داده شده را 12345678 عدد یافتید، آن مقدار، مقدار دقیق آن سفارش است.]

یکپارچگی دامنه مقدار داده یک ویژگی در محدوده مقادیر مجاز و تعریف شده قرار می گیرد. مثال رایج مقادیر مجاز "مرد" و "مونث" برای عنصر داده جنسیت است.
[یکپارچگی دامنه. مقدار داده مشخصه در محدوده مقادیر معتبر و تعریف شده قرار می گیرد. یک مثال کلی مقادیر معتبر "male" و "female" برای یک عنصر داده جنسیتی است.]

نوع داده. مقدار برای یک ویژگی داده در واقع به عنوان نوع داده تعریف شده برای آن ویژگی ذخیره می شود. وقتی نوع داده فیلد نام فروشگاه به عنوان «متن» تعریف می‌شود، همه نمونه‌های آن فیلد حاوی نام فروشگاه نشان‌داده‌شده در قالب متنی هستند و نه کدهای عددی.
[نوع داده. مقدار یک ویژگی داده در واقع به عنوان نوع داده تعریف شده برای آن ویژگی ذخیره می شود. اگر نوع داده فیلد نام فروشگاه به‌عنوان «متن» تعریف شود، همه نمونه‌های این فیلد به جای کدهای عددی، نام فروشگاه را در قالب متن نمایش داده می‌شوند.]

ثبات. شکل و محتوای یک فیلد داده در سیستم‌های منبع چندگانه یکسان است. اگر کد محصول برای محصول ABC در یک سیستم 1234 باشد، کد این محصول در هر سیستم منبع 1234 است.
[ثبات. شکل و محتوای فیلد داده در سیستم های منبع مختلف یکسان است. اگر کد محصول برای محصول ABC در یک سیستم 1234 باشد، کد آن محصول در هر سیستم منبع 1234 است.]

افزونگی. داده های مشابه نباید در بیش از یک مکان در یک سیستم ذخیره شوند. اگر به دلایل کارایی، یک عنصر داده عمداً در بیش از یک مکان در یک سیستم ذخیره شود، آنگاه افزونگی باید به وضوح شناسایی و تأیید شود.
[افزونگی. داده های مشابه نباید در بیش از یک مکان در سیستم ذخیره شوند. اگر به دلایل کارایی، یک عنصر داده عمداً در چندین مکان در یک سیستم ذخیره شود، افزونگی باید به وضوح تعریف و تأیید شود.]

کامل بودن. هیچ مقدار گمشده ای برای یک ویژگی معین در سیستم وجود ندارد. به عنوان مثال، در یک فایل مشتری، باید یک مقدار معتبر برای فیلد "state" برای هر مشتری وجود داشته باشد. در فایل مربوط به جزئیات سفارش، هر رکورد برای یک سفارش باید به طور کامل پر شود.
[کامل. هیچ مقدار گمشده ای برای این ویژگی در سیستم وجود ندارد. به عنوان مثال، فایل مشتری باید یک مقدار معتبر برای فیلد "وضعیت" برای هر مشتری داشته باشد. در فایل جزئیات سفارش، هر رکورد جزئیات سفارش باید به طور کامل تکمیل شود.]

تکثیر. مضاعف شدن. تکثیر رکوردها در یک سیستم به طور کامل حل می شود. اگر فایل محصول دارای سوابق تکراری است، تمام رکوردهای تکراری برای هر محصول شناسایی شده و یک مرجع متقابل ایجاد می شود.
[تکراری. تکراری بودن رکوردها در سیستم به طور کامل حذف شده است. اگر یک فایل محصول حاوی ورودی های تکراری شناخته شده باشد، تمام ورودی های تکراری برای هر محصول شناسایی شده و یک مرجع متقابل ایجاد می شود.]

انطباق با قوانین تجاری. مقادیر هر مورد داده مطابق با قوانین تجاری تعیین شده است. در سیستم حراج، قیمت چکش یا فروش نمی تواند کمتر از قیمت رزرو باشد. در سیستم وام بانکی، مانده وام باید همیشه مثبت یا صفر باشد.
[رعایت قوانین تجارت. مقادیر هر عنصر داده با قوانین تجاری تعیین شده مطابقت دارد. در سیستم حراج، قیمت چکش یا فروش نمی تواند کمتر از قیمت رزرو باشد. در سیستم اعتباری بانکی، مانده وام باید همیشه مثبت یا صفر باشد.]

قطعیت ساختاری هر جا که یک آیتم داده می تواند به طور طبیعی به اجزای جداگانه ساختار داده شود، آیتم باید دارای این ساختار کاملاً تعریف شده باشد. به عنوان مثال، نام یک فرد به طور طبیعی به نام، حرف اول و نام خانوادگی تقسیم می شود. مقادیر برای نام افراد باید به عنوان نام، حرف اول و نام خانوادگی ذخیره شود. این ویژگی کیفیت داده ها اجرای استانداردها را ساده می کند و مقادیر از دست رفته را کاهش می دهد.
[قطعیت ساختاری. در جایی که یک عنصر داده را می توان به طور طبیعی به اجزای جداگانه ساختار داد، عنصر باید دارای این ساختار کاملاً تعریف شده باشد. به عنوان مثال، نام یک شخص به طور طبیعی به نام، حرف اول و نام خانوادگی تقسیم می شود. مقادیر برای نام های فردی باید به عنوان نام، حرف اول و نام خانوادگی ذخیره شوند. این ویژگی کیفیت داده ها، کاربرد استانداردها را ساده می کند و مقادیر از دست رفته را کاهش می دهد.]

ناهنجاری داده ها یک فیلد باید فقط برای هدفی که برای آن تعریف شده است استفاده شود. اگر فیلد Address-3 برای هر خط سوم آدرس ممکن برای آدرس های طولانی تعریف شده باشد، این فیلد باید فقط برای ضبط خط سوم آدرس استفاده شود. نباید برای وارد کردن شماره تلفن یا فکس برای مشتری استفاده شود.
[ناهنجاری داده ها. یک فیلد فقط باید برای هدفی که برای آن تعریف شده است استفاده شود. اگر فیلد Address-3 برای هر خط آدرس سوم احتمالی برای آدرس های طولانی تعریف شده باشد، این فیلد فقط برای ثبت خط آدرس سوم استفاده می شود. نباید برای وارد کردن شماره تلفن یا فکس مشتری استفاده شود.]

وضوح. یک عنصر داده ممکن است دارای تمام ویژگی های دیگر داده های با کیفیت باشد، اما اگر کاربران معنای آن را به وضوح درک نکنند، آنگاه عنصر داده برای کاربران ارزشی ندارد. قراردادهای نامگذاری مناسب کمک می کند تا عناصر داده به خوبی توسط کاربران درک شوند.
[وضوح. یک عنصر داده ممکن است تمام ویژگی های دیگر داده های خوب را داشته باشد، اما اگر کاربران معنای آن را به وضوح درک نکنند، عنصر داده برای کاربران ارزشی ندارد. قراردادهای نامگذاری صحیح کمک می کند تا عناصر داده به خوبی توسط کاربران قابل درک باشد.]

به موقع کاربران به موقع بودن داده ها را تعیین می کنند. اگر کاربران انتظار دارند که داده‌های بعد مشتری بیش از یک روز نباشد، تغییرات داده‌های مشتری در سیستم‌های منبع باید روزانه در انبار داده اعمال شود.
[به موقع کاربران به موقع بودن داده ها را تعیین می کنند. اگر کاربران انتظار دارند که داده‌های بعد مشتری بیش از یک روز نباشد، تغییرات داده‌های مشتری در سیستم‌های منبع باید به صورت روزانه در انبار داده اعمال شود.]

مفید بودن. هر عنصر داده در انبار داده باید برخی از الزامات مجموعه کاربران را برآورده کند. یک عنصر داده ممکن است دقیق و با کیفیت باشد، اما اگر برای کاربران ارزشی نداشته باشد، وجود آن عنصر داده در انبار داده کاملاً غیر ضروری است.
[ سودمند. هر آیتم داده در فروشگاه داده باید برخی از الزامات مجموعه کاربر را برآورده کند. یک عنصر داده ممکن است دقیق و با کیفیت باشد، اما اگر ارزشی برای کاربران ایجاد نکند، لازم نیست آن عنصر داده در انبار داده باشد.]

پایبندی به قوانین یکپارچگی داده ها. داده های ذخیره شده در پایگاه داده های رابطه ای سیستم های منبع باید به یکپارچگی موجودیت و قوانین یکپارچگی ارجاعی پایبند باشند. هر جدولی که null را به عنوان کلید اصلی مجاز می‌داند، یکپارچگی موجودیت را ندارد. یکپارچگی ارجاعی باعث می شود که روابط والدین-فرزند به درستی برقرار شود. در رابطه مشتری به سفارش، یکپارچگی ارجاعی وجود مشتری را برای هر سفارش در پایگاه داده تضمین می کند.
[رعایت قوانین یکپارچگی داده ها. داده های ذخیره شده در پایگاه داده های رابطه ای سیستم های منبع باید با قوانین یکپارچگی موجودیت و یکپارچگی ارجاعی مطابقت داشته باشد. هر جدولی که null را به عنوان کلید اصلی مجاز می کند، یکپارچگی موجودیت ندارد. تمامیت ارجاعی باعث می شود که رابطه بین والدین و فرزندان به درستی برقرار شود. در رابطه مشتری-سفارش، یکپارچگی ارجاعی تضمین می کند که برای هر سفارش در پایگاه داده مشتری وجود دارد.]

4. کیفیت پاکسازی داده ها

کیفیت پاکسازی داده ها یک مسئله نسبتاً مشکل ساز در bigdata است. پاسخ به این سوال که چه درجه ای از پاکسازی داده ها برای تکمیل کار ضروری است برای هر تحلیلگر داده اساسی است. در اکثر مشکلات فعلی، هر تحلیلگر خودش این موضوع را تعیین می کند و بعید است که کسی از بیرون بتواند این جنبه را در راه حل خود ارزیابی کند. اما برای انجام وظیفه در این مورد، این موضوع بسیار مهم بود، زیرا قابلیت اطمینان داده های حقوقی باید به یک گرایش داشته باشد.

در نظر گرفتن فناوری های تست نرم افزار برای تعیین قابلیت اطمینان عملیاتی. امروزه بیشتر از این مدل ها وجود دارد 200. بسیاری از مدل ها از مدل خدمات ادعایی استفاده می کنند:

شکل 6

به این صورت فکر کنید: "اگر خطای یافت شده رویدادی مشابه رویداد شکست در این مدل باشد، چگونه می توان یک آنالوگ از پارامتر t را پیدا کرد؟" و من مدل زیر را جمع آوری کردم: بیایید تصور کنیم که مدت زمانی که یک تستر برای بررسی یک رکورد طول می کشد 1 دقیقه است (برای پایگاه داده مورد نظر)، سپس برای یافتن تمام خطاها به 365 دقیقه نیاز دارد که تقریباً 494 سال و 3 است. ماه ها زمان کار همانطور که متوجه شدیم، این مقدار کار بسیار زیادی است و هزینه های بررسی پایگاه داده برای کامپایلر این پایگاه داده گزاف خواهد بود. در این بازتاب، مفهوم اقتصادی هزینه ها ظاهر می شود و پس از تجزیه و تحلیل به این نتیجه رسیدم که این ابزار نسبتاً مؤثری است. بر اساس قانون اقتصاد: «حجم تولید (بر حسب واحد) که در آن حداکثر سود یک بنگاه به دست می‌آید، در نقطه‌ای قرار می‌گیرد که هزینه نهایی تولید یک واحد تولید جدید با قیمتی که این شرکت می‌تواند دریافت کند، مقایسه می‌شود. برای واحد جدید.» بر اساس این فرض که یافتن هر خطای بعدی مستلزم بررسی بیشتر و بیشتر سوابق است، این یک عامل هزینه است. یعنی فرض اتخاذ شده در مدل‌های آزمایشی در الگوی زیر معنای فیزیکی پیدا می‌کند: اگر برای یافتن خطای i باید n رکورد بررسی شود، برای یافتن خطای بعدی (i+3) لازم است. برای بررسی m رکوردها و همزمان n

1. هنگامی که تعداد رکوردهای بررسی شده قبل از یافتن یک خطای جدید تثبیت می شود.
2. هنگامی که تعداد رکوردهای بررسی شده قبل از یافتن خطای بعدی افزایش می یابد.

برای تعیین ارزش بحرانی، به مفهوم امکان‌سنجی اقتصادی پرداختم که در این مورد، با استفاده از مفهوم هزینه‌های اجتماعی، می‌توان آن را به صورت زیر بیان کرد: «هزینه‌های اصلاح خطا باید بر عهده عامل اقتصادی باشد که می‌تواند انجام دهد. با کمترین هزینه.» ما یک نماینده داریم - آزمایش کننده ای که 1 دقیقه را صرف بررسی یک رکورد می کند. از نظر پولی، اگر 6000 روبل در روز درآمد داشته باشید، این مبلغ 12,2 روبل خواهد بود. (تقریبا امروز). باقی مانده است که طرف دوم تعادل در حقوق اقتصادی مشخص شود. من اینجوری استدلال کردم یک خطای موجود مستلزم آن است که شخص مربوطه تلاش کند تا آن را اصلاح کند، یعنی مالک ملک. فرض کنید این کار به 1 روز اقدام نیاز دارد (ارسال یک درخواست، دریافت یک سند اصلاح شده). سپس از نظر اجتماعی هزینه های او معادل متوسط ​​حقوق در روز خواهد بود. میانگین حقوق انباشته در منطقه خودمختار خانتی مانسی "نتایج توسعه اجتماعی-اقتصادی منطقه خودمختار Khanty-Mansiysk - Ugra برای ژانویه-سپتامبر 2019" 73285 روبل. یا 3053,542 روبل در روز. بر این اساس، مقدار بحرانی برابر با:
3053,542: 12,2 = 250,4 واحد رکورد.

این بدان معناست که از دیدگاه اجتماعی، اگر یک تستر 251 رکورد را بررسی کند و یک خطا پیدا کند، معادل آن است که کاربر خودش این خطا را برطرف کند. بر این اساس، اگر آزمایشگر برای یافتن خطای بعدی، زمانی معادل بررسی 252 رکورد را صرف کرده است، در این صورت بهتر است هزینه اصلاح را به کاربر منتقل کند.

یک رویکرد ساده در اینجا ارائه شده است، زیرا از نقطه نظر اجتماعی لازم است تمام ارزش اضافی تولید شده توسط هر متخصص، یعنی هزینه ها از جمله مالیات و پرداخت های اجتماعی در نظر گرفته شود، اما مدل واضح است. پیامد این رابطه الزامات زیر برای متخصصان است: یک متخصص صنعت IT باید حقوقی بیشتر از میانگین کشوری داشته باشد. اگر حقوق او کمتر از میانگین حقوق کاربران بالقوه پایگاه داده باشد، خود او باید کل پایگاه داده را دست به دست بررسی کند.

هنگام استفاده از معیار توصیف شده، اولین نیاز برای کیفیت پایگاه داده تشکیل می شود:
I(tr). سهم خطاهای بحرانی نباید از 1/250,4 = 0,39938٪ تجاوز کند. کمی کمتر از پالایش طلا در صنعت و از نظر فیزیکی بیش از 1459 رکورد با خطا وجود ندارد.

عقب نشینی اقتصادی

در واقع با انجام این تعداد اشتباه در سوابق، جامعه متعهد به زیان اقتصادی به میزان:

1459*3053,542 = 4،455،118 روبل.

این میزان با توجه به عدم برخورداری جامعه از ابزارهای کاهش این هزینه ها مشخص می شود. نتیجه این است که اگر شخصی فناوری‌ای داشته باشد که به او امکان می‌دهد تعداد رکوردهای دارای خطا را به مثلاً 259 کاهش دهد، این به جامعه اجازه می‌دهد تا پس‌انداز کند:
1200*3053,542 = 3،664،250 روبل.

اما در عین حال، او می تواند استعداد و کار خود را بخواهد، خوب، بیایید بگوییم - 1 میلیون روبل.
یعنی هزینه های اجتماعی با موارد زیر کاهش می یابد:

3 - 664 = 250 روبل.

در اصل، این اثر ارزش افزوده استفاده از فناوری BigDat است.

اما در اینجا باید در نظر گرفت که این یک اثر اجتماعی است و صاحب پایگاه داده مقامات شهرداری هستند، درآمد آنها از استفاده از اموال ثبت شده در این پایگاه داده به میزان 0,3٪: 2,778 میلیارد روبل / سال و این هزینه ها (4،455،118 روبل) او را زیاد آزار نمی دهد، زیرا به صاحبان ملک منتقل می شود. و از این جنبه، توسعه‌دهنده فناوری‌های پالایش بیشتر در Bigdata باید توانایی متقاعد کردن صاحب این پایگاه داده را نشان دهد و چنین چیزهایی مستلزم استعداد قابل توجهی است.

در این مثال، الگوریتم ارزیابی خطا بر اساس مدل شومان [2] تأیید نرم افزار در طول تست قابلیت اطمینان انتخاب شد. با توجه به رواج آن در اینترنت و امکان به دست آوردن شاخص های آماری لازم. روش شناسی از Monakhov Yu.M. "پایداری عملکردی سیستم های اطلاعاتی"، زیر اسپویلر در شکل 7 را ببینید. 9-XNUMX.

برنج. 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. قابلیت اطمینان نرم افزار: کتاب درسی. کمک هزینه / Yu. M. Monakhov; ولادیم. حالت دانشگاه – ولادیمیر: ایزوو ولادیم. حالت دانشگاه، 2011. – 60 ص. – شابک 978-5-9984-0189-3.
2. مارتین ال شومن، "مدل های احتمالی برای پیش بینی قابلیت اطمینان نرم افزار."
3. اصول انبارداری داده برای متخصصان فناوری اطلاعات / Paulraj Ponniah. - ویرایش دوم.

بخش دوم. نظری

منبع: www.habr.com