Форум программистов, компьютерный форум, киберфорум
Наши страницы

MS Access

Войти
Регистрация
Восстановить пароль
 
 
AMufu
16 / 16 / 3
Регистрация: 05.09.2012
Сообщений: 223
#1

База данных склад - MS Access

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Добавлено через 5 минут
Quantity, если подразумевалось количество
0
AMufu
16 / 16 / 3
Регистрация: 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
213 / 168 / 25
Регистрация: 29.03.2016
Сообщений: 297
20.04.2017, 18:08 #5
Цитата Сообщение от AMufu Посмотреть сообщение
Стокс - внутренние склады предприятия, такие как Главный склад, Склад цеха 1, Склад цеха 2 и тд, то есть подразделентя предприятия.
А где это описание реализовано в схеме данных?
У вас склады "висят" сами по-себе, и никакого отношения к вашему предприятию не имеют.
Да и о самом вашем предприятии, с ваших слов, никакого описания не имеется.
Где вы собираетесь брать информацию о вашем предприятии для накладных, например.

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

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

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

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

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

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

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

Каким образом вы сможете описать третью/четвертую стороны документа в вашей модели данных?
Гм... Тогда наверное придется добавить в таблицу Документс два дополнительных "технических" поля типа ДопСторона1, ДопСторона2
0
mobile
Эксперт MS Access
22441 / 12759 / 2596
Регистрация: 28.04.2012
Сообщений: 13,950
21.04.2017, 00:26 #9
Я видел договор в котором было более 20 сопутствующих организаций. Возможно это не имеет отношения к Вашему случаю. Тем не менее, гарантийный выход это создание таблицы ДополнительныеСтороны с полями идДокумент, идОрганизация связанная с документами и организациями как "многие-ко-многим". Будут отражены все действующие лица вне зависимости от их количества
0
Jamaica
213 / 168 / 25
Регистрация: 29.03.2016
Сообщений: 297
21.04.2017, 09:42 #10
Цитата Сообщение от AMufu Посмотреть сообщение
Тогда добавлю в таблицу партнерс дополнительное поле, которое обозначит, что данная компания - "главная".
С точки зрения БД описание "главной" компании ничем не отличается от описания других компаний.
Каким образом вы можете "отличить" одну компанию от другой?
По значению ключевого поля.
Если вам очень хочется некоторым образом выделить "главную" компанию от других,
используйте для нее значение ключевого поля, равное 0, например.
Цитата Сообщение от AMufu Посмотреть сообщение
какая польза от привязывания складов и департаментов к "главной" компании
Ее легко будет прочувствовать при масштабных и не очень реорганизациях предприятия.

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

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

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

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

Нормально ли это. Можно было бы пойти и объединить вообще всех возможных учасников в одной таблице-справочнике "Лиц" и в другой таблице присваивать каждому "Лицу" его статус (партнёр, подразделение, сотрудник).
Но тогда мне кажется меене четкой становится схема таблиц, хотя в таблице учасники 3 поля можна свести к одному.
Как думаете, как будет лучше?
0
24.04.2017, 23:49
MoreAnswers
Эксперт
37091 / 29110 / 5898
Регистрация: 17.06.2006
Сообщений: 43,301
24.04.2017, 23:49
Привет! Вот еще темы с ответами:

База данных "Склад" - MS Access
Ребята помогите. Нужна бд Склад, может есть у кого? Курсовую нужно через два дня сдавать а база еще не готова. Заранее спасибо!

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

Склад. База товаров, хранящихся на складе - MS Access
Помогите пожалуйста решить задачу, если не трудно! Склад. База товаров, хранящихся на складе: наименование, единица измерения, цена...

Может кто поделиться интересует база склад продуктов - MS Access
Ребятки пожалуйста можете поделиться наработками Предупреждение за дублирование темы


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

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

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