Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 11 months ago.
Improve this question
I want to design them drawing an ER Diagram.
I have already designed an ER Diagram but teacher told me that it has only 5 entities and I need at least 7 or 8 entities. Also told me that I must not add primary key to a relationship(diamond shape).
So my question is how can i achieve this?
Here are the entities and properties of my database.
User – (user_id, username, profile_picture, member_date, user_gender, user_email)
Movie – (movie_id, movie_name, movie_year, movie_country, movie_description)
Review – (review_id, user_id, movie_id, review_score, review_date)
Actor – (actor_id, actor_name, actor_birthdate, actor_gender)
Genre – (genre_id, genre)
Director – (director_id, director_name)
Movie_Genre – (genre_id, movie_id)
Movie_Cast – (actor_id, movie_id)
Movie_Director – (director_id, movie_id)
I think the answer to your diagram questions is right there in your entity list. You have an entity named MOVIE_DIRECTOR but in the diagram you have a relationship named DIRECTS. You just need to change all your relationship diamonds to appropriately named entity rectangles and most of your issues will be resolved. For example, the relationship named "HAS" should really be the entity named MOVIE_GENRE.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
when we have two tables, suppose A and B,there exists one to many relationship between these two, than can there be element from A that are not connected to any element from B?
One to many relationship between relational tables is a concept that primarily means that if there is a record in table A, then it can have many associated records in table B.
For e.g. customer_id record in table A can have many loans for that customer in table B.
So 1 customer_id associated with many loan_ids in another table.
Coming back to your question, it is possible that 1 loan_id in loan_table can have multiple guarantors in guarantor_table and it is also possible that a loan does not have a guarantor associated with it. So even though there is one to many relationship between the tables it does not mean it will always have many records in table B for one record in table A.
Check this link - What is the difference of partiality and optionality when drawing ER diagrams
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have a couple of properties in my sql server SLS.Customer table which are references to other tables. I can't think of proper names for those tables. Help please :)
Table1: Contains the "How did you hear about us" values. (Example records: Through a friend, Advertisement, Seminar x, conference y, etc.)
Table2: Contains various reasons a customer refused to buy our product.
Table3: Contains the industry/business type a customer belongs to. (I thought of CustomerIndustry or just Industry but it sounds strange!!
Table4: Contains contact info of the person(s) related to a customer entity (specially if the customer is a company, rather than an individual, I need contact info of a person in charge). This is different from the tables PartyAddress and PartyPhones
As the question is suggestion based. I just put some suggestions here.
Table1:
RefererInfo
RefererDetails
Table2:
backlogReasons
backlogInfo
backlogDetails
Table3:
CustomerCategory
CustomerBackground
Table5:
PersonInChargeForParty
ContactsForParty
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have the following entities in my system: COMPANY, POSITION, APPLICANTS. There is many to many relationships between POSITION and APPLICANTS, but the current model does not show that there is many to many relationships between COMPANY and APPLICANTS.
Does it make sense to you to have a join table foo that has the company_id, position_id and applicant_id or i should have a table that joins COMPANY and POSITION and another that joins POSITION and APPLICANTS?
I don't think so. You can get APPLICANT for a given COMPANY via JOIN with POSITION.
I think a relationship between a COMPANY and an individual becomes significant when they shift from APPLICANT to EMPLOYEE. I would not model it as you propose.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I have 2 tables User and User_Event
User
id PK BIGINT
User_Event
event_id PK BIGINT
user_id FK References User.id
Should I create above tables before runtime
OR
should I create table "User_Event" for each Existing user at runtime (In this case table name would be like this
User_Event_user001,User_Event_user002....)
Now my questions is
1. Which design is better?
2. which implementation is faster?
For both questions, the best answer is to have an invariant database structure.
Modifying/creating the tables is a lot of work for databases, as they are designed for managing DATA inside the defined structures (tables, views).
It is very rare that changing the structure on the fly is pertinent, and even less effective.
--> create tables before runtime !
I don't know what is purpose of your system but classical implementation is to have one table User_Event and store data about all users in this table. If you want to get info for one user you should use query:
SELECT event_id FROM User_Event where user_id=<your user_id>;
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 months ago.
Improve this question
I'm looking for a little database design advice...
I have a spreadsheet with a few columns in it. Column 1 being a list of categories and the rest being related categories(to the category in column 1). I'm trying to figure out what the best way to setup the tables would be... My thought so far is to have a table that just lists the categories then have a table with 2 columns that holds the id of the category and the id of a related category.... Would this be the best way to do this? Any better ideas?
A self referencing table (parentId to childId) is how most people implement a hierarchical structure like the one you are describing.
Your way is the best. Academics would call it resolving a reflexive many-to-many relationship with an associative entity, but it's nothing more than what you described.
m:n relations should always (maybe there are exceptions) be made with extra table for relations. So it should be the most flexible solution