Базы данных. Практикум

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

мации или о проекте документа, чтобы отличать неподписанные до-

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

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

Снова пропустим детали и приведем конечную таблицу (табл. 4). Приведем несколько комментариев по поводу табл. 4. Мы уже

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

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

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

22

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

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

Что касается пункта I, а), вопрос 5, прогнозировать в наших усло- виях что-либо сложно, кроме обязательного появления новых отчет- ных форм и документов.

2.4. Оценка эффективности автоматизации технологического процесса

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

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

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

2.Снижение трудозатрат сотрудников фирмы. Это позволит не увеличивать число работников при увеличении объема продаж.

3.Эффективный контроль оплаты товаров. Финансовое под-

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

4.Надежный учет продаж.

24

3. РАЗРАБОТКА СТРУКТУРЫ БАЗЫ ДАННЫХ

3.1. Концептуальная схема базы данных

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

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

2.Каждый атрибут класса описывается ровно одним столбцом (полем) в своей таблице.

3.Крайне не рекомендуется использовать объекты с повторяю- щимися атрибутами (полями).

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

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

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

7.Поля (атрибуты) должны содержать минимально возможные элементы информации.

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

Первые три правила определяются понятием реляционной модели данных. Следующие три правила выражают условия нормализации.

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

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

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

28

пространенный метод – ввести поле (условно назовем его «Уникаль- ный номер документа в таблице») и объявить его первичным ключом.

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

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

Приступим к проектированию заголовка и создадим таблицу «То- варные счета». Какие поля в нее будут входить?

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

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

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

30