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.
Related
I have these set of requirement:
For each school, the system needs to keep track of its unique name, address, classification (Value could be Elementary, Middle, or High), and number of students studying in it.
For each School System Employee, we need to keep track of the unique employee number, full name, address, salary, and the school where (s)he works. An individual works only in one school.
For each student, we keep track of the student’s name (at times, we need to refer to student’s first name, middle initial, and last name individually), address (at times, we need to refer to the street address, city, state, and zip code individually), the school (s)he attends, and what grade (s)he is in.
The system sends letters to High School students frequently, and hence, needs to keep track of each High School student along with the year when (s)he enrolled in the High School.
A system-wide list of courses offered is kept. Information about a course consists of its unique number, unique title, and number of credits.
For each school, the information about which courses are taught there is kept.
For each student, we keep a grade report that provides the grade (Value could be A, B, C, D, or F) for the student for a specific course.
The School System owns buses which are identified uniquely by their registration numbers. Some students take them to commute between their home and their school, while others use their personal means to commute. We keep track of which student takes which bus to commute. We also keep track of drivers assigned to buses (a driver is a school system employee who could be assigned to multiple buses, and a bus could have multiple drivers assigned to it – consider this a weekly assignment of buses and drivers).
Here is my attempt at the ER design:
This is my first ER design and i just wanted to know if met all the requirements and if I did it correctly? Any help will be much appreciated! Thanks!
First of all I don't like it to omit columns necessary for forein keys, e.g. a school ID in the employee table. But I don't know enough about ER diagrams to say if that would even be allowed.
The diagram looks fine to me. Some points though:
School names can change. If there is a number system available (such as NCES School ID for USA) I'd make this the PK instead.
Numbers of students must be no column in the school table; the number of students per school is implicitly given by the students related to the school.
I don't like 1:1 relations very much. Student <-> High Schooler is okay, but I'd rather have the enrollment date in the students table.
StudentID alone can't possible the PK for the grades table. It must be StudentID + Course# instead.
The line from student to course is superfluous, because the relation is given by the grades table already (which is a bridge table containing StudentID, Course# and an optional grade).
The course table's PK must not be Course# + Title, because that would mean the same course number would be allowed in combination with different titles. The PK should be the course number alone. As to the relation: I don't know if the same course can be taught at different schools. If so, the relations are correct.
Met. (though I'd break appart address into # StreetAddress, PO Box, city, state zip etc.(assuming US) Though if you want extra credit you could subtype addresses into their own table and simply have the employee, student and school addresses all in one table with a foreign key...
I'd break down Name, address just as habbit always go to
the loweest common denominator: Fname, LName, etc... (for scaling
solutions long term; combining data is easy, breaking it out later
is hard)
Looks good
Doesn't grade define Highschool? a 9th
grader is in highschool right? so why a seperate table?
4.1) now a table which lists what letters were sent to what students might be useful... but they didn't say they needed this so I'd seek clarification on the requirement.
if # is unique title doens't need to be part
of key.
Missing (you need a schoolCourses table)
Missing (I guess could be handled through your grade table though) Id call the table studentcourses and keep grade on the table... then yeah it works.
Associative/Junction table between bus/student and bus/employee
needed
Overall many-to-many need to be resolved as part of modeling. and I agree with Thorsten, I want to see all fields in all tables including the FK's and I've done enough to know the CASE tools allow it.
and while 1-1 relationships look good for 4/5th normal form. they generally are not practical anymore unless the truely represent a separate concept. So I may have a vehicle table for a vehicle database but I may also have a table for car attributes vs motorcycle attributes vs truck vs boat etc... but vehicle is the primary in this case there so little reason to separate out high school I just don't see the long term value of keeping the object separate (but maybe I just lack vision).
You'll learn that in ERD's the cardinality of the relationships between the data is THE MOST IMPORTANT (following datatype/size/scale precsion). Eliminating M-M relationships is a must. and everything really boils down to 1-M or 1-1 when your done.
Not sure what the line between the school/bus implies.... the buses are owned by the whole system... maybe you need a "System" table tie that to the schools and buses to the system. that way if you support multiple school systems you know which buses belong to what system and what schools are in what system...
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.
I go to a lot of sports games, mostly hockey. I have been tracking the games via an excel sheet and even at one point a simple database table. I am trying to build this a little better and eventually create a web interface. But I also want to be able to run various queries.
I don't care about player goals, ice-time, sog or any of those stats - merely just teams playing, score and date with a section for notes. (eg, Hat trick, 500th game for player)
So what I had was:
(id, home_team, home_score, away_team, away_score, jersey = [home,away,alt], date, notes, timestamp)
I have thought of other ways to normalize it but I don't want to over complicate it and trying to query has been a nightmare.
I had a three table design in mind:
Team
(team_id, city, state, nickname)
League
(league_id, league_name, conference, division)
Venue
(venue_id, venue_name, venue_city, venue_state, venue_zip, venue_address, venue_capacity)
Venue table and even league table seem unnecessary for the most part but I was thinking of different types of queries.
Then I would create some views or a games table that would pull in the necessary fields.
Queries I had in mind to execute:
Games attended that the home team won
How many times my team has played whatever team and overall record
Games won/lost wearing alternate jersey, home jersey, away jersey
Venues visited and record when visiting
Games attended where there has been a significant event. (Hat trick, record)
Overall record of games attended in x year, all time.
Playoff game record, preseason game record, regular season record (I was thinking I could notate game type in notes or create a field for type and do (playoff, preseason, regular)
Any advice would be appreciated, its not that I do not know how to build the database, it is that I do not know how to build it right and without stressing over the entire website I want to build from it.
Eventually I would like to expand it to other sporting events (football, baseball, basketball, etc..) but before getting too far ahead of myself I would like to get the hockey one running.
Thanks in advance
Novice relational database design question here. This is a "I feel like I'm doing wrong. What is it?" question. What it boils down to is, how can I avoid unnecessary complexity when designing a relational database. I also realise that this is as much a question about class structure design, seeing as I'm using an ORM and I'm really thinking of these tables as objects.
Background
Lets say I want to record the results of a number of competitive games between an unspecified number of "players". These players all belong to a "leaderboard", so, the leaderboard has multiple players and records multiple results. The "score" for each of the players is recorded at the end of each game and belongs to a single "result" instance (see image). A score is also parented by the player to which it belongs.
edit: An example
Each row in the leaderboard table represents a collection of players who together form a league. For example, all of
the players who belong to a tennis league will have the same
leaderboard_id in the player table.
A row in the results table
represents a match that has taken place between players that belong to
a particular league. So the leaderboard_id associated with our
players is recorded in each result in this league. The results table
doesn't hold the score of each player, rather, I've attempted to
normalise (appologies for potentially inappropriate use of that term)
these into a score table.
Bringing this all together. We have a
league in the Leaderboard table, in which a game has taken places
between two players. These players belong to the league in
question. The two players have just played a match and their scores
are recorded as rows in the score table. These rows are collected
together under a single results_id, refereing to a row in the
results table.
Question
Q1. Does this make sense? Is there anything glaringly obvious that is wrong with this design?
As is, I can easily query the scores a particular player has accumulated over time, look up the players that played in a particular result, etc. However, there are some actions that really feel like they should be simple, but, to me, feel overly complicated.
For instance, if I want to return the most recent results for a particular player (ie not the player's scores, rather the results that contain a score that belongs to our player).
So, hand-wavey Q2. Maybe this is just lack of experience with SQL, but, I shouldn't have to do a JOIN to look up this, should I? But then, what's the alternative? Should I create a one-to-many composition between player and results, so that I can simply look up a player results?
With the current design to find the most recent result for a player I would need to do something like this (python sqlalchemy)
Score.query.join(Result, Player)\
.filter(Player.id ==player_id)\
.order_by(Result.timestamp.desc()).first()
Is this bad?
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.