PrincíPios de Banco de dados - UNIASSELVI

2013

PrincíPios de Banco de dados

Prof. Décio LehmkuhlProf. Djayson Roberto Eger

Copyright © UNIASSELVI 2013

Elaboração:

Prof. Décio Lehmkuhl

Prof. Djayson Roberto Eger

Revisão, Diagramação e Produção:

Centro Universitário Leonardo da Vinci – UNIASSELVI

Ficha catalográfica elaborada na fonte pela Biblioteca Dante Alighieri

UNIASSELVI – Indaial.

005.75L523p Lehmkuhl, Décio Princípios de banco de dados / Décio Lehmkuhl; Djayson Roberto. Indaial : Uniasselvi, 2013. 189 p. : il ISBN 978-85-7830- 684-7

1. Banco de dados. I. Centro Universitário Leonardo da Vinci.

Impresso por:

III

aPresentação

Atualmente existem vários bancos de dados no mundo. Você já parou para pensar qual é a sua relação com os mesmos ou qual é a importância deles para a sociedade? Vamos relacionar alguns fatos para evidenciar uma possível resposta a este questionamento.

A sociedade vive em torno de dados. Sua conta de energia elétrica, água, telefone e várias outras possuem dados relacionados que formam o valor a ser pago na fatura. Cada fornecedor desses serviços tem em sua base de dados o seu cadastro e o consumo que foi utilizado. Logo, pode-se concluir que o seu cadastro possivelmente existe em inúmeros bancos de dados.

Pense em um documento pessoal, por exemplo, o seu CPF. Ele deve constar na base de dados da Receita Federal. Se você comprou algum produto em estabelecimento comercial, o seu CPF provavelmente existe na base de dados dele. Como foi mencionado acima, existe uma grande “ligação” entre você e vários bancos de dados.

Isso pode tornar o conteúdo desta disciplina muito interessante. Serão abordados vários assuntos que vão desde as primeiras formas de armazenamento de dados até o estado atual de evolução da tecnologia. Você aprenderá quais são os conceitos de bancos de dados e até poderá programar a sua própria base de dados.

Sendo assim, temos muito para aprender! Bons estudos!

Prof. Décio Lehmkuhl Prof. Djayson Roberto Eger

IV

Você já me conhece das outras disciplinas? Não? É calouro? Enfim, tanto para você que está chegando agora à UNIASSELVI quanto para você que já é veterano, há novidades em nosso material.

Na Educação a Distância, o livro impresso, entregue a todos os acadêmicos desde 2005, é o material base da disciplina. A partir de 2017, nossos livros estão de visual novo, com um formato mais prático, que cabe na bolsa e facilita a leitura.

O conteúdo continua na íntegra, mas a estrutura interna foi aperfeiçoada com nova diagramação no texto, aproveitando ao máximo o espaço da página, o que também contribui para diminuir a extração de árvores para produção de folhas de papel, por exemplo.

Assim, a UNIASSELVI, preocupando-se com o impacto de nossas ações sobre o ambiente, apresenta também este livro no formato digital. Assim, você, acadêmico, tem a possibilidade de estudá-lo com versatilidade nas telas do celular, tablet ou computador. Eu mesmo, UNI, ganhei um novo layout, você me verá frequentemente e surgirei para apresentar dicas de vídeos e outras fontes de conhecimento que complementam o assunto em questão.

Todos esses ajustes foram pensados a partir de relatos que recebemos nas pesquisas institucionais sobre os materiais impressos, para que você, nossa maior prioridade, possa continuar seus estudos com um material de qualidade.

Aproveito o momento para convidá-lo para um bate-papo sobre o Exame Nacional de Desempenho de Estudantes – ENADE. Bons estudos!

UNI

Olá acadêmico! Para melhorar a qualidade dos materiais ofertados a você e dinamizar ainda mais os seus estudos, a Uniasselvi disponibiliza materiais que possuem o código QR Code, que é um código que permite que você acesse um conteúdo interativo relacionado ao tema que você está estudando. Para utilizar essa ferramenta, acesse as lojas de aplicativos e baixe um leitor de QR Code. Depois, é só aproveitar mais essa facilidade para aprimorar seus estudos!

UNI

VII

UNIDADE 1 – FUNDAMENTOS DE BANCO DE DADOS .......................................................... 1

TÓPICO 1 – INTRODUÇÃO A BANCO DE DADOS .................................................................... 31 INTRODUÇÃO .................................................................................................................................... 32 CONCEITOS DE BANCO DE DADOS .......................................................................................... 4

2.1 DADO E INFORMAÇÃO .............................................................................................................. 42.2 BANCOS DE DADOS .................................................................................................................... 6

3 HISTÓRICO DO GERENCIAMENTO DOS DADOS ................................................................. 84 SISTEMA GERENCIADOR DE BANCO DE DADOS ................................................................ 11

4.1 DEFINIÇÕES DE UM SGBD ......................................................................................................... 114.2 FUNÇÕES DE UM SGBD .............................................................................................................. 134.3 ESTRUTURA DE UM SGBD ......................................................................................................... 144.4 TIPOS DE USUÁRIOS DO SGBD ................................................................................................. 16

5 PRINCIPAIS BANCOS DE DADOS DISPONÍVEIS NO MERCADO .................................... 165.1 MYSQL ............................................................................................................................................. 165.2 ORACLE ........................................................................................................................................... 175.3 POSTGRESQL ................................................................................................................................. 185.4 SQL SERVER .................................................................................................................................... 20

LEITURA COMPLEMENTAR .............................................................................................................. 22RESUMO DO TÓPICO 1 ....................................................................................................................... 24AUTOATIVIDADE ................................................................................................................................ 25

TÓPICO 2 – EVOLUÇÃO DOS BANCOS DE DADOS ................................................................. 271 INTRODUÇÃO .................................................................................................................................... 272 HISTÓRICO DA EVOLUÇÃO DOS BANCOS DE DADOS ..................................................... 28

2.1 PRIMEIRA GERAÇÃO .................................................................................................................. 282.2 SEGUNDA GERAÇÃO .................................................................................................................. 302.3 TERCEIRA GERAÇÃO .................................................................................................................. 32

3 ARQUITETURA DE BANCO DE DADOS ..................................................................................... 353.1 ARQUITETURA CENTRALIZADA ............................................................................................ 353.2 ARQUITETURA CLIENTE-SERVIDOR ...................................................................................... 363.3 ARQUITETURA PARALELA ....................................................................................................... 373.4 ARQUITETURA DISTRIBUÍDA ................................................................................................... 38


TÓPICO 3 – TENDÊNCIAS E PERSPECTIVAS ............................................................................... 451 INTRODUÇÃO .................................................................................................................................... 452 CLASSIFICAÇÃO DOS BANCOS DE DADOS .......................................................................... 46

2.1 BANCOS DE DADOS DE INFORMAÇÕES GEOGRÁFICAS ................................................. 462.2 BANCOS DE DADOS MULTIMÍDIA .......................................................................................... 492.3 BANCO DE DADOS TEMPORAL ............................................................................................... 502.4 BANCOS DE DADOS BIOLÓGICOS .......................................................................................... 51

sumário

VIII

2.5 BANCO DE DADOS XML ............................................................................................................. 533 TIPOS DE GERENCIAMENTO DE DADOS ................................................................................ 54

3.1 DATA MINING ................................................................................................................................ 553.2 DATA WAREHOUSE ...................................................................................................................... 583.3 DATA MART .................................................................................................................................... 603.4 DATA MARKETING ....................................................................................................................... 60

4 NOVOS CONCEITOS ........................................................................................................................ 614.1 BIG DATA ......................................................................................................................................... 624.2 NOSQL ............................................................................................................................................. 64


UNIDADE 2 – MODELAGEM DE DADOS ...................................................................................... 71

TÓPICO 1 – MODELOS DE DADOS ................................................................................................. 731 INTRODUÇÃO .................................................................................................................................... 732 MODELO CONCEITUAL .................................................................................................................. 743 MODELO LÓGICO ............................................................................................................................. 754 MODELO FÍSICO ................................................................................................................................ 75LEITURA COMPLEMENTAR .............................................................................................................. 77RESUMO DO TÓPICO 1 ....................................................................................................................... 80AUTOATIVIDADE ................................................................................................................................ 81

TÓPICO 2 – MODELO ENTIDADE-RELACIONAMENTO ......................................................... 831 INTRODUÇÃO .................................................................................................................................... 832 MODELO ENTIDADE-RELACIONAMENTO ............................................................................. 83

2.1 ENTIDADE ...................................................................................................................................... 852.2 ATRIBUTOS ..................................................................................................................................... 862.3 RELACIONAMENTO .................................................................................................................... 87

3 CONSTRUINDO UM MODELO ENTIDADE-RELACIONAMENTO .................................... 88LEITURA COMPLEMENTAR .............................................................................................................. 90RESUMO DO TÓPICO 2 ....................................................................................................................... 91AUTOATIVIDADE ................................................................................................................................ 92

TÓPICO 3 – TIPOS DE RELACIONAMENTOS .............................................................................. 931 INTRODUÇÃO .................................................................................................................................... 932 CONDICIONALIDADE DO RELACIONAMENTO ................................................................... 933 GRAU DO RELACIONAMENTO .................................................................................................... 95

3.1 RELACIONAMENTO UM PARA UM ........................................................................................ 953.2 GRAU UM PARA MUITOS ........................................................................................................... 963.3 GRAU MUITOS PARA MUITOS .................................................................................................. 96

4 AUTORRELACIONAMENTO .......................................................................................................... 97RESUMO DO TÓPICO 3 ....................................................................................................................... 99AUTOATIVIDADE ................................................................................................................................ 100

TÓPICO 4 – MODELO RELACIONAL .............................................................................................. 1011 INTRODUÇÃO .................................................................................................................................... 1012 BANCO DE DADOS RELACIONAL .............................................................................................. 1013 TABELA ................................................................................................................................................. 1014 CHAVE ................................................................................................................................................... 102

4.1 CHAVE PRIMÁRIA ........................................................................................................................ 1024.2 CHAVE ESTRANGEIRA ............................................................................................................... 103

IX

4.3 CHAVE ALTERNATIVA ................................................................................................................ 105LEITURA COMPLEMENTAR .............................................................................................................. 106RESUMO DO TÓPICO 4 ....................................................................................................................... 108AUTOATIVIDADE ................................................................................................................................ 109

TÓPICO 5 – NORMALIZAÇÃO DE DADOS .................................................................................. 1111 INTRODUÇÃO .................................................................................................................................... 1112 ANOMALIAS DE ATUALIZAÇÃO ................................................................................................. 1133 APLICAÇÃO DAS FORMAS NORMALIZAÇÃO ....................................................................... 1154 FERRAMENTAS PARA MODELAGEM DE DADOS ................................................................. 117

4.1 DBDESIGNER ................................................................................................................................. 1174.2 ERWIN .............................................................................................................................................. 1184.3 POWERDESIGNER ........................................................................................................................ 119

RESUMO DO TÓPICO 5 ....................................................................................................................... 121AUTOATIVIDADE ................................................................................................................................ 122

UNIDADE 3 – SQL ................................................................................................................................. 123

TÓPICO 1 – INTRODUÇÃO À LINGUAGEM SQL ....................................................................... 1251 INTRODUÇÃO .................................................................................................................................... 1252 O QUE É SQL ........................................................................................................................................ 1263 MODELO DE DADOS DESTA UNIDADE .................................................................................... 1264 CRIANDO O BANCO DE DADOS ................................................................................................. 127

4.1 CONEXÃO AO BANCO DE DADOS .......................................................................................... 1284.2 CRIAÇÃO DE TABELAS ............................................................................................................... 129

5 RESTRIÇÕES ........................................................................................................................................ 1365.1 CHAVE PRIMÁRIA E RESTRIÇÃO NOT NULL ...................................................................... 1365.2 CHAVE ESTRANGEIRA ............................................................................................................... 1385.3 CHAVE ÚNICA .............................................................................................................................. 1395.4 CHECAGEM DE DADOS .............................................................................................................. 140


TÓPICO 2 – MANUTENÇÃO DOS DADOS ................................................................................... 1471 INTRODUÇÃO .................................................................................................................................... 1472 INSERINDO, SELECIONANDO, ATUALIZANDO E DELETANDO DADOS ..................... 147

2.1 VALIDANDO AS RESTRIÇÕES DA TABELA ........................................................................... 1472.2 TRANSAÇÕES ................................................................................................................................ 1522.3 CONVERSÃO DE DADOS ............................................................................................................ 1522.4 COMANDOS UPDATE E DELETE .............................................................................................. 154

3 SELEÇÃO DE DADOS ....................................................................................................................... 156LEITURA COMPLEMENTAR .............................................................................................................. 164RESUMO DO TÓPICO 2 ....................................................................................................................... 166AUTOATIVIDADE ................................................................................................................................ 167

TÓPICO 3 – OUTRAS ESTRUTURAS DE DADOS ........................................................................ 1691 INTRODUÇÃO .................................................................................................................................... 1692 OBJETOS DE BANCOS DE DADOS .............................................................................................. 170

2.1 ÍNDICES ........................................................................................................................................... 1702.2 SEQUENCES ................................................................................................................................... 1722.3 VIEWS ............................................................................................................................................... 175

X

3 PL/SQL ................................................................................................................................................... 1773.1 PROCEDURES ................................................................................................................................. 1783.2 FUNCTION ...................................................................................................................................... 1793.3 PACKAGES ....................................................................................................................................... 1803.4 TRIGGERS ........................................................................................................................................ 181


REFERÊNCIAS ........................................................................................................................................ 187

1

UNIDADE 1

FUNDAMENTOS DE BANCO DE DADOS

OBJETIVOS DE APRENDIZAGEM

PLANO DE ESTUDOS

Esta unidade tem por objetivos:

• apresentar o que é um banco de dados;

• demonstrar como foi a evolução dos bancos de dados;

• apresentar perspectivas e tendências desta tecnologia.

Esta unidade está dividida em três tópicos e, em cada um deles, você encontrará atividades que proporcionarão a compreensão dos conteúdos apresentados.

TÓPICO 1 – INTRODUÇÃO A BANCO DE DADOS

TÓPICO 2 – EVOLUÇÃO DOS BANCOS DE DADOS

TÓPICO 3 – TENDÊNCIAS E PERSPECTIVAS

3

TÓPICO 1UNIDADE 1

INTRODUÇÃO A BANCO DE DADOS

1 INTRODUÇÃO

“O período de maior ganho de conhecimento e experiência é o período de maior dificuldade na vida de cada um”. (Dalai Lama)

Esse tópico tem como objetivo apresentar ao(a) acadêmico(a) conceitos de bancos de dados. Você aprenderá que existe uma grande diferença entre dado e informação e que a partir deles é possível gerar conhecimento. Compreender isso é requisito básico para o bom aproveitamento da disciplina.

FIGURA 1 – DADO, INFORMAÇÃO E CONHECIMENTO

FONTE: Os autores

Também será abordado um histórico do gerenciamento dos dados. O objetivo é que se perceba que vários ciclos de aperfeiçoamento aconteceram para se chegar ao nível tecnológico que temos hoje.

Para fins conclusivos, veremos quais são os principais bancos de dados relacionais existentes no mundo. Você perceberá que cada um deles possui focos diferenciados com características e particularidades que necessitam de uma análise aprofundada para sua melhor compreensão.

UNIDADE 1 | FUNDAMENTOS DE BANCO DE DADOS

4

2 CONCEITOS DE BANCO DE DADOS

2.1 DADO E INFORMAÇÃO

Para entendermos melhor o que é um banco de dados, precisamos antes compreender a diferença que existe entre dado e informação. Dado é um conteúdo que ainda não foi processado para gerar um significado. Pode-se dizer que dado é a menor unidade de conteúdo que tem significado no mundo real. Por exemplo, ao realizar uma pesquisa para mapear a qualidade de uma biblioteca, normalmente são feitas entrevistas com seus respectivos usuários. A figura a seguir mostra o formulário WEB onde os dados da pesquisa podem ser coletados.

FIGURA 2 – FORMULÁRIO DE COLETA DE DADOS PARA A PESQUISA

FONTE: Os autores

TÓPICO 1 | INTRODUÇÃO A BANCO DE DADOS

5

Assim que os usuários responderem à pesquisa, os dados vão sendo armazenados em um depósito de dados. A figura a seguir representa este depósito de dados.

FIGURA 3 – DEPÓSITO DE DADOS DA PESQUISA

FONTE: Os autores

Mesmo já possuindo os dados, eles não têm uma utilidade bem definida. É possível ler linhas e linhas de pesquisa, porém não se tem um real significado do que ela traz como resultado. A partir desse momento surgem questões como, por exemplo, qual é o grau de escolaridade dos usuários da biblioteca e como eles avaliam o atendimento?

Para responder a estas perguntas, precisamos fazer uma análise de todas as respostas e formatá-las de uma forma mais resumida e de fácil entendimento. Quando executamos esse processo estamos gerando informação, que é o processamento de dados para responder a algumas perguntas ou traduzir de uma forma mais sumarizada o significado dos mesmos. A informação sempre é gerada com base nos dados. A figura a seguir mostra algumas informações dos dados da pesquisa.

FIGURA 4 – INFORMAÇÕES DE PARTE DO RESULTADO DA PESQUISA

FONTE: Os autores


6

A informação gera conhecimento. Rob e Coronel (2011, p. 11) nos dizem que “o conhecimento implica familiaridade, consciência e compreensão das informações conforme se apliquem a um ambiente”. Quando conseguimos compreender informações e relacioná-las ao seu contexto, estamos obtendo conhecimento.

As informações podem ser utilizadas para tomada de decisão. No exemplo da pesquisa da biblioteca, pode ser feita uma análise para descobrir como está a qualidade do atendimento, e com base nisso, tomar decisões para melhorar os pontos fracos.

DICAS

2.2 BANCOS DE DADOS

Agora que já sabemos o que são dados, informações, conhecimento e qual é a diferença entre ambos, precisamos nos concentrar no local onde os dados ficam armazenados. Anteriormente nos referimos a esse local como depósito de dados, porém, o mais correto seria chamar de banco de dados. Para definir banco de dados, buscamos uma explanação mais genérica e abrangente escrita por Elmasri e Navathe (2011, p. 3):

Um banco de dados é uma coleção de dados relacionados. Com dados, queremos dizer fatos conhecidos que podem ser registrados e possuem significado implícito. Por exemplo, considere os nomes, números de telefone e endereço das pessoas que você conhece. Você pode ter registrado esses dados em uma agenda ou, talvez, os tenha armazenado em um disco rígido, usando um computador pessoal e um software como Microsoft Access ou Excel. Essa coleção de dados relacionados, com um significado implícito, é um banco de dados.

Um banco de dados também pode ser chamado de base de dados. Os dados são armazenados de uma maneira que tem como objetivo facilitar a inclusão, remoção, consulta e alteração. Eles representam aspectos ou fatos do mundo real, que muitas vezes é denominado de minimundo ou universo de discurso. Só devemos armazenar no banco de dados o que faz parte do seu minimundo.

Para exemplificar melhor, pense em um sistema de vendas de ingressos online para cinemas. Nesse minimundo existem características que são importantes e necessárias para a venda de ingressos, como por exemplo, o nome do filme, horário em que ele será reproduzido, o local, se é dublado ou legendado etc. Essas características precisam estar armazenadas para possíveis consultas e alterações. Já características como a cor das paredes ou o tipo de piso da sala do cinema não são fatos necessários para posterior consulta em um sistema e não precisam ser armazenados no banco de dados.


7

Para simplificar a definição, podemos dizer que o minimundo é tudo o que existe no mundo real que é pertinente para a resolução do problema. A figura a seguir demostra de forma visual este conceito.

FIGURA 5 – CONCEITO DE MINIMUNDO

FONTE: Os autores

Bancos de dados existem normalmente para serem utilizados por aplicações. Elas é que realizam consultas e fazem alterações nos dados. Para tornar esse processo mais simples, existe o Sistema Gerenciador de Banco de Dados (SGDB) que é um software responsável por manter os bancos de dados que estão sob sua responsabilidade. Nele existem funções pré-definidas para inserção, remoção, atualização e consulta dos dados armazenados. A figura a seguir nos dá uma visão geral da relação entre o SGDB e o seu universo.

FIGURA 6 – SGDB E SEU UNIVERSO

FONTE: Disponível em: <http://www.devmedia.com.br/conceitos-fundamentais-de-banco-de-dados/1649>. Acesso em: 18 nov. 2012.


8

Detalhes do funcionamento e filosofias do SGDB serão vistos em tópicos posteriores. Por hora, somente memorize que SGDB é um software responsável pelo gerenciamento de bases de dados.

3 HISTÓRICO DO GERENCIAMENTO DOS DADOSConseguimos de forma introdutória definir alguns conceitos básicos

relacionados a banco de dados. Vimos que existe um Sistema Gerenciador de Banco de Dados que é responsável pelo gerenciamento dos dados. Para a tecnologia chegar a esse patamar, passou por diversos processos evolutivos que tiveram como resultado a organização que temos hoje.

Voltando no tempo, quando a informática estava dando seus primeiros passos, os sistemas eram desenvolvidos para atender a demandas isoladas, com foco na resolução de problemas dentro de determinadas áreas.

Para evidenciar de forma mais clara essa ideia, considere a seguinte situação: um gerente da área de vendas de uma determinada empresa precisa ter informações mais detalhadas dos vendedores que ele gerencia e das vendas que são efetuadas. Todos os dados estão armazenados fisicamente em pastas que se encontram dentro de gavetas de arquivos.

Com muito trabalho, ele consegue examinar todas as suas pastas e extrair as informações de que necessitava. Acontece que de uma hora para outra suas vendas aumentaram muito, fazendo com que fosse necessária a contratação de novos profissionais. Nesse novo cenário, o gerente não consegue mais obter as informações necessárias dos vendedores e suas vendas, pois o volume cresceu de tal forma que tornou inviável a análise manual dos dados.

Esse acontecimento faz com que seja necessário um sistema de computador. Sendo assim, é feita a conversão do sistema de arquivos manual para um sistema de informação. Esse novo sistema ainda não utilizava um SGBD (o conceito de SGBD será visto mais à frente). Todos os dados eram gravados em arquivos e cada programa que era construído poderia ter um formato diferente de organização para a gravação. Rob e Coronel (2011, p. 12) fazem um relato do que aconteceu naquela época.

A conversão de um sistema de arquivos manual para um sistema de arquivos computadorizado correspondente pode ser tecnicamente complexa (como as pessoas estão habituadas as interfaces relativamente amigáveis dos computadores de hoje, se esqueceram de quão hostis eram essas máquinas!). Isso gerou um novo tipo de profissional, conhecido como especialista em processamento de dados (PD), que devia ser contratado ou “desenvolvido” a partir da equipe atual. O especialista em PD criava as estruturas de arquivos computacionais necessárias, escrevendo o software que gerenciava os dados dentro dessas estruturas e projetava aplicativos que produziam relatórios com base nos dados dos arquivos. Assim, surgiram vários sistemas computadorizados “domésticos”.


9

De uma forma resumida, podemos dizer que existiam programas de computadores gravando dados em arquivos e eles eram responsáveis por toda a estrutura e complexidade de gravação. A figura a seguir ilustra essa abordagem.

FIGURA 7 – GERENCIAMENTO DE DADOS EM SISTEMA DE ARQUIVOS

FONTE: Os autores

Seguindo essa linha, podemos concluir que se a estrutura de dados de um arquivo fosse alterada, todos os programas que utilizassem esse arquivo precisariam ser atualizados, pois deixariam de funcionar. Para fins de exemplo, imagine que existe um arquivo com os dados de clientes. Foi solicitado que seja inclusa uma observação para cada cliente. Tomando como base a figura anterior, é feita uma alteração no programa que está rodando no computador 1 e logicamente no arquivo cliente. A partir desse momento o programa que está no computador 2 para de funcionar, pois ele ainda trabalha com a estrutura de dados antiga. Em casos mais complexos, ele poderia “corromper” o arquivo cliente, porque não tem conhecimento da nova estrutura de armazenamento.

Esse problema é conhecido pelo nome de dependência estrutural, em que independente do tipo de alteração que seja feita no arquivo, todos os programas precisarão ser alterados. Isso abre margem para erros, tornando todo o processo mais caro e difícil de ser executado. O desejado seria a independência estrutural, em que qualquer alteração de estrutura não influenciaria no acesso aos dados.

Como foi mencionado anteriormente, na época, quando o armazenamento de dados era feito em simples arquivos, os sistemas eram desenvolvidos de forma isolada, com focos bem distintos. Isso significa que o gerente da área de vendas tinha o seu sistema, o de recursos humanos tinha outro e o financeiro poderia ter outro específico para a sua necessidade. Conhecendo este cenário, podemos imaginar que o gerente de vendas possui dados dos seus vendedores e que o de recursos humanos também. Como ambos trabalham em sistemas distintos, cada um tem a sua versão dos dados, ou seja, o nome do vendedor está armazenado no sistema de vendas e no de recursos humanos.


10

Redundância de dados é o termo utilizado quando temos o mesmo dado armazenado em mais de um local. Rob e Coronel (2011, p.18) fazem um alerta para possíveis problemas que a redundância de dados pode gerar.

A estrutura do sistema de arquivos dificulta a combinação de dados a partir de várias fontes e sua falta de segurança torna o sistema de arquivos vulnerável a falhas. A estrutura organizacional realiza o armazenamento dos mesmos dados em locais diferentes. Os profissionais de bancos de dados utilizam o termo ilhas de informação para se referir a essa localização dispersa dos dados. Como é improvável que os dados armazenados em locais diferentes sejam sempre atualizados de modo consistente, as ilhas de informação, em geral, contém versões diferentesdos mesmos dados [...].

Pode acontecer, por exemplo, que um vendedor tenha uma alteração no seu nome. Essa alteração pode ter sido feita apenas no sistema de vendas, enquanto que no de recursos humanos o nome continua desatualizado. A figura a seguir documenta essa estrutura.

FIGURA 8 – REDUNDÂNCIA DE DADOS

FONTE: Os autores

A complexidade do gerenciamento de dados é alta no exemplo apresentado acima. Seria mais correto o dado estar armazenado em um único local para que todas as aplicações o consumissem.


11

Outro ponto a ser observado quanto ao armazenamento de dados em arquivos se refere à concorrência de acesso, ou seja, mais de um usuário tentando acessar o mesmo dado em um mesmo momento. Um exemplo clássico dessa situação é a manutenção de saldo de uma conta bancária.

Imagine uma conta bancária que tem um saldo de R$ 1.500,00. Se dois clientes retirarem dinheiro dessa conta ao mesmo tempo, teremos um problema de inconsistência dos dados. Vamos ver na prática como isso acontece: o cliente 1 e o cliente 2 fazem uma busca no saldo da conta e ambos têm como resultado R$ 1.150,00. O primeiro retira R$ 300,00 da conta e o segundo R$ 150,00. Dependendo de qual cliente finalize a operação por último o saldo da conta poderá ser R$ 850,00 (R$ 1.500,00 – R$ 300,00) ou R$ 1.000,00 (R$ 1.150,00 – R$ 150,00).

O correto seria que quando está sendo feita a manutenção do saldo pelo cliente 1, o cliente 2 ficasse aguardando a manutenção terminar para daí sim iniciar o seu procedimento. Em um sistema de arquivos isso é muito complicado de gerenciar.

Até agora vimos como era o armazenamento de dados em arquivos juntamente com algumas características negativas desse modelo. Percebemos que a dependência estrutural dos dados, a redundância e o acesso concorrente são fatores dificultadores que podem causar vários erros nos sistemas. Visando diminuir a complexidade no gerenciamento de dados surge o SGBD ou Sistema Gerenciador de Banco de Dados. Esse será o nosso próximo assunto. Por enquanto, entenda que compreender o funcionamento de sistemas que gravam dados em arquivos é muito útil para evitarmos os mesmos problemas quando iniciarmos o trabalho com SGBD.

4 SISTEMA GERENCIADOR DE BANCO DE DADOS

4.1 DEFINIÇÕES DE UM SGBD

Um Sistema Gerenciador de Banco de Dados é um software responsável pelo gerenciamento de base de dados. Uma das principais características dele é retirar da aplicação à estruturação dos dados, deixando de forma transparente o acesso aos mesmos. A figura a seguir mostra graficamente onde o SGBD está inserido.


12

FIGURA 9 – SGBD

FONTE: Os autores

O SGBD elimina boa parte da complexidade do gerenciamento de dados, fazendo com que o programador tenha um foco maior na lógica da sua aplicação do que no armazenamento dos dados.

Ao falarmos de SGBD precisamos entender como funciona a forma básica de armazenamento nesse novo tipo de organização. Ao invés de gravarmos dados em arquivos, gravamos em tabelas. Uma tabela possui colunas e registros. Vamos resumir a organização de armazenamento de dados de um SGBD:

• Um banco de dados é formando por uma ou mais tabelas.• Tabelas são locais onde os dados ficam logicamente armazenados.• Colunas são campos que armazenam um determinado tipo de dado.• Registros são linhas, que de uma forma mais resumida, pode-se dizer que são

conjuntos de campos preenchidos.

A figura a seguir esclarece esse conceito.

FIGURA 10 – FORMA BÁSICA DE ARMAZENAMENTO DE DADOS

FONTE: Os autores


13

4.2 FUNÇÕES DE UM SGBD

A seguir listamos algumas funções do SGBD:

• Manutenção do dicionário de dados – toda aplicação que desejar trabalhar com o banco de dados fará isso por intermédio do SGBD. Ele mantém definições de estruturas de dados e como eles estão relacionados. Qualquer alteração de estrutura é automaticamente atualizada no dicionário de dados. Isso retira a responsabilidade dos programas que necessitam dos dados de manter a estrutura de organização dos mesmos. Essa é a função do SGBD que tem toda a estrutura dos dados em seu dicionário de dados. A figura a seguir traz um exemplo do dicionário de dados de um banco Mysql.

FIGURA 11 – DICIONÁRIO DE UM BANCO DE DADOS MYSQL

FONTE: Os autores

• Segurança – O SGBD é responsável por garantir regras de segurança no que diz respeito ao acesso a dados e a objetos do banco. Cada usuário deve utilizar algum meio para se autenticar no SGBD, seja por login e senha ou através de leitura biométrica. Ao se autenticar, existem regras que definem os acessos, ou seja, quais bases estão visíveis, quais tabelas ou qualquer outra característica que estará disponível. Também existem controles em nível de objeto. O usuário pode ter acesso somente à leitura em um determinado objeto e gravação/leitura em vários outros.


14

• Apresentação dos dados em vários formatos – Um exemplo clássico deste conceito se refere ao trabalho com datas. Para clarificar, vamos pensar em uma data: 21 de dezembro de 2012. Essa data aqui no Brasil pode ser digitada por um usuário como 21/12/2012, enquanto que nos Estados Unidos a mesma seria 12/21/2012. O SGBD consegue manipular ambas as datas de forma transparente, desde que configurado corretamente.

• Controle de acesso simultâneo ao mesmo dado – garante a integridade e consistência dos dados armazenados no banco quando acessados de forma concorrente. Isso resolve o problema apresentado no título “3 HISTÓRICO DO GERENCIAMENTO DOS DADOS”, que descrevia o acesso de dois usuários na manutenção do saldo de uma conta bancária em um sistema de arquivos.

• Gerenciamento de backups – o SGBD fornece ferramentas para que o administrador do banco de dados possa configurar e efetuar backups. Se for feito o backup, outra funcionalidade existente é a de retornar os dados que o mesmo salvou. Isso pode ser necessário por vários motivos como, por exemplo, falhas de hardware ou manipulação da base de dados de forma incorreta.

• Linguagem de acesso e manipulação dos dados – é fornecida pelo SGBD uma linguagem estruturada para consulta e alteração dos dados. Através dela, é possível que o utilizador tenha acesso aos dados de uma forma mais simplificada. O SQL (Structured Query Language) é uma espécie de linguagem padrão para este fim. Alguns SGBDs fornecem outra linguagem de programação para possibilitar a implementação de rotinas que executem no servidor do banco. Isso pode viabilizar a criação de aplicações mais performáticas, pois ao invés de consumir processamento e recursos de rede da máquina do usuário, boa parte do programa roda no servidor.

4.3 ESTRUTURA DE UM SGBD

Os sistemas gerenciadores de bancos de dados são compostos, de uma forma geral, por módulos com funcionalidades bem definidas. Cada módulo tem sua responsabilidade no processo de gerenciamento dos dados. Usuários e programadores interagem com esses módulos a fim de obter seus resultados. A figura a seguir detalha essa estrutura.


15

FIGURA 12 – ESTRUTURA DE UM SGBD

FONTE: Disponível em: <http://www.ime.usp.br/~andrers/aulas/bd2005-1/aula5.html>. Acesso em: 18 nov. 2012.

Vamos detalhar os módulos apresentados na figura anterior.

• Programas aplicativos/consultas – Um usuário comum normalmente utiliza um sistema e é através desse sistema que o acesso ao banco de dados é feito. Já um programador tem ferramentas que são específicas para trabalhar com a tecnologia que o SGBD disponibiliza. Essas ferramentas tem um foco mais centrado na visualização de dados e manutenção de suas estruturas.

• Processador/otimizador de consultas – Interpreta todos os acessos que são feitos na base de dados com um foco maior em otimização. Em outras palavras, ele é responsável por processar e definir “caminhos” para que o usuário tenha uma resposta a sua solicitação com performance.

• Software para acessar os dados – Esse módulo é o responsável por recuperar os dados do local onde eles estão armazenados. Esses dados são divididos em dois grupos: os dados armazenados e a definição dos dados armazenados. O primeiro grupo se refere aos dados que um usuário comum manipula, como por exemplo, nomes de pessoas, cidades, endereços, telefones etc. Já o segundo define a forma de organização dos dados do primeiro grupo. É composto por tabelas, índices, relacionamentos etc.


16

4.4 TIPOS DE USUÁRIOS DO SGBD

Existem vários tipos de usuários que acessam bancos de dados. Alguns têm um foco mais gerencial, enquanto outros apenas se concentram na manipulação de dados da base. A seguir detalhamos alguns tipos de usuários e suas responsabilidades ou necessidades.

• Administrador do banco de dados (DBA – Database Administrator) – Essa figura é responsável por toda a administração do banco de dados. Atividades como instalação, configuração e melhorias em performance fazem parte do seu dia a dia. Também possui tarefas relacionadas ao gerenciamento de acesso de usuários na base e um constante monitoramento visando garantir uma alta disponibilidade do sistema.

