Modello di dati orientato agli oggetti

Il modello dati orientato agli oggetti è un'estensione delle disposizioni della programmazione orientata agli oggetti (mentre il modello relazionale nasce sulla base della teoria degli insiemi, proprio come modello dati). Lo standard ODMG-93 (Object DataBase Management Group) è stato sviluppato dal Object-Oriented Database Management Group. Questo standard non è stato ancora completamente implementato.

La struttura di un database orientato agli oggetti è rappresentata graficamente sotto forma di albero, i cui nodi sono oggetti. La struttura visibile di un oggetto è determinata dalle proprietà della sua classe. Classe include oggetti, mentre la struttura e il comportamento degli oggetti della stessa classe sono gli stessi. Ogni oggetto, ovvero un'istanza di una classe, è considerato un discendente dell'oggetto in cui è definito come proprietà. Proprietà dell'oggetto- un tipo standard, ad esempio stringa, o una classe di tipi costruita dall'utente. Il comportamento degli oggetti viene impostato utilizzando i metodi. MetodoÈ un'operazione che può essere applicata a un oggetto.

Si consideri ad esempio il database "LIBRARY" (Fig.4.4). Per ogni oggetto sono definite le proprietà, i loro tipi e valori. Nel DB:

"LIBRARY" - genitore (antenato) per "SUBSCRIPTION", "CATALOG", "ISSUE";

"CATALOGO" è il genitore per "BOOK".

"LIBRO" - oggetti diversi possono avere lo stesso genitore o genitori diversi. Se lo stesso genitore (un autore), i numeri di inventario sono diversi, ma isbn, UDC, titolo e autore sono gli stessi.

La struttura logica di un database orientato agli oggetti è simile a quella gerarchica, la differenza principale è nei metodi di manipolazione dei dati. Sopra il database è possibile eseguire azioni come operazioni logiche, potenziate da metodi 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 la proprietà viene aggiunta al "CATALOGO" telefono l'autore del libro, poi ottenuto con le stesse modalità in “ABBONAMENTO” e “CATALOGO”. Il significato della proprietà sarà determinato dall'oggetto in cui è incapsulata.

Eredità al contrario, estende l'ambito della proprietà a tutti i discendenti dell'oggetto. Pertanto, a tutti gli oggetti del tipo "BOOK" che discendono dal "CATALOG" possono essere assegnate le proprietà del genitore isbn, UDC, nome e autore.

poliformismo indica la capacità dello stesso codice di programma di lavorare con diversi tipi di dati. In altre parole, significa che è consentito in oggetti di tipo diverso avere metodi - procedure e 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. Per il database "LIBRARY", ciò significa che gli oggetti della classe "BOOK" aventi genitori diversi dalla classe "CATALOG" possono avere un diverso insieme di proprietà, ad es. i programmi per lavorare con un oggetto della classe "BOOK" possono contenere codice polimorfico. In una classe, un metodo non ha corpo, cioè non è definito quali azioni specifiche dovrebbe eseguire. Ogni sottoclasse esegue le operazioni richieste. L'incapsulamento nasconde i dettagli di implementazione da tutti gli oggetti al di fuori della gerarchia data.

I vantaggi del modello orientato agli oggetti rispetto al modello relazionale sono la capacità di visualizzare informazioni su relazioni complesse di oggetti, l'assenza di limitazioni nelle strutture di archiviazione dei dati. Un database orientato agli oggetti può memorizzare non solo la struttura, ma anche gli aspetti comportamentali dei dati. Utilizzando l'approccio orientato agli oggetti, è possibile creare database anche con grandi quantità di informazioni semantiche, come multimediali e specializzate per aree tematiche specifiche (geografiche, design, ecc.).

Gli svantaggi di questo approccio includono un'elevata complessità concettuale, inconvenienti nell'elaborazione dei dati e bassa velocità di esecuzione delle query.

Negli anni '90 sono stati creati prototipi di database operativi orientati agli oggetti. Questi sono POET (POET SoftWare), JASMINE (COMPUTER ASSOCIATES), IRIS, ORION, POSTGRES.

Argomento 5

Approccio relazionale nella costruzione di un modello informativo-logico: concetti di base

Modello relazionale dei dati. Concetti basilari

Come notato nella sezione della lezione precedente, il modello relazionale è attualmente uno dei modelli più comuni nel mercato dei database. Questo modello si basa su un insieme di tabelle interconnesse (relazioni).

