Viktiga steg för databasdesign

2.1. Konceptdesign

Databasdesign utförs i tre steg:

1. konceptdesign;
2. logisk design;
3. fysisk design.

Syftet med den konceptuella designfasen är att skapa en konceptuell datamodell utifrån användarnas idéer om ämnesområdet. För att uppnå det utförs en serie sekventiella procedurer. Ett exempel på ett entitetsschema (konceptuellt):

1. Definition av enheter och deras dokumentation. För att identifiera entiteter definieras objekt som existerar oberoende av andra. Sådana objekt är enheter. Varje enhet får ett meningsfullt namn som användarna kan förstå. Namnen och beskrivningarna av enheterna förs in i dataordboken. Om möjligt ställs det förväntade antalet instanser av varje entitet in.

2. Fastställande av relationer mellan enheter och deras dokumentation. Endast de relationer mellan enheter definieras som är nödvändiga för att uppfylla databasdesignkraven. Typen av varje är inställd. Medlemsklassen av enheter avslöjas. Länkar tilldelas meningsfulla namn uttryckta med verb. En detaljerad beskrivning av varje anslutning, som anger dess typ och tillhörighetsklassen för de enheter som deltar i anslutningen, läggs in i dataordlistan.

3. Skapande av en ER-modell av ämnesområdet. ER-diagram används för att representera enheter och relationer mellan dem. Utifrån dem skapas en enda visuell bild av det modellerade ämnesområdet - ER-modellen av ämnesområdet.

4. Definition av attribut och deras dokumentation. Alla attribut som beskriver enheterna i den skapade ER-modellen avslöjas. Varje attribut ges ett meningsfullt namn som användarna kan förstå. Följande information lagras i dataordboken för varje attribut:

• attributnamn och beskrivning;
• typ och dimension av värden;
• standardvärdet för attributet (om något);
• om attributet kan ha NULL-värden;
• om attributet är sammansatt, och i så fall vilka enkla attribut det består av. Till exempel kan attributet "Kundens fullständiga namn" bestå av enkla attribut "Efternamn", "Förnamn", "Patronym", eller det kan vara enkelt, innehålla enstaka värden, som "Sidorsky Evgeniy Mikhailovich". Om användaren inte behöver tillgång till individuella element i "Namn", så presenteras attributet som enkelt;
• om attributet beräknas, och i så fall hur dess värden beräknas.

5. Definition av attributvärden och deras dokumentation. För varje attribut för en enhet som deltar i ER-modellen bestäms en uppsättning giltiga värden och ett namn tilldelas den. Till exempel kan attributet "Kontotyp" bara ha värdena "insättning", "aktuell", "på begäran", "kortkonto". Datalexikonposterna relaterade till attributen uppdateras med namnen på attributvärdesuppsättningarna.

6. Definition av primärnycklar för enheter och deras dokumentation. Detta steg styrs av definitionen av en primärnyckel - som ett attribut eller en uppsättning attribut för en entitet som tillåter unik identifiering av dess instanser. Primär nyckelinformation placeras i dataordboken.

7. Diskussion av den konceptuella datamodellen med slutanvändare. Den konceptuella datamodellen representeras av en ER-modell med tillhörande dokumentation som innehåller en beskrivning av den utvecklade datamodellen. Om domäninkonsekvenser upptäcks, görs ändringar i modellen tills användarna bekräftar att modellen som föreslagits av dem på ett adekvat sätt återspeglar deras personliga åsikter.

2.2 Logisk design

Syftet med det logiska designsteget är att omvandla den konceptuella modellen baserad på den valda datamodellen till en logisk modell som är oberoende av funktionerna i DBMS som senare används för den fysiska implementeringen av databasen. För att uppnå det utförs följande procedurer.

Ett exempel på ett logiskt databasschema.

1. Välja en datamodell. Oftast väljs en relationsdatamodell på grund av tydligheten i den tabellformade presentationen av data och bekvämligheten att arbeta med dem.

2. Definiera en uppsättning tabeller baserade på ER-modellen och dokumentera dem. En tabell skapas för varje entitet i ER-modellen. Entitetsnamn är namnet på tabellen. Relationer mellan tabeller upprättas genom mekanismen för primära och främmande nycklar. Tabellernas strukturer och etablerade relationer mellan dem dokumenteras.

3. Normalisering av tabeller. För att korrekt utföra normalisering måste designern på djupet förstå semantiken och användningsmönster för data. I det här steget kontrollerar han riktigheten av strukturen för tabellerna som skapades i föregående steg genom att tillämpa normaliseringsproceduren på dem. Det består i att ta vart och ett av borden till åtminstone 3:e NF. Som ett resultat av normalisering erhålls en mycket flexibel databasdesign, vilket gör det enkelt att göra nödvändiga tillägg till den.

