Attività di base nella progettazione di database

1.1 Introduzione

La progettazione di un database è in qualche modo simile alla progettazione dell'architettura di un progetto Java. Puoi inserire tutti i dati in un paio di tabelle oppure puoi creare una bellissima struttura di dati da schemi e dozzine di tabelle.

Ecco le attività che uno sviluppatore di solito deve affrontare durante la progettazione di un database:

1. Garantire che tutte le informazioni necessarie siano memorizzate nel database.
2. Garantire la possibilità di ottenere dati su tutte le richieste necessarie.
3. Riduzione della ridondanza e della duplicazione dei dati.
4. Garantire l'integrità del database
5. Ottimizzazione della velocità di accesso ai dati

La cosa principale da ricordare è che non puoi creare una struttura di database ideale, perché. anch'esso, come il tuo codice, cambierà costantemente. Ci sono tre cose che dovresti tenere a mente quando progetti la struttura del tuo database:

1. La struttura deve essere abbastanza buona.
2. Deve esserci una logica in tutto ciò che gli altri possono capire.
3. L'ottimizzazione prematura è la radice di tutti i mali.

Non devi creare la migliore struttura di database al mondo. Lei cambierà ancora. Il tuo compito è assicurarti che dopo 20 modifiche alla struttura del tuo database, sia abbastanza facile capirlo.

Molto probabilmente nei primi anni del tuo lavoro nessuno si fiderà di te per progettare una base da zero. Apporterai modifiche a uno schema esistente. Devi cercare di capire in base a quali principi è organizzato e aderirvi . Con il loro statuto, non entrano nel monastero di qualcun altro.

Non ottimizzare il database finché non è necessario. Se la tabella ha solo un paio di centinaia di righe, molto probabilmente il DBMS la manterrà in memoria e memorizzerà nella cache le query.

D'altra parte, dovresti essere in grado di accelerare il lavoro di richieste importanti di decine o addirittura centinaia di volte. E sarebbe bello se tu sapessi come farlo. Come si dice al liceo al primo anno? "Dimentica tutto quello che ti è stato insegnato a scuola..."

Se sai cos'è la normalizzazione del database, allora mi affretto a farti piacere, nel tuo lavoro molto probabilmente ti occuperai di denormalizzazione . Niente è più importante per i santuari del progetto della velocità del database. E se, per accelerare la selezione dei dati dal database, devi combinare 200 (!) Tabelle in una (con mostruosa ridondanza), dovrai farlo.

1.2 Progettazione della libreria

Immergiamoci un po' nell'area tematica e pensiamo alla progettazione di database utilizzando qualcosa di semplice come una tipica libreria di libri.

Il compito principale di qualsiasi biblioteca è l'elaborazione del fondo del libro. È facile distinguere tre gruppi principali di utenti del sistema: lettore, bibliotecario, amministratore . L'attività di ciascuno è mostrata in un diagramma dei casi d'uso.

Già ora si possono distinguere alcune entità e relazioni del futuro database:

Con questo approccio, non è chiaro come collegare il lettore al libro (il lettore non ha un'arietà nella relazione "emissione / ricezione". Se il libro ha più copie, allora può essere rilasciato a più lettori. Anche se un libro è inteso come una copia, una volta salvato nella tabella dei libri del lettore attuale, sarà impossibile ottenere informazioni su chi (e quante volte) ha preso questo libro prima.

La soluzione potrebbe essere l'introduzione di un'entità aggiuntiva : una carta per l'emissione di un libro. Quando il libro viene rilasciato al lettore, viene creata una carta e quando il libro viene consegnato, viene apposto un segno corrispondente. Con l'ausilio di queste carte si determinano i debiti di ciascun utente e si calcolano le statistiche sull'utilizzo dei libri. Quando si prenota la letteratura da parte del lettore, viene avviata anche una carta; se la letteratura prenotata non viene ritirata dal lettore entro un certo periodo, la carta viene distrutta. C'è un limite al numero di libri che un lettore può prenotare.

Selezionando la letteratura, l'utente visualizza il catalogo della letteratura con la possibilità di filtrare i risultati della ricerca per autore, titolo, anno di pubblicazione.

È possibile calcolare le statistiche per tutti i libri della biblioteca, mentre il numero di copie emesse del libro per un determinato periodo di tempo. È inoltre possibile impostare il numero minimo di istanze del libro per le quali viene eseguito il calcolo. Sulla base di queste statistiche, i libri inutilizzati vengono cancellati dalla biblioteca.

Si possono distinguere le seguenti entità principali dell'area tematica:

• utente (bibliotecari e amministratori);
• lettore;
• sala lettura;
• libro;
• carta di emissione del libro;
• carta di prenotazione del libro.

Il diagramma ER modificato del database è mostrato nella figura.

Secondo i casi d'uso mostrati nella Figura 1, il database dovrebbe implementare le seguenti query (elenco non esaustivo):

• visualizzare libri che soddisfano le condizioni specificate;
• visualizzare gli utenti che hanno carte per l'emissione di libri che non sono stati chiusi in tempo (il bibliotecario cerca debitori);
• visualizzare tutti i libri che corrispondono alle carte di prestito libri dell'utente che non sono state chiuse in tempo (l'utente è venuto in biblioteca per nuovi libri - è necessario vedere se è un debitore e informarlo);
• eliminare tutte le schede di prenotazione create più di N secondi fa;
• visualizzare tutti i libri corrispondenti alle schede di prenotazione dei libri non chiuse dell'utente specificato (il lettore ha ordinato i libri ed è venuto in biblioteca per loro - il bibliotecario deve ottenere questo elenco per poterlo distribuire).

1.3 Formazione dello schema

Per formare uno schema di dati, devi prima integrare il diagramma ER con i dettagli delle entità (perfezionarlo). A volte, allo stesso tempo, è possibile trovare errori nella costruzione di un diagramma ER: in questo compito si è scoperto che il libro doveva essere "in qualche modo" collegato alla sala della biblioteca.

Questo può essere fatto inserendo il “numero di sala” richiesto nel libro, tuttavia, con questo approccio, lo stesso libro dovrà essere descritto più volte nel database (se si verifica in sale diverse). Un approccio più corretto consiste nell'introdurre un'entità aggiuntiva "book placement". La figura mostra un diagramma ER con un'entità aggiunta e oggetti di scena.

Il diagramma ER sopra riportato riflette le tabelle, le relazioni e gli attributi principali; sulla sua base, è possibile costruire un modello di database. Non esiste uno standard per il diagramma ER, ma esistono numerose notazioni (Chen, IDEFIX, Martin, ecc.), ma non è stato possibile trovare né lo standard né le notazioni per il modello di dominio. Tuttavia, nel corso della costruzione di un tale diagramma, vengono necessariamente evidenziati i campi chiave (esterni e interni), a volte indici e tipi di dati.

In questo caso, nello schema seguente:

• per i link si usa la notazione di Martin ("zampe di gallina");
• le tabelle sono mostrate come rettangoli divisi in 3 sezioni:
• nome della tabella;
• chiavi interne (contrassegnate da un pennarello);
• i restanti campi, mentre quelli obbligatori sono contrassegnati da un pennarello.

Durante lo sviluppo di questo modello, c'era il desiderio di unire la tabella degli amministratori con la tabella dei bibliotecari - aggiungi la tabella degli utenti, tuttavia:

• l'amministratore non è associato a una stanza specifica (dovresti compilare il campo corrispondente con valori nulli);
• questo probabilmente complicherebbe la distribuzione dei diritti di accesso - ora solo l'amministratore del database (che lavora tramite un apposito pannello DBMS e non ha un account nel sistema in fase di sviluppo) ha accesso alla tabella degli amministratori. Tuttavia, quando si uniscono le tabelle, le query degli utenti richiedono l'accesso alla nuova tabella.

Durante la costruzione di questo diagramma, è stato trovato e corretto un difetto nel diagramma ER: è stata aggiunta una tabella librarians_roomsche unisce bibliotecari e sale. Questo è necessario perché un bibliotecario può lavorare in più stanze, ma più bibliotecari possono lavorare nella stessa stanza.

Quando si progettano database, dovresti essere in grado di ragionare almeno come nell'esempio sopra. Se pensi di esserci riuscito, andiamo oltre: ancora più teoria.