Apostila_BD

Prévia do material em texto

1
CURSO SUPERIOR
DE FORMAÇÃO ESPECÍFICA
EM INFORMÁTICA EMPRESARIAL
COM MÍDIAS INTERATIVAS
DISCIPLINA: BANCO DE DADOS
SUPERVISORA : MARIA SALETE MARCON GOMES VAZ
PROFESSORES :
JOSÉ SIMÃO DE PAULA PINTO
LUCÉLIA DE SOUZA
LUCIANO MATHIAS DÖLL
MARIA SALETE MARCON GOMES VAZ
SCILAS BARBOSA DE SOUZA
2
SUMÁRIO
1 INTRODUÇÃO...................................................................................................................4
2 SISTEMA DE GERENCIAMENTO DE BANCO DE DADOS - SGBD......5
2.1 Objetivos dos SGBDs....................................................................................................... 5
2.2 Conceitos Gerais............................................................................................................... 6
2.3 Arquitetura de Banco de Dados........................................................................................ 9
2.4 Administrador de Banco de Dados – DBA.....................................................................10
2.5 Evolução dos sistemas de arquivos para sgbd relacional................................................10
2.6 Exercícios de Revisão com Respostas............................................................................ 12
2.7 Considerações do Capítulo............................................................................................. 13
3 MODELAGEM DE BANCO DE DADOS................................................................14
3.1 Projeto de Banco de Dados............................................................................................. 14
3.2 Modelagem Entidade/Relacionamento........................................................................... 15
3.3 Modelagem Relacional................................................................................................... 17
3.4 Mapeamento Entidade/Relacionamento para o Relacional............................................ 20
3.5 Exercícios de Revisão com Respostas............................................................................ 23
3.6 Considerações do Capítulo............................................................................................. 26
4 IMPLEMENTAÇÃO DE BANCO DE DADOS..................................................... 27
4.1 Linguagem SQL..............................................................................................................29
4.2 Comandos para definição de dados.................................................................................29
4.3 Comandos para Manipulação de dados...........................................................................33
4.4 Gerenciamento de acesso................................................................................................40
4.5 Exercícios de Revisão com Respostas............................................................................ 41
3
4.6 Considerações do Capítulo............................................................................................. 45
5 CONSIDERAÇÕES FINAIS............................................................................47
BIBLIOGRAFIA............................................................................................................48
4
1 INTRODUÇÃO
Atualmente, está ocorrendo uma mudança fundamental na forma como as empresas
usam os dados. Não basta apenas automatizar transações, é necessário usar a
informação inerente aos dados, para monitorar e analisar as operações empresariais,
projetando necessidades futuras e fornecendo um diferencial competitivo.
O objetivo deste trabalho é introduzir aos alunos os conhecimentos
fundamentais necessários para que sejam bem sucedidos no projeto,
desenvolvimento e implementação de banco de dados empresariais, trabalhando em
grupo ou individualmente. Um banco de dados empresarial é uma coleção de
quaisquer dados que possam afetar ou serem afetados por decisões no interior da
empresa, ou seja, é um modelo da realidade percebida pela empresa.
Os dados empresariais podem ser formais (armazenados em um banco de
dados) ou informais (experiências profissionais dos membros da organização).
Também podem estar estruturados (em forma tabular) ou desestruturados (em
cartas e memorandos). Para alavancar o investimento em tecnologia de informação,
é preciso a conversão dos dados relevantes para um formato estruturado e formal,
para que compartilhe informações por toda a empresa.
Com a finalidade de descrever todo esse processo de estruturação e
formalização dos dados, este documento está organizado como segue. No Capítulo
2 é apresentada uma visão geral de Sistemas de Gerenciamento de Banco de
Dados. No Capítulo 3, aspectos de modelagem de dados são apresentados, além
dos modelos Entidade/Relacionamento e Relacional, incluindo o mapeamento de um
para o outro. No Capítulo 4, a implementação de aplicações de banco de dados é
abordada, incluindo a Linguagem de Banco de Dados SQL, para criação,
manipulação e consulta à base. Finalmente, no Capítulo 5 são feitas as
considerações finais deste material.
5
2 SISTEMA DE GERENCIAMENTO DE BANCO DE DADOS - SGBD
Os sistemas de bancos de dados estão no centro de todas as tomadas de decisões
das organizações empresariais atualmente. Eles surgiram por volta dos anos 60
para gerenciarem grandes quantidades de dados e da necessidade de estruturar
esses dados e fornecer rotinas padronizadas de acesso.
Um Sistema Gerenciador de Banco de Dados – SGBD é “um programa, ou
um conjunto de programas que controlam todos os aspectos de um Banco de Dados,
como a declaração da estrutura de dados, gravação e leitura dos dados,
recuperação de falhas na comunicação ou no meio da gravação, controles de
concorrência, de acesso e segurança dos dados, dentre outros”. Ou seja, pode ser
definido como “um conjunto de programas utilizados para definir, administrar e
processar o banco de dados e suas aplicações”. Uma aplicação de banco de dados
é um programa que permite recuperar, ver e atualizar as informações armazenadas
pelo SGBD. O banco de dados em conjunto com as aplicações que o manipulam é
chamado de Sistema de Banco de Dados.
Concluindo, o Sistema de Gerenciamento de Banco de Dados corresponde a
uma coleção de programas que controlam todos os aspectos de banco de dados e
esse corresponde a uma coleção de dados ou informações inter-relacionadas.
2.1 OBJETIVOS DOS SGBDS
O objetivo principal de um SGBD é prover um ambiente que seja conveniente e
eficiente para uso na recuperação e no armazenamento da informação. A seguir
alguns aspectos que o SGBD precisa eliminar ou reduzir:
(i) Redundância e Inconsistência de dados – As informações em
arquivos pode ser repetida em diversos lugares. Por exemplo, o
endereço de um cliente pode aparecer em arquivos diferentes. Essa
redundância aumenta os custos de armazenamento e acesso aos
dados, podendo ocasionar inconsistência de dados. Pode ser
modificado o endereço do cliente num arquivo e não alterar no outro.
O controle da redundância permite a garantia de consistência. E
também existindo redundância dificulta o acesso aos dados.
6
(ii) Isolamento dos Dados – como os dados estão em vários arquivos e
que podem estar em diferentes formatos, é difícil escrever novas
aplicações para recuperação apropriada dos dados. É necessário
permitir o compartilhamento dos dados.
(iii) Anomalias de acesso concorrente – quando os dados podem sofrer
acesso de diferentes programas, o sistema deve ser bem coordenado
para que não ocorram erros ou consultas de dados com resultados
inconsistentes.
(iv) Problemas de segurança - é necessário fornecer cópias (back-up) e
permitir a recuperação de dados no caso de acesso não autorizados
aos dados. O sistema deve permitir que todos os usuários de banco de
dados estejam autorizados ao acesso aos dados.
2.2 CONCEITOS GERAIS
Um banco de dados pode ser definido como “uma coleção de dados estruturada,
sendo que os dados contêm informações sobre um empreendimento particular”,ou
ainda, “um conjunto de dados ordenados logicamente”.
Figura 1: Visão Geral de um SGBD
O banco de dados representa algum aspecto do mundo real (Figura 1),
chamado “mini-mundo”, sendo que qualquer alteração feita no mini-mundo é refletida
no banco de dados de forma automática. O SGBD é quem permite ao usuário criar e
manter o banco de dados.
7
Abstração de dados
Os SGBDs simplificam a interação dos usuários com o sistema, pois fornecem uma
visão abstrata dos dados, ou seja, escondem como os dados são armazenados,
como também permitem que os dados sejam recuperados de forma rápida e
eficiente.
Modelo de Dados
O Modelo de Dados é uma coleção de ferramentas conceituais para descrição das
estruturas lógicas e físicas dos dados, os relacionamentos entre eles, a semântica
dos dados e restrições de consistência. O modelo de dados pode ser físico ou lógico.
O modelo de dados físico fornece uma visão mais detalhada de como os dados
estão armazenados. Os modelos lógicos podem ser baseados em registros ou em
objetos.
Os modelos lógicos baseados em registros são classificados em hierárquico,
em rede e relacional. E os modelos lógicos baseados em objetos são:
Entidade/Relacionamento (E/R), semânticos e orientados a objetos.
Esquemas
Um esquema é o projeto geral do banco de dados, a estrutura lógica da base de
dados.
Instâncias
As instâncias são a coleção de dados armazenados na base de dados em um
determinado instante de tempo. O SGBD deve garantir que toda instância satisfaça
ao esquema de banco de dados, conforme sua estrutura e restrições.
Linguagens de Banco de Dados
Linguagens são utilizadas para a comunicação com os gerenciadores de bancos de
dados. Dependendo do gerenciador em questão a linguagem pode ser proprietária
ou seguir um padrão, podendo ser estruturada para conjuntos ou orientada a objetos.
A linguagem deverá possibilitar a manipulação de todos os aspectos relativos
ao funcionamento de um banco de dados:
 Criação e/ou vinculação de um local físico para o banco de dados;
