Разработка информационной системы для автоматизации работы магазина автозапчастей

Оглавление Введение Глава 1. Теоретические основы разработки информационных систем

1.1 Информационные системы. Классификация информационных систем

1.2 Использования баз данных в информационных системах

1.3 Ms Access, как средство разработки информационных систем Глава 2. Проектирование и реализация информационной системы средствами MS Access

2.1 Анализ предметной области и функции решаемых задач

2.2 Анализ входной информации предметной области и выделение информационных объектов

2.2 Преобразование моделей в реляционную базу данных Заключение Список литературы

Введение

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

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

Многие из современных ИС при этом написаны на одном из языков создания динамических HTML-страниц (JSP, PHP, ASP и т. д.) и рассчитаны на функционирование в среде Интернет. Хранение данных таких систем в большинстве случаев осуществляется в базах данных СУБД MySQL. MySQL представляет собой бесплатную, мощную и надежную СУБД, использование которой даже в очень сложных проектах практически всегда оправдано.

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

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

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

Для достижения данной цели необходимо решить следующие задачи:

1. Теоретический анализ и обработка практической и методической литературы по теме исследования.

2. Анализ особенностей проблемы разработки информационной системы автомагазина.

3. Проектирование и реализация приемлемой для салона информационной системы средствами Access.

Глава 1. Теоретические основы разработки информационных систем

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

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

В 70-х — начале 80-х гг. информационные системы начинают широко использоваться в качестве средства управленческого контроля, поддерживающего и ускоряющего процесс принятия решений). Тoгдa пoявилacь кoнцeпция cиcтeм пoддepжки пpинятия peшeний (decision support systems — DDS). Эти cиcтeмы должны были oбecпeчить мeнeджepoв спeциaлизиpoвaннoй и интepaктивнoй пoддepжкoй пpoцeccoв принятия yникaльныx peшeний пpoблeм в peaльнoм, быcтpoизмeняющeмcя миpe.

К концу 80-х гг. концепция использования информационных систем вновь изменяется. Развитие мощности (быстродействия) микро-ЭВМ, пакетов прикладных программ и телекоммуникационных ceteй далo тoлчoк к пoявлeнию фeнoмeнa кoнeчнoгo пoльзoвaтeля (end user computing).Они становятся стратегическим источником информации и используются на всех уровнях организации любого профиля. Информационные системы этого периода, предоставляя вовремя нужную информацию, помогают организации достичь успеха в своей деятельности, создавать новые товары и услуги, находить новые рынки сбыта, обеспечивать себе достойных партнеров, организовывать выпуск продукции по низкой цене и многое другое.

Инфopмaциoнныe cиcтeмы, пpeднaзнaчeнныe для oбecпeчeния мeнeджepoв инфopмaциeй для пoддepжки принятия эффeктивныx peшeний, нaзывaютcя yпpaвлeнчecкими инфopмaциoнными cиcтeмaми (management information systems — MIS).

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

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

Классификация информационных систем.

1.Классификация информационных систем по признаку структурированности задач:

· Для структурированных задач;

· Для частично структурированных или неструктурированных задач:

1. Создающие управленческие отчеты;

2.Разрабатывающие альтернативные решения (модельные и экспертные).

2.Классификация информационных систем по функциональному признаку и уровням управления:

· производственные системы;

· системы маркетинга;

· финансовые и учетные системы;

· системы кадров (человеческих ресурсов);

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

3. Классификация по степени автоматизации:

· ручные

· автоматические

· автоматизированные

4.Классификация по характеру использования информации:

· Информационно-поисковые системы

· Информационно-решающие системы

· Управляющие ИС

· Советующие ИС

5. Классификация по сфере применения

· Информационные системы организационного управления

· ИС управления технологическими процессами (ТП)

· ИС автоматизированного проектирования (САПР)

· Интегрированные (корпоративные) ИС

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

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

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

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

Хотя этот подход далек от совершенства, он может работать, особенно для краткосрочных проектов. Если все будет сделано с достаточной тщательностью, то готовая база данных даже может функционировать, при условии небольшого объема хранящихся в ней данных и отсутствия необходимости в изменениях. Однако разработанные этим способом базы данных неизбежно будут испытывать серьезные проблемы с масштабируемостью, и по прошествии некоторого времени их будет чрезвычайно трудно изменить. Известно, что приложения, в конце концов, приходится изменять и даже полностью переписывать, чтобы добавить в них новые (или убрать устаревшие) функции; но при этом обычно нужно сохранить устаревшие данные. Значит, мы приходим к необходимости частичного перепроектирования «устаревшей» базы данных для добавления новых функций без риска потери каких-либо данных. Это ведет к снижению производительности, поскольку зачастую мы добавляем новые структуры базы данных (таблицы и представления), а также сложную логику SQL для представления устаревших и новых данных в рамках все того же интерфейса. Создание эффективной логической модели данных до выполнения любых реальных действий по разработке базы данных поможет предотвратить описанные проблемы и выяснить любые неучтенные требования на уровне данных до того, как будет написана хотя бы строка программного кода.

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

