Разработка регламента выполнения процесса «Складской учет» (Основные сведения теории проектирования баз данных)

Содержание:

Введение

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

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

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

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

Цель курсовой работы – разработать регламент выполнение процесса «Складской учет».

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

– провести анализ литературы с теории баз данных и информационных систем;

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

Объект исследования: торговое предприятие.

Предмет исследования: склад торгового предприятия.

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

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

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

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

1. Основные сведения теории проектирования баз данных

1.1. Основные понятия теории баз данных

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

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

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

2. Значения всех атрибутов должны принадлежать одному типу.

3. Каждое поле имеет уникальное имя.

4. Каждая запись в таблице есть уникальной.

5. Последовательность записей и полей в таблице не является существенной.

Отношение – это важнейшее понятие и представляет собой двумерную таблицу, которая содержит некоторые данные.

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

Атрибуты – это свойства, что характеризуют сущность. В таблице каждый атрибут имеет название и ему соответствует заголовок столбца таблицы.

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

Рассмотрим следующее свойство ключа – неизбыточность – никакое из собственных подмножеств некоторого множества Н не обладает свойством уникальности.

Каждое отношение имеет комбинацию атрибутов, что может служить некоторым ключом. Ее существование гарантируется одним из принципов РМД.

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

Ключи используют для достижения таких следующих целей:

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

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

1.2. Структура базы данных

БД должна предоставить доступ к данным всем пользователям, включая даже тех, которые практически не имеют или не хотят иметь хоть какое-то представления о:

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

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

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

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

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

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

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

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

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

Архитектура каждой базы данных состоит из следующих уровней:

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

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

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

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

2. Проектирование базы данных для складского учета товарного предприятия

2.1. Описание предметной области и проходящих в ней процессов

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

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

Основными функциями кладовщика являются:

– прием товара на склад;

– выдача и хранение различных материальных ценностей;

– обеспечение сохранности всех складируемых ТМЦ;

– соблюдение режимов хранения, которые предотвращают порчу и потерю ТМЦ;

– перемещение ТМЦ к местам хранения с сортировкой по видам, качеству и другим признакам.

Функции заведующего складом:

– контроль работы по приему и рациональному размещению ТМЦ на складе;

– организация проведения транспортировочных работ на складе при соблюдении правил охраны труда и техники безопасности;

– обеспечение сохранности складируемых ТМЦ;

– соблюдение режимов хранения ТМЦ;

– ведение складского учета.

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

– неэффективное использование оборудования или технических ресурсов;

– дефицит площадей;

– высокие затраты на хранение или обработку грузов;

– невысокое качество обслуживания клиентов.

Препятствия на пути повышения эффективности учета складских операций можно разделить на 4 группы:

– организационные;

– технологические;

– информационные;

– технические.

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

1. Рассмотрение технологических процессов на складе (логистическая экспертиза).

2. Создание объемно-планировочных решений, проектирование технологии работы складских помещений.

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

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

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

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

Одновременно с приемкой, оприходованием товаров менеджер производит оприходование товаров в информационной системе.

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

– трудности при идентификации товаров;

– неравномерная нагрузка на складские помещения;

– приемка по копиям накладных, не приспособленным для записи дополнительной информации;

– недостача подъемно-транспортной техники;

– недостача вместимости зоны для размещения и приемки поступающего товара;

– двойной ввод данных о приходе;

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

– товар может хаотично складироваться в зоне напольного хранения.

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

2.2. Исследование экономической эффективности разработки

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

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

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

2) Прямого эффекта, что описывается, в основном, снижением трудовых показателей.

К показателям труда относятся:

 абсолютное снижение затрат на труд (ΔТ). которое рассчитывается по формуле: ΔТ=Т0 – Т1,

где Т0 - трудовые затраты по обработке данных по базовому варианту, Т1 - трудовые затраты по обработке данных по проектному варианту.

Рассчитаем абсолютное снижение трудовых затрат.

– 7 часов в день составляют затраты труда на обработку данных по базовому варианту. Рассчитаем сколько часов на месяц составляют затраты труда на обработку данных по базовому варианту:

7 часов/день * 24 раб. дня = 168 часов/месяц

Узнаем сколько составляют затраты труда в часах в год:

168 часов/месяц * 12 месяцев = 2016 часов/год.

То есть, Т0 = 2016 часов/год составляют затраты труда на обработку данных по базовому варианту.

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

3 часов/день * 24 рабочих дня = 72 часов/месяц.

Затем узнаем сколько составляют затраты труда в часах в год:

72 часов/месяц * 12 месяцев =1728 часов/год.

То есть, Т1 = 1728 часов/год составляют затраты труда на обработку данных по предлагаемому варианту.

Получим, что Т0 = 2016 часов/год, Т1 = 1728 часов /год, можно посчитать абсолютное снижение затрат труда в часах в год:

ΔТ = 2016 - 1728 = 288 часов/год.

 коэффициент относительного снижения затрат труда (КЗТ) рассчитывается по формуле

(2)

Подставив данные в формулу, получим, что КТ = 14,3% - коэффициент относительного снижения затрат труда.

 индекс снижения затрат труда или повышение производительности труда (ППT) рассчитывается по формуле:

(3)

В результате:

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

2.3. Инфологическое проектирование БД складского учета

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

Проблема представления семантики интересовала давно разработчиков, и в 70-х годах было рассмотрено модель "сущность—связь", предложенную японским ученым Ченом (ER-диаграмма в нотации Чена).

В базе будут фигурировать следующие сущности с указанием полей:

Товары:

– Код товара;

– Название товара;

– Срок хранения.

Заявки:

– Код заявки;

– Название организации;

– Код товара;

– Требуемое количество.

Склад:

– Код товара;

– Количество;

– Дата поступления.

Отпуск товаров:

– Код заявки;

– Код товара;

– Отпущенное количество;

– Дата отпуска товара.

Создадим ER-диаграмму в нотации Чена (рисунок 3).

Рисунок 1 – ER-диаграмма в нотации Чена

2.4. Логическое проектирование БД складского учета

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

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

Таблица 1 – Описание таблиц

№ п/п	Название поля	Ключ	Тип данных
Таблица «Отпуск товаров»
1	Код заявки	+	Числовой
2	Код товара	+	Числовой
3	Отпущенное количество		Числовой
4	Дата отпуска товара		Дата/время
Таблица «Заявки»
1	Код заявки	+	Числовой
2	Название организации		Текстовый
3	Код товара	+	Числовой
4	Требуемое количество		Числовой
Таблица «Товары»
1	Код товара	+	Числовой
2	Название товара		Текстовый
3	Срок хранения		Числовой
Таблица «Склад»
1	Код товара	+	Числовой
2	Количество		Числовой
3	Дата поступления		Дата/время

2.5. Выбор среды проектирования

Для создания БД будет использоваться СУБД Access.

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

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

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

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

Поскольку MS Access не является клиент - серверной СУБД, то его возможности по обеспечению работы нескольких пользователей ограничены.

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

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

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

В первую очередь отметим распространенность, что обусловлена принадлежностью СУБД компании Microsoft, операционные системы и программное обеспечение которой использует множество пользователей ПК. MS Access абсолютно совместим с ОС Windows, постоянно обновляется, поддерживает различные языки.

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

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

Также Access обладает большими возможностями по экспорту/импорту данных в разнообразные форматы через механизм ODBC: от текстовых файлов и таблиц Excel до любой серверной СУБД.

Еще одним немаловажным преимуществом MS Access является встроенные средства разработки приложений. Большое количество приложений, которые распространяемые среди пользователей, содержат некоторый объем кода языка Visual Basic for Applications.

VBA – единственное средство для выполнения различных стандартных задач в MS Access (построение команд SQL, обработка ошибок, работа с переменными, использование Windows API), для создания сложных приложений.

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

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

3.Физическое проектирование БД для складского учета

3.1. Создание базы данных MS Access

Рассмотрим процесс создания таблицы в СУБД MS Access 2013, а именно с помощью конструктора таблиц.

