Проектирование базы данных

Привет.

Моя программа должна связать поставщиков материалов со складом моего магазина. Много чего опущу, так как всю бд описывать тут очень долго. Приведу некоторые части, если вдруг будет непонятно, то дополню.

1. Вопрос по связи.
Есть Материалы, есть Склад, есть МатериалыПоЗаказу. МатериалыПоЗаказу в итоге попадут на склад.
Отношения:
1. Материалы: id, name...
2. МатериалыПоЗаказу: id, material_id, count, ...
3. Склад: id, material_po_zakazu_id, count

Связи:
1. Материалы(id) < - >> МатериалыПоЗаказу(material_id)
2. Склад(material_po_zakazu_id) ? - ? МатериалыПоЗаказу(id)

Вопрос: какой вид у 2 связи? По-идее 1:1, потому что одному МатериалыПоЗаказу(id) будет соответствовать одна запись на Складе. Я правильно понимаю?

2. А не лучше ли будет сделать связь Склад < - > Материалы? Одной записи в Материалах будет соответствовать 0..1 запись на Складе. Как будет лучше и вообще прав ли я?

Возможно, если еще появятся вопросы буду писать в эту тему.

0

Если на складе товар неразличим по партиям (дате поступления, сроку хранения) и по месту хранения; на складе не производится пересортица, переоценка, инвентаризация и прочие специфические складские операции, то таблица Склад вообще не нужна. Все необходимые данные можно получить запросом из разности прихода и расхода.

1

К сожалению нет возможности убрать склад =((( придется делать с ним.

0

в комментах:

Сообщение от VladSharikov 1. Вопрос по связи. Есть Материалы, есть Склад, есть МатериалыПоЗаказу. МатериалыПоЗаказу в итоге попадут на склад. Отношения: 1. Материалы: id, name... 2. МатериалыПоЗаказу: id, material_id, count, ... 3. Склад: id, material_po_zakazu_id, count -- почему так? почему не material_id? (т.е. Склад: id, material_id, count) далее понадобится: 4. РазмещениеМатериаловНаХранение: zakaz_id,material_id,count,sklad_id (материалы с одного заказа могут быть размещены на разных складах, в том числе с разбивкой партии материала по разным складам: РазмещениеМатериаловНаХранение.count<Мат ериалыПоЗаказу.count) Связи: 1. Материалы(id) < - >> МатериалыПоЗаказу(material_id) 2. Склад(material_po_zakazu_id) ? - ? МатериалыПоЗаказу(id)-- тогда здесь будет: 2. Склад(id, material_id) < - >> РазмещениеМатериаловНаХранение(sklad_id, material_id) (много - за счет разных заказов) 3. Склад(material_id) <<-> Материалы(id) (много - за счет разных складов) Вопрос: какой вид у 2 связи? По-идее 1:1, потому что одному МатериалыПоЗаказу(id) будет соответствовать одна запись на Складе. Я правильно понимаю? 2. А не лучше ли будет сделать связь Склад < - > Материалы? Одной записи в Материалах будет соответствовать 0..1 запись на Складе. Как будет лучше и вообще прав ли я? Возможно, если еще появятся вопросы буду писать в эту тему.

1

cygapb-007, спасибо за ответ!
у вас уже более заточено под реальную систему. у нас пока тока игрушки =) в моей системе только 1 склад на котором будут храниться уже купленные материалы.
Я подумал еще сегодня с утра и, по-идее, будет правильно организовать связь 1:М.
Склад(material_po_zakazu_id) 1 - М МатериалыПоЗаказу(id)
Например: заказали из каталога материалов (Материалы) некоторые материалы. Таблица Материалы: id, material_id, order_id, count. Допустим мы сделали заказ 1, выбрали материал 1, 10 штук. Сделаем заказ 2, выберем материал 1, 20 штук. На склад после каких-то действий (оплаты и т.п.) поставится материал 1, 10 штук и потом добавится материал 1 еще 20 штук. То есть будет 0..М записей МатериалыПоЗаказу(id) к 0..1 записи Склад(material_id). Правильно? В итоге связь Склад(material_po_zakazu_id) 0..1 - 0..М МатериалыПоЗаказу(id). Правильно?

0

Поясните, пожалуйста:

Сообщение от VladSharikov Материалы: id, name...

С этим вроде все ясно: есть бесконечное хранилище материалов (каталог), из которых формируется заказ, например:

id	name
193	рога
518	копыта
784	ласты

2. МатериалыПоЗаказу: id, material_id, count, ...

вроде бы тоже ясно: формируем заказ, включая в него представленные в каталоге товары в потребном количестве, например:

id	material_id	count
17	193	2
17	518	4

3. Склад: id, material_po_zakazu_id, count

а вот отсюда начинаются вопросы.
1) "в моей системе только 1 склад на котором будут храниться уже купленные материалы" - тогда что такое id?
2) material_po_zakazu_id - это ид заказа? тогда что такое count? общее количество всех материалов в заказе?
3) где в Склад упоминается (и упоминается ли?) material_id ?
попробуйте заполнить, у меня получается только так:

id	material_po_zakazu_id	count
1	17	6

1

Материалы - правильно:

id	name
193	рога
518	копыта
784	ласты

МатериалыПоЗаказу:

id	material_id	order_id	count
1	193	1	50
2	518	1	100
3	193	2	30
4	518	3	50
5	784	3	120

Склад:

id	material_id	count
1	193	80
2	518	150
3	784	120

Связи:
МатериалыПоЗаказу.material_id М - 1 Материалы.id_материала
МатериалыПоЗакзу.material_id М - 1 Склад.material_id - вопрос был по этой связи. я подумал и сделал ее такой. правильно?

Вот. Такое должно получится в итоге. Вопрос по второй связи.

В моем объяснении Склад.material_po_zakazu_id это и есть Склад.material_id для связи с МатериалыПоЗаказу

0

то есть Склад.id - это номер заказа?
Тогда связь Склад(id,material_id) <-> МатериалыПоЗаказу(id,material_id) (0..1 - 1)

(хотя в такой трактовке первоначальная схема базы изменена )

PS и неясно, может ли в одном заказе быть более одной строки

не, вообще не понял... id - это что, номер строки?

0

cygapb-007, Склад.id просто автоинкрементный индекс таблицы Склад. Как и везде. Материалы.id - первичный ключ, автоинкрементый. МатериалыПоЗаказу.id - автоинкрементный индекс.
id это что-то вроде номера строки. первичный ключ. по нему идентифицируем строку.

На складе нету номера заказа. Для склада он не важен, для склада важен id_материала и его количество.

0

в таблице склад необходим уникальный индекс по полю material_id, никакого автоинкремента в ней не нужно!
Тогда связь Склад(material_id)<->Материалы(id) (0..1 - 1)

1

cygapb-007,

Сообщение от cygapb-007 в таблице склад необходим уникальный индекс по полю material_id

так и сделал, но единственное что связь другая. у меня другая связь.
МатериалыПоЗаказу (material_id) М - 1 Склад (material_id) - так сделать можно?

я понимаю, что можно и как вы предложили

Сообщение от cygapb-007 Склад(material_id)<->Материалы(id) (0..1 - 1)

как будет лучше?

0

да, все правильно у вас:
Склад (material_id) < - >> МатериалыПоЗаказу (material_id) (1-M)

1

cygapb-007, да, но можно использовать и ваш вариант. по-моему, это тоже будет правильно. разве нет? или это неправильно со стороны проектирования? как будет правильно? вы же тоже не с потолка взяли свой вариант.

0

там получается цепочка товары-(1-M)->заказы-(M-0..1)->склад
товары->склад - другая цепочка, лишняя в данном контексте

0

попробуйте почитать "An Introduction to Database Systems" C.J.Date

0

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

0

Сообщение от VladSharikov Моя программа должна связать поставщиков материалов со складом моего магазина.

Это очень спорное утверждение. Кому нужна такая программа? Кладовщику или продавцу?

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

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

Я бы на вашем месте лучше бы рассмотрел предметную область. Как организовано хранение материалов на складе. Рассмотрел бы внимательнее бизнес-процессы. Составил бы список действующих лиц, их цели.

Склад(склад как отдельное здание), магазин(как организация), сотрудник, поставщик - это доменные объекты. Их нужно внимательнее искать в предметной области.

Если правильно составить список утверждений для предметной области, то вопросов в проектировании не будет.
Например
Поставщик поставляет магазину от одного и более видов материалов.
В заказ включается от одного и более материалов.
Склад хранит от одного и более видов материалов.

Т к вы описали только малую часть БД то у вас вскоре снова появятся вопросы, и все они будут связаны с недостаточным рассмотрением предметной области.

Сообщение от VladSharikov МатериалыПоЗаказу

и названия приведите к нормальному виду, это либо названия сущностей предметной области на русском, либо названия таблиц на английском

0

XRuZzz, по постановке задачи очень похоже на следующее:
1.Набрать заказов
2.Получить полный список заказанных товаров
3.Найти где закупить
4.Доставить заказанное

0

XRuZzz,
я делаю программу , которая в дальнейшем не будет использоваться каким-то магазином. делаю примерно что-то похожее. в семестре было несколько частей. ил, дл и физическое проектирование. ил и дл уже пройдены и засчитаны, нужно сделать базу данных опираясь на первые 2 шага. их уже не изменишь, хотя может быть было бы неплохо это сделать. делаю не себе, не по моей схеме. нужно придерживаться схемы.

Сообщение от XRuZzz все они будут связаны с недостаточным рассмотрением предметной области.

