Создание веб-ресурса дистанционного образования

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

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

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

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

Недоліки систем управління базами даних:

          великий розмір;

          вартість СУБД;

          витрати на перетворення інформації;

          більш серйозні наслідки при виході системи з ладу;

          складність.

Забезпечення функціональності, який повинна володіти кожна СУБД, супроводжується значним ускладненням програмного забезпечення

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

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

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

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

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

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

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

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

Таблиця 2.3

Співвідношення термінів на різних етапах проектування.

Загальна методика переходу до фізичної моделі:

1.      Денормалізація реляційної моделі.

2.      Перетворення реляційної моделі в фізичну модель:

  - кожне відношення перетворюється на таблицю;

   - кожен атрибут стає стовбцем таблиці;

   - первинний ключ відношення стає первинним ключом таблиці;

   - для стовбців при необхідності задаються діапазони значень.

3.      Перейменування таблиць та атрибутів фізичної моделі.

4.      Генерація фізичної моделі за допомогою CASE-засобу.

5.      Перейменування ключів (первинних та зовніх), посилальних зв'язків.

6.      Розробка віртуальних відношень.

7.      Написання тригерів.

8.      Написання процедур та функцій користувача.

3. РЕАЛІЗАЦІЯ СИСТЕМИ ОБМІНУ ТЕКСТОВИМИ ПОВІДОМЛЕННЯМИ

Впровадження (реалізація) системи - це процес установки апаратного і програмного забезпечення і початок реальної роботи ІС.

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

Процес реалізації бази даних подано на рис.3.1

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

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

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

При переході на нову систему можна використовувати один з підходів:

1. Прямий перехід - стара ІАС виводиться з експлуатації після появи нової.

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

3. Послідовний перехід - застосовується, коли можлива заміна елементів ІАС одного за іншим

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

          Методика впровадження ІАС на основі БД

1. Планування впровадження

У плані впровадження указуються заходи щодо впровадження, для кожного з яких визначені очікувані дати завершення, оцінки витрат і відповідальні виконавці.

2. Тестування програм і підготовка устаткування

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

Розробка плану, що визначає етапи і терміни виконання робіт

Написання коду програм

Тестування програм

Документування програм

Навчання користувачів

Установка і використання програмної системи

3. Вибір і навчання персоналу

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

4. Тестування системи

Покрокове тестування

Обробка тестових операцій

Обробка реальних операцій

5. Документування системи

для розробників

для операторів

для користувачів

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

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

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

Більшість інформаційних систем реалізовуються у вигляді зірки. У центрі розташовується могутня система управління базами даних, що накопичує і оброблювальна основну масу інформації. Як периферійні клієнтські системи виступають настільні додатки, такі, як, наприклад DB2, Paradox, MS Excel, dBase і т.д.

До моменту появи SQL Server 2000 вже було створено достатньо багато різних систем, призначених для зберігання даних і управління ними. Крім SQL Server 6.x і радніших версій існує ще цілий ряд продуктів, використовуваних і до цього дня. Кількість даних, накопичених на цих системах, вельми значно.

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

Етапи перетворення даних:

1.              Рішення питання про те, які файли даних повинні бути перетворені.

2.              Перевірка повноти і усунення неточностей.

3.              Саме перетворення даних.

4.              Перевірка нових файлів на предмет коректності перетворення.

5.              Якщо перетворення було тривалим, то нові файли повинні бути оновлені операціями, що відбулися в період перетворення.

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

7.              Створення документації про проведене перетворення даних.

Проблема перетворення даних:

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

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

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

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

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

Метою експорту даних є надання зовнішнім системам інформації, що зберігається на СУБД. При цьому дані перетворяться у формат, зрозумілий зовнішній системі. Наприклад, якщо потрібно передати дані в MS Excel, то результатом виконання експорту буде xls-файл.