När du utvecklar databasen kan du välja följande steg i arbetet.

Steg I. Formulering av problemet.

I detta skede bildas en uppgift för att skapa en databas. Det beskriver i detalj sammansättningen av basen, syftet och syftet med dess skapande, och är också listat vilka typer av arbete som är avsedda att utföras i den här databasen (urval, tillägg, ändring av data, utskrift eller utmatning av rapporten, etc. .).

Steg II. Analys av objektet.

I detta skede anses det från vilket objekt kan vara BD, vad egenskaperna hos dessa föremål kan. Efter att ha brutit databasen till enskilda objekt är det nödvändigt att överväga egenskaperna hos var och en av dessa föremål, eller med andra ord att ställa in vilka parametrar varje objekt som beskrivs. All denna information kan placeras som separata poster och tabeller. Därefter måste du överväga datatypen för varje enskild rekordenhet. Information om datatyp ska också tillämpas på tabellkomponenten.

III-scenen. Syntesmodell.

I detta skede, på analysen är det nödvändigt att välja en specifik modell av databasen. Följande är fördelarna och nackdelarna med varje modell och jämförs med kraven och uppgifterna i den skapade databasen. Efter en sådan analys väljer modellen som kan maximera genomförandet av uppgiften. Efter att ha valt modellen måste du dra den en krets med länkarna mellan tabeller eller noder.

IV-scenen. Välj sätt att presentera informations- och programvaruverktyg.

Efter att ha skapat modellen är det nödvändigt, beroende på den valda mjukvaruprodukten, bestämma formen av informationspresentation.

I de flesta DBMS kan data lagras i två typer:

använder former;

utan användning av former.

Formen är det användargenererade grafiska gränssnittet för datainmatning i databasen.

V-steg. Syntes av datormodellobjekt.

I processen att skapa en datormodell är vissa steg typiska för alla DBM.

Steg 1. Starta DBMS, skapa en ny databasfil eller öppnandet av den tidigare skapade basen.

Steg 2. Skapa ett källtabell eller tabeller.

Genom att skapa källtabellen måste du ange namn och typ av varje fält. Fältnamn ska inte upprepas i samma tabell. I arbetet med att arbeta med databasen kan du komplettera tabellen med nya fält. Det skapade bordet måste hållas, vilket ger ett namn, unikt inom ramen för det skapade.

• 1. Informationen i tabellen ska inte dupliceras. Det borde inte finnas några repetitioner mellan tabellerna. När specifik information endast lagras i ett bord, ändras det bara på ett ställe. Det fungerar effektivare, och utesluter också möjligheten att obeglastas av information i olika tabeller. Till exempel bör i samma tabell innehålla adresser och telefonnummer.
• 2. Varje tabell måste innehålla information endast på ett ämne. Information för varje ämne bearbetas mycket lättare om de finns i tabellerna oberoende av varandra. Till exempel är adresser och kundorder att lagras bättre i olika tabeller, så att klientinformationen kvarstår i databasen när du raderar en order.
• 3. Varje tabell måste innehålla de nödvändiga fälten. Varje fält i tabellen måste innehålla separat information på bordet. Till exempel kan ett bord med data på klienten innehålla fält med namnet på företaget, adress, stad, land och telefonnummer. När du utvecklar fält för varje tabell måste det komma ihåg att varje fält måste vara associerat med ämnets ämne. Det rekommenderas inte att inkludera i tabellen de data som är resultatet av ett uttryck. Bordet måste innehålla all nödvändig information. Information bör brytas till de minsta logiska enheterna (till exempel "namn" och "efternamn" -fälten, och inte det allmänna fältet "namn").
• 4. Databasen måste ha en primär nyckel. Detta är nödvändigt så att DBMS kan associera data från olika tabeller, till exempel data på klienten och dess order.

Steg 3. Skapa skärmformulär.

Inledningsvis måste du ange tabellen på grundval av vilken formuläret ska skapas. Det kan skapas med hjälp av en master av formulär, vilket indikerar vilken typ av den ska ha eller självständigt. När du skapar en blankett kan du inte ange alla fält som innehåller ett bord, men bara några av dem. Formenamnet kan sammanfalla med tabellnamnet, på grundval av vilket det skapas. Baserat på samma bord kan du skapa flera former som kan skilja sig åt i formuläret eller antalet fält som används från denna tabell. Efter att du har skapat måste formuläret sparas. Den skapade blanketten kan redigeras genom att ändra plats, storlekar och formatera fält.

