prof[1] marcelo pessoa - administração de banco de dados

38
Faculdade de Tecnologia do Nordeste – FATENE Curso: Desenvolvimento WEB Prof. Marcelo Pessoa Administração de Banco de Dados Agosto/2008

Upload: pedro-correia

Post on 07-Jun-2015

790 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Prof[1]  Marcelo Pessoa - Administração de Banco de Dados

Faculdade de Tecnologia do Nordeste – FATENECurso: Desenvolvimento WEBProf. Marcelo Pessoa

Administração de Banco de Dados

Agosto/2008

Page 2: Prof[1]  Marcelo Pessoa - Administração de Banco de Dados

Índice

1. Introdução...................................................................................................................................41.1. Dado.....................................................................................................................................41.2. Informação...........................................................................................................................41.3. A Informação como Recurso da Empresa...........................................................................4

2. Organizações Básicas de Arquivos............................................................................................52.1. Conceitos.............................................................................................................................52.2. Estruturas de Arquivos.........................................................................................................5

2.2.1. Arquivo seqüencial.......................................................................................................53. Bancos de Dados.......................................................................................................................7

3.1. Banco de Dados (BD)..........................................................................................................73.2. Sistema de Gerência de Banco de Dados (SGBD).............................................................7

3.2.1. Processamento de Dados sem Banco de Dados........................................................73.2.2. Processamento de dados com uso de SGBD.............................................................83.2.3. Principais Componentes de um Sgbd..........................................................................83.2.4. Características de um SGBD.......................................................................................8

3.3. Abstração de Dados............................................................................................................93.4. Modelos de Bancos de Dados...........................................................................................103.5. Independência de Dados...................................................................................................103.6. Funções relacionadas ao Sgbd.........................................................................................10

3.6.1. Administrador de Dados.............................................................................................103.6.2. Administrador de Banco de Dados............................................................................103.6.3. Projetista da Base de Dados......................................................................................113.6.4. Analista de Sistemas..................................................................................................11

3.7. Arquiteturas para uso do Sgbd..........................................................................................113.7.1. Mono-usuário.............................................................................................................113.7.2. Multi-Usuário com Processamento Central...............................................................113.7.3. Arquitetura em Rede com Servidor de Arquivos....................................................... 113.7.4. Arquitetura Cliente/Servidor.......................................................................................11

3.8. Fases do Projeto de Bd.....................................................................................................113.8.1. Construir o Modelo Conceitual...................................................................................113.8.2. Construir o Modelo Lógico.........................................................................................113.8.3. Construir o Modelo Físico .........................................................................................123.8.4. Avaliar o Modelo Físico .............................................................................................123.8.5. Implementar o BD......................................................................................................12

4. MODELAGEM DE DADOS......................................................................................................134.1. Conceitos...........................................................................................................................134.2. Tipos de Abstração............................................................................................................13

4.2.1. Classificação..............................................................................................................134.2.2. Agregação..................................................................................................................134.2.3. Generalização............................................................................................................13

4.3. Requisitos para Modelagem de Dados............................................................................. 134.4. Modelos Conceituais..........................................................................................................134.5. Modelos Lógicos................................................................................................................14

4.5.1. Modelo Hierárquico....................................................................................................144.5.2. Modelo de Rede.........................................................................................................144.5.3. Modelo Relacional......................................................................................................15

4.6. Modelo de Dados Físico....................................................................................................165. MODELO ENTIDADE-RELACIONAMENTO (M.E.R.).............................................................17

5.1. Introdução..........................................................................................................................175.2. Entidade.............................................................................................................................17

Page 3: Prof[1]  Marcelo Pessoa - Administração de Banco de Dados

5.3. Relacionamento.................................................................................................................175.3.1. Auto-relacionamento..................................................................................................185.3.2. Cardinalidade de Relacionamentos...........................................................................195.3.3. Cardinalidade Máxima...............................................................................................195.3.4. Classificação de Relacionamentos Binários..............................................................195.3.5. Relacionamento ternário............................................................................................215.3.6. Cardinalidade mínima................................................................................................21

