1.1 Indledning

At designe en database svarer lidt til at designe arkitekturen i et Java-projekt. Du kan lægge alle data i et par tabeller, eller du kan bygge en smuk datastruktur ud fra skemaer og snesevis af tabeller.

Her er de opgaver, som en udvikler normalt står over for, når han designer en database:

  1. Sikre at alle nødvendige oplysninger er gemt i databasen.
  2. Sikring af muligheden for at indhente data om alle nødvendige forespørgsler.
  3. Reduktion af redundans og duplikering af data.
  4. Sikring af databaseintegritet
  5. Hastighedsoptimering af dataadgang

Det vigtigste at huske er, at du ikke kan lave en ideel databasestruktur, fordi. det, ligesom din kode, vil også ændre sig konstant. Der er tre ting, du bør huske på, når du designer din databasestruktur:

  1. Strukturen skal være god nok.
  2. Der skal være en logik i alt, som andre mennesker kan forstå.
  3. For tidlig optimering er roden til alt ondt.

Du behøver ikke lave verdens bedste databasestruktur. Hun vil stadig ændre sig. Din opgave er at sikre, at efter 20 ændringer i strukturen af ​​din database, er det nemt nok at finde ud af det.

Mest sandsynligt i de første år af dit arbejde, vil ingen stole på dig til at designe en base fra bunden. Du vil foretage ændringer i et eksisterende skema. Du skal prøve at forstå ud fra hvilke principper det er indrettet og overholde dem . Med deres charter klatrer de ikke ind i andres kloster.

Optimer ikke databasen, før det er nødvendigt. Hvis tabellen kun har et par hundrede rækker, vil DBMS højst sandsynligt beholde den i hukommelsen og cache forespørgsler til den.

Java webinar

På den anden side bør du være i stand til at fremskynde arbejdet med vigtige anmodninger med tiere eller endda hundredvis af gange. Og det ville være rart, hvis du vidste, hvordan du gør det. Hvordan siger de i gymnasiet på det første år? "Glem alt, hvad du blev lært i skolen..."

Hvis du ved, hvad databasenormalisering er, så skynder jeg mig at behage dig, i dit arbejde vil du højst sandsynligt beskæftige dig med de-normalisering . Intet er vigtigere for projektets helligdomme end databasens hastighed. Og hvis du, for at fremskynde udvælgelsen af ​​data fra databasen, skal kombinere 200 (!) tabeller til én (med monstrøs redundans), bliver du nødt til at gøre dette.

1.2 Biblioteksdesign

Lad os dykke lidt ned i emneområdet og tænke på databasedesign ved hjælp af noget så simpelt som et typisk bogbibliotek.

Ethvert biblioteks hovedopgave er behandlingen af ​​bogfonden. Det er let at skelne mellem tre hovedgrupper af systembrugere: læser, bibliotekar, administrator . Hver aktivitet er vist i et use case-diagram.

Allerede nu kan nogle entiteter og relationer i den fremtidige database skelnes:

Med denne tilgang er det ikke klart, hvordan man forbinder læseren med bogen (læseren har ikke en arity i forholdet "udstedelse / modtagelse". Hvis bogen har flere eksemplarer, så kan den udstedes til flere læsere. Selv hvis en bog forstås som én kopi, vil det, når det gemmes i den nuværende læsers bogoversigt, være umuligt at få oplysninger om, hvem (og hvor mange gange) der har taget denne bog tidligere.

Løsningen kan være indførelsen af ​​en ekstra enhed - et kort til at udstede en bog. Når bogen udleveres til læseren, oprettes et kort, og når bogen afleveres, sættes et tilsvarende mærke på det. Ved hjælp af disse kort bestemmes hver brugers gæld, og statistik over brugen af ​​bøger beregnes. Ved bestilling af litteratur af læseren påbegyndes også et kort, hvis den bookede litteratur ikke tages af læseren inden for en vis periode, destrueres kortet. Der er en grænse for, hvor mange bøger en læser kan booke.

Ved valg af litteratur ser brugeren litteraturkataloget med mulighed for at filtrere søgeresultaterne efter forfatter, titel, udgivelsesår.

Det er muligt at beregne statistik for alle bøger på biblioteket, mens antallet af udgivne eksemplarer af bogen for en given periode. Du kan også indstille det mindste antal bogforekomster, som beregningen udføres for. Ud fra disse statistikker afskrives ubrugte bøger fra biblioteket.

Der kan skelnes mellem følgende hovedenheder i fagområdet:

  • bruger (bibliotekarer og administratorer);
  • læser;
  • læsesal;
  • Bestil;
  • bogudstedelseskort;
  • book bookingkort.

Det modificerede ER-diagram af databasen er vist på figuren.

I henhold til de use cases, der er vist i figur 1, skal databasen implementere følgende forespørgsler (ikke en udtømmende liste):

  • vise bøger, der matcher de angivne betingelser;
  • vise brugere, der har kort til at udstede bøger, der ikke er blevet lukket til tiden (bibliotekaren leder efter debitorer);
  • vise alle de bøger, der svarer til den givne brugers bogudlånskort, der ikke blev lukket i tide (brugeren kom til biblioteket efter nye bøger - du skal se, om han er debitor og informere ham om det);
  • slet alle reservationskort oprettet for mere end N sekunder siden;
  • vise alle bøger, der svarer til ulukkede bogreservationskort fra den angivne bruger (læseren bestilte bøger og kom til biblioteket for dem - bibliotekaren skal have denne liste for at kunne udlevere den).

1.3 Skemadannelse

For at danne et dataskema skal du først supplere ER-diagrammet med detaljerne for entiteterne (forfine det). Nogle gange er det samtidig muligt at finde fejl i konstruktionen af ​​et ER-diagram - i denne opgave fandt man ud af, at bogen skulle "på en eller anden måde" være forbundet med bibliotekssalen.

Dette kan gøres ved at indsætte det nødvendige "halnummer" i bogen, men med denne tilgang vil den samme bog skulle beskrives i databasen flere gange (hvis den forekommer i forskellige haller). En mere korrekt tilgang er at indføre en ekstra enhed "bogplacering". Figuren viser et ER-diagram med en tilføjet enhed og rekvisitter.

Ovenstående ER-diagram afspejler de vigtigste tabeller, relationer og attributter; på grundlag heraf kan du bygge en databasemodel. Der er ingen standard for ER-diagrammet, men der er en række notationer (Chen, IDEFIX, Martin osv.), men hverken standarden eller notationerne kunne findes for domænemodellen. I løbet af konstruktionen af ​​et sådant diagram, fremhæves nøglefelter (eksterne og interne) dog nødvendigvis, nogle gange indekser og datatyper.

I dette tilfælde i følgende diagram:

  • for links, Martins notation ("kragetæer" bruges);
  • tabeller er vist som rektangler opdelt i 3 sektioner:
    • tabel navn;
    • interne taster (markeret med en markør);
    • de resterende felter, mens de obligatoriske er markeret med en markør.

Ved udviklingen af ​​denne model var der et ønske om at forbinde administratortabellen med bibliotekartabellen - tilføj brugertabellen dog:

  • administratoren er ikke knyttet til et specifikt rum (du skal udfylde det tilsvarende felt med null-værdier);
  • dette ville sandsynligvis komplicere fordelingen af ​​adgangsrettigheder - nu har kun databaseadministratoren (som arbejder gennem et særligt DBMS-panel og ikke har en konto i det system, der udvikles) adgang til administratortabellen. Men når du forbinder tabeller, vil brugerforespørgsler kræve adgang til den nye tabel.

Ved konstruktionen af ​​dette diagram blev en fejl i ER-diagrammet fundet og rettet - en tabel blev tilføjet, librarians_roomsder forener bibliotekarer og sale. Dette er nødvendigt, fordi én bibliotekar kan arbejde i flere rum, men flere bibliotekarer kan arbejde i samme rum.

Når du designer databaser, bør du være i stand til at ræsonnere i det mindste som eksemplet ovenfor. Hvis du tror, ​​at det lykkedes, så lad os gå videre: endnu mere teori.