Livro DB

Banco de Dados
Sidney de Castro
1
Faculdade de Engenharia Celso Daniel - FAENG
Grupo de estudos Tecnologia WEB - Engenharia da Computação
sidcast@gmail.com
Resumo. Este documento descreve as caracterı́sticas básicas de um sistema

gerenciamento de banco de dados. Será usado nas aulas de Banco de Dados
como uma seleção de textos sobre o uso de banco de dados relacionais.
Sumário
1 Sistema de Gerenciamento de banco de dados 3
2 Algebra Relacional 5
2.1 Definições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Funções . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Normalização de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Exercı́cio Resolvido - Normalização de Dados . . . . . . . . . . . . . . 8
2.5 Exercı́cio sobre Normalização de Dados . . . . . . . . . . . . . . . . . . 10
2.6 Relação Entre Entidades . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.6.1 Relação Hierárquica . . . . . . . . . . . . . . . . . . . . . . . . 11
2.6.2 Relação Simétrica . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.6.3 Relação Recursiva . . . . . . . . . . . . . . . . . . . . . . . . . 12
3 Modelagem de Dado 13
3.1 Dado ou Processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Diagrama de Entidade e Relacionamento DER . . . . . . . . . . . . . . . 15
3.3 Validação do DER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4 Interface de Acesso ao Banco 18

4.1 Interface do Netbeansr . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2 Java Database Connectivity (JDBC) . . . . . . . . . . . . . . . . . . . . 19
5 Introdução ao SQL 20
5.1 Origem e Evolução da SQL . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.2 Palavras-chaves em SQL . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.2.1 DML - Linguagem de Manipulação de Dados . . . . . . . . . . . 21
5.2.2 DDL - Linguagem de Definição de Dados . . . . . . . . . . . . . 21
5.2.3 DCL - Linguagem de Controle de Dados . . . . . . . . . . . . . 21
5.2.4 DTL - Linguagem de Transação de Dados . . . . . . . . . . . . . 22
5.2.5 DQL - Linguagem de Consulta de Dados . . . . . . . . . . . . . 22
6 ANEXOS 25
1. Sistema de Gerenciamento de banco de dados
Banco de dados (ou base de dados), é um conjunto de registros dispostos em estrutura
regular que possibilita a reorganização dos mesmos e produção de informação. Os bancos
de dados relacionais representam a principal ferramenta de armazenamento e recuperação
de informação que existe nos dias de hoje. Um banco de dados normalmente agrupa
registros utilizáveis para um mesmo fim. A forma de se organizar estes dados em uma
base é pode ser definida como uma álgebra relacional.
Os Bancos de dados relacionais (BDR) surgiram em meados da década de 1970.
Porém, apenas alguns anos mais tarde as empresas passaram a utilizá-los no lugar de
arquivos planos (do inglês flat file), bancos de dados hierá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 informação:
Toda informação deve ser representada de uma única forma, como dados em uma
tabela
3. Regra da garantia de acesso:
Todo dado (valor atômico) pode ser acessado logicamente (e unicamente) usando
o nome da tabela, o valor da chave primária da linha e o nome da coluna.
4. Tratamento sistemático de valores nulos:
Os valores nulos (diferente do zero, da string vazia, da string de caracteres em
brancos e outros valores não nulos) existem para representar dados não existentes
de forma sistemática e independente do tipo de dado.
5. Catálogo dinâmico on-line baseado no modelo relacional:
A descrição do banco de dados é representada no nı́vel lógico como dados or-
dinários (isso é, em tabelas), permitindo que usuários autorizados apliquem as
mesmas formas de manipular dados aplicada aos dados comuns ao consultá-las.
6. Regra da sub-linguagem compreensiva:
Um sistema relacional pode suportar várias linguagens e formas de uso, porém
deve possuir ao menos uma linguagem com sintaxe bem definida e expressa por
cadeia de caracteres e com habilidade de apoiar a definição de dados, a definição
de visões, a manipulação de dados, as restrições de integridade, a autorização e a
fronteira de transações.
7. Regra da atualização de visões:
Toda visão que for teoricamente atualizável será também atualizável pelo sistema.
8. Inserção, atualização e eliminação de alto nı́vel:
A capacidade de manipular a relação base ou relações derivadas como um opera-
dor único não se aplica apenas a recuperação de dados, mas também a inserção,
alteração e eliminação de dados.
9. Independência dos dados fı́sicos:
Programas de aplicação ou atividades de terminal permanecem logicamente inal-
teradas quaisquer que sejam as modificações na representação de armazenagem
ou métodos de acesso internos.
10. Independência lógica de dados:
Programas de aplicação ou atividades de terminal permanecem logicamente inal-
teradas quaisquer que sejam as mudanças de informação que permitam teorica-
mente a não alteração das tabelas base.
11. Independência de integridade:
As relações de integridade especı́ficas de um banco de dados relacional devem ser
definidas em uma sub-linguagem de dados e armazenadas no próprio banco (e não
em programas).
12. Independência de distribuição:
A linguagem de manipulação de dados deve possibilitar que as aplicações
permaneçam inalteradas estejam os dados centralizados ou distribuı́dos fisica-
mente.
13. Regra da Não-subversão:
Não deve ser possı́vel subverter ou ignorar as regras de integridade e restrições
definidas.
Os Bancos de Dados Relacionais foram desenvolvidos para prover acesso facili-
tado aos dados, possibilitando que os usuários utilizassem uma grande variedade de abor-
dagens no tratamento das informações. Pois, enquanto em um banco de dados hierárquico
os usuários precisam definir as questões de negócios de maneira especı́fica, iniciando pela
raiz do mesmo, nos Bancos de Dados Relacionais os usuários podem fazer perguntas re-
lacionadas aos negócios através de vários pontos. A linguagem padrão dos Bancos de
Dados Relacionais é a Structured Query Language, ou simplesmente SQL, como é
mais conhecida.
Podemos verificar no link a seguir um comparaçã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 gráfica garante (GUI) a definição dos processos a que se aplica esta
parte do sistema.
• As regras de negócio são os algoritmos que escrevemos
• Os dados são armazenados em um repositório externo que pode ser compartilhado
por várias pessoas.
Figura 1. Partes de um software

2. Algebra Relacional
A álgebra relacional é uma forma de cálculo sobre conjuntos ou relaçõ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) Representação em Estru-

(b) Respresentação em Listagem
tura
Figura 2. Formas de Representação de Tabelas
2.1. Definições
Vamos definir os elementos gráficos e suas funcionalidades:
• Entidades - Objeto do mundo real do qual desejamos quardar alguma informação.
Ex: Carro, Aluno, MovimentaçãoDeEstoque.
• Atributo - É uma caracterı́stica da Entidade.
Ex Carro.cor, Carro.ano, Aluno.nome.
• Linha da Tabela - É o conjunto de atributos que definem uma ocorrência (objeto
do mundo real).
• Valor do Atributo - É o valor que o atributo assume para cada linha da tabela.
• Chave da Entidade É o atributo cujo valor não se repete para nenhuma outra
ocorrencia dentro de uma entidade.
• Tipo do Atributo - É 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 - É o atributo que está presente na entidade e não é chave,
existe com a finalidade de permitir o relacionamento entre esta entidade e outra
onde este atributo é chave.
2.2. Funções
A álgebra relacional é uma forma de cálculo sobre conjuntos ou relações. Há seis
operações fundamentais na álgebra relacional. Estas operações são: seleção, projeção,
renomear, produto cartesiano, união e diferença entre conjuntos. Todas essas
operações produzem uma nova relação como seu resultado. Em adição às operações
fundamentais há outras de uso comum que são frequentemente utilizadas: interseção de
conjuntos, junção natural, divisão e junção theta.
Uma aplicação prática da álgebra relacional é na execução de consultas a bancos
de dados relacionais. Por essa razão, foram criadas novas operações, denominadas es-
tendidas, que são: Eliminação de duplicatas, ordenação, agrupamento e agregação
e junção externa. As álgebras relacionais recebiam pouca atenção até a publicação do
modelo relacional de dados [Codd 1970]. Codd propôs tal álgebra como uma base para
linguagens de consulta em banco de dados.
Como em qualquer álgebra, alguns operadores são primitivos e os outros, que são
descritos em termos dos primitivos e definidos como derivados. É útil que a escolha dos
operadores paralelos primitivos faça uso dos operadores lógicos primitivos. Os seis ope-
radores primitivos de Codd na álgebra são o de seleção, projeção, produto cartesiano,
união, diferença e renomeação. Estes seis operadores são fundamentais no sentido de
que nenhum deles pode ser omitido sem perder poder expressivo.
• Projeção - Escolha dos atributos que serão listados.
Ex: Na figura 3(b) vemos o resultado de P(Aluno.nome), que é a projeção da
tabela aluno
(a) Tabela Aluno (b) Projeção
Figura 3. Calculo de uma Projeção
• Seleção - É a restição das linha que serão apresentadas por algum critério cuja o
resultado verdadeiro da expressão satisfaça. Uma expressão faz uso dos operado-
res relacionais (¿, ≥, ¡, ≤, =, 6= ).
Ex: Selecionar os alunos da computação.
P(Aluno.nome,Aluno.disciplina;S(Aluno(Aluno.disciplina=’computacão’))
Figura 4. Seleção dos alunos da computação
• Produto Cartesiano e Junção Natural - A função do Produto Cartesiano em

conjuntos, opera com a seleção para cada linha do primeiro com todos os elemen-
tos do segundo . Isto não é muito útil para a computação, mas se utilizarmos o
conceito de junção natural podemos selecionar para cada linha do primeiro con-
junto apenas os elementos que satisfaçam ao critério de coincidir com o valor de
algum atributo do segundo.
EX:
Figura 5. Junção Natural de duas Entidades
2.3. Normalização de Dados

Inicialmente devemos lembrar que um dos objetivos do uso desta álgebra relacional é
eliminar a redundância de armazenamento de dados, não apenas pela economia de espaço
mas principalmente para garantir a integridade da informação.
Garantir a integridade é manter sua representação (o dado) em apenas um lo-
cal, isto garante que qualquer processo deverá consultar apenas este dado para obter a
informação desejada.
Qualquer documento que contenha dados, pode ser classificado como estando na
primeira forma normal, ou seja, não há uma normalização destes dados. Também po-
demos classificar o documento como desnormalizado.
O critério para definir que dado deve fazer parte da tabela e consequentemente
passar para a segunda forma normal é a avaliação da dependência funcional.
Dependência funcional na prática é a resposta à perguntade se este atributo de-
pende funcionalmente da chave da entidade?
Ex: O nome do aluno depende do código do aluno na tabela Aluno?
E a resposta é sim.
Logo o nome do aluno deve ser um atributo da tabela Aluno.
Para a terceira forma normal vamos avaliar a situação do campo valorDoDes-
conto da tabela NotaFiscalItem. Parece obvio que este atributo depende funcionalmente
da chave da tabela, mas também poderia ser calculado como sendo valorU nitatio ∗
quantidade ∗ imposto. Logo este atributo não prescisa ser armazenado.
Então se um atributo depende da chave da entidade e apenas desta chave (não é
função de mais atributos), dizemos que o modelo está na terceira forma normal.
2.4. Exercı́cio Resolvido - Normalização de Dados
Dado o esquema (figura 6) 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 6. Nota fiscal simplificada
Como primeira atividade devemos identificar as entidades que estão presentes

no documento, esta é uma tarefa que não tem uma definição muito precisa pois depende
do escopo do problema e da solução que estamos projetando. Em nosso caso vamos
simplificar ao máximo já que o interesse é no método para a normalização de dado. A
figura 7(a) representa este estado.
Com as entidades identificadas conforme vemos na figura 7(b), partimos para a
identificação das chaves das entidades.
(a) Identificação das Entidades (b) Definição das Chaves das Entidades
Figura 7. Evolução do Processo de Normalização de Entidades
A próxima etapa é definir as chaves estrangeiras ou em outras pala-

vras as relações entre as entidades. Neste exemplo estamos usando uma fer-
ramenta de software livre chamada DBDesignerr que pode ser encontrada em
’http://www.fabforce.net/dbdesigner4/’.
A interpretação do gráfico apresentado na figura 8 é a seguinte:
• Na tabela NFCABECALHO incluimos a chave estrangeira CPFDoCliente, para
permitir a relação hierarquica entre o Cabeçalho de Nota Fiscal e os clientes.
• Na tabela NFItem incluimos a chave estrangeira CódigoDoProduto, para permitir
a relação hierarquica entre o Item de Nota Fiscal e os produtos.
• Definimos sem a necessidade de incluir chave estrageira a relação hierarquica
entre Cabeç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 dependência funcional. Ex: Para a tabela CLIENTE atribuı́mos
o nome do cliente como atributo, e assim por diante.
Figura 8. Definição das chaves estrangeiras e as relações

2.5. Exercı́cio sobre Normalização de Dados
Vamos então fazer um exercı́cio para identificar as entidades e os atributos no diagrama
de contexto de automação de uma clinica médica hipotética figura 9.
Dada a seguinte lista de requisitos.
• O paciente chega à recepção da clinica e se identifica para a enfermeira
(Apresentação de documentos pessoais.
• O paciente informa a forma de pagamento ao serviço da clinica (convênio médico,
particular, etc). Os dados são validados e a enfermeira solicita uma sucinta
descrição de suas necessidades e horário disponı́veis para a marcação da consulta
como o médico especialista.
• Na data e hora marcada a consulta acontece com a prévia identificação do paciente
e levantamento da ficha média (se existir).
• O médico pode dar o diagnostico e um prescrição médica ou solicitar exames com-
plementares. Se exames são solicitados o paciente é encaminhado ao setor/clinica
responsável pelos exames e uma data de retorno é marcada.
• Na data de retorno o paciente com os exames e seu histórico médico é encami-
nhado para a consulta, e novamente o médico pode dar o diagnostico ou solicitar
exames complementares.
(a) IDEF0 - Clinica Médica (b) IDEF1 - Clinica Médica
Figura 9. Diagrama de Contexto

2.6. Relação Entre Entidades
A relação existente entre entidades pode ser de vários tipos, para efeito de aplicação em
banco de dados hierárquico vamos definir três tipos principais: hierárquica, simétrica
ou recursiva.
2.6.1. Relação Hierárquica
Na prática podemos definir uma relação como sendo a junção natural (ver figura 5)entre
duas entidades. Verifica-se que a ligação ocorre com a identificação de dois atributos um
em cada entidade. Geralmente o atributo é chave na primeira entidade e chave estrangeira
na segunda entidade, se a situação é esta, então está definida a relação de hierarquia entra
as entidades. Esta relação de hierarquia pode ser comparada a relação de parentesco entre
pai e filho, um pai tem diversos filhos (onde o atributo é chave estrangeira) mas um filho
apenas um pai (onde o atributo é chave).
Usando o programa DBDesignerr podemos observar na figura 10 uma
representação da relação Hierárquica existente entre as entidades PROFESSOR e
ALUNO. Nesta representação deixamos o programa definir chaves e criar a relação sem
interferir. O programa decidiu criar os atributos PROFESSOR idPROFESSOR e definiu
com FK (FOREIGN KEY ou Chave Estrangeira).
Para diferenciar o nome da entidade dos atributos usamos letra maiúscula para
entidade e as regras de nomeação da UML para os atributos.
Na conexão da relação entre as entidade encontramos seu nome (Rel 01) e um
losango com um lado sem preenchimento e outro preenchido. Do lado sem o preenchi-
mento interpretamos com sendo de cardinalidade1 igual a 1 e do outro lado como sendo
n.
Figura 10. Representação de uma Relação Hierárquica
2.6.2. Relação Simétrica
Supondo que em duas entidades apresentes possuam uma relação com cardinalidade n
em ambas as entidades e esta relação é dado por atributos chaves dos dois lados. Isto
define uma relação de simetria entre as entidades. Um exemplo desta situação é o caso
1
Cardinalidade para a teoria dos conjunto é a quantidade de ocorrências de elementos no conjunto
do FONECEDOR (que fornece produtos) e o PRODUTO (que pode ser fornecido por
diversos fornecedores), verifique esta situação na figura 11.
Ao criarmos as duas relação percebemos que um Fornecedor só produzirá um
produto e ao contrário a situação é a mesma, um Produto será comprado de um único
fornecedor 2 .
Figura 11. Problema na Relação simétrica
Novamente deixamos o programa DBDesignerr tomar a decisão e ao criarmos a

relação simétrica o programa cria uma terceira entidade FONERCEDOR has PRODUTO
com duas relações hierárquicas figura 12.
Figura 12. Relação Simétrica Fornecedor x Produto
2.6.3. Relação Recursiva
Finalmente podemos definir uma relação de recursividade com a inclusão de um atributo

que se refere à própria chave da entidade. Ex.: Suponha a entidade PESSOA e um atributo
cujo conteúdo é a própria chave, a interpretação é: parente de alguma pessoa. Então a
entidade PESSOA apresenta uma recursão sob a relação de parentesco.
Novamente deixamos as decisões por conta do programa e o atributo criado foi
PESSOA idPESSOA, que podemos verificar na figura 13.
Figura 13. Relação Recursiva
2
procure verificar esta afirmação fazendo um exemplo e colocando dados nas duas entidades
3. Modelagem de Dado
Um software é uma das poucas maneiras possı́vel de capturar e usar o conhecimento de
alguém colocando este conhecimento a serviço de outro. Poderı́amos pensar em livros ou
nas escolas, mas a capacidade de interação do software é algo muito superior.
Um software é composto basicamente por três elementos: Os algoritmos; A inter-
face com o usuário; A base de dado. Com o algoritmo pretendemos capturar o comporta-
mento, com a interface temos a oportunidade de definir a ordem em as coisas acontecem
e com os dados temos a memória e relacionamos com as etapas anteriores.
A Engenharia de Software é a ciência da computação aplicada na transformação
do computador em uma ferramenta de trabalho para os seus utillizadores.
Segundo Pressman [Presman 2005], as práticas de engeharia de software se inten-
sificam com o agravamento dos problemas relativos ao software.
• A sofisticaçãodos dos problemas ultrapassam nossa capacidade de construir
softwares que extraiam o potencial oferecido pelo hardware.
• Nossa capacida de construir software de qualidade não pode acompanhar a de-
manda por novas aplicações.
• Nossa capacidade de manter os softwares existentes foi ameaçada por projetos
ruins e recursos inadequados.
Observa-se nestas considerações que a Engenharia de Software trata intimamente
das limitações humanas em criar software.
Em nossa disciplina Banco de Dados vamos focar nas questões relativas ao arma-
zenamento e recuperação de dados.
3.1. Dado ou Processo

A Engenharia de Software utiliza diversos artefatos para representar as funcionalidade de
um software. Estes artefatos incluem desde listas de ações em nı́vel de abstração muito
alto (Lista de Requisitos) até diagramas com mensagens de método na execução de um
programa (Diagrama de Sequencia).
As primeiras tentativas de representação do comportamento de sistemas tem seu
foco no fluxo de dados entre os processos. Na figura 9(a) vemos um exemplo com o uso
de IDEF0 (Integration Definition for Function Modeling).
Com o surgimento da OO (Orientação a Objetos) passamos o foco para o pro-
cesso, na figura 14 observamos um diagama de caso de uso. Este diagrama é equivalente
em funcionalidade ao IDEF0, mas não apresenta depósitos de dados apenas o fluxo do
processo.
Ao apresentarmos a figura 14 ou a figura 9(b) sem explicar verbalmente ou
por escrito interpretação fica prejudicada, esta dificuladde ocorre devido a falta de
contextualização do problema. Colocar o problema dentro da dimensão correta, se faz
necessário o artefato da UML demoninado Contexto 0. Ex:
Desejamos automatizar o atendimento dos cliente em um posto de gaso-
lia. Vamos controlar as vendas de combustı́vel e os serviços em geral. As
tarefas a serem autimatizadas nestes postos se dividem em três nı́veis de
Figura 14. Diagrama de Case de Uso da UML
responsabilidades: O gerente do posto (cadastros e controle dos proces-

sos); Frentista (executor dos serviços aos clientes); O caixa (Recebimento
dos pagamentos dos clientes).
Então baseado no Contexto 0 podemos definir com maior grau de detalhamento
os requisitos usando um texto estruturado.
Exemplo de uma Lista de Requisitos
Contexto 0: Os cadastros do sistema devem ser feitos pelo gerente.
01-Requisito: CADASTRO
• O gerente faz o cadastramento do cliente.
• O gerente faz o cadastramento do produto.
• O gerente faz o cadastramento do funcionário.
• O gerente faz o cadastramento do fornecedor.
Contexto 0: Todo serviço ao cliente (abastecimento, troca de óleo,

lavagem, etc.) É realizado pelo frentista. Para todo serviço realizado o
caixa deverá emitir uma Nota Fiscal (simples/paulista).
02-Requisito: SERVIÇO
• O frentista ao abastecer os veı́culos deve identificar. O abasteci-

mento. (Combustı́vel, Volume, Data Hora, Tipo Combustı́vel)
• Frentista deve lavar o veiculo (Data Hora, Tipo de Lavagem)
• Todo serviço gera uma nota fiscal, o caixa deve perguntar se o
cliente deseja a inclusão do CPF na nota.
0n-Requisito: GESTÃO
Em todo sistema comercial a gestão e do negócio é a parte mais impor-
tante e o motivo da implantação do sistema logo é neste momento que
devemos apresentar o maior nı́vel de detalhes. Devemos explicar até onde
vai a automação que se pretende fazer.
• Ao final do dia uma tela apresentará o volume vendido em cada

bomba.
• Ao receber combustı́vel, identica-lo com (data hora, tipo, tan-
que,...).
• ....
3.2. Diagrama de Entidade e Relacionamento DER
Com a Orientação a Objetos passamos a avaliar o fluxo de dados, a analise de dados
passa a fazer parte da Engenharia de Software (atividade fim na produção de software),
deixando de ser avaliada parte da Engenharia de Sistema (atividade que usa software na
modelagem de processos).
Um DER (Diagrama de Entidade e Relacionamento) é um artefato da Engenharia
de Software que permite uma visão de parte do banco de dados e modela de forma garantir
que todos os dados serão armazenado.
Com o uso da ferramenta de modelagem DBDesignerr , podemos representar em
diversas notações as caracterı́sticas de uma base de dados relacional figura 15
Figura 15. Visão de uma base de dados relacional usando DBDesigner4r
Na figura 15 temos um representação das tabelas gerado pelo DBDesignerr , den-

tro das tabelas os atributos com identificação da chave principal e as chaves estrangeiras.
Na parte de baixo das tabelas vemos uma descrição das relações entre as tabelas.
A grande vantagem do uso de um programa para a criação do DER é que é possı́vel
gerar automaticamente uma criação das tabelas no formato SQL conforme podemos ob-
servar nos anexos em Cod 2.
3.3. Validação do DER

O diagrama de Entidade e Relacionamento deve ser capaz de representar a guarda e
recuperação de todos os dados que serão objeto de manipulação no sistema em questão,
desta forma devemos tomar todo o cuidado para que os atributos estejam presentes no
modelo e possam ser recuperados.
Supondo o fraguento de DER da figura 16 poderı́amos criar um conjunto de dados
hipotético com as caracterı́stica da figura 17
Figura 16. Parte do modelo de dados de um posto de gasolina
Figura 17. Possı́vel configuração da base de dados da figura 16
Para atender aos requisitos o modelo deve estar apto a suportar a implementação
de funcionalidades para responder as perguntas:
1. Qual é o volume total de gasolina vendida no perı́odo?
2. Qual é o volume vendido por bomba no dia perı́odo
3. Lista de vendas por funcionário por dia.
4. Etc.
Então usando nosso conhecimento de álgebra relacional vamos responder:
1. Listar:
Da tabela VENDACOMBUSTIVEL
Projeção(Seleção.(dataVenda=perı́odo),Valor
P Total)
.......... lista.precoV enda ∗ litros
Resultado
V alorT otal = 2, 5 ∗ 20 + 2, 5 ∗ 40 + 1, 8 ∗ 50
2. Para cada BOMBA lista:
..........Da tabela VENDACOMBUSTIVEL
..........Projeção(Seleção(dataVenda=perı́odo),Bomba,Valor
P Total)
.................... lista.precoV enda ∗ litros
Resultado
Bomba1 = 2, 5 ∗ 20 + 2, 5 ∗ 40 + 1, 8 ∗ 50
Bomba2 = 1, 82 ∗ 30
3. Para cada FUNCIONÁRIO listar:

..........Da tabela VENDACOMBUSTIVEL
..........Projeção(Seleção(dataVenda=perı́odo),Bomba,Valor
P Total)
.................... lista.precoV enda ∗ litros
Resultado
F uncionario1 = 2, 5 ∗ 20 + 2, 5 ∗ 40 + 1, 8 ∗ 50
F uncionario2 = 1, 82 ∗ 30
Desta forma em tempo de análise é possı́vel validar se as relações que estamos

planejando são realmente importantes neste modelo.
Uma sugestão de atividade é de usando o DER da figura 15 fazer a analise para
todas as relações existentes criando perguntas que são relevantes para o negócio.
4. Interface de Acesso ao Banco
4.1. Interface do Netbeansr
Uma forma bastante comum de acessar o banco de dados é através da interface do próprio
Netbeansr . O código a seguir cria um usuário de nome grupo1 no Banco GRUPO01,
concedendo todos os direitos (código 1).
1 CREATE USER ’grupo1’@’%’ IDENTIFIED BY ’***’;

2
3 GRANT USAGE ON * . * TO ’grupo1’@’%’ IDENTIFIED BY ’***’
4 WITH MAX_QUERIES_PER_HOUR 0
5 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0 MAX_USER_CONNECTIONS 0 ;
6
7 GRANT ALL PRIVILEGES ON ‘GRUPO01‘ . * TO ’grupo1’@’%’;
Cod 1. Criação de Usuário no Banco GRUPO01
A configuração acontece na aba de serviços do Netbeans conforme ilustra a figura

18. Para este acesso estamos usanso a conexãop com JODBC que é um driver em puro
java que faz a conexção como o banco.
Figura 18. Tela de Configuração da Conexão MySQL Netbeans
Outra opção é o uso da interface web do PHP o phpMyAdminr , geralmente

este sistema funciona em Linuxr . A grande vantagem é que roda no servidor não sendo
necessário qualquer instalação na máquina local figura 19.
Figura 19. Tela do Chrome(Browser) com o PHPMyAdmin
Tanto o PHPMyAdmin quanto o plugin do Netbeans cumprem muito bem seu

objetivo que é básica mente a criação da estrutura funcional do banco de dado.
4.2. Java Database Connectivity (JDBC)
Java Database Connectivity ou JDBC é um conjunto de classes e interfaces (API) escritas
em Java que fazem o envio de instruções SQL para qualquer banco de dados relacional;
Api de baixo nı́vel e base para apis de alto nı́vel; Amplia o que você pode fazer com Java;
Possibilita o uso de bancos de dados já instalados; Para cada banco de dados há um driver
JDBC que pode cair em quatro categorias:
• Tipo 1 - Ponte JDBC-ODBC: É o tipo mais simples mas restrito à plataforma
Windows. Utiliza ODBC para conectar-se com o banco de dados, convertendo
métodos JDBC em chamadas às funções do ODBC. Esta ponte é normalmente
usada quando não há um driver puro-Java (tipo 4) para determinado banco de
dados, pois seu uso é desencorajado devido à dependência de plataforma.
• Tipo 2 - Driver API-Nativo: O driver API-Nativo traduz as chamadas JDBC
para as chamadas da API cliente do banco de dados usado. Como a Ponte JDBC-
ODBC, pode precisar de software extra instalado na máquina cliente.
• Tipo 3 - Driver de Protocolo de Rede: Traduz a chamada JDBC para um pro-
tocolo de rede independente do banco de dados utilizado, que é traduzido para o
protocolo do banco de dados por um servidor. Por utilizar um protocolo indepen-
dente, pode conectar as aplicações clientes Java a vários bancos de dados diferen-
tes. É o modelo mais flexı́vel e pode ser visto como um driver intermediário, pois
também atua como Middle Ware. É mais utilizado para banco de dados antigos
como estatais de governos.
• Tipo 4 - Driver nativo: Converte as chamadas JDBC diretamente no protocolo
do banco de dados. Implementado em Java, normalmente é independente de plata-
forma e escrito pelos próprios desenvolvedores. É o tipo mais recomendado para
ser usado.
5. Introdução ao SQL
5.1. Origem e Evolução da SQL
Podemos encontrar um breve relato da origem do padrão SQL em
http://pt.wikipedia.org/wiki/SQL :
Query Language, ou Linguagem de Consulta Estruturada ou SQL, é uma
linguagem de pesquisa declarativa para banco de dados relacional (base
de dados relacional). Muitas das caracterı́sticas originais do SQL fo-
ram inspiradas na álgebra relacional. O SQL foi desenvolvido original-
mente no inı́cio dos anos 70 nos laboratórios da IBM em San Jose, dentro
do projeto System R, que tinha por objetivo demonstrar a viabilidade da
implementação do modelo relacional proposto por E. F. Codd. O nome
original da linguagem era SEQUEL, acrônimo para Structured English
Query Language (Linguagem de Consulta Estruturada em Inglês), vindo
daı́ o fato de, até hoje, a sigla, em inglês, ser comumente pronunciada
sı́quel ao invés de és-kiú-él, letra a letra. No entanto, em português, a
pronúncia mais corrente é a letra a letra: ése-quê-éle.
A linguagem SQL é um grande padrão de banco de dados. Isto decorre da
sua simplicidade e facilidade de uso. Ela se diferencia de outras lingua-
gens de consulta a banco de dados no sentido em que uma consulta SQL
especifica a forma do resultado e não o caminho para chegar a ele. Ela é
uma linguagem declarativa em oposição a outras linguagens procedurais.
Isto reduz o ciclo de aprendizado daqueles que se iniciam na linguagem.
Embora o SQL tenha sido originalmente criado pela IBM, rapidamente
surgiram vários dialectos desenvolvidos por outros produtores. Essa ex-
pansão levou à necessidade de ser criado e adaptado um padrão para a
linguagem. Esta tarefa foi realizada pela American National Standards
Institute (ANSI) em 1986 e ISO em 1987. O SQL foi revisto em 1992
e a esta versão foi dado o nome de SQL-92. Foi revisto novamente em
1999 e 2003 para se tornar SQL:1999 (SQL3) e SQL:2003, respectiva-
mente. O SQL:1999 usa expressões regulares de emparelhamento, queries
recursivas e gatilhos (triggers). Também foi feita uma adição controversa
de tipos não-escalados e algumas caracterı́sticas de orientação a objeto.
O SQL:2003 introduz caracterı́sticas relacionadas ao XML, seqüências
padronizadas e colunas com valores de auto-generalização (inclusive
colunas-identidade). Tal como dito anteriormente, o SQL, embora pa-
dronizado pela ANSI e ISO, possui muitas variações e extensões produ-
zidos pelos diferentes fabricantes de sistemas gerenciadores de bases de
dados. Tipicamente a linguagem pode ser migrada de plataforma para
plataforma sem mudanças estruturais principais. Outra aproximação é
permitir para código de idioma procedural ser embutido e interagir com
o banco de dados. Por exemplo, o Oracle e outros incluem Java na base
de dados, enquanto o PostgreSQL permite que funções sejam escritas em
Perl, Tcl, ou C, entre outras linguagens.
5.2. Palavras-chaves em SQL
O texto a seguir é uma adptação do texto encontrado em
http://pt.wikipedia.org/wiki/SQL de autor anonimo.
5.2.1. DML - Linguagem de Manipulação de Dados
Primeiro há os elementos da DML (Data Manipulation Language - Linguagem de

Manipulação de Dados). A DML é um subconjunto da linguagem usada para inserir,
atualizar e apagar dados. INSERT é usada para inserir um registro (formalmente uma
tupla) a uma tabela existente. UPDATE para mudar os valores de dados em uma ou mais
linhas da tabela existente. DELETE permite remover linhas existentes de uma tabela.
5.2.2. DDL - Linguagem de Definição de Dados
O segundo grupo é a DDL (Data Definition Language - Linguagem de Definição de Da-

dos). Uma DDL permite ao utilizador definir tabelas novas e elementos associados. A
maioria dos bancos de dados de SQL comerciais tem extensões proprietárias no DDL. Os
comandos básicos da DDL são poucos CREATE cria um objeto (uma Tabela, por exem-
plo) dentro da base de dados. DROP apaga um objeto do banco de dados. Alguns sistemas
de banco de dados usam o comando ALTER, que permite ao usuário alterar um objeto,
por exemplo, adicionando uma coluna a uma tabela existente. outros comandos DDL:
• CREATE TABLE - Criação da estrutura de uma tabela.
• ALTER TABLE - Alteração da estrutura de um tabela.
• DROP TABLE - Exclusão da estrutura de um tabela.
• CREATE INDEX - Definição de uma chave de acesso permanente
• ALTER INDEX - Alteração de uma cahve de acesso (ı́ndice).
• DROP INDEX - Exclusão de umm ı́ndice.
• CREATE VIEW - Criação de uma visão de dado.
• ALTER VIEW - Alteração de uma visão de dado.
• DROP VIEW - Exclusão de uma visão de dado.
5.2.3. DCL - Linguagem de Controle de Dados
O terceiro grupo é o DCL (Data Control Language - Linguagem de Controle de Dados).

DCL controla os aspectos de autorização de dados e licenças de usuários para controlar
quem tem acesso para ver ou manipular dados dentro do banco de dados. Duas palavras-
chaves da DCL:
• GRANT - autoriza ao usuário executar ou setar operações.
• REVOKE - remove ou restringe a capacidade de um usuário de executar
operações.
outros comandos DCL:
• ALTER PASSWORD - Mudar uma password.
• CREATE SYNONYM - instrução CREATE SYNONYM é utilizada para forne-
cer um nome alternativo para uma tabela ou visão presente no mesmo esquema ou
em outro esquema.
5.2.4. DTL - Linguagem de Transação de Dados
BEGIN WORK (ou START TRANSACTION, dependendo do dialeto SQL) pode ser
usado para marcar o começo de uma transação de banco de dados que pode ser comple-
tada ou não. COMMIT envia todos os dados das mudanças permanentemente. ROLL-
BACK faz com que as mudanças nos dados existentes desde que o último COMMIT ou
ROLLBACK sejam descartadas. COMMIT e ROLLBACK interagem com áreas de con-
trole como transação e locação. Ambos terminam qualquer transação aberta e liberam
qualquer cadeado ligado a dados. Na ausência de um BEGIN WORK ou uma declaração
semelhante, a semântica de SQL é dependente da implementação.
5.2.5. DQL - Linguagem de Consulta de Dados
Embora tenha apenas um comando, a DQL é a parte da SQL mais utilizada. O comando
SELECT permite ao usuário especificar uma consulta (query) como uma descrição do re-
sultado desejado. Esse comando é composto de várias cláusulas e opções, possibilitando
elaborar consultas das mais simples às mais elaboradas. As cláusulas são condições de
modificação utilizadas para definir os dados que deseja selecionar ou modificar em uma
consulta.
Cláusulas
• FROM - Utilizada para especificar a tabela que se vai selecionar os registros.
• WHERE - Utilizada para especificar as condições que devem reunir os registros
que serão selecionados.
• GROUP BY - Utilizada para separar os registros selecionados em grupos es-
pecı́ficos.
• HAVING - Utilizada para expressar a condição que deve satisfazer cada grupo.
• ORDER BY - Utilizada para ordenar os registros selecionados com uma ordem
especifica.
• DISTINCT - Utilizada para selecionar dados sem repetição.
Operadores Lógicos
• AND - E lógico. Avalia as condições e devolve um valor verdadeiro caso ambos
sejam corretos.
• OR - OU lógico. Avalia as condições e devolve um valor verdadeiro se algum for
correto.
• NOT - Negação lógica. Devolve o valor contrário da expressão.
Operadores Relacionais
• < - Menor que
• > - Maior que
• <> - Diferente de
• <= - Menor ou Igual a
• >= - Maior ou Igual a
• = - Igual a
• BETWEEN - Utilizado para especificar um intervalo de valores.
• LIKE - Permite a utilização de expressões regulares simples.
Funções de Agregação
• AVG - Utilizada para calcular a media dos valores de um campo determinado.
• COUNT - Utilizada para devolver o número de registros da seleção.
• SUM - Utilizada para devolver a soma de todos os valores de um campo determi-
nado.
• MAX - Utilizada para devolver o valor mais alto de um campo especificado.
• MIN - Utilizada para devolver o valor mais baixo de um campo especificado.
Referê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.
Presman, R. S. (2005). Engenharia de Software. Makron Books, São Paulo.
6. ANEXOS
Código SQL para a criação de tabelas gerado automaticamente pelo DBDesignerr .
1 CREATE TABLE SIMULACAO (

2 idSIMULACAO INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
3 INICIO DATETIME NULL,
4 PRIMARY KEY(idSIMULACAO)
5 );
6
7 CREATE TABLE LOCALIDADE (
8 idLOCALIDADE INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
9 SIMULACAO_idSIMULACAO INTEGER UNSIGNED NOT NULL,
10 PRIMARY KEY(idLOCALIDADE),
11 INDEX LOCALIDADE_FKIndex1(SIMULACAO_idSIMULACAO)
12 );
13
14 CREATE TABLE ITERACAO (
15 idITERACAO INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
17 NRO_ITERACAO INTEGER UNSIGNED NULL,
18 INICIO DATETIME NULL,
19 TERMINO DATETIME NULL,
20 PRIMARY KEY(idITERACAO),
21 INDEX ITERACAO_FKIndex1(SIMULACAO_idSIMULACAO)
22 );
23
24 CREATE TABLE AGENTE (
25 idAGENTE INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
27 PRIMARY KEY(idAGENTE),
28 INDEX AGENTE_FKIndex1(SIMULACAO_idSIMULACAO)
29 );
30
31 CREATE TABLE CONFIGURACAO (
32 idCONFIGURACAO INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
34 QTD_PASSOS_PROCURA INTEGER UNSIGNED NULL,
35 PROB_ATRACAO FLOAT NULL,
36 DELAY INTEGER UNSIGNED NULL,
37 FATOR_ATRACAO_PRISAO_POLICIAL INTEGER UNSIGNED NULL,
38 FATOR_ATRACAO_PRISAO_BANDIDO INTEGER UNSIGNED NULL,
39 FATOR_ATRACAO_PRISAO_TRASEUNTES INTEGER UNSIGNED NULL,
40 FATOR_ATRACAO_ASSALTO_POLICIAL INTEGER UNSIGNED NULL,
41 FATOR_ATRACAO_ASSALTO_BANDIDO INTEGER UNSIGNED NULL,
42 FATOR_ATRACAO_ASSALTO_TRANSEUNTE INTEGER UNSIGNED NULL,
43 FATOR_INCREMENTO_ASSALTO INTEGER UNSIGNED NULL,
44 FATOR_INCREMENTO_PRISAO INTEGER UNSIGNED NULL,
45 FATOR_DECREMENTO_ASSALTO INTEGER UNSIGNED NULL,
46 FATOR_DECREMENTO_PRISAO INTEGER UNSIGNED NULL,
47 PRIMARY KEY(idCONFIGURACAO),
48 INDEX CONFIGURACAO_FKIndex1(SIMULACAO_idSIMULACAO)
49 );
50
51 CREATE TABLE REPUTACAO (
52 idREPUTACAO INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
53 ITERACAO_idITERACAO INTEGER UNSIGNED NOT NULL,
54 LOCALIDADE_idLOCALIDADE INTEGER UNSIGNED NOT NULL,
55 PRIMARY KEY(idREPUTACAO),
56 INDEX REPUTACAO_FKIndex1(LOCALIDADE_idLOCALIDADE),
57 INDEX REPUTACAO_FKIndex2(ITERACAO_idITERACAO)
58 );
59
60 CREATE TABLE POSICAO (
61 idPOSICAO INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
62 AGENTE_idAGENTE INTEGER UNSIGNED NOT NULL,
63 ITERACAO_idITERACAO INTEGER UNSIGNED NOT NULL,
64 PRIMARY KEY(idPOSICAO),
65 INDEX POSICAO_FKIndex1(ITERACAO_idITERACAO),
66 INDEX POSICAO_FKIndex2(AGENTE_idAGENTE)
67 );
68
69
Cod 2. Criação de Tabelas em SQL

Livro DB

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Livro DB

Загружено:

Авторское право:

Доступные форматы

Banco de Dados

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

1 Sistema de Gerenciamento de banco de dados 3

4 Interface de Acesso ao Banco 18

Figura 1. Partes de um software

(a) Representação em Estru-

Figura 2. Formas de Representação de Tabelas

(a) Tabela Aluno (b) Projeção

Figura 3. Calculo de uma Projeção

Figura 4. Seleção dos alunos da computação

• Produto Cartesiano e Junção Natural - A função do Produto Cartesiano em

Figura 5. Junção Natural de duas Entidades

2.3. Normalização de Dados

Figura 6. Nota fiscal simplificada

Como primeira atividade devemos identificar as entidades que estão presentes

Figura 7. Evolução do Processo de Normalização de Entidades

A próxima etapa é definir as chaves estrangeiras ou em outras pala-

Figura 8. Definição das chaves estrangeiras e as relações

(a) IDEF0 - Clinica Médica (b) IDEF1 - Clinica Médica

Figura 9. Diagrama de Contexto

2.6.1. Relação Hierárquica

Figura 10. Representação de uma Relação Hierárquica

2.6.2. Relação Simétrica

Figura 11. Problema na Relação simétrica

Novamente deixamos o programa DBDesignerr tomar a decisão e ao criarmos a

Figura 12. Relação Simétrica Fornecedor x Produto

2.6.3. Relação Recursiva

Finalmente podemos definir uma relação de recursividade com a inclusão de um atributo

Figura 13. Relação Recursiva

3.1. Dado ou Processo

responsabilidades: O gerente do posto (cadastros e controle dos proces-

Contexto 0: Os cadastros do sistema devem ser feitos pelo gerente.

Contexto 0: Todo serviço ao cliente (abastecimento, troca de óleo,

• O frentista ao abastecer os veı́culos deve identificar. O abasteci-

• Ao final do dia uma tela apresentará o volume vendido em cada

Figura 15. Visão de uma base de dados relacional usando DBDesigner4r

Na figura 15 temos um representação das tabelas gerado pelo DBDesignerr , den-

3.3. Validação do DER

Figura 16. Parte do modelo de dados de um posto de gasolina

Figura 17. Possı́vel configuração da base de dados da figura 16

3. Para cada FUNCIONÁRIO listar:

Desta forma em tempo de análise é possı́vel validar se as relações que estamos

1 CREATE USER ’grupo1’@’%’ IDENTIFIED BY ’***’;

Cod 1. Criação de Usuário no Banco GRUPO01

A configuração acontece na aba de serviços do Netbeans conforme ilustra a figura

Figura 18. Tela de Configuração da Conexão MySQL Netbeans

Outra opção é o uso da interface web do PHP o phpMyAdminr , geralmente

Figura 19. Tela do Chrome(Browser) com o PHPMyAdmin

Tanto o PHPMyAdmin quanto o plugin do Netbeans cumprem muito bem seu

5.2.1. DML - Linguagem de Manipulação de Dados

Primeiro há os elementos da DML (Data Manipulation Language - Linguagem de

5.2.2. DDL - Linguagem de Definição de Dados

O segundo grupo é a DDL (Data Definition Language - Linguagem de Definição de Da-

5.2.3. DCL - Linguagem de Controle de Dados

O terceiro grupo é o DCL (Data Control Language - Linguagem de Controle de Dados).

5.2.5. DQL - Linguagem de Consulta de Dados

1 CREATE TABLE SIMULACAO (

Cod 2. Criação de Tabelas em SQL

Вам также может понравиться