Форум программистов, компьютерный форум, киберфорум
Базы данных
Войти
Регистрация
Восстановить пароль
 
Рейтинг 4.75/4: Рейтинг темы: голосов - 4, средняя оценка - 4.75
0 / 0 / 1
Регистрация: 22.12.2013
Сообщений: 30
1

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

09.10.2016, 22:51. Показов 795. Ответов 18
Метки нет (Все метки)

Здравствуйте, форумчане. Просьба помочь с проектированием.

Назрели следующие вопросы:

1) Как может выглядеть таблица "Склад", если её нужно связать с таблицей "Поставки" и "Товары"? Одна компания-поставщик по идее должна иметь возможность поставлять несколько типов товаров.
2) Правильно ли я организовал связь "многие ко многим" в таблице "Заказ"? Конечная цель, которую хотелось достичь - чтобы пользователь мог заказать несколько товаров.

Текущую схему прилагаю на скрине.
Замечания по остальным таблицам приветствуются
0

Помощь в написании контрольных, курсовых и дипломных работ здесь.

Миниатюры
Проектирование базы данных  
Programming
Эксперт
94731 / 64177 / 26122
Регистрация: 12.04.2006
Сообщений: 116,782
09.10.2016, 22:51
Ответы с готовыми решениями:

Проектирование базы данных
Здравствуйте, извините что обращаюсь, я просто не знаю как ещё построить связи между таблицами...

Проектирование базы данных
Здравствуйте, извините что обращаюсь, я просто не знаю как ещё построить связи между таблицами...

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

Проектирование базы данных
Уважаемые, вопрос достаточно творческий. Разрабатываю информационную систему, хранит различные...

18
3586 / 3057 / 822
Регистрация: 29.08.2013
Сообщений: 20,396
Записей в блоге: 2
10.10.2016, 09:21 2
а если один товар возят 2 конторы по разным ценам?

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

Добавлено через 4 минуты
по складу не забудьте таблицу остатков
1
Хитрая блондиночка $)
1461 / 976 / 399
Регистрация: 21.12.2015
Сообщений: 3,785
10.10.2016, 09:27 3
Цитата Сообщение от qwertehok Посмотреть сообщение
а если один товар возят 2 конторы по разным ценам?
А как такое может быть?
Цитата Сообщение от qwertehok Посмотреть сообщение
а если в компании поменяются какие-либо данные, а вы захотите распечатать старый документ, то у вас подставятся новые данные
На этот случай ведется база сформированных документов. В любом случае старые уже оформленные документы не могут быть в движении товара, поэтому их просто нет смысла хранить в БД, либо же отсекать такие документы периодами проводок.
Однако все же соглашусь - В таблице компаний стоит добавить два поля: Дата регистрации компании и дата закрытия записи о компании. И если реквизиты обновились - создавать новую запись, а старую закрывать записью даты закрытия.

И еще мне не нравятся таблицы Доставки и заявки.
Я бы их объединила в одну потребительскую корзину. Тогда бы и таблица заказов не нужна была бы.

Добавлено через 41 секунду
Цитата Сообщение от qwertehok Посмотреть сообщение
не забудьте таблицу остатков
А вот это будет ужасный просчет. Остатки ни в коем случае хранить нельзя.
Только вычислять на основании периодов.
1
3586 / 3057 / 822
Регистрация: 29.08.2013
Сообщений: 20,396
Записей в блоге: 2
10.10.2016, 09:33 4
Цитата Сообщение от Hikari Посмотреть сообщение
А как такое может быть?
что значит как?
допустим вы покупаете товар ХХ по 500 штук в неделю, ваш продавец говорит: "извини на этой неделе только 450 - остальные утонули в песках сахары".
ты ищешь нового и покупаешь на 10% дороже

это я к тому что в таблице Поставки должна быть цена или ссылка на прайс поставщика. Соответственно в таблице Товары цены не нужно. Это просто таблица с характеристиками.

Цитата Сообщение от Hikari Посмотреть сообщение
В любом случае старые уже оформленные документы не могут быть в движении товара, поэтому их просто нет смысла хранить в БД
конечно их нет в БД, просто вместо поля ИНН\Телефон и прочее нужен справочник
и когда нам нужно сделать отчет берется дата документа и берутся нужные данные из справочников

