I need to calculate a weighted grade from 3 criteria (Health, Structure, Form) for each tree. Each tree has a letter grade (A-F) for each of the criteria. The overall grade for each tree is weighted by the criteria.
I have a TREE TABLE with fields: tree #, a health letter grade (A-F), a structure letter grade (A-F), and form letter grade (A-F))
I have a GRADING SCALE TABLE with fields: letter grade (A-F), numeric grade (1-0)
I have a WEIGHTED TABLE with fields: criteria (health, struc...) and weight (.2, .6..)
I have a one-to-many relationship from the GRADING SCALE TABLE [letter grade] to each of the criteria on the TREE TABLE [health letter grade], etc. Many trees can have the same grade.
When I first tested a query showing the numeric grades for each tree, but this resulted in triple records for each tree and these were not the correct values.
I figured I would step the process and ran a query using the switch function, which provided the correct numeric grade for each tree for each criteria (Yay - this was based on a similar post that calculated numeric grades from letter grades)
I used:
HealthNum: Switch([Health]="A",1,[Health]="B",.75...,True,"Missing a grade")
BUT, I am struggling to run a query to calculate the weights for each criteria and the ultimate weights.
I tried for each of the tree criteria: HealthWtd: [HealthNum]*[Criteria_wt]; where the criteria field was set to [Criteria]="Health"
When I set [Criteria]="Health" and I put in the [Criteria]="Structure" in the OR position, I end up with two records for each tree. One record has a correct health weight and an incorrect structure weight, while the other record has an incorrect health weight and correct structure weight.
Some of the caveats: the grading scale and weights are likely to change from time to time, so I would rather use a relationship over the switch function. My boss has disliked the use of excessive nesting.
I feel like this should be an easy task and cannot for the life of me figure this one out.
With current table structure, either hard code weight factor in query expression or use DLookup() to pull correct Weight factor from table. Could also use DLookup() for Scale.
Example for Health:
DLookup("Weight", "Weighted", "Criteria='Health'") * DLookup("Number", "Scale", "Letter='" & [Health] & "'")
Tree table is not normalized. If it were, could join to Scale and Weight tables to properly associate records and calculate weight. Then a CROSSTAB query could produce the horizontal output.
Normalized table which could be joined to other tables:
+---------+-----------+-------+
| TreeNum | Criteria | Grade |
+---------+-----------+-------+
| 10 | Health | A |
+---------+-----------+-------+
| 10 | Structure | B |
+---------+-----------+-------+
| 10 | Form | C |
+---------+-----------+-------+
| 12 | Health | B |
+---------+-----------+-------+
| 12 | Structure | B |
+---------+-----------+-------+
| 12 | Form | D |
+---------+-----------+-------+
Related
I will preface this with that I am both relatively unfamiliar with SQL and dc.js. I feel the solution to this is likely pretty simple.
I am currently drawing a group of charts based on a join of two tables that results in a form similar to the following:
Subject | Gender | TestName
------- | ------ | --------
1 | M | Test 1
2 | M | Test 1
1 | M | Test 2
2 | M | Test 2
Essentially, a lot of unique data that is repeated on the join due to TestName changing per subject. The join is on Subject.
I have one bar chart for Gender, which can be either M or F. I also have a bar graph of a count of each test (TestName) and how many subjects were present in that test. As you can tell from the join, a single subject can and often is a member of more than one test.
My issue is that when I crossfilter this data, the counts for each test is correct (here, it would be 2 each), but my gender information is inflated (4, instead of 2) since it counts what should be each unique subject every time it appears in this joined data set. I want my charts to display n Subjects for Gender, but instead it displays n * 'number of tests'.
Is there a way to chart the correct count per test case but keep my other charts displaying only a maximum count of unique subjects while keeping my crossfilter working?
I need to build application where users can search/filter products by multiple characteristics. There are 25 product groups. Each product group have around 10 product characteristics. I have a few data base design solutions, but none of them seems appropriate enough:
Create 25 tables per each group with column names storing product group characteristics.
Create one table with all products and as many columns as there are product characteristics (~ 200)
EAV: create 1 table for all characteristics and 1 table with all products and their attributes stored in rows, not in column names. This solution will result in writing a lot of application code, because I won't be able to select a product with all characteristics in one row. I will have to write application code to group mysql results.
I believe there are already solutions for problems like mine. Thanks for help.
EDIT:
In most cases the characteristics in groups are entirely different. These are starter/alternator components. Only around 25% of characteristics can overlap, like physical characteristics, length, diameter, etc.
I would suggest the following:
Create 3 tables; Groups, GroupCharacteristics,Products.
Groups is linked to both tables.
GroupCharacteristics will have the list of characteristics, using 3 columns, (1)GroupName,(2)CharacteristicName,(3)Mapping [Values for mapping could be C01,C02 through C10]
You will use mapping later on.
One group has many characteristics so it's a one to many link.
Products will have 12 Columns; (1)ProductName/Id,(2)GroupName,(3)C01,(4)C02 ... (12)C10.
The C** columns will be filled with the values of the related characteristics in order to keep them mapped correctly.
Groups:
[GroupName]
1-Vehicles
2-Furniture
Characteristics:
[Map][Group][Characteristic]
1-C01 | Vehicles | Length
2-C02 | Vehicles | Volume
3-C03 | Vehicles | Type
4-C01 | Furniture | Height
5-C02 | Furniture | Volume
6-C03 | Furniture | Length
Products:
[ProdName][Group][C01][C02][C03]...
1-Car | Vehicles | 2 | 50 | Hatchback
2-Jet | Vehicles | 10 | 70 | Null
3-Table| Furniture | 1 | null | 1.6
4-Cup | Furniture |0.1 | 0.12 | null
String col = Select Map from Characteristics where Group = 'Vehicles' and Characteristic = ' Type'
-- this returns the column (in this case C03) then --
String sql = "Select ProdName from Products where Group = 'Vehicles' and "+col+"='Hatchback'"
-- this will build the query in a string then you just execute it --
execute(sql)
-- in whatever language you're using this is just the basic idea behind the code you have to write.
I've been racking my brains for a while and I'm sure there is a simple solution to it, but for the life of me it's not obvious.
I want to query a database in MySQL Workbench to return a set of serial numbers for a given part number, which is of a fairly basic form:
Select serial_num as sn12345
from process
where part_number = 12345
Thus my output is
sn12345
---------------
0000001
0000002
etc
Now I have a number of part numbers I want to get the serial numbers of so that my output is like
sn12345 | sn12346 | sn12347 |
------------------------------------------
0000001 | 0000005 | 0000008 |
0000002 | 0000006 | 0000009 |
Assume that there are more columns than just these. However, I do not want to UNION the query as I want output in individual columns. Also, there may be different numbers of serial number entries for each part number, i.e 100 for one, but 1000 for a second, and 5 for a third, etc, so I'll probably have a lot of NULL entries.
Thanks in advance!
Trying to summarize in as few of words as possible:
I am trying to create a system that tracks the various products an individual can sell and the commission percentage they earn on that particular item. I am thinking about creating reference integers for each product called "levels" which will relate to their commission percentage in a new lookup table instead of a single reference point.. Is this overkill though or are there any benefits over just placing inline for each record?
My gut tells me there are advantages of design 1 below but not sure what they are the more I think about it. If I need to update all individuals selling product X with level Y, indexes and replaces make that easy and fast ultimately in both methods. By using design 2, I can dynamically change any "earn" to whatever percentage I can come up with (0.58988439) for a product whereas I would have to create this "level" in design 1.
Note: the product does not relate to the earn diretly (one sales rep can earn 50% for the same product another sales rep only earns 40% on).
Reference Examples:
Design 1 - two tables
table 1
ID | seller_id | product_id | level
-----------------------------------------------
1 | 11111 | 123A | 2
2 | 11111 | 15J1 | 6
3 | 22222 | 123A | 3
table 2
ID | level | earn
--------------------------
1 | 1 | .60
2 | 2 | .55
3 | 3 | .50
4 | 4 | .45
5 | 5 | .40
6 | 6 | .35
Design 2 - one table
ID | seller_id | product_id | earn
-----------------------------------------------
1 | 11111 | 123A | .55
2 | 11111 | 15J1 | .35
3 | 22222 | 123A | .45
(where earn is decimal based, commission percentage)
Update 1 - 7/9/13
It should also be noted that a rep's commission level can change at any given time. For this, we have planned on simply using status, start, and end dates with ranges for eligible commission levels / earn. For example, a rep may earn a Level 2 (or 55%) from Jan 1 to Feb 1. This would be noted in both designs above. Then when finding what level or percentage a rep was earning at any given time: select * from table where (... agent information) AND start <= :date AND (end > :date or END IS NULL)
Does level mean anything to the business?
For instance, I could imagine a situation where the levels are the unit of management. Perhaps there is a rush for sales one quarter, and the rates for each level change. Or, is there reporting by level? In these situations is would make sense to have a separate "level" table.
Another situation would be different levels for different prices of the product -- perhaps the most you sell it for, the higher the commission. Or, the commissions could be based on thresholds, so someone who has sold enough this year suddenly gets a higher commission.
In other words, there could be lots of rules around commission that go beyond the raw percentage. In that case, a "rule" table would be a necessary part of the data model (and "levels" are a particular type of rule).
On the other hand, if you don't have any such rules and the commission is always based on the person and product, then storing the percentage in the table makes a lot of sense. It is simple and understandable. It also has good performance when accessing the percentage -- which presumably happens much more often than changing it.
First of all, using id values to reference a lookup table has nothing to do with normalization per se. Your design #2 shown above is just as normalized. Lots of people have this misunderstanding about normalization.
One advantage to using a lookup table (design #1) is that you can change what is earned by level 6 (for example), and by updating one row in the lookup table, you implicitly affect all rows that reference that level.
Whereas in design #2, you would have to update every row to apply the same change. Not only does this mean updating many rows (which has performance implictations), but it opens the possibility that you might not execute the correct UPDATE matching all the rows that need updating. So some rows may have the wrong value for what should be the same earning level.
Again, using a lookup table can be a good idea in many cases, it's just not correct to call it normalization.
I'm creating a query with Microsoft Access 2003 and had encounter an issue. I'm new!
I've got 2 tables. First table, i have a list of records that include the name, property name and the country state. Second table, i have a list of property names, the number of units in the property and the property's country state.
I will like to count the number of records in the first table by its state, meanwhile summing up the number of units the property has in the state.
What I encountered is, when I sum the number of units, the units repeats!
Taking for example;
Table1:
Name | State | Property Name
Mr 1 | State A | Building AAA
Mr 2 | State A | Building AAA
Mr 3 | State A | Building BBB
Mr 4 | State B | Building XXX
Mr 5 | State B | Building XXX
Table2:
Property Name | State | Number of Units
Building AAA | State A | 100
Building BBB | State A | 50
Building XXX | State B | 20
My Result:
State | Number of Units | No of Records
State A | 250 | 3
State B | 40 | 2
The result i want:
State | Number of Units | No of Records
State A | 150 | 3
State B | 20 | 2
EXPANDED
Assuming you are using the Access query builder, you will need to construct three Select queries:
1) Table1 will be the source table for the first query. Use the State field twice in the query, first as a Group By field and second as a Count field. (Any of the fields could have been used for the count, since you are only interested in the number of records.) Save the query for use in the third query.
2) Table2 will be the source table for the second query. Use the State field as a Group By field and the Units field as a Sum field. Save this query, too.
3) The third query will bring the information together. For the source, use the first and second queries, with a join between them on the State field. Select the State field (from either query) as a Group By Field, the CountOfState field from the first query as a Sum field, and the SumofUnits field from the second query as a Sum field.
While the actual amount of work done by Access in producing the final result will not change, the three queries can be consolidated into a single query by editing the underlying SQL.
The new query was produced by inserting the Table1 and Table2 queries into the third, final result query, one on either side of the INNER JOIN statement. The T1 and T1 in the new query are aliases for the embedded queries that eliminate ambiguity in referencing the fields of those queries.
The new query cannot be created using the Query Builder (although the original three queries provide the raw material for it). Instead, the SQL must be written/pasted in/edited in the SQL View of the Query Builder.
SELECT T1.State AS State,
Sum(T1.CountOfState) AS Records,
Sum(T2.SumOfUnits) AS Units
FROM
(SELECT Table1.State,
Count(Table1.State) AS CountOfState
FROM Table1
GROUP BY Table1.State) T1
INNER JOIN
(SELECT Table2.State,
Sum(Table2.Units) AS SumOfUnits
FROM Table2
GROUP BY Table2.State) T2
ON T1.State = T2.State
GROUP BY T1.State;