[rotulo] Artigo do tipo Tutorial
Recursos especiais neste artigo:
[rotulo-tag]Conteúdo sobre boas práticas[/rotulo-tag], [rotulo-tag]Artigo no estilo Curso Online[/rotulo-tag] [/rotulo] [lead]Splunk: Monitorando em tempo real os elementos da TI – Parte 2
Neste artigo colocaremos a mão na massa com um tutorial prático onde o leitor poderá explorar todo o potencial do Splunk para monitoramento da TI de uma empresa com base em dados de máquina. Extrair valor de logs e fazer com que a infraestrutura de uma empresa tenha menos problemas com downtime, por exemplo, são alguns dos pontos que fazem do Splunk uma plataforma única no mundo.

Em que situação o tema é útil
Imagine que você precisa de uma ferramenta para consolidar logs de várias máquinas servidoras em uma só e, através de uma interface prática, analisar os problemas que vêm acontecendo relacionados com a compra de um produto em sua plataforma de e-commerce. Ou mesmo, imagine ter vários servidores Linux/Unix/Windows remotos, sendo necessário consolidar todos os logs dos ativos de TI para investigação de erros ou até ameaças de segurança. A possibilidade de investigar problemas e responder a eventos que impactam o funcionamento do seu ambiente fazem do Splunk uma plataforma de Big Data ideal para análise de toda a sua infraestrutura de TI.[/lead]

Não basta somente querer monitorar o ambiente e obter respostas em tempo real, é necessário que o departamento de TI das empresas tenha as pessoas certas e a ferramenta de coleta e análise de informação mais adequada para que o trabalho seja realizado. Muitas são as empresas que têm interesse em entrar para o mundo da análise de dados e ter suas decisões baseadas em números ou fatos, e é isso que o Splunk pode entregar, desde que a equipe de TI dê ao pessoal de negócios o apoio necessário para coletar os dados certos, disponibilizar um software para que analistas de infraestrutura possam analisar dados e extrair de lá, do Big Data, as respostas às perguntas do dia a dia. O mais interessante é que com o Splunk é possível conseguir respostas em segundos ao invés de dias, o que acontece com empresas que ainda tocam grandes Data Warehouses.

Analisar através de gráficos os pacotes que trafegam em redes, roteadores e switches, ou ainda fazer o monitoramento de servidores Windows, Unix e Linux, é parte do que o Splunk lhe dará possibilidade de fazer com poucos cliques. Deste modo, demonstraremos neste artigo algumas das funcionalidades do Splunk na prática.

[subtitulo]Iniciando o Splunk[/subtitulo]

O primeiro passo para iniciarmos com o Splunk é acessar o site do produto e fazer o download da plataforma. Quando estiver na tela de download, perceba que você poderá selecionar o arquivo a ser baixado de acordo com a arquitetura

...

[rotulo] Artigo do tipo Teórico
Recursos especiais neste artigo:
Contém nota Quickupdate, Artigo no estilo Curso Online. [/rotulo] [lead]Do que se trata o artigo
Este artigo apresentará, de maneira geral, a ferramenta de coleta, indexação e análise de informação vista como uma plataforma universal de dados de máquina, ou seja, todo e qualquer tipo de informação que seja possível ler a olhos nus, independentemente de onde estiver e que se encontre de maneira estruturada – caso contrário não poderá ser coletada e disponibilizada para o usuário final. O grande diferencial do Splunk em relação a outras ferramentas do gênero é que ele possibilita, de forma fácil e rápida, a indexação de informações de quaisquer fontes de dados, e as disponibiliza para análise e desenvolvimento de dashboards por meio de poucos cliques. Assim, possibilita a correlação de tais dados com as necessidades dos negócios.

Em que situação o tema é útil
Muitos dos cases de sucesso do mercado nacional e/ou internacional ainda têm uma postura reativa em relação à TI para suporte aos negócios (produtos e serviços) que tais empresas entregam. O Splunk é um software que permite que a organização passe a ter uma visão mais proativa com base nas informações que elas nem sabem que possuem (Big Data) e, na maioria das vezes, informações que podem trazer, além de melhor suporte à decisão, mais inteligência competitiva para manter os negócios de maneira mais confiável por parte da TI. Assim, tem-se maior visibilidade operacional em relação à capacidade instalada, além da informação necessária para manter as estratégias de crescimento da empresa em tempo real.

Splunk: Monitorando o ambiente de TI – Parte 1
O Splunk é uma ferramenta que permite coletar, indexar e analisar a informação gerada pelo negócio, também conhecida pelo nome de dados de máquina. A partir da coleta e da indexação de toda a informação de syslog de uma máquina, por exemplo, é possível determinar vários problemas que a TI não fazia nem ideia de que ocorriam com o ambiente. Com isso, várias análises poderão ser realizadas, desde a implementação de um sistema de alertas com base em uma quantidade x de erros ou ocorrência de determinado evento, até a apresentação de gráficos que refletem indicadores de performance do negócio

...

Entendendo os tipos de tablespace no Oracle 11g

Por Wagner Bianchi

Definir critérios para a divisão de um banco de dados Oracle em tablespaces é sempre uma questão importante para os DBAs na organização do armazenamento. Um pré-requisito para configurar de maneira competente os tablespaces em seu banco de dados é entender os diferentes tipos existentes e como eles podem ser utilizados no servidor de bancos de dados Oracle para melhor atender à demanda do nível externo e otimizar quanto ao espaço que é requisitado, tabelas mais acessadas e qual é a melhor maneira de gerenciar como um dos tipos existentes.

Os tablespaces se apresentam nas seguintes categorias:

• Tablespace SYSTEM:

 

O tablespace SYSTEM é considerado um tablespace permanente, além disso, todos os segmentos que precisam ser mantidos por um usuário ou uma aplicação além dos limites de uma sessão ou transação devem ser armazenados em um tablespace permanente.

 

Os segmentos de um usuário nunca devem residir neste tablespace. A partir do Oracle 10g, é possível especificar um tablespace permanente padrão além do recurso de especificar um temporário padrão no Oracle 9i. Também a partir do Oracle 10g, o este tablespace é gerenciado localmente por padrão, ou seja, toda a utilização de espaço é gerenciada por um *segmento de bitmap na primeira parte do primeiro arquivo de dados do tablespace. Usar tablespace gerenciados localmente remove parte da disputa ou concorrência que pode ser gerada neste tablespace porque operações de alocação e desalocação de espaço não precisam usar tabelas de dicionário de dados.

 

Para verificar se o tablespace SYSTEM é gerenciado localmente ou não, entre com a seguinte consulta e verifique a coluna EXTENT_MANAGEMENT:

 

O tablespace SYSTEM é responsável por armazenar o dicionário de dados e seus respectivos objetos (metadados). Quantos mais objetos forem criados nos bancos de dados de uma instância Oracle, maior será este tablespace.

 

• Tablespace SYSAUX:

 

Como o tablespace anterior, o SYSTEM, este não deve ter segmentos de usuários. O conteúdo deste tablespace são membros de processos realmente auxiliares, por isso, caso haja algum processo que esteja ocupando muito espaço neste tablespace, interessante pensar em trocá-lo de lugar. O monitoramento poderá ser realizado através do EM Database Control.

 

