⚡️🗒️Power BI: Visual Calculations [Notes]

Disclaimer: This is work in progress intended to consolidate information from various sources for learning purposes. For the latest information please consult the documentation (see the links below)! 

Last updated: 2-Nov-2026

[feature] Visual Calculations (aka Visual Calcs)

• {def} a type of DAX calculation that's defined and executed in the scope of a visual [1] [5]
• represent columns added to a virtual table of filtered and aggregated data [5]
• not directly connected to the rest of the semantic model [5]
• {characteristic} defined and evaluated only on the filtered and aggregated data that is visible in the visual 
• the visual matrix in which the visual calculation is created [5] 
• aka calculations table that’s defined in the DAX query [5]
•  the filter context dictates what the measures and fields on the visual return, and the visual calculation takes those values as input for its evaluation [5]
• ⇐ a visual calculation is only indirectly affected by filter context, not directly, the way a measure or field reference is [5]
• {characteristic} evaluate at runtime [5]
• like measures do [5] 
• ⇒ they can be fully dynamic in the context of the visual [5]
• {characteristic} a single query is sent to the source [5]
• ⇐ no such guarantee exists for analysis that relies on measures [5] 
• ⇐ how pronounced the effects are depends on the size of the data and the complexity of the DAX used [5]
• {characteristic} executed on a row-by-row basis
• like a calculated column [5]
• {characteristic} calculated on the fly [4]
• like a measure [5]
• {characteristic} stored on the visual
• ⇒ aren’t part of the semantic model [5]
• ⇒ can refer to any data in the visual
•  incl. columns, measures, or other visual calculations [1]
• ⇒ anything in the model must be added to the visual before the visual calculation can refer to it [1]
• ⇒ no need to worry about filter context [5]
• ⇒ they can refer to the visual structure
• ⇒ leads to more flexibility
• {characteristic} operate on aggregated data instead of the detail level [1]
• ⇒ leads to performance benefits [1]
• {benefit} combine the simplicity of context from calculated columns with the on-demand calculation flexibility from measures [1]
• ⇐ the context is 'visible
• ⇐ share behaviors with calculated columns and measures [5]
• ⇐ have important differences
• ⇐ in how they can be used, where they are stored, when they are computed [5]
• {benefit} make it easier to create calculations (that were previously hard to create) 
• leads to simpler DAX, easier maintenance, better performance [1]
• reuse the results from its components [2]
• simpler than measures, more trustworthy than Excel [5]
• {benefit} the visual context in which they operate not only describes what data is on the visual (which is then iterated over in a row context) but also the structure of the visual 
• ⇒ a visual calculation can refer to the axes of a visual, such as the x-axis or the y-axis instead of the actual field [5]
• ⇐ enables visual calculations to be highly flexible [5]
• ⇐ a visual calculation can continue to work even if the field that is on the x-axis changes by simply referring to the axis instead of the actual field [5]
• {benefit} highly visual [5] always show the data the calculation works on, and tools are provided to easily validate the results [5]
• {benefit} should perform better than measures 
• ⇐ because they’re executed as part of the DAX query to fetch the results instead of independently [5]
• {limitation} unaware of the semantic model [5]
• ⇐ as they are not part of the semantic model) [5]
• ⇒ DAX functions that perform actions on that model don’t work (return an error) [5]
•  e. g. RELATED, USERELATIONSHIP
• {limitation} can’t be reused across multiple reports [5] 
• ⇒ leads to code duplication [5]
• ⇐ only live on the visual, which will avoid cluttering of the semantic model [5]
• they’re saved in the metadata of the report, inside the visual definition. [5]
• can only be used inside one report and that definitions cannot be shared across multiple reports that share the same semantic model [5]
• (limitation) do not work together with the 'show items with no data' option, because it would result in performance issues.[5]
• {recommendation} create measures for any key calculations that should be reused across multiple reports [5]
•  o    allows to establish a SVoT, better reusability, maintenance, design, etc.
• introduce a set of functions specific to visual calculations [1]
• {category} medium-level functions
• {function} COLLAPSE
• the calculation is evaluated at a higher level of the axis [1]
• navigate to a higher level in the lattice formed by the fields on the axes of the visual matrix [5] 
• most often used for percentage of parent, grandparent, and total calculations [5]
• {function} COLLAPSEALL
• the calculation is evaluated at the total level of the axis [1]
• does not take extra parameters because it always moves to the highest level on the axis [5] navigate to the highest level of the lattice on the axis specified [5]
• {function} EXPAND
• the calculation is evaluated at a lower level of the axis [1]
• navigate to a lower level in the lattice formed by the fields on the axes of the visual matrix [5]
• often used for aggregated descendant averages [5]
• the reverse of COLLAPSE
• {function}EXPANDALL
• the calculation is evaluated at the leaf level of the axis [1]
• always moves down to the lowest level (leaf level) on the axis and doesn’t take these parameters [5]
• the reverse of COLLAPSEALL [5]
• {function} FIRST
• retrieves a value from the first element on a specified axis [5]
• often used to compare against a base period or entity [5]
• retrieves the value of the column in the first element on the specified axis since the last time the calculation was reset [5]
• an easier-to-use shortcut to the INDEX function with the position parameter set to 1 [5]
• {function} ISATLEVEL
• checks whether specified columns are on the current level of the axis [5]
• returns a Boolean (True/False) value
• guaranteed to work correctly in visual calculations with functions that navigate the levels of the lattice [5]
• unlike ISINSCOPE, ISFILTERED inspection functions [5]
• {function} LAST
• refers to the last row of an axis [1]
• retrieves a value from the last element on a specified axis [5]
• the reverse of FIRST
• often used to compare against the most recent entry [5]
• {function} LOOKUP
• evaluates an expression with a value from a cell in the provided visual matrix using filters [5]
• anything that is not specified is inferred from the context [5]
• often used to compare against a specific value in the visual matrix [5]
• {function} LOOKUPWITHTOTALS
• uses the total for any filter that is not specified [5]
• returns the value of the expression provided at the specified coordinates after filters have been applied [5]
• any filter that is not specified is treated as referring to the total
• if no single value can be determined, an error is returned [5]
• ⇐ instead of using the context to infer any filter that is not specified like LOOKUP does [5]
• relies on absolute navigation in the visual matrix [5]
• ⇐ COLLAPSE and COLLAPSEALL rely on relative navigation on the lattice [5]
• ⇐ upon case can be used to retrieve same result [5]
• {function} NEXT
• retrieves a value from a next element on a specified axis [5]
• retrieves the value of the column from a next element on the specified axis since the last time the calculation was reset [5]
• provides a shortcut to the OFFSET function with a positive value provided for the delta parameter [5]
• {function} PREVIOUS
• retrieves a value from a previous element on a specified axis [5]
• retrieves the value of the column from an earlier element on the specified axis since the last time the calculation was reset [5]
• provides a shortcut to the OFFSET function with a negative value provided for the delta parameter [5]
• {function} RANGE
• provides a range of rows relative from the current position on the axis [5]
• shortcut to WINDOW 
• returns a context 
• ⇒ it must be used with other functions, such as CALCULATE, to actually perform a calculation [5]
• often employed to calculate a moving sum [5]
• {category} high-level functions
• {function} MOVINGAVERAGE
• adds a moving average on an axis [1]
• involves selecting a slice of the values on an axis and returning the average over that slice [5]
• most often used to calculate averages across periods [5]
• provides an easier-to-use shortcut to the WINDOW function [5]
• {function} RUNNINGSUM
• returns the sum of all values in a column on the axis since the last time the calculation was reset, up to and including the current value [5]
• if no reset is defined, RUNNINGSUM starts at the top of the visual matrix and continues to the end, following the sort order [5]
• created specifically for visual calculations [5]
• often used for Pareto analysis [5]
• provides an easier-to-use shortcut to the WINDOW function [5]
• it’s possible to write a running sum in a measure, though the code becomes more complex to write [5] 
• ⇐ include explicit references to columns on which the calculation works [5]
• ⇒ if the user changes the columns on the visual, the measure will return unexpected results and will have to be updated to reflect the changes [5]
• {category} low-level functions
• ⇐ {exception} are available in standard DAX
• these functions are easier to use, though they are less flexible than their foundational counterparts [5]
• {recommendation} rewrite visual calculation using DAX for more flexibility [5]
• {recommendation} start with the easier-to-use visual calculations exclusive functions and resort to other functions only when needed [5]
• {category}foundational functions
• {parameter} relation 
• table expression that defines from which output a value is returned, namely a table expression [5]
• name of a table or a DAX statement that returns a table, such as ADDCOLUMNS or SUMMARIZECOLUMNS
• any columns specified in the partitionBy parameter must come from the relation parameter or from a related table [5]
• {parameter} orderBy
• specifies how each partition on the relation or axis is sorted [5]
• accepts only the ORDERBY function
• partitions are defined by using either partitionBy or reset [5]
• {default} ordering by every column that is in the relation or on the axis that is not specified in partitionBy or reset [5]
• {parameter} blanks
• specify how blank values on the axis should be ordered while the calculation traverses the axis (in a visual calculation) or the relation [5]
• does not sort anything in the values of the visual matrix (e.g. visual calculations or measures) [5] it sorts the values of the fields on the axis used [5]
• {value} DEFAULT
• indicates that blank numerical values are ordered between zero and negative values. For blank textual values, the blank values are ordered before all text values, including empty text values [5]
• {value} FIRST 
• blank values are always ordered at the beginning, regardless of ascending or descending sorting order [5]
• {value] LAST 
• blank values are always ordered at the end, regardless of ascending or descending sorting order [5]
• {parameter} partitionBy
• specifies how the relation or axis is partitioned [5]
• accepts the PARTITIONBY function [5]
• {recommendation} use reset instead of partitionBy  
• ⇐ it’s the easiest way of achieving the same result [5]
• {parameter} matchBy
• defines how to match data to identify unique rows [5]
• use this parameter if you do not have anything that can uniquely identify the rows in your relation (aka composite key) [5]
• when using axis in visual calculations, there's not need to use matchBy in visual calculations because the axis always has unique identifiers [5]
• if no matchBy is specified and the columns in orderBy and partitionBy cannot uniquely identify every row in the relation, the foundational function will try to find the least number of additional columns required to uniquely identify the rows and append these to the orderBy value (even if you did not specify orderBy) [5] 
• {parameter} resets
• accepts the MATCHBY function
• available only for visual calculations
• the calculation is reset by dividing the data on the axis into slices, the same way partitionBy does [5]
• {def} reset parameter
•  defines when a calculation should restart as it traverses the visual matrix
• {limitation} one cannot specify both reset and partitionBy
• one can think of the reset parameter as being mapped to the partitionBy parameter, however reset automatically includes parent levels and partitionBy does not [5]
• {function} INDEX
• returns a row in an absolute position
• position parameter defines the absolute position on the relation or axis from which to obtain the data.
• {function} OFFSET
• returns a row in a relative position
• {parameter} delta
• specifies the relative position on the relation or axis from which to obtain the data [5]
• when specifying a delta that causes a relative movement that does not exist on the partition, when specifying  0 or BLANK(), then OFFSET will not perform a relative movement, and the context is set to the current row [5]
• any DAX expression that returns a scalar value is valid [5]
• {function} RANK
• provides a ranking of each row within a partition, sorted by the specified sort order [5]
• returns a blank value for total rows when used in measures but returns a value on those rows when used in visual calculations [5]
• expects a table and applies an expression to rank the rows in the table [5]
• {warning} it's not the column-based version of RANKX [5]
• {parameter} ties parameter
• {value|default} SKIP
• if two rows end up with the same rank, they will both be assigned the same rank and the next rank number will be skipped [5]
• {value}DENSE
• the next rank number will not be skipped [5]
• {function} ROWNUMBER
• returns a unique ranking of each row within a partition, sorted by the specified sort order [5]
• returns an error if it cannot uniquely identify each row [5]
• ⇒ guarantees that the same number will never be assigned twice [5]
• {function}WINDOW
• returns multiple rows, which are positioned at a selectable absolute or relative interval [5]
• {parameter} from
• indicate where the window start
• {parameter} to
• indicate where the window ends
• {parameter} from_type
• specifies whether the window starts at either 
• {default} relative position (REL)
• then a negative value provided for this parameter specifies the number of rows to go back from the current position to get the first (or last) row in the window [5]
• absolute position (ABS) [4]
• indicate the 1-based absolute position in the current partition of the start and end of the window [4]
• 1= first row, -1 = last row
• {parameter} to_type
• see from_type
• {category} supportive functions
• used as inputs to specific foundational function parameters with the same name [5]
• on their own, these functions provide no value [5]
• {recommendation) specify an axis value for the relation parameter and use reset as needed when using foundational functions in visual calculations [5]
• the Axis parameter 
•  defines the path or direction through the visual matrix that a calculation follows, controlling how functions move through the data displayed in a visual
• tells PBI how to traverse the visual's data when performing the calculation, giving precise control on how the calculations are performed
• {function} ORDERBY
• define the sorting order within each partition of the relation or axis on which the function operates [5]
• {function} PARTITIONBY
• indicates if and how to slice up the data in the relation or axis on which the foundational function operates [5]
• it can be skept if no slices are defined [5]
• {function} MATCHBY
• instruct DAX on how to determine the current row [5]
• {category} shared functions
• DAX functions which are shared across all experiences [5]
• {category} exclusive functions 
• functions introduced in DAX solely for visual calculations [5]
• {category} blocked functions 
• functions that reach out to the model [5]
• {default} most of them are evaluated row-by-row [1]
• ⇐ like a calculated column
• there's no need to add an aggregation function [1]
•  it's better not to add such aggregates when they're not necessary [1]
• {operation} create calculation
• adds the visual calculation to the visual
• it's possible to create visual calculations directly in the service [5]
• allows to create very complex visual calculations in steps and hide any irrelevant intermediate results [5]
• creation is not traced as activity in audit logs but is covered in a generic activity named Update Report Content [5]
• {operation} hide calculation
• calculations that aren't needed in the visual can be hidden [2]
• hidden fields enable users to hide elements from the visual [5]
• {def} hidden field
• a column in a visual intended solely to support a visual calculation, but is not displayed to the report consumer
• {operation} copy calculation
• copies the calculation between visuals and if intermediary steps are not there, they will be copied as well [planned] [2]
• {operation} formatting 
• ⇐ do not take on the format of any measures used to create them [5]
• {operation} view a visual as a visual matrix 
• enables users to add more calculations, which can be seen as new columns in the visual matrix [5]
• {feature} templates 
• ready available calculation constructs 
• {benefit} make it easier to write common calculations [1]
• {feature|planned} support for Scanner API [2]
• {feature} explore
• new experience that allows to explore data in a focused way [4]
• allows adding visual calculations to visuals [4]
• {feature} parameter pickers
• allows to create visual calculations faster by picking parameters [3]
• {limitation} only available for required parameters on functions that are exclusive to visual calculations (and select other functions) that have a defined list of options [3]
•  required parameters that can take any text, or numerical value will not get a parameter picker, and neither will many DAX functions [3]
• {feature} visual preview 
• shows users what the visual will look like when leaving the visual calculations edit mode and returning to the report [5]
• allows users to see what impact newly added visual calculations have on the visual, and how the visual will look like if certain measures or visual calculations are hidden [5]
• {feature} visual matrix
• {def} the internal tabular representation of the data shown in the visual that PBI uses to evaluate the calculation
• the data representation of your visual 
• ⇐ shows you the outcomes of all newly added calculations [5] 
• ⇐ the simplest representation of the data used to create the visual [5]
• offers a way to structure data dynamically based on rows and columns in a WYSIWYG fashion [5]
• doesn't display any formatting that may be applied to the visual itself [5]
• every value in a visual calculation must exist in the visual matrix
• ⇒ both the original value residing in the model and the visual calculation will be shown in the resulting visual [5]
• {feature} formula bar 
• allows to write and edit visual calculations [5]
• {parameter} axis 
• influences how the visual calculation traverses the visual matrix [1] 
• ⇐ defines the direction in which the running sum should be calculate [5]
• can be seen as the axis of a chart, which has an x-axis and a y-axis [5]
• not available in measures, calculated columns, or calculated tables [5]
• defines the direction in which the running sum should be calculated: over rows, columns, or a combination [5]
• {default} set to the first axis in the visual
• {value} ROWS
• the visual calculation is evaluated row-by-row in the visual matrix, from top to bottom. [1]
• {value} COLUMNS
• the visual calculation is evaluated row-by-row in the visual matrix, from left to right [1]
• {value} ROWS COLUMNS
• calculates vertically across rows from top to bottom, continuing column by column from left to right [1]
• {value} COLUMNS ROWS
• calculates horizontally across columns from left to right, continuing row by row from top to bottom [1]
• {warning} not all visuals provide all axes, and some visuals provide no axes [1]
• references to a non-existent or invalid axis is permissible and will be ignored [3]
• {parameter} reset 
• influences if and when the function resets its value to 0 or switches to a different scope while traversing the visual matrix [1]
• expects there to be multiple levels on the axis [1]
• ⇐ use PARTITIONBY if there's only one level on the axis [1]
• {value|default} NONE
• means the visual calculation is never restarted [1]
• {value} HIGHESTPARENT 
• resets the calculation when the value of the highest parent on the axis changes [1]
• {value} LOWESTPARENT 
• resets the calculations when the value of the lowest parent on the axis changes [1]
• {value} numerical value
• refers to the fields on the axis, with the highest field being one [1]
• {concept} lattice
• formed by all the fields on all the axes [5]
• visual calculations calculate results on various levels on the lattice [5]
• lattice navigation functions allow users to explicitly move around in the lattice [5]
• e.g. COLLAPSE, COLLAPSEALL, EXPAND, EXPANDALL
• {default} the data type of a visual calculation is decimal number [5]
• {concept} format strings
• allow for a more fine-grained level of formatting
• {feature} traceability 
• prevents redundancy and conflicting definitions by identifying inconsistent calculations [5] 
• using audit trails and versioning systems further enhances accountability and enables swift corrections when needed [5]
• {limitation} functions that rely on model relationships  aren't available
• e.g. USERELATIONSHIP, RELATED or RELATEDTABLE
• {limitation} not all visual types are supported [1]
• ⇐ for the full list of limitations see [1]
• {limitation} one can't filter on visual calculations [1]
• {limitation} underlying data can't be exported [1]
• {limitation} don't support conditional formatting
• {concept} skippable parameters
• introduced with visual calculations [5]
• allow for cleaner code because users can simply omit any unnecessary optional parameters [5]
• ⇐ unlike with DAX functions that do not support skippable parameters [5]
• {concept} telemetry 
• the collection and analysis of data to monitor, measure, and optimize system performance[5]
• can provide valuable insights into the usage patterns, dependencies, and performance of visual calculations [5]
• allows administrators can identify discrepancies and ensure that visual calculations align with organizational standards [5]
•  

