מתכונת 6 במדעי המחשב - תכנות באינטרנט 899372

מה נדרש: לבחור את התיאור הנכון של ה"לקוח" במודל שרת–לקוח.

רעיון: במודל שרת–לקוח יש שני צדדים:

פתרון – מעבר על האפשרויות:

תשובה: ב.

בדיקה: סדר הפעולות כשגולשים לדף: המשתמש מקליד כתובת ← הדפדפן (הלקוח) שולח בקשה ← השרת מריץ קוד ובונה דף ← השרת שולח את הדף ← הדפדפן מציג אותו. רק אפשרות ב' מתארת את מי ששולח את הבקשה ומציג את התוצאה.

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

מה נדרש – שאילתה שמחזירה רק את עמודת שם החוג, עבור השורות שבהן registered < maxPlaces.

רעיון – SELECT של העמודה courseName, FROM הטבלה Courses, ותנאי WHERE שמשווה בין שתי עמודות באותה שורה: מספר הנרשמים לעומת מספר המקומות המרבי.

פתרון

SELECT courseName
FROM Courses
WHERE registered < maxPlaces;

בדיקה – השאילתה על טבלה קטנה לדוגמה:

התוצאה: שחמט (14 < 20) ו־גיטרה (3 < 8). קרמיקה לא הוחזרה כי היא מלאה (12 = 12 – אין מקום פנוי), וג׳ודו לא הוחזר כי נרשמו אליו יותר מהמקומות.

טעות נפוצה: לכתוב <= – אז גם חוג מלא (מספר הנרשמים שווה למספר המקומות) יוחזר, למרות שאין בו מקום פנוי. אפשר לכתוב את התנאי גם בצורה maxPlaces > registered או maxPlaces - registered > 0.

מה נדרש: שאילתה שמחזירה שתי עמודות (name, city) רק עבור גשרים שמקיימים שני תנאים.

רעיון:

פתרון:

SELECT name, city
FROM Bridges
WHERE length > 1000 AND yearBuilt <= 1950

