Размер: px

Начинать показ со страницы:

Транскрипт

1 Статья сдана в сборник "Новое в управлении и автоматике", М.:Наука, гг. ВИРТУАЛЬНЫЙ ФУТБОЛ: АЛГОРИТМЫ И МОДЕЛИРОВАНИЕ ИГРЫ РОБОТОВ-ФУТБОЛИСТОВ Д.Е.Охоцимский *, В.Е. Павловский *, А.Г.Плахов **, А.Н.Туганов **, В.В.Павловский ** * Институт прикладной математики им.м.в.келдыша РАН, Москва, Миусская пл., 4 ** МГУ им. М.В.Ломоносова, механико-математический факультет, Москва, Воробьевы горы, МГУ Аннотация. Представлена система моделирования игры роботов-футболистов и базовые алгоритмы управления игроками в игре. Дан краткий обзор современных соревнований роботовфутболистов. Описаны общая схема игры, используемые модели игры, принципы управления движением роботов-игроков, структура системы моделирования, предложены эвристические методы управления коллективом роботов для достижения цели игры. Выполненные исследования являются первым шагом в решении задачи создания интеллектуальных алгоритмов группового управления роботами-футболистами. Работа выполнена при финансовой поддержке грантов РФФИ, Введение. Работа выполнена в рамках проекта по исследованию методов управления группой роботов в интеллектуальной игре. Цель представленного этапа заключается в разработке базовых алгоритмов управления виртуальными роботами-футболистами, а также - инструментальных средств, поддерживающих создание управляющих алгоритмов для роботов-футболистов, средств для организации соревнований по футболу роботов в рамках компьютерного моделирования. В статье описаны полученные в этих исследованиях результаты. В настоящее время известны различные системы по организации соревнований роботов-футболистов, в том числе и на основе компьютерного моделирования, как например , настоящая работа вводит аналогичную схему для роботов, участие которых в соревнованиях предполагается в рамках Фестивалей Мобильные роботы, проводимых в МГУ . Предлагаемая в статье система аналогична упомянутой системе типа , но является самостоятельным проектом, ориентированным в большей мере на моделирование футбола роботов . 2. Схемы соревнований по футболу роботов. В настоящее время предложен ряд различных схем организации соревнований роботов-футболистов, например схемы соревнований Ассоциации RoboCup, или схемы, принятые в Международной Федерации FIRA . В RoboCup заявлен следующий манифест: "... Через 50 лет, в 2050 году, команда роботов-футболистов должна выиграть у Чемпиона мира по футболу (команды людей-футболистов)... " , и для достижения этой цели соревнования проводятся в нескольких Лигах: Лиге Моделирования, Лиге малого класса (малых роботов), Лиге среднего класса (средних роботов), Лиге 4-ногих 1

2 роботов SONY (AIBO), Лиге гуманоидных роботов (она впервые в демо-режиме введена с 2001 года) и двух дополнительных (ассоциированных) Лигах - Лиге моделирования роботов-спасателей и Лиге реальных роботов-спасателей. Кроме того в RoboCup существуют юниорские лиги. Соревнования проводятся в виде Чемпионатов мира для роботов, открытых Чемпионатов или кубков отдельных стран, а также - в виде открытых турниров на крупнейших Международных соревнованиях. Так например, соревнования в 2000 г. были проведены в рамках Австралийской Олимпиады и проходили в Мельбурне. В качестве примеров роботов-участников таких соревнований ниже на рис.1,2 показаны роботы Лиги малого класса и фрагмент игры роботов Лиги среднего класса , определенных правилами RoboCup. Рис.1. Прототипы роботов-футболистов Малой Лиги RoboCup. Рис.2. Фрагмент игры роботов Средней Лиги RoboCup на Чемпионате 2001 года. На рис.2 приведен эпизод финального матча команды CS Freiburg Университета Albert-Ludwigs, Фрейбург, Германия (показана игра у ворот этой команды), против команды Trackies Университета Osaka, Осака, Япония, во время Чемпионата мира 2001 г., проходившего в рамках 1-ой Международной конференции по роботизированному футболу в Сиэтле, США, 4-10 августа 2001 г. (команда CS Freiburg этот турнир выиграла и стала Чемпионом мира 2001 г.). Весьма интересный Чемпионат мира был проведен RoboCup в 2002 году параллельно с мировым футбольным чемпионатом, проходившим в Японии и Корее. Чемпионат RoboCup прошел в японском городе Фукуока. О постоянно возрастающей активности ассоциации RoboCup и разработчиков роботов-футболистов говорят следующие цифры всего на Чемпионате в Фукуоке присутствовали 188 команд из 29 стран, в них суммарно 2

3 входило более 1000 участников разработчиков роботов разных Лиг. Соревнования в Фукуоке за 5 игровых дней посетили более зрителей. На всех очередных соревнованиях RoboCup совершенствует правила игры роботов и вводит новые виды соревнований. Так, Чемпионат 2002 года примечателен тем, что на нем впервые на официальные соревнования вышли роботы-гуманоиды (двуногие роботы), соревновавшиеся в нескольких номинациях. Ниже на нескольких фотографиях приведены фрагменты соревнований роботов-футболистов в Фукуоке. Эти фотографии взяты с официальных Интернет-сайтов RoboCup и Чемпионата в Фукуоке . На рис. 3 5 приведены фрагменты соревнований гуманоидных роботов. На первых фотографиях показаны роботы, соревнующиеся в упражнении "пенальти". Рис.3. Новые роботы Asimo фирмы Honda демонстрируют упражнение "пенальти". Рис.4. Пенальти выполняет робот Tao-Pie-Pie (Новая Зеландия), в воротах стоит робот ARICC-HURO (Сингапур). Победитель соревнований роботов-гуманоидов определялся по общей совокупности номинаций-упражнений (всего их было задано три). И в итоге победителем среди гуманоидных роботов стал японский робот Nagara (разработчики Ассоциация промышленности префектуры Гифу, Япония), показанный на рис.5. 3

4 Рис. 5. Робот Nagara победитель 2002 года среди роботов гуманоидов. Ниже приведены фотографии, демонстрирующие фрагменты соревнований в других Лигах RoboCup. На рис.6 фрагмент соревнований роботов Лиги малого класса RoboCup. Рис.6. Соревнования в Лиге малых роботов RoboCup. Важно здесь отметить, что, как показывает рис.6, роботы малой Лиги играют командами не более 5х5 игроков на небольшом поле, имеющем борта вокруг поля, мяч может отражаться от этих бортов. Система Лиги малых роботов предполагает, что над полем может находиться телекамера (или несколько телекамер), доставляющая для каждой из команд зрительную информацию об игровой ситуации основному управляющему компьютеру. Этот компьютер (такой компьютер может иметь каждая команда) расположен рядом с игровым полем и может связываться с игроками по радиолинии. В отличие от Малой Лиги роботы, соревнующиеся в Лиге Среднего класса, являются полностью автономными и должны быть оснащены развитой бортовой системой управления и весьма развитой сенсорной системой, центром которой является подсистема зрения робота. Фрагмент этих соревнований в 2002 году приведен на рис.7. 4

5 Рис.7. Матч команд Средней Лиги. Укажем нововведение в соревнованиях роботов Средней Лиги сравнивая эпизоды 2001 г. (рис.2) и фрагмент, приведенный выше (рис.7), можно заметить, что ранее в этих соревнованиях на игровом поле также были борта, а с 2002 года они убраны, что означает, что роботы должны строже обращаться с мячом во время игры. Наконец, на рис.8 показан фрагмент соревнований в Лиге 4-ногих роботов Sony. Рис.8. Игра команд Лиги 4-ногих роботов Sony (роботы AIBO). Анализ указанных схем соревнований роботов-футболистов показывает, что, несмотря на различие конструкций таких роботов и технических решений, принятых при их построении, в схемах соревнований роботов много общего в верхних, стратегических, уровнях управления игроками, что позволяет поставить задачу их отработки с помощью единых средств моделирования. Такая система моделирования предлагается и описывается в настоящей работе. Ее цель создание и отработка в режиме моделирования таких алгоритмов управления роботами-футболистами, которые в дальнейшем могут быть перенесены и на реальные роботы. При этом рассматриваются групповые (командные) алгоритмы стратегического и тактического уровней управления командой роботов. 5

6 3. Схема игры и модель игры. За прототип игры примем игру роботов Лиги малого класса RoboCup. Во многом порядок и правила этой Лиги соответствуют правилам, принятым и в другой международной ассоциации FIRA. Пусть игра проходит на прямоугольном поле с бордюрами (ограничивающими поле стенками) между двумя командами колесных роботов-футболистов. Размеры поля и ворот, роботов-участников и мяча заданы как параметры, они вводятся в конфигурационных файлах системы и могут быть при необходимости изменены. Также параметрами являются механические параметры игроков, мяча и игровой среды, задающие механическую модель игры . В каждой команде n участников (n=1,2,3,...), при этом наиболее часто используемый случай - игра команд 5х5 участников, хотя рассматривались и другие варианты, вплоть до 11х11, или больше. Роботы имеют круглую цилиндрическую форму (т.е. форму диска в виде сверху), и в первой версии игры не имеют каких-либо средств контроля над мячом, кроме удара по нему корпусом. Мяч тоже имеет круглую форму. Параметрами управления роботов являются линейное ускорение (торможение) d, оно направлено по продольной оси робота, и угловая скорость робота w. На первом этапе исследований предполагается, что роботы имеют автономную систему управления, но "видят" всё поле (игра с полной информацией). Коммуникация (обмен сообщениями) роботов одной команды между собой возможна, но используется, или не используется, по усмотрению их бортовой системы управления. Правила игры в достаточной мере упрощены и содержат только условия возобновления игры с центра поля после гола, и некоторый аналог правил вбрасывания мяча в спорных ситуациях, к которым относятся тупиковые состояния, в которые может попадать игра. Примером такого тупика является ситуация, когда игроки вводят мяч в один из углов поля и игра "зацикливается" в таком состоянии. При обнаружении подобных ситуаций игра прерывается и возобновляется вбрасыванием мяча в области центра поля. Имеются также правила, задающие начальные расстановки игроков при вбрасывании мяча. После вбрасывания игроки обеих команд получают право начать движение к мячу одновременно. Любые игровые действия игроков считаются допустимыми, никаких правил насчет положения "вне игры", штрафных, угловых, пенальти нет. Игрокам разрешается блокировать или даже толкать друг друга в борьбе за мяч. Здесь необходимо следующее замечание. В текущей версии системы ограничения на действия игроков минимальны, это сделано для того, чтобы обеспечить разработку возможно более широкого класса алгоритмов, однако, в дальнейшем с развитием проекта такие ограничения могут вводиться. Игра может продолжаться заданное время, моделируя матч команд, либо выполняется в отладочном режиме - продолжается неограниченное время, и в этом режиме может быть остановлена вручную. 4. Система моделирования. Система моделирования игры построена следующим образом. Реализованы несколько версий программ моделирования для разных операционных систем, в том числе - для системы WINDOWS, и каждая программа моделирования реализует идентичные механические модели и использует алгоритмы управления игроками, которые подключаются как модули и могут изменяться. Версии программ моделирования совместимы по конфигурационным файлам и схеме подключения модулей с алгоритмами управления игроками. Цель такого моделирования - оптимизация параметров алгоритмов, их сравнение и выбор наиболее эффективных алгоритмов. При этом алгоритмы управления противоборствующими командами могут быть как одинаковыми 6

