Cum se configurează smartphone-uri și PC-uri. Portal informativ
  • Acasă
  • Sfat
  • Descrierea obiectelor și conexiunile dintre ele. Navigare mai multe obiecte consistente

Descrierea obiectelor și conexiunile dintre ele. Navigare mai multe obiecte consistente

Legături între obiecte.

Numele parametrului Sens
Subiect articol: Legături între obiecte.
Rubrica (categoria tematica) Conexiune

În lumea reală, în special în sistemele complexe, există diverse relații între obiecte. La modelare, obiectele sunt reprezentate ca obiecte, iar relațiile dintre ele ca conexiuni. Fiecare tip comunicatii are propriul nume în model. În formă grafică, o relație este afișată ca o linie între obiectele înrudite, indicând identificatorul relației.

Există trei tipuri de conexiuni elementare: unu-la-unu (Fig. 4.1.), unu-la-mai multe (Fig. 4.2.) și mulți-la-mulți (Fig. 4.3.).

O relație unu-la-unu există atunci când o instanță a unui obiect este asociată cu o singură instanță a altuia. O relație unu-la-unu este indicată prin săgeți ←sau→.

Oportunitati

Orez. 4.1. Un exemplu de relație unu-la-unu.

O relație unu-la-mulți există atunci când o instanță a unui prim obiect este asociată cu mai mult de o instanță a unui al doilea obiect, dar fiecare instanță a celui de-al doilea obiect este asociată cu o singură instanță a primului obiect. Această conexiune este reprezentată de o săgeată dublă →→.

Cuprinde

Orez. 4 . 2. Un exemplu de relație unu-la-mai mulți.

O relație multi-la-mulți există atunci când fiecare instanță a primului obiect este asociată cu unul sau mai multe o cantitate mare instanțe ale celei de-a doua și fiecare instanță a celei de-a doua este asociată cu una sau mai multe instanțe ale primei. Acest tip de conexiune este reprezentat de o săgeată bidirecțională ↔.

Studiu

Orez. 4.3 . Un exemplu de relație multi-la-mulți.

Pe lângă multiplicitate, conexiunile pot fi împărțite în necondiționate și condiționate. Fiecare instanță a unui obiect participă la o relație necondiționată. Nu toate instanțele unui obiect iau parte la o conexiune condiționată. Conexiunea trebuie să fie condiționată de ambele părți.

Toate conexiunile din modelul de informații necesită o descriere, care, cel puțin, include:

‣‣‣ identificatorul de comunicare;

‣‣‣ tipul conexiunii (pluralitatea și condiționalitatea acesteia).

Conexiunile elementare sunt componente structuri de comunicare. O secvență necondiționată de conexiuni unu-la-unu este de obicei numită structură de tip coadă și este afișată grafic în Fig. 4.4.a. O generalizare a structurii tipului de coadă este structura ciclică prezentată în Fig. 4.4.b.

Foarte rol important joacă în copaci model informativ, care este unul dintre cele mai comune tipuri de structuri de clasificare.
Postat pe ref.rf
O relație de arbore este o relație necondiționată unu-la-mulți și este reprezentată grafic în Fig. 4.4. V . O caracteristică a acestei structuri este că fiecare obiect nu poate avea mai mult de un strămoș și un număr arbitrar de descendenți. Un obiect care nu are copii se numește obiect frunză. Un arbore ierarhic începe cu un singur obiect, numit obiect rădăcină. Este foarte important ca fiecare obiect să aibă propriul său nume sau identificator unic.
Postat pe ref.rf
Această structură de comunicare este numită și ierarhică. În fig. 4.4. V . dreptunghiul R este obiectul rădăcină. Obiectele B1,. . ., B8 sunt frunze. Modelul ierarhic este destul de convenabil pentru reprezentarea domeniilor de subiect, deoarece relațiile ierarhice sunt destul de comune între entitățile din lumea reală. Dar modelul ierarhic nu acceptă relații multi-la-mulți, în care multe obiecte de un tip sunt asociate cu multe obiecte de alt tip. Să presupunem că trebuie să construim un model al relației dintre un set de profesori și un set de materii. O structură arborescentă ierarhică nu este potrivită pentru modelarea unor astfel de relații.

Z
ÎN
A
A) . . .
Z
B
b)
C

R
V)
A1
A2 A@A@
A3
A4
B1
B4
B5
B6
B7
B8

Fig.4.4. Modele de informații precum „coadă” (a), „ciclu” (b), „arboresc” (c).

Model infologic (model informațional-logic)- un model de domeniu orientat spre om și independent de DBMS care definește agregatele obiecte informaţionale, atributele și relațiile lor dintre obiecte, dinamica schimbărilor în domeniul subiectului, precum și natura nevoilor de informații ale utilizatorilor. Modelul informațional al domeniului subiectului poate fi descris prin modelul „entitate-relație” (modelul lui Chen), care se bazează pe împărțirea lumii reale în entități distincte distincte care sunt în anumite conexiuni între ele și ambele categorii - esența și conexiunea sunt considerate concepte primare, nedefinite.

Scopul modelării informației

  • oferind modalităților cele mai naturale pentru ca oamenii să colecteze și să prezinte informațiile în care ar trebui să fie stocate baza de date în curs de creare date. Prin urmare, ei încearcă să construiască un model de date infologice prin analogie cu limbajul natural (cel din urmă nu poate fi utilizat în formă pură datorita complexitatii prelucrare computerizată textele și ambiguitatea oricărui limbaj natural). Principalele elemente constructive ale modelelor informaționale sunt entitățile, conexiunile dintre acestea și proprietățile (atributele) acestora.

Noțiuni de bază

  • Esență– orice obiect distins (un obiect pe care îl putem distinge de altul), informații despre care trebuie stocate într-o bază de date. Entitățile pot fi persoane, locuri, avioane, zboruri, gust, culoare etc. Este necesar să se facă distincția între concepte precum tipul de entitate și instanța entității. Conceptul de tip de entitate se referă la un set de indivizi omogene, obiecte, evenimente sau idei care acționează ca un întreg. O instanță de entitate se referă la un anumit lucru dintr-un set. De exemplu, tipul de entitate poate fi CITY, iar instanța poate fi Moscova, Kiev etc.
  • Atribut– o caracteristică numită a unei entități. Numele său trebuie să fie unic pentru un anumit tip de entitate, dar poate fi același pentru diferite tipuri de entitate (de exemplu, CULOARE poate fi definită pentru mai multe entități: CÂINE, MAȘINĂ, FUM etc.). Atributele sunt folosite pentru a defini ce informații trebuie colectate despre o entitate. Exemple de atribute pentru entitatea CAR sunt TYPE, MAKE, LICENCE PLATE, CULOARE etc. Și aici există o distincție între tip și instanță. Tipul de atribut COLOR are multe instanțe sau valori: roșu, albastru, banană, noapte albă etc., dar fiecărei instanțe de entitate i se atribuie o singură valoare de atribut.

Nu există nicio diferență absolută între tipurile de entități și atribute. Un atribut este astfel numai în raport cu tipul de entitate. Într-un alt context, un atribut poate acționa ca o entitate independentă. De exemplu, pentru o fabrică de mașini, culoarea este doar un atribut al produsului de producție, dar pentru o fabrică de vopsele și lacuri, culoarea este un tip de entitate.

  • Cheieset minim atribute ale căror valori pot fi folosite pentru a găsi în mod unic instanța necesară a unei entități. Minimitatea înseamnă că excluderea oricărui atribut din set nu permite identificarea entității de către cele rămase. Pentru entitatea Schedule, cheia este atributul Flight_number sau setul de: Departure_point, Departure_time și Destination_point (cu condiția ca un avion să zboare dintr-un punct în altul la un moment dat).
  • Conexiune– asocierea a două sau mai multe entități. Dacă scopul bazei de date era doar acela de a stoca date individuale, fără legătură, atunci structura acesteia ar putea fi foarte simplă. Cu toate acestea, una dintre principalele cerințe pentru organizarea unei baze de date este asigurarea capacității de a găsi unele entități prin valorile altora, pentru care este necesar să se stabilească anumite conexiuni între ele. Și deoarece bazele de date reale conțin adesea sute sau chiar mii de entități, teoretic se pot stabili mai mult de un milion de conexiuni între ele. Prezența unei asemenea multitudini de conexiuni determină complexitatea modelelor informaționale.

