Категории

Cуществуют следующие способы оплаты за занятия:

  • Абонемент на 8 посещений (срок действия 1 месяц) - 300 грн.;
  • Абонемент на 4 посещения (срок действия 1 месяц) - 200 грн.;
  • Абонемент на 12 посещений(срок действия 1 месяц) - 400 грн.;
  • Разовое посещение - 60 грн.
(ДЛИТЕЛЬНОСТЬ ЗАНЯТИЙ ПО 1,5 ЧАСА)

Модель облікових даних

  1. Багато компаній і програмісти-одинаки пробують себе у ролі бухгалтерських програм. Таких програм розроблено...
  2. Математична модель даних
  3. Структура основної бази даних
  4. База даних технологічних процесів
  5. Сортування основної бази даних
  6. Система обробки інформації
  7. сервер обліку
  8. Корпоративна інформаційна система
  9. Висновок

Багато компаній і програмісти-одинаки пробують себе у ролі бухгалтерських програм. Таких програм розроблено безліч, кожна з них має свої переваги, але всі вони мають один великий недолік - пишуться від бухгалтерії. І в кожній з них простежується власне розуміння бухобліку тим конкретним фахівцем, який ставив завдання, при тому, що офіційна регламентація даної предметної області далека від досконалості. Мета статті - спробувати запропонувати нові методи обробки бухгалтерської інформації як технологічної основи побудови корпоративних інформаційних систем.

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

Дебет 10 рахунок - (матеріали) 100 руб. Кредит 60 рахунок - (постачальники) 100 руб.

Збільшується залишок матеріалів на складі - сума додається в дебет одного рахунку і збільшується заборгованість перед постачальником матеріалів, тобто та ж сума ще додається в кредит іншого рахунку.

