Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Завдання на курсове проектування




Висновки

Розробка структури СУБД та схеми даних

Наводиться схема даних створеної СУБД і коротко описуються зв’язки.

3.14 Опис типів полів розроблених таблиць

Коротко описується склад полів таблиць створеної СУБД. Робота з формами.

3.15 Розробка інструкції користувача СУБД

Наводиться короткий опис навігації в СУБД та особливості інтерфейсу під час роботи з базою даних.

Наводяться основні результати проектування бази даних.

4 СТРОКИ ВИКОНАННЯ КУРСОВОЇ РОБОТИ

Рекомендується такий графік виконання курсової роботи при тривалості семестру - 14 навчальних тижнів.

 

Таблиця 1 – Графік виконання курсової роботи

Розділ Зміст розділу % від об'єму КР Строк виконання (тиждень)
  Змістовне формування задачі. Розробка технічного завдання   1-2
  Розробка універсального відношення    
  Розробка ЕR-моделі   3-4
  Формування початкових відношень за методом "суть - зв'язок"   3-4
  Нормалізація відношень методом декомпозиції   3-4
  Оцінка спроектованих НФБК відношень    
  Аналіз запитів до БД, що реалізуються    
  Опис вихідних форм    
  Обґрунтування запропонованої структури бази даних і схеми даних    
  Опис складу бази даних та її призначення   5-6
  Розробка структури бази даних і схеми даних   7-8
  Розробка та налагодження бази даних   9- 10
  Розробка інструкції користувача    
  Оформлення курсової роботи    
  Захист курсової роботи   13- 14

5 ПОРЯДОК ЗАХИСТУ КУРСОВОЇ РОБОТИ

Готовність до захисту курсової роботи визначає керівник. Якщо робота виконана в повному обсязі і немає принципових помилок, керівник допускає студента до захисту. В іншому випадку робота повертається студенту на доопрацювання. Після позитивного висновку про готовність курсової роботи студент повинен захистити її перед комісією в складі двох викладачів, виділених кафедрою.

Під час захисту студент коротко (5-7 хвилин) доповідає про основні результати роботи і відповідає на запитання членів комісії за змістом роботи.

Теми курсових робіт наведені в кінці методичних вказівок. Позитивно оцінюється самостійний вибір студентом (за узгодженням з викладачем) теми курсової роботи. Самостійний вибір предметної області, у якій доцільно використовувати бази даних, дозволяє скласти враження про рівень творчої активності студента, його вміння здійснити попередній аналіз предметної області.

7 КОРОТКІ ТЕОРИТИЧН1 ПОЛОЖЕННЯ

З метою полегшення виконання курсової роботи наводяться приклади

виконання її окремих розділів, але забороняється використовувати ці розділи як електронний шаблон курсової роботи.

7.1 Аналіз предметної області та постановка задачі

Першим етапом проектування бази даних будь-якого типу є аналіз предметної області, що закінчується побудовою інформаційної структури (концептуальної схеми) [1]. На даному етапі аналізуються запити користувачів, вибираються інформаційні об'єкти та їх характеристики і на основі проведеного аналізу формується структура предметної області, яка не залежить від програмного та технічного середовища, в якому буде реалізуватися база даних.

Аналіз предметної області доцільно розбити на три фази:

- аналіз концептуальних вимог та інформаційних потреб;

- виявлення інформаційних об'єктів та зв'язків між ними;

- побудова концептуальної моделі предметної області та проектування концептуальної схеми бази даних.

На етапі аналізу концептуальних вимог та інформаційних потреб необхідно вирішити такі задачі:

- аналіз вимог користувача до бази даних (концептуальних вимог);

- виявлення задач, що мають місце при обробці інформації, яка повинна бути подана у базі даних;

- виявлення перспективних задач;

- документування результатів аналізу.

Вимогами користувачів до бази даних, що розробляється, є, в загальному випадку, список запитів з вказанням їх інтенсивності та об'ємів даних. Ці вказівки опрацьовуються в діалозі з майбутнім користувачем бази даних. Тут же з'ясовуються вимоги до введення, відновлення та корегування інформації. Вимоги користувачів уточнюються та доповнюються при аналізі перспективних задач, що мають місце.

