Этой темой я занимался с 1980 г.: изучал, преподавал, разрабатывал автоматизированные системы управления, ERP-системы или, как теперь говорят, «компьютерные решения». К сожалению, эта наука – часть кибернетики – кажется, забыта (в России, но не на Западе). То, как наши финансисты и управленцы обращаются с данными (по крайней мере, в средних компаниях), вызывает ужас и негодование. И, конечно, желание помочь. Но они не всегда спрашивают помощи у консультантов, отдавая формирование баз данных на откуп айтишникам. А тех самих, к сожалению, не всегда учат правильно.
Общая теория организации данных будет представлена предельно кратко — только основные термины, понятия и теоремы. И главное, практические выводы. Доказательств приводить не стану — ограничусь ссылками на литературу. Но пояснения дам обязательно.
Инфологические модели данных
Модели данных бывают даталогические и инфологические. Даталогические – это всякие «биты, байты и файлы» в компьютере. Сие есть предмет компьютерщиков. Инфологические модели данных, в свою очередь, выражают суть описываемой информации и строятся независимо от компьютеров и систем управления базами данных (СУБД).
Инфологическая модель относительно постоянна. Она не зависит от изменений даталогической модели (конечно, если нет технических ошибок). Переход с одной компьютерной системы на другую не меняет инфологическую модель. К ней сотрудники привыкают и легко меняют сами. Модель развивается вместе с фирмой, что позволяет значительно снизить ошибки и повысить скорость IT-разработки, а главное — обеспечить более высокий порядок в менеджменте и финансах.
Метаязык – универсальный язык описания данных. Для инфологической модели используют формальный язык более высокого уровня, чем конкретной СУБД или ERP-системы. Такие языки в науке называют метаязыками.
Метаязык максимально независим от конкретных понятий, пользователей, компьютерной системы, но верно и однозначно отражает суть модели данных компании. Высказывания на метаязыке, конечно, индивидуальны, но просты и понятны.
Итак, наш предмет – именно инфологические модели. Будем рисовать их на бумаге, в EXCEL, WORD, использовать средства визуализации. Все это разные языковые средства. Чтобы их объединить, упорядочить, сделать однозначными и понятными (в первую очередь, ученым и бизнесменам), придумали метаязык.
Приведу варианты одного и того же языка для описания данных (они формально эквивалентны и просты):
1. Овал-диаграммы: элементы данных в овалах соединены связями (рис.1). Овал-диаграммы – это инструмент разработчика. Они используются для первичного выделения элементов и анализа связей. К диаграмме такого типа прибегают в спорах, аналитике, но для конечного пользователя используют иные формы языка.
2. Прямоугольные схемы – суть та же, но изображение иное – в виде заголовка таблицы с подчеркнутыми первичными ключами, которые часто называют просто ключами(рис.2). В отличие от овал-диаграмм прямоугольные схемы обязательно имеют имена файлов. Такие схемы являются и инструментом разработчика, и средством для конечного пользователя.
3. Логические файлы. Я, например, часто использую построчный список полей и называю это логическим файлом. Придумал не сам, просто не помню, откуда взял. Это еще один способ описания одного и того же – модели данных. Он полностью описывает таблицы данных и их связи через одноименные поля. Это очень важно и удобно для ленивых (типа меня), кто не любит тратить время на рисунки. Поэтому далее будем оперировать именно этим языком. Конечно, на презентации для начальства надо бы изобразить всю модель на одном листе (слайде), лучше в виде диаграммы прямоугольных схем.
Логический файл:
ПЕРВИЧНАЯ ЗАПИСЬ (СТАТЬЯ ЗАТРАТ + ОБЪЕКТ УЧЕТА, СУММА, ДАТА)
Обратите внимание: логический файл и его составляющие записываются заглавными буквами.
4. Анкетная форма ЛБД. Логическая база данных может быть представлена в анкетной форме:
Файл ПЕРВИЧНАЯ ЗАПИСЬ
СТАТЬЯ ЗАТРАТ
ОБЪЕКТ УЧЕТА
СУММА
ДАТА
Она используется для того, чтобы можно было сразу записать комментарии к полям файла.
5. Табличное представление данных. Есть еще один язык – народный: просто графы табличек. Такое представление данных самое понятное и распространенное, хотя люди не слишком задумываются над тем, что это есть модель. Табличное представление чуть хуже, так как в нем иногда забывают о ключах и признаках (зависимых данных). Поэтому его можно использовать во вспомогательных целях (например, объясняя сотрудникам суть информационного пространства).
Перечисленные языки позволяют получить продукт —ЛБД или модель данных (МД). ЛБД — одно из названий инфологической модели — это формализованное описание взаимосвязей между данными. Одна и та же ЛБД может быть реализована различными программными средствами. Она создается для лучшего понимания работы с информацией до решения вопросов программирования и последующего функционирования системы.
Основные понятия метаязыка
Гарантирую, что этих понятий хватит, чтобы разобраться и упорядочить любые данные в экономике и финансах:
- элемент данных – это элемент в строке или столбцетаблицы (например, «Иванов»);
- поле – логическое представление однородных элементов, представленное именем поля. Для удобства имя поля пишется заглавными буквами. Например, поле ФАМИЛИЯ имеет значение «Иванов». Записывается: ФАМИЛИЯ = «Иванов»;
- перечень допустимых значений поля. Например, поле ПРИЗНАК может иметь только три значения: 0, 1 или 2. Это может быть записано так: <ПРИЗНАК> = <”1”, ”2”, ”3”> или просто <ПРИЗНАК> = <1, 2, 3>;
- запись – совокупность элементов, описывающих информацию об объекте. В реляционной модели запись иногда называют кортежем;
- файл – совокупность записей. Представляется в модели данных перечнем полей. Примеры см. далее;
- ключ (первичный ключ) – поле или совокупность полей, однозначно определяющее совокупность полей, называемых атрибутами. То же самое можно сказать и на уровне записи. Первичные ключи подчеркиваются сплошной линией;
- вторичный ключ – поле для выборки. Первичный ключ в том числе должен выступать в роли вторичного, то есть использоваться для выборок. Вторичные ключи подчеркиваются пунктиром;
- сцепленный ключ – несколько полей, вместе определяющих совокупность атрибутов.Сцепленный ключ может быть как первичным, так и вторичным. Последовательность полей (ключей) в сцепленном ключе задает последовательность выборки (сортировку данных). Например, ФАМИЛИЯ+ОЦЕНКА сортирует записи: например, сначала идут Ивановы со всеми их оценками (по возрастанию или убыванию – это уже детали), а затем Петровы и т. д. Обратная последовательность ОЦЕНКА+ФАМИЛИЯ дает иную сортировку: сначала в алфавитном порядке идут те, кто получил пятерку, затем те, кто удостоился четверки и так далее;
- язык отчетов. Это замечание очень важно для нашего предмета – финансов в целом и БДР в частности. В одних отчетах превалирует «взгляд финансиста», и в сцепленном ключе поля идут в последовательности СТАТЬЯ ЗАТРАТ + ОБЪЕКТ УЧЕТА. В других отчетах нужен «взгляд менеджера». Тогда последовательность записей меняется: ОБЪЕКТ УЧЕТА + СТАТЬЯ ЗАТРАТ. Конечно, разделение «взглядов» условно. Для этого не надо менять БД, а следует лишь дать соответствующую команду компьютеру с использованием языка отчетов. Так как отчет тоже таблица, язык отчетов не отличается от записи соответствующего отношения (реляционной модели). Например: ОТЧЕТ (ОБЪЕКТ УЧЕТА + СТАТЬЯ ЗАТРАТ, СУММА, ДАТА);
- атрибут – зависимый от ключа или сцепленного ключа элемент данных (поле). В предыдущем примере это поля СУММА и ДАТА;
- связь – зависимость между элементами данных (полями);
- типы связи:
- «1» — элементу данных (полю) А соответствует ровно один элемент данных (поля) В. Может быть и связь типа «2», «3», но в хороших моделях данных, называемых нормальными, такого стремятся не допускать, для чего просто вводят 2 или 3 поля, например;
- «М» — элементу данных поля А соответствуют несколько (0, 1, 2, 3,..) элементов данных поля В. Сколько именно, заранее не известно;
- «1:1» — элементу данных (полю) А соответствует ровно один элемент данных (поля) В, и наоборот;
- «1:М» — элементу данных поля А соответствуют несколько (0, 1, 2, 3,..) элементов данных поля В. Вместе с тем элементу данных (полю) В соответствует ровно один элемент данных (поля) А;
- «М:М» — элементу данных поля А соответствуют несколько (0, 1, 2, 3,..) элементов данных поля В, и наоборот.
Например, высказывание «Студент Трифонов, вы получаете отличную оценку» может быть преобразовано в запись: «Трифонов», «отлично» или «Трифонов», «5», где «Трифонов», «отлично» и «5» — элементы данных.
В соответствующей ведомости успеваемости будут поля ФИО и ОЦЕНКА, а сама ведомость называется на метаязыке файлом.
Но ФИО не может выступать в роли первичного ключа, так как у Трифонова могут быть полные однофамильцы, поэтому в таких ведомостях вводят искусственно первичный ключ (чаще всего, порядковый номер). Таким образом, имеем:
Запись: «16», «Трифонов», «5».
Файл: ПОРЯДКОВЫЙ НОМЕР, ФИО, ОЦЕНКА
Первичный ключ подчеркивается.
Итак, логический файл (в реляционной модели называется отношением, а на «человеческом языке» таблицей) состоит из записей, включающих несколько элементов данных. Запись однозначно идентифицируется с помощью значений одного или нескольких полей (сцепленный ключ), называемых первичным ключом (при изображении они подчеркиваются).
Не правда ли, все очень просто? Для тренировки приведите самостоятельно пару примеров посложнее. А еще лучше, сформулируйте небольшое техническое задание для работников ПЭО или программиста.
Реляционная модель
Существует простое и универсальное представление любой совокупности данных. Оно называется реляционной моделью и состоит из взаимосвязанных таблиц, называемых отношениями или для большего удобства пользователей — файлами. Отношение (таблица) не обязательно отражается в виде файла физической БД. Тем не менее, реляционная модель данных используются и на «машинном уровне» [5].
Связь между таблицами устанавливается, как правило, путем указания одноименных полей (как правило, первичных ключей). Поля, по которым осуществляются выборки, называются вторичными ключами и подчеркиваются пунктиром.
Нормальные формы. Реляционная модель может быть представлена логично и экономично. Такое представление получило название третьей нормальной формы (3НФ). Вся система нормальных форм – это математическая конструкция, описывающая «правила игры». Рассмотрим ее весьма лаконично:
- (1НФ): элементы соответствующей таблицы являются атомарными, то есть в файле нет групповых зависимостей — все связи идут от ключа в формате «1:1»;
- (2НФ) = (1НФ) + атрибуты функционально полно зависят от ключа. Если ключ сцепленный, значение каждого атрибута (зависимого поля) зависит именно от декартова произведения представленных в записи значений полей сцепленного ключа;
- (3НФ) = (2НФ) + не содержит транзитивных зависимостей между полями любой записи.
- Существуют формы более высокой пробы, но на практике они не всегда достижимы. Это НФБК – нормальная форма Бойса-Кодда, 4НФ и 5НФ. Именно к таким моделям следует стремиться разработчикам баз данных;
- (НФБК) = (2НФ) + все функциональные зависимости исходят только из ключа;
- (4НФ) – это обобщение НФБК на случай многозначных зависимостей. Она гарантирует, что все нетривиальные многозначные зависимости (то есть не входящие в сцепленные ключи) есть зависимости от ключа;
- (5НФ) = (4НФ) + не содержит нетривиальных зависимостей.
Обозначения в самой лучшей – реляционной — модели данных таково: файлы (отношения) и их поля изображаются заглавными буквами:
ИМЯ-ФАЙЛА (ИМЯ-ПОЛЯ-1, ИМЯ-ПОЛЯ-2, ИМЯ-ПОЛЯ-3, …, ИМЯ-ПОЛЯ-N).
Ключи подчеркиваются и пишутся слева. Несколько подчеркнутых полей означают сцепленный ключ. Мы будем пользоваться именно этой транскрипцией. Иногда сцепленный ключ для наглядности в текстах изображается так:
ИМЯ-ПОЛЯ-1 + ИМЯ-ПОЛЯ-2 + ИМЯ-ПОЛЯ-3…
Пример 5НФ. Исходная информация представлена в виде следующей, пока не упорядоченной, модели:
- Проектировщик ЛБД выделил всего 5 элементов данных:
МЕСТО-РАБОТЫ (М),
СЛУЖАЩИЙ (С),
ДОЛЖНОСТЬ (Д),
ПРЕДЫДУЩЕЕ-МЕСТО-РАБОТЫ (П),
ГОД-УВОЛЬНЕНИЯ (Г).
- Зависимости между элементами данных:
С «1» М (напомним, что это означает: у служащего одно место работы);
С «1» Д (у служащего одна должность);
С + П «1» Г (служащий с каждого предыдущего места работы увольнялся в каком-то конкретном году);
С «М» П (у служащего несколько предыдущих мест
работы).
Казалось бы, элементарно. Однозначный проект РБД состоит из 2-х файлов (отношений):
РАБОТНИК (С, М, Д);
ПРЕДЫДУЩЕЕ-МЕСТО-РАБОТЫ-РАБОТНИКА (С, П, Г).
Но есть не отмеченные проектировщиком, но реально существующие связи:
М «М» С (место работы для нескольких служащих);
М «М» Д (место работы для нескольких должностей).
Поэтому простейшее, казалось бы, отношение РАБОТНИК не находится в 4НФ. Забытые зависимости как раз являются теми нетривиальными зависимостями, о которых говорилось выше.
Корректной будет иная ЛБД:
РАБОТА-И-РАБОТНИКИ (М, С);
РАБОТНИК-И-ЕГО-ДОЛЖНОСТЬ (С, Д);
ПРЕДЫДУЩЕЕ-МЕСТО-РАБОТЫ-РАБОТНИКА (С, П, Г).
Сложно? Нет. Уверен, вы научитесь быстро. Устали от теории? Трудно сразу разобраться? Конечно, но американский математик Е.Кодд [9] к 1969 г. завершил свою реляционную теорию и получил бы за нее Нобелевскую премию, если бы математикам ее давали. С тех пор весь «информационно-программистский мир» говорит на его языке, использует РБД. Значение его открытия:
- конечно и заключается и в том, что он завершил эту науку;
- бесконечно в том смысле, что поле применения бесконечно большое – любые множества данных.
Вы уже ждете практически значимый и содержательный пример? И он у нас есть — описание информационного пространства оптовой фирмы. В данном примере ЛБД сразу будет представлена в 3НФ
Формальная эквивалентность моделей данных и разница в их практическом применении
Доказано, что существуют только три типа моделей данных: иерархическая, сетевая и реляционная [1]. Любая совокупность данных может быть представлена в виде этих моделей. В этой связи для практики имеют значение две теоремы:
Первая: любая совокупность данных может быть представлена в виде реляционной модели [2].
Вторая: иерархическая (древовидная) и сетевая модели данных преобразуются в реляционную модель и наоборот [1].
Лучшая из моделей – реляционная – и будет нашей целью. Почему она лучше всех:
- удобство ведения, в первую очередь легкость модификаций, при том, что все старые информационные потребности удовлетворяются автоматически;
- простота, прозрачность для пользователей (в частности, можно легко заказывать разные отчеты и строить произвольные деревья (в финансах, например, это нужно для форматов отчетов БДР и БДДС));
- наличие реляционной алгебры [5], формально описывающей все операции в РБД (такого сервиса нет в моделях-конкурентах).
Комментарий: вести иерархическую и сетевую модели гораздо сложнее, а «защиты от дурака» меньше, чем в реляционной модели. Поэтому в данной работе мы не изучаем другие модели. Наша цель – скорее к практике, через РБД. Только так получится простой, устойчивый, практичный результат. И потому не будем останавливаться на иерархической и сетевой моделях, а поближе познакомимся с РБД.
Литература:
- Мартин Дж. Организация баз данных в вычислительных системах / Пер. с англ. – М., 1980.
- Ульман Дж. Основы систем баз данных / Пер. с англ. – М., 1983.
- Тиори Т., Фрай Дж. Проектирование структур баз данных / Пер. с англ. – М., 1985.
- Цикридис Д., Лоховски Ф. Модели данных / Пер. с англ. – М., 1985.
- Озкарахан Э. Машины баз данных и управление базами данных / Пер. с англ. – М., 1989.
- Мицкевич А.А., Константинова Е.А. Экономическая информация и модели данных: учебное пособие. - М., 1987.
- Мицкевич А.А. Организация баз данных: учебное пособие. - М, 1989.
- Мицкевич А.А., Константинова Е.А., Мухамедвалеева С.Г. Базы знаний и экспертные системы: учебное пособие. - М., 1989.
- Codd E.F. Relational Model of Data for Large Shared Dada Banks. – CACM, 1970,Vol 13, No. 6, pp.377-387.
Пример ЛБД на языке логических файлов
Перед вами фрагмент ЛБД оптовой компании. Обратите внимание, что в этом примере ЛБД представлена в 3НФ. Имея богатую практику в 1980-х гг., я привык представлять любую информацию в 3НФ и не «заморачиваться» более сложными изысками. Написал ЛБД на одном из вариантов метаязыка, который, на мой взгляд, не требовал особых усилий для понимания программистом. Так оно и вышло. Все было понято однозначно.
Если вы разберетесь прямо в ЛБД, получите полное представление об информации, которой оперирует фирма. Успехов вам в «чтении и переводе». Надеюсь, все будет не просто понятно, а однозначно понятно — что и требуется в бизнесе.
1. Логические файлы (отношения) подсистемы «Описание товаров»
1.1. Товар. «Товар» – совокупность однородных товарных единиц, неразличимых между собой. «Товаром» может быть и множество реальных товаров, объединенных в тюк, контейнер и т.п., которые покупаются и продаются как единое целое.
Файл «Товар»
- Код-товара (первичный ключ формируется программно, обеспечивает связь со свойствами товара)
- Наименование (*)
- Английское-наименование (*)
- Шифр-товарной-группы (ссылка или вторичный ключ)
- Шифр-производителя (ссылка или вторичный ключ)
- Шифр-сезона (ссылка или вторичный ключ)
Файл «Классификатор производителей»
- Шифр-производителя (первичный ключ формируется программно)
- Наименование
- шифр-страны (используется для сокращения объема и обеспечения целостности БД)
Возможно отражение информации о производителях в едином файле «Классификатор контрагентов».
Файл «Классификатор стран»
- Шифр-страны (первичный ключ формируется программно)
- Наименование-страны
1.2. Товарные группы: «Направление» (бизнес, подразделение) – верхний уровень классификации товаров: 1 — «химия»; 2 — «ткани»; 3 — «трикотаж»; 4 — «пряжа»; 5 — «пищевые добавки (ПД)».
«Товарная группа» — первый содержательный уровень классификации. Название принято на фирме и менять его нет смысла, но необходимо уточнить понимание товарной группы в каждом бизнесе.
«Тип товара» — второй содержательный уровень классификации. Фактически это классификатор типов товаров внутри товарной группы. Название принято и менять его нет смысла, но необходимо уточнить понимание типа товара в каждом бизнесе и каждой товарной группе.
В общем случае поля Товарная-группа и тип-товара объединены связью М:М.
Целесообразно заполнить файл «Основной классификатор товаров» в процессе диалога: руководитель направления – разработчик ЛБД.
Файл «Основной классификатор товаров»
- *Шифр-товарной-группы (первичный ключ формируется программно)
- Направление = {химия, ткань, трикотаж, пряжа, ПД}
- Товарная-группа (например, «ясельный трикотаж»)
- тип-товара (например, «ползунки короткие»)
- резервные поля 1-3 (для дополнительных признаков основной классификации)
1.3. Свойства и состав товаров. «Свойства товара». Количество свойств товара не ограничено. Свойства товара используются, прежде всего, для торговли по образцам. Хотя и для аналитических группировок они могут пригодиться. Файл «Классификатор свойств товаров» используется для обеспечения целостности БД.
Вариант 1. Файл «Свойства товара»-1
- *Шифр-свойства (первичный ключ является сцепленным: 1 +(2)+(3))
- (*)Код-товара (заполняется, если свойство относится к отдельному товару)
- (*)Шифр-товарной-группы (заполняется, если свойство относится к товарной группе в целом)
- Значение-строка (длина задается на уровне максимально возможной среди всех используемых значений типа «Строка»)
- Значение-число (размерность выбирается максимально возможной)
- Значение-дата (размерность выбирается максимально возможной)
Допустимо иное представление, использующее отдельные файлы «Свойства товара» и «Свойства товарной группы»:
Вариант 2. Файл «Свойства товара»-2
*Шифр-свойства (первичный ключ является сцепленным: 1 + 2)
*Код-товара (заполняется, если свойство относится к отдельному товару)
Значение-строка (длина задается на уровне максимально возможной среди всех используемых значений типа «Строка»)
Значение-число (размерность выбирается максимально возможной)
Значение-дата (размерность выбирается максимально возможной)
Вариант 2. Файл «Свойства товарной группы»
*Шифр-свойства (первичный ключ является сцепленным: 1 + 2)
*Шифр-товарной-группы (заполняется, если свойство относится к товарной группе в целом)
Значение-строка (длина задается на уровне максимально возможной среди всех используемых значений типа «Строка»)
Значение-число (размерность выбирается максимально возможной)
Значение-дата (размерность выбирается максимально возможной)
Файл «Классификатор свойств товаров»
*Шифр-свойства (первичный ключ, формируемый программно)
Наименование-свойства (например, «цвет» или «ширина»)
Формат-ограничений = {Диапазон, Перечень, Иное}
тип-поля = {Строка, Число, Дата, Ссылка}
Размерность-ограничений (включая тип поля)
ЗНАчения (Диапазон или Перечень) = {Разрешенные значения}
Классификатор-открыт = {Да, Нет}
ССЫЛКА = {Ссылка на текст комментария или подробного описания свойств, например, для «технологического применения» пищевой добавки}
Пример записи файла «Классификатор свойств товаров»
- *Шифр-свойства = 0078
- Наименование-свойства = Ширина
- Формат-ограничений = Перечень
- Размерность-ограничений = см
- ЗНАчения = 45, 50, 70, 75, …
- Классификатор-открыт = Нет (это означает, что оператор не может ввести запись о ткани с шириной, не указанной в классификаторе)
- ССЫЛКА = Нет ссылки
«Состав товара». Состав ткани или химического соединения можно отразить в файле «Свойства товара». Возможно и иное решение – создать специальный файл. Скорее всего, последнее решение технологичнее. Рассмотрим его.
Файл «Состав товара»
- (*)Код-товара (заполняется, если состав относится к отдельному товару)
- (*)Шифр-товарной-группы (заполняется, если состав относится к товарной группе в целом)
- шифр-компоненты
- процент (может не заполняться)
Файл «Классификатор компонент»
- *шифр-компоненты
- имя-компоненты
- список-синонимов (в том числе на иностранных языках)
- КОММЕНТАРИЙ (например, для ПД это «технологическая функция»)
2. Логические файлы (отношения) подсистемы «Движение товаров».
В отличие от существовавшего ранее обобщенного файла движение товара на логическом уровне целесообразно использовать детализированное представление по видам операций:
- «Покупки (бартерный приход)» и «Продажи (бартерный расход)» не отражаются напрямую на состоянии складов;
- хранение и движение товара на складах отображается в файле «Движение товаров на складах». Здесь учитываются все виды прихода и расхода (покупки, продажи, перемещения, инвентаризация).
Предполагается, что связь бизнес-операций наиболее свободная. Например, покупка товара идет одним числом, купленные товары могут храниться на разных складах, начиная с иной даты, или вообще продаются, минуя склад.
Файл «Покупки»
- шифр-покупки (первичный ключ является производным от сцепки (2) + (3) +(4) )
- *Код-товара
- *код-поставщика
- *Дата-покупки (дата договора)
- *Дата-оплаты
- *номер-партии (для организации алгоритма FIfo)
- Объем-покупки (количество товара)
- ед.-измерения (возможно отражение этого факта в файле «Свойства товара») цена
- Бартер-или-покупка = {б, п}
- ГТД (если товар импортный, указывается номер таможенной декларации)
- Код-ЛПР (шифр покупающего менеджера или подразделения)
- ссылка-на-документ (договор, накладная о покупке или бартере)
Формирование первичного ключа шифр-покупки является программно-методологическим вопросом, хотя подойдет и порядковый номер.
Файл «Продажи»
- шифр-продажи (первичный ключ является производным от сцепки (2) + (3) +(4) )
- *Код-товара
- *код-покупателя
- *номер-партии-покупки (для организации алгоритма FIfo)
- *Дата-продажи (дата договора)
- *Дата-оплаты (дата последней трансакции, когда вся покупка оплачена)
- Объем-продажи
- ед.-измерения (возможно отражение этого факта в файле «Свойства товара»)
- цена
- Бартер-или-покупка = {б, п}
- ГТД (если товар импортный, указывается номер таможенной декларации)
- Код-ЛПР (шифр продающего менеджера или подразделения)
- ссылка-на-документ (договор, накладная о продаже или бартере)
Формирование первичного ключа шифр-продажи является программно-методологическим вопросом, хотя подойдет и порядковый номер.
Файл «Движение товаров на складах»
- *Код-товара
- *номер-партии-покупки (для организации алгоритма FIfo)
- *код-склада (куда первоначально закладывается или перемещается, или откуда продается, куда добавляется или вычитается при инвентаризации)
- *Дата
- *операция = {приход, расход}
- Тип-операции (покупка, продажа, перемещение, инвентаризация)
- Объем (количество товара)
- ед.-измерения (возможно отражение этого факта в файле «Свойства товара»)
- Резервировался = {да, -} (только для продажи или перемещения резерва – с целью отображения движения резерва)
- ссылка (на запись о покупке или продаже, на документ об инвентаризации или о перемещении товара)
Первичным ключом является сцепка Код-товара + код-склада + Дата + операция.
Файл «Резерв»
- *Код-товара (что резервируется)
- Кто-резервирует (ссылка на код потребителя или код-ЛПР – это и есть указание на кладовщика)
- Дата-резервирования
- шифр-склада
- Дата-окончания-резервирования
- дата-продажи-товара
- сколько (количество зарезервированного товара)
- ссылка-на-документ (документ о резервировании. Возможно, это поле лишнее, так как эксперт считает, что резервирование должно быть чисто компьютерной операцией)
Обратите внимание, что файл имеет сцепленный ключ (1) + (2) + (3) + (4).
Резервировать может ЛПР, без документального оформления со стороны заказчика.
Движение резерва отражается через файл «Движение товаров».
Покупатели и продавцы могут представляться в отдельных файлах типа «Классификатор производителей». Ниже будет предложено обобщенное хранение информации о покупателях, продавцах и потребителях. С точки зрения обеспечения целостности БД этот вариант предпочтительнее.
Файл «Классификатор контрагентов»
- Шифр-контрагента (первичный ключ формируется программно)
- Наименование
- Производитель = {0, 1} (то есть «нет» или «да»)
- Поставщик = {0, 1}
- Покупатель = {0, 1}
- шифр-страны (используется для сокращения объема и обеспечения целостности БД)
3. Логические файлы (отношения) подсистемы «Экономика».
Затраты разнесены по партиям и накапливаются (по дням или неделям — в зависимости от концепции представления времени). Затраты сокращаются пропорционально уменьшению остатка партии на складах. Система разнесения затрат описана в математической подсистеме.
Для разгрузочных работ затраты хранятся в первой записи файла «Затраты», для погрузочных — в соответствующих записях файла «Затраты». В любом случае затраты аккумулируются по неделям и относятся на конец недели. Если имеется неполная неделя продажи, затраты на хранение относятся на дату продажи.
Далее описание прерывается, так как у меня нет права выдавать коммерческие секреты фирмы…
4. Система обеспечения целостности базы данных
Целостностью называется степень полноты и непротиворечивости данных.
Нарушением целостности может быть даже ошибка в одной букве при вводе данных. Защита осуществляется при помощи выбора элементов данных оператором из значений классификатора. Другим примером может быть ошибка в числах. Частичная защита, как правило, строится путем контрольных сумм, логической проверки и т.п.
В нашей ЛБД защита целостности (обеспечение высокой целостности) основана на системе классификаторов и контрольных суммах. Файлы-классификаторы заполняются ответственными работниками и проверяются на целостность администратором БД (АБД). Для управления БД в распоряжении Администратора находятся файлы:
- «Описание классификаторов» — предназначен для управления классификаторами (открыть/закрыть, разрешить изменить диапазон и т.д.);
- «Временное хранение» — буфер записей, целостность которых должна быть подтверждена ответственными лицами.
Для разработки классификаторов могут быть использованы существующие государственные и отраслевые классификаторы. Это целесообразно, но при отсутствии такой возможности будут разработаны собственные классификаторы. Здесь существуют две проблемы:
проблема 1: ведение и обеспечение целостности БД заключается в том, что некоторые свойства могут быть закреплены за товарной группой, а другие свойства поставлены в соответствие только определенному товару. Желательно отделить одно от другого. Это планируется сделать в процессе разработки классификаторов. Вот она, 4НФ;
проблема 2: формирование первичных ключей. Каковы интервалы значений? Делать ли ключ многопозиционным? Использовать ли шифры из классификаторов? И так далее.
5. Заполнение классификаторов
Это ключевой элемент информации, циркулирующей в основных бизнесах группы компаний. В «1С» их называют справочниками, в других системах — иначе. Но суть от этого не меняется.
Целостность классификаторов по каждому направлению периодически контролируется АБД, представителем бухгалтерии и склада, представителем направления. Контроль завершается 15 числа каждого месяца, составляется акт о целостности и коррекции классификаторов.