База даних Теорія та практика прикладного програмування 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). Реалізація семи запитів різного типу, в тому числі обов’язкові запити з використанням розрахунків та з формуванням звіту. Загальна кількість полів в універсальній таблиці (від 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-ДІАГРАМА, МОДЕЛЬ «СУТНІСТЬ-ЗВ'ЯЗОК», НОРМАЛІЗАЦІЯ, ФІЗИЧНЕ ПРОЕКТУВАННЯ, СУБД, ЗВІТ, МАКРОС,ФІЗИЧНЕ ПРОЕКТУВАННЯ, МОДУЛЬ
Зміст
Основні ідеї сучасної інформаційної технології базуються на концепції, відповідно до якої дані повинні бути організовані у бази даних з метою адекватного відображення мінливого реального світу і задоволення інформаційних потреб користувачів. Ці бази даних створюються і функціонують під управлінням спеціальних програмних комплексів, які називаються системами управління базами даних (СУБД).
Збільшення обсягу та структурної складності збережених даних, розширення кола користувачів інформаційних систем призвели до широкого поширення найбільш зручних і порівняно простих для розуміння реляційних (табличних) СУБД. Для забезпечення одночасного доступу до даних безлічі користувачів, нерідко розташованих досить далеко один від одного і від місця зберігання баз даних, створені мережеві багатодоступні версії БД заснованих на реляційній структурі. У них тим чи іншим шляхом вирішуються специфічні проблеми паралельних процесів, цілісності (правильності) і безпеки даних, а також санкціонування доступу.
У курсовій роботі представлено проектування інформаційної системи «Теорія та практика прикладного програмування».
Метою даної курсової роботи є закріплення теоретичних знань, отриманих при вивченні навчальної дисципліни «Проектування та експлуатація інформаційних систем» і придбання навичок у використанні сучасних інформаційних технологій для виготовлення програмних продуктів, що підтримують функціонування інформаційних систем.
База даних «Теорія та практика прикладного програмування» призначена для зберігання, обробки та пошуку інформації про зміст підручника з програмування.
Головним конструктором баз даних є адміністратор. Адміністратор здійснює роботу з супроводу баз даних у комп'ютерних системах. До його основних обов'язків належить забезпечення збереження інформації, коректування БД за завданнями користувачів, визначення ефективності баз даних, консультування користувачів.
Користувач — це особа, яка користується інформацією, що міситься у базах даних. Зокрема, Користувач автоматизованої системи — особа, яка бере участь у функціонуванні автоматизованої системи або використовує результати її функціонування [2].
З точки зору інформаційної безпеки, користувачем є тільки людина. Програма ж, що працює за її завданням, є вже суб'єктом. З її допомогою користувач взаємодіє з системою, можливо включеною в мережу, і отримує створюване нею робоче середовище. Користувачем є людина, що використовує систему або мережу для вирішення поставлених перед нею завдань. Її називають кінцевим користувачем.
Базою даних «Теорія та практика прикладного програмування» можуть користуватися молоді програмісти, які займаються вивченням мови програмування Delphi. У БД зберігається інформація про зміст розділів підручника, компоненти, функції та процедури, що в ньому розглядаються.
Рисунок 1.1 – Модель предметної області ІС «Теорія та практика прикладного програмування»
2. Проектування інформаційної системи
Під предметною областю розуміють стійкий зв'язок між іменами, поняттями та об'єктами зовнішнього світу, що не залежить від самої інформаційної системи та кола її користувачів. Введення в розгляд поняття предметної області бази даних обмежує і робить доступним для огляду простір інформаційного пошуку в базі даних і дозволяє виконувати запити за кінцевий час [3].
Проектування бази даних — це впорядкований процес створення такої моделі предметної області, яка зв’язує дані, що зберігаються в базі з об’єктами предметної області, що описуються цими даними.
Проектування баз даних, як правило, відіграє одну з ключових ролей у більшості проектів. Грамотно спроектована база дозволяє без особливих проблем вносити зміни, змінювати структуру системи [4].
Повний етап проектування бази даних складається з трьох частин:
1. Концептуального (або інфологічного) проектування.
2. Даталогічного проектування.
3. Фізичного проектування.
2.1 Концептуальне (інфологічне) проектування
Проектування бази даних складається з кількох етапів і починається з попередньої структуризації предметної області. Перш за все, необхідно виділити всі об'єкти, які будуть використовуватися в базі даних, вказати їх властивості (характеристики) та встановити зв'язки між ними. Цей етап називають концептуальним проектуванням бази даних.
Для опису предметної області використовують три основні конструктивні елементи сутність, атрибут і зв'язок.
Сутність - це узагальнене поняття для позначення безлічі однорідних об'єктів, інформацію про які необхідно збирати і зберігати в інформаційній системі. Сутність визначається своїм унікальним ім'ям і переліком атрибутів, що характеризують властивості сутності.
Атрибут - це пойменована характеристика суті, яка приймає значення з деякої множини допустимих значень. Атрибути моделюють властивості сутності.
Зв'язок – це графічно зображена асоціація, призначена для позначення виділеної відносини між двома або більше сутностями [1].
У даній інформаційній системі основними об'єктами є:
Главы з властивостями: № главы, название главы, краткое содержание, начальная страница, конечная страница;
Подглавы з властивостями: № главы, код подглавы, название подглавы, начальная страница, конечная страница;
Параграфы з властивостями: код параграфа, № главы, код подглавы, название параграфа, начальная страница, конечная страница, ключевые слова которые упоминаются, процедуры которые упоминаются, функции которые упоминаются, свойства компонентов которые упоминаются, типы переменных которые упоминаются, определения, фрагменты кода, рисунки, таблицы;
Таблицы з властивостями: код параграфа, название таблицы, содержание таблицы;
Типы переменных з властивостями: код параграфа, тип переменной, описание;
Фрагменты кода з властивостями: код параграфа, фрагмент кода, описание;
Рисунки з властивостями: код параграфа, название рисунка, рисунок;
Функции властивостями: код параграфа, функция, описание;
Ключевые слова з властивостями: код параграфа, код ключевого слова, ключевое слово, описание.
ER-модель є однією з самих простих візуальних моделей даних (графічних нотацій). Вона дозволяє визначити структуру в загальних рисах [5]. Це загальний опис структури називається ER-діаграмою або онтологією вибраної предметної області.
На етапі переходу до реалізації даної ER-діаграми у вигляді реальної інформаційної системи або програми, відбувається відображення ER-моделі в більш детальну модель даних реляційної (об'єктної, мережевої, логічної, або ін) бази даних, яка називається фізичною моделлю даних по відношенню до вихідної ER-діаграмі.
Модель Сутність-Зв'язок (ER-модель) (англ. entity-relationship model або entity-relationship diagram) — це модель даних, що дозволяє описувати концептуальні схеми. Вона надає графічну нотацію, засновану на блоках і з'єднуючих їх лініях, за допомогою яких можна описувати об'єкти і відносини між ними будь-якої іншої моделі даних. У цьому сенсі ER-модель є мета-моделлю даних, тобто є засобом опису моделей даних.
ER-модель зручна при проектуванні інформаційних систем, баз даних, архітектур комп'ютерних програм, і інших систем (далі — моделей). З її допомогою можна виділити ключові сутності, що присутні в моделі, і позначити зв’язки, які можуть встановлюватися між цими сутностями. Важливо відзначити, що самі зв’язки також є сутностями (виділяються в окремі графічні блоки), що дозволяє встановлювати зв’язки на безлічі самих відносин [1].
Для цього використовуються наступні позначення:
Сутність зображається прямокутниками.
Атрибути позначаються овалами (або прямокутниками з закругленими кутами).
Зв’язки зображаються ромбами.
Главы
Название главы
№ главы
Краткое содержание
Начальная страница
Конечная страница
Описание функции
Описание переменных
Название подглавы
Название параграфа
Начальная страница
Конечная страница
Типы переменных
Функции
Таблицы
Рисунки
Свойства комп.
Процедуры
Описание процедуры
Определения
Ключевые слова
Описание ключ. слов
Рисунок 2.1.1 – ER-діаграма
У базі даних можуть перебувати дані, що повторюються, які призводять до надмірності даних. Надмірність даних є причиною аномалій, які виявляються в некоректному оновленні, видаленні та редагуванні даних, що в свою чергу стає причиною порушення таких властивостей бази даних, як цілісність, несуперечність, логічна і фізична незалежність. Мінімальна надмірність досягається шляхом виключення повторюваних записів. Але іноді повне усунення надмірності недоцільно [6].
Нормалізація — це розбиття таблиці на дві або більше, що володіють кращими властивостями при включенні, зміні та видаленні даних. Остаточна мета нормалізації зводиться до отримання такого проекту бази даних, в якому кожен факт з'являється лише в одному місці, тобто виключена надмірність інформації. Це робиться не стільки з метою економії пам'яті, скільки для виключення можливої суперечливості збережених даних [7].
Процес нормалізації складається з кількох етапів, на кожному з яких визначаються так звані нормальні форми: 1НФ, 2 НФ, 3 НФ, НФБК, 4НФ, 5НФ (форма проекції зв’язків). У більшості проектів третя нормальна форма завершує процес нормалізації.
Таблиця знаходиться у першій нормальній формі (1НФ) тоді і тільки тоді, коли жоден з її рядків не містить у будь-якому своєму полі більше одного значення і жодне з її ключових полів не порожньо.
Таблиця знаходиться в другій нормальній формі (2НФ), якщо вона задовольняє визначенням 1НФ і всі її поля, що не входять до первинного ключа, пов'язані повною функціональною залежністю з первинним ключем.
Таблиця знаходиться в третій нормальній формі (3НФ), якщо вона задовольняє визначенням 2НФ і не одне з її неключових полів не залежить функціонально від будь-якого іншого неключового поля.
Таблиця знаходиться в нормальній формі Бойса-Кодда (НФБК), якщо і тільки якщо будь-яка функціональна залежність між її полями зводиться до повної функціональної залежності від можливого ключа.
Таблиця знаходиться у п'ятій нормальній формі (5НФ) тоді і тільки тоді, коли в кожній її повній декомпозиції всі проекції містять можливий ключ. Таблиця, яка не має жодної повної декомпозиції, також знаходиться в 5НФ. Повною декомпозицією таблиці називають таку сукупність довільного числа її проекцій, підключення яких повністю збігається з вмістом таблиці.
Четверта нормальна форма (4НФ) є окремим випадком 5НФ, коли повна декомпозиція повинна бути з'єднанням рівно двох проекцій. Вельми не просто підібрати реальну таблицю, що може бути надана в 4НФ, але не була б у 5НФ.
содержат
содержат
Главы
Начальная страница
Краткое соделжание
Название главы
№ главы
Конечная страница
Подглавы
Конечная страница
Начальная страница
Код подглавы
№ главы
1
м
1
м
Название подглавы
А
содержат
содержат
содержат
содержат
Параграфы
Код параграфа
№ главы
Конечная страница
Код подглавы
Название параграфа
Начальная страница
Ключ.слова кот.упомин.
Процедуры кот.упомин.
Функции кот.упомин.
Свойства кот.упомин.
Типы перем.кот.упомин
Определения
Фрагменты кода
Рисунки
Таблицы
Таблицы
Содержание таблицы
Название таблицы
Код параграфа
Типы
переменных
Описание
Тип переменной
Код параграфа
Ключевые слова
Код ключевого слова
Ключевое слово
Описание
Код параграфа
Функции
Описание
Функция
Код параграфа
1
м
1
м
1
м
1
м
содержат
Рисунки
Рисунок
Название рисунка
Код параграфа
1
м
содержат
Фрагменты кода
Описание
Фрагмент кода
Код параграфа
1
м
Процедуры
Описание
Процедура
Код параграфа
содержат
1
м
А
Рисунок 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.
Система управління базами даних (СУБД) — спеціалізована програма (частіше комплекс програм), що призначена для організації і ведення бази даних. [10]
СУБД Access входить до складу широко розповсюдженого сімейства офісних додатків Microsoft Office. Microsoft Access на сьогоднішній день є одним з найпоширеніших настільних додатків для роботи з базами даних. Це пов’язано з тим, що Access володіє дуже широким діапазоном засобів для введення, аналізу та представлення даних. Ці кошти є не тільки простими і зручними, а й високопродуктивними, що забезпечує високу швидкість розробки додатків. Спочатку Access мала ряд унікальних можливостей, таких як вміння зводити воєдино інформацію з різних джерел (електронних таблиць, текстових файлів, інших баз даних), подання даних в зручному для користувача вигляді за допомогою таблиць, діаграм, звітів, інтеграція з іншими компонентами Microsoft Office. Вдосконалюючись від версії до версії, Access стала інструментом, який може задовольнити потреби самих різних категорій користувачів: від новачка, якому подобається дружній інтерфейс системи, що дозволяє йому впоратися із завданнями, до професійного розробника, який має весь необхідний інструментарій для побудови унікального рішення для конкретного підприємства середнього бізнесу.
Таблиці — це основні й найнеобхідніші об’єкти будь-якої БД. Саме в таблицях зберігаються всі дані. Реляційна БД може містити цілий набір взаємозв'язаних таблиць.
Запити — це спеціалізовані структури, що створюються для здійснення обробки бази даних. За допомогою запитів можна упорядкувати дані, виконати їх фільтрацію, об’єднання, відбір або навіть зміну.
Форми — це об’єкти, що дозволяють вводити в базу нові дані або переглядати вже існуючі у зручній для користувача формі (вигляді, поданні).
Звіти — ці об’єкти говорять самі за себе. Вони видають дані на принтер або інший пристрій виводу (це може бути і монітор), у зручному та наочному вигляді. Наприклад, у вигляді бланку або рахунку.
Макроси — це набір макрокоманд. Коли виникає необхідність частого виконання одних і тих же операцій з БД, є можливість згрупувати набір команд в один макрос. Після чого ініціалізацію його виконання закріплюють за певною комбінацією клавіш клавіатури. Простими словами, натискання цієї комбінації при роботі з базою призводить до виконання всієї послідовності дій, що записані у макрос.
Модулі — це програми, що створені засобами мови Visual Basic. Вони дозволяють доповнити стандартні засоби Access, якщо наявних вже не вистачає для задоволення всіх вимог до роботи СУБД. Програміст може розширити можливості системи, дописавши необхідні модулі та додавши їх у БД [4].
У 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 – Схема даних
Запити створюються користувачем для вибірки потрібних даних з одної або декількох пов'язаних таблиць. Запит може формуватися за допомогою запитів за зразком 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 – Форма «Об авторе»
Ласкаво просимо в довідкову систему бази даних «Теорія та практика прикладного програмування».
База даних «Теорія та практика прикладного програмування» призначена для зберігання довідкової інформації, що міститься у певних главах посібника з прикладного програмування (Бобровский С.И. 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 Мб.
Надалі дану систему можна вдосконалювати, відповідно до потреб користувачів.
Кириллов В.В. Основы проектирования реляционных баз данных. Учебное пособие. — СПб.: ИТМО, 1994. — 90 с.
ГОСТ 34.003-90. Государственный стандарт Российской Федерации: «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения». — М.: ИПК Издательство стандартов, 2002.
Дейт Д. Введение в систему баз данных. — М., СПб.: BHV — Санкт-Петербург, 1977. — 312 с.
http://ru.wikipedia.org/ . — Вільна енциклопедія.
Інформаційні системи і технології /Карпенко С.Г., Попов В.В., Тарнавський Ю.А. та ін. — К.: МАУП, 2004. — 192с.
Лук’янова В.В. Комп’ютерний аналіз даних: Посібник. — К.: Академія, 2003. — 344с.
Основи інформаційних систем: Навчальний посібник /Ситник В.Ф., Писаревська, Ерьоміна Н.В., Краєва О.С. Ред Ситник В.Ф. — К.: КНЕУ, 1997. — 252с.
Оскерко В.С., Пунчик З.В. Практикум по технологиям баз данных: Учебное пособие. — Минск: БГЭУ, 2004. — 170с.
Конспект лекций по дисциплине «Информационные системы в ПК»
http://www.lessons-tva.info/ . — Безкоштовне дистанційне навчання інформатиці, телекомунікаціям та основам електронного бізнесу.
Нравится материал? Поддержи автора!
Ещё документы из категории информатика:
Чтобы скачать документ, порекомендуйте, пожалуйста, его своим друзьям в любой соц. сети.
После чего кнопка «СКАЧАТЬ» станет доступной!
Кнопочки находятся чуть ниже. Спасибо!
Кнопки:
Скачать документ