Depois de muito tempo sem escrever, vamos nós de novo!

Tenho me deparado sempre com dúvidas de desenvolvedores quanto ao uso de sinônimos públicos. Devemos usar? Não devemos? Cria pra todos os objetos? Não cria? Vamos tentar de uma vez por todas desvendar esse mistério de public synonym no Oracle.

Bom, sinônimos, como bem sabemos são palavras que tem o mesmo significado… isso no português! No Oracle, sinônimo é um pouco diferente, porém sendo um pouco igual! Confuso não? Rs. Vamos simplificar!

No Oracle o sinônimo público (public synonym) é um objeto de banco, cujo dono é PUBLIC (ou seja, todo mundo) que “aponta” para um outro objeto de um determinado schema. Como se fosse uma espécie de link. Por exemplo:

Imagine que você tem uma tabela no schema DONOSIS chamada MINHATABELA. Caso algum usuário que não seja DONOSIS deseje executar um select nesta tabela, você faz o seguinte comando: select * from donosis.minhatabela, mas e se eu não quiser colocar o dono do objeto na frente? Seja para que meus usuários não saibam quem é o dono dos objetos (questões de segurança), seja para que eu simplifique a codificação? Aí eu uso o sinônimo público! Eu crio um sinônimo púbico chamado MINHATABELA que aponta para o objeto de banco: DONOSIS.MINHATABELA. O código para criação é:

create or replace public synonym MINHATABELA for DONOSIS.MINHATABELA;

Após a criação deste sinônimo público, qualquer usuário do banco que executar o select select * from MINHATABELA; conseguirá de forma transparente acessar a tabela MINHATABELA do schema DONOSIS sem nem saber que ela se encontra neste schema! Simples não?

Isso pode ser utilizado para qualquer objeto de banco, como: Views, Procedures, Functions, Packages, Tables, etc.

Claro que para que o acesso ao objeto seja concluído, o usuário que está acessando tem que possuir privilégio no objeto de destino. Ou seja, mesmo com sinônimo público, os privilégios que foram concedidos no objeto de destino continuam funcionando normalmente.

Vantagens?
Simplicidade de codificação (não precisa colocar o nome do dono do objeto na frente).
Transparência de propriedade (não se sabe quem é o dono do objeto).
Simples modificação de objetos (você pode mudar o dono dos objetos, sem impacto algum).

Quando não usar?
Quando o objeto só será utilizado pelo próprio dono. Por exemplo: Se nossa tabela MINHATABELA fosse utilizada apenas por objetos do schema DONOSIS, não tinhamos a menor necessidade de ter um sinônimo, o objeto sendo do próprio schema, não precisamos colocar o schema na frente!

Erros mais comuns:
ORA-01775 loop chain of synonyms – Este erro ocorre geralmente quando ocorre algum problema com o objeto destino que o sinônimo aponta, por exemplo: Se for uma procedure que está inválida; Se for uma tabela que não existe; algo do tipo!

É isso pessoal, espero que tenha ficado claro como funciona e para que serve os sinônimos públicos (public synonym). Por enquanto é só!

Qualquer coisa, basta entrar em contato.

Atc.
Gerson Júnior
gerson.vasconcelos@gmail.com

Com a contribuição do nosso amigo e leitor Robson Cristovão, está aí um guia básico de SQL que pode ser bastante útil para quem está começando no mundo SQL e tem algumas dúvidas quanto ao uso e sitaxe de alguns comandos SQL! Fica a dica!

AND | OR:
SELECT nome_coluna(s)
FROM nome_tabela
WHERE condiçao
AND | OR condiçao


ALTER TABLE (add coluna):
ALTER TABLE nome_tabela
ADD nome_coluna datatype


ALTER TABLE (drop column):
ALTER TABLE nome_tabela
DROP COLUMN nome_coluna


AS (alias for column):
SELECT nome_coluna AS coluna_apelido
FROM nome_tabela


AS (alias for table):
SELECT nome_coluna
FROM nome_tabela AS tabela_apelido


BETWEEN:
SELECT nome_coluna(s)
FROM nome_tabela
WHERE nome_coluna
BETWEEN valor1 AND valor2


CREATE (database):
CREATE DATABASE nome_base_de_dados


