規劃搜尋的中繼資料屬性 (SharePoint Server 2010)
適用版本： SharePoint Server 2010
上次修改主題的時間： 2012-01-30
本文描述如何在 Microsoft SharePoint Server 2010 規劃要搜尋的中繼資料屬性。編目內容時，編目程式也會編目與該內容相關的中繼資料，例如，作者、標題以及電子郵件地址等資訊。搜尋系統將此資訊儲存為「編目屬性」以及「Managed 屬性」。編目屬性全部都是編目時從文件擷取的屬性 (例如作者、標題或主旨)，Managed 屬性是可以顯示在精簡或進階搜尋中的編目屬性。當使用者執行一般搜尋時，結果會包含有任何編目屬性的項目。不過，為了提供精簡搜尋功能給使用者，您需要規劃 Managed 屬性。因為這些屬性可以顯示在精簡搜尋中，所以 Managed 屬性可以幫助使用者執行更成功、更切題的查詢。SharePoint Server 2010 提供一組預設的 Managed 屬性，但是您可以建立新的 Managed 屬性，然後將編目屬性對應至將顯示在搜尋結果中的 Managed 屬性。
精簡搜尋只能應用於 Managed 屬性，而不能應用於編目屬性。為使編目屬性能運用精簡搜尋查詢，您必須將編目屬性對應至 Managed 屬性。您可以將多個編目屬性對應到單一 Managed 屬性，或將單一編目屬性對應至多個 Managed 屬性。如果有多個編目屬性對應到某個 Managed 屬性，且某文件包含多個編目屬性的值，則對應這些屬性的順序及其優先順序，將會決定 Managed 屬性的值。
例如，三個不同的文件類型可能分別使用不同的屬性名稱來識別作者。一個文件類型可能將此屬性命名為 Author，另一個可能命名為 Writer，而第三個可能為 Property3。雖然這三個都是編目屬性，但是當使用者依作者執行查詢時 (例如，在搜尋方塊中輸入 author:John Smith)，只有擁有 Author 屬性的文件才會顯示在搜尋結果中。若要確定擁有其他屬性名稱的文件會顯示在精簡搜尋結果中，您必須將這些編目屬性逐一對應至 Author Managed 屬性。
本文內容：
關於 Managed 屬性
減少重複的 Managed 屬性
在資訊結構中新增重要概念的屬性
案例
關於 Managed 屬性
若要建立一組有用的 Managed 屬性，您可以分析最重要的內容，從而找出內容中可以對應至 Managed 屬性的中繼資料。
如果不先編目內容，要探索內容屬性是件相當困難的工作。因此，我們建議您先了解每一個網站集合中的內容，再開始規劃 Managed 屬性。然後，您可以使用測試伺服器，編目所有這類的內容。編目之後，您會有一個編目屬性清單，可以在您建立 Managed 屬性時用來與資訊結構進行比較。即使系統編目之後，對應屬性也不是件輕鬆的事，這是因為不容易識別使用屬性的內容類型或應用程式。如果您不確定某個特殊的屬性，可以在測試環境中設定對應，然後測試搜尋這個屬性。
安裝 SharePoint Server 2010 時，會自動建立許多最有用的 Managed 屬性。規劃其他 Managed 屬性時，可以將這些 Managed 屬性當作起點。自動建立的屬性包含：
作者
描述
網站名稱
類型
檔案大小
上次修改日期
URL
標題
請記住，為了利用屬性進行有效的搜尋，必須先指派編目屬性的值。例如，如果您有一份 Microsoft Word 2010 文件包含 Author 屬性 (對應至名稱為 Author 的 Manage 屬性)，但是該份文件上的 Author 屬性沒有任何指派的值，則當使用者利用 Author 屬性進行查詢時，文件不會顯示在搜尋結果中。若要保證精簡搜尋的最佳結果，請考慮實作一套包含文件中繼資料規劃在內的企業內容管理解決方案。如需有關文件中繼資料規劃的詳細資訊，請參閱＜規劃受管理的中繼資料 (SharePoint Server 2010)＞和＜規劃內容類型與工作流程 (SharePoint Server 2010)＞。如需有關規劃企業內容管理解決方案的詳細資訊，請參閱＜企業內容管理規劃 (SharePoint Server 2010)＞。
如需有關管理中繼資料屬性的資訊，請參閱＜管理搜尋的中繼資料屬性 (SharePoint Server 2010)＞。
減少重複的 Managed 屬性
部分基本屬性可能會在不同的內容類型中顯示為不同的編目屬性。例如，編目屬性可能是 Owner、Writer 以及 Created By，這些都是 Author 的同義字。您可以做到而且最重要的事就是規劃減少重複現象。也就是說，規劃建立一組 Managed 屬性，並將意義相同的編目屬性對應至 Managed 屬性。在這種情況下，可將 Owner、Writer 以及 Created By 對應至 Managed 屬性 Author。
您可以排列多個編目屬性的優先順序，如此若在編目時找到多個屬性，只有最高優先順序的屬性值會用於使用一或多個 Managed 屬性的查詢。如果未排列編目屬性的優先順序，則對應至 Managed 屬性的所有編目屬性值都會用於查詢。如此一來，Managed 屬性會變成多重值。這表示查詢結果會傳回包含任何對應屬性值符合查詢的所有內容。合理的單一值屬性方法是挑選最常用的編目屬性當作 Managed 屬性，然後依照出現的頻率，排列對應屬性的優先順序。要判斷最常編目的屬性並不簡單，不過有一個策略是排列您知道與常用應用程式相關之屬性的優先順序。例如，Microsoft Office 2010 文件包含一組預設屬性，像是 Author、Title、Company、Type 等等。如果大部分的使用者都使用 Microsoft Office 2010，而且您的內容集也包含利用其他應用程式建立的文件，可考慮將其他應用程式建立之文件中的屬性對應至 Office 2010 文件中的屬性。如果其他應用程式建立的文件包含 Writer 這個屬性，請考慮將它對應至 Author Managed 屬性。
對應屬性時務必小心，避免出現不正確或無關的屬性對應。這是因為不精確的對應會降低搜尋結果的關聯性。例如，將 Last saved by 屬性對應至 Author Managed 屬性時，會得到較無關聯的搜尋結果。如果可能，請在首次部署之前測試 Managed 屬性的搜尋，然後計劃在一般作業期間檢閱搜尋查詢的使用資料，以便調整對應的屬性。如需有關檢閱搜尋查詢的使用資料詳細資訊，請參閱＜檢視 Web Analytics 報告 (SharePoint Server 2010)＞。
在資訊結構中新增重要概念的屬性
除了預設對應至 Managed 屬性的編目屬性之外，其他編目屬性可能會清楚對應至資訊結構中由現有 Managed 屬性擷取的概念。例如，有一家公司可能將客戶服務當作其資訊結構中的重要商務程序。與資訊結構中客戶服務相關的重要概念可以包含客戶、客戶服務代表以及客戶服務區域。
至於資訊結構中的每一個概念，想想看有沒有可以代表這個概念的編目屬性可以對應至 Managed 屬性。如果有，將該屬性變成 Managed 屬性。
案例
企業營運應用程式會追蹤客戶和員工資料，當該資料的屬性在商務資料目錄中註冊並編目為商務資料內容來源之後，就成為 Managed 屬性可能的候選字。您也可以尋找應該對應至這些 Managed 屬性的應用程式編目屬性，例如，獨立資料應用程式中的客戶服務代表識別碼 (ID) 屬性，或者是客戶服務代表專用的應用程式類型 Author 屬性。如果搜尋查詢使用該屬性或是與該屬性相關的字詞，搜尋結果將包含對應至客戶服務代表識別碼 Managed 屬性之任何編目屬性的所有項目。
資訊結構中所識別的每一個主要商務程序都有一組相關的檔案類型或商務資料應用程式，可用來探索可能的 Managed 屬性。
請注意，雖然資訊結構中有許多概念不是由屬性來代表，但是在網站結構規劃以及實作其他搜尋功能時，這些概念都很實用。這個資訊結構可以找出您忽略的 Managed 屬性。不過，正因為只是資訊結構中所列的一個概念，不表示這個概念應該要有 Managed 屬性。
See Also
Concepts
收集目前搜尋環境的相關資訊 (SharePoint Server 2010)
決定企業搜尋團隊與專案關係人 (SharePoint Server 2010)
規劃編目與同盟 (SharePoint Server 2010)
規劃企業搜尋拓撲 (SharePoint Server 2010)
Plan people search (SharePoint Server 2010)
規劃搜尋範圍 (SharePoint Server 2010)