Sviluppo di applicazioni e banche dati: punti di contatto. Informazioni su db e directory di dati

17.06.2019 notizia

30.04.2009 Alexey Kovyazin

I database relazionali sono penetrati in quasi tutti i sistemi informativi e, a quanto pare, sono diventati l'area più consolidata dell'IT, dove si può inventare poco, ma la realtà è tutt'altro che ideale.

I database relazionali sono oggi utilizzati in quasi tutte le applicazioni, da quelli incorporati in dispositivi mobili e speciali, alle applicazioni basate sul Web, fino ai sistemi di gestione aziendale. La penetrazione dei database in tutti i tipi di applicazioni è in aumento e gli sviluppatori stanno ottenendo strumenti e approcci sempre più intuitivi. Si potrebbe avere l'impressione che gli sviluppatori di applicazioni per database siano lo strato più "benestante" di programmatori che dispongono di strumenti per tutte le occasioni, ma questo è tutt'altro che vero. Embarcadero Technologies, acquisendo la divisione di strumenti di sviluppo CodeGear di Borland nel 2008, ha combinato lo sviluppo di applicazioni professionali e strumenti di progettazione, sviluppo e strumenti di gestione del database per affrontare sia i problemi delle applicazioni che dei database.

Progettazione caotica del database

Nella moderna industria dello sviluppo software, è convinzione comune che sia impossibile definire i requisiti del prodotto prima di iniziare un progetto, e quindi lo sviluppo deve essere adattato al loro costante cambiamento. Di conseguenza, sono emersi processi iterativi per soddisfare le mutevoli esigenze e il refactoring del codice sorgente è diventato parte integrante dello sviluppo del software. Cosa succede ai database durante lo sviluppo iterativo? La modifica dei requisiti ti costringe a modificare lo schema del database e molto spesso ciò avviene in modo opaco, senza analizzare l'immagine complessiva e le dipendenze. Tabelle, campi, chiavi esterne e vincoli vengono creati e modificati in modo caotico, nessuno monitora l'integrità referenziale e nessuno può dire con certezza in che modo il database all'iterazione N differisce dal suo stato all'iterazione N-1.

In effetti, lo sviluppo dei database oggi viene effettuato con il metodo "patch", come ai tempi del dominio del processo "waterfall" - all'inizio del progetto, un certo modello del database è "disegnato" basato sui requisiti parziali conosciuti al momento, viene quindi generato un database fisico, e poi si dimentica il modello apportando modifiche direttamente al database. Gli svantaggi di questo approccio sono evidenti: lo scambio di conoscenze e la comprensione del quadro generale sono difficili e i cambiamenti sono opachi, possono generare contraddizioni nella logica e nello schema del database, che rimarranno taciuti fino al momento in cui il sistema software verrà messo in funzione, il che porta a perdite molto grandi. Gli sviluppatori di applicazioni di database moderne necessitano di strumenti orientati allo sviluppo iterativo di database.

