BANCOS DE DADOS

O QUE É BANCO DE DADOS?

 É um conjunto de informações armazenadas de forma organizada. No tradicional

sistema manual, as informações geralmente são armazenadas em arquivos de papéis.
Para recuperar as informações armazenadas, algum tipo de procura manual é
necessária. Já nos sistemas de armazenamento digitalizados, os dados são
armazenados em fitas magnéticas ou discos rígidos e o acesso aos dados é feito
através de softwares de computador.

 Por que utilizar sistemas de computadores para armazenar informações em Banco de

Dados?

 Muitas vantagens surgem com a utilização de sistemas de informações baseados em

computadores como:

Recuperação e atualização das informações;

 Armazenamento das informações em menor espaço do que no sistema manual;
 Vários usuários podem compartilhar o mesmo dado e utilizá-lo para diferentes
tarefas;
 Controle de redundância das informações;
 Incompatibilidade de dados podem ser previstos;
 Forçar utilização de padronizações;
 Controle de acesso e integridade (segurança).

MODELO RELACIONAL

O modelo relacional foi criado por Codd em 1970 e tem por finalidade representar os
dados como uma coleção de relações, onde cada relação é representada por uma tabela,
ou falando de uma forma mais direta, um arquivo. Porém, um arquivo é mais restrito que
uma tabela. Toda tabela pode ser considerada um arquivo, porém, nem todo arquivo pode
ser considerado uma tabela.

Para os usuários, o Banco de Dados -> Relacional é uma coleção de tabelas bi-
dimensionais as quais são de fácil compreensão. Existem quatro conceitos que
precisamos entender:
 Tabelas
 Colunas
 Linhas
 Campos
Computadores são particularmente adequados para o armazenamento e manipulação de
dados e permitem classificar e recuperar com rapidez e eficiência grandes volumes de
dados.

Bancos de dados são depósitos de conjuntos de dados relacionados.

Linguagem de Programação Profª Leny Cerqueira lenny106@gmail.com
Hoje, graças aos microcomputadores, SGBDs são usados tanto por empresas, para
registrar os processos relativos a vendas, contabilidade geral, gerenciamento de
funcionários, quanto em nível doméstico para gerenciar compras, contas, informações
referentes a amigos.

DBMS (SISTEMA DE GERENCIAMENTO DE BANCO DE DADOS)

Para controlar o acesso e armazenamento de informações é necessário a utilização de
um Sistema de Gerenciamento de Banco de Dados (DBMS). Um DBMS é um software
que gerencia os pedidos dos usuários para acesso às informações, um DBMS também
controla o armazenamento, a recuperação e a modificação dos dados de interesse dos
usuários

Há variados SGBDs para microcomputadores, como por exemplo, dBase IV e Paradox

da Borland International; Access e FoxPro da Microsoft; Lotus Approach e FileMaker
Pro da Claris..

O DBMS atua como “interface” entre o armazenamento físico dos dados e os

usuários. Quando um usuário efetua um pedido de acesso, o DBMS intercepta
este pedido e executa as operações necessárias no Banco de Dados. Portanto,
o DBMS “protege” os usuários do Banco de Dados dos detalhes técnicos dos
equipamentos, da estrutura de armazenamento e da estratégia de acesso.

Quando um usuário envia uma solicitação ao DBMS, este intercepta a solicitação,

interpreta e realiza as operações necessárias no banco de dados.

Várias alternativas existem para implementar um DBMS. Os tipos mais utilizados são:
 Hierárquico
 Lista invertida
 Rede
 RELACIONAL
 Os vários Bancos de Dados que têm sido desenvolvidos recentemente são
Relacionais.

VANTAGENS E DESVANTAGENS DO USO DE UM SGBD

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;

C. M. Getúlio Vargas Profª Leny Cerqueira 2º ano – Técnico em Informática

 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.

Compartilhamento de Dados

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.

O SGBD multi-usuário deve manter o controle de concorrência para assegurar que o

resultado de atualizações sejam corretos. Um banco de dados multi-usuários deve
fornecer recursos para a construção de múltiplas visões.

Restrição a Acesso não Autorizado

Um SGBD deve fornece um subsistema de autorização e segurança, o qual é utilizado

pelo DBA 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.

Representação de Relacionamentos Complexos entre Dados

Um banco de dados pode incluir uma variedade de dados que estão interrelacionados de
várias formas. Um SGBD deve fornecer recursos para se representar uma grande
variedade de relacionamentos entre os dados, bem como, recuperar e atualizar os dados
de maneira prática e eficiente.

