Conceitos de Programação e Arquitectura de Software (I)

Introdução

Hoje em dia a complexidade dos sistemas de software, exige a sua concepção e desenvolvimento obedeçam a regras criteriosas, à utilização das tecnologias e técnicas mais adequadas e à aplicação de boas práticas.

Um dos pontos chave para atingir o objectivo de criar bons sistemas é a Arquitectura de Software.

Mas o que é isso da Arquitectura de Software? E as técnicas? E as boas práticas?

O objectivo desta série de artigos é dar resposta a estas e muito mais perguntas, sistematizando, de forma clara e sucinta, um conjunto de conceitos base sobre arquitectura e desenvolvimento de software, para novos programadores.

O artigo foca-se na Programação Orientada a Objectos (POO) e os exemplos apresentados foram desenvolvidos na linguagem C#, da plataforma Microsoft .NET, mas os conceitos são aplicáveis a qualquer outra tecnologia ou linguagem.

Conteúdo

• 1. Arquitectura de Software
  • 1.1. O que é a Arquitectura de Software?
  • 1.2. Porque é importante a Arquitectura de Software?
  • 1.3. Quais os objectivos da Arquitectura de Software?
  • 1.4. Arquitecturas por camadas
    • 1.4.1. O que é a arquitectura de 2 camadas (2-tier)?
    • 1.4.2. O que é a arquitectura de 3 camadas (3-tier)?
    • 1.4.3. O que é a Data Access Layer (DAL)?
    • 1.4.4. O que é a Business Logic Layer (BLL ou BL)?
    • 1.4.5. O que é a Presentation Layer (PL ou UI)?
  • 1.5. Algumas Arquitecturas populares
    • 1.5.1. O que é a Arquitectura MVC?
    • 1.5.2. O que é a Arquitectura SOA?
• Referências

1. Arquitectura de Software

1.1. O que é a Arquitectura de Software?

A Arquitectura de Software corresponde ao processo de de criar uma solução estruturada que responda a todos os requisitos técnicos e operacionais do sistema. Consiste na estrutura, ou estruturas de alto nível do sistema, às regras, procedimentos heurísticos e padrões para criar tais estruturas e à documentação dessas estruturas.

“As estruturas do sistema compreendem elementos de software, as propriedades desses elementos, visíveis do exterior e as relações entre eles. A arquitectura preocupa-se com a parte pública dos interfaces, os detalhes privados dos elementos de software – aqueles que dizem respeito apenas à implementação – não são arquitecturais.”
-- Bass, Clements e Kazman
”Software Arquitecture in Practice” (3ª edição)

A arquitectura de software NÃO É um conjunto ou uma pilha de tecnologias (entenda-se aqui tecnologias como as ferramentas, técnicas e APIs usadas para construir o sistema).

No mundo da programação, quando alguém pergunta como vamos arquitectar uma dada aplicação, muitas vezes dizemos, por exemplo, que vamos construir um sistema baseado em “ASP.NET MVC 4, com uma camada de serviços WCF, em cima duma framework e os dados são guardados numa BD do SQL Server”. Isto é uma pilha de tecnologias, mas não nos descreve como vai ser o sistema. É como se perguntássemos qual a arquitectura de um edifício e nos dissessem que é feito com tijolos, cimento e que vão ser usadas betoneiras e colheres de pedreiro para o construir.

1.2. Porque é importante a Arquitectura de Software?

A arquitectura de um sistema define as grandes decisões a serem tomadas.

Primeiro temos que identificar os requisitos do sistema, que pode ser de diferentes tipos.

Como podemos ver, nem todos os requisitos são compatíveis entre si. Então, temos que tomar decisões que garantam que o sistema está equilibrado - que corresponde aos objectivos para que foi desenhado, dentro do ambiente onde vai ser executado.

Em resumo, a arquitectura de software é importante porque:

• Controla a complexidade
• Força a aplicação das melhores práticas
• Dá consistência e uniformidade
• Aumenta a previsibilidade
• Permite a reutilização

1.3. Quais os objectivos da Arquitectura de Software?

O principal objetivo da arquitectura de software é identificar os requisitos que afectam a estrutura do sistema. A arquitectura procura construir uma ponte entre os requisitos de negócio e os requisitos técnicos, através da compreensão dos Casos de Uso e da definição de formas de implementar esses casos de uso no software.

Lembrar que a arquitectura deve:

• Expor a estrutura do sistema, mas esconder os detalhes de implementação
• Identificar todos os casos de utilização e cenários
• Tentar dar resposta aos requisitos de vários intervenientes (stakeholders)
• Tratar dos requisitos funcionais e de qualidade

1.4. Arquitecturas por camadas

1.4.1. O que é a arquitectura de 2 camadas (2-tier)?

A arquitectura de 2 camadas refere-se ao modelo cliente/servidor, termo que começou a ser usado na década de 1980, referindo-se a computadores pessoais ligados em rede. O modelo cliente/servidor real começou a ganhar aceitação no final de 1980 e mais tarde foi adoptado para a programação Web.

Actualmente, na utilização da arquitectura de 2 camadas, os interfaces do utilizador (UI) (p.ex. todas as páginas Web, numa aplicação para Internet) são executados no cliente e a Base de Dados (BD) é armazenada no servidor. A lógica da aplicação pode ser executada no cliente ou no servidor. Portanto, neste caso, o UI vai aceder diretamente à BD. Os clientes também podem ser motores de processamento (e não de interface), que fornecem soluções para outros sistemas remotos ou locais.

Em qualquer dos casos, hoje em dia, o modelo de 2 camadas é preterido em relação ao modelo de 3 camadas. A vantagem de um sistema de 2 camadas é a sua simplicidade, mas a simplicidade tem o custo da escalabilidade. A arquitectura de 3 camadas (mais recente) introduz uma camada intermédia, para a lógica da aplicação.

1.4.2. O que é a arquitectura de 3 camadas (3-tier)?

A arquitetura de 3 camadas surgiu na década de 1990 com o intuito de superar as limitações da arquitetura de 2 camadas. Esta arquitectura tem sido intensivamente adoptada e aperfeiçoada pelos modernos projectistas e programadores de sistemas Web.

