如何設計一個數據庫來存儲屬性，選擇屬性的同義詞

Question

我正在爲一個房地產應用程序設計一個數據庫。事實證明，這比我預期的更多參與（也許我過於複雜）。

的問題本質上是由於存在：

• 同義詞 例如術語：扁平，公寓和複式可以都指基本上，相同類型的屬性
• 屬性（不同的屬性類型有不同的屬性） 例如，一間公寓可能是一樓或頂層等

我已經結束了一個相當（無意）詳細的分類用於不同屬性類型的樹。樹節點是屬性類型的實際實例。

我想創建一個數據庫，以便我不僅可以使用任何同義詞進行查詢，還可以查詢屬性。

因此，例如，該查詢（在僞SQL）：

SELECT *從屬性其中同義詞= 「平坦」 和屬性IN（ '地下'， '花園'）;

應該返回公寓名單|單位是要麼一樓，有一個花園。

有人能幫助我如何設計數據庫模式，以便允許上述類型的查詢？

最後但並非最不重要的是，我將使用MySQl或PostgreSQL作爲後端數據庫，但是如果可能的話，寧願使用db不可知的方法。

Answer 1

要處理同義詞，您可以在包含屬性類型的靜態列表的表和包含同義詞的表之間進行多對多查找。這樣一個同義詞可以映射到多個屬性類型。

例如：

Table:Property Type 
1 House 
2 Appartment 
3 Large House 
4 Cave 

Table:Synonym 
1 house 
2 flat 
3 dwelling 
4 condo 
5 mansion 

Table:PropertyType-Synonym 
1 1 (House is a house 
1 3 (House is a dwelling) 
2 2 (Appartment is a flat) 
2 3 (Appartment is a dwelling) 
2 4 (Appartment is a condo) 
3 1 (Large House is a house) 
3 3 (Large House is a dwelling) 
3 5 (Large House is a mansion) 
4 3 (Cave is a dwelling) 

有關屬性，你可以利用一種開放的屬性結構。

例如：

Table:Property 
1 Apartment F, Field House Gardens 
2 123 Alphabet Street, NumberTown 

Table:Attribute 
1 Is ground floor? 
2 Number of bedrooms 
3 Has garden? 

Table:Property-Attribute-Values 
1 1 No 
1 2 2 
1 3 Yes 
2 2 5 
2 3 Yes 

希望這有助於

Answer 2

我會採取不同的方法，以你的歸屬方案。我不會將不同的屬性視爲同義詞，而是將它們視爲重疊，或者更具體地說，將屬性描述爲嵌套的。這將處理您的商業案例，同時承認Mike Sherrill所做的精明觀察。

這裏是一個快速ERD素描：

通過一個非常快速的數據字典的方式：

PROPERTY是一塊地產。

CATEGORY是描述屬性的集合。這張桌子的重點更多的是作爲屬性的組織者而不是別的。它可能包括諸如「財產類型」，「所有權結構」，「浴室數量」以及其他可能感興趣的內容。

ATTRIBUTE是一個特定的感興趣的質量。請注意此實體類型的漸開線關係。我會在稍後處理更多。重點是屬性可以更一般或更具體，某些屬性可以看作是其他屬性的改進。

DESCRIPTOR是屬性和與該特定房地產相關聯的屬性的交集。

那麼這應該如何幫助？

關鍵是屬性是如何工作的。如果您使用嵌套集模型，則可以解決或多或少的特定歸因和搜索條件。考慮一個潛在類別的下圖與它的相關聯的屬性：

在此示例類別是「型的屬性」。您可以從圖中看到，此類別中存在屬性的分層分解。圖中的每個框都是ATTRIBUTE中的記錄。包含其他框的框具有子屬性。位於另一個盒子內的盒子具有FK到他們的包含盒子等等。

以這種方式，你可以說「我想找到一個屬於閣樓的房產」。然後，您可以找到PROPERTY記錄，並在相關DESCRIPTOR中指向「閣樓」屬性。這很容易。但是如果你的搜索是空的呢？

這種方法的好處在於，您可以通過說「讓我們把歸因層次歸結爲下一個不是複雜的東西」來放鬆您的標準。在我的例子中，這將是「高層」。現在你再次嘗試你的搜索，你可能會有更好的運氣。

像這樣的系統可以讓您在每種歸因類別中按照自己的需要進行具體化處理，同時讓其他人放鬆到足以開始獲得搜索結果。這真的是一個房地產經紀人的工作是關於不是？幫助客戶做出必要的妥協，找到最符合其最重要標準的方法？

處理嵌套集合

這種做法的唯一棘手的部分是如何處理嵌套組。有很多方法可以做到這一點，其中許多方法已在其他地方完整記錄。我自己喜歡visitation number技術，特別是對於相對靜態的數據集。這使得查找某些給定的ATTRIBUTE或其任何子節點的匹配變得非常容易，而無需在SQL中執行任何異常處理。

編輯：那麼這是如何工作的？

OP問你如何處理臥室數量和查詢的樣子是什麼？讓我們再舉一個例子來加以說明：

上面顯示了嵌套集合類別「臥室數量」。我還將訪問數字添加到圖表中。請注意訪問數字的工作方式，特別要注意，任何給定屬性值的左（綠）和右（紅）數字都包含任何下屬屬性的左側和右側訪問數字。例如，「2+臥室」分別有左和右數字6和15。屬於「2+臥室」的每個屬性都有落在此範圍內的左側和右側數字。

那麼如何查詢給定描述符的屬性？假設我們想要找到所有擁有兩間或更多臥室的房產。對於這樣一個查詢的SQL可能是這個樣子：

select P.* 
from PROPERTY P 
    inner join DESCRIPTOR D 
    on P.id = D.property_id 
    inner join ATTRIBUTE A 
    on D.attribute_id = A.id 
where A.left >= (select X.left from ATTRIBUTE X 
       where X.name = '2+ Bedrooms') 
    and A.right <= (select Y.right from ATTRIBUTE Y 
        where Y.name = '2+ Bedrooms') 

注意上面的查詢是有一點不同的是你可能會真正使用。例如，您可能會使用其int標識鍵而不是其字符串名稱查找過濾屬性。不過，我認爲我會留下它作爲主要觀點的清晰圖示，通過查看而不是來了解特定的相關屬性，但對於屬於您的過濾器範圍的任何相關屬性進行過濾。

如果您想過濾多個屬性，那麼只需在where子句中添加更多子子句。