La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

Reverse Engineering di una base dati. Reverse Engineering di una base dati Pag. 2 ©Contenuti m Introduzione e scenario di riferimento m La progettazione.

Presentazioni simili


Presentazione sul tema: "Reverse Engineering di una base dati. Reverse Engineering di una base dati Pag. 2 ©Contenuti m Introduzione e scenario di riferimento m La progettazione."— Transcript della presentazione:

1 Reverse Engineering di una base dati

2 Reverse Engineering di una base dati Pag. 2 ©Contenuti m Introduzione e scenario di riferimento m La progettazione delle basi dati m Dallo schema logico allo schema concettuale q Assegnare nomi significativi agli oggetti q Normalizzare e rimuovere i dati tecnici q Determinare le chiavi e le associazioni q Definire le gerarchie di specializzazione/generalizzazione q Integrare le entità q Documentare il modello concettuale m Mapping schema concettuale / schema logico-fisico m Approccio misto alle attività di R.E. m Produzione di uno schema di sintesi m DallE/R al modello delle classi m Glossario

3 Reverse Engineering di una base dati Pag. 3 ©Introduzione m Il Reverse Engineering è un insieme di tecniche e di strumenti che consentono di : q analizzare il software esistente q derivarne in automatico la documentazione q modificarne l'impostazione q rigenerare il codice (Forward Engineering) m In particolare, a riguardo della componente dati di un sistema, è possibile, tramite il reverse engineering, derivare le strutture concettuali dei dati a partire da DDL o copy di tracciati record di archivi esistenti m Ciò consente di fornire una rappresentazione concettuale delle informazioni del sistema esistente, che può essere utilizzata come base di partenza per la ri-progettazione (re-engineering)

4 Reverse Engineering di una base dati Pag. 4 ©Scenario m Questa presentazione riporta un esempio di come si procede per un reverse engineering della componente dati di unapplicazione m Esiste una base dati relazionale (es: DB2 o Oracle) non documentata e si vuole ottenere come risultato uno schema concettuale dei dati e tutta la documentazione necessaria per: q capire il significato delle informazioni q poter effettuare agevolmente la manutenzione della base dati q evidenziare eventuali criticità rilevate sul modello q individuare interventi di miglioramento, analizzando limpatto su quanto già realizzato. m Le attività da eseguire sono le seguenti: q analisi del DDL q derivazione dal DDL dello schema logico finale q produzione dello schema concettuale (per il significato dei diversi tipi di schema vedere più avanti)

5 Reverse Engineering di una base dati Pag. 5 © Scenario … m Alcune attività possono essere effettuate in modo meccanico con il supporto di un tool adeguato: è possibile ad esempio derivare in modo automatico dal DDL uno schema logico-fisico dei dati m Ottenuto lo schema logico (un diagramma delle tabelle e dei loro legami), si tratta di astrarre da questo uno schema concettuale dei dati, indipendente dal DBMS e dallambiente tecnologico utilizzati. E qui iniziano le vere difficoltà, lattività può essere assai critica, in quanto richiede una profonda conoscenza del significato e del dominio dei dati e unanalisi attenta a risolvere problemi di omonimia e sinonimia a tutti i livelli (entità, attributi, relationship) m Per condurre tale attività sarà probabilmente necessario: q coinvolgere le persone che hanno partecipato alla progettazione della base dati attuale o altre persone esperte del dominio applicativo q analizzare il codice applicativo al fine di ricavare altre informazioni non dichiarate esplicitamente nella base dati, quali valori dei domini, regole di integrità dei dati, ecc…

6 Reverse Engineering di una base dati Pag. 6 © La progettazione delle basi dati m La progettazione delle basi dati si articola nelle seguenti fasi operative: q progettazione concettuale q progettazione logica q progettazione fisica m Ogni fase produce un risultato finale che viene detto schema, così come evidenziato nella seguente tabella: FaseRisultato progettazione concettualeschema concettuale progettazione logicaschema logico progettazione fisicaschema fisico

7 Reverse Engineering di una base dati Pag. 7 © La progettazione concettuale m La progettazione concettuale ha lobiettivo di tradurre i requisiti espressi dal cliente in una descrizione formale delle informazioni necessarie al sistema m Tale descrizione è detta schema concettuale, in quanto: q è indipendente dalle caratteristiche di ogni specifico DBMS q la sua strutturazione dipende esclusivamente dai legami di significato che esistono tra le varie informazioni in esso contenute, non da criteri di efficienza

