Índice. 39 MySQL. 42 PostgreSQL. 48 JDataStore. SQL News Novas tecnologias, atualizações, lançamentos de produtos,eventos e livros.

Transcrição

1

2 ANUNCIO

3 Índice 06 SQL News Novas tecnologias, atualizações, lançamentos de produtos,eventos e livros. 08 Guia Rápido da SQL Explorando os princupais recursos do comando SELECT. 12 Otimização de comandos SQL Conceitos e diretrizes para aumento da performance na execução de comandos SQL. 18 Modelagem de dados com ErWin Uma introdução aos recursos e utilização desta ferramenta. 22 Introdução a UML Defi nição, implementação e utilizção de um modelo usando UML 26 Conctando Front-Ends Exemplos práticos para o acesso a banco de dados com diversas ferramentas. 34 Emacs SQL Utilizando o Emacs para acesso e manutenção de bancos de dados. 39 MySQL Instalação, overview dos recursos e utlilização do MySQL no linux. 42 PostgreSQL Uma análise dos recursos do postgre e vantagens de sua distribuição nacional. 44 Replicação de dados Teoria e prática envolvendo replicação de dados no SQL Server. 48 JDataStore Conhecendo o banco de dados e uma entrevista com Sergio Cardoso. SQL Magazine - 3

4 E D I T O R I A L Coordenador Editorial Gladstone Matos gladstone@neoficio.com.br Editor Geral Gustavo Viegas gustavo@sqlmagazine.com.br Equipe Editorial Cristina Viegas Edgar Silva Fábio Faldini Gisele Nichols Pedro Henrique dos Santos Acessora de Imprensa Kaline Dolabela kalined@hotmail.com Contribuíram nesta edição Clementino Leal, Cleison Santos, Everson Ramos, Edgar Silva, Fábio Faldini, Gustavo Viegas, Gisele Nichols, Gladstone Matos, Paulo Ribeiro, Pedro Henrique Editor de Arte Vinicius O. Andrade viniciusoandrade@gmail.com Capa Mauro Lassance mauro@bitourisn.com Gerente Geral Rosângela Matos rosangela@neoficio.com.br Publicidade Julio César Lopes julio@neoficio.com.br Jornalista Resposável Sérgio Moraes C. Brandão MTb: Impressão Ediouro Gráfica e Editora S/A Atendimento ao Leitor info@sqlmagazine.com.br Assinaturas assinaturas@sqlmagazine.com.br Colaboração de Artigos gustavo@sqlmagazine.com.br Na Web Distribuição Fernando Chinaglia Dist. S/A Rua Teodoro da Silva, 907 Grajaú - RJ - CEP: Atualmente, na medida em que as tecnologias de banco de dados e ferramentas para desenvolvimento de aplicações vem evoluindo, temos um abismo cada vez maior entre o profissional de informática e as áreas de conhecimento fora de sua especialização. Questiono: Até onde deve ir o conhecimento do profissional de tecnologia da informação? Será que a especialização total é o melhor caminho? Seja técnico, desenvolvedor ou analista, a questão é quanto de sua área ele precisa saber para implementar, analisar, projetar e interagir num processo de desenvolvimento e manutenção de uma aplicação? Será que podemos afirmar que um desenvolvedor deve ter somente conhecimentos profundos de uma determinada ferramenta de desenvolvimento e, no caso de uma aplicação que acesse um banco de dados, não ter a mínima noção deste banco? Ou ainda: um DBA que tem a responsabilidade de instalar, configurar, dimensionar, criar os objetos de um modelo, garantir uma boa performance, entre outras, não faria suas tarefas de modo mais consciente sabendo um pouco sobre como os dados serão acessados e manipulados? Podemos citar ainda aqueles que participam das definições de um projeto, lá no estágio embrionário do sistema. Para estes, o conhecimento do banco de dados, das tecnologias e ferramentas utilizadas para desenvolvimento, afetariam na definição do projeto a ponto de facilitar sua implementação e futura manutenção? Como disse, o abismo que separa o conhecimento entre cada profissional de informática tem se mostrado crescente, e isso, de certa forma, não é bom. A SQL Magazine chega até você com o objetivo de trazer informações sobre o mundo dos bancos de dados, tecnologias e ferramentas de desenvolvimento. Temos uma árdua tarefa diante dos leitores: diminuir o abismo citado, através da publicação de artigos de base, fomentando o conhecimento daqueles que ainda não lidam com o assunto, artigos técnicos, para os que já utilizam algum tipo de SGBD e artigos avançados, voltados para DBA s. Além de novidades, previews, cursos e dicas. Espero que você encontre na SQL Magazine informações para o seu crescimento profissional, tomada de decisão, auxílio na solução de problemas, base para definição de projetos independente do seu papel nos mesmos e acima de tudo: uma fonte de consultas e mais consultas. Boa leitura. Gustavo Viegas Editor Gustavo@sqlmagazine.com.br 4 - Magazine SQL

5 ANUNCIO SQL Magazine - 5

6 Usando UML Com.NET Através do Rational XDE ( extended Development Environment ) Professional v2002 você pode ter na IDE do Visual Studio o ambiente nescessário para analisar, implementar e documentar suas soluções baseadas no.net FrameWork utilizando UML. Esta integração é extremamente útil para implementação de sistemas complexo utilizando C#. O XDE suporta os principais diagramas UML, possibilita a utilização de vários Design Patterns além de facilitar a implementação de Design Patterns próprios. Consulte < rational.com> para um overview do produto. SQL News Application Server da Oracle oferece business intelligence incorporado Integrado ao servidor de aplicação, o Oracle9i Application Server proporciona todo o middleware necessário para uma eficiente comunicação de dados em e-business. Com um único produto é possível executar diversas aplicações (Java, portal, integração de aplicativos, wireless e outras). Foram efetuadas customizações que otimizam o processo de configuração de backup e recovery, gerenciamento automático de backups e logs arquivados, backups e restaurações reiniciáveis e restauração/recuperação de teste. O SQL e o PL/SQL receberam outras melhorias no Oracle9iAS. Foi adicionada depuração no lado servidor para múltiplas linguagens, permitindo que os ambientes de desenvolvimento integrado (IDEs) depurem tanto Java quanto PL/SQL dentro da mesma estrutura. Mais informações em Cresce a competição entre os bancos de dados da IBM, Microsoft, e Oracle Enquanto a Microsoft fala de futuras implementações no SQL Server, a Big Blue disponibiliza a versão DB2 8.1 UDB. Nesta última versão, a IBM está tentando tornar o seu banco de dados mais fácil de ser utilizado, distribuído, e administrado. Implementações que aumentam a performance na execução de queryes e capacidades autônomas estão entre as novidades do DB A Microsoft anunciou a versão 64-bit do SQL Server (Beta) e espera conquistar maior confiança dos usuários de banco de dados. A Oracle, por sua vez, utilizou a OracleWorld User Conference em San Francisco para mostrar detalhes do seu novo banco de dados, chamado até então de 10i e previsto para lançamento em meados de Apesar do nome final do produto não estar definido, a Oracle falou oficialmente que a nova versão terá seu foco no gerenciamento, aumento da capacidade, e novo suporte para XML e Web services. Computador que se conserta sozinho A IBM está desenvolvendo sistemas que se consertam sozinhos e necessitam de menos intervenção humana. Para isso, criou a divisão Autonomic Computing, cuja meta é fazer com que os computadores sejam autônomos de maneira semelhante ao comportamento do sistema nervoso humano, que permite adaptar-se às mudanças à sua volta, a defender-se de ataques externos e a recuperar-se de falhas internas. As capacidades autônomas estarão incluídas inclusive no banco de dados DB2. A idéia é permitir que os computadores dêem conselhos sobre seu melhor rendimento e, então, permitir que esses sistemas executem os conselhos sem o aval dos técnicos. Oracle9i nas eleições Mais de 185 milhões de votos foram processados no primeiro e segundo turnos das eleições pelo Tribunal Superior Eleitoral. Em menos de 24 horas, os brasileiros já sabiam o resultado dos 91 milhões de votos apurados na primeira fase. Para realizar tal feito, o TSE utilizou o banco de dados Oracle9i. O sistema, desenvolvido em parceria do TSE com a Oracle, é o mais avançado no segmento. Os dados de todos os Tribunais Regionais Eleitorais, correspondentes aos votos para deputados estaduais e federais, senadores e governadores, são totalizados e somados aos do TSE, que é responsável pela centralização e contagem dos votos para presidente da República. Esse processo permitiu a divulgação imediata dos resultados nos telões de apuração e na Internet.

