Banco de Dados III

CENTRO UNIVERSITÁRIO ASSUNÇÃO
UNIFAI
JAQUELINE LACERDA DOS SANTOS
Banco de Dados – Sql
São Paulo
2003
JAQUELINE LACERDA DOS SANTOS
Banco de Dados – Sql
Trabalho de Conclusão de Curso apresentado

ao Curso de Ciências da Computação, para
obtenção parcial do grau de Bacharel* em
Ciências da Computação.
ORIENTADOR: Profº. Ms. ANDRÉ LUIZ GARCIA PEREIRA
São Paulo
2003
AGRADECIMENTOS
Primeiramente a Deus por estar sempre presente na minha vida, por me dar saúde, inteligência,
força e coragem para enfrentar todos os obstáculos.
Aos meus pais pela educação e apoio designado a mim por todos os anos de estudo.
Ao Profº. Ms. André Luiz Garcia Pereira pela atenção e colaboração no decorrer desta pesquisa,
sempre apresentado e observando os pontos de maior importância.
RESUMO
Este trabalho tem como objetivo analisar as mudanças ocorridas nos últimos anos em
relação à tecnologia de Banco de Dados. A qual sofreu várias mudanças, saindo de meras
relações hierárquicas até chegar ao conceito de objetos. Atualmente as aplicações requerem
objetos compostos com uma complexa estrutura interna, tendo um gerenciamento de
comportamentos que engloba métodos associados a objetos e suas operações, amplas regras de
negócios e longas transações.
Estas necessidades, juntamente como conhecimento adquirido ao longo da utilização da
tecnologia de armazenamento em computadores, leva-se a banco de dados sofisticados, até
mesmo orientado a objetos, que ao contrário dos primeiros bancos de dados, que caracterizam–se
por ter uma uniformidade, registros pequenos, campos de registros fixos e sem estrutura, entre
outras, caracteriza-se por seus conceitos de estrutura de objetos com seus atributos e métodos,
hierarquia de classes, múltipla herança, identidade de objetos, etc.
Com as imposições de mercado juntamente com as evoluções dos conceitos associados à
tecnologia, tem-se a garantia de que serão seguidas as regras de negócio, trazendo para os tempos
atuais, uma maior facilidade em um único objetivo: a integridade e a velocidade da informação.
SUMÁRIO
1 INTRODUÇÃO.................................................................................................... 12
2 CONCEITOS E DEFINIÇÕES DE BANCO DE DADOS.................................. 13
2.1 EXEMPLOS......................................................................................................... 15
2.2 HISTÓRICO......................................................................................................... 17
3 MODELOS DE BANCOS DE DADOS.............................................................. 19
3.1 MODELO HIERÁRQUICO................................................................................. 20
3.2 MODELO DE REDES......................................................................................... 21
3.3 MODELO RELACIONAL................................................................................... 22
3.4 AS TERMINOLOGIAS PRESENTES NO SGBD RELACIONAL................... 24
3.4.1 ARQUIVOS.......................................................................................................... 24
3.4.2 TABELAS............................................................................................................ 25
3.4.3 CAMPOS.............................................................................................................. 26
3.4.4 LINHAS................................................................................................................ 26
3.4.5 COLUNAS........................................................................................................... 26
3.4.6 REGISTROS......................................................................................................... 26
4 CHAVES............................................................................................................... 27
4.1 CHAVES PRIMÁRIA.......................................................................................... 28
4.2 CHAVE ESTRANGEIRA.................................................................................... 29
4.3 CHAVE ALTERNATIVA.................................................................................... 30
5 MODELO ENTIDADE – RELACIONAL........................................................... 31
5.1 CONJUNTO DE ENTIDADES............................................................................ 31
5.2 CONJUNTO DE RELACIONAMENTO............................................................. 32
5.3 DIAGRAMA ENTIDADE – RELACIONAMENTO.......................................... 33
5.3.1 ENTIDADES FRACAS E FORTES.................................................................... 35
6 ESTRUTURA DOS BANCOS DE DADOS RELACIONAIS............................ 36
6.1 ESTRUTURA BÁSICA....................................................................................... 37
7 O QUE É SGBD ? ................................................................................................ 38
7.1 AS VANTAGENS E DESVANTAGENS DO USO DE UM SGBD.................. 40
7.2 QUANDO NÃO UTILIZAR UM SGBD............................................................. 41
8 PARA QUE GUARDAR DADOS ( NECESSIDADES DE
ARMAZENAMENTO ) ? .................................................................................... 42
8.1 PRINCIPAIS OPERAÇÕES PARA ATUALIZAÇÃO DOS DADOS............... 43
9 NECESSIDADE DE UMA FERRAMENTA PARA ISSO SQL UMA
LINGUAGEM DE CONSULTA.......................................................................... 44
10 SQL....................................................................................................................... 45
10.1 HISTÓRICO......................................................................................................... 46
10.2 ESTRUTURA....................................................................................................... 54
10.3 UMA APLICAÇÃO DO SQL.............................................................................. 59
11 ESTUDO DE CASOS........................................................................................... 66
12 CONCLUSÃO...................................................................................................... 86
REFERÊNCIA.................................................................................... 87
LISTA DE ILUSTRAÇÕES
Figura 1 - Tabela de Dados.......................................................................................... 13

Figura 2 - Na figura abaixo é possível entender melhor o Banco de Dados com a
Representação Física................................................................................... 15
Figura 3 - Modelo Hierárquico..................................................................................... 20
Figura 4 - Modelo de Redes......................................................................................... 21
Figura 5 - Modelo de Relacional.................................................................................. 23
Figura 6 - Os discos rígidos, normalmente, são sobrepostos em pilhas, com um
pequeno espaçamento entre si para a passagem da cabeça de leitura /
gravação. Nessa posição, são chamados de Winchester. ............................ 24
Figura 7 - Tabela Cad_Curso....................................................................................... 25
Figura 8 - Tabela Cad_Curso....................................................................................... 28
Figura 9 - Tabela Cad_Dependentes............................................................................ 28
Figura 10 - Tabela Cad_Funcionário.............................................................................. 30
Figura 11 - DER............. ............................................................................................... 34
Figura 12 - DER com Entidades Fracas........................................................................ 35
Figura 13 - Tabela Endereço.......................................................................................... 37
Figura 14 - Processamento sem SGBD.......................................................................... 39
Figura 15 - Processamento com SGBD.................................................................. 39
Figura 16 - Número de Página de cada versão......................................................... 47
Figura 17 - Evolução das linguagens de consulta até o surgimento do SQL em 1999.. 49
Figura 18 - No exemplo abaixo, possui um campo do tipo CLOB que pode
armazenar até 25.000 caracteres e possui também um campo BLOB que
pode armazenar até 5.000 bytes................................................................... 50
Figura 19 - No exemplo abaixo, possui um campo do tipo ARRAY, esse campo pode
armazenar até 20 cadeias de caracteres, cada uma com 30 posições.......... 51
Figura 20 - No exemplo abaixo mostra que o tipo ROW pode ser nomeado ou não
nomeado ( ao contrário do campo CEP, TipoEndereço é um ROW
nomeado)..................................................................................................... 52
Figura 21 - No exemplo abaixo os componentes de um campo ROW são acessados
através do operador ‘.’................................................................................. 52
Figura 22 - Hierarquia de tipos de dados do SQL 1999, os retângulos destacados

correspondem aos novos tipos..................................................................... 53
Figura 23 - DER............................................................................................................. 62
LISTA DE ABREVIATURAS
DBM ( Data Base Manager - Gerenciador de Banco de Dados ).

GUAM ( Generalized Updated Access Method - Método de Acesso Atualizado Generalizado).
COBOL ( Commom Business Oriented Language – Linguagem Orientada a Transação
Comum).
PL ( Programming Language – Linguagem de Programação ).
SEQUEL ( Structured English Query Language – Linguagem de Consulta Estruturada em
Inglês ).
SQL ( Structured Query Language – Linguagem de Consulta Estruturada ).
A Relational Model of Data for Large Shared Data Banks - Um modelo de dados relacional
para grandes Bancos de Dados Compartilhados.
Communications of the ACM – ACM Comunicações.
Oracle Corporation - Corporação de oráculo.
ISO ( Internacional Organization for Standardization - Organização Internacional de
Normalização ).
ANSI ( American National Standards Institute - Instituto Americano de Padrão Nacional ).
OQL ( Object Query Language - Linguagem de Consulta à Objeto ).
ODMG ( Object Data Management Group - Grupo de Administração de Objetos e Dados ).
OMG ( Object Managment Group – Grupo de Administração de Objetos ).
ABNT ( Brazilian Association of Norms and Techniques - Associação Brasileira de Normas e
Técnicas ).
CLOB ( Character Large Object – Objeto de Caráter Grande ).
BLOB ( Binary Large Object – Objeto Binário Grande ).
1) Introdução
Objetiva-se com esse trabalho, identificar os principais avanços da tecnologia de Banco de

Dados, suas características e sua abrangência de usabilidade atual. O Banco de Dados é uma
coleção de dados inter-relacionados, representando informações sobre um domínio específico.
Existem gigantescas bases de dados gerenciando nossas vidas. Um Banco de Dados contém os
dados dispostos numa ordem pré-determinada em função de um projeto de sistema, sempre para
um propósito muito bem definido, fornecendo os conceitos básicos dos Sistemas de Bancos de
Dados, enfatizando o projeto conceitual, modelagem de dados, tópicos de programação e
integração com ambientes de desenvolvimento e técnicas mais utilizadas.
Novas tecnologias na área de Banco de Dados têm surgido. Um exemplo tem-se o Banco
de Dados Orientado a Objetos, um fator emergente, que integra Banco de Dados e a Tecnologia
de Orientação a Objetos. Os Bancos de Dados Orientados a Objetos iniciaram-se primeiramente
em projetos de pesquisa nas universidades e centros de pesquisa. Em meados dos anos 80, eles
começaram a se tornar produtos comercializados, hoje são mais de 25 produtos no mercado.
Para finalizar, será tratada nesse trabalho também a utilização da SQL (Structured Query
Language – Linguagem de Consulta Estruturada). É uma linguagem desenvolvida para permitir
que qualquer pessoa, mesmo não sendo um programador, realize uma consulta (pesquisa) a um
banco de dados, para isso, essa linguagem se aproxima muito da linguagem natural dos seres
humanos.
2) Conceitos e Definições Gerais de Banco de Dados
O Banco de Dados foi criado para guardar as informações no computador e armazena -

las em sistemas de arquivos permanentes. Pode - se definir um Banco de Dados como um arquivo
que contém dados que serão transformados em informações, que poderão ser manipuladas pelo
gerenciador de Banco de Dados.
Sendo manipulado por um conjunto de programas os quais, efetuam operações de
manutenção no Banco de Dados, como inclusões, exclusões e atualizações de dados, assim como
processos de cálculo e regravações de informações, também operações de pesquisa de
informações mais complexas para os níveis gerenciais de controle.
No Banco de Dados existem tabelas identificadas por campos e linhas; cada linha
representa um registro do Banco. Através desta organização, a busca na base de dados fica mais
fácil não importando a quantidade de linhas.
Pode - se dizer que esse conjunto de dados é tão bem organizado que pode ser utilizado e
acessado por aplicações diferentes.
TB_ENDEREÇO Nome da Tabela

COD_MORADOR
NOM_MORADOR
COD_RUA
Campos da
NOM_RUA Tabela
NUM_CASA
NUM_FONE
Fig.1.: Tabela de Dados
Um Sistema de Banco de Dados não é nada mais do que um sistema de manutenção de

