Modelo de valor de atributo de entidade - Entity–attribute–value model

O modelo de valor de atributo de entidade ( EAV ) é um modelo de dados para codificar, de maneira eficiente em termos de espaço, entidades onde o número de atributos (propriedades, parâmetros) que podem ser usados ​​para descrevê-los é potencialmente vasto, mas o número que irá realmente aplicável a uma determinada entidade é relativamente modesto. Essas entidades correspondem à noção matemática de uma matriz esparsa .

O EAV também é conhecido como modelo de objeto-atributo-valor , modelo de banco de dados vertical e esquema aberto .

Estrutura de dados

Esta representação de dados é análoga a métodos eficientes de espaço de armazenamento de uma matriz esparsa , onde apenas valores não vazios são armazenados. Em um modelo de dados EAV, cada par de valor de atributo é um fato que descreve uma entidade, e uma linha em uma tabela EAV armazena um único fato. As tabelas EAV são frequentemente descritas como "longas e finas": "longas" refere-se ao número de linhas, "finas" às poucas colunas.

Os dados são registrados em três colunas:

  • A entidade : o item que está sendo descrito.
  • O atributo ou parâmetro : normalmente implementado como uma chave estrangeira em uma tabela de definições de atributos. A tabela de definições de atributos pode conter as seguintes colunas: um ID de atributo, nome de atributo, descrição, tipo de dados e colunas que auxiliam na validação de entrada, por exemplo, comprimento máximo de string e expressão regular, conjunto de valores permitidos, etc.
  • O valor do atributo.

Exemplo

Considere como alguém tentaria representar um registro clínico de uso geral em um banco de dados relacional. Claramente, criar uma tabela (ou um conjunto de tabelas) com milhares de colunas não é viável, porque a grande maioria das colunas seria nula . Para complicar as coisas, em um prontuário longitudinal que acompanha o paciente ao longo do tempo, podem haver vários valores do mesmo parâmetro: a altura e o peso de uma criança, por exemplo, mudam à medida que a criança cresce. Por fim, o universo dos achados clínicos não para de crescer: por exemplo, surgem doenças e novos exames laboratoriais são concebidos; isso exigiria adição constante de colunas e revisão constante da interface do usuário. (A situação em que a lista de atributos muda com frequência é chamada de "volatilidade de atributo" no jargão do banco de dados.)

O seguinte mostra um instantâneo de uma tabela EAV para descobertas clínicas de uma visita a um médico para febre na manhã de 05/01/98. As entradas mostradas entre colchetes angulares são referências a entradas em outras tabelas, mostradas aqui como texto em vez de valores de chave estrangeira codificados para facilitar a compreensão. Neste exemplo, os valores são todos valores literais, mas também podem ser listas de valores predefinidos. Os últimos são particularmente úteis quando os valores possíveis são conhecidos como limitados (ou seja, enumeráveis ).

  • A entidade . Para os achados clínicos, a entidade é o evento do paciente : uma chave estrangeira em uma tabela que contém no mínimo uma ID do paciente e um ou mais carimbos de data / hora (por exemplo, o início e o final da data / hora do exame) que registram quando o evento que está sendo descrito aconteceu.
  • O atributo ou parâmetro : uma chave estrangeira em uma tabela de definições de atributos (neste exemplo, definições de descobertas clínicas). No mínimo, a tabela de definições de atributo conteria as seguintes colunas: um ID de atributo, nome de atributo, descrição, tipo de dados , unidades de medida e colunas que auxiliam na validação de entrada, por exemplo, comprimento máximo de string e expressão regular, máximo e mínimo permitido valores, conjunto de valores permitidos, etc.
  • O valor do atributo. Isso dependeria do tipo de dados e discutiremos como os valores são armazenados em breve.

O exemplo abaixo ilustra os achados de sintomas que podem ser vistos em um paciente com pneumonia .

(<patient XYZ, 1/5/98 9:30 AM>,  <Temperature in degrees Fahrenheit>,  "102" )
(<patient XYZ, 1/5/98 9:30 AM>,  <Presence of Cough>,  "True" )
(<patient XYZ, 1/5/98 9:30 AM>,  <Type of Cough>,  "With phlegm, yellowish, streaks of blood" )
(<patient XYZ, 1/5/98 9:30 AM>,  <Heart Rate in beats per minute>,  "98" )
...

Os dados EAV descritos acima são comparáveis ​​ao conteúdo de um recibo de venda de supermercado (que seria refletido em uma tabela de itens de linha de vendas em um banco de dados). O recibo lista apenas os detalhes dos itens realmente comprados, em vez de listar todos os produtos da loja que o cliente pode ter comprado, mas não o fez. Como os achados clínicos de um determinado paciente, o recibo de venda é esparso.

  • A "entidade" é a id de venda / transação - uma chave estrangeira em uma tabela de transações de vendas. Isso é usado para marcar cada item de linha internamente, embora no recibo as informações sobre a venda apareçam na parte superior (localização da loja, data / hora da venda) e na parte inferior (valor total da venda).
  • O "atributo" é uma chave estrangeira em uma tabela de produtos, de onde se consulta a descrição, preço unitário, descontos e promoções, etc. (Os produtos são tão voláteis quanto as descobertas clínicas, possivelmente ainda mais: novos produtos são introduzidos a cada mês , enquanto outros são retirados do mercado se a aceitação do consumidor for baixa. Nenhum designer de banco de dados competente codificaria produtos individuais, como Doritos ou Diet Coke, como colunas em uma tabela.)
  • Os "valores" são a quantidade comprada e o preço total do item de linha.

A modelagem de linha , em que fatos sobre algo (neste caso, uma transação de vendas) são registrados como várias linhas em vez de várias colunas , é uma técnica de modelagem de dados padrão. As diferenças entre a modelagem de linha e EAV (que pode ser considerada uma generalização da modelagem de linha) são:

  • Uma tabela modelada por linha é homogênea nos fatos que descreve: uma tabela de itens de linha descreve apenas os produtos vendidos. Em contraste, uma tabela EAV contém quase qualquer tipo de fato.
  • O tipo de dados da (s) coluna (s) de valor em uma tabela modelada por linha é pré-determinado pela natureza dos fatos que registra. Por outro lado, em uma tabela EAV, o tipo de dados conceituais de um valor em uma linha específica depende do atributo nessa linha. Conclui-se que, em sistemas de produção, permitir a entrada direta de dados em uma tabela EAV seria uma receita para o desastre, porque o próprio mecanismo de banco de dados não seria capaz de realizar uma validação de entrada robusta. Veremos mais tarde como é possível construir frameworks genéricos que realizam a maioria das tarefas de validação de entrada, sem codificação infinita em uma base de atributo por atributo.

Em um repositório de dados clínicos, a modelagem de linha também encontra vários usos; o subesquema do teste de laboratório é normalmente modelado dessa maneira, porque os resultados dos testes de laboratório são normalmente numéricos ou podem ser codificados numericamente.

As circunstâncias em que você precisaria ir além da modelagem de linha padrão para EAV estão listadas abaixo:

  • O tipo de dados de atributos individuais varia (conforme visto com os achados clínicos).
  • As categorias de dados são numerosas, crescentes ou flutuantes, mas o número de instâncias (registros / linhas) dentro de cada categoria é muito pequeno. Aqui, com a modelagem convencional, o diagrama entidade-relacionamento do banco de dados pode ter centenas de tabelas: as tabelas que contêm milhares / milhões de linhas / instâncias são enfatizadas visualmente da mesma forma que aquelas com muito poucas linhas. Os últimos são candidatos à conversão para uma representação EAV.

