Esempio di modello di dati orientato agli oggetti. Modello di database orientato agli oggetti. Supporto insufficiente per oggetti complessi

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 dall'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".

"BOOK" - 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 sono discendenti del "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 è ammissibile 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 DB "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 elaborare i 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, nonché la 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 interconnesse.

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 di 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;

Le 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 valori atomici, ovvero un intervallo di valori (un tipo elementare separato) è associato a ciascun tributo, 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 il confronto, nelle celle della tabella possono essere inserite varie informazioni: array, strutture, altre tabelle, ecc.

Commento:

Dalle proprietà della relazione segue che non tutti la tabella può essere una relazione. Affinché una certa 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 della 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 sono 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.

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.

Lo standard OOM è 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 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. Qui, 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 essere diversi, almeno nel numero di inventario (unico per ogni copia del libro), ma avere gli stessi valori di 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 in un database OOM, 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 successiva correzione di indici (tabelle indice) contenenti informazioni per un rapido reperimento dei 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 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 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. 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, un disagio nell'elaborazione dei dati e una bassa velocità di query.

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 " Merce". Oggetti della classe " Clienti»Sono clienti specifici; proprietà della classe: numero cliente, città nome cliente, stato, ecc. 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 " Merce". 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, l'esecuzione della stessa funzionalità richiede la scrittura di procedure in Visual Basic for Application (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.

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 come i sistemi di progettazione/produzione assistita da computer (CAD / CAM), i sistemi di sviluppo software assistito da computer (CASE), i sistemi di gestione dei documenti composti, 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 (relatio - relazione) e il modello è un modello di dati relazionale costruito sul concetto di relazioni matematiche e talvolta è anche chiamato modello Codd. Le proposte di Codd sono state così efficaci per i sistemi di database che per questo modello è stato insignito del 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. In termini generali, 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à di magazzino.

Riso. 5. Tabella "Merci in magazzino »

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

Ogni record è contraddistinto da una chiave record univoca, che sono 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, viene chiamata chiave semplice, se è composta da più campi, viene chiamata 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, allora 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 un file aggiuntivo che contiene tutti i valori chiave del file di dati in modo ordinato. 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, attualmente è comunemente utilizzato il linguaggio di query strutturato (Structured Query Language - SQL). È un linguaggio utilizzato per creare, modificare e manipolare i dati. SQL non è un linguaggio di programmazione algoritmico. È 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 questo database è 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, il numero totale di righe non è limitato. 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 da parte dell'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 la struttura cambia, le modifiche da apportare ai programmi applicativi sono minime;

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.

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.

Un 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 una 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. Qui, un oggetto di tipo Library è il genitore per gli oggetti di istanza delle classi Subscriber, Directory e Issuance. Oggetti Libro diversi possono avere genitori uguali 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, udc, titolo 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.

L'incapsulamento limita l'ambito di un nome di proprietà all'esterno 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 di tipo Catalogo, otteniamo le proprietà con lo stesso nome per gli oggetti Abbonato e Catalogo. Il significato di tale proprietà sarà determinato dall'oggetto in cui è incapsulata.

L'ereditarietà, d'altra parte, estende l'ambito della proprietà a tutti i discendenti dell'oggetto. Pertanto, a tutti gli oggetti di tipo Book che discendono da un oggetto di tipo Catalog possono essere assegnate le proprietà dell'oggetto padre: isbn, udk, titolo 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 del ticket e del numero delle proprietà astratte nell'oggetto Library porta all'ereditarietà di queste proprietà da parte di tutti gli oggetti figlio Subscriber, Book e Issue. Non è quindi un caso che i valori della proprietà ticket delle classi Abbonato ed Emittente riportati in Fig. 2.9 sono gli stessi - 00015.

Il 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 questo esempio, polimorfismo significa che gli oggetti della classe Book che hanno genitori diversi dalla classe Catalog possono avere un diverso insieme di proprietà. Pertanto, i programmi per lavorare con oggetti della classe Book possono 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 vantaggio del modello di dati orientato agli oggetti rispetto a quello relazionale è la capacità di visualizzare informazioni su relazioni complesse tra oggetti. Il modello dati orientato agli oggetti consente di identificare un singolo record di database e definire le funzioni della loro elaborazione.

