Share
Aplicațiile web pot fi împărțite în două componente importante: un front-end care afișează și culege informații și un back-end pentru stocarea informațiilor. În acest articol, voi demonstra ce este o bază de date relațională și cum să creați în mod corespunzător baza de date pentru a stoca informațiile aplicației dvs..
O bază de date stochează date într-un mod organizat, astfel încât să poată fi căutat și preluat ulterior. Ar trebui să conțină unul sau mai multe tabele. O masă este asemănătoare cu o foaie de calcul, deoarece este alcătuită din rânduri și coloane. Toate rândurile au aceleași coloane, iar fiecare coloană conține datele în sine. Dacă vă ajută, gândiți-vă la tabelele dvs. în același mod în care ar fi o masă în Excel.
Figura 1
Datele pot fi inserate, preluate, actualizate și șterse dintr-un tabel. Cuvantul, creată, este în general utilizat în loc de inserat, astfel încât, colectiv, aceste patru funcții sunt abreviate afectiv ca CRUD.
O bază de date relațională este un tip de bază de date care organizează datele în tabele și le leagă, pe baza unor relații definite. Aceste relații vă permit să preluați și să combinați date dintr-unul sau mai multe tabele cu o singură interogare.
Dar asta era doar o grămadă de cuvinte. Pentru a înțelege cu adevărat o bază de date relațională, trebuie să faceți una singură. Să începem prin obținerea unor date reale cu care să putem lucra.
În spiritul articolelor clone Nettuts + Twitter (PHP, Ruby on Rails, Django), hai să obținem câteva date despre Twitter. Am căutat Twitter pentru "#databases" și am luat următorul eșantion de zece tweets:
tabelul 1
| Numele complet | nume de utilizator | text | creat la | following_username |
|---|---|---|---|---|
| "Boris Hadjur" | "_DreamLead" | "Ce credeți despre #emailing #campaigns #traffic in #USA? Este o piață bună în zilele noastre? Aveți #database?" | "Tue, 12 Feb 2013 08:43:09 +0000" | "Scootmedia", "MetiersInternet" |
| "Gunnar Svalander" | "GunnarSvalander" | "Bill Gates discută despre bazele de date, software-ul gratuit pe Reddit http://t.co/ShX4hZlA #billgates #databases" | "Tue, 12 Feb 2013 07:31:06 +0000" | "klout", "zillow" |
| "GE Software" | "GEsoftware" | "RT @KirkDBorne: lecturi în #Databases: lista excelentă de citire, multe categorii: http://t.co/S6RBUNxq via @rxin Fascinant." | "Tue, 12 Feb 2013 07:30:24 +0000" | "DayJobDoc", "byosko" |
| "Adrian Burch" | "Adrianburch" | "RT @tisakovich: @NimbusData la conferința @Barclays Big Data din San Francisco astăzi, vorbind #virtualization, #databases și #flash memory." | "Tue, 12 Feb 2013 06:58:22 +0000" | "CindyCrawford", "Arjantim" |
| "Andy Ryder" | "AndyRyder5" | "http://t.co/D3KOJIvF articol despre Madden 2013 folosind AI pentru a prodict bolul super #databases # bus311" | "Tue, 12 Feb 2013 05:29:41 +0000" | "MichaelDell", "Yahoo" |
| "Andy Ryder" | "AndyRyder5" | "http://t.co/rBhBXjma un articol despre setările de confidențialitate și facebook #databases # bus311" | "Tue, 12 Feb 2013 05:24:17 +0000" | "MichaelDell", "Yahoo" |
| "Brett Englebert" | "Brett_Englebert" | "# BUS311 NCFPD din Universitatea din Minnesota creează #database pentru a preveni" frauda alimentară ". Http://t.co/0LsAbKqJ" | "Tue, 12 Feb 2013 01:49:19 +0000" | "RealSkipBayless", "stephenasmith" |
| Brett Englebert | "Brett_Englebert" | "# Companiile BUS311 s-ar putea să-și protejeze #datele de producție, dar cum ar fi fișierele lor de rezervă? Http://t.co/okJjV3Bm" | "Tue, 12 Feb 2013 01:31:52 +0000" | "RealSkipBayless", "stephenasmith" |
| "Nimbus Data Systems" | "NimbusData" | "@NimbusData CEO @tisakovich @BarclaysOnline Big Data conferință în San Francisco astăzi, vorbind #virtualization, # baze de date, & # flash memory" | "Mon, 11 Feb 2013 23:15:05 +0000" | "dellock6", "rohitkilam" |
| "SSWUG.ORG" | "SSWUGorg" | "Nu uitați să vă înscrieți pentru expoziția noastră GRATUITă de vineri: #Databases, #BI și #Sharepoint: Ce trebuie să știți! Http://t.co/Ijrqrz29" | "Mon, 11 Feb 2013 22:15:37 +0000" | "drsql", "steam_games" |
Iată ce înseamnă fiecare nume de coloană:
MySQL este folosit la aproape orice companie de Internet pe care ați auzit-o.
Toate acestea sunt date reale; puteți căuta Twitter și găsi de fapt aceste tweets.
Asta e bine. Datele sunt toate într-un singur loc; așa că este ușor de găsit, nu? Nu chiar. Există câteva probleme cu acest tabel. În primul rând, există date repetitive în coloane. Coloanele "username" și "following_username" sunt repetitive, deoarece ambele conțin același tip de date - mâinile Twitter. Există o altă formă de repetare în coloana "next_username". Câmpurile trebuie să conțină numai o valoare, dar fiecare dintre câmpurile "next_username" conține două.
În al doilea rând, există date repetitive între rânduri.
@ AndyRyder5 și @Brett_Englebert fiecare tweeted de două ori, astfel încât restul informațiilor lor a fost duplicat.
Duplicatele sunt problematice, deoarece fac operațiunile CRUD mai dificile. De exemplu, ar fi nevoie de mai mult timp pentru a prelua date, deoarece timpul ar fi risipit, trecând prin rânduri duplicate. De asemenea, actualizarea datelor ar fi o problemă; dacă un utilizator modifică mânerul Twitter, ar trebui să găsim fiecare duplicat și să îl actualizăm.
Datele repetitive reprezintă o problemă. Putem rezolva această problemă prin divizare tabelul 1 în tabele separate. Să continuăm cu prima rezolvare a problemei de repetare pe coloane.
Așa cum am menționat mai sus, coloanele "username" și "following_username" din tabelul 1 sunt repetitive. Această repetare a avut loc deoarece am încercat să exprim relația dintre utilizatori. Să ne îmbunătățim tabelul 1de proiectare prin împărțirea în două mese: unul doar pentru următoarele relații și unul pentru restul de informații.
Fig. 2
Deoarece @Brett_Englebert urmează @RealSkipBayless, ca urmare a tabela va exprima acea relație prin stocarea lui @Brett_Englebert ca "from_user" și @RealSkipBayless ca "to_user". Să mergem mai departe și să ne despărțim tabelul 1 în aceste două tabele:
Tabelul 2: The ca urmare a masa
| FROM_USER | to_user |
|---|---|
| _DreamLead | Scootmedia |
| _DreamLead | MetiersInternet |
| GunnarSvalander | Klout |
| GunnarSvalander | Zillow |
| GEsoftware | DayJobDoc |
| GEsoftware | byosko |
| adrianburch | Cindy Crawford |
| adrianburch | Arjantim |
| AndyRyder | MichaelDell |
| AndyRyder | Yahoo |
| Brett_Englebert | RealSkipBayless |
| Brett_Englebert | stephenasmith |
| NimbusData | dellock6 |
| NimbusData | rohitkilam |
| SSWUGorg | drsql |
| SSWUGorg | steam_games |
Tabelul 3: The utilizatori masa
| Numele complet | nume de utilizator | text | creat la |
|---|---|---|---|
| "Boris Hadjur" | "_DreamLead" | "Ce credeți despre #emailing #campaigns #traffic in #USA? Este o piață bună în zilele noastre? Aveți #database?" | "Tue, 12 Feb 2013 08:43:09 +0000" |
| "Gunnar Svalander" | "GunnarSvalander" | "Bill Gates discută despre bazele de date, software-ul gratuit pe Reddit http://t.co/ShX4hZlA #billgates #databases" | "Tue, 12 Feb 2013 07:31:06 +0000" |
| "GE Software" | "GEsoftware" | "RT @KirkDBorne: lecturi în #Databases: lista excelentă de citire, multe categorii: http://t.co/S6RBUNxq via @rxin Fascinant." | "Tue, 12 Feb 2013 07:30:24 +0000" |
| "Adrian Burch" | "Adrianburch" | "RT @tisakovich: @NimbusData la conferința @Barclays Big Data din San Francisco astăzi, vorbind #virtualization, #databases și #flash memory." | "Tue, 12 Feb 2013 06:58:22 +0000" |
| "Andy Ryder" | "AndyRyder5" | "http://t.co/D3KOJIvF articol despre Madden 2013 folosind AI pentru a prodict bolul super #databases # bus311" | "Tue, 12 Feb 2013 05:29:41 +0000" |
| "Andy Ryder" | "AndyRyder5" | "http://t.co/rBhBXjma un articol despre setările de confidențialitate și facebook #databases # bus311" | "Tue, 12 Feb 2013 05:24:17 +0000" |
| "Brett Englebert" | "Brett_Englebert" | "# BUS311 NCFPD din Universitatea din Minnesota creează #database pentru a preveni" frauda alimentară ". Http://t.co/0LsAbKqJ" | "Tue, 12 Feb 2013 01:49:19 +0000" |
| Brett Englebert | "Brett_Englebert" | "# Companiile BUS311 s-ar putea să-și protejeze #datele de producție, dar cum ar fi fișierele lor de rezervă? Http://t.co/okJjV3Bm" | "Tue, 12 Feb 2013 01:31:52 +0000" |
| "Nimbus Data Systems" | "NimbusData" | "@NimbusData CEO @tisakovich @BarclaysOnline Big Data conferință în San Francisco astăzi, vorbind #virtualization, # baze de date, & # flash memory" | "Mon, 11 Feb 2013 23:15:05 +0000" |
| "SSWUG.ORG" | "SSWUGorg" | "Nu uitați să vă înscrieți pentru expoziția noastră GRATUITă de vineri: #Databases, #BI și #Sharepoint: Ce trebuie să știți! Http://t.co/Ijrqrz29" | "Mon, 11 Feb 2013 22:15:37 +0000" |
Acest lucru arată mai bine. Acum în utilizatori masa (Tabelul 3), există o singură coloană cu mânere Twitter. În ca urmare a masa (masa 2), este doar un singur mâner Twitter pentru fiecare câmp din coloana "to_user".
Edgar F. Codd, om de știință informatică care a stabilit baza teoretică a bazelor de date relaționale, a numit această etapă de eliminare a datelor repetitive pe coloane, prima formă normală (1NF).
Acum, că am repetat repetări pe coloane, trebuie să reparăm repetări pe rânduri. Întrucât utilizatorii @ AndyRyder5 și @Brett_Englebert fiecare tweeted de două ori, informațiile lor sunt duplicate în utilizatori masa (Tabelul 3). Acest lucru indică faptul că trebuie să scoatem tweets-ul și să-i punem în masă.
Figura 3
Ca și înainte, "textul" stochează tweetul însuși. Din moment ce coloana "created_at" stochează timestampul tweet-ului, este logic să-l trageți și în această masă. De asemenea, includ o referință la coloana "nume de utilizator", astfel încât să știm cine a publicat tweet-ul. Iată rezultatul plasării tweets în propria lor masă:
Tabelul 4: The tweeturi masa
| text | creat la | nume de utilizator |
|---|---|---|
| "Ce credeți despre #emailing #campaigns #traffic in #USA? Este o piață bună în zilele noastre? Aveți #database?" | "Tue, 12 Feb 2013 08:43:09 +0000" | "_DreamLead" |
| "Bill Gates discută despre bazele de date, software-ul gratuit pe Reddit http://t.co/ShX4hZlA #billgates #databases" | "Tue, 12 Feb 2013 07:31:06 +0000" | "GunnarSvalander" |
| "RT @KirkDBorne: lecturi în #Databases: lista excelentă de citire, multe categorii: http://t.co/S6RBUNxq via @rxin Fascinant." | "Tue, 12 Feb 2013 07:30:24 +0000" | "GEsoftware" |
| "RT @tisakovich: @NimbusData la conferința @Barclays Big Data din San Francisco astăzi, vorbind #virtualization, #databases și #flash memory." | "Tue, 12 Feb 2013 06:58:22 +0000" | "Adrianburch" |
| "http://t.co/D3KOJIvF articol despre Madden 2013 folosind AI pentru a prodict bolul super #databases # bus311" | "Tue, 12 Feb 2013 05:29:41 +0000" | "AndyRyder5" |
| "http://t.co/rBhBXjma un articol despre setările de confidențialitate și facebook #databases # bus311" | "Tue, 12 Feb 2013 05:24:17 +0000" | "AndyRyder5" |
| "# BUS311 NCFPD din Universitatea din Minnesota creează #database pentru a preveni" frauda alimentară ". Http://t.co/0LsAbKqJ" | "Tue, 12 Feb 2013 01:49:19 +0000" | "Brett_Englebert" |
| "# Companiile BUS311 s-ar putea să-și protejeze #datele de producție, dar cum ar fi fișierele lor de rezervă? Http://t.co/okJjV3Bm" | "Tue, 12 Feb 2013 01:31:52 +0000" | "Brett_Englebert" |
| "@NimbusData CEO @tisakovich @BarclaysOnline Big Data conferință în San Francisco astăzi, vorbind #virtualization, # baze de date, & # flash memory" | "Mon, 11 Feb 2013 23:15:05 +0000" | "NimbusData" |
| "Nu uitați să vă înscrieți pentru expoziția noastră GRATUITă de vineri: #Databases, #BI și #Sharepoint: Ce trebuie să știți! Http://t.co/Ijrqrz29" | "Mon, 11 Feb 2013 22:15:37 +0000" | "SSWUGorg" |
Tabelul 5: utilizatori masa
| Numele complet | nume de utilizator |
|---|---|
| "Boris Hadjur" | "_DreamLead" |
| "Gunnar Svalander" | "GunnarSvalander" |
| "GE Software" | "GEsoftware" |
| "Adrian Burch" | "Adrianburch" |
| "Andy Ryder" | "AndyRyder5" |
| "Brett Englebert" | "Brett_Englebert" |
| "Nimbus Data Systems" | "NimbusData" |
| "SSWUG.ORG" | "SSWUGorg" |
După divizare, utilizatori masa (Tabelul 5) are rânduri unice pentru utilizatori și mâinile lor Twitter.
Edgar F. Codd a numit acest pas de eliminare a datelor repetitive pe rânduri a doua formă normală (1NF).
Datele pot fi inserate, preluate, actualizate și șterse dintr-un tabel.
Pana acum, tabelul 1 a fost împărțită în trei tabele noi: ca urmare a (masa 2), tweeturi (Tabelul 4), și utilizatori (Tabelul 5). Dar cum este util acest lucru? Datele repetitive au fost eliminate, dar acum datele sunt împărțite în trei tabele independente. Pentru a prelua datele, trebuie să trasăm legături semnificative între tabele. În acest fel, putem exprima interogări precum: "ce a făcut un utilizator tweeted și care este următorul utilizator".
Modul de a desena legături între tabele este să dați mai întâi fiecărui rând dintr-un tabel un identificator unic, numit o cheie primară, și apoi să menționați cheia primară din celălalt tabel căruia doriți să-l legați.
De fapt am făcut deja asta utilizatori (Tabelul 5) și tweeturi (Tabelul 4). În utilizatori, cheia primară este coloana "nume de utilizator", deoarece nici doi utilizatori nu vor avea același handle Twitter. În tweeturi, menționăm această cheie în coloana "nume de utilizator", astfel încât să știm cine a tweeted ce. Deoarece este o referință, coloana "nume de utilizator" din tweeturi se numește o cheie străină. În acest fel, cheia "nume de utilizator" leagă utilizatori și tweeturi mese împreună.
Coloana "nume de utilizator" este cea mai bună idee pentru o cheie primară pentru utilizatori masa?
Pe de o parte, este o cheie naturală - este logic să căutați utilizând un mâner Twitter în loc să asociați fiecărui utilizator un ID numeric și să căutați pe acesta. Pe de altă parte, ce se întâmplă dacă un utilizator dorește să schimbe mânerul lui Twitter? Aceasta ar putea duce la erori în cazul în care cheia primară și toate cheile de referință străine nu sunt actualizate cu exactitate, erori care ar putea fi evitate dacă s-ar utiliza un cod numeric constant. În cele din urmă, alegerea depinde de sistemul dvs. Dacă doriți să oferiți utilizatorilor posibilitatea de a-și schimba numele de utilizator, este mai bine să adăugați o coloană numerică "id" cu creștere incrementală utilizatori și să o utilizați ca cheia primară. În caz contrar, "numele de utilizator" ar trebui să facă bine. Voi continua să folosesc numele de utilizator ca cheie primară pentru utilizatori
Să mergem mai departe tweeturi (Tabelul 4). O cheie primară trebuie să identifice în mod unic fiecare rând, deci ce ar trebui să fie cheia primară aici? Câmpul "create_at" nu va funcționa, deoarece dacă doi utilizatori tweet exact în același timp, tweeturile lor ar avea o marcă de timp identică. "Textul" are aceeași problemă în faptul că, dacă doi utilizatori au răspuns la mesajul "Hello world", nu am putut face distincție între rânduri. Coloana "nume de utilizator" este cheia externă care definește legătura cu utilizatori așa că nu trebuie să ne amestecăm cu asta. Din moment ce celelalte coloane nu sunt candidați buni, este logic să adăugăm o coloană numerică "id" și să o folosim ca cheie primară.
Tabelul 6: The tweeturi tabel cu o coloană "id"
| id | text | creat la | nume de utilizator |
|---|---|---|---|
| 1 | "Ce credeți despre #emailing #campaigns #traffic in #USA? Este o piață bună în zilele noastre? Aveți #database?" | "Tue, 12 Feb 2013 08:43:09 +0000" | "_DreamLead" |
| 2 | "Bill Gates discută despre bazele de date, software-ul gratuit pe Reddit http://t.co/ShX4hZlA #billgates #databases" | "Tue, 12 Feb 2013 07:31:06 +0000" | "GunnarSvalander" |
| 3 | "RT @KirkDBorne: lecturi în #Databases: lista excelentă de citire, multe categorii: http://t.co/S6RBUNxq via @rxin Fascinant." | "Tue, 12 Feb 2013 07:30:24 +0000" | "GEsoftware" |
| 4 | "RT @tisakovich: @NimbusData la conferința @Barclays Big Data din San Francisco astăzi, vorbind #virtualization, #databases și #flash memory." | "Tue, 12 Feb 2013 06:58:22 +0000" | "Adrianburch" |
| 5 | "http://t.co/D3KOJIvF articol despre Madden 2013 folosind AI pentru a prodict bolul super #databases # bus311" | "Tue, 12 Feb 2013 05:29:41 +0000" | "AndyRyder5" |
| 6 | "http://t.co/rBhBXjma un articol despre setările de confidențialitate și facebook #databases # bus311" | "Tue, 12 Feb 2013 05:24:17 +0000" | "AndyRyder5" |
| 7 | "# BUS311 NCFPD din Universitatea din Minnesota creează #database pentru a preveni" frauda alimentară ". Http://t.co/0LsAbKqJ" | "Tue, 12 Feb 2013 01:49:19 +0000" | "Brett_Englebert" |
| 8 | "# Companiile BUS311 s-ar putea să-și protejeze #datele de producție, dar cum ar fi fișierele lor de rezervă? Http://t.co/okJjV3Bm" | "Tue, 12 Feb 2013 01:31:52 +0000" | "Brett_Englebert" |
| 9 | "@NimbusData CEO @tisakovich @BarclaysOnline Big Data conferință în San Francisco astăzi, vorbind #virtualization, # baze de date, & # flash memory" | "Mon, 11 Feb 2013 23:15:05 +0000" | "NimbusData" |
| 10 | "Nu uitați să vă înscrieți pentru expoziția noastră GRATUITă de vineri: #Databases, #BI și #Sharepoint: Ce trebuie să știți! Http://t.co/Ijrqrz29" | "Mon, 11 Feb 2013 22:15:37 +0000" | "SSWUGorg" |
În final, să adăugăm o cheie primară la ca urmare a masa. În acest tabel, nici coloana "din_user", nici coloana "to_user" nu identifică în mod unic fiecare rând pe cont propriu. Cu toate acestea, "from_user" și "to_user" fac împreună, deoarece reprezintă o singură relație. O cheie primară poate fi definită pe mai multe coloane, deci vom folosi ambele aceste coloane drept cheie primară pentru ca urmare a masa.
În ceea ce privește cheia externă, "from_user" și "to_user" sunt fiecare chei străine, deoarece pot fi folosite pentru a defini o legătură cu utilizatori masa. Dacă vom căuta un mâner Twitter pe coloana "from_user", vom primi toți utilizatorii pe care îi urmează. În mod corespunzător, dacă vom căuta un handle Twitter pe coloana "to_user", vom primi toți utilizatorii care îl urmează.
Am realizat multe până acum. Am eliminat repetițiile între coloane și rânduri, separând datele în trei tabele diferite, apoi am ales cheile primare semnificative pentru a conecta tabelele împreună. Acest întreg proces se numește normalizare, iar rezultatele sale sunt date care sunt organizate în mod clar în conformitate cu modelul relațional. Consecința acestei organizații este că rândurile vor apărea în baza de date numai o singură mișcare înainte, ceea ce va face operațiunile CRUD mai ușoare.
Figura 4 diagrame schema bazei de date finalizate. Cele trei tabele sunt conectate împreună, iar tastele principale sunt evidențiate.
Figura 4
Există mici variații în SQL între fiecare furnizor RDBMS, numit dialecte SQL.
Acum, că știm cum să proiectăm o bază de date relațională, cum să implementăm una? Sistemele de gestionare a bazelor de date relaționale (RDBMS) sunt software care vă permit să creați și să utilizați baze de date relaționale. Există mai mulți furnizori comerciali și cu sursă deschisă de a alege de la. În ceea ce privește partea comercială, Oracle Database, IBM DB2 și Microsoft SQL Server sunt trei soluții bine cunoscute. Pe partea liberă și deschisă, MySQL, SQLite și PostgreSQL sunt trei soluții utilizate pe scară largă.
MySQL este folosit la aproape orice companie de Internet pe care ați auzit-o. În contextul acestui articol, Twitter utilizează MySQL pentru a stoca tweeturile utilizatorilor lor.
SQLite este comună în sistemele încorporate. iOS și Android permite dezvoltatorilor să utilizeze SQLite pentru a gestiona baza de date privată a aplicației. Google Chrome utilizează SQLite pentru a stoca istoricul navigării, cookie-urile și miniaturile dvs. pe pagina "Cele mai vizitate".
PostgreSQL este, de asemenea, un RDBMS utilizat pe scară largă. Extensia sa PostGIS suplimentează PostgreSQL cu funcții geospațiale care o fac utilă pentru cartografierea aplicațiilor. Un utilizator notabil al PostgreSQL este OpenStreetMap.
După ce ați descărcat și ați configurat un sistem RDBMS în sistemul dvs., următorul pas este să creați o bază de date și tabele în interiorul acestuia pentru a introduce și gestiona datele dvs. relaționale. Modul în care faceți acest lucru este cu limbajul structurat de interogări (SQL), care este limba standard pentru lucrul cu RDBMS.
Iată o scurtă trecere în revistă a instrucțiunilor SQL comune care sunt relevante pentru exemplul datelor de pe Twitter de mai sus. Vă recomandăm să consultați Cookbook-ul SQL pentru o listă mai completă de cereri SQL.
CREATE DATABASE development;
CREATE TABLE utilizatori (full_name VARCHAR (100), numele de utilizator VARCHAR (100));
RDBMSs necesită ca fiecare coloană dintr-un tabel să aibă un tip de date. Aici am atribuit coloanelor "full_name" și "username" tipul de date VARCHAR care este un șir care poate varia în lățime. Am stabilit în mod arbitrar o lungime maximă de 100. O listă completă a tipurilor de date poate fi găsită aici.
Accentsconagua
INTRODUCEȚI ÎN UTILIZATORI (full_name, username) VALUES ("Boris Hadjur", "_DreamLead"); SELECT text, created_at FROM tweets WHERE username = "_ DreamLead";
Utilizatorii UPDATE SET full_name = "Boris H" WHERE username = "_ DreamLead";
Șterge de la utilizatori WHERE username = "_ DreamLead";
SQL este destul de similar cu propozițiile regulate în limba engleză. Există mici variații în SQL între fiecare furnizor RDBMS, numit dialecte SQL, dar diferențele nu sunt destul de dramatice încât nu puteți transfera cu ușurință cunoștințele SQL de la unul la altul.
În acest articol, am învățat cum să proiectăm o bază de date relațională. Am luat o colecție de date și l-am organizat în mese conexe. De asemenea, am analizat pe scurt soluțiile RDBMS și SQL. Deci, începeți prin descărcarea unui RDBMS și normalizarea unor date într-o bază de date relațională astăzi.
Previzualizați imaginea: FindIcons.com/Barry Mieny
