Detta är en gäst post från anum Lodhi, som har stort intresse för programvara utforma

Precis som du behöver en plan för att bygga ett hus, behöver du en databas modell för att genomföra en databas framgångsrikt. Arbetet med byggandet av den senare kallas "Designing fas", som omfattar ett antal tunga steg till slut -produkt att vara flexibel. Denna fas faktiskt definierar information (+ dess struktur) som kommer att gå in i databasen, som rör de antaganden som den eller de värden dataposter och förhållandet mellan de dataposter i databasen. Alla professionella använda detta förfarande design deras databas och det mest effektiva sättet.

Det omfattar fyra steg:

1. Behovsanalys

Databasen krav bestäms. De exakta kraven på användaren från systemet är captured.All relevant information om systemet samlas. De sex vanligaste teknikerna är:

• Provtagning av befintlig dokumentation, blanketter, databaser
• Forskning och platsbesök
• Observation av arbetsmiljön
• Frågeformulär
• Prototyper, bygga en liten modell av användarens krav på att kontrollera på förhand
• Gemensamma krav Planering (JRP) - gruppmöten genomförs för att analysera de problem

2. Entity Relationship Diagram (ERD)

ERD är en hög notation för att uttrycka databas design. Det definierar grafiskt databasens struktur på ett mycket enkelt och begripligt sätt med hjälp av symboler.

Den information som samlats in under "Behovsanalys" steg förvandlas till en ERD (Entity Relationship Diagram) som är data är organiserad i enheter och relationer mellan dem. Så istället för att gå igenom en lång bit av material, har vi en grafisk framställning av samma stycke information som är lättare att läsa.

Ett prov ER Diagram är här:

(bild courtesy Wikipedia)

Olika datamodellering språk kan användas för att skapa en reparationsdiskett som kråka fot notation, Chen notation, IDEFIX (Integration Definition Information Modeling), Shading notation, Bachman notation, UML (Unified Modeling Language) standard etc. Wikipedia har en bra sida om ER diagram här

3. Relationsmodellen

Det är mycket lätt att förstå det scenario från en reparationsdiskett, men den senare är mycket svag av genomförandet synvinkel. Begreppen underklasser (IS-A strukturer) och relationer, till exempel, inte kan genomföras i databasen direkt. Vid denna punkt relationsmodellen kommer in.

En relationsmodellen sysselsätter ett enhetligt begrepp av tabeller (även kallad relationer). Företaget ställer och relationer som skildras i ERD omvandlas till bord-en relationell modell.

Det finns fem steg för konvertering:

• Vrid varje icke-svag person som i motsvarande tabell med samma uppsättning attribut
• Ersätt en relation med en relation vars attribut är nycklarna för att ansluta enheten sätter
• Vissa relationer kan vara bra om det inte kombineras med eller inte. Till exempel stödjande relationer (för svag enhet uppsättningar) behöver inte omvandlas till relation alls.
• Ersätt en svag person som fastställts av en relation vars attribut är dess egna attribut (eventuella) plus lånade attribut som bidrar till att göra sitt primära nyckel.
• Konvertera den underklass strukturer med hjälp av objektet ansatsen, E / R stil konvertering eller null-värden.

Förklaring att konvertera ER diagram till förhållandet modell har omfattande begrepp som inte tas upp i detta inlägget. Det finns många bra böcker och online-resurser som gör det lätt att förstå. För en översikt anser detta exempel som jag har tagit från Wikipedia:

En idealiserad, mycket enkelt exempel på en beskrivning av några relvars och deras attribut:

• Kund (kundnummer, Tax ID, namn, adress, stad, delstat, Zip, Phone)
• (Förordning Nej, kundnummer, Faktura nr, Datum placeras Datum lovade Terms, Status)
• Orderrad (löpnummer, Orderrad Nej, produktkod, Antal)
• Faktura (Faktura Nej, kundnummer, löpnummer, datum, Status)
• Invoice Line (Faktura Nej, Faktura Line Nej, produktkod, Antal Shipped)
• Produkt (Product Code, produktbeskrivning)

I denna konstruktion har vi sex relvars: Kund, Order, Order Line, Faktura, Invoice Line och Produkt. Den fet, understruken attribut kandidat nycklar. De icke-fet, understruken attribut främmande nycklar.

4. Normalisering

Normalisering är en process för att höja den normala formen betyg. Det främst eliminerar följande beroenden för att undvika uppsägningar och data anomalier:

• Partiell dependency: baserad på en del av primärnyckeln
• Transitivt beroende: baseras på ett attribut som inte ingår i primärnyckeln

De första tre former av normalisering är:

1. 1NF
   • Lägsta genomförbara normal form
   • Primärnyckel enhet integritet krav är uppfyllda
   • Varje cell innehåller ett enda värde
   • Icke Primärnyckel värden är beroende av primärnyckeln
2. 2NF
   • Alla 1NF villkor är uppfyllda
   • Partiell
     beroenden tas bort
3. 3NF
   • Alla 2NF villkor är uppfyllda
   • Transitiva beroenden bort

Högre former till 5NF och BCNF (Boyce-Codd Normal Form) finns också.

Normalisering kan tillämpas på två sätt:

• Normal former tillämpas efter relationsmodellen skapas
• Det tredje steget hoppas över och skapandet av tabellerna sker med normalisering i ersättning direkt

daleeman blogg har ett mycket bra inlägg om databasnormalisering. Läs: praktiska tillämpningen av databas normalisering som hjälper dig att förstå databasnormalisering i detalj.