I am trying to think of the best design for trainers and clients database.
My initial thought was this:
Entity person with common attributes of clients and trainers (name, dob, etc.). A client can have only one trainer. One trainer can have many clients.
I wonder whether creating an entity user for controlling clients and trainers privileges, or just adding an attribute Role in person
Another thing I had considered was having everything in a single entity with a recursive relationship?
Any suggestion?
Thanks.
Trainers and Clients from an entity perspective probably have different data that you care to track about each one. You can still have a global users table, but the trainer and client should have a 1:1 relationship with the user entity. You can then have a join table between clients and trainers. I would suggest a many to many relationship here, just in case someone really wants to get in shape and wants to have 2 trainers.
Can trainers have trainers? For example, a trainer who specializes in triathletes might be a weak swimmer and have a swim coach.
I like the Role design myself.
Related
we are tasked with creating a database which has three entities team, user, course. A course will have multiple students and multiple teams in it. A student and professor can belong to many courses. However, a user with the type of student can only belong to one team in a specific course, but they can belong to other teams in different courses. We are currently trying to figure out how to display this relationship. We are also leaning towards teams being a weak entity which depends on course. So far we have two versions of how we believe the entities and relationships will look like. Would someone be able to tell if we are on the correct track, the weak entity is throwing us off. We also are a bit confused on the cardinality for the ternary relationship.
We only put primary keys in the diagram to simplify it.
A user has the following attributes: name, primary key(userID), userType(either admin, student,teacher), and email.
A course has the following attributes: course name, primary key(course id), start date, and end date.
A team is a weak entity with the following attributes: course id, team number. Primary key(course id, team number).
Thank you to anyone who may be able to help.
IMO, the course table should not have both team and user linked to it, only team should be linked to it, to specify what course is the team for. My ERD diagram would look something similar to this :
Team_member is an associative entity used to solve the many-to-many relationship between team and user, since each user can belong to many teams, and each team can have many members, so it should have a composite key made up of user_id and team_id, to record each member within a team, and team should have a foreign key of course_id to specify its course.
From my understanding, cakephp doesn't support database inheritance relationship. However, I want to create a database with different type of Users.
In this case, there are three types of Users: Seller, Customer, and Administrator. Every users should have basic User information such as password, username, etc.
However, each types of users will have its own unique set of datas. For example, seller may have inventory_id while customer may have something like delivery_address, etc.
I have been thinking of creating a workaround to this problem without destroying cakephp convention. I was going to create three additional foreign keys, admin_id, seller_id and customer_id, inside User table, which links to other table. However, knowing that this is an IS-A relationship not HAS-A, I would have to make sure that two of the ids are NULL value. Therefore, this workaround seems ugly to me..
Is there any other simpler, better approach?
For this type of database structure I would probably look at adopting an Entity-Attribute-Value model. This would mean your customer may have a delivery_address and your user may have an inventory_id but as far as your relationship in Cake is concerned your both your user and customer would just have an attribute_id ... you can then create another table that stores what type of attributes are available.
It it's simplest form, your user and customer would be attached to an *attribute_lookup* or *attribute_link* table by a hasMany (probably) relationship. That attribute_lookup/link table would be connected by a belongsTo/hasOne relationship to the actual Attribute Type and Attribute Value models.
Providing that you normalise your tables correctly, you can stick well within Cake relationship conventions.
You can read more about EAV here.
I have been thinking about this problem for some time now, and I have eventually got around to build a solution for it. What I came up with is a new ORM that can be used on top of CakePHP.
It sort of works as CakePHP 3.0 with entities that represent an id/model, but it is much more advanced and supports multi table inheritance and single table inheritance.
Check it out: https://github.com/erobwen/Cream
I would like to make a model agency based on codeigniter, but im a but stuck with the database, exactly the registration part.
I would like to allow users to sign up as, model, photohgrapher, agency, or make-up artist.
So could someoone give me an opinion how to make the database? Like seperate the models, photographers, agencies, and artists in diferent tables, and at the registration form only ask for baseic info? like name, password, email, D.O.B., or there is a nother way?.
Thank you
You should use entity sub-typing with a parent type of "USER", which will contain your basic information, and with sub-types of "MODEL", "AGENCY", "PHOTOGRAPHER", "MAKEUP_ARTIST". This will allow you to have a better user experience for the inevitable case where there is overlap. I'm sure there are photographers who have agencies and agencies that do make-up etc. It would be much better for these types of users to have a single user ID and password despite having different types of profiles.
Make a drop down for different type of people signing up which the data for drop down comes from a separate table (e.g. person_type) from database and save the basic details of the person in separate table with the ID of the person_type table.
You can make a model for getting, inserting and updating records for this purpose.
Just a homework question I am trying to figure out, I would appreciate some assistance.
Apparently, there are three problems with the design of this database design:
Account = {AccNumber, Type, Balance}
Customer = {CustID, FirstName, LastName, Address, AccNumber}
The one that is pretty obvious is that 'CustID' is useless if 'AccNumber' exists.
I am not quite sure about the second and third problem.
Is there a problem with a separate attribute for 'FirstName' and "LastName', cant we just use 'Name'?
And another option, if 'AccNumber' is the primary key (assuming CustID will be removed), it probably should be place in the beginning :
Such as:
Customer = {AccNumber, Name, Address}
Any input would be appreciated!
Thanks
The customer-account relationship, at first glance, appears to be a many-many relationship, which necessitates the use of an intermediary relationship table. For instance, I have three accounts of my own at my bank. In addition, my wife has two of her own. Finally, we have a shared account. The schema above could not well handle such relationships.
You could, indeed, just use "Name" - but you may need to know what the first or last names are at some point in the future and such a concatination can be quite problematic to split.
Good luck with your homework...
The problem is that you haven't presented us with what the database should represent in words; as it is now, there's nothing "wrong" with the design, since we don't know what the design is supposed to model.
I certainly wouldn't say that CustID is useless, as it serves as the primary key of the table. What you need to determine is the relationship between customers and accounts. It should be one of the following:
A single customer can be tied to multiple accounts, but a single account can be tied to a single customer
A single customer can be tied to only one account, but an account can be tied to multiple customers.
A single customer can be tied to multiple accounts, and a single account can be tied to multiple customers
Right now, with AccNumber in the Customer table, your design models #2.
How is is designed right now, each customer could only have one bank account.
The many-to-many relationship will be a problem. Instead, you might create a third table that holds the relationships. For example:
Account = {AccNumber, Type, Balance}
Connection = {ConnID, AccNumber, CustID}
Customer = {CustID, FirstName, LastName, Address}
This way, both Account and Customer are parented by Connection (for lack of a better name). You could query all connections with a certain AccNumber and find all the customers using that account, and vice versa.
I have a new circumstances (for me anyway) and wonder what is the best way to do this in EF4.0, (database first). This is a madeup example, but it mimics the logic of what I need to do:
Say you have just two tables PEOPLE and TEAMS, each team has a team leader and a backup team leader. The people table has a single record for each person, with a unique ID, the team record has a unique ID, but also a TeamLeaderID and a BackupTeamLeaderId, which map to the people table.
How do you handle this in EF? If I only had a teamleaderid, I could access it by Team.People.Name, but since I know have two links from teams->people this design will not work.
I can think of lots of kludgy scenarios for this, but what is the proper way to set this up in EF (or alternatively resdesign the underlying tables).
I'm not sure why you are starting with an EF question. Do you have your database schema worked out? If so, present that. If not, then I'd start there.
Your Team table will need a Leader foreign key to the People table. If any person can only be in one team, then you could add a TeamID column to your People table. Each person with TempID set to a particular Team would be a player on that team.