Tolerância a Falhas

Um SGBD deve fornecer recursos para recuperação de falhas tanto de software quanto
de hardware.

Quando não Utilizar um SGBD

Em algumas situações, o uso de um SGBD pode representar uma carga desnecessária
aos custos quando comparado à abordagem processamento tradicional de arquivos
como, por exemplo:

Alto investimento inicial na compra de software e hardware adicionais;

generalidade que um SGBD fornece na definição e processamento de dados;

sobrecarga na provisão de controle de segurança, controle de concorrência,

recuperação e integração de funções.

Problemas adicionais podem surgir caso os projetistas de banco de dados ou os

administradores de banco de dados não elaborem os projetos corretamente ou se as
aplicações não são implementadas de forma apropriada. Se o DBA não administrar o
banco de dados de forma apropriada, tanto a segurança quanto a integridade dos
sistemas podem ser comprometidas. A sobrecarga causada pelo uso de um SGBD e a

C. M. Getúlio Vargas Profª Leny Cerqueira 2º ano – Técnico em Informática

má administração justificam a utilização da abordagem processamento tradicional de
arquivos em casos como:

o banco de dados e as aplicações são simples, bem definidas e não se espera

mudanças no projeto;

a necessidade de processamento em tempo real de certas aplicações, que são

terrivelmente prejudicadas pela sobrecarga causada pelo uso de um SGBD;

não haverá múltiplo acesso ao banco de dados.

TABELAS
Um banco de dados compreende dados agrupados em tabelas.

Tabelas podem estar relacionadas entre si.

Uma tabela compreende linhas e colunas.

Cada linha de uma tabela (ou registro) contém informações de um elemento da tabela.

Cada coluna da tabela (ou campo) contém um tipo de informação dos elementos que
compõem a tabela.

Todos os registros de uma tabela contêm os mesmos campos, sempre na mesma

seqüência.

Os campos de uma tabela são definidos por quem cria a tabela.

Por exemplo, em um banco de dados com informações de Clientes, em uma tabela que
armazene os dados de clientes, cada linha da tabela conterá informações sobre um
cliente e as colunas serão Código do Cliente, Empresa, Endereco, etc.

Cada campo tem um nome e um tipo (texto, numérico, data, etc.).

O tipo de um campo define que informações poderão ser nele armazenadas. Um campo
texto guardará qualquer texto, contendo os mais variados caracteres. Um campo
numérico conterá valores numéricos e poderá ser usado em cálculos. Campos de data e
hora armazenarão datas e horas e permitirão a verificação de erros na entrada de dados.

PROPRIEDADE DE UMA TABELA

Uma única tabela possui as seguintes propriedades:

Não pode haver linhas duplicadas;

Não há colunas com nomes duplicados;

A ordem de uma linha é insignificante;

C. M. Getúlio Vargas Profª Leny Cerqueira 2º ano – Técnico em Informática

 ORDENAÇÃO DOS DADOS
Uma das grandes vantagens do uso de um SGBD é a possibilidade de ordenação dos
dados e alteração desta ordenação para apresentação dos mesmos no vídeo ou de
forma impressa.

Para ordenar os dados, um SGBD vale-se de chaves e índices.

É importante que toda tabela tenha uma chave primária, que pode compreender um ou
mais campos. A chave primária é aquele campo ou conjunto de campos que permite
identificar de forma única cada registro.

Além das chaves, os índices permitem a classificação dos dados.

Índices são estruturas de armazenamento de dados que permitem que uma tabela seja
acessada segundo outras ordens de classificação que não aquela da chave primária.

CHAVE PRIMÁRIA
O Conceito de "Chave Primária" é fundamental para o correto entendimento de como
funciona um Banco de Dados. Vamos entender o que significa um campo ser a Chave
Primária de uma Tabela e como tornar um Campo a Chave Primária de uma Tabela.

"Ao Definirmos um Campo como sendo uma Chave Primária, estamos informando ao
Microsoft Access que não podem existir dois registros com o mesmo valor no campo que
é a Chave Primária, ou seja, os valores no campo Chave Primária precisam ser únicos.
Por exemplo, se defino um campo "Número da Identidade", da tabela Clientes, como
sendo um campo do tipo Chave Primária, estou dizendo ao Microsoft Access que não
podem existir dois clientes com o mesmo valor no campo "Número da Identidade". Na
prática estou garantindo que não possam ser cadastrados dois clientes com o mesmo
Número de Identidade".

