I am new to ER Diagrams and currently trying to model a database of a (simplified) online shopping platform. I was wondering if product categories and model should be separate entities from the product entity, or can categories and models be considered attributes under the product entity?
The short answer is "it depends" ...
It depends on your requirements, what you expect to do with the data, and if it has sense that "model" and "product_category" can be strong entities on their own.
For example, in normal conditions, I will assume that "product_category" is a strong entity... Why? My answer is that you can have product categories even if you don't have products for such categories.
Another reason to make it a strong entity could be reporting or making searches about product categories (It will be more easy for a database engine to list all "product categories" by searching a small table, instead of iterating for all available products to gather all their categories)
Conclusion: There is not good or wrong answer for this ... the model will be good if itself can answer your data requirements ...
Related
We need to build a category hierarchy, like
Clothing
Men
Suits
Classic
Modern
Business
Party
Trousers
Ties
Beachwear
Women
Dresses
Gala
Evening
Simple
Skirts
Long
Mid-size
Short
Mini
Blouses
Beachwear
I designed the Category entity to have a belongsToparent relationship only ( I think I will need a children property too?). So far, a product would be attached to one category only.
Now the client is saying he thinks it should be a many-to-many relationship, and he thinks we should attach a product to all the categories in the chain (like ProductA should be attached to categories "Mid-size"-"Skirts"-"Women"-"Clothing" each). To me this sounds like overkill and a lot of redundancy. I should have all the other relationships through the parent chain available.
However, I ask myself if this is realistic, as it actually are relationships which need to be traversed and thus result in additional queries.
What would be a good design for clothing categories? That it be a hierarchy seems to be required by the client (there are also tags).
(like ProductA should be attached to categories
"Mid-size"-"Skirts"-"Women"-"Clothing" each).
It is a standard requirement in e-commerce applications for one product to belong to several categories. It makes perfect sense to any manager.
You should implement tree-traversal using optimal tree functions, not parent-child relationships of Eloquent. Check, for example, this laravel package.
Some people maybe know ER-Diagrams? The model of a database
e.g.:
http://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model
So here is my database model:
(Translation: Werkstatt = Garage, Dienstleistung = Service, Kategorie = Category, Bewertung = Rating, bewerten = rate, besitzt = owns, hat = has)
My questions are:
1) I can model many-to-many relationships, one-to-one, one-to-many. Should I use own tables for them when needed? For example MANY-to-MANY relationship needs an own table.
Or will Laravel take care of the relationship by its Eloquent ORM?
2) You can design a database so good, that there can't be NULL-Values for example. Or that it handles dependencies or redundancy in a proper way (see http://en.wikipedia.org/wiki/Database_normalization#Normal_forms). Should I take care of redundancy and dependancy, or will again Laravel take care of that?
So in general I just want to know, how far should I go with my database design? Should I make it as good as possible, or is it enough just to create the basic entities?
Info: Here you can see the consquences which can happen if the database is not normalized:
http://en.wikipedia.org/wiki/Database_normalization#Free_the_database_of_modification_anomalies
Regards
It seems to me that there should be no direct relationship between USER and GARAGE. Rather, one USER should be be linked to RATING (one to many), and GARAGE to RATING (again, one to many). So I would have Ratings as a separate table, with each rating having a userid, a garageid, and a rating. I believe that in that case, you will not need a separate many-to-many table, unless you count the rating as the many-to-many table (which you shouldn't--Rating should have its own Eloquent model, in fact.) Disclaimer: I'm just a beginner at Laravel myself.
Using the snowflake schema image from wikipedia:
http://en.wikipedia.org/wiki/File:Snowflake-schema-example.png
Would it ever make sense to have a "Brand_Id" foreign key in Fact_Sales as you do in Dim_Product? There is a many-to-one relationship of sales/brands just like sales/products or products/brands, so is there any logical reason not to? You may want to join directly to the Dim_Brand table.
I'm probably not seeing something obvious.
The type of relationship you're looking at is a has-a relationship.
A product has a brand. A sale has a product; it's the thing that was sold. But a sale does not have a brand. Or, a better way of saying this, you cannot sell a brand. (don't read too far into that one...)
So, no, you wouldn't want to add brand to sales.
If you are working in a dimensional model (the Star/Snowflake schema note in your question makes be think you are), then adding the BRAND_ID to the sales fact makes sense from a performance perspective, if the questions that the business is trying to answer are "what were the sales for brand X across all products in this time frame".
It also may be useful if the product dimension is a Type 1 SCD, and a product changes brands. You may want to preserve the prior sales as being of the "old" brand.
Keep in mind you are not doing entity - relationship modeling when you build a star/snowflake reporting schema. Questions of is-a or has-a aren't pertinent to a dimensional model.
I think that would be nice as a way to cache the data... but in all honesty, your probably better off just relying on the links as they are.
The reasoning is that you already have that definition of what that table does, store sales. To add in what brand those products are that the store sold is going to muddy the 'topic' or 'theme' of that table, recording sales of a store.
Now if by some way you had a product that can be sold under different brands (heck if I know how a package can have split personalities...) then yea, it would make sense to a degree, but a more reasonable solution is to give each product it's own SKU code then.
I am about to deign my first E-Commerce Database.
What i have find out in most E-Commerce websites is that these sites have Category, then SubCategory and then again SubCategory and so on. And the depth of SubCategory is not fixed means One Category have six nested Sub Category while some other have different
Now All the products have attributes associated with it.
Now my question is are these websites keep on adding tables for nested sub categories and keep on adding columns for the attributes in the database
OR
They apply something called as "EAV" model (if i am right) to solve this problem or they keep on adding columns and or tables and also keep on updated the WebPages as on many sites i have found there is now a new category.
(If they use EAV model then the website performance is impacted isnt it..)
Since this is my first ECommerce project please provide some valuable suggestions of yours.
Thanks,
Any help is appreciated.
What you need is a combination of EAV for product features and nested sets for product categories.
While I certainly agree that EAV is almost always a bad choice, one application where EAV is the perfect choice is for handling product attributes in an online catalog.
Think about how websites show product attributes... The attributes of products are always shown as a vertical list with two columns: "Attribute" | "Value". Sometimes these lists show side-by-side comparisons of multiple products. EAV works perfectly for doing this kind of thing. The things that make EAV meaningless and inefficient for most applications are exactly what makes EAV meaningful and efficient for product attributes in an online catalog.
One of the reasons why everyone always says "EAV is EVIL!" is that the attributes in EAV are "meaningless" insofar as the column name (i.e. meaning of the attribute) is table-driven and is therefore not defined by the schema. The whole point of schemas is to give your model meaning so this point is well taken. However in the case of an online product catalog, the meaning of product attributes is really unimportant to the system, itself. The only reason your catalog system cares about product attributes is to dump them in a list or possibly in a product comparison matrix. Therefore EAV is doesn't happen to be evil in this particular case.
For product categories, you want a nested set model, as I described in the answer to this question. Nested sets give you very quick retrieval along with the ability to traverse multiple levels of an unbalanced hierarchy at the expense of some precalculation effort at edit time.
2 part question:
1st
What is the best way to setup a table/relationship structure given the following scenario: I have many tables that store different kinds of data (ie: books, movies, magazine - each as different tables) and then one table that stores reviews that can link to any of the table types. So a row in the review table can link to either books or magazines table.
How I have it now is that there is a 3rd table that defines the available tables and gives them an ID number. There ends up being no true relationship stored that goes from Reviews to Books. Is this the best way to do this?
2nd
How do I represent the fake relationship in Entity Framework? I can do a query that would join the 3 tables, but is there a way to model it in the table mapping instead?
The other way to think of it is to consider BOOKS, MOVIES, MAGAZINES as sub-types of REVIEWABLE_ITEMS. They probably share some common characteristics - without knowing more about your problem domain it would be hard to be sure. The advantage of this approach is that you can model REVIEWS as a dependency of REVIEWABLE_ITEMS, giving you both a single table for Reviews and an enforceable relationship.
edit
Yes, this is just like extending types in the OO paradigm. You don't say which flavour of database you're intending to use but this article by Joe Celko shows how to do it in SQL Server. The exact same implementation works in Oracle, and I expect it would work in most other RDBMS products too.
It really depends on how you want to access/view the reviews.
I would implement one table for each kind of revew: one for books, one for movies, etc. with a one-to-many relationship for each of them (between books and books reviews, movies and movie reviews, etc). If you need all the reviews in one table, create a view which selects all reviews with a UNION ALL.
Either you include a concept "reviewable", which can be either a book or a magazine or ... , and to which "reviews" can refer, or else you can have a concept "review", which can either be a "book review" that can reference a book, or a "magazine review" that can reference a magazine, or a "newspaper review" that can reference a newspaper, ...
Because truly relational systems do not exist, you cannot do without explicitizing one of those two abstractions in your database design. (Unless perhaps if you are willing to implement a lot of trigger code.)