• Projetista ou analista de dados – É o profissional que tem como tarefa fazer o mapeamento dos dados que deverão ser armazenados no banco. Em seguida, vem à definição da estrutura onde os mesmos serão “organizados”. Isso envolve a criação/manutenção de tabelas e demais objetos de acordo com a tecnologia do SGBD. Este usuário tem um grande foco em performance, pois quando vai definir a estrutura de organização dos dados é crucial que ela seja performática.

• Programador – É a figura que constrói o sistema que irá acessar o banco de dados. É imprescindível que o sistema desenvolvido manipule os dados de forma correta, para evitar a perda ou falta de confiança neles.

• Usuário comum – Utiliza o sistema que foi desenvolvido pelo programador para acessar o banco de dados. Normalmente desconhece as estruturas onde os dados estão armazenados. Consegue manipular somente o que o sistema permite. Ele é a sua fronteira com o SGBD.

5 PRINCIPAIS BANCOS DE DADOS DISPONÍVEIS NO MERCADO

Atualmente existem vários fornecedores de bancos de dados. Isso significa que é necessária uma boa análise antes de decidir qual banco utilizar. Cada um tem as suas características e peculiaridades. Alguns são apropriados para projetos menores, outros não. O custo para implantação também deve ser levado em conta. A seguir, vamos ver uma breve descrição dos principais SGBDs disponíveis no mercado.

5.1 MYSQL

É um dos SGBDs mais populares do mundo. Inicialmente foi desenvolvido para aplicações de pequeno porte, porém já superou há muito tempo essa barreira.


17

5.2 ORACLE

Hoje, é um dos bancos de dados mais robustos e confiáveis do mundo corporativo. Nasceu da ideia de um homem que percebeu que o mercado precisava desse tipo de tecnologia.

O MySQL teve origem quando os desenvolvedores David Axmark, Allan Larsson e Michael “Monty” Widenius, na década de 90, precisaram de uma interface SQL compatível com as rotinas ISAM que utilizavam em suas aplicações e tabelas. Em um primeiro momento, tentaram utilizar a API mSQL, contudo a API não era tão rápida quanto eles precisavam, pois utilizavam rotinas de baixo nível (mais rápidas que rotinas normais). Utilizando a API do mSQL, escreveram em C e C++ uma nova API que deu origem ao MySQL. Com o ótimo resultado gerado por essa nova API, o MySQL começou a ser difundido e seus criadores fundaram a empresa responsável por sua manutenção, que é a MySQL AB. (MILANI, 2007, p. 23).

Como foi citado acima, a empresa que mantinha inicialmente o Mysql era a Mysql AB. Ela foi comprada pela Sun em janeiro de 2008. Em abril de 2009, a Oracle, que é uma das gigantes do mundo de bancos de dados comprou a Sun, sendo hoje responsável pela manutenção do MySql.

Atualmente, o Mysql se encontra na versão 5.6 e é muito utilizado em aplicações WEB. Roda em várias plataformas como Linux e Windows. É livre para uso não comercial. O site oficial é <http://www.mysql.com>.

Há quase trinta anos, Larry Ellison vislumbrou uma oportunidade que outras companhias não haviam percebido, quando encontrou uma descrição de um protótipo funcional de um banco de dados relacional e descobriu que nenhuma empresa tinha se empenhado em comercializar essa tecnologia. Ellison e os cofundadores da Oracle, Bob Miner e Ed Oates, perceberam que havia um tremendo potencial de negócios no modelo de banco de dados relacional, mas não se deram conta de que mudariam a face da computação empresarial para sempre. Hoje a Oracle (Nasdaq: ORCL) continua à frente de seu tempo. A tecnologia Oracle pode ser encontrada em quase todos os setores do mundo inteiro e nos escritórios de 98 das empresas citadas na lista “Fortune 100”. A Oracle é a primeira empresa de software a desenvolver e empregar software empresarial totalmente habilitado para Internet em toda a sua linha de produtos: banco de dados, aplicativos empresariais e ferramentas para desenvolvimento de aplicativos e suporte a decisões. A Oracle é o principal fornecedor de software para gerenciamento de informações e a segunda maior empresa de software independente do mundo.

FONTE: Disponível em: <http://www.oracle.com/br/corporate/press/story-346137-ptb.html>. Acesso em: 16 jan. 2013.


18

5.3 POSTGRESQL

O Oracle possui uma vasta lista de recursos. Tem a linguagem PL/SQL para desenvolvimento de funcionalidades internas. Integra-se com outras linguagens de programação como JAVA, C, C++ etc. Roda em várias plataformas. O site oficial é <http://www.oracle.com>.

É conhecido pela sua robustez e confiabilidade e tem uma característica bem interessante: é um SGBD de código fonte aberto. O texto a seguir descreve esse banco de dados com uma maior riqueza de detalhes.

Leia a seguir um texto retirado do site da comunidade brasileira de PostgreSql.

UNI

O QUE É O POSTGRESQL?

Para alguns pode parecer um assunto batido, mas esse é um artigo introdutório, voltado principalmente àqueles que conhecem pouco ou nada sobre o PostgreSQL. O PostgreSQL é um SGBD (Sistema Gerenciador de Banco de Dados) objeto-relacional de código aberto, com mais de 15 anos de desenvolvimento. É extremamente robusto e confiável, além de ser extremamente flexível e rico em recursos. Ele é considerado objeto-relacional por implementar, além das características de um SGBD relacional, algumas características de orientação a objetos, como herança e tipos personalizados. A equipe de desenvolvimento do PostgreSQL sempre teve uma grande preocupação em manter a compatibilidade com os padrões SQL92/SQL99.

HISTÓRICO DO POSTGRESQL

O PostgreSQL (conhecido anteriormente como Postgres95) derivou do projeto POSTGRES da universidade de Berkley, cuja última versão foi a 4.2. O POSTGRES foi originalmente patrocinado pelo DARPA (Agência de Projetos de Pesquisa Avançada para Defesa), ARO (Departamento de Pesquisa Militar), NSF (Fundação Cinetífica Nacional) e ESL Inc. A implementação do projeto POSTGRES iniciou em 1986, já em 87 tornou-se


19

operacional. A primeira versão lançada para o público externo foi em 1989. Devido a uma crítica feita ao seu sistema de regras, o POSTGRES teve essa parte reimplementada e lançada em uma segunda versão em 1990. Em 1991 foi lançada a versão 3, com melhorias no executor de consultas e algumas partes do código foram reescritas. As versões subsequentes, até o Postgres95, foram focadas em confiabilidade e portabilidade. O POSTGRES foi utilizado para diversos sistemas de pesquisa e de produção, uma aplicação de análise financeira, um banco com rotas de asteroides, e diversos sistemas de informações geográficas. O código do POSTGRES foi aproveitado em um produto comercializado pela Illustra Information Technologies (posteriormente incorporada à Informix, que agora pertence à IBM).

A versão seguinte, o Postgres95, teve mudanças radicais em relação ao projeto original. O seu código foi totalmente revisado, o tamanho das fontes foi reduzido em 25%, e a linguagem SQL foi implementada como interface padrão. A performance foi consideravelmente melhorada e vários recursos foram adicionados. Em 1996. o nome Postgres95 tornou-se inadequado, o projeto foi rebatizado “PostgreSQL”, para enfatizar a relação do POSTGRES original com a linguagem SQL. A numeração da versão voltou a seguir o padrão anterior ao Postgres95 (considerada a 5.0), e a primeira versão do PostgreSQL foi a 6.0. Enquanto a ênfase do Postgres95 tinha sido a correção de falhas e otimização do código, o desenvolvimento das primeiras versões do PostgreSQL foi orientada à melhoria de recursos e implementação de novos recursos, sempre seguindo os padrões de SQL anteriormente estabelecidos.

O POSTGRESQL HOJE

A equipe do projeto cresceu e se espalhou pelo mundo. O Grupo Global de Desenvolvimento do PostgreSQL tem membros nos Estados Unidos, Canadá, Japão, Rússia, vários países da Europa e alguns outros. Esse grupo é formado essencialmente por empresas especializadas em PostgreSQL, empresas usuárias do sistema, além dos pesquisadores acadêmicos e programadores independentes. Além da programação, essa comunidade é responsável pela documentação, tradução, criação de ferramentas de modelagem e gerenciamento, e elaboração de extensões e acessórios.

Pela riqueza de recursos e conformidade com os padrões, ele é um SGBD muito adequado para o estudo universitário do modelo relacional, além de ser uma ótima opção para empresas implementarem soluções de alta confiabilidade sem altos custos de licenciamento. É um programa distribuído sob a licença BSD, o que torna o seu código fonte disponível e o seu uso livre para aplicações comerciais ou não. O PostgreSQL foi implementado em diversos ambientes de produção no mundo, entre eles, um bom exemplo do seu potencial é o banco de dados que armazena os registros de domínio .org, mantido pela empresa Afilias.


20

Alguns recursos presentes na versão mais recente:Subconsultas.Controle de concorrência multiversão (MVCC).Integridade Referencial.Funções armazenadas (Stored Procedures), que podem ser escritas em

várias linguagens de programação (PL/PgSQL, Perl, Python, Ruby, e outras).Gatilhos (Triggers).Tipos definidos pelo usuário.Esquemas (Schemas).Conexões SSL.Áreas de armazenamento (Tablespaces).Pontos de salvamento (Savepoints).Commit em duas fases.Arquivamento e restauração do banco a partir de logs de transação.Diversas ferramentas de replicação.Extensões para dados geoespaciais, indexação de textos, xml e várias outras.

COMO COMEÇAR?

No site nacional do projeto podem ser encontrados tutoriais de instalação nas plataformas Linux e Windows, além do manual de referência traduzido. No site oficial, você encontra toda a documentação. Para baixar o código fonte do PostgreSQL, você pode utilizar o mirror brasileiro. Depois de seguir as instruções de instalação do tutorial, você pode escolher uma boa ferramenta gráfica de gerenciamento.

Alguns links úteis:Site Oficial (<http://www.postgresql.org>)Site de marketing (<http://advocacy.postgresql.org/?lang=br>)Site nacional (<http://www.postgresql.org.br>)Lista de discussão nacional (<http://br.groups.yahoo.com/group/

postgresql-br>)

FONTE: Disponível em: <http://wiki.postgresql.org.br/Introdu%C3%A7%C3%A3o_e_hist%C3%B3rico>. Acesso em: 16 jan. 2013.

5.4 SQL SERVER

É o banco de dados da empresa Microsoft. É considerado um dos principais concorrentes da Oracle. O texto a seguir descreve o SQL Server.


21

TODA A HISTÓRIA DO SISTEMA SQL DA MICROSOFT

Você sabe o que é o SQL Server? Se você tem um blog ou um site que utiliza banco de dados já deve ter, pelo menos, ouvido falar nele. O MS SQL Server é um sistema de gerenciamento de banco de dados relacional desenvolvido pela Microsoft. A partir da versão 2008 a plataforma de dados com alta confiabilidade e que permite a redução de custos com eficiência e robustez.

Tudo começou em março de 1987 quando a Microsoft comprou os direitos do DataServer da Sysbase para o sistema operacional OS/2. O objetivo era provocar o interesse e chamar a atenção da comunidade do dBase. Por isso a Microsoft traçou um acordo com a Ashton-Tate como forma de endossar esse novo processo. Assim, a primeira versão do SQL Server se chamava Ashton-Tate/Microsoft SQL Server e chegou ao mercado na metade final de 1988. Em maio do ano seguinte a versão 1.0 para OS/2 era lançada com parca participação da Microsoft (limitando-se apenas a poucas ferramentas, testes e o projeto visando tornar o aplicativo mais simples de ser instalado). Na segunda metade de 1990 a união da Microsoft com a Ashton-Tate se encerrou e a versão 1.1 do SQL Server passou a oferecer suporte para o Windows 3.0 (que era uma novidade na época). Apesar disso, a base do SQL era produzida pela Sysbase e a Microsoft sequer tinha acesso ao código-fonte. Qualquer defeito tinha que ser relatado para a Sysbase e corrigido apenas por ela. Só em 1991 a Microsoft passou a poder acessar a fonte do SQL apenas para leitura.

Com o lançamento da versão 4.2 para OS/2 no fim de 1991 a Microsoft já desenvolvia o banco de dados em conjunto com a Sysbase, o que só mudou em agosto de 1993 quando a Microsoft finalmente conseguiu a totalidade da criação do SQL Server e lançou a versão para o Windows NT 3.1. Essa nova versão já era em 32-bit. Assim, pouco tempo depois, a parceria entre as duas empresas acabava.

Podemos declarar como principais vantagens do SQL Server o fornecimento de uma plataforma de grande confiabilidade e robustez capaz de suportar aplicações de missão crítica de grande exigência. A possibilidade de encriptação dos dados contidos em todo o banco de dados ou nos arquivos de log. Isso protege os dados das solicitações não autorizadas sem a necessidade de aplicativos complementares. Além disso, ele permite o espelhamento do banco de dados a recuperação automática da página de dados e a compressão do fluxo de logs. Um aumento na produtividade com a rapidez e simplicidade de instalação, manutenção e uso. Também possui uma enorme versatilidade na aceitação de informações e no oferecimento de respostas previsíveis as demandas dos usuários.


22

As aplicações vão desde criar aplicações que se utilizem de um banco de dados de forma rápida e simples até aplicações de alta complexidade com a mesma facilidade. Da mesma forma o SQL Server garante que seus dados podem ser acessados de qualquer lugar mesmo estando baseados a distância e serem acessados por uma enorme variedade de aplicativos diferentes o que o torna muito prático e de fácil uso para hospedagem de sites na internet.

FONTE: Disponível em: <http://www.artigonal.com/advertising-artigos/toda-a-historia-do-sistema-sql-da-microsoft-1845126.html>. Acesso em: 16 jan. 2013.

Caro(a) acadêmico(a)! A Leitura Complementar a seguir traz uma visão clara de questões relacionadas à utilização de um sistema de banco de dados. A seguir serão apresentados alguns fatores que devem ser analisados quando trabalhamos com esse tipo de tecnologia.

UNI

GERENCIAMENTO DO SISTEMA DE BANCO DE DADOS: UMA MUDANÇA DE FOCO

A introdução de um sistema de banco de dados em um ambiente de sistema de arquivos fornece um modelo no qual podem ser aplicados procedimentos e padrões rígidos. Como consequência, o papel do componente humano muda da ênfase em programação (no sistema de arquivos) para focar nos aspectos mais amplos de gerenciamento dos recursos de dados da organização e na administração do próprio software do banco de dados complexo.

O sistema de banco de dados torna possível atingir usos muito mais sofisticados dos recursos de dados contanto que seja projetado para aproveitar esse poder disponível. Os tipos de estruturas de dados criados no banco de dados e a extensão dos relacionamentos entre elas desempenham um papel poderoso na determinação da eficiência do sistema.

Embora o sistema de banco de dados apresente vantagens consideráveis em relação à abordagem de gerenciamento anteriores, também trazem desvantagens significativas. Por exemplo:

LEITURA COMPLEMENTAR


23

Aumento de custos: os sistemas de banco de dados exigem hardware e software sofisticado e pessoal altamente treinado. O custo de manutenção do hardware, software e pessoal necessários para operar e gerenciar um sistema de banco de dados pode ser substancial. Os custos de treinamento, licenciamento e atendimento as regulamentações costumam ser negligenciados quando da implementação desses sistemas.

Complexidade do gerenciamento: os sistemas de banco de dados apresentam interfaces com muitas tecnologias diferentes e têm um impacto significativo sobre os recursos e a cultura de uma empresa. As alterações introduzidas pela adoção do sistema de banco de dados devem ser adequadamente gerenciadas para garantir que ajudem no progresso dos objetivos da empresa. Levando em conta o fato que os bancos de dados mantêm dados fundamentais da empresa que são acessados a partir de várias fontes, as questões de segurança deve ser uma constante preocupação.

Manutenção de banco de dados atualizado: para maximizar a eficiência do sistema de banco de dados, deve-se manter o sistema atualizado. Portanto, é necessário fazer atualizações frequentes e aplicar os últimos pacotes e medidas de segurança a todos os componentes. Como a tecnologia do banco de dados avança rapidamente, os custos com treinamento de pessoal tendem a ser significativos.

Dependência do fornecedor: Em virtude do alto investimento em tecnologia e treinamento de pessoal, as empresas podem hesitar em trocar os fornecedores de banco de dados. Por essa razão, é menos provável que estes ofereçam vantagens de preço aos clientes existentes, que ficarão restritos quanto a suas escolhas de componentes de sistema de banco de dados.

Ciclos frequentes de atualização/substituição: os fornecedores de SGBDs atualizam seus produtos adicionando novas funcionalidades. Em geral, esses recursos são integrados a novas versões de atualização de software. Algumas dessas versões exigem atualizações de hardware. Não são apenas as atualizações que geram custo, mas também o treinamento dos usuários e administradores para que utilizem e gerenciam adequadamente os novos recursos.

FONTE: Rob e Coronel (2011, p. 18)

24

RESUMO DO TÓPICO 1

Neste tópico, você viu que:

• Existe uma grande diferença entre dado, informação e conhecimento.

• Bancos de dados relacionais predominam no mundo do desenvolvimento de software.

• SGBD ou Sistema Gerenciador de Bancos de Dados foi uma evolução do paradigma de armazenamento em arquivos.

• Algumas dicas são importantes para ter sucesso na escolha do banco de dados a ser utilizado.

25

1 De acordo com o conteúdo estudado, defina o conceito de dado, informação e conhecimento.

2 O que é um SGBD ou Sistema Gerenciador de Bancos de Dados e qual é a sua melhoria em relação ao armazenamento de dados em arquivos?

3 Dê quatro exemplos de bancos de dados relacionais disponíveis no mercado.

4 Cite as principais funções de um SGBD.

5 O que faz uma pessoa que tem o cargo de Administrador do Banco de Dados (DBA – Database Administrator)?

AUTOATIVIDADE

27

TÓPICO 2

EVOLUÇÃO DOS BANCOS DE DADOS

UNIDADE 1

1 INTRODUÇÃO“O descontentamento é o primeiro passo na evolução de um homem

ou de uma nação”. (Oscar Wilde)

Relembrando um pouco do Tópico 1, vimos que inicialmente os bancos de dados eram simples sistemas de arquivos. Tudo o que era desenvolvido tinha uma finalidade específica, não existindo muita integração entre sistemas distintos. Isso gerou vários problemas, como redundância de dados e concorrência de acessos. Outro ponto negativo nesse tipo de estrutura é que toda a organização dos dados ficava armazenada no programa que fazia a sua utilização. Questões relacionadas à alteração dessa estrutura ficavam relacionadas a inconsistências e trabalho árduo.

Também foi apresentado o conceito de SGBD, que é a evolução do modelo de sistemas de arquivos. Os principais SGBDs da atualidade fizeram parte desta apresentação e todos são considerados SGBDs relacionais ou objeto relacional. Esse tipo de tecnologia é o que predomina hoje no mercado quando tratamos de aplicações tradicionais.

Para entendermos o futuro é interessante conhecermos o passado. Por isso esse tópico trata da evolução dos bancos de dados, dividindo-se em três grupos: histórico da evolução, arquitetura e níveis de abstração dos bancos de dados. O primeiro trata as gerações dos bancos de dados (três gerações), o segundo as arquiteturas (centralizadas, distribuídas, cliente-servidor etc.) e o terceiro a abstração (três níveis).

Bons estudos!


28

2 HISTÓRICO DA EVOLUÇÃO DOS BANCOS DE DADOS

2.1 PRIMEIRA GERAÇÃO

A evolução ou o histórico da evolução dos bancos de dados estão divididos em três gerações: a primeira trata dos bancos hierárquicos e em rede, a segunda dos relacionais e a terceira dos bancos orientados a objetos e objeto relacional. Vamos estudar cada geração para entender melhor todo o processo de evolução.

Foi na década de 60 que “nasceram” os primeiros bancos de dados. Existiam basicamente duas formas de organização: o modelo hierárquico e o em rede. Ambos trabalhavam com o conceito de registro, que segundo Korth e Silberschatz (1995), é uma coleção de campos (atributos) os quais contêm apenas um valor de dado.

Também existe a ideia de ligação entre registros. Korth e Silberschatz (1995) definem que uma ligação é uma associação entre exatamente dois registros.

Um banco de dados hierárquico consiste basicamente em um conjunto de registros conectados por meio de ligações. Toda a estrutura está organizada em um modelo de árvore ou também conhecido como modelo hierárquico. Cada registro filho pode ter apenas um registro pai. Um registro pai pode ter vários registros filho. Exemplificamos isso na figura a seguir.

FIGURA 13 – RELAÇÃO ENTRE REGISTRO PAI E REGISTROS FILHOS

FONTE: Os autores

Para simplificar o conceito de um banco de dados hierárquico observe a figura a seguir. Nela apresentamos uma estrutura típica de clientes de um banco com suas contas e saldo. Esse exemplo é muito utilizado em livros que tratam desse assunto.

PAI

FILHO FILHO FILHO

TÓPICO 2 | EVOLUÇÃO DOS BANCOS DE DADOS

29

FIGURA 14 – ESTRUTURA DE UM BANCO DE DADOS HIERÁRQUICO

FONTE: Os autores

A figura a seguir demostra a estrutura dos dados que estão na figura anterior.

FONTE: Os autores

FIGURA 15 – ESTRUTURA DE DADOS DA FIGURA 14

Os dados da conta e saldo podem ser acessados somente a partir do nó raiz (registro falso), seguindo os registros da esquerda para a direita. É necessário navegar por toda a estrutura para chegar a esses valores. Um dos problemas se refere à duplicidade de dados. Por exemplo, se uma conta pertencesse a mais de um cliente, os dados da conta provavelmente precisariam ser duplicados. Isso, segundo Korth e Silberschatz (1995) gera dois inconvenientes: a inconsistência dos dados quando acontecerem atualizações e a perda de espaço em disco.

Marcando presença ainda na primeira geração estão os bancos de dados que seguem o modelo em rede. São considerados como sendo uma evolução do modelo hierárquico. Embora o nome sugira ligação com redes de computadores (um computador “ligado” ao outro), o conceito não tem relação com isso.

Esse modelo surgiu com o benefício de que o registro possa fazer parte de várias associações, o que não era possível no hierárquico (a não ser que o registro fosse duplicado). Também eliminou a hierarquia quando ao acesso dos dados. A figura a seguir mostra uma estrutura de dados no modelo rede.

RAIZ

RAIZ

Marcos Silva

NOME CPF

Nº CONTA Nº CONTASALDO SALDO

CPFNOME

João Trindade469.206.617-21 227.428.671-04

R$ 150,00R$ 700,0070948 12496


30

FIGURA 16 – ESTRUTURA DE DADOS NO MODELO REDE

FONTE: Os autores

Na parte esquerda da figura 16 temos o nome do cliente e seu CPF. No lado direito a conta e o saldo. Note que agora é possível associar uma conta a dois clientes sem ter que duplicá-la (a conta 70948 pertence ao Marcos e ao João). Não temos a presença de um registro falso (raiz), sendo que agora se podem acessar os dados de qualquer parte do grafo.

Apesar de uma aparente melhoria em relação aos bancos de dados hierárquicos, o modelo em redes apresenta alguns problemas. É complicado para o programador trabalhar com esse modelo, pois ele tem que pensar em ligações de registros e como percorrê-las para buscar os dados que necessita.

Sendo assim, podemos concluir que a primeira geração de bancos de dados deixou pontos a serem melhorados. Entretanto, na época, existiam sistemas que eram referência para os modelos hierárquicos e de redes. Como exemplo, Kort e Silberschatz (1995) citam o IMS – sistema de gerenciamento de informações da IBM (hierárquico) e o IDMS (rede).

2.2 SEGUNDA GERAÇÃO

No início da década de 70, surge um novo conceito em banco de dados: o modelo de dados relacional. Esse modelo é largamente utilizado até os dias de hoje por aplicações de processamento de dados comerciais mais padronizadas (ERPs, CMDs etc.). Date (2003) nos diz que a introdução do modelo relacional em 1969-1970 foi sem dúvida o evento mais importante em toda a história da área de bancos de dados.

Rob e Coronel (2011) fazem um breve relato sobre este modelo.

O modelo relacional foi apresentado em 1970 por E. F. Codd (da IBM) em seu famoso artigo “A Relational Model Data for Large Shared Databanks” (Um modelo relacional de dados para grandes bancos de dados compartilhados) (Comunicações da ACM, junho de 1970, p. 377-387). O modelo relacional representava uma importante ruptura tanto para usuários como para projetistas. Para utilizar uma analogia, esse modelo produziu um banco de dados de “câmbio automático” para substituir os de “câmbio manual” que o precederam. Sua simplicidade conceitual preparou o terreno para a verdadeira revolução dos bancos de dados. (ROB; CORONEL, 2011, p. 40).

Marcos Silva

João Trindade

469.206.617-21

227.428.671-04 R$ 150,00

R$ 700,0070948

12496


31

O modelo relacional trabalha na sua forma mais básica com tabelas. Podem existir relações entre as mesmas para buscas de registros. A definição das tabelas pode envolver restrições para garantir dados confiáveis. Este modelo elimina a complexidade de navegação ou busca de dados presentes nos hierárquicos e nos de rede. A figura a seguir traz um exemplo de dados organizados sob o modelo relacional. Neste exemplo são listados os clientes de um banco com seus respectivos gerentes de conta.

FIGURA 17 – ORGANIZAÇÃO DE DADOS NO MODELO RELACIONAL

FONTE: Os autores

Note que na figura anterior existe um relacionamento entre as tabelas cliente e gerente. Para tal, é utilizada a coluna CD_GERENTE. Neste caso, significa que um cliente pode ter somente um gerente e que um gerente pode ter vários clientes. Podem ser adicionadas restrições em ambas as tabelas para que, por exemplo, não se permita o cadastro de mais de um gerente ou cliente com o mesmo CPF.

Quando trabalhamos com um modelo relacional é comum a utilização de um diagrama relacional ou MER – Modelo Entidade Relacionamento. A figura a seguir traz o MER da estrutura apresentada na figura anterior.


32

FIGURA 18 – MODELO ENTIDADE RELACIONAMENTO FIGURA 17

FONTE: Os autores

A presença de uma chave ao lado das colunas CD_CLIENTE E CD_GERENTE indica que os campos são identificadores únicos de registros, ou seja, o dado que está nessas colunas não poderá se repetir na tabela. Diz-se que esses campos são chaves primárias.

Boas partes dos conceitos apresentados aqui serão revistos e aprofundados na Unidade 2, que vai tratar exclusivamente do modelo de dados relacional.

2.3 TERCEIRA GERAÇÃO

A terceira geração é datada em meados do ano de 1980 e vai até os dias atuais. Como em todas as outras, essa geração também têm o seu destaque tecnológico. O nome deste novo conceito é banco de dados orientado a objetos.

Para detalhar melhor qual foi a origem deste tipo de banco de dados, Silberschatz, Korth e Sudarshan (2006) nos apresentam um breve relato.

As aplicações tradicionais de bancos de dados consistem em tarefas de processamento de dados, como transações bancárias e gerenciamento de folha de pagamento, com tipos de dados relativamente simples, que são adequados ao modelo de dados relacional. Uma vez que os sistemas de bancos de dados foram aplicados a uma faixa mais ampla de aplicações, como projeto auxiliado por computador e sistemas de informações geográficas, as limitações compostas pelo modelo relacional se apresentaram como um obstáculo. A solução era a introdução dos bancos de dados baseados em objeto, que permitem lidar com tipos de dados complexos. (SILBERSCHATZ; KORTH; SUDARSHAN, 2006 p. 241).

Esse novo tipo de estruturação permite uma adaptação menos dolorosa, porque vários programadores já estão familiarizados em linguagens orientadas a objeto, o que em termos de conceito são iguais a este tipo de banco. Tudo “gira” em torno de objetos, que possuem atributos e propriedades com mais uma gama de recursos para atingir seus objetivos.


33

Existe também uma variação do modelo orientado a objetos “puro”. Ele se chama modelo de dados objeto-relacional, que é um meio termo entre bancos relacionais e bancos orientados a objetos. Elmasri e Navathe (2011) explicam essa nova ideia.

Vendedores de SGBD relacional (SGBDR) também reconheceram a necessidade de incorporar recursos que foram propostos para bancos de dados de objeto, e versões mais novas de sistemas relacionais incorporaram muitos desses recursos. Isso levou a sistemas de bancos de dados que são caracterizados como objeto relacional ou SGBDORs. A versão mais recente do padrão SQL (2008) para SGBDRs inclui muitos desses recursos, que eram conhecidos originalmente como SQL/Object e agora têm sido incorporados na especificação SQL principal, conhecida como SQL/Foundation. (ELMASRI; NAVATHE, 2011, p. 236).

Entretanto, os bancos de dados orientados a objetos ainda não têm um uso massivo em virtude da grande popularidade de sistemas relacionais e objeto relacional. Fernando Amaral faz algumas análises evidenciando essa situação.

Leia a seguir um texto que faz uma análise sobre o motivo pelo qual bancos de dados orientados a objetos não são utilizados em larga escala.

IMPORTANTE

POR QUE NÃO ESTAMOS UTILIZANDO BANCO DE DADOS ORIENTADOS A OBJETOS?

A orientação a objetos, mesmo que não da forma purista encontrada no mundo acadêmico, é uma realidade irreversível no mundo do desenvolvimento de software. Mesmo o próprio Visual Basic, uma das linguagens mais utilizadas do mundo e que sempre foi rotulada como linguagem “para fracos”, sem tipagem e sem qualquer recurso de OO, ganhou, com o lançamento da plataforma. NET, uma versão totalmente reformulada e OO, onde restou pouca semelhança com o VB clássico.

Agora, e quanto ao universo dos Bancos de Dados? A esmagadora maioria dos gerenciadores de banco de dados existentes hoje no mercado são relacionais, e não há qualquer evidência de uma tendência em contrário, ou seja, parece que no futuro vamos continuar utilizando banco de dados relacionais. Porque o mercado de banco de dados continua predominantemente relacional, enquanto utilizamos cada vez mais linguagens de programação OO?


34

O QUE ACONTECEU?

Diante desta indagação, resolvi investigar os motivos, e descobri que são muitos. Inicialmente um bom OODBMS é muito, muito mais caro que um produto relacional “Top” de linha, além disso:

- O modelo relacional é mais simples- O modelo OO não tem a escabilidade de um banco de dados relacional- O modelo OO possui dependência de linguagem: um banco de dados OO deve ser acessado através de uma API específica, normalmente através de uma linguagem específica. Por outro lado, nos OODBMS a linguagem e o banco de dados utilizam os mesmo tipos de dados.- Consultar um banco de dados relacional, devido a sua natureza, é mais simples. Em um banco de dados OO não é possível fazer joins ou consultas “Ad-Hoc”.

Outro fato que não deve ser esquecido é que o modelo relacional é mais antigo, possui uma padronização maior e um maior número de ferramentas. Os bancos de dados OO se mostraram superiores em aplicações específicas, como, por exemplo, CAD, multimídia etc.

CONSEQUÊNCIAS: IMPEDANCE MISMATCH

Então tudo indica que os bancos de dados relacionais vão continuar predominantes por muito tempo, e que, cada vez as linguagens de programação serão OO (repetindo: mesmo que não da forma purista encontrada no mundo acadêmico). Mas como trabalhar corretamente com uma linguagem OO e um banco de dados relacional? Na OO temos objetos, que representam entidades do mundo real e atributos, que são suas características. No modelo relacional temos Entidades (ou tabelas), com atributos (campos). Na OO, o relacionamento entre objetos é através de referências, no relacional, através de chaves primárias e estrangeiras.

A implementação de uma classe terá que contornar todos os problemas desta diferença entre universos tão heterogêneos. Para uma simples classe poderá parecer fácil, mas para um sistema complexo com dezenas ou centenas de classes e relacionamentos, pode virar um pesadelo.

Este conflito objeto X relacional é conhecido com “The Object-Relational Impedance Mismatch”, ou simplesmente Impedance Mismatch, algo como um problema de adaptação, numa tradução livre. Estudos afirmam que a Impedance Mismatch podem consumir até 25 % do tempo de desenvolvimento de um software e ainda prejudicar consideravelmente seu desempenho.


35

O obra Agile Database Techniques: Effective Strategies for the Agile Software Developer, (Scott W. Ambler, ISBN:0471202835), dedica o capítulo 7 de título The Object-Relational Impedance Mismatch a debater esse assunto, e é uma leitura altamente recomendada.

FONTE: Disponível em: <http://www.fernandoamaral.com.br/Default.aspx?Artigo=17>. Acesso em: 22 jan. 2013.

Com o passar do tempo é possível que esta situação mude. Existem grandes iniciativas para que isso aconteça. O cache da empresa Intersystems é um exemplo disto. Outra tendência é que o uso desta tecnologia se limite apenas a situações onde existem dados complexos, como informações geográficas, aplicações que trabalham com imagens, entre outras.

3 ARQUITETURA DE BANCO DE DADOS

3.1 ARQUITETURA CENTRALIZADA

A arquitetura de um banco de dados está diretamente ligada a questões de hardware e sistema computacional existentes na estrutura em questão. O poder de processamento, a estrutura de rede, a memória e diversos outros componentes, são características que fazem parte da análise de toda arquitetura para bancos de dados.

Sendo assim, vamos nos concentrar em quatro tipos de arquitetura: centralizada, cliente-servidor, paralela e distribuída. Cada um destes tipos teve grande importância na história da evolução dos bancos de dados.

Os primeiros bancos de dados estavam implementados nesse tipo de arquitetura. Na década de 1970, eles tinha a implementação centralizada, normalmente em mainframes. Para os usuários acessarem os dados utilizavam terminais sem capacidade de processamento. Esses computadores se conectavam em mainframes (onde era feito todo o processamento) e ali obtinham os dados que necessitavam.

Na arquitetura centralizada, existem duas formas de utilização de sistemas: a multiusuário e a monousuário. A estrutura exposta no parágrafo anterior é um exemplo de sistema multiusuário. Silberschatz, Korth e Sudarshan (2006, p. 527) exemplificam com mais detalhes essas duas formas.


36

Distinguimos duas maneiras como os computadores são usados: como sistemas monousuário e como sistemas multiusuários. Os computadores pessoais e as estações de trabalho caem na primeira categoria. Um sistema monousuário típico é uma unidade de desktop usada por uma única pessoa, normalmente com apenas uma CPU em um ou dois discos rígidos e normalmente somente uma pessoa usando a máquina de cada vez. Um sistema multiusuário típico, por outro lado tem mais discos e mais memória, pode até ter várias CPUs e possui um sistema operacional multiusuário. Ele atende a uma grande quantidade de usuários que estão conectados ao sistema por meio de terminais.