все они? какие вопросы? это был единственный вопрос. бд уже есть и работает. да она охватывает минимум и наверняка не применима для реального магазина, но она сделана, учитывая ил и дл схему, которые УЖЕ были сделаны.
сделал уже больше половины и вопросов нет.

в любом случае, спасибо, что откликнулись. книгу посмотрю, как появится минутка. спасибо.

Добавлено через 6 часов 52 минуты
cygapb-007, появилась проблема.
при добавлении строк в МатериалыПоЗаказу появляется ошибка:
.
FK_MaterialOrderMaterials_Warehouse - связь между МатериалыПоЗаказу и Склад.

Склад:

id	material_id	count
1	193	80
2	518	150
3	784	120

МатериалыПоЗаказу:

id	material_id	order_id	count
1	193	1	50
2	518	1	100
3	193	2	30
4	518	3	50
5	784	3	120

Материалы:

id	name
193	рога
518	копыта
784	ласты

это просто структура.

В таблице склад - material_id уникальный ключ. Связь: Склад (material_id) 1 - М МатериалыПоЗаказу(material_id).

Проблема при попытке добавить МатериалПоЗаказу.
Подскажите как решить такую проблему.

Добавлено через 11 минут
Я вообще правильно понимаю смысл этих связей?
Склад (material_id) < - >> МатериалыПоЗаказу (material_id) (1-M)

это значит, что на 1 записи в таблице "Склад" соответсвует 1..М записей таблицы "МатериалыПоЗаказу", правильно?

Еще дополню предыдущий пост. После того, как я добавил в Warehouse запись с material_id 1, то код
сработал. то есть он проверял наличие в Warehouse, наверное. так? Получается наоборот. У меня должно быть так: на Склад можно, что то добавить, если это есть в МатериалыПоЗаказу. А у меня наоборот. Как это сделать?

0

Сообщение от VladSharikov Склад: id material_id count 1 193 80 2 518 150 3 784 120 МатериалыПоЗаказу: id material_id order_id count 1 193 1 50 2 518 1 100 3 193 2 30 4 518 3 50 5 784 3 120 Материалы: id name 193 рога 518 копыта 784 ласты

Эээ... Не совсем так. FK может ссылаться только на первичный ключ или на ключ с уникальными значениями.

Материалы - это справочник с первичным ключем ID, для этой таблицы никаких ссылок не требуется, но ссылаться на нее можно (по значениям первичного ключа)

Следующая таблица в цепочке - материалы по заказу, то есть для нее должен быть указан FK(material_id) на материалы(id). Для обеспечения возможности ссылаться на эту таблицу для нее необходимо указать первичный или уникальный ключ. Очевидно, это пара (order_id,material_id). Однако проблема в том, что на складе хранятся итоговые данные по материалам из всех заказов, поэтому связать склад по FK с материалами по заказу не получится.
Один из возможных способов обеспечения ссылочной целостности - использование триггеров на изменение данных в этой таблице, которые будут автоматически корректировать таблицу Склад.

Далее по цепочке склад, у этой таблицы тоже есть уникальный индекс по material_id, но она является подмножеством таблицы материалов. Значит, для нее можно определить FK(material_id) on Материалы(id), а так же ссылаться на нее из МатериалыПоЗаказам (другой способ обеспечения ссылочной целостности).

В материалы можно добавить любую запись о новом материале.
Далее порядок добавления добавления зависит от выбранного способа: с использованием триггеров добавляются данные в таблицу материалов по заказу (при этом триггер автоматически корректирует таблицу Склад).
Либо добавляется запись об отсутстующем материале в Склад, после чего появляется возможность добавить этот материал в список заказанных.

Я вообще правильно понимаю смысл этих связей? Склад (material_id) < - >> МатериалыПоЗаказу (material_id) (1-M) это значит, что на 1 записи в таблице "Склад" соответсвует 1..М записей таблицы "МатериалыПоЗаказу", правильно?

Точнее, одной записи в Склад соответствует несколько (0..M) записей в МатериалыПоЗаказу. Соответственно, первичной таблицей является Склад.

Еще дополню предыдущий пост. После того, как я добавил в Warehouse запись с material_id 1, то код SQL 1 INSERT INTO MaterialOrderMaterials (order_id, material_id, COUNT) VALUES (46, 1, 1) сработал. то есть он проверял наличие в Warehouse, наверное. так? Получается наоборот. У меня должно быть так: на Склад можно, что то добавить, если это есть в МатериалыПоЗаказу. А у меня наоборот. Как это сделать?

Разорвать связь между этими таблицами и задействовать триггеры. В качестве бонуса - отпадет необходимость обсчитывать итоги по Склад (просуммируются в триггере).

Еще один вариант решения - разорвать все связи вообще и делать все изменения данных через хранимые процедуры. Решение менее затратное по ресурсам, но допускающее потерю целостности за счет «ручных» корректировок данных.

1