O modelo de 3 camadas é uma arquitetura cliente/servidor em que o UI, a lógica funcional, o armazenamento de dados e o acesso aos dados são desenvolvidos e mantidos como módulos independentes (algumas vezes até em plataformas distintas). O termo "três camadas" ou "três níveis" (3-layer), bem como o conceito de arquitecturas multi-camada, parece ter sido originado a partir do Software Rational.

A arquitetura de 3 camadas, classicamente, tem os seguintes níveis:

• Camada de apresentação ou de servidor Web: Interface do Utilizador, que exibe os dados para ou aceita inputs do utilizador (ver detalhes abaixo).
• Camada de Lógica de Negócio/Aplicação ou Servidor Aplicacional: Validação e aceitação dos dados antes de guardar na BD, processamentos, cálculos e todas as outras operações específicas do negócio/aplicação (ver detalhes abaixo).
• Camada de Dados ou Servidor BD: Simples operações de leitura e escrita de dados na BD ou em qualquer outro sistema de armazenamento (ver detalhes abaixo).

1.4.3. O que é a Data Access Layer (DAL)?

A Camada de Acesso a Dados (DAL) consiste principalmente num conjunto simples de código que efectua as interações básicas com a BD ou qualquer outro dispositivo de armazenamento de dados. Estas funcionalidades são muitas vezes referidos como CRUD (Create, Retrieve, Update, Delete).

A DAL deve ser genérica, simples, rápida e eficiente. Não deve incluir lógica de negócio/aplicação complexa. Muitos sistema têm longas e complexas Stored Procedures (SP), que são executadas para uma simples operação de leitura de dados. Estas SP contém, muitas vezes, lógica de negócio, lógica da aplicação e lógica de UI também. Se uma SP estiver a ficar muito longa, isso é sinal de que está a colocar a lógica de negócio na DAL.

1.4.4. O que é a Business Logic Layer (BLL ou BL)?

Ao lermos a imensa documentação disponível sobre este tema, percebemos que nem todos os autores concordam com o que é a Camada de Lógica de Negócio (BL). Em muitos casos é apenas uma ponte entre a Camada de Apresentação e a Camada de Dados, sem qualquer função adicional que não seja passar dados de uma lado para o outro. No entanto, nada nos impede de alterar a abordagem a este tipo de BL. Mas a mudança deve ser feita como e quando se sentir confortável de que o método a aplicar é flexível o suficiente para suportar o crescimento do sistema. Existem muitas maneiras excelentes de implementar a BL, mas tenha cuidado ao selecioná-las, pois podem complicar em excesso um sistema simples. É um equilíbrio que é preciso encontrar com base na sua experiência.

Como recomendação geral, deve decidir como mapear os dados das tabelas para Entidades de Negócio (classes) correctamente definidas. As entidades de negócio devem levar em consideração os vários tipos de requisitos e funcionamento do sistema. Pode-se usar uma abordagem de definir uma entidade separada para cada tabela da BD (a maioria dos ORMs levam a isto), mas recomenda-se a criação de entidades que permitam encapsular as exigências funcionais e de UI da aplicação, que podem ser autónomas ou, por exemplo, agregar várias entidades relacionadas com as tabelas da BD.

1.4.5. O que é a Presentation Layer (PL ou UI)?

A Camada de Apresentação ou Interface com o Utilizador (UI), como o nome indica, interage directamente com o utilizador. Tipicamente é constituída por um ambiente gráfico composto por variados objectos (controlos) que permitem ao utilizador interagir com o sistema, quer através da introdução e visualização de dados, quer através da realização de acções e introdução de comandos.

1.5. Algumas Arquitecturas populares

1.5.1. O que é a Arquitectura MVC?

A arquitetura Model-View-Controller (MVC) separa a modelagem do domínio, a apresentação e as ações baseadas nos inputs do utilizador (lógica de apresentação) em três classes distintas.

Infelizmente, a popularidade deste modelo resultou em alguns usos defeituosos. Cada tecnologia (Java, ASP.NET, etc.) definiu-o da sua própria maneira, fazendo com que seja difícil de entender. Em particular, o termo "controlador" tem sido usado para significar coisas diferentes em contextos diferentes. As definições abaixo estão o mais próximo possível da tecnologia ASP.NET MVC.

• Model: conjunto de classes que criam um modelo do sistema, usado para apresentar os dados ao utilizador. Podemos ter entidades de negócio, coleções, DataSets, etc.
• View: ficheiro de página Web (HTML, Javascript) que se encarrega de implementar o UI.
• Controller: classe que recebe os pedidos e eventos despoletados pelas acções do utilizador na View.

Num sistema distribuído de n camadas, a arquitetura MVC tem o papel vital de organizar a Camada de Apresentação.

Recomenda-se a consulta do artigo “ASP.NET MVC vs ASP.NET Web Forms – Porquê o MVC?” para maior detalhe nos conceitos desta arquitectura.

1.5.2. O que é a Arquitectura SOA?

A Arquitetura Orientada a Serviços (SOA) é  um modelo de programação em que as funcionalidades das aplicações são disponibilizadas como serviços, que utilizam o paradigma pedido/resposta para estabelecer a comunicação entre os sistemas clientes e os sistemas que implementam os serviços.

A SOA é essencialmente uma coleção de serviços, que comunicam uns com os outros e com os sistemas clientes. A comunicação pode envolver a simples passagem de dados ou pode envolver dois ou mais serviços na coordenação de alguma atividade.

Com o desenvolvimento das aplicações baseadas em Web, a utilização de Web Services tornou-se popular, tendo-se assistido a uma proliferação dos sistemas SOA. Todavia há que salientar que um serviço não é necessariamente um web service, nem tem que estar relacionado com a Web.

A SOA pode ser ainda usada como o conceito para conectar vários sistemas de prestação de serviços. Esta arquitectura tem um grande quinhão de participação no futuro do mundo das TI.

Referências