8
 Criação do banco de dados;
 Criação de tabelas e alteração de suas características;
 Manipulação de tabelas, no sentido de incluir, alterar e excluir dados;
 Recuperação de dados e mecanismos de agregação e classificação dos
resultados obtidos;
 Controle de aspectos de segurança, incluindo a criação de contas de
usuários (par identificação/senha) e gerenciamento de permissões (leitura,
gravação, alteração e destruição de objetos);
 Mecanismos para geração e recuperação de cópias de segurança (back-
up);
 Mecanismos para controle de utilização (geração de "log").
As linguagens são classificadas em:
 Linguagem de Definição de Dados – DDL, que especifica o esquema do
banco de dados.
 Linguagem de Manipulação de Dados - DML, que especifica a
manipulação dos dados organizados por um modelo de dados apropriado.
 Linguagem de Consulta – QL, que é uma porção da linguagem de
manipulação que envolve a recuperação de informações.
 Linguagem de 4a Geração, que combina estruturas de controle de
linguagens de programação com estruturas para manipulação de
elementos de um banco de dados.
A não existência de uma ou mais das características citadas compromete o
gerenciamento do SGBD e dos bancos de dados nele inseridos.
Transação
Uma transação é a execução de um programa que acessa ou modifica o conteúdo
de um banco de dados. As transações também podem ser definidas como
“representações de eventos”.
Quando os eventos ocorrem, suas transações devem ser processadas junto
ao banco de dados. Para tanto, é preciso ativar o programa de processamento da
transação e entrar com os dados da transação. O programa, então, chama o SGBD
para alterar a base de dados. Os programas de processamento das transações
9
geralmente mostram ou imprimem respostas, como confirmação de pedidos ou
recibo.
As propriedades desejáveis das transações (propriedades ACID) são:
 ATOMICIDADE: ou a transação foi ou não foi executada.
 CONSISTÊNCIA: execução de uma transação deve deixar o banco de
dados em um estado consistente.
 ISOLAMENTO: a não disponibilidade dos dados até que a transação seja
efetivada (concluída).
 DURABILIDADE: garante que os dados em uma transação serão
efetivados e não perdidos.
2.3 ARQUITETURA DE BANCO DE DADOS
Arquitetura ANSI/SPARC
A arquitetura ANSI/SPARC (Figura 2), é definida em três níveis:
 NÍVEL FÍSICO (interno): descreve como um registro é armazenado
 NÍVEL LÓGICO (conceitual): descreve dados armazenados no banco de
dados e os relacionamentos entre os dados
 NÍVEL DE VISÃO (externo): programas de aplicação escondem detalhes
dos tipos de dados
Figura 2: Arquitetura ANSI/SPARC
10
Independência de Dados
Habilidade de modificar a definição de um esquema em um nível sem afetar a
definição do esquema em um nível mais alto. Dois tipos de independência de dados
são considerados:
 Independência Física – capacidade de alterar o nível físico sem precisar
alterar o nível lógico e o nível de visão.
 Independência Lógica – capacidade de alterar o nível lógico sem precisar
alterar o nível de visão.
2.4 ADMINISTRADOR DE BANCO DE DADOS – DBA
O Administrador de Banco de Dados – DBA (DataBase Administrator) é a pessoa ou
grupo de pessoas “responsáveis pelo estabelecimento de regras e procedimentos
para controlar e proteger um banco de dados”. Ele trabalha segundo diretrizes
definidas pela administração de dados para controlar a estrutura do banco de dados,
gerenciar as modificações nos dados e conservar os programas do SGBD.
2.5 EVOLUÇÃO DOS SISTEMAS DE ARQUIVOS PARA SGBD RELACIONAL
Os Bancos de Dados, conforme Figura 3, evoluíram a partir dos Gerenciadores de
Arquivos, os quais não contavam com uma linguagem de consulta padrão.
Posteriormente, surgiram os SGBDs relacionais (a ser visto no próximo capítulo) os
quais possuem uma linguagem de consulta padrão, Structured Query Language –
SQL (Seção 4.1). Com relação ao tipo de dados, ambos tratam de dados simples.
Figura 3: Evolução dos Sistemas de Arquivos para SGBDs Relacionais.
Sem consulta
Com consulta
Dados Simples
GERENCIADOR DE ARQUIVOS
SGBD RELACIONAL
11
A seguir tem-se uma descrição quanto aos aspectos inerentes de cada sistema
citado nos quadrantes da Figura 3:
Gerenciador de Arquivos
 Bom desempenho
 Inconsistência
 Redundância e Replicação
 Segurança
 Integridade
 Isolamento dos dados
 Dificuldade de acesso aos dados
 Anomalias no acesso concorrente
Como exemplos de gerenciadores de arquivos pode-se citar o uso em Linguagem de
programação como COBOL e PL1.
SGBDs Relacionais
 Pobre semanticamente
 Linguagem de consulta
 Segurança
 Ferramentas de interfaces
 Aplicação Comercial
 Dados representados segundo tabelas
 Modelo formal apoiado na teoria dos conjuntos
 Tecnologia relacional
Como exemplos de Sistemas Gerenciadores de Banco de Dados Relacionais pode-
se citar DB2, INFORMIX, SYBASE, INGRES.
12
2.6 EXERCÍCIOS DE REVISÃO COM RESPOSTAS
1. Defina o que é um Sistema de Gerenciamento de Banco de Dados.
Um sistema de gerenciamento de banco de dados (SGBD) é uma coleção de dados
inter-relacionados e uma coleção de programas para acesso a esses dados.
2. Defina banco de dados e SGBD (explique também seus objetivos).
O banco de dados constitui de uma coleção de dados que representam aspectos do
mundo real com semântica própria e que se deseja armazenar para recuperação
futura. O Sistema de gerenciamento de banco de dados constitui de uma coleção de
programas que manipula o banco de dados. O objetivo principal de um sistema de
banco de dados é proporcionar aos usuários uma visão abstrata dos dados. Isto é, o
sistema esconde determinados detalhes de como os dados são mantidos e como
estão armaze3nadops. Isto é feito por meio da definição de três níveis de abstração
de dados, os quais podem ser vistos como: nível físico, nível lógico e os níveis de
visão.
3. De uma forma geral, explique o que é Modelo de Dados.
Sob aestrutura do banco de dados está o modelo de dados, que corresponde a um
conjunto de ferramentas conceituais para descrição dos dados, relacionamento entre
os dados, semântica dos dados e suas restrições. A modelagem de dados
corresponde a uma abstração do mundo real contendo o conjunto de informações
desse mundo que se julga importante armazenar e manipular.
4. Defina esquema e instância.
Um esquema corresponde à especificação dos dados de um banco de dados. É
importante distinguir o esquema de um banco de dados, que reflete o projeto e a
especificação dos dados, do conteúdo específico do Banco, que é chamado de
instância do banco de dados, que normalmente é variável no tempo.
13
2.7 CONSIDERAÇÕES DO CAPÍTULO
O gerenciamento de dados tornou-se uma das atividades mais importantes em
muitas organizações. A sociedade está cada vez mais orientada para a informação,
e assim uma determinação de como organizar os dados para maximizar sua
utilidade.
Sistemas de banco de dados baseados em computador simplificam a tarefa
de manter e recuperar uma grande quantidade de dados. Neste capítulo foram
descritos os conceitos inerentes a bancos de dados, os sistemas que os manipulam
e o modelo de dados para definição dos dados, relacionamentos entre eles,
semântica e restrições de integridade.
Na Figura 4 são representados os principais conceitos inerentes a Banco de
dados.
Figura 4: Dados, Banco de Dados, SGBD e Modelo de Dados
No banco de dados são armazenados os dados, que são gerenciados pelo Sistema
Gerenciador de Banco de dados, mas que foram organizados segundo um modelo
de dados.
No próximo capítulo são descritos os modelos Entidade/Relacionamento e
Relacional. Também, o mapeamento necessário de um para o outro.
Gerencia
Organiza
Armazena
Dados Banco de
Dados
Sistema Gerenciador de
Banco de Dados
Modelo de
Dados
14
3 MODELAGEM DE BANCO DE DADOS
A modelagem de dados é uma atividade desenvolvida em fases variadas do
processo metodológico de desenvolvimento de sistemas, com a finalidade de
garimpar informações para a obtenção do modelo de dados.
Um modelo de dados a nível macro pode ser obtido em fases de
planejamento, por exemplo, enquanto modelos de dados detalhados podem ser
obtidos em fases de análise e projeto. Tudo depende do foco que se deseja aplicar
ao trabalho de levantamento e seus objetivos.
3.1 PROJETO DE BANCO DE DADOS
Um dos aspectos mais importantes no projeto de banco de dados é, na realidade,
um exercício de simulação de um pedaço do universo da empresa. Essa simulação
visa transformar um universo nebuloso que representa a realidade da empresa em
um universo semanticamente entendido por conceitos de modelagem de dados. O
modelo de dados é a representação gráfica e textual das estruturas, dos operadores
e das regras que definem dados. Na seção seguinte será tratado o modelo
conceitual E/R.
Figura 5: Esquema Entidade/Relacionamento
1
N
1
N
11
M
N1
N
N
1
EMPREGADO DEPARTAMENTO
PROJETO
CONTROLA
TRABALHA
POSSUI
DESENVOLVE
GERENCIA
CHEFIA
subordinado
chefe
 DEPENDENTE 
