База данных для автоматизации процесса расчетов с поставщиками (курсовая: программа (база данных Access) и пояснительная записка)


СОДЕРЖАНИЕ

ВВЕДЕНИЕ    3
1. ХАРАКТЕРИСТИКА И ОРГСТРУКТУРА ООО «ИНТРЕЙД»    5
2. ПРОЕКТИРОВАНИЕ И РЕАЛИЗАЦИЯ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ РАСЧЕТОВ С ПОСТАВЩИКАМИ В ООО «ИНТРЕЙД»    12
2.1. Постановка задачи    12
2.2. Инфологическая модель системы    13
2.3. Даталогическая модель системы    20
2.4. Физическая модель и реализация системы    21
ЗАКЛЮЧЕНИЕ    38
СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ    39

 

ВВЕДЕНИЕ

 

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

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

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

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

- изучить организационно-правовую структуру расчетов с поставщиками  в ООО «Интрейд»;

- спроектировать информационную систему расчетов с поставщиками  в ООО «Интрейд»;

- реализовать спроектированную информационную систему в СУБД Microsoft Access.

 

2. ПРОЕКТИРОВАНИЕ И РЕАЛИЗАЦИЯ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ РАСЧЕТОВ С ПОСТАВЩИКАМИ В ООО «ИНТРЕЙД»

2.1. Постановка задачи

 

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

Система должна обеспечить выполнение следующих основных функций:

  • ввод, хранение и редактирование информации по поставщикам, заказам, поступлениям по заказам и счетам на оплату;
  • вычисление задолженности перед определенным поставщиком по определенному заказу;
  • вычисление задолженности перед определенным поставщиком по всем заказам;
  • вычисление задолженности перед всеми поставщиками по определенному заказу
  • формирование отчётов.

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

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

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

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

Системные требования:

  1. ОС Windows XP и выше;
  2. СУБД Microsoft Access;
  3. оперативная память 64 Мб и выше;
  4. для хранения программы c исходной БД потребуется около 10 Мб на жестком диске (в зависимости от объема входящей информации размер рабочей базы данных может изменяться);
  5. набор стандартных средств ввода/вывода (клавиатура, мышь, монитор);
  6. для вывода на бумажный носитель отчетов рекомендуется наличие принтера.

 

2.2. Инфологическая модель системы

 

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

- инфологический уровень;

- концептуальный уровень;

- внешний уровень;

- внутренний уровень.

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

B зависимости от вида представления информации различают следующие типы схем:

- инфологическая схема, дающая общее информационно-логическое представление об информации предметной области;

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

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

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

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

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

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

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

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

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

 

Рисунок 2. Информационные потоки в системе расчета с поставщиками

 

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

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

2) Поставщик поставляет заказ и выставляет счет на оплату.

3) Счет имеет статус неоплачен до тех пор, пока не будет произведена оплата.

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

1. Поставщики.

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

2. Заказы.

Атрибут – Код заказа.

3. Сотрудники.

Атрибут – Код сотрудника.

4. Поступления по заказу (поставки).

Атрибут – Код поступления (поставки).

5. Счета на оплату.

Атрибут – Код счета.  Инфологическая модель БД, построенная с помощью языка Таблицы-связи, изображена на рисунке 3.

 

Рисунок 3. Инфологическая модель

 

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

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

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

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

 

2.3. Даталогическая модель системы

 

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

 

Рисунок 4. Даталогическая модель

 

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

2.4. Физическая модель и реализация системы

 

