iliasamodin

Если следовать рекомендация по связи (см. Телефонные коды стран, Телефонный план нумерации), целесообразно хранить полный номер (+добавочный). Полный номер состоит из кода зоны и внутренних номеров, итоговая длина 11 цифр, для отдельной страны (локализованных систем) код зоны от 1 до 3 цифр хранить смысла нет. Итого, под полный номер подходит int8, под локальные может и int4 подходить.
Для добавочных номеров - отдельное поле, тут кто во что горазд.
Номера начинающиеся с нолей, как правило, местные (открытый план нумерации), хранить их нет смысла, т.к. позвонить по ним возможно только находясь в том же регионе.
Корректнее хранить полный номер и, при необходимости, отдельно, правила преобразования полного номера в местные и обязательно ограничения где это работает.
Хранение в int позволяет на уровне БД исключить ошибки ввода без использования regexp на каждый insert/update, более удобно хранить непрерывные диапазоны.
Однако, если не хранить "весь мир", слабо ощутимая выгода от перехода со string на int при хранении справочника номеров.

Скорее всего currentDir не совпадает с проектным.
Что у тебя показывает

import os
os.getcwd()

?

Смысл в том, что при идентифицирующей связи внешний ключ в дочерний сущности также становится частью первичного ключа. В этом и смысл фразы "зависимая сущность" - т.к. внешний ключ есть часть первичного, то сущность просто не может существовать без указания значения внешнего ключа.

Хороший пример - сущность "элемент заказа" (OrderItem). Не может быть элемента заказа без самого заказа. Поэтому идентифицирующая связь из отношения "заказ" (Order) отлично тут подойдет. Если у заказа первичный ключ Id, то первичный ключом OrderItem будет, к примеру, такая пара: (OrderId, Number), где OrderId - внешний ключ в таблицу заказов, добавленный идентифицирующей связью, а Number - номер элемента заказа (строки в чеке, если так понятнее), позволяющий иметь несколько заказанных товаров в одном заказе.

Неидентифицирующая связь, соответственно, НЕ добавляет колонки внешнего ключа в первичный ключ. Соответственно, значение внешнего ключа при неидентифицирующей связи может быть как NULL, так и NOT NULL.