Le principali idee teoriche del modello relazionale sono state presentate nei lavori sulla teoria delle relazioni del logico americano Charles Souders Peirce (1839-1914) e del logico tedesco Ernst Schroeder (1841-1902), nonché del matematico americano Edgar Codd .

Nei lavori di Peirce e Schroeder, è stato dimostrato che l'insieme delle relazioni è chiuso sotto alcune operazioni speciali che insieme formano un'algebra astratta. Questa importantissima proprietà delle relazioni è stata utilizzata nel modello relazionale per sviluppare un linguaggio di manipolazione dei dati.

Nel 1970 apparve un articolo di E. Codd sulla presentazione dei dati organizzati in tabelle bidimensionali, chiamate relazioni. Codd è stato il primo ad introdurre i concetti base ei limiti del modello relazionale come base per l'archiviazione dei dati, e ha mostrato la possibilità di elaborazione dei dati utilizzando operazioni tradizionali su insiemi e operazioni relazionali speciali introdotte.

I concetti base del modello relazionale sono riportati in tabella. 3.1.

Gli oggetti del modello relazionale sono principalmente tabelle (relazioni). L'integrità dei dati è garantita da chiavi esterne e primarie (vedi p. "Integrità dei dati relazionali").

Gli operatori nel modello relazionale sono un insieme di istruzioni che recuperano e manipolano i dati.

Tabella 5.1. Elementi del modello relazionale

Termine del modello relazionale	Descrizione
Banca dati (DB)	Un insieme di tabelle e altri oggetti necessari per rappresentare in modo astratto l'area tematica selezionata
Schema DB	Un insieme di intestazioni di tabella che sono correlate tra loro
Atteggiamento	Tabella: un insieme di oggetti del mondo reale, caratterizzati da proprietà e caratteristiche comuni (campi della tabella)
Intestazione relazione	Intestazione tabella: i nomi dei campi (colonne) della tabella
Corpo di relazione	Corpo della tabella: una raccolta di valori per tutti gli oggetti nel mondo reale, che possono essere rappresentati come record di tabella (righe di tabella)
Diagramma di relazione	Riga delle intestazioni di colonna della tabella (tabella "intestazione")
Attributo di relazione	Nome colonna tabella (campo tabella)
Tupla di relazione	Table Row (Record) - Una rappresentazione univoca di un oggetto del mondo reale creato utilizzando i valori dei campi della tabella
Dominio	Molti valori di attributo validi
Valore attributo	Valore del campo nel record (tupla)
Chiave primaria	Uno o più (nel caso di una chiave composta) attributi che definiscono in modo univoco il valore della tupla (il valore della riga della tabella)
Tasto esterno	Un attributo di tabella i cui valori corrispondono ai valori della chiave primaria in un'altra tabella correlata (genitore, primaria). Una chiave esterna può essere costituita da uno o più attributi (chiave esterna composita). Se il numero di attributi della chiave esterna è inferiore al numero di attributi della chiave primaria corrispondente, allora si parla di chiave esterna troncata (parziale)
Il grado (arietà) della relazione	Numero di colonne della tabella
Il potere della relazione	Numero di righe (tuple) della tabella
Istanza di relazione	L'insieme di record (tuple) per una determinata tabella (relazione). L'istanza può cambiare nel tempo. Poiché un database ordinario attualmente funziona con una sola versione della relazione, tale istanza della relazione viene chiamata quella corrente.
Tipo di dati	Tipo di valore degli elementi della tabella
relazione di base	Relazione contenente una o più colonne che caratterizzano le proprietà dell'oggetto, oltre alla chiave primaria
Rapporto derivato	Non è una relazione di base, ad es. non caratterizza le proprietà dell'oggetto e viene utilizzato per fornire collegamenti tra altre tabelle, potrebbe non contenere una chiave primaria. Se viene specificata una chiave primaria, è costituita da chiavi esterne associate alle chiavi primarie della relazione sottostante
Connessione	Stabilisce una relazione tra i valori corrispondenti nei campi chiave: la chiave primaria di una tabella e la chiave esterna di un'altra
Relazione uno a uno (1: 1)	Quando si utilizza questo tipo di relazione, un record in una tabella può avere al massimo un record associato in un'altra tabella. In entrambe le tabelle, i campi chiave devono essere primari. Utilizzato per suddividere tabelle con più campi o per la protezione dei dati su richiesta
Relazione uno a molti (1: M)	Quando si utilizza questo tipo di relazione, ogni record di una tabella può corrispondere a più record della seconda, ma ogni record della seconda tabella corrisponde a un solo record della prima tabella. La chiave primaria deve essere specificata nella prima tabella e la chiave esterna nella seconda.
Relazione molti a molti (N: M)	Con questo tipo di relazione, un record della prima tabella può corrispondere a più record della seconda tabella, ma un record della seconda tabella può corrispondere a più record della prima. L'unicità delle chiavi per tali tabelle non è richiesta. Nel processo di progettazione di uno schema di database, tali collegamenti vengono trasformati. Per fare ciò, è necessario introdurre una relazione ausiliaria che consenta di sostituire la relazione molti a molti con due relazioni uno a molti.