5.4. Notações Alternativas........................................................................................................225.5. Atributo ..............................................................................................................................22

5.5.1. Domínio......................................................................................................................235.5.2. Tipos de Atributos......................................................................................................235.5.3. Atributo de Relacionamento ......................................................................................235.5.4. Identificador de Entidades..........................................................................................235.5.5. Relacionamento Identificador (Entidade Fraca)........................................................ 245.5.6. Identificador de Relacionamentos..............................................................................24

5.6. Generalização/Especialização...........................................................................................245.7. Entidade Associativa (Agregação).....................................................................................265.8. Relacionamento Mutuamente Exclusivo........................................................................... 275.9. Restrição de Persistência no Relacionamento..................................................................275.10. Esquema Textual do MER...............................................................................................28

6. Linguagem de Banco de Dados – SQL....................................................................................29

Page 4: Prof[1]  Marcelo Pessoa - Administração de Banco de Dados

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.

DadosIdentificadosOrganizadosAgrupados

ArmazenadosRecuperados

geram Informação

1.3. A INFORMAÇÃO COMO RECURSO DA EMPRESA

Administração de Banco de Dados 4

Page 5: Prof[1]  Marcelo Pessoa - Administração de Banco de Dados

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 Salario0 1000 ADEMAR 25 6001 1050 AFONSO 27 7002 1075 CARLOS 28 5003 1100 CESAR 30 10004 1150 DARCI 23 15005 1180 EBER 22 20006 1250 ENIO 27 7507 1270 FLAVIO 28 6008 1300 IVAN 30 7009 1325 MIGUEL 34 1000

10 1340 MARIA 35 150011 1360 RAMON 32 200012 1400 SANDRA 29 70013 1450 TATIANA 30 500

a) Acesso a um registroPodemos 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

Page 6: Prof[1]  Marcelo Pessoa - Administração de Banco de Dados

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 Idade0 1000 ADEMAR 25 0 1070 ANGELA 25 0 1000 ADEMAR 251 1050 AFONSO 27 1 1120 CLAUDIA 27 1 1050 AFONSO 272 1075 CARLOS 28 2 1280 IARA 28 2 1070 ANGELA 253 1100 CESAR 30 3 1310 LUIS 30 3 1075 CARLOS 284 1150 DARCI 23 4 1420 SONIA 23 4 1100 CESAR 305 1180 EBER 226 1250 ENIO 277 1270 FLAVIO 288 1300 IVAN 309 1325 MIGUEL 34

10 1340 MARIA 3511 1360 RAMON 3212 1400 SANDRA 2913 1450 TATIANA 30

5 1120 CLAUDIA 276 1150 DARCI 237 1180 EBER 228 1250 ENIO 279 1270 FLAVIO 28

10 1280 IARA 2811 1300 IVAN 3012 1310 LUIS 3013 1325 MIGUEL 3414 1340 MARIA 3515 1360 RAMON 3216 1400 SANDRA 2917 1420 SONIA 2318 1450 TATIANA 30

c) Exclusão de um registroNormalmente é 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

Page 7: Prof[1]  Marcelo Pessoa - Administração de Banco de Dados

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

Page 8: Prof[1]  Marcelo Pessoa - Administração de Banco de Dados

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 SGBDOs 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

Page 9: Prof[1]  Marcelo Pessoa - Administração de Banco de Dados

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

Page 10: Prof[1]  Marcelo Pessoa - Administração de Banco de Dados

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

Page 11: Prof[1]  Marcelo Pessoa - Administração de Banco de Dados

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

Page 12: Prof[1]  Marcelo Pessoa - Administração de Banco de Dados

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

Page 13: Prof[1]  Marcelo Pessoa - Administração de Banco de Dados

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

Page 14: Prof[1]  Marcelo Pessoa - Administração de Banco de Dados

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

Page 15: Prof[1]  Marcelo Pessoa - Administração de Banco de Dados

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

Page 16: Prof[1]  Marcelo Pessoa - Administração de Banco de Dados

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

