I have a stock dimension set up on several items. I don't want to add dimensions I just want a current stock dimension that is enabled to be recognised during financial update of stock. I thought I could create a new dimension group and add the same dimensions as the previous one except I have checked serial numbers to be part of financial stock update. I just want to know if this is ok?
You can set up a new tracking dimension group where the flag "Financial inventory" is active for dimension "Serial number", yes. Since the gui allows you to do that, this is ok from a technical point of view (if you are asking if this makes sense as a business requirement, this would be the wrong place to ask that).
You may run into problems if you want to change the tracking dimension group on an existing product. I think you can only do this as long as the product has not been used in any transactions yet.
Related
Hello FullCalendar team,
I am looking to build a feature that would limit the type of events that could go into a specific timeslot.
For example, I would like to indicate to a front-desk end-user that only a certain type of appointment was allowed to be entered into the timeslot. Perhaps the timeslot only takes meeting types that are tagged "check-ins" and "follow-ups" arbitrarily set by some higher up admin.
What would be the best way to go about building this limitation and displaying it to the user? I saw that there is an overlap function I might be able to use along with background-events. The higher-up admin might be able to create background-events that if they overlap with another requested event then limits the type. THen it would be very clear that any certain color-coded event set by the higher-admin would indicate that only certain types could be added.
But am I missing a very obvious way to do this? I was hoping there might be an easier way to templatize the day for end-users. Appreciate the advice.
Im learning dimensional modeling and Im trying to create a model. I was thinking about a social media platform which rates hotels. The platform has following data:
hotel information: name and address
a user can rate hotels (1-5 points)
a user can write comments
platform stores the date of the comments
hotel can answer via comment and it stores the date of it
the platform stores the total number of each rating level (i.e.: all rates with 1 point, all rates with 2 point etc.)
platform stores information of the user: sex, name, total number of votes he/she made and address
First, I tried to define which information belongs to a dimension or fact table
(here I also checked which one is additive/semi additive/non-additive)
I realized my example is kind of difficult, because it’s hard to decide if it belongs to a fact table or dimension.
I would like to hear some advice. Would someone agree with my model?
This is how I would model it:
Hotel information -> hotel dimension
User rating -> additive fact – because I can aggregate them with all dimensions
User comment -> semi additive? – because I can aggregate them with the date dimension (I don’t know if my argument is correct, but I know I would have new comments every day, which is for me a reason to store it in a fact table
Answer as comment -> same handling like with the user comments
Date of comment-> dimension
Total Number of all votes (1/2/3/4/5) -> semi-additive facts – makes no sense to aggregate them, since its already total but I would get the average
User information sex and name, address -> user-dimension
User Information: total number of votes -> could be dimension or fact. It depends how often it changes. If it changes often, I store it in a fact. If its not that often, then dimension
I still have question, hope someone can help me:
My Question: should I create two date dimensions, or can I store both information in one date dimension?
2nd Question: each user and hotel just have one address. Are there arguments, to separate the address dimension in a own hierarchy? Can I create a 1:1 relationship to a user dimension and address dimension?
For your model, it looks well considered, but here are some thoughts:
User comment (and answers to comments): they are an event to be captured (with new ones each day, as you mention) so are factual, with dimensionality of the commenter, type of comment, date, and the measure is at least a 'count' which is additive. But you don't want to store big text in a fact so you would put that in a dimension by itself which is 1:1 with the fact, for situations where you need to query on the comment itself.
Total Number of all votes (1/2/3/4/5) are, as you say, already aggregates, mostly for performance. Totals should be easy from the raw data itself so maybe not worthwhile to store them at all. You might also consider updating the hotel dimension with columns (hotel A has 5 '1' votes and 4 '2' votes) that you'd update as you go on, for easy filtering and categorisation.
User Information: total number of votes: it is factual information about a user (dimension) and it depends on whether you always just want to 'find it out' about a person or whether you are likely to use it to filter other information (i.e. show me all reviews for users who have made 10-20 votes). In that case you might store the total in the user dimension (and/or a banding, like 'number of reviews range' with 10-20, 20-30). You can update dimensions often if you need to, but you're right, it could still just live as a fact only.
As for date dimensions, if the 'grain' is 'day' then you only need one dimension, that you refer to from multiple facts.
As for addresses, you're right that there are arguments on both sides! Many people separate addresses into their own dimension, referred to from the other dimensions that use them. Kimball suggests you can do that behind the scenes if necessary, but prefers for each dimension to have its own set of address columns(but modelled as consistently as possible).
In Google Analytics, I gather e-commerce data, allowing me to track purchases. There is a specific analysis, however, which I cannot imagine how to set up. I need to verify how big a percentage of a revenue is generated by transactions which include product X but not products Y and Z. I have attempted to set this up in a custom report, but cannot figure out exactly which combination of dimensions, metrics and filters to use.
In case you're still wondering;
If you make a segment with "Product = X" and then go to the Transaction report you'll see the amount of transactions with only that product.
Took me a while to figure out as well.
I have two database tables
this is a sample database of a Ticketing system.
Figure 1: Sample table of air ticket.
Figure 2: Sample table of tax.
Requirement:
When ticket is made from the interface, it has multiple taxes of different names every time.
How can I store this information i.e. 'n' number of taxes for each ticket with different names every time.
I have tried to make many to many relationship but the problem is:
For each ticket if the tax is not setup, then need to add the tax first.
Any optimal solution for this?
"the problem is: For each ticket if the tax is not setup, then need to
add the tax first."
This is not a real-life problem. In real life governments declare taxes well in advance of collecting them, This gives organizations sufficient time to amend their systems which need to handle taxes. Tax is never a surprise.
"But this is very tiring solution for the end user.... to make bunch
of tax setup for each ticket"
This sort of thing is reference data, and is the duty of the system developer (hint: that's you) to populate the reference data tables. Or at least provide a screen where the user can create or amend various taxes. This is a different function from defining a ticket type.
The Ticket Creation screen should have a drop-down list (or similar widget) displaying all the existing taxes, which allows the user to pick the relevant one(s). If you reall think it's necessary you can include a link to the Create Tax screen, but that really is a very confusing workflow.
If the commentators are correct, and this is a ticket purchasing function, then your design is seriously wrong. Sales taxes must be included automatically to the cost of the purcahse as part of the transaction. Otherwise nobody would pay any tax.
On the check out page I need users to choose a delivery date. Their needs to be multiple shipping options (that cost different amounts), but these are restricted based on what day you choose. Alternately if you choose a shipping method first, this will restrict what days you can choose for delivery.
One shipping option is ‘saturday’, and the delivery date must be a saturday.
Another shipping option is ‘next day’, the delivery must be the next day, and the order must be made before 2pm.
The final option is 'standard', which has no limitations except it cant be delivered on a saturday, and the delivery cant be the next day.
Also, I need to be able to restrict dates for delivery for all shipping options, as deliveries wont be made on bank holidays or the day after.
Im really struggling to do this so Id appreciate any pointers. If I can only achieve some of what I need that may be ok as a compromise.
Thanks
This sounds like a perfect case for using a calendar table to identify which dates are actually holidays. While I don't have specific experience with Ubercart, I've used calendar tables in a number of different solutions, and even wrote up a blog entry that details how to create and use a calendar table with a MySQL server. It's quite long, so rather than post the whole thing here, I'll just point you to the actual entry at http://www.brianshowalter.com/calendar_tables.