נתונים משויכים בדרך כלל לתכנות ובעולם המידע המודרני מוצגים בשלוש גרסאות שוות מבחינה לוגית: נתונים המתוארים ומשמשים בתוכנה בשפת תכנות; נתונים במערכות מסדי נתונים; נתונים במערכות מידע מבוזרות. התכנות המודרני העניק חופש יחסי רק לגרסה הראשונה של פורמליזציה של מידע. שתי האפשרויות השניות הן צורות אמינות פחות או יותר של מתן מידע וקשרים בין מרכיביו.
נתונים בעבר ובהווה
העמדה הבסיסית של שפות התכנות היא התיאור המדויק של נתונים ואלגוריתמים. מחשבים אינם "מציגים" שום סיכוי לאי ודאות: יש משהו שצריך לפעול עליו, ויש פקודה שמבצעת את הפעולה הזו.
המושג המודרני מבוסס על בסיס הרבה יותר גבוה: יש נתון, ומה בדיוק הוא יהיה נקבע במקום השימוש בו. בכל מקרה, בזמן השימוש, הנתונים נבדקים אוטומטית ומומרים לסוג הנכון.מתכנת מודרני אינו מחויב לדאוג לתיאורו המקדים ולשמירה על תאימות סוגים באלגוריתם.
תהליך מעבר:
- מתוך נתונים מוקלדים ותיאור החובה שלהם לפני השימוש;
- לנתונים לא מודפסים וחופש מכל התחייבות לתאר ולהשתמש בהם.
למעשה, אנו יכולים לזהות את ההקלה היחסית של דרישות הפורמליזציה - היא זמינה רק בסביבה של כלי תכנות מודרניים. בזמן הריצה, הסוג של כל נתון קבוע ורצף הפקודות מוגדר היטב.
סוגים ודוגמנות
מתמטיקה ופיזיקה, מסחר וייצור, כלכלה ותחומים אחרים שבהם משתמשים במספרים, תמיד פעלו עם נתונים ולא ייחסו כל חשיבות למושג הטיפוס. העובדה שמספרים יכולים להיות שלמים או שברים לא ממש משנה.
כל נוסחה ספציפית או פעולה ספציפית יכולה לתת מספר שלם, שבר אינסופי, מספר ממשי או מרוכב. עד עכשיו, ישנם פלאי הנפש כמו לאין סוף קטן וגדול לאין שיעור. יתרה מכך, לנסים האלה יש אפילו תכונות.
עדיין אין חופש בתכנות. הכל חייב להיות רשמי בקפדנות. הרעיון של נתונים הוא, קודם כל, סוג:
- integer;
- boolean;
- char;
- מחרוזת וכן הלאה.
שמות של סוגים עשויים להיות שונים בשפות תכנות שונות, אבל תמיד יש מספר שלם או ממשי, ערך בוליאני, סמל,קַו. עדיין נותרו שרידים ורעיונות ספציפיים: מספר שלם ללא סימן, קוד, בייט, מילה, מילה כפולה, מחרוזת באורך קבוע.
למושג נתונים במערכת נתונים אין חופש. שפת SQL - "בינלאומית" (יש דיאלקט לכל מסד נתונים מודרני) - אינה סובלת אי דיוקים לא רק בנתונים, אלא גם בשאילתות sql. טעות בבקשה היא ערובה להעדר תוצאה. אין צורך לדבר על הפרות של תיאורים בכלל.
מודל תהליכי מידע וייצוג נתונים הוא הדרך הבטוחה היחידה לבנות מבנה שיכול להתפתח ולהסתגל לתנאים משתנים.
Dynamics of original
מידע טבעי הוא שינוי מתמשך. לתת תיאור ותפיסה פורמלית של מודל נתונים בתחום ספציפי פירושו לפתור שלוש בעיות:
- להגדיר אילו נתונים יש כאן;
- פורמל את היחסים ביניהם;
- תאר תהליכים לשינוי נתונים וקשרים.
דוגמה למערך נתונים של אלגוריתם פשוט ב-JavaScript - עותק מצומצם של המודל אפילו של מערכת ניהול מסד הנתונים המוצקה ביותר.
רק שבמקרה השני, מומחים ומומחים, כשמעצבים מבני נתונים, טבלאות וקשרים, בדרך כלל לא רואים (ממש קשה לכסות כמות גדולה של מידע טבעי) את המהות של הדברים, ו מתקבל קבוצה מסורבלת ולא מפותחת של ערימות נתונים, בעוד שבאזור הנושא מידע מקור מסתובב בחופשיות ובקלות.
סטטיאפשרי
זה נוהג נפוץ ב-JavaScript לכלול קוד המצורף לדף ופונקציות שהוקצו לאירועים בתגי עמוד. כך או כך, תגי עמוד מגדירים את הנתונים שמשאב אינטרנט נתון מקבל, משנה או יוצר.
אם אתה מרכז את קוד המטפל שלך בזהירות רבה באירועי אלמנט, ולא בקוד העמוד בכללותו, זו הדרך הטובה ביותר לצאת. באופן אידיאלי, כאשר הקוד אינו מציג נתונים חדשים או אינו מתקן את הנתונים הזמינים, אלא מתמקד במה בדיוק יש לו ברגע מסוים בזמן.
למעשה, אם אתה מגדיר את המושג "נתונים" כתיאור מינימלי סטטי של מידע המקור ועוקב אחריו, אז זה אומר שיש לך סיכוי להצליח.
בהתייחס למאגרי מידע, הדברים הרבה יותר מסובכים. כל קוד JavaScript "מספק" לדף פונקציונליות. כל מסד נתונים הוא אוסף של טבלאות, קשרים ביניהן, נהלים מאוחסנים, שאילתות ופונקציונליות זמינות מבחוץ.
סטטי היא הבעיה של כל אלגוריתם. התפיסה המודרנית של נתונים היא סטטית: מספר, מחרוזת, תו וכן הלאה. בעיבוד או בכתיבה לטבלת מסד נתונים, הכל מתברר בצורה חלקה. אבל מתי המקור מקבל מימד או משמעות אחרת? אפשרות ראשונה: שנה את השלט, אבל חיבורים ובקשות עלולים להופיע מיד.
סטטיקה ואובייקטים
הגדרת המושג "נתונים" כאובייקט משנה את המצב באופן דרמטי. לאובייקט יש מבנה משלו. כאן אתה יכול להשתמש בכל תיאור של כל משתנים. תפקיד לא ישחק. לאובייקט יש שיטות שבאמצעותן נתונים זמינים. מאז הכלבשימוש בתחום התכנות, כלומר שלוש שיטות בסיסיות: קריאה, כתיבה, שינוי. אתה יכול להוסיף עוד כדי להשוות, לחפש, לשכפל וכו'.
אזור הנושא כופה מגוון של מאפיינים על כל נתון. כך מתברר שמושג הנתונים הופך למעין תיאור שניתן לשנות באופן דינמי. סטטי בתוך אובייקט נותן דינמיקה מחוצה לו.
שינוי השילוב של מתארים סטטיים בתוך אובייקט, אינך צריך לדאוג לגבי הדינמיקה של היחסים שלו עם אובייקטים אחרים.
תכנות והצגת נתונים
מה זה נתונים? התודעה הציבורית כבר רגילה לטכנולוגיית מידע, עובדת בעננים ויש לה קונטיינרים במרחבים וירטואליים. כעת, לא רק מתכנתים ומשתמשים מקצועיים, אלא גם אנשים רגילים מוכשרים בענייני מידע ושימוש בו.
אבל מה זה תכנות? עד היום נותנת דעת הקהל את ההגדרה הבאה למושג זה ולמושגיו:
- מידע ונתונים הם המושגים הבסיסיים המשמשים במדעי המחשב.
- נתונים הם דרך מסוימת שמתקבלת ומתעדת תצפיות ביחס למציאות הסובבת.
- הם פשוטים ומורכבים (מבנים), ראשוניים ומשניים.
- מסד נתונים הוא אוסף של חומרים עצמאיים המוצגים בצורה שיטתית כך שניתן למצוא אותם, לשנותם ולהשתמש בהם.
כמה זה אובייקטיבי? מחברים סמכותייםחושב כך. תרגול אמיתי נוטה להבטיח שכל תחום נושא יקבע את מערכת הנתונים הנכונה שלו ונותן כל הזדמנות לבנות מודל דינמי טוב.
זה לא נדיר שלקוח (צרכן) כופה דעה משלו על מתכנת (מעצב מסדי נתונים) על איך ומה לעשות. מבחינת התכנות ניתן למלא כל רצון של הלקוח בדייקנות מירבית.
צריך את אורקל כדי לפתור את בעיית התקצוב לתחזוקת אספקת המים הכפרית (בניין 21 בכפר) - טוב. יש צורך ב-MySQL כדי לארגן מערכת מעקב אחר פריטי דואר עבור כל סניפי הדואר ברוסיה - גם הכל יעבוד.
ניתן תמיד להרכיב כל אלגוריתם ולספק גישה לכל ייצוג מידע במסגרת הגדרת מושג הנתונים, אשר נקבעה על ידי מפתח מערכת ניהול מסד הנתונים או שפת התכנות. השאלה היא אחרת: איך עושים את זה במינימום עלויות בדינמיקה מקסימלית?
מסדי נתונים, דוגמאות
נוצר בסיס פשוט ללא דגם. המושגים הבסיסיים של נתונים ותקשורת הם קטנים, הפונקציונליות פשוטה מאוד. לדוגמה, עבור מוסד להשכלה גבוהה אתה צריך:
- טבלת המורים;
- טבלה קבוצתית (מפתח ומספר קבוצה);
- טבלה כללית של תלמידים (משתמשים במפתחות קבוצתיים).
הדקאן רוצה לדעת את ההתקדמות של המורים. טבלת המורים כוללת שדות:
- שם משפחה;
- name;
- patronymic;
- מספר קבוצה בפיקוח.
לטבלת התלמידים יש שדות:
- שם משפחה;
- name;
- patronymic;
- תאריך לידה;
- GPA (עבור כל המקצועות);
- מספר קבוצה.
יכולות להיות לפחות שתי אפשרויות לדגימה: באמצעות שם המורה, ניתן לגשת למספר הקבוצה ולראות את כל התלמידים וממוצע הציונים שלהם, או לפי שם המשפחה של המורה והאחרון שם התלמיד, אתה יכול לראות את הציון הממוצע של התלמיד האחרון.
אפילו בגרסה כל כך פשוטה, בעיות מובטחות ויהיה צורך לשנות משהו. מצב: המורה חלה, חודש נוסף מחליף אותו, כלומר הוא מפקח על שתי קבוצות. יש רק שדה אחד מתחת למספר קבוצה אחד בטבלת המורים.
כדי לפתור את הבעיה, עליך להוסיף שדה כפול. ואם שניים חולים, אז הוסף שלושה שדות. אז טבלת המורים מתחילה לצמוח מאפס.
יש אפשרות נוספת: החלף את השדה המספרי של מקש הקבוצה בשדה סמלי. לאחר מכן, בכל פעם שתבחר, תצטרך להמיר את המחרוזת לרצף של מפתחות, ושאילתת sql אחת תהפוך לכמה.
דוגמה מבטיחה יותר היא לא ליצור טבלאות, אלא ליצור אובייקטים. אז המורה הוא אובייקט, והוא יכול לקבל כמה קבוצות בפיקוח. אבל זה תמיד אובייקט אחד. לאובייקט המורה יש מפתח ייחודי, אך יכול לכלול מספר קבוצות בפיקוח. לקבוצה יש גם מפתח ייחודי. גם סטודנט.
כל שלושת המשרות זמינות לא רק במסגרת המשימה, אלא ניתן לפתח אותן עוד יותר.
בסיסים מונחה עצמים
מובילי תעשיית המידעמציעים מסדי נתונים יחסיים קלאסיים. הם נבדקו על ידי החיים, הם עובדים, הם בטוחים, אמינים, ובמקרה של בעיות, הם מאפשרים לך לשחזר מידע.
מאגרי מידע מונחי-אובייקט (OODB) החלו להתפתח באמצע שנות ה-80, ולפי מחברים מוסמכים, הם מבטיחים עד היום. אבל עד כה, מלבד תיאוריות יסוד והוראות מושגיות, אין OODB שהשיג את אותו דירוג והפצה כמו MySQL, MS SQL Server או Oracle על כל גלגוליו המגוונים.
אבל מה אם ההגדרה, המושג של נתונים, סוגים, תכונות, מחלקות, היררכיות מוצעת על ידי מפתח שהדירוג שלו לא מספיק כדי ליצור קהילה של מתכנתים שמתיימרים על המנטליות של ה-OODB הזה? נצטרך לסמוך על הכוח שלנו.
יותר משלושים גרסאות של OODB נוצרו בסביבת לינוקס. אבל איפה הערובה שמסד הנתונים שנוצר לא ידרוש יותר פונקציונליות? סביבת Windows אינה מציעה ערבויות רבות בתחום זה.
פתרון מונחה-אובייקט
עם זאת, יש פתרון. באמצעות MySQL כדוגמה, תוכל להראות כיצד טבלאות יחסיות סטנדרטיות הופכות למודל מונחה עצמים של הבעיה הנפתרת.
אין כאן מסד נתונים, אבל יש סביבה ליצירת מערכת עצמים משלך. הכוח של MySQL משמש רק כזיכרון יחסי עבור טבלאות משורות מידע. היגיון השימוש נקבע על ידי היזם עצמו. בפרט, יש טבלת is_cache. יש בו הכלמספר שדות בסיסיים:
- owner_code;
- session_code;
- h_code;
- a_surprise;
- a_contents.
שאר השדות נושאים פונקציות שירות. טבלה זו עומדת בכניסה של כל בקשה ומתעדת את הגעתה. מה יצליח מודל מסד הנתונים נקבע על ידי המפתח שלו. מה יתאים לשדה התוכן (a_contents) נקבע על פי האובייקטים של המודל שנוצר על ידי המפתח.
יש ארבעה דברים ברעיון הזה: היט, הפעלה, קוד היסטוריית היט ותוכן ספציפי. מהי קריאה, איזו מערכת אובייקטים צריכה להיבנות - נקבע על ידי היזם. מה הכוונה במפגש (תהליך עבודה) נקבע על ידי היזם. קוד ההיסטוריה הוא היכולת להחזיר בקשות לאחור.
לטבלאות כאן אין שום קשר לתחום הנושא. יש בקר שיחות (is_cache), יש רישום (is_customs), יש היסטוריית שיחות (is_histories). שאר הטבלאות נקבעות לפי המשימה שנפתרת.
למעשה, פתרון זה מציע ליצור OODB משלך בהתבסס על מודל מסד הנתונים של הדומיין הבנוי והבעיה הנפתרת. יש כאן יתרון עצום - זה תפיסת הנתונים שלך, המודל שלך להצגתם והקשר ביניהם. יש כאן בסיס - מסד נתונים יחסי נהדר. לא יהיו בעיות לחפש משהו ולא להבין משהו.
דגם: מערכת אובייקטים + DBMS
כמעט בלתי אפשרי לשנות שום דבר בטכנולוגיית המידע. מהפכת המידע האמיתית עדיין רחוקה. תודעה מקצועיתמפתחי תוכנה לא הולכים לשנות את המסורות הקלאסיות. אבל עדיין יש דרך לצאת מהמצב.
באמצעות מערכות אמינות מודרניות לניהול מסדי נתונים כבסיס ליצירת סביבה לקיומו של מודל משלך, תוכל להשיג הצלחה ניכרת.
בכל מקרה, תצטרך לבנות תצוגה או מודל נתונים כדי לפתור את המשימה, אבל אתה צריך לעשות את זה נכון: תן לזה להיות מערכת של אובייקטים, ו-DBMS טוב יהיה הסביבה שלה.
