Файл: Проектирование реализации операций бизнес-процесса «Взаиморасчеты с поставщиками.pdf

- форма «Сальдо взаиморасчетов» для формирования и вывода информации о поступлении товаров и платежах по всем поставщикам по заданному периоду.

Состав файлов, необходимых для решения задачи:

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

- файл, содержащий информацию о товарах;

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

- файл, содержащий информацию об оплате поступивших товаров;

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

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

- файл, содержащий выходную информацию по карточке взаиморасчетов;

- файл, содержащий выходную информацию по сальдовой ведомости.

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

Обоснование проектных решений по программному обеспечению.

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

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

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

Проектная часть.

---

Информационная модель и ее описание.

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

Процесс проектирования данных можно условно разделить на два этапа: логическое моделирование и физическое проектирование. Результатом первого из них является так называемая логическая (или концептуальная) модель данных, выражаемая обычно диаграммой «сущность-связь» или ER (Entity-Relationship) диаграммой, которая представлена в одной из стандартных нотаций, принятых для отображения подобных диаграмм. Результатом второго этапа является готовая база данных либо DDL-скрипт для ее создания.
Логическая модель данных описывает факты и объекты, подлежащие регистрации в будущей базе данных. Основными компонентами такой модели являются сущности, их атрибуты и связи между ними. Как правило, физическим аналогом сущности в будущей базе данных является таблица, а физическим аналогом атрибута — поле этой таблицы. С логической точки зрения сущность представляет собой совокупность однотипных объектов или фактов, называемых экземплярами этой сущности. Физическим аналогом экземпляра обычно является запись в таблице базы данных. Как и записи в таблице реляционной СУБД, экземпляры сущности должны быть уникальными, то есть полный набор значений их атрибутов не должен дублироваться. И так же, как и поля в таблице, атрибуты могут быть ключевыми и неключевыми. На этапе логического проектирования для каждого атрибута обычно определяется примерный тип данных (строковый, числовой, BLOB и др.). Конкретизация происходит на этапе физического проектирования, так как различные СУБД поддерживают разные типы данных и ограничения на их длину или точность.

Одной из основных частей информационного обеспечения является информационная база, которая представляет собой совокупность данных, с помощью которых удовлетворяются информационные потребности управленческих процессов и решаемых задач. Разработка БД выполняется с помощью моделирования данных. Цель моделирования данных состоит в обеспечении разработчика ИС концептуальной схемой базы данных в форме одной модели или нескольких локальных моделей, которые относительно легко могут быть отображены в любую систему баз данных. Наиболее распространенным средством моделирования данных являются диаграммы "сущность-связь" (ERD). С помощью ERD осуществляется детализация накопителей данных DFD – диаграммы, а также документируются информационные аспекты бизнес-системы, включая идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их связей с другими объектами (отношений).

---

Сущность (Entity) — множество экземпляров реальных или абстрактных объектов (людей, событий, состояний, идей, предметов и др.), обладающих общими атрибутами или характеристиками. Любой объект системы может быть представлен только одной сущностью, которая должна быть уникально идентифицирована. При этом имя сущности должно отражать тип или класс объекта, а не его конкретный экземпляр (например, АЭРОПОРТ, а не ВНУКОВО). Сущность можно определить как объект, событие или концепцию, информация о которых должна сохраняться. сущности должны иметь наименование с четким смысловым значением, именоваться существительным в единственном числе, не носить "технических" наименований и быть достаточно важными для того, чтобы их моделировать. Именование сущности в единственном числе облегчает в дальнейшем чтение модели. Фактически имя сущности дается по имени ее экземпляра. Примером может быть сущности Заказчик (но не Заказчики!) с атрибутами Номер заказчика, Фамилия заказчика и Адрес заказчика. На уровне физической модели ей может соответствовать таблица Customer с колонками Customer_number, Customer_name и Customer_address. Каждая сущность должна быть полностью определена с помощью текстового описания. Каждая сущность может обладать любым количеством связей с другими сущностями модели.

Связь (Relationship) — поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области. Связь — это ассоциация между сущностями, при которой каждый экземпляр одной сущности ассоциирован с произвольным (в том числе нулевым) количеством экземпляров второй сущности, и наоборот.

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

- каждый экземпляр сущности-родителя может иметь ноль, один или более одного связанного с ним экземпляра сущности-потомка;

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

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

- каждый экземпляр сущности-родителя связан с некоторым фиксированным числом экземпляров сущности-потомка.

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

---

Связь с логической точки зрения представляет собой соотношение между сущностями, которое нередко может быть выражено обычными фразами, например: «Клиент размещает заказ» («A customer places an order» — этой фразой вполне можно описать связь, изображенную на рис. 1), где существительными являются названия связанных между собой сущностей. Подавляющее большинство средств проектирования данных позволяют создавать ER-диаграммы визуально, изображая сущности и соединяя их связями с помощью мыши. Интерфейс таких средств нередко настолько прост, что позволяет освоить логическое проектирование данных не только разработчику, но и пользователю-непрограммисту, если таковой участвует в проектировании данных как эксперт в предметной области.

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

Таблица 6

Сущности и атрибуты

Сущности	Атрибуты
Поставщики	Код поставщика Наименование Адрес ИНН Расчетный счет
Товары	Код товара Наименование Единица измерения
Накладные	Номер документа Дата Поставщик
Поступление товара	Накладная Товар Цена за единицу Количество
Оплата по накладной	Регистрационный номер Накладная Дата оплаты Сумма
Счета на оплату	Номер документа Дата Поставщик
Товары по счету	Счет Товар Цена за единицу Количество
Оплата по счетам	Регистрационный номер Счет Дата оплаты Сумма
Авансы	Регистрационный номер Поставщик Дата Сумма

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

- для сущности Поставщики атрибут Код поставщика,

- для сущности Товары атрибут Код товара,

- для сущности Накладные атрибут Номер документа,

- для сущности Поступление товара составной ключ: атрибуты Накладная, Товар,

- для сущности Оплата по накладной атрибут Регистрационный номер,

- для сущности Счета на оплату атрибут Номер документа,

- для сущности Товары по счету составной ключ: атрибуты Счет, Товар,

- для сущности Оплата по счетам атрибут Регистрационный номер,

- для сущности Авансы атрибут Регистрационный номер.

---

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

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

- неизменность,

- гарантированная уникальность,

- гибкость,

- эффективность.

Перечень связей между сущностями приведен в таблице 7.

Таблица 7

Связи и атрибуты

Связь	Атрибут связи
Поставщики и Накладные	Передают товар по накладным
Поставщики и Счета на оплату	Выставляют счета на оплату
Накладные и Поступление товара	Включают в себя перечень товаров
Накладные и Оплата по накладным	Оплачиваются
Товары и Поступление товара	Поступают по накладным
Счета на оплату и Товары по счету	Включают в себя перечень товаров
Счета и Оплата по счетам	Оплачиваются
Товары и Товары по счетам	Включены в счет
Поставщики и Авансы	Получают авансы

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

1. Каждая накладная в соответствии с принятой структурой может относиться только к одному поставщику, в то же время один поставщик может поставлять товары по нескольким накладным, кроме того, отдельные поставщики могут вообще не поставлять товар. Следовательно, для связи Поставщики – Накладные степень связи 1:n (один ко многим), класс принадлежности сущности Поставщики – необязательный, сущности Накладные – обязательный.

2. Каждый счет на оплату в соответствии с принятой структурой может относиться только к одному поставщику, в то же время один поставщик может выставлять несколько счетов, кроме того, отдельные поставщики могут вообще не выставлять счетов. Следовательно, для связи Поставщики – Счета на оплату степень связи 1:n (один ко многим), класс принадлежности сущности Поставщики – необязательный, сущности Счета на оплату – обязательный.

3. Каждое поступление товара в соответствии с принятой структурой может проводиться только по одной накладной, в то же время по одной накладной могут поступать несколько товаров. Следовательно, для связи Накладные – Поступление товара степень связи 1:n, класс принадлежности сущности Накладные – необязательный, сущности Поступление товара – обязательный.

---