Definiția key fields.

Masa

Acesta este un termen care este folosit foarte des în FoxPro și este adesea folosit într-un mod care nu este deloc înțeles de către nou-veniți. Putem spune că acest termen are două definiții (cum ar fi termenul „bază de date”)

Masa este un fișier cu extensia DBFși fișiere înrudite cu același nume, dar cu extensia FPT(un fișier pentru stocarea câmpurilor precum Notă și general) și cu extensia CDX(fișier index structural)

Formal, asta este absolut definiție corectă. Singura problemă este că în marea majoritate a cazurilor când FoxPro folosește termenul "masa", atunci nu este deloc ceea ce se înțelege prin asta. Mai precis, nu chiar asta.

Masa- acesta este un cert imagine de fișier cu extensie DBF deschis în specificat sesiuni de date iar în cele specificate Zona de lucru.

Având dorința americanilor de a tăia totul, nu s-au obosit să vină cu un termen potrivit. Prin urmare, apare constant confuzia. Ar fi mai potrivit să se folosească în locul termenului "masa" termeni "cursor" sau "alias", pentru că reflectă mai exact esența. Și într-adevăr, în unele cazuri acești termeni sunt folosiți tocmai în acest sens, ceea ce nu face decât să încurce complet totul, deoarece sunt folosiți și în alte sensuri.

Alias (alias) - Acest Fișier DBF „alias” deschis în orice Zona de lucru. De obicei, aliasul se potrivește cu numele fișierului DBF. Cu toate acestea, acest lucru nu este întotdeauna cazul. Faptul este că într-o sesiune de date nu pot exista două aliasuri identice. Prin urmare, dacă aliasul tabelului nu este specificat în mod explicit la deschiderea acestuia (opțiunea ALIAS din comanda USE sau într-un alt mod), atunci FoxPro va atribui automat un alias unic pentru tabel, începând, desigur, cu un alias care se potrivește cu numele fișierului DBF, dacă este posibil.

Ține minte că în mod absolut În cele mai multe cazuri sub termenul "masa" exact ce se înțelege "imagine de fișier", adică fișierul este deja deschis prin comanda USE (sau altă metodă) în mediul FoxPro. Dacă este vorba despre un fișier DBF, atunci, de regulă, acest lucru este specificat în mod specific.

În versiunile FoxPro 2.x, așa cum este folosit termenul "masa" termen folosit "Bază de date"(se pare că de aici a venit extensia - primele litere ale frazei engleze Fișierul bazei de date), deoarece fișierul DBC nu exista încă în versiunile respective. În consecință, atunci când programatorii trec la versiunea Visual FoxPro, poate fi destul de dificil să le înțelegi din cauza acestei confuzii cu termenii.

Ar trebui să vă amintiți întotdeauna că mesele se deschid în așa-numita "spații de lucru". Ce este asta nu este explicat clar nicăieri (ei spun că este deja clar). Voi încerca să o definesc așa

Spațiul de lucru (Zona de lucru) este un identificator numeric care poate fi atribuit unui tabel. Dacă ai avut experiență de programare în alte limbi, atunci poți spune că spațiul de lucru este „ mâner" sau " descriptor" tabelele din mediul FoxPro

Doar un singur tabel poate corespunde unui singur spațiu de lucru la un moment dat, în timp ce mai multe spații de lucru pot corespunde unui singur tabel. Cu alte cuvinte, aceeași masă Poate fi deschis simultan în mai multe spații de lucru, dar un singur tabel poate fi deschis într-un anumit spațiu de lucru.

Până când tabelul este deschis în orice spațiu de lucru, acesta nu pare să existe pentru FoxPro. Mai precis, nu puteți efectua nicio operațiune de citire/modificare a datelor cu ajutorul comenzilor și funcțiilor standard.

Pe lângă conceptul de „spațiu de lucru”, FoxPro a introdus conceptul "sesiune de date" (DataSession)

Sesiune de date- aceasta este o copie dinamică a mediului FoxPro. Prin deschiderea mediului FoxPro, deschideți automat o sesiune de date, care se încheie automat când părăsiți FoxPro. Dar în interiorul FoxPro însuși aveți posibilitatea de a face o copie a mediului FoxPro folosind așa-numitul „sesiuni de date private”

Ce oferă asta mai exact? „sesiuni de date private”? Și acest lucru face posibilă simularea muncii mai multor utilizatori, independenti unul de celălalt, în cadrul unei singure aplicații FoxPro.

Ca urmare, tabelele deschise într-o sesiune de date sunt „nu sunt vizibile” în altă sesiune de date. Și, în consecință, manipulările (nu toate) efectuate cu tabele într-o sesiune de date nu afectează alte sesiuni de date.

Cel mai frecvent caz de utilizare Sesiune de date privată- este deschiderea simultană a mai multor formulare cu care se vizualizează același document laturi diferite. De regulă, în acest scop, se stabilește o relație între tabele prin SETARE RELATIE. Dacă deschideți astfel de formulare într-o singură sesiune de date, aceasta devine adesea o mare problemă, deoarece într-un formular trebuie să aplicați niște indici și relații la tabele, iar în alta - altele. Iar trecerea de la o formă la alta are ca rezultat modificări imprevizibile ale conținutului.

Numele tabelului

Un fișier tabel, ca orice alt fișier dintr-un sistem Windows, poate conține până la 128 de caractere, poate conține spații, caractere rusești, numere și unele caractere speciale. Cu toate acestea, pentru a face lucrul în FoxPro mai ușor, aș recomanda următoarele restricțiiîn numele fișierului tabel

Nu folosiți caractere rusești în nume - motivul acestei recomandări este că FoxPro a fost dezvoltat în primul rând pentru utilizatorii vorbitori de limba engleză, iar utilizarea caracterelor dintr-o altă limbă este o adăugare ulterioară. Ca urmare, există un risc mare ca ceva, undeva, să fie trecut cu vederea și, în anumite situații, literele rusești din nume vor cauza erori neașteptate.

Nu folosiți spații în nume - în principiu, utilizarea spațiilor nu va provoca erori, dar va complica oarecum procesul de programare în sine, deoarece numele și căile de acces care conțin spații trebuie să fie cuprinse între ghilimele. Va adăuga doar o îngrijorare suplimentară - nu uitați de ghilimele. De ce să-ți complici viața când te poți descurca cu ușurință fără ea.

Limitați lungimea numelui la 8 caractere și nu utilizați numere și caractere speciale în nume - spre deosebire de recomandarea similară referitoare la numele fișierului Bază de date există un motiv pentru asta. Motivul nu este atât de evident încât poate fi descris pe scurt. Dar lanțul de raționament care a condus la această recomandare se bazează pe recomandarea de numire câmpuri cheie tabele și nume de etichete de index. După ce ați citit aceste secțiuni veți înțelege motivul acestei recomandări.

Nu folosiți unul dintre cuvintele rezervate în FoxPro pentru nume - din nou, acest lucru nu va provoca erori, dar va reduce drastic „lizibilitatea” codului. La urma urmei, cuvintele rezervate sunt evidențiate automat într-o anumită culoare (dacă utilizați standardul editor de text FoxPro) și imediat devine dificil să distingem o opțiune sau o comandă de numele unui tabel

Nu utilizați aliasuri de tabel în interiorul bazei de date - în în acest caz, Ceea ce vorbim este că în interiorul bazei de date puteți atribui unui tabel un alias care este diferit de numele fișierului DBF. Vorbire nu merge despre optiune ALIASîntr-o echipă UTILIZARE. Acest lucru este oarecum diferit. Dacă intri în modul de modificare a structurii tabelului și mergi la fila "Masa", atunci veți vedea asta în opțiune "Nume" numele este același cu numele fișierului DBF. Acesta este numele care poate fi schimbat prin atribuirea unui anumit nume tabelului "poreclă" care va fi folosit pentru a accesa tabelul specificat. Personal, nu aș recomanda utilizarea unor astfel de pseudonime pentru începători, deoarece poate provoca confuzie în procesul de programare în sine.

Locația mesei

Atât pentru fișierul bazei de date, cât și în general pentru toate tabelele de lucru utilizate în proiect, ar trebui să selectați folder special(director). Această recomandare se aplică atât fazei de dezvoltare a proiectului, cât și livrării aplicației finite către clienți.

Motivele acestei recomandări sunt detaliate în secțiune Unde să plasați fișierele de proiect. Pe scurt, ideea este că, în caz contrar, crește riscul coruperii neintenționate a fișierelor de date și, în consecință, pierderea datelor. De asemenea, ușurează căutarea fisierele necesareși creație copie de rezervă.

Este recomandabil să plasați fișierul bazei de date în același folder cu fișierele DBF incluse în acesta

De în general, desigur, puteți păstra fișierul bazei de date într-un director și fișierele DBF incluse în altul. Dar acest lucru complică procesul de dezvoltare a proiectului în sine. De exemplu, crearea unei copii de rezervă în cel mai simplu caz este copiere simplă directoare cu fișiere de lucru în altă locație. Dacă fișierele de lucru sunt separate de fișierul bazei de date, atunci va fi necesară copierea a 2 directoare. Codul va deveni mai complex în consecință.

În plus, în acest caz dimensiunea fișierului bazei de date va crește ușor ( mai precis un dosar DCT - fișier memo), deoarece stochează direct cale relativă la tabelele incluse în acesta. Dacă tabelele sunt situate în același director cu fișierul bazei de date în sine, atunci această cale relativă pur și simplu nu există. Pentru a fi corect, trebuie remarcat faptul că calea relativă către baza de date este stocată și în anteturile tabelelor care sunt incluse în această bază de date. Dar acest lucru nu afectează dimensiunea tabelelor, deoarece un spațiu fix este întotdeauna alocat pentru această cale relativă, indiferent de faptul că există.

De fapt lucrez cu mese

