Data K. Introducere în sistemele de baze de date - dosar n1.doc. Sisteme de management al bazelor de date

Connolly T., Begg K., Strachan A. Baze de date: proiectare, implementare și întreținere. Teorie și practică (document)

Garcia-Molina Hector, Ullman J., Widom J. Sisteme de baze de date. Curs complet (document)

Tokmakov G.P. Bază de date. Concept de bază de date, model de date relaționale, limbaje SQL și XML (Document)

n1.doc

Data K. Introducere în sistemele de baze de date. LA.; M.; St.Petersburg; Editura Casa Williams. 2000.
Model relațional (pp. 81-100)
ParteII

Model relațional

Bază tehnologie moderna bazele de date sunt, fără îndoială, un model relațional; tocmai acest fundament face din domeniul tehnologiei bazelor de date o știință. Prin urmare, orice descriere a acestei zone care nu include o descriere a modelului poate fi doar superficială. De asemenea, abilitățile sau experiența în acest domeniu nu pot fi considerate satisfăcătoare decât dacă cineva are o înțelegere profundă a model relațional. Să ne grăbim să adăugăm că nu vrem să spunem că acest material este greu de înțeles, este pur și simplu este bază.

După cum sa menționat în capitolul 3, modelul relațional ia în considerare trei aspecte ale datelor - structura date (obiecte date), integritate date și tratament date (operatori). Această parte a cărții acoperă fiecare dintre cele trei aspecte: Capitolul 4 discută obiecte, Capitolul 5 discută integritatea și Capitolele 6 și 7 discută operatori. (Ne-am dedicat ultimul subiect două capitole, deoarece partea operațională a modelului poate fi implementată în două moduri diferite, dar echivalente, cunoscute respectiv ca algebră relațională și calcul relațional) Scopul capitolului 8 va fi descris mai jos.

Cometariu. Este important de înțeles că modelul nu este static, s-a schimbat de-a lungul anilor și, desigur, continuă să se schimbe. Definițiile, descrierile și explicațiile din această carte reflectă opiniile actuale ale autorului și ale altora din domeniu. Cu toate acestea, trebuie remarcat faptul că, în timp ce mare parte din materialul discutat este într-adevăr „rocă solidă” (schimbările menționate mai sus sunt mai degrabă evolutive decât revoluționare), există încă zone de dezacord. Astfel de subiecte sunt notate în mod corespunzător în text.

După cum sa menționat mai sus, modelul relațional nu este foarte greu de înțeles. Dar este o teorie, iar majoritatea teoriilor vin cu propria terminologie tehnică, iar modelul relațional (din motivele prezentate în capitolul 3) nu face excepție.

capitolul 4

Obiecte de date relaționale: domenii și relații

4.1. Exemplu introductiv

După cum sa observat în capitolul 3, modelul relațional este împărțit în trei părți, care se ocupă de obiecte, integritateȘi operatori. Toate cele trei părți au propriile lor condiții speciale. Cei mai importanți termeni folosiți în partea „obiecte” (subiectul acestui capitol) sunt prezentați în Fig. 4.1. Ca exemplu, tabelul S este preluat din baza de date a furnizorilor și a pieselor. Este vorba despre termeni relație, tuplu, număr cardinal, atribut, grad, domeniuȘi cheia principala(ar trebui să fiți deja familiarizați cu macar cu termeni atitudineȘi cheia principala). Acum vom da explicație informală fiecare termen, iar în secțiunile ulterioare prezentăm definiții formale.

Deci, pe scurt:

■ Atitudine corespunde ceea ce am numit până acum un tabel.
■ Cortegiu corespunde unui rând din acest tabel și atribut- coloana. Se numește numărul de tupluri numar cardinal iar numărul de atribute este grad.
■ Cheia principala este un identificator unic pentru tabel, adică o coloană sau o combinație de coloane astfel încât la un moment dat să nu existe două rânduri care să conțină aceeași valoare în acea coloană sau combinație de coloane.
■ Și în sfârșit, domeniu este populația generală de valori din care sunt luate valorile reale pentru anumite atribute ale unei anumite relații. De exemplu, domeniul desemnat S# în Fig. 4.1 este setul tuturor valori acceptabile numerele furnizorilor, iar setul de valori S# în relația S în orice moment este un subset al acestui set. De asemenea, setul de valori ale lui S# în raport cu SP la un moment dat este un subset al acestui set.

În fig. 4.2 oferă o prezentare generală a acestor termeni. Această cifră necesită unele explicații.

1. Trebuie înțeles că „echivalențele” prezentate în figură sunt doar aproximative, întrucât termenii relaționali enumerați în stânga au definiții precise, în timp ce echivalentele informale din dreapta au doar definiții brute, nerigoare.

Prin urmare, de exemplu, o relație și un tabel nu sunt același lucru, deși în practică este adesea convenabil să presupunem că sunt. (Vom explica diferența exactă dintre o relație și un tabel mai târziu în acest capitol.)

2. Conceptul de domeniu ilustrează un punct important discutat în Capitolul 3 - Nu toate sistemele relaționale susțin pe deplin toate aspectele modelului relațional. De fapt, în capitolul 3 am dat descriere generala sisteme relaționale, fără a menționa deloc domenii.

De fapt, majoritatea sistemelor relaționale moderne nu suportă pe deplin domenii, în ciuda faptului că acestea sunt una dintre componentele fundamentale ale modelului relațional în ansamblu. Deci, amintiți-vă că următoarele capitole descriu numai model relațional; comportamentul sistemului relaţional este complet Nu trebuie să corespundă cu ceea ce este descris.

Acum să trecem la prezentarea oficială.

4.2. Domenii

Să luăm ca punct de plecare cea mai mică unitate semantică de date, care se presupune a fi o valoare separată a datelor (cum ar fi camera privata furnizor, greutatea individuală a piesei sau cantitatea individuală de piese furnizate). Vom numi astfel de valori scalari(deși acest termen este rar folosit în literatura relațională). Valorile scalare sunt „cea mai mică unitate semantică de date” în sensul că acestea atomic: y nu au nicio structură internă (adică sunt indecompuse) în modelul relațional și, prin urmare, atunci când sunt considerate într-un SGBD relațional. Acordați o atenție deosebită faptului că a nu avea structură internă atunci când este privit în modelul relațional nu înseamnă a nu avea deloc structură internă. De exemplu, numele unui oraș, desigur, are o structură internă (constă dintr-o succesiune de litere); totuși, scriind numele, vom pierde sensul. Semnificația va deveni clară numai dacă literele sunt puse împreună și în ordinea corectă.

Cometariu. Am observat în treacăt că conceptul de „atomicitate a valorilor scalare” este destul de vag. Cu toate acestea, discuții suplimentare despre această problemă sunt rezervate pentru capitolele ulterioare ale cărții; deocamdată vom presupune că acest concept este intuitiv.

Acum puteți defini un domeniu ca un set numit de valori scalare de același tip. De exemplu, domeniul numerelor furnizorilor este setul tuturor numere posibile furnizori; Domeniul cantității de părți de aprovizionare este mulțimea tuturor numerelor întregi mai mari decât zero și mai mici decât, să zicem, 10.000. Deci domeniile sunt seturi generale de valori, din care sunt luate valorile reale ale atributelor. Mai exact, fiecare atribut trebuie definit pe un singur domeniu (sau per domeniu); aceasta înseamnă că valorile atributului trebuie luate din acel domeniu. De exemplu, atributul număr de piesă pentru relația P și atributul de număr de piesă pentru relația SP sunt definite în domeniul numărului de piesă (deoarece aceste două atribute reprezintă în mod clar numerele de piesă). Cu alte cuvinte, în orice moment dat, fiecare valoare P# în raport cu P trebuie să fie o valoare din domeniul numărului de piese și același lucru este valabil și pentru o valoare P# în raport cu SP. Adică, în orice moment dat, setul de valori P# în raport cu P este un subset al setului de valori din domeniul numărului de piese și același lucru este valabil și pentru valoarea P# în raport cu SP .

Rețineți, apropo, că, de obicei, în orice moment, vor exista valori într-un domeniu care nu sunt valoarea niciunuia dintre atributele corespunzătoare acelui domeniu. De exemplu, dacă valoarea P8 este o valoare a piesei validă, atunci aceasta este inclusă în domeniul numărului de piese, chiar dacă nu există nicio parte P8 în relația noastră P din baza de date de exemplu furnizor și piese, de exemplu. V cel Momentan nu există un astfel de detaliu.

Comparații cu restricții de domeniu

Care este semnificația domeniilor? Unul dintre cele mai importante răspunsuri la această întrebare este acesta: domeniile limitează comparațiile. Să explicăm ce s-a spus. Luați în considerare două interogări SQL împotriva bazei de date furnizori și piese (rețineți că ambele interogări folosesc o îmbinare):

Una dintre aceste interogări, cea din stânga, poate avea sens, în timp ce cea din dreapta probabil că nu. Cum se știe asta? Din punct de vedere formal, răspunsul este că interogarea din stânga folosește o comparație între atributele P.P# și SP.P#, care (după cum sa menționat deja) sunt definite pe unuși același domeniu, în timp ce interogarea din dreapta folosește o comparație între atributele P.WEIGHT și SP.QTY, care sunt probabil definite pe diferite domenii. (Aici spunem „probabil” pentru că, deși greutatea și cantitatea sunt numere, sunt numere diferite „soiuri”. Nu are sens să comparăm greutatea și cantitatea. Prin urmare, domeniile greutate și cantitate trebuie să fie diferite.)

Prin urmare, conform raționamentului anterior, dacă valorile a două atribute sunt preluate din același domeniu, atunci comparațiile și, prin urmare, îmbinările, uniunile și multe alte operațiuni care utilizează astfel de două atribute, sunt de asemenea probabil să aibă sens, deoarece în Ele comparați atributul similar cu atributul similar. În schimb, dacă valorile a două atribute sunt din domenii diferite, atunci comparațiile și alte operațiuni probabil nu vor avea sens. Prin urmare, avantajul unui sistem de suport de domeniu este că un astfel de sistem poate preveni gafele. Vă rugăm să rețineți că aici este ușor de presupus eroare mecanică, de exemplu tastând S# în loc de P#. Dacă utilizatorul încearcă să efectueze o operație care utilizează compararea valorii domenii diferite, sistemul își va întrerupe funcționarea și va anunța utilizatorul despre o posibilă eroare. (Spunem „posibil” pentru că pot exista circumstanțe în care o astfel de comparație nu este o eroare. Dar mai multe despre asta în părțile ulterioare ale cărții.)

Apropo, trebuie remarcat faptul că, deși toate exemplele pe care le-am dat au fost exprimate în termeni de limbaj SQL, acest limbaj nu suportă de fapt domenii în sensul în care le oferim noi. Ambele interogări de mai sus sunt valide în SQL. Cu toate acestea, cel de-al doilea, desigur, va da un răspuns fără sens.

Definirea datelor

O problemă care poate să nu fie încă clară pentru cititor este aceea că domeniile sunt în primul rând de natură conceptuală. Acestea pot sau nu să fie stocate în mod explicit în baza de date ca seturi reale de valori; de fapt, în majoritatea cazurilor acestea nu sunt salvate. Dar acestea ar trebui cel puțin definite în definițiile bazei de date (adică într-un sistem care susține pe deplin conceptul de domeniu; dar, după cum s-a menționat, majoritatea produselor de astăzi nu oferă un astfel de suport); și apoi fiecare definiție de atribut trebuie să includă o referință la domeniul corespunzător, astfel încât sistemul să știe ce atribute pot fi comparate și care nu.

Acum, pentru a concretiza ideile modelului relațional (atât în această secțiune, cât și în întreaga secțiune), vom folosi un limbaj relațional ipotetic pentru a ilustra aceste idei. Operatorii lingvistici vor fi introduși treptat pe măsură ce prezentarea progresează. Este clar că în primul rând avem nevoie de o modalitate de a crea un nou domeniu:

CREAȚI DOMENIU domeniu tip de date ;

Aici domeniu este numele noului domeniu, a date- tip se potrivește cu un tip de date precum CHAR( n) sau NUMERIC( n). Cometariu. Mai târziu în carte vom discuta câteva componente suplimentare Declarații CREATE DOMAIN care nu sunt afișate mai sus.

În fig. Figura 4.3 (aceeași figură prezentată în Capitolul 3) arată modul în care acest limbaj poate fi utilizat pentru a defini o bază de date de furnizori și piese. Rețineți că acest exemplu utilizează instrucțiuni CREATE BASE RELATION în plus față de instrucțiunile CREATE DOMAIN. Pentru a descrie pe deplin declarația aici, vom observa doar că fiecare definiție de atribut din instrucțiunea CREATE BASE RELATION include o referință la domeniul corespunzător.

Când creați un domeniu nou utilizând instrucțiunea CREATE DOMAIN, DBMS creează o intrare de director care descrie noul domeniu. (Pentru a vă aminti ce este un director, priviți înapoi la Capitolul 3.) În mod similar, atunci când creați o nouă relație folosind instrucțiunea CREATE BASE RELATION, DBMS creează o intrare de director care descrie noua relație.

