1 / 241

Basi di Dati Relazionali ad Oggetti

Basi di Dati Relazionali ad Oggetti. RDBMS: panorama attuale. Gestiscono e manipolano dati semplici (tabellari) Hanno un linguaggio di interrogazione (SQL) semplice, dichiarativo e standard

topper
Download Presentation

Basi di Dati Relazionali ad Oggetti

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Basi di Dati Relazionali ad Oggetti

  2. RDBMS: panorama attuale • Gestiscono e manipolano dati semplici (tabellari) • Hanno un linguaggio di interrogazione (SQL) semplice, dichiarativo e standard • Tool consolidati per lo sviluppo di applicazioni (Oracle Developer, Sybase Power Builder, Microsoft Visual Basic)

  3. RDBMS: panorama attuale • Portabili su diverse piattaforme • Esempi di RDBMS: IBM DB2, Oracle, Sybase, Informix, Microsoft SQL Server • Buone prestazioni • Affidabilità, gestione transazioni • Basati su una architettura client-server supportano efficientemente un gran numero di utenti • Forniscono meccanismi di controllo dell’accesso

  4. RDBMS: panorama attuale • Oggi il mercato mondiale dei RDBMS supera i 50 billioni di dollari all’anno, ma… i RDBMS presentano anche alcuni limiti

  5. RDBMS: problemi • Prevalentemente connessi alle caratteristiche intrinseche del modello relazionale: • SQL-92 fornisce solo un insieme limitato di tipi di dato • le tabelle hanno una struttura flat e non forniscono un buon supporto per strutture annidate, quali insiemi ed array • non è possibile definire relazioni di sotto-tipo tra gli oggetti di un database

  6. RDBMS: problemi • Le associazioni tra entità vengono modellate per valore e questo nel caso di associazioni complesse può richiedere la creazione di parecchie tabelle/colonne “fittizie” • Gli RDBMS non sfruttano gli approcci object-oriented per la progettazione e realizzazione di software che oggi stanno diventando pressochè uno standard

  7. OODBMS: panorama attuale • Permettono di modellare direttamente oggetti complessi e le loro associazioni • Object-orientation sempre più diffuso in ambito software engineering e programmazione: unicità del paradigma • Buone prestazioni per applicazioni navigazionali • Limitato supporto per concorrenza, parallelismo e distribuzione

  8. OODBMS: panorama attuale • Semplici modelli transazionali • Limitate funzionalità di controllo dell’accesso • Coprono un mercato di nicchia che richiede accessi navigazionali efficienti (disegno di chip, ecc.)

  9. OODBMS: problemi • Il progetto del database è strettamente legato al progetto delle applicazioni • Mancanza di un modello dei dati e di un linguaggio di query standard pienamente accettati • Mancanza di un linguaggio di query dichiarativo (SQL-like)

  10. RDBMS vs. OODBMS • RDBMS forniscono un supporto efficiente ed efficace per applicazioni che manipolano dati semplici • OODBMS forniscono un supporto efficiente per alcune classi di applicazioni su dati complessi, ma senza molti degli aspetti positivi dei RDBMS

  11. Il modello relazionale ad oggetti • I DBMS relazionali ad oggetti (object-relational) nascono dall’esigenza di assicurare le funzionalità dei RDBMS rispetto alla gestione di dati tradizionali, estendendo il modello dei dati con la possibilità di gestire dati complessi tipica degli OODBMS

  12. ORDBMS: caratteristiche generali • Nuovi tipi di dato: • testi, immagini, audio/video, dati geografici, ecc. • tipi di dato user-defined • tipi collezione • Metodi per modellare le operazioni sui tipi definiti dall'utente (es. Java, C) • Nuovi modi per modellare le associazioni

  13. ORDBMS: caratteristiche generali • La filosofia per la gestione dei dati è però ancora quella relazionale: • Tutti gli accessi ai dati avvengono tramite SQL • Tutti le entità di interesse sono modellate tramite tabelle

  14. ORDBMS: panorama attuale • Oggi quasi tutti i principali produttori di RDBMS (Oracle, Informix, DB2,..) hanno esteso i loro DBMS con caratteristiche object-relational • Tali estensioni presuppongono anche una estensione del linguaggio SQL • Allo stato attuale ogni RDBMS ha un’estensione proprietaria object-relational

  15. ORDBMS: panorama attuale • Le estensioni differiscono per: • Le funzionalità che supportano • Il modo di realizzarle • Le estensioni apportate ad SQL • E questo nonostante SQL-99 ...

  16. Lo standard SQL-99 • SQL-99 è un tentativo di standardizzazione dell’estensione object-relational del modello relazionale • Al momento della definizione di SQL-99 i maggiori produttori di RDBMS avevano già la loro versione delle estensioni object-relational • SQL-99 non standardizza tutte le funzionalità object-relational presenti nei DBMS commerciali

  17. Lo standard SQL-99 • E’ quindi ancora presto per capire quando e in che misura lo standard sarà recepito a livello commerciale • La sensazione è che sarà necessario un ulteriore standard che medi tra tutte le estensioni proprietarie

  18. Nel seguito … • Discutere le caratteristiche generali di un ORDBMS • discuteremo come queste caratteristiche vengono gestite dallo standard • se non altrimenti specificato, utilizzeremo la sintassi di SQL-99 • introdurremo le caratteristiche relazionali ad oggetti di Oracle

  19. Estensione del sistema di tipi

  20. Sistema dei tipi in SQL92 • In SQL-92 i tipi di un attributo in una relazione possono essere: • numerici (interi, reali, ecc.) • carattere (stringhe di lunghezza fissa o variabile, caratteri singoli) • temporali (date, time, datetime, interval) • booleani (true, false) • non strutturati (BYTE, TEXT, BLOB, CLOB)

  21. Sistema dei tipi in SQL92 • Per ogni tipo built-in esistono un insieme fisso e predefinito di operazioni che su di esso possono essere eseguite • Queste limitazioni rendono spesso difficile la rappresentazione di dati reali

  22. Estensione del sistema di tipi • Tipi semplici • Abstract data types • User-defined types • Tipi riferimento • Tipi complessi: • tipi record e tipi collezione

  23. Tipi semplici • I tipi semplici (o distinct type) sono la forma più semplice di estensione del sistema dei tipi fornita da un ORDBMS • Consentono agli utenti di creare nuovi tipi di dati, basati su un solo tipo (built-in o user-defined)

  24. Tipi semplici • Sono usati per definire tipi di dati che richiedono operazioni diverse rispetto al tipo su cui sono definiti • I tipi semplici sono considerati dal DBMS totalmente distinti dal tipo su cui si basano • I valori del tipo semplice non sono direttamente confrontabili con quelli del tipo su cui si basano (strong typing)

  25. Tipi semplici • Confronti con il tipo base o con altri tipi semplici definiti sullo stesso tipo base richiedono operazioni di cast • l’ORDBMS crea automaticamente una funzione di cast quando un nuovo tipo semplice viene creato • Non è fornito alcun meccanismo di ereditarietà e subtyping per i tipi semplici

  26. Esempio • Si supponga di creare un nuovo tipo id_impiegato basato sul tipo intero • Come il tipo intero, id_impiegato è utilizzato per memorizzare valori numerici ma il DBMS tratterà i due tipi come tipi distinti • Per i due tipi possono essere definite operazioni diverse (ad esempio la somma di due identificatori non ha senso, mentre potrebbe essere utile una operazione di confronto)

  27. Tipi semplici in SQL-99 • SQL-99 consente di definire tipi semplici basati solo su tipi built-in CREATE TYPE <name> AS <built-in type> FINAL • Vedremo in seguito il significato della clausola FINAL

  28. Esempio CREATE TYPE id_impiegato AS INTEGER FINAL; CREATE TABLE Impiegati( id id_impiegato, nome VARCHAR(50), età INTEGER, id_manager id_impiegato);

  29. Casting • I valori dei distinct type sono considerati come distinti dai valori del tipo di base • il casting non è automatico • le funzioni di cast (se necessarie) vanno implementate esplicitamente, eventualmente direttamente dal sistema

  30. Esempio - assegnazione SELECT nome FROM Impiegati WHERE id_manager = 123; errore

  31. Esempio - confronto CREATE TYPE Euro AS Decimal(8,2) FINAL; CREATE TYPE Dollaro_USA AS Decimal(8,2) FINAL; CREATE TABLE Vendite_Europee( n_cliente INTEGER, n_ordine INTEGER, totale Euro); CREATE TABLE Vendite_USA( n_cliente INTEGER, n_ordine INTEGER, totale Dollaro_USA);

  32. Esempio: confronto SELECT n_cliente,n_ordine FROM Vendite_Europee ERP, Vendite_USA USA WHERE ERP.n_ordine = USA.n_ordine AND ERP.totale > USA.totale; errore!!!

  33. Casting in SQL-99 • Il DBMS definisce due funzioni di casting per ogni nuovo tipo semplice: • una per passare dal distinct type al tipo built-in • una per passare dal tipo built-in al distinct type

  34. Funzioni di casting in SQL-99 CREATE CAST (<source type> AS <target type>) WITH <segnatura funzione> [AS ASSIGNMENT] • <source type>: tipo input • <target type>: tipo output • almeno uno tra <source type> e <target type> deve essere un tipo definito dall’utente • l’altro può essere un tipo qualunque

  35. Funzioni di casting in SQL-99 • <segnatura funzione> è la segnatura di una qualunque funzione • la funzione deve essere definita come segue: FUNCTION <name> (<source type>) RETURNS <target type> … codice ...

  36. Funzioni di casting in SQL-99 • Se la clausola AS ASSIGNMENT è specificata, il casting è invocato implicitamente quando necessario • per ogni coppia di tipi può esistere una sola funzione di casting definita dall’utente

  37. Funzioni di casting in SQL-99 • Le funzioni di casting per i tipi semplici vengano create automaticamento dal sistema con la clausola AS ASSIGNMENT

  38. Casting in SQL-99 • La funzione di casting può essere invocata: • esplicitamente CAST(<source type> as <target type>) • implicitamente, senza invocare la funzione CAST • la stessa funzione può essere invocata per casting su tipi built-in (esempio: integer in real)

  39. Esempio SELECT nome FROM Impiegati WHERE id_manager = CAST(123 AS id_impiegato); SELECT nome FROM Impiegati WHERE id_manager = 123;

  40. Esempio SELECT n_cliente,n_ordine FROM Vendite_Europee ERP, Vendite_USA USA WHERE ERP.n_ordine = USA.n_ordine AND CAST(ERP.totale AS Decimal(8,2) > CAST(USA.totale AS Decimal(8,2));

  41. Esempio - alternativa • Per passare da Euro a Dollaro_USA posso anche definire una nuova funzione di cast CREATE FUNCTION f(e Euro) RETURNS Dollaro_USA BEGIN DECLARE g DECIMAL(8,2); SET g = e; RETURN g; END; CREATE CAST(Euro AS Dollaro_USA) WITH FUNCTION f(Euro);

  42. ADT • Un abstract data type include: • uno o più attributi • uno o più metodi

  43. ADT in SQL-99 • Gli attributi possono essere dichiarati come gli attributi di una tabella • possono usare clausole default • non è possibile specificare vincolo NOT NULL • il tipo può essere instanziabile oppure no • vedremo meglio dopo

  44. ADT in SQL-99 • Se ci sono solo attributi (completeremo in seguito la definizione): CREATE TYPE <nome tipo> AS <lista definizione attributi> [{INSTANTIABLE|NOT INSTANTIABLE}] {FINAL|NOT FINAL} • INSTANTIABLE è il default

  45. Esempio • Si supponga di voler rappresentare l’indirizzo di un impiegato in un RDBMS • Sono possibili due opzioni: • indirizzo: VARCHAR(n) • rappresentare ogni componente dell’indirizzo come un attributo separato

  46. Esempio CREATE TYPE t_indirizzo AS numero_civico INTEGER, via VARCHAR(50), città CHAR(20), stato CHAR(2), cap INTEGER NOT FINAL; t_indirizzo è un tipo complesso i cui attributi hanno tipi predefiniti

  47. ADT • Gli ADT possono anche essere annidati: CREATE TYPE t_impiegato AS id id_impiegato, nome CHAR(20), curriculum TEXT, indirizzo t_indirizzo NOT FINAL;

  48. ADT • Gli ADT possono essere usati come: • tipi di una colonna in una relazione • tipi di una tabella (row type)

  49. ADT come tipo di colonna • Gli ADT possono essere usati come tipi di una colonna di una relazione CREATE TABLE Impiegati ( imp# id_impiegato, nome CHAR(20), curriculum TEXT, indirizzo t_indirizzo);

  50. ADT come tipo di colonna Tabella Impiegati curriculum indirizzo nome imp# numero_civico via città stato cap

More Related