La obiect Grilă la specificarea unei valori pentru RecordSourceType sub termenul "masa" (Masa)înseamnă exact fișierul DBF, iar sub termenul "alias" (Alias)- imagine de fișier. Ce cauzează o cantitate mareîncepătorii au probleme cu acest obiect. În niciun caz nu folosi la fel de RecordSourceType indicaţie "Masa"- acest lucru va duce la un comportament imprevizibil al acestui obiect. Lăsați valoarea implicită "Alias"

După cum s-a menționat mai sus, tabelele sunt întotdeauna deschise într-un anumit spațiu de lucru și pentru a merge la spațiul de lucru dorit există 2 moduri de adresare: fie după numărul acestui spațiu de lucru, fie după numele alias-ului tabelului deschis în acest spațiu de lucru.

Motivul acestei recomandări este că unui anumit spațiu de lucru nu îi pasă deloc masa este deschisă în el. Și în anumite condiții, masa poate fi redeschisă, dar într-un alt spațiu de lucru. În consecință, atunci când vă adresați unui spațiu de lucru după numărul său, este imposibil să fiți complet sigur că exact ceea ce este deschis în el tabelul necesar. Și, în general, că cel puțin o masă este deschisă în ea. Pe de altă parte, accesarea prin alias este mai probabil să indice tabelul dorit (pot exista și opțiuni aici, dar acestea sunt cazuri mai exotice)

Este extrem de nedorit să se modifice dinamic tabelele în timpul funcționării sau să se adauge/elimină tabele din baza de date. Acest lucru este asociat cu probleme mari și complicații semnificative ale codului programului.

Zona de lucru numerotata 0

Mențiune specială merită zona de lucru zero. O referire la spațiul de lucru zero înseamnă o referire la primul spațiu de lucru liber. Acestea. zona de lucru, care este în prezent nu este asociat cu niciun tabel

Această adresare vă permite să faceți mai multe lucruri

În primul rând, vă permite să deschideți noi mese fără să vă faceți griji dacă spațiul de lucru actual este ocupat de un alt tabel. Acestea. se dă o comandă a formei

UTILIZAȚI MyTable ÎN 0

Specificarea unui spațiu de lucru de zero este necesară deoarece, altfel, tabelul va fi deschis în spațiul de lucru curent în timp ce se închide orice tabel care ar putea fi deschis în acesta. Și în această sintaxă deschiderea masa noua nu va afecta precedentul mese deschise

O altă utilizare a spațiului de lucru nul este setările implicite.

De exemplu, probabil că știți deja că oricare Vedere implicit se deschide în mod tamponare optimistă de rând (3), dar dacă trebuie să-l utilizați în mod tamponare optimistă a tabelului (5), apoi după deschidere trebuie să faceți această comutare folosind funcția CursorSetProp() ca asta

Adevărat, astfel de setări globale trebuie utilizate cu prudență, deoarece sunt doar globale, de exemplu. valabil pentru toate zonele de lucru fara exceptie.

De asemenea, voi observa că setarea globală a spațiului de lucru zero nu va afecta spațiile de lucru care au deja tabele deschise. Afectează doar spațiile de lucru care nu sunt încă utilizate.

Masa mare

Foarte des în conferințe apare expresia "masă mare" .

Aș spune că conceptul "masă mare" foarte subiectiv. Conform observațiilor mele, în cele mai multe cazuri, prin „mare” înțelegem un tabel ale cărui operații de citire/scriere durează o perioadă de timp vizibilă. Vizibil pentru utilizator.

Unul dintre cele mai importante criterii Un factor care afectează timpul de execuție al oricărei operațiuni pe un tabel este numărul de înregistrări din acel tabel. Dar atunci apare întrebarea: un tabel mare este câte înregistrări există?

Numărul maxim permis de înregistrări care pot fi conținute într-un tabel este 1 miliard de înregistrări. Acestea. unu și nouă zerouri. Asa de, "mare" poate fi considerat un tabel care contine cel putin câteva milioane de înregistrări.

Dar, din nou, termenul „mare” apare nu atunci când se estimează pur și simplu numărul de înregistrări, ci când se estimează timpul de execuție a anumitor operațiuni cu astfel de tabele. Dar există multe motive care afectează timpul de citire/scriere. În consecință, tabelul care este considerat „mare” într-un caz nu este atât de „mare” în altul.

Încă o dată, îmi amintesc de lenea americanilor și de dorința lor de a reduce totul (totuși, rușii au mers și mai departe aici - pot spune aproape totul folosind doar câteva cuvinte specifice). Termen "cursor" folosit în mai multe sensuri în funcţie de context.

Cursor- aceasta este imaginea fișierului DBF deschisîntr-una din zonele de lucru

Cursor- acesta este un tabel temporar rezultat din executarea comenzii Selectați-SQL

Cursor- Acest indicator Poziția indicatorului de introducere a textului de la tastatură

Ei bine, ultima definiție nu este foarte interesantă. În sensul că aici totul este clar, cu excepția motivului pentru care acest termen a fost folosit și pentru tabelele temporare, pentru că cuvântul "cursor" de fapt tradus ca "indicator".

Cursorul ca imagine de fișier DBF

Din nou asta scurtă definiție nu este în întregime exactă, deoarece în acest sens este folosit un obiect specific. Introducerea acestui obiect se explică prin nevoia de vizualizare Mese la proiectarea formularelor și rapoartelor.

Voi observa, de asemenea, că cursorul, ca obiect, este folosit nu doar ca imagine fișiere dbf, dar și ca imagine Vedere. Și Vedere și masă - nu este acelasi lucru.

Cursorul ca tabel temporar

Aceasta este cea mai comună utilizare a acestui termen. De fapt, există 2 moduri de a crea astfel de cursoare

Prima cale este utilizarea comenzii CREAȚI CURSOR. Cursorul creat în acest fel va fi editabil. Și acesta va fi o masă temporară, adică. va fi distrus automat în momentul închiderii. Ei bine, nu sunt multe de spus despre această metodă. Nu există probleme sau particularități aici

A doua cale- aceasta este utilizarea opțiunii CURSORîntr-o echipă SELECT-SQL. Ceva de genul următoarei sintaxe

SELECTAȚI * DIN MyTable ÎN CURSOR TmpTable

Acesta este TmpTable cursor

Depinzând de diverse conditii acest cursor poate avea diferite „încarnari” fizice și proprietăți diferite

Dacă interogarea SQL este complet optimizată, atunci, în loc de a crea un fișier nou, se va deschide pur și simplu același tabel cu un filtru aplicat. Aceasta este adesea o surpriză foarte neplăcută. Puteți verifica care este cursorul generat fizic folosind funcția DBF().

SELECTAȚI * DIN MyTable ÎN CURSOR TmpTable ?DBF ("TmpTable")

Dacă este returnat un nume de fișier cu o extensie DBF, atunci acest cursor este același tabel sursă cu un filtru aplicat.

Dacă doriți să vă asigurați pentru orice interogări că cursorul este un tabel temporar și nu tabelul original cu un filtru aplicat, atunci ar trebui să adăugați opțiunea FĂRĂ FILTRU

SELECTAȚI * DIN MyTable ÎN CURSOR TmpTable NOFILTER

A apărut această opțiune numaiîn versiunea 5 a Visual FoxPro, deși nu a fost încă documentat acolo. În versiunile anterioare, este necesar să adăugați condiții fictive sau caracteristici de grupare pentru a elimina posibilitatea de optimizare.

Cu toate acestea, dacă cursorul este masa temporara, asta nu înseamnă că acest tabel temporar va fi neapărat localizat fizic pe disc. Este foarte posibil ca întreaga masă temporară să se potrivească în întregime RAM. Acestea. funcţie DBF ("TmpTable") va arăta corect unele fișier temporar, dar o încercare de a-l găsi fizic pe disc va eșua și funcția FILE(DBF("TmpTable")) va reveni .F.

Adevărat, locația întregului tabel temporar în memorie nu va interfera în niciun fel cu lucrul cu acest tabel temporar. De fapt, în majoritatea covârșitoare a cazurilor, nu ar trebui să vă pese unde este situat fizic acest tabel.

O altă problemă importantă este legată de faptul că cursoarele obținute în acest fel nu pot fi editate. Sunt doar pentru citire. Începând cu versiunea 7 a Visual FoxPro, a existat o soluție la această problemă: opțiune specială Citeste, scrie

SELECTAȚI * DIN MyTable ÎN CURSOR TmpTable NOFILTER READWITE

Utilizarea acestei opțiuni vă permite să creați un cursor care poate fi editat. Pentru versiunile inferioare ale FoxPro, pentru ca cursorul să fie editat, acesta trebuie redeschis

SELECTAȚI * DIN MyTable ÎN CURSOR TmpReadTable NOFILTER USE (DBF ("TmpReadTable")) ÎN 0 DIN NOU ALIAS TmpWriteTable USE IN TmpReadTable

Cursorul a redescoperit în acest fel TmpWriteTable acum poți edita

Cursoarele pot fi indexate la fel ca tabelele obișnuite. Cu toate acestea, dacă cursorul este deschis în modul numai citire, atunci puteți crea o singură etichetă index pentru el.

Toate cursoarele create în acest fel sunt șterse automat de pe disc (dacă fișierul temporar a fost creat fizic pe disc) atunci când sunt închise. Dacă ați creat o structură structurală pentru un astfel de cursor fișier index, atunci și acest fișier va fi șters automat când cursorul este închis.

Formarea numelui cursorului în comanda Select-SQL

Aceasta nu este o întrebare atât de simplă pe cât ar părea. Problema aici este că numele cursorului este de fapt un alias pentru tabelul temporar. Dar în FoxPro, 2 tabele cu aceleași aliasuri nu pot fi deschise într-o singură sesiune de date.

