נקה נתונים כמו משחק רוק, נייר, מספריים. זה משחק עם או בלי סוף? חלק 1. תיאורטי

1. נתונים ראשוניים

ניקוי נתונים הוא אחד האתגרים העומדים בפני משימות ניתוח נתונים. חומר זה שיקף את ההתפתחויות והפתרונות שעלו כתוצאה מפתרון בעיה מעשית של ניתוח מאגר המידע בהיווצרות ערך קדסטרלי. מקורות כאן "דוח מס' 01/OKS-2019 על תוצאות הערכת השווי הקדסטרלית הממלכתית של כל סוגי הנדל"ן (למעט חלקות קרקע) בשטח האוקרוג האוטונומי חאנטי-מנסיסק - אוגרה".

נשקל הקובץ "מודל השוואתי total.ods" ב"נספח ב'. תוצאות קביעת ק"ש 5. מידע על אופן קביעת הערך הקדסטרלי 5.1 גישה השוואתית".

טבלה 1. אינדיקטורים סטטיסטיים של מערך הנתונים בקובץ "מודל השוואתי total.ods"
מספר הכולל של שדות, יחידות. - 44
סך כל הרשומות, יח'. — 365 490
מספר כולל של תווים, יח'. — 101 714 693
מספר תווים ממוצע ברשומה, יח'. - 278,297
סטיית תקן של תווים ברשומה, יח'. - 15,510
מספר מינימלי של תווים בערך, יח'. - 198
מספר תווים מקסימלי בערך, יח'. - 363

2. חלק מבוא. תקנים בסיסיים

תוך כדי ניתוח המאגר שצוין, נוצרה משימה לפרט את הדרישות לדרגת הטיהור, שכן, כפי שברור לכולם, מאגר הנתונים שצוין יוצר השלכות משפטיות וכלכליות על המשתמשים. במהלך העבודה התברר כי לא היו דרישות ספציפיות למידת ניקוי הביג דאטה. בניתוח הנורמות המשפטיות בעניין זה הגעתי למסקנה שכולן נוצרות מתוך אפשרויות. כלומר, הופיעה משימה מסוימת, מקורות מידע מורכבים עבור המשימה, ואז נוצר מערך נתונים ועל בסיס מערך הנתונים שנוצר, כלים לפתרון הבעיה. הפתרונות המתקבלים הם נקודות ייחוס בבחירה מבין חלופות. הצגתי זאת באיור 1.



מאחר שבעניין קביעת תקנים כלשהם, עדיף להסתמך על טכנולוגיות מוכחות, בחרתי בדרישות המפורטות ב "הגדרות של תקינות נתונים של MHRA GxP והנחיה לתעשייה", מכיוון שחשבתי את המסמך הזה כמקיף ביותר לסוגיה זו. בפרט, במסמך זה הסעיף אומר "יצוין שדרישות שלמות הנתונים חלות באופן שווה על נתונים ידניים (נייר) ואלקטרוניים." (תרגום: "...דרישות שלמות הנתונים חלות באופן שווה על נתונים ידניים (נייר) ונתונים אלקטרוניים"). ניסוח זה קשור באופן ספציפי למדי למושג "ראיה בכתב", בהוראות סעיף 71 לקוד סדר הדין האזרחי, אמנות. 70 CAS, סעיף 75 APC, "בכתב" Art. 84 קוד סדר הדין האזרחי.

איור 2 מציג תרשים של היווצרות גישות לסוגי מידע בפסיקה.

אורז. 2. מקור כאן.

איור 3 מציג את המנגנון של איור 1, עבור המשימות של "ההדרכה" לעיל. קל, על ידי ביצוע השוואה, לראות שהגישות הנהוגות בעמידה בדרישות שלמות המידע בתקנים מודרניים למערכות מידע מוגבלות משמעותית בהשוואה לתפיסה המשפטית של מידע.

איור 3

במסמך שצוין (Guidance), החיבור לחלק הטכני, יכולות עיבוד ואחסון נתונים, מאושש היטב על ידי ציטוט מפרק 18.2. מסד נתונים יחסי: "מבנה הקבצים הזה מאובטח יותר מטבעו, מכיוון שהנתונים מוחזקים בפורמט קובץ גדול המשמר את הקשר בין נתונים למטא נתונים."

