عندما ناقشنا ﻟلDatabase Link تعلمنا كيفية ربط قاعدة بيانات بأخرى وكيفية الوصول إلى الكائنات في قاعدة بيانات أخرى.

ولكن قد تحتاج في بعض الأحيان إلى نقل وتحديث البيانات في قاعدة البيانات إلى قاعدة بيانات أخرى.

على سبيل المثال، إذا كنت مدير مجموعة من الصيدليات؛ فكل صيدلية لديها قاعدة بيانات، ولكنها تحتاج كل ساعة إلى جلب جميع حسابات الصيدليات من قواعد البيانات الموزعة إلى قاعدة البيانات الرئيسية. هذه هي مهمة Materialized Views؛ ولكن Materialized Views لديها مهام أخرى غير مفصلة هنا. 

هنا سوف نستخدم نفس المثال الذي استخدمناه في Database Link، ولنفترض هنا أن قاعدة بيانات OBAY هي قاعدة البيانات الرئيسية التي ستستقبل البيانات،

لنفترض أننا سنستقبل البيانات في المستخدم TEST،

أما بالنسبة لقاعدة البيانات الأخرى ORCL، والتي تحتوي على الجدول الرئيسي، ولنفترض أنها EMPLOYEE، المملوكة للمستخدم VBS، والتي نحتاج إلى نقل وتحديث بياناتها كل ثانية إلى قاعدة البيانات الرئيسية OBAY.

بالطبع نحتاج قبل أي شيء إلى عمل   Database Link بين المستخدم TEST في قاعدة بيانات OBAY والمستخدم VBS في قاعدة بيانات ORCL، لعملية نقل وتحديث بيانات الجدول

EMPLOYEE من قاعدة بيانات ORCL إلى قاعدة بيانات OBAY.

كما أن عملية تحديث البيانات بين الجدول الرئيسي وMaterialized Views تنقسم إلى ثلاثة أنواع:

 1- FAST REFRESH: في هذا النوع من التحديثات يتم نقل البيانات التي تغيرت بعد التحديث الأخير فقط، ولا يحتاج الأمر إلى نقل كافة البيانات من الجدول، بل فقط ما تغير بعد التحديث الأخير.

هذا النوع يختصر الوقت عادة.

2- COMPLETE REFRESH: يقوم هذا النوع من التحديثات بنقل كافة بيانات الجدول من المصدر إلى Materialized Views وإعادة كتابة البيانات القديمة وإضافة البيانات الجديدة.

يتطلب هذا النوع غالباً وقتاً أطول من النوع FAST.

3- FORCE REFRESH: يبدأ هذا النوع أولاً بتطبيق النوع FAST إذا فشلت العملية، على سبيل المثال، إذا لم يتم العثور على Logs Views Materialized على جانب المصدر،

في هذه الحالة يتم تطبيق النوع COMPLETE.

إذا لم يتم تحديد نوع التحديث أثناء إنشاء Materialized Views، يكون الإعداد الافتراضي هو (FORCE).

-:Materialized Views Logs

 كما ذكرنا من قبل فإن نوع التحديث FAST ينقل فقط البيانات التي تغيرت منذ التحديث الأخير من جدول المصدر إلى Materialized Views.

ولكن أين يتم تخزين البيانات التي تغيرت في جدول المصدر قبل نقلها إلى Mataerialized Views؟ الإجابة هي تخزينها في Logs View Materialized وهو جدول يتم إنشاؤه في قاعدة البيانات وحتى في المستخدم الذي يملك جدول المصدر وذلك من خلال الأمر التالي:

CREATE MATERIALIZED VIEW LOG ON EMPLOYEE; 

حيث EMPLOYEE هو جدول المصدر. في لحظة كتابة الأمر أعلاه، تقوم قاعدة البيانات بإنشاء جدول بالصيغة

<MLOG$_<TABLE_NAME.

:Primary Key Materialized Views

 ولكن من أجل تنظيم جدول المصدر دون التأثير على ﺍلFAST REFRESH بحيث يتم حفظ التغييرات بناءً على ﺍلPrimary Key ، يمكننا في لحظة إنشاءﺍلMaterialized Views  تحديد خيار WITH PRIMARY KEY وهو الافتراضي (DEFAULT) إذا لم يتم تحديد خيار آخر، والخيار الآخر هو ROWID.

عند إنشاء ﺍلMaterialized Views  بخيار Primary Key، يجب أن يحتوي جدول المصدر على primary Key Constraint . أيضًا، عند تحديد خيار Fast Refresh عند إنشاء

ل Materialized Views، يجب أن نكون قد أنشأنا ﺍلMaterialized View Logs في المستخدم