Este tablespace auxiliar não existe nas versões anteriores ao Oracle 10g e foi criado especialmente para aliviar o tablespace SYSTEM de segmentos associados a algumas aplicações do próprio banco de dados como o Oracle ultra search, Oracle Text e até mesmo segmentos relacionados ao funcionamento do Oracle Enterprise Manager entre outros.

 

Como resultado da criação do tablespace SYSAUX, alguns dos gargalos de I/O freqüentemente associados ao tablespace SYSTEM foram reduzidos ou eliminados. Vale salientar, que o este tablespace não pode se colocado em modo offline e é parte integrante obrigatória em todos os bancos de dados a partir do Oracle 10g. Existe uma visão no dicionário de dados que exibe os dados relacionados com os ocupantes atuais neste tablespace:

										...

Entenda o Storage Engine Blackhole

Por Wagner Bianchi

Desde alguns anos atrás, o servidor de bancos de dados MySQL está baseado em um padrão em que, ao se definir um projeto, primeiro se busca as características do sistema ou subsistema que será desenvolvido, levantando informações em relação ao seu back-end e depois que tais pontos são definidos, o administrador de bancos de dados pode definir qual Storage Engine utilizar.

Os Storage Engines não passam de módulos que podem ser plugados ao MySQL para que certas características como possuir transação ou não,  integridade referencial ou não, MVCC, ACID, leitura e escrita sequêncial e outras mais que sabemos que motores de armazenamentos nativos como MyISAM, Archive, InnoDB, Federated, Memory e CSV possuem em uma instalação padrão do servidor de bancos de dados de código fonte aberto mais utilizado do mundo.

O poder que o MySQL deu aos seus usuários, os administradores de bancos de dados, de escolherem quais motores de armazenamento ou Storage Engines utilizar, atribuiu a ele o título de Plugable Database, ou seja, você poderá escolher o motor que deseja utilizar em seu projeto, considerando as suas principais características, para que, de forma transparente, este gerencie as tabelas de seu banco de dados.

Além dos vários Storage Engines que estão disponíveis em uma instalação do MySQL, que são os motores chamados de nativos, ainda podemos observar várias outras empresas que escrevem seus próprios motores e plugam estes no servidor de bancos de dados MySQL, oferecendo funcionalidades bem diferentes daquelas existentes em motores nativos. Destes podemos citar Infobrigth, PBXT, XTradb, Drizzle, Amazon AW3, Google e vários outros.

Este artigo surgiu da vontade de trazer à público uma dúvida levantada por vários profissionais que me enviam por e-mail a mesma pergunta ao enviar o comando SHOW ENGINES, através do mysql client ou mesmo através de qualquer GUI: "O QUE É ESSE TAL DE BLACKHOLE?". A resposta a essa pergunta se inicia agora.



Perceba que na saída do comando SHOW ENGINES, temos a coluna comment que nos descreve as características, bem a "grosso modo" em relação a cada motor nativo do MySQL. Quando chegamos na descrição ou comentário na linha do BLACKHOLE, percebemos que, tudo que escrevermos para uma tabela controlada por este motor de armazenamento vai desaparecer. UAU?!?!? Mas, para que serve isso? Muito bem!

mysql> CREATE TABLE tab_blackhole (
    ->   id int not null auto_increment primary key,
    ->   nome char(40)
    -> ) ENGINE=BLACKHOLE;
Query OK, 0 rows affected (0.00 sec)

mysql> insert into tab_blackhole set nome ='IMASTERS';
Query OK, 1 row affected (0.01 sec)

...

MYSQL – Trabalhando com Views – Parte 01

Neste artigo serão apresentados os principais conceitos de armazenamento de procedimentos no servidor de bancos de dados MySQL, além de mostrar como trabalhar essencialmente com objetos chamados Views. Além dos conceitos que serão vistos, aprenderemos também, como montar nossas próprias visões dos dados de tabelas em um banco de dados.

Para os exemplos que criaremos durante o artigo, utilizaremos o banco de dados World, disponível em mysql.com.

 

 

World Database disponível em mysql.com .

 

Introdução

Para quem trabalha com desenvolvimento de sistemas e administração de dados diretos em bases de dados concentradas em um SGBD como o MySQL, Oracle ou SQL Server, sabe o quanto é chateante ter que escrever e reescrever determinadas consultas todos os dias ou mesmo mais de uma vez no mesmo dia. Muitas destas consultas são derivadas de várias tabelas o que nos dá um re-trabalho ao montar todas aquelas JOIN's, utilizar esse ou aquele índice setado para esta ou aquela tabela para que também a performance de tal consulta tenha um tempo razoavelmente atraente.

Sabemos também que a cada momento em que reescrevemos uma mesma consulta, conseguir os mesmos resultados de antes é uma tarefa séria, já que existem várias formas para se escrever uma mesma consulta, levando em conta a ordem em que as tabelas aparecem, a ordem dos campos e tudo mais. Tudo isso implica em ganho ou perda de performance. Estamos falando tanto em performance que parece que nosso artigo tomou outros rumos, mas não. De fato, quando temos um grande trabalho de ajuste de performance em uma consulta, podemos rapidamente transformar esta em uma View, que a partir disso, permanecerá armazenada no servidor de bancos de dados em forma de tabela, para que possamos consultá-la todas as vezes que precisarmos, sem ter que reescrever a mesma, aproveitando todo o trabalho de refino de performance supracitado.

 

Mas, o que é uma View?

Uma View é um objeto que pertence a um banco de dados, definida baseada em declarações SELECT’s, retornando uma determinada visualização de dados de uma ou mais tabelas. Esses objetos são chamados por vezes de “virtual tables”, formada a partir de outras tabelas que por sua vez são chamadas de “based tables” ou ainda outras Views. E alguns casos, as Views são atualizáveis e podem ser alvos de declaração INSERT, UPDATE e DELETE, que na verdade modificam sua “based tables”.

Os benefícios da utilização de Views, além dos já salientados, são:

 

·                                             Uma View pode ser utilizada, por exemplo, para retornar um valor baseado em um identificador de registro;

·                                             Pode ser utilizada para promover restrições em dados para aumentar a segurança dos mesmos e definir políticas de acesso em nível de tabela e coluna. Podem ser configurados para mostrar colunas diferentes para diferentes usuários do banco de dados;

·                                             Pode ser utilizada com um conjunto de tabelas que podem ser unidas a outros conjuntos de tabelas com a utilização de JOIN’s ou UNION.

 

Criando Views

Para definir Views em um banco de dados, utilize a declaração CREATE VIEW, a qual tem a seguinte sintaxe:

 

CREATE [OR REPLACE] [ALGORITHM = algorithm_type] VIEW

         VIEW

...

MySQL – TRIGGERS

 

Neste artigo, serão apresentados os principais conceitos sobre os TRIGGERS e sua aplicabilidade. Após a conceituação, trabalharemos um estudo de caso de um estoque de produtos, com baixa nas quantidades através destes procedimentos armazenados.

 

Após ler este artigo, você estará apto à:

   - Definir o que é um TRIGGER;
   - Definir dados de antes (OLD) e depois (NEW);
   - Criar um TRIGGER;
   - Excluir um TRIGGER;
   - Restrições em relação à TRIGGERS.

 

O que é um TRIGGER?

 

