Introducere

baza de date relațională a fost propusă de Edgar Codd (de la IBM Research) în jurul anului 1969. De atunci a devenit modelul de bază de date dominant pentru aplicațiile comerciale (în comparație cu alte modele de baze de date, cum ar fi modelele ierarhice, de rețea și de obiecte). Astăzi, există multe sistem comercial de gestionare a bazelor de date relaționale (RDBMS), cum ar fi Oracle, IBM DB2 și Microsoft SQL Server., Există, de asemenea, multe RDBM-uri gratuite și open-source, cum ar fi MySQL, mSQL (mini-SQL) și javadb încorporat (Apache Derby).

o bază de date relațională organizează date în tabele (sau relații). Un tabel este format din rânduri și coloane. Un rând este, de asemenea, numit o înregistrare (sau tuplu). O coloană este, de asemenea, numit un câmp (sau atribut). Un tabel de baze de date este similar cu o foaie de calcul. Cu toate acestea, relațiile care pot fi create între tabele permit o bază de date relațională pentru a stoca în mod eficient cantitate mare de date, și de a prelua în mod eficient datele selectate.,un limbaj numit SQL (Structured Query Language) a fost dezvoltat pentru a lucra cu baze de date relaționale.

obiectivul de proiectare a bazei de date

o bază de date bine concepută trebuie:

  • să elimine redundanța datelor: aceeași bucată de date nu trebuie stocată în mai multe locuri. Acest lucru se datorează faptului că datele duplicate nu numai spațiile de depozitare a deșeurilor, ci conduc cu ușurință la inconsecvențe.
  • asigurați integritatea și acuratețea datelor:
  • mai mult

procesul de proiectare a bazei de date relaționale

designul bazei de date este mai mult artă decât știință, deoarece trebuie să luați multe decizii., Bazele de date sunt de obicei personalizate pentru a se potrivi unei anumite aplicații. Nu există două aplicații personalizate sunt la fel, și, prin urmare, nu există două baze de date sunt la fel. Liniile directoare (de obicei, în ceea ce privește ce să nu facă în loc de ce să facă) sunt furnizate în luarea acestor decizii de proiectare, dar alegerile în cele din urmă se bazează pe tine – proiectantul.

Pasul 1: definiți scopul bazei de date (Analiza cerințelor)

adunați cerințele și definiți obiectivul bazei de date, de ex …

Elaborarea formularelor de introducere eșantion, interogări și rapoarte, de multe ori ajută.,

Pasul 2: adunați date, organizați în tabele și specificați cheile primare

după ce ați decis cu privire la scopul bazei de date, colectați datele care sunt necesare pentru a fi stocate în baza de date. Împărțiți datele în tabele bazate pe subiect.

alegeți o coloană (sau câteva coloane) ca așa-numita cheie primară, care identifică în mod unic fiecare dintre rânduri.

cheie primară

în modelul relațional, un tabel nu poate conține rânduri duplicate, deoarece acest lucru ar crea ambiguități în regăsire., Pentru a asigura unicitatea, fiecare tabel trebuie să aibă o coloană (sau un set de coloane), numită cheie primară, care identifică în mod unic fiecare înregistrare a tabelului. De exemplu, un număr unic customerID poate fi folosit ca cheie primară pentru Customers tabelul; productCode pentru Products tabelul; isbn pentru Books masă. O cheie primară se numește o cheie simplă dacă este o singură coloană; se numește o cheie compusă dacă este alcătuită din mai multe coloane.,

majoritatea RDBMS-urilor construiesc un index pe cheia primară pentru a facilita căutarea și regăsirea rapidă.

cheia primară este, de asemenea, utilizată pentru a face referire la alte tabele (care vor fi elaborate mai târziu).

trebuie să decideți ce coloană(coloane) va fi utilizată pentru cheia primară. Este posibil ca decizia să nu fie simplă, dar cheia primară trebuie să aibă următoarele proprietăți:

  • valorile cheii primare trebuie să fie unice (adică nicio valoare duplicată)., De exemplu, customerName poate să nu fie adecvat pentru a fi folosit ca cheie primară pentru Customers masa, ca ar putea exista doi clienti cu acelasi nume.
  • cheia primară trebuie să aibă întotdeauna o valoare. Cu alte cuvinte, nu trebuie să conțină nul.