La struttura dati del modello relazionale assume la rappresentazione dell'area tematica del problema in esame come un insieme di relazioni interrelate.

In ogni relazione, una relazione può fungere da principale (base, genitore) e l'altra da subordinata (derivata, figlia). Per mantenere questi collegamenti, entrambe le relazioni devono contenere un insieme di attributi con cui sono correlate: nella relazione principale, questa è la chiave primaria della relazione (identifica in modo univoco la tupla della relazione principale); la relazione subordinata deve avere un insieme di attributi corrispondenti alla chiave primaria della relazione principale. Qui, questo insieme di attributi è già una chiave secondaria o una chiave esterna, ad es. definisce l'insieme di tuple della relazione derivata associata ad una singola tupla della relazione di base.

Si formano molte tabelle interconnesse schema db.

Quindi l'atteggiamento Rè una tabella bidimensionale contenente alcuni dati.

Matematicamente n relazione -aria RÈ un insieme di prodotti cartesiani D 1 × D 2 ×… × D n insiemi (domini) D 1, D 2, ..., D n(n≥1), non necessariamente diverso:

R D 1 × D 2 ×… × D n,

dove D 1 × D 2 ×… × D n- prodotto cartesiano completo, ovvero un insieme di tutte le possibili combinazioni di n elementi ciascuna, in cui ogni elemento è preso dal proprio dominio.

Dominioè un concetto semantico che può essere visto come un sottoinsieme dei valori di alcuni tipi di dati che hanno un significato specifico.

Proprietà del dominio:

Il dominio ha un nome univoco (all'interno del database),

Definito su un semplice tipo di dati o su un altro dominio,

Potrebbe avere una condizione booleana per descrivere un sottoinsieme dei dati consentiti per questo dominio,

Porta un certo carico semantico.

Il significato principale dei domini è che limitano i confronti: non puoi confrontare valori di domini diversi, anche se hanno lo stesso tipo di dati.

Attributo la relazione è una coppia della forma

<Имя_атрибута: Имя_домена>(o<ANNO DOMINI>).

I nomi degli attributi sono univoci all'interno di una relazione. Spesso i nomi degli attributi sono gli stessi dei nomi di dominio corrispondenti.

Una R, definita su più domini, ha due parti: un'intestazione e un corpo.

Intestazione relazione- un numero fisso di attributi di relazione che descrivono il prodotto cartesiano dei domini su cui è specificata la relazione:

(<LA 1: RE 1>, <LA 2: RE 2 >, …, <E n>).

L'intestazione è statica: non cambia mentre si lavora con il database.Se la relazione ha cambiato, aggiunto o rimosso attributi, si ottiene una relazione diversa. Anche con il nome salvato.

Corpo relazione contiene molte tuple di relazione.

Ogni corteoè un insieme di coppie della forma:

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

R(<A 1: Val 1>, <A 2: Val 2 >, …, <A n: Val n>).

Tale che il valore Val io attributo un io appartiene al dominio D io.

Il corpo di una relazione è un insieme di tuple, cioè un sottoinsieme del prodotto cartesiano dei domini. Quindi, il corpo di una relazione è esso stesso una relazione nel senso matematico della parola. Il corpo di una relazione può cambiare mentre si lavora con il database, poiché le tuple possono cambiare, essere aggiunte ed eliminate nel tempo.

La relazione è solitamente scritta come:

R(<LA 1: RE 1>, <LA 2: RE 2 >, …, <E n>),

o abbreviato: R(un 1, un 2, …, Un) o R.

Diagramma di relazioneè un insieme di intestazioni di relazione incluse nel database, ovvero un elenco di nomi di attributi di una data relazione con l'indicazione del dominio a cui appartengono:

S R =(un 1, un 2, …, Un), A io D io, io = 1, ..., n.

Se gli attributi prendono valori dallo stesso dominio, allora vengono chiamati θ-comparable, dove θ è l'insieme dei confronti validi specificati per questo dominio.

Ad esempio, se un dominio contiene dati numerici, allora tutte le operazioni di confronto sono valide per esso: θ == (=,<>,>=,<=,<,>). Tuttavia, anche per i domini contenenti dati di carattere, è possibile specificare non solo le operazioni di confronto di uguaglianza e disuguaglianza. Se viene specificato un ordinamento lessicografico per un dato dominio, allora ha anche un set completo di operazioni di confronto.

Gli schemi delle due relazioni sono chiamati equivalente se hanno lo stesso grado, e l'ordinamento dei nomi degli attributi negli schemi è possibile in modo che gli attributi comparabili siano negli stessi posti, cioè attributi che prendono valori dallo stesso dominio.

Pertanto, le seguenti condizioni sono soddisfatte per le relazioni equivalenti:

La presenza dello stesso numero di attributi;

La presenza di attributi con gli stessi nomi;

La presenza delle stesse stringhe nella relazione, dato che l'ordine degli attributi può differire;

Relazioni di questo tipo sono immagini diverse della stessa relazione.

Proprietà relazionali seguire direttamente dalla definizione di cui sopra di una relazione. Queste proprietà sono fondamentalmente la differenza tra le relazioni del modello di dati relazionali e le tabelle semplici:

L'unicità del nome della relazione. Il nome di una relazione deve essere diverso dai nomi di altre relazioni.

Unicità delle tuple. Non ci sono tuple identiche in una relazione. Infatti, il corpo di una relazione è un insieme di tuple e, come ogni insieme, non può contenere elementi indistinguibili. Le tabelle, a differenza delle relazioni, possono contenere le stesse righe. Ogni cella di una relazione contiene solo un valore atomico (indivisibile).

Tuple non ordinate. Le tuple non sono ordinate (dall'alto verso il basso), poiché il corpo della relazione è un insieme e l'insieme non è ordinato (per confronto, le righe nelle tabelle sono ordinate). La stessa relazione può essere rappresentata da tabelle diverse, in cui le righe sono in ordine diverso.

Disordine degli attributi. Gli attributi non sono ordinati (da sinistra a destra).

L'unicità del nome dell'attributo all'interno della relazione. Ogni attributo ha un nome univoco all'interno della relazione, il che significa che l'ordine degli attributi non ha importanza (per il confronto, le colonne nella tabella sono ordinate). Questa proprietà è in qualche modo diversa dalla definizione matematica della relazione. La stessa relazione può essere rappresentata da tabelle diverse in cui le colonne sono in ordine diverso.

Atomicità dei valori degli attributi. Tutti i valori degli attributi sono atomici. Ciò deriva dal fatto che gli attributi sottostanti hanno significati atomici, ovvero ogni triboot è associato a un intervallo di valori (un tipo elementare separato), i valori degli attributi sono presi dallo stesso dominio. Gli schemi di relazione e le tuple sono insiemi, non elenchi, quindi l'ordine in cui vengono presentati non ha importanza. Per fare un confronto, è possibile inserire varie informazioni nelle celle della tabella: array, strutture, altre tabelle, ecc.

Commento:

Dalle proprietà della relazione segue che non tutti la tabella può essere una relazione. Affinché una tabella possa definire una relazione, è necessario che la tabella abbia una struttura semplice (contiene solo righe e colonne e ogni riga deve avere lo stesso numero di campi), la tabella non deve avere righe identiche, nessuna colonna di la tabella deve contenere dati di un solo tipo, tutti i tipi di dati utilizzati devono essere semplici.

Va notato che il modello relazionale è un database sotto forma di un insieme di relazioni interconnesse, che vengono chiamate schema di database relazionale.

Concetti basilari

Definizione 1

Modello orientato agli oggetti la presentazione dei dati consente di identificare i singoli record del database.

I record del database e le loro funzioni di elaborazione sono collegati da meccanismi simili ai corrispondenti strumenti implementati nei linguaggi di programmazione orientati agli oggetti.

Definizione 2

Rappresentazione grafica una struttura di database orientata agli oggetti è un albero i cui nodi rappresentano oggetti.

Tipo standard (ad esempio, stringa - corda) o un tipo creato dall'utente ( classe), descrive proprietà dell'oggetto.

Nella Figura 1, l'oggetto LIBRARY è il genitore degli oggetti istanza DIRECT, SUBSCRIBER e REFERENCE. Diversi oggetti del tipo LIBRO possono avere uno o diversi genitori. Gli oggetti di tipo LIBRO che hanno lo stesso genitore devono avere almeno numeri di inventario diversi (unici per ogni copia del libro), ma gli stessi valori di proprietà autore, titolo, udk e isbn.

Le strutture logiche di un database orientato agli oggetti e di un database gerarchico sono superficialmente simili. Differiscono principalmente nei metodi di manipolazione dei dati.

Quando si eseguono azioni sui dati nel modello orientato agli oggetti, vengono utilizzate operazioni logiche, che sono rafforzate dall'incapsulamento, dall'ereditarietà e dal polimorfismo. Con alcune limitazioni, è possibile utilizzare operazioni simili ai comandi SQL (ad esempio, durante la creazione di un database).

Durante la creazione e la modifica del database, vengono eseguite la formazione automatica e il successivo adeguamento degli indici (tabelle indice), che contengono informazioni per un rapido recupero dei dati.

Definizione 3

Obbiettivo incapsulamenti- limitare l'ambito del nome della proprietà ai confini dell'oggetto in cui è definito.

Ad esempio, se viene aggiunta una proprietà all'oggetto DIRECTORY che imposta il numero di telefono dell'autore e ha il nome telefono, si otterranno le proprietà omonime per gli oggetti DIRECTORY e SUBSCRIBER. Il significato di una proprietà è determinato dall'oggetto in cui è incapsulata.

Definizione 4

Eredità, incapsulando inversamente, è responsabile della diffusione dell'ambito della proprietà rispetto a tutti i discendenti dell'oggetto.

Ad esempio, a tutti gli oggetti BOOK che sono discendenti dell'oggetto DIRECTORY possono essere assegnate le proprietà dell'oggetto padre: autore, titolo, udk e isbn.

Se è necessario estendere l'azione del meccanismo di ereditarietà ad oggetti che non sono parenti immediati (ad esempio due discendenti dello stesso genitore), viene definita una proprietà di tipo astratto nel loro antenato comune addominali.

Quindi le proprietà Camera e biglietto nell'oggetto LIBRARY vengono ereditati da tutti gli oggetti figlio REFERENCE, BOOK e SUBSCRIBER. Ecco perché i valori di questa proprietà delle classi SUBSCRIBER e OUTPUT sono gli stessi - 00015 (Figura 1).

Definizione 5

Polimorfismo consente allo stesso codice di programma di lavorare con diversi tipi di dati.

In altre parole, consente a oggetti di tipo diverso di avere metodi (funzioni o procedure) con gli stessi nomi.

Ricerca in un database orientato agli oggetti, serve a determinare la somiglianza tra l'oggetto che l'utente specifica e gli oggetti che sono memorizzati nel database.

Vantaggi e svantaggi del modello orientato agli oggetti

Il principale vantaggio il modello dati orientato agli oggetti, a differenza del modello relazionale, consiste nella capacità di visualizzare informazioni su relazioni complesse di oggetti. Il modello di dati considerato consente di definire un record di database separato e le funzioni della sua elaborazione.

A svantaggi Il modello orientato agli oggetti è caratterizzato da un'elevata complessità concettuale, un'elaborazione dei dati scomoda e una bassa velocità di esecuzione delle query.

Oggi tali sistemi sono abbastanza diffusi. Questi includono DBMS:

• Postgres,
• Orione,
• Iris,
• ODBGiove,
• Versante,
• Obiettività / DB,
• Negozio di oggetti,
• statico,
• Pietra preziosa
• G-Base.

Nell'OOMD, 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 ai corrispondenti strumenti nei linguaggi di programmazione orientati agli oggetti.

Il modello orientato agli oggetti standardizzato è descritto nelle raccomandazioni dello standard ODMG-93 (Object Database Management Group). Le raccomandazioni dell'ODMG-93 non sono ancora state pienamente attuate. Per illustrare le idee chiave, si consideri un modello un po' semplificato di un database orientato agli oggetti.

La struttura di un database orientato agli oggetti (OODB) è 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 coerente di oggetti.

Un esempio della struttura logica di una biblioteconomia OODB è mostrato in Fig. 2.8.

In questo caso, un oggetto di tipo LIBRARY è l'oggetto padre, ad esempio, delle classi SUBSCRIBER, DIRECTORY e OUTPUT. Diversi oggetti di tipo BOOK possono avere gli stessi genitori o diversi. Gli oggetti di tipo LIBRO aventi lo stesso genitore devono differire almeno per il numero di inventario (unico per ogni copia del libro), ma avere gli stessi valori di proprietà isbn, udk, nome e autore.

Riso. 2.8. La struttura logica del database della biblioteconomia

La struttura logica dell'OODB è esteriormente simile alla struttura dell'OODB. La principale differenza tra loro risiede nei 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. Operazioni simili ai comandi SQL possono essere utilizzate in misura limitata (ad esempio, per creare un database).

La creazione e la modifica del database è accompagnata dalla formazione automatica e dal successivo adeguamento di indici (tabelle indice) contenenti informazioni per un rapido reperimento dei dati.

Consideriamo brevemente i concetti di incapsulamento, ereditarietà e polimorfismo in relazione al modello di database orientato agli oggetti.

incapsulamento limita l'ambito del nome della proprietà ai limiti dell'oggetto in cui è definito. Quindi, se aggiungiamo una proprietà che imposta il numero di telefono dell'autore del libro e ha il nome telefono a un oggetto del tipo DIRECTORY, otterremo le 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, name 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 di tipo abs nel loro antenato comune. Quindi, la definizione delle proprietà astratte ticket e numero nell'oggetto LIBRARY porta all'ereditarietà di queste proprietà da parte di tutti gli oggetti figlio SUBSCRIBER, BOOK e REFERENCE. Non è un caso che i valori dell'immobile biglietto delle classi SUBSCRIBER e ISSUE mostrate in figura saranno le stesse - 00015.

Polimorfismo v 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. Applicato al nostro database orientato agli oggetti, il polimorfismo significa che gli oggetti della classe BOOK, che hanno 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 in OODB consiste nel trovare la somiglianza tra l'oggetto, specificato dall'utente, e gli oggetti memorizzati nel database. Un oggetto definito dall'utente chiamato oggetto di destinazione (una proprietà dell'oggetto ha un tipoobbiettivo), nel caso generale, può essere 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. 2.9.

Riso. 2.9. Frammento di un database con un oggetto di destinazione

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

Il principale svantaggi Gli OOMD sono un'elevata complessità concettuale, un inconveniente nell'elaborazione dei dati e una bassa velocità di query.

Negli anni '90 c'erano prototipi sperimentali di OODBMS. Attualmente esistono oltre 300 DBMS di questo tipo. Alcuni sistemi sono relativamente diffusi, ad esempio i seguenti DBMS: Cache (InterSystems), POET (POET Software), Jasmine (Computer Associates), Versant (Versant Technologies), O2 (Ardent Software), ODB-Jupiter (R&D center "Inteltek Plus") così come Iris, Orion e Postgres.

I vantaggi di OODB a lungo termine dovrebbero portare alla loro distribuzione molto ampia. Per fare ciò, è necessario prima risolvere i problemi di eliminazione delle carenze inerenti a OODB: aumentare la flessibilità della struttura del database, costruire un linguaggio di programmazione chiaro, elaborare la sintassi per l'analisi delle query, definire diversi metodi di accesso ai dati, lavorare risolvere i problemi di accesso simultaneo, definire l'enumerazione di dati complessi, elaborare la protezione e il ripristino dei dati. L'elenco delle attività che devono essere risolte può essere continuato.

Tuttavia, anche dopo aver risolto questi problemi, il passaggio a OODB sarà graduale e non molto rapido, poiché sarà difficile staccarsi dall'enorme numero di DBMS relazionali operativi per ragioni oggettive e soggettive. Rendere meno doloroso tale passaggio consentirà l'inclusione non solo dell'oggetto, ma anche della componente relazionale nell'OODBMS. Inoltre, MMD dovrebbe essere introdotto in OODBMS per la formazione di sistemi HD OLAP, che sono sempre più richiesti nella pratica.

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 software automatizzato;

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. Il MD che implementa questo concetto e si basa 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 articolo 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.

Importanti concetti OOP sono 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 si può dare la seguente catena: tutti i programmatori di un'impresa sono i suoi dipendenti, quindi ogni programmatore che è 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 un numero limitato di proprietà dalla sua superclasse.

Viene chiamata l'ereditarietà dell'istanza variabile eredità strutturale, ereditarietà del metodo - eredità comportamentale, e viene chiamata la possibilità di utilizzare lo stesso metodo per classi diverse, o meglio, applicare metodi diversi con lo stesso nome per classi diverse 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. Le caratteristiche generali di una classe sono descritte dai suoi attributi. I metodi delle classi di oggetti sono in qualche modo analoghi alle proprietà degli oggetti nel mondo reale. Ogni oggetto appartenente a una particolare 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 nel modello a oggetti vengono creati 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 relazione è 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à, OOMD può utilizzare una relazione di tipo "is" e una relazione di 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 HIGH PAID). 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.