Cerințe pentru modelul informațional

  • Cartografierea adecvată a domeniului subiectului
  • Evitarea interpretării ambigue a modelului
  • Definirea clară a domeniului subiectului modelat (finitivitatea modelului)
  • Extensibilitate ușoară, asigurând introducerea de date noi fără modificarea celor definite anterior, același lucru este valabil și pentru ștergerea datelor
  • Posibilitatea de compunere și descompunere a modelului datorită dimensiunii mari a modelelor informaționale reale
  • Usor de inteles de catre diferite categorii de utilizatori; Este de dorit ca modelul de informații să fie construit (sau cel puțin să participe la crearea lui) de către un specialist care lucrează într-un anumit domeniu și nu doar de un proiectant de sisteme informatice de procesare a datelor
  • Aplicabilitatea limbajului de specificație a modelului atât în ​​manual, cât și proiectare asistată de calculator sisteme de informare

Componentele unui model informatic

  • Descrierea obiectelor și a relațiilor dintre ele, numită modelul ER (însemnând modelul „Entitate-Relație”)
  • Descrierea nevoilor de informații ale utilizatorului
  • Relații de atribute algoritmice
  • Relații lingvistice determinate de particularitățile de reprezentare a disciplinei în mediul lingvistic
  • Constrângeri de integritate

Construirea modelului „Obiect – Proprietate – Relație”.

Clase de obiecte

În domeniul subiectului, în procesul examinării și analizei acesteia, se disting clase de obiecte. O clasă de obiecte este o colecție de obiecte care au același set de proprietăți. De exemplu, dacă luăm în considerare o universitate ca disciplină, atunci se pot distinge următoarele clase de obiecte: studenți, profesori, public etc. Obiectele pot fi reale, așa cum am menționat mai sus, sau pot fi abstracte, cum ar fi obiectele, pe care le studiază elevii.

Când este reflectat într-un sistem informațional, fiecare obiect este reprezentat de identificatorul său, care distinge un obiect al unei clase 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”. ID-ul 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, dar valorile lor, desigur, pot diferi. De exemplu, pentru obiectele clasei „STUDENT”, un astfel de set de proprietăți care descriu obiectele clasei poate fi „ANUL NAȘTERII”, „GENUL”, etc.

Când descrieți o zonă de subiect, este necesar să descrieți fiecare dintre clasele existente de obiecte și setul de proprietăți fixate pentru obiecte. din această clasă.

Vom folosi următoarea notație pentru a afișa obiectele și proprietățile lor.

Fiecare clasă de obiecte din informații model logic i se atribuie un nume unic. Numele unei clase de obiecte este o frază gramaticală a unui substantiv (un substantiv care poate avea adjective și prepoziții). Dacă numele constă din mai multe cuvinte, atunci este de dorit ca substantivul să fie primul. Substantivul trebuie folosit la singular și nu în plural. Prin urmare, pentru clasa de obiecte „DISCIPLINE STUDIATE” discutată mai sus, este mai bine să dați numele „DISCIPLINĂ STUDIATĂ”. Dacă într-o zonă de subiect sunt folosite în mod tradițional nume diferite pentru a desemna orice clasă de obiecte (adică există sinonimie), atunci toate acestea trebuie înregistrate atunci când descriem sistemul, atunci unul dintre ele este ales ca principal și numai acesta ar trebui să fie utilizat în viitor la ILM. În plus față de numele clasei de obiecte, ILM-ul poate folosi denumirea de cod scurt.

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

Relațiile dintre un obiect și proprietățile sale

Când descrieți un domeniu, este necesar să reflectați conexiunile dintre obiect și proprietățile care îl caracterizează. Acesta este descris pur și simplu ca o linie care leagă denumirea unui obiect ș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 aceste proprietăți singur. Pentru alte proprietăți, este posibil ca un obiect să aibă mai multe valori în același timp. Să fie, de exemplu, când descrieți un „ANGAJAT”, „LIMBA străină” pe care o vorbește este înregistrată ca proprietatea sa. Deoarece un angajat poate cunoaște mai multe limbi straine, atunci vom numi o astfel de proprietate multiplu. 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 aceste proprietăți static, iar acele proprietăți a căror valoare se poate modifica în timp vor fi apelate dinamic.

O altă caracteristică a conexiunii dintre un obiect și proprietatea acestuia este un semn dacă această proprietate este prezentă în toate obiectele unei clase date sau absentă în unele obiecte. De exemplu, pentru angajații individuali poate exista proprietatea „GRAD DE CHARGE”, dar este posibil ca alte obiecte din această clasă să nu aibă proprietatea specificată. Să numim astfel de proprietăți condiționate.

Când descriem legătura dintre o proprietate condiționată și un obiect, vom folosi linie punctata, iar pentru a desemna proprietăți dinamice și statice vom folosi literele D și S deasupra liniei corespunzătoare.

Uneori este utilă introducerea conceptului de „proprietate compozită” într-un model infologic. Exemple de astfel de proprietăți sunt „ADRESA”, constând din „ORAȘ”, „STRADA”, „CASA” și „APARTAMENT”, și „DATA NAȘTERI”, constând din „ZIUA”, „LUNA” și „ANUL”. În ILM, pentru a desemna o proprietate compozită, folosim un pătrat, din care emană linii care îl conectează cu denumirea elementelor sale constitutive.

Relațiile dintre obiecte

Pe lângă conexiunea dintre un obiect și proprietățile sale, modelul infologic surprinde conexiuni între obiecte de diferite clase. Există conexiuni de următoarele tipuri:

  • „unu la unu” (1:1): în fiecare moment de timp, fiecărui reprezentant (instanță) al entității A îi corespunde 1 sau 0 reprezentanți ai entității B:
Un student nu poate „câștiga” o bursă, să nu primească o bursă obișnuită sau să primească una dintre bursele îmbunătățite.
  • „unu-la-mulți” (1:M): un reprezentant al entității A corespunde cu 0, 1 sau mai mulți reprezentanți ai entității B.
Apartamentul poate fi gol, unul sau mai mulți rezidenți pot locui în el.
  • „mulți la unul” (M:1)

Uneori, aceste tipuri de conexiuni sunt numite grad de conexiune. 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-numita „clasă de membru”, care arată dacă nu poate exista nicio legătură între un obiect al unei clase date și orice obiect al altei clase. Clasa de membru al unei entități trebuie să fie obligatorie sau opțională.

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

Să presupunem că modelul infologic afișează legătura dintre două clase de obiecte: „PERSONALITATE” și „LIMBA străină”. -

Să presupunem că domeniul este o fabrică în care unii angajați cunosc o limbă străină, dar niciunul dintre ei nu vorbește 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ă.

Să presupunem în continuare că domeniul de studiu este un institut, iar obiectul PERSOANĂ reprezintă solicitanții care intră în acest institut. Fiecare dintre solicitanți trebuie să cunoască o limbă străină, dar nimeni nu vorbește mai mult de o limbă.

Atât în ​​primul cât și în cel de-al doilea caz luat în considerare, între entități se observă relația M:1. În diagramă, aceasta este afișată din partea obiectului „PERSONALITATE” printr-o săgeată dublă, iar din partea obiectului „LIMBĂ Străină” printr-o singură săgeată pe o linie care ilustrează legătura dintre aceste entități.

Diferența dintre situațiile luate în considerare este că în primul caz, clasa de apartenență este opțională pentru ambele entități, iar în al doilea caz, pentru entitatea „PERSONALITATE”, clasa de apartenență este obligatorie. În diagramă, aceasta este reprezentată printr-un punct în dreptunghiul 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.