- MSDN Patterns & Practices
- Microsoft Application Architecture Guide
- Code Project - Introduction to Object Oriented Programming Concepts (OOP) and More
- Learn Visual Studio.NET - Application Architecture Fundamentals

Como encontrar a Chave do Windows ou do Office

Se estiver a pensar fazer uma reinstalação do Windows, mas não consegue encontrar a chave do produto, está com sorte, porque esta está armazenada no Registo do Windows ... só que não é fácil de encontrar e é impossível de ler, sem alguma ajuda. Felizmente, estamos aqui para ajudar.

Como se pode ver na imagem abaixo, a identificação do produto é armazenado no registo, mas está em formato binário, que não pode ser lido por seres humanos.

Não se compreende porque razão a Microsoft se deu a tanto trabalho para tornar difícil de ver as chaves de produto do seu software, especialmente porque elas são armazenados no registo e pode ser lidas por software. Só podemos supor que eles não querem ninguém a reutilizar uma chave de um computador antigo.

Mas a realidade é que podemos até recuperar uma chave de produto a partir dum computador que já nem sequer arranque o sistema. Tudo o que é necessário é ter acesso ao disco, a partir de outro computador. Mais à frente neste artigo, vamos ver como podemos realizar esta tarefa.

Encontrar a Chave do Windows sem nenhum software

Assumindo que consegue arrancar o computador com o Windows, sem problemas, pode facilmente criar um VBScript simples que vai ler o valor da chave, no registo e, em seguida, vai traduzi-lo para o formato que necessita para a reinstalação.

Temos aqui um exemplo desse VBScript, fornecido por um utilizador do forum da How-To Geek:

Set WshShell = CreateObject("WScript.Shell")
MsgBox ConvertToKey(WshShell.RegRead("HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DigitalProductId"))
Function ConvertToKey(Key)
Const KeyOffset = 52
i = 28
Chars = "BCDFGHJKMPQRTVWXY2346789"
Do
Cur = 0
x = 14
Do
Cur = Cur * 256
Cur = Key(x + KeyOffset) + Cur
Key(x + KeyOffset) = (Cur \ 24) And 255
Cur = Cur Mod 24
x = x -1
Loop While x >= 0
i = i -1
KeyOutput = Mid(Chars, Cur + 1, 1) & KeyOutput
If (((29 - i) Mod 6) = 0) And (i <> -1) Then
i = i -1
KeyOutput = "-" & KeyOutput
End If
Loop While i >= 0
ConvertToKey = KeyOutput
End Function

Copie o texto acima e cole num novo documento do Bloco de Notas (Notepad). De seguida, escolha a opção Ficheiro | Guardar Como e na opção “Guardar com o tipo”, escolha “Todos os ficheiros (*.*)”. Finalmente, no nome do ficheiro, insira chave_windows.vbs, ou outro nome qualquer, desde que a extensão seja vbs.

Sugerimos coloque no Ambiente de Trabalho, para mais fácil acesso.

Depois de salvar o ficheiro, basta fazer duplo-clique sobre o mesmo e uma pop-up vai mostrar a chave do Windows do computador:

Use um utilitário para recuperar chaves de produto (mesmo que o Windows do PC não arranque)

A maneira mais fácil de ter acesso a uma chave de produto é através de um utilitário de terceiros.

Vamos usar, como exemplo, o utilitário ProductKey, da NirSoft. As ferramentas desta editora são sempre livres de lixo, e bastante úteis. O único problema com este utilitário em particular é que alguns antivírus irá detectá-lo como um falso positivo, porque alguns malwares podem tentar roubar a sua chave de produto.

Tudo o que necessita é fazer download do ProduKey, descompactá-lo e, em seguida, executá-lo para ver imediatamente todas as suas chaves de produto instaladas. É tão simples como isso.

Pode também fazer o download do ficheiro de tradução para Português. Após descompactar, basta copiar o ficheiro .ini para a pasta onde instalou o utilitário ProductKey.

Se quiser recuperar uma chave a partir de um computador que não arranque o sistema, pode ligar o disco rígido a outro PC, e depois executar o ProduKey. Neste caso, usa a opção Ficheiro | Selecionar Fonte e procura a pasta do Windows, no disco do computador avariado. Pode, então, ver as chaves dos produtos.

Também pode usar um Live CD de Linux, para copiar o diretório do Windows do computador avariado, para uma pen-drive, ou copiar apenas os ficheiros de registo, se preferir.

Tradução livre do artigo "How to Find Your Lost Windows or Office Product Keys", de Lowell Heddings para a How-To-Geek.

Windows: Qual a diferença entre edição “OEM” e “Retalho”

Já tentou comprar uma licença do Windows na Amazon ou outra loja online? E em lojas nacionais, como a FNAC ou a WORTEN?

Parece simples, mas nem sempre é. A realidade é que vai encontrar licenças System Builder (OEM), mais baratas e licenças Full Version (Retalho), mais caras.

Então a pergunta que se coloca é: Qual a diferença entre estas versões?

Antes de mais, devemos esclarecer que, no que toca a funcionalidades, ambas as edições são idênticas, i.e., instalando uma versão OEM ou uma versão de Retalho, o seu Windows funciona da mesma forma.

Vamos ver um pouco mais em detalhe as diferenças.

As licenças destinam-se a alvos diferentes

Os dois tipos de licença diferem conceptualmente. A licença OEM é destinada aos fabricantes e integradores de hardware, que constroem computadores para depois vender a terceiros, enquanto a licença de Retalho se destina ao público em geral (pelo menos em teoria – a realidade é que a maioria dos utilizadores não compra o Windows numa caixa).

Licenças Versão Completa/Retalho (Full Version/Retail)
Estas são as licenças standard para o consumidor do Windows. Elas foram projectadas para os normais utilizadores de computadores, que pretendem comprar uma licença para actualizar a sua máquina para uma nova versão do Windows. Este tipo de licença permite ao utilizador instalar o Windows em qualquer computador e mesmo mudar para outro, mas a mesma licença só pode estar instalada num único PC em cada momento.

Se alguma vez entrou numa loja de informática e viu uma caixa com o logo do Windows, numa prateleira, então estava a olhar para uma edição de Retalho do Windows.

