Artigos Banco de Dados Trabalhando com domínios - Revista SQL Magazine 112
Artigo do tipo Exemplos Práticos
Trabalhando com domínios
Um modelo de dados define uma coleção de conceitos que podem ser usados para descrever a estrutura de um banco de dados. Muitos modelos de dados foram propostos e podemos classificá-los de acordo com os tipos de conceitos que eles utilizam para descrever a estrutura do banco de dados. Modelos de dados de alto nível oferecem conceitos que são mais próximos ao modo como muitos usuários percebem os dados. Já o modelo de dados de baixo nível oferece conceitos que descrevem os detalhes de como os dados são armazenados no computador (estes conceitos costumam ser voltados para profissionais envolvidos no desenvolvimento de soluções de software, não para usuários).

Não é difícil encontrar modelos de dados com problemas de códigos sem identificação, ou seja, parâmetros sem um significado relacionado para o entendimento de um determinado valor. Quando realizamos uma seleção de dados em uma base, queremos extrair uma informação coerente e que represente o que aquele registro significa realmente.

Nos momentos que somos surpreendidos por valores sem significados aparentes, precisamos de uma fonte de informação complementar para facilitar o entendimento da informação gerada. Nestes casos, para gerarmos uma informação coerente e confiável, podemos utilizar um dos dois mecanismos apropriados para resolver este problema: check constraint ou tabela de tipo, também chamada de domínio. Para cada uma das opções existe uma forma de aplicação e neste artigo você vai entender para que serve e em quais situações devemos utilizar, uma ou outra.

Assim, este artigo mostra como melhorar a qualidade de um modelo de dados mostrando como aplicar corretamente uma check constraint e uma tabela de tipo ou domínio.


Em que situação o tema é útil
Para que nenhum dado na base de dados não tenha seu valor definido, ou seja, representando seu significado real, é possível adotar entre uma das duas opções (check constraint ou tabela de tipo) dependendo do problema que esteja sendo modelado.

As dicas e técnicas descritas neste artigo irão agregar qualidade a qualquer modelo de dados relacional, diminuindo problemas com informações sem credibilidade por falta de entendimento dos dados armazenados na base de dados.

Os sistemas são repletos de parâmetros que têm como objetivo definir status de um determinado registro e, de alguma forma, o valor deste parâmetro deve ter um significado claro na base de dados. Um exemplo deste tipo de parâmetro é a definição do sexo de uma pessoa. Geralmente é usado ‘F’ para definir o sexo feminino e ‘M’ para o masculino. Neste tipo de parâmetro é fácil identificar um dado na base de dados, pois ele é auto explicativo, mas se um sistema usa ‘0’ para feminino e ‘1’ para masculino a interpretação não fica muito clara e, neste caso, deve estar documentado de alguma forma o significado das opções.

É claro que existem outros tipos de situações que envolvem parâmetros. Um exemplo simples é a classificação de estado civil de uma pessoa. Esta tem mais opções que a anterior, porém, ela é limitada, pois existe um número fixo de opções.

Mudando um pouco o foco do exemplo, mas ainda falando em parâmetros de sistemas, podemos encontrar tipos de ações em que uma determinada funcionalidade do sistema pode se encontrar. Imagine que seu sistema controle as cobranças bancárias de um escritório, sendo que existem cinco estágios, onde “1” é emitido, “2” é vencido, “3” é Cancelado , “4” Pago e “5” é Cobrança Indevida. Considere também que no dia 25 de cada mês o sistema tem uma stored procedure que gera todas as cobranças para o mês seguinte e, nesse momento, para cada uma delas é inserida uma linha na tabela de FATURAMENTO, contendo informações do tipo: data do vencimento, código do cliente, valor da fatura e status da fatura.

...
Quer ler esse conteúdo completo? Tenha acesso completo