CC BY
2УДК 004.652
Н.С. Пономарев, И.А. Рычка
Камчатский государственный технический университет, Петропавловск-Камчатский, 683003 e-mail: [email protected]
БАЗА ДАННЫХ СИСТЕМЫ МОНИТОРИНГА РЫБОЛОВСТВА В СВТУ ФАР
Статья содержит описание существующей базы данных подсистемы обработки промысловых отчетов информационной системы организации регулирования рыболовства (ИСОРР) СВТУ ФАР. Представлены функциональные задачи подсистемы, детально рассмотрены сущности и связи, этапы проектирования базы данных, включая инфологическое, даталогическое и физическое моделирование, а также процесс нормализации данных.
Ключевые слова: база данных, промысловые отчеты, проектирование, модели данных, нормализация.
N.S. Ponomarev, I.A. Rychka
Kamchatka State Technical University,
Petropavlovsk-Kamchatskу, 683003 e-mail: [email protected]
FISHERIES MONITORING SYSTEM DATABASE AT THE NORTHEAST TERRITORIAL ADMINISTRATION OF RUSSIAN FEDERAL FISHERIES AGENCY
The article contains a description of the existing database of the subsystem for processing fishing reports of the information system of the organization of fisheries regulation of the Northeast Territorial Administration of Russian Federal Fisheries Agency. The functional tasks of the subsystem are presented, the entities and connections, the stages of database design, including infological, datalogical and physical modeling, as well as the process of data normalization are examined in detail.
Key words: database, field reports, design, data models, normalization.
Процесс автоматизированной обработки промысловых отчетов с последующим пополнением базы данных сведениями, предоставленными в промысловых отчетах, позволяет производить проверку больших объемов данных с последующим ее хранением в базе данных. Стремление к максимизации положительного воздействия поднимает фундаментальный вопрос: как оптимально организовать процесс автоматизации обработки данных?
Центральным элементом любой информационной системы является ее база данных. Эффективная организация данных играет решающую роль в обеспечении успешного функционирования подсистемы обработки промысловых отчетов (далее по тексту будем называть систему по названию основного программного модуля - InReports). Процесс анализа предметной области и составление модели данных в целях создания наиболее эффективной базы данных, известен как проектирование, которое включает в себя такие ключевые этапы, как инфологическое моделирование, которое предполагает частично формализованное описание объектов предметной области с использованием определенной смысловой модели, даталогическое моделирование, которое описывает структуру данных в рамках выбранной модели данных и отображает логические взаимосвязи между элементами данных, независимо от их содержания и физической организации, физическое проектирование базы данных, которое включает выбор наиболее эффективного расположения элементов базы данных на внешних носителях.
Этапы проектирования базы данных представляют собой комплексный процесс, который требует тщательного анализа, понимания предметной области и правильного выбора методов моделирования для обеспечения оптимальной функциональности и эффективности информационной системы.
Постановка задачи. InReports является подсистемой информационной системы организации регулирования рыболовства (ИСОРР) и создана для того, чтобы на базе единого информационного ресурса СВТУ ФАР автоматизировать обработку и обеспечить высокий контроль качества промысловых отчетов, представляемых в СВТУ ФАР рыбопромысловыми предприятиями [1].
Следовательно, база данных ИСОРР (рабочее название базы данных, применяемое далее по тексту - SalmonDB) не представляет собой отдельную единицу, а является комплексом таблиц, интегрированных в базу данных ИСОРР и тесно взаимодействующих с другими ее таблицами [2].
SalmonDB - это массивы данных, характеризующие промысловую деятельность рыбопромысловых предприятий Камчатского края, формируемые и хранимые на серверах СВТУ ФАР.
Информация SalmonDB представлена массивами данных (в электронном виде) нескольких видов:
- справочник видов промысла;
- справочник объектов промысла;
- справочник рыбопромысловых участков (РПУ);
- справочник рыбопромышленных предприятий;
- разрешения на промысел;
- промысловые отчеты.
Состав функциональных задач InReports определяется содержанием конкретных функций управления и информационными потребностями специалистами отдела организации рыболовства СВТУ ФАР. К числу этих функций и потребностей относятся:
- автоматизированная обработка промысловых отчетов;
- протоколирование ошибок из поступающих промысловых отчетов;
- формирование выходных форм документов из базы данных:
а) документы о промысле лососевых рыб,
б) нормативно-правовые документы по вылову лососевых;
- просмотр результатов промысловых отчетов с возможностью комбинированного поиска по различным параметрам, таким как дата отчета, рыбодобывающее предприятие, объект промысла, объем вылова рыбодобывающим предприятием за отчетный период, а также возможностью проведения поиска по каждому из этих параметров в отдельности;
- внесение новых объектов в справочники (в случае их отсутствия) в SalmonDB.
Анализ вышеприведенных функций позволяет выделить ключевые сущности в информационной системе организации регулирования рыболовства, необходимые для обеспечения ее эффективного и корректного функционирования.
Описание сущностей. Для описания объектов предметной области используются сущности как некоторые абстракции реальных объектов и процессов, информацию о которых требуется хранить в базе данных.
Сущности SalmonDB подразделяются на уже существующие в ИСОРР сущности и новые, необходимые для решения задачи обработки промысловых отчетов:
1. Сущность «промысловые участки» обозначает место промысла (участок моря или реки) и имеет следующие атрибуты:
- id_rpu - идентификационный код РПУ;
- rpu - название РПУ;
- size - площадь РПУ;
- boundaries - границы РПУ;
- id_fishing - код вида рыболовства;
- gear - орудия лова;
- id_own - идентификационный код предприятия, ведущего промысел.
2. Сущность «виды рыболовства» обозначает виды рыболовства, действующие на данном РПУ:
- id_fishing - код идентификатора вида рыболовства;
- fishing - краткое описание вида рыболовства;
3. Сущность «объект промысла» обозначает виды промысловых рыб:
- id_fish - код идентификатора промыслового вида биоресурса;
- fish - название объекта промысла.
4. Сущность «предприятие» обозначает данные о предприятии, ведущем промысел:
- id_own - идентификационный код предприятия, ведущего промысел;
- own - наименование предприятия;
5. Сущность «разрешения на промысел» обозначает сведения о разрешениях, выданных предприятию на промысел:
- Np - номер разрешения на промысел;
- id_ rpu - код промыслового участка;
- id_fish - код объекта промысла;
- quota - объем квот, выданных предприятию;
- gear - орудие лова;
- d - срок действия разрешения.
6. Сущность «улов» обозначает входящие данные с промысловых отчетов:
- Np - номер разрешения на вылов биоресурсов;
- d - отчетная дата подачи промыслового отчета;
- id_fish - код объекта промысла;
- bycatch - является ли добытый биоресурс приловом или нет;
- day_volume - дневной вылов рыбодобывающего предприятия на отчетную дату;
- sum_volume - суммарный вылов рыбодобывающего предприятия на отчетную дату по данному разрешению;
Даталогическая модель. Даталогическая модель представляет собой формализованное описание структуры данных для мониторинга рыболовства СВТУ ФАР. Она базируется на ин-фологической модели, но уже включает в себя конкретные таблицы, столбцы и связи между ними. В процессе построения даталогической модели учитывались требования предметной области, а также оптимальность и эффективность хранения и обработки данных.
Итак, даталогическая модель - это модель логического уровня, которая представляет собой отображение логической связи между элементами, независимо от их содержания и среды хранения. Для построения даталогической модели были использованы следующие принципы:
1. Таблица состоит из двух столбцов:
- Ключевое поле,
- Название поля и тип поля.
2. Для обозначения первичного ключа используется аббревиатура PK.
3. Для обозначения внешнего ключа используется аббревиатура FK.
4. У каждой таблицы есть название, записанное над таблицей.
5. Строке с названием поля соответствует столбец с типом данных.
6. Для обозначения связи один-ко-многим и многий-ко-многим используется обозначение 1-N и N-N.
7. Связь между таблицами указана по полям, участвующим в этой связи.
На основе инфологической модели была построена даталогическая модель базы данных (рисунок), которая позволят реализовать основные функции информационной системы InReports:
Практически в каждую таблицу были включены поля id_user и timestamp для контроля корректировок данных таблиц:
- id user - идентификационный код и внешний ключ, по которому можно определить пользователя, изменившего данные;
- timestamp - дата и время внесения изменений.
Физическая модель. Для описания наименования таблиц, столбцов, типов данных, определения первичных, внешних ключей для системы была использована физическая модель таблиц SalmonDB (табл. 1).
Таблица 1
Физическая модель таблиц SalmonDB
Наименование таблицы Наименование поля Назначение поля Ключ Тип данных
rpu id rpu идентификационный код РПУ MEDIUMINT (6)
rpu название РПУ VARCHAR (255)
size площадь РПУ VARCHAR (255)
boundaries границы РПУ text
id fishing код вида рыболовства SMALLINT (2)
gear орудия лова VARCHAR (255)
-"- id_own идентификационный код предприятия, ведущего промысел SMALLINT (5)
fishing id fishing код идентификатора вида рыболовства SMALLINT (3)
fishing краткое описание вида рыболовства VARCHAR (255)
fish id_fish код идентификатора промыслового вида биоресурса SMALLINT (3)
fish название объекта промысла CHAR (50)
own id_own идентификационный код предприятия, ведущего промысел SMALLINT (5)
own наименование предприятия VARCHAR (255)
permit NP номер разрешения на промысел BIGINT (4)
id rpu код промыслового участка SMALLINT (3)
id fish код объекта промысла SMALLINT (3)
quota объем квот, выданных предприятию DOUBLE (12,5)
gear орудие лова TEXT
d срок действия разрешения TEXT
catch Np номер разрешения на вылов биоресурсов BIGINT (12)
d отчетная дата подачи промыслового отчета DATE
id fish код объекта промысла SMALLINT (3)
-"- bycatch является ли добытый биоресурс приловом или нет ENUM (‘да’,’’)
-"- day_volume дневной вылов рыбодобывающего предприятия на отчетную дату DOUBLE (20,10)
-"- sum_volume суммарный вылов рыбодобывающего предприятия на отчетную дату DOUBLE (20,10)
Нормализация. SalmonDB является реляционной базой данных. Процесс нормализации реляционной БД обеспечивает устранение нежелательных свойств, и для этого, как правило, достаточно удовлетворения трем нормальным формам из семи. Нормальная форма (НФ) определяется как совокупность требований, которым должно удовлетворять таблица БД, что устраняет избыточные функциональные зависимости между полями таблиц. Третья форма включает в себя вторую, вторая в свою очередь включает в себя первую. Изложим их суть:
По требованию 1 НФ (первая нормальная форма) в каждом поле таблицы должно храниться атомарное значение (одно несоставное значение).
По требованию 2 НФ таблица должна иметь первичный ключ.
По требованию 3 НФ все неключевые поля таблицы должны зависеть от полного ключа (в случае если он составной), т. е. все неключевые поля зависят только от первичного ключа, а не от других неключевых полей.
Приведением таблицы к 3 НФ избавляемся от транзитивности, при которой неключевые поля зависят от значений других неключевых полей.
Следовательно, необходимо проверить SalmonDB на соответствие всем трем нормальным формам. Действительно все таблицы:
1) имеют атомарные поля;
2) имеют первичный ключ, а именно:
• таблица "fish " - id_fish,
• таблица " fishing" - id_fishing,
• таблица "own " - id_own,
• таблица "rpu" - id_rpu,
• таблица "permit" - Np, id_rpu, id_fish,
• таблица "catch" - Np, d, id_fish, bycatch;
3) в случаях если ключ составной, неключевые поля таблиц зависят от полного ключа, а именно (табл. 2):
Таблица 2
Обоснование соответствия таблиц БД третьей нормальной форме (3НФ)
Таблица БД Обоснование соответствия третьей нормальной форме (3НФ)
permit Каждое неключевое поле в данной таблице должно относиться только к разрешению на промысел. Объем квот, орудие лова, срок действия разрешения относятся непосредственно к самому разрешению и не зависят друг от друга, следовательно, все неключевые поля зависят только от первичного ключа (Np, id rpu, id fish), а не от других неключевых полей.
catch Каждое неключевое поле в данной таблице должно относиться только к отчету за конкретную дату. Суточный и накопительный вылов относятся только к отчету и могут зависеть друг от друга, но это требование игнорируется, т. к. не всегда сумма суточных уловов равна накопительному улову. Следовательно, все неключевые поля зависят только от первичного ключа (Np, d, id fish, bycatch), а не от других неключевых полей.
Анализ каждой таблицы базы данных системы SalmonDB подтвердил, что они соответствуют всем требованиям трех нормальных форм, являющихся основополагающими принципами в теории реляционных баз данных, что подтверждает высокий уровень структурированности, эффективности и оптимальности организации данных и является важным аспектом в обеспечении надежности и производительности базы данных.
Анализ функций и сущностей ИСОРР и комплексный подход к проектированию SalmonDB дали возможность разработать базу данных и эффективно организовать процессы обработки и хранения данных, обрабатываемых с промысловых отчетов, подаваемых рыбопромысловыми предприятиями, а также ведения протоколов обработки отчетов с отсечением отчетов, содержащих ошибки. Применение даталогического и физического моделирования позволило создать базу данных, которая оптимизирует процессы хранения и обработки данных, а также обеспечивает высокую производительность и надежность.
Литература
1. О порядке и механизме представления оперативной и статистической отчетности по добыче рыбы и переработке рыбопродукции: Приказ Госкомрыболовства Российской Федерации от 10 октября 1996 года № 185.
2. Мониторинг рыболовства, 2005: Инструкции и рекомендации экипажам промысловых судов и судовладельцам» / Л.А. Кошкарева, Ф.А. Образцов, И.Г. Проценко, В.Ю. Резников, К.В. Статиен-ко, МА. Ступникова; под общ. ред. д.т.н. И.Г. Проценко. - Петропавловск-Камчатский: ФГУП «Камчатский центр связи и мониторинга», 2005.
