יצירת view דו-זמני

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

view הופך לדו-זמני כשממפים שלוש מהעמודות שלו:

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

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

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

שלוש דוגמאות

דוגמה	זמן תוקף	זמן רישום
תשלום של 100 ל-3 באוק׳ מתוקן ל-120 ב-5 באוק׳.	3 באוק׳, נשמר בתיקון.	3 באוק׳ לגרסה הראשונה; 5 באוק׳ לתיקון.
מדידת שטח שנלקחה ב-3 באוק׳ בשעה 14:10 מוקלדת ב-6 באוק׳. שגיאת הקלדה בה מתוקנת ב-7 באוק׳.	3 באוק׳ 14:10, נשמר בתיקון.	6 באוק׳; התיקון מקבל 7 באוק׳.
עסקה נרשמת בביצוע, תאריך עסקה 3 באוק׳, בשעה 10:02. ב-4 באוק׳ מתברר שהכמות שגויה והיא מתוקנת.	תאריך עסקה 3 באוק׳, נשמר בתיקון.	3 באוק׳ 10:02; התיקון מקבל 4 באוק׳.

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

יצירת ה-view

view ששומר היסטוריה הוא Materialized, כדי שהגרסאות שלו יאוחסנו.

1. פתחו את Views ולחצו על + View.
2. הגדירו את ה-view באחת משתי הלשוניות:
   • Metrics: תנו שם ל-view, בחרו את ה-domain, המדדים והממדים שלו, ולחצו על Continue.
   • SQL: פתחו את עורך ה-SQL, כתבו והריצו את ה-SELECT, לחצו על + View בעורך, תנו שם ל-view ולחצו על Continue.
3. ההגדרות של ה-view נפתחות באותם סעיפים כמו העורך שלו. בסעיף Load and timeliness, סמנו את Materialized View. הסעיף Time Travel מופיע.
4. הגדירו את Keep history ל-Bitemporal.
5. בחרו את העמודות Business key, Valid time ו-Recorded time.
6. הגדירו את השאר בסעיפים האחרים ולחצו על Save. עד אז שום דבר לא נרשם.

שלושתם מוצהרים יחד או לא בכלל. Provisa דוחה view שמציין רק חלק מהם ואומר אילו חסרים.

טבלה מקבלת את אותם סעיפים כשרושמים אותה: בחרו אותה תחת + Table, לחצו על Continue, וסעיף Time Travel שלה נמצא ב-Load and timeliness. מודל מקבל את הסעיף כשיוצרים אותו (+ Model). במודל, המפתח שלו הוא המפתח העסקי, ולכן הסעיף שואל רק על שני הזמנים.

טבלה שמתעדכנת במקום

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

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

היומן מופיע תחת Cache, בלשונית Materialized Store, בשם Version log of הטבלה. ה-Settings שלו קובעים באיזו תדירות הוא נלכד ומהו האיחור המותר; Full capture נמצא לצדם. קריאה רגילה של הטבלה קוראת את הטבלה; קריאה נכון לזמן מסוים, או כפי שנרשם בזמן מסוים, קוראת את היומן שלה.

קריאה

ה-view מופיע ברשימת Views עם התג HISTORY. חלונית הפרטים שלו אומרת שהוא שומר היסטוריה ומקשרת לסייר ה-SQL כשה-view נבחר. הגדירו את בוררי As of ו-As recorded at בסייר לזמנים הרצויים, ואז הריצו את השאילתה.

אותם זמנים מגיעים לכל ממשק אחר. סשן pgwire קובע אותם פעם אחת לכל משפט שהוא מריץ:

SET provisa.as_of = '2026-10-03T12:00:00';
SET provisa.as_recorded = '2026-10-03T23:59:59';

כותרות ה-HTTP, הארגומנטים של resolve ופרמטרי ה-REST מפורטים ב-Views עם היסטוריה.

שינוי בהמשך

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