Previous Post <<||>> Next Post

References: 
[1] Microsoft Learn (2024) Power BI: Using visual calculations [preview] [link]
[2] SSBI Central (2024) Visual Calculations - Making DAX easier, with Jeroen ter Heerdt [link]
[3] Microsoft Power BI Updates (2025) Power BI June 2025 Feature Summary [link]
[4] Microsoft Learn (2025) Power BI: Use Explore (preview) in the Power BI service [link]
[5] Jeroen ter Heerdt et al (2026) Microsoft Power BI Visual Calculations: Simplifying DAX 

📉Graphical Representation: Zero, the Origin (Just the Quotes)

"The zero of the scale should appear on every chart, and should shown by a heavy line carried across the sheet. If this is not done the reader may assume the bottom of the sheet to be zero and so be misled. The scale should be graduated from zero to a little over the maximum figure to be plotted on the charts, so that there will be a space between the highest peak on the curve and the top of the chart." (Allan C Haskell, "How to Make and Use Graphic Charts", 1919)

"When plotting any curve the vertical scale should, if possible, be chosen so that the zero of the scale will appear on the chart. Otherwise, the reader may assume the bottom of the chart to be zero and so be grossly misled. Zero should always be indicated by a broad line much wider than the ordinary co-ordinate lines used for the background of the chart." (Willard C Brinton, "Graphic Methods for Presenting Facts", 1919)

