Fase 3: Escolha de um SGBD

Prévia do material em texto

4 Fase 3: Escolha de um SGBD 
 
A escolha de um SGBD é controlada por uma série de fatores — alguns 
técnicos, outros econômicos e ainda outros referentes à política da 
organização. Os fatores técnicos focalizam a adequação do SGBD para a 
tarefa disponível. As questões a considerar são o tipo de SGBD (relacional, 
objeto-relacional, objeto, outro), as estruturas de armazenamento e os 
caminhos de acesso que o SGBD admite, as interfaces de usuário e 
programador disponíveis, os tipos de linguagens de consulta de alto nível, a 
disponibilidade de ferramentas de desenvolvimento, a capacidade de interagir 
com outros SGBDs por meio de interfaces-padrão, as opções arquiteturais 
relacionadas à operação cliente-servidor, e assim por diante. Os fatores não 
técnicos incluem o status financeiro e a organização de suporte do vendedor. 
Nesta seção, concentramo-nos na discussão dos fatores econômicos e 
organizacionais que afetam a escolha do SGBD. Os seguintes custos devem 
ser considerados: 
1. Custo de aquisição do software, Esse é o custo inicial da compra 
do software, incluindo opções de linguagem de programação, 
diferentes opções de interface (formulários, menus e ferramentas 
de interface gráfica com o usuário (GUI) baseadas na Web), 
opções de recuperação/backup, métodos de acesso especiais e 
documentação. É preciso selecionar a versão de SGBD correta 
para um sistema operacional específico. Normalmente, as fer-
ramentas de desenvolvimento, ferramentas de projeto e suporte 
adicional da linguagem não estão incluídos no preço básico. 
2. Custo de manutenção. Este é o custo recorrente do recebimento 
de serviço de manutenção padrão do vendedor e para manter a 
versão do SGBD atualizada. 
3. Custo de aquisição de hardware. Pode ser preciso adquirir novo 
hardware, como memória adicional, terminais, unidades de disco 
e controladores, ou dispositivos especializados em 
armazenamento e arquivamento do SGBD. 
4. Custo de criação ou Conversão do banco de dados. Este é o 
custo da criação do sistema de banco de dados do zero ou da 
conversão de um sistema existente para o novo software de 
SGBD. Neste último caso, é comum operar o sistema existente 
em paralelo ao novo sistema até que todas as novas aplicações 
sejam totalmente implementadas e testadas. Esse custo é difícil 
de projetar e costuma ser subestimado. 
5. Custo de pessoal. A aquisição de software de SGBD pela 
primeira vez por uma organização com freqüência é 
acompanhada por uma reorganização do departamento de 
processamento de dados. Cargos de DBA e seu pessoal existem 
na maioria das empresas que adotaram SGBDs. 
6. Custo de treinamento. Como os SGBDs em geral são sistemas 
complexos, o pessoal deve ser treinado com freqüência para usar 
e programar o SGBD. O treinamento é exigido em todos os 
níveis, incluindo programação e desenvolvimento de aplicações, 
projeto físico e administração de banco de dados. 
7. Custo operacional. O custo da operação continuada do sistema 
de banco de dados normalmente não é calculado com base em 
uma avaliação das alternativas porque é contraído 
independentemente do SGBD selecionado. 
 
Os benefícios da aquisição de um SGBD não são tão fáceis de medir e 
quantificar. Um SGBD tem diversas vantagens intangíveis em relação aos 
sistemas de arquivo tradicionais, como facilidade de uso, consolidação de 
informações de toda empresa, maior disponibilidade de dados e acesso mais 
rápido à informação. Com o acesso baseado na Web, certas partes dos dados 
podem se tornar globalmente acessíveis a funcionários e também a usuários 
externos. Benefícios mais tangíveis incluem redução nos custos de 
desenvolvimento de aplicação, redução na redundância de dados e melhor 
controle e segurança. Embora os bancos de dados estejam fortemente 
estabelecidos na maioria das organizações, a decisão de passar uma aplicação 
de um enfoque baseado em arquivo para um centralizado no banco de dados 
ainda precisa ser tomada. Essa mudança geralmente é baseada nos seguintes 
fatores: 
1. Complexidade dos dados. À medida que os relacionamentos dos 
dados se tornam mais complexos, a necessidade de um SGBD é 
maior. 
2. Compartilhamento entre aplicações. A necessidade de um SGBD 
é maior quando as aplicações compartilham dados comuns 
armazenados de forma redundante em vários arquivos. 
3. Evolução ou crescimento dinâmico dos dados. Se os dados 
mudam constantemente, é mais fácil lidar com essas mudanças 
usando um SGBD do que um sistema de arquivo. 
4. Freqüência das solicitações casuais dos dados. Os sistemas de 
arquivo não são adequados de forma alguma para a recuperação 
casual de dados. 
5. Volume e necessidade de controle dos dados. O grande volume 
de dados e a necessidade de controlá-los às vezes exige um 
SGBD. 
 