7 Backups seguros e contínuos A Storageteck, fornecedora de soluções de armazenamento de dados, está colocando no mercado as fitotecas robotizadas L20, L40 e L80, que permitem que os backups sejam feitos continuamente, 24 horas por dia. O produto foi desenvolvido para pequenas e médias empresas cujas plataformas rodam em ambientes NT, Novell, Linux ou Unix. Focados no mercado entry level, as bibliotecas de backup destinam-se a redes com necessidades de armazenamento a partir de 400 GB. Na prática, os produtos da Série L são disponíveis nas versões 2, 4 ou 8 drives, com capacidades de 110 GB a 220 GB cada. IBM DB2 UDB 8.1 para Linux (Beta) A IBM se orgulha do seu compromentimento com o Linux. Desde o seu portal Linux até a campanha Paz, Amor, e Linux que foi grafitada nas ruas de cidades americanas no ano passado, a companhia tem deixado claro que pretende ser vista na linha de frente do desenvolvimento para este sistema. A versão 8.1 (Beta) do DB2 UDB esta disponível para download no site da Big Blue ( com/db2/) e a IBM recomenda no mínimo 128Mb de memória e de 250Mb a 350Mb disponíveis em disco para instalação e utilização de um banco de dados de tamanho médio. Uma novidade está no db2setup utility, um utilitário com aparência e operação semelhante a de muitos programas para Windows. Informações adicionais e uma análise do produto estão disponíveis no endereço Microsoft SQL Server comemora seu 10 º Aniversário A Microsoft Corp. anunciou no dia 20 de novembro o 10º aniversário do Microsoft(R) SQL Server (TM) na Associação de Profissionais de SQL Server (PASS) em Seattle, num grande evento exclusivamente dedicado ao banco. No keynote de abertura, Gordon Mangione, vice presidente corporativo do SQL Server na Microsoft, falou do passado e das futuras implementações no SQL Server como motivos para os muitos clientes e parceiros continuarem a desenvolver utilizando a plataforma Microsoft SQL Server. Com base nas inovações do produto, Mangione anunciou a disponibilização do SQL Server 2000 (64-bit) Beta 2 e do Microsoft SQL Server 2000 Service Pack 3 (SP3) Beta 1. Ele encorajou aos desenvolvedores a utilizarem ambas as versões Beta disponíveis e reforçou o objetivo da Microsoft de desenvolver um conjunto de ferramentas que garantam um alto nível de performance, gerenciamento e escalabilidade. ANUNCIO Oracle 9i - O Manual do DBA Autor: Kevin Loney Editora Campus páginas. R$ 159 Pertencente à série Oracle Press, cujos livros são guias oficiais da Oracle produzidos por especialistas da própria empresa, este livro oferece uma cobertura completa dos recursos mais recentes e as maneiras de incorporar esses recursos no gerenciamento de um banco de dados Oracle. Com este livro, o leitor aprenderá a implementar as soluções administrativas de especialistas, a manter os seus importantes sistemas da Internet e de comércio eletrônico flexíveis, seguros e disponíveis - tudo com informações exclusivas autorizadas pela Oracle. Este guia abrange todos os pontos importantes sobre Oracle 9i, fornecendo exemplos e técnicas reais. Alguns tópicos: SQL Magazine - 7

8 Guia rápido da SQL por Gladstone Matos Alinguagem SQL é sucinta e ao mesmo tempo poderosa. Através de um idioma de fácil entendimento, a SQL permitiu a padronização na forma de comunicar os aplicativos front-ends com os diversos bancos de dados disponíveis. Neste artigo veremos os principais parâmetros do comando SELECT, a principal forma de recuperar dados através da SQL. COMANDO SELECT A SQL foi criada com o objetivo de padronizar os comandos de manipulação de dados em SGBD s. Hoje em dia, apesar da linguagem possuir uma quantidade considerável de extensões e implementações proprietárias, pode-se afirmar que a meta foi alcançada. A maior parte do código SQL escrito nas aplicações se encontra no formato puro, conhecido como ANSI. O sucesso da SQL trouxe uma produtividade interessante para a manipulação de banco de dados. Conhecendo bem a linguagem é possível acessar os recursos básicos de qualquer banco relacional, como Oracle, SQL Server ou MySQL, sem praticamente nenhuma mudança. Veremos neste artigo um pequeno guia de referência para os parâmetros do comando SELECT, um dos mais importantes da linguagem SQL. SELECT Simples O comando SELECT permite recuperar os dados de um objeto do banco, como uma tabela, uma view e, em alguns casos, uma stored procedure (alguns bancos de dados permitem a criação de procedimentos que retornam valor). A sintaxe mais básica do comando é: SELECT <LISTA_DE_CAMPOS> FROM <NOME_DA_TABELA> Exemplo: SELECT CODIGO, NOME FROM CLIENTES; SELECT * FROM CLIENTES; O caracter * representa todos os campos. Apesar de prática, esta máscara não é muito utilizada, pois, para o SGBD, é mais rápido receber o comando com todos os campos explicitados. O uso do * obriga o servidor a consultar quais são os campos antes de efetuar a busca dos dados, criando mais um passo no processo. COMANDO WHERE A cláusula Where permite ao comando SQL passar condições de filtragem, Veja o exemplo: SELECT CODIGO, NOME FROM CLIENTES WHERE CODIGO = 10; SELECT CODIGO, NOME FROM CLIENTES WHERE UF = RJ SELECT CODIGO, NOME FROM CLIENTES WHERE CODIGO >= 100 AND CODIGO <=500; SELECT CODIGO, NOME FROM CLIENTES WHERE UF= MG OR UF = SP

