1. Concepte de bază și termeni la subiect
„MODEL INFORMATIV – BAZA CONSTRUCTII
SISTEME DE MANAGEMENT BAZ DE DATE.

Fiecare civilizație trebuie să se ocupe de procesarea informațiilor. Pe măsură ce economia se dezvoltă și populația crește, la fel crește și volumul de date interconectate necesare pentru a rezolva problemele de afaceri și administrative.

@ Modelul de colectare, stocare, prelucrare și utilizare a datelor interconectate în scopul gestionării cât mai optime a fluxurilor de informații și soluționării sarcinilor atribuite într-un anumit domeniu se numește sistem informațional. ... Un astfel de sistem este conceput în primul rând pentru a facilita munca umană, dar pentru aceasta trebuie să corespundă cât mai bine unui model foarte complex al lumii reale.

@ Miezul sistemului informatic îl reprezintă datele stocate în acesta. ... În orice întreprindere, datele diferitelor departamente, de regulă, se suprapun, adică sunt utilizate în mai multe departamente sau sunt în general partajate. De exemplu, scopurile de management necesită adesea informații în întreaga întreprindere. Comanda de piese nu este posibilă fără disponibilitatea informațiilor privind stocurile. Datele stocate în sistemul informațional trebuie să fie ușor accesibile în forma în care sunt necesare pentru activitatea specifică de producție a întreprinderii. În acest caz, modul de stocare a datelor nu este esențial. Astăzi, la întreprindere putem găsi un tip tradițional de sistem de procesare a datelor, în care un angajat plasează manual datele într-un liant, iar lângă el - un sistem modern care utilizează cele mai rapide computere, cel mai sofisticat hardware și software. În ciuda diferențelor lor izbitoare, ambele sisteme trebuie să ofere informații fiabile la un moment dat, unei anumite persoane, într-un anumit loc și la un cost limitat.

Pentru a înțelege procesul de construire a unui sistem informațional, trebuie să cunoașteți o serie de termeni care sunt utilizați pentru a descrie și prezenta datele.

@ Domeniul subiectului este partea unui sistem real care prezintă interes pentru acest studiu.

La proiectarea sistemelor informatice automatizate, tematica este afișată prin modele de date de mai multe niveluri. Numărul de niveluri utilizate depinde de complexitatea sistemului, dar în orice caz include nivelurile logice și fizice. Un domeniu se poate referi la orice tip de organizație (de exemplu, o bancă, universitate, spital sau fabrică).

Este necesar să se facă distincția între domeniul complet (întreprindere de producție mare, depozit, magazin universal etc.) și unitatea organizatorică a acestui domeniu. O unitate organizațională, la rândul ei, poate reprezenta propriul domeniu (de exemplu, un atelier pentru producția de caroserii dintr-o fabrică de automobile sau un departament de prelucrare a datelor al unei întreprinderi de producție de computere). În acest caz, atelierele și departamentele în sine pot corespunde anumitor domenii.

Informațiile necesare pentru a descrie subiectul depind de modelul actual și pot include informații despre personal, salarii, bunuri, facturi, facturi, rapoarte de vânzări, teste de laborator, tranzacții financiare, dosare medicale, adică informații despre oameni, locuri, obiecte , evenimente și concepte.

@ Obiect este un element al sistemului informatic, informații despre care stocăm. În teoria bazelor de date relaționale, un obiect se numește entitate.

Obiectul poate fi real(de exemplu, o persoană, un obiect sau loc) și abstract(de exemplu, un eveniment, un cont de client sau un curs urmat de studenți). Deci, în domeniul vânzărilor de mașini, exemple de obiecte sunt MODEL AUTO, CLIENT și CONT. Intr-un depozit este un FURNIZOR, MARFURI, TRIMITERE etc. Fiecare obiect are un anumit set de proprietati care sunt stocate in sistemul informatic. Când procesați date, de multe ori trebuie să vă ocupați de o colecție de obiecte omogene, cum ar fi angajații, și să înregistrați informații despre aceleași proprietăți pentru fiecare dintre ele.

@ Clasa de obiecte numiți un set de obiecte care au același set de proprietăți.

Astfel, pentru obiectele din aceeași clasă, setul de proprietăți va fi același, deși valorile acestor proprietăți pentru fiecare obiect pot fi, desigur, diferite. De exemplu, proprietățile MODEL ale clasei de obiecte pentru fiecare obiect pot fi desigur diferite. De exemplu, o clasă de obiecte MODEL AUTO va avea același set de proprietăți care descriu caracteristicile vehiculului, iar fiecare model va avea valori diferite pentru acele caracteristici.

Obiectele și proprietățile lor sunt concepte din lumea reală. În lumea informațiilor care există în viziunea programatorului, se vorbește despre atributele obiectelor.

@ Atribut este o afișare informațională a proprietăților obiectului. Fiecare obiect este caracterizat de un număr de atribute de bază.

De exemplu, un model de mașină se caracterizează prin tipul de caroserie, cilindreea motorului, numărul de cilindri, puterea, dimensiunile, denumirea etc. Clientul unui magazin auto are atribute precum numele, prenumele, patronimul, adresa și eventual un număr de identificare. Fiecare atribut din model trebuie să aibă un nume unic - un identificator. Un atribut în implementarea unui model de informații pe orice purtător de informații este adesea numit element de date, câmp de date sau doar un câmp.

Orez. 1.1. Trei domenii de prezentare a datelor.

@ masa este o structură regulată constând dintr-un set finit de înregistrări de același tip. În unele surse, un tabel se numește relație.

Vom încerca să evităm ultimul termen, deoarece odată cu dezvoltarea teoriei relaționale, „relație” împreună cu termenul „relație” au început adesea să numească relații între tabele. Fiecare înregistrare a unui tabel constă dintr-un număr finit (și același!) de câmpuri, și câmpul specific al fiecărei înregistrări dintr-un tabel poate conține doar date de un singur tip.

@ Valorile datelor reprezintă datele reale conținute în fiecare element de date.

Elementul de date „NUMELE MODELULUI” poate avea valori precum „Voyager” 96 3.8 Grand”, „Continental 4.6” sau „Crown Victoria 4.6.” În funcție de modul în care elementele de date descriu obiectul, valorile acestora pot fi cantitative , calitative sau descriptive Informațiile despre un anumit domeniu pot fi reprezentate folosind mai multe obiecte, fiecare dintre acestea fiind descrisă de mai multe elemente de date. date.

@ Se numește un singur set de valori acceptate de elementele de date o instanță a unui obiect... Obiectele comunică între ele într-un anumit mod.

@ Se numește modelul corespunzător al obiectelor cu elementele de date și relațiile lor constitutive model conceptual domeniul subiectului. Modelul conceptual oferă o idee despre fluxul de date din domeniu.

Unele elemente de date au o proprietate importantă pentru construirea unui model informațional. Dacă cunoaștem valoarea pe care o ia un astfel de element de date al unui obiect, putem identifica valorile pe care le iau alte elemente de date ale aceluiași obiect. De exemplu, cunoscând numărul unic de model al mașinii - 7, putem determina că acesta este „Voyager“ 96 „și că cilindreea motorului pentru acest model este „3778”.

@ Elementul cheie datele se numesc un element prin care puteți determina valorile altor elemente de date.

Două sau mai multe elemente de date pot identifica în mod unic un obiect. În acest caz, ei sunt numiți „candidați” pentru elementele de date cheie. Întrebarea este , care dintre candidați să folosească pentru accesarea obiectului este decis de utilizator sau de proiectantul sistemului. Trebuie avut grijă atunci când alegeți elementele cheie de date, deoarece alegerea celui potrivit vă va ajuta să creați modelul conceptual de date potrivit.

@ Cheia principala este un atribut (sau un grup de atribute) care identifică în mod unic fiecare rând dintr-un tabel.

Conceptul cheie primară este extrem de importantîn legătură cu conceptul de integritate a bazei de date, despre care vom discuta în detaliu la sfârșitul acestei secțiuni.

@ Tasta alternativă este un atribut (sau un grup de atribute) care nu se potrivește cu cheia primară și care identifică în mod unic o instanță a unui obiect.

De exemplu, pentru obiectul „EMPLOYEE”, care are atributele „EMPLOYEE ID”, „SURNUME”, „PRINUME” și „SUMNUM”, grupul de atribute „LAST NUME”, „NUME”, „PATRONY” poate fi un cheie alternativă în raport cu atributul „ID ANGAJAT” (presupunând că compania nu are nume complet).

@ Cheie externă este un atribut de tabel care este cheia primară a altui tabel.

De exemplu, atributul „NUMĂR DE MODEL” al unui obiect VEHICUL poate fi o cheie străină pentru un obiect „MODEL”.

@ Înregistrarea datelor este o colecție de valori ale elementelor de date aferente.

În fig. 1.2. astfel de articole sunt cheia unică și numele modelului, deplasarea, numărul de cilindri și puterea motorului. De exemplu, una dintre intrările - „7 Voyager'96 3.8 Grand 3778 6 164.0”. Acest șir reprezintă valorile pe care le iau elementele de date ale obiectului MODEL. Înregistrările sunt stocate pe un mediu, care poate fi un creier uman, o foaie de hârtie, memoria computerului, dispozitivul de stocare extern etc.

MODEL
CHEIE DE MODEL UNIC	Numele modelului	Volumul de lucru (cm cubi)	Putere (CP)
	GMC Jimmy 4.3
7	Voyager'96 3.8 Grand	3778	164,0
	Stealth 3.0
	348 Păianjen 3.4

Figura 1.2. Înregistrări de date ale obiectului MODEL.

Fiecare înregistrare a unui tabel constă dintr-un număr finit (și același!) de câmpuri, și câmpul specific al fiecărei înregistrări dintr-un tabel poate conține doar date de un singur tip

@ Tip de date caracterizează tipul de date stocate.

Conceptul de tip de date din modelul informațional este complet adecvat conceptului de tip de date din limbajele de programare. De obicei, SGBD-urile moderne permit stocarea de caractere, date numerice, șiruri de biți, date numerice specializate (de exemplu, sume în unități monetare), precum și date cu un format special (data, oră, interval de timp etc.). În orice caz, atunci când alegeți un tip de date, trebuie să țineți cont de capacitățile SGBD-ului cu care va fi implementat modelul fizic al sistemului informațional.

@ Conexiune este o relație funcțională între entități.

Dacă există o relație între unele entități, atunci faptele de la o entitate se referă sau sunt legate într-un fel de faptele de la o altă entitate. Menținerea consistenței dependențelor funcționale dintre entități se numește integritate referențială. Întrucât relațiile sunt conținute „în interiorul” modelului relațional, implementarea integrității referențiale poate fi realizată atât de către aplicație, cât și de către SGBD în sine (folosind mecanisme declarative de integritate referențială și declanșatoare).

Legăturile pot fi reprezentate de cinci caracteristici principale:

Tip link (identificare, neidentificare)

Entitatea-mamă;

Entitate copil (dependentă);

Puterea de comunicare (cordialitate);

Sunt permise valori nule.

Relația se numește identificare dacă instanța entității copil este identificată (identificată în mod unic) prin relația sa cu entitatea mamă. Atributele care alcătuiesc cheia primară a entității părinte sunt de asemenea incluse în cheia primară a entității copil. Entitate copil cu o relație de identificare mereu dependent.

Relația se numește neidentificare dacă instanța entității fiu este identificată diferit decât printr-o relație cu entitatea-mamă. Atributele care alcătuiesc cheia primară a entității părinte sunt, de asemenea, incluse în atributele non-cheie ale entității copil.

Puterea de comunicare este raportul dintre numărul de instanțe ale entității-mamă și numărul corespunzător de instanțe ale entității fii. Pentru orice altă relație decât nespecifică, această relație este scrisă ca 1: n.

@ Proceduri stocate este o aplicație (program) care combină interogări și logica procedurală (instrucțiuni de atribuire, ramificare logică etc.) și este stocată într-o bază de date.

Procedurile stocate vă permit să conțineți, împreună cu baza de date, programe destul de complexe care efectuează o cantitate mare de muncă fără a transfera date prin rețea și a interacționa cu clientul. De obicei, programele scrise în procedurile stocate sunt asociate cu prelucrarea datelor. Astfel, baza de date poate fi un strat independent funcțional al aplicației care poate interacționa cu alte straturi pentru a primi interogări sau a actualiza date.

@ Reguli vă permit să apelați execuția acțiunilor specificate atunci când modificați sau adăugați date în baza de date (DB) și astfel controlați adevărul datelor plasate în ea.

De obicei, o acțiune este un apel la o anumită procedură sau funcție. Regulile pot fi asociate cu un câmp sau o înregistrare și, în consecință, pot fi declanșate atunci când se modifică datele dintr-un anumit câmp sau înregistrare tabel. Nu puteți folosi reguli când ștergeți datele. Spre deosebire de constrângeri, care sunt doar un mijloc de a controla condiții relativ simple pentru introducerea corectă a datelor, regulile vă permit să verificați și să mențineți relații arbitrar complexe între elementele de date din baza de date.

@ Integritate referenţială se asigură că valoarea cheii externe a instanței entității copil se potrivește cu valorile cheii primare din entitatea părinte.

Integritatea referenţială poate fi monitorizată pentru toate operaţiunile care modifică datele.

@ Normalizarea relațiilor este procesul de construire a structurii optime de tabele și relații într-o bază de date relațională.