Să presupunem că domeniul de studiu este un anumit institut lingvistic, în care fiecare dintre angajați cunoaște î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 entități va fi M:M, iar clasa de membru a ambelor entități este obligatorie.

Obiecte simple și complexe

Se spune că un obiect este simplu dacă este tratat ca indivizibil. Un obiect complex este o combinație de alte obiecte, simple sau complexe, afișate de asemenea în sistemul informațional. Conceptul de obiect „simplu” și „complex” este relativ. Într-o considerație, 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 ca un obiect simplu, dar pentru o întreprindere care produce scaune, acesta va fi un obiect compozit (inclusiv „picioare”, „spatar”, „scaun”, etc.).

Există mai multe soiuri obiecte complexe: obiecte compuse, obiecte generice și obiecte agregate.

Obiect compozit corespunde maparii relatiei " întreg-parte" Exemple de obiecte compozite sunt NODURI - PĂRȚI, CLASĂ - STUDENTI etc.

Pentru a afișa obiecte compuse într-un model de informații, de obicei nu se folosesc simboluri speciale. Relația dintre un 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 conectate printr-o relație de tip M: M, iar „GROUP” și „STUDENTI” sunt conectate printr-o relație de 1: M .

Un obiect generalizat reflectă prezența unei relații „gen-specie” între obiectele din domeniul subiectului. De exemplu, obiectele STUDENT, ȘCOLAR, LICENȚAT, STUDENT TEHNIC formează obiectul generalizat STUDENTI. Obiectele care alcătuiesc un obiect generalizat se numesc categorii ale acestuia.

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

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

Compararea metodelor de construire a modelelor ER

Modelele ER sunt utilizate pe scară largă în practica de proiectare a bazelor de date. Mai mult, ele sunt utilizate atât în ​​proiectarea manuală, cât și în proiectarea asistată de calculator. Tehnici reprezentare grafică Modelele ER diferă ușor în sisteme diferite automatizarea proiectării și în diverse surse literare.

În continuare, ne vom uita la caracteristicile reprezentării modelelor ER în cele trei cele mai multe sisteme cunoscute automatizări de proiectare (sisteme CASE): Prokit*WORKBENCH, Design/IDEF și CASE ORACLE, precum și în unele surse literare.

Pot fi identificate mai multe categorii de diferențe în descrierea modelelor ER.

1. Diferențe minore asociate cu utilizarea diferitelor simboluri pentru a afișa aceleași entități. Astfel, dreptunghiuri, blocuri cu colturi rotunjite, ovale etc.

Următorul set de diferențe este legat de modul de a descrie conexiunile dintre obiecte și de a specifica numele conexiunilor. Astfel, în unele tehnici, pentru a descrie o conexiune în conectorul unei linii reprezentând această conexiune, se propune să se înfățișeze un romb și să se scrie numele conexiunii în interiorul sau lângă el (modelul lui Chen). Deoarece conexiunile sunt bidirecționale, numele conexiunii se va schimba în funcție de partea din care este vizualizată. Prin urmare, se propune adesea să se indice ambele nume în ILM (de exemplu, în sisteme CASE ORACLE, Prokit). Mai mult, pentru a clarifica la ce direcție de comunicare se referă ce nume, se adoptă anumite acorduri privind modul de plasare a acestor nume pe diagrame. De exemplu, deasupra liniei nume de locuri legate de partea stângă a conexiunii, iar sub linie - la dreapta. Prezența unui astfel de un numar mare desemnările și semnăturile aglomera modelul. În plus, denumirea în sine prezintă adesea o anumită dificultate, ceea ce crește complexitatea modelării informațiilor. Prin urmare, în cazurile în care acest lucru nu duce la ambiguități și ambiguități, dacă sistemul permite acest lucru, se poate recomanda să nu se folosească denumiri și nume speciale pentru relații.

Diferite simboluri sunt, de asemenea, folosite pentru a descrie tipul de conexiune (1:1, 1:M, M:M). Unele sisteme de automatizare a designului, cum ar fi Prokit, oferă utilizatorului posibilitatea de a alege dintr-o varietate de notații posibile pe cele care îi plac sau cu care este mai familiarizat. În acest sistem, următoarele convenții pot fi folosite pentru a indica tipul de conexiuni între obiecte.

Pentru a afișa apariția obligatorie a obiectelor într-o relație („membership/ membership class”), se folosesc și simboluri diferite. Astfel, în CASE ORACLE clasa de membru este trecută după cum urmează; pe acea parte a relației cu care elementul nu poate fi neapărat asociat, se folosește o linie punctată, iar în cazul în care apartenența este obligatorie, - linie solida. Având în vedere clasa de membru, sunt posibile tipurile de relații prezentate în figură.

Notația folosită în CASE ORACLE este mai convenabilă, deoarece dacă este implicat un obiect cantitati mari conexiuni, apoi dreptunghiuri suplimentare cu puncte devin incomod de plasat în figură.

În Desing IDEF, natura apartenenței la o relație este descrisă așa cum se arată în figură.

2. Diferențe, legate și de modul de a descrie anumite situații, dar mai semnificative, ducând la diferențe în modelele în sine. De exemplu, în sistemul 3RACLE, un obiect generalizat este descris prin blocuri „cuibări” care denotă obiecte „specii” în interiorul unui bloc care prezintă un obiect „generic”. Figura prezintă o imagine a obiectului PERSONA discutat mai sus în convenția folosită în CASE ORACLE.

După cum rezultă din compararea figurilor, imaginea obiectelor generalizate în metodele comparate diferă nu numai prin forma de prezentare. Deci, dacă un obiect este clasificat în funcție de diferite criterii, atunci când se folosește prima dintre metodele luate în considerare de reprezentare a obiectelor generalizate, este clar vizibil după ce criteriu se realizează clasificarea. A doua metodă de imagine nu oferă acest lucru. Cu alte cuvinte, metoda de reprezentare a obiectelor generalizate propusă la începutul capitolului este semantic mai semnificativă și mai informativă.

Figura prezintă același obiect PERSON generalizat folosind sintaxa sistemului IDEF1X. În semantica sa, această metodă de reprezentare este mai apropiată de cea pe care am propus-o metoda de baza Imagini ILM. Diferența este că IDEF1X folosește aceeași notație pentru entitățile de categorie și entitățile „generale” -

3. Pe lângă diferențele în descrierea anumitor entități, în teoria modelării informaționale există o discrepanță în terminologia utilizată. De exemplu, în CASE ORACLE, un obiect generic este numit supertip (syper-tip), iar un obiect specie este numit subtip. Există multe astfel de diferențe de terminologie care pot fi citate, dar acesta nu este scopul nostru acum.

4. Următorul cerc de diferențe este legat de imaginea spațială a anumitor componente ale ILM. De exemplu, proprietățile obiectelor nu sunt uneori afișate pe aceeași diagramă cu obiectele și relațiile dintre ele, iar descrierile lor sunt făcute separat. Adesea „scrierea proprietăților este prezentată sub formă tabelară sau altă formă analitică, mai degrabă decât sub formă grafică.

ILM, chiar și pentru un domeniu mic și simplu, include o descriere a unui număr semnificativ de componente și conexiuni între ele. Acest lucru ridică problema vizibilității. schema generala. Această problemă este rezolvată diferit în construcția manuală și automată a unui model de informații. În sistemele automate este cel mai adesea construit o singură imagine Se folosește modelul ER și tehnica de scalare, atunci când, prin scăderea sau creșterea scării imaginii, puteți vedea pe ecran atât întreaga diagramă, cât și fragmentul ei individual.

De asemenea, sunt folosite diverse tehnici pentru a reduce numărul de intersecții ale liniilor din diagramă. Astfel, în sistemul Prokit, în aceste scopuri, este posibilă duplicarea imaginii unui obiect și plasarea acestui duplicat lângă obiectul cu care trebuie asociat. Pentru a arăta că acesta nu este un obiect nou, se folosește un fel de simbol, de exemplu, colțul blocurilor corespunzătoare este tăiat.

