How do I use Power Pivot to summarize data in groups which are defined in a separate, non-relatable table
I'm analyzing a database that has the following tables:
Sales
Store
Category
Units
Sales
Stores
Store
address
etc
StoreGroups
Store
Group
A store can be in multiple groups (i.e. store B762 is in NW group & control_group) hence the StoreGroup table - where the two fields together make the primary key. Therefore, I can't relate StoreGroups to my Sales table, because both have duplicate Store values.
Right now all stores are being reported in each group:
PivotTableScreenshot
to confirm, if a store is in two groups, its sales should get counted for BOTH groups i.e. control group and NWRegion.
I've tried to adapt this DAX example mentioned below but have not been successful:
http://www.daxpatterns.com/dynamic-segmentation/
You have a many-to-many relationship between stores and groups.
You should be able to create a relationship from the store in StoreGroups and the Store in Stores (StoreGroups is a bridge table).
If you can post a link to some sample data, that would be helpful.
After doing that, you can read start to read about writing DAX formulas for many-to-many scenarios here. Be sure to also read in the comments, especially the one from Marco Russo.
Related
We have a system with two main roles: service provider and customer. The provider side is users like doctors, nurses, and caregivers. The customer side is just the customer. all user types contain some common data and some uncommon data. in the current system, we have a table for each user type, and for common data, we have User table. currect system ERD is:
https://s4.uupload.ir/files/screenshot-20210710165449-1007x662_tpwd.png
in the current system, we have a lot of tables and we think about reducing them. our vision is to bring all user types in a single table called User and instead of a lot of tables, we have more columns. of course in some users, we have empty cells that do not belong to this user type.
I have 4 questions:
is it ok to bring customers and providers to a table like User?
what is the optimal number of columns in a table?
load a row with a lot of columns OR relation between different tables?
provider type should be a separate table or can be an enum?
It is best to put all users in single table. So when you check login there is less place to do mistake. When selecting user you dont need to use SELECT * FROM... You can use SELECT id, username, name FROM...
Dont put too many columns, if there is some data which you dont need when searching or displaying users, you can create helper table "user_meta" with dolumns user_id, meta_key, value where user_id and meta_key are primary key
Answered by first 2 answers
Provider type should be enum if there will not bee needs to expand with additional types.
This question is an extension of another question I asked regarding many-to-many relationships in MySQL.
I currently have 3 tables that I need to link with a 4th intermediary table:
Stores, Products, and States
My intermediary table, _stores_products_states, combines the id from the other three tables to determine which product is sold by which store and in which state.
Now, as I understand it, I would need to create an entry in _stores_products_states for every possible combination of the three, correct? This would lead to thousands of duplicated values in 1-2 of the columns (though never all 3).
For example, if Best Guy sells both GI Bros and Darbies in all 50 states, that would be 100 entries just for those two products. If those products are sold by another store, they too would have 100 entries.
Is this the correct way to implement this kind of relationship?
EDIT:
This whole setup is basically just to determine the availability of a particular product. A user will search for a product and receive a list of stores that sell that product in their state.
The 4th table is the way!
So if I got it right, your '_stores_products_states' table could even be called sale
You do not need to create a record for all possible combinations of product, state, and store. You only need to create a record for existing combinations, that is, availability of a product in a store in a state (maybe with things like local price and quantity bolted on).
You will have to store this information one way or another; a 3-relation link table, especially stored as a clustered MySQL index, would be a pretty standard solution, with good performance characteristics.
One thing I wonder about is why you have stores separate from states. I'd expect a store to be associated with a state. With the 3-relation link table, you'd be able to associate the same store with a product in several different states. Is this what your business domain supposes?
I have been trying to set up a data warehouse using ralph kimballs technique but I am having difficulty actually understanding how to load data into my tables. I have a sales_filev1.csv that contains the columns:
CUST_CITY_NM
CUST_STREET_ADD
CUST_POSTAL_CD
CUST_STATE_CD
CUST_NM
CUST_NO
CUST_PHONE_NO
PROD_CAT_CD
PROD_LN_CD
PROD_NM
PROD_PACKAGE_SIZE_NO
SLS_PROMO_IN
SLS_QTY_NO
SLS_UNIT_PRICE_AM
STORE_CITY_NM
STORE_ESTABLISH_DT
STORE_ID
STORE_LVL_CD
STORE_MGR_NM
STORE_MGR_PHONE_NO
STORE_NM
STORE_NO
STORE_POSTAL_CD
STORE_STATE_CD
STORE_STREET_AD
SALES_DT
Then I have a CUST_LOOKUP.csv containing
CUST_NO
CUST_ID
CUST_INCOME_AM
CUST_CD
Then the last file is a product lookup:
PROD_NM
PROD_SKU_NO
SLS_UNIT_COST_AM
PROD_INTRO_DT
PROD_ID
I understand that I need to do have a sales_fact table as well. However, would my sales_filev1 not be the sales fact since it contains all of the information about the customers, store and products purchased and when? Then I would just use a join and insert to add the data together?
You need to model your data dimensionally (if you are going to use a star schema) and decide the grain of your data, determine the measures that will go into the fact table(s) and the attributes that will reside in the dimension table(s).
A datawarehouse is not joining all the data you have together in one table. It is optimal for storage and reporting.
Have a read of Dimensional Modelling and perhaps purchase the excellent book by Ralph Kimball's DWH Toolkit.
I am currently working on a report-generating application (in Visual Basic) for a pre-existing database (in mySQL), in which I need to submit queries across multiple tables to access all of the information needed; however, my experience with this sort of project is limited. I am hoping someone can point me toward an efficient method of achieving this.
In the initial report, I need data from 3 tables.
Table 1) 'invoice' - table structure contains a date, an invoice number, and a customer number (and other non-pertinent columns)
Table 2) 'transaction_data' - table structure contains an invoice number, a billing code, and an item description (and other non-pertinent columns). Each row of the table contains a single line-item from a single invoice (so there can be several rows in this table containing the same invoice number).
Table 3) 'customers' - table structure contains customer number, name, address, phone (and other non-pertinent columns).
I need to be able to search 'invoice' based on dates, to get a list of all invoice numbers within the specified time frame (and their corresponding customer number). I then need to take that list of invoice numbers, and search 'transaction_data' for each row that contains one of the invoice numbers, and check for a specific billing code. If the billing code does not exist, I need to use the customer number (obtained during the invoice search) to put together a list of invoice number, customer name, address, phone number.
This can be accomplished fairly easily by populating an array variable utilizing for/while loops, but will require multiple queries across separate tables... of which 'invoice' and 'customers' have 20k+ entries and 'transaction_data' table has over 100k entries. Surely, this is not the most efficient manner of compiling said data.
Can someone please direct me as to how the query SHOULD be structured efficiently? Thanks in advance for helping a database noobie!
Look up JOINS in the MySQL manual. You would join the three tables together and with a WHERE clause get the specific rows you need that match the criteria you are searching for. No loops needed.
I'm trying to write a SQL query that satisfies multiple criteria.
Of these, most are connected via a column, so joins are possible, however, some queries are such that I'd have to search additional tables for the information. What would be the least expensive and best way to do this?
Let's say that we have a few tables.
One table contains information such as sales information for a server: the salesperson, client id, service lease term, timestamps etc. It is possible that a client has multiple sales but with a different "service". I'd need to pick up all of the different ones.
Another table has the quotes for the services, I'd need to pick some information out about this, whilst another, which could be joined to this one has some more information.
Those tables are linked by a common client ID, so joins are possible, but I'd also need to search the first table for multiple instances of the client ID. Of course, I'd want to restrict the search to certain timestamps, which I can easily do as the timestamps are stored in MySQL format.