Licenças Integrador Sistemas/OEM (System Builder/OEM)
Estas licenças são usadas pelos fabricantes de computadores (OEM – Original Equipment Manufacturers). São usadas não só pelos grandes fabricantes como IBM, Asus ou Dell, como pelos pequenos integradores e lojas locais de informática, onde podemos comprar computadores com configurações à medida. Este tipo de licença fica vinculada ao PC onde é instalada a primeira vez, para sempre. Não pode ser usada noutro PC.

Posso usar uma licença OEM?

A Microsoft tem alternado a sua política no tocante a permitir ou não que os normais entusiastas da computação usem licenças OEM, quando constroem as suas próprias máquinas.

No Windows XP, Windows Vista, e Windows 8, era permitido.
No Windows 7 e agora no Windows 8.1, não é permitido.

Mas não vai saber isto a não ser que leia as letras miúdas das licenças.

Antes do Windows 7, a compra de uma licença OEM para o seu próprio PC era perfeitamente legítima. Com o Windows 7, a Microsoft alterou as populares licenças OEM do Windows. As pessoas normais deixaram de estar autorizadas a usá-las para construir seus próprios PCs, mas a Microsoft continuou a vender massivamente as licenças OEM a essas mesmas pessoas. Por exemplo, este ainda é o S.O. mais vendido na Amazon e a Microsoft sabe porquê: porque as pessoas normais compram a versão OEM (mais barata).

 

A Microsoft viu que a desregulação do licenciamento OEM do Windows 7 estava de loucos, por isso resolveu corrigir a situação no Windows 8 - foi acrescentada uma permissão de “Licença de Uso Pessoal”, à licença OEM do Windows 8. Isso significa que pode comprar uma licença Windows 8 OEM e usá-la num computador que esteja a montar em casa, para seu uso pessoal.

No fim de contas, as pessoas estavam a usar licenças OEM nas suas máquinas pessoais e a Microsoft acabou simplesmente por normalizar a situação que ela própria tinha criado com a alteração ao licenciamento do Windows 7.

Entretanto, chegou o Windows 8.1, que é considerado pela Microsoft como um S.O. completamente novo. E tem novas regras de licenciamento também. A permissão de uso pessoal foi retirada da licença OEM, voltando à situação do Windows 7, sendo apenas permitida para integradores que montem máquinas para revenda.

Esta questão está claramente resumida no guia de licenciamento para uso pessoal, para parceiros OEM, da Microsoft (pode ser consultado aqui):

No entanto, já passou mais de um ano e continuamos a encontrar as cópias OEM do Windows 8.1 no topo de vendas da Amazon ou da Newegg. As pessoas continuam a comprar estas licenças, que representam uma poupança significativa, relativamente às versões de Retalho. Claramente, são compradas para uso pessoal e não por integradores ou fabricantes de computadores.

A informação sobre o licenciamento nestes sites não dizem claramente “ESTA LICENÇA NÃO É AUTORIZADA PARA USO NO SEU PRÓPRIO PC”, que é o deveria dizer se a Microsoft pensasse em levar a sério os termos do seu contrato de licença OEM. Quando pesquisa o Windows 8.1 no site da Amazon, é exibida uma mensagem que diz mais ou menos isto: “Se for um integrador de sistemas, a Amazon oferece-lhe produtos Windows OEM. Caso contrário compre os nossos títulos Windows 8.1”. Esta mensagem é demasiado vaga – qualquer pessoa que esteja a montar o seu próprio PC, pode pensar que é um integrador de sistemas. Mas não é - pelo menos de acordo com os termos da licença do Windows 8.1. Todavia, com o Windows 8, já era um integrador de sistemas. No Windows 7 também não era, mas nos anteriores era. Confuso o suficiente? Bem, as pessoas podem estar confundidas, mas as licenças OEM continuam a vender bem.

Limitações das licenças OEM

Apesar de mais baratas, as licenças OEM têm algumas limitações (legítimas):

• Licença só pode ser usada num único PC
  Após instalar a sua cópia OEM do Windows, a licença fica vinculada ao computador, para sempre. Especificamente, fica vinculada ao modelo de motherboard. A licença OEM fica associada a um único sistema, enquanto com uma licença de Retalho pode usá-la noutro computador, no futuro.
• Sem suporte directo da Microsoft
  Não dão direito a suporte directo e gratuito por parte da Microsoft. A licença OEM estipula que o construtor do sistema é o responsável por fornecer o suporte – quando compra um computador com versão OEM do Windows, é suposto a empresa ou pessoa que que lho vendeu providenciar o suporte. Se montar o seu próprio computador com uma licença OEM do Windows, então é responsável por fornecer o seu próprio suporte. Claro que as licenças Windows OEM permitem obter e instalar as actualizações do Windows Update.
• Escolher 32 bits ou 64 bits na compra
  Quando compra uma versão OEM do Windows, tem que escolher a media de instalação de 32 bits ou de 64 bits, enquanto na versão de Retalho, a mesma media permite instalar a edição de 32 bits ou a de 64 bits. Como a licença OEM é para usar num único PC, espera-se que a escolha da versão 32 bits ou 64 bits seja feita no momento da compra (claro que hoje em dia, deve querer apenas a edição de 64 bits, de qualquer forma).
• Não pode ser usada para atualizar o sistema
  A cópia OEM do Windows não pode ser usada para actualizar uma versão mais antiga do Windows – p.ex., a atualização do Windows XP para o Windows 7, ou do Windows 7 para o Windows 8.1. A licença está projectada para instalação em PCs novos, que ainda não tenham qualquer sistema operativo.

Que licença devo comprar?

Supondo que não tem problemas em ultrapassar os constrangimentos do licenciamento, uma versão OEM do Windows faz muito sentido se você for um geek, a construir o seu próprio PC. Se estiver disposto a vincular essa cópia do Windows ao seu hardware e não precisar ligar para o suporte da Microsoft, pode economizar algum dinheiro.

