Інфологічне моделювання бази даних Абітурієнт

[ виправити ] текст може містити помилки, будь ласка перевіряйте перш ніж використовувати.

скачати

ЗМІСТ
  Введення
1. Аналіз предметної області
1.1. Опис предметної області
1.2. Інфологічне моделювання
2. Інфологічне проектування
2.1. Модель «сутність-зв'язок»
2.2. Зв'язки між сутностями
Висновок
Список літератури

Введення

Процес проектування БД на основі принципів нормалізації представляє собою послідовність переходів від неформального словесного опису інформаційної структури предметної області до формалізованого опису об'єктів предметної області в термінах деякої моделі.
Инфологическая модель застосовується на другому етапі проектування БД, тобто після словесного опису предметної області. Процес проектування тривалий і вимагає обговорень із замовником і з фахівцями в предметної області. Нарешті, при розробці серйозних корпоративних інформаційних систем проект бази даних є тим фундаментом, на якому будується вся система в цілому, і питання про можливе кредитуванні часто вирішується експертами банку на підставі саме грамотно зробленого інфологічне проекту БД. Отже, инфологическая модель повинна включати таке формалізований опис предметної області, яке легко буде "читатися» не тільки фахівцями по базах даних. І це опис має бути настільки ємним, щоб можна було оцінити глибину і коректність опрацювання проекту БД, і звичайно, воно не повинно бути прив'язане до конкретної СУБД. Вибір СУБД - це окреме завдання, для коректного її вирішення необхідно мати проект, який не прив'язаний ні до якої конкретної СУБД.
Інфологічне проектування перш за все пов'язане зі спробою подання семантики предметної області в моделі БД.
Метою даної курсової роботи є систематизація, накопичення і закріплення знань про побудову инфологической моделі і побудова инфологической моделі бази даних «Абітурієнт».
Мета проекту: створення підсистеми, що відповідає за зберігання і обробку особистих справ абітурієнтів, які вступають до університету згідно з правилами прийому абітурієнтів.

1. Аналіз предметної області

1.1. Опис предметної області

