Modelli di presentazione dei dati: un modello orientato agli oggetti. Modello di dati orientato agli oggetti

Nel modello orientato agli oggetti (OOM), durante la presentazione dei dati, è possibile identificare i singoli record del database. Le relazioni vengono stabilite tra i record del database e le loro funzioni di elaborazione utilizzando meccanismi simili a quelli dei linguaggi di programmazione orientati agli oggetti.

OOM standard descritto nelle raccomandazioni dello standard ODMG-93 (Object Database Management Group). Le raccomandazioni dell'ODMG-93 non sono ancora state pienamente attuate. Per illustrazione idee chiave Consideriamo un modello un po' semplificato di un database orientato agli oggetti.

La struttura del database OO è rappresentata graficamente sotto forma di albero, i cui nodi sono oggetti. Le proprietà degli oggetti sono descritte da un tipo standard (ad esempio, un tipo stringa) o un tipo costruito dall'utente (definito come classe).

Il valore di una proprietà di tipo stringa è una stringa di caratteri. Il valore di una proprietà di tipo class è un oggetto che è un'istanza della classe corrispondente. Ogni istanza di una classe è considerata un discendente dell'oggetto in cui è definita come proprietà. Un oggetto istanza di una classe appartiene alla sua classe e ha un solo genitore. Le relazioni generiche nel database formano una gerarchia correlata di oggetti.

Un esempio della struttura logica dell'OO DB della biblioteconomia è mostrato in Fig. 3.14. In questo caso, un oggetto di tipo LIBRARY è l'oggetto padre, ad esempio, delle classi SUBSCRIBER, DIRECTORY e OUTPUT. Oggetti diversi di tipo LIBRO aventi lo stesso capostipite devono differire almeno nel numero di inventario (unico per ogni copia del libro), ma avere gli stessi valori proprietà isbn, udk, nome e autore.

Figura 3.14. La struttura logica del database della biblioteca

La struttura logica del database OO è esteriormente simile alla struttura di un database gerarchico. La principale differenza tra loro risiede nei metodi di manipolazione dei dati. Per eseguire azioni sui dati nel database OOM, utilizzare operazioni logiche potenziato da meccanismi orientati agli oggetti di incapsulamento, ereditarietà e polimorfismo. Operazioni simili ai comandi SQL possono essere utilizzate in misura limitata (ad esempio, per creare un database).

La creazione e la modifica della banca dati è accompagnata dalla formazione automatica e dal successivo adeguamento di indici (tabelle indice) contenenti informazioni per ricerca rapida dati.

Consideriamo brevemente i concetti di incapsulamento, ereditarietà e polimorfismo in relazione ai database OOM.

incapsulamento limita l'ambito del nome della proprietà ai limiti dell'oggetto in cui è definito. Quindi, se aggiungi una proprietà a un oggetto di tipo DIRECTORY che imposta il numero di telefono dell'autore del libro e ha il nome telefono, quindi otterremo proprietà con lo stesso nome per gli oggetti SUBSCRIBER e DIRECTORY. Il significato di tale proprietà sarà determinato dall'oggetto in cui è incapsulata.

Eredità, al contrario, estende l'ambito della proprietà a tutti i discendenti dell'oggetto. Quindi, a tutti gli oggetti del tipo BOOK che sono discendenti di un oggetto del tipo DIRECTORY possono essere assegnate le proprietà dell'oggetto genitore: isbn, udk, nome e autore. Se è necessario estendere l'effetto del meccanismo di ereditarietà a oggetti che non sono parenti immediati (ad esempio, tra due discendenti dello stesso genitore), allora viene definita una proprietà astratta di tipo abs nel loro antenato comune. Quindi, la definizione di proprietà astratte biglietto e Camera in un oggetto LIBRARY fa sì che queste proprietà vengano ereditate da tutti gli oggetti SUBSCRIBER, BOOK e REFERENCE figlio. Non è un caso che i valori dell'immobile biglietto delle classi SUBSCRIBER e ISSUE mostrate in figura saranno le stesse - 00015.

Polimorfismo nei linguaggi di programmazione orientati agli oggetti, significa la capacità dello stesso codice di programma di lavorare con diversi tipi di dati. In altre parole, significa validità negli oggetti tipi diversi avere metodi (procedure o funzioni) con gli stessi nomi... Durante l'esecuzione di un programma oggetto, gli stessi metodi operano su oggetti diversi a seconda del tipo di argomento. Applicato al nostro DB OO, il polimorfismo significa che gli oggetti della classe BOOK, avendo genitori diversi dalla classe DIRECTORY, possono avere un diverso insieme di proprietà. Di conseguenza, i programmi per lavorare con oggetti della classe BOOK possono contenere codice polimorfico.

La ricerca nel database OO consiste nel trovare la somiglianza tra l'oggetto specificato dall'utente e gli oggetti memorizzati nel database. Un oggetto definito dall'utente chiamato oggetto goal (la proprietà dell'oggetto è di tipo goal), nel caso generale, può rappresentare un sottoinsieme dell'intera gerarchia di oggetti archiviati nel database. L'oggetto di destinazione, così come il risultato dell'esecuzione della query, può essere archiviato nel database stesso. In fig. 3.15.

Il principale dignità OOM rispetto ai dati relazionali è la capacità di visualizzare informazioni su complesse relazioni tra oggetti. I dati OOM consentono di identificare un singolo record del database e definire le funzioni della loro elaborazione.

Svantaggio Gli OOM sono un'elevata complessità concettuale, disagi nell'elaborazione dei dati e bassa velocità esecuzione delle richieste.

Figura 3.15. Frammento del database con l'oggetto di destinazione

Torniamo ancora al task Orders, presentato sotto forma di modello di dati relazionale in Fig. 3.8 e considerarlo in termini di database orientato agli oggetti. Ci sono tre classi in totale: " Clienti», « Ordini" e " Prodotti". Oggetti della classe " Clienti»Sono clienti specifici; proprietà della classe: numero cliente, città nome cliente, stato e così via. Metodi di classe - " Crea ordine», « Paga la fattura" eccetera. Un metodo è un tipo di operazione che può essere applicata a un oggetto; un metodo è ciò che un oggetto dovrebbe fare. La classe corrispondente alla tabella " Dettagli dell'ordine", non richiesto. I dati della tabella possono essere parte della classe " Ordini". Presenza in classe" Clienti"Metodo" Crea ordine"Porta all'interazione con gli oggetti delle classi" Ordini" e " Prodotti". In questo caso, l'utente non ha bisogno di conoscere questa interazione di oggetti. L'utente si riferisce solo all'oggetto " Ordini"E usa il metodo" Crea ordine". L'impatto su altri database può essere nascosto all'utente. Se il metodo " Crea ordine", A sua volta, si riferisce al metodo" Verifica la solvibilità del cliente”, Questo fatto può anche essere nascosto all'utente. Nei database relazionali, per svolgere le stesse funzioni, è necessario scrivere procedure nel linguaggio Visual Basic per applicazione (VBA).

Negli anni '90, c'erano prototipi sperimentali di sistemi di gestione di database OO. Attualmente, tali sistemi sono molto diffusi. In particolare, questi includono i seguenti DBMS: POET (POET Software), Jasmine (Computer Associates), Versant (Versant Technologies), O2 (Ardent Software), ODB-Jupiter (Inteltek Plus Research and Production Center), e Iris, Orion e Postgres.

Le tecnologie di database basate sui suddetti MD si basano su un concetto statico di archiviazione delle informazioni, focalizzato sulla modellazione dei dati. Tuttavia, nuove aree di applicazione della tecnologia con oggetti di database complessi e interconnessi, come:

Progettazione assistita da computer;

Produzione automatizzata;

Sviluppo automatizzato Software;

Sistemi informativi per uffici;

Sistemi multimediali;

Sistemi informativi geografici;

Sistemi di pubblicazione e altri - hanno dimostrato le capacità limitate del concetto statico in termini di modellazione di oggetti nel mondo reale.

Per i nuovi tipi di complesse applicazioni di database specializzate, è efficace un concetto dinamico di archiviazione delle informazioni, che consente di simulare dati e processi che agiscono su questi dati in parallelo. Ciò consente di prendere in considerazione la semantica del dominio e quindi descrivere in modo più adeguato queste applicazioni. Questo concetto si basa sull'approccio orientato agli oggetti ampiamente utilizzato nello sviluppo del software. MD implementazione questo concetto e basato sul paradigma orientato agli oggetti (OOP), è chiamato modello di dati orientato agli oggetti (OOMD).

