MÓDULO 4 – A INTEGRAÇÃO E A REDUNDÂNCIA DOS DADOS

MÓDULO 4 – 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. 4.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. 4.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é 8% 5% 10% 2. Registro de clientes ID_Cliente Nome 010 Carlos José 015 Mário Augusto 017 Ibes Sampaio 003 001 003 Comissão ID_Vendedor 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 003 001 003 ID_Vendedor Nome 003 José 001 Paulo 003 José Comissão 10% 8% 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.