tecnologias de banco de dados para sistemas de informação

TECNOLOGIAS DE BANCO DE DADOS PARA SISTEMAS DE
INFORMAÇÃO – EAD
MÓDULO 1 – A HISTÓRIA DOS DADOS
Iremos iniciar a disciplina de tecnologias de banco de dados para sistemas de
informação falando sobre a história dos dados. Em disciplinas anteriores do
nosso curso, falamos rapidamente sobre os bancos de dados, sistemas de
banco de dados e banco de dados distribuídos. Agora nos aprofundaremos um
pouco mais no universo dos dados, como eles são estruturados, distribuídos e
controlados através dos vários sistemas que auxiliam os sistemas de
informação.
Antes de falarmos sobre os sistemas de banco de dados e seus vários
atributos, é interessante inicialmente destacarmos a histórias dos dados no
decorrer dos tempos. Hoje, por trás de todas as atividades que presenciamos
estão os dados armazenados que conduzem a geração de um grande número
de informações necessárias para conduzirem negócios de todos os tipos e
tamanhos.
Quando falamos em dados, devemos pensar na maneira como eles são
organizados, gerenciados e controlados. Pensando em termos de informática,
ligamos a gerência, organização e controle dos dados aos bancos de dados,
sistemas de gerenciamento de banco de dados e aos ambientes de banco de
dados.
1.1 A história dos dados
Normalmente quando falamos em dados pensamos logo no computador, só
que pesquisando na história chegaremos à conclusão que o interesse das
pessoas pelos dados é bem mais antigo que os computadores. Nesta época
eram aplicados métodos primitivos de manipulação e armazenamento dos
dados.
Um exemplo típico de manipulação de dados feitos na antigüidade era o
controle que os pastores tinham sobre os seus rebanhos. O pastor controlava
seu rebanho com um saco contendo várias pedras e a medida que o rebanho
deixava o cercado e iria para o pasto, o pastor colocava uma pedra dentro do
saco representando cada ovelha. Quando as ovelhas retornavam para o
cercado, a cada ovelha que entrasse no cercado o pastor retirava uma pedra.
Com esse controle era possível saber se todas as ovelhas estavam presentes
ou se alguma não havia retornado. Se observarmos bem esse método de
controle utilizado pelo pastor é uma legítima maneira de armazenar e recuperar
os dados, só que em formas primitivas.
Com o passar dos tempos foram surgindo outros métodos de manter dados e
registros, pois a medida que as formas de comércios evoluíam se fazia
necessário encontrar meios de controle de estoque, pagamentos e dados de
produção.
No século XVII aumentou o interesse das pessoas por encontrar uma
alternativa para automatizar o processamento dos seus dados, e por causa
dessa necessidade vários dispositivos surgiram nessa época para suprir essa
necessidade. Citaremos abaixo alguns criadores que desenvolverem
dispositivos para trabalharem diretamente com os dados, são eles:

Blaise Pascal (1640): Dispositivo contendo engrenagens que eram
capazes de realizar operações de soma e subtração.

Joseph Marie Jacquard (1805): Desenvolveu um dispositivo capaz de
reproduzir padrões. O dispositivo era composto por uma série de cartões
perfurados, em que os fios do material eram entrelaçados e produziam
uma seqüência de padrões desejados.

Charles Babbage (1833): Aproveitou a idéia dos cartões perfurados de
Jacquard e criou uma invenção chamada de “Máquina Analítica” que
consistia em um depósito para guardar itens de dados e um processado
para operar os dados. A máquina de analítica de Babbage nunca foi
concluída, mas ela inspirou muitos dos princípios existentes na
computação moderna.
O século XIX foi um dos propulsores para o desenvolvimento de formas de
armazenamento de dados, devido a quantidade enorme de dados que foram
surgindo para serem armazenados. Um exemplo foi o censo americano
realizado em 1880 que levou quase sete anos para ser totalmente reunido a
mão. Os engenheiros americanos constataram que devido ao grande
crescimento da população o próximo senso não estaria concluído antes que o
outro fosse começar. Para solucionar o problema do censo americano, um
engenheiro chamado Herman Hollerith baseou-se no trabalho realizado por
Jacquard e criou uma forma de armazenar os dados do censo em cartões
perfurados. Com a utilização do equipamento de Hollerith a contagem do
censo de 1890 foi realizada em apenas um mês.
Em 1896 Hollerith formou a Tabulating Machine Company com o intuito de
produzir e comercializar o seu equipamento. A combinação de sua
companhia com várias outras originou a que hoje chamamos de IBM
(International Business Machines).
No mesmo escritório do censo em que era usado o equipamento de Hollerith,
o engenheiro James Powers desenvolveu um dispositivo que alimentaria
automaticamente o equipamento de cartões perfurados e imprimia o
resultado. Em 1911 James Powers fundou a Powers Tabulating Machine
Company que futuramente acabou se tornando a Unisys Corporation.
A partir de 1940 a quantidade de equipamentos que processavam dados
aumentou bastante, passaram a ser utilizados cartões perfurados com
calculadoras, impressoras e ordenadoras. Os dados eram armazenados em
cartões perfurados e o seu processamento era feito através de um conjunto de
fios conectados a placas projetadas e inseridas em dispositivos
eletromecânicos. Os equipamentos eletromecânicos coexistiram em parte com
os computadores eletrônicos, esses últimos foram introduzidos em meados de
1950.
1.2 Evolução das formas de armazenamento dos dados
Como falamos anteriormente, houve uma evolução constante nas formas de
armazenamentos dos dados com o passar dos tempos. Citaremos abaixo as
principais formas de armazenamento e a época em que foram utilizadas:

1870: A fita de papel perfurada foi a primeira forma de armazenamento
moderna dos dados.

1900: Utilização de cartões perfurados como meio de armazenamento.
Até as décadas de 1920, 1930 e 1940 os cartões perfurados foram o
único meio de armazenamento dos dados utilizados nesta época.

1930: Início a era do armazenamento magnético apagável através da
utilização de fitas magnéticas para armazenamento do som. Na década
de 1940 foram realizados testes para utilizarem as fitas magnéticas para
o armazenamento de dados. De 1950 a 1960 as fitas magnéticas eram
unanimidade quando se falava em armazenamento de dados em
computadores.
Houve uma constante melhoria e evolução na forma de armazenamento
dos dados pelas fitas magnéticas, e hoje elas ainda são utilizadas no
armazenamento de grandes quantidades de dados que precisam ser
armazenados por longos períodos.

1940: O conceito de fita magnética acabou originando a criação dos
discos magnéticos. Na década de 1960 aconteceu a conversão das fitas
magnéticas para os discos magnéticos.

Dias atuais: Nos dias atuais, existem várias formas de armazenamento
dos dados, o principal é através dos discos rígidos utilizados em
computadores pessoais e servidores, além dos CD`s, DVD`s, cartões de
memória e pendrivers que utilizam a tecnologia de memória flash. A
tecnologia de armazenamento através de chip será em um futuro
próximo a forma dominante no armazenamento dos dados.
Os próximos capítulos darão destaque a maneira como os dados são
armazenados, tratados e gerenciados e o seu grau de importância para os
sistemas de informação.
MÓDULO 2 – OS DADOS NO AMBIENTE CORPORATIVO
Antes de iniciarmos o capítulo que fala sobre os dados no ambiente
empresarial, seria interessante especificarmos o significado da palavra “dados”
no contexto que estamos trabalhando. Existem várias definições para a palavra
dados, a definição de Mark Gillenson fala que:
“Os dados são fatos únicos sobre algo que nos interessa”
Atualmente com a evolução dos computadores, principalmente quando se fala
em velocidade e capacidade de operação, ilustra bem o interesse das
corporações pelos computadores e não sendo este interesse muito diferente
dos antigos pastores que utilizavam as formas primitivas de armazenamento
dos dados na antigüidade. Esse interesse se deve principalmente a capacidade
de armazenamento e processamento que os computadores proporcionam aos
dados e que ocasionam vantagens para as empresas no mercado competitivo
que elas atuam.
Os benefícios oferecidos pela evolução dos computadores fazem
com que as empresas invistam a cada dia na utilização de
tecnologia de ponta. Esses investimentos proporcionam as
empresas vantagens competitivas no mercado que atuam.
Os dados tornaram-se indispensáveis para qualquer tipo de organização
moderna, sendo as aplicações e os computadores que a executam
fundamentais em todos os aspectos para cada tipo de iniciativa. É importante
quando falar em recursos corporativos citar além das instalações, capitais,
pessoal, estoque e equipamentos, citar também os dados como um recurso
corporativo.
É falado rotineiramente no meio empresarial que os dados e as informações
derivadas desses dados são armas altamente competitivas para as empresas.
Como exemplo de vantagem competitiva com o auxílio dos dados citaremos o
serviço de transporte dos correios. Eles foram os primeiros no Brasil a fornecer
informações sobre o rastreamento do produto através do seu website. Com
esse serviço sendo oferecido, as outras empresas que também trabalham com
o transporte de produtos, sentiram-se obrigadas a oferecer o mesmo serviço de
rastreamento.
Esse ciclo contínuo gerado pela competitividade das empresas e a utilização
dos dados como arma de negócio, levou o uso dos dados a níveis cada vez
maiores tornando-o um recurso empresarial cada dia mais importante e
indispensável. Hoje, bancos fornecem informações a seus clientes via internet,
transportadoras fornecem informações atualizadas sobre o transporte de
produtos a seus clientes, e outros tipos de informações que podem ser
fornecidas com a utilização dos dados.
Quando falamos em rastreamento on-line de objetos, bancos on-line, e
atualizações quase em tempo real, parece que tudo é muito simples, e fácil de
ser implantado. Mas analisando bem, existe uma complexidade enorme na
capacidade de fornecer acessos eficientes aos dados e promover o seu
armazenamento. Um dos primeiros complicadores para as empresas é o
armazenamento dos dados. Para uma empresa de médio a grande porte, a
quantidade de dados armazenados em seus bancos de dados alcança
facilmente a cada dos gigabytes e estes dados estão em constante
crescimento.
Outro agravante causado pelas facilidades que são oferecidas pelas empresas
aos clientes está relacionado a quantidade de acessos dos usuários aos dados
e informações. Se combinarmos o acesso aos dados com a quantidade de
dados que são armazenados, veremos o enorme desafio que as empresas
deverão superar para oferecer serviços de qualidade. Sem os avanços
alcançados pelos computadores na atualidade, seria quase impossível alcançar
o estágio de evolução que os sistemas de informação estão. A medida que os
sistemas de informação evoluem, paralelamente os hardwares e softwares que
são utilizados para auxiliar o seu controle, também estão em constante
evolução e com isso a quantidade de dados e informações também aumenta.
Devido a evolução da quantidade de dados armazenados pelas empresas, se
fez necessário pensar em uma forma segura de armazenar e recuperar esses
dados. A aplicação de diretivas de segurança permite as empresas a
prevenção de problemas que são causados por roubo de informações,
destruição intencional, alteração nos dados como forma de beneficiar um
terceiro além de dados que são causados acidentalmente.
MÓDULO 3 – OS DADOS NO AMBIENTE CORPORATIVO
3.1 Os dados sendo reconhecidos como recursos corporativos
Os recursos corporativos existentes nas empresas devem ser gerenciados,
acompanhados e protegidos para que a empresa alcance todos os seus
objetivos. Os dados são recursos corporativos difíceis de serem gerenciados,
pois são formados por milhares de pontos diferentes que estão em constante
mudanças. Observou o tamanho da complexidade? Se não, compare gerenciar
essa quantidade de dados com gerenciar um almoxarifado ou o quadro de
funcionários de uma empresa. Agora você vai ter uma idéia abrangente da
complexidade dos dados como recursos corporativos.
Na década de 1960 as empresas começaram a perceber que a forma de
armazenamento dos dados que era utilizada naquela época em um futuro
muito próximo iria tornar-se inviável, devido principalmente ao constante
aumento no volume de dados armazenados e o aumento do número de
usuários acessando esses dados. Surgiu então a necessidade de desenvolver
um software que controlasse o armazenamento, controle de acesso e
redundância desses dados. Dessa necessidade foi que nasceu os SGBD`s
(Sistemas Gerenciadores de Banco de Dados) e os DBA`s (Administradores de
banco de dados). A integração entre especialistas, DBA`s e os sistemas de
gerenciamento de banco de dados originou o que podemos chamar de
ambiente de banco de dados.
3.2 O ambiente de banco de dados
Falamos anteriormente que quando as empresas começaram a observar os
dados como um recurso corporativo que poderia ser utilizado como vantagem
competitiva no mercado que atuam, elas investiram na idéia de desenvolver um
sistema de gerenciamento de banco de dados e criar profissionais que seriam
responsáveis por tudo o que era relativo a dados (Administradores e
especializas em dados). A junção desses profissionais com o sistema de
gerenciamento e os equipamentos utilizados para armazenar os dados originou
o “ambiente de banco de dados”.
O ambiente de banco de dados surgiu para corrigir todos os problemas no
ambiente de desenvolvimento e de produção que estivessem relacionados aos
dados. Citaremos abaixo algumas características oferecidas pelo ambiente de
banco de dados:







Compartilhamento dos dados;
Armazenamento de grandes volumes de dados;
Melhoria na correção dos dados;
Controle de redundância dos dados;
Controle de acesso aos dados;
Ferramentas de segurança dos dados;
Ferramentas de privacidade dos dados;


Cópia de segurança dos dados,e
Operações de recuperação dos dados.
Reunindo esse aparato completo de ferramentas e atividades tornam o
ambiente capaz de resolver quase todos os problemas relacionados a dados
que venham a surgir.
Como o nosso foco é falar das tecnologias de banco de dados para os
sistemas de informação, a cada capítulo abordaremos um passo a passo dos
diversos componentes existentes em um ambiente de banco de dados, pois em
um ambiente de sistemas de informação existe internamente um ambiente de
banco de dados.
MÓDULO 4 – DOS DADOS AOS BANCOS DE DADOS
Os capítulos anteriores foram responsáveis por conceituar os dados e a sua
importância no ambiente corporativo. Este capítulo será responsável por
abordar os bancos de dados e os motivos que levaram o surgimento dos
sistemas de gerenciamento de banco de dados.
Antes do surgimento dos bancos de dados, todos os dados existentes nos
sistemas de informação eram armazenados em arquivos simples. Como as
aplicações não eram tão sofisticadas como as que temos atualmente, alguns
programas requeriam os dados de apenas um arquivo e outros de vários
arquivos separados. Normalmente todos os arquivos utilizados no
armazenamento dos dados eram criados para apenas uma única aplicação,
não existindo o compartilhamento de dados e arquivos entre diferentes
aplicações.
Com o aumento da importância dada aos sistemas de informação e a evolução
e barateamento dos equipamentos de hardware, fizeram com que as regras de
armazenamento fossem alteradas. Ficou cada vez mais claro que o foco nos
dados deveria ser maior, tanto quanto o foco dado ao desenvolvimento do
sistema. O tamanho e a sofisticação dos sistemas acarretaram no aumento do
armazenamento de dados nos arquivos, fazendo com que a redundância dos
dados também acompanhasse esse crescimento. Problemas como exatidão
dos dados geravam pesadelos enormes para as grandes empresas, devido
principalmente a dependência cada vez maior que elas tinham dos sistemas de
informação para o gerenciamento dos seus negócios.
Se resumirmos alguns problemas com o armazenamento dos dados em
arquivos, podemos encontrar os seguintes fatores:

O armazenamento dos dados era feito em formato e arquivos diferentes;

A duplicação dos dados gerando arquivos redundantes acontecia
freqüentemente devido aos dados não serem compartilhados entre os
programas;

Os arquivos de armazenamento sofriam danos que dificilmente
poderiam ser recuperados;

Os dados estavam vulneráveis a roubos e danos acidentais;

Os programas dependiam da maneira como os dados eram
armazenados, se essa forma fosse alterada, o programa também
deveria ser alterado.

Para mudar o cenário que observamos nas citações acima, surgiu o
conceito de Banco de Dados.
4.1 Conceitos de Banco de Dados
O conceito de banco de dados foi um dos principais responsáveis pelo nível de
tecnologia em que os sistemas de informação encontram-se nos dias atuais.
Seus recursos gerenciais e técnicos de armazenamento são o centro das
atenções quando se fala em desenvolver um sistema de informação de
qualidade.
O conceito de banco de dados é formado por alguns princípios básicos:

Foi criado um ambiente de dados centralizado que proporcionasse as
empresas considerar os dados como um recurso corporativo. Essa
centralização permitiu que os dados fossem compartilhados entre
diversos aplicativos e usuários;

Possibilidade de integrar os dados de forma não-redundante;

Ambiente completo de gerenciamento dos dados que permite o controle
dos dados, segurança, recuperação, além do controle de concorrência.
O ambiente formado pelos sistemas de informação é bem amplo. Ele é
composto por diversos componentes de hardware, software, pessoas, redes e
dados. Cada um desses ambientes possui um foco específico e variado. Com o
surgimento dos primeiros sistemas de informação também conhecidos como
sistemas de processamento de dados, a maioria das atenções era totalmente
direcionada para o sistema, sendo destinada pouca atenção aos dados e a
forma como eles eram estruturados.
Os dados só passaram a ser reconhecidos quando as funções empresariais
tornaram-se cada vez mais dependentes dos sistemas de informação. Dados
sobre produtos, clientes, funcionários, fornecedores e concorrentes
armazenados de forma apropriada, forneceriam um importante vantagem
competitiva para a empresa. Com o reconhecimento dos dados como um
importante recurso corporativo, tornou-se cada vez mais clara a necessidade
de gerenciá-lo de forma organizada, sendo necessário um software que
pudesse ao mesmo tempo proteger, gerenciar e fornecer acesso compartilhado
a esses dados, para que ele pudesse cumprir o seu destino de importante
recurso corporativo. Dessa necessidade
gerenciamento de banco de dados.
nasceram
os
sistemas
de
MÓDULO 5 – DOS DADOS AOS BANCOS DE DADOS
5.2 SGBD – Sistemas de gerenciamento de banco de dados
Um SGBD é composto por uma coleção de programas que permitem aos
usuários definir, construir e manipular bancos de dados para diversos tipos de
aplicações. Com eles podemos:

Definir um banco de dados, especificando e descrevendo todas as
características de armazenamento dos dados;

Construir um banco de dados em si;

Manipular uma série de funções que permitem a consulta, atualização,
inserção e exclusão dos dados.
Os primeiros SGBD`s surgiram na década de 1960 e eram muito simples, se
comparado com o que temos atualmente. Os sistemas atuais possuem as
seguintes funções:
Controle de redundância dos dados: A redundância consiste no
armazenamento de uma mesma informação em locais diferentes, provocando
problemas de grande utilização do espaço computacional para armazenamento
dos dados. O principal problema da redundância dos dados é a sua
inconsistência, pois duas informações podem aparecer em locais distintos, mas
com valores diferentes. Os SGBD`s possuem um controle sobre a redundância
e inconsistência dos dados.
Controle de acesso: Quando se trabalha com dados compartilhados, é
necessário ter o controle completo do que está autorizado ou não para acessar
os dados do banco de dados. Para controlar esse acesso, são criados usuários
e grupos de usuários que recebem uma conta de acesso aos dados. Algumas
contas possuem restrições e privilégios diferenciados.
Compartilhamento dos dados: O SGBD controla o acesso concorrente dos
dados em um ambiente de múltiplos usuários, possibilitando o
compartilhamento desses dados e garantindo aos vários usuários a realização
de atualizações sobre o mesmo conjunto de dados.
Controle de transações: O SGBD permite a realização de um conjunto de
operações sobre o B.D que deve ser executada integralmente sem a
ocorrência de falhas. Essas operações são chamadas de transações e devem
ser executadas com segurança.
Possibilidade de múltiplas interfaces: Quando se têm vários usuários
acessando, pode ser que esses vários usuários representem interfaces
diferentes. Podemos chamar de interfaces as consultas de dados,
programação, etc.
Relacionamento complexo entre os dados: Em uma base de dados podem
existir diversos inter-relacionamentos entre os dados existentes nesta base. O
SGBD possui a capacidade de representar esses relacionamentos entre os
dados, bem como recuperá-los e modificá-los.
Backup e restauração dos dados: Recursos são fornecidos para restauração
dos dados caso uma falha venha a ocorrer.
Apesar de todas as vantagens que falamos sobre os SGBD`s que falamos
acima, podemos dizer que um SGBD é um sistema caro que requer um alto
investimento que dependerá do porte da empresa. As empresas que
desejarem adquirir um SGBD devem está ciente do investimento que deverá
ser feito para que todas as funções que falamos acima sejam aplicadas nos
seus dados.
MÓDULO 6 – A INTEGRAÇÃO E A REDUNDÂNCIA DOS DADOS
Na área de gerenciamento dos dados as questões que envolvem a
redundância dos dados e a sua integração, são consideradas questões críticas
e merecem uma atenção especial.
Quando falamos em integração dos dados, estamos no referindo a sua
habilidade de juntar partes de dados e integrá-los dentro de um sistema de
informação.
Exemplo de integração: Imagine um registro que contenha os dados de
nome, endereço, e-mail e telefones de um cliente. Um outro registro contém
todas as informações de venda dos clientes. Pode haver um momento em que
se queira premiar ou oferecer alguma promoção para o cliente que comprou
mais produtos, sendo necessário entrar em contato com o cliente. Teríamos
então uma integração entre o registro do cliente e o registro de compras do
cliente.
Quando se fala em redundância dos dados você pode logo imaginar na
existência de um mesmo dado armazenado no mesmo sistema de informação.
A redundância dos dados diferentemente da integração é uma característica
negativa. A integração dos dados e a redundância dos dados, são
características que possuem uma forte ligação e serão abordadas no decorrer
do capítulo.
Os dados que estão armazenados em um sistema de informação são uma
descrição do mundo real. Por mais valioso que sejam esses dados que estão
armazenados, se eles estiverem duplicados ou armazenados diversas vezes
dentro do mesmo sistema de informação, podem resultar problemas de perca
de desempenho no sistema, incertezas na exatidão dos dados e
conseqüentemente a redução da competitividade da empresa no mercado que
atua.
Citaremos abaixo alguns problemas causados pela redundância dos dados:
Utilização de grandes quantidades de espaço que estão destinados ao
armazenamento de dados no sistema;
A atualização de todos esses dados que estão replicados consome tempo e
recurso computacional do sistema, acarretando na perca de desempenho do
sistema.
A integração dos dados pode ser comprometida com os problemas causados
pela redundância dos dados, pois a integração necessita da exatidão dos
dados. Se eles estão redundantes, quem garante que eles foram ou não
atualizados. Se ocorrer alguma falha na atualização de todos os dados que
estão redundantes, a integridade dos dados será comprometida.
6.1 Um exemplo de redundância de dados entre vários arquivos
Observe a seguinte situação:
Dados envolvidos: Nomes e endereços de um cadastro de clientes.
Situação: Diariamente, os diversos setores de uma grande empresa
necessitam dos dados que estão armazenados no cadastro de clientes da
empresa. Como não existe um sistema de informação na empresa que integre
todos os setores, o departamento de contas a receber, de vendas e de crédito
são forçados a duplicar esses dados em diversos registros, um para cada
departamento.
Arquivo de registro do departamento de vendas
ID
01012
01023
01042
Nome
Paulo Augusto
Antônio Carlos
Adriano Maia
Endereço
Rua T, 182
Rua Celeste, 1222
Rua César Cals, 134
Arquivo de registro do departamento de contas a receber
ID
01012
01023
01042
Nome
Paulo Augusto
Antônio Carlos
Adriano Maia
Endereço
Rua T, 182
Rua Celeste, 1222
Rua César Cals, 134
O problema na duplicação desses arquivos e conseqüentemente a geração de
redundância começa agora. Vamos supor que o cliente “’01042” se muda da
rua César Cals, para a Av. Beira Mar. Essa mudança foi registrada com
sucesso no registro de vendas, só que o registro de contas a receber não foi
atualizado, gerando dados inconsistentes nos registros da empresa. A empresa
não pode mais confiar nos seus arquivos de registros, pois quem pode garantir
qual o endereço correto do cliente “’01042”. Observamos que o problema de
integridade dos dados pode ser algo comum, quando não existe o controle de
redundância dos dados que são armazenados em diversos arquivos.
MÓDULO 7 – A INTEGRAÇÃO E A REDUNDÂNCIA DOS DADOS
7.2 Um exemplo de integração e redundância dos dados envolvendo
vários arquivos.
OBS: A redundância dos dados em apenas um arquivo acarreta o mesmo
problema que é causado pela redundância dos dados em diversos arquivos.



Desperdício no espaço destinado ao armazenamento dos dados;
Grande esforço computacional para a atualização dos dados
redundantes;
Problemas na integridade dos dados.
Situação 2:
Domínio: Empresa que trabalha com a venda de equipamentos esportivos.
Clientes: Academias e lojas de materiais esportivos.
Registros da empresa: Cadastro de vendedores e cadastro de clientes.
Arquivos de registro:
1.Registro de vendedores
ID_Vendedor
Nome
001
Paulo
002
Carlos
003
José
2. Registro de clientes
ID_Cliente
Nome
Comissão
8%
5%
10%
ID_Vendedor
010
015
017
Carlos José
Mário Augusto
Ibes Sampaio
003
001
003
Observando os registros dos clientes e dos vendedores notamos que nenhum
dos registros apresentam dados redundantes. O registro dos clientes possui
um campo com um identificador dos vendedores. Mas porque ele está ai além
de estar no registro dos vendedores? O identificador dos vendedores aparece
no registro dos clientes para que seja identificado qual vendedor é o
responsável por determinado cliente. Essa situação representa um
relacionamento um-para-muitos entre vendedores e clientes (Abordaremos o
assunto sobre relacionamentos no próximo capítulo). Com esse tipo de
relacionamento, um vendedor poderá ter diversos clientes, enquanto cada
cliente é atendido por apenas um vendedor.
Observando o registro de clientes, o identificador do cliente “003” aparece em
dois clientes, será que essa repetição consiste em uma redundância de dados?
A resposta é “NÃO”. Para que os dados sejam considerados redundantes, é
necessário que um mesmo fato esteja registrado mais de uma vez.

