I have a database with few tables, ex.:
Employee (Id, Name, state, country)
Material (Id, Name, color, Type, amount, stock)
Order (Id, MaterialId, EmployeeId, amount, discount, total amount)
ShippingOrders (OrderId, MaterialId, EmployeeId, amount, discount, total amount)
ShippingCountries (Id, CountryName)
Customers (Id, Name, state,address, CountryId)
MaterialImages (Image, MaterialId)
PlacedOrders (OrderId, EmployeeId, CustomerId, Amount, shippingDate)
SavedCarts
Now, I have to create data warehouse from this table. Like we have AdventureWorksDW from AdventureWorks database.
As I am completely new to database, I am curious to know how will I decide which fields should be selected as dimensions and which fields should be selected as Facts.
and once I decide that then how would I create a DW database (like AdventureWorksDW)?
Is this will be like Creating database and table. After that fill those tables with select query from master database (Ex. DimProduct in AdventureWorksDW is might made up from joins of few tables from AdventureWorks database)
To summarize, I am curious to know that how can I create my datawarehose db from existing db.
I am very new to SSAS and your suggestion and opinion will be very useful to me.
you will create your DW database like any other, it will just be more denormalized than your regular OLTP DB
You should have a mechanism (SSIS packages are the most commomn) to update your DW from your OLTP database from time to time.
The MAIN difference from facts and dimensions is that facts are values (like amount of sales for example) and dimensions are the "parameters" you will use to slice and dice the facts. Like customer, region, date, prodct type, etc..
now, how you will implement this on your DW is another thing (like for example, will you have a table for product color or will you add it to the product table) that we cant discuss on a single topic. As pondlife said, you have to google about data warehousing implementation.
Related
I am new to Biguery and I need to understand the functions on how to create automation within the system. My task is to create a near real-time dynamic dashboard of my company's sales data from Google Cloud Storage to BigQuery to Google Data Studio. I want to be sure I create one truth of data that will continuously be updated with current sales data moving forward rather than having to generate a new table from which to do data analysis on.
I have my datasets exported from our POS, and uploaded files to GCS in a bucket. This will occur on a weekly basis pulling sales data from the previous week.
In Bigquery, I provide that dataset from GCS to create a table according to its time period (For example, Oct_Wk2_2022).
With my limited background in SQL, I created a saved query where I made a UNION for each table to save the query as a new table. Here's a snippet of the SQL:
SELECT
Date, Time, Category, Item, Qty, Price_Point_Name, SKU, Modifiers_Applied, Gross_Sales, Discounts, Net_Sales, Tax, Location, Customer_Name
FROM
store-sales-daily-item-summary.Square_Sales_2022.Oct_Wk2_2022
UNION ALL
SELECT
Date, Time, Category, Item, Qty, Price_Point_Name, SKU, Modifiers_Applied, Gross_Sales, Discounts, Net_Sales, Tax, Location, Customer_Name
FROM
store-sales-daily-item-summary.Square_Sales_2022.Oct_Wk1_2022
When I export to BigQuery Table, it asks for a Destination table - from here, I can't add to an existing table (created from a previous BigQuery).
How do I create a scheduled query in SQL to append an existing table when I add a new table into BigQuery? What should my query look like to make that happen?
merge from the data manipulation language will do the trick of updating your existing table with least effort.
You can also handle duplicates with merge across the existing and new data.
next you can schedule the merge query.
https://cloud.google.com/bigquery/docs/reference/standard-sql/dml-syntax#update_statement
https://cloud.google.com/bigquery/docs/reference/standard-sql/dml-syntax#merge_statement
I have a Snowflake table with the following fields:
Date
Transaction Type
Transaction Speed
Company
The table has millions of rows, so I want to summarize the data which will then feed into Power BI. I want to group by Date, then Transaction Type, then Company, and sum the values in Transaction Speed.
I'm very new to SQL and have created some basic views, but am having trouble creating the summarization. Can anyone give me some guidance?
It is usually helpful to provide an example of what you have tried, but assuming I understand your requirements, you're likely looking for something like this:
SELECT date, transaction_type, company, sum(transaction_speed) as total_transaction_speed
FROM table
GROUP BY date, transaction_type, company;
I have been working on a SQL Server project that allows the users of a shopping website to insert their reviews for the product they bought.
Basically, I have 4 tables:
Customer: (Customer_ID, Username, Telephone_number, Grade)
Product: (Product_ID, Product_code, Name)
Review: (Review ID, Title, Content, Product_ID, Customer_ID)
Bill: (Bill_ID, Date, Product_ID, Customer_ID)
I've got two problems:
Firstly, I don't know how to force that only people who bought a product can review it.
Secondly, I don't know how to increase the grade in Customer table by a certain number of points (bonus points) after they review of a product.
Can anyone tell me how to solve these problems, especially in SQL Server code?
Several ways that you can do to protect your Review table from inserting such these records and it is best to handle these in your server-side or client-side code but as a design point of your DB, I think the best is to:
Design your Review table like:
(Review_ID, Title, Content, Bill_ID)
and set you Bill_Id column to not allow NULL, so that every review record must relate to a bill (shopping) record then you can handle error in your code which warns the users or...
Also if your grade is only about reviewing, you can set bonus (grade) a ratio of reviews so the grade would be like:
SELECT 5*COUNT(*) -- for example two reviews = 10 bonus
FROM Review
GROUP BY Customer_ID
And one more time I suggest you to handle all these in your code not in your DB.
Another suggestion is (If the logic and business of your application is based on database - which a shopping website is not!!) - is to create a stored procedure for INSERT operation like usp_ReviewInsert and call it in your code as a user wants to post a review, then your stored procedure handles all validating stuff (like relation between Bill and Review) and all updating stuff (like updating grade to a higher) and the insert operation in itself.
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!
I'm learning SQL for a while and I'm stuck with this problem.
I have two tables for a storage company.
In one table for the bookings for the whole company consisting booking no., date, product nr., quantity and storage room.
And in one table I have storage facility name and storage rooms to define the room belong to which facility
I want to have the sum of the quantity of one specific product in one specific storage facility
SELECT sum(Quantity) from Bookings where ProductNo=8888 and Storage.StorageFacility="Central"
Do I have to use a more complex query for the solution?
Your storage facility is in a different table than the BOOKINGS table (and they are related via STORAGE_ROOM). So you need to join these tables:
select sum(Quantity)
from bookings b
join storage_facility_details sfd
on b.storage_room = sfd.storage_room
where sfd.storage_facility = 'x'
and bookings.productno='8888'
The syntax of SQL can be slightly different on different database systems. Usually quotes (") are used to refer to tables and similar objects. Use single quotes (') to give values. Also, all the tables that you refer columns of need to appear after FROM. If the columns quantity and storagefacility appear in both tables you need to fully quality the name.
Also you need to join the two tables on a column, so the productno must also be present in your storage table.
SELECT sum(quantity) FROM bookings, storage
WHERE (bookings.productno = storage.productno)
AND
(bookings.productno='8888' AND storage.storagefacility='Central');