CREATE (index):
CREATE INDEX nome_indice
ON nome_tabela (nome_coluna)


CREATE (table):
CREATE TABLE nome_tabela(
nome_coluna1 tipo_dado,
nome_coluna2 tipo_dado,...)


CREATE (unique index):
CREATE UNIQUE INDEX nome_indice
ON nome_tabela (nome_coluna)


CREATE (view):
CREATE VIEW nome_da_view AS
SELECT nome_coluna(s)
FROM nome_tabela
WHERE condiçao


DELETE:
DELETE FROM nome_tabela
OU
DELETE FROM nome_tabela
WHERE condiçao


DROP (database):
DROP DATABASE nome_base_de_dados


DROP (index):
DROP INDEX nome_tabela.nome_indice


DROP (table):
DROP TABLE nome_tabela


GROUP BY:
SELECT nome_coluna1,SUM(nome_coluna2)
FROM nome_tabela
GROUP BY nome_coluna1


HAVING:
SELECT nome_coluna1,SUM(nome_coluna2)
FROM nome_tabela
GROUP BY nome_coluna1
HAVING SUM(nome_coluna2) valor_da_condiçao


IN:
SELECT nome_coluna(s)
FROM nome_tabela
WHERE nome_coluna
IN (valor1,valor2,..)


INSERT:
INSERT INTO nome_tabela
VALUES (valor1, valor2,....)
OU
INSERT INTO nome_tabela
(nome_coluna1, nome_coluna2,...)
VALUES (valor1, valor2,....)


LIKE:
SELECT nome_coluna(s)
FROM nome_tabela
WHERE nome_coluna
LIKE padrao


