規範化和多值字段

我遇到了一個問題，那就是我的學生在訪問中使用多值字段並因此而對正常化感到困惑。規範化和多值字段

這是我能做的。鑑於一對多關係，例如

Articles Comments 
-------- -------- 
artID{PK} commID{PK} 
text  text 
      artID{FK}

訪問能夠將此信息存儲到這似乎是一個表，像

Articles 
-------- 
artID{PK} 
text 
comment 
    + value

「價值」，指的評論「列」多個註釋值，這實際上訪問作爲單獨的表存儲。數值如何存儲的細節 - 表格，其PK和FK - 完全隱藏，但可以查詢多值字段，例如，在上面的示例中使用查詢

INSERT INTO article([comment].Value) 
VALUES ('thank you') 
WHERE artID = 1;

但是查詢並不完全揭示實現多值字段的隱藏表的底層結構。

鑑於此（災難，在我看來） - 我的問題是如何幫助新手進行數據庫設計和規範化理解Access提供的內容，爲什麼它可能沒有幫助，並且它不是理由忽略關係模型的基礎知識。更具體地說：

除了上面的查詢之外，還有更好的方法來揭示多值字段背後的結構嗎？
是否有很好的例子說明多值字段不夠好，並且顯示了明確規範化的好處？
是否有直接的方法來獲取Access多值的多選視覺輸出，但基於單獨的顯式表？

謝謝！

來源

2013-01-20 boisvert

多值字段在很多方面與查找相似，所以http://access.mvps.org/access/lookupfields.htm。它們主要對Sharepoint有價值，除非您使用Sharepoint，否則建議通常不會使用它們。用SQL複製表（select into，insert into）也不起作用。對於你的學生來說，這可能是一個很好的時機，可以讓你瞭解應用程序有時會有反功能:) – Fionnuala

我不能給你使用這個功能的建議，因爲我從來沒有使用它;不過，我可以給你理由不要使用它。

我想完全控制我在做什麼。對於多值字段，情況並非如此，因此我不使用它們。
此功能不可擴展。例如，如果你想添加一個日期字段到你的評論？
有時需要將Access（後端）數據庫升遷爲「大」數據庫（SQL Server，Oracle）。這些數據庫不提供這樣的功能。通常，客戶決定使用哪個數據庫。最近我不得不使用Oracle後端將Access應用程序（前端）遷移到SQL-Server後端，因爲我的客戶端決定放棄他的Oracle服務器。因此，限制自己只使用通用功能是個不錯的主意。
對於編輯查找表等常見任務，我創建了通用表單。我現有的解決方案不適用於多值字段。
我有一個（自制）工具，同步在我的開發人員的網站與客戶端的站點數據庫的數據庫結構的變化。該工具無法處理多值字段。
我對安全管理工具，可以授予SELECT，INSERT，UPDATE和DELETE表的權利或吊銷它們。同樣，管理工具不適用於多值字段。
有一個單獨的表的評論允許你快速檢查所有的意見（通過打開表）。你不能用多值字段來做到這一點。
您不會看到文章和數據庫圖表中的註釋之間的1對n關係。
使用單獨的表格可以選擇是否要級聯刪除細節表。如果您不這樣做，只要有附帶評論，您將無法刪除文章。如果你想保護評論不被意外刪除，這可能是可取的。

來源

2013-01-20 17:12:14

謝謝@Olivier - 我有1對n和缺乏控制問題的想法，但您的兼容性示例非常有用。也只是一些有經驗的人的看法 - 不管你信不信，學生們聽到它時都會喜歡權威的聲音。 – boisvert

MS Access在簡化數據庫管理和抽象出很多複雜性方面做得非常出色。然而，這使得學習dbms概念有點困難。你有沒有嘗試過使用其他'標準'dbms工具，比如MySQL（甚至是sqlite）。從學習的角度來看，他們可能會更好。

來源

2013-01-20 16:32:06 Verma

我同意，並且對於視覺前端，我也在考慮Libre Office。但我不認爲我可以完全忽略訪問 - 太知道要避免。有些學生最終會在家中使用它，並且會感到困惑。 – boisvert

Access不僅僅是一個數據庫，它是一個RAD工具，一個報告工具等等，並且不能輕易地被替換，特別是對於小型用戶而言，與市場上的其他單一應用程序一起使用。 – Fionnuala

