Моделиране на реална ситуация

3.2.Създаване на прост модел

• 
  За дадена дисциплина има един преподавател и произволен брой студенти;
  
• 
  Студентите посещават една или повече дисциплини;
  
• 
  Преподавателите преподават една или повече дисциплини;
  
• 
  Всеки студент получава по една оценка по всяка дисциплина;
  
• 
  За всяка дисциплина трябва да проследим следните данни: име и брой часове;
  
• 
  За всеки студент трябва да проследим следните данни: име и оценки по съответните дисциплини;
  
• 
  За всеки преподавател трябва да проследим следната информация: име и позиция (асистент, доцент, професор и т.н.). Ако е асистент, кой е контролиращият го.
  

• 
  Дисциплини – Classes
  
• 
  Преподаватели – Teachers
  
• 
  Студенти – Students
  

• 
  Съществува релация 1:n “преподава” (teaches) между обектите Преподаватели (Teachers) и Предмети (Classes);
  
• 
  Съществува релация m:n “посещава” (attends) между обектите Студенти (Students) и Предмети (Classes);
  
• 
  Съществува циклична релация “контролиран от” (controlled_by) между обекта Преподаватели (Teachers) и самия него.
  

Дотук извлякохме най-важните обекти и релации. Атрибутите са елементите от информацията, които трябва да проследим. Интересуват ни:

• 
  Име на преподавателя
  
• 
  Име на студента;
  
• 
  Наименование на предмета;
  
• 
  Брой часове на предмета;
  
• 
  Оценка на студента по предмета;
  
• 
  Позиция на преподавателя.
  

Диаграмата на фиг. 13-1 представя ER модела.

От схемата се вижда, че обектът:

• 
  Students има атрибут student_name, който представлява името на студента;
  
• 
  Teachers има атрибути: teacher_name – име на преподавателя; position – позиция на преподавателя;
  
• 
  Classes има атрибути: class_name – име на предмета; horarium – брой часове;
  

Съществува пряк алгоритъм за генериране на схемата на една база данни от ER диаграма. Този алгоритъм позволява на някои програмни средства (PowerDesigner, erWin) да генерират автоматично подобни схеми. Но добре е да се тества този процес внимателно, защото може да се наложат някои корекции с оглед на получавания резултат.

Основният алгоритъм е следният: всеки обект се превръща в таблица. За тази таблица се добавя първичен ключ, ако обектът е нямал уникален идентификатор (но в нашия случай обектите имат такъв и той преминава в първичен ключ на съответната таблица). Всеки атрибут, който може да има само една стойност, става колона в тази таблица. Ако обектът е слаб, той ще съдържа също така и външен ключ, който сочи към силния обект, от който слабият зависи.

Дадена релация 1:n се реализира чрез прибавяне на външен ключ към таблицата за обекта от страната n, сочещ към първичния ключ на таблицата от страната 1.

За една релация m:n се създава таблица, независима от всеки един от обектите, участващи в релацията. Причината се състои в това, че всеки един обект може да участва в релацията няколко пъти. Следователно нито един от двата обекта не може да функционира като първичен ключ, докато комбинацията от двата трябва да бъде уникална. Например, тъй като всеки студент може да се запише за повече от един предмет, то трябва да направим множество записи за всеки един студент, за да регистрираме този факт, а в рамките на таблицата Students това е неприемливо. Същата е ситуацията с таблицата за предметите Classes, които могат да бъдат посещавани от много студенти.

Генерирана по описания алгоритъм, схемата на базата данни би изглеждала както е показано на фигура 13-2. На тази схема е съществено да отбележим цикличната релация, преминала във външен ключ за таблицата Teachers към самата себе си. Смисълът й беше, че всеки асистент има доцент или професор, който го контролира. Съществено е да се отбележи, че чрез циклични релации, респективно външен ключ към същата таблица, могат да съхранявани дървовидни структури в една таблица.