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

З можливостей, які підтримує служба CORBA OTS можна назвати:

1. Створення транзакційних об'єктів.

2. Розподілені транзакції за участю об'єктів служб OTS реляційних СУБД Oracle, Sybase, Informix, Mqseries, об'єктно-орієнтованих СУБД Versant і Object Design, інструментів для доступу до баз даних Roguewave і Persistence Software.

3. Прикладні й системні транзакції.

4. Імітація вкладених транзакцій.

5. Транзакції керовані клієнтом і транзакції керовані сервером.

6. Довго триваючі транзакції й сеанси користувачів у дволанкових та триланкових середовищах.

Таким чином, можна зробити висновок, що служби транзакцій CORBA не відстають, а в деяких місцях навіть перевершують підтримку транзакцій технологією .Net. Зокрема, одним з більших переваг є кросплатформена підтримка транзакцій. На відміну від CORBA COM+ очевидно на справжній момент існує тільки на платформі Windows, отже ґрунтуючись на технології .Net неможливо створити розподілений кросплатформений додаток, повністю керуючий своїми транзакціями. Такий додаток зможе здійснювати тільки часткове керування транзакціями. Крім того до цієї ж проблеми можна віднести вирівнювання навантаження й організацію пулу об'єктів, тому що ці завдання також виконуються на основі COM+. В CORBA служби вирівнювання навантаження й організації пулів об'єктів кросплатформені.

Збір сміття

· .Net

Проводиться як автоматичний збір сміття на рівні CLR, так і збір сміття за викликом з коду програми.

· Java-corba

Збір сміття не відбувається (за винятком Java).

Домени додатків і програмні модулі

· .Net

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

Збірки - це будівельні блоки .NET Framework. Збірки - елементарні одиниці, що використовуються при встановленні додатків, контролі їх версії, повторному використанні, визначенні області активації об'єктів і визначенні рівня доступу. CLR одержує зі складань інформацію, необхідну для конструювання типів. Складання це колекції типів і ресурсів, що зберігаються в одному місці з метою спільного використання. Таким чином, вони являють собою логічні одиниці функціональності. Для CLR типи не існують поза контекстом збірок. Збірки можуть складатися з одного або декількох файлів. Найпростіший випадок - коли збірки зберігаються в одному каталозі й інші додатки не мають доступу до них. У такому випадку, встановлення і видалення додатка зводиться до копіювання й видалення каталогу, що містить збірку. Але, збірки, також можуть бути доступні й розділятися багатьма додатками, у тому числі й видаленими. У цьому випадку вони повинні мати строге ім'я (strong name) і можуть бути занесені в глобальний кеш збірок (GAC), який є на кожній машині із установленим .Net Framework.

· Java-corba

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

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

Безпека, захист і рівні доступу в додатках

· .Net

.Net Framework підтримує два типи розмежування рівнів доступу: розмежування рівня доступу до коду й ролі. Обидва типи засновані на інфраструктурі, що надає CLR. Частину рівнів доступу можна визначити як "допуски". Їх три типи: code access permission, identity permissions і role-based security permission. Code access permission використовуються для захисту ресурсів і операцій від неавторизованого використання. Identity permissions використовуються для ідентифікації збірок. Role-based security permission засновані на встановленні приналежності користувача певної ролі.

Також, в. Net Framework підтримується type safety і security які визначаються під час Jit-компіляції. Виконання умов type safety і security гарантує те, що код додатка зможе одержати доступ тільки до тих областей пам'яті, які авторизовані для доступу.

Security policy це набір правил, CLR, який вирішує що можна дозволити робити виконуваному коду.

Також підтримується три види principals, аутентификация й авторизація.

До складу .Net Framework включений простір імен Cryptography.

Для забезпечення мережної безпеки можуть використовуватися протоколи SSL, Kerberos, HTTPS, TCP/IP.

· Java-corba

На сьогодні консорціумом OMG розроблено чотири специфікації CORBA, що мають відношення до безпеки:

1. Специфікація служби безпеки CORBA. Створена на основі існуючих технологій безпеки, таких як служба безпеки DCE (Distributed Computing Environment), протокол Kerberos для аутентифікації в розподілених системах, шифрування, розроблене в Массачусетському технологічному інституті (MTI), а також загальний засіб доступу до служб безпеки, прикладний інтерфейс API загальної служби безпеки (Generic Security Service API - GSS API).

