Normalization

Read If you want

Normal Forms in DBMS - GeeksforGeeks

Database Anomalies

المشاكل اللي في الغالب هتبقا موجودة في الـ Database لو هي مش Well designed. المشاكل دي بتتقسم لـ:

الـInsertion Anomaly: لما تبقى عايز تضيف بيانات جديدة ومش قادر علشان ناقصة معلومات.
الـUpdate Anomaly: لما تعدل جزء معين والبيانات التانية المرتبطة بيه تفضل زي ما هي (متتغيرش في الجدول كله).
الـDeletion Anomaly: لو مسحت حاجة فيه حاجة تانية هتتمسح خالص ومش هتبقا موجودة وهي ملهاش علاقة بالموضوع.

Functional Dependency (الاعتمادية الوظيفية)

تعريف:

الـ Functional Dependency بتحصل لما تكون قيمة عمود (Attribute) معتمدة بشكل واضح على عمود آخر.
بنرمز لها بالشكل: A → B
يعني العمود B بيعتمد على العمود A.

أنواع Functional Dependency

1. Full Dependency

العلاقة بتحصل لما العمود يعتمد بالكامل على المفتاح الأساسي (Primary Key).
مثال:
في جدول الطلاب:

Student ID	Course	Score
1	Math	90

الـScore بيعتمد على المفتاح المركب (Student ID, Course).

2. Partial Dependency

بيحصل لما العمود يعتمد على جزء من المفتاح الأساسي، مش عليه بالكامل.
لو الـ Key مش Composite فمينفعش يبقا فيه Partial.
مثال:
في جدول الطلاب والمدرسين:

Student ID	Course	Instructor
1	Math	Bob

الـInstructor بيعتمد على Course فقط، مش على (Student ID, Course).

3. Transitive Dependency

العمود يعتمد على عمود وسيط اللي بيعتمد بدوره على المفتاح الأساسي.
مثال:
في جدول الموظفين:

Employee ID	Department	Manager
1	IT	Ahmed

الـManager بيعتمد على Department، وDepartment بيعتمد على Employee ID.

الهدف:

نتجنب Partial وTransitive Dependency لأنها تسبب مشاكل في التصميم.
الحل: فصل الجداول لتبسيط العلاقات وتحسين التنظيم باستخدام التطبيع (Normalization).

إيه هو Normalization؟

The process of taking a table through a series of tests (Normal Forms) to certify the goodness of a schema design, minimize redundancy, and avoid database anomalies.
في الغالب بنستخدمه عشان نعدل على حاجات موجودة Already عن طريق اننا نعدل عليه ونوصله لأحسن صورة.
لو عملت Logical Design (Mapping) ففي الغالب مفيش أي مشاكل هتظهر.

First Normal Form (1NF)

الشروط:

No repeating groups: (معنديش مثلًا عمود فيه أكتر من معلومة زي Skills: Db 100% هنا حطينا اسم المادة والدرجة)
No Multivalued attributes
No Composite attributes

مثال (Problem 1):

عندنا جدول للفرق وأعضاءها:

Team	Members
Frontend	Tom, Anna, John
Backend	Jenny, Bob

المشكلة:

خلية Members فيها أكتر من قيمة Multi-valued.
لو عايز أبحث عن عضو معين أو أنقله لفريق تاني، العملية هتكون معقدة.

الحل:

نفصل كل عضو في صف لوحده:

Team	Member
Frontend	Tom
Frontend	Anna
Frontend	John
Backend	Jenny
Backend	Bob

مثال (Problem 2)

المشكلة

الـ Name عبارة عن Composite
الـ Phone عبارة عن Multi-valued

الحل

نفصل الـ name كل واحد في عمود
نعمل جدول جديد عشان الأرقام

مثال (Problem 3)

المشكلة

الـ Subject عبارة عن Complex attribute بمعنى انه Repeating group

الحل

نعمل جدول جديد للـ Subject

ملحوظة على ترتيب الصفوف:

لو عايز تحتفظ بترتيب الأعضاء (مثلاً بالأقدمية)، تضيف عمود جديد يوضح الترتيب زي Join Date أو Order بدل الاعتماد على ترتيب الصفوف.

Second Normal Form (2NF)

الشروط:

تحقق شروط 1NF.
يكون (No Partial Dependency) كل Non-Key Attribute يعتمد بالكامل على Primary Key.

مثال:

المشكلة:

العمود Name بيعتمد على Emp_Id بس، مش على المفتاح الأساسي كله (Emp_ID + Car_ID).
وزيه العمود Color