למעשה, בגישה זו - מיכולות טכניות קיימות, אין שום דבר חריג וכשלעצמו זהו תהליך טבעי, שכן הרחבת המושגים מגיעה מהפעילות הנלמדת ביותר - עיצוב מסד נתונים. אבל, מצד שני, מופיעות נורמות משפטיות שאינן מספקות הנחות על היכולות הטכניות של מערכות קיימות, למשל: GDPR - תקנת הגנת מידע כללית.

אורז. 4. משפך של יכולות טכניות (מקור).

בהיבטים אלו, מתברר שמערכת הנתונים המקורית (איור 1) תצטרך, קודם כל, להישמר, ושנית, להוות בסיס להפקת מידע נוסף ממנו. ובכן, כדוגמה: מצלמות שמתעדות חוקי תנועה נמצאות בכל מקום, מערכות עיבוד מידע מנכות את המפרים, אך מידע אחר יכול להיות מוצע גם לצרכנים אחרים, למשל, כמעקב שיווקי אחר מבנה זרימת הלקוחות למרכז קניות. וזה מקור לערך מוסף נוסף בעת שימוש ב-BigDat. בהחלט ייתכן שלמערכי הנתונים הנאספים כעת, אי שם בעתיד, יהיה ערך לפי מנגנון דומה לערכם של מהדורות נדירות משנת 1700 בזמן הנוכחי. אחרי הכל, למעשה, מערכי נתונים זמניים הם ייחודיים ולא סביר שיחזרו על עצמם בעתיד.

3. חלק מבוא. קריטריונים להערכה

במהלך תהליך העיבוד, פותח סיווג השגיאות הבא.

1. מחלקת שגיאות (מבוסס על GOST R 8.736-2011): א) שגיאות שיטתיות; ב) שגיאות אקראיות; ג) טעות.

2. לפי ריבוי: א) עיוות מונו; ב) ריבוי עיוותים.

3. לפי קריטיות ההשלכות: א) קריטיות; ב) לא קריטי.

4. לפי מקור ההתרחשות:

א) טכני – שגיאות המתרחשות במהלך פעולת הציוד. שגיאה רלוונטית למדי עבור מערכות IoT, מערכות בעלות מידה משמעותית של השפעה על איכות התקשורת, ציוד (חומרה).

ב) שגיאות מפעיל - שגיאות במגוון רחב החל משגיאות הקלדה של מפעיל בזמן קלט ועד שגיאות במפרט הטכני לתכנון מסד נתונים.

ג) שגיאות משתמש - להלן שגיאות משתמש בכל הטווח מ"שכחת להחליף פריסה" ועד לטעות במטרים לרגליים.

5. מופרדים למחלקה נפרדת:

א) "משימת המפריד", כלומר הרווח ו":" (במקרה שלנו) כאשר הוא שוכפל;
ב) מילים שנכתבו יחד;
ג) אין רווח אחרי תווי השירות
ד) סמלים מרובים באופן סימטרי: (), "", "...".

ביחד, עם שיטתיות של שגיאות מסד נתונים המוצגת באיור 5, נוצרת מערכת קואורדינטות יעילה למדי לחיפוש שגיאות ופיתוח אלגוריתם לניקוי נתונים עבור דוגמה זו.

אורז. 5. שגיאות אופייניות המתאימות ליחידות המבניות של מסד הנתונים (מקור: Oreshkov V.I., Paklin N.B. "מושגי מפתח של איחוד נתונים").

דיוק, שלמות דומיין, סוג נתונים, עקביות, יתירות, שלמות, כפילות, התאמה לכללים עסקיים, הגדרה מבנית, אנומליות נתונים, בהירות, בזמן, עמידה בכללי שלמות נתונים. (עמוד 334. יסודות מחסני נתונים לאנשי IT / Paulraj Ponniah.-מהדורה שנייה)

הצג ניסוח באנגלית ותרגום מכונה לרוסית בסוגריים.

דיוק. הערך המאוחסן במערכת עבור רכיב נתונים הוא הערך הנכון עבור אותה התרחשות של רכיב הנתונים. אם יש לך שם לקוח וכתובת המאוחסנת ברשומה, אז הכתובת היא הכתובת הנכונה של הלקוח בשם זה. אם אתה מוצא את הכמות שהוזמנה כ-1000 יחידות ברשומה עבור מספר הזמנה 12345678, אזי הכמות הזו היא הכמות המדויקת עבור אותה הזמנה.
[דיוק. הערך המאוחסן במערכת עבור רכיב נתונים הוא הערך הנכון עבור אותה התרחשות של רכיב הנתונים. אם יש לך שם לקוח וכתובת המאוחסנים ברשומה, אז הכתובת היא הכתובת הנכונה של הלקוח בשם זה. אם אתה מוצא את הכמות שהוזמנה כ-1000 יחידות ברשומה עבור מספר הזמנה 12345678, אזי הכמות הזו היא הכמות המדויקת עבור אותה הזמנה.]