8 Reverse Engineering di una base dati Pag. 8 © La progettazione logica m La progettazione logica ha lobiettivo di trasformare lo schema concettuale in uno schema logico (iniziale) conforme alle strutture proprie del DBMS scelto per la realizzazione (es: schema logico gerarchico, relazionale, ecc…) m La trasformazione in un modello logico relazionale si basa sulle seguenti regole: q ogni entità viene trasformata in una tabella q ogni attributo diventa una colonna q per ogni relationship uno-a-molti, la chiave primaria dellentità con il verso a uno viene riportata come chiave esterna in quella con il verso a molti q per ogni relationship molti-a-molti viene creata una tabella associativa, che ha come chiave primaria la concatenazione delle chiavi primarie delle entità coinvolte nellassociazione

9 Reverse Engineering di una base dati Pag. 9 © La progettazione logica … m Normalmente, non è sufficiente effettuare una semplice traduzione. Lo schema logico deve essere ottimizzato, per consentire prestazioni adeguate ai sistemi che operano sui dati m A tale scopo possono essere introdotte nello schema modifiche quali: scomposizioni, denormalizzazioni, ecc… m La trasformazione dà luogo alle strutture dati definitive (es: tabelle, file, …) dello schema logico finale

10 Reverse Engineering di una base dati Pag. 10 © La progettazione delle basi dati – differenze metodologiche m In alcune metodologie la progettazione fisica non è distinta da quella logica, quindi le fasi si riducono a due: q progettazione concettuale q progettazione logico-fisica. m Anche la terminologia può cambiare: si parla di modello logico in luogo di modello concettuale e di modello fisico per quello logico- fisico (ad es. è questo lapproccio di alcuni tool di modellazione dati, quali Erwin, che distinguono tra un logical model e un physical model) m E invece comune a tutte le metodologie la netta distinzione tra la fase di modellazione (o progettazione) concettuale e le restanti fasi

11 Reverse Engineering di una base dati Pag. 11 © La progettazione logico-fisica m La progettazione fisica ha lobiettivo di completare lo schema logico con i parametri fisici di memorizzazione e di ricerca dei dati (indici, tablespace, …) tenendo conto delle caratteristiche del DBMS e dellambiente hardware e software in cui la base dati sarà realizzata. m Il risultato finale di questa fase è lo schema fisico

12 Reverse Engineering di una base dati Pag. 12 © Dallo schema logico-fisico allo schema concettuale m Astrarre un modello concettuale da un modello logico significa effettuare una serie di attività: q assegnare nomi significativi agli oggetti q normalizzare lo schema e rimuovere i dati tecnici q determinare le chiavi candidate (chiavi primarie e chiavi alternative) q determinare le associazioni (relationship) tra le entità q definire eventuali gerarchie di specializzazione / generalizzazione q integrare e aggiustare le entità q documentare tutti gli elementi del modello concettuale ottenuto (entità, attributi, ecc…) m Normalmente queste attività non sono svolte in maniera rigidamente sequenziale: si procede in modo iterativo (per aggiustamenti successivi)

13 Reverse Engineering di una base dati Pag. 13 © Assegnare nomi significativi agli oggetti del modello conc. m Spesso la denominazione degli oggetti della base dati segue standard di nomenclatura aziendali, definiti allo scopo di facilitarne limplementazione e la gestione negli specifici DBMS (es. una tabella è denominata TACN0521, …) m Quando si effettua il R.E. è necessario assegnare alle entità, agli attributi e alle relationship individuati un nome significativo, che agevoli la comprensione delle informazioni contenute nel modello concettuale (es: lentità derivata dalla tabella TACN0521, con chiave primaria cod_fornitore è denominata FORNITORE)

14 Reverse Engineering di una base dati Pag. 14 © Normalizzare e rimuovere i dati tecnici m Lattività comporta la rimozione delle ridondanze e, più in generale, di tutte le modifiche introdotte nel modello logico per ottimizzare le prestazioni del sistema e soddisfare i vincoli imposti dallambiente di implementazione m Le modifiche più frequenti apportate al modello logico possono essere: q denormalizzazioni q scomposizioni q introduzione di dati di natura tecnica

15 Reverse Engineering di una base dati Pag. 15 ©Denormalizzazioni m Con la tecnica di denormalizzazione si procede in maniera inversa rispetto alla normalizzazione m La normalizzazione dello schema concettuale ha lo scopo di ridurre la ridondanza dei dati e prevenire le anomalie che questa comporta per le operazioni di aggiornamento m La denormalizzazione consiste nellintrodurre alcune ridondanze nello schema logico con lobiettivo di ridurre il numero delle operazioni di I/O richieste per reperire i dati necessari

16 Reverse Engineering di una base dati Pag. 16 © Denormalizzazioni – attributi ridondanti Lattributo rag_soc_forn nella tabella Ordine è da eliminare dallo schema concettuale, in quanto ridondante

17 Reverse Engineering di una base dati Pag. 17 © Denormalizzazioni – indicatori Grazie allindicatore ind_presenza_richieste non è necessario accedere alla tabella Richieste_Servizi per verificare se esistono o meno richieste a fronte di un determinato servizio. Lindicatore può essere utile in ottica di ottimizzazione degli accessi, ma è ridondante e quindi da eliminare dallo schema concettuale Gli indicatori servono a segnalare un preciso evento o una condizione eliminando la necessità di eseguirne una verifica, accedendo ai dati di unaltra tabella

18 Reverse Engineering di una base dati Pag. 18 © Denormalizzazioni – attributi derivati m Lattributo num_tot_dipendenti riporta il numero totale dei dipendenti di un reparto evitando la necessità di effettuare gli accessi atti a recuperare i valori elementari (in questo caso una lettura dellintera tabella Dipendenti) m Attenzione: secondo unopinione diffusa, gli attributi derivati non dovrebbero essere presenti nel modello concettuale, in quanto ne comprometterebbero lessenzialità. Nel caso siano particolarmente rilevanti per il business, possono essere inseriti, ma è importante esplicitarne le regole di derivazione Gli attributi derivati sono attributi il cui valore è ricavato dal valore di altri attributi, ad esempio applicando algoritmi di calcolo

19 Reverse Engineering di una base dati Pag. 19 © Denormalizzazioni – vettori Questa tecnica è utilizzata quando si è in presenza di dati ripetitivi (es: dati mensili, …), con un numero di occorrenze predefinito, che sono spesso acceduti insieme dalle applicazioni Normalizzando la struttura si ottiene lentità:

20 Reverse Engineering di una base dati Pag. 20 © Denormalizzazioni – entità di decodifica La normalizzazione della struttura produce lo schema che segue, in cui compaiono le due entità di decodifica: Tipo_Fornitura e Tipo_Contratto

21 Reverse Engineering di una base dati Pag. 21 ©Scomposizioni m Con la tecnica di scomposizione si separa il contenuto di unentità in due o più tabelle m Lobiettivo è quello di ottimizzare le prestazioni, riducendo le dimensioni delle tabelle ottenute quando il numero delle righe e/o la dimensione della riga siano molto elevati m Spesso si effettua tale partizionamento quando lutilizzo dei dati non è omogeneo, ad esempio quando alcuni dati sono acceduti meno frequentemente di altri

22 Reverse Engineering di una base dati Pag. 22 © Scomposizione verticale Operando in modo inverso alla scomposizione, le due tabelle saranno ricomposte nel modello concettuale in ununica entità: In questo tipo di scomposizione la struttura dati originaria è suddivisa in modo da separare alcune colonne in una tabella e altre in unaltra tabella. Le due tabelle hanno la stessa chiave primaria.

23 Reverse Engineering di una base dati Pag. 23 © Scomposizione orizzontale In questo caso le righe dellentità Ordine sono separate in due tabelle diverse in base al loro stato: da un lato gli ordini da evadere, dallaltro gli ordini evasi. Nel modello concettuale le due strutture andranno integrate in ununica entità: La scomposizione orizzontale opera a livello di riga; in base a determinate condizioni alcune righe andranno a finire in una tabella, altre righe in unaltra tabella.

24 Reverse Engineering di una base dati Pag. 24 © Introduzione di dati di natura tecnica m Spesso nel modello logico sono introdotti dati di natura tecnica, che non sono rilevanti per il modello concettuale, ad esempio attributi per gestire informazioni di audit, quali: cod_ user_ultima_modifica, timestamp_ultima_modifica, ecc … m In alcuni casi sono introdotte tabelle di appoggio per memorizzare il risultato di qualche processo elaborativo in modo temporaneo (ad es. il contenuto può essere cancellato a fine giornata). Se tali tabelle non contengono informazioni proprie, ma dati ricavati da altre entità del modello, non andranno rappresentate come entità nel modello concettuale.

