Курсова робота
з дисципліни: Бази даних
на тему: В«АІС для ГОУДОД Центру розвитку творчості дитинства і юнацтва В»
Зміст
1.Теоретіческая частина
1.1 Процеси проектування
1.2 Інфологіческое проектування
1.3 Концептуальне проектування
1.4 Логічне проектування
1.5 Засоби створення моделі
2. Практична частина
2. 1 Спеціальна частина
2.1.1 Етапи виконання курсової роботи
2.2 Технологічна частина
2.2.1 Фізичне проектування
2.3 Інструкція користувачеві
Висновок
1. Теоретична частина
1.1 Процеси проектування
Проектування програмних систем складається з проектування процесів, даних і подій. У силу специфіки курсу ми розглядаємо лише проектування даних - процес розробки структури бази даних у відповідності до вимог замовників. В ході розробки проекту потрібно відповісти на наступні питання:
В· що представляють собою вимоги замовників, і в якій формі вони виражені;
В· як вони перетворюються в структуру бази даних;
В· як часто і яким чином структура бази даних повинна перебудовуватися.
В даний час розглядаються три рівні абстракції для визначення структури даних: концептуальний (точка зору замовника), логічний (точка зору розробника) і фізичний (точка зору адміністратора БД). У відповідності з цим розглядаються три рівні моделі і три кроки проектування. Деякі джерела стверджують, що ні фізичної моделі, ні кроку фізичного проектування насправді немає. Обговорення цього погляду проведемо, коли уточнимо зміст всіх трьох видів абстракції.
Концептуальний рівень - найбільш загальне уявлення про інформаційному змісті предметної області. Представляється у вигляді концептуальної моделі (КМ), яка часто називається концептуальною схемою або інформаційною структурою. КМ володіє високим ступенем стабільності, вона проблемно-орієнтована і не залежить від конкретної СУБД, операційної системи і апаратного забезпечення. Її поведінка повинна бути повністю передбачувано.
Концептуальне уявлення оперує основними елементарними даними предметної області, званими сутностями. Сутності описуються атрибутами. Дані можуть знаходитися в деякому відношенні один з одним: утворювати асоціації. Ці асоціації називаються зв'язками. КМ повинна підтримувати узгодженість зв'язків в межах рівня деталізації.
Зазвичай для концептуального представлення використовується модель В«Сутність-Зв'язокВ» (ER-модель), яка графічно виражається ER-діаграмами. Існують різні модифікації представлення (нотації) діаграм. Раніше вже приводилися відомості про ER-моделі. Додамо, що, не тільки сутності, але і зв'язки можуть мати атрибути, що виражають їх властивості. Представлення моделі зовні нагадує структуру бази даних і служить для відображення на логічну модель.
Логічний рівень уявлення оперує такими поняттями, як запис, компоненти запису, зв'язки між записами. Відповідна йому модель називається логічною (ЛМ), вона являє собою відображення концептуальної моделі в середу конкретної СУБД. Іноді розглядають не конкретну СУБД, а тільки її клас (модель) - ієрархічну, мережну або реляційну. Особливості цих моделей розглядалися раніше.
Фізичний рівень демонструє фізичне зберігання даних. На цьому рівні використовуються такі поняття, як фізичні блоки, файли, збережені записи, покажчики. Взаємозв'язку між збереженими записами, що виникають у процесі їх угруповання, а також індексні структури теж розглядаються на рівні фізичної моделі (ФМ). З точки зору чистої бази даних можна абстрагуватися від фізичної моделі представлення даних, але знати її дуже корисно для досягнення більш високої продуктивності системи. Якщо є можливість впливати на ФМ і є уявлення про способи оптимізації в її рамках, скористатися ними може бути корисно, особливо для розподілених даних. Але реально майже ніколи це не робиться.
Є й інша класифікація рівнів подання даних. Відповідно до стандарту ANSI/SPAC, архітектура БД представлена ​​трирівневою моделлю із зовнішнім, концептуальним і внутрішнім рівнями. На відміну від попередньої моделі, це не модель проектування, модель оперування даними.
Зовнішній рівень - опис мовою користувача структури даних, виду і форми їх представлення, а також опис операцій маніпулювання даними. Вважається, що для опису предметної області використовується кілька зовнішніх моделей. Даний рівень містить риси як КМ, так і ЛМ, описаних раніше.
Концептуальний рівень - найбільш загальне уявлення про інформаційному змісті предметної області. Визначення збігається з наведеним раніше.
Внутрішній рівень - організована сукупність структурованих даних, відображення концептуальної моделі в конкретну середу зберігання. Легко бачити, що це поняття об'єднує раніше певні логічну і фізичну моделі.
Розглядаючи ці два підходу до опису представлення даних, приходимо до висновку, що перший більш прагматичний. У ньому предметна область розглядається як єдине ціле, а не як сукупність проектних вимог, званих зовнішніми моделями. Реально проектні вимоги рідко можна назвати повноцінною моделлю, так як будь-яка модель повинна давати на якомусь рівні адекватне уявлення про предметну області. Отримані ж вимоги часто виступають як сукупність уявлень про неї різних груп користувачів. Така ситуація виникає в тих випадках, коли аналітик вважає, що користувачі формулюють свої знання як локальні моделі, сукупність яких і повинна складати необхідну модель. Невірність цього твердження добре ілюструється відомої індійської казкою про дослідження слона п'ятьма сліпцями, в ході якого вони запропонували свої локальні моделі слона (дослідник хобота вважав, що слон схожий на канат, хвоста - на мітелку, боки - на стіну, вуха - на лист, ноги - на колону). Реально користувач часто не в змозі побудувати навіть локальну інформаційну модель, а про глобальні зв'язки між ними і говорити не доводиться. Інше міркування. Популярне в даний час напрямок проектування - перепроектування технологічних процесів (реінжиніринг бізнес-процесів - BPR) - заперечує такий підхід в силу того, що він консервує існуючу технологію і не дає виділити мету виробництва. А раз неможливо виділити загальну мету виробництва, результат даного етапу дослідження не можна вважати моделлю. Але можна, ввівши поняття типу користувача (Експерта), розглядати відповідну зовнішню модель як точку зору цього експерта на предметну область. У цьому випадку концептуальна модель представляється як єдине ціле, доповнене сукупністю точок зору експертів.
инфологической підхід не надає формальних способів моделювання реальності, але він закладає основи методології проектування баз даних.
Тепер розглянемо три основних рівня проектування: Інфологіческое, концептуальне і логічне - з точки зору першого підходу.
1.2 Інфологіческое проектування
Основними завданнями інфологіческого проектування є визначення предметної області системи і формування погляду на ПЗ з позицій спільноти майбутніх користувачів БД, тобто инфологической моделі ПО.
Інфологіческая модель ПО являє собою опис структури та динаміки ПО, характеру інформаційних потреб користувачів в термінах, зрозумілих користувачеві і не залежних від реалізації БД. Це опис виражається в термінах не окремих об'єктів ПО і зв'язків між ними, а їх типів, пов'язаних з ними обмежень цілісності і тих процесів, які призводять до переходу предметної області з одного стану в інший.
1.3 Концептуальне проектування
На етапі концептуального проектування визначаються інформаційні потреби та локальні представлення предметної області. Виявляється роль, призначення, взаємозв'язок даних, провод...
