نموذج حي واحد من كل ما تملك.
الجوهر التقني بلغة مبسّطة: كيف يربط iDBQuery قواعد بياناتك وجداول البيانات وملفات PDF وواجهات API في نموذج واحد قابل للاستعلام تسأله بلغة واضحة — دون مشروع مستودع بيانات ودون خطوط معالجة.
المشكلة.
إجاباتك تعيش في أنظمة كثيرة في آن واحد. فالرقم صفٌّ في Postgres، وعمودٌ في جدول بيانات، وسطرٌ في ملف PDF، وحقلٌ تعيده واجهة API. ودون نموذج واحد فوقها، لا تعود هذه الرؤى لتتصل أبداً، ويتحوّل كل سؤال إلى ظهيرة من التصدير ودوال البحث.
المفتاح.
تتصل MySQL وPostgres وMongoDB وExcel وCSV وملفات PDF وواجهات REST مباشرة. ويقرأ iDBQuery كل مصدر كما هو، ويفحص بنيته، ويبني نموذجاً واحداً قابلاً للاستعلام — دون نسخ بياناتك إلى مستودع آخر.
آلية الاستدلال.
قواعد البيانات الحقيقية تستخدم أسماء جداول وأعمدة غامضة. وتربطها الطبقة الدلالية بمعانٍ تجارية واضحة، فيفهم iDBQuery المخطط المبهم ويجيب بشكل صحيح. والتصحيحات تُحفظ، فيزداد النموذج دقةً مع الوقت.
مفتش العناصر.
اسأل بلغة واضحة واحصل على إجابة يعود فيها كل رقم إلى صفه المصدري. انقر أي رقم لترى بالضبط من أين جاء والاستعلام الذي أنتجه. لا صندوق أسود — فالعمل الحسابي على بُعد نقرة دائماً.
المحرك.
تُنفَّذ الاستعلامات على محرك سريع داخل العملية نفسها. وتحتفظ كل محادثة بجلسة دافئة، فتبقى الأسئلة اللاحقة سريعة. والمصادر التي يتعذّر استعلامها في مكانها تُسحب عند الطلب، مع ضمانات تمنع مصدراً ضخماً من إغراق الذاكرة.
العارض ثلاثي الأبعاد، مُوجَّه بالمحادثة.
تصبح الإجابة الواحدة رسماً بيانياً أو جدولاً أو لوحة حية أو تقريراً قابلاً للمشاركة. فطرح السؤال في المحادثة وبناء سطح منه هما الإجراء نفسه — صِف ما تحتاجه ويجمّعه iDBQuery.
كيف تُسمّي الأنظمة المختلفة المعرّف ذاته
| النظام | اسمه في ذلك النظام |
|---|---|
| قواعد البيانات | المعرّف الفريد للعنصر (GUID) |
| Autodesk Platform Services | المعرّف الخارجي |
| المستندات | المعرّف الخارجي |
| واجهات API | معرّف التطبيق |