Dit is een gastpost door Anum Lodhi, die heeft grote belangstelling voor het ontwerpen van software

Net zoals u een blauwdruk nodig om een huis te bouwen, moet u een database blauwdruk om een database succesvol uit te voeren. Het proces van de bouw van de laatste is "het ontwerpen van Phase 'waarin een aantal zware stappen voor het einde omvat -product flexibel. Deze fase wordt in feite de informatie (+ structuur) dat zal gaan in de database, maakte de veronderstellingen met betrekking tot het type of de waarden van de data items en de relatie tussen de gegevens die items in de database. Alle professionele bedrijven gebruiken deze procedure ontwerp hun database en zijn de meest efficiënte manier.

Het omvat vier stappen:

1. Requirement Analyse

De database eisen worden bepaald. De exacte eisen van de gebruiker van het systeem is captured.All de relevante informatie met betrekking tot het systeem is verzameld. De zes meest voorkomende technieken zijn:

• Bemonstering van bestaande documentatie, formulieren, databases
• Onderzoek en bezoeken ter plaatse
• Observatie van de werkomgeving
• Vragenlijsten
• Prototyping-bouwen van een klein model van de eis van de gebruiker om te verifiëren voordat hand
• Gezamenlijke Requirements Planning (JRP) - groepsbijeenkomsten worden uitgevoerd om bestaande problemen te analyseren

2. Entity Relationship Diagram (ERD)

ERD is een hoog niveau notatie voor het uitdrukken van database ontwerpen. Het definieert grafisch de structuur van de database in een zeer eenvoudige en begrijpelijke wijze door het gebruik van symbolen.

De verzamelde informatie tijdens de 'stap Requirement Analysis' wordt omgezet in een ERD (Entity Relationship Diagram) dat de gegevens wordt georganiseerd in entiteiten en relaties tussen hen. Dus in plaats van te gaan door een lange stukje materiaal, hebben we een grafische weergave van hetzelfde stuk van de informatie die is makkelijker te lezen.

Een voorbeeld ER Diagram is dit:

(image courtesy Wikipedia)

Diverse gegevens modelleren talen kunnen worden gebruikt om een ERD zoals mond Crow's notatie maken, Chen notatie, Idefix (Integratie Definitie Voor Information Modeling), Shading notatie, Bachman notatie, UML (Unified Modeling Language) standaard, enz. Wikipedia heeft een goede pagina over ER diagrammen hier

3. Relationele Model

Het is heel gemakkelijk om het scenario te begrijpen vanuit een ERD, maar de laatste is zeer zwak uit de uitvoering oogpunt. Concepten van de subklassen (IS-A structuren) en relaties, bijvoorbeeld, niet kan worden uitgevoerd in de database direct. Op dit punt relationele model komt in het spel.

Een relationele model maakt gebruik van een enkel begrip van de tabellen (ook wel relaties). De entiteit stelt en de relaties afgebeeld in de ERD worden omgezet in tabellen-een relationeel model.

Er zijn vijf stappen voor de conversie:

• Draai elke niet-zwakke entiteit set in de bijbehorende tabel met dezelfde set van attributen
• Vervang een relatie met een relatie waarvan de attributen zijn de sleutels van de verbindende entiteit sets
• Sommige relaties kunnen goed doen als gecombineerde of uitgesloten. Bijvoorbeeld de ondersteunende relaties (voor zwakke entiteit sets) hoeven niet te worden omgezet naar verhouding at all.
• Vervang een zwakke entiteit door een relatie waarvan de attributen zijn eigen attributen (indien aanwezig) plus het geleende attributen die helpen haar primaire sleutel te maken.
• Zet de subklasse structuren met behulp van de object georiënteerde aanpak, E / R-stijl conversie of null-waarden.

Uitleg van het omzetten van ER diagram naar verhouding model heeft een enorme concepten die niet zal worden behandeld in dit bericht. Er zijn veel goede boeken en online beschikbare middelen dat maakt het makkelijk te begrijpen. Voor een overzicht van mening dat dit voorbeeld dat ik heb genomen uit Wikipedia:

Een geïdealiseerde, zeer eenvoudig voorbeeld van een beschrijving van een aantal relvars en hun attributen:

• Klant (Customer ID, BTW-nummer, naam, adres, stad, staat, Zip, Telefoon)
• Order (volgnummer, Klant-ID, factuur nr., Datum geplaatst, Datum Beloofde, Voorwaarden, Status)
• Bestel Line (volgnummer, Orderregel Nee, Product Code, Aantal)
• Factuur (Factuur nr., Klant-ID, volgnummer, datum, Status)
• Invoice Line (factuur nr., Invoice Line Nee, Product Code, Aantal verzonden)
• Product (Product Code, Product Beschrijving)

In dit ontwerp hebben we zes relvars: klant, Orde, Orderregel, factuur, factuur Line en Product. Het vet, onderstreept attributen zijn kandidaat-sleutels. De niet-vet, onderstreept attributen zijn foreign keys.

4. Normalization

Normalisatie is een proces van verhoging van de normale vorm rating. Het eerste elimineert de volgende afhankelijkheden in om gedwongen ontslagen en gegevens anomalieën te voorkomen:

• Gedeeltelijke afhankelijkheid: gebaseerd op een deel van de primaire sleutel
• Transitieve afhankelijkheid: op basis van een attribuut dat geen deel uitmaakt van de primaire sleutel

De eerste drie vormen van normalisatie zijn:

1. 1NF
   • Laagste implementeerbare normale vorm
   • Primaire sleutel entiteit integriteit van de vereisten is voldaan
   • Elke cel bevat een enkele waarde
   • Niet-primaire sleutel waarden zijn afhankelijk van de primaire sleutel
2. 2NF
   • Alle 1NF voorwaarden is voldaan
   • Gedeeltelijke
     afhankelijkheden verwijderd
3. 3NF
   • Alle 2NF voorwaarden is voldaan
   • Transitieve afhankelijkheden verwijderd

Hogere vormen tot 5NF en BCNF (Boyce-Codd Normal Form) ook bestaan.

Normalisatie kan worden toegepast op twee manieren:

• Normaal vormen toegepast na de relationele model is gemaakt
• De derde stap is overgeslagen en het creëren van tabellen is gedaan met de normalisering in ruil direct

daleeman blog heeft een zeer goede post over database normalisatie. Lees: de praktische toepassing van database normalisatie die u zullen helpen database normalisatie in detail te begrijpen.