قاموس نموذج البيانات

ميخائيل كونوفالوف ، رئيس قسم دعم مشاريع التكامل ، مديرية تكنولوجيا المعلومات ICD

يوم جيد يا خبروفيت!

هدف

منهج منظم لإدارة التنزيلات. نريد أن نقول كيفية تبسيط وأتمتة ملء المستودع بالمعلومات ، وفي نفس الوقت عدم الخلط في التدفقات من المصادر المختلفة.

مقدمة

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

أنت محظوظ إذا تم تطوير نظامك من البداية (من الجدول الأول) وتم إدارته بواسطة مهندس معماري واحد ، وفريق واحد من المطورين والمحللين. وإلى جانب ذلك ، قاد هذا المهندس المعماري بكفاءة نموذج مستودع البيانات. ولكن الحياة متعددة الأوجه ، ففي معظم الحالات تنمو DWH تلقائيًا ، في البداية كان هناك 30 طاولة ، ثم أضفنا المزيد حسب الحاجة ، ثم أحببنا ذلك وبدأنا في الإضافة لكل فرصة ، والآن لدينا أكثر من خمسة آلاف ، نعم الطبقات ، التدريج وعروض لا تزال تظهر. كل هذه "السعادة" سقطت علينا نتيجة لعملية واحدة ، ولكنها مريحة للغاية ، وهي علاقة سببية صعبة:

• يقول العمل: "لدينا حاجة لمثل هذه البيانات وهذه. بحاجة الى تقرير جديد »
• المحلل يبحث
• مطور ينفذ
• المهندس ينسق ويساهم في نموذج البيانات

ولكن ، كقاعدة عامة ، النقطة الأخيرة في الواقع غير موجودة. ويبدو فقط في لحظة معينة في الشركات الكبيرة التي تطورت إلى DWH ، حيث يدير المهندس المعماري الأنيق بكفاءة سلامة المعلومات في قاعدة البيانات. هذه المستودعات هي عبارة عن مراجعة للهيكل السابق ، والتي تم إعادة توثيقها ، وغالبًا ما أعيد بناؤها ، مع التركيز على الإصدار السابق (غير الموثق).

لذلك ، ملخص موجز:

1. لا يوجد DWH الذي ولد على الفور ولم يمثل في السابق قاعدة بيانات منتظمة مع مجموعة من الجداول ؛
2. كل ما هو موجود الآن ، وهو عبارة عن بنية خوارزمية وموثقة بشكل واضح ، تم الحصول عليه نتيجة لـ "تجربة مريرة" من التطورات السابقة.

إذا كنت المالك السعيد لـ DWH "الصحيح" ، أو إذا كنت جزءًا من فريق هذا المالك السعيد ، فقد تبدو هذه المقالة "نظريًا" مثيرة للاهتمام بالنسبة لك. وإذا كان عليك فقط مراجعة المراجعة ، أو إعادة (منعك) ، فبإمكان هذه المقالة تبسيط حياتك إلى حد كبير.

نظرًا لأنه يمكن أن يكون هناك قدر لا يمكن تصوره من مصادر المعلومات ، فهناك على الأقل نفس عدد التنزيلات وتدفقات التحميل الزائد لكائنات مختلفة ، وغالبًا ما يكون أكثر من ذلك بكثير ، نظرًا لأن كل كائن قاعدة بيانات يمكن أن يمر بأكثر من تحويل واحد قبل استخدام المستخدم النهائي لبياناته لإنشاء تقارير العمل. ولكن من أجله ، من أجل العمل ، وليس من أجل سعادته الخاصة ، تم تصميم هذا النظام البيئي بالكامل من أجل "النقل من سفينة إلى أخرى".

يستخدم Oracle كقاعدة بيانات لتخزيننا. مرة واحدة ، في مرحلة الإنشاء ، كان النواة المركزية لقاعدة البيانات الخاصة بنا تتألف من بضع مئات من الجداول. لم نفكر في التدريج ومتجر النوافذ. ولكن ، كما يقولون ، "كل شيء يتدفق ، كل شيء يتغير" ، والآن لقد نمت! تملي الأعمال متطلبات جديدة ، وقد ظهر بالفعل تكامل مع قواعد بيانات MS SQL و SyBASE و Vertica و Access المختلفة. من حيث لا تتدفق المعلومات إلينا ، حتى أنه ظهر تبادل مثل XML و JSON مع أنظمة الطرف الثالث ، وملف XLS كمصدر للمعلومات أمر عفا عليه الزمن تمامًا.

الحياة جعلتنا نذهب من خلال مراجعة وتحديث نموذج البيانات ، والحفاظ عليه وصيانته. فيما يلي أحد الأجزاء الأساسية:


التين. 1

لمن هو ، لكن بالنسبة لي - يمكن قراءته فقط على ورقة Whatman ، وستكون A0 صغيرة بعض الشيء ، أفضل من 4A0 ، على الشاشة يكون من المستحيل للعين أو الخيال.

تذكر الآن أن هذا هو جوهر (طبقة البيانات الأساسية) فقط ، أو بالأحرى الجزء الرئيسي منه ، يتكون النواة الكاملة من عدة أنظمة فرعية ليست أدنى مستوى من النظام الأساسي. تتم إضافة طبقة البيانات الأساسية وطبقة بيانات مارت أيضًا إلى هذا. علاوة على ذلك - أكثر من ذلك ، تتلقى الطبقة الأساسية معلوماتها من مصادر البيانات ، وهذا ، كما ذكر أعلاه ، مختلف قواعد البيانات والملفات. من ناحية أخرى ، إلى طبقة نوافذ المتاجر ، ينضم المستهلك إلى أنظمة الإبلاغ المختلفة.

في البداية ، عندما كان هناك عدد قليل من جداول قواعد البيانات وخوارزميات التحميل المطبقة في PL / SQL ، لم تكن هناك صعوبات خاصة في فهم تحديثات البيانات. ولكن مع ظهور DWH ، كان القرار الاستراتيجي هو شراء Informatica PowerCenter. مع كل راحة هذه الأداة ، سواء من حيث موثوقية التحميل والتصور للتنمية ، هذه الأداة لديها العديد من العيوب. يوضح الشكل أدناه نموذجًا لتسلسل بدء التشغيل لتحميل DWH.


التين. 2

العيب الأكثر أهمية هو الذاتية ، أو بالأحرى ، يمكن للمهندس المعماري فقط ضمان عدم نشر المنشورات قبل الفواتير. لسوء الحظ ، مع نمو DWH ، يزداد أيضا إنتروبيا المعلومات. مع الأخذ في الاعتبار نموذج البيانات المادية (الشكل 1) ومنطق تحميل هذه البيانات (الشكل 2) ، لا يزال يتم الحصول على البناء.

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

نظرية

سأحاول الآن توضيح الأفكار الرئيسية لقاموس نموذج البيانات ، وكذلك المهام التي يحلها.

نظرًا لأن البيانات الموجودة في وحدة التخزين موجودة في الجداول ، وأن مصادر البيانات عبارة عن جداول جزئية ، ووجهات نظر جزئية ، فإن الأخيرة هي جداول. ثم يلي فكرة بسيطة - لإنشاء بنية التبعية TABLE - TABLE . شكل 3NF مناسب تمامًا لهذا الغرض.

أولاً ، ملء بيانات كيان DWH ، نسميها (الهدف) ، في الحالة العامة ، يمكن تمثيلها على أنها محددة من جداول مختلفة. سواء أكان ذلك عبارة عن جداول Oracle أو SyBase أو MSSQL أو ملفات XLS أو أي شيء آخر ، فليس من المهم للغاية ، كل هذا ، نحن نسمي مصادرهم (المصدر) . وهذا هو ، لدينا مصدر يتدفق إلى الهدف .

ثانيا ، كل كيان DWH لديه إشارات إلى بعضها البعض.

ثالثًا ، هناك تسلسل زمني لبدء التنزيلات لمختلف كيانات DWH.

يبقى الحال بالنسبة للصغيرة ، لتنفيذ - كيف؟ يبدو أن الأمر بسيط للغاية ، من أساس DWH الخاص بك ، يجب على المهندس المعماري ، عندما يظهر الجدول التالي للكيان (الهدف) ، النظر في القاموس ووضع كيان المستقبل وجميع الكيانات التي تعمل كمصادر ووضعها في القاموس. علاوة على ذلك ، في الجدول الثاني من القاموس ، حدد الروابط بين مصادر هذه الكيانات في تحديد ، وكذلك جميع الجداول الثانوية التي يتم الرجوع إليها بواسطة المراجع. بعد ذلك ، يمكنك تضمين تحميل هذا الكيان في سلسلة تنزيل التخزين. يتم حل جدولين فقط - وإمكانية مراعاة تسلسل ملء البيانات مع الخوارزمية في الخوارزمية.

سيقوم نموذج بيانات القاموس بحل المشكلات التالية:

• عرض التبعيات. يمكنك أن ترى ما هي البيانات ، حيث يتم استخلاصها من. هذا مناسب للمحللين الذين تعذبهم الأسئلة دائمًا: "من أين وماذا يكمن ومن أين يأتي كل شيء". قدم هذا في التطبيق في شكل شجرة ، من المصدر إلى الهدف ، والعكس بالعكس: من الهدف إلى المصدر .
• تمزق الحلقات. عند تضمين التحميل التالي في دفق مشترك يعمل بالفعل ، دون وجود قاموس لطراز البيانات ، من الممكن تمامًا ارتكاب خطأ وتعيين وقت بدء لتحميل الهدف التالي أمام أحد مصادره. هذا يخلق حلقة. سوف قاموس نموذج البيانات بسهولة تجنب هذا.
• يمكنك كتابة خوارزمية لملء التخزين بناءً على قاموس النموذج. في هذه الحالة ، ليست هناك حاجة لتضمين التنزيل التالي في أي مكان ، فقط قم بإظهاره في القاموس وستحدد الخوارزمية مكانه. يبقى النقر على زر "Make ALL" المطلوب. سيقوم محمل الإقلاع بإطلاق تنزيلات تشبه الانهيارات الثلجية لجميع وحدات التخزين - من البسيط (المستقل) إلى المركب (المعتمد).

تطبيق

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

الآن ، في الحقيقة ، سوف أخبرك كيف تمكنا من اللحاق بالركب وجعل المراجعة وإعادة البناء رخيصة بما فيه الكفاية. بدأت DWH لدينا في التطور مع قرار القيادة حول حاجة وشيكة (DWH). كأداة ، تم استخدام PL / SQL لأول مرة. وبعد ذلك بقليل تحولت إلى Informatica. بطبيعة الحال ، كانت الأولوية توقيت الخلق. ظهر نموذج البيانات في PowerDesigner في وقت لاحق ، في الوقت الذي تشكلت فيه الثقة بوضوح أنه لا يمكن لأحد أن يتخيل بوضوح صورة كاملة وواضحة لـ DWH. لقد عشنا لبعض الوقت مع النموذج على الحائط ، عندما أصبح من الواضح أننا لا نستطيع التعامل مع إدارة هذا النظام برمته ، بدأنا في البحث عن حل سأحاول أن أصفه هنا باختصار.

قاموس نموذج البيانات في حد ذاته بسيط مثل العصا. ولكن ملء الأمر مشكلة. N- أشهر من المضنية ، والأهم من ذلك ، دراسة متأنية للأجزاء الثلاثة المذكورة أعلاه:

• ما هي المصادر (المصدر) التي يتكون منها كل كيان من المستودع (الهدف) ؛
• ما هي العلاقات بين كائنات التخزين (المراجع) ؛
• التسلسل الزمني لبدء التنزيل وملء المخزون.

لحسن الحظ ، ساعدنا Oracle و Informatica ، واتضح لنا أن مستودع Informatica موجود في قاعدة بيانات Oracle. مع الأخذ في الاعتبار أن جلسة Informatica هي ذرة التحميل لكيان DWH ، حيث يتم البحث قليلاً في المستودع ، وجدنا كل المصدر والهدف. هذا هو ، في إطار جلسة واحدة ، لجميع أهدافها (كقاعدة عامة ، هي واحدة) ، كل مصدرها مصادر. وبالتالي ، يمكننا ملء الشرط الأول للمشكلة. لكن لا تتسرع في الفرحة ، يمكن تقديم المصدر في شكل تحديد ذكي للغاية ، لذلك كان عليك كتابة محلل يقوم بسحب جميع الجداول المحددة في تحديد - لم يكن الأمر صعبًا على الإطلاق. لكن هذا ليس كل شيء ، فهذه الجداول نفسها يمكن أن تكون في الواقع تمثيلات. باستخدام DBA_VIEWS (أو من خلال DBA_DEPENDENCIES) تم حل هذه المشكلة أيضًا. لقد سحبنا الشرط الثاني من هذه ثلاثية من نموذج البيانات (الشكل 1) و DBA_CONSTRAINTS. لقد حصلنا أيضًا على الشرط الثالث من مستودع Informatica استنادًا إلى (الشكل 2).

ما جاء من كل هذا؟

• أولاً ، قمنا بفك تشابك جميع الحلقات التي تمكنا من رياحها في تطور DWH الخاص بنا.
• ثانياً ، لقد حصلنا على شجرة رائعة للمحللين:
  
  
  التين. 3
• ثالثا ، لدينا superloader ، المقدمة في التين. 2 تحولت إلى أنيقة (آسف ، أيها الزملاء ، ولكن تشويش الصورة مقصودة ، لأن هذه البيانات تعمل):
  
  
  التين. 4

قد يكون لديك الكثير من الطرق لتطبيق قاموس نموذج البيانات.

شكرا لكم جميعا!