database-normalization

5熱度

2回答

我是新來的卡桑德拉和正在尋找如何有這種一般結構如下數據模型中的最佳實踐：的數據是基於「用戶」（每用戶），每個提供大約500K-2M條目的大數據文件（每天定期更新幾次 - 有時全部更新，有時只增量）每個數據文件都有一定的強制性數據字段（~20強制），但可以根據他們的判斷增加額外的欄目（最多〜100）。的附加數據字段是NOT必然同爲不同用戶（字段的名稱或類型的那些字段的）實施例（CSV格式:

-1熱度

1回答

將以下關係分解爲BCNF

給定與屬性A，B，C，D，E的關係R以及功能依賴關係A-> B，BC-> E，ED-> A的集合。將其分解爲高正常形式。

-1熱度

1回答

規範和使用主/外鍵的SQL Server 2008 R2

注：我以前從來沒有做過這樣的：有哪些步驟或文檔，以幫助恢復正常數據庫中的表/視圖？目前，數據庫中有多個表和視圖不使用主鍵/外鍵概念，並且在多個表中重複相同的信息。我想清理一下，也有點設置一個進程，保持關係更新。例如，如果一個人的郵編變化或記錄被刪除，那麼它會自動更新其與其他表格行的關係。注意：*我的問題是規範現有的數據庫表。這些表格是現場直播的，所以我如何處理標準化？我是否需要創建一個具有我

2熱度

2回答

實體關係圖冗餘：商店，產品，訂單，類別

我試圖設計一個模型，允許用戶成爲一個賬戶的買方和賣方，但一些老師告訴我，這個圖是錯誤的，因爲它有冗餘。我已經回顧了圖表，但我還沒有找到解決這種冗餘的方法。在表orders我需要知道誰是買家，所以出於這個原因，我沒有從表中刪除這個。一些想法？

-1熱度

1回答

轉換關係到BCNF

R（A B C） AB - > C， Ç - >甲 AB是最小超鍵這是一個候選鍵。 AB - > C很好。但由於素數屬性取決於Non Prime屬性，因此C - > A不成立。我知道如何分解，直到3 NF。我也知道爲什麼關係不在BCNF中。但我不知道如何將這種關係分解爲BCNF。任何人都可以把這個關係分解成BCNF。

-1熱度

1回答

抽象關係模式的正常形式

我想知道關於關係數據庫正常形式的這些考題。在我看來，第一個應該是3NF，第二個是2NF（即第一個應該是錯的）。問題9. [...] C int, D int NOT NULL, UNIQUE (B,C) [...] 我的理由是，由於C是獨一無二的，它也是一個候選鍵，因此一個主屬性。因此，它也是一個超級鍵，因此適合3NF的描述。爲3NF定義：關係模式R是第三範式（3NF）如果，每當一個非平凡函數

0熱度

4回答

不知道這是否構成傳遞依賴

我有點卡住設計數據庫的一部分。我有一張名爲Staff的表格。它具有不同的屬性： StaffID First Name Last Name Job Title Department Number Telephone Number StaffID是此表中的主鍵。但是，我的問題是可以根據電話號碼找到任何信息（即每個工作人員都有不同的唯一電話號碼）。例如，這意味着當我們有Phone N

1熱度

2回答

如果我們更改主鍵值，爲什麼我們不必更改從屬列值？

我看了關於數據庫規範化的one tutorial on youtube。表看起來是這樣的： |Item(PK) | Supplier | Supplier Phone | Price| --------------------------------------------- | Xbox One| Microsoft| 1234 | 250 | -------------------

0熱度

1回答

我的mysql外鍵約束有什麼問題？

我正在開展一個個人項目，並且這是我一生中第一次嘗試創建一個規範化的數據庫（至少在第一個規範化級別）。下面是涉及我的問題的表格： CREATE TABLE `reoccurrences` ( `name` varchar(15) NOT NULL DEFAULT '', `username` varchar(31) NOT NULL DEFAULT '', `amount

-1熱度

1回答

標準化表結構VS平臺結構

我們公司對於平板結構與標準化表結構存在爭議。到目前爲止，我們確實認爲我們有一個規範化的數據庫，並且應用程序可以很好地運行它。但是，報告是由IT人員在客戶端完成的，因爲有時會生成一些臨時報告。有時他很擔心，因爲他無法從簡單的桌子結構中提取細節。他已經升級到管理層，他們也有這樣的印象：高規格化的數據庫並不真正有用。我們該如何捍衛規範化數據庫vs平坦表結構的上下文。任何人都有過這種經歷。