Цитата Сообщение от Hikari Посмотреть сообщение
А вот это будет ужасный просчет. Остатки ни в коем случае хранить нельзя.
давайте вы это расскажите кому-то другому
остатки, хотя бы за месяц, должны быть обязательно
и рассчитывать текущие остатки тогда не нужно за весь период существования, а только от последних сохранненых

другое дело что тогда нужно будет запрещать редактирование документов в старых периодах, иначе эти остатки будут некорректны
1
Хитрая блондиночка $)
1461 / 976 / 399
Регистрация: 21.12.2015
Сообщений: 3,785
10.10.2016, 09:47 5
Цитата Сообщение от qwertehok Посмотреть сообщение
ты ищешь нового и покапаешь на 10% дороже
И много складов, которые на такое нарушение пойдут себе в убыток?
Я просто частенько сталкиваюсь с торговыми точками (делаем и сопровождаем для них ПО), и хорошо знаю как склады работают. И впервые слышу чтоб фирма так просто взяла и часть товара переключила с другого поставщика.
Да и ее бухгалтеры от такого повесятся.
Цитата Сообщение от qwertehok Посмотреть сообщение
давайте вы это расскажите кому-то другому
Хорошо, как скажешь. Но ты сам обозначил основную проблему:
Цитата Сообщение от qwertehok Посмотреть сообщение
нужно будет запрещать редактирование документов в старых периодах
Однако это только верхушка айсберга )
Не буду вдаваться в подробности, просто скажу из своего 6-летнего опыта: Остатки хранить в виде живых цифр - злейшее зло для кладовщика. И с тем, как остатки между периодами рвутся, наша техподдержка сталкивается чуть ли не ежемесячно в тех ПО, которые та делают.
1
3586 / 3057 / 822
Регистрация: 29.08.2013
Сообщений: 20,396
Записей в блоге: 2
10.10.2016, 10:02 6
Цитата Сообщение от Hikari Посмотреть сообщение
И много складов, которые на такое нарушение пойдут себе в убыток?
при чем тут склады?
покупатель покупает по той цене что сможет купить.
даже не знаю какой пример привести. их же море

Цитата Сообщение от Hikari Посмотреть сообщение
Но ты сам обозначил основную проблему:
конечно, но на каждую проблему есть бизнес процесс

Цитата Сообщение от Hikari Посмотреть сообщение
Остатки хранить в виде живых цифр - злейшее зло для кладовщика.
инвентаризации?

Цитата Сообщение от Hikari Посмотреть сообщение
И с тем, как остатки между периодами рвутся
у ТС вроде учебное ПО, а мы с вами полезли в дебри ))

про НДС не будем рассказывать ТС?
1
0 / 0 / 1
Регистрация: 22.12.2013
Сообщений: 30
10.10.2016, 10:08  [ТС] 7
Спасибо за советы насчёт потребительской корзины! Но всё же, может вам есть что сказать по тем двум вопросам, которые меня заботят?

p.s. насчёт учебного ПО qwertehok прав) можно отнестись проще к вопросу, однако если в проектировании допущены вопиющие ошибки, то жду ещё замечаний)
0
3586 / 3057 / 822
Регистрация: 29.08.2013
Сообщений: 20,396
Записей в блоге: 2
10.10.2016, 10:12 8
Цитата Сообщение от aalexander Посмотреть сообщение
Но всё же, может вам есть что сказать по тем двум вопросам, которые меня заботят?
вы придумали все таблицы и теперь не можете придумать "Склад"?

что делает склад - хранит
значит:
код_товара
код_поставщика
количество

если у вас планируется хранение по местам, то нужны еще размеры

Цитата Сообщение от aalexander Посмотреть сообщение
2) Правильно ли я организовал связь "многие ко многим" в таблице "Заказ"? Конечная цель, которую хотелось достичь - чтобы пользователь мог заказать несколько товаров.
ну так представьте себе документ "Заказ"
1
0 / 0 / 1
Регистрация: 22.12.2013
Сообщений: 30
10.10.2016, 10:19  [ТС] 9
вы придумали все таблицы и теперь не можете придумать "Склад"?
вчера под вечер уже голова не варила. да и в теории я уже много чего подзабыл, поэтому возникли трудности.

что делает склад - хранит
значит:
код_товара
код_поставщика
количество
я думал о таком варианте, но скорее всего, придётся иметь как минимум парочку складов
0
3586 / 3057 / 822
Регистрация: 29.08.2013
Сообщений: 20,396
Записей в блоге: 2
10.10.2016, 10:23 10
тогда добавьте еще код_группы - что бы товары хранить товары одной группы


ЗЫ не будете же вы хранить рыбу и чай на одном складе
1
0 / 0 / 1
Регистрация: 22.12.2013
Сообщений: 30
10.10.2016, 10:29  [ТС] 11
Товар будет только трёх видов - холодильники, ноутбуки, моб. телефоны. Можно хранить и в одном месте всё, но преподаватель говорил, что нужно иметь несколько складов. тогда опять нужно делать "многие-ко-многим" через 3-ю таблицу?

хотя, думаю, стоит поговорить с ним насчёт одного.
0
3586 / 3057 / 822
Регистрация: 29.08.2013
Сообщений: 20,396
Записей в блоге: 2
10.10.2016, 10:32 12
Цитата Сообщение от aalexander Посмотреть сообщение
нужно иметь несколько складов
тогда при приеме нужно указывать склад куда это будет поступать

а при расходе - указывать откуда. Тут надо учесть что всего может быть 10 холодильников, но на 1 складе 7, а 3 на втором.
тогда при расхода нужно делать 2 документа - по 1 на склад
1
0 / 0 / 1
Регистрация: 22.12.2013
Сообщений: 30
10.10.2016, 10:44  [ТС] 13
чуть позже закину исправленную схему, постараюсь учесть пожелания. может ещё вопросы возникнут)

спасибо всем
0
Хитрая блондиночка $)
1461 / 976 / 399
Регистрация: 21.12.2015
Сообщений: 3,785
10.10.2016, 11:32 14
Цитата Сообщение от qwertehok Посмотреть сообщение
инвентаризации?
Переоценки, пересортицы, возвраты... Много факторов.
Цитата Сообщение от qwertehok Посмотреть сообщение
у ТС вроде учебное ПО, а мы с вами полезли в дебри ))
Так то да, но если топикстартер хочет научиться делать хорошее качественное и востребованное ПО - лучше начинать заранее вникать в смысл проектирования. И изучать область более плотно.
Цитата Сообщение от aalexander Посмотреть сообщение
может вам есть что сказать по тем двум вопросам, которые меня заботят?
Какие именно?
Я уже выразила мнение, что у тебя лишние сушности.
Упразднив их твои два вопроса отпадут сами собой.
Не потребуется делать M:M связь.
Вопрос по поставке товаров тоже отпадет. У каждого товара есть номенклатурный код. Ничего не мешает проводить накладные с разным ассортиментом товара в них.
Главное тут - структуру оптимальнее сотворить.
1
0 / 0 / 1
Регистрация: 22.12.2013
Сообщений: 30
10.10.2016, 14:56  [ТС] 15
Вот что вышло на данный момент. Надеюсь, это не хуже, чем было

Что можете сказать?

1) может показаться странным наличие двух идентичных таблиц "Склад" и "Поставки". Предполагаю так - мы поставляем что-то от кого-то столько-то и, когда запись в таблице "Поставки" появляется, то мы обновляем количество этого товара в таблице "Склад".
2) объединил 2 таблицы в "Потребительскую корзину". Так, чтобы один человек мог купить несколько товаров, это должно выглядеть так примерно (во втором столбике 1 - это код одного и того же покупателя)?

1 1 2 1 10.10.2016 Иванов
2 1 3 1 10.10.2016 Петров

Или я снова намудрил?
0
0 / 0 / 1
Регистрация: 22.12.2013
Сообщений: 30
10.10.2016, 14:58  [ТС] 16
Схема:
0
Миниатюры
Проектирование базы данных  
Хитрая блондиночка $)
1461 / 976 / 399
Регистрация: 21.12.2015
Сообщений: 3,785
10.10.2016, 18:03 17
1) Не очень понимаю почему поставщики не связаны с справочником товаров
2) Сушности "Поставки" и "Склад" можно упразднить, если считать потребительскую корзину единственным местом проводок, а склад как часть поставщика. Все равно склад таковым для торговых точек является. Но это если захочется оптимизации базы. Мы собственно так и делаем.

Т.е.
Сушности: Корзина, Поставщик, Получатель, Ассортимент товаров.
Все остальные кроме пожалуй счетов\договоров как по мне лишние.
Все проводки и движение товара вполне вместит в себя корзина, если (повторюсь) посчитать склады как Получателя.
Группы товаров... Я понимаю для чего тебе это, но как по мне для учебной задачи морочно. Я бы в общем товар не группировала, хотя...
0
0 / 0 / 1
Регистрация: 22.12.2013
Сообщений: 30
10.10.2016, 19:52  [ТС] 18
Цитата Сообщение от Hikari Посмотреть сообщение
Не очень понимаю почему поставщики не связаны с справочником товаров
ну вроде в "Складе" можем смотреть, кто поставил этот товар...

Цитата Сообщение от Hikari Посмотреть сообщение
Сушности "Поставки" и "Склад" можно упразднить, если считать потребительскую корзину единственным местом проводок, а склад как часть поставщика. Все равно склад таковым для торговых точек является.
Если я правильно понял вашу мысль, то так не подойдёт. Тут склад как бы местный, магазинный, а не склад компании-поставщика. Надо будет организовать что-то типа выгрузки на местный склад. Я это планирую сделать просто увеличением количества конкретного товара на "Складе", когда имеем новую поставку этого товара.

Цитата Сообщение от Hikari Посмотреть сообщение
Группы товаров... Я понимаю для чего тебе это, но как по мне для учебной задачи морочно. Я бы в общем товар не группировала, хотя...
ну я это делаю в расчёте потом сделать какой-нибудь отчёт по продажам каждой группы товаров. сколько всего холодильников, сколько ноутов и дибильников было продано.
0
Хитрая блондиночка $)
1461 / 976 / 399
Регистрация: 21.12.2015
Сообщений: 3,785
10.10.2016, 20:18 19
Цитата Сообщение от aalexander Посмотреть сообщение
Тут склад как бы местный, магазинный
Да без разницы. Значит сам магазин выступает складом - еще проще. Нет складской базы, которая раздает магазинам товар. Но все равно твой магазин можно записать в Получатели и без сушности Склада.
Цитата Сообщение от aalexander Посмотреть сообщение
Я это планирую сделать просто увеличением количества конкретного товара на "Складе", когда имеем новую поставку этого товара.
Обычно это делают записью в БД приходно-расходного ордера (он же "Накладная").
Для этого у тебя потребительска корзинка есть. Говорю же - в качестве потребителя может выступать и твой магазин.
Разницы между магазином и покупателем практически нет - и там и там требуется одинаковая фиксация движения товара, только тип накладных различается: У Магазина это расходный ордер, а у покупателя - приходный (он же: Чек за покупку)
Цитата Сообщение от aalexander Посмотреть сообщение
делаю в расчёте потом сделать какой-нибудь отчёт по продажам каждой группы товаров
Логично, но морочно. Например Ноутбук и Холодильник должны быть в разных группах по назначению товара, но в одной по некоторым характеристикам. Например и то и другое - электроприбор. Получается они должны присутствовать в двух группах. Поэтому я и говорю: Это морока. Тут нужно семь раз подумать, а стоит ли навешивать на ПО такие утяжеления? Как часто и важно будет получение группировки товаров? В общем этот тот еще вопрос. Ближе к технологии торговли чем к программированию, и далеко не так просто (это из своей практики говорю).
1
IT_Exp
Эксперт
87844 / 49110 / 22898
Регистрация: 17.06.2006
Сообщений: 92,604
10.10.2016, 20:18

Заказываю контрольные, курсовые, дипломные работы и диссертации здесь.

Проектирование базы данных
Здравствуйте. Учусь проектировать базы данных, мне необходимо спроектировать базу для приложения...

Проектирование базы данных
Всем привет. Портал для сотрудников организации написать хочу. Как и любой проект начинается с...

Проектирование Базы Данных - литература
Подскажите что почитать по проектированию БД. Также использование внешних ключей. Буду очень...

Правильное проектирование базы данных
Здравствуйте, коллеги подскажите. Стоит задача спроектировать базу данных для отдела продаж. ...

Проектирование Базы Данных предприятий
Ребят, всем привет, решил наконец-то приняться за разработку БД для предприятия, в котором работаю....

Правильное проектирование базы данных
Собственно исходя из картинки ..существует таблица "news" и таблица "music". Таблица news может...


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

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

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