Steg 4. Fyll i databasen.

Processen att fylla i databasen kan utföras i två typer: i form av ett bord och i form av en form. Numeriska och textfält kan fyllas i i form av ett bord och fälten av typmemo och ole är i form av en form.

VI-scenen. Arbeta med den skapade databasen.

Arbeta med databas innehåller följande åtgärder:

söka efter nödvändig information

datasortering;

dataval

utskrift;

Ändra och komplettera data.

Ämnen:databasdesignsteg, databasdesign baserat på typmodellen - Attityd.

Innan du skapar en databas måste utvecklaren bestämma de strumpbord som ska vara en databas, vilka data måste placeras i varje tabell, hur man knyter tabellerna. Dessa problem löses i databasdesignfasen.

Som ett resultat av konstruktionen bör databasens logiska struktur bestämmas, det vill säga sammansättningen av relationella tabeller, deras struktur och intersaginbindningar.

Innan du skapar en databas är det nödvändigt att ha en beskrivning av det valda ämnesområdet, som bör täcka verkliga objekt och processer, för att bestämma alla nödvändiga informationskällor för att möta de avsedda användarnas begäran och bestämma databehandlingsbehoven.

Baserat på en sådan beskrivning, vid databasdesignsteget, kompositionen och strukturen hos ämnesområdet, som måste vara i databasen och säkerställa uppfyllandet av de nödvändiga förfrågningarna och användaruppgifterna. Datastrukturen för ämnesområdet kan visas med den informationslogiska modellen. Baserat på denna modell skapas en relationsdatabas enkelt.

Steg i design och skapa en databas bestäms av följande sekvens:

Konstruera en informationslogisk modell av dataområdet;

Bestämning av den logiska strukturen i relationsdatabasen;

Konstruera databasbord;

Skapa ett dataschema

Ange data till tabeller (skapande av poster);

Utveckling av nödvändiga former, förfrågningar, makron, moduler, rapporter;

Användargränssnittsutveckling.

I processen att utveckla en datamodell är det nödvändigt att markera informationsobjekt som uppfyller kraven för datalisering och bestämningen av förhållandet mellan dem. Med den här modellen kan du skapa en relativ dupliceringsduplikation där en enda datainmatning tillhandahålls vid initial belastning och justeringar, samt dataintegritet vid ändringar.

När man utvecklar en datamodell kan två tillvägagångssätt användas. I det första tillvägagångssättet För det första bestäms de huvudsakliga uppgifterna, för den lösning som basen är byggd, är behoven hos uppgifter i data avslöjas och kompositionen och strukturen hos informationsobjekt bestäms i enlighet därmed. Med det andra tillvägagångssättet Omedelbart installerade typiska föremål av ämnesområdet. Den mest rationella kombinationen av båda tillvägagångssätten. Detta beror på det faktum att det i det första skedet som regel inte finns någon omfattande information om alla uppgifter. Användningen av sådan teknik är desto mer berättigad att flexibla verktyg för att skapa relationella databaser tillåter vid varje utvecklingsstadium att göra ändringar i databasen och modifiera sin struktur utan att det påverkar de uppgifter som anges tidigare.

Processen med att tilldela informationsobjekt av ämnesområdet som uppfyller kraven för normalisering kan utföras på grundval av ett intuitivt eller formellt tillvägagångssätt. De teoretiska grundarna för det formella tillvägagångssättet utvecklades och fullt fram anges i monografier på organisationen av databasen med en välkänd amerikansk forskare J. Martin.

Med ett intuitivt tillvägagångssätt kan informationsobjekt som motsvarar reella objekt lätt detekteras. Emellertid kräver den information och logiska modellen som erhållits samtidigt ytterligare omvandlingar, i synnerhet omvandlingen av många multivala länkar mellan föremål. Med detta tillvägagångssätt är betydande fel möjliga om det inte finns tillräcklig erfarenhet. Efterföljande verifiering av att uppfylla kraven för normalisering visar vanligtvis behovet av att klargöra informationsobjekt.

