Página 1 de 8

Página 2 de 8

1. Introdução A importância da informação para a tomada de decisões nas organizações tem impulsionado o desenvolvimento dos sistemas de informações, os quais muitas vezes são considerados uma forma de mudança organizacional planejada.

Todos nós sabemos existirem gigantescas bases de dados gerenciando nossas vidas. De fato sabemos que nossa conta bancária faz parte de uma coleção imensa de contas bancárias de nosso banco. Nosso Título Eleitoral ou nosso Cadastro de Pessoa Física, certamente estão armazenados em Bancos de Dados colossais. Sabemos também que quando sacamos dinheiro no Caixa Eletrônico de nosso banco, nosso saldo e as movimentações existentes em nossa conta bancária já estão à nossa disposição.

Nestas situações sabemos que existe uma necessidade em se realizar o armazenamento de uma série de informações que não se encontram efetivamente isoladas umas das outras, ou seja, existe uma ampla gama de dados que se referem a relacionamentos existentes entre as informações a serem manipuladas.

Estes Bancos de Dados, além de manterem todo este volume de dados organizado, também devem permitir atualizações, inclusões e exclusões do volume de dados, sem nunca perder a consistência.

Um Banco de Dados é antes de mais nada uma coleção logicamente coerente de dados com determinada significação intrínseca. Em outras palavras um arquivo contendo uma série de dados de um cliente, um arquivo com dados aleatoriamente gerados e dois arquivos padrão xls (excel) não podem ser considerados um Banco de dados. Um Banco de Dados contém os dados dispostos numa ordem pré-determinada em função de um projeto de sistema, sempre para um propósito muito bem definido.

Um Banco de Dados representará sempre aspectos do Mundo Real. Assim sendo uma Base de Dados (ou Banco de Dados, ou ainda BD) é uma fonte de onde poderemos extrair uma vasta gama de informações derivadas, que possui um nível de interação com eventos como o Mundo Real que representa.

Existe uma tendência de mercado em se dizer que qualquer problema será resolvido, caso a empresa adquira um Banco de Dados. Naturalmente, em um ambiente com acesso constante ao Banco de Dados (acesso concorrente, obviamente), onde a segurança seja de vital importância e que o desempenho da aplicação escrita estiver comprometendo a empresa, considerando-se logicamente uma aplicação bem escrita, sem dúvida a aquisição de um Banco de Dados poderá ser o primeiro passo na solução do problema.

É conveniente, sob pena de se realizar um grande investimento e não se colher fruto algum, que a empresa antes de adquirir um Banco de Dados, passe por um processo de entendimento dos processos de negócio e dos dados envolvidos. A compreensão do modelo de negócio da empresa é fundamental para o sucesso de um Banco de dados. A busca pela compreensão do negócio passa pela identificação das informações que são relevantes para a gestão. A essência da modelagem de dados reside em transformar esse universo infinito de informações em um universo finito e relacionado de dados. Um modelo de dados é uma técnica utilizada para mapear o mundo real em um modelo gráfico que irá representar o relacionamento existente entre os dados.

O principal objetivo dessa disciplina é apresentar essa técnica que, a partir da compreensão do negócio e das informações que suportam o mesmo, permite identificar os dados necessários e o relacionamento entre eles.

Não se faz modelo de dados sem se conhecer profundamente o negócio, suas definições e conceitos mais fundamentais. E quem conhece o negócio são os gestores e não os profissionais de TI. Paralelamente, não se modela corretamente um negócio sem a técnica de modelagem de dados.

Página 3 de 8

2. Conceitos

2.1 Banco de Dados É uma coleção de dados inter-relacionados, representando informações sobre um domínio específico.

Exemplos: lista telefônica, controle de acervo de uma biblioteca.

2.2 Sistema Gerenciador de Banco de Dados (SGBD) É um software com recursos específicos para facilitar a manipulação das informações dos bancos de dados e o desenvolvimento de programas aplicativos. O componente responsável pelo armazenamento das informações é o Banco de Dados. Enfim, é um conjunto de dados inter-relacionados (armazenamento) + um conjunto de programas para acessá-los (busca e manipulação).

