When we use recommender systems for retail banking products (life insurance, mutual fund, lockers etc) some of the products are one time purchases so if I need to create a recommender system that will predict what will be the purchases in the next 3 months how do I go about it?
Related
I'm try to make a database for instalmentSales app but I feel like I'm carrying coals to Newcastle.
Every customer should have required payments every month and the due date and amount, so I'm creating table for the required payments to save every customer required payments. Which is usually 12 months or so.
Also what if customer paid a partial amount of the monthly payment, like if he paid 50% of the payment and is going to pay the rest after few days or even next month, so I'm creating another table to save paid payments and the date of it so I can check/access the partial amount and the date of it later.
I feel like I'm doing it totally wrong and I'm out of ideas
I think you're on the right track; just call the "required payments" table Invoice and the "actual payments paid" table Payment. Since someone could in theory be paying multiple invoices with a single payment (e.g. they fell behind and are catching up), you probably couldn't use a foreign key here to make a one to many relationship between Invoice and Payment. You could do a many to many with a linking table if you want to track which payments are applied to which invoices.
I am sure that this question already exists but as I am not familiar to SAP development (am an IT auditor) I can't really do a decent search. So I apologize in advance.
We are introducing a new product in our grocery store: a sandwich. The ingredients are : certain amount of bread, rumsteak and cheese.
These base products are already in the SAP.
Can you please tell me how should I create a new product called "sandwich" which will be connected to my basic products? So when I sell or make a sandwich it is taken into account and has an impact on the quantity of bread and cheese etc.?
Thank you so so so much for your help, stackoverflow!
If you just want the stock of your base ingredients to be reduced when your product is sold, you can use a sales BOM (Bill of materials). If you want to produce your product using your base ingredients and then store the final product in your warehouse, you'd create a production BOM and create production orders.
This is of course a very, very, very (repeat about 20 times) short summary of the necessary customizing. Creating a sales BOM is relatively easy, but doesn't give you the ability to track your product stock. Production orders require some additional customization in module PP (maybe even PP-PI, depending on your scenario) and of course need someone to create production orders, create the products, then confirm the production orders.
We've a Tabular model which has 3 facts and few dimensions.
Out of the 3 facts 2 are about Account & Products.
Facts realated to acocunt of a customer. How many are active, how much is the current balance, how much was the balance at the start etc.
Product Fact is about different supplement products that a cstomer has. He/she may or may not have a supplement product. Now this has facts like how much the customer owes in different products, rebate amount etc.
Now they both have Dimension Account as common Dim.
Relation between Account & Product is 1-M. If an account has supplement product it can be 1, 2 and max 3. If it doesnt have, it is 1-0 :)
Problem we're having is that if we want to slice both fact by Account Dim attribute, we get only the accounts which have supplement product. Becuase I believe Tabular model works on INNER JOINS. In this case I want to have OUTER JOIN. Since I'd want to have all accounts come through in the query and where i've matching supplement product then the fact for that products.
Any help is appreciated.
I have a database problem where I am suppose to design a tour database. they keep track
visitors, tickets, and the attractions (such as palace or local shows) that they visit. We assume that each visitor has to buy a ticket to enter the tour.
Each ticket is valid for only one day, and there are no special tickets for children or families etc. But there are several classes of tickets, in particular Gold, Silver, and Bronze tickets. A Gold ticket is more expensive, but then most of the attractions in the tour are free or
at least fairly cheap. For Silver and Bronze tickets, there may be significant extra charges for most of the attractions. Thus, a person planning to spend the whole day and do as many rides as possible may want to buy a Gold ticket, while others are better off with a Silver or Bronze ticket.
Ticket prices, as well as the extra charges per attraction for each ticket class, may depend on the season, and may change over time. Thus, during Spring Break 2013 Season there may be one set of prices, while during the Peak Summer Season 2013 there may be another set of prices. Each attraction has a unique name (e.g., Glass museum or gold mine), and whenever a visitor visits an attraction, the database should store information about the ticket held by the visitor and about when exactly the visitor entered the attraction.
Visitors
(v_id,visitor_name)
Ticket_purchase
(v_id,t_id,date)
Tickets
(t_id,class,price,season)
Attractions
(t_id,attraction_name,goldextracost,silverextracost,bronzeextracost)
Attraction_visited
(v_id,t_id,attraction_name,datetime)
Now if I want to output the number of people who bought a Bronze ticket but who would have saved money if they had bought a Gold ticket (because they visited a lot of attractions where they had to pay extra during that day)
Is it possible with the above tables or I need some structural changes??
I think you have the information you need. You're recording the ticket used when a patron visits an attraction and with that data you can get the ticket class and calculate what the cost would have been had they visited the attraction with a different class ticket.
from what i can see you overwrite the ticket price when you change it...
because of this you cannot look back at different ticket prices... as i undrstand ticket prices can change
you would have to add to the tickets a field for the date when you created the new price. then you would not delete the old ticket price. just pull the newest.
and the same for anything else with a price... you cant overwrite it.. just add a start date...
and when you are ready to see how much the person spend you can see how much they spent on their tickets and attractions...
once you do this what you want will be possible.
Pawnshop business model:
CLIENTES (customer table), LOTES (lot table), ARTICULOS (item table) and TRANSACCIONES (transaction table).
The reason I defined a lot table is because when customers pawn or sell items, the pawnshop groups all these items into one lot, calculates the total loan or purchase amount, stores these values under one transaction and prints the ticket with a description of all the items and total amount. So I want the ability to say, if customer defaults on interest payments or does not redeem pawn, then customer forfeits all items and pawnshop may choose to sell some items to gold refinery and/or transfer other non-gold items to inventory to sell to the public. In other words, I want the ability to do a break-out explosions of each item.
Would the above ER be adequate for this capability?
From the point of view of a logical model, you probably don't want store_id on the lot (as it comes from the customer) or the transactions or articles (as they get it through the lot and customer). At the physical level you might have those as attributes (called denormalisation), you have the risk of data showing, for example, LOT 1234 being on CUSTOMER C12 and at STORE S1, while the customer table has C12 being at store S2.
Of course it is possible that you allow Mr Smith to pawn an item at one store but make payments on it at another. Or perhaps an item might be pawned at one store but physically relocated to a different one for security or space reasons. If so, then it is appropriate to have distinct store ids on these entities.
However that doesn't sit comfortably with the 'store' being an attribute of the customer, since that implies they have a relationship with only one store.
Also consider what happens if MR P BROKER has three stores, but decides to close one and move the business to one of the others. You need to merge the stores but do you update the store id on all the transactions and articles and lots (including ones that are 'in progress' and those redeemed) or do you leave them with the original store id ?
Another common data modelling issue is identifying customers. Is Mr Smith one customer and Mrs Smith another, or can Mr and Mrs Smith be 'parts' of the same customer ? If Mr Smith pawns something, can Mrs Smith redeem it ? I'm thinking family squabbles, disputed heirlooms.... Perhaps she can't redeem it, but can make payments on it.
If an item (eg a watch) is included in one lot, then redeemed, then included in a different lot, does it get a different item_id ?
When a client buys an article offered to the general public, is that a transaction? Or does your database only track transactions about lots?
Can an item exist in your system without being part of any lot? You can't express that fact in the ER model you've presented.
Your ER model doesn't show any many to many relationships. That makes me suspicious. I've never worked in a pawnshop, so I can't say for sure. But every other enterprise database I've ever seen has at least one many-to-many relationship. Sometimes a relationship is treated as though it were an entity, and appears with a box of its own. But that box would be on the "infinity" end of more than one relationship, something I don't see in your diagram.
Buena suerte.