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

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

3. מהם נתונים, היכן וכיצד הם מאוחסנים ?
נתונים הם כל מידע בעל ערך שאותו נירצה לשמור ולעיין בו שוב, למשל המצגת הזו.
אם כתבנו מכתב בעזרת מעבד תמלילים ומעבר להדפסתו נירצה לשמור את תוכנו.
רובנו יודעים מהו קובץ – אוסף של נתונים. זוהי ישות שניתן לשמור על הדיסק הקשיח, או לשלוח בדואר אלקטרוני.
חלקנו גם יודעים שאפשר לסדר את הדיסק הקשיח בעזרת תיקיות ובהן קבצים , בצורה הירארכית, למשל תיקיה ראשית בשם: ׳מכתבים׳ ותחתיה 2 תיקיות משנה: ׳מכתבים לחברים׳, ו ׳מכתבים לרשויות׳.
אם למשל היינו רוצים לשמור בקובץ רשימה של מסעדות ועבור כל מסעדה תיאור של מחיר ממוצע וציון שנתנו לה – מה השוני בין קובץ כזה לקובץ שהוא מכתב?
כדי להבין את ההבדל, תארו לכם שכל ביקור במסעדה היינו מתעדים בקובץ הנ״ל ואחרי שנה היו לנו 200 מסעדות – איך היינו מוצאים את המסעדה בעלת הציון הגבוה ביותר?

4. מיון קבצים ועידכונם
מה אם היתה לנו רשימה של 2000 מסעדות – אולי היה כדאי למיינם לפי ציון?
אולי במקום קובץ בפורמט חופשי כמו מכתב, היה כדאי לשמור את הרשימה כקובץ אקסל? – הרעיון שכל שורה תהיה לה משמעות בפני עצמה – רשומה.
נרחיב את הרעיון – נניח שאנחנו אחראים על 1000 עובדים ומחזיקים קובץ אקסל עם נתוני עובד בכל שורה, ממוין על פי שם משפחה ושם פרטי. נירצה לאתר את אלה עם טלפון סלולארי עם קידומות 050 ו-052.
אפשר כמובן לעשות חיפוש, אבל איך נשלוף את כל הרשומות לקובץ ניפרד?
ישנם פיתרונות, למשל מיון על פי טלפון, אך הם ארוכים ומסובכים.
אם במקום 1000 עובדים היה זה בנק עם 2 מיליון לקוחות?
אחת המסקנות היא שכמויות עצומות של מידע הופכות כל עיסוק איתו לקשה.

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

6. בסיס נתונים הירארכי
דוגמה: IMS כל מלבן ניקרא סגמנט. הנה דוגמה של לקוח הבנק.
לכל לקוח יכולים להיות מספר חשבונות עו״ש ו/או חסכון.
לכל חשבון יכולות להיות תנועות זיכוי וחיוב - כמה שנירצה.
כלומר, לכל לקוח סגמט שורש יחיד, וסגמנטים ׳ילדים׳ ככל שניצטרך.
אם היינו ׳משטחים׳ את המבנה, ומכינים רשומה שתוכל להכיל את כל נתוני הלקוח – זו הייתה יכולה להיות רשומה ארוכה מאד.

7. IMS
ההרשאת של גישה לנתונים הן ברמת הסגמנט – לכן ניתן לתת גישה לחשבון העו״ש ולא לחשבון החיסכון, למשל.
הסגמנטים השונים מקושרים בעזרת ׳מצביעים׳ פנימיים (כתובות) ולכן הגישה אליהם מהירה מאד.
ניתן גם לבחור שדות שרוצים בכל סגמנט שישמשו כאינדקס ולשלוף נתונים על פי מיון שרוצים.
אינדקס הוא בעצם קובץ עזר שכל כניסה בו מצביעה על רשומה – כמו בספר.
אחד החסרונות של בסיס זה, היא חוסר גמישות לאחר הקמת המערכת. לשנות סגמנטים זו משימה לא קלה (יש צורך בשינוי תוכניות).
זה אומר שצריך לתכנן היטב את השימושים העתידיים, דבר שהופך לקשה יותר ויותר.

