Форум программистов, компьютерный форум, киберфорум
Наши страницы
MS Access
Войти
Регистрация
Восстановить пароль
 
 
Рейтинг 5.00/6: Рейтинг темы: голосов - 6, средняя оценка - 5.00
AMufu
16 / 16 / 6
Регистрация: 05.09.2012
Сообщений: 223
1

База данных склад

19.04.2017, 23:31. Просмотров 1070. Ответов 21
Метки нет (Все метки)

Уважаемые форумчане!

Помогите пожалуйста советом.
Хочу сделать базу данных Склад.
Нужна работу с накладными на приход от поставщиков, расход клиентам, перемещение между складами, актами на списание и оприходование, вычисление остатков на дату.
В приложеной базе накинул таблицы и связи. Ключевых там два момента - таблица документы (documents), которая содержит просто перечень документов, и таблица ПеремещениеМатериалов (MaterTransfers), где на каждый документ присваивается перемещаемый материал, его количество, а также склад-от, с клад-куда, или контрагент-от, контрагент-кому.

Вот несколько вопросов, по которым прошу совета:
1. Подходящая ли схема выбрана.
2. Какие могут быть проблемы при именно такой организации
3. Чего не учел/пропустил
4. Как лучше организовать схему

Буду благодарен за любые советы.
0
Вложения
Тип файла: rar Warehouse_test.rar (14.0 Кб, 47 просмотров)
Надоела реклама? Зарегистрируйтесь и она исчезнет полностью.
Similar
Эксперт
41792 / 34177 / 6122
Регистрация: 12.04.2006
Сообщений: 57,940
19.04.2017, 23:31
Ответы с готовыми решениями:

База данных Склад
Здравствуйте! У меня тут пару проблем с базой данных склада. Делаю по ней...

База данных Склад
Здравствуйте! Сделал небольшую базу данных и назрела следующая проблема:...

База данных Оптовый склад
Помогите сделать связь ...

База данных склад продуктов питания
Добрый вечер.форумчане. Есть база склад продуктов питания, вот уже защищать...

Система выдачи и приема сотрудникам инструмента (склад инструментов)(аналогия База данных Библиотека)
Здравствуйте,создаю автоматизированную информационную систему "Склад...

21
AMufu
16 / 16 / 6
Регистрация: 05.09.2012
Сообщений: 223
19.04.2017, 23:49  [ТС] 2
Еще вспомнил, что материалам надо-бы добавить цену. Но это детали.
0
Jamaica
309 / 193 / 28
Регистрация: 29.03.2016
Сообщений: 324
20.04.2017, 00:00 3
Stocks, они же не сами по-себе?
Они, вероятно, являются подразделениями Partners.

В таком случае, в Documents, достаточно иметь FK на Stocks, нет?

И FK на Units они зачем и в Materials и в MaterTransfers?

Добавлено через 5 минут
Quantity, если подразумевалось количество
0
AMufu
16 / 16 / 6
Регистрация: 05.09.2012
Сообщений: 223
20.04.2017, 11:32  [ТС] 4
Цитата Сообщение от Jamaica Посмотреть сообщение
Stocks, они же не сами по-себе?
Они, вероятно, являются подразделениями Partners.
В таком случае, в Documents, достаточно иметь FK на Stocks, нет?
Нет. Стокс - внутренние склады предприятия, такие как Главный склад, Склад цеха 1, Склад цеха 2 и тд, то есть подразделентя предприятия. Партнерс - контрагенты, то-есть поставщики и клиенты. Поставщик тоже может быть одновременно и клиетном, потому таблица для них одна.

И FK на Units они зачем и в Materials и в MaterTransfers?
И тут и там, так как основная единица измерения может быть одна, а перемещение осуществлятся в другой. Понятно что нужна дополнительная таблица перевода, но пока определяюсь со схемой в принципе.

Quantity, если подразумевалось количество
Да, с правописанием проблемы ))