În procesul de normalizare, elementele de date sunt grupate în tabele care reprezintă obiecte și relațiile lor. Teoria normalizării se bazează pe faptul că un anumit set de tabele are proprietăți mai bune în includerea, modificarea și ștergerea datelor decât toate celelalte seturi de tabele cu care pot fi reprezentate aceleași date. Introducerea normalizării relațiilor în dezvoltarea unui model informațional asigură cantitatea minimă de fizică, adică înregistrată pe orice suport, bază de date și performanța maximă a acesteia, care afectează direct calitatea sistemului informațional. Normalizarea modelului informațional se realizează în mai multe etape (forma normală 1, 2 și 3).

@ Dicționar de date este un depozit centralizat de informații despre obiecte, elementele lor de date constitutive, relațiile dintre obiecte, sursele, valorile, utilizarea și formatele de prezentare ale acestora.

@ Asigurarea integritatii baza de date se numește un sistem de măsuri care vizează menținerea corectitudinii datelor din baza de date la un moment dat.

Costurile de verificare și menținere a acurateții datelor pot reprezenta o parte semnificativă din total operațională cheltuieli. De exemplu, în companiile de transport, pentru a controla corectitudinea introducerii datelor din documentele de călătorie, se practică introducerea în paralel a acelorași date de către mai mulți operatori. Se crede că probabilitatea de a comite aceeași eroare în acest caz va fi extrem de mică și o simplă comparație a rezultatelor introducerii diferiților operatori va ajuta la obținerea de date fără erori. Într-un SGBD, integritatea datelor este asigurată de un set de oferte speciale numite constrângeri de integritate.

@ Constrângeri de integritate este un set de reguli definite care stabilesc valabilitatea datelor și relațiile dintre acestea.

Un sistem automat de procesare a datelor se bazează pe utilizarea unui model de date sau model de informații specific. Modelul de date reflectă relațiile dintre obiecte.

2. Secvența creării unui model informațional

Procesul de creare a modelului informațional începe prin definirea cerințelor conceptuale ale unui număr de utilizatori (Figura 2.1). Cerințele conceptuale pot fi definite și pentru unele sarcini (aplicații) care nu sunt planificate a fi implementate în viitorul apropiat. Acest lucru poate crește ușor complexitatea lucrării, cu toate acestea, va ajuta la luarea în considerare pe deplin a tuturor nuanțelor funcționalității necesare sistemului în curs de dezvoltare și va reduce probabilitatea modificării acestuia în viitor. Cerințele individuale ale utilizatorului sunt integrate într-o singură „vizualizare generică”. Acesta din urmă este numit model conceptual.

@ Model conceptual reprezintă obiectele și relațiile lor fără a specifica modul în care sunt stocate fizic.

Astfel, modelul conceptual este în esență un model de domeniu. La proiectarea unui model conceptual, toate eforturile dezvoltatorului ar trebui să fie îndreptate în principal către structurarea datelor și identificarea relațiilor dintre acestea, fără a lua în considerare caracteristicile de implementare și problemele de eficiență a procesării. Proiectarea modelului conceptual se bazează pe analiza sarcinilor de prelucrare a datelor rezolvate în această întreprindere. Modelul conceptual include descrieri ale obiectelor și a interrelațiilor dintre acestea care prezintă interes în domeniul analizat și care sunt identificate ca rezultat al analizei datelor. Aceasta se referă la datele folosite atât în ​​programele de aplicație deja dezvoltate, cât și în cele care vor fi doar implementate.

Modelul conceptual este apoi tradus într-un model de date compatibil cu SGBD selectat. Este posibil ca relațiile dintre obiectele reflectate în modelul conceptual să se dovedească ulterior a fi irealizabile prin intermediul SGBD-ului selectat. Acest lucru va necesita o schimbare a modelului conceptual. Versiunea modelului conceptual care poate fi furnizată de un anumit SGBD se numește model logic.

@ Model logic reflectă conexiunile logice dintre elementele de date, indiferent de conținutul și mediul de stocare al acestora.

Modelul de date logic poate fi relațional, ierarhic sau în rețea ... Utilizatorilor li se aloca subseturi ale acestui model logic, numite modele externe (în unele surse, acestea sunt numite și subscheme), reflectând înțelegerea lor asupra domeniului. Model extern corespunde vederilor pe care utilizatorii le obțin pe baza modelului logic, în timp ce cerințe conceptuale reflectă percepțiile pe care utilizatorii și-au dorit inițial și care au stat la baza dezvoltării modelului conceptual. Modelul logic este mapat pe memoria fizică, cum ar fi disc, bandă sau alt mediu de stocare.

@ Modelul fizic care definește plasarea datelor, metodele de acces și tehnicile de indexare se numește modelul intern al sistemului.

Din punct de vedere al programării aplicate, independența datelor este determinată nu de tehnica de programare, ci de disciplina acesteia. De exemplu, pentru a evita recompilarea aplicației în orice modificare a sistemului, se recomandă să nu se definească constante (valori constante ale datelor) în program. Cea mai bună soluție este să transmiteți valori ca parametri programului.

Toate cerințele reale ale domeniului subiectului și cerințele „ascunse” corespunzătoare în etapa de proiectare ar trebui să fie reflectate în modelul conceptual. Desigur, orice posibilă utilizare și modificare a bazei de date nu poate fi avută în vedere. Dar în majoritatea domeniilor, datele de bază, cum ar fi obiectele și relațiile lor, sunt relativ stabile. Se schimbă doar cerințele de informare, adică modul în care datele sunt utilizate pentru a obține informații.

Gradul de independență a datelor este determinat de proiectarea atentă a bazei de date. Analiza cuprinzătoare a obiectelor de domeniu și a relațiilor lor minimizează impactul modificării cerințelor de date dintr-un program asupra altor programe. Aceasta este independența totală a datelor.

3. Relații în model

O relație exprimă o afișare sau o relație între două seturi de date. Există relații de tipul " unu la unu», « unu la multi" și „Mulți la mulți". În problema luată în considerare a automatizării gestionării activității unui dealer auto, dacă un client face o comandă pentru achiziționarea unei mașini pentru prima dată, se efectuează înregistrarea inițială a datelor și informațiilor sale despre comandă. Dacă clientul re-comandă, doar această comandă este înregistrată. Indiferent de câte ori un anumit client a făcut comenzi, acesta are un număr unic de identificare (cheie unică de client). Informațiile despre fiecare client includ numele clientului, adresa, telefon, fax, prenume, prenume, patronim, personalitate juridică și o notă. Astfel, atributele obiectului CLIENT sunt „CHEIA CLIENT UNIC”, „NUMELE CLIENT”, „ADRESA CLIENT”, etc. Următorul obiect de interes pentru noi este MODELUL AUTO. Acest obiect are atributele „CHEIE UNICA DE MODEL”, „NUME MODEL”, etc. Al treilea obiect luat în considerare este COMANDA. Atributele sale sunt „NUMĂRUL COMANDEI”, „CHEIA CLIENT” și „CHEIA MODELULUI”. Iar al patrulea obiect luat în considerare este VÂNZĂTORUL. Atributele sale sunt „CHEIA UNICĂ A VÂNZĂTORULUI”, „NUMELE VÂNZĂTORULUI”, „NUMELE” și „PATRONAL”.