У базі "Абітурієнт" відображаються особисті дані абітурієнтів в яких зберігаються дані про атестаті, відомості про здачу вступних іспитах, форма навчання а також деякі додаткові дані (інформація щодо поданих заяв, відомості про батьків, військовий облік, захоплення). Формуються списки на зарахування згідно з результатами вступних іспитів.
Широке застосування комп'ютерних технологій у навчальному процесі висунуло перед працівниками приймальної комісії АГПК завдання автоматизувати роботу приймальної комісії від моменту заповнення особової картки абітурієнта до виконання різного роду звітів.
Для роботи приймальної комісії була створена програма «Абітурієнт АГПК», що включає в себе базу даних у СУБД MS Access.
Спроектована база даних містить повну систему взаємопов'язаних відомостей про вступників до коледжу.
Програма «Абітурієнт АГПК» заснована на реляційної моделі управління БД, тобто кожен запис в БД містить інформацію, що відноситься до одного конкретного абітурієнта. Розробка користувальницького інтерфейсу програми «Абітурієнт АГПК» робиться для створення досить реальних форм і звітів, з можливістю перемикання в режим попереднього перегляду, що дозволяє легко продемонструвати користувачу зовнішній вигляд додатків.
Для зв'язку таблиць створюється ключове поле, яке дозволяє закріпити за абітурієнтом обрану ним спеціальність, не вводячи повторювані дані, а по одному коду або символу звернутися до потрібної таблиці і прочитати з неї дані. Для ефективного пошуку даних використовують індекси, які негайно дозволяють відшукати потрібного нам абітурієнта із загального списку.
Результатом роботи програми «Абітурієнт АГПК» є звіти, форми, запити, а на більш високому рівні - макроси (опис об'єднання декількох завдань, що виконуються автоматично).

1.2. Інфологічне моделювання

Нехай необхідно побудувати базу даних, яка містить інформацію про навчальний процес поточного семестру:
· Списки студентів груп;
· Перелік предметів, що вивчаються;
· Викладацький склад кафедр, які забезпечують навчальний процес;
· Відомості про лекційних та практичних заняттях в кожній з груп;
· Результати здачі іспитів (заліків) по кожному з проведених занять.
У результаті аналізу предметної області виявляються документи - джерела даних для створення бази даних.
· Документи довідкової інформації. Довідкова інформація міститься в документах «Список студентів груп», «Список викладачів кафедр», «Список предметів, що вивчаються». На рис. 2, 3 наведено форми довідкових документів для студентів і викладачів.
· Документи облікової інформації. Облікова інформація про навчальному процесу може бути представлена ​​в планах проведення занять в групах на поточний семестр, що містять перелік лекційних та практичних занять з предметів (рис. 4), а також у заповнених екзаменаційних відомостях (рис. 5).
Особливо відзначимо, що документи предметної області не тільки дають можливість виявити структуру даних, але і є основою для розробки форм введення / виводу, звітів для друку документів.
Список студентів групи № _________
Номер студента
Прізвище І.О.
Рік народження
Адреса
Бал
при надходженні
Кількість студентів ___________________
Середній бал у групі при вступі ___________
Рис. 2. Форма документа зі списком студентів групи
Список викладачів кафедри
Назва кафедри ____________
Код кафедри ________ Телефон ______
Завідувач ____________
Таб. номер
Прізвище І. О.
Уч. ступінь
Уч. звання
Рис. 3. Форма документа зі списком викладачів кафедри
План проведення занять у групі
група № ___________ семестр__________ / поточний /
Назва предмета
Код предмета
ПІБ викладача
Таб. номер викладача
Вид заняття
Годинники
Рис. 4. Форма документа з переліком занять з предмета в групі

Екзаменаційна відомість
Назва предмета ______________________ Група ______________
Викладач ______________________________
Вид здачі __________________________ Дата ____________________
№ п / п
Прізвище І.О.
студента
Оцінка
Підпис викладача
Рис. 5. Форма документа-бланка екзаменаційної відомості

2. Інфологічне проектування

2.1. Модель «сутність-зв'язок»

Инфологическая модель застосовується після словесного опису предметної області. На підставі аналізу предметної області виділимо наступні сутності моделі «сутність-зв'язок» («Entity Relationship» - ER-моделі): «Абітурієнти», «Спеціалізація», «Факультети», і зобразимо їх у вигляді графічних позначень (прямокутник, у верхній частині якого записано ім'я суті, а нижче перераховуються атрибути, причому ключові атрибути позначаються підкресленням).
Абітурієнти
Код абітурієнта
ПІБ
Номер особової справи
Нагороди
Потреба в гуртожитку
Стаж роботи
Спеціалізації
Код спеціалізації
Найменування
Кафедра
Кількість місць
Факультети
Код факультету
Назва
Як будь-яка модель, модель «сутність-зв'язок» має кілька базових понять, які утворюють вихідні цеглинки, з яких будуються вже більш складні об'єкти за наперед визначеними правилами.
Сутність, за допомогою якої моделюється клас однотипних об'єктів. Сутність має ім'я, унікальне в межах модельованої системи. Так як сутність відповідає деякому класу однотипних об'єктів, то передбачається, що в системі існує безліч екземплярів даної суті. Об'єкт, якому відповідає поняття сутності, має свій набір атрибутів - характеристик, що визначають властивості даного представника класу. При цьому набір атрибутів повинен бути таким, щоб можна було розрізняти конкретні екземпляри сутності.
Розглянемо суті «Кафедра», «Абітурієнт», «Викладач», «Предмет навчального плану», «Група».
Кафедра
Код кафедри
Найменування
Завідувач


Визначення сутності «Кафедра» у моделі ER
Абітурієнт
Номер залікової книжки
Прізвище
Ім'я
По батькові
Рік народження батькові
Адреса
Домашній телефон


Рис. 2. Визначення сутності «Абітурієнт» у моделі ER

Рік народження батькові
Домашній телефон
Викладач
Код викладача
Табельний номер
Прізвище
Ім'я
По батькові
Код дисципліни
Домашня адреса
Посада
Адреса
Блок-схема: альтернативний процес: Рік народження батькові
Блок-схема: альтернативний процес: Адреса
Блок-схема: альтернативний процес: Домашній телефон


