我一直在搞亂1NF

對我來說，到目前爲止，關於1NF的最容易理解的描述是，我發現'主鍵是一列（或一組列），唯一標識每一行。 'on www.phlonx.com 我知道每個鍵的冗餘意味着每行不應多於1個值。然後，超過1個值將是'多餘的'。對？我一直在搞亂1NF

我仍然設法擰了很多次NF。我張貼的問題，我在網上pizzashop http://foo.com pizzashop here

在那裏我感到困惑在第二範式的東西才發現我開始錯在1 NF。現在我想我需要1NF中的3個鍵來唯一標識每一行。在這種情況下，我發現order_id，pizza_id和topping_id會爲我做到這一點。那是3列。因爲如果你想知道哪個特定的披薩是你需要知道的是什麼order_id，它有什麼類型的披薩（pizza_id）以及那裏有什麼打頂。如果你知道的話，你可以查看其餘的。然而，從上一個問題的答案來看，這似乎是錯誤的，因爲topping_id會轉到另一張我不明白的表格。下面是列的列表：

ORDER_ID
order_date的
CUSTOMER_ID
CUSTOMER_NAME
電話
促進
黑名單Y或N
Customer_address
ZIP_CODE
市
企業郵箱
Pizza_id
Pizza_name
面積
Pizza_price
金額
Topping_id
Topping_name
Topping_prijs
Availabitly
Delivery_id
Delivery_zone
Deliveryguy_id
Deliveryguy_name
交付Y或N

編輯：我標記爲粗體的第一個連接的密鑰的ID。它們只是一列列表，沒有標準化。他們不是1桌或3桌或任何東西

來源

2011-04-11 Immers

那麼問題是什麼？ ;-) – egbokul 2011-04-11 11:18:43

你有沒有在一張表中的所有列？那肯定會違反2NF – 2011-04-11 11:19:19

@ Gabor Kulcsar我的問題是：我正在以正確的方式來解決這個問題嗎？如果不是，爲什麼不呢？ @mar_s：不，這不是第二範式也不是上面的表格留下一張大桌子。這是關於第一個正常形式的問題，它的主鍵 – Immers 2011-04-11 11:21:41

使用Object Role Modelling（與NORMA說）來捕獲有關設計的信息，按下按鈕，它會吐出SQL。

這比在1NF，2NF等之間來回更容易.ORM設計保證在5NF。

一些注意事項：

你可以有複合鍵
代理鍵可以後加入概念和邏輯設計：您將他們添加了前面這是壞的。它們是因爲RDBMS的性能而添加的，而不是在設計時

你有沒有讀 1NF上的幾個來源？

從簡單的英語和一些事實開始。這是ORM與口頭表達的關係。

所以：

客戶有許多比薩餅（零到n）

比薩有許多配料（零到n）

一位顧客都有一個地址

比薩有一個基地

...

來源

2011-04-11 11:29:38 gbn

是的，我已經明確地閱讀了1NF上的一些資源，事情就是我讀得越多，我就越感到困惑，這就是爲什麼我問這個問題。我一直在努力正常化太久，這令我非常沮喪。就像我使用人類語言技術一樣，我得到的結果與我嚴格使用科德規則的結果不同。我對我的教練感到困惑，說你應該能夠在不知道你的列名是什麼意思的情況下正常化。其他人則說要利用你的常識，並遵循你的邏輯。 – Immers 2011-04-11 12:06:36

@Jack_Anyway：只有知道（或假設）模型中存在的所有函數依賴關係（並且有算法可以告訴您如何實現這一點），您才能夠在不知道列名是什麼意思的情況下進行規範化。那麼這是可能的。然而，FD要麼是從數據中推斷出來的，要麼是從你設計的模型的含義（語義）中推導出來的，所以設計和規範化之間有自然而深刻的重疊。 – Unreason 2011-04-12 12:13:26

酷我喜歡得到它。它不一定是一個或者一件事物。當然。 – Immers 2011-04-12 13:43:53

relational databases的優勢來自分離信息到不同的表。查看錶的一個useful way首先將實體表識別爲相對永久的概念（在您的案例中，可能是Pizza，Customer，Topping，Deliveryguy）。然後你考慮它們之間的關係（在你的案例中，Order，Delivery）。關係表通過foreign keys指向相關實體將實體表鏈接在一起：一個訂單具有Customer，Pizza，Topping的外鍵）;遞送具有Deliveryguy和Order的外鍵。而且，是的，關係可以將關係連接起來，而不僅僅是實體。