code
nome
nomedp
datan
horas
datai
codd nomd
nompcodp
fone
15
3.2 MODELAGEM ENTIDADE/RELACIONAMENTO
A técnica de modelagem de dados mais difundida é a abordagem
entidade/relacionamento (E/R). Os conceitos básicos da abordagem E/R são:
entidade, relacionamento e atributo.Os conceitos serão apresentados juntamente
com a notação gráfica originalmente introduzida por Peter Chen, em 1976.
Para explicar os conceitos da Modelagem E/R vamos usar uma aplicação simples de
um sistema empresarial, que possui empregados, seus dependentes, departamentos
e projetos. Este módulo está representado graficamente na Figura 5.
3.2.1 Entidade
Uma entidade corresponde ao conjunto de objetos da realidade modelada sobre os
quais deseja-se manter informações no banco de dados. Uma entidade é
representada através de um retângulo que contém o nome da entidade. Na Figura 5
são apresentadas quatro entidades (EMPREGADO, DEPARTAMENTO,
DEPENDENTE e PROJETO).
O retângulo EMPREGADO designa o conjunto de todos os empregados sobre
os quais se deseja manter informações no banco de dados. Já o retângulo
DEPARTAMENTO corresponde ao conjunto de todos os departamentos da empresa.
E o retângulo PROJETO representa o conjunto de todos os projetos que se deseja
manter informações no banco de dados.
No caso da entidade DEPENDENTE que está representada por duplo
retângulo, designa que a entidade é fraca, isto é, ela não pode ser identificada
somente pelos seus atributos. Esta entidade depende da entidade proprietária
EMPREGADO.
Caso se deseja referir a um objeto particular (um determinado empregado ou
determinado departamento) fala-se em uma entidade e não um conjunto de
entidades.
3.2.2 Atributo
Um atributo corresponde ao dado que é associado a cada ocorrência de uma
entidade ou de um relacionamento. Segundo a Figura 5, podemos citar os atributos
16
da Entidade DEPARTAMENTO, codd e nomd, que correspondem ao número e o
nome do departamento, respectivamente.
Também existem atributos de relacionamento. Pode ser exemplicado pelo
atributo horas no Relacionamento DESENVOLVE.
Cada entidade deve possuir um identificador. Um identificador é um conjunto de um
ou mais atributos (e possivelmente relacionamentos) cujos valores servem para
distinguir uma ocorrência da entidade das demais ocorrências da mesma entidade.
O atributo codd na Entidade DEPARTAMENTO identifica unicamente um
departamento da empresa. Não poderão existir dois departamentos com o mesmo
número.
3.2.3 Relacionamento
Um relacionamento corresponde ao conjunto de associações entre entidades. Um
relacionamento é representado graficamente através de um losango, ligado por
linhas aos retângulos representativos das entidades que participam do
relacionamento. Na Figura 5 são apresentados relacionamentos denominados
CHEFIA, TRABALHA, GERENCIA, POSSUI, CONTROLA E DESENVOLVE. Em
cada um dos relacionamentos existem entidades participantes.
O relacionamento TRABALHA, por exemplo, expressa que o banco de dados
manterá informações sobre um conjunto de objetos classificados como empregados
(Entidade EMPREGADO), um conjunto de objetos classificados como
departamentos (Entidade DEPARTAMENTO) e um conjunto de associações, cada
uma ligando um empregado a um departamento (Relacionamento TRABALHA).
Não necessariamente um relacionamento associa entidades diferentes. Na
Figura 5 contém um auto-relacionamento, isto é, um relacionamento entre
ocorrências de uma mesma entidade. Neste caso, é necessário um conceito
adicional, o de papel da entidade no relacionamento. O papel de uma entidade em
um relacionamento define que função uma ocorrência da entidade cumpre dentro de
uma ocorrência do relacionamento.
17
No caso de relacionamento de CHEFIA, uma ocorrência de empregado
exerce o papel de chefe e a outra ocorrência o papel de subordinado. Papéis são
anotados no Diagrama E/R como mostrado na Figura 5.
No Esquema E/R, existe a cardinalidade de relacionamento, que corresponde
ao número de entidades que podem estar associadas via relacionamento. Existem
três tipos: 1:1 (um para um), 1:N (um para muitos), N:M (muitos para muitos).
Através do Esquema Entidade/Relacionamento da Figura 5, um
relacionamento 1:1 é o GERENCIA, que associa que um empregado (Entidade
EMPREGADO) gerencia um departamento (Entidade DEPARTAMENTO), e que
esse só pode ser gerenciado por um empregado. Já um relacionamento 1:N,
CONTROLA, que associa que um departamento (Entidade DEPARTAMENTO)
controla muitos projetos (Entidade PROJETO), mas um projeto só pode ser
controlado por um departamento. No relacionamento N:M, DESENVOLVE, associa
que vários empregados desenvolvem um projeto, mas um projeto pode ser
desenvolvido por vários empregados e para tanto tem uma carga horária como
atributo de relacionamento (horas).
3.3 MODELAGEM RELACIONAL
O modelo Relacional foi definido E. F Cood, em 1970. A grande aceitação comercial
foi apartir de meados da década de 80. As razões dessa grande aceitação foram
simplicidade dos conceitos básicos e poder dos operadores de manipulação.
O modelo relacional representa e processa dados na forma de tabelas
chamadas relações. As colunas da tabela são chamadas atributos e as linhas, tuplas.
Os termos tabela, coluna e linha e arquivo, campo e registro são usados,
respectivamente, como sinônimos dos termos relação, atributo e tupla.
O termo chave pode ser utilizado tanto nas fases de projeto quanto da
implementação. Durante o projeto, significa a chave lógica, que é um ou mais
atributos que identificam de forma única uma linha. Na implementação, o termo está
relacionado a uma chave física, que é uma estrutura de dados usada para melhorar
o desempenho do banco de dados. Uma chave lógica pode ou não ser uma chave
física e vice-versa. Geralmente, chave representa a chave lógica e índice representa
a chave física.
18
O esquema relacional corresponde ao conjunto de relações semanticamente ligadas
por seus domínios de definição. O conceito de relação permite ao mesmo tempo
representar uma entidade e uma relação semântica (relacionamento) do Esquema
Entidade/Relacionamento.
Figura 6: Conceitos de Modelagem Relacional
A Figura 6 será usada para descrever alguns conceitos de modelagem relacional
que são apresentados na seqüência. Um banco de dados relacional é composto de
tabelas ou relações, atributos, chaves primária, candidata e estrangeira, domínio,
restrições de integridade.
3.3.1 Tabelas ou Relações
Uma tabela é um conjunto não ordenado de linhas (tuplas). Cada linha é composta
por uma série de campos (valor de atributo). Cada campo é identificado por um
nome de campo (nome do atributo).
Chave Primária
Código Nome CPF Número
0101 João 1212345 001
0035 José 1234567 002
.
.
.
0987 Pedro 567489
Curitiba
Atributos
Tuplas
EMPREGADO
Chave Candidata
Chave Estrangeira
19
3.3.2 Atributos
Um atributo explicita o papel de um domínio em uma relação. Os atributos de uma
mesma relação devem ser diferentes. O conceito básico para identificar linhas e
estabelecer relações entre linhas de tabelas de um banco de dados relacional é o de
chave. Existem três tipos de chaves a considerar: primária, alternativa (candidata) e
estrangeira.
 Chave Primária: é uma coluna ou combinação de colunas cujos valores
distinguem uma linha das demais dentro de uma tabela. Na Figura 6, a chave
primária da Relação Empregado é o código do empregado. Cada
empregado tem um código que o identifica unicamente dentro da Relação
Empregado.
 Chave Candidata (ou alternativa): mais de um atributo ou combinações de
atributos podem servir para distinguir uma linha das demais. Um dos atributos
(ou combinação de atributos) é escolhido como chave primária. Os demais
atributos são chaves candidatas. No caso da Relação Empregado a chave
primária é código e a chave candidata é CPF. O CPF pode identificar também
unicamente um empregado.
 Chave Estrangeira: é um atributo ou uma combinação de atributos, cujos
valores aparecem necessariamente na chave primária de uma outra relação.
A chave estrangeira é o mecanismo que permite a implementação de
relacionamentos em um banco de dados relacional. A chave estrangeira
número corresponde a chave primária da Relação Departamento. Assim,
podemos com a relação Empregado estabelecer que o empregado trabalha
em um departamento. Os passos de transformação do Esquema
Entidade/Relacionamento são mostrados na Seção 2.9.
3.3.3 Domínio
Um domínio representa um conjunto de valores atômicos admissíveis dos atributos.
Dois valores de atributos só podem ser comparados se definidos sobre o mesmo
domínio. Por exemplo, o atributo FONE é definido sobre o domínio dos inteiros.
20
3.3.4 Restrições de Integridade
As restrições de integridade são classificadas em: restrições de domínio, de entidade
e referencial.
 Restrição de Domínio: diz respeito ao controle sintático e semântico de um