Рис. 3. Визначення сутності «Викладач» у моделі ER
Рік народження батькові
Домашній телефон
Код дисципліни
Найменування
Годинники
Вид заняття
Семестр
Вид здачі
Адреса
Блок-схема: альтернативний процес: Рік народження батькові
Блок-схема: альтернативний процес: Адреса
Блок-схема: альтернативний процес: Домашній телефон


Рис. 4. Визначення сутності «Дисципліна» в моделі ER
Група
Код групи
Найменування
Кількість абітурієнтів


Рис.5. Визначення сутності «Група» у моделі ER

Реляційна схема бази даних «Навчальний процес» представлена ​​наступними таблицями:
«Група» - містить по одному рядку для кожної з груп;
«Студенти» - містить по одному рядку для кожного зі студентів;
«Кафедра» - містить по одному рядку для кожної з кафедр;
«Викладач» - містить по одному рядку для кожного з викладачів;
«Предмет» - містить по одному рядку для кожного з предметів;
«Навчальний план» - містить по одному рядку для кожного виду заняття з кожного предмету окремого семестру;
«Успішність» - містить по одному рядку для кожного результату здачі окремим студентом окремої дисципліни.
Усі таблиці бази даних «Навчальний процес» знаходяться в третій нормальній формі:
· Кожен стовпець таблиці неподільний, і в рамках однієї таблиці немає стовпців з однаковими за змістом значеннями (1НФ);
· Первинні ключі однозначно визначають запис і ненадлишковим, всі поля кожної з таблиць залежать від її первинного ключа (2НФ);
· Значення будь-якого поля, що не входить у первинний ключ, не залежить від значення іншого поля, теж не входить у первинний ключ (3НФ).
У графічній формі зображені перераховані таблиці, їх стовпці, первинні та зовнішні ключі. Завдання первинних і зовнішніх ключів супроводжується побудовою додаткових структур - індексів, які забезпечують швидкий доступ до даних через значення ключа.


Структура бази даних

2.2. Зв'язки між сутностями

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


