Parte XXX

GT3.1 Organização lógica de dados

GT3.2 Bancos de dados comerciais

GT3.3 Queries em banco de dados

GT3.4 Normalização de banco de dados

GT3.5 Modelos de banco de dados

GT3.6 Gestão de banco de dados

GT3.7 Armazenamento baseado em IP, SANs e NAS

Guias de Tecnologia1 Hardware2 Software3 Dados e Bancos de Dados4 Telecomunicações5 Visão Técnica da Análise e Projeto de Sistemas

Guia de Tecnologia

3Dados e Bancos de Dados

GT3-2 Guias de Tecnologia

GT3.1 Organização lógica de dadosAssim como há muitas formas de estruturar organizações de negócio, existem também muitas formas de estruturar os dados dos quais essas organizações precisam. A capacidade de um gestor de usar um banco de dados é altamente dependente de como esse banco de dados está estruturado lógica e fisicamente. O sistema de gestão de banco de dados (database manage-ment system – DBMS) separa as visualizações lógica e física dos dados, o que significa que o programador e o usuário final não precisam saber onde e como os dados realmente estão armazenados. Na estruturação lógica do banco de dados, os negócios precisam levar em consi-deração as características dos dados e a forma como eles serão acessados.

Existem três modelos básicos para a estruturação lógica dos dados: o modelo hierárquico, o modelo em rede e o modelo relacional. Outros quatro modelos adicionais existentes são o multidimensional, o orientado a objeto, o small-footprint e o hipermídia (os três últimos são explicados na Seção GT3.5).

Usando esses modelos variados, os designers de bancos de dados podem construir vi-sualizações lógicas ou conceituais dos dados, que podem ser implementados fisicamente em quase todos os bancos de dados e com qualquer DBMS. Os DBMSs hierárquico, em rede e orientados a objetos normalmente relacionam os dados por meio de listas. DBMSs relacio-nais e multidimensionais interligam dados pelas informações contidas nos dados. Nesta seção, apresentamos os três modelos básicos de DBMSs.

A estrutura hierárquica foi desenvolvida porque as relações hierárquicas são encontradas com frequência em muitas organizações de negócio e processos tradicionais. Um exemplo desse tipo de estrutura de banco de dados é mostrado na Figura GT3.1.

Conforme a ilustração, o modelo hierárquico de banco de dados relaciona os dados estru-turando-os em uma “árvore” invertida, na qual os registros possuem dois elementos:

1. Uma única raiz ou campo-mestre, frequentemente chamado de chave, que identifica o tipo, a localização ou a ordem dos registros.

2. Um número variável de campos subordinados que definem o restante dos dados dentro de um registro.

De modo geral, embora todos os campos tenham apenas um “pai”, cada um pode ter muitos “filhos”.

As vantagens dessa abordagem são a velocidade e a eficiência de busca dos dados. Essa velocidade é obtida porque boa parte do banco de dados é eliminada na busca, com cada “vol-ta” para baixo na árvore. Conforme mostrado na Figura GT3.1, metade dos registros presen-tes no banco de dados (Vendas da Costa Leste) é eliminada quando a pesquisa é direcionada para Vendas da Costa Oeste, e dois terços das Vendas da Costa Oeste são eliminados quando a busca se volta para Taças.

Por fim, os relacionamentos explícitos de filhos/pais no modelo hierárquico significam que a integridade do banco de dados é mantida de forma rigorosa. Todo filho presente no banco de dados hierárquico deve ter um pai, e se um dos pais for eliminado do banco de dados, todos seus filhos se tornam automaticamente filhos dos pais dos pais deles. A abordagem hierárqui-ca, porém, tem algumas deficiências.

No modelo hierárquico, cada relação deve ser definida explicitamente na criação do ban-co de dados. Cada registro pode conter apenas um campo-chave e apenas uma relação é per-mitida entre os campos. Isso pode gerar problemas, porque dados do mundo real nem sem-

Vendas

Costa Oeste

Porcelana Taças

Costa Leste

Porcelana TaçasTalheres Talheres

Figura GT3.1 Modelo de banco de dados hie-rárquico.

3 • Dados e Bancos de Dados GT3-3

pre se adaptam a uma hierarquia tão rígida. Por exemplo, na matriz de uma organização, um funcionário pode se reportar a mais de um gerente, uma situação que seria estranha em uma estrutura hierárquica. Dessa forma, todas as buscas de dados devem ser originadas no topo da árvore, ou raiz, e seguir descendo.

Outra desvantagem significativa de modelos hierárquicos é o fato de ser difícil relacionar “primos” nas árvores. No exemplo mostrado na Figura GT3.1, não há um relacionamento direto entre as vendas de porcelana na Costa Leste e as vendas de porcelana na Costa Oeste. Uma comparação envolvendo todas as vendas de porcelana necessitariam de duas pesquisas separadas e, posteriormente, de outro passo para combinar os resultados da pesquisa.

O modelo de banco de dados em rede cria relacionamentos entre dados por meio de uma estru-tura em listas relacionada em que registros subordinados (chamados de membros, e não de fi-lhos) podem ser relacionados a mais de um pai (chamado de proprietário). De forma semelhan-te ao modelo hierárquico, o modelo em rede usa links explícitos, chamados de ponteiros, para as subordinadas e os subordinados a seus pais. Esse relacionamento é chamado de conjunto.

