實體關係圖和應用程序功能
似乎我正在開發的應用程序的核心功能只不過是關聯實體。因此，一對多關係會產生“元數據”，它只會為我們的應用程序功能提供（一種或另一種方式）關聯實體。
現在我們有一個實體關係圖 (ERD)，它有很多一對多（超過 10 個表）和一個關聯實體。它對那個模型或應用程序有什麼看法？
是否可以改進，即如果改進 ERD 以添加更多關聯實體，應用程序是否可以繞過更多功能？
關聯實體很少是否意味著應用程序的功能不豐富？
其他注意事項
我想知道的是：如果項目範圍陳述導致 ERD 只有一個多對多關係和十幾個一對多關係，那麼這是否意味著該項目不能解決很多問題（功能）除了隻數字化大量數據？
我認為少對多的情況下，它們一開始只會鏡像（除非我們為其他目的創建連接查詢……）。
或者簡單地說：大量的多對多關聯是否意味著軟體的功能將比多對多少的更豐富（在這個想法中不包括連接查詢）？
您涉及多個主題，因此確定它們的範圍以及它們之間存在的聯繫非常重要。
首先，如果您正在使用的特定業務領域意味著（a）多個一對多關聯以及一個關聯實體類型 - 或多對多
$$ M:N $$關聯-，並且（b）您在感興趣的數據庫的概念和邏輯抽象級別上以所需的精度表示所述特徵，然後（c）這種情況沒有什麼特別之處，您做得很好。
概念圖式：擷取業務的資訊需求
一個適當分隔的概念模式——我不確定，但似乎這就是你所說的“項目範圍陳述”的意思——意味著辨識和定義描述實體類型之間的互連 (1)的相關業務規則，( 2）實體類型和它們自己的屬性之間以及（3）屬性本身之間，這可能以完全不同的基數比出現——既不是一對多
$$ 1:N $$, 也不完全是多對多$$ M:N $$— 並且可能會或可能不會在實體關係圖中表示（為簡潔起見，ERD）。 關於問題的初始標題，關聯實體類型（不同於實體，即實體類型的實例或出現）只有在數據庫建模者未能（i）辨識它並因此（ii ) 沒有反映在相關的概念模式中，也可能沒有反映在 ERD 中。
ERD：概念模式的圖形表示
描述某個場景的關聯和相應基數比的 ERD 不應該解決“數字化批次數據的問題”，而是用於擷取和以圖形方式展示相關業務的概念定義。這種圖表是一種*交流工具，*如果使用得當，它會非常強大。
如果您想查看描述數據庫概念模式與非常不同的基數比（以及隨後的邏輯級表示）關聯的範例，請訪問例如我對標題為
抽象級別：應用程序組件、ERD 符號和關係/SQL 工具
由於您提到“表”，我假設您有建構關係數據庫的意圖，並且所述數據庫類型必須獨立於共享訪問它的應用程序（應用程序，為簡潔起見）。
自然，數據庫的概念和邏輯元素的數量會影響應用程序必須（a）從最終使用者終端或另一個系統接收的項目種類的數量，（b）應用一些計算處理和（c ) 發送到數據庫。但是應用程序組件（例如，物件導向的類）的數量不一定必須反映（1）數據庫的概念級實體類型的數量，也不一定必須反映（ 2）相應邏輯佈局的基表的數量（例如，單個面向對像類的欄位可能包含兩個或多個基表或派生表的列）。
另一方面，ERD不是由表格組成，而是由描繪實體類型和關係的圖形結構組成（我更喜歡用詞關聯、連接或連結，原因我將在下面詳述）。反過來，所述實體類型和關係通常由基表（即基關係）表示，並且如果可能，則通過在具有相應數據類型或域（即關係屬性）的列上聲明的約束來強制執行，**如果它們由關係數據庫執行在關係數據庫管理系統——這是典型案例，但概念級元素可以由例如過時的網路或分層數據庫處理。
以這種方式，區分 (i) 概念級關係和 (ii) 邏輯級關係是非常重要的，邏輯級關係是EF Codd 博士在他的關係模型中提出的用於管理數據的數學結構一個關係數據庫。在這方面，您可能會在本系列文章中找到幫助。
區分基本資料結構和可派生資料結構也是不錯的選擇；前者通常由基表表示（即，由 CREATE TABLE … ( … ); 語句的 dint 聲明的表），而後者由派生表表示（即，通過 SELECT 操作表示的那些，例如“組合”列 FROM在關係數據庫上操作時，不同的基表或其他派生表通過 JOIN（有時固定為 VIEW） 。由於應用程序組件必須直接與向最終使用者顯示感興趣的資訊的方式有關，因此它們在涉及 ANSI/SPARC 架構時屬於外部抽象級別，因此它們應該與上述觀點。
應用程序和數據管理：關注點分離
反過來，應用程序的功能涉及執行過程（使用物件導向的程式術語的“行為”），應該通過不同於創建數據庫的技術（例如算法開發）來分析和定義，因為數據庫建模和應用程序設計是兩個不同（儘管相關）的學科。
整個電腦化資訊系統（即數據庫和一個或多個共享它的應用程序）的結構和功能豐富性完全取決於設計者在成功（即準確）表示資訊方面所擁有的技能（關於數據庫）和處理或計算（關於應用程序）要求。這與稱為關注點分離的軟體開發原則一致。