"When dealing with very large quantities it is not always practicable to use a scale which starts at zero, and is carried up by even steps to a figure representing the highest peak on the curve. Such a chart would either be too large for convenient handling, or else the scale would have to be condensed so that only very large fluctuations would be indicated on the curve. In a ease of this kind the best practice is to start the at zero, and just above this point draw a wavy line across the sheet to indicate that the scale is broken at this point. This line can be very easily drawn with an ordinary serrated edge ruler as used by many accountants. The scale starts again on the upper side of the wavy line at a figure a little lower than the lowest point on the curve, and is carried up by even steps to a figure a little above the highest point to be shown on the curve." (Allan C Haskell, "How to Make and Use Graphic Charts", 1919)

"Another principle which will quickly appeal to your common sense, is the rule that when zero is real, the zero-line should be extra heavy to make it prominent. Remember that it takes the place of the floor or lower end of the bars in the bar-chart. It should stand out, therefore, in such a way that the reader can easily grasp its significance and compare with it the heights of the points on the curve. The rule is particularly important in cases where the chart extends down below the zero line into the negative side in order to show negative and positive values. On the same principle the 100% line, when it occurs in a chart, should be similarly heavy as it also may be considered a base for zero points, being the point of zero loss or gain. In fact, the rule may be extended to all cases of lines showing significant constant values, and the zero line should not be heavy, unless it has a special significance." (Karl G Karsten, "Charts and Graphs", 1925)