Розглянемо приклад створення бази даних для контролю оплати по кредитах.

База даних з предметної області “Контроль оплати по кредитах” призначена для використання в банківських установах. Тому слід врахувати, що головною її функцією є надання чіткої інформації про стан погашення наданих кредитів, щоб банківська установа могла негайно прийняти відповідні рішення, адже велика не погашена сума може призвести до банкротства. Також однією з вимог до даної бази даних є зберігання списків боржників, щоб в подальшому не надавати їм кредиту. Також база даних повинна автоматично розраховувати суму повернення згідно з чинною кредитною ставкою, визначати повернену суму, і зберігати усі виконані клієнтом фінансові операції.

Згідно з вищесказаними вимогами в базу даних слід включити: дані про клієнтів; види кредитів; інформацію про оформлення кредиту; а також дані про погашення кредиту.

База даних повинна виконувати такі функції.

1. Введення і зберігання даних про клієнтів:

- прізвище, ім’я, та по батькові;

- ідентифікаційний код;

- адреса;

- рік народження.

2. Введення і зберігання видів кредитів, які клієнти можуть отримати:

- назва кредиту;

- максимальна сума;

- річні проценти.

3. Оформлення кредиту:

- код кредиту;

- сума кредиту;

- дата надання;

- дата завершення.

4. Введення і зберігання інформації про погашення кредиту:

- сума;

- дата;

- час.

5. Виявлення боржників, що не повернули кредит до зазначеної дати:

-повернення.

6. Пошук клієнтів за адресою.

7. Формування списку клієнтів, які вже погасили кредит і можуть знову отримувати кредит.

8. Формування інформації про кредитну діяльність клієнтів.

 

База даних “Контроль оплати по кредитах” розробляється в середовищі Microsoft Office Access 2003, і може бути виконана на комп’ютері з середовищем Microsoft Office Access. Введення інформації здійснюється за допомогою клавіатури через форми в таблиці де інформації виводиться на екран комп’ютера. Також існує можливість виведення інформації на принтер.

7.2 Розробка універсального відношення

Друга фаза аналізу предметної області складається з: вибору інформаційних об'єктів, задання необхідних властивостей для кожного об'єкта, виявлення зв'язків між об'єктами, виявлення обмежень, що накладаються на інформаційні об'єкти, типи зв'язків між ними, характеристики інформаційних об'єктів.

При виборі інформаційних об'єктів бажано намагатися відповісти на такі питання.

1. На які класи можна розбити дані, що підлягають зберіганню у базі даних?

2. Яке ім'я можна присвоїти кожному класу даних?

3. Які найбільш цікаві характеристики (з точки зору користувача) кожного класу даних можна виділити?

4. Які імена можна присвоїти вибраним наборам характеристик?

 

Виділення інформаційних об'єктів - процес ітеративний. Він здійснюється на основі аналізу інформаційних потоків та інтерв'ювання споживачів. Характеристики інформаційних об'єктів визначаються тими ж методами.

Введемо ряд позначень, котрі будуть використовуватися у ході подальшого викладення матеріалу.

R - є відношення над множинами D1, D2,...Dn якщо воно являє собою множину упорядкованих n-кортежів вигляду d1,d2,...dn. D1,D2,...Dn - називаються доменами відношення R.

Відношення може бути подане у вигляді файла або таблиці, стовпці котрих - елементи доменів, а рядки - кортежі. Кожен кортеж відображає один екземпляр інформаційного об'єкта. Імена стовпців (поле запису) називаються атрибутами, а індивідуальні значення елементів - значеннями атрибутів. Кожен атрибут відображає відповідну характеристику інформаційного об'єкта. Число стовпців у відношенні називається ступенем відношення, а число кортежів - потужністю відношення. У процесі експлуатації бази даних ступінь відношення змінюється значно рідше, чим його потужність.

Реляційна база даних являє собою сукупність відношень, що зберігають всю необхідну інформацію. Кожне відношення зберігається в окремому файлі з дуже простою структурою, оскільки всі записи файла мають однаковий формат.

