I m trying to show a table where sales are broken down by each sales person with their respective target
I would like to do it in the most efficient way as possible which I think mean fewer table as possible,
District are unique in Geographic split table,
I would like to show for each sales person their sales and target as in results table ..I think I ll have to go through hierarchy but I m not sure how to go about it
I have tried create a table for district and table for sales force with unique columns...but I can get them to show in one table without creating table for each type of sales force.
Thanks for any advice
Related
I have two tables, one has sales records and one has deduct records. There is a primary key that links the two tables called Sales_ID but there are multiple deduct records that belong to one sales record. I am trying to get the sales information and the deduct information on one line. See below for tables and the desired result.
Sales Table:
Deducts table:
Desired results:
SELECT SALES.SALES_ID, SALES.SALE_QTY, SALES.SALE_AMT
FROM SALES
LEFT JOIN DEDUCTS
ON SALES.SALES_ID = DEDUCTS.SALE_ID
I understand that If I add a deduct code in the select statement I will get duplicates, but I don't know what to try to avoid that.
thanks in advance!
Ok, so I have a Student table that has 6 fields, (StudentID, HasBamboo, HasFlower, HasAloe, HasFern, HasCactus) the "HasPlant" fields are boolean, so 1 for having the plant, 0 for not having the plant.
I want to find the average number of plants that a student has. There are hundreds of students in the table. I know this could involve transposing of some sort and of course counting the boolean values and getting an average. I did look at this question SQL to transpose row pairs to columns in MS ACCESS database for information on Transposing (never done it before), but I'm thinking there would be too many columns perhaps.
My first thought was using a for loop, but I'm not sure those exist in SQL in Access. Maybe a SELECT/FROM/WHERE/IN type structure?
Just hints on the logic and some possible reading material would be greatly appreciated.
you could just get individual totals per category:
SELECT COUNT(*) FROM STUDENTS WHERE HasBamboo
add them all up, and divide by
SELECT COUNT(*) FROM STUDENTS
It's not a great database design though... Better normalized would be:
Table Students; fields StudentID, StudentName
Table Plants; fields PlantID, PlantName
Table OwnedPlants; fields StudentID,PlantID
The last table then stores records for each student that owns a particular plant; but you could easily add different information at the right place (appartment number to Students; Latin name to Plants; date aquired to OwnedPlants) without completely redesigning table structure and add lots of fields. (DatAquiredBamboo, DateAquiredFlower, etc etc)
In SSAS is there a way to have a dimension relate to a fact table based on two columns in the fact table?
We have two tables: Location (Dimension) and Sales (Fact). The Location dimension has one column: "state". The Sales table has three columns: "saleAmount", "customerState" and "billingState" (because our customer can be in California but wants us to bill a company or branch in New York).
In SQL, if we want to see all the sales in California, we write our SQL query as:
select sum(saleAmount) from Sales where customerState = 'California' or billingState = 'California'
Is there a way to accomplish this in SSDT when building my cube so that when I'm using Excel as an end user tool and I select the state attribute from the Location dimension and the saleAmount measure, the saleAmount will be based on customerState or billingState? (I do not want to have role playing dimensions here - where one Location dimension is based on customerState and another Location dimension is based on billingState. I want one dimension matching up with both columns at once.)
Not the way you're thinking, but you can achieve what you want by doing this:
Create a view on your fact table, that is a UNION of facts related to customerState and facts related to billingState. This means the view will only have 1 State column, and if a fact has different values for customerState and billingState, then it will have two rows in the view.
Use the view instead of your table to populate your measure group in the cube.
Link the measure group to the Location dimension on the single State column in the Fact view.
Builder beware, this results in duplicate counting of facts when rolling up states where a single fact is in two different states.
I have an existing table which is expected to work for a new piece of functionality. I have the opinion that a new table is needed to achieve the objective and would like an opinion if it can work as is, or is the new table a must? The issue is a query returning more records than it should, I believe this is why:
There is a table called postcodes. Over time this has really become a town table because different town names have been entered so it has multiple records for most postcodes. In reference to the query below the relevant fields in the postcode table are:
postcode.postcode - the actual postcode, as mentioned this is not unique
postcode.twcid - is a foreign key to the forecast table, this is not unique either
The relevant fields in the forecast table are:
forecast.twcid - identifyer for the table however not unique because there four days worth of forecasts in the table. Only ever four, newver more, never less.
And here is the query:
select * from forecast
LEFT OUTER JOIN postcodes ON forecast.TWCID = postcodes.TWCID
WHERE postcodes.postcode = 3123
order by forecast.twcid, forecast.theDate;
Because there are two records in the postcode table for 3123 the results are doubled up. Two forecasts for day 1, two for day 2 etc......
Given that the relationship between postcodes and forecast is many to many (there are multiple records in the postcode tables for each postcode and twcid. And there are multiple records for each twcid in the forecast table because it always holds four days worth of forecasts) is there a way to re-write the query to only get four forecast records for a post code?
Or is my thought of creating a new postcode table which has unique records for each post code necessary?
You have a problem that postcodes can be in multiple towns. And towns can have multiple postcodes. In the United States, the US Census Bureau and the US Post Office have defined very extensive geographies for various coding schemes. The basic idea is that a zip code has a "main" town.
I would suggest that you either create a separate table with one row per postcode and the main town. Or, add a field to your database indicating a main town. You can guarantee uniqueness of this field with a filtered index:
create unique index postcode_postcode_maintown on postcodes(postcode) where IsMainTown = 1;
You might need the same thing for IsMainPostcode.
(Filtered indexes are a very nice feature in SQL Server.)
With this construct, you can change your query to:
select *
from forecast LEFT OUTER JOIN
postcodes
ON forecast.TWCID = postcodes.TWCID and postcodes.IsMainPostcode = 1
WHERE postcodes.postcode = 3123
order by forecast.twcid, forecast.theDate;
You should really never have a table without a primary key. Primary keys are, by definition, unique. The primary key should be the target for your foreign keys.
You're having problems because you're fighting against a poor database design.
I'm creating a small pet shop database for a project
The database needs to have a list of products by supplier that can be grouped by pet type or product category.
Each in store sale and customer order can have multiple products per order and an employee attached to them the customer order must be have a customer and employee must have a position,
http://imgur.com/2Mi7EIU
Here are some random thoughts
I often separate addresses from the thing that has an address. You could make 1-many relationships between Employee, Customer and Supplier to an address table. That would allow you to have different types of addresses per entity, and to change addresses without touching the original table.
If it is possible for prices to change for an item, you would need to account for that somehow. Ideas there are create a pricing table, or to capture the price on the sales item table.
I don't like the way you handle the sales item table. the different foreign keys based on the type of the transaction is not quite correct. An alternative would be to replace SalesItem SaleID and OrderId with the SalesRecordId... another better option would be to just merge the fields from InStoreSale, SalesRecord, and CustomerOrders into a single table and slap an indicator on the table to indicate which type of transaction it was.
You would probably try to be consistent with plurality on your tables. For example, CustomerOrders vs. CustomerOrder.
Putting PositionPay on the EmployeePosition table seems off to... Employees in the same position typically can have different pay.
Is the PetType structured with enough complexity? Can't you have items that apply to more than one pet type? For example, a fishtank can be used for fish or lizards? If so, you will need a many-to-many join table there.
Hope this helps!