Проектирование схемы данных процесса проведения производственной практики

Любая информационная система позволяет пользователям работать с информацией благодаря базам данных. Базы данных хранят всю необходимую информацию, связанную с конкретной предметной областью. Спроектируем процесс проведения производственной практики студентов в организации. В исследовании представлена реляционная база данных, особенностью которой является то, что данные хранятся в виде таблиц, а сами таблицы связаны между собой определёнными видами отношений[1].

Первой сущностью, вокруг которой всё строится, является сущность Studenti. Она олицетворяет всех студентов, которые могут прийти на практику в организацию. Они должны предоставить ряд своих личных данных, чтобы их можно было внести в систему. К таким данным относятся: фамилия, имя, отчество, серия и номер паспорта, адрес, телефон. При этом id_studenti является первичным ключом.

Таблица 1 Studenti

Сущность/Таблица	Атрибут/Поле	Тип
Studenti	id_studenti	INTEGER (NOT NULL)
	Familiya	STRING (NOT NULL)
	Imya	STRING (NOT NULL)
	Otchestvo	STRING
	Pasport_seriya	INTEGER (NOT NULL)
	Pasport_nomer	INTEGER (NOT NULL)
	Adres	STRING
	Telefone	INTEGER

У студентов имеется место учёбы VUZ и направление подготовки

Kafedri. Эти учебные заведения имеют название и конкретный адрес. А направление подготовки чётко закреплено за кафедрами, принадлежащими этим учебным заведениям. Важно учитывать, что у одного ВУЗа может быть несколько кафедр, следовательно, сущности VUZ и Kafedri будут связаны, как «Один ко многим». Первичными ключами будут id_vuz и id_kafedri соответственно.

Таблица 2 Место обучения

Сущность/Таблица	Атрибут/Поле	Тип
VUZ	id_vuz	INTEGER (NOT NULL)
	Nazvanie	STRING (NOT NULL)
	Adres	STRING
Kafedri	id_kafedri	INTEGER (NOT NULL)

	id_vuz (FK)	INTEGER (NOT NULL)
	Nazvanie	STRING (NOT NULL)
	Adres	STRING

Теперь можно объединить всю получившуюся информацию с помощью сущности Student_kafedra и дополнить её. В качестве дополнительного атрибута необходимо указать курс студента, потому что от этого будет зависеть сложность последующих заданий. А вся остальная информация будет поступать от сущностей Kafedri и Studenti, что подразумевает использование связи «Один ко многим». При этом id_student_kafedra является первичным ключом.

Таблица 3 Student_kafedra

Сущность/Таблица	Атрибут/Поле	Тип
Student_kafedra	id_student_kafedra	INTEGER (NOT NULL)
	id_studenti (FK)	INTEGER (NOT NULL)
	id_kafedri (FK)	INTEGER (NOT NULL)
	Kurs	INTEGER

Далее необходимо рассмотреть сотрудников Sotrudniki, которые будут работать со студентами Student_kafedra. Они могут быть из разных подразделений Podrazdeleniya, а сами подразделения могут принадлежать разным компаниям Organizacii. У данных компаний есть конкретный адрес, название и контактные данные. В свою очередь у подразделений есть только названия. А о сотрудниках нужно знать их фамилию, имя, отчество, должность и способ с ними связаться. Так как сущность Organizacii входит в сущность Podrazdeleniya, а Podrazdeleniya входят в сущность Sotrudniki, то между ними используется связь «Один ко многим». А id_organizacii, id_podrazdeleniya и id_sotrudniki будут первичными ключами соответственно.

Таблица 4 Сотрудники организации

Сущность/Таблица	Атрибут/Поле	Тип
Organizacii	id_organizacii	INTEGER (NOT NULL)
	Nazvanie	STRING (NOT NULL)
	Adres	STRING
	Telefone	INTEGER
Podrazdeleniya	id_podrazdeleniya	INTEGER (NOT NULL)
	id_organizacii (FK)	INTEGER (NOT NULL)
	Nazvanie	STRING (NOT NULL)

Sotrudniki	id_sotrudniki	INTEGER (NOT NULL)
	id_podrazdeleniyaFK	INTEGER (NOT NULL)
	Familiya	STRING (NOT NULL)
	Imya	STRING (NOT NULL)
	Otchestvo	STRING
	Doljnost	STRING (NOT NULL)
	Telefone	INTEGER

Перед тем, как студентов примут на практику, должен пройти отбор.

Его олицетворяет сущность Otbor. Каждый студент должен пройти собеседование и тестирование по информационной безопасности. В процессе прохождения студентами этих этапов, уполномоченные сотрудники будут оставлять свои комментарии. Таким образом, сущность Student_kafedra связана с сущностью Otbor, как «Один ко многим», а id_otbor является первичным ключом.

Таблица 5 Otbor

Сущность/Таблица	Атрибут/Поле	Тип
Otbor	id_otbor	INTEGER (NOT NULL)
	id_student_kafedra (FK)	INTEGER (NOT NULL)
	Sobesedovanie	BOOLEAN
	Testirovanie	BOOLEAN
	Komentariy	STRING

В случае выполнения всех условий студента вносят в базу данных и составляют приказ. Он должен включать в себя номер, дату начала и конца практики. Сам приказ не является чем-то уникальным, значит, для идентификации его сущности Prikazi требуется участие двух других сущностей: Sotrudniki и Student_kafedra. То есть будет использоваться идентифицирующая связь, а первичный ключ будет состоять из id_sotrudniki (FK) и id_student_kafedra (FK).

Далее не будем предоставлять таблицы, а ограничимся словесным описанием.

На самой практике студенты должны выполнять различные задания. Для контроля выполненных этапов требуется отслеживать их прогресс. В сущности Zadaniya требуется указать вид работы и статус её выполнения. Сущности Student_kafedra и Sotrudniki связаны с Zadaniya, как «Один ко многим». При этом id_zadaniya выступает в роли первичного ключа.

Одним из важных моментов для студентов является посещение места прохождения практики, так как от этого напрямую зависит оценка в зачётной книжке. Сущностью, которая осуществляет учёт времени для каждого студента, является Vremya_na_praktike. Она соединена идентифицирующей связью с сущностью Student_kafedra. В таком случае получается, что первичным ключом будет id_student_kafedra (FK).

После создания таблиц и связей между ними в ERwin Data Modeler были добавлены атрибуты в соответствующие сущности, которые представлены на рисунке 1 в виде физической модели базы данных с уже заполненными полями в таблицах.

Studenti

d_studenti

Famdry a Imya Otchestvo Pasport_serrya Pa sport посте* Acres Telefone

Orgarvzaca

Zadaruya

Kafedn

■d_kafedn d_vuz (FK) Nazvame

na_prakt*e d_student_kafedra (FK)

d_student_kafedra (FK)

Data Vremya_pnbrtrya Vremya_ubrtrya

Student_kafedra id student kafedra

Norn e<_pnk aza

Data_nachala_prakbk

Data_okonchanrya_praktiki

ri_otbor

■d_org a ruz ac«

Naz v a rue

Adres TeJefone

--О Sobesedovarve Testrovarue Komentany id_student_kafedra (FK)

Podrazdelencya d_podrazde4emya

Nazvarue

•d_organ

Vremya.

Sotrudruki

d_sotrudnakj

»d_zadarwya

Zadanrya

VipoJnerue id_student_kafedra (FK)

Famdry a

Imya

Otchestvo

•d podrazde4ervya (FK)

Рис. 1 Физическая модель базы данных

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