"Most of the good things in this world involve some sacrifice. Curves are no exception. In a curve the direct visible connection between the curve itself and the zero line, or x-axis, is sacrificed. As time goes on and you become more and more used to the curve chart, you will begin to think of its values as in some mysterious manner floating disembodied along the connecting line which forms the curve. You will be tempted to forget that the quantities rest very substantially upon the floor (base line, zero line, x-axis or whatever you want to call it), and that it is only their tops which reach the points plotted in the curve. And forgetting this, you will try to save space by omitting the zero line and lower part of the chart, and by showing only that small portion or band of the chart through which the plotted curve travels." (Karl G Karsten, "Charts and Graphs", 1925)

"Note also, and this is important, that if through standing too close you should take a picture showing only the upper ends of the upright boards, but not their full lengths, you would consider the resulting picture not only a failure but actually deceptive. In other words, you must not omit the zero-line or base-line. While you would succeed in showing the variation of the top ends more clearly you would no longer have comparable lengths." (Karl G Karsten, "Charts and Graphs", 1925)

"This practice of omitting the zero line is all too common, but it is not for that reason excusable. The amputated chart is a deceptive one, tempting the average reader to compare the heights of points on the curve from the false bottom of the amputated chart-field, rather than from the true zero line, far below and invisible. A curve-chart without a zero line is in general no whit less of a printed lie, than a vertical bar-chart in which the lower part of the bars themselves are cut away. The representation of comparative sizes has been distorted and the fluctuations (changes in value) exaggerated." (Karl G Karsten, "Charts and Graphs", 1925)