La costruzione di OOMD parte dal presupposto che l'area tematica possa essere descritta da un insieme di oggetti. Ogni oggetto è un'entità identificabile in modo univoco che contiene attributi che descrivono lo stato degli oggetti del "mondo reale" e le loro azioni associate. Lo stato corrente di un oggetto è descritto da uno o più attributi, che possono essere semplici o complessi. Un semplice attributo può essere di tipo primitivo (ad esempio intero, stringa, ecc.) e assumere un valore letterale. Un attributo composito può contenere raccolte e/o collegamenti. Un attributo di riferimento rappresenta una relazione tra gli oggetti.

La proprietà fondamentale di un oggetto è l'unicità della sua Identificazione. Pertanto, ogni oggetto in un sistema orientato agli oggetti deve avere il proprio identificatore.

Un Object Identifier (OID) è un modo interno al database di etichettare singoli oggetti. Gli utenti che lavorano con il programma di dialogo per impostare query o visualizzare informazioni, di norma, non vedono questi identificatori. Sono assegnati e utilizzati dal DBMS stesso. La semantica dell'identificatore in ciascun DBMS è diversa. Può essere un valore casuale o contenere le informazioni necessarie per trovare un oggetto nel file di database, ad esempio il numero di pagina nel file e l'offset dell'oggetto dal suo inizio. È l'identificatore che dovrebbe essere usato per organizzare i riferimenti all'oggetto.

Tutti gli oggetti sono incapsulati, ovvero la rappresentazione o la struttura interna dell'oggetto rimane nascosta all'utente. Invece, l'utente sa solo che questo oggetto può eseguire alcune funzioni. Ad esempio, per l'oggetto WAREHOUSE possono essere utilizzati metodi come ACCEPT_PRODUCT, EXIT_TOBAP, ecc.. Il vantaggio dell'incapsulamento è che consente di modificare la rappresentazione interna degli oggetti senza rielaborare le applicazioni che utilizzano questi oggetti. In altre parole, l'incapsulamento implica l'indipendenza dei dati.

Un oggetto incapsula dati e funzioni (metodi, secondo OOP). I metodi definiscono il comportamento di un oggetto. Possono essere utilizzati per modificare lo stato di un oggetto modificando i valori dei suoi attributi, oppure per interrogare i valori degli attributi selezionati. Ad esempio, potrebbero esserci metodi per aggiungere informazioni su una nuova proprietà in affitto, aggiornare le informazioni sullo stipendio di un dipendente o stampare informazioni su un elemento specifico.

Gli oggetti che hanno lo stesso insieme di attributi e rispondono agli stessi messaggi possono essere raggruppati in Classe(in letteratura i termini "classe" e "tipo" sono spesso usati in modo intercambiabile). Ciascuna di queste classi ha il proprio rappresentante: un oggetto, che è un elemento di dati. Si chiamano oggetti di una certa classe copie.

In alcuni sistemi orientati agli oggetti, anche una classe è un oggetto e ha i propri attributi e metodi chiamati attributi di classe e metodi di classe.

Concetti importanti OOP servire gerarchia di classi e gerarchia di contenitori.

Gerarchia di classe implica la possibilità che ogni classe, chiamata in questo caso superclasse, abbia la propria sottoclasse. A titolo di esempio, possiamo dare la seguente catena: tutti i programmatori di un'impresa sono i suoi dipendenti, quindi ogni programmatore che è un oggetto della classe PROGRAMMERS all'interno dell'OOMD è anche un dipendente che, a sua volta, è un oggetto dei DIPENDENTI classe. Pertanto, i PROGRAMMATORI saranno una sottoclasse, i DIPENDENTI saranno una superclasse. Ma i programmatori possono anche essere divisi in sistema e applicazione. Pertanto, PROGRAMMERS sarà la superclasse delle sottoclassi SIS_PROGRAMMERS e APPLICATION_PROGRAMMERS. Continuando ulteriormente questa catena, otteniamo una gerarchia di classi in cui ogni oggetto della sottoclasse eredita le istanze di variabili e metodi della corrispondente superclasse.

Esistono diversi tipi di ereditarietà: singola, multipla e selettiva. L'ereditarietà singola è un caso in cui le sottoclassi ereditano da al massimo una superclasse. Ereditarietà multipla: eredità da più di una superclasse. L'ereditarietà selettiva consente a una sottoclasse di ereditare quantità limitata proprietà della sua superclasse.

Viene chiamata l'ereditarietà dell'istanza variabile eredità strutturale, ereditarietà del metodo - eredità comportamentale, ma la possibilità di utilizzare lo stesso metodo per classi diverse, o meglio di applicare metodi diversi con lo stesso nome per classi diverse si chiama polimorfismo.

L'architettura orientata agli oggetti ha anche un altro tipo di gerarchia: gerarchia dei contenitori... Consiste nel fatto che alcuni oggetti possono essere contenuti concettualmente all'interno di altri. Pertanto, un oggetto della classe DIPARTIMENTO deve contenere la variabile pubblica HEAD, che è un collegamento all'oggetto della classe DIPENDENTI corrispondente al capo del dipartimento, e deve contenere anche un collegamento a un insieme di riferimenti a oggetti corrispondenti al dipendenti che lavorano in questo reparto.

In alcuni sistemi orientati agli oggetti, anche una classe è un oggetto e ha i propri attributi e metodi. Caratteristiche generali classe sono descritti dai suoi attributi. I metodi delle classi di oggetti sono in qualche modo analoghi alle proprietà degli oggetti nel mondo reale. Ogni oggetto relativo a qualsiasi una certa classe, ha queste proprietà. Pertanto, quando si crea un oggetto, è necessario dichiarare la classe a cui appartiene per definire in questo modo le sue proprietà intrinseche.

L'utente e l'oggetto interagiscono tramite messaggi. In risposta a ciascun messaggio, il sistema esegue il metodo appropriato.

Tutti i collegamenti in modello a oggetti sono implementati utilizzando attributi di riferimento, che di solito sono implementati come OID.

Le relazioni in un database relazionale sono rappresentate da una mappatura di chiavi primarie ed esterne. Nella base stessa, non ci sono strutture per la formazione di associazioni tra tabelle, i collegamenti vengono utilizzati secondo necessità quando si uniscono le tabelle. Al contrario, le relazioni costituiscono la spina dorsale di un database orientato agli oggetti, poiché ogni oggetto include gli identificatori degli oggetti a cui è associato.

In OOMD, non solo i collegamenti tradizionali possono essere implementati, ma anche i collegamenti condizionati dall'ereditarietà.