8. המודל היחסי הצורך בבסיס נתונים שיהיה גמיש לשינויים הלך וגבר.
התפתח גם צורך ל ׳שפת שליפה׳ שתהיה פשוטה וקלה לתיפעול על ידי משתמשים שאינם אשפי תכנות.
בשנות השבעים של המאה הקודמת התפתח מודל איחסון נתונים שניקרא ׳יחסי׳.
מדענים של חברת IBM , אנשים כמו: Dr. Ted וכן CODD ו- DATE הציגו אפשרות לאיחסון נתונים במערך טבלאות מקושרות לוגית.
בשנת 1974 הוצגה לראשונה שפת: SQL או בשמה המלא: Structured Query Language
שפה זו הייתה קלה ללימוד, אם כי השימוש בה בצורה מיטבית עדיין דרש מיומנות (אחרת הקורס הזה לא היה נחוץ)

9. הרעיון
המודל היחסי דומה מעט לשימוש בטבלאות של אקסל (למעשה אקסל התפתח מאוחר יותר).
הנתונים יהיו מאורגנים כשורות ועמודות בטבלה, ובנוסף, יהיה קשר לוגי בין הטבלאות השונות.
מערך כזה של טבלאות והקשרים ביניהם יהיה בסיס הנתונים.
לפני שניגע במהות הבסיס היחסי, מעט היסטוריה.
ב-1978 הוצגה מערכת שמבוססת על המודל היחסי על ידי CODD בשם:System/R – האות R נבעה מהשם באנגלית: Relational.
חברת IBM הציגה בשנת 1983 את בסיס הנתונים שניקרא: DB2 (השם DB היה תפוס)
ב-1986 הוצג בסיס יחסי נוסף ע״י חברת Relational Software שהפכה ל-Oracle

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

11. ERD (Entity Relationship Diagram)

12. מהות הקשרים בין הטבלאות
כפי שראיתם בשקף הקודם, ישנם קוים המחברים בין הטבלאות.
למשל, מדריך וקורס. מטבע הדברים, מדריך יכול להדריך קורס אחד או יותר. לכן מהצד של טבלת המדריך ישנם שני קוים אנכים ומצד הקורס 3 ׳רגליים׳ וקו אנכי.
צורת הסימון הזו היא רק אחת האפשרויות בהן משתמשים.
נסו לנחש מה היחס בין סטודנט למושב בכיתה, בין פרופסור לקבוצה? התשובה בשקף הבא.
בין קורס למושב? לא כל טבלה חייבת להיות מקושרת לכל טבלה אחרת.
הקשרים האלה בין הטבלאות אינם קשרים פיזיים (כמו המצביעים של IMS), אלא קשרים לוגיים על ידי מידע משותף.
שימו לב למשל שבין קורס לכיתה ישנו שדה משותף: course_name – זה אומר שקורס בעל שם מסוים מתנהל בכיתה מסוימת. בהמשך נדון יותר בקשרים אלה. הם לב ליבו של בסיס הנתונים היחסי.

13. Entity Relational Model
לעיתים גם תראו את הקיצור: ERM, ה- M מהמילה: Model.
אם שמתם לב, הקשר בין פרופסור לקבוצה (section), הוא אחד לאפס או יותר, מסומן ע״י העיגול בתוספת ה=3 רגליים. זה מציין שיתכן שפרופסור אינו מלמד אף קבוצה, אולם הוא גם יכול ללמד קבוצות רבות.
לעומת זאת ראינו שהיחס בין מושב לסטודנט הוא בהכרח אחד לאחד. זה אומר שעבור כל סטודנט חייב להיות מושב אחד.
אין לנו בדוגמה שראינו יחס של רבים לרבים, אולם זו גם אפשרות. אם נניח שבסיס הנתונים שלנו מכיל טבלה של סופרים וטבלה של ספרים.
לכל סופר יתכנו מספר ספרים מצד אחד, ומצד שני לכל ספר, יתכנו מספר מחברים.
דוגמה נוספת: נניח שעלינו לבנות מערכת של הזמנות עבור חנות מוצרי חשמל.

