דה-נורמליזציה של מסדי נתונים ERP והשפעתה על פיתוח תוכנה: פתיחת טברנה בטורטוגה

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

איך לשמח את כולם? איך אפשר להימנע מלהשתגע מלתכנן ולתחזק מערכת כזו? מה לעשות אם לא רק הפיראטים והמלחים הרגילים מתחילים להגיע לטברנה?

הכל תחת חתך. אבל בוא נלך לפי הסדר.

1. מגבלות והנחות

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

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

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

הסבר על צורות רגילות ניתן באמצעות דוגמה המובנת ברמה היומיומית לרוב הקוראים. עם זאת, כהמחשה ויזואלית, בפסקאות 4-5, נעשה שימוש מכוון במשימה "פיקטיבית" במכוון. אם לא תעשה זאת ותיקח דוגמה כלשהי של ספרי לימוד, למשל, אותו מודל אחסון הזמנה מנקודה 2, אתה עלול למצוא את עצמך במצב שבו הפוקוס של הקורא יועבר מהפירוק המוצע של התהליך למודל, לחוויה אישית ותפיסה של האופן שבו יש לבנות תהליכים ומודלים לאחסון נתונים ב-IS. במילים אחרות, קחו שני מנתחי IT מוסמכים, תנו לאחד לספק שירותים ללוגיסטיקאים המסיעים נוסעים, והשני ללוגיסטיקאים המובילים מכונות לייצור שבבים. בקש מהם, מבלי לדון מראש ב-BP אוטומטי, ליצור מודל נתונים לאחסון מידע על נסיעה ברכבת.

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

2. צורות רגילות

הצורה הרגילה הראשונה של מסד הנתונים דורש אטומיות של כל התכונות.
בפרט, אם לאובייקט A יש תכונות לא מפתח a ו-b, כך ש-c=f(a,b) ובטבלה המתארת ​​אובייקט A מאחסנים את הערך של תכונה c, אז הצורה הרגילה הראשונה מופרת במסד הנתונים . לדוגמה, אם מפרט ההזמנה מציין כמות שיחידות המידה שלה תלויות בסוג המוצר: במקרה אחד זה יכול להיות חתיכות, בליטר אחר, בשלישית אריזות המורכבות מחתיכות (בדגם למעלה Good_count_WR) , אז האטומיות של תכונות מופרת במסד הנתונים. במקרה זה, כדי לומר מה צריך להיות אשכול הטבלה של מפרט ההזמנה, צריך תיאור ממוקד של תהליך העבודה ב-IS, ומכיוון שהתהליכים יכולים להיות שונים, יכולות להיות הרבה גרסאות "נכונות".

צורה רגילה שניה של מסד הנתונים מחייב עמידה בטופס הראשון ובטבלה משלו עבור כל גורם הקשור לתהליך העבודה ב-IS. אם בטבלה אחת יש תלות c=f1(a) ו-d=f2(b) ואין תלות c=f3(b), אז הצורה הנורמלית השנייה מופרת בטבלה. בדוגמה למעלה, אין תלות בין הזמנה לכתובת בטבלת ההזמנה. שנה את שם הרחוב או העיר ולא תהיה לך השפעה על התכונות החיוניות של ההזמנה.

מסד נתונים בצורת רגילה שלישית דורש ציות לצורה נורמלית שנייה והיעדר תלות פונקציונלית בין תכונות של ישויות שונות. ניתן לנסח כלל זה באופן הבא: "כל מה שניתן לחשב יש לחשב". במילים אחרות, אם יש שני אובייקטים A ו-B. בטבלה המאחסנת את התכונות של אובייקט A, תכונה C באה לידי ביטוי, ולאובייקט B יש תכונה b, כך שקיימת c=f4(b), אז הצורה הנורמלית השלישית מופר. בדוגמה למטה, התכונה כמות חתיכות (Total_count_WR) ברשומת ההזמנה טוענת בבירור שהיא מפרה את הצורה הרגילה השלישית

3. הגישה שלי ליישום נורמליזציה

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