dado e faz referência ao tipo de definição do domínio.
 Restrição de Entidade: diz respeito aos valores de chave primária que
devem ser únicos e não nulos.
 Referencial: diz respeito aos valores de um atributo chave estrangeira e os
valores do atributo chave primária devem ser correspondentes.
3.4 MAPEAMENTO ENTIDADE/RELACIONAMENTO PARA O RELACIONAL
O mapeamento (transformação) do Esquema Entidade/Relacionamento para o
Esquema Relacional pode ser feito em sete passos. Para mostrar os passos de
transformação, utilizaremos o Esquema E/R da Figura 5.
Figura 7: Esquema Relacional
O esquema relacional da Figura 7, que corresponde exatamente ao Esquema
Entidade/Relacionamento mapeado. Para se chegar neste esquema alguns passos
EMPREGADO
DEPARTAMENTO
FONE_DEPARTAMENTO
PROJETO
DESENVOLVE
DEPENDENTE
code nome codd codc
Codd fone
codp nomp codd
code codp horas
code nomedp datan
codd nomd code datai
21
foram seguidos. Eis os passos necessários para mapeamento E/R para o
Relacional.
PASSO 1: Para cada entidade não fraca no esquema E/R, criar uma relação que
inclui todos os atributos não multivalorados da entidade do Esquema E/R.
Neste passo foram criadas as relações EMPREGADO(cod,nome),
PROJETO(número,nome) e DEPARTAMENTO(numero,nome) com os atributos
correspondentes de cada entidade. Vale ressaltar que o atributo fone não foi
colocado neste passo para a relação DEPARTAMENTO tendo em vista que é um
atributo multi-valorado e vai ser tratado no Passo 6.
PASSO 2: Para cada entidade fraca no esquema E/R que tenha uma entidade
proprietária: (i) criar uma relação e incluir todos os atributos da entidade fraca; (ii)
incluir o(s) atributo(s) chave primária da entidade proprietária; e (iii) a chave primária
da relação resultante é a combinação da chave primária da entidade proprietária
com a chave primária de entidade fraca.
A entidade fraca no Esquema E/R é DEPENDENTE. A entidade proprietária
EMPREGADO possui como chave primária code. Assim a relação resultante será
Dependente com chave primária sendo a combinação do nome do dependente
(nomedp) e código do empregado (code).
PASSO 3: Para cada relacionamento 1:1 no esquema E/R: (i) identificar as relações
das entidades participando do relacionamento; (ii) escolher uma das relações e
incluir como chave estrangeira, a chave primária da outra relação; e (iii) incluir todos
os atributos do relacionamento na relação escolhida.
Para o exemplo da Figura 5, têm-se as Entidades EMPREGADO e
DEPARTAMENTO participando do relacionamento 1:1. É necessário escolher uma
das duas relações resultantes (Empregado e Departamento) que irá incluir como
chave estrangeira a chave primária da outra. Se for colocada a chave primária de
Departamento em Empregado, está sendo dito que todo empregado gerencia um
departamento e isso não é verdade. Portanto, deve ser colocada a chave primária
code na Relação Departamento, pois todo departamento tem um empregado que o
gerencia. Como existe um atributo de relacionamento, datai (data de início da
22
gerência), o mesmo será incluído na relação que foi incluída a chave primária como
chave estrangeira.
PASSO 4: Para cada relacionamento 1:N no Esquema E/R: (i) identificar a relação
que representa a entidade do lado N; (ii) incluir como chave estrangeira a chave
primária da relação que representa a entidade do lado 1; e (iii) incluir os atributos do
relacionamento na relação.
No exemplo da Figura 5, existe um relacionamento de 1:N, envolvendo as
entidades EMPREGADO e DEPARTAMENTO, cujo relacionamento é TRABALHA.
A relação que representa a entidade do lado N é a Empregado. Deve ser incluído a
chave da relação Departamento, que representa a Entidade DEPARTAMENTO do
lado 1, como chave estrangeira na Relação Empregado. Se existissem atributos de
relacionamentos deveriam ser incluídos também.
PASSO 5: Para cada relacionamento M:N no Esquema E/R: (i) criar uma nova
relação para representar o relacionamento; (ii) incluir como chave estrangeira as
chaves primárias das relações que participamdo relacionamento; (iii) essas chaves
combinadas formarão a chave primária da relação; (iv) incluir também eventuais
atributos do relacionamento.
Através da Figura 5, tem-se o relacionamento DESENVOLVE, que associa as
Entidades EMPREGADO e PROJETO. Para representar esse relacionamento no
esquema relacional, cria-se uma Relação Desenvolve inclui-se as chaves primárias
(code e codp) das relações Empregado e Projeto como chaves estrangeiras nesta
relação. Essas chaves combinadas formarão a chave primária da relação
Desenvolve resultante. O atributo de relacionamento horas será incluído na relação
resultante.
PASSO 6: Para cada atributo multivalorado: (i) criar uma nova relação; (ii) incluir o
atributo correspondendo ao atributo multivalorado mais a chave primária da relação
que tem esse atributo; (iii) incluir como chave primária da nova relação a
combinação do atributo multivalorado mais a chave primária da entidade que tinha o
atributo multivalorado.
Através da Figura 5, tem-se o atributo multivalorado fone. Deve ser criado
uma nova relação Fone_Departamento e incluir o atributo multivalorado fone e a
23
codp nome
chave primária da Relação Departamento que tem esse atributo multivalorado. A
combinação do atributo multivalorado e a chave primária da Relação Departamento
formarão a chave primária da relação resultante.
PASSO 7: Para cada relacionamento n-ário (n > 2): (i) criar uma nova relação para
representar o relacionamento; (ii) incluir como chaves estrangeiras as chaves
primária das relações que representam as entidades participantes; (iii) incluir os
eventuais atributos de relacionamento; e (iv) incluir como chave primária da relação
resultante a combinação das chaves estrangeiras.
No exemplo apresentado não existe relacionamento n-ário.
3.5 EXERCÍCIOS DE REVISÃO COM RESPOSTAS
1. Represente, na Notação de Peter Chen que um EMPREGADO é um
ADMINISTRATIVO ou é um PROFESSOR.
Figura 8: Generalização/Especialização de EMPREGADO
2. Idem para generalização/especialização de que PESSOA é uma pessoa FÍSICA
ou uma pessoa JURÍDICA (acrescente atributos).
Figura 9: Generalização/Especialização de PESSOA
EMPREGADO
ADMINISTRATIVO PROFESSOR
CPF
CNPJ
PESSOA
FÍSICA JURÍDICA
24
RG RA
sigla
3. Cite um exemplo de entidade forte e outro de entidade fraca.
Figura 10: Entidade Forte e Fraca
Entidade Forte: LIVRO
Entidade Fraca: EXEMPLAR
4. Projete um banco de dados (Esquema E/R) para a seguinte descrição de alunos,
professores e disciplinas, com os seguintes requisitos:
 Alunos têm um identificador único (registro acadêmico - RA) e um nome;
 Professores têm um identificador único (RG), um nome;
 Disciplinas têm uma sigla única e um nome;
 Um aluno pode cursar uma ou mais disciplinas, porém uma disciplina pode
ter muitos alunos;
 Um professor pode ministrar uma ou mais disciplinas, porém, cada
disciplina é ministrada por um único professor.
Figura 11: Esquema E/R para Professor, Aluno e Disciplina
N
1LIVRO N
nome
PROFESSOR
nome
ALUNO
N
nome
DISCIPLINA cursa
N
1
ministra
 EXEMPLAR 
25
CNPJ
codp
code
Data_concessão
ender
5. Projete um banco de dados relacional a partir do Esquema E/R do exercício
anterior.
PROFESSOR(RG, nome)
ALUNO(RA,nome)
DISCIPLINA(sigla,nome,RG)
CURSA(RA,sigla)
6. Elabore o Esquema Entidade/Relacionamento para a descrição de banco de
dados para produtos, fornecedores e empresas (usando Notação de Peter Chen):
 Um fornecedor pode atuar em mais de uma empresa e fornecer mais de um
produto. Cada produto possui apenas um fornecedor;
 Cada empresa concede permissão para apenas um fornecedor. Se uma
empresa dá permissão de fornecimento de um produto a um fornecedor, é
necessário registrar a data da concessão.
Figura 12: Esquema E/R para Fornecedor, Empresa e Produto.
N
nome
FORNECEDOR
nome
PRODUTO
N
nome
EMPRESA
fornece
N
1
pemissão
1
N
26
7. Projete um banco de dados relacional a partir do Esquema E/R do exercício
anterior.
FORNECEDOR(CNPJ, nome)
EMPRESA(code,nome,ender)
PRODUTO(codp,nome,CNPJ)
PERMISSÃO(CNPJ,code,codp,data_concessão)
3.6 CONSIDERAÇÕES DO CAPÍTULO
Toda a realidade, em princípio é nebulosa e informal. Através da observação
podemos extrair da realidade fatos que nos levam a conhecer de uma forma
organizada essa realidade.
Em uma empresa, existem fatos que, observados e modelados, dizem algo a
respeito do funcionamento desta empresa. Para que possamos retratar estes fatos e
que os mesmos possam nos levar a futuras decisões e ações, se faz necessário
então registra-los. Este registro é feito através da criação de um modelo.
Neste capítulo foram tratados os modelos formais de dados
Entidade/Relacionamento e Relacional. Após levantar os aspectos conceituais de
cada modelo, foram descritos os passos para o mapeamento do esquema
Entidade/Relacionamento para o Relacional.
Figura 13: Mapeamentos
Desde uma descrição informal, se constrói o Esquema Entidade/Relacionamento até
o Esquema Relacional (Figura 13). As informações são extraídas do mundo real e
descritas informalmente e então são representadas em cada esquema segundo as
definições de cada modelo.
Descrição
Informal
Esquema
E/R
Esquema
Relacional
27
4 IMPLEMENTAÇÃO DE BANCO DE DADOS
Para ser realizada a implementação de um banco de dados é necessário um
Sistema Gerenciador de Bancos de Dados. Dentre as funções do SGBD estão
aquelas relativas ao controle de localização física dos arquivos que conterão os
dados, organizados na forma de tabelas no caso dos bancos relacionais, controles
de segurança de acesso e a interpretação e execução de comandos que permitam a
manipulação dos dados.
Os SGBDs devem ser escolhidos levando-se em conta o sistema operacional
no qual irão funcionar, o suporte que o fabricante oferece após a venda, a
capacidade de armazenamento, o número de transações que podem realizar
(determinado em conjunto com o hardware utilizado) e o número de usuários
concorrentes possíveis.
Para a efetiva implementação de um banco de dados primeiramente o SGBD
que irá portá-lo deverá estar instalado, testado e evidentemente funcionando.
Deverá existir uma forma de acessar o SGBD de maneira a que sejam exprimidos e
enviados comandos e possam ser obtidos os resultados.
De acordo com o fabricante do SGBD as capacidades e funcionalidades
descritas acima modificam-se, sendo que, em geral, os ambientes mais simples,
voltados a usuários finais, agrupam várias funcionalidades em um ambiente gráfico
de fácil utilização. Eventualmente estes ambientes, por "esconderem" certas
complexidades, comprometem a realização de tarefas mais complexas. Um exemplo
típico de ambiente funcional para o desenvolvimento de pequenos bancos de dados,
e que ao mesmo tempo fornece várias ferramentas para criação de telas de consulta
e relatórios, é o MS-Access.
Os bancos de dados podem seguir uma organização interna que classifica-os
como organizados em Rede, Hierárquicos, Relacionais, Orientados a Objeto e
Objeto-Relacionais. No mercado, encontra-se mais comumente os bancos de dados
Relacionais, seguidos pelos Objeto-Relacionais, os quais implementam algumas
características da Orientação a Objetos em um ambiente relacional, visando extrair o
melhor dos dois ambientes.
28
A Tabela 1 lista algumas possibilidades em termos de SGBDs em uso atualmente.
Nome ou modelo Fabricante Observações
Oracle 9i Oracle Grande variedade de ferramentas acopláveis;
excelente desempenho e confiabilidade; alto custo
de aquisição e manutenção; necessidade de
profissionais altamente especializados para o
completo gerenciamento; disponível para
ambientes Unix, Linux e Windows.
DB2 IBM Grande estabilidade e escalabilidade; disponível
para vários ambientes operacionais, incluindo
Unix, Linux, Windows, equipamentos portáteis e
Mainframes; relativamente fácil de gerenciar;
ótima relação custo x benefício.
SQL Server
2000
Microsoft Totalmente integrado ao sistema operacional
Windows, permitindo usufruir de suas
característicasde gerenciamento de usuário;
integração interna com a tecnologia XML;
ferramenta de interface fácil de utilizar;
gerenciamento efetuado por meio de assistentes;
somente disponível para ambiente Ms-Windows.
MySQL 4.0 MySQL SGBD disponível para ambientes Linux e
Windows; bastante utilizado em servidores
Internet. Boa performance; disponível em versão
gratuita para aplicações não comerciais; possui
ferramenta de gerenciamento e uso em versão
Windows; suporte fornecido por empresas
especializadas, sob contrato, ou por meio de
grupos de discussão e suporte na Internet,
gratuitos porém sem compromisso.
PostgreSQL PostgreSQL SGBD de código aberto e disponível para
utilização livre de custos inclusive para aplicações
comerciais; desempenho e características
comparáveis aos SGBDs comerciais de grande
porte; disponível prioritariamente para ambiente
Linux, possui versão para Windows em
desenvolvimento (beta); suporte fornecido por
empresas especializadas, sob contrato, ou por
meio de grupos de discussão e suporte na
Internet, gratuitos porém sem compromisso.
Tabela 1: Sistemas Gerenciadores de Banco de Dados
Dos SGBDs citados no quadro anterior todos aceitam o modelo relacional; o Oracle
9i (e a versão anterior, a 8i), o DB2 e o PostgreSQL possuem extensões para
trabalhar também com características OO.
29
4.1 LINGUAGEM SQL
Os bancos de dados relacionais utilizam a linguagem de consulta estruturada, SQL
(Structured Query Language), e por representarem grande incidência no mercado
serão objeto de maiores estudos.
A SQL é uma linguagem estruturada para manipulação de dados. É
padronizada para os bancos de dados relacionais, mas cada gerenciador pode
possuir uma extensão própria dessa linguagem.
Ao se utilizar um SGBD e enviar a ele comandos ou sentenças, em SQL,
estes serão interpretados e processados pelo gerenciador. Caso ocorra um erro de
interpretação do comando enviado será retornada uma mensagem indicativa. A
maioria dos SGBDs utiliza o Inglês como língua padrão para comunicação de
mensagens.
4.2 COMANDOS PARA DEFINIÇÃO DE DADOS
Conforme visto na Seção 2.2, os comandos de definição de dados especificam o
esquema do banco de dados, ou seja, tratam da criação (CREATE), e destruição
(DELETE) de tabelas, os quais são analisados na seqüência.
CREATE
Para a criação da base de dados, deve-se enviar ao SGBD o comando CREATE,
seguido de uma indicação do nome do banco que se quer criar. Para a criação de
um banco de dados o nome da tabela a ser informado é DATABASE. Assim, a
criação de um banco de dados no gerenciador é realizada por meio do comando:
CREATE DATABASE
Uma vez que para serem executados corretamente os comandos podem necessitar
mais informações do que somente o que fazer e com qual banco, a linguagem SQL
prevê que certos comandos podem ser seguidos de PARÂMETROS ou
complementos, os quais completam a especificação do comando fornecendo mais
30
informações. Alguns destes parâmetros poderão ser OPCIONAIS, enquanto outros,
mais importantes ou essenciais, são OBRIGATÓRIOS.
Para o caso da criação de um banco de dados, é preciso pelo menos informar
o NOME do banco de dados a ser criado. Eventualmente pode-se desejar informar o
tamanho inicial e talvez até o local em disco onde o banco de dados deverá ser
armazenado, em conjunto com o nome do arquivo. Estas últimas informações
poderiam ser retiradas da configuração padrão do SGBD. Quando o SGBD utiliza
algum valor padrão dizemos que utiliza um valor DEFAULT.
Para o comando acima, a especificação mínima realizável é:
CREATE DATABASE NomeDoBancoDeDados
Devemos observar que podem existir pequenas variações na IMPLEMENTAÇÃO de
um comando de um gerenciador para outro; o que é padrão em um pode não ser em
outro, o que é obrigatório em um pode não ser em outro. Isto é válido para todos os
comandos, não somente para o CREATE.
A partir do momento em que o banco de dados foi criado já está disponível
um ESPAÇO gerenciável para o armazenamento de dados. Este espaço é
gerenciável pois o gerenciador, por meio de comandos específicos, pode ser
instruído a armazenar e recuperar dados e a controlar a segurança de acesso, por
exemplo.
Para o armazenamento de dados em um banco é necessário explicar ao
gerenciador como eles serão armazenados e como são estes dados. No caso de um
SGBD relacional os dados são armazenados na forma de relações, mais comumente
conhecidas como TABELAS. As tabelas são entidades que possuem TUPLAS de
ATRIBUTOS. Um atributo é um valor da relação, e é popularmente conhecido como
CAMPO ou COLUNA. Conjuntos de atributos repetem-se em tuplas, mais
comumente conhecidas como LINHAS ou REGISTROS.
A sintaxe para a criação de uma tabela é a seguinte:
CREATE TABLE NomeDaTabela
{
NomeDoAtributo TipoDeDado [QualificadorOpcional]
[, ...]
}
31
O comando create é o mesmo utilizado para a criação de bancos de dados; o objeto
agora é uma tabela. A tabela deve ser descrita, ou seja, sua ESTRUTURA deve ser
projetada.
Para cada atributo deve-se informar o tipo de dado que ele comportará, que
se refere a capacidade de armazenamento de números, datas ou textos, por
exemplo. Os tipos de dados disponíveis para a criação de tabelas variam de um
SGBD para outro, bem como seu tratamento interno. De uma forma geral pode-se
assumir que pelo menos existem disponíveis tipos para números e para seqüências
de caracteres; na prática esta lista é bem maior.
Finalmente, o qualificador é um complemento ao atributo que permite ao
gerenciador tratá-lo de forma especial. Um exemplo de qualificador é a indicação de
que o atributo é uma CHAVE de acesso aos dados da tabela, ou que ele é um
campo de auto-incremento da numeração. Outro qualificador bastante utilizado é a
expressão NOT NULL, que indica ao SGDB que ele não deve aceitar o cadastro de
tuplas que possuam este atributo em branco.
Conforme visto na Seção 2.8.2, uma Chave é dita Primária (Primary Key, PK)
quando IDENTIFICA UNICAMENTE uma tupla em uma relação. Por exemplo o
número do cpf poderia ser utilizado para identificar inequivocamente um cliente.
Porém, devemos notar que se o cliente possuir filhos e se estes utilizarem o cpf do
pai este número já não será uma chave única. Para contornar estes problemas
poderemos lançar mão de um artifício que é a criação de uma chave COMPOSTA
por mais de um atributo. Poderíamos por exemplo utilizar o cpf e o nome da mãe
para a localização do cliente.
Quando um atributo que é chave primária em uma relação é utilizado em
outra relação, nesta segunda ele é conhecido como Chave Estrangeira (Foreign key,
FK).
Seguindo o exemplo visto no Capítulo 3 – Modelagem de Banco de Dados, a
Figura 13 a seguir mostra que o identificador único da relação DEPTO é inserido na
relação EMPREGADO, permitindo com isso que um Departamento possua vários
Empregados e que para cada Empregado seja determinado EXATAMENTE e
INEQUIVOCAMENTE qual Departamento ele pertence:
32
Figura 14: Chave Primária e Chave Estrangeira
A construção de tabelas, e o relacionamento realizado por meio das chaves, é
realizada a partir dos estudos realizados na fase de MODELAGEM DE DADOS
(visto na Seção 2.7), sendo uma conseqüência do MODELO ENTIDADE
RELACIONAMENTO, MER ou ainda, E/R.
Uma entidade representativa de um empregado, por exemplo, pode conter os
atributos Code, Nome e Salário (simplificadamente). A criação desta tabela pode ser
realizada por meio da seguinte seqüência de comandos:
CREATE TABLE EMPREGADO
{
CODE INT PRIMARY KEY NOT NULL,
NOME VARCHAR(40) NOT NULL,
SALARIO NUMBER(5,2)
}
Nestes comandos o SGBD está sendo instruído para a criação (CREATE) de uma
tabela (TABLE), a qual será identificada pelo nome de EMPREGADO. Esta tabela
será composta de um campo CODE, que admite números inteiros (INT), será
utilizado como chave primária (PRIMARY KEY) e por este motivo não admite valores
nulos (NOT NULL); o segundo campo da tabela é o NOME, o qual admite até 40
caracteres de comprimento, e também não admitem nulos; e pelocampo SALARIO,
que admite um campo numérico (decimal).
A diferença que existe entre a utilização dos tipos de dados CHAR e
VARCHAR é que os campos char sempre ocupam o mesmo tamanho no arquivo
físico que contém a tabela, enquanto os campos varchar ocupam espaços variáveis
Codd nomed
… …. ……
DepartamenDepartamen
PK
Code Codd
nome
EmpregadoEmpregado
FK
33
em função do conteúdo (daí o 'var', que vem de 'variable'). Alguns SGBDs podem
trazer ainda uma forma de compactação mais avançada e serão indicados por
VARCHAR2. É o caso do Oracle, por exemplo.
DELETE
Para a destruição de tabelas, as mesmas podem ser apagadas com o comando
DROP. Por exemplo:
DROP TABLE NomeDaTabela;
ATENÇÃO: as operações executadas em SGBDs não são reversíveis como aquelas
executadas em documentos do MS-Word, por exemplo. Isto é, NÃO EXISTE UM
COMANDO DESFAZER. Portanto, tenha cuidado ao executar comandos, em
especial aqueles que apagam dados ou tabelas.
4.3 COMANDOS PARA MANIPULAÇÃO DE DADOS
Uma vez criada uma tabela ela será como uma folha em branco, ou mais
precisamente, como uma planilha em branco. Para inserir e trabalhar com o
conteúdo de uma tabela, os seguintes comandos de manipulação de dados (Seção
2.2) podem ser utilizados:
 INSERT, para inserir DADOS na tabela
 SELECT, para retornar (ler, consultar) os DADOS inseridos
 UPDATE, para modificar os DADOS
 DELETE, para apagar os DADOS