Система реализована посредством СУБД Microsoft Access.  Ниже перечислены основные свойства полей таблиц баз данных СУБД Microsoft Access.

  • Имя поля – определяет, как следует обращаться к данным этого поля при автоматических операциях с базой (по умолчанию имена полей используются в качестве заголовков столбцов таблиц).
  • Тип поля – определяет тип данных, которые могут содержаться в данном поле.
  • Размер поля – определяет предельную длину (в символах) данных, которые могут размещаться в данном поле.
  • Формат поля – определяет способ форматирования данных в ячейках, принадлежащих полю.
  • Маска ввода – определяет форму, в которой вводятся данные а поле (средство автоматизации ввода данных).
  • Подпись – определяет заголовок столбца таблицы для данного поля (если подпись не указана, то в качестве заголовка столбца используется свойство Имя поля).
  • Значение по умолчанию – то значение, которое вводится в ячейки поля автоматически (средство автоматизации ввода данных).
  • Условие на значение – ограничение, используемое для проверки правильности ввода данных (средство автоматизации ввода, которое используется, как правило, для данных, имеющих числовой тип, денежный тип или тип даты).
  • Сообщение об ошибке – текстовое сообщение, которое выдается автоматически при попытке ввода в поле ошибочных данных.
  • Обязательное поле – свойство, определяющее обязательность заполнения данного поля при наполнении базы.
  • Пустые строки – свойство, разрешающее ввод пустых строковых данных (от свойства Обязательное поле отличается тем, что относится не ко всем типам данных, а лишь к некоторым, например к текстовым).
  • Индексированное поле – если поле обладает этим свойством, все операции, связанные с поиском или сортировкой записей по значению, хранящемуся в данном поле, существенно ускоряются. Кроме того, для индексированных полей можно сделать так, что значение в записях будут проверяться по этому полю на наличие повторов, что позволяет автоматически исключить дублирование данных.

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

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

  • Текстовый – тип данных, используемый для хранения обычного неформатированного текста ограниченного размера (до 255 символов).
  • Числовой – тип данных для хранения действительных чисел.
  • Поле Мемо – специальный тип данных для хранения больших объемов текста (до 65 535 символов). Физически текст не хранится в поле. Он храниться в другом месте базы данных, а в поле храниться указатель на него, но для пользователя такое разделение заметно не всегда.
  • Дата/время – тип данных для хранения календарных дат и текущего времени.
  • Денежный - тип данных для хранения денежных сумм. Теоретически, для их записи можно было бы пользоваться и полями числового типа, но для денежных сумм есть некоторые особенности (например, связанные с правилами округления), которые делают более удобным использование специального типа данных, а не настройку числового типа.
  • Счетчик – специальный тип данных для уникальных (не повторяющихся в поле) натуральных чисел с автоматическим наращиванием. Естественное использование – для порядковой нумерации записей.
  • Логический - тип для хранения логических данных (могут принимать только два значения, например Да или Нет).
  • Гиперссылка – специальное поле для хранения адресов URL Web-объектов Интернета. При щелчке на ссылке автоматически происходит запуск броузера и воспроизведение объекта в его окне.
  • Мастер подстановок – это не специальный тип данных. Это объект, настройкой которого можно автоматизировать ввод данных в поле так, чтобы не вводить их вручную, а выбирать их из раскрывающегося списка.

Таблицы – это основные объекты любой базы данных. Во-первых, в таблицах хранятся все данные, имеющиеся в базе, а во-вторых, таблицы хранят и структуру базы (поля, их типы и свойства).

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

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

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

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

 

Рисунок 5. Входная и результатная информация системы

 

В системе необходимо создать 3 математические модели:

1) Математическая модель №1 оплаты по счету стоимости одного заказа для одного поставщика:

М.М.1 = Цена (за 1 единицу) * Количество (единиц)

2) Математическая модель №2 оплаты по счету стоимости всех заказов для одного поставщика:

М.М.2 = (Стоимость заказа № 1 + Стоимость заказа № 2 + …+ Стоимость заказа № N)

Где i – число заказов

3) Математическая модель №3 оплаты по счету стоимости всех заказов для всех поставщика:

М.М.3 = (Стоимость заказа № 1 + Стоимость заказа № 2 + …+ Стоимость заказа № N)

Где i – число заказов, j – число заказчиков

 

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

На рисунке 6 представлена физическая модель системы в виде схемы данных, созданной непосредственно в СУБД Access.

 

База данных для автоматизации процесса расчетов с поставщиками

Рисунок 6. Физическая модель системы

 

 

Заказать курсовую

 

Добавить комментарий


Защитный код
Обновить