連接表和標準化問題

我很難弄清楚以下設計模式是否可以接受。我有一個關係模型以下要求（和其他一些更多）：連接表和標準化問題

1）它必須能夠代表應用程序（如AppA，AppB，AppC），每一個與它自己的屬性集。 2）每個應用程序都可以通過不同的渠道進行溝通，如Internet（E-Mail，Twitter，Facebook），Phone（短信，彩信等），這樣程序和頻道之間就有了多對多的關係。

3）有一組預定義的標識符（地址，電話號碼，登錄賬號）可以被許多程序共享，所以程序和標識符之間也存在多對多的關係。

4）相同的標識符可以發送幾種類型的消息，程序（也是多對多）也可以發送，但我需要能夠限制每個應用程序使用通信類型的標識符基礎。

基本上，我所做的就是創建四個表，Program，Channel，Ident和CommunicationType存儲關於這些信息，而不是爲(Program, Channel)創建結表，(Program, Identifier)，等這將只是複雜的設計，我創建了一個由這四個表的主鍵組成的唯一表，並在(Program, Channel, Ident, CommunicationType)上有一個唯一約束。現在，該表的每個記錄都與給定的通信鏈接。

當然，這可以用一種非常簡單的方式解決我的問題，但是現在我正在質疑自己是否可以接受所有違反規範化原則的問題。任何人都可以給我一個意見嗎？

來源

2011-07-02 User

基本上，我所做的就是創建四個表，程序，渠道，訂貨號和CommunicationType存儲關於這些和信息，

這是個好主意。

，而不是創建結表爲（方案，信道），（方案，標識符），等這將只是使設計複雜化，我創建單個表包括以下各項的主鍵這四個表在上有一個唯一的約束（程序， Channel，Ident，CommunicationType）。

當你設計這樣的表格時，你需要小心一件事。您的結構（程序，通道，標識，通訊類型）允許程序和通道，程序和通訊類型的通道和標識的各種可能組合，等等。有時候這是一個壞主意。

同樣的標識符可以發送多個類型的消息，因此可以在程序（再次，許多到多），但我需要能夠限制的標識符使用通訊鍵入每個應用程序的基礎上。

而這就是一個壞主意。您似乎在說並非Ident，Program和CommunicationsType的每個組合都是有效的。

將有效組合存儲在其自己的表中。使用外鍵引用來維護數據完整性。

建立一個擁有密鑰{Program，Ident，CommunicationsType}的表格。具有關鍵字{Program，Channel，Ident，CommunicationType}的表可以爲其設置外鍵引用。

構建儘可能多的表來實現您所知道的所有約束。更多的表格意味着數據完整性檢查更簡單。（你可能需要比我提到的更多的表格，不要以爲他們需要有兩列;他們可能需要更多）。

你完全不清楚你需要一個表格鍵{Program，Channel}。但如果你這樣做，那麼你需要根據這些線建立表格。（空氣代碼）

create table pc (
    program_name varchar(10) not null references programs (program_name), 
    channel_name varchar(10) not null references channels (channel_name), 
    primary key (program_name, channel_name) 
); 

create table pict (
    program_name varchar(10) not null, 
    channel_name varchar(10) not null, 
    comm_type varchar(10) not null references communication_type (comm_type), 
    primary key (program_name, channel_name, comm_type), 
    foreign key (program_name, channel_name) 
     references pc (program_name, channel_name) 
); 

create table your-table-name (
    program_name varchar(10) not null, 
    channel_name varchar(10) not null, 
    comm_type varchar(10) not null, 
    ident varchar(10) not null, 
    primary key (program_name, channel_name, comm_type, ident), 
    foreign key (program_name, channel_name, comm_type) 
     references pict (program_name, channel_name, comm_type), 
    foreign key (ident) references ident (ident) 
);

根據需要添加其他欄。在某些情況下，您可能會發現需要重疊的外鍵。我不認爲你在這裏需要他們，但我可能是錯的。

我不確定你的意思是「如果它破壞了正常化的原則」。具有四列主鍵的表格並不違反任何正常形式，僅僅因爲這個原因，儘管它可能是出於其他原因。未能實現所有已知的約束通常是這個次優設計，但並不是因爲它違反了任何正常的形式。

來源

2011-07-03 00:31:13

+1。非常感謝你的回答！我想我會遵循這個設計。你是對的，我的意思是並不是'{Program，Ident，CommunicationType'的每個組合都是有效的。而且我還需要一個表格{Channel，Program}，因此我再次感謝您的設計。 – User

對不起，爲您提供一個需要更多信息的答案。我在這一點上的聲譽不允許任何評論...

基於解釋我可以看到沒有選錯的設計。

但是，要真正回答你的問題，理解你爲什麼選擇這種設計將是有用的。

畢竟它也可以在沒有單個表的情況下使用所有鍵和複合唯一索引。將所有組合鎖定在這種方式是相當嚴格的。

當您找到通訊時，您仍然需要與其他一個或多個表格連接才能訪問組成通訊的信息。

爲什麼你想要以這種方式存儲每條獨特的通信路徑？

來源

2011-07-02 23:59:10 HighCs

+1。非常感謝你的回答！我的目標是不在任何地方存儲冗餘信息，所以我真的很依賴表之間的連接。 – User

我不會這樣做。

我會創建表的每對（或n元組）之間的一個結點的表。這將允許最終更簡單的查詢，並且還允許您在每種情況下根據需要以適當的方式限制行，而與其他行無關。

你也可能會發現額外的屬性，需要在這些路口，就像從一個軟件到另一個，什麼是被訪問等方向性，有效載荷，使用語言，查詢點

來源

2011-07-03 00:10:50 Randy

+1。你是對的，現在我看到這不是一個好主意。非常感謝。 – User

連接表和標準化問題

回答

相關問題