7 (однотипными), так и различными. На этой основе организуются соревнования алгоритмов управления роботами-футболистами. В целом структура каждой из версий программы моделирования организована следующим образом (рис.9). Программа состоит из трех частей - серверной программы и двух модулей Team1, Team2, описывающих команды игроков, и разрабатываемых и представляемых отдельно. Рис.9. Структура системы моделирования: серверная программа и модули команд-игроков. Серверная программа является ядром системы моделирования и объединяет все модули в единый комплекс. Модули используют разные схемы объединения с серверной программой, в WINDOWS используется протокол DLL. В ходе игры процесс игры моделируется по тактам "времени". Они могут быть соотнесены с реальными тактами реального времени, тогда игра будет развиваться в реальном (астрономическом) времени, либо эти такты могут быть минимизированы, тогда игра будет исполняться в максимально ускоренном режиме, при этом темп игры будет определяться быстродействием моделирующего компьютера. В каждом такте программа моделирования выполняет вызовы модулей - сначала Team1, а затем Team2. Вызов каждого модуля выполняется столько раз, сколько определено игроков в команде, по одному вызову для каждого игрока. Программа модуля команды должна возвратить серверной программе "управления" для каждого очередного игрока. Рассчитывая их программа игрока может обращаться к специальным функциям серверной программы для опроса текущей ситуации на поле - положений и скоростей всех игроков и мяча. Тем самым моделируется визуальный ввод информации об игре в системы управления игроков. Получив все данные управления, серверная программа на основе механических моделей (см., например, ) моделирует перемещения всех объектов игры за текущий такт системного времени. Моделируется динамика движения объектов и все их соударения. Фиксируется состояние "гола" и всех текущих ситуаций игры. При необходимости серверная программа может перевести игру в одну из начальных ситуаций - стартовую (после гола) или в ситуацию выхода из тупиков. Фактически текущая версия программы моделирования моделирует игру с полной информацией, когда имеется host - камера, расположенная над полем, и наблюдающая все поле целиком (или две такие камеры, по одной для каждой команды, но с общей информацией о ситуации на поле), и с управлением игроками от двух управляющих hostмашин. Однако, при желании, программы игроков могут моделировать автономные системы управления каждого игрока. Интерфейс сервера моделирования в версии для WINDOWS приведен на рис.10. Фрагмент игры команд-участников (интеллектуальных алгоритмов управления футболистами) приведен на рис.11. 7

8 Как отмечалось выше, разработано несколько версий серверов моделирования и основанных на них средств разработки программ управления игроками. Имеются серверы для операционных сред MS DOS, MS WINDOWS и LINUX. Поддерживаются 7 наиболее популярных систем разработки программ на языках C(C++) и PASCAL для DOS и WINDOWS и компилятор GNU C(C++) для LINUX. Разработанные программные средства моделирования со структурой, приведенной выше на рис.9, объединены в программный пакет "Виртуальный футбол". В настоящее время (осень 2002 г.) доступна версия 1.5 этого пакета. Рис.10. Интерфейс серверной программы пакета "Виртуальный футбол" в версии для WINDOWS. Рис.11. Эпизод игры команд в пакете "Виртуальный футбол". Отметим, что пакет "Виртуальный футбол" включает также программные средства, непосредственно поддерживающие разработку программ-игроков в упомянутых выше программных средах, к ним относятся необходимые библиотеки и шаблоны программ, эти средства и документация для разработчиков наряду с серверной программой предоставляются всем заинтересованным участникам проекта. Начиная с версий 1.4 и 1.5 в пакет включены специальные дополнительные программы утилиты для проигрывания (воспроизведения) записей игр, эти записи 8

9 выполняются серверной программой, а также набор утилит для проведения турнира по виртуальному футболу. К ним относятся утилиты составления (генерирования) расписания игр турнира, и утилиты управления играми турнира. 5. Пример алгоритма управления. В проведенных с созданной системой экспериментах исследованы базовые эвристические алгоритмы управления, не использующие коммуникацию роботов между собой. Эти алгоритмы различались значениями характерных параметров и способами вычисления некоторых определяющих функций, но относились к одному классу , характеризующемуся следующим. Считалось, что алгоритмы игроков одной команды, вообще говоря, одинаковы по типу, но могут различаться значениями параметров (всех, или некоторых). Игрокам выделяется прямоугольная зона на поле - зона ответственности игрока, эта зона может быть меньше целого поля, или совпадать со всем полем. Робот-игрок играет в пределах своей зоны ответственности и должен оставаться в этой зоне, за исключением тех случаев, когда он выходит из нее вследствие инерции своего движения, тогда он должен принимать меры к возврату в зону ответственности. В каждый момент времени игрок определяет точку цели своего движения, эти точки называются особыми точками для игрока. Схема особых точек приведена на рис.12. Особые точки - это точки удара (точка, в которой возможен удар по воротам противника), точка вратаря (точка, в которую нужно переместиться, чтобы защитить свои ворота) и точка паса другому игроку своей команды. Положение особых точек на поле зависит от положения всех объектов на поле, - и мяча, и игроков, и динамически изменяется с течением времени. Геометрические характеристики этих точек таковы. Точка удара находится на прямой, соединяющей центр ворот команды противника с центром мяча так, что мяч находится между воротами и игроком. Расстояние от игрока до мяча при вычислении этой особой точки фиксировано и является параметром алгоритма. Точка вратаря находится на прямой, соединяющей центр своих ворот с центром мяча так, что игрок находится между воротами и мячом. В разных вариантах алгоритмов фиксировалось либо расстояние от игрока до ворот, либо расстояние от игрока до мяча. В последнем варианте зона ответственности вратаря выбиралась близкой к воротам, чтобы вратарь не передвигался за мячом по всему полю, а защищал ворота. Наконец, точка паса точка, находящаяся на прямой, соединяющей центр мяча с тем положением робота-адресата паса, которое он достигнет, двигаясь по прямой с текущей скоростью за время, за которое мяч после удара придет в ту же точку. Каждый алгоритм имеет набор параметров, определяющих приоритеты различных особых точек. Особые точки непрерывно рассчитываются системой управления с использованием функций прогноза положения всех объектов на поле и приоритетов особых точек. Робот принимает решение двигаться в ту особую точку, которая либо является наиболее быстро достижимой (вариант с "коротким" прогнозом), либо наиболее эффективна с точки зрения цели игры (вариант с полным прогнозом), либо является наиболее приоритетной (при этом приоритеты являются изменяемыми параметрами алгоритмов). Наконец, на основе введенной схемы рассмотрены три класса алгоритмов управления. В первом из них ("жесткие" или детерминированные алгоритмы) реализована только лишь указанная схема управления по особым точкам. Во втором классе (расширенные алгоритмы) реализованы логика "упорядочивания" движения на половине поля противника, а также схемы, имеющие приоритетную задачу выбивать мяч со своей половины (режим защитной тактики). Введена еще одна особая точка, алгоритмом последней модели она выбирается подобно точке удара, но на расстоянии, меньшем, чем 9

10 радиус робота. Это позволяло эффективно вести мяч к воротам соперника, вместе с тем не пропуская удары в сторону своих ворот. Рис.12. Схема особых ситуаций (особых точек) для принятия решений. В третьей схеме введены роли игроков (вратарь, защитник, нападающий, и т.п.), причем игроки могут динамически менять свои роли в зависимости от конкретной игровой ситуации. Эти, так называемые, "ролевые" алгоритмы были приняты в качестве базовых для проведения первых соревнований на основе пакета "Виртуальный футбол". Резюмируя отметим, что параметрами описываемой модели являются параметры роботов-участников, их зоны ответственности, глубина прогноза и варианты выбора типа прогноза (короткий или полный) при принятии решения, геометрические параметры расчета особых точек и их приоритеты, параметры типа алгоритма, задающие тот, или иной класс алгоритма, параметры выбора ролей игроков. Они оптимизировались путем многократного моделирования игры. 6. Моделирование и оптимизация алгоритмов. Проведено большое количество экспериментов, в том числе использовавших методы "машинной эволюции" с использованием генетических алгоритмов, в ходе которых отбирались наиболее эффективно играющие алгоритмы. Механизм отбора был построен на основе игры сравниваемых алгоритмов, отличающихся значениями определяющих параметров. Победивший вариант алгоритма выбирался для дальнейшей направленной оптимизации. Целью этих экспериментов был поиск наилучших значений указанных выше параметров и их сочетаний. В результате найдены оптимальные варианты алгоритмов, обеспечивавшие наибольший процент побед в проведенных "матчах". Нужно отметить, что при этом отдельно "тренировались" программы для роботов-вратарей, т.к. в реальной игре эпизодов с участием и, следовательно, тренировкой, вратарей происходит недостаточное количество. Затем проводились эксперименты по моделированию, в которых частично некоторыми функциями управления игроками управлял человек-оператор. Целью этих экспериментов была дальнейшая оценка эффективности найденных управляющих алгоритмов. Показано, что автоматические алгоритмы в целом выигрывают у команды, в которой "участвует" человек-оператор. Оптимизированные алгоритмы показали достаточно высокое качество игры, на этом основании они были предназначены для игры в соревнованиях. С их использованием была построена программа VST (название - аббревиатура от Virtual Soccer Team). 10

11 7. Соревнования по Виртуальному футболу. С использованием созданных моделей организуются регулярные соревнования по Виртуальному футболу роботов, подготовлены регламент таких соревнований и необходимая техническая документация, ведется рассылка всех программных средств моделирования заинтересованным участникам. Первые товарищеские соревнования трех команд были проведены г., этот турнир состоялся в рамках Конференции/Школы "Интеллектуальные и многопроцессорные системы" / "Интеллектуальные робототехнические системы" (ИМС- 2001/ИРС-2001), прошедших в Дивноморском, Геленджик, Россия. В турнире участвовали команда авторов настоящей работы (команда из ИПМ им.м.в.келдыша РАН - МГУ, Москва), команда из НИИ МВС ТРТУ, г. Таганрог (автор программы - Сергей Стоянов), команда из Днепропетровского национального университета, г. Днепропетровск, Украина (автор программы - Сергей Степанов). В настоящее время (осень 2002 г.) в проекте участвуют 20 команд из городов России и Украины Москвы (9 команд), Таганрога (3 команды), Волгограда (1 команда), Челябинска (1 команда), Владивостока (2 команды), Днепропетровска (1 команда), Донецка (3 команды). Количество команд в этих городах увеличивается, о своем намерении присоединиться к проекту заявили команды разработчиков из Санкт- Петербурга, Краснодара, Киева. Все перечисленные команды это команды различных университетов и ВУЗов, развиваемый проект активно используется в них в том числе и в учебном процессе для обучения студентов и аспирантов. В период осень 2001 осень 2002 года проведены 4 официальных турнира, турнир на Фестивале "Мобильные роботы 2001" в МГУ (декабрь 2001 г.) , турнир в МГУ во время "Дня механико-математического факультета МГУ" (апрель 2002 г.), турнир в Таганроге в рамках конференции "Многопроцессорные вычислительные системы " (июнь 2002 г.), турнир в Кацивели (Крым, Симеиз) на Украине в рамках конференции "Искусственный интеллект 2002" (сентябрь 2002 г.). Запланирован турнир на Фестивале "Мобильные роботы 2002" в МГУ в декабре 2002 г. По всем проведенным турнирам накоплен большой объем статистической информации и записей игр, позволяющий анализировать и совершенствовать создаваемые алгоритмы управления футболистами. Победителями прошедших турниров становились команды Днепр (Днепропетровск, ДНУ), Нерв (Москва, МЭИ ТУ), VST (Москва, ИПМ им.м.в.келдыша РАН МГУ), Квазар (Москва, МЭИ ТУ). Соревнования подтвердили эффективность принятых при разработке моделей игры решений и эффективность реализованной системы моделирования. Вместе с тем, в дальнейшем предполагается существенное развитие этой системы. Его цель повышение логической сложности игры, введение новых игровых функций. 8. Заключение. План развития системы. На основе проведенных экспериментов определены технические предложения по созданию расширенных алгоритмов управления роботами-игроками, начата разработка алгоритмов с реализацией активного взаимодействия игроков (игры в пас, и т.п.). Предполагается также следующее развитие модели игры, на основании которого будет реализована расширенная генерация системы. Для обеспечения эффективного воздействия игрока на мяч предполагается введение "вектора удара" игрока по мячу. Этот вектор соединяет центры игрока и мяча, но при этом не обязательно направлен вдоль продольной оси (или скорости) робота-игрока. Вектор удара будет реализовывать удар по мячу различной силы, но и различной точности (при большей силе удара точность удара должна уменьшаться). Этот вектор должен моделировать устройства удара, которыми оснащаются реальные роботы-футболисты, аналогичные показанным на рис.1-8. В дополнение к этим "устройствам" предполагается введение модели захватного 11

