астина процесу полягає у використанні цієї інформації для розробки проекту основних відносин. Цей процес вимагає наявності глибоких знань про функціональні можливості, що надаються цільової СУБД.
Однією з найважливіших цілей фізичного проектування бази даних є організація ефективного зберігання даних [8]. Наприклад, якщо вибірка рядків з даними про співробітників компанії повинна виконуватися по іменах в алфавітному порядку, то найбільш придатною структурою для зберігання цих даних є файл, відсортований по іменах співробітників. А якщо повинна виконуватися вибірка даних про всіх співробітників, зарплата яких знаходиться в певному діапазоні, файл, відсортований по іменах співробітників, не підходить для виконання такого завдання. Становище ще більше ускладнюється у зв'язку з тим, що деякі способи організації файлів добре підходять для масової завантаження даних в базу даних, але їх застосування надалі стає неефективним. Іншими словами, завдання полягає у використанні ефективної структури зберігання даних на зовнішньому пристрої, яка забезпечує швидке завантаження бази даних, а потім її перетворення в структуру, більш відповідну для повсякденної експлуатації.
База даних являє собою винятково важливий корпоративний ресурс і тому захист цього ресурсу має виняткове значення. На стадії збору та аналізу вимог, що становить частину життєвого циклу програми бази даних, повинні бути враховані і відображені в специфікації вимог до системи конкретні вимоги до захисту. Призначення цього етапу полягає у визначенні способів реалізації вимог до захисту. Склад засобів захисту залежить від конкретної системи.
Серед різноманіття засобів моделювання систем в методологіях структурного аналізу найбільш часто і ефективно застосовуються такі діаграми:
- ERD (Entity Relationship Diagrams) - діаграми «сутність-зв'язок»;
- DFD (Data Flow Diagrams) - діаграми потоків даних спільно зі словниками даних і специфікаціями процесів.
Всі вони містять графічні і текстові засоби моделювання системи: перші - для забезпечення точного визначення її компонентів і зв'язків, другі - для зручності демонстрування функціонування основних компонентів моделі.
DFD показує зовнішні по відношенню до системи джерела і стоки (адресати) даних, ідентифікує логічні функції (процеси) і групи елементів даних, що пов'язують одну функцію з іншою (потоки), а так само ідентифікує сховища (накопичувачі ) даних, до яких здійснюється доступ. Структури потоків даних і визначення їх компонентів зберігаються і аналізуються в базі даних. Кожна логічна функція (процес) може бути деталізована за допомогою DFD нижнього рівня. Вміст кожного сховища так само зберігають у базі даних, модель якої розкривається за допомогою ERD.
Таким чином, будується логічна функціональна специфікація - докладний опис того, що повинна робити система, звільнена, наскільки це можливо, від розгляду шляхів реалізації, що дає проектувальнику чітке уявлення про кінцеві результати, яких потрібно досягти.
Для проектування описаних вище діаграм використовуються CASE - засоби (Computer Aided Software Engineering).
Для проектування ERD використовують програмний засіб ERwin, яке являє собою набір засобів концептуального моделювання даних. ERwin реалізує проектування схеми бази даних і генерацію її опису на мові цільової СУБД.
Для проектування DFD використовується програмний засіб BPwin, яке є провідним інструментом візуального моделювання бізнес-процесів. BPwin дає можливість наочно уявити будь-яку діяльність або структуру у вигляді моделі.
Для побудови логічної моделі бази даних насамперед, необхідно визначити набір сутностей і задати зв'язки між ними. Проведений аналіз поставлених перед комплексом завдань, процесів, що протікають при виконанні цих завдань і даних, необхідних для здійснення цих процесів, дозволив скласти структури таблиць і зв'язків між ними.
На підставі аналізу нижче наведені описи призначення кожної з таблиць, а так само їх структуру.
Навчальна група - таблиця, що містить відомості про групу, яка навчається у спортивній школі (таблицю 2.1).
Тренера - викладачі - таблиця, що містить дані про викладачів (таблицю 2.2).
Учні - таблиця, що містить індивідуальні дані про учнів (таблицю 2.3).
Зарахування - таблиця, що містить інформацію про стані учня школи (таблицю 2.4).
У таблицях свідомо вказані імена полів, які будуть використовуватися при побудові фізичної моделі.
Таблиця 2.1 - Сутність «Навчальна група»
КлючАтрібутІмя в таблиці «GROUP» Тип данних1234? Код...
