Oracle SQL şi PL / SQL - 8. Date de modelare şi design de baze de date

Postat de admin

23 septembrie 2008 460 vizitari

Când vom crea baza de date, trebuie să ia în considerare cu atenţie componenta-componenta. Pentru instrucţiuni legate de proiectarea, putem să urmaţi concepte discutate în discuţie de data asta.

Sistemul de ciclul de dezvoltare
Baza de date Design
Challenge la Gestionarea datelor

8.1. Sistemul de ciclul de dezvoltare

Pornind de la conceptul de producţie, vom construi un sistem de baze de date, folosind Ciclul de dezvoltare. Acest ciclu este format din mai multe etape de dezvoltare.

Abordare de sus în jos şi sistematică de dezvoltare a acestei baze de date pentru a transforma nevoile de afaceri de informaţii la baza de date operationale.

8.1.1. Etape de dezvoltare

Analiză şi strategie de

Aflaţi şi analiza nevoilor de afaceri. Intervievat de manager şi a utilizatorilor de a identifica nevoile de informaţii. Combinand de companie şi de aplicarea sa în caietul de sarcini al sistemului în viitor.
Construi un model de sistem. Transfer de povestiri care au fost construite pe strategia de la faza de analiză şi reprezentarea grafică a nevoilor de informaţii de afaceri şi-regulă de politică. Confirmaţi şi cu modelul de filtru de analişti şi experţi.

Design

Proiectarea unei baze de date. Entitate relationale model de harta pentru a entităţilor de a tabelelor, atribute de coloane, o mare cheile de la străini, şi reguli de afaceri în contraints.

Dezvoltare şi documentare

Construirea unui prototip de sistem. Scrierea şi executând comenzi pentru a crea tabele şi obiecte de la baza sa de date.
Punerea în documentaţia de utilizator, vă ajuta ecran de tip text, exploatarea şi manualul de utilizare pentru a sprijini şi de funcţionare a sistemului.

De tranziţie

Filtru de prototip. Mutarea în aplicare pentru producţia de test împotriva utilizatorilor de venituri, de conversie a datelor care există deja, şi de operaţiunile de paralel.
Schimbările necesare de instituire a

Productie

Aplicare a sistemului pentru utilizatori. Operează în sistem de producţie. De performanţă, şi de a spori şi de filtru de sistem.

8.2. Baza de date Design

Proiectarea unui sistem de baze de date relationale care implică procesul de conversie la modelul de reprezentări în software-ul care poate lucra. Entităţi (sau obiecte), care este simţit de către utilizator transformat într-o masă-masă în baza de date. În timpul procesului de proiectare, scopul nostru este de proiectare a unui fiabile, de înaltă performanţă, folosind toate sistemele de care este produsă de toate de afaceri realizată în faza de analiză. Factorii cheie de la următoarele detalii explica de ce ar trebui să fie cea de-a doua perioadă de proiectare.

Performanţă

Iniţială de proiectare a sistemului au o foarte mare influenţă asupra performanţei scop. În general, impactul este mult mai mare ameliorare comparativ Tuning sistem a fost să fie difuzate.

Aplicaţii integrate
Sistemul de aplicaţii sunt, de obicei, construit de o echipa de dezvoltatori. Fără unele din specificaţia de proiectare a modului în care aceste sisteme de lucru, fiecare cu dezvoltatorul va construi propriul stil. Bun de design nu este folositor doar pentru a ridica si uita-te gust, dar de asemenea convins de faptul că fiecare componentă a sistemului integrat de fiecare aplicare cu una cu alta.

Integrarea cu alte sistem de

Deseori sunt nevoile că noul sistem este integrat cu sistemele care au fost acolo, sau chiar cu alte sisteme, care a construit recent. Bun de design pentru a creşte beneficiile de integrare care a fost descris mai sus în sistem, în general.

Documentaţie şi Comunicare

Partea principală a unui designer de lucru este de eforturile de proiectare cu alte decizii. În final, deciziile trebuie să fie documentate.

Scalabilitatea

