When you group things together in PlantUML, they tend to be placed next to each other horizontally.
Is there a way to group them together vertically?
Related
I am creating an Entity Relation Diagram for my database.
I would like to know if it's possible to make a dense table, I would like to compact all my rectangle in the table.
On the following picture, you have an example of a table of my diagram. I would like to reduce the margin between all lines to create a dense table.
Yes, make sure you select the whole row before resizing the row. There's currently no resize feature for a selected cell, which in other cases does not seem technically correct.
I found the solution, it was really simple:
Click on a rectangle.
Click on right, on the tab "Arrange" and change the Height Size.
I've been tasked with looking into Neo4j for our business needs. I've created some very small graphs to get used to the cypher syntax.
We have a scenario where a user will be able to search via many options which will need to then need to show their related data and keep track of these available items in stock as the results are filtered down. As a simple example (but the same design as what we will need). We might have 4 items of clothing (T-shirt, sweater, jeans, shirt) and the user can select either one to reveal their sizes and colours etc and keep track of the number in stock. However the user should be able to select size or colour first instead to reveal the different items (t-shirt,jeans etc). Basically different combinations depending on what is selected.
Jeans (20 in stock) > red (6) > small (2) or large (4), Jeans > green > small or large, Small > red > t-shirts, shirts, Green > large > t-shirts
In this scenario would the colour and size nodes need to be repeated for each items or could I just create them once and reuse them? This is the thing I am a little confused about. We will have potentially 150+ (list of countries) choices for one option node and if each one has its own unique nodes related to it (but are repeated for other options as new nodes) that is a lot of duplicates? We could have a million plus nodes...
Sorry if this is a dumb question! Just trying to gather if there is a particular way of handling this kind of use case in Neo4j.
Thank you very much for your help and advice. :)
In essence, this problem can be traced back to the good old attributes vs. entities question in ER modeling
Using separate entites. Creating singleton nodes for colors, sizes, country etc. seems a working solution and you can reuse them for multiple items. For example, if you want to assign red color to an item n, you'd issue this query: MATCH (r:Color {name: 'red'} CREATE (n)-[:HAS_COLOR]->(r). To select all red nodes, use MATCH (n:Item)-[:HAS_COLOR]->(:Color {name: 'red'}). This approach makes is easy to select all available colors, e.g. MATCH (c:Color) RETURN DISTINCT c
Using attributes. Using properties should also work fine. Filtering is even easier (MATCH (:Item {color: 'red')) and listing available colors can be implemented with MATCH (n) RETURN DISTINCT n.color
In conclusion, as with most data modeling questions, you'll probably need to go through a couple of iterations to get the data model right and maybe do some benchmarking/performance tuning as well. Fortunately, Neo4j makes it very easy to experiment with different data models.
There's often many ways to create your data model, and you'll have to weigh the pros and cons and figure out what may work best.
One aspect of consideration, attributes (properties) vs entities, Gabor covers in good detail.
Another aspect, just considering entities, is whether you want to use a tree structure, drilling down to a specific item whose attributes are defined by the nodes above it in the tree, or
For example, you might have a tree like this:
(jeans:Clothing:Attribute{type:'jeans'})-[:COLOR]->(jeansColor:Color:Attribute{type:'red'})
(jeansColor)-[:SIZE]->(:Size:Attribute{type:'small'})-[:QUANTITY]->(:Stock{quantity:2})
(jeansColor)-[:SIZE]->(:Size:Attribute{type:'large'})-[:QUANTITY]->(:Stock{quantity:4})
In this model each successive node in the hierarchy only has a single parent. The :Color node with type 'red' would only be applicable to the :Clothing node for 'jeans', and there would be other :Color nodes for 'red' in different hierarchies for different types of clothing. Similarly, :Size nodes would only have meaning within their hierarchy, so the 'small' and 'large' sizes above would only be applicable to red jeans, and the :Stock nodes would be specific to the hierarchy as well. We're using a second label :Attribute on :Color and :Size nodes so we can address those nodes more generically if we want.
Queries for stock at each level would use variable-length relationships down to :Item nodes and sum the quantities like so:
MATCH (:Clothing{type:'jeans'})-[*]->(item:Item)
RETURN sum(item.quantity) as stock
Queries for type would work the other direction (note we can use the :Attribute label instead of :Color here if we wanted):
MATCH (:Color{type:'red'})<-[*]-(clothing:Clothing)
RETURN collect(distinct clothing.type) as clothing
This model requires fairly rigid trees, and many duplicated nodes (as nodes with the same properties need to be duplicated across different branches of the trees).
An alternate model to consider is one where the attribute nodes (:Clothing, Color, :Size, and so on) have relationships directly with the related item, so each item is connected to all attributes which apply to it, similar to point 1 in Gabor's answer.
In this model, there is only one of each attribute node, so you won't have to deal with node duplication, but as the number of items in your db get larger, the work done in your matches might get more complicated, since you would be looking for item nodes at the intersection of all the items connected to the attributes you're searching for (so to find small red jeans you would expand to all items from each of the small, red, and jean attribute nodes and only keep the ones that are common between the three).
I have created a table like below. The table use a dataset
I want to add several cells within one of the row like below and be able to query through the same dataset and most of all, be able to leave the other rows intact (see below).
Issue is I cannot do it within the table.
One of my workaround solutions, which is not satisfying to me , is to to create a rectangle then add another table / matrix within that rectangle (like I did in the image above). Then superimpose the rectangle in one of the cell of the table / matrix I want to split. However, when I'm deploying the report, I have an error tablix ‘Tablix15’ has a detail member with inner members. Detail members can only contain static inner members
The other solution is to create several columns then merge the cells of the rows I don't need and keep the cells I want. Drawback : Very tedious and lacking of flexibility
If you have any ideas on how to do it or fix the error above, I'm all ears.
Thanks!
Satisfying or not - the solution is to create a rectangle in the cell and add tablixes to this rectangle for the extra columns.
You are getting the detail member with inner members error as I imagine you are probably nesting Row Groupings.
Consider this example, showing a nested table.
When run like this I get the following error, exactly as you do above
The tablix ‘Tablix8’ has a detail member with inner members. Detail members can only contain static inner members.
This static inner members it refers to is saying that it isn't going to allow you to do more grouping at this lower level. This should be fine though based on the information you presented in the question, as you only want the values for this specific Row. Therefore, to remove the grouping, right click the Row Header, select Row Group -> Delete Group and then select Delete Group Only.
Note the (three lined) = symbol has disappeared from the Row header. When this report is then set to Preview, it now renders as expected
Hopefully this will solve your issue. Please let me know if you have further problems or queries on this.
Has anyone figured out a good way to make a hidden table/matrix column take no horizontal space?
I could use some crazy conditionals to dynamically determine the contents of the columns (effectively sliding them leftward as far as possible), but that is nasty, plus doesn't allow for varying column widths in the columns to the right of the one I want to hide.
The idea is that when a parameter is set to "Any" then the column with the corresponding value should display. But when the parameter is set to an explicit single value the report doesn't need to contain that column any more (it will be separately listed as a condition at the top of the report).
This lets me use the same report in different situations, some requiring hiding unnecessary columns.
P.S. I think Microsoft should add expressions for object sizes, and I think they should add CanShrinkHorizontally to the CanShrink(Vertically) that already exists...
I think you are looking at the Hidden property of the column. Something that is hidden will still take up space. What you want to change is the Visibility of the column. Right click on the column header and click Column Visibility and set it there.
It looks like you can hide groups, and groups can be rows or columns.
Click the down-arrow next to "Column Groups" at the bottom of the Design pane, and turn on Advanced Mode. Modify the Hidden property of the Static group representing the desired column. Poof! You've made the entire column take up no space.
I struggled with this and came up with a workaround/solution.
In my scenario it was critical to have the RowGroups EffectiveDate, Description AND TransactionID. I wanted to hide the TransactionID column, because it was part of the grouping I couldn't set the Columns Visibility.
Before
After
So what I did was Merge Cells for the Description/TransactionID Header (and called it Transaction Type) and also for the first row of the tablix "Opening Balance".
Set the TransactionID textbox Hidden: True
The trick was to make the [DESCRIPTION] Right BorderStyle: None
Then set the Cell under [TRANSACTIONID] Top BorderStyle: Solid and Top BorderWidth 0.5
Alternatively make the fore color of the column you want to hide white and set border styles appropriately.
I'm hoping to display a multi-valued column in a tabular UI format. By multi-valued column, I mean a column in which a single cell can simultaneously have multiple values -- aka a list of values. These values might be drawn from a short list of possibilities (e.g. an enumeration) or from a long list (e.g. another table). Imagine a table of contacts with a "friends" column that can refer to zero or more other contacts.
I need the ability to add new values, remove values, and ideally the values would be listed horizontally and word wrapped. I have a feeling that no out-of-the-box datagrid control on the planet can do this, but I figured this is the right forum to ask such a question.
I'm guessing that the current state of the art is to display the information in a form, not in a table (e.g. "details" of a row). However, we would like to actually display the values in a column of the table in a horizontally wrapped, in-line editable fashion. At this time, we are planning to use WPF, so I'm hoping for a WPF solution.
WPF is definitely the right tool for this job. I don't think you'll find it very difficult to get the layout you want once you understand a few core WPF concepts (mostly binding and DataTemplates). I would suggest maybe a ListView/GridView with a GridViewColumn with a custom CellTemplate containing an ItemsControl with its own DataTemplate...Simple, really ;-)