Introdução
Olá a todos, esta é principalmente uma questão de classificação/teórica sobre o tópico de técnicas de herança e normalização no design de banco de dados e sua representação apropriada em diagramas relacionais de entidade. Em uma implementação prática, isso não representa um desafio, pois você pode simplesmente definir o atributo em questão como IS NOT NULL e pronto. No entanto, para uma representação gráfica, estou um pouco confuso sobre como fazê-lo corretamente. Aqui está um link do github gist com um diagrama de sereia interativo representando um cenário hipotético em um exemplo específico: gist
Problema
A parte importante está nesta seção: Suponha que temos uma entidade chamada PRODUCT que pode ter diferentes tipos de atributos dependendo do produto em questão (ex. Produto físico/Produto digital). Por esse motivo, introduzimos duas "subtabelas" cujos PKs referem-se a um atributo FK de PRODUCTs product_type_id . É claro que um PRODUCT só pode ter um product_type_id singular , mas como pode ser PhysicalProduct ou DigitalProduct , que tipo de relacionamento essas duas "subtabelas" têm com PRODUCT? Até agora deduzi que deve ser um a (zero ou um) conforme apresentado no gráfico. É aí que reside o problema (talvez inexistente). Se tivermos dois um a (zero ou um)relacionamentos com um atributo IS NOT NULL obrigatório não infere visualmente a possibilidade de dois relacionamentos um a zero ou é algo que não estala na minha cabeça aqui e é assim que deveria ser neste tipo de cenário?
O problema aqui são várias tabelas que fazem a mesma coisa. Em seu esquema, PhysicalProduct e DigitalProduct descrevem um produto . Isso é um não-não para a normalização.
E pense apenas no produto. O que você está vendendo, pode ser Físico ou Digital. Por que "ou... ou", por que não os dois? Por exemplo, posso ter um livro de capa dura e um e-book. Ou mp3 e vinil da mesma música... Não posso ter uma mercearia digital, mas ainda assim seria estranho se você começasse a descrever batatas e morangos por duas tabelas diferentes (vegetais/frutas).
Situações como essa geralmente são resolvidas pelo modelo de dados EAV . A tabela PRODUCT é uma descrição "geral" do produto e temos apenas uma tabela PRODUCT_ATTRIBUTE, que apontaria para o PRODUCT como muitos para um.
Todos os campos que você coloca em PhysicalProduct e DigitalProduct ("weight", "dimensions", "file_size", etc) tornam-se atributos na tabela PRODUCT_ATTRIBUTE. Se seu banco de dados não suporta tipos de dados variantes, você pode criar vários campos como "value_int", "value_string" ou apenas um
text
campo com uma conversão em um cliente quando necessário.