Cursorul este întotdeauna creat pe computerul clientului, deci nu este nevoie să vă faceți griji în legătură cu conflictele cu alți utilizatori. Mai mult, chiar dacă același proiect este lansat de două ori pe aceeași mașină, tot nu va exista niciun conflict asociat aceleasi nume cursoare deoarece sunt deschise în diferite sesiuni de date. Este posibil un conflict dacă creați mai multe cursoare cu același nume în aceeași sesiune de date

Ei bine, de exemplu, ai deschis 2 formulare folosind DataSession implicită iar în ambele au creat un cursor cu același nume. În acest caz, cursorul creat mai târziu va suprascrie cursorul creat mai devreme. În acest caz, setarea SETARE SIGURANȚA nu joacă niciun rol. Cursorul va fi recreat în tăcere. Fără solicitări suplimentare.

Există mai multe modalități de a evita astfel de conflicte

Deschideți formulare și rapoarte numai în Private DataSession

Monitorizați în mod independent unicitatea numelor cursorului

Utilizați funcția pentru a genera nume de fișiere unice
Ultima opțiune pare a fi cea mai preferată. Totuși, aici ar trebui să fii atent. Faptul este că în descrierea lui FoxPro se propune utilizarea următoarei funcții pentru a genera nume de fișiere unice

lcCursorName=SubStr (SYS (2015),3,10)

Problema este că funcția SYS(2015) poate conține atât litere, cât și cifre în valoarea returnată. Aceasta înseamnă că atunci când utilizați SubStr() pentru a selecta un șir, este posibil să ajungeți cu un număr ca prim caracter. Și folosirea unei cifre ca nume de variabilă în sintaxa FoxPro este inacceptabilă și veți primi în mod neașteptat un mesaj despre eroare de sintaxă. Pentru a evita acest lucru, ar trebui fie să amestecați cu forță litera

În consecință, executarea cererii va arăta astfel:

LOCAL lcCursorName lcCursorName=SYS (2015) SELECT * FROM MyTable INTO CURSOR &lcCursorName NOFILTER

Această metodă de a crea nume unice de cursore va asigura într-adevăr unicitatea, dar aceasta este o metodă foarte incomodă din cauza necesității de a utiliza în mod constant substituții de macro atunci când accesați un astfel de cursor. Prin urmare, este indicat să o evitați dacă este posibil.

Câmpuri de tabel

Un câmp de tabel este o coloană pe care o vedeți de fiecare dată când deschideți tabelul pentru vizualizare.

Numele câmpurilor de tabel

Câmpul tabelului inclus în (baza de date) poate conține până la 128 de caractere, conține caractere rusești, numere și unele caractere speciale. Cu toate acestea, pentru a simplifica munca în FoxPro, aș recomanda următoarele restricții în numele fișierului tabel

Nu utilizați numere și caractere speciale în nume - în principiu, utilizarea numerelor și a caracterelor speciale nu va provoca erori. Motivul acestei recomandări este creșterea dificultății de înțelegere a numelui.

Ei bine, de exemplu, dacă în tabel trebuie să indicați suma plății și suma taxei, atunci desigur puteți crea 2 câmpuri Platezh1Și Platezh2. Dar, în acest caz, de fiecare dată va trebui să vă amintiți ce înseamnă de fapt numărul 1 și ce înseamnă de fapt numărul 2. Dacă lucrați în mod constant cu un singur proiect, atunci aceasta nu este o problemă, amintiți-vă cumva. Dar dacă lași acest proiect deoparte și te-ai întors la el câteva luni mai târziu, atunci gânduri intense pe această temă - ce este mai exact? - Ai acoperit totul. Este mult mai înțelept să dăruiești nume semnificative: PlatezhȘi Nalog

Dacă creați o etichetă index simplă pentru un anumit câmp, a cărei expresie constă numai din numele câmpului, atunci limitați numele câmpului la 10 caractere - motivul aici este că numărul de caractere din numele etichetei index nu poate fi mai mare. decât 10. Aceasta înseamnă că va trebui să specificați numele etichetei de index este ceva diferit de numele câmpului pe care este construit indexul. În principiu, e în regulă. Cu toate acestea, dacă numele etichetei și numele câmpului sunt aceleași, atunci acest lucru simplifică foarte mult procesul de programare și permite, în unele cazuri, crearea unui codul programului independent de utilizarea unui anumit tabel.

Nu denumiți tabelul la fel ca unul dintre câmpurile sale - desigur, acest lucru nu va provoca o eroare, dar va complica înțelegerea codului scris de către programator însuși. Nu este întotdeauna posibil să determinați clar imediat ce despre care vorbimîn special despre tabel, și nu despre câmpul tabelului. Și dacă și numele lor coincid, atunci devine foarte dificil.

Nu utilizați unul dintre cuvintele rezervate FoxPro pentru nume, în special cele utilizate în comanda Select-SQL - acest lucru poate cauza un mesaj de eroare de sintaxă, care va necesita o complexitate semnificativă a codului pentru a suprima. În plus, acest lucru va reduce lizibilitatea codului. La urma urmei, cuvintele rezervate sunt evidențiate automat într-o anumită culoare (dacă utilizați un editor de text FoxPro standard) și devine imediat dificil să distingeți o opțiune sau o comandă de numele unui câmp de tabel.

Dacă imaginația îți eșuează complet și nu știi cum să denumești câmpul altfel decât de exemplu "Ordin" sau "Grup", apoi adăugați ca prim caracter o literă care indică tipul de date utilizate în acest câmp. De exemplu, "nOrder" sau „cGroup”

Unele cărți recomandă ca primul caracter al numelui unui câmp să fie întotdeauna o literă care indică tipul de date folosit în câmp. Nu aș recomanda să faceți acest lucru, din motivul că FoxPro este un limbaj care nu ține seama de majuscule și minuscule. Acestea. nu-i pasă dacă litere mari sau mici sunt folosite în nume. În consecință, toate comenzile și funcțiile FoxPro care returnează orice nume le returnează fie în partea de sus ( cu litere mari), sau cu litere mici (litere mici). Când este scris în acest fel, numele este perceput ca un cuvânt întreg fără diviziune semantică. Acestea. prima literă nu este percepută ca un tip de date, ci pur și simplu ca începutul unui cuvânt.

De fapt, lucrez cu câmpuri de tabel

Este extrem de nedorit să modificați dinamic câmpurile de tabel sau să adăugați/eliminați câmpuri în timpul funcționării. Acest lucru este asociat cu probleme mari și complicații semnificative ale codului programului.

Când utilizați câmpuri de tabel, este recomandabil să adăugați întotdeauna un alias de tabel pentru a le identifica în mod unic. Desigur, cu excepția cazurilor în care absența unui alias se datorează logicii programului.

Cert este că dacă aliasul nu este specificat, atunci FoxPro presupune că vorbim despre un câmp de tabel situat în spațiul de lucru curent. Și dacă tabelul din spațiul de lucru curent nu are un astfel de câmp, atunci despre o variabilă de memorie cu același nume. Dar atunci când scrieți un program relativ complex, nu este întotdeauna posibil să spunem cu încredere că ne aflăm în zona de lucru potrivită. Specificarea explicită a unui alias de tabel elimină această problemă.

Completați secțiunea "Cometariu" pentru toate câmpurile de tabel din designerul de tabel. A scrie comentarii, chiar și minim, este în orice caz un lucru foarte util. Acest text este afișat automat în fereastra proiectului în sine ( Proiect) când indicatorul se deplasează în câmpul corespunzător al tabelului. Și documentarea bazei de date este simplificată. Puteți folosi acest text (prin intermediul funcției DBGetProp()) când sunt emise mesaje de eroare.

Câmp cheie

Acesta este unul dintre cele mai importante concepte folosite atunci când lucrați cu tabele și baze de date

Câmp cheie- acesta este un câmp (sau un set de câmpuri) al cărui conținut poate identifica în mod unic o înregistrare de tabel. Acestea. Pe baza valorii câmpului cheie, puteți întotdeauna să spuneți fără ambiguitate despre ce înregistrare vorbiți și nu pot exista 2 înregistrări cu aceleași valori ale câmpului cheie.

Cheie externă este un câmp de tabel care conține valoarea unui câmp cheie dintr-un alt tabel. Acestea. doar un link către o înregistrare dintr-un alt tabel.

Voi începe imediat cu concluzia:
Pentru majoritatea sarcinilor din FoxPro, este convenabil să utilizați o cheie surogat de tip Integer ca câmp de cheie. Este recomandabil să introduceți câmpul cheie pentru toate tabelele bazei de date fără excepție.

Ei bine, acum să vedem cum am ajuns la aceste concluzii

Chei naturale sau surogat

Există încă dezbateri în desfășurare despre ce este mai bine să utilizați: cheile surogat sau naturale.

Cheie naturală este un câmp sau un set de câmpuri care au o anumită semnificație fizică. Ei bine, de exemplu, numărul personalului, numărul pașaportului etc.

Cheie surogat- acesta este un domeniu care nu are sens fizicși este introdusă exclusiv în scopul identificării unice a înregistrării. Informațiile pe care le conține nu au nicio legătură logic cu informațiile din alte câmpuri ale aceluiași tabel.

Să luăm în considerare ce avantaje și dezavantaje au cheile naturale și surogat

De fapt, cel mai important și determinant criteriu prin care se poate judeca dacă un anumit câmp este adecvat sau nu pentru a fi utilizat ca câmp cheie este unicitatea identificării înregistrării. Ceea ce ne referim aici este că valoarea câmpului selectat este unică pentru fiecare înregistrare?

Ei bine, cu o cheie surogat totul este clar - noi înșine îi formăm valoarea fără participarea utilizatorului, astfel încât să îi putem monitoriza unicitatea, dar cum rămâne cu cheia naturală?

La prima vedere, se pare că și totul este în ordine. Cum poate un număr de pașaport să nu fie unic? Sau numărul de personal? Se dovedește că încă se poate!

