通常來說
oltp
系統裡無論什麼樣的查詢語句查詢出的結果都是乙個二維的表,而
olap
裡乙個mdx
丟擲去返回過來的大多數都是乙個透視表
.這篇文章闡述本人對其的理解並且簡要的說說他們的不同
.概念闡述
:oltp:
聯機事務處理
,就是我們通常所說的業務系統
,實現資料庫增刪查改的那些操作
.olap:
聯機分析處理
,專門做分析用的
,這裡特指多維資料集
.從結構上來說
,我們傳統意義所說的表與透視表示不同的
.如果說表是乙個平面的結構的話
,那麼透視表就是乙個比較複雜的多維結構
.舉個例子
,針對於人口資訊系統
,我們可以抽象出一些這樣的資訊
:行政區劃
,婚姻狀況
,兵役狀況
,戶口型別…嗯
,就用這些資訊來闡述了.在
oltp
系統裡,
我們可以很容易的統計所有婚姻情況的人數
,或者所有兵役狀況的人數
,或者所有戶口型別的人數
,但是統計行政區劃的人數可能就不容易了
,因為行政區劃通常分三個層次:省
-市-區
.這樣的查詢語句寫起來
,寫起來簡單
,但你往往無法確定使用者到底是要按照什麼方式來統計,省
?市?還是區?.在
oltp
裡你可以把婚姻狀況
,兵役狀況
,戶口型別這樣的資訊作為乙個字段進行查詢
,但是如果使用者不告訴你行政區劃到底是按省還是市或者區的方式進行查詢的話
,你這個查詢語句寫起來就很為難
,因為很明顯直接把行政區劃作為乙個字段全部把其列出來這樣的查詢意義不大
,除非具體制定哪個省或者哪個市或者哪個區.而在
olap
系統中,
我們通常就不用考慮這些
,直接把行政區劃放上取
,使用者就直接可以根據自己的需要檢視自己想要檢視的資訊
.在這裡面再說說資料倉儲系統裡的幾個概念
(個人理解
,歡迎來拍磚
):先說粒度
,粒度在網上和教科書中有很多種解釋方法
,不過說的都很抽象
,在這裡
,,我們可以簡單的理解為資訊的精確程度
,和小學裡學的小數點後面精確到第多少位差不多
.比如時間
,老百姓記錄天氣溫度以天為單位就可以了
,而對於氣象部門就不能以天為單位觀察
,記錄和測量溫度情況
,可能要精確到小時或者分秒
.在上面所說的人口資訊系統裡面
,對於行政區劃這樣乙個資訊
,通常精確到區的單位
,比如吉林省長春市高新技術開發區
.有粒度了然後自然就會產生層次這個概念
.對於沒有層次的資訊談論粒度也就沒什麼意義了
,好比乙個團隊裡終究是需要乙個專案經理來管理
,然後專案經理往上還有領導
.那麼好比行政區劃這個資訊
,基本上就是乙個省管理若干個市
,乙個市管理若干個區
.層次最底層的就是其粒度
.再回過頭來看傳統意義表與透視表的區別
.傳統意義上的表上
,如果把行和列理解成不同的軸的話
,那麼我們會發現
,這些軸都只有乙個層次
,比如兵役狀況或婚姻狀況
,而透視表就不同了
,其軸上的資訊可能是具有很多層次的
,比如行政區劃
.所以透視表的其中乙個魅力就在於
,使用者可以根據當前看到的資訊逐層的檢視細節
,假如我檢視全國人口分布情況
,這時候行政區劃肯定是以省為單位列舉出來的
,然後要看吉林省下的人口分布情況
,點下吉林省
,吉林省下的各個市的人口分布境況就列舉出來了
,然後我再想看長春市
,於是長春市各區的人口情況就都列舉出來了
.而這樣乙個功能對很多使用者來說都有很強的吸引力
.透視表的這些特性
,我們傳統意義上的表也可以通過
sql查詢實現
,因為在現在奇人輩出的年代
,用組合語言都能實現物件導向
,所以我們不能絕對的說什麼東西是不可能的
,只不過在這種查詢細節的實現中
,sql
語句寫的方式就要複雜那麼一點
.另外也是因為這樣的區別
,在透視表上實現
drillthrough to detail
這樣的功能
,直接從資料庫里查就變得很不合適(
本段為個人觀點,
歡迎拍磚),
相比之下從多維資料集本身鑽取就合適很多
.關於這個問題
,很多從事業務系統開發的老專案經理都和我爭論過為什麼不直接走資料庫查詢
,因為他們覺得把一些細節資料聚合到多維資料集中似乎有點不大合適.但是
,因為透視表中乙個軸上的資訊很有可能是帶有很多層次的
,比如乙個透視表的乙個軸上放置著行政區劃資訊
,當前層次是省
,我要看這個省下有哪些人
(注意不是有多少人了
),那麼如果是走多維資料集裡的
drillthrough
函式的話
,系統會自動把這個省下的所有市和區的數目都加到一起然後返回乙個平面資料過來
.而如果這個查詢是要在資料庫裡實現的話
,那麼把這個省下的所有市以及關聯到的所有區的資訊都返回回來
,可想而知這個查詢會有多複雜
.說到頭來就好比我們寫程式一樣
,既然有人替我們實現了乙個介面下的所有方法了
,那麼我們就沒有必要再去自己實現那個介面了
,除非是極特殊的情況
,否則直接拿已經實現好的來呼叫就行了
.另外乙個比較有意思的概念
.我們知道在
oltp
和olap
系統相對應的
t-sql
和mdx
中，都有
where
這麼個篩選功能，
oltp
中的就不用多說了，值得一說的是
mdx中的這個
where.
在資料倉儲中有」切片
」和」切塊
」這兩個概念
,剛開始接觸這個技術的時候
,看書上描述的概念很是抽象
,儘管有圖
,但後來發現
,其關鍵處就是在於
,切片是
where
後面只有乙個篩選條件
,而切塊後面是多個篩選條件
.於是就誕生出了這兩個概念.而在
t-sql
中的where
似乎就沒有這麼多說道
.特意拿出來說一下
,因為這是從學電腦那天開始接觸相關的知識和概念
,感覺最有意思的其中之一
.不過也所謂簡約不簡單
(好像是哪句廣告詞
),畢竟傳統意義上的表與透視表有著很多不同
,所以想要從乙個抽象的角度來理解還是不那麼容易的
.以上是對於某一知識點的一些個人的理解
,相關的概念就和文言文一樣
,看起來累
,想要轉化成白話文還需要一翻功夫
,關鍵還是大家在一起交流
,所以寫出來一來算是分享
,二來希望得到境界更高的前輩們幫我糾正錯誤
,三是希望能看到二中所提到的前輩們對於某些細節的個人理解
,這些我相信對於個人以及大家一定會有幫助
.裡討論商業智慧型的朋友不是很多
,不過還是很高興能看到更多的朋友參與進來
,活躍社群裡的氣氛
.
透視表與傳統意義上的表
通常來說 oltp 系統裡無論什麼樣的查詢語句查詢出的結果都是乙個二維的表,而 olap 裡乙個mdx 丟擲去返回過來的大多數都是乙個透視表 這篇文章闡述本人對其的理解並且簡要的說說他們的不同 概念闡述 oltp 聯機事務處理 就是我們通常所說的業務系統 實現資料庫增刪查改的那些操作 olap 聯機...
pandas 交叉表與透視表
利用pivot table函式可以實現透視表，pivot table 函式的常用引數及其使用格式如下。pands.pivot table data,values none,index none,columns none,aggfunc mean fill value none,margins fal...
溝通在專案管理中的意義 上
前言 溝通這件事情說起來比較複雜，可以說不管是從軟體工程角度還是從專案管理角度，溝通是貫穿整體專案價值鏈的重要因素，也是贏得經濟效益的重要手段。可以說沒有溝通就沒有專案管理，良好的溝通計畫與經驗是專案成功的關鍵。專案中溝通藝術，不但是專案經濟鏈重要的一環，而且是決定專案成敗最重要的一項。那麼，什麼是...