PracticU

יצירת קשר יחיד-ליחיד
ב-SQL

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

יצירת קשר יחיד-ליחיד ב-SQL
קשר יחיד-ליחיד נדיר יחסית, אבל הוא שימושי כשרוצים להפריד מידע רגיש או נפרד מהטבלה הראשית. ההרצאה מדגימה זאת עם כרטיס אשראי אחד לכל תלמיד.
למה להפריד לטבלה אחרת
1. כמה נתונים בישות אחת: לכרטיס אשראי יש מספר, תוקף ו-CVV, ואולי גם סוג. לא כדאי להעמיס אותם על טבלת התלמידים.
2. ביצועים: ככל שלטבלה יש יותר עמודות היא איטית יותר, ולכן עדיף טבלה עם מעט עמודות.
3. אבטחה: זו הסיבה המרכזית. אם הכרטיסים באותה טבלה, כל מי שניגש לתלמידים רואה אותם. ה-DBA יכול להגדיר הרשאות לכל טבלה בנפרד, למשל רק למחלקת הכספים. את ההרשאות עצמן לא בנו בהרצאה.
בניית הטבלה והקשר
1. מפתח ראשי: בטבלה CreditCards העמודה StudentID מסוג int היא המפתח הראשי, בלי מספור אוטומטי. אין צורך בטבלת association, כי לכל תלמיד כרטיס אחד לכל היותר. תלמיד בלי כרטיס אשראי, למשל מי ששילם בהעברה, פשוט לא מופיע בטבלה.
2. שאר העמודות: מספר כרטיס ב-varchar(16), תוקף ב-varchar(5) בפורמט כמו 04/27, ו-CVV ב-varchar(3). CVV הוא varchar ולא מספר, כי הוא יכול להתחיל באפס. לא מסמנים ב-NULL.
3. הקשר: בדיאגרמה גוררים מ-StudentID בטבלת התלמידים אל StudentID בטבלת הכרטיסים. המרצה שכח בהתחלה להגדיר מפתח ראשי ותיקן זאת. בוחרים Cascade ב-Delete וב-Update, כי כשתלמיד נמחק אין סיבה לשמור את הכרטיס שלו.
4. איך מזהים: הקשר מסומן במפתח משני הצדדים, ולא במפתח מול אינסוף. הניסיון להוסיף כרטיס שני לאותו תלמיד נכשל בגלל המפתח הראשי.
אחרי ההרצאה תוכלו להחליט מתי כדאי להפריד נתונים לטבלה נפרדת בקשר יחיד-ליחיד.
השיעור הבא בקורס: אילוצים ב-SQL

פרקי ההרצאה: יצירת קשר יחיד-ליחיד ב-SQL

  1. 00:00

    סוגי הקשרים וקשר יחיד-ליחיד

  2. 00:57

    הצורך בכרטיס אשראי יחיד

  3. 01:54

    כרטיס אשראי כישות נפרדת

  4. 02:49

    שיקולי אבטחה ומידע רגיש

  5. 03:56

    טבלה נפרדת למידע רגיש

  6. 04:34

    הגדרת המפתח הראשי המשותף

תמלול ההרצאה: יצירת קשר יחיד-ליחיד ב-SQL

הטקסט המלא של הדקות הראשונות בהרצאה «יצירת קשר יחיד-ליחיד ב-SQL» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.

  1. 00:02

    סוגי הקשרים שראינו עד עכשיו היו one to many יחיד לרבים זה בעצם רוב המקרים שיש קשר עבורם וראינו גם many to many כקשר קונספטואלי שבנינו אותו על ידי טבלת association שמחוברת לשתי טבלאות אחרות אין קשר פיזי כזה באמת בדטאבייס אלא רק קשר רעיוני אבל יש עוד סוג קשר והקשר הזה זה one to one בואו נראה למה אנחנו צריכים קשר one-to-one ומה זה.

  2. 00:36

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

  3. 00:52

    והנתונים שאני רוצה לשמור זה נתון שאני רוצה אחד ויחיד לכל תלמיד, כזה בדיוק כמו שלכל תלמיד אני רוצה רק אימייל אחד, זה לא משנה ואם יש לו הרבה אימיילים.

  4. 01:01

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

  5. 01:13

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

  6. 01:24

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

  7. 01:36

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

  8. 01:43

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

  9. 02:01

    לכרטיס אשראי יש מספר כרטיס, יש לו תוקף, זה כבר נתון נוסף, יש לו security number, זה המספר מאחורה או מקדימה, נקרא cvv, security number של הכרטיס.

  10. 02:16

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

  11. 02:28

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

  12. 02:42

    תהיה יותר איטית. טבלה לא אמורה להיות מאוד מאוד גדולה מבחינת כמה עמודות יש לה. אז כמובן 10 או 20 עמודות זה לא כזה הרבה, עדיף לנו מעט יותר עמודות מאשר טבלה עצומה בגודלה.

  13. 02:55

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

  14. 03:16

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

  15. 03:39

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

  16. 03:50

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

  17. 04:11

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

  18. 04:22

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

  19. 04:36

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

  20. 04:52

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

  21. 05:20

    ואליד 2 הוא בעצם ואליד עד תאריך תפוגה, זה יהיה וורצ'אר, ולפי דעתי 5, סוגריים 5, כי אני בעצם

לקורס המלא: קורס SQL ו‑DBA אפליקטיבי

ההרצאה הקודמת: יצירת טבלת קשר רבים-לרבים - ב-SQL

ההרצאה הבאה: אילוצים ב-SQL

הרצאות קשורות מקורסים אחרים

  • אנשי קשר בטלפון
  • LINQ ל- SQL
  • התקנה של SQL
  • בניית אתר אינטרנט אמיתי לחנות חיות - דף צור קשר

קורסים נוספים במסלול

  • קורס NoSQL - MongoDB
  • קורס SSIS
  • קורס BI - ניתוח מסדי נתונים - Qlik Sense
  • קורס Power BI