Um TRIGGER ou gatilho é um objeto de banco de dados, associado a uma tabela, definido para ser disparado, respondendo a um evento em particular. Tais eventos são os comandos da DML (Data Manipulation Language): INSERT, REPLACE, DELETE ou UPDATE. Podemos definir inúmeros TRIGGERS em uma base de dados baseados diretamente em qual dos comandos acima irá dispará-lo, sendo que, para cada um, podemos definir apenas um TRIGGER. Os TRIGGERS poderão ser disparados para trabalharem antes ou depois do evento. Veremos como definir o momento de atuação do TRIGGER mais à frente.

 

Utilizaremos a seguinte tabela da Figura 01 para nossos testes:

 

 

Figura 01. Criando a tabela de testes – tbl_cliente.

        

Baseado na tabela tbl_cliente, podemos definir os TRIGGERS para serem disparados, por exemplo, antes (BEFORE) ou depois (AFTER) de um INSERT. Agora sabemos então que para cada momento BEFORE ou AFTER, podemos ter um TRIGGER a ser disparado para defender alguma lógica.

 

A sintaxe geral de definição de um TRIGGER é a seguinte:

   - DEFINER: Quando o TRIGGER for disparado, esta opção será checada para checar com quais privilégios este será disparado. Utilizará os privilégios do usuário informado em user (‘wagner’@’localhost’) ou os privilégios do usuário atual (CURRENT_USER). Caso essa sentença seja omitida da criação do TRIGGER, o valor padrão desta opção é CURRENT_USER();

   - trigger_name: define o nome do procedimento, por exemplo, trg_test;
   - trigger_time: define se o TRIGGER será ativado antes (BEFORE) ou depois (AFTER) do comando que o disparou;
   - trigger_event: aqui se define qual será o evento, INSERT, REPLACE, DELETE ou UPDATE;
   - tbl_name: nome da tabela onde o TRIGGER ficará “pendurado” aguardando o trigger_event;
   - trigger_stmt: as definições do que o o TRIGGER deverá fazer quando for disparado.

 

Definir dados de antes (OLD) e depois (NEW)

 

Em meio aos TRIGGERS temos dois operadores importantíssimos que nos possibilitam acessar as colunas da tabela alvo do comando DML, ou seja, podemos acessar os valores que serão enviados para a tabela tbl_cliente antes (BEFORE) ou depois (AFTER) de um UPDATE, por exemplo. Tais operadores nos permitirão então, ter dois momentos, o antes e o depois e também examinar os valores para que sejam ou não inseridos, atualizados ou excluídos da tabela.

 

Antes mesmo de analisarmos os operadores, temos que analisar vejamos as seguintes diretrizes:

   - INSERT: o operador NEW.nome_coluna, nos permite verificar o valor enviado para ser inserido em uma coluna de uma tabela. OLD.nome_coluna não está disponível.
   - DELETE: o operador

...

Iniciando com MySQL – Parte 2

 

Neste artigo, daremos continuidade à série de artigos que tratam do início com o MySQL Server, e nesta parte recordaremos os tipos de conexão com o servidor já vistos no artigos anterior e novos parâmetros para seleção do tipo de protocolo, quais protocolos estão disponíveis para conexão com o servidor, geração de XML e HTML através de consultas, executando o mysql client em Batch e como executar scripts em arquivos do sistema operacional para criar objetos e dar carga em tabelas de um banco de dados do MySQL.

 

         Após ler este artigo você será capaz de:

 

·                                                                    Definir qual protocolo de comunicação o mysql client utiliza para se conectar ao servidor;

·                                                                    Retornar consultas no formato XML;

·                                                                    Retornar consultas no formato HTML;

·                                                                    Iniciar o mysql client no formato Batch;

·                                                                    Executar scripts em arquivo do sistema operacional;

 

         Recordar é viver...

 

No artigo anterior, mostramos situações em que são utilizadas várias opções para conexão com o mysqld, através do mysql client, que é o utilitário de linha de comando para interação direta com a parte servidor do MySQL Server. As opções abordadas  no artigos anterior foram:

 

-u : parâmetro que antecede o nome do usuário utilizado a conexão;

-p : parâmetro que antecede a senha, lembrando que, se digitarmos uma senha, esta deve ser digitada imediatamente após a parâmetro, sem espaços;

-h : parâmetro que antecede um hostname ou endereço IP;

-P : parâmetro que antecede o número da porta de conexão com o mysqld;

 

Além dos parâmetros acima, vistos com exemplos práticos no artigo 1, neste artigo veremos primeiramente os protocolos de conexão do mysql  client com o servidor MySQL que é o mysqld.

 

A opção que pode ser utilizada para escolha do protocolo a ser utilizando para uma conexão com o servidor MySQL é --protocol. Antes de iniciarmos uma conexão, selecionando explicitamente qual protocolo usaremos, primeiramente, precisamos conhecer quais protocolos estão disponíveis.

 

A Figura 01 mostra os protocolos que são utilizados em Windows e Linux.

 

 

 

Figura 01. Protocolos utilizados para comunicação entre Cliente e Servidor MySQL.

 

Como podemos verificar na Figura 01, o protocolo TCP/IP é utilizado nas duas plataformas de sistemas operacinais, Windows e Linux/Unix. O socket, está disponível somente em sistema Linux/Unix. Named Pipes e Shared Memory são utilizados em ambiente Microsoft, disponível em Windows XP/2000/NT e em servidores mysqld com terminação nt, como o mysqld-nt ou mysql-max-nt, ambos descritos em suas características no artigo anterior desta série.

 

Casos particulares são somente as conexões via socket, named pipes e shared memory. O socket é criado no momento em que o MySQL Server é iniciado para uma conexão local no Linux/Unix, no diretório /var/run/mysqld/mysqld.sock. Caso sua conexão com o MySQL Server, mesmo que local, utilize o protocolo TCP/IP, o arquivo de socket não será utilizado.

 

Conexões em ambiente Windows também podem utilizar TCP/IP, mas estão disponíveis, embora desabilitados por padrão, conexões locais via Named Pipes que são conexões via Pipe Nomeado, habilitando iniciando o mysqld-nt ou mysqld-max-nt com a opção --enable-named-pipe. Shared Memory também só está disponível também para conexões locais no Windows e pode ser habilitada iniciando os servidores com terminação nt com a opção --shared-memory.  Vale salientar que o Pipe padrão é MySQL.

 

 

 

Caso não mencionemos em uma conexão com o MySQL Server sem mencionar a opção

--protocol, o protocolo de conexão é determinado implicitamente, baseado no sistema operacional do client, que solicita a conexão e do servidor, que recebe a conexão.

&

...

 

Backup no MySQL com MySQLDUMP – PARTE 1

 

 

Motivado pela importância dada à assuntos relacionados à backup, resolvi escrever esse artigo para referenciar um utilitário de grande valor dentre os muitos utilitários que são disponibilizados pelo MySQL durante a sua instalação. Basicamente, este artigo se concentrará em exibir como utilizar o MySQLDUMP em linha de comando, assim como algumas de suas variações para termos melhor proveito em determinadas situações, como fazer backup de todos os bancos do servidor, de um banco de dados específico ou de tabelas de uma banco de dados específico. Ao final, faremos uma restauração ou restore de um dos backups.

Introdução

