מושגי יסוד
מושגי יסוד לבניית מודל לוגי
למה צריך מודל נתונים לוגי
מבוא
אחת המשימות החשובות ביותר של BA הינה להכין מודל לוגי של ישויות המערכת.
באמצעות תרשים מסוג .Class Diagram. כל מחלקה מציינת ישות או תת ישות.
מודל נתונים לוגי הינו אוסף של ישויות(Entities)
את התרשים ניתן ליצור בכלים ידועים כגון: PowerPoint, Visio או כלי UML יעודיים כגון
EA, ARIS,UML STAR
המנתח אמור להיות משוחרר מהמימוש הפיסי. למנתח ממש לא חשוב כיצד יבוצע המימוש
( Oracle,Sql Server,DB2,Mysql,Big Data…)
המטרות העיקריות של יצירת המודל:
יצירת שפה ארגונית משותפת לניתוח והבנת הנתונים למנתחים, מפתחים, בודקים, DBA
לאפשר ניתוח נתונים באופן איכותי
לשמש בסיס נוח לתכנון המסכים
לאפשר אינטגרציה של מידע בין מערכות
לאפשר ארכיטקטורת מידע מוכוונת שירותים SOA
להוות בסיס לבניית מודל הנתונים הפיסי: ה DB
התרשים של המודל יועבר ל DBA אשר יבנה ממנו את ה DB הפיסי של המערכת.
החשיבות העצומה של מודל הנתונים נובעת מכך שכל התהליכים במערכת ( חישובים, הוספת נתונים , עדכון נתונים, שליפת נתונים, הצגת נתונים,בקיצור כל פעולות ה CRUD Create,Read,Update,Delete) קשורים למודל הנתונים.
מודל נתונים איכותי הינו בסיס חיוני לאיכות הפתרון המוצע ללקוח
בדרך כלל נהוג להכין תרשים לוגי ראשוני שמכונה תרשים על ולאחר מכן לפרט אותו באמצעות תרשים מפורט יותר.
הסבר: מה זה ישות - Entity
ישות הינה נושא שעליו הארגון מעוניין לנהל מידע הדרוש לצורכי הפרויקט הנוכחי
להלן דוגמאות לישויות בארגונים שונים:
מכללה: הישויות העיקריות: סטודנטים, מרצים, קורסים
בית חולים: רופאים, מטופלים, תרופות
חברת ביטוח: סוכנים, פוליסות, תביעות, לקוחות
ישות עוסקת בתחום/גורם מהותי אשר סביבו או באמצעותו מבוצעת הפעילות העסקית
הישות מכילה תת ישויות במבנה היררכי
הישות מהווה מרכז למספר רב של תהליכים עסקיים. לדוגמא סביב חשבון בנק יש מספר רב של תהליכים עסקיים: פתיחת חשבון, סגירת חשבון, הפקדות, משיכות,העברות, הוראות קבע, הקפאת חשבון...
הסבר: תת ישויות
ישות מורכבת מהיררכיה של תתי ישויות ("בנים" ,"נכדים" ואפילו "נינים")
לישות יש תת ישות ראשית אחת שמזהה אותו ומספר רצוי של תתי ישויות רגילים
תת ישות הינה אוסף מאפיינים שלהם מכנה עסקי משותף
תת ישות הינה ייחודית לישות
תת ישות יכולה להיות חד מופעית או רב מופעית
תת ישות מוגדרת לעתים עקב הצורך בשמירת היסטוריה של שינוים
תת ישות מוגדרת לעתים עקב דרישות אבטחת מידע ייחודיות
דוגמאות
הישות: חבר בקופת חולים
תתי ישויות: פרטי זיהוי, רגישות לתרופות, ניתוחים, בדיקות...
הישות: עובד
תתי ישויות: פרטי זיהוי,השתלמויות, שפות, היסטוריה של דרגות, היסטוריה של תפקידים, העדרויות, אמצעי קשר ...
הסבר: סוגי ישויות
Internal - באחריות בלעדית של המערכת הנוכחית (מומלץ להציג בצבע צהוב)
External - באחריות מערכות אחר (מומלץ להציג בצבע תכלת)
Extended - ישות/תת ישות מעורבת-חלק מהשדות באחריות גורם(מומלץ להציג בצבע סגול))
חיצוני, חלק אחר באחריות המערכת הנוכחית
Lut - טבלאות תרגום/פענוח, Reference tables (מומלץ להציג בצבע ירוק)
הסבר: מה זה Lut
Look Up Table הינה ישות עצמאית מיוחדת שמנוהלת בדרך כלל על ידי מנהל המערכת.
התפקיד של הישויות מסוג זה הינו לשמור על אמינות הנתונים במערכת ולאפשר שליפות מדוייקות
דוגמא אופינית: טבלת ישובים. אם נשמור בישות עובד/יישות ספק/ישות לקוח את שם היישוב, יש סכנה ששם היישוב יוזן בצורות שונות . לדוגמא אם שם היישוב הינו תל אביב אזי ניתן לרשום: ת"א/ תל-אביב/ תל אביב יפו/ואפילו טל אביב ואז כאשר נרצה לשלוף את כל העובדים/ספקים/לקוחות מתל אביב נקבל רק תוצאה חלקית. לכן הפתרון הינו להגדיר טבלה בה ירוכזו שמות היישובים ובמקום להקליד את שם היישוב המשתמש יצטרך לבחור ערך מתוך LIST BOX.
תכונות משותפות של טבלאות LUT
מספר מופעים קטן - לרב עד עשרות בודדות ובמקרים קיצוניים כמה מאות מופעים לדוגמא: מדינות-כ 200, סוגי מטבע כ 30, שפות מובילות כ 20, סוגי לקוחות בארגון כ10, קידומות לטלפונים כ 15.....
רמת עדכון נמוכה, הערכים בישויות מסוג LUT מתעדכנים לעתים רחוקות מאד, עדכון שם יישוב או הוספת שם יישוב או ביטול שם יישוב מבוצע לעתים ממש נדירות
תוכן הטבלה כולל לרב רק מפתח וערך. לדוגמא קוד יישוב ושם יישוב, קוד מוצר ושם מוצר
ב DB נשמר רק המפתח. בכל יישות שמתייחסת לערכי הLUT יישמר ב DB רק המפתח ולא הערך! מאפשר שינוי שם היישוב ללא סריקת כל ה DB
מופיע ב GUI כ List Box. המשתמש יכול רק לבחור ערך
בדרך כלל אין חשיבות לתאריך
הוספת קטגוריות. בטבלאות מעל 15 כניסות יש לשקול הוספת קטגוריות. בטבלת יישובים כדאי גם להוסיף קטגוריה של אזורים או סוג יישוב. בטבלת מוצרים כדאי להוסיף קטגוריה של סוגי מוצרים
יש לשקול הוספת סטאטוס. לעתים לא מעוניינים לבטל פיסית מופע של ערך בטבלה ולכן כדאי לציין את הסטטוס שלו כמבוטל לוגית/לא קיים
הסבר: מה זה Enum
Enumeration
מאפיין עם מספר מוגבל של ערכים אפשריים (מספר ערכים בודד)
למעשה זהו Lut עם מספר קבוע של ערכים
הערכים אינם מתעדכנים לעולם
מאפיינים מסוג זה יכולים להופיע במספר רצוי של תת ישויות
הסטראוטיפ: enum
טיפוס הנתונים: בדרך כלל char
בכל מערכת יש מספר רב של מאפיינים מסוג enum
מאפייני ה enum יכולים להיות משותפים למספר רב של מערכות
דוגמאות אופייניות: מגדר, מצב משפחתי,
הסבר: סטריאוטיפים של מאפיינים - Attributes
ניתן לסווג את המאפינים (שדות) בכל ישות/תת ישות ל 9 קטגוריות שונות של סטראוטיפים
Column- מאפיין רגיל ללא ייחוד, דוגמאות: שם משפחה, תאריך לידה, אחוז ריבית...
PK- מפתח ראשי (Primary Key) לכל ישות/תת ישות חייב להיות מפתח ראשי אחד בלבד. ברב המקרים נבחר מפתח מלאכותי. כדאי לשמור על עקביות בשם המפתח דוגמאות: מזהה לקוח, מזהה עובד, מזהה תלונה, מזהה ספק, מזהה מוצר
FK- מאפיין שמצביע על האב של תת ישות. ברב המקרים יש אב אחד , אבל ייתכנו גם מספר אבות. דוגמא בתת ישות היסטוריה של דרגות העובד יהיה מאפיין בשם מזהה עובד שמצביע על ישות העובד
PFK: מפתח שמורכב ממספר שדות, כאשר כל אחד מהשדות הוא FK
משתמשים בPFK במקרים בהם מעדיף הDBA להשתמש בשרשור של מספר שדות במקום להשתמש במזהה בודד
החסרון: מפתח לא נוח. :היתרון: מבטיח חד ערכיות של צירוף השדות
Lut- מאפיין שמתייחס לישות מסוג Lut. לדוגמא: בישות מוצר המאפיין סוג מוצר מתייחס ל Lut
Enum- מאפיין שמייחס לישות מסוג Enum לדוגמא: מגדר, מצב משפחתי,
Bool - מאפיין בוליאני שיכול רק לקבל ערכים של 0/1 או כן/לא. דוגמאות: האם חבר מועדון, האם שירת בצה"ל, האם בעל דרכון זר
Unique: מאפיין אחד או צירוף של מספר מאפיינים שחייב/ים להיות בעלי ערך ייחודי בכל מסד הנתונים
המאפיין אינו PK (המפתח הראשי מעצם הגדרתו הינו ייחודי). בדרך כלל מדובר במפתחות טבעיים
המאפיין חייב להיות ייחודי או ריק
דוגמאות: מספר אישי בצה"ל: לא ייתכנו שני עובדים בעלי אותו מספר אישי בצה"ל, אבל יתכנו מספר עובדים שאין להם כלל מספר אישי
מספר תעודת זהות של סטודנט: לא ייתכנו שני סטודנטים בעלי מספר תעודת זהות זהה, אבל ייתכנו סטודנטים שאין להם כלל תעודת זהות (סטודנטים מחול)
Null: מאפיין שאינו שדה חובה
רב המאפיינים בתת ישות הם שדות חובה, אבל יש מקרים בהם מבחינה לוגית/משפטית החוק העסקי אינו מחייב שדה חובה.:דוגמאות: שם משפחה קודם, מספר אישי בצה"ל, תאריך סיום משימה בפועל, ארץ עליה.
ניתן לראות כי אוסף המאפינים של ישות ההזמנות להשכרת רכב, מחולק לקבוצות של סטראוטיפים שונים
כל המאפיינים הם חובה למעט שני המאפיינים האחרונים
PK- יש רק אחד
FK- מצביעים לאבות
LUT-קשר לטבלאות פענוח
Enum -קשר לטבלאות עם מספר ערכים מוגבל
bool-מאפיינים לוגיים
Column-מאפיינים ללא ייחוד
FK,null- מאפיינים שהם גם FK אבל הם אינם מאפייני חובה
הסבר: מה זה מפתח היברידי
זהו שדה מפתח טבעי שנראה כנתון בודד, אבל מעשית הוא מורכב ממספר שדות לוגיים
דוגמא 1 : מזהה בינלאומי לספרים-ISBN. המפתח מורכב מ 4 או 5 שדות לוגיים.
דוגמא 2: VIN מספר בינלאומי לזיהוי המנוע של הרכב-
במודל הלוגי מומלץ לבצע כדלקמן
1. להשאיר את המפתח ההיברידי
2. להגדיר מאפיינים נפרדים לכל אחד ממרכיבי השדה ההיברידי
3. לא לבחור את השדה ההיברידי כ PK אלא להעדיף מפתח מלאכותי
הסבר: הגדרת מושג ה - Object Value/Data Type
מאפיין בעל משמעות לוגית מורכבת
זהו מושג שבדרך כלל מתייחסים אליו כמאפיין בודד,
אבל למעשה הוא כולל מספר מרכיבים. במקום לפרט בכל ישות/תת ישות את כל המרכיבים מספיק לציין את שם המושג
לדוגמא במקום לפרק כתובת לגורמים ניתן להגדיר מושג לכתובת בשם Address ובכל תת ישות רלוונטית להפנות ל Address.
להלן מספר דוגמאות למאפיינים כאלו:
מאמר: מחסני, אגמי ומרכולי נתונים
מחבר: ליאור בר און
לפעמים כשאנחנו נתקלים במונחים חדשים הם נשמעים כמו "דברי-פלצנות". כמו איזה משהו שכמה אנשים שעוסקים בנושא המציאו לעצמם - רק בכדי להסתיר את העובדה שאין ממש במה שהם מתעסקים.
זה לפחות מחשבה שלי עוברת בראש לפעמים כשאני שומע מונחים בפעם הראשונה.
אבל הרבה פעמים אני מגלה דיי מהר שאלו מונחים שימושיים, שכמו Patterns, עוזרים לנו לתקשר בצורה פשוטה ומדויקת יותר.
בפוסט זה אני רוצה לדבר על כמה מונחים כאלו, שיכולים להישמע ברגע ראשון כמו מונחים סתמיים - אך בעצם יש מאחוריהם כמה רעיונות חשובים.
מאמר אנגלית : מה זה ETL
מאמר אנגלית: MetaData
מאמר אנגלית: What is MDM
סרטון: What is Jason
סרטון: MDM : Data Management_ What Is Master Data Management