Privilégio de INSERT | Oracle

Privilégio de INSERT | Oracle

Será que quando se dá o privilégio de INSERT numa tabela a um role isso implicitamente atribui a esse role a possibilidade de "ler" (SELECT) linhas da tabela?

Para começar considere-se a tabela "Data" mostrada na Figura 1 (pertencente ao esquema IMDB) à qual se vai atribuir a autorização de inserção de linhas ao role sousa:

SQL> GRANT INSERT ON "Data" TO sousa;

Figura 1: Tabela Data.

Agora falta testar a hipótese. Para tal entramos como sousa, e:

SQL> SELECT * FROM "Data";

O resultado, como seria de esperar, é uma mensagem de erro:

                              ORA-01031: insufficient privileges
                              01031. 00000 -  "insufficient privileges"

Apesar de em termos organizacionais não fazer grande sentido que alguém que pode registar dados não os consiga ler, de facto os privilégios nos sistemas de bases de dados relacionais cumprem com o objectivo com que foram pensados. O que pode ser facilmente demonstrado digitando o seguinte comando:

SQL> INSERT INTO "Data" ("Chave da Data", "Descrição Completa da Data",
          "Descrição Abreviada da Data", "Século", "Data-SQL")
          VALUES ('5', '5 de Janeiro de 2017', '05/01/2017', 'XXI',
          TO_DATE('2017-01-05', 'YYYY-MM-DD'));

Read More

A importância dos metadados

Os metadados são a fonte “dos/sobre” os dados em si mesmo. É aquilo que normalmente os utilizadores da informação não “vêm” mas que de uma forma, mais ou menos imperceptível, estão associados aos dados que eles utilizam. Enquanto a grande maioria dos utilizadores não vê, nem tem interesse em ver, há casos em que querem ver mas não os deixam.

Em Setembro de 2013 o supremo tribunal do estado do Arizona (EUA) decretou que os metadados (electrónicos) são do domínio público ao contrário do que uma entidade patronal pretendia. Enquanto numa imagem os metadados podem ser, ou servir, como meros marcos espaciais ou temporais, já no caso de registos pessoais eles podem ser fundamentais na vida de uma pessoa: quem escreveu as anotações sobre o desempenho profissional, em que data essas notas foram adicionadas, em que sistema informático, entre muitas outras hipóteses. A base para essa decisão do tribunal é a de que os metadados são parte integrante dos dados e que não têm existência ou significado quando tomados de uma forma isolada. Por exemplo, ter conhecimento de que o metadado “velocidade do obturador” numa fotografia é de 1/100s só faz sentido quando associado ao objecto.

James Comey confirmado pelo Senado dos EUA para comandar o FBI em Julho de 2013, durante uma audição na Comissão de Justiça do Senado, no dia 9 desse mês, disse que de um modo geral a análise de metadados é uma forma muito importante de ajuda ao combate contra-terrorista.

O jornal “Le Monde”, de 4 de Julho de 2013, noticiou que o estado Francês dispõe de um programa de escutas, semelhante ao norte-americano “Prism”, que de uma forma sistemática recolhe sinais digitais transmitidos entre computadores e telefones, i.e., mensagens de email, de SMS, Facebbok ou Twitter, que são armazenados numa gigantesca base de dados. Mas, as autoridades não se interessam pelos conteúdos das mensagens, mas antes pelo seu contexto. Ou seja, é mais interessante saber quem são o emissor e o receptor do que ter conhecimento da mensagem em si mesma. O que está a ser “escutado” são os metadados.

