Информационно-справочная система 'Автосалон'

ИНФОРМАЦИОННО-СПРАВОЧНАЯ СИСТЕМА «АВТОСАЛОН»

СОДЕРЖАНИЕ

Задание на курсовое проектирование

Введение

1.    ИНФОРМАЦИОННЫЕ СИСТЕМЫ

1.1        Информационные системы и базы данных

.2          Обоснование выбора системы управления базой данных

.3          Характеристика моделей данных

.4          Язык запросов SQL

2.    Проектирование базы данных по продаже автомобилей

2.1        Описание и постановка задачи

.2          Построение информационной модели

.3          Проектирование базы данных

2.3.1            Определение объектов базы данных

2.4        Разработка базы данных по продаже автомобилей в Microsoft Access. Начальный этап создания БД

2.4.1            Нормализация модели представления данных

.4.2              Этапы разработки и создания таблиц

.4.3              Организация связей между таблицами

.4.4              Создание форм базы данных

.4.5              Создание отчётов базы данных

2.5        Описание работы базы данных и организация доступа к данным

Заключение

Список использованной литературы

Приложение 1. РЕЗУЛЬТАТЫ ВЫПОЛНЕНИЯ ЗАПРОСОВ БАЗЫ ДАННЫХ

Приложение 2. ОТЧЁТЫ БАЗЫ ДАННЫХ

Задание на курсовое проектирование

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

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

Для продавцов необходимо предусмотреть возможность ввода сведений о новых поступлениях и удаления сведений о проданных автомобилях.

Введение

Анализ сбыта и методов продвижения товаров от фирм-производителей до конечных потребителей является неотъемлемой частью организации сбыта продукции на предприятиях. Повышение эффективности реализации продукции на основе повышения качества функционирования фирм-посредников за счёт использования информационных технологий является актуальным направлением развития рыночных отношений. Эта тема актуальна для современных рыночных условий и является темой данной курсовой работы в применении к внедрению информационных систем (ИС) в автосалон по продаже автомобилей японских и корейских фирм-производителей.

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

Для достижения поставленной цели были решены следующие задачи, определившие структуру работы:

·   охарактеризованы возможности использования информационных технологий в сфере продаж;

·        проанализирована деятельность автосалона «Автомир» и разработана ИС «Автосалон».

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

1.       ИНФОРМАЦИОННЫЕ СИСТЕМЫ

1.1     Информационные системы и базы данных

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

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

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

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

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

В курсовой работе решается задача построения БД для автосалона «Автомир». Автосалон является посредником при перепродаже автомобилей японских и корейских фирм. Здесь требуется найти наиболее эффективный способ ведения информации о постоянных клиентах, о поставляемых и продаваемых автомобилей. Фирме необходимо решать задачи регистрации заказов, расчёта стоимости, выставления счетов, учёта платежей клиентов и др. Разработанная база данных будет описана во второй главе.

1.2     Обоснование выбора системы управления базой данных

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

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

MS Access из всех рассматриваемых средств разработки имеет самый богатый набор визуальных средств. Главное качество Access, которое привлекает к нему многих пользователей, - тесная интеграция с Microsoft Office. К примеру, скопировав в буфер графический образ таблицы, открыв Microsoft Word и применив вставку из буфера, мы тут же получим в документе готовую таблицу с данными из БД.

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

Встроенный SQL позволяет максимально гибко работать с данными и значительно ускоряет доступ к внешним данным.

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

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

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

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

1.3     Характеристика моделей данных

Хранимые в базе данные имеют определенную логическую структуру, т.е. модель. Различают следующие основные модели представления данных в БД:

- иерархическую;

-        сетевую;

         реляционную;

         объектно-ориентированную.

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

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

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

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

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

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

К недостаткам можно отнести трудность использования реляционных моделей для некоторых современных приложений. Названная проблема решается расширением реляционных моделей в объектно-реляционные.

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

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

1.4 Язык запросов SQL

Запрос представляет собой специальным образом описанное требование, определяющее состав производимых над БД операций по выборке и ли модификации хранимых данных. Для подготовки запросов с помощью M’ Access используется язык запросов SQL (Structured Query Language). Структурированный язык запросов SQL основан на реляционном исчислении с переменными кортежами. SQL предназначен для выполнения операций над таблицами (создание, удаление, изменение структуры ) и над данными таблиц (выборка, изменение, добавление и удаление), а также некоторых сопутствующих операций. SQL является непроцедурным языком и не содержит имеющихся в обычных языках программирования операторов управления, организации подпрограмм, ввода-вывода и т.д.

