Você está na página 1de 94

PONTIFÍCIA UNIVERSIDADE CATÓLICA DE CAMPINAS INSTITUTO DE INFORMÁTICA PLANO DE ENSINO Curso: Disciplina: Docente:

PONTIFÍCIA UNIVERSIDADE CATÓLICA DE CAMPINAS

INSTITUTO DE INFORMÁTICA

PLANO DE ENSINO

Curso:

Disciplina:

Docente:

C.H. Semanal 04 (quatro horas aula)

Período Letivo:

Análise de Sistemas

Bancos de Dados I

André Luís dos Reis Gomes de Carvalho

1º Semestre de 2000

Objetivo Geral da Disciplina:

Sistematizar o desenvolvimento de bancos de dados (estudo das fases de modelamento de dados).

 

Avaliação:

Haverá apenas uma prova, a prova final (P).

 

Haverá apenas um trabalho que se desenvolverá em várias fases (F i ).

A nota de trabalho T será dada pela média aritmética das notas de cada fase (F i ).

 

Os trabalhos serão realizados sob supervisão do professor através de reuniões periódicas com o grupo envolvido nos trabalhos. Deverá haver um número mínimo de 6 reuniões no semestre. A cada reunião o professor atribuirá aos integrantes do grupo uma nota individual que expressará a participação (R i ) de cada membro do grupo no trabalho.

A nota de acompanhamento A será dada pela média aritmética das notas de cada reunião (R i ).

 

A nota corrigida de trabalho TC será dada pela seguinte expressão: T.A/10.

 

A média final M será dada pela seguite expressão: 0,4.TC + 0,6.P.

Freqüência:

Nenhum abono de falta será concedido pelo professor. Qualquer problema neste sentido deverá ser encaminhada ao PA que tomará todas as providências no sentido de encaminhar a solução do mesmo.

Bibliografia Utilizada :

Introdução a Sistemas de Bancos de Dados Date, C.J.

 

Projeto Lógico e Projeto Físico de Bancos de Dados Setzer, V.W.

The Entity-Relationship Approach to Logical Database Design Chen, P.

Computer Database Organization Martin, J.

Fundamental Concepts of Information Modeling Flavin, M.

Sistemas de Bancos de Dados Korth, H.F.; e Silberschatz

 

 

 

04

Histórico.

O objetivo desta unidade didática é mostrar ao aluno a importância de sistematizar o processo de modelamento de dados.

Aulas

Prova escrita

Fases de modelamento de dados.

 

expositivas

Trabalho Prático

 

O objetivo desta unidade didática é que o aluno aprenda a identificar visões.

Aulas

Prova escrita

08

Levantamento de visões (conceito de visão, como identificar visões, tipos de visões).

expositivas

Trabalho Prático

 

Trabalhos

 

práticos em

campo

Estudo dirigido

20

Modelamento conceitual de visões (modelo entidade- relacionamento extendido binário: entidades, relacionamentos, atributos, tipos de atributos, agregados, hierarquias).

O objetivo desta unidade didática é que o alunos aprenda a modelar dados.

Aulas

Prova escrita

expositivas

Trabalho Prático

 

Trabalhos

práticos em

Integração

das

visões

(construção

do

modelo

conceitual

campo

global).

Estudo dirigido

18

Derivação dos arquivos físicos.

 

O objetivo desta unidade didática é que o aluno aprenda a derivar arquivos físicos a partir de modelos lógicos.

Aulas

Prova escrita

Particionamento dos arquivos físicos.

expositivas

Trabalho Prático

Implementação das visões.

   

Trabalhos

 

práticos em

campo

Estudo dirigido

10

Linguagens

de

Consulta

Teóricas

(Álgebra

e

Cálculo

O objetivo desta unidade didática é que o aluno aprenda a expressar consultas em linguagens de consulta.

Aulas

Prova escrita

Relacional).

expositivas

Trabalho prático

SQL.

 

Estudo dirigido

Normalização

7

Desenvolvimento

8

A

Construção do Modelo Descritivo

20

O

MER

21

A

Construção do Modelo Conceitual

33

A Construção dos Modelos Conceituais Parciais

33

A Construção do Modelo Conceitual Global

34

A

Construção do Modelo Interno

35

A Construção do Modelo Interno Preliminar

35

A Construção do Modelo Interno Otimizado

39

A

Implementação dos Programas Aplicativos

39

Linguagens de Consultas Teóricas

40

Cálculo Relacional

41

Álgebra Relacional

43

SQL (Structured Query Language)

46

Principais Comandos

47

a) Criação de Domínios:

47

b) Eliminação de Domínios:

48

c) Criação de Tabelas:

48

d) Acréscimo de Colunas a uma Tabela

49

f)

Eliminação de Tabelas:

50

g) Criação de Índices:

50

h) Eliminação de Índices:

51

i) Inclusão de Dados:

51

j) Exclusão de Dados:

51

k) Atualização de Dados:

52

l) Criação de Asserções:

52

m)Eliminação de Asserções:

52

n) Consultas:

53

o) Junção de Tabelas:

63

p) União de Tabelas:

66

q) Interseção de Tabelas:

68

r) Diferença de Tabelas:

68

s) Criação de Visões:

70

t) Eliminação de Visões:

71

u) Definição de Sinônimos:

72

v) Eliminação de Sinônimos:

72

w)Concessão de Privilégios

72

x) Revogação de Privilégios

75

y) Processamento de Transações

75

Catálogos

76

Modo Programado

77

Comandos Simples de Modo Programado

78

a)

SELECT com criação de tabela

78

b)

Inserção de grandes volumes de dados

79

Comandos de Modo Programado relacionados com Cursores

79

a) Declaração de Cursores

79

b) Abertura de Cursores

80

c) Obtenção de Dados de Cursores

80

d) Atualização de Dados de Cursores

81

e) Fechamento de Cursores

82

Comandos Dinâmicos em Modo Programado

82

a) Preparação de Comandos

82

b) Execução de Comandos

82

Quando nos propomos a falar de sistemas de bancos de dados, sem dúvida não poderemos deixar de esbarrar no conceito de . Dizemos qualquer de que não disponhamos mas de que tenhamos necessidade.

Em sendo conhecimento, a informação só existe na mente das pessoas, constituindo uma parte de um quadro mental de referência. A está sempre associada a um ente específico concreto ou abstrato, que poderíamos chamar de .

Hoje em dia, mais do que nunca, constitui um recurso básico e imprescindível para toda e qualquer atividade humana. Informações completas e oportunas acabam por diferenciar uma companhia de seus concorrentes, vindo até mesmo a ter implicações não desprezíveis no sucesso ou insucesso de uma empresa.

Dizemos

representar

transferência.

a

qualquer

informação

conjunto

da

fora

de

símbolos

organizados

com

mente

humana,

possibilitando

intencionalidade

seu

para

e

armazenamento

No contexto da computação, quando falamos a respeito de armazenar informações do mundo real em arquivos de dados, nos referimos à armazenagem de coisas que se conheça a cerca das entidades que povoam o mundo real, visando construir uma representação destas mesmas entidades através de seus atributos.

Neste processo de representação, assumimos de maneira implícita que todos os entes do mundo real sejam idênticos a um ente de referência o que nos possibilita construir uma representação padrão.

Um dado representa primariamente informações sobre uma entidade em uma realidade, e secundariamente um próprio pedaço da realidade. Quando extraímos informações dos entes do mundo real e as representamos através de dados em um banco de dados, acabamos por restringir a informação real que virtualmente poderia requerer uma quantidade infinita de dados para representá-la com propriedade. Isto sem falar a respeito das coisas que são

deixadas de lado a fim de conseguir maior semelhança com o ente de referência e em última instância a construção de uma representação padrão.

Desta maneira, não são mais que uma imagem pálida do que é a informação viva do mundo real. Assim, quando obtemos de um sistema de informação dados a respeito de algum ente do mundo real, deve-se realizar sobre eles um processo inverso de enriquecimento semântico, de maneira que se consiga associar os dados obtidos a partir de um banco de dados às entidades do mundo real que lhes deram origem.

Não sendo mais que uma representação das entidades do mundo real, podemos dizer que podem existir inúmeras representações possíveis, sendo cada uma mais ou menos adequada a cada situação.

Chamamos a qualquer conjunto de símbolos com um significado específico que compõe um dado mas que não constitui informação completa.

O processo de normalização consiste de um algoritmo que descreve uma série de transformações que devem ser realizadas sobre arquivos de dados a fim de torná-los estáveis e econômicos. O objetivo é colocar todos os arquivos em consideração na 3ª forma normal.

Antes de vermos um exemplo, convém que apresentemos algumas definições:

Dizemos que o atributo Y da relação R é funcionalmente do atributo X da mesma relação se e somente se cada valor de X em R tiver associado a si precisamente um valor de Y em R a qualquer momento.

Dizemos que uma relação R está na 1FN se e somente se todos os domínios básicos de R contiverem somente valores atômicos.

Dizemos que uma relação R está na 2FN se e somente se ela estiver na 1FN e todos os

atributos não chave forem totalmente dependentes funcionalmente da chave primária.

Dizemos que uma relação R está na 3FN se e somente se ela estiver na 2FN e todos os

atributos chave forem dependentes funcionalmente não transitivos da chave primária.

A título de exemplo, consideremos a relação não normalizada abaixo:

Prod { , NomeP, CorP, PesoP, FornP {#F, NomeF, CidF, DistF,QdeF}}

Passando para a 1FN temos:

Prod { , NomeP, CorP, PesoP} Fornec { , , NomeF, CidF, DistF, QdeF}

Passando para a 2FN temos:

Prod { , NomeP, CorP, PesoP} Fornec { , NomeF, CidF, DistF} PF { , , QdeF}

Finalmente, passando para a 3FN temos:

Prod { , NomeP, CorP, PesoP} Fornec { , NomeF, CidF} PF { , , QdeF} Dist { , Dist}

Podemos dizer de maneira simplificada, que o método tradicional de desenvolvimento de

sistemas pode ser resumido em entradas, processamento, e saídas.

Entre as características desta abordagem tradicional, podemos ressaltar o incentivo ao

desenvolvimento de múltiplas aplicações isoladas, cada qual mantendo seus próprios arquivos

de dados.

Se procedermos a uma análise nas implicações desta abordagem poderemos identificar a existência de alguns problemas, como por exemplo a falta de integração entre os arquivos, o elevado índice de "sorts" e "merges" para a obtenção de ordenação apropriada para a emissão de relatórios, o elevado grau de redundância de dados entre os arquivos das diversas aplicações, a incompatibilidade entre as ocorrências do mesmo dado, a duplicidade de procedimentos e a ocupação inadequada de espaço.

Como já fizemos alusão anteriormente, não é possível negar que os dados são um recurso

imprescindível à boa operação de uma empresa, e desta maneira faz-se necessário que os dados se caracterizem por sua disponibilidade, facilidade de interpretação, atualidade, exatidão

e precisão.

Um sistema de computação que modele os dados de uma organização de acordo com a estrutura e o ambiente reais da organização poderá garantir as metas acima. Para permitir esta modelagem adequada, surge a tecnologia de bancos de dados.

O que é afinal um sistema de banco de dados? Poderíamos dizer que um sistema de banco de dados é um sistema de armazenamento de dados em ambiente computacional, cujo objetivo global é registrar e manter informações de maneira a eliminar os problemas que podem ser identificados em sistemas desenvolvidos segundo a abordagem tradicional, e a conferir aos dados as características apontadas acima como necessárias.

Entendemos por um depósito de dados armazenados em geral de forma

integrada e compartilhada. Podemos imaginar um banco de dados como sendo a unificação de diversos arquivos que de outra forma seriam distinguíveis, eliminando total ou parcialmente (mas de qualquer forma mantendo sob controle) qualquer redundância entre aqueles arquivos. Os dados em um banco de dados podem em geral ser compartilhados entre diversas aplicações

e usuários diferentes. Na verdade, a possibilidade de compartilhamento poderia ser vista como

uma conseqüência da integração do banco de dados. Desta maneira, informações sobre peças que uma empresa fabrique poderiam ser compartilhadas pelo setor de fabricação, pelo setor de

controle de qualidade e pelo setor de vendas.

O termo é em geral estendido para descrever compartilhamento no tempo, isto

é, a possibilidade de diversos usuários ou aplicações acessarem em conjunto o banco de dados

ao mesmo tempo.

Um sistema de banco de dados envolve quatro componentes maiores: hardware, software, usuários e os dados propriamente ditos. Para que seja possível a integração e o compartilhamento de informações em um banco de dados, faz-se necessário que os dados residam em dispositivos de acesso direto como discos ou fitas.

Em geral, para controlar o acesso e o uso das informações em um banco de dados, entre o banco de dados físico e os sistemas aplicativos que os manipulam, encontra-se um software normalmente chamado de sistema gerenciador de banco de dados ou simplesmente SGBD. Este sistema manipula todas as solicitações dos usuários para acesso e/ou utilização dos dados do BD, isolando os sistemas aplicativos dos detalhes de hardware, garantindo a integridade de atualizações aos dados e promovendo o acesso controlado (proteção) aos dados. Em outras palavras, o SGBD fornece uma visão do BD a um bom nível de abstração, suporta operações de usuários, garante a integridade dos dados, bem como a segurança deles.

Antes dos SGBD, como já dissemos anteriormente, os próprios programas aplicativos mantinham seus arquivos de dados, de maneira que a estrutura dos arquivos utilizados por um programa dependia dos programas que utilizariam os mesmos. Este tipo de dependência entre os dados e os programas aplicativos não é uma coisa desejável, pois qualquer mudança que um programa aplicativo necessite na estrutura de um arquivo implicaria em mudanças em talvez muitos programas que fizessem uso do arquivo, ainda que estes programas logicamente não tivessem nenhuma razão para serem afetados por estas mudanças.

Definimos dependência de dados como sendo suposições sobre a organização físicas de dados

e o aproveitamento deste conhecimento por parte de programas aplicativos que manipulem

estes dados. Vejamos agora, a título de ilustração, alguns exemplos de dependência de dados.

1. Alguns programas aplicativos são extremamente sensíveis à organização dos arquivos que manuseiam. Considere por exemplo a aplicação de recuperar informações de funcionários em um arquivo seqüencial.

Suponhamos que exista um arquivo de funcionários com os campos número e nome, e que

seja fornecido a um programa aplicativo o código do funcionário a fim de que este proceda

à busca e forneça o nome do funcionário. Analisemos o seguinte programa:

Programa Ordem; Leia (NumFunc); Achou = F;

Fim

= F;

Enquanto Não Achou E Não Fim Faça Se FimArq (ArqFunc) Fim = V; Senão Leia (ArqFunc, RegFunc);

Se RegFunc.NumFunc = NumFunc Achou = V; Senão Se RegFunc.NumFunc > NumFunc Fim = V; FimSe; FimSe; FimSe; FimEnquanto;

Se Achou Escreva (RegFunc.NomeFunc); Senão Escreva ('Não Encontrado!'); FimSe; FimPrograma.

Este programa supõe e se aproveita da suposição de que o arquivo de funcionários estaria

ordenado em ordem crescente de número de funcionário. Desta maneira, se o arquivo for

reordenado por nome de funcionário, o programa não mais funcionará.

2. Certos programas aplicativos podem ainda ser sensíveis ao formato dos dados. Considere o

seguinte trecho de um programa aplicativo:

Programa Formato; Tipo

TipoRegFunc = Registro

NumFunc : Int; NomeFunc: Char [30]; SalarFunc: Real; FimRegistro;

Variável ArqFunc: Arquivo De TipoRegFunc;

Qualquer das mudanças abaixo provocaria mudanças no programa aplicativo:

Adicionar ao registro um campo (por exemplo o campo endereço) não utilizado pelo

programa;

Mudança do tipo de um campo do arquivo não utilizado pelo programa;

Retirada de um campo do arquivo não utilizado pelo programa.

No entanto note que o programa aplicativo não deveria ser sensível a este tipo de coisa,

uma vez que não se utiliza dos dados que sofreram alterações.

3. Considere a seguinte situação: dois programas precisam do mesmo arquivo, só que em

formatos diferentes, por exemplo, um programa que, para todo aluno, lista as matérias que

ele cursa; e outro que, para toda matéria, lista os alunos que estão matriculados nela.

Entre as possíveis soluções para o uso compartilhado do arquivo por parte dos dois

programas poderíamos destacar:

Freqüentes reorganizações (são caras e limitam o acesso "on-line");

Manter duas cópias do arquivo (além de também serem caras, podem criar problemas

de consistência interna, isto é, será possível garantir que os dois arquivos contêm as

mesmas informações? Também têm a questão da segurança, isto é, será possível

garantir ambos os arquivos estarão igualmente protegidos?).

Para alcançar a independência de dados, o SGBD mantém o BD e provê comandos para

acessá-lo, sendo este acesso sempre feito através do SGBD. O SGBD mantém uma visão

estável dos dados, que não é afetada por mudanças na organização. Para tal, o SGBD deve distinguir entre a organização lógica e a organização física dos dados.

Entendemos por organização lógica dos dados, a maneira pela qual os dados são pelos programas aplicativos; e por organização física dos dados, o modo como estes se encontram armazenados em dispositivos físicos.

Enquanto os programas aplicativos conhecer a organização lógica dos dados, a organização física dos dados.

Como vantagens do controle centralizado dos dados por parte do SGBD poderíamos citar:

Reduzir e/ou manter a redundância de informações sob controle (redundâncias por um lado provocam desperdício de espaço de armazenamento e podem causar inconsistências, mas por outro podem vir a melhorar a eficiência de um sistema de banco de dados);

Promover o compartilhamento dos dados (não somente as aplicações existentes podem compartilhar entre si os dados do BD, mas também novas aplicações podem ser desenvolvidas sem que se tenha que criar um só arquivo de dados);

Manter restrições de segurança (a centralização dos dados permite um maior controle destes, e os SGBD em geral permitem a manutenção de diversas permissões de acesso - acréscimo, remoção, modificação, recuperação, etc - e a diversos níveis);

Garantir a integridade (restrições de integridade ou procedimentos de validação podem ser definidos e serão executados pelo SGBD sempre que for tentada uma atualização do BD. É importante chamar a atenção para o fato de que a integridade dos dados é ainda mais importante em sistemas de banco de dados do que em sistemas convencionais, pois uma vez que os dados são compartilhados, torna-se possível que o mal uso que alguma aplicação possa fazer dos dados do banco de dados tenha um efeito não somente local à aplicação, mas possivelmente afetar diversas outras aplicações);

Obter independência dos dados (uma aplicação enxerga os dados do banco de dados da maneira que lhe for conveniente, sem preocupações com o formato, localização ou método de acesso aos dados. Aplicações diferentes poderão ter visões diferentes do BD permitindo

alterações no BD com menor impacto sobre as aplicações, tornando possíveis modificações no software ou no hardware sem necessidade de reprogramações e facilitando o uso compartilhado dos dados uma vez que permite uma visão adequada às necessidades das diversas aplicações sobre o mesmo conjunto de dados).

A palavra neste contexto deve ser entendida como . Desta maneira, esquema lógico é uma descrição da organização lógica dos dados e um esquema físico é uma descrição da organização física dos dados.

Em uma arquitetura de dois esquemas, cada esquema lógico é definido em termos de esquema físicos existentes. Deste modo, poderemos adicionar ou mudar esquemas lógicos facilmente. Por outro lado, esta arquitetura causa uma grande dependência entre os esquemas lógico e físico, e mudar um esquema físico pode ser muito complicado e causar grandes mudanças nos esquemas lógicos existentes.

Em uma arquitetura de três esquemas, para isolar os esquemas lógico e físico, introduzimos um esquema intermediário. Assim teremos:

Um esquema externo ou lógico que consiste dos dados tais como estes são vistos pelos programas aplicativos;

Um esquema intermediário ou conceitual que consiste de uma descrição global e não redundante do BD a nível conceitual;

Um esquema interno ou físico que consiste dos dados tais como estes são armazenados em dispositivos físicos.

Cada esquema lógico é definido em termos de esquemas conceituais, e estes por sua vez, são definidos em termos de esquemas físicos. Uma vez que o esquema conceitual é não redundante, mudanças no esquema físico só afetam uma pequena parte do esquema conceitual, levando a uma maior simplicidade e facilidade na realização de mudanças no esquema físico nesta arquitetura do que na de dois esquemas.

Com isso, poderemos distinguir dois tipos de independência de dados: a independência lógica dos dados (mudanças na visão do BD de um programa aplicativo não afetam as visões que outros programas aplicativos possam ter do BD) e a independência física dos dados (mudanças na estrutura física do BD deixam intacto o esquema lógico, isto é, nenhum programa aplicativo tem sua visão do BD afetada).

Entendemos por modelo físico a forma (estrutura) usada internamente para organizar os dados no BD, isto é, a forma como os dados estão armazenados. Os três modelos mais consagrados são os modelos de rede, hierárquico e o relacional.

Para efeitos deste estudo, concentraremos nossa atenção no modelo relacional que é de longe o mais comumente empregado.

Podemos definir o modelo relacional como um modelo em que os conjuntos de dados são representados por tabelas de valores. Cada tabela é bidimensional e organizada em linhas e colunas. Cada elemento em um conjunto de dados é representado por uma linha na tabela, cada atributo dos elementos de um conjunto é representado por uma coluna na tabela e cada item de dado deste elemento é representado pelo valor da célula que ocupa na tabela.

Ex.:

Sigla

Nome

Nº Aulas/Semana

BDAD

Banco de Dados

3

APSI

Análise e Projeto de Sistemas de Informação

2

IART

Inteligência Artificial

2

No modelo relacional, cada linha se compõe de apenas um tipo de registro, possui um número fixo de atributos, é única (não é permitido a existência de linhas iguais) e possui pelo menos um identificador (chave); os atributos têm valores sempre atômicos (não há grupos que se repetem) e assumem valores em domínios de valores possíveis; o mesmo domínio pode ser usado por diversos atributos; as linhas e colunas podem ser consideradas em qualquer seqüência sem que a mudança de ordem afete as informações em qualquer momento.

Mais adiante voltaremos a falar do modelo relacional, uma vez que estudaremos com detalhes

a implementação relacional. A escolha do modelo relacional como objeto de estudo mais

profundo se deve ao fato de que este modelo é o modelo usado pelos SGBD mais em uso nos

dias de hoje.

Numa abordagem moderna, a tarefa de desenvolvimento de sistemas pode ser enxergada em

três dimensões: a dimensão funcional, a dimensão de armazenamento e a dimensão de

transição de estados.

Como o objetivo deste curso é o projeto de BD, restringiremos nosso estudo somente à

dimensão de armazenamento. Achamos importante no entanto lembrar que os métodos

modernos de desenvolvimento de sistemas recomendam a seguinte ordem para a definição

destas três dimensões:

Definição preliminar do modelo de armazenamento de dados;

Definição do modelo funcional com revisão do modelo de armazenamento de dados;

Definição do diagrama de estados do sistema, isto é, do diálogo do sistema através de

janelas, botões, menus, submenus, comandos, teclas, etc.

Uma técnica moderna para representar a estrutura de armazenamento de dados em um sistema

de computação é a modelagem de dados. Dentre os modelos para a realização desta tarefa,

escolhemos estudar uma extensão do Modelo Entidade Relacionamento (MER), o MER

Estendido Binário, que, doravante, chamaremos apenas de MER.

A fim de diminuir a dificuldade de absorção das idéias que passaremos a abordar a seguir,

faremos uma analogia entre os termos comumente utilizados na modelagem conceitual,

relacional e tradicional:

Atributo

Coluna, ou item de dado

Campo, ou item de dado

Entidade

Tabela, ou

Arquivo

 

Relação

 

Objeto

Linha

Registro

Relacionamento

Tabelas auxiliares para ligação, ou chaves estrangeiras

Arquivos auxiliares para ligação, ou chaves estrangeiras

Ligações

Linhas das tabelas auxiliares para ligação, ou valores das chaves estrangeiras

Registros das tabelas auxiliares para ligação, ou valores das chaves estrangeiras

Tradicionalmente, considera-se que uma empresa, para alcançar seus objetivos, deve usar de

maneira eficaz e racional seus recursos. Estes recursos são normalmente separados em

recursos humanos, recursos financeiros, máquinas e equipamentos, e tecnologia. Pode-se

observar no entanto, que a esta lista, cada dia se torna mais importante acrescentar como um

recurso da empresa os seus dados.

Cada órgão encarregado de administrar um destes recursos tem como funções recrutar,

selecionar e captar novos recursos; garantir a plena disponibilidade dos recursos

administrados; evitar o uso indevido dos recursos da empresa; e promover o uso eficaz dos

recursos.

Para executar estas tarefas com relação aos dados, torna-se necessário o surgimento da figura

do Administrador de Dados comas funções de gerenciar os dados enquanto recursos da

empresa, construir e manter o modelo conceitual dos dados da empresa, manter um registro

com a descrição de todos os dados existentes na empresa, divulgar aos usuários e profissionais

de informática as descrições dos dados da empresa, promover a integração entre os diversos

sistemas de aplicação, e facilitar o desenvolvimento de aplicações para as quais já existem

dados.

Tradicionalmente, existem duas maneiras para se abordar o desenvolvimento de sistemas: a

partir das funções e a partir dos dados. Uma boa razão para a abordagem funcional é o fato de

um sistema ser uma função, sendo análise a atividade de decompor esta função em suas

funções componentes e estas em suas componentes menores. A abordagem funcional parece ser uma abordagem bastante natural para sistemas. Por outro lado, os dados são mais estáveis que as funções e a abordagem funcional normalmente leva a sistemas isolados e arquivos redundantes, enquanto a abordagem pelos dados permite obter sistemas que compartilham dados.

Estudos a respeito da evolução das empresas no que diz respeito ao uso do processamento de dados apontam seis estágios pelos quais passam as empresas: iniciação, contágio, controle, integração, administração de dados e maturidade. Segundo estes estudos, esta evolução é gradativa, reflete a progressiva maturação dos profissionais de informática e dos usuários, e não pode ser artificialmente apressada. Nos primeiros estágios a empresa se preocupa com a automatização das funções mudando o enfoque gradativamente até que entre o terceiro e o quarto estágio, quando começa a mudar o foco das funções para os dados. Assim, o estágio em que a empresa se encontra pode sugerir o enfoque adequado a se dar nos desenvolvimentos da mesma.

Nem todos os sistemas de computação fazem uso de bancos de dados, mas para aqueles que fazem, o elemento sistêmico BD é na maioria das vezes um elemento de importância vital.

No processo de engenharia de BD, segue-se uma rotina de vários passos que conduzem do mundo real à criação de um BD.

mundo real do ponto de vista formal é muito nebuloso. Este mundo é povoado por seres, fatos, coisas, etc. Faz-se necessária uma organização deste mundo. o que normalmente se dá através do levantamento de informações a respeito da porção do mundo real que é de interesse no escopo computacional em questão. Estas informações, organizadas ainda de uma forma informal, são constituídas por relatórios escritos em uma linguagem natural (português, inglês, etc.).

Podem conter um simbolismo difícil de ser entendido. Este é um nível dito descritivo, pois procura-se descrever o mundo real por meio de frases. Não existem regras formais para desenvolver este modelo, pois tanto o mundo real quanto o modelo descritivo não são formais.

Vencidas todas estas dificuldades e de posse de um modelo descritivo do mundo real, poderemos passar à descrição das estruturas e transações envolvidas no modelo descritivo, construindo o modelo conceitual do BD.

O modelo aqui desenvolvido deve ser estritamente formal, o mais próximo possível dos formalismo matemático. Este modelo em geral é feito baseado em símbolos para os quais deve haver uma conceituação rigorosa.

Sem dúvida podemos dizer que o modelo descritivo também é um modelo conceitual, mas sempre que nos referirmos ao modelo conceitual da base de dados, estaremos nos referindo a este modelo conceitual formal.

Em geral, a construção do modelo conceitual de um BD se processa em duas fases: a fase dos modelos conceituais parciais e a do modelo conceitual global. Exploraremos com mais riqueza de detalhes esta modelagem a medida que prosseguirmos nosso estudo.

Desta fase para a frente, a tarefa modelar um BD se torna bastante mais amena, uma vez que não mais lidamos com informações informais, mas sim com um modelo conceitual bem e formalmente definido.

Nosso objetivo nesta fase é a construção do modelo interno do BD, ou seja definir as representações internas dos dados e dos programas. Este modelo em geral permanece sempre um mistério para os usuários do BD que desconhecem (uma vez que não lhes interessa) como seus dados estão descritos internamente, isto é, como as estruturas de dados fornecidas por eles são gravadas internamente no BD.

Esta fase também é feita em duas etapas: a construção de um modelo interno preliminar e a otimização deste. Voltaremos a abordar este assunto mais para frente nesta apostila.

Por fim, vem a fase da implementação dos programas que manipularão os dados a fim de realizar os objetivos funcionais inicialmente estabelecidos. No caso de realizarmos a implementação do BD fazendo uso de um SGBD, desconheceremos nós também a maneira pela qual os dados serão internamente armazenados e interagiremos com o SGBD para solicitar o acesso ao BD. No caso da implementação ser feita com a utilização de uma linguagem tradicional de programação, teremos que nos preocupar mais ou menos com

este tipo de coisa, dependendo dos recursos que a linguagem de programação coloque à disposição.

Esta fase se caracteriza por ser extremamente subjetiva e de vital importância para o sucesso do sistema de computação que se tenciona desenvolver. Diversos fatores contribuem grandemente para a dificuldade da execução desta fase a saber:

Dificuldades de ordem técnica (estas dificuldades de certa forma são até esperadas, tendo em vista a inexistência de métodos precisos para a realização das tarefas desta fase);

Dificuldades de natureza política (quando os grupos de usuários não exista, possuem interesses conflitantes e não se consegue uma solução consensual);

Problemas de comunicação (sabemos que a linguagem que utilizamos para nos comunicarmos é uma linguagem informal e imprecisa, gerando a possibilidade de múltiplas interpretações. Sabemos ainda que outra grande fonte de problemas reside na diferença de contextos e vocabulários que existe entre profissionais de informática e usuários de uma maneira geral);

Omissões voluntárias ou involuntárias de informação (as omissões voluntárias são via de regra causadas por uma sensação de insegurança por parte dos usuários com relação ao sistema que se pretende implantar. Muitos por questão de ignorância ou desinformação temem perder seus lugares com o advento do sistema. Por outro lado as omissões involuntárias em geral são causadas pelo fato de que para os usuários, muitas das coisas que fazem parte das suas atividades são tão obvias que eles acham irrelevantes, acabando por omitir informações importantes);

Ignorância e mistificação a cerca do que seja e do que seja capaz um computador (ainda nos dias de hoje, há quem pense que basta por no computador para ter tudo resolvido, há quem ainda veja o computador como uma caixinha de milagres);

Tabu (muitos usuários vêm as coisas relacionadas com a área como algo hermético, onde sua entrada é vedada. Muitos ainda acham tudo relacionado com informática

extremamente complicado e nutrem uma espécie de aversão preconceituosa a tudo relacionado à computação. Neste contexto, não tentam entender nossos "feed-backs", acham de devemos saber o que estamos fazendo, para que se intrometer no assunto?);

Visualização global (muitas vezes, principalmente quando ainda nos falta alguma experiência, podemos encontrar dificuldade em enxergar o problema a enfrentar como um todo, nos sentindo perdidos em meio aos inúmeros detalhes envolvidos na situação).

Chega o momento de definirmos mais formalmente um conceito ao qual de certa forma já fizemos alusão anteriormente e que constitui peça fundamental para a elaboração do produto desta fase.

Já mencionamos anteriormente que a tecnologia de BD vem para aglutinar dados de aplicações tradicionalmente esparsos, redundantes, incoerentes e incompletos. Desta maneira, todas aplicações deixariam de manter seus próprios arquivos e passariam a armazenar seus dados no BD.

Naturalmente neste processo de aglutinação, acabaremos angariando para o BD dados que são de interesse de certas aplicações mas não de outras. Uma vez que cada aplicação manipulado BD a parte que lhe é devida e desconhece todo o resto dos dados que por ventura lá existam armazenados, podemos dizer que as aplicações não possuem uma visão global do BD, cada aplicação vê o BD como sendo o subconjunto dos dados do BD que utiliza para a realização de suas funções. Assim, existirão várias visões do BD, uma para cada aplicação.

Mais formalmente, definiremos visão como sendo um par ordenado (dados, operações) que descreve os dados do futuro BD do modo que deverão ser vistos por uma aplicação e as operações que serão feitas com estes dados.

O produto desta fase deverá ser uma especificação de todas as visões que estão envolvidas na porção do mundo real de interesse.

Iniciaremos o estudo do MER através de algumas definições. Entenderemos por objeto qualquer coisa que exista no mundo real da qual se tenha necessidade de ter informações.

Entenderemos por entidade um conjunto de objetos semelhantes segundo algum critério. Entenderemos por ligação qualquer vínculo entre objetos do qual se tenha necessidade de ter informações. Entenderemos por relacionamento um conjunto de ligações semelhantes segundo algum critério. Entenderemos por atributo qualquer informação a respeito de um objeto ou de uma ligação entre objetos da qual se tenha necessidade. Por fim, entenderemos por restrição qualquer exigência que se faça a respeito de qualquer dos itens que definimos acima.

O MER é um modelo que tem como meio de expressão um simbolismo gráfico.

Entidades são representadas por um retângulo com uma inscrição interna representando o nome da entidade. Os nomes são no singular por convenção. Considere os exemplos de entidades abaixo.

por convenção. Considere os exemplos de entidades abaixo. Relacionamentos são representados por um losango com uma

Relacionamentos são representados por um losango com uma inscrição interna representando o nome do relacionamento. Os nomes são no singular por convenção. Como um relacionamento é um conjunto de ligações semelhantes, e tendo em vista que cada ligação vincula sempre dois objetos, temos que sempre existem dois sentidos associados a uma

ligação, e em última instância a um relacionamento. Acrescentamos por esta razão ao losango duas setas em sentidos opostos representando dos dois sentidos das ligações do relacionamento. Sobre estas setas, inscreve-se frases especificando cada um dos dois sentidos.

O exemplo abaixo, simboliza um relacionamento que contêm ligações que vinculam objetos

que são empregados no mundo real com objetos que são departamentos da empresa no mundo

real.

que vinculam objetos que são empregados no mundo real com objetos que são departamentos da empresa

Relacionamentos têm sempre duas cardinalidades (uma para cada sentido do relacionamento) que expressam restrições com respeito àquele relacionamento. Uma cardinalidade é escrita como um par de valores numéricos separados por uma vírgula. N representa um valor desconhecido, podendo ser arbitrariamente grande. As cardinalidades de um relacionamento costumam ser posicionadas em lados opostos do losango, no sentido das setas. O exemplo abaixo já contém uma carga semântica um pouco mais pesada que os anteriores. O que queremos dizer com o modelo abaixo é que funcionários se vinculam com dependentes pelo relacionamento posse. As setas nos dizem que funcionários têm dependentes e que dependentes são de funcionários. Lemos o modelo abaixo da seguinte maneira: um funcionário tem de 0 até N dependentes, e um dependente é de 1 e sempre um funcionário.

e um dependente é de 1 e sempre um funcionário. Como no mundo real cada objeto

Como no mundo real cada objeto pode ter diversos relacionamentos diferentes, também no modelo poderemos expressar este fato. Considere o exemplo abaixo. Nele expressamos que clientes se relacionam pelo relacionamento compra com produtos e também com duplicatas a pagar pelo relacionamento posse. Cada cliente compra de 0 até N produtos e cada produto é comprado por de 0 até N clientes. Cada cliente tem de 0 até N duplicatas a pagar e cada duplicata a pagar e de 1 e sempre 1 cliente.

Também à semelhança do mundo real, duas entidades podem ter mais de um relacionamento. Veja

Também à semelhança do mundo real, duas entidades podem ter mais de um relacionamento. Veja o exemplo abaixo. Nele, funcionários se relacionam com projetos pelos relacionamentos lotação e gerência. Cada funcionário está lotado em 1 e sempre 1 projeto e cada projeto lota de 1 até N funcionários. Além disto, cada funcionário pode gerenciar ou não um projeto e cada projeto é gerenciado por 1 e sempre 1 funcionário.

e cada projeto é gerenciado por 1 e sempre 1 funcionário. Auto relacionamentos são relacionamentos que

Auto relacionamentos são relacionamentos que expressam vínculos entre objetos de uma mesma entidade. No exemplo abaixo temos dois casos de auto relacionamentos. No primeiro, peças se relacionam com peças pelo relacionamento composição. Cada peça compõe de 0 até N outras peças e por outro lado cada peça pode compor de 0 até N outras peças. No segundo,

pessoas se relacionam com pessoas pelo relacionamento casamento. Cada pessoa pode ser casada ou não com outra pessoa.

Cada pessoa pode ser casada ou não com outra pessoa. Entidades podem ser fracas com relação

Entidades podem ser fracas com relação a outras. Isto significa que não fazem sentido se a entidade dita forte. Esta relação de fraqueza é expressa no modelo como um relacionamento com um pequeno círculo de um dos lados. A entidade do lado do círculo é a entidade fraca. No exemplo abaixo, mostramos que a entidade dependente, como o próprio nome diz, é fraca pelo relacionamento de posse com a entidade funcionário, isto é, não tem sentido sem a entidade funcionário.

isto é, não tem sentido sem a entidade funcionário. O MER é um modelo para expressar

O MER é um modelo para expressar dados e seus vínculos que se tem interesse de manter. Por esta razão, não expressamos em um MER nem operações (uma vez que não são dados nem vínculos entre dados) nem dados sobre os quais não se tenha interesse. Assim, no exemplo abaixo, mostramos a entidade paciente relacionada com a entidade consulta pelos relacionamentos agendamento e desagendamento. A menos que se tenha uma boa razão para se guardar desagendamentos, desagendamento é uma operação que se faz sobre o relacionamento agendamento. Quando desejamos agendar uma consulta, geramos uma ligação

no relacionamento agendamento, quando desejamos desagendar uma consulta, simplesmente retiramos uma ligação do relacionamento agendamento, não precisamos de um relacionamento desagendamento.

não precisamos de um relacionamento desagendamento. Como definimos acima, atributos representam as informações

Como definimos acima, atributos representam as informações que se deseja manter a respeito de uma entidade ou relacionamento.

Segundo suas funções, os atributos se classificam em chave primária, chave adicional, super chave, chave secundária e atributo comum. Mais para frente veremos que existe ainda um outro tipo de atributo, mas deixemos para comentar mais a respeito adiante.

Chave primária é o menor conjunto de atributos que identifica unicamente um único objeto em uma entidade ou uma única ligação em um relacionamento. Toda entidade e todo relacionamento possui chave primária, embora nos relacionamentos ela não seja indicada, mas sim implicitamente conhecida como a concatenação das chaves primárias das entidades relacionadas.

Às vezes, esta combinação de chaves não é o suficiente para identificar unicamente uma ligação em um relacionamento (pela possibilidade da existência de mais de uma ligação entre os mesmos dois objetos das mesmas duas entidades em um relacionamento). Nestes casos, existem duas opções: colocar uma chave adicional no relacionamento (que em conjunto com as chaves primárias implícitas identificaria unicamente uma ligação) ou colocar uma super

chave no relacionamento (que sozinha identificaria unicamente uma ligação no relacionamento, se sobreporia às chaves primárias implícitas que continuariam implícitas, mas sem propriedades de chave primária).

Chaves secundárias são chaves que não identificam unicamente um único objeto em uma entidade ou uma única ligação em um relacionamento, mas sim um grupos deles.

Por fim, atributos comuns são atributos sem nenhuma função especial, representam tão somente informações que se deseje manter sobre objetos de entidades ou ligações de relacionamentos.

Vale a pena ressaltar o fato de que não se pode expressar com o MER atributos iterativos (repetitivos), por esta razão não se pode ter atributos com nome no plural.

Aconselha-se que em paralelo à construção do modelo, vá se construindo também um contendo informações sobre os dados do BD (nome, tipo, tamanho, visões em que está envolvido e em que operações, etc.).

Qualquer que seja o tipo do atributo, eles sempre são representados por uma haste com um símbolo em uma das extremidades que indica o tipo do atributo seguido do nome do atributo. Veja abaixo o símbolo de cada um dos atributos acima mencionados.

o símbolo de cada um dos atributos acima mencionados. O símbolo de chave primária é um

O símbolo de chave primária é um asterisco seguido opcionalmente por um número. Este número serve para numerar os componentes da chave primária em caso de chave composta.

O símbolo de chave adicional é um sinal de mais seguido opcionalmente por um número. Este número serve para os mesmos fins do número que segue opcionalmente o símbolo de chave primária.

O símbolo de super chave é um sinal de sustenido seguido opcionalmente por um número.

Este número serve para os mesmos fins do número que segue opcionalmente o símbolo de chave primária.

O símbolo de chave secundária é uma letra S seguida opcionalmente por um número. Este

número serve para diferenciar as chaves secundárias em caso de haver mais de uma. Este número pode ser seguido opcionalmente por outro número separado do primeiro por uma vírgula. Este segundo número serve para os mesmos fins do número que segue opcionalmente o símbolo de chave primária.

Veja no exemplo abaixo atributos apropriadamente dispostos em entidades e relacionamentos.

O que se pretende expressar é que a entidade cliente tem com chave primária o atributo CGC,

como uma chave secundária o atributo RamAtivdd, como outra chave secundária composta os atributos Estado e Cidade, e com o atributo comum RazSoc. A entidade produto tem como

chave primária o atributo Cod, e como atributo comum Nome. Por fim, o relacionamento compra tem como chave adicionam o atributo Data, e como atributo comum Qtd.

chave adicionam o atributo Data, e como atributo comum Qtd. Às vezes, entidades se classificam em

Às vezes, entidades se classificam em alguns tipos, cada tipo tendo atributos próprios diferenciados. Surge para isto o conceito de hierarquia. Existem dois tipos de hierarquias conforme pode-se observar no exemplo abaixo. O primeiro desenho representa uma hierarquia sem interseção e o segundo uma com interseção.

Qualquer que seja o tipo de uma hierarquia, a entidade superior detém os atributos comuns a todos os membros da hierarquia e as inferiores os atributos próprios a cada uma delas.

É perfeitamente possível se ter árvores de hierarquia mais profundas, isto é, hierarquias sob hierarquias. Também é possível se ter mais de uma hierarquia sob uma mesma entidade. Todas entidades que participam de uma hierarquia são entidades como outra qualquer, portanto podem ter seus atributos e relacionamentos. Não faz sentido uma hierarquia em que não haja atributos ou relacionamentos próprios nas entidades inferiores.

No primeiro desenho, vemos que veículos se classificam em aéreo, terrestre e marítimo, podendo um veículo ser de um, dois ou dos três tipos concomitantemente.

No segundo desenho, vemos que funcionários se classificam em motorista, secretária e engenheiro, não podendo alguém que ocupa uma função ocupar também outra.

se classificam em motorista, secretária e engenheiro, não podendo alguém que ocupa uma função ocupar também
se classificam em motorista, secretária e engenheiro, não podendo alguém que ocupa uma função ocupar também

Surge com as hierarquias sem interseção aquele último tipo de atributo que havíamos

mencionado acima. Trata-se do atributo classificador, que serve para dizer de que tipo (onde

se encontra nas entidades inferiores) é cada objeto da entidade superior.

Este tipo de atributo é representado por uma haste seguida por uma letra C e pelo nome do atributo. Note no exemplo abaixo, que além da novidade do atributo classificador, não se usa colocar chave primária nas entidades inferiores de uma hierarquia uma vez que estas têm como chave primária a chave primária da entidade superior.

como chave primária a chave primária da entidade superior. O último conceito que introduziremos é o

O último conceito que introduziremos é o conceito de agregação. Usa-se agregação quando se

tem duas entidades relacionadas por um relacionamento e se deseja relacionar através de outro

relacionamento uma terceira entidade não com a primeira entidade, nem com a segunda, mas com as duas relacionadas. Agregados têm como chave primária a chave do seu relacionamento interno.

No exemplo abaixo, temos a entidade aluno relacionada não coma entidade professor, não com a entidade matéria, mas sim com ambas relacionadas pelo relacionamento ministério.

sim com ambas relacionadas pelo relacionamento ministério. Segue agora um exemplo mais complexo que envolve quase

Segue agora um exemplo mais complexo que envolve quase todos conceitos apresentados até agora.

Nele temos a entidade matéria relacionada com a entidade turma pelo relacionamento posse (cada matéria tem de 0 até N turmas e cada turma é de 1 até N matérias, sendo a entidade turma fraca pelo relacionamento posse com a entidade matéria.

Estas duas entidades relacionadas, se relacionam pelo relacionamento ministério com a entidade professor (cada turma de matéria se é ministrada por 1 e sempre 1 professor e cada professor ministra de 0 até N turma de matéria), pelo relacionamento faz com a entidade aluno (cada turma de matéria é feita por de 0 até N alunos e cada aluno faz de 0 até N turma de matéria) e pelo relacionamento fez também com a entidade aluno (cada turma de matéria foi feita por de 0 até N alunos e cada aluno fez de 0 até N turma de matéria).

A entidade matéria se relaciona pelo relacionamento PreReq consigo própria (cada matéria é pré-requisito de 0 até N matérias, podendo também ter como pré-requisito de 0 até N matérias).

As entidades professor, graduação e pós-graduação formam uma hierarquia com interseção, sendo a primeira a entidade superior e as duas últimas entidades inferiores.

A entidade matéria tem chave primária Cod e atributos comuns Nome e Ementa. A entidade turma tem como chave primária os atributos Letra, Semestre e Ano. A entidade professor tem como chave primária Matr e como atributos comuns Nome e Ender. A entidade graduação que representa os professores de graduação, tem como chave primária implícita Matr e como atributo comum próprio o atributo Local da Graduação. A entidade pós-graduação que representa os professores de pós-graduação, tem a mesma chave primária implícita mencionada acima e como atributo comum próprio o atributo Área de Orientação. A entidade aluno tem como chave primária o atributo RA e como atributos comuns Nome e Ender. O relacionamento fez tem como atributos comuns Nota e Freq. Todos os relacionamentos têm como chave primária as chaves das duas entidades que eles relacionam. A chave da entidade agregada é a chave do relacionamento posse em seu interior.

das duas entidades que eles relacionam. A chave da entidade agregada é a chave do relacionamento

Poderíamos definir esta fase como sendo a construção de uma representação do conhecimento

de uma organização orientada para a representação dos dados envolvidos e das relações dos

dados entre si. Tem-se por objetivo captar o mais fielmente possível a realidade da

organização a fim de prover base para a implantação física de um BD.

Como dissemos anteriormente, a construção do modelo conceitual é feita normalmente em

duas fases: a construção dos modelos conceituais parciais (um para cada visão identificada na

fase anterior) e a integração deles na formação do modelo conceitual global.

Esta parte do modelo conceitual tem duas componentes: uma representação gráfica e uma

linguagem descritiva. Representaremos graficamente os dados e suas relações e nos

utilizaremos da linguagem descritiva a fim de descrever as operações que são realizadas sobre

os dados. Desta maneira, teremos expressos no modelo tanto os aspectos estáticos (dados)

como dinâmicos (operações). Deve-se ainda ter expresso neste modelo restrições semânticas e

de integridade.

Como representação gráfica dos dados, suas relações e algumas restrições semânticas e de

integridade, sugerimos que se use o MER. Como linguagem descritiva das operações que são

realizadas sobre os dados e de algumas restrições semânticas e de integridade que não

puderam ser representadas graficamente através do MER, sugerimos que se use algo como

português estruturado.

É imprescindível advertir que durante a construção dos MER, deve-se evitar ao máximo

pensar em processos, arquivos e fluxos de informação. Vale a pena ressaltar que no modelo de

uma visão, só devem aparecer os dados que são usados naquela visão, e da maneira como são

usados. Assim, é perfeitamente possível haver uma entidade ou um relacionamento em uma

visão com um conjunto de atributos diferentes daquele que possua em uma outra visão. Além

disto, podem existir atributos que em uma visão sejam comuns e em outra sejam chaves

secundárias, e assim por diante. O atributo chave primária deve ser o mesmo sempre em todas

as visões tanto para entidades como para relacionamentos. A cardinalidade de um

relacionamento também é sempre a mesma em todas as visões. É possível que uma entidade

apareça em uma visão como parte de uma hierarquia, com determinados relacionamentos ou

como parte de um agregado, e em outra visão não.

O modelo conceitual global é construído a partir dos modelos conceituais parciais de uma

maneira incremental. A maneira mais simples que conheço de se entender como se dá a

construção do modelo conceitual global é através de uma alegoria.

Basicamente, tudo que deve ser feito é transportar para o papel em branco onde será

construído o modelo conceitual global, todos os modelos conceituais parciais com o cuidado

de fazer com que elementos do modelo parcial (entidades, relacionamentos atributos,

agregados e hierarquias) que está sendo transportado que já se encontrem presentes no modelo

global se sobreponham de maneira incremental.

Desta maneira, se ao transferirmos uma entidade ou um relacionamento de um modelo parcial

para o modelo global observarmos que esta entidade ainda não se encontra transferida para o

modelo global, tudo o que teremos que fazer será copiá-la para lá. Se ao contrário,

observarmos que esta entidade já se encontra transferida, tudo que teremos que fazer será

adequar os atributos no modelo global.

Antes de dizermos como proceder essa adequação, convém agora definirmos alguns termos

que empregaremos a seguir. Entenderemos por atributo sem função especial qualquer atributo

que não seja chave primária, chave adicional, super chave, chave secundária, nem

classificador. Entenderemos por atributo com função especial aqueles atributos que possuírem

uma das funções acima mencionadas (chave primária, chave adicional, super chave, chave

secundária ou classificador).

Passaremos agora a descrever o processo de adequação dos atributos no modelo conceitual

global quando da transferência de uma entidade ou relacionamento já presente neste modelo.

Se no modelo parcial houverem atributos que não se encontrem presentes no modelo global,

tudo que temos que fazer será transportá-los para o modelo global.

Se no modelo parcial houverem atributos sem função especial que já se encontrem presentes

no modelo global sem função especial prevalecerá a função que já se possuem no modelo

global, e tudo ficará como está.

Se der o contrário, no parcial houverem atributos com função especial que já se encontrem

presentes no modelo global sem função especial, prevalecerá a função que possuem no modelo

parcial, e alteraremos o modelo global.

Se no modelo parcial houver um atributo com função especial que já se encontra presente no

modelo global também com função especial, neste caso o atributo passará a acumular funções.

Agregados e hierarquias são simplesmente transportados dos modelos parciais para o global.

Como já havíamos comentado anteriormente, esta fase se compõe de duas subfases (a

construção do modelo interno preliminar e a otimização deste) que passaremos a detalhar em

seguida.

O objetivo desta fase é trabalhar o modelo conceitual global a fim de eliminar, ou melhor

transformar em entidade qualquer coisa presente no modelo conceitual global que não seja

entidade. O modelo conceitual global trabalhado para ser constituído somente por entidades

será o modelo interno preliminar.

Como perceberemos a seguir, os casos possíveis que poderemos ter que analisar são

virtualmente infinitos. Desta maneira, nosso objetivo nesta parte do estudo é o de formar uma

linha de pensamento que possa ser utilizada quando em face a uma situação real nova.

Por simplicidade, inicialmente deixaremos de lado qualquer tipo de MER diferente de duas

entidades relacionadas por um relacionamento. Qualquer que seja a cardinalidade do

relacionamento, sempre é possível reduzir o MER a três entidades. Em alguns casos é possível

a redução a duas e até mesmo a uma. Seremos sempre ambiciosos, desejando a máxima

redução possível. Consideraremos a seguir algumas possibilidades para a cardinalidade do

relacionamento.

Nesta situação, cada objeto de A se relaciona com exatamente um objeto de B (um objeto

de A possui exatamente uma ligação no relacionamento R) e vice versa.

Desta maneira é possível a redução do MER a uma só entidade ARB que aglutinaria os atributos de A, de R e de B, naturalmente eliminando os possíveis atributos comuns.

Neste caso, cada objeto de A pode estar relacionado com de 1a N objetos de B (um objeto de A pode possuir de 1 a N ligações no relacionamento R). B por sua vez sempre se relaciona com exatamente um objeto de A (um objeto de B pode possuir uma e somente uma ligação no relacionamento R).

Como não somos capazes de precisar a quantidade de relacionamentos que um objeto de A poderá vir a ter com um objeto de B, não poderemos aglutinar o MER em uma única entidade onde cada objeto representasse um objeto de A, todos seus relacionamentos com objetos de B, e os próprios objetos de B relacionados.

Para alcançarmos a solução mais ambiciosa (uma entidade ARB), existe ainda uma possibilidade. Podemos aglutinar o MER em uma única entidade onde cada objeto representasse um objeto de A, um relacionamento com um objeto de B, e o próprio objeto de B relacionado. Neste caso, como os objetos de A podem ter muitos relacionamentos com objetos de B, teremos muitos objetos na entidade aglutinada associados a um único objeto de A. Isto naturalmente caracteriza uma redundância, mas se soubermos de antemão

que na prática a probabilidade dos objetos de A terem muitos relacionamentos com objetos

de B é baixa, poderemos optar por esta solução.

Existem ainda duas possibilidades mais modestas (duas entidade): aglutinar A com R em uma entidade AR deixando B só; e deixar A só aglutinando R com B em uma entidade RB.

A primeira possibilidade não faz muito sentido, pois encerra os mesmos problemas da

aglutinação em uma única entidade. Assim temos como viável somente a segunda possibilidade.

Neste caso, cada objeto de A pode estar relacionado com de 1a N objetos de B (podendo um objeto de A possuir de 1 a N ligações no relacionamento R) e vice versa.

Podemos raciocinar de maneira semelhante à que utilizamos no caso anterior.

Para aglutinarmos o MER em uma única entidade ARB, teríamos que garantir que a probabilidade dos objetos de A terem muitos relacionamentos com objetos de B é baixa e também que a probabilidade dos objetos de B terem muitos relacionamentos como objetos de A é baixa.

Para aglutinarmos o MER em duas entidade AR e B teríamos que garantir que a probabilidade dos objetos de A terem muitos relacionamentos com objetos de B é baixa.

Para aglutinarmos o MER em duas entidade A e RB teríamos que garantir que a probabilidade dos objetos de B terem muitos relacionamentos com objetos de A é baixa.

Sempre podemos ficar com três entidades A, R, e B. Vale a pena lembrar, que a maneira de julgar se uma probabilidade é baixa ou não depende do caso que tratamos (depende fundamentalmente do número de objetos e ligações que se espera ter nas entidades e relacionamento respectivamente).

Neste caso, cada objeto de A pode estar relacionado com nenhum ou exatamente um objeto de B (um objeto de A pode não ter, ou ter exatamente uma ligação no relacionamento R). B por sua vez, sempre se relaciona com exatamente um objeto de A (um objeto de B tem exatamente uma ligação no relacionamento R).

Podemos levantar duas possibilidades uma mais ambiciosa (aglutinar A, R e B em uma entidade ARB, deixando os atributos de R e de B nulos no caso de um objeto de A não ter relacionamentos) e uma mais modesta (aglutinar R com B na entidade RB deixando A só).

Se a probabilidade de um objeto de A não possuir relacionamento com um objeto de B for baixa, poderemos optar pela primeira solução. Em qualquer caso, sempre poderemos ficar com a segunda solução.

O raciocínio para o caso dos auto relacionamentos é idêntico ao que tivemos quando tratamos

dos relacionamentos comuns. No caso de cardinalidade 1,1 - 1,1 teremos uma única entidade

AR que aglutina dois objetos de A e uma ligação de R e nos casos 1,1 - 1,N e 1,N - 1,N poderemos ter uma única entidade ou duas. Ampliemos agora nosso universo, deixando de lado somente os agregados e as hierarquias e passando a trabalhar com MER com diversas entidades e relacionamentos.

O processo é simples. Escolhemos sempre um relacionamento e suas entidades (talvez uma só,

no caso de auto relacionamento)para começar. Procedemos conforme o raciocínio desenvolvido acima. Se alguma das entidades primitivas possuíam algum relacionamento com outra entidade não considerada na operação, este relacionamento é transferido para a entidade que aglutinou a entidade primitiva (no caso de ter havido aglutinação). Repete-se este processo até que não se tenha mais relacionamentos no MER.

O caso das hierarquias é o mais simples de todos, em geral o processo se resume em eliminar a

hierarquia, deixando apenas entidades soltas. Existem no entanto algumas outras possibilidades que passaremos a considerar.

No caso das hierarquias sem interseção cuja entidade superior não possua relacionamento, poderemos fazer uma espécie de implosão, trazendo os objetos apropriados da entidade superior para cada entidade inferior.

No caso das hierarquias com interseção cuja entidade superior não possua relacionamento, poderemos fazer a mesma implosão, mas neste caso haverá redundância que teremos que considerar probabilisticamente a viabilidade de manter.

No caso dos agregados, procedemos com segue. Faremos o processo comum com o relacionamento e a(s) entidade(s) interna(s) ao agregado. Eliminamos o agregado, deixando somente as entidades possivelmente aglutinadas em seu interior. Todos os relacionamentos

com o agregado deverão ser transferidos para a entidade que aglutinou o relacionamento que

estava dentro do antigo agregado.

Quando falamos em otimização do modelo interno, falamos em particionamentos de arquivos.

Particionamentos podem ser horizontais ou verticais. Entendemos por particionamento

horizontal de um arquivo, a separação de grupos de registros deste arquivo em arquivos

separados; e por particionamento vertical de um arquivo, a separação de campos deste arquivo

em arquivos separados.

É importante notar, que pode-se ter interseções, isto é, em um particionamento horizontal

podemos levar certos grupos de registros para mais de um arquivo, e em um particionamento

vertical podemos levar certos grupos de campos para mais de um arquivo.

Vale a pena ressaltar, que um arquivo pode ser particionado tanto horizontal como

verticalmente em qualquer ordem. Os arquivos resultantes de um particionamento também

podem ser particionados em mais arquivos.

Particionamentos têm por objetivo isolar em arquivos separados e menores, informações que

possuem uma grande taxa de acesso, aumentando assim a eficiência do acesso ao BD.

Agora que temos os arquivos físicos otimizados resultantes do modelagem, podemos retornar

aos modelos conceituais parciais (visões) para a implementação do algoritmo em português

estruturado associado a cada visão, que poderá ser feita sob um SGBD ou em uma linguagem

de programação adequada.

Linguagens de consulta fazem parte de uma classe de linguagens que costumamos chamar de

linguagens de quarta geração.

Para melhor compreendermos o que são linguagens de quarta geração e as implicações

oriundas de seu advento, faremos uma analogia.

Antes da analogia propriamente dita, vale a pena equalizar os termos que usaremos. Entendemos por linguagens de primeira geração a programação direto em linguagem de máquina (binário), por linguagens de segunda geração os montadores de maneira geral e por linguagens de terceira geração a grande maioria das linguagens de programação em uso nos dias de hoje.

Consideremos o que se ganhou com o surgimento de cada nova geração de linguagens. Por um lado, ganhou-se maior de conforto para o desenvolvedor na tarefa de escrever programas, maiores facilidades de manutenção, maior vida útil dos sistemas e maior portabilidade. Naturalmente, existe outro lado a se considerar ganhamos linguagens cada vez mais específicas para determinados tipos de aplicação e programas bastante maiores e mais lentos.

Felizmente, com a constante melhoria do elemento hardware estas desvantagens têm se tornado cada vez mais insignificantes, o que vêm possibilitando o surgimento de uma nova geração de linguagens, a quarta.

Após o comentado acima a cerca das conseqüências do surgimento de cada geração de linguagens, é fácil imaginar o que nos espera com o surgimento desta nova geração.

Não é sem motivo que introduzimos este tópico no estudo deste curso, como já dissemos, as linguagens que estudaremos a seguir fazem parte da quarta geração de linguagens e mais especificamente à família das linguagens de consulta.

Linguagens de consulta, como diz o próprio nome, são linguagens dedicadas à consulta a bancos de dados. Existem inúmeras linguagens de consulta implementadas e em uso nos mais diversos ambientes computacionais.

Por um lado, seria de fato impraticável estudar exaustivamente todas as linguagens de consulta, por outro, seria restringente o estudo de apenas uma ou outra delas.

Felizmente, todas elas possuem uma de duas raízes teóricas, e são a estas linguagens teóricas, que serviram de base para as linguagens reais que temos nos dias de hoje, que nos dedicaremos a seguir.

Para podermos compreender cálculo relacional e conseguir expressar consultas a BD através

desta linguagem, primeiramente faz-se necessário que mudemos um pouco a visão que temos

de um BD.

Normalmente quando pensamos em BD, talvez por influência do modelo relacional, pensamos

em uma porção de tuplas organizadas em tabelas.

Desta maneira, quando desejamos obter informações a partir do BD, tudo que tem que ser

feito é construir a resposta através de particionamentos e junções, tanto verticais como

horizontais.

Introduziremos a seguir a forma que a linguagem cálculo relacional supõe estar o BD, não

significando isto, que o BD efetivamente esteja neste formato, o que vai depender da

implementação da linguagem baseada em cálculo relacional.

Para o cálculo relacional, o BD se compõe por uma grande quantidade de tuplas, todas

misturadas (não organizadas em tabelas). No entanto lá, não existem somente as tuplas que

poderíamos chamar de "originais", existem também todas a tuplas resultantes de todas as

possíveis partições das tuplas originais, e existem ainda, todas as tuplas resultantes de todas as

possíveis junções das tuplas originais entre si, das partições das tuplas originais entre si, e das

tuplas originais com as partições das tuplas originais.

Se pararmos para pensar por um momento, considerando que neste universo de tuplas existem

todas as tuplas originais, todas as partições das tuplas originais, todas as junções das tuplas

originais entre si, das partições das tuplas originais entre si, e das tuplas originais com as

partições das tuplas originais, chegaremos à conclusão de que neste universo de tuplas existem

respostas para todas as possíveis consultas que se queira farão BD, e tudo que temos que fazer

com o cálculo relacional é especificar, compor, selecionar deste universo a resposta que

desejamos.

Para especificar uma resposta em cálculo relacional, temos que antes estudar sua sintaxe e

semântica. Para tal, apresentaremos a seguir, uma seqüência de definições que nos dirão a

respeito desta sintaxe e semântica.

Assumiremos que se conheça o que é uma constante, uma variável, uma função, e argumentos de uma função. Desta maneira, definimos:

Um predicado é o mesmo que uma função booleana;

Um término pode ser uma constante, uma variável ou um símbolo de função de grau N seguida por N términos (seus N argumentos);

Uma fórmula atômica é um símbolo de predicado de grau N seguido por N términos (seus N argumentos);

Para definir fórmula bem formada diremos:

Toda fórmula atômica é uma fórmula bem formada;

Se F é uma formula bem formada, então F (F negado) também é uma fórmula bem formada;

Se F 1 e F 2 são fórmulas bem formadas, então F 1 F 2 (F 1 e F 2 ), F 1 F 2 (F 1 ou F 2 ), F 1 F 2

(F 1 implica F 2 ), ( x) [F 1 , F 2 ] (existe uma tupla X dentre as que satisfazem F 1 que também

satisfaz F 2 ) e ( x) [F 1 , F 2 ] (qualquer das tuplas X que satisfazem F 1 também satisfazem F 2 )

também são fórmulas bem formadas.

Sendo t uma variável e (t) uma fórmula bem formada em função de t, toda consulta em

cálculo relacional tem a forma: {t / (t)}.

Consideraremos como predicados pré definidos todos os nomes de tabelas do BD. Estes predicados recebem como argumento uma tupla (são predicados de grau 1) e têm o seguinte comportamento: produzem resultado verdadeiro sempre que a tupla passada como argumento for um membro daquela tabela, e resultado falso no caso contrário.

Consideraremos ainda como funções pré definidas as funções tuple (atr 1 ,

como resultado uma tupla formada pela concatenação dos n atributos fornecidos como

argumento) e concat (tpl 1 , fornecidas como argumento).

atr n ) (que produz

,

,

tpl n ) (que produz como resultado a concatenação das n tuplas

Conhecidos os fundamentos do cálculo relacional, nada melhor para fixar os conceitos do que

concretizar tudo em um exemplo. Para isto, consideremos o BD que nos serviu de modelo para

os exemplos de álgebra relacional. Para maior comodidade, reproduziremos o modelo

mencionado abaixo:

Consideremos agora que desejamos nos utilizar deste BD e, com cálculo relacional, responder

às consultas abaixo:

Quais os alunos de PD do 1º ano?

{t / Alu_1 o _Ano (t) t.CodCur = PD}

Quais os nomes dos alunos do 1º ano?

{t / ( x) [Alu_1 o _Ano (t), tuple (x.NomAlu) = t]}

Qual o nome do curso do aluno 90147 do 3º ano?

{t / ( x) [Alu_3 o _Ano (t), x.RAAlu = 90147 ( y) [Curso (y), x.CodCur = y.CodCur

tuple (y.NomCur) = t]]}

Quais os alunos do colégio?

{t / Alu_1 o _Ano (t)

Alu_2 o _Ano (t)

Alu_3 o _Ano (t)}

Para iniciarmos o estudo de álgebra relacional, faremos uma analogia desta com a álgebra

tradicional da matemática. Naturalmente, não é nossa intenção um estudo profundo nem

rigoroso da álgebra matemática, mas apenas tomar emprestado algumas idéias que poderão

nos ser úteis no estudo que faremos a seguir.

Poderíamos dizer que o universo da álgebra matemática é povoado por expressões algébricas

cujos componentes chamamos de operandos e operadores, sendo que os operandos pertencem

a algum conjunto de números, e o resultado das expressões também. Poderíamos pensar que

este universo é povoado por "contas".

De maneira análoga, o universo da álgebra relacional também é povoado por expressões de

álgebra relacional cujos componentes também chamamos de operandos e operadores.

Poderíamos, também aqui, pensar que este universo é povoado por "contas", só que desta vez,

o que temos são contas diferentes, uma vez que os operandos da álgebra relacional são tabelas

de um BD e o resultado das expressões também.

Agora que já conhecemos os conceitos que estão por trás desta linguagem de consulta,

passemos a averiguar quais são os operadores desta linguagem.

 

O

operador seleção tem como símbolo a letra grega sigma ( ).

Sua forma geral é:

tab [cond].

 

Seu efeito é criar uma tabela com as tuplas da tabela que satisfazem a condição e

devolvê-la como resultado.

 

O

operador projeção tem como símbolo a letra grega pi ( ).

Sua forma geral é: tab [atr_1,

,

atr_n ].

Seu efeito é criar uma tabela com todas as tuplas da tabela ,porem somente com os

atributos especificados entre colchetes, e devolvê-la como resultado.

 

O

operador produto cartesiano tem como símbolo a letra .

Sua forma geral é: tab1 tab2.

 

Seu efeito é promover todas as combinações possíveis entre tuplas de e

concatenando-as em uma única tupla, e com estas tuplas resultantes desta concatenação,

criar uma tabela que é devolvida como resultado.

 

O operador junção tem como símbolo o caracter *.

Sua forma geral é: tab1 tab2 [cond].

Seu efeito é promover todas as combinações possíveis entre tuplas de e concatenando-as em uma única tupla, e destas tuplas resultantes da concatenação, tomar apenas aquelas que satisfizerem e criar uma tabela que é devolvida como resultado.

 

O

operador união tem como símbolo o símbolo de união da matemática (

). (UNION)

Sua forma geral é: tab1

tab2.

 

Este operador possui a restrição de somente poder operar em tabelas que possuem a mesma estrutura.

Seu efeito é tomar de e de todas as suas tuplas, criando uma tabela com todas elas juntas e devolvê-la como resultado.

 

O

operador interseção tem como símbolo o símbolo de interseção da matemática ( .

Sua forma geral é: tab1

tab2.

 

Este operador possui a restrição de somente poder operar em tabelas que possuem a mesma estrutura.

Seu efeito é tomar de aquelas tuplas que também estão em , criar com elas uma tabela e devolvê-la como resultado.

 

O operador diferença tem como símbolo o símbolo de diferença da matemática (-).

Sua forma geral é: tab1 - tab2.

Este operador possui a restrição de somente poder operar em tabelas que possuem a mesma estrutura.

Seu efeito é tomar de aquelas tuplas que não estão também em , criar com elas uma tabela e devolvê-la como resultado.

Conhecidos os operadores da álgebra relacional, nada melhor para fixar os conceitos do que concretizar tudo em um exemplo. Para isto, consideremos o seguinte BD:

Consideremos agora, que desejamos nos utilizar deste BD e, com álgebra relacional, responder às consultas abaixo:

Quais os alunos de PD do 1º ano? Alu_1º_Ano [CodCur = PD]

Quais os nomes dos alunos do 1º ano? Alu_1º_Ano [NomAlu]

Qual o nome do curso do aluno 90147 do 3º ano? (( Alu_3º_Ano [RA = 90147]) * Curso [1.CodCur = 2.CodCur]) [NomCur]

Quais os alunos do colégio?

Alu_1º_Ano

Alu_2º_Ano

Alu_3º_Ano

SQL é uma linguagem unificada de dados para:

1. Definição de dados (criar tabelas, visões);

2. Acesso a dados (consultas);

3. Manipulação de dados (operações);

4. Controle de acesso a dados (definir em que parte do BD o usuário pode manipular).

SQL existe em duas modalidades:

1. Como linguagem autônoma, interativa, permitindo que através de um terminal ou computador o usuário acesse diretamente os dados que procura;

2. Como sub linguagem de programação, interna à uma outra linguagem como COBOL,

Dbase, que se encarregue das estruturas básicas de programação, da formatação de

telas, impressão de relatórios, etc.

Toda estrutura SQL deriva da álgebra e do cálculo relacional. O usuário especifica o resultado

desejado e não o método de obter o resultado.

O formato dos comando SQL é livre, podendo usar uma ou mais linhas. O comando deve ser

terminado por um “;”.

Sintaxe:

CREATE DOMAIN <dominio> <tipo>;

Tipos Válidos:

Cadeia de caracteres (possivelmente constituída de letras,

dígitos e caracteres especiais) de tamanho fixo T.

Cadeia de caracteres (possivelmente constituída de letras,

dígitos e caracteres especiais) de tamanho variável

limitado a no máximo T caracteres.

Número inteiro com faixa de valores válidos dependente

do equipamento.

Número inteiro com faixa de valores válidos dependente

do equipamento.

Número real de ponto fixo com tamanho T (que inclui

eventual sinal e o ponto decimal) e D dígitos à direita do

ponto decimal.

Número real de ponto flutuante com faixa de valores

válidos dependente do equipamento.

Número real de ponto flutuante com faixa de valores

válidos dependente do equipamento.

Número real de ponto flutuante com precisão de no

mínimo D dígitos.

Data representada por ano (com 4 dígitos), mês e dia do

mês.

Exemplo:

Horário representado por horas, minutos e segundos.

CREATE DOMAIN NomeAluno CHAR (30);

Sintaxe:

DROP DOMAIN <dominio>;

Exemplo:

DROP DOMAIN NomeAluno;

Sintaxe:

CREATE TABLE <tabela> ( <coluna> <tipo> [NOT NULL] [, ] [,<coluna> <tipo> [NOT NULL]] [PRIMARY KEY (<coluna> [,<coluna>] [, ] [,<coluna>])] [FOREIGN KEY (<coluna> [,<coluna>]

[, ] [,<coluna>]) REFERENCES <tabela> [ON DELETE CASCADE] [ON UPDATE CASCADE]] [ ] [FOREIGN KEY (<coluna> [,<coluna>] [, ] [,<coluna>]) REFERENCES <tabela> [ON DELETE CASCADE] [ON UPDATE CASCADE]] [CHECK <condicao>]);

Exemplo:

CREATE TABLE alunos3oPD (RA SMALLINT, Nome CHAR (30));

A cláusula NOT NULL proíbe que a coluna receba valor nulo;

A cláusula PRIMARY KEY especifica a chave primária da tabela;

A cláusula CHECK especifica uma condição que constitui uma restrição de

integridade que precisa ser verificada para toda linha da tabela criada.

Sintaxe:

ALTER TABLE <tabela> ADD ( <coluna> <tipo> [, ] [,<coluna> <tipo>]);

Exemplo:

ALTER TABLE alunos3oPD ADD (Apelido CHAR (15));

Sintaxe:

ALTER TABLE <nome da tabela> DROP ( <coluna>

[,

[,<coluna>);

]

Exemplo:

ALTER TABLE alunos3oPD DROP (Apelido);

Sintaxe:

DROP TABLE <tabela>;

Exemplo:

DROP TABLE professores;

Sintaxe:

CREATE [UNIQUE] INDEX <indice> ON <tabela> (<coluna> [ASC/DESC] [,<coluna> [ASC|DESC]]

[,

[,<coluna> [ASC/DESC]]);

]

[UNIQUE] é um parâmetro opcional que teta a duplicidade de dados na chave de

indexação.

[ASC|DESC] indica que o índice será baseado na coluna podendo se ascendente ou

descendente.

As demais colunas especificadas na sintaxe servem para desempatar a primeira coluna

índice.

Exemplo:

CREATE INDEX indice_materia ON materias (cod_mat ASC);

Restrições:

Índice só pode estar associado a tabelas e nunca à visões;

Não é possível misturar chaves ascendentes e descendentes no mesmo índice.

Sintaxe:

DROP INDEX <indice>;

Exemplo:

DROP INDEX indice_materia;

Sintaxe:

INSERT INTO <tabela> [(<coluna> [,<coluna>]

[,

[,<coluna>]]

]

VALUES(<valor>

[,<valor>]

[,

[,<valor>]);

]

Exemplo:

INSERT INTO alunos3oPD VALUES (90057, “André”, “Boca”);

Sintaxe:

DELETE FROM <tabela>

[WHERE <condicao>];

[WHERE <condicao>] é uma cláusula que determina as linhas que serão

 

eliminadas.

Exemplo:

DELETE FROM matéria WHERE nome = “FPD”;

Sintaxe:

UPDATE <tabela> SET <coluna> = <valor> [, <coluna> = <valor>] [, ] [, <coluna> = <valor>] [WHERE <condicao>];

Exemplo:

UPDATE notas SET nota = nota + 3.0 WHERE cod_mat = “01”;

Adiciona 3 pontos na nota de cada aluno da matéria 01, na tabela NOTAS.

Sintaxe Geral:

CREATE ASSERTION <assercao> <condicao>;

Sintaxe Geral:

DROP ASSERTION <assercao>;

O comando SELECT é uma query, isto é, faz pesquisas em tabelas.

Sintaxe Geral:

SELECT [ALL/DISTINCR] <coluna> [as <apelido>] [,<coluna> [as <apelido>]] [, ] [,<coluna> [as <apelido>]] FROM <tabela> [as <apelido>] [,<tabela> [as <apelido>]] [, ] [,<tabela> [as <apelido>]] [WHERE <condicao>] [GROUP BY <coluna> [,<coluna>] [, ] [,<coluna>]] [HAVING <condicao>] [ORDER BY <coluna> [ASC|DESC] [,<coluna> [ASC|DESC]] [, ] [,<coluna> [ASC|DESC]]];

Seleção Simples:

Exemplo:

SELECT * FROM notas WHERE cod_mat = “01”;

Resultado:

90218

01

9.5

90230

01

5.0

90003

01

0.5

90199

01

8.0

90109

01

8.0

Projeção Simples:

Exemplo:

SELECT nome FROM professores;

Resultado:

André

Chico

Lucius

Celso

Rogério

Vagner

Renato

Seleção com Resultados Ordenados:

Exemplo:

SELECT * FROM notas ORDER BY cod_mat, nota;

Resultado:

90003

01

0.5

90230

01

5.0

90199

01

8.0

90109

01

8.0

90218

01

9.5

.

.

.

.

.

.

.

.

.

90090

08

0.0

90113

08

1.0

90033

08

10.0

Operadores Aritméticos:

+ (sinal)

: número positivo

- (sinal)

: número negativo

** ou ^

: exponenciação

*

: multiplicação

/

: divisão

+

: soma

-

: subtração

Operadores Lógicos:

SÍMBOLO DESCRIÇÃO

=

igual a

!=

diferente de

>

maior que

>=

maior ou igual a

<

menor que

<=

menor ou igual a

AND

e

OR

ou

NOT

não

Between

And:

Testa o conteúdo de uma coluna e extrai apenas os dados

que se encontram dentro da faixa especificada.

Exemplo:

SELECT ra, nota FROM notas WHERE nota BETWEEN 5.0 AND 10.0

Resultado:

90218

9.5

90230

5.0

90033

10.0

90199

8.0

90109

8.0

In (Lista):

Opera sobre uma lista de valores e testa se o valor da coluna especificada pertence a

esta lista.

Exemplo:

SELECT * FROM professores

WHERE cod_prof IN (“01”,”04”);

Resultado:

01

André

04

Celso

Like:

Quando não se sabe o valo exato que está sendo procurado, usa-se o operador LIKE

que reconhece dois caracteres especiais: (1) corresponde a uma seqüência qualquer

de 0 ou mais caracteres; e (2) corresponde a qualquer caracter.

Exemplo:

SELECT alunos3oPD WHERE nome LIKE “R%”;

Resultado:

90223

Rachel de Carvalho Pascolino

 

90228

Raquel Moricone Pacheco

Pézinho

90229

Raquel Pinhantelli da Silva

Vamp

90230

Regiane Feltrin de Melo

90238

Ricardo Cesar Sebastião

Tião

90242

Ricardo Santos Lisboa

Pipoca

90249

Rodrigo Spadaccia

Zolhu’s

Is [Not] Null:

Verifica se a coluna especificada possui ou não um valor nulo.

Exemplo:

SELECT ra, cod_mat FROM notas WHERE notas IS NULL;

Resultado:

 

90090

09

90090

08

90090

03

Group By:

 

Agrupamento de linhas permite que as linhas da tabela de resultado sejam agrupadas,

de acordo com critérios especificados pelo usuário.

Funções de Grupo:

As funções de grupo retornam um valor para um grupo de linhas.

AVG([DISTINCT] N): calcula a média dos valores de uma coluna. Ignora

nulos.

COUNT([DISTINCT] {*|<expressão>}): conta o número de vezes que a

expressão retorna qualquer coisa diferente de nulo.

MAX(<espressao>): determina o valor máximo de uma coluna alfanumérica ou

numérica.

MIN(<expressao>]: determinado valor mínimo de uma coluna alfanumérica

ou numérica.

STDDEV ([DISTINCT] <expressão>): totaliza os valores de uma coluna.

Só pode ser usado com colunas numéricas.

VARIANCE ([DISTINCT] <expressão>): determina a variância da

expressão. Ignora nulos.

Primeiro Exemplo:

SELECT cod_mat, AVG (nota) as Media FROM notas GROUP BY cod_mat HAVING Media >= 5.0;

Resultado:

01

08

6.2

5.5

Segundo Exemplo:

SELECT COUNT (*) as Qtos FROM matérias;

Resultado: 9
Resultado:
9

Observações:

A

diferença entre as cláusulas HAVING e WHERE é que, a cláusula WHERE define

as

linhas de resultado como um todo, já a cláusula HAVING opera sobre um grupo

de

linhas.

Sub Queries:

Uma subquery é um comando SELECT que está aninhado dentro de um comando

SELECT, INSERT, UPDATE, ou DELETE.

Subqueries constituem operandos dos operandos de comparação.

Como um comando SELECT pode retornar uma lista de valores, é necessário que o

operador seja adequado ao resultado produzido pelo comando. A alternativa é que, no

caso de listas, o outro operando também seja uma lista.

Exemplo:

SELECT ra, nota FROM notas WHERE cod_mat = (SELECT cod_mat FROM matérias

WHERE nome = “LPC”);

Resultado:

90218

90230

90003

90199

90109

9.5

5.0

0.5

8.0

8.0

Observações:

A cláusulas DISTINCT, ORDER BY, UNION, INTERSECT e EXCEPT

podem ser utilizadas uma única vez na instrução SELECT inteira.

Subqueries não podem ter as cláusulas ORDER BY, GROUP BY e HAVING.

Distinct:

Como default de SELECT é ALL, sempre que a instrução SELECT é executada ela

selecionará todas as linhas que atenderem a condição especificada, mesmo que haja

duplicidade na tabela de resultado.

Com a cláusula DISTINCT as linhas repetidas desaparecem da tabela de resultados

(embora continuem existindo dentro da tabela de dados).

Exemplo:

SELECT DISTINCT ra, nota FROM notas WHERE nota <= ALL (SELECT nota FROM notas);

Resultado:

90090 0.0

Os Predicados Any e All:

Os predicados ANY e ALL estão sempre associados a uma subquery.

ANY determina se a condição estabelecida pela cláusula WHERE é verdadeira para

pelo menos uma das linhas da tabela de resultado da subquery.

Exemplo:

SELECT ra, cod_mat, nota FROM notas WHERE not nota < ANY (SELECT nota FROM notas);

Resultado:

90113

08

1.0

90218

01

9.5

90287

03

3.5

90090

09

0.0

90089

05

0.5

90230

01

5.0

90118

06

1.0

90259

07

4.0

90214

04

1.5

90090

08

0.0

90090

03

0.0

90242

02

2.5

90238

04

2.5

90003

01

0.5

90074

07

3.0

90198

05

4.0

90199

01

8.0

90109

01

8.0

ALL determina se a condição estabelecida pela cláusula WHERE é verdadeira para

todas as linhas da tabela resultado da subquery.

Exemplo:

SELECT ra, nota, cod_mat FROM notas WHERE nota <= ALL (SELECT nota FROM notas);

Resultado:

90090

0.0

09

90090

0.0

08

90090

0.0

03

O Predicado EXISTS:

O predicado EXISTS está sempre associado a uma subquery e determina se a subquery

seleciona ou não alguma linha.

Em outras palavras, o predicado EXISTS permite que um SELECT selecione as linhas

que fazem com que a subquery selecione ou não alguma linha.

O predicado EXISTS é o único que permite o uso do asterisco (*) na subquery. Outra

observação é que a subquery envolver informações da query principal.

Exemplo:

SELECT ra FROM alunos3oPD as A WHERE EXISTS (SELECT * FROM Notas as N Where N.RA = A.RA and Nota = 0);

Resultado: 90090 90090 90090
Resultado:
90090
90090
90090

O Predicado UNIQUE:

O predicado UNIQUE está sempre associado a uma subquery e determina se a

subquery seleciona ou não linhas replicadas.

Em outras palavras, o predicado UNIQUE permite que um SELECT selecione as

linhas que fazem com que a subquery selecione linhas linhas replicadas.

Exemplo:

SELECT ra FROM alunos3oPD as A WHERE UNIQUE (SELECT * FROM Notas as N Where N.RA = A.RA and Nota = 0);

Resultado:
Resultado:

Queries Correlacionadas:

A subquery é executada para cada linha selecionada no SELECT principal, diferente

dos subqueries simples que são executados somente uma vez. Para isso ocorrer, o

subquery deve fazer referência a uma coluna referente a uma tabela selecionada do

query principal.

Exemplo:

SELECT ra, nota, cod_mat FROM notas n1 WHERE nota1 > (SELECT AVG (nota) FROM notas WHERE n1.ra!= ra AND Cod_mat = n1.cod_mat ORDER BY cod_mat);

Mostra os alunos cuja nota é maior que a média das notas de todos os outros

alunos. É listado em ordem do código da matéria.

Resultado:

90218

9.5

01

90199

8.0

01

90109

8.0

01

90242

2.5

02

90287

3.5

03

90238

2.5

04

90198

4.0

05

90118

1.0

06

90259

4.0

07

90033

10.0

08

90090

0.0

09

As junções de tabelas possibilitam a criação de tabelas de resultado contendo

informações extraídas de duas tabelas de dados. Os atributos da tabela resultado de

uma junção de duas tabelas serão os atributos da primeira tabela, seguidos pelos

atributos da segunda tabela. As linhas da tabela resultado de uma junção serão obtidas

pela concatenação de linhas da primeira tabela com linhas da segunda tabela.

Existem vários tipos de junção, a saber: produto cartesiano, junção interna, junção

externa esquerda, junção externa direita e junção externa completa.

O PRODUTO CARTESIANO consiste em combinar CADA UMA das linhas da

primeira tabela com TODAS as linhas da segunda tabela. Este tipo de junção não exige

a existência de um ou mais atributos comuns às duas tabelas.

A JUNÇÃO INTERNA pressupõe a existência de um ou mais atributos comuns às

duas tabelas. SOMENTE as linhas cujos valores desses atributos comuns forem

coincidentes serão combinadas na junção interna; as linhas da primeira tabela cujos

valores desses atributos comuns não coincidirem com os valores destes mesmos

atributos de nenhuma linha da segunda tabela NÃO serão combinadas na junção

interna; as linhas da segunda tabela cujos valores desses atributos comuns não

coincidirem com os valores destes mesmos atributos de nenhuma linha da primeira

tabela NÃO serão combinadas na junção interna.

A JUNÇÃO EXTERNA ESQUERDA também pressupõe a existência de um ou mais

atributos comuns às duas tabelas. As linhas cujos valores desses atributos comuns

forem coincidentes SERÃO combinadas neste tipo de junção. As linhas da primeira

tabela cujos valores desses atributos comuns não coincidirem com os valores destes

mesmos atributos de nenhuma linha da segunda tabela TAMBÉM serão combinadas

neste tipo de junção (os valores dos atributos provindos da segunda tabela ficarão

nulos). As linhas da segunda tabela cujos valores desses atributos comuns não coincidirem com os valores destes mesmos atributos de nenhuma linha da primeira tabela NÃO serão combinadas neste tipo de junção.

A JUNÇÃO EXTERNA DIREITA também pressupõe a existência de um ou mais atributos comuns às duas tabelas. As linhas cujos valores desses atributos comuns forem coincidentes SERÃO combinadas neste tipo de junção. As linhas da primeira tabela cujos valores desses atributos comuns não coincidirem com os valores destes mesmos atributos de nenhuma linha da segunda tabela NÃO serão combinadas neste tipo de junção. As linhas da segunda tabela cujos valores desses atributos comuns não coincidirem com os valores destes mesmos atributos de nenhuma linha da primeira tabela TAMBÉM serão combinadas neste tipo de junção (os valores dos atributos provindos da primeira tabela ficarão nulos).

A JUNÇÃO EXTERNA COMPLETA também pressupõe a existência de um ou mais atributos comuns às duas tabelas. As linhas cujos valores desses atributos comuns forem coincidentes SERÃO combinadas neste tipo de junção. As linhas da primeira tabela cujos valores desses atributos comuns não coincidirem com os valores destes mesmos atributos de nenhuma linha da segunda tabela TAMBÉM serão combinadas neste tipo de junção (os valores dos atributos provindos da segunda tabela ficarão nulos). As linhas da segunda tabela cujos valores desses atributos comuns não coincidirem com os valores destes mesmos atributos de nenhuma linha da primeira tabela TAMBÉM serão combinadas neste tipo de junção (os valores dos atributos provindos da primeira tabela ficarão nulos).

Os atributos comuns que serão levados em conta para combinar linhas da primeira tabela com linhas da segunda tabela podem ser indicados explicitamente ou não.

No caso de uma junção NATURAL eles não são indicados explicitamente; TODOS os atributos comuns serão levados em conta e eles aparecerão UMA ÚNICA VEZ na tabela resultante da junção.

No caso de junções não naturais, o critério de junção precisará ser explicitado com ON

ou com USING. No primeiro caso (ON), os atributos comuns às duas tabelas

aparecerão DUPLICADOS na tabela resultante da junção. No segundo caso (USING),

os atributos comuns às duas tabelas aparecerão UMA ÚNICA VEZ na tabela resultante

da junção.

Sintaxe:

 

<tabela> [NATURAL] {INNER | LEFT OUTER | RIGHT OUTER | FULL OUTER} JOIN <tabela> [ON <condicao>] [USING (<coluna> [, <coluna>] [, ] [, <coluna>]] [AS <tabela> (<coluna> [, <coluna>] [, ] [, <coluna>])];

Exemplo de Inner Join:

 

SELECT ra, nota, nome FROM (notas NATURAL INNER JOIN materias) WHERE nota >= 8.0;

Resultado:

 
 

 
 

90218

9.5

LPC

90033

10.0

LMON

90199

8.0

LPC

90109

8.0

LPC

Exemplo de Left Outer Join:

SELECT nome_prof, nome_mat FROM (professores LEFT OUTER JOIN materias

USING (cod_prof) AS temp (cod_prof, nome_prof, cod_mat, nome_mat)) ORDER BY nome_prof;

Mostra os professores e as matérias que lecionam, mesmo que alguém não lecione

matéria alguma.

 

Resultado:

 

André

LPC

André

APSI

André

IA

Celso

CAI

Chico

CG

Lucius

ISSO

Lucius

REDES

Lucius

LMON

Renato

Rogério

FPD

Vagner

Observações:

 

AUTO JUNÇÕES (Self Joins) são o tipo de junção em que uma tabela é juntada

consigo própria.

A união de tabelas permite agrupar, em uma única tabela de resultado, as linhas de

duas outras tabelas. É imprescindível que as tabelas envolvidas tenham a mesma

estrutura, i.e., a mesma quantidade de colunas, com os mesmos nomes e tipos. Este

tipo de operação só poderá ser realizada se as tabelas envolvidas residirem no mesmo

BD.

Sintaxe:

<tabela>

UNION

<tabela>;

Exemplo:

SELECT ra, apelido FROM alunos3oPD UNION SELECT ra, apelido FROM alunos2oTA;

Mostra uma tabela com os alunos do 3 o PD e do 2 o TA.

Resultado:

89131

 

89147

Maçãzinha

89276

 

90002

Béri

90003

Kety

90030

Gaf’s

90033

 

90036

Boca

90062