I'm trying to design a cube with iccube and following the walkthrough, I can't seem to be able.
In the walkthrough (http://www.iccube.com/support/documentation/user_guide/walkthrough/walkthrough.html) when creating a dimension, there is in the picture the "Is fact indexing" option available. But, when I' trying to create a multidimensional dimension, with any table, the option is never shown. The one I have are:
Name*
Table*
Unknown member
Time dimension
Default time dimension
Is indexing by range
So, when I get to add the cube, it only has the calc measure section.
Thanks!
Nicolas, the option 'Is Fact Indexing' is no more available that way. To reply to your question, once you've created a cube, you need to add some Facts (see the icon on the right side when hovering over the newly created cube). Those facts are also called 'Measure Group'. A cube can have one or more 'Measure Group'; each group being attached to a table.
Related
I’m relatively new to Tableau and have a question.
I want to create a heatmap show the location of two different groups of people. I’ve learned how to overlay maps using dual axis but the problem I keep running into is that each group requires different filters to aggregate the data the way I want.
Basically, I want to show:
Group1.id IF charge_id IS NOT NULL
And
Group2.id IF status = ‘ACTIVE’
Whenever I create a calculated field with one of the above calculated fields and place it in the filters box it automatically removes the other group from the map because the filters contradict one and other.
Help is much appreciated 😊
The filter shelf applies to the entire worksheet, so if you want to “filter” each field selectively, use an IF expression in a calculated field that evaluates to null when you don’t want that field in the view.
Give sample data if you want more detail
In graph viewer, is it possible to not start with a random vertice? When I uncheck the option, the graph simply disappears. But I don't get to choose the starting point anywhere.
And when I set up the configuration it is not saved to the graph view. Is this going to be fixed? I find it kind of a key feature for a graph-database to be able to easily explore the graph.
I am working with arrangodb 2.3.1
Anyway, besides some trouble with the graph viewer, I really enjoy this fancy multi model database! And for me it is a big plus it's made in Germany! Keep on the great work arangodb-team!
As already mentioned in the comments you can select the start vertex later.
Click on the Filter icon (see image)
Two input boxes should appear - Attribute name and Attribute value. Type in _key into the left box (see image)
Type in a known _key of a vertex (or another attribute) into the right box (see image)
Simply hit return and you should see the vertex with the given _key value
I’m absolutely stumped by what I suspect is probably simple for those experienced with Access. I’m brand new to Access (2010) and studying a lot, but unfortunately still confused by many basic concepts. I’m embarrassed to admit that I have spent about 40 hours trying (unsuccessfully) to solve the specific issue below. Please forgive me if I haven’t included enough detail here - I’m not sure how much someone needs to know to address this. I’m happy to edit and/or provide more information.
My question:
How do I create a Form for creating new records / editing existing records in Table1 where two fields in Table1 have different values from a single field in Table2? (I have better detail below)
I want the Form to have all the records from Table1. I have tried many different ways with queries, sub-forms, etc., but can’t pull it off. I’m fairly certain the issue is related to how I address Table2. Ideally, the user would be able to select from dropdowns in the form for the two fields to be updated in Table1.
I am including screenshots of a mockup of my intended Form concept, the object Relationships as I currently have them, the design and datasheet views of Table1 and the design and datasheet views of Table2.
“Table1” above is “t_PEOPLE” in the images while “Table2” is “t_COLORS.”
The object relationship types are currently one-to-many with enforced referential integrity (cascade update related fields) and the join properties are "include ALL records from 't_PEOPLE' and only those records from 't_COLORS' where the joined fields are equal."
I'm happy to send the actual database file if that helps.
I will be very grateful for any guidance - thank you!!
The general approach to this is as follows:
A) If I understand what you're trying to do here, your t_colors table is usually referred to as a Reference table or Lookup table. You need to make one form to add, edit, and delete records in this t_colors table. How the user accesses that form varies. I'll get to that in a minute.
B) The form for your People table needs to have drop down menus for your two color selections. In the dropdown menus' RowSource, you will use a query that looks up values in your t_colors table.
C) Depending what you are using your colors for in t_people, you should consider making a third table with PeopleID and ColorID in it. It would then link to both t_people and t_colors. This would allow you to have multiple colors specified for a single person, and you wouldn't be limited to two. In your People form, you would use a subform for these colors. The subform would probably need to be a datasheet form or a continuous form. If you are using a datasheet form for your people form, then you would need to use a datasheet form for the colors subform.
If the user wants to use a color that isn't already in your t_colors table, you need to give them a way of inserting that color. There are various approaches to this. You could use a union query in the dropdowns RowSource that shows a "" option. If selected you would bring up your Colors form and when they close the colors form you have to requery your dropdown menu. Or you could insert the color for them using VBA when they enter a value that is "Not In List" (an event that Combobox's have).
Please note that the relationships you've defined are not overly helpful or important in this case. Yes, they can be helpful when it comes to using the Update Cascade or Delete Cascade features. But quite truthfully, relationships are basically for programmers, to make sure you get an error if and when referential integrity is violated. Users should never see these errors and properly designed forms will prevent them from occurring. The main reason to use them is that it will force you to design your forms properly by giving you an error when something is wrong, hopefully during your own testing phase of the project.
I am trying to implement minesweeper solver in lisp. I know this is not rare problem but i didn't find any article that can help me with that. At start i have a minefield as input with numbers on uncovered fields. Algorithm should be finished when all mines are found. So, in every step i have to check what fields i can put in my list of mined fields and to choose one field from my list of not mined fields and open it. Later i will check is my list of mined fields completed and if yes algorithm is done. I would appreciate any help. I don't ask for source code, but i need good ideas. I am not experienced with this kind of problems.
I HAVE to use A* algorithm. And i don't need to open all unopened fields...I need to find positions of all mined fields. And of course it has to be the SHORTEST path to do that. When i find positions of all mined fields algorithm is finished. So, once more, i need to find all mined fields with optimal number of opened fields. And of course i need a heuristic for my algorithm which will help to choose one of all safe unopened fields.
And that list of safe unopened fields needs to be determined after every opening. So i need to call main function, that function will check did i find all mined fields, if not, then all safe adjacent unopened fields needs to be added to list of paths. And a path with best heuristic will be chosen
I did implement a minesweeper solver in my first year at the University so I can give you some tips. (This is not using A* algorithm)
Important - Not all positions are solvable.
Backtracking of the whole mine field is a bit complicated for advanced difficulties (complicated=takes some time, consider all the possibilites to place 100 mines in a 30x30 field).
You can solve everything locally, in the same way a human solves the minesweeper. The potential of this is to give the users a hint how to continue instead of solving everything.
Example:
Have a separate mine field where you do the solving
Find all the unsolved cells that have a solved (number/ known mine) cell close enough (2 cell distance)
For every such cell, take a 5x5 neighborhood with the cell in the center, find every possibility (backtracking) and check if the possibilites have something in common (mines/non-mines), if yes, you can check the mines and uncover the non-mines.
Repeat while you can uncover something.
When you cannot uncover anything and the number of remaining mines is small enough, you can try backtracking over the whole field.
I hope I remember it correctly, I did some proofs why the 5x5 area is enough to check but it was almost 10 years ago.
You do not need the A* algorithm; its purpose is to find the shortest path in a graph (such as the shortest path between two places in a map, or the smallest amount of moves that will solve a puzzle). You will probably want to use a technique that is known as backtracking.
As long as there are unopened fields, pick an unopened field that is next to an open field, and tentatively flag it as a mine. Then, look at an unopened field that is adjacent to the previous one as well as to an opened field, and flag that one as a mine too, if this doesn't contradict the adjacent numbers - if it does, flag it as safe instead. Continue. Eventually, you will have looked at all unopened fields that surround the current area and have found one possible way of flagging the fields as safe or unsafe. However, this was based on several guesses, so now you need to go back to the last field where you made a guess and then make the opposite guess and then move forwards again to get another possible flag combination. Then, go even further back, revise your guesses, and so on. This can be implemented quite neatly with recursion. Eventually, you will have a collection of possible flag combinations. If you can find a field that is safe in all possible flag combinations, open that field. Otherwise, pick a field that is safe in as many flag combinations as possible.
I'm having a bit of a time trying to get Dojo grids (1.5) to play nice. Specifically I've spent about two weeks of work trying to implement a grid that allows for our result set data to collapse into rows, where rows can be expanded. Data comes in as a full set in JSON format, using ItemFileReadStore as the store. Any subsequent sorts or pagings are handled by GETing a new json from the application, and passing in new query parameters in the url.
The nested data was only two layers deep - a top layer to always be displayed and an array of child data with identical structure as the top layer. Each node has a unique ID and a cluster ID - on a parent node the unique ID and cluster ID will match.
I was initially very excited with TreeGrid - but I couldn't see how I could format it to do what I needed - namely eliminate the 'summary row' and one extra row full of null cells (???) that I just couldnt figure out how to remove unless I focused the query to only one cluster. I studied the test examples, built many test pages myself, tried to understand the forestModel, which for what I could tell was unnecessary... I found so little documentation, and sources I found online hinted that TreeGrid might not be reliable...
So I decided I would try to implement the expandable/collapsible rows in dataGrid.
I flattened the JSON data and added another attribute to indicate being a top level node ('alwaysShow' = true). I built my grid programaticaly and applied grid.filter() to pull only those top level nodes. I modified that filter by extending the ItemFileReadStore _FetchItems "filter" method to allow for OR querying instead of AND, and also modified it to allow for keys to point to arrays - when a top level node (small +/- icon in the cell) is clicked, the cluster ID of the parent node is added to the grid.filter.allowed[] and the filter is updated, allowing nodes with that cluster_id value to be displayed.
This worked fine on my small test set of five records (although id say a little slugish...) - but now I am pulling ~900 rows back from the application, and on expanding large clusters (~80 rows) I am seeing a very long flash of blue and white on the filter updates. I've spent most of my day trying to step through in firebug to find where its happening, but the dojo logic is so spread out. Seems to be happening before the call to _Grid.js defaultUpdate.
Its so bad that I am considering trying again with TreeGrid. Im also considering just doing this by hand... Im kicking myself for spending so much time trying to get Dojo to work to begin with. I would also consider a commercial "JSON->table with collapsible row" library if anyone has any recommendations...
Any suggestions or insights? Familiarity with the flashing problem or how I could adapt TreeGrid to my needs? I'm aware this is a bit of a rant... Many thanks for any help.
-robbie
EDIT: I eventually gave up trying to get Dojo to do what I needed and coded it myself in less than a day. Not the best use of three weeks...
EDIT:
I just found a solution that works for me, I have added the following CSS:
.dojoxGridSummaryRow {
visibility: collapse
}
Basically the summaries are probably still created but they are not visible nor taken into account in the table layout. That's good for me. Hope this will solve your issue.
This won't help but just to let you know that:
"- but I couldn't see how I could format it to do what I needed - namely eliminate the 'summary row' "
is the very EXACT same thing I'm trying to achieve and did not find the solution even though this looks like a very simple feature... Will let you know if I found a solution...