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

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

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



2012 © Все права защищены
При использовании материалов активная ссылка на источник обязательна.