1.1إنشاء التحليل: الملفات والبنود والروابط
الأساسي في 30 ثانية
- كل كيان مهني = ملف: العميل والمنتج والطلب تصبح ملفات في التحليل، وكل ملف لا يخلط إلا مفهومًا واحدًا.
- نوع البند أمر جوهري: التاريخ بنوع تاريخ، والمبلغ بنوع نقدي — لا شيء كله نص، وإلا صارت الفرزات والحسابات والرقابات خاطئة.
- لا تكرّر معلومة أبدًا: اسم العميل يعيش في ملف العميل وحده؛ والطلبات تشير إليه عبر رابط (مفتاح أجنبي).
حالة مصغّرة متسلسلة — ياسين يرسم تحليل تطبيق التجارة الخاص به
ياسين مطوّر WinDev في شركة صغيرة لتجارة العتاد الكهربائي بمدينة وهران. عليه تسليم تطبيق تسيير (عملاء، منتجات، طلبات، فواتير، مخزون). يبدأ بتعداد «أشياء» المهنة: العميل، والمنتج (كابل، قاطع، لوحة…)، والطلب وسطوره. يجعل من كل كيان ملفًا. ثم يصف البنود بالنوع المناسب: الاسم نصًا، وPrixUnitaireHT نقديًا، وDateCommande تاريخًا — لا كل شيء نصًا. ويعطي كل ملف مفتاحًا أساسيًا (معرّفًا تلقائيًا). وأخيرًا يرسم الرابط: العميل له عدة طلبات، والطلب ينتمي إلى عميل واحد. يهمّ بنسخ اسم العميل في كل طلب، ثم يتراجع: هذه المعلومة يجب أن تعيش مرة واحدة في ملف العميل. لقد بنى ياسين أساس تطبيقه: تحليلًا متناسقًا بلا تكرار.
حالة مستقلة لهذا القسم: تعود في الدرس والمخطّط والسكربت وتحدّي 48 ساعة للقسم 1.1.
1. من الكيانات إلى الملفات
منهجية التحليل هي نفسها دائمًا. أولًا تحديد الكيانات المهنية: «الأشياء» التي يتعامل معها التطبيق (العميل، المنتج، الطلب). كل كيان يصبح ملفًا. وهكذا ينشئ ياسين ملفات العميل والمنتج والطلب وسطر الطلب.
قاعدة بسيطة: كيان واحد = ملف واحد. لا نخلط مفهومين أبدًا في الملف نفسه — فالمنتج والطلب شيئان مختلفان، إذًا هما ملفان.
2. بنود ذات أنواع صحيحة
ثم نصف بنود كل ملف: المعلومات الأولية (الاسم، المدينة، PrixUnitaireHT، DateCommande). ولكل بند نختار اسمًا واضحًا ونوعًا مناسبًا وحجمًا.
اختيار النوع جوهري: التاريخ يُخزَّن بنوع تاريخ (لا نصًا)، والمبلغ بنوع نقدي (للحساب والفرز والتجميع). ووضع كل شيء نصًا يجعل الفرزات خاطئة والحسابات مستحيلة والرقابات معطّلة.
3. المفاتيح الأساسية والروابط
كل ملف يحتاج مفتاحًا أساسيًا: المعرّف الفريد لكل سجل. عمليًا نستخدم كثيرًا معرّفًا تلقائيًا يولّده المحرّك — بسيط وثابت وموثوق.
وأخيرًا نرسم الروابط التي تعبّر عن قواعد المهنة. وأكثرها شيوعًا واحد-إلى-متعدد (1,n): العميل له عدة طلبات. الملف في جهة «المتعدد» (الطلب) يحمل بندًا يشير إلى مفتاح الآخر: هو المفتاح الأجنبي. ثم تحدد قواعد التكامل سلوك الحذف (المنع أو الحذف المتسلسل) لحماية التناسق.
🔎 مثال ملموس — 🔎 مثال ملموس — تحليل « NegoceElec »
الهيكل العظمي للبيانات الذي يرسمه ياسين في محرّر التحليلات:
// Analyse "NegoceElec" — extrait
Client : IDClient (identifiant automatique), Nom, Ville, Telephone
Produit : IDProduit (auto), Libelle, Famille, PrixUnitaireHT (monétaire)
Commande : IDCommande (auto), IDClient (clé étrangère), DateCommande (date)
LigneCommande : IDLigne (auto), IDCommande, IDProduit, Quantite (entier), PrixHT
Liaison : Client (1) ──── (n) Commande // un client a plusieurs commandes
Règle d'intégrité : supprimer un client ayant des commandes → interditالقراءة: يحدد ياسين نوع كل بند (نقدي، تاريخ، صحيح) ويربط الطلب بالعميل عبر المفتاح IDClient، دون نسخ الاسم.
الانعكاس: كيان واحد = ملف واحد؛ معلومة واحدة = مكان واحد؛ والباقي يمرّ عبر الرابط.
مفردات القسم
- كيان → ملف
- كل «شيء» في المهنة (العميل، المنتج، الطلب) يصبح ملفًا في التحليل؛ كيان واحد = ملف واحد، دون خلط المفاهيم.
مثال بسيط: ينشئ ياسين ملف العميل وملف المنتج وملف الطلب.
ما ليس كذلك: وضع كل شيء في ملف واحد «متنوّع» يخلط العملاء والمنتجات.
رد فعل: مفهوم مهني → ملف.
- البند والنوع
- معلومة أولية في ملف (الاسم، السعر، التاريخ)، تُعلَن باسم واضح ونوع مناسب وحجم معقول.
مثال بسيط: يخزّن ياسين PrixUnitaireHT نقديًا وDateCommande تاريخًا.
ما ليس كذلك: تخزين سعر وتاريخ نصًا، ثم محاولة الحساب أو الفرز.
رد فعل: نوع صحيح → حسابات وفرزات صحيحة.
- المفتاح الأساسي
- بند يميّز كل سجل بشكل فريد وثابت؛ عمليًا معرّف تلقائي يولّده المحرّك.
مثال بسيط: يعطي ياسين ملف العميل معرّف IDClient تلقائيًا.
ما ليس كذلك: استخدام رمز مهني متغير (بريد إلكتروني، رمز عميل يُعاد ترقيمه) كمفتاح.
رد فعل: مفتاح أساسي → معرّف تلقائي.
- رابط 1,n (واحد إلى متعدد)
- العلاقة الأكثر شيوعًا: العميل له عدة طلبات، والطلب ينتمي إلى عميل واحد؛ وجهة «المتعدد» تحمل المفتاح الأجنبي.
مثال بسيط: رابط العميل (1,n) الطلب عبر IDClient يحمل قاعدة المهنة لدى ياسين.
ما ليس كذلك: نسخ اسم العميل في كل طلب بدل الربط.
رد فعل: ملفان مترابطان → مفتاح أجنبي، لا نسخ.
- قاعدة التكامل
- سلوك المحرّك عند حذف أو تعديل سجل مرتبط (المنع، الحذف المتسلسل)، لحماية التناسق.
مثال بسيط: يمنع ياسين حذف عميل لا يزال لديه طلبات.
ما ليس كذلك: السماح بحذف عميل وترك طلبات يتيمة.
رد فعل: حذف مرتبط → قاعدة تكامل.
في التطبيق — عمليًا — بناء تحليل العميل / الطلب
- عدّد كيانات المهنة وأنشئ ملفًا لكل واحدة (العميل، المنتج، الطلب، سطر الطلب).
- صف البنود بالنوع المناسب (نص للاسم، تاريخ للتاريخ، نقدي للسعر) وحجم معقول.
- أعط كل ملف مفتاحًا أساسيًا (يفضَّل معرّف تلقائي).
- ارسم الروابط وفق قواعد المهنة (عميل → عدة طلبات)، وحدد قواعد التكامل، ثم ولّد التحليل.
سكربت خطوة بخطوة — ارسم التحليل كما يفعل ياسين (5 دقائق)
1) عدّد كيانات التجارة (العميل، المنتج، الطلب، سطر الطلب) وأنشئ ملفًا لكل كيان. 2) صف البنود بالنوع المناسب (الاسم نصًا، PrixUnitaireHT نقديًا، DateCommande تاريخًا). 3) أضف مفتاحًا أساسيًا لكل ملف (معرّف تلقائي). 4) ارسم رابط العميل (1) → الطلب (n) مع IDClient كمفتاح أجنبي، دون نسخ اسم العميل. 5) اضبط قواعد التكامل ثم ولّد التحليل.
احتفظ بهذا التحليل: سيتغذى منه النوافذ (1.2)، وWLangage (1.3)، والحقول المرتبطة (1.4)، وRAD (1.5).
نموذج للنسخ واللصق — قائمة تحقّق التحليل عند ياسين
[ ] Un fichier par entité métier (Client, Produit, Commande…)
[ ] Rubriques nommées clairement et bien TYPÉES (date, monétaire…)
[ ] Une clé primaire par fichier (identifiant automatique de préférence)
[ ] Aucune information répétée d'un fichier à l'autre
[ ] Liaisons tracées (Client 1,n Commande via clé étrangère)
[ ] Règles d'intégrité décidées (suppression interdite / en cascade)
[ ] Analyse généréeهيكل صغير
يبدأ ياسين بثلاثة ملفات (العميل، المنتج، الطلب) ويحافظ مع ذلك على مفتاح أساسي ورابط نظيفين.
سطور الطلب
لتسيير عدة منتجات في الطلب الواحد، يضيف ياسين سطر الطلب، مرتبطًا بالطلب وبالمنتج معًا.
مفتاح مهني
حين تفرض الإدارة مرجعًا رسميًا للمنتج، يحتفظ به ياسين بندًا مفهرسًا لكنه يُبقي المعرّف التلقائي مفتاحًا أساسيًا.
تكامل صارم
في المخزون، يمنع ياسين حذف منتج لا يزال مذكورًا في سطر طلب.
✓ ممارسات جيدة
- ملف واحد لكل كيان مهني، دون خلط المفاهيم.
- حدّد نوع البنود دائمًا (تاريخ، نقدي، صحيح).
- خزّن كل معلومة مرة واحدة واربطها برابط.
✗ أخطاء شائعة
- نسخ بيان (اسم العميل) في عدة ملفات.
- وضع كل شيء نصًا: فرزات خاطئة وحسابات مستحيلة.
- اختيار مفتاح أساسي غير ثابت (رمز مهني متغيّر).
النقاط الأساسية
- المنهجية: تحديد الكيانات (→ ملفات)، وصف البنود (اسم + نوع + حجم)، تعريف المفتاح الأساسي، رسم الروابط، ثم توليد التحليل.
- اختيار النوع جوهري: تاريخ بتاريخ، ومبلغ بنقدي — لا نصًا أبدًا.
- الرابط الأكثر شيوعًا هو واحد-إلى-متعدد (1,n)؛ وجهة «المتعدد» تحمل المفتاح الأجنبي، وقواعد التكامل تحمي التناسق.
- مبدأ أساسي: لا تكرّر معلومة أبدًا؛ بل يُشار إليها بالرابط.
تحدي 48 ساعة — طبّقه غدًا
خذ مجالًا تعرفه (أو تجارة ياسين) وارسم تحليله: عدّد الكيانات، وأنشئ ملفًا لكل واحدة، وحدد أنواع البنود، وأضف مفتاحًا أساسيًا، وارسم على الأقل رابط 1,n. اكتب في جملة واحدة لماذا لا ننسخ معلومة من ملف إلى آخر أبدًا.
- أستطيع تحويل الكيانات المهنية إلى ملفات تحليل.
- أعرف كيف أحدد أنواع البنود وأختار مفتاحًا أساسيًا.
- أعرف كيف أرسم رابط 1,n دون تكرار أي معلومة.
أسئلة شائعة
لماذا يجب ألا نكرّر معلومة في عدة ملفات؟
لأن كل بيان مكرّر ينتهي إلى التباعد: يُعدَّل في مكان ولا يُعدَّل في آخر، فينتج تضارب ومجاميع خاطئة وأخطاء صعبة الإصلاح. إذا خُزّن اسم عميل في ملف العميل ونُسخ في كل طلب، فإن تغيير الاسم يفرض التحديث في كل مكان — ونسيان واحد يعرض اسمين مختلفين للعميل نفسه. ودور الروابط تحديدًا هو تجنّب هذا التكرار: المعلومة تعيش مرة واحدة، والملفات الأخرى تشير إليها بالمفتاح.
هل يلزم مفتاح تلقائي أم مفتاح «مهني»؟
فضّل المعرّف التلقائي في الغالب: فهو فريد بحكم التصميم، وثابت (لا معنى مهني له، لذا لا سبب لتغييره)، وفعّال للفهارس والربط. أما المفاتيح «المهنية» (رمز العميل، البريد الإلكتروني، المرجع) فتبدو عملية لكنها تتغيّر، وقد تتكرر أو تغيب عند الإنشاء — وتعديل مفتاح أساسي يفرض عكس التغيير في كل الملفات المرتبطة. بالنسبة إلى ياسين، المعرّف التلقائي هو المفتاح الافتراضي.
أي مبدأ أساسي نلتزم به عند إنشاء تحليل؟