9 Guia Rápido da SQL Os parênteses, corretamente utilizados, dão mais poder a consulta: SELECT CODIGO, NOME FROM CLIENTES WHERE UF = RJ OR (UF= SP AND ATIVO= N ); Neste comando, todos os clientes do Rio de Janeiro e apenas os clientes inativos de São Paulo seriam capturados. SELECT CODIGO, NOME FROM CLIENTES WHERE (ENDERECO IS NULL) OR (CIDADE IS NULL) Aqui todos os clientes que não possuem endereco ou cidade cadastrados serão selecionados. FILTRO DE TEXTO SELECT CODIGO, NOME FROM FUNCIONARIO WHERE DEPARTAMENTO= VENDAS ; SELECT CODIGO FROM CLIENTES WHERE NOME > K ; Para busca parcial de strings, o SELECT fornece o operador LIKE: SELECT CODIGO, NOME FROM CLIENTES WHERE NOME LIKE MARIA* ; Neste comando, todos os clientes cujo nome iniciam com Maria serão retornados. Se quisermos retornar os nomes que contenham MARIA também no meio, podemos alterar para: SELECT CODIGO, NOME FROM CLIENTES WHERE NOME LIKE *MARIA* O uso da máscara no início e no fim da string fornece maior poder de busca, mas causa considerável perda de performance. Este recurso deve ser utilizado com critério. Nota: Em alguns bancos de dados a máscara de fitro não é representada pelo caracter *. Consulte a referência do banco utilizado para verificar o caracter correto. Por padrão, a SQL diferencia caixa baixa de caixa alta. Para eliminar essa diferença, utilize a função UPPER: SELECT CODIGO, NOME FROM CLIENTES WHERE UPPER(NOME) LIKE MARIA*SILVA* ORDENAÇÃO A ordenação pode ser definida com o comando ORDER BY. Assim como no comando WHERE, o campo de ordenação não precisa estar listado como campo de visualização: SELECT CODIGO, NOME FROM CLIENTES ORDER BY NOME SELECT CODIGO, NOME FROM CLIENTES ORDER BY UF, NOME A inclusão da palavra DESC garante a ordenação invertida: SELECT CODIGO, NOME FROM CLIENTES ORDER BY NOME DESC SELECT CODIGO, NOME FROM CLIENTES ORDER BY UF DESC, NOME JUNÇÃO DE TABELAS O SELECT permite juntar duas ou mais tabelas no mesmo resultado. Isso pode ser feito de várias formas: SELECT CLIENTES.CODIGO, CLIENTES.NOME, PEDIDOS.DATA, PEDIDOS.VALOR FROM CLIENTES, PEDIDOS WHERE CLIENTES.CODIGO = PEDIDOS.CODCLIENTE Nesta linha as tabelas relacionadas CLIENTES e PEDIDOS são unificada através do campo chave, em uma operação de igualdade. Repare que o nome dos campos passam a ser prefixados pelo nome das tabelas, resolvendo duplicidades. Uma versão resumida desta comando pode ser: SELECT A.CODIGO, A.NOME, B.DATA, B.VALOR FROM CLIENTES A, PEDIDOS B WHERE A.CODIGO = B.CODCLIENTE O uso de aliases no código SQL torna a manutenção mais simples. No comando abaixo temos várias tabelas unificadas em uma mesma cláusula: SELECT A.CODIGO, A.NOME, B.DATA, B.VALOR, C.QTD, D.DESCRICAO FROM CLIENTES A, PEDIDOS B, ITENS C, PRODUTOS D WHERE A.CODIGO = B.CODCLIENTE AND B.CODIGO = C.CODPEDIDO AND C.CODPRODUTO = D.CODIGO Neste comando unificamos as tabelas relacionadas CLIENTES, PEDIDOS, ITENS e PRODUTOS. Veja mais alguns exemplos: SELECT A.CODIGO, A.NOME, B.DATA, B.VALOR FROM CLIENTES A, PEDIDOS B WHERE A.CODIGO = B.CODCLIENTE AND A.UF= RJ SELECT A.CODIGO, A.NOME, B.DATA, B.VALOR FROM CLIENTES A, PEDIDOS B WHERE A.CODIGO = B.CODCLIENTE AND UF = RJ OR (UF= SP AND ATIVO= N ); SELECT A.CODIGO, A.NOME, B.DATA, B.VALOR FROM CLIENTES A, PEDIDOS B WHERE A.CODIGO = B.CODCLIENTE ORDER BY A.UF, A.NOME Observe que a junção através da igualdade de campos traz como resultado somente os registros que possuem referência nas duas tabelas. Observe o comando abaixo: SELECT A.CODIGO, A.DESCRICAO, B.DESCRICAO FROM PRODUTOS A, COMPONENTES B WHERE A.CODIGO = B.CODPRODUTO Os produtos que não possuem componentes não são selecionados. Caso seja necessário criar uma listagem incluindo também os registros que não possuem correspondência, deve-se utilizar o comando JOIN. COMANDO JOIN A junção de tabelas no comando SELECT também pode ser feita com o comando JOIN. Este comando deve ser utilizado com a palavra reservada INNER ou com a palavra OUTER: INNER - Semelhante ao uso do operador = na junção de tabelas. Aqui, os registros sem correspondências não são incluídos. Esta cláusula é opcional e pode ser omitida no comando JOIN. OUTER Os registros que não se relacionam também são exibidos. Neste caso, é possível definir qual tabela será incluída na seleção, mesmo não tendo correspondência. Para exemplificar, temos as tabelas abaixo: Produtos Código Descrição Categoria 1 Martelo 1 2 Chave de Fenda 1 3 Alicate 2 4 Desmagnetizador 2 5 Parafuso <null> Componentes Código Cod.Produto Descrição Qtd 1 3 Adaptador CF CaboMod A CaboMod A2 1 Código Categoria 1 Ferramenta A1 2 Ferramenta B1 3 Ferramenta C1 4 Ferramenta D1 Descrição Observe os exemplos e o resultado produzido: SELECT A.CODIGO, A.DESCRICAO, B.DESCRICAO, B.QTD FROM PRODUTOS A INNER JOIN COMPONENTES B ON (A.CODIGO = B.CODPRODUTO) SQL Magazine - 9