Tänk på formella regler som kan användas för att markera informationsobjekt:

Baserat på beskrivningen av ämnesområdet, avslöja dokumenten och deras attribut som ska lagras i databasen.

Bestämma de funktionella beroenden mellan attribut;

Välj alla de beroende attributen och specificera för varje alla dess nyckelattribut, dvs de som det beror på;

Gruppattribut är lika beroende av viktiga attribut. De erhållna grupperna av beroende attribut tillsammans med sina nyckelattribut bildar informationsobjekt.

Vid bestämning av den logiska strukturen i relationsdatabasen baserat på modellen visas varje informationsobjekt på ett tillfredsställande sätt med en relationell tabell, och länkarna mellan tabellerna motsvarar förhållandet mellan informationsobjekt.

I processen att skapa först är databastabellerna som motsvarar informationsobjekten hos den konstruerade datamodellen konstruerade. Därefter kan dataprogrammet skapas, där befintliga logiska länkar spelas in mellan tabellerna. Dessa obligationer motsvarar relationerna för informationsobjekt. I dataprogrammet kan parametrarna för att upprätthålla databasens integritet anges om datamodellen har utvecklats i enlighet med kraven på normalisering. Dataintegritet innebär att databaserna är installerade och korrekt stöds av förhållandet mellan poster av olika tabeller när du laddar, lägger till och tar bort poster i relaterade tabeller, såväl som när du ändrar nyckelfälten.

Efter att dataschemat genereras är det en inmatning av konsekventa data från ämnesområdet.

Baserat på den skapade databasen genereras de nödvändiga förfrågningarna, formulär, makron, moduler, rapporter som producerar den nödvändiga behandlingen av databasdata och deras representation.

Med hjälp av de inbyggda databasverktygen och verktygen skapas ett användargränssnitt som låter dig hantera inmatning, lagring, bearbetning, uppdateringar och databasinformation.

Designdatabas baserad på objektmodell - Attityd

Det finns ett antal metoder för att skapa informationslogiska modeller. En av de mest populära teknikerna i utvecklingen av modeller använder ERD (Entity-Relationship Diagrams). I rysk-språket litteratur, kallar dessa diagram "objekt - attityd" eller "essens - kommunikation". ERD-modellen föreslogs av Peter Ping Shen Chen 1976. Hittills har flera typer av sina sorter utvecklats, men de är alla baserade på grafiska diagram som föreslås av Chen. Diagram är konstruerade av ett litet antal komponenter. Tack vare synligheten av presentationen används de i stor utsträckning vid verktyg (datorstödd programsteknik).

Tänk på den terminologi som används och notationen.

Entitet- Ett verkligt eller imaginärt föremål som är avgörande för ämnesområdet som behandlas, information om var som är föremål för lagring.

Varje enhet måste ha en unik identifierare. Varje förekomst av enheten bör entydigt identifieras och skilja sig från alla andra fall av denna typ (enhet).

Varje enhet måste ha vissa egenskaper:

Ha ett unikt namn; Och samma tolkning (definition av enhet) ska alltid tillämpas på detta namn. Omvänt: Samma tolkning kan inte tillämpas på olika namn, såvida de inte är aliaser;

Har en eller flera attribut som antingen tillhör den enhet eller ärva den genom anslutningen;

Ha en eller flera attribut som definitivt identifierar alla instans av enheten.

Entitet kan vara oberoende eller beroende. Tecknet på den beroende enheten är närvaron av den ärvd genom anslutningen av attribut (fig 1.).

Varje enhet kan ha ett antal anslutningar med andra liknande enheter.

Kommunikation (förhållande)- Mottagad associering mellan två enheter, meningsfullt för ämnesområdet som behandlas. En av de enheter som deltar i anslutningen är oberoende, kallas föräldrakärnan, den andra är beroende, kallat ett dotterbolag eller en efterföljande väsen. Som regel är varje förekomst av föräldrakärnan förknippad med godtycklig (inklusive noll) av antalet exemplar av ett dotterbolag. Varje kopia av den efterkommande enheten är förknippad med en kopia av moderenheten. Således kan en förekomst av en efterföljande enhet existera endast med förekomsten av en moderenhet.

Kommunikation ger namnet uttryckt av verbets grammatiska omsättning och placeras nära länken.