Атрибут або набір атрибутів, котрий можна використовувати для однозначної ідентифікації конкретного кортежу, називається початковим ключем (у випадку набору атрибутів - складений ключ). Можливі випадки, коли відношення може вміщувати декілька унікальних ключів. Тоді один з них вибирається як головний початковий, а інші отримують назву початкових ключів.

Атрибути, що представляють копії ключів інших відношень, називаються зовнішніми ключами.

Атрибут або набір атрибутів, що використовуються для більш швидкого пошуку, називається другорядним індексом.

УНІВЕРСАЛЬНИМ ВІДНОШЕННЯМ називається відношення, що вміщує в себе всі атрибути, котрі будуть використовуватися у базі даних. Для невеликих баз даних універсальне відношення може служити відправною точкою при їх проектуванні.

Розглянемо порядок створення універсального відношення при розробці бази даних для контролю оплати по кредитах. Виходячи з виконаного в минулому розділі аналізу предметної області, в універсальне відношення потрібно включити атрибути, щоописують таку інформацію про об'єкт:

особа, види кредитів, кредит, щомісячна оплата.

Перерахуємо атрибути вищеназваних об’єктів:

Особа (ПІБ, ідентифікаційний код, адреса, рік народження).

Види кредитів (назва кредиту, максимальна сума, річні проценти).

Кредит ( код кредиту, сума кредиту, дата надання, дата завершення).

Щомісячна оплата ( сума, дата, час ).

Для деяких характеристик об'єктів необхідно визначити обмеження. Логічні обмеження, що накладаються на дані, називаються обмеженням цілісності. Обмеження цілісності це така властивість, котра задається для деякого інформаційного об'єкта або його характеристик і котра повинна зберігатися для кожного стану.

Обмеження цілісності визначимо для атрибута рік народження відношення особа. Як відомо кредити не надаються особам віком менше 18 років. Також дата завершення відношення кредит повинна бути більша за дату оформлення кредиту, що є цілком очевидним.

В таблиці 2 перерахуємо атрибути для універсального відношення.

 

Таблиця 2 – Початковий перелік атрибутів, для формування універсального відношення бази даних

 

Назва атрибута Ім'я поля К о м е н т а р і й
ПІБ ПІБ Прізвище, ім’я, та по батькові клієнта
ідентифікаційний код ідентифікаційний код Ідентифікаційний код клієнта
адреса адреса Адреса клієнта
рік народження рік народження Рік народження клієнта
назва кредиту назва кредиту Назва кредиту, який клієнт може взяти
максимальна сума максимальна сума Максимальна сума кредиту
річні проценти річні проценти Проценти, під які позичаються кредити
код кредиту код кредиту Унікальний
сума кредиту сума кредиту Сума, яку клієнт позичає
дата надання дата надання Дата надання кредиту
дата завершення дата завершення Кінцева дата погашення кредиту
сума сума Сума погашення
дата дата Дата погашення
час час Час погашення

 

Оскільки всі перераховані в таблиці атрибути є незалежними, тобто значення одних з них не можуть бути обчислені за значеннями інших, то всі вони можуть бути включеними в склад універсального відношення.

R (ПІБ, ідентифікаційний код, адреса, рік народження, назва кредиту, максимальна сума, річні проценти, код кредиту, сума кредиту, дата надання, дата завершення, сума, дата, час).

7.3 Розробка ER-моделі предметної області

Заключна фаза аналізу предметної області складається з розробки її інформаційної структури (або концептуальної схеми).

В звичайних випадках для побудови концептуальної схеми використовуються традиційні методи агрегації та узагальнення. При агрегації декілька інформаційних об'єктів (елементів даних) об'єднуються в один відповідно до семантичних зв'язків між об'єктами. Наприклад, літак типу А перевозить вантаж з пункту відправлення в пункт надходження. Методом агрегації можна створити інформаційний об'єкт (суть) РЕЙС з атрибутами: тип літака, пункт відправлення, пункт надходження, рейс літака.

При узагальнені інформаційні об'єкти (елементи даних) об'єднуються в родовий об'єкт. Наприклад, інформаційні об'єкти: автобус, автомобіль, літак, пароплав - можуть бути об'єднані в родовий об'єкт "транспортні засоби".

Концептуальна модель застосовується для структурування предметної області з урахуванням не тільки інформаційних інтересів користувачів системи, але і інформаційного споживання самої предметної області.