I vincoli di integrità giocano un ruolo importante 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 è significativo 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 deve 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 letterali di quel 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 - primi anni '70) - i modelli gerarchici e di rete; la seconda generazione (ca. 1970-1980) - la modello relazionale; la terza generazione (anni '80 - primi anni 2000) - Object Oriented Models.).

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 applicazioni in cui è giustificato l'uso di database orientati agli oggetti:

L'applicazione è costituita da un gran numero di 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 prevedibile ai dati, quindi la natura di navigazione dei database orientati agli oggetti non sarà uno svantaggio significativo;

La necessità di richieste ad hoc è limitata;

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

Al momento, ci sono molti DBMS orientati agli oggetti sul mercato del software. Tavolo 10.6 presenta alcuni dei sistemi commerciali di questa classe.

Tabella 10.6

OODBMS commerciale moderno,

le loro aziende produttrici e i loro campi di applicazione

Una delle differenze fondamentali tra database a oggetti e database relazionali è la capacità di creare e utilizzare nuovi tipi di dati. Una caratteristica importante di 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 controllo delle versioni degli oggetti, la separazione dei diritti di accesso a oggetti 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 comporta operazioni interne aggiuntive.

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

Quando si creano varie applicazioni basate su OODBMS, è importante la struttura incorporata delle classi di un particolare DBMS. La libreria di classi supporta, di norma, non solo tutti i tipi di dati standard, ma anche un set esteso di tipi 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 consentono 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 in esso è occupata dalla classe TOdbObject, che contiene tutte le proprietà e i metodi necessari per controllare l'accesso al database ed 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. Una delle operazioni più importanti è la ricerca dei 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 possibilità di formare una query di ricerca per 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 le possibili applicazioni, citiamo l'automazione della gestione documentale in un moderno ufficio, la costruzione di sistemi informativi di riferimento (simili alle note banche dati legali), la manutenzione delle banche dati di rete, anagrafica personale, 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, è possibile utilizzare 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 del sistema e connessioni con l'ambiente, altri sistemi e risorse del 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 di sottosistemi con descrizioni funzionali semplificate, procedure e approvazione dell'interazione di questi layout al fine di soddisfare il sistema obiettivo), mentre è possibile utilizzare "schemi" di criteri di adeguatezza, stabilità, efficienza;

