Viene chiamata la relazione contenente la chiave esterna. Vincoli di chiave primaria e esterna. Fig.3.4. Insieme di relazioni normalizzato

Ultimo aggiornamento: 07/02/2017

I database possono contenere tabelle interconnesse da vari collegamenti. Una relazione rappresenta un'associazione tra entità di tipo diverso.

Quando si seleziona una relazione, vengono selezionate una tabella primaria o principale (tabella della chiave primaria/tabella principale) e una tabella secondaria dipendente (tabella della chiave esterna/tabella secondaria). La tabella figlia dipende dalla tabella genitore.

Le chiavi esterne vengono utilizzate per organizzare la comunicazione. Una chiave esterna rappresenta una o più colonne di una tabella che è anche una potenziale chiave di un'altra tabella. La chiave esterna non deve corrispondere alla chiave primaria della tabella principale. Sebbene, di regola, la chiave esterna della tabella dipendente punti alla chiave primaria della tabella principale.

Le relazioni tra le tabelle sono dei seguenti tipi:

Uno a uno

Uno a molti

molti a molti(Molti a molti)

Comunicazione uno a uno

Questo tipo di connessione non si trova spesso. In questo caso un oggetto di un'entità può essere associato solo ad un oggetto di un'altra entità. Ad esempio, su alcuni siti un utente può avere un solo blog. Cioè, nasce una relazione: un utente - un blog.

Spesso questo tipo di relazione comporta la suddivisione di una tabella grande in più tabelle piccole. La tabella padre primaria in questo caso continua a contenere dati a cui si accede frequentemente, mentre la tabella dipendente figlio in genere archivia i dati a cui si accede meno frequentemente.

A questo proposito, la chiave primaria della tabella dipendente è allo stesso tempo una chiave esterna che fa riferimento alla chiave primaria della tabella principale.

Ad esempio, la tabella Utenti rappresenta gli utenti e presenta le seguenti colonne:

UserId(id, chiave primaria)

Nome (nome utente)

La tabella Blog rappresenta i blog degli utenti e presenta le seguenti colonne:

BlogId (identificatore, chiave primaria e esterna)

Nome (nome del blog)

In questo caso, la colonna BlogId memorizzerà il valore della colonna UserId dalla tabella users. Cioè, la colonna BlogId fungerà sia da chiave primaria che da chiave esterna.

Relazione uno a molti

Questo è il tipo di connessione più comune. In questo tipo di relazione, più righe di una tabella figlio dipendono da una singola riga nella tabella padre. Ad esempio, un blog può contenere diversi articoli. In questo caso, la tabella blog è la tabella genitore e la tabella articoli è la figlia. Cioè, un blog - molti articoli. Oppure, per fare un altro esempio, diversi giocatori di football possono giocare in una squadra di calcio. E allo stesso tempo, un giocatore di football può giocare solo in una squadra alla volta. Cioè, una squadra, molti giocatori.

Ad esempio, abbiamo una tabella denominata Articoli che rappresenta gli articoli del blog e ha le seguenti colonne:

ArticoloId(id, chiave primaria)

BlogId (chiave esterna)

Titolo (titolo dell'articolo)

Testo (testo dell'articolo)

In questo caso, la colonna BlogId della tabella articoli memorizzerà il valore della colonna BlogId della tabella blogs.

relazione molti a molti

Con questo tipo di relazione, una riga della tabella A può essere associata a molte righe della tabella B. A sua volta, una riga della tabella B può essere associata a molte righe della tabella A. Un tipico esempio sono gli studenti e i corsi: uno studente può seguire diversi corsi e di conseguenza più studenti possono iscriversi a un corso.

Un altro esempio sono gli articoli e i tag: è possibile definire più tag per un articolo e un tag per diversi articoli.

Ma in SQL Server, a livello di database, non è possibile stabilire una relazione diretta molti-a-molti tra due tabelle. Questo viene fatto attraverso una tabella di staging ausiliaria. A volte i dati di questa tabella di staging rappresentano un'entità separata.

Ad esempio, nel caso di articoli e tag, lascia che ci sia una tabella Tags che abbia due colonne:

TagId(identificatore, chiave primaria)

Testo (testo tag)

Lascia anche che ci sia una tabella intermedia ArticleTags con i seguenti campi:

TagId (identificatore, chiave primaria e esterna)

ArticleIdId (identificatore, chiave primaria ed esterna)

Tecnicamente, otterremo due relazioni uno-a-molti. La colonna TagId della tabella ArticleTags farà riferimento alla colonna TagId della tabella Tags. Inoltre, la colonna ArticleId della tabella ArticleTags farà riferimento alla colonna ArticleId della tabella Articles. Ciò significa che le colonne TagId e ArticleId nella tabella ArticleTags rappresentano una chiave primaria composita e sono anche chiavi esterne per la relazione con le tabelle Articles e Tags.

Integrità referenziale dei dati

Quando si modificano le chiavi primarie ed esterne, è necessario osservare il seguente aspetto: integrità referenziale dei dati(integrità referenziale). La sua idea di base è che due tabelle in un database memorizzino gli stessi dati per mantenere la coerenza. L'integrità dei dati rappresenta relazioni costruite correttamente tra tabelle con collegamenti corretti tra di loro. In quali casi può essere violata l’integrità dei dati:

Anomalia di cancellazione(anomalia di cancellazione). Si verifica quando una riga viene eliminata dalla tabella principale. In questo caso, la chiave esterna della tabella dipendente continua a fare riferimento alla riga eliminata dalla tabella principale

Anomalia di inserimento(anomalia di inserimento). Si verifica quando una riga viene inserita in una tabella dipendente. In questo caso, la chiave esterna della tabella dipendente non corrisponde alla chiave primaria di nessuna delle righe della tabella principale.

Aggiornare le anomalie(anomalia dell'aggiornamento). Con tale anomalia, più righe della stessa tabella possono contenere dati che appartengono allo stesso oggetto. Quando modifichi i dati in una riga, potrebbero entrare in conflitto con i dati in un'altra riga.

Anomalia di cancellazione

Per risolvere un'anomalia di cancellazione è necessario impostare uno dei due vincoli su una chiave esterna:

Se una riga di una tabella dipendente richiede necessariamente una riga della tabella principale, viene impostata un'eliminazione a cascata per la chiave esterna. Cioè, quando una riga viene eliminata dalla tabella principale, le righe associate vengono eliminate dalla tabella dipendente.

Se una riga di una tabella dipendente non consente alcuna relazione con una riga della tabella principale (ovvero, tale relazione è facoltativa), la chiave esterna viene impostata su NULL quando la riga correlata viene eliminata dalla tabella principale. In questo caso, la colonna della chiave esterna deve essere nullable.

Anomalia di inserimento

Per risolvere un'anomalia di inserimento durante l'aggiunta di dati a una tabella dipendente, la colonna che rappresenta la chiave esterna deve essere nullable. Pertanto, se l'oggetto aggiunto non ha alcuna connessione con la tabella principale, la colonna della chiave esterna conterrà un valore NULL.

Aggiornare le anomalie

Per risolvere il problema dell'anomalia dell'aggiornamento viene utilizzata la normalizzazione, di cui parleremo più avanti.

Ultimo aggiornamento: 27/04/2019

Le chiavi esterne consentono di stabilire relazioni tra tabelle. Una chiave esterna viene impostata sulle colonne di una tabella dipendente e subordinata e punta a una delle colonne della tabella principale. In genere, una chiave esterna punta a una chiave primaria da una tabella principale correlata.

La sintassi generale per impostare una chiave esterna a livello di tabella è:

CHIAVE ESTERA (colonna1, colonna2, ... colonnaN) RIFERIMENTI main_table (main_table_column1, main_table_column2, ... main_table_columnN)

Per creare un vincolo di chiave esterna, dopo FOREIGN KEY specificare la colonna della tabella che rappresenterà la chiave esterna. E dopo la parola chiave REFERENCES, viene indicato il nome della tabella correlata, quindi tra parentesi il nome della colonna correlata a cui punterà la chiave esterna. Dopo l'espressione REFERENCES ci sono le espressioni ON DELETE e ON UPDATE, che specificano rispettivamente l'azione quando si elimina e si aggiorna una riga dalla tabella principale.

Ad esempio, definiamo due tabelle e le colleghiamo utilizzando una chiave esterna:

CREATE TABLE Clienti (Id INT PRIMARY KEY AUTO_INCREMENT, Età INT, Nome VARCHAR(20) NOT NULL, Cognome VARCHAR(20) NOT NULL, Telefono VARCHAR(20) NOT NULL UNIQUE); CREATE TABLE Ordini (Id INT PRIMARY KEY AUTO_INCREMENT, CustomerId INT, CreatedAt Date, FOREIGN KEY (CustomerId) REFERENCES Clienti (Id));

In questo caso vengono definite le tabelle Clienti e Ordini. Clienti è il principale e rappresenta il cliente. Gli ordini sono dipendenti e rappresentano l'ordine effettuato dal cliente. La tabella Orders è collegata tramite la colonna CustomerId alla tabella Customers e alla relativa colonna Id. La colonna CustomerId è cioè una chiave esterna che punta alla colonna Id della tabella Customers.

È possibile utilizzare l'operatore CONSTRAINT per specificare un nome per un vincolo di chiave esterna:

CREATE TABLE Ordini (Id INT PRIMARY KEY AUTO_INCREMENT, CustomerId INT, CreatedAt Date, CONSTRAINT Orders_custonmers_fk FOREIGN KEY (CustomerId) REFERENCES Clienti (Id));

IN CANCELLAZIONE e IN AGGIORNAMENTO

Utilizzando le istruzioni ON DELETE e ON UPDATE, è possibile impostare le azioni che vengono eseguite quando una riga correlata viene rispettivamente eliminata o modificata dalla tabella principale. Le seguenti opzioni possono essere utilizzate come azione:

CASCADE: elimina o modifica automaticamente le righe da una tabella dipendente quando le righe correlate nella tabella principale vengono eliminate o modificate.

SET NULL: quando si elimina o si aggiorna una riga correlata dalla tabella principale, imposta la colonna della chiave esterna su NULL. (In questo caso, la colonna della chiave esterna deve supportare l'impostazione NULL)

RESTRICT: rifiuta l'eliminazione o la modifica di righe nella tabella principale se sono presenti righe correlate nella tabella dipendente.

NESSUNA AZIONE: uguale a LIMITA.

SET DEFAULT: quando si elimina una riga correlata dalla tabella principale, imposta la colonna della chiave esterna sul valore predefinito specificato utilizzando l'attributo DEFAULT. Nonostante questa opzione sia disponibile in linea di principio, il motore InnoDB non supporta questa espressione.

Cancellazione a cascata

L'eliminazione a catena consente di eliminare automaticamente tutte le righe correlate dalla tabella dipendente quando elimini una riga dalla tabella principale. Per fare ciò, utilizzare l'opzione CASCADE:

CREATE TABLE Ordini (Id INT PRIMARY KEY AUTO_INCREMENT, CustomerId INT, CreatedAt Date, FOREIGN KEY (CustomerId) REFERENCES Clienti (Id) ON DELETE CASCADE);

L'espressione ON UPDATE CASCADE funziona in modo simile. Quando modifichi il valore di una chiave primaria, il valore della chiave esterna associata cambia automaticamente. Tuttavia, poiché le chiavi primarie cambiano molto raramente e generalmente non è consigliabile utilizzare colonne con valori modificabili come chiavi primarie, nella pratica l'espressione ON UPDATE viene utilizzata raramente.

Impostazione NULL

Quando imposti l'opzione SET NULL per una chiave esterna, la colonna della chiave esterna deve contenere NULL:

CREATE TABLE Ordini (Id INT PRIMARY KEY AUTO_INCREMENT, CustomerId INT, CreatedAt Date, FOREIGN KEY (CustomerId) REFERENCES Clienti (Id) ON DELETE SET NULL);

La Figura mostra una tabella (un rapporto di grado 5) contenente alcune informazioni sui dipendenti di un'ipotetica impresa. Le righe della tabella corrispondono alle tuple. Ogni riga è in realtà la descrizione di un oggetto del mondo reale (in questo caso un dipendente), le cui caratteristiche sono contenute nelle colonne. Le relazioni relazionali corrispondono a insiemi di entità e le tuple corrispondono a entità. Vengono chiamate le colonne di una tabella che rappresentano una relazione relazionale attributi.

Ogni attributo è definito su un dominio, quindi un dominio può essere pensato come l'insieme di valori validi per un dato attributo. Nello stesso dominio è possibile definire più attributi della stessa relazione e persino attributi di relazioni diverse.

Viene chiamato un attributo il cui valore identifica univocamente le tuple chiave (o semplicemente chiave). La chiave è l'attributo Numero del personale, poiché il suo valore è univoco per ciascun dipendente dell'azienda. Se le tuple vengono identificate solo concatenando i valori di più attributi, allora si dice che la relazione ha una chiave composta.

Chiave primaria- in un modello di dati relazionale, una delle potenziali chiavi di una relazione, selezionata come chiave primaria (o chiave predefinita).

Una relazione può contenere più chiavi. Una delle chiavi viene sempre dichiarata primario, i suoi valori non possono essere aggiornati. Vengono chiamate tutte le altre chiavi di relazione possibili chiavi.

Da un punto di vista teorico, tutte le potenziali (possibili) chiavi di relazione sono equivalenti, cioè hanno le stesse proprietà di unicità e minimalità. Tuttavia, tra le chiavi potenziali, viene solitamente selezionata la chiave primaria più conveniente per determinati scopi pratici, ad esempio per la creazione esterno chiavi sotto altri aspetti o per creare un indice cluster. Pertanto, di regola, come chiave primaria viene scelta quella che ha la dimensione più piccola (memoria fisica) e/o include il minor numero di attributi.

Se chiave primariaè costituito da un singolo attributo, si chiama con una semplice chiave.

Se chiave primariaè costituito da due o più attributi, si chiama chiave composta. Pertanto, nome, cognome, patronimico, numero di passaporto, serie di passaporti non possono essere chiavi primarie individualmente, poiché potrebbero essere le stesse per due o più persone. Ma non esistono due documenti personali dello stesso tipo con la stessa serie e lo stesso numero. Pertanto, in una relazione contenente dati sulle persone, la chiave primaria può essere un sottoinsieme di attributi costituito dal tipo di documento personale, dalla sua serie e dal numero.

A differenza dei modelli gerarchici e di dati di rete, quello relazionale non ha il concetto di relazione di gruppo. Per riflettere le associazioni tra tuple di relazioni diverse, viene utilizzata la duplicazione delle loro chiavi.

Vengono chiamati gli attributi che sono copie di chiavi di altre relazioni chiavi straniere.

Ad esempio, la relazione tra le relazioni DEPARTMENT e EMPLOYEE viene creata copiando la chiave primaria "Numero_dipartimento" dalla prima relazione alla seconda. Pertanto per ottenere l'elenco dei dipendenti di un determinato dipartimento è necessario: 1) Dalla tabella DIPARTIMENTO impostare il valore dell'attributo "Numero_dipartimento" , corrispondente a questo "Nome_Dipartimento". 2) seleziona tutti i record dalla tabella DIPENDENTE, valore dell'attributo "Numero_dipartimento" che è uguale a quello ottenuto nel passaggio precedente. Per scoprire in quale reparto lavora un dipendente, è necessario eseguire l'operazione inversa: 1) Determinare "Numero_dipartimento" dalla tabella DIPENDENTE. 2) Utilizzando il valore ottenuto troviamo la voce nella tabella REPARTO.

18. Normalizzazione nei database relazionali, il concetto di forma normale nella progettazione di database.

Forma normale - una proprietà di una relazione in un modello di dati relazionale, che la caratterizza dal punto di vista della ridondanza, che può potenzialmente portare a risultati logicamente errati del campionamento o della modifica dei dati. La forma normale è definita come un insieme di requisiti che una relazione deve soddisfare.

Viene chiamato il processo di conversione di un database in forma normale normalizzazione . La normalizzazione ha lo scopo di portare la struttura del database in una forma che fornisca una ridondanza minima, ovvero la normalizzazione non è intesa a ridurre o aumentare la produttività del lavoro o ridurre o aumentare il volume del database. L'obiettivo finale della normalizzazione è ridurre la potenziale incoerenza delle informazioni archiviate nel database.

L'eliminazione della ridondanza viene effettuata, di regola, scomponendo le relazioni in modo tale che in ciascuna relazione siano memorizzati solo i fatti primari (cioè fatti che non sono dedotti da altri fatti memorizzati).

Dipendenze funzionali.

Un database relazionale contiene sia informazioni strutturali che semantiche. La struttura di un database è determinata dal numero e dal tipo di relazioni che contiene e dalle relazioni uno-a-molti che esistono tra le tuple di queste relazioni. La parte semantica descrive l'insieme delle dipendenze funzionali che esistono tra gli attributi di queste relazioni. Definiamo la dipendenza funzionale.

19. 1NF: Definizioni di base e regole di trasformazione.

Per discutere la prima forma normale sono necessarie due definizioni:

Attributo semplice - un attributo i cui valori sono atomici (indivisibili).

Attributo complesso - si ottiene collegando più attributi atomici che possono essere definiti sullo stesso o su domini diversi (è detto anche vettore o aggregato di dati).

Definizione di prima forma normale:

una relazione è in 1NF se i valori di tutti i suoi attributi sono atomici. . Altrimenti non è affatto una tabella e tali attributi devono essere scomposti.

Diamo un'occhiata ad un esempio:

Nel database del dipartimento Risorse umane dell'impresa, è necessario archiviare informazioni sui dipendenti che è possibile tentare di presentare in relazione a

DIPENDENTE(NUMERO_DIPENDENTE, NOME, DATA DI NASCITA, STORIA_LAVORO, FIGLI).

Da un'attenta considerazione di questa relazione ne consegue che gli attributi "storia del lavoro" E "bambini" sono complessi, inoltre, l'attributo "storia del lavoro" include un altro attributo complesso "stipendio_storia".
Queste unità hanno questo aspetto:

 CRONOLOGIA_LAVORO (DATA_RICEZIONE, NOME, CRONOLOGIA_STIPENDI),

 STORICO_STIPENDI (DATA_APPUNTAMENTO, STIPENDIO),

 BAMBINI (NOME_BAMBINO, ANNO_NASCIA).

La loro connessione è mostrata in Fig. 3.3.

Fig.3.3. Atteggiamento iniziale.

Per riportare la relazione originaria SERVO alla prima forma normale è necessario scomporla in quattro relazioni, come mostrato nella figura seguente:

Fig.3.4. Insieme di relazioni normalizzato.

Qui la chiave primaria di ciascuna relazione è evidenziata con una cornice blu, i nomi delle chiavi esterne sono in carattere blu. Ricordiamo che le chiavi esterne vengono utilizzate per rappresentare le dipendenze funzionali che esistono nella relazione di origine. Queste dipendenze funzionali sono indicate da linee con frecce.

L'algoritmo di normalizzazione è descritto da EF Codd come segue:

• Partendo dalla relazione in cima all'albero (Figura 3.3.), viene presa la sua chiave primaria, e ciascuna relazione immediatamente subordinata viene espansa inserendo un dominio o una combinazione di domini di quella chiave primaria.
• La Chiave Primaria di ciascuna relazione espansa in questo modo è costituita dalla Chiave Primaria che la relazione aveva prima dell'estensione e dalla Chiave Primaria aggiunta della relazione madre.
• Successivamente, tutti i domini non semplici vengono cancellati dalla relazione genitore, il nodo superiore dell'albero viene rimosso e la stessa procedura viene ripetuta per ciascuno dei rimanenti sottoalberi.

20. 2NF: definizioni di base e regole di trasformazione.

Molto spesso la chiave primaria di una relazione comprende diversi attributi (nel qual caso si chiama composito) - si veda, ad esempio, la relazione BAMBINI mostrata in Fig. 3.4 domanda 19. Allo stesso tempo, viene introdotto il concetto piena dipendenza funzionale.

Definizione:

un attributo non chiave è funzionalmente completamente dipendente da una chiave composita se dipende funzionalmente dall'intera chiave nel suo insieme, ma non dipende funzionalmente da nessuno dei suoi attributi costitutivi.

Esempio:

Sia presente una relazione FORNITURA (N_FORNITORE, PRODOTTO, PREZZO).
Un fornitore può fornire prodotti diversi e lo stesso prodotto può essere fornito da fornitori diversi. Quindi la chiave della relazione è "N_fornitore + prodotto". Lasciare che tutti i fornitori forniscano beni allo stesso prezzo. Quindi abbiamo le seguenti dipendenze funzionali:

• N_fornitore, prodotto -> prezzo
• Prodotto -> prezzo

La dipendenza funzionale incompleta dell'attributo prezzo dalla chiave porta alla seguente anomalia: quando cambia il prezzo di un articolo, è necessaria una visione completa della relazione per modificare tutti i record relativi ai suoi fornitori. Questa anomalia è una conseguenza del fatto che due fatti semantici sono combinati in un'unica struttura dati. La seguente espansione fornisce le relazioni in 2NF:

• CONSEGNA (N_FORNITORE, PRODOTTO)
• PRODUCT_PRICE (PRODOTTO, PREZZO)

Quindi puoi dare

Definizione di seconda forma normale: Una relazione è in 2NF se è in 1NF e ogni attributo non chiave dipende completamente dal punto di vista funzionale dalla chiave.

21. 3NF: definizioni di base e regole di trasformazione.

Prima di parlare della terza forma normale è necessario introdurre il concetto: dipendenza funzionale transitiva.

Definizione:

Siano X, Y, Z tre attributi di una qualche relazione. In questo caso, X --> Y e Y --> Z, ma non esiste corrispondenza inversa, cioè Z -/-> Y e Y -/-> X. Allora Z dipende transitivamente da X.
Sia presente una relazione STORAGE ( DITTA, MAGAZZINO, VOLUME), che contiene informazioni sulle aziende che ricevono merci dai magazzini e sui volumi di questi magazzini. Attributo chiave - "ditta". Se ogni azienda può ricevere merci da un solo magazzino, a questo proposito esistono le seguenti dipendenze funzionali:

• ditta -> azione
• azione -> volume

In questo caso si verificano anomalie:

• se al momento nessuna azienda riceve la merce dal magazzino, i dati sul suo volume non possono essere inseriti nel database (poiché l'attributo chiave non è definito)
• se cambia il volume del magazzino è necessario visualizzare l'intera relazione e modificare le schede di tutte le aziende associate a tale magazzino.

Per eliminare queste anomalie è necessario scomporre la relazione originaria in due:

• MAGAZZINAGGIO ( DITTA, AZIONE)
• VOLUME_MEMORIA ( AZIONE, VOLUME)

Definizione di terza forma normale:

Una relazione è in 3NF se è in 2NF e ogni attributo non chiave non dipende transitivamente dalla chiave primaria.

InterBase può utilizzare i seguenti tipi di restrizioni:

• CHIAVE PRIMARIA - la chiave primaria della tabella.
• UNICA - chiave tabella unica.
• CHIAVE ESTERA- chiave esterna, fornisce un collegamento ad un'altra tabella e garantisce l'integrità referenziale tra la tabella principale e tabelle figlio.

Una nota sulla terminologia

Se sei come l'autore di questo corso nel senso che ti piace cercare risposte a una domanda che ti interessa in modo esaustivo, in diverse opere di autori diversi, allora non potrai fare a meno di notare una certa confusione nelle definizioni principale (maestro) -> subordinato (particolare) tavoli. Ricordiamo che la tabella principale è spesso chiamata tabella madre e la tabella subordinata è spesso chiamata tabella figlia.

Ciò è probabilmente dovuto al modo in cui queste definizioni vengono interpretate nei DBMS locali e del server SQL.

Nei DBMS locali, la tabella principale è quella che contiene i dati principali e la tabella subordinata contiene i dati aggiuntivi. Prendiamo, ad esempio, tre tabelle correlate. Il primo contiene dati sulle vendite, il secondo sui prodotti e il terzo sui clienti:

Riso. 18.1.

Qui le informazioni principali sono archiviate nella tabella delle vendite, quindi è la tabella principale (genitore). Ulteriori informazioni vengono archiviate nelle tabelle prodotto e cliente, il che significa che sono secondarie. Ciò è comprensibile: una figlia non può avere due madri biologiche, ma una madre è perfettamente in grado di dare alla luce due figlie.

Ma nei server di database SQL esiste una diversa definizione di relazioni: quando un campo in una tabella fa riferimento a un campo in un'altra tabella, viene chiamato chiave esterna. E il campo a cui fa riferimento si chiama genitore o chiave primaria. Una tabella che ha una chiave esterna (un collegamento a un record in un'altra tabella) è spesso chiamata figlia e tabella con chiave genitore- genitoriale. Anche nella definizione delle relazioni si dice che un genitore può avere un solo record univoco, a cui possono fare riferimento più record tavolo per bambini.

Quindi, nell'esempio precedente, la tabella delle vendite ha due chiavi esterne: l'ID prodotto e l'ID cliente. Ed entrambe le tabelle sul lato destro della figura hanno chiave genitore"Identificatore". Poiché lo stesso cliente o prodotto può apparire ripetutamente nella tabella delle vendite, risulta che entrambe le tabelle sul lato destro della figura sono genitori e la tabella a sinistra è una figlia. Perché ora stiamo studiando InterBase-SQL server di database, saremo guidati da queste definizioni nelle lezioni successive. Per non scervellarci ulteriormente con questa confusione, mettiamoci subito d’accordo: tavolo per bambini ha una chiave esterna (FOREIGN KEY) su un'altra tabella.

CHIAVE PRIMARIA

CHIAVE PRIMARIA- La chiave primaria è uno dei principali tipi di restrizioni in un database. La chiave primaria è progettata per identificare in modo univoco un record in una tabella e deve essere univoca. Le chiavi primarie PRIMARY KEY si trovano nelle tabelle, che di solito sono chiamate genitore (Parent). La chiave primaria non deve essere confusa con gli indici primari dei database locali; la chiave primaria non è un indice, ma un vincolo. Quando si crea una chiave primaria InterBase crea automaticamente per lui indice univoco. Tuttavia, se creiamo indice univoco, questo non creerà vincoli di chiave primaria. Una tabella può avere solo una chiave primaria, PRIMARY KEY.

Supponiamo che tu abbia una tabella con un elenco di dipendenti. Il campo Cognome può contenere valori duplicati (omonimi), quindi non può essere utilizzato come chiave primaria. È raro, ma ci sono omonimi che, inoltre, hanno gli stessi nomi. Ancora più raramente esistono omonimi completi, quindi anche tutti e tre i campi “Cognome” + “Nome” + “Patronimico” non possono garantire l'unicità del record e non possono costituire la chiave primaria. In questo caso, la soluzione, come prima, è aggiungere un campo identificativo che contenga il numero di serie di questa persona. Tali campi vengono solitamente incrementati automaticamente (parleremo dell'organizzazione dei campi autoincrementanti nelle prossime lezioni). COSÌ,

Chiave primaria è uno o più campi in una tabella, la cui combinazione è univoca per ciascun record.

Se la chiave primaria contiene una singola colonna (come accade nella maggior parte dei casi), viene utilizzato l'identificatore PRIMARY KEY quando definizione di colonna:

CREATE TABLE Prim_1(Stolbec1 INT NOT NULL PRIMARY KEY, Stolbec2 VARCHAR(50))

Se la chiave primaria è composta da più colonne, lo specificatore viene inserito dopo aver definito tutti i campi:

CREATE TABLE Prim_2(Stolbec1 INT NOT NULL, Stolbec2 VARCHAR(50) NOT NULL, CHIAVE PRIMARIA (Stolbec1, Stolbec2))

Come si può vedere dagli esempi, la chiave primaria deve avere un vincolo di colonna/i NOT NULL.

UNICO

UNICO- chiave univoca. L'identificatore UNIQUE indica che tutti i valori di questo campo devono essere univoci, pertanto anche tali campi non possono contenere valori; NULLO. Si può dire che una chiave UNICA sia un'alternativa a una chiave primaria, ma ci sono delle differenze. La differenza principale è che deve esserci una sola chiave primaria, mentre possono esserci più chiavi univoche. Inoltre, non è possibile creare un vincolo UNIQUE sullo stesso set di colonne utilizzato per un PRIMARY KEY o un altro vincolo UNIQUE. Le chiavi univoche, come le chiavi primarie, si trovano nelle tabelle che sono genitori di altre tabelle.

