Задание: разработать БД для хранения информации о товарах для реализации системы параметрического поиска .

Пример реализации системы параметрического поиска


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

Выделены следующие типы параметров:

1. Логические (наличие какой-либо функции у товара - есть/нет). Например - наличие фотокамеры в данной модели сотового телефона.
2. Строковые (определённое строковое значение). Например - название фирмы изготовителя. Параметр может принимать только 1 значение.
3. Числовые (определённое числовое значение). Например - цена. Параметр может принимать только 1 значение.
4. Списковые. Параметр может принимать несколько значений. Например - холодильник Indesit может иметь следующие цвета: былый, серый, красный.


В пакете ERWin я создала логическую схему БД (см. рисунок). Нужна грамотная оценка схемы. Описание возможных минусов и недостатков, предложения как сделать лучше.


Аленочка тм

ModelRЦель проекта?

Я же вроде бы написала..
В базе будет храниться вся информация о товарах: группы товаров, товары, характеристики товаров, причём совокупность параметров, по которым можно характеризовать товар может сильно отличаться для разных групп товаров.

В будущем планируется создать систему параметрического поиска (web), которая будет работать с созданной БД и производть собственно ПОИСК информации по запросу пользователя и только по тем параметрам, которые ему нужны..

во первых спасибо за дельные советы и замечания.

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

Модбильные телефоны->Мобильный телефон с идентификатором 1->Цвет->Зелёный, true, 3, -8.12, 25, Красный, false

Это правильно?



Неправильно и такую ситуацию нужно исключить.
Я сделаю это на сервере с помощью специальных процедур.


AlexTheRaven
Списковый тип мне вообще сложно предстаить. Что это? XML? Массив? Таблица в таблице? Объект? Список HTML <ul><li></li></ul>? Пахнет расширением реляционной модели.

Это нужно?



"Списковый тип" - не совсем удачное название. Таким образом я хотела обозвать тип параметра, значение которого будет выбираться из списка возможных вариантов, например из специального справочника.

AlexTheRavenКак сделать лучше? - Лучше для чего?
Поищите темы про EAV, модель Тенцера, расширенную модель Тенцера.

лучше - в смысле правильно с точки зрения проектирования БД под эту задачу...

AlexTheRaven AlexTheRavenи что допустимые значения никак не опредляются
Сам себя поправляю. Допустимые варианты определяются, вижу. Не определяется
1) Сколько значений у каждого из параметров
2) Обязательно ли значение должно выбираться из варианта

1) Сколько значений у каждого параметра зависит от его типа!!!! Тогда мне нужно внести некоторые поправки. Нужно определить следующие типы параметров:

1. Параметр, которые принимает 1 строковое значение
2. Параметр, которые принимает 1 числовое значение (цена)
3. Параметр, который принимает 1 логическое значение (да/нет)
4. Параметр, значение которого выбирается из списка и может быть только одно (бренд, фирма-изготовитель)
5. Параметр, который может принимать несколько значений и значения которого выбираются из списка (возможные цвета модели)

2) Значение не обязательно должно выбираться из списка возможных вариантов!!! например, в случае если параметр - это цена!!! Опять же это зависит от типа параметра.

ModelR

1)Рассмотрите еще возможности:
...
5.Параметр ссылка на товар. (пользователь хочет плеер с конкретным HDD).



Спасибо, обязательно рассмотрю!!

ModelRГруппы товара образуют иерархию.

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

А ещё количество уровней может как увеличиваться, так и уменьшаться.

Как эту иерархию представить на схеме и потом реализовать ? Завести атрибут родитель у сущности <Группа товаров> и поставить рекурсивную связь как на рисунке?

ModelR
2)По целостности, не ясно:
Для чего Тип параметра в ПК Параметр?


Дело в том, что я использую ERWin 4.0 для создания логической схемы БД. В руководстве пользователя к этому программному продукту написано, да и на практике видно, что ПК родительской сущности мигрируют в дочернюю сущность автоматически. И как от этого избавиться я не знаю..
Может быть стоит использовать другой программный продукт??

ModelRПочему Значения не имеет в качестве ПК набор ВК в то время как Параметр группы товара - имеет?


да, что-то со связями у меня туговато, дело в том, что есть такие связи как идентифицирующие и неидентифицирующие, вот что по этому поводу написано в документации:

На ERwin Toolbox есть пять типов связей: идентифицирующая, неидентифицирующая, полный кластер подтипов, неполный кластер подтипов, неопределенная (связь”многие-ко-многим”). Идентифицирующая связь - такая связь, при которой экземпляр дочерней сущности идентифицируется через свою ассоциацию с родительской сущностью. Атрибуты первичного ключа родительской сущности становятся атрибутами первичного ключа дочерней. Неидентифицирующая связь - это такая связь, при которой экземпляр дочерней сущности не идентифицируется через свою ассоциацию с родительсой сущностью. Атрибуты первичного ключа родительской сущности становятся неключевыми атрибутами дочерней.

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

ModelR
Если весь контроль перекладывается на процедурный код, то собственно для чего обсуждать схему? Программно в любую схему можно затолкать почти любую информацию.


Насчёт схемы - неправильно построенная схема, может значительно усложнить код и вообще привести к нежелательным последствиям...

ModelR3)Эстетически - если это сущности, то все их имена д.б. в единственном числе. Если таблицы - все во множественном.

Дело в том, что логическая схема потом будет с помощью ERWin преобразована в физическую, так что думаю, что это не принципиально...

Аленочка тм

Programmer_OrtodoxНарисованная схема в первом посте, работать не будет. В центре всего должна стоять классическая древесная таблица, для идентификации всего и вся. А вот смайлик там просто классный!

почему это она не будет работать? будет и ещё как, просто её нужно до ума довести...

жду ваших примеров "древесной таблицы"...:-))

..и причём тут смайлик?

guest_20040621> Выделены следующие типы параметров:
...
> 4. Списковые.

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

Представляется более осмысленным: параметр - это одна сущность, его тип (строковый, логический, численный) - другая.

На схеме не видно единиц измерений.

Если планируется реально использовать эту структуру для какого-то проекта, то представленное решение хм... imho не тянет даже на промежуточное.

Наиболее важная принципиальная ошибка: однозначность идентификации товара по имени невозможна в принципе. Системы синонимизации на схеме нет.

О каких единицах измерения идёт речь? И что такое система синонимизации?

С помощью советов ModelR доработала логическую схему БД. Какие ещё будут замечания?

Аленочка тм

2 ModelR

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

Аленочка тм

ModelR ModelRСудя по последней диаграмме Вы уже освоились.Оп..., а судя по самой последней - еще есть проблемы. Еще раз посмотрите на Параметр группы товаров и на Значения.... Сформулируйте соответсвующие правила на простом русском языке и проверьте, то ли нарисовано на диагамме. В Значениях ПК пустой намеренно?

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

вот так?



Аленочка тм

"Чёрный поинт" - это обозначение конца связи "один-ко-многим".
"Отсутствие поинта" - начало связи многие-ко-многим
PK - Primary Key (первичный ключ)
FK - Forign Key (внешний ключ, ссылка не первичный ключ другой таблицы)

а вообще для начала почитайте теорию по проектированию БД, про логические и физические модели..

Аленочка тм

тьфу блин..."Отсутствие поинта" - начало связи один-ко-многим


Аленочка тм