10 Resultado 1 Cód Descrição Descrição Qtd 1 Alicate Adaptador CF 1 2 Desmagnetizador CaboMod A1 2 3 Desmagnetizador CaboMod A2 1 Este comando pode ser escrito na versão resumida abaixo: SELECT A.CODIGO, A.DESCRICAO, B.DESCRICAO FROM PRODUTOS A JOIN COMPONENTES B ON (A.CODIGO = B.CODPRODUTO) Como mostrado no resultado, os produtos que não possuem componentes não são incluídos na seleção. SELECT A.CODIGO, A.DESCRICAO, B.DESCRICAO, B.QTD FROM PRODUTOS A LEFT OUTER JOIN COMPONENTES B ON (A.CODIGO = B.CODPRODUTO) Resultado 2 Cód Descrição Descrição Qtd 1 Martelo 1 2 Chave de Fenda 2 3 Alicate Adaptador CF 1 4 Desmagnetizador CaboMod A1 4 Desmagnetizador CaboMod B2 5 Parafuso Neste comando todos os produtos serão incluídos na seleção, independente de possuirem um componente. Observe que a palavra LEFT se refere a primeira tabela no relacionamento. O mesmo comando poderia ser descrito na forma: SELECT A.CODIGO, A.DESCRICAO, B.DESCRICAO FROM COMPONENTES A RIGHT OUTER JOIN PRODUTOS B ON ( A.CODIGO = B.CODPRODUTO ) A ordem das tabelas foi invertida, mas o resultado é o mesmo. Observe mais alguns exemplos: SELECT A.CODIGO, A.DESCRICAO, B.DESCRICAO, B.QTD FROM PRODUTOS A JOIN COMPONENTES B ON ( A.CODIGO = B.CODPRODUTO ) WHERE A.CATEGORIA=1 Resultado 3 Cód Descrição Descrição Qtd <vazio> <vazio> <vazio> <vazio> SELECT A.CODIGO, A.DESCRICAO, B.DESCRICAO FROM PRODUTOS A JOIN COMPONENTES B ON (A.CODIGO = B.CODPRODUTO ) WHERE A.CATEGORIA=1 OR A.CATEGORIA=2 ORDER BY A.CATEGORIA, A.DESCRICAO 10 - Magazine SQL Resultado 4 Cód Descrição Descrição Qtd 3 Alicate Adaptador CF 1 4 Desmagnetizador CaboMod A1 2 4 Desmagnetizador CaboMod A2 1 FULL OUTER JOIN Podemos ainda combinar o uso de INNER e OUTER através do comando FULL OUTER JOIN. Neste caso, todos os registros das duas tabelas envolvidas serão exibidos, tendo ou não relacionamento. Observe: SELECT A.CODIGO, A.DESCRICAO, B.DESCRICAO FROM PRODUTOS A FULL OUTER JOIN CATEGORIA B ON ( A.CATEGORIA = B.CODIGO ) ORDER BY A.DESCRICAO Produtos Código Descrição Categoria 1 Martelo Ferramenta A1 2 Chave de Fenda Ferramenta A1 3 Alicate Ferramenta B1 4 Desmagnetizador Ferramenta B1 5 Parafuso Ferramenta C1 Ferramenta D1 UNION Existe ainda uma Segunda forma de juntar tabelas com o comando SELECT. Através do parâmetro UNION, é possível colar o conteúdo de duas tabelas. Veja o exemplo: SELECT CODIGO, NOME FROM CLIENTES UNION SELECT CODIGO, NOME FROM FUNCIONARIOS O resultado deste comando é a listagem de todos os clientes e a listagem dos funcionários, dentro do mesmo result set. Repare que no comando JOIN a união é horizontal e no UNION a união é vertical. Por default, os registros duplicados são eliminados na cláusula UNION. No exemplo anterior, se tivéssemos um cliente com mesmo nome e código de um funcionário, apenas o registro da primeira tabela seria exibido. Para incluir todos os registros, independente de duplicidade, utilize a palavra ALL: SELECT CODIGO, NOME FROM CLIENTES UNION ALL SELECT CODIGO, NOME FROM FUNCIONARIOS FUNÇÕES DE AGRUPAMENTO São cinco as funções básicas de agrupamento: AVG: Retorna a média do campo especificado: SELECT AVG(VALOR) FROM PEDIDOS; MIN/MAX/SUM: Respectivamente, retorna o menor valor, o maior e o somatório de um grupo de registros: SELECT MIN(VALOR) FROM PEDIDOS; SELECT MAX(VALOR) FROM PEDIDOS; SELECT AVG(VALOR) FROM PEDIDOS; COUNT: Retorna a quantidade de itens da seleção: SELECT COUNT(CODIGO) FROM CLIENTES; AGRUPAMENTO Um poderoso recurso do comando SELECT é o parâmetro GROUP BY. Através dele podemos retornar informações agrupadas de um conjunto de registros, estabelecendo uma condição de agrupamento. É um recurso muito utilizado na confecção de relatórios. Para exemplificar, temos as tabelas CLIENTES e PEDIDOS: Código Clientes 1 Gustavo Viegas Nome 2 Vinicius Andrade 3 Rosangela Mattos Pedidos Código CodCliente Data Valor /10/ /10/ /10/ /01/ /10/ /10/ SELECT CODCLIENTE, MAX(VALOR) FROM PEDIDOS GROUP BY CODCLIENTE O comando acima retorna o maior valor de pedido de cada cliente. Observe o resultado: CodCliente Resultado 6 MAX (Valor)

11 Guia Rápido da SQL SELECT CODCLIENTE, COUNT(*) FROM PEDIDOS GROUP BY CODCLIENTE Aqui vemos quantos pedidos foram feitos por cada cliente. Veja o resultado: CodCliente Resultado 7 COUNT(*) HAVING Através do comando HAVING podemos filtrar a cláusula GROUP BY. Observe o comando abaixo: SELECT CODCLIENTE, COUNT(*) FROM PEDIDOS GROUP BY CODCLIENTE HAVING COUNT(*) >= 2 CodCliente Resultado 8 COUNT(*) Somente os clientes com 2 ou mais pedidos serão selecionados. Repare que o HAVING é utilizado, geralmente, com alguma função de agrupamento. Para filtros normais, pode-se utilizar o comando WHERE. Observe o exemplo abaixo: SELECT CODCLIENTE, COUNT(*) FROM PEDIDOS WHERE DATA > 06/10/2002 GROUP BY CODCLIENTE HAVING COUNT(*) >= 2 CodCliente Resultado 9 COUNT(*) 3 2 Repare que o cliente número 3 apresentou apenas dois pedidos, visto que o primeiro não possui data maior que 6/10. NOTA A formatação no uso de campos do tipo DATE pode sofrer alterações de acordo com o banco utilizado. Consulte o manual de referência do mesmo para maiores detalhes. Conclusão O uso correto do comando SELECT fornece uma poderosa interface de filtro. Utilizando sempre a sintaxe padrão, o desenvolvedor conta com maior independência de plataforma, pois o SQL ANSI é compreendido pelos principais bancos de dados. Existem ainda funções especiais e funções de conversão, que serão abordados em futuras edições da SQL Magazine. Para maior eficiência no uso do SELECT, é desejável também o bom planejamentos dos índices do banco. Para maiores informações a respeito do uso de índices, leia a matéria de Everson Ramos, publicada nesta edição. Espero que este artigo introdutório sirva de consulta em seus projetos! websites ClubeDelphi SQLAutor Gladstone Matos é coordenador das revistas ClubeDelphi, Java Magazine e SQL Magazine.. Pode ser contactado através do gladstone@clubedelphi.net ANUNCIO SQL Magazine - 11

