ER modellash va diagrammalar: entity, cardinality va crow's foot

Qisqacha: ER diagramma — bazaning chizmasi: to'rtburchaklar (entity — jadvallar), ichida atributlar (ustunlar), orasida chiziqlar (bog'lanishlar). Chiziq uchidagi "qarg'a oyog'i" belgilari cardinality'ni aytadi: "bitta", "nol yoki bitta", "ko'p". Jadval yozishdan oldin chizish dizayn xatosini qog'ozda — eng arzon joyda — tuzatishga imkon beradi.

Bu darsda

• Entity, atribut, bog'lanish va cardinality nima ekanini tushuntira olasiz.
• Crow's foot belgilarini o'qiysiz va yozasiz: ||, |o, o{, |{.
• Mermaid erDiagram bilan vazifalar bazasining diagrammasini chizasiz.
• Mavjud bazadan katalog so'rovi bilan bog'lanishlar xaritasini olasiz.
• dbdiagram.io (DBML) va DrawSQL kabi vositalar nima uchun kerakligini bilasiz.

Oldin bilishingiz kerak: Relatsion model, Foreign key va referential actions, JOIN'lar.

1. Nega bu kerak?

O'tgan darslarda ko'p SQL yozdik — lekin jadvallar tayyor edi. Endi teskari savol: jadvallarning o'zini qanday loyihalash kerak? Bu va keyingi to'rt dars shu haqida.

Tasavvur qiling: Jasur aka uy qurmoqchi. Usta g'isht terishni boshlab yuborsa va uchinchi qavatda "zinapoya qayerda bo'ladi?" deb so'rasa — devorlarni buzish kerak. Shuning uchun avval chizma chiziladi. Chizmada xona joyini o'zgartirish — o'chirg'ich bilan bir harakat. Qurilgan uyda — haftalab ish.

Baza ham shunday. Jadvalda millionlab qator bo'lgach, bog'lanishni o'zgartirish — migratsiya, qulf, to'xtash, ma'lumotni ko'chirish. ALTER TABLE darsida ko'rdik: 1 mln qatorli jadvalda ustun turini o'zgartirish yarim soniya jadvalni to'liq qulflaydi. Chizmada esa bu bir chiziqni boshqa joyga surish.

ER diagramma (Entity-Relationship diagram) — bazaning chizmasi. Uni 1976-yilda Piter Chen taklif qilgan, bugun esa deyarli har bir jamoa yangi xususiyatni muhokama qilishda ishlatadi.

2. Uch asosiy tushuncha

2.1 Entity va atribut

Entity (mohiyat) — biz ma'lumot saqlaydigan "narsa": foydalanuvchi, vazifa, teg. Har entity bazada odatda bitta jadval bo'ladi. Inglizcha so'zni saqlaymiz: dasturchilar suhbatida "entity" deyiladi.

Atribut (attribute) — entity'ning xususiyati: foydalanuvchining emaili, vazifaning matni. Bazada — ustun.

Entity topishning oddiy usuli: talablar matnidagi otlarni belgilang. "Foydalanuvchi vazifa qo'shadi, vazifaga teg qo'yadi" — uchta ot, uchta entity. Fe'llar ("qo'shadi", "qo'yadi") — bog'lanishlar.

2.2 Bog'lanish va cardinality

Bog'lanish (relationship) — ikki entity orasidagi aloqa: "foydalanuvchi vazifaning egasi". Bazada bu — tashqi kalit (foreign key).

Cardinality — bog'lanishning har uchida nechta yozuv bo'lishi mumkin. Har uchida ikki savol beriladi:

• Eng kami — nol bo'lishi mumkinmi? (majburiymi yoki ixtiyoriymi)
• Eng ko'pi — bitta yoki ko'p?

"Foydalanuvchi — vazifa" uchun: bitta foydalanuvchining vazifalari 0 ta bo'lishi mumkin (Shahnoza hali hech narsa yozmagan) va ko'p bo'lishi mumkin. Har vazifaning egasi esa aniq bitta — egasiz vazifa yo'q (egasi_id NOT NULL).

Tekshirib ko'ring: "Vazifa — teg" bog'lanishida har uchida eng kami va eng ko'pi qancha?

3. Crow's foot notatsiyasi

3.1 Belgilar

ER diagrammani chizishning bir necha uslubi bor. Eng ko'p tarqalgani — crow's foot (qarg'a oyog'i): "ko'p" belgisi uch barmoqli oyoqqa o'xshaydi. Har chiziq uchida ikki belgi turadi: tashqaridagisi — eng ko'pi, ichkaridagisi — eng kami.

Doira — "nol", tik chiziq — "bir", qarg'a oyog'i — "ko'p". Shu uchta belgidan hamma kombinatsiya yig'iladi.

3.2 Mermaid'da birinchi diagramma

Saytimizda ER diagramma Mermaid tilida chiziladi — matn yozasiz, rasm o'zi chiqadi. Sintaksis: chap_entity <chap_belgi>--<o'ng_belgi> o'ng_entity : "yorliq". Avval eng kichik misol — foydalanuvchi va vazifa:

erDiagram
    foydalanuvchilar ||--o{ vazifalar : "egasi"

Chapdan o'ngga o'qiymiz: "bitta foydalanuvchi (||) — nol yoki ko'p vazifa (o{)". O'ngdan chapga: "har vazifaning — aniq bitta foydalanuvchisi". Har bog'lanishni ikki yo'nalishda o'qib chiqish odati xatolarni tez ko'rsatadi.

3.3 Uzluksiz va nuqtali chiziq

Mermaid'da -- (uzluksiz) va .. (nuqtali) chiziq bor:

• Uzluksiz — identifikatsiya qiluvchi (identifying) bog'lanish: bola yozuv ota-onasisiz mavjud emas va uning kaliti ota-ona kalitini o'z ichiga oladi. Misol: vazifa_teglari — uning birlamchi kaliti (vazifa_id, teg_id).
• Nuqtali — identifikatsiya qilmaydigan (non-identifying) bog'lanish: bola o'z kalitiga ega, ota-onaga faqat havola qiladi.

Amalda ko'p jamoa bu farqqa qattiq rioya qilmaydi va hammasini uzluksiz chizadi. Bizning kanon diagrammamizda nuqtali chiziq boshqa ma'noda — "mantiqiy bog'liq, lekin bazada tashqi kalit yo'q" (vazifa_tarixi, uni tarix jadvallari darsida ko'ramiz). Asosiysi — jamoada bir xil kelishuv bo'lsin va diagramma ostida izoh tursin.

4. vazifalar bazasining diagrammasi

4.1 Holat 23: to'rt jadval

Hozirgacha qurgan bazamizda to'rtta jadval bor. Quyidagi diagramma holat 23 sxemasidan (kanon er-diagramma.mmd dan kelajak jadvallarni olib tashlab) chizilgan. Nimaga qarang: o'z-o'ziga qaytgan chiziq (ota_id) va o'rtadagi vazifa_teglari "ko'prik" jadvali.

erDiagram
    foydalanuvchilar ||--o{ vazifalar : "egasi"
    foydalanuvchilar ||--o{ teglar : "egasi"
    vazifalar |o--o{ vazifalar : "ota_id"
    vazifalar ||--o{ vazifa_teglari : "vazifa"
    teglar ||--o{ vazifa_teglari : "teg"

    foydalanuvchilar {
        bigint id PK
        text email UK "lower(email) noyob"
        text ism
        timestamptz yaratilgan_vaqt
    }
    vazifalar {
        bigint id PK
        bigint egasi_id FK
        text matn "1-100 belgi"
        boolean bajarildi
        timestamptz bajarilgan_vaqt
        ustuvorlik ustuvorlik "enum"
        timestamptz muddat
        bigint ota_id FK "(ota_id, egasi_id)"
        timestamptz yaratilgan_vaqt
    }
    teglar {
        bigint id PK
        bigint egasi_id FK
        text nom "kichik harf, # bilan"
    }
    vazifa_teglari {
        bigint vazifa_id PK, FK
        bigint teg_id PK, FK
    }

Diagrammani o'qiymiz:

Atribut qatorida uch qism: tur, nom va kalit belgisi — PK (birlamchi kalit), FK (tashqi kalit), UK (noyob kalit). Qo'shtirnoqdagi matn — izoh. vazifa_teglari da ikkala ustun ham PK, FK: ular birgalikda birlamchi kalit va har biri alohida tashqi kalit.

4.2 Diagramma sxemadan nimani yashiradi

Diagramma — soddalashtirilgan rasm. Unda ko'rinmaydigan narsalar bor va buni bilish muhim:

• CHECK cheklovlari — matn uzunligi faqat izohda, bajarildi = (bajarilgan_vaqt IS NOT NULL) umuman yo'q.
• ON DELETE amallari — chiziqda CASCADE yoki SET NULL ko'rinmaydi. Muhim bo'lsa — yorliqqa yozamiz (kanon diagrammasida "muallif (SET NULL)" shunday).
• Tarkibiy tashqi kalit — ota_id aslida (ota_id, egasi_id) juftligi orqali bog'langan: kichik vazifa faqat o'sha egasining vazifasiga ulanadi (ALTER TABLE darsida qo'shgan edik). Diagrammada bu faqat izohda.

Ya'ni diagramma — muhokama vositasi. Haqiqat manbai — SQL fayllar (sql/001…). Ikkalasi farq qilsa, SQL to'g'ri.

Tekshirib ko'ring: Nega vazifalar |o--o{ vazifalar da chap tomonda |o (nol yoki bitta), || emas?

5. Diagrammadan jadvalga va aksincha

5.1 Uch daraja

Loyihalash odatda uch qadamda boradi:

Yuqoridagi holat 23 diagrammasi — fizik darajaga yaqin (turlar bor). Buyurtmachiga ko'rsatishda turlarni olib tashlab, faqat to'rtburchak va chiziqlarni qoldirish kifoya.

5.2 Cardinality → SQL

Har belgi aniq SQL'ga aylanadi. Shu jadval keyingi darsning asosi:

Diqqat qiling: "ota tomonda kamida 1 bola" (|{) ni oddiy cheklov bilan bazada kafolatlab bo'lmaydi — "har foydalanuvchida kamida bitta vazifa" degan qoida trigger yoki ilova kodini talab qiladi. Shuning uchun real diagrammalarda o{ ancha ko'p uchraydi.

5.3 Bazadan diagrammaga: katalogdan bog'lanishlar

Ba'zan teskari vazifa turadi: tayyor, diagrammasi yo'q bazani tushunish. Postgres hamma tashqi kalitlarni o'z katalogida saqlaydi — pg_constraint jadvalida (contype = 'f' — foreign key). ::regclass jadval raqamini nomga aylantiradi. Biz o'z PostgreSQL 17.6 klasterimizda, kanon holat 23 sxemasida ishga tushirdik:

SELECT conrelid::regclass AS jadval,
       confrelid::regclass AS qaysiga,
       conname AS cheklov
FROM pg_constraint
WHERE contype = 'f'
ORDER BY 1, 2;

     jadval     |     qaysiga      |            cheklov
----------------+------------------+-------------------------------
 vazifalar      | foydalanuvchilar | vazifalar_egasi_id_fkey
 vazifalar      | vazifalar        | vazifalar_ota_id_fkey
 teglar         | foydalanuvchilar | teglar_egasi_id_fkey
 vazifa_teglari | vazifalar        | vazifa_teglari_vazifa_id_fkey
 vazifa_teglari | teglar           | vazifa_teglari_teg_id_fkey
(5 rows)

Beshta qator — diagrammadagi beshta chiziq. ORDER BY 1 jadval nomi bo'yicha emas, jadval yaratilgan tartib (ichki raqam) bo'yicha saraladi — shuning uchun vazifalar birinchi.

Tashqi kalit "bitta" yoki "nol yoki bitta" ekanini bilish uchun ustunning NOT NULL ekanini ko'rish kerak. "Kamida nechta" degan savolga esa ma'lumotning o'zi javob beradi. Masalan, vazifasi eng kam foydalanuvchilar:

SELECT f.ism, count(v.id) AS vazifalar
FROM foydalanuvchilar f
LEFT JOIN vazifalar v ON v.egasi_id = f.id
GROUP BY f.id
ORDER BY vazifalar, f.id
LIMIT 3;

        ism         | vazifalar
--------------------+-----------
 Shahnoza Ergasheva |         0
 Gulnora Saidova    |         4
 Bekzod Nazarov     |         4
(3 rows)

Shahnozada 0 vazifa — demak foydalanuvchi tomonida "nol" haqiqatan uchraydi va o{ to'g'ri belgi. Bu LEFT JOIN bilan sanash — o'sha darsdagi Shahnoza misoli.

Maslahat: DBeaver, pgAdmin, DataGrip kabi GUI vositalar bazadan ER diagrammani avtomatik chizadi — ular aynan shu katalog jadvallarini o'qiydi. Biz ularni sinamadik (kanon mashinasida o'rnatilmagan); yuqoridagi so'rov esa istalgan Postgres'da ishlaydi.

6. Vositalar: Mermaid, DBML, DrawSQL

Diagramma chizishning ikki yo'li bor: sichqoncha bilan (rasm muharriri) va matn bilan ("diagramma — kod"). Matnli yo'lning katta afzalligi: diagramma git'da saqlanadi, o'zgarishlari diff'da ko'rinadi, kod review'da muhokama qilinadi.

DBML (Database Markup Language) — dbdiagram.io ning matn tili. Mermaid'dan farqi: unda indeks, ON DELETE va izohlarni ham yozish mumkin, sayt undan tayyor CREATE TABLE SQL'ini ham chiqaradi. Bizning holat 23 dan bir parcha DBML'da shunday yoziladi (dbdiagram.io hujjati bo'yicha, 2026-10-24; saytning o'zini biz sinamadik):

Table vazifalar {
  id bigint [pk]
  egasi_id bigint [not null, ref: > foydalanuvchilar.id]
  matn text [not null, note: '1-100 belgi']
  bajarildi boolean [not null, default: false]
}

ref: > — "ko'pdan bittaga" (ko'p vazifa → bitta foydalanuvchi). DBML va DrawSQL — tashqi saytlar: ular uchun hisob kerak va loyiha sxemasi ularning serveriga ketadi. Yopiq loyihada buni jamoa bilan kelishib oling.

Kanon kuzatuvi. Kurs kanonida yakuniy (holat 40) diagramma mermaid-cli 11.4.1 bilan rasmga aylantirilgan: render muvaffaqiyatli, lekin o'z-o'ziga qaytgan chiziq (ota_id) yorlig'i boshqa yorliq ustiga tushadi — o'qiladi, lekin chiroyli emas. Avtomatik joylashtiruvchi vositalarning odatiy cheklovi: katta diagrammani qismlarga bo'lish yaxshiroq.

7. Ko'p uchraydigan xatolar

1. Entity o'rniga atribut, atribut o'rniga entity. "Shahar" — foydalanuvchining atributimi yoki alohida entity? Agar shaharning o'zi haqida ma'lumot saqlanmasa (aholi, viloyat) — atribut. Agar ko'p narsa uni ishlatsa va nomi bir xil yozilishi kerak bo'lsa — entity. Bu savolni Normalizatsiya darsida chuqur ko'ramiz.

2. Faqat bir yo'nalishda o'qish. "Foydalanuvchida ko'p vazifa" — to'g'ri. Teskarisini o'qimasangiz, "vazifada nechta egasi?" savoli javobsiz qoladi va keyin "bitta vazifani ikki kishi bajaradi" talabi kelganda sxema buziladi.

3. N:M ni ikkita FK bilan "hal qilish". vazifalar.teg_id — bitta teg; teglar.vazifa_id — bitta vazifa. Ikkalasi ham N:M emas. Faqat ko'prik jadval to'g'ri.

4. Diagramma va SQL ajralib qolishi. Sxema o'zgardi, diagramma eski qoldi — u endi zarar keltiradi. Matnli diagramma (Mermaid, DBML) sxema fayllari yonida, bitta commit'da yangilansin.

5. Mermaid sintaksis xatosi. Atribut turi bir necha so'zdan iborat bo'lsa (timestamp with time zone yaratilgan_vaqt), diagramma chizilmaydi — Parse error. Biz buni mermaid-cli 11.4.1 da sinab ko'rdik. Turni bitta so'z bilan yozing: timestamptz. Nomlarda harf, raqam va _ ishlatish ham xavfsiz odat — SQL nomlari bilan bir xil bo'ladi.

8. Mashqlar

1-mashq (oson)

teglar ||--o{ vazifa_teglari chizig'ini ikki yo'nalishda o'zbekcha gap bilan o'qing. Har yo'nalishda eng kami va eng ko'pi nechta? Ishora: «Crow's foot notatsiyasi» bo'limidagi belgilar jadvali.

2-mashq (o'rta)

Keyingi qadamda bazaga izohlar jadvali qo'shiladi: har izoh bitta vazifaga yoziladi; muallifi — foydalanuvchi, lekin foydalanuvchi o'chirilsa izoh qoladi (muallifsiz). Holat 23 diagrammasiga izohlar entity'sini (id, vazifa_id, muallif_id, matn, yaratilgan_vaqt) va ikkita bog'lanishni qo'shing. Ishora: muallif "nol yoki bitta" bo'lishi mumkinmi? Belgilar — «Crow's foot notatsiyasi» bo'limida.

erDiagram
    foydalanuvchilar ||--o{ vazifalar : "egasi"
    vazifalar ||--o{ izohlar : "vazifa"
    foydalanuvchilar |o--o{ izohlar : "muallif (SET NULL)"

    izohlar {
        bigint id PK
        bigint vazifa_id FK
        bigint muallif_id FK "NULL bo'lishi mumkin"
        text matn
        timestamptz yaratilgan_vaqt
    }

3-mashq (qiyin)

Katalogdan har tashqi kalitning ustun nomi va o'chirishdagi amalini chiqaring: ustunlar jadval, ustun, qaysiga, ochirishda. pg_constraint.conkey — ustun raqamlari massivi, confdeltype — amal harfi (c — CASCADE, n — SET NULL, r — RESTRICT, a — NO ACTION). Ustun nomini pg_attribute dan oling (attrelid, attnum, attname). Ishora: massivda qidirish — = ANY (massiv), birlashtirish — JOIN.

SELECT c.conrelid::regclass AS jadval,
       a.attname AS ustun,
       c.confrelid::regclass AS qaysiga,
       c.confdeltype AS ochirishda
FROM pg_constraint c
JOIN pg_attribute a
  ON a.attrelid = c.conrelid AND a.attnum = ANY (c.conkey)
WHERE c.contype = 'f'
ORDER BY 1, 2;

     jadval     |   ustun   |     qaysiga      | ochirishda
----------------+-----------+------------------+------------
 vazifalar      | egasi_id  | foydalanuvchilar | c
 vazifalar      | egasi_id  | vazifalar        | c
 vazifalar      | ota_id    | vazifalar        | c
 teglar         | egasi_id  | foydalanuvchilar | c
 vazifa_teglari | teg_id    | teglar           | c
 vazifa_teglari | vazifa_id | vazifalar        | c
(6 rows)

9. SQL qadami

Bu darsda sxema o'zgarmaydi — holat 23. Kanon natijasi — er-diagramma.mmd: yakuniy (holat 40) sxemaning Mermaid diagrammasi, oltita jadval bilan. Biz darsda undan hali qurilmagan qismlarni (izohlar, tarix, keyingi ustunlar) olib tashlab, holat 23 ko'rinishini chizdik.

O'z loyihangizda ham shu odatni boshlang: sxema fayllari yonida er-diagramma.mmd turadi va har sxema o'zgarishi bilan bitta commit'da yangilanadi. Keyingi darslarda unga izohlar (holat 34), izohlar_soni (holat 36), yangilangan_vaqt, ochirilgan_vaqt va vazifa_tarixi (holat 38), versiya (holat 40) qo'shiladi. To'liq diagrammani real loyiha sxemasi darsida yakuniy holat bilan ko'rib chiqamiz.

Commit yo'q — SQL fayllar o'zgarmadi.

10. Real ishda

• Dizayn hujjati (design doc). Yangi xususiyat muhokamasida ER diagramma birinchi chiziladigan narsa: "qaysi jadval qo'shiladi, qaysi bog'lanish o'zgaradi".
• README va onboarding. Yangi dasturchi loyihaga kelganda bazaning bitta rasmi o'nlab SQL fayldan tezroq tushuntiradi. GitHub Markdown'dagi Mermaid shu uchun qulay.
• ORM sxemalari. Keyingi qismda o'rganadigan Prisma kabi vositalarning sxema fayli ham aslida matnli ER model; ulardan diagramma avtomatik chiziladi (27-qismda ko'ramiz).
• Intervyuda: "onlayn do'kon (yoki kutubxona) uchun ER diagramma chizing" — backend intervyularining klassik vazifasi. Baholanadi: entity'larni to'g'ri topish, N:M uchun ko'prik jadval, cardinality'ni ikki tomondan asoslash.

Xulosa

• ER diagramma — bazaning chizmasi: entity (jadval), atribut (ustun), bog'lanish (tashqi kalit).
• Cardinality — har uchida eng kami (0 yoki 1) va eng ko'pi (1 yoki ko'p).
• Crow's foot: doira — nol, tik chiziq — bir, qarg'a oyog'i — ko'p.
• Mermaid erDiagram — matnli diagramma: git'da saqlanadi, review qilinadi.
• Diagramma CHECK, ON DELETE va tarkibiy kalitlarni yashiradi — haqiqat manbai SQL.
• Mavjud bazaning bog'lanishlarini pg_constraint katalogidan olish mumkin.

Keyingi dars: Bog'lanishlar: 1:1, 1:N, N:M — diagrammadagi har chiziq turini jadvalga qanday o'girishni o'rganamiz va izohlar jadvalini quramiz.

Manbalar

• Mermaid hujjati: "Entity Relationship Diagrams" — mermaid.js.org, 2026-10-24 da ko'rildi.
• PostgreSQL 18 hujjati: "pg_constraint" (System Catalogs) — postgresql.org/docs/18.
• dbdiagram.io hujjati: "DBML — Database Markup Language" — dbml.dbdiagram.io (sinalmagan, hujjat bo'yicha).
• P. Chen, "The Entity-Relationship Model — Toward a Unified View of Data", 1976.