Теоретические и практические аспекты разработки информационной системы

Дипломная работа по предмету «Информатика»
Информация о работе
  • Тема: Теоретические и практические аспекты разработки информационной системы
  • Количество скачиваний: 1
  • Тип: Дипломная работа
  • Предмет: Информатика
  • Количество страниц: 20
  • Язык работы: Русский язык
  • Дата загрузки: 2021-11-24 18:11:28
  • Размер файла: 734.95 кб
Помогла работа? Поделись ссылкой
Информация о документе

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

Если Вы являетесь автором текста представленного на данной странице и не хотите чтобы он был размешён на нашем сайте напишите об этом перейдя по ссылке: «Правообладателям»

Можно ли скачать документ с работой

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

ГЛАВА 2  ТЕОРИТИЧЕСКИЕ И ПРАКТИЧЕСКИЕ АСПЕКТЫ РАЗРАБОТКИ ИНФОРМАЦИОННОЙ СИСТЕМЫ


2.1 Разработка логической схемы модели БД информационной системы


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

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

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

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

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

Тип поля – определяет тип данных, которые могут содержаться в данном поле.

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

Формат поля – определяет способ форматирования данных в ячейках, принадлежащих полю.

Маска ввода – определяет форму, в которой вводятся данные а поле (средство автоматизации ввода данных).

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

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

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

Сообщение об ошибке – текстовое сообщение, которое выдается автоматически при попытке ввода в поле ошибочных данных.

Обязательное поле – свойство, определяющее обязательность заполнения данного поля при наполнении базы.

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

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

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

Логическая структура базы данных определяет:

• таблицы и их имена, также называемые сущностями (entities);

• имена полей, также называемые атрибутами (attributes) каждой таблицы;

• характеристики полей, например уникальность их значения и допустимость значений NULL, а также тип данных, хранимых в поле;

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

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

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

всех лиц, вовлеченных в проект.

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

2.2 Физическая реализация модели базы данных

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В своей базе данных я создал 8 таблиц, которые содержат сведения о товарах, поставщиках и их данных:

- Поставщик – представлены сведения о поставщиках;

- Предприятие – сведения организации Березка;

- Приходный ордер;

- Расходный ордер;

- Справочник банки – сведения о банках;

- Справочник Должности – сотрудники организации Березка;

- Справочник Представители;

- Товары – сведения о товарах.

Таблица «Предприятие» включает в себя 9 полей (рисунок 2.2).

Рисунок 2.2 – Таблица Предприятие


Таблица «Приходный ордер» состоит из 14 полей (рисунок 2.3).

Рисунок  2.3 – Таблица Приходный ордер


Таблица «Расходный ордер» состоит из 14 полей (рисунок 2.4).

Рисунок  2.4 – Таблица Расходный ордер



Таблица «Справочник Банки» состоит из 3 поля (рисунок 2.5).

Рисунок  2.5 – Таблица Справочник Банки


Таблица «Справочник Должности» состоит из 2 поля (рисунок 2.6).

Рисунок  2.6 –Таблица Справочник Должности


Таблица «Справочник Контрагенты» состоит из 12 полей (рисунок 2.7).

Рисунок  2.7 – Таблица Справочник Контрагенты


Таблица «Справочник  Представители» состоит из 11 полей (рисунок 2.8).

Рисунок  2.8 – Таблица Справочник «Представители»

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

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

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

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

Ниже приведен список форм, на основе которых реализован пользовательский интерфейс:

  1. Основная;
  2. Товар_Запрос;
  3. Товары1;
  4. Список товаров;
  5. Отчеты;
  6. Справочники;
  7. СправочникБанки;
  8. СправочникДолжности;
  9. СправочникПоставщики;
  10. СправочникПредставители;
  11. Поставщики;
  12. Предприятие;
  13. Касса;
  14. ПриходныйОрдер;
  15. РасходныйОрдер;
  16. О программе;

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

При нажатии кнопки «Товары» на форме «Главная» открывается форма «Товар_Запрос» (рисунок 2.28).

Рисунок 2.28 – Форма «Товар_Запрос»

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