Gli svantaggi del modello orientato agli oggetti sono l'elevata complessità concettuale, l'inconveniente nell'elaborazione dei dati e la bassa velocità di query.

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

Le banche dati nel loro insieme sono solitamente classificate in base a caratteristiche economiche e giuridiche.

Secondo i termini della fornitura di servizi, si distinguono banche libere e a pagamento, che a loro volta si dividono in commerciali e senza scopo di lucro (scientifiche, bibliotecarie o socialmente significative).

Secondo la forma di proprietà, i BND sono suddivisi in statali e non statali. In base al grado di accessibilità, si distinguono tra pubblico e con un numero limitato di utenti.

Altri tipi di classificazione sono associati ai singoli componenti del BnD.

1. Lo sviluppo delle banche dati si compone di 4 fasi:

Fase 1. Formazione e analisi dei requisiti di sistema:

Viene redatta una specifica di sistema, comprendente un elenco di compiti che devono essere risolti da BND;

Elenco degli utenti finali e loro funzioni;

Elenco dei requisiti per il database;

Viene redatto un diagramma di flusso del documento nell'organizzazione.

Fase 2. Progettazione concettuale: viene realizzato un modello informativo del sistema senza riferimento al tipo di computer e al tipo di software di sistema; viene costruito un modello di database infologico, che descrive in modo più completo l'area tematica in termini di utente.

Fase 3. Progettazione dell'implementazione: vengono selezionati un sistema informatico, un software di sistema e un DBMS; viene progettata la struttura dei dati e viene costruito un modello datalogico del database (schema del database), che è una descrizione della struttura logica del database nella lingua di uno specifico sistema di gestione del database selezionato.

Fase 4. Implementazione fisica, che include la creazione e il caricamento di dati in un database, lo sviluppo e il debug di programmi applicativi per lavorare con un database, la scrittura di documentazione. In questa fase viene costruito un modello fisico del database, che descrive i dispositivi di archiviazione utilizzati, le modalità di organizzazione fisica dei dati. La descrizione della struttura fisica di un database è chiamata schema di archiviazione. Attualmente si tende a ridurre questo tipo di lavoro.

2. I principali compiti risolti dal personale della banca dati

Lo staff di BND comprende vari specialisti: amministratori BND, analisti di sistema, programmatori di sistemi e applicazioni, operatori, specialisti in mezzi tecnici, marketing, ecc.

Elenchiamo le principali funzioni e compiti risolti dal personale durante lo sviluppo e il funzionamento del database:

1) analisi dell'area tematica (determinazione delle esigenze degli utenti finali, costruzione di un modello informativo dell'area tematica, identificazione dei vincoli di integrità);

2) progettare la struttura del database (determinare la composizione e la struttura dei file del database, descriverne lo schema nel linguaggio di descrizione dei dati);

3) impostazione dei vincoli di integrità del database;

4) caricamento e mantenimento del database (la manutenzione del database include la modifica, l'eliminazione e l'aggiunta di record); sviluppo della tecnologia di caricamento e manutenzione; sviluppo di moduli di inserimento dati; inserimento e controllo dei dati;

5) protezione dei dati (differenziazione degli utenti, selezione e verifica dei mezzi di protezione, registrazione dei tentativi di accesso non autorizzati);

6) garantire il ripristino del database;

7) analisi dell'efficienza BnD e sviluppo del sistema;

8) lavorare con gli utenti (raccolta risposte, formazione);

9) manutenzione del software di sistema (acquisizione, installazione e sviluppo);

10) lavoro organizzativo e metodologico (selezione dei metodi di progettazione e ammodernamento, pianificazione dello sviluppo di BND, sviluppo della documentazione).

3. Utenti di banche dati

Come ogni complesso software-organizzativo-tecnico, una banca dati esiste nel tempo e nello spazio. Ha fasi di sviluppo specifiche:

Design,

Implementazione,

Supporto,

Aggiornamento e sviluppo,

Riorganizzazione completa.

Ad ogni fase dell'esistenza, alla banca dati sono collegate diverse categorie di consumatori.

Utenti finali

Questa è la principale categoria di utenti i cui interessi sono legati alla banca dati. A seconda delle caratteristiche della banca dati creata, essa può sostanzialmente differire nella cerchia dei suoi utenti finali. Questi possono essere consumatori casuali che di volta in volta indirizzano il database al database dopo aver ricevuto alcune informazioni e possono essere utenti ordinari. I clienti occasionali possono essere visti come potenziali clienti dell'azienda, sfogliando un catalogo di prestazioni o servizi con una descrizione generale o dettagliata. I dipendenti che lavorano con programmi appositamente progettati per loro, che forniscono l'automazione delle loro azioni nell'esecuzione delle funzioni, possono essere utenti ordinari. Ad esempio, un amministratore che pianifica il lavoro di una divisione ausiliaria di un'azienda informatica ha un programma che lo aiuta a pianificare e organizzare gli ordini correnti secondo le istruzioni, monitorare l'andamento della loro produttività e organizzare gli accessori necessari per i nuovi ordini nel magazzino. La conoscenza principale e speciale che non dovrebbe essere richiesta agli utenti finali nel campo della lingua e della tecnologia informatica.

Amministratori di banche dati

Questo è un gruppo di utenti, che nella fase iniziale dello sviluppo della banca dati è responsabile della sua progettazione ottimale dal punto di vista del funzionamento simultaneo di un insieme di utenti finali, a supporto, la fase è responsabile del corretto funzionamento di questo stack di informazioni in modalità multiutente. Durante la fase di progettazione e riorganizzazione, questo gruppo è responsabile della capacità di riorganizzare correttamente lo stack senza modificarne o completarne la manutenzione continua.

Sviluppatori e amministratori di applicazioni

Si tratta di un gruppo di utenti che interviene durante la progettazione, creazione e riorganizzazione della banca dati. Gli amministratori delle applicazioni coordinano il lavoro degli sviluppatori sviluppando un'applicazione specifica o un gruppo di applicazioni, unite in un sottosistema funzionale. Gli sviluppatori di applicazioni specifiche lavorano con le informazioni del database necessarie per un'applicazione specifica.

Non tutte le banche dati hanno selezionato ogni tipo di utente. È noto che nello sviluppo di sistemi informativi che utilizzano un DBMS tabulare, l'amministratore della banca dati, l'amministratore dell'applicazione e lo sviluppatore spesso esistevano in una sola persona. Tuttavia, quando si creano database aziendali complessi e moderni che vengono utilizzati per automatizzare tutti o gran parte dei processi aziendali in una grande azienda o società, potrebbero esserci gruppi di amministratori delle applicazioni e dipartimenti di sviluppo. Le modalità operative più difficili sono assegnate al gruppo degli amministratori di database.

Consideriamoli in modo più dettagliato.

Parte del gruppo di amministratori BnD dovrebbe essere:

Commentatori di sistema;

Sviluppatori di strutture dati e aspetto relativo alla banca dati di supporto informativo;

Sviluppatori di processi tecnologici di elaborazione dati;

Programmatori di sistemi e applicazioni;

Società operative ed esperti nel servizio di riparazione.

La questione della banca dati commerciale svolge un ruolo importante nella vendita di esperti.

Le principali funzioni del gruppo di amministratori di DB

1. Ricerca dell'area dati: descrizione dell'area dati, confezionamento del testo dei vincoli di integrità, determinazione dello stato (disponibilità, riservatezza) delle informazioni, determinazione delle esigenze dei consumatori, determinazione della corrispondenza dei "consumatori dati", determinazione della volume delle caratteristiche del trattamento dei dati.