luați în Considerare următoarele, în a alege cheia primară:

  • cheia primară trebuie să fie simplu și familiar, de exemplu, employeeID pentru employees masă și isbn pentru books masă.,
  • valoarea cheii primare nu trebuie să se schimbe. Cheia primară este utilizată pentru a face referire la alte tabele. Dacă îi modificați valoarea, trebuie să schimbați toate referințele; în caz contrar, referințele vor fi pierdute. De exemplu, phoneNumber poate să nu fie adecvat pentru a fi folosit ca cheie primară pentru tabelul Customers, pentru că s-ar putea schimba.
  • cheia primară utilizează adesea tipul întreg (sau număr). Dar ar putea fi și alte tipuri, cum ar fi textele. Cu toate acestea, cel mai bine este să utilizați coloana numerică ca cheie primară pentru eficiență.
  • cheie primară ar putea lua un număr arbitrar., Cele mai RDBMSs sprijin așa-numita auto-increment (sau AutoNumber tip) pentru întreg cheie primară, în cazul în care (curent maxim de valoare + 1) este atribuit un nou record. Acest număr arbitrar este de fapt mai puțin, deoarece nu conține informații factuale. Spre deosebire de informațiile factuale, cum ar fi numărul de telefon, numărul fără fapte este ideal pentru cheia primară, deoarece nu se schimbă.
  • cheia Primară este de obicei o singură coloană (de exemplu, customerID sau productCode). Dar ar putea face, de asemenea, din mai multe coloane. Ar trebui să utilizați cât mai puține coloane posibil.,

Let’s illustrate with an example: a table customers contains columns lastName, firstName, phoneNumber, address, city, state, zipCode. The candidates for primary key are name=(lastName, firstName), phoneNumber, Address1=(address, city, state), Address1=(address, zipCode). Name may not be unique. Phone number and address may change., Prin urmare, este mai bine să creați un număr de auto-increment fără fapte, Să zicem customerID, ca cheie primară.

Pasul 3: creați relații între tabele

o bază de date formată din tabele independente și fără legătură are un scop mic (puteți lua în considerare utilizarea unei foi de calcul în schimb). Puterea bazei de date relaționale constă în relația care poate fi definită între tabele. Cel mai important aspect în proiectarea unei baze de date relaționale este identificarea relațiilor dintre tabele., Tipurile de relații includ:

  1. one-to-many
  2. many-to-many
  3. one-to-one
One-to-Many

într-o bază de date „class roster”, un profesor poate preda zero sau mai multe clase, în timp ce o clasă este predată de un singur profesor (și numai unul). Într-o bază de date „companie”, un manager gestionează zero sau mai mulți angajați, în timp ce un angajat este gestionat de un singur manager. Într-o bază de date „vânzări de produse”, un client poate plasa mai multe comenzi; în timp ce o comandă este plasată de un anumit client. Acest tip de relație este cunoscut ca unu-la-mulți.,

relația unu-la-mulți nu poate fi reprezentată într-un singur tabel. De exemplu, într-o „clasă listă” baza de date, am putea începe cu un tabel numit Teachers, care stochează informații despre profesori (cum ar fi name, office, phone și email). Pentru a stoca cursuri predate de către fiecare profesor, am putea crea coloane class1, class2, class3, dar se confruntă cu o problemă imediat pe cât de multe coloane pentru a crea., Pe de altă parte, dacă vom începe cu un tabel numit Classes, care stochează informații despre o clasă (courseCode, dayOfWeek, timeStart și timeEnd); am putea crea coloane suplimentare pentru a stoca informații despre (o) profesor (cum ar fi name, office, phone și email). Cu toate acestea, deoarece un profesor poate preda multe clase, datele sale ar fi duplicate în mai multe rânduri în tabelul Classes.,

Pentru a sprijini o unu-la-multe relații, avem nevoie pentru a proiecta două tabele: o masă Classes pentru a stoca informații despre clasele cu classID ca cheie primară; și o masă Teachers pentru a stoca informații despre profesorii cu teacherID ca cheie primară. Putem crea apoi relația unu-la-mulți prin stocarea cheii primare a tabelului Teacher (adică .,, teacherID) („o”sau în tabelul părinte) în tabelul classes („multe”sau în tabelul copil), cum este ilustrat mai jos.

coloana teacherID în tabelul de copil Classes este cunoscut sub numele de cheie externă. O cheie străină a unui tabel copil este o cheie primară a unui tabel părinte, folosit pentru a face referire la tabelul părinte.

rețineți că pentru fiecare valoare din tabelul părinte, ar putea exista zero, unul sau mai multe rânduri în tabelul copil., Pentru fiecare valoare din tabelul copil, există un singur rând în tabelul părinte.într-o bază de date” vânzări de produse”, comanda unui client poate conține unul sau mai multe produse; iar un produs poate apărea în mai multe comenzi. Într-o bază de date „librărie”, o carte este scrisă de unul sau mai mulți autori; în timp ce un autor poate scrie zero sau mai multe cărți. Acest tip de relație este cunoscut ca mulți-La-mulți.