12 устройства робота, обеспечивающего ведение мяча игроком. Предполагается, что эти средства позволят реализовать игру с большим разнообразием ситуаций и более широкими возможностями по управлению роботами и принятию игровых решений. Описываемое расширение будет включено в версию сервера 2.0, анонсировать который предполагается в декабре 2002 г. на Фестивале "Мобильные роботы". Подготовлен также проект следующей версии сервера (версии 3.0), в которой будет реализована "строгая" мультиагентная среда управления виртуальными футболистами. Разработана пилотная версия сервера, реализующего 3D-моделирование игры. ЛИТЕРАТУРА. 1. С.В.Ахапкин, С.В.Васильев, В.И.Городецкий, Л.А.Станкевич. Футбол роботов многоагентная среда для исследования группового поведения интеллектуальных роботов. // Тр. X науч.-тех. конф. "Экстремальная робототехника", СПб, 1999, изд-во СпбГТУ, с RoboCup Federation. Official materials SoccerServer Manual. (RoboCup Federation electronic documentation and links on the Internet) Materials of CS Freiburg soccer team FIRA official materials France Robotic Festival Д.Е.Охоцимский, В.Е.Павловский, А.Г.Плахов, А.Н.Туганов. Моделирование игры роботов-футболистов и базовые алгоритмы управления ими. // Искусственный интеллект, N 3, 2000, с Д.Е.Охоцимский, В.Е.Павловский, А.Г.Плахов, А.Н.Туганов, В.В.Павловский. Моделирование игры роботов-футболистов в пакете "Виртуальный футбол". // Мехатроника, N 1, 2002, с Фестиваль "Мобильные роботы" в МГУ RoboCup Federation. Rules. & rules. 11. RoboCup

Институт прикладной математики им. М.В.Келдыша Российской академии наук На правах рукописи Плахов Андрей Григорьевич ВИРТУАЛЬНЫЙ ФУТБОЛ РОБОТОВ: АЛГОРИТМЫ ИГРОКОВ И СРЕДА МОДЕЛИРОВАНИЯ Специальность 05.13.11

Санкт-Петербургский государственный университет информационных технологий, механики и оптики Кафедра «Компьютерные технологии» А.А. Шевченко, М.В. Костенко Автоматическая генерация тактик для игроков в

Введение... 9 Глава 1. История футбола и основные футбольные термины...11 Словарь футбольных терминов...11 История современного футбола...27 Глава 2. Подготовка к занятиям...47 Познай свое тело...47 Футбольная

234 Юрий ТЕСЛЯ 9.5. Прогнозирование результатов футбольных матчей Наверное с использованием разработанных моделей и методов можно решать различные интеллектуальные задачи. Но поскольку в их основе находится

Прогнозирование осуществляется по трем алгоритмам в основе которых находится: 1. Рейтинг команд. Отображает величину воздействия команды на результат матча. Рейтинг рассчитывается автоматически как прогнозируемый

МАЛЫМИ СОСТАВАМИ Adresa: str. Tricolorului, 39, MD 2012, CHIŞINĂU, Republica Moldova Telefon/fax: + 373 22 88 04 20 Compartamentul Tehnic FMF E-mail: [email protected] www.fmf.md ВВЕДЕНИЕ Соревновательный аспект

Каляев А.В. ПРОГРАММИРОВАНИЕ ВИРТУАЛЬНЫХ АРХИТЕКТУР И ОРГАНИЗАЦИЯ СТРУКТУРНО- ПРОЦЕДУРНЫХ ВЫЧИСЛЕНИЙ В МНОГОПРОЦЕССОРНЫХ СИСТЕМАХ С МАССОВЫМ ПАРАЛЛЕЛИЗМОМ 1 Аннотация НИИ многопроцессорных вычислительных

Положение о лиге по мини-футболу (футзалу) среди студентов Назарбаев Университета I. ЦЕЛИ И ЗАДАЧИ 1.1 Лига по мини-футболу (футзалу) среди студентов и сотрудников Назарбаев Университета (далее - Лига)

Конкурс «Первый шаг в мир роботов» Номинация: «Футбол» Составитель: Гудкова Екатерина Анатольевна - сертифицированный тренер Lego Education Academy 1. Условия состязания В этом состязании участникам необходимо

ХАРАКТЕРИСТИКА ИГРЫ Волейбол является спортивной игрой с мячом, в которой две команды соревнуются на специальной площадке, разделенной сеткой. Существуют различные версии игры, чтобы показать ее многогранность.

Некоторые, ключевые изменения в Правилах игры в футбол 2016. (Этот материал не является официальным документом) ПРАВИЛО 1 ПОЛЕ ДЛЯ ИГРЫ Определена минимальная разметка, при которой можно начинать игру.

П РА В И Л А И Г Р Ы All rights reserved. Copyright since 98 Superfut OÜ Добро пожаловать в Superfut! Вы сделали хороший выбор! Теперь у вас появится уникальная возможность сыграть в настоящий футбол в

Состязание «Управляемый футбол 2х2» 1. Общие положения 1.1. Поле. Размер 2400 мм на 1200 мм. Размер ворот 500-700 мм. Цвет полигона белый. Бортики не менее 50 мм. 1.2. Мяч. В качестве мяча используется

Скачать pes 2015 на андроид с кешем >>> Скачать pes 2015 на андроид с кешем Скачать pes 2015 на андроид с кешем Отзывчивое управление позволяет быстро реагировать на каждое движение остальных участников

Правила проведения соревнований по баскетболу 3x3 в рамках всероссийского этапа Всероссийских спортивных игр школьников «Президентские спортивные игры» 1. Общие положения Соревнования по уличному баскетболу

Выполнила: инструктор по физической культуре Леонова С.Л. ФУТБОЛ КАК ВИД СПОРТА ФУТБОЛ (англ. football, от foot нога и ball - мяч), командная спортивная игра с мячом на специальной площадке (поле); в командах

Модуль 3. УПРАВЛЕНИЕ ПРОЦЕССАМИ 1. Распределяет процессорное время между несколькими одновременно существующими в системе процессами, а также занимается созданием и уничтожением процессов, обеспечивает

130 Ежегодное Пленарное Заседание Международново Совета футбольных ассоциаций (IFAB) Кардиф, Уельс рд ф, 05 марта 2016 Главные изменения Law 12 Лишение соперника очевидной возможности забить мяч Когда

«СОГЛАСОВАНО» Глава Местной администрации Муниципального образования города Сестрорецка Т.С. Осянникова 2017 г. «УТВЕРЖДАЮ» Генеральный директор Федерации футбола Санкт-Петербурга А.А. Зинченко 10 мая

УДК 621.38 ТРЕХМЕРНАЯ АНИМИРОВАННАЯ РЕКОНСТРУКЦИЯ ФУТБОЛЬНОГО МАТЧА ИЗ ВИДЕО Галиакберов Р.А., Ладыженский Ю.В. Донецкий национальный технический университет Кафедра прикладной математики и информатики

Хет-трик футбольная карточная игра Патрика Ковальски перевод Валерия Крапиля Для 2 игроков от 14 лет 20 карт полевых игроков с указанием силы в атаке (1а) и силы в защите (1b) Компоненты игры: 45-60 минут

Государственное бюджетное образовательное учреждение дополнительного образования детей Санкт-Петербургский центр детского (юношеского) технического творчества Спортивная игра «Хупбол»

«УТВЕРЖДАЮ» Президент МРО «Северо-Запад» А.А.Турчак 2018 г. ПОЛОЖЕНИЕ О проведении Фестиваля студенческого футбола Межрегионального объединения региональных спортивных федераций по футболу «Северо-Запад»

ВЫСОКИЕ ТЕХНОЛОГИИ ДЛЯ ВЫСОКИХ ЦЕЛЕЙ Новый подход к организации корпоративных событий Универсальное средство для организации эксклюзивных мероприятий Quest event это уникальное программное решение, предоставляющее

ФУТБОЛ УПРАВЛЯЕМЫХ РОБОТОВ. V ВОЗРАСТНАЯ КАТЕГОРИЯ Общие положения Поле Мяч В качестве мяча используется стандартный мяч для гольфа. Цвет мяча белый, оранжевый или розовый. Диаметр мяча 43 мм. Вес мяча

КВАЗИПЛАНИРОВЩИК ДЛЯ ИСПОЛЬЗОВАНИЯ ПРОСТАИВАЮЩИХ ВЫЧИСЛИТЕЛЬНЫХ МОДУЛЕЙ МНОГОПРОЦЕССОРНОЙ ВЫЧИСЛИТЕЛЬНОЙ СИСТЕМЫ ПОД УПРАВЛЕНИЕМ СУППЗ А.В. Баранов, Е.А. Киселёв, Д.С. Ляховец Межведомственный суперкомпьютерный

MATLAB 5.2. ИМИТАЦИОННОЕ МОДЕЛИРОВАНИЕ В СРЕДЕ WINDOWS: ПРАКТИЧЕСКОЕ ПОСОБИЕ. Гультяев А.К. В книге рассматриваются основы построения имитационных моделей и их применения в задачах принятия решений. Основное

МЕТОДЫ И АЛГОРИТМЫ АВТОМАТИЧЕСКОЙ РАССТАНОВКИ ЗАДЕРЖЕК В ВЫЧИСЛИТЕЛЬНЫХ СТРУКТУРАХ С ОБРАТНЫМИ СВЯЗЯМИ А.А. Гуленок, А.В. Бовкун, В.А. Гудков В последнее время широкое распространение получили программируемые

Футбольный победитель взлом >>> Футбольный победитель взлом Футбольный победитель взлом На данный момент разработчики выложили файл от 14 апреля 2016 г. Стоит учитывать то, что разработчиков порой нужно

УДК 004.932.2 ПАРАЛЛЕЛЬНАЯ ВЫЧИСЛИТЕЛЬНАЯ СИСТЕМА ДЛЯ ОТСЛЕЖИВАНИЯ ОБЪЕКТОВ В ВИДЕОПОТОКЕ А.А. Середа, Ю.В. Ладыженский Донецкий национальный технический университет В докладе рассмотрена параллельная

Модуль 6. АРХИТЕКТУРА ОПЕРАЦИОННЫХ СИСТЕМ 1. Ядро операционной системы это программные модули операционной системы, которые постоянно находятся 1) в оперативной памяти с целью эффективной организации вычислительного

Процессы и потоки Понятия «процесс» и «поток» Процесс (задача) - программа, находящаяся в режиме выполнения. Потоќ выполне ния (thread нить) наименьшая часть программы, исполнение которой может быть назначено

УДК.744 (075.8) ИНФОРМАЦИОННАЯ И ФУНКЦИОНАЛЬНАЯ МОЩНОСТЬ СЦЕН СВР В.Г. Ли Таганрогский технологический институт Южного федерального университета Работа посвящена проблеме оценки производительности визуализаторов

СОГЛАСОВАНО Директор Санкт-Петербургского государственного автономного учреждения «Центр подготовки спортивных сборных команд Санкт-Петербурга» УТВЕРЖДАЮ Заместитель председателя Комитета по физической

ХАРАКТЕРИСТИКИ ПАРАЛЛЕЛЬНЫХ ВЫЧИСЛИТЕЛЬНЫХ ПРОЦЕССОВ И СИСТЕМ Характеристики, связанные с работой вычислительной системы, производительность, загруженность, ускорение позволяют оценить качество процессов

Модельные показатели соревновательной деятельности футболистов высокой квалификации Перевозник В. И., Перцухов А. А. Аннотация. Цель работы проанализировать модельные показатели техникотактических действий

ПРОГРАММА ПОДГОТОВКИ ФУТБОЛИСТОВ 10-14 ЛЕТ В ЧЕМ ПРОБЛЕМЫ СОВМЕСТНЫЙ МОНИТОРИНГ С DFB У юных футболистов нет понимания структуры игры Тренеры не владеют практическими навыками конструкции «футбольных»

Рабочая программа для второго года обучения по дополнительной общеобразовательной общеразвивающей программе «Футбол» Возраст учащихся: 6-9 лет Разработчик программы: Кляцко Антон Александрович педагог