registros por computador, ou seja, um sistema cujo objetivo global é manter as informações e
torná-las disponíveis quando solicitadas. [DATE, 2000].
Banco de Dados é o conjunto de dados organizados de maneira lógica, visando permitir a
otimização dos processos referentes a seu armazenamento e recuperação.
[CORNACHIONE, 1998]
Para entender se melhor o que é Banco de Dados, é necessário saber que a informação é
um “dado“ que foi processado por um determinado “sistema”, obtido de uma tal forma que seja
de utilidade pelo usuário receptor, seja para a execução de tarefas como para a tomada de
decisões.
É importante notar que alguns autores acreditam que há diferença entre dados e
informação para outros, ambos são sinônimos. [YONG, 1983].
Arquivos são um conjunto de “dados” (informações) interligados, com formato definido;
organizados por alguns critérios estabelecidos por um software DBM ( Data Base Manager –
Gerenciador de Banco de Dados ) e pelos seus usuários.
Por dados, podemos entender como “fatos conhecidos” que podem ser armazenados e que
possuem um significado não muito claro.
O significado do termo “Banco de Dados” é mais restrito e possui as seguintes
propriedades:
Um Banco de Dados é uma coleção lógica de dados com um significado ligado a

uma disposição desordenada dos dados não pode ser referenciada como um
Banco de Dados;
Um Banco de Dados é projetado, criado e armazenado com dados para um

propósito especifico, um Banco de Dados possui um conjunto pré-definido de
usuários e aplicações;
Um Banco de Dados representa alguns aspectos do mundo real, no qual é

chamando de “mini – mundo”, qualquer alteração efetuada no “mini –
mundo” é automaticamente refletida no Banco de Dados.
Arquivos
Lógicos
Informações para
o usuário
Banco de Dados
(Arquivos Físico)
Fig.2.: Na figura abaixo é possível entender melhor o Banco de Dados com a Representação
Física.
2.1) Exemplos
Existem inúmeros exemplos de Banco de Dados. Ao se procurar um número na lista

telefônica, esta sendo usado um Banco de Dados, e sempre que se recebe uma peça através de
mala direta, esse envio só é possível porque alguém usou uma lista de correspondência, que é um
Banco de Dados de nomes, usando esses exemplos, uma lista telefônica é um Banco de Dados de
nomes e clientes em potencial e endereços.
Um Banco de Dados é uma coleção de dados armazenados, usados pelo sistema de
aplicações de uma empresa especifica. Está definição requer alguma explicação, “Empresa” é
simplesmente um termo genérico conveniente para designar uma organização comercial,
cientifica, técnica ou de outra natureza que seja razoavelmente auto-suficiente.
Alguns exemplos são:

Companhias de manufaturas;
Bancos;
Hospitais;
Universidades;
Departamentos do governo.
Qualquer empresa tem necessariamente que manter uma quantidade de dados sobre suas
operações; estes são os “dados operacionais”.
Os dados operacionais das empresas provavelmente incluiriam o seguinte dados sobre:

Produtos;
Contabilidade;
Pacientes;
Estudantes;
Planejamento.
Portanto, um “Banco de Dados“ é um deposito de dados armazenados. Geralmente ele é

tanto “Integrado” como “Compartilhado”.
Integrado, significa que o Banco de Dados pode ser a união de diversos arquivos que, de
outra forma seriam distintos, eliminando parcial ou totalmente qualquer redundância entre os
arquivos;
Compartilhado, significa que partes individuais de dados podem ser compartilhados entre
diversos usuários diferentes, significando que cada um daqueles usuários pode ter acesso à
mesma parte do dado (e pode usá-la para finalidades diferentes).
Um Banco de Dados compartilha na realidade uma conseqüência do fato de ser integrado.

Em outras palavras, um determinado banco de dados será percebido por usuário diferentes sob
uma variedade de formas diferentes.
O termo compartilhado, freqüentemente expandido para cobrir não somente o
compartilhamento como foi descrito, mas também o “compartilhamento concorrente“; isto é, a
capacidade de que diversos usuários diferentes, estejam tendo acesso conjunto ao banco de dados
possivelmente à mesma parte do dado ao mesmo tempo.
Um sistema de banco de dados que suporte esta forma de compartilhamento é algumas
vezes conhecido como um sistema de múltiplos usuários.
O Banco de Dados é a memória organizada de uma empresa, a serviço de seu
desenvolvimento. Um computador bem alimentado é capaz de fornecer, em pouquíssimo tempo
os dados necessários para se tomar a melhor decisão.
2.2) Histórico
Com a necessidade e o compromisso especifico do governo americano, em fazer pousar

Astronautas na Lua, antes do término da década de 60, foi desenvolvido o “Projeto Apollo”. Um
dos maiores, mais complexos e bem sucedidos Projetos de Sistemas de Informações
Computadorizadas, apoiados na Tecnologia de Banco de Dados já realizados pelo ser humano até
o ano 2000.
Naquela época, a empresa americana de administração “ROCKWELL” ¹, reconhecendo
que não existiam Sistemas de Informações disponíveis no mercado para lidar com o Projeto
Apollo pelo fato das informações que seriam armazenadas possuírem tamanho e complexidade
muito grande, solicitou então a “IBM” ² que projetasse um Sistema de Informação capaz de
atender às suas especificações de requisitos.
Em 1964, a “IBM” trabalhando junto com a Rockwell, desenvolveu o “GUAM” (
Generalized Updated Access Method - Método de Acesso Atualizado Generalizado ). Neste ano a
plataforma “IBM/360“ ³ foi introduzida no mercado, marcando o inicio da Terceira Geração de
Computadores em termos de Hardware, e Software Básico, introduzido também o Sistema
Operacional.
Os dados requeridos pelo Projeto Apollo representavam basicamente uma grande carta
Organizacional Hierárquica, em conseqüência disso, o primeiro modelo de Banco de Dados
surgiu, chamado de “Banco de Dados Modelo Hierárquico“, o primeiro e mais influente Sistema
Gerenciador de Banco de Dados (SGBD).
Em 1968, foi estabelecido um grupo de trabalho de Banco de Dados que ficou conhecido
internacionalmente como “ DBTG “ (Data Base Task Group - Grupo de Tarefa de Banco de
Dados), com a missão inicial de administrar o desenvolvimento da linguagem “ COBOL “
4
( Commom Business Oriented Language – Linguagem Orientada a Transação Comum ).
O DBTG concluiu que a necessidade da época, não era simplesmente de um software com
a capacidade de manipular listas, mas um Dispositivo Generalizado para definir Estruturas de
5
Dados Complexas, porque as experiências com a Linguagem “PL/1“ da IBM tinha revelado
sérias limitações com o enfoque de Banco de Dados Hierárquico, o DBTG optou então por
incentivar as pesquisas de uma estrutura de dados que fosse mais geral e voltada para um enfoque
de Administração de Banco de Dados, esta estrutura passou a ser chamada de Banco de Dados
Modelo Rede (Network).
No final dos anos 60, os pesquisadores começaram a descobrir que a área de Banco de
Dados continha algumas perguntas interessantes e significativas, que necessitavam de exames
mais criteriosos e novas respostas, então em 1970, a área de pesquisa de Banco de Dados foi
6
marcada pela publicação de um artigo de “E.F.Codd “ , um pesquisador da IBM; neste artigo
propôs um enfoque de Administração de Banco de Dados baseado na Teoria Matemática dos
Conjuntos e das Relações, que passou a ser chamado de “Banco de Dados Modelo Relacional “.
Com elegância, simplicidade e a fundamentação teórica das idéias de CODD acabou por
interessar outros grupos de pesquisadores para a área de Banco de Dados, sendo assim, os
Sistemas Gerenciadores de Bancos de Dados (SGBDs) puderam ser construídos com menor
esforço do que antes com os Modelos Hierárquicos e Rede (Network).
Muitos Sistemas baseados no Modelo Relacional foram então construídos durante os anos
70, mas apenas com modestos investimentos, com o passar do tempo e a evolução das
tecnologias envolvendo computadores, surgiram Sistemas Gerenciadores de Bancos de Dados
Relacionais (SGBDR) mais eficientes, dentre eles destacam-se o Sistema R, “IBM System R”.
[ITA, 2003]
__________________________________________________________________________________________
¹ Empresa América de Administração
² Marca que identifica toda a linha de microcomputadores pessoais fabricados pela IBM.
³ Inicio da Terceira Geração de Computadores em termos de Hardware, e de Software Básico.
4
Linguagem de Programação iniciada nos anos 60 e 70, principalmente para processamento de informações
comerciais.
5
Linguagem de Programação 1 de alto nível que acompanhou o IBM / 360.
6
Edgar Frank Codd, Cientista Inglês criador da tecnologia de Banco de Dados Relaciona (SQL) na década de
70.
3) Modelos de Bancos de Dados
Os tipos ou modelos de banco de dados podem ser divididos de acordo com as estruturas
de dados e os operadores que apresentam ao usuário. O modelo mais utilizado atualmente é o
relacional, pois através dele os dados podem ser percebidos pelo usuário como tabelas e os
operadores à disposição do usuário podem gerar novas tabelas a partir das tabelas antigas.
Os sistemas que antecedem o modelo relacional são chamados de pré-relacionais, são
eles: hierárquicos e de rede. São modelos considerados hábito e possuem uma característica
comum, todos eles expõem ponteiros para o usuário; mais recentemente foi criado o modelo
orientado a objetos que é um sistema em que a unidade de armazenamento é o objeto.
Um modelo de dados é uma estrutura de referência para organizar dados, todo SGBD
deve suportar um modelo que permita uma representação dos dados de uma realidade.
O esquema conceitual de uma aplicação é o resultado da adequação dos requisitos de
dados desta aplicação ao modelo de dados do SGBD. Todo modelo de dados deve suportar, no
mínimo, a especificação de entidades e relacionamentos.
Historicamente, os primeiros modelos de Banco de Dados surgiram na década de 60,
desde então, a pesquisa científica na área procura evoluir no sentido de definir e encontrar
modelos que representem da melhor maneira possível os dados de uma realidade, ou seja, que
organizem os dados de uma forma mais próxima à maneira como estes são vistos e manipulados
pelas pessoas no mundo real. [MOREIRA, 2002]
Além disso, na implementação de um modelo, busca-se também organizações de dados e
estratégias de processamento que otimizem a performance de acesso e métodos de acesso que
sejam independentes da aplicação. Um exemplo, disso é a linguagens de consulta, retirando da
mesma a tarefa de programar procedimentos para realizar operações sobre dados.
3.1) Modelo Hierárquico
Surgiu na década de 60, organizava dados em uma estrutura de Bancos de Dados

Hierárquicos. São baseados em registros compostos por diversos campos e são organizados em
forma de árvore e não em formato de tabelas.
Os registros possuem sub-registros e assim sucessivamente, formando uma ramificação
semelhante a uma árvore. Dois registros são unidos por um elo, um é ascendente e outro é
descendente.
Um ascendente pode ter vários descendentes mas cada descendente tem apenas um
ascendente direto. As raízes são os únicos registros que não possuem “PAI” e nenhum nível de
ascendente pode faltar.
Fornecedor
Endereço
Município Rua Bairro CEP
Fig.3: Modelo Hierárquico
[SILBERSCHATZ, 1999]
3.2) Modelo de Redes
Utilizado principalmente no final da década de 60 e durante a década de 70, organizava

dados em uma estrutura formada por várias listas, que definia uma confusa rede de ligações
(estrutura similar a um grafo direcionado).
Este tipo de gerenciador de Banco de Dados é parecido com o Modelo Hierárquico,
porém, cada registro “filho” pode ser ligado a mais de um registro “pai”, possibilitando a
formação de ligações mais complexas, porque não há a restrição a um só tipo de relacionamento
que vigora.
Fig.4.: Modelo de Redes
3.3) Modelo Relacional
Este modelo é utilizado por quase todos os atuais fabricantes de Banco de Dados do
mundo. Criado por Edgar Frank Codd, pesquisador da IBM e definido na década de 70, é
considerado até hoje uma das maiores inovações técnicas do século XX.
É o modelo de dados dominante no mercado atualmente, organiza dados em um conjunto
de relações (tabelas), alem disso é o mais fácil de ser descrito e entendido.
O Modelo Relacional consagrou – se como o primeiro modelo de dados para aplicações
comerciais. Os primeiros sistemas de Banco de Dados tiveram por base, o modelo de rede e
modelo hierárquico, esses dois modelos antigos estão mais próximos da implementação no nível
físico que no modelo relacional.
No mercado existem outros tipos de sistemas, porém há um pré - domínio dos SGBDs
relacionais, principalmente fora das plataformas de grande porte, nestes ambientes estão
gradativamente substituindo o SGBD de outras abordagens (Hierárquica, Rede, por exemplo).
Banco de Dados Relacional é um grupo de dados percebido pelos usuários como um conjunto de
tabelas. [DATE, 2000]
A terminologia “relação” foi utilizada na estrutura original devido ao fato de que os
sistemas relacionais baseiam – se num conjunto fundamental de idéias teóricas conhecidas como
modelo relacional. Essa terminologia é a mais comum na área acadêmica.
A terminologia “ tabela” é mais comum na prática e nos produtos comerciais.
Uma “relação” é vista como uma “tabela”, onde as colunas indicam os campos e as
linhas as ocorrências (valores). Relacionamentos entre relações são estabelecidos por igualdade
de valor de campos.
Fig.5.: Modelo de Relacional
3.4) As Terminologias presentes no SGBD relacional:
Arquivos
Tabelas
Campos
Linhas
Colunas
Registros
3.4.1) Arquivos
Arquivos são conjunto de Dados, organizados em registros, fixos em suportes magnéticos

