Разработка базы данных с использованием средств Microsoft Access для автоматизации процедур учета и формирования заказов на предприятии ООО "Озон"

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Содержание

Введение

1. Анализ и выбор метода решения задачи автоматизации системы учета заказов на предприятии ООО «Озон»

1.1 Анализ существующей на предприятии системы учета заказов

1.2 Инфологическая модель задачи автоматизации заказов

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

1.4 Выбор методики и технических средств реализации базы данных

2. Разработка базы данных по учету заказов на ООО «Озон» с использованием пакета Microsoft Access

2.1 Процедура проектирования реляционной базы данных

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

2.3 Разработка форм для обработки информации в базе данных

2.4 Разработка механизма оформления заказов в базе данных

2.5 Разработка средств анализа в базе данных ООО «Озон»

Заключение

Список использованной литературы

Введение

автоматизация заказ данный форма

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

В настоящее время можно отметить, что акцент в развитии информационных технологий (далее сокращение ИТ) смещается в сторону улучшения взаимоотношений с клиентами, и продолжает усовершенствоваться класс интеллектуальных информационных технологий. Интеллектуальные программные системы способны непрерывно извлекать новые знания и изменять свою структуру и функции, развиваться и адаптироваться вместе с предприятием к решаемым задачам и условиям внешней среды. Один из путей решения этой задачи - применение мультиагентных систем (далее МАS - Multiagent Systems), получивших стремительное развитие в последнее десятилетие. Технологии управления взаимоотношениями с клиентами (Customer Relationship Management) в настоящее время представляют собой удобный информационный инструмент и позволяют выработать эффективную технологию работы с клиентами. На первый взгляд две данные технологии находятся на разных полюсах, как по своей сложности, так и по своей направленности и специфике. Однако при более детальном рассмотрении можно сказать, что в перспективе их методологии могут быть рассмотрены как взаимодополняющие.

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

Задачами работы являются:

-- анализ системы документооборота на ООО «Озон»;

-- построение инфологической модели учета заказов;

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

-- практическая разработка программного комплекса учета и контроля заказов средств Microsoft Access;

-- анализ надежности созданного программного продукта;

-- оценка экономической эффективности мероприятий по внедрению на фирме разработанного программного комплекса.

1. Анализ и выбор метода решения задачи автоматизации системы учета заказов на предприятии ООО «Озон»

1.1 Анализ существующей на предприятии системы учета заказов

ООО «Озон» - компания, специализирующаяся на оптовой и розничной продаже фармацевтической продукции.

Объемы продаж имеют устойчивую тенденцию к росту, постоянно расширяется география как клиентов, так и поставщиков предприятия. В 2011 году было реализовано продукции на 244 млн. руб., что составило 145600 выполненных заказов. Это на 8,6 % больше, чем в предыдущем, 2010 году.

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

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

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

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

Наиболее слабыми местами в данной схеме работы являются:

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

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

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

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

1.2 Инфологическая модель задачи автоматизации заказов

Для обработки поступающих от клиентов заказов, контроля состояния склада и формирования заказов поставщикам менеджеры ООО «Озон» используют значительное количество информационных данных. В настоящее время менеджеры по работе с клиентами зачастую собирают о клиентах (особенно оптовых покупателях) довольно значительный объем данных, но можно выделить те атрибуты, которые в обязательном порядке используются всеми менеджерами - именно они и должны лечь в основу разрабатываемой базы данных предприятия по учету заказов. Итак, как легко видеть из рисунка 1.4., стержневыми сущностями в данной информационной системе являются: ПОСТАВЩИК; КЛИЕНТЫ; СОТРУДНИКИ

Нам также потребуется сущность ТОВАРЫ, которая является обозначающей для сущности ПОСТАВЩИК.

Для характеристики сущности КЛИЕНТЫ используется сущность ЗАКАЗ, поскольку заказ возникает только после того, как один из клиентов оформит его на фирме. Эта же сущность используется для характиристики и другой стержневой сущности - СОТРУДНИКИ, т.к. именно сотрудники выполняют все действия, связанные с обслуживанием полученного заказ.

Между сущностями ТОВАРЫ и ЗАКАЗ существует связь, являющаяся ассоциативной сущностью ЗАКАЗАНО. Она представлена связью «многие - ко многим», поскольку один Заказ может содержать несколько наименований Товаров, а один и тот же Товар входить в разные Заказы.

