1.1 Bevezetés

Az adatbázis tervezése némileg hasonlít egy Java projekt architektúrájának megtervezéséhez. Az összes adatot elhelyezheti néhány táblában, vagy gyönyörű adatstruktúrát építhet sémákból és több tucat táblából.

Az alábbiakban felsoroljuk azokat a feladatokat, amelyekkel a fejlesztő általában szembesül az adatbázis tervezése során:

  1. Gondoskodni arról, hogy az adatbázisban minden szükséges információ tárolva legyen.
  2. Adatszerzés lehetőségének biztosítása minden szükséges kérésre.
  3. A redundancia és az adatok ismétlődésének csökkentése.
  4. Az adatbázis integritásának biztosítása
  5. Adatelérési sebesség optimalizálása

A legfontosabb, hogy ne feledje, hogy nem lehet ideális adatbázis-struktúrát létrehozni, mert. a kódhoz hasonlóan ez is folyamatosan változik. Az adatbázis-struktúra kialakításakor három dolgot kell szem előtt tartania:

  1. A szerkezetnek elég jónak kell lennie.
  2. Mindenben kell lennie egy logikának, amit mások megérthetnek.
  3. Az idő előtti optimalizálás minden rossz gyökere.

Nem kell elkészítenie a világ legjobb adatbázis-struktúráját. Még mindig megváltozik. Az Ön feladata annak biztosítása, hogy az adatbázis szerkezetének 20 módosítása után könnyen kitalálható legyen.

Valószínűleg a munkája első éveiben senki sem fogja bízni abban, hogy a semmiből megtervezze az alapot. Egy meglévő sémát fog módosítani. Meg kell próbálnia megérteni, hogy milyen elvek alapján van elrendezve, és be kell tartania azokat . Charterjukkal nem másznak be valaki más kolostorába.

Ne optimalizálja az adatbázist, amíg nem szükséges. Ha a táblának csak néhány száz sora van, akkor valószínűleg a DBMS a memóriában tartja, és gyorsítótárban tárolja a lekérdezéseket.

Java webinar

Másrészt a fontos kérések munkáját tízszeresére, akár százszorosára is fel kell gyorsítania. És jó lenne, ha tudnád, hogyan kell csinálni. Hogy mondják a gimnáziumban az első évben? "Felejts el mindent, amit az iskolában tanítottak..."

Ha tudja, mi az adatbázis normalizálása, akkor sietek a kedvében járni, munkája során nagy valószínűséggel a denormalizálással fog foglalkozni . Semmi sem fontosabb a projekt szentélyei számára, mint az adatbázis sebessége. És ha az adatok adatbázisból való kiválasztásának felgyorsítása érdekében 200 (!) táblát kell egyesítenie egy (szörnyű redundanciával), akkor ezt meg kell tennie.

1.2 Könyvtár tervezés

Merüljünk el egy kicsit a témakörben, és gondolkodjunk el az adatbázis-tervezésen valami olyan egyszerű dologgal, mint egy tipikus könyvtár.

Minden könyvtár fő feladata a könyvalap feldolgozása. A rendszerhasználók három fő csoportját könnyű megkülönböztetni: olvasó, könyvtáros, rendszergazda . Mindegyik tevékenysége egy használati eset diagramon látható.

Már most is megkülönböztethető néhány entitás és kapcsolat a jövőbeli adatbázisban:

