DBMS - Guida rapida

Database è una raccolta di dati correlati e dati è una raccolta di fatti e cifre che possono essere elaborati per produrre informazioni.

Per lo più i dati rappresentano fatti registrabili. I dati aiutano nella produzione di informazioni basate sui fatti. Ad esempio, se disponiamo di dati sui voti ottenuti da tutti gli studenti, possiamo quindi concludere su topper e voti medi.

UN database management system memorizza i dati in modo tale che diventi più facile recuperare, manipolare e produrre informazioni.

Caratteristiche

Tradizionalmente, i dati erano organizzati in formati di file. Il DBMS era allora un concetto nuovo e tutta la ricerca è stata fatta per superare le carenze nello stile tradizionale di gestione dei dati. Un moderno DBMS ha le seguenti caratteristiche:

Real-world entity- Un DBMS moderno è più realistico e utilizza entità del mondo reale per progettare la sua architettura. Usa anche il comportamento e gli attributi. Ad esempio, un database scolastico può utilizzare gli studenti come entità e la loro età come attributo.
Relation-based tables- DBMS consente alle entità e alle relazioni tra di loro di formare tabelle. Un utente può comprendere l'architettura di un database semplicemente guardando i nomi delle tabelle.
Isolation of data and application- Un sistema di database è completamente diverso dai suoi dati. Un database è un'entità attiva, mentre si dice che i dati siano passivi, su cui il database lavora e si organizza. DBMS memorizza anche i metadati, ovvero i dati sui dati, per facilitare il proprio processo.
Less redundancy- DBMS segue le regole di normalizzazione, che divide una relazione quando uno qualsiasi dei suoi attributi ha ridondanza nei valori. La normalizzazione è un processo matematicamente ricco e scientifico che riduce la ridondanza dei dati.
Consistency- La coerenza è uno stato in cui ogni relazione in un database rimane coerente. Esistono metodi e tecniche che possono rilevare il tentativo di lasciare il database in uno stato incoerente. Un DBMS può fornire una maggiore coerenza rispetto alle precedenti forme di applicazioni di archiviazione dei dati come i sistemi di elaborazione dei file.
Query Language- Il DBMS è dotato di un linguaggio di query, che rende più efficiente il recupero e la manipolazione dei dati. Un utente può applicare tutte le opzioni di filtraggio necessarie per recuperare un insieme di dati. Tradizionalmente non era possibile dove veniva utilizzato il sistema di elaborazione dei file.
ACID Properties - DBMS segue i concetti di Atomicità, Consistenza, Isolazione, e Durability (normalmente abbreviato come ACID). Questi concetti vengono applicati alle transazioni, che manipolano i dati in un database. Le proprietà ACID aiutano il database a rimanere integro in ambienti multi-transazionali e in caso di errore.
Multiuser and Concurrent Access- DBMS supporta l'ambiente multiutente e consente loro di accedere e manipolare i dati in parallelo. Sebbene ci siano limitazioni alle transazioni quando gli utenti tentano di gestire lo stesso elemento di dati, ma gli utenti non ne sono sempre consapevoli.
Multiple views- DBMS offre più visualizzazioni per diversi utenti. Un utente che si trova nel reparto vendite avrà una vista del database diversa rispetto a una persona che lavora nel reparto produzione. Questa funzione consente agli utenti di avere una visione concentrata del database in base alle loro esigenze.
Security- Funzionalità come visualizzazioni multiple offrono sicurezza in una certa misura in cui gli utenti non sono in grado di accedere ai dati di altri utenti e reparti. DBMS offre metodi per imporre vincoli durante l'immissione dei dati nel database e il recupero degli stessi in una fase successiva. DBMS offre molti livelli diversi di funzionalità di sicurezza, che consentono a più utenti di avere viste differenti con caratteristiche differenti. Ad esempio, un utente nel reparto vendite non può vedere i dati che appartengono al reparto acquisti. Inoltre, può anche essere gestita la quantità di dati del reparto vendite che devono essere visualizzati all'utente. Poiché un DBMS non viene salvato sul disco come file system tradizionali, è molto difficile per i miscredenti rompere il codice.

Utenti

Un tipico DBMS ha utenti con diritti e autorizzazioni differenti che lo utilizzano per scopi differenti. Alcuni utenti recuperano i dati e altri ne eseguono il backup. Gli utenti di un DBMS possono essere ampiamente classificati come segue:

Administrators- Gli amministratori mantengono il DBMS e sono responsabili dell'amministrazione del database. Sono responsabili di curarne l'utilizzo e da chi dovrebbe essere utilizzato. Creano profili di accesso per gli utenti e applicano limitazioni per mantenere l'isolamento e forzare la sicurezza. Gli amministratori si occupano anche delle risorse DBMS come la licenza di sistema, gli strumenti necessari e altre operazioni di manutenzione relative a software e hardware.
Designers- I designer sono il gruppo di persone che lavorano effettivamente sulla parte di progettazione del database. Controllano attentamente quali dati devono essere conservati e in quale formato. Identificano e progettano l'intero insieme di entità, relazioni, vincoli e viste.
End Users- Gli utenti finali sono coloro che effettivamente raccolgono i vantaggi di avere un DBMS. Gli utenti finali possono variare da semplici visualizzatori che prestano attenzione ai registri o alle tariffe di mercato a utenti sofisticati come analisti aziendali.

Il design di un DBMS dipende dalla sua architettura. Può essere centralizzato o decentralizzato o gerarchico. L'architettura di un DBMS può essere vista come livello singolo o multi livello. Un'architettura a più livelli divide l'intero sistema in correlato ma indipendenten moduli, che possono essere modificati, alterati, modificati o sostituiti in modo indipendente.

Nell'architettura a 1 livello, il DBMS è l'unica entità in cui l'utente si siede direttamente sul DBMS e lo utilizza. Tutte le modifiche apportate qui verranno eseguite direttamente sul DBMS stesso. Non fornisce strumenti utili per gli utenti finali. I progettisti ei programmatori di database normalmente preferiscono utilizzare un'architettura a livello singolo.

Se l'architettura del DBMS è a 2 livelli, deve disporre di un'applicazione attraverso la quale è possibile accedere al DBMS. I programmatori utilizzano un'architettura a 2 livelli in cui accedono al DBMS tramite un'applicazione. In questo caso il livello dell'applicazione è completamente indipendente dal database in termini di funzionamento, progettazione e programmazione.

Architettura a 3 livelli

Un'architettura a 3 livelli separa i suoi livelli l'uno dall'altro in base alla complessità degli utenti e al modo in cui utilizzano i dati presenti nel database. È l'architettura più utilizzata per progettare un DBMS.

Database (Data) Tier- A questo livello, il database risiede insieme ai suoi linguaggi di elaborazione delle query. Abbiamo anche le relazioni che definiscono i dati e i loro vincoli a questo livello.
Application (Middle) Tier- A questo livello risiedono il server delle applicazioni e i programmi che accedono al database. Per un utente, questo livello di applicazione presenta una vista astratta del database. Gli utenti finali non sono a conoscenza dell'esistenza del database al di fuori dell'applicazione. All'altra estremità, il livello del database non è a conoscenza di nessun altro utente oltre il livello dell'applicazione. Quindi, il livello dell'applicazione si trova nel mezzo e funge da mediatore tra l'utente finale e il database.
User (Presentation) Tier- Gli utenti finali operano su questo livello e non sanno nulla dell'esistenza del database oltre questo livello. A questo livello, l'applicazione può fornire più visualizzazioni del database. Tutte le visualizzazioni vengono generate dalle applicazioni che risiedono nel livello applicazione.

L'architettura del database a più livelli è altamente modificabile, poiché quasi tutti i suoi componenti sono indipendenti e possono essere modificati in modo indipendente.

I modelli di dati definiscono il modo in cui viene modellata la struttura logica di un database. I modelli di dati sono entità fondamentali per introdurre l'astrazione in un DBMS. I modelli di dati definiscono come i dati sono collegati tra loro e come vengono elaborati e archiviati all'interno del sistema.

Il primo modello di dati potrebbe essere un modello di dati piatto, in cui tutti i dati utilizzati devono essere mantenuti sullo stesso piano. I modelli di dati precedenti non erano così scientifici, quindi erano inclini a introdurre molte duplicazioni e ad aggiornare le anomalie.

Modello Entità-Relazione

Il modello Entity-Relationship (ER) si basa sulla nozione di entità e relazioni del mondo reale tra di loro. Durante la formulazione dello scenario del mondo reale nel modello di database, il modello ER crea un insieme di entità, un insieme di relazioni, attributi generali e vincoli.

Il modello ER è utilizzato al meglio per la progettazione concettuale di un database.

Il modello ER si basa su:

Entitiese i loro attributi.
Relationships tra le entità.

Questi concetti sono spiegati di seguito.

Entity - Un'entità in un modello ER è un'entità del mondo reale con proprietà chiamate attributes. Ogniattribute è definito dal suo insieme di valori chiamato domain. Ad esempio, in un database scolastico, uno studente è considerato un'entità. Lo studente ha vari attributi come nome, età, classe, ecc.
Relationship - Viene chiamata l'associazione logica tra entità relationship. Le relazioni vengono mappate con le entità in vari modi. Le cardinalità di mappatura definiscono il numero di associazioni tra due entità.

Mappatura delle cardinalità -
- uno a uno
- uno a molti
- molti a uno
- molti a molti

Modello relazionale

Il modello di dati più popolare in DBMS è il modello relazionale. È un modello più scientifico di altri. Questo modello si basa sulla logica dei predicati del primo ordine e definisce una tabella come filen-ary relation.

I punti salienti di questo modello sono:

I dati vengono memorizzati in tabelle chiamate relations.
Le relazioni possono essere normalizzate.
Nelle relazioni normalizzate, i valori salvati sono valori atomici.
Ogni riga in una relazione contiene un valore univoco.
Ogni colonna in una relazione contiene valori di uno stesso dominio.

Schema del database

Uno schema di database è la struttura scheletro che rappresenta la vista logica dell'intero database. Definisce come sono organizzati i dati e come sono associate le relazioni tra loro. Formula tutti i vincoli che devono essere applicati ai dati.

Uno schema di database definisce le sue entità e la relazione tra di loro. Contiene un dettaglio descrittivo del database, che può essere rappresentato tramite diagrammi di schema. Sono i progettisti del database che progettano lo schema per aiutare i programmatori a comprendere il database e renderlo utile.

Uno schema di database può essere suddiviso ampiamente in due categorie:

Physical Database Schema - Questo schema riguarda l'archiviazione effettiva dei dati e la sua forma di archiviazione come file, indici, ecc. Definisce come i dati verranno archiviati in una memoria secondaria.
Logical Database Schema- Questo schema definisce tutti i vincoli logici che devono essere applicati ai dati memorizzati. Definisce tabelle, viste e vincoli di integrità.

Istanza database

È importante distinguere individualmente questi due termini. Lo schema del database è lo scheletro del database. È progettato quando il database non esiste affatto. Una volta che il database è operativo, è molto difficile apportarvi modifiche. Uno schema di database non contiene dati o informazioni.

Un'istanza di database è uno stato di database operativo con dati in un dato momento. Contiene un'istantanea del database. Le istanze del database tendono a cambiare nel tempo. Un DBMS garantisce che ogni sua istanza (stato) sia in uno stato valido, seguendo diligentemente tutte le convalide, i vincoli e le condizioni che i progettisti del database hanno imposto.

Se un sistema di database non è a più livelli, diventa difficile apportare modifiche al sistema di database. I sistemi di database sono progettati in più livelli come abbiamo appreso in precedenza.

Indipendenza dei dati

Un sistema di database normalmente contiene molti dati oltre ai dati degli utenti. Ad esempio, memorizza i dati sui dati, noti come metadati, per individuare e recuperare facilmente i dati. È piuttosto difficile modificare o aggiornare una serie di metadati una volta archiviati nel database. Ma man mano che un DBMS si espande, deve cambiare nel tempo per soddisfare i requisiti degli utenti. Se tutti i dati dipendessero, diventerebbe un lavoro noioso e altamente complesso.

I metadati stessi seguono un'architettura a più livelli, in modo che quando modifichiamo i dati a un livello, non influiscono sui dati a un altro livello. Questi dati sono indipendenti ma mappati tra loro.

Indipendenza logica dei dati

I dati logici sono dati sul database, ovvero memorizzano informazioni su come i dati vengono gestiti all'interno. Ad esempio, una tabella (relazione) memorizzata nel database e tutti i suoi vincoli, applicati a quella relazione.