Quanto dinheiro vai poupar, depende da edição do Windows que quiser comprar e da loja onde comprar, mas, numa loja como a Amazon, consegue economizar entre os 15% e os 40%.

A Microsoft já não comercializa versões de Retalho do Windows 7, embora continue a vender versões OEM. Isto leva a situações de termos as poucas licenças de Retalho, ainda disponíveis, a custar 4 ou 5 vezes o valor da versão OEM.

Referências

“What’s the Difference Between the “System Builder” and “Full Version” Editions of Windows?”, de Chris Hoffman para a How-To-Geek.

"Microsoft is Misleading Consumers With Windows 8.1 System Builder Licensing", de Chris Hoffman para a How-To-Geek.

SQL Server: Índices (1) – Introdução

Introdução

Um dos caminhos mais importantes para obter alto desempenho numa base de dados (BD) do SQL Server são os Índices. Os índices são os objectos de BD que permitem acelerar o processo de consulta das linhas de uma tabela, de uma maneira semelhante à forma como o índice de um livro ajuda a encontrar, rapidamente, informações dentro desse livro.

Uma boa compreensão dos índices é essencial para os administradores de BD (DBA), mas também para os programadores, essencialmente pela seguinte razão: quando um pedido de dados chega ao SQL Server, este só tem duas opções possíveis para aceder às linhas solicitadas:

• Percorrer todas as linhas da(s) tabela(s) que contém os dados, examinando cada uma para ver se corresponde aos critérios de selecção;
• Ou usar um índice, se existir, para localizar rapidamente os dados solicitados.

A primeira opção está sempre disponível no SQL Server. A segunda opção só estará disponível se forem dadas instruções ao SQL Server, para criar um índice.

Como os índices têm um custo associado (ocupam espaço e devem ser mantidos sincronizados com as tabelas), não são obrigatórios no SQL Server. É possível ter uma BD sem nenhum índice. Provavelmente irá ter uma péssima performance e problemas de integridade de dados, mas o SQL Server permite criar uma BD com estas características.

Mas não é isto que nós queremos! O que queremos é uma base de dados que tenham uma boa performance, integridade de dados e, ao mesmo tempo, mantenha a sobrecarga associada aos índices, num mínimo. Neste artigo, vamos começar a tratar deste objectivo.

Conteúdo

• O que é um Índice?
• Estrutura de um Índice
• Índices Clustered e Nonclustered
• Tipos de Índices
• Limites dos Índices
• Como o SQL Server usa os Índices?
• Considerações para a criação de Índices
• Resumo
• Referências

O que é um Índice?

Índices mal concebidos e falta de índices são as fontes primárias de bloqueios nas aplicações de BD. Projectar índices eficientes é fundamental para alcançar um bom desempenho.

Os índices permitem ao SQL Server encontrar e/ou modificar dados num espaço de tempo menor, utilizando um mínimo de recursos para atingir um máximo de performance. Os índices, quando bem construídos, também permitem ao SQL Server atingir um nível de concorrência máxima, permitindo que as consultas efectuadas por um utilizador tenham pouco impacto nas consultas executadas por outros. Finalmente, os índices providenciam uma forma eficiente de fazer cumprir a integridade dos dados, garantindo a unicidade de valores chave, quando um índice único é criado.

Mas, afinal, o que é um índice?

Um índice corresponde a uma estrutura em disco, associada a uma  tabela ou view, que agiliza a pesquisa de linhas nessa tabela ou view.

Um índice contém chaves, construídas a partir de uma ou mais colunas da tabela ou view, que permitem ao SQL Server encontrar a linha ou linhas associadas aos valores das chaves, de forma rápida e eficiente. Por exemplo, numa tabela com informação pessoal, podemos criar um índice para a coluna do Número Contribuinte (NIF). Se efectuarmos uma pesquisa baseada num NIF, o SQL Server primeiro vai pesquisar o valor da chave no índice e, em seguida, vai usar o índice para localizar directamente a respectiva linha de dados, na tabela. Sem o índice, teria que se percorrer todas as linhas da tabela até se encontrar o NIF pretendido, o que costuma ter um impacto significativo na degradação do desempenho.

Podem-se criar índices para a maioria das colunas de uma tabela ou view. As excepções são, principalmente as colunas configuradas com tipos de dados de grandes objectos (BLOB e CLOB), como image, text e varchar(max). Também se podem criar índices em colunas do tipo XML, mas esses índices são um pouco diferentes e estão fora do âmbito deste artigo.

Estrutura de um Índice

Um índice é composto por um conjunto de páginas (nós) que são organizadas numa estrutura de Árvore-B. Esta estrutura é de natureza hierárquica, com o nó da raiz na parte superior da hierarquia e os nós de folha na parte inferior.

Quando é feita uma consulta sobre uma coluna indexada, o SQL Server começa no nó de raiz e navega, para baixo, através dos nós intermédios, sendo cada camada mais granular do que a anterior. O mecanismo de consulta continua para baixo, através dos nós de índice, até atingir o nível da folha. Por exemplo, se pesquisarmos o valor 123, numa coluna indexada, o mecanismo de consulta começa no nível da raiz e determina qual a página de referência no primeiro nível intermédio. Neste exemplo, a primeira página aponta para os valores 1-100 e a segunda página, para os valores 101-200, de modo que o mecanismo de consulta irá para a segunda página. O mecanismo continua e determina que deve ir para a terceira página no nível intermédio seguinte. Finalmente, o mecanismo de consulta navega até ao nó de folha que corresponde ao valor 123 (percurso a vermelho na imagem). O nó de folha contém toda a linha de dados ou apenas um ponteiro para essa linha, dependendo se o índice é clustered ou nonclustered.

Índices Clustered e Nonclustered

No SQL Server, existem dois tipos principais de índices: o Clustered e Nonclustered.

Clustered Index
Um índice Clustered armazena as linhas de dados de uma tabela ou view já ordenadas, com base na chave do índice. Com um índice clustered,  os dados são armazenados na própria estrutura do índice. Como fisicamente as linhas da tabela só podem ter uma ordem, apenas pode existir um índice clustered por tabela.

