2011-05-01 45 views
6

我目前的項目是一個帶布爾檢索功能的高級標籤數據庫。記錄被查詢與(在音樂數據庫例如)布爾表達式像這樣:爲緩存原因規範化布爾表達式。有沒有比真值表更有效的方法?

funky-music and not (live or cover) 

應該得到所有時髦的音樂在音樂數據庫,但不居住或歌曲的翻唱版本。

當涉及到緩存時,問題是存在相同但查詢結構不同的查詢。例如,將德,摩根的規則,上面的查詢可以這樣寫:

funky-music and not live and not cover 

緩存將通過散列查詢字符串,例如執行時會產生完全相同的記錄,但事業突破的緩存。

因此,我的第一個意圖是創建一個查詢的真值表,然後可以用作緩存鍵作爲等價表達式形成相同的真值表。不幸的是,這是不可行的,因爲真值表隨着輸入數量(標籤)呈指數增長,我不想限制一個查詢中使用的標籤數量。

另一種方法是遍歷應用由布爾代數定義的規則的語法樹,以形成(最小)規範化表示,這似乎也很棘手。

因此,總體問題是:是否有一種可行的方法來實現等效查詢的識別,而不需要circuit minimization或真值表(編輯:或任何其他算法是NP-hard)?

ne plus ultra會識別已經緩存的子查詢,但這不是主要目標。

+0

使用按位鍵 - 例如。設置位0如果時髦|位6 0 =住/ 1 =工作室|位8 rap |位9彈出 然後您使用按位操作來確定查詢 上的密鑰表示是否有意義? – Dan 2011-05-01 14:50:49

+0

這是移動設備API中的一種常見模式 - createScreen(long style_element),其中long style_element是所述按位操作的最終結果,並且爲所述Screen對象指定了無盡的(真正的lol)樣式元素 – Dan 2011-05-01 15:31:09

+0

這將是一種內存有效的方式將信息存儲在數據庫中。但這是一個完全不同的話題。 – user733321 2011-05-01 17:38:46

回答

1

確定查詢是否等價於「False」的通用高效算法可用於有效解決NP完全問題,因此您不可能找到一個。

您可以嘗試將您的查詢轉換爲規範形式。由於上述原因,總會有一些查詢花費很大的代價來轉換成任何給定的形式,但是您可能會發現,在實踐中,某種形式在大多數情況下運行得相當好 - 而且您總是可以放棄一半如果變得太難了,就要轉型。

你可以看看http://en.wikipedia.org/wiki/Conjunctive_normal_form,http://en.wikipedia.org/wiki/Disjunctive_normal_form,http://en.wikipedia.org/wiki/Binary_decision_diagram

+0

創建你提到的那些形式涉及創建一個真理表也。因此,我可以簡單地使用真值表的歸一化形式(輸入和組合排序)的散列作爲緩存鍵。似乎最好的方式是爲查詢覆蓋少於10個標籤的查詢創建「最優」散列,而對於具有更多標籤的查詢則使用更簡單但不是最佳的算法。 – user733321 2011-05-01 17:51:11

+0

你應該能夠純粹象徵性地獲得任何這些形式。給出任何這兩種形式的任何兩個表達式,您可以通過AND或OR來計算出這些表達式的結果,並且結果將以相同的形式出現。你可以用NOT來做同樣的事情。在某些情況下,結果會很複雜,但這是可能的。對於BDD,應該有庫來做到這一點 - 參見例如http://javabdd.sourceforge.net/apidocs/net/sf/javabdd/BDD.html。因此,您可以通過組合各個變量的表示來構建表示。 – mcdowella 2011-05-01 18:47:07

+0

但我不明白這將如何規避NP完全算法​​的需要。 – user733321 2011-05-02 12:46:41

1

您可以將查詢轉換爲連接標準形式(CNF)。它是布爾公式的典型簡單表示,通常是SAT求解器的基礎。

最有可能的「大」查詢會有很多連詞(而不是很多的disjunctions),所以CNF應該很好地工作。

+0

那麼構建一個'不是最壞情況查詢'的CNF會不會比NP複雜?你有沒有參考如何實施轉換?常見的算法似乎涉及太複雜的真值表。 – user733321 2011-05-02 12:51:49

+0

我會說,是的。見http://en.wikipedia.org/wiki/Conjunctive_normal_form – 2011-05-02 19:37:13

相關問題