Você está na página 1de 89

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

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

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 -

Figura 12

DER

34

-

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

Figura 22 -

através do operador ‘.’

52

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.

Fig.1.: Tabela de Dados

TB_ENDEREÇO COD_MORADOR NOM_MORADOR COD_RUA NOM_RUA NUM_CASA NUM_FONE
TB_ENDEREÇO
COD_MORADOR
NOM_MORADOR
COD_RUA
NOM_RUA
NUM_CASA
NUM_FONE

Nome da Tabela

Campos da

Tabela

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
Arquivos Lógicos Informações para o usuário Banco de Dados (Arquivos Físico) Fig.2.: Na figura abaixo

ArquivosLógicos Informações para o usuário Banco de Dados (Arquivos Físico) Fig.2.: Na figura abaixo é

Lógicos

Informações para o usuário o usuário

Banco de Dados (Arquivos Físico) (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é

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 “ ( 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

o

4

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

6

¹ 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

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
Endereço

Rua

Bairro

Município

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.

porque não há a restrição a um só tipo de relacionamento que vigora. Fig.4.: Modelo de
porque não há a restrição a um só tipo de relacionamento que vigora. Fig.4.: Modelo de
porque não há a restrição a um só tipo de relacionamento que vigora. Fig.4.: Modelo de
porque não há a restrição a um só tipo de relacionamento que vigora. Fig.4.: Modelo de
porque não há a restrição a um só tipo de relacionamento que vigora. Fig.4.: Modelo de
porque não há a restrição a um só tipo de relacionamento que vigora. Fig.4.: Modelo de
porque não há a restrição a um só tipo de relacionamento que vigora. Fig.4.: Modelo de

Fig.4.: Modelo de Redes

[SILBERSCHATZ, 1999]

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 [SILBERSCHATZ, 1999]
Fig.5.: Modelo de Relacional [SILBERSCHATZ, 1999]

Fig.5.: Modelo de Relacional

[SILBERSCHATZ, 1999]

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]

e telefones, gravada numa BBS ; etc. [OLIVEIRA, 1999] Fig.6.: Os discos rígidos, no rmalmente, são

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.

Coluna

(Atributo)

Nome do Campo (Nome do Atributo) Nom_Aluno Mat_Aluno Cur_Aluno Paulo 7150 Economia Paula 7152 Administração
Nome do Campo
(Nome do Atributo)
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

Linha

(Tupla)

Valor do

Campo

(Valor do

Atributo)

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

72

Pedro

2

73

Eduarda

1

TB_Empresa

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
Seguro_Social
Rua_Cliente
Número_Empréstimo
Saldo
Nome_Cliente
Cidade_Cliente
Cliente
Devedor
Empréstimo

Fig.11.: DER

[SILBERSCHATZ, 1999]

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

Acesso

Lógico

Acesso Lógico Acesso físico

Acesso

físico

Programa
Programa
Sistema operacional Arquivo
Sistema
operacional
Arquivo

Fig.14.: Processamento sem SGBD

[UNIMAR, 2003]

Programa Chamada externa SGBD Acesso lógico Sistema operacional Acesso físi co Método de acesso Banco
Programa
Chamada
externa
SGBD
Acesso
lógico
Sistema
operacional
Acesso
físi co
Método
de acesso
Banco d e
Dad os

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]

a dados era necessário que o programador navegasse nas estruturas de dados, para obter os de

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 )

QL ANSI – SQL ( 1986) Aceito pelo ANSI X3H2 SQ L 92 ( 1992 )
QL ANSI – SQL ( 1986) Aceito pelo ANSI X3H2 SQ L 92 ( 1992 )
QL ANSI – SQL ( 1986) Aceito pelo ANSI X3H2 SQ L 92 ( 1992 )
QL ANSI – SQL ( 1986) Aceito pelo ANSI X3H2 SQ L 92 ( 1992 )
QL ANSI – SQL ( 1986) Aceito pelo ANSI X3H2 SQ L 92 ( 1992 )
QL ANSI – SQL ( 1986) Aceito pelo ANSI X3H2 SQ L 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 SQ L 1999, os retângulos destacados correspondem aos

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_BANCO NUMBER(10), COD_AGENCIA NUMBER(7), NOME_AGENCIA VARCHAR2(30), ENDERECO VARCHAR2(40)) TABLESPACE TS_DADOS01

-----------------------------------------------------------------------

CREATE TABLE CONTA_CORRENTE (NUM_CONTA NUMBER(10), COD_BANCO NUMBER(10), COD_AGENCIA NUMBER(7),

SALDO

NUMBER,

TIPO

VARCHAR2(1),

CPF_CGC NUMBER(12)) TABLESPACE TS_DADOS01

