I want to manage some datas by intervals on my database like that :
It is possible to do that on an unique table or I need 3 tables, one for each color (with FK) ?
Real example :
Actually, on my app I use this on a dataGridView and on my database :
It is possible to set / modify or everything on three databases. I manually add the equivalency (green) but for some number with a little different is it the same equivalency, so it's - for me - interesting to use numeric intervals
I'm not an expert on modeling databases but this is how I solve your scenario.
I'd create two Range Tables, one for storing column values, and other one for row values, each table will have same structure but since you need to represent the final values in a matrix way i decide to consider two tables(instead of merging them in one, its possible but then you'll need more effort to showing data from "Values"). As you can see i've considered a IdEquivalency columns, this will be useful for showing the data ad needed.
Finally the table Values(for green values) has two FK(one for each range value), and the value stored.
This is still a basic idea, but I'm sure you get the point.
Considerations:
Change Table Names according what its value represent.
Related
We received some generic training related to TM1 and dimension creation and we were informed we'd need separate dimensions for the same values.
Let me describe, we transport goods and we'd have an origin and destination province and in typical database design I'd expect we'd have one "province" reference table, but we were informed we'd need an "origin" dimension and a "destination" dimension. This seems to be cumbersome and seems like we'd encounter the same issue with customers, services, etc.
Can someone clarify how this could work for us?
Again, I'd expect to see a "lookup" table in the database which contains all possible provinces (assumption is values in both columns would be the same), then you'd have an ID value in any column that used the "province" and join to the "lookup" table based on ID.
in typical database design I'd expect we'd have one "province" reference table, but we were informed we'd need an "origin" dimension and a "destination" dimension
Following the regular DB design it makes sense to keep two data entities separate: one defines source, other defines target. I think on this we'd both agree. If you could give more details it would be better.
Imagine a drop down list: two lists populated by one single "source", but represent two different values in DB.
assumption is values in both columns would be the same
if the destination=origin, you don't need two dimensions then? :) This point needs clarification.
Besides your solution (combination of all source and destination in a table with an unique ID, which could be a way of solving this), it seems it's resolvable by cube or dimension structure changes.
If at some dimension you'd use e.g. ProvinceOrigin and ProvinceDestination as string type elements, and populate them from one single dimension (dynamic attribute) then whenever you save the cube you'll have these two fields populated from one single dimension.
Obviously the best solution for you depends on your system architecture.
I have imported 2 tables from SQL Server to Power BI desktop in which each table contain one column having binary data. And these columns are used to create the relationship between that two tables.
When I proceed to create the relationship in Power BI these columns are not visible. I also tried the conversion of that binary column to text and try to create the relationship but it shows an error: Can´t create a relationship between two columns because one of the columns must have the unique value.
How can I create the relationship in Power BI desktop using Binary data columns?
As TDP stated, there has to be duplicate values, whether or not it is through an error in your data source. Please review the query editor and enable viewing column distribution and check to see if there are duplicate values in either of the columns you wish to use.
You will either need to modify your data source or make the changes within query editor directly to remove these duplicates.
It should not matter what data type you are using (binary/text) if there are duplicates. You will not be able to stop duplicates occurring just by changing the datatype.
EDIT: Oops, old thread. The answer still applies, please remove if unnecessary.
Can´t create a relationship between two columns
because one of the columns must have the unique value
This is your issue. One end of the relationship must have a distinct set of values.
Once you converted binary to text you would have been able to create the relationship if you had a distinct set on one side.
This isn't to do with binary being converted to text.
I'm trying to create a multidimentional database from a preexisting database using SQL Server Analysis Services. My problem is that the original database stores all information on a varchar field called "value". What's in that field depends on another field that holds the type of statistic. So I can have for example a fact with statistic_type "number of products sold" with value 1000 and another with type "cost of material bought" with value 5000. The values can have completely differentic meanings, some are numeric values, others are percentages and others are strings.
How do I turn those into measures. Should the statistic_type be a dimension of the cube and have the value as a measure? Does a measure always need to have a numeric value? Should I separate the fact table amoung several tables, one for each type of statistic? Or is there some sensible way to create a cube using just the one table.
It's the first time I'm working with multidimentional databases and SSAS so I'm a little lost.
A measure always needs to have a numeric value. In fact, you will probably have to cast the value column as a numeric datatype in your Data Source View in order for it to even be a candidate for a measure in your cube.
You should make statistic_type a dimension and "value" a measure. It's ok to just use the one table, although it might be easier to work with if you make a lookup table of the distinct statistic_types.
I need to store multiple 4 letters strings for each database row but the amount of 4 letter strings could be different every time.
So would it be easier to setup a new table and add a new row for each 4 letter string with the id of the related row in the other table ?
For normalisation reasons and performance as well as being able to later perform efficient queries, you would want to store it in a related table.
Main : ID, other columns
Related : Main_ID, 4-letter-string
If there is nothing else you will store in the Main table, then just store them as multiple rows, and relate via a common ID.
You can store it on one record and still search efficiently, if FULLTEXT searching is turned on, but I doubt your 4-letter strings are natural language words, so it may not suit as well.
I have a table that holds information about a particular Object, Say Item and has columns
ItemID, ItemName, price, ItemListingType.....LastOrderDate
One of the bits of information, ItemListingType could be one of 10 different types
such as:
private, gov, non-gov, business... etc (strings) and could be extended to more types in future.
Should I be using a column inside table ITEM or should I Use a separate table with two columns and put a foreign key in Item table to reference that (a one to many relationship)? Like:
ListingTypeID int
ListingTypeName varchar(MAX)
EDIT: how many values for a column, you will consider to use another table for that
2, 4 or what ?
Thanks
Use a separate table to store this kind of reference data. This is a tenet of normalization and will also enable easier caching because you are separating read-only and read-write data. my two cents...
Separate table.
What if you have a listing type not yet used?
Or delete the last item with type x?
Or need to change a value?
These are insert, update and delete anomalies, which is one reason for normalisation
I would definitely go for a "lookup" style column; that way you are not stumped when there future additions to the list of permissible listing types. You are also reducing redundancy and making it easier to change the designation of aparticular type of listing (if "gov" changes to "government agencies", then you only have to change it in one place).
You should do it with the second table that holds the ListingTypes and link to the id of that table from the one with the Objects...
Take a look at Relational Database and Relational model.
In situations like this I ask myself:
Can the Item have an undetermined number of Listing types? If yes, different table.
Do the specs say that there will never be more than 3 types? Depends. Sometimes I'll still go with a separate table, sometimes not. You get a feel for this after a while.
Will the Item ALWAYS have a single listing type? If yes, same table, single column.
Now to take matters one step further.
If an Item has zero or more listing types AND those listing types are actually shared (in other words two items could have the same listing type, then we have 3 tables: Items, ListingTypes, and a cross reference table to support a many to many relationship.
Clasically, you should use an extra table, because you won't have any duplication that way. It will also allow you to change the value for this listing in a single place. However, if you are very very sure that no types will be added, keep the column.