Em outras palavras poderíamos dizer que o Campo Chave Primária identifica de Maneira
Única cada Registro de uma Tabela, isto é, de posse do valor da Chave Primária somente
localizaremos um registro com aquele valor no campo Chave Primária.

RELACIONAMENTOS ENTRE TABELAS

Conforme podemos ver no banco de dados Pedidos.mdb, existem diversas tabelas:
Clientes, Produtos, Pedidos, Detalhes do Pedido, etc. Embora as informações estejam
separadas em cada uma das Tabelas, na prática devem existir relacionamentos entre as
tabelas. Por exemplo: Um Pedido é feito por um Cliente e neste Pedido podem existir
diversos itens, os quais são armazenados na tabela Detalhes do Pedido. Além disso cada
Pedido possui um número único, mas um mesmo Cliente pode fazer diversos pedidos e
assim por diante .

Em um banco de dados, precisamos de alguma maneira para representar estes

relacionamentos da vida Real, em termos das tabelas e de seus atributos. Isto é possível
com a utilização de "Relacionamentos entre tabelas", os quais podem ser de três tipos:

C. M. Getúlio Vargas Profª Leny Cerqueira 2º ano – Técnico em Informática

  Um para Um
 Um para Vários
 Vários para Vários
Relacionamento do Tipo Um para Um:
Esta relação existe quando os campos que se relacionam são ambos Chaves Primárias
em suas respectivas tabelas. Cada um dos campos não apresenta valores repetidos. Na
prática existem poucas situações onde utilizaremos um relacionamento deste tipo.

Um exemplo poderia ser o seguinte:

Imagine uma escola com um Cadastro de Alunos na tabela Alunos, destes apenas uma
pequena parte participa da Banda da Escola. Por questões de projeto do Banco de
Dados, podemos criar uma Segunda Tabela "Alunos da Banda", a qual se relaciona com
a tabela Alunos através de um relacionamento do tipo Um para Um. Cada aluno somente
é cadastrada uma vez na Tabela Alunos e uma única vez na tabela Alunos da Banda.
Poderíamos utilizar o Campo Matrícula do Aluno como o Campo que relaciona as duas
Tabelas.

Na tabela Alunos da Banda poderíamos colocar apenas o Número da Matrícula do aluno,

além das informações a respeito do Instrumento que ele toca, tempo de banda, etc.
Quando fosse necessário buscar as informações tais como nome, endereço, etc, estas
podem ser recuperadas através do relacionamento existente entre as duas tabelas,
evitando, com isso, que a mesma informação (Nome, Endereço, etc) tenha que ser
duplicada nas duas tabelas, inclusive aumentando a probabilidade de erros de digitação.

Na Próxima Figura vemos o exemplo de um Relacionamento do tipo Um para Um entre as

tabelas Alunos e Alunos da Banda.

Relacionamento Um para Um entre as Tabelas Alunos e Alunos da Banda.

Com a criação deste relacionamento estamos evitando a repetição desnecessária de

informações em diferentes tabelas.

Relacionamento do Tipo Um para Vários:

Este é, com certeza, o tipo de relacionamento mais comum entre duas tabelas. Uma das
tabelas (o lado um do relacionamento) possui um campo que é a Chave Primária e a
outra tabela (o lado vários) se relaciona através de um campo cujos valores relacionados
podem se repetir várias vezes.

C. M. Getúlio Vargas Profª Leny Cerqueira 2º ano – Técnico em Informática

Considere o exemplo entre a tabela Clientes e Pedidos. Cada Cliente somente é
cadastrado uma única vez na tabela de Clientes (por isso o campo Código do Cliente é
uma chave primária, indicando que não podem existir dois clientes com o mesmo código),
portanto a tabela Clientes será o lado um do relacionamento. Ao mesmo tempo cada
cliente pode fazer diversos pedidos, por isso que o Código de um Cliente poderá aparecer
várias vezes na tabela Pedidos, tantas vezes quantos forem os pedidos que o Cliente tiver
feito. Por isso que temos um relacionamento do tipo Um para Vários entre a tabela
Clientes e Pedidos, através do campo Código do Cliente, indicando que um mesmo
Cliente pode realizar diversos (vários) pedidos.

Na próxima figura vemos um exemplo de um Relacionamento Um para Vários entre as

Tabelas Clientes e Pedidos do banco de dados Pedidos.mdb, através do campo código
do cliente:

Relacionamento Um para Vários entre as Tabelas Clientes e Pedidos.

Observe que o lado Vários do relacionamento é representado pelo símbolo do infinito ( ¥).

