So I'm doing a weekly task and am a little stumped. Basically doing a database logical model for a Restaurant menu.
I'm trying to record a Menu with 3 different types so I've set it up as:
MENU
With 3 subtypes:
Main, Entree, Dessert
With main, entree and dessert having their own subtypes.
However, I only have one subtype option for my Desserts which is it is either Lactose Free or not.
What would be the best way to set this up? It is possible to have a a single subtype?
Related
I'm trying to describe a Car object that has multiple options regarding the engine or gearbox, that is referenced by an aggregateOffer as the itemOffered.
I want to indicate that the said Car can have either a manual or automatic gearbox, can be new or used, accept diesel or other fuels etc. The two options I see are the following :
1) Make a list with possible gearboxes and other options
"itemOffered" : {
"vehicleTransmission": ["Automatic","Manual"],
"fuelType": ["Diesel", "Essence"]
}
Would this be interpreted as follows : the car has either a manual OR an automatic gearbox ?
I'm affraid the semantic behind this would suggest that the said car has both.
2) Make a list of cars with all possibilities
"itemOffered": [
{
"#type": "Car1",
"fuelType": "Essence",
"vehicleTransmission": "Automatic" },
{
"#type": "Car2",
"fuelType": "Essence",
"vehicleTransmission": "Manual" }
]
But this would be potentially very big, as I have multiple car offers with several different options, I would end up listing my entire database.
To clarify, the point of this Car object is to be attached to an aggregateOffer on a page where only the aggregateOffer is displayed and not every single offer available.
The second interpretation is correct. If you have one Car with multiple fuelType values, all of these values apply to this Car; they don’t represent alternatives.
Anyway, the AggregateOffer doesn’t seem to be suitable for your case. This type is intended for multiple offers of the same product, not for multiple offers of different (albeit similar) products:
When a single product is associated with multiple offers (for example, the same pair of shoes is offered by different merchants), then AggregateOffer can be used.
If you don’t want to list/repeat so many properties for each Car, you could make use of the ProductModel type. You can link ProductModel items with the isVariantOf property. Each variant model will inherit the features from its base product model, unless you "overwrite" them in the variant model. Each Car would then use the model property to refer to its product model.
However, if you have a specific structured data consumer in mind, they might not support this more complex structure.
I have the following problem to resolv. Given the following UML diagram:
I need to complete the diagram doing the following steps:
a) When an employee has a skill, the relationship between the employee and the skill shows years of experience.
b) A worker may have another employee as a manager and a worker who is a manager must manage five or more workers. As a manager, you can determine which workers he manages, but a worker can not determine who is his manager.
c) An activity can have a maximum activity precedent and any number of upcoming activities. Using these roles, we can show how the activities are arranged. Given an activity, you can only determine their own activities (if you have), but not what your previous activity (if any).
d) A worker is not simply associated with a set of skills, but a worker has skills. In particular, every worker should have three or more skills, and any number of employees can have the same ability.
e) A project is not simply a set of activities associated with, but contains a project activities. Specifically, a project must have one or more activities, and activity must belong to exactly one project.
f) Projects and activities are a specific type of job.
My solution is shown in the following picture, but because I am new in this I would like to check if is fine.
Thank you in advance!
Looks good in most parts. Honestly I don't understand the later parts of c)
Your -boss relation is wrong. Your Northern Koreans should not have a private known boss. Instead there's only the other way around and the boss has - let's call them - -slaves. If you put in a private -boss it actually means that the slave can navigate to its private boss which is explicitly not wanted. Only the boss shall know the one he's responsible for. So actually the object itself is the boss object. As a thought, since only the boss should have those 5 employees, it could be an idea to create a separate boss object like this:
Note that this might also have drawbacks since Boss is now actually a different object than Employee, but it seems to fit the requirements.
Point f) seems to call for a generalization. So you would need a generalization towards SpecificJob. This would be an arrow with open triangle, not the one you used:
This actually reads Project and Activity are specific kinds of Job as they both inherit from the latter.
I am an aspiring iOS developer with not much experience except 3 months of courses on threehouse.
I decided to make an app (just for fun) that counts the calories within your salad.
I have constructed a very rough model which uses a class Vegetable and I inherit different classes for each vegetable, however this is clearly wrong and I could see it from the first 10 minutes. Now I am wondering if my approach wouldn't be better with just using a Struct named Produse and instantiate from there every ingredient since most of the ingredients in the salad are the same and I am only interested in the properties name: String, type:ProduceType (an enum), caloriesPerHundredGrams: Double. All of these member values are essentially the same for fruits, vegetables and spices.
Any suggestions?
P.S. I don't know how to retrieve data from the web yet and I intend for this exercise to have all of my ingredients hardcoded. I will use a server as a backend once I learn that!
I'm trying to create a e-commerce website with out using any third party components.
My biggest problem so far is designing my model/database schema.
The e-commerce solution is for a Take away.
They only really have two types of Meals they Sell.
Rice Meals
Noodle meals Meals
Now Rice Meals have a set of options, so for example a Rice meal comes with either beans or plantain or both. (If both we need to off set the price)
Rice meals also come with a sauce the customer has 3 different options. There is no price difference.
Noodle meals
You can choose a Noodle type
You Can choose a sauce that goes with it.
You can choose if you want fish or meat
Then they have other products that don't have any options.
So my question is how can I create a flexible schema to store Products the options they have and the possible values for those options.
I also need to work out how to store what has actually been selected by the user.
I'm using EF with code first, would love someone to give me a few tips in the right direction.
The closest thing I have come across that may be a solution is this.
http://villyblog.blogspot.co.uk/2008/11/sample-database-schema-for-catalog-with.html
Really confused about the best way to do this.
Keep it simple!
Modeling is a skill. It's about observing and filtering. Even in a relatively simple business like a Take-away there is a lot of noise and if you manage to filter the noise and keep the essence your entity model will become both robust and flexible. First focus on the absolute minimum. Let me try to show you how this could work in your case.
The filtering begins with finding the "ubiquitous" language (Evans, Domain Driven Design): the "things" the business talks about and that are candidates to become entities in the model.
You talk about meals, types, values, prices, discounts, options, products. What are candidate entities?
One important step to take is to find the real, tangible "things". Customers don't eat options. They eat meals, or products. Nor do they eat prices.
"Option" is an interesting word. It is a covert verb. It's an act of opting for some "thing". It's a common design flaw in modeling to turn actions into entities, while they should become methods working on entities. Finding these disguised verbs is very very important. Without diving too deep into this issue I can say that having actions as entities make it hard to assign the right responsibilities to classes.
Likewise, prices (values) and types are no tangible things. They are attributes of things. Turning attributes into entities is a less obvious error, but it happens. I think the model you show as example contains both of the above flaws.
So far, in fact, the only real "thing" that emerges is a Product. The rest is either action or attribute. A Product can either be a meal, or a component of a meal. So these products come in combinations, or aggregates, which can be modeled by a hierarchy.
So here's the core of your "flexible schema to store Products":
You can store all possible combinations of products in one database table. No need to store options separately. Options are products as well. It's an act of combining to design the options in a hierarchy of products.
A concrete part of the hierarchy, the rice meals, could look like this:
The business does the combining, which is designing the hierarchy. The customer does the picking of options. Here business rules come into play. Let's say one rule is that the owner can combine any products, another rule is the customer can only combine end points (the smaller gray rectangles). The parent product could contain a property telling how many of its children can be chosen.
There may be a way to build these rules into the model, but coded rules are far more easy to modify than a model.. Let the model just be a dumb bag of data.
Now the part
I also need to work out how to store what has actually been selected by the user.
When a customer picks options he is making a classical order with order lines. That would make for a model like
Well, this is getting a long answer. A short word on the discounts. It depends a bit on how you want to calculate them. A simple way is a product property that's simply a multiplication factor to apply to the prices of each child product when more than 1 are selected.
Something like this might work, based vaguely on the link you provided:
MealType
- MealTypeID (short maybe? identity, PK)
- Name
Meal
- MealID (long, identity, PK)
- MealTypeID (FK)
- Name
- BasePrice
- IsActive (bit)
MealOption
- MealOptionID (PK) (short or int, identity)
- Name
- PriceOffset
- IsActive (bit)
MealMealOption (not the best name, but just represents a relationship between Meals and MealOptions)
- MealMealOptionID (PK, int or long, identity)
(composite foreign key with MealID and MealOptionID)
- MealID
- MealOptionID
Order
- (this holds stuff common to all orders such as billing address info, messages from the customer, etc.)
- OrderID (long, identity, PK)
- TotalCost
- TotalPriceOffset
etc...
OrderItems
- OrderItemsID (long, identity, PK)
- OrderId (FK)
- MealID (FK)
other order item-specific stuff...
OrderOptions
- OrderOptionID (long, identity, PK)
- OrderItemsID (FK)
- OrderID (FK)
- MealMealOptionID (FK)
anything else needed here...
Any table obviously will also have whatever other fields you deem necessary for that table.
The answer to this question is here >
Database design for user settings
It's a edr diagram of how to store: N number of settings, that are associated with N Number of users, and each user can have a N number of settings associated with that individual user. So you could have one user with 5 settings and another user with 10 settings.
This is very flexible and I'll be using it in the future. I have swapped the entity user and replaced it with product.
What I want to know now is HOW DO YOU STORE SELECTED SETTINGS? These tables are only able to store and show user settings and available options/settings.
Any ideas?
I am developing a geneaology application, and am currently at the stage of modelling relationships between individuals.
Based on my research, I have noted that most of the mappings of relationships are based on families (father + mother) and so I would like to understand the underlying reasoning behind this before I adopt it blindly.
Since my project is patriarchal, I assume that as soon as a person adds a father, then that creates a new family
Most Genealogy software vendors decided to follow the model that professional genealogists use. The basis is a family group sheet, that includes the father at the top left, the mother at the top right, and the children below.
The database structure then chosen is to have records of two types: Individuals and Families. These are exemplified by the GEDCOM standard which is used to transfer genealogy data between programs.
Then they use what is called a lineage-linked data structure. This structure has two connections:
The Individual will link to the family in which they are a husband or a wife (a FAMS link) and the Family will link back to the two individuals (a HUSB and a WIFE link).
The Individual will link to the families who are their parents, either blood or adopted (a FAMC), and each Family will link back to their children (CHIL links).
Once you develop your program, make sure it will be able to read and write GEDCOM.