Veremos nos próximos tópicos a evolução das arquiteturas centralizadas.

ESTUDOS FUTUROS

3.2 ARQUITETURA CLIENTE-SERVIDOR

Conforme os computadores pessoais foram evoluindo e o seu custo se tornou menor, a arquitetura centralizada, como era conhecida, teve o seu uso diminuído. Os computadores pessoais substituíram os terminais de acesso e começaram a desempenhar novos papéis. O gerenciamento da interface que antes era responsabilidade do servidor, agora passou a ser gerenciado por clientes.

Em resumo, os sistemas centralizados atualmente respondem requisições que são feitas pelos sistemas clientes. Esse é o conceito de cliente-servidor. A figura a seguir representa graficamente esse conceito.

FIGURA 19 – ARQUITETURA CLIENTE-SERVIDOR

FONTE: Os autores


37

A funcionalidade oferecida pelos servidores de bancos de dados cliente-servidor pode ser dividida em duas partes: o front-end e o back-end. O back-end basicamente controla as estruturas de acesso ao dado, enquanto o front-end faz a interface com o usuário final. A figura a seguir expõe esse cenário.

FIGURA 20 – FUNCIONALIDADE DE FRONT-END E BACK-END

FONTE: Silberschatz, Kort e Sudarshan (2006, p. 529)

Novamente, se você observar a Figura 20, estamos nos referindo a SQL (Structured Query Language). Por hora entenda que SQL é uma linguagem para acesso/manipulação dos dados. A Unidade 3 deste Caderno de Estudos tratará de esclarecer este assunto.

ESTUDOS FUTUROS

3.3 ARQUITETURA PARALELA

É uma arquitetura que tem como objetivo o compartilhamento de recursos para processamento de dados. O texto sobre sistemas paralelos de Silberschatz, Korth e Sudarshan (2006) detalha este conceito.


38

SISTEMAS PARALELOS

Sistemas paralelos melhoram as velocidades de processamento e E/S usando várias CPUs e discos em paralelo. As máquinas paralelas estão se tornando cada vez mais comuns, tornando o estudo de sistemas de banco de dados paralelos cada vez mais importantes. A força motriz por trás dos sistemas de banco de dados paralelos é a demanda de aplicações que precisam consultar bancos de dados extremamente grandes (da ordem de terabytes – ou seja, 10 (12) bytes) ou que tenham de processar um número extremamente grande de transações por segundo (da ordem de milhares de transações por segundo). Os sistemas de bancos de dados centralizados e cliente-servidor não são poderosos o suficiente para lidar com tais aplicações.

No processamento paralelo, muitas operações são realizadas simultaneamente, ao contrário do processamento serial, em que as etapas computacionais são realizadas sequencialmente. Uma máquina paralela com granularidade grossa consiste em um pequeno número de processadores poderosos; uma máquina maciçamente paralela ou paralela com granularidade fina utiliza milhares de processadores menores. A maior parte das máquinas de alto nível hoje em dia oferece algum grau de paralelismo com granularidade grossa; máquinas com dois ou quatro processadores são comuns. Computadores maciçamente paralelos podem ser distinguidos de máquinas paralelas com granularidade grossa pelo grau muito maior de paralelismo que eles admitem. Computadores paralelos, com centenas de CPus e discos, estão disponível comercialmente.

Existem duas medidas principais de desempenho de um sistema de banco de dados: 1) throughput, o número de tarefas que pode ser completado em determinado intervalo de tempo, e 2) tempo de resposta, a quantidade de tempo necessária para completar uma única tarefa desde o momento em que ela foi submetida. Um sistema que processa um grande número de transações pequenas pode melhorar o troughput processando muitas transações em paralelo. Um sistema que processa grandes transações pode melhorar o tempo de resposta e também o troughput realizando subtarefas de cada transação em paralelo.

FONTE: Silberschatz, Korth e Sudarshan (2006, p. 532)

3.4 ARQUITETURA DISTRIBUÍDA

A definição mais básica de sistemas distribuídos é que máquinas diferentes podem estar conectadas entre si através de uma rede de comunicações. O sistema distribuído difere do sistema paralelo na seguinte questão: no paralelo a tendência é que as máquinas fiquem mais próximas, enquanto que no distribuído elas podem estar geograficamente distantes.


39

Date (2003) nos diz que a internet é um exemplo mais óbvio de sistema distribuído, de tal modo que uma única tarefa de processamento de dados possa se estender a várias máquinas da rede.

A figura a seguir mostra um exemplo de arquitetura de bancos de dados distribuída.

FIGURA 21 – ARQUITETURA DE BANCO DE DADOS DISTRIBUÍDA


Rob e Coronel (2011) nos dizem que bancos de dados distribuídos, por sua vez, armazenam o banco relacionado logicamente por dois ou mais locais físicos independentes.

Veja o quadro a seguir, que mostra as vantagens e desvantagens desse modelo de arquitetura.

NOTA


40

QUADRO 1 – VANTAGENS E DESVANTAGENS DE BANCOS DE DADOS DISTRIBUÍDOS

Vantagens

Os dados ficam localizados próximo do local de maior demanda. Os dados em um sistema de banco de dados distribuído são dispersos para atender às necessidades comerciais.

Maior rapidez de acesso aos dados. Os usuários finais costumam trabalhar apenas com um subconjunto dos dados da empresa, armazenado localmente.

Maior rapidez de processamento de dados. Um sistema de gerenciamento de banco de dados distribuídos divide a carga de trabalho do sistema, processando dados em vários locais.

Facilidade de ampliação. É possível adicionar novos locais à rede sem afetar as operações de outros locais.

Aprimoramento das comunicações. Como os sites locais são menores e mais próximos dos clientes, promovem melhor comunicação entre os departamentos e entre os clientes e a equipe da empresa.

Custos operacionais reduzidos. Do ponto de vista dos custos, é mais eficiente adicionar estações de trabalho a uma rede do que atualizar um sistema de mainframe. O trabalho de desenvolvimento é feito de modo mais rápido e barato em PCs de baixo custo do que em mainframes.

Interface amigável. Os PCs e as estações de trabalho costumam ser equipados com interface gráfica de usuário (GUI) fácil de usar. A GUI simplifica o treinamento e utilização dos usuários finais.

Menor risco de falha em ponto único. Quando um componente dos computadores falha, o trabalho é mantido por outras estações. Os dados também são distribuídos em vários locais.

Independência do processador. O usuário final é capaz de acessar todas as cópias disponíveis dos dados e suas solicitações são processadas por qualquer processador no local dos dados.

Desvantagens

Complexidade de gerenciamento e controle. As aplicações devem reconhecer a localização dos dados e ter a capacidade de integrá-los a partir de vários locais. É necessário que os administradores tenham capacidade de coordenar as atividades do banco de dados, evitando sua degradação em função de anomalias.

Dificuldade tecnológica. É necessário tratar e solucionar a integridade dos dados, o gerenciamento de transações, o controle de concorrência, o backup, a recuperação, a otimização de consultas, a seleção do caminho de acesso etc.

Segurança. A probabilidade de falhas de segurança aumenta quando os dados são armazenados em vários locais. A responsabilidade do gerenciamento dos dados será compartilhada por diferentes pessoas em diversos locais.

Falta de padrões. Não há protocolos de comunicação padronizados no nível de banco de dados. (Embora o TCP/IP seja, na prática, um padrão no nível de rede, não há padronização no nível de aplicação.) Por exemplo, diferentes fornecedores de banco de dados empregam técnicas diferentes e geralmente incompatíveis de gerenciamento da distribuição de dados e processamento no ambiente de SGBDD.

Ampliação das necessidades de armazenamento e infraestrutura. São necessárias várias cópias de dados em diferentes locais, exigindo, assim, espaço adicional de armazenamento em disco.

Aumento de custos com treinamento. Os custos com treinamento costumam ser mais elevados em modelos distribuídos do que em centralizados, às vezes a ponto de compensar as economias operacionais e de hardware.

Custos. Os bancos de dados distribuídos exigem infraestrutura duplicada para operar (localização física, ambiente, pessoal, software, licenciamento etc.).



41

GRIDS COMPUTACIONAIS COMO TENDÊNCIA NO PROCESSAMENTO DE BANCOS DE DADOS

Methanias Colaço Júnior

A computação distribuída é uma realidade evidente no contexto dos Sistemas Gerenciadores de Banco de Dados. Neste artigo, apresentaremos o conceito de uma tecnologia distribuída emergente: os Grids Computacionais.

Atualmente, o custo para se ter um banco de dados com capacidade de

terabytes (1024 gigabytes) já não é, relativamente, tão alto. Com a evolução da capacidade de armazenamento, cientistas estão planejando experimentos físicos e simulações que geram arquivos de resultados enormes na ordem de petabytes (1024 terabytes). Essa grande quantidade de dados demanda mais recursos computacionais para ser analisada e ter esses recursos em um único lugar é impraticável.

Esses avanços que a tecnologia tem experimentado, principalmente nas áreas de bancos de dados e de redes de computadores, levaram à ideia de utilizar computadores, independentes e geograficamente dispersos, conectados em uma plataforma para execução de aplicações paralelas. Esta plataforma, chamada comumente de Grid Computacional, apresenta características diferentes das outras plataformas existentes, principalmente devido a sua heterogeneidade (diversidade de computadores), compartilhamento com outros usuários e complexidade.

O termo Grid Computacional vem exatamente da analogia feita à rede elétrica (Electric Power Grid) baseado nas malhas de interligação dos sistemas de distribuição de energia elétrica, nos quais um usuário utiliza a eletricidade sem ao menos saber onde ela foi gerada. Esta representa a infraestrutura que permitirá avanços na computação, de um modo geral, como ocorreu com a rede elétrica. Essa infraestrutura necessita de software específico para monitorar e controlar o ambiente. Segundo Ian Baird, Grid é uma infraestrutura emergente que faz o processamento e o acesso a dados serem possíveis de qualquer lugar e a qualquer horário, sem que alguém seja obrigatoriamente notificado. Em outras palavras, Computação em Grid é uma coleção de recursos heterogêneos e distribuídos, possibilitando que os mesmos sejam utilizados em grupo para executar aplicações de larga escala.



42

Neste momento, vocês podem estar se perguntado: “Mas qual a diferença dos Grids para a computação distribuída tradicional?” A diferença se dá pelo fato de que a computação distribuída é um conceito que vem dos anos 80 e 90, consistindo na possibilidade de resolver um determinado problema computacional através da utilização de diferentes recursos distribuídos geograficamente. A computação distribuída passa a ser uma “Computação em Grade” no momento em que existe uma infraestrutura física e uma infraestrutura lógica (software) que permita coordenar os trabalhos que vão ser processados e garantir a sua qualidade de serviço. Os Grids são uma evolução da computação distribuída, uma vez que eles são orientados essencialmente para aplicações que precisam de uma grande capacidade de cálculos e/ou enormes quantidades de dados transmitidos de um lado para o outro.

Não podemos imaginar que a tecnologia em Grid é uma panaceia (resolução

de todos os problemas neste contexto), pois se imaginarmos uma aplicação sendo executada paralelemente em diversos pontos, é fácil visualizar a necessidade de divisão da mesma em partes coordenadas e interdependentes que necessitarão de alteração de código. Além disso, é necessário consolidar soluções de níveis de prioridade para acesso aos recursos da rede. Contudo, as pesquisas sobre Grids permitirão que empresas acessem e compartilhem bases de dados de forma remota, o que é essencialmente benéfico para as ciências da saúde ou comunidades de pesquisa, cujos volumes grandiosos de dados são gerados e analisados durante todo o dia. Já imaginaram o fato de uma empresa que possui filiais em países com fusos diferentes poder usar, durante o dia, o poder de processamento dos computadores da filial no Japão, ociosos neste horário por ser noite? Este é o futuro com a evolução da computação distribuída. SGBDs como o Oracle já começam a apresentar características de processamento baseadas em Grids Computacionais. Em um próximo artigo, descreveremos as novas características do Oracle 10g baseadas nesta tecnologia.

FONTE: Disponível em: <http://www.devmedia.com.br/grids-computacionais-como-tendencia-no-processamento-de-bancos-de-dados/1382>. Acesso em: 24 jan. 2013.

43

RESUMO DO TÓPICO 2


• O histórico da evolução dos bancos de dados foi dividido em três gerações.

• Existem vários tipos de arquiteturas de bancos de dados e cada um possui particularidades que devem ser estudados durante o processo de escolha.

• A arquitetura cliente-servidor é amplamente utilizada inclusive nos dias de hoje.

44

1 Diferencie a primeira geração da segunda no histórico da evolução dos bancos de dados.

2 Explique como foi a terceira geração de bancos de dados.

3 Segundo o que foi estudado neste Caderno de Estudos, quando se fala em arquitetura de bancos de dados, quais são os fatores ou itens que devem ser analisados?

4 Descreva o que vem a ser uma arquitetura de banco de dados centralizada.

5 Cite a principal diferença entre as arquiteturas paralelas e distribuídas.

AUTOATIVIDADE

45

TÓPICO 3

TENDÊNCIAS E PERSPECTIVAS

UNIDADE 1

1 INTRODUÇÃO“Nossas dúvidas são traidoras e nos fazem perder o que, com

frequência, poderíamos ganhar, por simples medo de arriscar.” (William Shakespeare)

Agora que você já tem uma boa fundamentação sobre bancos de dados, suas origens, sua evolução e suas arquiteturas, chegou a hora de estudarmos as possíveis tecnologias que são apontadas como tendência para o futuro. Será percebido que algumas delas já fazem parte do cotidiano em algumas áreas, porém ainda precisam evoluir.

FIGURA 22 – NOVAS TECNOLOGIAS EM BANCOS DE DADOS

FONTE: Disponível em: <http://www.devmedia.com.br/introducao-aos-bancos-de-dados-nosql/26044>. Acesso em: 23 dez. 2012.

Vamos estudar, inicialmente, os tipos de bancos de dados que servem para trabalhar com dados complexos em cenários como georeferenciamento, biologia, entre outros. Também veremos conceitos de gerenciamento e mineração de dados para geração de informações. Por último, dois novos conceitos no mundo de bancos de dados: NoSQL e Big Data. Bons estudos!

46


2 CLASSIFICAÇÃO DOS BANCOS DE DADOS

2.1 BANCOS DE DADOS DE INFORMAÇÕES GEOGRÁFICAS

Até o presente momento estudamos bancos de dados sob uma ótica do modelo relacional. Este é largamente utilizado e muito difundido em vários sistemas considerados “tradicionais” como ERPs, CRMs, E-commerce etc.

Porém, existem sistemas com uma abrangência mais específica que norteiam áreas mais delimitadas. É o caso do armazenamento e manipulação de informações geográficas ou também de arquivos que necessitam de uma organização em nível de bancos de dados.

Esse é o foco do nosso estudo nesta seção. Está dividido em sete áreas: bancos de dados de informações geográficas, multimídia, temporal, biológico e XML. Cada uma dessas áreas será estudada e exemplificada.

Este tipo de banco de dados tem como objetivo armazenar e manipular dados geométricos que sejam pertinentes a representações de partes do planeta. Também é conhecido como Sistema Gerenciador de Bancos de Dados Geográficos ou simplesmente SGBDG. Em resumo, armazena dados geográficos como mapas, imagens de satélite etc.

FIGURA 23 – OBJETO QUE PODE SER REPRESENTADO POR UM SGBDG

FONTE: Disponível em: <http://www.mobypicture.com/user/patrickitj/view/9762284>. Acesso em: 15 dez. 2012.

Alguns bancos que são de natureza relacional permitem que sejam instalados pacotes para que tipos de dados geográficos sejam suportados. Um exemplo disto é uma extensão que pode ser adicionada no banco PostgreSQL para habilitar suporte a dados espaciais. O nome dela é PostGIS e sua ideia é ilustrada na figura a seguir.

TÓPICO 3 | TENDÊNCIAS E PERSPECTIVAS

47

FIGURA 24 – EXTENSÃO ESPACIAL DO POSTGRESQL

FONTE: Disponível em: <http://www.infoescola.com/informatica/banco-de-dados-geograficos/>. Acesso em: 15 dez. 2012.

O texto a seguir trata sobre representação geral de informações geográficas. Nele, procura-se detalhar com maior riqueza de detalhes, o paradigma de bancos de dados geográficos.

UNI

DESCRIÇÃO GERAL DE SISTEMAS DE INFORMAÇÃO GEOGRÁFICA

O termo sistemas de informação geográfica (SIG) é aplicado para sistemas que realizam o tratamento computacional de dados geográficos. A principal diferença de um SIG para um sistema de informação convencional é sua capacidade de armazenar tanto os atributos descritivos como as geometrias dos diferentes tipos de dados geográficos. Assim, para cada lote num cadastro urbano, um SIG guarda, além de informação descritiva como proprietário e valor do IPTU, a informação geométrica com as coordenadas dos limites do lote. A partir destes conceitos, é possível indicar as principais características de SIGs:

• Inserir e integrar, numa única base de dados, informações espaciais provenientes de meio físico-biótico, de dados censitários, de cadastros urbano e rural, e outras fontes de dados como imagens de satélite, e GPS.

• Oferecer mecanismos para combinar as várias informações, através de algoritmos de manipulação e análise, bem como para consultar, recuperar e visualizar o conteúdo da base de dados geográficos.

48


Os componentes de um SIG estão mostrados na Figura 1.1. No nível mais próximo ao usuário, a interface homem-máquina define como o sistema é operado e controlado. Esta interface pode ser tanto baseada na metáfora da “mesa de trabalho” (Kuhn e Frank, 1991) (Richards e Egenhofer, 1995) (Câmara, 1999), como adaptada ao ambiente de navegação da Internet (Kraak e Brown, 2001), quanto baseada em linguagens de comando como Spatial SQL (Egenhofer, 1994) e LEGAL (Câmara, 1995). No nível intermediário, um SIG deve ter mecanismos de processamento de dados espaciais. A entrada de dados inclui os mecanismos de conversão de dados (Hohl, 1998). Os algoritmos de consulta e análise espacial incluem as operações topológicas (Egenhofer e Franzosa, 1991), álgebra de mapas (Tomlin, 1990), estatística espacial (Druck et al., 2004), modelagem numérica de terreno (Li et al., 2004) e processamento de imagens (Mather, 2004). Os mecanismos de visualização e plotagem devem oferecer suporte adequado para a apreensão cognitiva dos aspectos relevantes dos dados pesquisado (MacEachren, 2004) (Tufte, 1983) (Monmonier, 1993). No nível mais interno do sistema, um sistema de gerência de bancos de dados geográficos oferece armazenamento e recuperação dos dados espaciais e seus atributos. Cada sistema, em função de seus objetivos e necessidades, implementa estes componentes de forma distinta, mas todos os subsistemas citados devem estar presentes num SIG.

Do ponto de vista da aplicação, o uso de sistemas de informação geográfica (SIG) implica escolher as representações computacionais mais adequadas para capturar a semântica de seu domínio de aplicação. Do ponto de vista da tecnologia, desenvolver um SIG significa oferecer o conjunto mais amplo possível de estruturas de dados e algoritmos capazes de representar a grande diversidade de concepções do espaço.

FONTE: Disponível em: <http://www.dpi.inpe.br/livros/bdados/cap1.pdf>. Acesso em: 11 set. 2012.


49

2.2 BANCOS DE DADOS MULTIMÍDIA

Dados multimídia são cada vez mais populares. Com o advento da internet a troca de dados multimídia expandiu-se. Entretanto, imagens, vídeo e audio estão hoje, na maioria das vezes, armazenados em sistemas de arquivos. Esse fato não vem a ser um problema quando se trabalha com um volume reduzido de dados, considerando que um banco não iria trazer grandes benefícios. Porém, com muitos arquivos uma forma de armazenamento em banco facilitaria o gerenciamento dos mesmos.

Boa parte dos principais bancos de dados implementam um tipo de dado binário para armazenar dados multimídia. Isso faz com que essa forma de armazenamento se resuma apenas em salvar arquivos no banco, não trazendo muitas vantagens comparadas com o armazenamento em sistemas em arquivos.

Um banco de dados multimídia precisa ter algumas características como suporte a objetos gigantes (muito mais que alguns gigabytes), fornecimento dos dados em um ritmo constante (um vídeo precisa ser fornecido sem lacunas durante sua exibição) e recuperação baseada na semelhança.

O texto a seguir detalha a necessidade e a motivação para a recuperação baseada em semelhança.

UNI

RECUPERAÇÃO BASEADA EM SEMELHANÇA

Dados de imagem. Duas figuras ou imagens que são ligeiramente diferentes, conforme representadas no banco de dados, podem ser consideradas iguais por um usuário. Por exemplo, um banco de dados pode armazenar um projeto de marca comercial. Quando uma marca comercial deve ser registrada, o sistema pode precisar primeiro identificar todas as marcas comerciais semelhantes que foram registradas anteriormente.

Dados de áudio. Interfaces de usuário baseadas em fala estão sendo

desenvolvidas para permitir que o usuário dê um comando ou identifique um item de dados pela fala. A entrada do usuário precisa então ser testada por semelhança com aqueles comandos ou itens de dados armazenados no sistema.

Dados escritos à mão. A entrada escrita à mão pode ser usada para identificar um item de dados ou comando escrito à mão, armazenado no banco de dados. Aqui, novamente, o teste de semelhança é exigido.

50


A noção de semelhança normalmente é subjetiva e específica do usuário. Porém, o teste de semelhança normalmente é mais bem-sucedido do que o reconhecimento de voz ou escrita manual, pois a entrada pode ser comparada com dados já no sistema e, assim, o conjunto de opções disponíveis ao sistema é limitado.

Existem vários algoritmos para encontrar as melhores combinações de determinada entrada pelo teste de semelhança. Alguns sistemas, incluindo a discagem por nome, sistema de telefone ativado por voz, foram implantados comercialmente.

FONTE: Silberschatz, Korth e Sudarshan (2006, p. 620)

Para resumir e exemplificar uma das principais características que um banco de dados multimídia precisa ter. Vamos pensar em um arquivo cujo conteúdo é uma imagem. Quando trabalhamos com imagens, o sistema deve conseguir identificar algumas particularidades delas. Por exemplo, listar todas as imagens de um pôr de sol ou talvez todas as que contenham barcos cuja cor é branca. Para isso ser possível é necessário identificar a semântica da imagem, ou seja, o que significa e qual o seu conteúdo. Este conceito também é válido para áudio e vídeo.

2.3 BANCO DE DADOS TEMPORAL

Em um conceito resumido, podemos dizer que um banco de dados temporal armazena o estado de um determinado objeto, procurando obter toda a sua evolução. Fazendo uma junção deste conceito com os bancos de dados relacionais, pode-se entender que o objeto pode ser uma tabela.

As aplicações rotineiras se preocupam normalmente em registrar quando determinado fato ocorreu. Um banco de dados temporal se preocupa com todo o histórico de todos os fatos. Isso pode ser confeccionado com base em intervalos de datas ou intervalo de validade das informações.

Cabe ao projetista de banco de dados definir o formato de gerenciamento dos dados de forma temporal. Alguns tipos de sistemas que podem consumir um banco de dados temporal são: BI (Sistema de suporte a decisões ou Bussiness Intelligence), SIGs (Sistemas de Informações Gerenciais) etc.

Alguns SGBDs fornecem meios para o desenvolvimento de bancos temporais. Entre eles, existe um grande destaque por parte da Oracle, com o Time Series Cartridge.


51

2.4 BANCOS DE DADOS BIOLÓGICOS

Tendo em vista que existem vários estudos desenvolvidos no campo da biologia, existe a necessidade de documentá-los e armazená-los em locais seguros. Esse é o conceito de bancos de dados biológico. Alguns são públicos, outros privados. Podem oferecer também integração com outros bancos de dados.

O site <http://pt.scribd.com/doc/58841709/Banco-de-Dados-biologico> traz alguns exemplos de bancos de dados biológicos.

UNI

Projeto GMOD

“O Generic Model Organism Database Project é um projeto open source, cujo objetivo é desenvolver um conjunto completo de softwares para a criação e administração de um banco de dados biológico”. GMOD (2004). Financiado pelo NIH (National Instituteof Health) e pelo USDA Agricultural Research Service.

Citrina O Citrina consiste em uma ferramenta de gerência que permite automatizar

o espelhamento e processamento de bancos de dados que estão distribuídos através de diversos servidores FTP. A mesma foi desenvolvida através da tecnologia Java Ant, o que a torna mais flexível e portável.

Um exemplo de uso para o Citrina seria a transferência de Chado SQL

entre vários sites de organismos e a população automática dos diversos bancos de dados PostgreSQL através dos recursos de SQL fornecidos pela tecnologia Java Ant.

BioMart Sistema de Integração de dados orientado a consultas, baseado na ideia

de Data Warehouse. Sistema de Consultas desenvolvido especificamente para uso de grandes

bancos de dados. Simplifica a tarefa de integração entre diferentes bancos de dados distribuídos pela rede.

52


Chado

Segundo Chado (2004), consiste em um “... conjunto de módulos de um esquema destinados à construção de um esquema de banco de dados biológico relacional....”

O Chado foi desenvolvido com o intuito de ser aplicado, especificamente, a um banco de dados open source, como é o caso do PostGreSQL (PostgreSQL, 2004) e do MySQL (MySQL, 2004). Além disso, outro pré-requisito para o funcionamento eficiente do Chado é a configuração de diversos pacotes BioPerl (BioPerl, 2004).

O Chado está sendo utilizado atualmente pelo FlyBase (FlyBase, 2004) e pelo Berkeley Drosophila Genome Project (BDGP, 2004).

O Chado, o qual constitui um dos subprojetos do GMOD, apresenta-se como um esquema mais simples e genérico para a representação de dados biológicos. Este esquema ainda se encontra em desenvolvimento, o que pode ser verificado na grande simplicidade nos módulos responsáveis pela representação de mapas genéticos, interações genéticas e expressão gênica.

Todos os dados resultantes das análises de um projeto genoma são armazenados nos chamados bancos de dados biológicos. Inicialmente, cada laboratório desenvolveu o seu próprio banco de dados, contemplando somente as necessidades do projeto genoma por ele sendo executado.

Um banco de dados genômico para os biólogos geralmente é um web site que apresenta informações que muitas vezes estão armazenadas em arquivos texto.

Outras vezes, os dados podem até estar em SGBDs, mas isto só começou a se tornar realidade há poucos anos. Por exemplo, o www.plasmodb.org, um “banco de dados genômico” do Plasmodium (causador da malária) usa dados armazenados tanto em arquivos texto quanto em Oracle. A migração vem se dando há pouco tempo.

O banco de dados biológico mais famoso é o GenBank.

FONTE: Disponível em: <http://pt.scribd.com/doc/58841709/Banco-de-Dados-biologico>. Acesso em: 24 dez. 2012.


53

2.5 BANCO DE DADOS XML

O XML (Extensible Markup Language) é uma linguagem de marcação extensível criada em 1996. Pode ser utilizada para troca, compartilhamento e armazenamento de dados.

Rob e Coronel (2011, p.615) fazem um relato do cenário onde a XML pode estar envolvida.

A internet fez surgir novas tecnologias que facilitam a troca de dados de negócios entre parceiros comerciais e clientes. As empresas têm utilizado a internet para criar novos tipos de sistemas que integrem seus dados de modo a aumentar a eficiência e reduzir custos. O comércio eletrônico (e-commerce) permite que todos os tipos de organizações vendam produtos e serviços em um mercado global de milhões de usuários. As transações de comércio eletrônico – venda de produtos ou serviços – podem ser executados entre empresas (business-to-business ou B2B) ou entre uma empresa e um cliente (business-to-consumer ou B2C).A maioria dessas transações ocorre entre empresas. Como o comércio eletrônico B2B integra processos de negócios entre empresas, ele exige a transferência de informações comerciais entre as diferentes entidades. Mas o modo como os dados são representados, identificados e utilizados tende a diferir significativamente de empresa para empresa [...].

De uma forma bem resumida, pode-se dizer que XML consiste em descrever o conteúdo dos campos em um formato de marcação. É amplamente utilizado na internet para integração entre sistemas.

A figura a seguir mostra um exemplo de XML.

FIGURA 25 – EXEMPLO XML

FONTE: Disponível em: <http://blog.kirupa.com/?p=227>. Acesso em: 27 jan. 2013.

54


3 TIPOS DE GERENCIAMENTO DE DADOSNo cenário em que vivemos hoje, as empresas precisam estar preparadas e

“munidas” de informações que possam gerar valor competitivo para o seu negócio. Para que isso aconteça, precisamos de uma forma de analisar os dados disponíveis nos seus sistemas a fim de gerar informação e conhecimento. Vale a pena lembrar-se do que foi apresentado no início desta unidade: a partir dos dados são geradas informações e a interpretação dessas informações gera conhecimento.

FIGURA 26 – DADOS SÃO UTILIZADOS PARA GERAR INFORMAÇÃO

FONTE: Disponível em: <http://gestorsistemas.info/content/?secao=data_mining>. Acesso em: 27 jan. 2013.

Rob e Coronel (2011, p. 535) fazem um relato sobre a necessidade de análise e gerenciamento de dados analisados.


55

As organizações tendem a crescer e prosperar quando obtêm melhor compreensão de seu ambiente. A maioria dos gerentes deseja rastrear as transações diárias para avaliar o fluxo dos trabalhos. Recorrendo ao banco de dados operacional, a gerência pode desenvolver estratégias que atendam as metas organizacionais. Além disso, a análise dos dados pode fornecer informações sobre estratégias e avaliações táticas de curto prazo como as seguintes: nossas promoções de vendas estão funcionando? Que porcentagem do mercado controlamos? Estamos atraindo novos clientes? As decisões táticas e estratégicas também são moldadas por uma pressão constante de forças externas e internas, incluindo a globalização, o ambiente legal, cultural e (talvez o mais importante) a tecnologia.

Esta seção trata de formas de analisar e gerar informações e conhecimento acerca de um determinado negócio. Esse processo também pode ser denominado de estudo de atividades para gerar informações de apoio à decisão. Envolve os seguintes itens que serão posteriormente estudados: Data Mining, Data Warehouse, Data Mart e Data Marketing.

3.1 DATA MINING

Data Mining ou mineração de dados é um dos primeiros processos que são executados a fim de construir uma nova base de dados que gere conhecimento e informações de apoio à decisão.

FIGURA 27 – PROCESSOS DE DATA MINING

FONTE: Disponível em: <http://imasters.com.br/artigo/10229/tecnologia/mineracao-de-dados-e-web-semantica/>. Acesso em: 27 jan. 2013.

56


Rob e Coronel (2011) nos dizem que o banco de dados de suporte a decisões é criado, em grande parte, pela extração de dados do banco operacional e pela importação de dados adicionais de fontes externas. Isso significa que as empresas já possuem seus sistemas de gerenciamento e extraem os dados dos mesmos para buscar padrões que sejam valiosos para o ramo do negócio.

O texto disponível em: <http://www.intelliwise.com/reports/i2002.htm> elucida de forma mais pormenorizada o que vem a ser um Data Mining. Ele também traz alguns termos que serão vistos em seguida, como Data Warehouse e Data Mart.

UNI

Data Mining é uma das novidades da Ciência da Computação que veio para ficar. Com a geração de um volume cada vez maior de informação, é essencial tentar aproveitar o máximo possível desse investimento. Talvez a forma mais nobre de se utilizar esses vastos repositórios seja tentar descobrir se há algum conhecimento escondido neles. Um banco de dados de transações comerciais pode, por exemplo, conter diversos registros indicando produtos que são comprados em conjunto. Quando se descobre isso, pode-se estabelecer estratégias para otimizar os resultados financeiros da empresa. Essa já é uma vantagem suficientemente importante para justificar todo o processo. Contudo, embora essa ideia básica seja facilmente compreensível, fica sempre uma dúvida sobre como um sistema é capaz de obter esse tipo de relação. No restante deste artigo vamos observar alguns conceitos que podem esclarecer essas dúvidas.

O que é Data Mining?

Talvez a definição mais importante de Data Mining tenha sido elaborada por Usama Fayyad (Fayyad et al. 1996):

“[...] o processo não trivial de identificar, em dados, padrões válidos, novos, potencialmente úteis e ultimamente compreensíveis”.

Esse processo vale-se de diversos algoritmos (muitos deles desenvolvidos recentemente) que processam os dados e encontram esses “padrões válidos, novos e valiosos”. É preciso ressaltar um detalhe que costuma passar despercebido na literatura: embora os algoritmos atuais sejam capazes de descobrir padrões “válidos e novos”, ainda não temos uma solução eficaz para determinar padrões valiosos. Por essa razão, Data Mining ainda requer uma interação muito forte com analistas humanos, que são, em última instância, os principais responsáveis pela determinação do valor dos padrões encontrados.


57

Além disso, a condução (direcionamento) da exploração de dados é também tarefa fundamentalmente confiada a analistas humanos, um aspecto que não pode ser desprezado em nenhum projeto que queira ser bem sucedido.

Os passos do Data Mining

A literatura sobre o assunto trata com mais detalhes todos os passos necessários ao Data Mining. Veja, por exemplo, Groth (1998) e Han, Chen & Yu (1996). Para o escopo do que pretendemos neste artigo é suficiente apresentar os passos fundamentais de uma mineração bem sucedida. A partir de fontes de dados (bancos de dados, relatórios, logs de acesso, transações, etc.) efetua-se uma limpeza (consistência, preenchimento de informações, remoção de ruído e redundâncias etc.). Disto nascem os repositórios organizados (Data Marts e Data Warehouses), que já são úteis de diversas maneiras.

Mas é a partir deles que se pode selecionar algumas colunas para atravessarem o processo de mineração. Tipicamente, este processo não é o final da história: de forma interativa e frequentemente usando visualização gráfica, um analista refina e conduz o processo até que valiosos padrões apareçam. Observe que todo esse processo parece indicar uma hierarquia, algo que começa em instâncias elementares (embora volumosas) e terminam em um ponto relativamente concentrado, mas muito valioso.

58


Este é um dos conceitos importantes para nós neste artigo: encontrar padrões requer que os dados brutos sejam sistematicamente "simplificados" de forma a desconsiderar aquilo que é específico e privilegiar aquilo que é genérico. Faz-se isso porque não parece haver muito conhecimento a extrair de eventos isolados. Uma loja de sua rede que tenha vendido a um cliente em particular uma quantidade impressionante de um determinado produto em uma única data pode apenas significar que esse cliente em particular procurava grande quantidade desse produto naquele exato momento. Mas isso provavelmente não indica nenhuma tendência de mercado.

