עיצוב נתונים

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

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

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

חלק ראשון - מדוע עיצוב נתונים הינו דבר חיוני.

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

מאחר ויהיה עליך לעדכן את האפליקציה שלך, אתה רוצה שפעולת עדכון זו תהיה קלה ופשוטה. בעזרת מסדי נתונים שעוצבו נכון ובזהירות, מפתחים חדשים בצוות שלך יוכלו להבין בקלות יתרה את מבנה מסד הנתונים, הטבלאות, העמודות ועוד. לעומת מסד נתונים שלא הושקע בו עיצוב מתאים ויכול לקחת זמן רב רק בכדי להצליח להבין איך בדיוק הוא בנוי. בוא ונגיד ויש לך טבלה אשר עוקבת אחר הוצאות. נוסיף ונאמר שבשביל מחלקת הספירות עליך לדעת לשם מה יועדה כל הוצאה, מחלקת הספירות תוכל לאכסן מידע על מטרת ההוצאות בעזרת שדה קוד_מחלקה אשר יהיה מספר בן 7 ספרות. כעת, אתה תתפתה ליצור עמודה בטבלת ההוצאות שתקרא מספר_מחלקה ותהיה גם היא מספר בן 7 ספרות. אל תתפתה! מפתחים עתידיים אשר יסתכלו על הנתונים בטבלה יראו מספרים כמו 5214390 ולא יהיה להם שום מושג מה המספר אמור להביע!
ומה יקרה כאשר מחלקות יעברו שינויים או שיוספו חדשות?
מעצב נתונים טוב היה יוצר טבלת קודים אשר כוללת שדה שם_מקוצר ו שם_מחלקה בתור עמודת מפתח.

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

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

חלק שני - כיצד ליישם את טכניקות עיצוב הנתונים.

הדרך הכי טובה ליישום עיצוב הנתונים היא פשוט לכתוב על דף למה בדיוק ישמש מסד הנתונים.

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

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

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

חלק שלישי - "נורמאליזציה"

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

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

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

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

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

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

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

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