Este conhecimento, que em inglês se costuma designar como “signals intelligence”, com origem eletromagnética, como por exemplo, os nomes de quem liga e de quem atende, o local, a data, a duração, o tamanho da mensagem, o assunto, tudo isto distribuído por todas as formas de comunicação (email, SMS, FAX, Google, facebook, Yahoo, Twitter, etc. é uma quantidade astronómica de metadados que pode ser utilizada com múltiplos propósitos.

O termo metadado é claramente ambíguo. Pode ser utilizado com objetivos e funções muito diversas. Tem igualmente diversas classificações e conceitos. Um deles subdivide-os em metadados estruturais e descritivos; o primeiro está associado ao desenho e especificações das estruturas de informação, enquanto, por outro lado, os metadados descritivos tem a ver com o próprio conteúdo dos dados. Um bom exemplo deste último caso são os catálogos (em papel ou digital) das bibliotecas. Imagine-se a dificuldade, ou mesmo a impossibilidade, em encontrar um livro numa biblioteca sem o respectivo sistema de catalogação. Quem seria capaz de encontrar um determinado exemplar num universo de 50000 volumes sem qualquer tipo de auxílio?

A adição de metadados beneficia bastante a qualidades dos dados. Outro exemplo: uma página web pode incluir metadados especificando a linguagem em que está escrita, que ferramentas foram utilizadas na sua construção ou palavras-chaves que ajudam os motores de busca a localizá-la.

Os metadados são constituídos por um conjunto de descritores organizados numa estrutura e, que informaticamente podem ser trabalhados de diversas maneiras, e que se destinam a descrever qualquer forma de “dado”. Os metadados estão “espalhados” por todos os sectores de actividade.

Pode-se afirmar que no campo da análise de informação os metadados são mais importantes que o próprio conteúdo da informação. São como que um “anzol” que “pesca” os dados mais pertinentes numa determinada situação. Tendo os metadados uma estrutura então podem ser utilizados como matéria-prima em diversos tipos de operações, i.e., uma estrutura de suporte que, por exemplo, descreve, localiza no tempo e no espaço simplifica muito a pesquisa, gestão e utilização das próprias peças de informação.

Read More

O talento em bases de dados

Há uma grande procura de profissionais na área das bases de dados, nomeadamente para o ambiente de administração de bases de dados (os denominados DBAs), como se pode rapidamente concluir através de breves pesquisas, utilizando a expressão "base dados", em sites especializados em ofertas de emprego em áreas mais tecnológicas (Figura 1).

Figura 1: Pesquisas para "base dados" nestes três sites em 22/4/2017.

Uma das maiores dificuldades que as empresas, nacionais e internacionais, têm no recrutamento de talentos com formação e/ou experiência nesta área é precisamente a sua escassez. Isso tem provocado uma (pequena) inflação nos salários oferecidos aos profissionais ainda disponíveis.

Como tal, pode ser interessante o investimento pessoal em formação na área das bases de dados, quer seja numa óptica de desenho e construção da base de dados, como na vertente mais complexa relacionada com a administração dos sistemas de bases de dados.

Read More

Lista (enorme) com nomes | Oracle | PostgreSQL | MySQL

Neste link está uma folha de cálculo em Excel com 1 milhão de nomes em português que pode ser usada em múltiplas aplicações, entre elas para preencher tabelas de teste em sistemas de bases de dados relacionais. Na Figura 1 está um pequeno output desse ficheiro.

Figura 1: Exemplo da lista de nomes.

Read More

Geração de Dados | Oracle

Geração de Dados | Oracle

A geração de valores aleatórios em Oracle para valores numéricos e datas, por exemplo, e recorrendo ao utilitário DBMS_RANDOM é fácil e traduz-se em resultados que fazem sentido e que podem posteriormente ser utilizados em testes.

Já a geração de cadeias alfanuméricas recorrendo aquele utilitário resulta em valores sem utilização prática. Acresce ainda que muitas vezes os testes de performance a bases de dados têm que ser feitos utilizando tabelas interligadas entre si por chaves estrangeiras. Ora isso não fazível recorrendo a strings do tipo ‘wqT45dfreDSkutRR’.

Então a melhor forma de ultrapassar esta deficiência é utilizar tabelas de lookup em que inserimos listas com possíveis valores, por exemplo, para nomes de pessoas, ou denominação de localidades ou países.

Figura 1: A tabela Colaborador.

A Query 1 que nos vai servir de caso de estudo devolve três campos: “Número de Funcionário”, “Nome” e “Data de Entrada”, em que para o primeiro e último campo pode-se aplicar o pacote DBMS_RANDOM mas em que o “Nome” será gerado a partir da coluna “Nome” da tabela “Colaborador” (Figura 1).

Query 1: Geração de valores aleatórios

SELECT "Número de Funcionário", "Nome", "Data de Entrada"

  FROM (SELECT TRUNC(DBMS_RANDOM.VALUE (100, 1000)) "Número de Funcionário",

          SYSDATE + DBMS_RANDOM.VALUE (-365* 15, -1) "Data de Entrada"

        FROM lamy

      CONNECT BY LEVEL <= 100) tabela1

    LEFT OUTER JOIN (SELECT DISTINCT "Nome" FROM "Colaborador"

        ORDER BY DBMS_RANDOM.VALUE) tabela2 ON 1 = 1

ORDER BY DBMS_RANDOM.VALUE;

Conjunto resultado:

Figura 2: Resultado da geração de valores aleatórios para a coluna Nome.

Read More

Regras para o desenho de tabelas | Parte 3

Depois de vermos a importância das chaves primárias, na terceira parte das regras para o desenho de tabelas vamos ver como elas se relacionam entre si. É essa associação entre os dados armazenados em duas ou mais tabelas que dá forma a uma base de dados relacional. Um grupo de tabelas isoladas, como que ilhas - sem vista entre si - num vasto oceano, não passa de uma tulha de dados com pouco ou nenhum interesse para os processos de tomada de decisão.

Como se faz então essa associação entre tabelas?

Essa conexão faz-se através do que se designa como chave estrangeira, que consiste numa ou mais colunas de uma tabela que são provenientes de outra tabela, conhecida como tabela-pai ou tabela de origem. São essas colunas em comum que permitem relacionar os dados entre si. Uma chave estrangeira diz-se simples quando consiste numa única coluna, e composta quando é formada por duas ou mais colunas.

No esquema Cinema retratado na Figura 1 a tabela Actores do Filme tem duas chaves estrangeiras:

• a coluna Filme proveniente da tabela Filme e da coluna Título do Filme, em notação técnica seria Filme.Título do Filme, i.e., nome_da_tabela.nome_da_coluna;
• e a coluna Actor com origem na coluna Nome do Actor da tabela Actor.

Figura 1: Esquema Cinema.

Então a tabela Actores do Filme tem duas chaves estrangeiras (simples). Por sua vez o conjunto destas duas colunas constitui a chave primária da tabela, ou seja, são os valores simultâneos nas duas colunas os únicos que asseguram a regra da integridade da tabela. Caso se escolhesse, e.g., a coluna Filme como chave primária então haveria apenas a hipótese de cada actor durante toda a sua vida artística participar numa única película. Por outro lado, e considerando o último exemplo, sendo as chaves primárias das tabelas Actores do Filme e Filme as mesmas então isso implicaria que seriam uma e a mesma tabela.

Read More

Regras para o desenho de tabelas | Parte 2

É muito comum que, no momento de declarar a chave primária de uma tabela, não haja a mínima preocupação com a compreensão do seu contexto no âmbito do processo de negócio, e seja atribuída uma chave primária com valor abstracto e com o formato numérico. Veja-se o exemplo da tabela Género da Figura 1 em que se utiliza o campo GéneroID como chave primária e.g., o género "Comédia" tem o código "11". 

Figura 1: Tabela Género com uma chave primária abstracta "GéneroID".

Mas na realidade no sistema real não existe nenhuma classificação numérica para os géneros dos filmes. No mundo do cinema as comédias não têm um código "11". Em todas as situações em que num sistema não existam códigos identificadores verdadeiros/reais então o mesmo tem que acontecer nas bases de dados que os modelam. Assim, a tabela Género correctamente desenhada, terá apenas uma coluna a qual será obviamente igualmente chave primária (Figura 2).

Figura 2:  Tabela Género num formato normalizado.

Os sistemas não são todos iguais e há alguns em que existem conjuntos de entidades em que os seus elementos se diferenciam por códigos, ou seja, por valores numéricos ou alfa numéricos, que são reconhecidos por todos os participantes do sistema, Por exemplo, os alunos têm números, aos contribuintes são-lhes atribuídos números de identificação fiscal, ou cada viatura automóvel tem a sua própria matrícula.

Read More