"An important rule in the drafting of curve charts is that the amount scale should begin at zero. In comparisons of size the omission of the zero base, unless clearly indicated, is likely to give a misleading impression of the relative values and trend." (Rufus R Lutz, "Graphic Presentation Simplified", 1949)

"Where the values of a series are such that a large part the grid would be superfluous, it is the practice to break the grid thus eliminating the unused portion of the scale, but at the same time indicating the zero line. Failure to include zero in the vertical scale is a very common omission which distorts the data and gives an erroneous visual impression." (Calvin F Schmid, "Handbook of Graphic Presentation", 1954)

"Since bars represent magnitude by their length, the zero line must be shown and the arithmetic scale must not be broken. Occasionally an excessively long bar in a series of bars may be broken off at the end, and the amount involved shown directly beyond it, without distorting the general trend of the other bars, but this practice applies solely when only one bar exceeds the scale." (Anna C Rogers, "Graphic Charts Handbook", 1961)

"One can hide data in a variety of ways. One method that occurs with some regularity is hiding the data in the grid. The grid is useful for plotting the points, but only rarely afterwards. Thus to display data badly, use a fine grid and plot the points dimly [...] A second way to hide the data is in the scale. This corresponds to blowing up the scale (i.e., looking at the data from far away) so that any variation in the data is obscured by the magnitude of the scale. One can justify this practice by appealing to 'honesty requires that we start the scale at zero', or other sorts of sophistry." (Howard Wainer, "How to Display Data Badly", The American Statistician Vol. 38(2), 1984)