să ilustrăm cu o bază de date” vânzări de produse”. Începem cu două tabele: Productsși Orders., Tabelul products conține informații despre produse (cum ar fi name, description și quantityInStock) cu productID ca cheie primară. Tabelul orders conține comenzile clienților (customerID, dateOrdered, dateRequired și status). Din nou, nu putem stoca articolele comandate în tabelul Orders, deoarece nu știm câte coloane să rezervăm pentru articole., De asemenea, nu putem stoca informațiile despre comandă în tabelul Products.

Pentru a sprijini mai multe-la-multe relații, avem nevoie pentru a crea o a treia masă (cunoscut ca un nod de masă), spune OrderDetails (sau OrderLines), în cazul în care fiecare rând reprezintă un element de un anumit ordin. Pentru OrderDetails tabel, cheia primară este formată din două coloane: orderID și productID, care identifică în mod unic fiecare rând., Coloanele orderID și productID în OrderDetails tabel sunt utilizate pentru referință Orders și Products tabele, prin urmare, ele sunt, de asemenea, chei străine în OrderDetails masă.

relația mulți-La-mulți este, de fapt, implementată ca două relații unu-la-mulți, cu introducerea tabelului de joncțiune.

  1. o comandă are multe elemente în OrderDetails. Un element OrderDetails aparține unei anumite ordini.,
  2. un produs poate apărea în multe OrderDetails. Fiecare element OrderDetails a specificat un produs.
unu-la-Unu

Într-un „vânzările de produse” bază de date, un produs poate fi opțional informații suplimentare, cum ar fi image, moreDescription și comment. Păstrarea lor în tabelul Products are ca rezultat multe spații goale (în acele înregistrări fără aceste date opționale). În plus, aceste date mari pot degrada performanța bazei de date.,

în Schimb, putem crea un alt tabel (spun ProductDetails, ProductLines sau ProductExtras) pentru a stoca datele opționale. O înregistrare va fi creată numai pentru acele produse cu date opționale. Cele două tabele, Products și ProductDetails, prezintă o unu-la-unu relație. Adică, pentru fiecare rând din tabelul părinte, există cel mult un rând (posibil zero) în tabelul copil. Aceeași coloană productID ar trebui utilizată ca cheie primară pentru ambele tabele.,unele baze de date limitează numărul de coloane care pot fi create în interiorul unui tabel. Ai putea folosi o relație unu-la-unu pentru a împărți datele în două tabele. Relația unu-la-unu este utilă și pentru stocarea anumitor date sensibile într-un tabel securizat, în timp ce cele nesensibile din tabelul principal.

tipuri de date coloană

trebuie să alegeți un tip de date adecvat pentru fiecare coloană. În mod obișnuit, tipurile de date includ: numere întregi, numere în virgulă mobilă, șir (sau text), dată/oră, binar, colecție (cum ar fi enumerarea și setul).,

Pasul 4: Rafina & Normalizarea Design

De exemplu,

  • adăugarea de mai multe coloane,
  • de a crea un nou tabel de date opțional folosind unu-la-unu relație,
  • împărți o masă mare în două mese mai mici,
  • altele.
normalizare

aplicați așa-numitele reguli de normalizare pentru a verifica dacă baza de date este corectă și optimă din punct de vedere structural.

prima formă normală( 1NF): un tabel este 1NF dacă fiecare celulă conține o singură valoare, nu o listă de valori. Aceste proprietăți sunt cunoscute sub numele de atomice., 1NF, de asemenea, interzice repetarea grup de coloane, cum ar fi item1, item2,.., itemN. În schimb, ar trebui să creați un alt tabel folosind relația unu-la-mulți.

a doua formă normală( 2NF): un tabel este 2NF, dacă este 1NF și fiecare coloană non-cheie depinde în totalitate de cheia primară. În plus, în cazul în care cheia primară este alcătuită din mai multe coloane, fiecare coloană fără cheie depinde de întregul set și nu de o parte din acesta.,

De exemplu, cheia primară a OrderDetails tabel cuprinzând orderID și productID. Dacă unitPrice depinde doar productID, ea nu trebuie să fie păstrate în OrderDetails masa (dar în Products table). Pe de altă parte, dacă unitPrice este dependentă de produs precum și un ordin special, atunci acesta trebuie să fie păstrate în OrderDetails masă.,