Концептуальная модель предметной области представлена на рисунке 1.4.

1 м м 1

Рисунок 1.4. - Концептуальная модель задачи учета заказов на ООО «Озон»

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

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

Название поставщика (все поставщики - фирмы или частные предприниматели, имеющие фирменное наименование)

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

Город поставщика

Область поставщика

Индекс поставщика

Страна поставщика

Телефон поставщика (с кодом страны или региона)

Факс поставщика (с кодом страны или региона)

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

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

Далее рассмотрим обозначающую сущность ТОВАРЫ. Ей присущи следующие обязательные атрибуты:

Наименование товара

Единица измерения товара

Цена товара

Наличие товара на складе (данный атрибут должен выражаться неотрицательным целым числом)

Возможность заказать товар у Поставщика (данный атрибут проще всего представить в логической форме - поставки прекращены или есть возможность заказа товара).

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

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

Рассмотрим стержневую сущность КЛИЕНТЫ. По сути, это база клиентов, разместивших заказы на фирме. Атрибутами сущности являются:

Название клиента

Контактное лицо по заказу (особенно это важно при работе с крупными заказчиками, фирмами).

Адрес клиента

Город клиента

Область клиента

Индекс клиента

Страна клиента

Телефон клиента (с кодом страны или региона)

Факс клиента (с кодом страны или региона)

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

Важной стержневой сущностью базы данных является сущность СОТРУДНКИ, с помощью которой ведется база работников предприятия, заносится вся необходимая информация о сотруднике. Необходимыми атрибутами данной сущности являются:

Фамилия, имя и отчество сотрудника

Пол сотрудника

Должность сотрудника

Дата рождения сотрудника

Адрес сотрудника

Город сотрудника

Область сотрудника

Индекс сотрудника

Страна сотрудника (атрибуты 5-9 существенны, поскольку сотрудники ООО «Озон» работают и в других городах и даже за рубежом)

Домашний телефон сотрудника (с кодом страны или региона)

Мобильный телефон сотрудника (с кодом страны или региона)

Общие сведения о сотруднике

Уникальный идентификационный номер сотрудника, являющийся также и ключом данной сущности.

Сущность ЗАКАЗ является характеристикой сущностей КЛИЕНТЫ и СОТРУДНИКИ. Её атрибутами являются:

Уникальный код клиента, разместившего заказ

Уникальный код сотрудника, обслуживающего заказ

Дата размещения заказа

Название получателя заказа (поскольку получатель не всегда совпадает с клиентом, т.е. лицом, разместившим заказ)

Адрес получателя

Город получателя

Индекс получателя

Область получателя

Страна получателя

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

Последней сущностью, которую следует проанализировать, является ассоциативная сущность ЗАКАЗАНО. Её атрибутами являются:

Код заказанного товара

Цена товара в заказе

Количество товара в заказе

Предоставленная скидка

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

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

ПОСТАВЩИКИ(КодПоставщика, Название, Адрес, Город, Область, Индекс, Страна, Телефон, Факс)

ТОВАРЫ (КодТовара, Наименование, КодПоставщика, ЕдиницаИзмерения, Цена, НаСкладе, ПоставкиПрекращены) [ПОСТАВЩИКИ]

ЗАКАЗ (КодЗаказа, КодКлиента, КодСотрудника, ДатаРазмещения, НазваниеПолучателя, АдресПолучателя, ГородПолучателя, ИндексПолучателя, ОбластьПолучателя, СтранаПолучателя) {КЛИЕНТЫ, СОТРУДНИКИ}

СОТРУДНИКИ (КодСотрудника, ФИО, Пол, Должность, ДатаРождения, Адрес, Город, Область, Индекс, Страна, ДомашнийТелефон, Мобильный Телефон, Примечание)

ЗАКАЗАНО [Товары М, Заказы N] (КодЗаказа, КодТовара, Цена, Количество, скидка)

КЛИЕНТЫ (КодКлиента, Название, ОбращатьсяК, Адрес, Город, Область, Индекс, Страна, Телефон, Факс)

Теперь мы можем построить инфологическую модель базы данных по учету заказов на ООО «Озон» с использованием описанного в предыдущем параграфе языка ER-диаграмм:

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Рисунок 1.5. -

Инфологическая модель базы данных ООО «Озон»

Размещено на http://www.allbest.ru/

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

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

Теперь о внешних ключах:

- Если сущность С связывает сущности А и В, то она должна включать внешние ключи, соответствующие первичным ключам сущностей А и В.

- Если сущность В обозначает сущность А, то она должна включать внешний ключ, соответствующий первичному ключу сущности А.

Связь между первичными и внешними ключами сущностей иллюстрируется рисунке 1.6:

Рисунок 1.6. - Структуры: а - ассоциации; б - обозначения (характеристики)

В построенных выше стержневых сущностях выделены атрибуты, описывающие внешние ключи. Очевидно, что ни один из них не может принимать неопределенное значение, являясь фактически номером соответствующего экземпляра сущности. Построенные выше сущности имеют только одну ассоциацию: сущность ЗАКАЗАНО. Её первичный ключ представляет собой сочетание внешних ключей, которыми являются атрибуты КодЗаказа и КодТовара, принадлежащие соответственно сущностям ТОВАРЫ и ЗАКАЗ. В случае с сущностями-обозначениями и характеристиками (это сущности ТОВАРЫ и ЗАКАЗ) их первичные ключи КодТовара и КодЗаказа соответственно, а среди атрибутов встречаются КодПоставщика и КодКлиента и КодСотрудника, относящиеся к сущностям-описаниям (характеризуемым сущностям) ПОСТАВЩИКИ и КЛИЕНТЫ-СОТРУДНИКИ. Таким образом, соблюдены все требования, предъявляемые к первичным ключам сущностей и к их внешним ключам. Подведем итоги, описав для используемых сущностей процедуры работы с первичными и внешними ключами в случае изменения содержания базы данных. Необходимо ответить на следующие вопросы:

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

2. Что должно случиться при попытке УДАЛЕНИЯ целевой сущности, на которую ссылается внешний ключ? Например, при удалении поставщика, который осуществил, по крайней мере, одну поставку.

Существует три возможности:

КАСКАДИРУЕТСЯ	Операция удаления "каскадируется" с тем, чтобы удалить также поставки этого поставщика.
ОГРАНИЧИВАЕТСЯ	Удаляются лишь те поставщики, которые еще не осуществляли поставок. Иначе операция удаления отвергается.
УСТАНАВЛИВАЕТСЯ	Для всех поставок удаляемого поставщика NULL-значение внешний ключ устанавливается в неопределенное значение, а затем этот поставщик удаляется. Такая возможность, конечно, неприменима, если данный внешний ключ не должен содержать NULL-значений.

Что должно происходить при попытке ОБНОВЛЕНИЯ первичного ключа целевой сущности, на которую ссылается некоторый внешний ключ? Например, может быть предпринята попытка обновить номер такого поставщика, для которого имеется, по крайней мере, одна соответствующая поставка. Имеются те же три возможности, как и при удалении:

КАСКАДИРУЕТСЯ	Операция обновления "каскадируется" с тем, чтобы обновить также и внешний ключ в поставках этого поставщика.
ОГРАНИЧИВАЕТСЯ	Обновляются первичные ключи лишь тех поставщиков, которые еще не осуществляли поставок. Иначе операция обновления отвергается.
УСТАНАВЛИВАЕТСЯ	Для всех поставок такого поставщика NULL-значение внешний ключ устанавливается в неопределенное значение, а затем обновляется первичный ключ поставщика. Такая возможность, конечно, неприменима, если данный внешний ключ не должен содержать NULL-значений.

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

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

NULL-значения не допустимы

УДАЛЕНИЕ ИЗ (цель) КАСКАДИРУЕТСЯ

ОБНОВЛЕНИЕ (первичный ключ цели) КАСКАДИРУЕТСЯ

Указанные спецификации представляют зависимость по существованию характеристических сущностей. В ситуации с рассмотренными выше сущностями базы данных ООО «Озон» имеют место следующие общие наблюдения:

Сущность ПОСТАВЩИКИ *( Стержневая сущность )

ПЕРВИЧНЫЙ КЛЮЧ ( КодПоставщика )

ПОЛЯ (КодПоставщика, Название, Адрес, Город, Индекс,Страна,Телефон, Факс);

Сущность СОТРУДНИКИ *( Стержневая сущность )

ПЕРВИЧНЫЙ КЛЮЧ ( КодСотрудника )

ПОЛЯ (КодСотрудника, ФИО, Пол, Должность, ДатаРождения, Адрес, Город, Индекс,Страна,ДомашнийТелефон, МобильныйТелефон, Примечания);

