2.3. clasificarea entităților
Trei clase de entități
În momentul în care a ajuns să înțeleagă terminologia. K.Deyt [3] identifică trei clase principale de entități: tija. asociativ și caracteristic. precum și o subclasă de entități asociative - denumiri.
Rod esență (miez)
În exemplele discutate tije anterioare - este „Student“, „apartament“, „Men“, „doctor“, „Căsătoria“ (din exemplul 2.2), iar altele ale căror nume sunt plasate în dreptunghiuri.
entitate asociativă (asociație)
entitate asociativă (asociație) - este tipul de conexiune "multi-la-multe" ( "1-to-many" etc.) între două sau mai multe entități sau entități exemplu (ca în exemplul 2.4). Asociația a considerat ca entități egale:
Ei pot participa la asociații și alte notatii în același mod ca și esența de bază;
poate poseda proprietăți, adică nu au doar un set de atribute cheie necesare pentru a specifica relațiile, dar, de asemenea, orice număr de alte atribute care caracterizează raportul.
De exemplu, asocierea „căsătoriei“ din exemplele 2.1 și 2.4 conțin atributele cheie, și „numărul soțului personal“, a „Kod_M“ „Kod_Zh“ „Numărul de personal al soției sale“, precum și specificând atributele „nici o dovada“, „Data înregistrării“, „Mesto_registratsii „“ numărul de înregistrare în cartea de registru „etc.
Natura intrinsecă (caracteristici)
Natura intrinsecă (caracteristici) - acest tip de conexiune „multi-la-unu“ sau „unu-la-unu“ între două entități (un caz special al asociației). Unicul scop al caracteristicilor din zona de subiect este de a clarifica descrierea, sau o altă entitate. Nevoia de ele rezultă din faptul că esența lumii reale sunt uneori proprietăți multi-evaluate. Soțul poate avea mai multe neveste (Exemplul 2.3), cartea - câteva tirajele caracteristici (astfel cum a fost modificată, completată, revizuită.) Etc.
Existența caracteristicilor depinde în întregime de natura caracterizată prin: o femeie lipsit de statutul femeilor în cazul în care soțul moare.
Pentru a descrie caracteristicile utilizate YAIM nouă propunere, care are forma generală:
CARACTERISTICI (1 atribut, un atribut 2)
De asemenea, se extind limbajul ER diagrame, introducând pentru caracteristicile de imagine ale trapez (fig. 2.2).
Fig. 2.2. Elementele lingvistice extinse ER-diagrame
Indicând natura sau denumirea
Indicând natura sau denumirea - este tipul de conexiune „multi-la-unu“ sau „unu-la-unu“ între cele două entități și caracteristici diferite, care nu depind de entitatea desemnată.
Luați în considerare exemplul legat de înscrierea angajaților din diferite departamente ale organizației.
În absența unor reguli stricte (un angajat se poate înscrie simultan în mai multe departamente sau creditate în orice secțiune), trebuie să creați o descriere cu Înmatricularea asociere:
Departamentele (număr departament, numele departamentului.)
Angajații (număr personal, numele.)
Inscriere [Departamente M, Serviciu-N]
(Număr Departament, numărul angajatului, data de înscriere).
Cu toate acestea, cu condiția ca fiecare angajat trebuie să fie neapărat înscriși într-unul din departamentele, puteți crea o descriere cu denumirea angajaților:
Departamentele (număr departament, numele departamentului.)
Angajații (număr personal, prenume. Departament Număr
În acest exemplu, angajații au o existență independentă (în cazul în care departamentul șters, atunci nu rezultă că trebuie să fie, de asemenea, eliminate de angajați ai departamentului). Prin urmare, acestea nu pot fi caracteristicile de departamente și sunt numite simboluri.
Notarea este utilizat pentru a stoca valori duplicate atribute text mare: subiecți „Codifiers“ studiate de către studenți, numele organizațiilor și departamentele lor, liste de bunuri, etc.
Descriere notația arată diferit de descrierea caracteristicilor numai în faptul că entitatea desemnată nu este în acolade, la fel ca în pătrat:
SIMBOL (atribut 1, un atribut 2) [LIST
De regulă, se referă la nu sunt considerate ca efect deplin, cu toate că acest lucru nu ar duce la nicio eroare.
Denumiri și caracteristici nu sunt entități complet independente, deoarece acestea presupun existența unor alte entități care urmează să fie „desemnat“ sau „caracterizat prin“. Cu toate acestea, ei încă mai sunt cazuri speciale spirit și poate, desigur, au proprietăți care pot participa în asociații, și notația au propriile lor (nivel inferior) caracteristici. De asemenea, subliniem faptul că toate instanțele caracteristicilor trebuie să fie în mod necesar asociate cu orice caz caracterizată de entitate. Cu toate acestea, puteți face unele copii au caracterizat prin esența relațiilor. Cu toate acestea, atunci când vine vorba de căsătorie, esența „Bărbaților“ ar trebui să fie înlocuită cu esența „bărbați“ (fără soț, fără o soție).
Acum redefini entitatea pivot ca o entitate care nu este nici o asociație, nici desemnarea oricărei caracteristici. Aceste entități au o existență independentă, chiar dacă acestea pot reprezenta și alte persoane, cum ar fi personalul desemnat departamentele.
În cele din urmă, ia în considerare exemplul de construire a modelului bazei de date Infological, „Nutriție“, care trebuie să fie păstrate pe vasele de informație (fig. 2.3), produsele lor de zi cu zi de consum, din care aceste feluri de mâncare preparate, și furnizorii acestor produse. Informațiile vor fi folosite de către bucătarul-șef și unitățile de alimentație publică mici, precum și vizitatorii săi.
1. lobio în limba georgiană
fasole polilinie purificată, sare ceapa, piper și se presară în ulei cu simmered o cantitate mică de bulion; Se adaugă coriandru, pătrunjel, Reagan (busuioc) și se fierbe până gata. Apoi se coace în cuptor.
fasole (conserve sau proaspete) 200
ceapa verde 40 Unt 30 10 Green.
Se obțin 210 Calorii 725.
Fig. 2.3. EXEMPLUL reteta de gătit
Cu ajutorul acestor oameni sunt marcate cu următoarele obiecte și caracteristici ale bazei proiectate:
Feluri de mâncare, pentru a descrie datele care sunt necesare, incluse în rețetele lor: numărul de feluri de mâncare (de exemplu, dintr-o carte de rețete), numele fel de mâncare, un fel de fel de mâncare (aperitiv, supă, etc.), rețeta (tehnologii de gătit) randament (porțiuni de greutate), numele, greutatea și conținutul caloric al fiecărui produs inclus în masă.
Consumul zilnic de alimente (cheltuieli): portii vase, data.
obiecte de analiză se pot distinge:
baruri Platanele alimentare și a orașului;
Asociația Compoziție (se leagă cu produsele alimentare) și
Livrări (furnizor leagă cu produse);
Rețete și caracteristici de curgere.
Diagrama ER-modelul prezentat în Fig. 2.4. iar modelul de limbă YAIM este după cum urmează:
Feluri de mâncare (BL, vase, Side)
Produse (PR, Calorie produs)
Furnizori (PIC City, furnizor) [Oraș]
Compoziția [Food M, N Products] (PB, PR, Greutate (g))
Supplies [Furnizori M, N Products] (PIC, PR, Data_P, pret, greutate (kg))
Oraș (oraș, țară)
Rețete (BL, reteta)
Flow (BL, PROBEI Data_R)
În aceste modele, vase, produse și furnizor - numele și BL, PR si POS - feluri de mâncare coduri numerice, produse și organizații care furnizează aceste produse.
Fig. 2.4. Modelul bazei de date Infological, „Nutriție“
2.4. Pe cheile primare și străine
Să ne amintim că o cheie sau o cheie posibil - acest lucru este setul minim de atribute, valoarea care se poate găsi în mod unic instanța dorită a entității. Minimalitatea înseamnă că excluderea unui set de orice atribut care nu identifică natura rămase. Fiecare entitate are cel puțin o cheie posibilă. Una dintre ele este luată ca fiind cheia primară. La selectarea cheia primară pentru a fi preferată cheie noncomposite sau chei compuse dintr-un număr minim de atribute. Este adecvat să se utilizeze chei cu valori de text lung (preferabil folosind atributele întregi). Astfel, pentru a identifica studentul poate folosi un număr unic de înregistrare-carte, sau un set de nume, prenume, numele patronimic, numărul de grup, și pot fi atribute extinse, deoarece este posibilă apariția a două grupuri de elevi (și mai mulți studenți) cu același nume, prenumele și patronimic. Poor este, de asemenea, utilizat ca un număr de cheie nu este hrană, și numele său, cum ar fi „Snack de brânză topită“ Prietenia „cu șuncă și murături“ sau „iepure în sos de smântână cu crochete de cartofi și salată de varză roșie.“
Nu este permis să cheia primară a entităților de bază (orice atribut implicat în cheia primară) pentru a lua o valoare nulă. nu, nu va avea un individ, și, prin urmare, o instanță existentă a esenței de bază: În caz contrar, există o situație contradictorie. Din aceleași motive, trebuie să ne asigurăm unicitatea cheii primare.
Acum, despre chei străine:
În cazul în care entitățile cu entități Cravate A și B, acesta ar trebui să includă chei externe, chei primare entități A și B. corespunzătoare
În cazul în care entitatea în entitatea reprezintă A, atunci ar trebui să includă o cheie externă, cheia primară corespunzătoare a entității A.
În Sec. 2.3 a fost considerat un exemplu în care „angajați“ înseamnă „departamente“ și a inclus străine cheie „numărul de card“, care corespunde cheii primare a entității „Departamente“.
Legătura dintre cheile primare și externe ale entităților ilustrate în Fig. 2.5.
Fig. 2.5. Structuri: a - asociația; b - indicații (caracteristici)
Să însemne orice în prezentul document entității asociate (tije, caracteristici, simboluri sau asociații) utilizează un nou termen generic „țintă“ sau „entitate țintă“.
Astfel, atunci când se analizează problema alegerii modului de reprezentare a asociațiilor și a simbolurilor în datele de bază problema principală, care ar trebui să răspundă: „? Care sunt cheile străine“. Și apoi, pentru fiecare cheie externă trebuie să fie abordate trei întrebări:
1. Poate cheia externă ia valori nule (NULL-valori)? Cu alte cuvinte, ar putea exista o anumită instanță a unei entități de acest tip, pentru care entitatea țintă necunoscută specifică cheia externă? În cazul aprovizionării este, probabil, imposibil - livrarea efectuată de către un furnizor necunoscut, sau livrarea unui produs necunoscut sunt lipsite de sens. Dar, în cazul angajaților, această situație, dar s-ar putea avea sens - este posibil ca orice angajat care nu este înscris în prezent la toate în orice departament. Rețineți că răspunsul la această întrebare nu depinde de bunul plac al designerului de baze de date, și este determinată de cursul real al acțiunilor întreprinse în acea parte a lumii reale, care urmează să fie prezentată în baza de date dată. Observații similare sunt, de asemenea, relevante pentru problemele discutate mai jos.
2. Ce ar trebui să se întâmple atunci când încearcă să elimine entitatea țintă căruia i trimiterile străine cheie? De exemplu, atunci când ștergerea unui furnizor care a efectuat cel puțin o livrare. Există trei posibilități:
Delete „în cascadă“, în scopul de a elimina ca furnizarea de acest furnizor.
Pentru toate livrările furnizorului astfel NULL valoarea cheii externe este setată la o valoare nulă, iar apoi actualizați furnizor cheie primară. O astfel de posibilitate este, desigur, nu se aplică în cazul în care cheia externă nu trebuie să conțină NULL valori.
Astfel, pentru fiecare cheie străină în proiectantul bazei de date de proiect trebuie să specifice nu numai câmpul sau combinație de câmpuri care alcătuiesc cheia externă și tabela destinație care este identificată prin această cheie, dar, de asemenea, răspunsurile la cele de mai sus trei întrebări (trei limitări care se aplică la această cheie externă).
În cele din urmă, cu privire la caracteristicile - înseamnă entitățile a căror existență depinde de tipul de entități desemnate. Desemnarea apare ca o cheie externă în tabelul corespunzător acestei caracteristici. Dar cele trei discutat mai sus restricțiile privind cheia externă în acest caz, ar trebui să fie specificate după cum urmează:
NULL-valori nu sunt permise
ȘTERGE cascadelor (țintă)
UPDATE (obiectiv cheie primară) cascadelor
Aceste specificații sunt dependente de existența entităților caracteristice.
2.5. constrângeri
Conceptul de integritate a datelor
Integritatea (de Integritate Engleză -. Integritate, integritate, integritate, integritate) - înțeleasă ca corectitudinea datelor în orice moment. Dar acest obiectiv poate fi atins doar în anumite limite: baza de date nu poate controla exactitatea fiecărei valori introduse în baza de date (deși fiecare valoare poate fi verificată pentru plauzibilitate). De exemplu, se poate constata că valoarea introdusă este de 5 (care reprezintă numărul de zile din săptămână) într-adevăr ar trebui să fie egală cu 3. Pe de altă parte, valoarea 9 este în mod clar eronată și SGBD trebuie să-l respingă. Cu toate acestea, pentru acest lucru trebuie raportat că numărul de zile ale săptămânii ar trebui să aparțină setul de (1,2,3,4,5,6,7).
Menținerea integrității bazei de date poate fi considerată ca o protecție a datelor împotriva modificărilor incorecte sau deteriorarea (a nu se confunda cu alterarea ilegală și distrugerea, este o problemă de securitate). bază de date moderne au unele mijloace pentru a asigura menținerea integrității (precum și mijloacele necesare pentru a asigura menținerea siguranței).
tipuri de integritate
Există trei grupuri de reguli de integritate:
Integritatea entităților.
Integritate, definit de utilizator.
În Sec. 2.4 a fost considerată motivație două integritate reguli comune pentru toate bazele de date relaționale.
Nu este permis oricarui atribut care participă la o cheie primară, a avut o valoare nespecificată.
Valoarea cheie externă trebuie să fie:
să fie egală cu valoarea cheii țintă primară;
să fie complet nesigur, adică fiecare valoare atribut implicat în cheia externă trebuie să fie nulă.
Pentru orice bază de date special, există o serie de norme specifice suplimentare care i se aplică, și unul definit de către dezvoltator. Cel mai adesea controlate de:
unicitatea anumitor atribute,
interval de valori (Examinare scor la 2 la 5),
Valorile set de accesorii (jumătate "M" sau "W").
2.6. La construirea modelului Infological
DB cerințe de către administrator, și programator cerere
Dificultatea principală a percepției a recomandărilor cuprinse în capitolul patru și anexa B, planul pur psihologic.
Într-adevăr, pentru determinarea listei și structura datelor stocate este necesară pentru a colecta informații cu privire la cererile reale și potențiale, precum și utilizatorii bazei de date, iar modelul de construcție Infological ar trebui să vă faceți griji doar cu privire la fiabilitatea acestor date, uitând complet de aplicații și utilizatorii, care creează o bază date.
Acest lucru se datorează cerințelor diferite complet la baza de dezvoltatori de aplicații și date de administrator de baze de date. În primul rând ar dori să aibă într-un singur loc (de exemplu, în același tabel), toate datele de care au nevoie pentru punerea în aplicare a solicitării din programul de aplicație sau terminal. Al doilea este preocupat de excluderea posibilelor denaturări ale datelor stocate când intră în baza de date a unor noi date de informații, și actualizarea sau ștergerea celor existente. Pentru a face acest lucru, acestea sunt eliminate din baza de date duplicate și relațiile funcționale nedorite între atribute, baza de date cu divizare în mai multe mese mici (a se vedea. P. 4.6). Deoarece mulți ani de experiență la nivel mondial în utilizarea sistemelor informatice, care se bazează pe date arată că defecte de proiectare nu pot fi corectate prin orice trucuri în programele de aplicații, designeri cu experiență nu își poate permite să meargă pentru a satisface programatorii de aplicații (chiar și atunci când acestea sunt ele însele astfel).
recomandări
facă o distincție clară între lucruri cum ar fi solicitarea de date și datele de întreținere (de intrare, modificare, ștergere);
amintiți-vă că, de regulă, baza de date este baza de informații nu una, ci mai multe aplicații, dintre care unele vor apărea în viitor;
de proiectare a bazei de date Bad nu poate fi corectată prin orice (chiar și cele mai sofisticate) aplicații.