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 2 years ago.
Improve this question
I have an EER diagram of the hospital database. I am currently working on the normalization process.
As I understand the partial dependency is when an attribute is dependent on only the part of the composite primary key. And this should be removed.
I've applied the rules on my database but still want to make sure that these tables doesn't include partial dependency.
In examinationo table the composite key consists of inpatient_no, doct_no and lab_no. In my opinion diagnosis and conducted_test attributes depend on all three of them. Is this correct?
This table has composite key of inpatient_no, doct_no and surgery_no. The attributes date and time convey information when the inpatient will undergo the surgery. Is this a partial dependncy?
I'm very new to databases, so my quesitions can be quite easy.
It looks to me like your table called inpatient_undergoes_surgery represents an entity, in this case an event. The table has one row for each surgical appointment. It has date and time as attributes. It also has one-to-one relationships to an inpatient, doctor, and surgery.
This table appears to be normalized to me. The others might not be. In particular, it's possible that your surgery table duplicates the information in this table.
Pro tip It's best to use a DATETIME or TIMESTAMP data type to represent the kind of date and time in your table. There's no need to use separate columns for date and time. Understanding that the date and time taken together are actually a single attribute of your entity helps clarify your design process.
Related
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 6 years ago.
Improve this question
I have two tables in my db:
Marketers:
Id, Username, Password, Email
Stores:
Marketer Id, 1 Store, 2 Store, 3 Store, 4 Store, ...., 10 store
there is the names of 10 stores for every marketer in Stores table.
So there is a one to one relationship between these two tables. right?
I'm wondering if it would be better to just combine these two tables or not.
I wan't to send a lot of query for the second table (Stores tables). so I though this would be better if I separate these two cause I rarely need the information stored in 'Marketers table'.
From a good design perspective, you should keep these tables as separate.
for your current requirements,
if you do not need data from Marketers so often, why do you need to include that in Stores. you would just end up fetching extra data each time.
say if tomorrow if some new info and the mapping changes to one to many or vice versa, your current design will work perfectly fine.
and of course from future maintainence view, it is easier to update current design.
although, i would also, suggest you to add an independent primary to Stores table also.
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 years ago.
Improve this question
I have a table like:
classes:id,time_instructor_id
instructors:id,name
I want each instructors to have one or many classes which is fine with my current design...
What for ex in the future one instructors leaves the job and another one can substitute that instructor, how do I assign the class to the new Instructor?
I was thinking in this case if I could have a N:N table?
What is your opinion?
You have no problem. If an instructor leaves and another instructor is added and takes over the first instructor's classes you can simply UPDATE the instructor_id value for those classes with the new instructor's id.
You do not need a many-to-many table unless you want to be able to assign more than one instructor per class.
Is there more to your requirement than stated in your question?
Yes, you can create third table called classes_instructors (this might depend on the framework conventions) which will have two attributes, maybe 3rd one to show whether is it active.
id
class_id
instructor_id
active
This is pretty common schema and pattern to use a many-to-many relationship through a join table. Some people tend to call it associative table or entity many-to-many relation.
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 years ago.
Improve this question
I'm currently trying to build a football database in MySQL. It should store the fixtures from different leagues, plus their results, odds and some other information.
Is the scheme I just created correct or are there any mistakes in it? If so, what can I improve? I'm also not really sure about the link between tblMatch and tblTeams.
Afterwards I want to be able to make a Query where I can select a fixture including the points the home and away team got before the match, plus the average amount of goals of the teams. Like the new fields: 'homeTeamPoints', 'awayTeamPoints' ect.
So my question is: Where should I put these fields? In an extra table or should I put those in the table: 'tblMatch' and store the precalculated values there?
I hope you get what I tried to explain.
Best Regards
-bababow
A few notes:
You will want to replace "homeTeam" and "awayTeam" with "homeTeamID" and "awayTeamId" which will be foreign keys to the tblTeams table. This will enforce that the teams in the match both actually exist.
Remove the matchID and competitionID from the teams. I'm assuming teams can participate in many matches and competitions and therefore this structure will not support that.
What do you want to know about competitions? Is this a tournament? You may want to have a "bracket" and/or "tournament winner" column in there to store the results of the overall tournament.
Those are my main thoughts, other than that it looks OK.
In my perspective if the values of both the fields needs update regularly and table tblMatch data size is large then you should take it into separate table. if both the fields are updates whenever whole record is change then it could be in tblMatch table.
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 table that will hold 'game stats'. The name of the stats that are held are going to be changing depending on which sport the stats are for.
Is best practice to make two tables: one for the stats with columns such as 'Stat1, Stat2' etc. and another one holding the titles with the sportID as a key. Or would the best practise to have several tables for resorts for each sport. Or any other way?
Thanks,
I agree with andy. A generic-titled column like Stat1 - where the purpose is unspecified in the column name, is used polymorphically, or the column type must be made more generic - usually indicates a poor SQL/RA design.
Consider if this were encountered: create table people (field1 varchar(20), field2 varchar(20)). Yeah - not going to fly in my database. Give the columns (and tables) names that mean something in relation to purpose.
Instead, each different type of information collected should have it's own entity (read: table) or group of related entities. In this case I would imagine that each sport represents a different type of collected stats/information. (Even Win/Loss information can vary by sport.)
Trying to "label" columns based on an additional table is a half-way attempt of an Entity-Attribute-Value (EAV) model. While an EAV can be useful it comes with a lot of downsides in SQL and should not be used except after very careful consideration for a specific use-case. (I do not believe that EAV fits this scenario appropriately.)
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 9 years ago.
Improve this question
I'm using MYSQL to store data about user orders. Using PayPal, some orders have only a transaction ID, and others have only a profile ID. Is it poor database design to have separate fields for txn_id and profile_id, where one or the other is NULL depending on the order?
No, that is not poor design at all.
You have a situation where one or the other is NULL depending on the context. The problem arises when you try to enforce that exactly one is NULL or at least one is not NULL. To do that effectively, you will need to use a trigger to check the values.
If there is always only one id or the other, you might consider having two fields, one is something like id_type and the other is id_value (if they are of the same data type).
This might make querying simpler down the line.
You have two options basically:
Two fields, one for Transaction and one for Profile
One field for both Transaction and Profile and have another field to identify whether is a Transction ID or a Profile ID
I prefer No. 1 (which basically the same as yours) because you maintained the proper naming of the field and not a generic one. And besides you could always use COALESCE() or that kind of function to retrieve the not NULL one if either is NULL.
On that regard it means also that you should have a artificial primary key that would not rely on either Transction ID or Profile ID.