ניהול שינויים במחסן נתונים יש עומק היסטורי הארגון משתנה במשך הזמן מבנה הנתונים במערכות התפעוליות – משתנה לדוגמא: * "חולצה לבנה דגם סילון" יכולה לעבור מקבוצת מוצרים "חולצות עבודה" ל- " חולצות גברים" * סניף "נתניה" יכול לעבור ממחוז "מרכז" למחוז "צפון"

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

ניהול השינויים מתמקדת בטבלאות המימדים ולא בעובדות בעיית ניהול השינויים מתמקדת בטבלאות המימדים הסיבה: טבלת העובדות מייצגת עובדה הקשורה למימדים הנכונים באותה עת

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

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

ניהול ערכים עדכניים בלבד - סניף העובר ממחוז אחד לשני ניהול ערכים עדכניים בלבד - סניף העובר ממחוז אחד לשני

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

יצירת רשומת מימד חדשה מרכז

ניהול רשומות שינויים עם תאריך תוקף 345

SELECT Sum(sale_amount) AS tot_sales FROM sales AS s, products AS p כל מכירות פברואר 97 של פריטים המשויכים לקטגורית "חולצות גברים" (יכלול גם פריט "חולצת לבנה דגם סילון" אפילו שחולצה זו הייתה משויכת פעם לקטגורית "חולצת עבודה") SELECT Sum(sale_amount) AS tot_sales FROM sales AS s, products AS p WHERE (s.s_date >= p.start_date) AND (s.s_date <= p.end_date) AND (p.product_group ="menswear") AND (s.product_id = p.product_id) AND s.s_date >= #1/2/97# ) AND ) s.s_date <= #31/12/97# ) )

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

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

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

טכניקות לניהול סיכומים – ניהול הסיכומים בטבלת העובדות הסיכומים מנוהלים בטבלת העובדות בשורות מיוחדות נניח אנו רוצים לנהל את סך כל המכירות ברמת המימד הגיאוגרפי – סניף, אזור ומחוז אם יש 70 סניפים, 10 אזורים ו- 4 מחוזות נצטרך 84 שורות נוספות בטבלת העובדות לכל שורת סיכום - מפתח חד משמעי יש להוסיף עמודה מיוחדת לטבלת סניפים (טבלת המימד) – רמת הסיכום

מבנה כוכב עם סיכום ברמת סניף, אזור, מחוז

תוכן טבלת עובדות וסניפים עם סיכומים סניפים S1, S2, S3 שייכים לאזור R1 במחוז D1 סניפים S4, S5 שייכים לאזור R2 במחוז D1 מפתח המיקום K6 בטבלת הסניפים מציין שזוהי רמת סיכום עבור סניף S1 מפתח המיקום K7 בטבלת הסניפים מציין שזוהי רמת סיכום עבור סניף S2 טבלת העובדות מציגה בשורה שמפתח המיקום שלה הוא K6 את סך כל המכירות של סניף S1 טבלת העובדות מציגה בשורה שמפתח המיקום שלה הוא K8 את סך כל המכירות של כל הסניפים השייכים לאזור R1

תוכן טבלת עובדות וסניפים עם סיכומים קוד קוד קוד מיקום מיקום

הצגת סך כל המכירות עבור כל אחד משלושת המחוזות: צפון ודרום חסרון השיטה: כל שאילתא צריכה להכיל התייחסות לעמודה המציינת את רמת הסיכום SELECT district_name,sale_amount FROM sales s, branches b WHERE s.mikum_key = b.mikum_key AND s.mikum_key IN (SELECT mikum_key FROM branches WHERE district_name IN (‘North’,’South’) AND level = 3)

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

סכמת פתיתי שלג עם שתי טבלאות סיכומיות – סיכום מכירות עבור האזור ועבור המחוז

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

ע

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

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

ארכיטקטורה של מערכת עם ניווט לטבלאות סיכומים