CC BY
85
4. Науменко О. П. Уголовная ответственность за незаконные организацию и проведение азартных игр по законодательству стран СНГ / О. П. Науменко // Бизнес в законе, 2014. № 4. С. 34-37.
5. Севостьянов Р. А. Проблемы уголовной ответственности за организацию и ведение незаконного игорного бизнеса: автореф. дисс... канд. юр. наук. Саратов 2009. - 24 с.
6. Семенов Н. В., Замараева Н. А. Проблемы применения специальных знаний при расследовании преступлений, связанных с незаконной игорной деятельностью (статья 171.2. УК РФ «незаконные организация и проведение азартных игр») / Н. В. Семенов, Н. А. Замараева // Теория и практика судебной экспертизы. - 2012.- № 3 (27). С. 94-97.
7. Уголовный кодекс Российской Федерации от 13 июня 1996 г. № 63-Ф3 (ред. от 30.03.2015, с изм. от 07.04.2015) // СПС «КонсультантПлюс», 2015.
8. Федеральный закон от 20.07.2011 № 250-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации» // СПС «КонсультантПлюс», 2015.
9. Федеральный закон от 29.12.2006 № 244-ФЗ (ред. от 22.07.2014) «О государственном регулировании деятельности по организации и проведению азартных игр и о внесении изменений в некоторые законодательные акты Российской Федерации» (с изм. и доп., вступ. в силу с 22.08.2014) // СПС «КонсультантПлюс», 2015.
Системный анализ предметной области и построение концептуальной модели базы данных «научная деятельность студентов вуза» Абрамченко Н. В.
Абрамченко Нина Владимировна /Abramchenko Nina Vladimirovna - кандидат педагогических наук, доцент, кафедра высшей математики и информатики, Финансовый университет при Правительстве Российской Федерации (Омский филиал), кафедра информационной безопасности, Сибирская государственная автомобильно-дорожная академия (СибАДИ), г. Омск
Аннотация: проблема проектирования баз данных как ядра информационных систем, адекватных своей предметной области, зачастую возникает из-за недостаточного понимания между заказчиком и разработчиком. Решением проблемы служит создание концептуальной модели базы данных на основе системного анализа предметной области.
Ключевые слова: информационные системы, проектирование баз данных, концептуальная модель, системный анализ.
Создание базы данных предполагает интеграцию данных, предназначенных для решения набора конкретных прикладных задач отдельных пользователей (групп пользователей) - сотрудников организации, для которых создается база данных. Соответственно, каждый пользователь может иметь собственные представления о данных и связях между ними, что выражается в его концептуальных требованиях к базе данных. Требования каждого пользователя должны быть учтены и обобщены в единое представление, которое далее будет служить основой для построения единой базы данных (рис. 1).
Объединяя частные представления о содержимом базы данных, полученные в результате опроса пользователей, и свои представления о данных, которые могут потребоваться в будущих приложениях, разработчик сначала создает обобщенное неформальное описание создаваемой базы данных [1].
Это описание, выполненное с использованием естественного языка, математических формул, таблиц, графиков и других средств, понятных всем людям, работающих над проектированием базы данных, называют концептуальной моделью базы данных (или схемой).
Рис. 1. Обобщение представлений пользователей о данных 39
Она представляет собой информационное описание предметной области с учетом логических взаимосвязей, поэтому её еще называют инфологической (информационно-логической) моделью. В этой человеко-ориентированной модели отсутствуют какие-либо понятия, связанные с ЭВМ, она полностью независима от физических параметров среды хранения данных. Этой средой может быть память человека, а не ЭВМ. Поэтому концептуальная (инфологическая) модель не должна изменяться до тех пор, пока какие-то изменения в реальном мире не потребуют изменения в ней некоторого определения; чтобы эта модель продолжала отражать предметную область. Т. е., по сути, это модель только предметной области.
Основные компоненты концептуальной модели базы данных это:
• описание предметной области,
• формулировка информационных задач,
• описание ограничений целостности,
• описание объектов предметной области с их атрибутами и связями [2].
Рассмотрим процесс построения концептуальной модели базы данных на основе анализа предметной области «Научная деятельность студентов вуза».
1. Описание предметной области
Предметная область содержит сведения, отражающие учет научных статей студентов-исследователей в вузе. Каждая статья характеризуется следующими параметрами: идентификатор статьи; название; ФИО автора(ов); ФИО научного руководителя (преподавателя); издание (название журнала или сборника); год издания.
В системе ведется карточка студента-исследователя. На каждого студента-исследователя (имеющего хотя бы одну работу) в карточку заносятся следующие сведения: номер зачетной книжки; ФИО; год поступления; факультет; телефон; e-mail.
На каждого научного руководителя (преподавателя) в карточку заносятся следующие сведения: номер преподавателя; ФИО; кафедра; ученая степень; ученое звание; телефон; e-mail.
Каждый студент-исследователь может иметь несколько статей, и у каждой статьи может быть несколько авторов.
Каждая работа может быть проведена под руководством одного научного руководителя или без руководителя, а преподаватель, естественно, может выступать руководителем сколь угодного числа работ студентов в ходе деятельности, в том числе ни одной.
2. Информационные задачи
Задача 1. Вывести список статей, сгруппированных по сотрудникам заданной кафедры и типам издания.
Задача 2. Вывести количество статей по каждой кафедре за последние пять лет, разграниченное по годам.
Задача 3. Вывести список студентов-исследователей с указанием их рейтинга, определяющимся количеством работ за заданный период.
3. Описание ограничений целостности
На основании анализа предметной области и сформулированных задач выделим следующие объекты:
- «Студент-исследователь»;
- «Научный руководитель (преподаватель)»;
- «Научная статья».
Сформулируем ограничения целостности.
• Значение атрибута «Номер зачетной книжки» объекта «Студент-исследователь» должно быть уникально.
• Значение свойства «ID статьи» (идентификатор статьи) объекта «Ученая статья» должно быть уникально.
• Значение свойства «ID преподавателя» (идентификатор преподавателя) объекта «Научный руководитель-преподаватель» должно быть уникально.
• Значение свойства «Кафедра» объекта «Научный руководитель-преподаватель» может быть одним из следующих: «Высшая математика и информатика», «Бухучет, анализ и статистика», «Общественные науки», «Финансы и кредит», «Экономика и менеджмент», с возможностью добавления нового.
• Значение свойства «Факультет» объекта «Студент-исследователь» может содержать значения: «Управление и бизнес-технологии», «Экономика».
• Значение свойства «Научная степень» объекта «Научный руководитель-преподаватель» может содержать значения: «Кандидат наук», «Доктор наук», пустое значение.
• Значение свойства «Ученое звание» объекта «Научный руководитель-преподаватель» может содержать значения: «Доцент», «Профессор», пустое значение.
• Каждый экземпляр объекта «Научная статья» обязательно связан с хотя бы одним экземпляром объекта «Студент-исследователь», и наоборот, каждый экземпляр объекта «Студент-исследователь» обязательно связан с хотя бы одним экземпляром объекта «Научная статья».
• Каждый экземпляр объекта «Научная статья» может быть связан с не более чем одним экземпляром объекта «Научный руководитель-преподаватель».
• Каждый экземпляр объекта «Научный руководитель-_преподаватель» может быть связан с более чем одним экземпляром объекта «Научная статья» или ни с одним.
4. Описание объектов предметной области с их свойствами и связями
Изобразим объекты с их свойствами и связями между собой в виде диаграмм «сущность-связь» (ЕЯ-диаграмм) (рис. 2).
Рис. 2. ER-диаграмма объектов, их свойств и связей
Таким образом, мы описали ядро концептуальной или инфологической модели базы данных. Эта модель служит основой для следующего этапа проектирования базы данных - создания даталогической модели в рамках выбранной СУБД. Так как до настоящего времени сохраняется доминирование реляционных СУБД, покажем на данном примере процедуру перехода к реляционным отношениям.
Количество и состав реляционных отношений (таблиц) зависит от числа объектов, наличия у них сложных свойств в совокупности с необходимостью их обработки в будущих запросах, характера связи между объектами и обязательностью этой связи для каждого экземпляра соответствующего объекта.
Сложных свойств в рассматриваемой модели не выявлено. Между объектами «Научный руководитель-преподаватель» и «Научная статья» определена связь вида «один-ко-многим», характеризующаяся при этом отсутствием признака «класс принадлежности сущности» с обеих сторон. На этом основании рекомендуется построить три реляционных отношения следующего состава (подчеркиванием обозначается первичный ключ):
1. Научный руководитель-преподаватель (ID преподавателя, ФИО преподавателя, кафедра, ученая степень, ученое звание, телефон, e-mail).
2. Научная статья (ID статьи, название, издание, год издания).
3. Статья - Руководитель (ID статьи, ID руководителя).
Между объектами «Студент-исследователь» и «Научная статья» определена связь вида «многие-ко-многим» (характеризующаяся при этом признаком «класс принадлежности сущности» с обеих сторон). На этом основании рекомендуется достроить еще два реляционных отношения следующего состава:
4. Студент-исследователь (номер зачетной книжки, ФИО студента, курс, факультет, телефон, email).
5. Статья - Студент (ID статьи, номер зачетной книжки).
Таким образом, разработанная на этапе концептуального проектирования на основе системного анализа предметной области информационно-логическая модель базы данных служит источником корректного даталогического проектирования, создания схемы базы данных, адекватной своей предметной области, что обусловливает значимость первого этапа проектирования баз данных.
Литература
1. Абрамченко Н. В. Основы проектирования баз данных: Учебное пособие / Н. В. Абрамченко. Омск: Полиграфический центр КАН, 2015. 56 с.
2. Диго С. М. Базы данных: проектирование и использование: Учебник / С. М. Диго - М.: Финансы и статистика, 2005. 592 с.: ил.
Об использовании генетических алгоритмов при построении механических
торговых систем Копылов А. Н.
Копылов Алексей Николаевич /Kopylov Alexey Nikolaevich — старший преподаватель, кандидат технических наук,
доцент,
кафедра математики и моделирования систем, Воронежский институт МВД России, г. Воронеж
Аннотация: рассмотрен один из подходов к построению механических торговых систем. Ключевые слова: механическая торговая система, генетический алгоритм, популяция, хромосома, шаблоны правил.
Построению механических торговых систем (МТС) посвящено достаточно большое количество публикаций. Как правило, множество потенциальных стратегий, среди которых ведется поиск наилучшей (в соответствии с заранее выбранной целевой функцией), обычно достигает значительных размеров. При этом, несмотря на бурное развитие вычислительной техники за последние десятилетие, перебор всех допустимых вариантов лишь в редких случаях является возможным. Для решения этой проблемы предлагаются различные способы. В частности, в работах [1, 2] предлагается использовать генетические алгоритмы для поиска подходящих моделей. В работе [2], например, для поиска сигналов входа в рынок создается популяция особей, хромосомы которых содержат по три гена. Каждый ген, входящий в состав хромосом, соответствует блоку из четырех чисел и шаблону правила. Таким образом, каждая хромосома состоит из двенадцати чисел (параметров модели), которые вместе с шаблонами правил и определяют реакцию МТС. Модель для генерирования сигналов выхода из рынка строится по аналогичному принципу. При этом в работе [2] оптимизация МТС на исторических данных при построении входных и выходных моделей проводится раздельно. В работе [1], напротив, каждая из хромосом популяции содержит одновременно как гены, отвечающие за вход в рынок, так и гены, отвечающие за выход из рынка.
После этапа оптимизации (подбора параметров МТС) на исторических данных проводится тестирование системы на «свежих» (не вошедших в оптимизационную выборку) данных. Такой вид тестирования также называют форвардным или слепым тестированием. Он подробно описан в работах [2-6]. При этом в работе [5] предлагается использовать модель только в том случае, если она прошла как минимум десять форвардных тестов (со сдвигом по времени на величину тестового окна) и при этом модель прибыльна в целом, имеет форвардный показатель эффективности 50% и более, причем не менее 50% ее форвардных тестов были прибыльными. Однако в приведенных выше работах [1, 2], полученные модели тестировались только на одном интервале данных. При этом в работе [2] тестирование проводилось на разных рынках, а в работе [1] только на одной валютной паре EUR/USD и только для пятиминутных данных. Таким образом, с точки зрения [5] для увеличиения вероятности удовлетворительной работы построенной МТС и надежности генерируемых сигналов входа и выхода из рынка на постоптимизационных данных необходимо провести больше форвардных тестов. Однако для приведенных работ [1, 2] это означало бы формирование на каждом этапе новой популяции с последующим выбором в процессе эволюции только одной хромосомы и дальнейшим ее тестированием. При этом очевидно, что лучшие хромосомы на разных исторических данных могут включать разные шаблоны правил, что может затруднить анализ динамики структуры МТС. Кроме того, лучшие хромосомы, полученные в результате оптимизации на идентичных наборах данных, также могут отличаться вследствие невозможности перебора всех допустимых значений и большого числа локальных экстремумов. Поэтому можно поступить следующим образом — после процесса оптимизации на самых «свежих» исторических данных в случае получения удовлетворительных результатов зафиксировать шаблоны правил, соответствующих каждому из генов в хромосоме с наибольшей функцией приспособленности, а затем проводить оптимизацию на более ранних исторических данных с последующим форвардным тестированием, но уже для хромосом с жестко заданными набором шаблонов правил для
