1.1 Introducere
Proiectarea unei baze de date este oarecum similară cu proiectarea arhitecturii unui proiect Java. Puteți pune toate datele în câteva tabele sau puteți construi o structură de date frumoasă din scheme și zeci de tabele.
Iată sarcinile cu care se confruntă de obicei un dezvoltator atunci când proiectează o bază de date:
- Asigurarea că toate informațiile necesare sunt stocate în baza de date.
- Asigurarea posibilitatii de obtinere a datelor asupra tuturor solicitarilor necesare.
- Reducerea redundanței și duplicarea datelor.
- Asigurarea integrității bazei de date
- Optimizarea vitezei de acces la date
Principalul lucru de reținut este că nu puteți face o structură ideală a bazei de date, deoarece. și acesta, ca și codul dvs., se va schimba constant. Există trei lucruri pe care ar trebui să le țineți cont atunci când vă proiectați structura bazei de date:
- Structura trebuie să fie suficient de bună.
- Trebuie să existe o logică în tot ceea ce alții pot înțelege.
- Optimizarea prematură este rădăcina tuturor relelor.
Nu trebuie să creați cea mai bună structură de baze de date din lume. Ea se va schimba în continuare. Sarcina dvs. este să vă asigurați că, după 20 de modificări ale structurii bazei de date, este suficient de ușor să vă dați seama.
Cel mai probabil, în primii ani de muncă, nimeni nu va avea încredere în tine pentru a proiecta o bază de la zero. Veți face modificări unei scheme existente. Trebuie să încercați să înțelegeți pe baza ce principii este aranjat și să respectați ele . Cu statutul lor, ei nu se urcă în mănăstirea altcuiva.
Nu optimizați baza de date până când este necesar. Dacă tabelul are doar câteva sute de rânduri, atunci cel mai probabil DBMS îl va păstra în memorie și va stoca interogări în el.
Pe de altă parte, ar trebui să puteți accelera de zeci sau chiar sute de ori munca solicitărilor importante. Și ar fi bine dacă ai ști cum să o faci. Cum se spune la liceu în primul an? „Uită tot ce ai fost învățat la școală...”
Dacă știi ce este normalizarea bazei de date, atunci mă grăbesc să te mulțumesc, în munca ta cel mai probabil te vei ocupa de denormalizare . Nimic nu este mai important pentru sanctuarele proiectului decât viteza bazei de date. Și dacă, pentru a accelera selecția datelor din baza de date, trebuie să combinați 200 (!) Tabele într-unul singur (cu redundanță monstruoasă), va trebui să faceți acest lucru.
1.2 Proiectarea bibliotecii
Să ne aprofundăm puțin în domeniul subiectului și să ne gândim la proiectarea bazei de date folosind ceva la fel de simplu ca o bibliotecă de cărți tipică.
Sarcina principală a oricărei biblioteci este prelucrarea fondului de carte. Este ușor să distingem trei grupuri principale de utilizatori de sistem: cititor, bibliotecar, administrator . Activitatea fiecăruia este prezentată într-o diagramă de caz de utilizare.
![](https://cdn.codegym.cc/images/article/ce739b07-800a-4e3c-a436-b40d3c54ea1d/512.jpeg)
Deja acum se pot distinge unele entități și relații ale viitoarei baze de date:
![](https://cdn.codegym.cc/images/article/b7373320-28d3-4fd8-9b62-a75c6102299f/1024.jpeg)
Cu această abordare, nu este clar cum să se conecteze cititorul cu cartea (cititorul nu are o aritate în relația „emitere/recepție”. Dacă cartea are mai multe exemplare, atunci poate fi eliberată mai multor cititori. Chiar și dacă o carte este înțeleasă ca un singur exemplar, atunci când este salvată în tabelul de cărți al cititorului curent, va fi imposibil să obțineți informații despre cine (și de câte ori) a luat această carte mai devreme.
Soluția poate fi introducerea unei entități suplimentare - un card pentru emiterea unei cărți. Când cartea este eliberată cititorului, se creează un card, iar când cartea este predată, se pune pe ea un semn corespunzător. Cu ajutorul acestor carduri se determină datoriile fiecărui utilizator și se calculează statistici privind utilizarea cărților. La rezervarea literaturii de către cititor, se începe și un card; dacă literatura rezervată nu este preluată de cititor într-o anumită perioadă, cardul este distrus. Există o limită a numărului de cărți pe care un cititor le poate rezerva.
La selectarea literaturii, utilizatorul vizualizează catalogul de literatură cu posibilitatea de a filtra rezultatele căutării după autor, titlu, anul publicării.
Este posibil să se calculeze statistici pentru toate cărțile din bibliotecă, în timp ce numărul de exemplare emise ale cărții pentru o anumită perioadă de timp. De asemenea, puteți seta numărul minim de instanțe de carte pentru care se efectuează calculul. Pe baza acestor statistici, cărțile neutilizate sunt eliminate din bibliotecă.
Se pot distinge următoarele entități principale ale domeniului de studiu:
- utilizator (bibliotecari și administratori);
- cititor;
- sală de lectură;
- carte;
- card de emitere a cărților;
- carte de rezervare.
Diagrama ER modificată a bazei de date este prezentată în figură.
![](https://cdn.codegym.cc/images/article/af26b62d-dd9e-4713-be71-3f4fc10c5379/1024.jpeg)
Conform cazurilor de utilizare prezentate în Figura 1, baza de date ar trebui să implementeze următoarele interogări (nu o listă exhaustivă):
- afișați cărți care corespund condițiilor specificate;
- utilizatori de afișaj care au carduri pentru emiterea cărților care nu au fost închise la timp (bibliotecarul caută debitori);
- afișați toate cărțile care corespund cardurilor de împrumut de cărți ale utilizatorului dat, care nu au fost închise la timp (utilizatorul a venit la bibliotecă pentru cărți noi - trebuie să vedeți dacă este debitor și să îl informați despre aceasta);
- ștergeți toate cardurile de rezervare create cu mai mult de N secunde în urmă;
- afișați toate cărțile corespunzătoare cardurilor de rezervare neînchise ale utilizatorului specificat (cititorul a comandat cărți și a venit la bibliotecă pentru ele - bibliotecarul trebuie să obțină această listă pentru a o da).
1.3 Formarea schemei
Pentru a forma o schemă de date, trebuie mai întâi să completați diagrama ER cu detaliile entităților (rafinați-o). Uneori, în același timp, este posibil să găsiți erori în construirea unei diagrame ER - în această sarcină, s-a constatat că cartea trebuie să fie „cumva” conectată cu sala bibliotecii.
Acest lucru se poate face prin plasarea „numărului sălii” necesar în carte, cu toate acestea, cu această abordare, aceeași carte va trebui să fie descrisă în baza de date de mai multe ori (dacă apare în săli diferite). O abordare mai corectă este introducerea unei entități suplimentare „plasare de carte”. Figura prezintă o diagramă ER cu o entitate adăugată și elemente de recuzită.
![](https://cdn.codegym.cc/images/article/e0d1296a-18db-464c-88ac-c6f6a33c661b/1024.jpeg)
Diagrama ER de mai sus reflectă tabelele, relațiile și atributele principale; pe baza acesteia, puteți construi un model de bază de date. Nu există un standard pentru diagrama ER, dar există o serie de notații (Chen, IDEFIX, Martin etc.), dar nici standardul, nici notațiile nu au putut fi găsite pentru modelul de domeniu. Cu toate acestea, în cursul construirii unei astfel de diagrame, câmpurile cheie (externe și interne) sunt în mod necesar evidențiate, uneori indici și tipuri de date.
În acest caz, în următoarea diagramă:
- pentru legături, notația lui Martin ("se folosește picioare de cioara");
- tabelele sunt prezentate ca dreptunghiuri împărțite în 3 secțiuni:
- numele tabelului;
- chei interne (marcate cu un marker);
- câmpurile rămase, în timp ce cele obligatorii sunt marcate cu un marker.
La dezvoltarea acestui model, a existat dorința de a se alătura tabelului de administratori cu tabelul de bibliotecari - adăugați totuși tabelul de utilizatori:
- administratorul nu este asociat cu o cameră anume (ar trebui să completați câmpul corespunzător cu valori nule);
- acest lucru ar complica probabil distribuirea drepturilor de acces – acum doar administratorul bazei de date (care lucrează printr-un panou special DBMS și nu are cont în sistemul în curs de dezvoltare) are acces la tabelul de administratori. Cu toate acestea, la alăturarea tabelelor, interogările utilizatorilor ar necesita acces la noul tabel.
La construirea acestei diagrame, a fost găsit și corectat un defect în diagrama ER - a fost adăugat un tabel librarians_rooms
care unește bibliotecarii și sălile. Acest lucru este necesar deoarece un bibliotecar poate lucra în mai multe camere, dar mai mulți bibliotecari pot lucra în aceeași cameră.
Când proiectați baze de date, ar trebui să puteți raționa cel puțin ca în exemplul de mai sus. Dacă crezi că ai reușit, să mergem mai departe: și mai multă teorie.
GO TO FULL VERSION