При нажатии кнопки «По имени товара» на форме «Товар_Запрос» открывается диалоговое окно «Введите имя товара», где происходит поиск товара по имени.
При нажатии кнопки «По количеству товара» на форме «Товар_Запрос» открывается диалоговое окно «Введите количество товара», где нужно вводить параметр и затем происходит поиск нужного нам количества товара.
При нажатии кнопки «Список товаров» на форме «Товар_Запрос» открывается форма «Список товаров» (рисунок 2.30). На форме представлен список товаров и их производителей, также можно распечатать этот список.
Рисунок 2.30 – Форма «Список товаров»
При нажатии кнопки «Просмотр товаров по поставщикам» на форме «Товар_Запрос» открывается форма «Отчёты » (рисунок 2.31). На представленной форме можно просмотреть продукцию поставщиков в виде отчета.
Рисунок 2.31 – Форма «Отчёты»


При нажатии кнопки «Отчеты» на форме «Главная» открывается форма «Отчёты» (рисунок 2.31).

При нажатии кнопки «Справочники» на форме «Главная» открывается форма «Справочники» (рисунок 2.32).

Рисунок 2.32 – Форма «Справочники» 
При нажатии кнопки Справочник «Банки» на форме «Справочники» открывается форма «СправочникБанки». Представленная форма предназначена для ввода, вывода и редактирования данных о банках. Источником записей данной формы является таблица «СправочникБанки» и имеет поля: БИК, Кор. Счет, Название (рисунок 2.33).

Рисунок  2.33 – Форма «Справочник Банки»


При нажатии кнопки Справочник «Должности» на форме «Справочники» открывается форма «СправочникДолжности». Представленная форма предназначена для ввода, вывода и редактирования данных о должностях. Источником записей данной формы является таблица «СправочникДолжности» и имеет поле: Наименование должности (рисунок 2.34).

Рисунок  2.34 – Форма «СправочникДолжности»

При нажатии кнопки Справочник «Контрагенты» на форме «Справочники» открывается форма «СправочникПоставщики». Представленная форма предназначена для ввода, вывода и редактирования данных о поставщиках. Источником записей данной формы является запрос «ЗапросПоставщики» и имеет поля: Фирма партнер, Полное название фирмы, Адрес, ИНН, КПП, Код по ОКВЭД, Код по ОКПО, расчетный счет, Банк, Кор. Счет, БИК (рисунок 2.35).


Рисунок 2.35 – Форма «СправочникПоставщики»


При нажатии кнопки Справочник «Представители» на форме «Справочники» открывается форма «Справочник Представители». Представленная форма предназначена для ввода, вывода и редактирования данных о представителях.

Источником записей данной формы является таблица «СправочникПредставители» и имеет поля: Фамилия, Имя, Отчество, Должность, табельный номер, Адрес, ПаспортСерия, ПаспортНомер, ПаспортВыдан, ПаспортДатаВыдачи (рисунок 2.36).


Рисунок  2.36 - Форма «Справочник Представители»


При нажатии кнопки «Касса» на форме «Главная» открывается форма «Касса» (рисунок 2.37).


Рисунок 2.37 – Форма «Касса»


При нажатии кнопки «Приходный ордер» на форме «Касса» открывается форма «Приходный ордер». Представленная форма предназначена для ввода, вывода, редактирования и удаления данных по поступлению денежных средств. Источником записей данной формы является таблица «Приходный ордер» и имеет поля: Предприятие, Номер документа, Дата составления, Дебет, Код структурного подразделения, Корреспондирующий счет, Код аналитического учета, Код целевого назначения, Сумма, Принято от, Через кого, Основание, Приложение (рисунок 2.38).

При нажатии кнопки «Расходный ордер» на форме «Касса» открывается форма «Расходный ордер». Представленная форма предназначена для ввода, вывода, редактирования и удаления данных по поступлению денежных средств. Источником записей данной формы является таблица «Расходный ордер» и имеет поля: Расходный ордер №, от, Организация, Получил, Через кого, Код структурного подразделения, Корреспондирующий счет, Код аналитического учета, Кредит, Код целевого назначения, Сумма, Основание, Приложение (рисунок 2.39).

При нажатии кнопки «Справка» на форме «Главная» открывается форма «О программе» (рисунок 2.40). На представленной форме находятся сведения об авторе.

Отчеты

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