segundo um processo eletrônico de magnetização.
Por exemplo: o texto de uma carta, gravado num disquete; um desenho armazenado num
Winchester; um programa gravado num CD-ROM; uma lista de nomes, endereços e telefones,
gravada numa BBS; etc. [OLIVEIRA, 1999]
Fig.6.: Os discos rígidos, normalmente, são sobrepostos em pilhas, com um pequeno

espaçamento entre si para a passagem da cabeça de leitura / gravação. Nessa posição, são
chamados de Winchester.
Os arquivos de dados contêm as informações fornecidas pelo usuário e são classificados
em:
Arquivo – Mestre: o qual contém informações que sofrem poucas alterações;
Arquivo de transações ou movimento: contém informações que serão utilizadas

para atualizar o Arquivo – Mestre;
Arquivo de trabalho: contém informações que são armazenadas temporariamente e

utilizadas por outros módulos do sistema.
3.4.2) Tabelas
Uma tabela é uma área de disco ou memória que armazena uma coleção de dados sobre
um tópico especifico, a mesma organiza os dados em colunas e linhas.
No Banco de Dados Relacional as tabelas apresentam relações lógicas entre elas.
Nome do Campo
(Nome do Atributo)
Coluna Nom_Aluno Mat_Aluno Cur_Aluno

(Atributo) Paulo 7150 Economia
Valor do
Paula 7152 Administração Campo
Daniel 7154 Ciências Contábeis (Valor do
Atributo)
Daniela 7156 Ciências Contábeis
Linha
(Tupla)
Fig.7.: Tabela Cad_Curso

3.4.3) Campos
Campo é um item relacionado ao objeto em questão. Todos os itens incluídos numa

mesma coluna, pertencem ao mesmo campo.
Cada campo é identificado por um nome de campo (nome de atributo, na terminologia
acadêmica).
3.4.4) Linhas
Cada linha é composta por uma série de campos, na terminologia acadêmica, as linhas são
chamadas de “Tuplas”.
3.4.5) Colunas
O conjunto de campos homônimos de todas linhas de uma tabela forma uma coluna.
3.4.6) Registros
Um Registro é formado por diversos campos de dados que possuem certa finalidade para
ficarem agrupados.
O Modelo Relacional formal deixou de usar o termo “ registro”, para usar “tupla”
(termo exato de “tupla-n”).
O termo “tupla” corresponde aproximadamente a noção de “caso de registro horizontal” ,
como o termo “relação” corresponde a noção de “tabela” . [UNIMAR, 2003]
4) Chaves
A chave é o conceito básico para identificar linhas e estabelecer relações entre linhas de
tabelas de um Banco de Dados Relacional
Existe a Super Chave que é o conjunto de um ou mais atributos que tomados
coletivamente, nos permitem identificar de maneira única uma entidade em um conjunto de
entidades e a Chave Candidata que é uma Super Chave para a qual nenhum subconjunto possa
ser uma Super Chave.
Uma Chave, seja Primária, Candidata ou Super Chave, é uma propriedade do conjunto de
entidades e não de uma entidade individualmente. Quaisquer duas entidades individuais em um
conjunto não podem ter ao mesmo tempo, os mesmos valores em seus atributos – chave.
[INÁCIO, 2002]
Existem três tipos de chaves que são as mais utilizadas:
Chave Primária
Chave Estrangeira
Chave Alternativa
4.1) Chave Primária
A Chave Primária é a Chave Candidata que é escolhida pelo projetista do Banco de

Dados como de significado principal para a identificação de entidade dentro de um conjunto de
entidades, é também uma coluna cujo os valores distinguem uma linha das demais dentro de uma
tabela.
No Banco de Dados da tabela Cad_Curso a “Chave Primária” é a coluna “Mat_Aluno”.
Nom_Aluno Mat_Aluno Cur_Aluno

Paulo 7150 Economia
Paula 7152 Administração
Daniel 7154 Ciências Contábeis
Daniela 7156 Ciências Contábeis
Fig.8.: Tabela Cad_Curso

No Banco de Dados da tabela Cad_Dependentes possui uma “Chave Primária
Composta”, podendo – se observar que apenas um dos valore dos campos que compõem a chave,
não é suficiente para distinguir uma linha das demais. Isso acontece pois tanto um código de
empregado quanto um número de dependente podem aparecer em diferentes linhas, sendo assim,
para que seja possível identificar uma linha na tabela, é necessário considerar ambos valores.
Cod_Empresa Num_Depend Nom_Depend Tpo_Depend Dat_Nascimento

70 1 Felipe Filho 30/09/1994
71 2 Beatriz Esposa 03/10/1958
72 1 Lucas Marido 07/08/1960
73 1 Paula Filha 11/09/1983
Fig.9.: Tabela Cad_Dependentes

Portanto qualquer combinação de colunas que contenha as colunas “Cod_Empresa” e
“Num_Depend” é uma “Chave Primária”, por isso, nas definições exige-se que essa seja
“mínima”.
Chave Mínima é quando todas suas colunas forem efetivamente necessárias para garantir
a qualidade de valores da chave. Por exemplo, poderia – se incluir mais uma coluna além das
duas já existentes, como uma chave primária, mas a inclusão de uma terceira coluna não é
necessária para manter a qualidade de valores, devendo - se então obedecer o principio da chave
mínima. [INÁCIO, 2002]
4.2) Chave Estrangeira
A Chave Estrangeira é uma coluna cujo os valores aparecem necessariamente na Chave

Primária de uma tabela, também é o mecanismo que permite a implementação de relacionamento
em um Banco de Dados Relacional.
No Banco de Dados da tabela “Empresa”, a coluna “Cod_Depto” é uma Chave
Estrangeira em relação a Chave Primária da “ Tabela Departamento ”.
A existência de uma Chave Estrangeira impõe restrições que devem ser garantidas ao
executar diversas operações de alteração de Banco de Dado; como garantir que o novo valor de
uma chave estrangeira aparecerá na coluna da chave primária referenciada e que na chave
estrangeira não aparecerá o antigo valor da chave primária que está sendo alterada.
Cod_Depto Nom_Depto
1 Vendas TB_Departamento
2 Produção
3 Financeiro
Cod_Empresa Nom_Func Cod_Depto

70 Carlos 3
71 Paula 2 TB_Empresa
72 Pedro 2
73 Eduarda 1
4.3) Chave Alternativa
A Chave Alternativa em algumas ocasiões mais de uma coluna podem servir para
distinguir uma linha das demais, uma das colunas é escolhida como chave primária e as demais
colunas são chamadas de “Chave Alternativa”.
No Banco de Dados da tabela Cad_Funcionário, com dados de empregados na qual tanto
a coluna “Cod_Empresa” quanto na coluna “RG” podem ser usadas para distinguir uma linha das
demais, no exemplo foi escolhida como chave primária a coluna “Cod_Empresa”, então diz – se
que a coluna “RG” é uma chave alternativa.
Cod_Empresa Nom_Func Cod_Depto RG_Func

70 Carlos 3 19.527.122-0
71 Paula 2 22.877.697-3
72 Pedro 2 13.432.961-2
73 Eduarda 1 18.681.244-8
Fig.10.: Tabela Cad_Funcionário

5) Modelo Entidade – Relacional
O Modelo Entidade – Relacional (E-R) tem por base perceber que o Mundo Real é
formado por um conjunto de objetos chamados “Entidades” e pelo conjunto dos
“Relacionamentos“ entre esse objetos.
O Modelo E-R é um dos modelos com maior capacidade de mudança, que se referem a
tentativa de representar o significado dos dados. [SILBERSCHATZ, 1999]
Existem três noções básicas utilizadas pelo modelo E – R:
Conjunto de entidades
Conjunto de relacionamento
Diagrama Entidade – Relacionamento
5.1) Conjunto de Entidades
Uma entidade é um “objeto” no Mundo Real que pode ser identificada de forma única em
relação a todos outros objetos, sendo representada por um conjunto de atributos.
Atributos são propriedades descritivos de cada membro de um conjunto de entidades.
Um “conjunto de entidades” abrange entidades, do mesmo tipo que compartilham as
mesmas propriedades.
Os conjuntos de entidades não são necessariamente separados. Um exemplo, é possível
definir um conjunto de entidades com todos os empregados do banco (empregado) e um conjunto
de entidades com todos os clientes do banco (cliente). A entidade pessoa, pode pertencer ao
conjunto de entidades empregado, ou a de cliente, como também a ambos ou a nenhum.
A denominação de um atributo para um conjunto de entidades manifesta que o Banco de
Dados matem informações similares de cada uma das entidades do conjunto de entidades;
entretanto cada entidade pode ter seu próprio valor em cada atributo.
Os atributos possíveis ao conjunto de entidades clientes são:
nome_cliente
seguro_social
rua_cliente
cidade_cliente
Atributos possíveis para o conjunto de entidades empréstimo são:
número_empréstimo
conta
Para cada atributo existe um conjunto de valores possíveis, chamado domínio, ou

conjunto de valores, daquele atributo.
Propriamente um atributo de um conjunto de entidades é uma função que relaciona o
conjunto de entidades a seu domínio, desde que possua alguns atributos, cada entidade pode ser
descrita pelo conjunto de entidades. [SILBERSCHATZ, 1999]
5.2) Conjunto de Relacionamento
Um relacionamento é uma associação entre várias entidades e também pode ter atributos
descritivos.
Em um relacionamento, podemos também definir alguns conceitos, tais como:
Participação: é a associação entre os conjuntos de entidades em um conjunto de

relacionamentos;
Papel: é a função que uma entidade desempenha em um relacionamento.
A definição de papéis das entidades em um relacionamento é útil quando o significado de

um relacionamento precisa ser esclarecido, quando uma entidade participa de uma instância de
relacionamento de maneiras diferentes.
Exemplo, uma entidade empregado só pode participar em um relacionamento como
empregado ou gerente. Uma vez que os conjuntos de entidades participantes em um conjunto de
relacionamentos são geralmente distintos, os papéis são subentendidos e não são, em geral,
especificados.
Entretanto, são úteis quando o significado de um relacionamento precisa ser esclarecido,
neste caso, quando os conjuntos de entidades e os conjuntos de relacionamentos não são
distinguíveis, o mesmo conjunto de entidades participa de um conjunto de relacionamentos mais
de uma vez, em diferentes papéis. [INÁCIO, 2002]
5.3) Diagrama Entidade – Relacionamento
É composto pelos seguintes componentes:
Retângulos: representam os conjuntos de entidades;