În primul rând, orice informație introdusă de utilizator poate conține erori. Ei bine, oamenii nu pot să nu facă greșeli. Unii oameni greșesc mai des, alții mai rar, dar toată lumea greșește. Unele erori pot fi cu siguranță detectate programatic, dar nu toate.

De exemplu, dacă vorbim despre un anumit număr alfanumeric (număr de pașaport) și utilizatorul a introdus „123 ABC”, dar ar fi trebuit să fie „423 ABC”, atunci din punct de vedere sintactic este corect, dar în ceea ce privește conținutul este o eroare . Dacă se dovedește mai târziu că acum trebuie să intri numar nou pașaport, dar deja „123 ABC”, atunci programul va refuza să facă acest lucru, deoarece un astfel de număr există deja. Și nu se știe pentru ce să o corecteze, întrucât documentele din care a fost introdusă nu mai există.

În al doilea rând (și poate mai important), informațiile tinde să se schimbe. De exemplu, nu cu mult timp în urmă pașapoartele au fost înlocuite Federația Rusăși dacă programul s-a bazat pe numărul său ca identificator, atunci acum totul a căzut într-o mare dezordine în legătură cu această înlocuire

Din nou, nu cu mult timp în urmă, așa-numitele „Numere de identificare a contribuabilului” au fost introduse în Federația Rusă. Așa-numitul „TIN”. Ei bine, s-ar părea, ei bine, acesta este identificatorul unic al contrapărții. Dar birocrația noastră natală a reușit să strice totul și aici. S-a dovedit că TIN-ul încalcă toate criteriile de unicitate datorită unor caracteristici ale formării sale

La una dintre conferințe, unul dintre vizitatori s-a exprimat destul de emoționat despre acest lucru

Dau preferință SK-ului pur și simplu pentru că SK oferă utilizatorului posibilitatea de a decide, Ivanov I.I. și Petrov I.I. - aceeași persoană sau diferită. Poate și-a schimbat numele de familie, poate chiar și genul, poate și-a schimbat atât tipul de pașaport, cât și numărul acestuia. Poate și-a schimbat cetățenia, s-a întors din război fără brațe, picioare și cap, a născut copii, a făcut operații plastice pentru a-și schimba greutatea... Dar asta nu l-a împiedicat să fie el însuși.

Astfel, în caz general, o cheie naturală nu oferă principalul lucru - identificarea fără ambiguitate a unei înregistrări prin valoarea câmpului cheie. Și dacă o oferă, atunci încetează să fie naturală în sensul original al cuvântului, deoarece obligă utilizatorul să se adapteze și să se eschiveze.
Deci, de ce, în ciuda unor argumente atât de evidente împotriva, există încă destule un numar mare de adepții utilizării unei chei naturale?

În opinia mea, există o neînțelegere clară aici că o cheie surogat este o informație care nu este furnizată utilizatorului nicăieri și în niciun fel. O cheie surogat este ceva ascunsă invizibil pentru utilizator mecanică „internă”.

Faptul este că principalul argument al susținătorilor cheii naturale este „înțelegerea” acesteia pentru utilizator. Acestea. se presupune că utilizatorul caută ceva pe baza valorii câmpului cheie. Cu alte cuvinte, utilizatorul însuși introduce, corectează și vizualizează valoarea câmpului cheie.

Dar în legătură cu cheia surogat, o astfel de utilizare este pur și simplu inacceptabilă! Ei bine, utilizatorul nu ar trebui să știe cum se „bifează” totul în cadrul programului. Utilizatorul este interesat de citirile ceasului și nu de toate „angrenajele”. Dacă doriți să furnizați utilizatorului o abreviere ( nume scurt, „nick”), atunci aceasta nu ar trebui să fie în niciun caz o cheie surogat. Introduceți încă un câmp suplimentar în acest scop.
Există un alt argument, mai viclean, în favoarea utilizării cel puțin parțiale a cheilor naturale. Faptul este că de foarte multe ori este nevoie de o clasificare internă. Ei bine, de exemplu, dacă vorbim despre documente, atunci acestea pot fi în unele stări care se exclud reciproc:

Există o tentație foarte mare să nu faci un tabel suplimentar cu aceste 3 înregistrări, ci pur și simplu să folosești codurile 1,2,3 Ei bine, într-adevăr, utilizatorul nu poate schimba numărul și numele stărilor. Aici adepții cheii naturale își ridică vocea - ei spun că unele numere îi spun programatorului, lasă-l să scrie cuvintele imediat

În acest caz, personal aș recomanda să nu cedeți tentației de a „simplifica” baza de date și de a introduce o placă de service suplimentară cu 3 înregistrări de stare. Chiar dacă utilizatorul nu are posibilitatea de a-l edita. Veți vedea singur cât de potrivit va fi și, în unele cazuri, pur și simplu de neînlocuit atunci când vă scrieți programul.
Concluzia este clară - cheile surogat sunt preferabile cheilor naturale după toate criteriile

Ce tip de date să utilizați: Caracter sau Întreg

Anterior, când FoxPro avea doar câmpuri precum Numeric preponderenţa argumentului a înclinat în favoarea folosirii câmpurilor ca Caracter, dar odata cu aparitia domeniilor ca Întreg totul nu este atât de clar

Când se compară modul de stocare a unui câmp cheie în format caracter sau numeric, sunt prezentate 3 argumente

Este mai ușor să generați o nouă valoare în câmpurile numerice

Câmpurile de caractere sunt „mai economice”, adică. se poate potrivi mai multe valori aceeași mărime

Câmpurile de caractere sunt „mai universale” pentru așa-numitele sarcini de replicare, de exemplu. fuzionarea bazelor de date care nu au legătură

Câmpurile numerice sunt mai ușor de format

Aici, câmpurile numerice nu au concurență, deoarece modul standard de a forma câmpuri cheie numerică este „valoarea maximă plus unu”. În cazul câmpurilor de caractere, de regulă, se folosește un fel de generator de numere pseudoaleatoare. Nu este locul unde să discutăm despre modul în care sunt generate cheile simbolice, dar procedurile folosite sunt de obicei destul de complexe din cauza dificultății de a asigura o valoare cu adevărat unică.

Permiteți-mi să observ, de asemenea, că nu ar trebui să utilizați definiția valorii maxime din tabelul curent pentru a genera o nouă valoare cheie. Acest lucru este bine în modul cu utilizator unic, dar în modul cu mai mulți utilizatori riști să obții 2 valori cheie identice atunci când doi utilizatori adaugă o intrare nouă în același timp. De obicei, se folosește un tabel special de servicii care stochează valoarea ultimei valori a cheii utilizate (sau prima neutilizată). Exemple de utilizare a unui astfel de tabel sunt date în proiectele standard FoxPro exemplu: Soluție.pjx(formă NewID.scx) Și TasTrade.pjx. Și în versiunea 8 a apărut FoxPro câmpuri cu incrementare automată, care a simplificat complet această sarcină.

Câmpurile de caractere sunt „mai economice”, adică. pot încadra mai multe valori în aceeași dimensiune

Să începem cu întrebarea: de câte valori sunt necesare pentru a identifica toate înregistrările dintr-un tabel?

Din restricțiile de sistem se știe că numărul maxim permis de înregistrări într-un tabel DBF este 1 miliard de înregistrări. Acestea. acesta este unu și nouă zerouri

Un câmp întreg poate lua valori în intervalul de la -2.147.483.647 la 2.147.483.647. Ei bine, valorile negative în general nu sunt utilizate, dar valorile pozitive sunt de 2 ori mai mari decât numărul maxim posibil de înregistrări. Ținând cont de posibila ștergere a înregistrărilor - tocmai corect.

Întrucât câmpul este tip Întreg fizic are 4 octeți (4 caractere), apoi să vedem câte valori pot fi alocate cu aceeași dimensiune pentru un câmp de caractere

Un octet poate conține 256 de valori, adică acesta va fi 256**4=4.294.967.296. Dar, deoarece unele valori nu pot fi utilizate din mai multe motive (de exemplu, line feed, Esc etc.), se dovedește că în ceea ce privește numărul de valori ale tipului de câmp Întreg nu este cu nimic inferior unui domeniu ca Caracter(4), poate chiar oarecum superior

cometariu

Trebuie remarcat faptul că în câmpurile FoxPro precum Numeric stocate ca câmpuri de caractere, de ex. Fiecare cifră are nevoie de un octet pentru a fi stocată. Aceasta înseamnă că, dacă numărul așteptat de valori dintr-un tabel dat nu depășește o mie (mai puțin de 4 caractere), atunci există o tentație de a „salva” și în loc de a tasta Întreg introduceți, să zicem, un câmp de tip N(2)

Deci, nu aș recomanda să faceți acest lucru din următoarele motive:

ÎN calculatoare moderne dimensiunea fizică a tabelelor (în octeți) nu mai joacă un rol la fel de important ca înainte. Vă puteți permite să nu economisiți mult spațiu pe disc.

Dacă toate câmpurile cheie din toate tabelele au același tip și dimensiune de date, atunci acest lucru simplifică foarte mult procesul de programare în sine. Nu este nevoie să ne amintim cu durere ce tip și dimensiune au fost utilizate într-un anumit tabel. Uneori, acest lucru este de o importanță fundamentală.

Câmpurile de caractere sunt „mai universale” pentru așa-numitele sarcini de replicare

Replicare- aceasta este combinația de informații din două baze de date neînrudite, de exemplu, din două ramuri ale aceleiași organizații din punct de vedere geografic prieten de la distanță de la prieten

Da, într-adevăr, în astfel de sarcini este mai convenabil să folosiți câmpuri simbolice, deși chiar și într-o situație atât de aparent pierdere, câmpurile numerice au ceva de „obiectat”

Acesta nu este locul pentru a discuta această problemă din cauza vastității ei, așa că voi observa doar că pentru o gamă foarte mare de probleme problema replicării în sine nu este relevantă. Fie se folosește tehnologia serverului de fișiere, fie îmbinarea este necesară doar într-o singură direcție pentru a obține informații și rapoarte
Concluzia nu este la fel de categorica ca in cazul cheilor surogat:

