一旦你認為你已經明確了業務內容，你最好同客戶進行一次系統的交流。采用客戶的術語并且向他們解釋你所想到的和你所聽到的。同時還應該用可能、將會和必須等詞匯表達出系統的關系基數。這樣你就可以讓你的客戶糾正你自己的理解然后做好下一步的 ER 設計。
一定要花點時間創建 ER 圖表和數據字典。其中至少應該包含每個字段的數據類型和在每個表內的主外鍵。創建 ER 圖表和數據字典確實有點費時但對其他開發人員要了解整個設計卻是完全必要的。越早創建越能有助于避免今后面臨的可能混亂，從而可以讓任何了解數據庫的人都明確如何從數據庫中獲得數據。
有一份諸如 ER 圖表等最新文檔其重要性如何強調都不過分，這對表明表之間關系很有用，而數據字典則說明了每個字段的用途以及任何可能存在的別名。對 SQL 表達式的文檔化來說這是完全必要的。
一張圖表勝過千言萬語：開發人員不僅要閱讀和實現它，而且還要用它來幫助自己和用戶對話。模式有助于提高協作效能，這樣在先期的數據庫設計中幾乎不可能出現大的問題。模式不必弄的很復雜；甚至可以簡單到手寫在一張紙上就可以了。只是要保證其上的邏輯關系今后能產生效益。
在定義數據庫表和字段需求（輸入）時，首先應檢查現有的或者已經設計出的報表、查詢和視圖（輸出）以決定為了支持這些輸出哪些是必要的表和字段。舉個簡單的例子：假如客戶需要一個報表按照郵政編碼排序、分段和求和，你要保證其中包括了單獨的郵政編碼字段而不要把郵政編碼糅進地址字段里。
要了解用戶通常是如何報告數據的：批處理還是在線提交報表？時間間隔是每天、每周、每月、每個季度還是每年？如果需要的話還可以考慮創建總結表。系統生成的主鍵在報表中很難管理。用戶在具有系統生成主鍵的表內用副鍵進行檢索往往會返回許多重復數據。這樣的檢索性能比較低而且容易引起混亂。