После запуска СУБД и создания базы данных нужно нажать на ленту «Создание» и выбрать в разделе «Таблицы» Конструктор таблиц (рис.2.)

Рисунок 2 – Выбор конструктора таблиц.

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

Рисунок 3 – Таблица Товары в режиме конструктора

Аналогичным образом создаются остальные таблицы.

Стоит отметить, что после формирования структуры таблицы (наименований полей и определение их типов). Нужно определить ключевое поле. Поскольку в ключевом поле должны находится уникальные данные, то, например, для таблицы «Товары» им будет поле «Код товара».

Для установки индексированного поля в разделе свойств нужно использовать пункт «Индексированное поле». Оно имеет 3 варианта значений: да (допускаются совпадения), нет, да (не допускаются совпадения). Как показано на рис.5. поле «Код товара» индексированное (совпадения не допускаются).

Рассмотрим процесс установки связей между таблицами. Для этого необходимо открыть окно «Схема данных», добавить все таблицы. После этого нужно перетащить определенные поля одно на другое. В результате этого откроется окно которое показано на рисунке 4:

Рисунок 4 – Обеспечение целостности данных при связывании таблиц

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

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

Рисунок 5 – Схема данных

Далее перейдем к вводу данных в таблицы. Заполненные данными таблицы примут такой вид (рис. 6 - 9):

Рисунок 6 – Заполненная таблица Заявки

Рисунок 7 – Заполненная таблица Склад

Рисунок 8 – Заполненная таблица Отпуск товаров

Рисунок 9 – Заполненная таблица Товары

3.2. Реализация объектов информационной системы

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

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

Создадим запрос на выборку на основе таблицы Склад, который будет отображать товары, что есть в количестве от 50 до 200 единиц. Для этого нужно на ленте Создать выбрать Запросы → Конструктор запросов. Откроется окно, в которое нужно добавить таблицу Склад и выбрать поля Код товара, Количество, Дата поступления (рис.12):

Рисунок 10 – Запрос Количество в режиме конструктора

Рисунок 11 – Запрос Количество в режиме просмотра

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

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

Для создания параметрического запроса необходимо в строке Условие отбора поля Дата поступления ввести выражение: [Введите дату]

Рисунок 12 – Запрос с параметром в режиме конструктора

Нажав на кнопку Запуск откроется диалоговое окно, куда необходимо ввести дату (рис.15):

Рисунок 13 – Диалоговое окно запроса с параметром

Просмотрим результат выполнения запроса (рис.14):

Рисунок 14 – Запрос с параметром в режиме просмотра

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

Внешний вид окна конструктора запросов показан на рис. 15:

Рисунок 15 – Запрос Количество (параметр) в режиме конструктора

После запуска появится диалоговое окно вида (рис.16):

Рисунок 16 – Диалоговое окно параметрического запроса

Для введенного значения результат выполнения запроса показан на рис. 17:

Рисунок 17 – Запрос Количество (параметр) в режиме просмотра

Формы – элемент базы данных для удобного отображения или ввода данных.

Стоит отметить, что формы бывают одиночные (на основе одной таблицы) и составные или сложные (на основании нескольких таблиц). Также выделяют подчиненные формы – это многотабличные формы, которые созданы на основании таблиц, которые объединены связью «один – ко - многим».

Создадим форму для связанных таблиц «Товары» - «Заявка».

Для построения формы на основе двух таблиц нужно выделить таблицу «Товары», выполнить команду Создание – Форма, создается Макет вложенных форм, где форма по таблице «Товары» - главная, по таблице «Заявка» - подчиненная (встроенная в главную) (рис.18):

Рисунок 18 – Форма Товары

Аналогичным образом строятся и остальные формы.

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

Построим отчет для таблицы Товары. Для этого вызовем мастер создания отчетов (Создание – Отчеты – Мастер отчетов). Далее нужно:

– выбрать таблицу «Товары» и переместить поля в категорию Выбранные;

– в уровень группировки выбрать поле Название товара;

– выполним сортировку по полю Название товара;