РАЗРАБОТКА ИМИТАЦИОННОЙ МОДЕЛИ СИСТЕМЫ УПРАВЛЕНИЯ АВТОМАТИЗИРОВАННЫМ АВТОДРОМОМ Д.А. Егоров Общее описание системы Система определяет положение автомобиля на автодроме по изображениям с камер, расположенных

Формы учебного процесса, используемые при реализации образовательной программы «робототехника», как образовательной технологии. Будучи ограниченным общим временем нашего педагогического совета, позвольте

ЧЛЕНАМ ФИФА Циркуляр 1262 Цюрих, 12 мая 2011 г. SG/ftr-est Изменения к Правилам игры 2010/2011. Господа, 5 марта 2011 г. в Уэльсе состоялось 125 ежегодное Общее заседание Международного совета футбольных

Раздел 5 Система материальных точек Движение абсолютно твердого тела Тема 1 Кинематика и динамика абсолютно твердого тела Тема 2 Момент инерции Сохранение момента импульса Тема 3 Энергия движущегося АТТ

II. Аннотация 1. Цели и задачи дисциплины Целями освоения дисциплины являются изучение круга задач, решаемых современными операционными системами, применяемых для их решения методами и алгоритмами, а также

Памятка для судьи Первенства ДЮФК РК сезона 2015-2016гг I. Система проведения и сроки соревнований 1. Первенство ДЮФЛ Крыма по футболу проводится по всем 9 (девяти) возрастным категориям по принципу «каждый

УТВЕРЖДАЮ: Президент местной общественной организации «Красноярская городская федерация спортивного туризма», председатель «Красноярский городской клуб спелеологов» И.Н. Бурмак 2016 г. УТВЕРЖДАЮ: Председатель

ЛАБОРАТОРНАЯ РАБОТА «ПРИНЯТИЕ РЕШЕНИЙ В СРЕДЕ SCILAB». Введение Sclb - это система компьютерной математики, которая предназначена выполнения инженерных и научных вычислений, включающих в себя задачи принятия

Футбол управляемых роботов 1. Общие положения 1.1. Поле 1.1.1. Цвет полигона зеленый. 1.1.2. Цвет линии разметки белый. 1.1.3. Материал полигона войлок или ковер. 1.1.4. Ширина линии разметки 15-20 мм.

Руководство по работе с пакетом SCILAB Автор: Павлова М. И. e-mail: [email protected] Новости Scilab В 2-3 декабря 2004 года состоялась первая международная конференция SCILAB2004. Программу и материалы статей

Я всегда считал, что те, кто работает в футболе, являются привилегированными. Нам платят за работу, которую мы любим и которую нам нравится выполнять. А в моём случае я также был достаточно удачлив, так как работал в разных странах, сталкивался с различными культурами и методами работы, пополнял свой багаж знаний и опыта. И это помогает мне при анализе смотреть на вещи с разных сторон.

Когда люди обсуждают трансферы, рыночную стоимость игроков и причины, по которым вы покупаете или продаёте того или иного футболиста, легко заметить, что многие не видят истинного положения вещей. Ситуация может быть слишком сложной и запутанной для фанатов. И в этой статье я постараюсь изложить свой взгляд на подобные проблемы, опираясь на личный опыт.

Естественно, я сосредоточусь на своей зоне ответственности в клубе. Это футбол, руководство игрой, определяемое менеджером или тренером – в зависимости от ситуации.

Клубная структура

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

Правила, турнирная таблица, состав, работники клуба и их полномочия, контракты футболистов, окружающая среда, культура, традиции клуба… Знание всего этого очень важно для принятия правильных решений. По крайней мере, тех, что зависят от вас.

В Испании и Италии есть должность, которую называют «футбольный директор» (Director of Football) или «главный скаут» (Chief Scout). В теории он отвечает за подписание тренера и пополнение состава. В большинстве случаев, хотя и не всегда, он консультирует ответственного человека, либо президента/владельца (President/Owner), который отвечает за все процессы, где необходимо его последнее слово.

В Англии всем этим занимается менеджер (Manager). В числе его полномочий управление всеми футбольными делами, в том числе – определение состава на матч.

На практике обе типа структуры зависят от одного обстоятельства: доступных средств на трансферы и зарплаты игроков. Что «менеджер», что «тренер» неизбежно сталкиваются с тем, что они имеют возможность подписать только трёх-четырёх игроков из своего списка. Это на самом деле так. В последнем случае менеджер может выбрать тех, кого хочет.

Формирование состава

Как человек, отвечающий за техническую сторону вопроса, вы должны выбрать игровую модель, в соответствии с которой ваша команда будет вести себя на поле. Важно познакомиться со всеми игроками, поговорить с ними, выяснить их мнение относительно состава. В случае необходимости дополнить обойму исполнителями, способными качественно её усилить. Если у вас нет такой возможности, придётся приспособить под вашу модель игры имеющийся состав и надеяться, что футболисты окажут поддержку, когда она понадобится вам.

Кроме того, в разных странах разнятся подходы к составлению контрактов. Особые условия – в клубах, участвующих в международных турнирах. Есть лиги, где обязательно должны играть 5 игроков из этой страны, в других присутствует лимит на подписание иностранцев, в третьих игроков делят на списки «А» и «В»… В конце концов, каждая страна, каждая лига имеет свои особенности. И вы обязаны их полностью переварить, прежде чем присоединитесь к коллективу и решитесь изменять его.

У вас должен быть план, своеобразный «футбольный проект». Но в разговоре с владельцами, которые приходят в футбол из мира бизнеса, его нужно называть только «бизнес-планом».

И тут я снова обращусь к собственному опыту. Когда я приехал в Италию, там не было никакого «бизнес-плана». Я узнал об этом только в последний день трансферного окна, когда мне неожиданно сообщили, что клуб собирается следовать финансовому фэйр-плэй.

В Испании постоянный диалог с руководством клуба позволяет вам придерживаться экономических ограничений, вы понимаете, где вы находитесь. Хотя однажды для меня стало сюрпризом приобретение форварда в последний день августа, инициированное президентом. Он обосновал этот трансфер дешёвой стоимостью игрока, поскольку он был в аренде.

В Англии, в частности, в «Ливерпуле» во время моих первых 3-х сезонов, председатель и главный исполнительный директор держали меня в курсе всех ограничений и имевшихся вариантов. Позже клубная структура изменилась, и постепенно бизнес-план становился всё более и более важным, чем любой футбольный проект, когда дело доходило до принятия важных решений.

То, что также нельзя забывать, это деятельность юношеской академии. Наигрывание местных игроков существенно увеличивает ваше родство с клубом и значительно снижает затраты. В Испании и Италии молодёжная структура возложена на спортивного директора, главный тренер уделяет ей не так много времени. В Англии может случиться то же, что произошло со мной в последний год работы в Ливерпуле: менеджер получает полный контроль над всей молодёжной системой и может непрерывно следовать одному стилю игры во всех возрастных группах. Барселонская структура работы с молодёжью сейчас на пике популярности. Более очевидного и яркого примера в этом плане не сыскать.

При отсутствии молодых проспектов, способных в ближайшее время заиграть в основе, вам придётся окинуть взглядом трансферный рынок.

Спортивный директор или менеджер должны держать трансферный бюджет под своим контролем, а также заниматься подсчётом зарплат футболистов. Хорошая сеть скаутов необходима, хотя и действует не безошибочно, а деньги будут влиять на доступность определённых ниш рынка для вашего клуба. Доходы и расходы для менеджера имеют большую значимость, чем для тренера.

Правила и виды регламентов

Что также необходимо рассмотреть, это различные международные нормы. Обычно заявка первой команды на сезон ограничена 25 футболистами. В ряде стран, как в Испании, например, вы можете выпустить юниора на поле в 5 матчах, после чего он должен быть внесён в основной состав.

В Англии вы можете использовать услуги игроков резервной команды, в которой мы обкатывали молодёжь, а она, в свою очередь, получала необходимый для продвижения к первой команде опыт.

У вас в распоряжении команда U18. Некоторые футболисты оттуда, особенно если они из-за границы, должны иметь профессиональные контракты. В противном случае другие клубы могут умыкнуть их прямо из-под вашего носа.

Во время моей работы в «Ливерпуле» болельщики часто говорили, что я подписал слишком много игроков, тогда так на самом деле многие из них тренировались в отдельных юниорских группах, и некоторых из них я даже не знал. В Испании такие футболисты присоединяются ко второй молодёжной команде, и не включаются в реестр приобретений основной команды. Тот же принцип действует в Италии.

[В комментариях к статье Рафа заметил, что испанская система лучше английской, так как игроки «молодёжки» не варятся среди своих сверстников, они играют во взрослый футбол в низших дивизионах, в связи с чем гораздо проще понять уровень их конкурентноспобности на высоком уровне]

Лига чемпионов

Ещё один набор правил, с которыми нам всегда приходится считаться, – включение в список собственных воспитанников и местных при составлении заявки на Лигу чемпионов. Это число достигло 4-х в графе «воспитанники своей академии», также требуется 4 местных игрока. Если футболист провёл в клубе более 3-х лет до достижения 21-летия, он считается собственным воспитанником.

Опять же есть различия. Тренер занимается только своей командой, состав – прерогатива спортивного директора. А вот менеджеру приходится составлять планы на будущее. В «Ливерпуле» перед нами ставилась следующая задача: привести из-за рубежа несколько молодых игроков, которым до 21-летия как минимум 3 года (Айяла, Пачеко, Инсуа).Таким образом, согласно правилам того времени, в дальнейшем они бы считались нашими воспитанниками, чем помогли бы клубу сохранить деньги на трансферах и контрактах, а также были бы внесены в заявку на Лигу чемпионов. В Испании и в Европе в целом как тренер вы вовлекаетесь в процесс формирования планов на следующие годы только в том случае, если работаете несколько лет и выигрываете трофеи. Сделать это удаётся немногим.

1. Постановка задачи.. 2

2. Проектирование базы данных.. 2

2.1. Основные понятия. 2

2.2. Нормализация баз данных. 3

3. Пояснения к проекту.. 6

4. Последовательность работы... 6

4.1. Создание таблиц.. 6

4.1.1. Средства для работы с базами данных. 6

4.1.2. Инструментальные средства. 7

4.1.3. Компоненты.. 7

4.1.4. Псевдоним базы данных. 7

4.1.5. Создание базы данных. 7

4.1.6. Создание псевдонима. 7

4.1.7. Создание таблиц. 9

4.2. Создание форм.. 11

4.3. Доступ к базе данных. 12

4.4. Использование модуля данных. 13

4.5. Навигация по таблицам базы данных. 14

4.5.1. Форма Список команд . 14

4.5.2. Перемещение по записям.. 15

4.5.3. Форма Список матчей . 16

4.5.4. Форма Список голов . 21

4.5.5. Задание для самостоятельной работы.. 21

5. Список литературы... 21

6. Приложение. Пример реализации поиска.. 22

Создать базу данных Чемпионат по футболу , которая будет состоять из нескольких таблиц. Для заполнения таблиц создать формы. Предусмотреть возможность поиска информации по ключевым полям.

2. Проектирование базы данных

2.1. Основные понятия

База Данных – организованная совокупность данных, предназначенная для длительного хранения во внешней памяти ЭВМ, постоянного обновления и использования. (Ершов словарь по информатике).

Можно доказать, что любую структуру данных можно преобразовать в простую двумерную таблицу. Такое представление является наиболее удобным и для пользователя, и для машины.

Реляционная база данных - совокупность данных состоящих из связанных двумерных таблиц.

Примечание

Название произошло от английского слова «relation» - отношение.

Поле таблицы

Номер

Имя абонента

Адрес

Запись таблицы

Петров Евгений

Садовая ул., 18

Дядя Коля

Зеленая ул., 45-2-56

Химчистка

Киевская ул., 123

Основные понятия реляционных баз данных

Любые совокупности данных представляются в виде двумерных таблиц , каждая из которых содержит информацию об объектах определенного типа. Каждая таблица состоит из фиксированного числа столбцов и переменного числа строк . Запись – строка таблицы.
Каждая запись содержит информацию об отдельном экземпляре объекта. Поле – столбец таблицы.
Каждый столбец представляет собой конкретное данное – одну характеристику объекта (атрибут). Для каждого поля разработчик должен определить:

· уникальное имя поля;

· тип поля;

· дополнительные характеристики (длину, формат) поля.

Основная идея реляционного подхода – представить произвольную структуру данных в виде простой двумерной таблицы. Такой процесс называется нормализацией структуры.

2.2. Нормализация баз данных

При проектировании структуры базы данных могут возникнуть проблемы:

· избыточность информации;

противоречивость информации; потеря целостности (взаимосвязь между данными).

Процесс проектирования базы данных с использованием метода нормальных форм является пошаговым и заключается в последовательном переводе по определенным правилам отношений из первой нормальной формы в нормальные формы более высокого порядка.

Приступим к разработке базы данных, в которой будет храниться информация о футбольном чемпионате страны (дата матча, играющие команды, забитые голы). Представим эту информацию в виде таблицы 1. В структуре таблицы указаны только названия полей, т. к. тип и размерность полей на данном этапе значения не имеют.

Таблица 1

Имя поля

Дата матча

Команда хозяев: название, город, тренер

Команда гостей: название, город, тренер

Игрок, забивший гол

Существуют основные правила нормализации структуры базы данных. Приведем только правила, с которыми будем работать.

Правило 1: В таблице необходимо разделить составные поля на отдельные элементы данных. Каждое поле таблицы должно представлять уникальный тип информации. Т. е. необходимо избавиться от повторяющихся полей (групп).

Правило 2: Каждая таблица должна иметь уникальный идентификатор (первичный ключ), который может состоять из одного или нескольких полей.

Правило 3: В таблице не должно быть данных, не относящихся к объекту, определяемому первичным ключом.

1 шаг (Правило 1)

В таблице 1 второе и третье поле являются составными, и содержат информацию о названии команды, города, фамилии тренера. В соответствии с Правилом 1 необходимо эти поля разделить. У нас получится новая таблица 2.

Таблица 2

Имя поля

Дата матча

Команда хозяев: название

Команда хозяев: город

Команда хозяев: тренер

Команда гостей: название

Команда гостей: город

Команда гостей: тренер

Игрок, забивший гол

Признак команды, к которой принадлежит игрок

Время (число минут от начала матча)

Еще одно требование, которое мы должны учесть – это необходимость избавления от повторяющихся полей (групп). На первый взгляд может показаться, что в таблице 2 повторяющимися группами полей являются поля с информацией о командах хозяев и гостей. Но эти поля имеют различное функциональное значение.

2 шаг (Правило 2)

Записи таблицы 2 не содержат уникального ключа, по которому однозначно можно определить проводимый матч. Поэтому введем в таблицу 2 дополнительное поле ключа – код матча. У нас получится новая таблица 3.

Таблица 3

Имя поля

Код матча (ключ)

Дата матча

Команда хозяев: название

Команда хозяев: город

Команда хозяев: тренер

Команда гостей: название

Команда гостей: город

Команда гостей: тренер

Игрок, забивший гол

Признак команды, к которой принадлежит игрок

Время (число минут от начала матча)

Для каждого гола в таблице 3 содержится повторяющаяся информация о дате матча, о командах. Поэтому разобьем эту таблицу на две таблицы, одна будет содержать данные о матчах, а другая – о голах, забитых в каждом конкретном матче. Структура этих таблиц приведена в таблицах 4 и 5.

Таблица 4

Имя поля

Код матча (ключ)

Дата матча

Команда хозяев: название

Команда хозяев: город

Команда хозяев: тренер

Команда гостей: название

Команда гостей: город

Команда гостей: тренер

Таблица 5

Имя поля

Код гола (ключ)

Код матча

Игрок, забивший гол

Признак команды, к которой принадлежит игрок

Время (число минут от начала матча)

Таблицы 4 и 5 связаны по полю Код матча , которое для таблицы 4 является уникальным. Чтобы обеспечить уникальность записей таблицы 5, в нее введен ключ Код гола .

3 шаг (Правило 3)

Для выполнения Правила 3 необходимо выделить в отдельную таблицу те поля, которые не зависят от ключа Код матча . В таблице 4 такими полями являются поля, которые определяют команду. Разобьем таблицу 4 на две таблицы: первая – информация о матчах, вторая – информация о командах (см. таблицы 6 и 7).

Таблица 6

Имя поля

Код матча (ключ)

Дата матча

Код команды хозяев

Код команды гостей

Таблица 7

Имя поля

Код команды (ключ)

Название

В результате наша база данных Чемпионат по футболу будет иметь структуру, показанную на рисунке 1.

3. Пояснения к проекту

Проект будет состоять из пяти форм:

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

4. Последовательность работы

4.1. Создание таблиц

4.1.1. Средства для работы с базами данных

Средства Delphi , предназначенные для работы с базами данных, можно разделить на два вида:

· Инструментальные средства – специальные программы, обеспечивающие обслуживание баз данных вне разрабатываемых приложений.

· Компоненты , предназначенные для создания приложений, осуществляющих операции с базами данных.

4.1.2. Инструментальные средства

· Borland Database Engine (BDE) – процессор баз данных, который представляет собой набор динамических библиотек и драйверов, предназначенных для организации доступа к базам данных из Delphi-приложений.

· BDE Administrator – утилита для настройки различных параметров BDE.

· Database Desktop – программа создания и редактирования таблиц, SQL-запросов.

· SQL Explorer – Проводник баз данных, позволяющий просматривать и редактировать базы данных.

4.1.3. Компоненты

Приведем компоненты, которые будут использованы в данном проекте.

Table – набор данных, основанный на таблице базы данных (страница BDE );

DataSource – источник данных (страница Data Access );

DBGrid – таблица (страница Data Controls );

DBNavigator – навигационный интерфейс (страница Data Controls );

DBEdit – однострочный редактор (страница Data Controls ).

4.1.4. Псевдоним базы данных

Разрабатывая программу, трудно сразу предусмотреть на каком диске, в каком каталоге будут находиться файлы базы данных во время их использования. Для решения этой проблемы в Delphi используется псевдоним (alias ), который указывает место нахождение файлов базы данных. Псевдоним – это короткое имя, поставленное в соответствие реальному, полному имени каталога базы данных. Псевдонимы сохраняются в реестре, и потом все программы при запуске смогут по этим псевдонимам найти таблицу и прочитать необходимые настройки, которые надо использовать при доступе к данным.

Примечание

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

4.1.5. Создание базы данных

Процесс создания базы данных может быть представлен как последовательность следующих шагов:

1. Создание папки.

2. Создание псевдонима.

3. Создание таблиц.

Создадим папку для нашего проекта и подпапку для базы данных с помощью средств Windows. Имя папки – База Данных , имя папки – Данные .

4.1.6. Создание псевдонима

Псевдоним (alias) может быть создан при помощи утилиты BDE Administrator :

C:\Program Files\Common Files\Borland Shared\BDE\bdeadmin. exe

На Рисунке 2 приведен вид диалогового окна BDE Administrator после запуска утилиты.

В левой части окна, на вкладке Databases , перечислены псевдонимы, зарегистрированные на данном компьютере. Для создания нового псевдонима необходимо выбрать команду меню Object – New . Откроется новое диалоговое окно New Database Alias (Рисунок 3) из списка Database Driver Name выберем драйвер (тип базы данных) STANDARD , который обеспечивает доступ к таблицам в формате Paradox .

Для подтверждения выбора драйвера кликнем на клавише OK . В результате в список псевдонимов будет добавлен новый элемент (см. Рисунок 4).

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

Имя псевдонима можно изменить, щелкнув правой кнопкой мыши на имени псевдонима (на вкладке Databases ), в открывшемся контекстном меню выбрать команду Rename и ввести новое имя – SPORT .

Путь к файлам базы данных вводится на вкладке Definition в поле Path с клавиатуры или с помощью стандартного диалогового окна Select Directory, которое открывается щелчком на кнопке с тремя точками, находящейся в конце поля Path (см. Рисунок 5).

Для того чтобы созданный псевдоним был зарегистрирован в файле конфигурации (idapi. cfg ), необходимо выполнить команду в меню Object – Apple (Применить) . В открывшемся диалоговом окне Confirm следует подтвердить необходимость сохранения изменений в файле конфигурации.

4.1.7. Создание таблиц

Приступим к созданию таблиц базы данных Чемпионат по футболу : таблица матчей – Match , таблица команд – Team и таблица голов – Goal . Структура этих таблиц приведена в таблицах 8, 9 и 10 соответственно.

Таблица матчей – Match Таблица 8

(имя поля)

Примечание

Код матча (ключ)

Дата матча

Код команды хозяев

Код команды гостей

Таблица команд – Team Таблица 9

(имя поля)

Примечание

Код команды (ключ)

Название

Таблица голов – Goal Таблица 10

(имя поля)

Примечание

Код гола (ключ)

Код матча

Игрок, забивший гол

Признак команды, к которой принадлежит игрок: 1 – хозяин, 2 – гость.

Время (число минут от начала матча)

Таблицы создаются с помощью входящей в состав Delphi утилиты Database Desktop . Эта утилита позволяет создавать, просматривать и модифицировать таблицы баз данных различных форматов. Вызвать утилиту Database Desktop можно:

C:\Program Files\Common Files\Borland Shared\Database Desktop\dbd32.exe

Для создания таблицы в окне Database Desktop выполните команду File- New- Table ... Сначала в окне Create Table необходимо из раскрывающегося списка выбрать тип таблицы и нажать клавишу Ok . Пусть тип базы будет Paradox7 . После этого открывается новое окно (см. рисунок 5), в котором необходимо создать структуру таблицы Match .

Для каждого поля таблицы необходимо указать имя, тип, если нужно размер поля. Имя поля используется для доступа к данным. В качестве имени используется последовательность букв латинского алфавита и цифр длиной не более 25 символов. Для определения типа поля используйте клавишу пробел или правую клавишу мыши. Тип Alpha означает текстовый (строковый) тип поля. Для этого поля необходимо указать его длину. Для полей с типом Number , Date длину не указывают. Необходимо отметить признак ключевого поля ID_ M , установив символ «*» в графе Key .

Примечание

Ключевые поля должны быть сгруппированы в верхней части таблицы.

После завершения заполнения таблицы сохраните ее, нажав кнопку Save as ... В открывшемся окне Save Table As ... в поле Имя файла введите имя таблицы Match , а в поле Alias выберите созданный ранее псевдоним SPORT . Для завершения работы нажмите клавишу Save .

При создании полей таблиц можно использовать задание ограничений на значения полей, которое заключаются в указании для этих полей следующих параметров:

1. Требование обязательного ввода значений (Required Field );

2. Минимальное значение (Minimum value );

3. Максимальное значение (Maximum value );

4. Значение по умолчанию (Default value );

5. Маска ввода (Picture ).

На Рисунке 6 приведен пример заполнения поля PR_ G (Признак команды ), с указанием ограничений на значение поля.

Аналогично создайте и сохраните таблицы команд – Team и голов – Goal .

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

4.2. Создание форм

Создайте проект.

Таблица 10

Выделенная компонента

Окно инспектора объектов

Имя свойства

Действие

База данных СПОРТ

Сохраните модуль и проект под именами UnitGlavn и ProjectGlavn в папке База данных .

Создайте четыре формы с помощью команды File-New-Other. В открывшемся окне New Item выберите на вкладке New объект Form . Дайте имена формам и сохраните модули под именами, указанными в таблице.

Таблица 11

Название формы

Имя формы

Имя модуля

Список матчей

Список команд

Список голов

Поиск

На главную форму поместите пять кнопок:

Список матчей , Список команд , Список голов, Поиск, Выход .

Для каждой кнопки напишите соответствующую процедуру для открытия окна (см. таблицу 12).

Таблица 12

Выделенная компонента

Окно инспектора объектов

Имя свойства

Действие

Список матчей

FormMatch. Show;

Список команд

Список голов

Поиск

FormPoisk. Show;

Выход

В модуле главной формы после служебного слова implementation надо записать:

Uses UnitMatch, UnitTeam, UnitGoal, UnitPoisk;

Вернитесь к проекту.

4.3. Доступ к базе данных

Доступ к базе данных обеспечивают компоненты Database , Table и DataSource .