O número 003 no registro de vendedores o caracteriza como o
identificador de um vendedor.

O número 003 no registro de clientes caracteriza que o vendedor
número 003 é responsável pelos clientes 010 e 017.
A recuperação dos dados de cada um dos registros de forma individual não é
considerada uma tarefa complicada. Agora se houver a necessidade de
encontrar um registro que dependa da ligação entre as tabelas, as coisas
tornam-se mais complicadas.
Ex: Encontrar o nome do vendedor que é responsável pelo cliente 001.
Essa necessidade não pode ser satisfeita recuperando os dados de apenas um
arquivo. Para que esta operação seja efetuada, é necessário que seja feita a
integração dos dados existentes em ambos os registros.
Para que seja encontrado o nome do vendedor responsável por um
determinado cliente, primeiro devemos recuperar os dados do cliente no
registro de clientes, usando o identificador do vendedor que foi recuperado no
registro de clientes é que será possível encontrar o nome do vendedor no
registro de vendedores.
Esse tipo de recuperação de dados em que é preciso trabalhar com vários
arquivos e comandos, não é o tipo de atividade ideal, pois está sujeita a
aparição de erros e ocasiona problema de desempenho. Embora os arquivos
não estejam com dados redundantes, eles não possuem nenhum tipo de
integração, fazendo com que seja extremamente complicado recuperar dados
nos dois registros que estejam relacionados entre si.
Sabendo dos problemas que são causados pela falta de integração entre os
dois registros, então a solução ideal seria juntar os dois registros em um só.
Vamos juntá-los e observar os resultados.
ID_Cliente
Nome
010
Carlos
José
015
Mário
Augusto
017
Ibes
Sampaio
ID_Vendedor ID_Vendedor Nome
003
003
José
Comissão
10%
001
001
Paulo
8%
003
003
José
10%
Agora temos um registro muito bem integrado. O sistema que necessitar
recuperar o nome do vendedor relativo ao cliente X só necessitará fazer
apenas um único acesso. Resolvemos então o problema anterior do acesso a
vários arquivos, só que infelizmente essa integração gerou redundância nos
dados. Onde? O vendedor José está repetido duas vezes, sendo considerado
uma redundância de dados, pois repete o mesmo fato diversas vezes dentro de
um mesmo arquivo. Se analisarmos do ponto de vista lógico, não faz muito
sentido a repetição do nome do vendedor e da sua comissão. Outro problema
existente nesse registro é a sua má estruturação, pois dois tipos diferentes de
dados estão fundidos em um único arquivo. Mais um problema grave, se o
cliente 015 decidir não ser mais cliente, seus dados serão apagados e
juntamente com a exclusão do registro do cliente 015 irão os registros do
vendedor 001.
Assim como a exclusão, a inclusão também é complicada. Se a empresa
desejar cadastrar um novo vendedor, esse cadastro não poderá ser feito até
que esse tenha pelo menos um cliente.
Encontramos um grande dilema na estrutura de dados em que são envolvidas
a integração e a redundância dos dados. Arquivos separados não possuem
redundância, mas possuem pouca integração. Arquivos juntos estão muito bem
integrados, eliminando os múltiplos acessos e os múltiplos comandos, mas
infelizmente possuem muita redundância nos dados. Nenhuma das duas
situações podem ser aceitas, pois a baixa integração torna o sistema de
informação lento e a redundância causa problemas na exatidão dos dados.
Para resolver os problemas de redundância e integração dos dados é que
foram criados os SGBD`s. Qualquer sistema de armazenamento e recuperação
dos dados que não possua as características que solucionem problemas que
envolvem redundância e integração dos dados, não pode ser considerado um
SGBD.
MÓDULO 8 – MODELAGEM DE DADOS I
Em 1976 foi publicado um trabalho que definia uma possível abordagem para o
processo de modelagem de dados. O trabalho intitulado de “The EntityRelationship Model” passou a ser considerado como uma referência para o
processo de modelagem dos dados. A abordagem entidade-relacionamento
escrita por Peter P. Chen é composta por técnicas de diagramação e de
conceitos que devem ser compreendidos e respeitados.
A diagramação entidade-relacionamento é muito simples, servindo como
representação dos conceitos que são manipulados por ela.
É utilizado na sua representação um retângulo que representa as entidades,
um losango que têm o papel de representar os relacionamentos e os balões
que indica e aloca os atributos.
Essa proposta de modelagem de dados mantêm-se atualizada até os dias de
hoje, pois é ao mesmo tempo completa e inquestionável. Sua maior qualidade
está ligada principalmente a sua simplicidade e objetividade. Se observarmos
bem o modelo que foi proposto por Chen ele define a seguinte lei:
“O mundo está cheio de coisas que possuem características próprias e que se
relacionam entre si” (Lei conhecida como a lei do mundo).
Vamos pegar a lei do mundo e tentar conceituar os elementos que são do
nosso interesse e fazem parte do modelo de entidade e relacionamento. Os
elementos são os seguintes:



Entidades
Relacionamentos
Atributos
Devemos definir que dentro do universo que estamos observando será
reconhecido os objetos ou as “coisas”, sendo esses objetos elementos
individualizados que podem ou não fazer parte de um conjunto ou categoria, se
for levado em conta a sua semelhança.
Ex: Análise de um ambiente de produção existente em uma fábrica
Elementos identificados:



Máquinas;
Funcionários;
Ferramentas;



Procedimentos de operação;
Procedimentos de verificação;
Peças produzidas.
Analisando todos os elementos que foram observados, percebemos a
existência de conjuntos distintos de elementos.

As máquinas representam todas as máquinas que foram observadas,
independente da sua utilização.

Os funcionários representam todos os funcionários observados,
independente da função que desempenham.

As ferramentas representam todas as ferramentas, independente da
finalidade.

Peças que representam todas as peças produzidas.
Todos os elementos que foram identificados possuem características em
comum, fazendo com que sejam enquadrados em conjuntos particulares,
sendo essas características inerentes a todos os objetos de um mesmo
conjunto.
Analisando alguns conceitos e exemplos que foram citados, podemos chegar à
abordagem entidade – relacionamento.
Lei do mundo
Objetos
individualizados
semelhantes
Características próprias
Inter-relacionamento dos objetos
MER
Modelo
relacionamento
e Entidades
Entidade
–
Atributos
Relacionamentos.
8.1 As entidades
Existem várias normas de identificação das entidades. Segundo Shlers &
Mellor, o objeto deverá ser reconhecido ou os elementos individualizados
através dos elementos abaixo:





Coisas tangíveis
Funções exercidas pelos elementos
Eventos ou ocorrências
Interações
Especificações.
Os criadores da definição procuraram deixar claro que essa não é
necessariamente uma definição formal no processo de classificação dos
elementos. Com o ganho de experiência na modelagem, todos esses
processos de classificatórios passam a ser intuitivos, não sendo necessária a
busca de um enquadramento ideal para a classificação.
8.1.1 As coisas tangíveis
As coisas tangíveis representam tudo àquilo que pode ser tocado. Isso engloba
todos os elementos que possuam uma existência concreta.
Ex:




Um carro;
Um livro;
Um cavalo;
Uma caneta.
O agrupamento de todos esses elementos vai depender do ponto de vista que
foi adotado no processo de modelagem, onde o nível de abstração poderá ter
um grau maior ou menor, levando a formação de diferentes grupos.
Ex:
Entidades (Elementos)
Animal
Equipamento
Meio de transporte
Objetos
Cachorro, gato, cavalo
Computador, calculadora, Ipod
Carro, ônibus, avião.
8.1.2 As funções
As funções possuem a responsabilidade de definir os atributos. É feita a
classificação e capacitação com base em características existentes em um
dado elemento. É feita a especificação da sua atuação no ambiente que está
inserido.
Ex:
Entidades (Conjuntos)
Especialista
Atendente
Cliente
Objetos do conjunto
Médico ortopedista,
analista de sistemas
Recepcionista de
eventos, gerente de uma
pousada
Estudante, paciente
Coisas tangíveis
Pessoa
Pessoa
Pessoa
8.1.3 Eventos ou ocorrências
Alguns objetos só são percebidos quando alguma ação acontece. São eles:
Ex:


Acidente rodoviário;
Evento festivo;

Uma partida de voleibol.
A maioria dos dados que fazem parte desses eventos são dados de objetivos
participantes do evento.
5.1.4 As interações
As interações são resultantes da associação de objetos em função de um
processo executado.
Ex:
Compra de um barco;
Adoção de um animal;
Venda realizada de um imóvel.
Os objetos que fazem parte das interações, passam a existir de forma
individualizada.
8.1.5 As especificações
Encerrando a lista de elementos identificados nas entidades temos as
especificações. Elas são formadas por conjuntos de elementos que definem as
características de outros objetos. Se essas especificações forem analisadas
isoladamente elas não representarão um objeto, mas quando são seguidas ou
aplicadas, essas especificações dão origem a um objeto.
Os objetos especificados podem ser omitidos dos modelos conceituais de
dados, desde que seus atributos sejam alocados aos objetos aos quais eles
referenciam.
Ex: Aparelho de ar-condicionado:
Objetos tangíveis
Ar-condicionado
Cor
Modelo
Data de produção
Número de série
Objetos especificados
Modelo de ar-condicionado
Capacidade
Voltagem
Altura
Largura
8.2 Os atributos
Quando observamos um objeto em um determinado ambiente, estamos na
verdade reconhecendo os elementos através de suas características. Essas
características são comuns a todos os objetos que pertencem a um mesmo
conjunto.
Ex: Quando estamos andando na rua e percebemos um objeto passando,
somos capazes de definir no primeiro instante se é um carro, uma moto ou uma
pessoa. Esse tipo de reconhecimento é realizado através de um conjunto de
características que serão julgadas naquele momento.

As características que definem um carro são aplicadas a quase todos os
carros.

As características que definem uma moto são aplicadas a quase todas
as motos.

As características que definem uma pessoa são aplicadas a quase todas
as pessoas.
Carro
Marca: Ford
Placa: MEI6600
Modelo: Ford Focus
Ano de fabricação: 2007
Pessoa
Cor cabelo: Vermelho
Estatura: 1,75
Peso: 63kg
Idade: 33 anos
As exceções existentes:


Um carro do exército não possui placa;
Uma pessoa careca não apresenta as características de cor dos
cabelos.
Analisando todos esses atributos é que podemos classificá-los em conjuntos
distintos.
MÓDULO 9 – MODELAGEM DE DADOS I
9.3 Os relacionamentos
Até agora falamos sobre a análise de um determinado ambiente e nele
mapeamos e identificamos todos os objetos existentes. Além do mapeamento e
da identificação, devemos mapear o relacionamento existente entre os objetos,
pois quando observamos alguns objetos, reconhecemos as relações existentes
entre eles.
Em alguns casos a observação de um relacionamento é o ponto inicial para
a identificação do objeto.
Quando fazemos o mapeamento e a identificação de um relacionamento, é
possível demonstrar como um objeto se comporta em relação aos demais, o
seu grau de dependência em relação aos outros objetos juntamente com a
associação de dados existentes entre eles, além de outros fatores.
Os objetos de um ambiente podem se relacionar independente do tipo de cada
um. O grau de fidelidade que é atingido durante o processo de modelagem é
que estabelecerá se a associação é válida ou não, significando que se um
relacionamento espelha a realidade, ele poderá envolver qualquer tipo ou
instância de objeto.
9.3.1 Tipos de relacionamentos
Relacionamento entre instâncias de objetos de tipos diferentes: é associada à
instância de um objeto de um tipo a outro de outro tipo. É o tipo de
relacionamento mais utilizado.
Exemplo 01: “Marcos é proprietário de uma moto vermelha”.
Objetos envolvidos:


Pessoa: instanciado por “Marcos”.
Moto: instanciado por “moto vermelha”.
Caracterização do objeto:


Pessoa: Nome, data de nascimento, RG, CPF.
Moto: Marca, modelo, motor.
Relacionamento: “Pessoa é proprietária de Moto”
Caracterização do relacionamento:




Nem toda pessoa é proprietária de uma moto.
Uma moto pode pertencer a uma pessoa ou não.
Algumas pessoas têm mais de uma moto.
Se uma moto pertence a uma pessoa ela não pertencerá a mais
ninguém.
Representação:
Processo utilizado para o mapeamento de dois ou mais objetos e para o
mapeamento de mais de um tipo de relacionamento entre os mesmos
objetos.
Exemplo 02: “Uma moto é de propriedade de uma pessoa e pode ser utilizada
por outras pessoas para sua locomoção”. “Uma pessoa utiliza um imóvel para
morar”.
Objetos envolvidos:



Pessoa
Moto
Imóvel
Caracterização do objeto:



Pessoa: Nome, data de nascimento, RG, CPF.
Moto: Marca, modelo, motor.
Imóvel: Localização, metragem, registro.
Relacionamento:


“Pessoa utiliza moto”
“Pessoa utiliza imóvel”
Relacionamento entre os objetos:

Pessoa utiliza moto.
o Nem toda pessoa utiliza uma moto.
o Uma moto pode ser utilizada por uma ou mais pessoas.
o Algumas pessoas utilizam mais de uma moto.
o Uma moto sempre será utilizada por pelo menos uma pessoa.

Pessoa utiliza imóvel
o Toda pessoa utiliza um, e só um imóvel para morar.
o Um imóvel pode ser utilizado por uma ou mais pessoas.
o Um imóvel nem sempre será utilizado por uma pessoa.
Representação:
Existem vários outros tipos de relacionamentos que podem ser abordados. Uns
mais simples e outros mais complexos, depende muito do número de entidades
que estão envolvidas no ambiente.
MÓDULO 10 – MODELAGEM DE DADOS II
Os relacionamentos devem ser enquadrados em três grandes grupos para que
possam cumprir a finalidade de expressar a semântica das associações entre
as entidades. As três alternativas são:



1:1 (Um para um)
1:N (Um para muitos)
N:M (Muitos para muitos)
10.1 Relacionamento 1:1
Esse tipo de relacionamento denota um caso especial de relacionamento 1:N
onde o valor de N é fixado obrigatoriamente em 1. O seu grau de
relacionamento é bem restrito quando falamos em associações de entidades,
fazendo com que seja um relacionamento pouco comum no dia-a-dia.
Com o relacionamento 1:1 temos que uma entidade do tipo A só pode se
relacionar com uma entidade do tipo B, e que uma entidade do tipo B só pode
se relacionar com uma entidade do tipo A.
Podemos representar a relação existente entre as entidades de um
relacionamento 1:1 através do conjunto abaixo:
Percebemos claramente que cada entidade do conjunto A se relaciona apenas
com uma entidade do conjunto B e vice-versa.

“Uma pessoa recebe uma e só uma certidão de nascimento e por sua
vez uma certidão de nascimento só pertence a uma pessoa”.
Os relacionamentos 1:1 são difíceis de serem caracterizados, pois a mudança
de visão ou interpretação pode fazer com que o relacionamento possa ser
questionado e reconsiderado.
Ex: No caso anterior da pessoa receber apenas uma certidão de nascimento.
Se por acaso uma outra certidão for emitida devido a algum tipo de problema
que ocorreu na primeira, o relacionamento passará de 1:1 para 1:N.
Quando falamos em estrutura de dados para a construção de um banco de
dados, os relacionamento 1:1 e 1:N são bem semelhantes, e eventuais
mudanças de um relacionamento 1:1 para 1:N não possui efeito traumático.
10.1.1 Tipos de relacionamentos 1:1

(0,1): (0,1): Significa que uma entidade do primeiro conjunto pode ou
não se relacionar com uma entidade do segundo conjunto, porém
podendo ter apenas um relacionamento e vice-versa.
Tipo de relacionamento encontrado na formação de pares entre duas
entidades, sendo esses pares opcionais.

(1,1): (0,1): Significa que a primeira entidade obrigatoriamente possui
um relacionamento, sendo opcional para a segunda entidade. Em
ambos os casos, apenas um relacionamento é permitido.
Esse tipo de relacionamento é encontrado nos casos em que uma entidade
possui ou controla a outra de alguma forma. Em alguns casos as entidades
podem ser unidades em uma só entidade.

(0,1): (1,1): Similar ao relacionamento (1,1): (0,1).

(1,1): (1,1): Tipo de relacionamento pouco encontrado, pois ele indica
que uma entidade não pode existir sem estar relacionada a outra.
Normalmente esse tipo de relacionamento é substituído pela unificação
das entidades. Não é um relacionamento muito recomendado, pois exige
que as entidades envolvidas sejam criadas juntas.
10.2 Relacionamento 1:N
Diferente do relacionamento 1:1 que possui poucos casos de ocorrência, o
relacionamento 1:N é bastante comum, sendo encontrado com freqüência em
grande parte dos modelos que são construídos. Podemos encontrar no
relacionamento 1:N possíveis restrições em relação as associações entre
entidades.
Exemplo de restrição: apesar de uma entidade do conjunto A se associar com
N entidades do conjunto B, cada entidade do conjunto B só pode está
associada a uma entidade do conjunto A.
As associações existentes no relacionamento 1:N são semelhantes a uma
árvore, onde a raiz pode dar origem a vários ramos, mas um ramo só será
originado de uma raiz.
Exemplo de Relacionamento 1:N (Um para muitos)
Um aluno pode está inscrito em 0 (nenhum), 1(um) ou N (diversos) cursos
Um professor é designado para atender 0 (nenhum), 1(uma) ou N (diversas)
turmas.
10.2.1 Tipos de relacionamentos 1:N

(0,1): (0,N): A primeira entidade do relacionamento 1:N pode ou não
participar do relacionamento, mas apenas uma única vez. A segunda
entidade pode ou não participar do relacionamento, ou pode fazê-lo
várias vezes.
Relacionamento muito comum, normalmente significa que duas entidades
não possuem nenhum relacionamento de propriedade ou restrição e
existência, podendo ser colocado em uma relação hierárquica.

(0,N): (0,1): Similar ao relacionamento (0,1): (0,N).

(0,1): (1,N): Esse tipo de relacionamento indica na maioria das vezes
uma relação hierárquica, onde a primeira entidade pode pertencer ou
não a relação, enquanto a segunda entidade obrigatoriamente deve
pertencer a relação.
Esse tipo de relacionamento não é muito comum, pois exige que uma
instância possua no mínimo uma “filha”. Sua utilização pode ser necessária
em casos que algo para existir deva ter pelo menos uma parte, essa parte
terá vida própria, mesmo que só possa ser utilizada em um único local.

(1,N): (0,1): Similar ao relacionamento (0,1): (1,N).

(1,1): (0,N): Tipo de relacionamento que indica a “maternidade” da
segunda entidade com relação a primeira, onde cada instância da
primeira entidade é obrigada a possuir uma “mãe” e apenas uma, que
seja instância da primeira entidade.
OBS: Tipo de relacionamento muito comum.

(0,N): (1,1): Similar ao relacionamento (1,1): (0,N).

(1,1): (1,N): Relacionamento em que é encontrada uma ”maternidade”
da segunda entidade em relação a primeira, onde cada instância da
primeira entidade é obrigada a possuir uma “mãe” e apenas uma, que
seja instância da primeira entidade. É obrigado ainda que a entidade
“mãe” possua uma “filha”.
Obs: Tipo de relacionamento que possui o inconveniente de exigir a criação de
uma entidade “filha”, para criar a entidade “mãe”.

(1,N): (1,1): Similar ao relacionamento (1,1): (1,N).
6.3 Relacionamento N:M
O relacionamento N:M representa uma associação entre entidades onde não
existe restrições com relação as possíveis relações que serão estabelecidas
entre as entidades do conjunto A e as entidade do conjunto B.
Em termos de estrutura de representação de entidades, podemos considerar o
relacionamento N:M como uma associação matricial. Nas colunas temos as
entidades do conjunto A e nas linhas temos as entidades do conjunto B. Cada
interseção entre linhas e colunas, representa um relacionamento entre as
entidades.
Ex:
Entidades
B_01
B_02
B_03
A_01
X
X
A_02
X
A_03
X
X
X
O mesmo exemplo transformado em conjuntos:
Não é obrigado que todas as entidades existentes no conjunto “A” estejam
relacionadas a várias entidades do conjunto “B”. Algumas podem não ter
nenhum relacionamento, outras somente um relacionamento e outras, vários
relacionamentos. O mesmo fato é válido para as entidades do conjunto B.
Uma pergunta que gera dúvidas em várias pessoas: “Porque utilizar M:N em
vez de M:M? ”
As letras diferentes são utilizadas para que fique claro que as duas grandezas
são totalmente diferentes.
Ex: O conjunto A pode ser relacionar com até 8 entidades do conjunto B. Uma
entidade do conj. B não necessariamente precisa se relacionar com até 8
entidades do conj. A. No caso ela poderia se relacionar com no máximo 3
entidades do conjunto A por exemplo. Neste caso teríamos M=3 e N=8.
10.3.1 Tipos de relacionamentos N:M


(0,N): (0,N): Relacionamento muito comum que representa a forma mais
geral dos relacionamentos, pois envolve todas as possibilidades para
ambos os lados, além de ser também opcional.
(0,N): (1,N): Relacionamento muito semelhante ao (0,N): (0,N), sendo
considerado também um relacionamento muito comum, porém exige que
haja pelo menos um relacionamento na segunda entidade.

(1,N): (0,N): Similar ao relacionamento (0,N): (1,N).

(1,N): (1,N): Relacionamento do tipo múltiplo que deve exigir a relação
entre as entidades pelo menos uma vez.
MÓDULO 11 – CONCEITOS DE BANCO DE DADOS RELACIONAL
Apesar de todas as dificuldades que foram apresentadas anteriormente sobre o
armazenamento de dados em arquivos lineares não redundantes e ao mesmo
tempo integrados, essa idéia é uma ótima estrutura para um banco de dados
desejável. Afinal, a organização de arquivos lineares é a estrutura de dados
mais básica disponível e a mais utilizada. Tudo o que falamos agora é
encontrado nos bancos de dados relacionais.
Em um banco de dados relacional, os dados armazenados aparentam estar em
arquivos lineares simples. Como o banco de dados relacional utiliza notações
matemáticas em suas estruturas, esses arquivos lineares são chamados de
relações, sendo que na prática chamamos mesmo é de “tabelas”. Quando
falamos em dados armazenados em arquivos, cada linha representa um
registro, e dentro de uma relação elas são chamadas de “tuplas”. Em arquivos
as colunas são chamadas de campos, e nas relações as colunas são
chamadas de “atributos”. Na prática, quando é falado em banco de dados
relacionais os seguintes sinônimos são utilizados.




Relações -> Tabelas
Tuplas -> Linhas
Registros -> Atributos
Colunas -> Campos
Existe uma diferença entre os conceitos usado nos arquivos e os conceitos
utilizados nas relações, pois em um banco de dados relacional os dados
apresentam estar armazenados em estruturas que parecem muito com um
arquivo. As diferenças são:
1. As colunas existentes em uma relação podem estar em qualquer ordem,
que o significado dos dados não é afetado. Isto não é possível em um
arquivo.
2. As linhas de uma relação podem estar dispostas em qualquer ordem, o
que não é possível em um arquivo.
3. Cada posição Linha/Coluna, que podemos chamar também de células
devem ter apenas um único valor, o que não é necessariamente verdade
em um arquivo.
4. Em uma relação não existe duas linhas que sejam idênticas, o que não
é necessariamente verdade em um arquivo.
11.1 Chave primária
“O que é uma chave?”
Chave é um conjunto de atributos de uma relação que pode ser utilizada em
qualquer operação que englobe atributos e valores de atributos.
Em algumas relações podem ser encontradas várias chaves parecidas,
também chamadas de chaves candidatas. Durante a fase de projeto lógico do
banco de dados, o Administrador de Banco de Dados escolhe uma dessas
chaves, aplicando a ela a restrição de estado único, sendo essa chave
escolhida denominada de “chave primária”.
Com a utilização de uma chave primária, uma relação nunca apresentará linhas
repetidas, significando a possibilidade de identificar cada linha separadamente
uma da outra.
Ex: Tabela de vendedores
CODIGO
001
002
NOME
Carlos
Eduardo
CIDADE
Fortaleza
São Paulo
ESTADO
Ceará
São Paulo
CATEGORIA
A03
A03
003
004
Marcos
Paulo
Campinas
Rio de Janeiro
São Paulo
Rio de Janeiro
A01
A04
VENDEDORES(CODIGO, NOME, CIDADE, ESTADO, CATEGORIA)
Na tabela de vendedores a chave primária é representada pelo conjunto
{CODIGO} uma vez que dois vendedores não apresentam o mesmo código.
Qualquer outro conjunto de atributos da relação “vendedor” que contenha
“codigo” (CODIGO, NOME, CIDADE) é uma chave candidata. No entanto a
escolha da chave primária objetiva sempre minimizar a quantidade de atributos.
Quando uma chave primária é construída com mais de um atributo da relação,
ela é denominada de “chave primária composta”, caso o contrário é
denominada de “chave primária simples”.
Entre as várias chaves candidatas de uma relação, aquelas que não foram
escolhidas como chaves primárias são denominadas de chaves alternativas e
podem ser utilizadas como chave de ordenação ou consulta. Já as chaves que
não fazem parte do conjunto de chaves candidatas são denominadas de
chaves secundárias, pois não permite a identificação individual de uma linha da
relação.
A chave estrangeira referencia sua própria relação, não sendo necessário
aparecer como chave na relação que participar.
Exemplo de chave estrangeira:
Observe na tabela de pedidos a existência de COD_FOR e COD_PECA como
chaves estrangeiras nessa relação, pois COD_FOR e COD_PECA são chaves
primárias nas relações peças e fornecedores.
11.2 As restrições de integridade
As restrições de integridade são algumas normas que foram criadas e definidas
para manter a total integridade dos dados armazenados no banco de dados. As
principais restrições de integridade são:
Restrição de domínio: Todos os valores dos atributos devem ser coerentes
com o domínio correspondente.
Ex:


Idade: Número inteiro positivo
Salário: Número real positivo
Restrição de chave primária: Cada valor existente na chave primária deve ser
único na relação a que pertence.
Restrição de entidade: O valor de uma chave primária nunca pode ser nulo,
pois o valor nulo não permite a identificação de uma linha.
Restrição de referência: Toda referência que é feita de uma linha através de
uma chave estrangeira deve ser verificada, pois toda linha que for referenciada
deve previamente existir no banco de dados.
11.3 As operações de um banco de dados relacional
Todas as operações executadas em um banco de dados relacional abordam
quatro categorias, devendo obedecer as restrições de integridade que citamos
anteriormente. As categorias são:
11.3.1 Operações sobre estruturas
As operações que são realizadas sobre as estruturas apóiam os
administradores de banco de dados nas definições e manutenções. São elas:
Inserção: Adição de novas tabelas ao plano de dados.
Remoção: Retirada de tabelas e atributos do esquema de dados.
Atualização: Adição de algum tipo de atributo a uma tabela já existente no
esquema dos dados.
As operações realizadas na estrutura do banco de dados permitem a
adaptação do BD às novas necessidades que possam surgir dentro da
empresa.
11.3.2 Operações sobre os dados
São operações realizadas sobre as linhas (tuplas) já existentes em um banco
de dados. São elas:
Inserção: Adição de uma ou mais linhas em uma relação.
Remoção: Retirada de uma ou mais linhas de uma relação.
Atualização: Alteração de algum valor de atributo de uma linha.
11.3.3 Operações sobre conjuntos
São operações aplicadas a duas relações que obedecem à compatibilidade de
união, apresentando atributos pertencentes ao mesmo domínio.
União: O resultado da união de duas relações consiste no conjunto de todas as
linhas das duas relações, sem a existência de redundância nas linhas.
Interseção: O resultado da interseção de duas relações consiste no conjunto
de todas as linhas que pertencem as duas relações.
Diferença: é o resultado da diferença entre duas relações, gerando como
resultado as linhas que pertencem a uma relação e não pertence à outra.
Produto cartesiano: é aplicada a relação que não necessitam ser compatíveis
para gerar a sua união. O resultado do produto cartesiano é uma relação que
apresenta linhas que são formadas pela combinação de todas as linhas de uma
relação com as linhas das outras.
11.3.4 Operações sobre tabelas
São as operações aplicadas a qualquer tipo de relação. São elas:
Seleção: Operação aplicada a um conjunto de relações com o propósito de
selecionar um subconjunto de linhas com todos os seus atributos, que
satisfazem a uma determinada condição que foi imposta. O conjunto de linhas
resultantes dessa seleção forma uma relação temporária.
Projeção: Operação aplicada a uma relação com o intuito de selecionar os
atributos de uma relação com base em uma lista de atributos que foi fornecida.
O resultado é uma tabela sem repetições.
Junção: Operação utilizada para combinar linhas que foram selecionadas de
duas ou mais relações, de modo a ser estabelecida virtualmente uma única
linha.
MÓDULO 12 – ARQUITETURA DOS SISTEMAS DE BANCO DE DADOS
Quando falamos em arquitetura, normalmente utilizamos esse termo para
referenciar a forma como os aplicativos computacionais são estruturados e os
hardwares estão dispostos e são utilizados. Utilizaremos o termo arquitetura
no nosso capítulo para descrever a forma que os hardwares que são utilizados
pelos sistemas de banco de dados estão dispostos e a forma como os SGBD`s
serão utilizados.
A indústria da computação está atravessando uma grande evolução atualmente
o que proporcionou o barateamento dos equipamentos de hardware,
possibilitando que os enormes e caros mainframes fossem substituídos por
pequenos, mas potentes computadores. Os sistemas computacionais também
acompanharam essa evolução, sendo desenvolvidos sobre arquiteturas
flexíveis, eficientes e abertas.
A escolha da arquitetura ideal é cercada de perguntas e dúvidas. A pergunta
mais comum é: O que é uma arquitetura desse tipo? O que é necessário para
promover a sua implementação? Quais são as principais vantagens e
desvantagens em utilizar esse tipo de arquitetura? Vamos tirar todas essas
dúvidas falando um pouco sobre cada uma das arquiteturas existentes.
12.1 Arquitetura de banco de dados centralizada
O modelo computacional que é utilizado durante anos é o chamado sistema
centralizado composto por um “host” e vários “terminais” onde os terminais
possuem pouco poder de processamento e são compostos apenas pelo
monitor e o teclado que ficam conectados a um grande computador
“mainframe” que possui a capacidade de processar e armazenar os dados.
Esse tipo de arquitetura tem como característica a necessidade de grandes
investimentos tanto na aquisição de equipamentos como na manutenção dos
mesmos.
Considerando a utilização de um sistema de gerenciamento de banco de
dados, ele e todos os seus aplicativos são hospedados no host e são
acessados pelos terminais “burros” que estão conectados ao host. Dessa
forma, todo o processamento dos dados é realizado no computador central.
Principais Vantagens:



