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

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

Тим самим виконується правило, що кожне явище або об'єкт може бути представлено тільки однією сутністю. Не може бути двох однакових сутностей і повинен існувати унікальний ідентифікатор для кожної сутності (no entity without identity).

На діаграмі кожна сутність повинна обов'язково супроводжуватися визначенням, яке звичайно відповідає на два питання: - що відрізняє екземпляри даної сутності від екземплярів іншої сутності? - що відрізняє екземпляри даної сутності один від одного?

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

Модель сутність-зв'язок показано в додатку Б.

2.2 Логічне проектування

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

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

Обґрунтування і вибір моделі даних.

В даний час існує декілька сотень різних реляційних СУБД для мейнфреймів і мікрокомп'ютерів, хоча для багатьох з них визначення реляційної моделі носить дещо перебільшений характер. Як приклад розрахованих на багато користувачів СУБД може служити система CA-Openlngres фірми Computer Associates і систему Informix фірми Informix Software, Inc. Прикладами реляційних СУБД для персональних комп'ютерів є Access і FoxPro фірми Microsoft, Paradox і Visual dBase фірми Borland, а також R:Base фірми Microrim. Реляційні СУБД відносяться до СУБД другого покоління (покоління подані в таблиці 2.1). Реляційна модель відбулася. Проте вже тоді розширювався круг додатків, для яких ця технологія була неадекватною. Прикладами можуть служити мультимедійні додатки, системи, що оперують просторово-часовими даними, системи автоматизації проектування, CASE-системи.

Проте реляційна модель також володіє деякими недоліками - зокрема, обмеженими можливостями моделювання. Для вирішення цієї проблеми був виконаний великий об'єм дослідницької роботи. У 1976 році П. Чен запропонував модель "суть-зв'язок (Entity-Relationship model - ER-модель) ", яка в даний час стала найпоширенішою технологією проектування баз даних. У 1979 році Э. Кодд зробив спробу усунути недоліки власної основоположної роботи і опублікував розширену версію реляційної моделі - RM/T (1979), потім ще одну версію - RM/V2 (1990). Спроби створення моделі даних, що дозволяє точніше описувати реальний світ, нестрого називають семантичним моделюванням даних (semantic data modeling).

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

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

Таблиця 2.1

Покоління розвитку СУБД

Розробка даталогічної моделі бази даних.

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

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

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

Всі відношення знаходяться у 1НФ, тому що :

1.   Усі атрибути кожного відношення є атомарними, тобто неподільними

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

3.   Значення кожного стовпця має однаковий формат, тобто є однорідним

4.   Порядок рядків у кожному відношенні неістотний

Усі відношення моделі мають первинні ключові атрибути та описові атрибути, які функціонально повинні залежати від ключа, тому відношення знаходяться у 2НФ.

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

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

2.4 Фізичне проектування бази даних.

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

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

Етап процедури вибору СУБД:

1. Визначення предметної області проведеного дослідження

2. Скорочення списку вибору до двох-трьох продуктів

3. Оцінка продуктів

4. Проведення обґрунтованого вибору і підготовка звіту

Визначення проблемної області проведеного дослідження.

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

Оцінка продуктів.

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

Таблиця 2.2

Параметри оцінки СУБД

СУБД володіють як багатообіцяючими потенційними перевагами, так і недоліками. Переваги:

          контроль за надмірністю даних;

          більше корисної інформації при тому ж обсязі збережених даних;

          несуперечність даних;

          підтримка цілісності даних;

          підвищена безпека;

          застосування стандартів;

          підвищення ефективності з ростом масштабів системи;

          можливість перебування компромісу при суперечливих вимогах;

          підвищення приступності даних і їхньої готовності до роботи;

          поліпшення показників продуктивності;

          спрощення супроводу системи за рахунок незалежності відданих;

          поліпшене керування рівнобіжною роботою;

          розвиті служби резервного копіювання і відновлення;

          контроль за надмірністю даних.

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

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

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

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

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