Компонент Database представляет базу данных как единое целое, т. е. совокупность таблиц, компонента Table – одну из таблиц базы данных. Компонента DataSource обеспечивает связь таблицы и компонента отображения или редактирования данных (см. рисунок 7).

4.4. Использование модуля данных

При конструировании формы невизуальные компоненты, используемые для доступа к данным, такие как DataSource или Table , размещаются на форме, но при выполнении приложения эти компоненты не видны. Поэтому их можно размещать в любом удобном месте формы, выступающей для них контейнером – модулем. Для размещения невизуальных компонентов, через которые осуществляется доступ к данным, предназначен специальный объект – модуль данных (см. рисунок 8).

Создайте новый объект DataModule , выполнив команду File- New- Data Module. Сохраните его модуль под именем UnitDModul в папке База данных .

На лист окна DataModule1 вставьте компонент Database (связь с сервером) со страницы BDE . В свойстве AliasName (имя псевдонима) выберите из списка: SPORT .

Добавьте в окно DataModule1 компоненты Table (набор данных) со BDE и DateSource (источник данных) со страницы Data Access и расположите их рядом друг с другом (см. рисунок 8).

Активизируем таблицу Match . Для этого установим свойства компонент Table1 и DataSource1 в том порядке, в каком они перечислены в таблице 13.

Таблица 13

Выделенная компонента

Окно инспектора объектов

Имя свойства

Действие

Примечание

TableMatch

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

Match. db

Имя файла данных, для доступа к которому используется компонент.

Признак активизации файла данных (таблицы). True – открытие файла.

DS_Match

Имя компонента для доступа к его свойствам.

TableMatch

Имя компонента – входные данные.

Выполните аналогичные действия для таблиц Список команд – Team и Список голов – Goal . В результате окно DataModule1 будет выглядеть так, как приведено на рисунке 9.

4.5. Навигация по таблицам базы данных

4.5.1. Форма Список команд

Активизируйте форму Список команд . Поместите на нее компонент DBGrid (таблица данных) со страницы Data Controls (управление данными). Для этого объекта следует прописать DataSource (источник данных). Откройте это свойство. Вы увидите, что выбирать пока не из чего. В модуле формы Список команд после служебного слова implementation запишите:

Uses UnitDModul ;

Снова откройте свойство DataSource и выберите в нем единственную имеющуюся запись: DataModule1 . DS_Team . Теперь компонент DBGrid и компонент DataSource связаны друг с другом. В компоненте DBGrid появились названия полей созданной таблицы Team .

Перейдите в окно DataModule1 и щелкните два раза мышью по объекту TableTeam . Откроется небольшое окно DataModule1 . DS_ Team . Щелкните на поле этого окна правой кнопкой мыши и в контекстном меню выберите строку Add all fields (добавить все поля).

Перейдите к форме Список матчей и выполните двойной щелчок на объекте DBGrid . Открылось окно Editing DBGrid1. Columns (редактор столбцов). Щелкните на поле этого окна правой кнопкой мыши и в контекстном меню выберите строку Add All Fields (добавить все поля). В окне Editing DBGrid1. Columns появится список всех полей таблицы. Щелкните мышью на одном из появившихся названий полей. Откройте свойство Title (название) и для каждого поля в

свойстве Caption запишите название: Код команды, Название команды, Город, Тренер (см. рисунок 10).

В результате этих действий русские названия полей отразятся в таблице Список матчей . Закройте окно Editing DBGrid1. Columns .

4.5.2. Перемещение по записям

Для перемещения указателя текущей записи в наборе данных используются следующие методы:

процедура First – установка на первую запись;

процедура Next – установка на следующую запись (для последней записи указатель не перемещается);

процедура Last – установка на последнюю запись;

процедура Prior – установка на предыдущую запись (для первой записи указатель не перемещается).

Delphi предоставляет возможность перемещаться по набору данных с помощью управляющих элементов, в качестве которых можно использовать компоненты DBGrid и DBNavigator . Управление этими элементами приводит к автоматическому вызову ранее перечисленных методов.

Перейдем на форму Список команд . Добавим на форму компонент DBNavigator (навигатор базы данных) со страницы Data Controls (управление данными). Навигатор содержит кнопки, обеспечивающие выполнение различных операций с набором данных путем автоматического вызова соответствующего метода. Состав кнопок определяется свойством VisibleButtons. На рисунке 11 представлен общий вид компоненты DBNavigator .

Кнопки навигатора выполняют следующие действия:

Таблица 14

Номер кнопки на рисунке

Обозначение кнопки

Действие

Перемещение к первой записи

Перемещение к предыдущей записи

Перемещение к следующей записи

Перемещение к последней записи

Вставка новой записи перед текущей

Удаление текущей записи

Редактирование текущей записи

Сохранение отредактированной информации в базе данных.

Отмена результата редактирования или добавления новой записи

Внесите изменения в свойства компонента DBNavigator .

Таблица 15

Выделенная компонента

Окно инспектора объектов

Имя свойства

Действие

(источник данных)

DataModule1 .DS _Team

(установление связи объектов)

(показать подсказку)

(подсказка)

Щелкнуть на кнопке с тремя точками, расположенными справа. В появившемся окне встроенного редактора String List Editor заменить английские на русские названия кнопок:

Первая запись

Предыдущая запись

Следующая запись

Последняя запись

Вставка записи

Удаление записи

Редактирование записи

Сохранение изменений

Отменить изменения

Обновить изменения

Завершить работу, щелкнув на кнопке OK.

Сохраните изменения и запустите проект. Убедитесь, что все работает.

4.5.3. Форма Список матчей

Активизируйте форму Список матчей . Поместите на нее компонент DBGrid и выполните аналогичные действия п.4.5.1 для таблицы Match .

По таблице можно перемещаться программно, без использования компоненты DBNavigator . Для этого внесем изменения в этот компонент, становим свойства, которые позволят использовать для навигации по таблице Match только четыре кнопки First, Prior, Next, Last (см. таблицу 12). Установите эти свойства в соответствии с рисунком 12.

Добавьте на форму компоненты Button (Изменить, Добавить, Удалить, Подтвердить, Отменить) , Label для вывода состояния записи (Просмотр, Удаление, Редактирование, Вставка) и CheckBox для включения или выключения режима редактирования, как показано на рисунке 13. А так же разместите на форме компоненты меток и рядом с ними соответствующие компоненты для редактирования полей.

Рисунок 13

При заполнении полей Команда – хозяин , Команда – гость таблицы Список матчей , целесообразно значения этих полей выбирать из списка. Если для поля задана таблица выбора, то в него можно ввести только значение, содержащееся в таблице выбора. Это гарантирует, что в поле не будет введено недопустимое значение. Для этого воспользуемся компонентом DBLookupComboBox , с помощью которого можно выбирать нужную информацию из таблицы Team .

Выполните действия, приведенные в таблице 16.

Таблица 16

Выделенная компонента

Окно инспектора объектов

Имя свойства

Действие

Дата матча

DBEdit1 со страницы Data Control

DataModule1.DS_Match

Команда - хозяин

DBLookupComboBox1

DataModule1.Ds_Match

DataModule1.DS_Team

Команда - гость

DBLookupComboBox2

DataModule1.DS_Match

DataModule1.DS_Team

Для того чтобы программа, которую мы будем писать, легко читалась, введем обозначения созданных кнопок и меток. Для этого необходимо изменить свойство Name у соответствующих компонентов (см. таблицу 17).

Таблица 17

Компонента

Условное обозначение

Свойство Name

Изменить

Добавить

Удалить

Подтвердить

Отменить

Закрыть

Состояние записи

Дата матча

TDBLookupComboBox

Команда - хозяин

TDBLookupComboBox

Команда - гость

Таблица

Режим редактирования

UnitMatch .

1. В разделе Use

DB, DBTables , Dialogs, ExtCtrls, DBCtrls, Grids, DBGrids, StdCtrls, Mask;

2. А в разделе описания переменных перед implementation должна быть запись:

FormSpisok: TFormSpisok;

3. После записи {$R *.dfm} вставим две вспомогательные процедуры:

procedure TFormMatch. StateChange(Sender: TObject);

btnEdit. Enabled:=false;

btnInsert. Enabled:=false;

btnDelete. Enabled:=false;

btnChangeOK. Enabled:=true;

procedure TFormMatch. StateBrowse(Sender: TObject);

cbCanEditClick(Sender);

btnChangeOK. Enabled:=False;

4. Перед разделом private { Private declarations }в раздел описания Type вставим две строки:

procedure StateChange(Sender: TObject);

procedure StateBrowse(Sender: TObject);

5. Для каждой кнопки напишите соответствующую процедуру.

BtnEdit – Изменить – OnClick

DataModule1.DS_Match. Dataset. Edit;

lblChangeKind. Font. Color:=clTeal;

lblChangeKind. Caption:="РЕДАКТИРОВАНИЕ ЗАПИСИ";

StateChange(Sender);

BtnInsert – Добавить – OnClick

Var Nomer: Integer;

// Подтверждение в режим вставки

