Capítulo 1 – Banco de Dados

A história dos bancos de dados

Antigamente as empresas armazenavam informações em fichas de papel que eram organizadas em arquivos físicos através de pastas. Extrair informações e manter esses arquivos organizado era uma tarefa que exigia um esforço (e custo) maior. Além disso o acesso à informação dependia da localização geográfica dos arquivos. Pouco tempo depois, esses arquivos físicos evoluíram para arquivos digitais. No início, cada entidade (clientes, funcionários, produtos, etc) era um arquivo de dados que eram acompanhados de um “software simples” para manipular os dados do arquivo, que permitiam realizer operações de cadastro, alteração, exclusão e consulta nos arquivos digitais. Essa metodologia conseguiu facilitar a função de consulta de dados, mas ainda tinha problemas de organização como de um arquivo físico.

O “software simples” era um tipo de software conhecido como CRUD (Create, Read, Update e Delete), que realizava operações básicas como cadastro, consulta, atualização e exclusão de registros de um arquivo digital, manipulando uma única entidade.

As entidades precisavam relacionar-se (por exemplo, um produto é fornecido por um fornecedor) e os “softwares simples” para manipular os arquivos digitais começaram a ficar “complexos” para permitir os relacionamentos entre entidades. Então, na década de 60 a empresa IBM investiu fortemente em pesquisas para solucionar estes problemas dos bancos de dados digitais primitivos. Vários modelos de bancos de dados surgiram nesta época, dentre eles os modelos hierárquico e rede.

Em junho de 1970, o pesquisador Edgar Frank “Ted” Codd da IBM, mudou a história dos bancos de dados apresentando o modelo relacional no artigo intitulado “A Relational Model of Data for Large Shared Data Banks”, onde o autor apresentou uma forma de usuários sem conhecimento técnico armazenarem e extraírem grandes quantidades de informações de um banco de dados. Esse artigo foi o grande impulso para a evolução dos bancos de dados, a partir do artigo de “Ted” Codd que os cientistas aprofundaram a ideia de criar o modelo de banco de dados relacional.

Banco de dados relacional

Apesar de ter sido o marco dos bancos de dados relacionais, o artigo de Codd não foi muito explorado no início. Só no final da década de 70 que foi desenvolvido um sistema baseado nas idéias do cientista, o “Sistema R”. Junto com esse sistema, foi criado a Linguagem de Consulta Estruturada (SQL – Structured Query Language) que se tornou a linguagem padrão para bancos de dados relacionais. Embora tenha contribuído para a evolução dos bancos de dados relacionais, o “System R” não foi muito bem sucedido comercialmente, mesmo servindo de base para os sistemas de banco de dados seguintes.

Nos anos 80 surgiram outros bancos de dados, a Oracle apresentou o Oracle 2 e a IBM o SQL/DS (que se tornou DB2), ambos sistemas comerciais de bancos de dados. Na sequência vieram SQL Server, MySQL, DBase III, Paradox, etc.

Bancos de dados hoje

Atualmente existem vários modelos de bancos de dados tais como orientado a objetos, orientado a documentos, etc. Mas o mais comum ainda é o banco de dados relacional. A decisão entre qual modelo de banco de dados utilizar baseia-se no tipo de dados que você pretende armazenar. Por exemplo, se você for armazenar uma grande quantidade de dados em um modelo pequeno é mais indicado utilizar um banco de dados orientado a documentos a um banco de dados relacional. A decisão de projeto vai de acordo com o tipo do dado que se deseja armazenar, não há uma questão de superioridade entre os modelos.

Capítulo 2 – SGBD

Sistema de Gerenciamento de Banco de Dados

São um conjunto de programas que fazem uma gestão autônoma da informação, de acordo com um modelo preestabelecido e adaptado à empresa ou qualquer outro órgão que os utilizem. O SGBD deve fornecer ao usuário uma “representação conceitual” dos dados, sem fornecer muitos detalhes de como as informações são armazenadas. Um “modelo de dados” é uma abstração de dados que é utilizada para fornecer esta representação conceitual utilizando conceitos lógicos como objetos, suas propriedades e seus relacionamentos.

 

Diferença entre Banco de Dados e Sistema Gerenciador de Banco de Dados

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

SGBD é um software com recursos específicos para facilitar o processo de definição, construção, manipulação e o gerenciamento das informações dos bancos de dados e o desenvolvimento de programas aplicativos.

 

232323

 

Capítulo 3 – Principais bancos do mercado