Page 17: Prof[1]  Marcelo Pessoa - Administração de Banco de Dados

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 PESSOALOTAÇÃ

Page 18: Prof[1]  Marcelo Pessoa - Administração de Banco de Dados

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

CASAMENTO

Page 19: Prof[1]  Marcelo Pessoa - Administração de Banco de Dados

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

Page 20: Prof[1]  Marcelo Pessoa - Administração de Banco de Dados

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

Page 21: Prof[1]  Marcelo Pessoa - Administração de Banco de Dados

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

1 NCLIENTE REALIZA PEDIDO

1 NDEPTO ALOCA EMPREGADO

Page 22: Prof[1]  Marcelo Pessoa - Administração de Banco de Dados

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

1 NDEPTO ALOCA EMPREGADO

(1,1) (0,N)DEPTO ALOCA EMPREGADO

(0,N) (1,1)DEPTO ALOCA EMPREGADO

1 NDEPTO ALOCA EMPREGADO

Page 23: Prof[1]  Marcelo Pessoa - Administração de Banco de Dados

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ório130.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/Multivalorado132.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 contatoc) 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

Page 24: Prof[1]  Marcelo Pessoa - Administração de Banco de Dados

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

Page 25: Prof[1]  Marcelo Pessoa - Administração de Banco de Dados

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

Page 26: Prof[1]  Marcelo Pessoa - Administração de Banco de Dados

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

Page 27: Prof[1]  Marcelo Pessoa - Administração de Banco de Dados

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

CARGATRANSPORTE

TRANSPORTE

1 NALUNO EMPRÉS-

TIMOLIVRO

Page 28: Prof[1]  Marcelo Pessoa - Administração de Banco de Dados

5.10. ESQUEMA TEXTUAL DO MERUm 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_NOMESEÇÃO_ENTIDADESEÇÃO_GENERALIZAÇÃOSEÇÃO_AGREGAÇÃOSEÇÃ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 | 1MAX_CARD → 1 | NDECL_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_ENTIDADEFILHO: 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: DEPARTAMENTOAtributos: código: inteiro;

Nome: texto(20);Ativo: boolean;

Identificador: código

Entidade: EMPREGADOAtributos: matrícula: inteiro;

Nome: texto(50);DataNasc : data;

Identificador: matrícula

Relacionamento: ALOCAEntidades: (0,N) DEPARTAMENTO

(1,1) EMPREGADOAdministração de Banco de Dados 28

Page 29: Prof[1]  Marcelo Pessoa - Administração de Banco de Dados

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éticasou 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

Page 30: Prof[1]  Marcelo Pessoa - Administração de Banco de Dados

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

Page 31: Prof[1]  Marcelo Pessoa - Administração de Banco de Dados

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 Significadobetween ... and ... entre dois valores ( inclusive )in ( .... ) lista de valoreslike com um padrao de caracteresis null é um valor nulo Exemplos: SELECT EMPREGADO, SALÁRIO

Administração de Banco de Dados 31

Page 32: Prof[1]  Marcelo Pessoa - Administração de Banco de Dados

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<> diferentenot nome_coluna = diferente da colunanot nome_coluna > não maior quenot between não entre dois valores informadosnot in não existente numa dada lista de valoresnot like diferente do padrao de caracteres informadois 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

Page 33: Prof[1]  Marcelo Pessoa - Administração de Banco de Dados

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 retornoavg(n) média do valor n, ignorando nuloscount(expr) vezes que o número da expr avalia para algo nao nulomax(expr) maior valor da exprmin(expr) menor valor da exprsum(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

Page 34: Prof[1]  Marcelo Pessoa - Administração de Banco de Dados

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

Page 35: Prof[1]  Marcelo Pessoa - Administração de Banco de Dados

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 equi-junçã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 deDepartamentos. 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

Page 36: Prof[1]  Marcelo Pessoa - Administração de Banco de Dados

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

Page 37: Prof[1]  Marcelo Pessoa - Administração de Banco de Dados

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

Page 38: Prof[1]  Marcelo Pessoa - Administração de Banco de Dados

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_DEPARTAMENTOSAS 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