В связи с этим SQL автономно не используется, а обычно погружен в среду встроенного языка программирования СУБД, в нашем случае в MS. Access.

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

Рассмотрим важнейший оператор - оператор SELECT, который будет использован при проектировании и работы БД. В упрощённом виде оператор имеет следующий формат:

SELECT [ALL/DISTINCT]<список данных> <список таблиц>

[WHERE<условие выбора>]

[GROUP BY <имя столбца>,[имя столбца]…]

[HAVING <условие поиска>]

[ORDER BY <спецификация сортировки>,[<спецификация сортировки>]…]

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

2.       Проектирование базы данных по продаже автомобилей

2.1     Описание и постановка задачи

информационный система база данные

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

Рис. 2.1. Структурная схема бизнес - процесса

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

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

·   сотрудники;

·        клиенты (покупатели);

·        поставщики;

·        каталог (прайс лист);

·        автомобили;

·        заказы (поставка и продажа);

·        цена.

На основании данных компонентов можно получить список основных бизнес процессов, происходящих в автосалоне, а именно:

·   составление каталога;

·        рассылка каталога;

·        анализ рынка;

·        продажи;

·        оформление счетов и накладных;

·        управление работой персонала;

·        реклама;

·        решение бухгалтерских задач.

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

Упрощенная организационная структура автосалона "Автомир" представлена на рисунке 2.2. и позволяет определить кто выполняет бизнес процессы.

Рис. 2.2. Организационная структура фирмы

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

·   обновление каталога - периодически (раз в месяц);

·        подведение итогов продаж - ежемесячно;

·        годовой отчет - ежегодно к 20 февраля.

Выполнение вышеуказанных действий в бизнес процессе позволяют определить мотивацию производственной деятельности автосалона. Бизнес задачи автосалона "Автомир" определяются как:

·   достижение наилучшего соотношения «затраты - удобство» для клиентов;

·        обеспечение условий для успешной деятельности персонала;

·        получение приемлемой прибыли;

·        повышение доходов при автоматизации обработки данных.

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

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

Цель работы дилера: продажа автомобилей по каталогу.

Функции дилера:

·   Заключение договоров на продажу автомобиля.

·        Ведение каталога автомобилей, предлагаемых на продажу.

·        Прием заказов у клиентов (покупателей) на покупку автомобилей.

·        Работа с клиентами (маркетинг): подготовка сведений о приобретаемых машинах, анализ продаж, ведение справочника клиентов.

·        Ведение расчетов за проданные автомобили (выписка счетов).

Требования к программе:

Программа должна работать под управлением операционных систем Windows 9х и выше.

Перечень вводимой информации детализируется до необходимого количества.

Требования к оснащению офиса автосалона компьютерной техникой:

·        ПЭВМ не ниже Pentium 100/16/420 с операционной системой Windows 9х и выше и пакетом программ MS Office.

·        лазерный или струйный принтер.

2.2     Построение информационной модели

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

Рис. 2.3. Диаграмма взаимосвязей между безнес компонентами и бизнес процессами (ER - диаграмма)

В практике проектирования информационных систем такие схемы получили название ER-диаграмм (Entity-relationship diagram (ERD) - диаграмма «Сущность-связь»). ER-диаграммы хорошо вписываются в методологию структурного анализа и проектирования информационных систем. Такие методологий обеспечивают строгое и наглядное описание проектируемой системы, которое начинается с ее общего обзора и затем уточняется, давая возможность получить различную степень детализации объекта с различным числом уровней.

Логическая модель данных предметной области (бизнес компонентами) обеспечивает разработчикам понимание структур данных. После её разработки следует приступать к моделированию физической структуры систем хранения выявленных объектов данных, то есть к разработке физической модели данных.

2.3     Проектирование базы данных

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

q Быстрый доступ к данным;

q   Отсутствие дублирования (повторения) данных;

q   Целостность данных.

Проектирование структуры данных отражает логику работы БД. При проектировании структур данных можно выделить три основных подхода:

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

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

.        Структурирование информации в процессе проведения системного анализа на основе совокупности правил и рекомендаций.

Процесс создания непосредственно БД обычно включает следующие этапы:

Ø проектирование БД;

Ø  создание файла проекта БД;

Ø  создание БД (формирование и связывание таблиц, ввод данных);

Ø  создание меню приложения;

Ø  создание запросов;