2. Sviluppo della struttura del database: la definizione della composizione e della struttura dei file del database e dei collegamenti intermedi, la scelta delle modalità di ottimizzazione dei dati e delle modalità di accesso alle informazioni, descrizione del database nel data description language (DLS) .

3. Impostazione dei vincoli di integrità nella descrizione della struttura del database e delle procedure di elaborazione del database:

Impostazione dei vincoli di integrità dichiarativa inerenti all'area dati;

Determinazione dei vincoli di integrità dinamica inerenti l'area dati nel corso della modifica delle informazioni memorizzate nel database;

La definizione dei vincoli di integrità è richiamata dalla struttura del database;

Sviluppo di procedure per mantenere l'integrità del database durante l'inserimento e la correzione dei dati;

Determinazione dei vincoli di integrità mediante il funzionamento parallelo dei consumatori in modalità multiutente.

4. Avvia il download e guida il database

Sviluppo di una tecnica per l'avvio del caricamento del database, che differirà dalla procedura per modificare e aggiungere dati con l'uso regolare del database;

Sviluppo di una tecnica per controllare i dati inseriti, lo stato reale dell'area dati. Gli oggetti reali dei modelli di database di alcune aree dati e la correlazione è intermedia, e al momento dell'inizio della riparazione corrente, questo modello deve corrispondere completamente allo stato degli oggetti dell'area dati ora per volta;

Secondo la tecnica sviluppata di avvio del caricamento del progetto del sistema, potrebbe essere necessario l'inizio dell'immissione dei dati.

5. Protezione dei dati

Definizione di un sistema di password, principi di targeting dei consumatori, creazione di gruppi di consumatori con diritti di accesso ai dati identici;

Sviluppo di principi per la protezione di determinati dati e oggetti di sviluppo; sviluppo di metodi specializzati per la codifica dell'informazione durante la sua circolazione nelle reti informative locali e globali;

Sviluppo di mezzi per fissare l'accesso ai dati e tentativi di violazione del sistema di sicurezza;

Testare il sistema di protezione;

Indagine sui casi di violazione del sistema di protezione e sviluppo di metodi dinamici per la protezione delle informazioni nel database.

6. Supporto per il ripristino del database

Sviluppo di principi organizzativi per l'archiviazione e il ripristino di database;

Sviluppo di software aggiuntivo e processi tecnologici per il ripristino del database dopo i guasti.

7. Indagine sulle chiamate ai consumatori di database: un insieme di statistiche sul simbolo delle richieste, il tempo per accendere le loro prestazioni, in conformità con i documenti di output richiesti

8. Indagine sull'efficienza del funzionamento di BnD:

Indagine sugli indici di funzionamento del BnD

Pianificazione della ristrutturazione (cambiamento strutturale) della banca dati e riorganizzazione della BND.

9. Lavorare con gli utenti finali:

Raccolta di informazioni sulla modifica dell'area dati;

Raccolta di informazioni sulla valutazione del lavoro BnD;

Formazione dei consumatori, consulenza ai consumatori;

Sviluppo della necessaria documentazione sistematica ed educativa riguardante il lavoro degli utenti finali.

10. Preparazione e manutenzione degli strumenti di sistema:

Ricerca di software esistenti sul mercato e ricerca della possibilità e necessità del loro utilizzo nell'ambito di BND;

Sviluppo del necessario programma organizzativo e tecnico dei movimenti per lo sviluppo di BND;

Verifica delle prestazioni del software riscattato prima di collegarlo al BND;

Controllo della connessione del nuovo software al BND.

11. Lavoro organizzativo e sistematico nello sviluppo di BND:

Selezione o creazione di un metodo di sviluppo del database;

Determinazione degli obiettivi e direzione di sviluppo del sistema nel suo insieme;

Pianificare le fasi di sviluppo del BnD;

Sviluppo di libri di riferimento per i dizionari generali del progetto BND e un modello concettuale;

Installazione di modelli esterni di applicazioni sviluppate;

Controllo della connessione della nuova applicazione al lavoro di BND;

Possibilità di risoluzione dei problemi complessi di un insieme di applicazioni che interagiscono da un database.