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

У реалізації БД, як зазначалося раніше, виділяють "комп'ютерне" створення власне БД, інтерфейсу користувача і алгоритму програми (алгоритму перетворення).

Створення власне БД припускає використання мови програмування SQL або QBE для:

  • • побудови структури таблиць (завдання імені таблиці і переліку полів з відповідними типами даних, вказівка ключів, індексів та обмежень на окремі поля або групу полів);
  • • встановлення зв'язків між таблицями з урахуванням посилальної цілісності;
  • • заповнення таблиць даними.

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

Ручне заповнення можливо двома способами:

  • • безпосередньо самої таблиці (у тому числі і через відповідні утиліти);
  • • через спеціально створювані форми, що відносяться до інтерфейсу користувача і є в якійсь мірі аналогом рядка "паперової" таблиці уздовж лінійки, покладеної на цей рядок таблиці.

Інтерфейс користувача

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

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

  • 1. Орієнтація на вимоги користувача (а не на вміння розробника) - User_centred Design.
  • 2. Узгодженість (використання однозначних команд в робочому середовищі).
  • 3. Наявність зворотного зв'язку від комп'ютера (сигнал про сприйняття команди).
  • 4. Простота інтерфейсу - надання тільки тих його елементів управління, які потрібні на даному кроці сеансу роботи з програмним продуктом. Під сеансом (сесією) розуміється інтервал часу від запуску продукту до виходу з нього.
  • 5. Гнучкість інтерфейсу - здатність враховувати рівень підготовки користувача.
  • 6. Облік естетичних вимог, до яких включаються час освоєння інтерфейсу, час рішення задачі, суб'єктивна задоволеність зручністю інтерфейсу.
  • 7. Облік традицій предметної області.
  • 8. Ітераційний характер розробки інтерфейсу з урахуванням уподобань користувача.
  • 9. Облік можливостей програмних і апаратних засобів.
  • 10. Можливість обліку психологічних характеристик користувача: ліва півкуля мозку краще сприймає текст, праве - образи, зображення.
  • 11. Облік можливостей спрощення програмування.
  • 12. Малий час відгуку комп'ютера: якщо інтервал від запиту до відповіді комп'ютера перевищує 20 с, систему не вважають інтерактивною.

Перераховані вимоги часом суперечливі, проте їх слід враховувати.

Основою інтерфейсу користувача є система елементів управління спільно з формами і звітами.

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

Алгоритм додатки

У традиційному підході формується алгоритм прямого перетворення даних вихідних таблиць у вихідні документи. В якості вихідних документів (таблиць) виступають запити і звіти. Запити формуються за допомогою мови програмування SQL або QBE. Звіти є фактично запитами, забезпеченими додатковими поясненнями. Звіти можуть реалізуватися за допомогою різних конструкторів (при фактично ручному створенні) або за допомогою майстрів (в напівавтоматичному режимі).

Алгоритми додатки в сучасному підході відрізняються від алгоритмів програми більш складними обчисленнями з можливим формуванням проміжних об'єктів. Алгоритм програми може бути написаний на різних мовах програмування - наприклад, Visual Basic for Applications (VBA), Object Pascal, SQL. В останньому випадку він виконується у вигляді збережених процедур, генераторів, тригерів.

На закінчення слід зазначити, що процес проектування ітератівен: можуть постійно змінюватися вимоги в ТЗ, складові проектування та реалізації БД.

Процеси проектування і реалізації розглянемо на двох прикладах - "Навчальний процес" і "Прийом на роботу", стисле опис яких наведено в прикладах 2.1 і 2.2.

Реалізація описаних в прикладах баз даних проводиться на СУБД Access і InterBase (в рамках програмного продукту Delphi).

Численним можливостям зазначених СУБД присвячені спеціальні окремі публікації [27-36, 41]. Освоєння можливостей, як показав досвід, доцільно проводити в два етапи:

  • 1) розгляд основної гілки технології реалізації на конкретному прикладі (БД) з використанням обмеженого кола можливостей СУБД;
  • 2) детальний освоєння - по докладним описам [27-36, 41] - названих СУБД при обліку їх численних приватних можливостей.

Роботи на другому етапі після ретельного вивчення технології на першому етапі, як показує практика, не викликає особливих труднощів. У той же час опис численних приватних процедур другого етапу, як виявляється з робіт [17-36], займає обсяг, що перевищує справжню публікацію. У зв'язку з цим в даній роботі висвітлимо тільки перший етап.

Процедура створення сховищ даних тільки почала формуватися. В даний час виділилися два варіанти:

  • • повний, описаний в гл. 2;
  • • "усічений", що полягає в періодичній передачі в архівні таблиці даних з оперативних таблиць. Зв'язки між архівними таблицями найчастіше відсутні.

Другий варіант наведено в роботі [32] і розглянутий у § 15.4 даної роботи.

 
< Попер   ЗМІСТ   Наст >