Assume I have an imaginary factory for building different kinds of vehicles: cars, buses, pickups, etc...
Each of these vehicles is built up of many different materials: doors, door openers, wheels, etc...
I have a template for each vehicle type: e.g. a car consists of 4 wheels (regardless of the wheel model, size, or brand).
A customer buys a vehicle of type car, and now I want to specify the brand of the tyre. How can I differentiate now between the template which builds a vehicle and the exact item codes of which this specific car is built of?
Update1:
My goals are to be able to:
make a (general) template for each vehicle
build a concrete vehicle (with all materials used)
Suppose a car needs 4 door handles. I mention in this in the template. However, I have e.g. 4 kinds of door handles: a, b, c, & d. I cannot mention this in the template bec. it depends on the customer choice later on.
After a while I build a car and I use handle kind b.
My question is how can I have the proper setup/relationships for templates, all materials, and real vehicles?
An individual car and tyre brand needs to be a 1:1 relationship. It ought to be a simple query.
Your database schema and the template that builds a specific car in memory are two separate issues. Which one are you really asking about?
Related
I am making database design for food products and I am getting lost in deciding how to design product types and categories in database.
Let me share my current database structure:
Now lets think of real life example. Lets say if we take cheese product. And we just say it is smoked cheese with some flavor. Then we can assume that it is dairy product, and it would look something like this: Dairy -> Cheese -> Smoked -> Garlic flavor.
I have a list with different food categories and types enclosed:
I was trying to list just part of it and it becomes very complicated from my point of view.
Two main categories of food would be: Food and Beverages/drinks, but maybe I should begin with those categories like Bakery, Dairy, Fruit & Vegetables and etc.? Coz then in dairy products I may have food and drinks like cheese and milk. If we would take only cheese for now, I have googled and there is 66 different types of cheese maybe even more can be found here.
I know that everything could be simply added to maybe one table, but as I have so many different categories and types, and they repeats in each other, how could I make an optimal solution for that with the respect to all food categories?
I can conclude that yes I am not yet sure how to properly organize all the categories and types, but is there any table structure that you could propose?
If something is not clear enough, please let me know, and I will clarify that.
From my point of view you are looking for some combinations of labeling and categories. A system that could be flexible enough for your case may be implemented as M:N relation of product:label and 1:N of label:label.
This way your cheese example may be labeled like this:
Organic type -> Dairy -> Cheese
Cooked -> Smoked
Flavored -> Garlic flavor
If your application would allow for fulltext search on labels, adding new products with labels should be easy. End users, on the other hand, will have the possibility to filter through Dairy in general, or Cheese specifically.
The food categories that you have would be better organized in hierarchy. As a relational database you will have overlaps depending on how you organize your products. Ideally, you want to avoid many-to-many at all costs.
Perhaps, it would be better to create relationships based on the purpose of the database. For example, if this is for a supermarket, I would create the relationships based on the vendor and the products they sell, and maybe relate them to the department that receives the products. then add labels, or tags, that categorize the products by what kind of food (dairy, meat, fruits, etc)
This would allow you to have a more functional system based on process, and adding the tags, would be easily searchable by humans.
So, my suggestion is think about how this would be used and fits into your process and focus on that for the design (schema, relationships). Then focus on the users, and add another layer to make it easy to work with (labels, tags)
Does this make sense?
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 purchase from a manufacturer gift cards (not virtual ones, but real plastic ones), and keep it in my warehouse as serialized inventory, this base product is not salable.
i sell them as another products, that has additional virtual charachteristic (fixed one, that cant be configured by the customer). e.g. i can have 3 diferent products of: 100$, 200$ and 300$, and have the style of the base product in the warehouse. again,all defined as separate product in the catalogue.
I thought of modeling the inventory product as "configurable product" and the dependant product as "configurable product instance", and add the fixed configuration as features of the product. Is this the correct way? i see configurable product example, only when customer is defining configuration (the PC001 sample).
any other way? (maybe variant? though, my understanding it fits only when base product is virtual)
Thanks,
Amit
For gift cards, I prefer use variant products because that's the way that use OFBiz in the demo data and, above all, OFBiz has processes ready for this type of product-with-variants: load balance of the gift card, relate gift card with customer, etc. Check using Gift Card in OFBiz.
Just one consideration, if you sell the gift card as a product itself, not as a "payment method", then you can use both solutions: you can create the parent product as a virtual one and its "childs" as variants (like a shirt with different sizes), or create it as a configurable one (like a PC with several PC components). Just check the different processes that uses OFBiz to "sell" the product depending of this type (variant or configurable), and use the one that suits you. In this case I also prefer use a virtual product with variants, it's easier to manage it.
According to my design I have car models(BMW, toyota, ...) and car types(coupe, sedan, van, ...). So my CAR table has those two tables primary key and price information.
My problem is that I have one more car type named "customizable". that car type dont have an exact price because its open for bargain. I mean a coupe BMW's price is always same like sedan BMW but customizable BMW varies.
Current design doesnt meet that need. How can I solve this.
It sounds like you need to store the negotiated price against the Allocation - since that's the table that has the Car and Customer in it.
Or you could add another table which gets queries when the Type is 'custom'.
Presentations:
• Details of speakers - Speakers, topics, times, contact details, special requirements (if any) e.g. data projection, audio, powerpoint version
• Details of Chairs (your model should be able to cope with more than one “N” number) for each presentation session, there are chairpersons who chair the presentations; they changeover at refreshment breaks, but we need to know which session each will do; contact details.
With the info above, can I fit both speakers and chairs attributes under one entity called 'Presentation' or should I create two new entities - one for speaker and one for Chairs?
Based on the question, it seems like you will want more entities than just those. It depends on if there are any other specifications and data related to each of the entities.
Anyways, here's one possible idea:
Presentations Entity
Persons Entity (name and contact details)
speaker_for relationship (Persons to Presentations)
chairperson_for relationship (Persons to Presentations)
This way someone can speak at many presentations or chair many presentations, and you can easily query that. Also a person could also speak at one presentation and chair another. You can just have a Speakers entity and a Chairs entity, but they are so similar it seems unnecessary to me.
Like I said, you could adapt this to your liking and conforming to other specs.