Microsoft's Internet Explorer browser has no built-in vector graphics machinery required for "loss-free" gradient background themes.

Please upgrade to a better browser such as Firefox, Opera, Safari or others with built-in vector graphics machinery and much more. (Learn more or post questions or comments at the Slide Show (S9) project site. Thanks!)

R-DBMS - Introduzione ai database relazionali liberi

La progettazione concettuale - Modello entità-relazioni

Master "Tecnologie OpenSource"

R-DBMS – Presentazione del modulo

  1. Definizioni
  2. Progettazione di un DB
  3. Modello concettuale: ER/EER
  4. Modello logico: diagramma relazionale
  5. Modello fisico
  6. SQL
  7. Postgres: presentazione del progetto
  8. Amministrare Postgres
  9. GUI per Postgres (PgAdminIII, pgMyAdmin, Openoffice..)
  10. SQLite: un R-DBMS “leggero”

Argomenti della lezione

  • Introduzione ai DB relazionali e ai DBMS
  • Evoluzione storica dei modelli di DBMS
  • Caratteristiche principali di un DBMS
  • Architetture dei DBMS
  • Processo di modellazione
  • Modello concettuale: diagramma ER
  • Modellazione avanzata: diagramma EER

Introduzione

I database sono diventati una componente essenziale della vita di tutti i giorni.

Definizioni: database

Per database si intende una collezione di dati coerenti e correlati. Più nello specifico si può parlare di database in presenza di:

In altre parole un database deriva da qualche sorgente di dati, è caratterizzato da un qualche grado di interazione con gli eventi del mondo reale (o più precisamente dell’universo del discorso), ed è progettato e popolato specificamente sulla base degli interessi di un gruppo di utenti interessati al suo contenuto.

Definizioni: DBMS

Un DBMS (Database Management System) è una collezione di programmi che permettono agli utenti di creare e manutenere un Database

In particolare si tratta di un software general-purpose teso a facilitare il processo di definizione, costruzione e manipolazione di un database per le più diverse applicazioni.

Nota: in generale per implementare un database non è necessario un DBMS general-purpose, tuttavia tali software sono lo stato dell’arte della tecnologia in questo ambito, e permettono di alleggerire lo sviluppatore dal lavoro di implementazione di una soluzione ad-hoc

Storia dei DBMS

La memorizzazione efficace dei dati è stato un problema resosi evidente fin dagli albori dell’era informatica. Nel corso degli anni, al pari delle evoluzioni tecnologiche, si sono susseguite differenti soluzioni:

  • DB basati su flat-file
  • DB gerarchici
  • Modelli basati su reti
  • Modelli relazionali
  • Soluzioni orientate agli oggetti
  • Modelli ibridi (relazionali/O-O)

Flat file

L’utilizzo di un modello di database basato su file system non prevede l’applicazione di alcuna tecnica di modellazione dei dati, e si basa sulla memorizzazione delle informazioni su semplici file, utilizzando le sole strutture del sistema operativo. Il termine flat file è un modo per descrivere un semplice file di testo privo di qualsiasi struttura.

Caratteristiche del modello flat-file:

Database gerarchici

I database gerarchici si basano su una struttura ad albero rovesciato, in cui ogni tabella è in relazione padre/figlio con le altre.

  • Le tabelle “figlie” esistono solo in funzione delle tabelle “genitore”
  • Questa struttura supporta relazioni di tipo uno a molti
  • Lo svantaggio evidente è nel fatto che le interrogazioni devono partire tutte dalla tabella root


Modello a reti

Il modello a rete è un perfezionamento di quello gerarchico.

  • In queste architetture ciascuna tabella può avere più di una tabella genitore
  • Si viene così a creare una struttura simile ad una rete
  • La presenza di più tabelle genitore permettono la modellazione di relazioni molti a molti


Database relazionali

I database relazionali rappresentano un ulteriore miglioramento rispetto ai precedenti, permettendo l’accesso diretto a ciascuna tabella e interconnessioni (relazioni) liberamente defininibili.

Il modello relazionale fu teorizzato nei laboratori IBM a cavallo degli anni ’70, dal matematico Edgard F. Codd; si basa sulla teoria degli insiemi e su un processo di modellazione detto normalizzazione, teso ad eliminare incongruenze e duplicazione dedi dati.

Tale modello prevede l’esistenza di un linguaggio di interrogazione dei dati, chiamato SQL (Structured Query Language)

Database Object Oriented e ibridi

Negli ultimi anni si sono affermate due nuove architetture:

Vantaggi di un DBMS (1/2)

Utilizzare un DBMS nello sviluppo di un’applicazione data driven apporta numerosi vantaggi:

Vantaggi di un DBMS (2/2)

Altri punti a favore nell’utilizzo di un DBMS risultano essere:

L’altro lato della medaglia…

Esistono alcuni ambiti applicativi in cui tutta questa versatilità non è necessaria. In questi casi l’uso di un DBMS è sconsigliabile:

Architettura di un DBMS

L’architettura dei DBMS si è evoluta nel tempo, passando dagli iniziali sistemi monolitici, in cui tutte le componenti erano accentrate in un unico sistema che si occupava di memorizzare i dati, fornire l’accesso agli stessi e implementare tutti i meccanismi già descritti, fino ad arrivare alle moderne architetture basate sull’interazione tra più sottosistemi indipendenti, spesso residenti su macchine differenti che comunicano attraverso la rete.

Tale evoluzione rispecchia in parte quanto avvenuto nel mondo della computazione, che ha visto la transizione dai mainframe alle più moderne tecnologie di calcolo distribuito e cloud computing

Architettura centralizzata

Schema di un DBMS centralizzato:

tutte le capacità di calcolo e storaging risiedono su un mainframe, al quale si collegano terminali stupidi

Architettura client/server a 2 livelli

La rapida crescita delle capacità di calcolo e memorizzazione, l’abbattimento dei costi dell’hardware e la diffusione delle tecnologie di networking ha portato all’introduzione di un nuovo modello architetturale

Nell’architettura client/server a due livelli il mainframe viene sostituito da una serie di server dedicati a specifici servizi, e i terminali stupidi da workstation e PC.

Architettura client/server a 3 livelli

L’avvento del Web ha modificato definitivamente il modo di accedere alle risorse attraverso la rete, imponendo un’ulteriore evoluzione del modello client/servr

In questa architettura sono disaccoppiate le funzionalità di logica applicativa (sull’application server), di storaging (DBMS) e di interfaccia con l’utente (GUI, client Web, RIA)

Modellazione di un database (1/3)

L’implementazione di un’applicazione data-driven robusta passa necessariamente da un’attenta fase di analisi e modellazione del database

La modellazione è quel processo che assicura che il tutto funzioni prima ancora che venga implementato; può essere inteso come un test preliminare su carta, prima di investire energie e risorse nella realizzazione di qualcosa che si scoprirà non funzionare…

Nota: risolvere un problema sulla carta costa molto meno che riscrivere componenti software!

Modellazione di un database (2/3)

Esistono diverse metodologie utilizzabili per la progettazione di un database. Ciascuno di questi approcci è sempre riconducibile ad un numero finito di passi da seguire:

Nota: tutte queste fasi sono da considerarsi intercambiabili, ripetibili e iterabili

Modellazione di un database (3/3)

Analisi dei requisiti

L’analisi dei requisiti è una delle fasi più delicate di tutto il processo di modellazione.

In questo step, in cui collaborano il committente e i progettisti, devono emergere tutti gli aspetti significativi del progetto:

Modellazione concettuale

In questa fase i progettisti devono tradurre i requisiti raccolti in qualcosa di quantitativo, una schematizzazione del problema che possa successivamente essere tradotta in un linguaggio interpretabile dal DBMS.

Il modello concettuale fa uso di concetti come entità, attributi e relazioni per rappresentare gli oggetti del mondo reale (più specificamente dell’universo del discorso) portatori di informazioni.

Il modello concettuale può essere rappresentato in modi diversi; le tecniche più note sono il diagramma entità-relazioni (ER) e l’UML

Modellazione logica

La modellazione logica tende a tradurre il modello concettuale in un DDL (Data Definition Language), interpretabile dal DBMS

Nei database relazionali la modellazione logica si basa sul modello relazionale, che fu introdotto nel 1970 da Edgard F. Codd nei laboratori IBM, e incontrò subito grandi attenzioni per la sua semplicità e per le basi matematiche su cui si basa (relazioni matematiche, teoria degli insiemi, logica dei predicati).

In questo modello il database è rappresentato come una collezione di relazioni o tabelle di valori. Ogni riga della tabella (tupla) corrisponde ad un insieme di dati correlati.

Nota: il passaggio da modello concettuale a logico può essere realizzato in forma algoritmica, a patto che il primo sia stato normalizzato.

Modellazione fisica

L’ultimo step della fase di progettazione consiste nella creazione di un modello fisico.

Il modello fisico, come evidenziato in precedenza, è strettamente correlato al DBMS scelto. Esso è costituito dalle descrizioni delle tabelle, dei vincoli di integrità referenziale, ed eventualmente dei behavior (triggers e stored procedures) nel linguaggio di programmazione interno al DBMS.

Per una corretta scrittura di un modello fisico occorre conoscere gli internals del sistema che si utilizza:

Modello ER

Il componente base del modello Entità-Relazioni è l’entità.

Una entità è un qualcosa che esiste nel mondo reale. Può essere un oggetto fisico (una automobile, un libro..) o un oggetto concettuale (un lavoro o un corso universitario).

Ciascuna entità possiede uno o più attributi, che la caratterizzano e posseggono il contenuto informativo. I valori degli attributi, che descrivono una entità, costituiscono la maggior parte delle informazioni memorizzate in un database relazionale.

