Здесь приведена часть таблиц из БД и часть полей
БД представляет собой Склад-Магазин одежды
Storage-это склад он связан отношением один - ко -многим с StorageInventory(инвентарный остаток по складу)
ShopInventory-инвентарный остаток по магазину
ShopInventory и StorageInventory связаны отношением один-ко-многим с таблицей Products
Один на стороне Products т.к один товар может иметь несколько размеров то размеры хранятся в StorageInventory (что есть на складе) и ShopInventory(что есть в магазине) а само название товара хранится в Products Связаны они соответсвенно по коду продукта
Я не могу связать таблицу движения товара ProductMotions с таблицами StorageInventory и ShopInventory Как она должна быть связана с ними ? Какие поля нужно добавить
Сразу скажу код магазина нигде не используется потомучто магазин только один

Таблица ProductMotions отображает движение товара между складом и магазином и наоборот

Как они должны быть связаны чтоб отражать движение товара между складом и магазином?
Я привел здесь не все поля
Что нужно добавить?

Да не
я схему данных в акцессе быстро сделал
На самом деле БД в SQL Server 2000
Конечно я не делал тут ключевых полей и других таблиц там Поставщиков Заказы клиентов
Я тут привел именно проблемную часть БД

evostr0. Так как в проектировании пока несилен, все написанное ниже мои размышления. Хотелось бы услышать конструктивную критику решения, прошу сильно не пинать, а то только появитесь в форуме Oracle

1. А сущности "склад" и "магазин" сильно отличаются? почему не объединить в одну? Я бы объединил (назовем ее пока "сайт").
BooblikСразу скажу код магазина нигде не используется потомучто магазин только один
2. Вот это зря, имхо, а если бизнес вырастет и откроются еще магазины?
BooblikStorage-это склад он связан отношением один - ко -многим с StorageInventory(инвентарный остаток по складу)
ShopInventory-инвентарный остаток по магазину
ShopInventory и StorageInventory связаны отношением один-ко-многим с таблицей Products
Один на стороне Products т.к один товар может иметь несколько размеров то размеры хранятся в StorageInventory (что есть на складе) и ShopInventory(что есть в магазине) а само название товара хранится в Products Связаны они соответсвенно по коду продукта
3. Я бы ввел дополнительную сущность "продаваемый вариант". Т.е. разные модификации товара (размер, цвет и т.п.) - разные "продаваемые варианты".
BooblikЯ не могу связать таблицу движения товара ProductMotions с таблицами StorageInventory и ShopInventory Как она должна быть связана с ними ? Какие поля нужно добавить
4. Код "сайта", код "продаваемого варианта", тип движения.
Дело в том что если откроются новые магазины то эта программа с БД установится в этом магазине а все реквизиты магазина будут хранится в реестре
Получается идет взаимодействие только со складом
Ведь магазин магазину не перепродает же одежду :) поэтому между ними не будет никаких операций
Т.е кто сидит в магазине им нужно только знать что есть на складах а что есть в другом магазине это им же не нужно поэтому не используется таблица где хранится список магазинов
а склады вот хранятся в таблице потомучто складов может быть несколько

Проще хранить что на складах а что в магазине в разных двух таблицах
Так проще выполнять операции
Поэтому я и не объединил в одну
К тому же с той таблицей где хранится инфа о товаре в магазине будут совершаться некие действия в ходе купли и возврата товара поэтому дабы не затрагивать таблицу складов я и разъединил их в две

BULK INSERT BooblikПроще хранить что на складах а что в магазине в разных двух таблицах
Так проще выполнять операции

ну-ну...
что ну-ну?
критикуйте что не так

evostr BooblikПроще хранить что на складах а что в магазине в разных двух таблицах
Так проще выполнять операции
Поэтому я и не объединил в одну
А чем проще то, если не секрет?
Определять инвентаризационные остатки по магазину и складу
Например в таблице где хранится информация о товаре в магазине будет хранится еще и код заказа сделанный клиентом т.е можно потом узнать об инвентарном остатке на дату заказа
а смешивать все в одной таблице делать идентификатор что на складе что в магазине в одной таблице по моему это немного запутанно получается например при поставке на склад нужно заполнять кучу полей например что товар поставлен на склад а не в магазин обнулять код заказа т.к заказ не был сделан клиентом а это лишь поставка на склад и т.д
А при двух таблицах сразу ясно если поставка на склад то добавляем в таблицу склада если идет выдача в магазин то заполняем в таблице магазина
Конечно нужно будет при этом что то уменшать в таблице склад/магазин но это будет проще чем
все изменять в одной таблице устанавливать кучу идентификаторов А вот таблица ProductMotions
как раз и должна отображать движение товара

Хорошо
кто нить может здесь привести схему данных склад-магазин кто это делал

proposed amendment BooblikХорошо
кто нить может здесь привести схему данных склад-магазин кто это делал

только ленивый еще не делал, вероятно. наверное процентов 90 всех решений именно купи-продайки магазинные. примеры реализации и модели схемы данных есть в и-нете
А можно ссылку
А то в Яндексе сколько пытался идет совсем не то без примеров и схем данных