Relație unu-la-unu (între două tipuri de obiecte)

Să ne întoarcem mental la vremurile economiei de distribuție planificată. Să presupunem că un client poate face o singură comandă la un moment dat. In acest caz se stabileste o relatie intre obiectele CLIENT si COMANDA. unu la unu", Notat cu săgeți simple, așa cum se arată în fig. 2.2, a.

Orez. 2.2. Relația dintre două obiecte: a) „unu la unu”; b) „unu la mulți”; c) „mulți la mulți”

Orez. 2.3. Relația dintre date într-o relație unu-la-unu.

Relație unu-la-mulți (între două tipuri de obiecte).

La un moment dat, un client poate deveni proprietarul mai multor modele de mașini, în timp ce mai mulți clienți nu pot fi proprietarii aceleiași mașini. O relație unu-la-mai mulți poate fi desemnată folosind o singură săgeată îndreptată spre unul și o săgeată dublă îndreptată către mulți, așa cum se arată în Figura 4-2. 2.2, b.

În acest caz, mai multe înregistrări ale celui de-al doilea obiect (copil sau subordonat) vor corespunde unei înregistrări de date a primului obiect (este adesea numită părinte sau principală). Relațiile unu-la-mulți sunt foarte frecvente în proiectarea bazelor de date relaționale. Dicționarul este adesea folosit ca obiect părinte, iar cheile unice pentru accesarea înregistrărilor din dicționar sunt stocate în copil. În exemplul nostru, ca atare referință, vă puteți imagina obiectul CLIENT, care stochează informații despre toți clienții. Când accesăm o înregistrare pentru un anumit client, avem o listă cu toate achizițiile pe care le-a făcut și informații despre care sunt stocate în obiectul MODEL AUTO, așa cum se arată în Fig. 2.4. Dacă există unele înregistrări în obiectul copil pentru care nu există înregistrări corespunzătoare în obiectul CLIENT, atunci nu le vom vedea. În acest caz, se spune că obiectul conține înregistrări pierdute (singurate). Acest lucru nu este permis, iar în viitor veți învăța cum să evitați astfel de situații.

Orez. 2.4. Relația dintre date într-o relație unu-la-mulți.

Dacă ne uităm la înregistrările obiectului MODEL AUTO, atunci în obiectul CLIENT putem obține date despre clientul care a cumpărat acest autoturism (vezi fig. 2.4). Vă rugăm să rețineți că nu vom primi detalii despre clienți pentru înregistrările pierdute.

Relație multi-la-mulți (între două tipuri de obiecte).

În acest exemplu, fiecare agent de vânzări poate deservi mai mulți clienți. Pe de altă parte, achiziționând mașini la momente diferite, fiecare client poate fi servit de diferiți vânzători. Există o relație multi-la-mulți între obiectele CLIENT și VÂNZĂTOR. Această relație este indicată de săgeți duble, așa cum se arată în Fig. 2.2, c.

În fig. 2.5 prezintă o diagramă conform căreia datele vor fi interconectate în acest caz. Privind datele din obiectul CLIENT, vom putea afla ce vânzători au servit un anumit client. Totuși, în obiectul VÂNZĂTOR, în acest caz, va trebui să creăm mai multe înregistrări pentru fiecare vânzător. Fiecare linie va corespunde fiecărui serviciu clienți oferit de vânzător. Cu această abordare, ne vom confrunta cu probleme serioase. De exemplu, nu putem introduce o cheie unică pentru fiecare vânzător în obiectul VÂNZĂTOR, deoarece în mod inevitabil un vânzător va deservi mai mulți clienți, iar în acest caz vom avea mai multe înregistrări pentru același vânzător.

Orez. 2.5. Relația dintre date într-o relație multi-la-mulți

Conform teoriei bazelor de date relaționale, stocarea unei relații multi-la-mulți necesită trei obiecte: unul pentru fiecare entitate și unul pentru stocarea relațiilor dintre ele (un obiect intermediar). Obiectul intermediar va conține identificatorii obiectelor înrudite, așa cum se arată în Fig. 2.6.

Orez. 2.6. Afișarea relației dintre date într-o relație multi-la-mulți folosind un obiect intermediar

Relațiile dintre obiecte fac parte din modelul conceptual și trebuie afișate în baza de date. Alături de relațiile dintre obiecte, există relații între atributele unui obiect. De asemenea, face distincția între relațiile unu-la-unu, unu-la-mulți și multe-la-mulți.

Relație unu-la-unu (între două atribute)

Presupunem că cheia (numărul) clientului este identificatorul său unic, adică nu se modifică cu comenzile ulterioare de la acest client. Dacă, împreună cu numărul clientului, în baza de date este stocat un alt identificator unic (de exemplu, un număr de pașaport), atunci există o relație unu-la-unu între acești doi identificatori unici. În fig. 2.7, a această relație este indicată de săgeți simple.

Relație unu-la-mai mulți (între două atribute)

Numele clientului și numărul clientului coexistă. Pot exista mulți clienți cu același nume, dar toți au numere diferite. Fiecărui client i se atribuie un număr unic. Aceasta înseamnă că există un singur nume pentru un anumit număr de client. Relația „unu la mulți” este indicată printr-o singură săgeată în direcția „unu” și o săgeată dublă în direcția „mulți” (Figura 2.7, b).

Relație multi-la-mulți (între două atribute)

Mai mulți clienți cu același nume ar putea fi serviți de mai mulți furnizori. Este posibil ca mai mulți vânzători cu același nume să fi primit comenzi de la mai mulți clienți. Există o relație multi-la-mulți între numele clientului și atributele numelui vânzătorului. Notăm această relație cu săgeți duble (Fig. 2.7, în).

A)

b)

v)

Orez. 2.7. Relații între două atribute:
a) relația „unu la unu”; b) relația unu-la-mai mulți» c) relaţia „mulţi la mulţi»

Tipuri de modele de date

Modelele de date ierarhice și de rețea au început să fie utilizate în sistemele de management al bazelor de date la începutul anilor ’60. La începutul anilor '70, a fost propus un model de date relaționale. Aceste trei modele diferă în principal prin modul în care reprezintă relațiile dintre obiecte.

Modelul ierarhic de date este construit pe principiul unei ierarhii de tipuri de obiecte, adică un tip de obiect este cel principal, iar restul, situat la nivelurile inferioare ale ierarhiei, sunt subordonate (Fig. 2.8). Între obiectele principale și subordonate se stabilește o relație unu-la-mulți. Cu alte cuvinte, există mai multe tipuri de obiecte subordonate pentru un anumit tip de obiect principal. În același timp, pentru fiecare instanță a obiectului principal, pot exista mai multe instanțe de tipuri de obiecte subordonate. Astfel, relațiile dintre obiecte sunt similare cu relațiile dintr-un arbore genealogic cu o excepție: poate exista un singur tip de obiect original (principal) pentru fiecare tip de obiect generat (subordonat o). Pe orez. 2.8 nodurile și ramurile formează o structură arborescentă ierarhică. Un nod este o colecție de atribute care descriu un obiect. Cel mai înalt nod din ierarhie se numește nodul rădăcină (acesta este tipul de obiect principal). Nodul rădăcină este la primul nivel. Nodurile dependente (tipurile de obiecte subordonate) sunt la nivelul al doilea, al treilea etc.

Orez. 2.8. Schema modelului de date ierarhice.

În modelul de date de rețea, conceptele de obiecte principale și subordonate sunt oarecum extinse. Orice obiect poate fi atât principal, cât și subordonat (în modelul de rețea, obiectul principal este notat cu termenul „proprietar al colecției”, iar subordonat prin termenul „membru al colecției”). Același obiect poate fi atât proprietarul, cât și membrul colecției în același timp. Aceasta înseamnă că fiecare obiect poate participa la orice număr de relații. O diagramă a modelului de rețea este prezentată în Figura 2.9.

Figura 2.9. Diagrama modelului de date de rețea.

În modelul de date relaționale, obiectele și relațiile dintre ele sunt reprezentate folosind tabele, așa cum se arată în Fig. 2.10. Relațiile sunt, de asemenea, considerate obiecte. Fiecare tabel reprezintă un obiect și este format din rânduri și coloane. Într-o bază de date relațională, fiecare tabel trebuie să aibă o cheie primară (element cheie) - un câmp sau o combinație de câmpuri care identifică în mod unic fiecare rând din tabel. Datorită simplității și naturaleței prezentării, modelul relațional este cel mai utilizat în DBMS pentru calculatoare personale.

Orez. 2.10. Schema modelului de date relaționale.

Tipuri de relații între obiectele domeniului subiect

Relațiile multiple pot fi de patru tipuri - unu-la-unu, unu-la-mulți, mulți-la-mulți și mulți-la-unu.

O relație unu-la-unu (1: 1) există atunci când o instanță a unui obiect este asociată cu o singură instanță a altuia. Relația este unică de la stânga la dreapta și de la dreapta la stânga.

Oportunitati

Director de întreprindere

O relație unu-la-mai multe (1: M) există atunci când o instanță a primului obiect este asociată cu una (sau mai multe) instanțe ale celui de-al doilea obiect, dar fiecare instanță a celui de-al doilea obiect este asociată cu o singură instanță a primului obiect. . Relația este unică de la dreapta la stânga.

Este format din

Cartier

O relație multi-la-mulți (M: M) există atunci când o instanță a primului obiect este asociată cu una sau mai multe instanțe ale celui de-al doilea și fiecare instanță a celui de-al doilea cu una sau mai multe instanțe ale primului.

Student (nume, număr carnet. Facultate) Subiect (nume, număr de ore)

O relație multi-la-unu (M: 1) este similară cu o relație unu-la-mulți. Link-ul este unic doar de la stânga la dreapta.

Prenume student (M: 1) Număr grup

Model conceptual... Se numește modelul obiectelor cu atributele care le descriu și relațiile dintre ele model conceptual... Acest model reprezintă obiectele și relațiile lor fără a specifica modul în care sunt stocate fizic.

Este prezentat grafic sub forma unei diagrame speciale propuse de specialistul american în baze de date C. Bachman. În diagramele Bachmann, obiectele sunt reprezentate de vârfurile unui anumit grafic matematic, legăturile sunt reprezentate de arcele graficului. Luați în considerare, de exemplu, modelul de date privind achizițiile (vezi Figura 48).

Orez. 48 Un exemplu de model conceptual

Modelul este format din trei obiecte: Furnizor, Comanda, Articol Relatia emisa existenta intre obiectele Furnizor si Comanda are o cardinalitate unu-la-mai multi, intrucat fiecare comanda se face catre un singur furnizor, dar se pot face mai multe comenzi catre acest furnizor. . Relația dintre obiectele Comandă și Articol are cardinalitate multi-la-mulți, deoarece o comandă conține mai multe articole și un articol poate apărea în mai multe comenzi.

Toate obiectele sunt active.

Controlul utilizatorului asupra grupurilor de ferestre.

Tipuri de ferestre orientate pe sarcini.

Realizarea instantanee a modificărilor.

Pictograme dinamice care reflectă starea obiectului.

Manipulare directă.

Combinarea obiectelor.

Compoziția obiectelor și a recipientelor.

Vedere multiplă consecventă a obiectelor.

Caracteristicile interfețelor grafice considerate mai sus, precum și tehnologia DCD care stă la baza implementării lor, necesită utilizarea unei abordări orientate pe obiecte pentru proiectarea GUI. Această abordare implică utilizarea analogiilor între obiectele software și obiectele din lumea reală. Din punct de vedere al interfeței cu utilizatorul, obiectele nu sunt doar fișiere sau pictograme, ci și orice dispozitiv de stocare și prelucrare a informațiilor, inclusiv celule, paragrafe, simboluri etc., precum și documentele în care se află.

Obiectele, indiferent dacă aparțin lumii reale sau au o întruchipare computerizată, au anumite caracteristici care ne ajută să înțelegem ce sunt și cum se comportă în anumite situații. Următoarele concepte descriu principalele aspecte și caracteristici ale obiectelor care au o variantă de realizare computerizată.

Proprietățile obiectului... Obiectele au anumite caracteristici sau atribute numite proprietăți care le determină prezentarea sau posibilele stări (de exemplu, culoarea, dimensiunea, data modificării). Proprietățile nu se limitează la caracteristicile externe sau vizibile ale obiectului. Ele pot reflecta organizarea lor internă sau starea curentă a obiectului.

Operații asupra obiectelor... Toate acțiunile care pot fi efectuate asupra (sau asupra) unui obiect sunt considerate operații valide. Mutarea sau copierea unui obiect sunt exemple de operații. Utilizatorul poate efectua operații asupra obiectelor folosind unul sau altul mecanism oferit de interfață (controlul comenzii sau manipularea directă).

Comunicarea (relația) între obiecte... Orice obiect într-un fel sau altul interacționează cu alte obiecte. În multe cazuri, relația dintre obiecte poate fi descrisă ca o relație de un anumit tip.

Tipuri de legături între obiecte.

Cele mai comune tipuri de relații sunt Colecții, Constrângeri și Compozite.

Kit este cel mai simplu tip de relație, care reflectă prezența unor proprietăți comune ale obiectelor. Rezultatele unei interogări (căutare după model) sau operarea unei selecții multiple de obiecte sunt exemple de utilizare a acestui tip de relație. Un avantaj important al acestui tip de relație este că vă permite să specificați operațiuni care trebuie să se refere la un anumit set de obiecte.

