Myshka

состоит
по определению БД всегда состоит в одной из НФ

IMHO, полностью нормализованная форма будет содержать всего две таблицы:

stations (id, name);
events (card, event, station_id, sum, timestamp)

где event: ('активация', 'приход', 'расход', 'блокировка', 'возврат', 'списание')
Но здесь есть смысл в частичной денормализации и добавлении поля balance и, если возможны какие-то операции с заблокированной картой, то поля state.

cards
id (INT), status (BOOL), ...
stations
id (INT), name (VARCHAR), ...
operatioons
id (INT), station_id (INT), operation (INT) (+1/-1, etc), balance (INT), created (INT)...

station - станция на которой последний раз ею пользовались

time - время последнего использования

SELECT FROM `operatioons` WHERE `station_id` = {STATION_ID} ORDER_BY created DESC LIMIT 1

Выведет последнюю операцию с картой, отсюда можно взять ID станции и время, когда картой воспользовались (пополнили счет/прошли турникет)

Персона, если не заморачиваться со сменами фамилии, пола и т.п. - по сути одна, а эта персона во времени может приходить, уходить и т.п.

Вот и напрашивается одна табличка с первичным ключом person_id и горой данных типа ФИО и т.п., а вторая слегка упрощенная табличка - этакая история (хронология) событий:
датавремя, персона (person_id), действие (например int или enum)

соответственно если взять первую запись по хронологии для конкретной персоны - увидим когда персона впервые появилась, по действию последней записи персоны - понимаем ее статус

ну и всяческие "сколько в прошлом месяце пришло и сколько ушло" или сколько было френдов 143 дня назад" запросы лепятся в одну строчку... точнее вру, последний получится чуть посложнее

У вас избыточность данных.
id, first_name, last_name,sex,city - почти не будут меняться. Их в одну таблицу friends.
А в других останется только id записи и ссылка personid на friends