Um único host fornece alto grau de segurança, concorrência e controle
de cópias de segurança e recuperação.
Não há necessidade de um diretório distribuído, já que todos os dados
estão localizados em um único host.
Não existe a necessidade de junções distribuídas, já que todos os dados
estão em um único host.
Principais desvantagens:


Todos os acessos aos dados realizados por outro que não seja o host
onde o banco de dados está, gera alto custo de comunicação.
O host em que o banco de dados está localizado pode criar um
“gargalo”, dependendo da quantidade de acessos simultâneos.

Podem acontecer problemas de disponibilidade dos dados, se o host
onde os dados estão armazenados sair do ar.
12.2 Arquitetura de banco de dados descentralizada
Na arquitetura de banco de dados descentralizada os dados são armazenados
em pelo menos dois hosts, sendo que a totalidade dos dados são armazenados
em um único servidor e em outros servidores são mantidos parte do banco de
dados. Todo tipo de transação que é realizada, é feita primeiro no servidor local
antes de ser atualizado o servidor central.
Principais vantagens:



Autonomia local.
Custo de comunicação reduzido, pois cada tabela pode ficar localizada
no host que mais a usa.
Aumento da disponibilidade dos dados.
Principais desvantagens:

Os diversos locais tem que se preocupar com a segurança, concorrência
e cópias de segurança dos dados.
12.3 Arquitetura de banco de dados distribuída
A arquitetura de banco de dados distribuída tem como característica a
subdivisão dos dados e o seu compartilhamento entre vários computadores e a
sua atualização é feita através de um sincronismo entre os computadores
pertencentes ao circuito de distribuição. A arquitetura distribuída utiliza vários
SGBD`s que são espalhados pelos hosts e contendo dados replicados em
vários lugares em que bancos de dados diferentes são consultados ao mesmo
tempo por um mesmo usuário. Os dados são distribuídos pela rede e quando é
feita uma consulta pelo usuário essa distribuição é transparente, fazendo com
que o usuário pense que ele está consultando os dados de apenas um
computador e não vários computadores.
Principais vantagens:



Utilização de diferentes SGBD`s;
Utilização de diferentes tipos de computadores;
Possibilidade de acessar os dados de vários computadores como se
fosse de apenas um só.
Principais desvantagem:

Esforço computacional para que seja mantida a consistência dos dados
e a sua segurança.
12.4 Arquitetura de banco de dados replicada
Na arquitetura de replicação, os dados são armazenados em hosts replicados
permitindo que a falha de um determinado host possa ser contornada pelo host
que irá substituí-lo. O banco de dados primário é igual ao banco de dados
secundário. As transações atualizam primeiro o banco de dados primário para
depois ser atualizado o banco de dados secundário.
Principais Vantagens:

Custo de comunicação reduzido para o acesso aos dados apenas para
leitura, pois as cópias das tabelas podem estar localizadas nos hosts
que mais utilizam.

Melhor disponibilidade pois se um host com um banco X sair do ar, o
outro host que possui a replicação do mesmo banco entra em ação.
Principais desvantagens:

O controle de concorrência em diversos bancos quando os dados das
tabelas replicadas são atualizados.
12.5 Arquitetura de banco de dados paralela
Na arquitetura de banco de dados paralela é utilizado o paralelismo de vários
servidores que trabalham simultaneamente sobre os seus respectivos bancos
de dados para a obtenção de um rápido resultado. No paralelismo os
servidores são alinhados e cada um é responsável pelas sub-tarefas de um
banco de dados.
Toda unificação e distribuição é realizada por um hardware que tem o papel de
roteamento, fazendo com que o particionamento seja de dois tipos:

HASH: No particionamento HASH as tabelas são particionadas
igualmente segundo uma chave de hashing. A sua utilização é ideal para
aplicativos que enfatizam o acesso associado.

RANGER: No particionamento RANGER as tabelas são divididas por
vários valores de chaves. A sua utilização é ideal para aplicações que
enfatizam a busca pela chave de particionamento.

ESQUEMA: As tabelas são distribuídas entre vários servidores e a sua
utilização é ideal quando se possui grandes quantidades de tabelas
pequenas.
MÓDULO
13
–
CLIENTE/SERVIDOR
ARQUITETURA
DE
BANCO
DE
DADOS
Depois de falarmos no capítulo anterior sobre algumas arquiteturas de banco
de dados existentes, vamos dedicar este capítulo a arquitetura mais utilizada
atualmente. Na arquitetura cliente/servidor, são utilizados computadores
pessoais e servidores conectados em uma rede local em que o processamento
é dividido entre clientes e servidores.
Relembrando os conceitos de rede local (LAN) vistos na disciplina de Redes,
uma rede local é uma tida como uma organização de computadores
conectados através de uma rede. Quando falamos em local, significa dizer que
os computadores devem estar localizados próximos uns dos outros, dentro de
um prédio ou em um prédio vizinho. Umas das principais vantagens de um LAN
é o compartilhamento de recursos, então certamente também podemos
compartilhar os dados existentes nos bancos de dados.
Quando utilizamos um banco de dados na arquitetura cliente/servidor, todo o
processamento é feito no computador cliente que roda o aplicativo que utiliza o
banco de dados, e o computador servidor é responsável por hospedar o SGBD
propriamente dito ou parte dele. A maioria das estruturas que utilizam a
arquitetura cliente/servidor dedicam um computador exclusivo para rodar o
SGBD.
O aplicativo de banco de dados existente no computador cliente é chamado de
front-end, sendo responsável pelo processamento de entrada e saída dos
dados dos usuários. O sistema back-end existente no servidor é responsável
por manipular o processamento dos dados e acesso ao disco.
Exemplo de um processamento entre cliente e servidor.