Добавлено через 11 часов 11 минут
Ответов совсем мало - или все сделал правильно, или очень не правильно.
Подскажите удачной ли является идея совместить все документы в одной таблице MaterTransfers - приход-расход при перемещении между складами, приход-расход при отправте-получении от партнеров?
0
Jamaica
309 / 193 / 28
Регистрация: 29.03.2016
Сообщений: 324
20.04.2017, 18:08 5
Цитата Сообщение от AMufu Посмотреть сообщение
Стокс - внутренние склады предприятия, такие как Главный склад, Склад цеха 1, Склад цеха 2 и тд, то есть подразделентя предприятия.
А где это описание реализовано в схеме данных?
У вас склады "висят" сами по-себе, и никакого отношения к вашему предприятию не имеют.
Да и о самом вашем предприятии, с ваших слов, никакого описания не имеется.
Где вы собираетесь брать информацию о вашем предприятии для накладных, например.

Цитата Сообщение от AMufu Посмотреть сообщение
..., так как основная единица измерения может быть одна, а перемещение осуществлятся в другой.
Значит нет "основной единицы", в Materials FK не нужен.

Цитата Сообщение от AMufu Посмотреть сообщение
удачной ли является идея совместить все документы в одной таблице MaterTransfers
Да, только ее нужно доработать.

Вы с ТТН-ками сталкивались?
0
AMufu
16 / 16 / 6
Регистрация: 05.09.2012
Сообщений: 223
20.04.2017, 23:11  [ТС] 6
Цитата Сообщение от Jamaica Посмотреть сообщение
А где это описание реализовано в схеме данных?
У вас склады "висят" сами по-себе, и никакого отношения к вашему предприятию не имеют.
Да и о самом вашем предприятии, с ваших слов, никакого описания не имеется.
Где вы собираетесь брать информацию о вашем предприятии для накладных, например.
Относительно информации для накладных - справедливо. Раньше, небыло внешних документов, потому обходился без такой информации. Очевидно логичным будет создать отдельную таблицу Company, с одной единственной записью, которая будет содержать информацию о предприятии. Форма будет ограничивать добавление дополнительных записей в данную таблицу. То-есть данная база будет для ведения учета только по одному предприятию. Все склады (как и другие департаменты, а также и работники) по умолчанию принадлежат данному предриятию и связывать эти таблицы (склады, работники) с таблицей Company не стоит, так?

Значит нет "основной единицы", в Materials FK не нужен.
Задумка такая, что основная единица может быть использована в качестве единицы "по умолчанию" для накладных и для отчетов. И пользователь при оформлении документа на перемещение может ввести только "основную" единицу данного материала или одну из тех единиц, которые указаны в таблице перевода единиц для даного материала. Если ничего не указано - то достутна только "основная единица"

Да, только ее нужно доработать.

Вы с ТТН-ками сталкивались?
В принципе - да, но в учете - нет. А какая там особенность? Это же по сути та же накладная на отгрузку, в которую добавлена третья сторона - перевозчик.
0
Jamaica
309 / 193 / 28
Регистрация: 29.03.2016
Сообщений: 324
20.04.2017, 23:29 7
Цитата Сообщение от AMufu Посмотреть сообщение
Очевидно логичным будет создать отдельную таблицу Company, с одной единственной записью, которая будет содержать информацию о предприятии.
Нет.
Это типичное заблуждение.
С точки зрения БД, описание вашей организации не имеет никакого отличия от описания любой другой организации,
потому никаких отдельных таблиц создавать не требуется.
Цитата Сообщение от AMufu Посмотреть сообщение
Все склады (как и другие департаменты, а также и работники) по умолчанию принадлежат данному предриятию...
В РБД нет понятия "отношения по умолчанию".
Все отношения должны быть описаны явным образом.
Цитата Сообщение от AMufu Посмотреть сообщение
...в которую добавлена третья сторона - перевозчик.
Каким образом вы сможете описать третью/четвертую стороны документа в вашей модели данных?
0
AMufu
16 / 16 / 6
Регистрация: 05.09.2012
Сообщений: 223
21.04.2017, 00:13  [ТС] 8
Цитата Сообщение от Jamaica Посмотреть сообщение
Нет.
Это типичное заблуждение.
С точки зрения БД, описание вашей организации не имеет никакого отличия от описания любой другой организации,
потому никаких отдельных таблиц создавать не требуется.
Спасибо за совет. Тогда добавлю в таблицу партнерс дополнительное поле, которое обозначит, что данная компания - "главная".