Fisicamente, os ponteiros são os endereços de armazenamento que contêm a localização de um registro relacionado. Com a abordagem do modelo em rede, um registro membro pode ser relacionado a um registro proprietário e, ao mesmo tempo, ele mesmo pode ser um regis-tro proprietário que está vinculado a outros conjuntos de membros (ver Figura GT3.2). Dessa forma, muitos relacionamentos podem ser estabelecidos no modelo em rede, uma vantagem bastante significativa quando comparado ao modelo hierárquico.

Faça uma comparação entre a Figura GT3.2 e a Figura GT3.1. Na Figura GT3.2, as in-formações sobre as vendas de porcelana, talheres e taças estão em um local subordinado ou membro. As informações sobre cada item têm dois pais ou proprietários, Costa Leste e Costa Oeste. O problema de obter um quadro geral do âmbito das vendas nacionais de porcelana que existe no modelo hierárquico não ocorre no modelo em rede. Além disso, as buscas pelos dados não começam pela raiz – pois pode não haver uma raiz única na rede –, o que dá uma flexibilidade muito maior para pesquisas de dados.

O modelo em rede não apresenta nenhuma restrição ao número de relações ou conjuntos com os quais um campo pode estar envolvido. Isso aproxima o modelo dos relacionamentos de negócio que acontecem no mundo real, onde, por exemplo, os fornecedores têm muitos clientes e os clientes têm muitos fornecedores. Entretanto, os bancos de dados em rede são muito complexos e, para cada conjunto, um par de ponteiros precisa ser mantido. Conforme o número de conjuntos ou relacionamentos vai aumentando, o custo de processamento de bus-cas vai se tornando cada vez maior. O modelo em rede é de longe o modelo de banco de dados mais complicado para planejar e implementar.

Embora a maioria das organizações de negócio tenha sido organizada de forma hierárquica, a maioria dos dados de negócio, especialmente os dados de contabilidade e financeiros, foi or-ganizada em tabelas de linhas e colunas. As tabelas permitem comparações rápidas por coluna ou linha, e os itens são facilmente recuperáveis localizando-se o ponto de intersecção entre uma linha específica e uma coluna. O modelo de banco de dados relacional é baseado nesse conceito simples de tabelas a fim de capitalizar características existentes nas linhas e colunas de dados, o que é consistente com as situações de negócio no mundo real.

Em um banco de dados relacional, as tabelas são chamadas de relações, e o modelo é ba-seado na teoria matemática de conjuntos e relações. Nesse modelo, cada linha de dados equi-

MODELO DE BANCO DE DADOS EM REDE

MODELO DE BANCO DE DADOS RELACIONAL

Vendas

Costa Oeste

Porcelana Taças

Costa Leste

Talheres

Figura GT3.2 Modelo de banco de dados em rede.

GT3-4 Guias de Tecnologia

vale a um registro, e cada coluna de dados equivale a um campo. Na terminologia do modelo relacional, uma linha é chamada de tupla, e a coluna é chamada de atributo. No entanto, um banco de dados relacional nem sempre é formado por uma grande tabela (normalmente cha-mada de arquivo simples) formada por todos os atributos e tuplas. Esse design provavelmente acarretaria maior redundância de dados. Em vez disso, um banco de dados é normalmente projetado como uma coleção de diversas tabelas relacionadas.

Existem alguns princípios básicos envolvidos na criação de um banco de dados relacional. Em primeiro lugar, a ordem das tuplas ou atributos na tabela é irrelevante, porque sua posição com relação a outras tuplas e atributos não importa para a busca por dados baseados em tuplas e atributos específicos. Em segundo lugar, cada tupla precisa ser identificada exclusivamente pelos dados presentes dentro dessa tupla – algum tipo de dado de chave primária (por exem-plo, um CIC ou número do funcionário). Em terceiro lugar, cada tabela precisa ter um iden-tificador único – o nome da relação. Em quarto lugar, não podem haver atributos ou tuplas duplicados. E, por fim, deve haver apenas um valor em cada célula da tabela.

Em um banco de dados relacional, três operações básicas são utilizadas para desenvolver conjuntos úteis de dados: seleção, junção e projeto (select, join, project). A operação de sele-ção cria um subconjunto com todos os registros dos arquivos que correspondem aos critérios estabelecidos. A operação estabelece, em outras palavras, um subconjunto de linhas que aten-dem a determinados critérios. A operação de junção combina as tabelas relacionais para dar ao usuário mais informações do que as que estão disponíveis em tabelas individuais. A ope-ração projeto cria um subconjunto de colunas na tabela, permitindo que o usuário crie novas tabelas que contenham apenas a informação solicitada.

As principais vantagens do modelo relacional são a simplicidade conceitual e a capaci-dade de relacionar registros de uma forma que não foi definida anteriormente (ou seja, não existem modelos em rede ou modelos hierárquicos previamente explicitados). Essa capaci-dade dá grande flexibilidade aos usuários, especialmente aos usuários finais.

