קביעת נוסחת שמות מתאימה (Naming Conversions)

By | 25 בספטמבר 2009

 

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

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

הכי חשוב לדעתנו בקביעת שם אובייקט הוא שניתן יהיה לשחזרו בעת כתיבת שאילתא למשל מבלי צורך לחפש ברשימת האובייקטים. נושא זה חשוב גם ב- SQL 2008 , למרות מערכת השלמת השמות כיון שאפילו את האות הראשונה של האובייקט יהיה קשה לזכור אם לא נשתמש בתקן שמות אחיד. שדות בתוך הטבלה מהווים אפילו אתגר גדול יותר במידה והגיון קביעתם אינו אחיד. חישבו למשל על חיבור בין שתי טבלאות באמצעות JOIN כאשר באחת רשום CustomerID, CustomerName ובשניה ClientKey, Client.

לסביבת מחסן נתונים אנו מציעים את התקן הבא:

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

 

  1. מומלץ ששמות טבלאות המימד יכלו באותיות dmn וטבלאות העובדות יתחילו ב- fact. באופן זה, יהיה לנו קל יותר לחפש אובייקטים במידה וכן נרצה לאתרם ברשימה.

 

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

 

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

 

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

 

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

 


 

Share

כתיבת תגובה

האימייל לא יוצג באתר.