generarea unei noi valori pentru o cheie numerică este mai ușoară decât generarea unei noi valori pentru o cheie simbolică

numărul de valori cheie pentru tip ÎntregȘi Personaj(4) aproape la fel

atunci când decide sarcini complexe Este mai convenabil pentru replicare să folosească câmpuri cheie simbolice
Dar, deoarece majoritatea programatorilor nu vor trebui să se ocupe de sarcini de replicare, puteți utiliza tipul în siguranță Întreg.

Este necesar să folosiți un câmp cheie în toate tabelele fără excepție?

La prima vedere, întrebarea poate părea ciudată. Este posibil fără un câmp cheie? Se pare că în unele cazuri este posibil.

De exemplu, pentru a organiza o relație multi-la-mulți, modalitatea standard este de a crea un tabel proxy. Ce înseamnă?

Să presupunem că aveți o listă de contrapărți și o listă de bănci. Desigur, aceeași contrapartidă poate avea un cont la mai multe bănci. Dar și invers este adevărat - o bancă lucrează cu mai multe contrapărți. În acest caz, nu poți face cheie externă banca în tabelul contrapărților sau cheia străină a contrapărții în tabelul băncilor. Trebuie să introduceți un tabel intermediar care va stoca cheia externă a băncii și cheia externă a contrapartidei.

Cu această organizare, fiecare intrare din acest tabel intermediar este identificată în mod unic printr-o pereche de valori: cod contrapartidă - cod bancar. Prin urmare, este tentant să nu introduceți un alt câmp pentru cheia surogat a acestui tabel proxy.

Dacă revenim la exemplul cu contrapărți și bănci, este ușor de observat că am ignorat punctul că o contraparte poate avea mai multe conturi în aceeași bancă. Chiar acest detaliu (contul bancar al contrapărții) nu poate fi atașat nici băncii, nici contrapărții. Dar se potrivește foarte bine cu această masă intermediară. Dacă, pentru a identifica o înregistrare în acest tabel, te-ai bazat pe perechea: cod bancar - cod contraparte, atunci ar trebui să refaci serios o parte semnificativă a programului. Și dacă aveți propriul cod de înregistrare, nu există probleme. Ei bine, au adăugat încă un câmp, deci ce?

În acest caz, m-am uitat la un caz destul de evident, dar adesea se pare că nu poate fi altfel și aici nu este necesar propriul tău identificator de înregistrare. Nu te flata pe tine. Dacă ți se pare că ceva nu se poate întâmpla, înseamnă doar că nu știi ceva.
Concluzie - utilizați propriul câmp cheie în toate tabelele fără excepție. Chiar dacă ți se pare că te poți descurca fără el.

Numele câmpului cheie

Deoarece câmpul cheie este un câmp normal de tabel, atunci i se aplică toate recomandările date în secțiune „Câmpuri de tabel”. Cu toate acestea, deoarece acesta este încă un domeniu foarte specific, aș adăuga următoarele recomandări pentru acesta:

Formați numele câmpului cheie al tabelului adăugând 2 litere „ID” la numele tabelului (din cuvântul identificator - identificator), eliminând litera „s” dacă numele tabelului este un cuvânt la plural - De exemplu, dacă denumit tabelul contrapartidelor „Partneri”, apoi cheia câmpului se va numi „PartnerID”. Cu această metodă de denumire, puteți spune clar cărui tabel îi aparține cheia. Dar nu ar trebui să numiți câmpul cheie în același mod ca tabelul în sine, deoarece în unele cazuri va deveni foarte problematic să determinați imediat despre ce vorbim - câmpul sau tabelul în sine.

Denumiți cheile străine în același mod ca și câmpurile de chei corespunzătoare - acest mod de a numi cheile străine face foarte ușor de înțeles despre ce vorbim de fapt atunci când scriem un program.

Limitați numele câmpului cheie la 10 caractere - motivul aici este că numărul de caractere din numele etichetei index nu poate fi mai mare de 10. Și cu siguranță ar trebui să construiți un index pe câmpul cheie. Dacă numărul de caractere din câmpul cheie este mai mare de 10, atunci numele etichetei index va diferi de numele câmpului cheie. Și acest lucru nu este foarte bun în sensul că va complica serios programarea, deoarece veți folosi acest index tot timpul.

Lucrează de fapt cu câmpurile cheie ale tabelului

Valoarea câmpului cheie trebuie să fie atribuită o singură dată în momentul creării înregistrării și să nu se modifice pe toată durata existenței acestei înregistrări. Este extrem de nedorit să modificați valoarea unui câmp cheie. Este mai bine să construiți programul în așa fel încât să nu fie nevoie de o astfel de modificare. Mai mult, nu aș recomanda utilizarea valorilor câmpurilor cheie ale înregistrărilor șterse (e mort, este mort).

Această strategie facilitează prinderea erorilor utilizatorului, deoarece în majoritatea cazurilor, dacă utilizatorul greșește într-un document, acesta nu corectează documentul eronat, ci îl șterge și îl creează din nou! Atunci demonstrează că acesta nu este un program rău!

În plus, această strategie face posibilă integrarea mai multor baze de date într-un singur complex cu mai puține probleme dacă este nevoie.

Nu oferiți niciodată utilizatorilor posibilitatea de a schimba ei înșiși valoarea câmpurilor cheie. Mai mult, utilizatorul nu ar trebui să le suspecteze deloc existența. Acesta ar trebui să fie pur un mecanism intern pentru a asigura integritatea bazei de date.

Faptul este că orice informație pe care o introduce utilizatorul este prin definiție nesigură și indiferent de modul în care protejezi informațiile, utilizatorul va găsi o modalitate de a o ocoli sau pur și simplu te va forța să o faci! Și ceea ce nu bănuiește și nu poate strica.

Nu încercați să atașați alte funcții la câmpurile cheie, în afară de identificarea unică a unei înregistrări.

De exemplu, în unele cazuri este tentant să folosiți câmpuri cheie și ca număr de serie al unui element dintr-o listă. Deci, nu trebuie să faci asta. Introduceți un câmp suplimentar pentru a implementa această funcționalitate. De asemenea, nu ar trebui să utilizați câmpul cheie ca nume scurt pentru element

Dacă adăugați orice funcționalitate în câmpul cheie, în afară de identificarea unică a înregistrărilor, pur și simplu vă veți crea o mulțime de probleme (codul programului va deveni mult mai complicat). Și singurul avantaj este niște economii spatiu pe disc. Nu cred că merită.

Ultima actualizare: 2004-03-02 11:22
Publicat de: Vladimir Maksimov

O cheie primară este un câmp sau un set de câmpuri cu valori care sunt unice într-un tabel. Valorile cheii pot fi folosite pentru a se referi la înregistrări întregi, deoarece fiecare înregistrare are o valoare diferită pentru cheie. Fiecare tabel poate avea o singură cheie primară. Access poate crea automat un câmp de cheie primară pentru dvs. atunci când creați un tabel sau puteți specifica câmpurile pe care doriți să le utilizați ca cheie primară. Acest articol explică cum și de ce să utilizați cheile primare.

Pentru a seta cheia primară a unui tabel, deschideți tabelul în vizualizarea Design. Selectați câmpul (sau câmpurile) pe care doriți să le utilizați, apoi pe panglică, faceți clic Cheia principala.

Notă: Acest articol este destinat utilizării numai cu bazele de date desktop Access. Access gestionează automat cheile primare pentru noile tabele din aplicațiile web Access și bazele de date web. Deși este posibil să înlocuiți aceste chei primare automate, nu vă recomandăm să faceți acest lucru.

În acest articol

Prezentare generală a cheilor primare în Access

Access folosește câmpurile cheie primară pentru a asocia rapid datele din mai multe tabele și pentru a combina acele date într-un mod semnificativ. Puteți include câmpurile cheii primare în alte tabele pentru a vă referi înapoi la tabelul care este sursa cheii primare. În acele alte tabele, câmpurile sunt numite chei externe. De exemplu, un câmp ID client din tabelul Clienți poate apărea și în tabelul Comenzi. În tabelul Clienți, este cheia principală. În tabelul Comenzi se numește cheie străină. O cheie externă, pur și simplu, este cheia principală a unui alt tabel. Pentru mai multe informații, consultați Noțiunile de bază pentru proiectarea bazei de date.

Dacă mutați date existente într-o bază de date, este posibil să aveți deja un câmp pe care îl puteți utiliza ca cheie primară. Adesea, un număr unic de identificare, cum ar fi un număr de identificare sau un număr de serie sau un cod, servește ca o cheie primară într-un tabel. De exemplu, este posibil să aveți un tabel Clienți în care fiecare client are un număr unic de identificare a clientului. Câmpul ID client este cheia primară.

Access creează automat un index pentru cheia primară, ceea ce ajută la accelerarea interogărilor și a altor operațiuni. Accesul asigură, de asemenea, că fiecare înregistrare are o valoare în câmpul cheie primară și că este întotdeauna unică.

Când creați un tabel nou în vizualizarea Foaie de date, Access creează automat o cheie primară pentru dvs. și îi atribuie un nume de câmp „ID” și tipul de date Număr automat.

Ce face o cheie primară bună?

Un candidat bun pentru o cheie primară are mai multe caracteristici:

Identifică în mod unic fiecare rând

Nu este niciodată gol sau nul - conține întotdeauna o valoare

Valorile pe care le conține rar (ideal, niciodată) se schimbă

Dacă nu puteți identifica o cheie bună, creați un câmp AutoNumber pe care să îl utilizați ca cheie. Un câmp AutoNumber generează automat o valoare pentru el însuși atunci când fiecare înregistrare este salvată pentru prima dată. Prin urmare, un câmp AutoNumber îndeplinește toate cele trei caracteristici ale unei chei primare bune. Pentru mai multe informații despre adăugarea unui câmp AutoNumber, consultați articolul Adăugarea unui câmp AutoNumber ca cheie primară .

