Konseptdesign I Databasedesignprosess
Konseptdesign I Databasedesignprosess
Konseptdesign er første trinn i databasedesignprosessen. Målet på dette stadiet er å designe en database som er uavhengig av databaseprogramvare og fysiske detaljer. Resultatet av denne prosessen er en konseptuell datamodell som beskriver de viktigste dataenhetene, attributtene, relasjonene og begrensningene til et gitt problemdomene. Dette designet er beskrivende og narrativt i form. Husk følgende minimal data regel:
“Alt som trengs er der, og alt som er der er nødvendig”.
Med andre ord, sørg for at alle data som trengs er i modellen, og at alle data i modellen er nødvendig. Alle dataelementer som kreves av databasetransaksjonene må defineres i modellen, og alle dataelementer som er definert i modellen må brukes av minst en databasetransaksjon. Den konseptuelle utformingen har fire trinn, som er som følger.
1. Dataanalyse og krav
2. Enhetsrelasjonsmodellering og normalisering
3. Datamodellbekreftelse
4. Distribuert databasedesign
Dataanalyse Og Krav:
det første trinnet i konseptuell design er å oppdage egenskapene til dataelementene. Passende dataelementegenskaper er de som kan forvandles til passende informasjon. Derfor er designerens hryvnias innsats fokusert på:
â € ¢ informasjonsbehov. Hva slags informasjon er nødvendigâ €det vil si, hvilken utgang( rapporter og spørringer) må genereres av systemet, hvilken informasjon genererer det nåværende systemet, og i hvilken grad er den informasjonen tilstrekkelig?
â € ¢ brukere. Hvem vil bruke informasjonen? Hvordan skal informasjonen brukes? Hva er de ulike sluttbrukerdatavisningene?
â € ¢ informasjonskilder. Hvor er informasjonen å finne? Hvordan skal informasjonen hentes ut når den er funnet?
â € ¢ grunnlov. Hvilke dataelementer trengs for å produsere informasjonen? Hva er dataattributtene? Hvilke forhold eksisterer mellom dataene? Hva er datavolumet? Hvor ofte brukes dataene? Hvilke datatransformasjoner skal brukes til å generere den nødvendige informasjonen? Designeren får svar på disse spørsmålene fra en rekke kilder for å kompilere nødvendig informasjon. Legg merke til disse kildene:
â € ¢ utvikling og Innsamling av sluttbrukerdatavisninger. Databasedesigneren og sluttbrukeren(e) samhandler for i fellesskap å utvikle en presis beskrivelse av sluttbrukerdatavisninger. I sin tur vil sluttbrukerdatavisningene bli brukt til å identifisere databases hoveddataelementer.
â € ¢ direkte observere dagens system: eksisterende og ønskede resultater. Sluttbrukeren har vanligvis et eksisterende system på plass, uansett om det er manuelt eller datamaskinbasert. Designeren vurderer det eksisterende systemet for å identifisere dataene og deres egenskaper.
â € ¢ i forbindelse med systemdesigngruppen. Databasedesignprosessen er en Del Av Systemutviklingens Livssyklus (SDLC). I noen tilfeller vil systemanalytikeren som har ansvaret for utformingen av det nye systemet også utvikle den konseptuelle databasemodellen.
Enhetsrelasjonsmodellering og Normalisering:
før du oppretter ER-modellen, må designeren kommunisere og håndheve passende standarder som skal brukes i dokumentasjonen av designet. Prosessen med å definere forretningsregler og utvikle den konseptuelle modellen ved HJELP AV er-diagrammer kan beskrives ved hjelp av følgende trinn.
1. Identifisere, analysere og avgrense forretningsreglene.
2. Identifiser de viktigste enhetene, ved hjelp av resultatene I Trinn 1.
3. Definer relasjonene mellom enhetene, ved hjelp av resultatene I Trinn 1 og 2.
4. Definer attributter, primærnøkler og fremmednøkler for hver av enhetene.
5. Normaliser enhetene. (Husk at enheter implementeres som tabeller i EN RDBMS.)
6. Fullfør det første er-diagrammet.
7. Valider ER-modellen mot sluttbrukerneâ € ™ informasjons-og behandlingskrav.
8. Endre ER-modellen ved hjelp av resultatene I Trinn 7.
Datamodellbekreftelse:
datamodellverifikasjonstrinnet er et av de siste trinnene i det konseptuelle designstadiet, og det er også et av de mest kritiske. I dette trinnet må ER-modellen verifiseres mot de foreslåtte systemprosessene for å bekrefte at de tiltenkte prosessene kan støttes av databasemodellen. Verifisering krever at modellen kjøres gjennom en rekke tester mot:
â € ¢ sluttbrukerdatavisninger.
â € ¢ alle Nødvendige Transaksjoner: velg, SETT INN, OPPDATER og slett operasjoner.
â € ¢ rettigheter og sikkerhet.
④ forretningsmessig pålagte datakrav og begrensninger.
Distribuert Databasedesign:
selv om det ikke er et krav for de fleste databaser, kan det hende at en database må distribueres mellom flere geografisk spredte steder. Prosesser som får tilgang til databasen kan også variere fra ett sted til et annet. For eksempel vil en detaljhandelsprosess og en lagerlagringsprosess sannsynligvis bli funnet på forskjellige fysiske steder. Hvis databasedataene og prosessene skal distribueres over hele systemet, kan deler av en database, kjent som databasefragmenter, ligge på flere fysiske steder.