É bem verdade que em muitos cursos e estudos que são encontrados pela internet, muito se falam sobre políticas e estratégia de backup, mas na realidade, são poucos os profissionais que se preocupam com o fato de que problemas podem acontecer e em momentos muito complicados. Quando você menos espera, o banco de dados pede sua atenção para uma recuperação de dados, dados são excluídos erroneamente ou mesmo corrompidos. O MySQLDUMP é um utilitário, uma ferramenta padrão do MySQL para efetuar backup’s lógicos disponibilizado na sua instalação.

O Utilitário

Assim como o ORACLE apresenta o seu dinâmico RMAN, o MySQL traz consigo o MySQLDUMP, que nada mais é que uma ferramenta que nos dá possibilidade de copiar os bancos de dados que estão dentro do SGBD MySQL. O Funcionamento deste é algo bem simples, é um programa cliente que coloca o conteúdo de tabelas em arquivos texto, chamados de DUMP. É útil para fazer cópias de segurança de bancos de dados ou transferir conteúdos de bancos de dados para outro servidor.

O MySQLDUMP pode produzir arquivos no formato SQL que contenham declarações CREATE TABLE e INSERT para recriar os arquivos ou para produzir arquivos de dados delimitados por tabulações.

Funcionamento

Com este utilitário, você pode copiar, uma ou mais tabelas, um banco de dados inteiro ou todos os bancos de dados do servidor. Lembrando que este funciona em linha de comando e é o que utilizaremos nos exemplos.

Um detalhe interessante para casos que ocorram acidentes com o hardware ou qualquer outro problema e também para minimizar a perda de informações, é interessante que o comando FLUSH LOGS seja emitido ao efetuarmos o backup. Isso garante que um novo log seja criado e no caso de um backup on-line, as informações concorrentes ao backup sejam colocadas em logs separados, ou seja, além do backup você ainda terá os logs e poderá sincronizá-los no momento do restore. A leitura de logs para sincronia será apresentada em um outro artigo, onde falaremos do utilitário MySQLBINLOG.

mysql> flush logs;

Abra o prompt ou terminal (Linux/Unix) e digite o seguinte comando:

 

shell> mysqldump -u <usuario> -p<senha> mysql > mysql.sql

O comando acima, copia o banco de dados mysql para o diretório raiz do usuário atual do sistema operacional. Para verificarmos a existência do arquivo e o seu conteúdo, no Windows, digite "dir" para listar os arquivos e em seguida "edit mysql.sql" , no Linux, “ls mysql.sql”

...

Advanced Series – Stored Procedures Parte 2 (Transações)

 

Neste artigo, daremos continuidade aos procedimentos armazenados, ampliando os recursos que foram abordados na Parte 1 desta série de artigos. Vamos enriquecer os conceitos a cada passo, passando pelo conceito de transação e os atributos em conformidade com as propriedades ACID, como o MySQL garante essa conformidade, o modo AUTOCOMMIT e exemplos que exibem a sintaxe utilizada para produzir os recursos abordados. Serão apresentadas as principais estruturas para iniciar e finalizar transações e como utilizarmos de SAVEPOINT.

Após este artigo, você será capaz de:

 

·         Definir o que é uma transação e quais as suas vantagens;

·         Definir o que é COMMIT e ROLLBACK e quais são as suas funções;

·         Definir o que é o modelo ACID;

·         Explicar como o MySQL dá suporte ao modelo ACID;

·         Definir e utilizar AUTOCOMMIT;

·         Iniciar e finalizar uma transação no MySQL;

·         Definir e utilizar SAVEPOINT;

 

Introdução – Transação

Sabemos que grande parte dos vários processos existentes no mundo real, como transferências de valores em instituições bancárias, DOC’s, compras em comércio eletrônico e outros serviços utilizam transações que são um atributo ou artifício comum em bancos de dados comerciais. Muitos conceitos surgiram desde que Edgard Frank Codd, ou simplesmente Ted, divulgou as Leis do Modelo Relacional e criou este modelo. Tais leis eram para serem seguidas à risca para que um SGBD realmente contemplasse tal modelo, mas, alguns destes relaxam nas implementações para garantir mais performance. Alguns autores como C. J. Date que é a principal referência após a morte de Codd, deram continuidade ao trabalho e defende o conceito de transação da seguinte forma:

 

“Transação é uma unidade lógica de trabalho, envolvendo diversas operações de bancos dados.”

                                                       (C. J. Date – Introdução a Sistemas de Bancos de Dados – página 63)

Há ainda quem diga que uma transação é “todo e qualquer comando que altera o estado do banco de dados”, mas de acordo com o que defende Codd e C. J. Date, este conceito não está completo e veremos mais à frente o por quê. Ainda, o usuário deve ser capaz de informar ao sistema quando operações distintas fazem parte de uma transação. Basicamente, esta começa quando uma operação BEGIN é executada, e termina quando uma operação COMMIT ou ROLLBACK correspondente é executada. Desta forma, podemos perceber que uma transação logo é formada caracteristicamente por estes comandos.

Podemos consistir o conceito de transação com um exemplo clássico que é utilizado quando precisamos iniciar este assunto em sala de aula, que é uma explicação análoga a uma transferência bancária. Em meio a um processo de transferência de valor entre contas, temos alguns comandos SQL que são executados todos de uma vez, formando a tal unidade lógica, que por sua vez, envolve diversas operações de bancos de dados, tais como INSERT e UPDATE. Transações também podem conter DELETE e SELECT, mas no caso da transferência, utilizaremos somente o UPDATE.

Digamos que nossa agência tenha dois correntistas, A e B e num belo dia, A resolve fazer uma transferência de R$ 50,00 para B. Esta transação será feita pela internet, através de um sistema de internet banking, então, A acessará a sua conta e completará a operação. Do lado servidor, o banco de dados recebe o valor e a conta de destino, tal valor é subtraído da conta de origem e adicionado na conta de destino. Nesse momento há uma conferência por parte do SGBD – “tudo correu bem” ­– então a transação é finalizada com sucesso. Vamos esboçar o procedimento.

 

 

          Figura 01. Transferência de valor entre contas.

         

            Como o procedimento da Figura 01?

Na linha 1, trocamos o delimitador para utilizarmos o “;” em meio ao procedimento, na linha 2, começamos a definição do procedimento com o comando CREATE PROCEDURE, seguido pelo seu nome e os parâmetros, que são respectivamente a origem do valor, o destino do valor e o valor monetário. Na linha 3, utilizamos o comando BEGIN para delimitar os comandos de nosso procedimento. Nas linhas 4 e 5, temos os comandos UPDATE que subtrai o valor monetário da conta de origem e o soma a conta de destino.

COMMIT e ROLLBACK

Neste básico exemplo, não utilizamos COMMIT e ROLLBACK mas já dá para entendermos o que é uma transação. Em um exemplo mais à frente, veremos que o COMMIT é uma operação de confirmação de que correu tudo bem e que todos os comandos que fazem parte da unidade lógica, ou do procediemtno armazenado, forma executados com sucesso e o banco de dados encontra-se em um estado consistente. O ROLLBACK retornará todos os comandos anteriores àquele onde houve um erro, ou seja, tudo será desfeito se houve um problema com algum comando dentro de uma transação.

