Normalization — relational ma’lumotlar bazasida ma’lumotni takrorlanish, update anomaly va nomuvofiqlikni kamaytiradigan table hamda relationshiplarga ajratish jarayoni. Normalization ma’lumotni mantiqiy entity va dependencylar asosida tashkil qiladi.
Maqsad barcha data’ni iloji boricha ko‘p table’ga bo‘lish emas. Maqsad har faktni aniq joyda saqlash va bir xil ma’lumotni keraksiz takrorlamaslikdir.
Takrorlanish
Quyidagi table’da user ma’lumoti har order qatorida takrorlanishi mumkin:
order_id
user_id
user_name
user_email
product
amount
User emaili o‘zgarsa barcha order rowlarini yangilash talab qilinadi.
Ayrim row yangilanib, boshqalari qolsa database’da bir user uchun turli email paydo bo‘ladi.
Normalization user ma’lumotini alohida users table’iga chiqaradi.
Update anomaly
Bir fakt ko‘p rowda takrorlansa o‘zgartirish barcha nusxalarda bir xil bajarilishi kerak.
Masalan, department nomi 500 employee rowida yozilgan.
Nomni almashtirishda ayrim rowlar yangilanmasa inconsistent holat yuz beradi.
Bu update anomaly.
Insert anomaly
Yangi ma’lumotni boshqa bog‘liq ma’lumot bo‘lmasdan saqlab bo‘lmasligi insert anomaly deyiladi.
Masalan, course ma’lumoti faqat student enrollment table’ida saqlansa, hali student yozilmagan yangi course’ni kiritib bo‘lmaydi.
Course alohida table’ga ajratiladi.
Delete anomaly
Bitta row o‘chirilganda boshqa kerakli fakt ham yo‘qolishi mumkin.
Masalan, course haqidagi yagona ma’lumot oxirgi student enrollment rowida bo‘lsa, student o‘chirilganda course ma’lumoti ham yo‘qoladi.
Entitylarni ajratish buni oldini oladi.
Functional dependency
Normalization functional dependency tushunchasiga tayanadi.
Agar bir attribute qiymati boshqasini yagona aniqlasa:
user_id → user_email
deb yoziladi.
Bu user_id ma’lum bo‘lsa user_email bitta qiymatga ega ekanini bildiradi.
Candidate key barcha rowni yagona aniqlaydi.
Birinchi normal forma
First Normal Form — 1NF table celllari atomik qiymatga ega bo‘lishini va rowlar aniqlanishini talab qiladi.
Masalan, bitta field ichida:
Python, Django, PostgreSQL
ko‘rinishida ko‘p qiymat saqlash query va constraintni qiyinlashtiradi.
Skills alohida relationship table’da saqlanishi mumkin.
“Atomik” tushunchasi application va database type’iga bog‘liq. JSON field ayrim modelda bitta qiymat, boshqasida buzilishi kerak bo‘lgan strukturadir.
Ikkinchi normal forma
Second Normal Form — 2NF 1NFni va non-key attribute’larning composite keyning faqat bir qismiga qaram bo‘lmasligini talab qiladi.
Masalan, enrollment table keyi:
(student_id, course_id)
bo‘lsa student_name faqat student_idga bog‘liq.
U students table’iga chiqariladi.
2NF asosan composite keyli table’larda ko‘rinadi.
Uchinchi normal forma
Third Normal Form — 3NF non-key attribute boshqa non-key attribute orqali keyga transitiv bog‘lanmasligini talab qiladi.
Misol:
employee_id → department_id → department_name
department_name employee rowida emas, departments table’ida saqlanadi.
Employee faqat department_idni saqlaydi.
Boyce-Codd normal forma
BCNF har determinant candidate key bo‘lishini talab qiladigan kuchliroq normal forma.
3NF bilan BCNF ko‘p oddiy schema’da bir xil natija beradi.
Murakkab overlapping candidate keylarda farq paydo bo‘lishi mumkin.
BCNFga decomposition ba’zan barcha dependencylarni bitta table constraintlari bilan saqlashni qiyinlashtiradi.
To‘rtinchi normal forma
4NF mustaqil multi-valued dependencylarni ajratadi.
Masalan, employee’ning skilllari va tillari bir table’da saqlansa barcha kombinatsiyalar hosil bo‘ladi:
employee × skill × language
Skill va language relationshiplari alohida table’ga ajratiladi.
Beshinchi normal forma
5NF join dependency va decompositiondan keyin ma’lumotni yo‘qotmasdan qayta birlashtirish masalalariga tegishli.
U kamroq kundalik schema dizaynida uchraydi, ammo murakkab many-to-many relationshiplarda muhim bo‘lishi mumkin.
Lossless decomposition
Table bo‘lingandan keyin join orqali original faktlarni noto‘g‘ri yangi kombinatsiyalarsiz tiklash mumkin bo‘lishi kerak.
Bu lossless decomposition.
Noto‘g‘ri decomposition ma’lumot yo‘qotishi yoki soxta rowlar yaratishi mumkin.
Dependency preservation
Decompositiondan keyin business dependencylarni alohida table constraintlari bilan tekshirish mumkin bo‘lsa dependency preservation saqlanadi.
Aks holda invariantni tekshirish uchun join yoki trigger talab qilinishi mumkin.
Normal forma tanlovida lossless va dependency preservation hisobga olinadi.
Surrogate key
Normalized table ko‘pincha sun’iy ID — surrogate keyga ega bo‘ladi.
Masalan:
users.id
products.id
Natural keylar ham unique constraint bilan saqlanishi mumkin.
Surrogate key business uniquenessni avtomatik ta’minlamaydi.
Many-to-many relationship
Ko‘pga-ko‘p bog‘lanish junction table orqali ifodalanadi.
users
roles
user_roles
user_roles composite unique key bilan bir userga ayni role ikki marta biriktirilishini oldini oladi.
Normalization va query
Normalized schema ko‘proq join talab qilishi mumkin.
Bu yomon dizayn degani emas.
Index va query optimizer joinlarni samarali bajarishi mumkin.
Lekin juda ko‘p mayda table va noaniq boundary application querylarini murakkablashtiradi.
Amaliy chegara
Ko‘p transactional schema 3NF yoki unga yaqin modelda quriladi.
Keyin aniq performance va reporting talabi bo‘lsa tanlangan joylarda denormalization qilinadi.
Normalization nazariy maqsad emas, ma’lumot yaxlitligini boshqarish vositasidir.
Normal forma va performance
Normal formalar query tezligini bevosita kafolatlamaydi.
Ular data dependency va anomalylarni boshqaradi.
Performance esa index, query plan, storage va workloadga ham bog‘liq.
Shu sababli schema avval correctness bo‘yicha, keyin o‘lchangan bottleneck asosida optimallashtiriladi.
Bog‘liq tushunchalar
Relational model, Functional dependency, First Normal Form, Second Normal Form, Third Normal Form, BCNF, Data anomaly, Decomposition, Denormalization