Scopo
|
Definire la progettazione fisica dettagliata del database.
|
La progettazione fisica del database include gli elementi modello (come le tabelle, viste e procedure memorizzate) che
rappresentano la struttura fisica dettagliata del database e degli elementi modello (come gli schema ed i tablespace)
che rappresentano la progettazione della memoria dati sottostante del database. Collettivamente, questi elementi
del modello contengono il modello dati fisico del database. Tale modello dati fisico è contenuto nel Prodotto di lavoro: Modello dati e non è un prodotto di lavoro del
modello separato.
Le operazioni dettagliate per lo sviluppo della progettazione fisica del database sono riportate di seguito:
Scopo
|
Per tracciare i tipi definiti dall'utente e riutilizzabili.
|
I domini possono essere utilizzati dal progettista di database per applicare gli standard tipo in tutta la
progettazione del database. I domini sono tipi di dati definiti dall'utente che possono essere applicati ad una colonna
in una tabella. I domini hanno le proprietà di una colonna senza il nome.
Scopo
|
Creare le relazioni e le tabelle di database iniziali.
|
Il progettista di database modella gli elementi del modello dati fisico utilizzando le tabelle e le colonne nelle
tabelle, come descritto nella sezione Linee guida per il
prodotto di lavoro: Modello dati.
Se è stato creato un modello dati logico, le relative entità logiche possono quindi essere utilizzate come base per una
serie iniziale di tabelle.
In alternativa, il progettista di database può saltare l'avvio del modello dati fisico utilizzando le classi permanenti
nel modello di progettazione come punto di partenza per le tabelle nel modello dati fisico. Il progettista di
database esegue la modellazione delle classi permanenti e dei relativi attributi come tabelle e colonne
rispettivamente. Il progettista di database deve inoltre definire le relazioni tra le tabelle, basate sulle
associazioni tra le classi permanenti nel modello di progettazione. Una descrizione su come gli elementi e le
relazioni del modello di progettazione vengono associati agli elementi e alle relazioni del modello dati è fornita
nella sezioneLinee guida per il prodotto di lavoro: Database relazionali forward engineering.
Se si inizia il modello dalle classi persistenti anziché da un modello di dati logici normalizzato, sarà generalmente
necessario applicare una determinata normalizzazione per poter eliminare le ridondanze di dati e le dipendenze di campi
senza chiavi. Consultare Concetto:
Normalizzazione per maggiori informazioni sulla normalizzazione del database.
Scopo
|
Per definire le tabelle di riferimento standard utilizzate in tutto il progetto.
|
Esistono spesso delle tabelle per la ricerca standard, tabelle di convalida o tabelle di riferimento utilizzate in
tutto il progetto. Poiché i dati presenti in queste tabelle tendono ad essere frequentemente acceduti ma raramente
modificati, tali dati meritano una considerazione speciale. Nel modello di progettazione queste tabelle possono
contenere dei codici di prodotto standard, prefissi nazionali o provinciali, codici di avviamento postali, codici
tasse, dati di convalida dei prefissi di teleselezione o altre informazioni accedute di frequente. Nei sistemi
finanziari, queste tabelle possono contenere elenchi dei codici di condotta, classificazioni dei livelli assicurativi o
tassi di conversione. Effettuare una ricerca nel modello di progettazione per le classi che sono principalmente di sola
lettura e che forniscono delle informazioni di conferma per un elevato numero di clienti.
Se la tabella di riferimento è piccola, non provare a indicizzarla, poiché l'indicizzazione potrebbe effettivamente
aggiungere un ulteriore sovraccarico alle tabelle piccole. Una piccola tabella a cui si accede frequentemente tende
anche a restare in memoria, dato che gli algoritmi della memoria cache spesso conservano le tabelle accedute con
frequenza nella cache dei dati.
Se possibile, accertarsi che la cache del database sia sufficientemente grande per conservare tutte le tabelle di
riferimento in memoria, compreso il normale "spazio operativo" per le query e transazioni. Molto spesso il segreto per
aumentare le prestazioni del database è di ridurre l'I/O del disco.
Una volta definite le strutture delle tabelle di riferimento, stabilire una strategia per riempire le tabelle di
riferimento. Poiché l'accesso a queste tabelle avviene nella fase iniziale del progetto, la determinazione dei valori
di riferimento e il caricamento delle tabelle devono spesso verificarsi relativamente presto durante il runtime
dell'applicazione. Sebbene il progettista di database non sia responsabile per l'ottenimento dei dati, è responsabile
delle modalità di aggiornamento delle tabelle di riferimento.
Scopo
|
Per definire una o più colonne che identificano in modo univoco una riga nella tabella.
Per definire i vincoli sulle colonne che garantiscono la univocità dei dati o della raccolta di dati.
|
Una chiave primaria è rappresentata da una o più colonne che identificano in modo univoco le righe in una tabella. Una
tabella dispone di una singola chiave primaria. E' spesso presente una chiave "naturale" che può essere utilizzata per
identificare in modo univoco una riga di dati (ad esempio, il codice postale in una tabella di riferimento). La chiave
primaria non deve contenere dati che potrebbero cambiare con l'ambiente di business. Se la chiave "naturale" è un
valore che può cambiare (ad esempio il nome di una persona), è consigliabile che il progettista di database crei una
singola colonna non significativa e senza immissione utente durante la creazione di una chiave primaria. In questo
modo viene creata una struttura dati con una maggiore adattabilità alle modifiche nella struttura, regole o ambiente di
business.
L'utilizzo di una colonna non significativa e senza immissione utente come chiave primaria è un concetto essenziale
nella progettazione di un magazzino dati. I sistemi di transazione scelgono spesso una chiave primaria "naturale" che
potrebbe essere subordinata ad una minima modifica in una colonna non significativa e senza immissione utente.
Un vincolo univoco specifica che i dati nella colonna o la raccolta di colonne è univoca per riga. Se il vincolo
univoco si trova in una colonna, i dati in una specifica riga della colonna specificata devono essere univoci rispetto
ai dati in una diversa riga della stessa colonna.
Quando viene definito un vincolo univoco per un gruppo di colonne, l'univocità si basa sull'intera raccolta dei dati
nelle colonne che compongono quel vincolo univoco. I dati presenti in una specifica riga di una specifica colonna non
devono essere univoci rispetto ai dati presenti in una diversa riga della stessa colonna. Il progettista di database
utilizza il vincolo univoco per garantire l'univocità dei dati di business.
Scopo
|
Per garantire l'integrità del database.
|
Le regole di integrità dei dati, note anche come vincoli, assicurano che i valori dei dati siano all'interno degli
intervalli definiti. Laddove è possibile identificare questi intervalli, il database può applicarli. Tuttavia, non si
vuole intendere che la convalida dei dati non deve essere effettuata nell'applicazione, ma soltanto che il database può
servire come "validator dell'ultimo ricorso" nel caso l'applicazione non funzioni correttamente. Laddove sono presenti
le regole di convalida dei dati, i vincoli del database devono essere progettati per applicarle.
Una chiave esterna è rappresentata da una o più colonne in una tabella che viene associata alla chiave primaria in
un'altra tabella. Una tabella può avere molte chiavi esterne e ciascuna chiave esterna è un'associazione a una diversa
tabella. Questa associazione o relazione tra le tabelle viene spesso indicata come una relazione
principale-secondaria. La tabella secondaria contiene la chiave esterna, che viene associata alla chiave primaria
nella tabella principale.
La definizione dei vincoli della chiave esterna viene anche frequentemente utilizzata dal programma di ottimizzazione
del query per migliorarne le prestazioni. In molti casi, le regole di applicazione delle chiavi esterne
utilizzano le tabelle di riferimento.
Scopo
|
Per migliorare le strutture dati del database in relazione alle prestazioni.
|
Nel caso di un modello dati relazionale, la mappatura iniziale produce generalmente una semplice associazione "classe a
tabella". Se è necessario richiamare contemporaneamente gli oggetti da classi diversi, il sistema RDBMS utilizza
un'operazione definita "unione tabella" per richiamare le righe associate agli oggetti di interesse. Per dati acceduti
con frequenza, le operazioni di unione possono determinare elaborazioni dispendiose. Per eliminare il costo
dell'operazione di unione, viene spesso utilizzata una tecnica relazionale standard definita "denormalizzazione".
La denormalizzazione unisce le colonne provenienti da due o più tabelle diverse nella stessa tabella, pre-unendo
efficacemente le informazioni. La denormalizzazione rispecchia un compromesso tra le operazioni di aggiornamento più
dispendiose in favore delle operazioni di richiamo meno dispendiose. Inoltre, questa tecnica riduce le prestazioni del
sistema in query che sono solo interessate agli attributi di uno degli oggetti che sono completamente uniti nella
tabella denormalizzata, dal momento che gli attributi sono normalmente richiamati in ogni query. Nei casi in cui
l'applicazione desidera normalmente tutti gli attributi, si può avere un significativo miglioramento delle prestazioni.
Il processo di denormalizzazione di più di due tabelle è raro e aumenta il costo degll'inserimento e degli
aggiornamenti così come il costo delle query non unite. Limitare la denormalizzazione a due tabelle è un buon criterio
a meno che non vengano prodotte delle prove forti e convincenti riguardanti i vantaggi.
La denormalizzazione può essere dedotta dalle classi di
progettazione nei casi in cui le classi sono nidificate. Le classi nidificate possono essere associate a una
tabella denormalizzata.
Alcuni database di oggetti adottano un concetto simile alla denormalizzazione, in cui gli oggetti correlati sono
raggruppati sul disco e richiamati in operazioni singole. Il concetto di utilizzo è analogo: ridurre il tempo di
richiamo dell'oggetto diminuendo il lavoro che il sistema deve eseguire per richiamare gli oggetti correlati dal
database.
In alcuni casi, l'ottimizzazione del modello dati può smascherare i problemi nel modello di
progettazione, inclusi i colli di bottiglia nelle prestazioni, una carente modellazione o le progettazioni
incomplete. In questo caso, discutere i problemi con il progettista della
classe, attivando le richieste di modifica.
Scopo
|
Per consentire un accesso dati efficace utilizzando l'indicizzazione.
Per consentire un accesso dati efficace utilizzando le viste del database.
|
Una volta progettata la struttura della tabella, è necessario stabilire i tipi di query che saranno eseguiti rispetto
ai dati. L'indicizzazione è utilizzata dal database per velocizzare l'accesso. L'operazione di indicizzazione è più
efficace quando i valori dei dati nella colonna da indicizzare sono relativamente diversi.
Considerare i seguenti principi di indicizzazione:
-
La colonna della chiave primaria della tabella deve essere sempre indicizzata. Le colonne della chiave primaria
sono utilizzate frequentemente come chiavi di ricerca e per operazioni di unione.
-
Le tabelle inferiori alle 100 righe di dimensione con solo alcune colonne presentano un minore beneficio
dall'indicizzazione. Alcune tabelle generalmente si adattano facilmente alla cache del database.
-
Gli indici devono essere definiti anche per le query eseguite frequentemente oppure per le query che devono
richiamare i dati rapidamente (di solito, una qualsiasi ricerca effettuata mentre una persona è in attesa). E'
possibile definire un indice per ciascuna serie di attributi che sono utilizzati insieme come criterio di ricerca.
Ad esempio, se il sistema deve individuare tutti gli ordini in cui un particolare prodotto è ordinato, è necessario
un indice nella tabella Elemento riga della colonna del numero prodotto.
-
Gli indici vanno generalmente definiti solo nelle colonne utilizzate come identificatori e non sui valori numerici,
come il saldo del conto o sulle informazioni testuali come i commenti dell'ordine. I valori identificatori della
colonna tendono ad essere assegnati quando viene creato l'oggetto e restano invariati per tutto il ciclo vitale
dell'oggetto.
-
L'indicizzazione di numeri semplici (tipi di dati numerici e interi) è molto più agevole e veloce rispetto agli
indici eseguiti sulle stringhe. Dato il volume di dati più grande elaborato su una query o un comando di unione
(join) esteso, i salvataggi di piccole entità si sommeranno rapidamente. Gli indici sulle colonne numeriche
tendono ad occupare significativamente meno spazio rispetto agli indici eseguiti sui caratteri.
D'altro canto, l'utilizzo di indici non è indipendente; quanti più indici sono presenti in una tabella, maggiore è il
tempo di elaborazione degli inserimenti e aggiornamenti. Quando si pianifica l'uso degli indici, tenere presente le
seguenti precauzioni:
-
Non eseguire l'indicizzazione soltanto per rendere più rapido una query eseguita raramente, a meno che la query non
sia richiesta in un punto critico, rendendo essenziale la massima velocità.
-
In alcuni sistemi, le prestazioni dell'aggiornamento e dell'inserimento sono più importanti di quelle della query.
Un esempio comune si trova nelle applicazioni di acquisizione dei dati aziendali in cui i dati sulla qualità sono
catturati in tempo reale. In questi sistemi vengono eseguite soltanto le query in linea saltuarie e la maggior
parte dei dati viene analizzata in modo periodico mediante applicazioni di notifica in batch che eseguono analisi
statistici sui dati. Per i sistemi di acquisizione dei dati, rimuovere tutti gli indici per ottenere la massima
velocità di elaborazione. Se gli indici sono richiesti, essi possono essere ricreati appena prima dell'esecuzione
della notifica di prospetti in batch e delle applicazioni di analisi, quindi eliminati quando vengono completate la
notifica del prospetto e l'analisi.
-
Tenere sempre presente che gli indici hanno costi nascosti. Ad esempio, richiedono del tempo per essere aggiornati
(una tassa pagata per ogni inserimento, aggiornamento o eliminazione) e occupano spazio su disco. Accertarsi che il
loro utilizzo porti valore.
Molti database offrono una scelta di tipi di indice. I più comuni includono:
-
Indici B-treeI tipi più frequentemente utilizzati si basano sulle strutture dati d'indice b-tree bilanciate.
Sono molto utili quando i valori chiave dell'indice sono casualmente distribuiti e tendono ad avere un'ampia
variabilità. Tendono ad avere scarse prestazioni tuttavia quando i dati da indicizzare sono già in ordine
sequenziale.
-
Indici di tipo hashMeno frequenti, i valori chiave dell'indice sono di tipo hash. Offrono migliori
prestazioni quando l'intervallo dei valori chiave dell'indice è noto, relativamente senza modifiche e univoco.
Questa tecnica si affida all'uso del valore chiave per calcolare l'indirizzo dei dati di interesse. Poiché il
concetto della prevedibilità è importane, gli indici hash tendono ad essere utili solo per tabelle di ricerca di
medie dimensioni che vengono modificate raramente.
La scelta di una strategia di indicizzazione e di tempificazione della creazione dell'indice possono avere un enorme
impatto sulle prestazioni. Il caricamento di elevate quantità di dati deve essere eseguito senza gli indici (ciò può
essere ottenuto rilasciando l'indice, caricando i dati e quindi ricreando l'indice). Il motivo è che la struttura
dell'indice viene nuovamente bilanciata mentre si aggiunge ogni riga. Poiché le successive righe modificheranno la
struttura ottimale dell'indice, il lavoro eseguito per bilanciare nuovamente l'indice mentre ogni riga viene inserita è
ampiamente perduto. E' più rapido ed efficiente caricare i dati senza gli indici, quindi ricreare l'indice quando è
terminato il caricamento dei dati. Alcuni database forniscono dei programmi di caricamento dati estesi in modo
automatico.
Un'altra strategia per ottimizzare le prestazioni di accesso al database è l'utilizzo delle viste. Le viste di database
sono tabelle virtuali che non dispongono di una propria memoria indipendente. Per il programma di chiamata (o utente),
tuttavia, una vista si comporta come una tabella. Una vista supporta il recupero dei dati e può essere utilizzata per
aggiornare i dati (a seconda della struttura e del vendor del database). La vista contiene dati da una o più tabelle
accessibili tramite una singola istruzione di selezione (select). L'aumento delle prestazioni si ottiene durante la
selezione dei dati, specialmente nelle tabelle di cui si esegue frequentemente il query. I dati vengono richiamati da
una singola ubicazione - la vista - piuttosto che ricercando le tabelle multiple o estese che sono presenti nel
database.
Le viste giocano anche un ruolo importante nella protezione del database. Una vista contenente parti di una tabella può
limitare l'accesso a dati sensibili contenuti nella tabella base.
Scopo
|
Per definire l'assegnazione dello spazio e l'organizzazione della pagina su disco del database.
|
Un progettista di database utilizza i tablespace per rappresentare la quantità di spazio di memoria che viene assegnata
alle tabelle, agli indici, alle procedure memorizzate e così via. Uno o più tablespace sono associati a un database. Il
progettista di database deve analizzare le tabelle nel modello dati per determinare il modo in cui occorre distribuirle
insieme agli altri elementi del database di supporto, in tutto lo spazio di memoria del database.
Nel determinare le strutture tablespace per il database, tenere presente che i database non eseguono operazioni I/O
sulle righe, sui record oppure sulle intere tabelle. Invece, i database eseguono operazioni di I/O sui blocchi del
disco. Il motivo è semplice: le operazioni I/O sul blocco sono generalmente ottimizzate nel software e nell'hardware
del sistema. Come risultato, l'organizzazione fisica delle tabelle e degli indici nel database può avere un impatto
notevole sulle prestazioni del sistema.
Quando si pianificano l'assegnazione dello spazio e l'organizzazione della pagina su disco del database, tenere
presente i seguenti fattori:
-
la densità delle informazioni nelle pagine del disco
-
l'ubicazione delle pagine sul disco o su più dischi
-
la quantità di spazio sul disco da assegnare alla tabella
Questi fattori vengono discussi nelle sezioni che seguono.
Densità pagina sul disco
La densità delle pagine sul disco dipende dalla misura con cui sono previste modifiche ai dati nel tempo.
Fondamentalmente, una pagina con densità inferiore è maggiormente in grado di accettare modifiche di valori oppure
l'aggiunta di dati nel tempo, mentre una pagina di dati completa fornisce una migliore prestazione in lettura,
poiché vengono richiamati più dati per lettura blocco.
Per rendere più semplice la gestione del disco, il progettista di database può raggruppare le tabelle nella misura
in cui tendono a modificare. I seguenti tre gruppi costituiscono un buon inizio per questo tipo di organizzazione:
-
tabelle altamente dinamiche
-
tabelle alquanto dinamiche
-
tabelle maggiormente statiche
Le tabelle altamente dinamiche devono essere associate alle pagine su disco che hanno un'enorme quantità di spazio
libero (probabilmente 30%); le tabelle alquanto dinamiche devono essere associate alle pagine su disco che hanno
meno spazio libero (probabilmente 15%); e la tabella più statica deve essere associata alle pagine su disco che
hanno veramente poco spazio libero (probabilmente 5%). Gli indici per le tabelle devono essere associati in modo
analogo.
Ubicazione pagina sul disco
Dopo l'associazione dei gruppi di tabelle, il progettista di database deve stabilire l'ubicazione in cui collocare
le pagine sul disco. L'obiettivo è di bilanciare il carico di lavoro su un numero di svariate unità e testine al
fine di ridurre o eliminare i colli di bottiglia. Considerare le seguenti linee guida:
-
Mai collocare i dati sullo stesso disco del sistema operativo, dei relativi file temporanei o delle unità di
swap. Queste unità sono abbastanza impegnate senza dover aggiungere ulteriore carico di lavoro.
-
Collocare i dati acceduti simultaneamente su diverse unità in modo da bilanciare il carico di lavoro. Alcuni
sistemi supportano i canali I/O paralleli. In tal caso, collocare i dati su canali diversi.
-
Collocare gli indici su un'unità diversa dai dati di cui crea l'indice per poter distribuire il carico di
lavoro.
-
Fare riferimento alla documentazione del fornitore del database per le linee guida.
-
Il tipo di memoria utilizzata (ad esempio RAID-5, RAID-10, SAN, NAS e canale collegato) influisce sulle
prestazioni del database. Utilizzare le indicazioni sulle prestazioni fornite dal fornitore di memoria.
L'I/O del database è generalmente il fattore limitante nelle prestazioni del database. Il bilanciamento I/O è un
processo iterativo e sperimentale. Mediante creazione dei prototipi per le prestazioni di accesso al database
durante la fase di elaborazione, insieme all'appropriata strumentazione per il controllo dell'I/O fisico e logico,
è possibile rilevare in anticipo i problemi di prestazioni mentre vi è ancora tempo per modificare la progettazione
del database.
Allocazione di spazio su disco
Utilizzando le caratteristiche del meccanismo di progettazione della persistenza, valutare il numero di oggetti che
deve essere memorizzato. La quantità di spazio su disco richiesta per memorizzare gli oggetti varia da RDBMS a
RDBMS. Quando si calcola lo spazio su disco, accertarsi di stimare la crescita dovuta alle aggiunte di
dati. Per stimare lo spazio su disco per un database, è necessario prima stimare lo spazio su disco richiesto
per ciascuna tabella e poi calcolare i requisiti di spazio per tutte le tabelle. Consultare il manuale
dell'amministratore di database per il prodotto RDBMS specifico al fine di determinare la formula esatta di stima
della dimensione. Di seguito sono riportate alcune procedure generali di stima dei requisiti di spazio per
una tabella:
-
Calcolare la dimensione media della riga. Questo calcolo deve includere tutte le informazioni di
controllo a livello di record, oltre a tutte le informazioni di controllo richieste per le colonne con
lunghezza variabile.
-
Calcolare il numero di righe che si adattano ad una pagina o un blocco di I/O. Poiché la maggior parte dei
database memorizza soltanto record completi su una pagina o un blocco di I/O, occorre che vi sia un numero
intero di righe che dovranno adattarsi ad una pagina o un blocco di I/O.
-
Calcolare il numero di pagine o blocchi di I/O richiesto per memorizzare il numero stimato di record nel
database. Il numero stimato di record deve includere tutti i fattori di caricamento.
-
Moltiplicare il numero di pagine o blocchi di I/O richiesto per la dimensione della pagina o del blocco I/O.
-
Aggiungere eventuali eccessi per gli indici aggiuntivi.
-
Aggiungere un qualsiasi eccesso prefissato per la tabella.
Una volta che i requisiti dello spazio tabella sono stati definiti:
-
Calcolare la somma dello spazio richiesto dalle tabelle.
-
Aggiungere tutte le quantità fisse di spazio richieste per la gestione del database.
-
Aggiungere lo spazio disco richiesto per la registrazione della transazione e la traccia di controllo.
In un ambiente aggiornato frequentemente, i requisiti di retenzione per la traccia di controllo richiedono quantità
significative di memoria. La documentazione per i principali sistemi di gestione dei database commerciali fornisce
solitamente istruzioni dettagliate di dimensionamento. Accertarsi di consultare queste istruzioni quando si
calcolano le stime dei requisiti di spazio su disco del database.
Scopo
|
Per stabilire se le procedure memorizzate o i trigger devono essere utilizzati per implementare le
operazioni sulla classe di accesso dei dati.
|
Gran parte dei database supporta un funzione di procedura memorizzata. Una procedura memorizzata è un codice eseguibile
avviato all'interno dello spazio dei processi di un sistema di gestione del database. Consente di eseguire le azioni
associate al database sul server senza dover trasferire i dati su una rete. L'utilizzo giudizioso delle procedure
memorizzate può migliorare le prestazioni del sistema.
Le procedure memorizzate sono normalmente di due tipi: procedure effettive o trigger. Le procedure sono eseguite
esplicitamente da un'applicazione, generalmente hanno dei parametri e forniscono un valore di ritorno specifico. I
trigger, d'altro canto, sono richiamati implicitamente quando si verificano degli eventi del database (ad esempio,
inserire una riga, aggiornarla o eliminarla), non hanno parametri oltre che la riga modificata (poiché sono richiamati
implicitamente) e non forniscono un valore di ritorno specifico.
Nei sistemi di database che mancano di vincoli, i triggers sono spesso utilizzati per applicare l'integrità
referenziale e dei dati. Altrimenti, essi tendono ad essere utilizzati quando un evento deve attivare (o causare) un
altro evento. I trigger sono spesso utilizzati anche per motivi di sicurezza mediante controllo dell'evento di
attivazione.
E' necessario controllare le classi nel modello di progettazione per rilevare se hanno delle operazioni che vanno
implementate utilizzando la funzione procedura memorizzata o trigger. I candidati comprendono:
-
tutte le operazioni che si occupano principalmente dei dati permanenti (creazione, aggiornamento, richiamo o
cancellazione).
-
tutte le operazioni in cui un query è occupato in un calcolo (come il calcolo della quantità media e del valore di
un prodotto nell'inventario).
-
le operazioni che devono accedere al database per poter convalidare i dati.
Da tenere presente che il miglioramento delle prestazioni del database significa di solito ridurre l'I/O. Pertanto, se
l'esecuzione di un calcolo sul server DBMS ridurrà la quantità di dati trasferita sulla rete, il calcolo dovrebbe
probabilmente essere eseguito sul server.
Collaborare con il progettista della classe di progettazione per discutere in che modo è possibile utilizzare il
database per migliorare le prestazioni. Il progettista aggiornerà il metodo di operazione per indicare se una o più
procedure memorizzate possono essere utilizzate per implementare l'operazione.
|