- "montaggio" e test del sistema - l'implementazione di sottosistemi e criteri funzionali a tutti gli effetti, la 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 del ciclo di vita del sistema in fase di sviluppo. In questo caso si considera 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 una serie di questioni generali di 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 tempi, risultati, rischio, possibilità di spendere 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.

Si possono distinguere le seguenti principali caratteristiche distintive del 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;

Supporto legale e 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: dallo stato in cui “il progetto non c'è ancora” allo 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 dello 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 orari e orari di lavoro allargati;

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 vengono determinati i sottosistemi, le loro interrelazioni e vengono selezionate le modalità più efficaci di esecuzione del progetto e di utilizzo delle risorse. Lavori tipici di questa fase:

Lavoro di progettazione di base;

Sviluppo di specifiche tecniche private;

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).

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. L'insieme di valori per i campi multivalore è considerato una tabella separata, incorporata 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

L'approccio multidimensionale alla presentazione dei dati è apparso quasi contemporaneamente a quello relazionale, ma l'interesse per i DBMS multidimensionali ha cominciato a prendere 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. Nei sistemi informativi, 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 delle formule nei fogli di calcolo, sono calcolati utilizzando formule predefinite).

Riso. 2.7. Rappresentazione dei dati relazionali e multidimensionali

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 è Oracle Express Server.

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à il 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 di 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.