2. השגת צורה נורמלית שלישית במובן המחמיר עשויה להיות לא מעשית בפועל ביצירת מערכות ERP אם חלק מהתנאים הבאים או כולם מתקיימים:

• תהליכים אוטומטיים רק לעתים רחוקות נתונים לשינויים,
• מועדי מחקר ופיתוח צפופים,
• הדרישות לשלמות הנתונים נמוכות יחסית (טעויות פוטנציאליות בתוכנה תעשייתית אינן מובילות לאובדן כסף או לקוחות על ידי לקוח התוכנה)
• וכו '

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

3. ניתן למתן את כל ההשלכות של דה-נורמליזציה של מודל הנתונים ב-IS שכבר נוצר על ידי מחקר מקדים יסודי של הקוד והבדיקה.

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

5. מומלץ לשאוף לצורה הרגילה השלישית של מסד נתונים אם:

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

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

4 בעיה להמחשה

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

מתחם מערכות המידע של הטברנה מורכב מהתוכנות הבאות:

• מערכת התרעה מוקדמת על לקוח שמזהה את הקטגוריה שלו על סמך מאפיינים אופייניים
• מערכת בקרה למארחות רובוטים וברמנים רובוטים
• מערכת ניהול מחסנים ומשלוחים לנקודת המכירה
• מערכת ניהול קשרי ספקים (SURP)

תהליך

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

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

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

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

5. דוגמאות לדנורמליזציה והשפעתה על פיתוח תוכנה

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

מופיעה ספריית סוגי לקוחות עם שני ערכים: 1 - פיראטים, 2 - מלחים, המשותף לכל מעגל המידע של החברה.

מערכת הודעות הלקוח מאחסנת מיד את תוצאת עיבוד התמונה כמזהה (מזהה) של הלקוח המוכר וסוגו: מלח או פיראט.

מזהה אובייקט מזוהה
קטגוריית לקוחות

100500
פיראט

100501
פיראט

100502
סיילור

נציין זאת שוב

1. המלחים שלנו הם למעשה אנשים מגולחים
2. הפיראטים שלנו הם למעשה אנשים מזוקנים

אילו בעיות במקרה זה צריכות להיפטר כדי שהמבנה שלנו ישאף לצורה הנורמלית השלישית:

• attribute atomity violation - קטגוריית לקוח
• ערבוב העובדה המנותחת והמסקנה בטבלה אחת
• קשר תפקודי קבוע בין תכונות של ישויות שונות.

בצורה מנורמלת, נקבל שתי טבלאות:

• תוצאת זיהוי בצורה של קבוצה של תכונות מבוססות,

מזהה אובייקט מזוהה
שיער פנים

100500
כן

100501
כן

100502
לא

• התוצאה של קביעת סוג הלקוח כיישום של ההיגיון המוטבע ב-IS כדי לפרש את המאפיינים שנקבעו

מזהה אובייקט מזוהה
מזהה זיהוי
קטגוריית לקוחות

100500
100001
פיראט

100501
100002
פיראט

100502
100003
סיילור

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

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

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

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

• תוצאת זיהוי בצורה של קבוצה של תכונות מבוססות,

מזהה אובייקט מזוהה
גרטה על החזה השמאלי
ציפור על הכתף
שיער פנים

100510
1
1
1

100511
0
0
1

100512

1
0

• התוצאה של קביעת סוג הלקוח (תנו לזה להיות תצוגה מותאמת אישית שבה מוצגים תיאורים מספריות)

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

בדוגמה לעיל, כל שלוש הצורות הרגילות מופרות, בואו ננסה להפר אותן בנפרד.

הפרה של הצורה הרגילה הראשונה:

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

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

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

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

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

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

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

הפרה של הצורה הנורמלית השנייה:

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

הפרה של הצורה הנורמלית השלישית:

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

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

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

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

ספרות

https://habr.com/en/post/254773/
קונולי תומס, ביג קרוליין. מאגר מידע. עיצוב, יישום ותמיכה. תיאוריה ופרקטיקה

מקור: www.habr.com