Розробки програмно-апаратного комплексу тарифікації і білінга телефонних розмов та інтернету

       2.2.3 Вибір середовища  розробки програми  білінга

       Як  основне програмне середовище для  написання програми білінга було вибрано Visual Basic, що є найбільш прогресивним засобом для швидкої розробки прикладних програм – RAD (Rapid Application Development) [1]. Visual Basic дозволяє писати Windows-програми швидше і простіше, ніж інші засоби розробки.

       Новизна мови полягає в:

• передусім,  у використанні технології RAD;
• створенні консольних 32-х розрядних програм Win32;
• використанні графічного інтерфейсу користувача (GUI – Graphical User Interface);
• підтримка повного циклу розробки, включаючи програмування, тестування, компіляцію і повторне використання елементів управління ActiveX;
• включенні до складу інших програм елементів, створених з допомогою Visual Basic і підтримуючих роботу з ними (Internet Explorer,  Microsoft Office 97 і інш.);
• створенні інтерфейсу користувача (меню, діалогові вікна, і інш.) з використанням технології drag-and-drop;
• оновленні і поліпшенні можливостей відладки програм: Visual Basic забезпечує розробника новими могутніми засобами, що роблять процес відладки ActiveX – елементів управління так же звичним, як і відладка звичайних програм.
• можливості вміщувати в форми елементи управління ОСХ для швидкого створення спеціалізованих програм, таких як Web-браузери, не втрачаючи швидкості виконання програм.

       Інтегроване середовище розробки (IDE – Integrated Development Environment) в Visual Basic повністю стандартизоване [2]. Його інтерфейс ідентичний інтерфейсу Microsoft Office. Використовується технологія IntelliSense для максимально швидкого створення безпомилкового (з синтаксичної точки зору) початкового коду.

       У порівнянні з попередньою версією  в середовищі розробника з'явилася  багато нових можливостей:

• використання технології IntelliSense, що дозволяє на етапі написання початкового коду автоматично перевіряти синтаксис мови і наявність об'єктів, посилання на які створюються;
• можливість роботи з декількома проектами з єдиного середовища, що дозволяє одночасно завантажувати і налагоджувати декілька елементів ActiveX;
• новий потужний редактор, який перевіряє синтаксис мовних конструкцій, відмічає їх кольором і підтримує режим drag and drop між окремими сторінками початкового тексту і навіть різними додатками;
• новий менеджер проектів, що дозволяє переглядати компоненти, з яких складається проект, їх ієрархію і взаємозв'язки;
• модифіковане вікно для установки і редагування властивостей програмних об'єктів, що дозволяє упорядковувати їх по алфавіту або по категоріях;
• оновлений відладчик з можливістю відстеження процесу виконання програм, стану і значення глобальних і локальних змінних;
• нова панель для розміщення вікон програми при її виконанні на моніторах з різними параметрами екрана.

       В якості СУБД для вибрано MS Access, що дуже гармонійно вписується в середовище розробки Visual Basic [6,7].

3 РОЗРОБКА СТРУКТУРНОЇ  СХЕМИ 

     Розробка  структурної схеми програмного  продукту з використанням СКБД являє  собою процес проектування бази даних.

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

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

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

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

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

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

       На  практиці проектування бази даних вимагає  хорошого розуміння предметної області, що моделюється, а також знань  в області моделювання залежності і нормалізації. Проектування бази даних звичайно є ітеративним процесом, в ході якого крок за кроком досягається необхідний результат, а іноді і переглядається декілька кроків, переробляючи попередню роботу з урахуванням нових потреб, що з'явилися. Ось зразкова послідовність кроків, що виконується в процесі проектування бази даних [6]:

       Дослідження інформаційного середовища для моделювання:

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

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

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

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

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

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

       Безпосереднє  створення структури бази даних і розміщення в ній деяких прототипів даних. Обов'язкове експериментування із запитами, вивчення отриманих результатів. Виконання рядів тестів на продуктивність, щоб перевірити різні технічні рішення.

     Оцінка  бази даних з точки зору технічного завдання.

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

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

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

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

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

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

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

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

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

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

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

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

       3.1 Розробка структури  БД тарифікатора 

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

       Таблиця Input містить вхідні дані для тарифікації, ключовий полів немає (таблиця 1).

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