In Sql Management studio MDX query designer, there's the metadata pane from which you can drag elements of the cube into your query.
Is there a key for the icons anyway?
There's six dots in a pyramid, another has six dots in two vertical rows of three. Not sure what the folder icon represents under a dimension, etc. That's not the only ones, so I'd really like a key. Any ideas? Couldn't find it in the help.
Thanks
The meaning of the icons become obvious once you've had experience creating a number of dimensions. Many of them are obvious by the label that's next to them. Here's a list of a few of the others:
Measure
Calculated Measure
Dimension
Attribute Hierarchy
User-Defined Hierarchy
Level 1 of User-Defined Hierarchy
Level 2 of User-Defined Hierarchy
Member Property
The folder icon underneath the dimension that you're talking about is most likely to hold the member properties.
Related
I am working for the Vanuatu government at the moment and there is a very specific reporting requirement. The report needs to generate a formal document ("statement") for students ("learners") who have achieved some courses ("components") of a full qualification but not the complete qualification.
The dataset consists of a list of learners and for each learner the list of components they have achieved.
The requirements that generate issues:
A border should be displayed around the page content.
The number of components vary per learner.
There is specific data at the top and at the bottom of the page. At the bottom of the page there is data here that is learner dependent.
There needs to be one page per learner (I can control this by using slightly different versions of this report that would work based on the number of components per learner.
The design I created for the report can be seen here. This is the design that should work for any learner who has passed 1 to 4 components.
However, this does not work, because, depending on the number of components the learner has achieved, the data at the bottom is pushed down.
I thought I might be able to solve this by putting the image at the background of the whole report per page, and then put a header and footer in with the data that is learner specific. But this does not work either because it is not possible it seems to have a background image that covers the whole report page, including a header and future.
And the other problem is that there is a learner specific number (the statement number) that should go in the future, and I don't think I can put dataset data like that in the footer.
I also thought of splitting the background image in 3 parts, one each for the header, footer and body. But then I run into the same problem because I still need to get the learner specific statement number in the footer.
Another solution was to maybe have a fixed set of rows (partly invisible) in the list of components, to force the height of this list, but this does not really work either, because some titles of the components will be longer than the width of the page and wrap and take up two lines of text. Some others may not. So I don't know the height of each component line.
Is this possible at all in SSRS? Any help would be greatly appreciated.
Try creating a rectangle in the space that will be taken by the components list.
Then cut the current text box containing your expression, click the rectangle then paste inside it. This will ensure that the rectangle is the container for the textbox.
Then, in Report Properties, set ConsumeContainerWhiteSpace to True. This should allow the textbox to grow within the rectangle
Is there a way to weigh layout according to node attributes in igraph? In other words, how to get nodes that share the same characteristics (but do not have edges between them) cluster more closely together?
While many layout functions can take edge weight into account, the nodes that I want to be closer to each other do not have edges between them. An example of such situation is if the graph is bipartite. Using layouts such as fruchterman.reingold is not very informative as vertices of the two different types are interspersed. However, I do not want it be be as extreme as the layout.bipartite option either as it would be rather messy when there are lots of vertices. What I wish is to have a layout that is somewhere between these two, having vertices of the same type to be on one side, and also cluster according to certain attributes, with edges between the two types.
Any idea or suggestion will be greatly appreciated. Thanks!
igraph layouts are simply matrices with 2 columns and N rows, so you can easily re-use one layout with another graph as long as the two graphs share the same number of nodes. You can make use of this here: create a graph where you connect the nodes that you want to be placed close to each other, calculate the layout using this graph, and then plot your original graph with the layout you have calculated.
I am trying implement underlay following sections in SSRS. Is there any way to achieve this?
In crystal reports there is underlay following section check box through which we can achieve this. I want to use this feature because in my details section there is one column (unit area) which repeats its data in each row due to which the totals at group footer comes wrong (due to duplicate unit area)
Workaround to get correct totals will also work for me if underlay is not possible. I googled for underlay feature and the only solution I could find was of using Matrix as per below msdn post. Let me know if there are any other possible workarounds or solutions.
http://social.msdn.microsoft.com/Forums/en-US/1284e27c-de34-4670-a214-67fbe18470b3/underlay-following-section-like-crystal-reports?forum=sqlreportingservices
This issue has been very frustrating to figure out, but I finally figured out how to mimic Crystal's Underlay Following Sections behavior in SSRS!!! I stumbled across the solution and after finding it I have searched on the method I used and found many articles referencing it, but never equating it to the solution for mimicking Crystal's Underlay property. Here's how I did it.
I had three groups - call them Company, Business, Employee - and details. Traditionally, these groups would be laid out on separate rows like this:
Company
...............Business
..............................Employee
...............................................Details
Using a table, I put the columns all on the same row - the details row - instead of multiple rows.
Company...Business...Employee...Details
Now, this should result in duplicate values for each of the groups for every detail set in my dataset. And if you have this set up and run it, you will see that's exactly what you get. Let's fix it.
Click anywhere on the table to bring up the tablix control region.
Click on the control for the details row; this should highlight the row.
Open up Properties and scroll down to the section called Other and look for a property called HideDuplicates. There should be a drop down list with all your groups.
Select the group that represents the parent group, in my case it was Company.
This property basically hides all of the group duplicates providing you with the Underlay look you are looking for. All you have to do is save and preview!
I used this method on other reports that I wanted one of the groups, say the Company group, to be on a line all by itself. No problem, just remember that as far as the details row is concerned, the Business group is now the parent.
Hope this helps
I am rendering a scatter plot every 5 seconds where the X-axis denotes time and Y-axis denotes a set of names ordered alphabetically.
A set of data points (say, 'X's) can optionally be grouped into a category and so I use a color to show this. Therefore all 'X's with the same color belong to the same category and so on.
Problem: I have tens of thousands of 'Name's and they can appear randomly on the graph at some point in time. The real purpose is to provide the user with a graph that provides the ability to monitor these names. Therefore, every time I render the graph, I get the list of points to be rendered and the underlying graph library: Flotr2 takes care of assigning colors to the sets of points. Therefore, if the dataset contains two categories of points, it assigns two colors and if a point belonging to a new category arrives, it assigns a third color. As a result of this, what I am observing due to this is a flicker effect:
And when the point disappears, the colors revert back to the ones before. Is there a good way to solve this problem? I have two specific problems:
Colors keep changing for every new point being added
A new point added somewhere shifts every other point vertically in either direction. For instance, if Category 2.5 is added, it ends up shifting Category 2 down and Category 1 up because the alphabetical order should be preserved.
In a scenario which is highly dynamic, such a graph tends to be useless because of the dynamism it shows visually. One obvious solution I can think of is to pre-allocate space for all points and all categories possible in the graph so that an appearance of a new point will not change anything but it just draws a point somewhere. However, I am not clear if this approach is ideal for large data sets where the set of names and categories change often.
Is there a good way to solve this problem? I am open to other graph types that mitigate this problem. In short, I want a real-time display that is capable of showing the appearance of new names on a time axis.
currently I have a requirement to display related items in a multi level grid.
that is great grandparent -> grandparent-> parent-> child
For example:
Country-> state->City->Street is the order of display.
The proposed solution is to display all these in a multi level grid (4 levels maximum).
Country
-> state
->City
->Street
Since I am not comfortable with this solution with respect to usability aspect, I am looking for a UI design pattern that will break up the display into logical units.
thanks
When you have data objects from two different levels of the same hierarchy, you can:
Put each level in a different window (or page, lightbox) and allow navigation between them. I call this drill-down.
Put each level in a different pane of the same window (or page), where placing focus on an object in the superordinate pane populates the subordinate pane. I call this master-detail (this includes cascading lists and is not to be confused with drill-down above).
Put both levels in the same pane, indenting the subordinate objects under each superordinate object, and usually providing controls to hide and show the subordinate objects for each superordinate object. I call this a tree.
With a hierarchy of multiple levels, you can use any combinations of these. Here are some guidelines for deciding how to relate any adjacent levels in the hierarchy.
Put the levels in a tree if
The number of levels in the hierarchy varies arbitrarily with each data object (like folders).
The user will be regularly comparing the subordinate objects of two or more superordinate objects that are near each other in the sort order (the user can then expand the tree for both superordinate objects to see the suboridinate objects all at once).
Put the levels in a master-detail relationship if:
You’re showing more than one or two attributes per object (e.g., more than just the name), and each level has different attributes.
There is more than one class of subordinate objects for the superordinate objects.
There are many-to-many relations that you’ll be displaying.
For details see Hierarchy Visual Design
Put the levels in a drill-down relationship if:
The amount of information to show for each level is simply too large to fit in a single reasonably sized window.
The task dictates that the user may transition from one level to the other but the user doesn’t use both levels at the same time (in general, you want to avoid making the user navigate back and forth between windows).
You’re going to need separate windows for different high-level tasks anyway. This implies you’re going to provide a means to directly navigate to the subordinate window without “drilling down” through the superordinate window
Generally drill-down only makes sense if both windows are primary windows (or pages). The subordinate window should not be a dialog box, property window, or lightbox. If you don’t have enough to show in the subordinate window to justify a full-size primary window, then use a master-detail. Compared to master-detail, a drill-down dialog:
Introduces inconsistency in saving changes.
Creates modes or ambiguity in the z-order (or, in the case of lightboxes, ambiguity on the function of the Back button).
Lacks a pulldown menu with its basic controls for editing and undoing (in Linux and Windows).
Does not support window resizing (in Mac and Windows) to provide more flexible viewing of the contents.
For more on all the above see http://www.zuschlogin.com/?p=31.
A common way to break this down might be to do it in 2 or more steps with navigation between them (i.e. navigation to another page or opening a modal dialog etc.)
So you could display the first grid/table with 1 or 2 or 3 levels of your hierarchy, and a navigation link to display the remaining levels in a second or subequent lists/tables.
If you're looking for confirmation of some established patterns you could choose from (or combine) these:
Master/Detail
Tree Table
or
Cascading Lists
Tree? Like a Windows Explorer view of a file system?