Namnet på varje anslutning mellan de två enheterna bör vara unika, men namnen på länkar i modellen är inte nödvändiga för att vara unika. Varje anslutning har en definition. Definitionen av kommunikation bildas av anslutningen av förälderns namn, namnet på kommunikationen, uttrycket av kommunikationsgraden och namnet på efterkommarens essens.

Till exempel kan anslutningen av säljaren med kontraktet definieras enligt följande:

Säljaren kan få ersättning för ett eller flera kontrakt.

Kontraktet måste initieras av exakt en säljare.

På diagrammet är anslutningen avbildad av ett segment (bruten). Segmenten av segmentet med speciella beteckningar (fig 2) indikerar graden av kommunikation. Dessutom är linjens natur en streckkod eller fast, indikerar kommunikationsskyldigheten.

Attribut- Eventuella kännetecken för kärnan, meningsfullt för ämnesområdet som behandlas. Den är avsedd för kvalifikationer, identifiering, klassificering, kvantitativa egenskaper eller uttryck av tillståndet. Attributet representerar typen av egenskaper (egenskaper) som är förknippade med ett flertal verkliga eller abstrakta föremål (personer, platser, händelser, stater, idéer, föremål, etc.) (fig 3).

Attribut förekomst - Detta är en viss egenskap för en specifik instans av enheten. Attributinstansen bestäms av typen av egenskap (till exempel "färg") och dess värde (till exempel "lilac"), kallad attributvärdet. ER-modellattributen är förknippade med specifika enheter. Varje enhet förekomst måste ha ett specifikt värde för var och en av sitt attribut.

Attribut kan vara antingen obligatoriskantingen frivillig. Compelling betyder att attributet inte kan göra odefinierade värden (nollvärden). Attributet kan vara antingen beskrivande (dvs den vanliga beskrivaren av enheten) eller för att komma in i den unika identifieraren (primär nyckel).

Unik identifiator- Detta är ett attribut eller en uppsättning attribut och / eller anslutningar, som är unikt karaktäriserande varje förekomst av denna typ av enhet. När det gäller fullständig identifiering är förekomsten av denna typ av enhet helt identifierat av sina egna nyckelattribut, annars är attribut av en annan enhet - föräldrar också involverade i identifiering.

Karaktären hos identifieringen visas i kommunikationsdiagrammet (bild 4).

Varje attribut identifieras med ett unikt namn uttryckt av substantivets grammatiska cirkulation, som beskriver den egenskap som representeras av attributet. Attribut är avbildade som en lista med namn i blocket av den associerade enheten, varje attribut tar en separat linje. Attribut som definierar den primära nyckeln placeras längst upp på listan och sticka ut för "#" -skylten.

Varje enhet bör ha minst en möjlig nyckel. En möjlig nyckel av enhet är en eller flera attribut vars värden unikt definierar varje instans av enheten. Med förekomsten av flera möjliga nycklar indikeras en av dem som den primära nyckeln, och resten är som alternativa nycklar.

För närvarande skapas IDEF1X-metoden baserat på Chen-tillvägagångssättet, som är utformat för att möta sådana krav som enkelhet att lära sig och förmågan att automatisera. IDEFLX-diagram används av ett antal vanliga fallfonder (i synnerhet Erwin, design / IDEF).

Kärnan i Idef1x-metodiken kallas oberoende av identifierare eller helt enkelt oberoende om varje förekomst av enheten kan identifieras utan att bestämma sina relationer med andra enheter. Kärnan kallas beroende av identifierare eller helt enkelt beroende, om den entydiga identifieringen av det här enheten beror på dess förhållande till en annan enhet (fig 5).

Varje enhet tilldelas ett unikt namn och ett tal separerat med snett funktion "/" och placeras ovanför blocket.

Om en kopia av den efterkommande enheten är unikt bestämd av hans relation med kärnan i föräldern, kallas anslutningen identifiering, annars - icke-identifierande.

Det identifierande förhållandet mellan kärnan i föräldern och enhetens ättling är avbildad med en solid linje. I fig. 5: Nr 2 - Beroende essens, kommunikation 1 - Identifiera kommunikation. Efterkommarens enhet i identifieringskommunikationen är kärnan som är beroende av identifieraren. Föräldraenheten i identifieringskommunikationen kan vara både oberoende och beroende av identifieraren (detta bestäms av dess anslutningar med andra enheter).

Den streckade linjen visar en oidentifierande kommunikation. I fig. 5: №4 - Oberoende enhet, kommunikation 2 - Oidentifierar. Efterkommarens enhet i en oidentifierbar kommunikation kommer att vara oberoende av identifieraren om den inte heller är en efterföljande enhet i någon identifieringskommunikation.

Kommunikation kan dessutom definieras med hjälp av graden eller effektindikationen (antalet arter enheter, som kan existera för varje instans av moderenheten).

Följande länkar kan uttryckas i IDEF1X:

Varje förekomst av moderenheten kan ha en noll, en eller flera artrelaterade instanser av efterkommaren;

Varje förekomst av moderföretaget måste ha minst en relaterad kopia av den efterkommande enheten;

Varje förekomst av moderföretaget bör inte ha mer än en-relaterad kopia av den efterkommande enheten;

Varje förekomst av moderenheten är förknippad med något fast antal arter av den efterkommande enheten.

Kommunikationseffekt indikeras som visas i fig. 6 (Standardkraft - n).

Attribut är avbildade som en lista med namn i essensblocket. Attribut som definierar den primära nyckeln placeras högst upp på listan och är separerade från andra attribut med en horisontell linje (fig 7).

Resultatet är en informations- och logisk modell som används av ett antal vanliga fallverktyg, som Erwin, Design / IDEF. I sin tur har Case Technologies hög potential när man utvecklar databaser och informationssystem, nämligen en ökning av arbetskraftens produktivitet, vilket förbättrar kvaliteten på mjukvaruprodukter, som stöder en enhetlig och samordnad arbetsstil.

Enheter kan också ha externa nycklar (utländsk nyckel). Vid identifiering av kommunikation används de som en del eller en hel primär nyckel, med oidentifierande - tjäna som försummade attribut. I attributlistan är den externa nyckeln markerad med bokstäver FK i parentes.

Databasdesignsteg

Alla subtiliteter för att bygga en informationsmodell av ett visst ämnesområde för mänsklig verksamhet förföljer ett mål - att få en bra databas. Vi kommer att förklara termen - en bra databas och formulera de krav som sådana databaser ska uppfylla:

1. Databasen ska uppfylla användarnas informationsbehov (organisationer) och i struktur och innehåll för att följa lösta mål.

2. Databasen ska säkerställa de erhållna data för en acceptabel tid, d.v.s. svara på prestandakrav

3. Databasen bör enkelt expanderas i omorganisationen av ämnesområdet.

4. Databasen ska enkelt ändras vid byte av programvara och hårdvaru.

5. De korrekta data som laddas i databasen måste förbli korrekta (data ska kontrolleras för korrekthet när de går in i dem).

Tänk på de främsta stadierna av designen (bild 3.5):

Första stadiet. Planering av databasutveckling. I detta skede fördelas det mest effektiva sättet att genomföra stadierna i systemets livscykel.

Andra fasen. Bestämning av systemkrav. Utbudet av åtgärder och gränser för databasprogrammet bestäms, och analysen av användarkraven samlas in.

Tredje etapp. Utforma den konceptuella modellen i databasen. Processen med att skapa en databas börjar med definitionen av en konceptuell modell som representerar objekt och deras förhållande utan att ange metoderna för deras fysiska lagring. Ansträngningarna i detta skede bör inriktas på att strukturera data och identifiera förhållandet mellan dem. Denna process kan delas upp i några fler subteps:

a) Förtydligande av uppgiften. Även innan du börjar arbeta med en specifik applikation har utvecklaren vanligtvis några idéer som den kommer att utvecklas. I andra fall, när en liten personlig databas utvecklas, kan sådana representationer vara ganska fullständiga. I andra fall, när en stor databas utvecklas under ordern, kan sådana representationer vara mycket små, eller de kommer säkert att vara ytliga. Omedelbart börjar utveckla med definierande tabeller, fält och anslutningar mellan dem är klart för tidigt. Detta tillvägagångssätt kan leda till en fullständig ändring av det mesta av ansökan. Därför bör den spenderas tid på att utarbeta en lista över alla huvuduppgifter, som i princip bör lösas genom denna ansökan, inklusive de som kan uppstå i framtiden.

Fikon. 3,5. Design Scheme BD

b) Förfining av uppgiftsexekveringssekvensen. För att ansökan ska kunna arbeta logiskt och bekvämt är det bäst att kombinera de viktigaste uppgifterna i koncernen och sedan effektivisera arbetsgrupperna för varje grupp så att de är för att utföra dem. Gruppering och grafisk representation av sekvensen av deras utförande kommer att bidra till att bestämma det naturliga förfarandet för utförande av uppgifter.

c) Dataanalys. Efter att ha definierat uppgiftslistan är det nödvändigt för varje uppgift att göra en detaljerad lista över data som krävs för att lösa den. Efter dataanalysfasen kan du fortsätta utveckla en konceptmodell, d.v.s. till fördelningen av objekt, attribut och anslutningar.

Fjärde scenen. Bygga en logisk modell. Att bygga en logisk modell börjar med ett datamodellval. När du väljer en modell, är dess enkelhet, synlighet och jämförelse av den naturliga strukturen av data med den modell som representerar den en viktig roll. Om den hierarkiska strukturen är inneboende i själva data, kommer valet av hierarkisk modell att föredra. Men ofta bestäms detta val av framgången (eller närvaro) av en viss DBMS. Det vill säga, utvecklaren väljer DBMS, och inte datamodellen. Således, i detta skede, är den konceptuella modellen översatt till en datamodell som är kompatibel med den valda DBMS. Det är möjligt att de relationer som visas i den konceptuella modellen mellan objekt eller några av objektattributen kommer senare att orealiseras med hjälp av den valda DBMS. Detta kommer att kräva en förändring i den konceptuella modellen. Versionen av den konceptuella modellen, som kan förses med en specifik DBM, kallas logisk modell. Ibland kallas processen med att bestämma de konceptuella och logiska modellerna definitionen av datastrukturen.

Femte scenen. Bygga en fysisk modell. Den fysiska modellen definierar dataplacering, åtkomstmetoder och indexeringsteknik. Vid det fysiska designsteget är vi knutna till en specifik DBMS och beskriver datanordningen mer detaljerat, vilket indikerar typerna, fältstorleken och restriktionerna. Förutom utvecklingen av tabeller och index, i detta skede, bestäms också de viktigaste förfrågningarna.

När man bygger en fysisk modell är det nödvändigt att lösa två ömsesidigt motsatta uppgifter i sin väsen. Den första av dessa är att minimera lagringsplatsen, och den andra är att uppnå maximal prestanda, integritet och datasäkerhet. För att till exempel säkerställa hög sökhastighet är det nödvändigt att skapa index, och deras antal kommer att bestämmas av alla möjliga kombinationer av fält som är involverade i sökningen. För att återställa data behöver du logga in alla ändringar och skapa säkerhetskopior av databasen. För effektiv drift av transaktioner krävs diskutrymmet för tillfälliga föremål, etc., vilket leder till en ökning (ibland signifikant) databasstorlek.

Sjätte scenen. Bedömning av den fysiska modellen. I detta skede en bedömning av prestanda. Här kan du kontrollera effektiviteten i frågor, sökhastighet, korrekthet och bekvämlighet att utföra operationer med databasen, dataintegritet och effektivitet i datorresurser. Med otillfredsställande prestanda är det möjligt att återgå till revisionen av fysiska och logiska datamodeller, valet av DBMS och typ av dator.

Sjunde scenen. Realisering av databasen. Med tillfredsställande prestanda kan du fortsätta skapa en layout av programmet, det vill säga en uppsättning grundläggande tabeller, önskemål, formulär och rapporter. Denna preliminära layout kan demonstreras för kunden och få det godkännande före godkännande av ansökan.

Åttonde scenen. Testning och optimering. Det önskade steget är att testa och optimera den utvecklade applikationen.

Steg nionde, final. Medföljande och operation. Eftersom det är omöjligt att identifiera och eliminera alla fel i testfasen, är ackompanjemangssteget vanligt för databaser.

Det finns två huvudsakliga tillvägagångssätt för utformningen av dataschemat: nedåt och uppåt. Med ett uppåtriktat tillvägagångssätt börjar arbetet från den lägre nivån - nivån av definitionen av attribut, som, baserat på analysen av de befintliga förbindelserna, är grupperade i relationerna, som representerar föremål och länkar mellan dem. Processen med normalisering av tabeller för en relationell datamodell är ett typiskt exempel på detta tillvägagångssätt. Detta tillvägagångssätt är väl lämpat för att utforma relativt små databaser. Med en ökning av antalet attribut till flera hundra och till och med tusentals mer lämplig designstrategi är ett nedåtriktat tillvägagångssätt. Detta tillvägagångssätt börjar med definitionen av flera högkvalitativa enheter och anslutningar mellan dem. Därefter beskrivs dessa objekt till önskad nivå. Ett exempel på denna design-tillvägagångssätt är användningen av "Essence-Communication" -modellen. I praktiken kombineras dessa metoder vanligtvis. I det här fallet kan du prata om det blandade designmetoden.

Steg 1. Förtydligande av uppgifter

Vid första etappen utarbetas en lista över alla större uppgifter, som i princip bör lösas genom denna ansökan - inklusive de som inte behövs idag, men kan förekomma i framtiden. Under de "huvudsakliga" uppgifterna är de funktioner som måste presenteras i formuläret eller rapporterna om ansökan.

Steg 2. Uppgiftsprestationssekvens

För att ansökan ska kunna arbeta logiskt och bekvämt är det bäst att kombinera de viktigaste uppgifterna i tematiska grupper och sedan effektivisera arbetsgrupperna så att de befinner sig i storleksordningen för deras utförande. Det kan visa sig att vissa uppgifter kommer att vara associerade med olika grupper eller att genomförandet av en viss uppgift ska föregå utförandet av en annan tillhörighet till en annan grupp.

Steg 3. Dataanalys

Efter att ha skapat en lista över uppgifter är det viktigaste steget att utarbeta en detaljerad lista över alla data som är nödvändiga för att lösa varje uppgift. Vissa data kommer att behövas som källan och kommer inte att förändras. Andra data kommer att kontrolleras och ändras under uppgiften. Vissa dataelement kan raderas eller läggas till. Slutligen kommer vissa data att erhållas genom beräkningar: deras produktion kommer att ingå i uppgiften, men de kommer inte att ingå i databasen.

Steg 4. Definition av datastruktur

Efter den preliminära analysen av alla nödvändiga dataobjekt måste du effektivisera dem på objekt och relatera objekt med tabeller och databasförfrågningar. För relationella databaser används åtkomsttypen av processen som kallas normalisering, som ett resultat av vilket den mest effektiva och flexibla lagringsmetoden produceras.

Steg 5. Utveckling av applikationslayout och användargränssnitt

Efter att ha ställt in programtexten är Microsoft Access lätt att skapa sin layout med former och länka dem med okomplicerade makron eller händelsebehandlingsförfaranden. Den preliminära arbetsanläggningen är lätt att demonstrera för kunden och få det godkännande före godkännandet av ansökningsuppgifterna.

Steg 6. Skapa en ansökan

När det gäller mycket enkla uppgifter är den skapade layouten en praktiskt slutlig applikation. Det är dock ganska ofta nödvändigt att skriva förfaranden som gör att du kan automatisera lösningen av alla uppgifter som planeras i projektet. Därför måste du skapa speciella bindemedel som ger övergången från en uppgift till en annan.

Steg 7. Testning och förbättring

Efter att ha slutfört arbetet med enskilda komponenter i programmet måste du kontrollera programmets funktion i var och en av de möjliga lägena. Det är nödvändigt att testa makronen, för att göra detta, med hjälp av det steg-för-steg debug-läget där ett visst makro kommer att utföras. När du använder Visual Basic, är Applications till ditt förfogande Det finns en mängd olika felsökningsverktyg som låter dig kontrollera programmet, avslöja och korrigera fel.

