Parece que as principais funcionalidades de um programa aplicativo em que estou trabalhando não são nada além de entidades associativas . Portanto, as relações um-para-muitos produzem "metadados" que apenas alimentarão (de uma forma ou de outra) as entidades associativas para as funcionalidades de nossa aplicação.
Agora temos um diagrama entidade-relacionamento (ERD) que tem muitos um-para-muitos (mais de 10 tabelas) e apenas uma entidade associativa. O que isso diz sobre esse modelo ou o aplicativo?
É melhorável, ou seja, a aplicação pode contornar mais funcionalidades se o ERD for melhorado para adicionar mais entidades associativas?
Ter poucas entidades associativas significa que a aplicação não será rica em funcionalidades?
Considerações adicionais
O que eu estou querendo saber é: se as declarações de escopo do projeto levam a um ERD com apenas uma relação muitos-para-muitos e uma dúzia de um-para-muitos, isso significaria que o projeto não resolve muitos problemas (funcionalidades) exceto apenas digitalizar muitos dados?
Eu acho que com menos muitos para muitos, eles apenas espelharão no início (a menos que criemos consultas de junção para outros propósitos...).
Ou simplesmente: um número alto de associações muitos-para-muitos significa que o software será mais rico em funcionalidades do que com menos muitos-para-muitos (não inclua consultas de junção nos pensamentos para este)?
Você toca em vários assuntos, por isso é importante estabelecer seus escopos e os vínculos que existem entre eles.
Em primeiro lugar, se o domínio de negócios específico com o qual você está trabalhando implica (a) várias associações de um para muitos junto com apenas um tipo de entidade associativa —ou associação de muitos para muitos [M:N]— e (b) você está representando essas características com a precisão exigida nos níveis conceitual e lógico de abstração do banco de dados de interesse , então (c) não há nada de especial nessa situação, você está indo muito bem.
Esquema conceitual: capturando os requisitos de informação de um negócio
Um esquema conceitual adequadamente delimitado —não tenho certeza, mas parece que é isso que você quer dizer com “declarações de escopo do projeto”— implica na identificação e definição das regras de negócios relevantes que descrevem as interconexões (1) entre tipos de entidade , ( 2) entre tipos de entidade e suas próprias propriedades e (3) entre as próprias propriedades , que podem ocorrer em razões de cardinalidade bem diferentes – nem apenas um para muitos [1:N], nem exclusivamente muitos para muitos [M :N]— e pode ou não ser representado em um diagrama entidade-relacionamento (ERD para abreviar).
Em relação ao título inicial da pergunta, um tipo entidade associativa —que é diferente de uma entidade , ou seja, uma instância ou ocorrência de um tipo entidade— só pode faltar se o modelador de banco de dados não conseguiu (i) identificá-lo e consequentemente (ii ) não refletiu no esquema conceitual pertinente e talvez em um ERD.
ERDs: representações gráficas de esquemas conceituais
Um ERD que descreva as associações e os respectivos rácios de cardinalidade de um determinado cenário não pretende resolver “o problema da digitalização dos dados dos lotes”, mas serve para captar e expor graficamente as definições conceptuais do negócio em questão. Esse tipo de diagrama é um instrumento de comunicação que pode ser realmente poderoso quando usado adequadamente .
Se você quiser ver exemplos de delineamento dos esquemas conceituais de bancos de dados com associações de razões de cardinalidade muito distintas (e as representações de nível lógico subsequentes), visite, por exemplo, minhas respostas às perguntas intituladas
Níveis de abstração: componentes do programa aplicativo, símbolos ERD e instrumentos relacionais/SQL
Como você menciona “tabelas”, suponho que você tenha a intenção de construir um banco de dados relacional, e esse tipo de banco de dados deve ser independente dos programas aplicativos (apps, para resumir) que compartilham o acesso a ele.
Naturalmente, o número de elementos conceituais e lógicos de um banco de dados repercute no número de tipos de itens que os aplicativos precisam (a) receber de um terminal de usuário final ou outro sistema, (b) aplicar algum processamento computacional e (c) ) enviar para o banco de dados. Mas a quantidade de componentes de aplicativos (por exemplo, classes orientadas a objetos) não precisa necessariamente espelhar (1) a quantidade de tipos de entidade de nível conceitual de um banco de dados nem (2) a quantidade de tabelas base do layout lógico correspondente (por exemplo, , os campos de uma única classe orientada a objetos podem abranger as colunas de duas ou mais tabelas base ou derivadas ).
Por outro lado, um ERD não é composto de tabelas, mas de construções gráficas que retratam tipos de entidade e relacionamentos (prefiro as palavras associações , conexões ou links , por motivos que detalharei abaixo). Esses tipos de entidade e relacionamentos são, por sua vez, geralmente representados por tabelas base (ou seja, relações de base), e reforçados por meio de restrições declaradas em colunas com os respectivos tipos de dados ou domínios, se possível (ou seja, atributos de relação), se forem gerenciados por virtude de um banco de dados relacional rodando em umsistema de gerenciamento de banco de dados relacional —que é o caso típico, mas os elementos de nível conceitual podem ser manipulados, por exemplo, por uma rede obsoleta ou banco de dados hierárquico—.
Desta forma, é muito importante distinguir entre (i) uma relação de nível conceitual e (ii) uma relação de nível lógico que é o construto matemático - proposto pelo Dr. EF Codd em seu modelo relacional - utilizado para administrar dados em um banco de dados relacional. Nesse sentido, você pode encontrar ajuda nesta série de posts .
Também é oportuno diferenciar entre estruturas de dados base e deriváveis ; a primeira comumente representada por tabelas base (ou seja, aquelas declaradas por meio de instruções CREATE TABLE … ( … );), e a última por tabelas derivadas (ou seja, aquelas expressas por meio de operações SELECT que, por exemplo, “combinam” colunas FROM tabelas base distintas ou outras tabelas derivadas por meio de JOINs, às vezes fixadas como VIEWs), ao operar em um banco de dados relacional. Como os componentes do aplicativo têm a ver diretamente com a maneira como as informações de interesse são exibidas aos usuários finais, eles pertencem ao nível externo de abstração quando se trata da arquitetura ANSI/SPARC, portanto, devem ter uma correspondência direta com os pontos de vista mencionados.
Programas de aplicativos e gerenciamento de dados: separação de preocupações
Por sua vez, as funcionalidades dos aplicativos envolvem a realização de processos (“comportamento” usando terminologia de programação orientada a objetos) e devem ser analisadas e definidas por técnicas (por exemplo, desenvolvimento de algoritmos) distintas daquelas utilizadas na criação de um banco de dados , porque modelagem de banco de dados e design de aplicativo são duas disciplinas diferentes (embora relacionadas).
A riqueza estrutural e funcional de todo um sistema informatizado de informação (ou seja, um banco de dados e um ou mais aplicativos compartilhando-o) depende inteiramente das habilidades possuídas pelo(s) designer(s) com relação à representação bem-sucedida (ou seja, precisa) da informação. (em relação ao banco de dados) e requisitos de processamento ou computacionais (em relação aos aplicativos). Isso está de acordo com o princípio de desenvolvimento de software conhecido como separação de interesses .