שרטטו את הקשרים
זמין גם ב-28 שפות
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
יחידה 2 מתוך 6 בפרק מידול נתונים למען המשמעות, הפרק השני בקורס Data Architect. כל יחידה עומדת בפני עצמה. הקודם: הקשיבו לשמות העצם · הבא: בנו את המודל הלוגי
השאלה שהיחידה הזו עונה עליה: איך הופכים ישויות מועמדות למודל נתונים מושגי?
יש לנו שמות עצם על הלוח. עכשיו אני רוצה לדעת על הקווים שבין הקופסאות, כי אוסף של ישויות הוא עוד לא באמת מודל נתונים. בקשרים נמצא חלק גדול מהמשמעות. שותף קמעונאי מפעיל מרכזי הפצה. מניפסט מפרט משלוחים. משלוח הולך לנמען. צוות מפעיל משאית. כל אחת מהאמירות האלה מספרת לי משהו על העסק, וכל אחת נותנת לי עוד שאלה לשאול.
התחילו בשפה של העסק
Section titled “התחילו בשפה של העסק ”אני עדיין לא רוצה לדבר על Salesforce. אני לא שואל אם זה צריך להיות קשר lookup או master-detail, לא חושב על אובייקטי צומת של Salesforce (Salesforce Junction Objects), ולא מחליט מה קורה כשרשומת הורה נמחקת. אני מנסה להבין את הקשר העסקי.
קחו את “שותף קמעונאי מפעיל מרכזי הפצה.” זה נשמע פשוט. אבל האם לשותף קמעונאי יש מרכז הפצה אחד או הרבה? ב-Steve Trucking, כל שותף קמעונאי מפעיל מרכז הפצה אזורי בכל אזור ש-Steve Trucking משרתת, אז הרבה. האם מרכז הפצה יכול להיות שייך ליותר משותף קמעונאי אחד? האם למרכז הפצה יש חשיבות משלו, עם צוות והיסטוריה משלו, או שהוא רק כתובת? אם שותף קמעונאי עוזב, האם עדיין אכפת לנו ממרכזי ההפצה שלו?
אלה לא שאלות על Salesforce. אלה שאלות עסקיות, והתשובות יכולות לשנות את המודל לגמרי.
לקרוא את הקווים
Section titled “לקרוא את הקווים ”לפני שנעמיק, אני רוצה לתת לכם את השפה שנשתמש בה בכל תרשים מכאן והלאה. היא שפה קטנה. קו בין שתי קופסאות אומר ששני הדברים קשורים, והסימנים בקצוות שלו אומרים כמה.
התחילו בקו פשוט, בלי שום סימן. משם אני מתחיל על הלוח: אני יודע ששני שמות העצם האלה קשורים, רק עוד לא שאלתי איך. ואז הקצוות מקבלים סימנים. פס אחד לרוחב הקו, הקו החוצה, פירושו אחד. רגל העורב (crow’s foot), הקצה שמתפצל לשלושה כמו רגל של ציפור, פירושה רבים. בהמשך היחידה תראו סימן שני מופיע ליד הראשון, פס או עיגול, והוא עונה על שאלה אחרת: האם יכול להיות אפס?
הכלל האחד שצריך לזכור: קוראים כל סימן ליד הקופסה שהוא נוגע בה. הסימן הקרוב ביותר לקופסה הוא המקסימום; הסימן הבא החוצה הוא המינימום.
שב, חכה, תמדל
Section titled “שב, חכה, תמדל ”לפני Steve Trucking, בחזרה לכלבים מיחידה 1. היו לנו חמש קופסאות: בעלים, מגדל, כלב, גזע ותרגיל. עכשיו אני שואל על הקווים ביניהן.
אחד או רבים? לבעלים יכול להיות יותר מכלב אחד; ל-Ana יש שניים. לכלב יש בעלים אחד, לפחות במודל שלנו. זה אחד-לרבים: פס ליד הבעלים, רגל עורב ליד הכלב. המגדל הוא באותה צורה: מגדל אחד מגדל הרבה כלבים.
האם יכול להיות אפס? Max הגיע מהכלבייה העירונית, אז אין לו מגדל בכלל. הקצה של המגדל מקבל עיגול: לכלב יש אפס או מגדל אחד. לעומת זאת, לכל כלב יש בעלים, אז הקצה הזה מקבל פס שני: בדיוק אחד.
רבים-לרבים? כלב יודע הרבה תרגילים, ותרגיל, נגיד שב, ידוע להרבה כלבים. זה רבים-לרבים, ובדיוק שם אני הולך לחפש מושג מוסתר. האם יש משהו בכך שהכלב הזה יודע את התרגיל הזה? כמה טוב היא עושה אותו, ומתי היא למדה אותו. לקשר יש עובדות משלו, אז הוא הופך לדבר בפני עצמו: תרגיל של כלב, כשהכלב בא קודם בשם, כי הכלב הוא זה שמניע אותו.
מה כל קו אומר? בעלים מחזיקים בכלב. מגדל מגדל אותו. כלב יודע את התרגילים שלו. תנו שמות לקווים, וכל אחד יוכל לקרוא לכם את המודל בחזרה.
עכשיו, או לאורך זמן? האם למישהו אכפת כמה טובה Bella בשב היום, או איך היא הגיעה לשם? אם מאלף בודק אותה כל כמה חודשים, כל בדיקה היא רשומה בפני עצמה: הערכת תרגיל, עם התאריך, רמת המיומנות ומי שבדק, מתחת לתרגיל של הכלב שהיא שייכת לו. אפילו לקשר שהפך לדבר יכולה להיות היסטוריה משלו.
את הגזע אני משאיר בינתיים לא מחובר. זו עדיין השאלה מיחידה 1, קופסה משלו או מילה על הכלב, ויחידה 4 מכריעה אותה.
כל אחת מהשאלות האלה עובדת באותה צורה על עסק אמיתי. עכשיו בואו נשאל אותן על Steve Trucking.
שאלו “אחד או רבים?”
Section titled “שאלו “אחד או רבים?” ”אחד הדברים הראשונים שאני רוצה להבין על קשר הוא הקרדינליות שלו. זה המונח מעולם מסדי הנתונים; השאלה פשוטה בהרבה: כמה מאלה יכולים להיות קשורים לכמה מאלה? ברמה המושגית יש שלושה דפוסים בסיסיים.
זה שלב חשוב בתהליך: לקחת שני שמות עצם שונים ולהבין את הקשר ביניהם. ברוב המקרים זה אחד-לרבים, או רבים-לאחד. רק בנסיבות נדירות תיתקלו באחד-לאחד.
אחד-לרבים נמצא בכל מקום. לשותף קמעונאי אחד יש הרבה מרכזי הפצה. מניפסט אחד מפרט הרבה משלוחים. למסלול אחד יש בערך עשר עצירות. כשאני שומע שפה כזו, אני מתחיל לשרטט את הקו.
ועכשיו הקו מקבל את הסימנים שלו. כל קצה אומר לכם כמה מהקופסה שהוא נוגע בה: הפס לאחד, רגל העורב לרבים. קראו אותו מכל קופסה: לשותף קמעונאי אחד יש הרבה מרכזי הפצה.
קשרי אחד-לאחד קיימים, אבל הם נדירים, וכשאני מוצא אחד, אני שואל כמה שאלות. האם אלה באמת שני שמות עצם שונים, או אותו אחד? אם הם שונים, מהו הקשר של אחד-לאחד ביניהם? והאם הוא תמיד יהיה אחד-לאחד, או רק אחד-לאחד כרגע? אלה שאלות מפתח בתכנון מודל הנתונים. צוות ומשאית נראים כמו אחד-לאחד בכל בוקר נתון: שני אנשים, משאית אחת, מסלול אחד. לאורך חודש הם לא, ושם מסתתר הקשר המעניין ביותר במודל הזה.
קשרי רבים-לרבים מעניינים במיוחד, כי הם הרבה פעמים מספרים לנו שיש עוד מושג בעסק. האם צוות יכול לנהוג ביותר ממשאית אחת לאורך זמן? כן. האם במשאית יכול לנהוג יותר מצוות אחד? לאורך חייה, בהחלט. אז לצוותים ולמשאיות יש קשר של רבים-לרבים. אבל עכשיו אני רוצה לדעת יותר. האם אכפת לעסק מתי הייתה לצוות משאית? לאיזה מסלול, באיזה יום? מי ביצע את השיבוץ? אם הקשר עצמו נושא מידע שחשוב לנו, גילינו עוד מושג עסקי: שיבוץ צוות (Crew Assignment).
זה הרגל מידול חשוב. לפעמים הדבר המעניין ביותר הוא לא אחד משמות העצם ששמענו בהתחלה. הוא מסתתר בקשר שבין שני שמות עצם.
קשרים יכולים להפוך לדברים
Section titled “קשרים יכולים להפוך לדברים ”זה אחד המקומות שבהם אני רוצה שאדמינים יתחילו לחשוב אחרת. ב-Salesforce אנחנו רגילים לדבר על אובייקטים ושדות, אז קל להתייחס לקופסאות כחלק החשוב ולקווים כאינסטלציה. אבל לקשר עצמו יכולה להיות משמעות עסקית.
חשבו על משלוח ועל המוצרים שבו. משלוח יכול לשאת כמה מוצרים, נגיד מכונת כביסה ומייבש. מוצר, אותו דגם מקרר, מופיע באלפי משלוחים. קל מספיק. אבל מה אם אני צריך לדעת כמה יחידות מהמוצר הזה יש במשלוח הזה, האם הוא מותקן, או האם הישן מפונה? כבר לא מעניין אותי רק קשר בין משלוח למוצר. מעניין אותי פריט משלוח (Delivery Item), והמושג הזה ראוי לישות משלו.
אם אתם מגיעים מ-Salesforce, אולי אתם כבר חושבים: “זה אובייקט צומת.” אתם לא טועים. אבל אני לא רוצה להתחיל משם. פריט משלוח הוא מושג עסקי לפני שהוא אובייקט צומת של Salesforce (Salesforce Junction Object). קודם העסק, אחר כך המימוש.
כמה הרגלים שלי לישויות הקשר האלה, איפה שלא ייבנו בסוף.
תנו לה שם. אם לעסק כבר יש מילה בשבילה, השתמשו במילה שלהם. אם אין, קחו את השמות של שני ההורים וחברו אותם. חשבו על הזמנה ומוצר. הדבר שביניהם הוא פריט הזמנה (Order Item): ההזמנה, והפריט שבהזמנה. זה ילד של שני ההורים, וב-Salesforce הוא עשוי להפוך לאובייקט צומת של Salesforce. אבל איזה שם בא קודם: Item Order או Order Item? הסתכלו על סוג הנתונים של כל הורה. המוצר הוא נתוני ייחוס; ההזמנה היא נתוני תנועות, וההזמנה היא זו שמניעה אותו. אז זה Order Item, או Order Product, בדיוק כמו של-Salesforce יש Opportunity Product. ב-Steve Trucking זה פריט המשלוח (Delivery Item). השם המניע בא קודם, והרשומה ממוינת ליד הבעלים שלה בכל רשימה שתסתכלו עליה אי פעם.
תנו לה מפתח משלה. מפתה לומר שפריט משלוח מזוהה על ידי משלוח ועוד מוצר ולעצור שם. זה מפתח מורכב, והרבה יותר קשה להתמודד עם מפתחות מורכבים: כל מערכת שמצביעה על הרשומה צריכה לשאת את שני החצאים. תנו לישות הקשר מזהה משלה, ושמרו את משלוח ועוד מוצר ככלל של ייחודיות, לא כמזהה.
שימו לב מה לא נמצא עליו: מספר סידורי. כמות ומספר סידורי לא שייכים לאותה רשומה. כמות סופרת כמה יחידות של דבר; מספר סידורי מזהה דבר אחד מסוים. אם העסק צריך מספרים סידוריים, כל יחידה הופכת לרשומה משלה, וחמישה מקררים הם חמש רשומות. אני לא רואה מקרה לפריט משלוח עם פירוט פריט משלוח מתחתיו. זה או זה או זה: צבירה עם כמות, או רשומה אחת לכל יחידה. כאן, זו הכמות.
שימו עין על המאפיינים שרוצים היסטוריה. חלק מישויות הקשר מתייצבות ברגע שהן נוצרות: מכונת הכביסה במשלוח הזה נשארת מכונת הכביסה במשלוח הזה. אחרות ממשיכות להשתנות. לצוות יש את משאית 117 השבוע, ובשבוע הבא המשאית עוברת לצוות אחר. כשהקשר משתנה ולעסק אכפת מה הוא היה פעם, ישות הקשר צריכה תאריכים, ושיבוץ הצוות הוא זה שצריך לשים עליו עין. שאלו מוקדם אם לעסק אכפת מעכשיו או לאורך זמן; נחזור לזה עוד רגע.
לקשרים יש משמעות מעבר לקרדינליות
Section titled “לקשרים יש משמעות מעבר לקרדינליות ”“אחד-לרבים” לא מספיק כדי להבין קשר. אני רוצה לדעת גם מה הקשר אומר.
למשלוח יש מיקום. איזה מיקום? מרכז ההפצה שהוא יוצא ממנו? הבית של הנמען שהוא הולך אליו? הם לא ניתנים להחלפה. לשני מודלים יכולות להיות בדיוק אותן קופסאות ואותה קרדינליות, והקווים יכולים לומר דברים שונים לגמרי. בגלל זה מודל טוב הוא לא רק קופסאות שמחוברות בקווים. הקווים צריכים שמות. אם אני מוסר את התרשים שלי לארכיטקט אחר, הוא לא אמור לנחש מה קשר אומר, ואם אני מציג אותו לעסק, הוא צריך להשתמש בשפה שהם מזהים.
גם חובה או רשות חשובים
Section titled “גם חובה או רשות חשובים ”יש עוד שאלה שמסתתרת בתוך “כמה?”: האם הקשר הוא חובה? האם משלוח יכול להתקיים לפני שהוא שובץ למסלול? הוא חייב: המניפסט מגיע יום או יומיים לפני המשלוח, והמסלולים נסגרים בערב שלפני. האם משלוח יכול להתקיים בלי שותף קמעונאי? לא; כל משלוח מגיע ממניפסט של שותף. זו אופציונליות: חובה או רשות.
שוב, אל תקפצו ישר לתיבת סימון Required (חובה) של Salesforce. יש הבדל בין לומר “לכל משלוח חייב להיות שותף קמעונאי” לבין לומר “Salesforce צריכה לחייב את שדה השותף הקמעונאי כשהרשומה נוצרת.” ייתכן שבסוף הם יהיו אותו מימוש, אבל הם לא אותה אמירה. הראשונה היא כלל עסקי; השנייה היא דרך אחת לאכוף אותו. כארכיטקטים, אנחנו רוצים להבין את הראשונה לפני שמחליטים על השנייה.
בתרשים, חובה או רשות הם הסימן השני בכל קצה. הסימן הקרוב ביותר לקופסה הוא המקסימום: הפס לאחד, רגל העורב לרבים. הסימן הבא החוצה הוא המינימום: פס נוסף פירושו לפחות אחד, עיגול פירושו שיכול להיות אפס. אז כל משלוח נמצא בדיוק במניפסט אחד, ומניפסט מפרט משלוח אחד או רבים. משלוח נמצא באפס או בעצירה אחת, אפס עד שהוא שובץ למסלול, ובעצירה מוסרים אפס או רבים משלוחים.
הזמן משנה קשרים
Section titled “הזמן משנה קשרים ”הנה שאלה שאני שואל הרבה: אתם מתכוונים לעכשיו, או לאורך זמן?
צוות מפעיל משאית. כרגע? למסלול של היום? כל עוד שני האנשים האלה עובדים יחד? כל אחת מהתשובות מייצרת מודל אחר. אם לעסק אכפת רק באיזו משאית יש לצוות היום, המודל יכול להישאר פשוט. אם הוא צריך כל משאית שצוות נהג בה, מתי, ובאיזה מסלול, אנחנו צריכים היסטוריה, ושיבוץ הצוות שגילינו פתאום חשוב מאוד.
זה מקור נפוץ לטעויות מידול. אנחנו ממדלים את המצב הנוכחי כי זה מה שאנחנו רואים על המסך. ואז, שבועות אחר כך, שותף קמעונאי מגיש תביעת נזק ומישהו שואל: “איזה צוות היה עם משאית 117 ב-17 במרץ?” ואנחנו מגלים שדרסנו את התשובה בכל פעם שהשיבוץ השתנה.
דרך אחת לשמור את ההיסטוריה הזו היא להפוך את השיבוץ לרשומה משלו. כשצוות משובץ, אנחנו יוצרים שיבוץ צוות עם תאריך התחלה. כשהשיבוץ משתנה, אנחנו שמים תאריך סיום על הרשומה הישנה ויוצרים רשומה חדשה עם תאריך התחלה משלה. עכשיו “למי היה השיבוץ הזה לפני שישה חודשים?” היא שאלה פשוטה לענות עליה, במקום לחפור בהיסטוריית שדות או ביומן של שינויי נתונים. וברגע שלצוות היו הרבה שיבוצים, מישהו ישאל איזה מהם הנוכחי, אז הייתי מוסיף גם דגל Active (פעיל).
אז כשמישהו מספר לי על קשר, אני לא שואל רק איך הדברים קשורים. אני שואל: האם הקשר הזה משתנה, והאם אכפת לנו מההיסטוריה שלו?
שרטטו לפני שאתם מגדירים
Section titled “שרטטו לפני שאתם מגדירים ”המודל של Steve Trucking מתחיל להיות שימושי. אנחנו יודעים אילו קשרים הם אחד-לרבים, איפה קשר רבים-לרבים מסתיר מושג נוסף, אילו קשרים הם רשות, ואילו משתנים לאורך זמן. ועדיין לא יצרנו אף אובייקט של Salesforce. זה מכוון.
התרשים הזה צריך להיות משהו שאני יכול לשים מול העסק, והם לא אמורים להכיר את Salesforce כדי להגיד לי אם הוא נכון. אם הם לא יכולים לאמת אותו כי הוא מלא במונחים של Salesforce, עברתי מהר מדי לתכנון הפיזי.
מה הארכיטקט מחליט כאן
Section titled “מה הארכיטקט מחליט כאן ”כשאני עובר על הקשרים במודל מושגי, אני מחליט:
- איך הישויות העסקיות המרכזיות קשורות זו לזו.
- האם כל קשר הוא אחד-לאחד, אחד-לרבים או רבים-לרבים, עכשיו ולאורך זמן.
- האם כל קשר הוא חובה או רשות.
- האם קשר של רבים-לרבים מסתיר מושג עסקי משמעותי.
- האם הקשר משתנה לאורך זמן, והאם אנחנו צריכים את ההיסטוריה שלו.
lookup או master-detail, הגדרת אובייקט הצומת, התנהגות מדורגת (cascade) ושיתוף הן החלטות פיזיות; נגיע אליהן. כרגע אנחנו עדיין עונים על השאלה החשובה יותר: איך העסק הזה באמת עובד? ברגע שנבין את הישויות ואת הקשרים ביניהן, נוכל להתחיל להוסיף את הפרטים שמתארים אותן. אז המודל המושגי שלנו מתחיל להפוך למודל נתונים לוגי.