INSERT
Para a inserção de dados em uma tabela, o comando INSERT é utilizado, o qual
pode inserir dados em todos os campos de uma linha ou somente em alguns, a
depender de como seja utilizado. Por exemplo o comando a seguir insere o
empregado 'João da Silva com código 1 e salário de 10.000,00 na tabela
EMPREGADO:
INSERT INTO EMPREGADO VALUES( 1, 'João da Silva', 10.000,00);
34
O campo correspondente ao código é numérico e portanto seu valor não precisa
estar inserido entre aspas; os valores de caracteres devem OBRIGATORIAMENTE
serem inseridos entre aspas. Quanto aos comandos, INSERT INTO significa 'inserir
em', enquanto VALUES significa 'valores'.
Conforme o SGBD em uso, o ponto-e-vírgula (" ; ") ao final da sentença não
será obrigatório. Por exemplo, no MS-SQL Server.
O comando acima foi elaborado em sua forma REDUZIDA. Em sua forma
COMPLETA ele ficaria com o seguinte formato (mais comum na maioria das
implementações):
INSERT INTO EMPREGADO (CODE, NOME, SALARIO)
VALUES( 1 , 'João da Silva', 10.000,00 );
Na forma completa os nomes dos campos que estão sendo inseridos são informados,
o que permite inclusive trocar sua ordem, caso necessário:
INSERT INTO EMPREGADO (NOME , CODE, SALARIO)
VALUES('João da Silva', 1 , 10.000,00);
SELECT
Uma vez que os dados estejam armazenados nas tabelas constituintes do SGBD
chegará o momento em que será necessário resgatá-los. Para isso utiliza-se o
comando SELECT (selecione).
Por exemplo, a execução do comando:
SELECT NOME, SALARIO FROM EMPREGADO;
Trará o seguinte resultado, retornado todos os nomes e salários disponíveis:
Nome Salário
-------------------------------------------
João da Silva 10.000,00
No comando utilizado, SELECT corresponde a selecione enquanto FROM indica de
que tabela os dados irão retornar. Os campos informados serão retornados, em
35
conjunto com os dados a eles associados, enquanto os não informados serão
OMITIDOS. No exemplo o campo CODE foi omitido. Isto não significa que os dados
correspondentes ao campo CODE tenham sido perdidos; eles simplesmente não
foram mostrados.
Pode-se utilizar este comando solicitando que todos os campos sejam
retornados:
SELECT * FROM EMPREGADO;
Neste caso o asterisco (" * ") indica que serão mostrados TODOS OS CAMPOS e o
resultado será o seguinte:
Codigo Nome Salário
------------------------------------------------------------
1 João da Silva 10.000,00
É preciso inserir mais algumas pessoas na tabela de maneira a realizar mais
consultas explorando as opções de seleção. Digamos então que os seguintes
comandos foram executados após a inclusão de 'João da Silva', na seqüência
apresentada:
INSERT INTO EMPREGADO (CODE, NOME , SALÁRIO)
VALUES( 2 , 'Ana Maria', 5.000,00 );
INSERT INTO EMPREGADO (CODE, NOME , SALÁRIO)
VALUES( 3 , 'Diego Antunes', 1.000,00 );
INSERT INTO EMPREGADO (CODE, NOME , SALARIO)
VALUES( 4 , 'João da Silva', 4.000,00 );
INSERT INTO EMPREGADO (CODE, NOME , SALÁRIO)
VALUES( 5 , 'Ana Silva', 1.500,00 );
INSERT INTO EMPREGADO (CODE, NOME , SALÁRIO)
VALUES( 6 , 'Valdecir Santos', 2.000,00 );
INSERT INTO EMPREGADO (CODE, NOME , SALÁRIO)
VALUES( 7 , 'João da Silva', 1.2000,00);
Uma observação é que os empregados 4 e 7 são homônimos do empregado 1,
'João da Silva'.
36
A execução dos comandos de seleção agora permitirá que sejam exploradas
algumas características interessantes.
SELECT * FROM EMPREGADO;
Code Nome Salário
---------------------------------------------------------------
1 João da Silva 10.000,00
2 Ana Maria 5.000,00
3 Diego Antunes 1.000,00
4 João da Silva 4.000,00
5 Ana Silva 1.500,00
6 Valdecir Santos 2.000,00
7 João da Silva 1.200,00
Os dados são retornados na seqüência em que eles foram gravados. Para que se
efetue uma CLASSIFICAÇÃO ou ORDENAÇÃO dos dados, utiliza-se a cláusula
ORDER BY (ordenar por) na declaração, informando o campo ou campos desejados
para a ordenação:
SELECT * FROM EMPREGADO ORDER BY NOME;
Code Nome Salário
------------------------------------------------------------
2 Ana Maria 5.000,00
5 Ana Silva 1.500,00
3 Diego Antunes 1.000,00
1 João da Silva 4.000,00
4 João da Silva 1.200,00
7 João da Silva 10.000,00
6 Valdecir Santos 2.000,00
Também pode-se efetuar o retorno dos dados utilizando uma cláusula restritiva e
aplicando uma condição a ser respeitada, por meio da declaração WHERE (onde):
37
SELECT * FROM EMPREGADO WHERE CODIGO > 4;
Code Nome Salário
------------------------------------------------------------------
5 Ana Silva 1.500,00
6 Valdecir Santos 2.000,00
7 João da Silva 10.000,00
E pode-se também efetuar a combinação de comandos:
SELECT * FROM EMPREGADO WHERE CODIGO > 4 ORDER BY NOME;
Code Nome Salário
-----------------------------------------------------------------
5 Ana Silva 1.500,00
7 João da Silva 10.000,00
6 Valdecir Santos 2.000,00
O comando SELECT é bastante versátil e possibilita ainda procurar por valores que
sejam próximos a algo conhecido, por meio do uso do operador LIKE (parecido):
SELECT * FROM EMPREGADO WHERE NOME LIKE 'Ana%';
Code Nome Salário
--------------------------------------------------------------------
2 Ana Maria 5.000,00
5 Ana Silva 1.500,00
SELECT * FROM EMPREGADO WHERE NOME LIKE '%Silva';
Code Nome Salário
---------------------------------------------------------------------
1 João da Silva 4.000,00
4 João da Silva 1.200,00
7 João da Silva 10.000,00
38
Nos dois casos foi utilizado o operador (" % ") o qual SUBSTITUE uma seqüência e
pode ser utilizado no início, no meio ou no final da condição.
Por meio da utilização de OPERADORES LÓGICOS podemos estender ainda
mais a funcionalidade do comando de seleção:
SELECT * FROM EMPREGADO
WHERE CODIGO < 3 AND CODIGO > 5;
Code Nome Salário
----------------------------------------------------------
1 João da Silva 4.000,00
2 Ana Maria 5.000,00
6 Valdecir Santos 2.000,00
7 João da Silva 10.000,00
SELECT * FROM EMPREGADO
WHERE NOME LIKE 'Ana%' OR CODIGO=3;
Code Nome Salário
--------------------------------------------------------
2 Ana Maria 5.000,00
3 Diego Antunes 1.000,00
5 Ana Silva 1.500,00
SELECT * FROM EMPREGADO
WHERE CODIGO < 1;
Code Nome Salário
------------------------------------------------------
(retorna uma linha em branco pois nenhuma linha atendeu a condição de pesquisa
proposta)
UPDATE
Uma vez que os dados já podem ser recuperados pode surgir a necessidade de
alterá-los. Por exemplo, considerando que o salário do empregado de código 7,
39
'João da Silva', esteja incorreto e que o valor correto seja 5.500,00. Para
ALTERAMOS o valordo salário o seguinte comando é executado:
UPDATE EMPREGADO
SET SALÁRIO = 5.500,00
WHERE CODIGO = 7;
O comando UPDATE (atualize) irá modificar o valor das linhas que atendam a
condição imposta pelo operador WHERE, modificando os valores dos campos
conforme especificado no operador SET (estabeleça). Se fosse utilizado o nome do
empregado ao invés do código (Code), todos os 'João da Silva' teriam seus salários
alterados para o valor informado.
Vamos verificar a validade do comando:
SELECT * FROM EMPREGADO;
Code Nome Salário
--------------------------------------------------------
1 João da Silva 4.000,00
2 Ana Maria 5.000,00
3 Diego Antunes 1.000,00
4 João da Silva 1.200,00
5 Ana Silva 1.500,00
6 Valdecir Santos 2.000,00
7 João da Silva 5.500,00
DELETE
Finalmente, caso uma parte dos dados de uma tabela não seja mais necessária
utilizaremos o comando DELETE para apagá-la:
DELETE EMPREGADO
WHERE Codigo = 4;
SELECT * FROM EMPREGADO;
40
Código Nome Salário
----------------------------------------------------------
1 João da Silva 4.000,00
2 Ana Maria 5.000,00
3 Diego Antunes 1.000,00
5 Ana Silva 1.500,00
6 Valdecir Santos 2.000,00
7 João da Silva 5.500,00
A utilização de um comando DELETE sem a cláusula WHERE, ou com uma que
inclua muitos ou todos os valores de dados irá apagar toda a tabela,
irreversivelmente (a não ser que exista uma cópia de segurança). Alguns SGBDs
possuem um comando chamado de TRUNCATE, que serve para apagar todo o
conteúdo de uma tabela sem gerar "log". Se este comando for executado toda a
tabela será apagada, porém sua estrutura permanecerá e ela poderá continuar a ser
utilizada com novos valores.
4.4 GERENCIAMENTO DE ACESSO
Por meio da utilização de comando SQL pode-se controlar o acesso dos usuários
aos dados armazenados. Os comandos a serem utilizados para o gerenciamento
dos privilégios de acesso são o GRANT (conceda) e o REVOKE (revogue).
GRANT SELECT ON EMPREGADO TO SIMAO;
 Concede o direito de efetuar consultas na tabela empregado, ao usuário
'simao'
GRANT ALL ON EMPREGADO TO SIMAO;
 Concede o direito de efetuar consultas, inserir, modificar e apagar dados
na tabela empregado ao usuário 'simao'
REVOKE DELETE ON EMPREGADO TO SIMAO;
 Retira o direito de apagar dados na tabela empregado, ao usuário 'simao'
REVOKE ALL ON EMPREGADO TO SIMAO;
41
 Retira todos os direitos do usuário 'simao' na tabela empregado
4.5 EXERCÍCIOS DE REVISÃO COM RESPOSTAS
1. Crie as tabelas abaixo usando a Linguagem SQL, supondo que o ambiente de
banco de dados já foi criado. O banco de dados ENSINO foi criado da seguinte
forma:
CREATE DATABASE ensino
PROFESSOR(RG, nome)
ALUNO(RA,nome)
DISCIPLINA(sigla,nome,RG)
CURSA(RA,sigla)
Criando a Tabela PROFESSOR:
CREATE TABLE PROFESSOR
{
RG INT PRIMARY KEY NOT NULL,
NOME VARCHAR(50) NOT NULL
}
A chave primária deve ser declarada como not null. Em alguns sistemas de
gerenciamento de banco de dados deve ser declarada como not null unique
(única e não nula). O unique indica que não haverá repetições.
Criando a Tabela ALUNO:
CREATE TABLE ALUNO
{
RA INT PRIMARY KEY NOT NULL,
NOME VARCHAR(50) NOT NULL
}
42
Criando a Tabela DISCIPLINA:
CREATE TABLE DISCIPLINA
{
SIGLA INT PRIMARY KEY NOT NULL,
NOME VARCHAR(50) NOT NULL,
RG INT,
FOREIGN KEY (RG) REFERENCES PROFESSOR
}
A cláusula REFERENCES estabelece a restrição de integridade referencial
entre as tabelas DISCIPLINA e PROFESSOR. Porém, observar sempre que
só podemos incluir essas restrições se as tabelas referidas na cláusula
REFERENCES já foram criadas antes desta.
Se a tabela PROFESSOR ainda não tivesse sido criada, ocorreria um erro ao
executar o comando CREATE para a tabela DISCIPLINA.
É muito normal realizar a criação das tabelas sem especificar a cláusula
REFERENCES e posteriormente ao processo de criação, utilizar-se o
comando ALTER TABLE para realizar a inserção das restrições de
integridade referencial.
Criando a Tabela CURSA:
CREATE TABLE CURSA
{
RA INT PRIMARY KEY NOT NULL,
SIGLA VARCHAR(50) NOT NULL
}
43
2. Inserir dados nas tabelas utilizando comandos SQL.
Inserindo dados na tabela PROFESSOR:
INSERT INTO PROFESSOR (RG, NOME)
VALUES(41679727, 'Maria José da Silva');
INSERT INTO PROFESSOR (RG, NOME)
VALUES(41679717, 'Francisco José Souza');
Inserindo dados na tabela ALUNO:
INSERT INTO ALUNO (RA, NOME)
VALUES(031001223, 'Marcos Francisco Santos');
INSERT INTO ALUNO (RA, NOME)
VALUES(031001323, 'Marcela Cristiano Vaz');
Inserindo dados na tabela DISCIPLINA:
INSERT INTO DISCIPLINA (SIGLA,NOME,RG)
VALUES(‘BD’, 'Banco de Dados’, 41679727);
INSERT INTO DISCIPLINA (SIGLA,NOME,RG)
VALUES(‘ES’, 'Engenharia de Software’, 41679717);
Inserindo dados na tabela CURSA:
INSERT INTO CURSA (RA,SIGLA)
VALUES(031001223,’BD’);
INSERT INTO CURSA (RA,SIGLA)
VALUES(031001223,’ES’);
44
3. Formular consultas aos dados das tabelas.
 Consultar todos os dados da tabela PROFESSOR:
SELECT * FROM PROFESSOR;
RG Nome
----------------------------------------------------------
41679727 Maria José da Silva
41679717 Francisco José Souza
 Consultar todos os dados da tabela ALUNO:
SELECT * FROM ALUNO;
RA Nome
----------------------------------------------------------
031001223 Marcos Francisco Santos
031001323 Marcela Cristiano Vaz
 Consultar todos os dados da tabela DISCIPLINA:
SELECT * FROM DISCIPLINA;
SIGLA Nome RG
-------------------------------------------------------------------
BD Banco de Dados 41679727
ES Engenharia de Software 41679717
 Consultar o(s) nome(s) do(s) aluno(s) da disciplina de Banco de Dados:
SELECT ALUNO.nome FROM CURSA, ALUNO
WHERE RA.CURSA = RA.ALUNO AND
SIGLA = ‘BD’; ;
45
Nome
-------------------------------------------------------------------
Marcos Francisco Santos
Na consulta foi necessário utilizar o qualificador de nome que consiste no
nome da tabela seguido de um ponto e o nome da coluna na tabela. O
qualificador de nome para a coluna nome da tabela ALUNO foi:
ALUNO.nome.
Os qualificadores de nome são utilizados em uma consulta para efetivar a
junção entre tabelas, uma vez que o relacionamento entre tabelas é realizado
por meio de chaves estrangeiras e isto implica na existência de colunas com
mesmo nome em tabelas diferentes.
Na consulta pode ser visto RA.CURSA e RA.ALUNO que são qualificadores
de nome para a coluna RA nas tabelas CURSA e ALUNO.
 Consultar o(s) nome(s) do(s) professor(es) da disciplina de Banco de
Dados:
SELECT nomep FROM PROFESSOR, DISCIPLINA
WHERE RG.PROFESSOR = RG.DISCIPLINA AND
SIGLA = ‘BD’; ;
Nome
-------------------------------------------------------------------
Maria José da Silva
4.6 CONSIDERAÇÕES DO CAPÍTULO
Devido ao sucesso de consulta e manipulação de dados, dentro de um ambiente de
banco de dados, através da utilização da Linguagem SQL, resultou num grande
46
sucesso dessa linguagem. Com isso uma grande quantidade de Sistemas
Gerenciadores de Banco de Dados foi tendo como linguagem básica a SQL.
A Linguagem SQL se tornou um padrão de fato, no mundo dos ambientes de
banco de dados relacionais.
Figura 15: Uso de Comandos SQL para Criação e Manutenção de Banco de dados Relacionais
Na Figura 15 é mostrado que após os mapeamentos do Esquema Relacional para
as tabelas do Esquema relacional, o banco de dados é criado através dos comandos
da Linguagem SQL.
Os sistemas de banco de dados comerciais precisam de uma linguagem de
consulta mais fácil para o usuário e a mais utilizada no mercado é a Linguagem SQL.
Ela possui muitos outros recursos além da consulta ao banco de dados, como meios
para a definição da estrutura dos dados, para modificação de dados no banco de
dados e para a especificação de restrições de segurança.
Neste capítulo foram mostrados os comandos para definição e manipulação
de banco de dados relacionais usando a Linguagem SQL. Pode ser visto que essa
Linguagem possui várias partes: linguagem para definição de dados, linguagem
interativa para manipulação de dados, comandospara especificação de direitos de
acesso e comandos para especificação de regras de integridade.
Descrição
Informal
Esquema
E/R
Esquema
Relacional
Linguagem
SQL
BD
Relacionais
47
5 CONSIDERAÇÕES FINAIS
Atualmente o que se valoriza no mercado de trabalho não são unicamente os dados
das organizações, mas o uso que se faz sobre esses dados. Na verdade o que se
tem valor é a informação extraída a partir de uma base de dados. Sendo assim, de
fundamental importância para as empresas manterem-se “vivas”, competitivas e
poderem interagir com o mercado de trabalho. Para tanto, é imprescindível que as
organizações empresariais invistam em tecnologia de banco de dados.
O Projetista de Banco de Dados precisa estar atento ao processo
metodológico de desenvolvimento de sistemas, o qual deve ser cuidadosamente
elaborado, para que a transformação dos aspectos do mundo organizacional que se
deseje estruturar, transforme-se em um modelo de dados formal da empresa.
O Modelo Relacional revela-se uma solução adequada para armazenamento
dos dados empresariais, o qual foi abordado neste material. Assim, o ciclo de
desenvolvimento de uma aplicação de banco de dados deve ser iniciado pela
investigação dos dados que se queira armazenar. A modelagem E/R define
conceitualmente o mundo que se deseja e o Modelo Relacional permite especificar a
modelagem física. O Projeto de banco de dados visa transformar a realidade da
empresa em dados compreensíveis semanticamente pela modelagem de dados.
Quanto à Implementação, o SGBD escolhido deve proporcionar um ambiente
conveniente e eficiente para recuperação e armazenamento das informações,
manter a integridade dos dados, controlar a concorrência, e tratar problemas de
segurança aos dados.
O Monitoramento e Manutenção dos dados devem ser bem planejados para
que se tenha um ambiente de trabalho estável e seguro.
Portanto, o Sistema de Banco de Dados da organização deve estar
estruturado e formalizado dentro da tecnologia de Banco de Dados, para que o
mesmo possa contribuir para a extração da informação e proporcionar um diferencial
competitivo à organização.
48
BIBLIOGRAFIA
COUGO, P. Modelagem Conceitual e Projeto de Banco de Dados. Editora
Campus, Rio de Janeiro, 1997.
CHU, S. Y. Banco de dados: Organização, Sistemas e Administração. Editora
Atlas, São Paulo, 1983.
DATE, C. J. Introdução a Sistemas de Banco de Dados. Tradução da 7ª Edição
Americana. Rio de Janeiro: Editora Campus, 2000.
GUIMARÃES, C. C. Fundamentos de Bancos de Dados – Modelagem, Projeto e
Linguagem SQL. Campinas, SP: Editora da UNICAMP, 2003.
HEUSER, C.A. Projeto de banco de Dados. 3ª Edição, Sagra Luzzatto, Rio Grande
do Sul, 2000.
KROENKE, D. Banco de Dados: Fundamentos, Projeto e Implementação. Sexta
Edição, Rio de Janeiro: LTC – Livros Técnicos e Científicos Editora S/A, 1999.
MACHADO, F; ABREU, M. Projeto de Banco de Dados. Uma Visão Prática. São
Paulo: Editora Érica, 9ª Edição, 2001.
SILBERSCHATZ, A.; KORTH, H.; SUDARSHAN, F.S. Sistema de Banco de Dados.
Quarta Edição. Edição, São Paulo: Makron Books, 2001.
VAZ, M. Fundamentos de Banco de Dados. Programa de Especialização em
Administração de Banco de Dados. UEPG, Departamento de Informática, Notas de
aula, 2003.
	CURSO SUPERIOR
	DE FORMAÇÃO ESPECÍFICA
	EM INFORMÁTICA EMPRESARIAL
	COM MÍDIAS INTERATIVAS
	1 INTRODUÇÃO
	2 SISTEMA DE GERENCIAMENTO DE BANCO DE DADOS - SGB
	 2.1 OBJETIVOS DOS SGBDS
	2.2 CONCEITOS GERAIS
	2.3 ARQUITETURA DE BANCO DE DADOS 
	2.4 ADMINISTRADOR DE BANCO DE DADOS – DBA
	2.5 EVOLUÇÃO DOS SISTEMAS DE ARQUIVOS PARA SGBD RE
	2.6 EXERCÍCIOS DE REVISÃO COM RESPOSTAS
	2.7 CONSIDERAÇÕES DO CAPÍTULO
	3 MODELAGEM DE BANCO DE DADOS
	3.1 PROJETO DE BANCO DE DADOS
	3.2 MODELAGEM ENTIDADE/RELACIONAMENTO
	3.3 MODELAGEM RELACIONAL
	3.4 MAPEAMENTO ENTIDADE/RELACIONAMENTO PARA O RELA
	3.5 EXERCÍCIOS DE REVISÃO COM RESPOSTAS
	3.6 CONSIDERAÇÕES DO CAPÍTULO
	4 IMPLEMENTAÇÃO DE BANCO DE DADOS
	4.1 LINGUAGEM SQL
	4.2 COMANDOS PARA DEFINIÇÃO DE DADOS
	4.3 COMANDOS PARA MANIPULAÇÃO DE DADOS
	4.4 GERENCIAMENTO DE ACESSO
	4.5 EXERCÍCIOS DE REVISÃO COM RESPOSTAS
	4.6 CONSIDERAÇÕES DO CAPÍTULO
	5 CONSIDERAÇÕES FINAIS
	BIBLIOGRAFIA