Talk:Dimension (data warehouse)

Expert needed

I've tagged this with {{expert}} because the present article is basically incomprehensible. Given a data set, what is an "item" in that data set? A variable? An observation? How does the example relate to the given definition?  --Lambiam^Talk 04:18, 20 February 2007 (UTC)

I have to disagree. There are already too many articles on the internet which lump dimension with hierarchy and then elaborate on data warehouses. This article is short and precise, defining exactly what a dimension is and giving important attributes. Short articles are often what a person is searching for. To bury this basic information in a larger context makes it difficult for the person who wants a clear explanation of a data dimension without having to sort through a long article just find this simple information. I vote to keep the article "as is" and not combine it. Marti Masters, Software Engineer and Data Analyst. — Preceding unsigned comment added by 84.24.63.85 (talk) 15:36, 30 December 2014 (UTC)

---

No, I agree an expert is needed in order to write a starting definition that is more comprehensible to a lay audience. Later on in the article is a slightly more understandable definition. This should be taken as the starting point and improved to then be used as the articles starting introduction:

• dimension tables contain descriptive attributes (or fields) that are typically textual fields

• Dimension table rows are uniquely identified by a single key field.

The current starting definition is a dimension " categorizes facts", but 'categorize' is vague and could have many meanings. Something more concrete and understandable is needed. While it's always a challenge, it's good to strive for a introductory definition that someone outside the field can read an get the gist of.

If the example give in the wiki page 'https://en.wikipedia.org/wiki/Online_analytical_processing' is correct, it would be very helpful to include here. The example is:

A simple example is given by the time table shown below. The store's sales table is a fact table, and the Date/Time table is a dimension table.

For example:

 Sales Fact Table
+-------------+----------+
| sale_amount | time_id  |
+-------------+----------+            Time Dimension
|      2008.10|     1234 |----+     +---------+-------------------+
+-------------+----------+    |     | time_id | timestamp         |
                              |     +---------+-------------------+
                              +---->|   1234  | 20080902 12:35:43 |
                                    +---------+-------------------+

 — Preceding unsigned comment added by 206.218.52.35 (talk) 17:50, 10 April 2019 (UTC) 

Merge with dimension table

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Merge Dimension table into Dimension (data warehouse) on the basis of consensus (with one exception) since October 2012. Klbrain (talk) 16:12, 29 July 2016 (UTC)

---

It seems pointless to have the two articles separate, considering the small content of each. Data warehousing would seem to be a small subset of dimension table. Virtuald 06:15, 6 August 2007 (UTC)

It does not make sense to put them together either. Not every dimension table is a dimension! Maybe in a (small) relational world it does. —Preceding unsigned comment added by 193.178.209.212 (talk) 11:28, 10 July 2008 (UTC)

It is, in fact, the other way around: not every dimension gets implemented as a dimension table. (A degenerate dimension, for example.) Still, I'd agree with Virtuald: no sense in keeping the articles separate. GregorB (talk) 00:00, 18 November 2008 (UTC)

Support, but the target article should be Dimension (data warehouse), covering both nicely. -DePiep (talk) 19:47, 26 October 2010 (UTC)

Support, I'm going to look into this shortly and do as DePiep suggest. Those two articles need to be merged because (a) it's an important subject, (b) there is a lot of literature available. Going to merge them into this article because these are both stubs but this article is a bit less stubby and more generic. RonaldKunenborg (talk) 21:33, 17 November 2012 (UTC)

Support, I agree with RonaldKunenborg

Ensslen (talk) 03:12, 7 December 2012 (UTC)

Disagree: Dimension table is by far the better article. Items of value from this article (if any) should be merged into that. --66.161.59.254 (talk) 03:45, 2 February 2013 (UTC)

Support, I agree dimension and Dimension Table are not too different from each other to have different pages — Preceding unsigned comment added by Aman861 (talk • contribs) 09:07, 13 June 2014 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.