Criar um Site Grátis Fantástico
ONLINE
1


 

Evolução dos Bancos de Dados e SGBDs

Introdução

Igualmente a muitas tecnologias na computação industrial, os fundamentos de bancos de dados relacionais surgiram na empresa IBM, nas décadas de 1960 e 1970, através de pesquisas de funções de automação de escritório. Foi durante um período da história na qual empresas descobriram que estava muito custoso empregar um número grande de pessoas para fazer trabalhos como armazenar e indexar (organizar) arquivos. Por este motivo, valia a pena os esforços e investimentos em pesquisar um meio mais barato e ter uma solução mecânica eficiente.

Muitas pesquisas foram conduzidas durante este período, cujos modelo hierárquicos, de rede e relacionais e outros modelos foram descobertos, bem como muita tecnologia utilizada hoje em dia.

Em 1970 um pesquisador da IBM – Ted Codd – publicou o primeiro artigo sobre bancos de dados relacionais. Este artigo tratava sobre o uso de cálculo e álgebra relacional para permitir que usuários não técnicos armazenassem e recuperassem grande grantidade de informações. Codd visionava um sistema onde o usuário seria capaz de acessar as informações através de comandos em inglês, onde as informações estariam armazenadas em tabelas.

Devido à natureza técnica deste artigo e a relativa complicação matemática, o significado e proposição do artigo não foram prontamente realizados. Entretando ele levou a IBM a montar um grupo de pesquisa conhecido como System R (Sistema R).

O projeto do Sistema R era criar um sistema de banco de dados relacional o qual eventualmente se tornaria um produto. Os primeiros protótipos foram utilizados por muitas organizações, tais como MIT Sloan School of Management (uma escola renomada de negócios norte-americana). Novas versões foram testadas com empresas aviação para rastreamento do manufaturamento de estoque.

Eventualmente o Sistema R evoluiu para SQL/DS, o qual posterioemente tornou-se o DB2. A linguagem criada pelo grupo do Sistema R foi a Structured Query Language (SQL) – Linguagem de Consulta Estruturada). Esta linguagem tornou-se um padrão na indústria para bancos de dados relacionais e hoje em dia é um padrão ISO (International Organization for Standardization). A ISO é a Organização Internacional de Padronização.


ATRIBUTOS/RELACIONAMENTO/MODELO LOGICO
ATRIBUTOS/RELACIONAMENTO/MODELO LOGICO

 

Atributos[editar]

Quanto ao tipo, podem ser classificados como:

  • Descritivos: representam as características intrínsecas dos objetos;
  • Nominativos: além de cumprirem a função de descritivos servem como definidores de nomes ou rótulos de identificação dos objetos (nome, código, número, sigla, etc);
  • Referenciais: representam uma citação ou ligação do objeto em questão com outro objeto, não propriamente definindo uma característica do objeto mas explicitando um relacionamento existente1 .
Ex: Cidade de nascimento, Nome do fabricante do carro, Local de trabalho, etc.

Relacionamentos

Na descrição de um relacionamento devem aparecer:

  • Sua função;
  • O que ele representa;
  • Quais as regras de seu estabelecimento;
  • Quais as exceções a seu estabelecimento;
  • Quando ocorre;
  • Quando pode deixar de existir.

Modelo Lógico de Dados

Um modelo lógico de dados para uso meramente operacional/transacional deve:

  • Ser completamente normalizado;
  • Representar fielmente o NEGÓCIO, e NÃO necessariamente a base de dados desejada, a qual será construída posteriormente por ocasião do Projeto Físico;
  • Conter descrição sucinta das entidades, atributos e relacionamentos;
  • Conter os nomes de entidades e atributos, extensos e abreviados, atribuídos de acordo com algum padrão adotado na organização e formados por termos previamente convencionados em um glossário;
  • Contemplar, para cada um dos atributos, o tipo de dado, tamanho e opcionalidade.

Recomendações

Um Modelo Lógico de Dados para uso meramente operacional/transacional não deve conter:

  • Replicações de atributos: fisicamente pode ser interessante alguma redundância com o objetivo de melhorar a performance de determinado(s) processo(s). No modelo lógico isso não pode ser feito; um atributo só é representado na Entidade que o pertence.
  • Atributos derivados: pelos mesmos motivos apontados anteriormente, a implementação das tabelas pode requerer o armazenamento de uma informação derivada de outra(s) (valor do saldo por exemplo). Tal tipo de informação não se constitui um atributo do modelo lógico.
  • Atributos repetitivos: o uso de atributos repetidos, como Telefone-1 e Telefone-2, não é admitido. Se existe a possibilidade de uma pessoa possuir mais de um telefone, então Telefone deve ser representado como uma entidade, mantendo relacionamento Nx1 com a entidade Pessoa.