Un câmp AutoNumber este o cheie primară bună.

Exemple de chei primare slabe

Orice câmp care îi lipsește una sau mai multe dintre caracteristicile unei chei candidate bune este o alegere proastă pentru o cheie primară. Iată câteva exemple de câmpuri care ar face chei primare slabe pentru un tabel de contacte, împreună cu motivele pentru care ar fi alegeri slabe.

Cheie primară slabă
	S-ar putea să nu fie unic în mod fiabil și se poate schimba
	Îmi place să se schimbe.
	Îmi place să se schimbe.
	Mai mult de o persoană poate împărtăși un cod poștal
Combinații de fapte și numere	Partea de fapt s-ar putea schimba, creând o povară de întreținere. Ar putea duce la confuzie dacă porțiunea de fapt se repetă ca un câmp separat. De exemplu, combinarea orașului și a unui număr incrementat (de exemplu, NEWYORK0579) ar fi o alegere proastă dacă orașul este stocat și ca câmp.
Numere de securitate socială	Informații private și nu sunt permise în departamentele guvernamentale și unele organizații. Unii oameni nu au un SSN Un individ poate avea mai mult de unul într-o viață

Chei compuse: folosind mai multe câmpuri în combinație ca cheie primară

În unele cazuri, doriți să utilizați două sau mai multe câmpuri dintr-un tabel ca cheie primară. De exemplu, un tabel Detalii comandă care stochează articole rând pentru comenzi poate folosi două câmpuri în cheia principală: ID comandă și ID produs. O cheie care are mai multe câmpuri se numește cheie compusă.

Setați cheia primară folosind câmpurile pe care le aveți deja în Access

Pentru ca o cheie primară să funcționeze bine, câmpul trebuie să identifice în mod unic fiecare rând, să nu conțină niciodată o valoare goală sau nulă și rar (ideal, niciodată) să se schimbe. Pentru a seta cheia primară:

Bază de date - este o structură organizatorică menită să stocheze informații.

Sistemul de gestionare a bazelor de date acesta este un complex software, care are scopul de a crea o structură noua baza, editarea conținutului și vizualizarea informațiilor, de ex. selectarea datelor afișate în conformitate cu criteriul dat, comandarea, proiectarea și livrarea ulterioară a acestora către un dispozitiv de ieșire sau transmisie prin canale de comunicație.

Accesul este relațional Sistemul de gestionare a bazelor de date(DBMS), inclus în pachetul MS Office.

Toate componentele bazei de date, cum ar fi tabelele, rapoartele, interogările, formularele și obiectele, sunt stocate într-un singur fișier disc, care are extensia .mdb.

Componenta structurală principală a unei baze de date este un tabel. Tabelele stochează datele de intrare. Fiecare tabel este format din coloane numite câmpuri, iar liniile numite înregistrări. Fiecare intrare de tabel conține toate informatie necesara despre un element individual de bază de date.

Când dezvoltați o structură de tabel, în primul rând, trebuie să definiți câmpurile prin definirea proprietăților acestora.

Accesați proprietățile câmpului bazei de date

Proprietate	Scopul lui
	Stabilește cum trebuie accesate datele din acest câmp. Trebuie să fie unic, de preferință astfel încât funcția câmpului să fie recunoscută după numele său.
	Determină tipul de date conținute în acest câmp.
Dimensiunea campului	Specifică lungimea maximă (în caractere) a datelor care pot fi stocate în acest câmp.
Format câmp	Determină modul în care sunt formatate datele din celulele care aparțin câmpului.
Mască de intrare	Definește forma în care datele sunt introduse în câmp.
	Definește antetul coloanei tabelului pentru acest câmp. Dacă nu este specificat, numele câmpului este folosit ca antet.
Valoare implicită	O valoare care este introdusă automat în celulele câmpului.
Condiție de valoare	Constrângerea utilizată pentru a verifica introducerea datelor este corectă
Mesaj de eroare	Mesaj text, care este emis automat atunci când încercați să introduceți date eronate în câmp.
Câmp obligatoriu	Stabilește dacă câmpul trebuie completat cu date.
Linii goale	Permite introducerea șirurilor goale
Câmp indexat	Vă permite să accelerați toate operațiunile legate de căutarea sau sortarea datelor din acest câmp. De asemenea, puteți seta o verificare dublură pentru acest câmp pentru a vă asigura că nu există date duplicate.

Trebuie remarcat faptul că proprietățile câmpurilor depind semnificativ de tipul de date conținute în câmp.

Accesați tipurile de date

Tip de date	Descriere
Text (implicit)	Text sau numere care nu necesită calcule, cum ar fi numerele de telefon (până la 255 de caractere)
Numeric	Date numerice diverse formate, folosit pentru calcule
Data Ora	Pentru a stoca datele calendaristice și ora curentă
Monetar	Pentru a depozita bani
	Pentru stocarea unor cantități mari de text (până la 65535 caractere)
	Un câmp numeric special în care Access atribuie automat un număr secvenţial unic fiecărei înregistrări. Valorile câmpurilor tip contor nu pot fi actualizate
Logic	Poate avea doar una dintre cele două valori posibile (adevărat/fals, da/nu)
Câmp obiect OLE	Obiect (de exemplu foaie de calcul Microsoft Excel, document Microsoft Word, imagine, înregistrare audio sau alte date în format binar) legate sau încorporate într-un tabel Access
	Pentru depozitare URL-uri Obiecte Internet Web.
Vrăjitor de înlocuire	Creează un câmp care oferă o alegere de valori dintr-o listă sau dintr-o casetă combinată care conține un set de valori constante sau valori dintr-un alt tabel. Nu este chiar un tip de câmp, ci o modalitate de a stoca câmpul

Câmp cheie - Acestea sunt unul sau mai multe câmpuri a căror combinație de valori identifică în mod unic fiecare înregistrare din tabel. Dacă sunt definite câmpuri cheie pentru un tabel, atunci Microsoft Accessîmpiedică introducerea valorilor duplicate sau goale într-un câmp cheie. Câmpurile cheie sunt folosite pentru cautare rapidași conexiuni de date de la mese diferite folosind interogări, formulare și rapoarte.

Există trei tipuri de câmpuri cheie în Microsoft Access: contor, cheie simplă și cheie compusă. Să ne uităm la fiecare dintre aceste tipuri.

Pentru a crea un câmp cheie de tip Counter, trebuie să utilizați modul Table Designer:

Includeți un câmp de contor în tabel.
Setați-l să crească automat cu 1.
Specificați acest câmp ca câmp cheie făcând clic pe butonul Câmp cheieConstructor de mese(Design Masei).

Dacă câmpurile cheie nu au fost definite înainte de salvarea tabelului creat, atunci la salvare va fi afișat un mesaj care indică faptul că câmpul cheie a fost creat. Când butonul este apăsat da(Da) un câmp cheie de contor numit Cod(ID) și tipul de date Tejghea(Număr automat).

Pentru a crea o cheie simplă, este suficient să aveți un câmp care conține valori unice (de exemplu, coduri sau numere). Dacă câmpul selectat conține valori duplicate sau goale, nu poate fi desemnat ca un câmp cheie. Pentru a identifica înregistrările care conțin date duplicat, puteți rula o interogare de căutare înregistrări duplicat. Dacă nu puteți elimina duplicatele prin modificarea valorilor, ar trebui fie să adăugați un câmp de contor la tabel și să faceți din acesta un câmp cheie, fie să definiți o cheie compusă.

O cheie compusă este necesară atunci când unicitatea unei înregistrări nu poate fi garantată folosind un singur câmp. Este o combinație de mai multe domenii. Pentru a defini o cheie compusă aveți nevoie de:

Selectați câmpurile care trebuie definite ca cheie.
apasa butonul Câmp cheie(Cheie primară) pe bara de instrumente Constructor de mese(Design Masei).

cometariu

Pentru o cheie compusă, ordinea câmpurilor care formează cheia poate fi importantă. Înregistrările sunt sortate în funcție de ordinea câmpurilor cheie din fereastra Table Design. Dacă trebuie să specificați o ordine de sortare diferită fără a modifica ordinea câmpurilor cheie, trebuie mai întâi să definiți cheia și apoi să faceți clic pe butonul Indexuri din bara de instrumente Design table. Apoi, în fereastra Indexuri care apare, trebuie să specificați o ordine diferită a câmpurilor pentru index cu numele Cheie primară.

Ca exemplu de utilizare a unei chei compuse, luați în considerare tabelul „OrderDetails” al bazei de date (Northwind) (Fig. 2.23).

În acest caz, câmpurile „ID comandă” și „ID produs” sunt folosite ca o cheie compusă, deoarece niciunul dintre aceste câmpuri nu garantează individual unicitatea înregistrării. În acest caz, tabelul afișează nu codul produsului, ci numele produsului, deoarece câmpul „ID produs” din acest tabel conține o înlocuire din tabelul „Produse” și valorile „ID-ului produsului” câmpurile acestor tabele sunt legate prin relația „unu-la-mulți” (o înregistrare a tabelului „Produse” poate corespunde mai multor înregistrări din tabelul „Detalii comandă”). Ambele câmpuri pot conține valori duplicat. Astfel, o comandă poate include mai multe produse și comenzi diferite Pot fi incluse produse identice. În același timp, combinația câmpurilor OrderID și ProductID identifică în mod unic fiecare înregistrare din tabelul OrderDetails.

Pentru a schimba cheia trebuie să:

Deschideți tabelul în modul Design.
Selectați câmpurile cheie disponibile.
Faceți clic pe butonul Câmp cheie oprit, iar pictogramele câmpului cheie ar trebui să dispară din zona de selecție.
Selectați câmpul pe care doriți să îl faceți cheie.
Faceți clic pe butonul Câmp cheie(Cheia principala). În acest caz, pictograma câmpului cheie ar trebui să apară în zona de selecție.

