Model de date orientat pe obiecte

Modelul de date orientat pe obiect este o extensie a prevederilor programării orientate pe obiect (în timp ce modelul relațional a luat naștere pe baza teoriei mulțimilor, și anume ca model de date). Object DataBase Management Group a dezvoltat standardul ODMG-93 (Object DataBase Management Group). Acest standard nu a fost încă implementat pe deplin.

Structura unei baze de date orientate pe obiecte este reprezentată grafic ca un arbore, ale cărui noduri sunt obiecte. Structura vizibilă a unui obiect este determinată de proprietățile clasei sale. Clasă include obiecte, în timp ce structura și comportamentul obiectelor din aceeași clasă sunt aceleași. Fiecare obiect, și anume o instanță a unei clase, este considerat un descendent al obiectului în care este definit ca proprietate. Proprietățile obiectului- fie un tip standard, cum ar fi șir, fie un tip de clasă construit de utilizator. Comportamentul obiectelor este stabilit prin metode. Metodă este o operație care poate fi aplicată unui obiect.

Ca exemplu, luați în considerare baza de date „BIBLIOTECĂ” (Fig. 4.4). Proprietățile, tipurile și valorile acestora sunt definite pentru fiecare obiect. În DB:

„BIBLIOTECĂ” - părinte (strămoș) pentru „SUBSCRIPTION”, „CATALOG”, „RELEASE”;

„CATALOG” este părintele pentru „CARTE”.

„CARTE” – obiecte diferite pot avea aceiași părinți sau diferiți. Dacă același părinte (un autor), atunci numerele de inventar sunt diferite, dar isbn, UDC, titlul și autorul sunt aceleași.

Structura logică a unei baze de date orientate pe obiecte este similară cu una ierarhică, principala diferență este în metodele de manipulare a datelor. Pe baza de date, puteți efectua acțiuni precum operații logice, îmbunătățite prin metode orientate pe obiect de încapsulare, moștenire și polimorfism.

Încapsulare limitează domeniul de aplicare al unui nume de proprietate la obiectul în care este definit. Deci, dacă proprietatea este adăugată la „CATALOG” telefon autorul cărții, apoi se obțin în mod similar în „ABONAMENT” și „CATALOG”. Semnificația proprietății va fi determinată de obiectul în care este încapsulată.

Moştenire, dimpotrivă, extinde domeniul de aplicare al proprietății la toți descendenții obiectului. Deci, tuturor obiectelor de tip „CARTE”, care sunt descendenți ai „CATALOG”, li se pot atribui proprietățile isbn părinte, UDC, titlul și autorul.

Poliformismulînseamnă capacitatea aceluiași cod de program de a lucra cu date eterogene. Cu alte cuvinte, înseamnă admisibilitatea în obiecte de diferite tipuri de a avea metode - proceduri și funcții - cu aceleași denumiri. În timpul execuției unui program obiect, aceleași metode operează pe obiecte diferite în funcție de tipul argumentului. Pentru baza de date „BIBLIOTECĂ”, aceasta înseamnă că obiectele clasei „CARTE” care au părinți diferiți de clasa „CATALOG” pot avea un set diferit de proprietăți, adică. programele de lucru cu un obiect din clasa „CARTE” pot conține cod polimorf. În clasă, metoda nu are un corp, adică nu este definit ce acțiuni specifice ar trebui să efectueze. Fiecare subclasă efectuează operațiile necesare. Încapsularea ascunde detaliile de implementare de la toate obiectele din afara ierarhiei date.

Avantajele unui model orientat pe obiecte în comparație cu unul relațional sunt capacitatea de a afișa informații despre relațiile complexe ale obiectelor, absența limitărilor în structurile de stocare a datelor. O bază de date orientată pe obiecte poate stoca nu numai structura, ci și aspectele comportamentale ale datelor. Folosind abordarea orientată pe obiect, se pot crea și baze de date cu cantități mari de informații semantice, cum ar fi baze de date multimedia și baze de date specializate pentru domenii specifice (geografice, design etc.).

Dezavantajele acestei abordări includ complexitatea conceptuală ridicată, inconvenientul procesării datelor și viteza scăzută de execuție a interogărilor.

În anii 1990, au fost create prototipuri ale bazelor de date orientate pe obiecte existente. Aceștia sunt POET (POET Software), JASMINE (ASOCIAȚI DE CALCULATOR), IRIS, ORION, POSTGRES.

Tema 5

Abordarea relaţională în construirea unui model informaţional-logic: concepte de bază

Model de date relaționale. Noțiuni de bază

După cum sa menționat în secțiunea prelegerii anterioare, modelul relațional este în prezent unul dintre cele mai comune modele de pe piața bazelor de date. Baza acestui model este un set de tabele (relații) interdependente.

Principalele idei teoretice ale modelului relațional au fost conturate în lucrările de teorie relațională ale logicianului american Charles Souders Peirce (1839-1914) și ale logicianului german Ernst Schroeder (1841-1902), precum și ale matematicianului american Edgar Codd.

În lucrările lui Pierce și Schroeder s-a dovedit că setul de relații este închis sub niște operații speciale care formează împreună o algebră abstractă. Această proprietate esențială a relațiilor a fost folosită în modelul relațional pentru a dezvolta un limbaj de manipulare a datelor.

În 1970 a apărut un articol al lui E. Codd despre prezentarea datelor organizate sub formă de tabele bidimensionale, numite relații. Codd a introdus mai întâi conceptele de bază și limitările modelului relațional ca bază pentru stocarea datelor și a arătat posibilitatea procesării datelor folosind operații tradiționale pe seturi și operații relaționale speciale introduse.

Conceptele de bază ale modelului relațional sunt prezentate în tabel. 3.1.

Obiectele modelului relațional sunt în principal tabele (relații). Integritatea datelor este asigurată de chei străine și primare (vezi Secțiunea „Integritatea datelor relaționale”).

Operatorii din modelul relațional sunt un set de instrucțiuni care asigură preluarea și manipularea datelor.

Tabelul 5.1. Elemente ale modelului relațional

Termen model relațional	Descriere
Baza de date (DB)	Un set de tabele și alte obiecte necesare pentru reprezentarea abstractă a domeniului selectat
Schema DB	Un set de anteturi de tabel legate între ele
Atitudine	Tabel - un set de obiecte din lumea reală care sunt caracterizate prin proprietăți și caracteristici comune (câmpuri de tabel)
Antetul relației	Antet tabel - numele câmpurilor (coloanelor) din tabel
Organul de relație	Corpul tabelului este un set de valori pentru toate obiectele lumii reale, care este reprezentat ca intrări în tabel (rânduri de tabel)
schema de relatii	Rând antet coloană tabel (antet tabel)
atribut de relație	Numele coloanei tabelului (câmpul tabelului)
relație tuplu	Rând tabel (înregistrare) – o reprezentare unu-la-unu a unui obiect din lumea reală creată folosind valorile câmpului tabelului
Domeniu	Setul de valori de atribute valide
Valoarea atributului	Valoarea câmpului din înregistrare (tuplu)
cheia principala	Unul sau mai multe (în cazul unei chei compuse) atribute care definesc în mod unic valoarea tuplului (valoarea rândului tabelului)
Cheie externă	Un atribut al unui tabel ale cărui valori corespund cu valorile unei chei primare dintr-un alt tabel înrudit (părinte, primar). O cheie externă poate consta din unul sau mai multe atribute (cheie externă compusă). Dacă numărul de atribute ale cheii străine este mai mic decât numărul de atribute ale cheii primare corespunzătoare, atunci se numește cheie străină trunchiată (parțială).
Gradul (aritatea) relației	Numărul de coloane din tabel
Puterea Relațională	Numărul de rânduri (tupluri) din tabel
Instanță de relație	Un set de înregistrări (tupluri) pentru un anumit tabel (relație). O instanță se poate schimba în timp. Deoarece o bază de date obișnuită la momentul curent funcționează cu o singură versiune a relației, o astfel de instanță a relației se numește cea curentă.
Tip de date	Tipul valorii elementului de tabel
Raportul de bază	Relație care conține una sau mai multe coloane care caracterizează proprietățile obiectului, precum și o cheie primară
Relație derivată	Nu este o relație de bază, adică nu caracterizează proprietățile obiectului și este folosit pentru a oferi legături între alte tabele, nu poate conține o cheie primară. Dacă este specificată o cheie primară, atunci aceasta constă din chei străine care sunt legate de cheile primare ale relației de bază.
Conexiune	Stabilește o relație între valorile de potrivire în câmpurile cheie - cheia primară a unui tabel și cheia externă a altuia
Comunicare unu-la-unu (1:1)	Când se utilizează acest tip de relație, o intrare dintr-un tabel poate avea cel mult o intrare asociată într-un alt tabel. În ambele tabele, câmpurile cheie trebuie să fie primare. Folosit pentru a separa tabele cu mai multe câmpuri sau pentru cerințele de protecție a datelor
Relație unu-la-mulți (1:M)	Când se utilizează acest tip de relație, fiecare înregistrare a unui tabel poate corespunde mai multor înregistrări a celui de-al doilea, dar fiecare înregistrare a celui de-al doilea tabel corespunde doar unei înregistrări a primului tabel. Primul tabel trebuie să aibă o cheie primară, al doilea trebuie să aibă o cheie străină.
Relație multi-la-mulți (N:M)	Cu acest tip de relație, o înregistrare din primul tabel poate corespunde mai multor înregistrări ale celui de-al doilea tabel, dar o înregistrare din cel de-al doilea tabel poate corespunde și mai multor înregistrări ale primului. Nu este necesară unicitatea cheilor pentru astfel de tabele. În procesul de proiectare a unei scheme de bază de date, astfel de legături sunt transformate. Pentru a face acest lucru, trebuie să introduceți o relație auxiliară care vă permite să înlocuiți relația multi-la-mulți cu două relații unu-la-mulți

Structura de date a modelului relațional presupune reprezentarea domeniului subiect al problemei luate în considerare ca un set de relații interdependente.

În fiecare relație, o relație poate acționa ca principală (bază, părinte), iar cealaltă ca subordonată (derivată, copil). Pentru a menține aceste legături, ambele relații trebuie să conțină un set de atribute prin care sunt legate: în relația principală, aceasta este cheia primară a relației (identifică în mod unic tuplul relației principale); relația copil trebuie să aibă un set de atribute corespunzătoare cheii primare a relației principale. Aici, acest set de atribute este deja o cheie secundară sau o cheie străină, adică definește un set de tupluri de relații derivate asociate cu un singur tuplu al relației de bază.

Se formează un set de tabele interconectate schema bazei de date.

Deci relația R este un tabel bidimensional care conține unele date.

Din punct de vedere matematic N relație -ariană R este mulţimea produsului cartezian D 1×D 2×…×Dn seturi (domenii) D 1 , D 2 ,…,D n(n≥1), opțional diferite:

R D 1×D 2×…×Dn,

Unde D 1×D 2×…×Dn este produsul cartezian complet, i.e. un set de combinații posibile de n elemente fiecare, unde fiecare element este luat din domeniul său.

Domeniu este un concept semantic care poate fi gândit ca un subset de valori ale unor tipuri de date care au o semnificație specifică.

Proprietățile domeniului:

Domeniul are un nume unic (în baza de date),

Definit pe un tip de date simplu sau pe un alt domeniu,

Poate avea o condiție booleană pentru a descrie subsetul de date permis pentru acel domeniu,

Poartă o anumită încărcătură semantică.

Valoarea principală a domeniilor este că restricționează comparațiile: nu poți compara valori din domenii diferite, chiar dacă au același tip de date.

Atribut relația este o pereche de formă

<Имя_атрибута: Имя_домена>(sau<ANUNȚ>).

Numele atributelor dintr-o relație sunt unice. Adesea, numele atributelor sunt aceleași cu numele de domenii corespunzătoare.

O relație R definită pe un set de domenii conține două părți: un antet și un corp.

Antetul relației– un număr fix de atribute de relație care descriu produsul cartezian al domeniilor pe care este specificată relația:

(<A1: D1>, <A2: D2 >, …, <Si n>).

Antetul este static: nu se modifică în timpul lucrului cu baza de date.Dacă atributele sunt modificate, adăugate sau șterse în relație, atunci se obține o altă relație. Chiar și cu numele salvat.

Corp relația conține un set de tupluri de relație.

Fiecare tuplu este un set de perechi de forma:

<Имя_атрибута: Значение атрибута>:

R(<A1:Val1>, <A2:Val2 >, …, <A n: Val n>).

Astfel încât valoarea Val i atribut Ai aparține domeniului D i.

Corpul relației este un set de tupluri, adică o submulțime a produsului cartezian al domeniilor. Astfel, corpul relației este de fapt o relație în sensul matematic al cuvântului. Corpul relației se poate schimba în timpul lucrului cu baza de date, deoarece tuplurile se pot modifica, pot fi adăugate și eliminate în timp.

Relația este de obicei scrisă astfel:

R(<A1: D1>, <A2: D2 >, …, <Si n>),

sau prescurtat: R(A 1, A2, …, A n) sau R.

schema de relatii este un set de anteturi de relații incluse în baza de date, adică o listă de nume de atribute ale unei relații date, indicând domeniul la care se referă:

S R =(A 1, A2, …, A n), A i D i, i = 1,...,n.

Dacă atributele iau valori din același domeniu, atunci ele sunt numite θ-comparabile, unde θ este setul de comparații valide specificate pentru acest domeniu.

De exemplu, dacă domeniul conține date numerice, atunci toate operațiunile de comparare sunt permise pentru acesta: θ == (=,<>,>=,<=,<,>). Cu toate acestea, pentru domeniile care conțin date de caractere, nu pot fi specificate numai operațiuni de comparare pentru egalitatea și inegalitatea valorilor. Dacă unui anumit domeniu i se oferă o ordonare lexicografică, atunci are și un set complet de operații de comparare.

Se numesc scheme a două relații echivalent, dacă au același grad și este posibil să se aranjeze numele atributelor în scheme astfel încât atributele comparabile, adică atributele care preiau valori din același domeniu, să fie în aceleași locuri.

Astfel, pentru relațiile echivalente sunt îndeplinite următoarele condiții:

Avand acelasi numar de atribute;

Prezența atributelor cu aceleași nume;

Prezența șirurilor identice în relații, ținând cont de faptul că ordinea atributelor poate varia;

Relațiile de acest fel sunt reprezentări diferite ale aceleiași relații.

Proprietățile relației rezultă direct din definiția de mai sus a unei relații. Aceste proprietăți sunt principalele diferențe dintre relațiile modelelor de date relaționale și tabelele simple:

Unicitatea numelui relației. Numele unei relații trebuie să fie diferit de numele altor relații.

Unicitatea tuplurilor. Nu există tupluri identice în relație. Într-adevăr, corpul relației este un set de tupluri și, ca orice mulțime, nu poate conține elemente care nu se pot distinge. Tabelele, spre deosebire de relații, pot conține rânduri identice. Fiecare celulă de relație conține doar o valoare atomică (indivizibilă).

Tulburarea tuplilor. Tuplurile nu sunt ordonate (de sus în jos), deoarece corpul relației este o mulțime, iar mulțimea nu este ordonată (pentru comparație, rândurile din tabele sunt ordonate). Aceeași relație poate fi reprezentată prin tabele diferite cu rânduri în ordine diferită.

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

Unicitatea numelui atributului în cadrul relației. Fiecare atribut are un nume unic în cadrul relației, ceea ce înseamnă că ordinea atributelor nu contează (pentru comparație, coloanele din tabel sunt ordonate). Această proprietate distinge oarecum o relație de definiția matematică a unei relații. Aceeași relație poate fi reprezentată prin tabele diferite în care coloanele sunt într-o ordine diferită.

Atomicitatea valorilor atributelor. Toate valorile atributelor sunt atomice. Acest lucru rezultă din faptul că atributele de bază au valori atomice, adică un domeniu de valoare (tip elementar separat) este asociat cu fiecare tribut, valorile atributelor sunt luate din același domeniu. Schema și tuplurile relației sunt mulțimi, nu liste, deci ordinea în care sunt prezentate nu contează. Pentru comparație - în celulele tabelului pot fi plasate diverse informații: matrice, structuri, alte tabele etc.

Cometariu:

Din proprietăţile relaţiei rezultă că nu fiecare tabelul poate fi o relație. Pentru ca un anumit tabel să definească o relație, este necesar ca tabelul să aibă o structură simplă (conține doar rânduri și coloane, iar fiecare rând trebuie să aibă același număr de câmpuri), tabelul să nu aibă aceleași rânduri, orice coloana tabelului trebuie să conțină date de un singur tip, toate tipurile de date utilizate trebuie să fie simple.

Trebuie remarcat faptul că modelul relațional este o bază de date sub forma unui set de relații interdependente, care se numesc schema bazei de date relaționale.

Noțiuni de bază

Definiția 1

Model orientat pe obiecte reprezentarea datelor face posibilă identificarea înregistrărilor individuale ale bazei de date.

Înregistrările bazelor de date și funcțiile lor de procesare sunt conectate prin mecanisme similare instrumentelor corespunzătoare care sunt implementate în limbaje de programare orientate pe obiecte.

Definiția 2

Reprezentare grafică Structura unei baze de date orientate pe obiecte este un arbore ale cărui noduri reprezintă obiecte.

Tip standard (de exemplu, șir - şir) sau un tip creat de utilizator ( clasă), descrie proprietățile obiectului.

În Figura 1, obiectul LIBRARY este părintele obiectelor de instanță ale claselor CATALOG, SUBSCRIBER și ISSUES. Diferite obiecte de tip CARTE pot avea unul sau diferiți părinți. Obiectele de tip BOOK care au același părinte trebuie să aibă cel puțin numere de acces diferite (unice pentru fiecare instanță a cărții), dar aceleași valori de proprietate autor, titlu, udkși isbn.

Structurile logice ale unei baze de date orientate pe obiecte și ierarhice sunt similare în exterior. Ele diferă în principal prin metodele de manipulare a datelor.

Când se efectuează acțiuni asupra datelor într-un model orientat pe obiecte, sunt utilizate operații logice, care sunt îmbunătățite prin încapsulare, moștenire și polimorfism. Cu anumite limitări, puteți utiliza operațiuni care sunt similare cu comenzile SQL (de exemplu, când creați o bază de date).

La crearea și modificarea unei baze de date, se formează automat și se corectează ulterior indicii (tabelele de index) care conțin informații pentru recuperarea rapidă a datelor.

Definiția 3

Ţintă încapsulare– limitarea domeniului de aplicare a numelui proprietății la limitele obiectului în care este definit.

De exemplu, dacă la obiectul CATALOG este adăugată o proprietate care specifică numărul de telefon al autorului și are numele telefon, atunci proprietățile cu același nume vor fi obținute pentru obiectele CATALOG și SUBSCRIBER. Sensul unei proprietăți este determinat de obiectul în care este încapsulată.

Definiția 4

Moştenire, reversul încapsulării, este responsabil pentru extinderea domeniului de aplicare a proprietății la toți descendenții obiectului.

De exemplu, tuturor obiectelor BOOK care sunt copii ale obiectului CATALOG li se pot atribui proprietățile obiectului părinte: autor, titlu, udkși isbn.

Dacă este necesar să se extindă acțiunea mecanismului de moștenire la obiecte care nu sunt rude imediate (de exemplu, la doi descendenți ai aceluiași părinte), o proprietate de tip abstract este definită în strămoșul lor comun. abs.

Deci proprietățile camerăși bilet din obiectul LIBRARY sunt moștenite de toate obiectele copil LENDING, BOOK și SUBSCRIBER. De aceea, valorile acestei proprietăți a claselor SUBSCRIBER și ISUANCE sunt aceleași - 00015 (Figura 1).

Definiția 5

Polimorfismul permite aceluiași cod de program să lucreze cu date eterogene.

Cu alte cuvinte, permite obiectelor de diferite tipuri să aibă metode (funcții sau proceduri) cu aceleași nume.

Căutareîntr-o bază de date orientată pe obiect este de a determina asemănarea dintre obiectul pe care îl specifică utilizatorul și obiectele care sunt stocate în baza de date.

Avantajele și dezavantajele modelului orientat pe obiecte

Principal avantaj Modelul de date orientat pe obiecte, spre deosebire de modelul relațional, este capacitatea de a afișa informații despre relațiile complexe ale obiectelor. Modelul de date luat în considerare permite definirea unei înregistrări separate a bazei de date și a funcțiilor sale de procesare.

LA neajunsuri Modelul orientat pe obiecte include complexitate conceptuală ridicată, procesare incomodă a datelor și viteză scăzută de execuție a interogărilor.

Până în prezent, astfel de sisteme sunt destul de răspândite. Acestea includ DBMS:

• postgres,
• orion,
• iris,
• ODBJupiter,
• Versant,
• Obiectivitate/DB,
• depozit de obiecte,
• static,
• piatră prețioasă
• g baza.

În OOMD, la prezentarea datelor, este posibilă identificarea înregistrărilor individuale ale bazei de date. Relațiile se stabilesc între înregistrările bazei de date și funcțiile lor de procesare folosind mecanisme similare instrumentelor corespunzătoare din limbajele de programare orientate pe obiecte.

Un model standardizat orientat pe obiecte este descris în recomandările standardului ODMG-93 (Object Database Management Group - an object-oriented database management group). Nu a fost încă posibilă implementarea completă a recomandărilor ODMG-93. Pentru a ilustra ideile cheie, luați în considerare un model oarecum simplificat al unei baze de date orientate pe obiecte.

Structura unei baze de date orientate pe obiecte (OODB) este reprezentată grafic ca un arbore, ale cărui noduri sunt obiecte. Proprietățile obiectului sunt descrise de un tip standard (de exemplu, șir - șir) sau un tip construit de utilizator (definit ca o clasă).

Valoarea unei proprietăți de tip șir este un șir de caractere. Valoarea unei proprietăți de tip clasă este un obiect care este o instanță a clasei corespunzătoare. Fiecare obiect de instanță de clasă este considerat un copil al obiectului în care este definit ca proprietate. Un obiect de instanță al unei clase aparține clasei sale și are un părinte. Relațiile generice din baza de date formează o ierarhie coerentă a obiectelor.

Un exemplu de structură logică a unui OODB pentru biblioteconomie este prezentat în fig. 2.8.

Aici, obiectul de tip LIBRARY este părintele obiectelor de instanță ale claselor SUBSCRIBER, CATALOG și ISUANCE. Diferite obiecte de tip CARTE pot avea parinti identici sau diferiti. Obiectele de tip BOOK care au același părinte trebuie să difere cu cel puțin un număr de acces (unic pentru fiecare instanță de carte), dar să aibă aceleași valori de proprietate isbn, udk, titluși autor.

Orez. 2.8. Structura logică a bazei de date a biblioteconomiei

Structura logică a OODB este similară în exterior cu structura BID. Principala diferență dintre ele este în metodele de manipulare a datelor.

Pentru a efectua acțiuni asupra datelor din modelul de bază de date considerat, sunt utilizate operații logice, îmbunătățite de mecanisme orientate pe obiect de încapsulare, moștenire și polimorfism. Operațiuni similare cu comenzile SQL pot fi utilizate într-o măsură limitată (de exemplu, pentru a crea o bază de date).

Crearea și modificarea bazei de date este însoțită de formarea automată și ajustarea ulterioară a indicilor (tabele de indici) care conțin informații pentru recuperarea rapidă a datelor.

Să luăm în considerare pe scurt conceptele de încapsulare, moștenire și polimorfism în relație cu modelul bazei de date orientate pe obiecte.

Încapsulare limitează domeniul de aplicare al unui nume de proprietate la obiectul în care este definit. Deci, dacă adăugăm o proprietate unui obiect de tip CATALOG care specifică numărul de telefon al autorului cărții și are numele telefon, atunci vom obține proprietăți cu același nume pentru obiectele SUBSCRIBER și CATALOG. Semnificația unei astfel de proprietăți va fi determinată de obiectul în care este încapsulată.

Moştenire,în schimb, extinde domeniul de aplicare al proprietății la toți descendenții obiectului. Deci, tuturor obiectelor de tip BOOK, care sunt descendenți ai unui obiect de tip CATALOG, li se pot atribui proprietățile obiectului părinte: isbn, udk, title și autor. Dacă este necesară extinderea acțiunii mecanismului de moștenire la obiecte care nu sunt rude imediate (de exemplu, între doi descendenți ai aceluiași părinte), atunci o proprietate abstractă de tip abs este definită în strămoșul lor comun. Astfel, definirea biletului de proprietăți abstracte și numărului în obiectul LIBRARY duce la moștenirea acestor proprietăți de către toate obiectele copil SUBSCRIBER, BOOK și ISUANCE. Nu întâmplător, prin urmare, valorile proprietății bilet clasele Abonat și EMISIune prezentate în figură vor fi aceleași - 00015.

Polimorfismul v limbaje de programare orientate pe obiect înseamnă capacitatea aceluiași cod de program de a lucra cu date eterogene. Cu alte cuvinte, înseamnă că obiectele de diferite tipuri pot avea metode (proceduri sau funcții) cu aceleași nume. În timpul execuției unui program obiect, aceleași metode operează pe obiecte diferite în funcție de tipul argumentului. În raport cu baza noastră de date orientată pe obiecte, polimorfismul înseamnă că obiectele clasei BOOK care au părinți diferiți față de clasa CATALOG pot avea un set diferit de proprietăți. În consecință, programele de lucru cu obiecte din clasa BOOK pot conține cod polimorf.

Căutarea în OODB constă în aflarea asemănării dintre obiectul specificat de utilizator și obiectele stocate în baza de date. Un obiect definit de utilizator numit obiect țintă (o proprietate a unui obiect are un felpoartă), în cazul general, poate fi un subset al întregii ierarhii de obiecte stocate în baza de date. Obiectul țintă, precum și rezultatul execuției interogării, pot fi stocate în baza de date însăși. În Fig. 2.9.

Orez. 2.9. Fragment dintr-o bază de date cu un obiect țintă

Principal demnitate OOMD în comparație cu relațional este capacitatea de a afișa informații despre relațiile complexe ale obiectelor. OOMD vă permite să identificați o singură înregistrare a bazei de date și să definiți funcțiile procesării acestora.

Principal neajunsuri OOMD sunt complexitatea conceptuală ridicată, inconvenientul procesării datelor și viteza scăzută de execuție a interogărilor.

În anii 90, au existat prototipuri experimentale de OODBMS. În prezent, există peste 300 de astfel de SGBD. Unele sisteme sunt relativ răspândite, cum ar fi următoarele DBMS: Cache (InterSystems), ROET (ROET Software), Jasmine (Computer Associates), Versant (VersantTechnologies), O2 (ArdentSoftware), ODB-Jupiter (Centrul de cercetare și producție „Inteltek Plus”) "), precum și Iris, Orion și Postgres.

Avantajele OODB în viitor ar trebui să conducă la o distribuție foarte largă a acestora. Pentru a face acest lucru, mai întâi trebuie să rezolvați problemele de eliminare a deficiențelor inerente ale OODB: creșteți flexibilitatea structurii bazei de date, construiți un limbaj de programare clar, elaborați sintaxa pentru analizarea interogărilor, definiți mai multe metode de accesare a datelor, lucrați probleme de acces simultan, determină enumerarea complexă a datelor, elaborează protecția și recuperarea datelor. Lista sarcinilor care trebuie rezolvate poate fi continuată.

Cu toate acestea, chiar și după rezolvarea acestor probleme, trecerea la OODB va fi treptată și nu foarte rapidă, deoarece va fi dificil să se rupă de numărul imens de SGBD relaționale existente din motive obiective și subiective. Pentru a face o astfel de tranziție mai puțin dureroasă va permite includerea în OODBMS nu numai a obiectului, ci și a componentei relaționale. În plus, MMD ar trebui introdus în OODBMS pentru a forma un depozit de date sisteme OLAP, care sunt din ce în ce mai solicitate în practică.

Tehnologiile de baze de date bazate pe MD descrise mai sus se bazează pe conceptul static de stocare a informațiilor, axat pe modelarea datelor. Cu toate acestea, noi domenii de aplicare a tehnologiei cu obiecte de baze de date complexe, interconectate, cum ar fi:

Proiectare asistată de calculator;

Productie automatizata;

Dezvoltare automată de software;

Sisteme informatice de birou;

Sisteme multimedia;

sisteme de geoinformatii;

Sistemele de publicare și altele au demonstrat limitările conceptului static în ceea ce privește modelarea obiectelor din lumea reală.

Pentru noile tipuri de aplicații complexe de baze de date specializate, conceptul dinamic de stocare a informațiilor este eficient, permițând modelarea în paralel a datelor și proceselor care acționează asupra acestor date. Acest lucru permite să se țină cont de semantica domeniului subiectului și, prin urmare, să descrie cel mai adecvat aceste aplicații. Acest concept se bazează pe abordarea orientată pe obiecte utilizată pe scară largă în dezvoltarea de software. MD care implementează acest concept și se bazează pe paradigma orientată pe obiect (OOP) se numește model de date orientat pe obiect (OODM).

Construcția OOMD se bazează pe presupunerea că domeniul poate fi descris de un set de obiecte. Fiecare obiect este o entitate identificabilă în mod unic care conține atribute care descriu starea obiectelor din „lumea reală” și acțiunile asociate acestora. Starea curentă a unui obiect este descrisă de unul sau mai multe atribute, care pot fi simple sau complexe. Un atribut simplu poate avea un tip primitiv (de exemplu, întreg, șir etc.) și poate lua o valoare literală. Un atribut compus poate conține colecții și/sau link-uri. Un atribut de legătură reprezintă o relație între obiecte.

Proprietatea cheie a unui obiect este unicitatea identificării acestuia. Prin urmare, fiecare obiect dintr-un sistem orientat pe obiecte trebuie să aibă propriul său identificator.

Un identificator de obiect (OID) este un mod intern al bazei de date de marcare a obiectelor individuale. Utilizatorii care lucrează cu o interogare sau un dialog de vizualizare nu văd de obicei acești identificatori. Ele sunt atribuite și utilizate de către SGBD în sine. Semantica identificatorului din fiecare SGBD este diferită. Poate fi fie o valoare aleatorie, fie conține informații necesare pentru a găsi obiectul în fișierul bazei de date, cum ar fi numărul paginii din fișier și decalajul obiectului de la începutul acestuia. Este identificatorul care ar trebui folosit pentru a organiza referințele la obiect.

Toate obiectele sunt încapsulate, adică reprezentarea sau structura internă a obiectului rămâne ascunsă utilizatorului. În schimb, utilizatorul știe doar că obiectul poate îndeplini o anumită funcție. De exemplu, pentru un obiect WAREHOUSE pot fi aplicate metode precum ACCEPT_ITEM, ISSUE_TOBAP etc.. Avantajul încapsulării este că vă permite să schimbați reprezentarea internă a obiectelor fără a reproiecta aplicațiile care folosesc aceste obiecte. Cu alte cuvinte, încapsularea implică independența datelor.

Un obiect încapsulează date și funcții (metode, conform OOP). Metodele definesc comportamentul unui obiect. Ele pot fi folosite pentru a schimba starea unui obiect prin modificarea valorilor atributelor acestuia sau pentru a interoga valorile atributelor selectate. De exemplu, ar putea exista metode de a adăuga informații despre o nouă proprietate închiriată, de a actualiza informațiile despre salariul unui angajat sau de a tipări informații despre un anumit produs.

Obiectele care au același set de atribute și răspund la aceleași mesaje pot fi grupate în Clasă(în literatură, termenii „clasă” și „tip” sunt adesea folosiți în mod interschimbabil). Fiecare astfel de clasă are propriul său reprezentant - un obiect, care este elementul de date. Obiectele unei anumite clase sunt numite copii.

În unele sisteme orientate pe obiecte, o clasă este, de asemenea, un obiect și are propriile atribute și metode numite atribute de clasă și metode de clasă.

Conceptele importante ale POO sunt ierarhia claselor și ierarhia containerelor.

ierarhia claselor implică posibilitatea ca fiecare clasă, numită în acest caz superclasă, să aibă propria sa subclasă. Următorul lanț poate fi citat ca exemplu: toți programatorii unei întreprinderi sunt angajații acesteia, prin urmare, fiecare programator care, în cadrul OODM, este un obiect al clasei PROGRAMMER, este și un angajat, care, la rândul său , este un obiect al clasei ANGAJATE. Astfel, PROGRAMMERS ar fi o subclasă, STAFF ar fi o superclasă. Dar programatorii pot fi împărțiți și în programatori de sistem și de aplicații. Prin urmare, PROGRAMMERS va fi o superclasă pentru subclasele SIS_PROGRAMMERS și APPLIC_PROGRAMMERS. Continuând acest lanț mai departe, obținem o ierarhie de clasă, în care fiecare obiect subclasă moștenește instanțe de variabile și metode ale superclasei corespunzătoare.

Există mai multe tipuri de moștenire - unică, multiplă și selectivă. Moștenirea singulară este atunci când subclasele moștenesc de la cel mult o superclasă. Moștenire multiplă - moștenire de la mai multe superclase. Moștenirea selectivă permite unei subclase să moștenească un număr limitat de proprietăți din superclasa sa.

Moștenirea instanței variabile este numită moștenirea structurală, mostenire metoda - moștenirea comportamentală, iar capacitatea de a folosi aceeași metodă pentru clase diferite, sau mai degrabă de a folosi metode diferite cu același nume pentru clase diferite, se numește polimorfism.

Arhitectura orientată pe obiecte are și un alt tip de ierarhie - ierarhia containerelor. Constă în faptul că unele obiecte pot fi cuprinse conceptual în altele. Astfel, un obiect din clasa DEPARTAMENT trebuie să conțină o variabilă publică HEAD, care este o referință la obiectul clasei ANGAJAT corespunzător șefului de departament și trebuie să conțină și o referință la un set de referințe la obiecte corespunzătoare angajaților care lucrează în acest departament.

În unele sisteme orientate pe obiecte, o clasă este, de asemenea, un obiect și are propriile atribute și metode. Caracteristicile generale ale unei clase sunt descrise de atributele sale. Metodele unei clase de obiecte sunt un fel de analog al proprietăților obiectelor din lumea reală. Fiecare obiect aparținând unei anumite clase are aceste proprietăți. Prin urmare, atunci când un obiect este creat, este necesar să se declare clasa căreia îi aparține pentru a-și defini proprietățile inerente.

Utilizatorul și obiectul interacționează prin mesaje. Ca răspuns la fiecare mesaj, sistemul execută metoda corespunzătoare.

Toate relațiile din modelul obiect sunt realizate folosind atribute de referință, care sunt de obicei implementate ca OID-uri.

Relațiile dintr-o bază de date relațională sunt reprezentate prin potrivirea cheilor primare și externe. Nu există structuri în baza de date în sine pentru a forma asocieri între tabele; legăturile sunt folosite după cum este necesar atunci când se conectează tabele. În schimb, relațiile sunt coloana vertebrală a unei baze de date orientate pe obiect, deoarece fiecare obiect include ID-urile obiectelor cu care este asociat.

În OOMD, pot fi implementate nu numai legăturile tradiționale, ci și legăturile datorate moștenirii.

Relație unu-la-unu (1:1)între obiectele A și B este implementat prin adăugarea unui atribut de referință pe obiectul B la obiectul A și (pentru a menține integritatea referențială) un atribut de referință pe obiectul A la obiectul B.

Relație unu-la-mulți (1:M)între obiectele A și B este implementat prin adăugarea unui atribut de referință la obiectul B la obiectul A și un atribut care conține un set de legături către obiectul A la obiectul B (de exemplu, se adaugă un atribut de referință B (OID2, OID3 ...) la obiectul A și instanțe ale obiectului B cu OID2, OID3, ... se adaugă atributul de referință A: OID1.

Relație multi-la-mulți (M:N)între obiectele A și B se implementează prin adăugarea unui atribut care conține un set de legături către fiecare obiect.

În OODM, puteți utiliza relația „toate-parte”, care descrie faptul că un obiect dintr-o clasă conține obiecte din alte clase ca părți ale sale. În cazul unei baze de date de producție, ar exista o relație „întreaga parte” între clasa PRODUCT și clasele PART și ASSEMBLY. Această relație este o variantă a relației multi-la-mulți care are o semantică specială. O relație între părți este implementată ca orice altă relație multi-la-mulți, cu un set de identificatori de obiect asociați. Cu toate acestea, spre deosebire de relația obișnuită multi-la-mulți, are o semnificație semantică diferită.

Deoarece paradigma orientată pe obiect acceptă moștenirea, este posibil să se utilizeze o relație „este” și o relație „extinde” în OODM. Relația „este”, cunoscută și sub denumirea de relație generalizare-specializare, creează o ierarhie de moștenire în care subclasele sunt cazuri speciale de superclase. Acest lucru permite să nu descriem caracteristicile remoștenite. Când se utilizează relația „extinde”, subclasa extinde funcționalitatea superclasei, mai degrabă decât să se limiteze la cazul său special.

Să luăm în considerare modul în care componente precum constrângerile de integritate și operațiunile asupra datelor sunt implementate în OOMD.

Caracteristicile acestor componente sunt determinate de specificul modelului. Această specificitate în OOMD este dictată în primul rând de concepte interne precum încapsularea obiectului, adică secretul structurii interne, accesul la date numai prin metode definite în prealabil, ierarhia de clasă și ierarhia containerului.

Specificul OOMD este dictat și de specificul obiectului. Se manifestă prin nevoia de a grupa obiectele în clase. Fiecare obiect este inclus într-o clasă sau alta în funcție de sarcină, iar un obiect poate aparține mai multor clase deodată (de exemplu, familiile PROGRAMĂTORI și PILOTE). O altă caracteristică specifică a unui obiect este că poate „rula” de la o clasă (subclasă) la alta. Astfel, un PROGRAMATOR DE SISTEM poate deveni eventual un PROGRAMATOR APLICAT. Astfel, ierarhia de clasă nu este analogă cu modelul ierarhic, așa cum ar putea părea înainte, ci necesită ca sistemul să poată schimba locația fiecărui obiect în ierarhia de clasă, de exemplu, să se deplaseze „în sus” sau „în jos” în ierarhia dată. Dar este posibil și un proces mai complex - sistemul trebuie să ofere posibilitatea unui obiect de a fi atașat (detașat) la un vârf arbitrar al ierarhiei în orice moment.

Constrângerile de integritate a legăturilor joacă un rol important în OODM. Pentru ca legăturile dintr-un DM orientat pe obiect să funcționeze, identificatorii de obiect de pe ambele părți ale legăturii trebuie să se potrivească. De exemplu, dacă există o asociere între ANGAJATI și COPII lor, atunci trebuie să existe o anumită garanție că atunci când un obiect care descrie un copil este inserat într-un obiect care reprezintă un angajat, ID-ul angajatului este adăugat la obiectul corespunzător. Acest tip de integritate a legăturilor, oarecum analogă integrității referențiale din modelul de date relaționale, se stabilește cu ajutorul legăturilor înapoi. Pentru a asigura integritatea legăturilor, proiectantului i se oferă sintaxa specială necesară pentru a specifica locația identificatorului invers al obiectului. Este responsabilitatea proiectantului să stabilească constrângeri asupra integrității relațiilor (precum și integrității referențiale într-o bază de date relațională).

În OOMD, atât descrierea datelor, cât și manipularea acestora au loc folosind același limbaj procedural orientat pe obiecte.

ODMG (Object Database Management Group) se ocupă de problemele standardizării tehnologiei bazelor de date cu obiecte. A dezvoltat un model de obiecte (ODMG 2.0 a fost adoptat în septembrie 1997) care definește un model standard pentru semantica obiectelor bazei de date. Acest model este important deoarece definește semantica încorporată pe care un SGBD orientat pe obiecte (OODBMS) o înțelege și o poate implementa. Structura bibliotecilor și aplicațiilor care utilizează această semantică trebuie să fie portabilă între diferitele OODBMS care acceptă modelul de date obiect dat. Principalele componente ale arhitecturii ODMG sunt: ​​Object Model (OM), Object Definition Language (ODL), Object Query Language (OQL) și capacitatea de a se conecta la C++, Java și Smalltalk.

Modelul de date obiect în conformitate cu standardul ODMG 2.0 este caracterizat de următoarele proprietăți:

Elementele de bază sunt obiectele și literalele. Fiecare obiect are un identificator unic. Un literal nu are propriul său identificator și nu poate exista separat ca obiect. Literalele sunt întotdeauna încorporate în obiecte și nu pot fi referite individual;

Obiectele și literalele diferă în funcție de tip. Fiecare tip are propriul său domeniu, partajat de toate obiectele și literalele acelui tip. Tipurile pot avea și un comportament. Dacă un tip are un anumit comportament, atunci toate obiectele de acel tip au același comportament. În practică, tipul poate fi clasa din care este creat obiectul, o interfață sau un tip de date simplu (cum ar fi un număr întreg). Un obiect poate fi gândit ca o instanță a unui tip;

Starea unui obiect este definită de un set de valori curente implementat de un set de proprietăți. Aceste proprietăți pot fi atribute ale unui obiect sau relații între un obiect și unul sau mai multe alte obiecte;

Comportamentul unui obiect este definit de un set de operații care pot fi efectuate asupra obiectului sau asupra obiectului însuși. Operațiile pot avea o listă de parametri de intrare și de ieșire, fiecare având un tip strict definit. Fiecare operație poate returna, de asemenea, un rezultat tastat;

Definiția bazei de date este stocată într-o schemă scrisă în Object Definition Language (ODL). Baza de date stochează obiecte, permițându-le să fie partajate între diferiți utilizatori și aplicații.

SGBD-urile bazate pe OODM sunt numite SGBD-uri orientate pe obiecte (OODBMS). Aceste SGBD sunt denumite SGBD de a treia generație* (* Istoria dezvoltării modelelor de stocare a datelor este adesea împărțită în trei etape (generații): prima generație (sfârșitul anilor 1960 - începutul anilor 70) - modele ierarhice și de rețea; a doua generație (aproximativ 1970-1980) - model relațional; a treia generație (anii 1980 - începutul anilor 2000) - modele orientate pe obiecte.).

Astăzi, bazele de date orientate pe obiecte sunt folosite în diverse organizații pentru a rezolva o gamă largă de probleme. Analiza și generalizarea experienței acumulate în domeniul datelor din tehnologia informației a făcut posibilă identificarea aplicațiilor în care se justifică utilizarea bazelor de date orientate pe obiecte:

O aplicație constă dintr-un număr mare de părți care interacționează. Fiecare dintre ei are propriul său comportament, care depinde de comportamentul celorlalți;

Sistemul trebuie să proceseze cantități mari de structuri de date nestructurate sau complexe;

Aplicația va avea acces previzibil la date, astfel încât natura navigațională a bazelor de date orientate pe obiecte nu va reprezenta un dezavantaj semnificativ;

Nevoia de cereri neplanificate este limitată;

Structura datelor stocate este de natură ierarhică sau similară.

În prezent, pe piața de software există multe SGBD-uri orientate pe obiect. În tabel. 10.6 prezintă unele dintre sistemele comerciale din această clasă.

Tabelul 10.6

OODBMS comercial modern,

companiile lor producătoare și domeniile de aplicare

Una dintre diferențele fundamentale dintre bazele de date obiect și relaționale este capacitatea de a crea și utiliza noi tipuri de date. O caracteristică importantă a OODBMS este că crearea unui nou tip nu necesită modificarea nucleului bazei de date și se bazează pe principiile programării orientate pe obiecte.

Nucleul OODBMS este optimizat pentru operațiuni cu obiecte. Operațiunile sale naturale sunt stocarea în cache a obiectelor, versiunea obiectelor, partajarea drepturilor de acces la anumite obiecte. OODBMS se caracterizează prin performanțe mai mari la operațiunile care necesită acces și regăsire a datelor împachetate în obiecte, în comparație cu SGBD-urile relaționale, pentru care nevoia de a prelua date aferente duce la operațiuni interne suplimentare.

De o importanță considerabilă pentru OODBMS este capacitatea de a muta obiecte dintr-o bază de date în alta.

Când creați diverse aplicații bazate pe OODBMS, structura de clasă încorporată a unui anumit SGBD este importantă. Biblioteca de clase, de regulă, acceptă nu numai toate tipurile de date standard, ci și un set extins de multimedia și alte tipuri de date complexe, cum ar fi video, sunet, secvență de cadre de animație. În unele OODBMS, au fost create biblioteci de clase care permit stocarea și căutarea în text integral a informațiilor documentare (de exemplu, Jasmine, ODB-Jupiter). Un exemplu de structura de bază a clasei este prezentat în fig. 10.17.

Poziția principală în aceasta este ocupată de clasa TOdbObject, care conține toate proprietățile și metodele necesare pentru controlul accesului la baza de date și efectuarea indexării. Toate celelalte clase suprascrie metodele sale, adăugând validarea tipului pe care îl implementează și un indexator specific.

După cum se poate observa din fig. 10.17, în structură există diverse clase axate pe prelucrarea informațiilor documentare - TOdbText, TOdbDocument, TODBTextDocument etc. Fiecare document este reprezentat de un obiect separat. Astfel, se asigură naturalețea depozitării documentelor. Una dintre cele mai importante operațiuni este căutarea documentelor la cerere. Pentru majoritatea claselor, este implementată abilitatea de a căuta obiecte după valoarea unei chei specifice. Pentru clasa TOdbText, este implementată capacitatea de a genera o interogare de căutare bazată pe o expresie scrisă în limbaj natural.

Clasa TOdbDocument este specială, capabilă să conţină obiecte de diferite tipuri. Este format din câmpuri, fiecare dintre ele având un nume și este asociat cu un obiect de un anumit tip. Prezența acestei clase oferă utilizatorului posibilitatea de a extinde setul de tipuri. Prin modificarea obiectului container (document), puteți seta un anumit set de câmpuri și puteți obține un nou tip de document.

Pe baza ODB-Jupiter, dezvoltatorii OODBMS au creat un sistem complet de recuperare a informațiilor ODB-Text, care are o structură universală de date stocate și un mecanism de căutare puternic. Sistemul ODB-Text este un instrument pentru prelucrarea colectivă a documentelor și menținerea unei arhive corporative. Printre aplicațiile posibile, vom numi automatizarea contabilității pentru fluxul de documente al unui birou modern, construcția de sisteme de referință și informații (asemănătoare cu cunoscutele baze de date juridice), întreținerea bazelor de date din rețea, evidența personalului, bibliografie, etc.

41. Caracteristici de proiectare ale IS aplicate. Fazele dezvoltării SI. (Tema 11, pp. 100-103).

11.1.3. Caracteristicile proiectării sistemului de CI aplicate

Când construiți (selectați, adaptați) un sistem informațional, puteți utiliza două concepte de bază, două abordări principale (al treilea concept este o combinație a acestora):

1. Orientarea către problemele care trebuie rezolvate cu ajutorul acestui sistem informaţional, i.e. abordare orientată pe probleme (sau abordare inductivă);

2. concentrarea asupra tehnologiei care este disponibilă (actualizată) într-un anumit sistem, mediu, de ex. abordare orientată către tehnologie (sau abordare deductivă).

Alegerea conceptului depinde de criterii strategice (tactice) și (sau) pe termen lung (pe termen scurt), probleme, resurse.

Dacă mai întâi se studiază capacitățile tehnologiei existente și apoi se determină problemele reale care pot fi rezolvate cu ajutorul lor, atunci este necesar să se bazeze pe o abordare orientată spre tehnologie.

Dacă problemele reale sunt identificate mai întâi, iar apoi este introdusă tehnologia suficientă pentru a rezolva aceste probleme, atunci este necesar să ne bazăm pe o abordare bazată pe probleme.

În același timp, ambele concepte de construire a unui sistem informațional depind una de alta: introducerea de noi tehnologii modifică problemele care se rezolvă, iar schimbarea problemelor care se rezolvă duce la necesitatea introducerii de noi tehnologii; Ambele influențează deciziile care sunt luate.

Proiectarea (dezvoltarea) sistemului și utilizarea oricărui sistem informatic aplicat (corporativ) trebuie să treacă prin următorul ciclu de viață al sistemului informațional:

- analiza pre-proiect (experienta in crearea altor sisteme similare, prototipuri, diferente si caracteristici ale sistemului in curs de dezvoltare etc.), analiza manifestarilor externe ale sistemului;

– analiza intrasistem, analiza internă (analiza subsistemelor de sistem);

- descrierea (reprezentarea) sistem (morfologică) a sistemului (descrierea scopului sistemului, relațiile și conexiunile sistemului cu mediul, alte sisteme și resurse ale sistemului - materiale, energetice, informaționale, organizaționale, umane, spațiale și temporale);

– determinarea criteriilor de adecvare, eficiență și durabilitate (fiabilitate);

– descrierea funcțională a subsistemelor sistemului (descrierea modelelor, algoritmi de funcționare a subsistemelor);

- prototiparea (descrierea fictică) a sistemului, evaluarea interacțiunii subsistemelor sistemului (dezvoltarea unui model - implementarea subsistemelor cu descrieri funcționale simplificate, proceduri și testarea interacțiunii acestor modele pentru a satisface obiectivul sistemului ), în timp ce este posibil să se utilizeze „modele” de criterii de adecvare, stabilitate, eficiență;

- „asamblarea” și testarea sistemului - implementarea subsistemelor și criteriilor funcționale cu drepturi depline, evaluarea modelului conform criteriilor formulate;

- sistem de operare;

– determinarea obiectivelor pentru dezvoltarea ulterioară a sistemului și a aplicațiilor acestuia;

- întreținerea sistemului - clarificarea, modificarea, extinderea capacităților sistemului în modul de funcționare a acestuia (în scopul evoluției acestuia).

Aceste etape sunt principalele pentru reinginerirea sistemelor informatice.

Dezvoltarea unui sistem informațional corporativ, de regulă, se realizează pentru o întreprindere bine definită. Caracteristicile obiectului de activitate al întreprinderii, desigur, vor afecta structura sistemului informațional. Dar, în același timp, structurile diferitelor întreprinderi sunt în general similare între ele. Fiecare organizație, indiferent de tipul activității sale, este formată dintr-un număr de divizii care desfășoară direct unul sau altul tip de activitate a companiei. Și această situație este valabilă pentru aproape toate organizațiile, indiferent de tipul de activitate în care sunt angajate.

Astfel, orice organizație poate fi considerată ca un ansamblu de elemente (subdiviziuni) care interacționează, fiecare dintre ele putând avea o structură proprie, destul de complexă. Relațiile dintre departamente sunt, de asemenea, destul de complexe. În cazul general, există trei tipuri de legături între unitățile de afaceri:

Legături funcționale - fiecare divizie realizează anumite tipuri de muncă în cadrul unui singur proces de afaceri;

Comunicații informaționale - unitățile fac schimb de informații (documente, faxuri, comenzi scrise și orale etc.);

Comunicații externe - unele unități interacționează cu sistemele externe, iar interacțiunea lor poate fi, de asemenea, atât informațională, cât și funcțională.

Caracterul comun al structurii diferitelor întreprinderi ne permite să formulăm câteva principii comune pentru construirea sistemelor informaționale corporative.

În general, procesul de dezvoltare a unui sistem informațional poate fi considerat din două puncte de vedere:

După timp sau pe etape ale ciclului de viață al sistemului în curs de dezvoltare. În acest caz, avem în vedere organizarea dinamică a procesului de dezvoltare, descrisă în termeni de cicluri, etape, iterații și etape.

Sistemul informatic al întreprinderii este dezvoltat ca proiect. Multe caracteristici ale fazelor de management al proiectelor și de dezvoltare a proiectului (fazele ciclului de viață) sunt comune și nu depind nu numai de domeniul subiectului, ci și de natura proiectului (nu contează dacă este un proiect de inginerie sau unul economic). ). Prin urmare, este logic să luăm în considerare mai întâi o serie de probleme generale de management de proiect.

Un proiect este o schimbare limitată în timp, intenționată, într-un sistem separat, cu obiective inițial clar definite, a căror realizare determină finalizarea proiectului, precum și cu cerințele stabilite pentru termeni, rezultate, risc, cheltuieli de fonduri și resurse, și structura organizatorică.

De obicei, pentru un concept complex (care, în special, este conceptul de proiect), este dificil să se ofere o formulare lipsită de ambiguitate care să acopere pe deplin toate trăsăturile conceptului introdus. Prin urmare, definiția de mai sus nu pretinde a fi unică și completă.

Se pot distinge următoarele caracteristici distinctive principale ale proiectului ca obiect de management:

Variabilitate - transfer intenționat al sistemului de la existent la unele

starea dorită, descrisă din punct de vedere al obiectivelor proiectului;

Limitarea scopului final;

durată limitată;

Buget limitat;

Resurse limitate necesare;

Noutate pentru intreprinderea pentru care se implementeaza proiectul;

Complexitate - prezența unui număr mare de factori care afectează direct sau indirect progresul și rezultatele proiectului;

Suport juridic și organizatoric - crearea unei structuri organizatorice specifice pe durata proiectului.

Eficiența muncii se realizează prin managementul procesului de implementare a proiectului, care asigură alocarea resurselor, coordonarea secvenței de lucru în curs de desfășurare și compensarea perturbărilor interne și externe.

Din punctul de vedere al teoriei sistemelor de control, proiectul ca obiect de control trebuie să fie observabil și gestionabil, adică se disting unele caracteristici prin care este posibilă monitorizarea constantă a progresului proiectului (proprietatea de observabilitate). În plus, este nevoie de mecanisme de impact în timp util asupra cursului implementării proiectului (proprietatea controlabilității).

Proprietatea de controlabilitate este deosebit de relevantă în condițiile de incertitudine și variabilitate a domeniului de studiu, care însoțesc adesea proiectele de dezvoltare a sistemelor informaționale.

Fiecare proiect, indiferent de complexitatea și cantitatea de muncă necesară implementării lui, parcurge anumite etape în dezvoltarea sa: de la starea când „încă nu există proiect” până la starea când „proiectul nu mai există”. Setul de etape de dezvoltare de la apariția unei idei până la finalizarea completă a proiectului este de obicei împărțit în faze (etape, etape).

Există unele diferențe în determinarea numărului de faze și a conținutului acestora, deoarece aceste caracteristici depind în mare măsură de condițiile de implementare a unui anumit proiect și de experiența principalilor participanți. Cu toate acestea, logica și conținutul principal al procesului de dezvoltare a unui sistem informațional în aproape toate cazurile sunt comune.

Se pot distinge următoarele faze ale dezvoltării sistemului informațional:

Formarea conceptului;

Elaborarea specificațiilor tehnice;

Proiecta;

De fabricație;

Punerea în funcțiune a sistemului.

Să luăm în considerare fiecare dintre ele mai detaliat. Faza a doua și parțial a treia sunt de obicei numite faze de proiectare a sistemului, iar ultimele două (uneori includ faza de proiectare) sunt fazele de implementare.

Faza de concept

Formarea ideilor, stabilirea obiectivelor;

Formarea echipei cheie de proiect;

Studierea motivației și cerințelor clientului și a altor participanți;

Colectarea datelor inițiale și analiza stării existente;

Definirea cerințelor și restricțiilor de bază, a resurselor materiale, financiare și de muncă necesare;

Evaluarea comparativă a alternativelor;

Depunerea propunerilor, examinarea și aprobarea acestora.

Elaborarea unei propuneri tehnice

Dezvoltarea conținutului principal al proiectului, a structurii de bază a proiectului;

Elaborarea și aprobarea termenilor de referință;

Planificarea, descompunerea modelului structural de bază al proiectului;

Intocmirea devizelor si bugetelor pentru proiect, determinarea necesarului de resurse;

Elaborarea planurilor calendaristice și a programelor de lucru extinse;

Incheierea unui contract cu clientul;

Punerea în funcțiune a mijloacelor de comunicare a participanților la proiect și controlul derulării lucrărilor.

Proiecta

În această fază se determină subsistemele și interconexiunile acestora, se selectează cele mai eficiente modalități de implementare a proiectului și de utilizare a resurselor. Lucrări caracteristice acestei faze:

Implementarea lucrărilor de proiectare de bază;

Elaborarea specificațiilor tehnice private;

Implementarea designului conceptual;

Întocmirea specificațiilor și instrucțiunilor tehnice;

Prezentarea dezvoltării, examinării și aprobării designului.

Dezvoltare

În această fază se realizează coordonarea și controlul operațional al lucrărilor la proiect, se fabrică, se combină și se testează subsistemele. Conținut principal:

Efectuarea de lucrări de dezvoltare software;

Efectuarea pregătirilor pentru implementarea sistemului;

Controlul si reglementarea principalilor indicatori ai proiectului.

Punerea în funcțiune a sistemului

În această fază se efectuează teste, funcționarea de probă a sistemului în condiții reale, se poartă negocieri asupra rezultatelor proiectului și asupra eventualelor noi contracte. Principalele tipuri de muncă:

Teste complexe;

42. Conceptul de ciclu de viață al PI. (Tema 11, pp. 103-105).

Post-relaționalmodel

Modelul relațional clasic presupune indivizibilitatea datelor stocate în câmpurile înregistrărilor tabelului. Modelul post-relațional este un model relațional extins care înlătură restricția indivizibilității datelor. Modelul permite câmpuri cu mai multe valori - câmpuri ale căror valori constau din subvalori. Un set de valori pentru câmpurile cu mai multe valori este considerat a fi un tabel autonom încorporat în tabelul principal.

Pe fig. 2.6, folosind exemplul de informații despre facturi și mărfuri pentru comparație, este prezentată prezentarea acelorași date folosind modele relaționale (a) și postrelaționale (b). Din figură se poate observa că, în comparație cu modelul relațional, modelul post-relațional stochează datele mai eficient, iar în timpul procesării nu va fi necesară efectuarea unei operații de îmbinare a datelor din două tabele.

Facturi

N factură	Client		N factură		Cantitate

deasupra capului

N factură	Client		Cantitate

Orez. 2.6. Structuri de date ale modelelor relaționale și postrelaționale

Întrucât modelul post-relațional permite stocarea datelor nenormalizate în tabele, se pune problema asigurării integrității și consistenței datelor. Această problemă este rezolvată prin includerea mecanismelor adecvate în SGBD.

Demnitate Modelul post-relațional este capacitatea de a reprezenta un set de tabele relaționale înrudite printr-un tabel post-relațional. Aceasta oferă o vizibilitate ridicată a prezentării informațiilor și o creștere a eficienței prelucrării acesteia.

dezavantaj Modelul post-relațional este complexitatea rezolvării problemei asigurării integrității și consistenței datelor stocate.

Modelul de date post-relațional considerat este susținut de DBMS uniVers. Alte SGBD-uri bazate pe modelul de date post-relațional includ și sistemele Bubba și Dasdb.

Model multidimensional

Abordarea multidimensională a reprezentării datelor a apărut aproape simultan cu abordarea relațională, dar interesul pentru SGBD-urile multidimensionale a început să se răspândească de la mijlocul anilor 1990. Impulsul a fost în 1993 un articol de E. Codd. A formulat 12 cerințe de bază pentru sistemele OLAP (OnLine Analytical Processing), dintre care cele mai importante sunt legate de capacitățile de reprezentare conceptuală și procesare a datelor multidimensionale.

În dezvoltarea conceptelor sistemelor informaționale se pot distinge următoarele două direcții:

Sisteme operaționale (tranzacționale) de procesare;

Sisteme de procesare analitică (sisteme de sprijin pentru decizii).

SGBD-urile relaționale au fost destinate sistemelor informaționale de prelucrare operațională a informațiilor și sunt foarte eficiente în acest domeniu. În sistemele de procesare analitică, acestea s-au dovedit a fi oarecum stângace și insuficient de flexibile. SGBD-urile multidimensionale sunt mai eficiente aici.

SGBD-uri multidimensionale sunt SGBD-uri înalt specializate concepute pentru procesarea analitică interactivă a informațiilor. Principalele concepte utilizate în aceste SGBD sunt agregabilitatea, istoricitatea și predictibilitatea.

Agregabilitate date înseamnă luarea în considerare a informaţiei la diferite niveluri de generalizare a acesteia. În sistemele informaționale, gradul de detaliere în prezentarea informațiilor pentru utilizator depinde de nivelul acestuia: analist, utilizator, manager, manager.

Istoricitate datele presupune asigurarea unui nivel ridicat de natură statică a datelor în sine și a relațiilor acestora, precum și legarea obligatorie a datelor în timp.

Previzibilitate prelucrarea datelor presupune setarea funcţiilor de predicţie şi aplicarea acestora la diferite intervale de timp.

Multidimensionalitatea modelului de date nu înseamnă multidimensionalitatea vizualizării datelor digitale, ci reprezentarea logică multidimensională a structurii informaționale în descriere și în operațiunile de manipulare a datelor.

Față de modelul relațional, organizarea multidimensională a datelor are o vizibilitate și un conținut informațional mai ridicat. Pentru ilustrare în fig. Figura 2.7 prezintă reprezentări relaționale (a) și multidimensionale (b) ale acelorași date privind volumele vânzărilor de mașini.

Concepte de bază ale modelelor de date multidimensionale: dimensiune și celulă.

Măsurare este un set de date de același tip care formează una dintre fețele hipercubului. Într-un model multidimensional, dimensiunile joacă rolul de indici care servesc la identificarea unor valori specifice în celulele hipercubului.

Celulă este un câmp a cărui valoare este determinată în mod unic de un set fix de măsurători. Tipul de câmp este cel mai adesea definit ca numeric. În funcție de modul în care sunt formate valorile unei anumite celule, aceasta poate fi o variabilă (valorile se schimbă și pot fi încărcate dintr-o sursă de date externă sau generate programatic) sau o formulă (se calculează valorile, cum ar fi celulele cu formule ale foii de calcul). conform formulelor predefinite).

Orez. 2.7. Reprezentarea datelor relaționale și multidimensionale

În exemplul din fig. 2,7 b valoarea fiecărei celule Volumul vânzărilor determinată unic de combinarea dimensiunii timp Luna vânzărilorși modele de mașini. În practică, sunt adesea necesare mai multe măsurători. Un exemplu de model de date tridimensional este prezentat în fig. 2.8.

Orez. 2.8. Exemplu de model 3D

SGBD-urile multidimensionale existente folosesc două scheme principale de organizare a datelor: hipercubic și policubic.

V policubică Schema presupune că mai multe hipercuburi cu dimensiuni diferite și cu dimensiuni diferite pot fi definite în baza de date ca fețe. Un exemplu de sistem care acceptă o variantă policubică a unei baze de date este Oracle Express Server.

Când hipercubic Schema presupune că toate celulele sunt definite de același set de măsurători. Aceasta înseamnă că dacă există mai multe hipercuburi în baza de date, toate au aceeași dimensiune și aceleași dimensiuni.

Principal demnitate modelul de date multidimensional este confortul și eficiența prelucrării analitice a unor cantități mari de date legate de timp.

dezavantaj modelul de date multidimensional este greoiul său pentru cele mai simple sarcini de prelucrare convențională a informațiilor online.

Exemple de sisteme care acceptă modele de date multidimensionale sunt Essbase, Media Multi-matrix, Oracle Express Server, Cache. Există produse software, precum Media/MR, care vă permit să lucrați simultan cu baze de date multidimensionale și relaționale.

Model orientat pe obiecte

Într-un model orientat pe obiecte, la prezentarea datelor, este posibilă identificarea înregistrărilor individuale ale bazei de date. Relațiile sunt stabilite între înregistrări și funcțiile lor de procesare folosind mecanisme similare cu facilitățile corespunzătoare din limbajele de programare orientate pe obiecte.

Un model standardizat orientat pe obiecte este descris în recomandările standardului ODMG-93 (Object Database Management Group - an object-oriented database management group).

Luați în considerare un model simplificat al unei baze de date orientate pe obiecte. Structura unei baze de date orientate pe obiecte este reprezentată grafic ca un arbore, ale cărui noduri sunt obiecte. Proprietățile obiectelor sunt descrise de un tip standard sau construit de utilizator (definit ca o clasă). Valoarea unei proprietăți de tip clasă este un obiect care este o instanță a clasei corespunzătoare. Fiecare obiect de instanță de clasă este considerat un copil al obiectului în care este definit ca proprietate. Un obiect de instanță al unei clase aparține clasei sale și are un părinte. Relațiile generice din baza de date formează o ierarhie conectată de obiecte. Un exemplu de structură logică a unei baze de date de biblioteconomie orientată pe obiecte este prezentat în fig. 2.9. Aici un obiect de tip Bibliotecă este părintele obiectelor de instanță de clasă Abonat, Catalogși extrădare. Obiecte de diferite tipuri Cărțiși poate avea aceiași părinți sau diferiți. Obiecte de tip Carte, care au același părinte, trebuie să difere cu cel puțin un număr de acces (unic pentru fiecare instanță de carte), dar să aibă aceleași valori de proprietate este B n udk, nume e și autor.

Structura logică a unei baze de date orientate pe obiecte este similară în exterior cu structura unei baze de date ierarhice. Principala diferență dintre ele este în metodele de manipulare a datelor.

Pentru a efectua acțiuni asupra datelor din modelul de bază de date considerat, sunt utilizate operații logice, îmbunătățite de mecanisme orientate pe obiect de încapsulare, moștenire și polimorfism.

Încapsulare limitează domeniul de aplicare al unui nume de proprietate la obiectul în care este definit. Deci, dacă într-un obiect de tip Catalog adăugați o proprietate care specifică numărul de telefon al autorului cărții și are un titlu telefon, atunci vom obține proprietățile cu același nume pentru obiecte Abonatși Catalog. Semnificația unei astfel de proprietăți va fi determinată de obiectul în care este încapsulată.

Moştenire, dimpotrivă, extinde sfera proprietății la toți descendenții obiectului. Astfel, pentru toate obiectele de tip Carte, care sunt descendenți ai unui obiect de tip Catalog, puteți atribui proprietățile obiectului părinte: isbn, udk, titluși autor. Dacă este necesară extinderea acțiunii mecanismului de moștenire la obiecte care nu sunt rude imediate (de exemplu, între doi descendenți ai aceluiași părinte), atunci o proprietate abstractă de tip abs. Astfel, definirea proprietăților abstracte biletși camerăîn obiect Bibliotecă face ca aceste proprietăți să fie moștenite de toate obiectele copil Abonat, Carteși Probleme A. Nu întâmplător, prin urmare, valorile proprietății bilet clase Abonatși extrădare prezentată în fig. 2.9 sunt aceleași - 00015.

Polimorfismulîn limbaje de programare orientate pe obiecte înseamnă capacitatea aceluiași cod de program de a lucra cu date eterogene. Cu alte cuvinte, înseamnă că obiectele de diferite tipuri pot avea metode (proceduri sau funcții) cu aceleași nume. În timpul execuției unui program obiect, aceleași metode operează pe obiecte diferite în funcție de tipul argumentului. În raport cu exemplul luat în considerare, polimorfismul înseamnă că obiectele unei clase Carte având părinți diferiți de clasă Catalog, poate avea un set diferit de proprietăți. Prin urmare, programe pentru lucrul cu obiecte de clasă Carte poate conține cod polimorf.

Căutarea într-o bază de date orientată obiect constă în aflarea asemănărilor dintre obiectul specificat de utilizator și obiectele stocate în baza de date.

Orez. 2.9. Structura logică a bazei de date a biblioteconomiei

Principal demnitate Modelul de date orientat pe obiecte în comparație cu cel relațional este capacitatea de a afișa informații despre relațiile complexe ale obiectelor. Modelul de date orientat pe obiecte vă permite să identificați o singură înregistrare a bazei de date și să definiți funcțiile pentru procesarea acestora.

dezavantaje modelul orientat pe obiecte sunt complexitatea conceptuală mare, inconvenientul procesării datelor și viteza scăzută de execuție a interogărilor.

SGBD-urile orientate pe obiecte includ POET, Jasmine, Versant, O2, ODB-Jupiter, Iris, Orion, Postgres.