Концептуальна модель дозволяє чітко розглянути окремі елементи предметної області. При цьому детальність відображення предметної області залежить від вибраної моделі. Модель з мінімальними можливостями повинна забезпечувати здатність задання даних та їх взаємозв'язок. Відповідно, семантична потужність концептуальної моделі збільшується із зростанням додаткового числа характеристик, котрі вона дозволяє визначити.

При виборі моделі для концептуального проектування бажано враховувати ті обставини, що будь-яким моделям властиві деякі обмеження, тому пошук ідеальної моделі, що повністю відображає реальний світ, дуже проблематичний. Вибір моделі диктується насамперед характером предметної області і вимогами, що ставляться перед базою даних. Іншою важливою обставиною є незалежність концептуальної моделі від СУБД, котра повинна бути вибрана після побудови концептуальної схеми.

В курсовій роботі для подання структури і обмежень реального світу використовуються моделі типу "суть-зв'язок" або ЕR-моделі, котрі були введені у практику П. Ченом [2, 3, 8 ].

Основними конструкціями ЕR-моделі є суті і зв'язки [5,7,13,14].

Під суттю розуміють основний зміст того явища, процесу або об'єкта, про який збирають інформацію в базі даних. Як суть може виступати місце, річ, особа і так далі. Суть визначається як деякий об'єкт, який цікавий користувачу. Суть, як правило виступає іменником.

Розрізняють тип суті та екземпляр суті. Під типом суті розуміють набір однорідних об'єктів, що виступають як ціле. Поняття "екземпляр суті" відноситься до конкретного об'єкта. Наприклад: тип суті – службовець, екземпляр суті - Коваленко Василь Васильович. Суть прийнято зазначати поіменованимихарактеристиками, які мають назву атрибутів. Назва атрибута повинна бути унікальною для кожної суті, хоча вона може повторюватися для різноманітних типів суті.

Наприклад:

тип суті – службовець

атрибути - прізвище, ім'я та по-батькові, адреса, рік народження і т. д.

тип суті - хворий

атрибути - прізвище, ім'я, по батькові, адреса, діагноз і т. д.

Розрізняють тип атрибута та екземпляр атрибута. Тип атрибута задає властивість суті, а екземпляри атрибута відображають різноманітні значення цієї властивості.

Наприклад:

тип атрибута - дата народження

екземпляри атрибута - 20.05.1941, 5.06.1958 і т. д.

Надалі при використанні терміну "суть" будемо розуміти тип суті, а терміну "атрибут" - тип атрибута.

Зазначимо, що абсолютна відміна між суттю і атрибутом відсутня. Атрибут є типом тільки в зв'язку з обраною суттю, а в іншому контексті він сам може виступати як суть. Наприклад, для заводу, що виготовляє автомобілі, колір фарби є лише одним з атрибутів суті автомобіля. Для фабрики, що випускає фарби, колір є суттю.