Elipses: representam os atributos;
Losangos: representam os relacionamentos entre os conjuntos de entidades;
Linhas: unem os atributos aos conjuntos de entidades e o conjunto de entidades aos
seus relacionamentos;
Elipses Duplas: representam atributos multivaloradas;
Linhas Duplas: indicam participação total de uma entidade em um conjunto de
relacionamentos.
Seguro_Social Rua_Cliente Número_Empréstimo Saldo
Nome_Cliente Cidade_Cliente
Cliente Devedor Empréstimo
Fig.11.: DER
Os atributos de um conjunto de entidades que são membros de uma chave primária devem
ser sublinhados.
Uma linha direcionada do conjunto de relacionamentos devedor para o conjunto de
entidades empréstimo especifica que devedor é um conjunto de relacionamentos muitos para
muitos ou um para muitos, de cliente para empréstimo.
Existem dois tipos de entidades:
Entidades Fracas
Entidades Fortes
5.3.1) Entidades Fracas e Fortes
Entidades Fracas são conjuntos de entidades que não têm atributos suficientes para
formar uma Chave Primária, enquanto as Entidades Fortes possuem esses atributos.
Um membro de um conjunto de entidades fortes é definido como uma entidade
dominante, ao contrário um membro de um conjunto de entidades fracas é uma entidade
subordinada.
Embora as entidades fracas não tenham uma chave primária, elas possuem uma Chave
Parcial que permite a distinção entre cada entidade fraca integrante do conjunto.
A chave primária de um conjunto de entidades fracas é formada pela chave primária do
conjunto de entidades fortes, mais a chave parcial do conjunto de entidades fracas.
O conjunto de entidades dominantes de identificação é dito Proprietário do conjunto de
entidades fracas por ele identificada. O relacionamento que associa o conjunto de entidades
fracas a seu proprietário é o relacionamento identificador.
Um conjunto de entidades fracas é identificado no diagrama E-R pela linha dupla usada
no retângulo e no losangos do relacionamento correspondente.
DT_Pagamento
Número_Empréstimo Total
Número_Pagamentos Total_Pagamento
Empréstimo Pagamentos_ Pagamentos

Empréstimo
Fig.12.: DER com Entidades Fracas [SILBERSCHATZ, 1999]

6) Estrutura dos Bancos de Dados Relacionais
Um Banco de Dados Relacional resume - se em uma coleção de tabelas, cada uma com
um nome único. Cada tabela tem uma estrutura parecida com o Modelo de Entidade –
Relacionamento.
Uma linha em uma tabela representa um “Relacionamento“ entre um conjunto de valores.
Essa tabela por sua vez é uma coleção de relacionamento entre o conceito de “tabela” e o
conceito de “relação” a partir das quais se origina o nome desse modelo de dados.
6.1) Estrutura Básica
Nom_Morador Nom_Rua Num_Casa

Maria Mario de Andrade 123
Antonio Anita Garibaldi 456
Manuela Paulo Coelho 789
João Maria Leopoldina 987
Antonia D.Pedro 654
Manuel Maria Joaquina 321
Fig.13.: Tabela Endereço
Na tabela “ Endereço “ acima, possui três colunas: Nom_Morador, Nom_Rua,

Num_Casa. Utilizando o Modelo Relacional, os nomes dessas colunas são tratados como
atributos do Modelo de Entidade – Relacionamento, para cada um desses atributos há um
conjunto de valores permitidos, chamado domínio do atributo.
Cada coluna de uma tabela de um Banco de Dados Relacional é um atributo, para cada
atributo há um conjunto de valores permitidos, chamado domínio do atributo.
Matematicamente, define – se uma relação como um subconjunto de um produto
cartesiano de uma lista de domínios. Como essa definição corresponde quase exatamente à
definição de uma tabela, podemos afirmar que as tabelas são em essência relações.
É possível para alguns atributos, possuir um mesmo domínio como por exemplo o
atributo nom_cliente de uma relação cliente e nom_empregado de uma relação empregado.
Um valor de domínio que pertence a qualquer domínio possível é o valor nulo, que indica
que um valor é desconhecido ou não existe.
7) O que é um SGBD ?
Define – se SGBD (Sistema de Gerenciamento de Banco de Dados) como sendo um

“Sistema com um objetivo principal em gerenciar o acesso e a correta manutenção dos dados
armazenados em um banco de dados “. É constituído por um conjunto de dados associados a um
conjunto de programas para acesso a esses dados.
O software gerenciador de Banco de Dados é um programa que cria, manipula, consulta e
fornece recursos para facilitar o acesso a dados armazenados em um Banco de Dados.
O desenvolvimento tecnológico aliado à evolução dos sistemas de informações nas
organizações permitiu que houvesse grandes modificações em relação à programação de
aplicações em computadores. Antes se usavam linguagens como COBOL, Basic, C e outras, os
programadores colocavam em um programa toda funcionalidade desejada. O gerenciador do
banco de Dados está entre o banco de dados físico e o usuário do sistema, as solicitações de
acesso que vierem a ser feitas, serão manipuladas pelo SGBD.
O SGBD faz com que os usuários tenham uma visão do banco de dados acima do nível do
hardware, e suporta as operações do usuário que são expressas em termos daquela visão em
níveis mais elevados, o objetivo é isolar os usuários do banco de dados dos detalhes em relação
aos hardwares. [DATE, 2000]
O SGBD deve fornecer ao usuário uma “Representação Conceitual” dos dados, sem
fornecer muitos detalhes de como as informações são armazenadas. Um “Modelo de Dados” é
uma abstração de dados que é utilizada para fornecer esta representação conceitual utilizando
conceitos lógicos como objetos, suas propriedades e seus relacionamentos. A estrutura detalhada
e a organização de cada arquivo são descritas no catálogo.
É importante mencionar que os dados e o aplicativo são independentes entre si, ou seja,
podemos mudar o último sem alterar o primeiro, por exemplo.
Programa
Acesso
Lógico
Sistema
operacional
Acesso
físico
Arquivo
Fig.14.: Processamento sem SGBD

[UNIMAR, 2003]
Programa
Chamada
externa
SGBD
Acesso
lógico
Sistema
operacional
Acesso
físico
Método
de acesso Banco de
Dados
Fig.15.: Processamento com SGBD

[UNIMAR, 2003]
7.1) As vantagens e desvantagens do uso de um SGBD
No processamento tradicional de arquivos, cada grupo de usuários deve manter seu

próprio conjunto de arquivos e dados, desta forma acaba ocorrendo excessos que prejudicam o
sistema como:
Toda vez que for necessário atualizar um arquivo de um grupo, então todos os
grupos devem ser atualizados para manter a integridade dos dados no ambiente
como um todo;
O excesso desnecessário de dados levam ao armazenamento excessivo de

informações, ocupando espaço que poderia estar sendo utilizado com outras
informações.
Um SGBD multi – usuário deve permitir que múltiplos usuários acessem o banco de
dados ao mesmo tempo, este fator é essencial para que múltiplas aplicações integradas possam
acessar o banco.
O SGBD multi – usuário deve manter o controle de concorrência para assegurar que o
resultado de atualizações sejam corretos e deve fornecer recursos para a construção de múltiplas
visões.
Um SGBD deve fornecer um subsistema de autorização e segurança, o qual é utilizado
pelo DBA para criar “contas” e especificar as restrições destas contas; o controle de restrições se
aplica tanto ao acesso aos dados quanto ao uso de softwares inerentes ao SGBD.
Um Banco de Dados pode incluir uma variedade de dados que estão relacionados de
várias formas, deve fornecer recursos para se representar uma grande variedade de
relacionamentos entre os dados como: recuperar e atualizar os dados de maneira prática e
eficiente.
Um SGBD deve fornecer recursos para recuperação de falhas tanto de software quanto de
hardware.
7.2) Quando não utilizar um SGBD
Em alguns situações, o uso de um SGBD pode representar uma carga desnecessária aos
custos quando comparado à abordagem tradicional de arquivos como por exemplo:
Alto investimento inicial na compra de software e hardware adicionais;
Generalidade que um SGBD fornece na definição e processamento de dados;
Sobrecarga na previsão de controle de segurança, controle de concorrência,

recuperação e integração de funções.
Problemas adicionais podem surgir caso os projetistas de Banco de Dados ou

Administradores de Banco de Dados não elaborem os projetos corretamente ou se aplicações não
são implementadas de forma apropriada. Se o DBA não administrar o Banco de Dados de forma
apropriada, tanto a segurança quanto a integridade dos sistemas podem ser comprometidas.
A sobrecarga causada pelo uso de um SGBD e a má administração justificam a utilização
da abordagem tradicional de arquivos como por exemplo:
O banco de dados e as aplicações são simples, bem definidas e não se espera

mudanças no projeto;
A necessidade de processamento em tempo real de certas aplicações, que são

terrivelmente prejudicadas pela sobrecarga causada pelo uso de um SGBD;
Não haverá múltiplo acesso ao banco de dados.

8) Para que guardar dados (Necessidade de armazenamento ) ?
Um sistema de Banco de Dados informatizado é capaz de armazenar uma grande

quantidade de informações, de forma precisa, facilitando a consulta rápida e por diversos
usuários.
Existe uma necessidade em se realizar o armazenamento de informações que não se
encontram isoladas umas das outras, existe uma ampla escala de dados que se referem a
relacionamentos entre as informações a serem manipuladas.
Mantendo todo este volume de dados organizados, o Banco de Dados deve permitir
atualizações, inclusões e exclusões do volume de dados, sem nunca perder a consistência, e
sabendo que na maioria das vezes os acessos serão concorrentes a várias tabelas do Banco de
Dados, algumas vezes com mais de um acesso ao mesmo registro de uma mesma tabela.
8.1) Principais Operações para Atualização dos Dados
Inclusão: o Sistema Operacional calcula o endereço do registro através do valor de

sua chave, localizando na área de índice o local onde será armazenado a chave a ser
incluída, reorganizando - se necessário as demais chaves, mantendo – as sempre
ordenadas, caso já exista registros neste endereço, ele fará a inclusão na área de
colisão. Após esta operação, ele procura na área de dados, um endereço disponível
para armazenamento do registro, inclui na posição correta, identificando o endereço
do registro que será incluído e o valor do seu endereço atualizado na área de índices.
[UNIMAR, 2003]
Alteração: o Sistema Operacional calcula o endereço do registro através do valor de

sua chave, atualizando no local especifico ou na área de colisão, dependendo de onde
ele esteja armazenado. Após esta operação, ele atualiza os dados do registro no
endereço correspondente. [UNIMAR, 2003]
Exclusão: o Sistema Operacional calcula o endereço do registro através do valor de
sua chave, removendo fisicamente a chave de acesso do registro da área de dados ou
da área de colisão, dependendo de onde ele esteja armazenado.
[UNIMAR, 2003]
9) Necessidade de uma ferramenta para isso SQL uma linguagem de consulta.
Um Banco de Dados representará sempre aspectos do Mundo Real. Sendo assim uma
Base de Dado é uma fonte de onde poderemos extrair muitas informações derivadas, que possui
um nível de interação com eventos como o Mundo Real.
A forma mais comum entre o usuário e o Banco de Dados, será através de sistemas
específicos que por sua vez acessam o volume de informações geralmente através da linguagem
SQL.
Os Analistas e Programadores de Desenvolvimento, criam sistemas que acessam os dados
da forma necessária ao usuário final, que interage diretamente com o Banco de Dados.
A SQL, por outro lado, é caracterizada por ser uma linguagem declarativa, ou seja, ela diz
ao computador o que quer que ele faça, sem se preocupar de que forma o trabalho será realizado,
o que importa é o resultado.
10) SQL
A grande parte do sucesso da SQL se deve ao fato de existir um modelo matemático

formal que serviu de base para seu desenvolvimento.
SQL – (Structured Query Language – Linguagem de Consulta Estruturada ) tem
representado o padrão para linguagens de Banco de Dados relacionais e existem diversas versões.
É uma linguagem desenvolvida para permitir que qualquer pessoa, mesmo não sendo um
programador, realize uma consulta a um Banco de Dados, é uma linguagem de alto nível para
manipulação de dados dentro do modelo relacional.
Não é uma linguagem procedural, e não é o usuário quem define como o gerenciador de
Banco de Dados executará uma tarefa, e sim o que ele deve fazer.
Praticamente todos os produtos de Banco de Dados relacionais que estão no mercado
suportam a SQL.
10.1) Histórico
A tecnologia de Banco de Dados Relacional se baseia na teoria