Comunicazione uno a uno (1: 1) tra gli oggetti A e B viene implementato aggiungendo un attributo di riferimento all'oggetto B all'oggetto A e (per mantenere l'integrità referenziale) un attributo di riferimento all'oggetto A all'oggetto B.

Relazione uno a molti (1: M) tra gli oggetti A e B viene implementato aggiungendo all'oggetto A un attributo di riferimento all'oggetto B e un attributo contenente un insieme di riferimenti all'oggetto A all'oggetto B (ad esempio, viene aggiunto un attributo di riferimento B (OID2, OID3 ...) all'oggetto A e alle istanze dell'oggetto B con OID2, OID3, ... viene aggiunto un attributo di riferimento A: OID1.

Relazione molti a molti (M: N) tra gli oggetti A e B viene implementato aggiungendo a ciascun oggetto un attributo contenente un insieme di collegamenti.

In OOMD, puoi usare una relazione intero-parte, che descrive che un oggetto di una classe contiene oggetti di altre classi come sue parti. Nel caso di un database di produzione, ci sarebbe una relazione total-to-part tra la classe PRODUCT e le classi PART e ASSEMBLY. Questa connessioneè una variante di una relazione molti a molti con semantica speciale. Una relazione intero-parte viene implementata come qualsiasi altra relazione molti-a-molti, utilizzando un insieme di identificatori di oggetti correlati. Tuttavia, in contrasto con la consueta relazione molti a molti, ha un significato semantico diverso.

Poiché il paradigma orientato agli oggetti supporta l'ereditarietà, in OOMD è possibile utilizzare la relazione del tipo "is" e la relazione del tipo "extends". La relazione is, chiamata anche relazione di generalizzazione-specializzazione, genera una gerarchia di ereditarietà in cui le sottoclassi sono casi speciali di superclassi. Ciò evita di descrivere le caratteristiche re-ereditate. Quando si utilizza la relazione "estende", la sottoclasse sviluppa la funzionalità della superclasse invece di essere limitata al suo caso particolare.

Considera come i componenti come i vincoli di integrità e le operazioni sui dati vengono implementati in OOMD.

Le caratteristiche di questi componenti sono determinate dalle specifiche del modello. Questa specificità in OOMD è dettata principalmente dai suoi concetti interni come l'incapsulamento di oggetti, cioè la segretezza della struttura interna, l'accesso ai dati solo attraverso metodi predefiniti, la gerarchia delle classi e la gerarchia dei contenitori.

La specificità dell'OOMD è dettata anche dalla specificità dell'oggetto. Si manifesta nella necessità di raggruppare gli oggetti in classi. Ogni oggetto è incluso in una o nell'altra classe a seconda dell'attività e un oggetto può appartenere a più classi contemporaneamente (ad esempio, le famiglie PROGRAMMERS e HIGHLY PID). Un'altra specificità di un oggetto è che può "trapassare" da una classe (sottoclasse) a un'altra. Quindi un PROGRAMMATORE DI SISTEMA può diventare APPLICABILE nel tempo. Pertanto, la gerarchia di classi non è analoga al modello gerarchico, come potrebbe sembrare in precedenza, ma richiede che il sistema sia in grado di modificare la posizione di ciascun oggetto all'interno della gerarchia di classi, ad esempio, spostarsi "su" o "giù" all'interno questa gerarchia. Ma è anche possibile un processo più complesso: il sistema deve garantire la capacità di un oggetto di essere attaccato (staccato) a un vertice arbitrario della gerarchia in qualsiasi momento.

Ruolo importante vincoli sull'integrità dei collegamenti riprodotti in OOMD. Affinché i collegamenti in un MD orientato agli oggetti funzionino, gli identificatori degli oggetti su entrambi i lati del collegamento devono corrispondere. Ad esempio, se esiste una relazione tra I DIPENDENTI e i loro FIGLI, allora ci deve essere la certezza che quando un oggetto che descrive un bambino viene inserito in un oggetto che rappresenta un dipendente, l'identificatore di quest'ultimo viene aggiunto all'oggetto corrispondente. Questo tipo di integrità del collegamento, in qualche modo analogo all'integrità referenziale in un modello di dati relazionale, viene stabilita utilizzando i feedback. Per garantire l'integrità dei collegamenti, al progettista viene fornita una sintassi speciale necessaria per specificare la posizione dell'identificatore dell'oggetto inverso. La responsabilità di impostare vincoli sull'integrità dei collegamenti (così come sull'integrità referenziale in un database relazionale) spetta al progettista.

In OOMD, sia la descrizione dei dati che la loro manipolazione avvengono utilizzando lo stesso linguaggio procedurale orientato agli oggetti.

Il gruppo ODMG (Object Database Management Groop) si occupa dei problemi di standardizzazione della tecnologia dei database a oggetti. Ha sviluppato un modello a oggetti (la versione 2.0 di ODMG è stata adottata nel settembre 1997) che definisce un modello standard per la semantica degli oggetti del database. Questo modello è importante perché definisce la semantica incorporata che un DBMS orientato agli oggetti (OODBMS) comprende e può implementare. La struttura delle librerie e delle applicazioni che utilizzano questa semantica dovrebbe essere portabile tra i vari OODBMS che supportano un dato oggetto MD. I componenti principali dell'architettura ODMG sono Object Model (OM), Object Definition Language (ODL), Object Query Language (OQL) e la capacità di collegarsi a C++, Java e Smalltalk.

Il modello dati oggetto secondo lo standard ODMG 2.0 è caratterizzato dalle seguenti proprietà:

Gli elementi costitutivi di base sono oggetti e letterali. Ogni oggetto ha un identificatore univoco. Un letterale non ha un proprio identificatore e non può esistere separatamente come oggetto. I letterali sono sempre incorporati negli oggetti e non possono essere referenziati individualmente;

Oggetti e letterali differiscono nel tipo. Ogni tipo ha il proprio dominio, condiviso da tutti gli oggetti e i letterali di questo tipo... I tipi possono anche avere comportamenti. Se un tipo ha un comportamento, tutti gli oggetti di quel tipo hanno lo stesso comportamento. In pratica, un tipo può essere la classe da cui viene creato l'oggetto, un'interfaccia o un semplice tipo di dati (come un intero). Un oggetto può essere pensato come un'istanza di un tipo;

Lo stato di un oggetto è determinato da un insieme di valori correnti implementati da un insieme di proprietà. Queste proprietà possono essere attributi di un oggetto o una relazione tra un oggetto e uno o più altri oggetti;

Il comportamento di un oggetto è determinato da un insieme di operazioni che possono essere eseguite su un oggetto o sull'oggetto stesso. Le operazioni possono avere un elenco di parametri di input e output, ognuno dei quali è di un tipo rigorosamente definito. Ogni operazione può anche restituire un risultato digitato;

Una definizione di database è archiviata in uno schema scritto in Object Definition Language (ODL). Il database memorizza gli oggetti in modo che possano essere condivisi da diversi utenti e applicazioni.

I DBMS basati su OOMD sono chiamati DBMS orientati agli oggetti (OODBMS). Questi DBMS sono indicati come DBMS di terza generazione * (* La storia dello sviluppo dei modelli di memorizzazione dei dati è spesso suddivisa in tre fasi (generazioni): la prima generazione (fine anni '60 - inizio anni '70) - gerarchica e modelli di rete; seconda generazione (ca. 1970-1980) - modello relazionale; terza generazione (anni '80 - primi anni 2000) - modelli orientati agli oggetti.).

Oggi i database orientati agli oggetti vengono utilizzati in varie organizzazioni per risolvere un'ampia gamma di attività. L'analisi e la generalizzazione dell'esperienza accumulata nel campo dei dati informatici ha permesso di identificare le applicazioni in cui è giustificato l'uso di database orientati agli oggetti:

L'applicazione è composta da un largo numero parti interagenti. Ognuno di loro ha il proprio comportamento, che dipende dal comportamento degli altri;

Il sistema deve gestire grandi quantità di dati non strutturati o complessi;

L'applicazione fornirà un accesso ai dati prevedibile, quindi la natura di navigazione dei database orientati agli oggetti non sarà svantaggio significativo;

La necessità di richieste ad hoc è limitata;

La struttura dei dati archiviati è di natura gerarchica o similare.

V attualmente ci sono molti DBMS orientati agli oggetti sul mercato del software. Tavolo 10.6 presenta alcuni di sistemi commerciali di questa classe.

Tabella 10.6

OODBMS commerciale moderno,

le loro aziende produttrici e i loro campi di applicazione

Uno di differenze fondamentali database di oggetti da relazionale è la capacità di creare e utilizzare nuovi tipi di dati. Caratteristica importante OODBMS è che la creazione di un nuovo tipo non richiede la modifica del core di base e si basa sui principi della programmazione orientata agli oggetti.

Il nucleo di OODBMS è ottimizzato per la manipolazione di oggetti. Le operazioni naturali per esso sono la memorizzazione nella cache degli oggetti, il mantenimento delle versioni degli oggetti, la condivisione dei diritti di accesso a siti specifici... Gli OODBMS sono caratterizzati da prestazioni più elevate sulle operazioni che richiedono l'accesso e il recupero di dati compressi in oggetti, rispetto ai DBMS relazionali, per i quali la necessità di recuperare dati connessi porta a operazioni interne aggiuntive.

Di grande importanza per OODBMS è la capacità di spostare oggetti da un database all'altro.

Durante la creazione varie applicazioni Sulla base di OODBMS, la struttura incorporata delle classi dell'uno o dell'altro DBMS non è di poca importanza. La libreria di classi di solito supporta non solo tutto tipi standard dati, ma anche un insieme esteso di dati multimediali e altri tipi di dati complessi, come video, suoni, sequenze di fotogrammi di animazione. In alcune librerie di classi OODBMS sono state create librerie che rendono possibile l'archiviazione e la ricerca full-text di informazioni documentarie (ad esempio Jasmine, ODB-Jupiter). Un esempio di una struttura di classe di base è mostrato in Fig. 10.17.

La posizione principale al suo interno è occupata dalla classe TOdbObject, che contiene tutto proprietà richieste e metodi per controllare l'accesso al database e per eseguire l'indicizzazione. Tutte le altre classi sovrascrivono i suoi metodi aggiungendo un controllo di convalida per il tipo che implementano e un indicizzatore specifico.

Come si vede dalla Fig. 10.17, ci sono varie classi nella struttura focalizzate sull'elaborazione delle informazioni documentali - TOdbText, TOdbDocument, TODBTextDocument, ecc. Ogni documento è rappresentato da un oggetto separato. In questo modo è garantita la conservazione naturale dei documenti. Uno di operazioni criticheè la ricerca di documenti su richiesta. Per la maggior parte delle classi, è implementata la capacità di cercare oggetti in base al valore di una chiave specifica. Per la classe TOdbText, implementata la capacità di formare query di ricerca da una frase scritta in linguaggio naturale.

La classe TOdbDocument è speciale, capace di contenere oggetti di diverso tipo. Consiste di campi, ognuno dei quali ha un nome ed è associato ad un oggetto di un certo tipo. La presenza di questa classe consente all'utente di espandere l'insieme dei tipi. Modificando l'oggetto contenitore (documento), è possibile impostare un determinato insieme di campi e ottenere così un nuovo tipo di Documento.

Sulla base di ODB-Jupiter, gli sviluppatori OODBMS hanno creato un sistema completo di recupero delle informazioni ODB-Text, che ha una struttura universale di dati archiviati e un potente motore di ricerca. Il sistema ODB-Text è uno strumento per l'elaborazione collettiva di documenti e il mantenimento di un archivio aziendale. Tra possibili applicazioni chiamiamo l'automazione della gestione documentale in un moderno ufficio, la costruzione di sistemi informativi e di riferimento (simili alle note banche dati legali), la manutenzione delle banche dati di rete, le anagrafiche, la bibliografia, ecc.

41. Caratteristiche del design dell'IS applicato. Fasi di sviluppo della PI. (Argomento 11, pp. 100-103).

11.1.3. Caratteristiche della progettazione di sistemi IC applicati

Quando si costruisce (sceglie, adatta) un sistema informativo, si possono usare due concetti principali, due approcci principali (il terzo concetto è una combinazione di essi):

1. orientamento ai problemi che devono essere risolti con l'aiuto di questo sistema informativo, ad es. approccio orientato al problema (o approccio induttivo);

2. orientamento verso la tecnologia disponibile (aggiornata) in un dato sistema, ambiente, ad es. approccio orientato alla tecnologia (o approccio deduttivo).

La scelta del concetto dipende da criteri, problemi, risorse strategici (tattici) e (o) a lungo termine (a breve termine).

Se inizialmente vengono studiate le possibilità della tecnologia disponibile e quindi vengono determinati i problemi reali che possono essere risolti con il loro aiuto, è necessario fare affidamento su un approccio orientato alla tecnologia.

Se prima vengono identificati i problemi reali e poi viene introdotta una tecnologia sufficiente a risolverli, allora è necessario affidarsi a un approccio orientato ai problemi.

Allo stesso tempo, entrambi i concetti di costruzione di un sistema informativo dipendono l'uno dall'altro: l'introduzione di nuove tecnologie modifica i problemi da risolvere e il cambiamento dei problemi da risolvere porta alla necessità di introdurre nuove tecnologie; entrambi influenzano le decisioni prese.

La progettazione del sistema (sviluppo) e l'utilizzo di qualsiasi sistema informativo applicato (aziendale) devono passare attraverso il seguente ciclo di vita del sistema informativo:

- analisi pre-progettazione (esperienza nella realizzazione di altri sistemi simili, prototipi, differenze e caratteristiche del sistema in sviluppo, ecc.), analisi delle manifestazioni esterne del sistema;

- analisi intrasistema, analisi interna (analisi dei sottosistemi di sistema);

- descrizione sistemica (morfologica) (presentazione) del sistema (descrizione dell'obiettivo sistemico, relazioni sistemiche e collegamenti con ambiente, altri sistemi e risorse di sistema- materiale, energetico, informativo, organizzativo, umano, spaziale e temporale);

- determinazione dei criteri di adeguatezza, efficienza e stabilità (affidabilità);

- descrizione funzionale dei sottosistemi del sistema (descrizione dei modelli, algoritmi per il funzionamento dei sottosistemi);

- prototipazione (descrizione del layout) del sistema, valutazione dell'interazione dei sottosistemi del sistema (sviluppo di un layout - implementazione dei sottosistemi con semplificazione descrizioni funzionali, procedure e approvazione dell'interazione di tali schemi al fine di soddisfare l'obiettivo del sistema), mentre è possibile utilizzare "schemi" di criteri di adeguatezza, sostenibilità, efficienza;

- "montaggio" e test del sistema - implementazione di veri e propri sottosistemi funzionali e criteri, valutazione del modello secondo i criteri formulati;

- il funzionamento del sistema;

- determinazione degli obiettivi per l'ulteriore sviluppo del sistema e delle sue applicazioni;

- manutenzione del sistema - chiarimento, modifica, ampliamento delle capacità del sistema nelle modalità del suo funzionamento (con l'obiettivo della sua evoluzione).

Queste fasi sono fondamentali per la reingegnerizzazione dei sistemi informativi.

Lo sviluppo di un sistema informativo aziendale, di regola, viene effettuato per un'impresa molto specifica. Le specificità dell'attività in oggetto dell'impresa influenzeranno senza dubbio la struttura del sistema informativo. Ma allo stesso tempo, le strutture delle diverse imprese sono generalmente simili tra loro. Ogni organizzazione, indipendentemente dal tipo di attività, è costituita da una serie di divisioni che svolgono direttamente l'uno o l'altro tipo di attività aziendale. E questa situazione è vera per quasi tutte le organizzazioni, indipendentemente dal tipo di attività in cui sono impegnate.

Pertanto, qualsiasi organizzazione può essere considerata come un insieme di elementi interagenti (divisioni), ognuno dei quali può avere una propria struttura piuttosto complessa. Anche i rapporti tra i dipartimenti sono piuttosto complessi. In generale, esistono tre tipi di collegamenti tra le divisioni dell'impresa:

Connessioni funzionali: ogni reparto esegue determinati tipi di lavoro all'interno di un singolo processo aziendale;

Comunicazioni informative - i reparti si scambiano informazioni (documenti, fax, ordini scritti e orali, ecc.);

Relazioni esterne: alcune unità interagiscono con sistemi esterni e la loro interazione può anche essere sia informativa che funzionale.

La generalità della struttura delle diverse imprese consente di formulare alcuni principi comuni di costruzione dei sistemi informativi aziendali.

In generale, il processo di sviluppo di un sistema informativo può essere considerato da due punti di vista:

Per tempo o per fasi ciclo vitale il sistema in via di sviluppo. V in questo caso viene considerata l'organizzazione dinamica del processo di sviluppo, descritta in termini di cicli, fasi, iterazioni e fasi.

Si sta sviluppando un sistema informativo aziendale come una sorta di progetto. Molte caratteristiche della gestione del progetto e delle fasi di sviluppo del progetto (fasi del ciclo di vita) sono generali, non dipendono solo dall'area tematica, ma anche dalla natura del progetto (non importa se si tratta di un progetto ingegneristico o economico) . Pertanto, ha senso considerare prima la serie problemi generali gestione del progetto.

Un progetto è un cambiamento intenzionale e limitato nel tempo di un sistema separato con obiettivi inizialmente chiaramente definiti, il cui raggiungimento determina il completamento del progetto, nonché con requisiti stabiliti per tempistiche, risultati, rischio, ambito di spesa dei fondi e risorse e per la struttura organizzativa.

Solitamente per un concetto complesso (che, in particolare, è il concetto di progetto) è difficile dare una formulazione univoca che copra integralmente tutte le caratteristiche del concetto che si sta introducendo. Pertanto, la definizione data non pretende di essere univoca e completa.

Il seguente principale caratteristiche progetto come oggetto di gestione:

La variabilità è un trasferimento intenzionale di un sistema da uno esistente a un certo

lo stato desiderato, descritto in termini di obiettivi del progetto;

La limitazione dell'obiettivo finale;

Durata limitata;

Budget limitato;

Risorse limitate richieste;

Novità per l'impresa per la quale si sta realizzando il progetto;

Complessità: la presenza di un gran numero di fattori che influenzano direttamente o indirettamente l'avanzamento e i risultati del progetto;

legale e supporto organizzativo- creazione di una struttura organizzativa specifica per la durata del progetto.

L'efficienza del lavoro si ottiene gestendo il processo di implementazione del progetto, che garantisce l'allocazione delle risorse, il coordinamento della sequenza di lavoro e la compensazione delle influenze di disturbo interne ed esterne.

Dal punto di vista della teoria dei sistemi di controllo, il progetto come oggetto di controllo deve essere osservabile e controllabile, cioè si distinguono alcune caratteristiche per cui è possibile monitorare costantemente l'andamento del progetto (proprietà di osservabilità) . Inoltre, sono richiesti meccanismi di influenza tempestiva sul corso dell'attuazione del progetto (proprietà di controllabilità).

La proprietà di controllabilità è particolarmente importante in condizioni di incertezza e variabilità dell'area disciplinare, che spesso accompagnano progetti per lo sviluppo di sistemi informativi.

Ogni progetto, indipendentemente dalla complessità e dalla mole di lavoro richiesta per la sua attuazione, attraversa determinati stati nel suo sviluppo: da uno stato in cui "il progetto non c'è ancora" a uno stato in cui "il progetto non c'è più". L'insieme delle fasi di sviluppo dall'emergere di un'idea al completamento completo del progetto è solitamente suddiviso in fasi (fasi, fasi).

Esistono alcune differenze nel determinare il numero di fasi e il loro contenuto, poiché queste caratteristiche dipendono in gran parte dalle condizioni per l'attuazione di un particolare progetto e dall'esperienza dei principali partecipanti. Tuttavia, la logica e il contenuto principale del processo di sviluppo del sistema informativo sono nella quasi totalità dei casi gli stessi.

Si possono distinguere le seguenti fasi di sviluppo del sistema informativo:

Formazione del concetto;

Sviluppo di specifiche tecniche;

Design;

Produzione;

Mettere in funzione il sistema.

Consideriamo ciascuno di essi in modo più dettagliato. La seconda e parzialmente la terza fase sono solitamente chiamate fasi di progettazione dei sistemi e le ultime due (a volte include la fase di progettazione) - le fasi di implementazione.

Fase concettuale

Formazione dell'idea, definizione degli obiettivi;

Formazione di un team di progetto chiave;

Studiare la motivazione e le esigenze del cliente e degli altri partecipanti;

Raccolta di dati di base e analisi stato esistente;

Determinazione dei requisiti e delle restrizioni di base, delle risorse materiali, finanziarie e lavorative richieste;

Valutazione comparativa delle alternative;

Presentazione delle proposte, loro esame e approvazione.

Sviluppo di una proposta tecnica

Sviluppo del contenuto principale del progetto, la struttura di base del progetto;

Sviluppo e approvazione delle specifiche tecniche;

Pianificazione, scomposizione del modello strutturale di base del progetto;

Stima e budget del progetto, determinando la necessità di risorse;

Sviluppo di piani di calendario e orari di lavoro ampliati;

Firmare un contratto con un cliente;

Messa in opera dei mezzi di comunicazione dei partecipanti al progetto e controllo sullo stato di avanzamento dei lavori.

Design

In questa fase si determinano i sottosistemi, le loro interconnessioni, le più modi efficaci esecuzione del progetto e utilizzo delle risorse. Lavori tipici di questa fase:

Lavoro di progettazione di base;

Sviluppo del privato specifiche tecniche;

Design concettuale;

Stesura di specifiche tecniche e istruzioni;

Presentazione del progetto, perizia e approvazione.

Sviluppo di

In questa fase vengono eseguiti il ​​coordinamento e il controllo operativo del lavoro di progetto, i sottosistemi vengono prodotti, combinati e testati. Contenuto principale:

Realizzazione di lavori di sviluppo software;

Prepararsi all'implementazione del sistema;

Controllo e regolazione dei principali indicatori del progetto.

Messa in servizio del sistema

In questa fase si effettuano i test, si sperimenta il funzionamento dell'impianto in condizioni reali, sono in corso le trattative sui risultati del progetto e su eventuali nuovi contratti. Principali tipologie di lavoro:

Test complessi;

42. Il concetto di ciclo di vita della PI. (Tema 11, pp. 103-105).

Con un gran numero di progetti sperimentali (e persino di sistemi commerciali), non esiste un modello di dati orientato agli oggetti generalmente accettato, non perché non sia stato sviluppato un modello completo, ma perché non esiste un accordo generale sull'adozione di alcun modello. Esistono infatti problemi più specifici legati allo sviluppo di linguaggi dichiarativi di interrogazione, esecuzione e ottimizzazione di interrogazioni, formulazione e mantenimento di vincoli di integrità, sincronizzazione degli accessi e gestione delle transazioni, ecc.

Il modello orientato agli oggetti (Figura 3) consente di creare, archiviare e utilizzare informazioni sotto forma di oggetti. Qualsiasi oggetto alla sua creazione riceve un identificatore univoco generato dal sistema, che è associato all'oggetto per tutta la sua esistenza e non cambia quando cambia lo stato dell'oggetto.

figura 3. Modello di dati orientato agli oggetti

Ogni oggetto ha stato e comportamento. Lo stato di un oggetto è un insieme di valori per i suoi attributi. Il comportamento dell'oggetto è un insieme di metodi (codice di programma) che operano sullo stato dell'oggetto. Il valore di un attributo di un oggetto è anche un oggetto o un insieme di oggetti. Lo stato e il comportamento di un oggetto sono incapsulati in un oggetto; l'interazione degli oggetti si basa sulla trasmissione di messaggi e sull'esecuzione dei metodi corrispondenti.

Molti oggetti con lo stesso insieme di attributi e metodi formano una classe di oggetti. Un oggetto dovrebbe appartenere a una sola classe (se non si considera la possibilità di ereditarietà). È consentita la presenza di classi primitive predefinite, i cui oggetti-istanze non hanno attributi: interi, stringhe, ecc. Una classe i cui oggetti possono fungere da valori di un attributo di oggetti di un'altra classe è chiamata dominio di quell'attributo.

È consentito creare una nuova classe basata su una classe esistente - ereditarietà. In questo caso, la nuova classe, chiamata sottoclasse della classe esistente (superclasse), eredita tutti gli attributi ei metodi della superclasse. La sottoclasse può anche definire attributi e metodi aggiuntivi. Si distinguono i casi di eredità semplice e multipla. Nel primo caso una sottoclasse può essere definita solo sulla base di una superclasse, nel secondo caso possono essere presenti più superclassi. Se un linguaggio o un sistema supporta l'ereditarietà singola delle classi, l'insieme delle classi forma una gerarchia ad albero. Pur mantenendo l'ereditarietà multipla, le classi sono collegate in un grafo diretto con radice chiamato reticolo di classi. Si considera che un oggetto di una sottoclasse appartenga a qualsiasi superclasse di quella classe.

I database orientati agli oggetti sono più ampiamente utilizzati in aree quali sistemi di progettazione/produzione assistita da computer (CAD/CAM), sistemi sviluppo automatizzato software (CASE), sistema di gestione documentale composto, ad es. in aree non tradizionali per i database. Esempi di DBMS orientati agli oggetti sono POET, Jasmine, Versant, Iris, Orion.

2.2.4 modello di dati relazionali

Nel 1970, il matematico americano E.F. pubblicò un articolo rivoluzionario nei suoi contenuti, proponendo di utilizzare la teoria degli insiemi per l'elaborazione dei dati. Ha sostenuto che i dati dovrebbero essere legati secondo la sua relazione logica (ad esempio unione, intersezione), non puntatori fisici. Ha proposto un semplice modello di dati in cui tutti i dati sono tabulati con righe e colonne denominate in modo univoco. Queste tabelle sono chiamate relazioni e il modello è chiamato modello relazionale dati, costruito sul concetto di relazioni matematiche, ed è talvolta chiamato anche modello di Codd. Le proposte di Codd erano così efficaci per i sistemi di database che per questo modello gli è stato assegnato il prestigioso Premio Turing per i fondamenti teorici dell'informatica.

Nei database relazionali, tutti i dati sono archiviati in semplici tabelle, divise in righe (chiamate record) e colonne (chiamate campi), all'intersezione delle quali si trovano le informazioni sui dati. V vista generale questo può essere rappresentato come in fig. 4.

figura 4. Tabella database relazionale.

Ogni colonna ha il suo nome. Ad esempio, nella tabella "Merci in magazzino" (Fig. 5), i nomi dei campi sono i seguenti: identificatore, Prodotto, Nome del gruppo, Gruppo, unità di misura, Prezzo d'acquisto, Prezzo di vendita, Disponibilità in magazzino.

Riso. 5. Tabella "Merci in magazzino »

Tutti i valori in una colonna sono dello stesso tipo. Quindi i campi sono varie caratteristiche(a volte dicono - attributi) di un oggetto. I valori dei campi su una riga si riferiscono allo stesso oggetto e campi diversi differiscono nel nome.

Ciascun record è contraddistinto da una chiave record univoca, di due tipi: primaria e secondaria.

Chiave primariaÈ uno o più campi che identificano in modo univoco un record. Se la chiave primaria è composta da un campo, si chiama chiave semplice, se è composta da più campi, si chiama chiave composta.

Chiave secondariaÈ un campo il cui valore può essere ripetuto in più record del file, ovvero non è univoco.

Tasto esterno la tabella subordinata è la chiave secondaria di questa relazione, che, allo stesso tempo, funge da chiave primaria nella tabella principale. Se per il valore della chiave primaria è possibile trovare una sola istanza del record, per il valore della chiave esterna ce ne sono diverse (Fig. 6).

figura 6. Esempio di utilizzo di una chiave esterna

In genere, un database relazionale è costituito da più tabelle, poiché Non è possibile combinare in un'unica tabella tutte le informazioni necessarie ai dipendenti (utenti del database) di qualsiasi organizzazione per risolvere i problemi.

L'indicizzazione è un mezzo di accesso efficiente tramite chiave a un record di file. L'indicizzazione crea file aggiuntivo che contiene in modo ordinato tutti i valori chiave nel file di dati. Per ogni chiave, il file di indice contiene un puntatore alla voce del file di dati corrispondente. Un puntatore a un record nel file di dati accede direttamente a quel record.

Per lavorare con i database relazionali, il linguaggio di query strutturato (Structured Query Language - SQL) è attualmente comunemente utilizzato. È un linguaggio utilizzato per creare, modificare e manipolare i dati. SQL non lo è linguaggio algoritmico programmazione. È un linguaggio informativo-logico, si basa sull'algebra relazionale ed è diviso in tre parti:

· Operatori di definizione dei dati;

Operatori di manipolazione dei dati (Inserisci, Seleziona, Aggiorna, Elimina);

· Operatori di definizione di accesso ai dati.

Nel 1986, SQL è stato adottato come standard ANSI (American National Standards Institute) per i linguaggi dei database relazionali. Oggi questa base considerato uno standard per i moderni sistemi informativi.

Pertanto, la tabella è il tipo principale della struttura dati del modello relazionale. La struttura di una tabella è determinata da un insieme di colonne. Ogni riga della tabella contiene un valore nella colonna corrispondente. Non ci possono essere due righe identiche nella tabella, numero totale le linee non sono limitate. Una colonna è un elemento di dati, ogni colonna ha un nome. Uno o più attributi i cui valori identificano in modo univoco una riga della tabella è la chiave della tabella.

I vantaggi del modello relazionale sono:

Semplicità e facilità di comprensione utente finale- l'unica struttura informativa è la tabella;

Quando si progetta un database relazionale, vengono applicate regole rigide basate su apparati matematici;

Completa indipendenza dei dati. Quando si cambia la struttura, le modifiche che devono essere apportate in programmi applicativi ah, minimo;

Per costruire query e scrivere programmi applicativi, non è necessario conoscere l'organizzazione specifica del database nella memoria esterna.

Gli svantaggi del modello relazionale sono:

Velocità di accesso relativamente bassa e grande quantità di memoria esterna;

Difficoltà a comprendere la struttura dei dati a causa della comparsa di un gran numero di tabelle a causa della progettazione logica;

Non è sempre possibile rappresentare un'area tematica sotto forma di un insieme di tabelle.

I database relazionali sono attualmente i più diffusi. I modelli di rete e gerarchici sono considerati obsoleti, i modelli orientati agli oggetti non sono ancora standardizzati e diffusi.

Database orientato agli oggetti(OODB) è un database in cui i dati sono modellati sotto forma di oggetti, i loro attributi, metodi e classi.

I database orientati agli oggetti sono generalmente consigliati per quei casi in cui è richiesta un'elaborazione ad alte prestazioni di dati con una struttura complessa.

Il manifesto OODB propone le caratteristiche richieste che ogni OODB deve soddisfare. La loro scelta si basa su 2 criteri: il sistema deve essere orientato agli oggetti ed essere un database.

Caratteristiche obbligatorie

1. Supporto per oggetti complessi. Il sistema dovrebbe prevedere la possibilità di creare oggetti composti utilizzando i costruttori di oggetti composti. I costruttori di oggetti devono essere ortogonali, ovvero qualsiasi costruttore può essere applicato a qualsiasi oggetto.

2. Sostegno all'individualità degli oggetti. Tutti gli oggetti devono avere un identificatore univoco che non dipende dai valori dei loro attributi.

3. Supporto per l'incapsulamento. L'incapsulamento corretto si ottiene grazie al fatto che i programmatori hanno il diritto di accedere solo alla specifica dell'interfaccia dei metodi e che i dati e l'implementazione dei metodi sono nascosti all'interno degli oggetti.

4. Supporto per tipi e classi. L'OODB deve supportare almeno un concetto di distinzione tra tipi e classi. (Il termine "tipo" è più coerente con il concetto di tipo di dato astratto. Nei linguaggi di programmazione, una variabile viene dichiarata con un'indicazione del suo tipo. Il compilatore può utilizzare queste informazioni per controllare il operazioni variabili essere compatibile con il suo tipo, il che consente di garantire la correttezza del software. D'altra parte, una classe è una sorta di modello per la creazione di oggetti e fornisce metodi che possono essere applicati a questi oggetti. Pertanto, il concetto di "classe" è più un runtime piuttosto che un tempo di compilazione.)

5. Supporto per l'ereditarietà di tipi e classi dai loro antenati. Un sottotipo, o sottoclasse, deve ereditare attributi e metodi rispettivamente dal suo supertipo o superclasse.

6. Sovraccarico combinato con rilegatura completa. I metodi dovrebbero essere applicati a oggetti di tipo diverso. L'implementazione di un metodo deve dipendere dal tipo di oggetti a cui viene applicato il metodo. Per fornire questa funzionalità, l'associazione dei nomi dei metodi sul sistema non dovrebbe avvenire fino al momento dell'esecuzione del programma.

7. Completezza computazionale. Il linguaggio di manipolazione dei dati dovrebbe essere un linguaggio di programmazione generico.

8. L'insieme dei tipi di dati deve essere estensibile. L'utente deve disporre di un mezzo per creare nuovi tipi di dati basati su un insieme di valori predefiniti tipi di sistema... Inoltre, tra le modalità di utilizzo del sistema e tipi personalizzati non dovrebbero esserci differenze nei dati.

OO DBMS

Database orientati agli oggetti- banche dati in cui le informazioni sono presentate sotto forma di oggetti, come nei linguaggi di programmazione orientati agli oggetti.

Se utilizzare o meno i sistemi di gestione di database orientati agli oggetti (OODBMS) in progetti reali oggi? In quali casi dovrebbero essere utilizzati e in quali no?

Qui Benefici utilizzando OODBMS:

· Non vi è alcun problema di mancata corrispondenza tra il modello di dati nell'applicazione e il database (disadattamento di impedenza). Tutti i dati vengono archiviati nel database nella stessa forma del modello dell'applicazione.

· Non è necessario supportare separatamente il modello dati sul lato DBMS.

· Tutti gli oggetti a livello di origine dati sono fortemente tipizzati. Niente più nomi di colonne di stringhe! Il refactoring di un database orientato agli oggetti e del codice che funziona con esso è ora automatizzato, piuttosto che un processo noioso e noioso.

Standard ODMG

Primo manifesto formalmente era solo un articolo inviato a Conferenza sui database orientati agli oggetti e deduttivi da un gruppo di individui. Come puoi vedere nella sottosezione precedente, i requisiti del Manifesto erano emotivi piuttosto che esplicitamente specificati. Nel 1991 è stato formato il consorzio ODMG (poi questa sigla è stata divulgata come Gruppo di gestione del database degli oggetti, ma in seguito ha acquisito un'interpretazione più ampia - Gruppo di gestione dei dati degli oggetti). Il consorzio ODMG è strettamente correlato al consorzio molto più grande OMG ( Gruppo di gestione degli oggetti), costituita due anni prima. Il principale obiettivo originale di ODMG era sviluppare lo standard industriale per i database orientati agli oggetti ( modello generale). Il modello a oggetti di base OMG COM ( Modello a oggetti di base). Nella sua esistenza più che decennale, ODMG ha pubblicato tre versioni base standard, l'ultimo dei quali si chiama ODMG 3.0. sedici

È divertente che sebbene ODMG (secondo l'autore) abbia lasciato OMG, in l'anno scorso alcuni standard OMG si basano sul modello a oggetti ODMG. In particolare, la specifica del linguaggio OCL ( Linguaggio dei vincoli degli oggetti), che fa parte della specifica generale del linguaggio UML 1.4 (e UML 2.0). In questo articolo, non intendiamo condurre un confronto dettagliato degli approcci OMG e ODMG e indirizzare i lettori interessati a Enciclopedie di Kogalovsky e materiali dai siti web di questi consorzi. Ci limiteremo riepilogo le idee principali contenute nello standard ODMG-3.

Architettura ODMG

L'architettura ODMG proposta è mostrata in Fig. 2.1. Questa architettura definisce una modalità di archiviazione dei dati e diversi tipi di accesso dell'utente a questo "archivio dati" 17. Un singolo archivio dati è accessibile da un linguaggio di definizione dei dati, un linguaggio di query e un numero di linguaggi di manipolazione dei dati. 18 Nella fig. 2.1 ODL significa Linguaggio di definizione degli oggetti, OQL - Linguaggio di interrogazione degli oggetti e OML - Linguaggio di manipolazione degli oggetti.

Riso. 2.1. Architettura ODMG

Centrale per l'architettura è modello di dati, che rappresenta la struttura organizzativa in cui sono conservati tutti i dati gestiti dall'OODBMS. Il linguaggio di definizione degli oggetti, il linguaggio di query e i linguaggi di manipolazione sono progettati in modo tale che tutte le loro capacità si basino sul modello di dati. L'architettura consente una varietà di strutture di implementazione per l'archiviazione di dati modellati, ma un requisito importante è che tutto librerie software e tutti gli strumenti di supporto sono forniti in un framework orientato agli oggetti e devono essere mantenuti coerenti con i dati.

I componenti principali dell'architettura sono i seguenti.

• Modello dati oggetto. Tutti i dati archiviati da un OODBMS sono strutturati in termini di costrutti di modelli di dati. Il modello di dati definisce l'esatta semantica di tutti i concetti (vedi sotto per maggiori dettagli).

• Linguaggio di definizione dei dati (ODL). Gli schemi di database sono descritti in termini di linguaggio ODL, in cui i costrutti del modello di dati vengono istanziati sotto forma di linguaggio di definizione. ODL consente di descrivere uno schema come un insieme di interfacce di tipo oggetto, che include la descrizione delle proprietà del tipo e delle relazioni tra di esse, nonché i nomi delle operazioni ei relativi parametri. ODL non è un linguaggio di programmazione completo; i tipi devono essere implementati in uno dei linguaggi della categoria OML. Inoltre, ODL è virtuale linguaggio, nel senso che lo standard ODMG non richiede la sua implementazione in prodotti software OODBMS considerati conformi allo standard. È consentito a questi prodotti supportare linguaggi di definizione equivalenti che includono tutte le funzionalità di ODL, ma adattati alle specifiche di un sistema specifico. Tuttavia, la presenza della specifica del linguaggio ODL nello standard ODMG è importante perché il linguaggio specifica le proprietà del modello di dati.

• Object Query Language (ODL). Il linguaggio ha una sintassi simile alla sintassi linguaggio SQL ma si basa sulla semantica del modello a oggetti ODMG. Lo standard consente l'uso diretto di OQL e il suo inserimento in uno dei linguaggi della categoria OML.

Modello di dati relazionali

Quasi tutto sistemi moderni basato su relazionale(relazionale) modello di gestione del database. Nome relazionaleè connesso al fatto che ogni record in tale database contiene informazioni relative a un solo oggetto specifico.

V relazionale Tutti i dati elaborati nel DBMS sono presentati sotto forma di tabelle piatte. Le informazioni sugli oggetti di un certo tipo sono presentate in forma tabellare: le colonne della tabella contengono vari attributi degli oggetti e le righe vengono utilizzate per ridurre le descrizioni di tutti gli attributi a singole istanze di oggetti.

Il modello creato nella fase di modellazione infologica in più soddisfa i principi della relatività. Tuttavia, per convertire questo modello in un modello relazionale, è necessario eseguire una procedura chiamata normalizzazione.

La teoria della normalizzazione opera con cinque forme normali... Questi moduli sono progettati per ridurre la ridondanza delle informazioni, quindi ogni modulo normale successivo deve soddisfare i requisiti del precedente e di alcuni condizioni supplementari... Nella progettazione pratica di database, la quarta e la quinta forma generalmente non vengono utilizzate. Ci siamo limitati a considerare le prime quattro forme normali.

Introduciamo i concetti necessari per comprendere il processo di riduzione di un modello a uno schema relazionale.

Atteggiamento- astrazione dell'oggetto descritto come insieme delle sue proprietà. Durante la fase di progettazione infologica, abbiamo parlato dell'astrazione degli oggetti e assegnato loro alcune proprietà. Ora, con il design concettuale, passiamo al livello successivo di astrazione. In questa fase gli oggetti, in quanto tali, non esistono più. Operiamo con un insieme di proprietà che definiscono l'oggetto.

Istanza di relazione- un insieme di valori delle proprietà di un particolare oggetto.

Chiave primaria- un insieme di attributi identificativi, ad es. il valore di questi attributi è unico in questo rispetto... Non esistono due istanze di una relazione contenente lo stesso valore nella chiave primaria.

Attributo semplice- un attributo i cui valori sono indivisibili.

Attributo complesso- un attributo il cui valore è un insieme di valori di diversi varie proprietà oggetto o più valori della stessa proprietà.

Concetti di entità ..

Dominio

Il dominio è più specifico per i database, sebbene abbia alcune analogie con i sottotipi in alcuni linguaggi di programmazione. Nella sua forma più generale, un dominio è determinato specificando un certo tipo di dati di base, a cui appartengono gli elementi del dominio, e un arbitrario espressione booleana da applicare a un elemento del tipo di dati. Se questa espressione booleana restituisce true, l'elemento dati è un elemento di dominio.

L'interpretazione intuitiva più corretta della nozione di dominio è la comprensione di un dominio come un insieme potenziale ammissibile di valori di un dato tipo. Ad esempio, il dominio "Nomi" nel nostro esempio è definito su tipo di base stringhe di caratteri, ma i suoi valori possono includere solo quelle stringhe che possono rappresentare un nome (in particolare, tali stringhe non possono iniziare con un segno morbido).

Da notare anche il carico semantico del concetto di dominio: i dati sono considerati comparabili solo se appartengono allo stesso dominio. Nel nostro esempio i valori per i domini "Gap Numbers" e "Group Numbers" sono del tipo intero, ma non sono confrontabili. Si noti che la maggior parte dei DBMS relazionali non utilizza il concetto di dominio, sebbene Oracle V.7 lo supporti già.

Post-relazionalemodello

Il modello relazionale classico presuppone l'indivisibilità dei dati memorizzati nei campi dei record della tabella. Il modello post-relazionale è un modello relazionale esteso che rimuove il vincolo sull'indivisibilità dei dati. Il modello consente campi multivalore - campi i cui valori sono costituiti da sottovalori. Viene considerato l'insieme di valori per i campi multivalore tavolo autonomo incorporato nella tabella principale.

Nella fig. 2.6 utilizzando l'esempio delle informazioni su fatture e merci per il confronto, viene mostrata la presentazione degli stessi dati utilizzando modelli relazionali (a) e post-relazionali (b). Si può notare dalla figura che, rispetto al modello relazionale, il modello post-relazionale memorizza i dati in modo più efficiente e durante l'elaborazione non è necessario eseguire l'operazione di unione dei dati di due tabelle.

Spese generali Spese generali

N fattura	Cliente		N fattura		Quantità

Sovraccarico

N fattura	Cliente		Quantità

Riso. 2.6. Strutture dati del modello relazionale e post-relazionale

Poiché il modello post-relazionale consente di archiviare dati non normalizzati in tabelle, sorge il problema di garantire l'integrità e la coerenza dei dati. Questo problema viene risolto includendo meccanismi appropriati nel DBMS.

Dignità il modello post-relazionale è la capacità di rappresentare un insieme di tabelle relazionali correlate da una tabella post-relazionale. Ciò garantisce un'elevata visibilità della presentazione delle informazioni e un aumento dell'efficienza della sua elaborazione.

Svantaggio modello post-relazionale è la complessità di risolvere il problema di garantire l'integrità e la coerenza dei dati archiviati.

Il modello di dati post-relazionale considerato è supportato dal DBMS uniVers. Altri DBMS basati sul modello dati post-relazionale includono anche i sistemi Bubba e Dasdb.

Modello multidimensionale

Un approccio multidimensionale alla presentazione dei dati è apparso quasi contemporaneamente a quello relazionale, ma ha cominciato ad acquisire interesse per i DBMS multidimensionali carattere di massa dalla metà degli anni '90. L'impulso nel 1993 è stato un articolo di E. Codd. Ha formulato 12 requisiti di base per i sistemi della classe OLAP (OnLine Analytical Processing), i più importanti dei quali sono legati alle possibilità di rappresentazione concettuale ed elaborazione di dati multidimensionali.

Nello sviluppo dei concetti di sistemi informativi si possono distinguere le seguenti due direzioni:

Sistemi di elaborazione online (transazionali);

Sistemi di elaborazione analitica (sistemi di supporto alle decisioni).

I DBMS relazionali erano destinati ai sistemi informativi per l'elaborazione delle informazioni on-line e sono molto efficaci in questo settore. Nei sistemi di elaborazione analitica, si sono dimostrati un po' goffi e non abbastanza flessibili. I DBMS multidimensionali sono più efficienti qui.

I DBMS multidimensionali sono DBMS altamente specializzati progettati per l'elaborazione analitica interattiva delle informazioni. I concetti di base utilizzati in questi DBMS sono: aggregabilità, storicità e prevedibilità.

Aggregabilità dati significa considerare l'informazione a vari livelli della sua generalizzazione. V sistemi di informazione il grado di dettaglio nella presentazione delle informazioni per l'utente dipende dal suo livello: analista, utente, manager, manager.

Storicità dati implica garantire un alto livello di dati statici stessi e le loro relazioni, nonché l'obbligo di legare i dati al tempo.

Prevedibilità i dati implicano l'impostazione di funzioni di previsione e la loro applicazione a diversi intervalli di tempo.

La multidimensionalità del modello dei dati non significa la multidimensionalità di visualizzazione dei dati digitali, ma la rappresentazione logica multidimensionale della struttura dell'informazione nella descrizione e nelle operazioni di manipolazione dei dati.

Rispetto al modello relazionale, l'organizzazione dei dati multidimensionali ha una maggiore visibilità e contenuto informativo. Per l'illustrazione in fig. 2.7 mostra le rappresentazioni relazionali (a) e multidimensionali (b) degli stessi dati sul volume delle vendite di auto.

Concetti di base dei modelli dati multidimensionali: dimensione e cella.

MisurazioneÈ un insieme di dati dello stesso tipo che forma una delle facce dell'ipercubo. In un modello multidimensionale, le dimensioni fungono da indici per identificare valori specifici nelle celle di un ipercubo.

Cellula Campo il cui valore è determinato in modo univoco da un insieme fisso di dimensioni. Il tipo di campo è spesso definito come numerico. A seconda di come si formano i valori di una determinata cella, può essere una variabile (i valori cambiano e possono essere caricati da un'origine dati esterna o generati a livello di codice) o una formula (valori, come le celle della formula fogli di calcolo, sono calcolati secondo formule predeterminate).

Riso. 2.7. relazionale e rappresentazione multidimensionale dati

Nell'esempio di Fig. 2,7 b ogni valore di cella Volume delle vendite determinato in modo univoco dalla combinazione della dimensione temporale Mese di vendita e modello di auto. In pratica, spesso sono necessarie più misurazioni. Un esempio di un modello di dati 3D è mostrato in Fig. 2.8.

Riso. 2.8. Esempio di modello 3D

Nei DBMS multidimensionali esistenti vengono utilizzati due principali schemi di organizzazione dei dati: ipercubico e policubico.

V policubica Lo schema presuppone che nel database possano essere definiti più ipercubi con dimensioni diverse e con dimensioni diverse come facce. Un esempio di sistema che supporta una versione polycubic del database è il server Oracle Server espresso.

quando ipercubica il diagramma presuppone che tutte le celle siano definite dallo stesso insieme di misurazioni. Ciò significa che se ci sono più ipercubi nel database, hanno tutti la stessa dimensione e coincidono.

Il principale dignità modello di dati multidimensionali è la convenienza e l'efficienza dell'elaborazione analitica di grandi quantità di dati relativi al tempo.

Svantaggio modello di dati multidimensionali è la sua ingombro per i compiti più semplici di ordinaria elaborazione delle informazioni operative.

Esempi di sistemi che supportano modelli di dati multidimensionali sono Essbase, Media Multi - matrix, Oracle Express Server, Cache. Esistono prodotti software, ad esempio Media/MR, che consentono di lavorare con database multidimensionali e relazionali allo stesso tempo.

Modello orientato agli oggetti

Nel modello orientato agli oggetti, quando si presentano i dati, è possibile identificare i singoli record del database. Le relazioni vengono stabilite tra i record e le loro funzioni di elaborazione utilizzando meccanismi simili a quelli dei linguaggi di programmazione orientati agli oggetti.

Il modello orientato agli oggetti standardizzato è descritto nelle raccomandazioni dello standard ODMG-93 (Object Database Management Group).

Consideriamo un modello semplificato di un database orientato agli oggetti. La struttura di un database orientato agli oggetti è rappresentata graficamente sotto forma di albero, i cui nodi sono oggetti. Le proprietà degli oggetti sono descritte da un tipo standard o costruito dall'utente (definito come classe). Il valore di una proprietà di tipo class è un oggetto che è un'istanza della classe corrispondente. Ogni istanza di una classe è considerata un discendente dell'oggetto in cui è definita come proprietà. Un oggetto istanza di una classe appartiene alla sua classe e ha un solo genitore. Le relazioni generiche nel database formano una gerarchia coerente di oggetti. Un esempio della struttura logica di un database di biblioteconomia orientato agli oggetti è mostrato in Fig. 2.9. Ecco un oggetto di tipo Bibliotecaè il genitore di oggetti istanza di classe Abbonato, Catalogare e emissione... Vari oggetti di tipo libri ma possono avere uno o più genitori. Oggetti di tipo Libro che hanno lo stesso genitore devono differire almeno per il numero di inventario (unico per ogni copia del libro), ma hanno gli stessi valori di proprietà è B n, udk, nomi e e autore.

La struttura logica di un database orientato agli oggetti è esteriormente simile alla struttura di un database gerarchico. La principale differenza tra i due sono i metodi di manipolazione dei dati.

Per eseguire azioni sui dati nel modello di database considerato, vengono utilizzate operazioni logiche, rafforzate da meccanismi di incapsulamento, ereditarietà e polimorfismo orientati agli oggetti.

incapsulamento limita l'ambito del nome della proprietà ai limiti dell'oggetto in cui è definito. Quindi, se un oggetto di tipo Catalogare aggiungi una proprietà che imposta il numero di telefono dell'autore del libro e ha un nome telefono, quindi otterremo proprietà con lo stesso nome per gli oggetti Abbonato e Catalogare... Il significato di tale proprietà sarà determinato dall'oggetto in cui è incapsulata.

Eredità al contrario, estende l'ambito della proprietà a tutti i discendenti dell'oggetto. Quindi, tutti gli oggetti di tipo Libro che sono discendenti di un oggetto di tipo Catalogare, puoi assegnare proprietà all'oggetto genitore: isbn, udk, titolo e autore... Se è necessario estendere l'azione del meccanismo di ereditarietà a oggetti che non sono parenti immediati (ad esempio, tra due discendenti dello stesso genitore), allora viene definita una proprietà astratta del tipo nel loro antenato comune addominali... Quindi, la definizione di proprietà astratte biglietto e Camera nella struttura Biblioteca fa sì che queste proprietà vengano ereditate da tutti gli oggetti figlio Abbonato, Libro e di emissione un. Non è un caso che i valori dell'immobile biglietto classi Abbonato e emissione mostrato in Fig. 2.9 sono gli stessi - 00015.

Polimorfismo nei linguaggi di programmazione orientati agli oggetti, significa la capacità dello stesso codice di programma di lavorare con diversi tipi di dati. In altre parole, significa che è possibile avere metodi (procedure o funzioni) con gli stessi nomi in oggetti di tipo diverso. Durante l'esecuzione di un programma oggetto, gli stessi metodi operano su oggetti diversi a seconda del tipo di argomento. Per quanto riguarda l'esempio in esame, polimorfismo significa che gli oggetti della classe Libro avere genitori diversi dalla classe Catalogare, può avere un diverso insieme di proprietà. Pertanto, programmi per lavorare con oggetti della classe Libro può contenere codice polimorfico.

La ricerca in un database orientato agli oggetti consiste nel trovare la somiglianza tra l'oggetto, specificato dall'utente, e gli oggetti memorizzati nel database.

Riso. 2.9. La struttura logica del database della biblioteconomia

Il principale dignità modello di dati orientato agli oggetti rispetto al relazionale è la capacità di visualizzare informazioni su relazioni complesse di oggetti. Il modello dati orientato agli oggetti consente di identificare un singolo record del database e definire le funzioni della loro elaborazione.

Svantaggi il modello a oggetti è caratterizzato da elevata complessità concettuale, disagi nell'elaborazione dei dati e bassa velocità di interrogazione.

I DBMS orientati agli oggetti includono POET, Jasmine, Versant, O 2, ODB - Jupiter, Iris, Orion, Postgres.