I want to create a database for my football (soccer) manager/training program:
I want it to store players and managers in the database, they will all have their own username and passwords etc. they should also have a position in which will be listed as an attribute along with their name, password etc.
Each position has different attributes (If possible I would want these to be stored in a separate table i.e. a goalkeeper table, a defender table, a midfielder table and a striker table), for example, a defender would have jockeying, clearing, heading, strength.
I'm using the MySqlite3 in python when creating these databases. I can figure out how to write the code once I know what structure my database (ERD) should be in.
My image shows the relationship between the different members of the team, however, my teacher and I both can't seem to figure out how to structure it
I would only create two entities because they share common attributes. I will merge the manger with player to team member and merge all the positions to position entity. the team_member has a postion_id as a foreign key.
Related
I'm currently working on a project, the admin of the application must be able to add/edit these information.
Class(className)
Teacher(teacherName,teacherInfo,teacherPicture,teacherEmail)
Practice(practiceName,practiceDate,practiceDescription,practiceDocs)
I tried making 3 tables of which the class would be the relational table containing the keys of teacher and practice, but that way I can't add only the subject without teachers and practices or add a Teacher and then afterwards assign him a class, or remove him from a class. So my question is how would I go about doing this or if you could point me to some good read for this problem.
If I understood it right, you have a practices table, a teachers table and a classes table, with relation fields put directly on those tables.
For you to be able to create teachers, classes and practices individually, you must take that relationship fields out and put the relations into separate tables.
So, instead of having, for example, a classes table with a teacher field, have a classes table without any field related to the teacher and another separate table classes_teachers where you'd have a unique identifier for the association, the id of the teacher and the id of the class.
The type of relationship your current schema provides is called a 1 by n relationship.
The kind of relationship you need is a n by n relationship.
I'm trying to design a system for giving users permissions on objects. Currently I have a database schema where there are roles and each role can have a permission on multiple 'securable objects'. Such an object can be a sensor, an other user or whatever new thing we might add later. So I have a table role_permissions that links a role to a user, sensor etc. A user can also have a permission directly, so there would also be a user_permissions table that link a user directly to a user, sensor etc.
Now the field that refers to a securable object can't be a foreign key, because the target objects can be of different types and thus come from different tables.
The problem I'm facing right now is how I can make Hibernate work with this. One-to-many relations won't work here I think because Hibernate can't possibly know in which table to look.
An alternative would be to create a role_user_permissions table, a role_sensor_permissions table, a user_user_permissions talbe, a user_sensor_permissions table, and a new role_other_type_permissions table + user_other_permissions table for every securable type that's in the system. So for every single type that needs to have permissions on it I would need 2 new tables to manage the permissions.
But now the database is cluttered with permissions tables that actually serve the exact same purpose but for different types. However, Hibernate IS happy to take this because through foreign keys it always knows what table to look in and what type the object is.
Does anyone know a best practice to solve this issue?
Thanks in advance,
Stan
I have two type of user in my master table Doctor and Hospital both user has common fields like Name,Address,Contacts etc.
But there are some different fields which is connected by foreign key to this table
Like for Doctor it has
one to one relation with specialization and department table
and for Hospital
has one to one with service and one to many with facilities table
Now my question is What should be the database schema for this type of relation, At present I made separate table for both Doctor and Hospital but the fields like Name,Contact and Adreess repeating in both table.
It sounds like Doctor and Hospital are both subclasses of some superclass, and the fields that repeat in both of them are attributes of that superclass. Do some google searches with either of these two search terms: "Generalization/Specialization" or "Class Table Inheritance". That second term will show you some specific designs for implementing subtypes or subclasses in relational tables.
You might want to ask the question of in the Database Administrators area. There is a tag called "subtypes" over there with one question in it. It's asking the same thing you are, in a different case.
I've been looking through different questions on here and I can't find something that exactly matches my situation.
I am designing a database for multiple types of users. I have one main User table which includes ID, Username, Password, PasswordSalt, AccountType (enum), and LastLoginDate. I need to have multiple types of accounts: Student, Parent, SchoolAdmin, SystemAdmin, Coordinator, and Teacher. I was originally thinking of having a separate table for each of these types of accounts, but I realized that SchoolAdmin, Coordinator, SystemAdmin, and Teacher all share the exact same data. These account types all have different permissions though. The Student and Parent accounts have extra information that they have to store.
I then thought about adding the information that the 4 identical tables share to the User table and then deleting those tables, but I came across another problem. I need to reference different types of accounts in other tables. For example, I had a foreign key for TeacherID in the Club table to show who the club sponsor is. If I add the information to the User table and get rid of those other tables, then how do I reference a specific account type in another table?
I have never designed a database like this so any help is appreciated.
There are three main ways of implementing inheritance on database models. Please check the links below, and study which is the best one to solve your problem. Nothing better to start analyzing this types of situations to become a good architect.
Single Table Inheritance
Class Table Inheritance
Concrete Table Inheritance
Each of the different approaches have their pros and cons so choose wisely.
Here is a question from a newbie. I need to store music data(URL, artist ...) for each user. Should I put all data in one single table with distinct keys for each user. Or maybe it is good idea to have separate tables for each user.
I am making an online player.
Thanks in advance
You will create huge database if you are going to create seprate table for each user, make a table structure that will contain entries of all user in single table....
Create a single table with different user privileges for ex create an
group column table and provide different grouids to different users
e.g. groupid =1 for admin ,2 for normal user etc.
A separate table for each user is not appropriate.
You need one table for the music data (URL, artist, ...).
If the only item you store about users is the name, you can put that into the music data table as well without violating database design principles too much.
As soon as you store additional information about users (e.g. password, e-mail address) you need a second table for the user data and connect the music data to the user data via a foreign key in the music data table (or, in case of a n:m relation, a third table).
If you are looking for further information about database design, keywords are functional dependency and normalization.
Enhanced relationship diagrams may help you in designing your database. It might be worth mapping out your proposed database using these diagrams before you implement them.
This is a good tool to make sure you have a correct database design for you and as previously said below deal with functional dependency and normalization.
This is a good website to help you if you haven't done this before: http://users.csc.calpoly.edu/~jdalbey/205/Lectures/HOWTO-ERD.html