I'm trying to find the best implementation of class diagram and database structure for football court management. The system have three actors:
Super Admin : manage everything with all privileged (web back-office)
Court Owner : can create a Football Club that may have more than one stadium (web back-office)
Player: who can review a club and book an available stadium (mobile)
My problems are :
Since the three actors have the same properties, I don't need the "extend" relation between "user" and "owner", "player", "admin", but also I can't only have the class "user" because not all users can submit a review and only the owner can add a club... so how to manage the privilege of different users who have the same properties ? and do I need the User group table that can help me to know the group of each user ("owner", "admin", "player") ? (I see that Joomla and Wordpress use a user group table)
The Club can have many stadiums (courts) in the majority of cases they are identical so should In my solution bellow is it correct to have two classes "club" and "stadium" and put the common information (city , latitude, longitude) inside the class "club" ?
Take in consideration that player can book a stadium of a club and the club have another available stadiums that can be booked is my solution bellow correct ?
Please I need your guidance and suggestion of the best implementation for a football clubs management where:
There is three actors ("player", "admin", "club owner")
Each actor have different privileged (only owner can create a club, only player can book and review...)
Avery Club can have many stadiums and player can book one of them or many, and we need to keep track of the availability of other stadiums of the same club.
Here is what I have tried:
Edit link : https://creately.com/diagram/iaqn8ddo/T1IfqHRrhGcHYPihjOwMIQSwM%3D
View Link : http://creately.com/diagram/example/iaqn8ddo/Copy%2Bof%2BTakwira
Does not look too bad.
You already have classes for the actors. So that's done.
The "privileges" can be modeled by assigning the specialized classes the according methods. That is: Owner has a createClub() method and Player has book() etc.
You need a Booking class that keeps track of the bookings made by Player
One observation: the composition from Stadium (you have a typo in the name) to SportsClub does not seem to make sense. A club is not composed of stadiums. In best case it's composed of members. Replace it with an association and use ownedStadium as role.
Related
I am trying to develop a new website for event management system.
I want everyone to sign up as a simple user only and then if they chose to run event user can then create an Organisation and create events.
Every club will have lots of staff members who should then be able to log in and make changes into the event. Like accounting,event set up and entries, Refunds etc.
So I have created few roles like following
clubOwner :- All permission
eventManager :- Tier 1
treasurer :- Tier 2
Now how should I structure staff roles and permission table so that if in future creator of the club leaves that organisation he/she can easily nominate someone else clubOwner.
It is also the case that one eventManager handles events for different clubs or they can also run events under own Organisation name.
So far I have come up with following structure
clubs
=========
id | clubName | clubOwner
club_staff
id | clubId | accountId | roleId
club_roles
id | name
club_role_permission
id | roleId | permissionId
club_role_permission_details
id| name |
I am not sure if this will solve both of my problem of clubOwner easily nominating other user and same user with different roles in different clubs.
Any suggestion will be appreciated.
Thank you
Though this topic is subjective to many developers, I believe you are in the right track.
Permissions - normally corresponds to smallest unit of actions like View Club Staff, Add Club Staff, Remove Club Staff and so on. Normal club staff can view other staff within their club, but cannot add or remove club members.
Roles - are group of Permissions that are related to each other. ClubManagerRole for example must have all the permissions related to managing the club, while ClubStaffRole can only view members for example.
Users - are your users, that's all.
UserRoles - a junction table which has many-to-many relationship between Users and Roles. In other words, a user can have many roles, and a certain role can be assigned to many users. Just like how there are many Club Managers but maybe some of them can also be Other Managers.
Clubs - are your clubs.
ClubUsers (or staff) - are the users of a club. If a certain user is allowed to be a staff of one club only, one-to-many will be a fit choice. Otherwise, you can go with a junction table again for many-to-many relationship which will allow for users being assigned to many clubs.
The nomenclatures again, are also subjective. You can search for Database practices/normalization to get a basic a idea on how one can come up with a good schema.
I am creating a database for universities in my country. Particular database of name of the courses offered by each university.
I think I must consider the following points to create a database
Possible names of courses, let's assume 100 courses.
Name of courses offered by one university, let's assume 60.
Number of courses offered by university may differ from one university to another. One may offer 60 courses and other may offer just 50. Courses may overlap.
How do I create a relational database between table of point no.1 and table of point no.2, considering the point no.3. Please suggest a design pattern for this.
Normally, you would have a table listing all the available courses (in all universities) and another table including the university and the course (one record for each combination) using the ID of the course from the first table. This, of course, is just a very basic description. You may also wish to have a table for universities, course instances (meaning, the same course may run several times during the year, even overlapping within the same university to cope with high number of students), etc.
You could have:
university_course, which is a type of course at a university
a course_category that broadly collects each type of course together
Many course rows, which give the names of a course within a category.
So:
university_course.university_id -> university.id (a university has many university courses)
university_course.category_id -> category.id (a university course has one category)
course.category_id -> category.id (a category has many courses)
Thus, the set of courses (Computer Science, Networking, Computer Studies, Computer Hardware) can map to a category (Computer Science) and then each university course points to the category.
Current diagram:
Explanation:
Activity - Table with all activities, as: jogging, swimming...
Person: All persons clients, trainers etc.
People can take part in many activities and activities can have many members.
I want also include person(type: Trainer), who leads activity. Person can lead many activities, but activity can has only one trainer.
How include my relation in diagram. Maybe new arrow between Activity and Person?
Adding a new association will serve your purpose best. You might name the opposite of the +trainer as +courseLead to tell that its a course led by the trainer.
I used PersonActivity (corresponds to you ActivityReservation) as an association class.
Consider the following tables: Season, Club, Team and Player
A team belongs to a club and has players, but each season the teams of a club and there players can change. I want to be able to follow all changes to the clubs/teams/players per season.
For the moment I create relationship tables like this:
season_club (season_id, club_id)
season_team_player (season_id, team_id, player_id)
A Team directly belongs to a club (has a foreign key column for this).
Is this the best way to go about this or is it better to create a new club for each season and store the season directly in club? I am trying like this because the club data doesn't change between season's and I want to track a club's changes of teams/players and also track the individual players their team changes.
I hope my question is somewhat clear...
Thanks in advance!
For the moment I create relationship tables like this:
season_club (season_id, club_id)
season_team_player (season_id, team_id, player_id)
A Team directly belongs to a club (has a foreign key column for this).
The second of these tables makes a lot of sense to me: together with your four main tables, this should provide all the information you require: you know which players played in which team in which season. And you can even see which teames had any players at all in a given season, from that conclude which teams existed in that season, and from the key on the club conclude which clubs where active in that season. So I don't see any need for the first table, unless your second table is incomplete, i.e. there were clubs for which you don't have data on existing teams, or for which you don't know the individual players.
In terms of performance, more redundancy might be desirable, but in terms of elegance, the above scheme, together with a bunch of nice views, should serve your needs just well.
Is this the best way to go about this or is it better to create a new club for each season and store the season directly in club?
I'd suggest not to do this unless you want to track changes to the club data itself, e.g. a change in address or whatever. If you can identify the same club in different seasons without having to compare names of clubs, I'd consider this a great advantage.
Can anyone help me to design database/table based on below criteria?
An e-commerce website is required which will allow visitors to browse, search and buy films. The following business logic applies:
Each film can be available in DVD or Blu-ray formats with different stock codes and prices. Additional formats may be added in the future by the website administrator.
Films should have a title, description, year they were released and a “star rating” out of ten stored against them.
Films are associated to none or more actor and actors can be associated to none or more films as some films may be documentaries (with no actors).
Films can be associated to one or more genre (such as action, adventure, Sci-Fi, etc).
The number of genres and actors may change so the website administrator needs to be able to add/edit as many genres and actors as they like over time.
Visitors of the website should be able to find films by browsing by actor or genre. When they do they should be able to see a list of all films that are associated to the actor/genre they have selected.
In order to buy from the website, visitors must register their details to become a user.
Users will have one or more addresses associated to their account. When they log in to the system in future all of their previously entered addresses should be available for them to select for their latest order. They should also be able to add a new address to their account at any time.
When ordering the user will select one or more items from the available films (in a particular format). They will need to select a billing and deliver address from those they have previously entered and pay for their order by credit card.
As the prices of the products can change over time the system should record what the price of each of the items in their order was at the time when they purchased as well as the total price of the entire order.
Tracking of stock levels is not required – all products can be assumed to be in stock all of the time.
If this is homework, or a class project, then you really need to start learning about normalisation. Take a look at the article on wikipedia or this introduction on the MySQL site
If this is a professional project, then you need professional help to design/develop your e-commerce site.
Here is something I could come up with, hopefully it should satisfy all the criteria mentioned in your requirements. I was designed in SQL Server as I do not have MySQL on this machine.
Steps to design the database (entity relationship modeling)
Identify the entities from the requirement. Entities are objects that hold information (usually denote real world entities like person, car, bank, employee, etc.). In your case, the entities identifiable are: Film, Actor, User, Order
Once you have identified the entities in your requirements, get down to the deciding the attributes (or properties) of the entities. The attributes are something that you associate the entity with. For example, one would identity a car by its manufacturer, model, color, engine capacity, etc. In your case, the attributes for the film entity would be Name, Genre, ActorInFilm(s), Format(s), Price
Identify the relationships between the entities. In your case, film has a relationship with actor. The relationship is: One film can have zero or more actors. And, one actor can act in one or more films. Thus film and actor are related.
Identify the cardinality of the relationships. Cardinality can be explained in simple terms as how many instance of the entity participate in the relationship.
For example, a employer can have 1 or more employees. And an employee can be employed by only one employer. In this case, there are 2 entities: Employer and Employee. They share the relationship employ. In your requirement, Film and Actor are the entities sharing the relationship Acts in (Actor(s) acts in Film). So the cardinality in this case will be one to many (Film to Actors)(one Actor can act in many Films) and zero to many (Actors to Films).
Once this part is done, you have your zero normal entity relationship diagram. Then comes the normalization. You can read about it on another post here.
After you have normalized the entity relationships (upto 3rd normal form is usually sufficient), you can implement the database design in the SQL design software (MySQL, etc.)
The best way to do the above steps is to take a sheet of paper and write the entities and attributes in a tabular format and then link them to other entities (to denote relationships).
You can refer any good book on database concepts (including normalization) or just search on google (keywords: database, normalization, database design, entity relationship modeling, etc.). What I have explained above is very brief, you will need to discover the rest of the database concepts yourself.
Entity relationship diagram is often abbreviated as ER diagram.