I need to normalize this database. This is for an application that will be allowing users to sign up for gaming tournaments that will be hosted at actual locations. When you search for a tournament the user can either register for the tournament, sponsor the event, or view the tournament. There will be multiple tournaments such as Fortnite, Apex, and what have you. The games will be on platforms like PS4 , PC, and Xbox one. Multiple players can be in a tournament, and they can be signed up for multiple tournaments at a time, same for viewers and sponsors. Each result should be stored such as wins and losses, and be put into the leaderboards. Please help me normalize this ERD diagram.
To normalize a database you have to make sure of the following rules:
1) Values in each column of a table are atomic.
I'm not sure what do you intend to keep in the wins and losses columns of your tables. But they have to be atomic. The number of wins is ok, but what are the wins is not.
2) No duplicities
I'm not seeing any obvious duplicity so I think this part is Ok.
3) No transitive dependency
In the Tournament Table there are both Teams and Gamer FK. If the gamer can only be in a Tournament if he is on a team, so you have a transitive dependency and should remove the GamerTag of the table. The same goes for the LeaderBoard and Results Table
There are other corrections, like in the Game tables theres an 'attribute name' column. In Team table the TournamentID is not set as FK, and GamerTag is not a FK because is not a PK in the gamer Table. User table has an 'attribute name' also. Among others.
Besides that, I'm not sure that this model will actually do what you want it to do. In general the names of your columns are not mnemonic so I cant be 100% sure of what they are. Like the what is the Leader Fk in Results table.
For a first model it's a good start. I recommend, before you continue to normalize it, revise it with care, write what are the purpose to each column.
Normalization is a nice thing to do with your tables but is not always the best way to store them. So I would also stop to think if it's really necessary to do it.
Related
I am practicing DynamoDB applying STD (single table design) and I am having some troubles to design my scheme.
Given the simple many-to-many relationship "A Club can have N players while a player can play in M clubs".
And supposing the following two AP (access patterns):
Get all the players from a Club.
Get all clubs where a player plays.
The AP 1 can be solved by the following schema:
Pseudo-Query:
GET * WHERE PK = 'CLUB#C1'
However, I am not figuring a good way to solve the AP 2. I could a GSI and have the following new scheme:
But, despite I can get the Clubs IDs, I am not retrieving the Club's information.
I have read AWS's dcumentation the Adjacency list design pattern
But, as far as I understand, it is quite different from my example since it is not querying Invoice's specific information for each bill.
In my case, I do need the Club's specific information shared by all players.
The only way I have figured out to do so (in a single query) is: for each Club-Player relation, store both entities' information.
Considering that both Club and Player have not static data that may change over time, how would I handle updates? Is it expected to do N updates each time an attribute change?
You can't always expect to get all of the data with a single lookup. You want all the clubs that a player plays for, which you can get from your GSI. Then you have 2 choices, wait until a user clicks on a club at fetch that information with a GetItem, or load all the clubs needed beforehand with a BatchGetItem.
Am storing games in a database. Games are between two players: call them player1 and player2. I have a document per game, with keys 'player1' and 'player2' containing the player ids. Obviously a given player could appear in either the player1 or player2 key depending on the draw.
Is there a way to structure my data so that I can efficiently find all games for a given player? I know that a query where player1=playerId OR player2=playerId is not possible in dynamo. Am looking for ideas on how to manage it. I started by creating "linked" documents with playerId as the partition key and date/time of game as the sort key. But this is getting messy!
Maybe my best option is to create two GSIs (on player1 and player2) and do an application level union.
Thanks
If I'm reading your question correctly, your access patterns are
Fetch games for a player
Fetch most recent game for a player (based on comments on an earlier post)
Let's start by modeling the relationship between two players playing a game. I'll call it a Match (naming is hard). You could store the Matches between players like this:
I've made up a few attributes on the Match item to illustrate the concept. I'm using a simple primary key with the format MATCH#[KSUID]. If you're not familiar, a KSUID is a unique identifier that is sortable and has a built-in time component. You can use them like UUIDs, but get the useful side effect of sortability based on time. This feature of KSUIDs will be useful when retrieving the latest Match.
We can create two secondary indexes to model the matches from either players perspective. For example, I'll create a secondary index named Player1Index and give it a GSIPK of the player1 attribute, and the GSISK could be the PK of your main table. Using the example above, your data would look like this
Similarly, the Player2Index would look like this
Notice that the KSUID is part of the sort key in both indexes, which means fetching matches by a player will automatically sort the matches in the order they were created. This would allow for your second access pattern where you fetch the latest match for a given player.
EDIT: If the goal is to get all matches where a given player was player1 or player2, you could create a Match item collection that contains each player as a separate item within the collection. For example:
Then you could create an inverted secondary index, swapping the PK/SK patterns in the index. That would look like this:
In this model, the secondary index would contain all matches for a given player, regardless of their role in the match. You may prefer this solution since you could grab the data in a single query with a single index. Pagination would be easier than the first approach.
Whichever path you take, the goal is to pre-join the data you need so it can be fetched in a single query. Sure, you could use the former pattern and query two indexes, and merge results in your application. Making two queries (versus one) isn't the worst thing in the world, but is way less satisfying than fetching the data all at once!
Situation: In the app we have up to 1000 schools. Every school has students and students are having lessons and are joining events (and more). We need to query quick and often lessons per student, per school per date. We have 2 designs in mind, wondering the best way to proceed.
1 - design with dedicated school node
2 - design with no dedicated school node
Examples of two designs
PRO design 1
- root ref to school user after login. noo need to query on school id's
- no need to mention school id's everywhere
- no need for node lessens per school and events per school
- rules on school level
...
PRO design 2
- more flatten data, as widely advised on the internet
For most NoSQL database structures, flattening and denormalising data is the best method. And that is exactly the case with Firebase too.
When you flatten your data, you get the following advantages :-
You're mostly only downloading the minimum required amount. That leads to efficiency and cost-effectiveness.
Your downloads are much faster - specially compared to the likes of SQL join queries.
Having said that, in your particular case, I think that it really depends on how much the school affects the logged in user.
Suppose that a school is only an attribute for a student, and serves no other purpose, then the second database is the way to go. For example, if the books a student can get are independent of the school she goes to, then the second database style is more suited.
However, if a school categories students into groups that define their interaction with the database, then the first database structure is the way to go. An example of this is that a student can only get a book when its available in the school she goes to.
Regardless of your decision, I would like to commend you on the fact that you have flattened your database quite well in both your structures! And my personal suggestion would be to go with the one that is more convenient to code, read and maintain for you.
There are 3 entities:
vehicle_model
vehicle
extra_options (such as open top, leather seats, etc..)
Vehicle model can have a subset of the extra options.
Vehicle can have a subset of it's model extras.
I've been trying hours to figure out how to represent this as er diagram, but without success. I Thought about ternary relationship ,and although I don't understand it completely I think this isn't the way.
I thought about creating another 2 entities, model_ext & vehicle_ext ,so that vehicle_ext would be connected to model_ext but this isn't a good design.
This is my first er diagram design. I'm really lost (read er-diagram chapter in "Silberschatz, Database System Concepts" three times already) so any idea would be appreciated.
did you try adding a new table say 'vehicle_vehicle_model_extra_options_map'? (you can name this table to any thing short, but for better explanation i use __map as a standard way for defining the map tables.)
note those two null able foreign key columns in this table.
Basically, vehicle has one to many relation to extra_options, and vehicle_model has one to many relation to extra_options table, therefore the new table was added.
updated:
In my OLTP database I have a layout consisting of instructors and students. Each student can be a student of any number of instructors. A student can also sign up for an instructor, but not necessarily book any tuition (lesson).
In a data warehouse, how best would this be modelled? If I create a dimension table for Lessons, Instructors and Students and a fact table for the lessons students have taken then this will work when an instructor wants to see what lessons a student has taken.
However, how will an instructor see how many students are REGISTERED with the instructor but has not yet taken a lesson?
In my OLTP, I have a many to many table (InstructorStudents) that links each student with one more more instructors. In an OLAP database, this isn't appropriate.
What would be the best schema in this case? Would a many to many be appropriate in this instance? I can't store a list of which students are registered to which instructors in the student table, so I feel another dimension table is necessary but cannot work out what should be contained in it.
If a fact represents a transaction, you seem to have two different facts here: Sign ups & Lessons. There are always a lot of ways to go but, perhaps, you need two fact tables. They may have similar dimensionality except the sign-up table will have a Class dimension (class name, instructor name, etc.). The Lessons table will tie to the class dimension but, also, to a Lesson dimension (date, classroom used, etc.).
There are a few other ways to do this but they will be more difficult from a programming & reporting perspective.
You need a many to many dimensional model.
You need a factless fact table. Look at the following resource that refers to an example close to your need
http://www.kimballgroup.com/1996/09/02/factless-fact-tables/