Talisman probleme de performanţă în timpul de design decât în momentul de producţie. De exemplu, pentru a construi în sistem de mediu a întreprinderilor mici şi controlată, fără mengujinya privind situaţia sau, într-adevăr, în colectarea de date de mare ca factori care pot dezvălui în defecte de proiectare-defect.

Evitaţi Găsirea unei roata spate

Multe dintre probleme ar putea să întâlniţi au fost de găsit pe cineva înainte de noi. Utilizaţi un desen sau un model de succes care a fost înainte, dacă este posibil.

8.2.1. Model de date

Modelul este baza de proiectare. Inginerii construi un model de masina memproduksinya şi înainte de a le face munca pe detalii de fiecare. În acelaşi fel, sistemul de designeri de a dezvolta modele de a explora idei şi de a creşte înţelegerea desenului sau a modelului de baza de date.

8.2.1.1. Utilizarea Model de obiectiv

Model de eforturi pentru a ajuta la conceptele de mintii umane. Modelul poate fi utilizat în următoarele scopuri:

Eforturile de a
Subsume
Descrie
Definiţi
De examen
Aranjare
Analiza
Mima

Obiectivele sale sunt rezultatul adecvat model pentru mulţi utilizatori, pot fi de înţeles de către utilizator, dar detaliile sunt destul de dezvoltator pentru a construi un sistem de baze de date.

8.3. Entitate relaţie de modelare

Entitate relaţie model derivat din caietul de sarcini sau a unui text de afaceri. Acest model este o reprezentare grafică a nevoilor de informaţii de afaceri şi-regulă de politică.

Model de relaţie de entităţi, de a separa informaţiile necesare de afaceri din activităţile efectuate de afaceri. Deşi activităţile de afaceri se pot schimba, de tipul de informaţii tinde să ţineţi ferm. Prin urmare, structura de date de asemenea, tind să ţineţi ferm.

8.3.1. Profit entitate relaţie model

De informaţii are nevoie de documentare de companii cu un format care este clară şi precisă
Furnizaţi o imagine de hartă care este uşor de înţeles, în contextul proiectare a unei baze de date
Dezvoltarea şi uşor de modelul de filtru
Oferind o imagine clară despre gama de informaţii
Oferă un cadru eficient pentru a integra mai multe aplicaţii, proiect de dezvoltare, de achiziţie şi de aplicare de pachete

8.3.2. Componente de

Relaţia de entităţi, Model structurat de entitate, atribut, şi relaţia

De entităţi,
- Ceva important cu privire la nevoile de informaţii dmana trebuie să ştiu. De entităţi, care reprezintă ceva important de la un sistem de afaceri, sau de a explica categorii sau grupuri de date referitoare la fiecare. De exemplu, este al clientului, pentru, şi de angajaţi. Pentru a reprezenta o entitate de la model, am posibilitatea să utilizaţi următoarele dispoziţii:
  - Caseta cu dimensiuni de anumite
  - Nume şi de o singură entitate unică
  - Nume cu majuscule entitate
  - Numele de sinonime opţional cu majuscule împrejmuit semn "()"
Atribut
- Ceva care descrie şi presupun o entitate. Explica de atribute şi entitate care deţine informaţii specifice pe care trebuie să fie cunoscute despre o entitate. De exemplu, de entitate pentru acest client, atribut poate fi un număr de client, numele, adresa şi numărul de telefon. Dacă o entitate nu are un atribut care trebuie să fie dintr-o perspectivă de afaceri, el nu este în raza de acţiune a nevoilor de sistem, şi ar trebui să nu apară în model. Fiecare poate este obligat să atribut (obligatoriu) şi opţionale. Această condiţie se numeşte denan opsionalitas (opţiune). Pentru a reprezenta atribut în modelul, putem utiliza următoarele dispoziţii:
  - Folosiţi un singur nume în litere mici
  - Identificarea atribut necesar, sau de valoarea pe care ar trebui să fie cunoscute, prin utilizarea "*"
  - Identificaţi atributul este opţională (nu este obligatoriu), prin utilizarea de "O"