Em outras palavras, não há como explorar essa informação em particular para que no futuro a empresa lucre mais. Apenas com conhecimento genérico é que isto pode ser obtido. Por essa razão devemos, em Data Mining, controlar nossa vontade de "não perder dados". Para que o processo dê certo, é necessário sim desprezar os eventos particulares para só manter aquilo que é genérico.

FONTE: Disponível em: <http://www.intelliwise.com/reports/i2002.htm>. Acesso em: 24 dez. 2012.

3.2 DATA WAREHOUSE

Resumidamente, podemos dizer que um Data WareHouse é um banco de dados que possui todos os dados da organização que são pertinentes para uma futura análise. Rob e Coronel (2011) explicam que Data WareHouse normalmente é um banco de dados apenas de leitura, otimizado para processamento de análises e consultas. Geralmente, os dados são extraídos de várias fontes e, em seguida, transformados e integrados.

É conhecido também como armazém de dados por reunir dados de vários sistemas distintos. Nas organizações é comum existirem sistemas específicos para algumas áreas, como por exemplo, folha de pagamento, faturamento, vendas etc. Quando chega o momento de responder a algumas perguntas, é muito complicado ir a cada sistema e pesquisar os dados relacionados. Por isso, através de um processo de Data Mining é gerado um Data WareHouse com os dados da empresa.

Tudo é feito para melhorar a tomada de decisão das empresas. O texto a seguir mostra como isso é possível.

UNI


59

COMO UM DATA WAREHOUSE PODE MELHORAR A TOMADA DE DECISÃO NAS EMPRESAS?

A principal proposta do data warehouse é colocar nas mãos dos analistas de negócios dados estratégicos para as tomadas de decisões baseadas em fatos reais e não por intuição. A produtividade oferecida pelo data warehouse é traduzida em ganho de tempo e dinheiro. Na construção de um banco de dados para suporte a um data warehouse são filtrados e normalizados os dados de vários bancos de dados dos sistemas estruturados, formando uma base de dados com todos os dados relevantes da empresa ou de uma área específica. Com o cruzamento desses dados extraem-se informações que os sistemas de informações estruturados não conseguem identificar. O banco Itaú enviava cerca de um milhão de malas diretas para seus correntistas e obtinha apenas 2% de retorno, após a implantação do data warehouse o retorno passou para 30% e a conta do correio diminuiu para um quinto.

Em muitas empresas quando um executivo faz uma pergunta sobre o perfil dos seus negócios fora de um padrão definido pelos analistas de sistemas o tempo e o esforço para respondê-la é muito grande. Várias bases de dados devem ser consultadas, programas de pesquisas são construídos, download de arquivos para microcomputadores para manipulação dos dados e gerar relatórios gráficos. Se uma decisão deve ser tomada acompanhando a velocidade do mercado, o executivo acaba tomando a decisão por intuição não podendo esperar o resultado da área de sistemas.

Quando o assunto é simulação de cenários de negócios o processo é ainda mais traumático. Os sistemas estruturados atuais não são suficientemente flexíveis para traçar cenários complexos usando cruzamento de vários componentes. Os bancos de dados tradicionais possuem visão bidimensional, por exemplo, enxergam uma tabela de produto por região. As ferramentas de data warehouse possuem a visão de uma tabela multidimensional, por exemplo, geram uma tabela de produto x região x período de tempo.

Os data warehouses já colecionam muitas estórias de sucesso. A clássica foi o resultado obtido pela rede americana de supermercados Wal-Mart quanto o seu data warehouse identificou uma relação entre o consumo de fraldas descartáveis e o consumo de cerveja. Analisando a informação do data warehouse verificou-se que quando os maridos iam ao supermercado à noite para comprar fraldas aproveitavam e compravam algumas cervejas. Constatado o fato, elaborou-se uma estratégia de vendas onde as fraldas ficam próximas as cervejas, induzindo os maridos a comprarem as cervejas. O resultado foi o aumento de vendas das cervejas. Outro exemplo é o caso da empresa de telecomunicações americana Sprint que com o seu data warehouse consegue identificar com 60 dias de antecedência os usuários que trocaram seus serviços por outra operadora. Através de um marketing agressivo ela conseguiu evitar a deserção de 120.000 clientes e uma perda de 35 milhões de dólares em faturamento.

60


A introdução de um data warehouse em uma empresa exige uma mudança de comportamento dos executivos e sua relação entre os computadores e as informações. Os data warehouse mantêm um quadro único e coerente das informações ao longo da empresa, uma única versão da verdade, trazendo produtividade e ganho de dinheiro.

FONTE: Disponível em: <http://www.efagundes.com/artigos/Como%20um%20data%20warehouse%20pode%20melhorar%20as%20tomadas%20de%20decisoes%20nas%20empresas.htm>. Acesso em: 24 dez. 2012.

3.3 DATA MART

3.4 DATA MARKETING

Com o passar dos anos, foi percebido que os usuários responsáveis por extrair informações dos Data WareHouses usavam uma pequena parte dele para realizar o seu trabalho. Neste mesmo conjunto era preciso criar novas visões e executar os mesmos procedimentos de forma repetitiva a cada atualização recebida. É nesse cenário que surge a definição de Data mart.

Para Date (2003), Data Mart é um depósito de dados especializado, orientado por assunto, integrado, volátil e variável no tempo, que fornece apoio a um subconjunto específico de decisões da gerência. É um agrupamento de dados e informações dentro do Data WareHouse com um objetivo específico e bem definido.

Em uma definição bem simplista, pode-se dizer que é um banco de dados utilizado para relacionamento com clientes. É nele que estão os dados utilizados para atingir objetivos de venda, público alvo para promoções etc.

O texto disponibilizado no site <http://www.benic.com.br/marketing-digital/blog/o-que-e-database-marketing> deixa claro quais são os benefícios da utilização deste conceito.

UNI


61

O QUE É DATABASE MARKETING

Caso a sua empresa queira adotar estratégias de retenção de clientes, fundamentadas no Marketing de Relacionamento, é imprescindível que possua tecnologia que possibilite desenvolver com eficácia essas estratégias.

A base do Marketing de Relacionamento é a personalização do relacionamento com os clientes, mas como realizar esta personalização se sua empresa possuiu milhares e até milhões de clientes em um único ano? É impossível imaginar alguma estratégia de Marketing de Relacionamento sem contemplar a área de Tecnologia da Informação.

Somente com o uso da Tecnologia é possível armazenar, recuperar, processar, comunicar e analisar os dados dos seus clientes. Ter um banco de dados com as informações dos clientes é condição primordial para o desenvolvimento de uma estratégia de Marketing de Relacionamento.

Este banco de dados, criado para armazenar as informações sobre os seus consumidores, é chamado de Database Marketing (DBM).

O Database Marketing é uma ferramenta para utilização das informações internas e externas para filtrar o mercado alvo, desenvolver o planejamento de vendas inteligentes e mensagens de promoções e de marketing que sejam relevantes.

FONTE: Disponível em: <http://www.benic.com.br/marketing-digital/blog/o-que-e-database-marketing>. Acesso em: 24 dez. 2012.

4 NOVOS CONCEITOSEsta última seção da Unidade 1 tem como objetivo apenas introduzir

alguns novos conceitos existentes no mercado. Entenda que estamos tratando de novas tecnologias e que muitas delas ainda não chegaram ao seu ápice de desenvolvimento e utilização. Isso pode significar que poderão sofrer alterações quando a sua definição e aplicação durante este período de amadurecimento.

Trataremos apenas de dois novos conceitos: Big Data e NoSQL. Vamos focar apenas no paradigma das tecnologias, passando de forma superficial por questões técnicas de implementação.

62


4.1 BIG DATA

Muito tem se falado sobre essa nova tecnologia. Ela visa atender basicamente ao gerenciamento de grandes volumes de dados. Imagine a quantidade de dados gerados por tweets no mundo inteiro. Agora pense no seguinte: esses dados podem revelar muitas coisas a respeito de um determinado cenário. Através da análise deles é possível, de certa forma, medir o nível de felicidade de uma determinada população, a satisfação das pessoas em relação a determinado produto comercializado por alguma empresa, entre várias outras situações.

Várias empresas já utilizam o conceito de Big Data em seus negócios. A figura a seguir dá uma visão geral do conceito.

FIGURA 28 – CENÁRIO ATUAL DO BIG DATA

FONTE: Disponível em: <http://oglobo.globo.com/infograficos/bigdata/>. Acesso em: 27 jan. 2013.


63

Um texto publicado na Info Abril: <http://info.abril.com.br/noticias/computacao-inteligente/aplicativo-de-big-data-e-tendencia-nas-corporacoes-diz-especialista-07012013-20.shl>, destaca a tendência de utilização do Big Data nas empresas.

UNI

APLICATIVO DE BIG DATA É TENDÊNCIA NAS CORPORAÇÕES, DIZ ESPECIALISTA

São Paulo – Uma pesquisa da IBM mostra que 90% de todos os dados divulgados na internet surgiram nos últimos dois anos. Além disso, as corporações de diferentes áreas digitalizam e compartilham documentos na web diariamente.

Segundo Ederson Riechelmann, diretor de outsourcing da Unione, é necessário usar aplicativos de Big Data (BDA) para organizar e usar todos estes dados. Ainda de acordo com o especialista, o uso destes apps é certamente uma tendência nas corporações.

As áreas que possuem urgência em usar estes apps são a comercial e de marketing. É possível, por exemplo, usar esta tecnologia para cruzar os dados e descobrir a rotina e os gastos mensais de um cliente e personalizar anúncios direcionados a ele.

Riechelmann explica que a área de segurança também é influenciada positivamente pelo avanço no mercado de aplicativos de Big Data.

Seria inviável comercializar estes apps sem uma forte barreira contra crackers e hackers. O especialista afirma que os todos esses resultados em usar estas aplicações (BDA) serão notados em curto prazo.

FONTE: Disponível em: <http://info.abril.com.br/noticias/computacao-inteligente/aplicativo-de-big-data-e-tendencia-nas-corporacoes-diz-especialista-07012013-20.shl>. Acesso em: 27 jan. 2013.

Como acontece com qualquer nova tecnologia, o mercado de trabalho carece de profissionais para trabalhar com Big Data. Existe bastante material informativo na internet, porém boa parte está disponível em inglês. O site <BigDataUniversity.com> oferece cursos online e gratuitos sobre Big Data e pode ser uma boa opção para quem domina a língua.

64


4.2 NOSQL

NoSQL é uma classe de bancos de dados que tem como principal destaque o rompimento com o paradigma relacional, predominante durante vários anos no mercado de TI. Ele representa vários bancos de dados que não são relacionais e utilizam outras formas de organização, visando armazenamento e processamento de dados complexos.

O texto disponível no site <http://imasters.com.br/artigo/17043/banco-de-dados/nosql-voce-realmente-sabe-do-que-estamos-falando/> esclarece de forma mais aprofundada o que é NoSQL.

UNI

O termo NoSQL foi usado pela primeira vez em 1998, como o nome de um banco de dados relacional de código aberto que não possuía um interface SQL. Seu autor, Carlo Strozzi, alega que o movimento NoSQL “é completamente distinto do modelo relacional e, portanto, deveria ser mais apropriadamente chamado ‘NoREL’ ou algo que produzisse o mesmo efeito”. Porém, o termo só voltou a ser assunto em 2009, por um funcionário do Rackspace, Eric Evans, quando Johan Oskarsson, da Last.fm, queria organizar um evento para discutir bancos de dados open source distribuídos.

NoSQL são diferentes sistemas de armazenamento que vieram para suprir necessidades em demandas onde os bancos de dados tradicionais (relacionais) são ineficazes. Muitas dessas bases apresentam características muito interessantes como alta performance, escalabilidade, replicação, suporte a dados estruturados e subcolunas.

O NoSQL surgiu da necessidade de uma performance superior e de uma alta escalabilidade. Os atuais bancos de dados relacionais são muito restritos a isso, sendo necessária a distribuição vertical de servidores, ou seja, quanto mais dados, mais memória e mais disco um servidor precisa. O NoSQL tem uma grande facilidade na distribuição horizontal, ou seja, mais dados, mais servidores, não necessariamente de alta performance. Um grande utilizador desse conceito é o Google, que usa computadores de pequeno e médio porte para a distribuição dos dados; essa forma de utilização é muito mais eficiente e econômica. Além disso, os bancos de dados NoSQL são muito tolerantes a erros.


65

FONTE: Disponível em: <http://imasters.com.br/artigo/17043/banco-de-dados/nosql-voce-realmente-sabe-do-que-estamos-falando/>. Acesso em: 27 jan. 2013.

De certa forma, pode-se dizer que bancos de dados que pertencem ao paradigma NoSQL trabalham com o conceito de Big Data visto anteriormente. Exemplos de bancos NoSQL: Berkeley DB, MemcacheDB, Cassandra (Apache), MongoDB, InfoGrid e Vertica.

No caso dos bancos NoSQL, toda a informação necessária estará agrupada no mesmo registro, ou seja, em vez de você ter o relacionamento entre várias tabelas para formar uma informação, ela estará em sua totalidade no mesmo registro.

DATA WAREHOUSE OU DATA MART? PROJETANDO BI

Tiago Curcio

As organizações que almejam alta competitividade no mercado não questionam a importância do Business Intelligence. A grande questão que se coloca é por onde e como começar. Os analistas de mercado têm uma resposta que pode parecer simplista, mas verdadeira: o tamanho do sapato deve ser o do tamanho do pé. Em outros termos, empresas pequenas ou com pouca cultura tecnológica podem começar usando algumas ferramentas de análise mais simples, como o EIS – Executive Information Systems, que são amigáveis e fornecem informações gerenciais de forma rápida e eficiente. Outra opção são as DSS – Decision Support Systems, sistemas de apoio à decisão que surgiram a partir dos sistemas transacionais e utilizam modelos para solucionar problemas não estruturados. São ferramentas que podem auxiliar as empresas a se familiarizar com os conceitos e tecnologias relativas ao BI, e evoluir nesse sentido aos poucos.

O fundamental é entender que os dados precisam ser estruturados de forma diferente do que ocorre nos sistemas transacionais. Por isso, os especialistas no assunto ressaltam que um dos principais pilares do BI é o Data Warehouse (DW). Como bem define William (Bill) Inmon, considerado o pai do DW, esse repositório nada mais é do que um banco de dados orientado por assuntos, não volátil (os dados não podem sofrer modificações) e integrado. No DW há apenas a carga dos dados e a consulta. Não há atualizações. Variável com o tempo é outra característica inerente ao DW. Isso significa que sempre será retratada uma situação num determinado ponto do tempo. É como se pegássemos uma foto de uma pessoa com um ano de idade e outra foto, dessa mesma pessoa, aos 10 anos de idade, para então fazer uma comparação e verificar as modificações ocorridas. No DW os assuntos são guardados em determinados pontos no tempo, o que permite uma análise histórica e comparativa dos fatos. Os dados podem ser retirados de múltiplos sistemas de computação utilizados internamente na empresa, ou também podem vir de fontes


66


externas. Em resumo, um DW pode ser definido como um conjunto de técnicas e de bancos de dados integrados, projetados para suportar as funções dos Sistemas de Apoio à Decisão, onde cada unidade de dados está relacionada a um determinado assunto ou fato. Sua meta é fornecer subsídios e informações aos gerentes e diretores, para que assim possam analisar tendências históricas de seus clientes e, com isso, melhorarem os processos e agilizarem as tomadas de ações.

O maior problema do Data Warehouse é a sua grande complexidade. Sua criação requer pessoas altamente especializadas, uma metodologia consistente, computadores, banco de dados, ferramentas de front-end (sistemas transacionais – para captura dos dados), ferramentas para extração e limpeza dos dados, e treinamento dos usuários. É um processo complicado e demorado, que requer altos investimentos e que se não for corretamente planejado e executado, pode trazer prejuízos enormes e se tornar um grande elefante branco dentro da organização.

Uma forma de minimizar os riscos seria começar com o desenvolvimento de Data Marts departamentais e, numa fase posterior, integrá-los transformando-os num Data Warehouse.

Em termos conceituais, pode-se afirmar que um Data Mart é um mini Data Warehouse que fornece suporte à decisão para um pequeno grupo de pessoas – como aos profissionais da área de marketing, ou de vendas, por exemplo. O tempo de desenvolvimento e implementação, assim como os investimentos necessários, também são bem menores, em comparação ao DW. Segundo estimativas, enquanto um Data Mart custa em torno de US$ 100 mil a US$ 1 milhão e leva cerca de 20 dias para ficar pronto, um DW integral começa a partir de US$ 2 milhões e demora no mínimo um ano para estar consolidado. Mas são valores apenas estimados, uma vez que não existe um projeto padrão que serve para todas as empresas indistintamente. O montante aplicado depende de cada caso.

De acordo com alguns especialistas no assunto, as diferenças existentes entre um Data Mart e um Data Warehouse são apenas com relação ao tamanho do projeto e ao escopo da empresa. Portanto, as definições dos problemas e os requisitos dos dados são essencialmente os mesmos para ambos. No entanto, um Data Mart trata das questões departamentais ou locais (de um departamento específico), enquanto um DW envolve as necessidades de toda a companhia de forma que o suporte à decisão atue em todos os níveis da organização.

Ralph Kimball, consultor norte-americano e considerado um dos mais influentes gurus do Business Intelligence, discorda dessa definição e argumenta que os Data Marts não devem ser departamentais, mas, sim, orientados aos dados ou a fontes de dados. Ele exemplifica o caso de uma instituição bancária que dispõe de uma fonte de dados de contas correntes e poupança. Nesse caso deveria ser criado um Data Mart de Contas, que não será um Data Mart proprietário da área financeira, e nem da área de marketing, mas sim um repositório de dados que terá como público todos os usuários de todos os departamentos que lidam com aquele assunto.


67

Ralph Kimball é um defensor da teoria de que o DW deve ser dividido para depois ser conquistado, ou seja, que o mais viável para as empresas é desenvolver vários Data Marts para posteriormente integrá-los e, assim, chegar-se ao DW. Na sua avaliação, as empresas devem construir Data Marts orientados por assuntos. Ao final, teriam uma série de pontos de conexão entre eles, que seriam as tabelas Fato e Dimensão em conformidade. Dessa forma, informações entre os diferentes Data Marts poderiam ser geradas de maneira íntegra e segura. Kimball batizou esse conceito de Data Warehouse Bus Architeture.

Bill Inmon rebate essa teoria e propõe justamente o contrário. Na sua avaliação deve-se construir primeiro um Data Warehouse, modelando-se toda a empresa para se chegar a um único modelo corporativo, partindo-se posteriormente para os Data Marts construídos por assuntos ou departamentais. Inmon defende a ideia de que o ponto de partida seriam os CIF – Corporate Information Factory – uma infraestrutura ideal para ambientar os dados da empresa. O CIF seria alimentado pelos sistemas transacionais. A construção de um ODS (Operational Data Store) seria facultativa, mas essa iniciativa ajudaria a reduzir a complexidade da construção de um DW, uma vez que todo o esforço de integração entre os sistemas transacionais da empresa seria depositado nele.

Uma vez que todos os dados estivessem integrados no DW, se partiria para os Data Marts que iriam atender aos diversos departamentos da empresa, gerando dados íntegros e corporativos. Inmon condena o processo inverso porque, na sua concepção, a construção de Data Marts atendendo a requisitos departamentais seria delineada a partir de regras específicas de negócios e de procedimentos de Extração, Transformação e Carga (ETL) dos dados oriundos dos sistemas transacionais. A visão corporativa da empresa seria relegada a segundo plano e as necessidades imediatas dos departamentos prevaleceriam. Além disso, essa iniciativa poderia gerar outros problemas, como a redundância de dados em diversos sistemas, o consumo exagerado de recursos de produção, e a formação de um verdadeiro caos informacional, na medida em que os dados dispostos nos diferentes Data Marts não poderiam ser integrados.

Qual deles está certo: Inmon ou Kimball? Ambos ou nenhum? Cabe a cada empresa analisar qual das duas abordagens mais se aplica às suas necessidades reais e ao seu bolso. No que ambos os gurus concordam é que uma empresa sem autoconhecimento e sem ter uma visão corporativa de seu negócio, nunca terá um sistema eficiente para auxiliá-la na tomada de decisão.

FONTE: Disponível em: <http://www.tiagocurcio.com/data-warehouse-ou-data-mart-2/>. Acesso em: 27 jan. 2013.

68

RESUMO DO TÓPICO 3


• Existem vários tipos de bancos de dados. Alguns exemplos são: bancos de dados de informações geográficas, multimídia, temporal, biológicos e XML.

• Data Mining é um processo de mineração de dados que visa construir um Data Warehouse. Data Warehouse é uma espécie de centralização dos dados da empresa com foco em apoio à tomada de decisão.

• Data Mart é um tipo de organização de dados com um fim bem específico e definido. Também visa dar apoio a tomada de decisão e normalmente se encontra dentro de uma organização de Data WareHouse.

• Big Data e NoSQL são novas tecnologias que visam à armazenamento e manipulação de grande quantidade de dados.

69

1 De acordo com o conteúdo estudado no neste tópico, defina por que é importante a busca por semelhança em bancos de dados multimídia.

2 Quais são os objetos que um banco de dados de informações geográficas pode armazenar?

3 Com base no conteúdo apresentado no Caderno de Estudos defina o que é um processo de Data Mining.

4 Qual é a diferença entre Data Warehouse e Data Mart?

5 Defina o que é o novo paradigma de bancos de dados denominado Big Data?

AUTOATIVIDADE

71

UNIDADE 2

MODELAGEM DE DADOS


PLANO DE ESTUDOS

A partir desta unidade, você será capaz de:

• conhecer o processo de modelagem de dados;

• identificar uma entidade e seus atributos;

• compreender a aplicação das formas normais.

Esta unidade está dividida em cinco tópicos e em cada um deles, você encontrará atividades que proporcionarão a compreensão dos conteúdos apresentados.

TÓPICO 1 – MODELOS DE DADOS

TÓPICO 2 – MODELO ENTIDADE-RELACIONAMENTO

TÓPICO 3 – TIPOS DE RELACIONAMENTOS

TÓPICO 4 – MODELO RELACIONAL

TÓPICO 5 – NORMALIZAÇÃO DE DADOS

73

TÓPICO 1

MODELOS DE DADOS

UNIDADE 2

1 INTRODUÇÃOO conhecimento da modelagem de dados é muito importante para

qualquer desenvolvedor que, em algum momento, construir alguma aplicação que irá interagir com um banco de dados. Independente do tamanho da aplicação a ser desenvolvido, o sucesso estará diretamente relacionado a uma modelagem bem feita, de modo a garantir dados consistentes, armazenados de forma eficiente, proporcionando bom desempenho e também a integridade dos dados.

O objetivo da modelagem de dados é garantir que todos os objetos de dados existentes em determinado contexto e requeridos pela aplicação estejam representados com precisão dentro do Banco de Dados.

Podemos definir modelagem de dados como sendo um conjunto de conceitos que devem ser usados para descrever a estrutura de uma base de dados. Quanto mais fiel a modelagem for ao ambiente em análise, maior é a chance de o projeto ter um bom resultado, permitindo assim a criação de um banco de dados mais aderente à realidade, possibilitando de forma mais eficiente o desenvolvimento da aplicação.

Uma modelagem mal feita, por sua vez, pode comprometer o sucesso do projeto, tendo como consequência diversos problemas, como por exemplo, a aplicação não funcionar adequadamente, os dados não confiáveis devido à falta de integridade, baixo desempenho etc.

O objetivo da modelagem é criar uma abstração da realidade que seja capaz de registrar os acontecimentos, de forma que seja possível programar um sistema que atenda às devidas necessidades e informações esperadas pelo usuário. A modelagem de dados utiliza notações em idioma natural, podendo ser facilmente compreendidos, por conta disso, é recomendado que o modelo de dados, depois de elaborado, sejam revisados e verificados pelos usuários finais.

A representação dos dados pode estar submetida a diferentes níveis de abstração. Estes níveis podem ser classificados como: modelos conceituais, modelos lógicos e modelos físicos. Veremos mais detalhes durante esta unidade.

O objetivo desta unidade é dar um embasamento para que você tenha as condições e conhecimentos mínimos para projetar um banco de dados relacional dentro da metodologia e segurança necessária para o sucesso de uma aplicação.

UNIDADE 2 | MODELAGEM DE DADOS

74

2 MODELO CONCEITUALSegundo Machado (2009), a princípio toda realidade é sempre bastante

nebulosa e informal. Ao observarmos esta realidade, podemos identificar fatos que nos levam a conhecê-la de uma forma mais organizada. Os fatos observados e modelados dizem algo a respeito do funcionamento de um negócio que estamos tentando compreender e manter.

O Modelo Conceitual é uma descrição mais abstrata da realidade, onde os fatos do mundo real são descritos de uma forma mais natural, bem como suas propriedades e relacionamentos. Esse modelo é utilizado para entendimento, transmissão, validação de conceitos e mapeamento do ambiente, possibilitando um melhor diálogo entre desenvolvedores e usuários.

Conforme relato de Machado (2004), o Modelo Conceitual deve ser sempre a primeira etapa de um projeto de um Banco de Dados (DB), onde o objetivo deste modelo é descrever de forma simples e facilmente compreensível pelos usuários finais as informações em um contexto de negócio, para posteriormente serem armazenadas em um banco de dados. É uma definição de alto nível que retrata toda a realidade de uma organização, processo de negócio, setor, repartição, departamento etc.

Durante o processo de criação do modelo conceitual, o analista deverá observar fatos e também buscar documentações, registros, regras etc. que possam lhe proporcionar um melhor entendimento do processo que se propõe a automatizar. Porém, é importante que o processo se atenha aos fatos relevantes que serão utilizados para a geração de informações e registro no sistema proposto.

É importante destacar que o Modelo Conceitual não está relacionado com o modelo de banco de dados, forma de acesso ou armazenamento dos dados. Ele está focado em uma representação gráfica da uma realidade existente em um contexto de negócio, conforme está ilustrado na figura a seguir. Essa modelagem é feita utilizando o modelo entidade-relacionamento. Nos próximos tópicos veremos mais detalhes.

FIGURA 29 – MODELO CONCEITUAL

FONTE: Os autores

TÓPICO 1 | MODELOS DE DADOS

75

3 MODELO LÓGICO

O Modelo Lógico tem por objetivo representar as estruturas que irão armazenar os dados dentro de um Banco de Dados, a partir deste momento é que são definidas com maior propriedade as entidades e os seus atributos.

O Modelo Lógico é iniciado somente a partir da estruturação do Modelo Conceitual. Nesta etapa é que será levada em consideração qual abordagem será utilizada referente ao Banco de Dados: Relacional, Hierárquico ou de Rede. Assim, o modelo lógico é diretamente dependente da abordagem, que determinará o tipo de SGDB que será utilizado.

O Modelo Lógico representa os dados em uma estrutura de armazenamento de dados. Nesse momento é definido a estrutura de registro do Banco de Dados, seus registros e números de campos com seus respectivos tamanhos, conforme a figura a seguir.

FIGURA 30 – MODELO LÓGICO

FONTE: Os autores

4 MODELO FÍSICO

O Modelo Físico é construído com base em um modelo lógico definido, com intuito de ser aplicado sobre um SGDB. Neste momento entram as questões relacionadas ao tipo e tamanho do campo, relacionamento, indexação, restrições etc. Ele descreve as estruturas físicas de armazenamento, tais como tabelas, índices, gatilhos, funções, visões, nomenclaturas etc.

O modelo físico, conforme Machado (2004) é a etapa final do projeto de banco de dados, onde será utilizada a linguagem de definição de dados do SGDB (DDL) para a construção do banco de dados com base no script SQL gerado. A figura a seguir representa um Modelo Físico que foi concebido a partir da ferramenta DBDesigner.


76

FIGURA 31 – MODELO FÍSICO

FONTE: Os autores

Normalmente, as ferramentas de modelagem têm funções para criação de scripts que serão responsáveis pela implementação do projeto físico em diversos SGBDs. Tomando como exemplo o projeto acima, temos como resultado o seguinte script SQL:

CREATE TABLE FILME (Codigo Filme INTEGER(6) NOT NULL, Titulo VARCHAR(100),GeneroVARCHAR(50), Ano INTEGER(4),Duracao TIME, Diretor VARCHAR(150),FaixaEtariaINTEGER(2) UNSIGNED, PRIMARY KEY(Codigo Filme));

CREATE TABLE CINEMA (Codigo do Cinema (CNPJ) INTEGER NOT NULL, Nome Fantasia VARCHAR(100), Rua VARCHAR(100), Bairro VARCHAR(100), Cidade INTEGER(6), Estado INTEGER(6),LotacaoINTEGER(3), PRIMARY KEY(Codigo do Cinema (CNPJ)))


77

CREATE TABLE EXIBICAO (Data Início DATE NOT NULL,Data Fim DATE NOT NULL,FILME_Codigo Filme INTEGER(6) NOT NULL,CINEMA_Codigo do Cinema (CNPJ) INTEGER NOT NULL, PRIMARY KEY(Data Inicio, FILME_Codigo Filme, CINEMA_Codigo do Cinema

(CNPJ)), INDEX FK2_EXIBICAO_FILME(FILME_Codigo Filme), INDEX FK1_EXIBICAO_CINEMA(CINEMA_Codigo do Cinema (CNPJ)),FOREIGN KEY(FILME_CodigoFilme)REFERENCES FILME(Codigo Filme)ON DELETE NO ACTION ON UPDATE NO ACTION,FOREIGN KEY(CINEMA_Codigo do Cinema (CNPJ)) REFERENCES CINEMA(Codigo do Cinema (CNPJ))ON DELETE NO ACTION ON UPDATE NO ACTION);

Caso você não tenha entendido o script gerado, não se preocupe, pois abordaremos mais detalhes sobre este assunto na Unidade 3.

UNI


DIFERENTES VISÕES PARA OS MESMOS DADOS

Sandra de Albuquerque Siebra

Todos esses modelos, na verdade, são visões diferentes, com nível de profundidade diferente para os mesmos dados. E é importante saber que, a partir de um modelo, o modelo seguinte pode ser derivado. Para lhe dar uma ideia de como as coisas acontecem, vamos explicar o processo descrito na figura a seguir. O analista de banco de dados observa a realidade (e também conversar com as pessoas que se fizerem necessárias) e, a partir do problema a ser resolvido (aplicação a ser desenvolvida), ele organiza suas ideias e cria um minimundo (que é um subconjunto da realidade contendo os dados necessários para a resolução do problema sendo tratado). O minimundo tem dados que vão ajudar a descrever o modelo conceitual (mais alto nível de abstração), o modelo lógico é especificado a partir do modelo conceitual e é implementado pelo modelo físico (que é que realmente é usado para criar o banco de dados (BD)).


78

Vamos descrever mais formalmente esse processo de criação do BD (que equivale ao processo de projeto do banco de dados)? Bem, podemos dizer que esse processo é composto por quatro fases conforme figura a seguir.

Na primeira fase, é feito o Levantamento e Análise dos Requisitos. Nessa fase são realizadas entrevistas com os potenciais utilizadores do BD, são levantados documentos importantes, pode-se olhar um sistema legado (já existente) para ver como ele funciona, com o objetivo de compreender e documentar os requisitos necessários para a construção do banco de dados (requisitos de BD).

A segunda fase é o projeto conceitual (ou modelagem) cujo objetivo é definir um modelo de dados conceitual que inclua a descrição das entidades do BD, dos atributos das entidades, dos relacionamentos entre entidades, além das possíveis restrições, evitando, no entanto, detalhes de próprios da fase de implementação. Essa fase dá origem ao esquema conceitual representado pelo modelo entidade-relacionamento (que estudaremos em detalhes na próxima seção).

A terceira fase é o projeto lógico (ou implementação) que objetiva mapear o modelo de dados conceitual para o modelo de dados relacional. Essa fase dá origem ao esquema lógico representado pelo modelo relacional que já é um modelo que depende do SGBD que será usado para implementar o banco de dados.

A quarta e última fase é o projeto físico que objetiva mapear o modelo dedados relacional para o modelo de dados físico que tratará das estruturas em memória e organização dos arquivos do BD (arquivos de índices). Essa fase dá origem ao esquema físico que será o que realmente será implementado no BD.


79

FONTE: Disponível em: <http://www.fernandoans.site50.net/curso/curso06/UFPE-BancoDeDados.pdf>. Acesso em: 26 fev. 2013.

80

RESUMO DO TÓPICO 1Neste tópico, você viu que:

• A modelagem de dados é o conjunto de conceitos que devem ser usados para descrever a estrutura de uma base de dados.

• O objetivo da modelagem é criar uma abstração da realidade que seja capaz de registrar os acontecimentos.

• A modelagem de dados utiliza notações em idioma natural.

• O Modelo Conceitual é uma descrição mais abstrata da realidade, onde os fatos do mundo real são descritos de uma forma mais natural, bem como suas propriedades e relacionamentos.

• O Modelo Conceitual deve ser sempre a primeira etapa de um projeto de um Banco de Dados (DB).

• O Modelo Conceitual não está relacionado com o modelo de banco de dados, forma de acesso ou armazenamento dos dados.

• O Modelo Lógico tem por objetivo representar as estruturas que irão armazenar os dados dentro de um Banco de Dados. A partir deste momento é que são definidas com maior propriedade as entidades e os seus atributos.

• O Modelo Lógico é iniciado somente a partir da estruturação do Modelo Conceitual.

• O Modelo Físico é construído com base em um modelo lógico definido, com intuito de ser aplicado sobre um SGDB.

• Na construção do Modelo Físico entram as questões relacionadas ao tipo e tamanho do campo, relacionamento, indexação, restrições etc.

• O Modelo Físico descreve as estruturas físicas de armazenamento, tais como tabelas, índices, gatilhos, funções, visões, nomenclaturas etc.

• O Modelo Conceitual, o Modelo Lógico e o Modelo Físico, na verdade, são visões diferentes, com nível de profundidade diferente para os mesmos dados. E é importante saber que, a partir de um modelo, o modelo seguinte pode ser derivado.

81

AUTOATIVIDADE

1 O Modelo de Dados pode ser representado em diferentes níveis de abstração. Quais são estes tipos de modelos?

2 O Modelo Conceitual é a primeira fase de um projeto de Banco de Dados. Para que ele é utilizado e o que ele possibilita?

3 O que o Modelo Lógico tem por objetivo representar?

4 Qual é o tipo de modelo que descreve as estruturas físicas de armazenamento, tais como tabelas, índices, gatilhos, funções, visões, nomenclaturas etc?

( ) Modelos conceituais.( ) Modelos lógicos. ( ) Modelos físicos.

83

TÓPICO 2

MODELO ENTIDADE-RELACIONAMENTO

