База даних "Теорія та практика прикладного програмування"

ЗМІСТ
ВСТУП 7
1 ОПИС ПРЕДМЕТНОЇ ОБЛАСТІ 8
2 ПРОЕКТУВАННЯ ІНФОРМАЦІЙНОЇ СИСТЕМИ 10
2.1 Концептуальне (інфологічне) проектування 10
2.1.1 Побудова ER-діаграми 12
2.1.2 Нормалізація даних 14
2.2 Даталогічне проектування баз даних 17
2.3 Фізичне проектування інформаційних систем 20
2.3.1 СУБД Access 20
2.3.2 Об’єкти Access 21
2.3.3 Створення таблиць 22
2.3.4 Створення запитів 27
2.3.5 Створення форм 35
3 ІНСТРУКЦІЯ КОРИСТУВАЧА 40
ВИСНОВКИ 42
ПЕРЕЛІК ВИКОРИСТАНИХ ДЖЕРЕЛ 43

ВСТУП
Для прийняття обґрунтованих та ефективних рішень у виробничій діяльності, в управлінні економікою і в політиці сучасний фахівець повинен уміти за допомогою комп'ютерів і засобів зв'язку одержувати, накопичувати, зберігати й обробляти дані, представляючи результат у виді наочних документів.
Сучасне життя немислиме без ефективного управління. Важливою категорією є системи обробки інформації, від яких багато в чому залежить ефективність роботи будь-якого підприємства чи установи. Така система повинна:
• забезпечувати отримання загальних та / або деталізованих звітів за підсумками роботи;
• дозволяти легко визначати тенденції зміни найважливіших показників;
• забезпечувати отримання інформації, критичної за часом, без істотних затримок;
• виконувати точний і повний аналіз даних. [1]
У світі існує безліч систем керування базами даних. Незважаючи на те, що вони можуть по-різному працювати з різними об'єктами і надавати користувачу різні функції й засоби, більшість СУБД спираються на єдиний усталений комплекс основних понять. В якості такого об’єкту ми виберемо СУБД Microsoft Access, що входить в пакет Microsoft Office.
У курсовій роботі представлено проектування інформаційної системи «Теорія та практика прикладного програмування».
1 ОПИС ПРЕДМЕТНОЇ ОБЛАСТІ
База даних «Теорія та практика прикладного програмування» призначена для зберігання, обробки та пошуку інформації про зміст окремих глав підручника з програмування.
Головним конструктором баз даних є адміністратор.
Адміністратор бази даних — особа, що відповідає за вироблення вимог до бази даних, її проектування, реалізацію, ефективне використання та супровід, включаючи управління обліковими записами користувачів БД і захист від несанкціонованого доступу. Не менш важливою функцією адміністратора БД є підтримка цілісності бази даних.
Користувач — особа або організація, яка використовує діючу систему для виконання конкретної функції. Зокрема, Користувач АС — особа, яка бере участь у функціонуванні автоматизованої системи або використовує результати її функціонування. [2]
З точки зору інформаційної безпеки, користувачем є тільки людина. Програма ж, що працює за її завданням, є вже суб'єктом. З її допомогою користувач взаємодіє з системою, можливо включеною в мережу, і отримує створюване нею робоче середовище. Користувачем є людина, що використовує систему або мережу для вирішення поставлених перед нею завдань. Її називають кінцевим користувачем.
Базою даних «Теорія та практика прикладного програмування» можуть користуватися молоді програмісти, які займаються вивченням мови програмування Delphi, студенти та абітурієнти, викладачі, користувачі Інтернета та вахівці з програмування. У БД зберігається інформація про зміст розділів підручника, компоненти, функції та процедури, що в ньому розглядаються.
Рисунок 1.1 – Модель предметної області ІС «Теорія та практика
прикладного програмування»
2. ПРОЕКТУВАННЯ ІНФОРМАЦІЙНОЇ СИСТЕМИ
Поняття предметної області бази даних є одним з базових понять інформатики і не має точного визначення. Його використання в контексті ІС припускає існування стійкої в часі співвіднесеності між іменами, поняттями та певними реаліями зовнішнього світу, що не залежить від самої ІС та її кола користувачів. Таким чином, введення в розгляд поняття предметної області бази даних обмежує і робить доступним для огляду простір інформаційного пошуку в ІС і дозволяє виконувати запити за кінцевий час.
Сукупність реалій (об'єктів) зовнішнього світу — об'єктів, про які можна ставити питання, — утворює об'єктне ядро предметної області, яке має онтологічний статус. Не можна отримати в ІС відповідь на питання про те, що їй невідомо.[3]
Проектування бази даних — це впорядкований процес створення такої моделі предметної області, яка зв’язує дані, що зберігаються в базі з об’єктами предметної області, що описуються цими даними.
Проектування баз даних, як правило, відіграє одну з ключових ролей у більшості проектів. Грамотно спроектована база дозволяє без особливих проблем вносити зміни, змінювати структуру системи.
Повний етап проектування бази даних складається з трьох частин:
1. Концептуального (або інфологічного) проектування.
2. Даталогічного проектування.
3. Фізичного проектування.
2.1 Концептуальне (інфологічне) проектування
Концептуальне проектування — це збір, аналіз та редагування вимог до даних. Для цього здійснюються наступні заходи:
· обстеження предметної області, вивчення її інформаційної структури;
· виявлення всіх фрагментів, кожен з яких характеризується користувальницьким поданням, інформаційними об'єктами і зв'язками між ними, процесами над інформаційними об'єктами;
· моделювання та інтеграція всіх уявлень.
Після закінчення цього етапу одержуємо концептуальну модель, інваріантну до структури бази даних. Часто вона представляється у вигляді моделі «сутність-зв'язок».
Зв'язок — це асоціювання двох чи більш сутностей. Якби призначенням бази даних було тільки збереження окремих, не пов'язаних між собою даних, то її структура могла б бути дуже простою. Проте одна з основних вимог до організації бази даних — це забезпечення можливості відшукання одних сутностей за значеннями інших, для чого необхідно встановити між ними певні зв'язки. А так як в реальних базах даних нерідко містяться сотні або навіть тисячі сутностей, то теоретично між ними може бути встановлено більше мільйона зв'язків. Наявність такої безлічі зв'язків і визначає складність інфологічних моделей. [4]
У даній інформаційній системі основними об'єктами є:
· Глава з властивостями: Код параграфа, Затрата времени на изучение, Код оператора, Компоненты, Код таблицы, Код рисунка, Код примечания, Код листингов, Дата разработки записи;
· Листинги з властивостями: Названия листинга, Работа с формой, Листинг;
· Операторы з властивостями: Ключевые слова, Синтаксис оператора, Семантика оператора, Пример использования;
· Параграфы з властивостями: Название параграфа, Краткое содержание, Начальная страница, Конечная страница;
· Примечания з властивостями: Страница, Примечание;
· Рисунки з властивостями: Название рисунка, Страница расположения рисунка, Рисунок;
· Таблицы властивостями: Название таблицы, Страница нахождения, Таблица.
2.1.1 Побудова ER-діаграми
В даний час при моделюванні структур баз даних однією з найпоширеніших нотацій є модель даних Entity-Relation (Сутність-Зв'язок), запропонована П. Ченом. При ER-моделюванні в предметній області виділяються певні класи реальних чи логічних об'єктів, які називаються сутностями. Далі між сутностями встановлюються різні зв'язки і взаємозалежності, які називають відносинами.
Результати ER-моделювання зазвичай представляють у вигляді ER-діаграм, на яких у вигляді прямокутників позначаються модельовані сутності, а у вигляді з'єднуючих їх ліній — відносини.
Модель "сутність-зв'язок" (ER-модель) (англ. Entity-relationship model або entity-relationship diagram) — модель даних, яка дозволяє описувати концептуальні схеми за допомогою узагальнених блочних конструкцій. ER-модель — це мета-модель даних, тобто засіб опису моделей даних. [5]
ER-модель зручна при проектуванні інформаційних систем, баз даних, архітектур комп'ютерних додатків та інших систем (моделей). За допомогою такої моделі виділяють найбільш суттєві елементи (вузли, блоки) моделі і встановлюють зв'язки між ними.
ER-модель зручна при проектуванні інформаційних систем, баз даних, архітектур комп'ютерних програм, і інших систем (далі — моделей). З її допомогою можна виділити ключові сутності, що присутні в моделі, і позначити зв’язки, які можуть встановлюватися між цими сутностями. Важливо відзначити, що самі зв’язки також є сутностями (виділяються в окремі графічні блоки), що дозволяє встановлювати зв’язки на безлічі самих відносин.
Рисунок 2.1.1 – ER-діаграма
Для цього використовуються наступні позначення:
1. Сутність зображається прямокутниками.
2. Атрибути позначаються овалами (або прямокутниками з закругленими кутами).
3. Зв’язки зображаються ромбами.
2.1.2 Нормалізація даних
Нормалізація таблиць бази даних — перший крок на шляху реалізації структури реляційної бази даних.
Теорія нормалізації реляційних баз даних була розроблена у кінці 70-х років 20 століття. Відповідно до неї, виділяються шість нормальних форм, п'ять з яких так і називаються: перша, друга, третя, четверта, п'ята нормальна форма, а також нормальна форма Бойса-Кодда, що лежить між третьою і четвертою.
База даних вважається нормалізованою, якщо її таблиці (принаймні, більшість таблиць) представлені як мінімум в третій нормальній формі. Часто багато таблиці нормалізуються до четвертої нормальної форми.
Головна мета нормалізації бази даних — усунення надмірності та дублювання інформації. В ідеалі при нормалізації треба домогтися, щоб будь-яке значення зберігалося в базі в одному примірнику, причому значення це не повинно бути отримано розрахунковим шляхом з інших даних, що зберігаються в базі.
Перша нормальна форма: [6]
· Забороняє повторювання стовпців, що містять однакову за змістом інформацію;
· Забороняє множинні стовпці (що містять значення типу списку і т.п.);
· Вимагає визначити первинний ключ для таблиці, тобто той стовпець або комбінацію стовпців, які однозначно визначають кожен рядок.
Друга нормальна форма вимагає, щоб неключові стовпці таблиць залежали від первинного ключа в цілому, але не від його частини (якщо таблиця знаходиться в першій нормальній формі і первинний ключ у неї складається з одного стовпця, то вона автоматично знаходиться і в другій нормальній формі).
Щоб таблиця перебувала в третій нормальній формі, необхідно, щоб неключові стовпці в ній не залежали від інших неключових стовпців, а залежали лише від первинного ключа. Найпоширеніша ситуація в даному контексті — це розрахункові стовпці, значення яких можна отримати шляхом будь-яких маніпуляцій з іншими стовпцями таблиці. Для приведення таблиці в третю нормальну форму такі стовпці з таблиць треба видалити.
Нормальна форма Бойса-Кодда вимагає, щоб в таблиці був тільки один потенційний первинний ключ. Найчастіше у таблиць, що знаходяться в третій нормальній формі, так і буває, але не завжди. Якщо виявився другий стовпець (комбінація стовпців), що дозволяє однозначно ідентифікувати рядок, то для приведення до нормальної форми Бойса-Кодда такі дані треба винести в окрему таблицю.
Для приведення таблиці, що знаходиться в нормальній формі Бойса-Кодда, до четвертої нормальної форми необхідно усунути наявні в ній багатозначні залежності. Тобто забезпечити, щоб вставка / видалення будь-якого рядка таблиці не вимагала б вставки / видалення / модифікації інших рядків цієї ж таблиці.
Таблицю, що знаходиться в четвертій нормальній формі ще можна розбити на три або більше таблиць, з'єднавши які ми отримаємо вихідну таблицю. Отриману в результаті такої, як правило, дуже штучної декомпозиції таблицю і називають таблицею, що знаходяться в п'ятій нормальній формі. Формальне визначення п'ятої нормальної форми таке: це форма, в якій усунені залежності з'єднання. У більшості випадків практичної користі від нормалізації таблиць до п'ятої нормальної форми не спостерігається.
Рисунок 2.1.2 – Нормалізована ER-діаграма (3НФ)
2.2 Даталогічне проектування баз даних
При переході від інфологічної моделі до даталогічної слід мати на увазі, що інфологічна модель включає в себе всю інформацію про предметну область, необхідну для проектування БД. Це не означає, що всі суті, зафіксовані в ІЛМ, повинні в явному вигляді відображатися в даталогічній моделі. Перш ніж будувати даталогічну модель, необхідно вирішити, яка інформація буде зберігатися в базі даних. Наприклад, у інфологічній моделі мають бути відображені показники, що обчислюються, але зовсім не обов'язково, щоб вони зберігалися в базі даних.
Таблиця 2.2.1. «Глава»
Поле Тип даних Розмір
№ п/п Лічильник Довге ціле
Код параграфа Числовий Довге ціле
Затрата времени на изучение Числовий Довге ціле
Код оператора Числовий Довге ціле
Компоненты Логічний
Код таблицы Числовий Довге ціле
Код рисунка Числовий Довге ціле
Код примечания Числовий Довге ціле
Код листингов Числовий Довге ціле
Дата разработки записи Дата/час
Таблиця 2.2.2. «Листинги»
Поле Тип даних Розмір
Код листинга Лічильник Довге ціле
Название листинга Текстовий 50
Работа с формой Логічний
Листинг Поле МЕМО
Таблиця 2.2.3. «Операторы»
Поле Тип даних Розмір
Код оператора Лічильник
Ключевые слова Текстовий 200
Синтаксис оператора Текстовий 240
Семантика оператора Текстовий 255
Пример использования Числовий Довге ціле
Таблиця 2.2.4. «Параграфы»
Поле Тип даних Розмір
Код параграфа Лічильник
Название параграфа Текстовий 50
Краткое содержание Текстовий 250
Начальная страница Числовий Довге ціле
Конечная страница Числовий Довге ціле
Таблиця 2.2.5. «Примечания»
Поле Тип даних Розмір
Код примечания Лічильник
Страница Числовий Довге ціле
Примечание Поле МЕМО
Таблиця 2.2.6. «Рисунки»
Поле Тип даних Розмір
Код рисунка Лічильник
Название рисунка Текстовий 65
Страница расположения
рисунка Числовий Довге ціле
Рисунок Поле МЕМО
Таблиця 2.2.7. «Таблицы»
Поле Тип даних Розмір
Код таблицы Лічильник
Название таблицы Текстовий 60
Страница нахождения Числовий Довге ціле
Таблица Поле МЕМО
Структура таблиць відноситься до 3 НФ:
1) кожен стовпець таблиці неподільний і в рамках однієї таблиці немає стовпців з однаковими за змістом значеннями.
2) первинні ключі таблиць однозначно визначають запис і не надмірні.
3) значення будь-якого поля не входить у первинний ключ, не залежить від значення іншого поля, що також не входить у первинний ключ.
2.3 Фізичне проектування інформаційних систем
Фізичне проектування — це безпосереднє проектування програмних модулів, з яких збирається додаток; це точка зору програміста на додаток.
Перехід від логічного до фізичного опису моделі складається з наступних кроків: [7]
1. Всі прості сутності перетворюються у зв’язки, ім'я сутності стає ім'ям відношення.
2. Кожен атрибут стає можливим стовпцем з тим же ім'ям. Стовпці, що відповідають необов'язковим атрибутам, можуть містити NULL-значення.
3. Компоненти унікального ідентифікатора сутності перетворюються в первинний ключ відношення.
4. Зв'язки «багато до одного» стають зовнішніми ключами.
З огляду на пряму відповідність логічної моделі та фізичної реалізації, остання чітко відображає перше, вносячи деякі уточнення за способом зберігання інформації. Тобто з урахуванням всього вищесказаного про розробку логічної моделі АС і логічної схеми БД отримана фізична модель БД.

Внимание, отключите Adblock

Вы посетили наш сайт со включенным блокировщиком рекламы!
Ссылка для скачивания станет доступной сразу после отключения Adblock!

Скачать полную версию