Но всё же не пойму какая польза от привязывания складов и департаментов к "главной" компании. Обясните пожалуйста.

Каким образом вы сможете описать третью/четвертую стороны документа в вашей модели данных?
Гм... Тогда наверное придется добавить в таблицу Документс два дополнительных "технических" поля типа ДопСторона1, ДопСторона2
0
mobile
Эксперт MS Access
22924 / 12999 / 2690
Регистрация: 28.04.2012
Сообщений: 14,233
21.04.2017, 00:26 9
Я видел договор в котором было более 20 сопутствующих организаций. Возможно это не имеет отношения к Вашему случаю. Тем не менее, гарантийный выход это создание таблицы ДополнительныеСтороны с полями идДокумент, идОрганизация связанная с документами и организациями как "многие-ко-многим". Будут отражены все действующие лица вне зависимости от их количества
0
Jamaica
309 / 193 / 28
Регистрация: 29.03.2016
Сообщений: 324
21.04.2017, 09:42 10
Цитата Сообщение от AMufu Посмотреть сообщение
Тогда добавлю в таблицу партнерс дополнительное поле, которое обозначит, что данная компания - "главная".
С точки зрения БД описание "главной" компании ничем не отличается от описания других компаний.
Каким образом вы можете "отличить" одну компанию от другой?
По значению ключевого поля.
Если вам очень хочется некоторым образом выделить "главную" компанию от других,
используйте для нее значение ключевого поля, равное 0, например.
Цитата Сообщение от AMufu Посмотреть сообщение
какая польза от привязывания складов и департаментов к "главной" компании
Ее легко будет прочувствовать при масштабных и не очень реорганизациях предприятия.

Добавлено через 2 минуты
Цитата Сообщение от mobile Посмотреть сообщение
создание таблицы ДополнительныеСтороны
Чем "Основные стороны" отличаются от "Дополнительных сторон" с точки зрения документа?
0
mobile
Эксперт MS Access
22924 / 12999 / 2690
Регистрация: 28.04.2012
Сообщений: 14,233
21.04.2017, 09:56 11
Цитата Сообщение от Jamaica Посмотреть сообщение
Чем "Основные стороны" отличаются от "Дополнительных сторон" с точки зрения документа?
Ничем конечно. Если ничем.

Неудачно выразился, признаю. Просто СтороныДокумента
0
Jamaica
309 / 193 / 28
Регистрация: 29.03.2016
Сообщений: 324
21.04.2017, 10:10 12
Стороны документа отличаются их ролью в экшене.
Кто-то в роли Грузополучателя,
кто-то в роли Грузоотправителя,
кто-то в роли Покупателя,
Кто-то в роли Плательщика,
... страхователя..., перевозчика
и т.д. и т.п.