O modelo relacional ou tabular de dados pode ser utilizado para uma série de aplicações. A maioria das pessoas pode visualizar facilmente o modelo relacional em forma de tabela, mas o modelo usa uma terminologia que não é familiar. Considere o exemplo de banco de dados relacional separado em Divisão, Cargo e Funcionário, mostrado na Figura GT3.3. As tabelas contêm dados sobre essas três entidades; os atributos ou características são código, nome, descrição, cargo, idade e código da divisão; as relações entre os dados e as tabelas entre as relações são implícitas. Eles não estão necessariamente relacionados fisicamente em um dispo-sitivo de armazenamento, mas estão relacionados implicitamente pelo Código da Divisão (01).

Essa propriedade das relações implícitas confere ao modelo relacional aquele que talvez seja seu mais forte benefício – a flexibilidade para relacionar os dados. Diferentemente dos modelos hierárquico e em rede, onde as relações são apenas aquelas construídas rigidamente durante o planejamento, todos os dados dentro da tabela e entre as tabelas podem ser relacio-nados, vinculados e comparados. Essa capacidade dá ao modelo relacional uma independência muito maior dos dados do que a apresentada pelos modelos em rede e hierárquico. Em outras palavras, o design lógico dos dados em tabelas pode ser mais independente da implementação física. Essa independência permite maior flexibilidade de implementação e modificação do modelo lógico. Naturalmente, como ocorre em todas as tabelas, o usuário final precisa conhe-cer apenas duas coisas: o identificador da tupla a ser pesquisado e o atributo desejado.

O modelo relacional tem algumas desvantagens: como os bancos de dados de larga escala são compostos por muitas tabelas relacionadas, o modelo geral pode ser complexo e, assim, ter um tempo de busca e de acesso mais lento (se comparado aos modelos em rede e hierárquico). A busca mais lenta e o tempo de acesso podem resultar em ineficiências de processamento, que levam a uma falta de aceitação inicial do modelo. Essas ineficiências de processamento, no entanto, são reduzidas continuamente por meio de modelos de bancos de dados aperfeiçoados e de programação. Além disso, a integridade dos dados não é parte inerente nesse modelo como nos modelos em rede e hierárquico. Portanto, a integridade dos dados precisa ser refor-çada com bons princípios de modelagem.

Código Nome

01 Taças

Divisão

Código Descrição

01 Diretor

Nome Código do Cargo

Smith, A. 01 01 42

Funcionário

Código da Divisão Idade

Cargo

Figura GT3.3 Tabelas do modelo de banco de dados relacional.

3 • Dados e Bancos de Dados GT3-5

A principal vantagem dos modelos de banco de dados hierárquico e em rede é a eficiência de processamento. As estruturas hierárquica e em rede são relativamente fáceis de compreender porque refletem o que é padrão nas relações de negócio do mundo real. Além disso, a estrutu-ra hierárquica permite que a integridade de dados seja facilmente mantida.

No entanto, estruturas hierárquicas e em rede têm diversas desvantagens. Todos os ca-minhos de acesso, diretórios e índices precisam ser especificados antecipadamente. Depois de especificados, não podem ser modificados sem que um grande esforço de programação seja feito, apresentando, assim, modelos de baixa flexibilidade. As estruturas hierárquica e em rede demandam esforços consideráveis e demorados para serem instaladas, e ainda são difíceis de consertar caso apresentem erros de modelagem. As duas estruturas não suportam buscas ad hoc, em linguagem natural.

As vantagens de um sistema de gestão de banco de dados relacional incluem a alta flexibi-lidade, por causa das consultas ad hoc, o poder de combinar informações de diferentes fontes, a simplicidade de modelagem e manutenção e a capacidade de acrescentar novos dados e registros sem atrapalhar aplicações existentes.

As desvantagens desse sistema incluem sua relativa baixa eficiência de processamento. Esses sistemas são mais lentos porque normalmente requerem muitos acessos aos dados ar-mazenados no disco a fim de executar os comandos de seleção, junção e projeto. Os sistemas relacionais não possuem o grande número de ponteiros que os sistemas hierárquicos apresen-tam, o que acelera a busca e a recuperação. Além disso, bancos de dados relacionais grandes podem ser projetados para apresentar algumas redundâncias de dados, a fim de tornar a re-cuperação de dados mais eficiente. O mesmo elemento de dados pode estar armazenado em múltiplas tabelas, e arranjos especiais são necessários para garantir que todas as cópias do mesmo elemento de dados sejam atualizadas ao mesmo tempo. A Tabela GT3.1 resume as vantagens e desvantagens comuns dos três modelos de bancos de dados, e a Figura GT3.4 é uma comparação dos três modelos.

Bancos de dados XML (Extensible Markup Language) podem armazenar documentos intei-ros em seu formato XML nativo. Um banco de dados desse tipo torna a pesquisa mais fácil, permitindo a busca por título, autor, palavras-chave, entre outras características. Os bancos de dados relacionais, por outro lado, ou convertem os documentos em dados relacionais (armaze-nados em tabelas) ou os tratam como grandes objetos binários (binary large objects – BLOBs), mas é difícil encontrar e recuperar a parte do BLOB que se deseja. Produtos de bancos de da-dos em XML incluem o Tamino XML da Software AG e o XML Database System da Ipedo. X Query é uma linguagem de busca usada nesses produtos, que podem pesquisar um grande conjunto de documentos baseados no nome de um autor, data de arquivamento, assunto ou palavras-chave no documento.