Una colonna dichiarata con un vincolo UNIQUE, come una chiave primaria, può essere utilizzata per imporre l'integrità referenziale tra il suo genitore e tabelle figlio. In questo caso, la chiave esterna tavolo per bambini farà riferimento a questo/i campo/i. Come con una chiave primaria, quando viene creata una chiave univoca, a indice univoco. Ma non il contrario. Un esempio di creazione di una tabella con una chiave primaria e due univoche:

CREATE TABLE Prim_3(Stolbec1 INT NOT NULL PRIMARY KEY, Stolbec2 VARCHAR(50) NOT NULL UNIQUE, Stolbec3 FLOAT NOT NULL UNIQUE)

CHIAVE ESTERA

CHIAVE ESTERA- chiave esterna. Si tratta di uno strumento molto potente per garantire l'integrità referenziale tra le tabelle, che consente non solo di monitorare la presenza dei collegamenti corretti, ma anche di gestirli automaticamente. Le chiavi esterne sono contenute in tabelle che sono figlie (Child) di altre tabelle. Integrità referenzialeè fornito appunto da una chiave esterna che rimanda alla primaria o

E così, in silenzio, ci siamo avvicinati ad un argomento molto importante: le chiavi primarie ed esterne. Mentre i primi sono utilizzati quasi da tutti, i secondi vengono in qualche modo ignorati. Ma invano. Le chiavi esterne non sono un problema, sono un vero aiuto per l'integrità dei dati.

1.2.5. Chiave primaria

Abbiamo già parlato molto dei campi chiave, ma non li abbiamo mai utilizzati. La cosa più interessante è che tutto ha funzionato. Questo è un vantaggio, o forse uno svantaggio, dei database Microsoft SQL Server e MS Access. Questo trucco non funzionerà nelle tabelle Paradox e senza un campo chiave la tabella sarà di sola lettura.

In una certa misura, le chiavi sono vincoli e potrebbero essere considerate insieme all'istruzione CHECK perché la dichiarazione avviene in modo simile e utilizza anche l'istruzione CONSTRAINT. Diamo un'occhiata a questo processo con un esempio. Per fare ciò, creeremo una tabella composta da due campi “guid” e “vcName”. Questo imposta il campo "guid" come chiave primaria:

CREATE TABLE Globally_Unique_Data (guid uniqueidentifier DEFAULT NEWID(), vcName varchar(50), CONSTRAINT PK_guid PRIMARY KEY (Guid))

La parte migliore qui è la linea CONSTRAINT. Come sappiamo, questa parola chiave è seguita dal nome del vincolo e la dichiarazione della chiave non fa eccezione. Per denominare una chiave primaria, consiglio di utilizzare un tipo di denominazione PK_name, dove nome è il nome del campo che dovrebbe diventare la chiave primaria. L'abbreviazione PK deriva da Primary Key.

Successivamente, al posto della parola chiave CHECK, che abbiamo utilizzato nei vincoli, c'è un operatore PRIMARY KEY. Questo è ciò che indica che non abbiamo bisogno di un controllo, ma di una chiave primaria. Tra parentesi sono indicati uno o più campi che costituiranno la chiave.

Ricordare che due righe non possono avere lo stesso valore in un campo chiave, in cui un vincolo di chiave primaria è identico a un vincolo univoco. Ciò significa che se si crea il campo per la memorizzazione del cognome come chiave primaria, non sarà possibile scrivere due Ivanov con nomi diversi in una tabella del genere. Ciò viola il vincolo della chiave primaria. Questo è il motivo per cui le chiavi sono vincoli e vengono dichiarate allo stesso modo di un vincolo CHECK. Ma questo non è vero solo per le chiavi primarie e le chiavi secondarie con unicità.

