Прайс-листы (банк данных интернет-магазина)

Содержание:

Введение

Прайс-лист- это неотъемлемая часть интернет магазина, на нем представлены все товары и услуги, цены т.д находящиеся на сайте магазина

Прайс-лист-это список цен на все товары и услуги, предоставляемые какой-либо фирмой, организацией и т. п.

Как говорил великий философ: Цена — стоимость плюс разумное вознаграждение за угрызения совести при назначении цены. 

Управление прайс-листом

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

Самое главное в прайс-листе — это продукты. У себя в компании мы приняли решение присваивать каждому товару уникальное название, не такое, как у всех.

К примеру, светодиоды — это ниша с высокой конкуренцией, при этом большинство игроков публикуют цены в интернете. И клиентам легко находить более выгодные предложения от «менее жадных» поставщиков. Поэтому мы ввели свою схему наименований светильников, например, «СДУ 60-95» — светодиодный уличный светильник с углом раскрытия светового потока 60 градусов и мощностью 95 Вт.

Многие, конечно, считают, что это полная глупость, но «999 рублей 99 копеек» действительно работает, и не только в рознице. Есть предположение, что люди не доверяют круглым цифрам, так как им кажется, что эти цены назначены «с потолка». Также есть еще одно правило: старайтесь использовать цифры 5, 7 и 9. Ценники с этими цифрами больше нравятся клиентам. Наш бизнес оптовый, в основном в сегменте B2B, поэтому мы стараемся не перегибать палку. К примеру, если выходит цена 16 000, исправляем её на 15 970, 4000 — на 3980, а 600 — на 590.

Многие, конечно, считают, что это полная глупость, но «999 рублей 99 копеек» действительно работает, и не только в рознице. Есть предположение, что люди не доверяют круглым цифрам, так как им кажется, что эти цены назначены «с потолка». Также есть еще одно правило: старайтесь использовать цифры 5, 7 и 9. Ценники с этими цифрами больше нравятся клиентам. Наш бизнес оптовый, в основном в сегменте B2B, поэтому мы стараемся не перегибать палку. К примеру, если выходит цена 16 000, исправляем её и на 15 970, 4000 — на 3980, а 600 — на 590

Базы данных

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

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

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

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

Все современные файловые системы поддерживают многоуровневое именование файлов за счет поддержания во внешней памяти дополнительных файлов со специальной структурой - каталогов или папок. Каждый каталог содержит имена каталогов и/или файлов, содержащихся в данном каталоге. Таким образом, полное имя файла состоит из списка имен каталогов плюс имя файла в каталоге, непосредственно содержащем данный файл. Разница между способами именования файлов в разных файловых системах состоит в том, с чего начинается эта цепочка имен.

Области применения файлов состоят в хранении, в первую очередь, текстовых данных: документов, текстов программ и т.д. Такие файлы образуются и модифицируются с помощью различных текстовых редакторов. Структура текстовых файлов обычно очень проста: это либо последовательность записей, содержащих строки текста, либо последовательность байтов. Одним словом, файловые системы обеспечивают хранение слабо структурированной информации, оставляя дальнейшую структуризацию прикладным программам.

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

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

Моделирование структуры базы данных книжного магазина

Рассмотрим основные понятия теории проектирования баз данных на примере построения базы данных отдела закупок книжного магазина.

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

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

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

После этого определим основные понятия, необходимые для моделирования предметной области. С этой точки зрения информационного моделирования нам будут интересны объекты предметной области, которые несут существенную смысловую нагрузку.

Сущностью называют отдельный объект предметной области (человек, место, вещь, понятие, событие), которое нужно представить в базе данных. Важно понимать, что сущность - это обобщающее понятие однотипных объектов предметной области, а не конкретный экземпляр. Например, сотрудник вообще, а не конкретно, менеджер Иванов. Одного из конкретных представителей той или иной сущности называют экземпляром сущности.

Анализируя описание предметной области рассматриваемого примера можно выделить следующие объекты предметной области, информация о которых должна храниться в базе данных (потенциальные сущности): поставщик, издатель, оптовое предприятие, прайс-лист, коммерческое предложение, договор, товар, товарный классификатор, группа товара, менеджер. Такие понятия как поставщик, издатель, оптовое предприятие тесно связаны между собой и представляют для менеджера отдела закупок организацию, которая уже поставляет товар в магазин или предлагает новый товар. Таким образом, эти сущности можно заменить одной сущностью и назвать ее поставщик. Аналогично, можно считать синонимами потенциальные сущности прайс-лист и коммерческое предложение - это некий документ, который содержит информацию о товаре и цене на него. Объединим эти сущности в одну сущность -прайс-лист.