Сущность КЛИЕНТЫ *( Стержневая сущность )

ПЕРВИЧНЫЙ КЛЮЧ ( КодКлиента )

ПОЛЯ (КодКлиента, Название,ОбращатьсяК, Адрес, Город, Область,Индекс, Страна, Телефон, Факс);

Сущность ТОВАРЫ *( Обозначение )

ПЕРВИЧНЫЙ КЛЮЧ ( КодТовара )

ВНЕШНИЙ КЛЮЧ ( КодПоставщика ИЗ ПОСТАВЩИКИ

NULL-значения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ ПОСТАВЩИКИ ОГРАНИЧИВАЕТСЯ

ОБНОВЛЕНИЕ ПОСТАВЩИКИ.КодПоставщика ОГРАНИЧИВАЕТСЯ)

ПОЛЯ (КодТовара, КодПоставщика, Наименование, ЕдиницаИзмерения, Цена, НаСкладе, ПоставкиПрекращены)

ОГРАНИЧЕНИЯ ( Значения полей КодПоставщика должны принадлежать набору значений соответствующих полей сущности ПОСТАВЩИКИ; при нарушении вывод предупреждающего сообщения);

Сущность ЗАКАЗ *( Характеризует СОТРУДНИКИ и КЛИЕНТЫ )

ПЕРВИЧНЫЙ КЛЮЧ ( КодЗаказа )

ВНЕШНИЙ КЛЮЧ ( КодКлиента ИЗ КЛИЕНТЫ

NULL-значения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ КЛИЕНТЫ ОГРАНИЧИВАЕТСЯ

ОБНОВЛЕНИЕ КЛИЕНТЫ.КодКлиента КАСКАДИРУЕТСЯ)

ВНЕШНИЙ КЛЮЧ ( КодСотрудника ИЗ СОТРУДНИКИ

NULL-значения ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ СОТРУДНИКИ ОГРАНИЧИВАЕТСЯ

ОБНОВЛЕНИЕ СОТРУДНИКИ.КодСотрудника КАСКАДИРУЕТСЯ)

ПОЛЯ ( КодЗаказа,КодКлиента, КодСотрудника, ДатаРазмещения, НазваниеПолучателя, АдресПолучателя, ГородПолучателя, ИндексПолучателя,ОбластьПолучателя, СтранаПолучателя )

ОГРАНИЧЕНИЯ ( Значения поля КодКлиента должны принадлежать набору значений соответствующего поля сущности КЛИЕНТЫ, значение поля КодСотрудника либо пусто,либо принадлжит набору значений соответствующего поля сущности СОТРУДНИКИ; при нарушении вывод сообщения);

Сущность ЗАКАЗАНО *( Связывает ТОВАРЫ и ЗАКАЗЫ )

ПЕРВИЧНЫЙ КЛЮЧ ( КодЗаказа, КодТовара )

ВНЕШНИЙ КЛЮЧ ( КодЗаказа ИЗ ЗАКАЗЫ

NULL-значения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ ЗАКАЗЫ ОГРАНИЧИВАЕТСЯ

ОБНОВЛЕНИЕ ЗАКАЗЫ.КодЗаказа КАСКАДИРУЕТСЯ)

ВНЕШНИЙ КЛЮЧ ( КодТовара ИЗ ТОВАРЫ

NULL-значения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ ТОВАРЫ ОГРАНИЧИВАЕТСЯ

ОБНОВЛЕНИЕ ТОВАРЫ.КодТовара КАСКАДИРУЕТСЯ)

ПОЛЯ ( КодЗаказа,КодТовара, Цена,Количество, Скидка )

ОГРАНИЧЕНИЯ ( Значения полей КодЗаказа и КодТовара должны принадлежать набору значений соответствующих полей сущностей ЗАКАЗЫ и ТОВАРЫ; при нарушении вывод сообщения);

1.4 Выбор методики и технических средств реализации базы данных

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

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

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

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

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

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

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

Рисунок 1.7. - Схема обработки информации в БД по принципу клиент-сервер

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

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

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

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

Реляционная модель ориентирована на организацию данных в виде двумерных таблиц. Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами:

- каждый элемент таблицы - один элемент данных;

- все столбцы в таблице однородные, т.е. все элементы в столбце имеют одинаковый тип (числовой, символьный и т.д.) и длину;

- каждый столбец имеет уникальное имя;

- одинаковые строки в таблице отсутствуют;