COMPARANDO OS MODELOS DE BANCOS DE DADOS

BANCOS DE DADOS XML

TABELA GT3.1 Vantagens e desvantagens de modelos de dados lógicos

Modelo Vantagens Desvantagens

Banco de dados hierárquico A busca é rápida e eficiente. O acesso aos dados é predefinido por rela-cionamentos exclusivamente hierárquicos, predeterminado pelo administrador. Fle-xibilidade de pesquisa/consulta limitada. Nem todos os dados são naturalmente hierárquicos.

Banco de dados em rede Muito mais relacionamentos podem ser definidos. Velocidade e eficiência maiores do que as apresentadas por modelos de banco de dados relacionais.

Esse é o modelo mais difícil de projetar, implementar e manter. Existe maior flexibi-lidade de consulta do que com o modelo hierárquico, porém menor flexibilidade do que com o relacional.

Banco de dados relacional Simplicidade conceitual; não existem rela-cionamentos predefinidos entre os dados. Alta flexibilidade em pesquisa ad hoc. Novos dados e registros podem ser acres-centados facilmente.

A eficiência e a velocidade de processamento são menores. A redundância de dados é co-mum, requerendo manutenção adicional.

GT3-6 Guias de Tecnologia

GT3.2 Bancos de dados comerciaisExiste uma série de bancos de dados comerciais. Os mais comuns, como os da Oracle, o SQL Server da Microsoft e o DB2 Server da IBM, incluem muitos recursos com os quais as pessoas vieram a contar para tornar seus servidores de bancos de dados “comercialmente respeitáveis”.

O Oracle Database 11g Enterprise Edition (oracle.com/database/) é o banco de dados comer-cial mais vendido pelas organizações para dar suporte ao alto volume de processamento de transações, busca intensiva de dados e operações de data warehouse.

O banco de dados escalável da Oracle é executado em todas as configurações de hardware capazes de administrar grandes quantidades de informação com alto índice de segurança. Os benefícios desse banco de dados são:

• Desempenho máximo e disponibilidade – monitora automaticamente todo o ambiente do banco de dados e resolve de forma proativa os problemas antes de se tornarem emer-gências.

• Produtividade elevada do administrador – dá aos administradores ferramentas das quais precisam para gerenciar mais bancos de dados.

• Falhas causadas por erro humano são eliminadas – aumenta o controle de ambientes de TI resolvendo a principal causa de inatividade não planejada por meio de automatização extensiva, configuração e mudança nas capacidades de gestão.

ORACLE 11G

NúmeroCliente

NomeCliente

8103045

GreenBrownBlackWhite

Green

M.1 S.1 T.1

Nut Bolt Washer

100 250 70

Registros de cliente

Produto

Nome

Quantidade

a. Relacional

b. Hierárquico

Registros de produto

NúmeroProduto

M.1S.1T.1U.1

NomeProduto

NutBoltWasherScrew

Campos

Registros

NomeCliente

GreenBrownGreenWhiteGreenBrownBrown

NúmeroProduto

M.1S.1T.1S.1S.1T.1U.1

Quantidade

103007030

25012050

Green

M.1 S.1 T.1

Nut Bolt Washer

100 550 190

Produto

Nome

Quantidade

c. Rede

Brown

T.1 S.1 U.1

Washer Bolt Screw

120 300 50

Brown

U.1

Screw

50

Figura GT3.4 Estruturas de banco de dados.

3 • Dados e Bancos de Dados GT3-7

O Oracle 11g é planejado para computação em grade com a finalidade de reduzir os cus-tos com infraestrutura por meio do uso de hardware compartilhado e capacidades de autoge-renciamento. O Oracle 11g pode ser executado em todos os sistemas operacionais, incluindo o Windows, o Linux e o UNIX, e suporta desde os menores até os maiores processadores.

O SQL Server da Microsoft é um banco de dados altamente escalável que pode ser executado em uma plataforma servidora do Microsoft OS. O SQL Server é uma plataforma de banco de dados abrangente que realiza gerenciamento de dados de classe corporativa com ferramentas integradas de business intelligence. Ele fornece os mais altos índices de segurança, confiabili-dade e escalabilidade para aplicações de negócio.

O SQL Server fornece integração perfeita com o Microsoft’s Data Platform, ajudando or-ganizações a administrarem qualquer dado, em qualquer lugar e a qualquer hora. Isso permite que empresas armazenem dados a partir de documentos estruturados, semiestruturados e não estruturados, como arquivos de imagens e música, diretamente dentro do banco de dados. O SQL Server disponibiliza um conjunto rico de serviços integrados que permite que usuários fa-çam várias coisas com seus dados, como query, busca, sincronização, relatório e análise. Dados podem ser armazenados e acessados nos maiores servidores dentro de um data center até os desktops e dispositivos móveis, permitindo que os usuários tenham controle sobre seus dados independentemente de onde estão armazenados.

O DB2 Universal Database (UDB) é um sistema de gestão de banco de dados da IBM que oferece uma plataforma flexível e econômica para construir aplicações de negócio robustas sob demanda. O DB2 UDB alavanca recursos com grande suporte para padrões abertos e de-senvolvimento de plataformas populares como a J2EE e a Microsoft .NET. A família do DB2 UDB também inclui soluções feitas sob medida para necessidades específicas, como business intelligence e ferramentas avançadas.