Зв'язок «один-до-багатьох» (1: М), один з боку «Викладач» і багато з боку «Абітурієнт»
У різних нотациях потужність зв'язку зображується по-різному. Між двома сутностями може бути задано скільки завгодно зв'язків з різними смисловими навантаженнями. Зв'язок будь-якого з цих типів може бути обов'язковою, якщо в даній зв'язку повинен брати участь кожен екземпляр сутності, необов'язковою - якщо не кожен екземпляр сутності повинен брати участь у цьому зв'язку. При цьому зв'язок може бути обов'язковою з одного боку і необов'язковою з іншого боку. Обов'язковість зв'язку теж по-різному позначається в різних нотациях. Ми знову використовуємо нотацію POWER DESIGNER. Тут необов'язковість зв'язку позначається порожнім кружечком на кінці зв'язку, а обов'язковість перпендикулярної лінією, який перекреслює зв'язок. І ця нотація має просту інтерпретацію. Кружальце означає, що жоден примірник не може брати участь в цьому зв'язку. А перпендикуляр інтерпретується як те, що, принаймні, один примірник сутності бере участь в цьому зв'язку.
Крім того, в ER-моделі допускається принцип категоризації сутностей. Це означає, що, як в об'єктно-орієнтованих мовах програмування, вводиться поняття підтипу сутності, тобто сутність може бути представлена ​​у вигляді двох або більше своїх підтипів - сутностей, кожна з яких може мати загальні атрибути і відносини і / або атрибути та відносини, які визначаються одного разу на верхньому рівні і успадковуються на нижньому рівні. Всі підтипи однієї сутності розглядаються як взаємовиключні, і при поділі сутності на підтипи вона повинна бути представлена ​​у вигляді повного набору взаємовиключних підтипів. Якщо на рівні аналізу не вдається виявити повний перелік підтипів, то вводиться спеціальний підтип, званий умовно «Інші», який в подальшому може бути уточнений. У реальних системах буває досить ввести подтіпізацію на двох-трьох рівнях.
Сутність має ім'я, унікальний у межах моделі. При цьому ім'я сутності - це ім'я типу, а не конкретного екземпляра.
Сутності поділяються на сильні і слабкі. Сутність є слабкою, якщо її існування залежить від іншої сутності - сильної по відношенню до неї.
Сутність може бути розщеплена на два або більше взаємовиключних підтипів, кожен з яких включає загальні атрибути та / або зв'язку. Ці загальні атрибути та / або зв'язку явно визначаються один раз на більш високому рівні. У підтипах можуть визначатися власні атрибути та / або зв'язку. У принципі виділення підтипів може тривати більш низьких рівнях, але в більшості випадків виявляється достатньо двох-трьох рівнів.
Сутність, на основі якої визначаються підтипи, називається супертіп. Підтипи повинні утворювати повне безліч, тобто будь-який екземпляр супертіпа повинен ставитися до деякого підтипу. Іноді для повноти безлічі треба визначати додатковий підтип, наприклад, «Інші».
Уявімо предметну область «Навчальний процес» як взаємодія наступних сутностей: кожен «Абітурієнт» здає іспит або залік по деякому «Предмету» згідно з навчальним планом. У навчальному процесі бере участь «Викладач», який здійснює читання навчального курсу та контроль знань «Абітурієнта». У навчальному процесі також бере участь «Кафедра», яка організовує роботу «Викладача». Навчання «Абітурієнта» ведеться в «Групі» спільно з його одногрупниками.
Слід зазначити, що для кожної суті встановлюється свій код - ключовий атрибут, однозначно характеризує сутність. Наприклад, звичайний номер Абітурієнта в групі не може виконувати роль ключа, оскільки для кожної групи ці номери можуть повторюватися. Для викладача атрибут Табельний номер небажано брати як ключового, оскільки все-таки можлива зміна табельної номери.
Для реалізації додаткових функцій бази може знадобитися введення додаткових атрибутів, наприклад, номера залікової книжки та домашнього телефону Абітурієнта, домашньої адреси та домашнього телефону викладача, посади викладача, робочої програми, дати складання іспиту (заліку) і т.д.
Будемо вважати для простоти всі зв'язки обов'язковими. Між виділеними сутностями можна виділити, наприклад, такі зв'язку:
1. «Абітурієнти» об'єднані в «Групи» (зв'язок М: 1).
2. Роботу «Викладачів» організовують «Кафедри» (зв'язок М: 1).
3. «Викладачі» викладають «Предмети навчального плану» (зв'язок 1: М).
5. «Абітурієнти» здають «Предмети навчального плану» (зв'язок М: М).
Покажемо тепер ці зв'язки між усіма сутностями графічно з використанням нотації POWER DESIGNER.
Будемо вважати для простоти, що всі Абітурієнти обов'язково об'єднані в групи.
Абітурієнт
Група


Об'єднання в групи
Блок-схема: рішення: Об'єднання в групи М 1


Моделювання зв'язку між сутностями «Абітурієнт» і «Група»
Аналогічним чином виглядає зв'язок «Викладач» і «Кафедра». Для простоти пропонується вважати, що кожен викладач обов'язково працює на який-небудь кафедрі.
Кафедра
Викладач
Об'єднання в кафедру
Блок-схема: рішення: Об'єднання в кафедру М 1


Моделювання зв'язку між сутностями «Викладач» і «Кафедра»
Версія повної ER-моделі для бази даних «Навчальний процес».

Група
Об'єднання в групи
Блок-схема: рішення: Об'єднання в групи
Абітурієнт
М 1


Вивчає
Блок-схема: рішення: Вивчає 1
Дисципліна
М
Викладає
Блок-схема: рішення: Викладає М
1 М 1
Викладач
Кафедра
Об'єднання в кафедру



Висновок

Процес проектування БД на основі принципів нормалізації представляє собою послідовність переходів від неформального словесного опису інформаційної структури предметної області до формалізованого опису об'єктів предметної області в термінах деякої моделі.
Инфологическая модель застосовується на другому етапі проектування БД, тобто після словесного опису предметної області. Процес проектування тривалий і вимагає обговорень із замовником і з фахівцями в предметної області. Нарешті, при розробці серйозних корпоративних інформаційних систем проект бази даних є тим фундаментом, на якому будується вся система в цілому, і питання про можливе кредитуванні часто вирішується експертами банку на підставі саме грамотно зробленого інфологічне проекту БД. Отже, инфологическая модель повинна включати таке формалізований опис предметної області, яке легко буде "читатися» не тільки фахівцями по базах даних. І це опис має бути настільки ємним, щоб можна було оцінити глибину і коректність опрацювання проекту БД, і звичайно, воно не повинно бути прив'язане до конкретної СУБД. Вибір СУБД - це окреме завдання, для коректного її вирішення необхідно мати проект, який не прив'язаний ні до якої конкретної СУБД.
Інфологічне проектування перш за все пов'язане зі спробою подання семантики предметної області в моделі БД. Реляційна модель даних в силу своєї простоти і лаконічності не дозволяє відобразити семантику, то є сенс предметної області.
На мій погляд, нелегко правильно сприйняти і оцінити тих порад і рекомендацій з побудови хорошою инфологической моделі, які десятиліттями формувалися найбільшими фахівцями в області обробки даних. В ідеалі необхідно, щоб попередньо був реалізований хоча б один проект інформаційної системи, запропонований його реальним користувачам.
Будь-які теоретичні рекомендації сприймаються всерйоз лише після кількох безрезультатних спроб пожвавлення невдало спроектованих систем. (Хоча є й такі проектувальники, які продовжують вірити, що зможуть реанімувати вмираючий проект за допомогою зміни програм, а не инфологической моделі бази даних.)
Для визначення переліку та структури даних, що зберігаються треба зібрати інформацію про реальних і потенційних додатках, а також про користувачів бази даних, а при побудові инфологической моделі слід дбати лише про надійність зберігання цих даних, геть забуваючи про додатки і користувачів, для яких створюється база даних.


Список літератури

1. Атре Ш. Структурний підхід до організації баз даних. - М.: Фінанси і статистика, 1983. - 320 с.
2. Бойко В.В., Савінков В.М. Проектування баз даних інформаційних систем. - М.: Фінанси і статистика, 1989. - 351 с.
3. Дейт К. Посібник з реляційної СУБД DB2. - М.: Фінанси і статистика, 1988. - 320 с.
4. Джексон Г. Проектування реляційних баз даних для використання з мікроЕОМ. -М.: Світ, 1991. - 252 с.
5. Кирилов В.В. Структурізованние мову запитів (SQL). - СПб.: ІТМО, 1994. - 80 с.
6. Мартін Дж. Планування розвитку автоматизованих систем. - М.: Фінанси і статистика, 1984. - 196 с.
7. Мейєр М. Теорія реляційних баз даних. - М.: Світ, 1987. - 608 с.
8. Тіорі Т., Фрай Дж. Проектування структур баз даних. У 2 кн., - М.: Світ, 1985. Кн. 1. - 287 с.: Кн. 2. - 320 с.
9. Ульман Дж. Бази даних на Паскалі. - М.: Машинобудування, 1990.-386 с.
10. Хаббард Дж. Автоматизоване проектування баз даних. - М.: Світ, 1984. - 294 с.
11. Цікрітізіс Д., лохівський Ф. Моделі даних. - М.: Фінанси і статистика, 1985. - 344 с.
Додати в блог або на сайт

Цей текст може містити помилки.

Програмування, комп'ютери, інформатика і кібернетика | Курсова
68кб. | скачати


Схожі роботи:
Інфологічне моделювання бази даних
Просопографіческіе бази даних Росії на прикладі баз даних Comandarm і Duma1
Використання електронної таблиці як бази даних Сортування і фільтрація даних в Microsoft Excel
Створення бази даних критичних властивостей речовин в редакторі баз даних MS Access
Бази даних банки даних загальне поняття
Захист даних і адміністрування бази даних
Бази даних
Бази даних 3
Бази даних 2
© Усі права захищені
написати до нас