Ø  создание экранных форм, отчётов;

Ø  генерация приложения как исполняемой программы.

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

2.3.1  Определение объектов базы данных

Объектом называется элемент информационной системы, информацию о котором мы сохраняем. В реляционной теории баз данных объект называется сущностью.

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

Классом объектов называют совокупность объектов, обладающих одинаковым набором свойств.

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

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

Атрибут - это информационное отображение свойств объекта. Каждый объект характеризуется рядом основных атрибутов.

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

·   машины;

·        поставщики;

·        клиенты;

·        сотрудники;

·        поставки заказ;

·        сделки;

·        заказы;

·        цена;

·        описание покупки;

·        описание продажи.

2.4     Разработка базы данных по продаже автомобилей в Microsoft Access

При работе в автосалоне, была спроектирована и разработана в Microsoft Access база данных по продаже автомобилей японских и корейских фирм: Toyota, Lexus, Mitsubishi, Honda, Kia, Hyundai и др. Система управления базами данных Microsoft Access, входящий в состав пакета Microsoft Office, позволяет быстро создавать приложения различной степени сложности на основе технологий визуального программирования. В качестве базовой модели была выбрана реляционная БД. При проектировании основное внимание уделялось наглядности ввода, представления и обработки информации.

Как известно, основными элементами БД являются: таблицы, ключи и индексы, и связи между таблицами.

Таблицы, образующие БД, предназначены для хранения различного рода информации и хранятся в файлах. Каждая таблица БД состоит из строк - записей и столбцов - полей и содержит информацию об объекте одного типа, а совокупность всех таблиц образует единую БД. Каждое поле имеет уникальное в пределах таблицы имя (56, С. 48). Поле содержит данные одного из допустимых типов, например, строкового, целочисленного или даты. При вводе значения в поле таблицы БД автоматически производится проверка соответствия типа значения и типа поля.

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

Организация связи между таблицами осуществляется для обеспечения целостности БД. Для связывания таблиц используются поля связи (совпадающие поля). Поля связи при этом должны быть индексированными.

Структура Microsoft Access кроме этого позволяет отдельно создавать SQL запросы на требуемую выборку из таблиц, формы, отчёты и кроме этого страницы, макросы, модули.

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

Начальный этап создания БД

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

2.4.1     Нормализация модели представления данных

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

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

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

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

Дальнейшая реализация заключается в основном в исключении аномалии дублирования данных.

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

·        Первая нормальная форма - удаление повторяющихся групп.

·        Вторая нормальная форма - удаление избыточных данных.

·        Третья нормальная форма - удаление атрибутов, не зависящих от первичного ключа.

·        Четвертая нормальная форма - изоляция независимых множественных отношений.

·        Пятая нормальная форма - изоляция семантически связанных множественных отношений.

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

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

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

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

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

Чтобы атрибуты Имя-Имя в табл. 2.1 не повторялись, следует создать отдельную сущность для каждого набора атрибутов; в результате появятся новые сущности.

Таблица 2.1.

Ненормализованная сущность

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

Таблица 2.2

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

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

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

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

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

Таблица 2.3.

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

Третья нормальная форма

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

В табл. 2.4 изображена база данных в третьей нормальной форме. Подчинённость таблиц определена цветами.

Таблица 2.4

Третья нормальная форма

Правильность данных в реляционных базах обеспечивается набором правил. Правила целостности данных делятся на четыре категории:

         Целостность сущностей. Каждая запись сущности должна обладать уникальным идентификатором и содержать данные.

         Целостность доменов. Каждый атрибут принимает лишь допустимые значения.

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

         Пользовательские правила целостности. Любые правила целостности, не относящиеся ни к одной из перечисленных выше категорий.

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

Преобразование логической модели в физическую

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

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

·        Каждая таблица должна иметь уникальный идентификатор (первичный ключ).

·        Все данные таблицы должны относиться к одной сущности.

·        Желательно избегать атрибутов, способных принимать неопределенные значения.

·        Таблица не должна содержать повторяющихся полей.

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

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

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

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

2.4.2  Этапы разработки и создания таблиц

Модель реализована в СУБД Microsoft Access 2002. В соответствии с изложенным выше, физическая модель состоит из семи таблиц, описание полей которых приведены в таблице 2.1.

На основе проведённого анализа было принято решение о создании следующих таблиц: машины, поставщики, клиенты, сотрудники, поставки заказ, сделки, заказы, цена, описание покупки, описание продажи (см. рис. 2.4.) с полями совпадающими с атрибутами (табл. 2.2.).

