В статье приведён пример создания и проектирования базы данных для лаборатории микроскопии. Для дальнейшего облегчения анализа и обработки данных полученных входе исследований и опытов.
Информационные технологии вошли в нашу повседневную жизнь большим объемом и безвозвратно. Еще раньше началось применение этих технологий в сфере науки. Только раньше использовались понятия вычислительная техника и автоматизированные системы. Сильно развилась и такая область как телекоммуникационные технологии, которые стали неотъемлемой составляющей любой автоматизированной информационной системы [1].
Вместе с тем росла сложность и информативность научного эксперимента. Экспериментальные установки становятся все сложнее, как в плане управления экспериментом, так и в области обработки и получения конечных данных. С применением компьютеров в этой области возрос и объем получаемых экспериментальных результатов. Теперь наряду с традиционными это могут быть большие объемы данных таких как: фото, аудио и видеоданные в цифровом виде. Но улучшение условий эксперимента и экспериментального оборудования выдвигает свои требования — теперь уже недостаточно интерпретировать какое-то явление, свойство, опираясь лишь на исследование одним методом, на одной установке. Если учесть, что экспериментальные лаборатории могу быть разнесены по разным зданиям, городам, и даже странам, то возникает необходимость аккумулировать все результаты научных исследований в одной базе для их дальнейшего, более плодотворного, анализа. Очевидно, что использовать для этого нужно простые, проверенные и наиболее используемые интерфейсы. К таковым, например, можно отнести Web-интерфейс [2].
Целью данной работы является создание базы данных реляционного типа с использованием СУБД, которая управлялась через Web-интерфейс и могла быть доступна различным пользователям как в плане удаленности, так и с учетом политики безопасности.
1. Анализ предметной области
База данных (далее — БД) разрабатывается для сотрудников и гостей WEB-приложения. Поэтому БД должна содержать как публичные, так и конфиденциальные для посетителей данные, к которым могут иметь доступ только сотрудники лаборатории микроскопии. В ней так же должны содержаться данные: о сотрудниках использующие данную систему, об исследуемых объектов в лаборатории и их свойствах и временного характера (время внесения данных, изменения данных).
В соответствии с предметной областью система строится с учетом следующих особенностей [3]:
1) Каждый исследуемый объект в лаборатории имеет уникальный номер и название;
2) Каждый сотрудник имеет свой уникальный номер;
3) Каждое свойство объекта имеет уникальный номер и свое название;
4) Наличие списка приборов для проведения опыта
Выделим следующие базовые сущности нашей области:
- Изучаемый объект (object)
- Модификации Объекта (group_object)
- Наименования свойств ихарактеристик объектов (characteristic)
- Свойства ихарактеристики объектов (sub_characteristic)
- Роли пользователей (name_of_role)
- Пользователи (users)
- Время изменения характеристик уобъекта (time_change_object)
- Значения характеристик (value)
2. Анализ информационных задач и круга пользовательской системы
Можно выделить 3 основные роли, у каждой из которой есть свои возможности работы с системой:
Администратор
Пользователь с наивысшим доступом, «Администратор», имеет возможность полного доступа ко всем функциям: добавления, чтения, изменения, удаления. А также отслеживания, кем была добавлена или изменена запись в базе данных.
Пользователь
Данный вид пользователя имеет доступ к функциям добавления данных, и их изменения.
Гость
Пользователь с наименьшими правами. «Гость» имеет возможность просмотра данных, а также её копирования.
Рис. 1. Диаграмма вариантов использования
Функциональные возможности:
1) Ведение БД (запись, чтение, удаление, модификация);
2) Обеспечение логической непротиворечивости БД;
3) Реализация наиболее часто встречающихся запросов и представлений для пользователей в готовом виде;
4) Реализация хранимых процедур и триггеров для поддержания сложных ограничений целостности в БД.
3. Выработка требований и ограничений
Основные ограничения целостности:
1) Значения всех числовых атрибутов не должны быть отрицательными и ограничены значениями из соображений логики функций, которые она выполняют [4].
– Коды, являющиеся первичными ключами для каждой сущности, имеют ограничения от 0001 до 9999 или от 200000 до 2000000000.
– Дата внесения данных выставляется автоматически.
2) Символьные атрибуты должны выполнять все требования для функции, которую они выполняют
– Названия имеют 1–50 символов кириллицы, латиницы, пробел, запятая, дефис.
В ходе проектирования, сформировалась следующее представление об БД, которое наглядно представлено на рисунке 2.
Рис. 2. Схема БД
К атрибутам каждой сущности относятся:
- object: id, name_object, id_user, time_add_object, time_change_object, name_of_device, id_characteristic_N
- device: id, name_of_device, description_of_device
- characteristic: id, name_characteristic, description
- sub-characteristic: id, id_characteristic, name_sub-property, description_sub-property.
- name_of_role: id, name_of_role
- users: id, login, password, first_name, last_name, patronymic, e-mail, phone, foto, id_role_of_user
- time_change_object: id, id_object, time_change_object, id_user_change_object.
- value: id, id_object, id_sub_characteristic, value
Сущность “object” служит для идентификации исходного изучаемого объекта в лаборатории и содержит идентификационный номер пользователя, который создал запись об объекте, время создания записи и название прибора на котором был проведён опыт. Во время исследования объекта, присваиваются наличие тех или иных свойств. При отсутствии наличия определённого свойства у объекта, в таблицу записывается параметр Null. Подробные параметры приведены в таблице 1.
Таблица 1
Сущность «object»
Атрибут |
Тип |
Null |
Unique |
Назначение |
id |
int |
Not Null |
да |
Первичный ключ: код объекта |
name_object |
varchar |
Not Null |
да |
Наименование объекта |
id_user |
int |
Not Null |
нет |
Внешний ключ: код пользователя |
time_add_object |
date |
Not Null |
нет |
Время внесения новых данных |
id_time_change_object |
int |
Null |
нет |
Внешний ключ: Время последнего изменения |
id_device |
varchar |
Null |
нет |
Внешний ключ: код прибора |
id_characteristic_1 |
int |
Null |
нет |
Внешний ключ: код свойства объекта. В ходе эксплуатации системы, столбцы будут пополнятся новыми свойствами |
…………. |
||||
id_characteristic_N |
При исследовании объекта необходимо знать на каком приборе проходили опты. Для этого создана сущность “device”. В ней хранятся такие данные как: идентификационный номер, название прибора и подробное описание данного прибора. Подробные параметры приведены в таблице 2.
Таблица 2
Сущность “characteristic”
Атрибут |
Тип |
Null |
Unique |
Назначение |
id |
int |
Not Null |
да |
Первичный ключ: код прибора |
name_of_device |
varchar |
Not Null |
да |
Наименование прибора |
description_of_charecteristic |
varchar |
Null |
нет |
Описание прибора |
Каждое свойство имеет своё уникальное наименование, а также подробное описание этого свойства. Описанные данные хранятся в сущности под названием “characteristic”. Подробные параметры приведены в таблице 2.
Таблица 3
Сущность “characteristic”
Атрибут |
Тип |
Null |
Unique |
Назначение |
id |
int |
Not Null |
да |
Первичный ключ: код характеристики |
name_of_characteristic |
varchar |
Not Null |
да |
Наименование свойства |
description_of_charecteristic |
varchar |
Null |
нет |
Описание свойства |
Каждое свойство может иметь подсвойства, каждое из которых имеет своё название, подробное описание и итоговое значение после проведённого опыта. Подробные параметры приведены в таблице 2.
Таблица 4
Сущность “ sub_characteristic”
Атрибут |
Тип |
Null |
Unique |
Назначение |
id |
int |
Not Null |
да |
Первичный ключ: код подсвойства |
id_characteristic |
varchar |
Not Null |
нет |
Внешний ключ: код свойства |
name_sub_characteristic |
varchar |
Not Null |
нет |
Наименование подсвойства |
description_sub_characteristic |
varchar |
Not Null |
нет |
Описание подсвойства |
Для разграничения прав пользователей в системе имеется сущность с наименованиями привилегий пользователей: администратор, сотрудник. Подробные параметры приведены в таблице 4 ниже.
Таблица 5
Сущность “name_of_role”
Атрибут |
Тип |
Null |
Unique |
Назначение |
id |
int |
Not null |
да |
Первичный ключ: код типа пользователя (роли) |
name_of_role_user |
varchar |
Not null |
нет |
Наименование привилегий |
Cущность “users” хранит данные об авторизированных пользователях в системе. Подробные параметры приведены в таблице 5 ниже.
Таблица 6
Сущность “users”
Атрибут |
Тип |
Null |
Unique |
Назначение |
id |
int |
Not Null |
да |
Первичный ключ: код пользователя |
login |
varchar |
Not Null |
да |
Логин пользователя |
password |
varchar |
Not Null |
нет |
Пароль пользователя, хранимый в виде хэш-значения MD5 |
first_name |
varchar |
Not Null |
нет |
Имя пользователя |
last_name |
varchar |
Not Null |
нет |
Фамилия пользователя |
patronymic |
varchar |
Null |
нет |
Отчество пользователя |
|
varchar |
Not Null |
да |
Электронная почта, необходимая для верификации аккаунта пользователя и восстановления пароля |
mobile_ phone |
varchar |
Null |
нет |
Контактный телефон |
foto |
varchar |
Null |
нет |
Фотография пользователя |
id_role_of_user |
int |
Not Null |
нет |
Категория пользователя |
Важно вести журнал вносимых изменений записей об объектах в системе. Для этого предусмотрена сущность “time_change_object” в которую вносятся такие данные, как идентификационный номер изучаемого объекта, время внесения изменений и пользователь, совершивший изменение Подробные параметры приведены в таблице 6 ниже.
Таблица 7
Сущность “time_change_object”
Атрибут |
Тип |
Null |
Unique |
Назначение |
id |
int |
Not Null |
да |
Первичный ключ |
id_object |
int |
Not Null |
нет |
Внешний ключ: код объекта |
time_change_object |
date |
Not Null |
нет |
время внесения изменения |
id_user_change_object |
int |
Not Null |
нет |
Внешний ключ: код пользователя производивший изменение |
В ходе прохождения исследования и опыта над объектом, свойства и подсвойства приобретают некие значения. Значения могут выражаться как: числовыми параметрами, так и обычным текстом, например: да, нет. Подробные параметры приведены в таблице 8 ниже.
Таблица 8
Сущность “value”
Атрибут |
Тип |
Null |
Unique |
Назначение |
id |
int |
Not Null |
да |
Первичный ключ |
id_object |
int |
Null |
нет |
Внешний ключ: код объекта |
id_characteristic |
int |
Null |
нет |
Внешний ключ: код свойства |
id_sub_characteristic |
int |
Null |
нет |
Внешний ключ: под характеристики к которому относится значение |
value |
varchar |
Null |
нет |
Значение свойств и подсвойств |
Программная реализация проекта базы данных выполнена с помощью операторов языка SQL: USE, CRETE, READ, UPDATE, DROP, INSERT [4].
4. Заключение
В ходе проведённой работы достигнута основная цель: создана база данных реляционного типа. Для дальнейшей реализации web-интерфейса не исключено использование следующих инструментов: HTML, CSS, Bootstrap, JavaScript, JQuery, Yii2, PHP, MySQL [3].
Для установки последующей системы вполне подойдут следующие компоненты:
- MySQL Server
- Операционная система Windows
- Права администратора на компьютере
В качестве сервера для отладки интерфейса и скриптов подойдёт программа OpenServer. Данный выбор обусловлен тем, что в программу уже встроены программные обеспечения такие как: MySQL, PHP, Apache, phpMyAdmin и другие. Так же существенным плюсом Open Server, является его свободное распространение.
Литература:
- Глухов Е. В., Должиков С. В., Ковисарова Е. В., Смелик В. В., Соппа И. В., Фролов А. М., Хузиятов Т. Д. Конспект лекций для подготовки к междисциплинарному экзамену «прикладная информатика (в экономике)". Учебное пособие/; под ред. Б. Л. Резника; Дальневосточный федеральный ун-т, Шк. естественных наук, Шк. экономики и менеджмента. Владивосток, 2012, 312 с.
- Купер А., Рейман Р., Кронин Д. Алан Купер об интерфейсе. Основы проектирования взаимодействия. — Пер. с англ. — СПб.: Символ'Плюс, 2009. — 688 с
- Виктор Гольцман. MySQL 5.0. Библиотека программиста: -Санкт-Петербург, 2010, 370 с.
- П. В. Бураков, В. Ю. Петров Введение в системы баз данных. /Учебное пособие., Санкт-Петербург 2010, 129 с.
- Дейт Дж. Кристофер Введение в системы баз данных. — М.: дом «Вильяме», 2005. — 8-е издание. 1315 с.
- Шакин В. Н. Методические указания по дисциплине «Теоретические основы построения БД» / Шакин В. Н., Сосновиков Г. К., Юскова И. Б. — М.: МТУСИ, Кафедра вычислительной математики и программирования, 2005, 37 с.