In questo esempio, la chiave primaria è un campo di tipo identificatore univoco (GUID). Il valore predefinito per questo campo è il risultato della procedura del server NEWID.

Attenzione

È possibile creare una sola chiave primaria per una tabella

Per semplificare gli esempi è consigliabile utilizzare come chiave una chiave di tipo numerico e, se il database lo consente, meglio se di tipo “autoincrement” (numero crescente/decrescente automatico). In MS SQL Server questo campo è IDENTITY e in MS Access è un campo di tipo "contatore".

L'esempio seguente mostra come creare una tabella di prodotti con un campo intero con incremento automatico come chiave primaria:

CREATE TABLE Prodotti (id int IDENTITY(1, 1), product varchar(50), Prezzo monetario, Quantità numerica(10, 2), CONSTRAINT PK_id PRIMARY KEY (id))

Questo è il tipo di chiave che utilizzeremo più spesso, perché il campo chiave memorizzerà numeri facili da comprendere e sarà più facile e più visivo lavorarci.

Una chiave primaria può essere costituita da più colonne. L'esempio seguente crea una tabella in cui i campi "id" e "Prodotto" costituiscono la chiave primaria, il che significa che verrà creato un indice univoco su entrambi i campi:

CREATE TABLE Prodotti1 (id int IDENTITY(1, 1), Prodotto varchar(50), Prezzo monetario, Quantità numerica(10, 2), CONSTRAINT PK_id PRIMARY KEY (id, [Nome prodotto]))

Molto spesso i programmatori creano un database con un campo chiave sotto forma di numero intero, ma allo stesso tempo l'attività indica chiaramente che determinati campi devono essere univoci. Perché non creare immediatamente una chiave primaria da quei campi che devono essere univoci e non sarà necessario creare soluzioni separate per questo problema.

L'unico inconveniente di una chiave primaria a più colonne è il problema della creazione di relazioni. Qui devi uscirne utilizzando vari metodi, ma il problema può ancora essere risolto. Devi solo inserire un campo di tipo uniqueidentifier ed effettuare una connessione utilizzandolo. Sì, in questo caso otteniamo una chiave primaria univoca e un campo di tipo uniqueidentifier, ma questa ridondanza di conseguenza non sarà maggiore della stessa tabella in cui la chiave primaria è uniqueidentifier e viene impostato un vincolo di unicità sui campi che devono essere unico. Cosa scegliere? Dipende dall'attività specifica e da cosa ti senti più a tuo agio a lavorare.

1.2.6. Chiave esterna

Una chiave esterna è anche un vincolo CONSTRAINT e rappresenta la relazione tra due tabelle. Diciamo che hai due tabelle:

• Nomi – contiene i nomi delle persone ed è composto da campi identificativi (campo chiave), nome.
• Telefoni è una tabella telefonica composta da un identificatore (campo chiave), una chiave esterna per la connessione alla tabella dei nomi e un campo stringa per memorizzare il numero di telefono.

Una persona può avere più telefoni, quindi abbiamo suddiviso l'archiviazione dei dati in diverse tabelle. La Figura 1.4 mostra visivamente la relazione tra due tabelle. Se hai già lavorato con le tabelle collegate, questo ti basterà. Se senti parlare di connessioni per la prima volta, proviamo a dare un’occhiata più da vicino al problema.

Ad esempio, prendiamo un tavolo di tre persone. La tabella 1.3 mostra il contenuto della tabella "Nomi". Ci sono solo tre righe e ognuna ha la propria chiave principale univoca. Per unicità, quando creiamo una tabella, renderemo la chiave un campo ad incremento automatico.

Tabella 1.3 Contenuto della tabella Nomi

Tabella 1.4. Contenuto della tabella Telefoni

La tabella 1.4 contiene cinque numeri di telefono. Il campo chiave principale contiene anche una chiave principale univoca, che può anche essere incrementata automaticamente. Una chiave secondaria è una relazione con la chiave primaria della tabella Nomi. Come funziona questa connessione? Petrov ha il numero 1 come chiave primaria nella tabella Nomi. Nella tabella Telefoni, nella chiave secondaria, cerchiamo il numero 1 e otteniamo i numeri di telefono di Petrov. Lo stesso vale per il resto delle voci. Visivamente la connessione può essere vista nella Figura 1.5.

Questo tipo di archiviazione dei dati è molto conveniente. Se non fosse possibile creare tabelle correlate, nella tabella Nomi dovremmo inserire tutti i numeri di telefono in un unico campo. Ciò è scomodo dal punto di vista dell'utilizzo, della manutenzione e del recupero dei dati.

Puoi creare più campi Nomi in una tabella, ma sorge la domanda: quanti. Una persona può avere solo 1 telefono, ma io, ad esempio, ne ho 3, senza contare quelli di lavoro. Un gran numero di campi porta alla ridondanza dei dati.

Puoi creare una riga separata con il cognome per ciascun telefono nella tabella Nomi, ma questo è facile solo per un esempio così semplice, quando devi inserire solo il cognome e puoi facilmente inserire più voci per Petrov con diversi telefoni numeri. Cosa succede se ci sono 10 o 20 campi? Pertanto, la creazione di due tabelle collegate da una chiave esterna può essere vista nel Listato 1.6.

Listato 1.6. Creazione di tabelle collegate da una chiave esterna

CREATE TABLE Nomi (idName int IDENTITY(1,1), vcName varchar(50), CONSTRAINT PK_guid PRIMARY KEY (idName),) CREATE TABLE Telefoni (idPhone int IDENTITY(1,1), idName int, vcPhone varchar(10), VINCOLO PK_idPhone CHIAVE PRIMARIA (idPhone), VINCOLO FK_idName CHIAVE ESTERA (idName) RIFERIMENTI Nomi (idName))

Si prega di rivedere attentamente il contenuto dell'elenco. È piuttosto interessante perché utilizza alcuni degli operatori che abbiamo già trattato e un ulteriore esempio sarebbe utile. Per entrambe le tabelle viene creato un campo chiave che viene per primo, è di tipo int e viene incrementato automaticamente partendo da 1 con incrementi di uno. Il campo chiave viene reso la chiave principale utilizzando un vincolo CONSTRAINT.

