внешний ключ или нулевое значение для связи двух удаленных таблиц

Таблица представляет отношения между значениями. (Некоторые значения идентифицируют сущности.) База данных не может использоваться, пока нам не будет сообщено, что каждая таблица — база или результат запроса — означает: каким отношениям бизнес/приложение удовлетворяют ее строки. (То есть, каков его (характеристический) предикат.) Каковы отношения для ваших таблиц?

Для запроса мы выражаем отношение в терминах базовых отношений, а затем выражаем его таблицу в терминах соответствующих базовых таблиц. Например, объединение возвращает строки, удовлетворяющие одному отношению и другому. Итак, опять же, нам нужно знать взаимосвязь таблиц с точки зрения бизнеса/приложения.

Кардиналы и ограничения – это свойства отношений с учетом возможных ситуаций. Они не нужны для обновления или запроса. Они могут направлять дизайн и используются для целостности.

Когда, говоря о клинике, вы говорите о «ее» поставщиках, вы не говорите того, что имеете в виду. «Имеет», «его», «для», «ссылки», «соответствует» — все ничего не означает — они относятся к связанным объектам, но не говорят, как они связаны с точки зрения бизнеса/приложения. Этот дизайн не содержит явной связи между клиниками и статьями. Если да, то вы ничего не сказали, благодаря чему мы могли бы поставить правильные строки или увидеть строки и узнать о ситуации. Тем не менее, вы могли бы затем вывести строки «клиника-поставщик», где поставщик «для» некоторого товара, который «имеет» данная клиника. Но разве это отношения, которые вы имеете в виду?? Например, если вам нужны пары, в которых клинике разрешено «иметь» поставщика «для» некоторых статей, это новая взаимосвязь/таблица, которая не может быть получена из того, что у вас есть.

создание «нулевой» статьи для каждого поставщика в article_supplier

Эта взаимосвязь/таблица представляет собой определенную комбинацию article_supplier и только что описанной взаимосвязи/таблицы. Но проще иметь только эти два.

создание внешнего ключа в поставщике, который ссылается на соответствующую клинику

Это означало бы, что если поставщик «имеет» более одной клиники, то в новой версии могут быть строки, отличающиеся только всеми остальными столбцами; Теория нормализации говорит, что это хуже, чем исходный дизайн и взаимосвязь/таблица Clinic_supplier. И это означает, что если у поставщика «нет» клиники, вам понадобится что-то вроде обнуляемого FK (внешний ключ).

Так что вам, вероятно, нужна таблица Clinic_Supplier. Но вы должны опубликовать новый вопрос, в котором вы на самом деле говорите, о каких отношениях между бизнесом и приложением вы говорите.

Ваш вопрос и следующее по существу дублируются в том смысле, что основные принципы/понятия, которые очевидно применяются для ответа на них, одинаковы:
Как я могу найти отношения между таблицами, которые связаны между собой?
Необходимо объединить 2 таблицы с их FK в 3-я таблица
Лучшее решение - троичная или двоичная связь

Вам нужно прочитать учебник по информационному моделированию и проектированию баз данных.

В вашем дизайне: Поставщик - это таблица. Статьи — это таблица. Поскольку Поставщик поставляет товары, их взаимосвязь выражается в таблице, которая их связывает. Итак, есть таблица supplier_article.

Клиника стол. Вы упомянули, что клиника использует статьи. По тому же принципу, что и выше, связь между Clinic и Article должна быть выражена в виде таблицы. Это должна быть таблица clinic_article.

Хотя вы не упомянули, вы должны посмотреть на другие возникающие зависимости. Например, клиника выполняет процедуры, а в процедурах используются изделия.

путем создания внешнего ключа в поставщике, который ссылается на соответствующую клинику

Это предполагает, что один поставщик может всегда снабжать только одну клинику. Даже если это так сегодня, это не будет так завтра, потому что вы можете захотеть запланировать несколько клиник в одном и том же месте или с использованием одного и того же приложения или базы данных.