Software livre é uma realidade cada vez mais constante no mundo da informática. Com o inegável sucesso do Linux, a comunidade de informática passou a notar outros nichos que poderiam ser explorados pelo software livre.

Com banco de dados não poderia ser diferente. Com um mercado de sistemas pagos bastante consolidado, incluindo gigantes como IBM, Microsoft e Oracle, os bancos de dados livres começam a mostrar sua força. O fato é que, como aconteceu com o Linux, o banco de dados relacional está se tornando uma commodity, seja pelo aumento de bons produtos no mercado, seja pela concorrência dos softwares livres.

Inicialmente é necessário diferenciar o uso que se fará do banco de dados. Já há algum tempo os bancos de dados deixaram de ser simples armazenadores de informações. Hoje em dia, pelo menos para os principais produtos do mercado, há uma vasta gama de serviços agregados a eles. Estruturas de dados cada vez mais complexas estão sendo geridas e armazenadas pelos bancos de dados para atender necessidades específicas, em especial para internet.

Alguns fatores influenciam na escolha de um banco de dados:

  1. Controle de redundância: o banco de dados deve ser capaz de garantir que os dados não tenham duplicidade. Isso normalmente é conhecido como integridade referencial.
  2. Compartilhamento de dados:a informação deve estar disponível para qualquer número de usuários de maneira rápida, concomitante e segura. É impensável, nos dias atuais, imaginar um banco de dados exclusivo para um usuário. A informação, cada vez mais, deve ser compartilhada por diversas pessoas da empresa. Disponibilizar a informação com rapidez e segurança é requisito fundamental para determinar a escolha do banco de dados.
  3. Controle de acesso:é essencial saber quem fez e o que cada usuário pode fazer dentro do banco de dados.
  4. Cópias de Segurança:deve haver rotinas específicas para realizar cópias de segurança dos dados armazenados.
  5. Recuperação:falhas acontecem. O que fazer quando houver uma quebra total do banco de dados? Qual o caminho para recuperação deste desastre? Claro que um bom backup pode resolver boa parte dos problemas, mas o que, além disso, o banco de dados poderá fazer? Mecanismos de backup online e em diversos servidores e clusters, entre outros, são ferramentas importantes quando um problema acontece.
  6. Desempenho:de nada adianta ter um banco de dados completo se este for lento para as necessidades da empresa.
  7. Escalabilidade:é necessário saber os limites do banco de dados. Convém, principalmente para os bancos de dados livres, considerar o tamanho máximo do banco de dados e o número máximo de linhas em cada tabela.

Algumas opções do mercado de banco de dados livre

O mais popular banco de dados livre do mercado é o MySQL (www.mysql.com). Milhares de sites na internet são mantidos neste banco de dados. Simples e poderoso, o MySQL é um sucesso inegável para empresas de diversos portes.

Outro grande concorrente dos bancos de dados livres é o PostgreSQL (www.postgresql.com). Também pode ser obtido da internet e é totalmente grátis.

O terceiro dos bancos de dados livres a considerar para implantação é o Firebird (www.firebirdsql.com). Também está disponível em diversas plataformas, como Linux, Windows, Solaris, HP-UX, Mac, dentre outros. É possível adquirir uma versão gratuita no site e é considerado bastante estável.

O custo de um banco de dados é significativo para qualquer empresa e a qualidade do software livre não deixa a desejar. Se o banco de dados relacional virará uma commodity ainda não é possível precisar. Hoje em dia, como poucas empresas possuem produtos de peso para competir, os preços ainda são muito semelhantes. Quem necessita de bancos de dados para toda a organização dificilmente utilizará um dos bancos de dados livres. Contudo, empresas menores poderão fazê-lo sem grandes problemas.

Algumas aplicações de mercado de banco de dados

  1. Banco de dados caseiros: aplicações simples, como o de Encomendas para Festas;
  2. Banco de dados comerciais:armazena todas as informações relativas ao negócio, como Fornecedores, Clientes, Empregados, etc;
  3. Banco de dados de engenharia:armazenam informações sobre projetos de engenharia, como o CAD;
  4. Banco de dados multimídia:armazenam imagens, áudios, vídeos;
  5. Banco de dados geográficos: armazenam combinações de dados espaciais e não espaciais.

 

 

Capítulo 4 – Conceito de Banco de Dados

Um banco de dados é uma coleção de dados organizada de forma que um computador possa armazená-los e recuperá-los de maneira eficiente. É um repositório de dados logicamente relacionados.

Um banco de dados é criado e mantido através de um software de propósito geral, o Sistema Gerenciador de Banco de Dados (SGBD).

