نظرة عامة على اتصالات قواعد البيانات¶

جدول المحتويات¶

1. كيف تعمل الاتصالات
2. أدلة التقنيات
3. المتطلب المسبق: تثبيت برنامج تشغيل ODBC على مضيف digna
4. إنشاء اتصال بقاعدة بيانات
5. خصائص ODBC
6. تشفير قيم الخصائص
7. اختبار اتصال
8. أي قاعدة بيانات يراها الاتصال
9. وضع التنميط ومخطط العمل
10. استخدام DSN بدلًا من ذلك
11. استكشاف الأخطاء وإصلاحها

كيف تعمل الاتصالات¶

يصل digna إلى كل تقنية مصدر عبر ODBC. الاتصال هو قائمة من خصائص ODBC تُدخلها كأزواج مفتاح/قيمة. عندما يفتح digna الاتصال، يضمّ هذه الأزواج في سلسلة اتصال — Key=Value، مفصولة بـ ;، بالترتيب الذي أدرجتها به — ويسلّمها إلى مدير برامج تشغيل ODBC (driver manager) على مضيف digna.

إدخالك للخصائص بنفسك هو ما يجعل الإعداد بدون DSN: يحمل الاتصال كل ما يحتاجه برنامج التشغيل، فلا حاجة إلى تسجيل أي مصدر بيانات ODBC (DSN) على المضيف. هذه هي الطريقة الموصى بها لتهيئة digna، لأن تعريف الاتصال يقيم بالكامل داخل digna وينتقل معه.

لماذا ODBC¶

كانت الإصدارات السابقة تتيح الاختيار بين برنامج تشغيل خاص بكل تقنية وبين ODBC، عبر المفتاح Use ODBC. ابتداءً من Release 2026.06، يعتمد digna على ODBC وحده. تقدّم واجهة قياسية واحدة أكثر مما تقدّمه مجموعة من برامج التشغيل المصممة خصيصًا:

• المصادقة — المصادقة جزء من ODBC، لذا يمكن للاتصال استخدام كل ما يدعمه برنامج التشغيل الخاص به: كلمات المرور، والرموز المميزة و PAT، وKerberos وActive Directory، والمصادقة متعددة العوامل وتسجيل الدخول الموحّد عبر المتصفح، وهويات السحابة، وشهادات العميل وTLS. تصل الطرق الجديدة مع تحديث برنامج التشغيل، بدلًا من انتظار إصدار من digna.
• برامج تشغيل يصونها موردو قواعد البيانات — يتابع برنامج التشغيل الخاص بالمورّد إصدارات الخادم الجديدة والإصلاحات الأمنية، ويمكنك تحديثه وفق جدولك الخاص، بشكل مستقل عن digna.
• طريقة واحدة لتهيئة كل شيء — كل تقنية هي قائمة من خصائص مفتاح/قيمة، بالواجهة نفسها، والتشفير نفسه للقيم الحساسة، وطريقة استكشاف الأخطاء نفسها، بدلًا من مجموعة حقول مختلفة لكل مصدر.
• الضبط والاتساع — خيارات برنامج التشغيل مثل المهل الزمنية وإعدادات TLS والوسطاء وأحجام الجلب متاحة لكل مصدر، ويمكن توصيل أي تقنية لديها برنامج تشغيل ODBC متوافق، بما في ذلك تلك التي لا ينشر digna دليلًا خاصًا بها.

أدلة التقنيات¶

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

المتطلب المسبق: تثبيت برنامج تشغيل ODBC على مضيف digna¶

يفتح digna اتصالات المصدر من الخادم الذي يشغّل الواجهة الخلفية لـ digna، لا من المتصفح. لذلك يجب تثبيت برنامج تشغيل ODBC على ذلك الجهاز، ويجب أن يكون اسمه مسجلًا لدى مدير برامج التشغيل المحلي.

odbcinst -q -d

odbcinst -q -d

