Mostrando postagens com marcador Modelagem. Mostrar todas as postagens
Mostrando postagens com marcador Modelagem. Mostrar todas as postagens

segunda-feira, 15 de dezembro de 2008

Trabalhando com Controles Lookup

Trabalhando com Controles Lookup

No Delphi chamamos de “Lookup” o mecanismo que representa o relacionamento entre duas tabelas dinamicamente e de forma automatizada para a manipulação de uma delas. Isso consiste em duas operações:
A primeira é de exibir a descrição de um dado a qual não existe no registro da tabela que esta sendo manipulada.
A segunda é, ao mesmo tempo que lista a descrição, sincronizadamente, atribui o valor do campo chave, de relacionamento entra as tabelas envolvidas no lookup, para a tabela que esta sendo manipulada.



Por exemplo, vejamos o relacionamento entre duas tabelas: “Produtos” e “Categoria de Produtos” (as quais usamos no artigo anterior). Primeiro a tabela Producs, abaixo:




Temos o ID da Categoria, mas não temos a descrição dela nesta tabela. A descrição da Categoria encontra-se na tabela Categories.



Existe um relacionamento entre elas ... (Mas isso não é obrigatório para se fazer o Lookup). Essa relação entre os campos pode ser feita pela aplicação, basta que exista um relacionamento lógico entre as colunas das tabelas que serão relacionadas.



O que essa estrutura me força previamente entender? _ Devo entender que para atualizar a tabela de “Produtos” dependerei sempre dos valores existentes na tabela “Categorias”. Isso porque, os valores possíveis para a categoria de produtos está armazenado na tabela Categoria, e a constraint que define a integridade referencial entre as duas tabelas jamais permitirá que seja inserido um valor para categoryID na tabela “Products” que não exista em “Categories”. Isso é muito bom que seja dessa forma.

O Lookup permite reproduzirmos essa relação, respeitando a referencia entre as tabelas de forma automática, suprimindo totalmente a necessidade da codificação de sequer uma linha de código para isso.


Os Controles de Lookup mais comuns são:

DBLookupComboBox: TDBLookupComboBox;
DBLookupListBox: TDBLookupListBox;

Intraweb Framework
IWDBLookupComboBox: TIWDBLookupComboBox;
IWDBLookupListBox: TIWDBLookupListBox;

Dev Express
cxDBLookupComboBox: TcxDBLookupComboBox;
cxDBCheckComboBox: TcxDBCheckComboBox;

Jedi
JvDBLookupComboEdit: TJvDBLookupComboEdit;

Campo Virtual LookUp

Tfield fkLookup: A mesma lógica descrita acima é aplicada também aos Datasets, especificamente quando, através deles trabalhamos com o que a literatura chama de campos persistentes. Trata-se de objetos da classe Tfield. Quando manipulamos dados usando Datasets (TDataset) podemos criar objetos que representam a referência linha/coluna de uma tabela. Esses objetos chamamos de campos de um Dataset, eles nos permitem acessar um determinado dado de um registro. Os Tfields podem ser de vários tipos. Cada tipo determina um grupo de operações que poderá realizar o Tfield. A Propriedade FieldKind determina o tipo do Tfield.
fkData, fkCalculated, fkLookup, fkInternalCalc, fkAggregate são os valores possiveis para a propriedade FieldKind. A Classe TFieldKind, definida na unit DB, define esses valores:


type TFieldKind = (fkData, fkCalculated, fkLookup, fkInternalCalc, fkAggregate);


O Tfield usado para fazermos Lookup é do tipo “fkLookup”. Isso quer dizer que a propriedade FieldKind é “fkLookup”.

Usamos a técnica de Lookups com os Fields (TFild) de um Dataset (Um TclientDataSet por exemplo) quando existe a necessidade de acessarmos (disponibilizarmos, visualizarmos) dados provenientes de tabelas diferentes num único resultset. Como por exemplo, ao apresentar uma listagem de “Pedidos” precisamos explicitamente exibir na tela: O nome do cliente que efetuou a compra, a data do pedido e a descrição dos produtos vendidos. Obviamente, a primeira coisa que vem a mente é o recurso de utilizarmos um join em SQL.

SELECT
  C.NomeCliente,
  P.DataPedido,
  I.Quantidade,
  I.PrecoVenda,
 (I.Quantidade * I.PrecoVenda) Total,
  P.DescricaoProduto
FROM
  Clientes C
  inner join Pedidos P on
    C.ClienteID = P.ClikenteID
  inner join Itens I on
    I.PedidoID = P.PedidoID
  inner join Produtos Pr on
    Pr.ProdutoID = I.ProdutosID


Contudo, num Dataset, isto impossibilitaria a utilização do mesmo para qualquer atualização nestes dados (Obviamente, isso é verdadeiro se não consideramos a técnica de gerenciarmos explicitamente, via código, o evento “BeforeUpdateRecord” do DataSetProvider – Falaremos sobre está técnica mais adiante).
No Delphi, o campo (TField) “virtual” lookUp funciona, no que tange a visualização de dados, de forma semelhante ao join. Ou seja, podemos configurar um determinado Dataset trazendo dados através de um comando SQL genérico (Select * from ) de uma única tabela, como o exemplo anterior, “Products”, e adicionarmos a ele um campo virtual que irá conter informações de um outro Dataset. A exemplo da relação entre Products e Categories, demonstrado acima. A grande vantagem desta técnica é porque mesmo disponibilizando dados de tabelas diferentes e ainda assim podermos atualizar os dados usando os comandos convencionais do próprio Dataset. Para fazermos uso do campo LookUp basta que os Datasets possuam um campo de relacionamento.