Som konstruktion av autonoma delar av ansökan är det lämpligt att överföra dem till kunden för att kontrollera deras funktion och få en åsikt om behovet av att göra några ändringar. När kunden blir bekant med ansökans arbete har det nästan alltid ytterligare förslag på förbättring, oavsett om de är noggranna preliminära projekt i projektet. Användare tycker ofta att vissa punkter om vilka i processen med att ställa in uppgifter, de pratade som mycket viktiga och nödvändiga, faktiskt inte spelar en viktig roll i den praktiska användningen av ansökan. Identifieringen av de nödvändiga förändringarna i de tidiga stadierna av applikationsutvecklingen gör det möjligt att avsevärt minska tiden för efterföljande ändringar.

Grunden för metodiken för att utforma tillämpade program lades på 60-talet av XX-talet av kända specialister från J. Martin, E. Jordon och D. Konstantyn. Vid gryningsapplikationen av datorutrustning var utvecklingen av program, sökandet och eliminering av fel så dyra att de erfarna praktikprogrammerare ofta rekommenderade: innan de skrev minst en rad av programmet är det värt att spendera minst 60% av alla nödvändiga att utveckla tid för design.

Modern teknikutvecklingsteknik gör byggandet av applikationer fantastiskt billiga och snabbt. En kvalificerad användare med Microsoft Access idag kan skapa på en persondator för en kväll att på tidiga datorer krävde månader av arbete (om det var möjligt möjligt). Dessutom har det blivit mycket lättare att hitta fel, eliminera dem och ändra projektet i processen att skapa en applikation. Modern teknik gör att du kan skapa mycket komplexa tillämpningar. Dessutom har beräkningshastigheten jämfört med det föregående decenniet ökat med flera storleksordningar. Men trots fondens kraft, om du inte spenderar stora ansträngningar för att bestämma ansökans uppgifter och principer, måste du senare förlora mycket längre tid för alla typer av ändringar. Om ansökans förslag inte är tillräckligt uttänkt, kommer tillägget av nya särdrag eller brister att vara förknippade med stora tillfälliga och finansiella kostnader.

Tänk på de viktigaste stadierna av designdatabasen

Designdatabas

I Microsoft Access, innan du skapar tabeller, former och andra objekt, måste du ange databasstrukturen. En bra databasstruktur är grunden för att skapa tillräckliga krav, en effektiv databas.

Databasdesignsteg

Nedan är de viktigaste stadierna av databasdesign:

Definiera målet att skapa en databas.

Definiera tabeller som måste innehålla en databas.

Bestämning av de fält som krävs i tabellen.

Ställa in ett individuellt värde till varje fält.

Definition av band mellan tabeller.

Uppdatering av databasstrukturen.

Lägga till data och skapa andra RBECTS .6 Data data.

Använd analys till Microsoft Access.

1. Definiera målet att skapa en databas

Vid den första etappen av databasdesignen är det nödvändigt att bestämma syftet med att skapa en databas, huvudfunktionerna och den information den ska innehålla. Det är det är nödvändigt att bestämma huvudämnena i databasborden och den information som fältfält innehåller.

Databasen måste uppfylla kraven för dem som kommer att arbeta direkt med det. För att göra detta är det nödvändigt att bestämma de teman som databasen måste täcka de rapporter som den ska utfärda, analysera de formulär som för närvarande används för att spela in data, jämföra den genererade databasen med en väldesignad bas som liknar den.

2. Definition av tabeller som måste innehålla en databas

En av de svåraste stegen i databasens designprocess är att utveckla tabeller, eftersom de resultat som databasen måste utfärdas (rapporter, utgångsformer etc.) inte alltid ger en komplett bild av tabellstrukturen.

Vid utformning av tabeller använder du inte nödvändigtvis Microsoft Access. För det första är det bättre att utveckla en struktur på papper. Vid utformning av tabeller rekommenderas det att styras av följande grundläggande principer:

Informationen i tabellen ska inte dupliceras. Det borde inte finnas några repetitioner mellan tabellerna.

När viss information endast lagras i ett bord, kommer den bara att ändras på ett ställe. Det fungerar effektivare, och utesluter också möjligheten att obeglastas av information i olika tabeller. Till exempel bör i samma tabell innehålla adresser och telefonnummer.

Varje tabell måste innehålla information endast på ett ämne.

Informationen för varje ämne bearbetas mycket lättare om de finns i tabellerna oberoende av varandra. Till exempel lagras adresser och kundorder i olika tabeller, så att kundinformationen kvarstår i databasen när du tar bort en order.