1.1 Inledning
Att designa en databas liknar något som att designa arkitekturen för ett Java-projekt. Du kan lägga all data i ett par tabeller, eller så kan du bygga en vacker datastruktur från scheman och dussintals tabeller.
Här är de uppgifter som en utvecklare vanligtvis står inför när han designar en databas:
- Se till att all nödvändig information lagras i databasen.
- Säkerställa möjligheten att få uppgifter om alla nödvändiga förfrågningar.
- Minska redundans och duplicering av data.
- Säkerställa databasintegritet
- Hastighetsoptimering för dataåtkomst
Det viktigaste att komma ihåg är att du inte kan skapa en idealisk databasstruktur, eftersom. den, liksom din kod, kommer också att ändras konstant. Det finns tre saker du bör tänka på när du utformar din databasstruktur:
- Strukturen måste vara tillräckligt bra.
- Det måste finnas en logik i allt som andra människor kan förstå.
- För tidig optimering är roten till allt ont.
Du behöver inte göra världens bästa databasstruktur. Hon kommer fortfarande att förändras. Din uppgift är att se till att efter 20 ändringar av strukturen i din databas är det lätt nog att ta reda på det.
Mest troligt under de första åren av ditt arbete kommer ingen att lita på att du designar en bas från grunden. Du kommer att göra ändringar i ett befintligt schema. Du måste försöka förstå utifrån vilka principer det är arrangerat och följa dem . Med sin charter klättrar de inte in i någon annans kloster.
Optimera inte databasen förrän det är nödvändigt. Om tabellen bara har ett par hundra rader kommer DBMS troligtvis att behålla den i minnet och cacheförfrågningar till den.
Å andra sidan bör du kunna påskynda arbetet med viktiga förfrågningar med tiotals eller till och med hundratals gånger. Och det skulle vara trevligt om du visste hur man gör. Hur säger de på gymnasiet första året? "Glöm allt du fick lära dig i skolan..."
Om du vet vad databasnormalisering är, då skyndar jag mig att behaga dig, i ditt arbete kommer du med största sannolikhet att ta itu med denormalisering . Ingenting är viktigare för projektets helgedomar än hastigheten på databasen. Och om du, för att påskynda valet av data från databasen, behöver kombinera 200 (!) tabeller till en (med monstruös redundans), måste du göra detta.
1.2 Biblioteksdesign
Låt oss dyka in i ämnesområdet lite och fundera på databasdesign med något så enkelt som ett typiskt bokbibliotek.
Huvuduppgiften för varje bibliotek är behandlingen av bokfonden. Det är lätt att särskilja tre huvudgrupper av systemanvändare: läsare, bibliotekarie, administratör . Aktiviteten för var och en visas i ett användningsfallsdiagram.
Redan nu kan vissa enheter och relationer i den framtida databasen urskiljas:
Med detta tillvägagångssätt är det inte klart hur man kopplar ihop läsaren med boken (läsaren har ingen aritet i förhållandet "utgivning/mottagning". Om boken har flera exemplar kan den ges ut till flera läsare. Även om en bok tolkas som ett exemplar, då när den sparas i den aktuella läsarens boktabell, kommer det att vara omöjligt att få information om vem (och hur många gånger) som tog den här boken tidigare.
Lösningen kan vara införandet av en ytterligare enhet - ett kort för att utfärda en bok. När boken ges ut till läsaren skapas ett kort och när boken överlämnas sätts ett motsvarande märke på det. Med hjälp av dessa kort bestäms varje användares skulder och statistik över användningen av böcker beräknas. Vid bokning av litteratur av läsaren startas även ett kort, om den bokade litteraturen inte tas av läsaren inom en viss period förstörs kortet. Det finns en gräns för hur många böcker en läsare kan boka.
När användaren väljer litteratur ser användaren litteraturkatalogen med möjlighet att filtrera sökresultaten efter författare, titel, utgivningsår.
Det är möjligt att räkna ut statistik för alla böcker i biblioteket, samtidigt som antalet utgivna exemplar av boken för en viss tidsperiod. Du kan också ställa in det minsta antal bokinstanser som beräkningen utförs för. Baserat på denna statistik skrivs oanvända böcker av från biblioteket.
Följande huvudenheter inom ämnesområdet kan särskiljas:
- användare (bibliotekarier och administratörer);
- läsare;
- läsrum;
- bok;
- bokutgivningskort;
- boka bokningskort.
Det modifierade ER-diagrammet för databasen visas i figuren.
Enligt användningsfallen som visas i figur 1 bör databasen implementera följande frågor (inte en uttömmande lista):
- visa böcker som matchar de angivna villkoren;
- visa användare som har kort för att ge ut böcker som inte har stängts i tid (bibliotekarien söker gäldenärer);
- visa alla böcker som motsvarar den givna användarens boklånekort som inte stängdes i tid (användaren kom till biblioteket för nya böcker - du måste se om han är gäldenär och informera honom om det);
- radera alla bokningskort skapade för mer än N sekunder sedan;
- visa alla böcker som motsvarar oslutna bokreservationskort för den angivna användaren (läsaren beställde böcker och kom till biblioteket för dem - bibliotekarien måste få den här listan för att kunna ge ut den).
1.3 Schemabildning
För att bilda ett dataschema måste du först komplettera ER-diagrammet med detaljerna för entiteterna (förfina det). Ibland är det samtidigt möjligt att hitta fel i att konstruera ett ER-diagram - i denna uppgift fann man att boken behövde vara "på något sätt" kopplad till bibliotekshallen.
Detta kan göras genom att placera det erforderliga "hallnumret" i boken, men med detta tillvägagångssätt måste samma bok beskrivas i databasen flera gånger (om den förekommer i olika salar). Ett mer korrekt tillvägagångssätt är att införa ytterligare en enhet "bokplacering". Figuren visar ett ER-diagram med en tillagd enhet och rekvisita.
Ovanstående ER-diagram återspeglar huvudtabellerna, relationerna och attributen; på grundval av det kan du bygga en databasmodell. Det finns ingen standard för ER-diagrammet, men det finns ett antal notationer (Chen, IDEFIX, Martin, etc.), men varken standarden eller notationerna kunde hittas för domänmodellen. Men under konstruktionen av ett sådant diagram markeras nyckelfält (externa och interna) nödvändigtvis, ibland index och datatyper.
I det här fallet, i följande diagram:
- för länkar, Martins notation ("kråkfötter" används);
- tabeller visas som rektanglar uppdelade i 3 sektioner:
- tabellnamn;
- interna nycklar (markerade med en markör);
- de återstående fälten, medan de obligatoriska är markerade med en markör.
När man utvecklade denna modell fanns det en önskan att ansluta administratörstabellen med bibliotekarietabellen - lägg till användartabellen, dock:
- administratören är inte associerad med ett specifikt rum (du skulle behöva fylla i motsvarande fält med nollvärden);
- detta skulle förmodligen komplicera fördelningen av åtkomsträttigheter - nu har bara databasadministratören (som arbetar via en speciell DBMS-panel och inte har ett konto i systemet som utvecklas) tillgång till administratörstabellen. Men när man går med i tabeller skulle användarfrågor kräva åtkomst till den nya tabellen.
När man konstruerade detta diagram hittades en brist i ER-diagrammet och korrigerades - en tabell lades till librarians_roomssom förenar bibliotekarier och salar. Detta är nödvändigt eftersom en bibliotekarie kan arbeta i flera rum, men flera bibliotekarier kan arbeta i samma rum.
När du designar databaser bör du kunna resonera åtminstone som exemplet ovan. Om du tror att du lyckades, låt oss gå längre: ännu mer teori.
GO TO FULL VERSION