14. ORDER Detail ORDER Header מערכת הזמנות
בתיכנון של בסיס הנתונים, קבענו שתהיה טבלה שבה יהיו נתוני ההזמנה הכלליים, כמו שם הלקוח, כתובתו, מספר כרטיס האשראי וכו׳.
בנוסף, תהיה טבלה שתכיל את פירוט ההזמנה. נניח שהלקוח רוצה 2 טלויזיות ,מכונת כביסה ומקרר.
מה יהיה הקשר הלוגי בין הטבלאות?
ORDER Detail
ORDER Header

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

16. מודלים נוספים
עבור ידע כללי אזכיר שני מודלים נוספים של איחסון נתונים:
מודל עצמים יחסי – Object Relational Data Model – זהו מודל שמשלב בין הטבלאות היחסיות שעליהן דיברנו , ותכנות מונחה עצמים. על פי מודל זה ישנו קשר הדוק בין עצמים לטבלאות, כלומר הבסיס הוא עדיין טבלאות, אבל צורת הגישה לנתונים קצת שונה.
המודל השני הוא XML – Extensible Markup Language –נראה בעזרת דוגמה: (הודעה ממישהו למישהו אחר תוך שימוש בסמנים שמסבירים את המשמעות של התוכן שנימצא ביניהם. גם כאן יש את עיקרון ההירארכיה.
<note> <to>Tove</to> <from>Jani</from>  <heading>Reminder</heading> <body>Don't forget me this weekend!</body> </note>
זוהי דרך לאיחסון נתונים, שהפכה מקובלת ב-20 שנה אחרונות, עבור ישומים שונים.

17. הסיבה למענה התכנסנו
אנחנו עומדים ללמוד שפה חדשה. שפה שניקראת: SQL או בשמה המלא: Structured Query Language
השפה תשמש לנו גישה לבסיס הנתונים, גם לבנות אותו וגם לעבדו.
אל דאגה, זה לא כמו ללמוד סינית או אפילו צרפתית. זה גם קל יותר משפת תכנות.
השפה אמנם קלה ללימוד מבחינת אוצר המילים שלה, אבל היא בעלת כוח רב עבור עיבודים שונים ומשונים של הנתונים.
מטרת השפה הייתה ליצור אמצעי שבעזרתו גם מי שאינו מומחה לתכנות, יוכל לגשת לנתונים שונים מצד אחד, ומצד שני ליצור כלי שהוא אד-הוק, כלומר יכול לתת מענה לצורך חדש שלא היה קיים בזמן תיכנון המערכת.
נניח שאנו מכירים את השפה וכתבנו איזו בקשה לנתונים (שאילתה בעגה המקצועית) – איך נבצע אותה? איך יתקבלו הנתונים החוזרים?

18. מה זו שאילתה?
המילה מעט מטעה – באנגלית Query, מעלה מחשבה של בקשת נתונים.
אמנם ברוב המקרים זו כן בקשה של נתונים.
כדי ׳להקים׳ או לבנות את בסיס הנתונים, נשתמש גם ב ׳משפט׳ SQL.
יש מצבים שבהם למשל נירצה למחוק שורה מטבלה, או לעדכן שורה ואז מכנים זאת: שאילתת עידכון, או שאילתת מחיקה.
באופן כללי אפשר לחלק את השפה SQL לשני חלקים: חלק אחד שעוסק בבניה/הריסה או כללית במבנה של בסיס הנתונים והחלק השני הוא עיבוד הנתונים כגון: שליפה, עידכון או מחיקה.
על החלק הראשון לא נתעכב יותר מידי, זה בד״כ מבוצע על ידי קבוצת ה- DBA באירגון, אבל בכל זאת נקים לעצמנו בסיסי נתונים ונילמד איך ליצור/להרוס טבלאות.
החלק השני, עיבוד הנתונים, יהיה הליבה של הלימודים שלנו.

19. פקודות SQL מילות המפתח העיקריות של השפה הן:
SELECT CREATE DELETE DROP UPDATE REPLACE GRANT REVOKE UPDATE INSERT
כאמור, אנחנו נתמקד בפקודות: SELECT UPDATE DELETE INSERT
אפילו מתוך אלה מה שיעניין אותנו יותר מכולן היא הפקודה: SELECT.
עכשיו תוכלו לשאול ובצדק, מדוע צריכים עוד 3 ימי עיון עבור פקודה אחת?
התשובה היא שכדי להבין את הצורה המיטבית להשתמש ב- select כדי לשלוף את מה שרוצים, צריכים להבין קצת יותר גם את מבנה בסיס הנתונים וגם את כל הדרכים שבהן פקודה זו יכולה להינתן.
כאשר נגיע ליום השלישי או הרביעי של הקורס, ותראו אפשרויות רבות ומגוונות לשלוף נתונים, תבינו מדוע גם קורס זה לא יהפוך אתכם למומחים גדולים בתחום – תירגול חוזר ונישנה כן יכול לעשות זאת.

20. מבנה בסיס הנתונים אנו רואים כאן דוגמה לטבלה של עובדים בחברה:
| ID | NAME | AGE | ADDRESS | SALARY | | 1 | Ramesh | | Ahmedabad | | | 2 | Khilan | | Delhi | | | 3 | kaushik | | Kota | |
אחד הדברים החשובים בתיכנון טבלאות, זו בחירה נכונה של עמודה (או עמודות) עבור מפתח ראשי, או באנגלית: Primary key.
מה ניראה לכם כמועמד טבעי למפתח ראשי? (מפתח ראשי אמור להיות יחודי – כלומר בכל שורה הוא שונה מכל יתר השורות.
על מנת לראות דוגמה של טבלה עם שני שדות, שיחד משמשים כמפתח ראש, ניזכר שוב בטבלת ההזמנות משקף 14, או ליתר דיוק, לטבלת פירוט מוצרי ההזמנה.
Order_number Line_number Item_name Quantity
Microwave Iron
מה יהיה המפתח הייחודי של טבלה זו?

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

22. דוגמה להרמוניה נתבונן בצמד הטבלאות הבאות: הזמנות ולקוחות:
Order_table Customer_table
order_id | item_name | quantity | customer_id |customer_id | credit_card
———--—+————--—-+— —--——+—————— ————-—--+——————-—
 Mac laptop | 
 Flashlight | 
 Pencil |
בטבלת ההזמנות יש לנו מפתח ראשי בשם: order_id מספר יחודי של זיהוי הזמנה
בטבלת הלקוחות יש לנו מפתח ראשי שהוא מספר זיהוי הלקוח: customer_id
 שימו לב שגם בטבלת ההזמנות ישנו שדה בשם: customer_id. על פי התיכנון של בסיס נתונים זה, השדה הזה הוגדר בטבלת ההזמנות כמפתח זר שמתייחס למפתח הראשי של טבלת הלקוחות.
שם השדה: customer_id אינו חייב להיות אותו שם בין הטבלאות , למרות שבהרבה מקרים בוחרים אותו שם. כאשר נגדיר בעצמנו טבלאות, ניראה כיצד יוצרים את הקשר הגורדי הזה בין הטבלאות.

23. דוגמה לשימוש בקשר שבין הזמנות ללקוחות
בואו ניקח בעיה ׳מהחיים׳. נניח שנפלה טעות בהזמנה מספר ובמקום מחשבי מק, צויינו 2 מחשבים, אבל הלקוח חוייב עבור שלושה.
אין לנו מחשב שלישי במלאי כרגע ולכן נירצה לזכות את הלקוח,כל עוד הוא לא מקבל את כל ההזמנה.
אפשרות אחת זהליצור שוב קשר עם הלקוח, ולבקש ממנו שוב את כרטיס האשראי כדי לזכותו, ואז לעצבן אותו עד מוות, כי לא רק שלא שולחים לו מחשבים גם מחייבים אותו ב-3? זו לא אפשרות שתביא לקוחות חוזרים.
בשביל מה יש לנו בסיס נתונים? מדוע שלא ניקח את מספר זיהוי הלקוח – במקרה הנ״ל, ואיתו ניגש לטבלת הלקוחות, ומשם נישלוף את מספר כרטיס האשראי שהוא: