Dette er en gjest postering av anum Lodhi, som har stor interesse for programvare utforme
Akkurat som du trenger en blåkopi å bygge et hus, trenger du en database blåkopi for å implementere en database til. Prosessen med byggingen av sistnevnte kalles "Designing Phase 'som inkluderer en rekke tunge skritt for slutten -produktet for å være fleksibel. Denne fasen faktisk definerer informasjonen (+ sin struktur) som vil gå inn i databasen gjort, forutsetningene knyttet til type eller verdier av dataelementer og forholdet mellom dataelementene i databasen. Alle profesjonelle selskaper bruker denne fremgangsmåten designe sin database og den mest effektive måten.
Det omfatter fire trinn:
1. Behovsanalyse
Databasen krav bestemmes. Det eksakte krav til brukeren av systemet er captured.All relevant informasjon knyttet til systemet er samlet. De seks vanligste teknikkene er:
- Prøvetaking av eksisterende dokumentasjon, skjemaer, databaser
- Forskning og besøk
- Observasjon av arbeidsmiljøet
- Spørreskjemaer
- Prototyping-bygge en liten modell av brukerens behov for å verifisere før hånd
- Joint Requirements Planning (JRP) - gruppemøter er utført for å analysere eksisterende problemer
2. Entity Relationship diagram (ERD)
ERD er et høyt nivå notasjon for å uttrykke database design. Det definerer grafisk strukturen i databasen på en veldig enkel og forståelig måte, gjennom bruk av symboler.
Informasjonen samles inn under trinnet Behovsanalyse 'er forvandlet til et ERD (Entity Relationship diagram) som dataene er organisert i enheter og relasjonene mellom dem. Så istedenfor å gå gjennom et lengre stykke av materialet, har vi en billedlig fremstilling av samme stykke informasjon som er lettere å lese.
Et eksempel ER Diagram er dette:
(image courtesy Wikipedia)
Ulike datamodellering språk kan brukes til å opprette en ERD som crow foten notasjon, Chen notasjon, Idefix (Integrerings-definisjon for Information Modeling), skyggelegging notasjon, Bachman notasjon, UML (Unified Modeling Language) standard osv. Wikipedia har en god side om ER diagrammer her
3. Relational Model
Det er veldig lett å forstå situasjonen fra en ERD, men sistnevnte er veldig svak fra gjennomføringen synspunkt. Concepts of subklasser (IS-A strukturer) og sammenhenger, for eksempel, ikke kan implementeres i databasen direkte. På dette punktet relasjonelle modellen kommer inn i bildet.
En relasjonelle modellen benytter en enkelt konsept for tabeller (også kalt relasjoner). Enhetstypen sett og relasjonene avbildet i ERD omdannes til bord-en relasjonell modell.
Det er fem trinn for konvertering:
- Turn hvert ikke-svak foretaket sette inn den tilsvarende tabellen med samme sett med attributter
- Erstatt et forhold av en relasjon som attributter er nøklene til å koble enheten sett
- Noen forbindelser kan gjøre det bra hvis det kombineres eller ekskluderes. For eksempel støtter forhold (for svak juridisk sett) trenger ikke å bli konvertert til forhold i det hele.
- Erstatte en svak entitet satt av et forhold som har attributter som er sin egen attributter (hvis noen) pluss lånte attributtene som bidrar til å gjøre sin primærnøkkel.
- Konverter subclass strukturer ved hjelp av objektorientert tilnærming, E / R stil konvertering eller nullverdier.
Forklaring av konvertering ER diagrammet til forholdet modellen har store begreper som ikke vil bli dekket i dette innlegget. Det er mange gode bøker og elektroniske ressurser som gjør det lett å forstå. For en oversikt vurdere dette eksemplet som jeg har hentet fra Wikipedia:
Et idealisert, veldig enkelt eksempel på en beskrivelse av noen relvars og attributter:
- Kunde (kunde-ID, skatte-ID, Navn, Adresse, By, Delstat, Zip, Telefon)
- Bestill (Bestill Nei, kunde-ID, Faktura Nei, Dato Plasserte, Dato lovet vilkår, status)
- Ordrelinje (Bestill Nei, Ordrelinje Nei, Product Code, Antall)
- Faktura (Invoice Nei, kunde-ID, Bestill Nei, Dato status)
- Faktura Line (faktura Nei, faktura Line Nei, Product Code, Antall Sendt)
- Produkt (Product Code, Produktbeskrivelse)
I denne designen har vi seks relvars: Kunde, Order, Order Line, Faktura, Faktura Line og Produkt. Det fet, understreket attributtene er kandidat nøkler. Den ikke-fet, understreket attributtene er sekundærnøkler.
4. Normalisering
Normalisering er en prosess for å øke den normale formen vurdering. Det primært eliminerer følgende avhengigheter for å unngå oppsigelser og data anomalier:
- Delvis avhengighet: basert på en del av primærnøkkelen
- Transitive avhengighet: basert på et attributt som ikke er del av primærnøkkelen
De første tre former for normalisering er:
- 1NF
- Laveste iverksettes normale form
- Primærnøkkel enhet integritet krav er oppfylt
- Hver celle inneholder en enkelt verdi
- Non-Primærnøkkel verdiene er avhengig av primærnøkkelen
- 2NF
- Alle 1NF vilkår er oppfylt
- Delvis
avhengigheter fjernes
- 3NF
- Alle 2NF vilkår er oppfylt
- Transitive avhengigheter fjernes
Høyere former opptil 5NF og BCNF (Boyce-Codd Normal Form) også eksisterer.
Normalisering kan brukes på to måter:
- Normal former søkt etter relasjonelle modellen er opprettet
- Det tredje trinnet er hoppet og etableringen av tabellene er gjort med normalisering i betraktning direkte
daleeman bloggen har et meget godt innlegg om databasen normalisering. Les: praktisk anvendelse av databasen normalisering som vil hjelpe deg å forstå database normalisering i detalj.