Nella descrizione della tabella Phones, l'ultima riga contiene per noi una nuova dichiarazione, ovvero la dichiarazione di una chiave esterna utilizzando l'operatore FOREIGN KEY. Come puoi vedere, anche questa è una limitazione e poco dopo vedrai il perché. Il campo della tabella che deve essere collegato ad un'altra tabella è indicato tra parentesi. Successivamente c'è la parola chiave REFERENCES (link), il nome della tabella con la quale dovrebbe esserci la connessione (Names) e tra parentesi il nome del campo ("idName"). Pertanto, abbiamo creato una connessione, mostrata nella Figura 1.4.

Attenzione!

Una chiave esterna può fare riferimento solo alla chiave primaria di un'altra tabella o a un vincolo univoco. Ciò significa che dopo la parola chiave REFERENCES deve esserci un nome di tabella e tra parentesi può essere specificata solo una chiave primaria o un campo con vincolo UNIQUE. Non è possibile specificare altri campi.

Ora, se riesci a riempire le tabelle con i dati. Le tre squadre successive aggiungono i tre nomi che abbiamo visto nella Tabella 1.3:

INSERT INTO Nomi(vcName) VALUES("Petrov") INSERT INTO Nomi(vcName) VALUES("Ivanov") INSERT INTO Nomi(vcName) VALUES("Sidorov")

Se hai già lavorato con SQL, puoi aggiungere voci per la tabella telefonica. Ometterò questi comandi, ma puoi vederli nel file foreign_keys.sql nella directory Chapter1 sul CD.

Il nostro compito ora è vedere quali sono le azioni restrittive di una chiave esterna, scopriamolo. Abbiamo specificato una relazione esplicita tra due campi in tabelle diverse. Se provi ad aggiungere nella tabella telefonica un record con un identificatore nel campo "idName" che non esiste nel campo omonimo (il nome potrebbe essere cambiato in un altro) nella tabella cognomi, si verificherà un errore . Ciò interromperà la relazione tra le due tabelle e il vincolo di chiave esterna non consentirà l'esistenza di record senza la relazione.

La limitazione si applica anche in caso di modifica o eliminazione di record. Ad esempio, se provi a eliminare una riga con il cognome Petrov, si verificherà un errore di vincolo di chiave esterna. Non è possibile eliminare record con righe correlate esternamente. Innanzitutto, è necessario eliminare tutti i numeri di telefono per questa voce e solo successivamente sarà possibile eliminare la riga con il cognome Petrov.

Quando si crea una chiave esterna, è possibile specificare ON DELETE CASCADE o ON UPDATE CASCADE. In questo caso, se elimini il record di Petrov dalla tabella Nomi o modifichi l'identificatore, tutti i record nella tabella Telefoni associati alla riga di Petrov verranno aggiornati automaticamente. Mai. No, va scritto in maiuscolo: non farlo MAI. Tutto deve essere cancellato o modificato manualmente. Se un utente elimina accidentalmente una voce dalla tabella Nomi, verranno eliminati anche i telefoni corrispondenti. Non ha senso creare una chiave esterna se metà delle sue restrizioni scompaiono! Tutto deve essere fatto manualmente e non è mai consigliabile modificare gli identificatori.

Anche l'eliminazione delle tabelle stesse dovrebbe iniziare con la tabella subordinata, ovvero con Telefoni, e solo successivamente sarà possibile eliminare la tabella principale Nomi.

Infine, ti mostrerò come ottenere una bella corrispondenza tra nomi e numeri di telefono da due tabelle:

SELEZIONA vcName, vcPhone FROM Nomi, Telefoni DOVE Nomi.idName=Telefoni.idName

Parleremo di tali query in modo più dettagliato nel Capitolo 2. Per ora, ho fornito un esempio solo per farvi capire la potenza delle tabelle correlate.

Una tabella può contenere fino a 253 chiavi esterne, il che è abbastanza anche per i database più complessi. Personalmente ho dovuto lavorare con database in cui il numero di chiavi esterne non superava le 7 per tabella. Se è maggiore, molto probabilmente il database è progettato in modo errato, sebbene esistano delle eccezioni.

La tabella stessa può avere anche un massimo di 253 chiavi esterne. Le chiavi esterne in una tabella sono meno comuni, in genere non più di 3. Molto spesso, una tabella può avere molti collegamenti ad altre tabelle.

Una chiave esterna può fare riferimento alla stessa tabella in cui è stata creata. Ad esempio, hai una tabella di titoli professionali in un'organizzazione, come mostrato nella Tabella 1.5. La tabella è composta da tre campi: chiave primaria, chiave esterna e titolo professionale. Qualsiasi organizzazione può avere molte posizioni, ma sarebbe abbastanza logico mostrarne i nomi e la struttura di subordinazione in un'unica tabella. Per fare ciò, la chiave esterna deve essere associata alla chiave primaria della tabella delle posizioni.

Tabella 1.5. Tabella con collegamento interno

Di conseguenza, otteniamo che il direttore generale ha una chiave esterna zero, ad es. questa posizione è a capo di tutte le altre. Per il direttore commerciale e il direttore degli affari generali, la chiave estera indica la fila del direttore generale. Ciò significa che queste due posizioni riportano direttamente all'amministratore delegato. E così via.

Vediamo come possiamo creare tutto questo come una query SQL:

CREATE TABLE Posizioni (idPosition int IDENTITY(1,1), idParentPosition int, vcName varchar(30), VINCOLO PK_idPosition CHIAVE PRIMARIA (idPosition), VINCOLO FK_idParentPosition CHIAVE ESTERNA (idParentPosition) RIFERIMENTI Posizioni (idPosition))

Come puoi vedere, la chiave esterna fa semplicemente riferimento alla stessa tabella che stiamo creando. Sul CD, nella directory Chapter1, potete vedere nel file foreign_keys_to_self.sql un esempio di creazione di questa tabella, riempiendola di dati e visualizzando le posizioni tenendo conto della loro subordinazione. Nel prossimo capitolo esamineremo più in dettaglio la possibilità di lavorare con tali tabelle.

Rapporto uno a uno

Finora abbiamo considerato la relazione classica, quando una riga della tabella dati principale corrisponde a una riga della tabella correlata. Questa relazione è chiamata uno-a-molti. Ma ci sono altre connessioni, e ora ne esamineremo un'altra: quella uno a uno, quando un record nella tabella principale è collegato a un record di un altro. Per implementare ciò è sufficiente collegare le chiavi primarie di entrambe le tabelle. Poiché le chiavi primarie non possono essere ripetute, in entrambe le tabelle è possibile correlare solo una riga.

