Разработка приложения для базы данных «Музыкальная школа»

 

Рисунок А.2 – Диаграмма декомпозиции

Выполнение работы «Ведение учета  учеников» осуществляется с помощью ресурса: «Руководство».

В результате декомпозиции бизнес-процесса «Ведение учета школьников» выделено три процесса:

• ведение учёта школьников, их личных данных и данных о родителях
• учёт данных для учителя
• формирование отчётных документов

Для реализации этих процессов определены хранилища данных:

• учитель;
• классное руководство;
• класс;
• ученик;

Входными данными для процесса «Ведение учёта приема и выпуска  учеников» являются:

• личные данные родителей;
• личные данные учащихся;
• список класса;
• сведения об учащихся;

Выходными данными для процесса «Ведение учёта приема и выпуска учеников» являются:

• личные карточки учеников;
• сведения об учащихся;
• сводные данные об учащихся;

Входными данными для процесса «Формирование класса» являются:

• сведение об учащихся;
• данные о расписании;
• информация о классе;

Выходными данными для процесса «Формирование класса» являются:

• сведение о классе.

Входными данными для процесса «Корректировка сведений по классному  руководству» являются:

• список класса;
• сведение об учителе;

Выходными данными для процесса «Корректировка сведений по классному руководству» являются:

• данные о классном руководстве.

Входными данными для процесса «Корректировка сведений по расписанию» являются:

• информация по расписанию.

Выходными данными для процесса «Корректировка сведений по расписанию» являются:

• расписание занятий.

Входными данными для процесса «Учет личных данных учителей» являются:

• сведения об учителе;
• сведения по классному руководству.

Выходными данными для процесса «Учет личных данных учителе» являются:

• сведения об учителе;
• личная карточка учителя.

Диаграмма, полученная в результате декомпозиции бизнес-процесса «Ведение учета школьников», представлена на рисунке 2.

Все процессы являются элементарными  и их дальнейшая декомпозиция не требуется.

 

4. Создание структур данных

Определим следующие структуры  данных:

- STUDENT

• SPECIALNOST
• PREPODAVATELI

 

Структуры данных системы, представлены в таблицах 2-4.

 

Таблица 2- Описание структуры данных STUDENT

Имя атрибута	Назначение
Name	Имя ученика
FirstName	Фамилия ученика
ParentName	Отчество ученика
Specialnost	Специальность, на которой будет  обучаться ученик
Date	Дата поступления
HomeAdress	Домашний адрес
PhoneNumber	Контактный телефон
NamePrepod	Фамилия преподавателя
ID	Уникальный номер записей таблицы  STUDENT

 

Таблица 3- Описание структуры данных SPECIALNOST

Имя атрибута	Назначение
Code	Код специальности
NaimSpec	Наименование специальности
NamePrepod	Фамилия преподавателя
ID	Уникальный номер записей таблицы  SPECIALNOST

 

Таблица 4- Описание структуры данных PREPODAVATELI

Имя атрибута	Назначение
NamePrepod	Имя преподавателя
FNamePrepod	Фамилия преподавателя
Otchestvo	Отчество преподавателя
Specialnost	Специальность
ID	Уникальный номер записей таблицы  PREPODAVATELI

 

Таким образом, были разработаны контекстная и детализирующая диаграммы, также структуры данных системы.

 

2. Разработка концептуальной модели

На основании разработанных  контекстной и детализирующей диаграмм и структуры данных была спроектирована концептуальная модель данных, представленная на рисунке 3.

 

Концептуальная модель данных содержит 3 сущности: Student, Prepodavateli , Specialnost.

 

 

Рисунок 3 - Концептуальная модель данных

 

Сущности Student и Specialnost соединены связью «учатся на». Так как у ученика не может быть 0 специальностей но и больше 1 специальности быть у него не может,то показатель кардинальности связи между сущностями Student и Specialnost равен 1:1. Бинарная связь с обязательным участием сущности Specialnost. Причем сущность Specialnost является сильной по отношению к сущности Student, на специальности в определенный момент может и не быть ни одного ученика. Сущности Prepodavateli и Specialnost соединены связью «Преподает на». Так как у преподавателя не может быть 0 специальностей но и больше 1 специальности быть у него не может, то показатель кардинальности связи между сущностями Prepodavateli и Specialnost равен 1:1. Бинарная связь с обязательным участием сущности Specialnost. Причем сущность Specialnost является сильной по отношению к сущности Student, на специальности в определенный момент может и не быть ни одного преподавателя.

Также на специальности может быть сколько угодно преподавателей и  студентов, поэтому показатель кардинальности у Specialnost равен 1: N. Одна специальность ко многим студентам и многим преподавателям.

 

3. Логическое проектирование БД

 

На основании концептуальной модели данных была разработана логическая модель данных, представленная на рисунке 4.

 