Строго говоря, реляционная база данных представляет собой упорядоченный набор таблиц, в которых хранятся данные. На практике база данных представляет собой набор таблиц, представлений и хранимых процедур (в зависимости от конкретной СУБД), которые хранят данные и выполняют с ними различные действия. Эти структуры определены при помощи встроенного языка программирования данной РСУБД, который обычно представляет собой один из диалектов языка SQL. Любая РСУБД хранит данные в файлах операционной системы и оснащена функциями по управлению файлами, управлению безопасностью и отладке производительности запросов, которые используются для манипуляций с данными. С точки зрения приложения, база данных — это место, откуда поступают данные.

В отличие от базы данных, модель данных не является представлением физического хранилища данных. Если база данных определяет способ хранения данных, способ использования реальных отношений между ними для манипулирования данными и обеспечивает программный доступ к данным, то модель данных просто перечисляет, какие данные существуют и как различные биты информации связаны между собой. Хорошо спроектированная модель данных, в конце концов, превращается в логическую схему разрабатываемой базы данных. По этой причине модели данных обязательно должны быть платформенно-независимыми; и любая модель данных может использоваться для создания физической базы данных в Oracle 10g, SQL Server 2005 или MySQL. И все же не следует думать, что при моделировании не нужно учитывать, с какой РСУБД будет работать приложение. В ряде ситуаций предварительная осведомленность о РСУБД, которая будет использоваться для управления базой данных, может повлиять на процесс моделирования данных.

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

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

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

Основные компоненты MS Access:

· построитель таблиц;

· построитель экранных форм;

· построитель SQL-запросов (язык SQL в MS Access не соответствует стандарту ANSI);

· построитель отчётов, выводимых на печать.

Они могут вызывать скрипты на языке VBA, поэтому MS Access позволяет разрабатывать приложения и БД практически «с нуля» или написать оболочку для внешней БД.

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

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

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

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

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

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

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

Основным свойством любого поля является его длина. Длина поля выражается в символах или, что-то же самое, в знаках. От длины поля зависит, сколько информации в нем может поместиться. Уникальным свойством любого поля является его имя и подпись. Подпись — это та информация, которая отображается в заголовке столбца. Ее не надо путать с именем поля, хотя если подпись не задана, то в заголовке отображается имя поля. Разным полям, например, можно задать одинаковые подписи. Разные типы полей имеют разное назначение и разные свойства.

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

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

Поля для ввода дат или времени имеют тип Дата/время.

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

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

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

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

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

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

Глава 2. Проектирование и реализация информационной системы средствами MS Access

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

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

Ассортимент имеющихся запасных частей в автомагазине приведен в таблице 1.

Таблица 1

Ассортимент предоставляемых запасных частей

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

Таблица 2

Поставщики

В качестве первичных документов для решения данной задачи используется:

Ассортимент предоставляемых запасных частей: (см. таблицу 3)

Таблица 3

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

Таблица 4

Список покупок: (см. таблицу 5)

Таблица 5

В данной работе допускаются следующие ограничения:

· возможна покупка одних и тех же автозапчастей у разных поставщиков;

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

Входную информацию делят на:

· условно — постоянную, сохраняющую свои значения на длительный период времени;

· постоянно меняющуюся оперативно — учетную информацию.

К условно — постоянной информации относятся:

· данные о всех автозапчастей;

· данные о поставщиках.

К постоянно меняющейся оперативно — учетной информации относятся:

· Данные о количестве, наименования закупаемых товаров;

· Данные о количестве проданного товара.

Перечень первичных документов представленных в виде таблицы 6:

Таблица 6

Выходную информацию представим в виде отчетной формы: (см. таблицу 7)

Таблица 7

Для получения этой формы используются данные первичных документов:

· ассортимент предоставляемых запасных частей;

· продажи.

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

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

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

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

2.2 Анализ входной информации предметной области и выделение информационных объектов Реквизитный состав первичных документов:

· Код товара

· Код поставщика

· Наименование

· отдел

· Количество

· Стоимость

· Код поставщика

· Поставщик

· Адрес

· Телефон

· Код товара

· Покупок

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

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

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

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

Код товара, покупок, дата покупки выдают нам информацию о том, какие товары были куплены.

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

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

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

Таблица 8

Информационные объекты и их реквизиты

Покажем на схеме 1 функционально зависимые реквизиты:

Схема 1

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

Ассортимент предоставляемых запасных частей:

· Код товара

· Код поставщика

· Наименование

· отдел

· Количество

· Стоимость Поставщики:

· Код поставщика

· Поставщик

· Адрес

· Телефон Продажи:

· Код товара

· Покупок

· Дата покупки В результате анализа получили 3 информационных объекта. Проведем по парный анализ связей между ними:

Поставщики Ассортимент предоставляемых запасных частей:

Тип связи: 1: М, так как закупать можно сразу несколько запасных частей для автомобиля. Связь между этими объектами обеспечивается с помощью реквизита: код поставщика.

Продажи Ассортимент предоставляемых запасных частей:

Тип связи: 1:1, так как у каждой запчасти свой код, своя цена, свой тип. Связь между этими объектами обеспечивается с помощью реквизита: код товара.

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

Информационно — логическая модель Схема 2

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

Схема3

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

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

Удачная разработка базы данных обеспечивает простоту ее поддержания.

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

База данных содержит 3 таблицы: «Поставщики», «Продажи», «Склад».

Рис. 1 Вид таблицы «Поставщики» в конструкторе Рис. 2 Вид таблицы «Продажи» в конструкторе Рис. 3 Вид таблицы «Ассортимент предоставляемых запасных частей» в конструкторе Сущности «Поставщики» объединены через сущность «Ассортимент предоставляемых запасных частей». Таким образом, сущность «Поставщики» связана с другими сущностями с отношением «один-ко-многим». Связи сущностей реализованных в Access представлены на рисунке 4.

Рис. 4 Информационно-логическая модель в Access

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

Рис. 5 Изменение связей Из данных искомых таблиц БД были реализованы пять запросов (см. рисунок 6).

Рис. 6 Запросы Примерами простых запросов являются запрос учета продаж по отделу грузовые. (Рисунок 7)

Рис. 7 Вид запроса в конструкторе Рис. 8 Результат запроса Примерами запроса с условием является запрос «Товары походящие к концу»

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

Рис. 11 Вид запроса в конструкторе Рис. 12 Результат запроса Примером запроса на сортировку является запрос «Учет продаж по отделу легковые «(см. рисунок 13)

Рис. 13 Вид запроса в конструкторе Рис. 14 Результат запроса Примерами запроса на вычисление данных являются запросы «Вычисление остатка товара»

Рис. 15 Вид запроса в конструкторе Рис. 16 Результат запроса Формы, которые можно создать средствами Microsoft Access, позволяют получать информацию, а так же корректировать ее в удобном для пользователя стиле. Microsoft Access позволяет создавать иерархические формы, в которых отображается информация из двух таблиц, связанных отношением «один — ко — многим». В случае необходимости иметь информацию о товарах и их производителе можно создать иерархическую форму. Для создания такой формы можно использовать мастер создания форм. Для корректировки вида формы используют режим «конструктора». Для сохранения, закрытия и выхода из Microsoft Access в форме используются соответствующие кнопки, созданные при помощи мастера создания кнопок. Данная форма представлена на рисунке 17.

Рис. 17 Главная форма Нужная форма выводится на экран исходя из действий пользователя, по нажатию на определенную кнопку из главной формы (см. риснок 17).

Рис. 18 Форма «Продажи»

Рис. 19 Форма «Остаток товара»

Рис. 20 Форма «Товары, подходящие к концу»

Рис. 21 Форма «Учет продаж (по отделу легковые)»

Рис. 21 Форма «Учет продаж (по отделу грузовые)»

Заключение

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

Разработанная система управления базой данных Access обладает следующими качествами:

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

· Удобный интерфейс, который позволяет с легкостью освоить управление базой данных.

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

· Позволяет быстро получить ответ на любой вопрос по запросу пользователя.

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

1. Гурвиц Г. А. Microsoft Access 2010. Разработка приложений на реальном примере.-СПб.:БХВ-Петербург, 2010. — 496 с.

2. Зирка М. О., Бухярова В., Коробкина Е., Кручинин Р. Базы данных. Расчетно — графические работы по информационным ситемам: Учебно-методическое пособие для студентов высших учебных заведений.- Егорьевск: ЕФ им.

3. Малыхина М. П. Базы данных: основы, проектирование, использование. — СПб.: БХВ — Петербург, 2004. — 512 с.

4. Марков А. С., Лисовский К. Ю. Базы данных.

Введение

в теорию и методологию: Учебник. — М.: Финансы и статистика, 2004. — 512 с.

5. Черемных С. В. и др. Моделирование и анализ систем. IDEF-технологии: практикум / С. В. Черемных, И. О. Семенов, В. С. Ручкин. — М.: Финансы и статистика, 2005. — 192 с.

6. Хомоненко А. Д., Цыганков В. М., Мальцев М. Г. Базы данных. Учебник для ВУЗов / Под ред. проф. А. Д. Хомоненко. — СПб.: КОРОНА-принт, 2000. — 416 с.