ORDER BY:
SELECT nome_coluna(s)
FROM nome_tabela
ORDER BY nome_coluna [ASC | DESC


SELECT:
SELECT nome_coluna(s)
FROM nome_tabela


SELECT (all):
SELECT * FROM nome_tabela


SELECT (distinct):
SELECT DISTINCT nome_coluna(s)
FROM nome_tabela


SELECT (into - usado para criar cópias auxiliares das tabelas):
SELECT * INTO new_nome_tabela
FROM original_nome_tabela
OU
SELECT nome_coluna(s)
INTO new_nome_tabela
FROM original_nome_tabela


TRUNCATE:
TRUNCATE TABLE nome_tabela


UPDATE:
UPDATE nome_tabela
SET nome_coluna=novo_valor
[, nome_coluna=novo_valor]
WHERE nome_coluna = algum_valor


WHERE:
SELECT nome_coluna(s)
FROM nome_tabela
WHERE condiçao


Espero que gostem.

Atc.
Gerson Júnior
gerson.vasconcelos@gmail.com

A dica de hoje é a respeito do seguinte…

Muitas vezes temos a necessidade de fazer algumas alterações nas nossas tabelas, nosso modelo, etc. E aí precisamos levantar quais tabelas recerenciam uma determinada tabela ou coluna, quais as filhas dessas colunas, quais as foreign key que fazem referência a elas e etc.

Aí, podemos usar o seguinte select:


select distinct c.table_name
from dba_constraints c,
dba_cons_columns cc
where c.constraint_type = 'R'
and cc.owner = c.owner
and cc.constraint_name = c.r_constraint_name
and cc.owner = &SCHEMA
and cc.table_name = &TABELA
and cc.column_name = &COLUNA


Claro que temos que mudar os parâmetros &SCHEMA, &TABELA e &COLUNA, para recuperar as tabelas que são filhas da tabela que você deseja.

Exemplo fica melhor não? Vamos lá:

Eu preciso descobrir quais as tabelas que fazem referência a alguma coluna da tabela SOURCE, para tal fazemos o seguinte select:


SQL> select DISTINCT C.TABLE_NAME
2 from dba_constraints c,
3 dba_cons_columns cc
4 where c.constraint_type = 'R'
5 and cc.owner = c.owner
6 and cc.constraint_name = c.r_constraint_name
7 and cc.owner = 'ORABUGIT'
8 and cc.table_name = 'SOURCES'
9 /
TABLE_NAME
------------------------------
PEOPLE_EQUIPS


Como podemos ver, obtemos como resposta a tabela PEOPLE_EQUIPS, portanto podemos ver que nesta tabela tem alguma coluna que referencia através de foreign key uma coluna da tabela SOURCE.

Espero que a dica seja útil!!

Abraços.

Atc.
Gerson Júnior
gerson.vasconcelos@gmail.com

Vamos com mais uma dica interessante sobre Oracle.
Vamos analisar desta vez, os comandos UNION e UNION ALL. Estes comandos servem para que possamos unir mais de uma query (select) em um mesmo comando, trazendo os resultados de ambas as query’s. Que? Entendeu nada!? Vamos lá:

Existe no Oracle a possibilidade de unirmos mais de um comando select de forma que possamos obter o resultados de todos eles unidos (claro!) em um único resultado, como se fosse um comando só, como assim?

Suponha que você possui uma tabela de clientes e uma tabela de funcionários, e você quer trazer todos os códigos e nomes de clientes e funcionários para exibir em um relatório? Como fazer isso? Assim:


Select codcli,
nom_cli,
'C' tipo
from clientes
union
Select cod_func,
nom_func,
'F'
from funcionarios;


Se vocês executarem este comando, teremos todos os clientes e todos os funcionários listados em um mesmo resultado, mas… temos algumas coisas a considerar.

1 – Vocês devem ter notado que os nomes das colunas das tabelas são diferentes, quando eu rodar que nome minha coluna vai ter? O nome das colunas da primeira query da lista de comandos, a primeira query vai mandar em tudo e as colunas do resultado vão receber o nome das colunas da primeira query.

2 – Quando usamos o comando UNION, temos obrigatóriamente que ter a mesma quantidade de colunas e o mesmo tipo de dados das colunas em todas as query’s. Como assim? Suponha que na tabela clientes a coluna cod_cli tenha tipo de dados number e na tabela funcionarios a coluna cod_func tenha tipo de dados varchar2, não pode! Ao executar este comando o banco vai retornar um erro dizendo que as colunas das query’s não estão corretamente relacionadas. Como em ambos os comandos elas são a primeira coluna da query e estarão relacionadas, ambas tem que ter o mesmo tipo.

3 – Não podemos utilizar ORDER BY nas query’s envolvidas, apenas na última query, que ordernará os registros de todas as query’s. Neste caso acima, por exemplo, se na ultima query colocássemos um ORDER BY 1 por exemplo, ele ordenaria o resultado das duas query’s juntas, como se fosse um comando só. Se tiver códigos iguais nas duas query’s, serão trazidos juntos, pois os resultados serão considerados juntos na hora de ordenar.

Outra coisa que comentei no início foi o UNION ALL, qual a diferença dele pro UNION? O UNION utilizado sozinho faz um distinct no resultado da query, ou seja, se tiverem resultados repitidos eles não serão exibidos, será exibida apenas uma ocorrência. Suponha que por coincidência tenhamos um cliente com código 1 e nome CICERO e tenhamos um funcionario com código 1 e nome CICERO também, caso não tivéssemos essa coluna tipo para diferenciar os registros de clientes e funcionários teríamos a ocorrência 1 CICERO apenas uma vez em nosso resultado. Já usando o UNION ALL, independente da quantidade de registros repetidos que sejam retornados, todos serão exibidos.

Como usa? Assim:


Select codcli,
nom_cli,
'C' tipo
from clientes
union all
Select cod_func,
nom_func,
'F'
from funcionarios;


Qual a diferença? Só o all depois do union, depois disso o resto o Oracle resolve. Espero esse tal de Oracle!!

Momento DBA: Para o banco, por não precisar se preocupar em verificar se existem resultados iguais para que exiba apenas um deles, o UNION ALL tem bem menos custo para ser executado, portanto, se você tiver query’s em que você tem certeza que não serão retornados valores repetidos (como essa do exemplo, em que temos uma coluna tipo para diferenciar) use sempre UNION ALL, seu DBA e seu Banco de Dados agradecem!

É isso pessoal, espero que tenham entendido e que gostem.
Qualquer dúvida, sugestão, reclamação etc não deixem de entrar em contato.

Atc.
Gerson Júnior
gerson.vasconcelos@gmail.com