Gerenciando bancos de dados na nuvem: o que você precisa saber

O último Relatório de tendências em TI da SolarWinds revelou que 95% das organizações brasileiras migraram aplicativos e infraestrutura críticos para a nuvem nos últimos 12 meses, com cargas de trabalho de bancos de dados entre os três principais. O relatório descobriu não só que muitas organizações estão percebendo os benefícios da computação em nuvem (como economia, disponibilidade e escalabilidade), mas também que os ambientes de TI híbrida resultantes criam novos desafios. Na verdade, por classificação ponderada, o principal desafio criado pela TI híbrida é a maior complexidade de infraestrutura, seguido pela falta de controle/visibilidade do desempenho de aplicativos e da infraestrutura baseados na nuvem.

De todos os aplicativos e infraestruturas que estão migrando para a nuvem, há um interesse especial no banco de dados. Os aplicativos estão no cerne da empresa moderna, e os bancos de dados estão no cerne de todos os aplicativos. Como resultado, os bancos de dados em migração para a nuvem muitas vezes podem apresentar mais obstáculos do que o esperado. Para ajudar os administradores de bancos de dados (DBAs, Database Administrators) a se prepararem melhor para executar a migração de banco de dados para a nuvem, vou explorar o que eles mais precisam saber, começando com as considerações principais antes da migração.

Chegando à nuvem

Com uma variedade de parâmetros de aplicativos e dados a serem considerados, a simples chegada à nuvem pode ser um grande desafio. Há dois caminhos principais até a nuvem: primeiro, o clássico “lift-and-shift”. É aqui que os departamentos de TI transferem os dados atuais para a nuvem, o que exige pouca ou nenhuma personalização e arquitetura. O segundo caminho é um processo mais complexo, que exige que o DBA comece do zero e crie e personalize uma infraestrutura que atenda melhor às necessidades do banco de dados hospedado pela nuvem.

Cada caminho tem seus prós e contras. Por exemplo, apesar de o cenário de lift-and-shift parecer fácil, muitos fatores devem ser considerados para garantir que o desempenho dos aplicativos não seja prejudicado como resultado da transição. De maneira semelhante, sem o planejamento adequado, os DBAs correm o risco de dimensionar os servidores incorretamente ou de ter seu desempenho inesperadamente reduzido porque o banco de dados não é mais hospedado localmente. Na verdade, 30% dos profissionais de TI afirmaram que já migraram aplicativos de volta para o local por esse mesmo motivo.

No entanto, isso não significa que começar com uma infraestrutura nova para fins específicos é algo simples. Os DBAs ainda precisam determinar a melhor forma de migrar seus dados existentes e considerar o risco da perda de dados. Além disso, a arquitetura de nuvem de uma organização costuma ser projetada fora da influência dos DBAs, o que não é ideal. Os DBAs devem procurar uma função ativa no início do processo e, se não for tarde demais para isso, entender por que certas decisões foram tomadas e ser um impulso para a mudança, se necessário. Isso ajudará a garantir que o Objetivo do tempo de recuperação (RTO, Recovery Time Objective) e o Objetivo do ponto de recuperação (RPO, Recovery Point Objective) sejam adequados para manter a proteção dos dados da organização. Por exemplo, eles devem ajudar a garantir que as replicações geográficas estejam instaladas para manter os aplicativos online em caso de interrupção.

O relacionamento com o provedor de serviços de nuvem e um conhecimento profundo sobre o SLA da organização também são importantes para que os DBAs tenham sucesso na era da TI híbrida. Não se esqueça de que alguns provedores de serviços de nuvem aceitam discos rígidos enviados, outros possuem conexões dedicadas de alta velocidade, e outros ainda oferecem orientações de arquitetura para atuar como “guias de migração de banco de dados”.

Desafios da nuvem

Depois que o departamento de TI migra um banco de dados para a nuvem, ainda há desafios associados com o gerenciamento e a otimização do banco de dados. Uma das coisas mais difíceis para os DBAs ajustarem é a falta de acesso local (o que se traduz em controle e governança) aos servidores em que o banco de dados está hospedado, já que agora eles estão fora do local. No entanto, trata-se de uma faca de dois gumes, pois com a perda de acesso local também elimina-se (em parte) a necessidade do gerenciamento diário dos bancos de dados. No entanto, a responsabilidade final pelo desempenho e pelo ROI ainda recai inequivocamente sobre o DBA.

Para isso, os DBAs devem conhecer todos os serviços oferecidos pelos provedores de nuvem; apesar de esses serviços serem capazes de ajudar no processo de gerenciamento e na otimização do desempenho dos aplicativos, a grande maioria dos serviços disponíveis para implantação indica que uma organização pode estar pagando por serviços que não são mais necessários.

Pense na infinidade de canais de televisão em HD disponíveis hoje. Há alguns anos, os consumidores pagavam para ter cerca de 15 canais HD específicos. Agora, o HD se tornou padrão e, com o surgimento de cada vez mais canais, os telespectadores estão pagando para acessá-los sem sequer se dar conta disso. O mesmo vale para serviços de nuvem.

Da mesma forma, para qualquer aplicativo ou carga de trabalho na nuvem, é essencial que os DBAs responsabilizem os provedores pelas métricas de desempenho descritas no SLA. Mesmo que, na computação em nuvem, uma carga de trabalho seja tecnicamente gerenciada por outra pessoa, os DBAs ainda são os responsáveis finais pelo sucesso das cargas de trabalho hospedadas pela nuvem. Sendo assim, é necessário estar sempre a par dos novos serviços e recursos, analisar a arquitetura recomendada e estar no controle da manutenção programada que possa afetar o desempenho dos aplicativos.

Resumindo, é essencial pensar na nuvem como uma parceria, trabalhando com o provedor de serviços para garantir que as necessidades da organização estejam sendo atendidas de acordo com o SLA.

Práticas recomendadas para o gerenciamento da nuvem do banco de dados

Migrar estrategicamente um banco de dados para a nuvem pode proporcionar ótimos resultados não só para a TI, mas também para os resultados financeiros da empresa. No entanto, os desafios associados a atingir esse objetivo e depois gerenciar os bancos de dados na nuvem podem ser um grande obstáculo para sua adoção. Para ajudar os DBAs a superar esses empecilhos e ter um banco de dados otimizado e bem-sucedido na nuvem, veja algumas das práticas recomendadas que se deve ter em mente:

A estratégia é a solução: Antes de migrar qualquer coisa para a nuvem (ainda mais uma infraestrutura complexa como o banco de dados), os DBAs devem parar e decidir fazer o lift-and-shift ou criar uma arquitetura de nuvem personalizada. Não existe uma resposta única, tudo depende das necessidades de cada organização depois de decidir qual caminho afetará de maneira menos negativa o desempenho do banco de dados. O aproveitamento de uma solução abrangente de monitoramento que cria métricas de desempenho de linha de base para todos os aplicativos e cargas de trabalho pode ajudar a orientar essa decisão. Além disso, um mapa realizado antes da transição ajudará a reduzir custos e dores de cabeça relacionados à carga de trabalho. Isso inclui ter um entendimento básico dos recursos e SLAs do provedor de serviços, bem como uma análise detalhada das agendas de arquitetura e manutenção recomendadas. E lembre-se: a nuvem não é uma solução definitiva. Um banco de dados com baixo desempenho no local terá um baixo desempenho na nuvem se a causa raiz não for solucionada.

  • Estabeleça uma relação de confiança com o provedor de serviços da nuvem: Conforme mencionado, a nuvem deve ser vista como uma parceria, na qual o departamento de TI interno e o provedor de serviços estão em sincronia, para que se obtenham os melhores resultados. No fim das contas, entretanto, o DBA ainda é responsabilizado quando as métricas de desempenho não são alcançadas. Por isso, é importante “confiar, mas verificar”, implementando o monitoramento de TI híbrida além do que é normalmente oferecido pelos provedores de serviço de nuvem. Isso garante que haja dados e visibilidade para entender realmente como as cargas de trabalho atuam na nuvem e os motivos para esse desempenho.
  • Obtenha uma visualização única: Os DBAs modernos precisam de ferramentas de gerenciamento e monitoramento abrangentes que forneçam um único painel de desempenho e a capacidade de fazer drill down em tecnologias de banco de dados e em métodos de implantação, incluindo a nuvem. Isso garantirá que as organizações não desperdicem orçamento valioso investigando um problema de desempenho de banco de dados com a solução errada. Com um conjunto de dados mais amplo e maior visibilidade, os DBAs de nuvem podem passar de um potencial problema de desempenho para outro mais rapidamente e diagnosticá-los e resolvê-los da forma correta.
  • Fique atento às mudanças: Agora, as atualizações de softwares e serviços são lançadas em um ritmo nunca antes visto, muitas vezes com pequenas novidades surgindo a cada dois ou três meses. O DBA precisa pensar criticamente sobre essas mudanças, bem como outras tendências no cenário de TI, perguntando-se constantemente: “isso é algo que possamos aproveitar? Se sim, esta é a escolha certa ou há opções melhores disponíveis?” O objetivo final precisa ser a melhor experiência geral para o negócio e os clientes. Isso pode significar que é hora de uma mudança, mas também pode significar que não é a hora certa.
  • Mude para uma mentalidade proativa: Em vez de apagar incêndios, os DBAs devem mudar para funções estratégicas projetadas para melhorar proativamente o banco de dados. Isso criará mais tempo para adquirir conhecimentos sobre novas tecnologias e reduzirá custos. Essa mentalidade proativa e voltada para o desempenho exige enxergar além do consumo de recursos e reduzir consultas a metodologias voltadas a desempenho, como análise de tempo de espera.

Considerações finais

A migração de qualquer coisa para a nuvem exige uma mudança na estratégia de monitoramento e gerenciamento e também demanda atenção a considerações fundamentais antes da migração. Em particular, os bancos de dados na nuvem apresentam aos DBAs diversos obstáculos que devem ser superados. Ao aproveitar as práticas recomendadas acima, os DBAs podem encontrar sucesso na nuvem.

 

Sobre a SolarWinds
A SolarWinds oferece softwares avançados e acessíveis para o gerenciamento de TI a clientes em todo o mundo, desde empresas de pequeno porte até empresas listadas na Fortune 500®, provedores de serviços gerenciados (MSPs), órgãos do governo e instituições educacionais. Nossas soluções são fundamentadas em uma profunda conexão com nossa base de usuários, que interage em nossa comunidade online, a THWACK, para solucionar problemas, compartilhar tecnologias e práticas recomendadas e participar diretamente do nosso processo de desenvolvimento de produtos. Saiba mais em www.solarwinds.com/pt.

Conheça um pouco sobre o MySQL

1. MySQL

1.1. O que é MySQL?

MySQL é um banco de dados relacional, desenvolvido para plataformas Linux–like, OS/2, Windows. Sendo um software de livre distribuição para plataformas não-Windows que o utilizam em um servidor Web.

MySQL é um servidor multiusuário, multitarefa, compatível com o padrão SQL (Structured Query language – Linguagem de Consulta estruturada), linguagem essa amplamente utilizada para manipulação de dados em RDBMS (Banco de dados Relacionais), sendo considerada um ferramenta de manipulação de base de dados de tamanho moderado.

As principais características que destacam MySQL são: sua velocidade proporcionada pela sua implementação leve que não inclui na totalidade o suporte as instruções SQL; sua natureza de distribuição gratuita; facilidade de integração com servidor Web e linguagens de programação de desenvolvimento de sites dinâmicos, especialmente a linguagem PHP.

1.2. Breve Histórico

“O MySQL foi criado por Michael Widenius na companhia suíça TcX. Por volta de 1979 Michael desenvolveu um banco de dados chamado UNIREG, sendo rescritos em várias linguagens desde então” [YAR 99]. Em 1994, a empresa TcX começou o desenvolvimento de aplicações baseadas na Web, tendo como base o banco UNIREG, porém esse banco possuía muito “overhead” para obter sucesso em uma aplicação para geração de páginas dinâmicas na Web. Então a empresa TcX começou a procurar por outro banco o mSQL, uma ferramenta baseada em SQL mas com características pobres não possuindo por exemplo suporte a índices, e com desempenho inferior ao UNIREG.

Foi então que o desenvolvedor do banco UNIREG contatou o David Hughes criador do mSQL, para saber do interesse dele em unir os dois bancos. Sendo positivo o interesse de David , a empresa TcX resolveu desenvolver um novo banco, mas mantendo ao máximo a compatibilidade com mSQL. TcX foi esperta o suficiente para não reinventar o que já estava bem feito, ela construiu seu servidor baseado na estrutura que já estava montada do UNIREG e utilizou grande número de utilitários escritas para mSQL e fez API’s para o novo servidor praticamente iguais ao mSQL. Como resultado usuários do mSQL que decidissem mudar para o novo servidor da TcX, teriam apenas que fazer pequenas e simples mudanças nos códigos existentes.

Então foi me maio de 1995 que, definitivamente, a primeira versão do MySQL foi lançada. Um dos parceiros da TcX sugeriu a distribuição do servidor na Internet, o objetivo disso era a utilização de um modelo pioneiro desenvolvido por Aladdin Peter Deutsch. O resultado foi um maior flexibilidade em sem “copyright”, que fez do MySQL mais difundido gratuitamente do que mSQL.

1.3. Por que MySQL?

Sendo a concepção inicial do trabalho a utilização de ferramentas de livre distribuição para plataforma Linux-GNU, e o desenvolvimento de uma aplicação de banco de dados utilizando a Web como interface, fez-se necessário a escolha de um banco de dados que permitisse explorar as características básicas para implementação de uma aplicação cliente-servidor.

Entre as possibilidades encontradas surgiram três bancos de dados: MySQL, PostgreSQL e Interbase. O servidor PostgreSQL destacou-se por suas características de banco de dados objeto-relacional, permitindo explorar todas as possibilidades dos bancos relacionais, porém estendendo funções como classes, herança.

O MySQL foi o banco de dados escolhido por apresentar extensa documentação, milhares de sites na internet, mas principalmente pela sua fácil instalação e integração com o servidor Web.

Sua instalação através de RPM (RedHat Package Manager –Gerenciador de pacotes RedHat), é um processo simplificado, sendo criado toda a estrutura interna de arquivos no sistema operacional, bem como execução de scripts de inicialização e ajustes em arquivos de inicialização no servidor Web e módulo PHP.