A única ocasião em que as linhas duma tabela são armazenadas de forma ordenada é quando a tabela tem um índice clustered. Neste caso temos uma tabela clustered (clustered table). Quando a tabela não é clustered, as linhas de dados são armazenadas numa estrutura desordenada chamada heap.

Nonclustered Index

Um índice noncluster é criado em separado da tabela. Fisicamente, as linhas dos dados são armazenadas na estrutura da tabela  (que pode ser clustered ou heap) e as linhas do índice são armazenadas numa estrutura de árvore-B separada.

Cada linha do índice contém o valor da chave e um localizador de linha. Este localizador aponta para a linha de dados da tabela, correspondente ao valor da chave do índice nonclusterd. Isto significa que o mecanismo de consulta necessita executar um passo adicional, de modo a obter realmente os dados.

As linhas do índice são armazenados na ordem dos valores da chave, mas as linhas de dados podem não ter qualquer ordem em particular, a menos que seja uma tabela clustered. Mesmo assim, é normal que a ordem dos dados na tabela não seja a mesma da ordem das chaves do índice nonclustered.

A estrutura do localizador de linha depende se ele aponta para uma tabela em cluster ou em heap. Se referenciar uma tabela clustered, o localizador de linha aponta para o valor da chave do índice clustered. Se referenciar uma tabela em heap, o localizador aponta directamente para a linha de dados.

Ao contrário dos índices clustered, podemos criar mais do que um índice nonclustered para a mesma tabela ou view. Para além de podermos criar vários índices noncluster, também podemos adicionar colunas ao índice (included columns). Isto significa que podemos armazenar, ao nível da folha, não só os valores das colunas indexadas, mas também os valores destas colunas incluídas. Isto permite realizar consultas completamente cobertas por índices e, por vezes, ultrapassar alguns dos limites impostos para as chaves dos índices.

Tipos de Índices

Para além de serem clustered e nonclustered, os índices podem ter características e configurações adicionais:

Índice Composto
Um índice cuja chave é composta, i.e., que contém mais que uma coluna. Ambos os índices clustered e nonclustered podem ser índices compostos. Existem limitações ao número e tamanho total das colunas que compõem a chave.

Índice Único (Unique)
Um índice que garante a singularidade de cada valor da chave indexada.

Se a chave do índice for simples (apenas uma coluna), então garante-se que o valor dessa coluna não se repete em nenhuma das linhas da tabela. Se a chave for composta, os valores de cada coluna individual podem-se repetir, mas cada combinação de valores das colunas da chave já não. Por exemplo, numa tabela que regista dados sobre um jogo de futebol, temos uma chave composta por duas colunas, uma com o tempo de jogo em minutos (0-90) e outra com o número de golos marcados (0-?). Podemos ter a seguinte sequência de dados da chave: (0,0) (5,0) (10,0) (11,1) (11,2), mas não podemos ter (0,0) (5,0) (10,0) (11,1) (11,2) (11,2).

Índice de Cobertura
Um tipo de índice que inclui todas as colunas que são necessárias para processar uma consulta particular. Por exemplo, a consulta pode devolver as colunas nome e apelido de uma tabela, com base no valor na coluna ContactId. Pode-se criar um índice de cobertura, que inclui todas as três colunas.

Limites dos Índices

Existem algumas limitações internas aos índices.

Tamanho da chave
O tamanho de uma chave de índice está limitado a um máximo de 900 bytes e 16 colunas. Este é definitivamente um limite e não um objetivo, pois quanto maior for a chave, mais páginas tem e mais profunda fica a árvore do índice. À medida que o número de páginas e a profundidade da árvore aumentam, menos eficiente se torna a utilização do índice. Índices maiores também usam mais espaço de armazenamento e podem resultar num uso menos eficiente de cache de dados do SQL Server.

Número de índices
Até ao SQL Server 2005 havia um limite de 250 índices por tabela, um cluster e 249 noncluster. A partir do SQL Server 2008, com a adição de índices filtrados, essa limitação foi aumentada para 1000, um cluster e 999 índices noncluster.

Qualquer destes limites é muito elevado e há poucos casos em que um sistema bem projectado se aproxime sequer deles. Existem duas razões para isso não acontecer:

• À medida que aumenta o número de índices também aumenta o tamanho total ocupado pela tabela (com todos os seus índices). Claro que os discos rígidos são baratos e abundam as soluções de armazenamento, mas o aumento do tamanho duma BD tem outros efeitos: as operações de manutenção (backups, restauros, verificações de consistência e reconstrução de índices) vão levar mais tempo, à medida que o tamanho da BD aumenta;
• Os índices têm que ser actualizados em sincronismo com as alterações dos dados. Quantos mais índices existirem numa tabela, mais os locais e maior o número de operações necessárias para actualizar. Se existirem 10 índices noncluster numa tabela, a inserção duma nova linha tem que ser feita em 11 locais (na tabela e em cada um desses índices).
  Nas BDs que são principalmente de leitura (de suporte à decisão, ou datawarehouses) isto pode ser aceitável. Mas nas BDs em que são frequentes as operações de alteração de dados - inserir, alterar, eliminar (sistemas OLTP), a sobrecarga imposta pela existência de muitos índices pode não ser aceitável.

Como o SQL Server usa os Índices

Vamos imaginar que queremos efectuar uma consulta sobre uma tabela, com um dado critério (p.ex. todas as linhas em que uma dada coluna tenha o valor ‘X’). Se a tabela não tiver um índice baseado na coluna selecionada, a única maneira de encontrar todas as ocorrências correspondentes ao critério dado, é ler a tabela inteira. Agora, se a tabela tiver um índice, o SQL Server acelera a localização de valores dentro desse índice de duas maneiras:

1. O índice é ordenado segundo as colunas da chave. Isto significa que uma vez encontrados todos os valores correspondentes ao critério, o resto da tabela pode ser ignorado. Isto é o mesmo que acontece numa lista telefónica: uma vez encontradas todas as entradas com um apelido em particular, o resto da lista pode ser ignorada, pois mais nenhuma correspondência é possível;
2. A estrutura da árvore do índice permite uma abordagem do tipo dividir-e-conquistar, para a localização de linhas, onde grandes partes da tabela são rapidamente excluídas da pesquisa. Isto está ilustrado na figura da Estrutura de um Índice, anterior.

