Собственное мнение:

Вообще без разницы, как организовать структуру. Гораздо важнее - для чего!
А именно: какая функциональность собственно реализуется?! как в нее попадают данные?! и т.д. и т.п.

Допустим, что это состояние склада, тогда не хватает: "какого именно".
Даже если рассматривается абстрактный справочник - как в него вносятся данные.
Варианты:
1) триггерами, скриптами ... - короче только кодом => структура вообще не важна, можно все в одну плоскую таблицу положить. Отчеты можно по ней построить без проблем
2) Пользователь вводит с формы ввода - о нем и нужно думать. Чаще и проще получается, если структура таблиц отражает порядок и специфику работы пользователей

> Товар(ID int, Название varchar(100), Поставщик int, Количество int)
> Количество(ID int, количество int, ЕдиницаИзмерения int)

Данная структура отражает такую технологию работы:
а) пользователь выбирает запись "Количество", получает на экран таблицу с соответствующими ей товарами
б) Добавляет-изменяет-удаляет записи "Товаров"

Э... Что-то как-то не удобно. Много ли записей товаров будет для одного количества???? Думаю, что обычно будет одна запись. Смысл реализовывать такое???

Скорее всего здесь предлагается так:
Одна таблица на экране - со списком товаров, для каждого есть поле, в котором показано (и может быть изменено) "количество-измерение". В таком случае, в таблице Количество должны быть перечислены все возможные варианты. Кстати, а их много??? Если мало вариантов, то такой вариант возможен, иначе - нет.


Немного логичней было бы:
Товар(ID int, Название varchar(100))
Количество(ID int, Товар int, Поставщик int, количество int, ЕдиницаИзмерения int)

т.е. по товару выдеть - какого поставщика сколько товара какой ед.изм.


ЗЫ. Видел много решений, построенных по 3НФ, логически красивых и правильных c точки зрения БД, но работать в них пользователям было практически невозможно - много лишних ненужных движений приходилось делать, целые таблицы - пустые или содержат по 1 записи.