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.
Related
For our project we want to save employees and customer in one or two database tables.
The customers have the same columns as the employees (e.g. name, address, language, email,...).
The employees on the other side do have additional columns like SocialSecurity Number, bankaccount,...
Since the two have many similar columns it might be senseful to merge them into a single 'person' table, considering that there might be from time to time a case where a customer get an employee or vice versa.
But since in the application this two 'roles' of people are strictly separated (we have querys where we want to get all customers and querys to get all employees, or search a person by email where role is customer / employee), then it might be more performant to keep them seperate.
Is there a big performance difference between this two solutions or is there even a third & better one?
I would not make this decision based on performance. I would make the decision based on security considerations and access rules.
In almost all circumstances I can think of, you would want separate tables for customers and employees. You could have a third table, persons, for common attributes such as names and addresses. That said, there are so many differences between the two, that I'm not even sure that is a good idea:
Customers could be incorporated entities such as companies.
Customers could be from anywhere in the world, but it is reasonable in many situations to assume that employees are local.
Employees have dependents.
You may maintain information such as gender, race, and age that you would not want to maintain about customers.
Those are just a few items that immediately come to mind. There are many other differences.
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.
I am working on a site which provides coupons for online shopping sites.
It provides discount coupons for shopping sites in India.
But now the client wants to provide coupons for USA stores also.
But offers available for Indian users are not useful for the USA users and vice versa.
Therefore there will be two versions of the site. One is for the Indian users and other is for the USA users.
But if a user from India searches for an offer which is not available in India but is available in the USA. Then it should appear in search results.
Now I am thinking of creating a new database for the USA users with exact same schema as that of the database for current users(Indian users).
But I would like to get advice from an expert.
In the long run you might want to add more countries so I would do it by adding a country table kind of thing and something like offer_valid for offerid country id which would make a single offer valid for one country or more.
Creating multiple databases would make the maintenance hectic.
Creating a separate database or a separate table (by adding _usa to table name) for that matter does not make sense.. because the same can be achieved by creating a mapping table which maps offers/coupons to the country/countries for which it is valid and is more scalable as well.
Here is what I suggest:
countries: id, name
coupons: id, name, discount
coupon_country_mapping: id, country_id, coupon_id, is_active
New to database design and admittedly over my head. Trying to create a small database that will allow me to find state highway construction project information along any given road. Relationships include:
One contract number to one project; One county to many projects; One road to many projects; One road to many counties and one county to many roads; One manager to many projects; One contractor to many projects; One contact list (phone, email) to one manager; One date each (bid, start, complete) to many projects.
Would be a small database, maybe 500 records total. There are only 6 counties. Right now I've broken roads down into 6 separate "roads by county" tables so while the route number may be the same in different counties each record will be unique because it's in a separate county table. Is this OK or is it better to keep one roads table and assign county values there? I created other tables listing the counties, contracts, contractors, managers, dates and project description. Just don't know what to do with them.
My purpose is to be able to search, mostly by road number and keyword, to find what projects are on what road at any given time. I'd also like to update this info via forms. The data will change frequently and it's just a little too unruly for a spreadsheet. I simply can't wrap my head around how to setup and relate the tables and individual records. Any thoughts would be phenomenally appreciated.
I imagine a database with a simple structure.
The relations many-to-many normally should and can be avoided.
Access doesn't have a direct implementation of this relations. You need to create a cross table between the two main tables.
Anyway I created a database for projects more complex than this so I tried to accomplish your request.
The "core" table is tblProjects that refers for details to other tables.
Since projects are related to roads, I use road as the main item and a road can have a list of counties. If you want to know how many projects are in a county it can be simply done with a query looking for all the roads that have that County_ID.
If you want to look up for project for one road, simply find the road_ID (e.g. using a combo-box to select it) and you can filter (query) the tblProjects by Road_ID.
tblManagers
*IDManager
LastName
FirstName
eMail
Phone
Mobile
tblContractors
*IDContractor
ContractorName
Reference
tblCounties
*IDCounty
CountyName
Road_ID
tblRoads
*IDRoad
RoadNum
RoadName
tblProjects
*IDProject
ContractNum
ProjectName
StartDate
EndDate
BidDate
Contractor_ID
Road_ID
Manager_ID
The fields with * are the Key Fields. They are in relations with the _ID corresponding fields (check referential integrity and cascade deletion when you create the relation).
Let me know
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.