Размещено на http://www.allbest.ru/

1. Задание к контрольной работе

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

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

Система должна выдавать отчеты по запросу менеджера: прайс-лист, перечень товаров со стоимостью (по видам товара), квитанция для расчета, стоимость услуг и т.п.

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

Целью разработки любой базы данных является хранение и использование информации о какой-либо предметной области.

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

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

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

· Концептуальная модель данных

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

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

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

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

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

Логическая модель данных - это данные, представленные на языке описания данных конкретной СУБД.

Логическая модель данных включает в себя следующие составляющие:

- структура данных;

- ограничения, накладываемые на данные

- операции, производимые над данными.

Одну и ту же ER-модель можно преобразовать как в реляционную модель данных, так и в модель данных для иерархических и сетевых СУБД, или в постреляционную (объектно- ориентированную модель данных.

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

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

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

3. Концептуальное проектирование информационной системы

Одна из наиболее распространённых концептуальных моделей данных - модель "Сущность-Связь" (часто ее называют кратко ER-моделью). На использовании разновидностей ER-модели основано большинство современных подходов к проектированию реляционных баз данных. Основными понятиями ER-модели являются сущность, связь и атрибут.

При разработке ER-моделей необходимо получить следующую информацию о предметной области:

1. Список сущностей предметной области.

2. Список атрибутов сущностей.

3. Описание взаимосвязей между сущностями.

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

· Хранить информацию о клиентах.

· Предоставлять перечень доступных товаров по категориям.

· Печатать квитанции по расчету с клиентами, информацию о сроках поставки и дополнительных услугах.

· Следить за наличием товаров.

Анализируя эту информацию, выделим сущности:

· Клиент;

· Товар;

· Квитанция;

· Услуга (если фирма имеет дополнительные виды услуцг).

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

· Покупатель: Имя клиента , Адрес доставки , Банковские реквизиты;

· Товар: Наименование товара, Категория товара, Фото, Цена товара, Единица измерения;

· Категория товара: Наименование категории;

· Дополнительная услуга: Наименование услуги, Стоимость;

· Квитанция: Номер квитанции, Дата выписки, Клиент;

Поскольку список товаров в квитанции не может быть атрибутом, выделим его в отдельную сущность:

· Список товаров в квитанции: Наименование товара, Количество товара в квитанции.

Сумма квитанции равна сумме стоимостей всех товаров, входящих в квитанцию. Эта характеристика не является независимой, и не может считаться атрибутом.

Определим связи между сущностями. Клиенты могут покупать много товаров, и товары могут продаваться многим клиентам. Клиенты покупают товары, получая при этом квитанции, в которые внесены данные о количестве и цене купленного товара. Каждый клиент может получить несколько квитанций. Каждая квитанция обязана выписываться на одного покупателя. Каждая квитанция обязана содержать не менее одного товара (не бывает пустых квитанций). Каждый товар может быть продан нескольким клиентам через несколько квитанций. Каждый клиент может заказать дополнительные услуги, и оплатить их по нескольким квитанции Один из вариантов ER-диаграммы приведён на рисунке 1.

Размещено на http://www.allbest.ru/

4. Логическое проектирование информационной системы

Наиболее распространённой логической моделью на сегодняшний день является реляционная модель.

Эта модель состоит из двумерных таблиц, обладающих следующими свойствами:

1. Каждая таблица состоит из однотипных строк и имеет уникальное имя.

2. В каждой позиции таблицы на пересечении строки и столбца может содержаться только одно значение.

3. Строки таблицы обязательно отличаются друг от друга хотя бы одним значением.

4. Столбцам таблицы однозначно присваиваются имена, и в каждом из них размещаются однородные значения данных (например: даты, фамилии, наименования, целые числа или денежные суммы).

5. При выполнении операций с таблицей ее строки и столбцы можно обрабатывать в любом порядке, независимо от содержания.

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

При разработке схемы базы данных необходимо выполнить следующие условия:

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

2. Поля таблиц по возможности не должны принимать неопределённых (пустых) значений. Неопределённые значения могут привести к ошибкам при выполнении вычислений над теми полями таблиц, в которых они встречаются.

Преобразуем разработанную в п. 2 ER-диаграмму в таблицы и реализуем их с помощью средств MS Access. Используя Конструктор таблиц, выберем типы данных в полях таблиц. В каждой талице создадим уникальное ключевое поле (рис. 2-6).

Рисунок 2- Таблица «Товар»

Рисунок 3-Таблица «Категория товара»

Рисунок 4- Таблица «Клиент»

Рисунок 5 - Таблица «Квитанция»

Рисунок 6 - Таблица «Дополнительные услуги»

Используя ключевые поля, создадим связи между таблицами базы данных (рис.7)

Рисунок 7 - Схема базы данных «Заказ товаров по каталогу»

Заполним полученные таблицы тестовыми данными (рис. 8-12)

Рисунок 8 - Содержание таблицы «Категория товара»

Рисунок 9 - Содержание таблицы «Товар»

Рисунок 10 - Содержание таблицы «Дополнительные услуги»

Рисунок 11 - Содержание таблицы «Клиент»

Рисунок 12 - Содержание таблицы «Квитанция»

5. Разработка интерфейса информационной системы

С помощью Мастера и Конструктора форм MS Access создадим формы для просмотра, ввода и редактирования данных в таблицах базы данных. Примеры экранных форм приведены на рис. 13-14.

Рисунок 13- Форма для просмотра каталога товаров

Рисунок 14 - Форма для вывода товаров по категориям

Создадим отчеты для печати данных, необходимых менеджерам кампании. Примеры отчетов приведены на рис. 15-17.

Рисунок 15 - Отчет для печати текущего прайс-листа

Рисунок 16 - Отчет по дополнительным услугам

Рисунок 17 - Квитанция клиенту

Для удобства управления приложением создадим кнопочную форму (рис.18).

Рисунок 18 -Главная кнопочная форма

Список литературы

1. Кузнецов С.Д. Введение в системы управления базами данных //СУБД. - 1995. - №1,2,3,4, 1996. - №1,2,3,4,5.

2. Хансен Г., Хансен Д.. Базы данных: разработка и управление: Пер. с англ. - М.: ЗАО «Издательство БИНОМ», 1999.- 704 с.

3. Дейт К. Введение в системы баз данных //6-издание. - Киев: Диалектика, 1998. - 784 с.

4. Пушников А.Ю. Введение в системы управления базами данных. Часть 1. Реляционная модель данных: Учебное пособие/Изд-е Башкирского ун-та. - Уфа, 1999. - 108 с..

5. Пушников А.Ю. Введение в системы управления базами данных. Часть 2. Нормальные формы отношений и транзакции: Учебное пособие/Изд-е Башкирского ун-та. - Уфа, 1999. - 138 с

Размещено на Allbest.ru