Інфологіческое моделювання бази даних - абітурієнт
Як будь-яка модель, модель «сутність-зв'язок» має кілька базових понять, які утворюють вихідні цеглинки, з яких будуються вже більш складні об'єкти за заздалегідь визначеними правилами.
Сутність. за допомогою якої моделюється клас однотипних об'єктів. Сутність має ім'я, унікальне в межах системи, що моделюється. Так як сутність відповідає деякому класу однотипних об'єктів, то передбачається, що в системі існує безліч екземплярів даної сутності. Об'єкт, якому відповідав би поняття сутності, має свій набір атрибутів - характеристик, що визначають властивості даного представника класу. При цьому набір атрибутів повинен бути таким, щоб можна було розрізняти конкретні екземпляри сутності.
Розглянемо суті «Кафедра», «Абітурієнт», «Викладач», «Предмет навчального плану», «Група».
Визначення сутності «Кафедра» в моделі ER
Мал. 2. Визначення сутності «Абітурієнт» в моделі ER
Мал. 3. Визначення сутності «Викладач» в моделі ER
Мал. 4. Визначення сутності «Дисципліна» в моделі ER
Рис.5. Визначення сутності «Група» в моделі ER
Реляційна схема бази даних «Навчальний процес» представлена наступними таблицями:
«Група» - містить по одному рядку для кожної з груп;
«Студенти» - містить по одному рядку для кожного зі студентів;
«Кафедра» - містить по одному рядку для кожної з кафедр;
«Викладач» - містить по одному рядку для кожного з викладачів;
«Предмет» - містить по одному рядку для кожного з предметів;
«Навчальний план» - містить по одному рядку для кожного виду заняття по кожному предмету окремого семестру;
«Успішність» - містить по одному рядку для кожного результату здачі окремим студентом окремої дисципліни.
Всі таблиці бази даних «Навчальний процес» знаходяться в третій нормальній формі:
· Кожен стовпець таблиці неподільний, і в рамках однієї таблиці немає стовпців з однаковими за змістом значеннями (1НФ);
· Первинні ключі однозначно визначають запис і ненадлишкових, все поля кожної з таблиць залежать від її первинного ключа (2НФ);
· Значення будь-якого поля, що не входить в первинний ключ, не залежить від значення іншого поля, теж не входить у первинний ключ (3НФ).
У графічній формі зображені перераховані таблиці, їх стовпці, первинні і зовнішні ключі. Завдання первинних і зовнішніх ключів супроводжується побудовою додаткових структур - індексів, які забезпечують швидкий доступ до даних через значення ключа.
Структура бази даних
Між сутностями можуть бути встановлені зв'язки - бінарні асоціації, що показують, яким чином сутності співвідносяться або взаємодіють між собою. Зв'язок може існувати між двома різними сутностями або між сутністю і їй же самій (рекурсивна зв'язок). Вона показує, як пов'язані екземпляри сутностей між собою. Якщо зв'язок встановлюється між двома сутностями, то вона визначає взаємозв'язок між екземплярами однієї й іншої сутності
Зв'язок «один-ко-многим» (1: М), один з боку «Викладач» і багато з боку «Абітурієнт»
У різних нотациях потужність зв'язку зображується по-різному. Між двома сутностями може бути задано скільки завгодно зв'язків з різними смисловими навантаженнями. Зв'язок будь-якого з цих типів може бути обов'язковою. якщо в зв'язку з цим повинен брати участь кожен екземпляр сутності, необов'язковою - якщо не кожен екземпляр сутності повинен брати участь в цих питань. При цьому зв'язок може бути обов'язковою з одного боку і необов'язковою з іншого боку. Обов'язковість зв'язку теж по-різному позначається в різних нотациях. Ми знову використовуємо нотацію POWERDESIGNER. Тут необов'язковість зв'язку позначається порожнім кружечком на кінці зв'язку, а обов'язковість перпендикулярної лінією, перекреслює зв'язок. І ця нотація має просту інтерпретацію. Кружечок означає, що жоден екземпляр не може брати участь в зв'язку з цим. А перпендикуляр інтерпретується як те, що, по крайней мере, один екземпляр сутності бере участь в зв'язку з цим.
Сутність має ім'я, унікальне в межах моделі. При цьому ім'я сутності - це ім'я типу, а не конкретного екземпляра.
Сутності поділяються на сильні і слабкі. Сутність є слабкою, якщо її існування залежить від іншої сутності - сильної по відношенню до неї.
Сутність може бути розщеплена на два або більше взаємовиключних підтипів, кожен з яких включає загальні атрибути та / або зв'язку. Ці загальні атрибути та / або зв'язку явно визначаються один раз на більш високому рівні. У підтипів можуть визначатися власні атрибути і / або зв'язку. В принципі виділення підтипів може тривати на більш низьких рівнях, але в більшості випадків виявляється достатньо двох-трьох рівнів.
Сутність, на основі якої визначаються підтипи, називається супертіп. Підтипи повинні утворювати повне безліч, тобто будь-який екземпляр супертіпа повинен ставитися до деякого підтипу. Іноді для повноти безлічі треба визначати додатковий підтип, наприклад, «Інші».
Уявімо предметну область «Навчальний процес» як взаємодія наступних сутностей: кожен «Абітурієнт» здає іспит або залік по деякому «Предмету» згідно з навчальним планом. У навчальному процесі бере участь «Викладач», який здійснює читання навчального курсу і контроль знань «Абітурієнта». У навчальному процесі також бере участь «Кафедра», яка організовує роботу «Викладача». Навчання «Абітурієнта» ведеться в «Групі» спільно з його одногрупниками.
Слід зазначити, що для кожної сутності встановлюється свій код - ключовий атрибут, однозначно характеризує сутність. Наприклад, звичайний номер Абітурієнта в групі не може виконувати роль ключа, оскільки для кожної групи ці номери можуть повторюватися. Для викладача атрибут Табельний номер небажано брати в якості ключового, оскільки все-таки можлива зміна табельної номера.
Будемо вважати для простоти всі зв'язки обов'язковими. Між виділеними сутностями можна виділити, наприклад, такі зв'язки:
1. «Абітурієнти» об'єднані в «Групи» (зв'язок М: 1).
2. Роботу «Викладачів» організовують «Кафедри» (зв'язок М: 1).
3. «Викладачі» викладають «Предмети навчального плану» (зв'язок 1: М).
5. «Абітурієнти» здають «Предмети навчального плану» (зв'язок М: М).
Покажемо тепер ці зв'язки між усіма сутностями графічно з використанням нотації POWERDESIGNER.
Будемо вважати для простоти, що все Абітурієнти обов'язково об'єднані в групи.
Процес проектування БД на основі принципів нормалізації представляє собою послідовність переходів від неформального словесного опису інформаційної структури предметної області до формалізованого опису об'єктів предметної області в термінах деякої моделі.
Инфологическая модель застосовується на другому етапі проектування БД, тобто після словесного опису предметної області. Процес проектування тривалий і вимагає обговорень з замовником і з фахівцями в предметної області. Нарешті, при розробці серйозних корпоративних інформаційних систем проект бази даних є тим фундаментом, на якому будується вся система в цілому, і питання про можливе кредитуванні часто вирішується експертами банку на підставі саме грамотно зробленого інфологічне проекту БД. Отже, інфологіческая модель повинна включати таке формалізоване опис предметної області, яке легко буде «читатися» не тільки фахівцями по базах даних. І це опис має бути настільки ємним, щоб можна було оцінити глибину і коректність опрацювання проекту БД, і звичайно, воно не повинно бути прив'язане до конкретної СУБД. Вибір СУБД - це окреме завдання, для коректного її вирішення необхідно мати проект, який не прив'язаний ні до якої конкретної СУБД.
Інфологіческое проектування перш за все пов'язано зі спробою уявлення семантики предметної області в моделі БД. Реляційна модель даних в силу своєї простоти і лаконічності не дозволяє відобразити семантику, тобто зміст предметної області.
На мій погляд, нелегко правильно сприйняти і оцінити тих порад і рекомендацій з побудови хорошою инфологической моделі, які десятиліттями формувалися найбільшими фахівцями в області обробки даних. В ідеалі необхідно, щоб попередньо був реалізований хоча б один проект інформаційної системи, запропонований його реальним користувачам.
Будь-які теоретичні рекомендації сприймаються всерйоз лише після кількох безрезультатних спроб пожвавлення невдало спроектованих систем. (Хоча є й такі проектувальники, які продовжують вірити, що зможуть реанімувати вмираючий проект за допомогою зміни програм, а не інфологічної моделі бази даних.)
Для визначення переліку та структури збережених даних треба зібрати інформацію про реальних і потенційних додатках, а також про користувачів бази даних, а при побудові інфологічної моделі слід дбати лише про надійність зберігання цих даних, геть забуваючи про додатки і користувачів, для яких створюється база даних.
1. Атре Ш. Структурний підхід до організації баз даних. - М. Фінанси і статистика, 1983. - 320 с.
2. Бойко В.В. Савінков В.М. Проектування баз даних інформаційних систем. - М. Фінанси і статистика, 1989. - 351 с.
3. Дейт К. Посібник з реляційної СУБД DB2. - М. Фінанси і статистика, 1988. - 320 с.
7. Мейер М. Теорія реляційних баз даних. - М. Мир, 1987. - 608 с.
8. Тіорі Т. Фрай Дж. Проектування структур баз даних. У 2 кн. - М. Мир, 1985. Кн. 1. - 287 с. Кн. 2. - 320 с.
10. Хаббард Дж. Автоматизоване проектування баз даних. - М. Мир, 1984. - 294 с.
11. Цікрітізіс Д. Лоховскі Ф. Моделі даних. - М. Фінанси і статистика, 1985. - 344 с.