Отчеты и формы Access имеют много общего. Однако, в отличие от форм, отчеты не предназначены для ввода и правки данных в таблицах. Они позволяют лишь просматривать и печатать данные. В отчете невозможно изменить исходные данные с помощью элементов управления, как это можно сделать с помощью форм. Хотя в отчетах можно использовать такие же элементы управления для указания состояния переключателей, флажков и списков. Отчет, как и форма, может быть создан с помощью мастера. Разделы отчета подобны разделам формы и включают заголовок и примечание отчета, область данных, а также верхний и нижний колонтитулы. В примечание отчета часто помещают поля с итоговыми значениями. Элементы управления могут быть добавлены в отчет с помощью панели инструментов Панель элементов (Toolbox), идентичной той, что используется в режиме Конструктора форм. Форматирование и группировка элементов управления в отчете выполняются аналогично форматированию и группировке элементов управления в форме. Формы могут содержать подчиненные формы, а отчеты могут содержать подчиненные отчеты.[3].

В БД предусмотрены следующие отчеты (Приложение 3):

1. Атемарская птицефабрика;

2. Ичалковский сыр-завод;

3. Кондитерский завод;

4. Консервный завод;

5. Ликероводочный завод;

6. Масло-жировой комбинат;

7. ОАО Молоко;

8. Оброченский мясо-комбинат;

9. Пивзавод;

10. Ригли;

11. Хлебозавод №5;

12. Ялга холод;

13. Товары;

14. Поквартально.

 Для формирования отчета «Атемарская птицефабрика» щелкаем «Создание отчета с помощью мастера». Выбираем из списка «Запрос: Атемарская птицефабрика». Нажав кнопку « >> » выбираем все поля из запроса. Нажимаем кнопку «Далее >». Вид представления данных выбираем Наименование, это первый уровень группировки. Далее выбираем Дата поставки, это второй уровень группировки. Нажимаем «Далее >”. Нажав кнопку «Итоги…» ставим галочку на пересечении строки Сумма и столбца Sum и нажимаем «ОК». Кнопка «Далее >». Выбираем Блок и ориентацию бумаги книжная, «Далее >». Выбираем Строгий и кнопка «Далее >». Вводим имя отчета «Атемарская птицефабрика» и кнопка «Готово». Закрываем отчет. Нажав на данном отчете правую кнопку мыши выбираем Конструктор. Выбираем поле «Sum» примечании для группы `Товары` и примечании для группы `Название поставщика` и удаляем их. Ставим курсор в строку Итоги для материала и исправляем ее на =”Итого по товару “ & [Товары]. Поле =Sum[Сумма] приподнимаем выше чтобы была в одной строке Итого по товару. Также поступаем и со строкой Итоги для  поставщика. Поля уменьшаем и увеличиваем в длине. Поля Дата поставки и другие в свойствах выбираем выравнивание по центру. Ну и так далее производим изменения, что бы поля хорошо читались не наползали друг на друга и помещались все выводимые данные. Закрываем отчет и сохраняем изменения.

Также создаем отчеты предприятий, только выбираем не все поля из запроса, а только поля «Наименование», «Дата поставки», «Количество», «Цена» и «Сумма».

Создаем отчет «ПОКВАРТАЛЬНО». Для этого запускаем Создание отчета с помощью мастера, выбираем «таблицу: Товары». Из полей нажав кнопку «>>» выбираем все поля, кнопка «Далее >». Выбираем Товары и кнопка «Далее >». Выбираем уровень группировки по Дате поставки нажав это поле два раза левой кнопкой мыши. Нажимаем кнопку «Группировка» и выбираем интервал группировки по кварталам, и кнопка «ОК». Кнопка «Далее >». Сортировку выбираем по полю Дата поставки. Нажимаем кнопку «Итоги» и ставим галочку на пересечении строки Сумма и столбца Sum. Кнопка «ОК» и «Далее >». Вводим имя отчета «ПОКВАРТАЛЬНО» и кнопка «Готово». Закрываем отчет и открываем его в режиме конструктора и производим настройки.

Макросы

Основной набор средств Microsoft Access, который мы рассматривали выше, ориентирован на пользователей, не владеющих языками программирования. Для программистов же к этим средствам добавлены макросы (небольшие программы на языке макрокоманд системы Access) и модули (процедуры на языке Visual Basic for Application, VBA). С их помощью можно существенно расширить функциональные возможности создаваемого вами приложения и настроить его на нужды конкретных пользователей.[2].