Introduktion

Vi er måske stødt på ordet ' Database ' ret ofte. Dette udtryk har stor vægt på sine arme. Oftere er det ikke kun relateret til udviklerens perspektiv, men bruges ret ofte med ikke-teknologiske grupper eller fællesskaber. Teknisk set er en database mere et lagerbegreb, der bruges til at betegne forholdet til forskellige former for data, der er koaguleret på et enkelt sted. Således kan vi definere en database som en organiseret indsamling af data, generelt lagret og tilgået elektronisk gennem computersystemer. Denne artikel er meget centreret om databasedesignet, og dets tilknytning til citerbare termer og metoder blev almindeligvis taget i betragtning. Vi vil diskutere disse termer vedrørende databasedesign for at forstå bits og stykker. Lad os tale om det med det samme.

hvor er indsæt nøgle på laptop tastatur

Hvad er databasedesign?

Databasedesign kan generelt defineres som en samling af opgaver eller processer, der forbedrer design, udvikling, implementering og vedligeholdelse af virksomhedens datastyringssystem. Design af en ordentlig database reducerer vedligeholdelsesomkostningerne og forbedrer derved datakonsistensen, og de omkostningseffektive foranstaltninger er stærkt påvirket med hensyn til disklagerplads. Derfor skal der være et genialt koncept for at designe en database. Designeren bør følge begrænsningerne og beslutte, hvordan elementerne hænger sammen, og hvilken slags data der skal gemmes.

Hovedformålene bag databasedesign er at producere fysiske og logiske designmodeller af det foreslåede databasesystem. For at uddybe dette er den logiske model primært koncentreret om kravene til data, og overvejelserne skal foretages i form af monolitiske overvejelser, og derfor skal de lagrede fysiske data opbevares uafhængigt af de fysiske forhold. På den anden side inkluderer den fysiske databasedesignmodel en oversættelse af databasens logiske designmodel ved at holde kontrol over fysiske medier ved hjælp af hardwareressourcer og softwaresystemer såsom Database Management System (DBMS).

Hvorfor er databasedesign vigtigt?

Den vigtige overvejelse, der kan tages i betragtning, mens man understreger vigtigheden af ​​databasedesign, kan forklares ud fra følgende punkter nedenfor.

1. Databasedesign giver tegningerne til, hvordan dataene skal lagres i et system. Et korrekt design af en database påvirker i høj grad den overordnede ydeevne af enhver applikation.
2. Designprincipperne, der er defineret for en database, giver en klar idé om opførsel af enhver applikation, og hvordan anmodningerne behandles.
3. Et andet eksempel på at understrege databasedesignet er, at et korrekt databasedesign opfylder alle brugernes krav.
4. Endelig reduceres behandlingstiden for en applikation betydeligt, hvis begrænsningerne ved at designe en højeffektiv database er korrekt implementeret.

Livscyklus

Selvom en databases livscyklus ikke er en vigtig diskussion, der skal tages videre i denne artikel, fordi vi er fokuseret på databasedesignet. Men før du hopper direkte på designmodellerne, der udgør databasedesign, er det vigtigt at forstå databasens overordnede arbejdsgang og livscyklus.

Behovsanalyse

Først og fremmest skal planlægningen foretages på, hvad der er de grundlæggende krav til projektet, under hvilke design af databasen skal videreføres. De kan således defineres som:

Planlægning - Denne fase handler om planlægning af hele DDLC (Database Development Life Cycle). De strategiske overvejelser tages i betragtning, inden man går videre.

System definition - Denne fase dækker grænserne og omfanget af den rigtige database efter planlægning.

Database design

Det næste trin involverer at designe databasen under hensyntagen til de brugerbaserede krav og opdele dem i forskellige modeller, så belastning eller tunge afhængigheder af et enkelt aspekt ikke pålægges. Derfor har der været en model-centreret tilgang, og det er her, logiske og fysiske modeller spiller en afgørende rolle.

Fysisk model - Den fysiske model er optaget af praksis og implementeringer af den logiske model.

hvordan man genererer tilfældige tal i java

Logisk model - Denne fase handler primært om at udvikle en model baseret på de foreslåede krav. Hele modellen er designet på papir uden nogen implementering eller vedtagelse af DBMS-overvejelser.

Implementering

Det sidste trin dækker implementeringsmetoderne og tjekker den adfærd, der matcher vores krav. Det sikres med løbende integrationstest af databasen med forskellige datasæt og konvertering af data til maskinforståeligt sprog. Manipulationen af ​​data er primært fokuseret på disse trin, hvor der stilles forespørgsler til at køre og kontrollere, om applikationen er designet tilfredsstillende eller ej.

Datakonvertering og indlæsning - Denne sektion bruges til at importere og konvertere data fra det gamle til det nye system.

sortere et array java

Afprøvning - Denne fase handler om fejlidentifikation i det nyligt implementerede system. Test er et afgørende skridt, fordi det tjekker databasen direkte og sammenligner kravspecifikationerne.

Database designproces

Processen med at designe en database bærer forskellige konceptuelle tilgange, der skal huskes. Et ideelt og velstruktureret databasedesign skal kunne:

1. Spar diskplads ved at eliminere overflødige data.
2. Bevarer dataintegritet og nøjagtighed.
3. Giver dataadgang på nyttige måder.
4. Sammenligning af logiske og fysiske datamodeller.

Logisk

En logisk datamodel beskriver generelt dataene i så mange detaljer som muligt uden at skulle bekymre sig om de fysiske implementeringer i databasen. Funktioner af logisk datamodel kan omfatte:

1. Alle enheder og relationer mellem dem.
2. Hver enhed har velspecificerede attributter.
3. Den primære nøgle for hver enhed er angivet.
4. Fremmednøgler, som bruges til at identificere en relation mellem forskellige enheder, er specificeret.
5. Normalisering sker på dette niveau.

En logisk model kan designes ved hjælp af følgende tilgang:

1. Angiv alle enheder med primærnøgler.
2. Angiv samtidige relationer mellem forskellige enheder.
3. Find ud af hver enheds attributter
4. Løs mange-til-mange relationer.
5. Udfør normaliseringsprocessen.

En vigtig faktor efter at have fulgt ovenstående tilgang er også kritisk at undersøge designet baseret på kravindsamling. Hvis ovenstående trin følges nøje, er der chancer for at skabe et meget effektivt databasedesign, der følger den native tilgang.

For at forstå disse punkter, se billedet nedenfor for at få et klart billede.

Hvis vi sammenligner den logiske datamodel som vist i figuren ovenfor med nogle eksempeldata i diagrammet, kan vi komme med fakta om, at der i en konceptuel datamodel ikke er tilstedeværelse af en primærnøgle, mens en logisk datamodel har primærnøgler til alle dens egenskaber. Logiske data modellerer også dækningsforholdet mellem forskellige enheder og rummer plads til fremmednøgler til at etablere relationer mellem dem.

Fysisk

En fysisk datatilstand repræsenterer generelt, hvordan tilgangen eller konceptet med at designe databasen. Hovedformålet med den fysiske datamodel er at vise alle strukturer af bordet inklusive kolonnenavn, kolonnedatatype, begrænsninger, nøgler (primære og fremmede) , og forholdet mellem tabeller. Følgende er funktionerne i en fysisk datamodel:

1. Angiver alle kolonner og tabeller.
2. Angiver fremmednøgler, der normalt definerer forholdet mellem tabeller.
3. Baseret på brugerkrav kan denormalisering forekomme.
4. Da de fysiske hensyn er taget i betragtning, så er der ligetil grunde til forskel end en logisk model.
5. Fysiske modeller kan være forskellige for forskellige RDBMS. For eksempel kan datatypekolonnen være anderledes i MySQL og SQL Server.

Når du designer en fysisk datamodel, skal følgende punkter tages i betragtning:

1. Konverter enhederne til tabeller.
2. Konverter de definerede relationer til fremmednøgler.
3. Konverter dataattributterne til kolonner.
4. Rediger datamodellens begrænsninger baseret på fysiske krav.

Ved at sammenligne denne fysiske datamodel med den logiske med den tidligere logiske model kan vi konkludere forskellene i, at entitetsnavne i en fysisk database betragtes som tabelnavne, og attributter betragtes som kolonnenavne. Desuden er datatypen for hver kolonne defineret i den fysiske model afhængigt af den faktiske anvendte database.

Ordliste

Enhed - En enhed i databasen kan defineres som abstrakte data, som vi gemmer i vores database. For eksempel en kunde, produkter.

tredje normalform

Egenskaber - En attribut er en detaljeret form for data, der består af enheder som længde, navn, pris osv.

Forhold - Et forhold kan defineres som forbindelsen mellem to enheder eller figurer. For eksempel kan en person relatere til flere personer i en familie.

Fremmed nøgle - Det fungerer som en henvisning til den primære nøgle til et andet bord. En fremmednøgle indeholder kolonner med værdier, der kun findes i den primære nøglekolonne, de refererer til.

Primærnøgle - En primær nøgle er markøren for poster, der er unik og ikke null og bruges til entydigt at identificere attributter for en tabel.

git status -s

Normalisering - En fleksibel datamodel skal følge visse regler. At anvende disse regler kaldes normalisering.

Resumé

Databasedesign er en metode til at identificere hullerne og mulighederne for at designe en korrekt udnyttelsesmetode. Det er hovedkomponenten i et system, der giver en blueprint af dataene og deres adfærd inde i systemet. Et ordentligt databasedesign prioriteres altid på grund af brugerkravene, der holdes overdrevent høje, og opfølgning med begrænsningerne ved at designe en database er måske kun en chance for at opnå den ønskede effektivitet. Desuden lærte vi også separat om de forskellige designmodeller, der skildrer det ideelle databasedesign sammen med den grænseløse diskussion om deres egenskaber og hvordan man kan bruge dem. Ydermere lærte vi, hvordan en databases livscyklus afgør databasens design, og hvordan man sætter designkonceptet ind i livscyklusmetoderne, så effektive og meget sofistikerede databaser kan designes ud fra brugernes krav.