O DB2 tem funcionalidade para o formato XML ou pode ser diretamente armazenado em XML, em vez de em tabelas de dados relacionais. O DB2 V9.1 apresentou o primeiro ser-vidor de dados híbrido ao setor, servindo-se de dados de estruturas puramente relacionais ou puramente em XML. Essa tecnologia possibilitou aplicações de desempenho sem precedentes e economia de custo/tempo de desenvolvimento que tornaram os dados em XML efetivos pela primeira vez, permitindo grandes insights ao negócio, mais rápidos e com baixo custo.

O MySQL é um DBMS, multiencadeado e multiusuário, com mais de seis milhões de instalações. O MySQL AB torna o MySQL disponível como software livre sob a GNU General Public Licen-se (GPL), mas também é licenciado duplamente sob os contratos de licença para casos em que o uso pretendido é compatível ao uso em GPL. Antes de criar o MySQL, os desenvolvedores usa-ram o mSQL para se conectar ao próprio nível de estrutura de dados e descobriram que faltavam características e velocidade, então decidiram escrever seu próprio front-end. Assim começou a vida do MySQL como um produto. O MySQL funciona em muitas plataformas diferentes.

GT3.3 Queries em banco de dadosAs linguagens de consulta são linguagens de computador utilizadas para fazer buscas em ban-cos de dados e sistemas de informação. Essas linguagens podem ser classificadas como lingua-gens de consulta de banco de dados ou linguagens de consulta de recuperação de informação.

A linguagem SQL (Structured Query Language) é a linguagem de computador mais po-pular usada para criar, modificar, recuperar e manipular dados de DBMSs relacionais. A lin-guagem evoluiu para além de seu propósito original a fim de dar suporte a sistemas de gestão de banco de dados relacionais baseados em objetos. É um padrão ANSI/ISO.

Embora a ANSI e ISO definam a SQL, existem muitas extensões e variações na versão da linguagem definida por esses padrões. O código SQL raramente pode ser adaptado entre siste-mas de bancos de dados sem grandes modificações. Existem diversas razões para essa falta de portabilidade entre os sistemas de bancos de dados:

• A maioria dos bancos de dados não implementa o padrão SQL inteiro.

O SQL SERVER DA MICROSOFT

DB2 UNIVERSAL DATABASE DA IBM

MYSQL

FALTA DE PADRÃO SQL

GT3-8 Guias de Tecnologia

• O padrão SQL não especifica o comportamento do banco de dados em diversas áreas importantes (por exemplo, índices).

• A especificação de padrões SQL sobre a semântica de construções de linguagem é menos bem definida, levando a áreas de ambiguidade.

• A falta de compatibilidade entre os sistemas de banco de dados é intencional, a fim de garantir a dependência dos fornecedores.

As palavras-chave da linguagem SQL podem ser divididas em diversos grupos: recupe-ração de dados, transação de dados, manipulação de dados, definição de dados e controle de dados. Observamos aqui o uso da SQL para a recuperação de dados em um banco de dados.

A operação utilizada com maior frequência em bancos de dados transacionais é a recuperação de dados. Quando restrita a comandos de recuperação de dados, a SQL age como uma lingua-gem declarativa.

• O comando SELECT é usado para recuperar zero ou mais linhas de uma ou mais tabelas presentes no banco de dados.

• O comando FROM é usado para indicar de qual tabela os dados serão retirados, bem como a forma como as tabelas relacionam-se entre si com o uso do comando JOIN.

• O comando WHERE é usado para identificar quais linhas devem ser recuperadas ou aplicadas ao comando GROUP BY. O comando WHERE é avaliado antes do comando GROUP BY.

• O comando GROUP BY é usado para combinar linhas com valores relacionados em ele-mentos de conjuntos menores de linhas.

• O comando HAVING é usado para identificar quais das “linhas combinadas” (linhas combinadas são produzidas quando a consulta tem uma palavra-chave em GROUP BY ou quando SELECT contém agregados) devem ser recuperadas. O comando HAVING age de forma parecida com WHERE, mas opera nos resultados de GROUP BY e, portan-to, pode utilizar funções agregadas.

• O comando ORDER BY é usado para identificar quais colunas são usadas para classificar os dados resultantes.

Exemplo 1.SELECT * FROM cdsWHERE price . US$ 20ORDER BY artist

Esse é um exemplo que poderia ser usado para obter uma lista de CDs caros. Ele recupera registros da tabela CDs que têm um campo preço maior de US$ 20. O resultado é ordenado alfabeticamente por artista. O asterisco (*) significa mostrar todas as colunas da tabela CDs. Como alternativa, colunas específicas poderiam ser nomeadas.

Exemplo 2.SELECT cds.title, count(*) AS artistFROM cdsINNER JOIN artist ON cds.cdnumber 5 cdartist.cdnumberGROUP BY cds.title

O exemplo 2 mostra o uso de múltiplas tabelas em uma junção e uma agregação (agrupamen-to). Esse exemplo mostra quantos artistas há por CD.