Exemplos: Access, Oracle, DB2, Ingress, SQL Server.

O principal objetivo de um SGBD é prover um ambiente adequado e eficiente para recuperar e armazenar dados, com capacidade de gerenciar grandes volumes e grupos de dados.

3. Características

3.1 Controle de Redundância No processamento tradicional de arquivos, cada grupo de usuários deve manter seu próprio conjunto de arquivos e dados. Desta forma, acaba ocorrendo redundâncias que prejudicam o sistema com problemas como:

Toda vez que for necessário atualizar um arquivo de um grupo, então todos os grupos devem ser atualizados para manter a integridade dos dados no ambiente como um todo;

A redundância desnecessária de dados levam ao armazenamento excessivo de informações, ocupando espaço que poderia estar sendo utilizado com outras informações.

A redundância consiste no armazenamento de uma mesma informação em locais diferentes, provocando inconsistências. Em um Banco de Dados as informações só se encontram armazenadas em um único local, não existindo duplicação descontrolada dos dados, possibilitando a eliminação dos dados “privativos” de cada sistema. Os dados, que eventualmente são comuns a mais de um sistema, são compartilhados por eles, permitindo o acesso a uma única informação sendo consultada por vários sistemas. Quando existem replicações dos dados, estas são decorrentes do processo de armazenagem típica do ambiente Cliente-Servidor, totalmente sob controle do Banco de Dados.

3.2 Eliminação de Inconsistências Através do armazenamento da informação em um único local com acesso descentralizado e, sendo compartilhada à vários sistemas, os usuários estarão utilizando uma informação confiável. A inconsistência ocorre quando um mesmo campo tem valores diferentes em sistemas diferentes. Exemplo, o estado civil de uma pessoa é solteiro em um sistema e casado em outro. Isto ocorre porque esta pessoa atualizou o campo em um sistema e não o atualizou em outro. Quando o dado é armazenado em um único local e compartilhado pelos sistemas, este problema não ocorre.

Página 4 de 8

3.3 Controle de Integridade Um Banco de Dados deverá impedir que aplicações ou acessos pelas interfaces possam comprometer a integridade dos dados.

3.3.1 Integridade Referencial

Consiste em impedir que um determinado código ou chave em uma tabela não tenha correspondência em outra tabela. Ex. Um código de uma determinada disciplina na tabela “Histórico Escolar” sem a sua descrição na tabela “Disciplina”.

3.3.2 Integridade de Domínio

Permite que os campos armazenados na base de dados sejam padronizados segundo um determinado formato de armazenamento (padronização de tabela, conteúdo de compôs, etc) e ao nome de variáveis seguindo critérios padrões preestabelecidos pela empresa. Ex. Para o campo "Sexo" somente será permitido armazenamento dos conteúdos "M" ou "F".

3.4 Indexação Chamaremos de Chave Primária ao Atributo que definir um registro, dentre uma coleção de registros. Chave Secundária (Terciária, etc), serão chaves que possibilitarão pesquisas ou ordenações alternativas, ou seja, diferentes da ordem criada a partir da chave primária ou da ordenação natural (física) da tabela.