4. Kontrollera den logiska datamodellen för möjligheten att utföra alla transaktioner som tillhandahålls av användare. En transaktion är en uppsättning åtgärder som utförs av en enskild användare eller applikationsprogram för att ändra innehållet i en databas. Så, ett exempel på en transaktion i BANK-projektet kan vara överföringen av rätten att hantera en viss kunds konton till en annan kund. I det här fallet kommer flera ändringar att behöva göras i databasen på en gång. Om en dator kraschar under en transaktion kommer databasen att vara i ett inkonsekvent tillstånd eftersom vissa ändringar redan har gjorts och andra inte. Därför måste alla partiella ändringar ångras för att återställa databasen till dess tidigare konsekventa tillstånd.

Listan över transaktioner bestäms av användarnas handlingar i ämnesområdet. Med hjälp av ER-modellen, dataordboken och etablerade relationer mellan primära och främmande nycklar görs ett försök att utföra alla nödvändiga dataåtkomstoperationer manuellt. Om någon manuell operation misslyckas, är den kompilerade logiska datamodellen otillräcklig och innehåller fel som måste elimineras. Kanske är de relaterade till en lucka i modellen för en enhet, relation eller attribut.

5. Fastställande av stödkrav för dataintegritet och deras dokumentation. Dessa krav är restriktioner som sätts på plats för att förhindra att motstridiga data matas in i databasen. I detta steg täcks dataintegritetsfrågor utan hänsyn till specifika aspekter av dess implementering. Följande typer av begränsningar bör övervägas:

• nödvändig data. Ta reda på om det finns attribut som inte kan ha NULL-värden;
• restriktioner för attributvärden. Giltiga värden för attribut är definierade;
• enhetens integritet. Det uppnås om enhetens primärnyckel inte innehåller NULL-värden;
• referensintegritet. Det är underförstått att det främmande nyckelvärdet måste finnas i primärnyckeln för en av tabellraderna för den överordnade enheten;
• begränsningar som införs av affärsregler. Till exempel, i fallet med BANK-projektet, kan en regel antas som förbjuder kunden att hantera till exempel mer än tre konton.

Information om alla etablerade dataintegritetsbegränsningar placeras i dataordboken.

6. Skapande av den slutliga versionen av den logiska datamodellen och diskussion med användare. Detta steg förbereder den slutliga versionen av ER-modellen, som representerar den logiska datamodellen. Själva modellen och uppdaterad dokumentation, inklusive dataordboken och länkschemat för relationstabeller, presenteras för granskning och analys av användare, som måste säkerställa att den representerar ämnesområdet korrekt.

2.3. Fysisk design

Syftet med det fysiska designsteget är att beskriva en specifik implementering av en databas som finns i en dators externa minne. Detta är en beskrivning av datalagringsstrukturen och effektiva metoder för att komma åt databasdata. I logisk design svarar de på frågan - vad som behöver göras, och i fysisk design - väljs ett sätt hur man gör det. De fysiska designprocedurerna är som följer.

1. Designa databastabeller med det valda DBMS. En relations-DBMS väljs för att användas för att skapa en databas som är värd på maskinmedia. Dess funktionalitet för att designa bord är djupt studerade. Sedan utförs designen av tabeller och schemat för deras anslutning i DBMS-miljön. Det förberedda databasprojektet beskrivs i den medföljande dokumentationen.

2. Implementering av affärsregler i miljön för det valda DBMS. Uppdatering av information i tabeller kan begränsas av affärsregler. Hur de implementeras beror på det valda DBMS. Vissa system för att implementera kraven inom ämnesområdet erbjuder fler funktioner, andra mindre. I vissa system finns det inget stöd för att implementera affärsregler alls. I det här fallet utvecklas applikationer för att implementera sina begränsningar.

Alla beslut som fattas i samband med implementering av domänaffärsregler beskrivs i detalj i den medföljande dokumentationen.

3. Designa den fysiska organisationen av databasen. Detta steg väljer den bästa filorganisationen för tabellerna. Transaktionerna som kommer att utföras i databasen som designas identifieras och de viktigaste av dem markeras. Transaktionsgenomströmning analyseras - antalet transaktioner som kan behandlas under ett givet tidsintervall och svarstid - den tidsperiod som krävs för att slutföra en transaktion. De strävar efter att öka transaktionsgenomströmningen och minska svarstiden.

Baserat på dessa indikatorer fattas beslut om att optimera databasens prestanda genom att definiera index i tabeller som påskyndar urvalet av data från databasen, eller genom att minska kraven på nivån av tabellnormalisering. Det diskutrymme som krävs för att rymma den skapade databasen uppskattas. Sträva efter att minimera det.

Beslut som fattas i ovanstående frågor dokumenteras.

4. Utveckling av en databasskyddsstrategi. Databasen är en värdefull företagsresurs och mycket uppmärksamhet ägnas åt att skydda den. För att göra detta måste designers ha en fullständig och tydlig förståelse för alla skydd som tillhandahålls av det valda DBMS.

5. Organisation av databasfungerande övervakning och dess justering. Efter skapandet av det fysiska projektet för databasen organiseras kontinuerlig övervakning av dess funktion. Den resulterande informationen om prestandanivån för databasen används för att ställa in den. För detta är också medel för det valda DBMS inblandade.

Beslut om att göra ändringar i en fungerande databas bör övervägas och vägas noggrant.