1. Relația dintre documentul original și entitate
Poate fi relații unu-la-unu, unu-la-mulți și mulți-la-mulți. În general, sunt relații unu-la-unu: adică o pereche de documente originale
ar trebui și ar trebui să corespundă doar unei singure entități. În cazuri speciale, ele pot fi relații unu-la-mulți sau mulți-la-unu, adică un document original corespunde mai multor realități
sau mai multe documente originale corespunzătoare unei entități. Entitatea de aici poate fi înțeleasă ca un tabel de bază. După clarificarea acestei corespondențe, proiectează pentru noi
Interfața de intrare este foarte utilă.
〖Exemplul 1〗: Informațiile despre CV-ul unui angajat corespund trei tabele de bază din sistemul de informații despre resurse umane: tabelul de informații de bază al angajatului și societatea
Tabel de relații, formular de CV de muncă. Acesta este un exemplu tipic de "un document original corespunde mai multor entități".
2. Chei primare și străine
În general, o entitate nu poate avea nici o cheie principală, nici una străină. În diagrama E-R, entitățile din partea frunză pot defini cheia primară,
De asemenea, este posibil să nu definești o cheie primară (deoarece nu are copii), dar trebuie să aibă o cheie străină (pentru că are un tată).
Designul cheilor primare și externe ocupă o poziție importantă în designul bazelor de date globale. Când proiectarea bazei de date globale este finalizată, există un
Experții americani în proiectarea bazelor de date au spus: "Chei, chei peste tot, nimic altceva decât chei", aceasta este experiența sa în proiectarea bazelor de date
De asemenea, reflectă ideile sale foarte abstracte despre nucleul sistemelor informaționale (modele de date). Pentru că: cheia primară este o entitate foarte abstractă, iar cheia primară este asociată cu
O pereche de chei străine care reprezintă o conexiune între entități.
3. Natura tabelului de bază
Tabelul de bază este diferit de tabelul intermediar și tabelul temporar deoarece are următoarele patru caracteristici:
(1) Atomicitate. Corpurile din tabelul de bază nu mai pot fi decompozate.
(2) Primitivitate. Înregistrările din tabelul de bază sunt înregistrări ale datelor originale (datele de bază).
(3) Deductiv. Toate datele de ieșire pot fi derivate din datele din tabelul de bază și din tabelul de coduri.
(4) Stabilitate. Structura tabelului de bază este relativ stabilă, iar înregistrările din tabel ar trebui păstrate mult timp.
După înțelegerea naturii tabelelor de bază, atunci când se proiectează baze de date, tabelele de bază pot fi diferențiate de tabelele intermediare și tabelele temporare.
4. Standardele de paradigmă
Relația dintre tabelul de bază și câmpurile sale ar trebui să respecte pe cât posibil al treilea paradigm. Totuși, designurile de baze de date care îndeplinesc a treia paradigmă adesea nu sunt
Cel mai bun design. Pentru a îmbunătăți eficiența operațională a bazelor de date, este adesea necesar să se reducă standardul de paradigmă: să crească în mod adecvat redundanța pentru a obține spațiu pentru timp
Scopul acestuia.
Exemplul 2: Există un tabel de bază pentru depozitarea bunurilor, așa cum este prezentat în Tabelul 1. Prezența câmpului "Sumă" indică faptul că tabelul nu este conceput să fie satisfăcut
A treia paradigmă este suficientă, deoarece "suma" poate fi obținută prin înmulțirea "prețului unitar" cu "cantitate", indicând că "cantitatea" este un câmp redundant. Totuși, creșterea
Câmpul redundant al "cantității" poate îmbunătăți viteza statisticilor interogărilor, care reprezintă practica de a schimba spațiu pentru timp.
În Rose 2002, există două tipuri de coloane prescrise: coloane de date și coloane calculate. O coloană precum "sumă" se numește "coloană de calcul" și
Coloane precum "Preț unitar" și "Cantitate" sunt numite "coloane de date".
Tabelul 1 Structura tabelului mărfurilor
Nume produs Model Produs Unitate Preț Cantitate Cantitate
TV 29 inch 2.500 40 100.000
5. Înțelege cele trei paradigme în termeni simpliști
Înțelegerea celor trei paradigme în termeni simplici este de mare folos pentru proiectarea bazelor de date. În proiectarea bazelor de date, pentru a aplica mai bine cele trei paradigme, doar
Trei paradigme trebuie înțelese în termeni simpli:
Primul paradigm: 1NF este o constrângere atomică asupra atributelor, care necesită ca atributele să fie atomice și să nu mai poată fi descompuse;
Al doilea paradigm: 2NF este constrângerea de unicitate asupra înregistrărilor, care necesită ca înregistrările să aibă o identificare unică, adică unicitatea entității;
Paradigma 3: 3NF este o constrângere asupra redundanței câmpului, adică niciun câmp nu poate fi derivat din alte câmpuri, necesitând ca câmpul să nu fie redundant
。
Niciun design redundant de baze de date nu poate face asta. Totuși, o bază de date fără redundanță nu este neapărat cea mai bună bază de date, uneori pentru a îmbunătăți norocul
Pentru a atinge eficiența, este necesar să se reducă standardul de paradigmă și să se păstreze corespunzător datele redundante. Abordarea specifică este să aderi la a treia paradigmă atunci când proiectezi modele conceptuale de date
, munca de reducere a standardului de paradigmă este luată în considerare în proiectarea modelului fizic de date. Reducerea paradigmei înseamnă adăugarea de câmpuri care permit redundanța.
6. Fii bun la identificarea și gestionarea corectă a relațiilor multi-to-many
Dacă există o relație multe-la-mulți între două entități, această relație ar trebui eliminată. Modul de a o elimina este să adaugi un al treilea real între cele două
Corp. Astfel, ceea ce era odată o relație de tip mulți-la-mulți a devenit acum două relații unu-la-mulți. Atributele celor două entități originale ar trebui să fie distribuite în mod rezonabil
Mergi la cele trei entități. A treia entitate aici este, în esență, o relație mai complexă, care corespunde unui tabel de bază. În general, cifrele
Instrumentul de proiectare a bibliotecii nu poate recunoaște relațiile multe-la-multe, dar poate gestiona relațiile multe-la-mulți.
Exemplul 3: În "Sistemul de Informații al Bibliotecii", "cartea" este o entitate, iar "cititorul" este de asemenea o entitate. Aceste două entități sunt aceeași
Relația dintre cărți este tipică de tip mulți-la-mulți: o carte poate fi împrumutată de mai mulți cititori în momente diferite, iar un cititor poate împrumuta mai multe
Această carte. În acest scop, ar trebui adăugată o a treia entitate între cele două, denumită "împrumut și returnare a cărților", iar proprietățile sale sunt: timpul de împrumut și împrumutul
De asemenea, are un logo (0 înseamnă împrumut o carte, 1 înseamnă returnarea unei cărți), în plus, ar trebui să aibă două chei străine (cheia primară "carte" și cheia primară "cititor"), astfel încât
Se leagă de "cărți" și "cititori".
7. Metoda valorii cheii primare PK
PK este un instrument de conexiune între mese pentru programatori, care poate fi un șir de numere fără semnificație fizică, care este adăugat automat de program la 1. Da
este un nume de câmp cu semnificație fizică sau o combinație de denumiri de câmpuri. Dar prima variantă este mai bună decât a doua. Când PK este o combinație de denumiri de câmpuri, sugerează un număr de câmp
Nu lua prea mult în calcul, deoarece indicele nu doar că ocupă mult spațiu, dar și încetinește.
8. Să faci redundanța corectă a datelor
Repetarea cheilor primare și străine în mai multe tabele nu este un concept de redundanță a datelor, iar mulți oameni nu sunt conștienți de acest lucru
。 Repetarea câmpurilor non-cheie este redundanță de date! Și este o redundanță la nivel scăzut, adică redundanță repetitivă. Redundanța avansată nu se bazează pe teren
Repetat, dar derivate ale câmpurilor.
Exemplul 4: Cele trei câmpuri "preț unitar, cantitate și sumă" din produs, "sumă" derivă din "prețul unitar" înmulțit cu "cantitate"
Este redundanță și este un fel de redundanță avansată. Scopul redundanței este de a crește viteza de procesare. Doar redundanța la nivel scăzut va crește numărul
inconsistența datelor, deoarece aceleași date pot fi introduse de mai multe ori din timpuri, locuri și roluri diferite. Prin urmare, susținem redundanța avansată (pie
redundanță prin natura sa), și se opune redundanței de nivel scăzut (redundanța repetitivă).
9. Nu există un răspuns standard pentru diagramele E--R
Nu există un răspuns standard la diagrama E-R a unui sistem informațional, deoarece proiectarea și metoda sa de desenare nu sunt unice, atâta timp cât acoperă activitatea cerută de sistem
Domeniul de aplicare și conținutul funcțional sunt fezabile. În schimb, este necesară modificarea diagramei E-R. Deși nu are un răspuns standard unic, asta nu înseamnă că poate fi arbitrar
Design. Criteriile pentru o diagramă E-R bună sunt: structură clară, asociere concisă, număr moderat de entități, alocare rezonabilă a atributelor și lipsa redundanței la nivel scăzut.
10. Tehnicile de vizualizare sunt utile în proiectarea bazelor de date
Spre deosebire de tabele de bază, tabelele de cod și tabelele intermediare, vizualizările sunt tabele virtuale care depind de existența tabelelor reale ale sursei de date. Vizualizările sunt pentru programatori
O fereastră care folosește baza de date este o formă de sinteză a datelor din tabelele de bază, o metodă de procesare a datelor și un fel de confidențialitate a datelor utilizatorilor
înseamnă. Pentru a efectua procesări complexe, a crește viteza de calcul și a economisi spațiu de stocare, adâncimea de definire a vizualizării nu ar trebui, în general, să depășească trei straturi. Cam trei etaje
Dacă vizualizarea tot nu este suficientă, ar trebui să definești un tabel temporar pe vizualizare și apoi să definești o vizualizare pe tabelul temporar. Astfel, adâncimea vederii este definită în mod repetat
Fără restricții.
Pentru anumite sisteme informaționale legate de interese politice, economice, tehnologice, militare și de securitate naționale, rolul opiniilor este și mai important. Acestea
După finalizarea designului fizic al tabelului de bază al sistemului, primul strat de vizualizări este stabilit imediat pe tabelul de bază, iar numărul și structura acestei vizualizări de nivel sunt aceleași ca în tabelul de bază
Numărul și structura sunt exact aceleași. Și se stipulează că toți programatorii au voie să opereze doar pe această vizualizare. Doar administratorul bazei de date, cu
"Cheia de siguranță" deținută de mai multe persoane poate fi operată direct pe masa de bază. Cititorii sunt invitați să se gândească: de ce se întâmplă asta?
11. Tabele intermediare, instrucțiuni și tabele temporare
Un tabel intermediar este un tabel care stochează statistici, este conceput pentru stocarea datelor, rapoarte de ieșire sau rezultate de interogare, iar uneori nu are o cheie primară cu
chei străine (cu excepția depozitelor de date). Tabelele temporare sunt proiectate de programatori pentru a stoca înregistrări temporare pentru uz personal. Tabelele de bază și intermediară sunt menținute de DBA
Tabelele temporare sunt menținute automat chiar de programator.
12. Constrângerile de integritate se manifestă în trei aspecte
Integritatea domeniului: Folosește Check pentru a implementa constrângerile, iar în instrumentul de proiectare a bazei de date există un Ch la definirea intervalului de valori al câmpului
butonul ECK, prin care este definită valoarea orașului câmpului.
Integritate referențială: implementată cu PK, FK și trigger-uri la nivel de tabel.
Integritate definită de utilizator: Sunt unele reguli de business implementate prin proceduri stocate și trigger-uri.
13. Metoda de prevenire a patch-urilor în designul bazei de date este principiul "trei mai puțin"
(1) Cu cât există mai puține tabele într-o bază de date, cu atât mai bine. Doar dacă numărul de tabele este redus se poate spune că diagrama E-R a sistemului este mică și fină, iar aceasta este eliminată
Entitățile duplicate și redundante formează un grad ridicat de abstractizare a lumii obiective, iar integrarea sistematică a datelor se realizează pentru a preveni designul patch-urilor;
(2) Cu cât mai puține câmpuri dintr-un tabel care combină cheile primare, cu atât mai bine. Datorită rolului cheii primare, una este să construiască indicele cheii primare, iar cealaltă să servească drept sub-tabel
chei străine, astfel încât numărul de câmpuri din combinația cheilor primare este redus, ceea ce nu doar economisește timp de rulare, ci și spațiu de stocare în index;
(3) Cu cât există mai puține câmpuri într-un tabel, cu atât mai bine. Doar un număr mic de câmpuri indică faptul că nu există duplicare a datelor în sistem
Există puțină redundanță de date și, mai important, cititorii sunt îndemnați să învețe să "schimbe rândurile", ceea ce previne ca câmpurile să fie atrase în tabelul principal din subtabelul
, lăsând multe terenuri libere în masa principală. Așa-numitul "rând de schimbare a coloanei" este pentru a extrage o parte din conținutul tabelului principal și a construi unul separat
Sub masă. Această metodă este foarte simplă, unii oameni pur și simplu nu se obișnuiesc, nu o adoptă și nu o implementează.
Principiul practic al proiectării bazelor de date este de a găsi echilibrul potrivit între redundanța datelor și viteza de procesare. "Trei mai puțin" este o prezentare holistică
Gândirea, viziunile cuprinzătoare, nu pot izola un anumit principiu. Principiul este relativ, nu absolut. Principiul "încă trei" este cu siguranță greșit. Încearcă
Gândește-te: dacă este acoperită aceeași funcție a sistemului, diagrama E-R a 100 de entități (1.000 de atribute în total) este cu siguranță mai bună decât diagrama E-R a celor 200 de entități (2.000 de atribute în total)
Diagrama E-R este mult mai bună.
A susține principiul "trei mai puțin" înseamnă a permite cititorilor să învețe să folosească tehnologia de proiectare a bazelor de date pentru integrarea sistematică a datelor. Pașii pentru integrarea datelor sunt:
Sistemul de fișiere este integrat într-o bază de date a aplicației, baza de date a aplicației este integrată într-o bază de date tematică, iar baza de date a temelor este integrată într-o bază de date globală cuprinzătoare.
Cu cât gradul de integrare este mai mare, cu atât partajarea datelor este mai puternică și cu cât există mai puține insule informaționale
Numărul cheilor primare și numărul de atribute vor fi mai mici.
Scopul susținerii principiului "cu trei mai puțin" este de a preveni ca cititorii să folosească tehnologia de patch-uri pentru a adăuga, șterge și modifica constant baza de date, astfel încât să creeze date la nivel enterprise
Biblioteca a devenit un "morman de gunoi" de tabele de baze de date proiectate arbitrar sau un "haos" de tabele de baze de date, și în cele din urmă cauzează tabelele și generațiile de bază în bază de date
Tabelele de coduri, tabelele intermediare și tabelele temporare sunt aglomerate și nenumărate, ceea ce duce la incapacitatea de a menține și paraliza sistemele informatice ale întreprinderilor și instituțiilor.
Principiul "încă trei" poate fi aplicat de oricine, care este eroarea metodei "patch-urilor" pentru proiectarea bazelor de date. Principiul "trei mai puțin"
Este un principiu de "mai puțin, dar bine", care necesită abilități ridicate de proiectare a bazelor de date și artă, lucru pe care nu toată lumea îl poate face, pentru că acest principiu este eliminat
Baza teoretică pentru proiectarea bazei de date folosind "metoda patch-urilor".
14. Modalități de îmbunătățire a eficienței operării bazelor de date
În condițiile date de hardware și software de sistem, metodele de îmbunătățire a eficienței operaționale a sistemului de baze de date sunt:
(1) În proiectarea fizică a bazei de date, reducerea paradigmei, creșterea redundanței, folosirea mai puținelor trigger-uri și utilizarea mai multor proceduri stocate.
(2) Când calculul este foarte complex și numărul de înregistrări este foarte mare (de exemplu 10 milioane), calculul complex trebuie mai întâi să fie în afara bazei de date
După ce metoda sistemului de fișiere este calculată și procesată în limbajul C++, aceasta este în cele din urmă adăugată în tabel. Aceasta este experiența proiectării sistemelor de facturare pentru telecomunicații.
(3) Dacă se constată că un tabel are prea multe înregistrări, cum ar fi mai mult de 10 milioane, tabelul trebuie împărțit orizontal. Practica segmentării orizontale este:
Împărțiți înregistrarea tabelului orizontal în două tabele pe baza unei anumite valori a cheii principale PK a tabelului. Dacă se constată că un tabel are prea multe câmpuri, cum ar fi depășirea
Optzeci, masa este împărțită vertical, iar masa originală este împărțită în două tabele.
(4) Optimizarea sistemului de gestionare a bazelor de date DBMS, adică optimizarea diferiților parametri ai sistemului, cum ar fi numărul de buffere.
(5) Când se folosește limbaj SQL orientat pe date pentru programare, se încearcă să adopti algoritmi de optimizare.
Pe scurt, pentru a îmbunătăți eficiența operațională a bazei de date, este necesar să se optimizeze sistemul bazei de date, designul bazei de date și implementarea programului
, aceste trei niveluri muncesc din greu în același timp.
Cele paisprezece abilități de mai sus sunt rezumate treptat de mulți oameni în numeroase practici de analiză și proiectare a bazelor de date. Pentru aceste experiențe
Cititorii nu ar trebui să fie rigizi sau mecanici, ci să digerge și să înțeleagă, să caute adevărul din fapte și să stăpânească flexibil. Și să o faci treptat: trimite aplicația
Expoziție, aplicație în dezvoltare.
|
Postat pe 09.04.2015 21:00:54
|
|
|
