дел

Ок, так доволі непогано було б. Я навіть скоріше зроблю так: перший рівень (області та КИїв, бо він до області прирівнюється), другий (міста обласного підпорядкування, напр. Львів і райнои області, і третій (населений пункт району, або район міста). Тоді буде чітко, і по-порядку.
Але в мене ще таке запитання: яким чином на рівня зв'язків в базі можна зробити так при такій структурі, щоб при виборі Львова з випадаючого списку, в наступному полі можна було вибрати не всі райони, а лише ті, які є у Львові. Тобто зрозуміло, що можна на рівні запитів фільтрувати, але хотілось би гарніше якось

А що буде, коли раптом виявиться, що десь в Україні є районне місто, поділене на райони? -
Ну власне там не буде обов'язково аж так докладно описувати, тобто якщо місто районне, то вже його район не буде потрібний.
Зробив таку схему (те, про що мова, справа внизу):

Адекватно?

Так, я також про Кривий ріг подумав. Ну, але поки так.
Навіщо окремо? Ну так щоб можна було наприклад при додаванні нового працівника був спершу випадаючий список областей, після вибору області генерувався випадаючий список районів тільки цієї області, і так далі.
Яким чином це реалізувати, якщо записувати просто і область. і район, і місто в одному полі в таблиці працівників?

Для них усіх повинні бути окремі поля, тоді можна буде написати SQL з GROUP BY. Думаю, через конструктор запитів його також можна побудувати. Має бути щось типу:

SELECT 
  NasPunkt
FROM 
  oxm_addresses
WHERE 
  Raion = "Криворізький" 
GROUP BY 
  NasPunkt

Можна винести це все в окрему таблицю з адресами.