『壹』 sqlServer里「多維和數據挖掘模式」和「表格模式」到底是什麼意思
表格、 多維和數據挖掘是SQLServerAnalysis Services 提供用於創建商業智能語義模型的兩種方法，還有一種方法是Power Pivot for SharePoint。
可以使用多種方法來實現針對不同業務和用戶需求量身定製的建模體驗。「多維」是建立在開放標准基礎之上的成熟技術，已由 BI 軟體的眾多供應商採用，但難以駕馭。「表格」提供一種關系建模方法，很多開發人員認為它更加直觀。
所有模型將部署為在 Analysis Services 實例上運行的資料庫，可以使用一套數據提供程序通過客戶端工具來訪問，並通過 Excel、Reporting Services、Power BI 和其他供應商的 BI 工具在互動式靜態報告中可視化。
表格和多維解決方案使用 SSDT 構建，旨在用於在獨立上運行的公司 BI 項目Analysis Services實例在本地和表格模型中，Azure Analysis Services中的伺服器雲。這兩個解決方案將生成可與 BI 客戶端輕松集成的高性能分析資料庫。然而，每個解決方案在創建、使用和部署方式上都存在不同。本主題的大部分內容比較了這兩種類型，以方便你找到適當的方法。
『貳』 多維資料庫是什麼
多維資料庫（Multi Dimensional Database,MDD）可以簡單地理解為：將數據存放在一個n維數組中，而不是像關系資料庫那樣以記錄的形式存放。因此它存在大量稀疏矩陣，人們可以通過多維視圖來觀察數據。多維資料庫增加了一個時間維，與關系資料庫相比，它的優勢在於可以提高數據處理速度，加快反應時間，提高查詢效率。
目前有兩種MDD 的OLAP產品：基於多維資料庫的MOLAP和基於關系資料庫的ROLAP。ROLAP建立了一種新的體系，即星型結構。
MDD並沒有公認的多維模型，也沒有像關系模型那樣標准地取得數據的方法(如SQL、API等)。基於MDD的OLAP產品，依據決策支持的內容使用范圍也有很大的不同。
在低端，用戶使用基於單用戶或小型LAN的工具來觀察多維數據。這些工具的功能性和實用性可能相當不錯，但由於受到規模的限制，它們不具備OLAP的所有特性。這些工具使用超立方結構，將模型限制在n維形態。當模型足夠大且稀疏數據沒有控制好時，這種模型將會不堪一擊。這些工具使用資料庫的大小是以MB來計量的，而不是以GB計量的，因此只能進行只讀操作，且具備有限的復雜計算。
在高端，OLAP工具用4GL提供了完善的開發環境、統計分析、時間序列分析、財政報告、用戶介面、多層體系結構、圖表等許多其他功能。盡管不同的OLAP工具都使用了它們自己的多維資料庫，但它們在不同程度上也利用了關系資料庫作為存儲媒體。因為關系資料庫和OLAP工具同時在高端伺服器上處理，所以速度和效率仍然很快。
純多維資料庫引擎也被開發出來。盡管這些工具缺乏4GL及充分的開發環境，但卻有比高端MDD工具所使用的資料庫更為復雜的資料庫。這些工具也具有統計分析、財務分析和時間序列分析等功能，並有自己的API，允許其對前端的開發環境開放。
MDD能提供優良的查詢性能。存儲在MDD中的信息比在關系資料庫中的信息具有更詳細的索引，可以常駐內存。MDD的信息是以數組形式存放的，所以它可以在不影響索引的情況下更新數據。因此MDD非常適合於讀寫應用。
『叄』 SQL Server 2008 在多維資料庫方面有哪些功能上的改進
1、聚合設計方面的改進：
• 新的聚合設計器。新的聚合設計器更便於瀏覽和修改聚合設計。現在，聚合設計在顯示時按度量值組分組。現在，為高級用戶提供了一個用來進行手動聚合設計的新視圖。
• 經過簡化和增強的聚合設計和基於用法的優化向導。使用這些經過更新的向導，您可以一次修改一個或多個分區中聚合的存儲設置並且更方便地設置聚合用法設置。基於用法的優化向導現在還允許您將新聚合追加到現有聚合。
• 新的 AMO 警告。當用戶偏離聚合設計最佳實踐時，會以這些新的警告消息向用戶發出警報。
2、多維數據集方面的改進：
多維數據集向導已經得以簡化和增強。這些改進可幫助您用更少的步驟創建更好的多維數據集。
3、維度設計方面的改進：
• 新的屬性關系設計器。該維度編輯器具有新的屬性關系設計器，這個新設計器更便於瀏覽和修改屬性關系。
• 新的 AMO 警告。當用戶偏離設計最佳實踐或在資料庫設計中出現邏輯錯誤時，會以這些新的警告消息向用戶發出警報。
• 經過簡化和增強的維度向導。這個最新版本的向導可自動檢測父子層次結構，提供更安全的默認錯誤配置，並支持成員屬性的規范。
• 新的「鍵列」對話框。使用這個新的對話框，可以更輕松地編輯鍵列。
• 「屬性」面板中的鍵列支持。現在，可以在「屬性」面板中編輯鍵列。
• 經過更新的「維度結構」選項卡。此選項卡現在可用於新的屬性關系設計器，並且更加易於使用，從而可以更方便地修改屬性和層次結構
4、Analysis Services 中的備份和還原功能上的改進
Analysis Services 中的備份和還原功能具有新的存儲結構，所有備份和還原方案的性能都有所改善。
5、改進的存儲結構
新的存儲結構為存檔的資料庫提供更可靠的存儲庫。使用新的存儲結構，對資料庫文件的大小將不存在實際限制，對資料庫所能存儲的文件數量也沒有限制。
6、改進的性能
新的備份和還原功能使性能得到了改進。對不同大小的資料庫以及各種數量的文件的測試表明，性能有了顯著的提高。若要獲取特定需求下的實際值，建議您針對自己的資料庫執行測試。
7、Analysis Services 個性化擴展性方面的改進
使用 Analysis Services 個性化擴展，開發人員可以創建新的 Analysis Services 對象和功能，並在用戶會話的上下文中動態提供這些對象和功能。開發人員無需創建有關查找該擴展功能的地點或方式的詳細規范。相反，開發人員可以立即與最終用戶和其他開發人員共享這些新的對象和功能。
8、新示例位置的改進
聯機叢書不再提供 SQL Server 示例資料庫和示例應用程序。這些示例資料庫和示例應用程序現在位於 SQL Server Samples（SQL Server 示例）網站上。該網站便於用戶查找這些示例，還提供了與 Microsoft SQL Server 和商業智能相關的其他新示例。在 SQL Server 示例網站上，您可以執行下列操作：
• 瀏覽由開發人員、用戶和 Microsoft 最有價值專家 (MVP) 社區提供的示例。
• 下載示例資料庫和代碼項目。
查看或參與討論區，您可以在討論區報告和詢問與各技術領域的示例相關的問題。
『肆』 殺神求教mysql資料庫多維表設計思路
把它解釋的通俗化你應該就會了：
a、b、c、d。。。理解為各個學生（有性別，班級等屬性）
A、B、C、D。。。理解為各門選修課程（有學分，任課教師等屬性）
一共三個表
表1：a、b、c、d。。。每個一行，a、b、c、d。。。作主鍵
表2：A、B、C、D。。。每個一行，A、B、C、D。。。作主鍵
表3：學生跟課程混編（以學生+課程 共同決定成績等屬性），a、b、c和A、B、C均不能作主鍵或UNQUE鍵
『伍』 Hyperion essbase入門（二）什麼是essbase
（大意是你可以把essabase想像成多張疊起來的excel表格，不僅僅在單張excel上可以進行表格之間的各種運算，在多張excel表格之間也可以做各種累計運算！） 這個大概是為什麼essbase能夠和excel工具深度集成的原因，因為essbase很多設計都是來源於excel等工具對於分析的限制和不足。但是excel不失為essbase的一個非常友好的前端，對於非常習慣使用Excel工具的業務人員，他們可以非常容易地使用和分析essbase里的數據，Oracle里關於Essbase賣點的一個經常使用的場景是：當業務人員把數據放在多種表格的時候，到了最後他都不知道哪張表格的數據是最新的，而如果把所有的數據都放在essbase里的時候，你可以輕易地得到最新的數據並且分析數據和數據之間的關系。 和傳統的oltp類型的資料庫不一樣，oltp用實體和關系來描述對象，而多維資料庫，則使用度量和維度來描述對象。在做多維設計的時候，其實就是考慮關於度量和維度的設計，比如銷售額就是一個典型的度量，而銷售地區就是一個典型的維度，但是在essbase里，度量也是一種特殊的維度，叫account維度，這個是和有些OLAP伺服器概念上有所區別的，這樣的定義方式能夠很方便地使用維度的操作方式訪問度量，而且應該說在MDX這種標准多維查詢語言里，度量和維度的確沒有本質的區分。
Essbase的一般設計對於MOLAP資料庫一個通常的觀念是MOLAP不能存儲很大的數據量，當essbase以BSO（塊存儲）來存儲多維數據的時候（傳統方式），則稱之為Essbase Analytic mole，這種傳統方式對於維度數據非常多，數據量非常龐大的時候的處理性能一般，這個也是造成許多人認為MOLAP多維資料庫不適合分析非常大量的數據的方式的緣由，但是BSO存儲方式能夠更好地支持大量回寫的應用，如what-if分析，並且能夠提供更好的分析功能。
當數據量很大或者多於10個維度的時候，essbase建議使用ASO聚合存儲方式來壓縮存儲的數據（據說性能在這種方式下能夠快幾十倍，而存儲量能減少幾十倍），使用這種存儲方式就稱之為Enterprise Analytic Mole，從而提供了修正這種MOLAP大數據量限制的很好的方式。這種存儲方式用於分析維度數量比較多，同時並非每個維度的數據都很稠密的時候是性能會非常好，可以處理大量的數據，這兩種不同的存儲，對於上層應用透明，在同一個應用里可以混合使用。
多維資料庫的設計（維度和度量）在essbase里稱之為outline，以.otl的後綴存儲，一個典型的多維資料庫設計過程是包括：先需要通過admin console創建一個outline。
（其實essbase提供了非常豐富的api介面，也可以使用api來創建和修改outline） 在outline里定義維度和層次和累計方式，然後就是通過admin console編輯數據載入規則來把外部數據按照設計好的outline載入到essbase資料庫里。
載入規則基本上有三種方式：
一是通過文本文件載入。二是通過Open sql的方式從ODBC數據源載入。最後一種是使用ETL工具進行載入。 然後使用計算腳本計算生成立方體里的其他所需要的數據，就可以通過excel或者BI工具來訪問和分析多維資料庫里的數據了。
『陸』 如何從資料庫中導出多維表
關系型資料庫中不支持多維表結構，你說的結果從傳統的關系型資料庫中實現不了。
但是oracle10g可是使用面向對象的定義實現你說的目的，實現方法很麻煩，你上網上查查，時間有限就不跟你說了。
希望對你能有點啟發。
『柒』 為了便於多維分析，在設計數據倉庫時要考慮哪些問題
由於資料庫通常用於操作型系統管理數據，是面向某個具體應用的，所以現在的資料庫設計大多採用以關系數據模型為主的設計方法，以保證數據的原子性、一致性，消除數據冗餘。常常先通過對需要處理的數據進行詳細分析後建立ER模型（實體-聯系模型）
『捌』 數據倉庫和多維資料庫的區別在哪裡
簡而言之，資料庫是面向事務的設計，數據倉庫是面向主題設計的。
資料庫一般存儲在線交易數據，數據倉庫存儲的一般是歷史數據。
資料庫設計是盡量避免冗餘，一般採用符合範式的規則來設計，數據倉庫在設計是有意引入冗餘，採用反範式的方式來設計。
資料庫是為捕獲數據而設計，數據倉庫是為分析數據而設計，它的兩個基本的元素是維表和事實表。維是看問題的角度，比如時間，部門，維表放的就是這些東西的定義，事實表裡放著要查詢的數據，同時有維的ID。
單從概念上講，有些晦澀。任何技術都是為應用服務的，結合應用可以很容易地理解。以銀行業務為例。資料庫是事務系統的數據平台，客戶在銀行做的每筆交易都會寫入資料庫，被記錄下來，這里，可以簡單地理解為用資料庫記帳。數據倉庫是分析系統的數據平台，它從事務系統獲取數據，並做匯總、加工，為決策者提供決策的依據。比如，某銀行某分行一個月發生多少交易，該分行當前存款余額是多少。如果存款又多，消費交易又多，那麼該地區就有必要設立ATM了。
顯然，銀行的交易量是巨大的，通常以百萬甚至千萬次來計算。事務系統是實時的，這就要求時效性，客戶存一筆錢需要幾十秒是無法忍受的，這就要求資料庫只能存儲很短一段時間的數據。而分析系統是事後的，它要提供關注時間段內所有的有效數據。這些數據是海量的，匯總計算起來也要慢一些，但是，只要能夠提供有效的分析數據就達到目的了。
數據倉庫，是在資料庫已經大量存在的情況下，為了進一步挖掘數據資源、為了決策需要而產生的，它決不是所謂的「大型資料庫」。那麼，數據倉庫與傳統資料庫比較，有哪些不同呢?讓我們先看看W.H.Inmon關於數據倉庫的定義:面向主題的、集成的、與時間相關且不可修改的數據集合。
「面向主題的」:傳統資料庫主要是為應用程序進行數據處理，未必按照同一主題存儲數據;數據倉庫側重於數據分析工作，是按照主題存儲的。這一點，類似於傳統農貿市場與超市的區別—市場裡面，白菜、蘿卜、香菜會在一個攤位上，如果它們是一個小販賣的;而超市裡，白菜、蘿卜、香菜則各自一塊。也就是說，市場里的菜(數據)是按照小販(應用程序)歸堆(存儲)的，超市裡面則是按照菜的類型(同主題)歸堆的。
「與時間相關」:資料庫保存信息的時候，並不強調一定有時間信息。數據倉庫則不同，出於決策的需要，數據倉庫中的數據都要標明時間屬性。決策中，時間屬性很重要。同樣都是累計購買過九車產品的顧客，一位是最近三個月購買九車，一位是最近一年從未買過，這對於決策者意義是不同的。
「不可修改」:數據倉庫中的數據並不是最新的，而是來源於其它數據源。數據倉庫反映的是歷史信息，並不是很多資料庫處理的那種日常事務數據(有的資料庫例如電信計費資料庫甚至處理實時信息)。因此，數據倉庫中的數據是極少或根本不修改的;當然，向數據倉庫添加數據是允許的。
數據倉庫的出現，並不是要取代資料庫。目前，大部分數據倉庫還是用關系資料庫管理系統來管理的。可以說，資料庫、數據倉庫相輔相成、各有千秋。
補充一下，數據倉庫的方案建設的目的，是為前端查詢和分析作為基礎，由於有較大的冗餘，所以需要的存儲也較大。為了更好地為前端應用服務，數據倉庫必須有如下幾點優點，否則是失敗的數據倉庫方案。
1.效率足夠高。客戶要求的分析數據一般分為日、周、月、季、年等，可以看出，日為周期的數據要求的效率最高，要求24小時甚至12小時內，客戶能看到昨天的數據分析。由於有的企業每日的數據量很大，設計不好的數據倉庫經常會出問題，延遲1-3日才能給出數據，顯然不行的。
2.數據質量。客戶要看各種信息，肯定要准確的數據，但由於數據倉庫流程至少分為3步，2次ETL，復雜的架構會更多層次，那麼由於數據源有臟數據或者代碼不嚴謹，都可以導致數據失真，客戶看到錯誤的信息就可能導致分析出錯誤的決策，造成損失，而不是效益。
3.擴展性。之所以有的大型數據倉庫系統架構設計復雜，是因為考慮到了未來3-5年的擴展性，這樣的話，客戶不用太快花錢去重建數據倉庫系統，就能很穩定運行。主要體現在數據建模的合理性，數據倉庫方案中多出一些中間層，使海量數據流有足夠的緩沖，不至於數據量大很多，就運行不起來了。
『玖』 資料庫中數據寫入多維數組，如何實現
往資料庫中寫入多維數組？實際上還是字元串的操作，我的做法是：將多位數組格式化為json字元串，當字元串保存在某列的某欄位。或者將多維數組放到一個表中的多條記錄中。