1.2. Загальні правила адміністрування

Робота адміністратора по управлінню доступом користувачів до розділів інформації і функцій регламентується наступними принципами, закладеними у Системі:

- у системі можуть працювати тільки зареєстровані користувачі.

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

- даних може працювати лише обмежене число користувачів. Це число визначається конфігурацією Системи; можна надавати або забороняти конкретному користувачу доступ до будь-якого розділу Системи (пункту головного меню);

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

можна надавати або забороняти конкретному користувачу доступ на виконання дій всередині розділу (облікового реєстра, словни­ ка). Список дій всередині кожного розділу, доступ до яких можна регулювати, визначається поточною версією Системи.

Стратегія адміністрування будується на первинній відвертості Системи, тобто знову реєстрований користувач має, за замовчанням, до­ступ до всіх розділів і до виконання у них всіх дій.

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

Користувач у доступному йому розділі може створити необхідну йому структуру каталогів (підкаталогів).

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

Припустимо, розділ містить 3 каталога (К1, К2, КЗ). Потрібно вста­новити доступ на весь розділ і до каталогів К1 і КЗ. Увійшовши до роз­ділу, користувач побачить тільки каталоги К1 і КЗ та їхні підкаталоги. Якщо користувач заборонив доступ до розділу, то стане заборонений до­ступ і до всіх каталогів розділу. Тепер, якщо користувач знову дозволить доступ до розділу, то дозвіл на доступ буде встановлено і для всіх ка­талогів розділу (К1, К2 і КЗ). Тобто, ввійшовши після цього в розділ, користувач побачить всі три каталоги. Аналогічні міркування вірні і для зв'язки каталог — підкаталоги.

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

Права на доступ домінують над правами на дії, звужуючи їхню об­ласть застосування.

Наприклад, припустимо, що обліковий реєстр або словник ор­ганізований по каталогах. Доступ на перегляд у цьому випадку може бути призначений по каталогах, а дозвіл на внесення змін визначається цілком для облікового регістра або словника. У цьому випадку право на зміну розповсюджується тільки на доступні каталоги (принцип не «можна правити те, що не бачиш»).

1.3. Перевірка і відновлення цілісності бази даних

В результаті збою обладнання або помилок персоналу можливе по­рушення цілісності бази даних. Для перевірки і відновлення цілісності бази даних у модулі «Адміністратор» є декілька можливостей: переіндексація бази даних, корекція бази даних, ремонт бази даних.

Переіндексацію бази даних потрібно проводити при появі таких помилок, як мимовільна «пропажа» записів розділу, а також при появі повідомлень про порушення унікальності (типу «ІЛш|Уіо1...»). Рекомендується проводити переіндексацію регулярно у профілактичних цілях. Крім відновлення порушених індексів ця процедура очищає базу даних від записів, помічених як видалені.

Корекцію бази даних потрібно виконувати при появі таких по­милок, як:

- у документі присутній контрагент, відсутній у словнику;

- сума по документу не відповідає підсумковій сумі по всіх позиціях специфікації документа;

- у розділі відсутній каталог, який не був видалений, або у розділі є записи, що не входять ні в один каталог (при вході у подібний розділ, Система видасть повідомлення OLE dispatch error...);

- у процесі перетворення бази даних система видає повідомлення про помилки.

При виконанні операції видалення запис насправді не видаляється, а позначається як «видалений». «Видалені» записи не видно у списках, вони не беруть участь у складанні звітів, ніяк не відображаються в об­лікових даних. Проте їхнє «фізичне» видалення відбувається тільки при виконанні функції переіндексації бази даних.

Ремонт бази даних необхідний тоді, коли Система видає повідо­млення про помилки у процесі підключення до бази даних або користу­вач взагалі не може підключитися до бази даних.

Оскільки ступінь і характер порушень у базі даних виявити не за­вжди можливо, рекомендується використовувати можливості Системи по відновленню бази даних послідовно, в указаному вище порядку. Якщо після успішного виконання чергового етапу помилки при роботі з базою даних зникли, значить необхідний результат досягнутий.

Перед початком будь-яких операцій по відновленню бази даних по­трібно створити її резервну копію.