1.4. Principais características

  • MySQL é um banco de dados multiprocessado, significando que pode utilizar vários processadores ao mesmo tempo.
  • Possui API’s para C, C++, Java, Perl, PHP, Phyton e TCL.
  • Foi desenvolvido para várias plataformas incluindo ambientes Unix, OS/2 e Windows.
  • Permite operações e funções nas cláusulas select e where, bem como suporte as funções SQL(group by , order by ), além de funções de grupo como: Count(), avg(), sum(), std(), max(), min().
  • Permite a seleção de diferentes tabelas de diferentes bases de dados em uma mesma query.
  • Suas características de privilégio de password são bastante flexíveis, permitindo inclusive a validação por “host”.
  • Possui algoritmos de criptografia de password, fornecendo assim segurança aos dados gravados nas tabelas.
  • Permite a utilização de até 16 índices por tabela.
  • Tem a capacidade para manipular bancos com até 50 milhões de registros.
  • MySQL foi escrito em C e C++.
  • Permite conexões via TCP/IP.
  • Permite acesso via ODBC.
  • Possui instruções para extração de informações relativas a tabelas, bancos, índices.

1.5. Política de uso na Web

A utilização de MySQL em sistemas operacionais não-Windows é gratuita se utilizada com um servidor WEB, não necessitando assim de licença para uso. Isso é válido mesmo que as aplicações Web que utilizem o banco sejam para fins comerciais, excluindo-se a comercialização do MySQL.

O suporte para MySQL pode ser contratado, no entanto para isso existem contratos de manutenção, sendo esses restritos as áreas de cobertura da equipe.

Autores: Lucas Lopes dos Santos e Ronaldo do Amaral

Bancos de Dados Orientados a Objetos – Conceitos Fundamentais

Bancos de Dados Orientados a Objetos

Hoje, os bancos de dados orientados a objetos são fator emergente que integram banco de dados e a tecnologia de orientação a objetos. Por um lado, a necessidade de realizar manipulações complexas para os banco de dados existentes e uma nova geração de aplicações de banco de dados geralmente requisitam mais diretamente um banco de dados orientado a objeto. Por outro lado, aplicações de linguagens orientadas a objeto e sistemas estão exigindo capacidades de banco de dados, tais como continuidade, simultaneidade e transações, dos seus ambientes. Estas necessidades estão levando à criação de sistemas poderosos, chamados banco de dados orientados a objeto.

Os bancos de dados orientados a objetos iniciaram-se primeiramente em projetos de pesquisa nas universidade e centros de pesquisa. Em meados dos anos 80, eles começaram a se tornar produtos comercialmente viaveis. Hoje, eles são mais de 25 produtos no mercado.

Conceitos Básicos de OODB

O desenvolvimento dos Sistemas de Gerenciamento de Bancos de Dados Orientados a Objetos (SGBDOO) teve origem na combinação de idéias dos modelos de dados tradicionais e de linguagens de programação orientada a objetos.

No SGBDOO, a noção de objeto é usada no nível lógico e possui características não encontradas nas linguagens de programação tradicionais, como operadores de manipulação de estruturas, gerenciamento de armazenamento, tratamento de integridade e persistência dos dados.

Os modelos de dados orientados a objetos tem um papel importante nos SGBDs porque, em primeiro lugar, são mais adequados para o tratamento de objetos complexos (textos, gráficos, imagens) e dinâmicos (programas, simulações). Depois, por possuírem maior naturalidade conceitual e, finalmente, por estarem em consonância com fortes tendências em linguagens de programação e engenharia de software. O casamento entre as linguagens de programação e banco de dados é um dos problemas que estão sendo tratados de forma mais adequada no contexto de orientação a objetos.

Apresenta-se adiante os conceitos básicos de modelos de dados e SGBDs orientados a objetos.

Modelos de Dados Orientados a Objetos

Superficialmente, pode-se dizer que orientação a objetos corresponde à organização de sistemas como uma coleção de objetos que integram estruturas de dados e comportamento. Além desta noção básica, a abordagem inclui um certo número de conceitos, princípios e mecanismos que a diferenciam das demais. Seus principais conceitos são apresentados em seguida.

Abstração
É a consideração apenas das propriedades comuns de um conjunto de objetos, omitindo os detalhes, utilizada com freqüência na definição de valores similares e na formação de um tipo a partir de outro, em diferentes níveis de abstração. O uso de abstrações permite a geração de tipos baseada em hierarquias de tipos e de relacionamentos.

Os principais conceitos de abstração utilizados em banco de dados são generalização e agregação. A generalização corresponde à associação “é um” onde, a partir de propriedades comuns de diferentes entidades, é criada uma outra entidade. O processo inverso é a especialização. A agregação corresponde a associação “parte de”.

Objeto
Os objetos são abstrações de dados do mundo real, com uma interface de nomes de operações e um estado local que permanece oculto. As abstrações da representação e das operações são ambas suportadas no modelo de dados orientado a objetos, ou seja, são incorporadas as noções de estruturas de dados e de comportamento. Um objeto tem um estado interno descrito por atributos que podem apenas ser acessados ou modificados através de operações definidas pelo criador do objeto. Um objeto individual é chamado de instância ou ocorrência de objeto. A parte estrutural de um objeto (em banco de dados) é similar à noção de entidade no modelo Entidade-Relacionamento.

Identidade de Objeto
Num modelo com identidade de objetos, estes têm existência independente de seus valores correntes e dos endereços de armazenamento físico. A identidade do objeto é geralmente gerada pelo sistema. A impossibilidade de garantir a identificação de objetos exclusivamente através de suas propriedades estruturais e comportamentais motivou a definição de identificadores únicos de objetos, que persistem no tempo de forma independente ao estado interno do objeto.

A identidade de objetos elimina as anomalias de atualização e de integridade referencial, uma vez que a atualização de um objeto será automaticamente refletida nos objetos que o referenciam e que o identificador de um objeto não tem seu valor alterado.

Objetos Complexos
Os objetos complexos são formados por construtores (conjuntos, listas, tuplas, registros, coleções, arrays) aplicados a objetos simples (inteiros, booleanos, strings). Nos modelos orientados a objetos, os construtores são em geral ortogonais, isto é, qualquer construtor pode ser aplicado a qualquer objeto. No modelo relacional este não é o caso, visto que só é possível aplicar o construtor de conjuntos às tuplas e o construtor de registro a valores atômicos.

A manutenção de objetos complexos, independente de sua composição, requer a definição de operadores apropriados para sua manipulação como um todo, e transitivos para seus componentes. Exemplos destas operações são: a atualização ou remoção de um objeto e cópia profunda ou rasa.

Encapsulamento
O encapsulamento possibilita a distinção entre a especificação e a implementação das operações de um objeto, além de prover a modularidade que permite uma melhor estruturação das aplicações ditas complexas, bem como a segurança dentro do sistema. Em banco de dados se diz que um objeto está encapsulado quando o estado é oculto ao usuário e o objeto pode ser consultado e modificado exclusivamente por meio das operações a ele associadas.

