1.1 Introduksjon
Å designe en database ligner litt på å designe arkitekturen til et Java-prosjekt. Du kan legge alle dataene i et par tabeller, eller du kan bygge en vakker datastruktur fra skjemaer og dusinvis av tabeller.
Her er oppgavene som en utvikler vanligvis står overfor når han designer en database:
- Sørge for at all nødvendig informasjon er lagret i databasen.
- Sikre muligheten for å innhente data om alle nødvendige forespørsler.
- Redusere redundans og duplisering av data.
- Sikre databaseintegritet
- Hastighetsoptimalisering av datatilgang
Det viktigste å huske er at du ikke kan lage en ideell databasestruktur, fordi. den, som koden din, vil også endre seg hele tiden. Det er tre ting du bør huske på når du designer databasestrukturen din:
- Strukturen må være god nok.
- Det må være en logikk i alt som andre mennesker kan forstå.
- For tidlig optimalisering er roten til alt ondt.
Du trenger ikke lage verdens beste databasestruktur. Hun vil fortsatt forandre seg. Din oppgave er å sikre at det etter 20 endringer i strukturen til databasen din er lett nok å finne ut av det.
Mest sannsynlig i de første årene av arbeidet ditt, vil ingen stole på at du designer en base fra bunnen av. Du vil gjøre endringer i et eksisterende skjema. Du må prøve å forstå på grunnlag av hvilke prinsipper det er ordnet og følge dem . Med charteret deres klatrer de ikke inn i andres kloster.
Ikke optimaliser databasen før det er nødvendig. Hvis tabellen bare har et par hundre rader, vil mest sannsynlig DBMS beholde den i minnet og cache forespørsler til den.
På den annen side bør du kunne fremskynde arbeidet med viktige forespørsler med titalls eller hundrevis av ganger. Og det ville vært fint om du visste hvordan du gjør det. Hvordan sier de på videregående det første året? "Glem alt du ble lært på skolen ..."
Hvis du vet hva databasenormalisering er, skynder jeg meg å glede deg, i arbeidet ditt vil du mest sannsynlig håndtere denormalisering . Ingenting er viktigere for prosjektets helligdommer enn hastigheten på databasen. Og hvis du, for å fremskynde utvelgelsen av data fra databasen, må kombinere 200 (!) tabeller til én (med monstrøs redundans), må du gjøre dette.
1.2 Bibliotekdesign
La oss dykke litt ned i fagområdet og tenke på databasedesign ved å bruke noe så enkelt som et typisk bokbibliotek.
Hovedoppgaven til ethvert bibliotek er behandlingen av bokfondet. Det er lett å skille mellom tre hovedgrupper av systembrukere: leser, bibliotekar, administrator . Aktiviteten til hver er vist i et use case-diagram.
Allerede nå kan noen enheter og relasjoner i den fremtidige databasen skilles:
Med denne tilnærmingen er det ikke klart hvordan man kan koble leseren til boken (leseren har ingen aritet i forholdet "utstedelse / mottak". Hvis boken har flere eksemplarer, kan den gis ut til flere lesere. Selv hvis en bok forstås som én kopi, vil det være umulig å få informasjon om hvem (og hvor mange ganger) som tok denne boken tidligere, når den lagres i boktabellen til den nåværende leseren.
Løsningen kan være introduksjonen av en ekstra enhet - et kort for å utstede en bok. Når boken utstedes til leseren, opprettes et kort, og når boken overleveres settes et tilsvarende merke på det. Ved hjelp av disse kortene fastsettes gjelden til hver enkelt bruker og statistikk over bruk av bøker beregnes. Ved bestilling av litteratur av leseren startes også et kort, dersom den bestilte litteraturen ikke blir tatt av leseren innen en viss periode, blir kortet ødelagt. Det er en grense på antall bøker en leser kan bestille.
Ved valg av litteratur ser brukeren litteraturkatalogen med muligheten til å filtrere søkeresultatene etter forfatter, tittel, utgivelsesår.
Det er mulig å beregne statistikk for alle bøker i biblioteket, mens antall utgitte eksemplarer av boken for en gitt tidsperiode. Du kan også angi minimum antall bokforekomster som beregningen utføres for. Basert på denne statistikken blir ubrukte bøker avskrevet fra biblioteket.
Følgende hovedenheter i fagområdet kan skilles:
- bruker (bibliotekarer og administratorer);
- leser;
- leserom;
- bok;
- bokutstedelseskort;
- bokbestillingskort.
Det modifiserte ER-diagrammet for databasen er vist i figuren.
I henhold til brukstilfellene vist i figur 1, bør databasen implementere følgende spørringer (ikke en uttømmende liste):
- vise bøker som samsvarer med de angitte betingelsene;
- vise brukere som har kort for utstedelse av bøker som ikke er stengt i tide (bibliotekaren ser etter debitorer);
- vise alle bøkene som tilsvarer den gitte brukerens bokutlånskort som ikke ble stengt i tide (brukeren kom til biblioteket for nye bøker - du må se om han er en debitor og informere ham om det);
- slette alle bestillingskort opprettet for mer enn N sekunder siden;
- vise alle bøker som tilsvarer ulukkede bokreservasjonskort til den angitte brukeren (leseren bestilte bøker og kom til biblioteket for dem - bibliotekaren må få denne listen for å kunne gi den ut).
1.3 Skjemadannelse
For å danne et dataskjema må du først supplere ER-diagrammet med detaljene til enhetene (avgrense det). Noen ganger er det samtidig mulig å finne feil ved å konstruere et ER-diagram - i denne oppgaven ble det funnet at boken måtte være "på en eller annen måte" koblet til biblioteksalen.
Dette kan gjøres ved å plassere det nødvendige "hallnummeret" i boken, men med denne tilnærmingen vil den samme boken måtte beskrives i databasen flere ganger (hvis den forekommer i forskjellige haller). En mer korrekt tilnærming er å introdusere en ekstra enhet "bokplassering". Figuren viser et ER-diagram med en ekstra enhet og rekvisitter.
ER-diagrammet ovenfor gjenspeiler hovedtabeller, relasjoner og attributter; på grunnlag av det kan du bygge en databasemodell. Det er ingen standard for ER-diagrammet, men det finnes en rekke notasjoner (Chen, IDEFIX, Martin, etc.), men verken standarden eller notasjonene kunne finnes for domenemodellen. Men i løpet av å konstruere et slikt diagram, er nøkkelfelt (eksterne og interne) nødvendigvis uthevet, noen ganger indekser og datatyper.
I dette tilfellet, i følgende diagram:
- for lenker, Martins notasjon ("kråkeføtter" brukes);
- Tabeller er vist som rektangler delt inn i 3 seksjoner:
- tabellnavn;
- interne taster (merket med en markør);
- de resterende feltene, mens de obligatoriske er merket med en markør.
Ved utviklingen av denne modellen var det et ønske om å slå sammen administratortabellen med bibliotekartabellen - legg til brukertabellen, men:
- administratoren er ikke knyttet til et spesifikt rom (du må fylle ut det tilsvarende feltet med nullverdier);
- dette vil sannsynligvis komplisere distribusjonen av tilgangsrettigheter - nå har bare databaseadministratoren (som jobber gjennom et spesielt DBMS-panel og ikke har en konto i systemet som utvikles) tilgang til administratortabellen. Men når du slår sammen tabeller, vil brukerforespørsler kreve tilgang til den nye tabellen.
Ved konstruksjon av dette diagrammet ble en feil i ER-diagrammet funnet og rettet - det ble lagt til en tabell librarians_roomssom forener bibliotekarer og saler. Dette er nødvendig fordi én bibliotekar kan jobbe i flere rom, men flere bibliotekarer kan jobbe i samme rom.
Når du designer databaser, bør du kunne resonnere i det minste som eksempelet ovenfor. Hvis du tror at du lyktes, la oss gå videre: enda mer teori.
GO TO FULL VERSION