de conjuntos que foi proposta por Edgar Frank Codd matemático e
P.H.D. em Ciências da Computação que divulgou suas primeiras
idéias no final da década de 60 e em junho de 1970 publicou o artigo “
A Relational Model of Data for Large Shared Data Banks “ na revista
“ Communications of the ACM “, enquanto ele trabalhava para a IBM
no Laboratório de Pesquisa de San Jose na Califórnia (hoje é o Centro
de Pesquisa Almadén).
Esse material é um marco na área de Banco de Dados e rendeu a E.F.Codd, em 1981 o
equivalente ao Prêmio Nobel nesta área, o ACM Turing Award. Em 18/04/2003, Codd veio a
falecer aos 79 anos e deixou em testamento seus conhecimentos na Teoria Relacional.
O Cientista utilizou a álgebra relacional para expressar as ações realizadas nas tabelas, operações
como seleção, projeção e junção, foram definidas de forma procedimental utilizando – se notação
matemática. [LIMA, 2003]
Em 1973 a IBM deu início ao seu primeiro gerenciador de dados relacional, o System R,
que utilizava uma linguagem de consulta denominada “ SEQUEL ” que no inicio da década de
80, por motivos jurídicos passa a se chamar “ SQL ”, esse projeto se estendeu até 1979, provou a
viabilidade do modelo matemático e foi o berço da SQL.
Em 1974 outros dois pesquisadores da IBM, D.D. Charmberlim e Boyce, publicaram um
artigo “ SEQUEL: A Stucturd English Query Language ” ao mesmo tempo em que apresentaram
um protótipo da IBM denominado SEQUEL – XRM; nasce então a linguagem SEQUEL.
A linguagem SQL era uma novidade para a época, os sistemas gerenciadores de Banco de Dados
existentes utilizavam o modelo de dados hierárquico ou rede. Para as linguagens de acesso a
dados era necessário que o programador navegasse nas estruturas de dados, para obter os de
interesse.[LIMA, 2003]
Novos fabricantes foram aparecendo, cada um foi incorporando novos recursos (e
incompatibilidade) à linguagem, isto evoluiu para uma tentativa de padronização da linguagem,
de maneira que todos adquirissem.
Apesar de todo trabalho com pesquisa iniciado e desenvolvido pela IBM, o primeiro
sistema de gerenciador de banco de dados relacional ( SGBDR ) disponível no mercado foi o “
Oracle “, lançado em 1979 por uma empresa chamada “ Relational Software “ ( hoje, Oracle
Corporation - Corporação de oráculo ). A entrada da IBM neste mercado só aconteceu em 1981,
com o lançamento do SQL / DS, e sua consolidação veio apenas em 1983, com o DB2.
No inicio da década de 80 várias implementações de SGBDRs utilizavam SQL, cada
fornecedor passou a incluir extensões à linguagem conforme seu interesse, então logo se
percebeu que era importante a padronização para permitir a portabilidade entre os diversos
produtos disponíveis, fortalecendo o mercado. Em 1984, apenas 20 % dos gerenciadores de
Banco de Dados seguiam o modelo Relacional.
A ANSI (American National Standards Institute - Instituto Americano de Padrão
Nacional ) publicou o primeiro padrão em 1986 e denominou o nome de SQL 86, mas no ano
seguinte, o padrão foi publicado como uma norma internacional pela ISO ( Internacional
Organization for Standardization - Organização Internacional de Normalização ).
Em 1989 uma nova padronização foi publicada pela ISO incluindo recursos como integridade
referencial, valores NULL e DEFAULT, CHECK CONSTRAINT e outras dando origem ao
SQL 89. [LIMA, 2003]
Em 1990 os gerenciadores de Banco de Dados seguiam o modelo Relacional
contabilizavam 80 %. Em 1992 foi publicada a versão do padrão que ficou conhecida como SQL
92 ou SQL 2, contendo 589 páginas ( quase cinco vezes maior do que o SQL 89 que tinha 120
páginas ).
Padrão Número de Páginas
SQL 86 105
SQL 89 120
SQL 92 575
SQL 99 1500 +
Atualmente 3000 +
Fig.16.: Número de Página de cada versão
Várias novidades foram agregadas nesta versão, como novos tipos de dados ( DATE e
TIME ), tabelas temporárias, catálogos, domínios, SQL Dinâmico, tabelas derivadas na cláusula
FROM, múltiplos operadores de JOIN, entre outras.
O curioso é que muitos desses recursos não foram implementados até hoje pelos
fornecedores, na SQL 92, foram definidos 3 níveis de conformidade:
Entry Level: Nível Inicial, muito parecido com o SQL 89;

Intermediate Level: Nível Intermediário, o mais completo;
Full Level: Nível Alto, o mais completo.
No inicio da década de 90, era grande o marketing das empresas que tentavam alcançar os
sistemas gerenciadores de Banco de Dados orientados a objeto, alguns até anunciavam a morte do
SQL, dizendo que seria a vez da OQL ( Object Query Language - Linguagem de Consulta à
Objeto ). As empresas deste segmento se reuniram e criaram a ODMG ( Object Data
Management Group - Grupo de Administração de Objetos e Dados ), vinculada à OMG ( Object
Managment Group – Grupo de Administração de Objetos ), para padronizar a OQL.
Em uma reunião o comitê de padronização da SQL trabalhava para implementar
características de orientação a objeto ao modelo relacional, gerando em 1999 o padrão mais
recente, que ficou conhecido como SQL 3 ( ISSO / IEC 9075 ), sendo está versão maior que a
anterior.
Árvore Genealógica do SQL
SEQUEL ( 1974 )
(Pela IBM )
Rebatizada como SQL
ANSI – SQL ( 1986)

Aceito pelo ANSI X3H2
SQL 92 ( 1992 )
SQL 1999 ( 1999) OQL v1 (1993 )

Parte do padrão ODMG 93
Fig.17.: Evolução das linguagens de consulta até o surgimento do SQL em 1999
Com o suporte a objetos complexos definidos pela SQL 3 como vídeo, imagem e textos os
fornecedores classificaram os seus produtos como “ Sistemas Gerenciadores de Dados Universais
”, as extensões para esses objetos passaram a ser comercializadas como um produto à parte.
[BEZERRA, 2003]
Foram incluídos novos tipos de dados básicos:
BOOLEAN: é o tipo lógico, possui como domínio de valores o conjunto {

TRUE, FALSE, UNKNOWN }, no SQL 1999, expressões que retornam valores do
tipo BOOLEAN são tratadas como predicados;
CLOB ( Character Large Object – Objeto de Caráter Grande) e BLOB ( Binary

Large Object – Objeto Binário Grande ): Um campo BLOB pode armazenar dados
binários, como uma imagem. Um CLOB é estruturalmente similar ao BLOB, com
diferença de armazenar caracteres, como um currículo ou uma coleção de artigos. Em
um BLOB / CLOB os operadores ‘ > ’ e ‘ < ’ não podem ser utilizados, operadores
de comparação para esse tipo são igualdade ‘ = ’ e desigualdade ‘ <> ‘. BLOBs e
CLOBs também não podem ser utilizados em definições de chaves primárias e
chaves estrangeiras ou em cláusulas ORDER BY e GROUP BY. O SQL 1999
também define o conceito de demarcador ( locator), ele serve como uma referência
para uma instância de um BLOB / CLOB e evita que todo seu conteúdo seja
transferido do Banco de Dados para a Aplicação.
CREATE TABLE Empregado ( nome CHAR VARYING ( 15 ),

currículo CLOB ( 25K )
CHARACTER SET BRAZILIAN
foto BLOB ( 5K ));
Fig.18.: No exemplo abaixo, possui um campo do tipo CLOB que pode

armazenar até 25.000 caracteres e possui também um campo BLOB que pode
armazenar até 5.000 bytes.
ARRAY: o tipo ARRAY representa um vetor unidimensional, ou seja, uma lista
contendo uma quantidade variável de elementos do mesmo tipo, não são permitidos
vetores multidimensionais ( vetor de vetores ), o acesso aos elementos de um vetor é
feito através da posição ordinal de cada um. O operador UNNEST é usado na
transformação de uma coluna do tipo ARRAY em uma tabela cujas linhas contêm os
valores armazenados no vetor.
CREATE TABLE Cidade ( nome CHAR VARYING ( 30 ),

população INTEGER
parques CHAR ( 30 ) ARRAY [20] );
- Utiliza o construtor de ARRAY, através do par de colchetes.

INSERT INTO Cidade
VALUES (‘Campo Belo’, 30000,
ARRAY [‘Parque da Saudade’, ‘Parque Esmeralda’] );
- Seleciona o nome da cidade e o nome do primeiro parque.

SELECT nome, parques [1] AS parque
FROM Cidade
- Seleciona o nome da cidade e o nome de cada parque.

SELECT C.nome, P.nome
FROM Cidade AS C.UNNEST (C.parques) AS P(nome)
Fig.19.: No exemplo abaixo, possui um campo do tipo ARRAY, esse campo pode
armazenar até 20 cadeias de caracteres, cada uma com 30 posições.
ROW: o tipo ROW define uma estrutura dentro de uma coluna, se trata de uma
tabela aninhada dentro de outra tabela ( um distanciamento do modelo relacional
original, que pressupõe tabelas normalizadas ). O tipo ROW é semelhante aos tipos
Struct e Record das linguagens C e Pascal. Para armazenar informações sobre
empregados, onde cada empregado possui um nome e um endereço. Essa última
informação é modelada como um tipo ROW: um endereço é uma estrutura formada
pelos campos logradouro, cidade UF e CEP.
[BEZERRA, 2003]
CREATE ROW TYPE TipoEndereco ( logradouro CHAR ( 30 ),

cidade CHAR ( 20 ),
unidadeFederativa CHAR ( 2 ),
CEP ROW ( prefixo CHAR ( 5 ),
sufixo CHAR ( 3 ) );
CREATE TABLE Empregados ( nome CHAR ( 40 ),

endereço TipoEndereco);
Fig.20.: No exemplo abaixo mostra que o tipo ROW pode ser nomeado ou não
nomeado ( ao contrário do campo CEP, TipoEndereço é um ROW nomeado).
INSERT INTO Empregados

VALUES (‘Ana Silva’, (Rua XYZ, 28’, ‘Cuiabá’, ‘MT’, (‘22733’,
‘000’)));
SELECT E.nome, E.endereço.cidade
FROM Empregados E;
Fig.21.: No exemplo abaixo os componentes de um campo ROW são acessados

através do operador ‘.’.
Extensões Objeto Relacional:
Hierarquia de Tabelas;
Tipos de Dados Definidos pelo usuário;
Tipos de Dados de Coleção ( Ex.: Arrays )
Suporte a Large Objects ( LOB´s)
TRIGGERS: o SQL 1999 introduz o conceito de TRIGGERS, que são rotinas

atreladas a eventos de modificação ( INSERT, UPDATE ou DELETE ) de uma
tabela, essa técnica fornece um controle maior sobre os dados, pois as regras de
negócio escritas na TRIGGER são respeitadas por todas as aplicações que utilizam o
banco. Outra vantagem é que uma eventual modificação nas regras fica disponível
automaticamente para todas essas aplicações.
SavePoint;
Extensões Olap ( Cube e Roll Up );
Comando Select com recursividade;
Stored Procedures;
Funções definidas pelo usuário.
[BEZERRA, 2003]
Fig.22.: Hierarquia de tipos de dados do SQL 1999, os retângulos destacados correspondem
aos novos tipos.
[BEZERRA, 2003]
A ABNT ( Brazilian Association of Norms and Techniques - Associação Brasileira de

Normas e Técnicas ) é representante do Brasil, no comitê da ISO, que trabalha na padronização
da SQL. Um Brasileiro teve importante participação na criação do SQL 3, Nelson Mattos, P.H.D.
em Ciências da Computação e representante da IBM, que participou dos comitês ANSI e ISO e
teve centenas de sugestões aceitas.
A SQL é hoje muito mais do que uma linguagem de consulta; é possível criar tabelas,
índices e visões; definir regras de integridade, impor restrições de segurança, implementar
resposta a eventos utilizando “ triggers ”; procedimentos e funções, além de muitos outros
recursos. A tendência é que continue se distanciando de seu propósito original, agregando cada
vez mais funcionalidades.
A quarta geração da linguagem SQL deverá ser publicada em 2003 e possivelmente será
chamada de SQL 2003. [LIMA, 2003]
10.2) Estrutura
A linguagem SQL é bastante ampla, suportando comandos para criação e manipulação de

