It seems that the core functionalities of an application program I'm working on are nothing but associative entities. Hence one-to-many relations sort of produce "metadata" that will only feed (one way or the other) the associative entities for our application functionalities.
Now we have an entity-relationship diagram (ERD) that has lots of one-to-many (more that 10 tables) and just one associative entity. What does it say about that model or the the application?
Is it improvable, i.e., can the application circumvent more functionalities if the ERD is improved to add more associative entities?
Does having very few associative entities means that the application will not be rich in functionalities?
Additional considerations
What I'm wondering is: if the project scope statements lead to an ERD with only one many-to-many relation and a dozen of one-to-many, then would that mean that the project does not solve many problems (functionalities) except only digitizing lots of data?
I think that with less many-to-many, they will just mirror at first (unless we create join queries for other purposes…).
Or simply put: does a high number of many-to-many associations means that the software will be richer in functionalities than with less many-to-many (do not include join queries in the thoughts for this one)?
Best Answer
You touch several subjects, therefore it is important to establish their scopes and the links that exist among them.
Firstly, if the specific business domain you are working with implies (a) multiple one-to-many associations along with just one associative entity type —or many-to-many [M:N] association—, and (b) you are representing said characteristics with the demanded precision at both the conceptual and logical levels of abstraction of the database of interest then (c) there is nothing special about such a situation, you are doing just fine.
Conceptual schema: capturing the informational requirements of a business
A properly delimited conceptual schema —I am not sure, but it seems that that is what you mean by “project scope statements”— implies to the identification and definition of the relevant business rules that describe the interconnections (1) between entity types, (2) between entity types and their own properties and (3) between the properties themselves, which may come about in quite different cardinality ratios —neither only one-to-many [1:N], nor exclusively many-to-many [M:N]— and may or may not be represented in an entity-relationship diagram (ERD for brevity).
Regarding the initial title of the question, an associative entity type —which is different from an entity, i.e., an instance or occurrence of an entity type— can only be missing if the database modeler failed to (i) identify it and consequently (ii) did not reflect it in the pertinent conceptual schema and perhaps in an ERD.
ERDs: graphical representations of conceptual schemas
An ERD depicting the associations and the corresponding cardinality ratios of a certain scenario is not supposed to solve “the problem of digitizing lots data”, but serves the purpose of capturing and exposing graphically the conceptual definitions of the business in question. This sort of diagram is a communication instrument that can be really powerful when used appropriately.
If you want to see examples of the delineation of the conceptual schemas of databases with associations of very distinct cardinality ratios (and the subsequent logical-level representations), visit, e.g., my answers to the questions entitled
Levels of abstraction: application program components, ERD symbols and relational/SQL instruments
Since you mention “tables”, I assume that you have the intention of building a relational database, and said type of database must be independent from the application programs (apps, for brevity) that share access to it.
Naturally, the number of conceptual and logical elements of a database has repercussions on the number of kinds of items that the apps have to (a) receive from an end-user terminal or another system, (b) apply some computational processing and (c) send to the database. But the quantity of apps components (e.g., object-oriented classes) does not necessarily have to mirror (1) the quantity of conceptual-level entity types of a database nor (2) the quantity of base tables of the corresponding logical layout (e.g., the fields of a single object-oriented class may encompass the columns of two or more base or derived tables).
On the other hand, an ERD is not composed of tables but of graphical constructs portraying entity types and relationships (I prefer the words associations, connections or links, for reasons I will detail below). Said entity types and relationships are, in turn, usually represented by base tables (i.e., base relations), and enforced via constraints declared on columns with the respective data types or domains if possible (i.e., relation attributes), if they are managed by virtue of a relational database running on a relational database management system —which is the typical case, but the conceptual-level elements could be handled by, e.g., an obsolete network or hierarchical database—.
In this manner, it is very important to distinguish between (i) a conceptual-level relationship and (ii) a logical-level relation which is the mathematical construct —proposed by Dr. E. F. Codd in his relational model— utilized for administering data in a relational database. In this regard, you may find of help this series of posts.
It is as well opportune to differentiate between base and derivable data structures; the former commonly represented by base tables (i.e., those declared by dint of CREATE TABLE … ( … ); statements), and the latter by derived tables (i.e., those expressed by way of SELECT operations that, e.g., “combine” columns FROM distinct base tables or other derived tables via JOINs, sometimes fixed as VIEWs), when operating on a relational database. Since the app components have to do directly with the way in which the information of interest is displayed to end-users, they belong in the external level of abstraction when it comes to the ANSI/SPARC architecture, hence they should have a direct correspondence with the aforementioned views.
Application programs and data management: separation of concerns
In turn, the functionalities of the apps involve carrying out processes (“behaviour” using object-oriented programming terminology) and should be analyzed and defined by techniques (e.g., algorithm development) that are distinct from the ones used in the creation of a database, because database modeling and app design are two different (although related) disciplines.
The structural and functional richness of a whole computerized information system (i.e., a database and one or more apps sharing it) depends entirely on the skills possessed by the designer(s) with respect to the successful (i.e., accurate) representation of the informational (regarding the database) and processing or computational (concerning the apps) requirements. This is in agreement with the software development principle known as separation of concerns.