عنصر النمذجة مخصص لوصف تعريفي لنموذج المجال في شكل علم الوجود - شبكة من مثيلات البيانات (الحقائق) والمفاهيم المجردة المترابطة من خلال العلاقات. يعتمد على منطق الإطار - مزيج من نهج موجه للكائنات لتمثيل المعرفة ومنطق الدرجة الأولى. عنصرها الرئيسي هو مفهوم يصف كائنًا تم تصميمه باستخدام مجموعة من السمات. تم بناء المفهوم على أساس مفاهيم أو حقائق أخرى ، والمفاهيم الأولية ستسمى الوالدين ، والمشتق - الطفل... تربط العلاقات بين قيم سمات الطفل والمفاهيم الرئيسية أو تحد من قيمها المحتملة. قررت تضمين العلاقات في تعريف المفهوم ، بحيث تكون جميع المعلومات المتعلقة به ، إن أمكن ، في مكان واحد. سيكون نمط بناء الجملة لتعريفات المفاهيم مشابهًا لـ SQL - يجب فصل السمات والمفاهيم الرئيسية والعلاقات بينها إلى أقسام مختلفة.
في هذا المنشور ، أريد أن أقدم الطرق الرئيسية لتعريف المفاهيم.
أولاً ، مفهوم تم إنشاؤه من خلال تحويل المفاهيم الأبوية .
ثانيًا ، يتضمن النمط الموجه للكائنات الميراث ، مما يعني أنك بحاجة إلى آلية تسمح لك بإنشاء مفهوم من خلال وراثة سمات وعلاقات المفاهيم الأصلية ، وتوسيعها أو تضييقها.
ثالثًا ، أعتقد أن الآلية ستكون مفيدة في تحديد العلاقة بين مفاهيم الأقران - دون التقسيم إلى مفاهيم الطفل والآباء.
الآن دعنا ننتقل إلى دراسة تفصيلية للأنواع الرئيسية لمكونات النمذجة.
لنبدأ بالحقائق
تمثل الحقائق وصفًا لمعرفة محددة حول مجال ما في شكل مجموعة مسماة من أزواج القيمة الرئيسية:
fact < > {
< > : < >
...
}على سبيل المثال:
fact product {
name: “Cabernet Sauvignon”,
type: “red wine”,
country: “Chile”
}قد لا يكون اسم الحقيقة فريدًا ، على سبيل المثال ، قد يكون هناك العديد من المنتجات بأسماء وأنواع ودول منشأ مختلفة. سنعتبر الحقائق متطابقة إذا تطابقت أسمائها وأسماء سماتها وقيمها.
يمكن استخلاص تشابه بين الحقائق في مكون النمذجة والحقائق في Prolog. تختلف فقط في النحو. في Prolog ، يتم تحديد حجج الحقائق من خلال موقعها ، ويتم تحديد سمات حقائق مكون النمذجة بالاسم.
المفاهيم
المفهوم عبارة عن هيكل يصف كيانًا مجردًا ويستند إلى مفاهيم وحقائق أخرى. يتضمن تعريف المفهوم اسمًا وقوائم سمات ومفاهيم فرعية. وأيضًا تعبير منطقي يصف التبعيات بين سمات (مفهوم الطفل) وسمات المفاهيم الأصلية ، مما يتيح لك استنتاج قيمة سمات مفهوم الطفل:
concept < > < > (
< > = <>,
...
)
from
< > < > (
< > = <>
...
),
…
where < >مثال على تحديد الربح على أساس مفاهيم الإيرادات و التكاليف :
concept profit p (
value = r.value – c.value,
date
) from revenue r, cost c
where p.date = r.date = c.dateيتشابه تعريف المفهوم في الشكل مع استعلام SQL ، ولكن بدلاً من اسم الجدول ، يجب تحديد أسماء المفاهيم الأصلية ، وبدلاً من الأعمدة التي تم إرجاعها - سمات المفهوم الفرعي. بالإضافة إلى ذلك ، فإن المفهوم له اسم يمكن من خلاله الإشارة إليه في تعريفات المفاهيم الأخرى أو في استعلامات النموذج. يمكن أن يكون مفهوم الأصل إما المفهوم نفسه أو الحقائق. تعبير العلاقة في جملة where عبارة عن تعبير منطقي يمكن أن يتضمن عوامل تشغيل منطقية وشروط مساواة وعوامل حسابية واستدعاءات دالة وما إلى ذلك. يمكن أن تكون وسيطاتهم عبارة عن متغيرات وثوابت ومراجع لسمات مفاهيم الأصل والفرع. مراجع السمات لها التنسيق التالي:
< >.< >مقارنة بمنطق الإطار ، في تعريف المفهوم ، يتم دمج هيكله (السمات) مع العلاقات مع المفاهيم الأخرى (المفاهيم الأصلية والتعبير عن العلاقات). من وجهة نظري ، هذا يسمح لك بجعل الكود أكثر قابلية للفهم ، حيث يتم جمع جميع المعلومات حول المفهوم في مكان واحد. كما أنه يتوافق مع مبدأ التغليف بمعنى أن تفاصيل تنفيذ المفهوم مخفية داخل تعريفه. للمقارنة ، يمكن العثور على مثال صغير بلغة منطق الإطار في المنشور السابق .
التعبير عن العلاقات له شكل ربط (يتكون من تعبيرات مرتبطة بالعمليات المنطقية "و") ويجب أن يتضمن شروط المساواة لجميع سمات مفهوم الطفل ، كافية لتحديد قيمهم. بالإضافة إلى ذلك ، قد تتضمن شروطًا تحد من معنى المفاهيم الأصلية أو تربطها معًا. إذا لم تكن جميع المفاهيم الأصلية مرتبطة في جملة where ، فسيعيد محرك الاستدلال جميع المجموعات الممكنة لقيمها كنتيجة (على غرار عملية FULL JOIN في SQL).
للراحة ، يمكن وضع بعض شروط المساواة في السمات في قسم السمات في مفاهيم الطفل والوالد. على سبيل المثال ، في تعريف الربح ، شرط السمةيتم نقل القيمة إلى قسم السمات ، وبالنسبة لسمة التاريخ يتم تركها في قسم أين . يمكنك أيضًا نقلها إلى القسم من :
concept profit p (
value = r.value – c.value,
date = r.date
) from revenue r, cost c (date = r.date)يسمح لك هذا السكر النحوي بجعل التبعيات بين السمات أكثر وضوحًا وتمييزها عن الشروط الأخرى.
تتبع المفاهيم القواعد في Prolog ولكن لها دلالات مختلفة قليلاً. يؤكد Prolog على بناء البيانات والأسئلة ذات الصلة منطقيًا بهم. تهدف المفاهيم في المقام الأول إلى هيكلة بيانات الإدخال واستخراج المعلومات منها. سمات المفهوم تتوافق مع حجج مصطلحات Prolog. ولكن إذا كانت الوسيطات في Prolog مرتبطة باستخدام المتغيرات ، ففي حالتنا يمكن الوصول إلى السمات مباشرة من خلال أسمائها.
نظرًا لأن قائمة المفاهيم الأصلية وشروط العلاقة مفصولة إلى أقسام منفصلة ، فإن الاستنتاج سيكون مختلفًا قليلاً عن ذلك في Prolog. سأصف خوارزمية بشكل عام. سيتم إخراج المفاهيم الأصلية بالترتيب الذي تم تحديدها به في المقطع من . يتم إجراء البحث عن حل للمفهوم التالي لكل حل جزئي للمفاهيم السابقة بنفس الطريقة كما في دقة SLD. ولكن بالنسبة لكل حل جزئي ، يتم التحقق من صلاحية تعبير العلاقة من جملة where .... نظرًا لأن هذا التعبير في شكل مقترن ، يتم اختبار كل تعبير فرعي على حدة. إذا كان التعبير الفرعي خاطئًا ، فسيتم رفض هذا الحل الجزئي ويستمر البحث إلى الحل التالي. إذا لم يتم تحديد بعض وسيطات التعبير الفرعي بعد (غير مرتبطة بالقيم) ، فسيتم تأجيل التحقق من صحتها. إذا كان التعبير الفرعي عامل مساواة وتم تحديد واحدة فقط من وسيطاته ، فسيجد نظام الاستدلال قيمته ويحاول ربطه بالوسيطة المتبقية. هذا ممكن إذا كانت الوسيطة المجانية سمة أو متغيرًا.
على سبيل المثال ، عند عرض كيانات مفهوم الربح ، سيتم العثور على كيانات مفهوم الإيرادات ، وبالتالي ، قيم سماته أولاً . ثم p.date المساواة = r.date = c.dateفي قسم حيث سيمكنك من ربط سمات التاريخ والمفاهيم الأخرى بالقيم . عندما يصل البحث المنطقي إلى مفهوم التكلفة ، فإن قيمة سمة التاريخ الخاصة به ستكون معروفة بالفعل وستكون وسيطة الإدخال لهذا الفرع من شجرة البحث. أخطط للتحدث بالتفصيل عن خوارزميات الاستدلال في إحدى المنشورات التالية.
الاختلاف عن Prolog هو أنه في قواعد Prolog ، كل شيء عبارة عن مسندات - ويدعو إلى القواعد الأخرى والمسندات المضمنة في المساواة ، والمقارنة ، وما إلى ذلك ، ويجب تحديد ترتيب تدقيقها بشكل صريح ، على سبيل المثال ، يجب أن يذهب أول قاعدتين ثم المساواة في المتغيرات:
profit(value,date) :- revenue(rValue, date), cost(cValue, date), value = rValue – cValueبهذا الترتيب ، سيتم تنفيذها. يفترض مكون النمذجة أن جميع حسابات الشروط في الجملة حيث تكون حتمية ، أي أنها لا تتطلب الغوص المتكرر في فرع البحث التالي. نظرًا لأن حسابهم يعتمد فقط على حججهم ، فيمكن حسابهم بترتيب تعسفي لأن الوسائط مرتبطة بالقيم.
كنتيجة للاستدلال ، يجب ربط جميع سمات المفهوم الفرعي بالقيم. وكذلك يجب أن يكون التعبير عن العلاقات صحيحًا ولا يحتوي على تعبيرات فرعية غير محددة. من الجدير بالذكر أن اشتقاق المفاهيم الأبوية لا يجب أن يكون ناجحًا. هناك حالات يُطلب فيها التحقق من فشل اشتقاق المفهوم الأصلي من البيانات المصدر ، على سبيل المثال ، في عمليات النفي. ترتيب المفاهيم الأصل في من القسم يحدد الترتيب الذي اجتاز شجرة القرار. هذا يجعل من الممكن تحسين البحث عن حل ، بدءًا من تلك المفاهيم التي تحد بشدة من مساحة البحث.
تتمثل مهمة الاستدلال المنطقي في العثور على جميع البدائل الممكنة لسمات مفهوم الطفل وتمثيل كل منها ككائن. تعتبر هذه الكائنات متطابقة إذا تطابق أسماء المفاهيم والأسماء وقيم السمات.
من المقبول إنشاء عدة مفاهيم بنفس الاسم ، ولكن مع تطبيقات مختلفة ، بما في ذلك مجموعة مختلفة من السمات. يمكن أن تكون هذه إصدارات مختلفة من نفس المفهوم ، ومفاهيم ذات صلة يمكن دمجها بسهولة تحت اسم واحد ، ومفاهيم متطابقة من مصادر مختلفة ، وما إلى ذلك. في الاستنتاج المنطقي ، سيتم النظر في جميع التعريفات الحالية للمفهوم ، وسيتم دمج نتائج بحثهم. تتشابه العديد من المفاهيم التي تحمل نفس الأسماء مع القاعدة في Prolog ، حيث يكون لقائمة المصطلحات شكل منفصل (المصطلحات هي ORed).
وراثة المفهوم
واحدة من العلاقات الأكثر شيوعًا بين المفاهيم هي العلاقات الهرمية مثل الجنس والأنواع. تكمن خصوصيتهم في أن هياكل الطفل ومفاهيم الوالدين ستكون متشابهة جدًا. لذلك ، فإن دعم آلية الوراثة على مستوى النحو مهم جدًا ؛ وبدونها ستكون البرامج مليئة بالكود المتكرر. عند بناء شبكة من المفاهيم ، سيكون من الملائم إعادة استخدام سماتها وعلاقاتها. في حين أن قائمة السمات يسهل توسيعها أو اختصارها أو إعادة تعريف بعضها ، إلا أن الموقف مع تعديل العلاقات أكثر تعقيدًا. نظرًا لأنها تعبير منطقي في شكل ربط ، فمن السهل إضافة تعبيرات فرعية إضافية إليها. ومع ذلك ، قد يتطلب الحذف أو التغيير مضاعفات كبيرة في بناء الجملة. فوائد هذا ليست واضحة جدالذلك ، سوف نؤجل هذه المهمة للمستقبل.
يمكنك إعلان مفهوم يعتمد على الميراث باستخدام البناء التالي:
concept < > < > is
< > < > (
< > = <>,
...
),
...
with < > = <>, ...
without < >, ...
where < >يحتوي قسم is على قائمة بالمفاهيم الموروثة. يمكن تحديد أسمائهم مباشرة في هذا القسم. أو حدد القائمة الكاملة للمفاهيم الرئيسية في القسم from وفي is - الأسماء المستعارة لتلك المفاهيم التي سيتم توريثها فقط:
concept < > < > is
< >,
…
from
< > < > (
< > = <>
...
),
…
with < > = <>, ...
without < >, ...
where < >يسمح لك قسم with بتوسيع قائمة سمات المفاهيم الموروثة أو تجاوز بعضها ، بدون قسم - للتقصير.
خوارزمية الاستدلال لمفهوم ما على أساس الوراثة هي نفس خوارزمية المفهوم الذي تمت مناقشته أعلاه. الاختلاف الوحيد هو أن قائمة السمات يتم إنشاؤها تلقائيًا بناءً على قائمة سمات المفهوم الأصلي ، ويتم استكمال التعبير عن العلاقات بعمليات المساواة في سمات الطفل والمفاهيم الأصل.
دعونا ننظر في عدة أمثلة لاستخدام آلية الميراث. يتيح لك الميراث إنشاء مفهوم قائم على مفهوم موجود ، والتخلص من تلك السمات التي لا تكون ذات مغزى إلا للوالد ، ولكن ليس لمفهوم الطفل. على سبيل المثال ، إذا تم تقديم بيانات المصدر في شكل جدول ، فيمكن عندئذٍ تسمية خلايا أعمدة معينة بأسمائها الخاصة (التخلص من السمة برقم العمود):
concept revenue is tableCell without columnNum where columnNum = 2من الممكن أيضًا تحويل العديد من المفاهيم ذات الصلة إلى نموذج واحد معمم. القسم with ضروري لتحويل بعض السمات إلى التنسيق العام وإضافة السمات المفقودة. على سبيل المثال ، يمكن أن تكون البيانات المصدر وثائق من إصدارات مختلفة ، وقد تغيرت قائمة الحقول بمرور الوقت:
concept resume is resumeV1 with skills = 'N/A'
concept resume is resumeV2 r with skills = r.coreSkillsلنفترض أن الإصدار الأول من مفهوم "السيرة الذاتية" لم يكن له سمة ذات مهارات ، والإصدار الثاني كان له اسم مختلف.
توسيع قائمة السمات قد يكون مطلوبًا في كثير من الحالات. المهام الشائعة هي تغيير تنسيق السمات وإضافة السمات التي تعتمد وظيفيًا على السمات الموجودة أو البيانات الخارجية ، إلخ. على سبيل المثال:
concept price is basicPrice with valueUSD = valueEUR * getCurrentRate('USD', 'EUR')من الممكن أيضًا الجمع بين عدة مفاهيم تحت اسم واحد دون تغيير هيكلها. على سبيل المثال ، للإشارة إلى أنهم من نفس الجنس:
concept webPageElement is webPageLink
concept webPageElement is webPageInputأو قم بإنشاء مجموعة فرعية من المفهوم عن طريق تصفية بعض كياناته:
concept exceptionalPerformer is employee where performanceEvaluationScore > 0.95الوراثة المتعددة ممكنة أيضًا ، حيث يرث مفهوم الطفل سمات جميع المفاهيم الأبوية. إذا كانت هناك أسماء سمات متطابقة ، فستعطى الأولوية للمفهوم الرئيسي على يسار القائمة. يمكنك أيضًا حل هذا التعارض يدويًا عن طريق التجاوز الصريح للسمة المطلوبة في القسم
with. على سبيل المثال ، سيكون هذا النوع من الوراثة مناسبًا إذا كنت بحاجة إلى جمع عدة مفاهيم ذات صلة في بنية واحدة "مسطحة":
concept employeeInfo is employee e, department d where e.departmentId = d.id الميراث دون تغيير بنية المفاهيم يعقد التحقق من هوية الأشياء. كمثال ، ضع في اعتبارك تعريف الأداء الاستثنائي . ستُرجع الاستعلامات المتعلقة بالمفاهيم الأصل ( الموظف ) والفرع (الأداء الاستثنائي ) نفس كيان الموظف. ستكون الأشياء التي تمثلها متطابقة في المعنى. سيكون لديهم مصدر بيانات مشترك ، نفس القائمة وقيم السمات ، لاسم مفهوم مختلف ، اعتمادًا على المفهوم الذي تم إجراء الاستعلام عليه. لذلك ، يجب أن تأخذ عملية مساواة الكائن في الاعتبار هذه الميزة. تعتبر أسماء المفاهيم متساوية إذا كانت متطابقة أو مرتبطة بعلاقة وراثة متعدية دون تغيير البنية.
الوراثة هي آلية مفيدة تسمح لك بالتعبير صراحة عن العلاقات بين المفاهيم مثل الفئة الفرعية ، والخاصة المشتركة ، والمجموعة الفرعية. وتخلص أيضًا من الكود المكرر في تعريفات المفاهيم واجعل الكود أكثر قابلية للفهم. تعتمد آلية الوراثة على إضافة / إزالة السمات ، والجمع بين عدة مفاهيم تحت اسم واحد وإضافة شروط التصفية. لا توجد دلالات خاصة مضمنة فيه ، يمكن للجميع إدراكها وتطبيقها كما يريدون. على سبيل المثال، وبناء التسلسل الهرمي من خاص إلى عام، كما في الأمثلة مع المفاهيم الذاتية ، سعر و webPageElement . أو، على العكس، من العام إلى الخاص، كما في الأمثلة مع مفاهيم الإيرادات و exceptionalPerformer... سيسمح لك هذا بالتكيف بمرونة مع تفاصيل مصادر البيانات.
مفهوم لوصف العلاقات
تقرر أنه لتسهيل فهم الكود وتسهيل تكامل مكون النمذجة مع نموذج OOP ، يجب تضمين علاقة مفهوم الطفل مع الوالد في تعريفه. وبالتالي ، تحدد هذه العلاقات طريقة الحصول على مفهوم الطفل من الآباء. إذا كان نموذج المجال مبنيًا في طبقات ، وكل طبقة جديدة مبنية على الطبقة السابقة ، فهذا مبرر. لكن في بعض الحالات ، يجب الإعلان عن العلاقة بين المفاهيم بشكل منفصل ، وعدم تضمينها في تعريف أحد المفاهيم. يمكن أن تكون علاقة عالمية تريد تعريفها بشكل عام وتطبيقها على مفاهيم مختلفة ، على سبيل المثال ، العلاقة بين الوالدين والطفل. يجب تضمين إما علاقة تربط بين مفهومين في تعريف كلا المفهومين ، بحيث يكون من الممكن العثور على كل من جوهر المفهوم الأول مع السمات المعروفة للمفهوم الثاني ، والعكس صحيح.بعد ذلك ، لتجنب تكرار الكود ، سيكون من المناسب تعيين العلاقة بشكل منفصل.
في تعريف العلاقة ، من الضروري سرد المفاهيم المضمنة فيها وتعيين تعبير منطقي يربطها ببعضها البعض:
relation < >
between < > < > (
< > = <>,
...
),
...
where < >على سبيل المثال ، يمكن تعريف العلاقة التي تصف المستطيلات المتداخلة على النحو التالي:
relation insideSquareRelation between square inner, square outer
where inner.xLeft > outer.xLeft and inner.xRight < outer.xRight
and inner.yBottom > outer.yBottom and inner.yUp < outer.yUpهذه العلاقة ، في الواقع ، هي مفهوم شائع ، سماتها هي جوهر المفاهيم المتداخلة:
concept insideSquare (
inner = i
outer = o
) from square i, square o
where i.xLeft > o.xLeft and i.xRight < o.xRight
and i.yBottom > o.yBottom and i.yUp < o.yUpيمكن استخدام العلاقة في تعريفات المفاهيم جنبًا إلى جنب مع مفاهيم الوالدين الأخرى. سيتم الوصول إلى المفاهيم المدرجة في العلاقة من الخارج وستلعب دور سماتها. ستطابق أسماء السمات الأسماء المستعارة للمفهوم المتداخلة. يوضح المثال التالي أن نموذج HTML يتضمن عناصر HTML الموجودة بداخله على صفحة HTML:
oncept htmlFormElement is e
from htmlForm f, insideSquareRelation(inner = e, outer = f), htmlElement eعند البحث عن حل ، سيتم أولاً العثور على جميع قيم مفهوم htmlForm ، ثم سيتم ربطها بالمفهوم المتداخل الخارجي للعلاقة داخل مربع ويتم العثور على قيم السمة الداخلية الخاصة به . في النهاية ، سيتم تصفية القيم الداخلية المرتبطة بمفهوم htmlElement .
يمكن أيضًا إعطاء العلاقة دلالات وظيفية - يمكن استخدامها كدالة من النوع المنطقي للتحقق مما إذا كانت العلاقة راضية عن كيانات المفهوم المتداخلة المحددة:
oncept htmlFormElement is e
from htmlElement e, htmlForm f
where insideSquareRelation(e, f)على عكس الحالة السابقة ، هنا يتم التعامل مع العلاقة كدالة ، والتي ستؤثر على ترتيب الاستدلال. سيتم تأجيل تقييم الوظيفة حتى اللحظة التي ترتبط فيها جميع وسائطها بالقيم. أي ، أولاً ، سيتم العثور على جميع مجموعات قيم مفاهيم htmlElement و htmlForm ، ثم سيتم تصفية تلك التي لا تتوافق مع العلاقة insideSquareRelation . أخطط للتحدث بمزيد من التفصيل عن دمج نماذج البرمجة المنطقية والوظيفية في أحد المنشورات التالية.
حان الوقت الآن لإلقاء نظرة على مثال صغير.
تعريف الحقائق والأنواع الأساسية للمفاهيم كافية لتنفيذ المثال مع المدينين من المنشور الأول. لنفترض أن لدينا ملفين CSV يخزنان معلومات العميل (الرقم التعريفي للعميل والاسم وعنوان البريد الإلكتروني) والفواتير (معرف الحساب ومعرف العميل والتاريخ والمبلغ المستحق والمبلغ المدفوع).
وأيضًا هناك إجراء معين يقرأ محتويات هذه الملفات ويحولها إلى مجموعة من الحقائق:
fact cell {
table: “TableClients”,
value: 1,
rowNum: 1,
columnNum: 1
};
fact cell {
table: “TableClients”,
value: “John”,
rowNum: 1,
columnNum: 2
};
fact cell {
table: “TableClients”,
value: “john@somewhere.net”,
rowNum: 1,
columnNum: 3
};
…
fact cell {
table: “TableBills”,
value: 1,
rowNum: 1,
columnNum: 1
};
fact cell {
table: “TableBills”,
value: 1,
rowNum: 1,
columnNum: 2
};
fact cell {
table: “TableBills”,
value: 2020-01-01,
rowNum: 1,
columnNum: 3
};
fact cell {
table: “TableBills”,
value: 100,
rowNum: 1,
columnNum: 4
};
fact cell {
table: “TableBills”,
value: 50,
rowNum: 1,
columnNum: 5
};أولاً ، دعنا نعطي خلايا الجدول أسماء ذات معنى:
concept clientId is cell where table = “TableClients” and columnNum = 1;
concept clientName is cell where table = “TableClients” and columnNum = 2;
concept clientEmail is cell where table = “TableClients” and columnNum = 3;
concept billId is cell where table = “TableBills” and columnNum = 1;
concept billClientId is cell where table = “TableBills” and columnNum = 2;
concept billDate is cell where table = “TableBills” and columnNum = 3;
concept billAmountToPay is cell where table = “TableBills” and columnNum = 4;
concept billAmountPaid is cell where table = “TableBills” and columnNum = 5;يمكنك الآن دمج خلايا من صف واحد في كائن واحد:
concept client (
id = id.value,
name = name.value,
email = email.value
) from clientId id, clientName name, clientEmail email
where id.rowNum = name.rowNum = email.rowNum;concept bill (
id = id.value,
clientId = clientId.value,
date = date.value,
amountToPay = toPay.value,
amountPaid = paid.value
) from billId id, billClientId clientId, billDate date, billAmountToPay toPay, billAmountPaid paid
where id.rowNum = clientId.rowNum = date.rowNum = toPay.rowNum = paid.rowNum;دعونا نقدم مفهومي "الفاتورة غير المسددة" و "المدين":
concept unpaidBill is bill where amountToPay > amountPaid;
concept debtor is client c where exist(unpaidBill {clientId: c.id});كلا التعريفين يستخدمان الميراث ، والمفهوم unpaidBill هو مجموعة فرعية من قانون المفاهيم ، المدين - مفهوم العميل . يحتوي تعريف المدين على استعلام فرعي لمفهوم الفاتورة غير المسددة . سننظر بالتفصيل في آلية الاستعلامات المتداخلة لاحقًا في أحد المنشورات التالية.
كمثال على مفهوم "ثابت" ، سنقوم أيضًا بتعريف مفهوم "دين العميل" ، والذي نجمع فيه بعض الحقول من مفهومي "العميل" و "الحساب":
concept clientDebt (
clientName = c.name,
billDate = b.date,
debt = b. amountToPay – b.amountPaid
) from unpaidBill b, client c(id = b.client); الاعتماد بين سمات المفاهيم العميل و ومشروع قانون نقل إلى من القسم ، والتبعيات لمفهوم الطفل clientDebt - إلى قسم من خصائصه. إذا رغبت في ذلك ، يمكن وضعها جميعًا في قسم حيث - ستكون النتيجة هي نفسها. ولكن من وجهة نظري ، فإن الإصدار الحالي أكثر إيجازًا ويؤكد بشكل أفضل على الغرض من هذه التبعيات - لتحديد العلاقات بين المفاهيم.
الآن دعونا نحاول تحديد مفهوم المتخلف الضار الذي لديه على الأقل 3 فواتير غير مدفوعة على التوالي. للقيام بذلك ، تحتاج إلى علاقة تسمح لك بطلب فواتير عميل واحد حسب تاريخه. سيبدو التعريف العام كما يلي:
relation billsOrder between bill next, bill prev
where next.date > prev.date and next.clientId = prev.clientId and not exist(
bill inBetween
where next.clientId = inBetween.clientId
and next.date > inBetween.date > prev.date
);تنص على وجود فاتورتين متتاليتين إذا كانتا تنتمي إلى نفس العميل ، وأن تاريخ إحداهما أكبر من تاريخ الآخر ، ولا توجد فاتورة أخرى بينهما. في هذه المرحلة ، لا أريد أن أسهب في الحديث عن التعقيد الحسابي لمثل هذا التعريف. ولكن إذا علمنا ، على سبيل المثال ، أن جميع الفواتير تصدر بفاصل زمني مدته شهر واحد ، فيمكن تبسيطها إلى حد كبير:
relation billsOrder between bill next, bill prev
where next.date = prev.date + 1 month and next.clientId = prev.clientId;سيبدو تسلسل 3 فواتير غير مدفوعة كما يلي:
concept unpaidBillsSequence (clientId = b1.clientId, bill1 = b1, bill2 = b2, bill3 = b3)
from
unpaidBill b1,
billsOrder next1 (next = b1, prev = b2)
unpaidBill b2
billsOrder next2 (next = b2, prev = b3)
unpaidBill b3;في هذا المفهوم، لأول مرة سيتم العثور على جميع الفواتير غير المسددة، ثم الفاتورة القادمة سيتم العثور لكل منهما باستخدام next1 العلاقة . تسمح لك الفكرة b2 بالتحقق من أن هذه الفاتورة غير مدفوعة. وفقًا للمبدأ نفسه ، باستخدام next2 و b3 ، سيتم العثور على الفاتورة الثالثة غير المدفوعة على التوالي. تمت إضافة معرف العميل إلى قائمة السمات بشكل منفصل ، من أجل زيادة تسهيل ربط هذا المفهوم بمفهوم العملاء:
concept hardCoreDefaulter is client c where exist(unpaidBillsSequence{clientId: c.id});يوضح مثال المدين كيف يمكن وصف نموذج المجال بالكامل بأسلوب تعريفي. بالمقارنة مع تنفيذ هذا المثال في OOP أو النمط الوظيفي ، فإن الكود الناتج يكون موجزًا للغاية ومفهومًا وقريبًا من وصف المشكلة بلغة طبيعية.
استنتاجات موجزة.
لذلك ، اقترحت ثلاثة أنواع رئيسية من مفاهيم مكون نمذجة اللغة الهجينة:
- المفاهيم التي تم إنشاؤها على أساس تحويل المفاهيم الأخرى ؛
- المفاهيم التي ترث هيكل وعلاقات المفاهيم الأخرى ؛
- المفاهيم التي تحدد العلاقات بين المفاهيم الأخرى.
هذه الأنواع الثلاثة من المفاهيم لها أشكال وأغراض مختلفة ، لكن المنطق الداخلي لإيجاد الحلول هو نفسه بالنسبة لها ، فقط طريقة تشكيل قائمة السمات تختلف.
تعريفات المفاهيم تشبه استعلامات SQL - سواء في الشكل أو في منطق التنفيذ الداخلي. لذلك ، آمل أن تكون اللغة المقترحة مفهومة للمطورين وأن يكون لها حد دخول منخفض نسبيًا. وستسمح لك الميزات الإضافية مثل استخدام المفاهيم في تعريفات المفاهيم الأخرى ، والوراثة ، والعلاقات المشتقة ، والتعريفات العودية بتجاوز SQL وتسهيل هيكلة الكود وإعادة استخدامه.
على عكس RDF و OWL ، لا يميز مكون النمذجة بين المفاهيم والعلاقات - كل شيء هو مفاهيم. على عكس لغات منطق الإطار ، يتم دمج الإطارات التي تصف بنية المفهوم والقواعد التي تحدد الروابط فيما بينها معًا. على عكس لغات البرمجة المنطقية التقليدية مثل Prolog ، فإن العنصر الرئيسي للنموذج هو المفاهيم التي لها بنية موجهة للكائنات ، وليس القواعد التي لها بنية مسطحة. قد لا يكون تصميم اللغة هذا مناسبًا لإنشاء علم الوجود على نطاق واسع أو مجموعة من القواعد ، ولكنه أفضل بكثير للعمل مع البيانات شبه المنظمة ودمج مصادر البيانات المتباينة. مفاهيم مكون النمذجة قريبة من فئات نموذج OOP ، والتي يجب أن تسهل مهمة تضمين وصف تعريفي للنموذج في رمز التطبيق.
وصف مكون النمذجة لم يكتمل بعد. في المقالة التالية ، أخطط لمناقشة مثل هذه المشكلات من عالم منطق الكمبيوتر مثل المتغيرات المنطقية والنفي وعناصر المنطق الأعلى. ثم هناك تعريفات مفاهيم متداخلة ، وتجميعات ، ومفاهيم تنشئ كياناتها باستخدام وظيفة معينة.
يتوفر النص الكامل بأسلوب علمي باللغة الإنجليزية على العنوان: paper.ssrn.com/sol3/papers.cfm؟abstract_id=3555711
روابط إلى المنشورات السابقة:
تصميم لغة برمجة متعددة النماذج. الجزء 1 - ما الغرض منه؟
نصمم لغة برمجة متعددة النماذج. الجزء 2 - مقارنة بين نماذج البناء في PL / SQL و LINQ و GraphQL
نصمم لغة برمجة متعددة النماذج. الجزء 3 - نظرة عامة على لغات تمثيل المعرفة