Quando temos um índice numa tabela, existem 4 operações básica que o SQL Server pode executar sobre esse índice:

Scans (Varreduras)
Uma varredura de índice (index scan) é uma leitura completa de todas as páginas de folha do índice. Quando a varredura é feita num índice clustered, na realidade é uma varredura de toda a tabela (table scan).

Quando a varredura do índice é feita pelo mecanismo de consultas, é sempre uma leitura completa de todas as páginas de folha do índice, independentemente de todas as linhas serem retornadas ou não. Nunca é uma leitura parcial.

Uma varredura não envolve apenas a leitura dos níveis de folha do índice, as páginas de nível superior também são lidas durante a operação.

Seeks (Pesquisas)
Uma pesquisa de índice (index seek) é uma operação em que o SQL Server usa a estrutura árvore-B para localizar um valor específico, ou o início de um conjunto de valores. Para uma pesquisa de índice ser possível, deve haver um predicado (filtro pesquisável) especificado na consulta e um índice correspondente (ou parcialmente correspondente) a esse predicado. Nos próximos artigos desta série iremos examinar esta questão em maior detalhe.

A operação de pesquisa é executada a partir da página de raiz. A partir das linhas desta página, o mecanismo de consultas vai localizar a página do seguinte nível inferior do índice, que contém a primeira linha que está a ser pesquisada. O mecanismo vai, então, ler essa página. Se a página estiver no nível de folha do índice, a pesquisa termina aí. Se não é o nível de folha, então o mecanismo de consulta identifica novamente a página do nível inferior seguinte, que contém o valor especificado. Este processo continua até que o nível de folha seja atingido.

Quando o mecanismo de consultas localiza a página de folha que contém o valor de chave especificado, ou o início do intervalo especificado de valores-chave, vai lendo ao longo das páginas de folha até que todas as linhas correspondentes ao predicado sejam devolvidas. A figura seguinte mostra um exemplo de como uma pesquisa seria feita, num índice, para devolver as linhas com o valor 4 na chave:

Se o índice contém todas as colunas que necessita para a consulta, nas suas páginas de folha, então temos um índice de cobertura para essa consulta. Se o índice não contém todas as colunas requeridas, então o SQL Server vai fazer uma localização (lookup) na tabela base para obter as outras colunas, a fim de processar a consulta.

Lookups (Localizações)
Os lookups ocorrem quando o SQL Server usa um índice para localizar as linhas pedidas por uma consulta, mas esse índice não contém todas as colunas necessárias para satisfazer a consulta, ou seja, o índice não faz a cobertura dessa consulta. Para obter as colunas restantes, o SQL Server faz um lookup, quer numa tabela clustered, quer numa heap.

Um lookup numa tabela clustered é sempre uma pesquisa (seek) de uma única linha do índice clustered. Então, se for necessário fazer lookup a 500 linhas, isso significa 500 pesquisas individuais ao índice clustered.

Updates (Atualizações)
Sempre que uma linha for alterada, essas alterações devem ser feitas não só na tabela base (clustered ou heap), mas também em qualquer índice que contenha as colunas que foram afetadas pela alteração. Isso aplica-se às operações de INSERT, UPDATE e DELETE.

Considerações para a criação de Índices

Por mais benéfica que a utilização de índices possa ser, estes devem ser projectados com cuidado (já vimos anteriormente alguns dos problemas relacionados com a criação excessiva de índices). Como resultado, a criação de índices deve levar em conta algumas considerações:

• O tamanho da chave dum índice clustered deve ser pequeno, porque ela vai fazer parte de todos os índices nonclustered.
  O ideal é tentar implementar o índice clustered em colunas exclusivas (unique) e que não permitam valores nulos. É por isso que a Chave Primária é muitas vezes usada para o índice clustered da tabela, embora considerações sobre consultas também devam ser levadas em conta ao determinar quais colunas a usar no índice;
• Os índices noncluster compostos são geralmente mais úteis que os índices simples, a não ser que todas as consultas sobre a tabela sejam filtradas com uma coluna de cada vez;
• Para índices compostos, deve levar em consideração a ordem das colunas na definição do índice. As colunas que são usadas em expressões de comparação na cláusula WHERE (como WHERE Nome = 'Luis') devem ser as primeiras da lista. As colunas subsequentes devem ser ordenadas com base na singularidade dos seus valores, com a mais exclusiva incluída primeiro;
• Os índices não devem ser maiores do que o necessário. Demasiadas colunas no índice, desperdiça espaço de armazenamento e aumenta a quantidade de locais em que os dados têm que ser alterados quando ocorre um INSERT, UPDATE ou DELETE;
• Se um índice é único, deve-se especificar que ele é único. O optimizador pode usar essa informação para gerar planos de execução mais eficientes.
  A singularidade de valores duma coluna afecta o desempenho do índice. De um modo geral, quantos mais valores duplicados tiver uma coluna, pior o índice executa. Por outro lado, quanto mais exclusivo for cada valor, melhor é o desempenho. Sempre que possível, implementar índices únicos;
• Nas tabelas que são modificadas frequentemente, use o mínimo de colunas possível no índice, e não crie muitos índices, uma vez que vai retardar as operações de actualização de dados;
• Se uma tabela contém uma grande quantidade de dados, mas existem poucas modificações, deve usar tantos índices quanto o necessário, para melhorar o desempenho das consultas. No entanto, deve usar criteriosamente os índices nas tabelas pequenas, porque o mecanismo de consulta pode demorar mais tempo a navegar pelo índice do que executar uma varredura (scan) da tabela.

Outras considerações para a criação de índices é a forma como a BD vai ser consultada. Conforme mencionado acima, deve levar em conta a frequência das modificações de dados. Além disso, deve considerar o seguinte:

• Tente inserir ou modificar tantas linhas quanto possível numa única instrução, em vez de usar múltiplas consultas;
• Crie índices nonclustered para as colunas usadas com frequência nos predicados das suas instruções e nas condições de JOIN;
• Considere criar índices para colunas usados em consultas de correspondência exata.

Nos próximos artigos desta série vamos analisar em mais detalhe algumas destas considerações e recomendações.

Resumo

Neste artigo, tentámos dar uma visão geral sobre os conceitos e funcionamento dos índices no SQL Server e fornecer algumas das orientações que devem ser consideradas na criação e implementação dos índices. Isto é apenas uma pequena introdução ao tema, não pretendendo ser, de forma alguma, um trabalho completo e exaustivo sobre indexação em SQL Server.

O desenho e a implementação de índices são componentes importantes de qualquer projecto de BD no SQL Server. Nós próximos artigos desta série vamos desenvolver alguns dos conceitos introduzidos e ver exemplos concretos da utilização e manipulação dos índices.

Entretanto, recomenda-se a consulta dos SQL Server Books Online, para mais informações sobre os conceitos aqui descritos e considerações adicionais.

Referências

- "Introduction to Indexes", de Gail Shaw para a SQL Server Central

- "Stairway to SQL Server Indexes: Level 1, Introduction to Indexes", de David Durant para a SQL Server Central

- "SQL Server Index Basics", de Robert Sheldon para a Simple Talk

- "Indexes", na Microsoft Developer Network (MSDN)

- "SQL Server Index Design Guide", na Microsoft TechNet

- "Books Online for SQL Server", na Microsoft TechNet

Porque a Microsoft adora o Linux

Algumas coisas não ficam bem juntas: cães e gatos, fãs do Real Madrid e do Barcelona, Windows e Linux, ... ou não é?

Em São Francisco, o CEO da Microsoft, Satya Nadella disse, e citamos, "A Microsoft adora o Linux".

Uau!

Percorreu-se um longo caminho desde que Steve Ballmer proclamou, em 2001, que "o Linux é um cancro". Nos anos que se seguiram, a Microsoft realmente atacou o Linux como se fosse um cancro, fazendo de tudo para o exterminar, desde patrocinar o ataque da SCO aos direitos de copyright do Linux, afirmar que o Linux violava patentes sem nome da Microsoft, até intermináveis ataques FUD.

Então, como é que o Linux passou de inimigo número um da Microsoft para seu "amor"?

Na realidade, Nadella explicou o cerne da questão, que podemos resumir na abordagem clássica duma história de detectives: "basta seguir o dinheiro".

Nadella disse à revista Wired que não está interessado em prosseguir com velhas lutas, especialmente quando, goste-se ou não, o Linux se tornou uma parte vital da tecnologia de hoje. "Se não abraçar a novidade…", disse ele, “…não vai sobreviver".

Ao fim de 22 anos, não há nada de realmente novo no Linux. Mas duas coisas são novidade: em primeiro lugar, o futuro do lucro da Microsoft não recai agora nos desktops ou nos programas desktop, mas no Azure, a sua solução cloud e em programas baseados em cloud, como o Office 365. Em segundo lugar, o Linux, mesmo na cloud Azure, é usado tanto por grandes como pequenas empresas e organizações.

Na verdade, Nadella admitiu que 20 por cento dos sistemas operativos no Azure são Linux. O sistema operativo open-source já contribui muito para a linha base da Microsoft. Hoje, o Azure ainda não suporta as distribuições comerciais Linux de topo, como o Red Hat Enterprise Linux, mas já suporta CoreOS Linux, CentOS, Oracle Linux, SUSE e Ubuntu.

Ao mesmo tempo, a Microsoft está consciente de que o Azure é o único sistema de nuvem puramente proprietário, em funcionamento. Todos os seus concorrentes - Amazon Web Services, Google Compute, OpenStack, etc. – correm em Linux e oferecem serviços de servidor Linux. Tivesse a Microsoft insistido apenas na linha Windows ou na linha de mais alto desempenho e não teria hipóteses.

Não é só o Linux que a Microsoft ama. Depois de décadas de resistência, a Microsoft suporta uma variedade de programas de código aberto, como o Hadoop (big data), Docker ou o Projecto Open Comute da Facebook. Na verdade, a Microsoft está mesmo a a abrir as suas próprias tecnologias ao open-source, tais como partes da Framewrok .Net.

A Microsoft também faz dinheiro diretamente com o Linux. As suas patentes Android, por muito questionáveis​​ que possam ser, ainda proporcionam mil milhões de dólares de receita a mais que o Windows Phone.

Se esteve com atenção, deve ter reparado que a Microsoft começou a mudar a sua atitude anti-Linux há anos atrás.

Já em 2008, Sam Ramji, na altura diretor de Estratégia de Plataforma de Tecnologia, da Microsoft e do Open Source Software Lab da empresa, disse: "A estratégia de código aberto da Microsoft está focada em ajudar os seus clientes e parceiros a serem bem sucedidos no mundo de hoje, de tecnologia heterogénea".

Podia-se ter pensado que era apenas a Microsoft a lançar fumo. Mas, de seguida, a Microsoft começou a mostrar que não estava apenas a falar por falar quando se tratava de desenvolvimento open-source.

Em 2011, a Microsoft já era o quinto maior contribuinte de código para o kernel do Linux. O que é que eles estavam a fazer? A certificar-se que o Linux poderia trabalhar com a virtualização da Microsoft – o Hyper-V. E o Hyper-V está no coração de Azure.

Como se pode ver, a paixão da Microsoft não é tanto pelo Linux e pelos sistemas open-source em si. O facto é que, em 2014, o mundo está a deixar o velho paradigma de computação desktop/aplicação e a dirigir-se para para uma abordagem de dispositivo/ serviços de nuvem. A Microsoft dirigiu o antigo. No entanto, para continuar a ser um competidor no novo paradigma, a Microsoft já percebeu que necessita trabalhar e jogar bem com os outros. Sim, mesmo até com o Linux.

 

Tradução livre do artigo “Why Microsoft loves Linux”, de Steven J. Vaughan-Nichols, para a ZDNet.