Можна припустити, що існують системи обліку з потрійною, чотирикратної і т.д. записом. Дійсно, такі системи використовуються на практиці. З урахуванням витрат за дебетом 20 рахунку збирається собівартість, наприклад, Д20 - К10 (матеріальні витрати). В кінці кожного місяця цей рахунок закривається, наприклад, Д46 - К20, і в наступному місяці собівартість розраховується з нуля. Але за витратами, крім того, ведеться облік наростаючим підсумком з початку року (незважаючи на те, що в кінці кожного місяця витрати списувалися під нуль, в грудні бухгалтерія повинна дати дані про витрати за весь рік). Це досягається застосуванням двох різних регістрів. В одному враховується звичайна бухгалтерія, а в іншому - витратна (те ж саме, але без списання витрат. Отримуємо потрійну запис:

Дебет 20 витратний 100 руб. Дебет 20 балансовий 100 руб. Кредит 10 рахунок 100 руб.

При списанні витрат задіюється тільки 20 балансовий рахунок:

Дебет 46 рахунок 100 руб. Кредит 20 балансовий 100 руб.

Чотирикратної записом фіксуються операції з матеріальними цінностями і фондами в бюджетній бухгалтерії (так звані другі проводки).

І, нарешті, повне змішання всіх типів проводок спостерігається в західній системі обліку. Наприклад, оприбуткування товарів для роздрібної торгівлі буде виглядати наступним чином:

Дебет 41 рахунок - (товари) 120 руб. Кредит 60 рахунок - (постачальники) 100 руб. Кредит 42 рахунок - (націнка) 20 руб.

Всі рядки в операції називаються полупроводкамі. Для збереження балансу повинен дотримуватися принцип рівності сум дебетових і кредитових полупроводок.

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

Структура зберігання даних

Будь-яка система обліку укладається в єдину схему зберігання і обробки даних. Для зберігання інформації розробляється структура основної бази даних (основний таблиці). У загальному випадку поля бази мають вигляд:

Вимірювачі (координати) Службова інформація Значення

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

РІК
МІСЯЦЬ
СКЛАД - код (номер) складу
МОЛ - шифр матеріально відповідальної особи
ТМЦ - номенклатурний номер товару / матеріалу.
Службова інформація:
ДВК - дата введення / коригування Значення:
НОК - початковий залишок у кількості
НОС - початковий залишок в сумі
ПК - прихід в кількості
ПС - прихід в сумі
РК - витрата в кількості
РС - витрата в сумі
КОК - кінцевий залишок у кількості
КОС - кінцевий залишок в сумі

Тут, щоб вивести залишки матеріальних цінностей на кінець року по складу N, застосовується фільтр виду (РІК = 2000 and МЕС = 12 and СКЛАД = N) і формується таблиця з полями ( Таблиця 1 ).

Поля-вимірювачі задіюються наступним чином: МВО для групування даних і отримання проміжних підсумків, ТМЦ бере участь в сортуванні. Графи «Найменування» і «Од. вим. »заповнюються з супутньою бази даних або пов'язаної таблиці. З полів-значень задіяні КОК і КОС. З ними проводяться наступні арифметичні дії: для отримання ціни виконується розподіл, поле КОС в підсумкових рядках підсумовується. Аналогічно можна побудувати облік розрахунків з постачальниками. Тут в якості значень будуть фігурувати суми проводок (в рублях і у валюті), а в якості вимірників - рік, місяць, день, дебет, кредит, код постачальника і т.п.

Подібним же чином у схему «вимірювачі-значення» вкладається будь-яка система обліку: головне - не перестаратися з вимірювачами і не закладати туди несуттєву інформацію. Всі інші показники, такі як найменування і одиниця виміру, виносяться в супутні бази даних (пов'язані таблиці). Значний також має бути рівно стільки, скільки необхідно. Наприклад, у наведеному прикладі КОК і КОС надлишкові, їх можна отримати шляхом нескладних обчислень:

КОК = НОК + ПК - РК;
КОС = НОС + ПС - РС.

Продовживши міркування, можна прийти до висновку, що поля для зберігання початкових залишків (НОК і НОС) теж зайві. Будь залишок - результат парафій і витрат за попередній час.

Математична модель даних

У більшості систем обліку основною дією, виконуваних над полями-значеннями, є підсумовування. Наприклад, щоб отримати журнал-ордер б№1, необхідно підсумувати всі проводки по касі за місяць в розбивці по днях і по кореспондуючих рахунках. Щоб отримати записи для головної книги по касі, необхідно підсумувати рядки журналу-ордера б№1 в розбивці по коррахунках за всі дні.

В процесі підсумовування система по черзі перебирає всі записи в базі даних, що забирає багато часу. В основу пропонованої автором моделі даних покладена класична формула Ньютона-Лейбніца:

В основній базі даних крім самої функції f (x) необхідно зберігати значення її інтегральної функції F (x). Тоді підсумовування f (x) замінюється на різницю значень F (x), при цьому для отримання результату замість суцільного перебору записів до бази даних досить звернутися всього двічі - до початкової записи і до кінцевої.

У реальних системах облік ведеться одночасно за багатьма показниками, тому функція f (x) стає багатовимірної - f (a, b, c, ... z), де a, b, c ... - поля-вимірювачі (рахунок, код матеріалу, номер документа, дата проводки і т.п.). Виділимо номер документа і дату проводки в окрему вісь координат - час t. Саме за часом часто відпрацьовуються запити «з ... по ...», тоді як запити типу «з 40 рахунку по 60» або «з третього складу по восьмий» - велика рідкість.

Для підсумовування даних за певний проміжок часу необхідно обчислити диференціал F (a, b, c, ... t) на відрізку н? T:

S (a, b, c, ... н? T) = F (a, b, c, ... t2) - F (a, b, c, ... t1),
н? t = [t1; t2]

Для отримання зведених даних по іншим аналітичним показниками - a, b, c ... - необхідно підсумувати значення S (a, b, c, ... н? T). Таким чином всі підсумкові документи будуть отримані в результаті диференціювання і інтегрування даних з основної бази.

Структура основної бази даних

Структура основної бази даних набуває вигляду, показаний в таблиці 2 .

Всі поля-вимірювачі можна розбити на три категорії: обліковий період, аналітика і час. Для звичайних задач бухгалтерського обліку вектор часу досить уявити трьома показниками: ДЕНЬ (календарне число у місяці); ВД (вид документа); НД (номер документа). З їх допомогою однозначно ідентифікується господарська операція за умови, що протягом одного дня немає повторюваних номерів документів кожного виду.

Аналітика А1, А2 ... Аn може бути виражена як простим набором незалежних аналітичних показників (наприклад, РАХУНОК, СКЛАД, ТМЦ), так і набором посилань до інших таблиць, що відображають більш складну аналітичну структуру.

Як значення використовуються чотири поля:

PD - сума проводки по дебету (прихід)
PK - сума проводки по кредиту (витрата)
ID - сумарні дебетові обороти з початку звітного періоду
IK - сумарні кредитові обороти з початку звітного періоду

Для забезпечення обліку, як у валюті, так і в кількості і т.д. немає необхідності додавати нові поля значень. З цією метою краще задіяти службове поле ТЗ - тип запису, наприклад:

ТЗ = 1 - значення в рублях
ТЗ = 2 - значення в кількості
ТЗ = 3 - значення у валюті

За допомогою унікального номера запису, що зберігається в поле НЗ, рублеві значення з кількісними і / або з валютними.

Розглянутий приклад з обліку ТМЦ перетворюється в вид, показаний в таблиці 3 .

Так задається сальдо на початок звітного періоду. У першому записі зберігається сума (тип запису ТЗ = 1), у другій - кількість (ТЗ = 2). Записи з початковим сальдо відрізняються від інших записів нульовими значеннями в полях PD і PK (суми проводок відсутні) і полем ДЕНЬ = 0. В цьому випадку при сортуванні за часом запису сальдо виявляться на самому початку. В таблиці 4 наведені записи в базі даних, що відображають рух ТМЦ.

У записах з НЗ = 15 зафіксований витрата розглянутого ТМЦ з кодом 100 в кількості 4 на суму 40. При цьому сумарні дебетові обороти не змінилися, а кредитові досягли значень 40 в сумі і 4 в кількості. У записах з НЗ = 180 зафіксовано прихід в кількості 10 на суму 100. При цьому сумарні дебетові обороти досягли значень 150 в сумі і 15 в кількості, а кредитові обороти не змінилися. У записах з НЗ = 250 знову витрата в кількості 7 на суму 70. При цьому сумарні кредитові обороти досягли значень 110 в сумі і 11 в кількості.

Різниця ID-IK дає поточне сальдо. Наприклад, кількісне сальдо за 5 грудня 5-4 = 1. Обороти за довільний відрізок часу обчислюються шляхом диференціювання основної бази:

дебетові обороти:
OD = IDконечное - IDначальное
кредитові обороти:
OK = IKконечное - IKначальное

Наприклад, прихід з 6 по 20 грудня склав OD = 15-5 = 10, витрата OK = 11-4 = 7. Для контролю візьмемо сальдо за 5 грудня (1), додамо прихід з 6 по 20 грудня (10) і віднімемо витрата (7), виходить 1 + 10-7 = 4. Це поточний залишок за 20 грудня рівний ID-IK (15-11 = 4).

Зауважте, вся інформація про обороти і сальдо береться за все з двох записів: кінцевою і початковою. Якби від першого рядка, де НЗ = 15, і до останньої, де НЗ = 250, було б не дві операції, а сотня, то процедура обчислення оборотів і сальдо анітрохи б не збільшилася. Для отримання зведених даних, наприклад, про суму витрат з 6 по 20 грудня по складу б№1 необхідно проінтегрувати отримані значення кредитових оборотів OK за всіма МОЛ і ТМЦ за умови СКЛАД = 1.

База оперативно заповнюється. При введенні нової проводки треба всього лише перевірити наявність в базі попереднього рядка з такою ж аналітикою. При використанні відповідної сортування (в даному прикладі: Рік, Місяць, Склад, МОЛ, ТМЦ, ДЕНЬ, ВД, НД) це виконується практично моментально. Якщо попередній рядок виявлена, то обчислювані поля візьмуть значення:

IDтекущее = IDпредидущее + PDтекущее
IKтекущее = IKпредидущее + PKтекущее

Якщо попереднього рядка немає, то в ID вписується значення PD, в IK значення PK. Ніякої обробки додаткових баз даних, наприклад, перерахунку оборотів і сальдо не потрібно. Основна база містить повну інформацію.

В запропоновану структуру основної бази даних легко вписуються як проводки з подвійним записом, з потрійною і т.д., так і полупроводкі. База даних стає досить універсальною, щоб не розробляти окремі системи обліку грошових коштів, товарно-матеріальних цінностей, валютних операцій і т.п. Всі національні, галузеві та інші відмінності закладаються не на рівні структури бази даних, а на рівні обробних процедур.

База даних технологічних процесів

У корпоративних інформаційних системах крім бухгалтерського обліку ведеться і інший облік. Уявімо технологічний процес, як функцію декількох змінних, безперервну в часі. Для зберігання інформації використовується база даних виду, показаного в таблиці 5 .

Автоматичні датчики знімають безліч показників в різних цехах з різних агрегатів: температура, тиск, напруга живлення, споживаний струм і т.д. Тоді поле ПОКАЗНИК буде містити код показника зі списку:

1 - температура робочої зони
2 - температура охолоджуючої рідини
3 - тиск в робочій зоні .і т.п.

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

IDтекущее = IDпредидущее + н? P при н? P> 0
IKтекущее = IKпредидущее + | н? P | при н? P

Таким чином, в ID буде зберігатися сумарна амплітуда всіх позитивних змін, а в IK - негативних. Точкою відліку служить значення показника на початок звітного періоду, зафіксоване в поле ID (негативне - в IK) при порожньому значенні поля ЧАС. Різниця ID-IK в будь-який момент часу дорівнює абсолютному значенню даного показника. Всі дані фіксуються в хронологічному порядку, тому відпадає необхідність перерахунку значень ID і IK.

На практиці недостатньо знати просто значення показника. Якщо розглядати показники як випадкові величини, корисно зафіксувати їх сумарні початкові моменти k-го порядку:

Якщо розглядати показники як випадкові величини, корисно зафіксувати їх сумарні початкові моменти k-го порядку:

,

де н? ti - i-й відрізок часу t, протягом якого значення показника p залишалося незмінним і рівним pi.

Сумарний початковий момент 1-го порядку є сумою творів значення показника на час, протягом якого діяло дане значення, за звітний період (p * н? T). Сумарний початковий момент 2-го порядку є сумою квадратів показника, помножених на час (p2 * н? T). Моменти Ak фіксуються в базі даних при зміні показника наростаючим підсумком з початку звітного періоду.

Від сумарних початкових моментів легко перейти до початкових моментів k-го порядку:

ak = Ak / t

Щоб отримати середнє значення показника на будь-якому проміжку часу [tначальное; tконечное], необхідно знайти різницю:

Pср. = a1 = (A1 кінцеве - A1 початкове) / н? t,

де н? t = t кінцеве - t початкова

Аналогічно обчислюється середній квадрат:

p2ср. = A2 = (A2 кінцеве - A2 початкове) / н? T

Через значення початкових моментів k-го порядку можна знайти центральні моменти:

m2 = a2 - a12
m3 = a3 - 3 a2 a1 + 2 a13
m4 = a4 - 4 a3 a1 + 6 a2 a12 - 3 a14

Центральний момент 2-го порядку m2 є дисперсією, а його квадратний корінь - середнім квадратичним відхиленням (СКВ).

При нормальному розподілі випадкової величини середнє значення і середньоквадратичне відхилення є вичерпною характеристикою досліджуваного показника. Так, середнє значення характеризує власне значення показника, а СКО - точність його оцінки.

Запропонована структура бази даних забезпечує максимальну продуктивність при обчисленні статистичних характеристик. Для здобуття середньої, дисперсії (а також асиметрії, ексцесу і т.п.) потрібно всього два звернення до бази даних: до запису, в якій ЧАС Б ?? tначальное і до запису, де ЧАС Б ?? tконечное.

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

Сортування основної бази даних

Для оперативної обробки інформації база даних сортується в певному порядку. При використанні на багато користувачів введення даних для перегляду інформації необхідно передбачити індекс з ключем: користувач, обліковий період, час, службова інформація. У прикладі з урахуванням ТМЦ ключ набирає вигляду:

Користувач, Рік, Місяць, День, ВД, НД, НЗ, ТЗ

Для додавання нового запису система повинна вміти швидко звернутися до попереднього запису з необхідною аналітикою. Для цього застосовується індекс з ключем: обліковий період, аналітика, час, службова інформація. У прикладі з обліку ТМЦ використовується ключ виду:

Рік, Місяць, Склад, МОЛ, ТМЦ, День, ВД, НД, НЗ, ТЗ

У прикладі технологічної бази даних використовується ключ:

Місяць, День, Показник, Цех, Агрегат, Хвилини

Метод SEEK забезпечить практично моментальний перехід до шуканої записи.

При інтегруванні значень можуть знадобитися і інші індекси. (Відразу відкинемо досить ефективні, але низькошвидкісні методи обробки SELECT, SET FILTER і т.п. - найвищу швидкість забезпечує комбінація методів SEEK і WHILE.) Наприклад, щоб отримати залишки ТМЦ по всіх складах, які значаться на матеріально відповідальних осіб, початковий ключ кілька видозмінюється:

Рік, Місяць, МОЛ, ТМЦ, Склад, День, ВД, НД, НЗ, ТЗ

Для других завдання подібного роду могут знадобітіся інші зелених сандалів аналітичних показніків Склад, МОЛ, ТМЦ. У Розглянуто прікладі їх Шість. У технологічній базі Даних аналогічна ситуация з полями Показник, Цех, Агрегат. Порядок - обліковий період, аналітика, час, службова інформація - зберігається, змінюється лише внутрішній порядок аналітичних полів. Для більшості сучасних СУБД шість індексів проблеми не становить, але в загальному випадку число можливих індексів дорівнює n !, де n - кількість незалежних аналітичних показників. При 5 показниках це вже 120 індексів.

Є й інша проблема - хронологічний порядок ведення бази даних. На відміну від технологічних процесів бухгалтерська база даних може бути наповнений не в хронологічному порядку. Крім того, в ній можливі виправлення. Як в першому, так і в другому випадку система буде змушена перерахувати значення полів ID і IK в записах з задіяної аналітикою, що мають більш пізню хронологію. При масовому введенні даних це може привести до того, що система «захлинеться».

Система обробки інформації

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

До сих пір типовою для вітчизняних багатокористувацьких систем обробки залишається схема, заснована на використанні файл-сервера. Вона зображена на рис. 1a, а її поліпшений варіант - на рис. 1б.

Всю відповідальність за введення, обробку та подання інформації несе на собі клієнтську програму - серверної частини системи залишається пасивна роль зберігання, а в SQL-варіанті ще й сортування інформації. У клієнтської частини необхідно передбачити все різноманіття представлення даних і методів їх обробки. Як показує практика, навіть використання SQL-технологій не призводить до скільки-небудь істотного скорочення мережевого трафіку. При такому підході про побудову системи з розгалуженою територіальною структурою не може бути й мови. Вимоги до апаратної частини клієнта дуже високі.

Можливі два виходи. Перший передбачає відмову від універсального клієнтського робочого місця на користь розробки комплекту спеціалізованих АРМів, пов'язаних загальною базою даних. Однак, просування цим шляхом, на перший погляд спокусливо простому, загрожує створенням некерованого монстра, якщо розробник навмисне не обмежить масштаб і проектні можливості системи. Другий варіант - розвантаження клієнтської частини за рахунок перенесення бізнес-логіки на сервер. Він більш кращий з точки зору універсальності і масштабованості системи. Але і тут нашим розробникам похвалитися нічим. Це або спеціалізовані комплекси, розроблені на замовлення, або спроби створення універсальних систем, далеких від досконалості, що не впроваджуваних і готових до експлуатації без участі розробника, які не балують користувачів стабільністю роботи.

Якщо базову бізнес-логіку зосередити в спеціальній програмі - «сервері обліку», то вдосконалена схема буде виглядати так, як показано на рис. 1в.

Сервер обліку обслуговує основну базу даних, а SQL-сервер безпосередньо обслуговує допоміжні таблиці, в яких зберігаються списки, довідники та інша супутня інформація. Фізично сервер обліку може бути винесено на окремий комп'ютер.

Ідея триланкової архітектури не нова. Різниця між однозвенной архітектурою (файл-сервер), двухзвенной (SQL-сервер) і триланкової архітектурою полягає тільки в тому, хто перебирає записи в базі даних - клієнт, сервер або спеціалізований сервер додатків. Сенс авторської концепції полягає в тому, що спеціалізований сервер для підсумовування даних не буде виробляти суцільного перебору записів в базі. За рахунок використання запропонованої моделі даних сервера буде достатньо звернутися тільки до двох записів - кінцевої і початкової, що значно підвищить продуктивність системи.

сервер обліку

При введенні бухгалтерської проводки (отриманні інформації з датчика) клієнтську програму взаємодіє з сервером обліку, який виконує необхідні обчислення над полями-значеннями і реєструє інформацію в основній базі даних. Для отримання інформації з основної бази клієнтську програму посилає клопотання не SQL-сервера, а сервера обліку, який виконує необхідні обчислення і трансформує дані з полів-значень в відповідне подання.

Зведені дані обчислюються шляхом диференціювання і інтегрування основної бази і зберігаються в проміжних таблицях. При внесенні змін в основну базу даних проміжні таблиці своєчасно оновлюються і поповнюються. Структура проміжних таблиць і алгоритми обробки полів-значень визначаються комплектом періодичної звітності. Наприклад, при заповненні бухгалтерської бази даних не в хронологічному порядку, щоб уникнути великої кількості перерахунків, для зберігання ID і IK застосовується окрема проміжна таблиця ( Мал. 2 ).

Необхідно виділити три режими обчислень: безперервний, режим періодичних обчислень і режим обчислень на вимогу. Різні журнали-ордери, відомості, головна книга, баланс формуються в режимі обчислень на вимогу. Це єдиний режим, який вже і так реалізований в SQL-сервері і являє собою звичайний запит SELECT, що виходить від клієнтського додатка.

Режим періодичних обчислень - це той же SELECT, але виконувати не клієнтом, а сервером. Результат запиту зберігається на диску у вигляді окремої проміжної таблиці для подальшої обробки. Таблиця в автоматичному режимі періодично оновлюється. Обчислення виконуються у фоновому режимі, причому необов'язково за часом, а в залежності, наприклад, від обюема надійшла або від ступеня завантаження сервера. Всю звітність, що формується в режимі періодичних обчислень, можна формувати на вимогу.

Безперервний режим відрізняється від двох попередніх тим, що це не команда SELECT, яка завжди виконується «навздогін». Це процес, який відстежує стан первинної бази даних і при внесенні до неї змін, негайно реагуючи. Наприклад, розглянуту проміжну таблицю, краще заповнювати в безперервному режимі - при надходженні кожної нової проводки сервер автоматично виконає дорозрахунків значень ID і IK. на Мал. 2 представлена ​​приблизна схема роботи сервера обліку.

У подібній схемі знімається проблема великої кількості індексів, число яких знаходиться в факторіальною залежності від кількості незалежних аналітичних показників. Процедури заповнення первинної та проміжних таблиць можуть бути розділені в часі, тому для формування проміжних таблиць необов'язково застосовувати методи SEEK і WHILE. Періодичні обчислення можна здійснювати іншими методами з частковим використанням індексів або взагалі без них.

Індекси рекомендується застосовувати тільки для обчислень в безперервному режимі: в цьому випадку формується мінімальна кількість проміжних таблиць, тому кількість індексів первинної таблиці буде цілком допустимим.

Наведена схема базової бізнес-логіки завдяки уніфікації зберігання даних реалізується нескладно. Всі алгоритми обробки інформації зводяться до фільтрації записів і елементарного додаванню (інтегрування) і віднімання (диференціювання) значень. У комбінації трьох режимів обчислень закладені найширші можливості обробки даних. Одна проміжна таблиця може виступати джерелом даних для інших проміжних таблиць.

Якщо наділити сервер обліку дещо більшим рівнем інтелекту, він сам зможе динамічно реорганізувати схему побудови проміжних таблиць, спираючись на накапливаемую статистику за характером запитуваних звітів. Для «особливих» користувачів, таких як головний бухгалтер і генеральний директор, які звертаються до системи рідше інших користувачів, але при цьому вимагають високої оперативності, необхідно зберегти апріорний порядок формування проміжних таблиць.

Таким чином, клієнтське додаток максимально звільняється від обробки даних, як при введенні інформації, так і при отриманні зведеної звітності. Це знижує вимоги до апаратури клієнтської частини і відкриває можливість роботи по низькошвидкісних каналах зв'язку. Більш того, сервер обліку може виступати в якості клієнта іншого сервера обліку.

Корпоративна інформаційна система

На основі запропонованої технології будується корпоративна інформаційна система. Сервер обліку першого рівня крім обробки оперативних даних готує зведені дані для сервера обліку другого рівня. Наприклад, на електростанції, що виробляє електроенергію, реєструється споживана потужність, обюем споживаного палива і т.п. Сервер обліку підсумовує показники і зберігає їх в зведених таблицях. Сервер обліку регіональної організації «Регіон-енерго», скориставшись підготовленими підлеглими електростанціями зведеними таблицями, становить свої таблиці, якими, в свою чергу скористається сервер обліку наступного рівня.

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

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

Для обміну інформацією між серверами необов'язково мати постійний високошвидкісний канал зв'язку. Досить налагодити періодичний обмін даними на рівні зведених таблиць. Для цього старшому сервера необхідно по черзі «обдзвонювати» підлеглі сервери і, «прикидаючись» клієнтом, забирати підготовлені зведені таблиці. Кожна регіональна система в достатній мірі автономна, і в разі тимчасової відсутності зв'язку спільна робота істотно не постраждає. Використовуючи ієрархічну структуру, корпоративна система може нарощуватися до транснаціональних масштабів.

Висновок

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

Сергій Тбёкотев - провідний програміст АТ «Микроком». З ним можна зв'язатися за адресою: [email protected] .

Н?