L'indipendenza dai dati logici è una sorta di meccanismo che si libera dai dati effettivi memorizzati sul disco. Se apportiamo alcune modifiche al formato della tabella, non dovrebbe cambiare i dati che risiedono sul disco.

Indipendenza fisica dei dati

Tutti gli schemi sono logici e i dati effettivi vengono memorizzati in formato bit sul disco. L'indipendenza fisica dei dati è il potere di modificare i dati fisici senza influire sullo schema o sui dati logici.

Ad esempio, nel caso in cui desideriamo modificare o aggiornare il sistema di archiviazione stesso, supponiamo di voler sostituire i dischi rigidi con SSD, non dovrebbe avere alcun impatto sui dati logici o sugli schemi.

Il modello ER definisce la vista concettuale di un database. Funziona attorno a entità del mondo reale e alle associazioni tra di loro. A livello di vista, il modello ER è considerato una buona opzione per la progettazione di database.

Entità

Un'entità può essere un oggetto del mondo reale, animato o inanimato, che può essere facilmente identificabile. Ad esempio, in un database scolastico, studenti, insegnanti, classi e corsi offerti possono essere considerati entità. Tutte queste entità hanno alcuni attributi o proprietà che danno loro la loro identità.

Un set di entità è una raccolta di tipi simili di entità. Un set di entità può contenere entità con attributi che condividono valori simili. Ad esempio, un set Studenti può contenere tutti gli studenti di una scuola; allo stesso modo un set Insegnanti può contenere tutti gli insegnanti di una scuola di tutte le facoltà. Gli insiemi di entità non devono essere disgiunti.

Attributi

Le entità sono rappresentate per mezzo delle loro proprietà, chiamate attributes. Tutti gli attributi hanno valori. Ad esempio, un'entità studente può avere nome, classe ed età come attributi.

Esiste un dominio o un intervallo di valori che possono essere assegnati agli attributi. Ad esempio, il nome di uno studente non può essere un valore numerico. Deve essere alfabetico. L'età di uno studente non può essere negativa, ecc.

Tipi di attributi

Simple attribute- Gli attributi semplici sono valori atomici, che non possono essere ulteriormente suddivisi. Ad esempio, il numero di telefono di uno studente è un valore atomico di 10 cifre.
Composite attribute- Gli attributi compositi sono costituiti da più di un semplice attributo. Ad esempio, il nome completo di uno studente può avere first_name e last_name.
Derived attribute- Gli attributi derivati sono gli attributi che non esistono nel database fisico, ma i loro valori sono derivati da altri attributi presenti nel database. Ad esempio, average_salary in un dipartimento non deve essere salvato direttamente nel database, ma può essere derivato. Per un altro esempio, l'età può essere derivata da data_of_birth.
Single-value attribute- Gli attributi a valore singolo contengono un valore singolo. Ad esempio: Social_Security_Number.
Multi-value attribute- Gli attributi multivalore possono contenere più di un valore. Ad esempio, una persona può avere più di un numero di telefono, email_address, ecc.

Questi tipi di attributi possono riunirsi in un modo del tipo:

attributi semplici a valore singolo
semplici attributi multivalore
attributi compositi a valore singolo
attributi multivalore compositi

Insieme di entità e chiavi

La chiave è un attributo o una raccolta di attributi che identifica in modo univoco un'entità nel set di entità.

Ad esempio, il roll_number di uno studente lo rende identificabile tra gli studenti.

Super Key - Un insieme di attributi (uno o più) che identifica collettivamente un'entità in un insieme di entità.
Candidate Key- Una super chiave minima è chiamata chiave candidata. Un set di entità può avere più di una chiave candidata.
Primary Key - Una chiave primaria è una delle chiavi candidate scelte dal progettista del database per identificare in modo univoco il set di entità.

Relazione

L'associazione tra entità è chiamata relazione. Ad esempio, un dipendenteworks_at un dipartimento, uno studente enrollsin un corso. Qui, Works_at e Enrolls sono chiamati relazioni.

Set di relazioni

Un insieme di relazioni di tipo simile è chiamato insieme di relazioni. Come le entità, anche una relazione può avere attributi. Questi attributi vengono chiamatidescriptive attributes.

Grado di relazione

Il numero di entità partecipanti a una relazione definisce il grado della relazione.

Binario = grado 2
Ternario = grado 3
n-ary = grado

Mappatura delle cardinalità

Cardinality definisce il numero di entità in un set di entità, che può essere associato al numero di entità di un altro set tramite set di relazioni.

One-to-one - Un'entità dell'insieme di entità A può essere associata al massimo a un'entità dell'insieme di entità B e viceversa.

One-to-many - Un'entità dall'insieme di entità A può essere associata a più di un'entità dall'insieme di entità B, tuttavia un'entità dall'insieme di entità B può essere associata al massimo a un'entità.

Many-to-one - Più di un'entità dell'insieme di entità A può essere associata al massimo a un'entità dell'insieme di entità B, tuttavia un'entità dell'insieme di entità B può essere associata a più di un'entità dell'insieme di entità A.

Many-to-many - Un'entità di A può essere associata a più entità di B e viceversa.

Vediamo ora come viene rappresentato il modello ER per mezzo di un diagramma ER. Qualsiasi oggetto, ad esempio entità, attributi di un'entità, insiemi di relazioni e attributi di insiemi di relazioni, può essere rappresentato con l'aiuto di un diagramma ER.

Entità

Le entità sono rappresentate per mezzo di rettangoli. I rettangoli vengono denominati con il set di entità che rappresentano.

Attributi

Gli attributi sono le proprietà delle entità. Gli attributi sono rappresentati tramite puntini di sospensione. Ogni ellisse rappresenta un attributo ed è direttamente collegata alla sua entità (rettangolo).

Se gli attributi sono composite, sono ulteriormente suddivisi in una struttura ad albero. Ogni nodo è quindi connesso al suo attributo. Cioè, gli attributi compositi sono rappresentati da ellissi che sono connesse con un'ellisse.

Multivalued gli attributi sono rappresentati da una doppia ellisse.

Derived gli attributi sono rappresentati da un'ellisse tratteggiata.

Relazione

Le relazioni sono rappresentate da una scatola a forma di diamante. Il nome della relazione è scritto all'interno della scatola dei diamanti. Tutte le entità (rettangoli) che partecipano a una relazione, sono collegate ad essa da una linea.

Relazione binaria e cardinalità

Una relazione a cui partecipano due entità è chiamata a binary relationship. La cardinalità è il numero di istanze di un'entità da una relazione che può essere associata alla relazione.

One-to-one- Quando solo un'istanza di un'entità è associata alla relazione, viene contrassegnata come "1: 1". L'immagine seguente riflette che solo un'istanza di ciascuna entità deve essere associata alla relazione. Raffigura la relazione uno a uno.

One-to-many- Quando più di un'istanza di un'entità è associata a una relazione, viene contrassegnata come "1: N". L'immagine seguente riflette che solo un'istanza di entità a sinistra e più di un'istanza di un'entità a destra possono essere associate alla relazione. Raffigura la relazione uno-a-molti.

Many-to-one- Quando più di un'istanza di entità è associata alla relazione, viene contrassegnata come "N: 1". L'immagine seguente riflette che più di un'istanza di un'entità a sinistra e solo un'istanza di un'entità a destra può essere associata alla relazione. Raffigura una relazione molti-a-uno.

Many-to-many- L'immagine seguente riflette che più di un'istanza di un'entità a sinistra e più di un'istanza di un'entità a destra possono essere associate alla relazione. Raffigura una relazione molti-a-molti.

Vincoli di partecipazione

Total Participation- Ogni entità è coinvolta nella relazione. La partecipazione totale è rappresentata da doppie linee.
Partial participation- Non tutte le entità sono coinvolte nella relazione. La partecipazione parziale è rappresentata da singole linee.

Entità

Le entità sono rappresentate per mezzo di rettangoli. I rettangoli vengono denominati con il set di entità che rappresentano.

Attributi

Multivalued gli attributi sono rappresentati da una doppia ellisse.

Derived gli attributi sono rappresentati da un'ellisse tratteggiata.

Relazione

Relazione binaria e cardinalità

Una relazione a cui partecipano due entità è chiamata a binary relationship. La cardinalità è il numero di istanze di un'entità da una relazione che può essere associata alla relazione.

One-to-one- Quando solo un'istanza di un'entità è associata alla relazione, viene contrassegnata come "1: 1". L'immagine seguente riflette che solo un'istanza di ciascuna entità deve essere associata alla relazione. Raffigura la relazione uno a uno.

One-to-many- Quando più di un'istanza di un'entità è associata a una relazione, viene contrassegnata come "1: N". L'immagine seguente riflette che solo un'istanza di entità a sinistra e più di un'istanza di un'entità a destra possono essere associate alla relazione. Raffigura la relazione uno-a-molti.

Many-to-one- Quando più di un'istanza di entità è associata alla relazione, viene contrassegnata come "N: 1". L'immagine seguente riflette che più di un'istanza di un'entità a sinistra e solo un'istanza di un'entità a destra può essere associata alla relazione. Raffigura una relazione molti-a-uno.

Many-to-many- L'immagine seguente riflette che più di un'istanza di un'entità a sinistra e più di un'istanza di un'entità a destra possono essere associate alla relazione. Raffigura una relazione molti-a-molti.

Vincoli di partecipazione

Total Participation- Ogni entità è coinvolta nella relazione. La partecipazione totale è rappresentata da doppie linee.
Partial participation- Non tutte le entità sono coinvolte nella relazione. La partecipazione parziale è rappresentata da singole linee.

Il modello ER ha il potere di esprimere le entità del database in modo gerarchico concettuale. Man mano che la gerarchia sale, generalizza la visione delle entità e, man mano che andiamo in profondità nella gerarchia, ci fornisce i dettagli di ogni entità inclusa.

Si chiama salire in questa struttura generalization, in cui le entità vengono riunite per rappresentare una visione più generalizzata. Ad esempio, un particolare studente di nome Mira può essere generalizzato insieme a tutti gli studenti. L'entità deve essere uno studente e, inoltre, lo studente è una persona. Viene chiamato il contrariospecialization dove una persona è uno studente e quello studente è Mira.

Generalizzazione

Come accennato in precedenza, il processo di generalizzazione delle entità, in cui le entità generalizzate contengono le proprietà di tutte le entità generalizzate, è chiamato generalizzazione. Nella generalizzazione, un numero di entità vengono riunite in un'unica entità generalizzata in base alle loro caratteristiche simili. Ad esempio, piccione, passero domestico, corvo e colomba possono essere generalizzati come uccelli.

Specializzazione

La specializzazione è l'opposto della generalizzazione. Nella specializzazione, un gruppo di entità è suddiviso in sottogruppi in base alle loro caratteristiche. Prendiamo ad esempio un gruppo "Persona". Una persona ha nome, data di nascita, sesso, ecc. Queste proprietà sono comuni a tutte le persone, gli esseri umani. Ma in un'azienda, le persone possono essere identificate come dipendenti, datori di lavoro, clienti o fornitori, in base al ruolo che svolgono nell'azienda.

Allo stesso modo, in un database scolastico, le persone possono essere specializzate come insegnanti, studenti o personale, in base al ruolo che svolgono nella scuola come entità.

Eredità

Usiamo tutte le caratteristiche di cui sopra di ER-Model per creare classi di oggetti nella programmazione orientata agli oggetti. I dettagli delle entità sono generalmente nascosti all'utente; questo processo noto comeabstraction.

L'ereditarietà è una caratteristica importante della generalizzazione e della specializzazione. Consente alle entità di livello inferiore di ereditare gli attributi delle entità di livello superiore.

Ad esempio, gli attributi di una classe Person come nome, età e sesso possono essere ereditati da entità di livello inferiore come Studente o Insegnante.

Il dottor Edgar F. Codd, dopo la sua vasta ricerca sul modello relazionale dei sistemi di database, ha elaborato dodici regole proprie, alle quali, secondo lui, un database deve obbedire per essere considerato come un vero database relazionale.

Queste regole possono essere applicate su qualsiasi sistema di database che gestisce i dati archiviati utilizzando solo le sue capacità relazionali. Questa è una regola fondamentale, che funge da base per tutte le altre regole.

Regola 1: regola dell'informazione

I dati memorizzati in un database, possono essere dati utente o metadati, devono essere un valore di una cella di tabella. Tutto in un database deve essere archiviato in un formato tabella.