Manipulação de dados. Primeiro existem os elementos da linguagem de manipulação de dados padrão – Data Manipulation Language (DML). A DML é o subconjunto da linguagem utilizada para adicionar, atualizar e excluir dados.

• O comando INSERT é usado para acrescentar zero ou mais linhas (formalmente tuplas) a uma tabela existente.

• O comando UPDATE é usado para modificar os valores de um conjunto de linhas de tabelas existentes.

• O comando MERGE é usado para combinar os dados de múltiplas tabelas. É algo como uma combinação dos elementos INSERT e UPDATE.

RECUPERAÇÃO DE DADOS

OUTROS USOS DE SQL

3 • Dados e Bancos de Dados GT3-9

• O comando TRUNCATE deleta todos os dados de uma tabela (não padrão, mas um comando SQL comum).

• O comando DELETE remove zero ou mais linhas existentes na tabela.

Transação de dados. A transação, se disponível, pode ser usada para contornar as operações de DML.

• O comando START TRANSACTION (ou BEGIN WORK, dependendo do dialeto da SQL) pode ser usado para marcar o começo de uma transação em um banco de dados, que é efetuada por inteiro ou não.

• O comando COMMIT faz com que todas as alterações nas transações se tornem perma-nentes.

• O comando ROLLBACK faz com que todas as alterações nos dados, desde o último COMMIT ou ROLLBACK, sejam descartadas, de modo que o estado dos dados retor-nam para a forma anterior às mudanças solicitadas.

Definição de dados. O segundo grupo de palavras-chave é a linguagem de definição de da-dos – Data Definition Language (DDL). A DDL permite que o usuário defina novas tabelas e elementos associados. A maioria dos bancos de dados SQL comerciais possui extensões pro-prietárias em sua DLL, o que permite o controle de características não padrão presentes no sistema de banco de dados. Os itens mais básicos da DLL são os comandos CREATE e DROP:

• O comando CREATE faz com que um objeto (uma tabela, por exemplo) seja criado den-tro do banco de dados.

• O comando DROP faz com que um objeto existente dentro de um banco de dados seja excluído de modo irrecuperável.

Controle de dados. O terceiro grupo de palavras-chave de SQL faz parte da linguagem de controle de dados – Data Control Language (DCL). A DCL lida com aspectos de autorização de dados e permite que o usuário controle quem pode visualizar ou manipular os dados dentro de um banco de dados.

• O comando GRANT autoriza um ou mais usuários a desempenhar uma operação ou um conjunto de operações em um objeto.

• O comando REVOKE remove ou restringe a capacidade de um usuário de desempenhar uma ou um conjunto de operações.

GT3.4 Normalização de banco de dadosEm bancos de dados relacionais, a normalização é a reestruturação dos campos e das tabelas do banco de dados. Isso elimina a redundância, organiza os dados de forma eficiente, reduz o potencial de anomalias durante operações com dados e melhora a consistência dos dados.

Um banco de dados não normalizado pode sofrer com algumas anomalias de dados:

• O banco de dados não normalizado pode armazenar dados que representam uma referên-cia particular em múltiplas localizações, chamado de anomalia de atualização, produzindo dados inconsistentes.

• O banco de dados não normalizado pode ter dependências inapropriadas (por exemplo, relacionamentos entre dados sem dependências funcionais). Acrescentar dados a um ban-co de dados desse tipo pode requerer primeiramente acrescentar dependências não rela-cionadas, o que é chamado de anomalias de inserção.

• De forma semelhante, tais dependências em bancos de dados não normalizados podem dificultar o processo de remoção, o que é chamado de anomalias de exclusão.

• Um banco de dados não normalizado pode sofrer de problemas de integridade inferen-cial, em que os dados não podem ser acrescentados a múltiplas tabelas simultaneamente.

Bancos de dados normalizados têm um modelo que reflete as verdadeiras dependências entre quantidades monitoradas, permitindo atualizações rápidas de dados com risco pequeno de introdução de inconsistências. Em vez de tentar amontoar toda a informação em uma tabela, os dados são espalhados logicamente em diferentes tabelas. Normalizar os dados é decompor

GT3-10 Guias de Tecnologia

uma única relação em um conjunto de relações menores que lidem com os limites impostos pela relação original. A redundância pode ser solucionada decompondo tabelas, entretanto, novos problemas podem surgir com essa decomposição. A normalização nos ajuda a tomar decisões conscientes evitando a redundância, levando sempre os prós e os contras em consideração.

Muitos níveis de normalização existem, os quais se baseiam uns nos outros, criando cada vez mais problemas específicos e complexos de normalização. A Tabela GT3.2 mostra as dife-rentes formas normais e suas características.

TABELA GT3.2 Formas normais

Forma normal Características

Primeira forma normal (1FN) – todos os campos devem conter apenas valores únicos, derivados do modelo de dados.

Garante que cada tabela tenha uma chave primária – um conjunto mínimo de atributos que possa identificar exclusivamente um registro.

Cada atributo deve conter um único valor, não um conjunto de valores.Elimina grupos de repetição (categorias de dados que parecem ser necessá-

rios um número diferente de vezes em registros distintos) por meio da defini-ção de atributos-chave e atributos não chaves.