Essa situação surge em ambientes de modelagem de ontologia , onde as categorias ("classes") geralmente devem ser criadas na hora, e algumas classes são frequentemente eliminadas em ciclos subsequentes de prototipagem.

Certas classes ("híbridas") têm alguns atributos que não são esparsos (presentes em todas ou na maioria das instâncias), enquanto outros atributos são altamente variáveis ​​e esparsos. Os últimos são adequados para modelagem EAV. Por exemplo, as descrições de produtos feitos por uma empresa de conglomerado dependem da categoria do produto, por exemplo, os atributos necessários para descrever uma marca de lâmpada são bastante diferentes daqueles exigidos para descrever um dispositivo de imagem médica, mas ambos têm atributos comuns, como embalagem custo unitário e por item.

Descrição dos conceitos

A entidade

Em dados clínicos, a entidade é tipicamente um evento clínico, conforme descrito acima. Em configurações de uso mais geral, a entidade é uma chave estrangeira em uma tabela de "objetos" que registra informações comuns sobre cada "objeto" (coisa) no banco de dados - no mínimo, um nome preferido e uma breve descrição, bem como o categoria / classe de entidade a que pertence. Cada registro (objeto) nesta tabela é atribuído a um ID de objeto gerado por máquina.

A abordagem da "tabela de objetos" foi iniciada por Tom Slezak e colegas do Lawrence Livermore Laboratories para o banco de dados Chromosome 19 e agora é padrão na maioria dos grandes bancos de dados de bioinformática. O uso de uma tabela de objetos não exige o uso simultâneo de um projeto EAV: as tabelas convencionais podem ser usadas para armazenar os detalhes específicos da categoria de cada objeto.