- порядок следования строк и столбцов может быть произвольным.

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

1.5 Обоснование выбора СУБД и средств разработки прикладного программного обеспечения

Логически в современной реляционной СУБД можно выделить наиболее внутреннюю часть - ядро СУБД (часто его называют Data Base Engine), компилятор языка БД (обычно SQL), подсистему поддержки времени выполнения, набор утилит. В некоторых системах эти части выделяются явно, в других - нет, но логически такое разделение можно провести во всех СУБД. Ядро СУБД отвечает за управление данными во внешней памяти, управление буферами оперативной памяти, управление транзакциями и журнализацию. Ядро СУБД обладает собственным интерфейсом, не доступным пользователям напрямую и используемым в программах, производимых компилятором SQL (или в подсистеме поддержки выполнения таких программ) и утилитах БД. Ядро СУБД является основной резидентной частью СУБД. При использовании архитектуры «клиент-сервер» ядро является основной составляющей серверной части системы. Основной функцией компилятора языка БД является компиляция операторов языка БД в некоторую выполняемую программу. Основной проблемой реляционных СУБД является то, что языки этих систем являются непроцедурными, т.е. в операторе такого языка специфицируется некоторое действие над БД, но эта спецификация не является процедурой, а лишь описывает в некоторой форме условия совершения желаемого действия. Поэтому компилятор должен решить, каким образом выполнять оператор языка прежде, чем произвести программу. Требования, предъявляемые к современным СУБД:

Поддержка определённой логической модели данных.

Наличие встроенных языковых средств, в том числе:

а) язык определения данных - Data Definition Language(DDL).

б) языки манипулирования данных - Data Manipulation Language(DML).

в) язык запросов - Query Language(QL).

Наличие графического интерфейса, в котором можно выделить: интерфейс пользователя(User Interface), интерфейс разработчика(Developer Interface), интерфейс администратора(Administrator Interface).

Наличие подсистемы словаря данных и системного каталога.

Наличие программных средств контроля целостности данных.

Наличие средств разграничения доступа к данным.

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

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

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

- панель инструментов позволяет быстро выполнять команды создания, открытия и управления объектами базы данных;

- полоса объектов, предназначенная для просмотра объектов БД. Ее вертикальное расположение более удобно в использовании;

- ярлыки в окне базы данных ускоряют создание объектов с помощью Мастеров или открытие новых объектов в режиме Конструктора:

- настройка способов выбора и открытия объектов в окне базы данных;

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

- поддерживается блокировка на уровне записей в дополнение к обычной блокировке, которая блокировала все записи на 4-кбайтной странице;

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

- возможен просмотр и редактирование связанных записей в режиме таблицы (subdatasheet);

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

- поддержка 16-разрядного стандарта кодировки символов Unicode;

- использование Microsoft ActiveX Data Objects (ADO) для доступа и манипулирования данными в базах данных сервера.

Microsoft Access предоставляет максимальную свободу в задании типа ваших данных (текст, числовые данные, даты, время, денежные значения, рисунки, звук, документы, электронные таблицы). Можно задать также форматы хранения и представления этих данных при выводе на экран или печать. Microsoft Access может работать с большим числом самых разнообразных форматов данных, включая файловые структуры других СУБД. Можно осуществлять импорт и экспорт данных из файлов текстовых редакторов или электронных таблиц. С помощью Access вы можете непосредственно обрабатывать файлы Paradox, dBASE III, dBASE IV, Btrieve, FoxPro и др. В Microsoft Access для обработки данных ваших таблиц используется мощный язык SQL (Structured Query Language -- Структурированный язык запросов). Используя SQL, можно выделить из одной или нескольких таблиц необходимую для решения конкретной задачи информацию. Access значительно упрощает задачу обработки данных. При любой обработке данных из нескольких таблиц Access использует однажды заданные вами связи между таблицами.

Microsoft Access спроектирован таким образом, что он может быть использован как в качестве самостоятельной СУБД на отдельной рабочей станции, так и в сети -- в режиме «клиент -- сервер». Поскольку в Access к данным могут иметь доступ одновременно несколько пользователей, в нем предусмотрены надежные средства защиты и обеспечения целостности данных. Можно заранее указать, какие пользователи или группы пользователей могут иметь доступ к объектам (таблицам, формам, запросам) к базам данных. Access автоматически обеспечивает защиту данных от одновременной их корректировки разными пользователями, в Access имеются средства, позволяющие легко проектировать и создавать приложения для работы с базами данных без знания языка программирования. Работа в Access начинается с определения реляционных таблиц и их полей, которые будут содержать данные. Microsoft Access предоставляет дополнительные средства разработки приложений, которые могут работать не только с собственными форматами данных, но и с форматами других наиболее распространенных СУБД. Возможно, наиболее сильной стороной Access является его способность обрабатывать данные электронных таблиц, текстовых файлов, файлов dBASE, Paradox, Btrieve, FoxPro и любой базы данных SQL, поддерживающей стандарт ODBC. Это означает, что можно использовать Access для создания такого приложения Windows, которое может обрабатывать данные, поступающие с сетевого сервера SQL или базы данных SQL на сервере.

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

2. Разработка базы данных по учету заказов на ООО «Озон» с использованием пакета Microsoft Access

2.1 Процедура проектирования реляционной базы данных

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

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

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

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

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

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

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

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

8. Указать ограничения целостности проектируемой базы данных и дать (если это необходимо) краткое описание полученных таблиц и их полей.

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

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

1. Каждая таблица состоит из однотипных строк и имеет уникальное имя.

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

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

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

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

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

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

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

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

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

Всякая нормализованная таблица автоматически считается таблицей в первой нормальной форме, сокращенно 1НФ. Как нетрудно заметить, все сконструированные нами ранее исходные таблицы БД учета заказов на ООО «Озон» заведомо находятся в первой нормальной форме.

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

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

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

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

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

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

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

Рассмотрим таблицу Поставщики. Очевидно, что, поскольку все содержащиеся записи относятся к конкретному поставщику, которому присвоен уникальный КодПоставщика, то эта таблица находится во 2НФ, а так как каждое поле однозначно определяется этим уникальным кодом, то таблица находится и в НФБК. Аналогичные замечания полностью применимы к таблицам Клиенты и Сотрудники, которые, следовательно, также находятся в НФБК.

Рассмотрим далее таблицу Товары. Она находится в 1НФ. Первичным ключом таблицы является поле КодТовара. Зная значение ключевого поля, мы однозначно находим значения всех других полей таблицы. Это означает, что таблица в 2НФ. Заметим также, что все поля таблицы функционально зависят от поля КодТовара (ключевого), все поля функционально зависят от полей Наименование и КодПоставщика, но, поскольку по коду товара эти поля определяются однозначно, но данные зависимости сводятся к полной функциональной зависимости от первичного ключа. Следовательно, таблица также находится в НФБК.

Наиболее сложными для анализа являются таблицы Заказы и Заказано. Отметим сразу же, что поле Цена в таблице Заказано (отражающее отпускную цену товара покупателю) не совпадает с полем Цена в таблице Товары, где указывается закупочная цена товара.

Ключевым полем в таблице Заказы является поле КодЗаказа, оно действительно однозначно определяет все другие поля таблицы. Следовательно, таблица находится в 2НФ. Но, совершенно очевидно, что все другие поля (кроме КодКлиента и КодСотрудника) содержат только сведения о получателе заказа и дате его оформления и функционально зависят от ключевого поля. Поля же КодКлиента и КодСотрудника находятся в прямой функциональной зависимости от ключевого поля в силу самой конструкции рассматриваемой таблицы. Следовательно, она находится в НФБК. Что касается таблицы Заказано, то её ключевое поле является составным (КодЗаказа - КодТовара). Поскольку исключены повторения товаров водном и том же заказе, а цена каждого наименования товара оговаривается в каждом отдельном случае и однозначно определена этими двумя полями, то и эта таблица находится в НФБК.

2.3 Разработка форм для обработки информации в базе данных

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

Рисунок 2.1. - Схема данных базы учета заказов ООО «Озон».

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

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

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

Таблица Клиенты формируется менеджерами по работе с клиентами. Все они должны иметь неограниченный доступ к данным этой таблицы.

Таблица Заказы также формируется менеджерами по работе с клиентами.

Наконец, таблица Заказано формируется также менеджерами по работе с клиентами, но полный доступ к данным должны иметь сотрудники склада.

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

Рисунок 2.2. - Главная кнопочная форма базы данных ООО «Озон»

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

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

Рисунок 2.3. - Форма Сотрудники базы данных ООО «Озон»

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

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

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

SELECT DISTINCT Клиенты.Страна

FROM Клиенты;

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