Regola 2: regola di accesso garantito

Ogni singolo elemento di dati (valore) è garantito per essere accessibile in modo logico con una combinazione di nome-tabella, chiave-primaria (valore di riga) e nome-attributo (valore di colonna). Nessun altro mezzo, come i puntatori, può essere utilizzato per accedere ai dati.

Regola 3: trattamento sistematico dei valori NULL

I valori NULL in un database devono ricevere un trattamento sistematico e uniforme. Questa è una regola molto importante perché un NULL può essere interpretato come uno dei seguenti: dati mancanti, dati non noti o dati non applicabili.

Regola 4: catalogo online attivo

La descrizione della struttura dell'intero database deve essere memorizzata in un catalogo online, noto come data dictionary, a cui possono accedere gli utenti autorizzati. Gli utenti possono utilizzare lo stesso linguaggio di query per accedere al catalogo che utilizzano per accedere al database stesso.

Regola 5: regola completa del linguaggio secondario dei dati

È possibile accedere a un database solo utilizzando un linguaggio con sintassi lineare che supporta la definizione dei dati, la manipolazione dei dati e le operazioni di gestione delle transazioni. Questa lingua può essere utilizzata direttamente o tramite un'applicazione. Se il database consente l'accesso ai dati senza l'aiuto di questo linguaggio, viene considerato una violazione.

Regola 6: Visualizza regola di aggiornamento

Tutte le viste di un database, che teoricamente possono essere aggiornate, devono anche essere aggiornabili dal sistema.

Regola 7: regola di inserimento, aggiornamento ed eliminazione di alto livello

Un database deve supportare l'inserimento, l'aggiornamento e l'eliminazione di alto livello. Questo non deve essere limitato a una singola riga, ovvero deve supportare anche operazioni di unione, intersezione e meno per produrre set di record di dati.

Regola 8: indipendenza fisica dei dati

I dati memorizzati in un database devono essere indipendenti dalle applicazioni che accedono al database. Qualsiasi cambiamento nella struttura fisica di un database non deve avere alcun impatto sulla modalità di accesso ai dati da parte di applicazioni esterne.

Regola 9: indipendenza logica dei dati

I dati logici in un database devono essere indipendenti dalla vista dell'utente (applicazione). Qualsiasi modifica nei dati logici non deve influire sulle applicazioni che li utilizzano. Ad esempio, se due tabelle vengono unite o una viene suddivisa in due tabelle diverse, non dovrebbe esserci alcun impatto o modifica sull'applicazione utente. Questa è una delle regole più difficili da applicare.

Regola 10: Integrità Indipendenza

Un database deve essere indipendente dall'applicazione che lo utilizza. Tutti i suoi vincoli di integrità possono essere modificati indipendentemente senza la necessità di alcun cambiamento nell'applicazione. Questa regola rende un database indipendente dall'applicazione front-end e dalla sua interfaccia.

Regola 11: indipendenza dalla distribuzione

L'utente finale non deve essere in grado di vedere che i dati sono distribuiti in varie posizioni. Gli utenti dovrebbero sempre avere l'impressione che i dati si trovino in un solo sito. Questa regola è stata considerata la base dei sistemi di database distribuiti.

Regola 12: Regola di non sovversione

Se un sistema ha un'interfaccia che fornisce l'accesso a record di basso livello, l'interfaccia non deve essere in grado di sovvertire il sistema e aggirare i vincoli di sicurezza e integrità.

Il modello di dati relazionale è il modello di dati principale, ampiamente utilizzato in tutto il mondo per l'archiviazione e l'elaborazione dei dati. Questo modello è semplice e ha tutte le proprietà e le capacità necessarie per elaborare i dati con efficienza di archiviazione.

Concetti

Tables- Nel modello di dati relazionali, le relazioni vengono salvate nel formato delle tabelle. Questo formato memorizza la relazione tra le entità. Una tabella ha righe e colonne, dove le righe rappresentano i record e le colonne rappresentano gli attributi.

Tuple - Una singola riga di una tabella, che contiene un singolo record per quella relazione è chiamata tupla.

Relation instance- Un insieme finito di tuple nel sistema di database relazionale rappresenta l'istanza della relazione. Le istanze di relazione non hanno tuple duplicate.

Relation schema - Uno schema di relazione descrive il nome della relazione (nome della tabella), gli attributi e i loro nomi.

Relation key - Ogni riga ha uno o più attributi, noti come chiave di relazione, che possono identificare in modo univoco la riga nella relazione (tabella).

Attribute domain - Ogni attributo ha un ambito di valore predefinito, noto come dominio dell'attributo.

Vincoli

Ogni relazione ha delle condizioni che devono valere perché sia una relazione valida. Queste condizioni sono chiamateRelational Integrity Constraints. Ci sono tre principali vincoli di integrità:

Vincoli chiave
Vincoli di dominio
Vincoli di integrità referenziale

Vincoli chiave

Ci deve essere almeno un sottoinsieme minimo di attributi nella relazione, che può identificare una tupla in modo univoco. Viene chiamato questo sottoinsieme minimo di attributikeyper quella relazione. Se sono presenti più di uno di questi sottoinsiemi minimi, questi vengono chiamaticandidate keys.

I vincoli chiave impongono che:

in una relazione con un attributo chiave, due tuple non possono avere valori identici per attributi chiave.
un attributo chiave non può avere valori NULL.

I vincoli chiave sono indicati anche come vincoli di entità.

Vincoli di dominio

Gli attributi hanno valori specifici nello scenario del mondo reale. Ad esempio, l'età può essere solo un numero intero positivo. Gli stessi vincoli sono stati tentati di utilizzare sugli attributi di una relazione. Ogni attributo è vincolato ad avere uno specifico intervallo di valori. Ad esempio, l'età non può essere inferiore a zero e i numeri di telefono non possono contenere una cifra al di fuori di 0-9.

Vincoli di integrità referenziale

I vincoli di integrità referenziale funzionano sul concetto di chiavi esterne. Una chiave esterna è un attributo chiave di una relazione a cui si può fare riferimento in un'altra relazione.

Il vincolo di integrità referenziale afferma che se una relazione fa riferimento a un attributo chiave di una relazione diversa o uguale, allora quell'elemento chiave deve esistere.

I sistemi di database relazionali dovrebbero essere dotati di un linguaggio di query che possa aiutare gli utenti a interrogare le istanze del database. Esistono due tipi di linguaggi di query: algebra relazionale e calcolo relazionale.

Algebra relazionale

L'algebra relazionale è un linguaggio di query procedurale, che accetta istanze di relazioni come input e restituisce istanze di relazioni come output. Utilizza gli operatori per eseguire le query. Un operatore può essere l'uno o l'altrounary o binary. Accettano le relazioni come input e producono le relazioni come output. L'algebra relazionale viene eseguita in modo ricorsivo su una relazione e anche i risultati intermedi sono considerati relazioni.

Le operazioni fondamentali dell'algebra relazionale sono le seguenti:

Select
Project
Union
Set diverso
prodotto cartesiano
Rename

Discuteremo tutte queste operazioni nelle sezioni seguenti.

Seleziona operazione (σ)

Seleziona le tuple che soddisfano il predicato dato da una relazione.

Notation- σ _p (r)

Dove σ sta per predicato di selezione e rsta per relazione. p è una formula logica preposizionale che può utilizzare connettori comeand, or, e not. Questi termini possono utilizzare operatori relazionali come - =, ≠, ≥, <,>, ≤.

For example -

σ_{subject="database"}(Books)

Output - Seleziona le tuple dai libri in cui l'oggetto è "database".

σ_{subject="database" and price="450"}(Books)

Output - Seleziona le tuple dai libri in cui l'oggetto è "database" e "prezzo" è 450.

σ_{subject="database" and price < "450" or year > "2010"}(Books)

Output - Seleziona le tuple dai libri in cui l'oggetto è "database" e il "prezzo" è 450 o dai libri pubblicati dopo il 2010.

Operazione del progetto (∏)

Proietta le colonne che soddisfano un dato predicato.

Notazione - ∏ _{A ₁ , A ₂ , A _n} (r)

Dove A ₁ , A ₂ , A _n sono nomi di attributi di relazioner.

Le righe duplicate vengono eliminate automaticamente, poiché la relazione è un insieme.

For example -

 ∏_{subject, author} (Books)

Seleziona e proietta colonne denominate come soggetto e autore dalla relazione Libri.

Operazione dell'Unione (∪)

Esegue l'unione binaria tra due relazioni date ed è definito come -

 r ∪ s = { t | t ∈ r or t ∈ s}

Notation - r U s

Dove r e s sono relazioni di database o set di risultati di relazione (relazione temporanea).

Perché un'operazione sindacale sia valida, devono sussistere le seguenti condizioni:

r, e s deve avere lo stesso numero di attributi.
I domini degli attributi devono essere compatibili.
Le tuple duplicate vengono eliminate automaticamente.

 ∏ _author (Books) ∪ ∏ _author (Articles)

Output - Proietta i nomi degli autori che hanno scritto un libro o un articolo o entrambi.

Imposta differenza (-)

Il risultato dell'operazione di set differenza sono le tuple, che sono presenti in una relazione ma non nella seconda relazione.

Notation - r - s

Trova tutte le tuple presenti in r ma non in s.

 ∏ _author (Books) − ∏ _author (Articles)

Output - Fornisce il nome degli autori che hanno scritto libri ma non articoli.

Prodotto cartesiano (Χ)

Combina le informazioni di due diverse relazioni in una.

Notation - r Χ s

Dove r e s sono relazioni e il loro output sarà definito come -

r Χ s = {qt | q ∈ r e t ∈ s}

 ∏ _{author = 'tutorialspoint'}(Books Χ Articles)

Output - Restituisce una relazione, che mostra tutti i libri e gli articoli scritti da tutorialspoint.

Rinomina operazione (ρ)

Anche i risultati dell'algebra relazionale sono relazioni ma senza nome. L'operazione di rinomina ci permette di rinominare la relazione di output. l'operazione "rinomina" è indicata con una piccola lettera grecarho ρ .

Notation- ρ _x (E)

Dove il risultato dell'espressione E viene salvato con il nome di x.

Ulteriori operazioni sono:

Imposta l'intersezione
Assignment
Unione naturale

Calcolo relazionale

A differenza dell'algebra relazionale, il calcolo relazionale è un linguaggio di query non procedurale, ovvero dice cosa fare ma non spiega mai come farlo.

Il calcolo relazionale esiste in due forme:

Tuple Relational Calculus (TRC)

Filtraggio di intervalli di variabili su tuple

Notation- {T | Condizione}

Restituisce tutte le tuple T che soddisfano una condizione.

For example -

{ T.name |  Author(T) AND T.article = 'database' }

Output - Restituisce tuple con "nome" dall'autore che ha scritto l'articolo su "database".

TRC può essere quantificato. Possiamo usare Existential (∃) e Universal Quantifiers (∀).

For example -

{ R| ∃T   ∈ Authors(T.article='database' AND R.name=T.name)}

Output - La query precedente produrrà lo stesso risultato della precedente.

Domain Relational Calculus (DRC)

In DRC, la variabile di filtro utilizza il dominio degli attributi invece di interi valori di tupla (come fatto in TRC, menzionato sopra).

Notation -

{a ₁ , a ₂ , a ₃ , ..., a _n | P (a ₁ , a ₂ , a ₃ , ..., a _n )}

Dove a1, a2 sono attributi e P sta per formule costruite da attributi interni.

For example -

{< article, page, subject > | 
       
         ∈ TutorialsPoint ∧ subject = 'database'}

Output - Restituisce Articolo, Pagina e Oggetto dalla relazione TutorialsPoint, dove l'oggetto è il database.

Proprio come TRC, anche DRC può essere scritto utilizzando quantificatori esistenziali e universali. Il DRC coinvolge anche operatori relazionali.

La potenza di espressione di Tuple Relation Calculus e Domain Relation Calculus è equivalente all'algebra relazionale.

Il modello ER, quando concettualizzato in diagrammi, fornisce una buona panoramica della relazione tra entità, che è più facile da capire. I diagrammi ER possono essere mappati su schemi relazionali, ovvero è possibile creare schemi relazionali utilizzando il diagramma ER. Non è possibile importare tutti i vincoli ER nel modello relazionale, ma è possibile generare uno schema approssimativo.

