База даних "Теорія та практика прикладного програмування"
База даних "Теорія та практика прикладного програмування"
58
Міністерство освіти і науки України
Українська інженерно-педагогічна академія
Гірничий факультет
Кафедра інформаційних технологій
ПОЯСНЮВАЛЬНА ЗАПИСКА
до курсової роботи
з дисципліни «Проектування та експлуатація інформаційних систем»
на тему:
«База даних “Теорія та практика прикладного програмування”
(Літературне джерело: “Культин Н.Б. Основы программирования в Delphi 7. - СПб.: БХВ-Петербург, 2003. - 608 с.: ил”. Розділ: “Глава 2. Управляющие сруктуры языка Delphi”, сторінки: 85-123)»
Виконав ст. гр. ДГ-К7-1
Куров А. В.
Керівник Ушакова І. В.
Стаханов
2009
Форма № У-6.01
Затв. наказом Мінвузу УССР
від 3 серпня 1984 р. №253
УІПА, гірничий факультет
(найменування вищого навчального закладу)
Кафедра інформаційних технологій
Дисципліна «Проектування та експлуатація інформаційних систем»
Спеціальність 6.01010036
Курс 3 Група ДГ-К7- 1 Семестр 5
ЗАВДАННЯ
на курсовий проект студента
Курова Артема Вiталiйовича
(прізвище, ім'я, по батькові)
1. Тема проекту База даних “Теорія та практика прикладного програмування”
(Літературне джерело: “Культин Н.Б. Основы программирования в Delphi 7. - СПб.: БХВ-Петербург, 2003. - 608 с.: ил”. Розділ: “Глава 2. Управляющие срук-туры языка Delphi”, сторінки: 85-123)
2. Термін здачі студентом закінченого проекту до 5 грудня 200 р.
3. Початкові дані до проекту Загальні вимоги до баз даних: забезпечення функціонування, цілісності та скорочення збитковості. Наявність обгрунтованої кількості віконних форм та таблиць (від 4 до 7). Реалізація семи запитів різного типу, в тому числі обов'язкові запити з використанням розрахунків та з формуванням звіту. Загальна кількість полів в універсальній таблиці (від 20 до 30). В базі даних можуть бути поля з додатковою інформацією розробника. Кількість записів визначається змістом інформації в базі даних. Обов'язкові поля: з операторами, поясненням їх синтаксису та семантики, приклади програм або їх фрагментів, рисунки.
4. Зміст розрахунково-пояснювальної записки (перелік питань, що їх належить розробити) Вступ з обов'язковим посиланням на літературу, в якій вказується актуальність і ефективність використання баз даних. Опис предметної області та користувачів бази даних. Проектування бази даних (інфологічне, даталогічне та фізичне проектування). Інструкція з експлуатації інформаційної системи з ілюстраціями (опис використання бази даних різними користувачами системи). Висновки з обов'язковим переліком кількісних даних, що характеризують інформаційну систему. Використані джерела. Додатки.
До записки додається диск з програмним продуктом.
5. Перелік графічного матеріалу (з точним зазначенням обов'язкових креслень) Схема використання інформаційної системи; ER - діаграма - початкова та нормалізована; екранні копії таблиць, бланків запитів за зразком, вікон, звітів, тощо.
6. Дата видачі завдання Дата видачі завдання 17 вересня 2009 р.
КАЛЕНДАРНИЙ ПЛАН
№
Найменування етапів курсового
проектування
Термін
виконання
Примітки
1.
Затвердження та підписування завдання. Вступ. Вивчення фактичних даних інформаційної системи за заданою літературою.
до 01.10
2.
Опис предметної області та користувачів системи. Заповнення даними універсального відношення.
Даталогічне проектування. Універсальне відношення. Таблиці та зв'язки між ними. Нормалізація таблиць
до 29.10
Активна співпраця з керівником проекту
5.
Фізичне проектування інформаційної систем в СУБД Access (таблиці, запити, форми, звіти, макроси і т.п.)
до 19.11
Активна співпраця з керівником проекту
6.
Тестування інформаційної системи. Внесення в систему, при необхідності, змін та доповнень.
до 26.11
Активна співпраця з керівником проекту
7.
Оформлення тексту пояснювальної записки: титульна сторінка, зміст, етапи проектування, результати тестування, інструкція з експлуатації, висновки, список використаних джерел та додатки
до 30.11
Активна співпраця з керівником проекту
8.
Представлення керівнику роботи на перевірку
до 5.12
9.
Робота з зауваженнями керівника. Вилучення неточностй та помилок. Підготовка студентом роботи до захисту
Об'єктом дослідження є довідкова інформація, що міститься у певних главах посібника з прикладного програмування («Культин Н.Б. Основы программирования в Delphi 7. - СПб.: БХВ-Петербург, 2003. - 608 с.: ил»)
Предметом дослідження є проектування та експлуатація інформаційних систем.
Метою дослідження є закріплення теоретичних знань, отриманих при вивченні навчальної дисципліни «Проектування та експлуатація інформаційних систем» і придбання навичок у використанні сучасних інформаційних технологій для виготовлення програмних продуктів, що підтримують функціонування інформаційних систем.
Методи дослідження. Для вирішення поставлених задач застосовані:
· загальнонаукові методи: теоретичного пошуку; концептуально-порівняльного аналізу, визначення теоретичних і прикладних аспектів дослідження, визначення структури і змісту підготовки;
· емпіричні методи: дослідження предметної області, дослідження об'єкту, що вивчається у штучно створених для нього умовах, порівняння об'єкту, що досліджується з аналогом;
· метод створення інформаційної системи довідкового призначення. Введення даних до ІС згідно моделі сутність-зв'язок з обов'язковою нормалізацією даних; створення запитів та форм.
Теоретична значущість дослідження: розроблена інформаційна система, на базі якої були засвоєні теоретичні відомості про інформацію, її обробку та зберігання; етапи проектування ІС, алгоритм та необхідність нормалізації; загальні відомості про роботу з базами даних та їх супроводження у середовищі MS Access.
Практична значущість була розроблена інформаційна система, що дозволяє отримувати у зручному, простому для сприйняття, та, як наслідок, зрозумілому користувачеві вигляді довідкову інформацію з посібника, яка може бути корисною при вирішенні задач, пов'язаних з прикладним програмуванням.
Результати дослідження можуть бути використані в інженерних та інженерно-педагогічних ВНЗ.
БАЗА ДАНИХ, АДМІНІСТРАТОР, КОРИСТУВАЧ, КІНЦЕВИЙ КОРИСТУВАЧ, КІНЦЕВИЙ КОРИСТУВАЧ, ПРЕДМЕТНА ОБЛАСТЬ, ПРОЕКТУВАННЯ БД, КОНЦЕПУТАЛЬНЕ ПРОЕКТУВАННЯ, СУТНІСТЬ, АТРИБУТ, ЗВ'ЯЗОК, ER-ДІАГРАМА, МОДЕЛЬ «СУТНІСТЬ-ЗВ'ЯЗОК», НОРМАЛІЗАЦІЯ, ФІЗИЧНЕ ПРОЕКТУВАННЯ, СУБД, ТАБЛИЦЯ, ЗАПИТ, ФОРМА, ЗВІТ, МАКРОС, МОДУЛЬЗМІСТ
ВСТУП 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. Зв'язки «багато до одного» стають зовнішніми ключами.
З огляду на пряму відповідність логічної моделі та фізичної реалізації, остання чітко відображає перше, вносячи деякі уточнення за способом зберігання інформації. Тобто з урахуванням всього вищесказаного про розробку логічної моделі АС і логічної схеми БД отримана фізична модель БД.
2.3.1 СУБД Access
Система управління базами даних (СУБД) -- спеціалізований комплекс програм, призначений для зручної та ефективної організації, контролю та адміністрування баз даних. В якості структурної форми СУБД може бути використана будь-яка з існуючих на сьогодні моделей. Прикладом такої моделі може служити реляційна СУБД або мережева СУБД. [8]
Microsoft Access -- реляційна СУБД корпорації Microsoft. Має широкий спектр функцій, включаючи зв'язані запити, сортування по різних полях, зв'язок із зовнішніми таблицями і базами даних. Завдяки вбудованій мові VBA, в самому Access можна писати програми, що працюють з базами даних.
Основні компоненти MS Access:
· будівник таблиць;
· будівник екранних форм;
· будівник SQL-запитів (мова SQL в MS Access не відповідає стандарту ANSI);
· будівник звітів, що виводяться на друк.
Microsoft Access на сьогоднішній день є одним з найпоширеніших настільних додатків для роботи з базами даних. Це пов'язано з тим, що Access володіє дуже широким діапазоном засобів для введення, аналізу та представлення даних.
2.3.2 Об'єкти Access
Таблиці -- це основні об'єкти будь-якої бази даних. По-перше, в таблицях зберігаються всі дані, які є в базі, а по-друге, таблиці зберігають і структуру бази (поля, їх типи і властивості).
Запити -- це об'єкти, що служать для отримання даних з таблиць і надання їх користувачеві в зручному вигляді. За допомогою запитів виконують такі операції як відбір даних, їх сортування і фільтрацію. За допомогою запитів можна виконувати перетворення даних по заданому алгоритму, створювати нові таблиці, виконувати автоматичне наповнення таблиць даними, імпортованими з інших джерел, виконувати найпростіші обчислення в таблицях і багато іншого. [9]
Якщо запити -- це спеціальні засоби для відбору та аналізу даних, то форми -- це засоби для введення даних. Сенс їх той самий -- надати користувачеві засоби для заповнення лише тих полів, які йому заповнювати належить. Одночасно з цим у формі можна розмістити спеціальні елементи управління (лічильники, що розкриваються списки, перемикачі, прапорці та інше) для автоматизації введення. Переваги форм розкриваються особливо наочно, коли відбувається введення даних з заповнених бланків. У цьому випадку форму роблять графічними засобами так, щоб вона повторювала оформлення бланка -- це помітно спрощує роботу складача, знижує його стомлення і запобігає появі друкарських помилок.
По своїх властивостях і структурі звіти багато в чому схожі на форми, але призначені тільки для виводу даних, причому для виводу не на екран, а на принтер. У зв'язку з цим звіти відрізняються тим, що в них прийняті спеціальні заходи для групування виведених даних і для виведення спеціальних елементів оформлення, характерних для друкованих документів.
Макроси та модулі. Ці категорії об'єктів призначені як для автоматизації повторюваних операцій при роботі з СУБД, так і для створення нових функцій шляхом програмування. В СУБД Microsoft Access макроси складаються з послідовності внутрішніх команд СУБД і є одним із засобів автоматизації роботи з базою. Модулі створюються засобами зовнішнього мови програмування, в даному випадку мови Visual Basic for Applications. Це один із засобів, за допомогою яких розробник бази може закласти в неї нестандартні функціональні можливості, задовольнити специфічне вимоги замовника, підвищити швидкодію системи управління, а також рівень її захищеності. [10]
2.3.3 Створення таблиць
При створенні бази даних дані зберігаються в таблицях -- списках рядків і стовпців, що відносяться до конкретної області. Визначення структури бази даних потрібно завжди починати зі створення її таблиць. Таблиці створюються раніше будь-яких інших об'єктів бази даних.
Проста база даних може складатися всього з однієї таблиці.
Усі таблиці бази даних «Теорія та практика прикладного програмування» були створені у режимі конструктора.
Рисунок 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.4 Створення запитів
Запит (query) -- це засіб вибору необхідної інформації з бази даних. Питання, що сформоване по відношенню до бази даних, і є запит.
Існує кілька типів запитів: на вибірку, на оновлення, на додавання, на видалення, перехресний запит, створення таблиць. Найбільш поширеним є запит на вибірку. Запити на вибірку використовуються для відбору потрібної користувачу інформації, що міститься в таблицях. Вони створюються тільки для пов'язаних таблиць. [9]
Запит «Использование компонент в параграфе» виводить інформацію про те, чи використовуються у даних параграфах компоненти.
Рисунок 2.3.9 - Запит «Использование компонент в параграфе» у режимі Конструктора
Рисунок 2.3.10 - Робота запиту «Использование компонент в параграфе»
Запит «Использование операторов в листингах» дозволяє отримати інформацію про те, які лістинги які оператори містять.
Рисунок 2.3.11 - Запит «Использование операторов в листингах» у режимі Конструктора
Рисунок 2.3.12 - Робота запиту «Использование операторов в листингах»
Запит «Использование операторов в параграфах» є параметричним запитом, що надає відомості про те, які оператори містить зазначений користувачем параграф.
Рисунок 2.3.13 - Запит «Использование операторов в параграфах» у режимі Конструктора
Рисунок 2.3.14 - Робота запиту «Использование операторов в параграфах»
Запит «Количество рисунков в параграфе» надає відомості про загальну кількість рисунків у кожному параграфі. Для створення цього запиту використовувалась функція Count.
Рисунок 2.3.15 - Запит «Количество рисунков в параграфе» у режимі Конструктора
Рисунок 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.26 - Робота запиту «Сведения об операторах»
Запит «Содержательность главы» надає інформацію про кожний параграф (назву, короткий зміст, початкову та кінцеву сторінки).
Рисунок 2.3.27- Запит «Содержательность главы» у режимі Конструктора
Рисунок 2.3.28 - Робота запиту «Содержательность главы»
Запит «Таблицы в параграфах на И» дозволяє побачити таблиці, що містяться у відсортованих за літерою «И» параграфах.
Рисунок 2.3.29- Запит «Таблицы в параграфах на И» у режимі Конструктора
Рисунок 2.3.30 - Робота запиту «Таблицы в параграфах на И»
2.3.5 Створення форм
Всі форми БД «Теорія та практика прикладного програмування» були створені за допомогою Майстра. Відкриття форм здійснюється натисканням відповідних кнопок на кнопковій формі (Рисунок 2.3.31), яка створена за допомогою Диспетчеру кнопкових форм. При запуску БД кнопкова форма запускається автоматично.
Рисунок 2.3.31 - Кнопкова форма
Форми «Использование компонент в параграфе» (Рисунок 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.40) відображають зміст однойменних запитів.
Рисунок 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.40 - Форма «Таблицы в параграфах на И»
Форма «Краткое содержание главы» відображає зміст запиту «Содержательность главы».
Рисунок 2.3.41 - Форма «Краткое содержание главы»
Форма «Таблицы в главе» відображає таблиці, що містяться у главі, та інформацію про їх розміщення.
Рисунок 2.3.42 - Форма «Таблицы в главе»
Форми «Примечания в главе» (Рисунок 2.3.43) та «Листинги в главе» (Рисунок 2.3.44) надають аналогічну інформацію, але стосовно приміток та лістингів відповідно.
Рисунок 2.3.43 - Форма «Примечания в главе»
Рисунок 2.3.44 - Форма «Листинги в главе»
3ІНСТРУКЦІЯ КОРИСТУВАЧА
База даних «Теорія та практика прикладного програмування» призначена для зберігання довідкової інформації, що міститься у певних главах посібника з прикладного програмування (Культин Н.Б. Основы программирования в Delphi7).
Головна кнопкова форма запускається автоматично, відразу після запуску БД.
Рисунок 3.1 - Інтерфейс кнопкової форми
де кнопка:
1 - відкриває форму «Краткое содержание главы» (Рисунок 2.3.41);
2 - відкриває форму «Операторы в главе» (Рисунок 2.3.38);
3 - відкриває фору «Таблицы в главе» (Рисунок 2.3.42);
4 - відкриває форму «Рисунки в главе» (Рисунок 2.3.39);
5 - відкриває форму «Примечания в главе» (Рисунок 2.3.43);
6 - відкриває форму «Листинги в главе» (Рисунок 2.3.44);
7 - відкриває форму «Запроси» (Рисунок 3.2),
Рисунок 3.2 - Інтерфейс кнопкової форми «Запроси»
яка містить компоненти для відображення існуючих запитів, де кнопка:
9 - відкриває форму «Использование компонент в параграфе» (Рисунок 2.3.32);
10 - відкриває форму «Таблицы в параграфах на И» (Рисунок 2.3.40);
11 - відкриває форму «Использование операторов в листингах» (Рисунок 2.3.33);
12 - відкриває форму «Использование операторов в параграфах» (Рисунок 2.3.34);
13 - відкриває форму «Количество рисунков в параграфе» (Рисунок 2.3.35);
14 - відкриває форму «Количество страниц в параграфе» (Рисунок 2.3.36);
15 - відкриває форму «Операторы и листинги в параграфах» (Рисунок 2.3.37);
16 - повертає користувача до попередньої кнопкової форми (Рисунок 3.1).
Натискання кнопки (8) призведе до закриття всієї бази даних.
ВИСНОВКИ
У процесі даної курсової роботи була спроектована та реалізована в СУБД MS Access інформаційна система «Теорія та практика прикладного програмування».
У цій базі даних зберігається довідкова інформація, що міститься у певних главах посібника з прикладного програмування (Культин Н.Б. Основы программирования в Delphi 7). База містить запити, що дозволяють здійснювати пошук необхідних даних та відображати статистичну інформацію, як то: інформацію про зміст глави; які таблиці, компоненти та лістинги містяться у параграфі; який оператор у якому лістингу знаходиться; інформація про загальну кількість сторінок.
Дана система пройшла всі три етапи проектування. На інфологічному рівні структура бази даних була відображена у вигляді ER-діаграми, яка надалі була приведена до третьої нормальної форми. На даталогічному рівні -- представлена реляційною моделлю. У таблицях був усунений надлишок. Безпосередня робота з СУБД з формування таблиць і їх заповнення на комп'ютері була проведена на стадії фізичного проектування.
Таким чином, було створено 7 таблиць, 11 запитів та 14 форм. Розмір файлу БД -- 8,28 Мб.
Надалі дану систему можна вдосконалювати, відповідно до потреб користувачів.
ПЕРЕЛІК ВИКОРИСТАНИХ ДЖЕРЕЛ
Кузин А.В., Левонисова С.В. Базы данных. -- Академия, 2008. -- 320 с.
ГОСТ 34.003-90. Государственный стандарт Российской Федерации: «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения». -- М.: ИПК Издательство стандартов, 2002.
http://www.intuit.ru/ . -- Інтернет університет інформаційних технологій.
Дейт Д. Введение в систему баз данных. -- М., СПб.: BHV -- Санкт-Петербург, 1977. -- 312 с.
Главная