Para melhor entendermos tal situação de ROLLBACK que é também chamada por Date de “recuperação do estado consistente”, usemos novamente nosso exemplo e imagine se caso o primeiro comando seja executado, mas na hora de creditar o valor na conta B houvesse um erro, para onde iria o dinheiro? Perdeu? Como é? Isso não poderia acontecer de maneira nenhuma. Nesse caso, o SGBD se encarregaria de fazer o ROLLBACK dos comandos anteriores ao erro retornando o banco de dados para o momento de antes, devolveria na verdade o valor para A, mantendo intacta sua quantia de saldo imediatamente anterior ao início da transação. Sendo assim, vamos aos conceitos:

...

Iniciando com o MySQL – Parte 1

Neste artigo vamos trabalhar com comandos básicos do MySQL, abordando conceitos práticos e teóricos. Para que se tenha melhor proveito do conteúdo que será abordado, você precisará ter no mínimo alguma habilidade com sistemas operacionais. Utilizaremos o prompt de comando do Windows e o terminal do Linux para acessar o mysql client, que é um utilitário instalado junto com o MySQL.

O Windows que utilizaremos será o XP Professional e o Linux será o Ubuntu LTS 6.06, em ambos o MySQL será acessado com o usuário root sem senha (é recomendável que você configure uma senha com nível de segurança considerável para o usuário root e somente use este para tarefas que realmente não seria possível efetuar com outros usuários com os mesmo privilégios - falaremos mais em breve sobre segurança).

 

Principais Comandos - Iniciando com o MySQL

A principal questão para iniciarmos será como interromper o servidor MySQL e em seguida iniciá-lo. Algumas configurações do servidor MySQL exigem a sua iniciação. Um exemplo é quando editamos algum parâmetro em seu arquivo de configurações. Exibiremos com parar e iniciar o servidor MySQL no Windows e Linux respectivamente:

 

 

 

Com tais comandos, colocamos em execução o servidor MySQL que é o mysqld, com algumas variações de versões do servidor, tais como:

• mysqld: trata-se de um arquivo compilado com todas as funcionalidades do servidor, incluindo o
gerenciamento da alocação dinâmica de memória e suporte à tabelas do tipo InnoDB;

• mysqld-debug: idêntico ao mysqld, porém inclui checagem e depuração da alocação dinâmica de
memória;

• mysqld-nt: trata-se de um arquivo compilado (binário) com os mesmos recursos do mysqld. Está otimizado para ser executado nos sistemas operacionais Windows NT/2000/XP.

• mysqld-max: trata-se do mysql estendido, isto é, possui todas as funcionalidades do mysqld,
com suporte aos tipos de tabelas InnoDB e BDB (Berkeley Database).

• mysqld-max-nt: igual ao mysqld-max, porém otimizado para ser executado nos sistemas
operacionais Windows NT/2000/XP.

Em sistemas operacionais Windows, podemos instalar o MySQL Server como serviço ou iniciá-lo manualmente. Quando o MySQL Server é instalado como serviço, ele será iniciado e interrompido automaticamente de acordo com a inicialização e interrupção do sistema operacional, a não ser que se os parâmetros de inicialização sejam modificados. Iniciando o servidor manualmente, entramos com um comando através da linha de comando. Tanto uma opção como a outra, podemos indicar qual dos servidores queremos iniciar.

Digamos que queremos então iniciar uma instancia do MySQL Server manualmente no Windows, escolhendo o mysqld-nt. Confira na pasta bin dentro da pasta MySQL, geralmente em C:\MySQL\MySQL Server 5.0\bin\, se existe este executável. Caso exista, entre com o seguinte comando no prompt:

 

 

Tal comando iniciará o MySQL Server e nos permitirá interagir com o mesmo através do terminal ou prompt, acessando o mysql client. Em sistemas operacionais Unix-like, o MySQL é iniciado como um *processo, podendo ser interrompido ou reiniciado, ou mesmo "restartado" através de um script shell que se encontra em /etc/init.d/mysql. Esse script em shell recebe um

...

Advanced Series - MySQL Stored Procedures Part 1

Olá pessoal,


Depois de algum tempo sem postar artigos aqui no portal SQL Magazine. Agradeço a todos os amigos que tem enviado e-mails com ótimas palavras e solicitando temas para abordarmos aqui na forma de artigo. Lembro a você que, para aqueles que buscam aprender MySQL com vídeos que trazem uma abordagem 92% prática, acesse a área de vídeos do Portal SQL Magazine onde tenho trabalhado junto com a equipe para trazer tudo o que você precisa aprender para manipular bem o SGBD MySQL.

Neste artigo (usarei um servidor SUPERION da SunSix, rodando Ubuntu 6.06 LTS com MySQL 5.0.37 Community Version), iniciaremos uma viagem interessante sobre todo o mundo dos procedimentos armazenados ou stored routines, cujo conceito principal é que são “programas armazenados no servidor, pré-compilados, chamados de forma explícita para executar alguma lógica de manipulação de dados, podendo retornar ou não algum valor”.

Mal começamos e já temos o conceito de stored procedure ou stored routines. No caso do MySQL, os procedimentos armazenados estão disponíveis exatamente desde a versão 5.0, que foi um marco na evolução do SGBD OpenSource mais utilizado no mundo.

Necessariamente, você precisará ter instalado na sua máquina, o MySQL 5++ e o MySQL Client (este é disponibilizado no momento da instalação do server) e um editor de textos como vi, emacs ou notepad. Poderemos utilizar também o MySQL Query Browser para tornar nossa experiência mais interessante com o MySQL e sair um pouco da linha de comando.

Antes de entrarmos na sintaxe, ainda temos que registrar aqui que, os procedimentos armazenados, quando criados e compilados, são inseridos em uma tabela chamada ROUTINES no banco de dados INFORMATION_SCHEMA, que é o dicionário de dados do MySQL. Para listarmos todos os stored routines (Stored Procedure e Functions), basta emitirmos o seguinte comando no mysql client:

mysql> SELECT * FROM INFORMATION_SCHEMA.ROUTINES;

Perceba que listamos todos os procedimentos armazenados (Stored Procedure e Functions), de todos os bancos de dados. Saliento que estamos listando somente Stored Procedure e Functions, pois, somente estas rotinas são gravadas na tabela ROUTINES do bancos de dados INFORMATION_SCHEMA. Triggers também são um tipo de procedimento armazenado, mas estão separadas em outra tabela do dicionário, chamada TRIGGERS.

 

mysql> SELECT * FROM INFORMATION_SCHEMA.TRIGGERS;

A sintaxe geral para criação de Stored Procedure é a seguinte:

CREATE PROCEDURE (tipo_param param_1 data_type, ...)

[BEGIN]

      corpo_da_rotina;

[END]

Explicando...

nome_procedure: seu procedimento armazenado deve ter um nome, para quando for chamado, podermos então usá-lo;

tipo_param: existem 3 tipos de parâmetros em uma Stored Procedure no MySQL:

• IN => este é um parâmetro de entrada, ou seja, um parâmetro cujo seu valor será utilizado no interior do procedimento para produzir algum resultado;
• OUT => esté parâmetro retorna algo de dentro do procedimento para o lado externo, colocando os valores manipulados disponíveis na memória ou no conjunto de resultados;
• INOUT => faz os dois trabalhos ao mesmo tempo!

