While it is possible to have a single row for Kingsway and a column for each facility it would be a poor design.
Better to have one table to list clubs. A second table holds the superset of all possible facilities across all clubs. A third table shows which facilities each club actually has. It will have a row for each (club, facility) pair e.g. (Kingsway, pool), (Kingsway, bicycles), (Kingsway, sauna) etc. If another club also had the same facilities there would be a further three rows in this table: (Club2, pool), (Club2, bicycles), (Club2, sauna).
How these tables become populated depends on the source of the data and the particular database design chosen. If the data comes from off-line sources, say brochures, there's no alternative but to type it in to each of the three tables. If the source is digital it could be loaded as-is into a disposable staging table. The appropriate parts are then copied to each of the three data tables. Finally the staging table can be dropped.
The final design could deploy either natural keys or surrogate keys. Using natural keys the third, linking table will appear exactly as shown above. The actual string "Kingsway" and the actual string "pool" will be in the linking table. Using surrogate keys the club and facility tables must be loaded first to creating the pairings between values in columns
club_id, and between
facility_id. Then the linking table can be populated with the correct
(club_id, facility_id) pairs. Likely this will need to join the staging table to the club and facility tables.