"When the data are magnitudes, it is helpful to have zero included in the scale so we can see its value relative to the value of the data. But the need for zero is not so compelling that we should allow its inclusion to ruin the resolution of the data on the graph." (William S Cleveland, "The Elements of Graphing Data", 1985)

"A coordinate is a number or value used to locate a point with respect to a reference point, line, or plane. Generally the reference is zero. […] The major function of coordinates is to provide a method for encoding information on charts, graphs, and maps in such a way that viewers can accurately decode the information after the graph or map has been generated."  (Robert L Harris, "Information Graphics: A Comprehensive Illustrated Reference", 1996) 

"Although in most cases the actual value designated by a bar is determined by the location of the end of the bar, many people associate the length or area of the bar with its value. As long as the scale is linear, starts at zero, is continuous, and the bars are the same width, this presents no problem. When any of these conditions are changed, the potential exists that the graph will be misinterpreted." (Robert L Harris, "Information Graphics: A Comprehensive Illustrated Reference", 1996)

"Grouped area graphs sometimes cause confusion because the viewer cannot determine whether the areas for the data series extend down to the zero axis. […] Grouped area graphs can handle negative values somewhat better than stacked area graphs but they still have the problem of all or portions of data curves being hidden by the data series towards the front." (Robert L Harris, "Information Graphics: A Comprehensive Illustrated Reference", 1996)

