מודל נתונים, מילון נתונים וארכיטקטורת נתונים ארגוניים

רווחים:

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

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

מודל נתונים ממשיך בשלוש רמות הפשטה. המודל הרעיוני (English conceptual) הוא הרמה הגבוהה ביותר: אילו ישויות עיקריות קיימות וכיצד הן קשורות? "הלקוח מבצע הזמנה, ההזמנה כוללת את המוצר". אין פרטים טכניים. המודל הלוגי מגדיר את התכונות (שדות), המפתחות וסוגי הקשר של כל ישות; אבל זה עדיין לא קשור למוצר מסד נתונים ספציפי. המודל הפיזי (אנגלית פיזיקלי) הוא הגרסה הקונקרטית של הטבלאות, סוגי הנתונים והאינדקסים במסד נתונים ספציפי (למשל SQL Server, PostgreSQL). שלוש הרמות הללו הן גרסאות מפורטות יותר ויותר של אותו רעיון.

ישות-יחסים ומפתחות

השפה הבסיסית של מודל הנתונים היא מודל ה-Entity-Relationship (ER). ניתן להתייחס לישות כעל טבלה: לקוח, הזמנה. התכונה היא העמודה של הטבלה: שם, מייל, סכום. מערכת יחסים היא האופן שבו ישויות מחוברות: ללקוח יכולות להיות הזמנות רבות (יחס אחד לרבים).

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

טיפ: כאשר ה-AI מייצר טיוטת ER, קל יותר לבקש במפורש את המפתח הראשי עבור כל טבלה ואת המפתח הזר עבור כל קשר. אבל אמת כל מפתח זר שהוצע על ידי המודל מול הכלל העסקי בפועל: לפעמים הקשר שאתה חושב שהוא "אחד לרבים" הוא למעשה "רבים לרבים".

נורמליזציה: מניעת הישנות

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

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

מילון נתונים: שפה נפוצה

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

שלושה מיני מארזים: לפי המספרים

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

מקרה 2 - סוג שגוי של מערכת יחסים. מומחה MIS במוסד חינוכי הכיר במערכת היחסים (אחד לרבים) "תלמיד שייך לכיתה" במודל שנוצר בבינה מלאכותית. עם זאת, תלמידים יכולים להירשם ליותר מכיתת בחירה אחת; מערכת היחסים הייתה למעשה רבים-לרבים ונדרש טבלת ביניים (Record). הטעות התגלתה בשטח כאשר תלמיד לא הצליח להירשם לכיתה ב'. אם ההצעה של ה-AI הייתה מאושרת, היא הייתה נתפסת מההתחלה.

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

הנחיה חלשה / הנחיה חזקה

הנחיה חלשה:

עיצוב מסד נתונים למסחר אלקטרוני.

הנחיה עוצמתית:

התפקיד שלך: אתה מודל נתונים מנוסה.נסח מודל נתונים LOGICAL לפי הכללים העסקיים הבאים.כללים:- לכל ישות: שדות, מפתח ראשי, שדות חובה.- עבור כל קשר: סוג (אחד-לרבים / רבים-לרבים) ומפתח זר.- הצע טבלת ביניים בקשרים רבים-לרבים.- נרמל טופס עד; אם אתה ממליץ על דה-נורמליזציה מכוונת, כתוב את הרציונל.- תווית [אישור נדרש] כל כלל עסקי שאינך בטוח בו. כללים עסקיים:- הלקוח יכול לבצע מספר הזמנות.- הזמנה מכילה מספר מוצרים; מוצר אחד מופיע בהזמנות רבות.- למוצרים יש קטגוריות.[כללים אחרים...]

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

ארבע תבניות הניתנות להעתקה

1) טיוטת מילון נתונים:

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

2) סקירת נורמליזציה:

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

3) טיוטת ER מכלל עסקי:

תרגם את הכללים העסקיים הבאים לישויות, תכונות וקשרים. ציין את סוג כל קשר (1-1, 1-N, N-N) ואם N-N, הצע טבלת ביניים. סמן כללים מעורפלים. כללים: [טקסט]

4) שאלות לאימות סוג קשר:

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

תרשים השוואה: רמות מודל

תכונה

מושגי

הגיוני

פיזית

פירוט

לפחות

בינוני

רוב

מפתח/קשר

נכסים עיקריים

מפתחות מוגדרים

כולל אינדקס/סוג

תלוי במסד נתונים

לא

לא

כן

קהל יעד

יחידה עסקית

אנליסט

מפתח/DBA

תרומה של AI

טיוטה

טיוטה חזקה

טיוטה, אישור DBA

טעויות נפוצות

• חושבים על מערכת יחסים של רבים לרבים כעל אחד לרבים. זוהי שגיאת הדוגמנות הנפוצה ביותר; אם טבלת הביניים נשכחת, המערכת לא יכולה לשמור על המצב בפועל.
• לשים הכל בטבלה אחת. איסוף כל השדות בטבלה אחת למען ה"פשטות" מייצר כפילות ועדכונים.
• לא כותב מילון נתונים. אותו KPI נותן תוצאות שונות כאשר המשמעות של השדות נשארת בתודעה.
• סומך באופן עיוור על ההמלצה של AI לגבי סוגי נתונים ואילוצים. המודל עשוי להציע אזור "גדול מספיק"; הכלל העסקי קובע את המגבלות בפועל (למשל, TR ID 11 ספרות).
• נורמליזציה מוחלטת. נורמליזציה מוגזמת בשכבת הדיווח מאטה את השאילתה; המטרה משתנה בהתאם להקשר.

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

לסיכום

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

משימת יישום

חשבו על "מערכת השאלות בספרייה": חברים, ספרים, רישומי הלוואה. (1) יש להפיק טיוטה לוגית של מודל באמצעות ההנחיה החזקה. (2) בדקו את סוג כל מערכת היחסים שהמודל מציע (באופן ספציפי, "האם לחבר יש יותר מעותק אחד של אותו ספר?") בעזרת שאלה עסקית. (3) מצא לפחות קשר רב-לרבים אחד והגדר טבלת ביניים. (4) כתוב שורות מילון נתונים עבור לפחות 4 שדות (שם, סוג, חובה, משמעות עסקית). (5) הדגש אילוץ שייתכן שהדגם התאים והסביר כיצד היית מאמת אותו.

רשימת בדיקה

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