Analyse av en database

Innledning

Når du utformer en programvare som grensesnitt mot en database, det være seg til skrivebordet eller web-grensesnitt, det er dedikert til en spesiell bruk enn til en annen, bør du alltid gjøre en grundig analyse for å unngå å måtte forholde med temaer som referanseintegritet, data redundans, etc..

Hensikten med denne analysen er et viktig arbeid: å oppnå best optimalisering av data og ressurser i påvente av fremtidige endringer i databasen eller implementeringer.

Formålet med denne artikkelen er å sette leseren til å takle sine egne prosjekter i fremtiden start høyre fot under organisering av informasjon for å styre, eller i en posisjon til å bære rundt på en godt utformet database, programvare og mer strømlinjeformet ytelse.

Hvem er kunden?

Det er et dumt spørsmål eller for stor? Kanskje, men du kan begynne å gi to-mark svar:

1. Jeg må tilfredsstille kunden;
2. å tilfredsstille kunden ... er en kunde.

Tilfelle 1. Er du sikker på at du har klare ideer om hva du trenger? Sikker på at du har vurdert alle alle alle? Er du sikker på at du ikke har for mye hastverk?

Hvis du ikke har stilt disse spørsmålene ... ponitele!

Jeg har bare adressert til leseren på en veldig direkte tone, unngå poenget, slår han at jeg ikke kan, og nå ønsker jeg å unngå å svare på det andre tilfellet.

Case 2. Kunden er ikke å tilfredsstille utbygger, men noen som kan ha et minimum av datakunnskap eller ikke. Hvis du har noen kunnskap kan forenkle våre liv fordi "vi snakker samme språk", eller er det en pedantisk at livet har en tendens til å komplisere den neste. Eller er en person som forstår ingenting, men maskinen vet hva han vil (sjelden) eller du kan gi oss beskjed. Eller vet ikke engang hva han ønsker eller er i stand til å gi nødvendig informasjon.

Ta dette som en lov: aldri ta noe for gitt, alle som har møtt! Det er bedre å være petulant, vurdere og revurdere alt, for å unngå å nå den konklusjon at, fordi de som eier eller prøve å møte er galt for en eller annen grunn.

Jeg avslutter dette nødvendig parentes sannsynlig å gi leseren forstå at det viktigste er å ha klare ideer, har en gryte av informasjon er ennå ikke organisert for å organisere den beste, som vi diskuterer nedenfor.

Lag en god analyse av en database

Som det fremgår av SQL Guide av dette området, SQL språk fremfor de ulike operatørene av databasen (MS Access, MySQL, og så videre) er ikke vanskelig å bruke. Jada, det er mer eller mindre komplekse produkter eller intuitivt, men det er ikke poenget.

Poenget er å vite hva de skal gjøre!

Sjon og derfor anta at leseren har et minimum av kognisjon i form av en relasjonsdatabase, kjenner SQL språket og vet hvordan å bruke noen DBMS, som er irrelevant for valg av produkt for den hensikt å forstå denne artikkelen.

Ting å gjøre kan oppsummeres i seks punkter:

1. samle informasjon for å håndtere;
2. dele dem inn i logiske grupper;
3. godt å tenke på splitting tabeller og datatyper som skal brukes;
4. tror at "andel" av redundans du ønsker å være;
5. anta en annen struktur;
6. slå av datamaskinen, stirrer i taket, til å revurdere strukturen

Denne uttalelsen er både alvorlig og humoristisk, selv til et visst punkt: det er sagt at den første idé er den rette (dette er betydningen av § 5) og det er best å legge merke til før du begynner å skrive programvaren ledelsen "rundt" til databasen.

Eksempel: database strukturen i en katalog av selskaper

Det er veldig populært på nettet de siste årene begrepet kataloger, er det en katalog for indeksering, er det en katalog for å søke etter produkter, tjenester, bedrifter og så videre.

Ikke å kunne eksos all den kunnskapen i denne sammenhengen knyttet til en database for å administrere (serien går til uendelig og utover) vi prøver å lage en datastruktur for å håndtere denne type tjeneste.

Hva må han gjøre denne tjenesten?

1. samle brukere;
2. administrerende geografiske steder;
3. administrere kategorier og underkategorier;
4. håndtere detaljer, knytte dem til punktene 1, 2 og 3;
5. inkludere alternativer som har betalt abonnement og så videre.

I avsnittene til å følge, vil bli beskrevet og kommentert på alle bordene nyttig - fra mitt synspunkt - å behandle søknaden omfattes av denne paragraf. Hvilke typer data er gitt ta hensyn MS Access som DBMS enklere å bruke, og deretter nærmere å forstå både den mindre erfarne spillere enn de mest erfarne, avansert bruker av DBMS.

Med hensyn til lengden på feltet, la jeg til skjønn av leseren til å etablere det. I noen tilfeller lengder av feltene er nødvendige (for eksempel, har skattemyndighetene kode 16 tegn, CAP har 5 og så videre), mens for andre ting som et navn, en adresse, kan jeg anbefale 50-150 tegn.

Må Vobis!

• <<
• 1
• 2
• 3
• >>