難以決定使用什麼/多少表；標準化表明一個
更多的是社區的概念問題，因為我還沒有像我想的那樣“思考數據庫”。我正在使用帶有 SQL Developer 的 Oracle Database 18c Express Edition。
我被要求建立一個數據庫來記錄商店的銷售情況。要記錄的內容是；
- 日期
- 天
- 時間
- 價值$$ grouped, either Low, Medium, or High, rather than absolute monetary value $$
- 地點$$ on a (-5,-5) to (5,5) grid $$
如果我們為每次銷售添加一個增量 UID 作為主鍵，我不明白為什麼我需要一張表來執行此操作。我需要一個實體，Sale，它包含六個屬性（UID 和上面的列表）。它將有一個主鍵，沒有重複組，沒有復合 PK，並且沒有依賴於另一個非關鍵欄位的非關鍵欄位。
我被要求生成的查詢（我不需要幫助，但可能會影響設計）是；
- 尋找最安靜的一天
- 找到最忙的時間
- 尋找收入最高的地點
- 按價值範圍生成銷售報告
- 在每個價值範圍內按小時跟踪購買報告
- 確定沒有收入的地點
顯然我需要處理一些限制（商店週日不營業，僅在x和y小時之間營業，到達樓層的自動扶梯位於 (0,0) 等），但這些相對簡單，我我相信，更多的閱讀和調整會讓我到達那裡。不過，根據我的經驗，技術問題更容易解決。
我真正的戲劇來自嘗試提出數據庫設計。通常我希望規範化為我完成大部分繁重的工作，將我引導到我需要創建新表以將不同屬性分離到它們自己的實體中的地方。該任務指定數據需要是 3NF（然後還繼續說不需要規範化，令人困惑）。我正在閱讀 Kevin Bowman 的“系統分析：初學者指南”作為我的主要參考點，根據我對它的理解，我期望記錄的數據已經是 3NF，不需要超過一個桌子。
這似乎太簡單了，我懷疑我在這個過程中的某個時候根本沒有得到它。一位同事說他計劃為每個屬性製作一個表格，這對我來說似乎很瘋狂並且沒有必要。
有沒有人有任何想法，或者看到我的推理有任何問題？
您可能會考慮的一點是以任何方式儲存實際銷售價值。如果您儲存範圍，使用者必須從值轉換為範圍，並且可能會出錯。如果您創建一個儲存範圍的表，系統可以執行此任務。您還可以稍後更改範圍。
規範化還意味著不儲存冗餘資訊。由於您可以從日期（使用格式）中得出日期，因此您不需要兩者。它還可能導致數據不一致。
您可以做的最後一件事是創建一個位置表。如果系統不知道存在哪些位置，則很難找到沒有銷售的位置。它還有助於驗證使用者輸入。
值範圍必須有一個規則，這意味著您正在失去數據：如果稍後修改波段怎麼辦？
更好地儲存詳細資訊（銷售成本）並單獨建模條帶。
已經提到了一天（兩者都不會是 3nf，請參閱您的文本）
我還將對位置進行建模並在此處使用 FK 表示，而不是包含它。
考慮根據以前的銷售數據重組車間意味著什麼（物理座標只是位置的一個組成部分）
哪些位置在收銀台、門口等：將座標放在銷售表中，很難輕易容納新屬性。