If MessageDlg("Добавить запись?",

<> mrYes then Exit;

DataModule1.DS_Match. Dataset. Last;

Nomer:=DataModule1.DS_Match. Dataset. FieldByName("ID_M").AsInteger;

DataModule1.DS_Match. Dataset. Append;

// Номер матча формируется автоматически, путем увеличения номера в последней записи

DataModule1.DS_Match. Dataset. FieldByName("ID_M").AsInteger:=Nomer+1;

lblChangeKind. Font. Color:=clGreen;

lblChangeKind. Caption:="ВСТАВКА ЗАПИСИ";

StateChange(Sender);

if DbeDat. CanFocus then DbeDat. SetFocus;

BtnDelete – Удалить – OnClick

// Запрос на подтверждение перехода в режим просмотра удаляемой записи

If MessageDlg("Удалить запись?",

mtConfirmation, , 0) <> mrYes then Exit;

lblChangeKind. Font. Color:=clRed;

lblChangeKind. Caption:="УДАЛЕНИЕ ЗАПИСИ";

StateChange(Sender);

if btnChangeCancel. CanFocus then btnChangeCancel. SetFocus;

B tnChangeOK – Подтвердить – OnClick

// Утверждение изменений в текущей записи (редактируемой или новой)

// или удаления текущей записи (просматриваемой)

If DataModule1.TableMatch. State in

// Проверка заполнения полей

If dbeDat. Text="" then

MessageDlg("Не задана дата матча", mtError, , 0);

if DbeDat. CanFocus then DbeDat. SetFocus;

If DBLHost. Text="" then

MessageDlg("Не задана команда - хозяин", mtError, , 0);

if DBLHost. CanFocus then DBLHost. SetFocus;

If DBLGuest. Text="" then

MessageDlg("Не задана команда - гость", mtError, , 0);

if DBLGuest. CanFocus then DBLGuest. SetFocus;

DataModule1.TableMatch. Post

else if lblChangeKind. Caption="УДАЛЕНИЕ ЗАПИСИ"

then DataModule1.TableMatch. Delete;

StateBrowse(Sender);

B tnChangeCancel – Отменить – OnClick

// Если набор данных находился в режиме просмотра (при удалении записи),

// то никаких действий метод Cancel не выполняет

DataModule1.TableMatch. Cancel

StateBrowse(Sender);

BtnClose – Закрыть – OnClick

cbCanEdit – OnClick

var bm1: TBookmark;

// Запоминание положения текущей записи

bm1:=DataModule1.Ds_Match. Dataset. GetBookmark;

// Отключение отображения изменений данных в визуальных компонентах

DataModule1.Ds_Match. Dataset. DisableControls;

If not cbCanEdit. Checked then begin

DataModule1.TableMatch. ReadOnly:=true;

// Блокировка элементов, связанных с переходом

// в режиме изменения записей

btnEdit. Enabled:=false;

btnInsert. Enabled:=false;

btnDelete. Enabled:=false;

btnChangeCancel. Enabled:=false;

btnChangeOK. Enabled:=false;

lblChangeKind. Font. Color:=clBlue;

lblChangeKind. Caption:="ПРОСМОТР ЗАПИСИ";

DBEDat. Enabled:=false;

DBLHost. Enabled:=false;

DBLGuest. Enabled:=false;

DataModule1.TableMatch. Active:=false;

DataModule1.TableMatch. ReadOnly:=false;

DataModule1.TableMatch. Active:=true;

// Разблокирование элементов, связанных с переходом

// в режиме изменения записей

btnEdit. Enabled:=true;

btnInsert. Enabled:=true;

btnChangeCancel. Enabled:=true;

btnChangeOK. Enabled:=true;

DBEDat. Enabled:=true;

DBLHost. Enabled:=true;

DBLGuest. Enabled:=true;

// Если набор данных пуст, то удаление записей запрещено

If DataModule1.Ds_Match. Dataset. RecordCount>0

then btnDelete. Enabled:=true

else btnDelete. Enabled:=false;

// Возврат в текущую запись

then DataModule1.Ds_Match. Dataset. GotoBookmark(bm1);

If DataModule1.Ds_Match. Dataset. BookmarkValid(bm1)

then DataModule1.Ds_Match. Dataset. FreeBookmark(bm1);

// Включение отображения изменений данных в визуальных компонентах

DataModule1.Ds_Match. Dataset. EnableControls;

FormMatch – OnCreate

// Первоначально изменение записей запрещено

cbCanEdit. Checked:=false;

// Запрет автоматического перехода в режим редактирования

DataModule1.DS_Match. AutoEdit:=false;

DBGridMatch. Columns.ReadOnly:=True;

FormMatch – OnShow

// Исходное состояние управляющих элементов

StateBrowse(Sender);

4.5.4. Форма Список голов

Самостоятельно разработайте процесс заполнения и навигацию в форме Список голов .

4.5.5. Задание для самостоятельной работы

На форме Список матчей добавить для каждой команды (команда-хозяин, команда-гость) информацию о городе команды и фамилии тренера. На форме Список матчей в таблице матчей убрать (видимость) поле код матча. На форме Список команд добавить кнопку Закрыть форму.

На оценку 5

Самостоятельно разработать форму поиска матчей:

1. по дате

2. по команде.

Для найденного матча показать список всех забитых голов и общий счет.

Описать процесс создания формы по примеру данного проекта.

5. Список литературы

Добавьте на форму компоненты DBGrid, GroupBox (Найти) , Button (Поиск, Выход) , CheckBox (По фамилии, По факультету) , Edit для ввода ключевых значений для поиска по полям DAT и FAK , как показано на рисунке 14.

Рисунок 14

Для того, чтобы программа, которую мы будем писать, легко читалась, введем обозначения созданных кнопок и меток. Для этого необходимо изменить свойство Name у соответствующих компонентов.

Таблица 16

Компонента

Условное обозначение

Свойство Name

Поиск

Выход

Найти

По фамилии

По факультету

Для ввода фамилии

Для ввода факультета

Таблица

В окне редактора форм перейдите в форму UnitPoisk .

1. В разделе Use должны быть включены следующие стандартные модули:

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

DB ,Dialogs, StdCtrls, ExtCtrls, Grids, DBGrids;

2. Для поиска записей по полям служат методы Locate и Lookup, причем поля могут быть неиндексированными.

Функция Locate (const KeyFields: String;

const KeyValues: Variant;

Options: TLocateOptions): Boolean

ищет запись с заданными значениями полей. Если удовлетворяющие условиям поиска записи существуют, то указатель текущей записи устанавливается на первую из них и функция возвращает значение True. Список полей, по которым ведется поиск, задается в параметре KeyFields (поля разделяются точкой с запятой). Параметр KeyValues указывает значения полей для поиска. Параметр Options задает значения LoCaseInsensitive (регистр букв не учитывать) и LoPartialKey (допускается частичное совпадение значений).

3. Для кнопки Поиск напишите соответствующую процедуру.

BtnFind – Поиск – OnClick

procedure TFormPOISK. btnFindClick(Sender: TObject);

Var KeyFields: String;

KeyValues: Variant;

Options: TLocateOptions;

if not (cbFindDAT. Checked or cbFindFAK. Checked)

MessageDlg("Не заданы условия поиска!", mtInformation,,0);

//Поиск одновременно по двум полям DAT и FAK

if cbFindDAT. Checked and cbFindFAK. Checked

KeyFields:="DAT;FAK";

KeyValues:=VarArrayOf();

//Поиск по одному из полей

//По полю DAT

if cbFindDAT. Checked

KeyFields:="DAT";

KeyValues:=editDAT. Text;

//По полю FAK

if cbFindFAK. Checked

KeyFields:="FAK";

KeyValues:=editFAK. Text;

//Поиск выполняется независимо от регистра букв

//с возможностью частичного совпадения

Options:=;

//Запись не найдена

If not DataModule1.Ds_Spisok. Dataset. Locate(KeyFields, KeyValues, Options)

MessageDlg("Запись не найдена...", mtInformation, ,0);

Футбол — командный вид спорта, в котором целью является забить мяч в ворота соперника ногами или другими частями тела (кроме рук) большее количество раз, чем команда соперника. Является самым популярным видом спорта в мире. В качестве основы для базы данных Access Футбольная Команда был выбран футбольный клуб Спартак. Предметная область - футбольная команда. Цель – создание базы данных для хранения, поиска и ознакомления с информацией о игроках, играх, результатах игр, футбольных командах и т.д. В данной БД реализована возможность просмотреть бомбардиров клуба, вывести список легионеров ФК Спартак, выгрузить календарь игр, посмотреть статистику каждого игрока ФК Спартак, статистику игр. Также можно сформировать турнирную таблицу после каждого тура, просмотреть движение каждой команды в чемпионате РФПЛ в виде графика. При желании БД можно переделать под любой другой футбольный клуб.

База данных Access Футбольная Команда содержит 7 таблиц , 12 запросов, 8 форм + главная кнопочная форма, 7 отчетов. Данная база данных Access является учебной, подходит для дальнейшей оптимизации и доработки под собственные нужды.

Пояснительная записки нет!

Цель практических заданий – приобретение навыков анализа предметной области, проектирования базы данных, ее физической реализации в СУБД Access.
Результат выполнения работы представляется в виде базы Access, который должен содержать:
структуру спроектированных таблиц,
схему данных со связями между таблицами,
формы, обеспечивающих интерфейс пользователя,
запросы ,
отчеты,
главную кнопочную форму.

Таблица «Календарь 2016-2017» — База данных Access Футбольная Команда

Форма «Расписание игр» — БД Access Футбольная Команда

Форма «Игроки» — База данных Access Футбольная Команда

Форма «Итоги тура» — База данных Access Футбольная Команда

Отчет «Статистика игр команды» — База данных Access Футбольная Команда

Отчет «Статистика игроков 2016-2017» — БД Access Футбольная Команда

Отчет «Список легионеров» — База данных Access Футбольная Команда

Отчет «Турнирная таблица после N тура» — База данных Access Футбольная Команда

Отчет «Календарь 2016-2017» — База данных Access Футбольная Команда

Отчет «Движение по турам команды Спартак» — БД Access Футбольная Команда

Скачать базу данных (БД) MS Access; БД Access Футбольная Команда; Спартак; футбольный клуб; база данных access; бд access; субд access; базы данных access; access пример; программирование access; готовая база данных; создание база данных; база данных СУБД; access курсовая; база данных пример; программа access; access описание; access реферат; access запросы; access примеры; скачать бд access; объекты access; бд в access; скачать субд access; база данных ms access; субд access реферат; субд ms access; преимущества access; базу данных; скачать базу данных на access; базы данных; реляционная база данных; системы управления базами данных; курсовая база данных; скачать базу данных; база данных access скачать; базы данных access скачать;

Федеральное Агентство Железнодорожного Транспорта

Кафедра «Связь»

Курсовая работа.

Проектирование базы данных.

Работу выполнил:

студент гр. Ит-314

Медведев Н.В.

Работу проверил:

преподаватель

Пащенко М.А.

Екатеринбург,

Введение 3

Инфологическое проектирование 5

1.1. Описание предметной области 5

1.2. Описание информационных потребностей пользователей 5

1.3. Построение инфологической модели 6

Даталогическое проектирование 7

2.1. Выбор и характеристика СУБД 7

2.2. Построение даталогической модели 9

2.3. Создание базы данных 11

2.4. Заполнение БД 12

Заключение 17

Список использованной литературы 18

Введение.

Под базой данных понимается объективная форма представления и организации совокупности данных, систематизированная таким способом, чтобы эти данные могли быть найдены и обработаны с помощью ЭВМ.

Система управления базой данных - это совокупность языковых и программных средств, предназначенных для создания, ведения и коллективного использования БД.

Проектирование БД представляет собой сложный трудоемкий процесс отображения предметной области во внутреннюю модель данных. В процессе проектирования разрабатывается модели разных уровней архитектуры БД, проверяется возможность отображения объектов одной модели объектами другой модели.

При проектировании базы данных решаются две основных проблемы:

· Каким образом отобразить объекты предметной области в абстрактные объекты модели данных, чтобы это отображение не противоречило семантике предметной области, и было по возможности лучшим (эффективным, удобным и т.д.)? Часто эту проблему называют проблемой логического проектирования баз данных.

· Как обеспечить эффективность выполнения запросов к базе данных, т.е. каким образом, имея в виду особенности конкретной СУБД, расположить данные во внешней памяти, создание каких дополнительных структур (например, индексов) потребовать и т.д.? Эту проблему называют проблемой физического проектирования баз данных.

Рис.1 Этапы проектирования БД

Инфологическое проектирование

1.1 Описание предметной области

Предметная область определяется с помощью четырех основных составляющих:

Свойство

В данном курсовом проекте предметной областью является «спортивное общество», а точнее, те люди, которые интересуются футболом и следят за результатами игр.

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

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

1.2. Описание информационных потребностей пользователей

Основные пользователи этой базы данных это люди, интересующиеся футболом и следящие за результатами игр. При помощи БД они могут узнать какая команда более перспективна для ставок, а какая наоборот «темная лошадка». Можно просмотреть результаты игры отдельной команды в разных чемпионатах. По БД может быть составлен рейтинг команды. Узнать информацию о команде, о сыгранных матчах в определенное время.

Основными понятиями ER-модели являются сущность, связь и атрибут:

Сущность – это реальный или представляемый объект, информация о котором должна сохраняться и быть доступна. В диаграммах ER-модели сущность представляется в виде прямоугольника, содержащего имя сущности. При этом имя сущности - это имя типа, а не некоторого конкретного экземпляра этого типа.

Каждый экземпляр сущности должен быть отличим от любого другого экземпляра той же сущности (это требование в некотором роде аналогично требованию отсутствия кортежей-дубликатов в реляционных таблицах).

Связь – это графически изображаемая ассоциация, устанавливаемая между двумя сущностями. Эта ассоциация обычно является бинарной и может существовать между двумя разными сущностями или между сущностью и ей же самой (рекурсивная связь).

Связь представляется в виде линии. При этом над местом "стыковки" связи с сущностью ставится знак «∞» или буква «M», если для этой сущности в связи могут использоваться много (many) экземпляров сущности, и цифра «1», если в связи может участвовать только один экземпляр сущности.

Как и сущность, связь – это типовое понятие, все экземпляры обеих пар связываемых сущностей подчиняются правилам связывания.

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

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

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

Построение инфологической модели

Инфологическая модель для базы данных «Результаты игр футбольной команды» проектировалась, как модель «Сущность-связь».

Сущность – это класс однотипных объектов. Процесс деятельности фирмы идентифицирует такие сущности: Команда, Тренер, Члены команды, Матчи, Чемпионат.

Каждая из сущностей имеет свой набор атрибутов.

Рисунок 1. Диаграмма ER – типов.

Описание сущностей:

Команда, Тренер, Члены команды, Матчи, Чемпионат.

2. Даталогическое проектирование.

2.1. Выбор и характеристика СУБД

Система управления базой данных (СУБД) представляет собой набор программных средств, посредством которого осуществляется управление базой данных и доступ к данным.

К числу основных функций СУБД принято относить следующие:

1. Непосредственное управление данными во внешней памяти.

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

2. Управление буферами оперативной памяти.

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

3. Управление транзакциями.

Транзакция – это последовательность операций над БД, рассматриваемых СУБД как единое целое. Либо транзакция успешно выполняется и СУБД фиксирует (COMMIT) изменения БД, произведенные ею во внешней памяти, либо ни одно из этих изменений никак не отражается на состоянии БД.

4. Журнализация.

СУБД должна обеспечивать надежное хранение данных во внешней памяти, т.е. СУБД должна иметь возможность восстановить последнее согласованное состояние БД после любого аппаратного или программного сбоя.

5. Поддержка языков БД.

Для работы с БД используются специальные языки баз данных. Чаще всего выделяются 2 языка – язык определения данных (DDL) и язык манипулирования данными (DML). DDL служит, главным образом, для определения логической структуры БД, а DML, содержит набор операторов манипулирования данными. Во многих СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с БД. Стандартным языком реляционных СУБД является язык SQL. Язык SQL сочетает средства DDL и DML, т.е. позволяет определять схему реляционной БД и манипулировать данными.

В SQL используются следующие основные типы данных, форматы которых могут несколько различаться для разных СУБД:

INTEGER - целое число (обычно до 10 значащих цифр и знак);

SMALLINT - "короткое целое" (обычно до 5 значащих цифр и знак);

DECIMAL ( p , q ) - десятичное число, имеющее p цифр (0

FLOAT - вещественное число с 15 значащими цифрами и целочисленным порядком, определяемым типом СУБД;

CHAR ( n ) - символьная строка фиксированной длины из n символов (0

VARCHAR ( n ) - символьная строка переменной длины, не превышающей n символов (n>0 и разное в разных СУБД, но не меньше 4096);

DATE - дата в формате, определяемом специальной командой (по умолчанию mm/dd/yy); поля даты могут содержать только реальные даты, начинающиеся за несколько тысячелетий до н.э. и ограниченные пятым-десятым тысячелетием н.э.;

DOUBLE PRECISION - для научных вычислений 15 цифр точности.

NUMERIC ( p . s ) - численные значения содержат цифры от 0 до 9 и необязательные знак и десятичную точку.

Поэтому при проектировании БД выбор остановился на СУБД InterBase 6.0, как СУБД поддерживающей все основные выше перечисленные функции. Помимо этого InterBase 6.0 имеет следующие характеристики:

1. Повышенная производительность за счет развитой архитектуры

Сервер InterBase реализует архитектуру множественных поколений записей (MGA - Multi-Generational Architecture). MGA обеспечивает уникальные возможности использования версий, что ведет к высокой степени доступности данных как для пользователей, работающих с транзакциями, так и для пользователей, использующих приложения поддержки принятия решений. Механизм MGA в InterBase хорошо работает при оперативной обработке коротких транзакций (OLTP - On-Line Transaction Processing) и является уникальным для крупномасштабных реальных приложений, превосходя другие базы данных в области параллельного исполнения длительных транзакций для поддержки принятия решений. Механизм версий устраняет необходимость блокировки записей, к которым осуществляется доступ по чтению во время транзакции, делая их свободными от конфликтов доступа – доступ по чтению никогда не блокирует доступ по записи. В отличие от других баз данных, InterBase обеспечивает своевременные, устойчиво воспроизводимые результаты для каждого запроса без специального программирования. В результате достигается максимальная пропускная способность для всех пользовательских транзакций.

2. Многопотоковая архитектура

Сервер InterBase добавляет многопотоковую архитектуру к MGA, улучшая производительность и оптимизируя использование системных ресурсов, особенно при большом числе пользователей. Многопотоковая архитектура обеспечивает разделяемый кэш данных, сокращая число дисковых операций ввода-вывода для каждого запроса в приложении. Разделяемый кэш метаданных на сервере сокращает стоимость компиляции для запросов и делает выполнение хранимых процедур и триггеров более эффективным. Статистика по пользователям и по базе данных, хранимая сервером, полезна при диагностике критических точек производительности приложения.

3. Мощная поддержка различных типов данных

Многим приложениям (мультимедиа, научные, интернет – приложения), требуется возможность обработки неструктурированных данных. InterBase является первой реляционной базой данных, удовлетворившей это требование с помощью BLOB. Использование BLOB позволяет сохранять в базе данных аудио-, видео-, графическую и бинарную информацию. В современных приложениях фильтры BLOB используются для сжатия и трансформации данных. Разработка приложений и улучшенная производительность для научных приложений поддерживаются многомерными типами данных InterBase, обеспечивающими хранение до 16 измерений в одном поле базы данных.

4. Сигнализаторы событий

Сигнализаторы событий оповещают «заинтересованные стороны» о специфических измнениях, произошедших в базе данных. Приложение регистрирует интерес к событию и затем ждет без опроса базы данных оповещения о наступлении события. За счет устранения опроса сигнализаторы событий экономят системные ресурсы и обеспечивают масштабируемость приложений.

5. Эффективность использования ресурсов

Компактность ядра InterBase экономит драгоценное дисковое пространство для его последующего использования критически важными бизнес-приложениями. InterBase так же обеспечивает производительность, сравнимую с конкурирующими базами данных, при меньших требованиях к оперативной памяти для дополнительной экономии на стоимости памяти. Развертывание сервера состоит из одного исполняемого файла и представляет собой простой машинный процесс, что упрощает инсталляцию даже заказных приложений.

6. Строгое соблюдение индустриальных стандартов

InterBase придерживается строгого соответствия индустриальным стандартам для клиент-серверных вычислительных сред, таким как ANSI/SQL, Java, UNICODE и XDR (External Data Representation – внешнее представление данных). Наша приверженность критически важным технологическим стандартам означает, что вы можете сократить время, необходимое для разработки, внедрения и сопровождения ваших приложений на множестве платформ с гарантией немедленного достижения наивысшей производительности.

2.2. Построение даталогической модели

На этом этапе необходимо установить соответствие между сущностями и характеристиками предметной области и отношениями и атрибутами в InterBase 6.0. Для этого нужно каждой сущности и характеристикам поставить в соответствие набор отношений (таблиц) и их атрибутов (полей).

Ключ – это минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся. Каждая сущность обладает хотя бы одним возможным ключом. Один из них принимается за первичный ключ. При выборе первичного ключа следует отдавать предпочтение несоставным ключам или ключам, составленным из минимального числа атрибутов. Нецелесообразно также использовать ключи с длинными текстовыми значениями (предпочтительнее использовать целочисленные атрибуты). Атрибут или группа атрибутов, которые в рассматриваемой таблице не являются первичным ключом, а в связной таблице – являются, называется внешним ключом.

Таблица соответствий названий сущностей.

Таблица соответствий названий полей.

Рисунок 2. Даталогическая модель.

2.3. Создание базы данных .

Создание таблиц:

Таблица «Чемпионат »:

CREATE TABLE "CHEMP" ("KOD_CHEMP" INTEGER NOT NULL, "VID_CHEMP" VARCHAR(20), "VREMYA" DATE, PRIMARY KEY ("KOD_CHEMP"));

Таблица «Члены команды »:

CREATE TABLE "LUDI" ("KOD_CHEL" INTEGER NOT NULL, "FAMIL" VARCHAR(20), "IMYA" VARCHAR(20), "OTCHESTVO" VARCHAR(20), "TEL" VARCHAR(20), "KOD_KOMANDI" INTEGER NOT NULL, "NOMER" INTEGER NOT NULL);

ALTER TABLE "LUDI" ADD FOREIGN KEY ("KOD_KOMANDI") REFERENCES TEAM ("KOD_KOMANDI");

Таблица «Матчи»:

CREATE TABLE "MATCHI" ("KOD_K1" INTEGER NOT NULL, "KOD_K2" INTEGER, "OCHKI_1" INTEGER, "OCHKI_2" INTEGER, "KOMANDA_1" VARCHAR(20), "KOMANDA_2" VARCHAR(20), "KOD_KOMANDI" INTEGER NOT NULL, "VREMYA" DATE, "KOD_CHEMP" INTEGER NOT NULL, PRIMARY KEY ("KOD_KOMANDI", "KOD_CHEMP"));

ALTER TABLE "MATCHI" ADD FOREIGN KEY ("KOD_CHEMP") REFERENCES CHEMP ("KOD_CHEMP");

ALTER TABLE "MATCHI" ADD FOREIGN KEY ("KOD_K1") REFERENCES TEAM ("KOD_KOMANDI");

ALTER TABLE "MATCHI" ADD FOREIGN KEY ("KOD_K2") REFERENCES TEAM ("KOD_KOMANDI");

Таблица «Work1»:

CREATE TABLE "WORK1" ("KOD_KOMANDI" INTEGER NOT NULL, "KOD_TRENERA" INTEGER NOT NULL, PRIMARY KEY ("KOD_KOMANDI", "KOD_TRENERA"));

Таблица «Команда ».

CREATE TABLE "TEAM" ("KOD_KOMANDI" INTEGER NOT NULL, "STRANA" VARCHAR(20), "GOROD" VARCHAR(20), "GOD_OSN" DATE, "NAZVANIE" VARCHAR(20), PRIMARY KEY ("KOD_KOMANDI"));

Таблица «Тренеры ».

CREATE TABLE "TRENER" ("KOD_TRENERA" INTEGER NOT NULL, "FAMIL" VARCHAR(20), "IMYA" VARCHAR(20), "OTCHESTVO" VARCHAR(20), "TEL" VARCHAR(20), "ADRES" VARCHAR(20), PRIMARY KEY ("KOD_TRENERA"));

Таблица «Позиция ».

CREATE TABLE "POZITZIYA" ("KOD_POZITZII" INTEGER NOT NULL,

"POZITZIYA" VARCHAR(20), PRIMARY KEY ("KOD_POZITZII"));

2.4. Заполнение БД

Таблица «Чемпионат».

Таблица «Члены команд».

Таблица «Матчи».

Таблица «Команда».

Таблица «Тренер».

Таблица «Work1».

I. Однотабличные запросы:

1. Выводит всех футболистов у кого первая буква фамилии находится в промежутке от "А" до "Г":

select famil from ludi where famil >="А" and famil < "Г";

2. Выводит всех тренеров у кого первая буква фамилии находится в промежутке от "А" до "Р":

select famil from trener where famil >="А" and famil < "Р";

3. Выдает всех игроков команды Локомотив:

select famil, imya, otchestvo from ludi where kod_komandi=1;

II. Многотабличные запросы:

1 .Выводит тренеров каждой команды:

select nazvanie, famil from team, trener, work1 where team.kod_komandi=work1.kod_komandi and work1.kod_trenera=trener.kod_trenera;

2. Выводит таблицу игр всех чемпионатов:

select vid_chemp, komanda_1,komanda_2,ochki_1,ochki_1 from chemp, matchi where chemp.kod_chemp=matchi.kod_chemp;

3. Выводит футболистов, кто играет в каком клубе:

select famil, nazvanie from ludi, team where team.kod_komandi=ludi.kod_komandi;

………………………………………….

…………………………………………..

III. С использованием функций и вычисляемых значений:

1. Вычисляет количество играков команды Локомотв:

select count(*) kod_chel from ludi where kod_komandi=1;

2. Выводит команду основанную раньше всех:

select min(god_osn) from team;

3. Выводит какое количесво матчей сыграла команда Локомотив:

select count(*) from matchi where kod_k1=1 or kod_k2=1;

IV. С групповыми операциями

1. Выводит количество играков каждой команды:

selectnazvanie, count(famil) fromludi, teamwhereteam.kod_komandi=ludi.kod_komandigroupbynazvanie;

2. Выводит сколько игр сыграно в каждом чемпионате:

select vid_chemp, count(kod_chemp) from chemp, matchi where matchi.kod_chemp=chemp.kod_chemp group by vid_chemp;

Заключение

В результате выполнения курсового проекта была создана база данных по играм футбольных команд в разных чемпионатах. Были разработаны 10 различных запросов, таких как – однотабличные, многотабличные, запросы с функциями и запросы с групповыми операциями. В курсовом проекте представлены инфологическая и даталогическая модели базы данных. Данная база данных может применяться в букмекерских конторах для быстрого получения данных об играх той или иной команды.

Список использованной литературы

2. Э.К. Лецкий «Информационные технологии на железнодорожном транспорте», М.:УМК МПС России, 2000.