param_1: esse é o parâmetro que enviaremos ao procedimento;

data_type: tipo de dados permitido para este parâmetro (INT, DECIMAL, CHAR [...]);

corpo_da_rotina: onde são definidos os comandos SQL que farão alguma manipulação e/ou defenderão alguma lógica, podendo retornar ou não algum resultado.

PRIMEIRO EXEMPLO!

Nesse primeiro exemplo, implementaremos um Stored Procedure bem simples, que nos devolverá um olá! Abra um terminal do seu Linux ou mesmo um prompt do seu Windows e entre no Mysql digitando:

shell> mysql -u nome_usuario -psenha,

 

Usarei neste artigo o banco de dados chamado test, que já vem criado desde a instalação do MySQL. Caso não conste no seu, use um banco de dados de sua preferência.

 

 

Caso prefira, podemos usar também o MySQL Query Browser (você poderá baixá-lo em http://dev.mysql.com/get/Downloads/MySQLGUITools/mysql-gui-tools-5.0r12-linux-i386.tar.gz/from/pick?done=0e56b35d372ca1 dentro de um pacote chamado MySQLGUITools). NO Windows basta instalar e no Linux basta descompactar o pacote TAR e executar.

Se você optou pelo MySQL Client, nesse momento estamos nesse ponto:

Se você tiver optado por trabalhar com o MySQL Query Browser, estamos nesse ponto:

 

 

Pronto! O Query Browser já nos deu quase tudo pronto para escrevermos somente os parâmetros que teremos no nosso procedimento e o corpo da rotina. Notem que, é utilizado o operador DELIMITER para mudar o delimitador de comandos, que por padrão é o “;”. no meio do procedimento, caso não mudemos, o procedimento será enviado pela metade e um erro será enviado por na sintaxe. 

O DELIMITADOR no MySQL, em outras situações, por padrão também é chamado de terminador, Para verificar qual o delimitador da sessão corrente emita o comando STATUS, seguido por “;” ou o delimitador personalizado.

...

Entendendo e usando índices - Parte 1

 

A partir desta edição, começaremos uma série de colunas, nas quais falaremos detalhadamente sobre índices; por que criar e como criar, como manter, qual a sua importância, melhores práticas, como funciona a “famosa” árvore binária, índices clusterizados e não-clusterizados... Enfim, iremos abordar tudo o que for importante saber para trabalhar bem essa feature básica e muito relevante nos bancos de dados objeto-relacionais.

 

Vale salientar, que os sources SQL/T-SQL aqui apresentados foram escritos e testados em ambiente Windows XP Professional, rodando SQL Server 2000 com Service Pack 4 instalado, usando o módulo Query Analyser.

 

Como o SQL Server armazena e acessa dados

 

O uso de índices pode trazer grandes melhorias para o desempenho do banco de dados. Pensando nisso, devemos então, primeiramente, entender como funciona o mecanismo que está trabalhando nos bastidores.

        

Os registros são armazenados em páginas de dados, páginas estas que compõem o que chamamos de pilha, que por sua vez é uma coleção de páginas de dados que contém os registros de uma tabela. Cada página de dados tem seu tamanho definido em até 8 Kb, apresenta um cabeçalho, também conhecido como header, que contém arquivos de links com outras páginas e identificadores (hash) que ocupam a nona parte do seu tamanho total (8 Kb) e o resto de sua área é destinada aos dados. Quando são formados grupos de oito páginas (64 Kb), chamamos este conjunto de extensão.

 

Os registros de dados não são armazenados em uma ordem específica, e não existe uma ordenação seqüente para as páginas de dados. As páginas de dados não estão vinculadas a uma lista, pois implementam diretamente o conceito de pilhas. Quando são inseridos registros em uma página de dados e ela se encontra quase cheia, as páginas de dados são divididas em um link é estabelecido para marcações e ligações entre elas.

 

Como os dados são localizados

 

Dentro da Arquitetura de índices do SQL Server, (assunto que detalharemos mais à frente) existem dois métodos para acesso a dados:

 

• Exame de tabela, que examina todas as páginas de dados das tabelas, começando do início da tabela passando por todos os registros, página a página e extraindo aqueles que satisfazem aos critérios da consulta.

 

• Usando índices, percorrendo a estrutura da árvore do índice para localizar os registros, por comparação, extraindo somente aqueles registros necessários para satisfazerem os critérios passados pela consulta.

Antes de tomar qualquer das decisões que foram apresentadas, o otimizador de consultas, componente responsável pela análise do melhor plano de execução da consulta, determina qual método será mais eficiente para recuperar os dados.

 

Mas a pergunta que surge rapidamente é, “Por que devo criar índices?”.

 

Por que criar índices

 

Os índices aceleram a recuperação dos dados. Por exemplo, imagine que você compre um livro de 800 páginas para suas pesquisas acadêmicas e este não apresente em seu conteúdo um índice reportando o seu conteúdo. Uma pesquisa talvez não fosse tão pavorosa, mas se você precisar de várias pesquisas, seria muito desagradável ficar horas procurando o conteúdo que deseja estudar. Por outro lado, um livro que apresente um índice de suas abordagens, se faz muito mais fácil e torna as pesquisas até prazerosas, pois teremos condição de irmos direto ao ponto que queremos.

 

Índices são sempre bem vindos em colunas de grande seletividade, como por exemplo, além da chave primária, que muitas vezes pode circular como identificador único da entidade na sua aplicação, você pode ter também um índice para colunas que poderão lhe auxiliar em consultas em que estas contarão com a cláusula WHERE, precisando ou não usar os operadores AND, OR ou *NOT, que muitas vezes, em casos específicos, alteram a performance da consulta.

 

Nota: *O operador NOT sempre deixará sua consulta mais lenta que o normal.

 

Um bom exemplo da criação necessária de índices, são aplicações bancárias que atendem à caixas eletrônicos. Sempre que solicitamos uma determinada transação ou mesmo informação, tal solicitação tende a ser cada vez mais rapidamente atendida. E quantos correntistas geralmente têm os grandes bancos? Será que quanto mais correntistas, mais lenta será a consulta?

 

Se não os índices, uma pesquisa pelo seu saldo demoraria quase o tempo de um almoço para retornar seu saldo ou mesmo, retornar uma resposta a sua solicitação de saque. Uma vez tendo ciência do funcionamento dos índices, respeitando a sua regra de negócios, uma consulta deverá ter resposta em tempo satisfatório.

 

Por que não criar índices

 

Os índices são muito bons no sentido de performance do banco de dados, otimizam as buscas de dados, mas, por outro lado, consomem muito espaço em disco, o que pode se tornar concorrente do próprio banco se você o detém em um espaço generoso ou pode se tornar caro quando de detém o banco em um storage.

 

Considere as seguintes observações antes de criar índices:

 

·         Quando colunas indexadas são modificadas, o SGBD desloca recurso internamente para manter esses índices atualizados e associados;

·         A manutenção de índices requer tempo e recursos, portanto, não crie índices que não serão usados efetivamente;

·         Quando se contém grande quantidade de dados duplicados, índices apresentam mais custo que benefícios. Assim como usar índices com atributos de pouca variação, como “sexo” ou atributos do tipo flag.

 

 

 

Arquitetura de Índice

 

A arquitetura de índice contemplada dentro do SQL Server 2000 compreende-se em torno de tipos de índices e pilha de dados.

 

Existem três tipos de índices:

 

• Índices de agrupamento ou ordenados: Os dados são armazenados em uma página de dados, em rodem crescente. A ordem dos valores nas páginas de índice também é crescente.
• Índice sem agrupamento e de hash, criado sobre uma pilha: Quando um índice sem agrupamento é criado sobre a pilha, o SQL Server usa os identificadores de registros das páginas de índice que indicam os registros das páginas de dados.
• Índices sem agrupamento ou de hash criados sobre um índice agrupado ou ordenado: Quando um índice sem agrupamento é criado sobre uma tabela com um índice de agrupamento, o SQL Server usa uma chave de agrupamento nas páginas de índice que indicam o índice de agrupamento. A chave de agrupamento armazena informações sobre a localização dos dados (headers em forma de hash).

Para manipular as pilhas, o SQL Server apresenta um mecanismo chamado “IAM” (Index Allocation Map), que contêm informações sobre onde às extensões de uma pilha são armazenadas. São usadas para navegar pela pilha e encontrar espaços disponíveis para os novos registros inseridos e, além disso, são responsáveis por conectar as páginas de dados.

 

No caso que você tenha um atributo inteiro, definido como chave primária e sendo assim, declarado com IDENTITY, a pilha de dados poderá não conter a mesma ordem física, caso seja uma tabela com grande volume de inserções e exclusões. A figura abaixo mostra uma pilha contendo a chave primária ‘código’ e um índice qualquer ‘nome’. Olhando bem a figura você compreenderá que o mecanismo de arrumação da pilha, rapidamente, após uma exclusão seguida por um novo cadastro, faz a realocação do novo registro e este é inserido onde anteriormente existia um valor. Resumindo, o mecanismo restaura o espaço para novos registros na pilha após exclusões.

 

 

 

...

Introdução às Stored Procedure com SQL Server 2000/2005

 

 

Olá pessoal,

 

 

Mais uma vez, vamos abordar um assunto interessante, para o qual, recebi muitos e-mails quando abordei que falaria sobre neste artigo. Agradeço as pessoas da faculdade Federal Fluminense e da Federal do Paraná que escreveram pedindo uma enfática no assunto que irei abordar.

 

Todos, desenvolvedores, analistas e DBA’s já estão bem cientes que os bancos de dados relacionais de nosso tempo e desde algum tempo atrás, já contemplam procedimentos armazenados e estes são realmente de muito proveito em várias situações do desenvolvimento. Para aqueles que trabalham com implementações em sistemas web, este é um ótimo recurso para garantir que o seu banco não terá “filhos órfãos”, já que, por exemplo, um usuário pode desistir da compra no meio dela. Já pensou nisso?

 

Neste primeiro artigo, mostrarei alguns exemplos práticos para que fiquemos bem familiarizados com os conceitos inicias. Saliento também que, a prática no desenvolvimento destas rotinas lhe trará maior segurança com o passar do tempo. Todos os procedimentos que serão apresentados terão sua abordagem tanto no SQL Server 2000 quanto no SQL Server 2005 e somente serão apontados quando se tratar de alguma diferença relevante.

 

Um procedimento armazenado (Stored Procedure), é uma coleção de instruções implementadas com linguagem T-SQL (Transact-Sql, no SQL Server 2000/2005), que, uma vez armazenadas ou salvas, ficam dentro do servidor de forma pré-compilada, aguardando que um usuário do banco de dados faça sua execução. Geralmente, assim como VIEWS fazem com relatórios e dados estatísticos escalonáveis, os SP’s encapsulam tarefas repetitivas, desde um simples INSERT, passando por inserções por lote, updates e algumas outras instruções mais complexas, como, efetuar uma efetivação de saque em uma conta de um determinado cliente em uma instituição bancária ou efetivar saídas de mercadorias seguido por baixa em estoque. Eles oferecem suporte a variáveis declaradas pelo próprio usuário, uso de expressões condicionais, de laço e muitos outros recursos, os quais veremos alguns mais à frente.

 

As vantagens do uso de Stored Procedures são claras:

 

·         Modularidade: passamos a ter o procedimento divido das outras partes do software, bastante alterarmos somente às suas operações para que se tenha as modificações por toda a aplicação;

 

·         Diminuição de I/O: uma vez que é passado parâmetros para o servidor, chamando o procedimento armazenado, as operações se desenolam usando processamento do servidor e no final deste, é retornado ou não os resultados de uma transação, sendo assim, não há um tráfego imenso e rotineiro de dados pela rede;

 

·         Rapidez na execução: os stored procedures, após salvos no servidor, ficam somente aguardando, já em uma posição da memória cache, serem chamados para executarem uma operação, ou seja, como estão pré-compilados, as ações também já estão pré-carregadas, dependendo somente dos valores dos parâmetros. Após a primeira execução, elas se tornam ainda mais rápidas;

 

·         Segurança de dados: podemos também, ocultar a complexidade do banco de dados para usuários, deixando que sejam acessados somente dados pertinentes ao tipo de permissão atribuida ao usuário ou mesmo declarando se o Stored Procedure é proprietário ou público, podendo ser também criptografada com WITH ENCRYPTION.

 

 Ex.: Utilizando WITH ENCRYPTION no SQL Server 2000:

 

Imagem I – Acessando o conteúdo de um Procedimento Armazenado pelo * Object Browser  no SQL Server 2000.

 

Ex.: Utilizando WITH ENCRYPTION no SQL Server 2005:

Imagem II - Acessando o conteúdo de um Procedimento Armazenado pelo * Object Explorer  no SQL Server 2005.

 

Repare nas imagens exibidas acima que, no SQL Server 200, recebemos uma  janela de conexão do objeto Procedure, nos mostrando que este fora criado de forma criptografada e que o conteúdo somente poderá ser editado por quem a criou e mesmo assim, este também não aparecerá para o dono. Somente, copiando à parte é que teremos acesso a este procedimento criptografado, mesmo que seja você o dono/criador dele. O comando ALTER PROCEDURE poderá ser utilizado para modificar o conteúdo do procedimento.

Observações:

Imagem III – Brow ser e Explorer, usaremos para executar e visualizar o conteúdo de procedimentos armazenados.

 

Existem certos tipos de Stored Procedures para o SQL Server 2000 e para o SQL Server 2005, são eles:

 

·         System Stored Procedures ou Procedimentos Armazenados do Sistema: nas duas versões do SGBD, são criados no momento da instalação e ficam armazenados no banco de dados chamado master, junto com as entidades e outros procedimentos próprios do sistema. São ultilizados das mais diversas formas. Um exemplo clássico, que utilizo muito, é o SP_HELPINDEX, para checar os índices de uma determinada tabela, como mostra a imagem abaixo:

 

Imagem IV – System Stored Procedure, exemplo da tabela locadora do artigo sobre associação de tabelas.

 

·         Local Stored Procedure ou Procedimentos Armazenados locais: esess procedimetjos são criados em bancos de dados de usuários individuais, ou seja, no SQL Server 2000 são proprietárias. Já no SQL Server 2005, tem o nome de Stored Procedures Temporárias Locais, que iniciam com um sinal de # e somente a conexão que a criou poderá executá-la. Ainda no SQL Server 2005, existem os Procedimentos Temporários Globais, que podem ser utilizados de forma global, ou seja, por qualquer usuário desta conexão e iniciam com ##. Ao ser encerrada esta conexão, os dois procedimentos são eliminados.

 

...

Associando Tabelas no SQL Server

 

Olá pessoal,

 

Depois de estar um tempo afastado aqui da nossa coluna do portal da Devmedia – SQL MAGAZINE - retorno para apresentar um assunto que muitos programadores e iniciantes em programação SQL abordam em alguns fóruns e listas nas quais atuo como moderador.

 

Primeiramente, vamos passar por conceitos de modelagem de dados, modelos conceituais, relacionais e físicos e então apresentarei os tipos de JOIN que são implementados dentro do SQL Server 2000. Salientando também que os códigos (SQL) que aqui serão abordados, foram escritos em ambiente Windows rodando a versão XP Professional e com Servidor SQL Server 2000 Developer Edition.

 

MODELO RELACIONAL

 

O modelo relacional se resume diretamente em tabelas e relacionamentos. Uma vez definido o modelo conceitual, ou o modelo E-R, podemos convertê-lo, implementando tabelas para armazenar os dados e relacionando-as para garantir integridade e diminuir a redundância do modelo.

 

As tabelas também são conhecidas como entidades ou mesmo relações e é composta por linhas que também podem ser chamadas de registros ou tuplas.

 

Um registro é composto por vários atributos que são ordenados dentro de cada entidade. Cada atributo está em uma coluna, que conterá valores que, uma vez combinados, formarão a informação – vale salientar o conceito de ”dado” e “informação”.

 

Resumindo, o modelo relacional é aquele que está em meio físico e contempla a realidade de um banco de dados: tabelas e relacionamento.

 

MODELAGEM DE DADOS

 

Certa vez, há algum tempo atrás, tive que apresentar um projeto para uma locadora de carros, a qual gostaria de focar em um sistema que resolvesse seus problemas de desorganização. Eram pilhas e mais pilhas de papéis contendo informações de quem alugou tal veículo, quanto tempo, quilometragem gasta e valor de acordo com a quilometragem gasta. Detalhe, a ficha passava pela aprovação de três setores antes da liberação do veículo para o locatário furioso que aguardava na recepção da empresa.

 

Pensando no foco do problema, considerei o seguinte modelo:

 

 

 

Para a construção desse modelo foram levadas em conta algumas premissas básicas em relação à cardinalidade, como:

 

• Há clientes cadastrados que alugam carros e outros não;
• Um automóvel pode ser locado por um ou mais clientes;

Não levarei em consideração aqui, a questão de quantidades de automóveis de um mesmo tipo. Consideraremos que existe somente um automóvel de cada dentro da locadora. (Examine o source, caso faça o download que temos um índice criado para impedir o cadastro de mais de um automóvel com o mesmo nome).

 

Diante dessa proposta, como foi definido no E-R acima, temos um relacionamento muitos-para-muitos que, obrigatoriamente gera uma terceira tabela que terá a movimentação do relacionamento que dei o nome de “locação”.

 

DEFINIDO O MODELO FÍSICO

 

Temos então, cinco tabelas:

 

1.       Cliente;

2.       Automóveis;

·         Modelo – tabela decodificação;

·         Marca - tabela decodificação;

3.       Locação;

 

Modelo relacional e diagrama do modelo físico que implementamos no banco de dados.

 

CARGA NA BASE

 

Já que agora temos nossa base de dados para a locadora, iremos dar carga nas tabelas, cadastrando alguns modelos de automóveis, marcas, alguns clientes, alguns automóveis e enfim começaremos a cadastrar as locações, que será o ponto principal da abordagem de nosso artigo, onde traremos as informações em consultas utilizando a sintaxe JOIN.

 

Lembrando que você poderá fazer o download do script SQL utilizando para montar todo esse modelo ao final do artigo.

 

CONCEITOS DE JOIN

 

As JOIN ou “associação” é uma operação que lhe permite consultar duas ou mais tabelas para produzir um conjunto de resultados que incorpore registros e colunas de cada tabela. Você pode associar tabelas em qualquer expressão que seja baseada em qualquer coluna ou combinação de colunas das tabelas envolvidas.

 

No nosso exemplo, temos uma associação de até três tabelas:

 

• Automóvel
• Marca;
• Modelo;

...

Introdução a Views

Olá Pessoal,

Escrevo esse artigo, primeiramente para reforçar os conhecimentos daqueles que já os tem e para trazer àqueles que ainda não tem em mente os conceitos e aplicações deste procedimento de banco de dados Microsoft. Este artigo foi escrito com seu foco voltado para o SQL Server 2000.

CONCEITOS

O que é uma view?
Onde se aplicam as views?
Ela é um procedimento armazenado?
Uma view influencia na desempenho de um banco de dados?
Como são criadas?
Como executamos, após a sua criação?

Uma view é uma maneira alternativa de observação de dados de uma ou mais entidades (tabelas), que compõem uma base de dados. Pode ser considerada como uma tabela virtual ou uma consulta armazenada.

Geralmente e recomendável, uma view, implementada encapsulando uma instrução SELECT (busca de dados para exposição), guarda os dados em uma tabela virtual, armazenando também em cache, pois todas as consultas ao banco, encapsuladas ou não, ao serem executadas, são armazenadas em cache. Por este motivo, pode ser mais rápido ter uma consulta armazenada em forma de view, em vez de ter que retrabalhar uma instrução.

As views nos possibilitam mais que simplesmente visualizar dados. Elas podem ser implementadas também com algumas aplicações de restrição:

- Restrição usuário x dados;

Ex.: Seu departamento de vendas não precisa saber ou ter acesso a uma coluna que contém valores (dados) referentes aos salários dos desenvolvedores.

- Restrição usuário x domínio;

Ex.: Podemos restringir o acesso de um usuário específico a colunas (domínios) específicas (os) de uma tabela.

- Associar vários domínios formando uma única entidade;

Ex.: Podemos ter várias "JOIN" encapsuladas em uma view, formando somente uma tabela arbitrariamente.

- Agregar informações, em vez de fornecer detalhes;

Ex.: Podemos apresentar um somatório de despesas em ligações de um determinado usuário, restringindo acesso aos detalhes da conta.

As vantagens de se usar views são:

- Economizar tempo com retrabalho;

Ex.: Você não precisar escrever aquela instrução enorme. Escreva uma vez e armazene!

- Velocidade de acesso às informações;

...

Boas Vindas

 

Amigos internautas,

 

Primeiramente, agradeço à revista SQL MAGAZINE e Rodrigo Spinola, pelo espaço cedido para a coluna e torço para que a nossa caminhada seja de bastante sucesso, tanto para os artigos quanto para o aprendizado do que será apresentado.

 

Falaremos de maneira bem técnica, de implementações voltadas para os bancos de dados SQL Server da Microsoft e também do MySQL, da MySQL AB.

 

Bom, diante do proposto, desejo que nossos encontros sejam prazerosos e de bastante aprendizagem.

 

Ficarei muito feliz em receber o seu e-mail solicitando temas para nossa coluna!

 

Espero que gostem e bons estudos!

-->">