الذي يحتوي على جدول المصدر، وإلا ستظهر رسالة خطأ. قد يكون الشرح السابق معقدًا بعض الشيء، ولكن لا تقلق، ركز معي على السيناريو الذي سننفذه معًا خطوة بخطوة، بدءًا من إنشاء المستخدمين إلى إنشاء  ﺍلMaterialized Views ، وهذا هو جوهر القصة.

قاعدة البيانات الأولى تسمى OBAY، سننشئ فيها مستخدمًا يسمى MAIN؛ سنقوم بإنشاء Materialized Views في هذا المستخدم لاسترجاع البيانات من جدول EMPLOYEE المملوك للمستخدم SUB في قاعدة بيانات ORCL.

هذه هي الخطوات:-

1- سنقوم بإنشاء المستخدم MAIN في قاعدة بيانات OBAY ومنحه الأذونات الكافية.

CREATE USER MAIN IDETIFIED BY MAIN;

GRANT CONNECT,RESOURCE,CREATE DATABASE LINK,CREATE MATERIALIZED VIEW TO MAIN; 

2- من ناحية أخرى نتأكد من جدول المصدر وهو هنا EMPLOYEE ونتأكد أيضا من أنه يحتوي على PRIMARY KEY CONSTRAINT حتى نتمكن من إنشاء MATERIALIZED VIEWS في قاعدة البيانات الأخرى باستخدام خيار WITH PRIMARY KEY.

SELECT * FROM EMPLOYEE;

SELECT OWNER,CONSTRAINT_NAME,CONSTRAINT_TYPE,TABLE_NAME FROM USER CONSTRAINTS; 

3- الآن في قاعدة بيانات OBAY نقوم بإنشاء DATABASE LINK  بين المستخدم MAIN والمستخدم SUB في قاعدة بيانات ORCL.

CREATE DATABASE LINK MAINSUB CONNECT TO SUB IDENTIFIED BY SUB USING 'ORCL'; 

4- في قاعدة بيانات ORCL وفي المستخدم SUB الذي يحتوي على جدول المصدر EMPLOYEE نقوم بإنشاء MATERIALIZED VIEW LOG.

CREATE MATERIALIZED VIEW LOG ON EMPLOYEE; 

لقد قمنا بإنشاء سجل MATERIALIZED VIEW لجدول EMPLOYEE.

يمكن التحقق من إنشاء MATERIALIZED  VIEW LOG  لجدول EMPLOYEE من خلال الاستعلام التالي:

SELECT * FROM TAB WHERE TNAME LIKE '%EMPLOYEE'; 

5- في قاعدة بيانات OBAY نقوم بإنشاء MATERIALIZED VIEW.

CREATE MATERIALIZED VIEW EMPLOYEE_MV REFRESH FAST

START WITH SYSDATE

NEXT SYSDATE + 1/(24*60*60)

WITH PRIMARY KEY

AS SELECT * FROM EMPLOYEE@MAINSUB;

لقد قمنا بإنشاء MATERIALIZED VIEW باستخدام خيار FAST REFRESH لأننا قمنا بإنشاء MATERIALIZED VIEW LOG على الجانب الآخر، وإلا لظهرت رسالة خطأ،

كما استخدمنا خيار WITH PRIMARY KEY لأن جدول المصدر يحتوي على PRIMARY KEY CONSTRAINT، ولكن هناك خيار آخر وهو WITH ROWID.

6- الآن يمكننا الاستعلام عن جدول المصدر وMATERIALIZED VIEW. ستلاحظ أنه في كل ثانية كما حددنا

(SYSDATE + 1/(24*60*60

ستكون النتيجة متطابقة بين جدول المصدر EMPLOYEE وMATERIALIZED VIEW وهو EMPLOYEE_MV.

7- الآن إذا أضفنا حقل جديد في جدول المصدر ثم كررنا عمليات الاستعلام فسيظهر الحقل الجديد في MATERIALIZED VIEW.

إذا قمنا بعمل استعلام للجدول MLOG$_EMPLOYEE قبل عملية REFRESH فسوف نجد معلومات عن الحقول التي تمت إضافتها بعد عملية REFRESH الأخيرة ولكن بعد عملية REFRESH تختفي المعلومات السابقة عن الجدول أثناء انتظار الجديد.

يمكن لمشرف قاعدة البيانات عمل استعلام عن MATERIALIZED VIEWS التي تعمل في

قاعدة البيانات من خلال جدول DBA_MVIEWS.

يمكننا الحصول على معلومات عن جدول آخر من نفس الجدول.

يمكننا الحصول على معلومات عن JOBS من خلال DBA_JOBS الجدول.

بالطبع، يمكن للمستخدم MAIN حذف MATERIALIZED VIEW.

DROP MATERIALIZED VIEW EMPLOYEE_MV;