שלמות דומיין. ערך הנתונים של תכונה נופל בטווח הערכים המוגדרים המותרים. הדוגמה הנפוצה היא שהערכים המותרים הם "זכר" ו"נקבה" עבור אלמנט הנתונים המגדריים.
[שלמות תחום. ערך נתוני התכונה נמצא בטווח של ערכים חוקיים מוגדרים. דוגמה כללית היא הערכים התקפים "male" ו-"female" עבור אלמנט נתוני מגדר.]

סוג מידע. ערך עבור תכונת נתונים מאוחסן למעשה כסוג הנתונים שהוגדר עבור אותה תכונה. כאשר סוג הנתונים של שדה שם החנות מוגדר כ"טקסט", כל המופעים של שדה זה מכילים את שם החנות המוצג בפורמט טקסטואלי ולא קודים מספריים.
[סוג מידע. הערך של תכונת נתונים מאוחסן למעשה כסוג הנתונים שהוגדר עבור אותה תכונה. אם סוג הנתונים של שדה שם החנות מוגדר כ"טקסט", כל המופעים של שדה זה מכילים את שם החנות המוצג בפורמט טקסט במקום קודים מספריים.]

עֲקֵבִיוּת. הצורה והתוכן של שדה נתונים זהים במערכות מקור מרובות. אם קוד המוצר עבור מוצר ABC במערכת אחת הוא 1234, אז הקוד עבור מוצר זה הוא 1234 בכל מערכת מקור.
[עֲקֵבִיוּת. הצורה והתוכן של שדה הנתונים זהים במערכות מקור שונות. אם קוד המוצר עבור מוצר ABC במערכת אחת הוא 1234, אז הקוד עבור אותו מוצר הוא 1234 בכל מערכת מקור.]

יתירות. אסור לאחסן את אותם נתונים ביותר ממקום אחד במערכת. אם, מטעמי יעילות, רכיב נתונים מאוחסן בכוונה ביותר ממקום אחד במערכת, יש לזהות ולאמת את היתירות בבירור.
[יתירות. אין לאחסן את אותם נתונים ביותר ממקום אחד במערכת. אם, מטעמי יעילות, רכיב נתונים מאוחסן בכוונה במספר מיקומים במערכת, יש להגדיר ולאמת את היתירות בבירור.]

שְׁלֵמוּת. לא חסרים ערכים עבור תכונה נתונה במערכת. לדוגמה, בקובץ לקוח, חייב להיות ערך חוקי עבור השדה "מדינה" עבור כל לקוח. בקובץ לפרטי הזמנה יש למלא כל רשומת פרט להזמנה במלואה.
[שְׁלֵמוּת. לא חסרים ערכים במערכת עבור תכונה זו. לדוגמה, לקובץ הלקוח חייב להיות ערך חוקי עבור השדה "סטטוס" עבור כל לקוח. בקובץ פרטי ההזמנה, יש למלא כל רשומת פרטי הזמנה במלואה.]

שִׁכפוּל. שכפול רשומות במערכת נפתר לחלוטין. אם ידוע שקובץ המוצר מכיל רשומות כפולות, אזי כל הרשומות הכפולות של כל מוצר מזוהות ונוצרת הפניה צולבת.
[לְשַׁכְפֵּל. שכפול רשומות במערכת בוטל לחלוטין. אם ידוע שקובץ מוצר מכיל ערכים כפולים, אזי כל הערכים הכפולים עבור כל מוצר מזוהים ונוצרת הפניה צולבת.]

התאמה לכללים העסקיים. הערכים של כל פריט נתונים עומדים בכללים העסקיים שנקבעו. במערכת מכירות פומביות, מחיר הפטיש או המכירה לא יכול להיות נמוך ממחיר המילואים. במערכת הלוואות בנקאית, יתרת ההלוואה חייבת להיות תמיד חיובית או אפסית.
[עמידה בכללי העסק. הערכים של כל רכיב נתונים תואמים לכללים עסקיים שנקבעו. במערכת מכירות פומביות, מחיר הפטיש או המכירה לא יכול להיות נמוך ממחיר המילואים. במערכת אשראי בנקאית, יתרת ההלוואה חייבת להיות תמיד חיובית או אפסית.]