Sono disponibili diversi processi e algoritmi per convertire i diagrammi ER in schemi relazionali. Alcuni di loro sono automatizzati e alcuni di loro sono manuali. Potremmo concentrarci qui sul contenuto del diagramma di mappatura alle basi relazionali.

I diagrammi ER comprendono principalmente:

Entità e suoi attributi
Relazione, che è associazione tra entità.

Entità di mappatura

Un'entità è un oggetto del mondo reale con alcuni attributi.

Processo di mappatura (algoritmo)

Crea una tabella per ogni entità.
Gli attributi dell'entità dovrebbero diventare campi di tabelle con i rispettivi tipi di dati.
Dichiara la chiave primaria.

Mappatura delle relazioni

Una relazione è un'associazione tra entità.

Processo di mappatura

Crea una tabella per una relazione.
Aggiungi le chiavi primarie di tutte le Entità partecipanti come campi della tabella con i rispettivi tipi di dati.
Se la relazione ha un attributo, aggiungi ogni attributo come campo della tabella.
Dichiarare una chiave primaria che componga tutte le chiavi primarie delle entità partecipanti.
Dichiara tutti i vincoli di chiave esterna.

Mappatura di insiemi di entità deboli

Un insieme di entità debole è uno a cui non è associata alcuna chiave primaria.

Processo di mappatura

Crea una tabella per l'insieme di entità deboli.
Aggiungi tutti i suoi attributi alla tabella come campo.
Aggiungi la chiave primaria di identificazione del set di entità.
Dichiara tutti i vincoli di chiave esterna.

Mappatura delle entità gerarchiche

La specializzazione o la generalizzazione ER si presenta sotto forma di insiemi di entità gerarchiche.

Processo di mappatura

Crea tabelle per tutte le entità di livello superiore.
Crea tabelle per entità di livello inferiore.
Aggiungi le chiavi primarie delle entità di livello superiore nella tabella delle entità di livello inferiore.
Nelle tabelle di livello inferiore, aggiungi tutti gli altri attributi delle entità di livello inferiore.
Dichiarare la chiave primaria della tabella di livello superiore e la chiave primaria per la tabella di livello inferiore.
Dichiarare i vincoli di chiave esterna.

SQL è un linguaggio di programmazione per database relazionali. È progettato su algebra relazionale e calcolo relazionale su tuple. SQL viene fornito come pacchetto con tutte le principali distribuzioni di RDBMS.

SQL comprende sia la definizione dei dati che i linguaggi di manipolazione dei dati. Utilizzando le proprietà di definizione dei dati di SQL, è possibile progettare e modificare lo schema del database, mentre le proprietà di manipolazione dei dati consentono a SQL di archiviare e recuperare i dati dal database.

Linguaggio di definizione dei dati

SQL utilizza il seguente set di comandi per definire lo schema del database:

CREARE

Crea nuovi database, tabelle e viste da RDBMS.

For example -

Create database tutorialspoint;
Create table article;
Create view for_students;

FAR CADERE

Elimina comandi, viste, tabelle e database da RDBMS.

For example-

Drop object_type object_name;
Drop database tutorialspoint;
Drop table article;
Drop view for_students;

ALTER

Modifica lo schema del database.

Alter object_type object_name parameters;

For example-

Alter table article add subject varchar;

Questo comando aggiunge un attributo nella relazione article con il nome subject di tipo stringa.

Linguaggio di manipolazione dei dati

SQL è dotato di linguaggio di manipolazione dei dati (DML). DML modifica l'istanza del database inserendo, aggiornando ed eliminando i suoi dati. DML è responsabile di tutte le modifiche ai dati dei moduli in un database. SQL contiene il seguente set di comandi nella sua sezione DML:

SELECT/FROM/WHERE
INSERISCI IN / VALORI
UPDATE/SET/WHERE
CANCELLA DA / DOVE

Questi costrutti di base consentono ai programmatori di database e agli utenti di inserire dati e informazioni nel database e di recuperarli in modo efficiente utilizzando una serie di opzioni di filtro.

SELEZIONA / DA / DOVE

SELECT- Questo è uno dei comandi di query fondamentali di SQL. È simile all'operazione di proiezione dell'algebra relazionale. Seleziona gli attributi in base alla condizione descritta dalla clausola WHERE.
FROM- Questa clausola accetta il nome di una relazione come argomento da cui selezionare / proiettare gli attributi. Nel caso in cui vengano forniti più nomi di relazione, questa clausola corrisponde al prodotto cartesiano.
WHERE - Questa clausola definisce il predicato o le condizioni, che devono corrispondere per qualificare gli attributi da proiettare.

For example -

Select author_name
From book_author
Where age > 50;

Questo comando produrrà i nomi degli autori dalla relazione book_author la cui età è maggiore di 50 anni.

INSERISCI IN / VALORI

Questo comando viene utilizzato per inserire valori nelle righe di una tabella (relazione).

Syntax-

INSERT INTO table (column1 [, column2, column3 ... ]) VALUES (value1 [, value2, value3 ... ])

INSERT INTO table VALUES (value1, [value2, ... ])

For example -

INSERT INTO tutorialspoint (Author, Subject) VALUES ("anonymous", "computers");

AGGIORNA / IMPOSTA / DOVE

Questo comando viene utilizzato per aggiornare o modificare i valori delle colonne in una tabella (relazione).

Syntax -

UPDATE table_name SET column_name = value [, column_name = value ...] [WHERE condition]

For example -

UPDATE tutorialspoint SET Author="webmaster" WHERE Author="anonymous";

CANCELLA / DA / DOVE

Questo comando viene utilizzato per rimuovere una o più righe da una tabella (relazione).

Syntax -

DELETE FROM table_name [WHERE condition];

For example -

DELETE FROM tutorialspoints
   WHERE Author="unknown";

Dipendenza funzionale

La dipendenza funzionale (FD) è un insieme di vincoli tra due attributi in una relazione. La dipendenza funzionale dice che se due tuple hanno gli stessi valori per gli attributi A1, A2, ..., An, allora quelle due tuple devono avere gli stessi valori per gli attributi B1, B2, ..., Bn.

La dipendenza funzionale è rappresentata da un segno di freccia (→) cioè X → Y, dove X determina funzionalmente Y. Gli attributi del lato sinistro determinano i valori degli attributi sul lato destro.

Assiomi di Armstrong

Se F è un insieme di dipendenze funzionali, allora la chiusura di F, indicata come F ⁺ , è l'insieme di tutte le dipendenze funzionali logicamente implicite da F. Gli assiomi di F.Armstrong sono un insieme di regole che, se applicate ripetutamente, genera una chiusura di dipendenze funzionali .

Reflexive rule - Se alpha è un insieme di attributi e beta è_subset_of alpha, allora alpha contiene beta.
Augmentation rule- Se a → b vale ey è un attributo impostato, vale anche ay → by. Ovvero l'aggiunta di attributi nelle dipendenze, non modifica le dipendenze di base.
Transitivity rule- Come la regola transitiva in algebra, se a → b vale e b → c vale, allora vale anche a → c. a → b è chiamato come funzionalmente che determina b.

Banale dipendenza funzionale

Trivial- Se vale una dipendenza funzionale (FD) X → Y, dove Y è un sottoinsieme di X, allora è chiamata FD banale. I banali FD valgono sempre.
Non-trivial - Se vale un FD X → Y, dove Y non è un sottoinsieme di X, allora è chiamato FD non banale.
Completely non-trivial - Se vale un FD X → Y, dove x interseca Y = Φ, si dice che è un FD completamente non banale.

Normalizzazione

Se la progettazione di un database non è perfetta, potrebbe contenere anomalie, che sono come un brutto sogno per qualsiasi amministratore di database. Gestire un database con anomalie è quasi impossibile.

Update anomalies- Se gli elementi di dati sono sparsi e non sono collegati tra loro correttamente, potrebbe portare a situazioni strane. Ad esempio, quando proviamo ad aggiornare un elemento di dati con le sue copie sparse in più punti, alcune istanze vengono aggiornate correttamente mentre alcune altre rimangono con valori precedenti. Tali istanze lasciano il database in uno stato incoerente.
Deletion anomalies - Abbiamo provato a cancellare un record, ma parti di esso sono state lasciate non cancellate a causa dell'inconsapevolezza, i dati vengono salvati anche altrove.
Insert anomalies - Abbiamo provato a inserire dati in un record che non esiste affatto.

La normalizzazione è un metodo per rimuovere tutte queste anomalie e portare il database a uno stato coerente.

Prima forma normale

La prima forma normale è definita nella definizione delle relazioni (tabelle) stessa. Questa regola definisce che tutti gli attributi in una relazione devono avere domini atomici. I valori in un dominio atomico sono unità indivisibili.

Riorganizziamo la relazione (tabella) come di seguito, per convertirla in Prima forma normale.

Ogni attributo deve contenere un solo valore dal proprio dominio predefinito.

Seconda forma normale

Prima di conoscere la seconda forma normale, dobbiamo comprendere quanto segue:

Prime attribute - Un attributo, che fa parte della chiave candidata, è noto come attributo principale.
Non-prime attribute - Un attributo, che non fa parte della chiave principale, si dice che sia un attributo non primo.

Se seguiamo la seconda forma normale, ogni attributo non primo dovrebbe essere completamente funzionalmente dipendente dall'attributo chiave principale. Cioè, se X → A vale, allora non dovrebbe esserci alcun sottoinsieme appropriato Y di X, per il quale vale anche Y → A.

Vediamo qui nella relazione Student_Project che gli attributi della chiave principale sono Stu_ID e Proj_ID. Secondo la regola, gli attributi non chiave, ad esempio Stu_Name e Proj_Name, devono dipendere da entrambi e non da nessuno degli attributi della chiave principale individualmente. Ma troviamo che Stu_Name può essere identificato da Stu_ID e Proj_Name può essere identificato da Proj_ID indipendentemente. Questo è chiamatopartial dependency, che non è consentito nella seconda forma normale.

Abbiamo rotto la relazione in due come illustrato nella foto sopra. Quindi non esiste una dipendenza parziale.

Terza forma normale

Affinché una relazione sia nella terza forma normale, deve essere nella seconda forma normale e quanto segue deve soddisfare:

Nessun attributo non primo dipende transitivamente dall'attributo chiave prime.

Per qualsiasi dipendenza funzionale non banale, X → A, allora o -

A è un attributo principale.

Troviamo che nella relazione Student_detail sopra, Stu_ID è la chiave e l'unico attributo chiave principale. Troviamo che la città può essere identificata da Stu_ID così come da Zip stesso. Né Zip è un superkey né City un attributo principale. Inoltre, Stu_ID → Zip → City, quindi esistetransitive dependency.

Per portare questa relazione nella terza forma normale, suddividiamo la relazione in due relazioni come segue:

Forma normale di Boyce-Codd

Boyce-Codd Normal Form (BCNF) è un'estensione della terza forma normale in termini rigorosi. BCNF afferma che -

Per qualsiasi dipendenza funzionale non banale, X → A, X deve essere una superchiave.

Nell'immagine sopra, Stu_ID è la superchiave nella relazione Student_Detail e Zip è la superchiave nella relazione ZipCodes. Così,

Stu_ID → Stu_Name, Zip

CAP → Città

Il che conferma che entrambe le relazioni sono in BCNF.

Comprendiamo i vantaggi di prendere un prodotto cartesiano di due relazioni, che ci fornisce tutte le possibili tuple che sono accoppiate insieme. Ma potrebbe non essere fattibile per noi in alcuni casi prendere un prodotto cartesiano in cui incontriamo relazioni enormi con migliaia di tuple aventi un numero considerevole di attributi.

Joinè una combinazione di un prodotto cartesiano seguito da un processo di selezione. Un'operazione di join accoppia due tuple da relazioni diverse, se e solo se una data condizione di join è soddisfatta.

Descriveremo brevemente i vari tipi di join nelle sezioni seguenti.

Theta (θ) Partecipa

Il join theta combina tuple di diverse relazioni a condizione che soddisfino la condizione theta. La condizione di join è indicata dal simboloθ.

Notazione

R1 ⋈_θ R2

R1 e R2 sono relazioni aventi attributi (A1, A2, .., An) e (B1, B2, .., Bn) tali che gli attributi non hanno nulla in comune, cioè R1 ∩ R2 = Φ.

Il join theta può utilizzare tutti i tipi di operatori di confronto.

Alunno
SID	Nome	Std
101	Alex	10
102	Maria	11