O asociere reflectă o relație mai strânsă între obiecte în care schimbarea unui obiect afectează un alt obiect din set. Cel mai simplu exemplu al unei astfel de relații este schimbarea formatului unei pagini adiacente atunci când adăugați text pe pagina anterioară.

Compoziţie are loc atunci când agregarea mai multor obiecte poate fi privită ca un obiect nou cu propriul set de proprietăți și operații permise. O coloană de celule dintr-un tabel și un paragraf dintr-un text sunt exemple de compoziții.

Un alt tip comun de relație între obiecte este un container.

Container este un obiect care conține alte obiecte (de exemplu, o imagine dintr-un document sau un document dintr-un folder poate fi considerată parte a conținutului containerului corespunzător). Proprietățile unui recipient afectează adesea comportamentul conținutului său. Aceasta influenta poate consta in extinderea sau suprimarea unor proprietati ale obiectelor continute in ea, sau in modificarea listei de operatii permise. În plus, containerul controlează accesul la conținutul său, precum și conversia tipului (formatului) a obiectului pe care îl include. Acest lucru, în special, poate afecta rezultatul transferului unui obiect dintr-un container în altul.

Aspectele avute în vedere mai sus necesită atribuirea fiecărui obiect unuia sau altui tip (clasă) de obiecte. Obiectele de același tip au proprietăți și comportament similare.

Tipurile de bază de obiecte de interfață constituie clasele fundamentale ale tuturor obiectelor furnizate de sistemul de operare. Există trei tipuri principale de obiecte: obiecte de date, obiecte container și obiecte dispozitiv.

Multe obiecte au caracteristici care aparțin mai multor clase (de exemplu, Inbox: proprietăți container și dispozitiv). Prin urmare, trebuie să înțelegeți bine clasele de obiecte de interfață și comportamentul acestora. Obiectele trebuie să răspundă așteptărilor utilizatorilor în ceea ce privește acțiunile pe care le efectuează, adică să determine ce vederi le pot afișa și modifica. Obiectele container trebuie să ofere vederi care se potrivesc cu alte containere, obiectele dispozitiv trebuie să ofere vederi care sunt specifice unui anumit dispozitiv și compatibile cu altele.

Obiectele de date oferă informații utilizatorilor. Ele pot reprezenta orice tip de informații, cum ar fi text, foi de calcul, imagini, muzică, vorbire înregistrată, video, animație sau orice combinație a acestora. Deoarece obiectele de date sunt în general orientate spre produs, ghidurile de proiectare nu definesc obiecte de date specifice. Aceasta este treaba designerilor de software.

2. 2. CONSTRUIREA MODELULUI „OBIECTUL – PROPRIETATE – RELATIE”.

Pentru a descrie ILM, sunt folosite atât limbaje analitice (descriptive), cât și instrumente grafice; în viitor, se utilizează o metodă grafică de afișare a modelului „obiect-proprietate-relație”. În domeniul subiectului în procesul examinării și analizei sale, se disting clase de obiecte. Clasa de obiecte numiți un set de obiecte care au același set de proprietăți. De exemplu, dacă considerăm o universitate ca disciplină, atunci în ea se pot distinge următoarele clase de obiecte: studenți, profesori, săli de sport etc. Obiectele pot fi reale, așa cum am menționat mai sus, sau pot fi abstracte, cum ar fi materii pe care le studiază elevii.

Când este reflectat în sistemul informațional, fiecare obiect este reprezentat de identificatorul său, care distinge un obiect al clasei de altul, iar fiecare clasă de obiecte este reprezentată de numele acestei clase. Deci, pentru obiectele din clasa „SUBIECTE STUDIATE”, identificatorul fiecărui obiect va fi „NUMELE SUBIECTULUI”. Identificatorul trebuie să fie unic.

Fiecare obiect are un set specific de proprietăți. Pentru obiectele din aceeași clasă, setul acestor proprietăți este același, iar valorile lor, desigur, pot diferi. De exemplu, pentru obiectele clasei „STUDENT”, un astfel de set de proprietăți care descriu obiectele clasei poate fi „AN NAȘTERE”, „GEN”, etc.

Când descrieți domeniul de subiect, este necesar să descrieți fiecare dintre clasele existente de obiecte și un set de proprietăți fixate pentru obiectele acestei clase.

Vom folosi următoarele denumiri pentru a afișa obiectele și proprietățile lor (Fig. & 2. 3).

Proprietate

Orez. 2.3 Desemnarea obiectelor și proprietățile acestora

Fiecărei clase de caracteristici din modelul infologic i se atribuie un nume unic.

La construirea unui model infologic, este de dorit să se ofere o interpretare verbală a fiecărei entități, mai ales dacă este posibilă o interpretare ambiguă a conceptului.

Orez. 2.4 Imaginea unei relații „obiect-proprietate”.

La descrierea domeniului subiectului, este necesar să se reflecte conexiunile dintre obiect și proprietățile care îl caracterizează. Acesta este pur și simplu descris ca o linie care leagă denumirea obiectului și proprietățile acestuia.

Relația dintre un obiect și proprietatea acestuia poate fi diferită. Un obiect poate avea o singură valoare pentru o proprietate. De exemplu, fiecare persoană poate avea o singură dată de naștere. Să numim astfel de proprietăți singur. Pentru alte proprietăți, este posibil să existe mai multe valori pentru un obiect în același timp. Să fie, de exemplu, când descriem „ANGAJATUL”, „LIMBA STRĂINĂ” pe care o deține este fixată drept proprietatea sa. Deoarece un angajat poate cunoaște mai multe limbi străine, o astfel de proprietate va fi numită plural. Când descriem conexiunea dintre un obiect și proprietățile sale, vom folosi o singură săgeată pentru proprietăți individuale și o săgeată dublă pentru proprietăți multiple.

În plus, unele proprietăți sunt permanente, valoarea lor nu se poate modifica în timp. Să numim astfel de proprietăți static, iar acele proprietăți, a căror valoare se poate modifica în timp, vor fi numite dinamic.

O altă caracteristică a relației dintre un obiect și proprietatea acestuia este semnul dacă această proprietate este prezentă în toate obiectele unei clase date sau absentă în unele obiecte. De exemplu, pentru unii angajați poate exista proprietatea „GRAFORMA ACADEMĂ” și este posibil ca alte obiecte din această clasă să nu aibă proprietatea specificată. Să numim astfel de proprietăți condiţional.

Când descriem conexiunea unei proprietăți condiționate cu un obiect, vom folosi o linie punctată, iar pentru a desemna proprietăți dinamice și statice, vom folosi literele D și S deasupra liniei corespunzătoare.