הגדרה מבנית. בכל מקום שבו ניתן לבנות פריט נתונים באופן טבעי לרכיבים בודדים, הפריט חייב להכיל מבנה מוגדר היטב זה. לדוגמה, שמו של אדם מתחלק באופן טבעי לשם פרטי, ראשי תיבות אמצעי ושם משפחה. יש לאחסן ערכים עבור שמות של אנשים כשם פרטי, ראשי תיבות אמצעי ושם משפחה. מאפיין זה של איכות נתונים מפשט את האכיפה של תקנים ומפחית ערכים חסרים.
[וודאות מבנית. כאשר רכיב נתונים יכול להיות מובנה באופן טבעי לרכיבים בודדים, האלמנט חייב להכיל מבנה מוגדר היטב זה. לדוגמה, שמו של אדם מחולק באופן טבעי לשם פרטי, ראשי תיבות אמצעי ושם משפחה. יש לאחסן ערכים עבור שמות בודדים כשם פרטי, ראשי תיבות אמצעי ושם משפחה. מאפיין איכות נתונים זה מפשט את היישום של תקנים ומפחית ערכים חסרים.]

אנומליה של נתונים. יש להשתמש בשדה רק למטרה שלשמה הוא מוגדר. אם השדה Address-3 מוגדר עבור כל שורת כתובת שלישית אפשרית עבור כתובות ארוכות, אזי יש להשתמש בשדה זה רק לרישום שורת הכתובת השלישית. אין להשתמש בו להזנת מספר טלפון או פקס עבור הלקוח.
[אנומלית נתונים. יש להשתמש בשדה רק למטרה שלשמה הוא מוגדר. אם השדה כתובת-3 מוגדר עבור כל שורת כתובת שלישית אפשרית עבור כתובות ארוכות, אזי שדה זה ישמש רק כדי להקליט את שורת הכתובת השלישית. אין להשתמש בו כדי להזין מספר טלפון או פקס עבור לקוח.]

בְּהִירוּת. אלמנט נתונים עשוי להחזיק בכל שאר המאפיינים של נתונים איכותיים, אך אם המשתמשים אינם מבינים את משמעותו בבירור, אזי לרכיב הנתונים אין ערך עבור המשתמשים. מוסכמות שמות נכונות עוזרות להפוך את רכיבי הנתונים למובנים היטב על ידי המשתמשים.
[בְּהִירוּת. לאלמנט נתונים עשויים להיות כל המאפיינים האחרים של נתונים טובים, אבל אם המשתמשים לא מבינים בבירור את המשמעות שלו, אז לרכיב הנתונים אין ערך למשתמשים. מוסכמות שמות נכונות עוזרות להפוך רכיבי נתונים למובנים היטב על ידי המשתמשים.]

בזמן. המשתמשים קובעים את עדכניות הנתונים. אם המשתמשים מצפים שנתוני ממד הלקוח לא יהיו ישנים מיום אחד, יש להחיל את השינויים בנתוני הלקוח במערכות המקור על מחסן הנתונים מדי יום.
[בתזמון הולם. המשתמשים קובעים את עדכניות הנתונים. אם משתמשים מצפים שנתוני מימד הלקוח יהיו בני לא יותר מיום אחד, יש להחיל שינויים בנתוני הלקוחות במערכות המקור על מחסן הנתונים על בסיס יומי.]

תוֹעֶלֶת. כל רכיב נתונים במחסן הנתונים חייב לעמוד בדרישות מסוימות של איסוף המשתמשים. אלמנט נתונים עשוי להיות מדויק ואיכותי, אך אם אין לו ערך עבור המשתמשים, אז זה מיותר לחלוטין שאלמנט הנתונים הזה יהיה במחסן הנתונים.
[תוֹעֶלֶת. כל פריט נתונים במאגר הנתונים חייב לעמוד בדרישות מסוימות של אוסף המשתמשים. רכיב נתונים עשוי להיות מדויק ואיכותי, אך אם הוא אינו מספק ערך למשתמשים, אין צורך שאותו רכיב נתונים יהיה במחסן הנתונים.]