Orez. 2.23. Exemplu de tabel folosind o cheie compusă

Pentru a șterge o cheie, trebuie să:

Deschideți tabelul în modul Design.
Selectați câmpurile cheie existente.
Faceți clic pe butonul Câmp cheie(Cheie primară), iar butonul ar trebui să ocupe poziția oprit, iar pictogramele câmpului cheie ar trebui să dispară din zona de selecție.

Care sunt relațiile dintre tabele

ÎN baza de date relationala datele de comunicare ajută la prevenirea datelor redundante. De exemplu, atunci când se dezvoltă o bază de date care conține informații despre cărți, ar putea avea un tabel numit Titluri care stochează informații despre fiecare carte: carte? titlul, data publicării și editorul. Sunt indicate, de asemenea, informații care ar putea trebui stocate despre editor, de exemplu, număr de telefon editor, adresa și cod poștal. Dacă salvați aceste date în antetele tabelului, editor? Numărul de telefon al lui va fi duplicat pentru fiecare carte publicată de el.

Cea mai bună soluție este să stocați informațiile despre editor masa separata Editorii. Apoi ar trebui să setați indicatorul din tabelul Titluri la o intrare din tabelul Publishers.

Pentru a vă asigura că datele dvs. nu sunt sincronizate, puteți asigura coerența între tabelele Titluri și Editori. Condițiile de integritate a datelor ajută la asigurarea faptului că datele dintr-un tabel se potrivesc cu datele din altul. De exemplu, fiecare carte din tabelul Titluri trebuie să fie asociată cu un anumit editor din tabelul Editori. Nu poate fi adăugat un titlu în baza de date pentru un editor care nu există în baza de date.

Tipuri de relații între tabele

O relație funcționează prin potrivirea datelor din coloanele cheie, de obicei coloane cu același nume în ambele tabele.

Există trei tipuri de relații între tabele.

Relații unul la mai multe

O relație unu-la-mulți este cel mai comun tip de relație.

O relație unu-la-mai mulți este creată dacă numai una dintre coloanele asociate este o cheie primară sau are o constrângere unică.

În Microsoft Access, partea cheie primară a unei relații unu-la-mai mulți este reprezentată de un simbol cheie.

Relații de la multe la multe

Într-o relație multi-la-mulți, un rând din tabelul A poate avea mai multe rânduri care se potrivesc în tabelul B și invers.

Relație unu la unu

Într-o relație unu-la-unu, un rând din tabelul A poate avea cel mult un rând corespunzător din tabelul B și invers.

Acest tip de link nu este obișnuit deoarece majoritatea informațiilor legate în acest fel pot fi plasate într-un singur tabel.

Împărțirea unui tabel cu mai multe coloane.
Izolarea unei părți a mesei din motive de securitate.
Stocați date care pot fi șterse cu ușurință împreună cu un tabel pe termen scurt.
Stocați informații care se aplică numai unui subset al tabelului principal.

În Microsoft Access, partea cheie primară a unei relații unu-la-unu este reprezentată de un simbol cheie.

Crearea de relații între tabele

Când creați o relație între tabele, câmpurile înrudite nu trebuie să aibă aceleași nume. Cu toate acestea, câmpurile care sunt legate trebuie să fie de același tip, cu excepția cazului în care câmpul cheie primară este un câmp de contor de date. Puteți mapa câmpurile de contor la un câmp numeric dacă Proprietățile FieldSize ale ambelor câmpuri se potrivesc. De exemplu, puteți mapa câmpuri de contor la un câmp numeric dacă proprietatea Dimensiunea campului ambele câmpuri au o valoare întreagă lungă. Chiar și atunci când câmpurile numerice sunt legate, acestea trebuie să aibă aceeași valoare a proprietății Dimensiunea campului .

Definiția unei relații unu-la-mulți „sau” unu-la-unu

Pentru a crea o relație de la unul la mulți, faceți următoarele acțiuni:

Închideți toate mesele deschise. Nu puteți crea sau modifica relații între tabelele deschise.
Apăsați F11 pentru a accesa fereastra bazei de date.
În meniu Serviciu selectați elementul comunicatii.
Dacă nu există relații în baza de date, se afișează automat o casetă de dialog Adăugarea unui tabel. Dacă doriți să adăugați tabele care trebuie legate, dar care nu sunt afișate în caseta de dialog Adăugarea unui tabel, apasa butonul Arată tabelul meniul comunicatii .
Faceți dublu clic pe numele tabelelor pe care doriți să le legați, apoi închideți caseta de dialog Adăugarea unui tabel. Pentru a crea o relație între un tabel și el însuși, adăugați-o de două ori.
Trageți câmpul pe care doriți să îl conectați dintr-un tabel în câmpul corespunzător dintr-un alt tabel. Pentru a trage mai multe câmpuri, țineți apăsată tasta CTRL, selectați fiecare câmp, apoi trageți-le.
În cele mai multe cazuri, trageți un câmp de cheie primară (care apare cu text aldine) dintr-un tabel pe un câmp similar (adesea cu același nume) numit cheie străină într-un alt tabel.
Se va deschide o casetă de dialog Schimbarea conexiunilor. Verificați dacă numele câmpurilor prezente în cele două coloane sunt corecte. Ele pot fi schimbate dacă este necesar.
Dacă este necesar, setați parametrii de comunicare. Pentru a obține informații despre o anumită setare în „ Schimbarea conexiunilor", faceți clic pe butonul semnului întrebării și faceți clic pe articol. Aceste opțiuni vor fi descrise în detaliu mai târziu în acest articol.
Faceți clic pe butonul Crea pentru a crea o conexiune.
Repetați pașii de la 5 la 8 pentru fiecare pereche de tabele pe care doriți să le conectați.
La închiderea casetei de dialog Schimbarea conexiunilor Microsoft Access vă va întreba dacă doriți să salvați aspectul. Indiferent dacă se salvează sau nu aspectul, relațiile sunt salvate în baza de date.
Notă:În interogări, precum și în tabele, puteți crea relații. Cu toate acestea, integritatea referenţială nu este impusă de interogări.

Cum să definești relațiile de la mulți la mulți

Pentru a crea o relație multi-la-mulți, urmați acești pași:

Creați două tabele care vor avea o relație de la mulți la mulți.
Creați un al treilea tabel, numit tabel de legătură, apoi adăugați câmpuri cu aceleași definiții ca și câmpurile cheie primară în fiecare dintre cele două tabele legate. Câmpurile cheie primară în masă rotativă, servesc ca chei străine. La fel ca în cazul oricărui alt tabel, puteți adăuga alte câmpuri la tabelul de legătură.
Într-un tabel pivot, setați cheia primară să includă câmpul cheie primară din cele două tabele care sunt conectate. De exemplu, în tabelul de legătură TitleAuthors, cheia primară poate consta din câmpurile OrderID și ProductID.
Notă: Pentru a crea o cheie primară, urmați acești pași:
1. Deschideți tabelul în vizualizarea Design.
2. Selectați câmpul sau câmpurile pe care doriți să le definiți ca cheie primară. Pentru a selecta un singur câmp, faceți clic pe zona de selecție a rândului pentru câmpul dorit.
  Pentru a selecta mai multe câmpuri, țineți apăsată tasta CTRL și faceți clic pe zona de selecție a rândurilor pentru fiecare câmp.
3. Faceți clic pe butonul Cheie câmp din bara de instrumente.
  Notă: Dacă ordinea câmpurilor din mai multe câmpuri cheie primară ar trebui să fie diferită de ordinea câmpurilor din tabel, faceți clic pe indici pe bara de instrumente pentru a deschide caseta de dialog indiciși apoi ordinea câmpurilor pentru indexul numit Cheia principala.
Definiți o relație unu-la-mulți între fiecare dintre cele două tabele principale și tabelul de legătură.

Integritate referenţială

Integritatea datelor se referă la sistemul de reguli pe care Microsoft Access îl utilizează pentru a asigura relațiile dintre înregistrările din tabelele asociate și ștergerea sau modificarea accidentală a datelor asociate. Integritatea datelor poate fi stabilită dacă sunt îndeplinite toate următoarele condiții:

Câmpul corespunzător din tabelul principal este o cheie primară sau are un index unic.
Câmpurile înrudite au același tip de date. Există două excepții. Câmpul contor poate fi legat de câmpul valoarea proprietății Dimensiunea campuluiîntreg lung și un câmp contor cu parametri de proprietate Dimensiunea campului codul de replicare poate fi asociat cu un câmp de valoare de proprietate numerică Dimensiunea campului cod de replicare.
Ambele tabele aparțin aceleiași baze de date Date Microsoft Acces. Dacă tabelele sunt legate, acestea trebuie să fie în format Microsoft Access și trebuie să fie deschisă baza de date în care sunt stocate setările de integritate a datelor. Integritatea datelor nu poate fi aplicată tabelelor legate din baze de date în alte formate.

Când se utilizează condiția de integritate a datelor, se aplică următoarele reguli:

Nu puteți introduce o valoare într-un câmp de cheie străină al unui tabel asociat; cheia primară a tabelului principal nu există. Cu toate acestea, puteți introduce o valoare cheie străină nulă pentru a indica faptul că înregistrările nu sunt legate. De exemplu, nu puteți crea o comandă atribuită unui client care nu există, dar puteți crea o comandă atribuită nimănui specificând o valoare Nulă în câmpul ID client.
Nu puteți șterge o înregistrare din tabelul principal dacă există înregistrări care se potrivesc în tabelul aferent. De exemplu, nu puteți șterge o înregistrare de angajat din tabelul Angajați dacă există comenzi legate de angajat în tabelul Comenzi.
Nu puteți modifica valoarea cheii primare din tabelul principal dacă înregistrarea are înregistrări asociate. De exemplu, nu puteți modifica codul de angajat din tabelul Angajați dacă există comenzi legate de acest angajat în tabelul Comenzi.