O usuário localizado no computador cliente gera uma consulta de dados
para o servidor de banco de dados. O servidor de banco de dados
executa a pesquisa e retorna somente os dados que foram solicitados
pelo usuário.
Podemos observar que existe uma grande vantagem nesse tipo de arquitetura
que é a divisão de processamento entre dois sistemas, o que aproveita muito
bem as características de cada hardware para cada aplicação específica.
13.1 Abordagem duas camadas
Na abordagem duas camadas são utilizados softwares para tornar a
localização dos dados transparente para o usuário que utiliza o computador
cliente. Essa transparência é necessária, pois quando o usuário faz uma
consulta no computador cliente, o software verifica primeiro se os dados
solicitados estão no disco rígido do próprio PC do cliente. Se estiverem, os
dados serão recuperados e a consulta é finalizada, se não, o software procura
por esses dados automaticamente no servidor.
13.2 Abordagem três camadas
A abordagem três camadas é bem mais sofisticada. Se o software não
encontrar os dados no disco rígido local ou no servidor localizado na LAN, ele
pode deixar a LAN através de um gatway e procurar os dados, por exemplo,
em um mainframe que pode ser alcançado a partir de muitas LAN`s.
Um outro exemplo de abordagem três camadas é aquela que utiliza os
seguintes computadores:
Computadores clientes;
Servidores de aplicação;
Servidores de banco de dados.
Nessa abordagem a interação inicial é feita pelo computador cliente, mas ele
agora pode solicitar uma variedade de aplicações que podem ser executadas
pelo servidor de aplicação. O servidor de aplicação depende do servidor de
banco de dados para fornecer os dados necessários para a aplicação.
13.3 Definição consensual da arquitetura cliente/servidor

Consiste em um processo realizado no cliente e outro no servidor que
podem ser distinguido um do outro, embora interajam totalmente;

Tanto cliente como servidor podem operar em diferentes plataformas;

Tanto a plataforma cliente como a plataforma servidora podem ser
atualizadas sem que a atualização de uma dependa da atualização da
outra;

O servidor pode atender a vários clientes simultaneamente e em alguns
casos um cliente pode acessar vários servidores;

A ação em geral é iniciada pelo cliente e não pelo servidor.

A interface gráfica amigável geralmente reside no computador cliente.

O servidor de banco de dados deve fornecer proteção e segurança aos
dados.
13.4 Vantagens e desvantagens da arquitetura cliente/servidor
A crescente popularidade da arquitetura cliente/servidor se deve principalmente
a evolução dos processadores, o que permite a eles a realização de trabalhos
que anteriormente eram realizados apenas pelos mainframes. Essa evolução
dos microprocessadores aliada as modernas técnicas de rede, permitiu a
conexão de vários computadores clientes a um potente computador que
funciona como servidor, substituindo com economia os sistemas centralizados.
É característica básica da arquitetura cliente/servidor tirar o máximo de
vantagens dos recursos computacionais, permitindo que plataformas diferentes
trabalhem juntas onde cada uma faz o trabalho que melhor executa. Podemos
combinar diferentes produtos de softwares para clientes, com diferentes
produtos de softwares para servidores. Essa é uma vantagem para os
fornecedores, pois eles podem interagir com o máximo de produtos
complementares possíveis, aumentando assim a opção de produtos.
Da mesma forma que existem vantagens, existe também as desvantagens da
arquitetura cliente/servidor e uma das principais desvantagens na sua
utilização é a sua complexidade. Com a sua complexidade, é difícil detectar os
problemas quando o sistema falha. A independência de aplicativos também
tem o seu lado negativo, pois a existência de vários front-ends no banco de
dados aumenta a quantidade necessária de suporte à programação, pois
variados códigos de programas devem ser desenvolvidos e mantidos. As
alterações na estrutura do banco de dados podem causar problemas nos frontends que utilizam diferentes plataformas.
A arquitetura cliente/servidor está sendo rapidamente incorporada aos sistemas
de gerenciamento de banco de dados relacionais comerciais. A sua
incorporação constitui na adequação dos SGBD`s para a divisão dos níveis
clientes e servidores. Assim, alguns computadores podem rodar apenas o
software cliente, outros podem ser máquinas servidoras dedicadas que rodam
apenas o software servidor, enquanto outros computadores podem suportar
ambos os módulos cliente e servidor.
MÓDULO 14 – OS USUÁRIOS E O GERENCIAMENTO DOS BANCOS DE
DADOS
Com o surgimento dos primeiros sistemas de gerenciamento de banco de
dados, algumas empresas perceberam a necessidade de criar um
departamento para gerenciar os SGBD`s e o seu ambiente. Com o passar do
tempo esse departamento de gerência também assumiu as responsabilidades
de gerenciar os dados armazenados em arquivos, planejamento estratégico
dos dados, estabelecimento de políticas e outras tarefas.
A administração dos bancos de dados consiste na gerência dos dados e na
gerência dos bancos de dados.
Gerência dos dados: Tem como função o planejamento e análise, sendo
responsável pelo estabelecimento de políticas e padrões dos dados fazendo
com que os dados de uma empresa sejam promovidos como recurso
competitivo.
Gerência dos bancos de dados: Tem como característica a sua orientação a
operações, realizando o monitoramento e o gerenciamento diário dos bancos
de dados existentes na empresa e também o fornecimento de um suporte
especializado os projetistas de programas durante o desenvolvimento dos
sistemas de informação.
14.1 As vantagens da administração dos dados e dos bancos de dados
Porque as empresas necessitam de departamentos para administração dos
dados e dos bancos de dados???
A maioria das empresas tem feito esse tipo de questionamento. Como
atualmente seus negócios dependem cada vez mais dos dados que estão
armazenados, as funções que são desempenhadas pelo departamento de
administração dos dados são reconhecidas e valorizadas como nunca foram
antes.
14.1.1 Os dados como recurso corporativo compartilhado
Considerando os dados como recurso corporativo, observamos que eles
ocupam um lugar de respeito ao lado dos equipamentos, pessoal, dinheiro e
outros recursos corporativos. Todos os aspectos citados são dependentes dos
sistemas de informação da empresa e do fluxo de dados que trafega pelo
sistema. As empresas não conseguem operar sem o seu estoque de dados de
pessoal, clientes, fornecedores, produtos, etc. Por isso que dizemos que um
dado é um importante recurso, pois por natureza ele descreve todos os outros
recursos.
Por ser um recurso tão importante os dados podem causar gargalos na sua
utilização, pois a medida que as funções corporativas buscam um mesmo dado
para executar as suas tarefas, a formação de um gargalo pode diminuir o
acesso aos dados. A primeira providência a ser tomada para solucionar esse
problema, é a aquisição de equipamentos mais modernos e em segunda
instância, a duplicação desses dados para atender as necessidades das
funções corporativas. Só que com a utilização dessas duas alternativas
acabamos por gerar um novo problema, pois a aquisição de novos
equipamentos possui certo limite e a duplicação dos dados acaba por gerar
dados redundantes. Qual a solução agora?
Chegamos à conclusão que qualquer recurso corporativo compartilhado requer
um departamento para gerenciá-lo. Faz muito pouco sentido possuir um
recurso importante e não ter um departamento para administrá-lo.
14.1.2 Gerenciamento operacional dos dados
Falando a nível operacional, para que seja feito o gerenciamento diário de um
banco de dado de uma empresa, é necessário a existência de um
departamento exclusivo para esse gerenciamento. Os dados que são
compartilhados para serem utilizadas pelas várias funções de um sistema e os
seus respectivos usuários, podem ser gerenciados por um setor leal a empresa
e não a alguma função em específico.
Trabalhar com os dados a nível operacional requer um conhecimento muito
bom do SGBD que está sendo utilizado e das tarefas específicas que envolvem
a segurança dos dados, copias de segurança e recuperação. Esse tipo de
tarefa não pode ser realizado por programadores e analistas, é necessário que
todas elas sejam desempenhadas por um profissional especialista.
14.1.3 Gerenciamento de banco de dados que foram adquiridos
externamente
No ambiente de alguns sistemas de informação, alguns bancos de dados são
adquiridos como parte de um sistema comprado. Um ERP é um ótimo exemplo
de um software multifuncional integrado juntamente com um banco de dados.
O pacote do ERP é composto pelos módulos de aplicação que gerenciam uma
grande variedade de funções empresarias e ele geralmente inclui também no
seu pacote de módulos um banco de dados central que é compartilhado por
todos os módulos do ERP. O banco de dados existente no ERP não foi
projetado pelo próprio pessoal da empresa, mas assim como falamos
anteriormente, para gerenciamento dos recursos compartilhados existentes no
banco de dados do ERP, é necessário ter um setor independente responsável.
14.1.4 Gerenciamento dos dados em um ambiente descentralizado
Com o avanço das redes locais as empresas resolveram descentralizar
algumas partes dos seus sistemas de informação, pois permitiria a alguns
departamentos lidar com as necessidades do seu sistema de informação sem
que dependesse da organização central do sistema de informação.
Um dos motivos que gerou essa descentralização dos sistemas de informação
era a diminuição do “overhead” do departamento central do sistema de
informação. A descentralização não virou uma regra e a maioria das grandes
empresas não implantou sistemas de informação totalmente descentralizados,
sendo que grande parte utiliza o modelo híbrido formado por sistemas
centralizados e sistemas descentralizados.
14.2 Os usuários de um banco de dados
São vários os usuários que utilizam o banco de dados onde cada um possui
uma necessidade em particular. Podemos classificar os usuários de um BD nos
seguintes tipos:
14.2.1 Administrador de banco de dados - DBA
O administrador de banco de dados é o chefe responsável por supervisionar e
gerenciar os recursos que são disponibilizados pelo banco de dados. Em uma
organização em que os recursos são compartilhados entre muitos usuários, a
necessidade desse profissional é de vital importância. O DBA têm o papel de
administrar os recursos primários e secundários formados pela base de dados,
SGBD e os softwares relacionados, assim como autorizar o acesso a base de
dados e coordenar e monitorar a sua utilização.
14.2.2 Projetista de banco de dados
Os projetistas possuem a função de identificar os dados que serão
armazenados no banco de dados e escolher a estrutura ideal para esse
armazenamento. Para que seja feita a escolha da estrutura apropriada é
necessário uma comunicação com os usuários do BD para que seja obtida uma
melhor visão dos dados através da opinião de cada usuário. Depois de coletar
todas essas informações são feitas análises e posteriormente o projeto da base
de dados que atenda as necessidades dos usuários finais.
14.2.2 Os usuários finais
São os profissionais que tem acesso ao banco de dados para a realização de
consultas, modificações dos dados e a geração de relatórios. Existem algumas
categorias de usuários finais:

Usuários ocasionais: os que ocasionalmente fazem acesso a base de
dados.

Usuários comuns: são os que realizam operações padrões de
consultas e atualizações.

Usuários sofisticados: formado por engenheiros e analista de negócios
que utilizam o BD para atender aos seus requisitos complexos.

Analistas e programadores: utilizam o banco para a integração dos
usuários promovendo a sua interação com o BD além de desenvolver
especificações para novas aplicações que possam surgir.
MÓDULO 15 – AS RESPONSABILIDADE EM ADMINISTRAR OS DADOS E
OS BANCOS DE DADOS
.As empresas estão utilizando os sistemas de informação para desempenhar
funções em todos os seus setores, isso faz com que o papel do analista de
dados também chamado de administrador de dados, torne-se algo crítico no
ambiente empresarial. É necessário que o administrador de dados tenha
compreensão do fluxo de dado que trafega entre os departamentos, empresas,
clientes e fornecedores, para que ele possa entender realmente como o
sistema trabalha com os dados na empresa.
O administrador de dados possui algumas responsabilidades que ele deve
executar dentro da empresa. São elas:
15.1 Responsabilidades na coordenação dos dados
A responsabilidade em coordenar os dados é de vital importância, devido
principalmente ao papel que os dados desempenham. Devido a complexidade
de fatores em que os dados estão envolvidos, a possibilidade de ocorrer erros
e incoerências é muito alta. Os complicadores que podem causar esses
problemas são os seguintes:





Redes locais
Servidores
Mainframes
Ambientes centralizados
Ambientes descentralizados
Exemplo de um problema:
Dois gerentes de diferentes setores estão fazendo uma apresentação que na
teoria utilizam os mesmos dados e o mesmo modelo de planilha, só que a
planilhas apresentadas possuem valores diferentes.
Esse tipo de problema pode ser perturbador dentro de uma empresa, pois se
as informações são as mesmas, as planilhas são semelhantes, como os
valores podem ser diferentes?
É papel dos administradores de dados a responsabilidade de manter o controle
e organização dos dados, de modo que o problema que foi citado como
exemplo não aconteça. Sabemos que é quase impossível o controle total dos
dados existentes dentro de uma empresa, pois eles estão espalhados entre
diversos computadores e diversos tipos de armazenamento, mas a
desorganização total também não é desejada. Cabe então aos administradores
dos dados coordenarem os dados de modo que seja mantido o controle sobre
os dados da empresa.
15.2 Responsabilidades no planejamento dos dados
As responsabilidades em planejar os dados são iniciadas na determinação de
quais dados serão necessários para os empreendimentos de uma empresa, e
as aplicações que utilizam esses dados. Como hoje existem empresas que se
integram na busca de troca de informações, é necessário que seja feito o
planejamento para a integração dos novos dados com os que já existem na
empresa.
Algumas metodologias foram desenvolvidas para auxiliar no planejamento dos
dados. Elas levam em consideração os negócios que são realizados pela
empresa, acrescentando dados necessários para suportá-los.
Exemplo: Hardwares e softwares são questões que devem ser observadas e
planejadas pela empresa, para que seja possível suportar as operações
realizadas pelo seu sistema de informação no futuro.
Outros aspectos envolvidos são:





Quantidade de discos rígidos necessários para o armazenamento dos
dados.
Poder de processamento necessário
Metadados e dicionário de dados.
Migração de dados antigos anteriores ao banco de dados para o banco
de dados atual.
Migração de dados de um SGBD para outro.
Todos esses aspectos que citamos estão envolvidos nas responsabilidades de
planejar os dados da empresa.
15.3 Responsabilidades em padronizar os dados
A padronização dos dados reduz as possibilidades de ocorrência de erros e
aumenta o desempenho dos profissionais ligados aos sistemas de informação
em entender os trabalhos que foram feitos por outros profissionais.
Exemplo de padronização de dados:



Nomes de atributos (Devem ser significativos e consistentes)
Nomes de tabelas.
Instruções de chamada dos programas ao banco de dados.
15.4 Responsabilidades no treinamento de outros profissionais
O administrador dos dados é o responsável em algumas empresas pelo
treinamento dos profissionais que possuem a necessidade de conhecer os
dados da empresa e o SGBD. Com esse treinamento os profissionais adquirem
o conhecimento sobre o banco de dados, suas funções e a sua importância
dentro da empresa.
Os conhecimentos adquiridos com o treinamento são:





A importância do compartilhamento dos dados;
A importância da sua segurança;
Importância dos dados privados;
Os conceitos de banco de dados;
Padrões de banco de dados.
15.5 Responsabilidades na administração dos bancos de dados
As responsabilidades em administrar os bancos de dados envolvem operações
que devem ser desempenhadas diariamente no ambiente de banco de dados.
É necessário um profissional com conhecimentos específicos em SGBD para
desempenhar todas essas funções.
Listaremos as funções desempenhadas pelo administrador de banco de dados
logo abaixo:
15.5.1 Monitoramento do SGBD
A principal função desempenhada pelo DBA é o monitoramento do
desempenho do SGBD, onde ele tem o controle sobre quais as aplicações que
estão utilizando o banco de dados e se o tempo de resposta do banco está
sendo satisfeito ou não. Tanto o monitoramento como o controle são
necessários, pois no caso de perca de desempenho do sistema, o DBA pode
tomar atitudes para contornar o problema. As informações que são coletadas
com o monitoramento podem também detectar problemas como consultas
ineficientes que devem ser novamente projetadas.
15.5.2 Detecção e correção de erros
Todos os tipos de aplicações estão sujeitas a ocorrência de erros, como um
SGBD também é uma aplicação ele também está sujeito a erros que podem
ser causados por problemas de hardware e software do sistema. Quando um
erro desse tipo acontece, o administrador de banco de dados deve ser
acionado para verificar os motivos que levaram a ocorrência do determinado
erro, e encontrar a forma mais rápida de solucionar o problema.
15.5.3 Manutenção do SGBD
Cabe ao administrador de banco de dados as atividades de manutenção dos
dados e dos softwares que envolvem o SGBD. As atividades a serem
desempenhadas pelo DBA são:




Instalação de novas versões do SGBD
Instalação de pacotes de atualização para correção de erros.
Cópias de segurança e recuperação.
Modificação da estrutura dos dados.
MÓDULO 16 – A IMPORTÂNCIA DA SEGURANÇA DOS DADOS
Os diferentes tipos de recursos corporativos possuem diferentes maneiras de
serem gerenciados. O gerenciamento ideal vai depender muito da importância
do recurso.
Ex:

Os recursos como o dinheiro devem ser protegidos de eventuais roubos;

Os recursos que envolvem os equipamentos devem ser protegidos de
má utilização;

A estrutura da empresa deve possuir guardas e sistemas de segurança.
A segurança dos dados não é muito diferente dos outros recursos citados,
sendo necessárias soluções padronizadas e bem pensadas que possam
promover a segurança dos dados. A segurança dos dados é crítica para as
empresas, pois os seus negócios dependem dos dados e dos sistemas de
informação para o seu sucesso. Uma pequena brecha por menor que seja na
segurança dos dados, pode afetar a capacidade de operação e de produção de
uma empresa.
Quando a segurança dos dados de uma empresa é questionada, pode ser que
outras pessoas que não fazem parte da empresa sejam atingidas. Os clientes
podem ter seus dados financeiros expostos, os fornecedores podem ter as
suas transações expostas, além de vários outros problemas que são causados
pelo vazamento de informações.
Quando se trabalha com dados e sistemas de informação, algumas brechas de
segurança podem ser encontradas. Citaremos abaixo algumas falhas de
segurança conhecida.
1. Acesso não autorizado aos dados: O acesso não-autorizado é o tipo mais
básico de falha na segurança dos dados. Ela acontece quando uma pessoa
obtém o acesso a dados que ela não está autorizada a ver. Esse tipo de falha
pode ser apenas de um registro de uma tabela de banco de dados, até o
acesso a uma cópia de uma tabela inteira ou mesmo de um banco de dados
inteiro.
Ex: A empresa X está interessada em adquirir a lista inteira de clientes da
empresa concorrente ou mesmo os planos de um novo produto que será
lançado.
Uma quantidade de diferentes usuários pode estar envolvida no acesso não
autorizado aos dados, isso inclui também os próprios funcionários da empresa.
Nos casos em que os funcionários estão envolvidos a situação é ainda mais
complicada, devido ao fato de o controle ser mais complexo do que controlar o
acesso de um usuário externo.
2. Modificação dos dados sem autorização: nesse tipo de situação, os
valores dos dados são alterados sem que essa alteração esteja autorizada a
ser executada.
Ex: imagina e situação em que o gerente de um banco aumenta o seu próprio
salário.
3. Danos acidentais aos dados: Os danos acidentais também envolvem
questões sobre a segurança dos dados. Os dados podem ser alterados ou
corrompidos em uma ação acidental ou intencional, com isso alguns desses
dados são inutilizados ou corrompidos. O hardware neste caso deve ser
protegido, pois se ele for danificado intencionalmente os dados que estão
armazenados nele também serão afetados.
Existem vários métodos que são utilizados para causar a violação dos dados.
Eles estão divididos em diversas categorias:
1. Acesso não autorizado ao computador: Uma boa forma de roubar os de
uma empresa é através do acesso não autorizado aos computadores da
empresa. Esse tipo de acesso pode ser feito das seguintes formas:

Obtendo o acesso de fora da empresa através da exploração de falhas
de segurança na rede.

Roubo de login e senha de usuário da empresa, fazendo com que o
acesso pareça que está sendo realizado por um usuário legítimo.
2. Interceptação de dados: A interceptação dos dados é bem parecida com o
conceito de grampear linhas telefônicas. Os dados podem estar muito bem
protegidos no computador da empresa, mas assim que são transmitidos para
fora eles perdem todo o aparato de segurança que foi montado pela empresa e
estão sujeitos a roubo enquanto estão sendo transmitidos. Alguns meios de
transmissão são mais susceptíveis a interceptação dos dados do que outros.



Grampear cabo par trançado e coaxial é possível.
Transmissão via satélite também está sujeita a interceptação.
Interceptar transmissões via fibra óptica não é uma tarefa fácil de ser
realizada.
3. Roubo de mídias, discos rígidos e computadores: é até estranho de se
escutar quando alguém fala: é possível roubar um computador? E um disco
rígido? Se fosse antigamente quando todos os computadores eram enormes,
esse tipo de questionamento era quase impossível de ser feito. Contudo, hoje
isso é bastante possível, e pendrivers, mídias de CD, mídias DVD, discos de
armazenamento externo, além dos notebooks, todos estão sujeitos a serem
potenciais vítimas de roubo de dados intencionados.
16.1 Medidas que devem ser tomadas para promover a segurança dos
dados
Devido à importância crítica dos dados e as possíveis ameaças que eles
possam sofrer, algumas medidas foram tomadas para proteger os dados e o
hardware no qual eles estão armazenados.
16.1.1 Segurança física na estrutura da empresa
Existem algumas medidas que devem ser tomadas para promover a segurança
dos dados e dos sistemas de hardware existentes na empresa. As medidas são
as seguintes:



Não colocar os equipamentos em porões para evitar possíveis
problemas com enchentes;
Não colocar os equipamentos no térreo para evitar possíveis acidentes
com automóveis desgovernados;
Não colocar os equipamentos acima do oitavo andar da empresa, pois é
a altura máxima que a escada dos bombeiros pode alcançar.
Questões de segurança física com relação ao acesso de pessoal ao CPD:



Acesso com senha;
Acesso com cartão magnético;
Acesso biométrico.
16.1.2 Controle no acesso aos sistemas da empresa
Além de proteger a estrutura é necessário também ter o controle no acesso de
usuários aos sistemas da empresa. É preciso criar defesas contra o acesso de
usuários não autorizados. Uma das melhores formas de controlar esse tipo de
acesso é com a utilização de senhas pelos funcionários que deve ser pessoal.
16.1.3 Controle no acesso ao banco de dados
Mesmo que o usuário tenha acesso ao banco de dados, é preciso criar algum
tipo de restrição nesse acesso (ele não pode acessar tudo que deseja). Esse
tipo de restrição faz com que o usuário só tenha acesso a determinados tipos
de dados, de modo que apenas certas pessoas possam recuperá-los ou alterálos.
Em nível de SGBD um usuário não pode simplesmente sair acessando todos
os dados que estão armazenados. O usuário precisa receber um tipo de
autorização para acessar os dados.
16.1.4 Treinamento dos funcionários
Uma medida de segurança que parece ser simples mas que surte muito efeito
é treinar os funcionários da empresa em boas práticas de segurança. Algumas
dessas práticas são:

Quando sair, desconecte o computador.



Não escreva a sua senha de acesso em local algum.
Não deixe disquetes e outros meios de armazenamento espalhados pelo
escritório.
Não leve nenhum meio de armazenamento para fora do escritório.
Promover a segurança dos dados não é algo simples de ser feito, devido à
importância dos dados nas estratégias da empresa eles são muitos visados
para promover vantagens competitivas. Se todas as medidas e cuidados que
foram falados neste capítulo forem aplicadas é provável que não solucione
todos os problemas, mas trará bem mais segurança aos dados do que se não
fossem aplicados.
MÓDULO 17 – CÓPIAS DE SEGURANÇA E RECUPERAÇÃO DOS DADOS
A importância da cópia de segurança e a recuperação dos dados são
independentes de quão sofisticado seja o sistema de informação. É preciso
estar preparado para lidar com as adversidades que possam surgir e que
podem afetar ou até mesmo destruir por completo todos os dados de um banco
de dados. Existem vários problemas que podem acontecer com os dados,
desde algo simples como um valor digitado incorretamente na base de dados
ou algo muito grave como um desastre que destruiu o CPD inteiro e tudo que
havia dentro dele. Em negócios que envolvem a utilização dos sistemas de
informação é provável que em algum momento algo possa acontecer de errado
com os dados. É preciso possuir ferramentas que possam corrigir esses erros
ou reconstruir o que foi destruído.
17.1 Cópias de segurança
A idéia da cópia de segurança é bem simples. Primeiro é executada a tarefa de
cópia de segurança dos dados de um banco de dados, respeitando um
cronograma regular que foi traçado. Essa cópia deve ser guardada em um local
seguro, longe da estrutura do CPD, pois se por acaso ocorrer um acidente e
todo o CPD for destruído, a cópia dos dados estará segura em outro local. As
possibilidades para o armazenamento da cópia dos dados são enormes,
podendo ser guardada em um cofre a prova de fogo, em um cofre de banco ou
até mesmo em uma filial da empresa que reside em outra estrutura.
A outra tarefa que deve ser realizada após a cópia de segurança ser gerada é
a criação de um arquivo de registro, também chamado de “log”, que contenha
todas as alterações que aconteceram nos dados. As alterações são as
seguintes:




Atualização de registros existentes.
Inclusão de novos registros.
Exclusão de registros existentes.
Registros de todas as transações.
Com a geração do arquivo de registro (log) é possível ter documentado as
alterações que os dados sofreram.
17.2 A recuperação dos dados para frente
Vamos imaginar uma situação em que a tabela de clientes da empresa X foi
totalmente danificada. Para que seja possível recuperar os dados dessa tabela,
é preciso recorrer ao procedimento de recuperação para frente dos dados.
Para que esse procedimento seja realizado é necessário ter em mãos a última
cópia de segurança dos dados que foi feita e o arquivo de registro com todas
as alterações que foram feitas na tabela, desde que a ultima cópia de
segurança foi realizada. Com a cópia de segurança e o LOG a disposição,
cabe ao programa de recuperação detectar os dados que necessitam ser
recuperados. O programa lê a primeira entrada do arquivo de LOG que foi
gravado após a última cópia de segurança ter sido gerada e atualiza a cópia de
segurança da tabela com a entrada do LOG. Volta novamente ao início do LOG
e continua rodando para frente realizando cada atualização na cópia de
segurança da tabela, na mesma ordem na qual elas foram originalmente feitas
na própria tabela do banco de dados. Quando esse procedimento é concluído,
a tabela perdida foi totalmente reconstruída.
17.3 A recuperação dos dados para trás
Para falarmos da recuperação dos dados para trás, vamos utilizar um exemplo
diferente de situação. Na empresa Y foi detectado que no meio de uma
operação normal no seu banco de dados, foi descoberto um erro que envolve
um dado que sofreu uma atualização recentemente. Seria muito fácil corrigir
esse tipo de erro, pois era só alterar novamente o valor errado para o valor
correto e pronto, problema solucionado. Só que não é bem assim que se
resolve esse tipo de problema, pois no caso de outra aplicação ter lido esse
dado que estava incorreto e feito uso dele, o erro foi expandido para outros
cantos do banco de dados. Todas as alterações que foram feitas no banco de
dados desde que o erro foi descoberto devem ser desfeitas. O processo para
resolver esse tipo de situação é chamado de “Rollback” ou recuperação para
trás.
A idéia básica do Rollback é a seguinte: Começa com o banco de dados no seu
estado atual e o LOG posicionado na última entrada que foi feita nele.
OBS: Nesse tipo de procedimento não é necessário a utilização de cópias de
segurança.
O programa de recuperação prossegue para trás no arquivo de LOG,
restabelecendo cada valor de dado atualizado no banco de dados, com a sua
imagem de antes, até que alcance o ponto em que o erro aconteceu. As
transações são desfeitas em ordem revessa.
Alguns sistemas podem iniciar automaticamente uma operação de Rollback
, com o intuito de desfazer as alterações que foram feitas no banco de
dados por uma transação que falhou antes da sua conclusão.
17.4 Duplicação e espelhamento dos bancos de dados
O espelhamento ou duplicação do banco de dados é uma técnica de cópia de
segurança e recuperação bem diferente das técnicas que já falamos. Esse tipo
de operação tem como característica manter duas cópias do banco de dados
inteiro e atualizar os dados em ambas as cópias simultaneamente. Se
acontecer de uma cópia ser totalmente destruída, as aplicações que utilizam o
banco de dados podem continuar a serem executadas, só que agora utilizando
o banco de dados que foi duplicado.
Quanto maior a distância entre os bancos espelhados, melhor a segurança. Se
as cópias estiverem no mesmo disco e em uma fatalidade o disco ficar
inoperante, ambas são perdidas. Agora se elas estiverem em discos separados
a probabilidade de perder os dois discos e consequentemente os dois bancos
diminui bastante.
17.5 Conclusão
As empresas devem está preparadas para a ocorrência de desastre com os
seus dados e com os seus sistemas de informação. Esse tipo cautela é algo
caro para as empresas, mas como elas estão cada vez mais dependentes dos
seus sistemas de informação para sobreviverem, as que quiserem ser
realmente cuidadosas e estarem preparadas para o pior, vão ter que investir.
Existem alguns procedimentos básicos que devem ser tomados para prevenir
ou amenizar a ocorrência de desastres com os dados e os sistemas de
informação. São eles:

Manter seus sistemas de banco de dados e sistemas de informação
totalmente espelhados;

Contratar empresas de “Hot Sites” para que sejam mantidos hardwares
semelhantes ao utilizados no CPD da empresa, de modo que possam
voltar ao ar rapidamente após a ocorrência de algum tipo de desastre;

Investir em profissionais especializados;

Investir em equipamentos e tecnologia de última geração.
Se alguns dos cuidados que citamos forem implantados pelas empresas, a
possibilidade de ela ficar inoperante quando um desastre acontecer é bem
menor do que se não fosse tomado nenhum tipo de atitude para proteger os
seus dados.
MÓDULO 18 – BANCO DE DADOS E A INTERNET
É difícil imaginar viver sem os carros, televisão e telefone. Com a internet não é
muito diferente, pois ela tornou-se rapidamente parte do nosso dia-a-dia. Os emails, sites informativos e transferência de arquivos são as associações que
fazemos quando se fala em internet e também não poderíamos deixar de citar
o comércio eletrônico. Tudo na internet agora se refere ao on-line. É banco online, notícias em tempo real, compras pela internet e jogos on-line.
As empresas encontraram através da internet novos meios para a venda dos
seus produtos, fazer alianças com outras empresas, divulgar suas marcas,
transformando o mercado a qual fazem parte em um mercado global. A
essência de todas as atividades que citamos (atividades on-line) são os bancos
de dados.
Consultar o seu saldo bancário, estoque de livros de uma biblioteca on-line,
fazer o pedido de um produto, leitura de jornais on-line, todas essas atividades
utilizam os bancos de dados para desempenhar o seu papel. Isso tudo nos
gera uma dúvida:
“Qual a diferença do banco de dados utilizado na internet, para o banco de
dados que não envolve especificamente a internet?”
A maioria dos bancos de dados utilizados na internet são relacionais, e muitos
são de natureza transacional. Os conceitos e regras dos bancos de dados
relacionais são os mesmos utilizados para as aplicações transacionais do
comércio eletrônico.
Mas onde estão as diferenças entre o ambiente com a internet e o ambiente
sem a internet? A resposta está dividida nos tópicos abaixo:
18.1 A conectividade com o banco de dados
Em um simples ambiente de banco de dados o programa da aplicação, o
SGBD e os dados podem está contidos em um mesmo computador.
Falando sobre ambiente cliente/servidor, observemos a estruturas que é
composta pelo computador do cliente conectado a um servidor em uma rede
local, onde o servidor contém o programa da aplicação, o SGBD e os dados
que são compartilhados entre todos os clientes.
Associando a estrutura cliente/servidor que citamos com a estrutura utilizada
na internet, veremos que o WWW pode ser considerado uma estrutura
cliente/servidor voltada para a internet. Os browsers no computador do cliente
são os softwares responsáveis por operar a aplicação do lado do cliente e os
servidores são os servidores WEB da empresa que permite a conectividade
com os clientes para o acesso de um site de comércio eletrônico por exemplo.
Com isso a WWW se classifica como o maior sistema cliente/servidor do
mundo.
No sistema cliente/servidor da WEB existem três tipos de computadores:



Computadores dos clientes;
Servidores WEB;
Servidores de Banco de Dados.
Mas como é feita a conectividade entre todas essas estruturas?
Vamos mostrar um caso de loja de comércio eletrônico que utiliza uma
estrutura de banco de dados.
O site de comércio eletrônico submarino.com.br comercializa vários produtos.
Para comprar um produto no site do submarino, o cliente utiliza o seu
computador pessoal para estabelecer uma conexão com o provedor de internet
e digitar a URL www.submarino.com.br. O browser do computador do cliente
envia uma mensagem para o servidor web do submarino e estabelece uma
conexão com o servidor. O servidor envia a página principal do submarino para
o computador do cliente onde existem várias opções para a escolha do produto
desejado.
“Falando em termos de sistema de informação, o que o cliente está
fazendo é procurar um produto na tabela PRODUTOS do banco de dados
do submarino”
Quando o cliente clica para escolher o produto desejado, o nome do produto é
transmitido pela internet para a aplicação que está em execução no servidor
web do submarino. A aplicação envia um comando para o SGBD relacional que
está localizado no servidor de banco de dados. A seguir, o fluxo é invertido,
retornando a informação desejada para o computador do cliente. Se o usuário
desejar comprar o produto, a transação continua com um tráfego de
mensagens indo e voltando entre o browser do cliente e o servidor WEB.
“Cada vez que o banco de dados precisar ser acessado, a aplicação
existente no servidor WEB passa um comando para o servidor de banco
de dados que consulta o banco e retorna o resultado”.
18.2 Tipos de dados
Os dados que são encontrados nos bancos de dados relacionais que não
fazem parte da internet, são na maioria de dois tipos básicos: Os dados
numéricos e os dados em formato de caracteres.
A internet e o WWW deram uma nova ênfase aos tipos de dados que são
armazenados nos bancos de dados. Agora são utilizadas imagens gráficas,
fotografias, vídeos e áudios. Imagine a tela inicial do site www.globo.com. Nela
você encontra além de textos os outros itens que citamos. Os bancos de dados
que são utilizados na internet devem ter a capacidade de armazenar todos os
tipos de dados que apresentamos. Os desenvolvedores dos sistemas de
gerenciamento de banco de dados adicionaram recursos aos seus produtos,
para que eles possam suportar outros tipos de dado que não sejam apenas
dados numéricos e caracteres.
18.3 Controle de banco de dados na internet
Os desafios são diversos quando falamos no gerenciamento dos bancos de
dados utilizando recursos web, se compararmos com os sistemas que não
estejam conectados a internet. Como o banco de dados web permite o acesso
de um público de usuários muito maior do que os que os bancos não web, eles
estão bem mais vulneráveis. Devemos dar uma ênfase especial para:
Desempenho do banco de dados: deve ser observado o tempo de resposta
do banco de dados e a quantidade de tráfego que está sendo gerada no
acesso a esse banco de dados.
Disponibilidade: um banco que é utilizado na internet deve está disponível o
tempo todo já que a internet é global, sendo utilizada em todos os horários. Os
principais causadores da indisponibilidade são:




Falha no sistema;
Falha nos sistemas de telecomunicação;
Falha no fornecimento de energia;
Tráfego excessivo que causa congestionamento no banco de dados.
Escalabilidade: os sistemas de banco de dados utilizados na internet devem
ter o seu crescimento escalável, devendo ter a capacidade de crescer em
tamanho sem afetar as operações do site.
Segurança e privacidade: como os sistemas web estão mais expostos, todas
as preocupações com a segurança desses sistemas e dos seus dados não são
nenhum exagero. Ligada a segurança está a privacidade, pois as empresas de
e-commerce possuem dados sigilosos dos seus clientes armazenados em seus
Bancos de dados. É preciso utilizar a criptografia na troca de informações
entre os clientes e o servidor, para que esses dados não sejam interceptados e
lidos durante a sua transmissão.
MÓDULO 19 – RESUMO
Faremos no módulo 15 um breve resumo sobre todos os módulos que falamos
no decorrer da disciplina de tecnologias de banco de dados para sistemas de
informação.
Começamos com o módulo 1 que fala sobre o começo de tudo, a origem dos
dados. Não podemos falar de banco de dados sem antes comentar sobre a
origem dos dados e como eles foram inicialmente utilizados bem antes de
serem armazenados em arquivos. Mostramos nesse capítulo a história dos
dados a sua evolução, e a forma como eles foram inicialmente armazenados.
Os módulos 2 e 3 falam dos dados nos ambientes empresariais. A evolução
dos computadores e a importância que os dados passaram a ter para as
empresas, fizeram com que eles fossem classificados como recurso
corporativo de alta importância. Com toda essa importância dos dados para a
empresa, foi criando um ambiente para os bancos de dados (responsáveis por
armazenar os dados) que possuem as seguintes características:








Compartilhamento dos dados;
Armazenamento de grandes volumes de dados;
Melhoria na correção dos dados;
Controle de redundância;
Controle de acesso;
Ferramentas de segurança;
Ferramentas de privacidade;
Cópia e recuperação dos dados.
Os módulos 4 e 5 são responsáveis por destacar a passagem dos dados para
o seu armazenamento em bancos de dados, abordando bem os motivos que
levaram o surgimento dos sistemas de gerenciamento de bancos de dados. Os
SGBD tornaram possível o controle de redundância, acesso, compatilhamento
e transações envolvendo os dados armazenados.
Os módulos 6 e 7 destacam um problema que sempre acontece quando não se
armazena os dados em bancos de dados, a sua integração e a redundância.
Integrar vários registros sem que existam dados redundantes é uma grande
“”dor de cabeça” para armazenar seus dados em registros. São citados vários
exemplos de dados redundantes e dados sem integração.
Nos módulos 8 e 9 é dado destaque a modelagem dos dados e a grande
importância do modelo de entidade e relacionamento. Falamos das entidades,
relacionamentos e atributos, comparando todos eles com o mundo real.
Continuamos a modelagem de dados no módulo 10 falando sobre os tipos de
relacionamentos existentes e suas associações.
O módulo 11 inicia os conceitos de banco de dados relacional, responsáveis
por resolver todos os problemas que envolvem dados redundantes e dados
integrados. Destacamos as relações, tuplas, registros e colunas existentes no
banco, e o conceito de chave primária assim como a sua importância para um
banco de dados relacional. É também falado sobre as restrições de integridade
existentes no banco relacional e as operações que podem ser realizadas sobre
a sua estrutura.
O módulo 12 destaca a arquitetura dos bancos de dados e a maneira que eles
são estruturados. Existem várias formas de estruturar os dados, dentre elas
tempos:





Banco de dados centralizados;
Banco de dados descentralizados;
Banco de dados distribuídos;
Banco de dados replicados;
Banco de dados paralelos;
Destacamos as principais vantagens e desvantagens das arquiteturas citadas.
Deixamos o módulo 13 para apresentar de forma bem mais detalhada a
arquitetura de banco de dados cliente/servidor, principalmente pela sua
importância e pela sua maior utilização pelas empresas. Destacamos a
abordagem cliente servidor duas camadas e três camadas e as vantagens e
desvantagens na utilização dessa arquitetura.
O módulo 14 inicia as abordagens sobre o gerenciamento dos dados e dos
bancos de dados. Destacamos os seguintes pontos:




As vantagens em se administrar os dados;
O gerenciamento operacional dos dados;
Gerenciamento de dados externos;
Gerenciamento de dados em ambientes descentralizados.
Falamos também dos usuários que de alguma forma utilizam os bancos de
dados. Dentre eles temos:



Administrador de banco de dados – DBA;
Projetista de banco de dados;
Os usuários finais.
As responsabilidades que devem ser seguidas na administração dos dados e
dos bancos de dados são destacadas no módulo 15. É falado sobre o papel
importante que deve ser desempenhado pelo analista de dados e suas
responsabilidades na coordenação dos dados. Outras responsabilidades de
destaque são:
Planejamento dos dados;
Padronização dos dados;
Treinamento de outros profissionais;
Monitoramento do SGBD;
Detecção e correção de erros;
Manutenção do SGBD.
A segurança dos dados é falada no módulo 16, comparando os dados com os
diferentes recursos corporativos existentes e a importância que deve ser dada
a cada um. É falado sobre as principais brechas que são encontradas em
alguns sistemas que utilizam banco de dados, em que destacamos as
seguintes:






Acesso não autorizado aos dados;
Modificação dos dados sem autorização;
Danos acidentais aos dados;
Acesso não autorizado a computadores;
Interceptação de dados;
Roubo de mídias, e computadores;
Também é dado ênfase nesse capítulo as medidas de segurança que devem
ser tomadas para prevenir essas brechas existentes nos sistemas.
O módulo 17 continua o assunto sobre segurança, só que agora abordando um
assunto importante que são as cópias de segurança e a recuperação dos
dados. Falamos nesse módulo sobre a importância na realização de cópias de
segurança dos dados e os logs das transações realizadas pelo SGBD. Com a
cópia de segurança, é possível recuperar dados que foram perdidos
acidentalmente ou corrompidos em uma operação falha.
Para finalizar, o módulo 18 é responsável por destacar a importância dos
bancos de dados para a internet, a sua utilização e a comparação entre os
bancos que são utilizados na internet e os bancos que não utilizam recursos
web.