لوحة المتصدرين

الاعتمادية الوظيفية functional dependency -أو FD اختصارًا- هي علاقة بين سمتَين attributes، حيث تكون عادةً بين المفتاح الرئيسي PK والسمات الأخرى التي ليست مفاتيحًا non-key attributes داخل الجدول، إذ تعتمد السمة Y وظيفيًا على السمة X -والتي تُعَد مفتاحًا رئيسيًا PK- في علاقة R إذا حدّدت قيمةُ السمة X قيمةَ السمة Y بصورةٍ فريدة لكل نسخةٍ صالحة من السمة X، ويشار إلى هذه العلاقة من خلال التمثيل التالي: X ———–> Y يسمى الجانب الأيسر من مخطط الاعتمادية الوظيفية FD السابق بالمحدِّد determinant، ويسمى الجانب الأيمن بالاعتمادي dependent، وفيما يلي بعض الأمثلة على ذلك. تحدِّد السمة SIN الاسم Name، والعنوان Address، وتاريخ الميلاد Birthdate في المثال الأول أدناه، حيث يمكننا تحديد أي من السمات الأخرى داخل الجدول باستخدام السمة SIN. SIN ———–> Name, Address, Birthdate تحدِّد السمتان SIN، وCourse تاريخ الانتهاء DateCompleted في المثال الثاني، حيث يجب أن يعمل هذا أيضًا مع مفتاح رئيسي مركّّب composite PK. SIN, Course ———–> DateCompleted يشير المثال الثالث إلى أن السمة ISBN تحدّد العنوان Title. ISBN ———–> Title قواعد الاعتماديات الوظيفية انظر إلى جدول البيانات (r(R لمخطط العلاقة (R(ABCDE الموضَّح في الشكل التالي: قد تسأل نفسك عند النظر إلى هذا الجدول: ما نوع الاعتماديات التي يمكننا ملاحظتها بين السمات في الجدول R؟ بما أنّ قيم السمة A فريدة (a1, a2, a3, etc)، فيمكن القول اعتمادًا على تعريف الاعتمادية الوظيفية FD أنّ: A → B, A → C, A → D, A → E ويترتب على ذلك أيضًا أن A → BC، أو أي مجموعة فرعية أخرى من المجموعة ABCDE. يمكن تلخيص ذلك على أساس A → BCDE. تُعَدّ السمة A مفتاحًا رئيسيًا. بما أن قيم السمة E هي نفسها دائمًا أي كلها لها القيمة e1، فهذا يعني أنّ: A → E, B → E, C → E, D → E ولكن لا يمكننا تلخيص ما سبق باستخدام ABCD → E، وذلك لأنّ: A → E, B → E, AB → E ملاحظات أخرى: تركيبات BC فريدة، لذلك BC → ADE. تركيبات BD فريدة، لذلك BD → ACE. إذا كانت قيم السمة C متطابقة، فإن قيم السمة D متطابقة كذلك. لذلك C → D. ولكن لا تحدِّد قيم السمة D قيم السمة C. لذلك لا تحدّد السمة C السمة D، ولا تحدِّد السمة D السمة C. يمكن مساعدة النظر إلى البيانات الفعلية في توضيح السمات التي هي سمات اعتمادية dependent، والسمات التي هي سمات محدِّدة determinant. قواعد الاستدلال Inference Rules تُعَدّ بديهيات أرمسترونغ Armstrong’s axioms مجموعةً من قواعد الاستدلال المستخدَمة لاستنتاج جميع الاعتماديات الوظيفية في قاعدة بيانات علائقية، حيث طوَّر ويليام أرمسترونغ William W. Armstrong هذه البديهيات. لنفترض أنّ (R(U هو مخطط علاقة لمجموعة سمات U، حيث سنستخدم الأحرف X، وY، وZ لتمثيل أي مجموعة فرعية، أو اتحاد union مجموعتين من السمات اختصارًا، بدلًا من استخدام X U Y. بديهية الانعكاس Axiom of reflexivity تنص هذه البديهية على أنه إذا كانت Y مجموعة فرعية subset من X، فإنّ X تحدِّد Y، كما في الشكل التالي: افترض الاعتمادية الوظيفية PartNo —> NT123 على سبيل المثال، حيث تتركّب (X (PartNo من معلومات متعددة، وهي: (Y (NT، و(partID (123. بديهية الزيادة Axiom of augmentation تنص بديهية الزيادة -والمعروفة باسم الاعتمادية الجزئية partial dependency أيضًا- على أنه إذا كانت X تحدِّد Y، فإنّ XZ تحدد YZ مهما كانت Z، أي كما في الشكل التالي: تنص بديهية الزيادة على أن يجب على كل سمة ليست مفتاحًا non-key attribute الاعتماد على المفتاح الرئيسي PK بصورة كاملة، فمثلًا، تعتمد السمات التالية: اسم الطالب StudentName، والعنوان Address، والمدينة City، وProv، وPC -أي الرمز البريدي postal code- على سمة رقم الطالب StudentNo فقط، ولا تعتمد على السمتين StudentNo، وGrade معًا. StudentNo, Course —> StudentName, Address, City, Prov, PC, Grade, DateCompleted هذا الوضع غير مرغوب به لأنه يجب على كل سمة ليست مفتاحًا الاعتماد على المفتاح PK بصورةٍ كاملة، ولكن تعتمد معلومات الطلاب في هذه الحالة جزئيًا فقط على المفتاح الرئيسي PK أي StudentNo. يجب إصلاح هذه المشكلة من خلال تقسيم الجدول الأصلي إلى جدولين على النحو التالي: الجدول الأول 1: يحوي الحقول التالية: StudentNo. Course. Grade. DateCompleted. الجدول الثاني 2: ويحوي الحقول التالية: StudentNo. StudentName. Address. City. Prov. PC. البديهية المتعدية Axiom of transitivity تنص البديهية المتعدِّية على أنه إذا كانت X تحدِّد Y، وY تحدِّد Z، فإنّ X تحدِّد Z أيضًا، أي كما في الشكل التالي: يحتوي الجدول أدناه على معلومات غير مرتبطة مباشرةً بالطالب، فيجب أن يكون لمعرِّف البرنامج ProgramID، واسم البرنامج ProgramName جدولًا خاصًا بهما، حيث لا يعتمد اسم البرنامج على رقم الطالب، وإنما يعتمد على معرِّف البرنامج. StudentNo —> StudentName, Address, City, Prov, PC, ProgramID, ProgramName هذه الحالة غير مرغوب بها بسبب اعتماد السمة التي ليست مفتاحًا -أي ProgramName- على سمة أخرى ليست مفتاحًا أيضًا -أي ProgramID-. نحل هذه المشكلة من خلال تقسيم هذا الجدول إلى جدولين: جدول لمعلومات الطالب، والآخر لمعلومات البرنامج، أي كما يلي: الجدول 1: StudentNo —> StudentName, Address, City, Prov, PC, ProgramID الجدول 2: ProgramID —> ProgramName لكن لا نزال بحاجة إلى مفتاح خارجي FK في جدول الطالب لنتمكن من تحديد البرنامج الذي سُجِّل الطالب به. الاتحاد Union تشير هذه القاعدة إلى أنه إذا كان جدولان منفصلان، والمفتاح الرئيسي PK هو نفسه، فقد ترغب في وضع الجدولين معًا، حيث تنص هذه القاعدة على أنه إذا كانت X تحدِّد Y، وX تحدِّد Z، فيجب على X أن تحدِّد Y وZ أيضًا، أي كما في الشكل التالي: افترض على سبيل المثال أنّ: SIN —> EmpName SIN —> SpouseName قد ترغب في ضم هذين الجدولين في جدول واحد على النحو التالي: SIN –> EmpName, SpouseName قد يختار بعض مسؤولي قاعدة البيانات database administrators -أو DBA اختصارًا- الاحتفاظ بهذه الجداول مفصولةً لسببين، هما: السبب الأول هو أنّ كل جدول يصِف كيانًا مختلفًا، لذلك يجب إبقاء الكيانات منفصلةً عن بعضها البعض، والسبب الثاني هو إذا تُرِك اسم الزوج/ـة SpouseName فارغًا NULL في معظم الأوقات، فلا حاجة إلى تضمينه في نفس جدول اسم الموظّف EmpName. التفكك Decomposition التفكُّك Decomposition هو عكس قاعدة الاتحاد Union، فإذا كان لديك جدولًا يبدو أنه يحتوي على كيانين يحدِّدهما المفتاح الرئيسي PK نفسه، فستفكِّر في تقسيمه إلى جدولين، حيث تنص هذه القاعدة على أنه إذا كانت X تحدِّد Y وZ، فستكون X تحدِّد Y، وX تحدِّد Z بصورةٍ منفصلة، أي كما في الشكل التالي: مخطط الاعتمادية Dependency Diagram يوضِّح مخطط الاعتمادية والمبيَّن في الشكل الآتي العديد من الاعتماديات المختلفة التي قد تكون موجودةً في جدول لم تطبَّقٍ عليه عملية التوحيد non-normalized table، أي الجدول الذي يحتوي على تكرار بيانات. تُحدَّد الاعتماديات التالية في هذا الجدول كما يلي: يتألف المفتاح الأساسي من مجموع ProjectNo وEmpNo. الاعتماديات الجزئية PDs: ProjName <— ProjectNo. EmpName, DeptNo <— EmpNo. HrsWork <— ProjectNo, EmpNo. الاعتمادية المتعددية Transitive Dependency: DeptName <—DeptNo. ترجمة -وبتصرف- للمقال Functional Dependencies لصاحبته Adrienne Watt. اقرأ أيضًا المقال التالي: فهم عملية التوحيد Normalization المستخدمة عند تصميم قاعدة البيانات المقال السابق: نمذجة الكيان العلاقي ER عند تصميم قواعد البيانات قواعد السلامة وقيودها لضمان سلامة البيانات في قواعد البيانات المفاهيم الأساسية في قواعد البيانات وتصميمها النسخة العربية الكاملة لكتاب تصميم قواعد البيانات