首先，網頁歸網頁，資料庫歸資料庫
網頁上要怎麼呈現資料，關鍵是在你怎麼跟資料庫要資料(SQL查詢等)

所以網頁的部份會是另一個問題，這裡暫且不討論

回到正題

以上訂單表中 單價 以及 商品圖有必要嗎？

通常來說，正規化的形式會做到3NF乃至BCNF，通常3NF能夠取得效能與資料關係最好的平衡點
正規化的定義

而另一方面，為了搭配物件導向的程式設計概念，我們會盡量將資料庫設計成一張表(Table)即為一個實體(Entity)，而資料表之間的關係便可以轉化為實體之間的關係(Entity Relationship)，此時便可以將資料關係轉化為實體關係圖(Entity Relationship Diagram, ERD)

當有了ERD的概念後，反過來說，我們也可以透過先設計實體關係，再設計資料表，通常若有妥善設計ERD，根據ERD產生的資料庫便會是第三正規化(3NF)後的資料庫

先簡單介紹ERD以及資料庫相關術語的轉換關係：

• 實體<->資料表
• 屬性<->資料欄位
• 實體關係<->資料關係(通常是Foreign key)

我們會將

1. 名詞作為實體
2. 形容名詞的形容詞或作為實體所有格的名詞，會作為屬性
3. 動詞作為實體關係

以您的問題為例：

在網頁上
商品介紹 有 1、商品ID 2、名稱 3、代表圖
訂單明細 有 1、訂單ID 2、商品ID 3、數量 4、單價 5、商品圖
在資料表中
商品表 有 1、ID 2、名稱 3、單價 4、代表圖
#訂單表 有 1、ID 2、商品ID 3、數量 4、單價 5、商品圖

可以看出您的系統中存在「商品」、「訂單」兩樣實體

而如何定義兩樣實體的屬性?

商品的部份，為了識別各個商品，會需要商品ID，商品也該有個名稱，並且也會有一張代表圖，另外每個商品都該有他的單價，以及現有的庫存數量

而訂單的部份，因為一張訂單不會只有一樣商品，而一樣商品也不會只出現在一張訂單，訂單及商品的關係為多對多關係。

多對多關係的解決方式，通常會使用Master and Detail的方式來設計：將訂單分割為「訂單」及「訂單細項」，訂單記錄與訂單相關的屬性(下訂日期、客戶等)，而訂單細項則對應訂單及商品的資料，一筆訂單細項應有訂單ID及商品ID兩個屬性，以對應訂單及商品的關係

根據上述，產生的ERD可參照下圖：

之後可再根據ERD設計資料庫，即可直接得到3NF後的資料庫

以上為個人淺見，實際狀況仍須根據您的實際需求去做更動。

這個問題問的很奇特。
其實有沒有需要，不是看開發者的認定嘛?

這實在是不知道該怎麼回答了。
不過一般來說，單價還是有其必要。不能因為之後改變價格時，訂單價格就改變。
至於商品圖。我個人認為不需要在訂單表上出現就是了。
當然了，依照需求而定。有部份工程師不想再連結或撈一次商品表來取得圖片。
就會將一些必要顯示的資料也一起存在訂單上。
認真來說這樣也是ok的。

你這個問題是「需求」
版上大部分是「工程師」
「需求」來自於業主...所以你是業主...還是被要求要設定格式的工程師...

我有簡單的答案和複雜的答案
看你喜歡那一個

簡單的答案
沒必要
訂單表中可以使用「商品 ID」去串出「單價」及「商品圖」

複雜的答案
要看資料欄位的「變化性」
試回答:一個商品的「單價」或「商品圖」是否「永遠不變」?
如果答案是「是」，那麼訂單表中就不必要有「單價」和「商品圖」
如果答案是「否」，那麼訂單表中就要有「單價」和「商品圖」
以下針對「單價」部份舉例如下
1/1 有一商品 X01，單價為 100
1/10 接一張訂單 P01，數量 10 pcs (單價應為 100)
1/20 因故商品調漲價格，單價變為 150
1/25 接一張訂單 P02，數量 20 pcs (單價應為 150)
由此例可看出
如果訂單表中「只有商品ID而沒有單價」的話
那麼 P01,P02 的單價都會變成 150
事情就大條了

實務上單價也不是只有一個欄位這麼單純
那又是後話了...

商品表中的單價可以視為取得的單價，訂貨時單價小於該值，表示折價出售。
訂單表中的單價可以視為銷貨時的單價，兩者是有所不同。
商品圖也是一樣，
商品表記錄的是目前的單價，及圖片。
訂單表中記錄的是當時銷售價格及圖片。