Між сутями (інформаційними об'єктами), а також між суттю і її атрибутами з'являються деякі асоціації, що називаються зв'язками. При цьому зв'язки можуть бути різних властивостей, характеру та вибірності. Звичайно зв'язок виражається дієсловом. Зв'язки як і суті іменуються, при цьому екземпляр кожного окремого зв'язку специфікується лінією між тими двома екземплярами суті, котрі цей зв'язок з'єднують. Атрибут (або набір атрибутів), що використовується для ідентифікації суті, називається ключем суті.

Кожен екземпляр зв'язку визначається набором ключів суті, що з'єднуються цим зв'язком.

Суті можуть з'єднуватися зв'язками різної ступені. Наприклад, ступінь зв'язку 1:1 свідчить про те, що один екземпляр однієї суті може бути зв'язаний не більше, ніж з одним екземпляром іншої суті. Відповідно, ступінь зв'язку 1:n означає, що один екземпляр однієї суті може бути зв'язаний з декількома екземплярами іншої суті, але не навпаки. Накінець, ступінь зв'язку m:n показує, що кожен з екземплярів будь-якої з сутей може бути зв'язаний з декількома екземплярами іншої суті.

Зв'язки можуть подаватися різними способами, з яких ми будемо використовувати тільки два: діаграма ЕR-екземплярів діаграма ЕR-типів. Діаграми ЕR-екземплярів відображають зв'язки між екземплярами сутей. Діаграми ЕR-типів відображають зв'язки між типами сутей. Приклади діаграм ЕR-екземплярів і ЕR-типів наведені на рис.1 і рис.2, відповідно.

На діаграмах ER-типу (рис.2) суть відображається прямокутником, а зв’язок – ромбом. Нижче прямокутника розміщуються атрибут або набір атрибутів, що є ключем суті. Цифра (1 або n) вказує тип зв'язку. Місцезнаходження суцільного кола визначає чи обов'язково всі екземпляри даної суті повинні брати участь у зв'язках (коло знаходиться всередині прямокутника), чи не обов'язково (коло винесено за межі прямокутника). У першому випадку говорять, що клас належності суті є обов'язковим, а в іншому - необов'язковим. У прикладах на рис. 1 і рис. 2 клас залежності суті 1 є необов'язковим, а клас належності суті 2 - обов'язковим. Тип зв'язку є 1:n, оскільки екземпляр 2 суті 1 зв'язаний з двома екземплярами суті 2.

 

Тип суті 1 Зв’язки Тип суті 2

 

Екз.1 суті 1 Екз.1 суті 2

Екз.2 суті 1 Екз.2 суті2

Екз.3 суті 1 Екз.3 суті 2

Екз.4 суті 1 Екз.4 суті 2

Рисунок 1 – Приклад діаграми ER-екземплярів

 

  Суть 1
  Суть 2
1 n

       
   

 

 


<Атр 1>,... <Атр 1>,...

 

Рисунок 2 – Приклад діаграми ER-типів

 

Зазначимо, що хоча загальноприйнятого формату для графічного подання ЕR-діаграм немає, розбіжності у зображеннях, як правило, виявляються зовсім несуттєвими. Використаний нами стандартний спосіб подання запропонований Дж. Ульманом.

Першою задачею, яку необхідно розв'язати при розробці ЕR-моделі, є формування сутей, що необхідні для опису предметної області. Іншими словами, необхідно вказати ті типи об'єктів (тобто набори подібних об'єктів), про які в системі повинна накопичуватися інформація. Це означає, що за підсумками аналізу предметної області потрібно мати повну або достатньо повну уяву про запити, що реалізуються в системі. Разом з тим необхідно врахувати, що при кваліфікованій експлуатації системи у більшості випадків у користувача виникає бажання розширити систему запитів. У зв'язку з цим, при розробці ЕR-схеми, з одного боку, зручно твердо прив'язатися до обраної в результаті аналізу предметної області системи запитів, а з іншого боку, бажано розглядати задачу в більш широкому плані, з врахуванням перспектив подальшого нарощування можливостей системи.

Перечислимо суті, які використовуються в задані предметній області, та визначимо ключі (атрибут чи групу атрибутів), які однозначно ідентифікують поля даних сутей.

Особа(ідентифікаційний код).

Види кредитів(річні проценти).

Кредит(код кредиту).

Щомісячна оплата(дата, час).

Зв’язки можуть подаватися діаграмами ER-екземплярів і діаграмами ER-типів. Діаграми ER-екземплярів відображають зв’язки між екземплярами сутей. Діаграми ER-типів відображають зв’язки між типами сутей [1].

За допомогою діаграм ER-екземплярів визначимо зв’язки, які існують між вищенаведеними сутями. Визначимо типи зв’язків і характеристики кожного зв'язку.

 

Зв'язок Особа – Кредит поданий діаграмою екземплярів на рис. 3, з якого видно, що клас належності обох сутей є обов'язковим тому, що немає сенсу зберігати інформацію про особу, якщо вона не брала кредит, і не може бути такого, щоб кредит не мав особи, яка його має погасити. Тип зв'язку - 1:n, оскільки одна особа може взяти за своє життя не один кредит, проте її не нададуть наступний кредит, якщо вона не погасила попередній. І не може бути такого, щоб один і той самий кредит взяли декілька осіб.




Поделиться с друзьями:


Дата добавления: 2014-11-16; Просмотров: 1015; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.06 сек.