La prima e più importante condizione per tale adattabilità è la presenza di opportunità a tutti gli effetti ingegneria inversa(reverse engineering, creazione di un modello di database basato sull'analisi del suo schema fisico) e ingegneria diretta(forward engineering; creazione e modifica dello schema fisico del database basato sul modello). In pratica, ciò significa che utilizzando uno strumento di progettazione, è possibile analizzare lo schema di un database esistente, creare un modello di database basato su di esso, modificare il modello e applicare immediatamente modifiche che dovrebbero modificare in modo corretto e coerente lo schema del database e non rovinare o confonderlo.

L'approccio iterativo ci spinge anche a creare sottomodelli associati a una particolare iterazione. L'evidenziazione di qualsiasi entità e dei relativi attributi in un sottomodello aiuta a separare le aree di responsabilità sia tra i diversi sviluppatori che tra le diverse iterazioni, garantendo nel contempo l'integrità complessiva del modello. Naturalmente è necessaria anche la capacità di confrontare i due modelli, e non sotto forma di script SQL, ma a livello di entità e attributi, per poter vedere e comprendere appieno le modifiche apportate durante l'iterazione e il loro impatto sull'intero modello.

Gli sviluppatori di applicazioni raramente lavorano da soli, quindi hanno bisogno di strumenti di collaborazione, ma se questo va bene dal lato dello sviluppo delle applicazioni, la collaborazione con il database di solito non è supportata in alcun modo a livello di strumenti. La collaborazione implica necessariamente un sistema di controllo della versione: tutte le versioni dei modelli e dello schema del database fisico devono essere archiviate in un unico repository, fornendo la possibilità di eseguire il rollback e confrontare gli schemi fin dall'inizio del processo di sviluppo.

Lo sviluppo del database non è meno importante dello sviluppo dell'applicazione, pertanto la direzione strategica dello sviluppo è fornire al processo di sviluppo del database il controllo della versione e la gestione dei requisiti, oltre a collegare esplicitamente le fasi di modellazione e modifica dei database alle iterazioni e al cambiamento dei requisiti di un progetto software. Per risolvere i problemi di cui sopra e supportare il moderno processo iterativo di sviluppo del database, Embarcadero offre ER / Studio, uno strumento di progettazione, analisi, reverse e forward engineering che consente di controllare le versioni del modello in base al proprio repository. Lo strumento Change Manager può essere utilizzato per controllare le modifiche ai metadati nei database fisici.

Codice disaggregato

Il problema più famoso che rallenta notevolmente il processo di sviluppo di applicazioni di database è la necessità di utilizzare strumenti diversi per eseguire il debug del codice dell'applicazione e del codice SQL nel database.

Diamo un'occhiata a un semplice esempio. Supponiamo che tu stia sviluppando un'applicazione in Delphi che chiama una procedura memorizzata in un DBMS Oracle. Utilizzando gli strumenti Delphi, lo sviluppatore dell'applicazione può passo dopo passo in modalità debug fino al momento della chiamata della query SQL, vedere i parametri passati alla stored procedure e il risultato che la procedura restituirà. Ma cosa succede all'interno della procedura quando viene eseguita sul server del database? È impossibile determinarlo dall'ambiente di sviluppo della nostra applicazione: per questo è necessario scaricare un'applicazione per lo sviluppo SQL, che ha la capacità di eseguire il debug delle stored procedure e mostra anche i piani per le query SQL, le statistiche della loro esecuzione, ti consente per visualizzare e modificare lo schema del database. Tuttavia, non è possibile passare i parametri dall'ambiente di sviluppo dell'applicazione all'ambiente di sviluppo SQL e bisogna copiarli manualmente, passando da una finestra all'altra. Inoltre, non è possibile visualizzare i risultati dettagliati dell'esecuzione del codice SQL nell'Application Builder, come il piano di query, le statistiche di esecuzione e così via. L'avvento della tecnologia di debug multilingua ha risolto questi problemi.

Il primo prodotto Embarcadero che supporta il debug cross-lingua è RapidSQL Developer (ex PowerSQL), la cui parte visuale è basata sulla tecnologia Eclipse e permette quindi di integrarsi in qualsiasi ambiente di sviluppo basato su di essa (incluso, ovviamente, JBuilder) e debugging dinamico tra più lingue. Ora, quando la stored procedure viene eseguita sul server, lo sviluppatore passa automaticamente a un ambiente di debug SQL completo nell'ambito dello stesso strumento, in grado di eseguire il debug di query SQL ordinarie e stored procedure. Lo sviluppatore può vedere i parametri di input effettivi di query e stored procedure, ottenendo l'opportunità di eseguire il debug passo dopo passo del codice SQL. L'integrazione di RapidSQL Developer in strumenti di sviluppo compatibili con Eclipse è il primo passo per l'integrazione dello sviluppo di applicazioni e database e il passaggio successivo è fornire funzionalità simili per Delphi, C++ Builder e altri strumenti di sviluppo di applicazioni di Embarcadero.

Applicazioni di database multipiattaforma

Una sfida particolare per gli sviluppatori è lo sviluppo di applicazioni di database che devono funzionare con più DBMS. Ad esempio, le banche e le compagnie di assicurazione di solito hanno diversi grandi uffici e molte piccole filiali. La maggior parte dei processi aziendali relativi all'immissione di informazioni operative e al flusso di lavoro quotidiano sono gli stessi presso la sede centrale e nelle filiali, ma le scale sono diverse. La naturale volontà di risparmiare sul costo delle licenze DBMS industriali da utilizzare nelle filiali porta a pensare che sarebbe bene scegliere un altro DBMS senza modificare l'applicazione.

Gli sviluppatori di database esperti comprendono bene l'essenza dei problemi che sorgono qui: la differenza nei tipi di dati e nei dialetti SQL, l'assenza di meccanismi di migrazione e replica tra diversi DBMS, la complessità della verifica della migrazione rendono la scrittura e il funzionamento di applicazioni per diversi DBMS un incubo. Dal lato degli strumenti di sviluppo delle applicazioni, stanno cercando di risolvere questo problema creando librerie di accesso ai dati (dbExpress in Delphi e C++ Builder, ADO e ADO.Net di Microsoft), costruite su principi architetturali e metodi di accesso unificati, nonché ad esempio utilizzando numerosi "Wrapper" oggetti-relazionali (Object Relation Mapping, ORM) sulla logica relazionale e la struttura del database, generando codice sorgente per lavorare con i dati in base all'analisi dello schema del database e utilizzando il meccanismo degli "adattatori" " per implementare il protocollo di uno specifico DBMS. Tra gli ORM più popolari ci sono Hibernate per Java e ActiveRecord in RubyOnRails, che forniscono un'interfaccia orientata agli oggetti ai dati memorizzati nel DBMS. Per Delphi esiste un progetto simile tiOPF, per C# - NHibernate.

Naturalmente, l'uso di tali librerie universali e insiemi di componenti può ridurre significativamente il numero di operazioni di routine nel processo di sviluppo di database multipiattaforma. Tuttavia, questo non è sufficiente quando si tratta di applicazioni che utilizzano database più complessi, in cui viene utilizzata attivamente la logica inerente alle stored procedure e ai trigger: per la sua implementazione, debug e test sono necessari strumenti separati, a volte completamente diversi per diversi DBMS . Per lo sviluppo di applicazioni di database multipiattaforma, Embarcadero offre lo strumento RapidSQL.

Tutti i prodotti di database Embarcadero supportano più piattaforme e si basano sull'analisi dello schema di Thunderbolt e sul motore delle statistiche del database. Ogni DBMS supportato e ogni versione specifica del DBMS hanno corrispondenti rami di codice nel core Thunderbolt, che consente di mappare lo schema del database alla rappresentazione interna in questo core nel modo più accurato possibile e, soprattutto, eseguire conversioni corrette tra la rappresentazione e banche dati reali. È grazie al core Thunderbolt che RapidSQL consente di sviluppare codice SQL di alta qualità per tutte le piattaforme supportate (Oracle, MS SQL, Sybase e varie varianti di IBM DB2) e ER/Studio può eseguire un accurato reverse e forward engineering del database schemi.

Se stai sviluppando un'applicazione per due o più piattaforme o eseguendo la migrazione di un'applicazione esistente da una piattaforma a un'altra, RapidSQL fornirà tutti gli strumenti necessari per la migrazione di schemi, utenti e autorizzazioni tra diversi DBMS. Naturalmente, RapidSQL non converte automaticamente le procedure PL / SQL in T-SQL - ciò richiede ancora un programmatore - tuttavia, lo strumento fornisce un'unica finestra per lo sviluppo multipiattaforma, editor unificati per oggetti schema, utenti e relativi diritti e SQL debug su tutte le piattaforme supportate. ... Secondo gli utenti di RapidSQL, questo consente di risparmiare fino al 70% del tempo impiegato per la migrazione tra diversi DBMS.

Modifiche a dati e diagrammi

La migrazione da un DBMS ad un altro è impossibile senza la sua verifica. Chi e come può garantire che i dati trasferiti da un DBMS all'altro siano davvero identici? Diverse librerie client, diversi tipi di dati e diverse codifiche rendono il processo di confronto dei dati un compito non banale.

Nel mondo reale, il lavoro non finisce con la distribuzione dell'applicazione e del database: c'è manutenzione, vengono visualizzate nuove versioni dei file eseguibili dell'applicazione e patch per il database. Come si possono avere garanzie che tutti gli aggiornamenti necessari siano stati applicati al database e che l'intero pacchetto software funzioni correttamente?

Embarcadero ha sviluppato lo strumento Change Manager per confrontare dati, schemi e configurazioni di database. Il confronto avviene nell'ambito di uno o più DBMS, con verifica automatica della corrispondenza tra tipi di dati e formazione di script SQL delle differenze, immediatamente applicabili per riportare i database in uno stato identico. Il modulo di confronto dei metadati fornisce il confronto degli schemi di database sia tra database attivi che tra database e script SQL e genera uno script per le differenze di metadati. Questa funzionalità può essere utilizzata non solo per verificare la conformità dei database con il benchmark, ma anche per organizzare un regolare processo di aggiornamento del database, nonché per verificare la presenza di modifiche non autorizzate, ad esempio, nelle filiali remote di una grande organizzazione. La situazione è simile con i file di configurazione: Change Manager confronta i file di configurazione e consente di garantire che la configurazione delle applicazioni distribuite soddisfi i requisiti per questo software.

Prestazioni dell'applicazione del database

Quante volte vediamo applicazioni che funzionano bene su piccoli volumi di dati di test, ma diventano inaccettabilmente lente su volumi reali. Errori di calcolo nei requisiti, test inadeguati nelle fasi iniziali, fretta nella consegna di un progetto sono tutti motivi familiari per uno sviluppo di applicazioni scadente. In questo caso, i teorici dello sviluppo del software propongono di impegnarsi nell'auto-miglioramento e migliorare sostanzialmente la qualità dei programmi, tuttavia, tutti i professionisti sanno che a volte è impossibile riscrivere un progetto, sia economicamente che, in alcuni casi, politicamente, e il compito di ottimizzazione delle prestazioni deve essere risolto in alcun modo.

La causa principale dei problemi di prestazioni nelle applicazioni di database risiede nelle query SQL non ottimizzate e nelle stored procedure. I moderni ottimizzatori di database sono abbastanza potenti, tuttavia, hanno anche determinati limiti di capacità e, per ottenere buone prestazioni, è necessario comporre correttamente query SQL, creare (o eliminare) indici aggiuntivi, in alcuni casi denormalizzare il database, trasferire alcuni della logica ai trigger e alle stored procedure.

Durante lo sviluppo, l'ottimizzazione delle query può essere eseguita utilizzando RapidSQL, che include un modulo SQL Profiler in grado di analizzare i piani e generare suggerimenti per migliorare le prestazioni delle query SQL. Ma cosa succede se il problema si verifica durante la produzione e non è localizzato in una specifica query SQL? Se le prestazioni scendono a una certa ora del giorno, o, cosa ancora più fastidiosa, il problema si verifica su una copia remota del sistema, mentre sul server principale va tutto bene? È qui che viene progettato DBOptimizer, uno strumento di profilazione del database per Oracle, Microsoft SQL Server, Sybase e IBM DB2.

Quando viene avviata la modalità di profilazione, DBOptimizer raccoglie informazioni sul database e sul runtime, comprese le informazioni sul carico della CPU e altri parametri del sistema operativo, scrivendole nella sessione di profilatura. Il risultato è un elenco di query eseguite in un dato intervallo di tempo, ordinato per risorse consumate. Per ogni richiesta problematica, puoi vedere il suo piano, le statistiche di esecuzione e altri dettagli. Inoltre, DBOptimizer mostra anche suggerimenti e consigli per migliorare la query in relazione a DBMS specifici.

Cassetta degli attrezzi

Tutti gli strumenti citati, mentre risolvono i problemi, vengono utilizzati in diverse fasi del ciclo di vita dello sviluppo del database. È piuttosto scomodo e costoso mantenere una dozzina di applicazioni per tutte le occasioni che possono essere necessarie o meno durante la progettazione, lo sviluppo, la migrazione, l'ottimizzazione e il funzionamento dei database.

Rilasciato nel febbraio 2009, il versatile toolkit Emdacadero All-Access include gli strumenti essenziali per tutte le fasi dello sviluppo di applicazioni database, da ER/Studio a DBOptimizer, da Delphi e C++ Builder a DBArtisan. Il modo migliore per descrivere All-Access è il confronto con la cassetta degli attrezzi che ogni proprietario zelante ha in casa. Forse non tutti gli strumenti vengono utilizzati tutti i giorni, ma una chiave regolabile dovrebbe essere sempre a portata di mano in caso di perdita.

All-Access non impone altri ruoli ai programmatori di database o agli architetti, ma fornisce un toolkit universale adatto a tutti i ruoli nel processo di sviluppo dell'applicazione di database, dall'architetto al tester; offre a tutti i membri del team di sviluppo strumenti per tutte le fasi di sviluppo del database, nonché una serie di strumenti altamente specializzati per l'ottimizzazione di database (DBOptimizer) e applicazioni (JOptimizer) per "espandere" i colli di bottiglia. Il pacchetto supporta più DBMS, il che fornisce risparmi sui costi.

Le differenze tecniche tra le tecnologie di database orientate agli oggetti e relazionali hanno portato a differenze culturali che ancora separano la comunità di gestione dei dati dalla comunità di sviluppo. Cosa fare dopo con questo?

Delphi è un ambiente di sviluppo che utilizza il linguaggio di programmazione Delphi (a partire dalla versione 7, il linguaggio nell'ambiente si chiama Delphi, in precedenza - Object Pascal), sviluppato da Borland e originariamente implementato nel suo pacchetto Borland Delphi, da cui ha ricevuto l'attuale nome nel 2003... Object Pascal, infatti, è l'erede del linguaggio Pascal con estensioni orientate agli oggetti.

Delphi è lo strumento definitivo per la creazione di applicazioni di database. Ottimale, perché supporta la tecnologia di sviluppo visivo, che può ridurre significativamente i tempi di sviluppo mantenendo una buona qualità e affidabilità del prodotto software. Delphi nella struttura della lingua consente di evitare errori nascosti.

Caratteristiche della famiglia Delphi 7:

* Un ambiente di sviluppo rapido di applicazioni che integra strumenti di modellazione per lo sviluppo e la distribuzione di applicazioni di e-commerce e servizi Web.

* Supporto per linguaggi di programmazione per Win32 (Delphi e C/C++) e per .NET (Delphi e C#) in un unico ambiente di sviluppo, che rende più semplice la manutenzione e la creazione di nuove applicazioni Win32 e più facilmente padroneggiabili. tecnologie NET;

* La capacità sia per gli sviluppatori di applicazioni Windows tradizionali che per gli sviluppatori che utilizzano Java di sviluppare applicazioni .NET senza abbandonare gli strumenti utilizzati, mantenendo competenze e concetti di programmazione simili;

* Il nuovo sistema di modelli di codice e altre innovazioni nell'ambiente di sviluppo migliorano qualitativamente il lavoro con i codici sorgente e aumentano la produttività dello sviluppo;

Microsoft SQL Server 2000 è un database completo e un'offerta di analisi dei dati per la creazione rapida di soluzioni di e-commerce, applicazioni aziendali e data warehouse scalabili.

Può ridurre significativamente il time to market per queste soluzioni fornendo al contempo la scalabilità per soddisfare i requisiti più esigenti.

Il pacchetto Delphi è una continuazione della linea di compilatori Pascal di Borland. Come linguaggio, Pascal è molto semplice e il controllo avanzato del tipo di dati facilita il rilevamento precoce degli errori e consente di creare rapidamente programmi affidabili ed efficienti.

Lo sviluppo di applicazioni database è una delle funzionalità più richieste dell'ambiente di programmazione Delphi. La potenza e la flessibilità del database di Delphi si basano su un core di basso livello, il Borland Database Engine (BDE). La sua interfaccia con le applicazioni è chiamata IDAPI (Integrated Database Application Programming Interface). BDE consente l'accesso ai dati utilizzando sia il tradizionale approccio orientato ai record (navigazione) sia l'approccio orientato agli insiemi utilizzato nei server di database SQL.

La libreria degli oggetti contiene un insieme di componenti visuali che semplificano notevolmente lo sviluppo di applicazioni per DBMS con architettura client-server. Gli oggetti incapsulano il livello inferiore, il Borland Database Engine.

Esistono insiemi speciali di componenti responsabili dell'accesso ai dati e componenti che visualizzano i dati. I componenti di accesso ai dati consentono di effettuare connessioni al database, effettuare selezioni, copiare dati, ecc.

I componenti di visualizzazione dei dati consentono di visualizzare i dati sotto forma di tabelle, campi, elenchi. I dati visualizzati possono essere in formato testo, grafico o in qualsiasi formato.

Le tabelle sono memorizzate nel database. Alcuni DBMS memorizzano il database come diversi file separati che rappresentano tabelle (in pratica tutti i DBMS locali), mentre altri sono costituiti da un unico file che contiene tutte le tabelle e gli indici (InterBase).

Gli oggetti di database in Delphi sono basati su SQL e incorporano tutta la potenza del Borland Database Engine. Delphi include anche Borland SQL Link, quindi l'accesso a Oracle, Sybase, Informix e InterBase DBMS è altamente efficiente. Inoltre, Delphi include un server Interbase locale in modo da poter sviluppare applicazioni estensibili offline a qualsiasi server SQL esterno.

Scalabilità in pratica: la stessa applicazione può essere utilizzata sia per le opzioni client/server locali che per quelle più serie.

Sebbene Delphi non disponga di un proprio formato di tabella di database, fornisce comunque un potente supporto per un gran numero di DBMS diversi, sia locali (ad esempio dBase o Paradox) che industriali (ad esempio Sybase o InterBase).

SUPPORTO BANCA DATI

11.1. Tecnologie di accesso ai dati

Visual C++ fornisce tecnologie di accesso ai dati che consentono la creazione di applicazioni di database. “Il numero di interfacce di accesso ai dati disponibili per le applicazioni Windows può sembrare schiacciante. Quale delle tecnologie con nomi misteriosi - DAO, ODBC, RDO, UDA, OLE DB o ADO - scegliere per costruire un'applicazione specifica ”[l.10, p. 242]. La maggior parte delle tecnologie di accesso si basa su due tecnologie chiave: ODBC (Open Database Connectivity) e DAO (Data Access Objects).

I parametri comparativi delle tecnologie ODBC e DAO possono essere presentati come segue:

Parametro
Architettura	Un insieme di moduli DLL, driver	Insieme di oggetti OLE
Origine dei dati	File di database di qualsiasi formato Oltre a SQL Server e Oracle	File di database del formato .mdb, Accesso, FoxPro, Paradox
Connessione al database	Oggetto classe CDatabase	Oggetto classe CDaoDatabase
Recuperando i dati	Oggetto classe Crecordset	Oggetto della classe CDaoRecordset
Visualizza i dati	Oggetto classe CrecordView	Oggetto della classe CDaoRecordView
Set di funzioni	Set di funzioni più piccolo di	Una vasta gamma di funzioni, nessun analogo in ODBC

ODBC e DAO hanno molto in comune, ad esempio l'utilizzo di classi MFC con funzionalità simili per eseguire le stesse operazioni di connessione al database, recuperare un set di record di database e visualizzarli. Ma le classi DAO contengono un insieme più ampio di funzioni, nonché funzioni che non hanno eguali in ODBC.

Ci sono anche differenze significative. Ciò riguarda l'architettura delle tecnologie nell'implementazione delle librerie di sistema. Le classi ODBC sono implementate come una raccolta di DLL chiamate driver (DLL, Dinamic-Link Library). E le classi DAO sono implementate come una raccolta di oggetti OLE, che è più moderno.

Un'altra differenza significativa tra le tecnologie risiede nel loro utilizzo per le origini dati. Attualmente, è stato sviluppato un numero abbastanza elevato di driver ODBC per vari DBMS. Pertanto, ODBC può essere utilizzato per file di database di vari formati, mentre DAO può essere utilizzato solo, principalmente, per file di database in formato .mdb. Allo stesso tempo, un'applicazione basata su ODBC può funzionare contemporaneamente con vari DBMS senza ricompilazione a causa del caricamento dinamico dei driver.

11.2. Creazione di un'applicazione database

La creazione di un'applicazione per lavorare con un database basato su tecnologie ODBC o DAO richiede i seguenti passaggi:

Stabilire l'accesso al database. La fase consiste nel registrare il database specificato come origine dati.

Creazione di uno stub dell'applicazione. Questo passaggio viene eseguito automaticamente utilizzando l'AppWizard durante i 6 passaggi di configurazione dell'applicazione con la scelta della tecnologia di accesso all'origine dati ODBC o DAO.

Implementazione di operazioni su database. La fase viene eseguita utilizzando le classi MFC della corrispondente tecnologia di accesso ai dati.

Lo scopo del lavoro è creare un'applicazione che esegua operazioni con il database: visualizzazione, aggiunta, eliminazione.

Usiamo il file db.mdb, che è un database creato nel DBMS di Access. Il file contiene informazioni sugli studenti: Nome, Voto (Corso). Il file può essere scaricato da ftp://ftp.sybex.com/2120/vcpp.exe [l.13, p. 415]. Puoi creare il tuo file in qualsiasi programma di database.

Lascia che la maschera che mostra il contenuto del database assomigli a questa:

Senza titolo - Lab11

File Modifica Record Visualizza Aiuto

[|<] [<] [>] [>|]

Stabilire l'accesso al database

Per stabilire l'accesso al database come origine dati, effettuare le seguenti operazioni:

Crea una cartella Dbase e copiaci il file db.mdb. Se hai creato il tuo file di dati, copialo.

Fare clic su Start, Impostazioni, Pannello di controllo in sequenza. Nella finestra Pannello di controllo, fare doppio clic su ODBC a 32 bit. Viene visualizzata la finestra Amministratore origine dati.

Fare clic sul pulsante Aggiungi. Si aprirà la finestra Crea nuova origine dati con un elenco di driver. Selezionare Microsoft Access Driver (.mdb) e fare clic sul pulsante Fine. Viene visualizzata la finestra di installazione di ODBC Microsoft Access 7.0.

Immettere Studenti nel Nome origine dati e Nome_Grado nel campo Descrizione. Se hai creato il tuo file di dati, inserisci i valori appropriati.

Fare clic sul pulsante Seleziona. Viene visualizzata la finestra Seleziona database. Seleziona il file db.mdb o il tuo file.

Fare clic sul pulsante OK. Viene visualizzata la finestra di installazione di ODBC Microsoft Access 7.0. Fare clic su OK e quindi su OK nella finestra Amministratore origine dati ODBC.

Pertanto, l'accesso al file di database db.mdb (o al proprio file) viene stabilito utilizzando il driver ODBC di Microsoft Access Driver (.mdb).

Creazione di uno stub dell'applicazione

Per creare un'applicazione, segui questi passaggi:

Seleziona il comando File-> Nuovo e la scheda Progetti. Viene visualizzata la finestra Nuovo progetto con un elenco di tipi di applicazioni.

Selezionare dall'elenco MFC Appwizard (exe). Nel campo Nome progetto, inserisci il nome del progetto Lab11. Il campo Posizione specifica la cartella in cui archiviare il progetto (per impostazione predefinita, uguale al nome del progetto). Fare clic su OK.

Completa 6 fasi di personalizzazione dell'applicazione creata. Nel primo passaggio, seleziona SDI (Single Document Interface) - una finestra aperta e fai clic su Avanti.

2a fase: lavorare con i database. La casella di controllo Solo file di intestazione presuppone solo l'accesso ai database, Visualizzazione database senza supporto file - Visualizzazione database senza supporto per operazioni sui file (i record possono essere aggiornati), Visualizzazione database con supporto file - Visualizzazione database e supporto file (funziona con molti documenti). Nel nostro esempio, imposta il pulsante di opzione Vista database con supporto file. Fare clic sul pulsante Origine dati per connettere l'applicazione all'origine dati.

Creazione di applicazioni per lavorare con i database.

I database vengono utilizzati quando è necessario lavorare con grandi quantità di dati.

Un database relazionale è un insieme di tabelle, procedure e altri oggetti che ne supportano il funzionamento. Il tavolo ha nome- un identificatore mediante il quale può essere indicato. Esempio di tabella dei dati dei dipendenti pers:

Numero	Il Dipartimento	Cognome	Nome	Cognome	Anno di nascita	Pavimento	Caratteristica	La foto
numero	Dip	Famiglie	nome	Par	Anno_b	Sesso	carattere	Foto
	Ufficio contabilità	Ivanov	Ivan	Ivanovich	1950
	Laboratorio 1	Petrov	Peter	Petrovic	1960
	Laboratorio 2	Sidorov	Sidor	Sidorovič	1955
	Laboratorio 1	Ivanova	Irina	Ivanovna	1961

colonne le tabelle corrispondono alle caratteristiche degli oggetti - campi. Ogni campo è caratterizzato dal nome e dal tipo di dati memorizzati. Nome del campoÈ un identificatore utilizzato in vari programmi di manipolazione dei dati. Come qualsiasi identificatore, il nome del campo può essere composto solo da lettere latine, una sola parola, ecc. (riga 2 nella tabella).

Tipo di campo caratterizza il tipo di dati memorizzati nel campo. Questi possono essere stringhe, numeri, valori booleani, testi di grandi dimensioni (ad esempio, caratteristiche dei dipendenti), immagini (foto dei dipendenti), ecc.

Ogni riga della tabella corrisponde a uno degli oggetti. È chiamato registrazione e contiene i valori di tutti i campi che caratterizzano l'oggetto dato.

Quando si creano tabelle di database, è importante assicurarsi che le informazioni siano coerenti. Questo di solito viene fatto introducendo campi chiave- garantire l'unicità di ogni record. Uno o più campi possono essere fondamentali. Nell'esempio dato, sarebbe possibile rendere chiave un insieme di campi Fam, Nam, Par... Ma in questo caso, non sarebbe possibile inserire nella tabella informazioni su omonimi completi che hanno lo stesso cognome, nome e patronimico. Pertanto, il primo campo viene inserito nella tabella numero- un numero che può essere reso fondamentale per garantire l'unicità di ogni record.

Quando si lavora con una tabella, l'utente o il programma sembra far scorrere il cursore sui record. In ogni momento c'è qualcosa il corrente il verbale con il quale si svolge il lavoro. I record nelle tabelle dati possono essere disposti senza alcun ordine, solo nella sequenza del loro inserimento (comparsa di nuovi dipendenti). Ma quando le tabelle vengono presentate all'utente, devono essere ordinate. L'utente potrebbe volerli visualizzare in ordine alfabetico, o ordinati per reparto, o per età, ecc.

Per l'ordinamento dei dati, viene utilizzato il concetto indice... L'indice mostra in quale sequenza si consiglia di visionare la tabella. È, per così dire, un intermediario tra l'utente e la tabella:

Gli indici possono essere primario e secondario.
Ad esempio, l'indice primario può essere un campo contrassegnato come chiave al momento della creazione del database. E gli indici secondari possono essere creati da altri campi sia durante la creazione del database stesso, sia successivamente nel processo di lavorazione con esso. Agli indici secondari vengono assegnati nomi - identificatori con cui possono essere utilizzati.
Un database di solito non contiene una, ma molte tabelle. Ad esempio, un database su una determinata organizzazione può contenere una tabella delle divisioni disponibili in esso con le caratteristiche di ciascuna di esse.
Tabella dep con campi Dip e Proisv

Nelle tabelle collegate, di solito uno appare come casa, e l'altro o più altri - come ausiliario, gestito dal principale. Le tabelle principale e secondaria sono collegate tra loro chiave... Alcuni campi presenti in entrambe le tabelle possono fungere da chiave.

Nell'esempio, il tavolo principale può essere Dip, ausiliario pers, e possono comunicare dal campo Dip presente in entrambe le tabelle.

Ogni record nella tabella principale Dip quei record della tabella ausiliaria corrispondono pers, in cui il campo chiave Dip con il nome del reparto è uguale al nome del reparto nel record corrente della tabella principale. In altre parole, se nel record corrente della tabella principale nel campo Dip dice "Contabilità", quindi nella tabella ausiliaria pers tutte le registrazioni dei dipendenti contabili sono evidenziate.

Crea database ed elabora le richieste a loro sistemi di gestione del database - DBMS: Paradox, Microsoft Access, FoxPro, Oracle, InterBase eccetera.

Diversi DBMS organizzano e archiviano i database in modi diversi. Paradox usa un file per ogni tabella. Microsoft Access e InterBase archiviano più tabelle come un unico file. In questo caso il database è il nome del file con il percorso per accedervi. I sistemi client / server (Sybase, Microsoft SQL, Oracle) archiviano tutti i dati su un computer separato e comunicano con il client utilizzando un linguaggio speciale: SQL.

Gli alias del database vengono utilizzati per semplificare le chiamate al database. Alias (alias) contiene tutte le informazioni necessarie per consentire l'accesso al database. Queste informazioni vengono fornite solo una volta al momento della creazione dell'alias. E l'applicazione utilizza uno pseudonimo per comunicare con il database. In questo caso, all'applicazione non interessa dove si trova fisicamente il database e spesso non si preoccupa del DBMS che ha creato e mantiene questo database. Quando si cambia il sistema di directory, il server, ecc. non è necessario modificare nulla nell'applicazione. È sufficiente che l'amministratore del database inserisca le informazioni appropriate nell'alias.

memorizzazione nella cache Tutte le modifiche significa che tutte le modifiche ai dati, l'inserimento di nuovi record, la cancellazione di record esistenti effettuati dall'utente vengono prima effettuate non nel database stesso, ma vengono archiviate in memoria in una tabella virtuale temporanea. E solo con un comando speciale, dopo tutti i controlli sulla correttezza dei dati inseriti nella tabella, all'utente viene data l'opportunità di confermare tutte queste modifiche nel database o rifiutarlo e tornare allo stato che era prima del inizio della modifica.

Il commit delle modifiche al database viene eseguito utilizzando transazioni... È una raccolta di comandi che modificano il database. All'utente viene data l'opportunità di completare la transazione apportando tutte le modifiche al database reale o effettuando il rollback da questo e tornando allo stato precedente all'inizio della transazione.

StruttureDelphi, progettato per lo sviluppo e il funzionamento di applicazioni che utilizzano database:

BDE (Borland Database Engine) - Motore di database Borland. È un insieme di librerie DLL che forniscono accesso a basso livello a database locali e client-server. Deve essere installato su ogni computer che utilizza applicazioni di database scritte per Delphi.

Collegamenti SQL - driver per lavorare con server di dati remoti (MS SQL Server, Oracle)

BDE Administrator è un'utilità per l'impostazione di alias di database (nomi), parametri di database e driver di database su un computer specifico. Quando si lavora con un database da un'applicazione creata utilizzando Delphi, si accede al database tramite il suo alias. I parametri definiti dall'alias del database sono validi solo per questo database; i parametri impostati per il driver del database si applicano a tutti i database che utilizzano il driver. Inoltre, è possibile impostare tali parametri comuni a tutti i database, come il formato della data e dell'ora, i formati dei valori numerici, il driver della lingua utilizzata, ecc.

Desktop del database (DBD) - uno strumento per creare, modificare e visualizzare una banca dati. Questa utility è principalmente focalizzata sul lavoro con tabelle di DBMS locali, come Paradox. È possibile, con alcune limitazioni, creare e visualizzare tabelle di database in esecuzione sotto il controllo dei server: InterBase, MS SQL Server, Oracle.

DBD consente al programmatore di formare una query al database utilizzando il metodo QBE (Query By Example).

SQL Explorer è un'utilità versatile che combina molte delle funzionalità di BDE Administrator e DBD. Con il suo aiuto, puoi creare e visualizzare alias di database, visualizzare le strutture e il contenuto delle tabelle di database, generare query al database in SQL, creare dizionari di dati (modelli di campi di tabella).

SQL Monitor è uno strumento per tracciare l'esecuzione di query SQL.

Componenti non visivi per lavorare con un database: utilizzati per connettere l'applicazione con tabelle di database in sistemi locali e distribuiti. Si trovano nella pagina di accesso ai dati della tavolozza dei componenti. Utilizzando componenti non visivi, è possibile connettersi ai database, formulare query su di essi e manipolare tabelle.

Componenti visivi per lavorare con un database, progettati per visualizzare i record di set di dati o i loro singoli campi. Questi componenti si trovano nella pagina Controlli dati della tavolozza dei componenti. Servono come strumento di sviluppo principale per l'interfaccia utente di accesso ai dati.

Caratteristiche dei programmi per lavorare con i database.

Una caratteristica dei programmi per lavorare con i database creati con Delphi è l'uso indispensabile di BDE in essi. (elaboratore di database relazionali Motore di database Borland incluso in Delphi), che funge da ponte di collegamento tra il programma e il database.

BDE assume tutto il lavoro di basso livello per fornire al programma client i dati di cui ha bisogno, quindi, nel caso generale, il programma interagisce con i dati come segue:

BDE non fa parte del programma. A seconda del tipo di DBMS, può essere posizionato sulla macchina del client o del server.

Di solito tra il programma e BDE esiste uno strato di componenti che semplifica notevolmente lo sviluppo dei programmi. I componenti non visivi funzionano direttamente con BDE e tre di essi (TTable, TQuery, TStoredProc) fungono da set di dati, mentre i componenti visivi visualizzano i dati forniti e servono a creare un'interfaccia intuitiva. Tra i set di dati e i componenti visivi, ci sono sempre componenti TDataSource che svolgono il ruolo di valvole che aprono o chiudono i flussi di dati che vengono scambiati tra sorgenti e componenti visivi (vedi Fig.).

Alcuni supportati inTipi DB Delphi.

Database locali e di file server.

Nei database locali, i database si trovano sulla macchina del cliente. In un file di database server, i database si trovano su un file server di rete.

La versione locale può fornire solo una modalità di accesso ai dati per utente singolo.

Nei database dei file server, i dati si trovano su un file server di rete, a cui possono accedere contemporaneamente più utenti. I dati nel database sono archiviati in un'unica copia, e ogni client in ogni momento lavora con una copia locale dei dati e la gestione dei dati è interamente affidata ai programmi client. Sono loro che devono occuparsi di sincronizzare le copie locali dei dati presso ogni sito cliente con i contenuti del database principale (e unico).

Quando viene eseguita una query su un database situato su un file server, viene effettivamente eseguita una query su una copia locale dei dati sul computer dell'utente. Pertanto, prima di eseguire la query, i dati nella copia locale vengono aggiornati completamente dal database reale. Quindi, se una tabella di database è composta da 10.000 record e sono necessari solo 10 record per eseguire una query, tutti i 10.000 record vengono comunque trasferiti al client. Pertanto, la rete è seriamente caricata.

Database client-server.

Nell'architettura client-server, appare un importante collegamento intermedio tra il BDE e il database: il database server (un programma speciale che gestisce il database).

Il client forma una richiesta al server nel linguaggio di query SQL (Structured Query Language - linguaggio di query strutturato), che è lo standard del settore per i database relazionali. Il server SQL fornisce l'interpretazione della query, la sua esecuzione, la formazione del risultato e l'emissione di questo risultato al client. Allo stesso tempo, le risorse del computer client non sono coinvolte nell'esecuzione fisica della richiesta: il computer client invia solo la richiesta al database del server e riceve il risultato, dopodiché lo interpreta come necessario e lo presenta al utente. Sulla rete vengono trasmessi solo i dati di cui il cliente ha bisogno.

Quando il server esegue le query, il grado di sicurezza dei dati aumenta notevolmente, poiché le regole di integrità dei dati sono definite sul server e sono uniformi per tutte le applicazioni che utilizzano questo database. Il potente apparato di transazione supportato dai server SQL blocca la modifica simultanea degli stessi dati da parte di utenti diversi e offre la possibilità di ripristinare i valori originali quando si apportano modifiche al database che sono terminate in modo anomalo.

Crea e visualizza gli alias del database.

attraversoDBD.

Di solito chiama Desktop del database incluso nel menu principale di Delphi nella sezione Strumenti. Se ciò non viene fatto, puoi abilitarlo lì con il comando Strumenti | Configura strumenti ... (file DBD32.exe).

DBD consente di creare tabelle di database di alcuni DBMS, impostare e modificare la loro struttura.

Puoi creare e visualizzare alias eseguendo Strumenti | Alias Manager. Viene visualizzata la finestra Gestore Alias:

Quando selezioni un alias nell'elenco Alias database, il tipo di driver viene modificato automaticamente nell'elenco a discesa