25 Reverse Engineering di una base dati Pag. 25 © Determinare le chiavi candidate m Può accadere che le chiavi primarie non siano state definite per tutte le tabelle m Occorre esaminare gli attributi (e i sottostanti domini) per stabilire quali di essi possono essere utilizzati come chiavi primarie o chiavi alternative m La presenza di indici univoci indica la presenza di chiavi candidate

26 Reverse Engineering di una base dati Pag. 26 © Determinare le associazioni m Lattività considera lesistenza di legami tra le entità, ancorché non implementati nel DBMS m Si esaminano gli attributi (e i sottostanti domini) per stabilire quali di essi sono utilizzati per riferimenti ad altre tabelle. Tali attributi sono foreign key potenziali m Si introducono quindi nel modello le nuove relationship, avendo cura di non introdurre relationship transitive (ridondanti) m Lattività potrebbe richiedere unanalisi del codice applicativo che implementa i controlli di integrità referenziale

27 Reverse Engineering di una base dati Pag. 27 © Integrare e aggiustare le entità m Non è raro che nello schema risultato di un primo R.E. siano presenti più entità identiche o simili. Le ragioni possono essere diverse: una tabella è la replica totale o parziale di unaltra, le tabelle sono state introdotte da gruppi di lavoro diverso per puro errore, le tabelle provengono da due schemi non ancora integrati, ecc… m Occorre determinare se le entità simili possono essere combinate in ununica entità

28 Reverse Engineering di una base dati Pag. 28 © Integrare e aggiustare le entità … m Sono sintomi di possibile identità: il nome delle entità è simile o uguale il nome degli attributi che formano la chiave primaria delle due entità è uguale i domini degli attributi che formano la chiave primaria delle due entità sono uguali la chiave primaria di unentità è chiave alternativa nellaltra entità m La verifica di identità va condotta analizzando: il significato delle entità in esame i domini delle loro chiavi primarie modalità e tempi di inserimento e cancellazione

29 Reverse Engineering di una base dati Pag. 29 © Integrare e aggiustare le entità … m Se si verifica uneffettiva coincidenza, le due entità possono essere unificate. La nuova entità risultante riceverà: il nome nella dizione più in generale una chiave primaria (derivata eventualmente dalla scelta tra le chiavi alternative) tutti gli attributi delle entità originarie, denominati secondo la dizione più generale tutte le relationship in cui erano coinvolte le entità originarie, denominate secondo la dizione più generale m Lunificazione di due entità può provocare anomalie: necessità di normalizzare lentità risultante possibilità di introdurre relationship transitive (ridondanti), che andranno eliminate dallo schema concettuale

30 Reverse Engineering di una base dati Pag. 30 © Integrare e aggiustare le entità … Esempio 1 Integrando insieme le due entità, Customer e Clienti, lentità risultante, Clienti, deve essere ulteriormente normalizzata Dopo lintegrazione e la normalizzazione, nello schema concettuale otteniamo:

31 Reverse Engineering di una base dati Pag. 31 © Integrare e aggiustare le entità … Esempio 2 Supponiamo di dover integrare i due schemi: Nello schema integrato compare una relationship transitiva (ridondante perché dato un dipendente è possibile conoscere la società a cui appartiene per il tramite del reparto di cui fa parte). La relationship andrà eliminata dallo schema finale.

32 Reverse Engineering di una base dati Pag. 32 © Definire le gerarchie di specializzazione m Si esaminano le entità con attributi simili per stabilire se conviene definire unentità più generale (supertipo), in cui raccogliere gli attributi comuni alle entità (sottotipo) e creare una gerarchia IS_A (detta anche gerarchia di generalizzazione / specializzazione) tra le entità m La nuova entità risultante riceverà : una chiave primaria (derivata eventualmente dalla scelta tra le chiavi alternative) tutti gli attributi comuni alle entità sottotipo, denominati secondo la dizione più generale tutte le relationship comuni in cui erano coinvolte le entità sottotipo, denominate secondo la dizione più generale m Ovviamente dalle entità sottotipo saranno rimossi attributi e relationship comuni

33 Reverse Engineering di una base dati Pag. 33 © Definire le gerarchie di specializzazione … Si deve verificare se unentità può considerarsi sottotipo oppure supertipo di unaltra entità già presente nel modello ed evidenziare la gerarchia IS_A:

