En primer lugar, la empresa DataSports Analytics S.A.S.
se dedica a proveer soluciones
integrales de análisis y consultoría en el ámbito deportivo, orientadas tanto a clubes
profesionales como a organizaciones dedicadas a la gestión de competiciones y academias
formativas. En este contexto, DataSports Analytics S.A.S. ha obtenido el conjunto de
datos “Player Scores” proveniente de la plataforma Kaggle, el cual incluye información
detallada de apariciones de jugadores en partidos ([Link]), competiciones
([Link]), clubes ([Link]), partidos ([Link]) y perfiles de jugadores
([Link]) (Cariboo, s. f.). Debido a la naturaleza relacional y al volumen de la
información—que comprende registros históricos que abarcan múltiples ligas y
temporadas—la empresa ha decidido almacenar y gestionar dichos datos en una base de
datos Oracle, con el fin de garantizar su integridad, escalabilidad y el óptimo rendimiento de
las consultas analíticas.
Asimismo, la utilización de estos datos dentro de DataSports Analytics S.A.S. se orienta a
distintos fines estratégicos. En primer lugar, se emplearán para elaborar indicadores de
rendimiento individual, tales como minutos jugados, goles, asistencias y tarjetas, lo que
permitirá generar reportes periódicos dirigidos a entrenadores y directores deportivos para
la evaluación objetiva del desempeño de cada futbolista. En segundo lugar, mediante la
integración de datos de competiciones y contexto de partidos, se diseñarán modelos de
machine learning que predigan variables de interés, como la probabilidad de transferencia
de un jugador o su valorización de mercado, considerando factores como la dificultad de la
liga, el rol táctico y el rendimiento histórico (Cariboo, s. f.; Davis, 2025). Finalmente, con el
propósito de ofrecer un servicio de valor agregado, la empresa desarrollará tableros de
visualización que permitan comparar el rendimiento de clubes y jugadores a lo largo de
diferentes temporadas, apoyando así la toma de decisiones basadas en evidencias
cuantitativas.
Por lo tanto, la estructura de almacenamiento en Oracle se diseñará de acuerdo con
principios de normalización y buenas prácticas en bases de datos, definiendo claramente
las entidades fundamentales (Competitions, Clubs, Players, Games y Appearances) y las
relaciones que las vinculan a través de claves primarias y foráneas. De esta forma,
DataSports Analytics S.A.S. asegura la consistencia referencial y facilita la realización de
consultas optimizadas para informes tanto estáticos como dinámicos, contribuyendo al
cumplimiento de objetivos comerciales y al fortalecimiento del área de inteligencia deportiva
de sus clientes.
Entidades y Atributos
1. Entidad: PLAYERS
○ PK: player_id
○ Atributos:
■ name
■ full_name
■ display_name
■ first_name
■ last_name
■ height_cm
■ nationality
■ position
■ date_of_birth
■ url
■ current_club_id (FK → CLUBS)
■ current_club_name
■ current_club_age
■ current_club_jersey_number
■ current_club_position
■ current_club_domestic_competition_id
■ market_value_in_eur
■ highest_market_value_in_eur
2. Entidad: CLUBS
○ PK: club_id
○ Atributos:
■ name
■ club_short_name
■ other_names
■ founding_year
■ nationality
■ stadium
■ capacity
■ url
3. Entidad: COMPETITIONS
○ PK: competition_id
○ Atributos:
■ name
■ type
■ country
■ season
4. Entidad: GAMES
○ PK: game_id
○ Atributos:
■ competition_id (FK → COMPETITIONS)
■ season
■ date
■ home_club_id (FK → CLUBS)
■ away_club_id (FK → CLUBS)
■ home_goals
■ away_goals
5. Entidad: CLUB_GAMES
○ PK: club_games_id
○ Atributos:
■ game_id (FK → GAMES)
■ club_id (FK → CLUBS)
■ own_goals
■ opponent_club_id (FK → CLUBS)
■ opponent_goals
■ home (Y/N)
■ club_name
■ opponent_club_name
6. Entidad: GAME_EVENTS
○ PK: event_id
○ Atributos:
■ game_id (FK → GAMES)
■ event_type
■ subtype
■ minute
■ player_id (FK → PLAYERS)
■ player_name
■ club_id (FK → CLUBS)
7. Entidad: GAME_LINEUPS
○ PK: lineup_id
○ Atributos:
■ game_id (FK → GAMES)
■ player_id (FK → PLAYERS)
■ player_name
■ club_id (FK → CLUBS)
■ starting (Y/N)
■ lineup_position
8. Entidad: APPEARANCES
○ PK: appearance_id
○ Atributos:
■ game_id (FK → GAMES)
■ player_id (FK → PLAYERS)
■ player_club_id (FK → CLUBS)
■ player_current_club_id (FK → CLUBS)
■ date
■ player_name
■ competition_id (FK → COMPETITIONS)
■ yellow_cards
■ red_cards
■ goals
■ assists
■ minutes_played
9. Entidad: PLAYER_VALUATIONS
○ PK: valuation_id
○ Atributos:
■ player_id (FK → PLAYERS)
■ date
■ player_name
■ nationality
■ club_id (FK → CLUBS)
■ club_name
■ market_value_in_eur
10.Entidad: TRANSFERS
○ PK: transfer_id
○ Atributos:
■ player_id (FK → PLAYERS)
■ transfer_date
■ transfer_season
■ from_club_id (FK → CLUBS)
■ to_club_id (FK → CLUBS)
■ from_club_name
■ to_club_name
■ transfer_fee
■ market_value_in_eur
■ player_name
Relaciones y Cardinalidades
1. PLAYERS ↔ CLUBS
○ Relación: Un jugador puede pertenecer en un momento determinado a un
solo club (current_club_id).
○ Cardinalidad:
■ CLUBS (1) – PLAYERS (N)
■ Esto implica que un club puede tener muchos jugadores, pero un
jugador solo tiene un club actual.
2. PLAYERS ↔ PLAYER_VALUATIONS
○ Relación: Un jugador puede tener múltiples valoraciones a lo largo del
tiempo.
○ Cardinalidad:
■ PLAYERS (1) – PLAYER_VALUATIONS (N)
■ Así, para cada jugador (player_id), existen varias filas en
PLAYER_VALUATIONS con diferentes fechas de valoración.
3. PLAYERS ↔ TRANSFERS
○ Relación: Un jugador puede ser transferido varias veces en su carrera.
○ Cardinalidad:
■ PLAYERS (1) – TRANSFERS (N)
■ Cada transferencia registra un solo jugador, pero un jugador puede
aparecer en múltiples registros de TRANSFERS.
4. CLUBS ↔ GAMES
○ Relación: Un partido involucra dos clubes (local y visitante).
○ Cardinalidad:
■ CLUBS (1) – GAMES (N) (como home_club_id)
■ CLUBS (1) – GAMES (N) (como away_club_id)
■ Se modela como dos relaciones separadas:
■ CLUBS (1) ↔ GAMES (N) vía home_club_id
■ CLUBS (1) ↔ GAMES (N) vía away_club_id
5. CLUBS ↔ CLUB_GAMES
○ Relación: Cada registro de CLUB_GAMES corresponde a un único club
participando en un único partido.
○ Cardinalidad:
■ CLUBS (1) – CLUB_GAMES (N)
■ GAMES (1) – CLUB_GAMES (N)
■ De esta manera, un club puede participar en muchos registros de
CLUB_GAMES (dado que juega múltiples encuentros), y un partido
(game_id) genera dos registros en CLUB_GAMES (uno para el club
local y otro para el visitante).
6. GAMES ↔ GAME_EVENTS
○ Relación: Cada suceso (evento) está asociado a un único partido.
○ Cardinalidad:
■ GAMES (1) – GAME_EVENTS (N)
■ Un partido puede tener múltiples eventos (goles, tarjetas, cambios),
pero cada evento pertenece a un solo partido.
7. CLUBS ↔ GAME_EVENTS
○ Relación: Cada evento involucrará a un club (el del jugador que generó el
evento o el que anotó el gol/recibió la tarjeta).
○ Cardinalidad:
■ CLUBS (1) – GAME_EVENTS (N)
■ Un club puede asociarse a muchos eventos en distintos partidos y un
evento concreto corresponde a un solo club.
8. PLAYERS ↔ GAME_EVENTS
○ Relación: Un evento puede involucrar a un solo jugador (cuando
corresponde a un gol, tarjeta o sustitución).
○ Cardinalidad:
■ PLAYERS (1) – GAME_EVENTS (N)
■ Un jugador puede tener múltiples eventos en distintos partidos, pero
un evento puntual corresponde a un solo jugador.
9. GAMES ↔ GAME_LINEUPS
○ Relación: Cada alineación inicial está asociada a un único partido.
○ Cardinalidad:
■ GAMES (1) – GAME_LINEUPS (N)
■ Un partido tiene varias filas en GAME_LINEUPS (tantos como
jugadores en la alineación cada club), y cada fila pertenece a un solo
partido.
10.CLUBS ↔ GAME_LINEUPS
○ Relación: Cada registro de alineación corresponde a un club participante en
un determinado partido.
○ Cardinalidad:
■ CLUBS (1) – GAME_LINEUPS (N)
■ Un club puede presentar alineaciones en múltiples partidos.
11.PLAYERS ↔ GAME_LINEUPS
○ Relación: Cada registro de alineación corresponde a un único jugador
convocado en la formación inicial.
○ Cardinalidad:
■ PLAYERS (1) – GAME_LINEUPS (N)
■ Un jugador puede aparecer en varias alineaciones a lo largo de
distintos partidos.
12.GAMES ↔ APPEARANCES
○ Relación: Cada aparición (“appearance”) está asociada a un único partido.
○ Cardinalidad:
■ GAMES (1) – APPEARANCES (N)
■ Un partido puede tener múltiples apariciones (tantos jugadores que
participaron), y cada fila de APPEARANCES pertenece a un solo
partido.
13.PLAYERS ↔ APPEARANCES
○ Relación: Cada aparición corresponde a un único jugador que participó en
un partido.
○ Cardinalidad:
■ PLAYERS (1) – APPEARANCES (N)
■ Un jugador puede tener múltiples apariciones a lo largo de la
temporada y su carrera.
14.CLUBS ↔ APPEARANCES
○ Relación: Cada fila de APPEARANCES registra el club del jugador en ese
partido (player_club_id) y, opcionalmente, el club actual
(player_current_club_id).
○ Cardinalidad:
■ CLUBS (1) – APPEARANCES (N)
■ Un club puede asociarse a muchas apariciones porque tiene múltiples
jugadores participando en distintos partidos.
15.COMPETITIONS ↔ GAMES
○ Relación: Cada partido se disputa en una única competición.
○ Cardinalidad:
■ COMPETITIONS (1) – GAMES (N)
■ Una competición (liga, copa, torneo) alberga muchos partidos.
16.COMPETITIONS ↔ APPEARANCES
○ Relación: Cada aparición se registra dentro de una competición dada.
○ Cardinalidad:
■ COMPETITIONS (1) – APPEARANCES (N)
■ Una competición tiene múltiples apariciones asociadas (por cada
jugador en cada partido).
Diagrama Conceptual (Texto)
A modo de visualización textual, se propone la siguiente descripción de cómo se
interconectan las entidades:
mathematica
CopiarEditar
PLAYERS (1)—< PLAYER_VALUATIONS (N)
|
| (1)—< TRANSFERS (N)
|
+—< GAME_EVENTS (N) >—(1) GAMES (1)—< CLUB_GAMES (N) >—(1)
CLUBS
| \ /
| \ /
| \ /
| >—< GAME_LINEUPS
|
+—< APPEARANCES (N) >—(1) COMPETITIONS (1)
\
\
\
CLUBS (1) (vía player_club_id
o player_current_club_id)
Explicación del diagrama:
● Cada PLAYER puede tener varias valoraciones (PLAYER_VALUATIONS), múltiples
transferencias (TRANSFERS), eventos en partidos (GAME_EVENTS) y apariciones en
encuentros (APPEARANCES).
● Cada GAME_EVENT vincula a un único GAME, un único PLAYER y un único
CLUB.
● Cada GAME_LINEUP asocia a un sólo partido con varios jugadores y clubes.
● Cada APPEARANCE se conecta a un GAME, un PLAYER, un CLUB (tanto de ese
partido como actual), y una COMPETITION.
● Cada GAME involucra una COMPETITION y dos CLUBS (como local y visitante).
● Cada CLUB_GAME descompone explícitamente el resultado de cada club en el
partido (dos filas por partido).
Consideraciones de Integridad y Normalización
Por consiguiente, el modelo ER cumple con la tercera forma normal (3FN), ya que:
1. El modelo evita grupos repetitivos: Cada hecho (evento, aparición, alineación,
transferencia, valoración) se separa en tablas individuales.
2. No existen dependencias parciales: Todas las columnas no clave dependen
únicamente de la clave primaria de su respectiva entidad (Elmasri & Navathe, 2021).
3. No hay dependencias transitivas: Por ejemplo, la player_name en
APPEARANCES se repite para facilitar consultas, pero la fuente de verdad es
PLAYERS(name). Esto podría considerarse una denormalización controlada para
optimizar lecturas (Kimball & Ross, 2013).
Conclusión
De este modo, el modelo entidad-relación propuesto describe tanto las entidades
principales (jugadores, clubes, competiciones, partidos) como las tablas transaccionales
(alineaciones, apariciones, eventos, valoraciones y transferencias), junto con las relaciones
que enlazan las claves primarias y foráneas. La definición de cardinalidades garantiza que
las restricciones de participación (obligatoria u opcional) y multiplicitud queden claramente
establecidas, facilitando la implementación en Oracle y asegurando la integridad referencial
en todos los procesos analíticos de DataSports Analytics S.A.S..