Relaţia
- Relaţiile dintre entitatea care arată opsionalitas sau de grade. Fiecare entitate trebuie să aibă o relaţie care reprezintă nevoile de informare şi de normele de afaceri. Relaţia este un mod de relaţie cu două dintre cele două entităţi, sau de o entitate în sine. Atunci când o entitate are o relaţie cu relaţia în sine, aşa-numitele recursive.
- Relaţia de sintaxă
  - Fiecare entitate sursă [poate fi | trebuie să fie] relaţie de nume de [unul şi numai unul | unul sau mai multe] destinaţie entitate
  - Notă: Regulile sunt citite sensul acelor de ceasornic
- Relaţia reguli Grafic
  - Dashed linie (-)
    - Opţional elemente care "poate fi"
  - Solid linie (-)
    - Elemente obligatorii, care "trebuie să fie"
  - Crow's Foot (ciori picioare)
    - Elemente care indica gradul de "unul sau mai multe"
  - Single-linie (-)
    - Elemente care indica gradul de "una şi numai una"
- Relaţia recursive
  - Relaţia dintre entitate în sine şi a solicitat relaţii recursive. Reprezentat de "porc de urechi" (urechi de porc).
- Tipuri de relaţie
  - Unu-la-unu
    - De grade unul şi numai unul în ambele direcţii. Acest tip de rare, şi poate într-adevăr, este de aceeaşi entitate, atribut sau a entităţii. Exemplu: Relaţiile dintre sot si sotie.
  - Multe-la-unu
    - Unul sau mai multe grade într-o direcţie şi un grad, şi numai unul în celălalt direcţie. Acesta este un tip foarte comun. Exemplu: Relaţiile dintre aeronave şi pasageri.
  - Multe-la-multe
    - Unul sau mai multe grade în ambele direcţii. Acesta este un tip foarte comun. Exemplu: Relaţiile dintre angajaţi şi expertiză.