只有在這樣的背景下，你才能實現標準化等任何事情。將一堆屬性扔到一個單獨的表中並不會使您的數據庫關係具有任何意義。

來源

2011-04-11 11:29:35

開1NF，維基百科，報價日期：

根據1NF日期的定義，表是1NF當且僅當它是「同構於有一定的關係」，這手段，具體地說，它滿足以下五個條件：

沒有從上到下的排序。

列沒有從左到右的順序。

沒有重複的行。

每一個行列交叉點都包含恰好一個來自適用域的值（並且沒有其他的）。

所有列都是常規的[即行沒有隱藏的組件，例如行ID，對象ID或隱藏的時間戳]。

克里斯日期，「什麼第一範式的真正含義」，第127-8 [4]

前兩個是保證在任何現代RDBMS。

重複行在現代RDBMS中是可能的 - 但是，只有在沒有主鍵（或其他唯一約束）的情況下。

第四個是最難的（並取決於您的模型的語義） - 例如您的字段Customer_address可能會打破1NF。可能是，因爲如果你與自己（以及系統的任何潛在用戶）簽訂合同，你將總是看到整個地址，並且不希望將街道名稱，街道號碼或樓層分開，但仍然可以聲稱1NF沒有損壞。

打破客戶地址會更合適，但是那裏有複雜性，您需要解決這些問題並且可能不會帶來任何好處（前提是您不必看到子原子部分）地址線）。

第五個被一些現代的RDBM打破，但真正的重要性在於你的模型和系統應該依賴於隱藏的元素，通常情況下這是真的 - 即使你的RDBMS在內部使用某些操作的OID，除非你開始將它們用於非管理性的非維護任務，您可以認爲它不會破壞1NF。

來源

2011-04-11 11:33:37 Unreason

你是對的，但它並沒有真正幫助OP：他們需要我懷疑的實際幫助... – gbn 2011-04-12 12:02:45

@gbn，這是一個假設！ :)僅基於您的答案被接受並投票決定的事實！ :) – Unreason 2011-04-12 12:15:48

不，基於OP的問題。不是每個人都懂得關係，甚至純粹的集合論...... – gbn 2011-04-12 13:19:04

我會用更多的表對於這一點，以消除重複的客戶，訂單，配料和pizze：

表：客戶

Customer_id 
    Customer_name 
    Customer_name 
    Phone 
    Promotion 
    Blacklist Y or N 
    Customer_address 
    ZIP_code 
    City 
    E_mail

表：訂單

Order_id 
Order_date 
Customer_id 
Delivery_zone 
Deliveryguy_id 
Deliveryguy_name 
Delivery Y or N

表：Order_Details

Order_ID (FK on Order) 
Pizza_ID (FK on Pizza) 
Amount

表：披薩

Pizza_id 
Pizza_name 
Size 
Pizza_price

表：唐培

Topping_id 
Topping_name 
Topping_prijs 
Availabitly

表：Pizza_Topping

Pizza_ID 
Topping_ID

Pizza_topping和ORDER_DETAILS是所謂interselection表（建模「助手」表是：兩個表之間的關係）。

現在假設我們只有一個比薩，有些澆頭，我們的客戶比利·史密斯訂單2從Quattro Stagione pizze - 我們的表將包含這樣的內容：

比薩（Pizza_ID，Pizza_name，Pizza_price）

1 Quattro stagioni 12€

摘心（Topping_id，topping_name，topping_price）

1 Mozzarrella 0,50€ 
    2 Prosciutto 0,70€ 
    3 Salami 0,50€

Pizza_Topping（Pizza_ID，Topping_ID）

1 1 
1 3

（在這裏，quattro stagioni比薩只包含Mozzarrella和薩拉米）。

訂單（ORDER_ID，CUSTOMER_NAME - 儘可省略）

1 Billy Smith

ORDER_DETAILS（ORDER_ID，Pizza_id，金額）

1 1 2

我已經刪除傳遞ID，因爲對我來說，沒有高低貴賤訂單和交貨之間 - 還是您支持部分交貨？

來源

2011-04-11 11:34:40

我一直在搞亂1NF

回答

相關問題