segunda-feira, 9 de junho de 2008

VIEW - Tabela Virtual

VIEW é uma tabela única derivada de outras tabelas. Essas outras tabelas podem ser tabelas de base ou outras VIEWS existentes. Uma VIEW não existe na forma física; ela pode ser considerada uma tabela virtual, em contraste com tabelas de base, cujos registros são efetivamente armazenados no banco de dados. Podemos imaginar uma VIEW como um modo de especificar uma consulta à qual precisamos com frequência.

O comando para criação de uma VIEW é CREATE VIEW. Uma VIEW é composta do nome de uma tabela, uma lista de nomes de atributos e uma consulta para especificar seu conteúdo. Se um atributo for uma função do banco de dados como SUM, AVG, COUNT, MAX, etc. ou uma operação aritmética você deve especificar um nome para identificar os atributos, senão é opcional.

Exemplo - tabelas de base:

Create Table COLABORADOR (

id_colaborador integer not null,

id_supervisor integer,

id_depto integer,

nomer varchar(50),

sexo varchar(1),

data_nascimento date,

salario numeric(15,4),

constraint pk_colaborador primary key (id_colaborador),

constraint fk_colab_supervisor foreign key (id_supervisor) references colaborador (id_colaborador),

constraint fk_colab_departamento foreign key (id_depto) references departamento (id_depto) on update cascade)

);

Create Table DEPARTAMENTO (

id_depto integer not null,

id_gerente integer not null,

nome_depto varchar(30),

constraint pk_departamento primary key (id_depto),

constraint fk_depto_gerente foreign key (id_gerente) references colaborador (id_colaborador) on update cascade)

);

Create Table PROJETO (

id_projeto integer not null,

id_depto integer not null,

nome_projeto varchar(30),

constraint pk_projeto primary key (id_projeto),

constraint fk_projeto_depto foreign key (id_depto) references departamento (id_depto) on update cascade)

);

Create Table COLABORADOR_PROJETO (

id_colaborador integer not null,

id_projeto integer not null,

horas float not null default 0.00,

constraint pk_colab_projeto primary key (id_colaborador, id_projeto),

constraint fk_cp_colaborador foreign key (id_colaborador) references colaborador (id_colaborador) on update cascade,

constraint fk_cp_projeto foreign key (id_projeto) references projeto (id_projeto) on update cascade)

);

E a partir delas criar a seguinte view:

Create View PROJETOS_COLABORADOR

as Select c.id_colaborador,

c.nome,

p.nome_projeto,

d.nome_depto,

cp.horas

From Colaborador_Projeto cp

Join Colaborador c on (c.id_colaborador = cp_id_coladorador)

Join Projeto p on (p.id_projeto = cp.id_projeto)

Join Departamento d on (d.id_depto = p.id_projeto)

Uma VIEW está sempre atualizada, já que quando alterarmos os registros nas tabelas de base das quais a VIEW é definida, a VIEW deve automaticamente refletir essas alterações. Desta forma, uma VIEW não efetua nenhuma ação na hora de sua criação, e sim na hora que especificamos uma consulta. Sendo de responsabilidade do SGDB e não do usuário assegurar que a VIEW esteja sempre atualizada.

  • Uma VIEW com uma única tabela definidora é atualizável se os atributos contiverem a chave primária da relação de base, porque mapeará cada registro resultante para um único registro da tabela de base;
  • VIEWS definidas em múltiplas tabelas utilizando junções geralmente não são atualizáveis;
  • VIEWS definidas com o uso de funções de agregação e de agrupamento não são atualizáveis.

Amigos, este artigo é uma pequena mostra do poder das VIEWS e para aqueles que queiram ter um maior conhecimento, aconselho a leitura de uma bibliografia específica para o SGDB utilizado - para o nosso bom Firebird recomendo os livros "Firebird Essencial" (capítulo 14) e "Firebird - O Banco de Dados do Novo Milênio" (capítulo 13), ambos de autoria de Carlos Cantu.

Referência:

Navathe, Elmasri, Sistemas de Banco de Dados - Fundamentos e Aplicações, Rio de Janeiro, 2000, Ed. LTC, 3ª Ed., 837p.

Um comentário:

Alessandro Palma disse...

Meu caro amigo,
Desde que comecei a trabalhar com o Firebird, desde a versão do Interbase utilizo as Views.
Percebi ao longo do tempo que realmente elas trazem vantagens como voce mesmo cita no seu artigo, porém à medida que o tempo foi passando e meus conhecimentos foram se aprofundando e meus encantamentos com elas foram sendo inevitalvementes sendo ofuscados pelos beneficios das SP (Store procedures).
Hoje meus aplicativos se restrigem basicamente a entrada e saida de dados, e deixo todo trabalho pesado de processamento com o Firebird.
Percebi também com isto que torna mais facil a manutenção do sistema, alem da significativa melhoria na velocidade do sistema.
Mas o que me fez relmente eu romper meu antigo relacionamento com as VIEWS foi a dificuldade quando criamos dependencias entre elas.
De qualquer forma é inevitável que a cada dia que passa consigo perceber que dentre diversas escolhas, o FIREBIRD é uma BELEZA..
abraço
Alessandro Palma
acp@acp-sistemas.com.br
http://acpsistemas.blogspot.com/