34 Reverse Engineering di una base dati Pag. 34 © Definire le gerarchie di specializzazione … Si deve verificare se unentità non sia da partizionare: la presenza di un attributo definitore (es.: tipo_cliente, tipo_contratto, …) e/o una serie di attributi inapplicabili a seconda della tipologia, può indicare lesistenza di una gerarchia IS_A In questo esempio, gli attributi nome_cliente, cognome_cliente, cod_sesso, non sono applicabili per le persone giuridiche: è opportuno evidenziare la specializzazione (gerarchia IS_A):

35 Reverse Engineering di una base dati Pag. 35 © Definire le gerarchie di specializzazione … Possono esistere due o più entità che sono simili in termini di attributi e significato. Le entità potrebbero costituire sottotipi di un supertipo non ancora definito E possibile evidenziare la seguente gerarchia IS_A:

36 Reverse Engineering di una base dati Pag. 36 © Mapping tra gli schemi concettuale e logico-fisico m Una volta ottenuto lo schema concettuale dei dati è importante documentare il mapping (la corrispondenza) tra gli oggetti dello schema concettuale e quelli presenti nello schema logico-fisico. m In altre parole è necessario documentare: a fronte di ogni tabella, lentità da cui è derivata a fronte di ogni colonna, lattributo o la relationship (nel caso di chiave esterna) che lha originata m Nel caso in cui lo schema logico-fisico è il risultato di denormalizzazioni o scomposizioni, si potranno verificare situazioni in cui: una tabella corrisponde a più entità (denormalizzazione) più tabelle corrispondono ad ununica entità (scomposizione) una colonna non fa riferimento a nessun attributo specifico dello schema concettuale, perché si tratta di una dato derivato (es: imp_totale_ordine) o un dato di natura tecnica (es: timestamp_ultimo_inserimento)

37 Reverse Engineering di una base dati Pag. 37 © Mapping tra gli schemi concettuale e logico-fisico … m Occorre documentare e mantenere aggiornato il mapping (la tracciabilità) tra le strutture concettuali e le corrispondenti strutture logiche, allo scopo di facilitare le attività di manutenzione m Grazie al mapping è possibile: m conoscere su quali oggetti fisici intervenire a fronte di una modifica allo schema concettuale (ad es. la modifica di unentità su quali tabelle ha impatto?) m effettuare unimpact analysis, valutando costi, tempi e difficoltà dellintervento di modifica

38 Reverse Engineering di una base dati Pag. 38 © Mapping tra gli schemi concettuale e logico-fisico … m E importante, inoltre, documentare ogni modifica evidenziata a livello dello schema logico-fisico rispetto allo schema concettuale, fornendo, dove possibile, unopportuna motivazione della scelta (ad es. il motivo per cui unentità è stata scomposta in due tabelle, o il perché di un attributo ridondante, ecc…) m Conoscere le motivazioni delle scelte effettuate, ci permette di intervenire in modo adeguato e rivedere tali scelte nel caso in cui cambino le premesse (vincoli dellambiente di implementazione, modalità di accesso alle informazioni, …)

39 Reverse Engineering di una base dati Pag. 39 © Approccio misto alle attività di R.E. m Lapproccio fin qui seguito è tipicamente bottom-up. A partire dagli elementi fisici (tabelle definite nel DDL) si ricava una rappresentazione ad un più alto livello di astrazione (lo schema concettuale dei dati), in parte attraverso attività meccaniche, effettuabili con il supporto di un tool, e in parte applicando meccanismi di astrazione e la normalizzazione m E possibile comunque adottare un approccio misto: partire con un approccio top-down, producendo dapprima una bozza del modello concettuale, applicando i meccanismi di astrazione classici dellanalisi dati. Ovviamente è possibile procedere in questo modo se è disponibile una conoscenza del dominio del problema (conoscenza diretta o acquisibile attraverso interviste agli esperti del problema, lanalisi della documentazione esistente, …) m Il modello prodotto dovrà essere confrontato ed opportunamente rivisto alla luce dei risultati del R.E. condotto in modo canonico (bottom-up)

40 Reverse Engineering di una base dati Pag. 40 © Approccio misto alle attività di R.E. m I vantaggi di un approccio misto possono essere così riassunti: q è possibile acquisire fin da subito una conoscenza ad alto livello delle informazioni e delimitare in modo opportuno il contesto dellanalisi q è possibile suddividere il dominio del problema, identificando sotto-insiemi logici in cui ripartire lapplicazione (se non è già presente una ripartizione di questo tipo) ed assegnare ad ogni sotto-insieme le entità e le corrispondenti tabelle q è possibile individuare più facilmente criticità, evidenziando gli scostamenti tra quanto fisicamente realizzato e quanto modellato inizialmente