بدلًا من الاسم المسجل، تقبل جميع مديري برامج التشغيل الشائعة أيضًا المسار الكامل لمكتبة برنامج التشغيل، على سبيل المثال Driver=/opt/simba/spark/lib/64/libsparkodbc_sb64.so. وهذا مفيد عندما يكون برنامج التشغيل مثبتًا لكنه غير مسجل.

إنشاء اتصال بقاعدة بيانات¶

افتح Admin Panel، وانتقل إلى علامة التبويب Database Connections وانقر Add DB Connection. تطلب الشاشة خمسة أشياء:

يُدار الاتصال مركزيًا ثم يُسند إلى مشروع واحد أو أكثر، لذا يمكن للاتصال نفسه أن يخدم عدة مشاريع.

خصائص ODBC¶

انقر Add Property لكل خاصية، واملأ Key وValue، وللأسرار فعّل خانة الاختيار Encrypted. يسرد كل دليل تقنية مجموعة مثال لتلك التقنية، تكيّفها مع إصدار برنامج التشغيل والخادم لديك — انظر الملاحظة أعلاه.

أيًّا كان برنامج التشغيل، تغطي مجموعة الخصائص الأشياء الأربعة نفسها:

• Driver — اسم برنامج التشغيل المسجل، كما هو موضح أعلاه.
• عنوان الخادم — يختلف المفتاح حسب برنامج التشغيل: SERVER أو HOST أو DBCNAME أو Server، أو بالنسبة لـ Oracle واصف الاتصال DBQ.
• بيانات الاعتماد — عادةً UID وPWD؛ يستخدم Snowflake الخاصية UID مع token، ويستخدم Databricks المستخدم الحرفي token مع رمز الوصول الشخصي في PWD.
• قاعدة البيانات أو الكتالوج الذي يُعمل فيه، حيثما يكون للتقنية ذلك — انظر أي قاعدة بيانات يراها الاتصال.

يمكن إضافة أي شيء آخر يوثّقه برنامج التشغيل بالطريقة نفسها — تجميع الاتصالات (connection pooling)، ومهل المقابس (socket timeouts)، وإعدادات Kerberos، وإعدادات الوكيل (proxy). لا يفسّر digna الخصائص؛ بل يمرّرها فقط.

تشفير قيم الخصائص¶

فعّل Encrypted لكل خاصية تحتوي على سر — PWD، أو token، أو سر العميل. عندها تُشفَّر القيمة قبل تخزينها في مستودع digna، وتُخفى في الشاشة، ولا يُفك تشفيرها إلا عند تجميع سلسلة الاتصال.

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

اختبار اتصال¶

انقر Test في نافذة Add DB Connection قبل الحفظ. يستخدم الاختبار القيم الموجودة حاليًا في النموذج ويُجري اتصالًا حقيقيًا، لذا يُبلغ بالضبط عمّا سيواجهه الفحص (inspection) — اسم برنامج تشغيل خاطئ، أو كلمة مرور مرفوضة، أو مضيف غير قابل للوصول. لا يُخزَّن أي شيء: يُتراجع عن اتصال الاختبار سواء نجح أو فشل.

بالنسبة لاتصال موجود بالفعل، مرّر المؤشر فوق صفّه في علامة التبويب Database Connections وانقر أيقونة القابس (plug) لإعادة اختباره. هذه هي أسرع طريقة للتحقق مما إذا كان المصدر قابلًا للوصول بعد تغيير كلمة المرور أو تغيير في الجدار الناري.

أي قاعدة بيانات يراها الاتصال¶

عند إضافة مصدر بيانات، يعرض digna الكتالوجات والمخططات والجداول التي يمكن للاتصال الوصول إليها. ومدى هذا الوصول يعتمد على التقنية:

وضع التنميط ومخطط العمل¶

يحدد وضع التنميط كيف يعالج digna البيانات ويحسب المقاييس:

• Standard: تُحسب المقاييس مباشرة على جداول المصدر دون نسخ البيانات.
• Permanent: تُنسخ بيانات اليوم الذي يجري فحصه إلى جدول دائم، وتُحسب المقاييس على البيانات المنسوخة.
• Session: تُنسخ البيانات إلى جدول جلسة أو جدول مؤقت، وتُحسب المقاييس على هذه البيانات المؤقتة.

يحدد الوضع ما يجب أن يُسمح لمستخدم الاتصال بفعله:

يقتصر Standard على القراءة، مما يجعله الوضع الذي يجب اختياره عندما يُمنح digna وصولًا للقراءة فقط. لا يُقرأ Work Schema إلا في وضع Permanent، لكن يُستحسن ملؤه على أي حال حتى يستمر الاتصال في العمل إذا تغيّر الوضع لاحقًا.

استخدام DSN بدلًا من ذلك¶

لا يزال DSN يعمل — فـ DSN مجرد خاصية أخرى:

Key: DSN        Value: my_registered_dsn
Key: UID        Value: <user>
Key: PWD        Value: <password>        [Encrypted]

يجب أن يكون DSN مسجلًا على مضيف digna، لحساب المستخدم نفسه الذي يشغّل الواجهة الخلفية لـ digna، وكـ System DSN عندما يعمل digna كخدمة. كل ما هو مهيأ في DSN يمكن تجاوزه بإضافته كخاصية أيضًا.

الإعداد بدون DSN هو الافتراضي الموثَّق لأنه يتجنب تلك الحالة المخزنة على المضيف: يُوصف الاتصال بالكامل في digna، ولا يحتاج مضيف digna جديد إلا إلى تثبيت برنامج التشغيل دون أي تهيئة.

استكشاف الأخطاء وإصلاحها¶

Data source name not found / no default driver specified¶

الأعراض: - يُبلغ الزر Test عن خطأ يذكر data source name not found، رغم أن الإعداد بدون DSN

الأسباب والحلول: 1. قيمة Driver لا تطابق اسم برنامج تشغيل مسجلًا — قارنها بعلامة التبويب Drivers في ODBC Data Source Administrator (64-bit)، أو بمخرجات odbcinst -q -d 2. برنامج التشغيل مثبت على محطة عملك لكن ليس على مضيف digna 3. برنامج التشغيل 32-بت بينما digna 64-بت — ثبّت برنامج التشغيل 64-بت 4. الخاصية Driver مفقودة تمامًا، ولم يُعطَ DSN أيضًا 5. على Linux وmacOS، برنامج التشغيل مثبت لكنه غير مسجل — أعطِ المسار الكامل لمكتبة برنامج التشغيل بدلًا من ذلك، أو سجّله في odbcinst.ini

انتهاء مهلة اختبار الاتصال¶

الأعراض: - يتوقف Test ثم يفشل بعد نصف دقيقة تقريبًا

الأسباب والحلول: 1. المضيف أو المنفذ غير قابل للوصول من مضيف digna — تحقق من الجدار الناري، وبالنسبة للمصادر السحابية، من قائمة عناوين IP المسموح بها 2. اسم المضيف صحيح لكن المنفذ يخص خدمة أخرى 3. يحتاج المصدر إلى أكثر من 30 ثانية الافتراضية لقبول الاتصال — ارفع قيمة DIGNA_SOURCE_LOGIN_TIMEOUT_SEC في القسم [base] من config.toml (القيمة 0 تعني الانتظار بلا حد) وأعد تشغيل الواجهة الخلفية 4. نقطة نهاية بلا خادم (serverless) تُستأنف من حالة الخمول — أعد المحاولة، وإذا تكرر ذلك بانتظام، فارفع مهلة تسجيل الدخول كما هو موضح أعلاه

فشل المصادقة رغم صحة بيانات الاعتماد¶

الأعراض: - يُبلغ برنامج التشغيل عن بيانات اعتماد غير صالحة، لكن المستخدم نفسه يعمل في عميل SQL آخر