Soggetti
Classe	Soggetto
10	Matematica
10	Inglese
11	Musica
11	Gli sport

Student_Detail =

STUDENT ⋈_{Student.Std = Subject.Class} SUBJECT

Student_detail
SID	Nome	Std	Classe	Soggetto
101	Alex	10	10	Matematica
101	Alex	10	10	Inglese
102	Maria	11	11	Musica
102	Maria	11	11	Gli sport

Equijoin

Quando Theta join utilizza solo equalityoperatore di confronto, si dice che sia equijoin. L'esempio sopra corrisponde a equijoin.

Natural Join ( ⋈ )

Il join naturale non utilizza alcun operatore di confronto. Non concatena come fa un prodotto cartesiano. Possiamo eseguire un Natural Join solo se esiste almeno un attributo comune che esiste tra due relazioni. Inoltre, gli attributi devono avere lo stesso nome e dominio.

Il join naturale agisce su quegli attributi corrispondenti in cui i valori degli attributi in entrambe le relazioni sono gli stessi.

Corsi
CID	Corso	Dipartimento
CS01	Banca dati	CS
ME01	Meccanica	ME
EE01	Elettronica	EE

HoD
Dipartimento	Testa
CS	Alex
ME	maya
EE	Mira

Corsi ⋈ HoD
Dipartimento	CID	Corso	Testa
CS	CS01	Banca dati	Alex
ME	ME01	Meccanica	maya
EE	EE01	Elettronica	Mira

Outer Joins

Theta Join, Equijoin e Natural Join sono chiamati inner join. Un'unione interna include solo quelle tuple con attributi corrispondenti e il resto viene scartato nella relazione risultante. Pertanto, è necessario utilizzare i join esterni per includere tutte le tuple delle relazioni partecipanti nella relazione risultante. Esistono tre tipi di join esterni: join esterno sinistro, join esterno destro e join esterno completo.

Join esterno sinistro (R

S)

Tutte le tuple dalla relazione Left, R, sono incluse nella relazione risultante. Se ci sono tuple in R senza alcuna tupla corrispondente nella relazione Right S, allora gli attributi S della relazione risultante vengono resi NULL.

Sinistra
UN	B
100	Banca dati
101	Meccanica
102	Elettronica

Destra
UN	B
100	Alex
102	maya
104	Mira

Corsi HoD
UN	B	C	D
100	Banca dati	100	Alex
101	Meccanica	---	---
102	Elettronica	102	maya

Join esterno destro: (R

S)

Tutte le tuple dalla relazione Right, S, sono incluse nella relazione risultante. Se ci sono tuple in S senza alcuna tupla corrispondente in R, allora gli attributi R della relazione risultante vengono resi NULL.

Corsi HoD
UN	B	C	D
100	Banca dati	100	Alex
102	Elettronica	102	maya
---	---	104	Mira

Join esterno completo: (R

S)

Tutte le tuple di entrambe le relazioni partecipanti sono incluse nella relazione risultante. Se non ci sono tuple corrispondenti per entrambe le relazioni, i rispettivi attributi non corrispondenti vengono resi NULL.

Corsi HoD
UN	B	C	D
100	Banca dati	100	Alex
101	Meccanica	---	---
102	Elettronica	102	maya
---	---	104	Mira

I database vengono archiviati in formati di file che contengono record. A livello fisico, i dati effettivi vengono memorizzati in formato elettromagnetico su alcuni dispositivi. Questi dispositivi di archiviazione possono essere ampiamente classificati in tre tipi:

Primary Storage- La memoria che è direttamente accessibile alla CPU rientra in questa categoria. La memoria interna della CPU (registri), la memoria veloce (cache) e la memoria principale (RAM) sono direttamente accessibili alla CPU, poiché sono tutte posizionate sulla scheda madre o sul chipset della CPU. Questa memoria è in genere molto piccola, ultra veloce e volatile. La memoria primaria richiede un'alimentazione continua per mantenere il suo stato. In caso di interruzione di corrente, tutti i suoi dati vengono persi.
Secondary Storage- I dispositivi di archiviazione secondari vengono utilizzati per memorizzare i dati per un utilizzo futuro o come backup. La memoria secondaria include dispositivi di memoria che non fanno parte del chipset della CPU o della scheda madre, ad esempio dischi magnetici, dischi ottici (DVD, CD, ecc.), Dischi rigidi, unità flash e nastri magnetici.
Tertiary Storage- L'archiviazione terziaria viene utilizzata per archiviare enormi volumi di dati. Poiché tali dispositivi di archiviazione sono esterni al sistema del computer, sono i più lenti in velocità. Questi dispositivi di archiviazione vengono utilizzati principalmente per eseguire il backup di un intero sistema. I dischi ottici e i nastri magnetici sono ampiamente utilizzati come archiviazione terziaria.

Gerarchia della memoria

Un sistema informatico ha una gerarchia di memoria ben definita. Una CPU ha accesso diretto alla memoria principale e ai registri incorporati. Il tempo di accesso alla memoria principale è ovviamente inferiore alla velocità della CPU. Per ridurre al minimo questa discrepanza di velocità, viene introdotta la memoria cache. La memoria cache fornisce il tempo di accesso più veloce e contiene i dati a cui la CPU accede più di frequente.

La memoria con l'accesso più veloce è quella più costosa. I dispositivi di archiviazione più grandi offrono una velocità ridotta e sono meno costosi, tuttavia possono archiviare enormi volumi di dati rispetto ai registri della CPU o alla memoria cache.

Dischi magnetici

Le unità disco rigido sono i dispositivi di archiviazione secondaria più comuni negli attuali sistemi di computer. Questi sono chiamati dischi magnetici perché usano il concetto di magnetizzazione per memorizzare le informazioni. I dischi rigidi sono costituiti da dischi di metallo rivestiti con materiale magnetizzabile. Questi dischi sono posizionati verticalmente su un mandrino. Una testina di lettura / scrittura si muove tra i dischi e viene utilizzata per magnetizzare o smagnetizzare il punto sottostante. Un punto magnetizzato può essere riconosciuto come 0 (zero) o 1 (uno).

I dischi rigidi sono formattati in un ordine ben definito per archiviare i dati in modo efficiente. Una piastra del disco rigido ha molti cerchi concentrici su di essa, chiamatitracks. Ogni traccia è ulteriormente suddivisa insectors. Un settore su un disco rigido in genere memorizza 512 byte di dati.

RAID

RAID sta per Redundant Array of Indipendente Disks, una tecnologia per connettere più dispositivi di archiviazione secondari e utilizzarli come un unico supporto di archiviazione.

RAID è costituito da un array di dischi in cui più dischi sono collegati insieme per raggiungere obiettivi diversi. I livelli RAID definiscono l'uso degli array di dischi.

RAID 0- In questo livello, è implementato un array di dischi con striping. I dati vengono suddivisi in blocchi e i blocchi vengono distribuiti tra i dischi. Ogni disco riceve un blocco di dati da scrivere / leggere in parallelo. Migliora la velocità e le prestazioni del dispositivo di archiviazione. Non sono presenti parità e backup nel livello 0.

RAID 1- RAID 1 utilizza tecniche di mirroring. Quando i dati vengono inviati a un controller RAID, invia una copia dei dati a tutti i dischi dell'array. Viene anche chiamato il livello RAID 1mirroring e fornisce una ridondanza del 100% in caso di guasto.

RAID 2- RAID 2 registra il codice di correzione degli errori utilizzando la distanza di Hamming per i suoi dati, con striping su dischi diversi. Come il livello 0, ogni bit di dati in una parola viene registrato su un disco separato e i codici ECC delle parole di dati vengono memorizzati su un diverso set di dischi. A causa della sua struttura complessa e del costo elevato, RAID 2 non è disponibile in commercio.

RAID 3- RAID 3 esegue lo striping dei dati su più dischi. Il bit di parità generato per la parola di dati viene memorizzato su un disco diverso. Questa tecnica consente di superare i guasti del disco singolo.

RAID 4- In questo livello, un intero blocco di dati viene scritto su dischi dati e quindi la parità viene generata e memorizzata su un disco diverso. Si noti che il livello 3 utilizza lo striping a livello di byte, mentre il livello 4 utilizza lo striping a livello di blocco. Sia il livello 3 che il livello 4 richiedono almeno tre dischi per implementare RAID.

RAID 5 - RAID 5 scrive interi blocchi di dati su dischi diversi, ma i bit di parità generati per lo stripe del blocco di dati vengono distribuiti tra tutti i dischi di dati anziché archiviarli su un diverso disco dedicato.

RAID 6- RAID 6 è un'estensione del livello 5. In questo livello, vengono generate due parità indipendenti e memorizzate in modo distribuito tra più dischi. Due parità forniscono ulteriore tolleranza agli errori. Questo livello richiede almeno quattro unità disco per implementare RAID.

I dati e le informazioni relativi vengono archiviati collettivamente in formati di file. Un file è una sequenza di record archiviati in formato binario. Un'unità disco è formattata in diversi blocchi che possono memorizzare i record. I record di file vengono mappati su quei blocchi del disco.

Organizzazione dei file

L'organizzazione dei file definisce il modo in cui i record dei file vengono mappati sui blocchi del disco. Abbiamo quattro tipi di organizzazione dei file per organizzare i record dei file:

Organizzazione file heap

Quando un file viene creato utilizzando Heap File Organization, il sistema operativo alloca l'area di memoria a quel file senza ulteriori dettagli contabili. I record di file possono essere collocati ovunque in quell'area di memoria. È responsabilità del software gestire i record. Il file heap non supporta da solo alcun ordinamento, sequenziamento o indicizzazione.

Organizzazione dei file sequenziali

Ogni record di file contiene un campo dati (attributo) per identificare in modo univoco quel record. Nell'organizzazione di file sequenziali, i record vengono inseriti nel file in un certo ordine sequenziale in base al campo chiave univoco o alla chiave di ricerca. In pratica, non è possibile memorizzare tutti i record sequenzialmente in forma fisica.

Organizzazione dei file hash

Hash File Organization utilizza il calcolo della funzione Hash su alcuni campi dei record. L'output della funzione hash determina la posizione del blocco del disco in cui devono essere posizionati i record.

Organizzazione di file in cluster

L'organizzazione dei file in cluster non è considerata buona per i database di grandi dimensioni. In questo meccanismo, i record correlati da una o più relazioni vengono conservati nello stesso blocco del disco, ovvero l'ordine dei record non è basato sulla chiave primaria o sulla chiave di ricerca.

Operazioni sui file

Le operazioni sui file di database possono essere generalmente classificate in due categorie:

Update Operations
Retrieval Operations

Le operazioni di aggiornamento modificano i valori dei dati mediante inserimento, eliminazione o aggiornamento. Le operazioni di recupero, invece, non alterano i dati ma li recuperano dopo un filtraggio condizionale opzionale. In entrambi i tipi di operazioni, la selezione gioca un ruolo significativo. Oltre alla creazione e all'eliminazione di un file, potrebbero esserci diverse operazioni che possono essere eseguite sui file.

Open - Un file può essere aperto in una delle due modalità, read mode o write mode. In modalità di lettura, il sistema operativo non consente a nessuno di alterare i dati. In altre parole, i dati sono di sola lettura. I file aperti in modalità di lettura possono essere condivisi tra più entità. La modalità di scrittura consente la modifica dei dati. I file aperti in modalità di scrittura possono essere letti ma non condivisi.
Locate- Ogni file ha un puntatore al file, che indica la posizione corrente in cui i dati devono essere letti o scritti. Questo puntatore può essere regolato di conseguenza. Usando l'operazione find (seek), può essere spostato in avanti o indietro.
Read- Per impostazione predefinita, quando i file vengono aperti in modalità di lettura, il puntatore del file punta all'inizio del file. Ci sono opzioni in cui l'utente può dire al sistema operativo dove posizionare il puntatore del file al momento dell'apertura di un file. Vengono letti i dati immediatamente successivi al puntatore del file.
Write- L'utente può scegliere di aprire un file in modalità di scrittura, che gli consente di modificarne il contenuto. Può essere cancellazione, inserimento o modifica. Il puntatore del file può essere posizionato al momento dell'apertura o può essere modificato dinamicamente se il sistema operativo lo consente.
Close- Questa è l'operazione più importante dal punto di vista del sistema operativo. Quando viene generata una richiesta di chiusura di un file, il sistema operativo
- rimuove tutti i blocchi (se in modalità condivisa),
- salva i dati (se modificati) sul supporto di memorizzazione secondario e
- rilascia tutti i buffer e gestori di file associati al file.

