I have product classification like this?
book
literature
science
pet
pet food
pet toy
There classes are modeled as ISA relation. Under the leaf node, there will be individuals. For example:
Literature_1
Literature_2
Science_1
Science_2
These are specific books modeled as individuals. For each class, i.e. "book, literature" etc, I have a code attached to it. For example:
book 001
literature 0101
science 0202
pet 008
pet food 1212
pet toy 1313
In addition to the ISA and individual modeling, I also need to model these codes and associate them to corresponding classes, so that it can allow answering such questions:
What's the code of the category 'book'?
What would be the proper way to model this 'code'? I don't feel it should be modeled as classes.
Related
I've been asked by my teacher to make the ER diagram of a certain library. Here is a very simple and not complete ER diagram only to illustrate my point:
Searching the library's website I found exactly the attributes I need for the customer, for the copies the book etc. However, the book is not the only thing provided by the library. The library provides music-CDs , journals, DVDs and many more leading to 20 different kinds of items in total.
One very ugly solution would be to create a different entity for all these items and connect each one of them with the copy entity. And this seems unavoidable since each item type has different attributes. A book for example has ISBN and a journal the ISSN. Looking at all the attributes of each item the only thing they all have in common is a title.
Is there a better way to do the ER diagram?
unfortunately no, he is asking for an academic solution and the way to represent the mini-world in er is 1 entity type per object. this is my vision to ER diagrams in its simplest academic form.
if you continue to sum entity types together, your entire mini world will be one entity type.
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?
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.
My assignment is to draw an ER model (by hand) using Chen notation using the specifications below:
http://i57.tinypic.com/73ff2f.png
If you have questions about these specs. I'll play the role of the
client who will resolve them.
The database will serve a university.
Students have id's, names and gpa's. They must have exactly one major,
but they could have minors as well. Each major or minor is a
department which has a unique name and a phone number. For each
student with a minor, we record the date she signed up for it. Faculty
members are associated with a unique department and have id's, names
and office locations. Each internship is held by a particular student
at a particular compain and is supervised by a particular faculty
member. We also keep track of the last term in which that student
registered under that advisor for an internship at that company.
Students may have many internships over time. A given faculty member
may supervise many students at a given company, and she may supervise
a given student at several companies. However, for a given student and
company, there can be only one faculty advisor.
Students, Departments,
Faculty and Companies should be your entity types. Internship should
be a ternary relationship type. The specs should also lead you to some
binary relationship types. Don't add any ingredients to this mix other
than what appear in the specs.
Below is my work:
http://i60.tinypic.com/28rf7tf.jpg
Can anyone please help as I really need a better understanding of this (my professor is AWFUL at explaining this).
You missed (per your assignment's last paragraph) a department entity type. (Box.)
You missed 'Faculty members are associated with a unique department'. That's a relationship between those two entity types. (Diamond with lines to those boxes.)
You could have those major and minor entitie types that are 1:1 with departments. (Your present boxes with each a line to its own diamond each with a line to department.) But (per your assignment's last paragraph not listing them as entities) you could have major being a relationship 'student[s] has a major in department [d]' and similarly for minor. (Lines from student to each of two diamonds each with a line to department.) But the assignment actually says 'each major or minor is a department' so that's major as 'student[s] has major department [d]' and similarly for minor. (Same picture.)
Per your assignment's last paragraph you should make internship a ternary relationship. (Under Chen it's a relationship diamond (possibly with its own properties) formed by 3 lines to entity type rectangles (possibly with their own properties) rather than an entity box.) However, it's not clear exactly when your assignment considers that an internship holds. (It tells us what relationships hold; it's just not clear which one it wants to call interning.) (Although we can look for interpretations consistent with it being ternary.) One is 'student [s] interns at company [c] supervised by faculty member [f]'. But since 'for a given student and company, there can be only one faculty advisor' that notion of internship is more simply characterized by a binary relationship 'student [s] interns at company [c]'. But then you still need a relationship 'faculty member [f] advises student [s] at a company [c]'. So I will suggest that your assignment expects the former. We can add property term. (This is more reasonably called a relationship on student, company, faculty member and date; but E-RM considers relationships to be on entities. Although it all depends on your class's method's particulars.)
(The possibility of multiple reasonable variations is why you should propose a particular design fully handling a particular specification in a SO question.)
A problem with the E-R Model [sic] is that it introduces needless distinctions between entities, reltionships and properties. There is really no distinction between a relationship instance and an entity. Eg: Here we could just as well have an internship be per above an entity in a 4-way relationship plus property. Eg: Your assignment says 'each major or minor is a department'. But a major or minor isn't a department. A major or minor could be considered a subject, which would be the subject after which a department is named or the subject of the degree offered by a department. Or we could just have relationships in which a department participates but the relationship is about that department's subject or name or degree being a major or minor.
(If an internship as relationship participated in its own relationships I don't know how your instructor's particular method would keep the further lines organized. Some methods add internship entities (box) 1:1 with relationships (diamond); then some methods specially associate the entity type with the relationship as a reification while some make the relationship 4-way by including the reified entity type. Eg 'internship [i] is student [s] at company [c] and ...'.)
(Correctly speaking there are entity types vs relationships and entities vs relationship instances. But the assignment talks of relationship "types".)
Re E-RM see this answer and this one. Also the E-RM wiki page section 'Entity–relationship modeling'. (Which correctly mentions misinterpretations of Chen's E-RM & E-RDs by some related modeling and diagramming methods and tools and even some presentations of E-RM itself. But the 'Overview' is nonsense.)
Re E-RM problems see this.
I'm learning database this semester. The homework on e-r model really confuses me.
The homework is drawing the e-r diagram about a vegetable market: A Vegetable Market has a collection of numbered stalls. Each stall has a name (unique) and sells at least one kind of vegetables (each kind of which has a name). Each stall sells each vegetable at its own particular price. Each farm grows some (at least one, but not all) of the vegetables, but a vegetable must be grown by at least one farm. Each farm has one name (unique) and address. Each stall buys each vegetable from only one farm at a particular price they have agreed.
My question is that how to describe the constraint "(at least one, but not all)" in the requirement?
Another question is that since vegetables don't have primary key or discriminator, should they be treated as entities? Or should they be treated as somethings else like attributes?
Here's my answer:
(source: rrimg.com)
Ad.1
As far as I know it is impossible to place on a ERD diagram information like at least one, but not all, I would simply mark the relationship as one or more, which is possible. The only thing that comes to my mind is placing an appropriate comment, stating that requirement.
Ad. 2
Yes, vegetable in my opinion should be represented as a separated entity. If you wanted to place it as an attribute, you coud do this as an attribute of entity "Farm_grows", but you will not be able to preserve uniqueness, you will have to have some key anywas, and finally the worst thing is that, it wouldn't be 3NF.
My propositions is on the below diagram - unfortunatelly I do not have a tool that supports your notation (I know it would be possible to do it in Visio, but you shouldn't have any problems translating my notation to yours).
The difference in comparison to yours is that I have one relationship for SELL and BUY, which is STALL_VEGETABLE. Why is that so? Because of this requirement:
"Each stall buys each vegetable from only one farm at a particular price they have agreed."
My model preserves that the Stall sells only those vegetables, that it bought, and also it because stall_name and vegetable_name are withing PK, it is impossible for Stall to buy one vegetable from different farms - your model allows that.