Existe uma certa discussão sobre as consultas em banco de dados quando está incorporada a noção de encapsulamento: Deve-se tornar visível apenas as operações e deixar ocultos os dados e as implementações ? É interessante relaxar o encapsulamento apenas para as consultas ? Como deve ser realizada a otimização de consultas em SGBDOO com encapsulamentos ?

Tipo de Objetos
O tipo de objeto pode ser visto como a descrição ou especificação de objetos. Um tipo possui duas partes, interface (visível para o usuário do tipo) e implementação (visível só para o usuário construtor do tipo).

Existem várias vantagens em se ter um sistema de tipos em um modelo de dados. Além de modularidade e segurança, do ponto de vista da evolução do sistema os tipos são especificações do comportamento que podem ser compostos e modificados incrementalmente, para formar novas especificações.

Classes
Um conjunto de objetos que possui o mesmo tipo (atributos, relacionamentos, operações) pode ser agrupado para formar uma classe. A noção de classe é associada ao tempo de execução, podendo ser vista como uma representação por extensão, enquanto que o tipo é uma representação intencional. Cada classe tem um tipo associado, o qual especifica a estrutura e o comportamento de seus objetos. Assim, a extensão da classe denota o conjunto dos objetos atualmente existentes na classe e o tipo provê a estrutura destes objetos.

Herança
Herança é um mecanismo que permite ao usuário definir tipos de forma incremental, por refinamento de outros já existentes, permitindo composição de tipos em que as propriedades de um ou mais tipos são reutilizadas na definição de um novo tipo. De fato, ela corresponde a transferência de propriedades estruturais e de comportamento de uma classe para suas subclasses.

As principais vantagens de herança são prover uma maior expressividade na modelagem dos dados, facilitar a reusabilidade de objetos e definir classes por refinamento, podendo fatorar especificações e implementações como na adaptação de métodos gerais para casos particulares, redefinindo-os para estes, e simplificando a evolução e a reusabilidade de esquemas de banco de dados.

Tipos de Herança
Os dois tipos de herança, simples e múltipla, são descritos a seguir:

 

  • Herança Simples: Na herança simples um certo tipo pode ter apenas um supertipo, da mesma forma uma subclasse só herda diretamente de uma única classe. Podemos classificar esta herança em quatro subtipos: de substituição, de inclusão, de restrição e de especialização.
  • Herança Múltipla: Nesta herança um tipo pode ter supertipos e os mesmos refinamentos de herança simples. Há basicamente dois tipos de conflitos referentes à herança múltipla: entre o tipo e o supertipo e entre múltiplos supertipos. O primeiro pode ser resolvido dando-se prioridade à definição presente no tipo, e não a no supertipo. Com os conflitos entre múltiplos supertipos, como uma resolução por default pode causar heranças não desejadas, a abordagem mais segura é baseada na requisição explícita da intervenção do usuário.

Métodos e Mensagens

Um método, em relação a um objeto, corresponde ao comportamento dos objetos, implementando uma operação associada a uma ou mais classes, de forma similar aos códigos dos procedimentos usados em linguagens de programação tradicionais, que manipula o objeto ou parte deste. Cada objeto tem um certo número de operações para ele definida. Para cada operação pode-se ter um ou mais métodos de implementação associados.

As mensagens são a forma mais usada para se ativar os métodos. Num SGBDOO os objetos se comunicam e são ativados através de mensagens enviadas entre eles.

Polimorfismo
Em sistemas polimórficos uma mesma operação pode se comportar de diferentes formas em classes distintas. Como exemplo temos o operação print que será implementada de forma diferente se o objeto correspondente for um texto ou uma imagem: dependendo do objeto teremos um tipo de impressão. Tem-se também polimorfismo quando ocorre a passagem de diferentes tios de objetos como parâmetros enviados a outros objetos

Um mesmo nome pode ser usado por mais de uma operação definida sobre diferentes objetos, o que caracteriza uma sobrecarga (overloading). A redefinição do operador para cada um dos tipos de objetos definidos caracteriza uma sobreposição (overriding). As operações são ligadas aos programas em tempo de execução caracterizando o acoplamento tardio ou late binding.

Outros conceitos
Finalmente há duas propriedades fundamentais para a construção de um SGBDOO: extensibilidade e completude computacional. A primeira garante que o conjunto de tipos oferecidos pelo sistema permite a definição de novos tipos e não há distinção entre os tipos pré-definidos e os definidos pelo usuário. A segunda implica que a linguagem de manipulação de um banco de dados orientado a objetos pode exprimir qualquer função computacional.

Fonte: Rational, Inc.

Autor: Marco Aurélio de Lima (maurelio@malima.com.br, http://www.malima.com.br)

Implementando Segurança em Access

Passos para tornar um banco de dados Access seguro:

  1. Abra o Administrador de grupo de trabalho (o programa Wrkgadm.exe que fica na pasta Windows/System)
  2. Clique no botão ‘Criar…’ para gerar um novo arquivo de informação de grupo de trabalho (o arquivo default é o System.mdw e fica na pasta Windows\System). Escreva o seu nome, o nome da empresa e uma string que servirá como código de grupo de trabalho. Não deixe de anotar essas informações, poderão servir futuramente caso você precise recriar o seu grupo de trabalho. Aconselho criar o novo mdw numa pasta diferente da pasta do system.mdw original.
  3. O administrador de grupo de trabalho automaticamente passa a usar o novo mdw criado. Abra um banco de dados qualquer. Você estará logado como o usuário ‘Admin’.
  4. Selecione ‘Ferramentas / Segurança / Contas de usuário e grupo’ para adicionar uma senha para o usuário ‘Admin’. Para tal, deixe o campo senha atual em branco e alimente uma nova senha e confirme. O usuário administrador é a conta default e alterar sua senha faz com que o Access ative a segurança.
  5. Crie um novo usuário com o qual você criará um banco de dados seguro. Adicione-o ao grupo de administradores. Não esqueça de anotar o que você alimentou nos campos nome e identificação para a necessidade de recriar o mdw. O número de identificação não é a senha que será usada para esse novo usuário.
  6. Retire o usuário administrador do grupo administradores.
  7. Feche o banco de dados e abra o banco de dados que você quer tornar seguro alimentando o nome do novo usuário criado. A senha ainda deve ser deixada em branco. Entre em ‘Ferramentas / Segurança / Contas de usuário / Alterar senha do logon’ e altere sua senha.
  8. Entre em ‘Ferramentas / Segurança / Assistente de segurança em nível de usuário’. Selecione os objetos a proteger (sugiro todos). Será criado um novo banco de dados encriptado com todos seus objetos no qual serão removidas as permissões do usuário administrador e do grupo usuários. O banco de dados original não será alterado.
  9. Abra o novo banco de dados. Crie os seus grupos personalizados e dê as permissões necessárias para cada grupo através da opção ‘Ferramentas / Segurança / Permissões para usuário e grupo’. Como todos são sempre membros do grupo usuários, só dê as permissões a esse grupo para aquelas funcionalidades que você queira que todos acessem. Não coloque ninguém no grupo administrador já que membros desse grupo sempre tem poder de administrar os objetos do banco de dados.
  10. Crie seus usuários e coloque-os nos grupos correspondentes. Não dê permissões diretamente aos usuários pois essa tarefa tornar-se-á repetitiva. Use as permissões herdadas dos grupos dos quais eles são membros, é muito mais fácil gerenciar somente as permissões dos grupos. Se um usuário é membro de múltiplos grupos ele
    terá a permissão dos grupos do qual ele faz parte mais as permissões dadas especificamente ao usuário.
  11. Se quiser que o banco seja aberto somente pelos membros que você criou, remova a opção abrir / executar para o grupo usuários.

Seguindo os passos acima você terá implementado a segurança no seu banco de dados. Porém geralmente queremos que essa segurança só valha para um banco de dados específico e não para todos os bancos de dados da sua máquina. Para que isso aconteça faça o seguinte:

  1. Abra o Administrador de grupo de trabalho (o programa Wrkgadm.exe que fica na pasta Windows/System) e clique no botão ‘Associar’. Escolha o System.mdw original da pasta Windows\System. Isso irá restaurar a situação original.
  2. Para chamar a sua aplicação segura crie um atalho. Ele deverá apontar para algo do tipo ‘”C:\Arquivos de Programas\Microsoft Office\Office\MSACCESS.EXE” C:\PastaDaSuaAplicação\NomeDoSeuBanco.mdb /wrkgrp C:\PastaDoMdwCriado\NomeDoMDWCriado.MDW”‘, ou seja, o caminho do Access + caminho do seu mdb + opção ‘/wrkgrp’ + caminho do arquivo mdw que você criou.

A partir disso termos as seguintes possibilidades:

a) Se clicarmos diretamente o no arquivo mdb, o Access o abre sem pedir senha e você será um usuário com as permissões do grupo usuários.