O notă despre nume. Pentru a fi concret, vom presupune următoarele restricții cu privire la nume:

■ Domeniile au nume unice în baza de date.
■ Relațiile cu nume au nume unice în baza de date.
■ Atributele au nume unice în relația lor de conținut (chiar dacă relația de conținut Nu numit!).

În general, un atribut poate avea fie un nume care se potrivește cu numele domeniului corespunzător, fie un nume diferit de acesta. Evident, pentru a evita ambiguitatea, ar trebui să folosiți nume diferite (în special dacă două atribute din aceeași relație se bazează pe același domeniu). Cu toate acestea, în general, este de dorit să se numească atribute cu același nume ca și domeniul de bază, sau cel puțin să le denumim astfel încât, de exemplu, numele atributului să conțină o parte cheie a numelui de domeniu. Urmăm această instrucțiune în exemplul din fig. 4.3.

Opțional, puteți să urmați o altă convenție generală și să omiteți complet referința la domeniul de bază din definiția oricărui atribut care are același nume ca și domeniul. De exemplu, instrucțiunea CREATE BASE RELATION pentru o relație de bază S poate fi simplificată:

Eliminarea domeniilor.Știm deja cum să creăm un domeniu nou. De asemenea, ar trebui să fie posibilă ștergerea domeniul existent daca nu mai avem nevoie:

DISTROY DOMAIN domeniul ;

Aici domeniu- acesta este numele domeniului care trebuie șters. Această operațiune elimină intrarea de director care descrie domeniul, făcând domeniul necunoscut de sistem. (Până la o notificare ulterioară, vom presupune că operațiunea DISTRUGERE DOMENIUL pur și simplu nu va fi efectuată dacă orice relație subiacentă la acel moment încă include un atribut care este definit pe domeniul specificat.)

Interogări bazate pe domenii. Iată un alt exemplu semnificație practică domenii. Luați în considerare o interogare care este formulată astfel:

„Care relații din baza de date conțin informații relevante pentru furnizori?”

Această întrebare poate fi formulată mai precis:

„Ce relații din baza de date includ un atribut care este definit pe domeniul furnizorului?”

Într-un sistem care acceptă conceptul de domeniu, o astfel de solicitare, după cum vedem, se traduce într-o simplă solicitare către director. Pe un sistem care nu acceptă domenii, evident că nu este posibil să interoghezi directorul pentru domenii. Puteți contacta doar prin atribute. O interogare de atribut va atinge acest obiectiv numai dacă designerul bazei de date urmează liniile directoare de denumire de mai sus (cu alte cuvinte, dacă menține ordinea domeniilor în baza de date).

Domenii și tipuri de date

Includerea acestei secțiuni se datorează faptului că mulți cititori sunt deja destul de pregătiți să înțeleagă următoarele: un domeniu este de fapt nimic mai mult sau mai puțin decât tip de date(după cum se înțelege în limbile moderne programare). De exemplu, în limbă Programare Pascal Sunt permise următoarele expresii:

Aici avem tip definit de utilizator numită „Ziua” (având exact șapte valori valide) și o variabilă numită „Azi” aparținând acelui tip de date (și, prin urmare, limitată la acele șapte valori). Evident, această situație este complet analogă cu situația dintr-o bază de date relațională, atunci când avem domeniu, numită „Ziua” și atribut, Mai mult, există limbaje de programare, cum ar fi SIMULA 67, MODULA-2 sau Ada (cu toate acestea, Pascal nu este unul dintre ele), care suportă unele sau chiar toate funcțiile atribuite de obicei domeniilor în modelul relațional. .

Având în vedere că un domeniu este practic doar un tip de date, ar fi incorect să spunem că SGBD-urile nu acceptă deloc domenii. În realitate, sistemele suportă domenii într-un sens foarte primitiv, la fel cum oferă anumite încorporate (adică definite de sistem) tipuri primitive date precum tipul întreg sau tip virgulă mobilă. Dar, dacă vorbim despre suport de domeniu în contextul sistemelor relaționale, ne referim la ceva mai mult decât un astfel de suport primitiv, și anume, că sistemul trebuie să ofere utilizatorului capacitatea de a-și crea propriul, mai mult. tipuri complexe date precum „numerele furnizorului”, „numerele piesei”, „numele orașelor”, „culorile”, etc. și oferă toate capabilitățile pentru a lucra cu aceste tipuri.

Ce include Aveți capacitatea de a lucra cu aceste tipuri? Desigur, acestea nu sunt doar comparațiile limitate de domenii descrise mai sus. De fapt, conceptul de domeniu este mult mai complex decât ar părea la prima vedere (de aceea mulți sisteme moderneși nu-l susțin). Cu toate acestea, din cauza volumului mare de material, nu vom atinge consecințele ulterioare de ceva timp. Prin urmare, deocamdată vom presupune că suportul de domeniu înseamnă un singur lucru: dacă două valori scalare pot fi comparate, atunci acestea aparțin aceluiași domeniu. Trebuie înțeles că aceasta este o simplificare foarte semnificativă și am recurs la ea pentru a simplifica prezentarea generală. Această problemă este discutată în continuare în părțile ulterioare ale cărții.

4.3. Relaţie

Acum să încercăm să aflăm exact ce este „atitudinea”. De la început, trebuie remarcat faptul că din punct de vedere istoric a existat o oarecare ambiguitate în jurul acestui concept relativ simplu (acest lucru se aplică și edițiilor anterioare ale cărții). Motivul constă în lipsa unei distincții clare între variabile relaţiile şi valorile relatii. Variabila de relatie- aceasta este o variabilă obișnuită, la fel ca în limbajele de programare, adică un obiect numit a cărui valoare se poate schimba în timp. Și valoarea acestei variabile va fi în orice moment sensul relatiei. De exemplu, folosind expresia

Este creată o variabilă de relație numită s a cărei valoare în orice moment va fi valoarea specifică a relației. 1

Deci, vă rugăm să rețineți că relație de bază(sau „tabel de bază”) nu este un termen complet exact; un termen mai precis, deși mai greoi, ar fi variabila relatie de baza. La urma urmei, dacă declarăm o variabilă QTY într-un limbaj de programare ca acesta:

Atunci nu vom numi această variabilă întreg, A variabilă de tip întreg.În realitate, numerele întregi sunt valorile această variabilă; cu alte cuvinte, termenul nepotrivit „întreg” este folosit pentru a desemna întregul sensuri. Prin urmare, în restul cărții, vom folosi termenul „variabilă relațională” atunci când va fi necesar să subliniem ceea ce ne referim. de fapt variabil; iar termenul nefericit „relație” va fi folosit în mod specific pentru a desemna sensul relației. În special, pentru concizie și simplitate, vom continua să folosim termenul „relație de bază” mai des decât termenul „variabilă relație de bază” (când ar fi dificil să le confundăm pe cele două).

Valorile relațiilor

Iată definiția termenului „atitudine” (în mod specific sens relaţie):

■ AtitudineR, definite pe mai multe domenii D1, D2,..., Dn (nu neapărat diferit), conține două părți: titluȘi corp.(Dacă vă gândiți la o relație în termeni de tabel, capul este rândul de titluri de coloane, iar corpul este setul de rânduri de date.)

1. Titlu conține un set fix de atribute sau, mai precis, perechi:

{A1: D1>, A2: D2>, ..., A1: Dn> },

Mai mult, fiecare atribut Aj se potrivește cu unul și numai unul dintre domeniile de bază DJ (j= 1,2,..., n). Toate numele atributelor A1, A2,...,Un diferit.

2. Corp conţine multe tupluri. Fiecare tuplu, la rândul său, conține multe perechi:

{ , vi2>, ..., An: vin>}

(i = 1,2, ..., T, Unde T - numărul de tupluri din acest set). Fiecare astfel de tuplu conține o astfel de pereche, adică Aj: vij>, Pentru fiecare atribut Aj în titlu. Pentru orice astfel de pereche Aj: vij> vij este o valoare dintr-un domeniu unic DJ, care este asociat cu atributul Aj.

Valori TȘi P sunt numite în consecință numar cardinalȘi grad relaţie R.

Ca exemplu, să ne uităm la tabelul S din Fig. 4.1 (nu o numim în mod deliberat o relație deocamdată) pentru a verifica cum se potrivește acestei definiții.

