Faculdade de Tecnologia do Nordeste � FATENE

Curso: Desenvolvimento WEB

Prof. Marcelo Pessoa
Administra��o de
Banco de Dados
Agosto/2008
�ndice
1.
Introdu��o........................................................................
..........................................................4
1.1.
Dado..............................................................................
......................................................4
1.2.
Informa��o........................................................................
..................................................4
1.3. A Informa��o como Recurso da
Empresa...........................................................................
4
2. Organiza��es B�sicas de
Arquivos..........................................................................
..................5
2.1.
Conceitos.........................................................................
...................................................5
2.2. Estruturas de
Arquivos..........................................................................
...............................5
2.2.1. Arquivo
seq�encial........................................................................
...............................5
3. Bancos de
Dados.............................................................................
..........................................7
3.1. Banco de Dados
(BD)..............................................................................
............................7
3.2. Sistema de Ger�ncia de Banco de Dados
(SGBD).............................................................7
3.2.1. Processamento de Dados sem Banco de
Dados........................................................7
3.2.2. Processamento de dados com uso de
SGBD.............................................................8
3.2.3. Principais Componentes de um
Sgbd..........................................................................8
3.2.4. Caracter�sticas de um
SGBD..............................................................................
.........8
3.3. Abstra��o de
Dados.............................................................................
...............................9
3.4. Modelos de Bancos de
Dados.............................................................................
..............10
3.5. Independ�ncia de
Dados.............................................................................
......................10
3.6. Fun��es relacionadas ao
Sgbd..............................................................................
...........10
3.6.1. Administrador de
Dados.............................................................................
................10
3.6.2. Administrador de Banco de
Dados............................................................................1
0
3.6.3. Projetista da Base de
Dados.............................................................................
.........11
3.6.4. Analista de
Sistemas..........................................................................
........................11
3.7. Arquiteturas para uso do
Sgbd..............................................................................
............11
3.7.1. Mono-
usu�rio...........................................................................
..................................11
3.7.2. Multi-Usu�rio com Processamento
Central...............................................................11
3.7.3. Arquitetura em Rede com Servidor de
Arquivos....................................................... 11
3.7.4. Arquitetura
Cliente/Servidor..................................................................
.....................11
3.8. Fases do Projeto de
Bd................................................................................
.....................11
3.8.1. Construir o Modelo
Conceitual........................................................................
...........11
3.8.2. Construir o Modelo
L�gico............................................................................
.............11
3.8.3. Construir o Modelo F�sico
..................................................................................
.......12
3.8.4. Avaliar o Modelo F�sico
..................................................................................
...........12
3.8.5. Implementar o
BD................................................................................
......................12
4. MODELAGEM DE
DADOS.............................................................................
.........................13
4.1.
Conceitos.........................................................................
.................................................13
4.2. Tipos de
Abstra��o.........................................................................
...................................13
4.2.1.
Classifica��o.....................................................................
.........................................13
4.2.2.
Agrega��o.........................................................................
.........................................13
4.2.3.
Generaliza��o.....................................................................
.......................................13
4.3. Requisitos para Modelagem de
Dados.............................................................................
13
4.4. Modelos
Conceituais.......................................................................
...................................13
4.5. Modelos
L�gicos...........................................................................
.....................................14
4.5.1. Modelo
Hier�rquico.......................................................................
.............................14
4.5.2. Modelo de
Rede..............................................................................
...........................14
4.5.3. Modelo
Relacional........................................................................
..............................15
4.6. Modelo de Dados
F�sico............................................................................
........................16
5. MODELO ENTIDADE-RELACIONAMENTO
(M.E.R.).............................................................17
5.1.
Introdu��o........................................................................
.................................................17
5.2.
Entidade..........................................................................
..................................................17
5.3.
Relacionamento....................................................................
.............................................17
5.3.1. Auto-
relacionamento....................................................................
..............................18
5.3.2. Cardinalidade de
Relacionamentos...................................................................
........19
5.3.3. Cardinalidade
M�xima............................................................................
...................19
5.3.4. Classifica��o de Relacionamentos
Bin�rios..............................................................19
5.3.5. Relacionamento
tern�rio..........................................................................
..................21
5.3.6. Cardinalidade
m�nima............................................................................
....................21
5.4. Nota��es
Alternativas......................................................................
..................................22
5.5. Atributo
..................................................................................
............................................22
5.5.1.
Dom�nio...........................................................................
...........................................23
5.5.2. Tipos de
Atributos.........................................................................
.............................23
5.5.3. Atributo de Relacionamento
..................................................................................
....23
5.5.4. Identificador de
Entidades.........................................................................
.................23
5.5.5. Relacionamento Identificador (Entidade
Fraca)........................................................ 24
5.5.6. Identificador de
Relacionamentos...................................................................
...........24
5.6.
Generaliza��o/Especializa��o......................................................
.....................................24
5.7. Entidade Associativa
(Agrega��o).......................................................................
..............26
5.8. Relacionamento Mutuamente
Exclusivo.........................................................................
..27
5.9. Restri��o de Persist�ncia no
Relacionamento..................................................................27
5.10. Esquema Textual do
MER...............................................................................
................28
6. Linguagem de Banco de Dados �
SQL...............................................................................
.....29
1. INTRODU��O
1.1. DADO
? Representa��o de um evento do mundo f�sico, de um fato ou de uma id�ia
? Representa��o de uma propriedade ou caracter�stica de um objeto real
? N�o tem significado por si s�
? Ex.: quantidade de Kwh consumidos em uma resid�ncia.
1.2. INFORMA��O
? Organiza��o e agrega��o dos dados, permitindo uma interpreta��o
? Informa��o ? interpreta��o dos dados
? Ex.: Consumo de energia comparado com a capacidade geradora da usina.
Dados
Identificados
Organizados
Agrupados
Armazenados
Recuperados
geram Informa��o
1.3. A INFORMA��O COMO RECURSO DA EMPRESA
Administra��o de Banco de Dados 4
2. ORGANIZA��ES B�SICAS DE ARQUIVOS
2.1. CONCEITOS
? Estruturas de Dados: define a forma como os dados est�o organizados, como se
relacionam e como ser�o manipulados pelos programas. Ex: vetores e matrizes,
registros,
filas, pilhas, �rvores, grafos, etc.
? Arquivo: cole��o de registros l�gicos, cada um deles representando um objeto ou
entidade.
Na pr�tica os arquivos geralmente est�o armazenados na mem�ria secund�ria (fitas e
discos) e s�o usados para armazenar os resultados intermedi�rios de processamento
ou
armazenar os dados de forma permanente.
? Registro l�gico (registro) : seq��ncia de itens, cada item sendo chamado de
campo ou
atributo, correspondendo a uma caracter�stica do objeto representado. Os registros
podem
ser de tamanho fixo ou de tamanho vari�vel.
? Campo: item de dados do registro, com um nome e um tipo associados
? Bloco: unidade de armazenamento do arquivo em disco, tamb�m denominado registro
f�sico. Um registro f�sico normalmente � composto por v�rios registros l�gicos.
Cada bloco
armazena um n�mero inteiro de registros.
? Chave: � uma seq��ncia de um ou mais campos em um arquivo
? Chave prim�ria: � uma chave que apresenta um valor diferente para cada registro
do
arquivo. � usada para identificar, de forma �nica, cada registro.
? Chave secundaria: � uma chave que pode possuir o mesmo valor em registro
distintos. �
normalmente usada para identificar um conjunto de registros.
? Chave de acesso: � uma chave usada para identificar o(s) registro(s) desejado(s)
em uma
opera��o de acesso ao arquivo.
2.2. ESTRUTURAS DE ARQUIVOS
2.2.1. ARQUIVO SEQ�ENCIAL
Nos arquivos seq�enciais a ordem l�gica e f�sica dos registros armazenados � a
mesma. Os registros podem estar dispostos seguindo a seq��ncia determinada por uma
chave
prim�ria (chamada chave de ordena��o), ou podem estar dispostos aleatoriamente.
# Numero Nome Idade Salario
0 1000 ADEMAR 25 600
1 1050 AFONSO 27 700
2 1075 CARLOS 28 500
3 1100 CESAR 30 1000
4 1150 DARCI 23 1500
5 1180 EBER 22 2000
6 1250 ENIO 27 750
7 1270 FLAVIO 28 600
8 1300 IVAN 30 700
9 1325 MIGUEL 34 1000
10 1340 MARIA 35 1500
11 1360 RAMON 32 2000
12 1400 SANDRA 29 700
13 1450 TATIANA 30 500
a) Acesso a um registro
Podemos considerar dois tipos de acesso: seq�encial ou aleat�rio.
O acesso seq�encial consiste em acessar os registros na ordem em que est�o
armazenados, ou seja, o registro obtido � sempre o posterior ao �ltimo acessado.
Como os
registros s�o armazenados em sucess�o cont�nua, acessar o registro �n� de um
arquivo requer
a leitura dos �n-1� registros anteriores.
Administra��o de Banco de Dados 5
O acesso aleat�rio se caracteriza pela utiliza��o de um �argumento de pesquisa�
(chave de acesso), que indica qual o registro desejado. Neste caso, a ordem em que
os
registros s�o acessados pode ser diferente da ordem em que eles est�o armazenados
fisicamente. Se o arquivo est� ordenado e a chave de acesso coincide com a chave
de
ordena��o, podemos utilizar a pesquisa bin�ria. Caso contr�rio, deve ser realizada
uma
pesquisa seq�encial no arquivo.
b) Inser��o de um registro
Se o arquivo n�o est� ordenado, o registro pode ser simplesmente inserido ap�s o
�ltimo registro armazenado.
Se o arquivo est� ordenado, normalmente � adotado o seguinte procedimento:
Dado um arquivo base B, � constru�do um arquivo de transa��es T, que contem os
registros a serem inseridos, ordenado pela mesma chave que o arquivo B. Os
arquivos B e T
s�o ent�o intercalados, gerando o arquivo A, que � a vers�o atualizada de B.
Arquivo B Arquivo T Arquivo A
# Num Nome Idade # Num Nome Idade # Num Nome Idade
0 1000 ADEMAR 25 0 1070 ANGELA 25 0 1000 ADEMAR 25
1 1050 AFONSO 27 1 1120 CLAUDIA 27 1 1050 AFONSO 27
2 1075 CARLOS 28 2 1280 IARA 28 2 1070 ANGELA 25
3 1100 CESAR 30 3 1310 LUIS 30 3 1075 CARLOS 28
4 1150 DARCI 23 4 1420 SONIA 23 4 1100 CESAR 30
5 1180 EBER 22
6 1250 ENIO 27
7 1270 FLAVIO 28
8 1300 IVAN 30
9 1325 MIGUEL 34
10 1340 MARIA 35
11 1360 RAMON 32
12 1400 SANDRA 29
13 1450 TATIANA 30
5 1120 CLAUDIA 27
6 1150 DARCI 23
7 1180 EBER 22
8 1250 ENIO 27
9 1270 FLAVIO 28
10 1280 IARA 28
11 1300 IVAN 30
12 1310 LUIS 30
13 1325 MIGUEL 34
14 1340 MARIA 35
15 1360 RAMON 32
16 1400 SANDRA 29
17 1420 SONIA 23
18 1450 TATIANA 30
c) Exclus�o de um registro
Normalmente � implementada como a inser��o, com a cria��o de um arquivo de
transa��es que cont�m os registros a serem exclu�dos, que � processado
posteriormente.
Pode ainda ser implementada atrav�s de um campo adicional no arquivo que indique o
estado (status) de cada registro. Na exclus�o, o valor deste campo seria alterado
para
�exclu�do�. Posteriormente, � feita a leitura seq�encial de todos os registros,
sendo que os
registros que n�o estiverem marcados como �exclu�dos� s�o copiados para um novo
arquivo.
d) Altera��o de um registro
Consiste na modifica��o do valor de um ou mais atributos de um registro. O
registro
deve ser localizado, lido e os campos alterados, sendo gravado novamente, na mesma
posi��o.
A altera��o � feita sem problemas, desde que ela n�o altere o tamanho do registro
nem modifique o valor de um campo usado como chave de ordena��o.
Administra��o de Banco de Dados 6
3. BANCOS DE DADOS
3.1. BANCO DE DADOS (BD)
Um Banco de Dados (BD) pode ser definido como uma cole��o de dados
interrelacionados, armazenados de forma centralizada ou distribu�da, com
redund�ncia
controlada, para servir a uma ou mais aplica��es.
3.2. SISTEMA DE GER�NCIA DE BANCO DE DADOS (SGBD)
Conjunto de software para gerenciar (definir, criar, modificar, usar) um BD e
garantir a integridade e seguran�a dos dados. O SGBD � a interface entre os
programas de
aplica��o e o BD. Em ingl�s � denominado DataBase Management System (DBMS).
3.2.1. PROCESSAMENTO DE DADOS SEM BANCO DE DADOS
Dados de diferentes aplica��es n�o est�o integrados, pois s�o projetados para
atender
a uma aplica��o espec�fica.
Administra��o de Banco de Dados 7
Problemas da falta de integra��o de dados:
? O mesmo objeto da realidade � m�ltiplas vezes representado na base de dados.
Exemplo: dados de um produto em uma ind�stria
? Redund�ncia n�o controlada de dados: N�o h� ger�ncia autom�tica da
redund�ncia, o que leva a inconsist�ncia dos dados devido a redigita��o de
informa��es
? Dificuldade de extra��o de informa��es: os dados s�o projetados para atender
aplica��es especificas gerando dificuldades para o cruzamento de informa��es
? Dados pouco confi�veis e de baixa disponibilidade
3.2.2. PROCESSAMENTO DE DADOS COM USO DE SGBD
Os dados usados por uma comunidade de usu�rios s�o integrados no Banco de
Dados. Cada informa��o � armazenada uma �nica vez, sendo que as eventuais
redund�ncias
s�o controladas pelo sistema em computador, ficando transparentes para os
usu�rios.
3.2.3. PRINCIPAIS COMPONENTES DE UM SGBD
? Dicion�rio de dados (Data Dictionary): Descreve os dados e suas rela��es em
forma
conceitual e independente de seu envolvimento nas diversas aplica��es. Fornece
refer�ncias cruzadas entre os dados e as aplica��es.
? Linguagem de defini��o de dados (DDL - Data Definition Language): Descreve os
dados que est�o armazenados no BD. As descri��es dos dados s�o guardadas em um
�meta banco de dados�.
? Linguagem de acesso (DML - Data Manipulation Language): Usada para escrever as
instru��es que trabalham sobre a base de dados, permitindo o acesso e atualiza��o
dos
dados pelos programas de aplica��o. Geralmente integrada com a DDL.
? Linguagem de consulta (QUERY): Permite que o usu�rio final, com poucos
conhecimentos t�cnicos, possa obter de forma simples, informa��es do BD.
? Utilit�rios administrativos: Programas auxiliares para carregar, reorganizar,
adicionar,
modificar a descri��o do BD, obter c�pias de reserva e recuperar a integridade
f�sica em
caso de acidentes.
3.2.4. CARACTER�STICAS DE UM SGBD
Um princ�pio b�sico em BD determina que cada item de dado deveria ser capturado
apenas uma vez e ent�o armazenado, de modo que possa tornar dispon�vel para
atender a
qualquer necessidade de acesso qualquer momento.
Alguns pontos importantes s�o:
? Independ�ncia dos dados: O SGBD deve oferecer isolamento das aplica��es em
rela��o aos dados. Esta caracter�stica permite modificar o modelo de dados do
Administra��o de Banco de Dados 8
BD sem necessidade de reescrever ou recompilar todos os programas que
est�o prontos. As defini��es dos dados e os relacionamentos entre os dados
s�o separados dos c�digos os programas. Mais de 80 % do tempo dos analistas
e programadores � gasto na manuten��o de programas. A principal causa
deste elevado tempo reside na falta de independ�ncia entre dados e programas.
? Facilidade uso/desempenho: Embora o SGBD trabalhe com estruturas de dados
complexas, os arquivos devem ser projetados para atender a diferentes
necessidades, permitindo desenvolver aplica��es melhores, mais seguras e
mais rapidamente. Deve possui comandos poderosos em sua linguagem de
acesso.
? Integridade dos dados: O SGBD deve garantir a integridade dos dados, atrav�s da
implementa��o de restri��es adequadas. Isto significa que os dados devem ser
precisos e v�lidos.
? Redund�ncia dos dados: O SGBD deve manter a redund�ncia de dados sob
controle, ou seja, ainda que existam diversas representa��es do mesmo dado,
do ponto de vista do usu�rio � como se existisse uma �nica representa��o.
? Seguran�a e privacidade dos dados: O SGBD deve assegurar que estes s�
poder�o ser acessados ou modificados por usu�rios autorizados.
? R�pida recupera��o ap�s falha: Os dados s�o de import�ncia vital e n�o podem
ser perdidos. Assim, o SGBD deve implementar sistemas de toler�ncia a falhas,
tais como estrutura autom�tica de recover e uso do conceito de transa��o.
? Uso compartilhado: O BD pode ser acessado concorrentemente por m�ltiplos
usu�rios.
? Controle do espa�o de armazenamento: O SGBD deve manter controle das
�reas de disco ocupadas, evitando a ocorr�ncia de falhas por falta de espa�o de
armazenamento.
3.3. ABSTRA��O DE DADOS
Um prop�sito central de um SGBD � proporcionar aos usu�rios uma vis�o abstrata
dos dados, isto �, o sistema esconde certos detalhes de como os dados s�o
armazenados ou
mantidos. No entanto, os dados precisam ser recuperados eficientemente.
A preocupa��o com a efici�ncia leva a concep��o de estruturas de dados complexas
para representa��o dos dados no BD. Por�m, uma vez que SGBD s�o freq�entemente
usados
por pessoas sem treinamento na �rea de computa��o, esta complexidade precisa ser
escondida dos usu�rios. Isto � conseguido definindo-se diversos n�veis de
abstra��o pelos
quais o BD pode ser visto:
? N�VEL F�SICO: � o n�vel mais baixo de abstra��o, no qual se descreve como os
dados s�o armazenados. Estruturas complexas, de baixo n�vel, s�o descritas em
detalhe.
? N�VEL CONCEITUAL: � o n�vel que descreve quais os dados s�o realmente
armazenados no BD e quais os relacionamentos existentes entre eles. Este n�vel
descreve o BD como um pequeno n�mero de estruturas relativamente simples.
Muito embora a implementa��o de estruturas simples no n�vel conceitual possa
envolver estruturas complexas no n�vel f�sico, o usu�rio do n�vel conceitual
n�o precisa saber disto.
? N�VEL VIS�O: Este � o n�vel mais alto de abstra��o, no qual se exp�e apenas
parte do BD. Na maioria das vezes os usu�rios n�o est�o preocupados com
todas as informa��es do BD e sim com apenas parte delas (Vis�es dos
Usu�rios)
Administra��o de Banco de Dados 9
3.4. MODELOS DE BANCOS DE DADOS
Um modelo de (banco de) dados � uma descri��o dos tipos de informa��es que est�o
armazenadas em um banco de dados, ou seja, � a descri��o formal da estrutura de
BD.
Estes modelos podem ser escritos em linguagens textuais ou linguagens gr�ficas.
Cada apresenta��o do modelo � denominado �esquema de banco de dados�.
Se tomarmos como exemplo uma ind�stria, o modelo de dados deve mostrar que s�o
armazenadas informa��es sobre produtos, tais como c�digo, descri��o e pre�o. Por�m
o
modelo de dados n�o vai informar quais produtos est�o armazenados no Banco de
Dados.
No projeto de um banco de dados, geralmente s�o considerados 3 modelos:
conceitual, l�gico e f�sico.
? Modelo conceitual: � uma descri��o mais abstrata da base de dados. N�o cont�m
detalhes de implementa��o e � independente do tipo de SGBD usado. � o ponto
de partida para o projeto da base de dados.
? Modelo L�gico: � a descri��o da base de dados conforme � vista pelos usu�rio do
SGBD (programadores e aplica��es). � dependente do tipo de SGBD escolhido,
mas n�o cont�m detalhes da implementa��o (uma vez que o SGBD oferece
abstra��o e independ�ncia de dados).
? Modelo f�sico (interno): Descri��o de como a base de dados � armazenada
internamente. Geralmente s� � alterada para ajuste de desempenho. A
tend�ncia dos produtos modernos � ocultar cada vez mais os detalhes f�sicos de
implementa��o.
3.5. INDEPEND�NCIA DE DADOS
? Independ�ncia de dados a n�vel f�sico: a capacidade de se modificar o modelo
f�sico, sem
precisar reescrever os programas de aplica��o.
? Independ�ncia dados a n�vel l�gico: a capacidade de se modificar o esquema
l�gico,
sem a necessidade de reescrever os programas de aplica��o. Modifica��es no n�vel
l�gico
s�o necess�rias sempre que a estrutura l�gica do BD for alterada. Em alguns casos
a
recompila��o pode ser requerida.
3.6. FUN��ES RELACIONADAS AO SGBD
3.6.1. ADMINISTRADOR DE DADOS
? Gerenciar o dado como um recurso da empresa.
? Planejar, desenvolver e divulgar as bases de dados da empresa.
? Permitir a descentraliza��o dos processos, mas manter centralizado os dados.
? Permitir f�cil e r�pido acesso as informa��es a partir dos dados armazenados.
? O grande objetivo de administrador de dados � permitir que v�rios usu�rios
compartilhem
os mesmos dados. Deste modo, os dados n�o pertencem a nenhum sistema ou usu�rio de
forma espec�fica, e sim, � organiza��o como um todo. Assim, o administrador de
dados se
preocupa basicamente com a organiza��o dos dados e n�o com o seu armazenamento.
3.6.2. ADMINISTRADOR DE BANCO DE DADOS
O DBA (DataBase Administrator) � pessoa ou grupo de pessoas respons�vel pelo
controle do SGBD. S�o tarefas do DBA:
? Responsabilidade pelos modelos l�gico e f�sico (definindo a estrutura de
armazenamento)
? Coordenar o acesso ao SGBD (usu�rios e senhas)
? Definir a estrat�gia de backup
? Melhorar o desempenho do SGBD
? Manter o dicion�rio de dados
Administra��o de Banco de Dados 10
3.6.3. PROJETISTA DA BASE DE DADOS
Constr�i o modelo conceitual de uma parte da base de dados, com a participa��o do
usu�rio. Junto com o DBA integra as novas partes ao banco de dados global.
3.6.4. ANALISTA DE SISTEMAS
Define e projeta aplica��o que ir�o usar a base de dados existente. Utiliza o
modelo
conceitual e o modelo l�gico existentes, mas n�o define os dados da base de dados.
3.7. ARQUITETURAS PARA USO DO SGBD
3.7.1. MONO-USU�RIO
? BD est� no mesmo computador que as aplica��es
? N�o h� m�ltiplos usu�rios
? Recupera��o geralmente atrav�s de backup
? T�pico de computadores pessoais
3.7.2. MULTI-USU�RIO COM PROCESSAMENTO CENTRAL
? BD est� no mesmo computador que as aplica��es
? M�ltiplos usu�rios acessando atrav�s de terminais
? T�pico de ambientes com mainframe
3.7.3. ARQUITETURA EM REDE COM SERVIDOR DE ARQUIVOS
? Multi-usu�rio
? Servidor de arquivos cont�m todos os arquivos do banco de dados
? As esta��es clientes executam as aplica��es e o software de BD
? Gera alto tr�fego na rede
? T�pico de redes pequenas (peer-to-peer)
3.7.4. ARQUITETURA CLIENTE/SERVIDOR
? Multi-usu�rio
? Servidor dedicado ao Banco de Dados, executando o SGBD
? As esta��es clientes executam apenas as aplica��es
? Tr�fego na rede � menor
? Arquitetura atualmente em uso
3.8. FASES DO PROJETO DE BD
3.8.1. CONSTRUIR O MODELO CONCEITUAL
? Modelo de alto n�vel, independente da implementa��o
? Etapa de levantamento de dados
? Uso de uma t�cnica de modelagem de dados
? Abstra��o do ambiente de hardware/software
3.8.2. CONSTRUIR O MODELO L�GICO
? Modelo implement�vel, dependente do tipo de SGBD a ser usado
? Considera as necessidades de processamento
? Considera as caracter�sticas e restri��es do SGBD
? Etapa de normaliza��o dos dados
Administra��o de Banco de Dados 11
3.8.3. CONSTRUIR O MODELO F�SICO
? Modelo implement�vel, com m�todos de acesso e estrutura f�sica
? Considera necessidades de desempenho
? Considera as caracter�sticas e restri��es do SGBD
? Dependente das caracter�sticas de hardware/software
3.8.4. AVALIAR O MODELO F�SICO
? Avaliar o desempenho das aplica��es
? Avaliar os caminhos de acesso aos dados e estruturas utilizadas
3.8.5. IMPLEMENTAR O BD
? Etapa de carga (load) dos dados
? Gerar as interfaces com outras aplica��es
Administra��o de Banco de Dados 12
4. MODELAGEM DE DADOS
4.1. CONCEITOS
? Abstra��o: processo mental atrav�s do qual selecionamos determinadas
propriedades ou
caracter�sticas dos objetos e exclu�mos outras, consideradas menos relevantes para
o
problema sendo analisado.
? Modelo: � uma abstra��o, uma representa��o simplificada, de uma parcela do mundo
real,
composta por objetos reais.
? Modelagem: atividade atrav�s da qual se cria um modelo.
? Modelo de dados: Um modelo de dados � uma descri��o das informa��es que devem
ser
armazenadas em um banco de dados, ou seja, � a descri��o formal da estrutura de BD
(descri��o dos dados, dos relacionamentos entre os dados, da sem�ntica e das
restri��es
impostas aos dados).
4.2. TIPOS DE ABSTRA��O
4.2.1. CLASSIFICA��O
Os objetos do mundo real s�o organizados segundo suas propriedades ou
caracter�sticas comuns, formando classes de objetos. Um objeto pode pertencer
simultaneamente a v�rias classes.
4.2.2. AGREGA��O
Uma classe � definida a partir de um conjunto de outras classes, que representam
suas
partes componentes.
4.2.3. GENERALIZA��O
Define uma nova classe a partir de caracter�sticas comuns de outras classes. A
classe
gen�rica que re�ne as caracter�sticas comuns � denominada superclasse e as classes
que
herdam estas caracter�sticas s�o denominadas subclasses.
4.3. REQUISITOS PARA MODELAGEM DE DADOS
? Entender a realidade em quest�o, identificando os objetos que comp�e a parte da
realidade
que vai ser modelada..
? Representar formalmente a realidade analisada, construindo um modelo de dados.
? Estruturar o modelo obtido e adequ�-lo ao SGBD a ser usado, transformando o
modelo
conceitual em modelo l�gico.
4.4. MODELOS CONCEITUAIS
S�o usados para descri��o de dados no n�vel conceitual. Proporcionam grande
capacidade de estrutura��o e permitem a especifica��o de restri��es de dados de
forma
expl�cita. Exemplos:
? Modelo Entidade-Relacionamento (M.E.R.)
? Modelo de Sem�ntica de dados
? Modelo Infol�gico
? Modelos Orientados para Objetos (OO)
Administra��o de Banco de Dados 13
4.5. MODELOS L�GICOS
S�o usados na descri��o dos dados no n�vel l�gico. Em contraste com modelos
conceituais, esses modelos s�o usados para especificar tanto a estrutura l�gica
global do BD
como uma descri��o em alto n�vel da implementa��o.
4.5.1. MODELO HIER�RQUICO
Um BD hier�rquico � uma cole��o de �rvores de registros. Os registros s�o usados
para representar os dados e ponteiros s�o usados para representar o relacionamento
entre os
dados, numa liga��o do tipo pai-filho. A restri��o � que um determinado registro
somente pode
possuir um registro pai.
4.5.2. MODELO DE REDE
O BD em rede � um grafo, onde os n�s representam os registros e os arcos
representam os relacionamentos entre os registros, atrav�s de liga��es pai-filho.
Diferente do
modelo hier�rquico, um registro pode possuir diversos registros pai.
Administra��o de Banco de Dados 14
4.5.3. MODELO RELACIONAL
Um BD relacional possui apenas um tipo de constru��o, a tabela. Uma tabela �
composta por linhas (tuplas) e colunas (atributos). Os relacionamentos entre os
dados tamb�m
s�o representados ou por tabelas, ou atrav�s da reprodu��o dos valores de
atributos.
Administra��o de Banco de Dados 15
4.6. MODELO DE DADOS F�SICO
Usados para descrever os dados em seu n�vel mais baixo. Capturam os aspectos de
implementa��o do SGBD.
Administra��o de Banco de Dados 16
5. MODELO ENTIDADE-RELACIONAMENTO (M.E.R.)
5.1. INTRODU��O
? Apresentado por Peter Chen, em 1976
? � a t�cnica mais difundida para construir modelos conceituais de bases de dados
? � o padr�o para modelagem conceitual, tendo sofrido diversas extens�es
? Est� baseado na percep��o de uma realidade constitu�da por um grupo b�sico de
objetos
chamados ENTIDADES e por RELACIONAMENTOS entre estas entidades
? Seu objetivo � definir um modelo de alto n�vel independente de implementa��o
? O modelo � representado graficamente por um Diagrama de Entidade-Relacionamento
(DER), que � simples e f�cil de ser entendido por usu�rios n�o t�cnicos
? Conceitos centrais do MER: entidade, relacionamento, atributo,
generaliza��o/especializa��o, agrega��o (entidade associativa)
5.2. ENTIDADE
? Conjunto de objetos da realidade modelada sobre os quais deseja-se manter
informa��es
no Banco de Dados
? Uma entidade pode representar objetos concretos da realidade (pessoas,
autom�veis,
material, nota fiscal) quanto objetos abstratos (departamentos, disciplinas,
cidades)
? A entidade se refere a um conjunto de objetos; para se referir a um objeto em
particular �
usado o termo inst�ncia (ou ocorr�ncia)
? No DER, uma entidade � representada atrav�s de um ret�ngulo que cont�m o nome da
entidade
5.3. RELACIONAMENTO
? � toda associa��o entre entidades, sobre a qual deseja-se manter informa��es no
Banco
de Dados.
? Os relacionamentos representam fatos ou situa��es da realidade, onde as
entidades
interagem de alguma forma
? Um dado por si s� n�o faz uma informa��o, pois n�o tem sentido pr�prio; �
necess�rio que
haja uma associa��o de dados para que a informa��o seja obtida.
? Exemplos:
? Fornecimento: entre as entidades FORNECEDOR e MATERIAL
? Matr�cula: entre as entidades ALUNO e DISCIPLINA
? Financiamento: entre as entidades PROJETO e AGENTE FINANCEIRO
? No DER, os relacionamentos s�o representados por losangos, ligados �s entidades
que
participam do relacionamento
Administra��o de Banco de Dados 17
PESSOA DEPARTAMENTO
DEPARTAMENTO LOTA�� PESSOA
? Diagrama de ocorr�ncias de relacionamentos:
5.3.1. AUTO-RELACIONAMENTO
Relacionamento entre ocorr�ncias da mesma entidade.
Diagrama de ocorr�ncias no auto-relacionamento:
O papel da entidade no relacionamento indica a fun��o que uma ocorr�ncia de uma
entidade cumpre em uma ocorr�ncia de um relacionamento.
Administra��o de Banco de Dados 18
marido esposa
PESSOA
CASAMENT
O
5.3.2. CARDINALIDADE DE RELACIONAMENTOS
A cardinalidade de uma entidade em um relacionamento expressa o n�mero de
inst�ncias da entidade que podem ser associadas a uma determinada inst�ncia da
entidade
relacionada.
Devem ser consideradas duas cardinalidades:
? Cardinalidade m�nima de uma entidade � o n�mero m�nimo de inst�ncias da
entidade associada que devem se relacionar com uma inst�ncia da entidade em
quest�o.
? Cardinalidade m�xima de uma entidade � o n�mero m�ximo de inst�ncias da
entidade associada que devem se relacionar com uma inst�ncia da entidade em
quest�o.
5.3.3. CARDINALIDADE M�XIMA
No projeto para BD relacional (como neste curso) n�o � necess�rio distinguir as
cardinalidades que sejam maiores que 1. Assim, s�o usados apenas as cardinalidades
m�ximas 1 e n (muitos).
5.3.4. CLASSIFICA��O DE RELACIONAMENTOS BIN�RIOS
A cardinalidade m�xima � usada para classificar os relacionamentos bin�rios
(aqueles
que envolvem duas entidades).
Administra��o de Banco de Dados 19
a) Relacionamentos 1:1 (um-para-um)
b) Relacionamentos 1:N (um-para-muitos)
c) Relacionamentos N:N (muitos-para-muitos)
Administra��o de Banco de Dados 20
5.3.5. RELACIONAMENTO TERN�RIO
� o relacionamento formado pela associa��o de tr�s entidades
Cardinalidade em relacionamentos tern�rios:
5.3.6. CARDINALIDADE M�NIMA
A cardinalidade m�nima � usada para indicar o tipo de participa��o da entidade em
um
relacionamento. Esta participa��o pode ser:
? Parcial ou Opcional: quando uma ocorr�ncia da entidade pode ou n�o participar de
determinado relacionamento; � indicado pela cardinalidade m�nima = 0 (zero).
? Total ou Obrigat�ria: quando todas as ocorr�ncias de uma entidade devem
participar de determinado relacionamento; � indicado pela cardinalidade m�nima
> 0 (zero).
Exemplos:
Um cliente pode fazer pedidos ou n�o, mas todos os pedidos devem estar associados
a
um cliente.
Administra��o de Banco de Dados 21
CLIENTE 1 REALIZA N PEDIDO
DEPTO 1 ALOCA N EMPREGADO
Todos os departamentos devem possuir pelo menos um empregado alocado, e todos
os empregados devem estar alocados em um departamento.
Parcialidade m�nima: para um departamento ser criado, devem existem pelo menos
10 empregados alocados.
5.4. NOTA��ES ALTERNATIVAS
? Nota��o Heuser: sem�ntica associativa
? Nota��o Santucci/MERISE: sem�ntica participativa
? Nota��o Setzer: sem�ntica associativa
5.5. ATRIBUTO
? � um dado que � associado a cada ocorr�ncia de uma entidade ou relacionamento.
? Os atributos n�o possuem exist�ncia pr�pria ou independente - est�o sempre
associados a
uma entidade ou relacionamento
? Exemplos:
? Funcion�rio: Matr�cula, Nome, Endere�o
? Material: C�digo, Descri��o
? Financiamento: Valor total, Meses
? Fornecedor: Nome, Endere�o
Administra��o de Banco de Dados 22
10
DEPTO 1 ALOCA N EMPREGADO
(1,1) (0,N)
DEPTO ALOCA EMPREGADO
DEPTO (0,N) ALOCA (1,1) EMPREGADO
DEPTO 1 ALOCA N EMPREGADO
5.5.1. DOM�NIO
� o conjunto de valores v�lidos que um atributo pode assumir.
Ex: Estado civil: solteiro, casado, divorciado, vi�vo
5.5.2. TIPOS DE ATRIBUTOS
a) Opcional/Mandat�rio
130.Opcional: o atributo pode possuir um valor nulo (vazio). Ex: n�mero
de telefone
? Mandat�rio: o atributo deve possuir um valor v�lido, n�o nulo. Ex: nome do
cliente
b) Monovalorado/Multivalorado
132.Monovalorado: o atributo assume um �nico valor dentro do dom�nio.
Ex: data de nascimento
? Multivalorado: o atributo pode assumir um n�mero qualquer de valores dentro do
dom�nio. Ex: Telefone para contato
c) At�mico/Composto
134.At�mico: o atributo n�o pode ser decomposto em outros atributos. Ex:
Idade
? Composto: o atributo � composto por mais de um atributo. Ex: Endere�o
5.5.3. ATRIBUTO DE RELACIONAMENTO
Assim como as entidades, os relacionamentos tamb�m podem possuir atributos.
5.5.4. IDENTIFICADOR DE ENTIDADES
? Conjunto de atributos que tem a propriedade de identificar univocamente cada
ocorr�ncia
de uma entidade
? Toda entidade deve possuir um identificador
? O identificador deve ser m�nimo, �nico, monovalorado e mandat�rio
Administra��o de Banco de Dados 23
5.5.5. RELACIONAMENTO IDENTIFICADOR (ENTIDADE FRACA)
Existem casos em que uma entidade n�o pode ser identificada apenas com seus
pr�prios atributos, mas necessita de atributos de outras entidades com as quais se
relaciona.
Este relacionamento � denominado Relacionamento Identificador. Alguns autores
denominam
uma entidade nesta situa��o de Entidade Fraca.
5.5.6. IDENTIFICADOR DE RELACIONAMENTOS
Uma ocorr�ncia de relacionamento diferencia-se das demais pelas ocorr�ncias das
entidades que participam do relacionamento. No exemplo
No exemplo, uma ocorr�ncia de ALOCA��O � identificada pela ocorr�ncia de
Engenheiro e pela ocorr�ncia de Projeto. Ou seja, para cada par (engenheiro,
projeto) h� no
m�ximo um relacionamento de aloca��o.
Em certos casos, ser� necess�rio o uso de atributos identificadores de
relacionamentos. Por exemplo:
Como o mesmo m�dico pode consultar o mesmo paciente em diversas ocasi�es, �
necess�rio o uso de um atributo que diferencie uma consulta da outra.
5.6. GENERALIZA��O/ESPECIALIZA��O
? A generaliza��o � um processo de abstra��o em que v�rios tipos de entidade s�o
agrupados em uma �nica entidade gen�rica, que mant�m as propriedades comuns
? A especializa��o � o processo inverso, ou seja, novas entidades especializadas
s�o
criadas, com atributos que acrescentam detalhes � entidade gen�rica existente
Administra��o de Banco de Dados 24
? A entidade gen�rica � denominada superclasse e as entidades especializadas s�o
as
subclasses. A superclasse armazena os dados gerais de uma entidade, as subclasses
armazenam os dados particulares
? Este conceito est� associado � id�ia de heran�a de propriedades. Isto significa
que as
subclasses possuem, al�m de seus pr�prios atributos, os atributos da superclasse
correspondente.
? Usada quando � necess�rio caracterizar entidades com atributos pr�prios ou
participa��o
em relacionamentos espec�ficos
Uma generaliza��o/especializa��o pode ser total ou parcial:
? � total quando, para cada ocorr�ncia da entidade gen�rica, existe sempre uma
ocorr�ncia em uma das entidades especializadas.
? � parcial quando nem toda ocorr�ncia da entidade gen�rica possui uma ocorr�ncia
correspondente em uma entidade especializada.
Administra��o de Banco de Dados 25
5.7. ENTIDADE ASSOCIATIVA (AGREGA��O)
? O uso desta abstra��o � necess�rio quando um relacionamento deve ser
representado
como uma entidade no modelo conceitual. Isto ocorre quando � necess�rio
estabelecer um
relacionamento entre uma entidade e um relacionamento.
? Para atender a esta situa��o foi criado o conceito de Entidade Associativa ou
Agrega��o. A
agrega��o � simplesmente um relacionamento que passa a ser tratado como entidade.
? Considerando o exemplo
Se for necess�rio adicionar a informa��o que, a cada consulta um ou mais
medicamentos podem ser prescritos ao paciente, ser� necess�rio criar uma nova
entidade
(MEDICAMENTO). Esta entidade deve se relacionar com as consultas, mas CONSULTA �
um
relacionamento. Deve ser criada ent�o uma entidade associativa.
Outra forma alternativa de se representar a entidade associativa �
Administra��o de Banco de Dados 26
5.8. RELACIONAMENTO MUTUAMENTE EXCLUSIVO
Neste tipo de relacionamento uma ocorr�ncia de um entidade pode estar associada
com ocorr�ncias de outras entidades, mas n�o simultaneamente.
5.9. RESTRI��O DE PERSIST�NCIA NO RELACIONAMENTO
Um relacionamento � persistente quando, depois de criado, ele n�o puder ser
removido
indiretamente pela remo��o de uma ocorr�ncia de uma das entidades associadas.
Administra��o de Banco de Dados 27
AVI�O
PASSAGEIRO
TRANSPORTE CARGA
TRANSPORTE
1 N
ALUNO EMPR�STIMO
LIVRO
5.10. ESQUEMA TEXTUAL DO MER
Um esquema ER pode ser um texto. Abaixo � definida uma sintaxe para uma
linguagem textual para defini��o de esquemas ER. Nesta sintaxe, s�o usadas as
seguintes
conven��es: colchetes indicam opcionalidade, o sufixo LISTA denota uma seq��ncia
de
elementos separados por v�rgulas e o sufixo NOME denota os identificadores.
ESQUEMA � Esquema: ESQUEMA_NOME
SE��O_ENTIDADE
SE��O_GENERALIZA��O
SE��O_AGREGA��O
SE��O_RELACIONAMENTO
SE��O_ENTIDADE � (DECL_ENT)
DECL_ENT �Entidade: ENTIDADE_NOME
{SE��O_ATRIBUTO}
{SE��O_IDENTIFICADOR}
SE��O_ATRIBUTO � Atributos: {DECL_ATRIB}
DECL_ATRIB � [(MIN_CARD, MAX_CARD)] ATRIBUTO_NOME [: DECL_TIPO]
MIN_CARD � 0 | 1
MAX_CARD � 1 | N
DECL_TIPO � inteiro|real|boolean|texto(inteiro)|enum(LISTA_VALORES)|data
SE��O_IDENTIFICADOR � Identificadores: {DECL_IDENT}
DECL_IDENT � (IDENTIFICADOR)
IDENTIFICADOR � ATRIBUTO_NOME
SE��O_GENERALIZA��O � {DECL_HIERARQUIA_GEN}
DECL_HIERARQUIA_GEN � Generaliza��o[(CORBERTURA)]; NOME_GEN
PAI: NOME_ENTIDADE
FILHO: LISTA_NOME_ENTIDADE
COBERTURA � t | p
SE��O_AGREGA��O �{DECL_ENT_ASSOC}
DECL_ENT_ASSOC � EntidadeAssociativa: NOME_RELACIONAMENTO
SE��O_RELACIONAMENTO � {DECL_RELACIONAMENTO}
DECL_RELACIONAMENTO � Relacionamento: NOME_RELACIONAMENTO
Entidades: {DECL_ENT-RELACIONADA}
[ Atributos: {DECL_ATRIB} ]
[ Identificadores: {DECL_IDENT}]
DECL_ENT-RELACIONADA � [(MIN_CARD,MAX_CARD)] NOME_ENTIDADE
Exemplo:
Esquema: EMPRESA
Entidade: DEPARTAMENTO
Atributos: c�digo: inteiro;
Nome: texto(20);
Ativo: boolean;
Identificador: c�digo
Entidade: EMPREGADO
Atributos: matr�cula: inteiro;
Nome: texto(50);
DataNasc : data;
Identificador: matr�cula
Relacionamento: ALOCA
Entidades: (0,N) DEPARTAMENTO
(1,1) EMPREGADO
Administra��o de Banco de Dados 28
6. LINGUAGEM DE BANCO DE DADOS � SQL
Devemos ressaltar que a linguagem SQL � utilizada tanto pelos profissionais
respons�veis
pelos dados, onde � ressaltada a figura do Administrador do Banco de Dados e dos
Analistas
de Dados, como tamb�m pelos desenvolvedores de Aplica��es. Enquanto �queles est�o
preocupados com o desempenho, integridade do Banco de Dados e utilizam toda gama
de
recursos dispon�veis no SQL, estes est�o preocupados apenas em "transformar dados
em
informa��es", portanto para os desenvolvedores costuma-se dizer que conhecer o
"select" j�
basta. Em nosso curso enfatizaremos a import�ncia de TODOS os comandos do SQL, mas
sabemos de antem�o que os professores respons�veis pelas linguagens IDEO, VB e
Delphi,
ressaltar�o a preponder�ncia da instru��o "select", que ser� apresentada a seguir
e n�o no
final do curso de SQL como geralmente acontece, pelo fato de que diversas
disciplinas
necessitam especificamente deste comando, que passaremos a apresentar:
Exerc�cio: baseado nas vinte quest�es expostas a seguir, elabore o DER
contemplando os
atributos e entidades citados em cada uma.
1) Sele��o de todas os campos (ou colunas) da tabela de Departamentos.
Resp:
SELECT * FROM DEPARTAMENTOS;
O exemplo utiliza o coringa "*" para selecionar as colunas na ordem em que foram
criadas. A
instru��o Select, como pudemos observar seleciona um grupo de registros de uma (ou
mais)
tabela(s). No caso a instru��o From nos indica a necessidade de pesquisarmos tais
dados
apenas na tabela Departamentos.
Where como base das Restri��o de tuplas.
A cl�usula "where" corresponde ao operador restri��o da �lgebra relacional. Cont�m
a
condi��o que as tuplas devem obedecer a fim de serem listadas. Ela pode comparar
valores
em colunas, literais, express�es aritm�ticas
ou fun��es.
A seguir apresentamos operadores l�gicos e complementares a serem utilizados nas
express�es apresentadas em where.
Operadores l�gicos
operador significado
= igual a
> maior que
>= maior que ou igual a
< menor que
<= menor que ou igual a
Administra��o de Banco de Dados 29
Exemplos:
SELECT EMPREGADO, FUN��O
FROM EMPREGADOREGADOS
WHERE [C�DIGO DEPARTAMENTO] > 10;
SELECT EMPREGADO, FUN��O
FROM EMPREGADO
WHERE FUN��O = 'GERENTE';
O conjunto de caracteres ou datas devem estar entre ap�strofes (�) na cl�usula
"where".
2) Selecione todos os departamentos cujo or�amento mensal seja maior que 100000.
Apresente o Nome de tal departamento e seu or�amento anual, que ser� obtido
multiplicando-se o or�amento mensal por 12.
Resp: Neste problema precisamos de uma express�o que � a combina��o de um ou mais
valores, operadores ou fun��es que resultar�o em um valor. Esta express�o poder�
conter
nomes de colunas, valores num�ricos, constantes e operadores aritm�ticos.
SELECT DEPARTAMENTO, OR�AMENTO * 12
FROM DEPARTAMENTOS
WHERE OR�AMENTO > 100000;
3) Apresente a instru��o anterior, por�m ao inv�s dos "feios" Expr1001 e Expr1002,
os
T�tulos Departamento e Or�amento.
Resp: Neste exemplo deveremos denominar colunas por apelidos. Os nomes das colunas
mostradas por uma consulta, s�o geralmente os nomes existentes no Dicion�rio de
Dado,
por�m geralmente est�o armazenados na forma do mais puro "informatiqu�s", onde
"todo
mundo" sabe que CliCodi significa C�digo do Cliente. � poss�vel (e prov�vel) que o
usu�rio
desconhe�a estes s�mbolos, portanto devemos os apresentar dando apelidos �s
colunas
"contaminadas" pelo informatiqu�s, que apesar de fundamental para os analistas,
somente s�o
vistos como enigmas para os usu�rios.
SELECT DEPARTAMENTO, OR�AMENTO * 12 AS [OR�AMENTO ANUAL]
FROM DEPARTAMENTOS
WHERE OR�AMENTO > 100000;
4) Apresente todos os sal�rios existentes na empresa, por�m omita eventuais
duplicidades.
Resp: A cl�usula Distinct elimina duplicidades, significando que somente rela��es
distintas
ser�o apresentadas como resultado de uma pesquisa.
SELECT DISTINCT FUN��O
FROM EMPREGADOS;
5) Apresente todos os dados dos empregados, considerando sua exist�ncia f�sica
diferente de sua exist�ncia l�gica (ou seja devidamente inicializado).
Administra��o de Banco de Dados 30
Resp: Desejamos um tratamento diferenciado para valores nulos. Qualquer coluna de
uma
tupla que n�o contenha informa��es � denominada de nula, portanto informa��o n�o
existente.
Isto n�o � o mesmo que "zero", pois zero � um n�mero como outro qualquer, enquanto
que um
valor nulo utiliza um "byte" de armazenagem interna e s�o tratados de forma
diferenciada pelo
SQL.
SELECT EMPREGADO, SAL�RIO + COMISS�O FROM EMPREGADOS;
6) Apresente os nomes e fun��es da cada funcion�rio contidos na tabela empresa,
por�m classificados alfabeticamente (A..Z) e depois alfabeticamente invertido
(Z..A).
Resp: A cl�usula Order By modificar� a ordem de apresenta��o do resultado da
pesquisa
(ascendente ou descendente).
SELECT EMPREGADO, FUN��O
FROM EMPREGADOS
ORDER BY EMPREGADO;
SELECT EMPREGADO, FUN��O
FROM EMPREGADOS
ORDER BY EMPREGADO DESC;
Nota: Tamb�m � poss�vel fazer com que o resultado da pesquisa venha classificado
por v�rias
colunas. Sem a cla�sula "order by" as linhas ser�o exibidas na sequ�ncia que o
SGBD
determinar.
7) Selecione os Nomes dos Departamentos que estejam na f�brica.
Resp:
SELECT DEPARTAMENTO
FROM DEPARTAMENTOS
WHERE [LOCAL DEPARTAMENTO] = "S�O PAULO";
O exemplo exigiu uma restri��o (S�o Paulo) que nos obrigou a utilizar da instru��o
Where.
Alguns analistas costumam afirmar em tom jocoso que SQL n�o passa de
"Selecione algo De algum lugar Onde se verificam tais rela��es"
Acreditamos que esta brincadeira pode ser �til ao estudante, na medida em que
facilita sua
compreens�o dos objetivos elementares do SQL.
Demais Operadores
Operador Significado
between ... and ... entre dois valores ( inclusive )
in ( .... ) lista de valores
like com um padrao de caracteres
is null � um valor nulo
Exemplos:
SELECT EMPREGADO, SAL�RIO
Administra��o de Banco de Dados 31
FROM EMPREGADOS
WHERE SAL�RIO BETWEEN 500 AND 1000;
SELECT EMPREGADO, [C�DIGO DEPARTAMENTO]
FROM EMPREGADOS
WHERE [C�DIGO DEPARTAMENTO] IN (10,30);
SELECT EMPREGADO, FUN��O
FROM EMPREGADO
WHERE EMPREGADO LIKE 'F' & �*�;
SELECT EMPREGADO, FUN��O
FROM EMPREGADO
WHERE COMISS�O IS NULL;
O s�mbolo "%" pode ser usado para construir a pesquisa ("%" = qualquer sequ�ncia
de nenhum
at� v�rios caracteres).
Operadores Negativos
operador descri��o
<> diferente
not nome_coluna = diferente da coluna
not nome_coluna > n�o maior que
not between n�o entre dois valores informados
not in n�o existente numa dada lista de valores
not like diferente do padrao de caracteres informado
is not null n�o � um valor nulo
8) Selecione os Empregados cujos sal�rios sejam menores que 1000 ou maiores que
3500.
Resp: Necessitaremos aqui a utiliza��o de express�o negativas. A seguir
apresentamos
operadores negativos.
SELECT EMPREGADO, SAL�RIO
FROM EMPREGADO
WHERE SAL�RIO NOT BETWEEN 1000 AND 3500;
9) Apresente todos os funcion�rios com sal�rios entre 200 e 700 e que sejam
Vendedores.
Resp: Necessitaremos de consultas com condi��es m�ltiplas.
Operadores "AND" (E) e "OR" (OU).
SELECT EMPREGADO, SAL�RIO, FUN��O
FROM EMPREGADO
WHERE SAL�RIO BETWEEN 700 AND 2000
AND FUN��O = 'VENDEDOR';
Administra��o de Banco de Dados 32
10) Apresente todos os funcion�rios com sal�rios entre 200 e 700 ou que sejam
Vendedores.
Resp:
SELECT EMPREGADO, SAL�RIO, FUN��O
FROM EMPREGADO
WHERE SAL�RIO BETWEEN 700 AND 2000
OR FUN��O = 'VENDEDOR';
11) Apresente todos os funcion�rios com sal�rios entre 200 e 700 e que sejam
Vendedores ou Balconistas.
Resp:
SELECT EMPREGADO, SAL�RIO, FUN��O
FROM EMPREGADO
WHERE SAL�RIO BETWEEN 700 AND 2000
AND ( FUN��O = 'BALCONISTA' OR FUN��O = 'VENDEDOR' );
Fun��es de Caracteres
Lower - for�a caracteres mai�sculos aparecerem em min�sculos.
Upper - for�a caracteres min�sculos aparecerem em mai�sculos.
Concat(x,y)- concatena a string "x" com a string "y".
Substring(x,y,str)- extrai um substring da string "str", come�ando em "x", e
termina em "y".
To_Char(num)- converte um valor num�rico para uma string de caracteres.
To_Date(char,fmt)- converte uma string caracter em uma data.
^Q - converte data para o formato apresentado.
12) Apresente o nome de todos os empregados admitidos em 01/01/80.
Resp:
SELECT *
FROM EMPREGADOS
WHERE [DATA ADMISS�O] = 01/01/80;
Fun��es Agregadas (ou de Agrupamento)
fun��o retorno
avg(n) m�dia do valor n, ignorando nulos
count(expr) vezes que o n�mero da expr avalia para algo nao nulo
max(expr) maior valor da expr
min(expr) menor valor da expr
sum(n) soma dos valores de n, ignorando nulos
13) Apresente a M�dia, o Maior, o Menor e tamb�m a Somat�ria dos Sal�rios pagos
aos
empregados.
Resp:
SELECT AVG(SAL�RIO) FROM EMPREGADOS;
SELECT MIN(SAL�RIO) FROM EMPREGADOS;
SELECT MAX(SAL�RIO) FROM EMPREGADOS;
Administra��o de Banco de Dados 33
SELECT SUM(SAL�RIO) FROM EMPREGADOS;
Agrupamentos
As fun��es de grupo operam sobre grupos de tuplas(linhas). Retornam resultados
baseados
em grupos de tuplas em vez de resultados de fun��es por tupla individual. A
cla�sula "group
by" do comando "select" � utilizada para dividir tuplas em grupos menores.
A cl�usula "GROUP BY" pode ser usada para dividir as tuplas de uma tabela em
grupos
menores. As fun��es de grupo devolvem uma informa��o sumarizada para cada grupo.
14) Apresente a m�dia de sal�rio pagos por departamento.
Resp:
SELECT DUPNUME, AVG(SAL�RIO)
FROM EMPREGADOS
GROUP BY [C�DIGO DEPARTAMENTO];
Obs.: Qualquer coluna ou express�o na lista de sele��o, que n�o for uma fun��o
agregada,
dever� constar da cla�sula "group by". Portanto � errado tentar impor uma
"restri��o" do tipo
agregada na cl�usula Where.
Having
A cl�usula "HAVING" pode ser utilizada para especificar quais grupos dever�o ser
exibidos,
portanto restringindo-os.
15) Retome o problema anterior, por�m apresente resposta apenas para departamentos
com mais de 10 empregados.
Resp:
SELECT [C�DIGO DEPARTAMENTO], AVG(SAL�RIO)
FROM EMPREGADO
GROUP BY [C�DIGO DEPARTAMENTO]
HAVING COUNT(*) > 3;
Obs.: A cla�sula "group by" deve ser colocada antes da "having", pois os grupos
s�o formados
e as fun��es de grupos s�o calculadas antes de se resolver a cl�usula "having".
A cl�usula "where" n�o pode ser utilizada para restringir grupos que dever�o ser
exibidos.
Exemplificando ERRO t�pico - Restringindo M�dia Maior que 1000:
SELECT [C�DIGO DEPARTAMENTO], AVG(SAL�RIO)
FROM EMPREGADOS
WHERE AVG(SALARIO) > 1000
GROUP BY [C�DIGO DEPARTAMENTO];
( Esta sele��o est� ERRADA! )
SELECT [C�DIGO DEPARTAMENTO], AVG(SAL�RIO)
FROM EMPREGADOS
GROUP BY [C�DIGO DEPARTAMENTO]
Administra��o de Banco de Dados 34
HAVING AVG(SAL�RIO) > 1000;
( Sele��o Adequada )
Seq��ncia no comando "Select":
SELECT coluna(s)
FROM tabela(s)
WHERE condi��o(�es) da(s) tupla(s)
GROUP BY condi��o(�es) do(s) grupo(s) de tupla(s)
HAVING condi��o(�es) do(s) grupo(s) de tupla(s)
ORDER BY coluna(s);
A "sql" far� a seguinte avalia��o:
a) WHERE, para estabelecer tuplas individuais candidatas (n�o pode conter fun��es
de grupo)
b) GROUP BY, para fixar grupos.
c) HAVING, para selecionar grupos para exibi�ao.
Equi-Jun��o ( Jun��o por igualdade )
O relacionamento existente entre tabelas � chamado de equi-jun��o, pois os valores
de
colunas das duas tabelas s�o iguais. A Equi-jun��o � poss�vel apenas quando
tivermos
definido de forma adequada a chave estrangeira de uma tabela e sua refer�ncia a
chave
prim�ria da tabela precedente. Apesar de admitir-se em alguns casos, a equi-jun��o
de
tabelas, sem a correspond�ncia Chave Prim�ria-Chave Estrangeira, recomendamos
fortemente
ao estudante n�o utilizar este tipo de constru��o, pois certamente em nenhum
momento nos
exemplos propostos em nossa disciplina ou nas disciplinas de An�lise e Projeto de
Sistemas,
ser�o necess�rias tais jun��es.
16) Listar Nomes de Empregados, Cargos e Nome do Departamento onde o empregado
trabalha.
Resp: Observemos que dois dos tr�s dados solicitados est�o na Tabela Emp, enquanto
o outro
dado est� na Tabela Departamentos. Deveremos ent�o acessar os dados restringindo
convenientemente as rela��es existentes entre as tabelas. De fato sabemos que
[C�DIGO
DEPARTAMENTO] � chave prim�ria da tabela de Departamentos e tamb�m � chave
estrangeira da Tabela de Empregados. Portanto, este campo ser� o respons�vel pela
equijun��o.
SELECT A.EMPREGADO, A.FUN��O, B.DEPARTAMENTO
FROM EMPREGADOS AS A, DEPARTAMENTOS AS B
WHERE A.[C�DIGO DEPARTAMENTO] = B.[C�DIGO DEPARTAMENTO];
Obs.: Note que as tabelas quando cont�m colunas com o mesmo nome, usa-se um
apelido
"alias" para substituir o nome da tabela associado a coluna. Imagine que algu�m
tivesse
definido NOME para ser o Nome do Empregado na Tabela de Empregados e tamb�m NOME
para ser o Nome do Departamento na Tabela de
Departamentos. Tudo funcionaria de forma adequada, pois o ali�s se encarregaria de
evitar
que uma ambiq�idade fosse verificada. Embora SQL resolva de forma muito elegante o
problema da nomenclatura id�ntica para campos de tabelas, recomendamos que o
estudante
fortemente evite tal forma de nomear os campos. O SQL nunca confundir� um A.NOME
com
um B.NOME, por�m podemos afirmar o mesmo de n�s mesmos?
Administra��o de Banco de Dados 35
17) Liste os C�digos do Cada Funcion�rio, seus Nomes, seus Cargos e o nome do
Gerente ao qual este se relaciona.
Resp: Precisamos criar um auto-relacionamento, ou seja, juntar uma tabela a ela
pr�pria. �
poss�vel juntarmos uma tabela a ela mesma com a utiliza��o de apelidos, permitindo
juntar
tuplas da tabela a outra tuplas da mesma tabela.
SELECT A.EMPNUME, A.EMPREGADO, A.FUN��O, B.EMPREGADO
FROM EMPREGADOS AS A, EMPREGADOS AS B
WHERE A.EMPGERE = B.EMPNUME;
As Sub-Consultas
Uma sub-consulta � um comando "select" que � aninhado dentro de outro "select" e
que
devolve resultados intermedi�rios.
18) Relacione todos os nomes de funcion�rios e seus respectivos cargos, desde que
o
or�amento do departamento seja igual a 300000.
Resp:
SELECT EMPREGADO, FUN��O
FROM EMPREGADOS AS A
WHERE 300000 IN ( SELECT OR�AMENTO
FROM DEPARTAMENTOS
WHERE DEPARTAMENTOS.[C�DIGO DEPARTAMENTO]
= A.[C�DIGO DEPARTAMENTO] );
Nota: Observe que a cl�usula IN torna-se verdadeira quando o atributo indicado
est� presente
no conjunto obtido atrav�s da subconsulta.
19) Relacione todos os departamentos que possuem empregados com remunera��o
maior que 3500.
Resp:
SELECT DEPARTAMENTO
FROM DEPARTAMENTOS AS A
WHERE EXISTS (SELECT *
FROM EMPREGADOS
WHERE SAL�RIO > 3500 AND EMP.[C�DIGO DEPARTAMENTO]
= A.[C�DIGO DEPARTAMENTO]);
Nota: Observe que a cl�usula EXISTS indica se o resultado de uma pesquisa cont�m
ou n�o
tuplas. Observe tamb�m que poderemos verficar a n�o exist�ncia (NOT EXISTS) caso
esta
alternativa seja mais conveniente.
Uni�es
Podemos eventualmente unir duas linhas de consultas simplesmente utilizando a
palavra
reservada UNION.
20) Liste todos os empregados que tenham c�digos > 10 ou Funcion�rios que
trabalhem
em departamentos com c�digo maior que 10.
Administra��o de Banco de Dados 36
Resp: Poder�amos resolver esta pesquisa com um �nico Select, por�m devido ao fato
de
estarmos trabalhando em nosso exemplo com apenas duas tabelas n�o consiguimos
criar um
exemplo muito adequado para utiliza��o deste recurso.
(Select * From Empregados Where EmpNume > 10)
Union
(Select * From Empregados Where [C�digo Departamento] > 10);
Inser��es, Altera��es e Exclus�es
Uma linguagem direcionada a extra��o de informa��es de um conjunto de dados, em
tese n�o
deveria incorporar comandos de manipula��o dos dados. Devemos observar contudo que
a
mera exist�ncia de uma linguagem padronizada para acesso aos dados "convidava" os
desenvolvedores a aderirem a uma linguagem "padr�o" de manipula��o de tabelas.
Naturalmente cada desenvolvedor coloca "um algo mais" em seu SQL (SQL PLUS, SQL *,
ISQL, e toda sorte de nomenclaturas), por um lado desvirtuando os objetivos da
linguagem
(padroniza��o absoluta), mas em contrapartida otimiza os acessos ao seu banco de
dados e
por maior que sejam estas mudan�as, jamais s�o t�o importantes que impe�am que um
programador versado em SQL tenha grandes dificuldades em se adaptar ao padr�o de
determinada implementa��o. De fato as diferen�as entre o SQL da Sybase, Oracle,
Microsoft,
s�o muito menores dos que as existentes entre o C, o BASIC e o Pascal, que s�o
chamadas
de linguagens "irm�s", pois todas originam-se conceitualmente no FORTRAN. Podemos
observar que todas as tr�s linguagens mencionadas possuem estruturas de controle
tipo "para"
(for), "enquanto" (while) e repita (do..while, repeat..until). Todas trabalham com
blocos de
instru��o, todas tem regras semelhantes para declara��o de vari�veis e todas usam
comandos
de tomada decis�o baseadas em instru��es do tipo "se" ou "caso", por�m apesar de
tantas
semelhan�as (sic), � praticamente imposs�vel que um programador excelente em uma
linguagem consiga rapidamente ser excelente em outra linguagem do grupo.
Poder�amos
arriscar a dizer que um excelente programador C que utilize a implementa��o da
Symantech
ter� que passar por um breve per�odo de adapta��o para adaptar-se ao C da
Microsoft.
O que ocorreria ent�o se este programador tiver que adaptar-se ao Delphi (Pascal)
da
Borland?
De forma alguma o mesmo ocorrer� com o especialista em SQL ao ter que migrar do
Banco de
Dados X para o Banco de Dados Y. Naturalmente existir� a necessidade de
aprendizado, mas
este programador poder� ir adaptando-se aos poucos sem precisar ser retreinado, o
que � um
aspecto extremamente vantajoso para as empresas.
Inserir (Insert)
INSERT INTO <tabela> [<campos>] [VALUES <valores>]
Ex:
INSERT INTO DEPARTAMENTOS;
Possibilita a inser��o de registros de forma interativa.
INSERT INTO DEPARTAMENTOS ([C�DIGO DEPARTAMENTO], DEPARTAMENTO, [LOCAL
DEPARTAMENTO])
VALUES (70,"PRODUCAO","RIO DE JANEIRO");
Possibilita a inser��o de registros em tabelas sem digita��o dos dados.
Atualizar (Update)
Administra��o de Banco de Dados 37
UPDATE <tabela> SET <campo> = <express�o> [WHERE <condi��o>];
Ex: UPDATE EMP SET SAL�RIO = SAL�RIO* 1.2 WHERE SAL�RIO< 1000;
Excluir (Delete)
DELETE FROM <tabela> [WHERE <condi��o>];
Ex: DELETE From Empregados WHERE SAL�RIO > 5000;
Vis�es
Uma vis�o consiste basicamente de uma tabela derivada de outras tabelas.
Considerando o
exemplo TRABALHO, poder�amos criar uma vis�o baseada na Tabela de Empregados (EMP)
e
na Tabela de Departamentos (DEPARTAMENTOS) onde tiv�ssemos somente os Nomes dos
Funcion�rios e os Departamenos nos quais estes trabalhassem. Ter�amos algo
assemelhado
ao abaixo representado:
CREATE VIEW EMPREGADOS_DEPARTAMENTOS
AS SELECT E.EMPREGADO, D.DEPARTAMENTO
FROM EMPREGADOS AS E, DEPARTAMENTOS AS D
WHERE E.[C�DIGO DEPARTAMENTO] = D.[C�DIGO DEPARTAMENTO];
Devemos observar que:
1- Uma vis�o definida sobre uma �nica tabela somente ser� atualiz�vel se os
atributos da tal
vis�o contiverem a chave prim�ria de tal tabela.
2- Vis�es sobre v�rias tabelas n�o s�o pass�veis de atualiza��es.
3- Vis�es que utilizam fun��es de agrupamentos, tamb�m n�o poder�o ser
atualizadas.
Administra��o de Banco de Dados 38