So in my application database I have a business profile entity that has:
one main Category (e.g. Restaurant, Hotel, Hospital, ...etc)
unlimited Subcategories (e.g. pizza restaurant, Italian restaurant, ...etc)
unlimited products (e.g. cheese pizza, pepperoni pizza, ...etc)
unlimited services (e.g. pick-up service, delivery service, ...etc)
P.S. I went with the Restaurant category as an example to demonstration its subcategories/services/products entities, but, it could be any anything really.
First: I can use something like the Adjacency List Model to define unlimited categories and their corresponding subcategories but, what about services and products entities ? how can I link them all to each another knowing that services and products are children of the subcategory entity?
For now this is what I have:
Figure-1
Second: How can I map each Business profile with its Category/subcategories/products/services ?! so that I know each business profile is under what category and what are the subcategories/products/services that each business profile has.
Here is the mapping that I have at the moment:
Figure-2
I am yet a novice database designer, I'm trying to make this database to be as much efficient as possible, as it will receive a lot of traffic. Is what I have now valid as a database scheme or is there any database designing concepts that needs to be dig deeper?
When I read this question I was worried this was going to have a complicated tree structure, but reading your work so far it's very clean and simple.
Personally, I think you're on the right track, and would make a few notes:
It's not hard to link services and products to subcategories, and you can also easily link businesses and products/services. I don't think this needs to be a tree. Just enforce this restriction when the records are created.
Adjacency List Model makes a lot of sense for trees of arbitrary depth for which you need to easily find subtrees, but I'm not sure if that fits your problem, in particular because:
You don't have arbitrary depth. You just have parents and sub-categories.
For something like a business-category system, the number of entries might be low enough that it's not worth adding the extra complexity. It's probably pretty fast to read the entire table and keep it in memory.
If you want services and products linked to both subcategories and categories, the simplest might be to have a single category table and have each category have a parent_id that may be null.
Related
I've a requirement to design a database for an ecommerce app that has vast scope of product categories ranging from pin to plane. All products have different kinds of features. For example, a mobile phone has specific features like memory, camera mega pixel, screen size etc whilst a house has land size, number of storeys and rooms, garage size etc. Such specific features go on and on as much as we've products. Whist all have some common features, there are mostly very different and specific features of all. So, it has gotten bit confusing while designing its database. I'm doing it for the first time.
My query is about database design. Here is what I'm planning to do:
Create a master table with all fields, that tells if a field is common or specific and map them with respective category of the product. All products will have "common" fields but "specific" will be shown only for one category.
table: ALL_COLUMNS
columns:
id,
name,
type(common or specific),
category(phone, car, laptop etc.)
Fetch respective fields from all_columns table while showing the fields on the front.
Store the user data in another table along with mapped fields
table: ALL_USER_DATA
columns:
id,
columnid,
value
I don't know what is the right way and how it is done with established apps and site. So, I'm looking forward if someone could tell if this is the right way of database architecture of an ecommerce app with highly comprehensive and sparse set of categories and features.
Thank you all.
There are many possible answers to this question - see the "related" questions alongside this one.
The design for your ALL_USER_DATA table is commonly known as "entity/attribute/value" (EAV). It's widely considered horrible (search SO for why) - it's theoretically flexible, but imagine finding "airplanes made by Boeing with a wingspan of at least 20 metres suitable for pilots with a new qualification" - your queries become almost unintelligible really fast.
The alternative is to create a schema that can store polymorphic data types - again, look on Stack Overflow for how that might work.
The simple answer is that the relational model is not a good fit for this - you don't want to make a schema change for each new product type your store uses, and you don't want to have hundreds of different tables/columns.
My recommendation is to store the core, common information, and all the relationships in SQL, and to store the extended information as XML or JSON. MySQL is pretty good at querying JSON, and it's a native data type.
Your data model would be something like:
Categories
---------
category_id
parent_category_id
name
Products
--------
product_id
price
valid_for_sale
added_date
extended_properties (JSON/XML)
Category_products
-----------------
category_id
product_id
I have some experience getting data out of database, but not so much in design. To work on this, I'm taking some personal projects and trying to create them in access. I've run across an issue that I was able to get a solution to, but I find it clumsy and was hoping to have some opinions on what I can do better.
My current project is a monthly budget. At this stage I would like a Form to appear as follows:
Category
Sub-Category Budget_Amount
Sub-Category Budget_Amount
Category
Sub-Category Budget_Amount
etc.
I found that I can do this if all the sub-categories are the fields in a table and the category names are hard-coded as labels in the form. However, I would like my table structure to be like this:
Category:
ID
Category_Name
Sub-Category:
ID
Sub-Category
ID_Category
Show_Category
Budget:
Id
Sub-CategoryID
Budget_Amount
The reason I want this structure is that not all sub-categories will be used every month, and in my mind it will be easier to match what was budgeted verses what was spent. I am also trying to practice minimizing space taken up by the database. Are there any ways to do this easily? Or am restricted to my current solution?
I would dive into normalization principles first as you seem not to be too familiar on those principles yet.
"The reason I want this structure..." is not a good reason at all.
Your basic is a sound normalized database structure.
I'd suggest you structure your tables like this:
tblCategory -> CatID (autonumber PK), Categorie
tblSubCategory -> SubCatID (autonumber, PK), CatID (number, FK), Subcategory
As for budgets, I'd expect that budgets tie in into projects. There's no logical reason to tie in budgets directly into any kind of category.
We would need more and escepially more explicit information on what you're trying to achieve.
Similar question:
Database Design Question - Categories / Subcategories
There's sites that could help you to start understanding designing in MS Access, for instance
http://www.functionx.com/access/index.htm
You set up a database company, ArtBase, that builds a product for art galleries. The core of this product is a database with a schema
that captures all the information that galleries need to maintain.
Galleries keep information about artists, their names (which are
unique), birthplaces, age, and style of art.
For each piece of artwork, the artist, the year it was made, its
unique title, its type of art (e.g., painting, lithograph, sculpture,
photograph), and its price must be stored.
Pieces of artwork are also classified into groups of various kinds,
for example, portraits, still lifes, works by Picasso, or works of the
19th century; a given piece may belong to more than one group. Each
group is identified by a name (like those just given) that describes
the group.
Finally, galleries keep information about customers. For each
customer, galleries keep that person’s unique name, address, total
amount of dollars spent in the gallery (very important!), and the
artists and groups of art that the customer tends to like.
Draw the ER diagram for the database.
Is the following ERD correct?
Is it possible that a group has zero Artworks?
Is it possible that the Artist didn't produce any artwork but still sits in the database?
1) You used ID as a PK in Artist and Artwork. This is a good thing as the use of an unique name (as requested in the business model) is wrong: after all, two pieces of art or two artists may bear the same name. However, you did respect the business model for the Customer entity whose PK is Name.
You can choose to make a good ERD and use ID as a surrogate PK for Artwork, Artist, and Customer; or respect the business model you were given and use Name as a PK for these three entities. Personally, I'd go with the former.
The following two questions can't be answered given the business model only; the answers below reflect the cardinality in the specific ERD you designed.
2) Yes, because according to the ERD a Group includes from 0 to N Artworks;
3) Yes, because according to the ERD although an Artist makes from 1 to N Artworks (and therefore there wouldn't be the need to insert an Artist in the database if he didn't do any Artwork) there is still a relationship between Customer and Artist in the sense that a Customer likes from 1 to N Artists.
Therefore an Artist can be in the database even if he didn't produce any Artwork (yet), provided that he is liked by at least one Customer. If an Artist didn't do any Artwork and is not liked by any Customer, he won't be in the database.
Missing some context information here, especialy some cadinality information. Pay attention to yourself asking questions about the context:
Is it possible that a group has zero Artworks?
Is it possible that the Artist didn't produce any artwork but still
sits in the database?
This information should be given by you (or by the presenting problem). If this is a work of your course or your college, your instructor needs to better explain the present context. If you are already working as a DBA or data modeler, please look for more information about this problem. It's almost indescribable the importance of a context in the development of an ER-Diagram. Keep this in mind: Without a well-defined context, the problem (the situation) is uncertain, and so is missing information to complete the reflection of a real-world situation. In short:
No complete context, no diagram (without a diagram, there is no system!).
I will make this diagram with you step-by-step, but I'll take some assumptions due to lack of information (context) here. I will give my opinion on certain resources used in ER-Diagram, but that does not mean that I'm saying you're layman. I am just showing my thought, which shows how I learned that here in my country. I believe that you are as capable as I am, ok? Well, let's begin...
Entities in ER-Diagram are defined when we have attributes / properties. According to your description, we can see immediately 3 entities here:
Customers
Artists
Artworks
Relationships exists to express links between entities. The most obvious relationship here is between Artists and Artworks, Don't you agree?
For each piece of artwork, the artist...
In accordance with the context revealed, all artwork has a unique artist (always), but it is uncertain if an artist always has one, multiple, or zero artworks. I SUPPOSE that an artist can have many or no artwork. That being said, we see that artists to artworks have a cardinality 0 to N, because, again, an artist may have made several or no artwork at all.
So far we have defined three entities, and linked two of them. Let's continue...
...its type of art (e.g., painting, lithograph, sculpture, photograph)...
If an artwork has only a single type of art, and an art type is defined only by its name, then we have here what is called a Functional Redundancy (translated from the Portuguese term "Redundância Funcional"). In spit summary, Functional Redundancies are like relationships between two entities, and serve to save you the trouble of repeating the same field in multiple columns in a table (which would be susceptible to errors). In a Conceptual Model, they are represented as a field in an entity with the suffix "(R)" (without the double-quotes).
If an entity has a field (column) like a Functional Redundancy, but with different values (multiple), then we have what is called Multivalued Field (also translated from the Portuguese term "Campo Multivalorado"). These are fields in entities that have the suffix "*" (also without the double-quotes).
This is not the case of the type of artwork, but it would until now for the groups of each artwork:
Pieces of artwork are also classified into groups of various kinds,
for example, portraits, still lifes, works by Picasso, or works of the
19th century; a given piece may belong to more than one group.
This would be true if groups only possess names, and no other entity relate to them. But then you said:
and groups of art that the customer tends to like.
This has changed things a bit. Groups no longer is a Multivalued Field in Artworks entity and becomes an entity with two relationships, one for Customers and one for Artworks. The relationship between Groups and Customers reveals the preferred art groups by customers. The relationship between groups and artworks shows which art groups a artwork is related. Now let's talk about the cardinalities of these relationships.
...a given piece may belong to more than one group. [...]
...and groups of art that the customer tends to like. [...]
Concerning Groups and Artworks, the word "may" says a lot to me. It says that something may or may not be effective. Still, it is uncertain whether an artwork can exist without at least one related group. Because of this, I see a 1 to N relationship from Artworks to Groups.
Conversely, the opposite process is not clear. I believe that there may be groups unrelated to artworks, perhaps because they are new groups created in a given time. So I see a relationship of 0 to N from Groups to Artworks.
Let's talk about Groups and Customers. It seems to me that a customer like at least one group of art. So I see a 1 to N relationship from Customers to Groups.On the opposite side, as already said, it would be possible to add new groups without automatically tying at least one customer to it. I think there may be new groups unrelated to customers. So guess what? We have a relationship of 0 to N from Customers to Groups.
So far we have identified another entity, a Functional Redundancy,
and two relationships with their respective cardinalities. Let's keep going...
and the artists ... that the customer tends to like.
There is a close connection here between two entities, Customers, and Artists. This relationship tells us what artists the customers like. If a customer must like at least one artist, then we have a 1 to N relationship from Customers to Artists. If a customer may or may not like an artist, then we have a relationship 0 to N.
If an artist has zero or more customers who appreciate it, then we have a relationship 0 to N from Artists to Customers. If an artist has at least one client who appreciates it's work, then we have a 1 to N relationship from Artists to Customers.
Lastly...
Galleries keep information about artists, [...] and style of art.
If multiple artists can share a single same art style, then we have a Functional Redundancy here. If several artists have various art styles, then we have a Multivalued Field.
After much talk, I came up with an ER-Diagram presented by your context and assumptions made by me:
NOTE: The green points highlights major assumptions.
Is this right? Is this the correct diagram? The correct answer would be (from me to you):
I do not know...
Without a concrete context, we can not finalize a diagram correctly. My tip is that you finish your context. Only then you will have a correct diagram.
Oh, one more thing. What would be this "money spent" attribute? If customers can buy artworks, it would represent a new relationship between Artworks and Customers. This relationship would represent the purchase of artworks from customers (called "ORDERS", for instance). If not so, skip this paragraph.
If I have forgotten something, please say so. If you have questions feel free to ask, I'm here to help you.
I have a database that seems to be challenging to my knowledge on database design.
I will try to explain and then I will ask the question.
I have a list of companies that have interact with the system and those companies can operate within my country and only my country, all the companies are dedicated to fishing activities. Those companies can have product providers or just fish by themselves. Those providers can operate in any country. The products bought from providers (most of them are frozen fish) can also come from any country and it is not necessarily the provider's country.
Of course I have a country table with the default value set to my country, that table is also referenced by providers and products.
Well, with this design, there is no way to avoid relationships crossing. But my real question are,
is it a good practice to allow this to happen?
If not, how should i redesign it to fix it?
If yes, why everyone tells me to prevent this kind of relations?
Thanks!
Your database design should be OK. Something that need to defined with different country should have to be. There is no something "crossing" logically with it.
The one thing you should avoid in database design is Circular Relation which is A need B, B need C and C need A.
Well, let's analyse the situation:
Those companies can operate within my country and only my country
I'm assuming the companies are represented by the user table; technically they wouldn't need a country, but looking ahead you may want to have companies from other countries.
Those providers can operate in any country.
Okay, so provider definitely needs their own country field.
The products bought from providers (most of them are frozen fish) can also come from any country and it is not necessarily the provider's country.
So product also needs their own country field.
Basically, you will want to represent a product from country X, bought from a provider of country Y and delivered by company from country Z. The model you have designed seems to reflect those relationships correctly.
Can anyone help me to design database/table based on below criteria?
An e-commerce website is required which will allow visitors to browse, search and buy films. The following business logic applies:
Each film can be available in DVD or Blu-ray formats with different stock codes and prices. Additional formats may be added in the future by the website administrator.
Films should have a title, description, year they were released and a “star rating” out of ten stored against them.
Films are associated to none or more actor and actors can be associated to none or more films as some films may be documentaries (with no actors).
Films can be associated to one or more genre (such as action, adventure, Sci-Fi, etc).
The number of genres and actors may change so the website administrator needs to be able to add/edit as many genres and actors as they like over time.
Visitors of the website should be able to find films by browsing by actor or genre. When they do they should be able to see a list of all films that are associated to the actor/genre they have selected.
In order to buy from the website, visitors must register their details to become a user.
Users will have one or more addresses associated to their account. When they log in to the system in future all of their previously entered addresses should be available for them to select for their latest order. They should also be able to add a new address to their account at any time.
When ordering the user will select one or more items from the available films (in a particular format). They will need to select a billing and deliver address from those they have previously entered and pay for their order by credit card.
As the prices of the products can change over time the system should record what the price of each of the items in their order was at the time when they purchased as well as the total price of the entire order.
Tracking of stock levels is not required – all products can be assumed to be in stock all of the time.
If this is homework, or a class project, then you really need to start learning about normalisation. Take a look at the article on wikipedia or this introduction on the MySQL site
If this is a professional project, then you need professional help to design/develop your e-commerce site.
Here is something I could come up with, hopefully it should satisfy all the criteria mentioned in your requirements. I was designed in SQL Server as I do not have MySQL on this machine.
Steps to design the database (entity relationship modeling)
Identify the entities from the requirement. Entities are objects that hold information (usually denote real world entities like person, car, bank, employee, etc.). In your case, the entities identifiable are: Film, Actor, User, Order
Once you have identified the entities in your requirements, get down to the deciding the attributes (or properties) of the entities. The attributes are something that you associate the entity with. For example, one would identity a car by its manufacturer, model, color, engine capacity, etc. In your case, the attributes for the film entity would be Name, Genre, ActorInFilm(s), Format(s), Price
Identify the relationships between the entities. In your case, film has a relationship with actor. The relationship is: One film can have zero or more actors. And, one actor can act in one or more films. Thus film and actor are related.
Identify the cardinality of the relationships. Cardinality can be explained in simple terms as how many instance of the entity participate in the relationship.
For example, a employer can have 1 or more employees. And an employee can be employed by only one employer. In this case, there are 2 entities: Employer and Employee. They share the relationship employ. In your requirement, Film and Actor are the entities sharing the relationship Acts in (Actor(s) acts in Film). So the cardinality in this case will be one to many (Film to Actors)(one Actor can act in many Films) and zero to many (Actors to Films).
Once this part is done, you have your zero normal entity relationship diagram. Then comes the normalization. You can read about it on another post here.
After you have normalized the entity relationships (upto 3rd normal form is usually sufficient), you can implement the database design in the SQL design software (MySQL, etc.)
The best way to do the above steps is to take a sheet of paper and write the entities and attributes in a tabular format and then link them to other entities (to denote relationships).
You can refer any good book on database concepts (including normalization) or just search on google (keywords: database, normalization, database design, entity relationship modeling, etc.). What I have explained above is very brief, you will need to discover the rest of the database concepts yourself.
Entity relationship diagram is often abbreviated as ER diagram.