Atunci când proiectați manual, de obicei nu este posibil să reprezentați întregul model ER sub forma unei singure diagrame. În acest caz, vă putem recomanda următoarea tehnică: descrieți și descrieți fiecare obiect în mod independent, atribuiți fiecărui obiect cod scurt. Folosind aceste coduri, pentru fiecare obiect indicați relațiile sale cu alte obiecte.

5. Unele capabilități disponibile în unele sisteme sau metode nu sunt disponibile în altele. În aceste cazuri este posibil diverse opțiuni: a) pentru înfățișarea situației se folosesc posibilitățile oferite de model, dar aceasta necesită utilizarea unor tehnici, adesea oarecum artificiale, pentru a le reprezenta; b) situația pur și simplu nu este reflectată în model.

De exemplu, în multe sisteme de modelare a informațiilor se presupune că un obiect poate avea doar proprietăți individuale. În acest caz, fiecare proprietate multiplă ar trebui să fie reprezentată ca un obiect independent și relația dintre acest obiect nou introdus și obiectul original ar trebui să fie reprezentată.

În IDEF, proprietățile obiectului pot fi doar unice și întotdeauna definite (nu condiționate). Dacă proprietatea poate să nu fie prezentă în niciun obiect, atunci este necesar să selectați entități separate, de exemplu, un ANGAJAT DE PERSONAL cu atributul SALARIU și un LUCRĂTOR ORAR care nu are un astfel de atribut. Acest lucru va duce la necesitatea selectării unui număr mare de obiecte și conexiuni în ILM și la o scădere a vizibilității modelului. De exemplu, cazurile individuale ale obiectului PERSONALITATE pot avea sau nu un titlu academic, o diplomă academică, un an de absolvire a unei universități și multe alte caracteristici. Pentru fiecare dintre aceste caracteristici va fi necesar să se distingă subclase.

Unele metode nu introduc obiectul agregat ca categorie independentă. În acest caz, obiectul agregat este descris ca simplu, iar utilizatorul trebuie să-și determine mai întâi identificatorul și proprietățile. Dacă modelul permite reprezentarea numai a relațiilor binare, atunci proiectantul trebuie să convertească relația n-are într-un set de relații binare.

Pe lângă aceste dificultăți la determinarea identificatorului unei entități agregate, pot apărea și probleme la trecerea de la un ILM la un model datalogic.

Opțiunea când situația nu poate fi reflectată în ILM poate fi ilustrată prin următoarele: dacă tehnica de construcție a modelului nu implică fixarea clasei de membru în relație, atunci această informație se va pierde pur și simplu.

În unele sisteme CASE, există o situație în care o anumită construcție este permisă în sistem ca una intermediară. De exemplu, în IDEF și CASE ORACLE relația M:M este permisă ca relație nespecifică. Prezența acestuia este permisă în primele etape de dezvoltare a proiectului, iar ulterior trebuie înlocuită cu o relație specifică prin introducerea unei terțe entități. Acesta este un dezavantaj al sistemului, deoarece, în primul rând, nu toate SGBD-uri necesită o astfel de transformare (unele sisteme acceptă în mod explicit relația M:M) și, în al doilea rând, dacă este necesară o astfel de transformare, sistemul de automatizare a proiectării ar putea să o efectueze automat. în etapa de proiectare datalogică. Chiar dacă se realizează proiectarea „manuală”, transformarea specificată trebuie să fie efectuată de proiectant în etapa de proiectare datalogică, și nu la descrierea domeniului subiectului. În plus, în timpul transformării luate în considerare la etapa de proiectare a informațiilor, este introdus IDEF categorie noua entități - entități de intersecție sau entități asociative. Introducerea de noi entități presupune introducerea în ILM și conexiuni suplimentare. Toate acestea luate împreună complică sarcina deja dificilă de proiectare a informațiilor.

Pot exista entități în domeniul subiectului ai căror identificatori depind de identificatorul unui alt obiect. De exemplu, dacă secțiunile unei întreprinderi sunt numerotate în cadrul unui atelier, atunci identificatorul secțiunii va fi compus, inclusiv codul atelierului și codul secțiunii. În modelul infologic, ne putem limita la a indica acest identificator compus. Unele metode de construire a modelelor ER (de exemplu, metodologia IDEFIX, Prokit) prevăd introducerea unor tipuri speciale de entități și tipuri speciale de relații pentru a afișa astfel de situații. Astfel, în IDEF, o entitate, pentru a identifica care trebuie să ia în considerare relația sa cu alte entități; se numește entitate dependentă de identificator și folosește o casetă rotunjită pentru a o reprezenta. Pentru a descrie o entitate independentă de identitate, se folosește un dreptunghi. Pentru a conecta obiecte, dintre care unul este necesar pentru a-l identifica complet pe celălalt, este introdus conceptul de relație de identificare. Are și propriul simbol. IDEF folosește o linie continuă pentru o relație de identificare și o linie punctată pentru o relație de neidentificare.

6. După cum s-a menționat mai sus, atunci când luăm în considerare principiile modelării infologice, conceptele de „obiect”, „proprietate”, „relație” sunt relative. Astfel, în modelul infologic de bază pe care îl propunem, se disting diferite tipuri de obiecte: simple, compuse, agregate, generalizate. Unele sisteme, cum ar fi IDEF, nu clasifică obiectele în acest fel și în schimb folosesc varietăți de relații.

Ambele abordări au dreptul de a exista. Nu există diferențe fundamentale care să aducă consecințe semnificative în abordările comparate.

2. 2. CONSTRUIREA MODELULUI „OBIECTUL - PROPRIETATE - RELAȚIE”

Pentru a descrie ILM, sunt utilizate atât limbaje analitice (descriptive), cât și instrumente grafice. metoda grafica cartografierea modelului „obiect-proprietate-relație”. În domeniul subiectului, în procesul examinării și analizei sale, sunt identificate clase de obiecte. Clasa de obiecte numită o colecție de obiecte care au același set de proprietăți. De exemplu, dacă luăm în considerare o universitate ca disciplină, atunci se pot distinge următoarele clase de obiecte: studenți, profesori, public etc. Obiectele pot fi reale, așa cum am menționat mai sus, sau pot fi abstracte, cum ar fi obiectele, pe care le studiază elevii.

Când este reflectat într-un sistem informațional, fiecare obiect este reprezentat de identificatorul său, care distinge un obiect al unei clase de altul, iar fiecare clasă de obiecte este reprezentată de numele acestei clase. Astfel, pentru obiectele din clasa „SUBIECTE STUDIATE”, identificatorul fiecărui obiect va fi „NUMELE SUBIECTULUI”. ID-ul 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, dar valorile lor, desigur, pot diferi. De exemplu, pentru obiectele clasei „STUDENT”, un astfel de set de proprietăți care descriu obiectele clasei ar putea fi „ANUL NAȘTERII”, „GENUL”, etc.

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

Vom folosi următoarea notație 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 obiecte dintr-un model de informații i se atribuie un nume unic.

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



Orez. 2.4 Imagine a relației obiect-proprietate

Când descrieți un domeniu, este necesar să reflectați conexiunile dintre obiect și proprietățile care îl caracterizează. Acesta este descris pur și simplu ca o linie care leagă denumirea unui obiect ș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 aceste proprietăți singur. Pentru alte proprietăți, este posibil ca un obiect să aibă mai multe valori în același timp. Să, de exemplu, atunci când descrii un „ANGAJAT”, fixează drept proprietate a acestuia „LIMBA străină” pe care o vorbește. Deoarece un angajat poate cunoaște mai multe limbi străine, vom numi această proprietate 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 aceste 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 dacă această proprietate este prezentă în toate obiectele unei clase date sau absentă în unele obiecte. De exemplu, pentru angajații individuali poate exista proprietatea „GRAFORMA ACADEMĂ”, dar este posibil ca alte obiecte din această clasă să nu aibă proprietatea specificată. Să numim aceste proprietăți condiţional.

Când descriem legătura dintre o proprietate condiționată și un obiect, vom folosi o linie punctată, iar pentru a indica proprietățile dinamice și statice vom folosi literele D și S deasupra liniei corespunzătoare.

Uneori într-un model de informare 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ȘTERI”, constând din „ZIUA”, „LUNA” și „ANUL”. În ILM, pentru a desemna o proprietate compozită, folosim un pătrat, din care emană linii, legându-l cu denumirile elementelor sale constitutive (Fig. 2. 4).

Modelul infologic afișează nu instanțe individuale de obiecte, ci clase de obiecte. Când desemnarea unui obiect este descrisă î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 în modelul de informații. O reprezentare explicită a unei clase de obiecte este necesară numai dacă software-ul pentru o anumită clasă de obiecte înregistrează nu numai caracteristicile 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 ÎNTREPRINDERII” nu se înregistrează doar vârsta fiecărui angajat, ci și vârsta medie a tuturor angajaților, atunci modelul infologic trebuie să reflecte nu numai obiectul „ANGAJAT”, ci și „ANGAJATII”. ” clasa de obiecte. Pentru a afișa o clasă de obiecte, puteți utiliza o desemnare 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 sale, modelul infologic surprinde conexiuni între obiecte de diferite clase. Există conexiuni de tipul „unu la unu” (1: 1), „unu la mulți” (1: M), „mulți la mulți” (M: M). Uneori, aceste tipuri de conexiuni sunt numite grad de conexiune.

Pe lângă gradul de conectare în modelul informațional, pentru a caracteriza legătura dintre diferite entități, este necesar să se indice așa-numitul „clasa de membru”, care arată dacă un obiect dintr-o anumită clasă nu poate fi legat de vreun obiect al altei clase. Clasa de membru al unei entități 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 singur obiect, ci afișează clase de obiecte și conexiuni între 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 informațional afișează relația dintre două clase de obiecte: „ANGAJAT” și „LIMBĂ străină”.

Să presupunem că domeniul este o fabrică în care unii angajați cunosc o limbă străină, dar niciunul dintre ei nu vorbește 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).

s1. .ya1

s2. .ya2

s3. .ya3

s4. .ya4

s5. .ya5

s6. .ya6

s7. .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 de tip ER este ca în Fig. 2. 7.

Orez. 2. 7. Diagrama tipurilor E - R

Să presupunem în continuare că domeniul de studiu este un institut, iar obiectul „PERSOANĂ” reprezintă solicitanții care intră în acest institut. Fiecare dintre solicitanți trebuie să cunoască 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 de tip ER este ca în Fig. 2.9.

Limbajul personalității

l1 i1

l2 i2

l3 i3

l4 i4

l5 i5

l6 i6

l7 i7


Atât în ​​primul cât și în cel de-al doilea caz luat în considerare, există o relație M între entități: 1. În diagramă, aceasta este arătată din partea obiectului „PERSONALITATE” printr-o săgeată dublă și din partea „LIMBĂ Străină”. ” obiect – printr-o singură săgeată pe linia care ilustrează relația dintre entitățile de date.

Diferența dintre situațiile luate în considerare este că în primul caz, clasa de apartenență este opțională pentru ambele entități, iar în al doilea caz, pentru entitatea „PERSONALITATE”, clasa de apartenență este obligatorie. În diagramă (Fig. 2.9) aceasta este afișată printr-un punct în 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 instanțelor ER va arăta ca cea prezentată în Fig. 2.10, iar diagrama de tip ER este ca în Fig. 2.11.

Limbajul personalității

l1 i1

l2 i2

l3 i3

l4 i4

l5 i5

l6 i6

l7 i7


Să presupunem că domeniul de studiu este un anumit institut lingvistic, în care fiecare angajat cunoaște î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 entități va fi M:M și clasa de membru a ambelor entități este obligatorie.

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

Mai sus, ne-am uitat la obiecte 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 considerat ca fiind indivizibil. Dificil un obiect este o unire a altor obiecte, simple sau complexe, afisate si in sistemul informatic. Conceptul de obiect „simplu” și „complex” este relativ. Într-o considerație, 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 compozit corespunde cartografierii relației „întreg-parte”. Exemple de obiecte compozite sunt NODURI-PARTE, CLASĂ-STUDENTI etc.

Pentru a afișa obiecte compuse într-un model de informații, de obicei nu se folosesc simboluri speciale. Relația dintre un 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, „PARTE” și „NODURI” sunt conectate printr-o relație de tip M: M, iar „GROUP” și „STUDENTI” sunt conectate printr-o relație de 1: M .

Obiect generic reflectă prezența unei relații „de tip gen” între obiectele din domeniul subiectului. De exemplu, obiectele STUDENT, ȘCOLAR, LICENȚAT, STUDENT TEHNIC formează obiectul generalizat STUDENTI. Obiectele care alcătuiesc un obiect generalizat se numesc categorii ale acestuia.

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

Determinarea relațiilor gen-specie înseamnă clasificarea obiectelor unui domeniu în funcție de anumite caracteristici. Subclasele pot fi distinse în modelul informațional în formă explicită și implicită. În primul caz, când reprezentare grafică se introduce o denumire specială pentru subclasă. În fig. 2. 14 prezintă un fragment din modelul infologic, reflectând obiectul generalizat „PERSONALITATE” pentru instituție educațională. Pentru el sunt mai multe categorii: PROFESOR, STUDENT, ABOLVENIT. Un triunghi a fost folosit pentru a indica o subclasă în diagramă.

Desigur, clasificarea poate fi pe mai multe niveluri. Astfel, î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 FACULTATE, PERSONAL DIDACTIC, ADMINISTRATIE etc.

Personalitate



Orez. 2.14 Imaginea obiectului generalizat


Clasele de obiecte identificate în domeniul subiectului pot fi fie intersectante, fie neintersectante. Pentru a afișa aceste informații într-un model infologic, puteți utiliza un grafic de intersecție, ale cărui vârfuri corespund unor clase (subclase) 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 mulțimii corespunzătoare de obiecte, iar greutatea unei muchii va desemna 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 alte obiecte sunt „implicate”. De exemplu, obiectul agregat „LIVRARE” combină obiectele „FURNIZOR”, care furnizează produse, „CONSUMATOR”, care primește aceste produse, precum și „PRODUSE” furnizate în sine. Un obiect unic este „DATA LIVRARE”. Un obiect agregat, ca un obiect simplu, poate avea proprietăți care îl caracterizează. În exemplul luat în considerare, o astfel de proprietate ar putea 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 Imaginea obiectului agregat

Pentru a afișa un obiect agregat în modelul de informații, vom folosi următoarele convenții:

Vom reprezenta obiectul agregat în sine ca un diamant, lângă care este indicat numele obiectului corespunzător. Acest romb trebuie conectat la simboluri acele obiecte care formează acest obiect agregat. Proprietățile unui obiect agregat sunt afișate în același mod ca și pentru obiect simplu. Pe orez. Figura 2.16 prezintă obiectul agregat „LIVRARE PRODUSE”.

1. Concepte și termeni de bază pentru subiect
„MODELUL DE INFORMAȚII ESTE BAZĂ PENTRU CONSTRUIRE
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, crește și volumul de date interconectate necesare pentru rezolvarea problemelor comerciale și administrative.

@ Modelul de colectare, stocare, prelucrare și utilizare a datelor interconectate pentru a gestiona cel mai optim fluxurile de informații și a rezolva problemele dintr-o anumită arie se numește sistem informațional. . Un astfel de sistem este conceput în primul rând pentru a ușura munca omului, dar pentru a face acest lucru trebuie să corespundă cât mai bine unui model foarte complex al lumii reale.

