База даних "Теорія та практика прикладного програмування"
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. | Опис предметної області та користувачів системи. Заповнення даними універсального відношення. | до 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 р. РЕФЕРАТ Курсовий проект: 41 с., 38 рис., 7 табл., 0 додатків, 10 джерел. Об'єктом дослідження є довідкова інформація, що міститься у певних главах посібника з прикладного програмування («Культин Н.Б. Основы программирования в 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. «Глава»
|
Поле | Тип даних | Розмір | | № п/п | Лічильник | Довге ціле | | Код параграфа | Числовий | Довге ціле | | Затрата времени на изучение | Числовий | Довге ціле | | Код оператора | Числовий | Довге ціле | | Компоненты | Логічний | | | Код таблицы | Числовий | Довге ціле | | Код рисунка | Числовий | Довге ціле | | Код примечания | Числовий | Довге ціле | | Код листингов | Числовий | Довге ціле | | Дата разработки записи | Дата/час | | | |
Страницы: 1, 2
|