2. Специфікація безпечної взаємодії (протокол Seciop CORBA).

3. Специфікація інтеграції CORBA ORB-SSL.

4. Специфікація брандмауерів CORBA.

Як відзначалося вище (див. "Доступ до Internet"), реалізація специфікації брандмауерів CORBA викликає утруднення, тому найбільш реальний у середовищі CORBA протокол SSL.

Можна зробити висновок, що і .Net і CORBA можуть забезпечити необхідний мінімальний рівень безпеки маючи разом з тим деякі вади в реалізації подібних служб.

Серіалізація об'єктів

· .Net

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

· Java-corba

Часткова серіалізація проводиться при передачі об'єктів за значенням, але передається тільки значення "стану" об'єкта - це значення властивостей об'єкта. Сам же об'єкт створюється на стороні клієнта способом, характерним для мови програмування клієнта з наступним присвоєнням його властивостям переданих значень. У цьому процесі виникають проблеми невідповідності Idl-опису властивостей і реальних властивостей, характерних для мови (наприклад, типів даних). Проблему намагаються розв'язати, але не завжди успішно. Така ж проблема виникає при серіалізації об'єктів зі збереженням їх у будь-якому сховищі об'єктів (об'єктній базі даних, тощо). .Net вигідно відрізняється в цьому змісті від CORBA, тому що об'єкти передаються у двійковому виді незалежно від мови - CLR розуміє їх завжди.

Робота з базовими типами

· .Net

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

· Java-corba

Є типи даних IDL, а є типи даних, характерні для мови програмування. Отже, проводиться меппінг/ремеппінг типів даних, не завжди успішний. Усі стандартні операції з типами даних - у мовах програмування клієнтів і серверів. Отже, вони в загальному випадку - різні.

Введення / виведення

· .Net

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

· Java-corba

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

Потрібно врахувати, що фірма Microsoft у даний момент розробляє нову, об'єктну файлову систему, яку збирається інтегрувати в Windows .Net з відповідною підтримкою з боку .Net Framework. Можна зробити висновок, що дана область не покривається CORBA і всі переваги на стороні .Net.

Порівняння двох технологій: .Net Framework і Java-corba показує, що кожна із цих технологій має свої переваги і свої недоліки. Хоча, все-таки, .Net на тлі CORBA виглядає більш сучасною й придатною до використання технологією. Можна зробити висновок, що застосування технологій визначається конкретними умовами, що існують у тієї або іншій організації. Зокрема, це основна операційна система, яка використовується на робочих місцях користувачів, капітальні вкладення в інші технології зроблені раніше і т.д.

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

2.3 Вибір системи керування базами даних

2.3.1 Визначення критеріїв порівняння

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

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

Моделювання даних

· Модель даних, що використовується

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

· Тригери та збережені процедури

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

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

· Засоби пошуку

Деякі сучасні системи мають вбудовані додаткові засоби контекстного пошуку.

· Передбачені типи даних

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

Особливості архітектури і функціональні можливості

· Мобільність

Мобільність - це незалежність системи від середовища, в яків вона працює.

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

· Масштабованість

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

· Розподіленість

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

· Мережеві можливості

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

Контроль роботи системи

· Контроль використання пам'яті комп'ютера

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

· Автоматичне налаштування

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

Особливості розробки додатків

· Засоби розробки

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

· Засоби проектування

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

· Багатомовна підтримка

Підтримка великої кількості національних мов розширяє область застосування системи та додатків, побудованих на її основі.

· Можливості розробки web-додатків

При розробці різних додатків часто виникає необхідність використання можливостей середовища internet. Середовища розробки різних виробників мають великий вибір інструментів для побудови додатків під web.

· Підтримка мов програмування

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

Продуктивність

· Рейтинг tpc (transactions per cent)

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

· Можливість паралельної архітектури

Для забезпечення паралельної обробки даних існує, як мінімум, два підходи: розпаралелювання обробки послідовності запитів на декілька процесорів, або використання декількох комп'ютерів-клієнтів, працюючих з однією СКБД, які об'єднують в так званий паралельний сервер.