41 Reverse Engineering di una base dati Pag. 41 © Produzione di uno schema concettuale di sintesi m Nel caso in cui lobiettivo sia un re-engineering dellapplicazione e il Reverse Engineering sia condotto più allo scopo di comprendere le informazioni principali del sistema che di documentare in modo dettagliato lesistente, ci si può fermare ad individuare gli oggetti di business e le loro proprietà principali (soprattutto nel caso in cui il sistema attuale dovrà essere ampiamente modificato) m In questottica, se le entità desunte dalla basi dati, sono molto numerose, può essere conveniente produrre uno schema concettuale di sintesi, più facilmente consultabile rispetto ad uno schema concettuale analitico

42 Reverse Engineering di una base dati Pag. 42 © Produzione di uno schema concettuale di sintesi … m Lo schema concettuale di sintesi ha caratteristiche profondamente diverse rispetto ad un normale (analitico) schema concettuale: le entità vengono aggregate in macroentità, con conseguente diminuzione del numero di relationship sono evidenziati solo gli attributi rilevanti m Lobiettivo è quello di rendere più agevole la consultazione, non di definire i dati e i relativi vincoli in modo esaustivo m Per aggregare le entità analitiche in macroentità è possibile utilizzare i seguenti criteri: aggregare le gerarchie di spec / gen (IS_A) in una macroentità aggregare le entità di decodifica nellentità a cui sono collegate aggregare le entità attributive allentità fondamentale a cui sono collegate

43 Reverse Engineering di una base dati Pag. 43 © Produzione di uno schema concettuale di sintesi … Aggregare le gerarchie di specializzazione / generalizzazione (IS_A) in una macroentità costituita dal solo supertipo:

44 Reverse Engineering di una base dati Pag. 44 © Produzione di uno schema concettuale di sintesi … Aggregare le entità di decodifica che hanno ununica relationship nellambito delle entità a cui sono collegate

45 Reverse Engineering di una base dati Pag. 45 © Produzione di uno schema concettuale di sintesi … Aggregare le entità attributive allentità fondamentale a cui sono collegate

46 Reverse Engineering di una base dati Pag. 46 © DallE/R al modello delle classi m Dallo schema concettuale, espresso in forma di Entity / Relationship è possibile derivare senza difficoltà il diagramma delle classi di oggetti (ovviamente solo la componente attributi delle classi) m Il modello Object Oriented è più ricco dal punto di vista semantico rispetto allE/R: normalmente questultimo non prevede tutti i meccanismi di astrazione del modello OO, quali ad esempio laggregazione (IS_PART_OF); è bene sfruttare tutte le potenzialità del modello OO per esprimere i vincoli sui dati

47 Reverse Engineering di una base dati Pag. 47 © DallE/R al modello delle classi …

48 Reverse Engineering di una base dati Pag. 48 © DallE/R al modello delle classi …

49 Reverse Engineering di una base dati Pag. 49 ©Glossario Aggregazione E il meccanismo per la costruzione di oggetti complessi aggregando oggetti componenti più semplici (es. un ordine è un oggetto complesso costituito dalle righe ordine). Esprime una relazione IS_PART_OF tra una parte e il tutto. Chiave candidata Si indica come chiave candidata di un'entità ogni attributo o insieme di attributi che permette di identificarne univocamente le occorrenze Se le chiavi candidate di unentità sono più d'una, una di esse viene assunta come chiave privarimaria, quelle restanti sono dette chiavi alternative Es: lentità CLIENTE ha come chiave primaria lattributo codice cliente, come chiave alternativa il codice fiscale DDL Data Definition Language. Linguaggio di definizione dei dati, messo a disposizione dai DBMS. Mapping Corrispondenza tra gli elementi di un certo livello di astrazione e quelli di un altro livello; es. corrispondenza tra una specifica entità del modello concettuale dei dati e la tabella o le tabelle in cui è implementata. Normalizzazione Tecnica del modello relazionale, che serve a semplificare le strutture dei dati, eliminandone le ridondanze. Si possono ottenere più livelli di normalizzazione, chiamati forme normali. Dominio E un insieme di valori di significato omogeneo. Es: sigle delle province italiane, codici avviamento postale, codici società, …


Scaricare ppt "Reverse Engineering di una base dati. Reverse Engineering di una base dati Pag. 2 ©Contenuti m Introduzione e scenario di riferimento m La progettazione."

Presentazioni simili


Annunci Google