Come decodificare un Modello da un Database o da uno Script

stampa

Come decodificare un Modello da un Database o da uno Script

Reverse engineering è il processo di creazione di un modello di dati da un database o da uno script. Lo strumento di modellazione crea una rappresentazione grafica degli oggetti del database selezionati e delle relazioni tra gli oggetti. Questa rappresentazione grafica può essere un modello logico o fisico.

Nota: è possibile eseguire il reverse engineering solo in un modello vuoto. Non è possibile eseguire il reverse engineering in un modello che contiene oggetti.

Un database può essere decodificato per i seguenti motivi:

  • Per capire come gli oggetti sono correlati tra loro e quindi per costruire su di esso
  • Per dimostrare la struttura del database

Al termine del processo di reverse engineering, è possibile eseguire le seguenti attività:

  • Aggiungere nuovi oggetti database
  • Creare la documentazione di sistema
  • Riprogettare la struttura del database in base alle proprie esigenze

La maggior parte delle informazioni che si esegue il reverse engineering è definita esplicitamente nello schema fisico. Tuttavia, il reverse engineering ricava anche informazioni dallo schema e le incorpora nel modello. Ad esempio, se il DBMS di destinazione supporta le dichiarazioni di chiavi esterne, il processo di reverse engineering deriva le relazioni di identificazione e non identificazione e i nomi dei ruoli predefiniti.

È possibile ricavare tutte le informazioni principali del modello, ad eccezione delle relazioni sottotipo, perché attualmente nessun sistema di gestione database SQL lo supporta. Tuttavia, i database di destinazione variano nella quantità di informazioni del modello di dati logici incluse nello schema fisico. Per questo motivo, i modelli risultanti possono variare a seconda del database di destinazione selezionato. È inoltre possibile dedurre alcune informazioni logiche tra cui chiavi primarie, chiavi esterne e relazioni di tabella. È possibile utilizzare le definizioni di indice di tabella o i nomi di colonna per dedurre queste chiavi e relazioni.

È possibile includere o escludere i trigger RI nel processo di reverse engineering. È possibile scegliere di trattare i trigger RI come oggetti modello o utilizzare l’opzione Forward engineering per includere i trigger RI nello schema. È inoltre possibile scegliere di includere o escludere queste opzioni durante il reverse engineering.

Quando si esegue il reverse engineering di un database, è possibile impostare un file di traccia per registrare le query eseguite per recuperare gli oggetti. È possibile esaminare le query al termine del processo di reverse engineering.

Il seguente diagramma illustra i passaggi per decodificare un modello da un database o uno script:

Illustrare il processo di reverse engineering

Completare i passaggi seguenti per eseguire il reverse engineering di un modello:

  1. (Opzionale) Salvare le query del database in un file di traccia.
  2. Seleziona i dettagli del modello.
  3. Selezionare le opzioni di reverse engineering.
  4. Connettersi a un database e decodificare.

Oggetti specifici di reverse engineering

Questa sezione include dettagli su come funziona il processo di reverse engineering per diversi oggetti del database.

Indice

Quando si esegue il reverse engineering di un database, vengono importati il nome, la definizione e i parametri di ciascun indice definito sul server. Quando si importano le informazioni dell’indice da un server, vengono mantenute le informazioni sulla posizione di archiviazione per ciascun indice. Pertanto, è possibile ricreare il database utilizzando le stesse assegnazioni di archiviazione. Non è necessario riassegnare manualmente il percorso di archiviazione per ciascun indice.

Dopo aver importato gli indici, è possibile visualizzare o modificare le proprietà dell’indice, le definizioni e le associazioni di tabelle nella finestra di dialogo Indici. È possibile assegnare un indice a un oggetto di archiviazione fisica nella finestra di dialogo Indici per un database DB2 z/OS, Informix, Oracle, SQL Server e SAP ASE. Se il database di destinazione è DB2 z / OS, Informix e Oracle, è anche possibile modificare i parametri di archiviazione nella finestra di dialogo Indici.

Se è selezionata un’opzione di archiviazione fisica per un database DB2 z/OS, Informix, Oracle o SAP ASE, lo schema include i parametri di archiviazione fisica dell’indice.

Oggetto di archiviazione fisica

Quando si esegue il reverse engineering di un database, è possibile importare i nomi e le definizioni degli oggetti di archiviazione fisica definiti sul server di destinazione. L’importazione avviene nello stesso modo in cui vengono importate tabelle fisiche, indici e altre informazioni dello schema fisico. Dopo aver importato oggetti di archiviazione fisici, è possibile visualizzare o modificare le definizioni degli oggetti e le associazioni di tabelle utilizzando gli editor standard.

Regola di convalida

Quando si esegue il reverse engineering da un file di schema, uno script o un catalogo di sistema, le regole di convalida vengono importate e allegate alla tabella o colonna appropriata nel modello risultante. La convenzione utilizzata per denominare le regole di convalida importate è la seguente:

VALID_RULEn

Qui n è un numero sequenziale che inizia da zero. La prima regola di convalida che viene rilevata è denominata VALID_RULE0, la regola successiva VALID_RULE1 e così via, fino a quando l’intero schema non viene elaborato.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.