@ Miez Sistem informatic sunt datele stocate în el . La orice întreprindere, datele din diferite departamente, de regulă, se intersectează, adică sunt utilizate în mai multe departamente sau sunt în general partajate. De exemplu, scopurile de management necesită adesea informații în întreaga întreprindere. Comandarea componentelor este imposibilă fără informații despre stocuri. Datele stocate în sistemul informațional trebuie să fie ușor accesibile în forma în care sunt necesare pentru un anume activitati de productieîntreprinderilor. În acest caz, metoda de stocare a datelor nu contează în mod semnificativ. Astăzi la întreprindere putem găsi un sistem de prelucrare a datelor tip tradițional, în care un angajat plasează manual datele într-un folder, iar alături este un sistem modern care folosește cele mai rapide computere, cele mai sofisticate echipamente și software. În ciuda diferențelor lor izbitoare, ambele sisteme trebuie să ofere informaţii de încredere la un anumit moment, la o anumită persoană, î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 de subiect parte numită sistem real, care este de interes pentru acest studiu.

La proiectarea sistemelor informatice automatizate, domeniul este reprezentat de modele de date de mai multe niveluri. Numărul de straturi utilizate depinde de complexitatea sistemului, dar în orice caz include straturi logice și fizice. Tematica 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 său, poate reprezenta domeniul său de subiect (de exemplu, un atelier de producție de caroserie al unei fabrici 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 se numește un element al sistemului informațional, informații despre care salvă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 localitate) Și abstract(de exemplu, un eveniment, un cont de client sau un curs pe care îl urmează studenții). Deci, în domeniul vânzărilor de mașini, exemple de obiecte sunt MODEL AUTO, CLIENT și CONT. Într-un depozit de mărfuri, acesta este un FURNIZOR, MĂRFURI, EXPEDIERE etc. Fiecare obiect are un anumit set de proprietăți care sunt stocate în sistemul informațional. Atunci 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 numită o colecție 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, desigur, pot fi diferite. De exemplu, proprietățile MODEL ale clasei de obiecte pentru fiecare obiect pot fi, desigur, diferite. De exemplu, clasa de obiecte CAR MODEL va avea același set de proprietăți care descriu caracteristicile mașinilor și fiecare model va avea sensuri diferite aceste caracteristici.

Obiectele și proprietățile lor sunt concepte ale lumii reale. În lumea informațiilor care există în mintea unui programator, ei vorbesc despre atributele obiectelor.

@ Atribut- aceasta este o afișare de informații despre proprietățile unui obiect. Fiecare obiect este caracterizat de o serie 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. Un client al unui magazin care vinde mașini 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 la implementarea unui model de informații pe orice mediu de stocare 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- aceasta este o structură regulată constând dintr-un set finit de înregistrări de același tip. În unele surse tabelul se numește relație.

Vom încerca să evităm ultimul termen, deoarece odată cu dezvoltarea teoriei relaționale, „relația”, împreună cu termenul „conexiune”, a început adesea să fie numite conexiuni între tabele. Fiecare înregistrare a unui tabel constă dintr-un număr finit (și identic!) de câmpuri, și un câmp specific pentru fiecare înregistrare a unui tabel poate conține un singur tip de date.

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

Elementul de date „NUMELE MODELULUI” poate lua 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 descrise prin mai multe elemente de date. date.

@ Se numește un singur set de valori acceptate de elementele de date instanță obiect. Obiectele sunt conectate între ele într-un anumit fel.

@ Se numește modelul corespunzător al obiectelor cu elementele lor de date constitutive și relațiile model conceptual domeniul subiectului. Un model conceptual oferă o perspectivă asupra fluxului de date într-un domeniu.

Unele elemente de date au o proprietate importantă pentru construirea unui model informațional. Dacă știm valoarea pe care o ia elementul de date al unui astfel de 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 unei mașini - 7, putem determina că este un „Voyager” 96” și că cilindreea motorului acestui model este „3778”.

@ Elementul cheie datele sunt un element din care pot fi determinate valorile altor elemente de date.

Două sau mai multe elemente de date pot identifica în mod unic un obiect. În acest caz, ele sunt numite elemente de date cheie „candidate”. Întrebarea este , ce candidat să folosească pentru a accesa obiectul este decis de utilizator sau de proiectantul sistemului. Elementele cheie ale datelor trebuie selectate cu grijă deoarece alegerea potrivita contribuie la crearea dreptului model conceptual date.

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

Conceptul de 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.

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

De exemplu, pentru obiectul „EMPLOYEE”, care are atributele „EMPLOYEE ID”, „LASTER NAME”, „NAME” și „PATRONICAL”, grupul de atribute „SURNAME”, „NAME”, „PATERNAME” poate fi o alternativă. cheia atributului „ID ANGAJAT” (presupunând că niciun angajați cu numele complet nu lucrează la întreprindere).

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

De exemplu, atributul MODEL NUMBER al unui obiect CAR poate fi o cheie străină pentru obiectul MODEL.

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

În fig. 1.2. Aceste elemente de date sunt cheia unică și numele modelului, deplasarea, numărul de cilindri și puterea motorului. De exemplu, una dintre intrări este „7 Voyager’96 3.8 Grand 3778 6.164,0” . Acest șir reprezintă valorile pe care le iau elementele de date ale obiectului VEHICLE MODEL. Înregistrările sunt stocate pe un mediu, care poate fi creier uman, o coală de hârtie, memorie computer, dispozitiv 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

Fig.1.2. MODEL înregistrări de date obiect.

Fiecare înregistrare a unui tabel constă dintr-un număr finit (și identic!) de câmpuri, și un câmp specific pentru fiecare înregistrare a unui tabel poate conține un singur tip de date

@ Tip de date caracterizează tipul de date stocate.

Conceptul de tip de date într-un model de informație este complet adecvat conceptului de tip de date în limbaje de programare. În mod obișnuit, 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, ar trebui 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 într-un fel legate de fapte de la o altă entitate. Menținerea consistenței dependențe funcționaleîntre entităţi se numeşte integritate referenţială. Deoarece relațiile sunt conținute „în interiorul” modelului relațional, implementarea integrității referențiale poate fi realizată fie de către aplicație, fie de către SGBD însuși (folosind mecanisme declarative de integritate referențială și declanșatoare).

Relațiile pot fi reprezentate de cinci caracteristici principale:

Tip de conexiune (identificare, neidentificare)

Entitatea-mamă;

Entitate copil (dependentă);

Puterea de comunicare (cordialitate);

Acceptarea valorilor goale (nule).

Conexiunea se numește identificare, dacă instanța entității copil este identificată (determinată fără ambiguitate) prin relația sa cu entitatea părinte. Atributele care alcătuiesc cheia primară a entității părinte sunt de asemenea incluse în cheia primară a entității copil. Entitate copil într-o relație de identificare este mereu dependent.

Relația se numește neidentificare, dacă instanța entității copil este identificată altfel decât printr-o relație cu entitatea mamă. Atributele care alcătuiesc cheia primară a entității părinte nu sunt incluse în atribute cheie entitate copil.

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

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

Procedurile stocate vă permit să conțineți programe destul de complexe împreună cu baza de date 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 proceduri stocate implică prelucrarea datelor. Astfel, baza de date poate fi funcțional nivel independent aplicație care poate comunica cu alte straturi pentru a primi cereri sau pentru a actualiza date.

@ Reguli vă permit să apelați execuția actiuni specificate atunci când modificați sau adăugați date în baza de date (DB) și controlați astfel 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ță, sunt 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 restricții, care sunt doar un mijloc de control asupra conditii simple corectitudinea introducerii 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 unei instanțe de entitate copil se potrivește cu valorile cheii primare din entitatea părinte.

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

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

Procesul de normalizare grupează elementele de date în tabele care reprezintă obiecte și relațiile lor. Teoria normalizării se bazează pe ideea că un anumit set de tabele are proprietăți mai bune pentru includerea, modificarea și ștergerea datelor decât toate celelalte seturi de tabele care pot reprezenta aceleași date. Introducerea normalizării relațiilor în dezvoltarea unui model informațional asigură volumul minim al unei baze de date fizice, adică înregistrat pe orice suport, și performanța maximă a acesteia, ceea ce afectează direct calitatea funcționării 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, semnificațiile, utilizările și formatele de prezentare ale acestora.

