Banco de Dados

Sidney de Castro
1
Faculdade de Engenharia Celso Daniel - FAENG
Grupo de estudos Tecnologia WEB - Engenharia da Computação
sidcast@gmail.com

Resumo. Este documento descreve as caracterı́sticas básicas de um sistema

gerenciamento de banco de dados. Será usado nas aulas de Banco de Dados
como uma seleção de textos sobre o uso de banco de dados relacionais.

Sumário

1 Sistema de Gerenciamento de banco de dados 2

2 Algebra Relacional 4
2.1 Definições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Funções . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Normalização de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Exercı́cio um sobre Normalização de Dados . . . . . . . . . . . . . . . . 7
2.5 Exercı́cio dois sobre Normalização de Dados . . . . . . . . . . . . . . . 8
2.6 Relação Entre Entidades . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Sistema de Gerenciamento de banco de dados
Banco de dados (ou base de dados), é um conjunto de registros dispostos em estrutura
regular que possibilita a reorganização dos mesmos e produção de informação. Os bancos
de dados relacionais representam a principal ferramenta de armazenamento e recuperação
de informação que existe nos dias de hoje. Um banco de dados normalmente agrupa
registros utilizáveis para um mesmo fim. A forma de se organizar estes dados em uma
base é pode ser definida como uma álgebra relacional.
Os Bancos de dados relacionais (BDR) surgiram em meados da década de 1970.
Porém, apenas alguns anos mais tarde as empresas passaram a utilizá-los no lugar de
arquivos planos (do inglês flat file), bancos de dados hierárquicos e em rede.
Em 1987, Edgar Frank Codd [Codd 1987], criador do modelo relacional, publicou
um artigo onde definia 12 regras para que um Sistema Gerenciador de Banco de Dados
(SGBD) fosse considerado relacional:
1. Regra Fundamental:
Um SGBD relacional deve gerenciar seus dados usando apenas suas capacidades
relacionais
2. Regra da informação:
Toda informação deve ser representada de uma única forma, como dados em uma
tabela
3. Regra da garantia de acesso:
Todo dado (valor atômico) pode ser acessado logicamente (e unicamente) usando
o nome da tabela, o valor da chave primária da linha e o nome da coluna.
4. Tratamento sistemático de valores nulos:
Os valores nulos (diferente do zero, da string vazia, da string de caracteres em
brancos e outros valores não nulos) existem para representar dados não existentes
de forma sistemática e independente do tipo de dado.
5. Catálogo dinâmico on-line baseado no modelo relacional:
A descrição do banco de dados é representada no nı́vel lógico como dados or-
dinários (isso é, em tabelas), permitindo que usuários autorizados apliquem as
mesmas formas de manipular dados aplicada aos dados comuns ao consultá-las.
6. Regra da sub-linguagem compreensiva:
Um sistema relacional pode suportar várias linguagens e formas de uso, porém
deve possuir ao menos uma linguagem com sintaxe bem definida e expressa por
cadeia de caracteres e com habilidade de apoiar a definição de dados, a definição
de visões, a manipulação de dados, as restrições de integridade, a autorização e a
fronteira de transações.
7. Regra da atualização de visões:
Toda visão que for teoricamente atualizável será também atualizável pelo sistema.
8. Inserção, atualização e eliminação de alto nı́vel:
A capacidade de manipular a relação base ou relações derivadas como um opera-
dor único não se aplica apenas a recuperação de dados, mas também a inserção,
alteração e eliminação de dados.
9. Independência dos dados fı́sicos:
Programas de aplicação ou atividades de terminal permanecem logicamente inal-
teradas quaisquer que sejam as modificações na representação de armazenagem
ou métodos de acesso internos.
 10. Independência lógica de dados:
Programas de aplicação ou atividades de terminal permanecem logicamente inal-
teradas quaisquer que sejam as mudanças de informação que permitam teorica-
mente a não alteração das tabelas base.
11. Independência de integridade:
As relações de integridade especı́ficas de um banco de dados relacional devem ser
definidas em uma sub-linguagem de dados e armazenadas no próprio banco (e não
em programas).
12. Independência de distribuição:
A linguagem de manipulação de dados deve possibilitar que as aplicações
permaneçam inalteradas estejam os dados centralizados ou distribuı́dos fisica-
mente.
13. Regra da Não-subversão:
Não deve ser possı́vel subverter ou ignorar as regras de integridade e restrições
definidas.
Os Bancos de Dados Relacionais foram desenvolvidos para prover acesso facili-
tado aos dados, possibilitando que os usuários utilizassem uma grande variedade de abor-
dagens no tratamento das informações. Pois, enquanto em um banco de dados hierárquico
os usuários precisam definir as questões de negócios de maneira especı́fica, iniciando pela
raiz do mesmo, nos Bancos de Dados Relacionais os usuários podem fazer perguntas re-
lacionadas aos negócios através de vários pontos. A linguagem padrão dos Bancos de
Dados Relacionais é a Structured Query Language, ou simplesmente SQL, como é
mais conhecida.
Podemos verificar no link a seguir um comparação entre os atuais banco relacio-
nais: http://en.wikipedia.org/wiki/Comparison of relational database management systems
Vamos recordar dos componentes que um software deve apresentar:
• A interface gráfica garante (GUI) a definição dos processos a que se aplica esta
parte do sistema.
• As regras de negócio são os algoritmos que escrevemos
• Os dados são armazenados em um repositório externo que pode ser compartilhado
por várias pessoas.