Banco de Dados, de tabelas, como de recuperação de dados. Além desses recursos, a linguagem
ainda oferece recursos de segurança, permitindo criar usuários do Banco de Dados e restringir seu
acesso a eles.
A linguagem SQL tem diversas partes:
Linguagem de definição de dados ( Data Definition Language – DDL): a DDL

proporciona comandos para a definição de esquemas de relações, exclusão de
relações, criação de índices e modificação nos esquemas de relações;
Linguagem interativa de manipulação de dados ( Data Manipulation Language

DML ): a DML engloba comandos para inserção, exlusão e modificação de tuplas no
Banco de Dados;
Incorporação DML (Embedded SQL): a forma de comandos SQL incorporados foi

projetada para aplicação em linguagens de programação de uso geral, como PL / 1,
Cobol, Pascal, Fortran e C;
Definição de visões: a DDL possui comandos para definição de visões;
Autorização: DDL engloba comandos para especificação de direitos de acesso a

relações e visões;
Integridade: DDL possui comandos para especificação de regras de integridade que

os dados que serão armazenados no banco de dados devem satisfazer. Atualizações
que violarem as regras de integridade serão desprezadas;
Controle de transações: a SQL inclui comandos para a especificação de início e
término de transações, bem como bloqueios de dados para controle da concorrência;
Algumas Definições de Tabelas:
Criação das Tabelas na tablespace TS_DADOS01

======================================
CREATE TABLE BANCO
(COD_BANCO NUMBER(10),
NOME_BANCO VARCHAR2(30),
ENDERECO VARCHAR2(50))
TABLESPACE TS_DADOS01
----------------------------------------------------------------------
CREATE TABLE AGENCIA_BANCO
COD_AGENCIA NUMBER(7),
NOME_AGENCIA VARCHAR2(30),
ENDERECO VARCHAR2(40))
-----------------------------------------------------------------------
CREATE TABLE CONTA_CORRENTE

(NUM_CONTA NUMBER(10),
COD_BANCO NUMBER(10),
SALDO NUMBER,
TIPO VARCHAR2(1),
CPF_CGC NUMBER(12))
-----------------------------------------------------------------------
CREATE TABLE CLIENTE
(CPF_CGC NUMBER(12),
NOME VARCHAR2(50),
ENDERECO VARCHAR2(60),
FONE VARCHAR2(15))
-----------------------------------------------------------------------
CREATE TABLE EMPRESTIMO
(NUM_EMPRESTIMO NUMBER(5),
VALOR NUMBER,
PRAZO NUMBER(2),
CPF_CGC NUMBER(12),
COD_BANCO NUMBER(10),
COD_AGENCIA NUMBER(7))
-----------------------------------------------------------------------
Criação das Constraints NOT NULL

============================
ALTER TABLE BANCO
MODIFY NOME_BANCO NOT NULL
--------------------------------------------------------
ALTER TABLE AGENCIA_BANCO
MODIFY NOME_AGENCIA NOT NULL
----------------------------------------------------------
ALTER TABLE CONTA_CORRENTE
MODIFY SALDO NOT NULL
------------------------------------------------------------
ALTER TABLE CLIENTE
MODIFY NOME NOT NULL
-----------------------------------------------------------------------
Criação das Constraints CHECK
==========================
ALTER TABLE EMPRESTIMO
ADD CONSTRAINT
CK1_VALOR
CHECK (VALOR > 5000)
-----------------------------------------------------------------------
ALTER TABLE EMPRESTIMO
ADD CONSTRAINT CK_PRAZO
CHECK (PRAZO IN (12,24,36))
-----------------------------------------------------------------------
ALTER TABLE CONTA_CORRENTE
ADD CONSTRAINT CK_TIPO_CC
CHECK (TIPO IN ('J','F'))
-----------------------------------------------------------------------
Criação das Constraints Primary Key criando os index na Tablespace
TS_INDEX01
==========================================================
ALTER TABLE BANCO ADD CONSTRAINT PK_BANCO
PRIMARY KEY(COD_BANCO)
USING INDEX TABLESPACE TS_INDEX01
------------------------------------------------------------------------------
ALTER TABLE AGENCIA_BANCO ADD CONSTRAINT
PK_AGENCIA_BANCO
PRIMARY KEY(COD_BANCO, COD_AGENCIA)
-----------------------------------------------------------------------
ALTER TABLE CONTA_CORRENTE ADD CONSTRAINT
PK_CONTA_CORRENTE
PRIMARY KEY(NUM_CONTA, COD_BANCO, COD_AGENCIA)
-----------------------------------------------------------------------
ALTER TABLE CLIENTE ADD CONSTRAINT PK_CLIENTE
PRIMARY KEY(CPF_CGC)
-----------------------------------------------------------------------
ALTER TABLE EMPRESTIMO ADD PRIMARY
KEY(NUM_EMPRESTIMO)
-----------------------------------------------------------------------
Criação das Constraints FOREIGN KEY

===============================
ALTER TABLE AGENCIA_BANCO ADD CONSTRAINTS
FK_BANCO FOREIGN KEY(COD_BANCO) REFERENCES
BANCO(COD_BANCO)
-----------------------------------------------------------------------
FK_AGENCIA_BANCO
FOREIGN KEY(COD_BANCO,COD_AGENCIA) REFERENCES
AGENCIA_BANCO(COD_BANCO,COD_AGENCIA)
-----------------------------------------------------------------------
ALTER TABLE EMPRESTIMO ADD CONSTRAINT
FK_EMPRESTIMO
FOREIGN KEY(COD_BANCO,COD_AGENCIA) REFERENCES
AGENCIA_BANCO(COD_BANCO,COD_AGENCIA)
-----------------------------------------------------------------------
ALTER TABLE EMPRESTIMO ADD CONSTRAINT
FK_EMPRESTIMO_CPF
FOREIGN KEY(CPF_CGC) REFERENCES CLIENTE(CPF_CGC)
-----------------------------------------------------------------------
FK_CONTA_CORRENTE_CFP
FOREIGN KEY(CFP_CGC) REFERENCES CLIENTE(CFP_CGC)
-------------------------------------------------------------------------
[CRISTINA E RICARDO, 2002]
10.3) Uma aplicação do SQL
Antes de vermos uma aplicação em SQL, precisamos entender as principais funções de

um SELECT:
SELECT: usada para relacionar os atributos desejados no resultado de uma consulta;

FROM: associa as relações que serão pesquisadas durante a evolução de uma
expressão;
WHERE: consiste em um predicado envolvendo atributos da relação que aparece na
cláusula from.
SELECT < colunas_da_tabela >

FROM < nome_da_tabela >
WHERE < condição_lógica >
Quando desejamos suprimir duplicidades na apresentação de resultados de uma cláusula
select, utilizamos a chave DISTINCT:
SELECT DISTINCT < colunas_da_tabela >

FROM < nome_da_tabela >
A cláusula select pode conter expressões aritméticas envolvendo os operadores:

( +, -, *, / ) e operandos constantes ou atributos das colunas.
Quando queremos exibir todas as colunas ( ou atributos ) da tabela ( ou relação ),
podemos usar * em invés de especificar todas as colunas da tabela.
A cláusula Where tem como finalidade delimitar um conjunto de valores ou intervalo de
valores a serem recuperados por uma cláusula select, utiliza operadores lógicos AND, OR e
NOT e operadores de comparação ( <, <=, >, >=, = e <> ), além desses é utilizado também pelo
SQL operadores BETWEEN, usado para determinar intervalos de valores para uma coluna, e IN,
para a seleção de valores pontuais de uma coluna.
SELECT * FROM < nome_da_tabela >

WHERE < nome_da_coluna > BETWEEN < valor_inicial >
AND < valor_final >
SELECT * FROM < nome_da_tabela >
WHERE < nome_da_coluna > IN ( < série_de_valores >)
Podemos também modificar os nomes das colunas de uma tabela para efeito de exibição
através da cláusula AS:
SELECT < nome_da_coluna > AS < novo_nome >

FROM < tabela >
Temos também o operador LIKE, usado na cláusula Where, é útil quando desejamos
encontrar coincidências de pares, ou seja, quando procuramos por valores de atributos que sejam
semelhantes a um determinado valor fornecido.
Identificamos esses valores através do uso de dois caracteres especiais:
%: usado pra comparar qualquer substring;

_: usado para comparar qualquer caracter.
Seleciona da tabela ALUNOS todos os alunos cujo nome inicia com ‘ AU ’
SELECT NA, NOME

FROM ALUNOS
WHERE NOME LIKE ‘ AU %’
Seleciona da tabela ALUNOS todos os alunos com NA= ‘107007’, ‘117007’, 127007’,
ETC...
SELECT NA, NOME

FROM ALUNOS
WHERE LIKE ‘ 1_7007’
A cláusula ORDER BY permite a classificação das colunas de uma tabela de modo

decrescente ou crescente ( padrão)
SELECT < colunas >

FROM < tabela >
ORDER BY < coluna_de_classificação > ASC
ou
ORDER BY < coluna_de_classificação > DESC
Para podermos entender melhor o que foi explicado anteriormente vamos utilizar uma “
Consulta de um Sistema Médico”, observando o DER que é necessário para montar o sistema
por inteiro, localizamos tudo o que necessário para fazermos o sistema, não só a consulta.
Fig.23.: DER
O Select para visualizar as tabelas que foram utilizadas no Sistema Médico:
SQL> select table_name from user_tables

2 /
TABLE_NAME
------------------------------
AME_CONSELHO
AME_CONTATO
AME_CONVENIO
AME_DOCUMENTO
AME_ENDERECO
AME_ESPECIALIZACAO
AME_FILIACAO
AME_HORARIO
AME_HOSPITAL
AME_TB_BENEFICIO
AME_TB_CONSELHO
TABLE_NAME
------------------------------
AME_TB_CONVENIO
AME_TB_DIA_SEMANA
AME_TB_DOCUMENTO
AME_TB_ESPECIALIZACAO
AME_TB_EXAME
AME_TELEFONE
17 rows selected.
O Select para a busca especificamente iremos utilizar a “Consulta de documentos

faltantes”:
SELECT '0', a.cod_convenio, a.nom_convenio, a.nom_responsavel,

c.dsc_tb_documento
FROM ame_convenio a, ame_documento b, ame_tb_documento c
WHERE a.cod_convenio = b.cod_convenio
AND b.cod_tb_documento = c.cod_tb_documento
ORDER BY a.nom_convenio ASC
O Select para visualizar as tabelas do Select acima:
SQL> desc ame_convenio
Name Null? Type

----------------------------------------- -------- ----------------
COD_CONVENIO NOT NULL NUMBER(6)
NOM_CONVENIO NOT NULL VARCHAR2(45)
NOM_RESPONSAVEL NOT NULL VARCHAR2(35)
DAT_NASCIMENTO DATE
NUM_RG VARCHAR2(15)
NUM_CPF NOT NULL NUMBER(11)
END_SITE VARCHAR2(45)
COD_TB_CONVENIO NOT NULL NUMBER(3)
DSC_FORMACAO VARCHAR2(45)
DAT_INCLUSAO NOT NULL DATE
NOM_INCLUSAO NOT NULL VARCHAR2(8)
DAT_ALTERACAO DATE
NOM_ALTERACAO VARCHAR2(8)
OPC_DOCTO_FALTA NUMBER(1)
DAT_ENTREGA_DOCTO DATE
SQL> desc ame_documento
Name Null? Type

----------------------------------------- -------- --------------
COD_TB_DOCUMENTO NOT NULL NUMBER(3)
COD_CONVENIO NOT NULL NUMBER(6)
SQL> desc ame_tb_documento
Name Null? Type

----------------------------------------- -------- -------------
COD_TB_DOCUMENTO NOT NULL NUMBER(3)
DSC_TB_DOCUMENTO NOT NULL VARCHAR2(45)
DAT_INCL_ALT NOT NULL DATE
NOM_INCL_ALT NOT NULL VARCHAR2(8)
OPC_OBRIGATORIO NOT NULL NUMBER(1)
Resposta do Select acima:
-----------
' COD_CONVENIO NOM_CONVENIO
- ------------ -----------------------
NOM_RESPONSAVEL
-----------------------------------
DSC_TB_DOCUMENTO
--------------------------------------
0 975 SÉRGIO JAMNIK
SÉRGIO JAMNIK
REGULARIZAÇÃO DO TERMO DE ADESÃO
0 1076 SÔNIA C. A. S. E SANTOS

