من JSON إلى قاعدة بيانات علائقية
يمكن لقاعدة بيانات أن تقبل كل عملية إدراج ومع ذلك تمنحك ميزانية شراء خاطئة. اطّلع على كيف يُفسد سعر في غير موضعه كتالوج منتجات، وكيف يحوّل Entity Enricher قرارات الهوية والعلاقات المراجَعة إلى جداول وتحديثات قابلة للتكرار.
يفسّر الوكيل ملف JSON الخاص بك ويكتب استعلامات SQL. وينفّذ Supabase MCP تلك الاستعلامات عبر apply_migration وexecute_sql. ويقع على وكيلك أو تطبيقك توفير قواعد النمذجة والهوية والاستيراد المتكرّر.
أنت تراجع مخططًا قابلًا لإعادة الاستخدام، بما في ذلك المفاتيح والعلاقات المشتركة أو المملوكة للسجل الأصل. ويستنتج المحرّك الجداول والقيود والفهارس البنيوية، ثم يوصّل تغييرات البيانات اللاحقة عبر النموذج نفسه. يساعد الذكاء الاصطناعي في اقتراح النموذج، والشيفرة تطبّق قواعده.
تتناول هذه المقارنة وكيلًا يبني انطلاقًا من JSON عبر Supabase MCP. ويمكن لتطبيق Supabase مصمَّم تصميمًا جيدًا أن ينفّذ هذه الضمانات أيضًا. والنموذج المعيب أدناه توضيحٌ لمخاطر النمذجة، وليس إعدادًا افتراضيًا في Supabase ولا معدّل فشل مُقاسًا.
يحتوي هذا الكتالوج الافتراضي على عيّنتين من المنتجات. يبيع المورّد SUP-7 مصباحًا بسعر 12 € ومكتبًا بسعر 85 €. المورّد مشترك، أما السعر ومدة التوريد فيخصّان كل عرض على حدة.
[
{
"sku": "LAMP-01",
"name": "Reading lamp",
"offers": [
{
"supplier": {
"supplier_id": "SUP-7",
"name": "Northstar Supply"
},
"unit_cost_eur": 12,
"lead_time_days": 3
}
]
},
{
"sku": "DESK-02",
"name": "Writing desk",
"offers": [
{
"supplier": {
"supplier_id": "SUP-7",
"name": "Northstar Supply"
},
"unit_cost_eur": 85,
"lead_time_days": 14
}
]
}
]في Entity Enricher، هذه أمثلة مخططات وليست استيرادًا تلقائيًا للبيانات. راجع المخطط المُنشأ، وحدّد المورد كعنصر مشترك والعروض كعناصر مملوكة للأصل، ثم انشر وأثرِ السجلات المطابقة أو أدرجها. وتوفّر معرّفات SKU والمورد المستقرة الهوية في هذا المثال.
تعيين خاطئ توضيحي
| العمود والمفتاح | نوع SQL |
|---|---|
| skuPK | text |
| name | text |
| supplier_idFK | text |
product.supplier_id → supplier.supplier_id
| العمود والمفتاح | نوع SQL |
|---|---|
| supplier_idPK | text |
| name | text |
| unit_cost_eur | numeric |
| lead_time_days | integer |
تحديث SUP-7 بعرض المكتب يستبدل سعر المصباح ومدة تسليمه. المفتاح الخارجي صالح، لكن البيانات خاطئة. كما يقصر هذا التصميم كل منتج على مورّد واحد.
Entity Enricher مع النموذج المراجَع
| العمود والمفتاح | نوع SQL |
|---|---|
| skuPK | text |
| name | text |
| العمود والمفتاح | نوع SQL |
|---|---|
| supplier_idPK | text |
| name | text |
product 1 → N offer N ← 1 supplier
| العمود والمفتاح | نوع SQL |
|---|---|
| product_skuPK / FK | text |
| supplier_idPK / FK | text |
| unit_cost_eur | numeric |
| lead_time_days | integer |
يُعاد استخدام صف مورّد واحد. ولكل زوج (منتج–مورّد) سعره ومدة توريده الخاصة به. وإضافة عرض المكتب تُبقي عرض المصباح سليمًا.
أسماء جداول ومفاتيح طبيعية مبسّطة، مع حذف بيانات المزامنة الوصفية. PK = المفتاح الأساسي، FK = المفتاح الخارجي. ويشكّل مفتاحا العرض معًا مفتاحًا مركّبًا واحدًا. ويفترض هذا المثال وجود عرض حالي واحد لكل زوج؛ أما سجلات الأسعار أو العملات أو شرائح الكميات فتتطلب نمذجة إضافية.
يحتاج مشترٍ إلى 100 مصباح. بدّل بين الاستيراد الأول والثاني لترى ما يعيده كل نموذج.
نموذج خاطئ: ميزانية 100 مصباح
8,500 €
مبالغ فيه بمقدار 7,300 €. أصبح تقرير هامش الربح وتوقّعات الشراء يعتمدان الآن على سعر المكتب.
نموذج EE بعد المراجعة: ميزانية 100 مصباح
1,200 €
يظل عرض المصباح بسعر 12 € ومدة توريد 3 أيام. أما عرض المكتب فهو صف منفصل.
حساب توضيحي مبني على بيانات العينة؛ دون أي استدعاءات لقاعدة البيانات أو خسائر مالية مقاسة.
إنشاء معرّف مورّد جديد عند كل عملية استيراد يؤدي إلى تشتّت المشتريات بين ملفات مكرّرة، فتصبح إجماليات الإنفاق ومقارنات المورّدين مضلِّلة.
Entity Enricher
المفاتيح المستقرة المعلَنة تجعل الكيانات المتكررة تتقارب. وقد تساعد المعرّفات الدلالية الاختيارية عند اختلاف التسميات، مع مطابقات لا تزال بحاجة إلى مراجعة.
مفتاح ربط يبدأ بـ product_sku لا يحل محل فهرس يبدأ بـ supplier_id. وقد تصبح عمليات البحث العكسي مكلفة مع نمو الكتالوج.
Entity Enricher
ينشئ EE فهارس بنيوية لعلاقاته، بما في ذلك عمليات البحث العكسي في جداول الربط، ويتجنّب الفهارس الزائدة ذات البادئة الأولى نفسها. اضبط الفهارس الأخرى وفق استعلاماتك الفعلية.
يكتسب ملف JSON لديك حقل عرض جديدًا، بينما لا يكتسبه الجدول الهدف ولا استعلام SQL الخاص بالاستيراد. فتفشل البيانات الجديدة في التحميل أو لا تصل أبدًا إلى التقارير التي تحتاج إليها.
Entity Enricher
يحدّد المخطط المنشور شكل الجداول وإسقاط البيانات معًا. عايِن عمليات الترحيل المدعومة قبل النشر؛ أما التحويلات غير المدعومة فمحظورة.
ينقطع الاتصال بعد الاستيراد. وبدون قواعد لإعادة التشغيل، قد تُنشئ إعادة المحاولة نسخًا مكررة؛ وقد يحل تحديث أقدم محل عرض أحدث.
Entity Enricher
يوفّر EE تسليمًا مرتّبًا وعمليات إدراج/تحديث قائمة على الهوية وضوابط للمراجعات. ويطبّق عميل PostgreSQL الدفعة ضمن معاملة واحدة ويؤكّدها بعد الالتزام.
يعيد النموذج ملف JSON، لكن أحد العروض يفتقر إلى مفتاح مطلوب أو ترفض الوجهة عملية الكتابة. ورسالة النجاح وحدها قد تُخفي منتجات وعروضًا مفقودة.
Entity Enricher
قد ترفض سياسات القبول كيانًا أو تُغفل العناصر الفرعية غير المكتملة. يُبلّغ EE عن النتائج الجزئية ويتتبّع تسليم النسخ المتماثلة بشكل منفصل، حتى تتمكن من تحديد ما يحتاج إلى إصلاح.
إعادة كتابة العروض غير المتغيّرة تستهلك موارد قاعدة البيانات، وتُحدِّث الفهارس دون داعٍ، وتزيد الضجيج في معالجة التغييرات اللاحقة.
Entity Enricher
يكتشف EE حالة الكيان غير المتغيّرة ويحمي تحديثات الصفوف من القيم غير المتغيّرة. ويمكن للمستهلكين متابعة تدفق الفروقات لرصد التغييرات، بما في ذلك عمليات الحذف.
راجع الهوية والملكية ومعنى كل حقل قبل النشر. يجعل EE هذه القرارات قابلة للتنفيذ، لكنه لا يستطيع إثبات صحة نموذج عملك. فالمطابقة الدلالية قد تُخطئ، ويظل أداء الاستعلامات مرهونًا بحجم العمل وحجم قاعدة البيانات.
يحلّ آخر إثراء محل الحالة الراهنة: فالقيم المفقودة قد تمحو القيم السابقة، وقائمة العروض المملوكة الأقصر تحذف العروض المُغفَلة. فاحتفظ بسجل تاريخي منفصل عند الحاجة. وتتطلب البيانات الجزئية أو المرفوضة تصحيحًا وإعادة إرسال؛ فحالة التسليم ليست إصلاحًا تلقائيًا.
يفيد Supabase MCP عندما تريد من وكيل أن يفحص قاعدة بيانات ويكتب استعلامات SQL مخصّصة. أما EE فيفيد عندما يجب أن يستمر عقد البيانات نفسه في إنتاج تحديثات علائقية متّسقة. ويمكنك استخدام Supabase PostgreSQL وجهةً لعميل المزامنة في EE، وفقًا لأذونات الاتصال وقاعدة البيانات. وتبقى سياسات الوصول إلى التطبيق من مسؤوليتك أنت.
روجع في 10 سبتمبر 2026. يوفّر Supabase عمليات ترحيل وأدوات Advisors تُنبّه إلى الفهارس المفقودة؛ أما ما يميّز EE فهو توليد القواعد وتطبيقها انطلاقًا من مخطط الإثراء الذي جرت مراجعته.