UNIDADE 2

1 INTRODUÇÃOCaro(a) Acadêmico(a)! A seguir será possível conhecer o Modelo Entidade-

Relacionamento e sua estrutura conceitual e lógica geral de um banco de dados.

2 MODELO ENTIDADE-RELACIONAMENTOO Modelo Entidade-Relacionamento (MER) é uma representação gráfica

dos objetos do mundo real, chamados de entidades, bem como a forma como que eles estão relacionados, denominada relacionamento. Este modelo tem por objetivo retratar uma porção da realidade para que seja implementada sobre uma estrutura de Banco de Dados.

Aliado ao fato do Modelo Entidade-Relacionamento (MER) ser uma ferramenta gráfica para representação de um banco de dados, ele ainda possui um alto grau de interpretação, simplificando o processo de comunicação entre usuários e analistas que estão à frente do projeto.

O MER descreve a estrutura conceitual e lógica geral de um banco de dados, conforme ilustrado na figura a seguir.


84

FIGURA 32 - ENTIDADERELACIONAMENTO E ATRIBUTO

FONTE: Os autores

Segundo Machado (2004), o MER foi originalmente definido por Peter Chen em 1976, baseado na teoria relacional criada em 1970 por Codd. Durante os anos 80, o MER sofreu algumas alterações com o objetivo de melhor atender às questões relacionadas ao mundo real, tornando-se hoje o modelo de dados conceitual mais conhecido e utilizado no mercado.

O processo de modelagem consiste em cinco aspectos importantes, segundo Machado (2004), que são os seguintes:

• Observação: Composta por entrevistas, reuniões, questionários, análise de documentos aliados ao conhecimento e experiência prévia da área de negócio.

• Entendimento dos conceitos: É considerado o núcleo do processo de modelagem. Fase destinada a identificar, entender e assimilar o objeto observado.

• Representação dos objetos: É aplicado à técnica de modelagem de dados Entidade-Relacionamento.

• Verificação de fidelidade e carências: Momento para identificar falhas e anomalias, ponto de vista errado ou má aplicação da técnica.

• Validação: Fase de aprovação final do modelo junto ao usuário final e outros profissionais da área técnica.

TÓPICO 2 | MODELO ENTIDADE-RELACIONAMENTO

85

Antes de iniciar com a elaboração de um Modelo Entidade Relacionamento, é preciso compreender seus principais componentes:

2.1 ENTIDADE

A entidade é a representação dentro do MER de um objeto físico ou abstrato do mundo real e relacionado ao negócio em análise. A entidade tem existência própria, e dentro do MER é sobre ela que são guardadas algumas informações.

Machado (2004, p. 71), define entidade como sendo “... aquele objeto que existe no mundo real com uma identificação distinta e com um significado próprio”.

Cada entidade deve possuir identificação própria e atributos. Dentro do MER, as entidades são representadas por um retângulo. Exemplos: casa, carro, matrícula, pessoa (física ou jurídica), viagem etc.

FIGURA 33 – ENTIDADES

FONTE: Os autores

Entidade X Instância de Entidade“Para se referir a uma entidade particular fala-se em instância ou ocorrência de entidade. Uma instância é um objeto de uma entidade com suas respectivas propriedades preenchidas com valores, distinguindo-a assim de qualquer outra instância. Vamos exemplificar: a entidade empregada, descrita há pouco, possui os atributos, nome, cargo que ocupa, idade e estado civil.Uma instância dessa entidade poderia ser: “Maria, secretária, 31 anos, solteira”. Ou seja, a instância é como se fosse um exemplo de empregado, com os atributos preenchidos com valores. Entendeu?” (SIEBRA 2010, p. 13).

UNI


86

2.2 ATRIBUTOS

Os atributos são as características ou propriedades das entidades e guardam informações específicas delas.

Segundo Machado (2009, p. 61), “Todo objeto, para ser uma entidade, possui propriedades que são descritas por atributos. Esses atributos e seus conteúdos (valores), juntos, descrevem as instâncias de uma entidade [...]”.

Exemplo: em uma entidade “Veículo”, teremos os atributos modelo, marca, ano, tipo, combustível etc.

Existem basicamente dois tipos de atributos:

• Identificadores: Dão identificação única a cada ocorrência dentro da entidade. Também são conhecidos por chaves. Por exemplo, em uma entidade “Pessoa”, o CPF poderia ser um atributo identificador, pois cada pessoa tem um CPF único.

• Descritores: Descrevem características da entidade. Tomando o exemplo anterior da entidade “Pessoa”, os atributos descritores poderiam ser nome, telefone, data de nascimento etc.

Os atributos relacionados à entidade podem ser representados dentro da mesma, ou na forma geométrica de círculos, também associados à entidade à qual pertencem, conforme demonstram as imagens:

FIGURA 34 – ATRIBUTOS DA ENTIDADE

FONTE: Os autores


87

Para que a entidade seja relevante ao projeto MER, ela deverá ter pelo menos um ou mais atributos.

UNI

2.3 RELACIONAMENTO

O relacionamento é a forma pela qual são feitas associações entre as entidades existentes no mundo real. Os relacionamentos são relativamente mais complexos que os outros componentes do MER, porém, eles são extremamente importantes por se tratarem de uma questão essencial deste tipo de modelo.

Para Machado (2009, p. 73) “Entender efetivamente relacionamentos e ser capaz de enxergar esses objetos como participantes do mundo real são fatores primordiais para efetuar trabalhos de modelagem de dados”.

No mundo real, assim como no MER, é justamente o relacionamento que é o responsável por dar sentidos aos objetos ou entidades.

Dentro do MER, os relacionamentos são representados por losangos, e normalmente seus nomes são verbos que identificam uma ação entre as duas entidades, conforme podemos ver na imagem a seguir.

FIGURA 35 – RELACIONAMENTO ENTRE ENTIDADES

FONTE: Os autores

Para melhor compreendermos os relacionamentos, é preciso entender os elementos que o caracterizam:

• Semântica: A forma verbal utilizada para representar o conceito, lido da esquerda para a direita, e de cima para baixo.

• Cardinalidade: É o número de ocorrências de uma entidade para outra. Podem ser de três tipos:


88

• 1:1= um para um.• 1:N = um para muitos.• N:M = muitos para muitos.

• Condições para as entidades participarem em determinado relacionamento.

• Número de entidades envolvidas em um relacionamento, determinando se ele é binário (entre duas entidades) ou n-ário (entre mais de duas entidades).

3 CONSTRUINDO UM MODELO ENTIDADE-RELACIONAMENTO

Inicialmente é necessário que tenhamos em vista um problema a ser resolvido, e com base nesse problema devemos delimitar o minimundo ou escopo a ser especificado.

Deste modo, durante a fase inicial, chamada análise de requisitos, costuma ser elaborado o Modelo Descritivo, que corresponde a uma documentação descritiva, que busca relatar através de linguagem natural à situação, o ambiente e o problema a ser resolvido, delimitando assim o escopo do projeto.

O Modelo Descritivo irá fornecer as informações para a construção do modelo MER.

Segue um exemplo prático e resumido de um Modelo Descritivo.

Uma universidade mantém um cadastro de seus acadêmicos. De cada um são registrados: nome, endereço, telefone e data de nascimento.

As disciplinas, que são oferecidas à universidade, mantêm o código, nome, carga horária e ementa.

O histórico de um aluno faz associação com as disciplinas que ele cursou em cada etapa, contendo a nota e frequência e situação de aprovado ou reprovado.

A universidade também mantém um cadastro dos seus professores: são registrados nome, endereço, telefone, e data de nascimento.

Cada uma das disciplinas nos cursos da universidade terá somente um professor ministrando as aulas.

Este documento pode ser construído a partir de vários recursos que o analista poderá fazer, como observações, reuniões, questionário, análise de documentos, troca de experiências etc.


89

Depois da elaboração deste documento, é muito importante revisá-lo juntamente com os usuários ou envolvidos no projeto, para validar as informações relacionadas.

Mesmo durante a construção do modelo descrito, é possível identificar nele quais serão as entidades, parte dos atributos das mesma e boa parte dos relacionamentos. As entidades, conforme foi citado anteriormente, são abstrações do mundo real dentro do MER.

Uma maneira prática de identificar mais facilmente as entidades é relacionar todos os substantivos descritos no modelo descrito. Depois de relacionados, é preciso verificar dentro desta lista de substantivos, quais realmente são entidades e quais têm aderência a serem atributos destas entidades.

Os relacionamentos por sua vez podem ser identificados através dos verbos utilizados no modelo descritivo. Obviamente, nem todos os verbos serão utilizados (pois fazem parte dos recursos da linguagem para descrição do cenário). Porém, os verbos que identificam ações entre duas entidades, é um sério candidato a um relacionamento. Por conta disso, é essencial identificar todas as entidades do modelo descritivo primeiro e para depois identificar os relacionamentos.

QUADRO 2 – TABELA DEMONSTRATIVA

OBJETO ENTIDADE ATRIBUTO RELACIONAMENTO

Universidade X

Aluno X

Nome X

Data de nascimento X

Cursar X

Disciplinas X

Notas X

Professor X

Ministrar X

.....

FONTE: Os autores


90


Edgar Frank Codd

Edgar Frank Codd (Dorset, 23 de agosto de 1923 – 18 de abril de 2003) foi um matemático britânico. Ele desenvolveu o modelo de banco de dados relacional, quando era pesquisador no laboratório da IBM em San José.

Em junho de 1970, ele publicou um artigo chamado “RelationalModelof Data for LargeShared Data Banks” (“Modelo de dados relacional para grandes bancos de dados compartilhados”) que foi publicado na Revista ACM (“Association for ComputingMachinery”) Vol. 13, No. 6, pp. 377–387. Este artigo, um desenvolvimento de um artigo interno da IBM publicado no ano anterior, demonstrou os fundamentos da teoria dos bancos de dados relacionais, usando tabelas (“linhas” e “colunas”) e operações matemáticas para recuperá-las destas tabelas (UNION, SELECT, SUM etc…).

Devido ao interesse da IBM em preservar o faturamento trazido por produtos pré-relacionais, tais como o IMS/DB, ela não quis, inicialmente, implementar as ideias de Codd. Este então buscou grandes clientes da IBM para mostrar-lhes as novas potencialidades de uma eventual implementação do modelo relacional. Mesmo com a pressão dos clientes IBM, ela não incluiu Codd nos novos projetos sendo implementados. Devido a isso, desgostoso pela rejeição de suas ideias, Codd uniu-se a seu colega Christopher J. Date da IBM para deixar a mesma, fundando uma consultoria chamada Codd & Date. Logo após adoeceu e teve de encerrar sua carreira, vindo a falecer no começo do III milênio. Porém, Date continuou a obra de Codd, tornando-se autor de vários livros importantes da área de BD.


91

RESUMO DO TÓPICO 2Neste tópico, você viu que:

• O Modelo Entidade-Relacionamento (MER) é uma representação gráfica dos objetos do mundo real, chamados de entidades, bem como a forma como que eles estão relacionados, chamada de relacionamento.

• O MER foi originalmente definido por Peter Chen em 1976, baseado na teoria relacional criada em 1970 por Codd.

• A entidade é a representação dentro do MER de um objeto físico ou abstrato do mundo real e relacionado ao negócio em análise. A entidade tem existência própria, e dentro do MER é sobre ela que são guardadas algumas informações.

• Os atributos são as características ou propriedades das entidades, e guardam informações específicas sobre as mesmas.

• Os atributos Identificadores identificam cada ocorrência dentro da entidade, também conhecidos por chaves.

• O atributo descritor descreve as características da entidade.

• O relacionamento é a forma pela qual são feitas associações entre as entidades existentes no mundo real.

92

AUTOATIVIDADE

1 A representação gráfica do Modelo Entidade-Relacionamento representa o quê?

2 Por quem foi originalmente definido o Modelo Entidade-Relacionamento? E com base em qual teoria?

3 O que uma entidade representa dentro do Modelo Entidade-Relacionamento?

4 Basicamente existem dois tipos de atributos, quais são eles e para que servem?

5 Qual é a função do relacionamento dentro do MER?

93

TÓPICO 3

TIPOS DE RELACIONAMENTOS

UNIDADE 2

1 INTRODUÇÃOConforme foi dito anteriormente, os relacionamentos definem como são

feitas as associações entre duas ou mais entidades. Eles existem por características intrínsecas dos objetos, e através do seu mapeamento é possível demonstrar como uma entidade se comporta em relação às demais.

Conforme Cougo (1997), cada objeto poderá se relacionar com diversos outros objetos independentemente do seu tipo. Porém, o que define se uma associação é válida ou não será o grau de fidelidade e completeza atingido durante o processo de modelagem.

Nesta unidade estaremos vendo quais são os tipos de relacionamento, a partir do grau de associação entre as entidades.

2 CONDICIONALIDADE DO RELACIONAMENTOOs relacionamentos podem ser denotados de opcionalidade quanto à

participação de elementos em sua associação. O critério para condicionalidade é verificar o número de ocorrência de instâncias dentro do relacionamento. Desta forma, vão existir relacionamentos opcionais, que não exigem a obrigatoriedade de acontecerem instâncias e os que indicarão obrigatoriedade da participação.

Para que o conceito fique mais claro, vamos observar alguns exemplos práticos. Observe a figura:

FIGURA 36 – RELACIONAMENTO OBRIGATÓRIO

FONTE: Os autores

94


Nesta relação, observamos que a entidade PAI precisa possuir pelo menos um FILHO para que seja caracterizado um relacionamento. Lendo o relacionamento, temos:

• Um PAI deverá ter um ou mais FILHOS.• Cada filho deverá ter um e somente um PAI.

O relacionamento entre duas ou mais entidades pode admitir opcionalidade, que é quando não é obrigatória a ocorrência de uma instância. Para ficar mais claro o entendimento, observe a figura a seguir:

FIGURA 37 – RELACIONAMENTO OPCIONAL

FONTE: Os autores

Neste relacionamento percebemos que não é obrigatório que a entidade PESSOA venha a possuir CARRO. Então, lendo o relacionamento, temos:

• Uma PESSOA poderá ter nenhum, um ou vários CARROS.• Um CARRO sempre pertencerá a uma única pessoa.

Ainda é possível determinar o número máximo de associações que as entidades podem fazer em um relacionamento, de modo a atender características de limitações sobre abstrações do mundo real. Por exemplo, vamos observar a figura a seguir:

FIGURA 38 – LIMITE DE ASSOCIAÇÃO

FONTE: Os autores

É possível observar que existe uma limitação no número máximo de associações entre as entidades, nos dois sentidos do relacionamento. Fazendo a leitura, temos:

• Em um CAMPEONATO, terá que ter no mínimo1 e no máximo 24TIMES.

TÓPICO 3 | TIPOS DE RELACIONAMENTOS

95

Um TIME deverá participar em pelo menos um CAMPEONATO, podendo participar de no máximo até dois CAMPEONATOS.

3 GRAU DO RELACIONAMENTO

3.1 RELACIONAMENTO UM PARA UM

O grau de relacionamento ou cardinalidade do relacionamento é responsável por determinar o número de ocorrências entre duas entidades que estão associadas por um relacionamento.

Com base no grau de relacionamento ou cardinalidade, temos a possibilidade de classificar os relacionamentos entre as entidades com três tipos de graus distintos, conforme estudaremos a seguir:

No relacionamento Um para Um (1:1), cada elemento de uma entidade se relaciona a apenas um único elemento de outra entidade. Veja o exemplo na figura a seguir, onde cada elemento da entidade “PESSOA” está associado apenas a um único elemento de “PASSAPORTE”.

FIGURA 39 – RELACIONAMENTO UM PARA UM

FONTE: Os autores

Sempre que for feito o relacionamento entre duas entidades, devemos fazer a leitura nos dois sentidos do negócio, isso poderá evitar o erro na criação do grau do relacionamento entre as entidades. Para o exemplo apresentado, cada uma das entidades tem características próprias. O seu relacionamento é de 1:1 em ambos os sentidos:

• Uma PESSOA poderá ter somente um PASSAPORTE.• Cada PASSAPORTE pertencerá somente a uma única PESSOA.

96


3.2 GRAU UM PARA MUITOS

No relacionamento Um para Muitos (1:N), temos a associação de um elemento da entidade associado a vários elementos de outra entidade. Veja o exemplo a seguir, em que a entidade “PESSOA” associado a muitos elementos da entidade “CARRO”, e somente um elemento de “CARRO” associado à entidade “PESSOA”. Este grau de relacionamento na prática é o mais comum no mundo real, observe a figura a seguir.

FIGURA 40 – RELACIONAMENTO UM PARA MUITOS

FONTE: Os autores

Observando a figura anterior, podemos ter a seguinte interpretação:

• Cada PESSOA pode ser proprietária de um ou vários CARROS. • Cada CARRO por sua vez, pertence a uma única PESSOA.

Podemos observar que é importante fazermos sempre a leitura nos dois sentidos do negócio, pois caso a leitura fosse feita apenas no sentido de “CARRO” para “PESSOA”, o grau fica Um para Um, não chegaríamos a um grau de relacionamento que reflete a realidade em questão.

3.3 GRAU MUITOS PARA MUITOS

O relacionamento Muitos para Muitos (M:N) ocorre quando a ocorrência de uma entidade se relaciona com vários de outra e vice-versa. Para um melhor entendimento, observe a figura a seguir.

FIGURA 41 - RELACIONAMENTO MUITOS PARA MUITOS

FONTE: Os autores

Conforme ilustra a figura anterior, podemos observar que uma ocorrência da entidade “LIVRO” pode estar associa a várias ocorrências na entidade “AUTOR”, e uma ocorrência da entidade “AUTOR” pode estar associa a várias ocorrências na entidade “LIVRO”. Na prática, poderias ler:

TÓPICO 3 | TIPOS DE RELACIONAMENTOS

97

4 AUTORRELACIONAMENTOO autorrelacionamento, assim como o seu próprio nome sugere é

responsável por identificar o relacionamento de uma ocorrência de uma entidade com ela mesma. Este tipo de relacionamento normalmente seve para representar uma estrutura hierárquica. Por exemplo, vamos considerar uma entidade pessoa, onde uma ocorrência (Pessoa) pode ter um pai, este pai pode ter pai e assim sucessivamente. Para ilustrar observe a figura a seguir:

• Um LIVRO pode ser escrito por um ou vários AUTORES.• Um AUTOR pode escrever um ou vários LIVROS.

Uma forma de identificar a cardinalidade Muitos para Muitos pode ser feita através da leitura do grau, onde o resultado vai ser Um para Muitos por ambos os lados da leitura.

Segundo Machado (2009, p. 84), “Esse tipo de relacionamento tem um aspecto extremamente peculiar, ele possui atributos. Isso quer dizer que esse relacionamento possui dados que são inerentes ao fato e não às entidades”.

FIGURA 42 – AUTORRELACIONAMENTO

FONTE: Os autores

A figura que acabamos de observar represente uma entidade pessoa com autorrelacionamento, onde podemos fazer a seguinte leitura, que uma pessoa tem um único pai e um pai pode ter associado muitas pessoas (filhos). Neste caso, o relacionamento é um para muitos, conforme vimos anteriormente, a única diferença é que a entidade que será relacionada neste momento é a própria entidade de origem.

Vejamos a seguir como fica a representação deste autorrelacionamento dentro de uma única tabela, veja na figura a seguir.

98


FIGURA 43 – AUTORRELACIONAMENTO

ID-PESSOA NOME ID-PAI

1 Edson Neto Null

2 Roberto Carlos Null

3 Agatha Christie 1

4 Renato Russo 2

5 Anderson Silva 4

FONTE: Os autores

Com base na figura que acabamos de observar, podemos identificar que as ocorrências que possuem o atributo ID-PAI com valor informado, representam a ocorrência de um filho do pai em questão.

Para facilitar o entendimento, vamos fazer a leitura da entidade que acabamos de analisar. Edson Neto é pai de Agatha Christie, Roberto Carlos é pai de Renato Russo e avô de Anderson Silva.

99


• Os relacionamentos definem como são feitas as associações entre duas ou mais entidades.

• Existem relacionamentos opcionais, que não exigem a obrigatoriedade de acontecerem instância e os que indicarão obrigatoriedade da existência.

• O grau de relacionamento ou cardinalidade do relacionamento é responsável por determinar o número de ocorrências entre duas entidades que estão associadas por um relacionamento.

• No relacionamento Um para Um (1:1), cada elemento de uma entidade se relaciona apenas com um único elemento de outra entidade.

• No relacionamento Um para Muitos (1:N), temos a associação de um elemento da entidade associado a vários elementos de outra entidade.

• O relacionamento Muitos para Muitos (M:N) ocorre quando a ocorrência de uma entidade se relaciona com vários de outra e vice-versa.

• O autorrelacionamento, como seu próprio nome sugere, é responsável por identificar o relacionamento de uma ocorrência de uma entidade com ela mesma.

RESUMO DO TÓPICO 3

100

AUTOATIVIDADE

1 O que define o relacionamento?

2 O que representa o grau de relacionamento ou cardinalidade do relacionamento?

3 Crie uma representação gráfica do relacionamento Um para Um (1:1) entre duas entidades.

4 Crie uma representação gráfica do relacionamento Um para Um (1:N) entre duas entidades.

5 Crie uma representação gráfica do relacionamento Um para Um (M:N) entre duas entidades.

6 Crie uma representação gráfica de um autorrelacionamento.

101

TÓPICO 4

MODELO RELACIONAL

UNIDADE 2

1 INTRODUÇÃONeste tópico será apresentada uma breve introdução ao modelo de

dados que é utilizado nos sistemas de gerenciamento de banco de dados do tipo relacional. O objetivo é dar condições para que você compreenda um projeto de um DB relacional, e não uma abordagem completa.

2 BANCO DE DADOS RELACIONALO banco de dados relacional é composto por estruturas que permitem o

armazenamento e resgate de informações, de modo estruturado, respeitando uma série de regras de funcionamento.

É preciso ter em mente que, o modelo lógico criado até aqui sofrerá uma adaptação para que possua aderência sobre estas estruturas de armazenamento que um banco de dados relacional dispõe.

Normalmente, um modelo lógico se transformará em um conjunto de tabelas e relações. As tabelas em um banco de dados relacionais têm sua origem no modelo entidade-relacionamento, onde elas eram chamadas de entidades. Os atributos de cada entidade irão compor campos em uma tabela.

Os relacionamentos têm a mesma origem quando é criado o modelo entidade-relacionamento além de criar as entidades e seus atributos, também é criado o relacionamento entre elas.

3 TABELAA tabela é um objeto de grande importância para um banco de dados,

pois é nela que serão armazenados os dados e futuramente disponibilizados aos usuários do sistema.

Segundo Heuser (2001, p. 78), uma tabela é um conjunto não ordenado de linhas (tupla), cada linha é composta por uma série de campos (atributo). Cada campo é identificado por um nome de campo (nome do atributo), o conjunto de campos homônimos de todas as linhas de uma tabela forma uma coluna. Observe a figura a seguir:

102


FIGURA 44 – TABELA

CÓDIGO NOME DATA DE NASCIMENTO ENDEREÇO120958 Edson Vargas Farias 15/02/1985 Rua Chapecó120959 Cintia Ferreira 27/08/1984 Rua Maranhão120960 Robson da Silva 28/01/1983 Rua Ingá120961 Agnaldo Ribeiro 02/05/1979 Rua Rondônia120962 Júlio Bastos 25/10/1984 Rua Enry

FONTE: Os autores

Ao fazermos uma comparação da tabela com o modelo lógico, percebemos que as tabelas correspondem às entidades. É muito provável que cada entidade do modelo lógico seja convertida em uma tabela ou mais tabelas.

Os campos da tabela (colunas) são facilmente relacionados aos atributos de cada entidade.

As linhas por sua vez, representam cada instancia da entidade. Cada vez que houver uma ocorrência de registro de uma entidade, respectivamente na tabela será adicionada uma linha com os valores dos seus atributos.

4 CHAVEAs chaves, em relação ao modelo lógico, correspondem aos atributos

identificadores. Eles permitem dar uma identificação a cada ocorrência de instância em uma tabela, e garantir que elas sejam únicas.

Porém, dentro do banco de dados propriamente dito, as chaves contam ainda com outras funcionalidades, sendo que, além de ter a função de identificar uma linha de uma tabela, elas ajudam a estabelecer o relacionamento entre as tabela de um banco de dados relacional.

Basicamente existem três tipos de chaves em um banco de dados relacional: chave primária, chave alternativa, chave estrangeira. Em seguida veremos mais detalhes referentes aos tipos de chaves e suas respectivas características.

4.1 CHAVE PRIMÁRIA

A chave primária ou primary key (PK) é uma coluna ou conjunto de colunas que identificam unicamente um registro dentro de uma tabela, ela pode ser simples ou composta. Os campos que pertencem à chave primária são obrigatórios, não admitindo valor vazio ou NULL.

TÓPICO 4 | MODELO RELACIONAL

103

Na abordagem relacional, segundo Heuser (2001), ao definir uma chave primária não se está definindo nenhum caminho de acesso, está-se definindo apenas uma restrição de integridade.

A chave primária simples é formada por apenas um campo da tabela. Neste caso podemos dizer que o valor da coluna chave não se repete.

FIGURA 45 – TABELA COM CHAVE PRIMÁRIA SIMPLES

PESSOACPF_PESSOA NOME88381248175 André Ricardo87702347368 Murilo Santos66986242255 Magda Silva

FONTE: Os autores

A chave primária composta é formada por mais de um campo da tabela, quando temos esta situação, o valor do conjunto de colunas envolvidas na chave não se repete. Isso significa que os valores de parte das colunas podem se repetir.

FIGURA 46 – TABELA COM CHAVE PRIMÁRIA COMPOSTA

PESSOA_MATRÍCULA

CPF_PESSOA CD_MATRÍCULA SITUACAO

88381248175 223344 Ativo

87702347368 556644 Ativo

66986242255 552244 Formado

FONTE: Os autores

4.2 CHAVE ESTRANGEIRA

A chave estrangeira ou foreign key (FK), é uma coluna ou conjunto de colunas que se referem necessariamente a uma chave primária de outra tabela ou dela mesma no caso de recursividade, estabelecendo um relacionamento entre as tabelas. Este relacionamento garante a integridade dos dados relacionados, pois apenas serão permitidos valores que atendam ao relacionamento.

A existência de uma chave estrangeira, segundo Heuser (2001), impõe restrições que devem ser garantidas ao executar operações de alterações do DB.

104


FIGURA 47 – TABELA COM CHAVE ESTRANGEIRA

• Na inclusão de uma linha: Deve garantir que o valor da chave estrangeira apareça na coluna da chave primária referenciada.

• Na alteração do valor da chave estrangeira: Deve garantir que o novo valor da chave estrangeira apareça na coluna da chave primária referenciada.

• Na exclusão de uma linha da tabela que contém a chave primária referenciada pela chave estrangeira: Deve garantir que na coluna chave estrangeira não apareça o valor da chave primária que está sendo excluída.

• Na alteração do valor da chave primária referenciada pela chave estrangeira: Deve garantir que na coluna chave estrangeira não apareça o antigo valor da chave primária que está sendo alterada.

Observe a figura a seguir, onde a tabela FUNCIONÁRIO possui uma coluna ID_DEPARTAMENTO que é chave primária da tabela DEPARTAMENTO.

FUNCIONÁRIO

ID_PESSOA PK NOME_FUNCIONÁRIO ID_DEPARTAMENTO FK

123041 Maria da Silva 1022

123042 João Neto 1023

123043 Roberto Augusto 1023

123044 Jonas Manuel Ribeiro 1021

123045 Augusto Franco 1023

DEPARTAMENTOID_DEPARTAMENTO PK NOME_DEPARTAMENTO1021 Financeiro1022 Recursos Humanos1023 Operacional1024 Direção

FONTE: Os autores

As duas tabelas anteriores representam informações distintas: a primeira traz uma relação de funcionários de uma empresa fictícia, e a outra relaciona os departamentos desta empresa.


105

Existe um relacionamento entre as tabelas, onde dentro da tabela de funcionário é feito referência ao departamento a que o funcionário pertence, a partir do número de sua identificação. Por exemplo, a funcionária “Maria da Silva”, cujo código é 123041, possui no campo ID_DEPARTAMENTO o valor 1022, que corresponde ao departamento “Financeiro” da tabela departamento.

Logo, este campo ID_DEPARTAMENTO na tabela funcionários é uma chave estrangeira (foreing key) que faz referência à chave primária da tabela DEPARTAMENTOS.

4.3 CHAVE ALTERNATIVA

Em alguns casos mais de uma coluna ou grupo de colunas da tabela servem para identificar unicamente um registro. Neste caso, uma das chaves é criada como chave primária e a outra, como alternativa (também conhecida como Chave única “UK”).

FIGURA 48 – TABELA COM CHAVE ALTERNATIVA

VEÍCULOCD_RENAVAM (PK) PLACA (UK) NOME998833229 MTU8956 KOMBI334432455 UTI0669 FUSCA442634523 MIK9887 GOL

FONTE: Os autores

No exemplo visto anteriormente, tanto a chave primária CD_RENAVAM quanto a alternativa PLACA servem para identificar um veículo. Neste caso foi optado por definir o campo CD_RENAVAM como sendo primária, pois esta informação existe antes mesmo de um veículo possuir placa, é importante lembrar que a chave primária não aceita valor NULL, já a chave alternativa sim.

Em alguns SGDB, é possível criar uma chave estrangeira referenciando uma chave alternativa.

UNI

106



As 12 Regras de Codd

Edgard F. Codd, em 1985, estabeleceu as 12 regras de Codd que determinam o quanto um banco de dados é relacional. Em algumas vezes, as regras se tornam uma barreira e nem todos os SGBDs relacionais fornecem suporte a elas. De qualquer forma, a título de conhecimento, vamos apresentá-las a seguir. Lembramos que nem todas as regras serão completamente compreendidas nesse momento, mas o serão até o final da disciplina.

Regra 1: Regra das informações em tabelas: As informações a serem armazenadas no banco de dados devem ser apresentadas como relações (tabelas formadas por linhas e colunas) e o vínculo de dados entre as tabelas deve ser estabelecido por meio de valores de campos comuns (chaves estrangeiras).

Regra 2: Regra de acesso garantido: Todo e qualquer valor atômico em um BD relacional possui a garantia de ser logicamente acessado pela combinação do nome da tabela, do valor da chave primária e do nome do campo/coluna que deseja acessar. Isso porque, com o nome da tabela, se localiza a tabela desejada. Com o valor da chave primária a tupla desejada dentro da tabela é localizada. E com o nome do campo/coluna se acessa a parte desejada da tupla.

Regra 3: Regra de tratamento sistemático de valores nulos: Valores nulos devem ser suportados de forma sistemática e independente do tipo de dado para representar informações inexistentes e informações inaplicáveis. Deve-se sempre lembrar que valores nulos devem ter um tratamento diferente de “valores em branco”.

Regra 4: Regra do catálogo relacional ativo: Toda a estrutura do banco de dados (domínios, campos, tabelas, regras de integridade, índices etc.) deve estar disponível em tabelas (também referenciadas como catálogo). Sua manipulação é possível por meio de linguagens específicas (por exemplo, SQL). Essas tabelas são, geralmente, manipuladas pelo próprio sistema no momento em que o usuário efetua alterações na estrutura do banco de dados (por exemplo, a inclusão de um novo atributo em uma tabela).

Regra 5: Regras de atualização de alto nível: Essa regra diz que o usuário deve ter capacidade de manipular as informações do banco de dados em grupos de registros, ou seja, ser capaz de inserir, alterar e excluir vários registros ao mesmo tempo.

Regra 6: Regra de sublinguagem de dados abrangente: Pelo menos uma linguagem, com sintaxe bem definida, deve ser suportada, para que o usuário possa manipular a estrutura do banco de dados (como criação e alteração de tabelas), assim como extrair, inserir, atualizar ou excluir dados, definir restrições de integridade e de acesso e controle de transações (commit e rollback, por exemplo). Deve ser possível ainda a manipulação dos dados por meio de programas aplicativos.


107

Regra 7: Regra de independência física: Quando for necessária alguma modificação na forma como os dados estão armazenados fisicamente, nenhuma alteração deve ser necessária nas aplicações que fazem uso do banco de dados (isolamento), assim como devem permanecer inalterados os mecanismos de consulta e manipulação de dados utilizados pelos usuários finais.

Regra 8: Regra de independência lógica: Qualquer alteração efetuada na estrutura do banco de dados como inclusão ou exclusão de campos de uma tabela ou alteração no relacionamento entre tabelas não deve afetar o aplicativo utilizado ou ter um baixo impacto sobre o mesmo. Da mesma forma, o aplicativo somente deve manipular visões dessas tabelas.

Regra 9: Regra de atualização de visões: Uma vez que as visões dos dados de uma ou mais tabelas são, teoricamente, suscetíveis a atualizações, então um aplicativo que faz uso desses dados deve ser capaz de efetuar alterações, exclusões e inclusões neles. Essas atualizações, no entanto, devem ser repassadas automaticamente às tabelas originais. Ou seja, a atualização em uma visão deve refletir na atualização das tabelas representadas por essa visão.

Regra 10: Regra de independência de integridade: As várias formas de integridade de banco de dados (integridade de entidade, integridade referencial e restrições de integridade complementares) precisam ser estabelecidas dentro do catálogo do sistema ou dicionário de dados e serem totalmente independentes da lógica dos aplicativos. Assim, os aplicativos não devem ser afetados quando ocorrerem mudanças nas regras de restrições de integridade.

Regra 11: Regra de independência de distribuição: Alguns SGBDs, notadamente os que seguem o padrão SQL, podem ser distribuídos em diversas plataformas/equipamentos que se encontrem interligados em rede. Essa capacidade de distribuição não pode afetar a funcionalidade do sistema e dos aplicativos que fazem uso do banco de dados. Em resumo, as aplicações não são logicamente afetadas quando ocorrem mudanças geográficas dos dados (caso dos BDs distribuídos).

Regra 12: Regra não subversiva: O sistema deve ser capaz de impedir qualquer usuário ou programador de transgredir os mecanismos de segurança, regras de integridade do banco de dados e restrições, utilizando algum recurso de linguagem de baixo nível que eventualmente possam ser oferecidos pelo próprio sistema.


108

RESUMO DO TÓPICO 4


• O banco de dados relacional é composto por estruturas que permitem o armazenamento e resgate de informações, de modo estruturado, respeitando uma série de regras de funcionamento.

• As tabelas em um banco de dados relacionais têm sua origem no modelo entidade-relacionamento, onde elas eram chamadas de entidades. Os atributos de cada entidade irão compor campos em uma tabela.