L'esempio seguente crea due tabelle che hanno una relazione di chiave primaria:

CREATE TABLE Nomi (idName uniqueidentifier DEFAULT NEWID(), vcName varchar(50), CONSTRAINT PK_guid PRIMARY KEY (idName)) CREATE TABLE Telefoni (idPhone uniqueidentifier DEFAULT NEWID(), vcPhone varchar(10), CONSTRAINT PK_idPhone PRIMARY KEY (idPhone), VINCOLO FK_idPhone CHIAVE ESTERA (idPhone) RIFERIMENTI Nomi (idName))

Solo una delle tabelle necessita di una chiave esterna. Poiché la relazione è uno a uno, non importa in quale tabella crearla.

molti a molti

La relazione più complessa è molti-a-molti, in cui molti record di una tabella corrispondono a molti record di un'altra tabella. Per implementare ciò, non sono sufficienti due tabelle; sono necessarie tre tabelle.

Per prima cosa dobbiamo capire quando è possibile utilizzare una relazione molti-a-molti? Supponiamo che tu abbia due tabelle: un elenco di residenti della casa e un elenco di numeri di telefono. Un appartamento può avere più di un numero, il che significa che un cognome può avere due numeri di telefono. Si scopre che esiste una relazione uno-a-molti. D’altra parte, possono esserci due famiglie in un appartamento (un appartamento comune o semplicemente un inquilino che usa il telefono del proprietario), il che significa che anche la connessione tra il telefono e l’inquilino è uno a molti. E l'opzione più difficile è avere due telefoni in un appartamento comune. In questo caso entrambi i numeri vengono utilizzati da più residenti dell'appartamento. Risulta quindi che “molte” famiglie possono utilizzare “molti” telefoni (comunicazione molti-a-molti).

Come implementare una relazione molti-a-molti? A prima vista, questo è impossibile nel modello relazionale. Circa 10 anni fa, ho trascorso molto tempo alla ricerca di diverse opzioni e di conseguenza ho semplicemente creato una tabella piena di dati ridondanti. Ma un giorno mi è stato affidato un compito, grazie al quale dalle condizioni è emersa un'ottima soluzione: dovevo creare due tabelle di residenti dell'appartamento e numeri di telefono e implementare in esse solo la chiave primaria. Le chiavi esterne non sono necessarie in questa tabella. Ma il collegamento tra i tavoli dovrebbe avvenire attraverso un terzo tavolo di collegamento. A prima vista, questo è difficile e poco chiaro, ma una volta compreso questo metodo, vedrai tutta la potenza di questa soluzione.

Le tabelle 1.6 e 1.7 mostrano rispettivamente esempi di tabelle dei cognomi e dei telefoni. E la Tabella 1.8 mostra la tabella di collegamento.

Tabella 1.6. Tabella dei cognomi

Tabella 1.7. Tavolo telefonico

Tabella 1.8. Tavolo telefonico

Vediamo ora come sarà la logica di ricerca dei dati in una relazione molti-a-molti. Diciamo che dobbiamo trovare tutti i telefoni che appartengono a Ivanov. La chiave primaria di Ivanov è uguale a 1. Troviamo nella tabella di collegamento tutti i record per i quali il campo “Relazione con nome” è uguale a 1. Questi saranno i record 1 e 2. In questi record nel campo “Relazione con telefono” c'è sono identificatori 1 e 2, rispettivamente, e Ciò significa che Ivanov possiede i numeri della tabella telefonica, che si trovano nelle righe 1 e 2.

Ora risolviamo il problema inverso: determiniamo chi ha accesso al numero di telefono 567575677. Questo numero nella tabella del telefono ha la chiave 3. Stiamo cercando tutti i record nella tabella di collegamento, dove nel campo "Connessione telefonica" è uguale a 3. Si tratta dei record con i numeri 4 e 5, che nel campo "Nome Link" contengono rispettivamente i valori 2 e 3. Se ora guardate la tabella dei cognomi, vedrete Petrov e Sidorov ai numeri 2 e 3. Ciò significa che questi due residenti utilizzano il numero di telefono 567575677.

Rivedi tutte e tre le tabelle e assicurati di capire quali numeri di telefono appartengono a quali residenti e viceversa. Se vedi questa connessione, capirai che è semplice come tre centesimi e puoi implementarla rapidamente nei tuoi progetti.

CREATE TABLE Nomi (idName uniqueidentifier DEFAULT NEWID(), vcName varchar(50), CONSTRAINT PK_guid PRIMARY KEY (idName)) CREATE TABLE Telefoni (idPhone uniqueidentifier DEFAULT NEWID(), vcPhone varchar(10), CONSTRAINT PK_idPhone PRIMARY KEY (idPhone)) CREATE TABLE LinkTable (idLinkTable uniqueidentifier DEFAULT NEWID(), idName uniqueidentifier, idPhone uniqueidentifier, VINCOLI PK_idLinkTable CHIAVE PRIMARIA (idLinkTable), VINCOLI FK_idPhone CHIAVE ESTERA (idPhone) RIFERIMENTI Telefoni (idPhone), VINCOLI FK_idName CHIAVE ESTERA (idName REF) ERENCES Nomi (idName ) )

La tabella di collegamento dispone di due chiavi esterne che si collegano alle tabelle dei nomi e dei telefoni e una chiave primaria che garantisce che i record siano univoci.

Ho scelto il campo GUID come chiave primaria perché è più conveniente per risolvere questo particolare problema. Il fatto è che dobbiamo inserire i record in due tabelle e in entrambi i casi dobbiamo specificare la stessa chiave. Il valore GUID può essere generato e quindi utilizzato quando si inseriscono dati in entrambe le tabelle.

Si può anche usare come chiave un campo ad incremento automatico, ma in questo caso il problema è un po' più difficile da risolvere, o meglio, è scomodo risolvere il problema. Ad esempio, quando si aggiunge un numero di telefono, è necessario prima inserire la riga corrispondente nella tabella, quindi trovarla, determinare la chiave assegnata alla riga e quindi stabilire la connessione.

In questa fase ci limitiamo solo a creare tabelle, ma nella sezione 2.8 torneremo su questo argomento e impareremo a lavorare con le tabelle correlate. Lavorare con una relazione uno-a-uno e uno-a-molti non è molto diverso, poiché in questo schema sono coinvolte solo due tabelle. Le relazioni molti-a-molti sono un po' più complicate a causa della tabella di collegamento, quindi ne parleremo separatamente nella Sezione 2.27.