הקפדה על כללי שלמות נתונים. הנתונים המאוחסנים במסדי הנתונים היחסים של מערכות המקור חייבים לעמוד בכללי שלמות הישות ושלמות ההתייחסות. לכל טבלה המאפשרת null כמפתח הראשי אין שלמות ישות. היושרה ההתייחסותית מאלצת את כינון יחסי הורה-ילד בצורה נכונה. ביחסי לקוח להזמנה, שלמות התייחסות מבטיחה את קיומו של לקוח עבור כל הזמנה במאגר.
[עמידה בכללי שלמות הנתונים. נתונים המאוחסנים במסדי נתונים יחסיים של מערכות מקור חייבים לעמוד בכללי שלמות הישות ושלמות ההתייחסות. לכל טבלה המאפשרת null כמפתח ראשי אין שלמות ישות. היושרה ההתייחסותית מאלצת את הקשר בין הורים לילדים להתבסס בצורה נכונה. ביחסי לקוח-הזמנה, שלמות התייחסות מבטיחה שקיים לקוח עבור כל הזמנה במסד הנתונים.]

4. איכות ניקוי הנתונים

איכות ניקוי הנתונים היא נושא בעייתי למדי בביגדאטה. מענה על השאלה איזו דרגת ניקוי נתונים נדרשת להשלמת המשימה היא בסיסית עבור כל מנתח נתונים. ברוב הבעיות הנוכחיות, כל מנתח קובע זאת בעצמו ולא סביר שמישהו מבחוץ מסוגל להעריך היבט זה בפתרון שלו. אבל עבור המשימה העומדת על הפרק במקרה זה, נושא זה היה חשוב ביותר, שכן מהימנות הנתונים המשפטיים צריכה להיות אחת.

בחינת טכנולוגיות בדיקת תוכנה כדי לקבוע מהימנות תפעולית. היום יש יותר מהדגמים האלה 200. רבים מהדגמים משתמשים במודל של שירות תביעות:

איור. מספר

חושב כדלקמן: "אם השגיאה שנמצאה היא אירוע דומה לאירוע הכשל במודל זה, אז איך למצוא אנלוגי של הפרמטר t?" והרכבתי את המודל הבא: בואו נדמיין שהזמן שלוקח לבוחן לבדוק רשומה אחת הוא דקה אחת (עבור בסיס הנתונים המדובר), ואז כדי למצוא את כל השגיאות הוא יזדקק ל-1 דקות, שזה בערך 365 שנים ו-494 חודשי זמן עבודה. כפי שאנו מבינים, מדובר בכמות גדולה מאוד של עבודה ועלויות בדיקת מסד הנתונים יהיו עצומות עבור המהדר של מסד נתונים זה. בהרהור זה מופיע המושג הכלכלי של עלויות ולאחר ניתוח הגעתי למסקנה שמדובר בכלי יעיל למדי. בהתבסס על חוק הכלכלה: "היקף הייצור (ביחידות) שבו מושג הרווח המקסימלי של פירמה נמצא בנקודה בה מושווה העלות השולית של ייצור יחידת תפוקה חדשה למחיר שפירמה זו יכולה לקבל. ליחידה חדשה." בהתבסס על ההנחה שמציאת כל שגיאה עוקבת דורשת יותר ויותר בדיקה של רשומות, זהו גורם עלות. כלומר, ההנחה שאומצה בבדיקת מודלים מקבלת משמעות פיזית בתבנית הבאה: אם כדי למצוא את השגיאה ה-i היה צורך לבדוק n רשומות, אז כדי למצוא את השגיאה הבאה (i+3) יהיה צורך לבדוק מ רשומות ובמקביל נ

1. כאשר מספר הרשומות שנבדקו לפני שנמצאה שגיאה חדשה מתייצב;
2. כאשר מספר הרשומות שנבדקו לפני מציאת השגיאה הבאה יגדל.

לקביעת הערך הקריטי פניתי למושג היתכנות כלכלית, שבמקרה זה, תוך שימוש במושג עלויות סוציאליות, ניתן לנסח כך: "עלויות תיקון הטעות צריכות להיות מוטלות על הגורם הכלכלי שיכול לעשות. זה בעלות הנמוכה ביותר." יש לנו סוכן אחד - בודק שמקדיש דקה אחת לבדיקת רשומה אחת. במונחים כספיים, אם אתה מרוויח 1 רובל ליום, זה יהיה 6000 רובל. (בערך היום). נותר לקבוע את הצד השני של שיווי המשקל במשפט הכלכלי. נימקתי ככה. טעות קיימת תחייב את הנוגע בדבר להשקיע מאמצים לתיקון, כלומר מבעל הנכס. נניח שזה דורש יום פעולה אחד (להגיש בקשה, לקבל מסמך מתוקן). ואז, מבחינה חברתית, העלויות שלו יהיו שוות לשכר הממוצע ליום. משכורת ממוצעת שנצברו במחוז חאנטי-מנסי האוטונומי "תוצאות הפיתוח החברתי-כלכלי של האוקרוג האוטונומי חאנטי-מנסיסק - אוגרה לינואר-ספטמבר 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 רובל.