L'organizzazione dei dati all'interno di un file gioca un ruolo importante qui. Il processo per individuare il puntatore del file a un record desiderato all'interno di un file varia in base al fatto che i record siano disposti in sequenza o raggruppati.

Sappiamo che i dati vengono archiviati sotto forma di record. Ogni record ha un campo chiave, che lo aiuta a essere riconosciuto in modo univoco.

L'indicizzazione è una tecnica della struttura dei dati per recuperare in modo efficiente i record dai file di database in base ad alcuni attributi su cui è stata eseguita l'indicizzazione. L'indicizzazione nei sistemi di database è simile a ciò che vediamo nei libri.

L'indicizzazione è definita in base ai suoi attributi di indicizzazione. L'indicizzazione può essere dei seguenti tipi:

Primary Index- L'indice primario è definito su un file di dati ordinato. Il file di dati viene ordinato su un filekey field. Il campo chiave è generalmente la chiave primaria della relazione.
Secondary Index - L'indice secondario può essere generato da un campo che è una chiave candidata e ha un valore univoco in ogni record, o una non chiave con valori duplicati.
Clustering Index- L'indice di clustering è definito su un file di dati ordinato. Il file di dati è ordinato su un campo non chiave.

L'indicizzazione ordinata è di due tipi:

Indice denso
Indice sparse

Indice denso

In un indice denso, esiste un record di indice per ogni valore della chiave di ricerca nel database. Ciò rende la ricerca più veloce ma richiede più spazio per memorizzare i record dell'indice stesso. I record di indice contengono il valore della chiave di ricerca e un puntatore al record effettivo sul disco.

Indice sparse

Nell'indice sparse, i record dell'indice non vengono creati per ogni chiave di ricerca. Un record di indice qui contiene una chiave di ricerca e un puntatore effettivo ai dati sul disco. Per cercare un record, procediamo prima per record di indice e raggiungiamo la posizione effettiva dei dati. Se i dati che stiamo cercando non sono quelli che raggiungiamo direttamente seguendo l'indice, il sistema avvia la ricerca sequenziale fino a trovare i dati desiderati.

Indice multilivello

I record di indice comprendono valori di chiavi di ricerca e puntatori di dati. L'indice multilivello viene archiviato sul disco insieme ai file di database effettivi. Man mano che la dimensione del database cresce, aumenta anche la dimensione degli indici. C'è un'immensa necessità di mantenere i record dell'indice nella memoria principale in modo da velocizzare le operazioni di ricerca. Se viene utilizzato un indice a livello singolo, non è possibile mantenere in memoria un indice di grandi dimensioni che porta a più accessi al disco.

L'indice multi-livello aiuta a scomporre l'indice in diversi indici più piccoli al fine di rendere il livello più esterno così piccolo da poter essere salvato in un singolo blocco del disco, che può essere facilmente sistemato ovunque nella memoria principale.

B ⁺ Albero

L' albero AB ⁺ è un albero di ricerca binario bilanciato che segue un formato di indice a più livelli. I nodi foglia di un albero B ⁺ indicano i puntatori ai dati effettivi. L' albero B ⁺ assicura che tutti i nodi fogliari rimangano alla stessa altezza, quindi bilanciati. Inoltre, i nodi foglia vengono collegati utilizzando un elenco di collegamenti; pertanto, un albero B ⁺ può supportare sia l'accesso casuale che l'accesso sequenziale.

Struttura di B ⁺ Albero

Ogni nodo foglia è alla stessa distanza dal nodo radice. L' albero AB ⁺ è nell'ordinen dove nè fisso per ogni albero B ⁺ .

Internal nodes -

I nodi interni (non foglia) contengono almeno puntatori ⌈n / 2⌉, tranne il nodo radice.
Al massimo, un nodo interno può contenere n puntatori.

Leaf nodes -

I nodi foglia contengono almeno puntatori a record ⌈n / 2⌉ e valori chiave ⌈n / 2⌉.
Al massimo, un nodo foglia può contenere n record di puntatori e n valori chiave.
Ogni nodo foglia contiene un puntatore a blocchi P per puntare al nodo foglia successivo e forma un elenco collegato.

B ⁺ Inserimento ad albero

Gli alberi B ⁺ vengono riempiti dal basso e ogni voce viene eseguita sul nodo foglia.
Se un nodo foglia trabocca -
- Dividi il nodo in due parti.
- Partizione in i = ⌊(m+1)_/2⌋.
- Primo i le voci vengono memorizzate in un nodo.
- Il resto delle voci (i + 1 in poi) vengono spostate in un nuovo nodo.
- i^th la chiave è duplicata nel genitore della foglia.
Se un nodo non foglia va in overflow -
- Dividi il nodo in due parti.
- Partiziona il nodo in i = ⌈(m+1)_/2⌉.
- Iscrizioni fino a i sono conservati in un nodo.
- Il resto delle voci viene spostato in un nuovo nodo.

B ⁺ Cancellazione albero

Le voci dell'albero B ⁺ vengono eliminate ai nodi foglia.
La voce di destinazione viene cercata ed eliminata.
- Se si tratta di un nodo interno, eliminare e sostituire con la voce dalla posizione sinistra.
Dopo l'eliminazione, viene testato l'underflow,
- Se si verifica un underflow, distribuire le voci dai nodi lasciati ad esso.
Se la distribuzione non è possibile da sinistra, allora
- Distribuisci dai nodi direttamente ad esso.
Se la distribuzione non è possibile da sinistra o da destra, allora
- Unisci il nodo con sinistra e destra ad esso.

Per una struttura di database enorme, può essere quasi impossibile cercare tutti i valori dell'indice attraverso tutto il suo livello e quindi raggiungere il blocco dati di destinazione per recuperare i dati desiderati. L'hashing è una tecnica efficace per calcolare la posizione diretta di un record di dati sul disco senza utilizzare la struttura dell'indice.

L'hashing utilizza funzioni hash con chiavi di ricerca come parametri per generare l'indirizzo di un record di dati.

Organizzazione hash

Bucket- Un file hash memorizza i dati in formato bucket. Il secchio è considerato un'unità di archiviazione. Un bucket in genere memorizza un blocco disco completo, che a sua volta può memorizzare uno o più record.
Hash Function - Una funzione hash, h, è una funzione di mappatura che mappa tutto l'insieme di chiavi di ricerca Kall'indirizzo in cui sono collocati i record effettivi. È una funzione che va dalle chiavi di ricerca agli indirizzi dei bucket.

Hashing statico

Nell'hashing statico, quando viene fornito un valore di chiave di ricerca, la funzione hash calcola sempre lo stesso indirizzo. Ad esempio, se viene utilizzata la funzione hash mod-4, genererà solo 5 valori. L'indirizzo di uscita deve essere sempre lo stesso per quella funzione. Il numero di secchi forniti rimane sempre invariato.

Operazione

Insertion - Quando è necessario immettere un record utilizzando hash statico, la funzione hash h calcola l'indirizzo del bucket per la chiave di ricerca K, dove verrà archiviato il record.

Indirizzo bucket = h (K)
Search - Quando un record deve essere recuperato, la stessa funzione hash può essere utilizzata per recuperare l'indirizzo del bucket in cui sono archiviati i dati.
Delete - Questa è semplicemente una ricerca seguita da un'operazione di cancellazione.

Benna troppo piena

La condizione di trabocco del secchio è nota come collision. Questo è uno stato fatale per qualsiasi funzione hash statica. In questo caso, è possibile utilizzare il concatenamento di overflow.

Overflow Chaining- Quando i bucket sono pieni, viene allocato un nuovo bucket per lo stesso risultato hash e viene collegato dopo quello precedente. Questo meccanismo è chiamatoClosed Hashing.

Linear Probing- Quando una funzione hash genera un indirizzo in cui sono già archiviati i dati, viene allocato il successivo bucket libero. Questo meccanismo è chiamatoOpen Hashing.

Hashing dinamico

Il problema con l'hashing statico è che non si espande o si restringe dinamicamente man mano che la dimensione del database cresce o si riduce. L'hashing dinamico fornisce un meccanismo in cui i bucket di dati vengono aggiunti e rimossi in modo dinamico e su richiesta. L'hashing dinamico è anche noto comeextended hashing.

La funzione hash, nell'hashing dinamico, è progettata per produrre un gran numero di valori e solo pochi vengono utilizzati inizialmente.

Organizzazione

Il prefisso di un intero valore hash viene considerato come indice hash. Solo una parte del valore hash viene utilizzata per calcolare gli indirizzi dei bucket. Ogni indice hash ha un valore di profondità per indicare quanti bit vengono utilizzati per calcolare una funzione hash. Questi bit possono indirizzare 2n bucket. Quando tutti questi bit sono consumati, ovvero quando tutti i secchi sono pieni, il valore della profondità viene aumentato linearmente e vengono allocati due volte i secchi.

Operazione

Querying - Guarda il valore della profondità dell'indice hash e usa quei bit per calcolare l'indirizzo del bucket.
Update - Eseguire una query come sopra e aggiornare i dati.
Deletion - Eseguire una query per individuare i dati desiderati ed eliminare gli stessi.
Insertion - Calcola l'indirizzo del bucket
- Se il secchio è già pieno.
  - Aggiungi altri secchi.
  - Aggiungi bit aggiuntivi al valore hash.
  - Ricalcola la funzione hash.
- Altro
  - Aggiungi dati al bucket,
- Se tutti i secchi sono pieni, eseguire i rimedi dell'hashing statico.

L'hashing non è favorevole quando i dati sono organizzati in un certo ordine e le query richiedono un intervallo di dati. Quando i dati sono discreti e casuali, l'hash ha le prestazioni migliori.

Gli algoritmi di hash hanno un'elevata complessità rispetto all'indicizzazione. Tutte le operazioni di hash vengono eseguite a tempo costante.

Una transazione può essere definita come un gruppo di attività. Un singolo compito è l'unità di elaborazione minima che non può essere ulteriormente suddivisa.

Facciamo un esempio di una semplice transazione. Supponiamo che un impiegato di banca trasferisca Rs 500 dal conto di A al conto di B. Questa transazione molto semplice e piccola coinvolge diverse attività di basso livello.

A’s Account

Open_Account(A)
Old_Balance = A.balance
New_Balance = Old_Balance - 500
A.balance = New_Balance
Close_Account(A)

B’s Account

Open_Account(B)
Old_Balance = B.balance
New_Balance = Old_Balance + 500
B.balance = New_Balance
Close_Account(B)

Proprietà ACID

Una transazione è un'unità molto piccola di un programma e può contenere diverse attività di basso livello. Una transazione in un sistema di database deve essere mantenutaAtomicità, Consistenza, Isolazione, e Dcapacità, comunemente nota come proprietà ACID, per garantire accuratezza, completezza e integrità dei dati.

Atomicity- Questa proprietà afferma che una transazione deve essere trattata come un'unità atomica, ovvero tutte le sue operazioni vengono eseguite o nessuna. Non ci deve essere stato in un database in cui una transazione viene lasciata parzialmente completata. Gli stati dovrebbero essere definiti prima dell'esecuzione della transazione o dopo l'esecuzione / l'aborto / il fallimento della transazione.
Consistency- Il database deve rimanere in uno stato coerente dopo ogni transazione. Nessuna transazione dovrebbe avere effetti negativi sui dati che risiedono nel database. Se il database era in uno stato coerente prima dell'esecuzione di una transazione, deve rimanere coerente anche dopo l'esecuzione della transazione.
Durability- Il database dovrebbe essere abbastanza resistente da contenere tutti i suoi ultimi aggiornamenti anche se il sistema non riesce o si riavvia. Se una transazione aggiorna un blocco di dati in un database e viene eseguito il commit, il database conterrà i dati modificati. Se una transazione va a buon fine ma il sistema fallisce prima che i dati possano essere scritti sul disco, quei dati verranno aggiornati una volta che il sistema tornerà in azione.
Isolation- In un sistema di database in cui più di una transazione viene eseguita simultaneamente e in parallelo, la proprietà di isolamento afferma che tutte le transazioni saranno eseguite ed eseguite come se fosse l'unica transazione nel sistema. Nessuna transazione influenzerà l'esistenza di qualsiasi altra transazione.

Serializzabilità

Quando più transazioni vengono eseguite dal sistema operativo in un ambiente multiprogrammazione, ci sono possibilità che le istruzioni di una transazione siano interlacciate con qualche altra transazione.