• Os relacionamentos têm a mesma origem quando é criado o modelo entidade-relacionamento além de criar as entidades e seus atributos, também é criado o relacionamento entre elas.

• A tabela é um objeto de grande importância para um banco de dados, pois é nela que serão armazenados os dados e futuramente disponibilizados aos usuários do sistema.

• A chave permite dar uma identificação a cada ocorrência de instância em uma tabela, e garantir que elas sejam únicas.

• Basicamente existem três tipos de chaves em um banco de dados relacional: chave primária, chave alternativa, chave estrangeira.

• A chave primária ou primary key (PK) é uma coluna ou conjunto de colunas que identificam unicamente um registro dentro de uma tabela, ela pode ser simples ou composta. Os campos que pertencem à chave primária são obrigatórios, não admitindo valor vazio ou NULL.

• A chave estrangeira ou foreign key (FK) é uma coluna ou conjunto de colunas que se referem necessariamente a uma chave primária de outra tabela ou dela mesma no caso de recursividade, estabelecendo um relacionamento entre as tabelas.

• A chave alternativa é criada quando mais de uma coluna ou grupo de coluna da tabela servem para identificar unicamente um registro.

109

AUTOATIVIDADE

1 Sabemos que uma tabela é um dos objetos mais importantes de um banco relacional. De que ela é composta?

2 A chave primária é formada por um ou vários campos de uma tabela, qual é o seu objetivo e o que ela garante?

3 A correta criação e aplicação da chave estrangeira é primordial para um bom funcionamento de um banco de dados relacional. Descreva o que você entendeu sobre a composição e funcionamento da chave estrangeira.

4 Quando se aplica a criação de uma chave alternativa?

111

TÓPICO 5

NORMALIZAÇÃO DE DADOS

UNIDADE 2

1 INTRODUÇÃOPara que a construção de um projeto de banco de dados tenha sucesso é

preciso que proporcione a integridade e consistência dos dados que irá armazenar. Para isso foi criado uma metodologia chamada normalização, que tem por objetivo possibilitar o desenvolvimento de um modelo de armazenamento consistente, além de um acesso eficiente e íntegro aos dados.

O processo de normalização é composto por um conjunto de regras aplicadas sobre as tabelas (entidades) e seus relacionamentos, buscando evitar falhas no projeto de banco de dados, como redundâncias, dissociação de assuntos e informações relevantes ou pertinentes dentro de um domínio etc. Estas e outras falhas desta natureza são conhecidas por anomalias.

Segundo Machado (2009), com o processo de normalização, pode-se gradativamente substituir um conjunto de entidade e relacionamento por outro, que se apresenta “purificado” em relação às anomalias de atualização (inclusão, alteração e exclusão).

Estas anomalias se não tratadas podem causar certos problemas, tais como grupos repetitivos de dados, dependências parciais em relação a uma chave concatenada, redundância de dados desnecessária, perdas acidentais de informações, dificuldade na representação de fatos da realidade observada e dependências transitivas entre atributos.

O que é normalização?

Em 1970, o Professor Dr. Edgar F. Codd, analista da IBM, desenvolveu uma série de estudos sobre como tratar os dados, a fim de eliminar as anomalias de atualização e as suas consequências desagradáveis para as organizações. Deste esforço surgiram duas inovações que revolucionaram a maneira de tratar os dados. A primeira destas inovações foi o Modelo Relacional, no qual se basearam os Sistemas Gerenciadores de Base de Dados (SGBD) da metade da década de 1980 e início de 1990. A segunda inovação foi o processo de Normalização, sendo que ambas estão intimamente relacionadas.

112


O processo de normalização como foi proposto por Codd sujeita um esquema de relação a uma série de testes para certificar-se de que ele satisfaça certa forma normal. Na verdade, a normalização de dados pode ser vista como o processo de análise de determinados esquemas de relações com base em suas dependências funcionais e chaves primárias para alcançar as propriedades desejáveis de: (1) minimização de redundâncias e (2) minimização de anomalias de inserção, exclusão e alteração. Nesse processo, os esquemas de relações insatisfatórios, que não alcançam certas condições (no caso, os testes de forma normal) são decompostos em esquemas de relações menores que passam nos testes e, consequentemente, possuem as propriedades desejadas. Em outras palavras, quando uma tabela não atende ao critério de uma forma normal, sua estrutura é redesenhada através da projeção (jogar para fora) de alguns atributos, levando a construção de novas tabelas contendo algum atributo que possa refazer o conteúdo da tabela original através da junção (reunir) das tabelas resultantes.

O processo de normalização tem as seguintes funções:

• Analisar tabelas e organizá-las de forma que a sua estrutura seja simples, relacional e estável, para que o gerenciamento delas possa ser também simples, eficiente e seguro.

• Evitar a perda e a repetição da informação.• Conseguir uma forma de representação adequada para o que se deseja

armazenar.• Oferecer mecanismos para analisar o projeto do BD (identificação de erros e

possibilidades de melhorias) e oferecer métodos para corrigir problemas que, por ventura, sejam encontrados.

E, com essas funções, pretende-se alcançar os seguintes objetivos:

• Garantir a integridade dos dados, evitando que informações sem sentido sejam inseridas no banco de dados.

• Organizar e dividir as tabelas da forma mais eficiente possível, diminuindo a redundância e permitindo a evolução do banco de dados com o mínimo de efeito colateral.

Inicialmente Codd propôs três formas normais que ele chamou de primeira (1FN), segunda (2FN) e terceira (3FN) forma normal. Uma definição mais forte da 3FN (chamada forma normal BOYCE-CODD - FNBC ou BCNF) foi depois proposta por Boyce e Codd. Todas essas formas normais são baseadas nas dependências funcionais entre os atributos de uma relação. Posteriormente, uma quarta (4FN) e quinta (5FN) forma normal foram propostas.

TÓPICO 5 | NORMALIZAÇÃO DE DADOS

113

As formas normais são aplicadas para evitar redundância de dados, inconsistências e anomalias de atualização. Isso porque, redundância de dados é um fato gerador de inconsistências. Já as anomalias de atualização criam dificuldades operacionais para manutenção do banco de dados, quebrando a confiabilidade no dado ou ferindo a integridade dos dados.

Uma forma normal engloba todas as outras anteriores, ou seja, a hierarquia entre as formas normais indica que uma tabela só pode estar numa forma mais avançada se, além de atender as condições necessárias, já estiver na forma normal imediatamente anterior.

Por exemplo, para que uma tabela esteja na 2FN, ela obrigatoriamente deve estar na 1FN e assim por diante.

Na prática, o mais comum é normalizar relações apenas até a 3FN. Isso porque as três primeiras formas normais (1FN, 2FN e 3FN) atendem à maioria dos casos denormalização e já são suficientes para organizar as tabelas de um BD.

FONTE: Siebra (2010)

2 ANOMALIAS DE ATUALIZAÇÃOA entidade que não for devidamente normalizada com base nas formas

normais brevemente vista anteriormente, corre o risco de sofrerem com algumas anomalias, é justamente esta a situação que estaremos vendo a seguir.

Segundo Siebra (2010), a mistura de atributos de várias entidades pode gerar problemas conhecidos como anomalias de atualização, tais anomalias podem causar uma série de ocorrências tais como:

• Grupos repetitivos de dados.• Dependências parciais de chave.• Redundâncias desnecessárias de dados.• Perdas acidentais de informações.• Dificuldade de representação de fatos da realidade (modelos).• Dependências transitivas entre atributos.• As anomalias de atualização podem ser de três tipos:

• Anomalias de inserção – Causam a repetição desnecessária de dados (redundância).

• Anomalias de alteração – Levam as inconsistências e aumentam o esforço para a atualização dos dados.

• Anomalias de exclusão – Causam a perda de informações associadas a um dado registro.

114


Para exemplificar, Siebra (2010) usa uma suposição onde é criada uma relação de empregados de uma empresa.

FIGURA 49 – RELAÇÃO EMPREGADO

FONTE: Siebra (2010)

Ao criarmos a relação desta forma, é possível observar as seguintes anomalias de atualização:

• Anomalia de Inserção: Ocorre quando vamos inserir uma nova ocorrência (Registro) na relação de empregado, será necessário incluir também os valores para os atributos de departamento em que o empregado trabalha, ou deixar null os campos referentes ao departamento. Além disso, deve-se tomar cuidado ao inserir dados de um departamento que já exista na tabela, pois a possibilidade de registrar um mesmo código de departamento com um nome diferente, desta forma criando uma inconsistência na base. Outra questão é a dificuldade para inserir um novo departamento que ainda não tivesse empregados registrados, neste caso a única maneira é colocar valores null nos atributos referente aos empregados. Essa alternativa gera um problema, pois o CPF do empregado faz parte da chave primária da nossa relação de empregados, onde cada registro deve representar um empregado e não um departamento.

• Anomalia de Alteração: No caso de necessidade de alterar os atributos de um departamento qualquer, esse valor deve ser alterado em todas as ocorrências referente aos empregados que trabalhassem no departamento em questão. Caso contrário, novamente será gerada uma inconsistência na nossa.

• Anomalia de Remoção: No caso de remoção de uma ocorrência de empregado, se esta for a última ocorrência de um departamento, a informação do departamento será perdida.

Para evitar tais anomalias, podemos utilizar as técnicas de normalização (formas normais) criadas por Codd.


115

3 APLICAÇÃO DAS FORMAS NORMALIZAÇÃOO objetivo da disciplina não é se aprofundar em cada uma das formas

normais, porém vamos ver como é o processo de aplicação conforme proposto por Machado (2009).

• Entidade ou documento não normalizado, apresentando grupos repetitivos e certas anomalias de atualização.

→Aplicação da 1FN

→Decompor a entidade em uma ou mais entidades, sem grupos repetitivos.→Destacar um ou mais atributos como chave primária da(s) nova(s)

entidades(s), e ele será concatenado com a chave primária da entidade original.

→Estabelecer o relacionamento e a cardinalidade entre a(s) entidade(s) gerada(s) e a entidade geradora.

→Verificar a questão da variação temporal de certos atributos e criar relacionamento 1:N entre a entidade original e a entidade criada por questões de histórico.

• Entidades na 1FN

→Aplicação da 2FN

→Para entidades que contenham chaves primárias concatenadas, destacar os atributos que tenham dependência parcial em relação à chave primária concatenada.

→ Criar uma entidade que conterá esses atributos, e que terá como chave primária o(s) atributo(s) do(s) qual (quais) se tenha dependência parcial.

→ Serão criadas tantas entidades quantos forem os atributos da chave primária concatenada, que gerem dependência parcial.

→ Estabelecer o relacionamento e a cardinalidade entre a(s) nova(s) entidades(s) gerada(s) e a entidade geradora.


→ Aplicação da 3FN

→Verificar se existem atributos que sejam dependentes transitivos de outros que não pertencem à chave primária, sendo ela concatenada ou não, bem como atributos que sejam dependentes de cálculo realizado a partir de outros atributos.

116


→Destacar os atributos com dependência transitiva, gerando uma nova entidade com esse atributo e cuja chave primária é o atributo que originou a dependência.

→Eliminar os atributos obtidos através de cálculos realizados a partir de outros atributos.


→Aplicação da FNBC

→ Só aplicável em entidades que possuam chaves primárias e candidatas concatenadas.

→ Verificar se alguma chave candidata concatenada é um determinante, e em caso afirmativo, criar uma entidade com os que dependam funcionalmente desse determinante e cuja chave primária é o próprio determinante.

• Entidades na FNBC

→ Aplicação do 4FN

→ Para se normalizar em 4FN, a entidade (obrigatoriamente) deve estar na 3FN.

→ Verificar se a entidade possui atributos que não sejam participantes da chave primária e que sejam multivalorados e independentes em relação a um mesmo valor da chave primária.

→ Retirar esses atributos não chaves e multivalorados, criando entidades individuais para cada um deles, herdando a chave primária da entidade desmembrada.

• Entidade na 4FN

→ Aplicação da 5FN

→ Aplicada em elementos que estejam na 4FN.→ A ocorrência desse tipo de forma normal está vinculada aos relacionamentos

múltiplos (ternários etc.) ou entidades que possuam chave primária concatenada com três ou mais atributos.

→ Verificar se é possível reconstruir o conteúdo do elemento original a partir de elementos decompostos desta.

→ Se não for possível, o elemento observado não está na 5FN, caso contrário, os elementos decompostos representam um elemento na 5FN.


117

• Entidades na Forma Normal Final

O processo de normalização leva ao refinamento das entidades, retirando delas grande parte das redundâncias e inconsistências. Naturalmente, para que haja uma associação entre entidades é preciso que ocorram redundâncias mínimas de atributos que evidenciam esses relacionamentos. Sem as redundâncias não haveria relacionamento entre entidades.

4 FERRAMENTAS PARA MODELAGEM DE DADOSPara desenhar o DER e até dar apoio a fases posteriores do projeto de banco

de dados, como a conversão do MER. Para o modelo relacional existem diversas ferramentas de modelagem de dados.

Na sequência será feito uma breve apresentação de três ferramentas de modelagem de dados (DBDesigner, CA Erwin, PowerDesigner).

4.1 DBDESIGNER

O DBDesigner é uma ferramenta gratuita para projeto de banco de dados que integra a modelagem, projeto, implementação e manutenção em um mesmo ambiente.

Ela é desenvolvida pela empresa Fabulous Force Database Tools, atualmente, encontra-se na versão 4 e está disponível para download em: <http://fabforce.net/dbdesigner4/>.

118


FIGURA 50 - INTERFACE DB DESIGNER 4

FONTE: Disponível em: <http://fabforce.net/dbdesigner4/screenshot_image.php?screenshot=dbd4_ss_simplemodel.png>. Acesso em: 26 fev. 2013.

Este programa é útil para, ao invés de criarmos uma base de dados através de códigos, criarmos uma base de dados visualmente, com a definição de tabelas, tipos de dados e relações entre tabelas. A partir do resultado final do desenho de uma base de dados, termos acesso ao código que podemos utilizar para a criação da nossa base de dados. O DBDesigner é direcionado para o desenvolvimento de banco de dados com o SGBD MySQL, mas também oferece suporte para o Ms-SQL e o Oracle.

4.2 ERWIN