Vamos supor o arquivo abaixo ordenado fisicamente pela chave primária (#). Para acessarmos o registro da cor “preto” diretamente, sem precisar ler todos os registros anteriores, criam-se as chaves secundárias (terciárias ...), conhecidas como ponteiros (*).

ARQUIVO PONTEIROS #1- Amarelo #1 *1 #2- Branco #2 *3 #3- Verde #3 *5 #4- Preto #4 *4 #5- Azul #5 *2 #6- Vermelho #6 *6

Supondo desejarmos incluir a cor Laranja, se o arquivo estive ordenado em ordem alfabética, seríamos obrigado a re-escrever todo o arquivo. Ao incluir um novo registro (ex.Laranja) ele será gravado fisicamente como o último registro na tabela e somente serão atualizados os ponteiros:

ARQUIVO PONTEIROS #1- Amarelo #1 *1 #2- Branco #2 *3 #3- Verde #3 *6 ATUALIZADO #4- Preto #4 *5 ATUALIZADO #5- Azul #5 *2 #6- Vermelho #6 *7 ATUALIZADO #7- Laranja #7 *4 NOVO

3.5 Detecções de Falhas Um SGBD deve fornecer recursos para recuperação de falhas de software e hardware, que podem ser causadas por problemas não só no próprio hardware ou software como também problemas de, por exemplo, falta de energia.

Página 5 de 8

Em caso de falha, o estado do sistema de banco de dados pode não ser mais consistente, isto é, ele pode não mais refletir o estado do mundo que se supõe representado no banco de dados. Para preservar a consistência, exigimos que cada transação seja atômica. É responsabilidade do esquema de recuperação assegurar a propriedade de atomicidade.

3.5.1 Atomicidade

A restauração do BD obedece a propriedade da atomicidade, na qual ou todas as operações da transação são refletidas corretamente no banco de dados ou nenhuma o será

Uma transação é uma unidade de execução de programa que acessa e, possivelmente, atualiza vários itens de dados. Uma transação, geralmente, é o resultado da execução de um programa de usuário, e é delimitada por declarações (ou chamadas de função) da forma begin transaction e end transaction. A transação consiste em todas as operações ali executadas, entre o começo e o fim da transação.

A ideia básica por trás da garantia da atomicidade é a seguinte. O sistema de banco de dados mantém um registro (em disco) dos antigos valores de quaisquer dados sobre os quais a transação executa uma gravação e, se a transação não se completar, os valores antigos sãos restabelecidos para fazer com que pareça que ela nunca foi executada. Assegurar a atomicidade é responsabilidade do próprio sistema de banco de dados, mais especificamente ela é tratada por um componente chamado de componente de gerenciamento de transações.

Há basicamente dois diferentes esquemas para garantir a atomicidade.

Baseado em log – todas as atualizações são escritas no log, que deve ser mantido em armazenamento estável. Se uma queda ocorrer, as informações do log são usadas na restauração do estado do sistema para o último estado consistente;

Paginação Shadow – Duas tabelas de página são mantidas durante a vida de uma transação: a tabela de páginas atuais e a tabela de páginas shadow. Quando a transação inicia, ambas as tabelas de páginas são idênticas. A tabela de páginas shadow nunca é alterada durante a exclusão da transação. Quando a transação é parcialmente efetivada, a tabela de páginas shadow é descartada e a tabela corrente torna-se a nova tabela de páginas. Se a transação for abortada, a tabela de páginas atuais é simplesmente descartada.

Desta forma exige-se que o banco de dados tenha ao menos uma instrução que permita a gravação de uma série modificações simultâneas e uma instrução capaz de cancelar um série modificações. Por exemplo, imaginemos que estejamos cadastrando um pedido para um cliente, que este deseje reservar 5 itens de nosso estoque, que estão disponíveis e portanto são reservados, porém existe um bloqueio financeiro (duplicatas em atraso) que impede a venda. A transação deverá ser desfeita com apenas uma instrução ao Banco de Dados, sem qualquer modificações suplementares nos dados. Caso você se obrigue a corrigir as reservas, através de acessos complementares, você não está lidando com um SGBD.

3.5.2 Backups

São arquivos de "pré-imagem" ou de outros recursos automáticos, os quais são utilizados para recuperar falhas de hardware e software exigindo minimamente a intervenção de pessoal técnico.

Página 6 de 8

3.6 Controle de Concorrência O SGBD deve incluir software de controle de concorrência ao acesso dos dados, garantindo em qualquer tipo de situação a escrita/leitura de dados sem erros Um SGBD multi-usuário deve permitir que múltiplos usuários acessem o banco de dados ao mesmo tempo. Este fator é essencial para que múltiplas aplicações integradas possam acessar o banco, uma vez que quando diversas transações concorrentes são executadas, suas operações podem ser intercaladas de modo inconveniente, resultando em um estado inconsistente.

O SGBD multi-usuário deve manter o controle de concorrência para assegurar que o resultado de atualizações sejam corretos. Como os aplicativos de um SGBD são por natureza multiusuário, o controle de concorrência é o que permite a utilização simultânea e segura de um dado, por mais de uma aplicação ou usuário, independente da operação que esteja sendo realizada, evitando erros de processamento (atualizar simultaneamente o mesmo campo do mesmo registro).

3.6.1 Propriedade de Isolamento

A propriedade de isolamento de uma transação garante que a execução simultânea de transações resulte em uma situação no sistema equivalente ao estado obtido caso as transações tivessem sido executadas uma de cada vez, em qualquer ordem. Assegurar a propriedade de isolamento é responsabilidade de um componente do sistema de banco de dados chamado componente de controle de concorrência. Quando várias transações são executadas de modo concorrente no banco de dados, a consistência dos dados não pode mais ser garantida. Então, é necessário que o sistema controle a interação entre as transações concorrentes. Como uma transação é uma unidade que preserva a consistência, uma execução sequencial das transações garante a preservação da consistência. Portanto, exigimos que qualquer escala produzida pelo processamento concorrente de um conjunto de transações tenha um efeito equivalente a uma escala produzida quando essas transações são executadas sequencialmente em alguma ordem. Do sistema que garante essa propriedade diz-se que ele garante a serialização. Há várias noções diferentes de equivalência que conduzem aos conceitos de serialização de conflito e serialização de visão.

A serialização das escalas geradas por transações concorrentes pode ser garantida por meio de um entre vários mecanismos chamados de esquemas de controle de concorrência. O componente de gerenciamento de controle de concorrência do banco de dados é o responsável pela manipulação dos esquemas de controle da concorrência.

3.6.2 Bloqueio

O protocolo de bloqueio é um conjunto de regras que estabelecem quando uma transação pode bloquear e desbloquear cada um dos itens de dados do banco de dados. O protocolo do bloqueio em duas fases permite que uma transação bloqueie um novo item de dado somente até desbloquear o primeiro deles. O protocolo garante a serialização, mas não está livre de deadlocks. Na ausência de informações a respeito do tipo de acesso que será feito no item de dados, o protocolo de bloqueio em duas fases é tanto necessário quanto suficiente para garantia da serialização.

O esquema da ordenação por timestamp garante a serialização pela seleção da ordem de execução entre pares de transações. Um único timestamp é associado a cada transação no sistema. Os timestamps das transações determinam a ordem de serialização. Assim, se o timestamp da transação T1 é menor que o da transação T2, o esquema garante que a escala de execução produzida seja equivalente a uma escala serializada na qual a transação T1 aparece antes da transação T2. Isso é feito revertendo a transação sempre que a ordem for violada.

Página 7 de 8

Vários protocolos de bloqueio não são resistentes a deadlocks, o abraço mortal. Esta situação indesejável pode ocorrer toda vez que um usuário travou um registro em uma tabela e seu próximo passo será travar um resgistro em uma tabela relacionada à primeira, porém se este registro estiver previamente travado por outro usuário, o primeiro usuário ficará paralisado, pois, estará esperando o segundo usuário liberar o registro em uso, para que então possa travá-lo e prosseguir sua tarefa. Se por hipótese o segundo usuário necessitar travar o registro travado pelo primeiro usuário (!), afirmamos que ocorreu um abraço mortal, pois cada usuário travou um registro e precisa travar um outro, justamente o registro anteriormente travado pelo outro! Imaginemos um caso onde o responsável pelos pedidos acabou de travar o Registro Item de Pedido, e, necessita travar um registro no Cadastro de Produtos, para indicar uma nova reserva. Se concomitantemente estiver sendo realizada uma tarefa de atualização de pendências na Tabela de Itens, e para tanto, previamente este segundo usuário travou a Tabela de Produtos, temos a ocorrência do abraço mortal.

Um modo de evitar deadlocks é usando a preempção e o rollback de transações. Para controla a preempção, marcamos um único timestamp para cada transação. Esses timestamps são usados para decidir se uma transação deverá ser revertida ou deverá esperar. Se uma transação é revertida, ela mantém o timestamp antigo quando reiniciada. Os esquemas de esperar-morrer e de ferir-esperar são dois esquemas com base em preempção. Outro método para o tratamento de deadlocks é usar o esquema de detecção de deadlock e recuperação. Para fazê-lo, é construído um gráfico de espera. Um sistema está em estado de deadlock se, e somente se, o gráfico de espera contém um ciclo. Quando o algoritmo de detecção identifica um deadlock, o sistema precisa recuperar-se. Isso é feito revertendo uma ou mais transações para quebra do deadlock.

3.7 Segurança O principal objetivo é garantir que não ocorram acessos não autorizados visando destruição, alteração ou introdução de inconsistências dos dados.

3.7.1 Restrição de Acesso

Um SGBD deve fornecer um subsistema de autorização e segurança, o qual é utilizado para criar “contas” e especificar as restrições destas contas; o controle de restrições se aplica tanto ao acesso aos dados quanto ao uso de softwares inerentes ao SGBD, definindo para cada usuário o nível de acesso a ele concedido (leitura, leitura e gravação ou sem acesso) ao arquivo, formulário e/ou campo. Este recurso impede que pessoas não autorizadas utilizem ou atualizem um determinado arquivo ou campo.

As restrições de Acesso possibilitam selecionar a autoridade de cada usuário. Assim um usuário poderá realizar qualquer tipo de acesso, outros poderão ler alguns dados e atualizar outros e outros ainda poderão somente acessar um conjunto restrito de dados para escrita e leitura.

As restrições de acesso são normalmente controladas pela atribuição de senhas aos usuários finais.

3.7.2 Visões

Um SGBD deve permitir que cada usuário visualize os dados de forma diferente daquela existente previamente no Banco de Dados. Uma visão consiste de um subconjunto de dados do Banco de Dados, necessariamente derivados dos existentes no Banco de Dados, mas que são filtrados de acordo com níveis de autorização de cada usuário, normalmente associados a sua hierarquia no organograma da empresa.

Página 8 de 8

3.7.3 Criptografia

Através do uso de um algoritmo (sequencia de passos para o embaralhamento), dos dados a serem protegidos e de uma chave (conjunto de bits), transforma-se textos ou dados abertos em códigos ilegíveis. A chave existe para embaralhar o texto e, através do conhecimento dela, conseguir recuperar o texto original. Isso é Criptografia no mundo computacional, e isso era Criptografia há mil anos.

Existe a possibilidade de encontramos Bancos de Dados que não satisfaçam completamente todas as características acima, o que não a inválida como Banco de Dados. Na prática podemos encontrar situações onde a primeira característica não seja importante, pois podemos ter o Banco de Dados baseado totalmente em um único servidor, e as redundâncias podem ser aceitas em algumas situações sob controle da aplicação (algo não muito recomendado, mas passível de aceitação, em situações onde a existência do nome do cliente em um arquivo contendo duplicatas emitidas, possibilita o acesso a apenas uma tabela sem relacionamentos, e sabe-se de antemão que uma duplicata depois de emitida, não pode ter seu cliente alterado).

O Controle de Integridade, é outra característica sempre presente nos Bancos de Dados, mas existem diferenças quando da implementação desta característica. Assim, é comum encontrarmos Bancos de Dados que suportam determinado acesso, enquanto outros não dispõem de recurso equivalente.

O Backup em tempo de execução é outra característica sempre disponível, porém temos aplicações que invariavelmente são comprometidas por falhas de hardware, e outras, que o mesmo tipo de falha não causa perda alguma de dados ou de integridade. Novamente, cada Banco de Dados tem esta característica melhor ou pior implementada, cabendo ao Administrador de Banco de Dados escolherem aquele que lhe oferecer mais segurança.

A escolha e implementação do Banco de Dados da empresa, portanto é uma decisão muito delicada, na medida em que está irá acarretar troca de aplicativos e troca de hardware. Os investimentos diretamente aplicados no Banco de Dados, costumam ser infinitamente menores do que aqueles a serem aplicados na empresa, visando sua perfeita adequação ao novo SGBD.