1.1.1.1 Характеристика комплекса задач.

1.1.1.1.1 Цель и назначение комплекса задач:

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

Решение комплекса задач предназначено для автоматизации деятельности сотрудников "Магазина компьютерной техники" в части исполнения следующих процессов:

1) Оформление продажи и ведение учета продаваемого с магазина товара.

2) Оформление поставки и ведение учета поставляемого в магазин товара.

3) Ведение учета о клиентах.

4) Ведение учета о поставщиках.

1.1.1.1.2 Перечень объектов, при управлении которыми решается комплекс задач:

Объектами, при управлении которыми решается комплекс задач являются:

Магазин компьютерной техники.

1.1.1.1.3 Продолжительность и периодичность решения:

Сроки выполнения работ.

1.1.1.1.4 Условия прекращения решения задач автоматизированным способом:

1) Устаревание данной системы

2) Неактуальность

1.1.1.1.5 Связи комплекса задач с другими комплексами ИС

1) Отсутствуют

1.1.1.1.6. Персонал определяющий условия решения задач

Условия и временные характеристики решения задач в ИПС "Магазин компьютерной техники" определяющий ролевой моделью системы.

1.1.1.1.7 Распределение действий между персоналом и ТС при различных ситуациях решения комплекса задач

Распределение действий между персоналом ИТ ИПС "Магазин компьютерной техники" определяются ролевой моделью системы.

1.1.1.2 Выходная информация представлена в таблице 2.

Таблица 2

Экранные формы

1.1.1.3 Входная информация.

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

Таблица 3

1.1.2 Выбор СУБД

Я выбрал для разработки программного компонента Visual Fox Pro по следующим причинам. VFP это очень мощное средство разработки СУБД. К тому же, VFP имеет очень перегруженный язык программирования, это результат обеспечения совместимости со старыми версиями. Современный VFP в большинстве случаев может без дополнительных переделок выполнить программы написанные для самого первого FoxBASE или dBase. Редкое средство программирования может похвастаться такой совместимостью.

Однако обратная сторона медали: современный язык xBase, точнее его диалект, используемый в VFP, содержит свыше полутысячи команд, функций и языковых конструкций. Одно и тоже в VFP можно сделать тремя четырьмя способами. Иногда "старое" программирование времен FoxBASE мирно уживается с современным ООП, а иногда ведет себя как кошка с собакой. Очень часто в описаниях языка VFP можно встретить фразу: "Включено для обеспечения совместимости со старыми версиями. Рекомендуется использовать то-то и то-то".

И из всего выше сказанного следует что у Visual Fox Pro ряд преимуществ, а именно:

СУБД является специализированной программой для работы с реляционными БД, что значительно упрощает процесс даталогического проектирования;

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

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

Эта система очень нетребовательна к аппаратным ресурсам и может выполняться на любом компьютере на котором установлена система Windows (и сама СУБД)

Отдельные утилиты позволяют создавать конечный исполняемый файл, и тогда это очень значительно упрощает распространение программы.

1.1.3 Определение взаимосвязей между сущностями

Взаимосвязь "один ко многим".

Между двумя сущностями "Журнал продаж" и "Товар" установлена взаимосвязь один ко многим, т.к. в журнале продаж может содержаться несколько товаров, это представлено на рисунке 3.

Рисунок 3

Между двумя сущностями "Товар" и "Журнал поставок" установлена взаимосвязь один ко многим, т.к. в журнале поставок может содержаться несколько товаров, это представлено на рисунке 4.

Рисунок 4

Взаимосвязь "многие ко многим".

Между двумя сущностями "Клиент" и "Журнал продаж" установлена взаимосвязь многие ко многим, т.к. в журнале продаж может содержаться несколько клиентов, а каждый клиент может совершить несколько покупок, это представлено на рисунке 5.

Рисунок 5

Между двумя сущностями "Поставщик" и "Журнал поставок" установлена взаимосвязь многие ко многим, т.к. в журнале поставок может содержаться несколько поставщиков, а каждый поставщик может совершить несколько поставок, это представлено на рисунке 6.

Рисунок 6

1.1.4 Задание первичных и альтернативных ключей

Сущность "Клиент" имеет первичный ключ "код клиента".

Сущность "Журнал продаж" имеет альтернативный ключ "код клиента", "код товара".

Сущность "Поставщик" имеет первичный ключ "код поставщика".

Сущность "Журнал поставок" имеет альтернативный ключ "код поставщика", "код товара".

Сущность "Товар" имеет первичный ключ "код товара".

1.1.5 Приведение модели к требуемому уровню нормальной формы

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

Первая нормальная форма.

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

менеджер визуальное программирование база

Схема:

Все наши таблицы находятся в 1 НФ, это представлено на рисунке 7.

Вторая нормальная форма.

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

Для того чтобы привести наши таблицы во 2 НФ мы в таблице "клиенты" создаем первичный ключ по полю "код клиента", в таблице поставщики создаем первичный ключ по полю "код поставщика", в таблице "товар" создаем первичный ключ по полю "код товара", в таблице "журнал продаж" создаем альтернативные ключи по полям "код клиента" и "код товара", в таблице "журнал поставок" создаем альтернативные ключи по полям "код поставщика" и "код товара". А также делаем взаимосвязи между таблицами. Это представлено на рисунке 7.

Рисунок 7

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

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

Модели этого уровня для реляционного подхода обычно не поддерживают сколь-нибудь развитую семантику межобъектных отношений, ограничиваясь, как правило, конструкциями "тип/подтип". С другой стороны логические схемы объектной БД могут иметь чуть более богатый аппарат учета смысловой окраски, обычно исчерпывающийся возможностями различать типы обобщения, ассоциации и наследования для связей. Логическая модель представлена на рисунке 8.

Рисунок 8

1.1.6. Физическое описание модели

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

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

В результате всех преобразований получается следующая физическая модель: Таблица pokypateli. dbf - предназначена для хранения информации о клиентах, структура данной таблицы представлена в таблице 4.

Таблица 4

Таблица postavsiki. dbf - предназначена для хранения информации о поставщиках, структура данной таблицы представлена в таблице 5.

Таблица 5

Таблица gyr_zak. dbf - предназначена для хранения информации о совершенных продажах, структура данной таблицы представлена в таблице 6.

Таблица 6

Таблица gyr_pos. dbf - предназначена для хранения информации о совершенных поставках, структура данной таблицы представлена в таблице 7.

Таблица 7

Таблица Tovar. dbf - предназначена для хранения информации о имеющемся в магазине товаре, структура данной таблицы представлена в таблице 8.

Таблица 8

2. Программный компонент

2.1 Структура проекта