Segunda forma normal (2FN) – requer que parte da chave primária não possa determinar um campo não chave.

O banco de dados precisa atender a todos os requisitos da primeira forma normal.

Dados armazenados em uma tabela com chave primária composta não devem ser dependentes apenas da parte da chave primária da tabela.

Os dados redundantes duplicados em múltiplas linhas de uma tabela são mo-vidos para uma tabela separada.

Terceira forma normal (3FN) – requer que um campo não chave não possa determi-nar outro campo não chave.

O banco de dados deve atender a todos os requisitos da segunda forma nor-mal.

Os dados armazenados em uma tabela devem ser dependentes apenas da chave primária, e não de qualquer outro campo da tabela.

Qualquer campo que seja dependente não apenas da chave primária, mas também de outro campo, é movido para uma tabela separada.

GT3.5 Modelos de banco de dadosMuitas aplicações hoje requerem bancos de dados capazes de armazenar, recuperar e proces-sar diversas mídias, não apenas texto e números. Vídeos, voz, fotos e desenhos não podem ser manuseados efetivamente ou eficientemente por bancos de dados hierárquicos, em rede ou relacionais e pelo DBMS. Para multimídia e outros dados complexos, são usados modelos de banco de dados especiais.

Os modelos desse tipo de banco de dados mais comuns são os seguintes:

• Banco de dados multidimensional. Esse é um banco de dados adicional que permite aos usuários finais recuperar e apresentar dados complexos que envolvem muitas dimensões rapidamente.

• Banco de dados dedutivo. DBMSs relacionais, hierárquicos e em rede tem sido usados por décadas para facilitar o acesso dos usuários aos dados. Os usuários, é claro, devem en-tender o que estão procurando e pelo menos conhecer um pouco da informação a ser bus-cada (como uma chave ou algum campo ou atributo sobre um registro). Essa abordagem, entretanto, pode não ser adequada para algumas aplicações baseadas em conhecimento que requerem método dedutivo para fazer as buscas. Como resultado, existe interesse no que chamamos de sistemas de banco de dados dedutivos.

• Bancos de dados de multimídia e hipermídia. Esses bancos de dados são análogos aos dados numéricos e textuais; no entanto, foram adaptados para atender aos requisitos es-peciais de lidar com diferentes tipos de materiais de mídia.

• Bancos de dados small-footprint. Esse tipo de banco de dados permite que as organiza-ções coloquem determinados tipos de dados no campo onde os trabalhadores estão loca-lizados. Enquanto laptops no passado eram as únicas máquinas portáteis capazes de exe-cutar um banco de dados, os avanços tecnológicos (por exemplo, CPUs mais poderosas e

3 • Dados e Bancos de Dados GT3-11

memórias melhoradas com baixo custo) estão criando dispositivos de mão e smartphones capazes de executar algumas formas de banco de dados SQL e de sincronizar esse banco de dados móvel com um banco de dados central localizado na empresa. O nome vem do fato de que as ferramentas que executam esses banco de dados (por exemplo, Access) são pequenas e que, assim, não usam muito espaço da memória.

Bancos de dados têm mecanismos de replicação que levam em conta a natureza da co-nexão ocasional dos laptops e dos dispositivos de mão, que são programados para resolver conflitos de replicação entre usuários móveis e que garantam que a sincronização de dados irá sobreviver a conexões de baixa qualidade sem fio ou através de modem. A tecnologia dos bancos de dados small-footprint também é executada em PDAs (como aqueles da Palm ou da Psion) e podem ser carregados em dispositivos e aplicações especializadas – como leitores de código de barras ou ferramentas médicas.

GT3.6 Gestão de banco de dadosA gestão de banco de dados, além de considerações puramente técnicas de hardware e de software, consiste principalmente de duas funções: modelagem e implementação do banco de dados e administração do banco de dados.

Ao fazer a modelagem e implementar do banco de dados, especialistas deveriam considerar cuidadosamente as necessidades de todos os usuários existentes e potenciais a fim de fazer o mo-delo e implementação de um banco de dados que otimize a eficiência de processamento e a efi-cácia desses usuários. O processo normalmente começa pela análise de quais informações cada usuário (ou grupo de usuários) precisa e então passa para a produção de visualizações lógicas de cada um deles. Essas visualizações lógicas são analisadas como um todo, a fim de encontrar similaridades que possam levar a uma simplificação, e então são relacionadas para que um único banco de dados coeso possa ser formado a partir de todas as partes. Esse banco de dados lógico é implementado por meio de um DBMS específico, em um sistema de hardware específico.

Os administradores do banco de dados são especialistas em TI responsáveis pelos dados; eles também devem assegurar que o banco de dados cumpra com as necessidades apresenta-das pelos usuários em termos de funcionalidade. No entanto, as necessidades dos usuários, como dos negócios em geral, não são constantes. Havendo mudanças no ambiente de negó-cios, os objetivos e as estruturas organizacionais reagem a essas alterações, e o banco de dados do qual a empresa depende também precisa mudar para continuar sendo eficiente. O hard-ware de computador no qual o software de DBMS está instalado precisa ser alterado a fim de acompanhar as mudanças ocorridas nos ambientes ou para obter uma vantagem por meio da nova tecnologia. Isso tudo traz limitações e/ou novas oportunidades de processamento de desempenho a um DBMS.