В общем, мозг можно сломать на раз-два.
1
AMufu
16 / 16 / 6
Регистрация: 05.09.2012
Сообщений: 223
21.04.2017, 19:47  [ТС] 13
. Стороны документа отличаются их ролью в экшене.
Кто-то в роли Грузополучателя,
кто-то в роли Грузоотправителя,
В контексте учета тмц отличие в том, что поле отправитель или получатель влияют на остаток на складе (если отправитель илу получатель - один из складов), тогда как перевозчик, страховик итд нет. То есть в таблице материал трансферс указал именно их с целью упрощения вычисления остатка по складу (все записи, где склад получил, минус все записи где склад отдал материал, корректируя количество на коэффициент перевода).
0
Jamaica
309 / 193 / 28
Регистрация: 29.03.2016
Сообщений: 324
21.04.2017, 20:05 14
Цитата Сообщение от AMufu Посмотреть сообщение
корректируя количество на коэффициент
А что нам мешает пользовать данную методу для ролей?
1
AMufu
16 / 16 / 6
Регистрация: 05.09.2012
Сообщений: 223
24.04.2017, 23:49  [ТС] 15
Цитата Сообщение от Jamaica Посмотреть сообщение
А что нам мешает пользовать данную методу для ролей?
Да похоже ничего не мешает. Минусов вроде не вижу (по крайней мере пока )) ).
Пожалуй так и сделаю.
Спасибо большое за советы ))

Добавлено через 1 час 25 минут
Я вот еще о чем подумал - в приложеной схеме для учасников документа должно быть выделено 3 поля по трех таблицах возможных учасником
а) Партнеры
б) Склады
в) Сотрудники (для случаев передачи со склада основных средств, таких как техника, или инструмента, итд)

Нормально ли это. Можно было бы пойти и объединить вообще всех возможных учасников в одной таблице-справочнике "Лиц" и в другой таблице присваивать каждому "Лицу" его статус (партнёр, подразделение, сотрудник).
Но тогда мне кажется меене четкой становится схема таблиц, хотя в таблице учасники 3 поля можна свести к одному.
Как думаете, как будет лучше?
0
AMufu
16 / 16 / 6
Регистрация: 05.09.2012
Сообщений: 223
24.04.2017, 23:52  [ТС] 16
Оновленную схему базы прилагаю
0
Вложения
Тип файла: rar Warehouse_test.rar (17.7 Кб, 26 просмотров)
Jamaica
309 / 193 / 28
Регистрация: 29.03.2016
Сообщений: 324
25.04.2017, 18:44 17
Предлагаю сначала разобрать более простые вопросы по последнему примеру.
1. На скрине я выделил 4 поля.
Street - точнее было бы StreetName
City - точнее было бы CityName
Country - точнее было бы CountryName.
Этими полями вы описываете не улицы, города, страны, а только их имена.
Иными словами - вы описываете некоторое пространство имен (территорий),
имеющих выраженную иерархическую структуру.

2.1. Как в вашем описании Employees можно иметь две записи одного человека,
совмещающего одновременно две должности?
На период отпуска коллеги, например.
2.2. Как определить, работником какой компании является некоторая запись в таблице Employees?
0
Jamaica
309 / 193 / 28
Регистрация: 29.03.2016
Сообщений: 324
25.04.2017, 18:45 18
Скрин:
0
Миниатюры
База данных склад  
AMufu
16 / 16 / 6
Регистрация: 05.09.2012
Сообщений: 223
26.04.2017, 21:03  [ТС] 19
Я так понимаю, Вы подводите к приблизительно такому варианту
0
Миниатюры
База данных склад  
Jamaica
309 / 193 / 28
Регистрация: 29.03.2016
Сообщений: 324
26.04.2017, 21:16 20
Нет.
0
26.04.2017, 21:16
MoreAnswers
Эксперт
37091 / 29110 / 5898
Регистрация: 17.06.2006
Сообщений: 43,301
26.04.2017, 21:16

База данных Access "Оптовый склад"
Помогите с базой данных, горит курсач, базу собрал, схему собрал, проблема с...

База данных "Оптовый склад"
ПОМОГИТЕ ПОЖАЛУЙСТА... Задача и моя жуткая проблема : есть таблица - список...

База данных "СКЛАД"
Добрый день! Дело в том, что необходимо создать базу данных типа "склад",...


Искать еще темы с ответами

Или воспользуйтесь поиском по форуму:
20
Ответ Создать тему
Опции темы

КиберФорум - форум программистов, компьютерный форум, программирование
Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2018, vBulletin Solutions, Inc.
Рейтинг@Mail.ru