Artigo SQL Magazine 38 - Desafio SQL Magazine

Clique aqui para ler esse artigo em PDF.

Clique aqui para ler todos os artigos desta edição

Desafio SQL Magazine

Comandos de definição de dados, controle de dados, criação de índices e controle de transações

Marco Antônio Pereira Araújo

Este é o oitavo e último artigo de uma série que apresentou um conjunto de desafios de modelagem de dados e linguagem SQL. Acabamos por fazer, mais que um conjunto de desafios, um mini-curso sobre estes assuntos. Desta forma, neste último artigo, além de apresentar a solução proposta no anterior, vamos complementar estes assuntos apresentando as sintaxes de comandos da DDL (Data Definition Language – Linguagem de Definição de Dados) utilizados nestes desafios, bem como as sintaxes de outros comandos importantes, envolvendo a DCL (Data Control Language – Linguagem de Controle de Dados), criação de índices e controle de transações.

Vamos discutir inicialmente a solução do desafio da edição anterior, que consistia na modificação do modelo de dados para incluir agregações e estruturas de generalização/especialização.

  O primeiro requisito deixado como desafio torna necessário fazer uma distinção entre tipos de obras, que agora podem ser Livros ou Periódicos. Para Livros, deve-se armazenar o número do ISBN (International Standard Book Number - Número Padrão Internacional de Livro), enquanto que para periódicos, deve-se armazenar o número do ISSN (International Standard Serial Number - Número Internacional Normalizado para Publicações Seriadas). Estes números não devem ficar armazenados na tabela Obra, uma vez que obras não possuem ambos os números simultaneamente e também não se deseja que fiquem nulos dependendo do tipo da obra.

  Problemas deste tipo podem ser resolvidos utilizando uma estrutura Generalização/Especialização, que representa situações onde determinadas entidades são tratadas como especializações de uma mais genérica, que agrupa o que é comum às entidades da hierarquia. Estruturas deste tipo podem ser mapeadas em uma única tabela, em uma tabela para cada especialização ou uma tabela para cada entidade envolvida, dependendo da situação. A Figura 1 apresenta estas situações de mapeamento para o problema em questão. Na situação 1, todos os atributos da hierarquia foram agrupados numa única tabela, fazendo com que atributos fiquem eventualmente vazios em função do tipo da obra. A situação 2 representa apenas as especializações, fazendo com que os atributos da generalização sejam repetidos. A situação 3 apresenta uma tabela para cada entidade da hierarquia, eliminando atributos repetidos, mas fazendo com que o acesso a uma obra tenha que agrupar dados de mais de uma tabela. Neste estudo de caso, será utilizada a situação 3, onde cada entidade é mapeada para uma tabela específica, não havendo redundância de dados ou atributos com valores nulos em função do tipo de obra em questão, atendendo assim ao requisito proposto.

Figura 1. Mapeamento de Estruturas Generalização/Especialização.

O próximo requisito trata da questão de compras de obras pela biblioteca. Periodicamente, a biblioteca faz compra de novas obras. Para isso, são abertas requisições onde são registradas as obras a serem adquiridas, bem como sua quantidade. Desta forma, uma obra pode estar em várias requisições e uma requisição pode possuir diversas obras. Requisições ainda possuem um número seqüencial que as identificam, uma data de abertura e um campo que indica o estado da requisição, podendo estar aberta ou fechada para inclusão de novas obras. Quando do momento da compra, cada obra da requisição pode ser adquirida de um fornecedor diferente, enquanto um fornecedor pode fornecer várias obras de diferentes requisições. Para isso, deve-se considerar uma nova entidade chamada Fornecedor, que possui código, razão social, e telefone de contato. Vale ressaltar ainda que fornecedores somente são definidos quando da compra de cada obra na requisição, associando então seu preço e data de compra.

Como uma obra pode ser alocada a uma requisição sem um fornecedor num primeiro momento, um relacionamento ternário não se mostraria adequado, uma vez que a tabela originada teria também o fornecedor como parte da chave primária, e este não poderia ficar nulo. Desta forma, esta situação pode ser resolvida com uma agregação, que normalmente origina uma nova tabela. A Figura 2 representa uma agregação para este problema.

Figura 2. Mapeamento de Agregação.

Percebe-se na tabela Item_Requisicao que o atributo cod_fornecedor é apenas uma chave estrangeira, não fazendo parte da chave primária. Isso irá permitir que ele possa ter o valor nulo enquanto uma obra de uma requisição não passar pelo processo de compra.

Desta forma, a Figura 3 apresenta o modelo conceitual após as modificações realizadas, enquanto a Figura 4 exibe o modelo lógico correspondente.

Figura 3. O modelo conceitual após as modificações.

Figura 4. O modelo lógico após as modificações.

As Tabelas 1 a 5 mostram as estruturas das tabelas que sofreram modificações em função dos novos requisitos. 

Tabela 1. Estrutura da tabela Livro.