Para que possam ser úteis, bancos de dados devem oferecer:

  • Confiabilidade,
  • Integridade,
  • Segurança ,
  • Visões (consultas),
  • Interface,
  • Independência de dados,
  • Concorrência,
  • Capacidade de rodar de forma distribuída e
  • Alta performance

Todas essas funções são executadas pelos SGBD.

Tabelas (Entidades)

É uma estrutura de linhas e colunas, semelhante a uma planilha eletrônica. Em uma tabela cada linha contém um mesmo número de colunas. Um banco de dados é composto de várias tabelas, cada tabela representando uma entidade em particular.

Campos (Colunas)

Cada coluna representa um espaço para armazenamento de um determinado dado de um registro em particular.

Registros (Tuplas)

Cada linha formada por uma lista ordenada de colunas representa  um registro, ou tupla. Um registro é um elemento, instância de uma tabela.

Pag 11 1

Capítulo 5 – Regras e Tipos de Relacionamentos

Os relacionamentos são responsáveis por definir uma ligação entre dois objetos pertencentes ao mundo real. Quando trabalhamos com aplicações construídas e administradas por um SGBD (Sistema Gerenciador de Banco de Dados), o relacionamento é o responsável por unir duas ou mais tabelas de banco de dados.

Tipos de Relacionamentos

1:1

No relacionamento 1:1 (um-para-um), cada um dos elementos de uma determinada entidade possui relacionamento com apenas um dos elementos de outra entidade.

1:N

No relacionamento 1:N (um-para-muitos), vamos imaginar duas entidades, as quais serão chamadas A e B. Neste relacionamento cada elemento da entidade A pode ter um relacionamento com vários elementos da entidade B. Entretanto, cada um dos elementos da entidade B pode estar relacionado a apenas um elemento da entidade A. No geral, este é tipo de relacionamento mais comum e mais usado pelas aplicações.

N:N

O relacionamento N:N (muitos-para-muitos) possui uma característica diferente dos outros. Neste caso, os dados estão diretamente relacionados ao fato, e não as entidades, como observamos nos outros tipos de relacionamentos vistos anteriormente.

Importante destacar que podem não haver associação de fatos nas situações em que os relacionamentos são de caráter condicional. Neste caso, a cardinalidade deve ser determinada por meio de uma ampla análise quanto à possibilidade de ocorrerem relacionamentos.

Regras de Relacionamentos

1:1

Lembrando que neste relacionamento, cada um dos elementos de uma entidade só pode se relacionar com apenas um elemento de outra entidade. Então, consideremos as tabelas Clientes e Documentos, em que cada um dos clientes pode ter apenas um documento (considerando que nesta tabela um mesmo cliente não pode ter mais de um documento), assim como cada um dos documentos só pode pertencer a apenas um cliente.

Confira nas imagens abaixo a criação das tabelas, das constraints e inserção de alguns registros:

Pag 13 1

Pag 14 1

 

Perceba que na tabela Documentos criei uma Foreign Key (chave estrangeira) se relacionando com a Primary Key da tabela Clientes. Veja como ficarão as tabelas:

Pag 14 2

 

1:N

Para que seja estabelecido um relacionamento de 1:N (um-para-muitos), temos que contar com duas tabelas, onde a primeira (1) obrigatoriamente terá uma coluna que use uma Primary Key (Chave Primária). Já na tabela que representa o relacionamento para muitos (N), deverá haver uma coluna referente à primeira tabela, a qual deve utilizar a Foreign Key (Chave Estrangeira) para que, assim, seja estabelecido o relacionamento entre ambas as tabelas.

Apenas salientando: diferente da Primary Key, colunas que usam a Foreign Key aceitam a inserção de valores repetidos.

Exemplo: Confira nas imagens a seguir a criação da tabela Telefones, com suas constraints, a inserção de alguns registros e o resultado da consulta a ela.

Pag 15 1

Pag 15 2

Pag 15 3

 

N:N

Para estabelecer este tipo de relacionamento, devemos ter três tabelas, sendo que a terceira é responsável por relacionar as outras duas. Para isso, é preciso que essas duas primeiras tabelas contenham uma coluna que seja chave primária.

 As colunas que são chaves primárias na primeira e na segunda tabela devem ser colunas com chave estrangeira na terceira. Assim, esta tabela terá duas chaves estrangeiras, as quais formam uma chave primária composta.

Diagrama de relacionamento

       Relacionamento 1:N

Pag 16 1

Relacionamento 1:N e 1:1

Pag 16 2 

Relacionamento 1:N com várias chaves primárias

Pag 16 3