UID (identificator unic)
- Identificator unic este o combinaţie de atribute sau de relaţie, sau ambele, care funcţionează ca pembeda de performanţă din fiecare entitate. Aspectul de fiecare entitate trebuie să fie unic pot fi identificate.
  - Cunoaşte fiecare atribut care să fie o parte din UID cu numărul simbol (#)
  - Cunoaşte-UID doilea cu un număr de simboluri închise în ghilimele unice ('#')
- Identificator unic prin relaţia
  O entitate pot fi identificate printr-o relaţie de unic. Utilizaţi bara de UID pentru a indica faptul că o relaţie este parte a unui identificator unic de entitate. Relaţia incluse în UID ar trebui să aibă un caracter obligatoriu, şi doar una din relaţie care participa la UID.
  - Exemple de când ne vom face o comandă de achiziţionare, avem de numărul de ordine şi de linie de elemente cu un număr unic de element. Dar atunci când este efectuată pentru alte achiziţii, de numărul de elemente nu mai este unic. Prin urmare, aceste elemente sunt identificate în mod unic prin numărul său de atribut şi pentru un anumit număr de elemente în cazul în care berelasi.
  Număr de ordine, numărul de elemente, numărul de produse
  100, 1, 209
  100, 2, 399
  100, 3, 876
  101, 1, 630
  101, 2, 297

8.4. Normalisasi

Înainte de a crea o bază de date de proiectare, trebuie să ne minimiza problemele de date normalisasi de a face cu modelul de date. Avem nevoie de a modifica modelul de date pentru a sprijini nevoile de diferite funcţional şi de a modifica designul bazei de date cu stocare de date normalisasi am făcut înainte de a crea baza de date.

8.4.1. Beneficii Normalisasi

Redundanţă a datelor Minimizarea
Reduce problemele de integritate
Identificarea de entitate, relaţie, şi tabelul de terlewatkan

8.4.2. Reguli Normalisasi

Prima formă normală (1NF)
- Toate singur atribut de a fi evaluate şi nu se repetă
A doua formă normală (2NF)
- Fiecare atribut trebuie să depind toate de identificator unic (UID) este o entitate
A treia formă normală (3NF)
- Aici nu poate fi non-UID, care depind de alte non-UID

8.5. Integritate şi de constrângere cheie

Asiguraţi-vă că numai utilizatorii care permite efectuarea operaţiunilor de baza de date pentru a fi în concordanţă cu punerea în aplicare de Integritate, constrângere. Toate datele de Integritate constrângere trebuie să fie aplicate de către serverul de baze de date sau aplicaţii software. Cheie (cheie) pot reconcilia cu constrângere de Integritate. Trei tipuri de primar cheie este cheia, cheia unic şi străine cheie.

8.5.1. Tipuri de constrângere de Integritate

De entităţi,
- Aici nu poate fi o parte din cheia primară este NULL, şi valoarea lor trebuie să fie unic (de diferite una cu cealaltă)
Referenţiale
- Valorile străine cheie trebuie să fie în conformitate cu care valoarea cheie primară diacunya, sau NULL
Coloana
- Valorile din coloana trebuie să fie în conformitate cu tipul de date care a fost definit pentru coloana
Definit de utilizator
- Valori ar trebui să se supună regulilor de afaceri (reguli de afaceri)

8.5.2. Tipuri cheie

Primar cheie
Fiecare rând (Record) pe masă este identificat printr-un set unic de coloana coloană sau numit cheie primară (PK). Primar cheie este definit pentru a nu permite valoarea duplicat şi nu pot fi evaluate NULL.
Primar cheie constă în faptul că a sunat de mai multe coloana cu compozite cheie primară sau o cheie primară compus. Coloana-coloana de la compozite cheie primară trebuie să fie unic în combinaţie, chiar dacă se depărta individuale pot avea un duplicat. Nici o parte din cheia primară, care pot avea o valoare NULL.
Candidati cheie
Un tabel poate avea unele chei candidate. Candidati cheie este o coloană sau o combinaţie de coloana, care poate funcţiona ca şi cheia primară pentru tabel.
Alegeţi un candidat pentru a fi cheia ca cheie primară pentru tabel. Candidati cheie va fi de altă alternativă de cheie sau de cheie unică. Ele trebuie să fie unic şi NU NULL.
Externe cheie
Externe cheie (FK) este o coloană sau o combinaţie de o coloană din tabel se referă la cheie primară sau unic de pe cheie sau la aceeaşi masă, pe de altă masă. Externe cheie pe baza valorii de date pur şi logică, şi nu de indicatorul fizice. Valoarea unei străine cheie trebuie să fie în conformitate cu cheia primară sau unică este cheia diacunya, sau poate fi nul. Dacă un străin cheie parte din cheia primară, el nu poate conţine valori null pentru ca acolo nu poate fi o parte din valoarea cheie primară NULL. Exemplu: În ITEM tabel, coloana ORD_ID nu pot conţine valori null pentru ca este parte din cheia primară.

8.6. Design de baze de date

Fazele de proiectare specificaţie genera o baza de date-design caietului de sarcini pentru baze de date relationale, inclusiv definirea de masă, index, a vedea, şi de spaţiu de stocare.

8.6.1. Mapare entitate relaţie model de la tabelul de exemplu Grafic

Maparea de entităţi, în Tabelul
Creaţi un tabel de exemplu diagramă pentru noul tabel. Tabelul exemplu topuri ar trebui să conţină tabelul de coloane pentru numele, numele coloana, tipuri de cheie, nulă şi unic, de informaţii, străine cheie, coloana de date şi o lungime maximă, şi eşantion de date. Salvaţi tablenya nume.
Atribut de cartografiere pentru a coloana
Harta fiecare atribut în modelul entitate relaţie de la nume de coloană din tabel, să adăugaţi exemplu de date de diagramă pentru a afişa conţinutul unui tabel într-un format vizual. Harta obligatoriu un atribut, care este marcat cu asterisc (*), la coloana care este definită ca NOT NULL (NN).
Nu desemnează coloana cu SQL rezervate cuvinte, cum ar fi numărul. Dă numele coloana cu abrevierea-constante, de abrevieri, cum ar fi NU NUM sau (dar nu ambele) pentru a evita confuzia, programatori şi utilizatori.
Mapare identificator unic pentru cheia primară
Harta UID care au fost identificate în modelul de entitate relaţie cu numărul simbol (#) la coloana cheie primară şi marcaţi-o ca o cheie de PK. UID Harta unic care conţine un singur atribut de a-PK coloanei. Mark nulă şi nu unic cu NN şi U. UID harta, care conţine multe atribut compozite de la examen. Mark coloana coloana cu NN-şi U1. Dacă există o cheie primară alternative, de marcă şi de U, cu NN, dar alege numai un singur examen.
Dacă UID conţinute în relaţia (indicată de UID bar), adăugaţi o coloană pentru fiecare FK relaţie cu marca şi PK şi FK. Adăugaţi la coloana coloana-FK la sfârşitul tabelul de exemplu graficul de pe partea dreapta sau din intreaga coloana, chiar dacă este FK parte din examen. Alegeţi un nume unic pentru fiecare coloana FK şi a adăuga date de exemplu.
Mapare Relaţia cu Ministerul de Externe cheie
În ultimul pas este de a harta de relaţie-cheie străine. Există două tipuri de relaţie la care trebuie să fie: Multi-la-unu şi unu-la-unu. Dacă o relaţie este o parte din UID, apoi ne-am memetakannya. Asiguraţi-vă că vom marca un obligatorii relaţie cu NN. Alegeţi un nume unic pentru straini columnt cheie.
- Multe-la-unu Relaţia
  Pentru a Harta multe-la-unu relaţie, prin plasarea unui primar cheie de pe partea de "o" şi pune un străin cheie de pe "multe". Această tehnică poate fi de asemenea aplicate în relaţie recursive.
- Unu-la-unu Opţional Relaţia
  Nu putem pune un străin cheie pe de o parte, pentru relaţia de acest tip de relaţie. Asiguraţi-vă pentru a adăuga U.
- Unu-la-unu obligatorie Relaţia
  Locul de unic străine cheie de pe masă şi o parte obligatorie a marca cu NN de a impune o obligatorii şi are nevoie de U, de a impune unu-la-unu relaţie.

8.6.2. Suplimentare de nevoile

Design index, care este obiectul de baze de date care oferă acces direct şi rapid la Rând pe masă. Ne pot, de asemenea, necesitatea de a crea index pentru cheia de supleant, străine cheie, şi-coloana coloana, care este utilizată frecvent în căutare de date.
Determinarea definiţia de vedere, care este un tabel logic bazat pe una sau mai multe de masă sau de vedere. Vezi poate limita accesul, pentru a îmbunătăţi prezentarea de informaţii, şi pot conţine interogări complexe care au fost create anterior.
Planul de spaţiu de stocare pentru fizică, care este suma totală de spaţiu necesar pentru a stoca datele din tabelul din baza de date.
De constrângere de Integritate

8.6.3. Simboluri de la documentul Tabelul Instanţă Grafic

PK
- Primar cheie
FK
- Externe cheie
FK1, FK2
- Doi straini-cheie de pe acelaşi tabel
FK1, FK1
- Două coloana din compozit străine cheie este acelaşi
NN
- Nu null
U
- Unic
U1, U2
- Două coloana în combinaţie unică

8.6.4. Linii directoare

Nume de masă ar trebui să fie uşor de urmărit înapoi în numele entităţii. Multi-entitate nume este uneori utilizat ca tabelul va conţine multe Row.
Nume coloană ar trebui să fi urmărite cu uşurinţă înapoi la relaţia model de entitate. Nume scurt coloana va reduce perioada de timp necesară analizarea comanda SQL.
Noi ar trebui să construiască propriile sale reguli şi standarde de denumire.

Vă rugăm să continuaţi discuţia de lectură Crearea de tabelul de

Notă:
Pentru a pune de articole pe Oracle SQL & PL / SQL script puteţi descărca tabelul de aici, şi să ruleze în conformitate live demo (browser-ul dvs. trebuie să suport de Flash Player).

Oracle SQL şi PL / SQL