Please enable JavaScript.
Coggle requires JavaScript to display documents.
PROGETTAZIONE DI UN DATABASE, MODELLAZIONE FUNZIONALE FASI 4 - 5,…
PROGETTAZIONE DI
UN DATABASE
FASE 4:
FISICA - IMPLEMENTAZIONE
completamente dello schema logico in
funzione dell'organizzazione fisica
DEFINIZIONE
progettare le strutture, prima logiche e poi fisiche, di un database (DB) in modo che possano accogliere i dati che un'utente ha bisogno
FASE 5:
REALIZZAZIONE
realizzazione fisica del DB
FASE 1:
ANALISI
tecniche/strategie
di progettazione
TOP - DOWN
si parte da uno schema astratto e si arriva ad uno più dettagliato (impresa formativa simulata - ramificazione)
BOTTOM - UP
le specifiche sono sviluppate in specifici schemi dettagliati e vengono integrati tra loro (ufficio clienti - capo ufficio clienti - ...)
INSIDE - OUT
si sviluppa a spirale partendo dai concetti più importanti e aggiungendo quelli correlati
FASE 2:
CONCETTUALE
CORRETTEZZA
uso corretto degli strumenti
COMPLETEZZA
tutti gli aspetti rilevanti della realtà devono essere modellati
CHIAREZZA
il modello deve essere leggibile e comprensibile a tutti
INDIPENDENZA
dallo strumento informatico che verrà utilizzato
FASE 3:
LOGICA
creazione di uno schema secondo
uno dei seguenti modelli:
GENERICO
INIZI ANNI '60
STRUTTURA AD ALBERO
RADICE è il record principale da cui partono i figli (SEGMENTI)
relazione UNO-A-MOLTI (1:N)
ogni padre può avere molti figli, ma ogni figlio può avere un solo padre
SVANTAGGI
tra lo schema logico e quello fisica esiste una dipendenza stretta e vincolante
operazioni di ricerca non sono efficienti
RETICOLARE
FINE ANNI '60
STRUTTURA A GRAFO
MEDIANTE PUNTATORI
evoluzione del modello gerarchico ogni nodo è punto di partenza per raggiungere un campo
ogni record può connettersi con altri n-record
relazione multipla MOLTI-A-MOLTI (N:N)
SVANTAGGI
realizzazione di due reticoli indipendenti è necessario duplicare i dati introducendo rindondanza
se dati non sono direttamente connessi tra loro ricerca è difficoltosa
link realizzati con puntatori = spreco di spazio per memorie esterne
estremamente rigido in caso di modifiche successive alla creazione
RELAZIONALE
Sviluppato da Edgar Frank Codd
all'inizio degli anni '70
pubblica articolo "modello per l'archiviazione di grandi banche di dati" dove struttura attraverso TABELLE e RELAZIONI
AD OGGETTI
anni '80
paradigma "Object-Oriented"
nuova frontiera nella ricerca sui data base, hanno la possibilità di definire tipi di dati e comportamenti nella classe stessa
OODBMS
Object Oriented DBMS
Jasmine (asviluppato dalla Fujitsu fine anni '90)
ORDBMS
Object Relational DBMS
PostgreSQL (sviluppato in Clifornia & completamente gratuito)
XML(Extensible Markup Language)
anni '90
non è proprio un modello di DB, utilizza un linguaggio di markup
è possibile definire dei TAG rispetto alle proprie esigenze: ha una struttura gerarchica
NoSql
raggruppano una famiglia di approcci ibridi nel tentativo di superare la rigidità del modello relazionale e migliorare la scalabilità della gestione di dati
schema fisso delle tabelle (prima nome, poi elenco dei campi,...)
presenza di una relazione tra due o più campi di tabelle
utilizzo di tabelle e campi per memorizzare i dati
accesso ai dati (transizione) garantito con le proprietà ACID
(Atomicità, Consistenza, Isolamento e Durabilità)
ESEMPI di maggior successo
Mongo DB
Redis, Memcached, HBase
Neo4j
Cassandra, Big Table, SImple DB
Firebase
MODELLAZIONE FUNZIONALE
FASI 4 - 5
MODELLAZIONE DI DATI
FASI 1 - 2 - 3
consiste in una rappresentazione astratta delle strutture dei dati di DB e serve per tradurre i dati dal punto di vista dell'utente al punto di vista dell'applicazione (trasportarli nel mondo reale al mondo informatico)
vitali laura