12 Otimização de comandos SQL por Everson Volaco M esmo um aplicativo bem projetado poderá experimentar problemas de desempenho se a frase SQL que usa for mal construída. Falhas no projeto do aplicativo e na construção do SQL causam a maioria dos problemas de desempenho em bancos de dados projetados adequadamente. Veremos neste artigo como melhorar o comando SQL, para garantir maior performance em sua execução, tendo como base o ORACLE. A forma como o banco de dados se organiza para responder a requisição de um aplicativo é diretamente influenciada pela maneira como a frase SQL é construída. Existem vários pontos a serem observados nesta construção. O caminho mais curto é o uso de índices para auxiliar a pesquisa mas, é importante observar, a simples criação de um índice nem sempre é o melhor caminho para otimização de comandos SQL. Alguns conceitos importantes Antes de partir para como e quais as melhores formas de se aplicar e se escrever comandos SQL é importante relembrarmos alguns conceitos importantes. Existem dois métodos básicos utilizados pelos SGDB s para localizar dados, também conhecidos como caminhos de acesso. São eles: -Full Table Scan: Leitura seqüencial, bloco por bloco, de toda a tabela. Neste método, são verificados registro a registro os critérios de seleção. -Index Search: Procura de um índice sobre a coluna definida no critério de seleção, identificando a localização dos registros qualificados. O ORACLE possui seu próprio mecanismo de otimização, chamado A simples criação de índices nem sempre é o melhor caminho para otimização de comandos SQL otimizador, para executar comandos SQL e dinamicamente determinar que caminho de acesso seguir, dependendo das informações disponíveis. O melhor caminho de acesso é, geralmente, o uso de índices, mas isso nem sempre é verdadeiro. Por exemplo, se existir uma forma de identificar diretamente um registro pelo seu endereço físico, a resposta será mais rápida. (neste caso estamos falando do rowid, endereço físico do registro em uma tabela ORACLE). Ex.: SELECT rowid INTO :emp_rowid FROM EMP WHERE emp.empno = 5353 FOR UPDATE OF emp.ename; UPDATE emp SET emp.ename = OTIMIZADOR WHERE rowid = :emp_rowid;

13 Otimização de Comandos SQL Excluindo registros duplicados: DELETE FROM emp e WHERE e.rowid > (SELECT MIN(x.rowid) FROM emp x WHERE x.empno = e.empno); Algumas informações para auxiliar o acesso do otimizador: Verificar nas colunas dentro da cláusula WHERE: - Que colunas são índices; - Que colunas estão definidas como NOT NULL; - Que índices podem ser usados. É possível ajudar o otimizador a procurar o melhor caminho de acesso através da criação de índices e clusters, o que será considerado a partir de agora. Regras de Utilização de Índices Um índice será usado se : - o índice existir; - a coluna índice for referenciada na cláusula WHERE; Um índice pode ser usado para testes de: - Igualdade: SELECT e.empno, e.ename FROM emp e WHERE e.job = CLERK ; - Intervalo ilimitado: SELECT e.empno, e.ename FROM emp e WHERE e.job > CLERK ; - Intervalo limitado: SELECT e.empno, e.ename FROM emp e WHERE e.job BETWEEN CLERK AND JONES ; A criação de índices deve ser feita com critério. A atualização (inserts, updates e deletes) em tabelas de dados gera uma ação equivalente nos índices, sendo que o tempo de atualização dos índices é superior ao de atualização da tabelas, pois além da colocação do registro em seqüência dentro do índice é necessário a atualização dos ramos das árvores do índice. Considerando os detalhes acima, índices devem ser criados somente quando necessário, pois a sua simples existência não implica em melhoria de performance, podendo muitas vezes ser a origem de perda de performance. Condições de não utilização de Índices 1) Funções ou Operadores Aritméticos Se a coluna índice for modificada por uma função ou por operadores aritméticos (+,-,*,/), o índice não será utilizado. Um índice sobre SAL ou ENAME não será utilizado nos seguintes casos: SELECT e.ename, e.empno FROM emp e WHERE e.sal*12 = 2400; SELECT e.ename, e.empno FROM emp e WHERE SUBSTR(e.ename,1,3) = JON Nos casos acima, as seguintes modificações permitem o uso de índice: SELECT e.ename, e.empno FROM emp e WHERE e.sal = 2400/12 SELECT e.ename, e.empno FROM emp e WHERE e.ename LIKE JON% 2) Conversão de Dados A conversão de dados pode inibir a utilização do índice da coluna em questão se usado inadvertidamente. Na seguinte sentença, um índice sobre a coluna HIREDATE não será usado: SELECT e.ename, e.empno FROM emp e WHERE TO_CHAR(e.hiredate, month dd,yyyy ) = january 23,1982 Esta mesma sentença SQL, modificada, usará o índice como segue: SELECT e.ename, e.empno FROM emp e WHERE e.hiredate = to_date( january 23,1982, mounth dd,yyyy ) Se na cláusula WHERE os predicativos utilizam dados de tipos diferentes, o ORACLE automaticamente converte um deles sem a preocupação sobre a melhor escolha para a utilização dos índices. A conversão por default é escolhida, pelo caso mais comum (Ex.: O valor de uma coluna, onde o tipo é number, rowid ou date, comparado com uma constante de tipo char). Em qualquer caso é muito recomendado o controle da conversão dos dados de maneira explícita. 3) Caso de colunas com valores NULL Os índices não contêm referência para valores do tipo null. Isto quer dizer que os valores null podem ser recuperados somente através de uma leitura seqüencial completa da tabela (Full Table Scan). No comando abaixo o índice sobre a coluna COMM não será utilizado: SELECT e.ename, e.empno FROM emp e WHERE e.comm is null Neste código o otimizador considera que a maioria dos registros dentro da tabela são valores not null e irá escolher a leitura seqüencial (Full Table Scan): SELECT e.ename, empno FROM emp e WHERE e.comm > = 100 Se a maioria dos registros contiver valores não nulos, a cláusula comm is not null será mais rápida. A velocidade de execução dependerá dos dados da tabela. Se a maioria dos registros contiver valores não nulos, a cláusula comm is not null será mais rápida. Os índices concatenados não terão referência para os registros onde todas as colunas que o compõem tiverem valores nulos. 4) Caso de predicados com a condição NOT EQUAL Os índices sobre colunas referenciadas pela condição not equal não serão usadas. O otimizador considera que o número de registros que irão satisfazer a condição será maior do que os registros que não a satisfazem. O índice sobre DEPTNO não será usado na seguinte sentença SQL: SELECT e.ename, e.empno FROM emp e WHERE e.deptno!=10 No comando abaixo, o índice sobre deptno será utilizado: SELECT e.ename, e.empno FROM emp e WHERE not e.deptno > 20 O ORACLE executará a sentença SQL como e.deptno <= 20 5) Casos de sentenças SQL com cláusula ORDER BY A cláusula ORDER BY aumenta consideravelmente a necessidade de recursos para execução de uma sentença SQL. Em geral, tabelas temporárias serão necessárias para operação de sort. É possível evitar a utilização de tabelas temporárias se um índice sobre a coluna alvo do order by existir. As seguintes condições devem ser cumpridas: - A coluna order by deve ser definida com not null; - A coluna order by deve ser uma simples coluna índice ou as primeiras colunas de índice concatenado; - A cláusula order by deve conter somente colunas e não expressões; - Não deve haver qualquer cláusula group by, distinct ou for update; - Não deve haver nenhum outro aces- SQL Magazine - 13