Schedule- Una sequenza cronologica di esecuzione di una transazione è chiamata pianificazione. Una pianificazione può contenere molte transazioni, ciascuna composta da un numero di istruzioni / attività.
Serial Schedule- È una pianificazione in cui le transazioni sono allineate in modo tale che una transazione venga eseguita per prima. Quando la prima transazione completa il suo ciclo, viene eseguita la transazione successiva. Le transazioni vengono ordinate una dopo l'altra. Questo tipo di pianificazione è chiamata pianificazione seriale, poiché le transazioni vengono eseguite in modo seriale.

In un ambiente multi-transazione, le pianificazioni seriali sono considerate un benchmark. La sequenza di esecuzione di un'istruzione in una transazione non può essere modificata, ma due transazioni possono avere le loro istruzioni eseguite in modo casuale. Questa esecuzione non danneggia se due transazioni sono reciprocamente indipendenti e lavorano su segmenti di dati diversi; ma nel caso in cui queste due transazioni stiano lavorando sugli stessi dati, i risultati potrebbero variare. Questo risultato sempre variabile può portare il database a uno stato incoerente.

Per risolvere questo problema, consentiamo l'esecuzione parallela di una pianificazione delle transazioni, se le sue transazioni sono serializzabili o hanno una relazione di equivalenza tra di loro.

Programmi di equivalenza

Un programma di equivalenza può essere dei seguenti tipi:

Equivalenza dei risultati

Se due programmi producono lo stesso risultato dopo l'esecuzione, si dice che sono risultati equivalenti. Possono produrre lo stesso risultato per un valore e risultati diversi per un altro insieme di valori. Ecco perché questa equivalenza non è generalmente considerata significativa.

Visualizza l'equivalenza

Due programmi sarebbero l'equivalenza della vista se le transazioni in entrambi i programmi eseguissero azioni simili in modo simile.

Ad esempio:

Se T legge i dati iniziali in S1, allora legge anche i dati iniziali in S2.
Se T legge il valore scritto da J in S1, allora legge anche il valore scritto da J in S2.
Se T esegue la scrittura finale sul valore dei dati in S1, esegue anche la scrittura finale sul valore dei dati in S2.

Equivalenza in conflitto

Due pianificazioni sarebbero in conflitto se avessero le seguenti proprietà:

Entrambi appartengono a transazioni separate.
Entrambi accedono allo stesso elemento di dati.
Almeno uno di questi è l'operazione di "scrittura".

Due pianificazioni che hanno più transazioni con operazioni in conflitto sono considerate equivalenti in conflitto se e solo se:

Entrambe le pianificazioni contengono lo stesso insieme di transazioni.
L'ordine delle coppie di operazioni in conflitto viene mantenuto in entrambe le pianificazioni.

Note- Le pianificazioni equivalenti di visualizzazione sono serializzabili in visualizzazione e le pianificazioni equivalenti in conflitto sono serializzabili in conflitto. Tutte le pianificazioni serializzabili in conflitto sono anche serializzabili.

Stati delle transazioni

Una transazione in un database può trovarsi in uno dei seguenti stati:

Active- In questo stato, la transazione viene eseguita. Questo è lo stato iniziale di ogni transazione.
Partially Committed - Quando una transazione esegue la sua operazione finale, si dice che sia in uno stato parzialmente confermato.
Failed- Si dice che una transazione è in uno stato fallito se uno qualsiasi dei controlli effettuati dal sistema di ripristino del database fallisce. Una transazione fallita non può più procedere oltre.
Aborted- Se uno qualsiasi dei controlli ha esito negativo e la transazione ha raggiunto uno stato non riuscito, il gestore ripristino ripristina tutte le operazioni di scrittura sul database per riportare il database allo stato originale in cui si trovava prima dell'esecuzione della transazione. Le transazioni in questo stato vengono chiamate interrotte. Il modulo di ripristino del database può selezionare una delle due operazioni dopo che una transazione si interrompe:
- Riavvia la transazione
- Uccidi la transazione
Committed- Se una transazione esegue correttamente tutte le sue operazioni, si dice che sia stata confermata. Tutti i suoi effetti sono ora stabiliti in modo permanente sul sistema di database.

In un ambiente multiprogrammazione in cui è possibile eseguire più transazioni contemporaneamente, è estremamente importante controllare la concorrenza delle transazioni. Disponiamo di protocolli di controllo della concorrenza per garantire atomicità, isolamento e serializzabilità delle transazioni simultanee. I protocolli di controllo della concorrenza possono essere ampiamente suddivisi in due categorie:

Protocolli basati su blocco
Protocolli basati su timestamp

Protocolli basati su blocco

I sistemi di database dotati di protocolli basati sul blocco utilizzano un meccanismo mediante il quale qualsiasi transazione non può leggere o scrivere dati finché non acquisisce un blocco appropriato su di essa. Le serrature sono di due tipi:

Binary Locks- Un blocco su un elemento di dati può essere in due stati; è bloccato o sbloccato.
Shared/exclusive- Questo tipo di meccanismo di chiusura differenzia le serrature in base al loro utilizzo. Se un blocco viene acquisito su un elemento di dati per eseguire un'operazione di scrittura, si tratta di un blocco esclusivo. Consentire a più di una transazione di scrivere sullo stesso elemento di dati porterebbe il database a uno stato incoerente. I blocchi di lettura sono condivisi perché nessun valore dei dati viene modificato.

Sono disponibili quattro tipi di protocolli di blocco:

Protocollo di blocco semplicistico

Semplici protocolli basati sul blocco consentono alle transazioni di ottenere un blocco su ogni oggetto prima che venga eseguita un'operazione di "scrittura". Le transazioni possono sbloccare l'elemento dati dopo aver completato l'operazione di "scrittura".

Pre-rivendicazione del protocollo di blocco

I protocolli di pre-rivendicazione valutano le loro operazioni e creano un elenco di elementi di dati su cui necessitano di blocchi. Prima di iniziare un'esecuzione, la transazione richiede in anticipo al sistema tutti i blocchi di cui ha bisogno. Se vengono concessi tutti i blocchi, la transazione viene eseguita e rilascia tutti i blocchi al termine di tutte le sue operazioni. Se non vengono concessi tutti i blocchi, la transazione viene ripristinata e attende che vengano concessi tutti i blocchi.

Bloccaggio bifase 2PL

Questo protocollo di blocco divide la fase di esecuzione di una transazione in tre parti. Nella prima parte, quando la transazione inizia l'esecuzione, cerca l'autorizzazione per i blocchi che richiede. La seconda parte è dove la transazione acquisisce tutti i blocchi. Non appena la transazione rilascia il suo primo blocco, inizia la terza fase. In questa fase la transazione non può richiedere nuovi lock; rilascia solo le serrature acquisite.

Il bloccaggio bifase ha due fasi, una è growing, dove tutti i blocchi vengono acquisiti dalla transazione; e la seconda fase si sta restringendo, in cui vengono rilasciati i blocchi detenuti dalla transazione.

Per richiedere un blocco esclusivo (in scrittura), una transazione deve prima acquisire un blocco condiviso (in lettura) e quindi aggiornarlo a un blocco esclusivo.

Rigoroso bloccaggio a due fasi

La prima fase di Strict-2PL è la stessa di 2PL. Dopo aver acquisito tutti i blocchi nella prima fase, la transazione continua a essere eseguita normalmente. Ma a differenza di 2PL, Strict-2PL non rilascia un blocco dopo averlo utilizzato. Strict-2PL mantiene tutti i blocchi fino al punto di commit e rilascia tutti i blocchi alla volta.

Strict-2PL non prevede l'interruzione a cascata come fa 2PL.

Protocolli basati su timestamp

Il protocollo di concorrenza più comunemente utilizzato è il protocollo basato sul timestamp. Questo protocollo utilizza l'ora di sistema o il contatore logico come timestamp.

I protocolli basati sul blocco gestiscono l'ordine tra le coppie in conflitto tra le transazioni al momento dell'esecuzione, mentre i protocolli basati sul timestamp iniziano a funzionare non appena viene creata una transazione.

Ad ogni transazione è associato un timestamp e l'ordine è determinato dall'età della transazione. Una transazione creata all'ora dell'orologio 0002 sarebbe più vecchia di tutte le altre transazioni successive. Ad esempio, qualsiasi transazione "y" che entra nel sistema a 0004 è più giovane di due secondi e la priorità sarà data a quella più vecchia.

Inoltre, a ogni elemento di dati viene assegnato il timestamp di lettura e scrittura più recente. Ciò consente al sistema di sapere quando l'ultima operazione di "lettura e scrittura" è stata eseguita sull'elemento di dati.

Timestamp Ordering Protocol

Il protocollo di ordinamento del timestamp garantisce la serializzabilità tra le transazioni nelle operazioni di lettura e scrittura in conflitto. Questa è la responsabilità del sistema di protocollo che la coppia di attività in conflitto deve essere eseguita in base ai valori di timestamp delle transazioni.

Il timestamp della transazione _Ti è indicato come TS ( _Ti ).
Il timestamp di lettura dell'elemento dati X è indicato da R-timestamp (X).
Scrivere il timestamp dell'elemento dati X è indicato da W-timestamp (X).

Il protocollo di ordinazione del timestamp funziona come segue:

If a transaction Ti issues a read(X) operation −

Se TS (Ti) <W-timestamp (X)
- Operazione rifiutata.
Se TS (Ti)> = W-timestamp (X)
- Operazione eseguita.
Tutti i timestamp degli elementi dati aggiornati.

If a transaction Ti issues a write(X) operation −

Se TS (Ti) <R-timestamp (X)

Operazione rifiutata.

Se TS (Ti) <W-timestamp (X)

Operazione rifiutata e Ti annullato.

Altrimenti, operazione eseguita.

Regola di scrittura di Tommaso

Questa regola stabilisce se TS (Ti) <W-timestamp (X), l'operazione viene rifiutata e T _i viene annullato.

Le regole di ordinamento del timestamp possono essere modificate per rendere serializzabile la visualizzazione della pianificazione.

Invece di fare T _i rollback, l'operazione di 'scrittura' stessa viene ignorata.

In un sistema multi-processo, il deadlock è una situazione indesiderata che si verifica in un ambiente di risorse condivise, in cui un processo attende per un tempo indefinito una risorsa che è trattenuta da un altro processo.

Ad esempio, supponiamo un insieme di transazioni {T ₀ , T ₁ , T ₂ , ..., T _n }. T _{0 ha} bisogno di una risorsa X per completare il suo compito. La risorsa X è detenuta da T ₁ e T ₁ è in attesa di una risorsa Y, che è detenuta da T ₂ . T ₂ è in attesa della risorsa Z, che è trattenuta da T ₀ . Pertanto, tutti i processi si attendono a vicenda per rilasciare risorse. In questa situazione, nessuno dei processi può completare il proprio compito. Questa situazione è nota come deadlock.

I deadlock non sono salutari per un sistema. Nel caso in cui un sistema sia bloccato in un deadlock, le transazioni coinvolte nel deadlock vengono annullate o riavviate.

Prevenzione deadlock

Per prevenire qualsiasi situazione di deadlock nel sistema, il DBMS ispeziona in modo aggressivo tutte le operazioni, in cui le transazioni stanno per essere eseguite. Il DBMS ispeziona le operazioni e analizza se possono creare una situazione di deadlock. Se rileva che potrebbe verificarsi una situazione di deadlock, la transazione non potrà mai essere eseguita.

Esistono schemi di prevenzione dei deadlock che utilizzano il meccanismo di ordinamento delle transazioni con timestamp al fine di predeterminare una situazione di deadlock.

Schema di attesa

In questo schema, se una transazione richiede di bloccare una risorsa (elemento di dati), che è già detenuta con un blocco in conflitto da un'altra transazione, può verificarsi una delle due possibilità:

Se TS (T _i ) <TS (T _j ) - cioè _Ti , che richiede un blocco in conflitto, è più vecchio di T _j - allora _Ti è permesso di aspettare fino a quando l'elemento di dati è disponibile.
Se TS (T _i )> TS (t _j ) - cioè _Ti è più giovane di T _j - allora _Ti muore. T _i viene riavviato dopo con un ritardo casuale ma con lo stesso timestamp.

Questo schema consente alla transazione più vecchia di attendere ma uccide quella più giovane.

Schema di attesa della ferita