É difícil desenvolver um conjunto genérico de orientações para adotar uma 
única técnica para o gerenciamento de dados em uma organização — seja ela 
relacional, orientada a objeto ou objeto-relacional. Se os dados a serem 
armazenados no banco de dados tiverem um alto nível de complexidade e 
lidarem com vários tipos de dados, a técnica típica pode ser considerar um 
SGBD orientado a objeto ou objeto-relacional. Além disso, os benefícios da 
herança entre as classes e a conseqüente vantagem da reutilização favorecem 
essas técnicas. Por fim, diversos fatores econômicos e organizacionais afetam 
a escolha de um SGBD em relação a outro: 
1. Adoção em toda a organização de certa filosofia. Esse costuma 
ser um fator dominante que afeta a aceitação de determinado 
modelo de dados (por exemplo, relacional versus objeto), de certo 
vendedor ou certa metodologia e ferramentas de desenvolvimento 
(por exemplo, o uso de ferramentas e metodologia de análise e 
projeto orientados a objeto pode ser exigido para todas as novas 
aplicações). 
2. Familiaridade do pessoal com o sistema. Se o pessoal de 
programação da organização estiver familiarizado com 
determinado SGBD, este pode ser favorecido, para reduzir o 
custo de treinamento è o tempo de aprendizagem. 
3. Disponibilidade de serviços pelo Vendedor. A disponibilidade de 
assistência do vendedor na solução de problemas com o sistema 
é importante, uma vez que passar de um ambiente não SGBD 
para SGBD em geral é uma grande incumbência, exigindo muita 
assistência do vendedor no início. 
 
Outro fator a considerar é a portabilidade do SGBD entre diferentes tipos de 
hardware. Muitos SGBDs comerciais possuem versões que rodam em muitas 
configurações (ou plataformas) de hardware/software. A necessidade de 
aplicações para backup, recuperação, desempenho, integridade e segurança 
também precisa ser considerada. Muitos SGBDs atualmente estão sendo 
projetados como soluções totais para as necessidades de processamento de 
informação e gerenciamento de recursos de informação nas organizações. A 
maioria dos vendedores de SGBD está combinando seus produtos com as 
seguintes opções ou recursos embutidos: 
 Editores de texto e navegadores; 
 Geradores de relatórios e utilitários de listagem; 
 Softwares de comunicação (em geral chamados de monitores de 
teleprocessamento); 
 Recursos de entrada e exibição de dados, como formulários, telas 
e menus com recursos de edição automáticos; 
 Ferramentas de consulta e acesso que podem ser usadas na 
World Wide Web (ferramentas habilitadas para a Web); 
 Ferramentas gráficas para projeto de banco de dados. 
 
Uma grande quantidade de software de terceiros está disponível e oferece 
funcionalidade adicional a um SGBD em cada uma dessas áreas. Em casos 
raros, pode ser preferível desenvolver software interno em vez de usar um 
SGBD — por exemplo,se as aplicações forem muito bem definidas e todas 
conhecidas de antemão. Sob tais circunstâncias, um sistema personalizado, 
criado internamente, pode ser apropriado para implementar as aplicações 
conhecidas da forma mais eficiente. Porém; na maioria dos casos, novas 
aplicações que não foram previstas no momento do projeto aparecem após a 
implantação do sistema. É exatamente por isso que os SGBDs se tomaram 
muito populares: eles facilitam a incorporação de novas aplicações apenas com 
modificações incrementais ao projeto existente de um banco de dados. Essa 
evolução de projeto ou evolução de esquema é um recurso presente em vários 
graus nos SGBDs comerciais.