14 so alternativo que seja prioritário sobre o índice da coluna order by; A seguinte sentença SQL será executada via índice em DNAME se os requisitos mencionados acima forem respeitados: SELECT d.dname FROM dept d order by d.dname; SELECT d.dname, d.deptno FROM dept d WHERE d.loc = dallas order by d.dname; SELECT d.dname, d.loc FROM dept d WHERE d.dname!= accouting order by d.dname; Na sentença abaixo, se um índice sobre a coluna LOC existir, tornar-se-á prioritário e o índice sobre dname não será usado: SELECT d.dname, d.deptno FROM dept d WHERE d.loc = dallas order by d.dname; 6) Casos de sentenças SQL contendo funções MAX ou `MIN Um índice será usado para executar uma sentença SQL com MAX ou MIN se as seguintes condições forem satisfeitas: - MAX ou MIN devem ser apenas expressões da lista de seleção; - A lista de seleção não deve ter qualquer outro operador de concatenação ou adição a não ser somente MAX ou MIN; - A lista de seleção não deve conter qualquer outra coluna a não ser uma simples ocorrência da coluna como agrupamento de MAX ou MIN; - A sentença SQL não pode ser um JOIN; - A cláusula WHERE e group by não podem ser utilizadas; - A coluna alvo do MAX ou MAX deve ser indexada ou fazer parte das primeiras colunas de um índice concatenado. A seguinte sentença SQL utilizará um índice sobre a coluna SAL: SELECT (max(e.sal)*2) FROM emp e; 7) Sentenças SQL recuperam informações sobre uma simples tabela Uma sentença SQL pode ter vários índices únicos e/ou não únicos à disposição do otimizador. A escolha do índice a ser usado depende da presença de: - Índices únicos e não únicos: os índices 14 - Magazine SQL únicos serão favorecidos sobre os índices não únicos. - Vários índices não únicos : os registros identificados pelo caminho de acesso do índice condutor (o primeiro nome na sentença SQL) serão unidos com aquele identificado por outro índice. A meta é identificar os registros pertencentes a todos os índices. Se o otimizador não tiver clara escolha concernente a qual índice usar, então irá arbitrariamente escolher o primeiro mencionado dentro da sentença SQL como índice condutor (Driving Index). 8) Caso de sentença SQL com interseção de vários predicados de igualdade dentro da cláusula WHERE com índice não único. O índice não único será sorteado pela coluna rowid a fim de minimizar o número de comparações necessárias. Se nós temos índice não único sobre JOB e DEPTNO: É possível ajudar o otimizador a procurar o melhor caminho de acesso através da criação de índices e clusters SELECT e.ename FROM emp e WHERE e.job = manager and e.deptno = 20; a. Procura a primeira ou próxima referência do índice sobre job (driving index) contendo manager. b. Procura a primeira ou a próxima referência do índice deptno contendo valor 20. Compara as duas rowid. - Se as duas forem iguais, registro encontrado. Vai a próxima referência de a. e compara com a próxima referência de b.. - Se forem diferentes guarda a referência de a. e passa a próxima referência de b.. - c. Continua a procura até que não existam mais referências sobre o índice de job (driving index). 9) Caso de sentença SQL com interseção de um predicado de igualdade com um predicado sem limite, dentro da cláusula WHERE com índice não único. Somente o índice sobre a igualdade será usado. No exemplo que segue, se índices não únicos existirem sobre as colunas JOB e DEPTNO, o índice sobre JOB será utilizado, os registros correspondentes serão recuperados e verificada a validade do segundo predicado. SELECT e.ename FROM emp e WHERE e.job = manager and e.deptno > 10 10) Caso de índice Concatenado Índices concatenados são índices formados por várias colunas representados como se fosse simplesmente uma única coluna. a) Interseção de vários predicados de igualdade. Se um índice concatenado existir sobre DEPTNO e JOB, somente uma referência será necessária para localizar a rowid correspondente : SELECT e.ename FROM emp e WHERE e.job = manager and e.deptno = 10 b) Interseção de predicados sem limite com predicados de igualdade. Se um índice concatenado existir sobre DEPTNO e JOB, será utilizado para executar a seguinte sentença SQL : SELECT e.ename FROM emp e WHERE e.job = manager and e.deptno > 10 c) Interseção de predicado sem limite. Se um índice concatenado existir sobre DEPTNO e JOB, será utilizado para executar a seguinte sentença SQL: SELECT e.ename FROM emp e WHERE e.job > manager and e.deptno > 10 d) Utilização parcial ou total dos índices concatenados. O otimizador pode somente usar a ou as primeira(s) parte(s) do índice concatenado. No seguinte caso, um índice concatenado foi criado sobre as colunas EMP- NO, ENAME e DEPTNO: A seguinte sentença SQL usa plenamente o índice concatenado: SELECT * FROM emp e WHERE e.empno = 7369 AND e.ename = smith and e.depnto = 20 SELECT * FROM emp e WHERE e.ename = smith AND e.empno = 7369 AND e.deptno = 20 As seguintes sentenças SQL utilizam parcialmente o índice concatenado:

15 Otimização de Comandos SQL Uso parcial do índice usando somente EMPNO e ENAME: SELECT * FROM emp e WHERE e.empno = 7369 and e.ename = smith Uso parcial do índice usando somente EMPNO e ENAME : SELECT*FROM emp e WHERE e.empno = 7369 and e.deptno = 20 As seguintes sentenças SQL não usam o índice : SELECT * FROM emp e WHERE e.ename = smith and e.deptno = 20 SELECT * FROM emp e WHERE e.ename = smith SELECT * FROM emp e WHERE e.deptno = 20 11) Casos de Índice único e não único na mesma sentença SQL. O otimizador favorecerá a utilização do índice único. No seguinte caso o índice não único existe em SAL e um índice único em EMPNO : SELECT e.ename FROM emp e WHERE e.sal = 3000 and e.empno = 7902 O índice único será usado para procurar a rowid correspondente ao empno = Nos registros recuperados serão verificados o valor de sal. 12) Caso de vários índices na mesma sentença SQL. Se vários índices únicos estão disponíveis, o otimizador irá escolher o primeiro mencionado na sentença SQL. Por exemplo, se índices únicos existirem sobre ENAME e EMPNO, e um índice não único existir sobre SAL, a seguinte sentença SQL será executada sobre o índice ENAME SELECT e.deptno FROM emp e WHERE e.sal = 3000 and e.ename = scott and e.empno = 7602 Otimização da cláusula OR (União de predicados) O caminho de acesso é determinado como se a cláusula OR e suas ramificações estivessem ausentes. O caminho é determinado considerando cada ramificação da cláusula OR separadamente. Exemplo A Índice existente sobre SAL e JOB. SELECT e.ename FROM emp e WHERE e.deptno = 10 AND (e.sal = 3000 or e.job = clerk ) Neste caso, o caminho de acesso identificado por 2 é melhor que o identificado por 1, então a cláusula OR é otimizada para utilização dos índices. 1)Para DEPTNO = 10 - Pesquisa seqüencial na tabela; 2) Para SAL = Índice não único sobre SAL; Para JOB = clerk - Índice não único sobre JOB; Exemplo B Somente índice sobre SAL utilizando a mesma sentença do exemplo Os dois caminhos de acesso identificado por 2 não são melhores que o identificado por 1, então os índices não serão utilizados e ocorrerá uma pesquisa seqüencial na tabela. O otimizador na Cláusula OR exige a presença dos índices utilizáveis dentro de cada coluna referenciada dentro da cláusula OR. Verificando o Caminho de Acesso do otimizador Podemos verificar o caminho de acesso utilizado pelo SGDB para executar uma determinada frase SQL. Chamaremos esse caminho de Acesso de Plano de Execução. No plano de execução são verificados todos os procedimentos feitos pelo SGDB, como utilização ou não de índices, clusters, rowid, além da verificação da quantidade de passos realizados pelo banco para execução do comando. Este procedimento é muito útil, pois pode ser utilizado como recurso para verificarmos se as alterações efetuadas em um comando realmente otimizam a execução do mesmo. A verificação do plano de execução é feita no Oracle através do comando EXPLAIN PLAN. A sintaxe do comando é a seguinte: EXPLAIN PLAN SET STATEMENT_ID = COMAND_ID INTO OUTPUT FOR COMANDOSQL; Onde: Análise Análise 1)Para DEPTNO = 10 - Pesquisa seqüencial na tabela; 2) Para SAL = Índice não único sobre SAL; Para JOB = clerk - Pesquisa sequencial na tabela. - COMAND_ID é um String identifica- dor para posterior visualização do plano de execução. - OUTPUT é tabela onde o plano de execução é gerado. O usuário que executar o EXPLAIN PLAN deve ter direitos de INSERT sobre a mesma. O comando para criação desta tabela émostrado da listagem1. O Script para criação desta tabela chama-se UTLXPLAN.SQL e é instalado juntamente com oracle e a sua localização depende da versão do banco. - COMANDOSQL é o comando a ser analisado. Para verificação do plano de execução gerado pelo EXPLAIN PLAN devemos consultar a tabela informada no comando. Este procedimento pode ser efetuado de várias maneiras, uma delas é a que segue: SELECT SUBSTR(LPAD(,2*(LEVEL-1)) operation,1,50) operation, options, object_name, position FROM OUTPUT START WITH id = 0 AND statement_id = COMAND_ID CONNECT BY PRIOR id = parent_id AND statement_id = COMAND_ID ; Onde, - COMAND_ID é um String identificador do plano de execução informado no EXPLAIN PLAN Listagem 1. create table NOME_DA_TABELA ( statement_id varchar2(30), timestamp date, remarks varchar2(80), operation varchar2(30), options varchar2(30), object_node varchar2(128), object_owner varchar2(30), object_name varchar2(30), object_instance numeric, object_type varchar2(30), optimizer varchar2(255), search_columns number, id numeric, parent_id numeric, position numeric, cost numeric, cardinality numeric, bytes numeric, other_tag varchar2(255), partition_start varchar2(255), partition_stop varchar2(255), partition_id numeric, other long, distribution varchar2(30)); SQL Magazine - 15

16 - OUTPUT é tabela onde o plano de execução é gerado. Vamos exemplificar a execução do EXPLAIN PLAIN validando a seguinte informação: Um índice é utilizado se ele existir e se a coluna que faz parte deste índice estiver contida na clausula WHERE do comando SQL. Este mesmo índice não é utilizado se existirem funções de conversão de dados envolvendo esta coluna. Em outras palavras: a execução do comando SELECT * FROM EMP WHERE EMPNO = 50 utilizará o índice da chave primária, que contém a coluna EMPNO, e a execução do comando SELECT * FROM EMP WHERE TO_CHAR(EMPNO) = 50, não utilizará o índice. Utilizaremos o comando do quadro em destaque acima para criação da tabela que receberá o plano de execução, com o nome de PLAN_TABLE. Em seguida executaremos o EXPLAIN PLAN para verificação da utilização do índice com o seguinte comando: EXPLAIN PLAN SET STATEMENT_ID = SQLMagazine Com Indice INTO PLAN_TABLE FOR SELECT * FROM EMP WHERE EMPNO = 50; A verificação do plano de execução é feita de seguinte forma: SELECT SUBSTR(LPAD(,2*(LEVEL-1)) operation,1,50) operation, options, object_name, position FROM PLAN_TABLE START WITH id = 0 AND statement_id = SQLMagazine Com Indice CONNECT BY PRIOR id = parent_id AND statement_id = SQLMagazine Com Indice ; O resultado com o plano de execução é mostrado na Tabela 2. Analisando este resultado comprovamos que o índice referente a chave primária foi utilizado. Vamos verificar agora o mesmo comando alterado: EXPLAIN PLAN SET STATEMENT_ID = SQLMagazine Sem Indice INTO PLAN_TABLE FOR SELECT * FROM EMP WHERE TO_CHAR(EMPNO) = 50 ; A verificação do plano de execução é feita de seguinte forma: SELECT SUBSTR(LPAD(,2*(LEVEL-1)) operation,1,50) operation, options, object_name, position FROM PLAN_TABLE START WITH id = 0 AND statement_id = SQLMagazine Sem Indice CONNECT BY PRIOR id = parent_id AND statement_id = SQLMagazine Sem Indice ; Este resultado mostra que a utilização do índice foi anulada pela função aplicada OPERATION OPTONS OBJECT_NAME select statement table access by index rowid emp index unique scan pk_emp OPERATION OPTONS OBJECT_NAME select statement table access full emp a coluna. Conclusão Os cuidados a serem tomados com o acesso a dados da aplicação são parte importante de um projeto. A forma como as consultas são escritas e como o banco de dados está projetado influencia diretamente na performance do produto. Esses fatores não devem andar separados. Na maioria dos casos é necessária a perfeita integração entre a consulta escrita e o estado do banco de dados. Muitas vezes uma simples arrumação na consulta, trocando algumas cláusulas ou mudando um pouco a lógica das condicionais, garante um ganho na velocidade de execução e resposta da mesma. Não esqueça nunca de analisar se o índice a ser criado é realmente necessário, para não adicionar um mais um processo para o seu banco. Boa sorte e bons projetos! ANUNCIO 16 - Magazine SQL

17 Otimização de Comandos SQL ANUNCIO SQL Magazine - 17

18 Modelagem de dados com SQL por Cleison Santos Coloca-se como de fundamental importância tanto a análise como a modelagem de dados para o processo de desenvolvimento de aplicações. Esses procedimentos garantem um maior controle das diversas etapas do projeto desde a de nição das regras do negócio até a implementação e manutenção da aplicação como um todo. Existem no mercado, atualmente, diversas ferramentas para modelagem de dados, dentre as quais pode ser destacado o software ErWin. O ErWin pode ser usado de uma forma simples e prática possibilitando uma melhor visualização, controle e documentação do que se tem no banco de dados. Através dos diversos recursos disponíveis (Figura 1) podemos desenhar o nosso banco de dados definindo as entidades de que compõe o modelo com seus respectivos atributos e relacionamentos, definir características dessas entidades tornandoas reais em um modelo físico ou em vários modelos físicos se for necessário o acesso a SGDB s distintos. Podemos ainda criar, de forma automática, o modelo implementado num banco de dados ou gerar scripts Figura 1. Tela inicial do ErWin para atualização de alterações efetuadas no modelo, sincronizar dois bancos de forma a garantir uma estrutura idêntica em ambos, e vários outros recursos. Na parte superior direita, observa-se uma barra de ferramentas com os principais objetos do ErWin, como mostrado na Figura 2, a seguir: Alguns conceitos importantes 1) Entidades - Entidade é o local onde ficam armazenadas as informações. Por exemplo, a Entidade CLIENTES pode guardar informações referentes aos clientes, e assim sucessivamente. 2) Subtipos - Podem ser definidos como um espelho de uma ou mais entidades. Por exemplo, pode-se criar um subtipo chamado CLIENTES_RJ que contenha somente os clientes que moram no Rio de Janeiro, podendo ter ou não todos os

19 Modelagem de Dados com ErWin Entidades Figura 2. Barra de ferramenta do ErWin Criar subtipos de entidades existentes Inserir textos no modelo, como comentário de entidades, relacionamentos e outros Relacionamento de cardinalidade um para muitos Relacionamento de cardinalidade muitos para muitos Relacionamento de cardinalidade um para um Auxilio para mudar os atributos de posição ou de entidades atributos da Entidade CLIENTES. 3) Atributos - Os atributos podem ser definidos como identificadores de cada informação contida na entidade. O Código do Cliente, por exemplo, é um atributo da Entidade CLIENTES. 4) Relacionamentos - Relacionamentos são definidos como a ligação entre duas ou mais entidades. 5) Cardinalidade - É o que caracteriza o relacionamento.por exemplo: um pai pode ter mais de um filho, porém um filho só pode ter apenas um pai. Isso quer dizer que a cardinalidade define o comportamento do relacionamento, definindo-o como um para muitos, muitos para um ou até muitos para muitos. Os tipos de modelo Modelo Lógico: É o modelo de abstração do sistema. Neste, detalhes como qual banco de dados será usado, o tipo de campo, o tipo de hardware, entre outros aspectos não são relevantes. Aqui, somente as necessidades do processo são definidas, dando uma visão global do sistema. No Erwin, podemos ter uma visão da regra de negócio, ou seja, podemos planejar uma estrutura lógica para o banco de dados, onde são definidas as validações, as restrições da regra de negócio, a análise das entidades e dos atributos definidos para a aplicação como um todo. Modelo Físico: É onde os detalhes são definidos. Serve como um espelho de tudo o que está no banco de dados, permitindo controlar características de tabelas e colunas (conhecidos no modelo lógico como Entidades e Atributos) de forma particular para o SGDB utilizado além de possibilitar a definição de Procedures, Triggers e outros processos. Criando o modelo lógico O tipo de modelo que está sendo visualizado encontra-se na Combo situada logo acima da barra de ferramentas, mostrada na Figura 1. O modelo utilizado inicialmente será o modelo lógico, pois começando por este fica mais fácil definir o outro. Isso porque, como já foi visto, no modelo lógico tem-se um melhor controle da aplicação, sendo possível definir as validações necessárias, tanto para a regra de negócio como para a implementação de banco de dados no modelo físico. Posteriormente, podem ser criados modelos físicos para acessar a diferentes bancos de dados a Figura 4. Editor de Atributos partir do mesmo modelo lógico. Será criado um modelo simples, onde definiremos algumas entidades com seus respectivos atributos e relacionamentos mostrando como utilizar alguns dos muitos recursos disponíveis no ErWin para modelagem de dados. O modelo será feito com base em um sistema comercial com as tabelas CLIENTES, VENDEDO- RES, PRODUTOS, FORNECEDORES, PEDIDOS E ITENS_PEDIDOS. Criando as Entidades Como já visto, as entidades podem ser criadas através do primeiro objeto da barra de ferramentas, clicando nesta, arrastando para o modelo e trocando o seu nome, como mostrado na Figura 3. Criando os Atributos Para criar os atributos, basta apenas dar um duplo clique na entidade. É possível criar novos atributos, renomear ou excluir um atributo já existente, como mostrado na figura 4. Pode-se, também, ao lado direito da tela, definir várias características do atributo como chave primária na opção Primary Key ou Requerido na opção Required. Figura 3. Criação da Entidade Clientes Figura 5. Editor de Relacionamentos entre entidades SQL Magazine - 19

20 Figura 6. Modelo lógico com entidades, atributos e relacionamentos. Figura 8. Modelo Físico com Tabelas, Colunas e Relacionamentos Figura 7. Editor de Coluna Criando os Relacionamentos Para definir um tipo de relacionamento, basta escolher um dos três objetos já mostrados da barra de ferramentas, clicar na tabela pai e depois na tabela filho. Automaticamente, o relacionamento escolhido é visualizado. A figura 5 mostra o editor de Relacionamento e suas funcionalidades. Ao dar um duplo clique sobre o relacionamento esta tela é automaticamente aberta. Nela definimos a cardinalidade do relacionamento, assim como a nulidade dos campos que estão sendo relacionados. A figura 6 mostra o modelo totalmente criado, com suas entidades, atributos e respectivos relacionamentos. Figura 9. Target Server Configuração do Banco de Dados 20 - Magazine SQL Criando o modelo físico Após criar todo o modelo lógico é necessária a definição dos atributos do modelo físico. Para alternar entre os modelo físico e lógico basta selecionar na Combo situada logo acima da barra de ferramentas, mostrada na Figura 1. No modelo físico iremos definir características das entidades e atributos criados no modelo lógico de acordo com o SGDB utilizado. Neste modelo temos uma visão real das tabelas, colunas, procedures, triggers e outros objetos do nosso banco. A figura 7 mostra o Editor de Coluna do modelo físico. Conforme o observado no modelo físico, não existem mais Entidades e Atributos, e sim Tabelas e Colunas, nomes comuns ao banco de dados. O editor de coluna permite alterar o tipo e tamanho de cada campo, assim como definir se ele pode ou não receber valores nulos. Ainda pode-se utilizar a aba Comment para comentar cada campo, assim como cada tabela. Criando o banco de dados a partir do Modelo Físico criado Terminada a implementação é necessário criar os objetos definidos no ErWin em um banco de dados. Para isso, é preciso fazer o modelo apontar para o SGDB a ser utilizado acessando-se o menu: Server\Target Server. Além da seleção do SGDB e da versão do mesmo é possível definir opções referentes ao tipo de dados e a nulidade default para as colunas definidas no modelo bem como máscara para nomenclatura automática de índices e tabelas. Vide Figura 9. Após as configurações do Target Server, basta acessar o menu Tasks\Forward Engineer/Schema Generation para criar o banco de dados. Vide Figura 10. Utilizaremos um banco criado no Oracle. Como se pode ver a tela é bem intuitiva. Na pasta Summary indicamos os objetos do nosso modelo ( tabelas, colunas, índices, triggers, etc.. ) que serão criados no banco. Ao clicar no botão Generate, o banco é criado, automaticamente, com todas as tabelas, campos e relacionamentos demonstrados no modelo físico. A Figura 11 mostra os scripts com todos objetos gerados no banco de dados a partir do modelo implementado. Criando um modelo a partir de um banco existente Em muitos casos, o banco de dados já está totalmente implementado, sendo necessária a criação do modelo a partir deste. Este processo chama-se Engenharia Reversa, e é acessado pelo menu Tasks\Reverse Engineer. A primeira tela a ser exibida é a ErWin Template Selection, onde escolhe-se a opção Blank Diagram para criar o modelo do zero. Ao clicar em Next, depara-se com a tela Select Taget Server, onde é informado o tipo de banco de dados a ser utilizado e a sua versão. Clicando-se mais uma vez no botão Next, surge a tela Set Options onde são definidos procedimentos necessários à realização da engenharia reversa. Vide figura 12. Figura 10. Tela de geração de banco de dados