SÔNIA C. A. S. E SANTOS
TELEFONE
11) Estudo de Casos
Para que possamos assimilar melhor tudo o que foi explicado nos capítulos anteriores
alguns exemplos de utilização de Gerenciamento de Usuários e seus Privilégios, serão explicados
abaixo.
Ex.1: Conectando no Sql/Plus com o usuário aula1 senha aula1 no banco de dados FAI.
SQL> conn aula1/aula1@fai

Conectado.
Ex.2: Criando um usuário chamado userxxxx (onde xxxx é um número da sua matricula ),
com a senha senha_1234, utilizando a tablespace temp como tablespace default e a tablespace
temp como tablespace temporária e estabelecendo uma quota de 2 m na tablespace temp e 1 m
na tablespace temp.
SQL> create user user7264

2 identified by senha_1234
default tablespace temp
temporary tablespace temp
4 quota 2m on tools
5 quota 1m on users
6 profile default;
Usuário criado.
Ex.3: Alterando a senha do usuário que foi criado no item 2, escolhendo uma nova senha.
SQL> alter user user7264
2 identified by tha_fla;
Usuário alterado.
Ex.4: Tentando se conectar com o novo usuário que acabou de ser criado. O comando
para conexão é : connect userxxxx/senha@fai.
Conn user7264/tha_fla@fai
Mas não se consegue conectar, pois falta o privilegio Session
Ex.5: Dando os privilégios necessários para os usuário conseguirem se conectar.

Verifando os privilégios no material "Grants de Sistemas".
SQL> grant create SESSION to user7264;

Operação de Grant bem-sucedida.
Ex.6: Dando os privilégios necessários para os usuários executarem as seguintes tarefas:

Criar tabelas, view´s e procedures;
Criar e alterar novos usuários;
Criar e alterar profile;
Dropar profiles;
Criar e Dropar trigger´s em qualquer usuário;
Criar roles;
Criar sinônimos (privados e públicos);
Export e Import Bancos de Dados;
Selecionar dados dicionário de dados.
SQL> grant create table, create view, create procedure to user7264

SQL> grant create user, alter profile to user7264;

SQL> grant drop profile to user7264;

SQL> grant create any trigger to user7264;
SQL> grant create role to user7264;

SQL> grant create synonym, create public synonym to user7264;

SQL> grant exp_full_database, imp_full_database to user7264;

Ex.7: Criando um profile chamado profile_xxxx, (onde xxxx é um número da sua

matricula) com as seguintes características :
Cpu_per_session 3000
Connect_time 50
Sessions_per_user unlimited
Número de logons errado, para bloqueio de senha 3
Validade da senha 30 dias
Tempo de Bloqueio de usuário após senha incorreta 5 dias
SQL> create profile profile_7264 limit

2 cpu_per_session 3000
3 connect_time 50
4 sessions_per_user unlimited
5 failed_login_attempts 3
6 password_life_time 30
7* password_lock_time 5
SQL> /
Perfil criado.
Ex.8: Alterando o profile que foi criado limitando o número de sessões por usuários para
10 e a validade da senha para 60 dias.
SQL> alter profile profile_7264 limit

2 sessions_per_user 10
3 password_life_time 60;
Perfil alterado.
Ex.9: Alterando o usuário que foi criado no exercício 2 (userxxxx), designando a ele o
profile criado no exercício 7 (profilexxxx).
SQL> alter user user7264 profile profile_7264;

Usuário alterado.
Ex.10: Tentando conectar – se digitando a senha errada mais de 3 vezes para validando se
o profile está OK.
SQL> conn user7264/12356@fai

ERROR:
ORA-28000: the account is locked
Ex.11: Conectando novamente como aula1/aula1@fai para desbloquear o usuário

userxxxx.

Conectado.
SQL> alter user user7264 account unlock;

Usuário alterado.
Ex.12: Conectando agora com o usuário que foi utilizado no laboratório anteriormente
(alunoxx). connect alunoxx/senha@fai.
SQL> CONN ALUNO23A/FLATHA@FAI
Conectado.
Ex.13: Verificando quais tabelas foram criadas neste usuário. Utilizando a view do
dicionário de dados USER_TABLES.
SQL> SELECT TABLE_NAME

2 FROM USER_TABLES;
TABLE_NAME
------------------------------
AGENCIA_BANCO
BANCO
CLIENTE
CONTA_CORRENTE
EMPRESTIMO
S_CUSTOMER
S_DEPT
S_EMP
S_IMAGE
S_INVENTORY
S_ITEM
S_LONGTEXT
S_ORD
S_PRODUCT
S_REGION
S_TITLE
S_WAREHOUSE
17 linhas selecionadas.
Ex.14: Dando privilégios para o usuário userxxxx para selecionar dados da tabela banco.
SQL> grant select on banco to user7264;

Ex.15: Conectando com o usuário userxxxx e selecionando todos os dados da tabela

BANCO do usuário alunoxx. Para selecionar dados de tabelas de outros usuários, basta colocar o
nome do usuário na frente do nome da tabela.
SQL> conn user7264/tha_fla@fai

Conectado.
SQL> select *
2 from aluno23a.banco;
COD_BANCO NOME_BANCO ENDERECO

----------------- ------------------------ ---------------------
1 Banco do Brasil Rua A, 43
409 Unibanco Rua B, 55
356 Banco Real Rua C, 55
341 Banco Itaú Rua D, 66
Ex.16: Conectado com o usuário userxxxx, tentando inserir os seguintes dados na tabela
banco do usuário alunoxx.
insert into alunoxx.banco values (200,'Banco ABC','Rua C, 76');
SQL> insert into aluno23a.banco values ( 200, 'banco abc','rua c, 76');
1 linha criada.
SQL> commit;
Validação completa.
Consege se conectar, pois o usuário user7264 tem o privilegio das Roles
exp_full_database, imp_full_database.
Ex.17: Conectado com o usuário alunoxx, criar uma role chamada role_xxxx (onde xxxx
é um número da sua matricula).
SQL> conn aluno23a@fai

Conectado.
SQL> create role role_7264;

Função criada.
Ex.18: Dando privilégios para a role_xxxx para selecionar, inserir, atualizar e excluir
dados das tabelas banco, cliente, conta_corrente, empréstimo.
SQL> grant select, insert, update, delete on banco to role_7264;

SQL> grant select, insert, update, delete on cliente to role_7264;

SQL> grant select, insert, update, delete on conta_corrente to role_7264;

SQL> grant select, insert, update, delete on emprestimo to role_7264;

Ex.19: Dando grant da role_xxxx para o usuário userxxxx :
SQL> grant role_7264 to user7264;

Ex.20: Conectando com o usuário userxxxx e tentando inserir novamente os seguintes
dados na tabela banco do usuário alunoxx.
insert into alunoxx.banco values (200,'Banco ABC','Rua C, 76');

SQL> conn user7264@fai
Conectado
SQL> insert into aluno23a.banco values ( 201, 'banco abc','rua c, 76');

1 linha criada.
SQL> commit;
Validação completa.
Consegue se conectar normalmente.
Ex.21: Conectado com o usuário userxxxx , criando a tabela agencia_banco (para

verificar com qual usuário está conectado, utilizando o comando show user);
CREATE TABLE AGENCIA_BANCO

NOME_AGENCIA VARCHAR2(30),
ENDERECO VARCHAR2(40));
SQL> conn user7264@fai

Conectado.
SQL> create table agencia_banco (

2 cod_banco number(10),
3 cod_agencia number(7),
4 nome_agencia varchar2(30),
5 endereco varchar2(40) );
Tabela criada.
SQL> show user

USER é "USER7264"
Ex.22: Criando uma constraint do tipo foreign key na tabela agencia_banco referenciando
a coluna cod_banco , da tabela banco do usuário alunoxx.
SQL> alter table agencia_banco add constraint agencia_banco_fk foreign key (

cod_banco )
2 references aluno23a.banco( cod_banco );
references aluno23a.banco( cod_banco )
*
ERRO na linha 2:
ORA-01031: insufficient privileges
Não consegue se conectar, pois esta faltando o Grant de references na tabela banco.
Ex.23: Conectando o usuário alunoxx e dando o grant na tabela banco para que possa ser
criado a constraint mencionada acima.
SQL> conn aluno23a@fai

Conectado.
SQL> grant references on banco to user7264;
Ex.24: Conectando o usuário userxxxx e criaando a constraint novamente:

Conectado.
SQL> alter table agencia_banco add constraint agencia_banco_fk 2 foreign
key ( cod_banco ) references aluno23a.banco( cod_banco );
Tabela alterada.
Ex.25: Consultando as view´s do dicionário de dados para verificar os grant´s dados para
o usuário userxxxx. As views consultadas é USER_TABS_PRIVS para verificar grant de
objectos, USER_SYS_PRIVS para verificar grant de sistemas e user_role_privs para verificar as
roles
SQL> select *
2 from user_sys_privs;
USERNAME PRIVILEGE ADM

------------------------------ ---------------------------------------- --------
USER7264 ALTER PROFILE NO
USER7264 CREATE ANY TRIGGER NO
USER7264 CREATE PROCEDURE NO
USER7264 CREATE PUBLIC SYNONYM NO
USER7264 CREATE ROLE NO
USER7264 CREATE SESSION NO
USER7264 CREATE SYNONYM NO
USER7264 CREATE TABLE NO
USER7264 CREATE USER NO
USER7264 CREATE VIEW NO
USER7264 DROP PROFILE NO
SQL> select *
2 from user_role_privs;
USERNAME GRANTED_ROLE ADM DEF OS_

------------------------------ ------------------------------ --- --- -------------------------
USER7264 EXP_FULL_DATABASE NO YES NO
USER7264 IMP_FULL_DATABASE NO YES NO
USER7264 ROLE_7264 NO YES NO
SQL> select *
2 from user_tab_privs
3 /
GRANTEE OWNER TABLE_NAME

GRANTOR
------------------------------ ------------------------------ ------------------------------ -------
-
USER7264 ALUNO23A BANCO
ALUNO23A
USER7264 ALUNO23A BANCO
ALUNO23A
Ex.26: Dropando o profile profilexxxx

Conectado.
SQL> Drop profile profile_7264

Perfil dropado.
Ex.27: Conectando no Sql/Plus com o usuário aula1 senha aula1 no banco de dados FAI.

Conectado.
Ex.28: Criando um usuário chamado dbaxx (onde xx é um número sequencial), com a

senha dbaxx, utilizando a tablespace tools como tablespace default e a tablespace temp como
tablespace temporária. Estabelecendo que ele terá quota ilimitada as tablespaces tools e users .
SQL> create user dba23

2 identified by dba23
3 default tablespace tools
4 temporary tablespace temp
5 quota unlimited on tools
6 quota unlimited on users;
Usuário criado.
Ex.29: Este usuário terá direito de repassar para outros usuários todos os privilégios que
forem concedidos a ele. Dando os privilégios para executar as seguintes tarefas:
Conectar-se ao Banco;
Criar tabelas, view´s e procedures em qualquer usuário;
Criar e alterar novos usuários;
Criar SnapShot;
Criar Tablespaces;
Criar database link´s (privados e públicos);
Executar procedures do dicionário de dados.
SQL> grant create SESSION to dba23;

SQL> grant create any table, create any view, create procedure to dba23 with
admin option;
SQL> grant create user to dba23 with admin option;

SQL> grant create snapshot to dba23 with admin option;

SQL> grant create tablespace to dba23 with admin option;

SQL> grant create database link to dba23 with admin option;

SQL> grant create public database link to dba23 with admin option;
SQL> grant execute_catalog_role to dba23 with admin option;

Ex.30: Conectando com o usuário dbaxx e dando privilégios para o usuário userxxxx
criar tablespace e criar snapshot. Mas não dê a ele o direito de repassar este privilégio.
SQL> conn dba23/dba23@fai

Conectado.
SQL> grant create tablespace to user7264;

SQL> grant create snapshot to user7264;

