Home » Articole » RO » Calculatoare » Baze de date » Structured Query Language (SQL)

Structured Query Language (SQL)

postat în: Baze de date 0

Convenții

Elementele limbajului SQL nu disting simbolurile majuscule și minuscule, de exemplu, nu are nicio diferență dacă scrieți SELECT …, Select …, select … sau orice combinație de caractere majuscule și minuscule, cum ar fi SeLecT. Din motive de lizibilitate, se folosește convenția conform căreia toate cuvintele cheie lingvistice sunt scrise cu litere mari și toate numele obiectelor utilizatorului, de exemplu, numele tabelelor și coloanelor, sunt scrise cu litere mici.

Vom scrie comenzi SQL scurte într-un singur rând.

SELECT street FROM address WHERE city = 'Duckburg';

Pentru comenzi mai lungi care generează mai multe linii, utilizăm un format tabelar.

SELECT street
FROM   address
WHERE  city IN ('Duckburg', 'Gotham City', 'Hobbs Lane');

Sfat: stocarea și recuperarea unor date text ar putea fi sensibile la majuscule și minuscule! Dacă stocați un nume de oraș „Duckburg”, nu îl puteți prelua ca „duckburg” – dacă nu utilizați o funcție pentru conversia de majuscule.

Sisteme de gestionare a bazelor de date (SGBD)

Context istoric

Unul dintre domeniile inițiale ale aplicațiilor pentru computer a fost stocarea unor cantități mari de date pe dispozitive de stocare în masă și preluarea acestora într-un moment ulterior. De-a lungul timpului, cerințele utilizatorilor au crescut pentru a include nu numai accesul secvențial, ci și accesul aleatoriu la înregistrările de date, accesul simultan prin procese paralele (scriere), recuperarea după eșecuri hardware și software, performanțe ridicate, scalabilitate etc. În anii 1970 și 1980, știința și industriile de calculatoare au dezvoltat tehnici pentru a îndeplini aceste cereri.

Ce constituie un sistem de gestionare a bazelor de date?

Cărămizile de bază pentru stocarea eficientă a datelor – și, din acest motiv, pentru toate sistemele de gestionare a bazelor de date (SGBD – în engleză: Database Management Systems, DBMS) – sunt implementări de algoritmi de citire și scriere rapidă a datelor situate în memoria centrală și dispozitive de stocare în masă, cum ar fi rutinele pentru arborii B, metoda de acces secvențial index (Index Sequential Access Method – ISAM), alte tehnici de indexare, precum și tamponarea blocurilor. Acești algoritmi nu sunt unici pentru SGBD. Acestea se aplică și sistemelor de fișiere, unor limbaje de programare, sistemelor de operare, serverelor de aplicații și multe altele.

Pe lângă însușirea acestor rutine, un SGBD garantează conformitatea cu paradigma ACID. Această conformitate înseamnă că într-un mediu de multi-utilizatori toate modificările aduse datelor dintr-o singură tranzacție sunt:

  • Atomice: toate modificările au loc sau niciuna.
  • Coerente: modificările transformă baza de date dintr-o stare validă în altă stare validă.
  • Izolate: tranzacțiile diferiților utilizatori care lucrează în același timp nu se vor afecta reciproc.
  • Durabile: baza de date reține modificările angajate chiar dacă sistemul se blochează ulterior.

Clasificarea proiectării SGBD

