I'm looking for some critical feedback on a relational database design I made for a project.
The database is needed for a 2nd year CS project at my school but we have not yet had any teachings on this subject so help is much appreciated.
The database needs to consist of tables such as shopping lists, Users, wares etc. which needs to be shared and updated between units.
As can be seen in the design every user is related to many shoppinglists and likewise mealplans and both of those are also related to groups. Users must also be related to groups and each row in UserGroup linking table has a role as Users must have a role in their group relations.
Is this a structurally sound design?
Is it inadvisable to have columns besides foreign keys in a linking table?
Thanks for your time and help!
http://imgur.com/ypuTVzW.png Full size picture of design schema
it's looks good.
Q> Is this a structurally sound design?
A> Yes
Q> Is it inadvisable to have columns besides foreign keys in a linking table?
A> It's common to have additional columns
Be careful, don't over-normalize.
Sometimes it's wise to have 1 table with duplicates records, than 10 tables join.
best regards
Related
I have to take an online course on DB design once again since I got a really lazy teacher that I thought had taught us everything and I continue to find out he didn't.
I'm designing a small DB in which two particular tables brought up this question.
I have a table called "Athlete" which stores Athlete info and a second table called "EntryInfo" which stores a guy's objectives, if he was a referral by another athlete.
There is no way an athlete could have more than one of this entry infos, so I thought idAthlete would apply to both "Athlete" and "EntryInfo" but I don´t know if this is correct or not. Now I have these questions:
1) In trying to keep "Athlete" table as clean as possible I didn't include this "EntryInfo" in the "Athlete" table from the beginning but it COULD be in the same table. Is this the best way to handle it? Regarding good practices in DB design should they be in 1 or 2 tables?
2) If it´s better to keep it in two separate tables, can I have idAthlete as PK in Athlete table (identity, incremental) and have it also as a PK in Entry Info only as a FK? or would it be a better practice to have a PK identity incremental idEntryInfo on EntryInfo table with a FK idAthlete?
I know this is such a basic question and I know I should take a course on DB design and normalisation (and I will do).
When you have two tables with the same key it's called vertical partitioning and it's a valid design for various reasons.
However I don't see any reasons in your explanation. I only see your statement keep "Athlete" table as clean as possible, which has a pretty general meaning. If you're going to put different groups of fields into different tables you can categorise that any number of ways
If you had a zillion records and you had performance issues it might be worth considering.
It will be simpler for you if you keep it in one table, then you don't have to fiddle about synchronising keys between the tables
I am having a database where i am having employee id's.
And some how the employee details are having relationship with multiple tables. Now I need to delete all the data from all the tables specific to an employee id.
In a clear way what i want is i need to remove the employee and its associated data from the database.
There are many tables and i can't check all the tables how the employee was associated. Is there any solution for this.
Thanks in advance.
Does your database have foreign keys? Is there documentation (like an E-R diagram and related architecture documentation) for the database that tells you all of the tables that are related to employee?
Without proper documentation, you could guess (based on table and column names), or by going through all application code that accesses the database to try to determine the relationships. Neither of these options are particularly helpful, and may result in missed relationships.
I have a table called Documents which stores filenames, notes etc. about documents. The relevant fields are:
Document_ID - Autonumber
Document_Type_ID - FK to a lookup table Document_Types
Table_Unique_ID
The Table_Unique_ID relates to any of the other IDs used in other tables and we know which table by the relevant Document_Type_ID.
E.g.
Document_Type_ID = 1 relates to the Projects table, so a document record with a Table_Unique_ID of 1357 and Document_Type_ID of 1 means it relates to Project_ID = 1357.
Document_Type_ID = 2 relates to the Sites table, so a document record with Table_Unique_ID of 1357 and Document_Type_ID of 2 means a Site_ID of 1357
and so on.
This allows for great flexibility for what types of documents we hold for various record in any table, Projects, Sites, Contacts etc. rather than creating separate tables (Project_Documents, Site_Documents etc.).
BUT it's been pointed out that data integrity is harder (or impossible) to impose using traditional simple PK/FK relationships, since that 1357 could relate to either Projects or Sites.
Currently data integrity is handled by user interface checks.
The question is, can triggers or stored procedures help when inserting Document records or when deleting the 'other' records (Projects, Contacts etc.)?
If so, I would really appreciate being pointed in the right direction.
What is your primary objective? Data integrity, or flexibility and a clean design? These are conflicting interests. If you absolutely have to enforce integrity without triggers, you'll have to have an uglier design. Compromises always have to be made in database design. You'll get the data-integrity elitists harping about how bad this design is, but at the end of the day is more normalization worth it?
I have to implement a testing platform. My database needs the following tables: Students, Teachers, Admins, Personnel and others. I would like to know if it's more efficient to have the FirstName and LastName in each of these tables, or to have another table, Persons, and each of the other table to be linked to this one with PersonID.
Personally, I like it this way, although trickier to implement, because I think it's cleaner, especially if you look at it from the object-oriented point of view. Would this add an unnecessary overhead to the database?
Don't know if it helps to mention I would like to use SQL Server and ADO.NET Entity Framework.
As you've explicitly mentioned OO and that you're using EntityFramework, perhaps its worth approaching the problem instead from how the framework is intended to work - rather than just building a database structure and then trying to model it?
Entity Framework Code First Inheritance : Table Per Hierarchy and Table Per Type is a nice introduction to the various strategies that you could pick from.
As for the note on adding unnecessary overhead to the database - I wouldn't worry about it just yet. EF is generally about getting a product built more rapidly and as it has to cope with a more general case, doesn't always produce the most efficient SQL. If the performance is a problem after your application is built, working and correct you can revisit and fix up the most inefficient stuff then.
If there is a person overlap between the mentioned tables, then yes, you should separate them out into a Persons table.
If you are only tracking what role each Person has (i.e. Student vs. Teacher etc) then you might consider just having the following three tables: Persons, Roles, and a bridge table PersonRoles.
On the other hand, if each role has it's own unique fields, then you should carry on as you are and leave each of these tables separate with a foreign key of PersonID.
If the attributes (i.e. First Name, Last Name, Gender etc) of these entities (i.e. Students, Teachers, Admins and Personnel) are exactly the same then you could just make a single table for all the entities with PersonType or Role attribute added to distinguish each person's role. However, if the entities has a lot of different attributes then it would be better that you create separate tables otherwise you will have normalization problem.
Yes that is a very bad way of structuring a DB. The DB structure should be designed based on the Normalizations.
Please check the normalization forms.
U should avoid the duplicate data as much as possible, else the queries will become slower.
And the main problem is when u r trying to get data that is associated with more than one or two tables.
In database design what are the feelings of tuple vs referencing table for small pieces of data?
For instance, supposing you are designing a schema involving office management. You want to record what department each employee belongs to, but are otherwise uninterested in any information relating to departments. So do you have department as a string/char/varchar/etc in your EMPLOYEE table, or have it instead be a foreign key, relating a DEPARTMENT table.
If the DEPARTMENT table is recording nothing other than department names, one would normally want to combine this with the EMPLOYEE table. But if this is contained in the EMPLOYEE table you cannot guarantee that some users will call HR "HumanResourses", some may call it "H-R", some may call it "human resources", etc. Having it as a foreign key guarantees that it can be only one thing. Also, if other information is ever to be added about departments, it would be easy if it is in a table of its own.
So what do people think about it? Naturally more tables and referencing is also likely to have a negative impact on performance. My question specifically is asked with Oracle 11g in mind, but I doubt that the type of rdms involved has much bearing on this design consideration.
If you use the related table, then you don't have the performance problem of updating 1,000,000 records because the Personnel Department became the Human Resources department.
You have another option. Create the table and use it as a lookup for data entry. But store the information in the main table.
However, I prefer the option of using the related table for the departments and storing the ID for the department and the employee in a join table that has the ids and start and endates. Over time employees tend to move from one department to another. It is helpful for reporting to be able to tell what department they were in when. You need to consider how the data will be used over time and in reporting when designing this sort of thing. Short-sighted designs are hard to fix later.
Your concern about having too many tables is really unfounded. Databases are designed to have many tables and to use joins. If you index correctly, there will not be preformance implications for most databases. And you know what,I know of realtional database with many many tables that have terrabytes of data that perform just fine.
You only have to worry about the performance impact of this sort of thing if you're dealing with truly massive datasets. For any regular office environment system like this, prefer the normalized schema.