In questo schema, se una transazione richiede di bloccare una risorsa (elemento di dati), che è già trattenuta con un blocco in conflitto da un'altra transazione, può verificarsi una delle due possibilità:

Se TS (T _i ) <TS (T _j ), allora _Ti costringe T _j ad essere ritirato - cioè _Ti ferisce T _j . T _j viene riavviato successivamente con un ritardo casuale ma con lo stesso timestamp.
Se TS (T _i )> TS (T _j ), allora _Ti è costretto ad aspettare fino a quando la risorsa è disponibile.

Questo schema consente alla transazione più giovane di aspettare; ma quando una transazione più vecchia richiede un elemento detenuto da uno più giovane, la transazione più vecchia costringe quella più giovane ad abortire e rilasciare l'oggetto.

In entrambi i casi, la transazione che entra nel sistema in una fase successiva viene interrotta.

Prevenzione della situazione di stallo

Interrompere una transazione non è sempre un approccio pratico. Invece, i meccanismi di prevenzione dei deadlock possono essere utilizzati per rilevare in anticipo qualsiasi situazione di deadlock. Sono disponibili metodi come "wait-for graph" ma sono adatti solo per quei sistemi in cui le transazioni sono leggere e hanno meno istanze di risorse. In un sistema ingombrante, le tecniche di prevenzione dei deadlock possono funzionare bene.

Aspetta grafico

Questo è un metodo semplice disponibile per tenere traccia di eventuali situazioni di deadlock. Per ogni transazione che entra nel sistema, viene creato un nodo. Quando una transazione _Ti richiede un blocco su un elemento, diciamo X, che è trattenuto da qualche altra transazione T _j , viene creato un arco diretto da _Ti a T _j . Se T _j rilascia l'elemento X, il bordo tra di essi viene eliminato e _Ti blocca l'elemento dati.

Il sistema mantiene questo grafico di attesa per ogni transazione in attesa di alcuni elementi di dati detenuti da altri. Il sistema continua a controllare se è presente un ciclo nel grafico.

Qui, possiamo utilizzare uno dei due seguenti approcci:

In primo luogo, non consentire alcuna richiesta di un elemento, che è già bloccato da un'altra transazione. Ciò non è sempre fattibile e può causare la fame, dove una transazione attende indefinitamente un elemento di dati e non può mai acquisirlo.
La seconda opzione è ripristinare una delle transazioni. Non è sempre possibile ripristinare la transazione più recente, poiché potrebbe essere importante di quella precedente. Con l'aiuto di alcuni algoritmi relativi, viene scelta una transazione, che deve essere interrotta. Questa transazione è nota comevictim e il processo è noto come victim selection.

Perdita di memoria volatile

Una memoria volatile come la RAM memorizza tutti i registri attivi, i buffer del disco e i dati correlati. Inoltre, memorizza tutte le transazioni attualmente in esecuzione. Cosa succede se un archivio così volatile si arresta in modo anomalo? Ovviamente eliminerebbe tutti i log e le copie attive del database. Rende il ripristino quasi impossibile, poiché tutto ciò che è necessario per recuperare i dati viene perso.

Le seguenti tecniche possono essere adottate in caso di perdita di memoria volatile:

Possiamo avere checkpoints in più fasi in modo da salvare periodicamente il contenuto del database.
Uno stato del database attivo nella memoria volatile può essere periodicamente dumped su una memoria stabile, che può anche contenere log, transazioni attive e blocchi di buffer.
<dump> può essere contrassegnato in un file di registro, ogni volta che il contenuto del database viene scaricato da una memoria non volatile a una stabile.

Recupero

Quando il sistema si riprende da un errore, può ripristinare l'ultimo dump.
Può mantenere un elenco di ripristino e un elenco di annullamento come punti di controllo.
Può ripristinare il sistema consultando gli elenchi di annullamento-ripristino per ripristinare lo stato di tutte le transazioni fino all'ultimo checkpoint.

Backup e ripristino del database da errori catastrofici

Un errore catastrofico è quello in cui un dispositivo di archiviazione secondario stabile viene danneggiato. Con il dispositivo di archiviazione, tutti i dati preziosi archiviati all'interno vengono persi. Abbiamo due diverse strategie per recuperare i dati da un guasto così catastrofico:

Backup remoto & minu; Qui una copia di backup del database viene archiviata in una posizione remota da dove può essere ripristinata in caso di catastrofe.
In alternativa, è possibile eseguire backup del database su nastri magnetici e archiviarli in un luogo più sicuro. Questo backup può essere successivamente trasferito su un database appena installato per portarlo al punto di backup.

I database per adulti sono troppo voluminosi per essere sottoposti a backup di frequente. In questi casi, abbiamo tecniche in cui possiamo ripristinare un database semplicemente guardando i suoi log. Quindi, tutto ciò che dobbiamo fare qui è eseguire un backup di tutti i registri a intervalli di tempo frequenti. È possibile eseguire il backup del database una volta alla settimana e il backup dei registri, essendo molto piccolo, può essere eseguito ogni giorno o il più frequentemente possibile.

Backup remoto

Il backup remoto fornisce un senso di sicurezza nel caso in cui la posizione principale in cui si trova il database venga distrutta. Il backup remoto può essere offline, in tempo reale o online. Nel caso in cui sia offline, viene mantenuto manualmente.

I sistemi di backup in linea sono più in tempo reale e salvavita per gli amministratori di database e gli investitori. Un sistema di backup online è un meccanismo in cui viene eseguito il backup di ogni bit dei dati in tempo reale simultaneamente in due luoghi distanti. Uno di questi è direttamente connesso al sistema e l'altro è conservato in un luogo remoto come backup.

Non appena l'archiviazione del database principale si guasta, il sistema di backup rileva l'errore e passa il sistema utente all'archivio remoto. A volte questo è così istantaneo che gli utenti non possono nemmeno rendersi conto di un fallimento.

Crash Recovery

DBMS è un sistema altamente complesso con centinaia di transazioni eseguite ogni secondo. La durata e la robustezza di un DBMS dipendono dalla sua architettura complessa e dal suo hardware e software di sistema sottostante. Se fallisce o si arresta in modo anomalo durante le transazioni, ci si aspetta che il sistema segua una sorta di algoritmo o tecniche per recuperare i dati persi.

Classificazione dei guasti

Per vedere dove si è verificato il problema, generalizziamo un errore in varie categorie, come segue:

Transazione fallita

Una transazione deve interrompersi quando non viene eseguita o quando raggiunge un punto da cui non può andare oltre. Questo è chiamato errore di transazione in cui solo poche transazioni o processi sono danneggiati.

I motivi di un errore di transazione potrebbero essere:

Logical errors - Quando una transazione non può essere completata perché presenta un errore di codice o una condizione di errore interno.
System errors- Dove il sistema di database stesso termina una transazione attiva perché il DBMS non è in grado di eseguirla o deve fermarsi a causa di alcune condizioni del sistema. Ad esempio, in caso di deadlock o indisponibilità delle risorse, il sistema interrompe una transazione attiva.

Crash di sistema

Ci sono problemi, esterni al sistema, che possono causare l'arresto improvviso del sistema e causare l'arresto anomalo del sistema. Ad esempio, le interruzioni dell'alimentazione possono causare il guasto dell'hardware o del software sottostante.

Gli esempi possono includere errori del sistema operativo.

Errore del disco

Agli albori dell'evoluzione tecnologica, era un problema comune in cui le unità disco rigido o le unità di archiviazione si guastano frequentemente.

I guasti del disco includono la formazione di settori danneggiati, l'irraggiungibilità del disco, l'arresto anomalo della testina del disco o qualsiasi altro guasto, che distrugge tutto o parte della memoria del disco.

Struttura di stoccaggio

Abbiamo già descritto il sistema di archiviazione. In breve, la struttura di stoccaggio può essere suddivisa in due categorie:

Volatile storage- Come suggerisce il nome, una memoria volatile non può sopravvivere ai crash di sistema. I dispositivi di archiviazione volatile sono posizionati molto vicino alla CPU; normalmente sono incorporati nel chipset stesso. Ad esempio, la memoria principale e la memoria cache sono esempi di archiviazione volatile. Sono veloci ma possono memorizzare solo una piccola quantità di informazioni.
Non-volatile storage- Questi ricordi sono fatti per sopravvivere ai crash del sistema. Sono enormi nella capacità di archiviazione dei dati, ma più lenti nell'accessibilità. Gli esempi possono includere dischi rigidi, nastri magnetici, memoria flash e RAM non volatile (con backup della batteria).

Recupero e atomicità

Quando un sistema si arresta in modo anomalo, possono essere eseguite diverse transazioni e vari file aperti per modificare gli elementi di dati. Le transazioni sono fatte di varie operazioni, che sono di natura atomica. Ma in base alle proprietà ACID del DBMS, l'atomicità delle transazioni nel suo insieme deve essere mantenuta, ovvero tutte le operazioni vengono eseguite o nessuna.

Quando un DBMS si riprende da un arresto anomalo, dovrebbe mantenere quanto segue:

Dovrebbe controllare lo stato di tutte le transazioni che erano in esecuzione.
Una transazione potrebbe essere nel mezzo di un'operazione; il DBMS deve garantire l'atomicità della transazione in questo caso.
Dovrebbe verificare se la transazione può essere completata ora o se deve essere annullata.
A nessuna transazione sarebbe consentito lasciare il DBMS in uno stato incoerente.

Esistono due tipi di tecniche che possono aiutare un DBMS a recuperare e mantenere l'atomicità di una transazione:

Mantenere i log di ogni transazione e scriverli su una memoria stabile prima di modificare effettivamente il database.
Mantenendo lo shadow paging, dove le modifiche vengono eseguite su una memoria volatile, e successivamente, il database effettivo viene aggiornato.

Ripristino basato su log

Il registro è una sequenza di record, che conserva i record delle azioni eseguite da una transazione. È importante che i registri vengano scritti prima dell'effettiva modifica e archiviati su un supporto di memorizzazione stabile, a prova di errore.

Il ripristino basato su log funziona come segue:

Il file di registro viene conservato su un supporto di memorizzazione stabile.
Quando una transazione entra nel sistema e inizia l'esecuzione, scrive un log su di essa.

<T_n, Start>

Quando la transazione modifica un elemento X, scrive i log come segue:

<T_n, X, V₁, V₂>

Si legge che T _n ha cambiato il valore di X, da V ₁ a V ₂ .

Al termine della transazione, registra -

<T_n, commit>

Il database può essere modificato utilizzando due approcci:

Deferred database modification - Tutti i log vengono scritti nella memoria stabile e il database viene aggiornato quando viene eseguito il commit di una transazione.
Immediate database modification- Ogni registro segue un'effettiva modifica del database. Cioè, il database viene modificato immediatamente dopo ogni operazione.

Recupero con transazioni simultanee

Quando più di una transazione viene eseguita in parallelo, i log vengono intercalati. Al momento del ripristino, sarebbe diventato difficile per il sistema di ripristino eseguire il backtrack di tutti i registri e quindi avviare il ripristino. Per facilitare questa situazione, la maggior parte dei moderni DBMS utilizza il concetto di "checkpoint".

Checkpoint

La conservazione e la gestione dei log in tempo reale e in un ambiente reale può riempire tutto lo spazio di memoria disponibile nel sistema. Con il passare del tempo, il file di registro potrebbe diventare troppo grande per essere gestito. Checkpoint è un meccanismo in cui tutti i registri precedenti vengono rimossi dal sistema e archiviati in modo permanente in un disco di archiviazione. Checkpoint dichiara un punto prima del quale il DBMS era in uno stato coerente e tutte le transazioni sono state salvate.

Recupero

Quando un sistema con transazioni simultanee si arresta in modo anomalo e si ripristina, si comporta nel modo seguente:

Il sistema di ripristino legge i log all'indietro dalla fine all'ultimo checkpoint.
Mantiene due elenchi, un elenco di annullamento e un elenco di ripristino.
Se il sistema di ripristino vede un log con <T _n , Start> e <T _n , Commit> o semplicemente <T _n , Commit>, inserisce la transazione nell'elenco redo.
Se il sistema di ripristino vede un log con <T _n , Start> ma non è stato trovato alcun log di commit o interruzione, inserisce la transazione nell'elenco di annullamento.

Tutte le transazioni nell'elenco di annullamento vengono quindi annullate ei relativi registri vengono rimossi. Tutte le transazioni nell'elenco di ripristino e i relativi registri precedenti vengono rimossi e quindi ripristinati prima di salvare i registri.