Информационная поддержка деятельности обувного магазина

Этапы разработки баз данных. Выделение сущностей с перечнем их атрибутов. Анализ информационных задач, круга пользователей системы. Логическое проектирование реляционных БД. Физическое проектирование. Реализация базы данных, направления данного процесса.
Краткое сожержание материала:

Размещено на

Задание

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

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

База данных должна осуществлять формирование запросов на выдачу следующей информации:

ь картинку изображающую этот вид обуви, наличие и стоимость обуви каждого артикула;

ь ассортиментный список дамской обуви с наименованием и имеющегося в наличии числа пар каждой модели;

ь определение модели обуви, которая находится в магазине в минимальном и максимальном количестве;

ь список городов и фабрик, изготовляющих женскую (мужскую и детскую) обувь;

ь количество пар обуви любого артикула и любого наименования с указанием сроков поставки;

ь формат деловых писем на фабрику с просьбой о поставке определённого количества пар обуви данного ассортимента, если количество пар в магазине меньше заданного количества < 5.

Введение

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

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

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

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

1. Этапы разработки баз данных

При разработке базы данных обычно выделяется несколько уровней моделирования, при помощи которых происходит переход от предметной области к конкретной реализации базы данных средствами конкретной СУБД. Можно выделить следующие уровни:

· Сама предметная область;

· Модель предметной области;

· Логическая модель данных;

· Физическая модель данных;

· Собственно база данных и приложения;

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

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

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

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

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

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

При разработке физической модели данных возникают вопросы: хорошо ли спроектированы таблицы? Правильно ли выбраны индексы?

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

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

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

2. Концептуальное проектирование

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

2.1 Выделение сущностей с перечнем их атрибутов

база атрибут данные проектирование

Выделим базовые сущности этой предметной области:

ь Поставщики. Атрибуты поставщика - код товара, артикул товара, имя фабрики, срок поставки, фирма поставщик, горд поставщик, код поставщика.

ь Склад. Атрибуты склада - код товара, артикул товара, наименование товара, код поставщика.

ь Магазин. Атрибуты магазина - код поставщика, цена товара, наименование товара,

артикул товара, код товара, количество в магазине, изображе...