Описание предветной области. Анализ предметной области обувного магазита 1 описание предметной области
 Скачать 50.39 Kb.
|
1 2 Модель предметной области. Модель предметной области — это наши знания о предметной области. Знания могут быть как в виде неформальных знаний в мозгу эксперта, так и выражены формально при помощи каких-либо средств. В качестве таких средств могут выступать текстовые описания предметной области, наборы должностных инструкций, правила ведения дел в компании и т.п. Опыт показывает, что текстовый способ представления модели предметной области крайне неэффективен. Гораздо более информативными и полезными при разработке баз данных являются описания предметной области, выполненные при помощи специализированных графических нотаций. Имеется большое количество методик описания предметной области. Модель предметной области описывает скорее процессы, происходящие в предметной области и данные, используемые этими процессами. От того, насколько правильно смоделирована предметная область, зависит успех дальнейшей разработки приложений. Логическая модель данных. На следующем, более низком уровне находится логическая модель данных предметной области. Логическая модель описывает понятия предметной области, их взаимосвязь, а также ограничения на данные, налагаемые предметной областью. Примеры понятий — «магазин», «поставщик», «склад», «продажа». Логическая модель данных является начальным прототипом будущей базы данных. Логическая модель строится в терминах информационных единиц, но без привязки к конкретной СУБД. Более того, логическая модель данных необязательно должна быть выражена средствами именно реляционной модели данных. Основным средством разработки логической модели данных в настоящий момент являются различные варианты ER—диаграмм(Entity-Relationship, диаграммы сущность-связь). Одну и ту же ER-модель можно преобразовать как в реляционную модель данных, так и в модель данных для иерархических и сетевых СУБД, или в постреляционную модель данных. Однако, т.к. мы рассматриваем именно реляционные СУБД, то можно считать, что логическая модель данных для нас формулируется в терминах реляционной модели данных. Решения, принятые на предыдущем уровне, при разработке модели предметной области, определяют некоторые границы, в пределах которых можно развивать логическую модель данных, в пределах же этих границ можно принимать различные решения. Например, модель предметной области складского учета содержит понятия «склад», «товар». При разработке логической модели данных возникают вопросы: хорошо ли спроектированы отношения? Правильно ли они отражают модель предметной области, а следовательно и саму предметную область? Физическая модель данных. На еще более низком уровне находится физическая модель данных. Физическая модель данных описывает данные средствами конкретной СУБД. Мы будем считать, что физическая модель данных реализована средствами именно реляционной СУБД, хотя, как уже сказано выше, это необязательно. Отношения, разработанные на стадии формирования логической модели данных, преобразуются в таблицы, атрибуты становятся столбцами таблиц, для ключевых атрибутов создаются уникальные индексы, домены преображаются в типы данных, принятые в конкретной СУБД. Ограничения, имеющиеся в логической модели данных, реализуются различными средствами СУБД, например, при помощи индексов, декларативных ограничений целостности, триггеров, хранимых процедур. При этом опять-таки решения, принятые на уровне логического моделирования определяют некоторые границы, в пределах которых можно развивать физическую модель данных. Точно также, в пределах этих границ можно принимать различные решения. Например, отношения, содержащиеся в логической модели данных, должны быть преобразованы в таблицы, но для каждой таблицы можно дополнительно объявить различные индексы, повышающие скорость обращения к данным. Многое тут зависит от конкретной СУБД. При разработке физической модели данных возникают вопросы: хорошо ли спроектированы таблицы? Правильно ли выбраны индексы? Собственно база данных и приложения. И, наконец, как результат предыдущих этапов появляется собственно сама база данных. База данных реализована на конкретной программно-аппаратной основе, и выбор этой основы позволяет существенно повысить скорость работы с базой данных. Например, можно выбирать различные типы компьютеров, менять количество процессоров, объем оперативной памяти, дисковые подсистемы и т.п. Очень большое значение имеет также настройка СУБД в пределах выбранной программно-аппаратной платформы. Но опять решения, принятые на предыдущем уровне — уровне физического проектирования, определяют границы, в пределах которых можно принимать решения по выбору программно-аппаратной платформы и настройки СУБД. Таким образом ясно, что решения, принятые на каждом этапе моделирования и разработки базы данных, будут сказываться на дальнейших этапах. Поэтому особую роль играет принятие правильных решений на ранних этапах моделирования. 2. Концептуальное проектирование В данном случае нет необходимости разбивать предметную область на локальные представления, так как нельзя по смыслу разделить данную предметную область 2.1 Выделение сущностей с перечнем их атрибутов база атрибут данные проектирование Выделим базовые сущности этой предметной области: 1 Поставщики. Атрибуты поставщика — код товара, артикул товара, имя фабрики, срок поставки, фирма поставщик, горд поставщик, код поставщика. 2 Склад. Атрибуты склада — код товара, артикул товара, наименование товара, код поставщика. 3 Магазин. Атрибуты магазина — код поставщика, цена товара, наименование товара, артикул товара, код товара, количество в магазине, изображение товара. 4 Продажи. Атрибуты продажи — код товара, наименование товара, дата продажи, количество проданного, артикул проданного товара. Описание связей данной предметной области: 1. Поставщики — Склад. Между этими сущностями существует связь «поставляет». Это связь между сущностью поставщик и сущностью склад. Сущность поставщики существует, не зависимо от сущности склад. В данной связи реализуется тип связи (1:М). 2. Склад — Магазин. Между этими сущностями существует связь «снабжает». Будем рассматривать как связь между сущностью Склад и сущностью Магазин, в наличии склада имеется весь ассортиментный список поставляемого товара, но магазин не обязательно имеет в наличии весь ассортиментный список товара находящегося на складе. В данной связи реализуется (1:1) тип связи. 3. Магазин — Продажи Между этими сущностями существует связь «продаёт». Это связь между сущностью магазин и продажи. В данной связи сущность магазин существует, не зависимо от продаж, а продажи без магазина существовать не могут. В данной связи реализуется тип связи (М:1). Построим ER — диаграмму соответствии с выделенными сущностями. Рис. 2.4 Обобщенная ER — диаграмма БД обувного магазина 2.2 Анализ информационных задач и круга пользователей системы Система создаётся для обслуживания следующих групп пользователей: ь Администратор БД: имеет доступ ко всем данным, может изменять структуру базы данных и связи между отношениями. Устанавливает права доступа для всех остальных групп пользователей. ь Менеджер и Директор магазина: имеют доступ для чтения всех данных. ь Бухгалтер: имеет доступ для чтения и изменения БД. ь Оператор: имеет доступ ко всем данным, но ни имеет права изменения структуры БД. Определим границы информационной поддержки пользователей: 1. Функциональные возможности: - ведение БД (запись, чтение, модификация, удаление в архив); - обеспечение логической непротиворечивости БД; - обеспечение защиты данных от несанкционированного или случайного доступа (определение прав доступа); - реализация наиболее часто встречающихся запросов в готовом виде; - предоставление возможности сформировать произвольный запрос на языке манипулирования данными. 2. База данных содержит готовые запросы на выдачу следующей информации: БД должна содержать сведения об ассортименте обуви в магазине. БД должна осуществлять формирование запросов на выдачу следующей информации: - Изображение этого вида обуви, наличие и стоимость обуви каждого артикула; - Ассортиментный список дамской обуви с наименованием и имеющегося в наличии числа пар каждой модели; - Определение модели обуви, и её количества в магазине; - Список городов и фабрик, изготовляющих женскую (мужскую и детскую) обувь; - Количество пар обуви любого артикула и любого наименования с указанием сроков поставки; - Формат деловых писем на фабрику с просьбой о поставке определённого количества пар обуви данного ассортимента, если количество пар в магазине меньше заданного количества < 5. - Количество товара в магазине; 3. Выбор СУБД Анализ информационных задач показывает, что для реализации требуемых функций подходят почти все СУБД для ПК (FoxPro, MS Access и др.). Все они поддерживают реляционную модель данных и предоставляют разнообразные возможности для работы с данными. Для реализации БД магазина наиболее эффективным будет использование СУБД MS Access, так как эта СУБД была изучена нами на практических занятиях по её изучению, она работает с реляционными БД, наиболее проста в описании данной БД, поддерживает язык запросов, также имеет более наглядный интерфейс. MS Access является частью стандартного пакета MS Office который очень широко распространён среди пользователей ПК.MS Access позволяет успешно применять данный пакет для решения практических задач Microsoft Access — это функционально полная реляционная СУБД. В ней предусмотрены все необходимые вам средства для определения и обработки данных, а также для управления ими при работе с большими объемами информации. Что касается легкости использования, то Microsoft Access совершил здесь настоящий переворот, и многие для создания своих собственных баз данных и приложений обращаются именно к нему. Система управления базами данных предоставляет вам возможность контролировать задание структуры и описание своих данных, работу с ними и организацию коллективного пользования этой информацией. СУБД также существенно увеличивает возможности и облегчает каталогизацию и ведение больших объемов хранящейся в многочисленных таблицах информации. Microsoft Access предоставляет вам максимальную свободу в задании типа ваших данных (текст, числовые данные, даты, время, денежные значения, рисунки, звук, документы, электронные таблицы). Можете осуществлять вставку различных объектов, из Word, Excel. Вы можете задать также форматы хранения (длина строки, точность представления чисел и даты времени) и предоставления этих данных при выводе на экран или печать. 4. Логическое проектирование реляционной БД 4.1 Преобразование ER—диаграммы в схему базы данных База данных создаётся на основании схемы базы данных. Для преобразования ER-диаграммы в схему БД приведём уточнённую ER-диаграмму. Полученная схема реляционной базы данных (РБД) приведена на рисунке 4. Рис. 4.3 Схема РБД, полученная из ER-диаграммы Обувного магазина. 4.2 Составление реляционных отношений Каждое реляционное отношение соответствует одной сущности (объекту ПО) и в него вносятся все атрибуты сущности. Для каждого отношения необходимо определить первичный ключ и внешние ключи (если они есть). В том случае, если базовое отношение не имеет потенциальных ключей, вводится суррогатный первичный ключ, который не несёт смысловой нагрузки и служит только для идентификации записей. Примечание: суррогатный первичный ключ также может вводиться в тех случаях, когда потенциальный ключ имеет большой размер (например, длинная символьная строка) или является составным (не менее трёх атрибутов). Потенциальным ключом отношения Поставщик является атрибут: Имя поставщика. Этот атрибут уникален, поэтому для сущности Поставщик необходимо ввести суррогатный ключ — код поставщика. Отношения приведены в табл. 1 — 3. Для каждого отношения указаны атрибуты с их внутренним названием, типом и длиной. Типы данных обозначаются так: N — числовой, C — символьный, D — дата (последний имеет стандартную длину, зависящую от СУБД, поэтому она не указывается). Источник НА КУРСОВОЕ ПРОЕКТИРОВАНИЕ ПО КУРСУ Пояснительная записка листов, рисунков, таблицы, источника, приложения. Объектом исследования является продажа обуви. Цель работы – разработать приложение для базы данных фирмы-продавца обуви. В результате проделанной работы разработана программа для базы данных фирмы-продавца обуви. При написании программы использовалась среда визуального программирования Delphi 2009.
1 Техническое задание 1.1 Основание для разработки 1.2 Назначение разработки 1.3 Требования к программе 1.3.1 Требования к функциональным характеристикам 1.3.2 Требования к надежности 1.3.3 Требования к составу и параметрам технических средств 1.3.4 Требования к информационной и программной совместимости 1.4 Требования к программной документации 1.5 Стадии и этапы разработки 1.6 Порядок контроля и приемки 2 Концептуальное проектирование системы 2.1 Разработка модели предметной области 2.2 Разработка концептуальной модели 3 Логическое проектирование БД 4 Физическое проектирование БД 5 Проектирование приложения 5.1 Анализ функций приложения 5.2 Определение описания функций 5.3 Отображение функций в модули 6 Описание программы 6.1 Общие сведения 6.2 Функциональное назначение 6.3 Описание логической структуры 6.4 Используемые технические средства 6.5 Вызов и загрузка 6.6 Входные данные 6.7 Выходные данные 7 Программа и методика испытаний 7.1 Объект испытаний 7.2 Цель испытаний 7.3 Требования к программе 7.4 Требования к программной документации 7.5 Средства и порядок испытаний 7.6 Методы испытаний 8 Описание применения 8.1 Назначение программы 8.2 Условия применения 8.3 Описание задачи 8.4 Входные и выходные данные В настоящее время сеть обувных магазинов на рынке товаров и услуг развита не меньше, чем какие – либо другие магазины, пользующиеся высокой популярностью. Каждый обувной магазин представляет огромный ассортимент различных видов обуви, которая, в свою очередь, требует учет. При учете ассортимента обуви необходимо учитывать множество данных, таких как: наименование обуви, размер, цена, количество, текущая дата. Как правило, при обработки большого количества данных возникают ошибки. Для того чтобы минимизировать ошибки и потери данных, необходимо автоматизировать процесс учета отпуска медицинских препаратов в аптечные сети. Для автоматизации данного процесса необходимо создать базу данных, в которой будет храниться информация об изготовителе обуви и ее ассортименте. В данной работе рассматривается клиент-серверное приложение для работы с базой данных «Учет поставок обуви». База данных спроектирована для СУБД Firebird 2.5. 1.1 Основание для разработки Программа разрабатывается на основании задания на курсовое проектирование по дисциплине «Базы данных». Задание утверждено заведующим кафедрой ИВС Пензенского государственного университета Косниковым Ю.Н. и выдано доцентом кафедры ИВС Ерёменко А.В. 1.2 Назначение разработки Приложение SHOP предназначено для обслуживания обувного магазина. 1.3 Требования к программе База данных должна позволять хранить изменение, хранение и удаление следующих данных: — информацию об ассортименте имеющейся обуви — идентификатор ассортимента, наименование обуви, размер, цену, количество, текущую дату; — информацию об изготовителе обуви — идентификатор изготовителя, название фирмы, ее адрес; Приложение должно выполнять следующие функции: — формировать сведения об ассортименте обуви; — формировать сведения об изготовителе обуви; — осуществлять запросы к базе данных; — формировать отчетные документы. 1.3.2 Требования к надежности Программа должна работать без перебоев, отслеживать формат вводимых данных. Сбои при работе программы не должны приводить к экономическому ущербу. Программа должна обеспечивать защиту данных от несанкционированного доступа. 1.3.3 Требования к составу и параметрам технических средств Программа должна быть предназначена для работы на персональных компьютерах, имеющих следующие минимальные характеристики: 1) тактовая частота процессора — не менее 1,5 МГц; 2) оперативная память – не менее 1024 Мбайт; 3) на жестком диске при установке используется около 300Мбайт; 4) объем жестокого диска должен быть не менее 500 Мбайта. 1.3.4 Требования к информационной и программной совместимости Приложение должно работать как на локальном компьютере, так и в на сети. Для работы на сервере на нем должна быть установлены СУБД Firebird 2.5 и файл с БД, а на рабочей станции – приложение для работы с БД. Для работы на локальном компьютере на нем должны быть установлены СУБД Firebird, приложение для работы с БД, файл с БД. Программа должна быть совместима с операционной системой Windows XP/7/8. 1.4 Требования к программной документации Программа должна сопровождаться пояснительной запиской, содержащей следующие программные документы: — программу и методику испытаний; Содержание и структура программных документов должны соответствовать требованиям стандартов ЕСПД. 1.7 Стадии и этапы разработки Программа должна разрабатываться со следующими этапами: Стадии и этапы разработки приведены в таблице 1. Таблица 1 – Стадии и этапы разработки
1.7 Порядок контроля и приёмки Контроль работоспособности программы должен осуществляться на основе тестовых наборов данных, которые должны охватывать выполнение всех функций приложения. Приемка программы должна осуществляться при ее работоспособности и правильном выполнении всех возложенных на нее функциональных возможностей при наличии программной документации. 2 Концептуальное проектирование системы 2.1 Разработка концептуальной модели При разработке концептуальной модели нужно сначала создать структуры данных и определить атрибуты для сущностей — Изготовитель, Ассортимент, Продажи, Склад. Для структуры данных сущности Изготовитель атрибуты и их назначение показаны в таблице 2. Таблица 2 — Структура данных сущности Изготовитель
Для структуры данных сущности Ассортимент атрибуты и их назначение показаны в таблице 3. Таблица 3 — Структура данных сущности Ассортимент
Для структуры данных сущности Продажи атрибуты и их назначение показаны в таблице 4. Таблица 4 — Структура данных сущности Продажи
Для структуры данных сущности Склад атрибуты и их назначение показаны в таблице 5. Таблица 5 — Структура данных сущности Склад
Первичным ключом для сущности Изготовитель является ID, для сущности Ассортимент — ID, для сущности Продажи – ID, для сущности Склад – ID. Показатель кардинальности равен 0,N для сущности Изготовитель, от которой начинается связь, и 1,1 — для сущности Ассортимент, на которой эта связь заканчивается (такая связь называется связью главная-подчиненная) т.к. Один изготовитель может выпускать несколько ассортиментов обуви, но конкретный ассортимент выпущен данным производителем. Степень участия сущности — полная. Сущность Ассортимент является слабой сущностью и может быть идентифицирована только при помощи сущности Изготовитель, поэтому показатель кардинальности 1,1 подчеркивается. Показатель кардинальности равен 0,N связь между сущностью Ассортимент, от которой начинается связь, и 1,1 — для сущности Склад, на которой эта связь заканчивается т.к. в сущности Склад может быть множество экземпляров сущности Ассортимент, но не весь ассортимент обуви должен быть представлен на данном скалде. Степень участия – частичная. Показатель кардинальности равен 0,N для сущности Склад, от которой начинается связь, и 1,1 — для сущности Продажи, на которой эта связь заканчивается (такая связь называется связью главная-подчиненная) т.к. с одного склада может быть осуществлено несколько продаж обуви, но конкретная продажа осуществляется с данного склада. Степень участия сущности — полная. Сущность Продажи является слабой сущностью и может быть идентифицирована только при помощи сущности Склад, поэтому показатель кардинальности 1,1 подчеркивается. Концептуальная модель представлена на рисунке 1. Рисунок 1 — Концептуальная модель Таким образом, была разработана концептуальная модель данных. 3 Логическое проектирование БД Логическое проектирование подразумевает создание реляционной модели данных на основе концептуальной модели. На данном этапе необходимо определить внешние ключи. Атрибут «ID» является внешним ключом для сущности Ассортимент и мигрирует из сущности Изготовитель (ID). Атрибут «ID» является внешним ключом для сущности Продажи и мигрирует из сущности Склад (ID), также этот внешний ключ входит в состав первичного ключа сущности Продажи, т. к. только сочетание ID склада и продаж позволяют уникально идентифицировать записи. Атрибут «ID» является внешним ключом для сущности Склад и мигрирует из сущности Ассортимент Изготовитель (ID), Ассортимент (ID). Также необходимо указать физические имена атрибутов. Сделать это следует вручную, так как возможности автоматической генерации физическим имен системы Open ModelSphere довольно ограничены. В таблице 6 представлены физические имена атрибутов и нулевые значения для сущности Изготовитель. Таблица 6 — Физические имена атрибутов сущности Изготовитель
В таблице 7 представлены физические имена атрибутов и нулевые значения для сущности Ассортимент. Источник АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ МАГАЗИНА ОБУВИ Библиографическая ссылка на статью: Перминова Н.А., Баженов Р.И. Совершенствование ассортимента обуви магазина «Велес» на основе АВС-XYZ-анализа // Экономика и менеджмент инновационных технологий. 2015. № 3 [Электронный ресурс]. URL: https://ekonomika.snauka.ru/2015/03/7782 (дата обращения: 24.06.2021). Свмещенный ABC-XYZ-анализ широко используется для ранжирования и группирования ассортиментных позиций по степени прогнозируемости объема спроса или уходимости товара. Величина вероятной погрешности при прогнозировании объема реализации является важнейшим фактором при выборе рациональной стратегии управления товарным запасом на любом предприятии. Проблемами ABC-XYZ-анализа занимаются российские и зарубежные ученые. Е.А.Бузукова рассмотрела анализ ассортимента и стабильности продаж с использованием ABC- и XYZ-анализа [1]. Оценку результативности ABC-XYZ-анализа показал Е.П.Голубков [2]. С.В.Ласковец, Р.В.Каптюхин, О.Н.Жидкова применили методы анализа ассортимента в целях совершенствования товарной политики компании [3]. А.И.Репичев провел анализ товарного портфеля сельскохозяйственного предприятия [4]. Рационализация управления трудовыми потоками в логистических системах проектных организаций на основе ABC-XYZ анализа показана В.В.Дементьевым и А.В.Фоменко [5]. Совершенствование управления запасами с помощью автоматизации проведения АВС – и XYZ – анализа исследовано Д.В.Эссауленко и др. [6]. Р.И.Баженов и др. применяли модификации анализа в различных предметных областях [7-16]. Зарубежные ученые используют ABC-XYZ- анализ в своих исследованиях [17-19]. Покажем ABC-XYZ-анализ ассортимента обуви специализированного магазина. Организация, которая предоставила данные о реализации товаров, находится в с.Амурзет. В работе представлен ассортимент товаров, включающий в себя 41 позицию. Кратко опишем применяемый метод. Ассортимент обычно анализируется по двум характеристикам: объем продаж и получаемая прибыль. АВС-анализ разбивает товары на группы: группа A – товары, доля нарастающего итога которого близка к 0,8 (то есть 80%); группа В – товары, находящиеся выше позиции, где значение нарастающего итога будет приблизительно равно 0,95 (то есть 95%); группа С — все оставшиеся товары. Рассматриваемый метод, позволяющий анализировать и прогнозировать стабильность бизнес-процессов, например, стабильность продаж отдельных видов товаров. Результат XYZ-анализа – это три категории: — X – группы товаров, характеризующиеся стабильной величиной потребления и высокой степенью прогнозирования. — Y – группы товаров, характеризующиеся известными сезонными колебаниями и средними возможностями их прогнозирования. — Z – группы товаров с нерегулярным потреблением, какие-либо тенденции отсутствуют, точность прогнозирования невысокая. В группу X попадают товары с колебанием продаж в течение года от 0 до 10%, в группу Y – от 10 до 25%, в группу Z – товары с непредсказуемыми колебаниями продаж и, как следствие, не поддающиеся прогнозу. Далее проводим сцепление групп ABC, XYZ в соответствии с наименованиями и анализируем полученные группы. Покажем применение представленного метода. Отчет из информационной системы показывает объем продаж (в руб.) (табл.1) за сентябрь, октябрь и ноябрь 2014 года. 1 2 |