تهدف هذه الوحدة إلى شرح مفهوم التوحيد (Normalization) في قواعد البيانات العلائقية، وكيفية استخدامه لتقليل التكرار، منع حالات الشذوذ، وتحسين سلامة البيانات.
تهدف هذه الوحدة إلى شرح مفهوم التوحيد (Normalization) في قواعد البيانات العلائقية، وكيفية استخدامه لتقليل التكرار، منع حالات الشذوذ، وتحسين سلامة البيانات.
التوحيد (Normalization) هو عملية أساسية في تصميم قواعد البيانات العلائقية. تُعتبر أداة منهجية لتقليل التكرار وتحسين سلامة البيانات.
التوحيد هو عملية تنظيم الجداول (العلاقات) في قاعدة البيانات لتقليل التكرار (Redundancy) ومنع التناقضات (Inconsistencies) وحالات الشذوذ (Anomalies) التي تحدث عند إدخال أو تحديث أو حذف البيانات.
يتم تحقيق التوحيد من خلال تحويل الجداول إلى أشكال طبيعية (Normal Forms) مختلفة، كل شكل منها يتبع مجموعة محددة من القواعد بناءً على الاعتماديات الوظيفية التي تعلمناها في الوحدة السابقة.
النماذج الموحدة (Normal Forms) هي مجموعة من الإرشادات أو الشروط التي يجب أن تستوفيها الجداول لتقييم مدى توحيدها. كل شكل طبيعي يمثل مستوى أعلى من التنظيم ويُقلل من التكرار وحالات الشذوذ بشكل أكبر.
فيما يلي أبرز النماذج الموحدة التي تُطبق بشكل شائع:
هو المستوى الأساسي للتطبيع. يجب أن يفي كل جدول في قاعدة البيانات بهذا الشكل الطبيعي ليعتبر "علائقياً" بالمعنى الحقيقي.
StudentID |
Name |
Courses |
|---|---|---|
1 |
علي | رياضيات، فيزياء |
2 |
سارة | كيمياء |
المشكلة هنا هي أن الحقل Courses يحتوي على قيم متعددة ("رياضيات، فيزياء") في صف واحد.
لتطبيع هذا الجدول إلى 1NF، نقوم بتفكيك القيم المتعددة إلى صفوف منفصلة، مع تكرار بيانات الطالب لكل مقرر:
StudentID |
Name |
Course |
|---|---|---|
1 |
علي | رياضيات |
1 |
علي | فيزياء |
2 |
سارة | كيمياء |
الآن، كل حقل يحتوي على قيمة واحدة. المفتاح الأساسي للجدول الجديد سيكون المفتاح المركب (StudentID, Course).
يُعالج 2NF مشاكل الاعتماديات الجزئية (Partial Dependencies) التي تحدث عندما تعتمد سمات غير رئيسية على جزء فقط من المفتاح الرئيسي المركب.
تخيل جدول Student_Course_Info لتسجيل الطلاب في المقررات، مع معلومات إضافية عن الطالب والمقرر:
StudentID |
CourseID |
StudentName |
CourseName |
Instructor |
|---|---|---|---|---|
101 |
CS101 |
أحمد | مقدمة في البرمجة | د. سعيد |
102 |
DB201 |
سارة | قواعد البيانات | د. ليلى |
101 |
MA101 |
أحمد | حساب التفاضل | د. نورا |
المفتاح الرئيسي المركب هو (StudentID, CourseID).
المشكلة هنا:
StudentName يعتمد فقط على StudentID (جزء من المفتاح المركب).CourseName وInstructor يعتمدان فقط على CourseID (جزء آخر من المفتاح المركب).لفصل الاعتماديات الجزئية، نقوم بتقسيم الجدول إلى جداول منفصلة:
Students):StudentID (PK) |
StudentName |
|---|---|
101 | أحمد |
102 | سارة |
Courses):CourseID (PK) |
CourseName |
Instructor |
|---|---|---|
CS101 | مقدمة في البرمجة | د. سعيد |
DB201 | قواعد البيانات | د. ليلى |
MA101 | حساب التفاضل | د. نورا |
Enrollment) (الجدول الوسيط):StudentID (FK) |
CourseID (FK) |
(PK المركب) |
|---|---|---|
101 | CS101 | |
102 | DB201 | |
101 | MA101 |
الآن، جميع السمات غير الرئيسية (لا توجد هنا في جدول Enrollment) تعتمد بشكل كامل على المفتاح الرئيسي المركب (StudentID, CourseID).
-- إنشاء جدول الطلاب
CREATE TABLE Students (
StudentID INT PRIMARY KEY,
StudentName VARCHAR(100) NOT NULL
);
-- إنشاء جدول المقررات
CREATE TABLE Courses (
CourseID VARCHAR(10) PRIMARY KEY,
CourseName VARCHAR(100) NOT NULL,
Instructor VARCHAR(100)
);
-- إنشاء جدول التسجيل (للعلاقة M:N بين الطلاب والمقررات)
CREATE TABLE Enrollment (
StudentID INT,
CourseID VARCHAR(10),
PRIMARY KEY (StudentID, CourseID), -- مفتاح رئيسي مركب
FOREIGN KEY (StudentID) REFERENCES Students(StudentID),
FOREIGN KEY (CourseID) REFERENCES Courses(CourseID)
);
يُعالج 3NF مشاكل الاعتماديات الانتقالية (Transitive Dependencies) التي تحدث عندما تعتمد سمة غير رئيسية على سمة غير رئيسية أخرى.
تخيل جدول Employees_Departments:
EmployeeID |
EmployeeName |
DepartmentID |
DepartmentName |
DepartmentLocation |
|---|---|---|---|---|
101 |
علي | D01 |
الموارد البشرية | الرياض |
102 |
سارة | D02 |
التسويق | جدة |
103 |
فهد | D01 |
الموارد البشرية | الرياض |
المفتاح الرئيسي هو EmployeeID.
المشكلة هنا:
EmployeeID $\rightarrow$ DepartmentIDDepartmentID $\rightarrow$ DepartmentName و DepartmentID $\rightarrow$ DepartmentLocationEmployeeID $\rightarrow$ DepartmentName و EmployeeID $\rightarrow$ DepartmentLocation بشكل انتقالي عبر DepartmentID.DepartmentName وDepartmentLocation يعتمدان على DepartmentID، وDepartmentID ليست المفتاح الرئيسي للجدول.لفصل الاعتماديات الانتقالية، نقوم بتقسيم الجدول إلى جداول منفصلة:
Employees):EmployeeID (PK) |
EmployeeName |
DepartmentID (FK) |
|---|---|---|
101 | علي | D01 |
102 | سارة | D02 |
103 | فهد | D01 |
Departments):DepartmentID (PK) |
DepartmentName |
DepartmentLocation |
|---|---|---|
D01 | الموارد البشرية | الرياض |
D02 | التسويق | جدة |
الآن، كل سمة غير رئيسية في جدول Employees (مثل EmployeeName) تعتمد مباشرة على المفتاح الرئيسي EmployeeID. ومعلومات القسم موجودة في جدول منفصل.
-- إنشاء جدول الأقسام
CREATE TABLE Departments (
DepartmentID VARCHAR(10) PRIMARY KEY,
DepartmentName VARCHAR(100) NOT NULL,
DepartmentLocation VARCHAR(100)
);
-- إنشاء جدول الموظفين
CREATE TABLE Employees (
EmployeeID INT PRIMARY KEY,
EmployeeName VARCHAR(100) NOT NULL,
DepartmentID VARCHAR(10),
FOREIGN KEY (DepartmentID) REFERENCES Departments(DepartmentID)
);
يُعتبر BCNF شكلاً طبيعيًا أكثر صرامة من 3NF، ويُعالج بعض الحالات الخاصة التي قد تسبب مشاكل في 3NF، خاصة عندما يكون هناك تداخل بين المفاتيح المحتملة (Candidate Keys).
X مفتاحًا فائقًا (Super Key). المفتاح الفائق هو أي مجموعة من السمات التي تُحدد بشكل فريد كل صف في الجدول (بما في ذلك المفتاح الرئيسي).Course_Instructor_Student
تخيل جدولاً يسجل المقررات، المدرسين الذين يدرسونها، والطلاب المسجلين. (هذا مثال كلاسيكي يُستخدم لشرح BCNF)
StudentID |
Course |
Instructor |
|---|---|---|
| 1 | قواعد بيانات | أحمد |
| 2 | قواعد بيانات | أحمد |
| 3 | ذكاء اصطناعي | سارة |
| 1 | ذكاء اصطناعي | سارة |
الاعتماديات المفترضة:
(StudentID, Course) $\rightarrow$ Instructor (الجمع بين الطالب والمقرر يحدد المدرس – لأن الطالب يسجل في مقرر، والمقرر يدرسه مدرس واحد). هذا هو المفتاح الرئيسي.Instructor $\rightarrow$ Course (كل مدرس يدرس مقررًا واحدًا فقط). هذه هي المشكلة: Instructor ليس مفتاحًا فائقًا، لكنه يحدد Course.الجدول في 3NF (لا توجد اعتماديات جزئية أو انتقالية بالنسبة للمفتاح الرئيسي المركب). لكنه ليس في BCNF لأن Instructor (المُحدِّد) ليس مفتاحًا فائقًا.
نفصل الجدول إلى جدولين:
Enrollment (التسجيل):StudentID (PK جزء) |
Course (PK جزء) |
|---|---|
| 1 | قواعد بيانات |
| 2 | قواعد بيانات |
| 3 | ذكاء اصطناعي |
| 1 | ذكاء اصطناعي |
Course_Taught_By (المقررات التي يدرسها المدرسون):Instructor (PK) |
Course |
|---|---|
| أحمد | قواعد بيانات |
| سارة | ذكاء اصطناعي |
الآن، كل الاعتماديات في كلا الجدولين تعتمد على مفتاح فائق. في جدول Course_Taught_By، Instructor هو المفتاح الرئيسي وبالتالي مفتاح فائق.
التوحيد ليس مجرد مجموعة من القواعد النظرية؛ بل هو عملية عملية وحاسمة في تصميم قواعد البيانات ذات الكفاءة العالية والموثوقية.
| المصطلح (الإنجليزية) | المصطلح (العربية) | التعريف |
|---|---|---|
| Normalization | التوحيد | عملية تنظيم الجداول في قاعدة البيانات لتقليل التكرار ومنع التناقضات وحالات الشذوذ. |
| Normal Form (NF) | الشكل الطبيعي | مجموعة من القواعد التي يجب أن يلتزم بها الجدول لتقييم مدى توحيده. |
| 1NF (First Normal Form) | النموذج الموحد الأول | شرطه أن كل حقل يحتوي على قيمة واحدة فقط، وكل صف فريد (ذرية القيم وعدم تكرار الصفوف). |
| 2NF (Second Normal Form) | النموذج الموحد الثاني | شرطه أن يكون الجدول في 1NF، ولا وجود لاعتمادية جزئية على جزء من المفتاح المركب. |
| 3NF (Third Normal Form) | النموذج الموحد الثالث | شرطه أن يكون الجدول في 2NF، ولا وجود لاعتمادية انتقالية بين الحقول غير المفتاحية. |
| BCNF (Boyce-Codd Normal Form) | نموذج بويس-كود الموحَّد | شرطه أن يكون الجدول في 3NF، ولكل اعتماد وظيفي X → Y، يجب أن يكون X مفتاحًا فائقًا. |
| Redundancy | التكرار | وجود نفس البيانات في أكثر من مكان داخل قاعدة البيانات. |
| Anomaly | شذوذ / حالة شاذة | مشكلة تحدث في قاعدة البيانات بسبب سوء التصميم (مثل مشاكل الإدخال، التحديث، الحذف). |
| Insertion Anomaly | حالة الإدخال الشاذة | صعوبة إدخال بيانات جديدة بسبب تصميم غير صحيح. |
| Update Anomaly | حالة التحديث الشاذة | تضارب أو فقدان التناسق عند تعديل البيانات المتكررة. |
| Deletion Anomaly | حالة الحذف الشاذة | فقدان بيانات أخرى مهمة (غير مستهدفة بالحذف) عند حذف سجل. |
| Functional Dependency (FD) | الاعتمادية الوظيفية | علاقة بين مجموعتين من الحقول حيث تحدد مجموعة القيم في الأخرى. |
| Partial Dependency | اعتمادية جزئية | اعتماد سمة غير رئيسية على جزء فقط من المفتاح الرئيسي المركب. |
| Transitive Dependency | اعتمادية انتقالية | اعتماد سمة غير رئيسية على سمة غير رئيسية أخرى في نفس الجدول. |
| Super Key | مفتاح فائق | أي مجموعة من السمات التي يمكنها تعريف كل سجل بشكل فريد (بما في ذلك المفتاح الرئيسي). |
اختبر فهمك لمفاهيم هذه الوحدة بالإجابة على الأسئلة التالية:
Student_Course_Grade_Instructor_Dept يحتوي على الأعمدة التالية: StudentID, StudentName, CourseID, CourseName, InstructorName, InstructorDept, Grade.
StudentID $\rightarrow$ StudentNameCourseID $\rightarrow$ CourseNameInstructorName $\rightarrow$ InstructorDept(StudentID, CourseID) $\rightarrow$ GradeCourseID $\rightarrow$ InstructorName (كل مقرر يدرسه مدرس واحد فقط)ProjectID |
ProjectName |
StudentID |
StudentName |
Advisor |
AdvisorDept |
|---|---|---|---|---|---|
| P1 | المكتبة الرقمية | S1 | ليلى | د. ناصر | علوم حاسب |
| P1 | المكتبة الرقمية | S2 | أحمد | د. ناصر | علوم حاسب |
| P2 | نظام إدارة المستشفى | S3 | فاطمة | د. سارة | نظم معلومات |
الاعتماديات المفترضة:
ProjectID $\rightarrow$ ProjectNameStudentID $\rightarrow$ StudentNameAdvisor $\rightarrow$ AdvisorDept(ProjectID, StudentID) هو المفتاح الرئيسي.