Загрузка...
Учебная работа. Курсовая работа: База даних Теорія та практика прикладного програмування 3
Українська інженерно-педагогічна академія
Гірничий факультет
Кафедра інформаційних технологій
ПОЯСНЮВАЛЬНА ЗАПИСКА
до курсової роботи
з дисципліни «Проектування та експлуатація інформаційних систем»
на тему:
«База даних “Теорія та практика прикладного програмування” (Літературне джерело: “Бобровский С.И. Delphi 7. Учебный курс – СПб.: Питер, 2004. – 736 с.: ил”. Сторінки: 14–54)»
Виконав:
ст. гр. ДГ-К7-1
Заіка О.І.
Керівник: Лавриненко Н. В.
Стаханов
2009
УІПА, гірничий факультет
Кафедра інформаційних технологій
Дисципліна «Проектування та експлуатація інформаційних систем»
Спеціальність 6.01010036
Курс 3 Група ДГ-К7- 1 Семестр 5
Форма № У-6.01
Затв. наказом Мінвузу УССР
від 3 серпня 1984 р. №253
ЗАВДАННЯ
на курсовий проект студента
Заіки Олександра Ігоровича
1. Тема проекту база даних “Теорія та практика прикладного програмування” (Літературне джерело: “Бобровский С.И. Delphi 7. Учебный курс – СПб.: Питер, 2004. – 736 с.: ил”. Сторінки: 14–54)
2. Термін здачі студентом закінченого проекту до 5 грудня 200 р.
3. Початкові дані до проекту Загальні вимоги до баз даних: забезпечення функціонування, цілісності та скорочення збитковості. Наявність обгрунтованої кількості віконних форм та таблиць (від 4 до 7). Реалізація 7 запитів різного типу, в тому числі обов’язкові запити з використанням розрахунків та з формуванням звіту. Загальна кількість полів в універсальній таблиці (від 20 до 30). В базі даних можуть бути поля з додатковою інформацією розробника. Кількість записів визначається змістом інформації в базі даних. Обов’язкові поля: з операторами, поясненням їх синтаксису та семантики, приклади програм або їх фрагментів, картинки.
4. Зміст розрахунково-пояснювальної записки (перелік питань, що їх належить розробити) Вступ з обов’язковим посиланням на літературу, в якій вказується актуальність і ефективність використання баз даних. Опис предметної області та користувачів бази даних. Проектування бази даних (інфологічне, даталогічне та фізичне проектування). Інструкція з експлуатації інформаційної системи з ілюстраціями (опис використання бази даних різними користувачами системи). Висновки з обов’язковим переліком кількісних даних, що характеризують інформаційну систему. Використані джерела. Додатки.
До записки додається диск з програмним продуктом.
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових креслень) Схема використання інформаційної системи; ER – діаграма — початкова та нормалізована; екранні копії таблиць, бланків запитів за зразком, вікон, звітів, тощо.
6. Дата видачі завдання Дата видачі завдання 17 вересня 2009 р.
Календарний план
№
Найменування етапів курсового проектування
Термін виконання
Примітки
1.
Затвердження та підписування завдання. Вступ. Вивчення фактичних даних інформаційної системи за заданою літературою.
до 01.10
2.
Опис предметної області та користувачів системи. Заповнення даними універсального відношення.
до 08.10
Активна співпраця з керівником проекту
3.
Інфологічне проектування. Вихідна ER-діаграма. Нормалізація діаграми
до 15.10
Активна співпраця з керівником проекту
4.
Даталогічне проектування. Універсальне відношення. Таблиці та зв’язки між ними. Нормалізація таблиць
до 29.10
Активна співпраця з керівником проекту
5.
Фізичне проектування інформаційної систем в СУБД Access (таблиці, запити, форми, звіти, макроси і т.п.)
до 19.11
Активна співпраця з керівником проекту
6.
Тестування інформаційної системи. Внесення в систему, при необхідності, змін та доповнень.
до 26.11
Активна співпраця з керівником проекту
7.
Оформлення тексту пояснювальної записки: титульна сторінка, зміст, етапи проектування, результати тестування, інструкція з експлуатації, висновки, перечень використаних джерел та додатки
до 30.11
Активна співпраця з керівником проекту
8.
Представлення керівнику роботи на перевірку
до 5.12
9.
Бота з зауваженнями керівника. Вилучення неточностй та помилок. Підготовка студентом роботи до захисту
до 05.12
10
Захист курсової роботи перед комісією
від 05.12
до 10.12
Комісія: завідувач кафедри, керівники проекту
Студент______________
Керівник_____________ Лавриненко Н. В.
17 вересня 2009 р.
Реферат
Курсовий проект: 47 с., 42 рис., 10 табл., 10 джерел.
О’єктом дослідження є довідкова інформація, що міститься у певних главах посібника з прикладного програмування Літературне джерело: “Бобровский С.И. Delphi 7. Учебный курс – СПб.: Питер, 2004. – 736 с.: ил”. Сторінки: 14–54).
Предметом дослідження є проектування та експлуатація інформаційних систем.
Метою дослідження є закріплення теоретичних знань, отриманих при вивченні навчальної дисципліни «Проектування та експлуатація інформаційних систем» і придбання навичок у використанні сучасних інформаційних технологій для виготовлення програмних продуктів, що підтримують функціонування інформаційних систем.
Методи дослідження. Для вирішення поставлених задач застосовані:
загальнонаукові методи: теоретичного пошуку; концептуально-порівняльного аналізу, визначення теоретичних і прикладних аспектів дослідження, визначення структури і змісту підготовки;
емпіричні методи: дослідження предметної області, дослідження о’єкту, що вивчається у штучно створених для нього умовах, порівняння о’єкту, що досліджується з аналогом;
способ створення інформаційної системи довідкового призначення. Введення даних до ІС згідно моделі сутність-зв’язок з обов’язковою нормалізацією даних; створення запитів та форм.
Теоретична значущість дослідження:
розроблена інформаційна система, на базі якої були засвоєні теоретичні відомості про інформацію, її обробку та зберігання; етапи проектування ІС, метод та необхідність нормалізації; загальні відомості про боту з базами даних та їх супроводження у середовищі MS Access.
Удобна значущість
була розроблена інформаційна система, що дозволяє отримувати у зручному, обычному для сприйняття, та, як наслідок, зрозумілому користувачеві вигляді довідкову інформацію з посібника, яка може бути корисною при вирішенні задач, пов’язаних з прикладним програмуванням.
Результати дослідження можуть бути використані в інженерних та інженерно-педагогічних ВНЗ.
СУТНІСТЬ, база ДАНИХ, АДМІНІСТРАТОР, ТАБЛИЦЯ, ЗАПИТ, ФОРМА, КОРИСТУВАЧ, КІНЦЕВИЙ КОРИСТУВАЧ, ПРЕДМЕТНА ОБЛАСТЬ, ПРОЕКТУВАННЯ БД, КОНЦЕПУТАЛЬНЕ ПРОЕКТУВАННЯ, АТРИБУТ, ЗВ’ЯЗОК, ER-ДІАГРАМА, МОДЕЛЬ «СУТНІСТЬ-ЗВ’ЯЗОК», НОРМАЛІЗАЦІЯ, ФІЗИЧНЕ ПРОЕКТУВАННЯ, СУБД, ЗВІТ, МАКРОС,ФІЗИЧНЕ ПРОЕКТУВАННЯ, МОДУЛЬ
Зміст
Вступ. 8
1. Опис предметної області 9
2. Проектування інформаційної системи. 11
2.1 Концептуальне (інфологічне) проектування. 11
2.1.1 Побудова ER-діаграми. 13
2.1.2 Нормалізація даних. 14
2.2 Даталогічне проектування баз даних. 19
2.3 Фізичне проектування інформаційних систем. 24
2.3.1 СУБД Access. 25
2.3.2 О’єкти Access. 26
2.3.3 Створення таблиць. 26
2.3.4 Створення запитів. 32
2.3.5 Створення форм. 39
3. Інструкція користувача. 47
Висновки. 50
Перелік використаних джерел. 51
Вступ
Основні ідеї сучасної інформаційної технології базуються на концепції, відповідно до якої дані повинні бути організовані у бази даних з метою адекватного відображення мінливого настоящего світу і задоволення інформаційних потреб користувачів. Ці бази даних створюються і функціонують під управлінням спеціальних програмних комплексів, які називаються системами управління базами даних (СУБД).
Збільшення обсягу та структурної складності збережених даних, розширення кола користувачів інформаційних систем призвели до широкого поширення найбільш зручних і порівняно простих для розуміння реляційних (табличних) СУБД. Для забезпечення одночасного доступу до даних безлічі користувачів, нерідко розташованих досить далековато один від 1-го і від місця зберігання баз даних, створені мережеві багатодоступні версії БД заснованих на реляційній структурі. У их тим чи іншим шляхом вирішуються специфічні проблеми паралельних процесів, цілісності (правильності) і безпеки даних, а також санкціонування доступу.
У курсовій роботі представлено проектування інформаційної системи «Теорія та практика прикладного програмування».
Метою даної курсової роботи є закріплення теоретичних знань, отриманих при вивченні навчальної дисципліни «Проектування та експлуатація інформаційних систем» і придбання навичок у використанні сучасних інформаційних технологій для виготовлення програмних продуктів, що підтримують функціонування інформаційних систем.
1. Опис предметної області
база даних «Теорія та практика прикладного програмування» призначена для зберігання, обробки та пошуку інформації про зміст підручника з програмування.
Головним конструктором баз даних є адміністратор. Адміністратор здійснює боту з супроводу баз даних у компьютер‘ютерних системах. До його основних обов’язків належить забезпечення збереження інформації, коректування БД за завданнями користувачів, визначення ефективності баз даних, консультування користувачів.
Користувач — це особа, яка користується інформацією, що міситься у базах даних. Зокрема, Користувач автоматизованої системи — особа, яка бере участь у функціонуванні автоматизованої системи або використовує результати її функціонування [2].
З точки зору інформаційної безпеки, користувачем є тільки людина. Програма ж, що працює за її завданням, є вже суб’єктом. З її допомогою користувач взаємодіє з системою, можливо включеною в мережу, і отримує створюване нею робоче середовище. Користувачем є людина, що використовує систему або мережу для вирішення поставлених перед нею завдань. Її називають кінцевим користувачем.
Базою даних «Теорія та практика прикладного програмування» можуть користуватися молоді програмісти, які займаються вивченням мови програмування Delphi. У БД зберігається інформація про зміст розділів підручника, компоненти, функції та процедури, що в ньому розглядаються.
Набросок 1.1 – Модель предметної області ІС «Теорія та практика прикладного програмування»
2. Проектування інформаційної системи
Під предметною областю розуміють стійкий зв’язок між іменами, поняттями та о’єктами зовнішнього світу, що не залежить від самої інформаційної системи та кола її користувачів. Введення в розгляд поняття предметної області бази даних обмежує і робить доступним для огляду простір інформаційного пошуку в базі даних і дозволяє виконувати запити за кінцевий час [3].
Проектування бази даних — це впорядкований процес створення такої моделі предметної області, яка зв’язує дані, що зберігаються в базі з о’єктами предметної області, що описуються цими даними.
Проектування баз даних, як правило, відіграє одну з ключових ролей у більшості проектів. Хорошо спроектована база дозволяє без особливих заморочек вносити зміни, змінювати структуру системи [4].
Повний етап проектування бази даних складається з трьох частин:
1. Концептуального (або інфологічного) проектування.
2. Даталогічного проектування.
3. Фізичного проектування.
2.1 Концептуальне (інфологічне) проектування
Проектування бази даних складається з кількох етапів і починається з попередньої структуризації предметної області. Перш за все, необхідно виділити всі о’єкти, які будуть використовуватися в базі даних, вказати їх властивості (свойства) та встановити зв’язки між ними. Цей етап називають концептуальним проектуванням бази даних.
Для опису предметної області використовують три основні конструктивні елементи сутність, атрибут і зв’язок.
Сутність — це узагальнене поняття для позначення безлічі однорідних о’єктів, інформацію про які необхідно збирати і зберігати в інформаційній системі. Сутність визначається своїм унікальним ім’ям і переліком атрибутів, що характеризують властивості сутності.
Атрибут — це пойменована черта суті, яка приймає значення з деякої множини допустимих значень. Атрибути моделюють властивості сутності.
Зв’язок – це графічно зображена асоціація, призначена для позначення виділеної відносини між двома або більше сутностями [1].
У даній інформаційній системі основними о’єктами є:
Главы з властивостями: № главы, заглавие главы, короткое содержание, исходная страничка, конечная страничка;
Подглавы з властивостями: № главы, код подглавы, заглавие подглавы, исходная страничка, конечная страничка;
Параграфы з властивостями: код параграфа, № главы, код подглавы, заглавие параграфа, исходная страничка, конечная страничка, главные слова которые упоминаются, процедуры которые упоминаются, функции которые упоминаются, характеристики компонент которые упоминаются, типы переменных которые упоминаются, определения, фрагменты кода, картинки, таблицы;
Таблицы з властивостями: код параграфа, заглавие таблицы, содержание таблицы;
Типы переменных з властивостями: код параграфа, тип переменной, описание;
Фрагменты кода з властивостями: код параграфа, фрагмент кода, описание;
Картинки з властивостями: код параграфа, заглавие рисунка, набросок;
Функции властивостями: код параграфа, функция, описание;
Главные слова з властивостями: код параграфа, код главного слова, ключевое слово, описание.
2.1.1 Побудова ER-діаграми
ER-модель є однією з самих простих візуальних моделей даних (графічних нотацій). Вона дозволяє визначити структуру в загальних рисах [5]. Це загальний опис структури називається ER-діаграмою або онтологією вибраної предметної області.
На етапі переходу до реалізації даної ER-діаграми у вигляді реальної інформаційної системи або програми, відбувається відображення ER-моделі в більш детальну модель даних реляційної (о’єктної, мережевої, логічної, або ін) бази даних, яка називається фізичною моделлю даних по відношенню до вихідної ER-діаграмі.
Модель Сутність-Зв’язок (ER-модель) (англ. entity-relationship model або entity-relationship diagram) — це модель даних, що дозволяє описувати концептуальні схеми. Вона надає графічну нотацію, засновану на блоках і з’єднуючих їх лініях, за допомогою яких можна описувати о’єкти і відносини між ними будь-якої іншої моделі даних. У цьому сенсі ER-модель є мета-моделлю даних, тобто є засобом опису моделей даних.
ER-модель зручна при проектуванні інформаційних систем, баз даних, архітектур компьютер‘ютерних програм, і інших систем (далі — моделей). З її допомогою можна виділити ключові сутності, що присутні в моделі, і позначити зв’язки, які можуть встановлюватися між цими сутностями. Важливо відзначити, що самі зв’язки також є сутностями (виділяються в окремі графічні блоки), що дозволяє встановлювати зв’язки на безлічі самих відносин [1].
Для цього використовуються наступні позначення:
Сутність зображається прямокутниками.
Атрибути позначаються овалами (або прямокутниками з закругленими кутами).
Зв’язки зображаються ромбами.
Набросок 2.1.1 – ER-діаграма
2.1.2 Нормалізація даних
У базі даних можуть перебувати дані, що повторюються, які призводять до надмірності даних. Надмірність даних є причиною аномалій, які виявляються в некоректному оновленні, видаленні та редагуванні даних, що в свою чергу стає причиною порушення таковых властивостей бази даних, як цілісність, несуперечність, логічна і фізична незалежність. Мінімальна надмірність досягається шляхом виключення повторюваних записів. Але іноді повне усунення надмірності недоцільно [6].
Нормалізація — це розбиття таблиці на дві або більше, що володіють кращими властивостями при включенні, зміні та видаленні даних. Остаточна мета нормалізації зводиться до отримання такового проекту бази даних, в якому кожен факт з’являється лише в одному місці, тобто виключена надмірність інформації. Це робиться не стільки з метою економії пам’яті, скільки для виключення можливої суперечливості збережених даних [7].
Процес нормалізації складається з кількох етапів, на дерматологическому з яких визначаються так звані нормальні форми: 1НФ, 2 НФ, 3 НФ, НФБК, 4НФ, 5НФ (форма проекції зв’язків). У більшості проектів третя нормальна форма завершує процес нормалізації.
Таблиця знаходиться у першій нормальній формі (1НФ) тоді і тільки тоді, если жоден з її рядків не містить у будь-якому своєму полі більше 1-го значення і жодне з її ключових полів не порожньо.
Таблиця знаходиться в другій нормальній формі (2НФ), якщо вона задовольняє визначенням 1НФ і всі її поля, що не входять до первинного ключа, пов’язані повною функціональною залежністю з первинним ключем.
Таблиця знаходиться в третій нормальній формі (3НФ), якщо вона задовольняє визначенням 2НФ і не одне з її неключових полів не залежить функціонально від будь-якого іншого неключового поля.
Таблиця знаходиться в нормальній формі Бойса-Кодда (НФБК), якщо і тільки якщо будь-яка функціональна залежність між її полями зводиться до повної функціональної залежності від можливого ключа.
Таблиця знаходиться у п’ятій нормальній формі (5НФ) тоді і тільки тоді, если в кожній її повній декомпозиції всі проекції містять можливий ключ. Таблиця, яка не має жодної повної декомпозиції, також знаходиться в 5НФ. Повною декомпозицією таблиці називають таку сукупність довільного числа її проекцій, підключення яких повністю збігається з вмістом таблиці.
Четверта нормальна форма (4НФ) є окремим випадком 5НФ, если повна декомпозиція виновата бути з’єднанням рівно двох проекцій. Вельми не попросту підібрати реальну таблицю, що може бути надана в 4НФ, але не була б у 5НФ.
Набросок 2.1.2 – Нормалізована ER-діаграма (3НФ)
2.2 Даталогічне проектування баз даних
На даному етапі о’єкти й зв’язки між ними перетворюють в логічну модель даних. Існує кілька логічних моделей даних. Серед их виділяють реляційну (від англ. Relation — відношення), ієрархічну і мережеву.
Ця база даних є реляційної. У ній о’єкти й зв’язки між ними представляються у вигляді таблиць (відносин), що складаються з рядків і стовпців. Стовпець — це поле, рядок — це запис. Кожне поле має ім’я і тип. Імена полів — це атрибути (вони визначаються властивостями о’єкта). Тип задає спосіб представлення атрибуту.
Реляційна модель даних має такі властивості:
кожен елемент таблиці — один елемент даних;
всі поля в таблиці є однорідними, тобто мають один тип;
кожне поле має унікальне ім’я;
однакові записи в таблиці відсутні.
Складемо таблиці з відповідними їм атрибутами, використовуючи дані наведені вище. Для дерматологического атрибуту встановимо логічно відповідний йому тип даних.
Таблиця 2.2.1. «Главы»
Поле
Тип даних
Розмір
№ главы
Числовий
Довге ціле
Заглавие главы
Текстовий
50
Короткое содержание
Поле МЕМО
Исходная страничка
Числовий
Довге ціле
Конечная страничка
Числовий
Довге ціле
Таблиця 2.2.2. «Подглавы»
Поле
Тип даних
Розмір
№ главы
Числовий
Довге ціле
Код подглавы
Текстовий
5
Заглавие подглавы
Текстовий
45
Исходная страничка
Числовий
Довге ціле
Конечная страничка
Числовий
Довге ціле
Таблиця 2.2.3. «Параграфы»
Поле
Тип даних
Розмір
Код параграфа
Числовий
Довге ціле
№ главы
Числовий
Довге ціле
Код поглавы
Текстовий
5
Заглавие параграфа
Текстовий
30
Исходная страничка
Числовий
Довге ціле
Конечная страничка
Числовий
Довге ціле
Главные слова, которые упоминаются
Текстовий
15
Процедуры, которые упоминаются
Текстовий
60
Функции, которые упоминаются
Текстовий
15
характеристики компонент, которые упоминаются
Текстовий
35
Типы переменных, которые рассматриваются
Текстовий
15
определения
Поле МЕМО
Фрагменты кода
Логический
Картинки
Логический
Таблицы
Логический
Таблиця 2.2.4. «Таблицы»
Поле
Тип даних
Розмір
Код параграфа
Числовий
Довге ціле
Заглавие таблицы
Текстовий
10
Содержание таблицы
Поле о’єкту OLE
Таблиця 2.2.5. «Типы переменных»
Поле
Тип даних
Розмір
Код параграфа
Числовий
Довге ціле
Тип переменной
Текстовий
10
Описание
Поле МЕМО
Таблиця 2.2.6. «Фрагменты кода»
Поле
Тип даних
Розмір
Код параграфа
Числовий
Довге ціле
Фрагмент кода
Поле МЕМО
Описание
Поле МЕМО
Таблиця 2.2.7. «Функции»
Поле
Тип даних
Розмір
Код параграфа
Числовий
Довге ціле
Функция
Текстовий
10
Описание
Поле МЕМО
Таблиця 2.2.8. «Процедуры»
Поле
Тип даних
Розмір
Код параграфа
Числовий
Довге ціле
Процедура
Текстовий
10
Описание
Поле МЕМО
Таблиця 2.2.9. «Главные слова»
Поле
Тип даних
Розмір
Код параграфа
Числовий
Довге ціле
Код главного слова
Числовий
Довге ціле
Ключевое слово
Текстовий
10
Описание
Поле МЕМО
Таблиця 2.2.10. «Картинки»
Поле
Тип даних
Розмір
Код параграфа
Числовий
Довге ціле
Заглавие рисунка
Текстовий
50
Набросок
Поле о’єкту OLE
структура таблиць відноситься до 3 НФ:
1) кожен стовпець таблиці неподільний і в рамках однієї таблиці немає стовпців з однаковими за змістом значеннями.
2) первинні ключі таблиць совершенно точно визначають запис і не надмірні.
3) значення будь-якого поля не заходить у первинний ключ, не залежить від значення іншого поля, що також не заходить у первинний ключ.
2.3 Фізичне проектування інформаційних систем
Фізичний етап проектування полягає в реалізації створеного проекту на компьютер‘ютері. Фізична модель бази даних визначає спосіб розміщення даних (файлів) на пристроях зовнішньої пам’яті ЕОМ, а також способи і засоби організації ефективного доступу до их. У цілому файлова структура та система управління є прерогативою операційної системи, тому по відношенню до баз даних, орієнтованих на боту з елементами даних і високу інтенсивність обміну, ефективність введення / виводу, вона буде не оптимальна. Операційна система з завданнями баз даних справляється погано.
Система управління базами даних (СУБД), її мова, набагато більша, ніж набір файлової системи операційного середовища. Тобто СУБД бере на для себя безпосередньо керування зовнішньою пам’яттю, мінімально використовуючи операційну систему.
Стадія фізичного проектування БД включає:
вибір способу організації БД;
розробку специфікації внутрішньої схеми БД засобами моделі даних;
опис відображення концептуальної схеми БД у внутрішній структурі управління файлами.
На відміну від ранніх СУБД багато сучасних системи, у тому числі і Access не надають розробнику будь-якого вибору на стадії фізичного проектування. На цій стадії можна говорити не про варіанти фізичного проектування, а про варіанти реалізації. Тобто, після створення даталогічної моделі фізичне проектування включає:
вибір СУБД;
оновлення структури таблиць;
призначення типів полів для розподілу атрибутів сутностей;
можливе створення таковых додаткових о’єктів як індекси, тригери (обробники подій) і процедури, що зберігаються, що полегшують пошук в таблицях і обробку даних контролю цілісності [9].
Дана інформаційна система розроблена в СУБД Access, основною перевагою якої є можливість створення і експлуатації досить потужних баз даних без необхідності щось програмувати. Ще одне додаткова перевага Access – інтегрованість цієї програми з Excel, Word та іншими програмами пакета MS Office.
2.3.1 СУБД Access
Система управління базами даних (СУБД) — спеціалізована програма (частіше комплекс програм), що призначена для організації і ведення бази даних. [10]
СУБД Access заходить до складу обширно розповсюдженого сімейства офісних додатків Microsoft Office. Microsoft Access на сьогоднішній денек є одним з найпоширеніших настільних додатків для роботи з базами даних. Це пов’язано з тим, що Access володіє дуже широким діапазоном засобів для введення, аналізу та представлення даних. Ці кошти є не тільки простими і зручними, а й високопродуктивними, що забезпечує високу швидкість розробки додатків. Спочатку Access мала ряд унікальних можливостей, таковых як вміння зводити воєдино інформацію з різних джерел (електронних таблиць, текстових файлів, інших баз даних), подання даних в зручному для користувача вигляді за допомогою таблиць, діаграм, звітів, інтеграція з іншими компонентами Microsoft Office. Вдосконалюючись від версії до версії, Access стала інструментом, який може задовольнити потреби самих різних категорій користувачів: від новачка, якому подобається дружній інтерфейс системи, що дозволяє йому впоратися із завданнями, до професійного розробника, який має весь необхідний інструментарій для побудови унікального рішення для определенного підприємства середнього бізнесу.
2.3.2 О’єкти Access
Таблиці — це основні й найнеобхідніші о’єкти будь-якої БД. Саме в таблицях зберігаються всі дані. Реляційна БД може містити цілий набір взаємозв’язаних таблиць.
Запити — це спеціалізовані структури, що створюються для здійснення обробки бази даних. За допомогою запитів можна упорядкувати дані, виконати їх фільтрацію, о’єднання, відбір або навіть зміну.
Форми — це о’єкти, що дозволяють вводити в базу нові дані або переглядати вже існуючі у зручній для користувача формі (вигляді, поданні).
Звіти — ці о’єкти говорять самі за для себя. Вони видають дані на принтер або інший пристрій виводу (це може бути і монітор), у зручному та наочному вигляді. Наприклад, у вигляді бланку або рахунку.
Макроси — це набір макрокоманд. Если виникає необхідність нередкого виконання одних і тих же операцій з БД, є можливість згрупувати набір установок в один макрос. Після чого ініціалізацію його виконання закріплюють за певною комбінацією клавіш клавіатури. Простими словами, натискання цієї комбінації при роботі з базою призводить до виконання всієї послідовності дій, що записані у макрос.
Модулі — це програми, що створені засобами мови Visual Basic. Вони дозволяють доповнити стандартні засоби Access, якщо наявних вже не вистачає для задоволення всіх вимог до роботи СУБД. Програміст може розширити можливості системи, дописавши необхідні модулі та додавши їх у БД [4].
2.3.3 Створення таблиць
У Microsoft Office Access дані організовуються в таблиці — сукупності рядків і стовпців, аналогічні паперам бухгалтера або книзі Microsoft Office Excel. Визначення структури бази даних потрібно завжди починати зі створення її таблиць. Таблиці створюються раніше будь-яких інших о’єктів бази даних.
Ординарна база даних може складатися всього з однієї таблиці. Більшість баз даних включають декілька таблиць. Наприклад, в одній таблиці можуть зберігатися відомості про продукти, у другій — відомості про замовлення, а в третьому — відомості про клієнтів.
Усі таблиці бази даних «Теорія та практика прикладного програмування» були створені у режимі конструктора.
Набросок 2.3.1 – Таблиця «Главы»
Набросок 2.3.2 – Таблиця «Подглавы»
Набросок 2.3.3 – Таблиця «Таблицы»
Набросок 2.3.4 – Таблиця «Параграфы»
Набросок 2.3.5 – Таблиця «Типы переменных»
Набросок 2.3.6 – Таблиця «Фрагменты кода»
Набросок 2.3.7 – Таблиця «Функции»
Набросок 2.3.8 – Таблиця «Главные слова»
Набросок 2.3.9 – Таблиця «Процедуры»
Набросок 2.3.10 – Таблиця «Картинки»
Так як дана база є реляційною, то вона містить не окремі таблиці, а групи взаємопов’язаних таблиць. Для створення зв’язків між таблицями використовувалася команда Схема даних меню Сервіс.
Набросок 2.3.11 – Схема даних
2.3.4 Створення запитів
Запити створюються користувачем для вибірки потрібних даних з одної або декількох пов’язаних таблиць. Запит може формуватися за допомогою запитів за зразком QBE або за допомогою мови структурованих запитів SQL. З допомогою запиту можна також оновити, видалити, додати дані в таблиці або створити нові таблиці на основі вже існуючих [7].
QBE — запит за зразком — засіб для пошуку необхідної інформації в базі даних. Він формується не на спеціальній мові, а шляхом заповнення бланка запиту у вікні Конструктора запитів.
SQL-запити — це запити, які складаються (програмістами) з послідовності SQL-інструкцій. Ці інструкції задають, що треба зробити з вхідним набором даних для генерації вихідного набору. Всі запити Access будує на основі SQL-запитів. Щоб побачити їх, необхідно в активному вікні проектування запиту виконати команду Вид / SQL.
Існує кілька типів запитів: на вибірку, на оновлення, на додавання, на видалення, перехресний запит, створення таблиць. Найбільш поширеним є запит на вибірку. Запити на вибірку використовуються для відбору потрібної користувачу інформації, що міститься в таблицях. Вони створюються тільки для пов’язаних таблиць [9]. Запит «Наличие таблиц» виводить інформацію про параграфи у яких присутні таблиці.
Набросок 2.3.12 – Запит «Наличие таблиц» у режимі Конструктора
Набросок 2.3.13 – Бота запиту «Наличие таблиц»
Запит «Кол-во страничек в параграфах» дозволяє отримати інформацію про загальну кількість сторінок у параграфі. Для побудови цього використовувався будівник виразів, за допомогою якого було створено поле, що обчислюється, «Кол-во страничек: [Параграфы]![Конечная страница]-[Параграфы]![Начальная страница]»
Набросок 2.3.14 – Запит «Кол-во страничек в параграфах» у режимі Конструктора
Набросок 2.3.15 – Бота запиту «Кол-во страничек в параграфах»
Запит «Кол-во определений» надає відомості про загальну кількість визначень у БД. Це груповий запит, в якому була використана функція COUNT().
Набросок 2.3.16 – Запит «Кол-во определений» у режимі Конструктора
Набросок 2.3.17 – Бота запиту «Кол-во определений»
Запит «Поиск по фрагменту кода» є параметричним запитом, що дозволяє відобразити зазначений користувачем фрагменти коду.
Набросок 2.3.18 – Запит «Поиск по фрагменту кода» у режимі Конструктора
Набросок 2.3.19 – Бота запиту «Поиск по фрагменту кода»
Запит «Поиск типа переменной» є запитом на відбірку, що дозволяє відобразити введений користувачем тип змінної.
Набросок 2.3.20 – Запит «Поиск типа переменной» у режимі Конструктора
Набросок 2.3.21 – Бота запиту «Поиск типа переменной»
Запит «Поиск пустых полей» виконує пошук параграфів, в яких немає інформації про: определения, главные слова, функции, характеристики компонент, типы переменных.
Набросок 2.3.22 – Запит «Поиск пустых полей» у режимі Конструктора
Набросок 2.3.23 – Бота запиту «Поиск пустых полей»
Запит «Без подчиненных» дозволяє побачити параграфи, яким не відповідає ні один запис у підпорядкованої таблиці «Типы переменных».
Набросок 2.3.24– Запит «Без подчиненных» у режимі Конструктора
Набросок 2.3.25 – Бота запиту «Без подчиненных»
2.3.5 Створення форм
Форми призначені для введення, перегляду та коректування взаємозв’язаних даних бази на екрані в зручному вигляді, який може відповідати звичному для користувача документу. Форми також можуть використовуватися для створення панелей управління в додатку користувача.
Зовнішній вигляд форми вибирається в залежності від того, з якою метою вона створюється. Форми Access дозволяють виконувати завдання, які не можна виконати в режимі таблиці. Форми дозволяють обчислювати значення і виводити на екран итог. Джерелом даних для форми є записи таблиці або запиту.
Всі форми БД «Теорія та практика прикладного програмування» були створені за допомогою Майстра. Відкриття форм здійснюється натисканням відповідних клавиш на кнопковій формі (Набросок 2.3.26), яка створена за допомогою Диспетчеру кнопкових форм (меню Сервіс—Службові програми—Диспетчер кнопкових форм). При запуску БД кнопкова форма запускається автоматично.
Форма «Главы» (Набросок 2.3.27) містить коротку інформацію про главу, початкову та кінцеву сторінку та інформацію про підглави.
Основною формою є форма «Параграфы» (Набросок 2.3.28), так як вона містить інформацію про вміст параграфів посібника (її назву, початкову та кінцеву сторінки, функції, ключові слова, процедури, властивості компонентів, типи змінних, що згадуються; визначення; дані про таблиці, функції та фрагменти коду, що містяться).
Набросок 2.3.27 – Форма «Главы»
Набросок 2.3.28 – Форма «Параграфи»
Форма «Типы переменных» (Набросок 2.3.29) відкривається натисканням клавиши «Типы переменных» у нижній правій частині форми «Параграфы» (Набросок 2.3.28) і містить інформацію про типи змінних, що розглядаються у параграфах.
Набросок 2.3.29 – Форма «Типы переменных»
Форма «Главные слова» (Набросок 2.3.30) містить дані про ключовы слова, які приводяться у параграфах; формы «Таблицы» та «Картинки» (Набросок 2.3.32) (Набросок 2.3.37) містять аналогічну інформацію щодо таблиць та рисунків; формы «Функции» та «Процедури» (Набросок 2.3.33) (Набросок 2.3.36) надають дані про функції та процедури, а форма «Фрагменты кода» (Набросок 2.3.34) — про фрагменти коду. Всі ці форми відкриваються натисканням відповідних клавиш у нижній частині форми «Параграфи» (Набросок 2.3.28).
Набросок 2.3.30 – Форма «Главные слова»
Набросок 2.3.32 – Форма «Таблицы»
Набросок 2.3.33 – Форма «Функции»
Набросок 2.3.34 – Форма «Фрагменты кода»
Набросок 2.3.35 – Форма «Типы переменных»
Набросок 2.3.36 – Форма «Процедуры»
Набросок 2.3.37 – Форма «Картинки»
Форма «Запросы» (Набросок 2.3.38) містить у собі клавиши виклику запитів, що маються у БД, та довідку про запити (Набросок 2.3.39).
Набросок 2.3.38 – Форма «Запросы»
Набросок 2.3.39 – Форма «Запросы»
Форма «О создателе» (Набросок 2.3.40) надає свідоцтво про создателя.
Набросок 2.3.40 – Форма «О создателе»
3. Інструкція користувача
Ласкаво просимо в довідкову систему бази даних «Теорія та практика прикладного програмування».
база даних «Теорія та практика прикладного програмування» призначена для зберігання довідкової інформації, що міститься у певних главах посібника з прикладного програмування (Бобровский С.И. Delphi 7. Учебный).
Після запуску БД автоматично запускається головна кнопкова форма (Набросок 3.1).
Набросок 3.1 – Інтерфейс головної кнопкової форми
Після натискання клавиши (1) відкриється форма «Главы» (Набросок 3.2). При натисканні на клавишу (2) відкриється форма «Параграфы»( Набросок 3.3), клавиша (3) відкриває форму для вибору запиту (итог запиту відображається у вигляді звіту), а клавиша (4) відомості про создателя. При натисканні на гіперпосилання «инструкция юзера» (5) відкриється документ Word у якому приводиться довідка стосовно користування базою.
Набросок 3.2 – Інтерфейс форми «Главы»
При натисканні на клавишу «Подглавы» відкриється форма «Подглавы».
Набросок 3.3 – Інтерфейс форми «Параграфы»
Зміст полів відображається у (6), для відкриття форм «Тип переменных», «Главные слова», «Процедуры», «Функции», «Фрагменти кода», «Картинки», «Таблицы» необхідно скористуватися клавишами (7). Навігация по базі данних відбувається за допомогою навігатора (8).
Висновки
У процесі даної курсової роботи була спроектована та реалізована в СУБД MS Access інформаційна система «Теорія та практика прикладного програмування».
У цій базі даних зберігається довідкова інформація, що міститься у певних главах посібника з прикладного програмування (Бобровский С.И. Delphi 7. Учебный). база містить запити, що дозволяють здійснювати пошук необхідних даних та відображати статистичну інформацію, як то: інформацію про те, які глави які підглави містять, та про початкову й кінцеву сторінки цих підглав; відомості про присутність у тій чи іншій главі рисунків; відображення зазначеного користувачем фрагменту коду та типу змінних; вивід результату розрахунку загальної кількості сторінок у підглавах; пошук пустих полів.
Дана система пройшла всі три етапи проектування. На інфологічному рівні структура бази даних була відображена у вигляді ER-діаграми, яка надалі була приведена до третьої нормальної форми. На даталогічному рівні — представлена реляційною моделлю. У таблицях був усунений надлишок. Безпосередня бота з СУБД з формування таблиць і їх заповнення на компьютер‘ютері була проведена на стадії фізичного проектування. Також було проведено тестування БД.
Таковым чином, було створено 10 таблиць, 7 запитів, 14 форм, 8 макросів та 7 звітів. Розмір файлу БД — 12,9 Мб.
Надалі дану систему можна вдосконалювати, відповідно до потреб користувачів.
Перелік використаних джерел
1. Кириллов В.В. Базы проектирования реляционных баз данных. Учебное пособие. — СПб.: ИТМО, 1994. — 90 с.
2. ГОСТ 34.003-90. Муниципальный эталон Русской Федерации: «Информационная разработка. Комплекс эталонов на автоматические системы. Автоматические системы. Определения и определения». — М.: ИПК Издательство эталонов, 2002.
3. Дейт Д. Введение в систему баз данных. — М., СПб.: BHV — Санкт-Петербург, 1977. — 312 с.
4. HTTP://ru.wikipedia.org/ . — Вільна енциклопедія.
5. Інформаційні системи і технології /Карпенко С.Г., Попов В.В., Тарнавський Ю.А. та ін. — К.: МАУП, 2004. — 192с.
6. Лук’янова В.В. компьютер’ютерний аналіз даних: Посібник. — К.: Академія, 2003. — 344с.
7. Основи інформаційних систем: Навчальний посібник /Ситник В.Ф., Писаревська, Ерьоміна Н.В., Краєва О.С. Ред Ситник В.Ф. — К.: КНЕУ, 1997. — 252с.
8. Оскерко В.С., Пунчик З.В. Практикум по технологиям баз данных: Учебное пособие. — Минск: БГЭУ, 2004. — 170с.
9. Конспект лекций по дисциплине «Информационные системы в ПК »
10. HTTP://www.lessons-tva.info/ . — Безкоштовне дистанційне навчання інформатиці, телекомунікаціям та основам електронного бізнесу.
]]>