重要的是要認識到物理和邏輯關係之間的差異。今天，整個互聯網和網絡服務（SOAP）在一種本質上具有多值性的數據格式上非常實現。

當你代表關係數據庫（如Access）多值數據，然後在後臺使用的是傳統的（和合法）的關係。我不能這樣強調，那麼在Access中使用多值列實際上是一個LEGITIMATE關係模型。

表未暴露的事實並不否定此問題。實際上，如果您將發票（主記錄和重複詳細信息）表示爲XML數據立方體，那麼我們會看到兩件事情：

1）您可以使用關係數據庫構建並表示該發票，如Access 2）這樣規範化的關係數據模型也可以表示爲一個單一的xml字符串。 3）刪除XML記錄（或字符串）意味着級聯刪除子行（發票明細）必須發生。

所以，儘管將多值字段添加到Access以處理SharePoint是事實，但認識到這些數據可以映射到關係數據庫是非常重要的（如果您不能這樣做，那麼Access可以不使用關係數據庫表中的XML數據作爲ACCESS當前的權利）。

而且隨着網絡如XML和SharePoint則需要消耗以及管理和利用這些數據不僅分佈廣泛，但實際上是互聯網的一個基本的主食。

隨着越來越多的數據變得越來越複雜，我們發現使用中要求多值數據爆炸。任何使用互聯網所謂「時尚」的人都會依賴和使用實際上非常多的XML，而且本質上是多值（複雜）的數據。

只要邏輯（而不是物理）關係數據模型被保留，那麼就可以使用多值列來表示這樣的數據，這正是Access正在做的事情（它將關係數據模型映射到複雜模型）。請注意，complex（xml）數據模型不一定必須是關係型的。但是，如果您要將這些數據映射到Access，那麼複雜的多值模型必須符合關係數據模型。

這完全是在Access中發生的。

這樣一個正確和合法的數學關係模型沒有暴露的事實在這裏沒什麼問題。我們是否建議，因爲Excel不公開使用的二進制代碼，那麼用戶將永遠不會了解計算機？或者，也許我們都必須編寫彙編程序，以便我們都正確地學習計算機的工作方式。

在一天結束時，誰在乎，爲什麼會這樣？現在人們駕駛自動駕駛汽車的事實並沒有拋棄他們使用不同的齒輪來操作汽車的概念。我們關閉全社會的想法是因爲有人打算駕駛自動汽車，或者在這種情況下使用複雜的數據，這對我們來說太笨了。

因此請記住，SQL中的擴展確實存在於Access中以查詢多值數據，但這裏也指出這些基礎表未公開。但是，如上所述，暴露這樣的表將仍然需要一個不改變或混亂級聯刪除，因爲該功能是必需的維護複雜數據模型（xml）和使用兩個之間的特徵交集和正確的數學關係模型相關表格來表示這些數據。

換句話說，您可以使用相關的表格來表示複雜的數據模型如果您刪除用戶使用參照完整性選項玩的能力。 RI選項必須保持在隱藏表格中設置，否則這些數據將無法將跳閘返回到其消耗的XML或複雜數據模型。

如前所述，關於用戶被教授汽油如何與氧氣反應以學習駕駛汽車，或者使用文字處理器以及被迫學習關係模型以及暴露底層表格在這裏沒什麼意義。

但是，這裏提到的關於這樣的表格暴露的觀點是合理的擔憂。

REAL問題是SQL服務器和Oracle等不能消耗或表示複雜的數據而訪問可以消費這些數據。

如前所述，複雜的數據船在LONG前航行！ XML，soap和互聯網的基本技術都基於這種複雜的數據模型。

在效果上，SQL服務器，Oracle和大多數數據庫不能消耗此多值數據表示它無需用戶具有在關係的方式來創建和模型這樣的數據是SQL服務器等的大的缺點

訪問權獨立於使用此數據的能力。

因此，對於任何使用智能手機，iPad或網絡的用戶，您都在使用基於複雜數據構建的基本技術，這些技術都是Access現在允許的。

由於越來越多的數據本質上是複雜的，很可能其他行業將不得不效仿。如果數據庫行業沒有改變，那麼主流的傳統關係數據庫系統將不會成爲這些數據的休憩處。

現在，遠離在相關表中存儲數據的趨勢正在迅速發展，像SharePoint這樣的產品甚至Google文檔都證明了這一概念。因此，Access只是對市場壓力作出反應，其他數據庫供應商很可能不得不效仿或放棄成爲稱爲互聯網的「時尚」的一部分。