Figura 1. Partes de um software

2. Algebra Relacional
A álgebra relacional é uma forma de cálculo sobre conjuntos ou relações.
Vamos aqui adotar que os conjuntos podem ser representados com base em sua
estrutura (figura 2(a)) ou como listagem (figura 2(b)) de seus elementos (linha).

(a) Representação em Estru-

(b) Respresentação em Listagem
tura

Figura 2. Formas de Representação de Tabelas

2.1. Definições
Vamos definir os elementos gráficos e suas funcionalidades:
• Entidades - Objeto do mundo real do qual desejamos quardar alguma informação.
Ex: Carro, Aluno, MovimentaçãoDeEstoque.
• Atributo - É uma caracterı́stica da Entidade.
Ex Carro.cor, Carro.ano, Aluno.nome.
• Linha da Tabela - É o conjunto de atributos que definem uma ocorrência (objeto
do mundo real).
• Valor do Atributo - É o valor que o atributo assume para cada linha da tabela.
• Chave da Entidade É o atributo cujo valor não se repete para nenhuma outra
ocorrencia dentro de uma entidade.
• Tipo do Atributo - É o domı́nio de dado que o atributo assume, ou seja, quais
valores podem ser atribuı́dos a este atributo
Ex:
Double - para valores em ponto flutuante
Integer - para valores inteiros
String/VarChar(n) - para cadeia de caracter.
• Chave Estrangeira - É o atributo que está presente na entidade e não é chave,
existe com a finalidade de permitir o relacionamento entre esta entidade e outra
onde este atributo é chave.

2.2. Funções
A álgebra relacional é uma forma de cálculo sobre conjuntos ou relações. Há seis
operações fundamentais na álgebra relacional. Estas operações são: seleção, projeção,
renomear, produto cartesiano, união e diferença entre conjuntos. Todas essas
operações produzem uma nova relação como seu resultado. Em adição às operações
fundamentais há outras de uso comum que são frequentemente utilizadas: interseção de
conjuntos, junção natural, divisão e junção theta.
Uma aplicação prática da álgebra relacional é na execução de consultas a bancos
de dados relacionais. Por essa razão, foram criadas novas operações, denominadas es-
tendidas, que são: Eliminação de duplicatas, ordenação, agrupamento e agregação
e junção externa. As álgebras relacionais recebiam pouca atenção até a publicação do
modelo relacional de dados [Codd 1970]. Codd propôs tal álgebra como uma base para
linguagens de consulta em banco de dados.
Como em qualquer álgebra, alguns operadores são primitivos e os outros, que são
descritos em termos dos primitivos e definidos como derivados. É útil que a escolha dos
operadores paralelos primitivos faça uso dos operadores lógicos primitivos. Os seis ope-
radores primitivos de Codd na álgebra são o de seleção, projeção, produto cartesiano,
união, diferença e renomeação. Estes seis operadores são fundamentais no sentido de
que nenhum deles pode ser omitido sem perder poder expressivo.
• Projeção - Escolha dos atributos que serão listados.
Ex: Na figura 3(b) vemos o resultado de P(Aluno.nome), que é a projeção da
tabela aluno

(a) Tabela Aluno (b) Projeção

Figura 3. Calculo de uma Projeção

• Seleção - É a restição das linha que serão apresentadas por algum critério cuja o
resultado verdadeiro da expressão satisfaça. Uma expressão faz uso dos operado-
res relacionais (¿, ≥, ¡, ≤, =, 6= ).
Ex: Selecionar os alunos da computação.