Ezzel a megközelítéssel nem világos, hogyan lehet az olvasót a könyvhöz kötni (az olvasónak nincs aritása a „kiadás/átvétel” kapcsolatban. Ha a könyvnek több példánya van, akkor több olvasónak is kiadható. Akár ha egy könyvet egy példányként értünk, akkor az aktuális olvasó könyveinek táblázatába mentve lehetetlen lesz információt szerezni arról, hogy ki (és hányszor) vette korábban ezt a könyvet.

A megoldás egy további entitás – egy könyvkibocsátási kártya – bevezetése lehet . Amikor a könyvet kiadják az olvasónak, kártya készül, majd a könyv átadásakor egy megfelelő jelölést helyeznek rá. Ezen kártyák segítségével meghatározzák az egyes felhasználók tartozásait, és kiszámítják a könyvhasználati statisztikákat. Az irodalom olvasó általi lefoglalásakor kártya is indul, ha a lefoglalt irodalmat az olvasó egy bizonyos időn belül nem veszi át, a kártya megsemmisül. Az olvasók által lefoglalható könyvek száma korlátozott.

Az irodalom kiválasztásakor a felhasználó megtekinti a szakirodalmi katalógust azzal a lehetőséggel, hogy a keresési eredményeket szerző, cím, megjelenési év szerint szűrje.

Lehetőség van a könyvtárban lévő összes könyv statisztikájának kiszámítására, miközben a könyvből adott időszakra kiadott példányszámot. Beállíthatja a könyvpéldányok minimális számát is, amelyekre a számítás végrehajtásra kerül. E statisztikák alapján a fel nem használt könyveket kiírják a könyvtárból.

A témakörben a következő fő entitások különböztethetők meg:

  • felhasználó (könyvtárosok és rendszergazdák);
  • olvasó;
  • olvasószoba;
  • könyv;
  • könyvkibocsátó kártya;
  • könyv foglalási kártya.

Az adatbázis módosított ER-diagramja az ábrán látható.

Az 1. ábrán látható használati eseteknek megfelelően az adatbázisnak a következő lekérdezéseket kell megvalósítania (nem teljes körű lista):

  • a megadott feltételeknek megfelelő könyvek megjelenítése;
  • megjeleníteni azokat a felhasználókat, akiknek van kártyájuk a könyvek kibocsátására, amelyeket nem zártak le időben (a könyvtáros adósokat keres);
  • jelenítse meg az adott felhasználó könyvkölcsönző kártyáinak megfelelő összes olyan könyvet, amelyet nem zártak le időben (új könyvekért jött a felhasználó a könyvtárba - meg kell nézni, hogy adós-e, és erről értesítenie kell);
  • törölje az összes több mint N másodperccel ezelőtt létrehozott foglalási kártyát;
  • jelenítse meg a megadott felhasználó lezáratlan könyvfoglalási kártyáinak megfelelő összes könyvet (az olvasó könyveket rendelt és értük jött a könyvtárba - ezt a listát a könyvtárosnak meg kell szereznie a kiadáshoz).

1.3 Sémaképzés

Adatséma kialakításához először ki kell egészíteni az ER diagramot az entitások adataival (finomítani). Időnként ugyanakkor előfordulhat, hogy hibákat találunk az ER-diagram felépítésében - ebben a feladatban azt találtuk, hogy a könyvet „valahogy” össze kell kapcsolni a könyvtárteremmel.

Ez megtehető a szükséges „csarnokszám” könyvben történő elhelyezésével, azonban ezzel a megközelítéssel ugyanazt a könyvet többször is le kell írni az adatbázisban (ha különböző csarnokokban fordul elő). Helyesebb megközelítés egy további „könyvelhelyezés” entitás bevezetése. Az ábra egy ER diagramot mutat egy hozzáadott entitással és kellékekkel.

A fenti ER diagram a főbb táblákat, kapcsolatokat és attribútumokat tükrözi, ennek alapján adatbázismodellt lehet építeni. Az ER diagramra nincs szabvány, de számos jelölés létezik (Chen, IDEFIX, Martin stb.), de sem a szabványt, sem a jelöléseket nem sikerült megtalálni a tartománymodellhez. Egy ilyen diagram készítése során azonban szükségszerűen kiemelésre kerülnek a kulcsmezők (külső és belső), esetenként indexek és adattípusok.

Ebben az esetben a következő ábrán:

  • linkeknél Martin jelölése ("szarkalábak" használatos);
  • A táblázatok téglalapként jelennek meg, három részre osztva:
    • táblázat neve;
    • belső kulcsok (jelölővel jelölve);
    • a többi mezőt, míg a kötelezően kitöltendőket jelölővel jelöljük.

A modell kidolgozásakor felmerült az a vágy, hogy az adminisztrátorok tábláját a könyvtárosok táblával egyesítsék – vegye fel azonban a felhasználók táblát:

  • az adminisztrátor nincs egy adott helyiséghez társítva (a megfelelő mezőt null értékekkel kell kitöltenie);
  • ez valószínűleg megnehezítené a hozzáférési jogok elosztását - most már csak az adatbázis-adminisztrátor (aki egy speciális DBMS-panelen keresztül dolgozik, és nincs fiókja a fejlesztés alatt álló rendszerben) férhet hozzá az adminisztrátorok táblájához. A táblák összekapcsolásakor azonban a felhasználói lekérdezésekhez hozzáférést kell biztosítani az új táblához.

A diagram elkészítésekor az ER diagram hibáját találták és kijavították - hozzáadtak egy táblázatot, librarians_roomsamely egyesíti a könyvtárosokat és a termeket. Erre azért van szükség, mert egy könyvtáros több helyiségben is dolgozhat, de egy helyiségben több könyvtáros is dolgozhat.

При проектировании баз данных вы должны уметь рассуждать хотя бы так, How в приведенном выше примере. Если вы считаете, что у вас это получилось – пойдем дальше: еще больше теории.