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?
Related
I have been studying datawarehouse in the last couple days, particularly, i have been reading The Data Wharehouse Toolkit - The Definitive Guide to Dimensional Modeling by Kimball and Ross.
Uppon that reading, i came to the 1st exapmle where there is a sales fact and it related to a product dimension, as you can see in the bellow image:
I think i can grasp the gist of how this relationship allows us to rotate the "cube" slicing and dicing data, however this is where i get lost:
In this example and many others on the web product is a one-to-one relationship with sales, which is fine i guess for most cases. But this generates a sales registtry for at least each kind of product that was in one sale.
So supposing i bought 1 banana, 2 apples and 1 orange, this would yield at least 3 sales registry. Again, which is fine i guess as it is storing the sale's ticket ID in the sales fact, we still can relate all itens in a given sale.
However if this was an use case: relate products on sales say i want to get every sale that had a banana and get stuff like: how many items each of these sales had, their price cost, their profit, stuff like that...
Wouldn't be better if the fact-product relation were Fact-one_to_many-Product relationship? Where fact would hold the sale's ticket ID and products would have its foreign key referencing where they are from or something?
I reckon these metrics should be in the fact table, and not in the product table as i think i would want. So, is this me not fighting my urge to normalize it or does it make sense in the way i would want to do that kind of filtering -> [given all sales with X product, get data from other products in the same sale].
If i were to follow the guidelines, product dimension would have one registry for every exclusive kind of product the store would have correct? And all the measurements i want i would store it on the fact itself, like price cost, sales price, profit, etc...
On the other hand, if i were to one-to-many product dimension would have many copies of each product. Which is bad, i think. However, i think it would give me better queries in that regard.
As you can see, i'm a beginer and really in the early stages of this path, so if you would endulge me in a Explain Like I'm Five kind of answer I would appreciate.
EDITED:
Sorry #Nick.McDermaid, you are right. I meant from the perspective of the sales fact where for every sale fact i will have only one product, but are correct that for one product it can have N sales related. And so, we have one record of product in the database for every different product on our store. This is the right way to do it, how to rightfully model it. Also, the many indicator is the "sales quantity" i'm guessing.
Anyhow, while this allows for slicing and dicing when/if we have sales as the point of view, but what if i want to for example:
Get all sales that had a banana in it, with all the other items in those sales. We can still do it with this structure but its harder than if the products were repeated and we had the sale id as a foreign key in the product table.
Cuz ultimetly i want to get all the sales(and products within that sale) that had a banana. And then take metrics out of them.
What you are somewhat hinting at would be a degenerate dimension, consisting of the sales id/invoice #/purchase order # of the transaction that took place. The whole purpose of a degenerate dimension is to group items that are related by a meaningless piece of data. For example, a PO # of A1234 is meaningless on its own, it doesn't tell you anything about the purchase. However, it can be used to identify other meaningful data, such as the date of purchase of the products for the customer. In that context, the PO # is defined by the collection of the entities it brings together to describe an event.
Another critical concept in data-warehousing is the abstraction of the schema in the database from the model in the cube. You don't join and group data in a cube model. You slice and filter. There are no foreign keys in a cube model. Those are used in the underlying data schema, but all of that work is handled behind the scenes of the cube model.
To keep track of inventory on-hand at different retail branches, we model each individual Stock Item ever purchased and its current location as a field on each entity. This makes it easy to trace faulty stock and where a unit has been inventorised over time.
Problem is, how to model the location of an individual stock item when it can reside in either a Stock Room or some Box in transit that is en route to another location, without muddling the data types of Stock Rooms and Shipments, and potentially other types of locations?
The only solutions our team can think of is to consider that a Shipment is a Location where a stock item can reside, which unfortunately has a source and destination location as well (yuck), or we need to write logic to exclude packaged up stock units when we conduct stock counts, which makes the current location field untrustworthy.
Both solutions seem messy to me. Alternatively, we may need to consider some generic stock accounting design.
Has anyone implemented this kind of stock tracking and is there existing literature about this with accompanying complexities and pitfalls?
I have no experience or literature, but it would seem to me that modeling a Shipment as being on a particular Truck at a given point in time would constitute a meaningful location.
You wouldn't have to track the source or destination location for a Truck entity; a VIN or some other unique ID would do.
I can imagine that a Shipment might change hands several times: first on a Truck, then in a Plane, onto a Train, then another Truck. Perhaps the abstraction is MovingLocation. A unique ID for each would tell you exactly where the Shipment was at a given moment in time.
Each MovingLocation could beacon out there instantaneous lat/lon location as a time series. You don't say if keeping track of that is part of your calculus. I'm spitballing here.
I have a table of all zip codes (and states) and sales tax rates and a table of merchants. I am trying to store which merchants charge sales taxes in which states. I was planning on adding a table which maps merchants to states they charge taxes in. However, there are a bunch of exemptions for different categories. For example, New York doesn't charge sales tax on clothes if the total is under $110, and Vermont doesn't charge sales tax on clothes at all.
Can I store something like that in a database in a clean way, or should I create a messy helper file that includes these rules?
You're in for a world of hurt if you try to roll out your own billing from scratch. There are also city, county, special purpose district, and transit authority taxes with various exemptions rules depending on where you are buying from.
Recommend using third party billing — for a lot of reasons, mostly outside of the scope of SO. With third party billing, you just need to concentrate on classifying the items correctly.
Is your intent that you will use this database to calculate sales tax, or that it is purely for reference/information?
If you're using it to calculate the tax, then a "messy helper file" would be, well, very messy.
If you're trying to deal with sales taxes from many states, then as Buddy says, this is a huge job. I had a little business in Ohio for a while and I was only selling one product and only had to deal with Ohio taxes, and it was still a complicated mess because of all the different taxing entities and different rates. Worst was the sales tax to support mass transit in Cleveland, as the places where this tax was imposed did not follow any simple geographical boundaries, that is, you couldn't just say "county X, yes or no" or anything like that. The only practical way to tell was to submit an address to their web site and they'd tell you if it was within their boundary. If you have to deal with all 50 states I'd be terrified at all the special cases that are likely to come up. So if you can find some third party software to do this, I'd seriously consider it. Somebody who has the resources to study the tax laws of every state and figure them all out and keep current on them.
Failing that ... I'd say you'd have to go through every state's laws and figure out all the cases that you have to deal with. Many states exempt some categories of products, like food and clothes. Some have different rates for different products, like surtaxes on luxury goods. I hadn't heard of an exemption up to a certain amount before, but apparently that's something else to consider. I'd say you have to find out what all the rules are, what data you need to support each, and build a monster table of all these rules. Presumably the table would include columns for applicable taxing entity, product category, rate for this category (possibly zero), and dollar threshold at which the rate applies. Maybe you'll discover other things.
Let's consider I have the following not normalized table
1) warehouse
id
item_id
residual
purchase cost
sale cost
Currency
I tried to normalize this and I obtained this tables:
1) warehouse table
id
product_id
residual
cost_id
2) costs table
id
purchase cost
sale cost
Currency
Does that comply with database normal forms?
Thanks much in advance!!!
This should be a comment, but it's too verbose.
There's not enough information to provide an answer - we have to infer structure from context - and the context is confusing. Your initial record looks like a description of a product to be bought and sold - but you've named it as warehouse - which is a place for storing products. I've no idea what you mean by residual. Do you have multiple purchase costs for a specific product? If so how are they differentiated. Similar for sale cost. If ther are multiple costs involved why is the selling price tied to the purchase cost?
I don't know what "residual" means in this context. But just ignoring that ...
I doubt that there's anything to be gained by breaking cost out into a separate table. Let's say we have two products, "toaster model 14" and "men's shirt style X7". Both have a cost of $12. So you create a cost record for $12, and point both records to this. Then you realize that you made a mistake and the toaster really cost $13. So you update the cost record. But that will then update the cost for the shirt also, which is almost surely wrong. Having a separate cost table would mean that you would always create a new cost record every time you created a stock record. Nothing is gained.
The fields you have listed look to me like they all belong in one table. You'd also need an item table that would have data like the description, maybe manufacturer, product specs, etc.
Your warehouse table appears to really be a stocked item table, as it lists items and not warehouses, but whatever. I suspect it also needs some sort of serial number, or how will you link a given physical item in the warehouse to the corresponding record?
If by "sale cost" you mean the price that you will charge to the customer when you sell it, I doubt this belongs in the warehouse table. When a customer buys a product, do you tell him, "I can sell you the one that's in bin 40 in the warehouse for $20 or the one that's in bin 42 for $22. Which do you want?" Probably not. I suspect you charge the same price regardless of which particular unit the customer gets. The fact that the price you have to pay to your supplier went up between when you bought the first one and when you bought the second one normally does not mean that you will charge your customer a different price. You may raise the price, but you will have one price regardless of which unit is sold. Therefore, the selling price goes in the item table, not the warehouse table. If "sale cost" is something else, maybe this whole paragraph is irrelevant.
That's my class diagram at the moment:
I believe I can control the level of stock at each venue by the difference between the quantity of purchased ingredient and the quantity of beverage sold (as each beverage is composed by ingredient).
However, I have a requirement that should allow users to transfer ingredients between venues, and I am wondering what is the best approach for that...
A new purchase order would add the product to one venue's inventory, but how can I remove it from the other one?
Just in case someone get to this question, here goes my solution:
I decided to create a table transfer_stocks to register all the transfers between venues. This table is also used to solve any discrepancy when stock is counted (when recipient_id is nil, it means wastage or stock missing in the venue -sender_id).
The products in stock is calculated by de difference between purchases, sales and stock transferred.
My class diagram: