Модель данных

[fobass]

Уважаемые разработчики, помогите с Логической моделью БД на тему ”ИС анализа рынка по продаже комп. техники” вот фото Л М данных, я все правильно связал сущности?
есть 4 таблицы
Товар – тут хранится товары на складе
Поставка – хранится данные поставки, поставщика на склад
Поставщик – хранит данные о поставщике
Фирма (продавец) – фирмы которые продают комп. и комп. технику

Цель задачи состоит в том что надо составить БД компьютерных фирм города т.е
(не одного а нескольких фирм) чтоб можно было узнать где что по каким ценам продается.





это дипломмный проект
автору важна любая инфо.

[soleil@mmc]

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

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

теперь по самой схеме:
1) чота мне кажется что по сути ваши "поставщик" и "фирма" - родственны и разбивать их на отдельные таблицы не нужно (просто предусмотреть признак - флаговый - является ли эта контора поставщиком)
и тогда немного связки подправятся

2) про "товар"
- "категорию" можно выделить в отдельный справочник и тогда все названия у всех товаров этой категории будут идентичны, а не каждый забит в разнобой по типу: "системный блок", "Системный блок", "Системный Блок", "системный__блок", "системный___блок__" и т.п. (и это еще мягко сказано)

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

- "наличие" вообще неясно для чего нужно или это остаток от поставки?!

- "стоимость" - если нет учета движухи товара, то имхо незачем хранить ст-ть закупки

- "параметры" - это типа свойства объекта?! - если мудрить, то и эти свойства можно разложить в более сложную схему, в которой для каждой "категории" будет свой набор свойств

3) про выбранные размерности полей
- имхо маловато выставлено для полей в табл. Клиенты: Название, Тел, Адрес и т.п.
- кол-во любое лучше указывать одним и тем же типом
- стоимость smallmoney - не знаю сколько это в разрядах, но имхо лучше закладываться под кризис и инфляцию

[fobass]

Для ясности задачи.
Есть в городе 5 фирм по продаже компьютерных техники. У каждой из них есть БД где хранится такие данные как: товары на складе, инфо о поставщиках, о сотрудниках и.д. где для покупателем доступны только прайс-листы этих фирм.
Мне надо обеднить это данные в оду БД

теперь по самой схеме:
1) чота мне кажется что по сути ваши "поставщик" и "фирма" - родственны и разбивать их на отдельные таблицы не нужно (просто предусмотреть признак - флаговый - является ли эта контора поставщиком)
и тогда немного связки подправятся

можно по подробнее

2) про "товар"
- "категорию" можно выделить в отдельный справочник и тогда все названия у всех товаров этой категории будут идентичны, а не каждый забит в разнобой по типу: "системный блок", "Системный блок", "Системный Блок", "системный__блок", "системный___блок__" и т.п. (и это еще мягко сказано)

Т.е. создать таблицу “Категории” где поля “ID_категория” и “Категория” и свизать с таб. “Товары” поля “ID_категория”.?

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

Согласен, так и сделаю.

- "наличие" вообще неясно для чего нужно или это остаток от поставки?!

Наличие – это наличие товара на складе. (Там я соответствующий тип не могу найти логический).

- "стоимость" - если нет учета движухи товара, то имхо незачем хранить ст-ть закупки

Здесь хранится стоимость закупки товара фирмы от поставщика

- "параметры" - это типа свойства объекта?! - если мудрить, то и эти свойства можно разложить в более сложную схему, в которой для каждой "категории" будет свой набор свойств

Тут хранится такие записи, например

Категория Параметры
оперативные памяти Dimm DDR1 / 512 MB
оперативные памяти Dimm DDR3 / 4 GB
Процессоры Intel Celeron / 2.5 Ghz

3) про выбранные размерности полей
- имхо маловато выставлено для полей в табл. Клиенты: Название, Тел, Адрес и т.п.
- кол-во любое лучше указывать одним и тем же типом
- стоимость smallmoney - не знаю сколько это в разрядах, но имхо лучше закладываться под кризис и инфляцию

Там нет табл. Клиенты





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

[soleil@mmc]

Сообщение от fobass

Для ясности задачи.
Есть в городе 5 фирм по продаже компьютерных техники. У каждой из них есть БД где хранится такие данные как: товары на складе, инфо о поставщиках, о сотрудниках и.д. где для покупателем доступны только прайс-листы этих фирм.
Мне надо обеднить это данные в оду БД

ты уж определись - у тебя учебный проект на разработку новой БД или проект по слиянию нескольких БД в одну?
и тебе нужно слить только прайс-листы или нужно зачем-то городить весь этот огород как на твоей картинке?

Сообщение от fobass

Там нет табл. Клиенты

разберешься по ходу дела когда данные начнут обрезаться