Model orientat pe obiecte. Modelul de date orientat pe obiecte

Noțiuni de bază

Definiție 1.

Model orientat pe obiecteprezentările de date fac posibilă identificarea intrărilor individuale de baze de date.

Înregistrările bazei de date și funcțiile de procesare sunt legate de mecanisme similare cu mijloacele adecvate care sunt implementate în limbi de programare orientate pe obiecte.

Definiția 2.

Reprezentare grafică Structurile unei baze de date orientate pe obiecte sunt un copac al cărui noduri reprezintă obiecte.

Tip standard (de exemplu, șir - Şir) sau tipul creat de utilizator ( clasă), descrie proprietățile obiectelor.

În figura 1, obiectul bibliotecii este un părinte pentru directorul obiectelor de clasă, abonatul și emiterea. Diferitele obiecte, cum ar fi o carte, pot fi unul sau diferiți părinți. În obiecte cum ar fi o carte care are același părinte, trebuie să existe cel puțin numere de inventar diferite (unice pentru fiecare copie a cărții), dar aceleași valori Proprietăți autor, nume, uDC. și iSBN..

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

Atunci când efectuați acțiuni pe date într-un model orientat pe obiect, se utilizează operații logice, care sunt îmbunătățite prin încapsulare, moștenire și polimorfism. Cu o anumită restricție, puteți aplica operațiuni care sunt similare cu comenzile SQL (de exemplu, atunci când creați o bază de date).

Când se creează și modifică baza de date, sunt efectuate formarea automată și reglarea ulterioară a indexurilor (tabele index), care conțin informații pentru căutarea rapidă a datelor.

Definiția 3.

scop încapsulare - restricționarea domeniului de aplicare al denumirii imobiliare a limitelor obiectului în care este definit.

De exemplu, dacă proprietatea este adăugată la obiect, care stabilește telefonul autorului și are un nume telefonProprietățile aceluiași nume vor avea obiectele catalogului și abonatului. Semnificația proprietății este determinată de obiectul în care este încapsulat.

Definiție 4.

Moştenire, Încapsularea din spate, este responsabilă de distribuirea domeniului de vizibilitate a proprietății în raport cu toți descendenții obiectului.

De exemplu, toate obiectele, care sunt descendenții directorului obiect, pot fi atribuite proprietăților obiectului părinte: autor, nume, uDC. și iSBN..

Dacă este necesar să se extindă acțiunea mecanismului de moștenire a obiectelor care nu sunt rude directe (de exemplu, doi descendenți ai unui părinte) în strămoșul lor global determină proprietatea abstractă a tipului abs..

Astfel, proprietăți număr și bilet În obiectul bibliotecii sunt moștenite de toate filialele emiterea, cartea și abonatul. Acesta este motivul pentru care valorile acestei proprietăți ale abonatului de clase și emiterea sunt aceleași - 00015 (Figura 1).

Definiție 5.

Polimorfism Permite aceluiași cod de program să funcționeze cu date multiplă.

Cu alte cuvinte, el admite în obiecte tipuri diferite Au metode (funcții sau proceduri) cu aceleași nume.

Căutare Baza de date orientată pe obiect este de a determina similitudinea dintre obiect pe care utilizatorul le specifică și obiectele stocate în baza de date.

Avantaje și dezavantaje ale unui model orientat pe obiect

De bază avantaj Un model de date orientat pe obiecte, spre deosebire de modelul relațional, este posibilitatea de a afișa informații despre relațiile complexe ale obiectelor. Modelul de date în cauză vă permite să determinați intrarea separată a bazei de date și funcțiile procesării acestuia.

LA dezavantaje Un model orientat obiect aparține dificultății conceptuale ridicate, prelucrării de date incomode și interogări mici.

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

• Postgres,
• Orion.
• Iris
• Odbjupiter,
• Versant
• Obiectivitate / db,
• ObjectStore.
• Statice.
• Piatră preţioasă
• G bază.

Baza de date orientată pe obiecte (OBS) - o bază de date în care datele sunt modelate sub formă de obiecte, atributele, metodele și clasele acestora.

Bazele de date orientate pe obiecte sunt de obicei recomandate pentru cazurile în care este necesară o prelucrare a datelor de înaltă performanță cu o structură complexă.

În Manifest, OBS oferă caracteristici obligatorii la care orice Obd trebuie să fie responsabil. Alegerea lor se bazează pe 2 criterii: Sistemul trebuie orientat pe obiecte și reprezintă o bază de date.

Caracteristici obligatorii

1. Suport pentru obiecte complexe. Sistemul ar trebui să asigure posibilitatea de a crea obiecte compozite prin aplicarea obiectelor de designer. Este necesar ca designerii de obiecte să fie ortogonali, adică orice designer ar putea fi aplicat oricărui obiect.

2. Suport pentru obiectele individuale. Toate obiectele trebuie să aibă un identificator unic care nu depinde de valorile atributelor lor.

3. Suport pentru încapsulare. Încapsularea corectă se realizează datorită faptului că programatorii au dreptul de a accesa numai metodele metodelor, iar datele și implementarea metodelor sunt ascunse în interiorul obiectelor.

4. Tipuri de sprijin și clase. Este necesar ca cel puțin o diferență de concept între tipuri și clase să fie menținută în OBD. (Termenul "tip" corespunde conceptului de tip de date abstract. În limbile de programare, variabila este declarată cu tipul său. Compilatorul poate folosi aceste informații pentru a verifica operațiile efectuate de compatibilitatea variabilă cu tipul său, ceea ce vă permite pentru a garanta corectitudinea software.. Pe de altă parte, clasa este un tip de șablon pentru crearea obiectelor și oferă metode care pot fi aplicate acestor obiecte. Astfel, conceptul de "clasă" într-o măsură mai mare se referă la momentul executării decât de timpul de compilare.)

5. Sprijin pentru moștenirea tipurilor și claselor de la strămoșii lor. Subtipul sau subclasa, trebuie să moștenească atributele și metodele de la supertype sau, respectiv, supraclass.

6. Supraîncărcarea în combinație cu legarea completă. Metodele trebuie aplicate obiectelor de diferite tipuri. Implementarea metodei ar trebui să depindă de tipul de obiecte la care se aplică această metodă. Pentru a asigura această funcționalitate, legarea metodelor de metode din sistem nu trebuie efectuată până la timpul de execuție a programului.

7. plenitudinea computațională. Limba de manipulare a datelor trebuie să fie limba de programare scop general.

8. Un set de tipuri de date trebuie să fie extensibil. Utilizatorul trebuie să aibă mijloace de a crea noi tipuri de date bazate pe un set de tipuri de sisteme predefinite. În plus, nu ar trebui să existe diferențe între metodele de utilizare a tipurilor de date ale sistemului și a utilizatorilor.

OO DBMS.

Obiecte orientate pe bază de date - Baze de date în care informațiile sunt prezentate ca obiecte ca în limbile de programare orientate pe obiecte.

Aplicați sau nu pentru a aplica sisteme de gestionare a bazelor de date orientate pe obiecte (Oosubd) în proiecte reale astăzi? În ce cazuri să le aplice și în ce nu?

Aici avantaje Utilizarea usubd:

· Nu există nicio problemă a inconsecvenței modelului de date în aplicație și BD (nepotrivire a impedanței). Toate datele sunt stocate în baza de date în aceeași formă ca și în modelul de aplicare.

· Nu este necesar să suportați separat modelul de date de partea DBMS.

· Toate obiectele de la nivelul sursei de date sunt scrise strict. Nu mai există nume de coloane! Baza de date orientată spre obiecte refactoring și codul care funcționează cu acesta este acum automatizat și nu un proces monoton și plictisitor.

Standard ODMG.

Primul manifestatformal, a fost doar un articol prezentat Conferința privind bazele de date orientate pe obiecte și deductivegrup de indivizi. După cum ați putea vedea în subsecțiunea anterioară, cerințele manifestului au fost destul de emoționale decât cele specificate clar. În 1991, consorțiul ODMG a fost format (atunci această abreviere a fost dezvăluită ca Grupul de gestionare a bazei de datedar a dobândit ulterior o interpretare mai largă - Obiect Grupul de gestionare a datelor). Consorțiul ODMG este strâns legat de un consorțiu mult mai numeric OMG ( Grupul de gestionare a obiectelor.), care a fost formată cu doi ani mai devreme. Scopul principal al ODMG a fost dezvoltarea unui standard industrial al bazelor de date orientate pe obiecte (model general). Ca bază a fost adoptată de modelul de bază al obiectului OMG COM ( Modul de bază al obiectului). Pentru mai mult de un deceniu de existență ODMG a publicat trei versiuni de bază Standard, ultimul dintre acestea se numește ODMG 3.0. şaisprezece

Este amuzant că, deși Odmg (conform autorului) a ieșit din OMG, în ultimii ani unele standarde OMG se bazează pe modelul Object ODMG. În special, specificația limbii OCL se bazează pe modelul ODMG ( Limba de constrângere a obiectelor.), care face parte din specificația globală a limbii UML 1.4 (și UML 2.0). În acest articol, nu punem obiectivul de a realiza o comparație detaliată a abordărilor OMG și ODMG și de a trimite cititori interesați Enciclopedia Kogalovsky. și materialele acestor situri de consorții. Suntem limitați la o scurtă prezentare a principalelor idei conținute în standardul ODMG -3.

Arhitectura Odmg.

Arhitectura ODMG propusă este prezentată în fig. 2.1. Această arhitectură definește metoda de stocare a datelor și diferite tipuri de acces utilizator la acest "depozit de date" 17. Un depozit de date unic este disponibil din limba de definiție a datelor, limbă de interogare și o serie de limbi de manipulare a datelor. 18 din fig. 2.1 înseamnă ODL Limba de definiție a obiectului (Limba de definiție a obiectului), OQL - Limba de interogare a obiectelor (limba de interogare a limbii)și OML - Limba de manipulare a obiectului (limba de manipulare a obiectului).

Smochin. 2.1. Arhitectura Odmg.

Central în arhitectură este model de datereprezentând structura organizatorică în care toate datele gestionate de Oosubd rămân. Limba de definiție a obiectului, limba de interogare și limbile de manipulare sunt concepute astfel încât toate capacitățile lor să se bazeze pe modelul de date. Arhitectura face ca existența unei varietăți de structuri de implementare să stocheze date simulate, dar o cerință importantă este ca toate bibliotecile de software și toate instrumentele de susținere să fie furnizate într-un cadru orientat pe obiect și ar trebui menținute în coordonare cu datele.

Principalele componente ale arhitecturii sunt următoarele.

• Modelul de date al datelor.Toate datele persistente de Oosubd sunt structurate în ceea ce privește modelele modelului de date. În modelul de date, se determină semantica exactă a tuturor conceptelor (vezi mai jos).

• Limba de definiție a datelor (ODL).Circuitele de bază de date sunt descrise în ceea ce privește limba ODL, în care modelele modelului de date sunt specificate sub forma unei limbi de definiție. ODL vă permite să descrieți schema ca un set de interfețe de tip obiect, care include descrierea proprietăților tipurilor și interdependențelor dintre ele, precum și numele operațiunilor și parametrii acestora. ODL nu este un limbaj complet de programare; Tipurile trebuie implementate într-una din limbile categoriei OML. În plus, ODL este virtuallimba, în sensul că standardul ODMG nu necesită implementarea acestuia în produsele software ale Oosubd, care sunt considerate a fi relevante pentru standard. Sprijin pentru aceste produse de limbi de definiție echivalente, inclusiv toate capabilitățile ODL, dar adaptate la caracteristicile specifice ale sistemului. Cu toate acestea, prezența specificațiilor lingvistice ODL în standardul ODMG este importantă deoarece proprietățile modelului de date sunt specificate în limba.

• Limba cererilor de obiecte (ODL). Limba are sintaxă similară cu sintaxa limba SQL.Dar se bazează pe semantica modelului ODMG Object. Standardul permite utilizarea directă a OQL și încorporarea acestuia într-una din limbile categoriei OML.

Modelul de date relațional

Aproape tot sisteme moderne bazat pe relațional(Relațional) modele de gestionare a bazelor de date. Nume relaționalse datorează faptului că fiecare intrare într-o astfel de baze de date conține informații referitoare numai la un anumit obiect.

ÎN relaționalDBMS Toate datele procesate sunt reprezentate ca mese plate. Informațiile despre obiectele unei forme specifice sunt prezentate într-o formă tabelară: diferite atribute ale obiectului sunt concentrate în coloanele de masă, iar șirurile sunt proiectate pentru a include descrieri ale tuturor atributelor cazurilor individuale de obiecte.

Modelul creat în stadiul modelării infografice este în mare parte satisfăcător principiile relaționale. Cu toate acestea, pentru a aduce acest model la relațional trebuie să fie efectuat prin procedura numită normalizare.

Teoria normalizării funcționează cu cinci forme normale. Aceste formulare sunt concepute pentru a reduce redundanța de informare, prin urmare, fiecare formă normală ulterioară trebuie să îndeplinească cerințele din cele anterioare și unele condiții suplimentare. Odată cu proiectarea practică a bazelor de date, formularele a patra și a cincea nu sunt de obicei utilizate. Ne-am limitat la luarea în considerare a primelor patru forme normale.

Introducem conceptele necesare pentru a înțelege procesul de aducere a modelului la schema relațională.

Atitudine- abstractizarea obiectului descris ca o totalitate a proprietăților sale. Realizarea etapei infografice a designului, am vorbit despre abstractizarea obiectelor și le-am atribuit câteva proprietăți. Acum, conducând design conceptual, ne mutăm la următorul nivel de abstractizare. În acest stadiu al obiectelor, ca atare, nu mai există. Operăm cu un set de proprietăți care definesc un obiect.

Instanță a relației- setul de valori ale proprietăților unui anumit obiect.

Cheia principala- identificarea setului de atribute, adică Valoarea acestor atribute este unică în acest sens. Nu există două cazuri ale relației care conțin aceleași valori în cheia primară.

Atribut simplu- atribut, ale cărui sensuri sunt indivizibile.

Atributul complex- Atribut, a cărui valoare este un set de valori ale mai multor proprietăți de obiecte diferite sau mai multe valori ale unei proprietăți.

Conceptul de esență ..

Domeniu

Conceptul de domeniu este mai specific pentru bazele de date, deși are unele analogii cu subtipurile din unele limbi de programare. În forma cea mai generală, domeniul este determinat de sarcina unui anumit tip de date de bază la care elementele domeniului și o expresie logică arbitrară aplicată elementului de tip de date. Dacă calculul acestei expresii logice dă rezultatul "adevărului", elementul de date este un element al domeniului.

Cea mai corectă interpretare intuitivă a conceptului de domeniu este înțelegerea domeniului ca un set potențial permis de valori acest tip. De exemplu, domeniul "nume" din exemplul nostru este definit pe tipul de bază de caractere de caractere, dar numărul de valori poate include numai acele linii care pot descrie numele (în special, astfel de linii nu pot începe cu un moale semn).

De asemenea, trebuie remarcat sarcina semantic a conceptului de domeniu: datele sunt considerate comparabile numai atunci când se referă la un domeniu. În exemplul nostru, domeniile domeniilor "numerele de trecere" și "numărul grupului" se referă la tipul de numere întregi, dar nu sunt comparabile. Rețineți că, în majoritatea DBM-urilor relaționale, conceptul unui domeniu nu este utilizat, deși este deja susținut în Oracle V.7.

Baza tehnologiilor bazei de date bazate pe MD descrise mai sus, se află un concept static de stocare a informațiilor concentrate pe modelarea datelor. Cu toate acestea, noi domenii de aplicare a tehnologiei cu obiecte complexe, interdependente BD, cum ar fi:

Design automatizat;

Producția automată;

Dezvoltare automată software;

Sisteme informatice de birou;

Sistem multimedia;

Sisteme informatice geografice;

Sisteme de publicare și altele, - a demonstrat capacități limitate ale unui concept static în ceea ce privește modelarea obiectelor din lumea reală.

Pentru noile tipuri de aplicații de bază de date complexe, un concept dinamic de stocare a informațiilor este eficient, ceea ce vă permite să simuleze datele și procesele în vigoare pe aceste date. Acest lucru vă permite să țineți cont de semantica zonei și, prin urmare, descrieți în mod adecvat aceste aplicații. Un astfel de concept se bazează pe o abordare orientată pe obiect, utilizată pe scară largă la crearea de software. MD, implementarea acestui concept și bazată pe o paradigmă orientată pe obiecte (OOP), a primit numele unui model de date orientat pe obiecte (OUD).

Construcția TOC încastrată din ipoteza că zona subiectului poate fi descrisă de setul de obiecte. Fiecare obiect este o entitate unică de identificare care conține atribute care descriu starea obiectelor lumii reale și acțiunile asociate. Starea actuală a obiectului este descrisă de unul sau mai multe atribute care pot fi simple sau complexe. Poate avea un atribut simplu tipul primitiv (de exemplu, un număr întreg, șir etc.) și să accepte sensul literal. Atributul compozit poate conține colecții și / sau linkuri. Atributul de referință este o legătură între obiecte.

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

Obiect ID (IID - Identificatorul obiectului) este o metodă internă pentru marcarea obiectelor individuale pentru baza de date. Utilizatorii care lucrează cu un program de dialog de solicitări sau informații de vizionare, de regulă, nu văd acești identificatori. Ei sunt desemnați și au folosit DBMS în sine. Semantica identificatorului din fiecare DBMS este a lor. Acesta poate fi atât o valoare aleatorie, cât și conține informațiile necesare pentru a căuta un obiect în fișierul de bază de date, de exemplu, numărul paginii din fișier și obiectul offset de la începutul său. Este identificatorul care ar trebui utilizat pentru a organiza referințele la obiect.

Toate obiectele sunt încapsulate, adică, prezentarea sau structura internă a obiectului rămâne ascunsă de utilizator. În schimb, utilizatorul știe numai acest lucru acest obiect Pot efectua anumite funcții. Deci, pentru facilitatea, depozitul poate folosi astfel de metode pentru a accepta_dovar, la emite_tobap etc. Avantajul încapsulării este că vă permite să modificați reprezentarea internă a obiectelor fără a relua aplicațiile în care sunt utilizate aceste obiecte. Cu alte cuvinte, încapsularea implică independența datelor.

Obiectul încapsulează datele și funcțiile (metode conform OOP). Metodele determină comportamentul obiectului. Acestea pot fi folosite pentru a schimba starea unui obiect prin schimbarea valorilor atributelor sale sau pentru a crea interogări la valorile atributelor preferate. De exemplu, pot exista metode de adăugare a informațiilor despre un nou obiect imobiliar pentru închiriere, pentru a actualiza informațiile despre salariul angajatului sau pentru imprimarea informațiilor 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 literatura de specialitate, termenul "clasă" și "tip" sunt adesea folosite ca sinonime). Fiecare astfel de clasă are propriul său reprezentant - un obiect care este un element de date. Obiectele dintr-o anumită clasă sunt numite copii..

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

Concepte importante ale OOP servesc ierarhia claselor și ierarhiei containerelor.

Clasele de ierarhie Aceasta implică posibilitatea de a avea prezența fiecărei clase, în acest caz, supraclassa, subclasa sa. De exemplu, puteți aduce următorul lanț: toți programatorii oricărei întreprinderi sunt angajații săi, prin urmare, fiecare programator care în cadrul OCD este o clasă de programatori, este, de asemenea, un angajat care, la rândul său, este un obiect de angajați de clasă. Astfel, programatorii vor fi o subclasă, angajați - un supraclass. Dar programatorii pot împărtăși, de asemenea, sistemul și aplicate. În consecință, programatorii vor fi o superclassă la subclamelele SIS_PROGRAME și GLOBAL_PROGRAMEMMERS. Continuând în continuare acest lanț, obținem o ierarhie a claselor, în care fiecare obiect subclasă moștenește copii ale variabilelor și metodelor supraclassului adecvat.

Există mai multe tipuri de moștenire - single, multiple și selective. Moștenirea unică este un caz în care subclasele moștenesc nu mai mult de o superclasă. Moștenire multiplă - moștenire mai mult de o superclassă. Moștenirea selectivă permite subclasa să moștenească un număr limitat de proprietăți ale superclasa sa.

Moștenirea copiilor variabilelor este numită moștenirea structurală, Metode de moștenire - moștenire comportamentală, și abilitatea de a folosi aceeași metodă pentru diferite clase sau, mai degrabă, se aplică metode diverse Cu același nume pentru diferite clase se numește polimorfism.

Arhitectura orientată pe obiect are, de asemenea, un alt tip de ierarhie - ierarhia containere. Este că unele obiecte pot fi constructive în interiorul altora. Astfel, obiectul de clasă ar trebui să conțină o variabilă disponibilă public, care este o referire la angajații de clasă, care corespunde șefului departamentului și trebuie să conțină, de asemenea, o legătură cu setul de referințe la obiectele care sunt potrivite pentru angajații din acest departament .

În unele sisteme orientate pe obiecte, clasa este, de asemenea, un obiect și are propriile atribute și metode. Caracteristici generale Clasa este descrisă de atributele sale. Metodele de clasă a obiectelor sunt un fel de analog al proprietăților obiectelor din lumea reală. Fiecare obiect referitor la orice clasă particulară are aceste proprietăți. În consecință, atunci când creați un obiect, este necesar să se declare clasa la care se referă astfel să determine proprietățile inerente.

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

Toate comunicațiile din modelul obiect se efectuează utilizând atributele de referință care sunt de obicei implementate ca identificatori OID.

Comunicarea în bazele de date relaționale sunt reprezentate prin compararea tastelor primare și externe. În baza de date în sine, nu există structuri pentru formarea asociațiilor între tabele, comunicarea este utilizată după cum este necesar la conectarea tabelelor. Dimpotrivă, comunicarea completează baza unei baze de date orientate pe obiect, deoarece identificatorii obiectelor cu care este conectat la fiecare obiect.

Nu numai legăturile tradiționale pot fi implementate în OUMD, dar și din cauza moștenirii.

Comunicare tip unu-la-unu (1: 1)Între obiectele A și B este implementat prin adăugarea unui atribut de referință unui obiect dintr-un obiect A și (pentru a menține integritatea de referință) a atributului de referință la obiectul A din obiectul V.

Tipul de comunicare One-la-Multe (1: m) Între obiectele A și B sunt implementate prin adăugarea unui atribut de referință unui obiect A și un atribut care conține un set de referințe la un obiect A, la un obiect în (de exemplu, un atribut de referință B (OID2, OID3 ...) este Adăugat și în cazurile unui obiect cu OID2, OID3, ... un atribut de referință A: OID1 este adăugat.

Comunicare ca mulți co-multe (M: N) Între obiectele A și B este implementat prin adăugarea unui atribut fiecărui obiect care conține un set de link-uri.

În Oud, puteți utiliza conexiunea "Integer", care descrie că obiectul aceleiași clase conține obiecte ale altor clase ca părțile sale. În cazul unei baze de date de producție între clasă, produsul și clasele, partea și asamblarea ar fi existat "Integer". Această comunicare - Aceasta este opțiunea comunicării "multor ko-numerice", care are o semantică specială. Comunicarea "Integerul" este implementată ca orice altă comunicare "Multe-la-multe" folosind o varietate de identificatori de obiecte asociate. Cu toate acestea, în contrast cu comunicarea obișnuită "Multe-ko-multe", are un alt sens semnificativ.

Deoarece paradigma orientată spre obiect acceptă moștenirea, atunci în Oud, este posibil să se utilizeze tipul "este" și conexiunea "extinde". Comunicarea "este", care se numește și relația de specializare-specializare, generează o ierarhie de moștenire, în care subclasele sunt furnizate de cazuri speciale de superclass. Acest lucru permite să nu descrie caracteristicile re-moștenite. Atunci când se utilizează comunicarea "extinde" subclasa dezvoltă funcționalitatea superclassului și nu se limitează la cazul său privat.

Luați în considerare modul în care aceste componente sunt implementate în Oud ca integritate și operațiuni de limitare a datelor.

Caracteristicile acestor componente sunt determinate de specificul modelului. Această specificitate în OMD este dictată în primul rând de conceptele sale interne ca încapsularea obiectelor, adică siguranța structurii interne, accesul la date numai prin anumite metode în avans, ierarhia clasei și ierarhia containerului.

Specificul OCOM este dictat de specificul obiectului. Se manifestă în nevoia de a grupa obiecte în clase. Fiecare obiect este inclus într-o anumită clasă, în funcție de sarcină, cu un obiect poate face parte dintr-o dată la mai multe clase (de exemplu, familia de programatori și plătitori de mare). Un alt obiect specific este acela că poate "dezactiva" de la o clasă (subclasă) la alta. Deci, programatorul de sistem se poate aplica cu timpul. Astfel, ierarhia clasei nu este un analog al modelului ierarhic, deoarece ar putea părea mai devreme, dar necesită un sistem de capacitate de a schimba locația fiecărui obiect în ierarhia clasei, de exemplu, pentru a naviga "în sus" sau "în jos "În această ierarhie. Dar este posibil un proces mai complex - sistemul ar trebui să furnizeze un obiect de obiect care trebuie atașat (deconectat) la un vârf arbitrar al ierarhiei în orice moment.

Un rol important în OUD joacă restricții privind integritatea relațiilor. Pentru ca comunicarea în MD orientate pe obiecte la locul de muncă, identificatorii obiectului de pe ambele părți ale comunicării trebuie să se respecte reciproc. De exemplu, dacă există o legătură între angajați și copiii lor, atunci trebuie să existe un fel de garanție că atunci când introduceți un obiect care descrie copilul într-un obiect care afișează angajatul, acesta din urmă identificator este adăugat la obiectul corespunzător. Acest tip de integritate de conectare, în ceva integritate similară de referință în modelul de date relațional, este setat folosind legături inverse. Pentru a garanta integritatea legăturilor, designerul este prevăzut cu un design special de sintaxă necesar pentru a specifica locația identificatorului invers al obiectului. Obligația de a stabili restricții privind integritatea relațiilor (precum și integritatea referințelor în baza de date relațională) se află pe designer.

În OMD și descrierea datelor și manipularea acestora apar cu același limbaj procedural orientat pe obiecte.

Obiect Gestionarea bazei de date GROP (GROMOP DE GESTIONARE A REGINGULELOR GROM). Ea a dezvoltat modelul de obiect (versiunea ODMG 2.0 a fost adoptată în septembrie 1997), care definește modelul standard pentru semantica obiectelor BD. Acest model are o importanță deosebită deoarece determină semantica încorporată, care este, de asemenea, înțeleasă și poate implementa DBMS orientate pe obiecte (Oosubd). Structura bibliotecilor și a aplicațiilor care utilizează această semantică trebuie transferată la diferite oosubde care susțin acest obiect MD. Principalele componente ale arhitecturii ODMG sunt: \u200b\u200bmodel de obiect (OM), Limba de definiție a obiectului (ODL), Limba de interogare a obiectului (OQL) și capacitatea de legare C ++, Java și SmalTalk.

Modelul obiect al datelor în conformitate cu standardul ODMG 2.0 este caracterizat prin următoarele proprietăți:

Elementele structurale de bază sunt obiecte și literari. Fiecare obiect are un identificator unic. Literalul nu are propriul identificator și nu poate exista separat ca obiect. Literalele sunt întotdeauna construite în obiecte și nu pot fi menționate individual;

Obiectele și literale diferă în tip. Fiecare tip are propriul său domeniu separat de toate obiectele și literale de acest tip. Tipurile pot avea, de asemenea, comportament. Dacă tipul are un comportament, atunci toate obiectele de acest tip au același comportament. În practică, tipul poate fi o clasă din care este creat un obiect, o interfață sau un tip simplu de date (de exemplu, un număr întreg). Obiectul poate fi reprezentat ca o instanță a tipului;

Starea obiectului este determinată de un set de valori curente implementate de o varietate de proprietăți. Aceste proprietăți pot fi atribute ale unui obiect sau o comunicare între un obiect și unul sau mai multe alte obiecte;

Comportamentul obiectului este determinat de un set de operații care pot fi efectuate deasupra obiectului sau obiectului în sine. Operațiile pot avea o listă de parametri de intrare și ieșire, fiecare dintre ele strict definit. Fiecare operație poate, de asemenea, să returneze un rezultat tipărit;

Definiția bazei de date este stocată într-o schemă înregistrată în limba de definiție a obiectului de definiție a obiectului (ODL). Baza de date stochează obiecte, permițându-le să le împărtășească pentru a împărtăși diverși utilizatori și aplicații.

DBM-urile bazate pe OUD se numește DBMS orientate pe obiecte (Oosubd). Aceste DBMS se referă la DBMS din a treia generație * (* Istoricul dezvoltării modelelor de stocare este adesea rupt în trei etape (generații): prima generație (sfârșitul anului 1960 este î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 aplicate în diferite organizații pentru a rezolva cercul larg. Sarcini. Analiza și generalizarea experienței acumulate în domeniul datelor tehnologiei informației au permis identificarea aplicațiilor în care utilizarea bazelor de date orientate pe obiecte este justificată:

Cererea constă în număr mare. Interacționarea pieselor. Fiecare dintre ei are comportamentul său, care depinde de comportamentul altora;

Sistemul trebuie să proceseze volume mari de nestructurate sau să aibă o structură complexă de date;

Cererea va efectua accesul la date previzibile, astfel încât natura de navigare a bazei de date orientate pe obiecte nu va fi un dezavantaj semnificativ;

Nevoia de solicitări neplanificate este limitată;

Structura datelor stocate are o natură ierarhică sau similară.

ÎN în prezent Există multe DBM-uri orientate pe obiecte pe piața software-ului. În fila. 10.6 Unele dintre sistemele comerciale ale acestei clase sunt prezentate.

Tabelul 10.6.

Oosubd comercial modern,

producătorii și domeniul lor de aplicare

Una dintre diferențele fundamentale ale bazelor de date obiect din relaționare este capacitatea de a crea și utiliza noi tipuri de date. O caracteristică importantă a OOSUBD este că crearea unui nou tip nu necesită o modificare a bazei de date și se bazează pe principiile programării orientate pe obiecte.

Miezul Oosubd este optimizat pentru operațiunile cu obiecte. Operații naturale pentru obiecte de caching, conducând versiuni de obiecte, separarea drepturilor de acces la obiecte specifice. Oosubd are o viteză mai mare asupra operațiunilor care necesită accesul și primirea datelor ambalate în obiecte, comparativ cu DBMS-urile relaționale, pentru care necesitatea de a preleva datele conexe duce la operații interne suplimentare.

O valoare considerabilă pentru Oosubd are capacitatea de a muta obiecte de la o bază la alta.

La crearea diferitelor aplicații bazate pe bazate pe Oosubd, este construită structura încorporată a clasei unuia sau a altor DBMS. Biblioteca de clasă suportă de obicei nu numai toate tipurile de date standard, ci și un set extins de tipuri multimedia și alte tipuri complexe de date, cum ar fi videoclipul, sunetul, secvența cadrelor de animație. În unele Oosubd, bibliotecile de clasă sunt create, permițând depozitarea și căutarea textului integral a informațiilor documentare (de exemplu, Jasmine, ODB-Jupiter). Un exemplu de structură de bază a claselor este prezentată în fig. 10.17.

Poziția principală în el ocupă clasa Todbobject, care conține toate proprietățile și metodele necesare pentru controlul accesului la baza de date și indexare. Toate celelalte clase își depășesc metodele prin adăugarea corectitudinii corectitudinii tipului implementat de acestea și a indexerului specific.

După cum se poate vedea din fig. 10.17, în structură există diferite clase concentrate pe procesarea informațiilor documentare - Todbtext, Todbdocument, TodbtextDocument etc. Fiecare document este reprezentat de un obiect separat. Acest lucru asigură stocarea naturală a documentelor. Una dintre cele mai importante operațiuni este de a căuta documente la cerere. Pentru majoritatea clase, este implementată abilitatea de a căuta obiecte cu valoarea unei anumite cheii. Pentru clasa Todbtext, este implementată posibilitatea formării search Query. Fraza scrisă într-o limbă naturală.

Clasa Todbdocument este specială, capabilă să găzduiască obiectele diferențiale. Se compune din câmpuri, fiecare având un nume și asociat cu obiectul unui anumit tip. Prezența acestei clase oferă utilizatorului posibilitatea de a extinde tipul de tip. Modificarea obiectului containerului (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 Oosubd a creat un sistem de informații ODB-text complet, care posedă structura universală Date stocate și mecanismul de căutare puternic. Sistemul ODB-Text este o prelucrare colectivă a documentelor și menținerea unei arhive corporative. Printre aplicațiile posibile va apela automatizarea contabilității documentelor de gestionare a biroului modern, referința de construcție sisteme de informare (similar cu bine-cunoscutele baze de date juridice), menținând baze de date de rețea, înregistrări ale personalului, bibliografiei etc.

41. Caracteristicile proiectării IP aplicate. Fazele de dezvoltare IP. (Subiectul 11, p. 100-103).

11.1.3. Caracteristicile proiectării sistemului aplicate

La construirea (selecție, adaptare) a sistemului informațional, puteți utiliza două concepte de bază, două abordări principale (al treilea concept - combinația lor):

1. Orientarea problemelor care trebuie rezolvate cu ajutorul acestui sistem informatic, adică abordarea orientată spre probleme (sau abordarea inductivă);

2. Orientarea tehnologiei care este disponibilă (actualizată) în acest sistem, mediu, adică Abordare orientată spre tehnologic (sau abordare deductivă).

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

Dacă posibilitățile tehnologiei existente sunt studiate mai întâi și după ce sunt determinate probleme realecare pot fi rezolvate cu ajutorul lor, atunci este necesar să se bazeze pe o abordare orientată tehnologic.

Dacă mai întâi sunt determinate problemele curente, iar apoi tehnologia este implementată suficient pentru a rezolva aceste probleme, este necesar să se bazeze pe o abordare orientată spre probleme.

În același timp, ambele concepte de construire a unui sistem informațional depind unul de celălalt: introducerea de noi tehnologii schimbă problemele solvabile, iar schimbarea problemelor rezolvate - conduce la necesitatea introducerii noilor tehnologii; Ambele sunt afectate de decizii.

Designul sistemului (Dezvoltare) și utilizarea oricărei sisteme informatice de aplicație (corporative) trebuie să transmită următorul ciclu de viață al sistemului informatic:

- analiza pre-proiectului (experiență în crearea altor sisteme similare, prototipuri, diferențe și caracteristici ale sistemului, etc.), analiza manifestărilor externe ale sistemului;

- analiza intrastemică, analiza internă (analiza subsistemelor de sistem);

- descrierea sistemică (morfologică) (prezentare) a sistemului (descrierea obiectivului sistemului, relațiile sistemice și relațiile de mediu, alte sisteme și resurse de sistem - materiale, energie, informație, organizațională, umană, spațială și temporară);

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

- descrierea funcțională a subsistemelor sistemului (descrierea modelelor, subsistemele algoritmilor de funcționare);

- Maketling (descriere de machiaj) a sistemului, evaluarea interacțiunii subsistemelor sistemului (Dezvoltarea aspectului - implementarea subsistemelor cu descrieri, proceduri și testarea simplificată a interacțiunii acestor aspecte pentru a satisface obiectivul sistemului ), este posibil să se utilizeze "layout-uri" de adecvare, durabilitate, eficiență;

- "Adunarea" și testarea sistemului - implementarea subsistemelor și criteriilor funcționale complete, evaluarea modelului în conformitate cu criteriile formulate;

- funcționarea sistemului;

- definirea obiectivelor dezvoltării ulterioare a sistemului și a aplicațiilor sale;

- Suportul sistemului - clarificarea, modificarea, extinderea capabilităților sistemului în modul său de funcționare (pentru ao evolua).

Aceste etape sunt sisteme de bază pentru sistemele de reengineering de informații.

Dezvoltarea unui sistem de informații corporative, de regulă, este efectuată pentru o întreprindere complet definită. Caracteristicile activității subiectului întreprinderii vor influența cu siguranță structura sistemului informațional. Dar, în același timp, structurile diferitelor întreprinderi sunt, în general, similare între ele. Fiecare organizație, indiferent de activitățile sale, constă într-o serie de diviziuni care desfășoară direct unul sau alt tip de activitate a companiei. Și această situație este valabilă pentru aproape toate organizațiile, indiferent de tipul de activitate pe care o fac.

Astfel, orice organizație poate fi considerată ca un set de elemente interacționale (unități), fiecare dintre acestea poate avea propria sa structură, destul de complicată. Relația dintre diviziuni este, de asemenea, destul de complexă. În cazul general, se pot distinge trei tipuri de linkuri între diviziile întreprinderilor:

Relațiile funcționale - fiecare unitate îndeplinește anumite tipuri de muncă ca parte a unui proces de afaceri unic;

Conexiuni de informare - diviziuni de schimb informații (documente, faxuri, ordine scrise și orale etc.);

Comunicații externe, unele diviziuni interacționează cu sisteme externeMai mult, interacțiunea lor poate fi, de asemenea, informativă și funcțională.

Structura generală a diferitelor întreprinderi face posibilă formularea unor principii uniforme pentru construirea de sisteme informatice corporative.

În general, procesul de dezvoltare a unui sistem informatic poate fi luat în considerare din două puncte de vedere:

În timp sau în etape ciclu de viață Sistem dezvoltat. În acest caz, se ia în considerare organizarea dinamică a procesului de dezvoltare descrisă în termeni de cicluri, etape, iterații și etape.

Sistemul informațional al întreprinderii este dezvoltat ca un proiect. Multe caracteristici ale managementului proiectelor și fazelor dezvoltării proiectului (fazele ciclului de viață) sunt generale, independente nu numai din zona subiectului, ci și asupra naturii proiectului (indiferent, ingineria este un proiect sau economic). Prin urmare, are sens la început să ia în considerare un număr probleme generale Management de proiect.

Proiectul este o schimbare limitată țintă într-un sistem separat, cu obiective inițial bine definite, a căror realizare determină finalizarea proiectului, precum și cerințe stabilite Până în prezent, rezultate, risc, cadru pentru fonduri și resurse și structura organizațională.

De obicei, pentru un concept complex (care, în special, conceptul proiectului) este dificil de oferit o formulare fără echivoc care acoperă pe deplin toate semnele ideii conceptului. Prin urmare, definiția de mai sus nu pretinde unicitatea și completarea.

Următoarele caracteristici principale distinctive ale proiectului ca obiect de conducere pot fi distinse:

Variabilitate - traducerea direcționată a sistemului de la existent în unele

starea dorită descrisă în ceea ce privește obiectivele proiectului;

Obiectiv limitat;

Durata limitată;

Limitări bugetare;

Resurse limitate necesare;

Noutate pentru întreprinderea pentru care este implementat proiectul;

Complexitatea este prezența unui număr mare de factori, afectează direct sau indirect progresul și rezultatele proiectului;

Dispoziția juridică și organizațională este crearea unei structuri organizaționale specifice la momentul implementării proiectului.

Eficacitatea lucrării se realizează prin gestionarea procesului de implementare a proiectului, care asigură distribuirea resurselor, coordonează secvența de muncă și compensarea efectelor perturbante interne și externe.

Din punctul de vedere al teoriei sistemelor de control, proiectul ca obiect de conducere trebuie respectat și ușor de gestionat, adică unele caracteristici sunt alocate pentru a monitoriza constant progresul proiectului (proprietatea observabilității). În plus, este necesar ca mecanismele care acționează în timp util despre progresul proiectului (proprietatea de gestionare).

Proprietatea de gestionare este deosebit de relevantă în fața incertitudinii și variabilității domeniului, care adesea însoțește proiecte pentru a dezvolta sisteme informatice.

Fiecare proiect, indiferent de complexitatea și domeniul de activitate necesar pentru punerea sa în aplicare, are loc în dezvoltarea anumitor state: de la stat atunci când proiectul nu este încă ", la stat atunci când proiectul nu mai este. Combinația de etape de dezvoltare de la apariția ideii la finalizarea completă a proiectului se face să se împartă în faze (etape, etape).

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

Următoarele faze ale dezvoltării sistemului de informații pot fi distinse:

Formarea conceptului;

Dezvoltarea specificațiilor tehnice;

Proiecta;

Fabricare;

Introducerea sistemului în funcțiune.

Luați în considerare fiecare dintre ele în detaliu. A doua și parțial a treia faze sunt făcute pentru a apela fazele de proiectare a sistemului, iar ultimele două (uneori includ faza de proiectare) - fazele de implementare.

Faza conceptuală

Formarea ideilor, stabilirea obiectivelor;

Formarea comenzii cheie a proiectului;

Studiul motivației și cerințelor clientului și al altor participanți;

Colectarea datelor sursă și analiza unui stat existent;

Identificarea cerințelor de bază și a restricțiilor cerute de resursele materiale, financiare și de muncă;

Evaluarea comparativă a alternativelor;

Reprezentare, expertiza și aprobarea lor.

Dezvoltarea dezvoltării tehnice

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

Dezvoltarea și aprobarea sarcinii tehnice;

Planificarea, descompunerea modelului structural de bază al proiectului;

Elaborarea estimărilor și bugetului proiectului, determinând necesitatea resurselor;

Dezvoltarea planurilor de calendar și a programelor de lucru extinse;

Semnarea unui contract cu clientul;

Instrumente de punere în funcțiune pentru comunicările participanților la proiect și monitorizarea muncii la domiciliu.

Proiecta

În această fază, sunt determinate subsistemele, sunt alese relațiile lor. metode eficiente Proiectul și utilizarea resurselor. Lucrări caracteristice ale acestei faze:

Efectuarea lucrărilor de proiectare de bază;

Dezvoltarea de sarcini tehnice private;

Implementarea designului conceptual;

Elaborarea specificațiilor și instrucțiunilor tehnice;

Reprezentarea dezvoltării, examinării și aprobării proiectelor.

Dezvoltare

În această fază, coordonarea și controlul operațional al lucrărilor la proiect sunt fabricate, subsisteme de fabricație, asocierea și testarea acestora. Conținut principal:

Executarea muncii de dezvoltare software;

Implementarea pregătirii pentru implementarea sistemului;

Controlul și reglementarea principalilor indicatori ai proiectului.

Punere in functiune

În această fază, testele, funcționarea pilot a sistemului în condiții reale, sunt în curs de desfășurare negocieri privind rezultatele proiectului și pe posibilele contracte noi. Principalele tipuri de lucrări:

Teste complexe;

42. Conceptul ciclului de viață IP. (Tema 11, pp. 103-105).

Model orientat pe obiecte

Într-un model orientat pe obiect, prezentarea datelor este posibilă identificarea înregistrărilor individuale de baze de date. Între înregistrările și funcțiile procesării acestora sunt stabilite cu ajutorul mecanismelor similare cu mijloacele adecvate în limbile de programare orientate pe obiecte.

Un model standard orientat pe obiect este descris în recomandările standard ODMG-93 (Grupul de gestionare a bazei de date Object - un grup de baze de date orientate spre obiect).

Luați în considerare un model simplificat al unei baze de date orientate pe obiect. Structura unei baze de date orientate pe obiecte reprezintă grafic sub forma unui copac al cărui noduri sunt obiecte. Proprietățile obiectelor sunt descrise de un tip standard sau tip, proiectat de utilizator (definit ca clasă). Valoarea proprietății tipului de clasă este un obiect care este o instanță a clasei corespunzătoare. Fiecare obiect instanță de clasă este considerat descendent al unui obiect în care este definită ca o proprietate. Un obiect obiect de obiecte aparține clasei sale și are un părinte. Relațiile generice în baza de date formează o ierarhie coerentă a obiectelor. Un exemplu de structură logică a unei baze de date de bibliotecă orientate pe obiect este prezentată în fig. 2.9. Aici, obiectul tipului de bibliotecă este un părinte pentru obiecte pentru obiecte. Abonat, director și emitere. Diferitele obiecte, cum ar fi o carte, pot avea unul sau diferit părinți. Obiectele cum ar fi o carte care are același părinte ar trebui să difere cel puțin numărul de inventar (unic pentru fiecare copie a cărții), dar au același ISBN, UDC proprietăți, nume și autor.

Structura logică a unei baze de date orientate pe obiect este similară cu structura bazei de date ierarhice. Principala diferență dintre ele constă în metode de manipulare a datelor.

Pentru a efectua acțiuni asupra datelor din modelul bazei de date în curs de examinare, sunt utilizate operațiuni logice, îmbunătățite prin mecanisme orientate pe obiecte de încapsulare, moștenire și polimorfism.

Încapsularea limitează domeniul de aplicare al denumirii proprietăților în cadrul obiectului în care este definit. Deci, dacă un tip de obiect este un obiect de catalog, întreabă telefonul autorului și a avea un nume de telefon, atunci vom primi proprietățile de același nume de la abonat și catalog. Semnificația acestei proprietăți va fi determinată de obiectul în care este încapsulat.

Moștenirea, dimpotrivă, distribuie scopul proprietății asupra tuturor descendenților obiectului. Deci, toate obiectele, cum ar fi cartea, care sunt descendenții obiectului de tip obiect, pot fi atribuite proprietăților obiectului părinte: ISBN, UDC, nume și autor. Dacă este necesar să se extindă efectul mecanismului de moștenire la obiectele care nu sunt rude directe (de exemplu, între doi descendenți ai unui părinte), atunci în strămoșul lor total este determinat tipul abstract de tip ABS. Deci, definiția proprietăților abstracte ale biletului și numărul în obiectul bibliotecii duce la moștenirea acestor proprietăți de către toți abonații, abonatul, cartea și emiterea. Nu este întâmplător ca valorile proprietății abonatului de bilete de clasă și emiterea prezentată în fig. 2.9, sunt acelasi - 00015.

Polimorfismul în limbile de programare orientată pe obiecte înseamnă capacitatea aceluiași cod de program de a lucra cu date multi-way. Cu alte cuvinte, înseamnă admisibilitatea în obiectele de diferite tipuri de a avea metode (proceduri sau funcții) cu aceleași nume. În timpul executării programului obiect, aceleași metode sunt operate cu obiecte diferite, în funcție de tipul de argument. În ceea ce privește exemplul în cauză, polimorfismul înseamnă că obiectele de clasă cu părinți diferiți din catalogul de clasă pot avea un set diferit de proprietăți. În consecință, programele de lucru cu obiecte de clasă pot conține un cod polimorf.

Căutarea unei baze de date orientate pe obiect este de a determina similitudinea dintre utilizatorul întrebat și obiectele stocate în baza de date.

Smochin. 2.9. Structura bazei de date logică a bibliotecii

Principalul avantaj al unui model de date orientat pe obiecte în comparație cu 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 intrare separată a bazei de date și să determinați funcțiile procesării acestora.

Dezavantajele unui model orientat pe obiecte sunt o complexitate conceptuală ridicată, inconvenientele procesării datelor și viteza redusă a interogărilor.

DBM-urile orientate pe obiecte includ poet, iasomie, versant, O2, ODB-Jupiter, Iris, Orion, postgres.

Băncile de date, ca întreg, sunt clasificate, de obicei, de motive economice și juridice.

În condițiile furnizării de servicii, se disting băncile gratuite și plătite, ceea ce, la rândul său, sunt împărțite în comerț și non-profit (științific, bibliotecă sau semnificativă din punct de vedere social).

La forma proprietății BNDS sunt împărțite în stat și non-stat. În funcție de gradul de accesibilitate, există intervale disponibile public și limitat.

Alte tipuri de clasificare sunt asociate cu componente separate BND.

1. Dezvoltarea băncilor de date constă din 4 etape:

Etapa 1. Formarea și analiza cerințelor sistemului:

O specificație a sistemului este compilată, care include o listă de sarcini pe care BND trebuie să o rezolve;

Lista utilizatorilor finali și funcțiile acestora;

Lista cerințelor bazei de date;

Circuitul fluxului de documente în cadrul organizației este întocmit.

Etapa 2. Design conceptual: modelul de informare a sistemului este creat fără a fi legat de tipul de calculator și tipul de software de sistem; Se construiește un model infografic al bazei de date, care descrie cel mai mult domeniul subiectului în termenii utilizatorului.

3 etapa. Design de implementare: Sistemul de calcul este selectat, sistem software. și dbms; Structura de date este proiectată și este construit modelul de zi de date al bazei de date (schema DB), care este o descriere a structurii logice a bazei de date în limba DBM-urilor selectate specifice.

4 etapa. Implementarea fizică care include crearea și descărcarea de date în baza de date, elaborarea și depanarea programelor de aplicații pentru lucrul cu baza de date, scrierea documentației. În acest stadiu, este construit modelul fizic al BD, care descrie dispozitivele de stocare utilizate, metodele de organizare fizică a datelor. O descriere a structurii fizice a bazei de date se numește schema de stocare. În prezent, există o tendință de a reduce acest tip de muncă.

2. Principalele sarcini rezolvate de personalul bancar de date

Personalul personalului BND include specialiști diferiți: administratori BND, analiști de sistem, programatori de sistem și aplicații, operatori, specialiști în mijloace tehnice, Marketing etc.

Listăm principalele funcții și sarcini rezolvate de personal atunci când dezvoltăm și operează o bază de date:

1) Analiza zonei subiectului (determinarea nevoilor utilizatorilor finali, construirea unui model de informare al domeniului subiectului, identificarea limitărilor de integritate);

2) Proiectarea unei structuri de baze de date (determinarea compoziției și structurii fișierelor de bază de date, o descriere a schemei sale în limba de descriere a datelor);

3) stabilirea limitărilor integrității bazei de date;

4) Încărcarea și întreținerea bazei de date (se face referire la baza de date, ștergerea și adăugarea de intrări); Dezvoltarea tehnologiei de descărcare și întreținere; Dezvoltarea formularelor de introducere a datelor; Introducerea și controlul datelor;

5) protecția datelor (delimitarea utilizatorilor, alegerea și verificarea mijloacelor de protecție, fixarea încercărilor de acces neautorizat);

6) asigurarea restabilirii bazei de date;

7) Analiza eficacității BND și a dezvoltării sistemului;

8) Lucrați cu utilizatorii (colectarea răspunsurilor, formării);

9) suportul software-ului de sistem (achiziție, instalare și dezvoltare);

10) Lucrări organizaționale și metodologice (alegerea metodelor de proiectare și modernizare, planificarea dezvoltării BND, dezvoltarea documentației).

3. Utilizatorii băncilor de date

Ca orice program și complex organizațional și tehnic, banca de date există în timp și în spațiu. Are anumite etape de dezvoltare:

Proiecta,

Implementare,

A sustine,

Actualizare și dezvoltare,

Reorganizare completă.

În fiecare etapă a existenței, diferite categorii de consumatori sunt conectate la banca de date.

Utilizatori finali

Aceasta este principala categorie de utilizatori care au interese asociate cu banca de date. În funcție de caracteristicile datelor create, datele pot fi, în esență, să difere în jurul utilizatorilor finali. Acestea pot fi consumatorii aleatorii adresați la baza de date din când în când în baza de date după primirea unor informații și pot exista utilizatori obișnuiți. Consumatorii casual pot fi considerați posibili clienți ai firmei care vizualizează catalogul de setări sau servicii cu generalizate sau descriere detaliata. Angajații care lucrează cu programe special concepute pentru ei, care oferă automatizarea acțiunii lor în performanța funcțiilor, pot fi utilizatori obișnuiți. De exemplu, la administratorul care planifică o unitate subsidiară compania de calculatoare, Există un program care îl ajută să planifice și să pună comenzi curente conform instrucțiunilor, să controleze cursul performanței lor, să eficientizeze în depozit accesoriile necesare pentru comenzi noi. Cunoștințele principale, speciale că, de la utilizatorii finali nu ar trebui să fie necesari în domeniul tehnologiei de limbă și de calcul.

Administratorii băncii de date

Acesta este un grup de utilizatori care, în stadiul inițial al dezvoltării băncii de date, este responsabil pentru dispozitivul său optim din punctul de vedere al funcționării simultane a unui set de utilizatori finali, în sprijin, etapa este responsabilă pentru funcționarea corectă a Acest stivă de informații în modul multiplayer. În dezvoltarea și etapa de reorganizare, acest grup este responsabil pentru posibilitatea reorganizării corecte a stivei fără a se schimba sau a-și termina serviciul curent.

Dezvoltatorii și administratorii de aplicații

Acest grup de utilizatori care funcționează în timpul proiectării, creării și reorganizării Băncii de Date. Administratorii de aplicații coordonează dezvoltatorii pentru a dezvolta o aplicație sau un grup de aplicații specifice în subsistemul funcțional. Dezvoltatorii anumitor aplicații lucrează cu partea din informațiile din baza de date, care este necesară pentru o anumită aplicație.

Nu în fiecare bancă de date, poate fi selectat orice tip de utilizatori. Se știe că dezvoltarea sistemelor informatice care utilizează administratorul tabelului DBMS al Băncii de date, administratorul de aplicații și dezvoltatorul au existat adesea într-o singură persoană. Cu toate acestea, atunci când creați baze de date corporative dificile moderne, care sunt utilizate pentru automatizarea tuturor unor părți mari de procese de afaceri într-o companie mare sau corporație, pot exista grupuri de administratori de aplicații și departamente de dezvoltatori. Cele mai dificile moduri de lucru sunt atribuite unui grup de administratori de baze de date.

Luați în considerare în detaliu.

O parte din grupul GND Admin trebuie să fie:

Comentatori de sistem;

Dezvoltatori de structuri de date și apariție privind banca de sprijinire a informațiilor;

Dezvoltatori de procesare a proceselor de prelucrare a datelor;

Sistem și programatori aplicați;

Companiile și experții existenți în serviciul de reparații.

Problema unei bănci comerciale de date, joacă un rol important, vânzând experți.

Principalele funcții ale grupului de administrare DB

1. Studiu de domeniu de date: Descrierea zonei de date, de stabilire a textului restricțiilor de integritate, definirea informațiilor privind statutul (disponibilitatea, confidențialitatea), definirea nevoilor consumatorilor, definirea "consumatorilor de date", determinarea caracteristicilor de prelucrare a datelor temporale.

2. Dezvoltarea structurii BD: definirea compoziției și structurii fișierelor de bază de date și a intermediarului de comunicare, selectarea metodelor de optimizare a datelor și a metodelor de acces pentru informații, descrierea bazelor de date în limba de descriere a datelor (Jaode).

3. Setarea restricțiilor de integritate în descrierea structurii procedurilor de procesare a bazei de date și a bazei de date:

Stabilirea restricțiilor de integritate declarativă inerente zonei de date;

Determinarea constrângerilor dinamice ale integrității inerente zonei de date în timpul unei modificări a informațiilor stocate în baza de date;

Determinarea restricțiilor de integritate este cauzată de structura bazei de date;

Dezvoltarea procedurilor de susținere a integrității bazei de date la introducerea și reglarea datelor;

Determinarea restricțiilor integrității funcționării paralele a consumatorilor în modul multiplayer.

4. Inițierea bazei de date de descărcare și manuală

Dezvoltarea tehnicii de încărcare DB, care va diferi de procedura de schimbare și adăugare a unei baze de date cu datele cu utilizare regulată;

Dezvoltarea tehnicilor de verificare a datelor introduse, starea reală a zonei de date. Obiectele reale ale modelelor de baze de date ale unei zone de date și corelarea intermediară și la momentul încetării reparații curente Acest model trebuie să se potrivească cu starea obiectelor din zona de date acum;

Conform tehnicii dezvoltate de inițiere a proiectării sistemului de introducere a datelor, poate fi necesară.

5. Protecția datelor

Determinarea sistemului de parole, principiile de filmare a consumatorilor, crearea de grupuri de consumatori care au drepturi identice de acces la date;

Elaborarea principiilor de prevenire a anumitor date și de dezvoltare; Elaborarea de metode specializate de codificare a informațiilor în timpul circulației sale în rețelele de informare locale și globale;

Dezvoltarea mijloacelor de fixare a accesului la date și încercări de încălcarea sistemului de protecție;

Sistem de protectie de testare;

Studiul cazurilor de încălcare a sistemului de protecție și de a dezvolta metode dinamice pentru prevenirea informațiilor din baza de date.

6. Suport pentru restaurarea bazei de date

Dezvoltarea mijloacelor organizaționale de arhivare și principii pentru restaurarea bazei de date;

Dezvoltarea unor maturi suplimentare și procese tehnologice de recuperare a bazei de date după eșecuri.

7. Studiul bazei de date pentru apelurile clienților: un set de statistici privind simbolul cererilor, timpul de includere a performanței acestora, în conformitate cu documentele de ieșire necesare

8. Studiul eficacității funcționării BND:

Studiul indicilor de funcționare BND

Restructurarea planificării structurii (schimbarea structurală) a bazei de date și reorganizarea BND.

9. Lucrați cu utilizatorii finali:

Colectarea informațiilor despre schimbarea zonei de date;

Colectarea de informații privind evaluarea lucrărilor BND;

Instruirea consumatorilor, consultanta consumatorilor;

Dezvoltarea documentației sistematice și educaționale necesare privind activitatea utilizatorilor finali.

10. Echipamente de sistem de gătit și de susținere:

Studiul maturilor existente pe piață și capacitățile de cercetare și necesitatea de a le folosi în cadrul BND;

Dezvoltarea programului organizatoric și tehnic necesar al mișcărilor pentru dezvoltarea BND;

Verificarea performanței maturilor răscumpărate în fața legăturii lor cu BND;

Controlul conexiunii noilor maturi către BND.

11. Lucrări organizaționale și sistematice la dezvoltarea BND:

Selectarea sau crearea unei metode de dezvoltare a bazelor de date;

Determinarea obiectivelor și direcția dezvoltării sistemului în ansamblu;

Planificarea etapelor de dezvoltare a BND;

Elaborarea de cărți de referință de dicționare generale ale proiectului BND și model conceptual;

Instalarea modelelor externe de aplicații dezvoltate;

Controlul conexiunii noii aplicații la operațiunea BND;

Posibilitatea de depanare integrată a aplicațiilor care interacționează de la o bază de date.

Într-un model orientat pe obiecte (OU), când datele sunt trimise, este posibilă identificarea intrărilor individuale de bază. Între înregistrările bazei de date și funcțiile procesării acestora stabilesc relații utilizând mecanisme similare cu mijloacele adecvate în limbile de programare orientate pe obiecte.

Standard Ou. Descrise în recomandările standard ODMG-93 (Grupul de gestionare a bazei de date Object - un grup de grupă de gestionare a bazelor de date orientate pe obiecte). În totalitate, recomandarea ODMG-93 nu este încă posibilă. Pentru a ilustra ideile cheie, luați în considerare un model ușor simplificat al unei baze de date orientate pe obiect.

Structura OO DB reprezintă grafic sub forma unui copac al cărui noduri sunt obiecte. Proprietățile obiectului sunt descrise de un anumit tip standard (de exemplu, șir) sau un tip de către utilizatorul construit de către utilizator (definit ca clasă).

Valorile tipului de șir este un șir de caractere. Valoarea proprietății tipului de clasă este un obiect care este o instanță a clasei corespunzătoare. Fiecare obiect instanță de clasă este considerat descendent al unui obiect în care este definită ca o proprietate. Un obiect obiect de obiecte aparține clasei sale și are un părinte. Relațiile generice din baza de date formează o ierarhie legată de obiecte.

Un exemplu de structură logică a cazului de bibliotecă OO DB este prezentat în fig. 3.14. Aici, obiectul tipului de bibliotecă este un părinte pentru obiecte pentru obiecte. Abonat, director și emitere. Diverse obiecte, cum ar fi o carte având același părinte, ar trebui să difere în cel puțin un număr de inventar (unic pentru fiecare copie a cărții), dar au aceleași valori ale proprietăților iSBN, UDC, numeși autor.

Fig.3.14.Îngrijirea datelor structurale logice

Structura logică a OO DB este similară cu structura bazei de date ierarhice. Principala diferență dintre ele constă în metode de manipulare a datelor. Pentru a efectua acțiuni privind datele din baza de date, se utilizează operații logice, armate prin mecanisme orientate pe obiecte, de încapsulare, moștenire și polimorfism. Operațiunile, cum ar fi comenzile SQL, pot fi limitate (de exemplu, pentru a crea o bază de date).

Crearea și modificarea bazei de date este însoțită de formarea automată și ajustarea indexului ulterior (tabele index) care conțin informații pentru a căuta rapid datele.

Luați în considerare scurt conceptul de încapsulare, moștenire și polimorfism în raport cu baza de date.

Încapsularelimitează domeniul de aplicare al denumirii proprietății în cadrul obiectului în care este definit. Deci, dacă un obiect este un obiect de catalog Adăugați proprietatea solicită agendei telefonului și a avea un nume telefon,apoi vom primi proprietățile de același nume de la abonat și catalog. Semnificația acestei proprietăți va fi determinată de obiectul în care este încapsulat.

Moştenire, Dimpotrivă, distribuie zona de vizibilitate a proprietății asupra tuturor descendenților obiectului. Astfel, toate obiectele, cum ar fi o carte, care sunt descendenții tipului de obiect al catalogului, pot fi atribuite proprietăților obiectului părinte: iSBN, UDC, numeși autor.Dacă este necesar să se extindă efectul mecanismului de moștenire la obiectele care nu sunt rude directe (de exemplu, între doi descendenți ai unui părinte), atunci în strămoșul lor total este determinat tipul abstract de tip ABS. Deci, definiția proprietăților abstracte bilet și numărÎn obiect, biblioteca duce la moștenirea acestor proprietăți de către toți abonații, abonatul, cartea și emiterea. Nu întâmplător, prin urmare, valorile proprietății biletclase Abonatul și emiterea prezentată în figură vor fi aceeași - 00015.

PolimorfismÎn limbile de programare orientată spre obiect, înseamnă capacitatea aceluiași cod de program de a lucra cu date multi-way. Cu alte cuvinte, înseamnă admisibilitatea în obiectele de diferite tipuri de a avea metode (proceduri sau funcții) cu aceleași nume. În timpul executării programului obiect, aceleași metode sunt operate cu obiecte diferite, în funcție de tipul de argument. În ceea ce privește baza de date OO, polimorfismul înseamnă că rezervarea obiectelor de clasă având părinții diferiți din directorul de clasă poate avea un set diferit de proprietăți. În consecință, programele de lucru cu obiecte de clasă pot conține un cod polimorf.

Căutarea în BD OO este de a afla similitudinea dintre obiectul specificat de utilizator și obiectele stocate în baza de date. Obiectul definit de utilizator, numit scopul obiectului (proprietatea obiectului este scopul de tip), în cazul general poate fi un subset al întregii ierarhii obiectelor din baza de date. Obiectul obiectului, precum și rezultatul executării interogării pot fi stocate în baza de date în sine. Un exemplu de cerere de bilete de cititor și nume de abonați care au primit cel puțin o carte de către bibliotecă este prezentată în fig. 3.15.

De bază demnitateAceste date în comparație cu relaționalul este capacitatea de a afișa informații despre interconexiunile complexe ale obiectelor. Acest lucru vă permite să identificați o intrare separată a bazei de date și să determinați funcțiile procesării acestora.

DezavantajOy sunt complexități conceptuale ridicate, inconveniente de prelucrare a datelor și viteza redusă a interogărilor.

Fig.3.15.Fragmentul bazei de date cu scopul obiectului

Revenirea la sarcina comenzilor reprezentate ca model de date relațional din fig. 3.8, și considerați-o în ceea ce privește o bază de date orientată pe obiect. În total, în exemplul a trei clase: " Clienți», « Comenzi"Și" Produse" Clasa " Clienți»Sunt clienți concreți; Proprietăți de clasă - Număr de client, numele clientului, statutul etc. Metode de clasă - " Creați o comandă», « Plătește factură"etc. Metoda este o anumită operație care poate fi aplicată obiectului; Metoda este ceea ce ar trebui să facă obiectul. Clasa corespunzătoare tabelului " Informații despre comandă", nu este necesar. Datele de tabel pot face parte din clasa " Comenzi" Disponibilitatea în clasă " Clienți"Metodă" Creați o comandă"Duce la interacțiunea cu clasele de clase" Comenzi"Și" Produse" În același timp, utilizatorul nu trebuie să știe despre această interacțiune a obiectelor. Utilizatorul apelează doar la obiect " Comenzi"Și folosește metoda" Creați o comandă" Faptul de expunere la alte baze de date poate fi ascuns de utilizator. Dacă metoda " Creați o comandă", La rândul său, se referă la metoda" Verificați bonitatea clientului"Acest fapt poate fi, de asemenea, ascuns de utilizator. ÎN bazele relaționale Datele Pentru a efectua aceleași funcții, trebuie să scrieți proceduri în vizuale de bază pentru aplicație (VBA).

În anii '90 au existat prototipurile experimentale ale sistemelor de gestionare a bazelor de date OO. În prezent, astfel de sisteme au fost larg răspândite. În special, acestea includ următoarele dbms: poet (poet software), iasomie (Computer Associates), versant (tehnologii versante), O2 (Software Ardent), ODB-Jupiter (Inteltek plus Centrul științific și de producție), precum și IRIS, Orion și postgres.