Além disso, os administradores do banco de dados precisam garantir sua confiabilidade, gerindo diariamente operações, incluindo o planejamento de contingências de emergências e fornecendo backup de dados e sistemas que garantam perda mínima de dados em caso de desastre. A segurança é sempre uma preocupação da gestão de dados. Quando existem múl-tiplos acessos aos bancos de dados que contêm todos os dados corporativos, é papel dos ad-ministradores estabelecer um equilíbrio entre as vantagens de negócio do acesso disseminado e a ameaça de espionagem corporativa, sabotagem de funcionários insatisfeitos e prejuízo ao banco de dados devido à negligência.

Os administradores de bancos de dados também desempenham um papel importante no treinamento dos usuários para os quais os dados estão disponíveis. Por fim, os administradores são responsáveis por garantir que os dados contidos em um banco de dados sejam acurados, confiáveis, verificáveis, completos, atualizados e relevantes – uma tarefa no mínimo intimi-dadora. Se não for assim, decisões brilhantes de negócio baseadas em informações erradas podem ser desastrosas em um mercado que é extremamente competitivo.

Um dos elementos do planejamento de contingência é o backup de dados, que é de funda-mental importância para qualquer usuário de TI. Fitas e disquetes são mídias populares utili-zadas para fazer o backup de dados, especialmente porque são baratas. Existem dois métodos principais de backup: o backup completo e o incremental. O backup completo mantém uma duplicação do banco de dados inteiro; o backup incremental mantém apenas dados adicionais ou que foram atualizados a cada vez que o banco de dados passou por backup. O método de

GT3-12 Guias de Tecnologia

backup incremental é mais eficiente porque é feito em menos tempo, porém não é tão seguro quanto o backup completo, já que a perda de qualquer mídia pode impossibilitar o processo de recuperação.

GT3.7 Armazenamento baseado em IP, SANs e NASO armazenamento conectado a servidores sobre redes de IP (Internet Protocol), também co-nhecido como armazenamento de IP, permite que servidores se conectem a dispositivos de ar-mazenamento SCSI (small computer system interface) como se estivessem diretamente ligados a um servidor, independentemente de suas localizações. O armazenamento de IP é um meca-nismo de transporte que busca resolver o problema de envio de dados para armazenamento em uma rede regular no formato de bloco, em vez de no formato de arquivo geralmente utilizado. O armazenamento IP pode economizar dinheiro permitindo que a empresa use infraestrutura de rede já existente para esse armazenamento. É preciso descrever o que o armazenamento de IP tenta substituir para compreender porque ele é considerado um aprimoramento.

Tradicionalmente, as tarefas de gestão de dados são manipuladas por fita ou disco dire-tamente ligados a cada servidor presente em uma rede, chamados de direct attached storage (DAS). Os dispositivos de armazenamento de rede são otimizados para tarefas de gestão de dados.

Esses dispositivos são ligados à rede corporativa e podem ser acessados a partir de aplica-ções em rede. No entanto, enviar dados para armazenamento na rede de uma empresa podem diminuir drasticamente a velocidade dessa rede, o que afetará o acesso ao e-mail e à Internet. As empresas precisaram transmitir muitos de seus DAS para armazenamento em rede.

O network attached storage (NAS) é uma arquitetura de armazenamento em rede baseado em IP e Ethernet, substituindo o propósito geral de um servidor de arquivos por um servidor executando um sistema operacional customizado que otimiza a gestão e o processamento dos dados. O sistema operacional otimizado melhora o desempenho do servidor de arquivos e dá suporte a recursos de RAID, cache, clustering, entre outros.

Uma área de armazenamento em rede – storage area network (SAN) pode resolver pro-blemas existentes no envio de dados para armazenamento em redes regulares por meio da construção de uma rede separada, dedicada e de alta velocidade voltada apenas para dispo-sitivos de armazenamento, servidores e sistemas de backup. Essa rede é capaz de lidar com demandas pesadas de armazenamento de dados e segrega o tráfego de armazenamento a uma rede construída especificamente para esses fins. A comunicação entre o servidor e os dispositi-vos de armazenamento é feita por meio de protocolo SCSI-3 de baixo nível. A tecnologia SAN é implementada usando ou uma conexão direta ponto a ponto, ou uma rede própria ligada a um storage de armazenamento de dados. É cara e complicada de construir, além de requerer uma equipe especialmente treinada. A tecnologia também faz uso de hardware relativamente caro que pode ser incompatível entre vários servidores. Veja a Tabela GT3.3.

TABELA GT3.3 Prós e Contras do SANs e NAS

Prós Contras

SANs Faz offload do tráfego de armazenamento a par-tir de uma rede existente

Caro – requer nova sub-rede

O modelo flexível aprimora a confiabilidade Gerencia dados em blocos, não em arquivos; portanto, requer software especializado

O equipamento é projetado para ser altamente expansível

Requer habilidades em sistemas de rede de canal de fibra

NAS Usa infraestrutura de rede existente Mais lento – protocolos de rede não são eficientes para o armazenamento

Gerencia dados como arquivos Carrega redes já carregadas com dados armazenados, incluindo backup

Fácil de instalar e usar Não é facilmente expansível