Entity, Entity sets and types, Keys

Un tipo di entità definisce un insieme di entità con attributi uguali.

La collezione di tutte le entità con uguali attributi, appartententi cioè allo stesso tipo di entità, è detta entity set

Si dice cardinalità di un entity set il numero di entità in esso contenute.

Il modello relazionale impone che all’interno di un entity set ciascuna entità sia univoca; deve essere sempre possibile rintracciare un attributo (chiave semplice) o un gruppo di attributi (chiave composta) che assume valore diverso per ciascuna entità.

Attributi

Gli attributi possono essere caratterizzati in modi differenti:

Relazioni e molteplicità

Le relazioni possono essere classificate secondo due criteri:

Weak entities e relazioni di partecipazione totale

Si definisce weak entity (entità debole) un tipo di entità privo di un attributo chiave (violazione del vincolo di univocità). Le entità di tale set dipendono da un’entità esterna appartenente ad un secondo tipo di entità detto di appartenenza.

Una weak entity presenta sempre un vincolo di partecipazione totale rispetto al tipo di entità da cui dipende.

La relazione tra strong entity e weak entity si dice relazioni di identità

Nota: le weak entities, pur non possedendo una chiave univoca, possiedono sempre una chiave parziale, che serve a distinguere weak entities diverse correlate ad una stessa entità di appartenenza.

Diagramma ER (1/2)

Nel diagramma E-R un tipo di entità viene rappresentato con un rettangolo.

Un attributo singolo viene rappresentato con un ovale.

Una relazione viene rappresentata con un rombo.

I collegamenti tra tipi di entità, relazioni e attributi sono rappresentati da segmenti di linea continua.

Gli attributi multipli+ si disegnano con un doppio ovale.

Le weak entities si disegnano come un rettangolo con contorno a doppia linea.

Le relazioni di identità con un rombo a doppia linea.

Le partecipazioni totali con un doppio segmento.

Diagramma ER (2/2)

Case study: DB aziendale

Si vuole modellare un DB aziendale in cui si memorizzino dati relativi a:

Si devono memorizzare anche informazioni circa:

Case study: DB aziendale (ER)

EER diagram

Con i diagrammi ER possono essere rappresentati la maggior parte degli universi in applicazioni data-driven tradizionali.

Tuttavia, al crescere della complessità dei sistemi, sono state proposte nuove caratteristiche che incrementano la semantica del modello concettuale, introducendo idee mutuate dalla programmazione quali l’ereditarietà e l’aggregazione.

Un diagramma EER (Enhanced-ER) risulta essere dunque un’estensione del modello ER, con l’aggiunta dei concetti di:

Specializzazione

La specializzazione è il processo che porta a definire un insieme di sottoclassi a partire da un tipo di entità base.

L’insieme delle sottoclassi che formano una specializzazione è caratterizzato sulla base di alcune caratteristiche distintive (attributi locali o specifici).

A partire da un singolo tipo di entità (superclasse) possono essere definiti una o più specializzazioni; ciascuna sottoclasse erediterà le caratteristiche comuni e le relazioni a cui partecipa la superclasse.

Nota: se un’entità è istanza di una sottoclasse deve esistere anche nell’entity set della superclasse.

Generalizzazione

Concettualmente il processo di generalizzazione è inverso a quello di specializzazione.

Esso consiste nella soppressione delle differenze tra tipi di entità, mediante l’individuazione di caratteristiche comuni che diventeranno parte di una superclasse comune di generalizzazione

Sottoclassi condizionalmente definite

In alcuni casi è possibile determinare con esattezza le entità che diventeranno membri di una sottoclasse, definendo una condizione sul valore di uno o più attributi.

Le sottoclassi così determinate prendono il nome di “sottoclassi condizionalmente definite”, perché le rispettive istanze dipendono dal verificarsi di un predicato

Vincoli di specializzazione (1/2)

Una relazione ti tipo classe/sottoclasse può essere caratterizzata da altri due tipi di vincoli differenti:

Questi due tipi di vincoli differenti, combinati insieme caratterizzano 4 scenari distinti:

Vincoli di specializzazione (2/2)

Disjoint, partecipazione totale

Overlapping, partecipazione totale

Categorie e aggregazioni

In alcuni casi è necessario modellare relazioni superclasse/sottoclasse in cui esiste un’unica sottoclasse, che erdita da più superclassi che rappresentano tipi di entità distinte

In questi scenari la sottoclasse rappresenta una collezione di oggetti che è un sottoinsieme (o l’ unione) di istanze di entity types distinte; si parla allora di union type o categoria.

Copyright (C) 2008 - Alca Societa' Cooperativa

http://alca.le.it - info@alca.le.it

released under CreativeCommons 2.5 by-nc-sa

NOTA: le immagini dei software e dei device contenuti
nella presentazione sono proprieta' dei relativi detentori
del copyright e sono state riprodotte a scopo esclusivamente didattico.