الحل:

هنعمل جداول جديدة لكل Partial Dependency

دي بيحللي الـ Update Anomaly عشان لو عندي أكتر من موظف عندهم نفس نوع العربية ونوع العربية دي لونها اتغير فمش هضطر اغيرها في كله
وبيحللي الـ Remove Anomaly عشان لو مسحت الموظف اللي اسمه Ahmed دا مش هضطر أمسح العربية اللي موجودة في الـ DB
الـ Insert Anomaly بحيث انه ممكن أضيف موظف بس من غير عربية أو أضيف عربية من غير موظف وهكذا ومش هيعملي مشاكل

Third Normal Form (3NF)

الشروط:

تحقق شروط 2NF.
يكون (No Transitive Dependency) مافيش Non-Key Attribute يعتمد على Non-Key Attribute تاني.

مثال:

لو ضفنا أرقام تليفونات المدرسين في جدول الدورات:

Course	Instructor	Phone Number
Math	Bob	123456789
Physics	Tom	987654321

المشكلة:

الـPhone Number بيعتمد على Instructor، مش على المفتاح الأساسي Course.
- أنا لو غيرت الـ Instructor لأي واحد تاني فهو هيفضل نفس رقم التليفون، يعني لو خليت Tom يدي Math برضو فكدا هيبقا عندي اتنين Tom بأرقام تليفون مختلفة (Update Anomaly)
- لو عايز أدخل Instructor جديد وهو ملوش أي Course له فكدا مينفعش (Insertion Anomaly)
- لو عايز أشيل كورس معين زي الـ Physics فأنا هشيل بيانات Tom أكنه مش بيشتغل عندي (Deletion Anomaly)
الجدول دا لسا في الـ 2NF
- الـ Instructor والـ Phone بيعتمدوا على الكورس
- بس الإختلاف ان الـ Instructor بيعتمد بشكل مباشر على الـ Course
- انما الـ Phone بيعتمد على الـ Instructor وبالتالي بيعتمد على الـ Course ودي بنسميها (Transitive Dependency غير مباشرة)

الحل:

مثال كامل

Boyce-Codd Normal Form (BCNF)

دا المطور شوية من الـ 3NF فبيسموه 3.5NF نادرة الحدوث جدًا

الشروط:

تحقق شروط 3NF.
أي Attribute لازم يعتمد على مفتاح أساسي (Super Key).
- مينفعش أي Attribute عموما يبقا معتمد على Non-key attribute

الفرق عن 3NF:

في BCNF بنزود القيود على العلاقات بين الأعمدة للتأكد إن مافيش اعتماد على مفتاح غير أساسي.

Fourth Normal Form (4NF)

الشروط:

تحقق شروط BCNF.
مافيش Multi-Valued Dependency.

مثال:

لو عندنا محل بيبيع منتجات بألوان وأحجام مختلفة:

Item	Color	Size
Jeans	Blue	Large
Jeans	Black	Medium

المشكلة:

الألوان والأحجام مش مرتبطين ببعض بشكل مباشر، وبالتالي التكرار موجود.

الحل:

نفصل البيانات لجدولين:

جدول الألوان:

Item	Color
Jeans	Blue
Jeans	Black

جدول الأحجام:

Item	Size
Jeans	Large
Jeans	Medium

Fifth Normal Form (5NF)

الشروط:

تحقق شروط 4NF.
مافيش Join Dependency.

مثال:

لو عندنا بيانات عن العملاء، العلامات التجارية، والنكهات المفضلة:

Customer	Brand	Flavor
Amr	Brand A	Cheese
Amr	Brand B	Chicken

المشكلة:

الجدول ده هو ناتج عملية Join بين جداول أصغر.

الحل:

نفصل البيانات لجداول أصغر:

جدول العملاء والعلامات التجارية: | Customer | Brand | |-----------|---------| | Amr | Brand A | | Amr | Brand B |
جدول العلامات التجارية والنكهات: | Brand | Flavor | |-----------|---------| | Brand A | Cheese | | Brand B | Chicken |
جدول العملاء والنكهات: | Customer | Flavor | |-----------|---------| | Amr | Cheese | | Amr | Chicken |

ملخص:

Normalization بتساعد في تقليل التكرار وزيادة جودة البيانات.
كل مرحلة (1NF, 2NF, 3NF, 4NF, 5NF) بتحط قيود إضافية لتحسين التصميم.
الهدف هو الوصول لقاعدة بيانات آمنة ومنظمة وقابلة للتطوير.