Confundiu ? Vamos lá.
Quando criamos uma tabela no SQL, com suas colunas, índices, tipos de dados, etc., estas informações são armazenadas no Database Catalog, um conjunto de tabelas que armazenam informações sobre os objetos que o usuário criou no banco de dados, como definição de tabela, código fonte de uma Stored Procedure ou definição de uma view.
Por exemplo, quando utilizamos a seguinte instrução no SQL Server:
SELECT * FROM TABELA1
Como o servidor sabe quais são os campos que deve ser retornados? Bom, neste caso, o SQL Server utiliza um tabela de sistema chama syscolumns, contém todos os campos de todas as tabelas dentro de um banco de dados e verifica quais são os campos da TABELA1 que devem ser retornados para a instrução. Estes dados que estão nestas tabelas especiais são chamados metadados.
Pois bem, existem basicamente três maneiras de retornar metadados no SQL Server:
1. Através de tabelas de sistema
2. Através de funções do SQL Server
3. Através de Schema Views
1. Através de tabelas de sistema
Como vimos no exemplo acima, os metadados são armazenados em tabelas de sistema. Todas as tabelas de sistema começam pelo prefixo sys e em hipótese alguma devem ser modificadas, pois caso alguma coisa errada ocorra com elas, o banco de dados inteiro pode deixar de funcionar. A Microsoft não recomeda o acesso direto (isto é , dar um SELECT nestas tabelas) a estas tabelas, pois elas podem mudar de nome nas próximas versões do produto, tornando seu código inválido e sem nenhuma escalabilidade.
Abaixo seguem algumas tabelas de sistema e um breve cometário sobre cada uma:
|
sysobjects |
Armazena informações sobre todos os objetos do B.D. |
|
sysindexes |
Armazena informações específicas sobre índices do B.D. |
|
syscolumns |
Armazena todas as informações sobre todas as tabelas do B.D. |
|
syscomments |
Armazena o código fonte de Stored Procedures e funções do B.D. |
|
syslocks* |
Armazena informações sobre os locks ( travas ) dos objetos do B.D. |
|
sysdatabases* |
Armazena informações sobre os Bancos de dados do Servidor SQL Server |
Obs: As tabelas de sistema marcadas com * somente existem no B.D. (banco de dados) MASTER
2.
Através de funções do SQL Server
Uma outra maneira mais segura de se obter metadados é utilizando algumas funções já prontas do SQL Server para acessar os dados. Estas funções só foram implementadas a partir do SQL Server 7.0.
No exemplo, utilizamos duas funções: primeiro a função OBJECT_ID() que retorna um identificador interno do SQL Server para um objeto e depois a função OBJECTPROPERTY() para retornar se o objeto é uma tabela ou não:
SELECT OBJECTPROPERTY(OBJECT_ID('TABELA1'),'isTable')
O retorno da função depende de qual propriedade do objeto se está consultando. Neste caso, a propriedade chama-se ‘isTable’ e a fução OBJECTPROPERTY() retorna o valor 1 se o objeto chamado TABELA1 for uma tabela, 0 se não for uma tabela e NULL se o objeto não existir no banco de dados atual.
3. Através de Schema Views
O último método de acesso a metadados é o mais recomendado pela Microsoft, pois o usuário irá consultar algumas views (instruções SQL pré-compiladas) que encapsulam o uso das tabelas de sistema. Estas Schema Views só foram implementadas as partir do SQL Server 7.0 e para o pessoal que utiliza Oracle, as Schema Views são muito parecidas com aquelas views com começam com V$(Dynamic performance views). Alguns exemplos comentados:
SELECT
COLUMN_NAME ,IS_NULLABLE , DATA_TYPE FROM INFORMATION_SCHEMA.COLUMNS
WHERE
TABLE_NAME = 'TABELA1'
--
Retorna o nome, se a columa permite null e o tipo de dados
de todas as colunas
--
da tabela chamada ‘TABELA1’
WITH ENCRIPTION
SELECT
SPECIFIC_NAME , ROUTINE_TYPE , ROUTINE_DEFINITION FROM INFORMATION_SCHEMA.ROUTINES
--
Retorna o nome , o tipo de rotina ( Stored Procedure ou função
) e o código fonte da
--
rotina , desde que a mesma não tenha sido criada com a opção
SELECT
TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
WHERE
TABLE_TYPE = 'VIEW'
--
Retorna todas as tabelas do banco de dados atual , que na
verdade são views
Bom, por hoje é só pessoal. Até a semana que vem.
Os textos publicados neste espaço são de responsabilidade única de seus autores (colunistas e leitores) e podem não expressar necessariamente a opinião do iMasters.
Mauro Pichiliani é mestre em computação, possui as certificações MCP, MCDBA, MCT e MCTS e atua como consultor de banco de dados com enfoque na área de tunning.
2001 - iMasters FFPA Informática Ltda - Todos os direitos reservados.