No lado Um do relacionamento o campo é definido como uma Chave Primária (Campo

CódigoDoCliente na tabela Clientes) e no lado Vários não (campo CódigoDoCliente na
tabela Pedidos), indicando que no lado vários o Código do Cliente pode se repetir várias
vezes, o que faz sentido, uma vez que um mesmo cliente pode fazer diversos pedidos.

Tipo de
Lado Um Lado Vários
Relacionamento
Um para Vários CódigoDoFornecedor na tabela CódigoDoFornecedor na tabela
Fornecedores Produtos
Um para Vários CódigoDaCategoria na tabela Categorias CódigoDaCategoria na tabela
Produtos
Um para Vários CódigoDoProduto na tabela Produtos CódigoDoProduto na tabela
Detalhes do Pedido
Um para Vários CódigoDoFuncionário na tabela CódigoDoFuncionário na tabela
Funcionários Pedidos
Um para Vários NúmeroDoPedido na tabela Pedidos NúmeroDoPedido na tabela
Detalhes do Pedido
Um para Vários CódigoDaTransportadora na tabela Via na tabela Pedidos
Transportadoras
Um para Vários CódigoDoCliente na tabela Clientes CódigoDoCliente na tabela
Pedidos

Mais adiante veremos como implementar, na prática, estes relacionamentos. Algumas

observações importantes sobre relacionamentos :

 O Nome dos Campos envolvidos no Relacionamento, não precisa ser,

necessariamente, o mesmo, conforme indicado pelo relacionamento entre os

C. M. Getúlio Vargas Profª Leny Cerqueira 2º ano – Técnico em Informática

 campos CódigoDaTransportadora e Via, na tabela anterior. O tipo dos campos é
que precisa ser o mesmo, por exemplo, se um dos campos for do tipo Texto, o
outro também deverá ser do tipo Texto .

 Sempre o Lado um do Relacionamento deve ser uma chave primária, já o lado

vários não pode ser uma chave Primária

 De Preferência, antes de Criar os Relacionamentos verifique se o tipo dos campos

a serem relacionados é o mesmo, além de características como máscaras de
entrada e formato .

Relacionamento do tipo Vários para Vários:

Seria uma situação onde em ambos os lados do relacionamento os valores poderiam se
repetir. Vamos considerar o caso entre Produtos e Pedidos. Posso ter Vários Pedidos nos
quais aparece um determinado produto, além disso vários Produtos podem aparecer no
mesmo Pedido. Esta é uma situação em que temos um Relacionamento do Tipo Vários
para Vários .

Na prática não temos como implementar um relacionamento deste tipo, devido a uma
série de problemas que seriam introduzidos no modelo de dados. Por exemplo, na tabela
Pedidos teríamos que repetir o Número do Pedido, Nome do Cliente, Nome do
Funcionário, Data do Pedido, etc para cada item do Pedido .

Para evitar este tipo de problema é bastante comum "quebrarmos" um relacionamento

do tipo Vários para Vários em dois relacionamento do tipo Um para Vários. Isso é feito
através da criação de uma nova tabela, a qual fica com o lado Vários dos
relacionamentos. No nosso exemplo foi criada a tabela Detalhes do Pedido, onde ficam
armazenadas as informações sobre os diversos itens de cada pedido, aí ao invés de
termos um relacionamento do tipo Vários para Vários, teremos dois relacionamentos do
tipo um para vários, conforme descrito pela próxima tabela

Tipo de Relacionamento Lado Um Lado Vários

Um para Vários CódigoDoProduto na tabela CódigoDoProduto na tabela Detalhes
Produtos do Pedido
Um para Vários NúmeroDoPedido na tabela NúmeroDoPedido na tabela Detalhes
Pedidos do Pedido

Na figura abaixo temos a representação dos dois relacionamentos Um para Vários:

Tabela Detalhes do Pedido ficou com o lado Vários dos Relacionamentos.

C. M. Getúlio Vargas Profª Leny Cerqueira 2º ano – Técnico em Informática

Esta situação em que um relacionamento um para Vários é "quebrado" em dois
Relacionamentos do tipo Um para Vários é bastante comum. Diversas vezes utilizamos
esta técnica para eliminar uma série de problemas no Banco de Dados, tais como
informação repetida e inconsistência de Dados.

Retirada e adaptada da apostila elaborada pela Profa. Maria Aparecida Castro Livi
Universidade Federal do Rio Grande do Sul
Instituto de Informática
Departamento de Informática Aplicada

C. M. Getúlio Vargas Profª Leny Cerqueira 2º ano – Técnico em Informática