■ În primul rând, există patru domenii principale în acest tabel, și anume domeniul numărul furnizorului (S#), domeniul numelui (NUME), domeniul valorii statutului (STATUS) și domeniul numelui orașului (ORAȘUL). (Când descriem o relație ca un tabel pe o bucată de hârtie, de obicei nu ne pasă să arătăm domeniile subiacente, dar trebuie să înțelegem că, cel puțin conceptual, ele sunt întotdeauna acolo.)
■ În plus, un tabel are în mod necesar două părți: un rând de titluri de coloană, precum și multe rânduri de date. Să ne uităm mai întâi la rândul antetului coloanei:

(S#, NUME, STATUS, ORAȘ)

Prima componentă a fiecărei perechi este numele atributului, a doua componentă este numele domeniului corespunzător. Prin urmare, putem fi de acord că rândul antetului coloanei reprezintă cu adevărat titlu.

Cometariu.În practică, capul relației este de obicei tratat pur și simplu ca un set de nume de atribute (adică numele de domenii sunt adesea omise), cu excepția cazurilor în care precizia este foarte importantă. Deși această practică poate fi puțin neglijentă, este convenabilă și o vom folosi des.

■ Cât despre restul tabelului, acesta este; desigur, un set de șiruri. Să ne concentrăm pe o singură linie, să spunem linia

Această linie reprezintă de fapt un set de perechi ordonate:

Prima componentă a fiecărei perechi este numele atributului, a doua componentă este valoarea atributului corespunzătoare. Adesea, numele atributelor sunt omise în descrierile informale deoarece se știe că fiecare valoare individuală dintr-un tabel este de fapt valoarea atributului al cărui nume apare în partea de sus a coloanei corespunzătoare; în plus, știm că valoarea aparține domeniului de bază al atributului. De exemplu, valoarea „S1” este valoarea atributului S# și este preluată din domeniul subiacent corespunzător, și anume domeniul numărul furnizorului (numit și S#). Astfel, putem fi de acord că fiecare linie reprezintă caravană conform definitiei.

Pe baza celor de mai sus, putem fi de acord că tabelul S din Fig. 4.1 poate fi văzut ca o reprezentare a unei relații în sensul unei definiții, Dacă am convenit cum să „citim” o astfel de imagine (de ex. dacă sunt unii dintre noi reguli de interpretare astfel de imagini). Cu alte cuvinte, trebuie să fim de acord că există câteva domenii subiacente; fiecare coloană corespunde doar unuia dintre aceste domenii; fiecare linie reprezintă un tuplu; fiecare valoare de atribut aparține domeniului corespunzător etc. Dacă am acceptat toate aceste „reguli de interpretare”, atunci si numai atunci putem spune că tabelul este o reprezentare acceptabilă a relației.

Acum putem spune că o relație și un tabel nu sunt într-adevăr același lucru (chiar dacă capitolele anterioare sugerau contrariul). Atitudine- acesta, în conformitate cu definiția dată mai devreme, este un tip de obiect destul de abstract și masa este o imagine concretă (de obicei pe hârtie) a acestui obiect abstract. Desigur, sunt foarte apropiați... și cel puțin în contexte informale sunt de obicei identificați. Dar când vrem să vorbim mai formal și mai precis (și acum, desigur, vrem să fim mai precisi), trebuie să recunoaștem că cele două concepte nu sunt tocmai identice.

(La urma urmei, același set de valori de relație poate fi prezentat nu sub forma unui tabel, ci, de exemplu, sub forma unei liste enumerate. De exemplu, Ivanov, Petrov și Sergeev lucrează în departamentul A și Grigoriev și Nikolaev lucrează în departamentul B. O astfel de enumerare nu este un tabel (cel puțin în acest context), deși aceste semnificații constituie o anumită relație între angajați și departamente. Notă ed.)

Cometariu. Dacă întâmpinați probleme în a înțelege unele dintre diferențele dintre o relație și un tabel, următoarele vă pot ajuta. În primul rând, unul dintre avantajele incontestabile ale modelului relațional este că obiectul său abstract de bază, (adică, o relație) are o reprezentare simplă pe hârtie (adică, o reprezentare pe tabel); Această viziune face sistemele relaționale ușor de utilizat și de înțeles și face comportamentul lor mai ușor de înțeles. Cu toate acestea, din păcate, vedere la masă sugerează unele fapte incorecte. De exemplu, se presupune în mod explicit că rândurile tabelului (adică tuplurile unei relații) sunt într-o anumită ordine de sus în jos, deși acest lucru nu este adevărat. Există o discuție suplimentară despre această problemă mai târziu în acest capitol.

Variabile de relație

În primul său articol, Codd a vorbit despre „schimbarea în timp” a relațiilor. Prin acest termen el a vrut să spună ceea ce am numit mai devreme în acest capitol variabile relații, adică variabile ale căror valori sunt relații (în general, relații diferite în momente diferite). De exemplu, după cum sa menționat deja, expresia

CREAȚI RELAȚIA DE BAZĂ S ... ;

Definește o variabilă numită s a cărei valoare în orice moment este, așa cum este definită mai sus, o relație. Totuși, această valoare „se modifică în timp” deoarece în timp vor fi introduse noi tupluri furnizori și/sau tupluri furnizori existente vor fi modificate sau eliminate (deci, în consecință, numărul cardinal se va „schimba și în timp”).

Cu toate acestea, „schimbarea în timp” nu este un termen foarte bun. La urma urmei, dacă un limbaj de programare folosește declarația de mai sus

DECLARE CANTITATE INTEGER ...;

Apoi vom numi variabila QTY nu un întreg „variabil în timp”, ci variabilă de tip întreg. Prin urmare, această carte va folosi termenul „variabilă relațională”; totuși, cititorul ar trebui să fie conștient de existența unui alt termen.

Acum lasa R - variabila relatie; variabil R va avea semnificații diferite în momente diferite. Cu toate acestea, toate valorile posibile ale variabilei R va avea aceleași anteturi. De exemplu, toate valorile posibile ale relației de bază S vor avea un antet (S#,SNAME,STATUS,CITY). 2

Și mai multe despre terminologie

După cum am explicat deja, numărul de atribute dintr-o relație dată este numit grad(uneori numit aritate) relație. Relația de gradul întâi se numește unar, o relație de gradul 2 este binară, o relație de gradul 3 este ternară... și o relație de grad p - p-ary.(În general, modelul relațional ia în considerare n relaţii -are, unde P este un întreg nenegativ arbitrar.) În baza de date furnizor și piese, relațiile S, P și SP au grade 4, 5 și, respectiv, 3.

Uneori, ambiguitatea apare din cauza asemănării conceptelor domeniuȘi relatie unara(la urma urmei, domeniul arată exact ca un tabel cu o singură coloană). Cu toate acestea, rețineți că există o diferență destul de semnificativă între aceste două concepte: domeniile sunt statice, A relațiile sunt dinamice(aici prin relație ne referim la variabil relaţie). Cu alte cuvinte, conținutul unei relații (variabile) se modifică în timp, dar conținutul unui domeniu nu se schimbă (amintim că un domeniu conține tot posibil valorile tip potrivit). Pentru o discuție mai detaliată a acestei probleme, a se vedea.

„Nu sunt domenii diferite”

Să revenim la definiție relaţie; Rețineți că domeniile de bază ale unei relații nu sunt neapărat distincte. Aceasta înseamnă că mai multe atribute dintr-o relație se pot baza pe același domeniu. Un exemplu de astfel de relație este prezentat în Fig. 4.4. (Această relație se numește PART_STRUCTURE.)

Dacă același domeniu este folosit de mai multe ori în aceeași relație, atunci, așa cum sa menționat mai devreme, nu puteți da tuturor atributelor același nume ca și domeniile subiacente. În fig. Figura 4.4 arată abordarea recomandată într-o astfel de situație: numiți atributele diferit, astfel încât aceste nume să aibă „rol” ca prefix. Nume atribut, iar ca sufix - numele domeniului. Într-adevăr, dacă suntem de acord să respectăm întotdeauna această regulă și, de asemenea, folosim întotdeauna aceleași caractere delimitare (de exemplu, caracterul de subliniere) pentru a separa numele rolului (dacă există unul) de numele domeniului, atunci nu vom avea niciodată nevoie o specificație explicită la definirea unui atribut „DOMAIN (domeniu)" (mai multe despre asta în secțiunea următoare).

Definirea datelor

Iată sintaxa instrucțiunii create relația de bază:

Când această instrucțiune este executată, o nouă relație de bază Cu nume baza- relație, precum și atributele specificate, potențialele și cheile externe. Relația este creată goală (adică nu conține tupluri). Veți găsi câteva exemple de utilizare a acestui operator în Fig. 4.3. Mai jos sunt câteva explicații ale operatorului.

1. Termeni listă(lista) și comalistă (listă separată prin virgulă) este convenabil de utilizat atunci când descrii operatori (vor fi folosiți aici și mai târziu în carte). În general, ele înseamnă următoarele:

Dacă xyz - unitate sintactică, deci xyz- listă -- xyz, al căror număr este mai mare sau egal cu zero și la fiecare două unități xyz separate de cel puțin un spațiu.
Dacă xyz- unitate sintactică, atunci xyz- comalistă - este o unitate sintactică care xyz, al cărui număr este mai mare sau egal cu zero și la fiecare două unități xyz separate prin virgulă (și eventual unul sau mai multe spații).

Deci, de exemplu, lista de definiții de atribute atribut- apărare- comalistă constă dintr-o succesiune de unități atribut- apărare(adică definiții de atribute), fiecare dintre acestea, cu excepția ultimei, este separată de următoarea virgulă și o listă de potențiale definiții cheie candidat-kei- definiție- listă constă dintr-o succesiune de unități candidat- cheie- definiție(adică definiții cheie candidate), fiecare dintre acestea, cu excepția ultimei, este separată de următoarea prin cel puțin un spațiu. Același lucru se poate spune și despre lista de definiții chei externe străin- cheie- definiție- listă.

2. Definiția atributului are următoarea formă:

atributul DOMAIN ( domeniu)

Dacă specificația „DOMENIU (domeniu)” este omisă, se presupune că atributul se bazează pe un domeniu cu același nume.

3. Definiția cheilor candidate este explicată în detaliu în capitolul următor. Deocamdată, să presupunem că fiecare instrucțiune de creare a relației de bază are o singură definiție în următoarea formă:

CHEIE PRIMARĂ (atribut-commalist)

4. Definițiile cheilor străine sunt explicate și în capitolul următor.

Ștergerea relațiilor de bază. Iată sintaxa pentru operatorul de ștergere a relației de bază existente:

DISTRUGERE RELAȚIA DE BAZĂ relație de bază ;

Această operație este concepută pentru a șterge toate tuplurile unei relații de bază specificate și apoi pentru a șterge toate intrările de director pentru acea relație. După aceasta, relația nu mai este cunoscută de sistem (cu excepția cazului în care este specificat, presupunem că operația DESTRUCȚI RELATIE DE BAZĂ pur și simplu nu va fi efectuată dacă există o definiție de vizualizare care face referire la relația de bază care este ștearsă. O discuție suplimentară despre această problemă. furnizate în părțile ulterioare ale cărții).

Proprietățile relațiilor

Relațiile au anumite proprietăți, toate acestea fiind proprietăți imediate ale definiției date mai devreme relaţie,și toate sunt foarte importante. Mai întâi indicăm pe scurt aceste proprietăți și apoi le discutăm în detaliu. Acestea sunt cele patru proprietăți enumerate mai jos. În orice privință

■ nu există tupluri identice;
■ tuplurile nu sunt ordonate de sus în jos;
■ atributele nu sunt ordonate de la stânga la dreapta;
■ toate valorile atributelor sunt atomice.

1. Nu există tupluri identice.

Această proprietate rezultă din faptul că corpul unei relații este o mulțime matematică (de tupluri), iar mulțimile din matematică, prin definiție, nu conțin elemente identice.

Apropo, prima proprietate servește ca o bună ilustrare a faptului că o relație și un tabel nu sunt același lucru, deoarece un tabel (în general) poate conține aceleași rânduri în absența unor reguli care să interzică acest lucru, în timp ce o relație nu poti conţin tupluri identice. (Prin urmare, o „relație” care conține tupluri identice nu va exista atitudine prin definiție) Din păcate, standardul SQL permite tabelelor să conțină rânduri identice. Ar fi nepotrivit aici să discutăm toate motivele pentru care șirurile identice sunt o eroare (o discuție extinsă a acestei probleme este dată în); Pentru scopurile noastre, este suficient să ne oprim asupra faptului că modelul relațional nu permite linii identice; Aici și de-a lungul acestei cărți presupunem, de asemenea, că nu sunt permise șiruri identice. (Acest punct se aplică în principal discuției despre SQL din Capitolul 8. Când luăm în considerare modelul relațional în sine, desigur, nu trebuie făcute presupuneri.)

O consecință importantă a faptului că nu există două șiruri identice este aceea că că există întotdeauna o cheie primară 3 . Deoarece tuplurile sunt unice, atunci cel puțin combinația toata lumea atributele vor avea proprietatea de unicitate, ceea ce înseamnă că, dacă este necesar, poate servi drept cheie primară. În practică, desigur, de obicei nu este necesar să folosiți toate atributele - o combinație de mai multe atribute este potrivită. Capitolul 5 va defini o cheie primară ca fiind una care nu include atribute care nu sunt necesare din punct de vedere al unicității; prin urmare, de exemplu, combinația (S#,CITY), deși „unica”, nu este o cheie primară, deoarece putem elimina atributul CITY fără a încălca unicitatea. (Rețineți, totuși, că cheile primare pot fi compuse. Un exemplu în acest sens este relația SP.)

2. Tuplurile nu sunt ordonate (de sus în jos).

Această proprietate rezultă și din faptul că corpul unei relații este o mulțime matematică, iar mulțimile simple în matematică nu sunt ordonate. De exemplu, în Fig. 4.1, tuplurile relației S ar putea fi dispuse în ordine inversă - ar fi aceeași relație. Prin urmare, într-o relație nu există conceptul de „al cincilea tuplu”, „al 97-lea tuplu” sau „primul tuplu”, adică nu există conceptul de adresare pozițională și conceptul de „secvență”. menționată în legătură cu proprietatea „nu există tupluri identice”, arată de ce proprietatea „tupluri nu sunt ordonate” este de asemenea importantă (de fapt, aceste proprietăți sunt interdependente).

După cum sa menționat în această secțiune, a doua proprietate a relațiilor ilustrează, de asemenea, faptul că o relație și un tabel nu sunt același lucru, deoarece rândurile unui tabel sunt ordonate de sus în jos, în timp ce tuplurile unei relații nu sunt.

3. Atributele nu sunt ordonate (de la stânga la dreapta).

Această proprietate rezultă din faptul că capul relației este definit și ca un set (de atribute). De exemplu, în Fig. 4.1, atributele relației S ar putea fi reprezentate, să zicem, în această ordine: NUME, ORAȘ, STATUS, S# - ar fi aceeași relație, cel puțin din punctul de vedere al modelului relațional. Prin urmare, nu există conceptul de „primul atribut” sau „ultimul atribut” (etc.), nu există nici un „atribut următor” (din nou, nu există conceptul de „secvență”); cu alte cuvinte, un atribut este întotdeauna identificat după nume, nu după locație. Acest lucru vă permite să evitați unele erori și ambiguități atunci când scrieți programe. De exemplu, nu există (sau nu ar trebui să existe) posibilitatea unei defecțiuni a sistemului din cauza unui atribut „cățărare” pe altul. Această situație diferă de situația din multe sisteme de programare, unde contiguitatea fizică a elementelor logic discrete poate fi exploatată (intenționat sau accidental) în diverse moduri care pot deteriora sistemul.

Rețineți că problema ordinii atributelor este un alt domeniu în care o anumită reprezentare în tabel a unei relații presupune fapte incorecte: coloanele tabelului sunt ordonate de la stânga la dreapta, dar atributele relației nu sunt.

4. Toate valorile atributelor sunt atomice.

Ultima proprietate este o consecință a faptului că toate domeniile subiacente conțin doar valori atomice. Această proprietate poate fi exprimată într-un alt mod (mai degrabă informal): la fiecare poziție a intersecției unei coloane și a unui rând dintr-un tabel, există exact o valoare, și nu un set de valori. Puteți spune și asta: relaţiile nu conţin grupuri de repetiţie. O relație care satisface această condiție se numește normalizată, sau reprezentată în prima formă normală (alte forme normale - a doua, a treia - sunt discutate în următoarele părți ale cărții).

Aceasta înseamnă că din punctul de vedere al modelului relațional, toate relațiile sunt normalizate. Aceasta înseamnă că termenul „relație” înseamnă întotdeauna o „relație normalizată” în contextul modelului relațional. Dar ideea este ce este matematic relația nu trebuie deloc normalizată. Luați în considerare relația ÎNAINTE prezentată în Fig. 4.5. Din punct de vedere matematic, ÎNAINTE este relație de gradul doi, într-unul din domeniile acestei relații valorile sunt relații.

Prin urmare, elementele acestui domeniu sunt ele însele relații și nu simpli scalari. În acest exemplu, atributul PQ este definit pe baza unui domeniu de valori relaționale ale cărui elemente sunt relații binare; aceste relații binare sunt la rândul lor definite pe baza a două domenii de valori scalare, și anume domeniile P# și QTY. Modelul relațional nu permite domenii valoare-relație (acest lucru va fi discutat mai târziu în această carte).

O relație precum relația BEFORE nu este permisă într-o bază de date relațională. Acesta trebuie înlocuit cu o relație normalizată care conține aceleași informații. O astfel de relație este relația AFTER din figură (de fapt, aceasta este relația SP deja familiară). Relația AFTER are un grad de trei și se bazează pe trei domenii cu valori scalare. După cum sa explicat deja, o relație precum relația AFTER se numește normalizată; o relație similară cu relația ÎNAINTE se numește nenormalizată; iar procesul de conversie a unei relații ÎNAINTE într-o relație DUPĂ se numește normalizare. După cum arată acest exemplu, este destul de ușor să obțineți o formă normalizată dintr-o formă nenormalizată, dar sunt multe de spus despre procesul de normalizare și vor fi discutate mai târziu în carte.

Motivul pentru care este necesară normalizarea tuturor tabelelor este următorul. Din punct de vedere matematic, raportul normalizat are mai mult structură simplă. Ca rezultat, mai puțini operatori sunt necesari pentru a lucra cu relații normalizate și sunt mai simple. De exemplu, luați în considerare două probleme.

1. Scrie informație nouă privind furnizarea a 500 de piese P5 furnizorului S5.
2. Înregistrați noi informații de livrare pentru furnizorul S4 al pieselor P5 în valoare de 500.

Pentru relația AFTER, nu există nicio diferență semnificativă în efectuarea acestor două operații, fiecare necesită inserarea unui tuplu în relație. Iar pentru relația ÎNAINTE, prima sarcină necesită aceeași inserare a unui tuplu în relație, dar a doua sarcină necesită funcționare semnificativ diferită,și anume: inserare intrare nouă la un set de înregistrări (adică, un grup de recurență) dintr-un tuplu existent. Prin urmare, pentru a sprijini operațiunile nenormalizate, două complet diferiți operatori"INTRODUCE". Din motive similare, veți avea nevoie și de două instrucțiuni „UPDATE” diferite, două instrucțiuni „DELETE” diferite etc. Vă rugăm să rețineți că aceste note se aplică nu numai procesatorilor de date, ci și toata lumea operatori de sistem; de exemplu, avem nevoie operatori suplimentari asigurând securitatea datelor, sunt necesari operatori suplimentari care să asigure integritatea datelor etc. (Și, în general, poate fi considerată o axiomă că dacă avem P modalități de prezentare a datelor, atunci avem nevoie P seturi de operații.) Deci, răspunsul cu un singur cuvânt la întrebarea „De ce insistăm asupra normalizării?” - Acest simplitate: simplitatea obiectelor cu care lucrăm, ceea ce duce la simplificarea întregului sistem.

4.4. Tipuri de relații

În această secțiune, vom defini unele dintre tipurile de relații găsite în sistemele relaționale (cu toate acestea, rețineți că nu toate sistemele acceptă fiecare dintre aceste tipuri).

1. În primul rând, numit o relație este o variabilă de relație definită în DBMS prin instrucțiunile CREATE BASE RELATION, CREATE VIEW și CREATE SNAPSHOT (în sintaxa pe care o folosim). Instrucțiunea CREATE VIEW a fost introdusă în Capitolul 3, iar instrucțiunea CREATE SNAPSHOT este discutată mai târziu în acest capitol.
2. De bază o relație este o relație numită care nu este derivată (adică relația de bază este autonom).În practică, relațiile de bază sunt acele relații care sunt considerate suficient de importante (dintre cele considerate în baza de date) pe care proiectantul bazei de date le-a considerat potrivit să le numească și să le facă o parte imediată a bazei de date, spre deosebire de relațiile temporare mai puțin importante (cum ar fi cum ar fi, de exemplu, rezultatul interogării).
3. Derivat O relație este o relație definită (prin o expresie relațională) în termeni de alte relații numite și, în ultimă instanță, în termeni de relații de bază.

Avertizare. Amintiți-vă că unii autori prin „derivat” înseamnă „exprimat” (vezi paragraful următor).

4. Exprimabil O relație este o relație care poate fi obținută dintr-un set de relații numite prin intermediul unei expresii relaționale. Desigur, fiecare relație numită este o relație exprimată, dar nu invers. Relațiile de bază, vederile, instantaneele (mai multe despre acestea mai jos), rezultatele intermediare și finale ale rapoartelor sunt toate relații exprimabile. Cu alte cuvinte, mulțimea tuturor relațiilor exprimabile este exact mulțimea tuturor relațiilor de bază și a tuturor relațiilor derivate.
5. Supunerea se numește relație derivată numită. (Reprezentările, ca și relațiile de bază, sunt variabile relaţii.) Reprezentări virtual - ele sunt reprezentate în sistem numai prin definiție în termenii altor relații numite.
6. Imagini (instantaneu) - sunt denumite relații derivate, la fel ca vederile (și ca și vederile sunt variabile relații). Totuși, spre deosebire de reprezentări, imaginile sunt reale și nu virtuale, adică. sunt reprezentate nu numai prin definiție în termenii altor relații numite, ci și (cel puțin conceptual) prin datele lor individuale. Iată un exemplu:

Crearea unui instantaneu este similară cu executarea unei interogări, cu excepția faptului că rezultatul unei astfel de interogări este stocat în baza de date sub un nume specific (SC în exemplul nostru) ca o relație numai pentru citire și periodic (în fiecare zi în exemplul nostru) instantaneul este „reîmprospătat”, adică valoarea sa curentă este resetată, interogarea este executată din nou, iar rezultatul său devine noua valoare instantanee. Utilizarea instantaneelor va fi discutată în părțile ulterioare ale cărții.

7. Un rezultat al unei interogări este o relație derivată fără nume, care servește ca rezultat al unei anumite interogări.
8. Un rezultat intermediar este o relație derivată fără nume care este rezultatul unei expresii relaționale încorporate într-o altă expresie mai mare. De exemplu, luați în considerare această expresie:

Relația rezultată din expresia S JOIN SP va fi un rezultat intermediar; Să-i spunem TEMP1. Atunci relația rezultată din expresia TEMP1 WHERE P# = "P2" va fi și ea un rezultat intermediar; Să-i spunem TEMP2. Iar relația rezultată din expresia TEMP2 va fi rezultatul final. Baza de date nu oferă existență persistentă pentru rezultatele intermediare și nici pentru rezultatele finale (într-adevăr, așa cum sa menționat în Capitolul 3, acestea pot să nu existe ca un tabel complet materializat ca atare).

9. Și în sfârșit, stocate relația este o relație care se menține în memorie fizică„direct” (desigur, cu o definiție adecvată a „imediatității”; o discuție mai detaliată a acestei probleme depășește scopul acestui capitol).

În concluzie, să adăugăm că relația stocată Nu coincide întotdeauna cu relația de bază. Setul de relații stocate trebuie să fie astfel încât toate relațiile de bază și, prin urmare, toate relațiile exprimate, să poată fi derivate din el; dar nu necesită ca toate relațiile stocate să fie relații de bază și nu necesită ca toate relațiile de bază să fie stocate. O discuție mai detaliată a acestei probleme a fost oferită în capitolul 3.

4.5. Relații și predicate

Deși nu ne-am oprit asupra acestei probleme, probabil că cititorul înțelege intuitiv că fiecare relație are unele interpretare, iar utilizatorii trebuie să-l cunoască pentru a utiliza în mod eficient baza de date. De exemplu, interpretarea relației S ar putea fi după cum urmează:

Furnizor cu un anumit număr (S#) are un nume specific (SNAME) și o anumită valoare de stare (STARE) și se află într-un anumit oraș (ORAȘ); în plus, nu există doi furnizori care au aceleași numere.

Această afirmație nu este foarte precisă, dar se potrivește scopurilor noastre.

Formal, afirmația anterioară este un exemplu a ceea ce se numește predicat, sau funcție de valoare de adevăr; în cazul nostru particular - o funcție a patru argumente. Înlocuirea valorilor acestor argumente este echivalentă voi suna funcția (sau „confirmarea” predicatului), și prin urmare obținerea unei expresii numită afirmație, care poate fi fie adevăr sau minciuni. De exemplu, la înlocuire

S#= "SI" SNAME ="Smith1 STATUS = 20 CITY = "Londra"

adevărul.Și la înlocuire

S#= „SI” NUME = „Abbey” STATUS = 45 ORAȘ = „Tucson”

Obținem o declarație care este minciuni(deoarece numărul furnizorului S1 nu este numit Abbey, nu este statutul 45 și nu este situat în Tucson). Și în orice moment de timp relația conține exact acele tupluri pentru care este predicatul adevărul.

Din cele de mai sus rezultă că (de exemplu) un tuplu prezentat ca candidat pentru inserarea într-o relație va fi acceptat de SGBD numai dacă nu contrazice predicatul corespunzător (adică declarația corespunzătoare nu va fi minciuni).În general, predicatul acestei relații este criteriul de posibilitate actualizări pentru această relație; acestea. un criteriu pentru a decide dacă o actualizare este validă (sau cel puțin „plauzibilă”) pentru o relație dată.

Pentru ca sistemul să determine dacă o relație dată poate fi actualizată, trebuie să cunoască predicatul acestei relații. Desigur, acum SGBD nu poate cunoaște exact predicatul pentru o relație dată. De exemplu, în cazul relației S, SGBD nu poate ști cu siguranță că predicatul pentru tuplu (S1,Smith,20,Londra) va fi adevăr, dar pentru tuplu (S1,Abbey,45,Tucson) - nr. 5 Cu toate acestea, SGBD consideră un tuplu acceptabil dacă sunt îndeplinite următoarele condiții:

Valoarea S# aparține domeniului număr furnizor.
Valoarea SNAME aparține unui domeniu de nume.
Valoarea STATUS aparține domeniului valorii de stare.
Valoarea CITY aparține domeniului numelui orașului.
Valoarea S# trebuie să fie unică între toate valorile relației.

Cu alte cuvinte, pentru o relație de bază precum S, DBMS utilizează relații specifice declarate pentru aceasta reguli de integritate, cum ar fi regula conform căreia valoarea S# este unică și aparține domeniului numărului furnizorului. Prin urmare, formal putem defini„valoarea” (cunoscută de SGBD) a unei relații de bază date ca o multiplicare logică (operație logică ȘI) a tuturor regulilor cunoscute de SGBD aplicate acestei relații. Și tocmai în acest sens SGBD va verifica admisibilitatea actualizării acestei relații.

Vom reveni la sensul raportului de mai multe ori în capitolele următoare.

4.6. Baze de date relaționale

Pe baza discuțiilor și explicațiilor din acest capitol, poate fi dată o definiție mai formală (mai formală decât cea dată mai devreme în acest capitol) a termenului „bază de date relațională”. Parafrazând definiția dată de Codd în, obținem următoarele:

O bază de date relațională este o bază de date care este percepută de utilizator ca un set de relații normalizate (de ex. variabile relaţii) de diferite grade.

După cum s-a menționat mai devreme, expresia „percepută de utilizator” este crucială: ideea unui model relațional se aplică la nivelurile externe și conceptuale ale sistemului, nu la nivelul intern. Un alt mod de a spune este că modelul relațional reprezintă un sistem de baze de date la un nivel de abstractizare oarecum îndepărtat de detaliile mașinii de bază; la fel ca, de exemplu, limbajul Pascal reprezintă un sistem de programare la un nivel de abstractizare oarecum îndepărtat de detaliile mașinii de bază. De fapt, modelul relațional poate fi gândit ca un limbaj de programare specific aplicațiilor de baze de date.

Distincția dintre domenii și relații (numite) poate fi, de asemenea, oarecum clarificată. Numim variabile de relații numite deoarece valorile lor se schimbă în timp. După cum sa menționat mai devreme în acest capitol, domeniile Nu sunt variabile în acest sens. De exemplu, multe tot posibil Numerele furnizorilor, desigur, nu se schimbă în timp, sau dacă se întâmplă, atunci schimbarea este descriptiv caracterul, adică apare la nivel de tip, nu la nivel de instanță. Aceasta este un pic ca schimbarea tipului de date de bază pentru numărul furnizorului de la CHAR(5) la CHAR(7). Vă rugăm să rețineți că o astfel de modificare poate necesita o reorganizare a bazei de date.

Deci, putem spune că în termeni tradiționali o relație corespunde unui fișier (logic, nu fizic), un tuplu este înregistrări(instanță, nu tip), atribut camp(tip, nu exemplu). Cu toate acestea, această corespondență în cel mai bun scenariu aproximativ. Relația nu trebuie considerată „doar un fișier”, ci ca un fișier, supuse anumitor reguli acest lucru se reflectă într-o simplificare semnificativă a structurii obiectelor de date pe care utilizatorul le întâlnește și, în consecință, într-o simplificare a operatorilor necesari pentru a lucra cu aceste obiecte. Mai precis, toate datele din sistem relațional se prezinta unul si numai unul mod, și anume valori explicite (această proprietate este uneori numită „principiul de bază al modelului relațional”, precum și „ principiul informaţiei„). În mod specific, aceste valori explicite reprezintă relații logice în interiorul și între relații; nu există niciun fișier vizibil de utilizator sau indicatori de înregistrare, nicio ordine de înregistrare vizibilă de utilizator, grupuri de repetare vizibile de utilizator etc.

6 Dacă ne gândim la relații ca la tabele, atunci am putea spune că, de exemplu, variabila relație S reprezintă tabele diferite în momente diferite. Cu toate acestea, rețineți că aceste tabele diferite vor avea rânduri diferite, dar coloanele vor fi aceleași.

7 Pentru cititorii familiarizați cu limbajul SQL, rețineți că în SQL este posibil să adăugați coloană nouă sau eliminați o coloană existentă din tabelul de bază folosind instrucțiunea ALTER TABLE. Cu toate acestea, această operație este mai bine gândită nu ca modificarea unui tabel existent, ci ca distrugerea tabelului existent și crearea unuia nou cu același nume și antet nou.

8 Mai exact, există întotdeauna cel puțin unul potenţial cheie. Presupunem că una dintre cheile candidate este selectată ca cheie primară. Există o discuție suplimentară despre această problemă în capitolul 5.

9 Conceptul de „secvență” este necesar pentru interfața dintre o bază de date relațională și un limbaj gazdă precum C sau COBOL. Dar aceasta este o cerință pentru limbajele de bază, nu pentru modelul relațional. În esență, aceste limbi necesită asta dezordonat seturile au fost convertite în ordonat astfel încât să poată fi efectuate operații precum „apelați următorul tuplu”. Rețineți, de asemenea, că astfel de capabilități fac parte din interfața de programare a aplicației - nu sunt vizibile pentru utilizatorul final.

10 Aici folosim stenografia evidentă că expresia (S1,Smith,20,London) corespunde tuplui ( , ).

Integritatea datelor relaționale (pag. 113-130)

Cartea " Introducere în sistemele de baze de date », Chris J. Data , 8 -e ediție, hârtie decalaj-alb, solid legare, 1328 p., ISBN 978-5-8459-0788-2, „WILLIAMS”, 2016 - comanda-cumpara carte " » în magazinul online ComBook.ru

Al optulea publicarea lucrării fundamentale" Introducere în sistemele de baze de date » Chris Date oferă o introducere cuprinzătoare în teoria acum foarte extinsă a sistemelor de baze de date

Cu asta clasic Cititorul va putea dobândi cunoștințe fundamentale în domeniul tehnologiei bazelor de date, precum și să se familiarizeze cu direcțiile în care domeniul de activitate în cauză este susceptibil să se dezvolte în viitor

Carte " Introducere în sistemele de baze de date » este destinat să fie folosit în primul rând ca un manual, mai degrabă decât ca o carte de referință, așa că va fi, fără îndoială, de interes pentru programatori profesioniști, cercetători și studenți care studiază cursuri relevante în instituțiile de învățământ superior

In carte Chris Date accentul se pune pe stăpânirea esenței și înțelegerii profunde a materialului prezentat, și nu doar pe prezentarea formală a acestuia

Carte " Introducere în sistemele de baze de date „cu siguranță va fi util tuturor celor care trebuie să lucreze cu baze de date sau pur și simplu să le folosească

( )
(comanda-cumpara carte " Introducere în sistemele de baze de date» în magazinul online ComBook.ru )

( )
(comanda-cumpara carte pe " Introducere în sistemele de baze de date» în megamarketul online Ozon.ru )

( )
(comanda-cumpara carte " Introducere în sistemele de baze de date» în magazinul online diamail.com.ua )

Pe Limba rusă cartea a fost publicată în iulie 2016 al anului la editura " WILLIAMS „și retipărit ediție limitată

CONȚINUTUL CĂRȚII « Introducere în sistemele de baze de date » ( 8 editia I)
____________________________________
Introducere

Partea I. Concepte de bază
Capitolul 1. Baze de date și gestionarea acestora
Capitolul 2. Arhitectura sistemului de baze de date
Capitolul 3. Introducere la baze de date relaționale date
Capitolul 4. Introducere în limbaj SQL

Partea a II-a. Model relațional
Capitolul 5. Tipuri
Capitolul 6. Relații
Capitolul 7. Algebră relațională
Capitolul 8. Calcul relațional
Capitolul 9. Integritatea datelor
Capitolul 10. Vizualizări

Partea a III-a. Proiectarea bazei de date
Capitolul 11. Dependențe funcționale
Capitolul 12. Normalizare ulterioară: formele 1nf, 2nf, 3nf și nfbk
Capitolul 13: Normalizare ulterioară: Forme normale de ordin superior
Capitolul 14. Modelare semantică

Partea a IV-a. Managementul tranzacțiilor
Capitolul 15. Recuperare
Capitolul 16. Paralelism

Partea V. Subiecte suplimentare
Capitolul 17. Protecția datelor
Capitolul 18. Optimizare
Capitolul 19. Informații lipsă
Capitolul 20. Moștenirea tipului
Capitolul 21. Baze de date distribuite date
Capitolul 22. Suport decizional
Capitolul 23. Baze de date istorice
Capitolul 24. Sisteme logice managementul bazei de date

Partea a VI-a. Obiecte, relații și XML
Capitolul 25. Baze de date cu obiecte date
Capitolul 26. Baze de date obiect-relaționale
Capitolul 27. World Wide Web și XML

Partea a VII-a. Aplicații
Anexa A: Modelul transrelațional
Anexa B: Expresii SQL
Anexa B: Abrevieri și caractere speciale
Anexa D. Structuri de stocare și metode de acces
Index de subiect

Bază de date.
Proiecta,
implementare și
acompaniament
Teorie și practică

Thomas Connolly
Caroline Begg

Cartea " Bază de date. Proiectare, implementare și suport. Teorie și practică », Thomas Connolly , Caroline Begg , hârtie decalaj-alb, solid legare, 1440 p., ISBN 978-5-8459-2020-1, „DIALECTICĂ”, 2017 - comanda-cumpara carte " Bază de date» în magazinul online ComBook.ru

Pe paginile cărții " » a concentrat mulți ani de experiență bogată în dezvoltarea bazelor de date pentru nevoile industriei, afacerilor și științei, precum și în predarea studenților. Rezultatul travaliului Thomas Connolly Și Caroline Begg a devenit complet ghid de referință privind proiectarea, implementarea și întreținerea bazelor de date

Carte " Bază de date. Proiectare, implementare și suport. Teorie și practică » conţine descriere detaliata caracteristici de dezvoltare a aplicațiilor de baze de date pentru Internet și numeroase exemple de cod pentru accesarea bazelor de date de pe Internet, inclusiv utilizarea instrumentelor JDBC, SQLJ, ASP, JSP și PSP Oracle

In carte " Bază de date. Proiectare, implementare și suport. Teorie și practică » se oferă o introducere cuprinzătoare în tehnologia de extragere a informațiilor, depozite de date și OLAP, sunt prezentate SGBD-uri moderne distribuite, orientate pe obiecte și relaționale cu obiecte

Prezentarea clară și concisă a materialului, prezența unuia principal și a trei exemple educaționale auxiliare și multe întrebări de testareși exerciții vă permite să utilizați această carte nu numai pentru auto-studiu, dar și ca bază pentru desfășurarea de cursuri de formare de toate nivelurile de complexitate, de la studenți juniori până la absolvenți, precum și un ghid cuprinzător de referință pentru profesioniști

Cartea originala: « Sisteme de baze de date: o abordare practică a proiectării, implementării și managementului " de Thomas Connolly și Carolyn Begg

(cartea poate fi comandată și achiziționată de la Biblio-Globus )
(comanda-cumpara carte " Bază de date» în magazinul online biblio-globus.ru )

(Cartea poate fi comandată de la KOMBUK e - cel mai mult preț scăzut in Rusia! )
(comanda-cumpara carte " Bază de date» în magazinul online ComBook.ru )

(Cartea poate fi comandată pe Ozon.ru )
(comanda-cumpara carte pe " Introducere în sistemele de baze de date» în megamarketul online Ozon.ru )

(cartea poate fi comandată de la DiaMail Ucraina )
(comanda-cumpara carte " Bază de date» în magazinul online diamail.com.ua )

In carte " » la întrebările care necesită soluții rapide se oferă răspunsuri simple și practice. După ce a lucrat 30 lectii, care durează aproximativ 10 minute toată lumea, veți învăța tot ce trebuie să știți pentru a folosi limba în mod profitabil T-SQL a lucra cu RDBMS Microsoft SQL Server

Acest ghid de buzunar la îndemână începe cu exemple simple de regăsire a datelor și progresează la subiecte mai complexe, inclusiv îmbinări, subinterogări, expresii obisnuiteși căutarea textului integral, proceduri stocate, cursoare, declanșatoare, constrângeri de tabel, procesarea datelor în formate XML Și JSON și mult mai mult

Pentru comoditatea studierii materialului de lecție, cartea „ Limbajul T-SQL pentru Microsoft SQL Server în 10 minute » echipat cu următoarele inserturi :

- Sfat . Indică comenzi rapide și soluții la probleme practice
- Avertizare . Ajută la evitarea obstacolelor ascunse comune
- Notă . Explică concepte înrudite și oferă informații suplimentare

Cheltuind 10 minute pentru fiecare lecţie , veți învăța următoarele :

bucură-te T-SQL SQL Server
- Compune interogări complexe folosind operatori, clauze și operațiuni pe T-SQL
- Extrageți, sortați și formatați conținutul bazei de date

- Implementarea globalizării și a localizării pe SQL Server
- Creați subinterogări pentru a clarifica datele
- Automatizați-vă volumul de lucru folosind declanșatoare

- Gestionați vizualizări, proceduri stocate, cursoare și alte instrumente SQL Server

(Cartea poate fi comandată și cumpărată de la KOMBUK e - cel mai mic preț din Rusia! )
(comanda-cumpara carte " Limbajul T-SQL pentru Microsoft SQL Server în 10 minute» în magazinul online ComBook.ru )

(Cartea poate fi comandată și achiziționată de pe Ozon.ru )
(comanda-cumpara carte pe " Limbajul T-SQL pentru Microsoft SQL Server în 10 minute» în megamarketul online Ozon.ru )

(cartea poate fi comandată și achiziționată de la DiaMail Ucraina )
(comanda-cumpara carte " Limbajul T-SQL pentru Microsoft SQL Server în 10 minute» în magazinul online diamail.com.ua )

In carte " » prezintă bazele teoretice pentru organizarea sistemelor de date mari și explică modul în care acestea sunt implementate în practică

In carte " Date mare » este luată în considerare arhitectura lambda , destinat construirii unor astfel de sisteme și folosind exemplul unei aplicații web specifice, caracteristicile implementării tuturor nivelurilor acestei arhitecturi sunt explicate folosind instrumente precum Hadoop , Cassandra Și Furtună

Bazat pe un exemplu realist din carte " Date mare » este schițată teoria sistemelor mari de transmisie și procesare a datelor, precum și modalități practice de implementare, implementare și gestionare a acestora

În aplicațiile web la scară largă care acceptă retele sociale, efectuați analize în timp real sau susțineți comerțul electronic, trebuie să procesați cantități mari de date, al căror volum și viteză depășesc capacitățile sisteme de informare bazate pe baze de date tradiționale. Pentru aplicații similare sunt necesare arhitecturi care se bazează pe clustere de mașini pentru stocarea și procesarea datelor de orice volum și la orice viteză. Adevărat, scalabilitatea și simplitatea nu sunt proprietăți care se exclud reciproc ale unor astfel de arhitecturi

Carte " Big data: principii și practică de construire a sistemelor scalabile de procesare a datelor în timp real » vă va învăța cum să creați sisteme mari de transmisie și procesare a datelor folosind o arhitectură special concepută pentru colectarea și analiza datelor la scară web. Cartea descrie un scalabil, ușor de înțeles o abordare Arhitectura Lambda , care poate fi implementat de o echipă mică. Acesta examinează teoria sistemelor mari de transmisie și procesare a datelor și arată cum să le implementeze în practică. Cu exceptia principii generale procesarea datelor mari, veți studia tehnologii specifice precum Hadoop , Furtună și baze de date NoSQL

Introducere în sistemele de date mari
Procesarea datelor la scară web în timp real
Instrumente Hadoop , Cassandra Și Furtună
Extinderea experienței de utilizare a bazelor de date tradiționale

De la cititorii cărții " Big data: principii și practică de construire a sistemelor scalabile de procesare a datelor în timp real » nu sunt necesare cunoștințe despre metodele de analiză a datelor mari sau competența instrumentelor NoSQL . Cunoașterea elementelor de bază ale bazelor de date tradiționale este de dorit ( SGBD )

Carte " Date mare » este conceput pentru cititorii care doresc să stăpânească principiile construirii sistemelor de date mari și să le implementeze în practică

(Cartea poate fi comandată de la KOMBUK e - cel mai mic preț din Rusia! )
(comanda-cumpara carte " Date mare» în magazinul online ComBook.ru )

(Cartea poate fi comandată pe Ozon.ru )
(comanda-cumpara carte pe " Date mare» în megamarketul online Ozon.ru )

(cartea poate fi comandată de la DiaMail Ucraina )
(comanda-cumpara carte " Date mare» în magazinul online diamail.com.ua )

Al treilea ediție bestseller Thomas Kite « „, un profesionist de renume mondial Întreabă-l pe Tom , dedicat cele mai bune practici aplicatii Oracle DBMS pentru construirea de aplicații scalabile care au performanță și fiabilitate bune

Filosofia lui Tom este simplă: Oracle DBMS Îl puteți percepe ca o „cutie neagră” cu date în interior sau puteți înțelege cum funcționează și să operați DBMS ca un mediu de calcul puternic. Dacă adoptați a doua abordare, veți constata că nu există multe probleme de gestionare a informațiilor care să nu poată fi rezolvate rapid și elegant

Complet revizuit al treilea publicarea cărții" Oracle pentru profesioniști: arhitectură, tehnici de programare și caracteristici principale ale versiunilor 9i, 10g, 11g și 12c » acoperă noile tehnici de dezvoltare introduse în cea mai recentă versiune Baza de date Oracle . Fiecare instrument este predat prin exemple, explicând nu numai ce este, ci și cum funcționează instrumentul și cum se dezvoltă. software cu utilizarea sa și care sunt cunoscute" roci subacvatice„legat cu el

(Cartea poate fi comandată pe Ozon.ru )
(comanda-cumpara carte " Oracle pentru profesioniști» în megamarketul online Ozon.ru )

(cartea poate fi comandată de la DiaMail Ucraina )
(comanda-cumpara carte " Oracle pentru profesioniști» în magazinul online diamail.com.ua )

(cartea poate fi comandată la bizbook.ua Ucraina )
(comanda-cumpara carte " Oracle pentru profesioniști» în magazinul online bizbook.ua )

In carte " SQL: Ghidul complet » conține cuprinzător, profund și descriere detaliata limba SQL . Este destinat utilizatorilor, programatorilor și cercetătorilor de date, precum și managerilor care doresc să cunoască impactul SQL la piata calculatoarelor

Carte " SQL: Ghidul complet » James R. Groff etc. vă vor spune cum să lucrați cu comenzi și instrucțiuni SQL , creați și configurați baze de date relaționale, încărcați și modificați obiectele bazei de date, rulați interogări puternice, îmbunătățiți performanța și construiți securitatea. Veți învăța cum să utilizați instrucțiunile DDL si aplica API , integrează XML și scenarii Java , folosiți obiecte SQL , creați servere web, lucrați cu acces de la distanțăși efectuează tranzacții distribuite

În această carte veți găsi informații precum descrieri de lucru cu baze de date în memorie, baze de date în flux și încorporate, baze de date pentru dispozitive mobile, și mult mai mult. Carte " SQL: Ghidul complet » include Descriere completa sintaxa conexiunii SQL iar după ce ai citit această carte vei învăța:

Construirea bazelor de date și aplicațiilor relaționale SQL. Crearea, încărcarea și modificarea obiectelor bazei de date folosind SQL
- Construirea și executarea de interogări simple, multi-tabel și rezumative
- Implementați securitatea folosind autentificare, privilegii, roluri și vizualizări
- Optimizare, backup, recuperarea și replicarea bazei de date
- Lucrul cu proceduri stocate, funcții, extensii, declanșatoare și obiecte
- Funcționalitate avansată folosind API, SQL dinamic și încorporat
- Descrie probleme precum tranzacții, mecanisme de blocare, vederi materializate și protocolul de finalizare a tranzacțiilor în două faze
- Cele mai recente tendințe ale pieței și viitorul SQL

Carte " SQL: Ghidul complet " include o descriere completă a capabilităților SQL, standardul ANSI, aplicații și considerații de programare. Include istoricul, tendințele pieței și compararea capabilităților principalelor SGBD. Informații actualizate despre bazele de date XML, enterprise și personalizate (în memorie, streaming și baze de date încorporate). De la trei experți de top - James R. Groff, Paul N. Weinberg, Andrew J. Oppel - care acoperă toate aspectele SQL. Revizuită pentru a ține cont de cele mai recente versiuni ale SGBD-urilor relaționale, cartea „ SQL: Ghidul complet » explică cum să creați, să populați și să administrați baze de date de înaltă performanță și cum să dezvoltați aplicații puternice și de încredere folosind SQL

(cartea este în stoc la KOMBUK e - cel mai mic preț din Rusia )
(comanda-cumpara carte pe " SQL: Ghidul complet» în magazinul online ComBook.ru )

( )
(comanda-cumpara carte pe " SQL: Ghidul complet» în magazinul online ozon.ru )

(cartea este în stoc la DiaMail Ucraina )
(comanda-cumpara carte pe " SQL: Ghidul complet» în magazinul online diamail.com.ua )

Carte " SQL în 10 minute » te va ajuta sa stapanesti in cel mai scurt timp posibil SQL este cel mai popular limbaj de interogare a bazei de date. Începând cu interogări simple pentru selectarea datelor, autorul trece pas cu pas prin subiecte din ce în ce mai complexe, cum ar fi utilizarea operatorilor de unire, subinterogări, proceduri stocate, indici, declanșatori și constrângeri

După ce am lucrat prin toate 22 de lecții din carte, fiecare dintre acestea nu va costa mai mult de 10 minute , vei afla despre tot ce trebuie aplicație practică SQL

Mulțumită cărții SQL în 10 minute » veți învăța rapid cum să compuneți independent interogări în bazele de date în limba respectivă SQL fara ajutorul nimanui

Exemple date în carte " SQL în 10 minute ", va funcționa în toate cele mai populare versiuni DBMS cele mai recente - IBM DB2 , Microsoft Access , Microsoft SQL Server , MySQL , Oracol , PostgreSQL , SQLite , MariaDB Și Apache Open Office Base

(cartea este pe stoc la OZON e )
(comanda-cumpara carte pe " SQL în 10 minute» în magazinul online ozon.ru )

Cartea " Oracle PL/SQL în 10 minute» în megamarketul online Ozon.ru

In carte " Oracle PL/SQL în 10 minute » la întrebările care necesită soluții rapide se oferă răspunsuri simple și practice. Acest ghid rapid de referință constă din 26 de lecții. Nu cheltuiți mai mult de 10 minute pentru fiecare ( sau chiar mai putin!), vei învăța tot ce trebuie să știi pentru a folosi limba în mod profitabil PL/SQL când lucrezi cu Oracle DBMS

« Oracle PL/SQL în 10 minute " este o referință de buzunar foarte compactă și la îndemână, care începe cu exemple simple de regăsire a datelor și progresează la subiecte mai complexe, inclusiv alăturari, subinterogări, expresii regulate și căutare de text complet, proceduri stocate, cursore, declanșatoare, constrângeri de tabel și multe altele

Caracteristicile cărții " Oracle PL/SQL în 10 minute »:

* O modalitate simplă și ușor de învățat de prezentare a materialului, indicând o cale scurtă și rezolvând probleme practice cu demonstrație folosind exemple specifice de utilizare a limbii PL/SQL și unelte Oracol

* Instrucțiuni pas cu pas pentru a vă ajuta să evitați obstacolele comune ascunse, explicând simplu și clar modul în care limba PL/SQL lucrați cu vizualizări, proceduri stocate, cursoare, declanșatoare și alte instrumente

*Explicarea simplă și logică a conceptelor înrudite și prezentarea de material suplimentar

După ce am studiat cartea " Oracle PL/SQL în 10 minute ", O sa inveti:

bucură-te PL/SQL în medii şi unelte Oracol
- Construiți interogări complexe folosind operatori, clauze și operații PL/SQL
- Extrageți, sortați și formatați conținutul bazei de date
- Selectați datele necesare folosind diferite căi filtrăndu-le
- Utilizați șirul de caractere, data și ora și funcții matematice pentru a manipula datele
- Uniți două sau mai multe mese împreună
- Introduceți, actualizați și ștergeți datele
- Creați și modificați tabele de baze de date
- Gestionați vizualizările, procedurile stocate, cursoarele, declanșatoarele și alte instrumente

Cartea originala: « », Ben Forta , 288 pagini, ISBN 9780672328664, 2015

Carte " SQL pentru manechin » ( 8 -e editie) este destinat celor care doresc să-și îmbunătățească nivelul de lucru cu bazele de date folosind limba interogări structurate — SQL . Veți stăpâni elementele de bază ale bazelor de date relaționale și ale limbajului SQL , învață să proiectezi baze de date, să le populezi cu informații și să le regăsești folosind capabilități avansate de limbaj

Părți separate ale cărții " SQL pentru manechin » sunt dedicate problemelor securității informațiilor în bazele de date și gestionării erorilor. Limba SQL nu este ușor, dar odată ce ați înțeles, puteți crea baze de date relaționale și puteți extrage informații valoroase din ele cu ușurință

Folosind cea mai recentă versiune a limbii SQL:2011 , veți putea structura un sistem de management al bazei de date, implementați proiecte, vă protejați datele, organizați accesul și lucrați cu el, mențineți baza de date și multe altele
), P o l n O ts V e t nu e ediție , copertă cartonată, ~800 p., ISBN, „DIALECTICĂ”, 2019

Carte " Informatică. Curs de bază „este scris pentru studenții care și-au ales ca profesie informatica, precum și pentru studenții specializați în orice alte discipline. Acoperirea largă a materialului, împreună cu prezentarea clară, îl fac accesibil studenților de orice nivel de fundal, oferind o înțelegere practică și realistă a subiectului

Scopul acestei cărți - să ofere studenților o înțelegere cuprinzătoare a disciplinei informatică, acoperind toate aspectele acesteia, de la cele pur practice la cele complet abstracte. Această abordare cuprinzătoare a învățării conceptelor de bază îi expune pe studenții de la informatică la marea lățime a materiei în care aleg să se specializeze și le permite studenților din orice altă disciplină să obțină o privire de ansamblu asupra oportunităților disponibile în societatea tehnocratică modernă în care trăiesc.

Cartea originala: « Informatică: o privire de ansamblu », Glenn Brookshear , Dennis Brylow , 13 th Ediție, 736 pagini, ISBN 9780134875460, Martie 2018

Cartea este discutată în blogul meu

URMAȚI ACEST MESAJ PENTRU SCHIMBĂRI -
Ultima actualizare - 30 iulie 2018 al anului
_______________________________________
ÎNTREBARE - Ce alte cărți pe această temă puteți oferi pentru publicare imediată în limba rusă? ?

P .S . Doar poziția ta activă într-o perioadă atât de dificilă va contribui la apariția unor noi cărți de care ai nevoie. Și, de asemenea, contribuie la îmbunătățirea calității cărților publicate grup de editare « DIALECTICĂ -WILLIAMS»

_____________________________________________
Vă examinez comentariile înainte de a le publica. Prin urmare, îmi rezerv dreptul de a publica sau nu comentarii cu semnătură Anonim

Funcții DBMS Deyt, K. J. Introducere în sistemele de baze de date [text] / K. J. Deyt. - M.: Editura Williams, 2006. - 1328 p. - ISBN 5-5489-0788-8.

Mai precis, funcțiile DBMS includ de obicei următoarele:

¦ Definirea datelor

SGBD-ul trebuie să ofere un mijloc de definire a datelor în forma sa sursă și de transformare a acestor definiții în forma obiectului adecvată. Cu alte cuvinte, SGBD-ul trebuie să includă componente ale unui procesor DDL (limbaj de definire a datelor) sau un compilator DDL pentru fiecare dintre limbajele de definire a datelor pe care le acceptă. SGBD-ul trebuie, de asemenea, să interpreteze corect sintaxa limbajului de definire a datelor, astfel încât să i se spună, de exemplu, că înregistrările externe ale ANGAJATELOR includ un câmp SALARIU. SGBD-ul trebuie să utilizeze aceste informații atunci când analizează și execută interogări de prelucrare a datelor.

¦ Manipularea datelor

SGBD-ul trebuie să poată procesa solicitările utilizatorilor de selectare, modificare sau ștergere a datelor deja existente în baza de date sau de a adăuga date noi la aceasta. Cu alte cuvinte, SGBD-ul trebuie să includă un procesor DML sau o componentă compilator DML care oferă suport pentru un limbaj de manipulare a datelor (DML).

În general, cererile NMD sunt împărțite în planificate și neplanificate.

a) O cerere planificată este o cerere a cărei necesitate de executare a fost prevăzută în prealabil. Administratorul bazei de date poate avea nevoie să proiecteze designul fizic al bazei de date pentru a se asigura că astfel de interogări pot rula suficient de rapid.
b) O solicitare neplanificată este, dimpotrivă, o cerere arbitrară pentru o selecție sau (mai puțin probabil) pentru o actualizare, a cărei necesitate nu a fost prevăzută în prealabil și a apărut dintr-un motiv special.

¦ Optimizare si executie

Interogările NMD, programate sau neprogramate, trebuie procesate de o componentă, cum ar fi un optimizator, al cărui scop este să găsească suficiente mod eficient executarea fiecăreia dintre cereri. Interogările optimizate sunt apoi executate sub controlul managerului de rulare.

¦ Protecția și menținerea integrității datelor

SGBD-ul trebuie să monitorizeze solicitările utilizatorilor și să prevină orice încercare de încălcare a restricțiilor de securitate și integritate a datelor definite de DBA (vezi secțiunea anterioară). Acest control poate avea loc în timpul compilării, în timpul executării sau ambele în timpul procesării cererii.

¦ Suport pentru recuperare de date și paralelism

DBMS sau altele conexe componenta software, numit în mod obișnuit manager de tranzacții sau manager de execuție a tranzacțiilor, trebuie să ofere controlul necesar asupra recuperării datelor și controlului concurenței.

¦ Dicţionar de date

SGBD-ul trebuie să suporte funcția de menținere a unui dicționar de date. Dicționarul de date în sine poate fi considerat o bază de date independentă (dar nu o bază de date pentru utilizatori, ci una de sistem). Dicționarul conține „date despre date”, adică. conține definiții ale altor obiecte de sistem, nu doar date obișnuite. În special, dicționarul de date ar trebui să conțină formele sursă și obiect ale tuturor schemelor existente (externe, conceptuale etc.) și mapărilor, precum și restricții stabilite protecția și integritatea datelor.

UNINTRODUCERELA

Sisteme de baze de date

EDIȚIA A ȘAPTEA

INTRODUCERE IN

sisteme

baze de date

EDIȚIA A ȘAPTEA

Moscova Sankt Petersburg Kiev 2001

K. J. Data

BBK 32.973.26-018.2.75 D27

Editura „William”

Traducere din engleză Candidat la științe fizice și matematice Yu G Gordienko, V V Repetsky, A.V. Sleepsova Editat de A.V. Sleepsova

Pentru întrebări generale, vă rugăm să contactați Editura William la: info@ williamspublishing. com, http:// www. williamspublishing com

Data, K., J.

D27 Introducere în sistemele de baze de date, ediția a VII-a: Trad. din engleza - M.: Editura „William”, 2001. - 1072 p. : bolnav. - Paral. tit. Engleză

ISBN 5-8459-0138-3 (rusă)

Această nouă ediție a lucrării fundamentale a lui Chris Data, unul dintre cei mai respectați experți și gânditori din lume în domeniul tehnologiei bazelor de date, va trezi cu siguranță interesul programatorilor profesioniști, cercetătorilor și studenților care urmează cursuri conexe în instituțiile de învățământ superior. Această carte conține o prezentare cuprinzătoare atât a ideilor clasice din domeniul teoriei relaționale, cât și o discuție amplă a celor mai moderne soluții practice și tehnologii în domeniul proiectării, implementării și întreținerii bazelor de date. În ciuda profunzimii excepționale de abordare a subiectului, materialul este prezentat într-un limbaj simplu și clar și este însoțit de un număr mare de exemple practice. Cartea va fi cu siguranță utilă oricui are de-a face cu baze de date sau pur și simplu interesat de acest subiect.

BBK 32.973.26-018.2.75

Toate titlurile produse software sunt mărci comerciale înregistrate ale companiilor respective

Nicio parte a acestei publicații nu poate fi reprodusă sub nicio formă sau prin orice mijloc, electronic sau mecanic, inclusiv fotocopiere sau înregistrare, pentru orice scop, fără permisiunea scrisă a editorului. Addison- WesleyPublicareCompanie, Inc

Toate drepturile rezervate Nicio parte a acestei cărți nu poate fi reprodusă sau transmisă sub nicio formă sau prin orice mijloace, electronice sau mecanice, inclusiv fotocopiere, înregistrare sau prin orice sistem de stocare a informațiilor, fără permisiunea Editorului.

ISBN 5-8459-0138-3 (rusă) isbn 0-201-38590-2 (engleză)

Această carte este dedicată soției mele Lindy și memoriei mamei mele Rima

PARTEA I. CONCEPTE DE BAZĂ 31

Capitolul 2. Arhitectura sistemului de baze de date 65

PARTEA I!. MODEL RELAȚIONAL 149

Capitolul 6. Algebră relațională 192

Capitolul 7. Calcul relațional 243

Capitolul 8: Integritatea datelor 301

Capitolul 9. Vizualizări 350

PARTEIII. PROIECTAREA BAZEI DE DATE 397

Capitolul 10. Dependențe funcționale 400

Capitolul 11. Normalizare ulterioară: formele 1NF, 2NF, ZNF și NFBC 422 Capitolul 12. Normalizare ulterioară: forme normale superioare 469

Capitolul 13. Modelarea semantică 505

PARTEA IV. GESTIUNEA TRANZACȚIILOR 543

Capitolul 14. Recuperare 544

Capitolul 15. Paralelism 566

PARTEA V. ASPECTE SUPLIMENTARE 601

Capitolul 16. Protecția datelor 602

Capitolul 17. Optimizare 639

Capitolul 18. Informații lipsă 693

Capitolul 19. Moștenirea tipului 725

Capitolul 20. Baze de date distribuite 767

Capitolul 21. Sprijin decizional 813

Capitolul 22. Baze de date cronologice 853

Capitolul 23. Sisteme de management al bazelor de date logice 899

PARTEA VI. OBIECTUL ȘI OBIECTUL-RELAȚIONAL

BAZELE DE DATE 943

Capitolul 24. Baze de date cu obiecte 944

Capitolul 25. Baze de date obiect-relaționale 999

APLICAȚII 1027

Anexa A: Expresii SQL 1028

Anexa B: Prezentare generală a limbajului SQL3 1041

Anexa B: Abrevieri și caractere speciale 1058

Prefață la cea de-a șaptea ediție 24

PARTEA I

Concepte de bază 31

Capitolul 1. Baze de date și gestionarea acestora 32

Exemplul introductiv 32

Ce este un sistem de baze de date 35

Hardware 37

Software 38

Utilizatori 39

1.3. Ce este o bază de date 40

Date permanente 40

Entități și relații 41

Proprietăți 43

Date și modele de date 44

1.4. Scopul bazelor de date 45

Administrarea datelor și administrarea bazei de date 46

Beneficiile unei abordări centralizate a gestionării datelor 47

Independența datelor 50

Sisteme relaționale și alte sisteme 56

Rezumat 59 Exerciții 59 Referințe 61 Răspunsuri la unele exerciții 62

Capitolul 2. Arhitectura sistemului de baze de date 65

Introducere 65

Trei niveluri de arhitectură 65

Nivel extern 68

Nivelul conceptual 72

Nivelul intern 73

Afișează 74

Administrator baze de date 74

Sistemul de management al bazelor de date 77

Sistemul de control al comunicațiilor 81

Arhitectura client/server 81

Utilități 83

Procesare distribuită 84

Exerciții 88

Referințe 90

Capitolul 3: Introducere în bazele de date relaționale 92

Introducere 92

Modelul relațional 92

Relații și variabile relaționale 97

Sensul relațiilor 99

Optimizare 101

Catalogul 104

Variabile și vederi relaționale de bază 105

Tranzacții 109

110 baze de date furnizori și piese

3.10. Rezumat 113 Exerciții 115 Referințe 116 Răspunsuri la unele exerciții 117

Capitolul 4: Introducere în SQL 119

Introducere 119

Prezentare generală a limbajului SQL 120

Catalogul 124

Vizualizari 125

Tranzacții 126

Injectarea instrucțiunilor SQL 126

Operații care nu folosesc cursoare 130

Operații folosind cursore 131

SQL dinamic 134

Imperfecțiunile limbajului SQL 136

Rezumat 136 Exerciții 137 Referințe 140 Răspunsuri la unele exerciții 145

PARTEA II

Modelul relațional 149

Capitolul 5. Domenii, relații și variabile relaționale de bază 151

Introducere 151

Domeniile 152

Fiecare valoare este de tip 154

Definiția tipului 155

Reprezentări valabile 156

Definirea operatorilor 159

Conversie de tip 161

Observații finale 162

5.3. Valorile raportului 163

Proprietățile relațiilor 166

Atribute ale căror valori sunt relații 168

Relațiile și interpretarea lor 169

5.4. Variabile relaționale 169

Definirea variabilelor de relație de bază 169

Actualizarea variabilelor de relație 171

5.5. Instrumente SQL 174

Domeniile 174

Tabelele de bază 177

5.6. Rezumat 178 Exerciții 180 Referințe 181 Răspunsuri la unele exerciții 185

Titlu: Microsoft Word - bdc.doc

Previzualizarea documentului

Introducere în sisteme
baze de date

O Introducere la
Sisteme de baze de date
C.J.Date

Boston. San Francisco. New York
Londra. Toronto. Sydney. Tokyo. Singapore. Madrid
Mexico City. Munchen. Paris. Cape Town. Hong Kong. Montreal

Introducere în sisteme

Baze de date
K. J. Data

Moscova. Saint Petersburg. Kiev
2005

№.
BBK 32.973.26-018.2.75
D27
UDC 681.3.07

Editura"William"
Cap editat de S.N. Trigub Traducere din
engleză și editare de K.A. Ptitsyn
Pentru întrebări generale, vă rugăm să contactați Editura William la:
[email protected], http://www.williamspublishing.com
115419, Moscova, PO Box 783; 03150, Kiev, PO Box 152

Data, K.J.
D27

Introducere în sistemele de baze de date, ediția a 8-a: Trad. din engleza — M.: Editura
casa „William”, 2005. - 1328 p.: ill. — Paral. tit. Engleză
ISBN 5-8459-0788-8 (rusă)

Noua ediție a lucrării fundamentale a lui Chris Date este cuprinzătoare
o introducere în teoria acum foarte extinsă a sistemelor de baze de date. Cu asta
Cititorul va putea dobândi cunoștințe fundamentale în domeniul tehnologiei bazelor de date
date, precum și să se familiarizeze cu zonele în care zona luată în considerare
activitățile sunt susceptibile să se dezvolte în viitor. Cartea este destinată a fi folosită
în primul rând ca un manual, mai degrabă decât o carte de referință și, prin urmare, va fi, fără îndoială, de interes pentru
programatori profesionisti,
științific
muncitorii
Și
elevi,
studiu
cursuri relevante în instituțiile de învățământ superior. Se concentrează pe înțelegerea esenței și
înțelegerea profundă a materialului prezentat și nu doar prezentarea formală a acestuia.
Cartea va fi cu siguranță utilă oricui trebuie să lucreze cu baze de date sau
foloseste-le doar.
BBK 32.973.26-018.2.75
Toate numele produselor software sunt înregistrate mărci comerciale companiile relevante.
Nicio parte a acestei publicații nu poate fi reprodusă în niciun scop.
sub orice formă sau prin orice mijloace, electronice sau mecanice, inclusiv fotocopiere și înregistrare pe suport magnetic, cu excepția cazului în care se acordă permisiunea scrisă a editorului
Compania de editură Addison-Wesley, Inc.
Traducere autorizată din ediția în limba engleză publicată de Addison-Wesley, Copyright 2004
Toate drepturile rezervate. Nicio parte a acestei cărți nu poate fi reprodusă sau transmisă sub nicio formă sau prin niciun mijloc,
electronice sau mecanice, inclusiv fotocopiere, înregistrare sau prin orice sistem de recuperare de stocare a informațiilor,
fără permisiunea Editorului.
Ediție în limba rusă publicată de Editura Williams conform Acordului cu R&I
Enterprises International, Copyright 2005
ISBN 5-8459-0788-8 (rusă)
ISBN 0-321-19784-4 (engleză)

Editura „William”, 2005
de Pearson Education, Inc., 2004

Prefață la ediția a opta

PARTEA I. CONCEPTE DE BAZĂ

Capitolul 4: Introducere în SQL

PARTEA II. MODEL RELAȚIONAL

Capitolul 5. Tipuri

Capitolul 6. Relații

Capitolul 7. Algebră relațională

Capitolul 9. Integritatea datelor

Capitolul 10. Vizualizări

PARTEA III. PROIECTAREA BAZEI DE DATE

Capitolul 11. Dependențe funcționale

Capitolul 12. Normalizare ulterioară: formele 1NF, 2NF, ZNF și NFBK

Capitolul 13. Normalizare ulterioară: formele normale sunt mai multe
ordin înalt

Capitolul 14. Modelare semantică

PARTEA IV. MANAGEMENTUL TRANZACȚIILOR

Capitolul 15. Recuperare

Capitolul 16. Paralelism

PARTEA V. SUBIECTE SUPLIMENTARE

Capitolul 17. Protecția datelor

Capitolul 18. Optimizare

Capitolul 19. Informații lipsă

Capitolul 20. Moștenirea tipului

Capitolul 21. Baze de date distribuite

Capitolul 22. Suport decizional

Capitolul 23. Baze de date istorice

Capitolul 24. Sisteme logice de gestionare a bazelor de date

PARTEA VI. OBIECTE, RELATII SI LIMBAJ XML

Capitolul 25. Baze de date cu obiecte

Capitolul 26. Baze de date obiect-relaționale

Capitolul 27. World Wide Web și XML

PARTEA VII. APLICAȚII

Anexa A: Modelul TransRelational™

Anexa B: Expresii SQL

Anexa B: Abrevieri și caractere speciale

Anexa D. Structuri de stocare și metode de acces

Anexa E. Răspunsuri la exerciții individuale

Index de subiect

29
31
31
31
32
33
34
35
37
37
39

PARTEA I. CONCEPTE DE BAZĂ

Capitolul 1. Baze de date și gestionarea acestora
1.1 Exemplu introductiv
1.2 Definiția generală a unui sistem de baze de date
Date
Hardware
Software
Utilizatori
1.3.Definiția generală a unei baze de date
Date permanente
Entități și relații
Proprietăți
Date și modele de date

43
43
46
47
49
49
50
51
51
52
55
56

1.4.Scopul bazelor de date
Administrarea datelor si administrarea bazei de date
Beneficiile abordării bazei de date
1.5 Independenta datelor
1.6 Sisteme relaționale și alte sisteme
1.7 Rezumat
Exerciții

58
59
59
62
68
71
72

Bibliografie

Capitolul 2. Arhitectura sistemului de baze de date

2.1 Introducere
2.2 Trei straturi de arhitectură
2.3 Nivel extern
2.4 Nivel conceptual
2.5 Nivel intern
2.6 Afișări
2.7 Administrator baze de date
2.8 Sistem de management al bazelor de date
2.9 Sistem de control al transmiterii datelor
2.10 Arhitectura client/server
2.11 Utilități
2.12 Prelucrare distribuită
2.13 Rezumat
Exerciții
Bibliografie

75
76
79
82
83
84
85
87
91
92
94
95
99
100
101

Capitolul 3: Introducere în bazele de date relaționale
3.1 Introducere
3.2 Model relațional
Definiție mai formală
3.3 Relații și relații variabile
3.4 Sensul relațiilor
3.5 Optimizare
3.6 Catalog
3.7 Variabile de bază relaționale și de reprezentare
3.8 Tranzacții
3.9 Baza de date furnizori și piese
3.10 Rezumat
Exerciții
Bibliografie

103
103
103
108
109
111
114
116
117
122
123
125
127
128

Capitolul 4: Introducere în SQL
4.1.introducere
4.2.Prezentare generală asupra limbajului SQL
4.3.Catalog
4.4.Vizualizări
4.5.Tranzacții
4.6.Injectarea instrucțiunilor SQL
Operații care nu folosesc cursoare
Operații care folosesc cursoare
Limbajul SQL dinamic și interfața SQL/CLI
4.7.Imperfecțiunile limbajului SQL
4.8.Rezumat
Exerciții
Bibliografie

133
133
135
138
139
140
140
144
145
148
152
152
153
155

Conţinut
PARTEA II. MODEL RELAȚIONAL
Capitolul 5. Tipuri
5.1 Introducere
5.2 Definirea valorilor și variabilelor
Tastarea valorilor și variabilelor
5.3 Definiții ale tipurilor și formatelor de prezentare
Definiții ale tipurilor scalare și nescalare
Formate de reprezentare posibile, selectoare și operatori THE_
5.4 Definirea tipului
5.5 Operatori
Conversii de tip
Concluzii finale
5.6 Generatoare de tip
5.7 Instrumente SQL
Tipuri încorporate
Tipuri DISTINTE
Tipuri structurate
Tip Generatoare
5.8. rezumat
Exerciții
Bibliografie
Capitolul 6. Relații
6.1 Introducere
6.2 Tupluri
Proprietățile tuplurilor
Generator de tip TUPLE
Operații cu tupluri
Comparația tipurilor de tuplu și reprezentările posibile
6.3.Tipuri de relaţii
Tip generator RELATION
6.4.Semnificaţiile relaţiilor
Compararea relațiilor și a tabelelor
Atribute cu valori relaționale
Relații fără atribute
Operații cu relații
6.5. Relaţii variabile
Definirea unei variabile de relație de bază
Actualizarea variabilelor de relație
Variabilele de raport și interpretarea lor
6.6.Instrumente SQL
Siruri de caractere
Tipuri de tabele
Valori și variabile de tabel
Tipuri structurate
6.7.Rezumat
Exerciții
Bibliografie

163
165
165
167
168
169
170
170
175
178
181
183
184
186
186
188
191
194
196
198
200
201
201
201
203
203
204
206
207
209
209
212
214
216
217
219
219
221
224
225
225
226
227
229
232
234
236

Cuprins

Capitolul 7. Algebră relațională
7.1. Introducere
7.2. Mai multe informații despre proprietatea de închidere relațională
7.3. Algebră originală - sintaxă
7.4. Algebră originală - semantică
O asociere
Intersecție
Diferență
Muncă
Reducere
.
Proiecție
Compus
Divizia
7.5. Exemple
7.5.1 Determinați numele furnizorilor care furnizează piesa P2
7.5.2. Determinați numele furnizorilor care furnizează mai puțin.
cel puțin un detaliu roșu
7.5.3 Determinați numele furnizorilor care furnizează toate piesele
7.5.4. Determinați numărul de furnizori care furnizează cel puțin
toate piesele furnizate de furnizorul S2
7.5.5 Determinați toate perechile de numere de furnizori astfel încât furnizorii în cauză să fie localizați în același oraș
7.5.6. Determinați numele furnizorilor care nu furnizează partea P2
7.6 Scop general algebră
7.7 Câteva note suplimentare
Asociativitatea și comutativitatea
Câteva echivalențe
Câteva generalizări
7.8.Operatii suplimentare
Semi-ună
Jumătate de diferență
Extensie
Agregare
Închidere tranzitivă
7.9 Gruparea și degruparea
7.10.Rezumat
Exerciții
Exerciții de scriere interogare
Bibliografie
Capitolul 8. Calcul relațional
8.1. Introducere
8.2. Calcul tuplu
Sintaxă
Variabile de interval
Liber și legat domeniul de aplicare variabil sens
Cuantificatori

241
241
244
246
249
249
250
251
251
252
254
255
258
260
260
261
261
261
261
262
263
265
265
266
266
267
268
268
268
272
275
276
279
281
282
285
289
289
291
291
293
294
295

Conţinut
Mai multe informații despre variabilele libere și legate
297
Operații relaționale
298
8.3. Exemple
300
8.3.1 Determinați numărul de furnizori din Paris cu un statut mai mare de 20.300
8.3.2 Găsiți toate perechile de numere ale unor astfel de furnizori care sunt localizați
într-un oraș (repetarea exemplului 7.5.5)
300
8.3.3 Obține informații complete despre furnizorii cu numărul de piesă P2
(versiunea modificată a exemplului 7.5.1)
301
8.3.4 Determinați numele furnizorilor pentru cel puțin o parte
roșu (repetați exemplul 7.5.2)
301
8.3.5. Găsiți numele furnizorilor de cel puțin o parte,
furnizate de furnizor cu numărul S2
302
8.3.6.Obțineți numele furnizorilor de toate tipurile de piese
(repetarea exemplului 7.5.3)
302
8.3.7 Determinați numele furnizorilor care nu furnizează piesa.
cu numărul P2 (repetarea exemplului 7.5.6)
302
8.3.8. Determinați numerele furnizorilor pentru cel puțin acele piese care
furnizat de furnizor cu numărul S2 (repetarea exemplului 7.5.4)
302
8.3.9. Obțineți numere de piese care cântăresc mai mult de 16 lire sunt furnizate
numărul furnizorului S2 sau să îndeplinească ambele condiții 303
8.4 Analiza comparativă a calculului relațional și algebrei relaționale
303
8.5 Capacități de calcul
308
8.5.1. Determinați numerele și greutatea în grame ale tuturor tipurilor de piese,
a căror greutate depășește 10.000 g
309
8.5.2. Selectați informații despre toți furnizorii și desemnați fiecare dintre aceștia
valoarea literală „Furnizor”
309
8.5.3. Obțineți informații complete despre fiecare livrare, inclusiv generale
greutatea de livrare
309
8.5.4. Pentru fiecare parte, obțineți numărul piesei și volumul total al livrării.
in bucati
309
8.5.5. Determinați numărul total de piese furnizate
309
8.5.6. Pentru fiecare furnizor, obțineți numărul furnizorului și volumul total
livrari pe bucati
309
8.5.7. Indicați numele orașelor în care sunt depozitate piesele, ce se află în ele
sunt mai mult de cinci părți roșii
309
8.6.
Instrumente de limbaj SQL
309
8.6.1. Specificați culorile pieselor și numele orașelor pentru părțile care au
peste 10 lire și depozitate în alte orașe decât Paris
310
8.6.2. Pentru toate piesele, indicați numărul piesei și greutatea în grame (simplificat
exemplu versiunea 8.5.1)
312
8.6.3. Obțineți toate combinațiile de date despre furnizor și piese,
situat in acelasi oras
313
8.6.4. Găsiți toate perechile de nume de orașe, astfel încât furnizorul le-a localizat
în primul oraș, furnizează o piesă depozitată în al doilea oraș 313
8.6.5. Obțineți toate perechile de numere de furnizor, astfel încât ambii furnizori
fiecare pereche conține un oraș de apă (vezi exemplul 8.3.2)
314
8.6.6. Determinați numărul total de furnizori
314

8.6.7. Determinați numărul maxim și minim de piese
cu numărul P2
315
8.6.8. Pentru fiecare piesă furnizată, vă rugăm să indicați numărul piesei și volumul total.
livrări în bucăți (versiunea modificată a exemplului 8.5.4)
315
8.6.9. Determinați numerele de piesă ale tuturor pieselor furnizate de mai mult de una
furnizor
316
8.6.10. Determinați numele furnizorilor de piese cu numărul P2
(vezi exemplul 7.5.1)
316
8.6.11. Determinați numele furnizorilor pentru cel puțin o parte

317
8.6.12. Determinați numărul de furnizori cu un statut mai mic decât acesta
care este în prezent maximul din tabelul S
317
8.6.13. Determinați numele furnizorilor de piese cu numărul P2
317
8.6.14. Determinați numele furnizorilor care nu furnizează piesa
cu numărul P2 (exemplu 8.3.7)
318
8.6.15. Determinați numele furnizorilor care furnizează piese

318
8.6.16. Identificați numerele de piese care fie cântăresc mai mult de 16 lire sau
furnizate de furnizor cu numărul S2 sau corespund acestuia
și o altă condiție (vezi exemplul 8.3.9)
319
8.6.17. Determinați numărul piesei și greutatea în grame pentru fiecare parte
cu o greutate > 10.000 g (vezi exemplul 8.5.1)
320
8.7. Calcul domeniului
321
8.7.1. Determinați numărul furnizorilor din Paris cu un statut mai mare de 20
(versiunea simplificată a exemplului 8.3.1)
322
8.7.2. Găsiți toate perechile de numere de furnizor în care există doi furnizori
sunt în același oraș (vezi exemplul 8.3.2)
322
8.7.3. Determinați numele furnizorilor pentru cel puțin o parte
roșu (vezi exemplul 8.3.4)
322
8.7.4 Determinați numele furnizorilor care furnizează cel puțin un tip
piese furnizate de furnizor cu numărul S2 (vezi exemplul 8.3.5) 323
8.7.5. Determinați numele furnizorilor care furnizează piese
toate tipurile (vezi exemplul 8.3.6)
323
8.7.6. Determinați numele furnizorilor care nu furnizează piesa
cu numărul P2 (vezi exemplul 8.3.7)
323
8.7.7. Determinați numărul de furnizori care furnizează,
cel puțin piese de toate tipurile furnizate
furnizor cu numărul S2 (vezi exemplul 8.3.8)
323
8.7.8. Obțineți numere de piese care fie cântăresc mai mult de 16 lire sau
furnizate de furnizor cu numărul S2, sau conform
ambele condiții (vezi exemplul 8.3.9)
323
8.8. Exemplu de limbaj de interogare
323
8.8.1. Determinați numărul furnizorilor aflați în Paris care
au statut > 20 (exemplul 8.7.1)
324
8.8.2. Determinați numărul tuturor pieselor furnizate, eliminându-le pe cele inutile
duplicate
325

Conţinut
13
8.8.3. Primește numere și informații despre starea furnizorilor localizați
la Paris prin prima sortare în ordine descrescătoare
stare și apoi în ordinea crescătoare a numerelor
325
8.8.4. Obține numere și date de stare ale furnizorilor care fie
sunteți în Paris, sau au un statut > 20, sau se întâlnesc
ambele condiții (versiunea modificată a exemplului 8.8.1)
326
8.8.5. Identificați părțile a căror greutate este între 16
până la 19 inclusiv
326
8.8.6. Pentru toate piesele, determinați numărul piesei și greutatea părții în grame
(exemplu 8.6.2)
326
8.8.7. Determinați numărul furnizorilor care furnizează piesa