Между таблицами будут определены соответствующие связи.

Рис. 2.4. Таблицы базы данных

Каждая таблица соответственно содержит подробную информацию об объекте. Рассмотрим содержание каждой таблицы.

Таблица МАШИНЫ

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

Рис. 2.5. Таблица - МАШИНЫ

Таблица ПОСТАВЩИКИ

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

Поле «Код поставщика» является ключевым.

Рис. 2.6. Таблица ПОСТАВЩИКИ

Таблица КЛИЕНТЫ

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

Рис. 2.7. Таблица КЛИЕНТЫ

Таблица СОТРУДНИКИ

Данная таблица содержит информацию о сотрудниках автосалона. Структура таблицы и содержание полей представлены на рис. 2.8. Ключевым полем является «Код сотрудника». Основную информацию о сотруднике представляют поля «Фамилия», «Имя», «Должность», «Домашний телефон» и «Рабочий телефон».

Рис. 2.8. Таблица СОТРУДНИКИ

Таблица ПОСТАВКИ ЗАКАЗ

Таблица ПОСТАВКИ ЗАКАЗ, структура которой представлена на рис. 2.9, позволяет узнать об оформлении заказа на поставку, а конкретно об описании заказа, поставщике, сотруднике, дате размещения, дате исполнения и типе операции. Поле «Код поставки» является ключевым, «Код поставщика» и «Код сотрудника» являются индексными (внешние ключи таблицы).

Рис. 2.9. Таблица ПОСТАВКИ ЗАКАЗ

Таблица СДЕЛКИ

Таблица СДЕЛКИ, (см. рис. 2.10), представлена информацией о дате операции, автомобиле, поставке, об описании операции, заводской цене и общей сумме. Поле «Код операции» является ключевым, «Код машины» и «Код поставки» являются индексными (внешние ключи таблицы).

Рис. 2.10. Таблица СДЕЛКИ

Таблица ЗАКАЗЫ

Информация о заказах на покупку автомобиля клиентами записывается в таблицу ЗАКАЗЫ (рис. 2.11). Поле «Код заказа» является ключевым, а поля «Код клиента», «Код машины» и «Код типа продажи» являются индексными.

Рис. 2.11. Таблица ЗАКАЗЫ

Таблицы ЦЕНА, ОПИСАНИЕ ПОКУПКИ и ОПИСАНИЕ ПРОДАЖИ содержат информацию о цене автомобиля и типе операции (заказано, поставлено, возврат) при покупке и продаже (в наличии, продано, возврат) соответственно.

2.4.3  Организация связей между таблицами

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

Схема взаимосвязей между атрибутами в модели приведена на рисунке 2.12. После определения содержания таблиц и их создания в Microsoft Access в разделе ОБЪЕКТЫ - подпункт «таблицы», были организованы непосредственные связи между таблицами. Для создания связей необходимо было установить соответствие величин одной таблицы величинам из другой таблицы. Связи между таблицами были организованы через ключевые поля родительской таблицы (внешний ключ) с соответствующим ему полем дочерней таблицы (рис. 2.12). Эти поля имеют одинаковые имена. Процесс создания связей был осуществлён в диалоговом окне «Схема данных» панели инструментов главного окна Access или выполнить команду меню Сервис/Схема данных (Tools/Relationships) в соответствии с табл. 2.4.

Рис. 2.12. Связи между таблицами

При связывании таблиц выделенное поле в одной таблице перетаскивалось и накладывалось на соответствующее поле в другой. При этом открывается диалоговое окно "Изменение связей", где задаются параметры связи.

2.4.4  Создание форм базы данных

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

Построение главной кнопочной формы

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

Рис. 2.13. Главная кнопочная форма

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

Подсистема продажи:

     данные о клиентах - позволяет вводит информацию о клиентах с целью последующего оформления заказа;

-        все автомобили - выполняется запрос на автомобили, которые проходили по заказам;

         автомобили в наличии - получаем список автомобилей проходящих по заказам - или не оплачены или возвращены;

         оформить заказ - осуществляется запуск формы для оформления заказа;

-        прайс лист - представляется информация о марке автомобиля и его стоимости.

Подсистема анализа:

-        популярность моделей - подсчёт количества проданных автомобилей;

         график - зависимость количества автомобилей от их марки;

         заказы за день - текущие заказы;

         отчёт по заказам за день;

         работа сотрудников - количество сделок по поставке автомобилей.

Подсистема поставки:

     поставщики - информация о фирме-поставщике;

     отчёт о поставщиках;

     данные о сотрудниках - информация о сотрудниках;

     отчёт о сотрудниках;

     добавление автомобиля и изменение цены продажи - возможность внесения в БД новой марки автомобиля и установка цены продажи;

     оформить заказ на поставку - форма оформления заказа.

В нижнем колонтитуле расположена кнопка выхода из формы.

По нажатию кнопки "Данные о клиентах" в области форма "Подсистема продажи" появляется форма, изображённая на рис. 2.14.

Рис. 2.14. Форма ввода данных о клиентах

После ввода соответствующих данных и нажатии кнопки  Сохранить, информация записывается в таблицу КЛИЕНТЫ. Аналогичным образом можно записать информацию при нажатии кнопок "Поставщики", "Данные о сотрудниках" и "Добавление автомобиля и изменение цены продажи" подсистемы поставки. На рис. 2.15 представлены формы, открывающиеся при активизации данных кнопок.

Рис. 2.15 Формы подсистемы поставок

Формы позволяют изменять данные в базе так же легко, как и вводить. Чтобы отредактировать поле, следует перейти к нему и с помощью клавиатуры внести необходимые изменения.

Если для нажатия используется клавиатура (например, клавиши <Tab> или <Enter>), то при переходе выделяется всё поле. Теперь нажатие любой клавиши удалить содержимое поля и подготовит его к вводу новых данных.

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

Формы оформления заказов

Поле "Подсистема продажи" содержит кнопку "Оформить заказ", при нажатии на которую появляется форма, изображенная на рис. 2.16. В процессе оформления заказа имеется возможность выбора клиента из списка клиентов уже занесённых в БД, которые содержаться в поле со списком. Аналогичные операции можно проделать и с выбором автомобиля, который необходимо внести по желанию клиента.

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

Рис. 2.16. Форма оформления заказа на продажу автомобиля

Для правильного ввода и наглядности на форме имеется возможность просмотреть данные об автомобилях, проходивших по заказам, путём нажатия кнопок "Все автомобили", "Автомобили в наличии" и "Проданные автомобили", расположенных внизу в поле "Сведения о машинах". Например, на рис. 2.17 представлен результат выполнения запроса по нажатию кнопки "Все автомобили".

Рис. 2.17 Автомобили, проходящие по заказам

Для оформления заказа на поставку автомобиля от фирмы поставщика необходимо в подсистеме поставки, расположенной на главной форме (2.13) нажать кнопку "Оформить заказ на поставку". Форма, открываемая по данному событию, представлена на рис. 2.18.

Рис. 2.18 Форма оформления заказа на поставку автомобиля

Здесь заносятся данные о фирме поставщике и сотруднике фирмы, ответственным за выполнение операции. Внизу формы располагается подчинённая таблица СДЕЛКИ, позволяющая выбирать тип автомобиля при нажатии на поле "Код машины", ввода заводской цены и цены поставки с автоматическим расчётом итоговой суммы сделки. Имеется возможность ввода даты и типа операции (заказано, поставлено, возврат)

Создание запросов

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

         запросы на все автомобили, оставшиеся и проданные, проходящие по заказам;

Текст запроса на все автомобили:Заказы.КодМашины, Машины.МаркаАвтомобиля, Машины.СерийныйНомер, Таблица_описание_продажи.ОписаниеПродажиТаблица_описание_продажи INNER JOIN (Машины INNER JOIN Заказы ON Машины.КодМашины = Заказы.КодМашины) ON Таблица_описание_продажи.КодТипПродажи = Заказы.КодТипПродажи;

         запрос на популярность автомобилей;

Текст запроса:DISTINCTROW Машины.МаркаАвтомобиля, First(Таблица_описание_продажи.ОписаниеПродажи) AS [First - ОписаниеПродажи], Count(*) AS [Count - Таблица_описание_продажи]Таблица_описание_продажи INNER JOIN (Машины INNER JOIN Заказы ON Машины.КодМашины = Заказы.КодМашины) ON Таблица_описание_продажи.КодТипПродажи = Заказы.КодТипПродажиBY Машины.МаркаАвтомобиля(((First(Таблица_описание_продажи.ОписаниеПродажи))='продано'));

         запрос на количество заказанных автомобилей за рабочий день.

Текст данного запроса:Заказы.КодМашины, Машины.МаркаАвтомобиля, Машины.СерийныйНомер, Заказы.Дата