Одним из наиболее удобных инструментов унифицированного представления данных, независимого от реализующего его программного обеспечения, является модель «сущность-связь» (entity-relationship model, ER-model), которая используется для анализа предметной области. Модель «сущность-связь» основывается на некой информации о реальном мире и предназначена для логического представления данных. Она определяет значения данных в контексте их взаимосвязи с другими данными, используемыми в системе. Модель «сущность-связь» представляется в графическом виде и называется диаграммой «сущность-связь». На ней представлены все выявленные сущности предметной области и указаны взаимосвязи между ними. Она показывает, как вероятнее всего будет выглядеть база данных, какие данные будут в ней храниться, что будет делать система, но не говорит как. Диаграмма «сущность-связь» должна быть независима от применяемой технологии и может быть реализована при помощи любой СУБД.

На диаграмме «сущность-связь» сущность изображается в виде прямоугольника, в котором указано имя сущности.

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

В рассматриваемом примере атрибутами сущности «поставщик» могут являться:

• наименование;
• адрес;
• телефон;
• форма собственности.

Для сущности «товар» можно выделить следующие атрибуты:

• автор книги;
• тираж;
• серия;
• год издания;
• издательство;
• тип переплета;
• цена книги.

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

Сущность не может иметь более одного значения каждого из её атрибутов. Если в процессе построения информационной модели выясняется, что сущность может иметь несколько значений атрибута, тогда необходимо выяснить, не является ли этот объект предметной области отдельной сущностью. Например, для сущности «поставщик» мы выделили такой атрибут как «адрес». А затем выяснили, что у организации почтовый адрес может не совпадать с юридическим адресом. В этом случае необходимо определить два атрибута - «юридический адрес» и «почтовый адрес». Если это сделать невозможно или затруднительно (если значений много или их количество неизвестно), то, скорее всего, это не атрибут, а отдельная сущность.

Например, если поставщик имеет несколько номеров телефонов - у директора, главного бухгалтера, товароведа и т.д., то понятие «телефон» следует выделить в отдельную сущность «телефоны организации», каждый экземпляр такой сущности будет характеризоваться наименованием организации и телефоном. Для упрощения примера будем считать, что каждая организация имеет только один телефон и он является атрибутом поставщика.

Атрибуты делят на обязательные, которые должны иметь значение, и необязательные, для которых конкретное значение может быть неопределенно. Обязательные атрибуты на нашей схеме выделяются жирным шрифтом. Обязательным атрибутом сущности «поставщик» является его наименование, а это значит, что в базу данных не будет внесена информация о поставщике, для которого не задано наименование. В случае возникновения такой ситуации пользователь получает сообщение об ошибке и предложение ввести недостающую информацию.

Для сущности «менеджер» оба ее атрибута «табельный номер» и «Ф.И.О. менеджера» являются обязательными. Каждый сотрудник при оформлении на работу получает табельный номер. А то, что «Ф.И.О. менеджера» является обязательным атрибутом, очевидно.

Атрибут характеризуется наименованием, описанием, форматом и длиной, а так же теми допустимыми значениями, которые может принимать атрибут. Например, атрибут «телефон» представляет собой строку текста длиной не более 7 символов. Тогда формат атрибута «телефон» может быть определен как: «строка текста длиной 7 знаков». Атрибут «дата заключения договора» сущности «договор» может содержать только данные типа «дата», тогда его формат можно определить как «дата». В этом случае в качестве значения атрибута ввести информацию типа «24.12.2004» будет невозможно, так как строка такого вида не может быть преобразована в дату. Атрибут «ставка НДС» сущности «товар» может принимать, согласно российскому законодательству, только значения «0», «10» или «20», следовательно, атрибут можно описать как «целое число, принимающее значение 0, 10, 20». Ввести значение «15» в это поле будет невозможно.

При проектировании базы данных допустимо две или несколько сущностей, имеющие общие или схожие атрибуты, объединять в одну. В нашем примере мы это сделали для сущностей «поставщик», «издатель», «оптовое предприятие».

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

Иногда удается использовать естественные уникальные признаки объекта. Например, ИНН (индивидуальный номер налогоплательщика) является уникальным идентификатором любого физического и юридического лица, который присваивается при создании предприятия. «ИНН» можно использовать в качестве уникальной идентификации организации. Добавим атрибут «ИНН» к сущности «поставщик».