P(Aluno.nome,Aluno.disciplina;S(Aluno(Aluno.disciplina=’computacão’))

Figura 4. Seleção dos alunos da computação

• Produto Cartesiano e Junção Natural - A função do Produto Cartesiano em

conjuntos, opera com a seleção para cada linha do primeiro com todos os elemen-
tos do segundo . Isto não é muito útil para a computação, mas se utilizarmos o
conceito de junção natural podemos selecionar para cada linha do primeiro con-
junto apenas os elementos que satisfaçam ao critério de coincidir com o valor de
 algum atributo do segundo.
EX:

Figura 5. Junção Natural de duas Entidades

2.3. Normalização de Dados

Inicialmente devemos lembrar que um dos objetivos do uso desta álgebra relacional é
eliminar a redundância de armazenamento de dados, não apenas pela economia de espaço
mas principalmente para garantir a integridade da informação.
Garantir a integridade é manter sua representação (o dado) em apenas um lo-
cal, isto garante que qualquer processo deverá consultar apenas este dado para obter a
informação desejada.
Qualquer documento que contenha dados, pode ser classificado como estando na
primeira forma normal, ou seja, não há uma normalização destes dados. Também po-
demos classificar o documento como desnormalizado.
O critério para definir que dado deve fazer parte da tabela e consequentemente
passar para a segunda forma normal é a avaliação da dependência funcional.
Dependência funcional na prática é a resposta à perguntade se este atributo de-
pende funcionalmente da chave da entidade?
Ex: O nome do aluno depende do código do aluno na tabela Aluno?
E a resposta é sim.
Logo o nome do aluno deve ser um atributo da tabela Aluno.
Para a terceira forma normal vamos avaliar a situação do campo valorDoDes-
conto da tabela NotaFiscalItem. Parece obvio que este atributo depende funcionalmente
da chave da tabela, mas também poderia ser calculado como sendo valorU nitatio ∗
quantidade ∗ imposto. Logo este atributo não prescisa ser armazenado.
Então se um atributo depende da chave da entidade e apenas desta chave (não é
função de mais atributos), dizemos que o modelo está na terceira forma normal.
2.4. Exercı́cio um sobre Normalização de Dados
Vamos então fazer um exercı́cio para identificar as entidades e os atributos no diagrama
de contexto de automação de uma clinica médica hipotética figura 6.
Dada a seguinte lista de requisitos.
• O paciente chega à recepção da clinica e se identifica para a enfermeira
(Apresentação de documentos pessoais.
• O paciente informa a forma de pagamento ao serviço da clinica (convênio médico,
particular, etc). Os dados são validados e a enfermeira solicita uma sucinta
descrição de suas necessidades e horário disponı́veis para a marcação da consulta
como o médico especialista.
• Na data e hora marcada a consulta acontece com a prévia identificação do paciente
e levantamento da ficha média (se existir).
• O médico pode dar o diagnostico e um prescrição médica ou solicitar exames com-
plementares. Se exames são solicitados o paciente é encaminhado ao setor/clinica
responsável pelos exames e uma data de retorno é marcada.
• Na data de retorno o paciente com os exames e seu histórico médico é encami-
nhado para a consulta, e novamente o médico pode dar o diagnostico ou solicitar
exames complementares.

(a) IDEF0 - Clinica Médica (b) IDEF1 - Clinica Médica

Figura 6. Diagrama de Contexto

2.5. Exercı́cio dois sobre Normalização de Dados
Dado o esquema (figura 7) do documento que representa uma nota fiscal (documento
desnormalizado), aplicar as regra da analise de dados passo a passo para obter um modelo
de dados na terceira forma normal.

Figura 7. Nota fiscal simplificada

Como primeira atividade devemos identificar as entidades que estão presentes

no documento, esta é uma tarefa que não tem uma definição muito precisa pois depende
do escopo do problema e da solução que estamos projetando. Em nosso caso vamos
simplificar ao máximo já que o interesse é no método para a normalização de dado. A
figura 8(a) representa este estado.
Com as entidades identificadas conforme vemos na figura 8(b), partimos para a
identificação das chaves das entidades.

(a) Identificação das Entidades (b) Definição das Chaves das Entidades

Figura 8. Evolução do Processo de Normalização de Entidades

A próxima etapa é definir as chaves estrangeiras ou em outras pala-

vras as relações entre as entidades. Neste exemplo estamos usando uma fer-
ramenta de software livre chamada DBDesigner que pode ser encontrada em
’http://www.fabforce.net/dbdesigner4/’.
A interpretação do gráfico apresentado na figura 9 é a seguinte:
• Na tabela NFCABECALHO incluimos a chave estrangeira CPFDoCliente, para
permitir a relação hierarquica entre o Cabeçalho de Nota Fiscal e os clientes.
 • Na tabela NFItem incluimos a chave estrangeira CódigoDoProduto, para permitir
a relação hierarquica entre o Item de Nota Fiscal e os produtos.
• Definimos sem a necessidade de incluir chave estrageira a relação hierarquica
entre Cabeçalho e item de nota fiscal.
Basta agora incluir os demais atributos respeitando a regra de coloca-los nas enti-
dades em que exista uam dependência funcional. Ex: Para a tabela CLIENTE atribuı́mos
o nome do cliente como atributo, e assim por diante.

Figura 9. Definição das chaves estrangeiras e as relações

2.6. Relação Entre Entidades

Referências
Codd, E. F. (1970). A relational model of data for large shared data banks. Commun.
ACM, 13(6):377–387.
Codd, E. F. (1987). More commentary on missing information in relational databases
(applicable and inapplicable information). 16(1):42–50.