@ Asigurarea integritatii baza de date este un sistem de măsuri care vizează menținerea în orice moment a corectitudinii datelor din baza de date.

Costul verificării și menținerii integrității datelor poate reprezenta o parte semnificativă din total operațională cheltuieli. De exemplu, în întreprinderile de transport, pentru a controla corectitudinea introducerii datelor din documentația de călătorie, se practică introducerea paralelă a acelorași date de către mai mulți operatori. Se crede că probabilitatea de a face aceeași greșeală în acest caz va fi extrem de mică și o simplă comparație a rezultatelor de intrare diverși operatori vă va ajuta să obțineți 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 specifice care stabilesc admisibilitatea datelor și relațiile dintre acestea.

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

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

Procesul de creare a unui model de informare începe cu identificarea cerințelor conceptuale ale unui număr de utilizatori (Figura 2.1). Cerințele conceptuale pot fi determinate ș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, dar va ajuta la luarea în considerare pe deplin a tuturor nuanțelor funcționalității necesare pentru sistemul în curs de dezvoltare și va reduce probabilitatea reluării acestuia în viitor. Cerințele individuale ale utilizatorilor sunt integrate într-o singură „vizualizare rezumată”. Acesta din urmă se numește model conceptual.

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

Astfel, un model conceptual este în esență un model de domeniu. La proiectarea unui model conceptual, toate eforturile dezvoltatorului ar trebui să vizeze în principal 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 unui model conceptual se bazează pe o analiză a sarcinilor de prelucrare a datelor rezolvate la această întreprindere. Modelul conceptual include descrieri ale obiectelor și relațiilor lor care sunt de interes în domeniul subiectului luat în considerare și identificate ca rezultat al analizei datelor. Aici ne referim la date utilizate ca în cele deja dezvoltate programe de aplicație, ș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 de către SGBD-ul ales. Acest lucru va necesita o schimbare a modelului conceptual. Versiunea unui model conceptual care poate fi furnizată de un anumit SGBD se numește model logic.

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

Modelul de date logic poate fi relațional, ierarhic sau de rețea . Utilizatorilor li se aloca subseturi ale acestui model logic, numite modele externe (numite și subscheme în unele surse), care reflectă înțelegerea lor asupra domeniului subiectului. 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 afișat în memorie fizică, cum ar fi un disc, o bandă sau un alt mediu de stocare.

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

Din punctul de vedere al programării aplicațiilor, independența datelor este determinată nu de tehnica de programare, ci de disciplina acesteia. De exemplu, pentru a evita recompilarea aplicației ori de câte ori sistemul se schimbă, se recomandă să nu se definească constante (valori constante ale datelor) în program. O soluție mai bună este să treceți valorile programului ca parametri.

Toate cerințele actuale ale domeniului și cerințele „ascunse” adecvate acestora în faza de proiectare trebuie să fie reflectate în modelul conceptual. Desigur, este imposibil să se prevadă toate utilizările și modificările posibile ale bazei de date. 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ă modalități de utilizare a datelor pentru a obține informații.

Gradul de independență a datelor este determinat de proiectarea atentă a bazei de date. O analiză 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. Acesta este ceea ce înseamnă independența completă a datelor.

3. Relații în model

O relație exprimă o mapare 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 sarcina avută în vedere de automatizare a gestionării unei dealer auto, în cazul în care un client plasează o comandă pentru achiziționarea unei mașini pentru prima dată, se efectuează înregistrarea inițială a datelor și informațiilor sale despre comanda efectuată. Dacă clientul plasează din nou o comandă, doar această comandă este înregistrată. Indiferent de câte ori un anumit client a plasat 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, semn entitate legalăși notează. Astfel, atributele obiectului CLIENT sunt „CHEIA UNICA CLIENT”, „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 CLIENTULUI” și „CHEIA MODELULUI”. Iar al patrulea obiect în cauză este VÂNZĂTORUL. Atributele sale sunt „CHEIA UNICĂ A VÂNZĂTORULUI”, „NUMELE VÂNZĂTORULUI”, „NUMELE” și „NUMELE PARTICULUI”.

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

Să ne întoarcem mental la vremurile unei economii de distribuție planificate. Să presupunem că la un anumit moment în timp un client poate face o singură comandă. In acest caz, se stabileste o relatie intre obiectele CLIENT si COMANDA " unu la unu", indicat prin săgeți simple, așa cum se arată în Fig. 2.2,a.

Orez. 2.2. Relaţii între 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.

O relație unu-la-mai multe (î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 deține aceeași mașină. O relație unu-la-mai multe poate fi reprezentată printr-o singură săgeată într-o direcție și o săgeată dublă în direcția mai multe, așa cum se arată în Figura 1. 2.2, b.

În acest caz, o înregistrare de date a primului obiect (numit adesea părinte sau principal) va corespunde mai multor înregistrări ale celui de-al doilea obiect (copil sau subordonat). Relațiile unu-la-mulți sunt foarte frecvente în dezvoltarea bazelor de date relaționale. Obiectul părinte este adesea un director, iar obiectul copil stochează chei unice pentru accesarea intrărilor din director. În exemplul nostru, un astfel de director poate fi reprezentat de obiectul CLIENT, care stochează informații despre toți clienții. Când accesăm o înregistrare pentru un anumit client, avem acces la o listă cu toate achizițiile pe care le-a făcut și la 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, nu le vom vedea. În acest caz, se spune că obiectul conține înregistrări orfane (singurate). Acest lucru nu este acceptabil, 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ă vedem înregistrările obiectului MODEL AUTO, atunci în obiectul CLIENT putem obține date despre clientul care a achiziționat acest mașină (vezi fig. 2.4). Vă rugăm să rețineți că nu vom primi informații despre clienți pentru înregistrările pierdute.

O relație de la mulți la mulți (între două tipuri de obiecte).

În acest exemplu, fiecare vânzător 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, putem afla care vânzători au servit un anumit client. Totuși, în acest caz va trebui să creăm mai multe înregistrări pentru fiecare vânzător în obiectul SELLER. Fiecare linie va corespunde fiecărui serviciu pentru clienți din partea vânzătorului. Cu această abordare ne vom confrunta cu probleme serioase. De exemplu, nu vom putea introduce o cheie unică pentru fiecare vânzător în obiectul VÂNZĂTOR, deoarece în mod inevitabil un agent de vânzări va deservi mai mulți clienți, caz în care 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 a stoca relațiile 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 obiectului. 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 primite de la a acestui client. Dacă, împreună cu numărul clientului, un alt identificator unic (de exemplu, un număr de pașaport) este stocat în baza de date, atunci există o relație unu-la-unu între acești doi identificatori unici. În fig. 2.7a această relație este indicată prin săgeți simple.

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

Numele clientului și numărul clientului există împreună. Clienții cu aceleasi nume pot fi multe, dar toate au numere diferite. Fiecărui client i se atribuie un număr unic. Aceasta înseamnă că există un singur nume asociat unui anumit număr de client. O relație „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” (Fig. 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 agenți de vânzări. Mai mulți vânzători cu același nume ar putea primi comenzi de la mai mulți clienți. Există o relație multi-la-mulți între atributele „nume client” și „nume furnizor”. Notăm această relație cu săgeți duble (Fig. 2.7c).

A)

b)

V)

Orez. 2.7. Relații între două atribute:
a) relație unu-la-unu; b) relaţia unu-la-mai mulţi
» c) relație multi-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. Cele trei modele diferă în principal prin modul în care reprezintă relațiile dintre obiecte.

Modelul ierarhic de date este construit pe principiul unei ierarhii a tipurilor de obiecte, adică un tip de obiect este cel principal, iar restul, situat la niveluri inferioare ierarhie – subordonaţi (Fig. 2.8). Se stabilește o relație unu-la-mulți între obiectele master și slave. Cu alte cuvinte, pentru un anumit tip de obiect principal, există mai multe tipuri de obiecte subordonate. Î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 seamănă cu relațiile dintr-un arbore genealogic, cu o singură excepție: pentru fiecare tip de obiect copil (subordonat), poate exista un singur tip de obiect părinte (principal). 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 este numit nodul rădăcină (acesta este tipul principal de obiect). 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. Diagrama modelului de date ierarhice.