– отметим макет Структура, ориентация Книжная и нажмем кнопку далее;

– в последнем окне задаем имя Отчета.

В результате получим отчет, показанный на рис. 19:

Рисунок 19 – Отчет Товары в режиме просмотра

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

Рисунок 20 – Кнопочная форма

На форме два столбца кнопок. Кнопки для открытия форм и отчетов разрабатываются с использованием макросов. Все они создаются аналогично. Рассмотрим создание макроса для открытия таблицы формы Склад.

Для этого нужно нажать на ленте Создание кнопку Макрос и в открывающемся списке выбрать макрокоманду открыть таблицу. Далее в поле таблица нужно выбрать таблицу товары и сохранить макрос.

После создания всех макросов нужно создать пустую форму в режиме конструктора, разместить с помощью панели управления надписи и кнопки, а потом с помощью панели свойств назначить макросы кнопкам (рис. 21):

Рисунок 21 – Назначения события по нажатию на кнопку

Заключение

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

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

– проанализировано литературу по теории реляционных баз данных;

• рассмотрено основные понятия теории баз данных, описано типичную архитектуру СУБД и модели данных;
• описано характеристику СУБД MS Access;
• выполнено проектирование ИС;
• разработано ИС для складского учета предприятия.

В процессе анализа вышеизложенной информации выявлены следующие достоинства рассмотренной ИС:

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

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

1. Балдин, К.В. Информационные системы в экономике: Учебное пособие / К.В. Балдин. - М.: НИЦ ИНФРА-М, 2013. - 218 c.
2. Блиновская, Я.Ю. Введение в геоинформационные системы: Учебное пособие / Я.Ю. Блиновская, Д.С. Задоя. - М.: Форум, НИЦ ИНФРА-М, 2013. - 112 c.
3. Бодров, О.А. Предметно-ориентированные экономические информационные системы: Учебник для вузов / О.А. Бодров. - М.: Гор. линия-Телеком, 2013. - 244 c.
4. Варфоломеева, А.О. Информационные системы предприятия: Учебное пособие / А.О. Варфоломеева, А.В. Коряковский, В.П. Романов. - М.: НИЦ ИНФРА-М, 2013. - 283 c.
5. Васильков, А.В. Информационные системы и их безопасность: Учебное пособие / А.В. Васильков, А.А. Васильков, И.А. Васильков. - М.: Форум, 2013. - 528 c.
6. Мартынова В.П. Базы данных. Распределенные и удаленные БД. Т.1: Учебник/В.П. Мартынова.–М.:ИД ФОРУМ,НИЦ ИНФРА-М, – 2013. – 272 c.
7. Мартынова В.П. Базы данных. Распределенные и удаленные БД. Т.1 / В.П. Мартынова.– М.: ИД ФОРУМ,НИЦ ИНФРА-М,2013. – 352 c.
8. Ракован О.Л. Базы данных / О.Л. Ракован – М.:Форум, 2004. – 352 c.
9. Ракован О.Л.Базы данных: Учебное пособие/О.Л. Ракован. - М.:Форум, 2012.–400 c.
10. Малевич И.П. Базы данных:Учебное пособие /И.П. Малевич. - СПб.:Питер, 2013.– 240 c.
11. Кирилов В.В. Введение в реляционные базы данных./В.В. Кирилов.–СПб.: БХВ-Петербург, 2012.–464 c.
12. Кошепелев В.Е. Базы данных в ACCESS 2007: Эффективное использование /В.Е. Кошепелев.–М.: Бином-Пресс, 2009.–592 c.
13. Кузина А.В. Базы данных:Учебное пособие для студентов высш. учеб. заведений /А.В. Кузина.– М.: ИЦ Академия, 2012.–320 c.
14. Ливенар С.В. Материалы базы данных "Пакет кадровика"/С.В. Ливенар.–М.: ИНФРА-М, 2008.–51 c.
15. Пирогова В.Ю. Информационные системы и базы данных: организация и проектирование: Учебное пособие/В.Ю. Пирогова.–СПб.: БХВ-Петербург, 2009.–528 c.