בדיקה: השאילתה על טבלה לדוגמה (בשאלה אין שורות) עם חמישה גשרים ועוד שלוש שורות גבול. התקבלו: Golden Gate (2737 מ', 1937) – San Francisco, Brooklyn Bridge (1834 מ', 1883) – New York, ושורת הגבול שנבנתה בשנת 1950 בדיוק. לא נבחרו: Tower Bridge (244 מ' – קצר מדי), Oresund (2000 – מאוחר מדי), שורת גבול משנת 1951 ושורת גבול שאורכה 1000 בדיוק.

טעות נפוצה: לכתוב yearBuilt < 1950 (ואז גשר משנת 1950 לא ייבחר), או לחבר את התנאים ב-OR במקום AND.

מה נדרש – להשלים שישה ביטויים בפעולה שבודקת אם sent היא original שבה כל תו הוכפל.

רעיון

פתרון

גם ביטויים שקולים מתקבלים, למשל sent.length != original.length * 2 ב-(1) ו-j += 2 ב-(6).

הפעולה המלאה:

function isDoubled (original, sent)
{
   // במחרוזת שנשלחה חייבים להיות בדיוק פי 2 תווים
   if (sent.length != 2 * original.length)
      return false;

   var j = 0;
   for (var i = 0; i < original.length; i++)
   {
      var c = original.charAt(i);
      // שני התווים בזוג הנוכחי של sent חייבים להיות שווים ל־c
      if (sent.charAt(j) != c || sent.charAt(j + 1) != c) // (4) – התו הראשון בזוג, (5) – התו השני בזוג
         return false;

      // נעבור לזוג הבא
      j = j + 2; // j
   }

   return true;
}

בדיקה

מעקב עבור original = "HI5", sent = "HHII55" (אורכים 3 ו־6, ולכן (1) שקר):

כש-i = 3 התנאי (2) שקר, הלולאה מסתיימת ומוחזר true.

התוצאות:

טעות נפוצה: לוותר על בדיקת האורך (1) – בלעדיה sent עם תווים מיותרים בסוף (למשל "HHII555") הייתה מתקבלת כתקינה, כי הלולאה עוברת רק על תווי original. טעות נוספת: לקדם את j ב־1 במקום ב־2.

מה נדרש – להשלים 8 ביטויים בפונקציה שקוראת ממסד הנתונים את הימים הגשומים, מציגה אותם בטבלת HTML ומדפיסה את מספרם.

רעיון – הסינון נעשה בשאילתה (WHERE), כך שהטבלה שחוזרת מכילה רק ימים גשומים, ומספר השורות שלה הוא בדיוק מספר הימים הגשומים. סדר הפעולות: חיבור ← פקודה עם שאילתה וחיבור ← מתאם ← פתיחת חיבור, Fill לתוך DataTable, סגירה ← לולאה על השורות עם Response.Write.

פתרון

הפונקציה המלאה:

protected void printRainyDays(string connectionString)
{
    SqlConnection connection = new SqlConnection(connectionString);
    string sql = "SELECT Day, Rain FROM Measurements WHERE Rain > 0 ORDER BY Day";
    SqlCommand cmd = new SqlCommand(sql, connection);
    SqlDataAdapter adapter = new SqlDataAdapter(cmd);
    DataTable dt = new DataTable();
    connection.Open();
    adapter.Fill(dt);
    connection.Close();
    Response.Write("<h2>ימים גשומים</h2>");
    Response.Write("<table border='1'><tr><th>תאריך</th><th>כמות גשם (מ\"מ)</th></tr>");
    foreach (DataRow r in dt.Rows)
    {
        Response.Write("<tr><td>" + r["Day"] + "</td><td>" + r["Rain"] + "</td></tr>");
    }
    Response.Write("</table>");
    Response.Write("מספר הימים הגשומים: " + dt.Rows.Count);
}

בדיקה – טבלה עם 7 ימי מדידה (3 מהם בלי גשם) והפונקציה המלאה ב-C#. נשלחה השאילתה SELECT Day, Rain FROM Measurements WHERE Rain > 0 ORDER BY Day והפלט היה בדיוק כמו בדוגמה: ארבע שורות (2027-01-02 – 12, 2027-01-03 – 31, 2027-01-05 – 4, 2027-01-07 – 22) ואחריהן "מספר הימים הגשומים: 4".

טעות נפוצה: לכתוב ב-(8) dt.Rows (אוסף, לא מספר) או לספור את כל הימים בטבלה במקום את הימים שהשאילתה החזירה; וב-(6) לכתוב dt במקום dt.Rows.

מה נדרש – פעולה בצד השרת שקוראת שני משתני Session, שומרת משתנה Session חדש ומפנה (Response.Redirect) לאחד משלושה דפים.

רעיון – קודם בודקים אם המשתמש מחובר: אם Session["userName"] הוא null – login.aspx. אחרת קוראים את הדירוג – ב-Session הערכים נשמרים מטיפוס object, ולכן צריך המרה (int). לפי הדירוג שומרים את שם הקבוצה ב-Session["group"] ורק אחר כך מפנים, כי Response.Redirect מסיים את הטיפול בבקשה – שורה שנכתבת אחריו לא תתבצע.

פתרון

protected void enterTournament()
{
    if (Session["userName"] == null)
    {
        Response.Redirect("login.aspx");
    }
    else
    {
        int rating = (int)Session["rating"];
        if (rating >= 1800)
        {
            Session["group"] = "masters";
            Response.Redirect("masters.aspx");
        }
        else
        {
            Session["group"] = "open";
            Response.Redirect("open.aspx");
        }
    }
}

בדיקה:

טעות נפוצה: לכתוב if (Session["rating"] >= 1800) בלי המרה – שגיאת הידור, כי Session מחזיר object; לכתוב rating > 1800 (שחקן עם דירוג 1800 בדיוק צריך להגיע ל-masters); ולשמור את Session["group"] אחרי Response.Redirect – השמירה לא תתבצע.

מה נדרש – מספר (כמות) המדידות, לא המדידות עצמן.

רעיון – COUNT(*) סופרת את השורות שעברו את הסינון. שני התנאים חייבים להתקיים יחד ⇐ AND. "25 או יותר" ⇐ >= 25.

פתרון

SELECT COUNT(*)
FROM WeatherLog
WHERE rainMm = 0 AND maxTemp >= 25;

בדיקה – בטבלת הדוגמה: Haifa (0 מ"מ, 27) – כן; Eilat (0, 38) – כן; Safed (12 מ"מ) – לא; Tel Aviv (4 מ"מ) – לא; Safed (20 מ"מ) – לא. התוצאה: 2. בטבלה מורחבת שהוספנו לה מדידה בלי גשם עם maxTemp = 25 בדיוק, היא נספרה (3).

טעות נפוצה: לכתוב maxTemp > 25 – אז מדידה של 25 בדיוק לא תיספר.

מה נדרש – ערך אחד – המינימום של העמודה minTemp.

רעיון – הפונקציה המצרפת MIN מחזירה את הערך הקטן ביותר בעמודה, בלי צורך ב-WHERE.

פתרון

SELECT MIN(minTemp)
FROM WeatherLog;

בדיקה – הערכים בעמודה הם 18, 24, 9, 19, 7 ⇐ השאילתה מחזירה 7.

טעות נפוצה: לכתוב SELECT minTemp FROM WeatherLog WHERE minTemp = MIN(minTemp) – אי אפשר להשתמש בפונקציה מצרפת בתוך WHERE.

מה נדרש – שתי עמודות (city, dayId) של השורות המתאימות.

רעיון – ב-WHERE אפשר לחשב ביטוי מתוך שתי עמודות של אותה שורה: maxTemp - minTemp, ולהשוות אותו ל־10. "גדול מ־10" ⇐ > 10.

פתרון

SELECT city, dayId
FROM WeatherLog
WHERE maxTemp - minTemp > 10;

בדיקה – ההפרשים בטבלת הדוגמה: 9, 14, 7, 6, 6 ⇐ רק Eilat (מדידה 2). השאילתה מחזירה Eilat | 2. בטבלה מורחבת עם מדידות שבהן ההפרש הוא 10 בדיוק – הן לא הוחזרו, כנדרש.

טעות נפוצה: לכתוב minTemp - maxTemp > 10 (ההפרש יוצא שלילי ושום שורה לא תוחזר).

מה נדרש – ערך אחד – הממוצע של העמודה rainMm.

רעיון – הפונקציה המצרפת AVG מחשבת סכום חלקי מספר השורות. הערה: ב-SQL Server, כשהעמודה מטיפוס מספר שלם, גם הממוצע מחושב כמספר שלם (7); כדי לקבל ממוצע עם שבר כותבים AVG(rainMm * 1.0). ב-Access מתקבל 7.2.

פתרון

SELECT AVG(rainMm)
FROM WeatherLog;

בדיקה – (0 + 0 + 12 + 4 + 20) / 5 = 36 / 5 = 7.2.

טעות נפוצה: לכתוב SUM(rainMm) (מחזיר 36, הסכום ולא הממוצע).

מה נדרש – העמודה dayId של המדידות שבהן הרוח מחוץ לטווח 10–40.

רעיון – מספר לא יכול להיות גם קטן מ־10 וגם גדול מ־40, ולכן מחברים את שני התנאים ב-OR.

פתרון

SELECT dayId
FROM WeatherLog
WHERE windKmh < 10 OR windKmh > 40;

בדיקה – מהירויות הרוח: 25, 45, 30, 8, 50 ⇐ מתאימות 45 (מדידה 2), 8 (מדידה 4), 50 (מדידה 5). השאילתה מחזירה 2, 4, 5.

טעות נפוצה: לחבר ב-AND – אז לא תוחזר אף שורה.

מה נדרש – שמות ערים, כל שם פעם אחת בלבד.

רעיון – LIKE '%f%' – התו % מחליף רצף כלשהו של תווים (גם ריק), כך שהאות f יכולה להופיע בכל מקום בשם. DISTINCT מסיר כפילויות (Safed מופיעה פעמיים בטבלה). ב-Access תו הכללי הוא *: LIKE '*f*'.

פתרון

SELECT DISTINCT city
FROM WeatherLog
WHERE city LIKE '%f%';

בדיקה – Haifa – כן; Eilat – לא; Safed (פעמיים) – כן; Tel Aviv – לא. השאילתה מחזירה Haifa, Safed (בלי DISTINCT היינו מקבלים את Safed פעמיים).

טעות נפוצה: לכתוב LIKE 'f' בלי תווי % – זה מחפש שם שהוא בדיוק "f".

מה נדרש: להשלים חמישה ביטויים בקוד שמוכר כרטיסים ממלאי משותף ומגביל כל תלמיד ל-2 כרטיסים.

רעיון:

פתרון:

הקוד המלא:

protected void Page_Load (object sender, EventArgs e)
{
    if (Session["bought"] == null) // איתחול
        Session["bought"] = 0;
    if ((int)Session["bought"] == 2) // כל תלמיד רשאי לקנות עד 2 כרטיסים
        Response.Write("הגעת למספר הכרטיסים המרבי");
    else
    {
        Application.Lock();
        if (Application["left"] == null) // איתחול המלאי
            Application["left"] = 100;
        if ((int)Application["left"] > 0)
        {
            Application["left"] = (int)Application["left"] - 1;
            Session["bought"] = (int)Session["bought"] + 1;
            Response.Write("הכרטיס נוסף להזמנה שלך");
        }
        else
            Response.Write("הכרטיסים אזלו");
        Application.UnLock();
    }
}

בדיקה: Session נפרד לכל תלמיד ו-Application משותף:

טעות נפוצה: לכתוב ב-(1) 3 – אז תלמיד יוכל לקנות 3 כרטיסים. טעות נוספת: לכתוב ב-(4) Application["left"] > 0 בלי המרה – לא עובר הידור.

מה נדרש: להסביר מה מייצג המשתנה Application["left"].

רעיון: משתנה Application נשמר בשרת אחד לכל האתר ומשותף לכל המשתמשים.

פתרון: Application["left"] הוא מלאי הכרטיסים שנשארו למכירה – אחד לכל האתר. בטעינה הראשונה באתר (null) הוא מאותחל ל-100; בכל קנייה מוצלחת של תלמיד כלשהו הוא קטן ב-1, וכשהוא 0 מוצגת לכל התלמידים ההודעה "הכרטיסים אזלו". מאחר שתלמידים רבים קונים במקביל, הבדיקה והעדכון שלו נעשים בין Application.Lock() ל-Application.UnLock(), כדי שלא יימכרו יותר מ-100 כרטיסים.

בדיקה: אחרי שתלמיד א קנה 2 ותלמיד ב קנה 1, הערך הוא 97 – והתלמיד הבא רואה את אותו ערך.

מה נדרש: להסביר מה מייצג המשתנה Session["bought"].

רעיון: משתנה Session נשמר בשרת בנפרד לכל משתמש, ולכן מתאים למידע אישי שנשמר בין טעינות של הדף.

פתרון: Session["bought"] הוא מספר הכרטיסים שהתלמיד הנוכחי כבר קנה. בטעינה הראשונה שלו הוא מאותחל ל-0; בכל קנייה מוצלחת הוא גדל ב-1; לפני כל ניסיון קנייה בודקים אותו, וכשהגיע ל-2 מוצגת ההודעה "הגעת למספר הכרטיסים המרבי" ולא מוכרים לו עוד. כך כל תלמיד מוגבל ל-2 כרטיסים בלי להשפיע על תלמידים אחרים.

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

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

רעיון:

פתרון:

הפונקציה המלאה:

protected void ShowTrips(string connectionString, string station)
{
    string res = "";
    DataSet ds = new DataSet();
    SqlConnection conn = new SqlConnection(connectionString);
    SqlCommand cmd = new SqlCommand();
    cmd.CommandText = "SELECT tripNum, toStation, departure FROM [dbo].[Trips] WHERE fromStation = '" + station + "' AND freeSeats > 0";
    cmd.Connection = conn;
    conn.Open();
    SqlDataAdapter adapter = new SqlDataAdapter(cmd);
    adapter.Fill(ds);
    conn.Close();
    if (ds.Tables[0].Rows.Count == 0)
        res = "אין נסיעות עם מקומות פנויים מתחנה זו";
    else
    {
        res += "<table><tr><th>מספר נסיעה</th><th>יעד</th><th>שעת יציאה</th></tr>";
        foreach (DataRow dr in ds.Tables[0].Rows)
        {
            res += "<tr><td>" + dr["tripNum"] + "</td><td>" + dr["toStation"] + "</td>";
            res += "<td>" + dr["departure"] + "</td></tr>";
        }
        res += "</table>";
    }
    Response.Write(res);
}

בדיקה: הפונקציה על טבלת הדוגמה:

הפלט עבור עכו:

<table><tr><th>מספר נסיעה</th><th>יעד</th><th>שעת יציאה</th></tr><tr><td>311</td><td>נהריה</td><td>07:15</td></tr><tr><td>315</td><td>בית שאן</td><td>09:30</td></tr></table>

טעות נפוצה: להשלים ב-(2) "station" (במירכאות) – אז השאילתה תחפש תחנה ששמה המילה station ולא את הערך שבמשתנה. טעות נוספת: ב-(3) >= – אז יוצגו גם נסיעות מלאות.