În modelul de date de rețea, conceptele de obiecte master și slave sunt oarecum extinse. Orice obiect poate fi atât master cât și slave (în modelul de rețea, obiectul master este notat cu termenul „proprietar al setului”, iar slave prin termenul „membru al setului”). Același obiect poate acționa simultan ca proprietar și ca membru al unui set. Aceasta înseamnă că fiecare obiect poate participa la orice număr de relații. Diagrama modelului de rețea este prezentată în Fig. 2.9.

Fig.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ă ( elementul cheie) – un câmp sau o combinație de câmpuri care identifică în mod unic fiecare rând dintr-un tabel. Datorită simplității și naturaleței prezentării, modelul relațional a devenit cel mai răspândit în SGBD-urile pentru calculatoare personale.

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

Diagrama de tip ER:

Simplificari:

1. Sunt considerați doar acei rezidenți care au un apartament.

2. Un rezident poate fi înregistrat doar într-un apartament.

3. Sunt luate în considerare doar apartamentele locuite în care sunt înregistrați rezidenți.

4. Mai mulți rezidenți pot fi înscriși într-un singur apartament.

5. Un număr de telefon pentru un apartament.

6. Nu orice apartament poate avea telefon.

7. Sunt rezidenți fără sursă de venit (copii).

8. Un rezident poate avea mai multe surse de venit.

9. Tipuri diferite venituri pentru diferiți rezidenți.

10. Există tipuri de venituri care nu sunt folosite.

Sfârșitul lucrării -

Acest subiect aparține secțiunii:

Comparația bazelor de date cu un singur tabel și cu mai multe tabele

Pe site citiți: „comparație între bazele de date cu un singur tabel și cu mai multe tabele”

Dacă aveți nevoie material suplimentar pe acest subiect, sau nu ați găsit ceea ce căutați, vă recomandăm să utilizați căutarea în baza noastră de date de lucrări:

Ce vom face cu materialul primit:

Dacă acest material ți-a fost util, îl poți salva pe pagina ta de pe rețelele sociale:

Toate subiectele din această secțiune:

Componentele BnD
Un dicționar de date este un „depozitar” de metainformații. Metainformații - informații

Etapa de definire a subcircuitului
Unele SGBD-uri au capacitatea de a descrie structura logică a bazei de date din punctul de vedere al unui anumit grup de utilizatori. Un astfel de model se numește extern, iar descrierea lui se numește subschemă

Modelarea infologică a domeniului subiectului. Compoziția modelului informațional (ILM)
1-2. Descrierea domeniului subiectului este reprezentată folosind un fel de sistem de semne, deci în

Descrierea obiectelor și proprietățile acestora. Tipuri de proprietăți ale obiectelor
O clasă de obiecte este o colecție de obiecte care au același set de proprietăți. Clasele de obiecte pot fi atât materiale, cât și abstracte (de exemplu, obiecte care

Diagrama de tip ER
Tipul de conexiune este de la 1 la 1. Clasa de obiecte aparținând atât lui P cât și K este opțională

Tipuri de obiecte complexe
1. Obiect compozit. 2. Obiect generalizat. 3. Obiect agregat. Obiect compozit

Determinarea componenței bazei de date
Una dintre abordările pentru determinarea compoziției unei baze de date este principiul sintezei. Esența: Doar indicatorii inițiali ar trebui stocați în baza de date. Toți indicatorii derivați trebuie

Tipuri de modele datalogice (DLM)
Pe baza metodei de stabilire a conexiunilor între date, se disting următoarele modele: Model relațional,Model ierarhic, Model de rețea,Model orientat pe obiect. Relatio

Indexarea fișierelor (tabelelor) în baza de date. Fișiere index și chei index
Pentru a accelera accesul la informațiile dintr-un fișier, fișierul este indexat. Cheia de index utilizată în indexare este atributul sau setul de atribute definite în relație. În parte

Metoda de proiectare RDB bazată pe ILM (regulile 1-12)
1. Pentru fiecare obiect simplu și proprietățile sale individuale, se construiește o relație ale cărei atribute sunt identificatori de obiect și detaliile corespund fiecărei proprietăți individuale.

Determinarea compoziției și a relațiilor bazei de date
Principiul de sinteză: Baza de date include atributele tuturor entităților + venitul calculat SumD. Baza de date este formată din 5 relații: PERSOANĂ (Nom, FIO, Rdate, Pol, S

Comparația bazelor de date cu un singur tabel și cu mai multe tabele
Pot apărea probleme de inserare, actualizare și ștergere. Problemă de inserare Orice bază de date nu trebuie să aibă câmpuri cu valori nedefinite sau goale. De exemplu: pentru od

Limbajul de interogare structurat
Implementările specifice SQL respectă cerințele standardului, dar oferă și caracteristici suplimentare(SQL1, SQL2(1992), SQL3(1999)) SQL poate fi utilizat în 2 moduri: 1. Int

Selectați oferta
TRP poate fi un nume de coloană, o constantă sau o expresie. Numele coloanei identifică una dintre coloanele conținute în tabelul care este specificat în clauza FROM. Se poate preciza


Specifică ce rânduri să selecteze. Condiția de căutare este setată ca criteriu de selecție. Tipuri de termeni de căutare: 1. Comparație. =,<>, <, >, <=, >=. 2. Demonstrează

Termeni de căutare compoziți. Tabelele de adevăr
ȘI adevărat fals nul SAU adevărat

Funcții agregate SQL
Interogările rezultate pot fi compuse din diverși operatori și funcții agregate limba. Toate funcțiile iau o întreagă coloană de date ca argument și returnează una, valoare rezumată

Interogări cu grupare și restricții asupra acestora
Selectați ADR, AVG(SUMD) FROM PERSON GROUP BY ADR 1. Informațiile despre rezidenți din tabelul Persoane sunt împărțite în grupuri - câte un grup pentru fiecare apartament. În fiecare grup, toate apartamentele au câte 1

Restricție pe lista coloanelor returnate
Într-o interogare de grupare, toate elementele din lista de coloane returnate trebuie să aibă aceeași valoare pentru fiecare grup de cuvinte. => Ca elemente ale listei de coloane returnate, puteți utiliza

Procedura pentru executarea unei interogări care conține o subinterogare asociată
1) Selectați un rând din tabel al cărui nume este specificat în interogarea principală. 2) Executați o subinterogare ținând cont de valorile conținute în rândul selectat 3) Calculați condițiile de căutare r

Se verifică dacă există rezultate ale subinterogării
SELECTAȚI *DIN PERSOANĂ UNDE EXISTĂ (SELECTARE ID-UL DIN HAVE_D, PROVIT WHERE PROVIT.ID

Adăugarea de elemente noi
Cea mai mică unitate de informație care poate fi adăugată la o bază de date este un singur rând. Există 2 moduri de a adăuga rânduri noi: 1) o instrucțiune INSERT de o linie, inclusiv

Ștergerea datelor existente
Cea mai mică unitate de informații care poate fi eliminată din baza de date este 1 rând. Pentru a șterge rânduri din primul tabel, se folosește instrucțiunea DELETE. DELETE FROM – nume_tabel -------------------

Condiții de unicitate a datelor
Să luăm tabelul PERSON și să descriem structura acestuia: CREATE TABLE PERSON (INTERBASE) (NOM INTEGER NOT N N

Modificarea definiției unui tabel
ALTER TABLE este folosit pentru a: 1. adăuga o nouă definiție de coloană. 2. modificați valoarea implicită. 3. modificați sau ștergeți cheia primară a tabelului.

Indici
Un index este un instrument care oferă acces rapid la rânduri de tabel pe baza valorii a 1 sau mai multe coloane. Indexul stochează valorile datelor și indicatorii către rânduri

Cele mai bune articole pe această temă