b) Se usuarmos o atalho criado, o Access pede a senha e você terá as permissões do usuário com o qual se logou.

Principais Instruções em SQL

Principais Instruções em SQL

Este documento apresenta as principais instruções em SQL, a linguagem padrão para a manipulação de Bancos de Dados Relacional, mostrando exemplos e aplicações.

Esta apostila foi desenvolvida com o auxílio on-Line do banco MS-ACCESS, O SQL para este banco não é totalmente compatível com o SQL Padrão ANSI, que é o oficial na maioria dos bancos de dados, então algumas cláusulas podem não funcionar em outros bancos.

Instrução SELECT

Instrui o programa principal do banco de dados para retornar a informação como um conjunto de registros.

Sintaxe
SELECT [predicado { * | tabela.* | [tabela.]campo1 [AS alias1] [, [tabela.]campo2 [AS alias2] [, …]]}
FROM expressãotabela [, …] [IN bancodedadosexterno]
[WHERE… ]
[GROUP BY… ]
[HAVING… ]
[ORDER BY… ]
[WITH OWNERACCESS OPTION]

A instrução SELECT tem as partes abaixo:
Parte Descrição
predicado Um dos seguintes predicados: ALL, DISTINCT, DISTINCTROW ou TOP. Você usa o predicado para restringir o número de registros que retornam. Se nenhum for especificado, o padrão será ALL.
* Especifica que todos os campos da tabela ou tabelas especificadas s são selecionados.
tabela O nome da tabela que contém os campos dos quais os registros são
selecionados.
campo1, campo2 Os nomes dos campos dos quais os dados serão recuperados. Se você incluir mais de um campo, eles serão recuperados na ordem listada.
alias1, alias2 Os nomes que serão usados como títulos de colunas em vez dos nomes originais das colunas na tabela.
expressãotabelaO nome da tabela ou tabelas contendo os dados que você quer recuperar.
bancodedadosexterno O Nome do banco de dados que contém as tabelas em expressãotabela se não estiver no banco de dados atual.

Comentários

Para executar esta operação, o programa principal de banco de dados procura a tabela ou tabelas especificadas, extrai as colunas escolhidas, seleciona as linhas que satisfazem o critério e classifica ou agrupa as linhas resultantes na ordem especificada. A instrução SELECT não atualiza os dados no banco de dados.

SELECT é normalmente a primeira palavra em uma instrução SQL. A maior parte das instruções SQL são instruções SELECT.

A sintaxe mínima da instrução SELECT é:
SELECT campos FROM tabela

Você pode usar um asterisco (*) para selecionar todos os campos na tabela. O exemplo abaixo seleciona todos os campos na tabela Funcionários:
SELECT * FROM Funcionários;

Se o nome de um campo estiver incluído em mais de uma tabela na cláusula FROM, preceda-o com o nome da tabela e o operador . (ponto). No exemplo abaixo, o campo Departamento está nas tabelas Funcionários e Supervisores. A instrução SQL seleciona Departamento da tabela Funcionários e NomeSupv da tabela Supervisores:

SELECT Funcionários.Departamento, Supervisores.NomeSupv
FROM Funcionários INNER JOIN Supervisores
WHERE Funcionários.Departamento = Supervisores.Departamento;

Ao criar um objeto Recordset, o programa principal de banco de dados do Jet usa o nome do campo da tabela como o nome do objeto Field no objeto Recordset. Se você quiser um nome de campo diferente ou um nome que não esteja implícito na expressão usada para gerar o campo, use a palavra reservada AS. O exemplo abaixo usa o título Nasc para nomear o objeto Field retornado no objeto Recordset resultante:

SELECT DataNasc AS Nasc FROM Funcionários;

Sempre que você usar funções aggregate ou consultas que retornem nomes de objetos Field ambíguos ou duplicados, você precisará usar a cláusula AS para fornecer um nome alternativo para o objeto Field. O exemplo abaixo usa o título Contagem para nomear o objeto Field retornado no objeto Recordset resultante:

SELECT COUNT(FuncionárioID) AS Contagem FROM Funcionários;

Você pode usar outras cláusulas na instrução SELECT para restringir e organizar posteriormente os seus dados retornados.

Cláusula GROUP BY

GROUP BY é opcional. Valores de resumo são omitidos se não houver qualquer função aggregate SQL na instrução SELECT. Os valores Null nos campos GROUP BY são agrupados e não omitidos. No entanto, os valores Null não são avaliados em qualquer função aggregate SQL. Use a cláusula WHERE para excluir linhas que você não quer agrupadas e use a cláusula HAVING para filtrar os registros após eles terem sido agrupados.

A não ser que contenha dados Memo ou OLE Object, um campo na lista de campos GROUP BY pode fazer referência a qualquer campo em qualquer tabela listada na cláusula FROM. Mesmo que o campo não esteja incluído na instrução SELECT, fornecida a instrução SELECT, inclua pelo menos uma função SQL. O programa principal de banco de dados do Jet não pode agrupar campos Memo ou OLE Objects.

Todos os campos na lista de campos SELECT devem ser incluídos na cláusula GROUP BY ou incluídos como argumentos em uma função aggregate SQL.

Cláusula HAVING

HAVING é opcional. HAVING é semelhante a WHERE, que determina quais registros são selecionados. Depois que os registros são agrupados com GROUP BY, HAVING determina quais registros são exibidos:

SELECT CategoriaID, Sum(UnidadesNoEstoque) FROM Produtos
GROUP BY CategoriaID
HAVING Sum(UnidadesNoEstoque) > 100 AND LIKE “BOS*”;

Uma cláusula HAVING pode conter até 40 expressões vinculadas por operadores lógicos, como And ou Or.

Cláusula ORDER BY

ORDER BY é opcional. Entretanto, se você quiser exibir seus dados na ordem classificada, você deve utilizar ORDER BY. O padrão ordem de classificação é ascendente (A a Z, 0 a 9). Os dois exemplos abaixo classificam os nomes dos funcionários pelo sobrenome.

SELECT Sobrenome, Nome FROM Funcionários ORDER BY Sobrenome;

SELECT Sobrenome, Nome FROM Funcionários ORDER BY Sobrenome ASC;

Para classificar em ordem descendente (Z a A, 9 a 0), adicione a palavra reservada DESC ao final de cada campo que você quiser classificar em ordem descendente. O exemplo abaixo seleciona salários e os classifica em ordem descendente

SELECT Sobrenome, Salário FROM Funcionários ORDER BY Salário DESC, Sobrenome;

Se você especificar um campo que contém dados Memo ou OLE Objects na cláusula ORDER BY, um erro ocorrerá. O programa principal de banco de dados do Jet não classifica campos deste tipo. ORDER BY é normalmente o último item em uma instrução SQL.

Você pode incluir campos adicionais na cláusula ORDER BY. Os registros são classificados primeiro pelo primeiro campo listado depois de ORDER BY. Os registros que tiverem valores iguais naquele campo são classificados pelo valor no segundo campo listado e assim por diante.

Cláusula WITH OWNERACCESS OPTION

A declaração WITH OWNERACCESS OPTION é opcional. O exemplo abaixo habilita o usuário a ver as informações de salário (mesmo que não tenha outra permissão para ver a tabela Folha de Pagamentos) desde que o proprietário da consulta tenha tal permissão:

SELECT Sobrenome, Nome, Salário FROM Funcionários ORDER BY Sobrenome
WITH OWNERACCESS OPTION;

Se, por outro lado, um usuário for impedido de criar ou anexar a uma tabela, você poderá usar WITH OWNERACCESS OPTION para habilitá-lo a executar uma consulta construção de tabela ou consulta anexação. Se você quiser reforçar as configurações de segurança do grupo de trabalho e as permissões dos usuários, não inclua a declaração WITH OWNERACCESS OPTION. Esta opção exige que você tenha acesso ao arquivo System.mda associado ao banco de dados. É realmente útil em implementações de multiusuários seguras.

Exemplo da instrução SELECT, cláusula FROM

Esse exemplo seleciona os campos “Sobrenome” e “Nome” de todos os registros da tabela “Funcionários”.

SELECT Sobrenome, Nome FROM Funcionários

Esse exemplo seleciona todos os campos da tabela “Funcionários”.

SELECT Funcionários.* FROM Funcionários;

Esse exemplo conta o número de registros que têm uma entrada no campo “CódigoPostal” e nomeia o campo retornado como “Tcp”.

SELECT Count(CódigoPostal) AS Tcp FROM Clientes;

Esse exemplo mostra qual seria o salário se cada funcionário recebesse um aumento de 10 porcento. Não altera o valor original dos salários.

SELECT Sobrenome, Salário AS Atual, Salário * 1.1 AS Proposto FROM Funcionários;

Esse exemplo coloca o título Nome no topo da coluna “Sobrenome”. O título Salário é exibido no topo da coluna “Salário”.

SELECT Sobrenome AS Nome, Salário FROM Funcionários;

Esse exemplo mostra o número de funcionários e os salários médio e máximo.

SELECT Count(*) AS [Total de Funcionários], Avg(Salário) AS [Salário Médio], Max(Salário) AS [Salário Máximo] FROM Funcionários;

Para cada registro, mostra Sobrenome e Salário no primeiro e último campos. A seqüência de caracteres “tem um salário de” é retornada como o campo do meio de cada registro.

SELECT Sobrenome, ‘tem um salário de’, Salário FROM Funcionários;

Exemplo de cláusula GROUP BY

Esse exemplo cria uma lista de nomes de departamentos únicos e o número de funcionários em cada um destes departamentos.

SELECT Departamento, Count([Departamento]) AS Tbc FROM Funcionários
GROUP BY Departamento;

Para cada título de função único, calcula o número de funcionários do departamento de Vendas que têm este título.

SELECT Título, Count(Título) AS Tbc FROM Funcionários
WHERE Departamento = ‘Vendas’ GROUP BY Título;

Esse exemplo calcula o número de itens em estoque para cada combinação de número e cor do item.

SELECT Item, Sum(Unidades) AS Tbc FROM ItensEmEstoque
GROUP BY Item, Cor;

Exemplo de cláusula HAVING

Esse exemplo seleciona os títulos de cargos do departamento de Produção atribuídos a mais de 50 funcionários.

SELECT Título, Count(Título) FROM Funcionários WHERE Departamento = ‘Produção’ GROUP BY Título HAVING Count(Título) > 50;

Esse exemplo seleciona os departamentos que tenham mais de 100 funcionários.

SELECT Departamento, Count([Departamento]) FROM Funcionários
GROUP BY Departamento HAVING Count(Departamento) > 100;

Exemplo de cláusula ORDER BY

As instruções SQL mostradas abaixo usam a cláusula ORDER BY para classificar os registros em ordem alfabética e depois por categoria.

Esse exemplo ordena os registros pelo sobrenome, em ordem descendente (Z-A).

SELECT Sobrenome, Nome FROM Funcionários ORDER BY Sobrenome DESC;

Esse exemplo ordena, primeiro, por categoria ID e depois por nome do produto.

SELECT CategoriaID, ProdutoNome, PreçoUnit FROM Produtos
ORDER BY CategoriaID, NomeProduto;

 

Instrução INSERT INTO

Adiciona um ou vários registros a uma tabela. Isto é referido como consulta anexação.

Sintaxe

Consulta anexação de vários registros:

INSERT INTO destino [IN bancodedadosexterno] [(campo1[, campo2[, …]])]
SELECT [origem.]campo1[, campo2[, …]
FROM expressãodetabela

Consulta anexação de um único registro:

INSERT INTO destino [(campo1[, campo2[, …]])]
VALUES (valor1[, valor2[, …] )

A instrução INSERT INTO tem as partes abaixo:

Parte Descrição
destino O nome da tabela ou consulta em que os registros devem ser anexados.
bancodedadosexterno O caminho para um banco de dados externo. Para uma descrição do
caminho, consulte a cláusula IN.
origem O nome da tabela ou consulta de onde os dados devem ser copiados.
campo1, campo2 Os nomes dos campos aos quais os dados devem ser anexados, se
estiverem após um argumento destino ou os nomes dos campos dos quais se deve obter os dados, se estiverem após um argumento origem.
expressãodetabela O nome da tabela ou tabelas das quais registros são inseridos. Este
argumento pode ser um único nome de tabela ou uma combinação
resultante de uma operação INNER JOIN, LEFT JOIN ou RIGHT JOIN ou de uma consulta gravada.
valor1, valor2 Os valores para inserir em campos específicos do novo registro. Cada valor é inserido no campo que corresponde à posição do valor na lista: Valor1 é inserido no campo1 do novo registro, valor2 no campo2 e assim por diante. Você deve separar os valores com uma vírgula e colocar os campos de textos entre aspas (” “).

Comentários

Você pode usar a instrução INSERT INTO para adicionar um único registro a uma tabela usando a sintaxe de consulta anexação de um único registro como mostrado acima. Neste caso, seu código especifica o nome e o valor de cada campo do registro. Você precisa especificar cada um dos campos do registro para os quais um valor deve ser designado e um valor para este campo. Quando você não especifica cada campo, o valor padrão ou Null é inserido nas colunas omitidas. Os registros são adicionados no final da tabela.

Você também pode usar INSERT INTO para anexar um conjunto de registros de outra tabela ou consulta usando a cláusula SELECT … FROM como é mostrado acima na sintaxe consulta anexação de vários registros. Neste caso, a cláusula SELECT especifica os campos para acrescentar à tabela destino especificada.

A tabela de origem ou de destino pode especificar uma tabela ou uma consulta. Se uma consulta for especificada, o programa principal de banco de dados do Microsoft anexa a qualquer e a todas as tabelas especificadas pela consulta.

INSERT INTO é opcional, mas quando incluída, precede a instrução SELECT.

Se sua tabela de destino contém uma chave primária, você deve acrescentar valores únicos, não Null ao campo ou campos da chave primária. Caso contrário, o programa principal de banco de dados do Jet não anexará os registros.

Se você anexar registros a uma tabela com um campo Counter e quiser numerar novamente os registros anexados, não inclua o campo Counter em sua consulta. Inclua o campo Counter na consulta se quiser manter os valores originais do campo.

Use a cláusula IN para anexar registros a uma tabela de outro banco de dados. Para achar quais registros serão anexados, antes de você executar a consulta anexação, primeiro execute e veja os resultados de uma consulta seleção que use o mesmo critério de seleção.

Uma operação de consulta anexação copia os registros de uma ou mais tabelas em outra. As tabelas que contêm os registros que você anexa não são afetadas pela operação de consulta anexação.

Em lugar de acrescentar registros existentes de outra tabela, você pode especificar o valor de cada campo em um único registro novo usando a cláusula VALUES. Se você omitir a lista de campo, a cláusula VALUES deve incluir um valor para cada campo na tabela; caso contrário, um erro ocorrerá em INSERT. Use uma instrução adicional INSERT INTO com uma cláusula VALUES para cada registro adicional que você quiser criar.

Exemplo de instrução INSERT INTO

Esse exemplo seleciona todos os registros de uma tabela hipotética “Novos Clientes” e os adiciona à tabela “Clientes” (quando não são designadas colunas individuais, os nomes das colunas das tabelas SELECT devem corresponder exatamente aos da tabela INSERT INTO).

INSERT INTO Clientes SELECT [Novos Clientes].*
FROM [Novos Clientes];

Esse exemplo cria um novo registro na tabela “Funcionários”

INSERT INTO Funcionários (Nome,Sobrenome, Título)
VALUES (“José”, “Pereira”, “Estagiário”);

Esse exemplo seleciona todos os estagiários de uma tabela hipotética “Estagiários” que foram contratados há mais de 30 dias e adiciona seus registros à tabela “Funcionários”.

INSERT INTO Funcionários SELECT Estagiários.*
FROM Estagiários WHERE DataContrato < Now() – 30;

Instrução UPDATE

Cria uma consulta atualização que altera os valores dos campos em uma tabela especificada com base em critérios específicos.

Sintaxe

UPDATE tabela
SET valornovo
WHERE critério;

A instrução UPDATE tem as partes abaixo:

Parte Descrição
tabela O nome da tabela cujos os dados você quer modificar.
valornovo Uma expressão que determina o valor a ser inserido em um campo específico nos registros atualizados.
critério Uma expressão que determina quais registros devem ser atualizados. Só os registros que satisfazem a expressão são atualizados.

Comentários

UPDATE é especialmente útil quando você quer alterar muitos registros ou quando os registros que você quer alterar estão em várias tabelas. Você pode alterar vários campos ao mesmo tempo. O exemplo abaixo aumenta o Valor do Pedido em 10 por cento e o valor do Frete em 3 por cento para embarques do Reino Unido:

UPDATE Pedidos SET ValorPedido = ValorPedido * 1.1, Frete = Frete * 1.03
WHERE PaísEmbarque = ‘RU’;

UPDATE não gera um conjunto de resultados. Se você quiser saber quais resultados serão alterados, examine primeiro os resultados da consulta seleção que use os mesmos critérios e então execute a consulta atualização.

Exemplo de instrução UPDATE

Esse exemplo muda os valores no campo “RelatórioPara” para 5 para todos os registros de funcionários que atualmente têm valores de RelatórioPara de 2.

UPDATE Funcionários SET RelatórioPara = 5 WHERE RelatórioPara = 2;

Esse exemplo aumenta o “PreçoUnit” de todos os produtos não suspensos do fornecedor 8 em 10 porcento.

UPDATE Produtos SET PreçoUnit = PreçoUnit * 1.1
WHERE FornecedorID = 8 AND Suspenso = No;

Esse exemplo reduz o PreçoUnit de todos os produtos não suspensos fornecidos pela Tokyo Traders em 5 porcento. As tabelas “Produtos” e “Fornecedores” têm uma relação um para vários.

UPDATE Fornecedores INNER JOIN Produtos
ON Fornecedores.FornecedorID = Produtos.FornecedorID SET PreçoUnit = PreçoUnit * .95
WHERE NomeEmpresa = ‘Tokyo Traders’ AND Suspenso = No;

Instrução DELETE

Cria uma consulta exclusão que remove registros de uma ou mais tabelas listadas na cláusula FROM que satisfaz a cláusula WHERE.

Sintaxe

DELETE [tabela.*]
FROM tabela
WHERE critério

A instrução DELETE tem as partes abaixo:

Parte Descrição
tabela.* O nome opcional da tabela da qual os registros são excluídos.
tabela O nome da tabela da qual os registros são excluídos.
critério Uma expressão que determina qual registro deve ser excluído.

Comentários

DELETE é especialmente útil quando você quer excluir muitos registros. Para eliminar uma tabela inteira do banco de dados, você pode usar o método Execute com uma instrução DROP.

Entretanto, se você eliminar a tabela, a estrutura é perdida. Por outro lado, quando você usa DELETE, apenas os dados são excluídos. A estrutura da tabela e todas as propriedades da tabela, como atributos de campo e índices, permanecem intactos.

Você pode usar DELETE para remover registros de tabelas que estão em uma relação um por vários com outras tabelas. Operações de exclusão em cascata fazem com que os registros das tabelas que estão no lado “vários” da relação sejam excluídos quando os registros correspondentes do lado “um” da relação são excluídos na consulta. Por exemplo, nas relações entre as tabelas Clientes e Pedidos, a tabela Clientes está do lado “um” e a tabela Pedidos está no lado “vários” da relação. Excluir um registro em Clientes faz com que os registros correspondentes em Pedidos sejam excluídos se a opção de exclusão em cascata for especificada.

Uma consulta de exclusão exclui registros inteiros e não apenas dados em campos específicos. Se você quiser excluir valores de um campo específico, crie uma consulta atualização que mude os valores para Null.

Importante

Após remover os registros usando uma consulta exclusão, você não poderá desfazer a operação. Se quiser saber quais arquivos foram excluídos, primeiro examine os resultados de uma consulta seleção que use o mesmo critério e então, execute a consulta exclusão. Mantenha os backups de seus dados. Se você excluir os registros errados, poderá recuperá-los a partir dos seus backups.

Exemplo de instrução DELETE

Esse exemplo exclui todos os registros de funcionários cujo título seja Estagiário. Quando a cláusula FROM inclui apenas uma tabela, não é necessário indicar o nome da tabela na instrução DELETE.

DELETE *FROM Funcionários WHERE Título = ‘Estagiário’;

Esse exemplo exclui todos os registros de funcionários cujo título seja Estagiário e que também tenham um registro na tabela “FolhadePagamento”. As tabelas “Funcionários” e “FolhadePagamento” têm uma relação um por um.

DELETE Funcionários.* FROM Funcionários INNER JOIN FolhaDePagamento
ON Funcionários.FuncionárioID = FolhadePagamento.FuncionárioID
WHERE Funcionários.Título = ‘Estagiário’;

Subconsultas SQL

Uma subconsulta é uma instrução SELECT aninhada dentro de uma instrução SELECT, INSERT, DELETE ou UPDATE ou dentro de uma outra subconsulta.

Sintaxe

Você pode usar três formas de sintaxe para criar uma subconsulta:

comparação [ANY | ALL | SOME] (instruçãosql)
expressão [NOT] IN (instruçãosql)
[NOT] EXISTS (instruçãosql)

Uma subconsulta tem as partes abaixo:
Parte Descrição
comparação Uma expressão e um operador de comparação que compara a expressão com o resultado da subconsulta.
expressão Uma expressão para a qual o resultado definido da subconsulta é procurado.
instruçãosqlt Uma instrução SELECT de acordo com as mesmas regras e formato de qualquer outra instrução SELECT. Ela deve estar entre parênteses.

Comentários

Você pode usar uma subconsulta em vez de uma expressão na lista de campo de uma instrução SELECT ou em uma cláusula WHERE ou HAVING. Em uma subconsulta, você usa uma instrução SELECT para fornecer um conjunto de um ou mais valores específicos para avaliar as expressões das cláusulas WHERE ou HAVING.

Use o predicado ANY ou SOME, que são sinônimos, para recuperar registros na consulta principal que satisfaçam a comparação com quaisquer registros recuperados na subconsulta. O exemplo abaixo retorna todos os produtos cujo preço unitário é maior que o preço de qualquer produto vendido com um desconto de 25 por cento ou mais:

SELECT * FROM Produtos WHERE PreçoUnit > ANY
(SELECT PreçoUnit FROM PedidoDetalhes WHERE Desconto >= .25);

Use o predicado ALL para recuperar apenas os registros na consulta principal que satisfaçam a comparação com todos os registros recuperados na subconsulta. Se você mudou ANY para ALL no exemplo acima, a consulta retornaria apenas os produtos cujo preço unitário fosse maior que o de todos os produtos vendidos com um desconto de 25 por cento ou mais. Isto é muito mais restritivo.

Use o predicado IN para recuperar apenas os registros na consulta principal para os quais alguns registros na subconsulta contêm um valor igual. O exemplo abaixo retorna todos os produtos com um desconto de 25 por cento ou mais:

SELECT * FROM Produtos WHERE ProdutoID IN
(SELECT ProdutoID FROM PedidoDetalhes WHERE Desconto >= .25);

De maneira contrária, você pode usar NOT IN para recuperar apenas os registros na consulta principal para os quais não existam registros com valores iguais na subconsulta. Utilize o predicado EXISTS (com a palavra reservada NOT opcionalmente) em comparações true/false para determinar se a subconsulta retorna algum registro.

Você também pode usar aliases de nomes de tabelas em uma subconsulta para fazer referência a tabelas listadas em uma cláusula FROM fora da subconsulta. O exemplo abaixo retorna os nomes dos funcionários cujos salários sejam iguais ou superiores à média de salários de todos os funcionários na mesma função. Para a tabela Funcionários é dada o alias “T1”:

SELECT Sobrenome, Nome, Título, Salário FROM Funcionários AS T1
WHERE Salário >= (SELECT Avg(Salário)
FROM Funcionários WHERE T1. T1.Título = Funcionários.Título) Order by Title;

No exemplo acima, a palavra reservada AS é opcional. Algumas subconsultas são aceitas em consultas de tabela cruzada especialmente como predicados (as da cláusula WHERE). Subconsultas como saída (as da lista SELECT) não são aceitas em tabelas de referência cruzada.

Exemplos de subconsultas SQL

Esse exemplo lista o nome, título e salário de todos os representantes de vendas cujos salários sejam superiores aos de todos os gerentes e diretores.

SELECT Sobrenome, Nome, Título, Salário FROM Funcionários
WHERE Título LIKE “*Repr Vendas*” AND Salário > ALL
(SELECT Salário FROM Funcionários WHERE (Título LIKE “*Gerente*”)
OR (Título LIKE “*Diretor*”));

Esse exemplo lista o nome e preço unitário de todos os produtos cujo preço unitário seja igual ao do Licor de Cacau.

SELECT NomeProduto, PreçoUnit FROM Produtos
WHERE PreçoUnit = (SELECT PreçoUnit FROM [Produtos]
WHERE NomeProduto = “Licor de Cacau”);

Esse exemplo lista a empresa e o contato de cada empresa de todos os clientes que fizeram pedidos no segundo trimestre de 2004.

SELECT NomeContato, NomeEmpresa, ContatoTítulo, Fone FROM Clientes
WHERE ClienteID IN (SELECT ClienteID FROM Pedidos
WHERE DataPedido BETWEEN #1/04/2004# AND #1/07/2004#);

Esse exemplo lista os funcionários cujo salário seja maior que a média dos salários de todos os funcionários.

SELECT Sobrenome, Nome, Título, Salário FROM Funcionários T1
WHERE Salário >= (SELECT AVG(Salário) FROM Funcionários
WHERE Funcionários.Título = T1.Título) ORDER BY Título;

Esse exemplo seleciona o nome de todos os funcionários que tenham registrado pelo menos um pedido. Isto também poderia ser feito com INNER JOIN.

SELECT Nome, Sobrenome FROM Funcionários AS E
WHERE EXISTS (SELECT * FROM Pedidos AS O
WHERE O.FuncionárioID = E.FuncionárioID);

Altera o campo Efetuado do arquivo de serviços para 2 caso o mesmo tenha parecer técnico da entidade encaminhanhamento diferente de nulo.

UPDATE servico SET efetuado = 2
WHERE numero_servico = ANY (SELECT servico.numero_servico
FROM servico INNER JOIN encaminhamento
ON (servico.numero_servico = encaminhamento. numero_servico)
AND (servico. ano_servico = encaminhamento.ano_servico)
WHERE (((servico.efetuado) Is Null) AND ((encaminhamento.parecer_tecnico) Is Not Null))
GROUP BY servico.numero_servico ORDER BY servico.numero_servico);

Autor: Marco Aurélio de Lima (maurelio@malima.com.br, http://www.malima.com.br)