Se poate face o distincție între următoarele generații de proiectare și implementare SGBD:

  • SGBD ierarhic: Structurile de date sunt proiectate într-un model ierarhic părinte / copil în care fiecare copil are exact un părinte (cu excepția structurii rădăcină, care nu are părinte). Rezultatul este că datele sunt modelate și stocate ca un arbore. Rândurile copil sunt stocate fizic direct după rândul părinte proprietar. Deci, nu este necesar să stocați ID-ul părintelui sau ceva de genul acesta în rândul copil (XML realizează o abordare similară). Dacă o aplicație procesează datele exact în acest mod ierarhic, aceasta este rapidă și eficientă. Dar dacă este necesar să procesați datele într-o secvență care se abate de la această ordine, accesul este mai puțin eficient. Mai mult, SGBD-urile ierarhice nu oferă modelarea relațiilor n:m. O altă problemă este că nu există nicio posibilitate de a naviga direct la datele stocate la niveluri inferioare. Mai întâi trebuie să navigați peste ierarhia dată înainte de a ajunge la acele date.Cel mai cunoscut SGBD ierarhic este IMS de la IBM.
  • SGBD de rețea: modelul de rețea proiectează structurile de date ca o rețea complexă cu legături de la unul sau mai multe noduri părinte la unul sau mai multe noduri copil. Chiar și ciclurile sunt posibile. Nu este nevoie de un singur nod rădăcină. În general, termenii nod părinte și nod copil își pierd sensul ierarhic și pot fi denumiți sursă de legătură și destinație de legătură. Deoarece aceste legături sunt realizate ca legături fizice în baza de date, aplicațiile care urmează legăturile arată performanțe bune.
  • SGBD relațional: modelul relațional proiectează structuri de date ca relații (tabele) cu atribute (coloane) și relația dintre acele relații. Definițiile din acest model sunt exprimate într-un mod pur declarativ, nedeterminând probleme de implementare, cum ar fi legăturile dintr-o relație în alta sau o anumită secvență de rânduri din baza de date. Relațiile se bazează exclusiv pe conținut. La executare, toate legăturile și asocierile se fac prin evaluarea valorilor reale ale datelor, de exemplu: ...
    WHERE employee.department_id = department.id ...
    .. Consecința este că – cu excepția cheilor străine explicite – nu există nicio semnificație a unui denotația părinte / copil sau proprietar / membru. Relațiile din acest model nu au nicio direcție.Modelul relațional și SQL se bazează pe teoria matematică a algebrei relaționale.
    În anii 1980 și 1990, SGBD proprietare și open-source bazate pe paradigma de design relațional s-au stabilit ca lideri de piață.
  • SGBD orientat pe obiecte: în zilele noastre, majoritatea aplicațiilor sunt scrise într-un limbaj de programare orientat pe obiecte (POO – în engleză: object-oriented programming, OOP). Dacă, în astfel de cazuri, SGBD subiacent aparține clasei SGBD relaționale, apare așa-numita nepotrivire a impedanței relațional-obiect. Adică, spre deosebire de limbajul aplicației, SGBD relațional pur (prDBMS) nu acceptă concepte centrale ale OOP:
    • Sistem de tip: OOP-urile nu cunosc doar tipurile de date primitive. Ca un concept central al limbajului lor, ele oferă facilitatea de a defini clase cu structuri interne complexe. Clasele sunt construite pe tipuri primitive, clase de sistem, referințe la altele sau la aceeași clasă. prDBMS cunoaște doar tipurile predefinite. PrDBMS secundar insistă în prima formă normală, ceea ce înseamnă că atributele trebuie să fie scalare. În OOP pot fi seturi, liste sau tablouri de tipul dorit.
    • Moștenire: clasele de OOP pot moșteni atribute și metode din superclasa lor. PrDBMS nu cunoaște acest concept.
    • Polimorfism: sistemul de executare poate decide prin legarea târzie care dintre grupurile de metode cu același nume și tipuri de parametri va fi numit. Acest concept nu este cunoscut de prDBMS.
    • Încapsulare: datele și metodele de acces la date sunt stocate în aceeași clasă. Nu este posibil să accesați datele direct – singura modalitate este utilizarea metodelor de acces ale clasei. PrDBMS nu cunoaște acest concept.

    SGBD orientate pe obiecte sunt concepute pentru a depăși decalajul dintre prDBMS și OOP. La vârf, au ajuns la o poziție slabă pe piață la mijlocul și sfârșitul anilor ’90. Ulterior, unele dintre conceptele lor au fost încorporate în standardul SQL, precum și în implementările rDBMS.

  • NoSQL: termenul NoSQL reprezintă grupul emergent de SGBD care diferă de atele în concepte centrale:
    • Nu susțin neapărat toate aspectele paradigmei ACID.
    • Datele nu trebuie să fie neapărat structurate conform oricărei scheme.
    • Scopul lor este de a sprijini toleranța la erori, datele distribuite și volumul vast, vezi și: teorema CAP.
    • Implementările diferă foarte mult în ceea ce privește tehnicile de stocare: puteți vedea depozite cheie-valoare, baze de date orientate spre documente, baze de date orientate spre grafice și multe altele.
    • Nu oferă o interfață SQL.
    • Câteva produse: MongoDB, Firebase Realtime Database (Google), Cloud Firestore (Google)
  • NewSQL: Această clasă de SGBD urmărește să ofere aceeași performanță scalabilă ca sistemele NoSQL, menținând în același timp paradigma ACID, modelul relațional și interfața SQL. Ele încearcă să atingă scalabilitatea evitând recuperarea greutăților sau controlul concurenței.

(Traducere din Wikibooks)

Etica Big Data în cercetare
Etica Big Data în cercetare

Principalele probleme cu care se confruntă oamenii de știință în lucrul cu seturile mari de date (Big Data), evidențiind principale aspecte etice, luând în considerare inclusiv legislația din Uniunea Europeană. După o scurtă Introducere despre Big Data, secțiunea Tehnologia prezintă … Citeşte mai mult

Nu a fost votat $0,00$2,35 Selectează opțiunile
PowerPoint - Ghid pentru începători
PowerPoint – Ghid pentru începători

PowerPoint este un instrument excelent pentru prezentări de orice fel, fie în clasă, fie în cadrul unei conferințe. O prezentare PowerPoint este formată dintr-o serie de diapozitive care pot fi proiectate (afișate electronic) sau tipărite într-o varietate de formate de … Citeşte mai mult

Nu a fost votat $0,00 Selectează opțiunile
Întreţinerea şi repararea calculatoarelor
Întreţinerea şi repararea calculatoarelor

Manual pentru începători pentru întreţinerea şi depanarea calculatoarelor, cu o introducere în noţiuni despre calculatoare, hardware, software (inclusiv sisteme de operare) şi securitatea pe Internet. Un calculator de uz general are patru componente principale: unitatea logică aritmetică (ALU), unitatea de … Citeşte mai mult

Nu a fost votat $3,99$8,99 Citește mai mult

Lasă un răspuns

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