· Можливість оптимізації запитів

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

Надійність

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

· Відновлення після збоїв

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

· Резервне копіювання

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

· Відкат змін

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

· Багаторівнева система захисту

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

Вимоги до робочого середовища

· Підтримка апаратних платформ

· Мінімальні вимоги до обладнання

· Максимальний розмір пам'яті, що адресується

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

· Операційні системи, під керуванням яких здатна працювати СКБД.

Змішані критерії

· Якість і повнота документації. На жаль, не всі системи мають повну та докладну документацію.

· Локалізованість. Можливість використання національних мов не у всіх системах реалізована повністю

· Модель формування вартості. Як правило, виробники СКБД використовують певні моделі формування вартості. Наприклад, вартість одного й того ж продукту може суттєво змінюватись в залежності від того, скільки користувачів буде з ним працювати.

· Стабільність виробника

· Поширеність СКБД.

2.3.2 Порівняльний аналіз СКБД MS SQL Server та Oracle

В даному випадку, виходячи з наведених вище критеріїв, можна звернути увагу на дві СКБД: Microsoft SQL Server та Oracle.

Основа для порівняння

Як Microsoft® SQL Server, так і Oracle являються поширеними системами керування базами даних, що надають багатий набір функцій для розробки й розгортання. Тому для того, щоб порівнювати ці СКБД, потрібно досліджувати їх в контексті продуктивності розробника. Виходячи з того, що програмною платформою проекту було вибрано технологію .NET, потрібно надати увагу питанню взаємодії СКБД з цією технологією, та її інструментами проектування і розробки. На даному етапі має сенс виділити наступні критерії порівняння:

• Інтеграція з Microsoft Visual Studio і платформою Microsoft .NET

Microsoft Visual Studio є найбільш популярним інструментом розробки додатків на ринку на сьогоднішній день. В результаті Oracle і Microsoft інтегрували свої пропозиції в сфері баз даних (Oracle SQL Server, відповідно) з Visual Studio і платформою .NET. Інтеграція з Visual Studio і .NET CLR (загальномовним середовищем виконання) являє собою одне з найбільших досягнень у продуктивності розроблювача баз даних за останні десять років.

• Підтримка розробки додатків, орієнтованих на служби (Service Oriented Architecture (SOA))

Наступаюче покоління мережних, з'єднаних і розподілених додатків буде засновано на концепціях Service Oriented Architecture (SOA). SOA у корені змінить процес проектування, розробки й розгортання додатків. Бази даних будуть відігравати важливу роль в Service Oriented Architecture. Тому Oracle і SQL Server містять кілька нових функцій для розробки додатків, заснованих на SOA. Ці функції включають:

XML: Здатність ефективно зберігати, розбирати, перевіряти, опитувати й обновляти XML документи в базі даних.

Web-служби: Здатність надавати об'єкти бази даних (таблиці, збережені процедури, тощо) як Web-служби, також як і можливість викликати зовнішні Web-служби з бази даних.

Asynchronous Message Queuing: Здатність гарантовано доставляти повідомлення, точно один раз, іншим мережним і розподіленим додаткам, незважаючи на системні відмови.

Event Notification: Здатність поширювати важливі бізнес події великій кількості користувачів і обладнань, у форматі, зрозумілому одержувачу, ефективним способом.

Query Notification: Здатність додатка підписатися й одержувати повідомлення про зміни в базі даних, які впливають на результати зазначеного запиту.

• Гнучкість розгортання

Споживачам потрібна гнучкість розгортання додатків на тій редакції СУБД, яка найбільше підходить для поточних вимог, заснованих на кількості користувачів, обсягах даних і кількості апаратного забезпечення й необхідних функцій. Більше того, споживачі люблять можливість повторного розгортання той же самого додатка пізніше з невеликими змінами або взагалі без них. Для того щоб задовольнити цій вимозі, усі редакції СУБД повинні підтримувати той самий основний набір функцій прикладного програмування (API). Це особливо важливо для незалежних постачальників програмного забезпечення (Independent Software Vendors - ISVS) готові додатки, що створюють, які прагнуть розробити додаток один раз і віддати замовникам для розгортання на будь-якій редакції СУБД. Якщо ні, то доведеться розробляти додатки для кожної редакції, що потребує більше часу й коштів. Як Oracle, так і SQL Server задовольнили ці вимоги, пропонуючи кілька редакцій, кожна з різною функціональністю й ціною.