Vejamos agora, a utilização do campo LookUp:

Suponha que neste momento queremos criar um cadastro (CRUD) de produtos. Mas temos um problema, o banco apresenta um normalização para a tabela produtos de maneira que o dado categoria do produto esta em outra tabela. A tabela Categorias (no caso Categories) é uma tabela de referência. Ela não é transacional e possui um número relativamente pequeno de registros.
Lembre-se que, na hora de incluirmos novos Produtos precisamos digitar, na interface, os dados necessários da tabela de produtos, sendo que para os campos “CategoryID” e “SupplierID” presimos apresentar as descrições de cada um dos campos. Entretanto, o dado, descrição da categoria, por exemplo, encontra-se na tabela de Categories. Ou seja, temos que ler da tabela de Categories: a descrição (Categories.Description), e o valor do respectivo vampo de relacionamento (Categories.CategoryID). Para, então, atribuir a Produtos (Products.CategoryID).

Para isso usaremos um Dataset, o CdsProdutos, criaremos nele um campo lookUp que apontará para o campo Description de Categories no CdsCategorias.
Existe o campo de relacionamento entre essas duas tabelas, esses dois campos estão presentes tanto no CdsProdutos (Products.CategoryID), quanto no CdsCategorias (Categories.CategoryID) possibilitando desta forma um “join virtual”, entre CdsProdutos e CdsCategorias. Consequentimente, podemos ainda assim a atualizar o recordset do CdsProdutos. Outro bonus fundamental dessa técnica é, o que que propositalmente guardei para relembrar no final, de que com o campo LookUp a atribuição de valor ao campo “Products.CategoryID” e feita automaticamente sem a necessidade de código para isso, proveniente do link feito com Categories.CategoryID. Isso ocorre imediatamente a ação do usuário selecionar a descrição da categoria no controle lookup disponibilizado na interface.




As linhas vermelhas indicam as propriedades envolvidas na configuração de um de um controle DBLookup (DBLookupComboBox). AS Linhas verdes indicam os valores, e suas origens, que devem ser associadas as respectivas propriedades.

Criando o Campo Virtual LookUp

Com o botão direito do mouse sobre o CdsProdutos, selecione “Fields Editor ...”



Para criar um novo Field, botão direito no “Fields Editor” e selecione “New Field” (Ou digite “Ctrl + N”).




No Diálogo de definição do novo Field configure as propriedades conforme ilustrado na figura abaixo.




Na propriedade “Name” será definido o nome da coluna/campo virtual. Automaticamente, enquanto você digitar o Delphi gera o nome do objeto Tfield em “Component”. A propriedade “Type” define o tipo de dado que o Tfield irá trabalhar, internamente isso irá definir a propriedade DataType cujo o tipo é “TfieldType”, por sua vez isso refletirá na definição de uma classe que especializa o Tfield a qual o Field criado instanciará.
Dependendo do tipo escolhido em “Type” será imprescindível definir o tamanho do Field. Isso quer dizer, por exemplo, se o campo for do tipo String, o limite máximo quanto ao número de caracteres que o Field poderá armazenar. Logo, na propriedade “Size” digite um valor adequado para o tamaho, limite de caracteres, no campo “CategoriaVirt”. É mais que aconselhável você conferir no banco qual o tamanho da coluna “Categories.CategoryName”, visto que será os valores armazenados por ela listados por esse novo campo.




Em Field Type marque Lookup, em resposta a essa ação os campos de “Lookup definition” serão habilitados, em “Key Fields” e “Lookup Keys” selecionamos as colunas de relacionamento entre os Datasets envolvidos no Lookup. Todavia, para habilitar a propriedade Dataset (onde devemos definir o Dataset que disponibilizara os dados para Lookup, no nosso caso CdsCategorias), temos que selecionar primeiro a coluna do CdsProdutos que faz o relacionamento com Categorias (CategoryID).

Na propriedade DataSet, repetindo, é onde definimos o Dataset de Lookup. Selecione CdsCategorias.
Na propriedade “Lookup Keys”, selecionamos a coluna, do Dataset o qual escolhemos na propriedade “Dataset”, que se relaciona com o CdsProdutos (CategoryID).
Por fim, na propriedade “Result Field” selecionamos a coluna do CdsCategorias que servirá para listar os dados da descrição da categoria. Ou melhor, a coluna para a qual nosso campo virtual “CategoriaVirt” apontará. Selecione “CategoryName”.




Portanto, olhando a tamanho da coluna em “Disign Table” no Enterprise Manager, podemos definir o valor 15 para a propriedade “Size”.


Para finalizar, após definir todas as propriedades, click em “OK”

Se você fizer um Drag and Drop do novo Field virtual Lookup para o Form veja que será criado um controle DbLookupCombobox associado ao CdsProdutos pelo DataSource “DsProdutos”.






Para testar, adicione um DbGrid ao Form1, associe ele ao DataSource DsProdutos (através da propriedade “DataSource” do DbGrid, no Object Inspector). No Evento OnCreate Do Form1 abra os dois Cds (CdsProdutos e CdsCategorias).


procedure TForm1.FormCreate(Sender: TObject);
begin
  CdsCategotias.Open;
  CdsProdutos.Open;
end;




Observações:

Embora apresente um ganho extraordinário para o desenvolvimento no front-end ,em situações onde trabalhamos com CRUD que envolve tabelas normalizadas, a técnica de lookup nem sempre será adequada. Observamos diversas situações em que o emprego do Lookup trará grande inconveniência, tanto no para usabilidade quanto para outros pontos importantes como: Performance e manutenibilidade. Um caso onde o Lookup é desaconselhado é quando a tabela de lookup possui muitos registros.

Em substituição a técnica de Lookup devemos usar, em conjunto, mais de uma técnica. Um exemplo comum é o join no próprio SQL do Dataset que manipula os dados, para tratar o pacote transacional posteiormente no evento BeforeUpdateRecord do DatasetProvider. Mas isso exige conhecimento intermediário em DataSnap. Em Breve abordaremos esse tema!

Artigo completo (View Full Post)

terça-feira, 22 de maio de 2007

Erwin: Modelagem de Dados - Complete Compare


Os sistemas de informação são as principais engrenagens que propulsionam o mundo de forma generalizada. Seja na área dos negócios, entidades governamentais, órgãos militares, ou na vida privada de cada um, progressivamente, mais e mais, eles são presentes e influentes. Ao ponto das relações humanas, sofrem transformações significativas. Eles são um meio, uma ferramenta e não um fim. A informação é o principal protagonista neste cenário. O que estou querendo dizer é que um sistema pode funcionar perfeitamente sem bug nenhum, entretanto, não produzir informações pertinentes para as pessoas que o utilizam. A informação é o recurso mais importante na vida de qualquer pessoa, na vida de uma corporação. Pense o seguinte, com a informação certa eu posso salvar a vida de uma pessoa, eu posso ficar milionário de uma hora pra outra. Eu posso conseguir o que eu quiser. Mas findando a viagem, voltemos ao ponto. Somos profissionais da Tecnologia da Informação, é ponto pacifico, todo mundo sabe que com dados construímos uma informação. Mas o que é a informação? A informação é um conjunto de fatos, organizados de tal forma que adquirem valor adicional além do valor do fato em si. Concluindo, é totalmente em vão o investimento num sistema que não é capaz de gerar informações relevantes, valiosas.
Como posso me certificar que o sistema que desenvolvo gera informações de qualidade?
Uma informação para alcançar o status de VALIOSA deve atender aos seguintes requisitos:

  • Ser precisa – Não possuir erros.
  • Ser Completa – Conter todos os fatos importantes.
  • Ser Econômica – O custo da geração dessa informação deve ser compatível com a relação posse/demanda do interessado nela.
  • Ser Flexível – Poder ser usada para várias finalidades.
  • Ser Confiável – Se a fonte não for idônea, você vai utilizar a informação? A confiabilidade da informação pode depender da confiabilidade do método de colheita de dados.
  • Ser Relevante – Alto grau de importância para o interessado.
  • Ser Simples – Fácil entendimento.
  • Em Tempo – Qual a importância de eu saber os números ganhadores da megasena após eles serem sorteados? Considerando que eu não tenha apostado. Entretanto, tudo muda de figura se eu souber disso pelo menos algumas horas ates de serem encerradas as apostas.
  • Ser Verificável – Essa característica aumenta consideravelmente a confiabilidade. Se não for possível checar, verificar a informação você já estará entrando no mundo da análise mística de sistemas.

Para a informação alcançar todas essas características vai depender, fundamentalmente, de como eu organizo e relaciono os fatos. Ou seja, os dados.
Neste artigo vamos apresentar alguns exemplos, onde usaremos uma ferramenta apropriada no desenvolvimento de sistemas para relacionarmos, organizarmos os dados. Veremos um pouco sobre modelagem de dados sob um enfoque prático.
Para começar um novo modelo no Erwin basta em menu “File”, clickar sobre “New”.





Selecione uma das opções “Logical”, “Physical”, “Logical/Physical”. Estas opções são correspondentes as duas últimas derivações do Modelo Relacional de Dados de Dados (Edgard codd) que define três níveis de modelos derivação dos modelos:

  1. Modelo Conceitual
  2. Modelo Lógico
  3. Modelo Físico

Neste caso devemos considerar que o modelo conceitual deverá ser feito fora da ferramenta, nela partimos direto para o modelo lógico. Pelo menos o habito me fez proceder desta forma, eu prefiro assim. A prática permite que vc imagine o modelo conceitual, mas ao passar para o papel, já o faça no modelo lógico. Não [e atoa eu as ferramenas case suprimam esta etapa. Portanto, assim faremos no decorrer deste artigo.
Vamos, inicialmente a partir do modelo conceitual, trabalhar com três entidades: Cliente, Pedido e Produto. A entidade Item surge na derivação para o modelo lógico, nosso ponto de partida no software Erwin, do relacionamento “N” para “M” entre as entidades Pedido e Produto. Portanto, no modelo que vamos desenvolver no Erwin contaremos com quatro entidades: Cliente, Pedido, Item e Produto.



O depois de definirmos os atributos e o relacionamento com a seta correspondente a cardinalidade, o próximo passo é partirmos para a derivação física do modelo. Só que o Erwin só habilitará essa opção no menu assim que você salvar seu modelo. O meu eu vou salvar com o nome ZnModeloBase.



Agora, na opção de menu “Tools”, click em “Derive New Model”.



Novamente, a mesma tela onde você escolheu o nível de derivação desejado. Nela você já vai definir que tecnologia de banco de dados vai usar. Visto que, é chegado o momento das definições físicas do seu modelo de dado. Agora você vai ter que definir os domínios, o tipo de dado, as validações (checkes e contrains) e etc..



Vou escolher Oracle, supondo que estarei criando um banco de dados que usará esta tecnologia. 9x é a versão do Oracle que eu tenho na máquina. Defina a derivação que você deseja (Física ou Logoca/Física) e a tecnologia de banco de dados, em seguida click em “Avançar”.
Na tela seguinte você pode definir ainda se aplica derivação dos relacionamentos muitos para muitos e generalização especialização. Bem como, na treeview a esquerda vc pode definir que objetos do seu modelo lógico será portado para o novo modelo físico derivado dele. Veja minhas escolhas na imagem abaixo:



Em seguida click em avançar novamente.



Agora vamos definir alguns domínios que serão usados para os campos da nossa tabela.



Para configurar a propriedades do domínio “IdentificadorZn”, click com o botão direito do mouse sobre ele e selecione “Properties”.



Vou escolher para esse domínio que seja do tipo Integer e Not Nul. Você pode alem disso definir volres default e constrains para o domínio nesta tela.
Além desse vamos definir um para tipos strings, também not null, cujo o tamanho máximo é 20 caracteres. O nome do domínio será “Texto20Zn”



Agora vamos definir os domínios de cada campo de cada tabela do nosso modelo físico. Click sobre a tabela Clientes.




Dê um duplo click sobre cada campo para configura-los. Primeiro vamos no “ID_CLIENTE”.



Click “Ok”, repita esse passo para cada campo, sendo que o campo Nome será do domínio “Texto20Zn”. Seria interessante criar um domínio para o CPF (Char de 11 not null), o qual, logicamente, seria relacionado ao campo CPF. Faça o mesmo para cada Tabela.
Para simularmos um erro, o qual será motivo para provocarmos uma alteração na base, deixe os campos da tabela Item, QTDE e VALOR_UNIT, configurados como “DATE”. No mesmo propósito o campo Dado1 de Clientes fica como “Blob”. Repito, isso é uma erro que estamos forçando para mais tarde alterarmos a base, a fim de corrigi-la, a través do complete compare do Erwin. Portanto seu modelo deverá estar agora igual a figura abaixo:



Para criar as tabelas no banco de dados através do Erwin, no menu “Tools”, click em “Forward Engineer/Schema Generation ...”



Neste diálogo, você escolhe o que vai ser criado e como vai ser criado. A princípio você deve selecionar somente o que é estritamente especifico ao que você pretende gerar. Exemplo, não pretendo criar nenhuma view, portanto, vou desmarcar todas as opções referentes a views. O mesmo para triggers.




Após selecionar as opções desejadas click em “Preview” ...






O Erwin vai gerar automaticamente um script SQL para criar as tabelas de acordo com o seu modelo. Veja o script gerado abaixo:


CREATE TABLE Clientes (
ID_CLIENTE INTEGER NOT NULL,
NOME VARCHAR2(20) NULL,
CPF CHAR(11) NULL,
DADO1 BLOB NULL
);


ALTER TABLE Clientes
ADD PRIMARY KEY (ID_CLIENTE);


CREATE TABLE Itens (
ID_PEDIDO INTEGER NOT NULL,
ID_PRODUTO INTEGER NOT NULL,
QTDE DATE NULL,
VALOR_UNIT DATE NULL
);


ALTER TABLE Itens
ADD PRIMARY KEY (ID_PEDIDO, ID_PRODUTO);


CREATE TABLE Pedidos (
ID_PEDIDO INTEGER NOT NULL,
DT_PEDIDO DATE NULL,
ID_CLIENTE INTEGER NULL
);


ALTER TABLE Pedidos
ADD PRIMARY KEY (ID_PEDIDO);


CREATE TABLE Produtos (
ID_PRODUTO INTEGER NOT NULL,
DESCRICAO VARCHAR2(20) NULL
);


ALTER TABLE Produtos
ADD PRIMARY KEY (ID_PRODUTO);


ALTER TABLE Itens
ADD FOREIGN KEY (ID_PEDIDO)
REFERENCES Pedidos (ID_PEDIDO);


ALTER TABLE Itens
ADD FOREIGN KEY (ID_PRODUTO)
REFERENCES Produtos (ID_PRODUTO);


ALTER TABLE Pedidos
ADD FOREIGN KEY (ID_CLIENTE)
REFERENCES Clientes (ID_CLIENTE);





Para efetuar a execução e, conseqüentemente, a criação das tabelas click em “Generate...”



No prompt de login digite usuário e senha do Owner no banco de dados e o servidor do banco de dados.



Veja o relatório abaixo ...


CREATE TABLE Clientes (
ID_CLIENTE INTEGER NOT NULL,
NOME VARCHAR2(20) NULL,
CPF CHAR(11) NULL,
DADO1 BLOB NULL
)

Execution Successful


ALTER TABLE Clientes
ADD PRIMARY KEY (ID_CLIENTE)

Execution Successful


CREATE TABLE Itens (
ID_PEDIDO INTEGER NOT NULL,
ID_PRODUTO INTEGER NOT NULL,
QTDE DATE NULL,
VALOR_UNIT DATE NULL
)

Execution Successful


ALTER TABLE Itens
ADD PRIMARY KEY (ID_PEDIDO, ID_PRODUTO)

Execution Successful


CREATE TABLE Pedidos (
ID_PEDIDO INTEGER NOT NULL,
DT_PEDIDO DATE NULL,
ID_CLIENTE INTEGER NULL
)

Execution Successful


ALTER TABLE Pedidos
ADD PRIMARY KEY (ID_PEDIDO)

Execution Successful


CREATE TABLE Produtos (
ID_PRODUTO INTEGER NOT NULL,
DESCRICAO VARCHAR2(20) NULL
)

Execution Successful


ALTER TABLE Produtos
ADD PRIMARY KEY (ID_PRODUTO)

Execution Successful


ALTER TABLE Itens
ADD FOREIGN KEY (ID_PEDIDO)
REFERENCES Pedidos (ID_PEDIDO)

Execution Successful


ALTER TABLE Itens
ADD FOREIGN KEY (ID_PRODUTO)
REFERENCES Produtos (ID_PRODUTO)

Execution Successful


ALTER TABLE Pedidos
ADD FOREIGN KEY (ID_CLIENTE)
REFERENCES Clientes (ID_CLIENTE)

Execution Successful

Schema Generation Complete
11 query succeeded.


Pronto!!!! Suas tabelas foram criadas com sucesso!!!!

Complete Compare

Essa funcionalidade permite você compara bases com modelos, modelos com modelos ou bases com bases. Alem disso provê um gerenciados para sincronização dos elementos comparados. Na opção de menu, “Tools”, subitem, “Complete Compare ...”, você poderá fazer isso.
Essa funcionalidade é mto útil para quem trabalha com modelagem de desenvolvimento de banco de dados. Normalmente durante a fase de análise o banco de dados sofre muitas alterações o Erwin facilita muito o trabalho de manutenção e atualização num projeto.
Logo, seguindo nessa idéia, simulando uma situação real, vamos fazer algumas alterações no nosso modelo e executar a sincronização com as tabelas geradas através do “complete Compare”.
Na tabela Clientes o campo “Dado1” será alterado para Varchar2(200). Para fazer isso, duplo click na tabela Clientes que eseta no seu modelo. Vai aparecer a janela de diálogo para edição da Tabela, selecione o campo Dado1 e no lado direito, na aba Oracle, em "Oracle datatype" altere o data type para Varchar2(200).



Adicione um campo “Dado2”, cujo datatype será: Date, Not Null.



Crie a tabela Vendedores, com os seguintes canpos: ID_VENDEDOR, NOME E COD. Em seguida altere os campos da tabela Itens, QTDE, para Integer e Valor_unit para Number(10,2), ambos “Not Null”. Relacione Vendedores com Pedidos, de acordo com o modelo abaixo.



Agora podemos sincronizar a base com o modelo. Click em “complete compare” e a seguir aparecerão os diálogos onde você determinará que tipo de comparação será feita e que tipo de sincronização. Bem como quais objetos do banco serão sincronizados.



Click em next ....



Dependendo da situação, pode ser interessante desmarcar o Prefix Owner. Ou seja ele vai desconsiderar o prefixo do Owner. Considerando que qause nenhum modelo se preocupa com quem é o Owner do objeto.
De acordo com o que você selecionou na treeview a esquerda o próximo diálogo listará todos os objetos por você selecionados. O mesmo para Tables/Views Ownered By, visto que no nosso modelo não definimos Owner para nossas tabelas, portanto ....



Aqui é apresentado uma listagem (treeview) com as opções por você seleciandas no diálogo anterior. Click next para a o dialogo referente as opção do próximo modelo, ou seja, no nosso caso a base de dados Oracle.



Neste diálogo, quase sempre é conveniente definir o Owner, primeiro pq isso restringe o número de objetos que serão comparados. Segundo, pq pode haver tabelas sinônimas para Owners diferentes. Marque “current Model Objects Only”, e na opção Match, desmarque “Using Owner”, visto que no modelo não existe tal referência.



Click Sim. Em seguida Ele apresenta a litagem das diferenças.



Ele compara de forma esperada as tabelas, desconsiderando o Owner, e lista as diferenças entre elas. Note que algumas diferenças não precisam ser consideradas, pois são restritas a particularidades do banco, tais quais: “PCTFREE10”. Portanto, essas deverão ser desconsideradas.
Na tabela de Clientes a alteração pertinente que precisamos fazer, por exemplo, é concernente ao campo Dado1, que será alterado de Blob para Varchar(200). Click sobre a linha que lista essa diferença, veja que em reflexo a essa operação os botões de importação e exportação serão habilitados. Em seguida click sobre “Import”. Repita a mesma operação para o campo Dado2.
Na tabela Itens, os campos QTDE e Valor_Unit, selecione os dois e click em “Import”.
Em Pedidos somente o Campo ID_VENDEDOR. Na tabela Produtos nenhuma alteração. Não se esqueça de selecionar a tabela Vendedores.
Ele gera um script das alterações que ele pretende fazer. Se “Generate ALTER statements for all new table columns” estiver marcado, click sobre “Preview”.



Segue o código ....



/*
CHANGE REPORT for Table CLIENTES
- change datatype from BLOB to VARCHAR2(200) of column DADO1
WARNING : Load data statement for table CLIENTES may fail or data in column DADO1 may be lost (existing data may violate the new datatype rules: converting to a shorter or incompatible datatype).
- Adding column Dado2
WARNING : Recreating Table CLIENTES based on the ERwin source model. Any differences marked 'Ignore' in the compare list will be recreated based on the ERwin source model.
ACTION is DROP and CREATE Table CLIENTES
- Data will be copied to table CLIENTESR5MG3815000 ,or table will be renamed CLIENTESR5MG3815000..
- Temp table will be dropped if load data statement is successful.
IMPACT ANALYSIS REPORT for DROP and CREATE Table CLIENTES
- referencing foreign key SYS_C009967 of table PEDIDOS will be dropped as a side effect.
*/

ALTER TABLE PEDIDOS DROP CONSTRAINT SYS_C009967;


ALTER TABLE CLIENTES RENAME TO CLIENTESR5MG3815000;


/*
CHANGE REPORT for Table ITENS
- change datatype from DATE to INTEGER, change null constraint from NULL to NOT NULL of column QTDE
WARNING : Load data statement for table ITENS may fail or data in column QTDE may be lost (existing data may violate the new datatype rules: converting to a shorter or incompatible datatype). and Load data or ALTER statement for table ITENS may fail (existing data may violate the new column rules: changing column QTDE to NOT NULL without DEFAULT).
- change datatype from DATE to NUMBER(10,2), change null constraint from NULL to NOT NULL of column VALOR_UNIT
WARNING : Load data statement for table ITENS may fail or data in column VALOR_UNIT may be lost (existing data may violate the new datatype rules: converting to a shorter or incompatible datatype). and Load data or ALTER statement for table ITENS may fail (existing data may violate the new column rules: changing column VALOR_UNIT to NOT NULL without DEFAULT).
WARNING : Recreating Table ITENS based on the ERwin source model. Any differences marked 'Ignore' in the compare list will be recreated based on the ERwin source model.
ACTION is DROP and CREATE Table ITENS
- Data will be copied to table ITENSR5MG3815001 ,or table will be renamed ITENSR5MG3815001..
- Temp table will be dropped if load data statement is successful.
IMPACT ANALYSIS REPORT for DROP and CREATE Table ITENS
- foreign key SYS_C009965 of table ITENS will be dropped as a side effect.
- foreign key SYS_C009966 of table ITENS will be dropped as a side effect.
*/

ALTER TABLE ITENS DROP CONSTRAINT SYS_C009965;


ALTER TABLE ITENS DROP CONSTRAINT SYS_C009966;


ALTER TABLE ITENS RENAME TO ITENSR5MG3815001;


/*
CHANGE REPORT for Table PEDIDOS
- Adding column ID_VENDEDOR
WARNING : Modify or load data statement for table PEDIDOS may fail (existing data may violate the new column rules: adding a NOT NULL without DEFAULT to column ID_VENDEDOR).
WARNING : Recreating Table PEDIDOS based on the ERwin source model. Any differences marked 'Ignore' in the compare list will be recreated based on the ERwin source model.
ACTION is DROP and CREATE Table PEDIDOS
- Data will be copied to table PEDIDOSR5MG3815002 ,or table will be renamed PEDIDOSR5MG3815002..
- Temp table will be dropped if load data statement is successful.
IMPACT ANALYSIS REPORT for DROP and CREATE Table PEDIDOS
- foreign key SYS_C009967 of table PEDIDOS will be dropped as a side effect.
- referencing foreign key SYS_C009965 of table ITENS will be dropped as a side effect.
*/

ALTER TABLE PEDIDOS RENAME TO PEDIDOSR5MG3815002;


/*
ACTION is CREATE Table Vendores
*/

CREATE TABLE Vendores (
ID_VENDEDOR INTEGER NOT NULL,
NOME VARCHAR2(20) NULL,
COD CHAR(2) NULL
);


ALTER TABLE Vendores
ADD PRIMARY KEY (ID_VENDEDOR);


CREATE TABLE Clientes (
ID_CLIENTE INTEGER NOT NULL,
NOME VARCHAR2(20) NULL,
CPF CHAR(11) NULL,
DADO1 VARCHAR2(200) NULL,
Dado2 CHAR(2) NULL
);


ALTER TABLE Clientes
ADD PRIMARY KEY (ID_CLIENTE);


CREATE TABLE Itens (
ID_PEDIDO INTEGER NOT NULL,
ID_PRODUTO INTEGER NOT NULL,
QTDE INTEGER NOT NULL,
VALOR_UNIT NUMBER(10,2) NOT NULL
);


ALTER TABLE Itens
ADD PRIMARY KEY (ID_PEDIDO, ID_PRODUTO);


CREATE TABLE Pedidos (
ID_PEDIDO INTEGER NOT NULL,
DT_PEDIDO CHAR(2) NULL,
ID_CLIENTE INTEGER NULL,
ID_VENDEDOR INTEGER NOT NULL
);


ALTER TABLE Pedidos
ADD PRIMARY KEY (ID_PEDIDO);


INSERT INTO Clientes (ID_CLIENTE, NOME, CPF) SELECT ID_CLIENTE, NOME, CPF FROM
CLIENTESR5MG3815000;


DROP TABLE CLIENTESR5MG3815000 CASCADE CONSTRAINTS;


INSERT INTO Itens (ID_PEDIDO, ID_PRODUTO, QTDE, VALOR_UNIT) SELECT ID_PEDIDO,
ID_PRODUTO, TO_CHAR(QTDE,'J'), TO_CHAR(VALOR_UNIT,'J') FROM
ITENSR5MG3815001;


DROP TABLE ITENSR5MG3815001 CASCADE CONSTRAINTS;


INSERT INTO Pedidos (ID_PEDIDO, DT_PEDIDO, ID_CLIENTE) SELECT ID_PEDIDO,
TO_CHAR(DT_PEDIDO), ID_CLIENTE FROM PEDIDOSR5MG3815002;


DROP TABLE PEDIDOSR5MG3815002 CASCADE CONSTRAINTS;


ALTER TABLE Itens
ADD FOREIGN KEY (ID_PEDIDO)
REFERENCES Pedidos (ID_PEDIDO);


ALTER TABLE Itens
ADD FOREIGN KEY (ID_PRODUTO)
REFERENCES Produtos (ID_PRODUTO);


ALTER TABLE Pedidos
ADD FOREIGN KEY (ID_VENDEDOR)
REFERENCES Vendores (ID_VENDEDOR)
ON DELETE SET NULL;


ALTER TABLE Pedidos
ADD FOREIGN KEY (ID_CLIENTE)
REFERENCES Clientes (ID_CLIENTE);




Um relatório sobre a comparação também pode ser visualizado, click em “Report ...”.



Para prossegui na intenção de efetuar as alterações click em “Next”. Mais um diálogo lista os possíveis problemas que ele vai encontrar ao processar as alterações.



Click em close para o próximo passo. No diálogo seguinte, no botão acima, click em “Start Export”.




Será apresentado mais um relatório durante a operação, também em forma de caixa de diálogo semelhante as anteriores. Onde haverá botões para impressão, salvar e etc...
Segue o relatório gerado pela exportação que acabamos de processar.



/*
CHANGE REPORT for Table CLIENTES
- change datatype from BLOB to VARCHAR2(200) of column DADO1
WARNING : Load data statement for table CLIENTES may fail or data in column DADO1 may be lost (existing data may violate the new datatype rules: converting to a shorter or incompatible datatype).
- Adding column Dado2
WARNING : Recreating Table CLIENTES based on the ERwin source model. Any differences marked 'Ignore' in the compare list will be recreated based on the ERwin source model.
ACTION is DROP and CREATE Table CLIENTES
- Data will be copied to table CLIENTESR5MG4020000 ,or table will be renamed CLIENTESR5MG4020000..
- Temp table will be dropped if load data statement is successful.
IMPACT ANALYSIS REPORT for DROP and CREATE Table CLIENTES
- referencing foreign key SYS_C009967 of table PEDIDOS will be dropped as a side effect.
*/

ALTER TABLE PEDIDOS DROP CONSTRAINT SYS_C009967

Execution Successful


ALTER TABLE CLIENTES RENAME TO CLIENTESR5MG4020000

Execution Successful


/*
CHANGE REPORT for Table ITENS
- change datatype from DATE to INTEGER, change null constraint from NULL to NOT NULL of column QTDE
WARNING : Load data statement for table ITENS may fail or data in column QTDE may be lost (existing data may violate the new datatype rules: converting to a shorter or incompatible datatype). and Load data or ALTER statement for table ITENS may fail (existing data may violate the new column rules: changing column QTDE to NOT NULL without DEFAULT).
- change datatype from DATE to NUMBER(10,2), change null constraint from NULL to NOT NULL of column VALOR_UNIT
WARNING : Load data statement for table ITENS may fail or data in column VALOR_UNIT may be lost (existing data may violate the new datatype rules: converting to a shorter or incompatible datatype). and Load data or ALTER statement for table ITENS may fail (existing data may violate the new column rules: changing column VALOR_UNIT to NOT NULL without DEFAULT).
WARNING : Recreating Table ITENS based on the ERwin source model. Any differences marked 'Ignore' in the compare list will be recreated based on the ERwin source model.
ACTION is DROP and CREATE Table ITENS
- Data will be copied to table ITENSR5MG4020001 ,or table will be renamed ITENSR5MG4020001..
- Temp table will be dropped if load data statement is successful.
IMPACT ANALYSIS REPORT for DROP and CREATE Table ITENS
- foreign key SYS_C009965 of table ITENS will be dropped as a side effect.
- foreign key SYS_C009966 of table ITENS will be dropped as a side effect.
*/

ALTER TABLE ITENS DROP CONSTRAINT SYS_C009965

Execution Successful


ALTER TABLE ITENS DROP CONSTRAINT SYS_C009966

Execution Successful


ALTER TABLE ITENS RENAME TO ITENSR5MG4020001

Execution Successful


/*
CHANGE REPORT for Table PEDIDOS
- Adding column ID_VENDEDOR
WARNING : Modify or load data statement for table PEDIDOS may fail (existing data may violate the new column rules: adding a NOT NULL without DEFAULT to column ID_VENDEDOR).
WARNING : Recreating Table PEDIDOS based on the ERwin source model. Any differences marked 'Ignore' in the compare list will be recreated based on the ERwin source model.
ACTION is DROP and CREATE Table PEDIDOS
- Data will be copied to table PEDIDOSR5MG4020002 ,or table will be renamed PEDIDOSR5MG4020002..
- Temp table will be dropped if load data statement is successful.
IMPACT ANALYSIS REPORT for DROP and CREATE Table PEDIDOS
- foreign key SYS_C009967 of table PEDIDOS will be dropped as a side effect.
- referencing foreign key SYS_C009965 of table ITENS will be dropped as a side effect.
*/

ALTER TABLE PEDIDOS RENAME TO PEDIDOSR5MG4020002

Execution Successful


/*
ACTION is CREATE Table Vendores
*/

CREATE TABLE Vendores (
ID_VENDEDOR INTEGER NOT NULL,
NOME VARCHAR2(20) NULL,
COD CHAR(2) NULL
)

Execution Successful


ALTER TABLE Vendores
ADD PRIMARY KEY (ID_VENDEDOR)

Execution Successful


CREATE TABLE Clientes (
ID_CLIENTE INTEGER NOT NULL,
NOME VARCHAR2(20) NULL,
CPF CHAR(11) NULL,
DADO1 VARCHAR2(200) NULL,
Dado2 CHAR(2) NULL
)

Execution Successful


ALTER TABLE Clientes
ADD PRIMARY KEY (ID_CLIENTE)

Execution Successful


CREATE TABLE Itens (
ID_PEDIDO INTEGER NOT NULL,
ID_PRODUTO INTEGER NOT NULL,
QTDE INTEGER NOT NULL,
VALOR_UNIT NUMBER(10,2) NOT NULL
)

Execution Successful


ALTER TABLE Itens
ADD PRIMARY KEY (ID_PEDIDO, ID_PRODUTO)

Execution Successful


CREATE TABLE Pedidos (
ID_PEDIDO INTEGER NOT NULL,
DT_PEDIDO CHAR(2) NULL,
ID_CLIENTE INTEGER NULL,
ID_VENDEDOR INTEGER NOT NULL
)

Execution Successful


ALTER TABLE Pedidos
ADD PRIMARY KEY (ID_PEDIDO)

Execution Successful


INSERT INTO Clientes (ID_CLIENTE, NOME, CPF) SELECT ID_CLIENTE, NOME, CPF FROM
CLIENTESR5MG4020000

Execution Successful


DROP TABLE CLIENTESR5MG4020000 CASCADE CONSTRAINTS

Execution Successful


INSERT INTO Itens (ID_PEDIDO, ID_PRODUTO, QTDE, VALOR_UNIT) SELECT ID_PEDIDO,
ID_PRODUTO, TO_CHAR(QTDE,'J'), TO_CHAR(VALOR_UNIT,'J') FROM
ITENSR5MG4020001

Execution Successful


DROP TABLE ITENSR5MG4020001 CASCADE CONSTRAINTS

Execution Successful


INSERT INTO Pedidos (ID_PEDIDO, DT_PEDIDO, ID_CLIENTE) SELECT ID_PEDIDO,
TO_CHAR(DT_PEDIDO), ID_CLIENTE FROM PEDIDOSR5MG4020002

Execution Successful


DROP TABLE PEDIDOSR5MG4020002 CASCADE CONSTRAINTS

Execution Successful


ALTER TABLE Itens
ADD FOREIGN KEY (ID_PEDIDO)
REFERENCES Pedidos (ID_PEDIDO)

Execution Successful


ALTER TABLE Itens
ADD FOREIGN KEY (ID_PRODUTO)
REFERENCES Produtos (ID_PRODUTO)

Execution Successful


ALTER TABLE Pedidos
ADD FOREIGN KEY (ID_VENDEDOR)
REFERENCES Vendores (ID_VENDEDOR)
ON DELETE SET NULL

Execution Successful


ALTER TABLE Pedidos
ADD FOREIGN KEY (ID_CLIENTE)
REFERENCES Clientes (ID_CLIENTE)

Execution Successful

Schema Generation Complete
24 query succeeded.


OBS: O Banco usado nesse exemplo possui a única finalidade de recurso didático, não possuído nenhuma pretensão se ser compatível com qualquer lógica de negócio que possa ser usada para um sistema profissional. Segue o Script final do banco ....


CREATE TABLE Clientes (
ID_CLIENTE INTEGER NOT NULL,
NOME VARCHAR2(20) NULL,
CPF CHAR(11) NULL,
DADO1 VARCHAR2(200) NULL,
Dado2 CHAR(2) NULL
);


ALTER TABLE Clientes
ADD PRIMARY KEY (ID_CLIENTE);


CREATE TABLE Itens (
ID_PEDIDO INTEGER NOT NULL,
ID_PRODUTO INTEGER NOT NULL,
QTDE INTEGER NULL,
VALOR_UNIT NUMBER(8,2) NOT NULL,
Promocao CHAR(1) NOT NULL
);


ALTER TABLE Itens
ADD PRIMARY KEY (ID_PEDIDO, ID_PRODUTO);


CREATE TABLE Pedidos (
ID_PEDIDO INTEGER NOT NULL,
DT_PEDIDO CHAR(2) NULL,
ID_CLIENTE INTEGER NULL,
ID_VENDEDOR INTEGER NOT NULL
);


ALTER TABLE Pedidos
ADD PRIMARY KEY (ID_PEDIDO);


CREATE TABLE Produtos (
ID_PRODUTO INTEGER NOT NULL,
DESCRICAO VARCHAR2(20) NULL,
CODprod VARCHAR2(20) NULL
);


ALTER TABLE Produtos
ADD PRIMARY KEY (ID_PRODUTO);


CREATE TABLE Vendores (
ID_VENDEDOR INTEGER NOT NULL,
NOME VARCHAR2(20) NULL,
COD VARCHAR2(2) NOT NULL
);


ALTER TABLE Vendores
ADD PRIMARY KEY (ID_VENDEDOR);


ALTER TABLE Itens
ADD FOREIGN KEY (ID_PEDIDO)
REFERENCES Pedidos (ID_PEDIDO);


ALTER TABLE Itens
ADD FOREIGN KEY (ID_PRODUTO)
REFERENCES Produtos (ID_PRODUTO);


ALTER TABLE Pedidos
ADD FOREIGN KEY (ID_VENDEDOR)
REFERENCES Vendores (ID_VENDEDOR)
ON DELETE SET NULL;


ALTER TABLE Pedidos
ADD FOREIGN KEY (ID_CLIENTE)
REFERENCES Clientes (ID_CLIENTE);





Pronto!!!! Aeeee...oi!!! A base está sincronizada com o modelo.
A vida é boa!!! É fácil trabalhar assim!!!
Então, foi bom pra você?
Qualquer ponto que não tenha ficado claro, por favor registre como comentário que responderemos prontamente.


Artigo completo (View Full Post)

 
BlogBlogs.Com.Br