談到資料分析時常常會用到次元這個詞，針對資料立方體的鑽取、旋轉、切片等操作都是圍繞次元進行的，幾乎所有的資料分析人員都知道并會運用這個術語，但要問及它的定義，卻幾乎沒有人能給出來。
通俗來講，我們把用來分類的屬性（字段）稱為次元，比如地區、年度、産品類型等；而另外一些用于聚合運算的屬性則稱為測度，比如銷售額、産量、考試成績等。次元不能做聚合運算，比如計算地區合計是沒有意義的；測度則不能用于分類，比如按銷售額分類也沒什麼業務意義。我們通常就是用是否”可用于分類“來判定一個屬性是不是次元，但這其實隻是對于次元性質的描述，并不能作為定義。
我們基于關系資料庫來讨論這個問題，先簡單回顧一下基本概念。
設有一個關系資料庫，其中有若幹資料表，表的資料結構由字段構成，表的資料由記錄構成。
資料表的某些字段被指定為主鍵，需要滿足這樣的條件：表中所有記錄在這些字段上的取值是互不相同的。也就是說，可以用主鍵值來确定唯一相應的記錄。資料表可以沒有主鍵，但有隻能有一套。構成主鍵的字段稱為主鍵字段。
每個資料表可以有多套外鍵，外鍵也是該資料表的某些字段，其取值總是在另一個表（可能是本表）的主鍵取值範圍内。這裡的另一個表被稱為外鍵指向表，簡稱外鍵表，構成外鍵的字段被稱為外鍵字段。
現在，我們定義：在關系資料庫中，不是外鍵字段的主鍵字段被稱為次元，次元所在的表稱為維表，次元可以用維表的主鍵字段來辨別。順便地，我們定義即不是主鍵字段也不是外鍵字段的字段為測度。從這個定義上看，顯然不可能某個字段既是次元又是測度。
需要說明的是，我們這裡所說的主鍵外鍵是指邏輯意義上的概念，也就是在資料的E-R結構設計中的主外鍵。有時為了性能而在實體資料結構中并不真地建立主鍵和外鍵，這種情況不在我們的考慮範圍内。
先從一些例子來了解次元的定義。
看這兩個同維表：
我們會在manager表建立外鍵，字段為id，指向employee表的主鍵id。這時，manage.id既是主鍵字段也是外鍵字段，那麼它不是次元。而employee.id是主鍵字段而不是外鍵字段，那麼它就是次元。
再看主子表的情況：
OrderDetail.id是主鍵字段，但也是指向Orders表的外鍵字段，是以它不是次元。而Orders.id是主鍵字段但不是外鍵字段，那麼它是次元，OrderDetail.no是主鍵字段且不是外鍵字段，它也是次元。
OrderDetail.no這個次元有些特殊，一般來說，不會有另外一個外鍵字段和它關聯了，我們把這種未被指向的次元稱為孤維。在查詢界面中做次元對齊運算時一般不用列出來孤維。
再來檢驗這個定義是否和正常的次元觀念相符，并且對于不相符的情況要給出合理的解決方案。
對于地區、産品這些正常次元，資料庫中都會有對應的地區表、産品表，那麼這些次元就對應了這些表的主鍵字段，符合我們定義。而銷售額、産量等屬性則不可能對應到某個表的主鍵，是以确實也不是次元。
但日期（或年度）呢？它顯然是個次元，但資料庫中并沒有一個表以它為主鍵，似乎不符合我們的次元定義。
事實上，所有用到日期資料類型的資料庫在邏輯上都應當有一個日期表，其它資料表的日期型字段均可以視為指向這個日期表的外鍵。但由于日期的相關資訊都可以由日期本身計算出來（年度、月份等），而不需要單獨存儲的屬性，是以我們通常不會在實體資料庫中建立這個日期表。那麼，隻要在邏輯上恢複這個日期表，日期就符合前面的次元定義了。我們把這種邏輯上應該有但實體上并未建立的表稱為假表，假表可以看成是一個單字段無記錄的表，這個單字段也就是該表的主鍵，這樣就可以承載沒有實體表的次元了。類似地，年度、月份也都可以用假表定義。
再觀察年齡這種屬性，它有可能用于分類（每個年齡的人數），又可能用于聚合（某部門人員的平均年齡），從性質上看，它似乎即是次元又是測度？這就與我們的定義相悖了。
其實，我們在用年齡分類統計時并不是用年齡值本身，而是年齡段，且年齡本身應該是個實數值，這是不能用于分類的。也就是說，年齡是測度，而通過年齡計算出來的年齡段才是個次元。這時候，我們要引入維函數概念，維函數以某個字段值為參數，傳回某個次元的取值。通過維函數可以把測度轉換成次元，在它的幫助下，我們就可以保持次元的嚴格定義，同時又不和正常觀念沖突。
這裡的次元定義是基于外鍵概念的，而我們知道，外鍵實際上定義了表之間的JOIN關系。從這個意義上講，次元是被JOIN定義的！
原文釋出時間為：2017-12-28