Чаще всего необходимо придумывать уникальные идентификаторы самостоятельно. Например, для уникальной идентификации товара в базе не всегда можно использовать его атрибут «ISBN», поскольку некоторым видам печатных изданий (музыкальная литература, малотиражные издания) его не присваивают. Чаще всего, для уникальной идентификации товара в базе данных используется целое число, которое автоматически генерируется системой управления базой данных и присваивается каждому новому экземпляру сущности.

На диаграмме «сущность-связь» атрибуты, определяющие уникальные идентификаторы каждой сущности, обозначаются буквами «РК» перед именем атрибута.

Заметим, что сущность может иметь несколько наборов уникальных идентификаторов.

Связь (отношение) - это то, что логически объединяет или связывает две различные сущности или одну сущность саму с собой. Например, «сотрудник» должен числиться в подразделении «отдел». Или «раздел классификатора» может включать в себя другой «раздел классификатора». Каждой связи присваивается имя, которое выражает ее функцию или действие, связывающее эти две сущности. Связь реализуется через соотнесение одинаковых значений атрибутов, которые являются общими для обеих сущностей. Различают следующие типы связей: один-к-одному (1:1), один-ко-многим (1:N) и многие-ко-многим (М:N).

На диаграмме «сущность-связь» связи между сущностями обозначаются в виде линий.

При связи один-к-одному каждому экземпляру одной сущности соответствует не более одного экземпляра другой. Этот вид связи встречается довольно редко.

Наиболее распространенный тип связи один-ко-многим. При таком типе связи каждому экземпляру одной сущности соответствует несколько экземпляров в другой связанной сущности.

В нашем примере сущности «поставщик» и «договор» объединены связью типа «один-ко-многим». В терминах информационной модели это обозначает, что каждый поставщик (экземпляр сущности «поставщик») может иметь один или несколько договоров (экземпляров в сущности «договор»), которые относятся к этому поставщику. А в терминах предметной области это обозначает, что с каждым поставщиком книжный магазин может заключить более одного договора. Если между сущностями была бы организована связь «один-к-одному», то это бы обозначало, что с каждым поставщиком в базе данных договоров может быть связано не более одного договора. Общим полем для сущности «поставщик» и «договор» является атрибут «ИНН поставщика», который однозначно идентифицирует каждый экземпляр поставщика.

При использовании связи многие- множеству экземпляров сущности в одной таблице соответствует множество экземпляров в другой связанной сущности.

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

Большинство современных СУБД непосредственно не поддерживают такой тип связи «многие-ко-многим». Для физической реализации такая связь разбивается на две связи типа «один-ко-многим» через промежуточную таблицу, которая является сущностью, не выявленной на этапе концептуального проектирования. Поэтому появление связи типа «многие-ко-многим» является основанием повторного анализа предметной области.

В нашем случае необходимо разбить связь между сущностями «поставщик» - «товар» на две. Поскольку каждый поставщик поставляет товар по своей цене, то можно использовать сущность «прайс-лист» в качестве естественного разбиения связи типа «многие-ко-многим» на две связи типа «один-ко-многим». В нашем примере каждый поставщик в «прайс-листе» предлагает один или несколько товаров по некоторой цене. С одной стороны, атрибут «цена» является частью сущности «прайс-лист». Общим атрибутом является атрибут «ИНН поставщика». С другой стороны, прайс-лист содержит не менее одного товара. Иначе говоря, сущности «товар» и «прайс-лист» связаны отношением «один-ко-многим» по общему полю «код товара». Таким образом, связь «многие-ко-многим» между сущностями «поставщик» и «товар» разбита на две. Сущность «прайс-лист» уникально идентифицируется атрибутами «ИНН поставщика» и «код товара».

Очень часто для осуществления электронного обмена документами возникает необходимость хранить в базе данных идентификатор товара, который уникально характеризует товар в базе данных поставщика, так называемый, «артикул товара». Очевидно, что данный атрибут нельзя разместить ни в сущности «поставщик», так как поставщик поставляет много товаров, ни в сущности «товар», так как у каждого поставщика один и тот же товар может иметь разный артикул. Очевидно, что для этих целей лучше всего подходит сущность «прайс-лист», которая определяет список товаров, предлагаемых каждым поставщиком.