الأسباب والحلول: 1. تحتوي كلمة المرور على ; — ضع القيمة بين أقواس معقوفة: {p@ss;word} 2. نُسخت مسافة زائدة في نهاية القيمة 3. يتوقع برنامج التشغيل آلية مصادقة محددة — على سبيل المثال AuthMech لبرنامجي تشغيل Hive وDatabricks، أو authenticator لـ Snowflake 4. خُزّنت القيمة مشفرة ثم عُدّلت — لا يمكن قراءة القيم المشفرة مجددًا، لذا أعد إدخال السر كاملًا 5. انتهت صلاحية رمز — تُصدر رموز الوصول الشخصية ورموز الوصول البرمجية بتاريخ انتهاء

شاشة مصدر البيانات لا تعرض قاعدة البيانات أو المخطط المتوقع¶

الأعراض: - الكتالوجات أو المخططات أو الجداول مفقودة عند إضافة مصدر بيانات

الأسباب والحلول: 1. يشير الاتصال إلى قاعدة بيانات مختلفة — انظر أي قاعدة بيانات يراها الاتصال 2. يفتقر مستخدم الاتصال إلى صلاحيات القراءة على المخطط أو على قاموس البيانات 3. قيمة Technology لا تطابق المصدر، لذا يستعلم digna من قاموس البيانات الخطأ 4. بالنسبة لـ Snowflake، لا يوجد مستودع افتراضي مُسند إلى المستخدم ولم تُعطَ الخاصية Warehouse، لذا لا يمكن تنفيذ استعلامات البيانات الوصفية

فشل التنميط بينما ينجح اختبار الاتصال¶

الأعراض: - ينجح Test، لكن الفحص يفشل عند إنشاء جداول العمل

الأسباب والحلول: 1. التنميط Permanent محدد ولا يستطيع مستخدم الاتصال إنشاء جداول في Work Schema — امنح الصلاحيات، أو انتقل إلى Session أو Standard 2. Work Schema فارغ أو يسمّي مخططًا غير موجود، بينما التنميط Permanent محدد 3. التنميط Session محدد ولا يُسمح لمستخدم الاتصال بإنشاء جداول مؤقتة 4. استعلام تنميط طويل التشغيل يصل إلى مهلة الاستعلام — ارفع قيمة DIGNA_SOURCE_QUERY_TIMEOUT_SEC في القسم [base] من config.toml (الافتراضي 3600 ثانية، والقيمة 0 تعطّل المهلة)

أفضل الممارسات¶

افعل:

• ثبّت برنامج التشغيل وسجّله على مضيف digna قبل تهيئة الاتصال
• فعّل Encrypted لكل كلمة مرور ورمز
• انقر Test قبل الحفظ، وأعد الاختبار بعد تغيير كلمة المرور
• سمِّ الاتصالات باسم المصدر والبيئة، على سبيل المثال sales_dwh_prod
• خصّص لـ digna مستخدم قاعدة بيانات مستقلًا، للقراءة فقط حيث يكفي التنميط Standard
• احتفظ باتصال واحد لكل قاعدة بيانات مصدر، وأضف اتصالًا ثانيًا بدلًا من تبديل الأول

لا تفعل:

• لا تخزّن الأسرار دون تشفير، ولا تشارك مستخدم قاعدة بيانات واحدًا بين digna وأدوات أخرى
• لا تستخدم برنامج تشغيل 32-بت مع تثبيت digna 64-بت
• لا تعتمد على User DSN عندما يعمل digna كخدمة — لن يكون مرئيًا
• لا تضع قيمة تحتوي على ; في خاصية دون أقواس معقوفة
• لا تجعل Work Schema يشير إلى مخطط يحتوي على بيانات المصدر

الدعم¶

تحتاج مساعدة في اتصال قاعدة بيانات؟

• البريد الإلكتروني: support@digna.ai
• الوثائق: https://docs.digna.ai
• الموقع: https://www.digna.ai

الإصدار: 2026.06
© 2026 digna GmbH — www.digna.ai