a treia formă normală( 3NF): un tabel este 3NF, dacă este 2NF și coloanele non-cheie sunt independente una de cealaltă. Cu alte cuvinte, coloanele non-cheie sunt dependente de cheia primară, numai de cheia primară și nimic altceva. De exemplu, să presupunem că avem un Products tabel cu coloane productID (cheie primară), name și unitPrice., Coloana discountRate nu aparțin Products masă dacă este, de asemenea, dependentă de unitPrice, care nu face parte din cheia primară.

forma Normală Superioară: 3NF are inadecvările sale, ceea ce duce la o formă Normală Superioară, cum ar fi forma normală Boyce/Codd, a patra formă normală (4NF) și a cincea formă normală (5NF), care este dincolo de domeniul de aplicare al acestui tutorial.uneori, puteți decide să încălcați unele dintre regulile de normalizare, din motive de performanță (de ex.,, de a crea o coloană numită totalPrice în Orders tabel care pot fi derivate din orderDetails înregistrări); sau pentru utilizatorul final solicitat pentru aceasta. Asigurați-vă că sunteți pe deplin conștienți de aceasta, dezvoltați logica de programare pentru a o gestiona și documentați corect decizia.

reguli de Integritate

de asemenea, ar trebui să aplicați regulile de Integritate pentru a verifica integritatea designului dvs.:

regula de Integritate a entității: cheia primară nu poate conține nul. În caz contrar, nu poate identifica în mod unic rândul., Pentru cheie compozit format din mai multe coloane, nici una din coloana poate conține nul. Majoritatea RDBMS verifică și aplică această regulă.

regula de integritate referențială: fiecare valoare a cheii străine trebuie să fie potrivită cu o valoare a cheii primare din tabelul de referință (sau tabelul părinte).

  • puteți introduce un rând cu o cheie străină în tabelul copil numai dacă valoarea există în tabelul părinte.
  • dacă valoarea cheii se modifică în tabelul părinte (de exemplu, rândul actualizat sau șters), toate rândurile cu această cheie străină din tabelul(tabelele) copil trebuie tratate corespunzător., Puteți fie (a) să nu permiteți modificările; (b) să faceți în cascadă modificarea (sau să ștergeți înregistrările) în tabelele copil în consecință; (c) să setați valoarea cheie din tabelele copil la nul.cele mai multe RDBMS pot fi configurate pentru a efectua verificarea și pentru a asigura integritatea referențială, în modul specificat.integritatea logicii de afaceri: pe lângă cele două reguli generale de integritate de mai sus, ar putea exista integritate (validare) referitoare la logica de afaceri, de ex.,, codul poștal trebuie să fie de 5 cifre într-un anumit interval, data și ora livrării trebuie să scadă în orele de lucru; cantitatea comandată trebuie să fie egală sau mai mică decât cantitatea din stoc etc. Acestea ar putea fi efectuate în regula de validare (pentru coloana specifică) sau logica de programare.
    indexarea coloanelor

    puteți crea index pe coloanele selectate pentru a facilita căutarea și regăsirea datelor. Un index este un mod structurat de fișiere care accelerează de date de acces pentru SELECT, dar poate încetini INSERT, UPDATE și DELETE., Fara o structura de index, pentru a procesa un SELECT interogare cu un criteriu de potrivire (de exemplu, SELECT * FROM Customers WHERE name='Tan Ah Teck'), la motorul de baze de date are nevoie pentru a compara toate înregistrările din tabel. Un indice de specialitate (de exemplu, în structura BTREE) ar putea ajunge la înregistrarea fără a compara fiecare înregistrări. Cu toate acestea, indicele trebuie să fie reconstruit ori de câte ori o înregistrare este schimbat, ceea ce duce la aeriene asociate cu utilizarea indexuri.

    Index poate fi definit pe o singură coloană, un set de coloane (numit index concatenat), sau o parte a unei coloane (de ex.,, primele 10 caractere ale unui VARCHAR(100)) (numit index parțial) . Ai putea construit mai mult de un index într-un tabel. De exemplu, dacă aveți de multe ori de căutare pentru un client, folosind fie customerName sau phoneNumber, ai putea accelera de căutare prin construirea unui index pe coloana customerName, precum și phoneNumber. Cele mai multe RDBMS construiește index pe cheia primară în mod automat.

    referințe & resurse

    Ultima versiune testată: MySQL 5.5.15
    Ultima modificare: septembrie, 2010

Lasă un răspuns

Adresa ta de email nu va fi publicată. Câmpurile obligatorii sunt marcate cu *