#3. Conceptual Model
##3.1. ER Model Diagram
[ER Model Diagram of the Football database]
##3.2. Arguments for the specifications
We've chosen to create a table for each entity, which makes the database better scalable for future changes. We’ve specified the scores table to have a reference on player and team, because if we would have only the player reference in the scores, we could still follow up which team scores, but since we support the use case, that a player can change the team, the player would take his scores to the new team. Therefore the scores table has a reference to the team and the player. We have the mapping table teams_league_season, so we can follow up which team was at which time in which season. So we support the storing of multiple football seasons.
##3.3. Mapping to RDBMS (MySQL database)
The following files are included and can be used to create the schema and then insert some sample records into the database:
##3.3. Proof
The following SQL file demonstrate the DML command used to query the database: Proof of DML command
##3.5. Discussion
Our first solution stored some redundant data, which where twice in the datbase. We could optimize this, by setting the refernces better and creating the views which accumulate e.g. the scores for a team on a matchday.