Dette er en gæst indlæg af änum Lodhi, som har stor interesse i software design

Ligesom du har brug for en plan til at bygge et hus, skal du bruge en database plan for at gennemføre en database med succes. Processen med opførelsen af sidstnævnte kaldes "Designing fase", som omfatter en række tunge skridt til at ende -produkt til at være fleksibel. Denne fase faktisk definerer oplysninger (+ sin struktur), som vil gå ind i databasen, de hypoteser, der er relateret til typen eller værdier for dataelementer og forholdet mellem de dataelementer i databasen. Alle professionelle virksomheder bruger denne fremgangsmåde designe deres database og dens den mest effektive måde.

Det omfatter fire trin:

1. Krav Analyse

Databasen krav er fastlagt. Det nøjagtige krav til brugeren fra systemet er captured.All de relevante oplysninger i forbindelse med systemet er samlet. De seks mest almindelige teknikker er:

• Prøvetagning af eksisterende dokumentation, skemaer, databaser
• Forskning og besøg på stedet
• Observation af arbejdsmiljøet
• Spørgeskemaer
• Prototyping-bygge en lille model af brugerens krav om at kontrollere, før hånden
• Fælles Requirements Planning (JRP) - møder er gennemført for at analysere eksisterende problemer

2. Aktivitetsdiagram (ERD)

ERD er et højt notation for at udtrykke database design. Det grafisk definerer strukturen af databasen i en meget enkel og forståelig måde ved brug af symboler.

De indsamlede oplysninger under 'Krav Analyse' skridt er omdannet til en reparationsdiskette (aktivitetsdiagram), der er de data, der er organiseret i enheder og relationer mellem dem. Så i stedet for at gå gennem en længere stykke materiale, vi har en grafisk gengivelse af den samme oplysninger, som er lettere at læse.

En prøve ER Diagram er denne:

(image courtesy Wikipedia)

Forskellige data modeling sprog kan bruges til at oprette en reparationsdiskette gerne smilerynker mund notation, Chen notation, Idefix (Integration Definition Information Modeling), skygge notation, Bachman notation, UML (Unified Modeling Language) standard, mv Wikipedia har en god side om ER diagrammer her

3. Relationelle model

Det er meget let at forstå det scenarie fra en reparationsdiskette, men sidstnævnte er meget svag fra gennemførelsen synspunkt. Begreberne underklasser (IS-A strukturer) og relationer, for eksempel, ikke kan gennemføres i databasen direkte. På dette punkt relationelle model kommer i spil.

En relationelle model beskæftiger et enkelt begreb tabeller (også kaldet forbindelser). Virksomheden sæt og forholdet afbildet i ERD konverteres til tabeller-en relationel model.

Der er fem trin til konvertering:

• Drej til hver ikke-svage enhed, der i den tilhørende tabel med det samme sæt af attributter
• Erstat et forhold med et forhold, hvis attributter er nøglerne til at tilslutte enhed sæt
• Nogle forbindelser kan gøre godt, hvis den kombineres eller udelukket. For eksempel støtte sammenhænge (for svag enhed sæt) behøver ikke at blive omdannet til forhold på alle.
• Udskift en svag enhed, der ved et forhold, hvis egenskaber er dens egne attributter (hvis nogen) plus de lånte egenskaber, der bidrager til at gøre dens primære nøgle.
• Konverter underklasse strukturer ved hjælp af objektorienterede tilgang, E / R stil konvertering eller Null-værdier.

Forklaring af konvertering ER diagram til forholdet model har langt de begreber, der ikke vil blive dækket i dette indlæg. Der er mange gode bøger og online-ressourcer til rådighed, der gør det nemt at forstå. For en oversigt overveje dette eksempel, at jeg har taget fra Wikipedia:

En idealiseret, meget simpelt eksempel på en beskrivelse af nogle relvars og deres attributter:

• Kunde (kunde-id, skatte-id, navn, adresse, by, stat, Zip, Phone)
• Bestil (bekendtgørelse nr., kunde-id, faktura nr., Dato Placeret, Dato lovet Vilkår, Status)
• Ordrelinje (bekendtgørelse nr., Ordrelinje Nej, Product Code, Qty)
• Faktura (faktura nr., kunde-id, bekendtgørelse nr., dato, Status)
• Faktura Line (faktura nr., Faktura Line nr., Product Code, Antal Afsendt)
• Produkt (Product Code, Product Description)

I dette design vi har seks relvars: Kunde, Bestil, Ordrelinje, faktura, Faktura Line og produkt. Den dristige, understregede attributter er kandidat nøgler. Den ikke-fed, understregede attributter er fremmede nøgler.

4. Normalisering

Normalisering er en proces for at øge den normale form bedømmelse. Det primært fjerner følgende afhængigheder for at undgå afskedigelser og data anomalier:

• Delvis afhængighed: baseret på en del af den primære nøgle
• Transitive afhængighed: baseret på en egenskab, som ikke er en del af den primære nøgle

De første tre former for normalisering er:

1. 1NF
   • Laveste gennemførlige normalform
   • Primær nøgle enhed integritet krav er opfyldt
   • Hver celle indeholder en enkelt værdi
   • Ikke-primære centrale værdier er afhængige af den primære nøgle
2. 2NF
   • Alle 1NF betingelser er opfyldt
   • Delvis
     afhængigheder er fjernet
3. 3NF
   • Alle 2NF betingelser er opfyldt
   • Transitive afhængigheder fjernet

Højere former op til 5NF og BCNF (Boyce-Codd Normal Form) findes også.

Normalisering kan anvendes på to måder:

• Normale former anvendes efter den relationelle model er skabt
• Det tredje skridt er springes over og oprettelsen af tabellerne sker med normalisering i betragtning direkte

daleeman blog har et meget godt indlæg om databasen normalisering. Læs: praktiske anvendelse af database normalisering, som vil hjælpe dig med at forstå database normalisering i detaljer.