Інтеграція з Visual Studio

На даний момент Oracle надає тільки базову інтеграцію з Visual Studio. Він надає компонент для Visual Studio, що називається Oracle Developer Tools for Visual Studio .NET. Oracle не надає деяких важливих функцій, що впливають на продуктивність розробника, включаючи:

* Oracle не дозволяє налагоджувати збережені процедури, написані мовою PL/SQL, з Visual Studio. Розробники змушені використовувати сторонні інструменти, такі як Jdeveloper.

* Visual Studio пропонує корисну можливість, що називається Проект SQL Server, яка спрощує розробку додатків SQL Server через керування всіма об'єктами бази даних (збережені процедури, тригери, користувацькі функції, користувацькі об'єкти, агрегати й діаграми класів) в одній зв'язаній сутності. Проекти SQL Server також дозволяють розроблювачам одержати переваги від функцій Visual Studio Team Services (VSTS), таких як контроль версій, тощо.

В Oracle немає еквівалента Проекту SQL Server, що є відчутним недоліком для продуктивності розробника.

* Автоматичне розгортання через Visual Studio. Після того, як об'єкти бази даних SQL Server були розроблені в проекті SQL Server, їх можна розгорнути в базі даних SQL Server шляхом одного кліку миші. Розгортання в один клік застосовується й до збірок .NET. Інтеграція Oracle з Visual Studio не підтримує таку можливість.

* Інтеграція з BI (Business Intelligence - бізнес-логіка) технологіями. Усі BI технології SQL Server, включаючи SQL Server Analysis Services, Reporting Services, і Integration Services, інтегровані з Visual Studio. Однак, жодна з BI технологій Oracle, такі як Oracle OLAP option, Oracle Data Mining Option, Oracle Reports, або Oracle Warehouse Builder не інтегрована з Visual Studio жодним чином. Отже, розробник .NET, що бажає вмонтувати можливості Oracle BI у свій додаток, буде змушений вивчити ще один інструмент, такий як Jdeveloper, що негативно позначиться на продуктивності праці.

Основним моментом є те, що SQL Server повністю інтегрується з Visual Studio, у той час як інтеграція Oracle неповна. З SQL Server, розробнику .NET не потрібно ніяких інструментів, крім Visual Studio для всіх аспектів розробки додатків. З іншого боку, Oracle вимагає використання інструмента Jdeveloper або інструментів інших виробників на додаток до Visual Studio, що приводить до неоптимального досвіду, збільшення часу навчання й зниженню продуктивності розробника.

Інтеграція с. NET

На перший погляд, здається, що як Oracle, так і SQL Server 2005 пропонують той самий тип інтеграції з Microsoft .NET CLR. Однак при більш докладному розгляді стає ясно, що SQL Server розміщає .NET CLR усередині процесу, а Oracle планує розмістити її поза процесом.

Розміщення усередині процесу означає, що .NET CLR виконується в просторі процесу SQL Server. Тому виклики логіки бази даних (збережених процедур, тригерів, користувацьких функцій), реалізованих у керованому коді, не приводять до витрат міжпроцесорної взаємодії. Через те, що Oracle планує розміщати .NET CLR поза процесом, продуктивність суттєво втрачається. Зверніть увагу, що як SQL Server, так і .NET CLR мають свої моделі керування потоками й пам'яттю. Моделі SQL Server інтегровані с. NET CLR, що дозволяє розробнику .NET краще налаштовувати додатки.

Розробка SOA додатків

Як Oracle, так і SQL Server надають той самий набір функцій, що дозволяє розробляти засновані на SOA додатка. Однак є відмінність у легкості використання. SQL Server містить легкі у використанні функції, що входять у сервер баз даних, що й легко інтегруються. В Oracle ця функціональність розподілена по декільком продуктам (сервер баз даних і сервер додатків) і не дуже добре інтегрована. Більше того, безліч функцій прикладного програмування засновані на стандартах Java (такі, як Java Messaging Service) і не представляють користі для .NET розробника. SQL Server надає добре спроектовану, краще інтегрувальну й більш продуктивну платформу для розробки SOA додатків, ніж Oracle.