Ex.31: Conectando com o usuário aula1 e retirando o privilégio de criar tablespace e criar
snapshot do usuário dbaxx.

Conectado.
SQL> revoke create tablespace from dba23;

Revogação bem-sucedida.
SQL> revoke create snapshot from dba23;

Ex.32: Consultando a view´s do dicionário de dados USER_SYS_PRIVS verificando se
os privilégios dados pelo usuário dbaxx ainda permanecem. Para realizar este select deverá estar
conectado com o usuário userxxxx.
SQL> conn user7264/tha_fla@fai;

Conectado.
SQL> select *
2* from user_sys_privs;

------------------------------ ---------------------------------------- ---------------
USER7264 CREATE SNAPSHOT NO
USER7264 CREATE TABLESPACE NO
Ex.33: Conectado com o usuário aula1 dando privilégios para o usuário dbaxx
selecionar, inserir e atualizar dados nas tabelas matriculas e alunos. Dando direito para que o
usuário dbaxx possa repassar estes privilégios.
Conectado.
SQL> grant select, insert, update on matriculas to dba23 with grant option;
SQL> grant select, insert, update on alunos to dba23 with grant option;
Ex.34: Conectado com o usuário dbaxx dê privilégios para o userxxxx selecionar, inserir
e atualizar dados nas tabelas matriculas e alunos do usuário aula1.
SQL> conn dba23/dba23@fai;

Conectado.
SQL> grant select,insert,update on aula1.matriculas to user7264;

SQL> grant select,insert,update on aula1.alunos to user7264;

Ex.35: Conectando com o usuário userxxxx e selecionando todos os dados das tabelas
matriculas e alunos do usuário aula1.

Conectado.
SQL> select *
2 from aula1.matriculas;
MATRICULA ANO DISCIPLINA

----------------------------- ---------- ----------
1245 2002 BCO DADOS
1246 2002 BCO DADOS
1247 2002 BCO DADOS
1248 2002 BCO DADOS
1249 2002 BCO DADOS
SQL> select *
2 from aula1.alunos;
MATRICULA NOME ENDERECO FONE

------------------------ ---------- ----------------------------------- -----------------
1245 LUIZ RUA A, 201 5111-0987
1246 FATIMA RUA B, 201 5222-0987
1247 DOMENICA RUA C, 229 5333-0987
1248 KATIA RUA D, 239 5444-0987
1249 DENISE RUA B, 109 5555-0987
Ex.36: Conectado agora com o usuário aula1, retirando o privilégio de selecionar,
atualizar das tabelas matriculas e alunos do usuário dbaxx.
SQL> revoke select,insert,update on aula1.matriculas from dba23;

SQL> revoke select,insert,update on aula1.alunos from dba23;

Ex.37: Conectado com o usuário userxxxx, tentando selecionar novamente todos os

dados das tabelas matriculas e alunos do usuário aula1.

Conectado.
SQL> select *
2 from aula1.matriculas;
MATRICULA ANO DISCIPLINA

-------------------------------- ---------- ----------
1245 2002 BCO DADOS
1246 2002 BCO DADOS
1247 2002 BCO DADOS
1248 2002 BCO DADOS
1249 2002 BCO DADOS
SQL> select *
2 from aula1.alunos;
MATRICULA NOME ENDERECO FONE

---------- ---------- ---------------------------------------- ------------------------
1245 LUIZ RUA A, 201 5111-0987
1246 FATIMA RUA B, 201 5222-0987
1247 DOMENICA RUA C, 229 5333-0987
1248 KATIA RUA D, 239 5444-0987
1249 DENISE RUA B, 109 5555-0987
Ex.38: Conectado com o usuário userxxxx, verificando quais privilégios que este usuário
tem nas tabelas matriculas e alunos.

Conectado.
SQL> select *
2 from user_sys_privs
3 /

------------------------------------------ ---------------------------------------- ---
USER7264 CREATE SNAPSHOT NO
USER7264 CREATE TABLESPACE NO
Não foram perdidos nenhum privilegio, pois o usuário user7264 tem o

privilegio das Roles de exp_full_database, imp_full_database.
[CRISTINA E RICARDO, 2002]

12) Conclusão
Na elaboração deste trabalho permitiu – se conhecer um pouco mais sobre Banco de

Dados, Sistemas Gerenciadores de Banco de Dados e SQL tão utilizados na informática.
Estudando Banco de Dados e aprendendo a utiliza-los é algo essencial para o exercer da
informática, pois se trata de uma ciência geradora de informações e cada vez mais é necessário
armazena-las e ter acesso às mesmas de maneira rápida e precisa.
Foi procurado enfatizar aspectos básicos de banco de dados, seu comportamento, sua
utilização, os tipos de usuários, arquiteturas e modelos. O objetivo maior foi alcançado, de gera-
se um conteúdo básico e introdutório no que se diz respeito ao que existe de atual em Banco de
Dados.
O Banco de Dados entrou no mercado a mais de 20 anos e existem dezenas de
fornecedores com suas soluções oferecendo diversos serviços e arquiteturas (Os principais:
Orientados a Objetos, Relacionais e Hierárquicos). Em se tratando de bancos de dados
relacionais, os mesmos estão incorporando recursos orientados a objetos em seus produtos da
próxima geração. Essas duas tendências devem prosseguir. Ambas proporcionam poderosos
recursos de modelagem orientada a objeto aos desenvolvedores de aplicação.
Enfim, Banco de Dados é uma tecnologia que possui um potencial enorme de crescimento
e avanço e novas e inovadoras idéias têm aparecido. Como sugestão de trabalhos futuros, dar
mais enfoque no estudo sobre a linguagem SQL, como melhorar a performance de consulta.
Também, um assunto extremamente importante e inovador, o estudo de sua variante, o OQL -
Object Query Language e sua ênfase em Banco de Dados Orientados a Objetos.
Referência:
Livros:
[YONG, 1983] – Banco de Dados / Organização Sistemas e Administração

Autor: Chu, Shao Yong
Ano: 1983
[CORNACHIONE, 1998] – Informática para as áreas de Contabilidade, Administração e

Economia
Autor: Cornachione Jr
Edgard Bruno
Editora: Atlas / São Paulo
Edição: 2 / Ano: 1998
[SILBERSCHATZ, 1999] - Sistema de Banco de Dados

Autor: Abraham Silberschatz
Henry F. Korth
S. Sudarshan
Editora: Makron Books / São Paulo
Edição:3 / Ano: 1999
[OLIVEIRA, 1999] – Mini dicionário Compacto de Informática

Autor: Renato da Silva Oliveira
Editora: Rideel / São Paulo
Edição:2 / Ano: 1999
[DATE, 2000] – Introdução a Sistema de Banco de Dados

Autor: Date, C.J.
Editora: Campus / Rio de Janeiro
Ano: 1999
Apostilas:
[MOREIRA, 2002] – Sistema de Banco de Dados

Universidade São Judas Tadeu
Autor: Profº Ricardo Moreira
Ano: 2002
[INÁCIO, 2002] – Sistema de Banco de Dados

Oracle Brasil
Autor: Profº João Inácio
Ano: 2002
Revista:
[LIMA, 2003] – Revista SQL Magazine

Jornalista: João Alberto de O. Lima
Edição: 4
Distribuidora: Fernando Dist. S/A
Ano: 2003
[BEZERRA, 2003] – Revista SQL Magazine

Jornalista: Eduardo Bezerra
Edição: 4
Distribuidora: Fernando Chinaglia Dist. S/A
Ano: 2003
Estudo de Casos:
[CRISTINA E RICARDO, 2002] – Exercícios feitos em aula

Local: Unifai Ipiranga
Professores: Cristina
Ricardo
Ano: 2002
Sites:
[UNIMAR, 2003] - http:// www.unimar.edu.br
[ITA, 2003] – http:// www.ita.com.br
http:// www.avec.br/download/sql.doc
http:// www.eac.fea.usp.br/eac/docentes/edgard/eac191www/arquivos%5Ceac191_grupo3.doc
http:// orbita.starmedia.com/curso_tecinf/vb60sql.doc
http:// www. macoratti.net/cursosql.htm

Banco de Dados III

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Banco de Dados III

Enviado por

Direitos autorais:

Formatos disponíveis

CENTRO UNIVERSITÁRIO ASSUNÇÃO

JAQUELINE LACERDA DOS SANTOS

Banco de Dados – Sql

Banco de Dados – Sql

Trabalho de Conclusão de Curso apresentado

ORIENTADOR: Profº. Ms. ANDRÉ LUIZ GARCIA PEREIRA

Figura 1 - Tabela de Dados.......................................................................................... 13

Figura 22 - Hierarquia de tipos de dados do SQL 1999, os retângulos destacados

DBM ( Data Base Manager - Gerenciador de Banco de Dados ).

Objetiva-se com esse trabalho, identificar os principais avanços da tecnologia de Banco de

O Banco de Dados foi criado para guardar as informações no computador e armazena -

TB_ENDEREÇO Nome da Tabela

Fig.1.: Tabela de Dados

Um Sistema de Banco de Dados não é nada mais do que um sistema de manutenção de

Um Banco de Dados é uma coleção lógica de dados com um significado ligado a

Um Banco de Dados é projetado, criado e armazenado com dados para um

Um Banco de Dados representa alguns aspectos do mundo real, no qual é

Existem inúmeros exemplos de Banco de Dados. Ao se procurar um número na lista

Alguns exemplos são:

Os dados operacionais das empresas provavelmente incluiriam o seguinte dados sobre:

Portanto, um “Banco de Dados“ é um deposito de dados armazenados. Geralmente ele é

Um Banco de Dados compartilha na realidade uma conseqüência do fato de ser integrado.

Com a necessidade e o compromisso especifico do governo americano, em fazer pousar

Surgiu na década de 60, organizava dados em uma estrutura de Bancos de Dados

Município Rua Bairro CEP

Fig.3: Modelo Hierárquico

Utilizado principalmente no final da década de 60 e durante a década de 70, organizava

Fig.4.: Modelo de Redes

Arquivos são conjunto de Dados, organizados em registros, fixos em suportes magnéticos

Fig.6.: Os discos rígidos, normalmente, são sobrepostos em pilhas, com um pequeno

Arquivo – Mestre: o qual contém informações que sofrem poucas alterações;

Arquivo de transações ou movimento: contém informações que serão utilizadas

Arquivo de trabalho: contém informações que são armazenadas temporariamente e

Coluna Nom_Aluno Mat_Aluno Cur_Aluno

Fig.7.: Tabela Cad_Curso

Campo é um item relacionado ao objeto em questão. Todos os itens incluídos numa

Existem três tipos de chaves que são as mais utilizadas:

A Chave Primária é a Chave Candidata que é escolhida pelo projetista do Banco de

Nom_Aluno Mat_Aluno Cur_Aluno

Fig.8.: Tabela Cad_Curso

Cod_Empresa Num_Depend Nom_Depend Tpo_Depend Dat_Nascimento

Fig.9.: Tabela Cad_Dependentes

4.2) Chave Estrangeira

A Chave Estrangeira é uma coluna cujo os valores aparecem necessariamente na Chave

Cod_Empresa Nom_Func Cod_Depto

Cod_Empresa Nom_Func Cod_Depto RG_Func

Fig.10.: Tabela Cad_Funcionário

Existem três noções básicas utilizadas pelo modelo E – R:

5.1) Conjunto de Entidades

Atributos possíveis para o conjunto de entidades empréstimo são:

Para cada atributo existe um conjunto de valores possíveis, chamado domínio, ou

5.2) Conjunto de Relacionamento

Participação: é a associação entre os conjuntos de entidades em um conjunto de

A definição de papéis das entidades em um relacionamento é útil quando o significado de

5.3) Diagrama Entidade – Relacionamento

É composto pelos seguintes componentes:

Retângulos: representam os conjuntos de entidades;

Cliente Devedor Empréstimo

Existem dois tipos de entidades:

Empréstimo Pagamentos_ Pagamentos

Fig.12.: DER com Entidades Fracas [SILBERSCHATZ, 1999]

6.1) Estrutura Básica

Nom_Morador Nom_Rua Num_Casa

Fig.13.: Tabela Endereço