Actualizare și ștergere în cascadă

Relațiile care utilizează integritatea referențială pot fi specificate pentru a solicita Microsoft Access să actualizeze automat în cascadă sau . Dacă setați aceste opțiuni, operațiunile de ștergere și actualizare vor fi interzise de regulile de integritate a datelor. Când ștergeți înregistrări sau modificați valorile cheii primare din tabelul principal, Microsoft Access face modificările necesareîn tabele aferente pentru a menține integritatea datelor.

Dacă faceți clic pe caseta de validare când definiți o relație, atunci când cheia primară a unei înregistrări din tabelul principal se modifică, Microsoft Access actualizează automat cheia primară cu noua valoare din toate înregistrările asociate. De exemplu, când modificați un cod de client în tabelul Clienți, câmpul Cod client din tabelul Comenzi este actualizat automat pentru toate comenzile pentru acel client, astfel încât conexiunea să nu fie întreruptă. Microsoft Access va efectua o actualizare în cascadă fără a afișa mesaje suplimentare.

Notă: Dacă câmpul contorului cheii primare este în tabelul principal, bifând Actualizare în cascadă a câmpurilor conexe nu va avea niciun efect deoarece nu poate modifica valoarea din câmpul contor.

Dacă bifați caseta când definiți o relație Ștergerea în cascadă a înregistrărilor asociate, ori de câte ori ștergeți o înregistrare din tabelul principal, Microsoft Access va șterge automat înregistrările aferente din tabelul aferent. De exemplu, atunci când ștergeți o înregistrare client din tabelul Clienți, toate comenzile clientului respectiv sunt șterse automat din tabelul Comenzi (inclusiv înregistrările din tabelul Detalii comandă care sunt asociate cu înregistrările comenzii). Când ștergeți înregistrări dintr-un formular sau tabel cu caseta de selectare selectată Ștergerea în cascadă a înregistrărilor asociate, Microsoft Access avertizează că intrările asociate vor fi, de asemenea, șterse. Cu toate acestea, atunci când ștergeți înregistrări folosind o solicitare pentru dezinstalează Microsoft Access va șterge automat înregistrările din tabelele aferente fără avertisment.

Tipuri de conexiune

Există trei tipuri de conexiune, după cum se arată mai jos:

Opțiunea 1 -îmbinare interioară. O îmbinare internă este o îmbinare în care înregistrările din două tabele sunt unite în rezultatele interogării numai dacă valorile din câmpurile aferente satisfac o condiție specificată. Într-o interogare implicită, îmbinarea este o îmbinare internă care selectează înregistrările numai dacă valorile câmpurilor aferente se potrivesc.

Opțiunea 2 definește o îmbinare exterioară stângă. O îmbinare exterioară stângă este o îmbinare în care sunt toate intrările din partea stângă a operației LEFT JOIN interogare SQL Instrucțiunile adaugă rezultate ale interogării chiar dacă nu există valori corespunzătoare în câmpul asociat din tabelul din dreapta.

Opțiunea 3 definește o îmbinare exterioară dreaptă. O îmbinare exterioară dreaptă este o îmbinare din care provin toate înregistrările partea dreapta Operația RIGHT JOIN din instrucțiunea de interogare SQL adaugă rezultatele interogării chiar dacă câmpul asociat din tabelul din stânga nu are valori corespunzătoare.

Unul sau mai multe câmpuri (coloane) a căror combinație de valori identifică în mod unic fiecare înregistrare dintr-un tabel se numește cheie primară. Câmpul cheie vă permite să evitați erorile la introducerea datelor, deoarece acestea nu pot fi repetate în acest câmp. Numărul de identificare atribuit cetățenilor poate fi folosit ca câmp cheie serviciul fiscal, seria și numărul pașaportului angajatului. Câmpul cheie poate conține un număr sau o secvență de caractere pentru a identifica fiecare înregistrare și pentru a evita duplicarea. Un câmp cheie este utilizat pentru a căuta și a lega rapid date din diferite tabele folosind interogări, formulare și rapoarte. Cheia primară nu poate conține valori nule și trebuie să aibă întotdeauna un index unic. În orice tabel este de dorit să existe unul sau mai multe câmpuri cheie. Null înseamnă că nu există date în câmp, de exemplu pentru că sunt necunoscute. Null nu poate fi echivalat cu un șir care conține spații. În câmpul special Counter (AutoNumber), fiecărei înregistrări i se atribuie un număr unic pentru acest câmp, care crește automat cu fiecare înregistrare nouă. Poate fi folosit pentru a numerota intrările în ordine.

O cheie primară compusă este o combinație de mai multe câmpuri. Este utilizat în cazurile în care este imposibil să se garanteze unicitatea unei înregistrări folosind un singur câmp. Această situație apare cel mai adesea pentru un tabel care este folosit pentru a lega două tabele într-o relație multi-la-mulți.

Datele cheie ale câmpului sunt utilizate pentru indexarea tabelului, ceea ce accelerează căutarea și procesarea informațiilor. Dacă sortarea tabelului nu este specificată, atunci înregistrările sunt sortate după valoarea cheii. Includerea înregistrărilor noi sau ștergerea înregistrărilor vechi nu mută tabelele, se schimbă doar locația fiecărui index. O cheie primară este folosită pentru a lega un tabel la altul.

Pentru a afișa un tabel pe ecran în fereastra bazei de date, selectați numele tabelului din listă și selectați Deschidere din meniul Fișier sau faceți clic pe butonul Deschidere din bara de instrumente. Faceți clic pe celula în care doriți să introduceți datele. Introduceți detaliile dvs. și faceți clic Introduceți cheile sau Tab. Pentru a accesa o intrare goală, faceți clic Tastele Ctrl+ (simbol plus) sau faceți clic pe butonul pentru a naviga prin înregistrări Intrare nouă. Modificarea valorilor câmpurilor, adăugarea sau ștergerea datelor și căutarea datelor se fac toate în vizualizarea Foaie de date. Introducerea datelor noi în câmpul evidențiat le înlocuiește automat pe cele vechi. Numărul de caractere pe care îl introduceți depinde de dimensiunea câmpului, nu de lățimea coloanei. Textul nu poate fi rupt într-o celulă. Nu puteți afișa mai multe rânduri de text într-o singură celulă. Pentru a introduce aceleași date în mai multe celule, selectați celulele, tastați datele, apoi apăsați Ctrl+Enter. Pentru a șterge datele din câmpul evidențiat, faceți clic Șterge cheia.

Astăzi la clasă ne vom uita la ce este un câmp cheie dintr-un tabel, vom învăța tipurile de câmpuri cheie și vom afla cum să determinăm câmp cheie dintr-un tabel Access pe un exemplu concret.

Proprietatea principală a unui tabel dintr-o bază de date relațională este că toate înregistrările trebuie să fie unice, adică Nu ar trebui să existe două înregistrări absolut identice într-un singur tabel:

Ivanov Ivan Ivanovici
Ivanov Ivan Ivanovici

Aceasta nu este o persoană înregistrată de două ori în tabel, ci două persoane diferite persoană anume! Da, pot fi absolut doi în tabel oameni diferiti cu numele Ivanov Ivan Ivanovici. Cum să le distingem? Acest lucru se realizează folosind un câmp cheie.

Un câmp cheie este un atribut sau un grup de atribute care asigură că fiecare rând (înregistrare) este unic.

Este câmpul cheie care va permite fiecărei înregistrări să fie considerată diferită, în în acest exemplu ne va permite să distingem între cei doi Ivanovi.

Câmpurile cheie sunt de următoarele tipuri:

tejghea;
cheie simplă;
cheie compusă.

Fiecare tabel trebuie să aibă un câmp cheie. Vom folosi un câmp cheie de tip counter. Pentru a-l crea, trebuie doar să selectați atributul în meniul contextual RMB selectați comanda Key Field. Dacă nu ați definit un atribut care să fie cheie, atunci la închiderea tabelului, Access se va oferi cu siguranță să creați un câmp cheie selectând singur cheia.

Vă rugăm să rețineți că câmpul cheie este foarte important atunci când creați tabele. Câmpul cheie este utilizat

pentru a conecta mesele între ele;
pentru căutarea rapidă a informațiilor în tabele.

Să încercăm folosind un anumit tabel ca exemplu definiți câmpul cheie. Exemplul este discutat în detaliu în tutorial video:

Să repetăm:

Dacă atributul Nume de familie este un câmp cheie, atunci nu ar trebui să existe două nume de familie identice în tabel, care în viata reala imposibil, pentru că În clasă, de exemplu, există frate și soră cu aceleași nume de familie.
Dacă utilizați (Nume, Adresă_de acasă) ca cheie primară, atunci nu ar trebui să existe adrese identice în înregistrările tabelului, ceea ce este, de asemenea, imposibil, deoarece Un frate și o soră care locuiesc la aceeași adresă pot studia în aceeași clasă.
După ce am sortat toate atributele candidaților pentru cheia primară, ajungem la concluzia că trebuie să introducem un câmp suplimentar pe care îl vom folosi ca cheie.
Permiteți-mi să vă reamintesc că, dacă numele câmpului este format din două cuvinte, atunci nu este recomandat să folosiți spații. În acest caz, este mai bine să folosiți un caracter de subliniere pentru a conecta cuvintele.

P.S. Teatrul începe cu un cuier, iar masa cu un câmp cheie. Este foarte important să înveți cum să identifici corect câmpul cheie.

Permiteți-mi să vă reamintesc că există mai multe moduri de a crea o bază de date, care sunt discutate în lecția „Introducere în Acces”, există și mai multe modalități de a crea tabele. Lecția discută în detaliu primele două metode: utilizarea vrăjitorului și intrarea într-un tabel.