Гнучкість розгортання

Хоча і Oracle і SQL Server пропонують кілька редакцій СКБД, тільки SQL Server надає те ж середовище розробки (.NET), інструментарій (Visual Studio) і інтерфейси прикладного програмування для всіх редакцій. В результаті, розробникам потрібно створити додаток тільки один раз, вони можуть розгорнути його на будь-яких редакціях SQL Server - Mobile, Express, Workgroup, Standard або Enterprise Edition - без необхідності перекодувати або змінити додаток. Oracle має недоліки двох типів:

* Oracle не пропонує безкоштовну версію своєї СУБД. Найдешевшою версією є Oracle Lite. SQL Server Express Edition безкоштовний.

* Oracle Lite не підтримує PL/SQL, основна мова, використовуваний розроблювачами баз даних Oracle для реалізації збережених процедур, тригерів, і методів об'єктів. Отже, може бути неможливо розгорнути на Oracle Lite додатка, розроблені на іншій редакції Oracle - Standard One, Standard і Enterprise. SQL Server не має подібних обмежень.

Таким чином, виходячи з результатів порівняння вищезазначених СКБД, значна перевага на стороні Microsoft SQL Server. У всіх трьох випадках дослідження показало, що ця система значно краще підходить для даного проекту.

2.4 Вибір технології доступу до даних

Архітектура системи реалізована таким чином, що в ній існує розподіл функціональності по різним рівням:

· Інтерфейс

· Веб-сервіси

· Дані

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

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

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

· Типізовані запити

· Типізовані результати

· Об'єктне представлення схеми зберігання

· Загальне рішення для цілого ряду проектів

· Створення концептуальної об'єктної моделі

· Явне декларативне представлення схеми об'єктно-реляційного співставлення (ORM) між концептуальною моделлю та моделлю зберігання.

В рамках платформи .NET та Microsoft SQL Server існує декілька технологій доступу до даних. Кожна з них має свої переваги і недоліки в контексті кожної окремо взятої задачі. З найбільш наближених до даної системи можна виділити три наступні технології:

· LINQ

· ADO .NET Entity Framework

· ADO .NET Data Services

· Sync Framework

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

2.4.1 Огляд технології Language Integrated Query (LINQ - мова інтегрованих запитів)

· Однакові типізовані запити до різних джерел даних

· Методи розширення інтерфейсу колекцій IEnumerable (Select, OrderBy, GrouBy, Join, Where)

· Результат вертається у вигляді об'єктної колекції (IEnumerable<T>)

· Intellisence, підсвічення коду, перевірка на етапі компіляції

· Спеціальний синтаксис виражень запитів

· Інтегрований в мову програмування доступ до даних

o Пов'язує таблиці та записи з класами та об'єктами

o Побудований на ADO .NET та .NET Transactions

· Відповідності (Mapping)

o Визначаються атрибутами чи в зовнішньому XML-файлі

o Відношення відповідають властивостям

o Можливість відкладеного чи одночасного завантаження даних через відношення

· Постійність (Persistence)

o Автоматичне відстеження змін

o Оновлення через SQL або збережені процедури

Окрім того, LINQ підтримує різні мови програмування, і, що важливо, має змогу працювати з даними різного формату. На Рис. 1 показана схема взаємодії LINQ з різними джерелами даних:

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Рисунок 1. Взаємодія LINQ з різними джерелами даних

Можливості LINQ в роботі з даними представлені в Таблиці 1:

Таблиця 1. Можливості LINQ при роботі з даними

Обмеження	Where
Вибірка	Select, SelectMany
Сортування	OrderBy, ThenBy
Групування	GroupBy
Об'єднання	Join, GroupJoin
Квантифікація	Any, All
Розбиття на частини	Take, Skip, TakeWhile, SkipWhile
Вибір елементів	First, Last, Single, ElementAt
Агрегатні функції	Count, Sum, Min
Конвертація	ToArray, ToList, ToDictionary
Приведення до типу	OfType<T>, Cast <T>

Виходячи з того, що дані будуть зберігатись в СКБД SQL Server, є сенс використовувати LINQ to SQL. Рис. 2 відображає схему взаємодії програмного коду з базою даних через LINQ to SQL.

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Рисунок 2. Архітектура LINQ to SQL

В процесі роботи, LINQ перетворює об'єкти SQL Server в об'єкти тієї мови програмування, на якій реалізується клієнтський сценарій роботи з базою даних. В даному випадку - C#. В таблиці 2 наведені дані про перетворення типів.

Таблиця 2. Перетворення типів

Database	DataContext
Table	Class
View	Class
Column	Property
Relationship	Field/Property
Stored Procedure	Method

програмний технологія база адмінчастина

2.4.2 Огляд технології Entity Framework

Особливості технології:

· Інфраструктура формування концептуального об'єктного представлення даних за допомогою сутностей (Entities)

· Реалізація класичних задач ORM

· Абстрагування від схеми зберігання

· Гнучке співставлення

Технологія Entity Framework являє собою набір технологій ADO.NET додатків, що забезпечують розробку, пов'язану з обробкою даних. Архітекторам і розробникам додатків, орієнтованих на обробку даних, доводиться враховувати необхідність досягнення двох зовсім різних цілей. Вони повинні моделювати сутності, зв'язки й логіку розв'язуваних бізнес-завдань, а також працювати з ядрами СКБД, використовуваними для збереження й одержання даних. Дані можуть розподілятися по декільком системам зберігання даних, у кожній з яких застосовуються свої протоколи, але навіть у додатках даних, що працюють із однієї системою зберігання, необхідно підтримувати баланс між вимогами системи зберігання даних і вимогами написання ефективного й зручного для обслуговування коду додатка.

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

Доступ до даних сутностей і їх зміна

Ціль Entity Framework - надати додаткам можливість читання й зміни даних, представлених у вигляді сутностей і зв'язків у концептуальній моделі. У службах об'єктів використовується модель EDM (Entity Data Model - модель сутностей даних) для перетворення запитів об'єктів до типів сутностей, представлених у концептуальній моделі, у запити, що залежать від джерела даних. Результати запитів перетворяться в об'єкти, якими управляють служби об'єктів. Платформа Entity Framework надає наступні способи виконання запитів до моделі EDM і повернення об'єктів.

· LINQ to Entities. Здійснює підтримку LINQ для виконання запитів до типів сутностей, які визначені в концептуальній моделі.

· Entity SQL - це незалежний від типу сховища діалект SQL, який працює безпосередньо із сутностями концептуальної моделі й підтримує такі функції моделі EDM, як наслідування і зв'язки. Мова Entity SQL використовується як з об'єктними запитами, так і із запитами, що виконуються за допомогою постачальника Entityclient.

· Методи конструктора запитів. Дозволяють створювати запити Entity SQL, використовуючи методи запитів у стилі LINQ.

Платформа Entity Framework містить у собі постачальник даних Entityclient. Постачальник управляє з'єднаннями, переводить запити сутностей у запити, що залежать від джерела даних, і повертає модуль читання даних, який використовується службами об'єктів для матеріалізації даних сутності у вигляді об'єктів. Якщо матеріалізація об'єктів не потрібно, постачальник Entityclient може також використовуватися як стандартний постачальник даних ADO.NET, який дозволяє додаткам виконувати запити Entity SQL і отримувати призначені тільки для читання дані, що вертаються модулем читання даних.

На Рис. 3 показано архітектуру технології Entity Framework

Рисунок 3. Архітектура Entity Framework

2.4.3 Огляд технології ADO.NET Data Services

ADO.NET Data Services (кодова назва "Astoria") - платформа для Microsoft Data Services, націлена, в першу чергу, на використання таких сучасних технологій, як Ajax і Silverlight, онлайн сервісів. Суть ADO.NET Data Services полягає в тому, щоб представити дані у вигляді сервісу, який може бути використаний Інтернет-клієнтами в корпоративних мережах і через Інтернет, з використанням URI. Для створення такого сервісу даних необхідно створити ADO.NET Entity Data Model (EDM), тобто описати всі об'єкти предметної області й задати зв'язки між ними (створити EDM можна автоматично на основі схеми бази даних). Після цього, створивши сервіс і запустивши його на виконання, можна звертатися до бази даних через URI. За допомогою HTTP методів GET, POST, PUT і DELETE, можна відповідно одержати, створювати, оновлювати та видаляти записи бази даних. При цьому обмін даними здійснюється за допомогою форматів XML і JSON.

