storia dei DBMS - "PARTHENOPE"

Storia dell’Informatica e del Calcolo Automatico
Prof.ssa F. Perla
La storia dei DBMS e dei modelli di
progettazione dei DATABASE
Realizzato da:
Claudio PETRONE
Amedeo MADDALUNO
Pasquale TESSITORE
…la preistoria dei DB
Probabilmente il più glorioso (ed a tutt'oggi
utilizzato) antenato dei database relazionali
odierni può essere identificato con la vecchia e
utilissima agenda.
In effetti se ne studiamo la struttura
scopriamo una notevole affinità con le
sue attuali implementazioni
tecnologiche attuali.
…ma come è fatta un’agenda?
Un’agenda è organizzata tramite un indice ( linguette sul
fianco che ci permettono di accedere più rapidamente a tutte
le informazioni segnalate dalla linguetta) che gestisce una
tabella composta da colonne che identificano il tipo di dato
riportato (nome, numero di telefono, indirizzo)
Le registrazioni, pur differendo l'una dall'altra per i dati
riportati al loro interno, "hanno tutti la stessa struttura", cioè
riportano le stesse informazioni nella medesima maniera.
Implementazioni tecnologiche - CSV
Il primo tentativo compiuto dagli informatici per
trasformare questo tipo di oggetti in un “qualcosa"
trattabile dal punto di vista elettronico corrisponde al
nome di CSV (Comma Separated Value)
I dati in formato testo - CSV
Cioè un banalissimo file di testo dove ogni informazione è
separata dalle altre tramite un carattere particolare
(normalmente una virgola) ed ogni record è separato dagli
altri tramite un altro carattere (normalmente il carattere di
"a capo").
Il CSV
Questo sistema era decisamente
semplicistico, in quanto
comunque per trovare all' interno
di un file del genere una
informazione specifica era
necessario scorrerlo, un modo
poco pratico, per trovare quanto
si ricercava.
CVS - ISAM
La logica evoluzione del CSV fu
l'ISAM (Indexed Sequential Access
Method), che differiva dal CSV solo
per il fatto che veniva definito un
ordinamento, tipicamente nel caso
dell’agenda l'ordine alfabetico sui
cognomi
CVS- ISAM
Tale ordinamento veniva sfruttato sia in scrittura ("dove
inserire il record del numero di telefono?") sia in lettura ("dove
recuperare il numero di telefono ?") permettendo in questo
modo di abbreviare incredibilmente i tempi di ricerca di
una data informazione.
Nuove implementazioni del CVS- ISAM
Per riuscire poi a gestire ancora meglio il tutto si
crearono anche delle specie di "archivi sussidiari", detti indici,
in cui veniva registrato solo l'ordine dei vari record senza
tutte le altre informazioni, il che permetteva di andare a
svolgere le proprie ricerche in questo "riassunto" in modo
molto più veloce e "puntare diritti" sul database completo per
leggere tutto il record una volta che si sapeva dov'era.
…ma si può essere più veloci?
A questo punto parecchi matematici si posero un problema:
“ se i database sono importanti, lo saranno ancora di più se
l’accesso alle informazioni sarà veloce”
Iniziano gli studi sui sistemi di ricerca;
ne naquero diversi dai nomi fantasiosi come "ricerca
dicotomica" o "a farfalla”.
primi studi…
Si sono sviluppati così tutti quei sistemi oggi definiti
"Database non relazionali" (in contrapposizione ai
database relazionali che vedremo dopo) di cui forse i
più famosi sono stati i database B-Trieve e DBIII-like
(clipper, DBIII, DBIV ecc)
…primi studi
Con l'evoluzione di questi ultimi, i database ebbero una
notevole diffusione e quindi iniziarono a nascere richieste
di affidabilità e di prestazioni sempre maggiori, con uno
sviluppo teorico notevole che li sostenesse.
L’evoluzione dei DB (1)
Inizio anni ’60: Charles Bachman (Eletric) progetta il primo
DBMS (Integrated Data Store), basato sul
modello reticolare. Bachman vincerà il primo
ACM Turing Award nel 1973.
Fine anni ’60: l’IBM sviluppa l’Information Management
System (IMS), basato sul modello gerarchico ancora
usato tutt’oggi.
1970: Edgar Codd (IBM) propone il modello relazionale.
Questi studi gli permetteranno di vincere l’ACM Turing 1981.
L’evoluzione dei DB (2)
Anni ’80: il modello relazionale vince su altri, e si diffondono
i DBMS basati su di esso. Il linguaggio SQL viene
standardizzato come linguaggio per DBMS basati sul modello
relazionale.
Anni ’90: sulla spinta di intense ricerche, i DBMS relazionali
divengono sempre più sofisticati e diffusi (DB2, Oracle,
Informix).
Nel 1999 James Gray vince l’ACM Turing Award per il suo
contributo alla gestione delle transazioni.
Inizio anni 60…
I calcolatori diventano strumento indispensabile per le
aziende sia pubbliche che private data la possibilità di
immagazzinare un’enorme quantità di dati.
Vengono così sviluppati due modelli di database:
Modello della rete (Codasyl) e gerarchico (IMS).
…inizio anni 60
Charles W. Bachman, che ha realizzato negli anni ‘60 per
General Electric il primo vero DBMS della storia ("IDS"),
fondò il "Database Task Group", all'interno del
"Codasyl“ (Conference on data system languages), il
gruppo di lavoro dedicato alla creazione e
standardizzazione del linguaggio di programmazione
COBOL.
Database Relazionali
Negli anni 70:Database Relazionali (1)
Edgar Codd, dipendente della sede californiana
della IBM, in quel periodo era un ricercatore
sulla nascente tecnologia degli hard disk
I sui studi lo portarono ad osservare
l'inefficienza dell'approccio Codasyl con la
nuova modalità di memorizzazione dei dati,
inefficienza dovuta principalmente all'assenza
di una funzione di ricerca.
Negli anni 70: Database Relazionali (2)
Nel 1970 Codd cominciò a produrre diversi documenti
schematizzanti un nuovo approccio alla costruzione delle basi
di dati, culminati nel famoso articolo intitolato:
"Modello relazionale per Basi di dati condivise“
("A Relational Model of Data for Large Shared Data Banks").
In questo articolo, descrisse un nuovo sistema per archiviare e
modificare grandi quantità di dati. Invece di utilizzare delle "righe"
collegate tra di loro attraverso un qualche tipo di struttura "ad
albero", come in Codasyl, ritenne di utilizzare una "tabella" di righe a
lunghezza fissa.
Questo sistema sarebbe stato molto inefficiente nell'archiviazione di
dati "sparsi", in cui la tabella avrebbe potuto avere diverse "celle"
vuote; tale errore di impostazione fu corretto dividendo i dati in
diverse tabelle, in cui gli elementi opzionali venivano spostati,
anziché sprecare spazio nella tabella principale.
Ad esempio, un utilizzo comune delle basi di dati è quello di
registrare delle informazioni sugli utenti: il loro nome, informazioni
di accesso, indirizzo e numeri di telefono.
• In un database tradizionale tutti questi dati sarebbero stati
memorizzati in un unico "record", e gli elementi non presenti (ad
esempio un utente di cui non sia noto l'indirizzo) sarebbero stati
semplicemente omessi.
• Al contrario, in un database relazionale, le informazioni sono state
divise, ad esempio, nelle tabelle "utente", "indirizzi", "numeri di
telefono": solo se i dati sono presenti viene creata, nella rispettiva
tabella.
La soluzione del sistema sta nel collegamento delle tabelle.
Nel modello relazionale, per ogni record viene definita una "chiave",
ovvero un identificatore univoco della riga. Nella ricostruzione delle
relazioni, l'elemento di riferimento, che distingue una riga da un'altra
è proprio questa "chiave" che viene richiamata nella definizione della
relazione.
La chiave può essere uno dei dati stessi che vengono memorizzati
(ad esempio, per la tabella utenti, il "Codice Fiscale" della persona), o
un campo che viene aggiunto specificatamente per questo scopo
(spesso chiamato "OID" - "Object IDentifier").
Questa operazione di "riunificazione" dei dati non è prevista nei
linguaggi di programmazione tradizionali; mentre l'approccio
tradizionale richiede semplicemente di "ciclare" per raccogliere i
diversi record, l'approccio relazionale richiede al programma di
"ciclare" per raccogliere le informazioni riguardanti ogni record.
Codd, propose, come soluzione, la creazione di un linguaggio
dedicato a questo problema, un linguaggio che, più tardi, si sarebbe
sviluppato nella codifica che oggi è utilizzata universalmente e che
rappresenta il perno fondamentale delle basi di dati:
SQL
Utilizzando una teoria matematica chiamata "calcolo delle tuple",
dimostrò che questo sistema era in grado di compiere tutte le
normali operazione di amministrazione dei database (inserimento,
cancellazione, etc.) e che inoltre consentiva di disporre di uno
strumento semplice per trovare e visualizzare gruppi di dati
tramite un'unica operazione.
System R
LA IBM cominciò a
implementare questa
teoria in alcuni
prototipi all'inizio degli
Anni '70, come nel
"System R".
System R
La prima versione fu realizzata nel 1974/75 con uno
strumento "monotabella";
negli anni successivi furono studiati i primi sistemi che
potessero supportare la suddivisione dei dati in tabelle
separate, utile per la separazione dei dati opzionali in tabelle
diverse da quella principale.
Versioni multiutente del System R
Versioni "multiutente" furono realizzate nel 1978 e nel 1979;
negli stessi anni fu standardizzato il linguaggio SQL.
La superiorità di questo sistema rispetto a Codasyl fu
quindi evidente e la IBM passò a sviluppare una versione
commerciale di "System R", che prese il nome di "SQL/DS"
prima e di "Database 2" (DB2) dopo.
Il lavoro di Codd, venne proseguito presso l‘Università
di Berkeley da:
Eugene Wong
e Michael Stonebraker.
INGRES
Il loro progetto, chiamato INGRES (Interactive Graphics
and Retrieval System) e finanziato tramite fondi destinati
alla creazione di un database geografico, vide la luce nel
1973 e produsse i primi risultati nel 1974 anche grazie
all'opera di numerosi studenti che prestarono la loro opera
quali programmatori
INGRES
INGRES era assai simile a "System R" e prevedeva un linguaggio
alternativo a SQL, chiamato QUEL.
Molte delle persone coinvolte nel progetto si convinsero della
fattibilità commerciale dello stesso e fondarono imprese per
entrare nel mercato con questo prodotto:
Sybase, Informix, NonStop SQL e alla fine la stessa Ingres,
naquero quali "spin-off" per la diffusione di INGRES all'inizio
degli Anni '80.
Perfino Microsoft SQL Server è, per certi versi, una
derivazione di "Sybase" e, quindi, di INGRES.
Solamente la Oracle di Larry Ellison partì utilizzando un
approccio diverso, basato sul "System R" della IBM, e alla
fine prevalse sulle altre compagnie con il suo prodotto,
lanciato nel 1978.
Sviluppi del lavoro di Codd
Il lavoro di Codd venne continuato nella Università di
Uppsala (in Svezia) dove fu sviluppato un prodotto,
Mimer SQL, commercializzato nel 1984.
Il Mimer SQL introduce per la prima volta il concetto di
transazione, successivamente importato in quasi tutti i
DBMS.
Database ad oggetti
Database ad oggetti
A partire dai primi anni ‘90, cominciano a diffondersi i
database a oggetti (ODBMS).
Nel modello dei dati a oggetti le entità del dominio vengono
modellate con oggetti e relazioni fra oggetti.
Un ODBMS offre le funzioni necessarie a rendere persistenti
collezioni di oggetti e le relazioni fra di loro.
La naturalezza nel rappresentare dati complessi e l'abilità ad
accedervi in modo efficiente è il principale punto a favore di
un ODBMS rispetto a un RDBMS.
Database ad oggetti
A differenza del modello relazionale, nel modello a oggetti gli
attributi di un oggetto possono essere di qualunque tipo: in
particolare, un oggetto può contenere altri oggetti.
Inoltre l'ODBMS può essere istruito per privilegiare gli accessi
a gruppi (cluster) di oggetti eterogenei, in modo che il
caricamento di un oggetto con tutte le sue componenti si
svolga in un'operazione unica di accesso al disco; questa stessa
operazione nei RDBMS deve essere eseguita tramite una o più
JOIN, che è una delle operazioni più costose di un RDBMS
Database ad oggetti
Pensiamo, per esempio, a come rappresentare il contorno di
una figura CAD in un RDBMS. Un contorno è una sequenza di
punti. Il modello dati relazionale non permette di definire un
nuovo tipo elementare "punto".
Il progettista del DB relazionale dovrà quindi usare un'unica
tabella con quattro colonne per contenere tutti i punti del
sistema.
Due colonne servono per mantenere le coordinate; una
contiene l'identificativo del contorno cui appartiene il punto, la
quarta il numero di sequenza del punto nel contorno.
Database ad oggetti
Per estrarre dal DB un contorno, prima bisogna estrarre dalla
relazione tutti i punti (presumibilmente alcuni milioni) quelli
che corrispondono al contorno che stiamo cercando, quindi
ordinarli secondo il numero di sequenza, infine trasferire il
risultato in un formato manipolabile nell'ambiente di
programmazione:
tipicamente un vettore dinamico di oggetti Point.
Altrettanto laboriosa sarà l'operazione inversa. La
macchinosità e l'inefficienza di tutto ciò sono tali da
sconsigliarlo in qualsiasi CAD reale.
Database ad oggetti
Un database a oggetti non solo può rappresentare direttamente la
sequenza ordinata dei punti, senza trasformarla in tabella, ma
può essere istruito a mettere i punti sulla stessa pagina di disco
su cui si trova la figura geometrica cui si riferiscono.
Tutti gli ODBMS prevedono un modo perché un'applicazione
possa dare questi "suggerimenti" al run-time del database, anche
se non esiste un modo standard;
un meccanismo tipico è di passare dalla costruzione di un
oggetto il riferimento a un altro oggetto già sul database, con
l’indicazione che i due devono stare possibilmente vicini.
Database ad oggetti
La prima differenza che salta agli occhi fra il mondo dei database a
oggetti e quello relazionale è la mancanza di interoperabilità. A un
database a oggetti si può accedere solo passando per il DBMS che lo
gestisce: per esempio, a un database ObjectStore può accedere solo un
programma scritto per ObjectStore e non, per esempio, per
Objectivity/DB; inoltre, anche se la maggior parte dei database a
oggetti sono supportati su una molteplicità di piattaforme (p.e. Win32,
Sun, HP, eccetera), non tutti sono realmente multipiattaforma, cioè
non permettono a un cliente su Windows di accedere a un database su
server Unix
Object Database Management Group
Per superare questo limite, che rappresenta il più grande difetto degli
ODBMS rispetto ai relazionali e, quindi, l'ostacolo maggiore alla loro
diffusione, è nato:
ODMG (Object Database Management Group)
un consorzio di costruttori di ODBMS.
Il suo fine è definire :
● un linguaggio astratto per la definizione dello schema del database
(ODL: Object Definition Language),
● un linguaggio standard per le interrogazioni sul database (OQL : Object
Query Language)
● il mapping di questi linguaggi astratti sui linguaggi di programmazione
reali.
Database a oggetti relazionali
Oggi molti DBMS applicano in realtà un misto tra il
modello relazionale e il modello a oggetti.
Si parla quindi di ORDBMS (Object Relational DBMS).
Evoluzione dei database a oggetti
• Gestione e memorizzazione delle immagini, audio e
video, MMDB
•
Data Warehouses
•
Sistemi informativi geografici (GIS) e analisi spaziali
Data WareHousing
Le potenzialità delle basi di dati si sono concretizzate, nel corso degli
anni, in tools quasi sorprendenti, rispetto agli usi di pochi anni fa, in
grado di maneggiare “informazione” come un qualsiasi altro bene
aziendale. Se negli anni settanta i database avevano in prevalenza un
ruolo di storage, oggi manager aziendali interrogano quotidianamente
il proprio Decision Support System per aiutarsi nelle scelte quotidiane.
Il processo attraverso il quale, a partire da dati operazionali, è possibile
ottenere informazioni che aiutino i manager nelle analisi dei dati
prende il nome di “Data
warehousing” (magazzino di dati).
Data WareHousing
Un data Warehousing in ambito aziendale fa parte di un
sistema informativo la cui materia prima da processare è:
l’informazione.
I suoi obiettivi sono:
• la gestione storica dei dati
• la facilità di accesso alle informazioni attraverso una
visione multidimensionale dei dati
• la capacità di fare ipotesi sul futuro
E’ realizzato attraverso un processo basato sulla
riorganizzazione dei dati esistenti in un DBMS.
GIS
Un Sistema Informativo Geografico (Geographical
Information System, GIS) è un sistema informativo
computerizzato che permette l'acquisizione, la registrazione,
l'analisi, la visualizzazione e la restituzione di informazioni
derivanti da dati geografici (geo-referenziati).
Il GIS è una forma di DBMS capace di gestire le posizioni
degli “elementi” sul territorio, che si integra con delle
componenti software di interrogazione e visualizzazione.
GIS
Per la rappresentazione dei dati in un sistema informatico
occorre formalizzare un modello rappresentativo
flessibile che si adatti ai fenomeni reali.
Nel GIS abbiamo tre tipologie di informazioni:
● geometriche: relative alla rappresentazione cartografica
degli oggetti rappresentati; quali la forma (punto, linea
poligono), la dimensione e la posizione geografica;
● topologiche: riferite alle relazioni reciproche tra gli
oggetti (connessione, adiacenza, inclusione ecc…);
● informative: riguardanti i dati (numerici, testuali ecc…)
associati ad ogni oggetto.
GIS
Il GIS prevede la gestione di queste informazioni in un
database relazionale.
L'aspetto che caratterizza il GIS è quello geometrico:
esso memorizza la posizione del dato impiegando un
sistema di proiezione reale che definisce la posizione
geografica dell'oggetto.
DBMS multimediali
I DBMS multimediali (MMDB) sono sistemi che permettono di
memorizzare e recuperare oggetti costituiti da testo, immagini, suoni,
animazioni, voce, video, ecc.
I MMDB presentano problematiche diverse rispetto ai DBMS
tradizionali:
• Dimensioni del DB (molto) maggiori
• Gestione di media continui (video, audio)
• Complessità di modellazione degli oggetti multimediali
• Ricerche non necessariamente “esatte”
DBMS multimediali
Settori applicativi:
•
•
•
•
•
DB medici (TAC, RX)
DB scientifici (spectral analysis, molecolari)
DB legali (fingerprints, mugshots, copy detection)
Publishing (electronic newspaper)
Fashion
DBMS multimediali
Benché a tutt’oggi non esista un modello standard per la descrizione
dei MMDB, è opinione comune che tutte le applicazioni non banali
debbano considerare una rappresentazione su (almeno) 4 livelli:
• Raw Data: descrive i dati multimediali veri e propri,
indipendentemente dal loro contenuto. Questo livello è rilevante per
gli aspetti di memorizzazione, ma non di ricerca.
• Objects Description: a questo livello sono definiti gli “oggetti”
multimediale di interesse (es: parti di immagini, elementi di testo).
DBMS multimediali
• Features (caratteristiche): le feature di un oggetto MM ne descrivono
il contenuto in termini di grandezze misurabili (es: colore di
un’immagine, spettro di un suono, ecc.)
• Concepts: il livello dei concetti usa una rappresentazione semantica
del dominio di interesse (background/domain knowledge) per interpretare
il contenuto degli oggetti multimediali
Ricerca in un MMDB
Ricerca in un MMDB:
su campi “classici”
● su campi strutturali
● su feature
● concettuali
● su relazioni spazio-temporali
●
Schema riassuntivo
Modelli di
DBMS
a oggetti
relazionale a oggetti
relazionale
reticolare
gerarchico
x
1960
x
1970
x
1980
x
x
1990
2000
Tempo
DB2
DB2 è un DBMS prodotto da IBM. La sua prima versione risale al 1983
e, secondo molti, è stato il primo prodotto ad utilizzare il linguaggio
SQL.
Inizialmente era un DBMS per i mainframe, ma oggi è diffuso su
qualsiasi tipo di server, perfino su PDA e altri dispositivi portatili;
esistono versioni per GNU Linux, Unix (AIX, HP-UX, Solaris) e MS
Windows.
I suoi precursori sono DL/1 e IMS/DB, sempre della IBM.
DB2
Quando Informix acquistò Illustra e introdusse nel proprio
database Universal Server, facendone un DBMS relazionale
a oggetti, sia Oracle che IBM dovettero introdurre il concetto
di oggetti nei proprio prodotti.
Pertanto DB2 è diventato un DBMS relazionale a oggetti.
Attualmente, DB2 e Oracle si contendono il primo posto nel
mercato dei DBMS.
Cachè
Caché è un DBMS proprietario prodotto da InterSystems.
InterSystems usa il termine "post-relazionale" per descriverne le
caratteristiche.
Caché fornisce accesso tramite SQL, Object e in maniera multidimensionale agli stessi dati.
Esistono versioni di Caché sia per Windows, sia per diverse
versioni di Unix e distribuzioni di Linux, sia per le piattaforme
OpenVMS.
Cachè
La memorizzazione dei dati in Caché avviene utilizzando i b-tree basati
su array multidimensionali (conosciutti anche con il nome di MUMPS
globals, sebbene InterSystems preferisca non utilizzare questo termine).
Cachè fornisce i linguaggi di sviluppo
• Caché ObjectScript
• Caché Basic
per facilitare il programmatore alla creazione e lo sviluppo di
applicazioni che interagiscono con il DBMS stesso.
Cachè
Fornisce inoltre interfacce esterne che permettono il Native Object
Binding con diversi linguaggi di programmazione quali C++, Java, EJB,
ActiveX.
Gli accessi relazionali mediante JDBC e ODBC sono implementati
tramite Direct Interface e risultano essere molto performanti.
Inoltre sono supportati anche accessi mediante XML e Web Services.
Cachè
I principali clienti e utilizzatori di Caché sono i grandi ospedali
degli USA, che lo usano per la memorizzazione elettronica dei
dati dei pazienti, e istituzioni finanziarie come Ameritrade.
I principali concorrenti di Caché sono DB2 di IBM, MS-SQL di
Microsoft e Oracle.
Cachè
Rispetto agli altri sistemi relazionali, per quanto riguarda applicazioni
simili, Caché può fornire spesso un rendimento più elevato (o a parità
di risorse hardware può sostenere un numero maggiore di utenti).
Questo vantaggio in performance viene pagato, sempre nel confronto
con altri sistemi relazionali, da una perdita di flessibilità; ne risulta la
necessità
di
una
formazione
specifica
per
il
personale
con
aggiornamenti diversi dallo standard attuale dei database e delle
versioni chiuse del programma, associate a degli specifici strumenti di
sviluppo, disponibili presso un solo venditore.
FileMaker Pro
FileMaker Pro è un database multi-piattaforma sviluppato da
FileMaker Inc.
E’ stato uno dei primi database presentati per Apple Macintosh
all'inizio degli anni ottanta.
E’ un database che combina potenza e facilità d'uso.
È anche conosciuto per la stretta integrazione del database con
l'interfaccia grafica. Ad esempio, per modificare un database, basta
prelevare un elemento e trascinarlo in un layout/schermo o form. Il
motore automaticamente rileverà il nuovo elemento e provvederà a
tenerne conto durante le interrogazioni.
FileMaker Pro
Il programma non si basa sulla filosofia della programmazione
orientata agli oggetti, anche se ne mutua molte caratteristiche, infatti
viene definito un ambiente di sviluppo "quasi-object" in cui la base
dello sviluppo è la manipolazione di entità chiamate oggetti, ma il
database non supporta molte delle caratteristiche avanzate previste
della programmazione a oggetti.
Questa peculiare gestione dei dati lo rende un prodotto unico e, sotto
molti punti di vista, lo rende difficile da confrontare con i prodotti
concorrenti, dato che questi sono basati su paradigmi diversi.
FileMaker Pro
E’ disponibile sia per la piattaforma Macintosh, sia per la
piattaforma Windows ed è in grado di utilizzare una rete locale
mista (composta da computer Macintosh e Windows).
E’ un prodotto scalabile, è disponibile una versione per le
postazioni degli utenti, per i server e esiste una versione in grado
di interfacciarsi a siti web e a dispositivi mobili.
Informix
Nel 1980, Roger Sippl e Laura King hanno fondato la società
Relational Database Systems (RDS).
Il loro primo prodotto, Marathon, è stato rilasciato su Onyx, una
versione di Unix per i primi microprocessori ZiLOG.
In RDS, Sippl and King hanno posto la loro attenzione al mercato
dell’emergente SQL e hanno adattato una versione del codice sorgente,
pubblicamente disponibile, di Inges alla piattaforma Unix.
Informix
La disponibilità di un codice ben collaudato ha permesso alla RDS di
rilasciare, nel 1981, la sua prima versione di Informix. Essa
comprendeva alcuni cambiamenti fondamentali rispetto al sistema
Ingres, in particolare:
• un adattamento del linguaggio di query QUEL nel suo linguaggio
Informer,
• un tool per la scrittura di report (ACE), usato per estrarre dati dal
database e presentarli all’utente in un formato semplice,
• uno strumento per interrogare ed editare interattivamente i dati
nel database (PERFORM).
Informix
La versione finale di questo prodotto, realizzata all’inizio del 1986, è
stata la 3.30.
Nel 1985, con l’introduzione di un nuovo motore basato su query SQL,
è nato INFORMIX-SQL versione 1.10 (la versione 1.00 non è stata mai
rilasciata). Tale prodotto comprendeva anche le varianti SQL di ACE e
PERFORM.
Verso la metà degli anni ’80, grazie alla crescita della popolarità di
Unix e di SQL, RDS è diventata una società di successo ed ha cambiato
il suo nome in Informix Software.
Informix
I prodotti INFORMIX-SQL versione 2.00 e INFORMIX-4GL 1.00
comprendevano sia il motore del database, sia i tool di sviluppo (I4GL
per i programmatori, ISQL per i non-programmatori).
Nel 1989, con il rilascio della versione 9.00, il motore è stato separato
dai tool I4GL e ISQL ed ha preso il nome di Informix-SE (Standard
Engine).
Nello stesso anno è nato un nuovo motore, denominato inizialmente
Informix Turbo e successivamente Informix OnLine. La versione 5.00
di Informix OnLine è stata rilasciata alla fine del 1990.
Informix
Dopo una breve e disastrosa parentesi nel campo dell’office
automation, nel 1994 Informix Software è ritornata al mercato sempre
crescente dei database server e, in collaborazione con Sequent
Computer Systems, ha rilasciato la versione 6.00 di Informix OnLine
Dynamic Server.
La versione 7.00, nello stesso anno, ha riscosso un enorme successo e
ha fatto sì che Informix diventasse il secondo database al mondo,
scavalcando Sybase.
Informix
Nel 1995 Informix ha acquistato Illustra (scritto dagli ex membri
del team di Postgres) ed ha concentrato i suoi studi sui database
relazionali ad oggetti. E’ nato, così, Informix Universal Server.
Nel 1996 la versione 8.00 e la versione 9.00 di Informix Universal
Server hanno reso Infomix la più importante fra le società
operanti nel campo dei DB relazionali ad oggetti.
Informix
Nel 1997 una leadership sfortunata e una cattiva amministrazione
hanno offuscato i successi di Informix. Il 1° aprile 1997 Informix ha
annunciato che il reddito era stato inferiore alle aspettative di 100
milioni di dollari.
Nel marzo del 2000, Informix ha acquistato Ardent Software. Questo
ha portato alla realizzazione di motori multi-dimensionali, quali
UniVerse e UniData.
UniData
Nel 2001, IBM ha acquistato da Informix la tecnologia dei DB, il
marchio, i progetti futuri e i 100.000 clienti associati.
Informix
Nel novembre del 2002, Phillip White, colui che era alla guida di Informix
nel 1997, è stato accusato di frode da un grand joury federale e nel 2004 è
stato condannato a 2 mesi di carcere, ad una multa di 10.000 dollari, a due
anni di libertà vigilata e a 300 ore di servizio civile.
Nel 2004 IBM ha rilasciato il database Open Source Cloudscape.
Microsoft SQL Server
Microsoft SQL Server è il database relazionale prodotto da Microsoft.
Nelle prime versioni era utilizzato per basi di dati medio-piccole, ma
negli ultimi cinque anni (con l'uscita della versione 2000) è stato
utilizzato anche per la gestione di basi di dati di grandi dimensioni.
L'ingresso di Microsoft nel mondo dei database di fascia "entrerprise"
risale al 1989, quando cominciò la competizione con Oracle, IBM e
Sybase che erano i dominatori del mercato.
Microsoft SQL Server
La prima versione fu SQL Server per OS/2 ed era quasi identica a
Sybase SQL Server 4.0 su Unix.
Fino al 1994, Microsoft SQL Server riportava tre copyright della
Sybase come indicazione della sua origine.
In seguito Sybase cambiò il nome del suo prodotto in "Adaptive Server
Enterprise" per evitare confusione con "Microsoft SQL Server".
Microsoft SQL Server
SQL Server 7.0 è stato il primo database server basato su un'interfaccia
GUI.
L'attuale versione, Microsoft SQL Server 2000, è stata rilasciata
nell‘agosto del 2000.
Microsoft sta testando il suo successore, SQL Server 2006, e la versione
beta è disponibile per il download.
Microsoft SQL Server
A partire dalla versione 7.0, Microsoft SQL Server è stato dotato di
uno strumento, denominato English Query (EQ), che consente
agli utenti di fare domande o dare comandi in lingua inglese.
Le domande e i comandi vengono tradotti da EQ in query SQL e,
dunque, processati da SQL Server.
Microsoft ACCESS
Access è prodotto dalla Microsoft ed è creato per girare in
ambiente Windows.
La prima versione, la 1.0, è uscita fra il 1989 e il 1990
quando ancora Windows (alla versione 3.0) non era molto
diffuso e lo standard dei programmi database per PC era
ancora il DBIII Plus.
Intorno al 1993 è uscita la versione 2.0, l'ultima versione
precedente l'avvento di Windows 95.
Microsoft ACCESS
A partire dall'estate del 1995, con l'uscita di Windows 95 è stato
rilasciato anche Access 7 (detto anche "per Windows 95") seguito
infine, nella primavera del 1997, da Access 97.
Nell'estate del 1999 è uscito Access 2000.
Come si vede, in media ogni due anni viene rilasciata una nuova
versione che a volte è del tutto incompatibile con i formati delle
precedenti, creando non pochi disagi fra gli utenti.
ORACLE
Convenzionalmente, con il termine Oracle ci si
riferisce
ad
uno
tra
i più famosi database
management system.
La società informatica che lo produce, la Oracle
Corporation, è una delle più grandi del mondo. É
stata fondata nel 1977 ed ha la sua sede centrale in
California.
Il
fondatore,
nonchè
Lawrence J. Ellison.
importante
azionista,
è
ORACLE
La società negli ultimi anni si è impegnata enormemente
nell'appoggiare il sistema operativo GNU Linux facendo in modo
che tutte le sue applicazioni fossero disponibili sotto questo
sistema operativo e garantendo assistenza ai suoi clienti per lo
stesso sistema operativo.
L'altra attività di Oracle dopo i database sono i programmi di
enterprise resource planning (ERP) di cui è la terza venditrice a
livello mondiale dopo SAP e PeopleSoft e prima di Microsoft e
Sage. Recentemente ha lanciato una OPA (offerta pubblica di
acquisto) proprio sulla PeopleSoft.
Firebird SQL
Firebird SQL è un database relazionale molto potente che offre
un'ampia gamma di funzioni previste nello standard ANSI SQL-92.
Viene sviluppato da FirebirdSQL Foundation (di cui IBPhoenix è
uno dei maggiori contribuenti) ed è un progetto open source
disponibile per moltissimi sistemi operativi compresi Windows,
GNU Linux e praticamente tutti gli altri sistemi operativi stile Unix.
Firebird SQL
Firebird è stato usato nei sistemi di produzione sotto una
varietà di nomi dal 1981.
Il suo principale punto di forza sta nella completezza delle
funzioni previste da SQL che vengono supportate. Questo lo
rende uno dei database open source più potenti attualmente
disponibili.
MySQL
MySQL è un DBMS relazionale, composto da un client
con interfaccia a caratteri e un server, entrambi
disponibili sia per sistemi Unix che per Windows,
anche se prevale un suo utilizzo in ambito Unix.
MySQL
L’ideatore è Michael Widenius, sviluppatore della
compagnia svedese TcX.
• 1979 - Michael Widenius sviluppa uno strumento per la
gestione di database : UNIREG.
• 1994 - la TcX inizia a sviluppare applicazioni per il web
utilizzando UNIREG, ma sfortunatamente il prodotto
richiedeva troppe risorse per riuscire a generare
dinamicamente pagine web.
MySQL
La TcX analizza altri prodotti quali SQL e mSQL; quest'ultimo
in versione 1.x non supportava nessun indice e quindi aveva
performance peggiori di UNIREG.
Widenius contatta Hughes, l'autore di mSQL, per rendere
possibile la connessione di mSQL a UNIREG; ma Hughes
aveva già apportato modifiche sostanziose a mSQL con la
versione 2.
• La TcX decide di creare un altro server per database che
fosse piu' vicino alle loro esigenze a partire dall'esperienza di
UNIREG.
MySQL
Nel 1995 nasce, così, la versione di MySQL 1.0.
Dal 1996, MySQL supporta la maggior parte della sintassi SQL e
possiede delle interfacce di linguaggio SQL per 15 diversi
linguaggi sia di programmazione che non, compreso un driver
ODBC per le piattaforme Windows.
Nel 2000, la MySQL AB adotta la licenza GPL (GNU General
Public License) per il prodotto MySQL.
PicoSQL
PicoSQL è un database relazionale client/server che supporta il
linguaggio SQL. Le sue caratteristiche principali rispetto ai prodotti
concorrenti sono la compattezza, il basso utilizzo di memoria e risorse
e la semplicità di installazione e configurazione.
Nonostante questo, picoSQL supporta il linguaggio SQL con tutte le sue
caratteristiche, gestisce alti livelli di concorrenza e le transazioni.
PicoSQL
Lo ha sviluppato completamente la
Picosoft di Pisa e deriva da
un driver ODBC della stessa società che permette di interrogare i file a
indice prodotti da applicazioni scritte in COBOL utilizzando strumenti
di query e reportistica creati per accedere a database relazionali, come
MS Access, Excel, Crystal Report, ecc.
Trasformare questo driver in un DB è stato relativamente semplice, per
cui l'azienda ha deciso di renderlo disponibile come Open Source. Data
la sua “leggerezza” e modularità, picoSQL può essere facilmente
adattato per qualsiasi sistema, dal pocket-pc al mainframe.
SQLite
SQLite è una libreria C che implementa un DBMS SQL
incorporabile all'interno di applicazioni.
Il suo creatore è D. Richard Hipp, che
lo ha rilasciato come software Open
Source di pubblico dominio, privo di
qualsiasi licenza
SQLite
Essendo una libreria, non è un processo stand-alone
utilizzabile di per sé, ma può essere linkato all'interno di
un altro programma.
È utilizzabile con C/C++ ed esistono binding anche per
altri linguaggi, in particolare Tcl.
È integrato nella versione 5 di PHP.
STORIA DELLA PROGETTAZIONE DI
UN DATABASE
BASE DI DATI
E’ una raccolta di dati progettati per essere fruiti in maniera
ottimizzata da differenti applicazioni e utenti diversi
Semplice: facilmente ritrovabili
Efficiente: rispetto al tempo CPU e spazio RAM
Efficace: informazioni rappresentative della realtà in esame
Sicuro: operazioni consentite a soggetti identificabili e
sicuri
SISTEMA DI GESTIONE DI UNA BASE
DI DATI o DBMS
Prodotti software che permettono di creare e di
interagire con una base di dati, consentendo opportune
operazioni agli utenti autorizzati, nel rispetto delle
regole prestabilite. Le richieste degli utenti non devono
violare alcun vincolo sui dati.
FUNZIONI DI UN DBMS
Permettere la creazione di una nuova
base di dati
Facilitare gli utenti nell’inserimento,
cancellazione, modifica
Rendere possibile l’estrazione di
informazioni interrogando la base di dati
DDL
Data Definition Language
DML
Data Manipulation Language
QL
Query Language
Superare i limiti di:
ridondanza integrità indipendenza concorrenza sicurezza
LIMITI DEGLI ARCHIVI
TRADIZIONALI
CLIENTI
Merceria: INTIMO e più
codcliente
cognome
nome
indirizzo
città
010
Bianchi
Lucia
Via roma
Bari
011
Giglio
Maria
Via nuova
Foggia
012
Marini
Claudia
Piazza vecchia
Lecce
VENDITE
codcliente
Data
codart
descrizione
010
10-mag-05
P01
Calze
010
11-giu-05
P02
010
15-lug-05
011
marca
quantità
Sissi
2
Top
Pompea
1
P05
Pigiama
Alpina
1
7-mag-05
P01
Calze
Sissi
5
011
20-giu-05
P02
Top
Pompea
1
012
3-sett-05
P01
Calze
Sissi
1
LIMITI
9 Ridondanza: info ripetute per stessi articoli
9 Incongruenza: le modifiche vengono apportate a
tutti gli articoli con ugual codice?
9 Inconsistenza: se uno stesso articolo si ritrova con
marche diverse quale sarà quella giusta?
9 Dipendenza dei programmi dai dati: se cambia il
tracciato record o la cartella di un archivio devo
cambiare l’applicativo
9 Difficoltà nel gestire l’integrità dei dati: va
scritto codice ad hoc nell’applicativo
9 Difficoltà nel gestire la concorrenza: in un file
condiviso due utenti tentano la modifica, quale l’esito?
9 Limitata sicurezza: non tutti gli utenti hanno stessi
permessi sui dati
9 Scarsa protezione dei dati da guasti accidentali
MODELLI PER IL DATABASE
LIVELLO CONCETTUALE
Entità
MODELLO E/R
GERARCHICO 1970
LIVELLO LOGICO
Attributi e vincoli
RETICOLARE fine anni 70
MODELLO RELAZIONALE
LIVELLO FISICO
Più file separati
File unico, FLAT FILE
z
Differenze fra i modelli
Modello gerarchico
z
z
Volendo tracciare un percorso storico che
attraversi l’evoluzione subita dai DBMS nel corso
degli anni, è necessario iniziare la trattazione a
partire dal modello gerarchico.
Si può fissare la data di nascita di questo modello
alla fine degli anni ’60, quando IBM sviluppa e
introduce sul mercato IMS, il primo database
gerarchico, ma anche il primo DBMS in assoluto
Definizione :Modello Gerarchico
z Un
database gerarchico è un insieme di
archivi. Gli archivi sono composti da record
chiamati segmenti. I segmenti sono in
rapporto gerarchico tra loro attraverso
legami di tipo padre-figlio.
Modello Gerarchico:Struttura ad Albero
z La
struttura ad albero che caratterizza il
modello gerarchico si basa sulla possibilità
di individuare un segmento principale, il
padre o la radice, dal quale dipendono n
segmenti figli, che a loro volta si
trasformano in padri per altri figli e così via
Totale dipendenza dal padre ed è possibile fare riferimento solo attraverso il
passaggio dal nodo principale. Non è possibile dal figlio risalire al padre.
Ricapitoliamo MODELLO
GERARCHICO
Il primo modello gerarchico si affermò nel 1968 si
chiamava IMS (Information Management System) e
fu sviluppato da IBM. Oggi resistono sui mainframe.
I dati sono organizzati in record connessi tra loro secondo
strutture ad albero. L’albero è formato da 2 tipi di record: il
record OWNER (proprietario) e il record MEMBER
(componente).
Ogni record del database, che non sia la radice dell' albero,
deve avere uno e un solo padre
Es. il file system del sistema operativo: ogni cartella è
contenuta in una cartella padre tranne che la root
Limiti:
non si presta a rappresentare in modo efficiente
le associazioni N:M
Esempio db gerarchico
scuola
docente
Tanti alberi quante sono le scuole
S01
D01 De Nicolo
S02
D07
Sicolo
ITCS Giordano
Anita
D02
Mitolo
Nicola
D06
Nimeo
Marini
Carlo
>>Ridondanza<<
ITCS Dell’Olio
Lucia
D05
Rosa
D01 De Nicolo
Anita
Modello Gerarchico al Modello Reticolare
z
z
Questa architettura mal si adatta ad una gestione
moderna e dinamica delle basi di dati.
Il modello gerarchico rappresenta una prima
soluzione al problema della gestione di grosse
moli di dati ma la sua intrinseca rigidità ne limita
la potenzialità; per questo, nasce il modello
reticolare che dotato di maggiore flessibilità, può
adattarsi a situazioni più complesse
Modello Gerarchico al Modello Reticolare
z
z
In una struttura gerarchica un segmento figlio può
avere solo un segmento padre;
Non è così nel modello reticolare: ogni record può
avere un numero qualsiasi di record subordinati e
di record precedenti e le correlazioni vengono
espresse attraverso record particolari, chiamati
record di collegamento (member), che formano
delle catene tra le varie parti del sistema.
Modello Reticolare
z
z
Le strutture utilizzate nel modello reticolare sono
due, il record (si pensi ai comuni file) e il set, che
permette di correlare i record, per mezzo di catene
di puntatori.
Dunque una base di dati reticolare è definita con
riferimento ad uno schema, che contiene tipi
record collegati fra loro da tipo set.
Ricapitoliamo:
MODELLO RETICOLARE
Si affermò CODASYL (fine anni 70) sviluppato dal gruppo
di standardizzazione del linguaggio COBOL
Un record puo’ avere uno o piu’ record padre e cio’
permette di evitare i problemi di ridondanza
Il modello reticolare e’ così chiamato poiche’ ogni suo
schema puo essere rappresentato per mezzo di un
grafo (o una rete), con nodi e archi.
Limiti: Complessa la gestione difficile il progetto
Esempio db reticolare
scuola
S01
D02
Mitolo
docente
ITCS Giordano
Nicola
D05
D01 De Nicolo
Marini
Carlo
S02
ITCS Dell’Olio
Anita
D07
Sicolo
Non si ha il limite di un solo record superiore:
corrispondenza molti a molti
Lucia
Reticolare - Relazionale
z
La caratteristica fondamentale dei linguaggi per il modello reticolare e quella di
essere basati su una visita della base di dati, effettuata seguendo i collegamenti
stabilite le occorrenze dei set. Sono ovviamente possibili anche accessi diretti o
scansioni sequenziali, ma l'operazione fondamentale per la visita di una base di dati
reticolare e quella di navigazione sulla base di dati. Questa navigazione avviene
accedendo a singoli record, quindi ad un livello piu basso di quanto non avvenga nel
modello relazionale, in cui, le operazioni elementari coinvolgono intere relazioni (o
comunque insiemi di tuple).
Per questo motivo, l'accesso a basi di dati reticolari avviene normalmente attraverso un
linguaggio ospite cioe un linguaggio di programmazione tradizionale (per esempio
COBOL o PL1) esteso in modo tale che sia possibile specicare, oltre alle istruzioni
ordinarie, anche i comandi DML.
MODELLO RELAZIONALE
•Il modello relazionale è stato introdotto nel 1970 da
E.F.Codd(un ricercatore dell’IBM di San Jose, CA, USA) allo
scopo di favorire l’indipendenza dei dati
•I modelli preesistenti (gerarchico e reticolare) erano
fortemente influenzati da considerazioni di natura fisica,
che enfatizzavano quindi aspetti di efficienza rispetto a
quelli di semplicitàd’uso:
•VELOCI MA COMPLICATI!!
•Rispetto agli altri modelli, quello relazionale si caratterizza
per:
•Semplicità concettuale
•Concetti pochi e chiari
Modello Relazionale
z
z
z
z
z
Nel modello relazionale i dati sono organizzati in tabelle che
rappresentano sia le entita’, sia le relazioni tra di esse: esistono quindi
tabelle di entita’ e tabelle di relazioni.
Nel modello relazionale, a differenza dei precedenti, non c' e’ alcun
meccanismo esplicito per rappresentare i legami logici tra i diversi tipi
di record che non sia la relazione.
La modifica di un dato o di un legame comporta la manipolazione di
un solo record di una tabella.
Nel modello relazionale, a differenza dei precedenti, si realizza l'
indipendenza logica, e’ cioe’ possibile modificare le strutture senza
dover modificare i programmi.
Si possono inoltre modificare le strutture a DB aperto, con gli utenti
collegati.
Che cos’è un DB Relazionale
z
z
z
z
Un Database Relazionale e’ un insieme di tabelle
che rappresentano ogni tipo di informazione.
E’ un insieme di relazioni, ovvero:
Lo schema di un DB relazionale è un insieme di
schemi di relazioni con nomi distinti, più un nome
per il DB
R= {R1(X1), R2(X2), …, Rm(Xm)}(Ri≠Rj i ≠j)
Modello Relazionale
z Varie
fasi da seguire per la progettazione
z Nuovo modo di pensare la progettazione.
IL PROCESSO DI PROGETTAZIONE
DEL DATABASE
Il processo consta di quattro fasi:
Raccolta e analisi dei requisiti
2. Disegno del database concettuale
3. Disegno del database logico
4. Disegno del database fisico
1.
LE FASI DI PROGETTAZIONE DI UN
DATABASE
Indipendente dal DBMS
Miniworld
RACCOLTA ED ANALISI
DEI REQUISITI
1
Requisiti Funzionali
Requisiti sui Dati
ANALISI FUNZIONALE
DISEGNO CONCETTUALE
Specifia transazioni di alto livello
Schema Concettuale
(Usando Data Model di alto livello)
2
3
DISEGNO LOGICO
(DATA MODEL MAPPING)
Specifico del DBMS
DISEGNO PROGRAMMI
APPLICATIVI
Schema Logico (Concettuale)
Usando il data model del DBMS
IMPLEMENTAZIONE
TRANSAZIONI
DISEGNO FISICO
Programmi
Applicativi
Schema Interno
4
1. Raccolta e analisi dei requisiti
Il progettista del DB intervista i potenziali
utenti dei DB per capire e documentare i
requisiti utente.
Output:
z Requisiti sui dati
z Requisiti funzionali
– Operazioni definite dall'utente (transazioni) che
saranno applicate al DB
z
Es: aggiornamenti, ricerche, …
– Specifica dei requisiti funzionali attraverso Data Flow
Diagrams
2. Disegno del database concettuale
Creazione dello schema concettuale, usando un
data model concettuale ad alto livello
Output:
– Descrizione concisa dei requisiti utente dei dati
inclusiva di una descrizione dettagliata di tipi di dati,
relazioni e vincoli fatta usando i concetti del data model
ad alto livello.
z
z
Poiché non vi sono dettagli implementativi, tale descrizione
può essere usata per comunicare con utenti non tecnici
Tale documentazione può essere usata anche come riferimento
per assicurarsi di aver considerato tutti i requisiti dell’utente
Disegno del database concettuale (2)
z
Questo approccio abilita il progettista a
concentrarsi sui dati ignorando i dettagli di
memorizzazione.
z
Dopo aver disegnato lo schema concettuale, le
operazioni di base del data model possono essere
usate per specificare le operazioni di alto livello
individuate durante l'analisi funzionale (passo 1)
Modelli concettuali… un po’ di storia
z
z
z
z
z
Nel tempo sono stati proposti numerosi modelli
concettuali per la progettazione di basi di dati
modelli semantici, RM/T, ... [inizio anni ‘70]
Entity-Relationship (E/R) [entità-associazione]
[Chen 1976]
IDEF1X [standard adottato dagli uffici governativi
USA]
UML (Universal Modelling Language) [1999]
Il modello Entity-Relationship (ER)
E.R.: Introduzione
Il modello Entità-Relazione (ER) è un diffusissimo
data model di alto livello, estesamente utilizzato
per definire lo schema concettuale di un
database.
E’ stato concepito per essere più vicino ai
concetti ‘umani’, e quindi facilmente
comprensibile anche ad utenti non tecnici
Il modello ER ha avuto una grandissima
diffusione principalmente per i formalismi grafici
semplici e chiari che incorpora
E.R.: Introduzione (2)
z
Il modello ER è utilizzato in molti tool per la
progettazione di database
– Es. Platinum ER-Win
z
z
z
Esistono degli algoritmi per convertire
automaticamente un modello ER in uno schema di
database per DBMS commerciali
Fu introdotto da Chen nel 1976
E’ stato migliorato negli anni da Chen ed altri (tra
cui Elmasri), portando all’Enhanced-ER (EER)
E.R.: Introduzione (3)
Il modello ER descrive i dati con tre concetti
fondamentali:
– Entità
– Attributi
– Relazioni
Entità
z
Le entità corrispondono a classi di oggetti del mondo reale
(fatti, persone, …) che hanno proprietà omogenee, comuni
ed esistenza “autonoma” ai fini dell’applicazione di
interesse.
– Un’entità può essere un oggetto fisico (casa, impiegato, …) o un
oggetto concettuale (un lavoro, una società, …)
z
Ogni entità ha un nome che la identifica univocamente nello
schema e viene rappresentata graficamente con un
rettangolo con il nome dell’entità all’interno.
Impiegato
Rappresentazione ER
dell’entità “Impiegato”
Studente
Rappresentazione ER
dell’entità “Studente”
Attributi
z
Ogni entità ha delle proprietà dette attributi
– Esempio: l'entità impiegato ha attributi nome, età, indirizzo,
salario, telefono,…
z
z
Ogni entità è caratterizzata da un valore per i suoi attributi
Ogni attributo ha un nome che lo identifica e viene
rappresentata graficamente con un’ellisse contenente il
nome dell’attributo, collegata all’entità cui si riferisce.
Nome
Matricola
Studente
Rappresentazione ER
dell’entità “Studente” con gli
attributi “Nome” e “Matricola”
Entità e Attributi: Esempio
Esempio: entità Impiegato
Nome = John Smith
E1
Età = 55
Tel_casa = 713-749-2630
Indirizzo = 2311 Kirby, Houstin, Texas
Tipo di Entità
Entità con gli stessi attributi di base sono raggruppati in
un tipo di entità.
Esempio:
Tutte le persone che lavorano per un dipartimento possono essere
definite con l’entità Impiegato
Nome del Tipo di Entità: Impiegato
(Schema o Intensione)
Nome, Età, Stipendio
e1
(John Smith, 55, 80k)
e2
(Fred Brown, 40, 30k)
Insieme di Entità
(Judy Clark, 25, 20k)
…
(Estensione)
e3
Un tipo di entità
descrive lo schema
(o intenzione) per
un insieme di entità
Le entità individuali
di un particolare tipo
di entità sono
raggruppate in una
collezione o insieme
detta estensione del
tipo di entità.
Tipi di Attributi
Nel modello E-R abbiamo diversi tipi di
attributi:
•Semplice
•Composto
Attributi Semplici e Composti
z
z
Attributi semplici: ogni entità ha un valore singolo
(atomico) per tale attributo
Attributi composti: possono essere divisi in
sottoparti, che rappresentano informazioni di base
con loro significati indipendenti
z
Esempio: Attributo Indirizzo
Via = 2311 Kirby
Indirizzo
Città = Houston
Stato = Texas
Codice = 77001
Attributi Semplici e Composti (2)
Gli attributi composti possono formare una gerarchia
Via
Indirizzo
z
Città
Numero
Nome
Interno
Stato
Codice
L’utilizzo di un attributo semplice o di uno
composto dipende dalla necessità o meno di
trattare separatamente le sottoparti.
Attributi chiave di un tipo di entità
Un importante vincolo sulle entità di un tipo di entità è la
chiave o vincolo di unicità.
L’attributo chiave di un tipo di entità è un attributo che deve
avere un valore univoco per ogni entità.
Esempio: Il codice fiscale di una persona
– Talvolta più attributi insieme formano una chiave: in tal caso tali
attributi possono essere raggruppati in un attributo composto che
diventa chiave.
– Alcuni tipi di entità possono avere più di un attributo chiave
– In notazione ER l’attributo chiave è rappresentato sottolineato
nell'ovale.
Esempio: database Company
Requisiti per il database Company
– La compagnia è organizzata in DIPARTIMENTI. Ogni Dipartimento
ha un nome, un numero ed un impiegato che lo gestisce. Bisogna tener
traccia della data di insediamento del manager. Un dipartimento può
avere più locazioni.
– Ogni dipartimento controlla una serie di PROGETTI. Ogni progetto ha
un nome, un numero ed una singola locazione
– Per impiegato si tiene traccia di: nome, SSN, indirizzo, salario, sesso e
data di nascita. Ogni impiegato lavora per un dipartimento e può
lavorare su più progetti. Teniamo traccia del numero di ore settimanali
che un impiegato spende su un progetto e del supervisore di ogni
impiegato
– Ogni impiegato ha una serie di PERSONE A CARICO. Per ogni
persona a carico, registriamo: nome, sesso, data di nascita e parentela
con l’impiegato
Disegno concettuale del database
Company
Descriviamo i tipi di entità per il database COMPANY.
In accordo ai requirements possiamo identificare quattro
tipi di entità:
1.
DIPARTIMENTO
Nome, Numero, {Sedi}, Manager, Datains_manager
Nome e Numero sono entrambi attributi chiave
2.
PROGETTO
Nome, Numero, Luogo, Dip_controllo
Nome e Numero sono entrambi attributi chiave
Disegno concettuale del database
Company (2)
3.
IMPIEGATO
Nome, SSN, Sesso, Indirizzo, Stipendio, DataNascita, Dipartimento,
Supervisore
SSN è un attributo chiave
Nome e Indirizzo sono attributi composti (occorrerebbe verificare
con l'utente se ha bisogno di riferire ai componenti individuali)
4.
PERS_A_CARICO
Sesso, DataNascita, Impiegato, Nome_pers_carico, Parentela
Disegno concettuale del database
Company (3)
Dobbiamo però rappresentare:
– Il fatto che un impiegato può lavorare su più progetti
– Il numero di ore settimanali di un impiegato su ciascun progetto
z
Si può aggiungere un attributo a IMPIEGATO “Lavora_su”
composto di due componenti semplici (Progetto, Ore)
IMPIEGATO
Nome (FName, Minit, LName), SSN, Sesso, Indirizzo, Stipendio,
DataNascita, Dipartimento, Supervisore, {Lavora_su(Progetto, Ore)}
z
In alternativa, le stesse informazioni si potrebbero mantenere
nel tipo di entità PROGETTO con un attributo composto
– Addetti (Impiegato, Ore)
Disegno concettuale del database
Company (4)
Esistono varie relazioni implicite:
– L'attributo Manager di DIPARTIMENTO si riferisce a un
impiegato che gestisce il dipartimento:
– L'attributo Dip_controllo di PROGETTO si riferisce al
dipartimento che controlla il progetto;
– L'attributo Dipartimento di IMPIEGATO si riferisce al
dipartimento per cui lavora l'impiegato;
Nelle disegno iniziale queste associazioni tra entità sono
rappresentabili come attributi, ma durante il processo di
raffinamento nel modello ER questi riferimenti dovrebbero
essere rappresentati come relazioni.
RELAZIONI, RUOLI E
VINCOLI STRUTTURALI
Tipi e istanze di relazioni
Le relazioni corrispondono a legami logici tra entità,
significativi ai fini dell’applicazione di interesse.
Un tipo di relazione è un’associazione tra n tipi di entità E1,
E2,…,En.
Le occorrenze o istanze di relazione associano n entità dei tipi
di relazione richiesti
Ogni tipo di entità è detto partecipare al tipo di relazione
Il grado di un tipo di relazione è il numero di entità che vi
partecipano. Se il grado è 2, la relazione è detta binaria
Tipi e istanze di relazioni (2)
Esempio: vogliamo rappresentare il fatto che ogni impiegato ei lavora per
un dipartimento dj.
Definiamo il tipo di relazione LAVORA_PER tra i due tipi di entità
IMPIEGATO e DIPARTIMENTO: ogni relazione ri associa una entità
IMPIEGATO ei con una entità DIPARTIMENTO dj.
…
Impiegato:
Tipo di Entità
d1
d2
…
r1
r2
r3
r4
Lavora_Per:
Relazione
…
e1
e2
e3
e4
Dipartimento:
Tipo di Entità
Grado di un tipo di relazione
Il grado di un tipo di relazione è il numero di tipi di entità
partecipanti
Esempi:
– LAVORA_PER è di grado 2 (binaria).
– La relazione SUPPLY è un tipo di relazione ternaria, dove ogni istanza di
relazione ri associa tre entità, un fornitore s, una parte p e un progetto j
ogni volta che s fornisce la parte p al progetto j.
e1
r1
e2
…
Fornitore
d1
r2
d2
…
r3
r4
e1
…
e2
…
Parte
Supply
Progetto
Le relazioni possono
essere di qualsiasi
grado ma le più
ricorrenti sono quelle
binarie.
Rappresentazione di Relazioni
In uno schema ER, un tipo di relazione ha un nome che lo
identifica univocamente e viene rappresentato graficamente
con un rombo, contenente il nome della relazione, e da linee
che lo collegano ai tipi di entità che mette in relazione.
Impiegato
Lavora_Per
Rappresentazione ER della relazione
“Impiegato lavora per Dipartimento”
Dipartimento
Relazioni come attributi
A volte (soprattutto in fase di disegno iniziale) può
essere conveniente considerare un tipo di relazione
come un attributo di una delle entità partecipanti, per
semplificare la definizione dello schema.
Le relazioni verranno poi esplicitate durante il
raffinamento del progetto.
Quando si considera una relazione binaria come
attributo esistono ovviamente due alternative, in base a
quale entità viene scelta per contenere l’attributo
Relazioni come attributi: Esempio
Il tipo di relazione LAVORA_PER può essere rappresentato:
– Tramite un attributo Dipartimento nel tipo di entità IMPIEGATO.
Per ogni entità impiegato si riferisce all'entità dipartimento in cui
lavora. Il dominio dell'attributo Dipartimento è l’insieme di tutte le
entità DIPARTIMENTO.
oppure
– tramite un attributo multivalued Impiegati del tipo di entità
DIPARTIMENTO.
Per ogni entità dipartimento il valore dell'attributo Impiegati è
l'insieme degli impiegati che lavorano in quel dipartimento.
Il dominio dell’attributo Impiegati è l'insieme delle entità
IMPIEGATO.
Se entrambi gli attributi sono utilizzati per rappresentare la
relazione LAVORA_ PER, allora essi sono vincolati ad essere
l'uno l'inverso dell'altro
Nomi di Ruolo
z
Ogni entità che partecipa a qualche tipo di
relazione riveste un ruolo particolare nella
relazione.
– Il nome di ruolo specifica il ruolo che riveste in
ciascuna istanza di relazione una entità partecipante.
z
Esempio: nel tipo di relazione LAVORA_PER,
– IMPIEGATO gioca il ruolo di impiegato o di addetto
– DIPARTIMENTO gioca il ruolo di dipartimento o di
datore di lavoro.
Vincoli sui tipi di relazioni
Ogni tipo di relazione ha un insieme di vincoli che
limitano le combinazioni possibili di entità che
possono partecipare ad istanze della relazione.
Questi vincoli sono determinati dalla situazione del
miniworld che le relazioni rappresentano.
Esempio:
– se la società ha la regola che ogni impiegato deve
lavorare esattamente per un dipartimento, si vuole
descrivere questo vincolo nello schema.
Rapporto di cardinalità
Deve essere indicato per ciascun tipo di entità che partecipa
ad una relazione, e permette di specificare il numero minimo
e massimo di istanze di relazione a cui le occorrenze delle
entità coinvolte possono partecipare.
Impiegato
(1,1)
Lavora_Per
(0,N)
Dipartimento
Rappresentazione ER della relazione “Impiegato lavora per
Dipartimento”, con rapporto di cardinalità N:1
• MAX: Ogni dipartimento può avere numerosi impiegati, e
ciascun impiegato lavora per un solo dipartimento
• MIN: Un dipartimento potrebbe non avere impiegati,
mentre un impiegato deve sempre essere assegnato ad un
dipartimento
Rapporto di cardinalità
E’ possibile assegnare un qualunque intero non negativo a un
rapporto di cardinalità, con l’ovvio vincolo che la cardinalità
minima deve essere minore o uguale alla cardinalità massima.
Nella maggior parte dei casi si utilizzano solo tre valori: 0, 1 e
N.
– Il valore 0 per la cardinalità minima indica una partecipazione
opzionale del tipo di entità alla relazione.
– Il valore 1 per la cardinalità minima indica una partecipazione
obbligatoria del tipo di entità alla relazione.
Esiste una notazione alternativa…..
Rapporto di cardinalità: Esempi
La relazione binaria GESTISCE tra IMPIEGATO e
DIPARTIMENTO è di rapporto di cardinalità 1:1 (un impiegato
può gestire al più un dipartimento, ed un dipartimento deve
sempre avere un solo manager)
Impiegato
e1
e2
e3
Gestisce
r1
r2
…
Impiegato
Gestisce
(1,1)
Dipartimento
d1
d2
d3
…
r3
…
e4
(0,1)
Dipartimento
Rapporto di cardinalità: Esempi
La relazione binaria LAVORA_SU tra IMPIEGATO e
PROGETTO è di rapporto di cardinalità M:N, (poiché un
impiegato può lavorare su più progetti, e più impiegati
possono lavorare sullo stesso progetto)
Impiegato
M
Lavora_Su
N
Progetto
r1
e1
r2
r3
r4
e2
e3
e4
p2
p3
Lavora_Su
…
r5
…
…
Impiegato
p1
Progetto
Attributi di Tipi di Relazioni (2)
Gli attributi dei tipi di relazioni 1:1 e 1:N possono essere
trasferiti a uno dei tipi di entità partecipanti.
Es:per il tipo di relazione GESTISCE, la data di insediamento può essere
l'attributo di IMPIEGATO oppure di DIPARTIMENTO, perché si tratta di
un tipo di relazione 1:1.
Per un tipo di relazione 1:N, un attributo di relazione può essere
trasferito solo al tipo di entità dalla parte N della relazione.
Es: nei tipo di relazione LAVORA_PER un attributo data_inizio per
inizio del rapporto dell'impiegato con il dipartimento, può essere incluso
come un attributo del tipo di entità IMPIEGATO.
La scelta di considerare l’attributo nel tipo di entità o nel tipo di
relazione è una scelta soggettiva del progettista di DB.
Attributi di Tipi di Relazioni (3)
Per tipi di relazioni M:N non è sempre possibile
mantenere l'attributo in una delle due entità
partecipanti in quanto tale attributo può essere
determinato dalla combinazione delle entità (Ad
esempio l'attributo Ore della relazione M:N
LAVORA_SU è determinato dalla combinazione
impiegato-progetto)
RAFFINAMENTO DEL MODELLO
ER
RAFFINAMENTO DEL MODELLO ER
z Si
procede a cambiare gli attributi che rappresentano
relazioni in tipi di relazioni.
z I rapporti di cardinalità e il vincolo di partecipazione
di ciascun tipo di relazione si determinano a partire
dai requisiti; Se necessario si consulta l'utente.
–
Nell'esempio specifichiamo i seguenti tipi di relazioni
1.
z
GESTISCE, tipo di relazione 1:1 tra IMPIEGATO e
DIPARTIMENTO.
Partecipazione:
IMPIEGATO: parziale
DIPARTIMENTO: (richiesto a utente) totale
Attributo: data_Ins
RAFFINAMENTO DEL MODELLO ER
2.
z
3.
z
LAVORA_PER, tipo di relazione 1:N tra
DIPARTIMENTO e IMPIEGATO
Partecipazione:
DIPARTIMENTO : totale
IMPIEGATO : totale
CONTROLLA, tipo di relazione 1:N tra
DIPARTIMENTO e PROGETTO
Partecipazione:
DIPARTIMENTO : totale
PROGETTO : (richiesto a utente) parziale
RAFFINAMENTO DEL MODELLO ER
4.
z
5.
z
z
SUPERVISIONE, tipo di relazione 1:N tra IMPIEGATO (ruolo
supervisore) e IMPIEGATO (ruolo subordinato)
Partecipazione:
IMPIEGATO: (?) richiesto a utenti parziale IMPIEGATO: (?) richiesto
a utenti parziale
(non tutti gli impiegati sono supervisori e non tutti gli impiegati hanno
un supervisore)
LAVORA_SU, tipo di relazione M:N tra IMPIEGATO e PROGETTO.
Partecipazione:
IMPIEGATO totale
PROGETTO totale
Attributo:Ore
RAFFINAMENTO DEL MODELLO ER
6.
z
z
A_CARICO, tipo di relazione 1:N tra IMPIEGATO e
PERS_CARICO.
Partecipazione:
IMPIEGATO parziale
PERS_A_CARICO : totale
Si eliminano quindi tutti gli attributi che sono
stati convertiti in relazioni. E importante
eliminare la ridondanza, che può essere
eventualmente aggiunta in fasi successive
MODELLO ER RISULTANTE
Numero
Nome
Cognome
LAVORA_PER
N
1
Indirizzo
Nominativo
Sesso
Data_Ins
Salario
1
SSN
DIPARTIMENTO
GESTISCE
1
DataN
CONTROLLA
Ore
supervisor
supervisee
SUPERVISIONA
N
M
LAVORA_SU
N
N
PROGETTO
1
HA_A_CARICO
Nome
N
Sesso
DataN
Locazione
Numero
P_A_CARICO
Nome
1
NumeroDip
IMPIEGATO
1
Locazioni
Nome
Parentela
3. Disegno del database logico
Consiste nella traduzione dello schema concettuale nel
modello dei dati del DBMS
z Il risultato è uno schema logico, espresso nel DDL del
DBMS
z In questa fase si considerano anche aspetti legati a:
z integrità e consistenza (vincoli)
z efficienza
Descrive in maniera corretta ed efficiente tutte le
informazioni contenute nel modell E/R.
Ristrutturazione del modello E/R.
z Traduzione verso il modello Logico.
z Obbiettivo: semplificare e Ottimizzare il progetto.
z
Progettazione logica nel modello reticolare
Abbiamo notato come la
progettazione logica possa essere articolata in due
sottofasi e come solo la seconda di esse (la
\traduzione") dipenda effettivamente dal modello
logico di interesse.
z Per tradurre schemi E-R ristrutturati in schemi
reticolari. Per certi aspetti, la situazione e ancora piu
semplice che per il modello relazionale, perche si puo
far corrispondere tipi record alle entità e tipi set alle
associazioni.
z
Progettazione logica nel modello reticolare
(2)
z Per
le associzioni, si deve pero notare che
un tipo set corrisponde ad una associazione
uno a molti fra tipi record diversi, per cui
dovra essere necessario prestare particolare
attenzione ai casi piu complessi, e cioe alle
associazioni molti a molti, a quelle ternarie
(o piu che ternarie) e a quelle ricorsive.
Relazione uno a molti
Una associazione uno a molti puo essere tradotta
direttamente con un tipo set. abbiamo due tipi record e
un tipo set.
Relazione molti a molti
Una associazione molti a molti puo essere tradotta
direttamente con un tipo set. abbiamo due tipi record e un
tipo set.
Conclusioni:
La traduzione del Modello E/R si adatta molto di pù
seplicemente verso un modello relazionale in quanto
logicamente più semplice e lineare.
z L'organizzazione dei dati del modello
reticolare ricorda piu le strutture fisiche dei dati che le
proprieta intrinseche dei dati stessi.
z Piu complicato molto più veloce(presenza di punatori)
z Presenza di una lista circolare dall’owen, da ciascuna
occorrenza del member e possibile risalire all'owner.
z
4. Disegno del database fisico
z
Produce lo schema fisico della base di dati ricevendo in ingresso lo
schema logico.
z
In questa ultima fase si operano scelte spesso strettamente dipendenti
dallo specifico DBMS utilizzato
z
Ad esempio, lo stesso schema logico può essere fisicamente
rappresentato in modo diverso in DB2 e in Oracle, al fine di meglio
sfruttare le caratteristiche dei due DBMS
z
Il risultato è lo schema fisico, che descrive le strutture di
memorizzazione e accesso ai dati (tablespace, clustering, indici, ecc.)
Riassumiamo
z
z
z
z
z
La progettazione di un sistema informativo è guidata dai dati, e si
avvale di una metodologia che consta di diverse fasi
Ogni fase produce uno schema, facendo uso di uno specifico modello
Per la progettazione concettuale si fa uso di un modello concettuale
che, astraendo da aspetti specifici dei DBMS, rappresenta un valido
compromesso tra ciò che si dovrà realizzare e la realtà che si deve
modellare
Tutti i modelli concettuali si basano su alcuni meccanismi di astrazione
fondamentali: classificazione, aggregazione, generalizzazione
Operazioni Consentite
z
z
z
z
z
z
z
z
z
z
z
z
z
Affinche’ un RDBMS possa dirsi relazionale deve essere in grado di eseguire le tre operazioni
relazionali di base: la proiezione, la selezione e il join.
La Proiezione e’ una visualizzazione "verticale" della tabella (solo alcune colonne).
La Selezione e’ una visualizzazione "orizzontale" della tabella (solo alcune righe che soddisfano
una condizione).
Il Join e’ l' unione di record che sono memorizzati su tabelle diverse.
Esistono diversi tipi di join: il prodotto cartesiano, il join naturale, il self join e l' outer join.
Il Prodotto cartesiano di due tabelle T1 e T2 e’ un insieme con tutte le possibili coppie di ogni
record T1 con ogni record T2.
Il prodotto cartesiano completo non ha alcun interesse, occorre quindi selezionare da questo le
righe significative, cioe’ quelle in cui il campo in comune tra le tabelle in join ha un contenuto
uguale.
Queste sono le condizioni di join che legano insieme due o piu’ tabelle in un Join naturale.
Il Self join e’ un join di una tabella con se stessa.
L' Outer join e’ un join tra due tabelle su una delle quali il record in join puo’ mancare ma il
record dell' altra tabella viene visualizzato comunque.
Tra le caratteristiche di un database relazionale vi e’ la possibilita’ di eseguire operazioni
insiemistiche sulle righe estratte da due o piu’ tabelle: unione, intersezione e differenza.
L' Unione consiste nell' estrazione di tutte le righe che compaiono in almeno una delle tabelle.
L' Intersezione consiste nell' estrazione delle righe comuni a tutte le tabelle.
La Differenza consiste nell' estrazione delle righe che compaiono nella prima tabella ma non nella
seconda.
Join: Database CPLATAM
CPLSAS
CPLUSER
Nome
Data_Nasc
ita
Lavoro
Nome
Studi
Master
pasquale
25/03/77
consulente
pasquale
Laureato
Y
Select studi, lavoro from cpluser.Tab1 A, cplsas.Tab2 B where A.Nome=B.Nome
Output:
Laureato Consulente
1 row selected
Database orientati agli oggetti
L’OODB (Object Oriented DataBase è un modello più
recente di database che nasce dall’esigenza di gestire
informazioni multimediali: immagini, audio, video,
documenti e risorse Internet.
Insieme ai dati nel database sono specificate le
modalità di accesso più adatte al formato che si sta
trattando: i metodi e i dati sono inglobati nelle classi proprio
come prescrive il paradigma della programmazione Object
Oriented.
Esempi di DBMS orientati agli oggetti sono Versant,
Objectstore e Poet