-----------------------------------------------------------------------

CREATE TABLE CLIENTE (CPF_CGC NUMBER(12), NOME VARCHAR2(50), ENDERECO VARCHAR2(60), FONE VARCHAR2(15)) TABLESPACE TS_DADOS01

-----------------------------------------------------------------------

CREATE TABLE EMPRESTIMO (NUM_EMPRESTIMO NUMBER(5), VALOR NUMBER, PRAZO NUMBER(2), CPF_CGC NUMBER(12), COD_BANCO NUMBER(10), COD_AGENCIA NUMBER(7)) TABLESPACE TS_DADOS01

-----------------------------------------------------------------------

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) USING INDEX TABLESPACE TS_INDEX01

-----------------------------------------------------------------------

ALTER TABLE CONTA_CORRENTE ADD CONSTRAINT PK_CONTA_CORRENTE PRIMARY KEY(NUM_CONTA, COD_BANCO, COD_AGENCIA) USING INDEX TABLESPACE TS_INDEX01

-----------------------------------------------------------------------

ALTER TABLE CLIENTE ADD CONSTRAINT PK_CLIENTE PRIMARY KEY(CPF_CGC) USING INDEX TABLESPACE TS_INDEX01

-----------------------------------------------------------------------

ALTER TABLE EMPRESTIMO ADD PRIMARY KEY(NUM_EMPRESTIMO) USING INDEX TABLESPACE TS_INDEX01

-----------------------------------------------------------------------

Criação das Constraints FOREIGN KEY ===============================

ALTER TABLE AGENCIA_BANCO ADD CONSTRAINTS

FK_BANCO

FOREIGN

KEY(COD_BANCO)

REFERENCES

BANCO(COD_BANCO)

-----------------------------------------------------------------------

ALTER

TABLE

CONTA_CORRENTE

ADD

CONSTRAINT

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)

-----------------------------------------------------------------------

ALTER TABLE CONTA_CORRENTE ADD CONSTRAINT FK_CONTA_CORRENTE_CFP FOREIGN KEY(CFP_CGC) REFERENCES CLIENTE(CFP_CGC)

-------------------------------------------------------------------------

10.3) Uma aplicação do SQL

[CRISTINA E RICARDO, 2002]

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>

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 Operação de Grant bem-sucedida.

SQL> grant create user, alter profile to user7264; Operação de Grant bem-sucedida.

SQL> grant drop profile to user7264; Operação de Grant bem-sucedida.

SQL> grant create any trigger to user7264;

Operação de Grant bem-sucedida.

SQL> grant create role to user7264;

Operação de Grant bem-sucedida.

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

Operação de Grant bem-sucedida.

SQL> grant exp_full_database, imp_full_database to user7264;

Operação de Grant bem-sucedida.

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

3 connect_time

4 sessions_per_user

5 failed_login_attempts 3

3000

50

unlimited

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), profile criado no exercício 7 (profilexxxx).

SQL> alter user user7264 profile profile_7264; Usuário alterado.

designando a ele o

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 userxxxx.

SQL> conn aula1/aula1@fai Conectado.

SQL> alter user user7264 account unlock; Usuário alterado.

para desbloquear o usuário

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; Operação de Grant bem-sucedida.

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; Operação de Grant bem-sucedida.

SQL> grant select, insert, update, delete on cliente to role_7264; Operação de Grant bem-sucedida.

SQL> grant select, insert, update, delete on conta_corrente to role_7264; Operação de Grant bem-sucedida.

SQL> grant select, insert, update, delete on emprestimo to role_7264; Operação de Grant bem-sucedida.

Ex.19: Dando grant da role_xxxx para o usuário userxxxx :

SQL> grant role_7264 to user7264; Operação de Grant bem-sucedida.

Ex.20: Conectando com o usuário userxxxx e tentando inserir novamente dados na tabela banco do usuário alunoxx.

os seguintes

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 (COD_BANCO NUMBER(10), COD_AGENCIA NUMBER(7), 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

Tabela criada.

endereco

varchar2(40) );

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; Operação de Grant bem-sucedida.

Ex.24: Conectando o usuário userxxxx e criaando a constraint novamente:

SQL> conn user7264/tha_fla@fai 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

11 linhas selecionadas.

SQL> select *

2 from user_role_privs;

ADM DEF OS_

USERNAME

------------------------------ ------------------------------ --- --- -------------------------

GRANTED_ROLE

USER7264

EXP_FULL_DATABASE

NO YES NO

USER7264

IMP_FULL_