Технологія отримує доступ до даних за допомогою веб-сервісів. Вони можуть бути двох типів:

· REST (Representational State Transfer - передача стану представлення)

Згідно REST, мережевий ресурс повинен підтримувати всього чотири операції: GET, PUT, POST і DELETE (з тими ж значеннями, як у протоколі HTTP). Дані повинні передаватися у вигляді невеликої кількості стандартних форматів (наприклад HTML, XML, JSON). Мережевий протокол (як і HTTP) повинен підтримувати кешування, не повинен залежати від мережевого шару, не повинен зберігати інформацію про стан між парами " запит-відповідь". Такий підхід забезпечує масштабованість системи й дозволяє їй еволюціонувати з новими вимогами.

· SOAP/WS-* (Simple Object Access Protocol - простий протокол доступу до об'єктів)

У випадку з SOAP/WS-* фактично маємо справу з виконанням операцій на віддаленому хості. Обмінюючись Soap-повідомленнями, клієнт фактично "просить" сервер виконати ту або іншу операцію, передаючи йому при цьому параметри (якщо це необхідно). У відповідь на це, сервер відправляє клієнту Soap-повідомлення, у якому знаходиться або оцінка про успішне виконання операції і результат, або повідомлення про помилку.

Крім того, передавати Soap-повідомлення можна потенційно через будь-який транспорт (WCF, наприклад, вміє це робити поверх http, tcp, named pipes, msmq, та ін).

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

2.4.4. Огляд технології Sync Framework

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

Sync Framework включає наступні технології:

· Базові компоненти Sync Framework.

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

· Служби Microsoft Sync Services for ADO.NET.

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

· Служба сховища метаданих.

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

· Служби Sync Services for File Systems.

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

· Служби Sync Services for Feedsync.

Використовуються для синхронізації Rss-каналів і каналів Atom у локальному сховищі.

Архітектура Sync Framework дозволяє спільно використовувати дані будь-якій кількості пристроїв, служб і додатків, сприймаючи сховища даних, механізми передачі й схеми як набір будівельних блоків. Будівельними блоками Sync Framework є середовище виконання, служби Metadata Services і постачальник. Середовище виконання забезпечує синхронізацію для постачальників. Постачальники використовують служби Metadata Services для обробки й зберігання метаданих.

На рисунку 4 показана високорівнева архітектура Sync Framework. Синхронізація здійснюється шляхом надання об'єкту сеансу синхронізації доступу до інтерфейсів постачальника зі сховища даних. Наприклад, сховище даних адресної книги й сховище даних обладнання синхронізують загальні контакти. Сеанс синхронізації з'єднує обох постачальників і викликає API-інтерфейс для визначення змін і необхідності їх застосування за допомогою служб Metadata Services.

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Рисунок 4. Архітектура Sync Framework

2.4.5 Вибір технологій доступу до даних

Для доступу до даних на мобільному пристрої під управлінням Windows Mobile найкращим варіантом є технологія Sync Framework. Таким чином, на мобільному пристрої створюватиметься локальна полегшена копія бази даних, з якою користувач буде мати змогу працювати локально, без доступу до сервера і основної бази даних. Йому потрібно буде лише іноді синхронізувати локальне сховище з глобальним і таким чином отримувати, або відправляти оновлені дані.

Що стосується доступу до слою даних з адміністративної частини системи, то тут має сенс використовувати технологію LINQ, тому що для даної структури і розміру бази даних важливо мати можливість створювати типізовані запити до бази даних та отримувати типізовані результати. Концептуальне представлення сховища не має сенсу для бази даних такого розміру. Більша частина даних буде кешуватись, тому немає ніякої вигоди у використанні ADO.NET Data Services.

2.5 Визначення інструментів для розробки проекту

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

· Програмна технологія: Microsoft .NET 3.5

· Система керування базами даних: Microsoft SQL Server 2008

· Платформа розробки компактного пристрою: Compact Framework + SQL Server Compact 3.5

· Платформа розміщення веб-додатіків: Microsoft Windows Server 2003

· Платформа розміщення клієнтського додатку: Microsoft Windows Mobile 6.5

· Інтегроване середовище розробки: Microsoft Visual Studio 2008 SP1

· Технологія доступу до даних: Language Integrated Query

· Технологія розробки адміністративної частини: ASP .NET 3.5 + AJAX

· Основна мова програмування адміністративної частини: C# + JavaScript

· Основна мова програмування клієнтської частини: C#

3. РЕАЛІЗАЦІЯ ПРОЕКТУ

3.1 Загальна схема проекту

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

3.1.1 Компонент зберігання інформації (глобально)

Реалізація:

o База даних

Розташування:

o сервер бази даних (DataBase Server).

Функції:

o зберігання інформації

o захист даних на рівні сервера бази даних

o частина логіки системи (рівень бази даних).

Доступ:

o адміністратори бази даних - необмежений,

o адміністратори системи - читання та запис (обмежений),

o користувачі - читання та запис (обмежений)

Взаємодія:

o Компонент взаємодії серверної частини з базою даних

o Компонент взаємодії клієнтської частини за базою даних

3.1.2 Компонент взаємодії адміністративної частини з базою даних

Реалізація:

o Веб-сервіс

Розташування:

o сервер додатків (Application Server)

Функції:

o додатковий захисний рівень даних від несанкціонованого доступу

o окремий рівень абстракції для гнучкості системи у випадках змін функціональності

o авторизація користувачів системи

o Прямий доступ до бази даних (читання, запис)

Доступ:

o всі користувачі (функція авторизації),

o адміністратори системи (усі функції, після вдалої авторизації)

o користувачі системи (деякі функції, після вдалої авторизації)

Взаємодія:

o Компонент зберігання інформації

o Адміністративна частина

3.1.3 Адміністративна частина

Реалізація:

o WEB-сайт

Розташування:

o сервер додатків (Application Server).

Функції:

o Відображення інформації

o Створення опитувань

o Керування опитуваннями

o Керування користувачами

o Редагування довідкової інформації

o Моніторинг процесу роботи

Доступ:

o Адміністратори системи (повна функціональність)

o Зареєстровані користувачі системи (обмежена функціональність)

Взаємодія:

o Компонент взаємодії адміністративної частини з базою даних

3.1.4 Компонент зберігання інформації (локально)

Реалізація:

o Файл з розширенням .mdf

Розташування:

o Файлова система мобільного пристрою

Функції:

o Збереження даних локально (без відправки на сервер)

o Відтворення структури глобального сховища локально

Взаємодія:

o Клієнтська частина

3.1.5 Компонент взаємодії клієнтської частини з базою даних

Реалізація:

o WEB-сервіс

Розташування:

o сервер додатків (Application Server).

Функції:

o Взаємодія з сервером бази даних (читання, запис)

o Взаємодія з локальним сховищем клієнтської частини (читання, запис)

o Синхронізація даних між глобальним та локальним сховищами

Доступ:

o Зареєстровані користувачі системи

Взаємодія:

o Сервер бази даних (глобальне сховище)

o Клієнтська частина (локальне сховище)

3.1.6 Клієнтська частина

Реалізація:

o Програма Windows Mobile

Розташування:

o Мобільний пристрій (файлова система)

Функції:

o Отримання інформації безпосередньо від джерела

o Первинна обробка отриманих даних

o Підготовка даних до занесення у сховище (форматування)

o Збереження даних локально

o Автономна робота (без прив'язки до місця)

o Синхронізація з сервером бази даних (в обидві сторони)

Доступ:

o Зареєстровані користувачі системи

Взаємодія:

o Компонент взаємодії клієнтської частини з базою даних

o Компонент зберігання інформації (локально)

Таким чином, можна виділити три концептуальні рівні проекту:

1. Інтерфейс користувача (WEB-сайт, програма Windows Mobile)

2. Сервіси

3. База даних

Графічне представлення схеми проекту наведене в рис. 5



Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Рисунок 5. Загальна схема проекту

3.2 Сценарій роботи системи

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

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

Конструктор опитувань

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

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

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

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

Клієнтська програма

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