Ну и начинаем представлять все в лицах.

Что заказываем у поставщиков? Товары. Вот тебе еще плюс таблица товаров.
Куда поступают товары? На склады. Вот тебе таблица складов.
У поставщиков может быть несколько складов отгрузки? А еще адрес для предоставления финансовых документов? Вот таблицы адресов поставщиков и типов адресов. Наши склады тоже имеют адреса? Тогда таблицу адресов можно расширить и на наши склады.
За товары будем платить деньги? Вот таблица с прайсами поставщиков. Ах, у поставщиков товары кодируются не так, как в нашей базе данных? Вот таблицы связи кодов поставщиков с нашими кодами. Ах да, мы бы хотели иметь не только текущие прайсы, но и их историческую ретроспективу? И это придется учесть...
Каждый товар всегда приходит с одного и того же склада поставщика? Если да - нам повезло, можно привязать склад поставщика к таблице товаров. Иначе - заводить отдельный механизм. А может, оставить логистику поставщика самому поставщику и выставлять ему общий заказ, а уж он сам пусть решает, с какого склада будет нам грузить товары? Да, но тогда надо учесть, что на один наш заказ может быть много поставок.

Попутно собираем коллекцию атрибутов - какие именно атомарные единицы информации нам потребуются (вот пример с датами: дата отправки заказа, дата получения заказа поставщиком, дата отправки поставщиком груза, дата поступления груза к складу, дата приходования на склад).

Ну и естественно расписываем бизнес-процессы, связанные с заказом товара. Например, так: "мы послали заказ. он пришел к поставщику. поставщик отгрузил товар. товар привезли нам. мы проверяем, что нам привезли и приходуем на склад... а что, если поставщик не может обеспечить нам весь заказ? Мы же не будем удалять необеспеченные строки и не будем менять количество в не полностью обеспеченных? А если мы заказывали зеленый мармелад, а нам вместо него по ошибке отгрузили белый шоколад? А что, если по пути шоколад поломался от тряски, или растаял, или везли долго, и срок годности прошел?"

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

Ну, и так далее ... ;-)))

2 Varan

Конечно, я привожу не универсальную постановку, а пример, как может идти разработка БД "Заказы". Кошмарный сон, который может присниться по завершении конкретного проекта, так сказать.
На описание, действительно, накладывается отпечаток моего личного опыта, что, несомненно, вредно для Студента. ;-)
Конечно (если спрашивает действительно студент, а не только ник у него такой), от учебной разработки нельзя ожидать, чтобы она могла работать в суровых условиях реальной жизни . Но значит ли это, что учебные проекты не должны отражать эту реальную жизнь? По-моему, не значит. По крайней мере, концы с концами должны сходиться и в учебных проектах. Пусть даже этих запроектированных учебных концов будет значительно меньше, чем бывает реальных. ;-)))
Если оглядываться на мои собственные учебные проекты, то я обычно старался, чтобы в каждом из них была, пусть маленькая, изюминка. Новаторская, сумасшедшая, прикольная, фантастическая, просто необычная (с моей колокольни глядючи, конечно ;-)). Которая сама по себе не могла составить проект. Поэтому она помещалась в добротно (ну, или менее добротно, если времени не хватало ;-)) выпеченную булочку - а вот она-то базировалась на самых житейских принципах, даже зачастую передиралась из заботливо подобранной во время производственных практик документации. И, конечно, была крепко привязана к предметной области.