1. Forholdet mellom det opprinnelige dokumentet og enheten
Det kan være én-til-én, én-til-mange, og mange-til-mange-relasjoner. Generelt er de én-til-én-relasjoner: altså et par originale dokumenter
bør og kun tilsvare én enhet. I spesielle tilfeller kan de være én-til-mange- eller mange-til-én-relasjoner, det vil si at ett originaldokument tilsvarer flere realiteter
kropp, eller flere originale dokumenter som tilsvarer en enhet. Entiteten her kan forstås som en grunnleggende tabell. Etter å ha klargjort denne korrespondansen, design for oss
Inngangsgrensesnittet er veldig nyttig.
〖Eksempel 1〗: Informasjon om en ansatt-CV tilsvarer tre grunnleggende tabeller i personalinformasjonssystemet: ansattens grunnleggende informasjonstabell og samfunnet
Forholdstabell, arbeids-CV-skjema. Dette er et typisk eksempel på «ett originaldokument tilsvarer flere enheter».
2. Primær- og fremmednøkler
Generelt kan ikke en enhet ha verken en primær eller en fremmednøkkel. I E-R-diagrammet kan entitetene i bladdelen definere primærnøkkelen,
Det er også mulig å ikke definere en primærnøkkel (fordi den ikke har barn), men den må ha en fremmednøkkel (fordi den har en far).
Utformingen av primær- og fremmednøkler har en viktig plass i utformingen av globale databaser. Når utformingen av den globale databasen er fullført, er det en
Amerikanske eksperter på databasedesign sa: «Nøkler, nøkler overalt, ingenting annet enn nøkler», dette er hans erfaring med databasedesign
Det gjenspeiler også hans svært abstrakte ideer om kjernen i informasjonssystemer (datamodeller). Fordi: primærnøkkelen er en svært abstrakt enhet, og primærnøkkelen er assosiert med
Et par fremmednøkler som representerer en forbindelse mellom enheter.
3. Naturen til den grunnleggende tabellen
Den grunnleggende tabellen skiller seg fra mellomtabellen og den midlertidige tabellen fordi den har følgende fire egenskaper:
(1) Atomisitet. Feltene i grunntabellen er ikke lenger dekomponerbare.
(2) Primitivitet. Postene i basistabellen er poster av de opprinnelige dataene (de underliggende dataene).
(3) Deduktiv. All utdatadata kan utledes fra dataene i grunntabellen og kodetabellen.
(4) Stabilitet. Strukturen til den grunnleggende tabellen er relativt stabil, og postene i tabellen bør beholdes over lang tid.
Etter å ha forstått naturen til grunnleggende tabeller, kan basistabeller ved design av databaser skilles fra mellomliggende tabeller og midlertidige tabeller.
4. Paradigmestandarder
Forholdet mellom grunntabellen og dens felt bør oppfylle det tredje paradigmet så mye som mulig. Databasedesign som oppfyller det tredje paradigmet er imidlertid ofte ikke det
Det beste designet. For å forbedre den operative effektiviteten til databaser, er det ofte nødvendig å redusere paradigmestandarden: øke redundansen på en passende måte for å oppnå rom for tid
Formålet med.
Eksempel 2: Det finnes en grunnleggende tabell for lagring av varer, som vist i tabell 1. Tilstedeværelsen av feltet "Beløp" indikerer at tabellen ikke er designet for å være oppfylt
Det tredje paradigmet er tilstrekkelig, fordi "mengde" kan oppnås ved å multiplisere "enhetspris" med "mengde", noe som indikerer at "mengde" er et redundant felt. Men øk
Det redundante feltet «mengde» kan forbedre hastigheten på spørringsstatistikk, som er praksisen med å bytte rom mot tid.
I Rose 2002 finnes det to typer foreskrevne kolonner: datakolonner og beregnede kolonner. En kolonne som «beløp» kalles en «beregningskolonne», og
Kolonner som «Enhetspris» og «Mengde» kalles «datakolonner».
Tabell 1 Tabellstruktur for varetabellen
Produktnavn, produktmodell, enhetspris, mengde, mengde
TV 29 tommer 2 500 40 100 000
5. Forstå de tre paradigmene på en enkel måte.
Å forstå de tre paradigmene på enkle språk er til stor nytte for databasedesign. I databasedesign, for å bedre anvende de tre paradigmene, er det bare
Tre paradigmer må forstås i lekmannsspråk:
Det første paradigmet: 1NF er en atomær begrensning på attributter, som krever at attributter er atomære og ikke lenger kan dekomponeres;
Det andre paradigmet: 2NF er unikhetsbegrensningen på poster, som krever at poster har en unik identifikasjon, det vil si enhetens unikhet;
Paradigme 3: 3NF er en begrensning på feltredundans, det vil si at ingen felt kan utledes fra andre felt, det krever at feltet ikke er redundant
。
Ingen redundant databasedesign kan gjøre det. En database uten redundans er imidlertid ikke nødvendigvis den beste databasen, noen ganger for å øke lykken
For å oppnå effektivitet er det nødvendig å redusere paradigmestandarden og beholde redundante data på en hensiktsmessig måte. Den spesifikke tilnærmingen er å følge det tredje paradigmet når man designer konseptuelle datamodeller
, arbeidet med å redusere paradigmestandarden tas i betraktning i utformingen av den fysiske datamodellen. Å senke paradigmet er å legge til felt som tillater redundans.
6. Vær god til å identifisere og håndtere mange-til-mange-relasjoner korrekt
Hvis det er et mange-til-mange-forhold mellom to enheter, bør forholdet elimineres. Måten å eliminere det på er å legge til en tredje reell mellom de to
kropp. På denne måten har det som tidligere var et mange-til-mange-forhold nå blitt to én-til-mange-relasjoner. Attributtene til de to opprinnelige enhetene bør fordeles rimelig
Gå til de tre enhetene. Den tredje enheten her er i hovedsak et mer komplekst forhold, som tilsvarer en grunnleggende tabell. Generelt sett, tall
Bibliotekdesignverktøyet kan ikke gjenkjenne mange-til-mange-relasjoner, men det kan håndtere mange-til-mange-relasjoner.
Eksempel 3: I "Library Information System" er "book" en enhet, og "reader" er også en enhet. Disse to enhetene er det samme
Forholdet mellom bøker er et typisk mange-til-mange-forhold: en bok kan lånes av flere lesere til ulike tider, og én leser kan låne flere
Denne boken. For dette formålet bør en tredje enhet legges til mellom de to, kalt «lån og tilbakelevering av bøker», og dens egenskaper er: lånetid og lån
Den har også en logo (0 betyr å låne en bok, 1 betyr å returnere en bok), i tillegg skal den også ha to fremmednøkler (primærnøkkelen til «bok» og primærnøkkelen til «leser»), slik at
Den knytter seg til «bøker» og «lesere».
7. Verdimetoden til primærnøkkelen PK
PK er et inter-tabell-tilkoblingsverktøy for programmerere, som kan være en tallrekke uten fysisk betydning, som automatisk legges til 1 av programmet. Ja
er et fysisk meningsfullt feltnavn eller en kombinasjon av feltnavn. Men det første er bedre enn det siste. Når PK er en kombinasjon av feltnavn, antyder man et feltnummer
Ikke tell for mye, for indeksen tar ikke bare opp mye plass, men går også tregere.
8. Få dataredundans riktig
Repetisjon av primær- og fremmednøkler i flere tabeller er ikke et begrep om dataredundans, og mange er ikke klar over det
。 Repetisjonen av ikke-nøkkelfelt er dataredundans! Og det er en lavnivå redundans, det vil si repeterende redundans. Avansert redundans er ikke feltbasert
Gjentatte ganger, men derivater av felt.
Eksempel 4: De tre feltene «enhetspris, mengde og mengde» i produktet, «mengde» er utledet fra «enhetspris» multiplisert med «mengde»
Det er redundans, og det er en slags avansert redundans. Formålet med redundans er å øke prosesseringshastigheten. Kun lavnivå redundans vil øke antallet
Inkonsistens i data, fordi de samme dataene kan legges inn flere ganger fra forskjellige tider, steder og roller. Derfor går vi inn for avansert redundans (pie)
redundans av natur), og motsetter seg lavnivå redundans (repeterende redundans).
9. Det finnes ikke noe standardsvar for E-R-diagrammer
Det finnes ikke noe standardsvar på E-R-diagrammet for et informasjonssystem, fordi dets design og tegnemetode ikke er unike, så lenge det dekker virksomheten som kreves av systemet
Omfanget og det funksjonelle innholdet er gjennomførbart. I stedet er det nødvendig å modifisere E-R-diagrammet. Selv om det ikke finnes et enkelt standardsvar, betyr det ikke at det kan være vilkårlig
Design. Kriteriene for et godt E-R-diagram er: klar struktur, konsis assosiasjon, moderat antall enheter, rimelig attributtildeling og ingen lavnivå redundans.
10. Visningsteknikker er nyttige i databasedesign
I motsetning til grunnleggende tabeller, kodetabeller og mellomliggende tabeller, er visninger virtuelle tabeller som er avhengige av de reelle tabellene i datakilden for å eksistere. Visninger er for programmerere
Et vindu som bruker databasen er en form for datasyntese i grunntabeller, en metode for databehandling, og en form for konfidensialitet for brukerdata
betyr. For å utføre kompleks prosessering, øke datahastigheten og spare lagringsplass, bør definisjonsdybden i visningen vanligvis ikke overstige tre lag. Som tre etasjer
Hvis visningen fortsatt ikke er nok, bør du definere en midlertidig tabell på visningen og deretter definere en visning på den midlertidige tabellen. På denne måten defineres dybden i synet gjentatte ganger
Ingen restriksjoner.
For visse informasjonssystemer knyttet til nasjonale politiske, økonomiske, teknologiske, militære og sikkerhetsmessige interesser, er meningenes rolle enda viktigere. Disse
Etter at den fysiske utformingen av systemets grunntabell er fullført, etableres det første laget med visninger umiddelbart på grunntabellen, og antallet og strukturen til dette lagvisningen er det samme som i grunntabellen
Tallet og strukturen er nøyaktig de samme. Og det er fastsatt at alle programmerere kun har lov til å bruke visningen. Kun databaseadministratoren, med
"Sikkerhetsnøkkelen" som holdes av flere personer kan betjenes direkte på det grunnleggende bordet. Leserne inviteres til å tenke: hvorfor er det slik?
11. Mellomliggende tabeller, setninger og midlertidige tabeller
En mellomtabell er en tabell som lagrer statistikk, den er designet for datavarehus, utdatarapporter eller spørringsresultater, og noen ganger har den ikke en primærnøkkel med
fremmednøkler (bortsett fra datavarehus). Midlertidige tabeller er designet av programmerere for å lagre midlertidige poster til personlig bruk. Basis- og mellomtabellene vedlikeholdes av DBA
Midlertidige tabeller vedlikeholdes automatisk av programmereren selv.
12. Integritetsbegrensninger manifesteres i tre aspekter
Domeneintegritet: Bruk Check for å implementere begrensninger, og i databasedesignverktøyet finnes det en Ch når du definerer verdiområdet til feltet
ECK-knappen, hvor verdibyen til feltet defineres.
Referanseintegritet: Implementert med PK-, FK- og tabellnivå-triggere.
Brukerdefinert integritet: Det er noen forretningsregler som implementeres med lagrede prosedyrer og triggere.
13. Metoden for å forhindre patching av databasedesign er prinsippet om «tre mindre»
(1) Jo færre tabeller i en database, desto bedre. Bare hvis antallet tabeller reduseres, kan det sies at E-R-diagrammet til systemet er lite og fint, og det fjernes
De dupliserte og redundante enhetene utgjør en høy grad av abstraksjon av den objektive verden, og systematisk dataintegrasjon utføres for å forhindre patching-design;
(2) Jo færre felt i en tabell som kombinerer primærnøkler, desto bedre. På grunn av primærnøkkelens rolle er den ene å bygge primærnøkkelindeksen, og den andre å fungere som en undertabell
fremmednøkler, slik at antallet felt i kombinasjonen av primærnøkler reduseres, noe som ikke bare sparer kjøretid, men også lagringsplass for indeksen;
(3) Jo færre felt i en tabell, jo bedre. Bare et lite antall felt indikerer at det ikke er noen dataduplisering i systemet
Det er lite dataredundans, og viktigere, leserne oppfordres til å lære å «endre rader», noe som forhindrer at felt blir hentet inn i hovedtabellen i undertabellen
, som etterlater mange frie felt i hovedtabellen. Den såkalte "kolonneendringsraden" er å trekke ut deler av innholdet i hovedtabellen og bygge en separat
Undertabell. Denne metoden er veldig enkel, noen venner seg bare ikke til den, tar den ikke i bruk og implementerer den ikke.
Det praktiske prinsippet for databasedesign er å finne riktig balanse mellom dataredundans og prosesseringshastighet. «Tre mindre» er en helhetlig oversikt
Tanke, helhetlige syn, kan ikke isolere et bestemt prinsipp. Prinsippet er relativt, ikke absolutt. «Tre til»-prinsippet er definitivt feil. Prøv
Tenk: Hvis samme funksjon i systemet dekkes, er E-R-diagrammet med 100 enheter (totalt 1 000 attributter) definitivt bedre enn E-R-diagrammet med 200 enheter (totalt 2 000 attributter)
E-R-diagrammet er mye bedre.
Å fremme prinsippet om «tre mindre» er å la leserne lære å bruke databasedesignteknologi for systematisk dataintegrasjon. Stegene for dataintegrasjon er følgende:
Filsystemet er integrert i en applikasjonsdatabase, applikasjonsdatabasen er integrert i en emnedatabase, og emnedatabasen integreres i en global omfattende database.
Jo høyere grad av integrasjon, desto sterkere er datadelingen, og desto færre informasjonsøyer er til stede
Antall primærnøkler og antall attributter vil være mindre.
Hensikten med å fremme prinsippet om «tre mindre» er å hindre lesere i å bruke patch-teknologi for kontinuerlig å legge til, slette og endre databasen, slik at bedriftsdata kan skapes
Biblioteket har blitt en «søppelhaug» av vilkårlig designede databasetabeller, eller et «rot» av databasetabeller, og forårsaker til slutt de grunnleggende tabellene og generasjonene i databasen
Kodetabellene, mellomtabellene og midlertidige tabellene er rotete og utallige, noe som resulterer i manglende evne til å vedlikeholde og lamme informasjonssystemene til bedrifter og institusjoner.
Prinsippet om «tre til» kan brukes av hvem som helst, noe som er feilslutningen i «patching-metoden» for å designe databaser. Prinsippet om «tre mindre»
Det er et prinsipp om mindre men fint, som krever høye ferdigheter i databasedesign og kunst, noe ikke alle kan gjøre, fordi dette prinsippet elimineres
Det teoretiske grunnlaget for å designe databasen ved bruk av «patching-metoden».
14. Måter å forbedre effektiviteten i databaseoperasjoner på
Under de gitte systemmaskinvare- og systemprogramvareforholdene er metodene for å forbedre driftseffektiviteten til databasesystemet:
(1) I den fysiske utformingen av databasen, redusere paradigmet, øke redundansen, bruke færre triggere og bruke flere lagrede prosedyrer.
(2) Når beregningen er svært kompleks og antallet poster er svært stort (for eksempel 10 millioner), må den komplekse beregningen først være utenfor databasen
Etter at filsystemmetoden er beregnet og behandlet i C++-språket, legges den til slutt til tabellen. Dette er erfaringen med design av telekommunikasjonsfaktureringssystemer.
(3) Hvis en tabell viser seg å ha for mange poster, for eksempel mer enn 10 millioner, bør tabellen deles horisontalt. Praksisen med horisontal segmentering er:
Del tabellens post horisontalt i to tabeller basert på en viss verdi av primærnøkkelen PK i tabellen. Hvis en tabell viser seg å ha for mange felt, for eksempel overskridende
Åtti, bordet deles vertikalt, og det opprinnelige bordet deles i to bord.
(4) Systemoptimalisering av databasestyringssystemet DBMS, det vil si optimalisering av ulike systemparametere, som antall buffere.
(5) Når du bruker dataorientert SQL-språk for programmering, prøv å ta i bruk optimaliseringsalgoritmer.
Kort sagt, for å forbedre driftseffektiviteten til databasen, er det nødvendig å optimalisere databasesystemet, databasedesignet og programimplementeringen
, disse tre nivåene jobber hardt samtidig.
De ovennevnte fjorten ferdighetene oppsummeres gradvis av mange personer i et stort antall databaseanalyse- og designpraksiser. For disse opplevelsene
Lesere bør ikke være rigide eller rutinemessige, men fordøye og forstå, søke sannhet fra fakta, og mestre fleksibelt. Og gradvis gjør: send inn søknaden
utstilling, anvendelse i utvikling.
|
Publisert på 09.04.2015 21:00:54
|
|
|