Заметим, что для сущности «договор» в качестве уникального ключа выбран набор атрибутов «номер договора» и «дата заключения договора». Для объяснения такого выбора уникального идентификатора необходимо обратиться к практике работы предприятий. Чаще всего договора заключаются ежегодно, при этом, нумерация договоров обычно начинается с цифры 1. Если выбрать в качестве первичного ключа номер договора, то через год в систему невозможно будет внести договор с номером 1, даже если он относится к другому поставщику. Поэтому, в качестве уникального идентификатора выбран набор атрибутов «номер договора» и «дата заключения договора». Если в организации используется другая система нумерации договоров, например, если номер договора с поставщиком содержит год заключения договора, то выбор уникального идентификатора может быть иным.

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

Основные возможности системы

- Модуль конструктора импорта прайсов:

1) загрузка, обработка и объединение прайсов поставщиков (и/или конкурентов)

2) приведения всех своих прайсов к единому, удобному для восприятия и работы формату

3) настройка под любые структуры прайс-листов без участия программистов и написания специальных скриптов

4) загрузка любой информации, включая рекомендованные цены

5) пересчет цен поставки с учетом скидок по категориям, брендам и курсам валют

6) автоматический импорт прайс-листов по расписанию

- Модуль работы с прайс-листами:’

• полнотекстовый поиск товаров по прайсам

• разнообразные расчеты цен по формулам и наценкам

• отбор позиций по любым критериям и реквизитам товаров

• массовая (групповая) обработка позиций - присвоение значений

• поиск по вхождению, поиск по комбинациям символов

• просмотр карточки товара из любого места в программе

• подключение инфо-панелей с информацией по стыковкам, описаниям, фото и т.д.

• возможность одновременной обработки прайсов заданных поставщиков

• расчет до пяти пяти учетных цен своего прайс-листа

• создание неограниченного количества типов формул расчета цен

• привязка расчета цен к товарам, категориям

• пересчет любой цены из любой другой цены

• групповой (массовый) пересчет цен

• создания правил наценок для расчет цен

• расчет оптимальной цены поставки по состыкованным позициям прайсов поставщиков

• поддержка фиксированных скидок (наценок) как в процентах, так и в числовых константах

- Модуль сопоставления аналогов товаров:

• автоматическое сопоставления товаров прайсов поставщиков (конкурентов)

• по-позиционное стыковка товаров-аналогов

• настройка сопоставления по наименованию, артикулу, категории, производителю

• просмотр состыкованных товаров в любом месте программы

• формирование сводныого прайс-листа на основе сопоставленых прайсов

• использование алгоритмов полнотекстового поиска базы данных MySQL

• создание сводного прайса (кросс-прайса) на основании сопоставленных товаров-аналогов

• расчет оптимальной (минимальной) цены поставки

Интеграция с популярными WEB-ресурсами

Интер-Прайс предназначается для снабженцев, давая возможность объединить все прайс-листы поставщиков в одной системе, легко искать товары, сравнивать цены и оптимально формировать заказы на поставку. В этой системе нет ограничений на количество товаров и количество поставщиков.

Модуль конструктора экспорта прайс-листа в форматах CSV XLS XML DBF

• конструирование выходного файла экспорта прайс-листа в форматах CSV XML XLS DBF

• настройка для любых движков CMS-систем, в которых есть модули загрузки через CSV (XML,XLS,DBF,TXT) форматы

• встроенный язык программирования для преобразований и фильтра данных

• формирование иерархического прайс-листа по категориям, брендам

• создание неограниченого числа настроек экспорта

• поддержка одновременной выгрузки в несколько типов интернет-магазинов

• автоматический экспорт прайс-листа по расписанию

Модуль работы с заказами от покупателей

• автоматизация функций ведение заказов от покупателей

• учет заказов от всех клиентов, включая заказы сделанные в интернет-магазине, по электронной почте, по телефону или другим иным современным способом телекоммуникаций

• поддержка всего необходимого инструментария по комфортному и полному ведению реестра заказов, включая поиск, отбор данных, установку заданных реквизитов заказов, оплаты, отчетов по доставке и отгрузке товара покупателям

• формирование печатных форм по оплате, доставке и отгрузке товара покупателям

Модуль работы с заказами поставщикам

• ведение журнала заказов на поставку

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

• объединение и разделение заказов, установка статусов, группировка товаров в заказах

• расчет общей суммы заказа, учет оплаты

• импорт заказов в кодах и наименованиях поставщиков

• автоматическое преобразовывание заказов по состыкованным позициям в альтернативные заказы другим поставщикам