對一個數據庫管理員來說，所能為他的數據庫做的最好的事情就是使之開始於一個合理的邏輯設計。不幸的很，數據庫設計常常被匆匆地完成以致於做錯，甚至在數據庫建立後重新返工。一個見聞廣博的和聰明的數據庫管理員知道對數據庫進行很好的設計，會大大提高數據庫的性能，而不是減損數據庫的性能，這種思想與流行的思想相反。事實上，直接投入物理設計或更深層的工作，只會帶來麻煩，不僅在性能方面，而且在數據完整性方面同樣如此。
如果一個數據庫運行得很快，但收藏的數據卻是錯誤的，這又有什麼好處呢？而且，在數據庫系統的早期設計階段，創建一個合理的邏輯設計，可以讓它接受以後創建和維護階段物理設計改變的考驗。可是，如果你在邏輯設計階段走捷徑，你將不但可能需要重新設計邏輯模型，而且還可能需要重新構造下面的物理模型。間接的代價（職員的工作時間、停工期等等）可能會是令人吃驚的。在進行和建立數據庫之前，需要了解邏輯數據庫設計和標准化背後的基本原則。
在70年代中期，關系數據庫模型逐漸超越其他的數據模型占據主導地位，Oracle關系模型技術的風靡使設計性能得到規范化。這其中最流行的是實體關系圖（Entity-RelationshipDiagram，ERD），它是P.P.Chen在1976年提出來的。這就是語義數據模型，因它試圖捕獲業務要素（業務本質）的語義或正確含義。因為關系模型本身幾乎就是一個依據語法的模型，是一種主要處理結構的模型，實體關系圖（ERD）通常用於補充它。實際上，ERD建模必然先於關系建模。當一個ERD結束時，它或多或少地被直接映射到關系模型上，而後關系模型再被映射到它的物理模型上。
一個實體是一個業務元素，比如一個雇員或一個項目。一個關系就是兩個實體之間的聯系，比如工作於不同項目的雇員。屬性即組成實體的特征，比如一個雇員的工資或項目的預算。屬性被認為是來自定義域中的取值或值的集合，它們所取的值是它們以後在關系模型中所用到的數據。它們是對一個事物全部抽取或部分抽取。ERD有許多畫法，只要你選擇一種並在整個使用過程中保持含義一致即可。
使用方框代表實體畫高級圖（那些不帶屬性的），將實體的名字列於方框的中心。低級圖的實體名稱列於方框中的上部，後面跟著屬性名稱。
在方框之間畫有箭頭，代表關系類型，有三種基本類型的關系：一對一、一對多以及多對多。一對一的關系根據一對一關系的類型，在線條的一端或兩端使用單箭頭。一對多使用雙箭頭，多對多在兩邊使用雙箭頭。當一個實體的每一個值都和另一個實體的一個值並且只有一個值有關時，就存在著一個純粹的一對一關系，反之亦然。這種類型的關系是很少見。
一種更為普遍的一對一關系是子類型關系，這是面向對象分析和設計的基礎之一。在面向對象系統中，這被看作是類和子類（或者更簡單地說，類的級別）。換句話說，在更為普遍的實體中的屬性（長方形）上，將屬性（如長和寬）送給更為特定的實體（正方形）。因此，繼承的方向是從一般到特殊。子類型關系比純類型的一對一關系更為常見，但這兩種都不常用。通常，當一個設計者偶然遇到一對一關系時，他必須問下列問題：
■這兩個實體能結合嗎？
■它們對於自己的目標是否是完全相同的？
■它們是否由於某些業務原因必須保持獨立和不同嗎？
通常情況下，一對一實體是可以合並的。在Oracle關系模型中，使用得最多的關系是一對多關系。在這種情況下，作為一名設計者，你所能為自己做的最好的事情就是把自己從所有的多對多關系中解脫出來；並不是真正地除去它們，但你可以在它們原先位置上使用兩個或多個一對多關系來代替多對多關系。之所以要這樣做，是因為關系模型並不能實際處理一個多對多關系的直接實現。仔細想想，如果有許多從事多個項目的雇員，你怎樣來貯存外鍵？你不能在一列中貯存多個值，這樣違反了數據必須是原子的關系型要求，這意味著沒有一個單元能夠持有一條以上的信息。信息法則也說明：它是第一范式（FirstNormalForm）的一個特殊情況。因此，為確保數據的原子性，每條多對多關系都被兩個或者多個一對多關系所取代。
你所要作的工作就是分割多對多關系。在關系模型中，被稱為職位的新實體通常被叫做交叉表，因為它代表著與其相關的兩個表中每一對實際值的交集，有時也稱為叫紐帶表（ junction table）或連接表（ join table），交叉表是這樣的一個實體：它不一定總是一些業務元素的真實抽象，但是它是解決和實現Oracle關系模型中多對多關系的基本方法。