Uneori într-un model infologic este utilă introducerea conceptului „Proprietate compozită”. Exemple de astfel de proprietăți sunt „ADRESA”, constând din „ORAȘ”, „STRADA”, „CASA” și „APARTAMENT”, și „DATA NAȘTERII”, constând din „NUMĂR”, „LUNA” și „AN”. Folosim în ILM pentru a desemna o proprietate compozită un pătrat, din care provin liniile care o leagă cu denumirile elementelor sale constitutive (Fig. 2.4).

Modelul infologic nu afișează instanțe individuale de obiecte, ci clase de obiecte. Când desemnarea unui obiect este afișată în ILM, este clar că vorbim despre o clasă de obiecte care au proprietățile descrise. Prin urmare, în majoritatea cazurilor, este posibil să nu se introducă în mod explicit o desemnare pentru o clasă de obiecte într-un model infologic. O imagine explicită a unei clase de obiecte este necesară numai dacă software-ul pentru o anumită clasă de obiecte înregistrează nu numai caracteristici legate de obiectele individuale ale acestei clase, ci și unele caracteristici integrale legate de întreaga clasă în ansamblu. De exemplu, dacă pentru clasa de obiecte „ANGAJATI” se înregistrează nu numai vârsta fiecărui angajat, ci și vârsta medie a tuturor angajaților, atunci în modelul infologic este necesar să se reflecte nu numai obiectul „ANGAJAT”, ci și clasa de obiecte „EMPLOYEES”. Pentru a afișa o clasă de obiecte, puteți utiliza o denumire specifică sau aceeași care este folosită pentru obiecte (Fig. 2. 5).

Orez. 2.5 Imaginea unei clase de obiecte și caracteristicile integrale ale clasei.

Pe lângă conexiunea dintre un obiect și proprietățile acestuia, modelul infologic înregistrează conexiuni între obiecte de diferite clase. Există legături de tipul „unu la unu” (1: 1), „unu la mulți” (1: M), „mulți la mulți” (M: M). Aceste tipuri de relații sunt uneori denumite gradul de relație.

Pe lângă gradul de conexiune în modelul infologic, pentru a caracteriza legătura dintre diferite entități, este necesar să se indice așa-numitul „Clasa de apartenență”, care arată dacă nu poate exista nicio legătură între un obiect din această clasă cu vreun obiect din altă clasă. Clasa de entitate trebuie să fie obligatorie sau opțională.

Să explicăm ceea ce s-a spus cu exemple concrete. După cum am menționat mai sus, modelul infologic nu este construit pentru un obiect separat, ci afișează clasele de obiecte și relațiile dintre ele. Diagrama corespunzătoare care afișează acest lucru se numește diagramă de tip ER (acest nume se datorează faptului că în engleză cuvântul „entity” este scris „Entity”, iar relația este „Relationship”). Cu toate acestea, uneori, pe lângă diagramele de tip ER, sunt folosite diagramele de instanță ER.

Să presupunem că modelul infologic afișează o relație între două clase de obiecte: „ANGAJAT” și „LIMBA STRĂINĂ”.

Să presupunem că tematica este o fabrică în care unii dintre angajați cunosc o limbă străină, dar niciunul dintre ei nu vorbește fluent mai mult de o limbă. Desigur, există multe limbi pe care niciunul dintre angajați nu le vorbește și, de asemenea, unii dintre angajați vorbesc aceeași limbă străină (Fig. 2. 6).

c1. .ya1

c2. .ya2

c3. .я3

c4. .ya4

c5. .ya5

c6. .ya6

c7. .ya7

Orez. 2.6 Diagrama ER - instanțe

În acest caz, diagrama instanțelor ER va arăta ca cea prezentată în Fig. 2. 6, iar diagrama tipurilor ER este ca în fig. 2.7.

Orez. 2. 7. Diagrama tipurilor E - R

Să presupunem în continuare că domeniul de studiu este o instituție, iar obiectul „PERSONALITATE” reflectă solicitanții care intră în această instituție. Fiecare dintre solicitanți trebuie să vorbească neapărat o limbă străină, dar nimeni nu vorbește mai mult de o limbă (Fig. 2. 8). În acest caz, diagrama instanțelor ER va arăta ca cea prezentată în Fig. 2. 8, iar diagrama tipurilor ER este ca în fig. 2.9.

Limbajul personalității

l1 i1

l2 i2

l3 i3

l4 z4

l5 i5

l6 i6

l7 i7

Atât în ​​primul, cât și în cel de-al doilea caz luat în considerare, se observă relația M între entități: 1. Pe diagramă, aceasta este afișată din partea obiectului „PERSONALITATE” printr-o săgeată dublă, iar din partea laterală a „ "LIMBĂ STRĂINĂ" - printr-o singură săgeată pe linia care ilustrează relația dintre entitățile de date.

Diferența dintre situațiile avute în vedere este că în primul caz, clasa de apartenență este opțională pentru ambele entități, iar în al doilea, pentru entitatea „PERSONALITATE”, clasa de apartenență este obligatorie. Pe diagramă (Fig. 2. 9) aceasta este arătată printr-un punct din dreptunghi corespunzător obiectului „PERSONALITATE”.

Fie ca tematica să fie aceeași ca în cazul precedent, dar există situații în care unii solicitanți cunosc mai multe limbi străine. În acest caz, legătura dintre obiecte va fi de tip M: M.

Pentru un astfel de domeniu, diagrama ER-instanțe va arăta ca cea prezentată în Fig. 2. 10, iar diagrama tipurilor ER este ca în fig. 2.11.

Limbajul personalității

l1 i1

l2 i2

l3 i3

l4 z4

l5 i5

l6 i6

l7 i7

Să presupunem că domeniul de studiu este un institut lingvistic, în care fiecare și: angajații cunosc în mod necesar mai multe limbi străine, iar pentru fiecare dintre limbile cunoscute științei din acest institut există cel puțin un specialist care o vorbește.

În acest caz, relația dintre obiecte va fi M:M, iar clasa de proprietate a ambelor entități este obligatorie.

(Ar putea fi dat un exemplu, dar ideea este clară).

Mai sus, am luat în considerare obiectele fără să ne adâncim în complexitatea lor. De fapt, există mai multe tipuri de obiecte.

În primul rând, acestea sunt obiecte simple și complexe. Obiectul este numit simplu, dacă este văzută ca indivizibilă. Dificil un obiect este o unire a altor obiecte, simple sau complexe, afișate și în sistemul informațional. Conceptul de obiect „simplu” și „complex” este relativ. Într-o vedere, un obiect poate fi considerat simplu, iar în alta, același obiect poate fi considerat complex. De exemplu, obiectul „scaun” din subsistemul de contabilitate a activelor materiale va fi considerat un simplu obiect, dar pentru o întreprindere care produce scaune, acesta va fi un obiect compozit (inclusiv „picioare”, „spatar”, „scaun”, etc.).

Există mai multe tipuri de obiecte complexe: obiecte compuse, obiecte generalizate și obiecte agregate.