O principal benefício de uma tabela de objetos central é que, por ter uma tabela de suporte de sinônimos de objetos e palavras-chave, pode-se fornecer um mecanismo de pesquisa padrão do Google em todo o sistema, onde o usuário pode encontrar informações sobre qualquer objeto de interesse sem precisar primeiro especifique a categoria a que pertence. (Isso é importante em sistemas de biociência, onde uma palavra-chave como "acetilcolina" pode se referir à própria molécula, que é um neurotransmissor, ou ao receptor biológico ao qual se liga.

O atributo

Na própria tabela EAV, este é apenas um ID de atributo, uma chave estrangeira em uma tabela de Definições de Atributo, conforme declarado acima. No entanto, geralmente há várias tabelas de metadados que contêm informações relacionadas a atributos, e essas são discutidas em breve.

O valor que

Coagir todos os valores em strings, como no exemplo de dados EAV acima, resulta em uma estrutura simples, mas não escalonável: interconversões de tipo de dados constantes são necessárias se alguém quiser fazer algo com os valores e um índice sobre o valor coluna de uma tabela EAV é essencialmente inútil. Além disso, não é conveniente armazenar grandes dados binários, como imagens, no formato codificado em Base64 na mesma tabela que pequenos inteiros ou strings. Portanto, sistemas maiores usam tabelas EAV separadas para cada tipo de dados (incluindo objetos binários grandes , "BLOBS"), com os metadados para um determinado atributo identificando a tabela EAV na qual seus dados serão armazenados. Na verdade, essa abordagem é bastante eficiente porque a quantidade modesta de metadados de atributo para uma determinada classe ou forma que um usuário escolhe para trabalhar pode ser armazenada em cache prontamente na memória. No entanto, é necessário mover os dados de uma tabela para outra se o tipo de dados de um atributo for alterado.

História

O EAV, como meio de representação do conhecimento de uso geral , originou-se do conceito de " listas de associação " ( pares atributo-valor ). Comumente usados ​​hoje, eles foram introduzidos pela primeira vez na linguagem LISP . Os pares de atributo-valor são amplamente usados ​​para diversos aplicativos, como arquivos de configuração (usando uma sintaxe simples como atributo = valor ). Um exemplo de uso do EAV sem banco de dados é o UIMA (Unstructured Information Management Architecture), um padrão agora gerenciado pela Apache Foundation e empregado em áreas como processamento de linguagem natural . O software que analisa o texto normalmente marca ("anota") um segmento: o exemplo fornecido no tutorial UIMA é um programa que executa o reconhecimento de entidade nomeada (NER) em um documento, anotando o segmento de texto "Presidente Bush" com a anotação- triplo de valor de atributo (Pessoa, Full_Name, "George W. Bush") . Essas anotações podem ser armazenadas em uma tabela de banco de dados.

Embora o EAV não tenha uma conexão direta com pares de AV, Stead e Hammond parecem ser os primeiros a conceber seu uso para armazenamento persistente de dados arbitrariamente complexos. Os primeiros sistemas de registros médicos a empregar EAV foram o registro médico eletrônico Regenstrief (esforço liderado por Clement MacDonald), o sistema TMR (The Medical Record) de William Stead e Ed Hammond e o HELP Clinical Data Repository (CDR) criado pelo grupo de Homer Warner em Hospital SUD, Salt Lake City, Utah. (O sistema Regenstrief, na verdade, usava um design de valor de carimbo de data e hora do paciente: o uso do carimbo de data e hora apoiava a recuperação de valores para um determinado paciente / atributo em ordem cronológica.) Todos esses sistemas, desenvolvidos na década de 1970, foram lançados antes dos sistemas comerciais baseado em EF Codd 's banco de dados relacional modelo estavam disponíveis, embora ajuda foi muito mais tarde portado para uma arquitetura relacional e comercializado pela empresa 3M. (Observe que, embora o artigo de referência de Codd tenha sido publicado em 1970, seu tom altamente matemático teve o infeliz efeito de diminuir sua acessibilidade entre os tipos que não são da ciência da computação e, consequentemente, atrasar a aceitação do modelo nos círculos de fornecedores de software e TI. O valor do subsequente A contribuição de Christopher J. Date , colega de Codd na IBM, ao traduzir essas ideias em uma linguagem acessível, acompanhada de exemplos simples que ilustram seu poder, não pode ser subestimada.)

Um grupo do Columbia-Presbyterian Medical Center foi o primeiro a usar um mecanismo de banco de dados relacional como base de um sistema EAV.

O sistema de gerenciamento de dados de estudos clínicos TrialDB de código aberto de Nadkarni et al. foi o primeiro a usar várias tabelas EAV, uma para cada tipo de dados DBMS .

A estrutura EAV / CR, projetada principalmente por Luis Marenco e Prakash Nadkarni, sobrepôs os princípios da orientação a objetos no EAV; ele se baseou na abordagem de tabela de objetos de Tom Slezak (descrita anteriormente na seção "Entidade"). SenseLab , um banco de dados de neurociência acessível ao público, é construído com a estrutura EAV / CR.

Use em bancos de dados

O termo "banco de dados EAV" refere-se a um projeto de banco de dados em que uma proporção significativa dos dados é modelada como EAV. No entanto, mesmo em um banco de dados descrito como "baseado em EAV", algumas tabelas do sistema são tabelas relacionais tradicionais.

Conforme observado acima, a modelagem EAV faz sentido para categorias de dados, como achados clínicos, onde os atributos são numerosos e esparsos. Onde essas condições não se mantêm, a modelagem relacional padrão (ou seja, uma coluna por atributo) é preferível; usar o EAV não significa abandonar o bom senso ou os princípios do bom design relacional. Em sistemas de registros clínicos, os subesquemas que lidam com dados demográficos e faturamento dos pacientes são normalmente modelados de maneira convencional. (Embora a maioria dos esquemas de banco de dados do fornecedor sejam proprietários, VistA , o sistema usado em todo o sistema médico do Departamento de Assuntos de Veteranos dos Estados Unidos (VA), conhecido como Veterans Health Administration (VHA), é de código aberto e seu esquema pode ser facilmente inspecionado, embora ele usa um mecanismo de banco de dados MUMPS em vez de um banco de dados relacional.)

Conforme discutido em breve, um banco de dados EAV é essencialmente impossível de manter sem várias tabelas de suporte que contêm metadados de suporte . As tabelas de metadados, que normalmente superam as tabelas EAV por um fator de pelo menos três ou mais, são tipicamente tabelas relacionais padrão. Um exemplo de tabela de metadados é a tabela Definições de Atributos mencionada acima.

EAV / CR: representando subestrutura com classes e relacionamentos

Em um projeto EAV simples, os valores de um atributo são tipos de dados simples ou primitivos no que diz respeito ao mecanismo de banco de dados. No entanto, em sistemas EAV usados ​​para representação de dados altamente diversos, é possível que um determinado objeto (instância de classe) possa ter subestrutura: ou seja, alguns de seus atributos podem representar outros tipos de objetos, que por sua vez, podem ter subestrutura, para um nível arbitrário de complexidade. Um carro, por exemplo, tem um motor, uma transmissão, etc., e o motor tem componentes como cilindros. (A subestrutura permitida para uma determinada classe é definida dentro dos metadados de atributos do sistema, como discutido mais tarde. Assim, por exemplo, o atributo "random-access-memory" poderia se aplicar à classe "computer", mas não à classe "engine" .)

Para representar a subestrutura, incorpora-se uma tabela EAV especial onde a coluna de valor contém referências a outras entidades no sistema (ou seja, valores de chave estrangeira na tabela de objetos). Para obter todas as informações sobre um determinado objeto, é necessária uma travessia recursiva dos metadados, seguida por uma travessia recursiva dos dados que para quando cada atributo recuperado é simples (atômico). A travessia recursiva é necessária se os detalhes de uma classe individual são representados na forma convencional ou EAV; essa travessia é realizada em sistemas objeto-relacionais padrão, por exemplo. Na prática, o número de níveis de recursão tende a ser relativamente modesto para a maioria das classes, portanto, as penalidades de desempenho devido à recursão são modestas, especialmente com indexação de IDs de objeto.

EAV / CR (EAV com classes e relacionamentos) refere-se a uma estrutura que suporta subestruturas complexas. Seu nome é um tanto impróprio: embora tenha sido um outshoot do trabalho em sistemas EAV, na prática, muitas ou mesmo a maioria das classes em tal sistema podem ser representadas na forma relacional padrão, com base no fato de os atributos serem esparsos ou densos . EAV / CR é realmente caracterizado por seus metadados muito detalhados, que são ricos o suficiente para suportar a geração automática de interfaces de navegação para classes individuais sem ter que escrever código de interface de usuário classe por classe. A base de tais interfaces de navegador é que é possível gerar um lote de consultas SQL dinâmicas que são independentes da classe do objeto, primeiro consultando seus metadados e usando informações de metadados para gerar uma sequência de consultas nas tabelas de dados, e algumas dessas consultas podem ser arbitrariamente recursivas. Essa abordagem funciona bem para consultas de objeto por vez, como em interfaces de navegação baseadas na Web, onde clicar no nome de um objeto traz todos os detalhes do objeto em uma página separada: os metadados associados à classe desse objeto também facilitam apresentação dos detalhes do objeto, pois inclui legendas de atributos individuais, a ordem em que devem ser apresentados e como devem ser agrupados.

Uma abordagem para EAV / CR é permitir que as colunas contenham estruturas JSON , que assim fornecem a estrutura de classe necessária. Por exemplo, o PostgreSQL , a partir da versão 9.4, oferece suporte a coluna binária JSON (JSONB), permitindo que atributos JSON sejam consultados, indexados e unidos.

Metadados

Nas palavras do Prof. Dr. Daniel Masys (ex-Presidente do Departamento de Informática Médica da Vanderbilt University), os desafios de trabalhar com EAV derivam do fato de que em um banco de dados EAV, o "esquema físico" (a forma como os dados são armazenados) é radicalmente diferente do "esquema lógico" - a maneira como os usuários e muitos aplicativos de software, como pacotes de estatísticas, o consideram, isto é, como linhas e colunas convencionais para classes individuais. (Como uma tabela EAV mistura conceitualmente maçãs, laranjas, toranjas e chop suey, se você quiser fazer qualquer análise dos dados usando um software de prateleira padrão, na maioria dos casos você tem que converter subconjuntos para a forma colunar. processo de fazer isso, chamado de pivô , é importante o suficiente para ser discutido separadamente.)

Os metadados ajudam a realizar a prestidigitação que permite aos usuários interagir com o sistema em termos de esquema lógico em vez de físico: o software consulta continuamente os metadados para várias operações, como apresentação de dados, validação interativa, extração de dados em massa e consulta ad hoc . Os metadados podem realmente ser usados ​​para personalizar o comportamento do sistema.

Os sistemas EAV trocam a simplicidade na estrutura física e lógica dos dados pela complexidade em seus metadados, que, entre outras coisas, desempenha o papel que as restrições de banco de dados e integridade referencial desempenham em designs de banco de dados padrão. Essa compensação geralmente vale a pena, porque no esquema misto típico de sistemas de produção, os dados em tabelas relacionais convencionais também podem se beneficiar de funcionalidades como a geração automática de interface. A estrutura dos metadados é complexa o suficiente para incluir seu próprio subesquema no banco de dados: várias chaves estrangeiras nas tabelas de dados referem-se a tabelas dentro desse subesquema. Este subesquema é relacional padrão, com recursos como restrições e integridade referencial sendo usados ​​ao máximo.

A correção dos conteúdos de metadados, em termos do comportamento pretendido do sistema, é crítica e a tarefa de garantir a correção significa que, ao criar um sistema EAV, esforços consideráveis ​​de design devem ser feitos para construir interfaces de usuário para edição de metadados que podem ser usados ​​por pessoas na equipe que conhece o domínio do problema (por exemplo, medicina clínica), mas não são necessariamente programadores. (Historicamente, uma das principais razões pelas quais o sistema TMR pré-relacional não foi adotado em sites diferentes de sua instituição de origem era que todos os metadados eram armazenados em um único arquivo com uma estrutura não intuitiva. Personalização do comportamento do sistema alterando o conteúdo deste arquivo, sem causar a quebra do sistema, era uma tarefa tão delicada que os autores do sistema apenas confiaram em si mesmos para fazê-lo.)

Quando um sistema EAV é implementado por meio de RDF , a linguagem RDF Schema pode ser convenientemente usada para expressar tais metadados. Essas informações de esquema podem então ser usadas pelo mecanismo de banco de dados EAV para reorganizar dinamicamente sua estrutura de tabela interna para melhor eficiência.

Algumas advertências finais sobre metadados:

  • Como a lógica de negócios está nos metadados em vez de explícita no esquema do banco de dados (ou seja, um nível removido, em comparação com os sistemas projetados tradicionalmente), é menos aparente para quem não está familiarizado com o sistema. Ferramentas de navegação e relatório de metadados são, portanto, importantes para garantir a manutenção de um sistema EAV. No cenário comum em que os metadados são implementados como um subesquema relacional, essas ferramentas nada mais são do que aplicativos criados usando relatórios prontos para uso ou ferramentas de consulta que operam nas tabelas de metadados.
  • É fácil para um usuário com conhecimento insuficiente corromper (ou seja, introduzir inconsistências e erros em) metadados. Portanto, o acesso aos metadados deve ser restrito e uma trilha de auditoria de acessos e mudanças deve ser implementada para lidar com situações em que vários indivíduos têm acesso aos metadados. Usar um RDBMS para metadados simplificará o processo de manutenção da consistência durante a criação e edição de metadados, aproveitando os recursos do RDBMS, como suporte para transações. Além disso, se os metadados fizerem parte do mesmo banco de dados que os próprios dados, isso garante que o backup será feito pelo menos com a mesma frequência que os próprios dados, para que possam ser recuperados até um determinado momento.
  • A qualidade da anotação e da documentação dentro dos metadados (ou seja, o texto narrativo / explicativo nas colunas descritivas do subesquema de metadados) deve ser muito maior, a fim de facilitar a compreensão por vários membros da equipe de desenvolvimento. Garantir a qualidade dos metadados (e mantê-los atualizados conforme o sistema evolui) tem alta prioridade no gerenciamento e manutenção de longo prazo de qualquer projeto que use um componente EAV. Metadados mal documentados ou desatualizados podem comprometer a viabilidade do sistema a longo prazo.

Informações capturadas em metadados

Metadados de atributos

  • Os metadados de validação incluem tipo de dados, intervalo de valores permitidos ou associação em um conjunto de valores, correspondência de expressão regular, valor padrão e se o valor pode ser nulo. Em sistemas EAV que representam classes com subestrutura, os metadados de validação também registrarão a qual classe, se houver, um determinado atributo pertence.
  • Metadados de apresentação : como o atributo deve ser exibido para o usuário (por exemplo, como uma caixa de texto ou imagem de dimensões especificadas, uma lista suspensa ou um conjunto de botões de rádio). Quando um objeto composto é composto por vários atributos, como no projeto EAV / CR, há metadados adicionais sobre a ordem em que os atributos devem ser apresentados e como esses atributos devem ser agrupados opcionalmente (sob títulos descritivos).
  • Para atributos que são parâmetros laboratoriais, intervalos de valores normais , que podem variar por idade, sexo, estado fisiológico e método de ensaio, são registrados.
  • Metadados de agrupamento : os atributos são normalmente apresentados como parte de um grupo de ordem superior, por exemplo, um formulário específico de especialidade. Os metadados de agrupamento incluem informações como a ordem em que os atributos são apresentados. Certos metadados de apresentação, como fontes / cores e o número de atributos exibidos por linha, se aplicam ao grupo como um todo.

Metadados de validação avançada

  • Metadados de dependência : em muitas interfaces de usuário, a entrada de valores específicos em certos campos / atributos é necessária para desativar / ocultar determinados outros campos ou ativar / mostrar outros campos. (Por exemplo, se um usuário escolher a resposta "Não" para uma pergunta booleana "O paciente tem diabetes?", As perguntas subsequentes sobre a duração do diabetes, medicamentos para diabetes etc. devem ser desativadas.) uma estrutura genérica envolve o armazenamento de dependências entre os atributos de controle e os atributos controlados.
  • Cálculos e validação complexa : Como em uma planilha, o valor de certos atributos pode ser calculado e exibido, com base em valores inseridos em campos que são apresentados anteriormente na sequência. (Por exemplo, a área da superfície corporal é uma função da altura e largura). Da mesma forma, pode haver "restrições" que devem ser verdadeiras para que os dados sejam válidos: por exemplo, em uma contagem diferencial de leucócitos, a soma das contagens dos tipos de leucócitos individuais deve ser sempre igual a 100, porque as contagens individuais representam percentagens. As fórmulas computadas e a validação complexa geralmente são efetuadas armazenando expressões nos metadados que são substituídas por macro com os valores que o usuário insere e podem ser avaliados. Em navegadores da Web, JavaScript e VBScript têm uma função Eval () que pode ser aproveitada para esse propósito.

A validação, apresentação e agrupamento de metadados possibilitam a criação de estruturas de código que suportam a geração automática de interface de usuário para navegação de dados e edição interativa. Em um sistema de produção que é entregue pela Web, a tarefa de validação de dados EAV é essencialmente movida da camada de back-end / banco de dados (que é impotente em relação a esta tarefa) para a camada do servidor intermediário / Web. Embora a validação de back-end seja sempre ideal, porque é impossível subverter tentando a entrada direta de dados em uma tabela, a validação de camada intermediária por meio de uma estrutura genérica é bastante viável, embora uma quantidade significativa de esforço de design de software deva ir para a construção da estrutura primeiro . A disponibilidade de estruturas de código aberto que podem ser estudadas e modificadas para necessidades individuais pode ajudar muito a evitar a reinvenção da roda.

Cenários de uso

(A primeira parte desta secção é um resumo do artigo de referência Dinu / Nadkarni na Central, para o qual o leitor é encaminhado para mais detalhes.)

A modelagem EAV, sob os termos alternativos " modelagem de dados genérica " ou "esquema aberto", há muito tempo é uma ferramenta padrão para modeladores de dados avançados. Como qualquer técnica avançada, pode ter dois gumes e deve ser usada com cautela.

Além disso, o emprego de EAV não impede o emprego de abordagens tradicionais de modelagem de banco de dados relacional dentro do mesmo esquema de banco de dados. Em EMRs que dependem de um RDBMS, como o Cerner , que usa uma abordagem EAV para seu subesquema de dados clínicos, a grande maioria das tabelas no esquema é, na verdade, modelada tradicionalmente, com atributos representados como colunas individuais em vez de linhas.

A modelagem do subesquema de metadados de um sistema EAV, na verdade, é um ajuste muito bom para a modelagem tradicional, por causa das inter-relações entre os vários componentes dos metadados. No sistema TrialDB, por exemplo, o número de tabelas de metadados no esquema supera as tabelas de dados em cerca de dez para um. Como a exatidão e a consistência dos metadados são essenciais para a operação correta de um sistema EAV, o designer do sistema deseja aproveitar todas as vantagens de todos os recursos que os RDBMSs fornecem, como integridade referencial e restrições programáveis, em vez de ter que reinventar o RDBMS - roda do motor. Consequentemente, as numerosas tabelas de metadados que suportam projetos EAV estão normalmente na forma relacional do terceiro normal.

Os sistemas de registros eletrônicos de saúde (EHRs) comerciais usam modelagem de linha para classes de dados, como diagnósticos, procedimentos cirúrgicos realizados e resultados de testes laboratoriais, que são segregados em tabelas separadas. Em cada tabela, a "entidade" é um composto da ID do paciente e a data / hora em que o diagnóstico foi feito (ou a cirurgia ou teste de laboratório realizado); o atributo é uma chave estrangeira em uma tabela de pesquisa especialmente designada que contém um vocabulário controlado - por exemplo, CID-10 para diagnósticos, Terminologia processual atual para procedimentos cirúrgicos, com um conjunto de atributos de valor. (Por exemplo, para resultados de testes de laboratório, pode-se registrar o valor medido, se está na faixa normal, baixa ou alta, a identificação da pessoa responsável por realizar o teste, a data / hora em que o teste foi realizado, e assim on.) Como afirmado anteriormente, esta não é uma abordagem de EAV completa porque o domínio dos atributos para uma determinada tabela é restrito, assim como o domínio dos IDs do produto na tabela de vendas de um supermercado seria restrito ao domínio dos produtos em um Tabela de produtos.

No entanto, para capturar dados sobre parâmetros que nem sempre são definidos em vocabulários padrão, os EHRs também fornecem um mecanismo EAV "puro", onde usuários avançados especialmente designados podem definir novos atributos, seu tipo de dados, valores máximos e mínimos permitidos (ou conjunto permissível de valores / códigos) e, em seguida, permitir que outros capturem dados com base nesses atributos. No Epic (TM) EHR, este mecanismo é denominado "Flowsheets" e é comumente usado para capturar dados de observação de enfermagem de pacientes internados.

Atributos esparsos de modelagem

O caso típico de uso do modelo EAV é para atributos altamente esparsos e heterogêneos, como parâmetros clínicos no prontuário eletrônico (EMRs), conforme declarado acima. Mesmo aqui, no entanto, é preciso afirmar que o princípio de modelagem EAV é aplicado a um subesquema do banco de dados, e não a todo o seu conteúdo. (Os dados demográficos dos pacientes, por exemplo, são mais naturalmente modelados em uma estrutura relacional tradicional de uma coluna por atributo.)

Consequentemente, os argumentos sobre EAV vs. design "relacional" refletem um entendimento incompleto do problema: Um design EAV deve ser empregado apenas para aquele subesquema de um banco de dados onde atributos esparsos precisam ser modelados: mesmo aqui, eles precisam ser suportados pela terceira forma normal de tabelas de metadados. Existem relativamente poucos problemas de projeto de banco de dados onde atributos esparsos são encontrados: é por isso que as circunstâncias em que o projeto EAV é aplicável são relativamente raras. Mesmo onde eles são encontrados, um conjunto de tabelas EAV não é a única maneira de lidar com dados esparsos: uma solução baseada em XML (discutida abaixo) é aplicável quando o número máximo de atributos por entidade é relativamente modesto e o volume total de esparsos os dados também são modestos. Um exemplo dessa situação são os problemas de captura de atributos de variáveis ​​para diferentes tipos de produtos.

Atributos esparsos também podem ocorrer em situações de comércio eletrônico em que uma organização está comprando ou vendendo um conjunto vasto e altamente diversificado de commodities, com os detalhes de categorias individuais de commodities sendo altamente variáveis. O software de comércio eletrônico Magento emprega uma abordagem EAV para resolver esse problema.

Modelando várias classes com muito poucas instâncias por classe: esquemas altamente dinâmicos

Outra aplicação do EAV é na modelagem de classes e atributos que, embora não sejam esparsos, são dinâmicos, mas onde o número de linhas de dados por classe será relativamente modesto - algumas centenas de linhas no máximo, mas normalmente algumas dezenas - e o sistema O desenvolvedor também deve fornecer uma interface de usuário final baseada na Web em um tempo de resposta muito curto. "Dinâmico" significa que novas classes e atributos precisam ser continuamente definidos e alterados para representar um modelo de dados em evolução. Este cenário pode ocorrer em campos científicos em rápida evolução, bem como no desenvolvimento de ontologias, especialmente durante as fases de prototipagem e refinamento iterativo.

Embora a criação de novas tabelas e colunas para representar uma nova categoria de dados não seja especialmente trabalhosa, a programação de interfaces baseadas na Web que suportam navegação ou edição básica com validação baseada em tipo e intervalo sim. Nesse caso, uma solução de longo prazo mais sustentável é criar uma estrutura onde as definições de classe e atributo são armazenadas em metadados, e o software gera uma interface de usuário básica a partir desses metadados dinamicamente.

A estrutura EAV / CR, mencionada anteriormente, foi criada para lidar com essa situação. Observe que um modelo de dados EAV não é essencial aqui, mas o designer do sistema pode considerá-lo uma alternativa aceitável à criação, digamos, de sessenta ou mais tabelas contendo um total de não mais do que duas mil linhas. Aqui, como o número de linhas por classe é tão pequeno, as considerações de eficiência são menos importantes; com a indexação padrão por ID de classe / ID de atributo, os otimizadores de DBMS podem armazenar em cache facilmente os dados de uma pequena classe na memória ao executar uma consulta envolvendo essa classe ou atributo.

No cenário de atributos dinâmicos, é importante notar que Resource Description Framework (RDF) está sendo empregado como a base do trabalho de ontologia relacionada à Web Semântica. RDF, que pretende ser um método geral de representação de informações, é uma forma de EAV: um triplo RDF compreende um objeto, uma propriedade e um valor.

No final do livro de Jon Bentley "Escrever programas eficientes", o autor adverte que tornar o código mais eficiente em geral também torna mais difícil de entender e manter, e por isso não se apressar e código de emenda a menos que se determinou pela primeira vez que não é um problema de desempenho e medidas como criação de perfil de código identificaram a localização exata do gargalo. Depois de fazer isso, você modifica apenas o código específico que precisa ser executado com mais rapidez. Considerações semelhantes se aplicam à modelagem de EAV: você a aplica apenas ao subsistema onde a modelagem relacional tradicional é conhecida a priori como difícil de manejar (como no domínio de dados clínicos) ou é descoberta, durante a evolução do sistema, para representar desafios de manutenção significativos. O Guru do banco de dados (e atualmente vice-presidente de Core Technologies da Oracle Corporation) Tom Kyte, por exemplo, aponta corretamente as desvantagens de empregar EAV em cenários de negócios tradicionais e afirma que a mera "flexibilidade" não é um critério suficiente para empregar EAV. (No entanto, ele faz a afirmação abrangente de que o EAV deve ser evitado em todas as circunstâncias, embora a própria divisão de Ciências da Saúde da Oracle empregue o EAV para modelar atributos de dados clínicos em seus sistemas comerciais ClinTrial e Oracle Clinical.)

Trabalho com dados EAV

O calcanhar de Aquiles do EAV é a dificuldade de trabalhar com grandes volumes de dados do EAV. Freqüentemente, é necessário realizar a conversão temporária ou permanente entre representações colunares e representações modeladas por linha ou EAV dos mesmos dados; isso pode estar sujeito a erros se feito manualmente, bem como com uso intensivo da CPU. Estruturas genéricas que utilizam atributos e metadados de agrupamento de atributos tratam da primeira, mas não da última limitação; seu uso é mais ou menos obrigatório no caso de esquemas mistos que contêm uma mistura de dados convencionais-relacionais e EAV, onde o quociente de erro pode ser muito significativo.

A operação de conversão é chamada de pivotamento . A dinâmica não é necessária apenas para dados EAV, mas também para qualquer formulário ou dados modelados por linha. (Por exemplo, as implementações do algoritmo Apriori para Análise de Associação, amplamente usado para processar dados de vendas de supermercados para identificar outros produtos que os compradores de um determinado produto também podem comprar, dinamizam dados modelados por linha como uma primeira etapa.) Muitos mecanismos de banco de dados possuem extensões SQL proprietárias para facilitar o pivotamento e pacotes como o Microsoft Excel também o suportam. As circunstâncias em que o pivô é necessário são consideradas a seguir.

  • Navegação de quantidades modestas de dados para uma entidade individual, opcionalmente seguida pela edição de dados com base nas dependências entre atributos. Essa operação é facilitada pelo armazenamento em cache de pequenas quantidades dos metadados de suporte necessários. Alguns programas, como o TrialDB, acessam os metadados para gerar páginas da Web semi-estáticas que contêm código de programação embutido, bem como estruturas de dados contendo metadados.
  • A extração em massa transforma grandes (mas previsíveis) quantidades de dados (por exemplo, dados completos de um estudo clínico) em um conjunto de tabelas relacionais. Embora exija muito da CPU, essa tarefa não é frequente e não precisa ser executada em tempo real; ou seja, o usuário pode esperar a conclusão de um processo em lote. A importância da extração em massa não pode ser superestimada, especialmente quando os dados devem ser processados ​​ou analisados ​​com ferramentas padrão de terceiros que desconhecem completamente a estrutura do EAV. Aqui, não é aconselhável tentar reinventar conjuntos inteiros de rodas por meio de uma estrutura genérica, e é melhor apenas extrair em massa os dados do EAV em tabelas relacionais e depois trabalhar com eles usando ferramentas padrão.
  • Interfaces de consulta ad hoc para dados modelados por linha ou EAV, quando consultados da perspectiva de atributos individuais, (por exemplo, "recuperar todos os pacientes com presença de doença hepática, com sinais de insuficiência hepática e sem histórico de abuso de álcool") deve normalmente mostram os resultados da consulta com atributos individuais como colunas separadas. Para a maioria dos cenários de banco de dados EAV, o desempenho da consulta ad hoc deve ser tolerável, mas as respostas abaixo de um segundo não são necessárias, uma vez que as consultas tendem a ser de natureza exploratória.

Divisão relacional

No entanto, a estrutura do modelo de dados EAV é uma candidata perfeita para Divisão Relacional, consulte álgebra relacional . Com uma boa estratégia de indexação, é possível obter um tempo de resposta em menos de algumas centenas de milissegundos em uma tabela EAV de bilhões de linhas. O MVP do Microsoft SQL Server, Peter Larsson, provou isso em um laptop e disponibilizou a solução geral.

Otimizando o desempenho de giro

  • Uma otimização possível é o uso de um " warehouse " separado ou esquema consultável cujo conteúdo é atualizado em modo de lote a partir do esquema de produção (transação). Consulte armazenamento de dados . As tabelas no warehouse são fortemente indexadas e otimizadas usando desnormalização , que combina várias tabelas em uma para minimizar a penalidade de desempenho devido às junções de tabela.
  • Certos dados de EAV em um warehouse podem ser convertidos em tabelas padrão usando " visualizações materializadas " (consulte data warehouse ), mas este é geralmente um último recurso que deve ser usado com cuidado, porque o número de visualizações deste tipo tende a crescer de forma não linear com o número de atributos em um sistema.
  • Estruturas de dados na memória : pode-se usar tabelas hash e matrizes bidimensionais na memória em conjunto com metadados de agrupamento de atributos para dados dinâmicos, um grupo de cada vez. Esses dados são gravados no disco como um arquivo delimitado simples, com os nomes internos de cada atributo na primeira linha: esse formato pode ser prontamente importado em massa para uma tabela relacional. Essa técnica "na memória" supera significativamente as abordagens alternativas, mantendo as consultas nas tabelas EAV o mais simples possível e minimizando o número de operações de E / S. Cada instrução recupera uma grande quantidade de dados e as tabelas de hash ajudam a realizar a operação de pivô, que envolve colocar um valor para uma determinada instância de atributo na linha e coluna apropriadas. A memória de acesso aleatório (RAM) é suficientemente abundante e acessível em hardware moderno que o conjunto de dados completo para um único grupo de atributos, mesmo em grandes conjuntos de dados, geralmente caberá completamente na memória, embora o algoritmo possa ser feito mais inteligente trabalhando em fatias dos dados se não for esse o caso.

Obviamente, não importa quais abordagens você adote, consultar EAV não será tão rápido quanto consultar dados relacionais modelados em coluna padrão para certos tipos de consulta, da mesma forma que o acesso de elementos em matrizes esparsas não é tão rápido quanto aqueles em não - matrizes esparsas se as últimas caberem inteiramente na memória principal. (Matrizes esparsas, representadas usando estruturas como listas vinculadas, requerem travessia de lista para acessar um elemento em uma determinada posição XY, enquanto o acesso a elementos em matrizes representadas como matrizes 2-D pode ser realizado usando operações rápidas de registro de CPU.) Se, no entanto , você escolheu a abordagem EAV corretamente para o problema que estava tentando resolver, esse é o preço que você paga; a esse respeito, a modelagem EAV é um exemplo de uma troca de espaço (e manutenção de esquema) versus tempo de CPU.

Alternativas

EAV versus o modelo de dados universal

Postulado originalmente por Maier, Ullman e Vardi, o "Universal Data Model" (UDM) visa simplificar a consulta de um esquema relacional complexo por usuários ingênuos, criando a ilusão de que tudo está armazenado em uma única "mesa universal" gigante. Ele faz isso utilizando relacionamentos entre tabelas, de forma que o usuário não precise se preocupar com qual tabela contém qual atributo. CJ Date, no entanto, apontou que em circunstâncias em que uma tabela está multiplamente relacionada a outra (como em bancos de dados genealógicos, onde o pai e a mãe de um indivíduo também são indivíduos, ou em alguns bancos de dados comerciais onde todos os endereços são armazenados centralmente, e uma organização pode têm endereços de escritório e endereços de envio diferentes), não há metadados suficientes no esquema do banco de dados para especificar associações inequívocas. Quando o UDM foi comercializado, como no SAP BusinessObjects , essa limitação é contornada por meio da criação de "Universos", que são visualizações relacionais com junções predefinidas entre conjuntos de tabelas: o desenvolvedor do "Universo" elimina a ambiguidade de junções ambíguas incluindo as relacionadas com multiplicação tabela em uma visualização várias vezes usando diferentes aliases.

Além da maneira como os dados são modelados explicitamente (o UDM simplesmente usa visualizações relacionais para interceder entre o usuário e o esquema do banco de dados), o EAV difere dos Modelos de Dados Universais porque também se aplica a sistemas transacionais, não apenas orientado a consultas (somente leitura ) sistemas como no UDM. Além disso, quando usadas como base para sistemas de consulta de dados clínicos, as implementações de EAV não necessariamente protegem o usuário de ter que especificar a classe de um objeto de interesse. No data mart clínico i2b2 baseado em EAV, por exemplo, quando o usuário pesquisa por um termo, ele tem a opção de especificar a categoria de dados em que o usuário está interessado. Por exemplo, a frase " lítio " pode se referir a o medicamento (que é usado para tratar o transtorno bipolar ) ou um teste de laboratório para o nível de lítio no sangue do paciente. (O nível de lítio no sangue deve ser monitorado cuidadosamente: uma quantidade excessiva do medicamento causa efeitos colaterais graves, enquanto uma quantidade insuficiente é ineficaz.)

XML e JSON

Uma implementação de Open Schema pode usar uma coluna XML em uma tabela para capturar as informações variáveis ​​/ esparsas. Idéias semelhantes podem ser aplicadas a bancos de dados que suportam colunas avaliadas em JSON : dados esparsos e hierárquicos podem ser representados como JSON. Se o banco de dados tiver suporte JSON, como PostgreSQL e (parcialmente) SQL Server 2016 e posterior, os atributos podem ser consultados, indexados e unidos. Isso pode oferecer melhorias de desempenho de mais de 1000 vezes em relação às implementações EAV ingênuas, mas não necessariamente torna o aplicativo de banco de dados geral mais robusto.

Observe que há duas maneiras de armazenar dados XML ou JSON: uma delas é armazená-los como uma string simples, opaca para o servidor de banco de dados; a outra maneira é usar um servidor de banco de dados que possa "ver" a estrutura. Obviamente, existem algumas desvantagens graves no armazenamento de strings opacas: elas não podem ser consultadas diretamente, não é possível formar um índice com base em seu conteúdo e é impossível realizar junções com base no conteúdo.

Construir um aplicativo que precisa gerenciar dados fica extremamente complicado ao usar modelos EAV, devido à extensão da infraestrutura que deve ser desenvolvida em termos de tabelas de metadados e código de estrutura de aplicativo. O uso de XML resolve o problema de validação de dados com base no servidor (que deve ser feito por código de camada intermediária e baseado em navegador em estruturas baseadas em EAV), mas tem as seguintes desvantagens:

  • É um programa intensivo. Esquemas XML são notoriamente difíceis de escrever à mão, uma abordagem recomendada é criá-los definindo tabelas relacionais, gerando código de esquema XML e, em seguida, eliminando essas tabelas. Isso é problemático em muitas operações de produção envolvendo esquemas dinâmicos, onde novos atributos devem ser definidos por usuários avançados que entendem um domínio de aplicativo específico (por exemplo, gerenciamento de estoque ou biomedicina), mas não são necessariamente programadores. Por outro lado, em sistemas de produção que usam EAV, esses usuários definem novos atributos (e o tipo de dados e verificações de validação associados a cada um) por meio de um aplicativo GUI. Como os metadados associados à validação devem ser armazenados em várias tabelas relacionais em um design normalizado, um aplicativo GUI que une essas tabelas e impõe as verificações de consistência de metadados apropriadas é a única maneira prática de permitir a entrada de informações de atributo, mesmo para desenvolvedores avançados - mesmo se o resultado final usar XML ou JSON em vez de tabelas relacionais separadas.
  • Os diagnósticos baseados em servidor que resultam com uma solução XML / JSON se dados incorretos são tentados a serem inseridos (por exemplo, verificação de intervalo ou violações de padrão de expressão regular) são crípticos para o usuário final: para transmitir o erro com precisão, seria, no mínimo, precisa associar um diagnóstico de erro detalhado e fácil de usar a cada atributo.
  • A solução não aborda o problema de geração da interface do usuário.

Todas as desvantagens acima podem ser corrigidas criando uma camada de metadados e código de aplicativo, mas ao criar isso, a "vantagem" original de não ter que criar uma estrutura desapareceu. O fato é que modelar atributos de dados esparsos de maneira robusta é um problema difícil de design de aplicativo de banco de dados, não importa qual abordagem de armazenamento é usada. O trabalho de Sarka, no entanto, prova a viabilidade de usar um campo XML em vez de tabelas relacionais EAV específicas de tipo para a camada de armazenamento de dados e em situações onde o número de atributos por entidade é modesto (por exemplo, atributos de produto variável para diferentes tipos de produto ), a solução baseada em XML é mais compacta do que uma baseada em tabelas EAV. (XML em si pode ser considerado um meio de representação de dados de valor de atributo, embora seja baseado em texto estruturado em vez de tabelas relacionais.)

Estruturas de árvore e bancos de dados relacionais

Existem várias outras abordagens para a representação de dados estruturados em árvore, seja XML , JSON ou outros formatos, como o modelo de conjunto aninhado , em um banco de dados relacional. Por outro lado, os fornecedores de banco de dados começaram a incluir suporte JSON e XML em suas estruturas de dados e recursos de consulta, como no IBM DB2 , onde os dados XML são armazenados como XML separados das tabelas, usando consultas XPath como parte de instruções SQL ou no PostgreSQL , com um tipo de dados JSON que pode ser indexado e consultado. Esses desenvolvimentos realizam, melhoram ou substituem a abordagem do modelo EAV.

Os usos de JSON e XML não são necessariamente os mesmos que os de um modelo EAV, embora possam se sobrepor. XML é preferível a EAV para dados arbitrariamente hierárquicos que são relativamente modestos em volume para uma única entidade: não se destina a escalar até o nível de vários gigabytes em relação ao desempenho de manipulação de dados. XML não está preocupado per se com o problema de atributos esparsos, e quando o modelo de dados subjacente às informações a serem representadas pode ser decomposto diretamente em uma estrutura relacional, XML é mais adequado como meio de intercâmbio de dados do que como mecanismo de armazenamento primário . EAV, conforme declarado anteriormente, é especificamente (e apenas) aplicável ao cenário de atributos esparsos. Quando tal cenário se mantém, o uso de tabelas de valor de atributo específicas de tipo de dados que podem ser indexadas por entidade, por atributo e por valor e manipuladas por meio de instruções SQL simples é muito mais escalável do que o uso de uma estrutura de árvore XML. O Google App Engine, mencionado acima, usa tabelas de valores fortemente tipados por um bom motivo.

Bancos de dados gráficos

Uma abordagem alternativa para gerenciar os vários problemas encontrados com dados estruturados de EAV é empregar um banco de dados de gráficos . Eles representam entidades como os nós de um gráfico ou hipergrafo , e os atributos como links ou arestas desse gráfico. O problema de junções de tabelas é abordado com o fornecimento de linguagens de consulta específicas para gráficos, como Apache TinkerPop ou o OpenCog atomspace pattern matcher.

Outra alternativa é usar o armazenamento SPARQL .

Considerações para software de servidor

PostgreSQL: colunas JSONB

PostgreSQL versão 9.4 inclui suporte para colunas binárias JSON (JSONB), que podem ser consultadas, indexadas e unidas. Isso permite melhorias de desempenho por fatores de mil ou mais em relação aos designs de mesa EAV tradicionais.

Um esquema db baseado em JSONB sempre tem menos tabelas: pode-se aninhar pares de valor-atributo em campos do tipo JSONB da tabela Entidade. Isso torna o esquema db fácil de compreender e as consultas SQL concisas. O código de programação para manipular os objetos de banco de dados na camada de abstração é muito mais curto.

SQL Server 2008 e posterior: colunas esparsas

O Microsoft SQL Server 2008 oferece uma alternativa (proprietária) ao EAV. As colunas com um tipo de dados atômico (por exemplo, colunas numéricas, varchar ou datetime) podem ser designadas como esparsas simplesmente incluindo a palavra SPARSE na definição de coluna da instrução CREATE TABLE. As colunas esparsas otimizam o armazenamento de valores NULL (que agora não ocupam nenhum espaço) e são úteis quando a maioria dos registros em uma tabela tem valores NULL para aquela coluna. Os índices em colunas esparsas também são otimizados: apenas as linhas com valores são indexadas. Além disso, o conteúdo de todas as colunas esparsas em uma linha específica de uma tabela pode ser agregado coletivamente em uma única coluna XML (um conjunto de colunas), cujo conteúdo está na forma [<column-name>column contents </column-name>]*....De fato, se um conjunto de colunas for definido para uma tabela como parte de uma instrução CREATE TABLE, todas as colunas esparsas definidas subsequentemente são normalmente adicionadas a ela. Isso tem a consequência interessante de que a instrução SQL SELECT * from <tablename>não retornará as colunas esparsas individuais, mas concatenará todas elas em uma única coluna XML cujo nome é o do conjunto de colunas (que, portanto, atua como uma coluna virtual computada). Colunas esparsas são convenientes para aplicativos de negócios, como informações de produto, onde os atributos aplicáveis ​​podem ser altamente variáveis ​​dependendo do tipo de produto, mas onde o número total de atributos variáveis ​​por tipo de produto é relativamente modesto.

Limitações de atributos esparsos

No entanto, essa abordagem para modelar atributos esparsos tem várias limitações: DBMSs rivais, notavelmente, optaram por não emprestar essa ideia para seus próprios motores. As limitações incluem:

  • O número máximo de colunas esparsas em uma tabela é 10.000, o que pode ser insuficiente para algumas implementações, como para armazenamento de dados clínicos, onde o número possível de atributos é uma ordem de magnitude maior. Portanto, esta não é uma solução para modelar * todos * os atributos clínicos possíveis para um paciente.
  • A adição de novos atributos - um dos principais motivos pelos quais um modelo EAV pode ser procurado - ainda requer um DBA. Além disso, o problema de construir uma interface de usuário para dados de atributos esparsos não é abordado: apenas o mecanismo de armazenamento é simplificado. * Os aplicativos podem ser escritos para adicionar e remover dinamicamente colunas esparsas de uma tabela em tempo de execução: em contraste, uma tentativa de realizar tal ação em um cenário multiusuário onde outros usuários / processos ainda estão usando a tabela seria evitada por tabelas sem colunas esparsas. No entanto, embora essa capacidade ofereça poder e flexibilidade, ela convida ao abuso e deve ser usada com cautela e com pouca frequência.
    • Isso pode resultar em penalidades de desempenho significativas, em parte porque quaisquer planos de consulta compilados que usam essa tabela são invalidados automaticamente.
    • A adição ou remoção de coluna dinâmica é uma operação que deve ser auditada, porque a remoção de coluna pode causar perda de dados: permitir que um aplicativo modifique uma tabela sem manter algum tipo de trilha, incluindo uma justificativa para a ação, não é uma boa prática de software.
  • As restrições SQL (por exemplo, verificações de intervalo, verificações de expressão regular) não podem ser aplicadas a colunas esparsas. A única verificação aplicada é para o tipo de dados correto. As restrições teriam que ser implementadas em tabelas de metadados e código de camada intermediária, como é feito em sistemas EAV de produção. (Essa consideração também se aplica a aplicativos de negócios.)
  • O SQL Server tem limitações no tamanho da linha se tentar alterar o formato de armazenamento de uma coluna: o conteúdo total de todas as colunas de tipo de dados atômicos, esparsas e não esparsas, em uma linha que contém dados não pode exceder 8016 bytes se a tabela contiver esparsos coluna para que os dados sejam copiados automaticamente.
  • Colunas esparsas que contêm dados têm uma sobrecarga de armazenamento de 4 bytes por coluna, além do armazenamento do próprio tipo de dados (por exemplo, 4 bytes para colunas de data e hora). Isso afeta a quantidade de dados de coluna esparsa que você pode associar a uma determinada linha. Essa restrição de tamanho é relaxada para o tipo de dados varchar, o que significa que, se alguém atingir os limites de tamanho de linha em um sistema de produção, será necessário contornar isso designando colunas esparsas como varchar, embora possam ter um tipo de dados intrínseco diferente. Infelizmente, essa abordagem agora subverte a verificação de tipo de dados do lado do servidor.

Ofertas de computação em nuvem

Muitos fornecedores de computação em nuvem oferecem armazenamento de dados com base no modelo EAV, onde um número arbitrário de atributos pode ser associado a uma determinada entidade. Roger Jennings fornece uma comparação detalhada deles. Na oferta da Amazon, SimpleDB, o tipo de dados é limitado a strings, e dados que são intrinsecamente não string devem ser coagidos para string (por exemplo, os números devem ser preenchidos com zeros à esquerda) se você deseja realizar operações como classificação. A oferta da Microsoft, Windows Azure Table Storage, oferece um conjunto limitado de tipos de dados: byte [], bool, DateTime, double, Guid, int, long e string [1] . O Google App Engine [2] oferece a maior variedade de tipos de dados: além de dividir os dados numéricos em int, long ou float, também define tipos de dados personalizados, como número de telefone, endereço de e-mail, geocódigo e hiperlink. O Google, mas não a Amazon ou a Microsoft, permite definir metadados que evitariam que atributos inválidos fossem associados a uma classe específica de entidade, permitindo que você crie um modelo de metadados.

O Google permite que você opere nos dados usando um subconjunto de SQL; A Microsoft oferece uma sintaxe de consulta baseada em URL que é abstraída por meio de um provedor LINQ ; Amazon oferece uma sintaxe mais limitada. De preocupação, o suporte integrado para combinar diferentes entidades por meio de junções é atualmente (abril '10) inexistente com todos os três motores. Essas operações devem ser executadas pelo código do aplicativo. Isso pode não ser uma preocupação se os servidores de aplicativos estiverem co-localizados com os servidores de dados no datacenter do fornecedor, mas muito tráfego de rede seria gerado se os dois estivessem separados geograficamente.

Uma abordagem EAV é justificada apenas quando os atributos que estão sendo modelados são numerosos e esparsos: se os dados sendo capturados não atendem a esse requisito, a abordagem EAV padrão dos fornecedores de nuvem costuma ser uma incompatibilidade para aplicativos que exigem um banco de dados back-end verdadeiro (em oposição a apenas um meio de armazenamento de dados persistente). A adaptação da grande maioria dos aplicativos de banco de dados existentes, que usam uma abordagem tradicional de modelagem de dados, para uma arquitetura de nuvem do tipo EAV, exigiria uma grande cirurgia. A Microsoft descobriu, por exemplo, que sua base de desenvolvedores de aplicativos de banco de dados relutava em investir tanto esforço. Mais recentemente, portanto, a Microsoft forneceu uma oferta premium - um mecanismo relacional completo acessível em nuvem, SQL Server Azure, que permite a portabilidade de aplicativos de banco de dados existentes com alterações modestas.

Uma limitação do SQL Azure é que os bancos de dados físicos são limitados a 500 GB de tamanho em janeiro de 2015. A Microsoft recomenda que os conjuntos de dados maiores do que isso sejam divididos em vários bancos de dados físicos e acessados ​​com consultas paralelas.

Veja também

Referências