סכום זה נקבע על ידי העובדה שאין לחברה את הכלים להוזיל עלויות אלו. מכאן נובע שאם למישהו יש טכנולוגיה המאפשרת לו לצמצם את מספר הרשומות עם שגיאות ל-, למשל, 259, אז זה יאפשר לחברה לחסוך:
1200*3053,542 = 3 רובל.

אבל באותו זמן, הוא יכול לבקש את כישרונו ועבודתו, ובכן, נניח - מיליון רובל.
כלומר, עלויות חברתיות מופחתות על ידי:

3 - 664 = 250 רובל.

למעשה, השפעה זו היא הערך המוסף מהשימוש בטכנולוגיות BigDat.

אך כאן יש לקחת בחשבון שמדובר בהשפעה חברתית, ובעלת המאגר היא רשויות עירוניות, הכנסתן משימוש בנכס שנרשם במאגר זה, בשיעור של 0,3%, היא: 2,778 מיליארד רובל/ שָׁנָה. ועלויות אלו (4 רובל) אינן מטרידות אותו במיוחד, שכן הן מועברות לבעלי הנכס. ובהיבט הזה, המפתח של טכנולוגיות זיקוק נוספות ב-Bigdata יצטרך להראות את היכולת לשכנע את הבעלים של מסד הנתונים הזה, ודברים כאלה דורשים כישרון ניכר.

בדוגמה זו, אלגוריתם הערכת השגיאות נבחר על סמך מודל שומאן [2] של אימות תוכנה במהלך בדיקת מהימנות. בשל שכיחותה באינטרנט והיכולת להשיג את האינדיקטורים הסטטיסטיים הדרושים. המתודולוגיה לקוחה מ- Monakhov Yu.M. "יציבות תפקודית של מערכות מידע", ראה מתחת לספוילר באיור. 7-9.

אורז. 7 – 9 מתודולוגיה של מודל שומאן





החלק השני של חומר זה מציג דוגמה לניקוי נתונים, שבה מתקבלות תוצאות השימוש במודל שומאן.
הרשו לי להציג את התוצאות שהתקבלו:
מספר משוער של טעויות N = 3167 n.
פרמטר C, למבדה ופונקציית מהימנות:

איור 17

בעיקרו של דבר, למבדה היא אינדיקטור ממשי לעוצמה שבה מתגלות שגיאות בכל שלב. אם אתה מסתכל על החלק השני, ההערכה עבור אינדיקטור זה היה 42,4 שגיאות לשעה, וזה די דומה לאינדיקטור שומאן. לעיל, נקבע כי הקצב שבו מפתח מוצא שגיאות לא צריך להיות נמוך מ-1 שגיאה לכל 250,4 רשומות, כאשר בודקים רשומה אחת לדקה. מכאן הערך הקריטי של הלמבדה עבור דגם שומאן:

60 / 250,4 = 0,239617.

כלומר, יש לבצע את הצורך בביצוע הליכי איתור שגיאות עד שהלמבדה, מה-38,964 הקיים, יורדת ל-0,239617.

או עד שהמחוון N (מספר פוטנציאלי של שגיאות) מינוס n (מספר שגיאות מתוקן) יורד מתחת לסף המקובל שלנו - 1459 יח'.

ספרות

1. Monakhov, Yu. M. יציבות תפקודית של מערכות מידע. תוך 3 שעות חלק 1. אמינות תוכנה: ספר לימוד. קצבה / יו' מ' מונקוב; ולאדים. מדינה univ. – ולדימיר: איזבו ולאדים. מדינה אוניברסיטה, 2011. – 60 עמ'. – ISBN 978-5-9984-0189-3.
2. מרטין ל. שומן, "מודלים הסתברותיים לחיזוי אמינות תוכנה."
3. יסודות מחסני נתונים לאנשי IT / Paulraj Ponniah.-מהדורה שנייה.

חלק שני. תֵאוֹרֵטִי

מקור: www.habr.com