I'm working on a small school project. I'm struggling with connecting the tables of DB (more specifically schedule - get all the info and connecting box, storage, and tires that are mentioned in the contract - i put aggregation). Here is a pic of my solution: https://ibb.co/eV1D8b . Does it look ok?
The task goes:
The company has more business office across the country. In addition to tire assembly, there are still several services: sales (tires and other products), tire maintenance, etc...
To change tires at the beginning of the season, it is necessary to order it by phone. The operator receives a call and for each box where it is possible to change the tires, see the booking records. Changing the tire takes 30 min.
Upon arrival, the user arrives at the counter where based on registration of the vehicle a work order is made for the employee in the box (on which the number of tire code contracts was recorded). The tires are then transported from warehouse to the box for the assembly. When the tires are stored, a contract is signed to ensure that after a contracted deadline of 6 months tires are kept for another 60 days, which is paid annually by $ 0.10 per tire daily. The price of tire storage depends on the size and is calculated per piece.
There is a possibility of joining the Loyalty Club and getting discounts for all family cars. The discount is valid only for services, not for products.
With companies that want the services of this tire service (rent-a-car, utility vehicles, etc...), a contract will be concluded to provide a more affordable price for tire assembly and storage.
Related
I do descriptive analytics and reporting at a company that sells a wide range of products. We record sales transactions and everytime an item is sold, the following is recorded:
Customer ID (each customer has a unique ID)
Product ID (each product has a unique ID)
Sale date
(Other fields are recorded too - location of purchase, quantity, payment type, etc.)
We sell a few big ticket items, and what I'm wondering is if it's possible to predict whether a customer will buy one of the big ticket items based on their purchase history, using transactional data as described above. We have about 2 million rows of sales data spanning seven years, and in that time maybe 14,000 big ticket items have been sold to 5,000 out of 50,000 customers.
I use SQL Server 2008 R2 which has the data mining feature. I did some brief reading on it but can't figure out what model would be best, or if it's something that's even doable. Can someone point me in the right direction to get started?
Not sure if the SQL server data mining feature is useful. I took a look at the one for SQL 2012 and decided it wasn't.
As for your prediction, this would be a supervised learning problem (just pick any simple algorithm), where each customer is a row and your features would be the different products. Your positive labels then would then be the rows of customers that had bought big ticket items.
what you are looking for is called sequential pattern mining and the specific technique that you are looking for is called discrete event prediction. However with that being said, I don't think you will be able to do what you want to do with an out of the box solution on sql server.
I am currently working on a web application that stores information of Cooks in the user table. We have a functionality to search the cooks from our web application. If a cook is not available on May 3, 2016, we want to show the Not-Bookable or Not-Available message for that cook if user performs the search for May 3, 2016. The solution we have come up to is to create a table named CooksAvailability with following fields
ID, //Primary key, auto increment
IDCook, //foreign key to user's table
Date, //date he is available on
AvailableForBreakFast, //bool field
AvailableForLunch, //bool field
AvailableForDinner, //book field
BreakFastCookingPrice, //decimal nullable
LunchCookingPrice, //decimal nullable
DinnerCookingPrice //decimal nullable
With this schema, we are able to tell if the user is available for a specific date or not. But the problem with this approach is that it requires a lot of db space i.e if a cook is available for 280 days/year, there has to be 280 rows to reflect just one cook's availability.
This is too much space given the fact that we may have potentially thousands of cooks registered with our application. As you can see the CookingPrice fields for breakfast, lunch and dinner. it means a cook can charge different cooking rates for cooking on different dates and times.
Currently, we are looking for a smart solution that fulfils our requirements and consumes less space than our solution does.
You are storing a record for each day and the main mistake, which led you to this redundant design was that you did not separate the concepts enough.
I do not know whether a cook has an expected rate for a given meal, that is, a price one can assume in general if one has no additional information. If that is the case, then you can store these default prices in the table where you store the cooks.
Let's store the availability and the specific prices in different tables. If the availability does not have to store the prices, then you can store availability intervals. In the other table, where you store the prices, you need to store only the prices which deviate from the expected price. So, you will have defined availability intervals in a table, specific prices when the price differs from the expected one in the oter and default meal price values in the cook table, so, if there is no special price, the default price will be used.
To answer your question I should know more about the structure of the information.
For example if most cooks are available in a certain period, it could be helpful to organize your availability table with
avail_from_date - avail_to_date, instead of a row for each day.
this would reduce the amount of rows.
The different prices for breakfast, lunch and dinner could be stored better in the cooks table, if the prices are not different each day. Same is for the a availability for breakfast, lunch and dinner if this is not different each day.
But if your information structure makes it necessary to keep a record for every cook every day this would be 365 * 280 = 102,200 records for a year, this is not very much for a sql db in my eyes. If you put the indexes at the right place this will have a good performance.
There are a few questions that would help with the overall answer.
How often does availability change?
How often does price change?
Are there general patterns, e.g. cook X is available for breakfast and lunch, Monday - Wednesday each week?
Is there a normal availability / price over a certain period of time,
but with short-term overrides / differences?
If availability and price change at different speeds, I would suggest you model them separately. That way you only need to show what has changed, rather than duplicating data that is constant.
Beyond that, there's a space / complexity trade-off to make.
At one extreme, you could have a hierarchy of configurations that override each other. So, for cook X there's set A that says they can do breakfast Monday - Wednesday between dates 1 and 2. Then also for cook X there's set B that says they can do lunch on Thursday between dates 3 and 4. Assuming that dates go 1 -> 3 -> 4 -> 2, you can define whether set B overrides set A or adds to it. This is the most concise, but has quite a lot of business logic to work through to interpret it.
At the other extreme, you just say for cook X between date 1 and 2 this thing is true (an availability for a service, a price). You find all things that are true for a given date, possibly bringing in several separate records e.g. a lunch availability for Monday, a lunch price for Monday etc.
I have been given the following scenario :
HyperAV is a retailer of home cinema equipment. They sell a variety of products including televisions, speakers, amplifiers, Blu-ray/DVD players and cables. The company has its head office in Stockport and 5 retail branches around the UK (in London, York, Cardiff, Manchester and Newcastle) and a large warehouse in Birmingham.
Due to the specialised nature of the products most sales are made in the shops which also have demonstration facilities allowing staff to show off the products to customers before they buy. However, the shops can also take orders over the telephone. The company deals with a number of suppliers who deliver items to both the shops and the warehouse. Limited space is available in the shops, so large numbers of items are stored at the warehouse and sent to the shops when their stock runs low.
The company’s buyer and stock controller are based in Stockport and work together to ensure that each branch has an adequate stock level of fast-selling items. If a shop takes an order for a product that it does not hold in stock, payment is taken and the item is sent to the shop from the warehouse. If the warehouse does not have a product in stock, it is ordered from the supplier by the buyer.
From this scenario I have been asked to draw a use case diagram.
I have received feedback but only to an extent where I have been told it is slightly incorrect. I would like to know if anyone can see what is wrong with it or how i can improve it in anyway?
I will not go and analyze what is right/wrong with your business case, but here are a few remarks:
Do not use Generalization with UCs. Each UC shall be a unique added value the system under consideration (SUC) delivers to the actor. If you have Generalization this means your UC is not unique. E.g. Deliver product: these are two absolutely separate UCs. They use a delivery service. But that's a UC for another SUC (namely the delivery service).
Avoid the use of <<include>>/<<extend>> as they indicate the use of functional analysis. UCs are about synthesis which is the opposite of that.
Use verb-substantive to name your UC. Order for example is not a UC.
Think about the "use" in UC. What is the added value it returns to its actor? If that is not of a real use, it's not UC. Process payment is an administrative task, not a UC. So what is the use behind this?
I want to create an application which allows Users to budget money they already have into various categories for a given month.
I've already modeled and prototyped handling the data which is tangible; e.g. Bank Accounts, Transactions, Transfers. The problem I am running into is with relating this "real" data (the stuff sitting in your bank, or in your pocket, or on your bank statement) with these fake notions of Budgets (or, as I like to consider them, envelopes).
Here's a quick list of requirements that I've thrown together:
User can manage their Financial Accounts
User can manage their Financial Transactions
User can associate each Transaction with a Financial Account
User can transfer money between Accounts
User can assign available money to a given Budget Category, per-month
User can modify existing Monthly Budget Categories (reduce or increase)
User can view the amount of money remaining for a given Monthly Budget Category
User can view amount of money available to Budget (may be negative)
Money remaining from a Budget Category can carry over to the next month
User can view their Financial Account totals (should not be affected by budget)
User can create Budget Categories as goals that could eventually be closed (e.g. Savings for a new car)
(Probably some other Use-Cases I am forgetting)
The use-cases in bold are the ones I am struggling with.
I toyed with the idea of having a "MonthlyBudget" object, which each transaction could be related to; but this seemed overly-complicated to implement in a database because I'd have to implement a date-range instead of a simple date.
I played with the idea of treating these Monthly Budget Categories as Accounts, and one would simply perform Transfers to them; but then there'd be no way for the User to cross-check their bank statement with the data in the system.
I played with the idea of "fake money" in which Budgets would somehow make use of, thereby separating "real money" and "budget money" -- but couldn't think this through logically.
I'm a bit at a loss on finding a clear and concise way of implementing this, specifically using a relational-database for storage. If anyone has any suggestions or idea, I'd be very appreciative.
The reason why people experience frustration with the budget envelope method is that it ties budget allocations to specific money actually present, whereas money is fungible and can count against the budget, whatever the source. Moreover, when you write a check or swipe your credit card, it may be for a purchase that includes multiple budget items.
A typical commercial budget data model sets up budgets in periods (monthly in your definition) and budget items with amounts. When funds are disbursed, the payment is applied to the appropriate budget item(s), partially or in full. To find out what you have left to spend in your budget, subtract all the applied payments.
If this is for personal finance, people are on a cash basis. However, the same principles apply. So you would have a grocery bill of $220. Maybe $150 of that was for regular food we eat all week, and the other $70 was for a Christmas party. When you come home and enter the grocery bill into the computer, you would want options:
Apply the whole $220 to grocery, because it has to be made up somewhere;
Apply the $150 to grocery and apply the $70 to seasonal entertainment;
Apply the $150 to grocery and put the $70 aside, because I haven't set up a seasonal entertainment budget yet. We don't want to make the user stop the whole process to create more budgets in order to enter the grocery bill, or soon s/he won't be entering the grocery bill faithfully any more because it is just too much work.
I need an elegant way to implement credit-based purchases for an online store with a small variety of products which can be purchased using virtual credit or real currency. Alternatively, products could only be priced in credits.
Previous work
I have implemented credit-based purchasing before using different product types (eg. Credit, Voucher or Music) with post-order processing to assign purchased credit to users in the form of real currency, which could subsequently be used to discount future orders' charge totals.
This worked fairly well as a makeshift solution, but did not succeed in disconnecting the virtual currency from the real currency, which is what I'd like to do, since spending credits is psychologically easier for customers than spending real currency.
Design
I need guidance on designing the database correctly with support for the simultaneous bulk purchase of credits at a discount along with real currency products. Alternatively, should all products be priced in credits and only credit have a real currency value?
Existing Database Design
Partial Products table:
ProductId
Title
Type
UnitPrice
SalePrice
Partial Orders table:
OrderId
UserId (related to Users table, not shown)
Status
Value
Total
Partial OrderItems table (similar to CartItems table):
OrderItemId
OrderId (related to Orders table)
ProductId (related to Products table)
Quantity
UnitPrice
SalePrice
Prospective UserCredits table:
CreditId
UserId (related to Users table, not shown)
Value (+/- value. Summed over time to determine saldo.)
Date
I'm using ASP.NET MVC and LINQ-to-SQL on a SQL Server database.
You don't pay your suppliers in Credits, so from an internal accounting perspective it would be better to hold only hard cash values (USD, UKP, whatever) against your products.
When displaying to your site's users you need a currency conversion table which translates hard prices into vouchers. Separating the data model from the front end display is a key design strategy. Whether you decide to show both real cash price and virtual credit price or just the credit valuation should have no bearing on how the data is stored in the database.
Talk to your accounting/finance people. Credit, once given, is as real as any money in double accounting, true you are not paying your suppliers in credits, but you are promising to deliver goods for credits that you will have to pay in hard cash. It should all balance at all times, and to see your complete financial position you should be able to get these credits in your balance sheet.
Try to model accounts and transactions, as well, right from the start - it will be easier to connect to finance/accounting software later and it is always good if you can run reports on both sides for purposes of reconciliation.