Only one column type is a clean numeric metric as stored: the raw match-statistic counts and rankings, which are DOUBLE. No column is a true unique ID. Most of the serve and return statistics are stored as text, so the profiler tags them as classifiers even though they behave like metrics. This comes from the column profiles I ran (`inspect_columns` and the `meta.columns` query). I did not look at the actual values in the text-typed stat columns. **Identifiers (keys, not unique IDs)** - There is no single-column ID. Each table is identified by a composite key, and these keys are inferred rather than enforced. - `raw_kaggle`, `return_kaggle` and `serve_kaggle` are keyed on player + date + tournament + round: `Name`, `Date`, `Tournament` (spelled `Tournment` in `serve_kaggle`) and `Rd`. - `players_man_` is keyed on `name`. - `players_tournament_man_` is keyed on `name`, `year` and `tournament`. - `Name` is the main entity label, with about 491 distinct players in `raw_kaggle`. It is descriptive rather than unique per row. - `against` holds the opponent and is a free-text label with about 252k distinct values in `raw_kaggle`. It is messy, with seeds and country codes embedded (e.g. `(1))BenoitPaire[FRA]`), so it is not a clean key. - `_batch_id`, `_source_file`, `_source_system` and `_ingestion_timestamp` are ingestion lineage columns. Each has a single value, so they are not analytical. **Categorical dimensions** - `Surface` has about 4 distinct values. - `Rd` (round) has about 14 distinct values, and `players_tournament_man_.rounds` is the round text there. - `Tournament` / `Tournment` (about 3,963 distinct, so effectively high-cardinality) and `players_tournament_man_.tournament` (about 362 distinct). - `return_kaggle.against` is typed as a classifier. `Score` is a high-cardinality text field (about 10k distinct) and is better treated as a descriptive label. - `serve_kaggle.Bpsvd` and `return_kaggle.BPCnv` are break-point saved and converted. They are stored as text, likely "x/y"-style strings, and are classified as dimensions only because of how they are stored. **Numeric metrics** - Properly typed (DOUBLE) in `raw_kaggle`: - Rankings: `Rk` and `vRk`, which are also present in `return_kaggle` and `serve_kaggle`. - Match counts: `TP` (total points), `SP` (serve points), `1SP`, `2SP`, `Aces`, `DFs` and `vA` (opponent aces). - About 86,793 of the 237,205 rows are null for `TP`, `Aces`, `DFs`, `SP`, `1SP`, `2SP` and `vA`. - Properly typed in the player table: `players_man_.number_of_matches` (BIGINT). - Numeric in meaning but stored as VARCHAR, needing parsing or casting before use: - Return: `TPW`, `RPW`, `vA%`, `v1st%`, `v2nd%` and `DR`. - Serve: `A%`, `1stIn`, `1st%`, `2nd%`, `Df%` and `Dr`. **Dates and times** - `Date` and `Time` exist in all three fact tables but are stored as VARCHAR, not DATE or TIME. The values use a non-standard format such as `1-Apr-2013` and `9‑Sep‑2024`. The second one contains a non-ASCII hyphen, so they need cleaning before parsing. - `players_tournament_man_.year` is a BIGINT covering 2002–2024. - `players_man_.playing_years` is VARCHAR and holds a list of years. **Caveat** The profiler's semantic roles are unreliable for the text-typed stat columns. For example, `TPW` and `RPW` are labelled "classifier" but are really percentage-style metrics.