Esta é uma das ferramentas mais utilizada no mercado, conforme informado no site do fabricante (http://erwin.com/). Através desta ferramenta, o desenvolvedor de um sistema de informação pode especificar os dados envolvidos, as suas relações e os requisitos de análise.


119

A ferramenta permite desde a criação e manutenção das bases de dados, até o uso de mecanismos de sincronização de dados necessários. Além disso, oferece recursos para realizar o processo inverso (Engenharia reversa4). O ERwin gera modelos para todos os principais bancos de dados atuais e pode ser integrado para ajudar no gerenciamento dos mesmos (para atualização das bases de dados).

A notação utilizada pelo ERwin não descende da notação original de Peter Chen, ela implementa diagramas parecidos com os utilizados na Engenharia de Software. A interface da ferramenta pode ser visualizada a seguir.

FIGURA 51 - ERWIN

FONTE: Os autores

4.3 POWERDESIGNER

É considerada juntamente com o ERwin, uma das ferramentas mais utilizadas e completas do mercado. Gera modelo conceitual, converte para modelo lógico (automaticamente, sem intervenção do usuário) e trabalha com todos os principais bancos de dados disponíveis empregando inclusive, técnicas de engenharia reversa e de integridade referencial.

120


Apesar de ser uma ferramenta paga, ela tem uma versão demo disponível para avaliação por 15 dias no site: <http://www.sybase.com.br/products/modelingdevelopment/powerdesignerou>, <http://www.sybase.com>. A interface da ferramenta pode ser visualizada a seguir:

FIGURA 52 - POWERDESIGNER

FONTE: Disponível em: <http://pt.softpicks.net/software/Produtividade/Gerenciamento-de-Projeto/Sybase-PowerDesigner_pt-220884.htm>. Acesso em: 26 fev. 2013.

121

RESUMO DO TÓPICO 5


• O processo de normalização é composto por um conjunto de regras aplicadas sobre as tabelas (entidades) e seus relacionamentos, buscando evitar falhas no projeto de banco de dados, como redundâncias, dissociação de assuntos e informações relevantes ou pertinentes dentro de um domínio etc.

• O processo de normalização pode-se, gradativamente, substituir um conjunto de entidade e relacionamento por outro, que se apresenta “purificado” em relação às anomalias de atualização (inclusão, alteração e exclusão).

• A entidade que não for devidamente normalizada com base nas formas normais corre o risco de sofrer algumas anomalias.

122

1 O que você entendeu sobre o processo de normalização de dados?

AUTOATIVIDADE

123

UNIDADE 3

SQL


PLANO DE ESTUDOS

Esta unidade tem por objetivos:

• fixar de forma prática os conteúdos apresentados nas unidades anteriores;

• introduzir a linguagem SQL para criação de bancos de dados;

• apresentar perspectivas sobre o uso desta tecnologia.

Esta unidade está dividida em três tópicos e em cada um deles, você en-contrará atividades que proporcionarão a compreensão dos conteúdos apresentados.

TÓPICO 1 – INTRODUÇÃO À LINGUAGEM SQL

TÓPICO 2 – MANUTENÇÃO DOS DADOS

TÓPICO 3 – OUTRAS ESTRUTURAS DE DADOS

125

TÓPICO 1

INTRODUÇÃO À LINGUAGEM SQL

UNIDADE 3

1 INTRODUÇÃO

“Transportai um punhado de terra todos os dias e fareis uma montanha”. (Confúcio)

Já estamos na Unidade 3, a última unidade deste Caderno de Estudos. Muita coisa aconteceu até aqui fazendo com que adquiríssemos mais conhecimento. Apenas para fins de revisão e clareza, vamos relembrar rapidamente o que foi visto.

Na Unidade 1 tivemos uma introdução do que é e como funciona o mundo dos bancos de dados. Conceitos e teorias que vão desde as primeiras formas de armazenamento até o estado atual da tecnologia, com SGBDs modernos e eficazes. Vimos que existem vários paradigmas de gerenciamento e adotamos para este livro o banco de dados relacional. No final da unidade mostramos os principais bancos relacionais existentes no mercado.

Ao estudarmos a Unidade 2, evoluímos nossa forma de pensar sobre o modelo de dados relacional. Juntamente com o conhecimento adquirido na unidade anterior, conseguimos compreender como nascem as entidades (tabelas) e como elas podem se relacionar. Em resumo, pode-se dizer que tivemos uma boa base para projetar um banco de dados.

Agora estamos na Unidade 3. Chegou a hora de criarmos um banco de verdade. Vamos ver na prática como “nascem” as tabelas e como elas são populadas com dados. Como complemento, vamos explorar algumas estruturas que fazem parte do cotidiano desta área, como procedures, functions entre outras.

Será utilizado nos exemplos o banco de dados ORACLE, um dos principais bancos da atualidade. Bons estudos!

UNIDADE 3 | SQL

126

A Structured Query Language ou simplesmente SQL é uma linguagem utilizada para construirmos e manipularmos bancos de dados relacionais. É através dela que modelos de entidade-relacionamento viram realidade. Ela fornece uma série de comandos para criarmos estruturas e posteriormente recuperarmos dados.

Seguindo o caminho do aprendizado, vamos procurar entender como a SQL surgiu. Silberschatz, Korth e Sudarshan (2006) fazem um relato sobre a sua criação.

A IBM desenvolveu a versão original da SQL, originalmente chamada Sequel, como parte do projeto R no início da década de 1970. A linguagem Sequel evoluiu desde então, e seu nome mudou para SQL (Structured Query Language). Muitos produtos agora aceitam a linguagem SQL. A SQL se estabeleceu claramente como a linguagem padrão de banco de dados relacional.Em 1986, o American National Standards Institute (ANSI) e a International Organization for Standardization (ISO) publicaram um padrão SQL, chamado SQL-86. Em 1989, o ANSI publicou um padrão estendido para a linguagem: a SQL-89. A próxima versão do padrão foi a SQL-92, seguida da SQL-1999; a versão mais recente é a SQL-2003. (SILBERSCHATZ, KORTH E SUDARSHAN, 2006, p. 3).

Como pôde ser visto na citação acima, vários padrões da linguagem SQL foram criados desde que ela nasceu. Isso fez com que fabricantes de bancos de dados relacionais escolhessem qual padrão gostariam de seguir. Sendo assim, a sintaxe, comandos e outras particularidades podem variar de um banco para o outro. Isso vem a ser um desafio para programadores que desejam fazer seus sistemas rodarem em bancos de fabricantes diferentes. Inclusive, alguns bancos de dados tem o seu próprio padrão de SQL que normalmente é derivado dos padrões definidos pela ANSI e ISO.

Pode parecer complicado em um primeiro momento assimilar algumas das informações passadas acima. No momento não se preocupe com isso, porque posteriormente vários assuntos ficarão mais claros. Por hora, entenda que SQL é a linguagem utilizada para trabalhar com bancos de dados relacionais e que cada banco pode seguir um padrão SQL específico. O que torna esse aspecto um pouco menos custoso é o fato que ambos os padrões derivam de um padrão definido por um órgão competente.

2 O QUE É SQL

3 MODELO DE DADOS DESTA UNIDADEPara iniciar a parte prática deste Caderno de Estudos é essencial que seja

definido um modelo de dados ou modelo entidade-relacionamento (MER). Na Unidade 2, você aprendeu regras, formas normais e uma série de boas práticas para modelar um banco de dados com qualidade. Não iremos revisar esses tópicos, apenas vamos tomar como base o modelo de dados definido aqui.

TÓPICO 1 | INTRODUÇÃO À LINGUAGEM SQL

127

O nosso minimundo ou universo do discurso é um consultório médico, onde atuam quatro médicos. Cada um tem as suas especialidades e basicamente atendem a pacientes que agendam horário para as consultas. Levando em consideração que o foco desta unidade é o aprendizado de SQL, o modelo de dados será extremamente simples, tratando apenas o agendamento de consultas e deixando de lado outras questões, como por exemplo, pagamento de consultas, fluxo de caixa etc.

Segue figura com o modelo de dados que será utilizado nesta unidade.

FIGURA 53 – MODELO ENTIDADE-RELACIONAMENTO QUE SERÁ UTILIZADO NESTE CADERNO DE ESTUDOS

FONTE: Os autores

4 CRIANDO O BANCO DE DADOSEnfim chegou o grande momento. Finalmente vamos criar nosso banco

de dados seguindo o modelo que foi definido anteriormente. Vale a pena lembrar que os comandos apresentados neste Caderno de Estudos foram testados em uma base de dados Oracle 11g Express Edition. Esta versão é gratuita e pode ser baixada no endereço <http://www.oracle.com/technology/products/database/xe>. É necessário apenas que se faça um cadastro no site e em seguida o download será liberado.

É interessante que você efetue o download e instale o banco de dados Oracle na sua máquina. Isso facilitará muito a sua aprendizagem, podendo testar todos os comandos apresentados. Não é nosso objetivo tratar questões relacionadas à instalação, porém o processo é simples, necessitando apenas que se deixem as opções default selecionadas e avance até o fim. Durante a instalação será solicitado para definir uma senha para o usuário system. Defina-a e memorize-a para uso posterior.

UNIDADE 3 | SQL

128

Por se tratar de um sistema robusto, a instalação do Oracle pode deixar o seu computador com uma performance um pouco inferior. Caso tenha alguma dúvida procure a ajuda de um profissional.

ATENCAO

4.1 CONEXÃO AO BANCO DE DADOS

Para realizarmos qualquer trabalho com um banco de dados é preciso fazer uma conexão ao mesmo. Para tal, é necessário um programa cliente que irá tratar todos os comandos recebidos, enviar ao banco e obter sua resposta. A própria Oracle fornece o SQL Plus que é instalado na máquina no momento da instalação do banco de dados.

Primeiramente, abra o SQL Plus. A localização deste programa pode variar de um sistema operacional para o outro. Procure pelo item “Oracle Database 11g Express Edition” -> “Executar Linha de Comandos SQL”. A figura a seguir mostra a localização do atalho utilizando o sistema operacional Windows XP.

FIGURA 54 – LOCALIZAÇÃO DO ATALHO DO SQL PLUS NO WINDOWS XP

FONTE: Os autores


129

Dando sequência no procedimento, digite o comando conn. Será solicitado que se informe um usuário e uma senha. O usuário poderá ser o system e a senha será a que você definiu durante a instalação.

A figura a seguir ilustra esse processo.

FIGURA 55 – CONEXÃO COM O BANCO DE DADOS ORACLE

FONTE: Os autores

O Oracle e a maioria dos bancos de dados fornece uma forma de organização para usuários e uma definição do que eles podem acessar. Não é nosso objetivo explorar a mesma, por isso vamos continuar utilizando o usuário system.

4.2 CRIAÇÃO DE TABELAS

Para criarmos as tabelas, é necessário primeiramente entender sobre os tipos de dados que os campos dela podem ter. O quadro alista os principais tipos de dados de um banco Oracle.

UNIDADE 3 | SQL

130

FONTE: Morelli (2000 p. 12)

A seguir, vamos criar as tabelas do nosso banco de dados de acordo com o modelo proposto para esta unidade. Inicialmente criaremos apenas as tabelas e sua chave primária, deixando os relacionamentos para um segundo momento.

O comando para criação de tabelas é o create table. Sua sintaxe encontra-se a seguir. O padrão adotado neste Caderno de Estudos define que os itens dentro de colchetes ([ ]) são opcionais e sua utilização depende da necessidade do usuário.

create table nome_da_tabela ( coluna1 tipo_de_dado, ... ColunaN tipo_de_dado, primary key (nome_coluna))

Vamos criar a tabela paciente seguindo a sintaxe apresentada acima.

Tipo Descrição

char (n) Cadeia de caracteres de tamanho fixo n. O default é 1 e o máximo, 255.

varchar2(n)

Cadeia de caracteres de tamanho variável com o máximo de n e pode ter o valor de até 4.000. Para que duas variáveis desse tipo sejam consideradas iguais, elas devem possuir, além do mesmo conteúdo, o mesmo tamanho.

longCadeia de caracteres de tamanho variável com o máximo de 2 gigabytes. Só pode existir um campo desse tipo por tabela.

raw e long raw

Equivalente ao varchar2 e long, respectivamente, mas utilizado para armazenar dados binários que não são interpretados pelo Oracle, como, por exemplo, sons, imagens etc. Para agilizar o acesso, costuma-se quebrar uma tabela em duas quando houver um campo desse tipo: a primeira teria os campos originais e a segunda, a chave e o campo “grande”. As duas seriam relacionadas em 1:1.Limite para o tipo raw: 2.000 bytes.

number(p, e)

Valores numéricos em que p indica a precisão (máximo de 38) e indica a escala (número de casas decimais) que varia de -84 a + 127. Por exemplo, number(5,2) especifica um número na faixa entre -999,99 e +999,99.

date Armazena data e hora, incluindo século, ano, mês, dia, hora, minuto e segundo. Ocupam 7 bytes.

QUADRO 3 – TIPOS DE DADOS PARA CAMPOS DE TABELAS DO ORACLE


131

create table paciente ( nr_sequencia number(6), nm_paciente varchar2(100), cpf_paciente varchar2(11), fone_paciente varchar2(15), primary key(nr_sequencia)) Uma forma de trabalhar com o SQL Plus para inserir comandos é através

da utilização de um editor de textos. Para utilizar um, digite o comando ed que o bloco de notas ou o seu editor padrão se abrirá. Caso seja apresentada a mensagem “Nada para salvar”, digite qualquer comando com um ponto e vírgula no final. Depois de receber outro erro, digite novamente ed. A figura a seguir demonstra o funcionamento do processo.

FIGURA 56 – UTILIZANDO SEU EDITOR DE TEXTOS PARA COMANDOS SQL

FONTE: Os autores

Agora substitua o conteúdo do editor de textos pelo comando create da tabela paciente, deixando apenas a barra (“/”) no final do arquivo. Salve o conteúdo e feche o editor. Tecle barra (“/”) + enter que o comando será executado. Veja na figura a seguir, o resultado desses passos.

UNIDADE 3 | SQL

132

FIGURA 57 – COMANDO DO EDITOR SENDO EXECUTADO

FONTE: Os autores

A partir deste momento, a tabela paciente existe no nosso banco de dados.

Poderíamos ter trabalhado diretamente na tela do SQL Plus sem utilizar o Notepad. É só digitar todo o comando SQL e no final colocar um ponto e vírgula (“;”).

IMPORTANTE

Para verificar se tudo ocorreu conforme o planejado, um comando muito útil é o desc. Com ele podemos ver a estrutura dos objetos do banco. Sua sintaxe é:

desc nome_do_objeto;

Vamos testá-lo para verificar a estrutura da tabela paciente.

desc paciente;

O resultado pode ser visto na figura a seguir.


133

FIGURA 58 – RESULTADO DO COMANDO DESC

FONTE: Os autores

Note que um detalhamento dos campos da tabela é apresentado conforme definimos com o comando create table. Por enquanto não se preocupe com a coluna Nulo?. Ela será vista mais à frente.

Já que aprendemos a criar uma tabela, vamos ver agora o que temos que fazer para excluí-la. O comando é extremamente simples e muito poderoso. É o drop table.

drop table nome_da_tabela;

Veja na figura a seguir o que acontece quando executamos um drop table da tabela paciente e em seguida tentamos visualizar a sua estrutura com um comando desc.

FIGURA 59 – UTILIZANDO O COMANDO DROP TABLE

FONTE: Os autores

UNIDADE 3 | SQL

134

Como pôde ser visto, a tabela paciente não existe mais na nossa base de dados.

O comando drop table elimina completamente a tabela e os dados existentes nela. Depois da execução não é mais possível desfazer a ação que ele executou.

ATENCAO

Já que excluímos a tabela paciente vamos recriá-la só que desta vez sem o uso do editor de textos. Digite o comando create table da tabela paciente e para executá-lo coloque um ponto e vírgula (“;”) no final. Em seguida, procure ver a estrutura da tabela criada com o comando desc. A figura seguinte ilustra esse processo.

FIGURA 60 – CREATE TABLE DA TABELA PACIENTE SEM EDITOR DE TEXTO

FONTE: Os autores

Perfeito, agora temos a tabela paciente novamente criada! A seguir temos todos os comandos para criação das outras tabelas que compõem o nosso modelo de dados.


135

A partir deste momento vamos evitar o uso de imagens para demonstrar o funcionamento dos scripts. Assuma que tudo o que deve ser executado será através do SQL Plus aplicando o que foi ensinado sobre ele até o momento. Fique atento para o seguinte detalhe: Se você estiver utilizando um editor de texto, não coloque o ponto e vírgula no final do comando.

IMPORTANTE

create table consulta ( nr_sequencia number(10), nr_seq_paciente number(6), nr_seq_medico number(4), dt_hora_inicio date, dt_hora_fimdate, ds_observacao varchar2(1000), primary key (nr_sequencia);

create table medico ( nr_sequencia number(4), nm_medico varchar2(100), crm_medico varchar2(10), cpf_medico varchar2(11), fone_medico varchar2(15), primary key (nr_sequencia));

Se você deseja adicionar algum campo em alguma das tabelas segue um comando que cria o campo dt_nascimento na tabela paciente.

alter table paciente add (dt_nascimento date);

Para apagar a mesma coluna, use o seguinte comando.

alter table paciente drop column dt_nascimento;

Depois de efetuar alterações nas estruturas das tabelas, verifique se elas foram aplicadas conforme o esperado através da utilização do comando desc.

UNIDADE 3 | SQL

136

5 RESTRIÇÕESConforme você estudou na Unidade 2, o modelo relacional exige que sejam

criadas várias integridades para garantir total confiança nos dados armazenados. Essa criação de integridade ou restrição é suportada pelo padrão SQL e por vários bancos de dados. Um sinônimo para restrição é a palavra constraint que inclusive chega a ser utilizada no SQL para criação de algumas restrições.

Morelli (2000, p. 12) nos dá uma definição para restrição ou o termo popularmente conhecido como constraint.

Um constraint ou restrição apresenta um mecanismo capaz de implementar controles que garantam a consistência dos dados (integridade de dados e referencial). Pode ser definido tanto em nível de coluna (afeta apenas um campo) como em nível de tabela (afeta todos os campos).

De uma forma resumida, podemos dizer que restrição é tudo o que faz alguma validação ou checagem em um conjunto de dados.

5.1 CHAVE PRIMÁRIA E RESTRIÇÃO NOT NULL

Quando criamos as tabelas do nosso modelo de dados, a única restrição que programamos foi a de chave primária (primary key). Sinalizamos ao Oracle os campos que fazem parte da chave primária e ele entende que os valores desses campos não podem se repetir (pois identificam os registros da tabela), e também não podem ser nulos. Por isso, se você usar o comando desc nas tabelas verá que algumas linhas na coluna Nulo? aparecem com o valor NOT NULL.

Quando colocamos uma coluna para fazer parte da chave primária, automaticamente ela deverá ser NOT NULL, ou seja, não é permitido que ela não tenha valor. Veja a seguir o resultado do comando desc na tabela consulta.

Nome Nulo? Tipo -------------------------------- -------- ---------- NR_SEQUENCIA NOT NULL NUMBER(10) NR_SEQ_PACIENTE NUMBER(6) NR_SEQ_MEDICO NUMBER(4) DT_HORA_INICIO DATE DT_HORA_FIM DATE DS_OBSERVACAO VARCHAR2(1000) O campo nr_sequencia faz parte da chave primária, por isso,

automaticamente quando criamos a restrição primary key (nr_sequencia), o Oracle colocou ele como NOT NULL.


137

Na tabela consulta só existe um campo que pode ser NULL: o DS_OBSERVACAO. Todos os demais deverão ser NOT NULL. Para incluirmos essa restrição precisamos utilizar o comando alter table. Inicialmente vamos aplicar a restrição apenas à coluna NR_SEQ_PACIENTE.

alter table consulta modify (nr_seq_paciente NOT NULL);

Novamente vamos ver a estrutura da tabela consulta com o comando desc:

Nome Nulo? Tipo ------------------------------- -------- ------------- NR_SEQUENCIA NOT NULL NUMBER(10) NR_SEQ_PACIENTE NOT NULL NUMBER(6) NR_SEQ_MEDICO NUMBER(4) DT_HORA_INICIO DATE DT_HORA_FIM DATE DS_OBSERVACAO VARCHAR2(1000)

Agora o campo NR_SEQ_PACIENTE não aceita mais valores nulos. Vale a pena lembrar que também é possível incluir esta restrição ao criar a tabela, no comando create table. Segue o exemplo para a tabela consulta.

create table consulta ( nr_sequencia number(10) NOT NULL, nr_seq_paciente number(6) NOT NULL, nr_seq_medico number(4) NOT NULL, dt_hora_inicio date NOT NULL, dt_hora_fimdateNOT NULL, ds_observacao varchar2(1000), primary key (nr_sequencia);

Como nossas tabelas já estão criadas, vamos utilizar o alter table para programar as restrições NOT NULL. Seguem os comandos para todas as tabelas.

alter table consulta modify ( nr_seq_medico NOT NULL, dt_hora_inicio NOT NULL, dt_hora_fimNOTNULL);

alter table paciente modify ( nm_paciente NOT NULL, cpf_paciente NOT NULL);

alter table medico modify ( nm_medico NOT NULL, crm_medico NOT NULL, cpf_medico NOT NULL);

UNIDADE 3 | SQL

138

Agora temos todas as restrições NOT NULL programadas na nossa base. Lembrando que para fazer um campo NOT NULL aceitar valores nulos é simples. Basta fazer o alter table com uma restrição NULL conforme exemplo que segue:

alter table medico modify ( nm_medico NULL);

Se você colocou o campo nm_medico da tabela médico para aceitar valores nulos (conforme descrito no último exemplo), modifique novamente para ele não aceitar nulos.

ATENCAO

5.2 CHAVE ESTRANGEIRA

A próxima restrição que vamos abordar é a de integridade referencial também conhecida como chave estrangeira ou foreign key. Você já estudou sobre esse tipo de restrição na Unidade 2, por isso vamos para a parte prática através do comando alter table. Veja no exemplo a seguir a criação da chave estrangeira entre as tabelas consulta e paciente.

alter table consulta add constraint consulta_paciente_fk foreign key (nr_seq_paciente)

references paciente(nr_sequencia);

O comando acima criou uma restrição de chave estrangeira com o nome consulta_paciente_fk que tem como regra que o campo nr_seq_paciente da tabela consulta só pode conter valores que estão no campo da chave primária da tabela paciente (nr_sequencia).

Para excluir uma integridade referencial também usamos o comando alter table só que desta vez com o drop constraint. Segue um exemplo:

alter table consulta drop constraint consulta_paciente_fk;

A seguir está o script para a criação de todas as chaves estrangeiras do nosso banco de dados (inclusive a constraint consulta_paciente_fk que acabamos de apagar).


139

alter table consulta add constraint consulta_paciente_fk foreign key (nr_seq_paciente) references paciente(nr_sequencia)

alter table consulta add constraint consulta_medico_fk foreign key (nr_seq_medico) references medico(nr_sequencia)

5.3 CHAVE ÚNICA

Em seções anteriores vimos como funciona a criação de uma chave primária. Percebemos também que os campos que a compõe não podem ter repetição de valores e também não podem ser nulos. A chave única ou Unique Key tem os mesmos princípios, porém com uma única diferença: os campos que a compõem podem ser nulos.

Para resumir, os campos que fazem parte de uma Unique Key não podem ter valores repetidos no seu conteúdo, mas aceitam valores nulos. São úteis em vários casos. No nosso banco de dados seria interessante uma restrição desse tipo na tabela paciente no campo cpf_paciente, para evitar que um paciente seja cadastrado mais de uma vez. Segue o comando da criação desta integridade.

alter table paciente add constraint paciente_cpf_uk unique (cpf_paciente);

Se caso desejássemos excluir esta integridade, poderíamos fazer com o seguinte comando:

alter table paciente drop constraint paciente_cpf_uk;

Precisamos criar mais duas integridades deste tipo na tabela médico. Uma no campo cpf_medico para impedir a duplicação do cadastro de um médico e outra no crm_medico para impedir que existam dois CRMs iguais cadastrados nesta tabela. Abaixo segue os comandos com todas as Unique Keys da nossa base de dados (inclusive da tabela paciente, que foi excluída no exemplo acima).

alter table paciente add constraint paciente_cpf_uk unique (cpf_paciente);

alter table medico add constraint medico_cpf_uk unique (cpf_medico);

UNIDADE 3 | SQL

140

alter table medico add constraint medico_crm_uk unique (crm_medico);

5.4 CHECAGEM DE DADOS

É muito comum, quando se trabalha com banco de dados, querer que determinadas tabelas tenham os seus valores consistidos com alguma regra fixa. Para isso podemos usar uma constraint de checagem dos dados. Rob e Coronel (2011, p. 254) definem o que vem a ser uma restrição de checagem de dados ou simplesmente restrição check.

CHECK é utilizado para validar dados quando é inserido um valor de atributo. A restrição check não é exatamente o que o seu nome sugere: ela verifica se uma condição específica ocorre. Alguns exemplos desta restrição são: o valor mínimo de pedidos deve ser 10 ou a data deve ser posterior a 15 de abril de 2008.

Como foi citado acima, uma restrição check serve para validar dados de acordo com determinadas situações. No nosso banco de dados ela se encaixaria na tabela consulta. Temos os campos dt_hora_inicio e dt_hora_fim que registram o início da consulta e quando ela terminou. Jamais uma consulta pode terminar antes de começar, ou seja, o campo dt_hora_inicio deve ser sempre menor que o campo dt_hora_fim. Para isso vamos criar uma constraint check. O comando está logo abaixo.

alter table consulta add constraint dt_hora_consulta_ck check(dt_hora_inicio<dt_hora_fim)

O comando acima fará com que a tabela consulta nunca tenha consultas terminando antes mesmo de começar. Se você desejar excluir uma check constraint é só seguir os mesmos princípios de exclusão de uma unique key.

Caro(a) acadêmico(a)! A Leitura Complementar a seguir traz uma visão clara de questões relacionadas à origem do SQL e sua evolução até o momento. A seguir serão apresentados alguns fatores que devem ser analisados quando trabalhamos com esse tipo de tecnologia.

UNI


141


O QUE É SQL

O que é e para que serve o SQL?

As aplicações em rede são cada dia mais numerosas e versáteis. Em muitos casos, o esquema básico de operação é uma série de scripts que dirigem o comportamento de uma base de dados.

Devido à diversidade de linguagens e de base de dados existentes, a maneira de comunicar entre umas e outras seria realmente complicado de providenciar, a não ser pela existência de padrões que nos permite realizar as operações básicas de uma forma universal.

É justamente disso que se trata o Structured Query Language que não é mais do que uma linguagem padrão de comunicação com base de dados. Falamos, portanto, de uma linguagem normalizada que nos permite trabalhar com qualquer tipo de linguagem (ASP ou PHP) em combinação com qualquer tipo de base de dados (MS Access, SQL Server, MySQL...).

O fato de ser padrão não quer dizer que seja idêntico para cada base de dados. Na prática, determinadas bases de dados implementam funções específicas que não têm necessariamente que funcionar em outras.

À parte desta universalidade, o SQL possui outras duas características muito apreciadas. Por uma parte, apresenta potência e versatilidade notáveis que contrasta, por outra, com sua acessibilidade de aprendizagem.

História do SQL

A história do SQL começa em 1970 com a publicação por E. F. Codd, no ACM Journal, de um artigo intitulado “A Relational Model of Data for Large Shared Data Banks”.

O modelo proposto por Codd é hoje considerado a base de trabalho para qualquer Sistema de Gestão de Base de Dados Relacional (SGBDR).

A primeira implementação da linguagem SEQUEL foi realizada pela IBM e tinha por objetivo a implementação do modelo de Codd. A evolução desta linguagem veio a dar origem ao SQL.

A primeira implementação comercial de SQL foi realizada pela Relational Software, Inc., hoje conhecida por Oracle Corporation.

UNIDADE 3 | SQL

142

Nos dias de hoje, a linguagem SQL é considerada um standard dos Sistemas de Gestão de Base de Dados Relacionais (SGBDR); por isso, todos os fabricantes a integram nos seu produtos.

A linguagem SQL pertence à 4ª Geração das Linguagens de Programação, da qual é a única sobrevivente. Não é, no entanto, uma evolução das linguagens de 3ª Geração (Pascal, BASIC, C, COBOL, FORTRAN), já que estas têm características bem diferentes:

- Existência de Variáveis, vectores etc.- Existência de instruções condicionais (if, switch, case etc.).- Existência de ciclos (for, while, do... while, repeat... until).- Possibilidade de escrita de funções e procedimentos.

Nenhuma destas características existe no SQL, havendo maior ligação entre a 3ª e 5ª gerações de linguagens de programação do que com a 4ª.

A linguagem SQL destina-se, por isso e pela sua simplicidade, não só a informáticos, como também a gestores, utilizadores, administradores de bases de dados etc..

No entanto, a sua principal diferença em relação às linguagens de 3ª geração é a ausência nestas de um objetivo pré-definido, coisa que no SQL está bem determinado: proporcionar a interface entre o SGBDR e o utilizador, através da manipulação de dados.

A linguagem SQL implementa os conceitos definidos no modelo relacional, reduzindo assim as incompatibilidades entre os sistemas e evitando a opção por arquiteturas proprietárias que implicam maiores custos de desenvolvimento e maior esforço financeiro e humano por parte dos intervenientes.

Com a linguagem SQL é possível:Criar, alterar e remover todas as componentes de uma base de dados, como

tabelas, índices, views etc.Inserir, alterar e apagar dados.Interrogar a base de dados.Controlar o acesso dos utilizadores à base de dados, e às operações a que

cada um deles tem acesso.Obter a garantia da consistência e integridade dos dados.

A linguagem SQL é composta por vários conjuntos de comandos:

DDL (Data Definition Language): comandos para definir ou modificar a composição das tabelas, apagar tabelas, criar índices, definir “views”, especificar direitos de acesso a tabelas e views.


143

DML (interactive Data Manipulation Language): inclui uma linguagem de consulta baseada em álgebra relacional e em cálculo relacional sobre registos; inclui também comandos para inserir, apagar e modificar registos na base de dados.

As novas versões de SQL incluem capacidades de verificação de integridade dos dados, bem como comandos para especificação do princípio e fim de transações; algumas implementações permitem o impedimento explícito de acesso aos dados, para controle de acesso concorrencial.

FONTE: Disponível em: <http://www.xtibia.com/forum/topic/42593-o-que-e-sql-historia-do-sql/ >. Acesso em: 3 fev. 2013.

144

RESUMO DO TÓPICO 1


• SQL é uma linguagem para acesso e manipulação de dados em um banco relacional.

• O modelo de dados ou modelagem entidade relacionamento vira realidade através da aplicação de comandos SQL.

• A criação de tabelas pode ser feita de várias formas, com algumas variações de comandos que têm o mesmo resultado.

• Restrições em tabelas servem para dar maior confiabilidade nos dados armazenados e procuram mantê-los íntegros.

145

AUTOATIVIDADE

1 De acordo com o conteúdo estudado, defina o que é SQL.

2 Escreva o comando que pode ser utilizado para apagar uma constraint de integridade referencial (chave estrangeira), cujo nome é aluno_matricula_fk?

3 Qual é o comando que pode ser utilizado para apagar uma tabela?

4 Com base no que foi aprendido até o momento, escreva um comando que crie um campo na tabela paciente para armazenar o documento de identidade do mesmo.

5 Crie um comando para excluir o campo que você criou na pergunta anterior.

147

TÓPICO 2

MANUTENÇÃO DOS DADOS

UNIDADE 3

1 INTRODUÇÃO

“A persistência é o menor caminho do êxito.” (Charles Chaplin).

Dando sequência à parte prática do nosso Caderno de Estudos, vamos relembrar o que fizemos até aqui. Basicamente, este caderno está dividido em três momentos, ou melhor, três unidades com focos bem distintos.

Na primeira unidade tivemos vários conceitos relacionados a entender o que é um banco de dados e qual é a sua utilidade hoje no mundo da tecnologia da informação. Podemos perceber que houve um grande processo evolutivo desde as primeiras formas de armazenamento. Já na segunda unidade, começamos a entender como se projeta um banco de dados, quais são as melhores práticas e boas recomendações sobre como alcançar os objetivos pretendidos.

Agora que chegamos a terceira e última unidade, estamos mergulhando neste mundo de forma prática, conhecendo com dinamismo tudo o que nos foi apresentado nas unidades anteriores. No primeiro tópico aprendemos a criar tabelas em suas devidas restrições e checagens. Agora, vamos colocar dados nessas tabelas e verificar se a estrutura que criamos realmente atende o que foi proposto inicialmente.

Bons estudos!

2 INSERINDO, SELECIONANDO, ATUALIZANDO E DELETANDO DADOS

2.1 VALIDANDO AS RESTRIÇÕES DA TABELA

Agora que já temos todas as tabelas criadas, vamos preenchê-las com dados e verificar se tudo o que programamos está funcionando. Essa verificação consiste basicamente em validar a chave primária, a obrigatoriedade de dados em campos NOT NULL, as integridades referenciais (chaves estrangeiras), as chaves de unicidade e checagem de dados (campos dt_hora_inicio e dt_hora_fim da tabela consulta). Aqui vamos aprender comandos relacionados à inserção, atualização e deleção dos dados nas tabelas.

148

UNIDADE 3 | SQL

Para isso ser possível, vamos começar utilizando um comando para inserir dados. É o comando insert, que tem sua sintaxe básica apresentada a seguir.

insert into nome_tabela (campo1, campo2, campoN) values (valor_campo1, valor_campo2, valor_campo3);

É um comando extremamente simples. Segue um código fonte da inserção de um paciente na tabela paciente.

insert into paciente (nr_sequencia, nm_paciente, cpf_paciente, fone_paciente)

values (1, 'Marcio Junior Silva', '16834865101', '(47)89899999');

Perceba que todos os campos do tipo varchar2 estão entre aspas simples. Isso é essencial para o correto funcionamento do comando. Para ver o que foi inserido no banco de dados, usamos o comando select.

select * from paciente;

O resultado é:

NR_SEQUENCIA NM_PACIENTE CPF_PACIENTE FONE_PACIENTE ------------ ---------- ------------ ------------1 MARCIO JUNIOR 16834865101 (47)89899999 SILVA

Para que você tenha um visão mais organizada dos dados selecionados via SQL Plus utilize os seguintes comandos:set linesize 1000;set pagesize 2000;alter session set NLS_DATE_FORMAT = 'DD/MM/YYYY HH24:mi:ss'

DICAS

Vamos agora validar algumas restrições que criamos na tabela paciente. A primeira é a de chave primária, ou seja, jamais poderemos conseguir incluir outro paciente com o campo nr_sequencia igual a 1. Vamos tentar?

TÓPICO 2 | MANUTENÇÃO DOS DADOS

149


values (1, 'Alberto Moreira', '66440726820', '(51)99578156');

ERRO na linha 1: ORA-00001: restrição exclusiva (SYSTEM.SYS_C007104) violada

Nossa restrição de chave primária está funcionando. O Oracle retornou em erro ORA-00001 informando que já existe outro registro com esse código.

Nossa próxima validação se refere a campos que não aceitam valores nulos. Vamos relembrar quais são os campos através de um comando desc na tabela paciente.

Nome Nulo? Tipo --------------------------- -------- ---------------- NR_SEQUENCIA NOT NULL NUMBER(6) NM_PACIENTE NOT NULL VARCHAR2(100) CPF_PACIENTE NOT NULL VARCHAR2(11) FONE_PACIENTE VARCHAR2(15)

O único campo que deve aceitar valores nulos é o fone paciente. Vamos tentar fazer um insert deixando o cfp_paciente com valor null.


values (2, 'Juliano Rosa', null, '(47)89899999');

ERRO na linha 2: ORA-01400: não é possível inserir NULL em ("SYSTEM"."PACIENTE"."CPF_PACIENTE")

Como pode ser visto acima, o Oracle não permite que o campo seja nulo, confirmando que a validação programada funciona corretamente.

Para ser possível realizar teste de validação da integridade referencial, precisamos antes inserir algum registro na tabela médico para posteriormente tentarmos inserir consultas. Note que, segundo nosso modelo de dados, a tabela consulta é filha das tabelas paciente e médico, por isso se faz necessário inserir dados de pacientes e médicos antes de alguma consulta.

Segue o comando para a inserção de um médico na tabela medico.

150

UNIDADE 3 | SQL

insert into medico (nr_sequencia, nm_medico, crm_medico, cpf_medico, fone_medico)

values (1, 'Jader Fonseca', '1002365', '94269268018', '(99) 12438080');

Se você desejar, pode fazer o comando select * from medico para visualizar os dados do médico cadastrado.

Finalmente, vamos inserir um registro na tabela consulta. Será uma consulta com o médico Dr. Jader Fonseca (nr_sequencia = 1) com data de início em 04/02/2013 15:00 e término as 04/02/2013 16:00. O paciente será o Marcio Junior Silva (nr_sequencia = 1). Segue o comando

insert into consulta (nr_sequencia, nr_seq_paciente, nr_seq_medico,dt_hora_inicio,dt_hora_fim)

values (1, 1, 1, to_date('04/02/2013 15:00:00', 'DD/MM/YYYY HH24:MI:SS'), to_date('04/02/2013 16:00:00', 'DD/MM/YYYY HH24:MI:SS'));

Note que usamos uma função to_date. Futuramente entraremos em mais detalhes sobre ela (seção 2.3 Conversão de dados). Apenas entenda que ela faz a conversão do tipo string para data. Veja o resultado do comando select * from consulta.

NR_SEQUENCIA NR_SEQ_PACIENTE NR_SEQ_MEDICO DT_HORA_INICIO DT_HORA_FIM DS_OBSERVACAO

1 1 1 04/02/2013 15:00:00 04/02/2013 16:00:00

A consulta foi inserida com sucesso. Agora vamos tentar cadastrar outra consulta para um paciente de código 10 (nr_sequencia da tabela paciente). Se nossa restrição de integridade estiver correta, esse comando não deverá funcionar. Veja o resultado.


values (1, 10, 1, to_date('04/02/2013 15:00:00', 'DD/MM/YYYY HH24:MI:SS'), to_date('04/02/2013 16:00:00', 'DD/MM/YYYY HH24:MI:SS'))

ERRO na linha 1:ORA-00001: restrição exclusiva (SYSTEM.SYS_C007105) violada

Como era esperado, o comando não funcionou. Não é possível incluir uma consulta para um paciente que não está cadastrado na tabela paciente.


151

Temos o mesmo tipo de restrição de unicidade na tabela médico para os campos de CPF e CRM. Com os conhecimentos obtidos até aqui você pode testar se tudo está funcionado. Sinta-se à vontade para realizar os devidos testes de funcionamento.

DICAS

Para finalizar nossos testes de restrição de integridade, falta testar a check constraint ou checagem de dados que fizemos na tabela consulta. Ela impede a criação de um registro quando a data de início da consulta é maior que a data final, ou seja, se uma consulta começou antes de terminar. Segue um insert com essa situação.


values (5, 1, 1, to_date('04/02/2013 16:00:00', 'DD/MM/YYYY HH24:MI:SS'), to_date('04/02/2013 15:00:00', 'DD/MM/YYYY HH24:MI:SS'))

ERRO na linha 1: ORA-02290: restrição de verificação (SYSTEM.TD_HORA_CONSULTA_CK) violada

Não é possível fazer uma inserção de consulta nesta situação. Terminamos aqui nossa validação de todos os tipos de restrições que criamos no nosso banco de dados. Fique à vontade para realizar novos testes, criar novos cenários. Com certeza isso irá lhe ajudar a compreender o funcionamento de um banco de dados.

Já que voltamos a falar desta tabela, vamos verificar o que acontece quando tentamos incluir novamente um CPF já cadastrado. Você lembra que criamos uma restrição de unicidade (chave única ou unique key) para o campo cpf_paciente? Criamos sim! Segue o comando com a inserção de outro paciente com o CPF do Márcio Júnior Silva (que já está cadastrado na tabela).


values (5, 'Mauricio Alves', '16834865101', '(99)89899999')

ERRO na linha 1: ORA-00001: restrição exclusiva (SYSTEM.PACIENTE_CPF_UK) violada

Novamente nossa restrição funcionou. Não é possível inserir o mesmo CPF mais de uma vez na tabela paciente.

152

UNIDADE 3 | SQL

Faça testes. Inclua registros nas tabelas e execute um commit. Inclua outros e efetue um rollback. Tente executar um rollback depois de executar um commit.

DICAS

2.3 CONVERSÃO DE DADOS

Anteriormente, quando trabalhamos com insert de data e hora utilizamos uma função to_date para fazer a conversão de string para o tipo date. Basicamente essa é a ideia chave das funções de conversão de dados. O Oracle trabalha com quatro funções distintas: to_char, to_number, to_date e nvl. O quadro a seguir mostra essas funções e detalha a sua aplicação.

2.2 TRANSAÇÕES

Na seção anterior, trabalhamos basicamente com os comandos insert e select para fazer a validação das restrições na nossa base de dados. Nossa metodologia para desempenhar tal tarefa foi inserir dados em tabelas e selecionar os mesmos para averiguação. Porém chegou a hora de uma grande revelação: os dados que você usou para fazer seus inserts ainda não estão gravados em definitivo nas tabelas. Inclusive se você fechar o SQL Plus e abri-lo novamente perceberá que os dados não vão estar mais disponíveis.

Para gravar os dados em definitivo é necessário executar o comando commit. Isso fará com que todas as inserções que foram feitas sejam gravadas em definitivo e disponibilizadas para todos os outros usuários do banco. Antes de um commit ser executado, os dados das tabelas que alteramos ficam disponíveis apenas para nós.

Esse é o funcionamento básico de uma transação. Morelli (2000) nos diz que uma transação é um conjunto de operações, comandos SQL, delimitada por um início e um fim. O fim pode ser um comando commit, que grava os dados em definitivo, ou um rollback, que desfaz todas as alterações que efetuamos na base até encontrar o último commit.

O funcionamento é bem simples. Para confirmar a gravação dos dados no banco, execute um commit. Se quiser desfazer a alteração, efetue um rollback. Não é possível desfazer as alterações com um rollback após ter dado um commit.


153

QUADRO 4 – FUNÇÕES DE CONVERSÃO DE DADOS DO ORACLE

Função Descrição

to_char(número ou data, ‘formato’)

Converte um campo numérico ou data em uma cadeia de caracteres do tipo varchar2, com o formato definido pela variável formato.

to_number(char) Converte uma cadeia de caracteres numérica em número inteiro

to_date(char, ‘formato’)

Converte uma cadeia de caracteres, especificando uma data, no tipo date, de acordo com a variável formato (se omitida, é assumido ‘DD-MMM-AA’).

nvl(coluna, valor) Converte um null que encontre na coluna, em um valor especificado.

FONTE: Morelli (2000 p. 37)

As funções to_char e to_date quando trabalham com datas possuem letras para definir o formato. O quadro a seguir mostra os principais formatos de conversão de data.

QUADRO 5 – FUNÇÕES DE CONVERSÃO DE DADOS DO ORACLE

Formato Descrição

YYYY Ano com 4 dígitos

MM Mês (01 – 12)

MON Nome abreviado do mês

WW Semana do ano (1 – 53)

W Semana do mês (1 – 5)

D Dia da semana (1 – 7)

DAY Nome do dia

DD Dia do mês (1 – 31)

DDD Dia do ano (1 – 366)

HH Hora do dia (1 – 12)

HH12 Hora do dia (1-12)

HH24 Hora do dia (0-23)

MI Minutos (0-59)

SS Segundos (0-59)

FONTE: Disponível em: <http://fazendoti.wordpress.com/2011/05/19/usando-a-funcao-to_date-em-oracle/>. Acesso em: 3 fev. 2013.

154

UNIDADE 3 | SQL

2.4 COMANDOS UPDATE E DELETE

Agora que você já conhece e utiliza os comandos insert e select ficará fácil de entender o update e delete. Eles servem respectivamente para atualizar ou apagar os dados em tabelas. Vamos começar explorando o comando update. Sua sintaxe está a seguir.

update nome_da_tabela set nome_campo1 = valor_campo1, nome_campo2 = valor_campo2, nome_campoN = valor_campoNwhere campo_restricao = valor_campo_restricao;

Para exercitar, vamos executar um update para o nosso paciente Márcio Júnior Silva (cujo campo nr_sequencia tem o valor 1), para modificar o seu telefone. Antes vamos fazer um select e verificar qual é o número do telefone que está cadastrado na base.

select nr_sequencia, nm_paciente, fone_paciente from paciente;

NR_SEQUENCIA NM_PACIENTE FONE_PACIENTE

------------ ------------- ----------------------

1 Marcio Junior Silva (47)89899999

O novo telefone dele deverá ser (47) 56897412. Segue o comando update.

Para exemplificar o uso de uma função que trabalhe com datas vamos ao seguinte comando.

select to_char(sysdate, ‘DD/MM/YYYY HH24:MI:SS’) from dual;

Se você executar esse comando, o resultado dele será a data do sistema juntamente com hora, minuto e segundo. É dessa forma que o Oracle trabalha com conversão de datas. Neste caso, o sysdate é um comando que retorna a data e hora atual do sistema e a tabela dual é uma espécie de tabela genérica do Oracle que existe para ser utilizada nessas situações.

Existem também várias outras funções que o Oracle disponibiliza para trabalhar com números, caracteres ou datas. Alguns exemplos podem ser vistos em <http://www.linknacional.com.br/criar-site/2011/11/funcoes-de-manipulacao-no-oracle/>.


155

update paciente set fone_paciente = '(47) 56897412' where nr_sequencia = 1;

commit;

É muito importante o uso da cláusula where, pois sem ela, todos os registros da tabela paciente ficariam com o mesmo telefone. Normalmente o campo que faz parte do where é o que identifica o registro que deve ser alterado, ou seja, a chave primária da tabela. Notem também a presença do commit, para gravar definitivamente a alteração na tabela. Vamos novamente executar um select para verificar o que aconteceu.

select nr_sequencia, nm_paciente, fone_paciente from paciente;

NR_SEQUENCIA NM_PACIENTE FONE_PACIENT------------ ------------------- ----------------------

1 Marcio Junior Silva (47) 56897412

Conforme pode ser visto, o telefone foi alterado. Dando continuidade, vamos ver como funciona o comando delete. Ele

tem a finalidade de eliminar registros de tabelas. Também necessita de um commit no final do processo para confirmar as alterações. Sua sintaxe básica é a seguinte:

delete from nome_tabela where campo_restricao = valor_campo_restricao;

Para testá-lo vamos novamente utilizar nosso paciente Márcio Júnior Silva (cujo campo nr_sequencia tem o valor 1). Vamos tentar apagá-lo da tabela paciente. Segue o comando.

delete from paciente where nr_sequencia = 1

ERRO na linha 1: ORA-02292: restrição de integridade (SYSTEM.CONSULTA_PACIENTE_FK) violada - registro filho localizado

Desta vez o comando não funcionou. Você se lembra da integridade referencial que existe entre a tabela consulta e paciente? É uma chave estrangeira na tabela consulta para o código do paciente. Anteriormente cadastramos uma consulta para ele e por isso não podemos excluir esse paciente. Uma consulta não pode ficar sem um paciente e caso o banco permitisse isso, teríamos um erro de integridade e dados não íntegros.

156

UNIDADE 3 | SQL

Se algum dia você desejar eliminar todos os registros de determinada tabela em uma única vez, não o faça por meio do comando delete. É mais performático

utilizar o comando truncate table nome_da_tabela e logo em seguida um commit.

DICAS

3 SELEÇÃO DE DADOSNeste ponto, já sabemos como inserir, alterar e excluir dados de tabelas

do banco. Tivemos uma pequena noção de seleção de dados, que foi necessária para validar as alterações que foram feitas com os comandos insert, update e delete. Agora chegou o momento de aprofundarmos um pouco nossos conhecimentos sobre o comando select.

Para conseguir apagar esse paciente, precisamos executar dois comandos delete. O primeiro para apagar todas as consultas que o paciente tem e o segundo para eliminar o seu cadastro da tabela paciente. Veja a seguir:

delete from consulta where nr_seq_paciente = 1;delete from paciente where nr_sequencia = 1;commit;

Aparentemente os registros foram excluídos. Note que no delete da tabela consulta não foi utilizado o campo nr_sequencia no where, mas sim o campo nr_seq_paciente que contém o código do paciente. Como a ideia era excluir todas as consultas do paciente de código = 1, a condição where buscou todas as consultas do paciente 1. Vamos selecionar os dados da tabela paciente para ver o que encontramos.

select * from paciente

não há linhas selecionadas

Na tabela paciente que estou utilizando não existem mais registros porque o Márcio Júnior Silva era o único que estava cadastrado. Caso você tenha mais pacientes e executar o comando select acima, todos os pacientes devem aparecer, menos o Márcio Júnior Silva.


157

Para isso ser possível, primeiro precisamos cadastrar mais dados em nossas tabelas. Seguem os comandos para inserção dos dados. Se desejar, você pode ignorar esses comandos e inserir seus próprios registros.


values (1, ‘Marcio Silva’, ‘16834865101’, ‘(47)89899999’);


values (2, ‘Juca Pedro’, ‘76820503903’, ‘(47)89748596’);


values (3, ‘Maria Quadros’, ‘62052125442’, ‘(47)12256897’);


values (4, ‘Pedro Almeida’, ‘84828752137’, ‘(47)89452541’);


values (5, ‘Josiane Silva’, ‘38145048524’, ‘(49)58574859’);


values (6, ‘Marcos Rocha’, ‘30305222619’, ‘(51)37865247’);


values (7, ‘Tiago Prado’, ‘18131028640’, ‘(39)85697454’);


values (8, ‘Augusto Pereira’, ‘03660633321’, ‘(41)45859687’);


values (9, ‘Priscila Chaves’, ‘67742258706’, ‘(45)25417896’);

158

UNIDADE 3 | SQL


values (10, ‘Marta Campos’, ‘43407732805’, ‘(49)65897485’);


values (1, ‘Jader Fonseca’, ‘1002365’, ‘94269268018’, ‘(99) 12438080’);


values (50, ‘Fernando Ferreira’, ‘105263’, ‘56624682736’, ‘(45) 58996452’);


values (51, ‘Marleide Benta’, ‘1089745’, ‘21764632184’, ‘(48) 49564586’);


values (52, ‘Cabral Rodrigues’, ‘2035698’, ‘13167468106’, ‘(44) 89745214’);


values (100, 1, 1, to_date(‘04/02/2013 20:00:00’, ‘DD/MM/YYYY HH24:MI:SS’), to_date(‘04/02/2013 21:00:00’, ‘DD/MM/YYYY HH24:MI:SS’));






159

















160

UNIDADE 3 | SQL


















161





Depois de colocarmos dados nas tabelas, vamos adiante. Um comando select tem várias particularidades e detalhes. Segue uma sintaxe básica:

select [distinct] coluna1, coluna2, colunaNfrom tabela1, tabela2, tabelaNwhere condições[group by colunas][having [condição][order by colunas]

Vamos apresentar alguns exemplos de comandos select com tudo o que está apresentado nesta sintaxe. Porém, vamos iniciar pelo básico. Segue um select que tem como objetivo listar o nome de todos os médicos que tem telefone informado.

select nm_medicofrom medicowhere fone_medico is not null;

Segue o resultado do comando.

NM_MEDICO ------------------------------------------------------Jader FonsecaFernando FerreiraMarleide BentaCabral Rodrigues

Neste select, a cláusula where é responsável por filtrar se todos os telefones tem valor informado (se são não nulos). Em outros momentos ela pode servir também para fazer joins entre tabelas, ou seja, quando eu necessito acessar mais de uma tabela para recuperar os dados, é feito a junção através dos campos que compõem o relacionamento.

162

UNIDADE 3 | SQL

Veja no exemplo a seguir, um select que mostra todas as consultas realizadas no período de 01/01/2012 até 31/01/2013. Os dados que serão buscados são o nome do médico, a data da consulta e o nome do paciente.

select b.nm_medico, a.dt_hora_inicio, c.nm_paciente from consulta a, medico b, paciente cwhere a.dt_hora_inicio between to_date(‘01/01/2012

00:00:00’, ‘DD/MM/YYYY HH24:MI:SS’) and to_date(‘31/01/2013 23:59:59’, ‘DD/MM/YYYY

HH24:MI:SS’)and b.nr_sequencia = a.nr_seq_medicoand c.nr_sequencia = a.nr_seq_pacienteorder by a.dt_hora_inicio; O comando between serve para informar o Oracle para buscar dados

dentro de um intervalo definido, que no caso acima é um período de datas. Esse comando é um filtro dentro do select. Já as duas linhas em destaque são joins das tabelas médico e paciente com a tabela consulta. Note que o acesso é feito pelos campos que compõem a chave estrangeira. Foi utilizado a cláusula order by que serve apenas para ordenar os dados. Segue o resultado:

NM_MEDICO DT_HORA_INICIO NM_PACIENTE ----------------------- ------------------- ----------Jader Fonseca 20/02/2012 15:00:00 Tiago PradoCabral Rodrigues 19/07/2012 15:30:00 Marcio Junior SilvaCabral Rodrigues 14/09/2012 14:00:00 Josiane SilvaFernando Ferreira 02/12/2012 19:00:00 Maria QuadrosJader Fonseca 11/01/2013 14:00:00 Josiane Silva

Ao invés de listar as datas e nome dos pacientes, poderíamos apenas contar por médico quantas consultas eles atenderam no mesmo intervalo de datas. Usaríamos uma função de agrupamento de dados para obter esse resultado. O comando pode ser visto a seguir:

select b.nm_medico, count (a.nr_sequencia)from consulta a, medico bwhere a.dt_hora_inicio between to_date(‘01/01/2012


HH24:MI:SS’)and b.nr_sequencia = a.nr_seq_medicogroup by b.nm_medico;

As partes em destaque no comando fazem parte do agrupamento de dados. A função count conta o número de consultas. Sempre que trabalhamos com esse tipo de função precisamos usar o group by e informar todos os campos que não estão sendo contados. Existem outras funções para agrupamento de valores como o max e o min que buscam o valor maior e o valor menor respectivamente.


163

Segue o resultado do comando:

NM_MEDICO COUNT(A.NR_SEQUENCIA)------------------------ -------------------- Cabral Rodrigues 2 Jader Fonseca 2 Fernando Ferreira 1

Para finalizarmos nosso tópico, vamos falar sobre o having. Este comando tem a finalidade de aplicar um filtro nos dados depois de eles serem agrupados. Para exemplificar, vamos fazer com que no select acima sejam retornados somente os médicos com duas consultas. Segue o comando e o resultado:

select b.nm_medico, count (a.nr_sequencia)from consulta a, medico bwhere a.dt_hora_inicio between to_date(‘01/01/2012


HH24:MI:SS’)and b.nr_sequencia = a.nr_seq_medicogroup by b.nm_medicohaving count (a.nr_sequencia) = 2;

NM_MEDICO COUNT(A.NR_SEQUENCIA)------------------------ -------------------- Cabral Rodrigues 2 Jader Fonseca 2

Retornaram somente os médicos com duas consultas.

Existe uma infinidade de recursos e funcionalidades avançadas que são possíveis de aplicar ao comando select. O que foi passado neste Caderno de Estudos é apenas uma forma introdutória de seleção de dados. Você pode consultar a bibliografia da disciplina se deseja aprofundar ainda mais os seus estudos.

164

UNIDADE 3 | SQL

SITE PROTEGIDO CONTRA SQL INJECTION E CONCEITUAÇÃO

A Injeção de SQL, mais conhecida através do termo americano SQL Injection, é um tipo de ameaça de segurança que se aproveita de falhas em sistemas que interagem com bases de dados via SQL. A injeção de SQL ocorre quando o atacante consegue inserir uma série de instruções SQL dentro de uma consulta (query) através da manipulação das entradas de dados de uma aplicação.

Funcionamento

Para exemplificar o funcionamento da injeção de SQL, vamos considerar uma instrução SQL comum:

SELECT id, nome, sobrenome FROM autores;

Essa instrução, que representa uma consulta na base de dados, retorna todos os registros das colunas “id”, “nome” e “sobrenome” da tabela “autores”. A partir desta mesma instrução, os registros a serem retornados podem ser restritos através da inclusão da cláusula WHERE, como é visto no exemplo abaixo:

SELECT id, nome, sobrenome FROM autores WHERE nome = ‘josé’ AND sobrenome = ‘silva’;

Com base nesta instrução, é fácil supor que “josé” e “silva” são strings, cujo conteúdo será preenchido pela entrada feita por algum usuário que estiver fazendo uso da aplicação.

Portanto, supondo que a aplicação não faça o tratamento apropriado do conteúdo inserido pelo usuário, o mesmo pode fazer o uso acidental do caractere de aspas simples. Gerando a entrada: nome = jo’sé e sobrenome = silva, fazendo com que a aplicação gere o código:

Caro(a) acadêmico(a)! A Leitura Complementar a seguir fala sobre um tema que é muito comentado principalmente no mundo WEB: a injeção de dados maliciosos em comandos SQL. Visando obter vantagens de acesso ou até mesmo a invasão de um sistema, pessoas mal intencionadas fazem uso desta vulnerabilidade.

UNI



165

SELECT id, nome, sobrenome FROM autores WHERE nome = ‘jo’sé’ AND sobrenome = ‘silva’;

De acordo com a especificação da linguagem SQL, existe um erro de sintaxe nessa instrução, uma vez que a string passada para o campo nome é a apenas palavra “jo”, pois a adição das aspas simples quebrou a delimitação das aspas simples originais da consulta. O interpretador do SQL espera que o restante da instrução seja outros comandos SQL válidos que complementem a instrução principal. No entanto, como “sé” não é um identificador válido, essa instrução não será executada e retornará um erro.

Com base neste problema, um possível atacante pode manipular os dados de entrada a fim de gerar um comportamento não esperado na base de dados.

Para exemplificar este conceito, consideremos na mesma consulta apresentada, a entrada dos seguintes dados pela aplicação: nome = jo’; DROP TABLE autores ; -- sobrenome = silva, fazendo com que a aplicação gere o código:

SELECT id, nome, sobrenome FROM autores WHERE nome = ‘jo’; DROP TABLE autores ; --’ AND sobrenome = ‘silva’;

Neste caso, a instrução será executada normalmente, pois não há um erro de sintaxe, no entanto, com a adição do caractere ponto-e-vírgula, a instrução foi dada como finalizada de modo prematuro dando espaço para uma nova instrução. Essa nova instrução, que poderia ser qualquer uma escolhida pelo atacante, pode ser a responsável por retornar dados confidenciais armazenados na base de dados ou de executar instruções que comprometam o sistema, como a remoção de dados e/ou tabelas, como pode ser visto no exemplo apresentado.

Aparentemente um método para prevenir esse problema seria a remoção de aspas simples dos campos de inserção da aplicação, ou simplesmente não executando a query nestas situações. Isso é verdade, mas existem várias dificuldades com esse método tanto quanto soluções. Primeiro, nem todos os usuários inserem dados em forma de strings. Se o usuário puder selecionar um autor pelo ‘id’ (presumivelmente um número), por exemplo, nossa query aparecerá como abaixo:

SELECT id, forename, surname FROM authors WHERE id=1234

Nesta situação, o atacante pode simplesmente adicionar uma instrução SQL no fim do ‘input’ numérico. Verificando os dialetos de SQL, vários delimitadores podem ser usados no Microsoft Jet DBMS engine, por exemplo, datas podem ser delimitadas com o caracter sustenido. Portanto, escapando da execução da adição de aspas simples, não necessariamente uma solução como demonstrado anteriormente.

FONTE: Disponível em: <http://www.2bweb.com.br/Artigos-software-Web/site-protegido-contra-sql-injection-e-conceituacao.cfm>. Acesso em: 3 fev. 2013.

166

RESUMO DO TÓPICO 2


• O comando insert serve para inserir dados em tabelas.

• O comando update atualiza dados em tabelas.

• O comando delete apaga dados em tabelas.

• Existem vários modos de fazer a validação das restrições em tabelas.

• O comando select seleciona os dados de um banco de dados.

167

AUTOATIVIDADE

1 Faça um comando select que liste todos os nomes de pacientes em ordem alfabética.

2 Tente apagar algum médico que possua uma consulta. É possível fazer isso? Se não for, explique o motivo.

3 Escolha uma das consultas cadastradas na tabela consulta e tente colocar o valor 599 para o campo nr_seq_paciente. Relate o que aconteceu.

4 Para fins de otimização de performance, que comando deve ser utilizado para apagar todos os registros de determinada tabela?

5 Que comando pode ser utilizado para contar registros em um select que utiliza uma função de agrupamento de dados?

169

TÓPICO 3

OUTRAS ESTRUTURAS DE DADOS

UNIDADE 3

1 INTRODUÇÃO

“Não são as ervas más que afogam a boa semente, e sim a negligência do lavrador”. (Confúcio)

Chegamos ao último tópico deste Caderno de Estudos. Com muito esforço e determinação estamos concluindo a disciplina de princípios de bancos de dados. O conteúdo que será apresentado nesta última parte é composto de algumas estruturas de bancos de dados que ainda não vimos.

FIGURA 61 – CHEGAMOS À RETA FINAL

FONTE: Disponível em: <http://run-x.blogspot.com.br/2010_03_01_archive.html>. Acesso em: 4 fev. 2013.

Elas servem basicamente para complementar tudo o que já foi visto, em alguns casos até automatizando comandos que antes fazíamos “no braço”. Está dividida em dois momentos: o primeiro trata de alguns objetos de bancos de dados e o segundo lista alguns recursos da linguagem PL/SQL.

Novamente desejo a você bons estudos!

UNIDADE 3 | SQL

170

2 OBJETOS DE BANCOS DE DADOSEsta seção tem como objetivo apresentar estruturas de dados de um banco.

As mesmas visam dar suporte a uma gama de recursos que complementam o trabalho de armazenar e recuperar dados.

De uma forma geral, vamos discutir sobre três itens: índices, sequences e views. Daremos exemplos de um uso cotidiano apresentando a necessidade de uma forma detalhada.

2.1 ÍNDICES

É um tipo de estrutura que tem como objetivo facilitar o acesso dos dados pelo banco de dados. Está diretamente ligado a questões de desempenho e diminuição do uso de recursos do servidor no qual o banco está disponível (se você instalou o Oracle na sua máquina, ela é o servidor).

Morelli (2000, p. 69) nos dá uma definição do que é um índice.

Índices (index) são estruturas especiais inseridas no banco de dados com o objetivo de melhorar o desempenho de acesso às tabelas. Sua função é reduzir o I/O em disco utilizando uma estrutura de árvore binária (B*Tree) para localizar rapidamente os dados. Ao varrer a árvore binária, ele identifica a chave e recupera o seu rowid, ponteiro para acesso ao dado, localizando o registro rapidamente. O Oracle cria automaticamente um índice do tipo unique ao criar uma chave primária, o qual recebeu o mesmo nome da constraint.

Entenda que rowid é um indentificador único de registros gravados em tabelas. Ele tem certa relação com índices. Segue a sintaxe de criação de um índice.

create index nome_do_indice on tabela (nome_campo);

A sintaxe é extremamente simples. Índices na sua forma mais básica são criados em campos que fazem parte de relacionamentos. Seguindo esta linha, precisamos criar dois índices no nosso modelo de dados e ambos na tabela consulta. Seguem os comandos:

create index nr_seq_paciente_fk_i on consulta (nr_seq_paciente);

create index nr_seq_medico_fk_i on consulta (nr_seq_medico);

TÓPICO 3 | OUTRAS ESTRUTURAS DE DADOS

171

O texto a seguir trata sobre algumas dicas para a criação de índices no que se refere a situações quando devem ser criados.

UNI

DICAS PARA CRIAÇÃO DE ÍNDICE Deparei com um material bem interessante que traz algumas “premissas”

para a criação de índices.

Segue a lista de sugestões:

Crie índices quando:

Uma coluna contiver uma grande faixa de valores.Uma coluna contiver muitos valores nulos.Quando uma ou mais colunas forem usadas frequentemente em clausulas

WHERE ou em JOINS.Se a tabela for muito grande e as consultas realizadas recuperarem menos

de 5% dos registros.

NÃO crie índices quando:

As colunas não são usadas frequentemente como condição nas consultas.A tabela for pequena ou se os resultados das consultas forem maiores que

5-10% dos registros.A tabela for atualizada com frequência.As colunas fizerem parte de uma expressão* Nesse item entende-se por expressão algo na cláusula where tipo:

SELECT TABLE_NAMEFROM ALL_TABLESWHERE TABLE_NAME||OWNER = ‘DUALSYS’Observe que na cláusula de comparação as colunas TABLE_NAME e

OWNER fazem uma expressão de comparação e por consequência um índice não ajudaria em nada.

UNIDADE 3 | SQL

172

Outras coisas importantes de lembrar:

ÍNDICES NÃO SÃO ALTERÁVEIS! (Para alterar um índice você deve removê-lo e recriá-lo.)

ÍNDICES ONERAM A PERFORMANCE DE INSERT / UPDATE (Não dá para fazer milagres, se sua tabela tiver muitos índices as performances de alterações podem ser comprometidas).

FONTE: Disponível em: <http://www.dartanghan.com.br/oracledb/oracle-index-dicas-para-criacao-de-indice/>. Acesso em: 4 fev. 2013.

2.2 SEQUENCES

Este tipo de estrutura visa gerar sequências de números, que na maioria das vezes são utilizadas em chaves primárias de tabelas. É basicamente um objeto que gera valores numéricos toda vez que for solicitado, porém sempre em sequência, incrementando os valores para que eles não se repitam.

Pense no nosso modelo de dados. Para as tabelas médico, consulta e paciente poderia existir uma sequence para cada uma delas. Ao invés de fazermos o insert com números fixos, poderíamos chamar uma sequence para gerenciar a inserção dos campos nr_sequencia. De uma forma geral, esta é a função de uma sequence.

Segue a sintaxe do comando para criação de uma sequence segundo Morelli (2000).

create sequence sequencia [increment by n] [start with n] [maxvalue n | nomaxvalue] [cycle | nocycle] [cache n | nocache];

QUADRO 6 – DETALHE DOS ITENS DA SINTAXE

Opção Descrição

sequencia Nome da sequência que não pode ser o nome de uma tabela ou view.

increment by n Especifica de quanto será o incremento ou decremento da sequência. O default é 1.

start with n Especifica o primeiro número a ser gerado. O default é 1.

maxvalue n Especifica o valor máximo que a sequência pode assumir. O default é nomaxvalue, indo até 1027.


173

FONTE: Morelli (2000, p. 73)

minvalue nEspecifica o valor mínimo para sequências que estejam sendo decrementadas. É mutuamente exclusiva à anterior.

cycle | nocycleIndica que, quando atingir o valor máximo, a numeração continuará a partir do valor inicial. O default é nocycle.

cache n | nocache Especifica quantos valores o Oracle pré-aloca e mantém em memória. O default é 20.

Visando um pouco de prática, vamos criar uma sequence para a tabela paciente.

create sequence nr_sequencia_paciente_sequ maxvalue 999999;

Note que o número máximo da sequence será 999999 porque na definição do campo nr_sequencia da tabela paciente temos um numérico de seis posições. Vale a pena ressaltar que uma sequence não tem vínculo nenhum com tabela ou campo, entretanto pode não ser correto declarar uma sequence com tamanho incompatível com o do campo onde ela será utilizada.

Para buscar o próximo número da sequence criada acima, podemos usar nr_sequencia_paciente_seq.nextval. Já para retornar o valor corrente usamos o nr_sequencia_paciente_seq.currval. Para fins de testes é possível fazer o select seguinte para retornar valores das sequences.

select nr_sequencia_paciente_sequ.nextval from dual

NEXTVAL---------- 1

select nr_sequencia_paciente_sequ.currval from dual CURRVAL---------- 1

UNIDADE 3 | SQL

174

Para fins de lembrança, como foi abordada anteriormente a tabela dual é uma espécie de tabela coringa no Oracle e serve para utilizar nesses casos em que precisamos retornar valores.

DICAS

Segue o exemplo de um comando insert utilizando a sequence criada.

insert into paciente (nr_sequencia, nm_paciente, cpf_paciente)

values (nr_sequencia_paciente_sequ.nextval, 'Alberto Antunes', '21724524593');

Se acaso for utilizado o comando nextval na sequence ela incrementará o seu valor atual. Quando for feito um nextval e o valor não for utilizado, o mesmo será “perdido”, pois sempre que a sequence é requisitada com nextval ela muda o seu valor.

O texto a seguir compara o comportamento de uma sequence no Oracle com os recursos que outros bancos de dados disponibilizam.

UNI

SEQUÊNCIAS ORACLE

Se você utiliza MS Access, deve conhecer o tipo de dados AutoNumber, que pode ser utilizado para definir uma coluna de tabela preenchida automaticamente com valores numéricos exclusivos. Com efeito, quando se cria uma tabela em MS Access e se esquece de definir uma chave primária, o aplicativo oferecerá a criação de uma coluna de PK. Se aceita, observe que o MS Access cria uma coluna chamada ID com tipo de dados AutoNumber. Após definir uma coluna com AutoNumber, todas as vezes em que uma linha for inserida na tabela, o MS Access adicionará automaticamente um valor a essa coluna, começando com 1 e aumentando em uma unidade a cada nova linha adicionada. Além disso, não é possível incluir esta coluna em comandos insert – o Access não permite editar esse valor de modo algum. O MS SQL Server


175

utiliza a propriedade da coluna “Identity” (identidade) para atender a uma finalidade similar. Em MS SQL Server, uma tabela pode ter, no máximo, uma coluna definida como “Identity”. Essa coluna se comporta de modo similar a coluna do MS Access com tipo de dados AutoNumber.

O Oracle não dá suporte ao tipo de dados AutoNumber ou à propriedade de coluna “Identity”. Em vez disso, pode-se utilizar uma “sequencia” para atribuir valores a uma coluna de tabela. Mas as sequencias do Oracle são muito diferentes do AutoNumber do Access e merecem uma análise mais detalhada.

- São objetos independentes no banco de dados (não são um tipo de dados).- Possuem um nome e podem ser utilizadas em qualquer posição de comando

em que se espere um valor.- Não são atreladas a uma tabela ou coluna.- Geram um valor numérico automático que pode ser atribuído a qualquer

coluna de qualquer tabela.- O atributo de tabela ao qual é atribuído um valor com base em sequência pode

ser editado e modificado.- É possível editar e excluir uma sequência do Oracle a qualquer momento.


2.3 VIEWS

Uma view é uma espécie de tabela virtual que o Oracle disponibiliza para visualização de dados. Ela pode ter diversos fins, como formatação de dados, obtenção de informações calculadas com base em dados, segurança etc. É um objeto que está construído para retornar informações de um select.

Rob e Coronel (2011, p. 294) nos dão um exemplo de aplicabilidade das views.

Suponha que, no fim de cada dia, deseje-se obter uma lista de todos os produtos que devem ser encomendados, ou seja, produtos cuja quantidade disponível é menor ou igual a uma quantidade mínima. Em vez de digitar a mesma consulta no fim de cada dia, não seria melhor salvar essa consulta de forma permanente no banco de dados? Essa é a função de uma visualização relacional. Uma visualização é uma tabela virtual baseada em uma consulta select.

Na citação acima entenda visualização relacional como um termo designado para definir uma view. Segue a sintaxe básica da criação de uma view.

create view nome_da_view as comando select;

Não existe muito segredo quanto a sua definição. O comando é extremamente simples. Entretanto, vale a pena ser discutida a sua aplicação.

UNIDADE 3 | SQL

176

Morelli (2000) cita dois exemplos onde à criação de uma view pode ser aplicada. No primeiro, ele explica que uma view pode ser criada para evitar que usuários não autorizados tenham acesso a todos os dados de uma tabela. Para isso, cria-se uma visão com apenas uns campos.

Outro exemplo que esse mesmo autor nos dá se refere à associação de uma visão a consultas que utilizam critérios de seleção complexos, facilitando assim a vida dos usuários.

Voltando novamente o foco para o nosso modelo de dados, poderíamos criar uma visão para mostrar todas as consultas que um médico vai atender ou já atendeu e seus respectivos pacientes. Assim, teríamos facilidade maior em fazer uma pesquisa com os dados. Segue o comando de criação da view.

create or replace view medico_consulta_paciente asselect a.nr_sequencia nr_seq_medico, a.nm_medico, a.crm_medico, a.cpf_medico, a.fone_medico, b.nr_sequencia nr_seq_consulta, b.dt_hora_inicio,b.dt_hora_fim, b.ds_observacao, c.nr_sequencia nr_seq_paciente, c.nm_paciente, c.cpf_paciente, c.fone_pacientefrom medico a, consulta b, paciente cwhere b.nr_seq_medico = a.nr_sequenciaand c.nr_sequencia = b.nr_seq_paciente;

A partir de agora, os comandos de seleção de dados ficam mais fáceis. Por exemplo, se desejarmos uma lista de médicos com todos os pacientes que já se consultaram ou vão se consultar, apenas buscamos os campos que precisamos sem necessidade de acessar mais de uma tabela.

select distinct nm_medico, nm_paciente from medico_consulta_pacienteorder by nm_medico

E o resultado é:


177

NM_MEDICO NM_PACIENTE ---------------------------------------- ---------------Cabral Rodrigues Augusto PereiraCabral Rodrigues Marcio Junior SilvaCabral Rodrigues Josiane SilvaFernando Ferreira Marcio Junior SilvaFernando Ferreira Marta CamposFernando Ferreira Marcos RochaFernando Ferreira Maria QuadrosJader Fonseca Josiane SilvaJader Fonseca Maria QuadrosJader Fonseca Juca PedroJader Fonseca Marcio Junior SilvaJader Fonseca Juca PedroJader Fonseca Tiago PradoMarleide Benta Marcio Junior SilvaMarleide Benta Priscila ChavesMarleide Benta Pedro Almeida

Perceba que foi utilizado o comando distinct no select porque um paciente pode ter consultado mais de uma vez um médico e caso o distinct seja retirado, alguns registros irão se repetir.

O comando distinct normalmente está relacionado a uma performance baixa no momento da execução do mesmo. Ele torna, em alguns casos, o trabalho de retornar um resultado um pouco mais lento que o normal. Utilize-o somente em casos quando for extremamente necessário.

ATENCAO

3 PL/SQLAté este momento você aprendeu a utilizar comandos SQL para criar

estruturas de dados como tabelas, índices, sequences, views etc. Outro foco era a manipulação de dados, com comandos de inserção, atualização, deleção e seleção.

A partir deste momento, vamos falar de uma linguagem procedural, com comandos de if/else, while, for etc. Estamos nos referindo a PL/SQL, a linguagem implementada pelo banco de dados Oracle.

Outros bancos também têm suas linguagens próprias, como é o caso do PostgreSQL que utiliza o PgSQL como sua linguagem de programação. Essa abordagem traz alguns benefícios, dentre eles uma melhoria no desempenho e uma centralização das regras de negócio.

UNIDADE 3 | SQL

178

Em relação à centralização de regras de negócio, Rob e Coronel (2011, p. 360) fazem uma breve consideração.

Uma abordagem melhor é isolar o código fundamental e, em seguida, fazer com que todos os aplicativos chamem esse código compartilhado. A vantagem de tal abordagem modular é que o código de aplicação é isolado em um único programa, resultando, assim, em melhor controle de manutenção e lógica.

Quanto à melhoria de desempenho, podemos considerar um fato bem básico. Quando os dados são todos processados dentro do próprio banco de dados, eles não trafegam pela rede, diminuindo bastante o tempo de resposta. Claro que essa afirmação pode sofrer variações, pois ela não é verdadeira no caso em que a máquina que hospeda o banco de dados não tenha um bom poder de processamento.

Focando especificamente no PL/SQL, vamos ver apenas quatro recursos de programação: procedure, function, package e triggers. A linguagem PL/SQL possui uma série de outros recursos, entretanto o que vamos mencionar faz parte da base da linguagem e é pré-requisito para adquirir conhecimentos mais avançados.

3.1 PROCEDURES

Uma procedure é um agrupamento de comandos SQL que podem conter estruturas de seleção, controle e repetição para gerenciá-los. Uma das características é que uma procedure pode fazer alterações de dados em tabelas e não retorna um valor no final do seu processamento.

Como a linguagem PL/SQL tem vários recursos no que se refere à programação, não vamos mais trabalhar com a ideia de sintaxe dos comandos. Ao invés disso, vamos apresentar um exemplo de uma necessidade acompanhada da implementação do código fonte.

Voltando para o nosso modelo de dados, suponhamos que seja necessário atrasar uma determinada consulta em um dia. Podemos criar uma procedure que recebe o código da consulta (nr_sequencia da tabela consulta) e executa um update no horário de início e horário de fim. Caso a solicitação de atraso tenha sido solicitada pelo paciente, colocar uma mensagem no campo ds_observacao com os seguintes dizeres: “Paciente solicitou alteração de data da consulta. A data antiga era em data_antiga”.

O código fonte a seguir mostra a implementação desta procedure.

create or replace procedure p_atrasa_consulta

( p_consulta consulta.nr_sequencia%type , p_solic_paciente varchar2) is

l_data_hora_inicio_ant date;


179

begin

-- se atraso foi solicitado pelo paciente-- busca as datas antigas para armazenar no campo ds_

observacaoif(p_solic_paciente = 'S') then

select dt_hora_inicio into l_data_hora_inicio_ant from consulta where nr_sequencia = p_consulta;

-- atualiza o campo de observação update consulta set ds_observacao = 'Paciente solicitou

alteração de consulta. A data antiga era ' || to_char(l_data_hora_inicio_ant, 'DD/MM/YYYY HH24:MI:SS')

where nr_sequencia = p_consulta;

end if;

-- atrasa a consulta em um diaupdate consulta set dt_hora_inicio = dt_hora_inicio + 1,

dt_hora_fim=dt_hora_fim+1where nr_sequencia = p_consulta;

end p_atrasa_consulta;

Se sua base de dados contém uma consulta cujo nr_sequencia = 110, o comando a seguir executa a procedure, fazendo com que a data seja alterada e a observação gerada.

exec p_atrasa_consulta(110, ‘S’);commit;

3.2 FUNCTION

Uma function tem os mesmos princípios de uma procedure, porém retorna um valor no final de sua execução. Vamos a um exemplo prático: todo CPF válido deve ter 11 caracteres. Vamos fazer uma function que recebe um CPF e retorna S no caso de ter 11 caracteres e N para qualquer outro caso. Segue o código fonte.

create or replace function f_valida_cpf(p_cpf varchar2) return varchar2 is

l_result varchar2(1);

UNIDADE 3 | SQL

180

beginl_result := 'N';

if(length(p_cpf) = 11) then l_result := 'S';end if;

return l_result;

end f_valida_cpf;

Para testar a função você pode usar o comando a seguir, variando o número do CPF que é passado para a função.

select f_valida_cpf(‘numero do cpf’) from dual;

Para fins de esclarecimento, o número do CPF possui uma fórmula para validação. Como nosso foco aqui é meramente educativo, decidimos validar apenas a presença de 11 caracteres.

ATENCAO

3.3 PACKAGES

Até o momento, vimos o conceito de procedure e function. Tivemos um exemplo de declaração de cada tipo para elucidar a forma de trabalho de uma linguagem de banco de dados procedural. Com o passar do tempo, quando programamos, muitas vezes, percebemos que determinada function está ligada logicamente a um conceito que uma procedure pode abranger.

Nesse ponto entra o conceito de package. É um agrupamento de procedures, functions e outros objetos que estão relacionados a alguma situação específica. É uma espécie de empacotamento de funcionalidades com um foco comum. Segue uma package com o nome teste_package.

create or replace package teste_package is--definiçãodefunctionseprocedures(somenteadefinição)

create or replace function f_valida_cpf(p_cpf varchar2) returnvarchar2;

end teste_package;

create or replace package body teste_package is


181

--definiçãodefunctionseprocedures(definiçãoeimplementação)

create function f_valida_cpf(p_cpf varchar2) returnvarchar2is

l_result varchar2(1);

begin l_result := 'N';

if(length(p_cpf) = 11) then l_result := 'S'; end if;

return l_result;

end f_valida_cpf;

end teste_package;

Perceba que a criação de uma package é dividida em dois momentos. O primeiro contém apenas o cabeçalho das procedures ou functions e o segundo trata da definição propriamente dita. A função f_valida_cpf foi incluída para fins de demonstração. Se uma function ou procedure for criada dentro do body de uma package e não for declarada no cabeçalho, a mesma não poderá ser acessada por comandos que estejam fora da package. Segue um exemplo para executar a função criada em uma estrutura de package.

select teste_package.f_valida_cpf(‘numero do cpf’) from dual;

3.4 TRIGGERS

Uma trigger tem a finalidade de executar alguma rotina de programação quando são feitas manutenções ou inserções de registros em tabelas. É basicamente um gatilho que é acionado conforme foi designado na sua programação.

É possível, por exemplo, a criação de uma trigger que execute determinado comando quando for dado update em alguma tabela. Isso vale também para ações de insert e delete.

Algumas aplicações práticas são: log dos dados alterados, alimentação de dados redundantes, validação das informações inseridas ou atualizadas etc. Nosso exemplo irá supostamente tratar a inserção de CPF inválido na tabela paciente. Sempre que um CPF for considerado inválido, o Oracle emitirá uma mensagem de erro. Segue a implementação.

UNIDADE 3 | SQL

182

create or replace trigger valida_cpf_pacientebefore insert or update on pacientefor each rowbeginif(f_valida_cpf(:new.cpf_paciente) = 'N') then raise_application_error(-20500, 'CPF inválido');end if;end valida_cpf_paciente;

Uma trigger tem uma forma interessante de acessar os valores da tabela que está sendo alterada. Ela usa :new.nome_do_campo para buscar o valor após a alteração e :old.nome_do_campo para retornar o valor antigo. Para executar a trigger, realize um update na tabela paciente em algum CPF como no exemplo a seguir.

update paciente set cpf_paciente = '565' where nr_sequencia = 11;

Esse comando fará com que a trigger seja disparada e retorne um erro, pois o CPF só tem três caracteres. Não se esqueça de trocar o nr_sequencia = 11 para nr_sequencia = algum nr_sequencia cadastrado na sua base. Se acaso tudo estiver certo, a trigger não irá gerar erro algum.

Caro(a) acadêmico(a)! A Leitura Complementar a seguir traz uma visão sobre performance em PL/SQL. Ele trata de duas questões: a troca de contexto e o manutenção de dados em tabelas temporárias. Entenda a troca de contexto como um comando SQL sendo executado dentro de um PL/SQL e tabelas temporárias como sendo a mesma filosofia de uma tabela normal, porém seus dados são temporários, ou seja, quando o scritp terminar de executar a tabela estará vazia.

UNI


183


DICAS PARA OBTER PERFORMANCE EM PL/SQL

O primeiro tópico que eu gostaria de abordar é questão da troca de contexto. Muita gente não sabe disso, então convém citar uma breve introdução. No Oracle, existem duas engines distintas que vão se encarregar de fazer o parse do seu código e executá-lo: a engine SQL e a engine PL/SQL. Acontece que, quando você envia para o Oracle um comando SQL, ele vai diretamente para a engine SQL para executar a validação do comando, o parse, a elaboração do plano e por fim a execução e fetch. Agora, se você envia um comando PL/SQL, tudo aquilo que não for relacionado ao SQL é executado pela engine de PL/SQL, como por exemplo, alocação de memória para arrays, atribuição de variáveis, cálculos, etc. Porém, quando o seu bloco chega em uma instrução SQL, ele vai simplesmente passar a informação adiante para a engine SQL processar. Neste evento ocorre a chamada troca de contexto, que nada mais é o ponto onde a engine PL/SQL para e passa o controle para a engine SQL.

O que acontece é que esta troca de contexto tem um custo para o banco... no meu banco eu fui capaz de medir em uma situação muito especifica um tempo de troca de contexto da ordem de 18us (microssegundos). Parece pequeno, mas não é. Pense neste tempo dentro de um loop for que executa um milhão de vezes, por exemplo.

Um caso típico de troca de contexto que pode ser otimizada é o “Select ... Into ... From Dual;”. Muita gente utiliza este comando com o objetivo de atribuir valores a variáveis, quando na verdade deveria estar simplesmente fazendo a atribuição da forma “x := y;” que não envolve nenhuma troca de contexto.

Remover a troca de contexto desnecessárias de blocos PL/SQL em processos intensivos foi responsável, na minha experiência prática, por ganhos de até 30% na velocidade de execução. Já houve um tempo que o PL/SQL não dispunha da maioria das funções disponíveis no SQL, porém hoje em dia a grande maioria está implementada nas duas engines e, portanto, não há mais necessidade de fazer chamadas com Select from dual. Uma exceção que eu poderia citar é a função REVERSE (que inverte uma string) que, pelo menos na versão do banco que eu estou trabalhando (10g R2), não existe no PL/SQL. Podem existir outras exceções, mas o importante é remover aqueles pontos que não há necessidade.

Outra questão que gera grande degradação de performance em processos é o uso excessivo de tabelas temporárias. Eu sei que esta é uma prática herdada de outros bancos, mas no Oracle o abuso destas tabelas pode dar muita dor de cabeça. Num outro caso de tuning de sucesso que eu executei, uma tabela temporária estava sendo utilizada para passar valores múltiplos para uma procedure. Esta é uma abordagem muito comum em Sybase e SQL Server, porém em Oracle o correto é passar os valores através de um array, especialmente pelo que vou descrever a seguir.

UNIDADE 3 | SQL

184

A tabela temporária funcionava muito bem quando havia uma única chamada de procedure, porém, quando o sistema evoluiu houve a necessidade de chamar este processo dentro de um processo externo que fazia um loop em certa massa de dados. Além disso, como vários pontos do processo usavam tabelas temporárias, não era possível fazer truncate de nenhuma tabela, pois este comando gera um commit implícito que esvazia todas as tabelas temporárias da sessão (exceto as on commit preserve rows, o que não é o caso).

Enfim, o efeito colateral desta modelagem é que antes de cada chamada da procedure era necessário fazer um delete desta temporária. E, embora o fato das tabelas temporárias serem minimamente logadas, ou seja, gerarem o mínimo de undo, elas geram redo e redo gera undo. Além disso, a operação de delete é uma daquelas que mais gera undo e redo nas temporárias. No fim das contas, o problema de performance que encontrávamos neste processo se devia ao excessivo uso de redo e undo logs. A solução, para não quebrar a compatibilidade com o código existente, foi criar parametros opcionais para que a procedure aceitasse também arrays como metodo de passagem de valores.

A alteração teve um resultado extremamente positivo, resultando no ganho de até 40% no desempenho da procedure em questão.

Sei que estas dicas são meio vagas sem um caso de estudo acompanhando, portanto em breve espero postar dois casos simples reproduzindo estas situações que comentei. Fiquem ligados!

FONTE: Disponível em: <http://oraculodosul.blogspot.com.br/2011/11/performance-com-plsql.html>. Acesso em: 6 fev. 2013.

185


• Para complementar o gerenciamento e manipulação de dados existem outras estruturas de dados como índices, sequences e views.

• Índices servem exclusivamente para questões relacionadas à recuperação de dados em um banco de dados. Tem um grande compromisso com a performance, ou seja, o rápido retorno na solicitação de algum dado.

• PL/SQL é uma linguagem procedural utilizada pelo Oracle para permitir a criação de rotinas com características idênticas à de uma linguagem de programação. Ficam armazenadas e são executadas no servidor de banco de dados.

• Triggers são funções que são chamadas automaticamente durante a alteração de dados em tabelas conforme a sua programação.

RESUMO DO TÓPICO 3

186

AUTOATIVIDADE

1 Defina o que é uma sequence em um banco de dados.

2 O que é uma view?

3 De acordo com o que foi estudado, descreva o que é PL/SQL.

4 Qual é a principal diferença entre procedures e functions?

5 O que é uma trigger e quando ela é executada?

187

REFERÊNCIAS

DATE, Christophe J.. Introdução a sistemas de bancos de dados. 8. ed. São Paulo: Elsevier, 2003.

ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 6. ed. São Paulo: Pearson, 2011.

HEUSER, Carlos Alberto. Projeto de banco de dados. Porto Alegre: Instituto de informática da UFRGS, 2001.

KORTH, Henry F.; SILBERSCHATZ, Abraham. Sistemas de bancos de dados. 2. ed. São Paulo: Makron Books, 1995.

MACHADO, F. N. R. Projeto de banco de dados: uma visão prática. São Paulo: Érica, 2009.

__________. Banco de dados: projeto e implementação. São Paulo: Érica, 2004.

MILANI, André. MySQL: Guia do pogramador. São Paulo: Novatec, 2007.

MORELLI, Eduardo M. Terra. Oracle 8: SQL, PL/SQL e Administração. São Paulo: Érica, 2000.

ROB, Peter; CORONEL, Carlos. Sistemas de banco de dados: Projeto, implementação e administração. São Paulo: Cengage Learning, 2011.

SIEBRA. Sandra de Albuquerque. Banco de dados. v. 2, Recife: UFRPE, 2010.

SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco de dados. 5. ed. São Paulo: Campus, 2006.

188

ANOTAÇÕES

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

189

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

PrincíPios de Banco de dados - UNIASSELVI

Documents

Transcript of PrincíPios de Banco de dados - UNIASSELVI