XML和複雜的數據結構是現在的行業和事實 - 這不是一個我們都應該逃避的問題，但實際上是擁抱。

Albert D. Kallal (Access MVP) 
Edmonton, Alberta Canada 
[email protected]

來源

2013-01-21 01:35:48

XML和複雜的數據結構是主要的，我們的數據需求正在發展爲需要這樣的系統，但這並不意味着多值域是最好的響應之一。但我喜歡XML示例 - 這是物理和邏輯之間不同映射的一個很好的例子，它是透明的。 – boisvert

Access mv列缺少其他MV系統（例如）處理xml數據的幾個功能。 MAJOR缺少的功能是在這種xml數據中分配控制列和相關列（這個設置需要用xml數據維護關係模型）。因此，使用正確的關係數據模型來保存XML數據（如訪問一樣）的想法不僅是一個很好的解決方案，而且應該是我們行業中經常使用的一種解決方案。這意味着您可以使用SQL和這種數據的LOGICAL關係視圖，而不是使用DOM和xml庫來操縱這些數據。 –

技術討論很有趣。我認爲真正的問題在於學生的理解。因爲它在Access中可用，學生將使用它，並且最初它可能會爲某些設計問題提供簡單的解決方案。當他們嘗試並使用這些數據時，會在以後發生。也許一個展示問題的簡單例子會說服一些學生避免使用多值域？也許以另一種更可用的格式存儲數據的例子會有所幫助？

祝你好運！

Peter Bullard

來源

2013-01-21 10:06:37 user1996658

很高興收到你的來信Peter :)我可能會努力準備這樣一個例子，可能是涉及「sub」表中多個字段的東西。我簡直無法相信我們必須與沒有實現關係模型的軟件進行鬥爭......再次......實際上，爲多值字段顯式顯示單獨的表格會非常簡單，而且導致同樣好的前端。恥辱。 – boisvert

我知道這個帖子太舊了。但是，它與我在這個主題上看到的其他任何帖子都不盡相同。這個人有一個使用多值字段的好例子...

作爲一個正在嘗試誰仍然努力嘗試讓他們的頭繞過Access的人，我發現討論和反對使用多值字段令人難以置信的挫敗感。

我試圖對所有這些進行排序，但如果每個人都如此反對他們，那麼替代方法是什麼？看起來，在每一個搜索結果中，我發現每個人都在告訴你如何使用多值字段和控件，或者告訴你它有多糟糕，多麼糟糕。許多人提到他們的替代方案，但沒有人說「這是一個例子」。我在這裏瞭解這些事情。雖然我知道這對於這些論壇中的很多人來說是一個更簡單的概念，但我真的可以用一些例子來看看。

我現在正要決定走哪條路。比較使用多值字段和替代方法的示例並使用控件選擇多個值將是一件好事。

或者我錯了，您可以選擇多個項目的組合框的功能只能通過訪問？

來源

2015-03-03 17:59:38 Phrayzur

多值字段的替代方法是其他人所做的，也是沒有人開發具有多值字段的軟件的原因：他們使用鏈接表。如果表格需要多值字段，則需要更多表格。做一個忙，並且不要使用多值字段，當你可以用單獨的表和外鍵更好地做同樣的事情時。 – boisvert

感謝您的回答Boisvert。我不想把自己限制在其他任何地方都不適用的快捷方式，或者從長遠來看讓事情變得更加困難。我將使用鏈表的組合框或列表框？用戶可以看到他們可以選擇多個項目嗎？ – Phrayzur

我想說，這是一個獨立的問題。找到問題的一個例子，如果您的開發技能更直觀，請使用截圖或兩個截圖。 – boisvert

我想先解決您最後的問題。有一種方法可以提供父母子女關係的視覺表達。它被稱爲子表單。如果您在Access中獲得關於子窗體的幫助，它將解釋這個概念。
我已經在一個項目中使用了子窗體，我想在窗體中顯示事務頭並在子窗體中顯示事務的詳細信息。即使數據存儲在兩個標準化表中，也沒有什麼可以阻止這個構造。

當然，這會影響屏幕而不是數據庫。這就是整個問題。規範化與存儲和檢索有關，而不是數據的其他用途。

來源

2017-12-20 15:46:15

規範化和多值字段

回答

相關問題