Рисунок 4 – реляционная модель данных

 

Логическая модель данных создана  путем преобразования концептуальной модели средствами системы OpenModelSphere. Для реляционной модели необходимо сгенерировать внешние ключи. В OpenModelSphere по умолчанию внешние ключи определяются с помощью первичных ключей. В результате генерации получаем внешний ключ сущности STUDENT:

• FK1 Specialnost ID — внешний ключ на поле ID сущности Specialnost;

а также внешний ключ сущности Prepodavateli:

• FK1 Specialnost ID - внешний ключ на поле ID сущности Specialnost.

 

Также на данном этапе определяются правила поддержки ссылочной  целостности (update rule) для всех ролей модели. Устанавливаем значение, откладывающее окончательное формирование правил ссылочной целостности до этапа разработки приложения для разрабатываемой информационной системы.

Определены физические имена и  допустимость нулевых значений атрибутов  сущностей, представленные в таблицах 5-7. Первичные ключи в таблицах выделены подчеркиванием.

 

Таблица 5- Сущность Student

Имя атрибута	Значение NULL
Name	Допустимо
FirstName	Допустимо
ParentName	Допустимо
Specialnost	Недопустимо
Date	Допустимо
HomeAdress	Допустимо
PhoneNumber	Допустимо
NamePrepod	Допустимо
ID	Недопустимо

 

Таблица 6- Сущность SPECIALNOST

Имя атрибута	Значение NULL
Code	Недопустимо
NaimSpec	Допустимо
NamePrepod	Допустимо
ID	Недопустимо

 

Таблица 7- Сущность PREPODAVATELI

Имя атрибута	Значение NULL
NamePrepod	Допустимо
FNamePrepod	Допустимо
Otchestvo	Допустимо
Specialnost	Недопустимо
ID	Недопустимо

 

4. Физическое проектирование БД

На основании логической модели была разработана физическая модель данных, представленная на рисунке 5.

 

Рисунок 5 – Физическая модель данных FireBird 2.5

 

Этап физического проектирования базы данных предусматривает принятие разработчиком окончательного решения о способах реализации создаваемой базы. В качестве СУБД была задана Firebird 2.5. Соответственно для определения типов данных в столбцах таблиц физической модели используются встроенные типы данных, поддерживаемые СУБД Firebird 2.5.

Определены типы данных атрибутов сущностей, представленные в таблицах 8-10.

Таблица 8- Сущность Student

Имя атрибута	Тип домена	Длина поля	Ключевые парам.
Name	Char	30
FirstName	Char	20
ParentName	Char	40
Specialnost	SmalInt
Date	Date
HomeAdress	Char	60
PhoneNumber	Char	10
NamePrepod	Char	30
ID	Integer		PK, FK

 

Таблица 9- Сущность SPECIALNOST

Имя атрибута	Значение NULL	Длина поля	Ключевые парам.
Code	SmalInt		Unique
NaimSpec	Char	100
NamePrepod	Char	40
ID	Integer		PK

 

Таблица 10- Сущность PREPODAVATELI

Имя атрибута	Значение NULL	Длина поля	Ключевые парам.
NamePrepod	Char	40
FNamePrepod	Char	20
Otchestvo	Char	30
Specialnost	SmalInt
ID	Integer		PK

 

 

 

Таким образом, на основании логической модели была создана физическая модель данных.

Создан SQL-скрипт базы данных, приведенный в приложении В.

База данных создана с помощью  инструментального средства IBExpert и находится в файле MUSICSCHOOL.fdb. База данных создана для пользователя SYSDBA (пароль masterkey).

SQL-скрипт базы данных содержит разработанные генераторы и триггеры для каждой таблицы.

Список генераторов представлен  в таблице 11.

 

Таблица 11- Список генераторов

Имя генератора	Описание
GEN_PREPOD_ID	Создан для таблицы Prepod для реализации автоинкрементного поля ID.
GEN_SPECIA_ID	Создан для таблицы SPECIA для реализации автоинкрементного поля ID.
GEN_STUDENT_ID	Создан для таблицы STUDENT для реализации автоинкрементного поля ID.

 

Таблица тригеров

Имя тригера	Описание
PREPOD_BI	Создан для добавления записи в  таблицу PREPOD
SPECIA_BI	Создан для добавления записи в  таблицу SPECIA
STUDENT_BI	Создан для добавления записи в  таблицу STUDENT

 

Таблица хранимых процедур

Имя тригера	Описание
PROC_INTO_PREPOD	Процедура создания или редактирования записей таблицы PREPOD, согласно входн. параметрам
PROC_INTO_ STUDENT	Процедура создания или редактирования записей таблицы STUDENT, согласно входн. параметрам
PROC_INTO_ SPECIA	Процедура создания или редактирования записей таблицы SPECIA, согласно входн. параметрам