"Graphic misrepresentation is a frequent misuse in presentations to the nonprofessional. The granddaddy of all graphical offenses is to omit the zero on the vertical axis. As a consequence, the chart is often interpreted as if its bottom axis were zero, even though it may be far removed. This can lead to attention-getting headlines about 'a soar' or 'a dramatic rise (or fall)'. A modest, and possibly insignificant, change is amplified into a disastrous or inspirational trend." (Herbert F Spirer et al, "Misused Statistics" 2nd Ed, 1998) 

"If you want to show the growth of numbers which tend to grow by percentages, plot them on a logarithmic vertical scale. When plotted against a logarithmic vertical axis, equal percentage changes take up equal distances on the vertical axis. Thus, a constant annual percentage rate of change will plot as a straight line. The vertical scale on a logarithmic chart does not start at zero, as it shows the ratio of values (in this case, land values), and dividing by zero is impossible." (Herbert F Spirer et al, "Misused Statistics" 2nd Ed, 1998)

"Choose scales wisely, as they have a profound influence on the interpretation of graphs. Not all scales require that zero be included, but bar graphs and other graphs where area is judged do require it." (Naomi B Robbins, "Creating More effective Graphs", 2005)

"Unfortunately, setting the scale at zero is the best recipe for creating dull charts, in both senses of the word: boring and with little variation. The solution is not to break the scale, but rather to find a similar message that can be communicated using alternative metrics." (Jorge Camões, "Data at Work: Best practices for creating effective charts and information graphics in Microsoft Excel", 2016)

"The omission of zero magnifies the ups and downs in the data, allowing us to detect changes that might otherwise be ambiguous. However, once zero has been omitted, the graph is no longer an accurate guide to the magnitude of the changes. Instead, we need to look at the actual numbers." (Gary Smith, "Standard Deviations", 2014)

🕋Data Warehousing: Axis (Definitions)

"A set of tuples. Each tuple is a vector of members. A set of axes defines the coordinates of a multidimensional dataset. For more information about axes, see your OLE DB documentation." (Microsoft Corporation, "SQL Server 7.0 System Administration Training Kit", 1999)

"An axis specifier indicates the relationship between the nodes selected by the location step and the context node. Examples of axis specifiers include child, parent, and ancestor." (Michael Coles, "Pro T-SQL 2008 Programmer's Guide", 2008)

"A set of tuples. Each tuple is a vector of members. A set of axes defines the coordinates of a multidimensional data set." (Microsoft, "SQL Server 2012 Glossary", 2012)

"Specifier that indicates the relationship between the nodes selected by the location step and the context node. Examples of axis specifiers include child, parent, and ancestor." (Miguel Cebollero et al, "Pro T-SQL Programmer’s Guide" 4th Ed, 2015)