Obiect compus corespunde cartografierii relației întreg-parte. Exemple de obiecte compuse sunt NODE-DETALII, CLASĂ-STUDENTI etc.

Modelele infologice nu folosesc de obicei convenții speciale pentru a afișa obiecte complexe. Relația dintre compozit și obiectele sale constitutive este afișată în același mod ca cel descris mai sus. Mai mult decât atât, natura conexiunii poate fi, de asemenea, diferită: de exemplu, „DETALII” și „NODURI” sunt legate între ele printr-o relație de tip M: M și „GRUP” și „ELEVI” - prin relația 1 : M.

Obiect generalizat reflectă prezența relației „gen-specie” între obiectele domeniului subiect. De exemplu, obiectele STUDENT, ȘCOLAR, GRADUAT, STUDENT STUDENT formează un obiect generalizat STUDENTS. Obiectele care alcătuiesc un obiect generalizat se numesc categorii ale acestuia.

Atât un obiect „generic”, cât și obiecte „specifice” pot avea un anumit set de proprietăți. Mai mult, se observă așa-numita moștenire a proprietăților, adică un obiect „specific” are toate proprietățile pe care le posedă un obiect „generic”, plus proprietăți inerente doar obiectelor de acest tip.

Determinarea relațiilor gen - specifice înseamnă clasificarea obiectelor din domeniul subiectului în funcție de una sau alta caracteristică. Subclasele pot fi distinse într-un model infologic într-o formă explicită și implicită. În primul caz, în reprezentarea grafică este introdusă o denumire specială pentru subclasă. În fig. 2. 14 prezintă un fragment din modelul infologic, reflectând obiectul generalizat „PERSONALITATE” pentru o instituție de învățământ superior. Pentru el sunt mai multe categorii: PROFESOR, ELEV, ELEV. Un triunghi a fost folosit pentru a indica subclasa din circuit.

Desigur, clasificarea poate fi pe mai multe niveluri. Deci, în exemplul luat în considerare, obiectul generalizat „PERSONALITATE” poate fi împărțit în două subclase: ANGAJAT și STUDENT. SALARIATII, la randul lor, pot fi clasificati in PERSONAL DIDACTIC, ADMINISTRATIE etc.

Personalitate

Orez. 2.14 Imagine generică a obiectului

Clasele de obiecte selectate în domeniu pot fi fie suprapuse, fie nesuprapuse. Pentru a afișa aceste informații în modelul infologic, puteți folosi graficul de intersecție, ale cărui vârfuri corespund claselor (subclaselor) de obiecte, iar marginile conectează o pereche de vârfuri numai dacă clasele corespunzătoare de obiecte se intersectează. Puteți utiliza un grafic ponderat pentru a afișa gradul de intersecție. În acest caz, greutatea unui vârf va desemna cardinalitatea setului corespunzător de obiecte, iar greutatea unei muchii - cardinalitatea mulțimii care este intersecția mulțimilor conectate prin această muchie (Fig. 2.15).

Orez. 2.15 Graficul de intersecție

Graficul de intersecție conține informații suplimentare despre domeniul subiectului și nu aparține clasei de modele ER.

Obiecte agregate de obicei corespund unui proces în care sunt „implicate” alte obiecte. De exemplu, obiectul agregat „FURNIZARE” combină obiectele „FURNIZOR”, care furnizează produse, „CONSUMATOR”, care primește aceste produse, precum și „PRODUSE” furnizate. Obiectul original este „DATA LIVRARE”. Un obiect agregat poate, ca un obiect simplu, să aibă proprietăți care îl caracterizează. În exemplul luat în considerare, o astfel de proprietate poate fi dimensiunea livrării.

Obiectele agregate sunt de obicei numite substantive verbale (de exemplu, aprovizionare-aprovizionare, eliberare-eliberare, vânzare-vânzare etc.).

Orez. 2.16 Imagine obiect agregată

Pentru a afișa un obiect agregat într-un model infologic, vom folosi următoarele convenții:

obiectul agregat însuși va fi reprezentat printr-un romb, lângă care este indicată numele obiectului corespunzător. Acest diamant trebuie asociat cu legenda obiectelor care alcătuiesc acest obiect agregat. Proprietățile unui obiect agregat sunt afișate în același mod ca și pentru un obiect simplu. Pe orez. 2.16 arată obiectul agregat „ALIMENTARE PRODUSE”.

| Planificarea lecției și materialele pentru lecție | 8 clase | Planificarea lecțiilor pentru anul universitar | Modele tabulare

Lecția 12
Modele tabulare

Modele tabulare

Probleme în studiu:

Tabele de tip „obiect-proprietate”.
- Un tabel de tip „obiect-obiect”.
- Matrici binare.

Tabelele obiect-proprietăți

O altă formă comună de model de informare este masă dreptunghiulară format din rânduri și coloane. Utilizarea tabelelor este atât de comună încât, de obicei, nu este necesară nicio explicație suplimentară pentru a le înțelege.

Ca exemplu, luați în considerare tabelul 2.1.

La alcătuirea unui tabel, în acesta sunt incluse doar informațiile care interesează utilizatorul. De exemplu, pe lângă informațiile despre cărți care sunt incluse în tabelul 2.1, mai sunt și altele: editor, număr de pagini, cost. Cu toate acestea, pentru compilatorul tabelului 2.1, au existat suficiente informații despre autor, titlul și anul publicării cărții (coloanele „Autor”, „Titlu”, „Anul”) și informații care au permis găsirea unei cărți pe rafturile din biblioteci (coloana „Raft”). Se presupune că toate rafturile sunt numerotate și, în plus, fiecare carte are propriul număr de inventar (coloana „Număr”).

Tabelul 2.1 - este un model informativ al fondului de carte al unei biblioteci de acasă.

Tabelul poate reflecta un anumit proces care are loc în timp (Tabelul 2.2).

Citirile, care sunt enumerate în tabelul 2.2, au fost luate în termen de cinci zile, la aceeași oră a zilei. Privind tabelul, este ușor să compari diferite zile în ceea ce privește temperatura, umiditatea etc. Acest tabel poate fi considerat ca un model informativ al procesului de schimbare a stării vremii.

Tabelele 2.1 și 2.2 se referă la tipul de tabel cel mai frecvent utilizat. Ele sunt numite tabele „obiect-proprietate”..

Un rând al unui astfel de tabel conține informații despre un obiect (o carte din bibliotecă sau starea vremii la 12-00 într-o anumită zi). Coloane - caracteristici (proprietăți) individuale ale obiectelor.

Desigur, rândurile și coloanele din tabelele 2.1 și 2.2 pot fi schimbate prin rotirea lor cu 90 °. Uneori o fac. Apoi rândurile vor corespunde proprietăților, iar coloanele vor corespunde obiectelor. Dar cel mai adesea tabelele sunt construite astfel încât să existe mai multe rânduri decât coloane. De regulă, există mai multe obiecte decât proprietăți.