Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Министерство образования и науки Украины
Черниговский государственный технологический университет
Кафедра информационных и компьютерных систем
Программная система "Футбольный чемпионат"
Курсовая работа по дисциплине “Организация баз данных”
Выполнили
студенты гр. КИ-104А.Г. Войцеховский
А.Г. Райская
Руководитель
Ассистент М.В. Харченко
Чернигов 2013
Реферат
Курсовая работа, 86 с., рис.21, 9 источников, 2 приложения.
Цель разработки курсовой работы - реализовать приложение, которое позволит работать с БД, как посредсредством тонкого клиента, так и посредством настольного приложения.
Основным методом проектирования модулей приложения - использование UML - диаграмм. Таким образом, при наличии лицензионного программного обеспечения можно было экспортировать разработанные классы в среду Eclipse EE.
В процессе написания приложения были разработаны и созданы две фабрики DAOTourFirma и ServiceTourFirma для работы с сущностями. С помощью ServiceTourFirma была дополнительно реализована бизнес-логика.
Также была использована технология Servlet- и JSP-контейнера. Так как сервлеты и jsp-страницы вызываются через HTTP-протокол, то Servlet-контейнер и JSP-контейнер часто сопровождает еще один компонент - web-сервер, который тоже может быть написан на Java.
В качестве сервера был использован сервер Tomcat 6.0. Приложение было разработано с использованием комплекта JDK версии 1.7.
В ходе выполнения данной курсовой работы для работы с базой данных использовалась СУБД PostgerSQL 9.0. Была создана база данных, которая состоит из 9 таблиц. В каждой таблице уникальный первичный ключ является внешним. Это дополнительное служебное поле, добавленное к уже имеющимся информационным полям таблицы, единственное предназначение которого -- служить первичным ключом. Значения этого поля не образуется на основе каких-либо других данных из БД, а генерируются искусственно. Главное достоинство внешнего ключа состоит в том, что он никогда не изменяется, поскольку не является информативным полем таблицы
В ходе разработки было получено корпоративное приложение «Футбольный чемпионат» доведенное до уровня стабильной версии. Результат разработки оформлен в виде программного проекта, приводимого в приложении к курсовой работе.
Для своей работы корпоративное приложение требует минимально: 1024 Мб оперативной памяти, процессор не ниже Atom 1100 МГц и любой браузер. Требования к операционной системы - Windows, Unix.
Дальнейшее развитие работы возможно в сторону усовершенствования работы сессий.
Реферат
Курсовая работа, 86 с., 21 рис., 9 джерел, 2 додатка.
Об"єктом розробки є корпоративна програма, яка дозволяє працювати с БД, як за допомогою тонкого клієнту, так і за допомогою веб сервісів.
Основним методом проектування модулей програми - використання UML - діаграм. Таким чином при наявності ліцензійного програмного забезпечення можна було експортувати розлоблені класи в Eclipse EE.
В процесі написання програми були розроблені і створені дві фабрики DAOTourFirma и ServiceTourFirma для роботи із сутностями. З допомогою ServiceTourFirma була додатково реалізована бізнес-логіка.
Також була використана технологія Servlet- и JSP-контейнера. Так як сервлети и jsp-сторінки викликаються через HTTP-протокол, то Servlet-контейнер и JSP-контейнер часто супроводжує ще один компонент - web-сервер, який також може бути написан на Java.
В якості сервера був використаний сервер Tomcat 6.0. Программа була розроблена з використанням комплекта JDK версії 1.7.
У ході виконання даної курсової роботи для роботи з базою даних використовувалася СУБД PostgerSQL 9.0. Була створена база даних, яка складається з 9 таблиць. У кожній таблиці унікальний первинний ключ є зовнішнім. Це додаткове службове поле, додане до вже наявних інформаційних полях таблиці, єдине призначення якого - служити первинним ключем. Значення цього поля не утворюється на основі будь-яких інших даних з БД, а генеруються штучно. Головне достоїнство зовнішнього ключа полягає в тому, що він ніколи не змінюється, оскільки не є інформативним полем таблиці
В ході розробки було отримано корпоративну програму «Футбольний чемпіонат», яка була доведена до рівня стабільного релізу. Результат розробки оформлено у вигляді програмного проекту, який наводиться в додатку до курсової роботи.
Для своєї роботи корпоративна програма потребує мінімально: 1024 Мб оперативної памяті, процесор не нижче Atom 1100 МГц и будь-який браузер. Вимоги до операційної системи - Windows, Unix.
Подальший розвиток проекту можливий в сторону удосконалення роботи з сессіями.
Java, C#, ORM, JSP, JPA, SQL, Servlet, HTML, TAG, JS
The Abstract
Course project, 86 p., Pic.21, 9 sources, 2 of the annex.
The object is to develop an application that enables you to work with the database, as through a thin client or through a desktop application.
The basic method of designing application modules - use UML - diagrams. Thus, if software could be developed to export the classes in the environment Eclipse EE.
During the writing of applications have been developed and set up two factories DAOTourFirma and ServiceTourFirma to work with the entities. With ServiceTourFirma have been further implemented business logic.
In the course of the course work for the operation of the database used DBMS PostgerSQL 9.0. A database, which consists of 9 tables. In each table a unique primary key is external. This is an optional service field, added to the already existing information fields of the table, the only purpose of which - to serve as a primary key. The values of this field is not formed on the basis of any other data from the database, and generated artificially. The main advantage of the foreign key is that it never changes, because it is an informative table field.
Also, the technology has been used, and Servlet-JSP-container. Because servlets and jsp-pages are invoked via HTTP-protocol, Servlet-JSP-container and the container is often accompanied by another component - web-server, which can also be written in Java.
During the development of enterprise applications have been received «Football championat» brought to the level of beta. The result of the development of the form of a software project, contained in the annex to the course work.
For its corporate application requires a minimum: 1024 MiB of RAM, the CPU is not Atom below 1100 MHz and a browser. Requirements for the operating system - Windows, Unix.
Further development work is possible to improve work with session.
Java, C#, ORM, JSP, JPA, SQL, Servlet, HTML, TAG, JS
Введение
1. Анализ решаемой задачи
1.1 Анализ предметной области
1.2 Цели и задачи системы
1.3 Назначение системы
1.4 Требования к системе
2. Проектирование
2.1 Выбор инструментальных средств разработки системы
2.1.1 Сервер базы данных
2.1.2 Технологии реализации системы
2.2 Проектирование архитектуры системы
2.2.1 Проектирование слоя бизнес логики и бизнес правил
2.2.2 Проектирование слоя доступа к данным
2.2.3 Проектирование слоя отображения
3. Разработка
3.1 Разработка базы данных системы
3.1.1 Разработка схемы базы данных
3.1.2 Обеспечение целостности данных
3.1.3 Разработка базовых запросов
3.1.4 Создание ролей, выбор индексов и представлений
3.1.5 Разработка хранимых процедур и триггеров
3.1.6 Организация защиты данных
3.1.7 Объектно-реляционное отображение
3.2 Разработка модулей системы
3.2.1 Разработка модулей слоя бизнес-логики и бизнес-правил
3.2.2 Разработка модулей слоя доступа к данным
3.2.3 Разработка модулей слоя сервиса
3.2.4 Разработка модулей слоя отображения
Список использованных источников
Введение
В настоящее время компьютеры и Internet-технологии получили широкое распространение во всех сферах деятельности человека. Применение вычислительной техники обусловлено тем, что она существенно облегчает работу человека, при этом ускоряется время выполнения задачи и повышается надежность результата. Так как вычислительная техника работает под программным управлением, то ее функциональность зависит от используемого программного обеспечения. По этому, создаются различные корпоративные приложения узкой специализации.
Проектирование базы данных (БД) - одна из наиболее сложных и ответственных задач, связанных с созданием корпоративного приложения (enterprise application). В результате её решения должны быть определены содержание БД, эффективный для всех её будущих пользователей способ организации данных и инструментальные средства управления данными. Основная цель проектирования БД - это сокращение избыточности хранимых данных, а следовательно, экономия объема используемой памяти, уменьшение затрат на многократные операции обновления избыточных копий и устранение возможности возникновения противоречий из-за хранения в разных местах сведений об одном и том же объекте.
Корпоративное приложение представляет собой программное приложение, предназначенное для управления данными большого объема и их обработки по бизнес правилам позволяющее принести определенные преимущества корпорации (предприятию) при ее внедрении.
Корпоративным приложением неявляются средства обработки текста, регулирования расхода топлива в автомобильном двигателе, управление лифтами и оборудованием телефонной станции, автоматического контроля химических процессов, а также операционные системы, компиляторы, игры и т.д. Корпоративное приложение обычно подразумевает необходимость долговременного (иногда в течение десятилетий) хранения данных. Данные зачастую способны пережить несколько поколений прикладных программ, предназначенных для их обработки, аппаратных средств, операционных систем и компиляторов.
Множество пользователей обращаются к данным параллельно. Как правило, их количество не превышает сотни, но для систем, размещенных в среде Web, этот показатель возрастает на несколько порядков.
При больших объемах данных в приложении должен быть предусмотрен богатый пользовательский интерфейс.
Корпоративные приложения редко существуют в изоляции. Обычно они требуют интеграции с другими системами, построенными в разное время с применением различных технологий.
Корпоративные приложения, как правило, являются сложными программными системами.
1. Анализ решаемой задачи
1.1 Анализ предметной области
Футбольный чемпионат - соревнование по футболу. Соревнование такого вида проводится каждый год. Во время чемпионата между разными командами проходят матчи, результаты которых записываются в турнирную таблицу определенного отборочного тура. Следующим шагом чемпионата является проведение финального тура, список участвующих команд которого формируется из победителей отборочных туров. Когда все матчи финального тура сыграны, руководствуясь сведениями об количестве набранных очков, можно определить победителя чемпионата.
Футбольный чемпионат является массовым мероприятием, что в свою очередь гласит о необходимости наличия определенного внутреннего механизма, который бы координировал его прохождение. Таким образом можно выделить высший исполнительный орган - исполнительный комитет, который берет на себя всю ответственность по организации и проведению чемпионата. Он состоит из президента и других членов, избранных Конгрессом (высшим правящим органом определенного футбольного союза) чемпионата. Конгресс проводится ежегодно. Исполнительный комитет может инициировать второй Очередной Конгресс для решения финансовых вопросов и/или вопросов повышенной важности.
Срок полномочий для президента и членов исполкома, избранных Конгрессом, составляет определенное число лет. Все члены исполкома могут быть переизбраны. Не могут быть избраны или переизбраны только чиновники в очень пожилом возрасте. Если в составе исполкома освобождается место, то ближайший Очередной Конгресс выбирает замену до конца действующего срока полномочий. Если место освобождается во время последнего года полномочий члена исполкома, замена не выбирается.
Срок полномочий для президента и членов исполкома начинается по окончании Конгресса, на котором они избраны, и заканчивается по окончании Конгресса, на котором избран его преемник. Назначение женщины в члены исполкома на четыре года производится на учредительном собрании Исполнительного комитета.
Исполнительный комитет уполномочен утверждать нормативные документы и принимать решения по всем вопросам, не попадающим под юрисдикцию. Исполнительный комитет управляет деятельностью определенного футбольного союза за исключением тех случаев, когда исполком делегировал полномочия - либо они были делегированы Уставом - президенту или администрации футбольного союза.
Исполнительный комитет может делегировать обязанности по подготовке и воплощению решений или по ведению неких дел одному или нескольким своим членам. Исполком также уполномочен делегировать полномочия - частично или полностью - президенту, одному или нескольким своим членам и/или администрации.
Как правило, Исполнительный комитет собирается раз в два месяца, когда его созывает президент. Президент также может пригласить на встречу исполкома третьих лиц в качестве консультантов.
1.2 Цели и задачи системы
Целью системы «Футбольный чемпионат» является автоматизация процесса проведения чемпионатов. Данное приложение несёт информативный характер: позволяет автоматизировать подсчёт количества выигрышей, проигрышей и ничьей, а также начисление очков командам в соответствии с результатами проведения матча(3 очка - выигрыш, 2 - ничья, 1 - проигрыш). Приложение позволяет при помощи форм ввода-вывода добавлять новые, удалять и изменять данные турнирной таблицы. Есть возможность просмотра данных о работниках и о командах, а также просмотр 10 лучших команд и результаты матчем, которые были проведены в текучий день.
1.3 Назначение системы
Разрабатываемая в рамках данного курсового проекта система «Футбольный чемпионат» предназначена для всех пользователей, которые интересуются результатами проведённых матчей. Авторизация не является общей в нашей системе. Гость может не авторизироватся, а просто зайти и просмотреть информацию о чемпионате. Менеджер, президент и администратор должны ввести персональные данные для определения в системе. Под персональными данными подразумеваются логин и пароль. После подтверждения пользователем введенных данных программная система проверяет их истинность. Сначала проверяется логин, если он не найден в базе, система выдает сообщение о том, что пользователя с таким именем не существует. В случае, если имя корректно, проверяется контрольная сумма пароля. Если она не совпадает, то пароль неправильный. Для большей безопасности системы после вычисления контрольной суммы проверяется совпадение всего пароля. Если логин и пароль подлинные и подходящие и являются парой «значение-ключ», то пользователь входит в систему, при этом ему присваивается статус президента, администратора или же менеджера.
На рисунке 1.1 представлена диаграмма вариантов использования для роли Президент чемпионата
Рисунок 1.1 - Диаграмма вариантов использования для роли Президент чемпионата
После входа в систему президент имеет следующие возможности: управление кадрами и составления бюджета.
Вариант использования «Управления кадрами», включает в себя добавления записи о новом сотруднике а также при увольнении сотрудника, удаление соответствующей записи. Вариант использования «Составить бюджет» включает в себя добавления и удаление записей о зарплатах.
На рисунке 1.2 представлена диаграмма вариантов использования для роли Администратор
Рисунок 1.2 - Диаграмма вариантов использования для роли Администратор
После входа в систему администратор имеет следующие возможности: управлять учётными записями и проверить сообщение в базе.
Вариант использования «Управлять учётными записями» имеет следующий сценарий: Если это добавление нового пользователя, то заполнить соответствующую формулу и сохранить изменения; если это изменение или удаление пользователя, то нужно его сначала найти в базе, при удалении - уничтожить данные о пользователе, при изменении - скорректировать их и сохранить.
На рисунке 1.3 представлена диаграмма вариантов использования для роли Менеджер.
Рисунок 1.3 - Диаграмма вариантов использования для роли Менеджер
После входа в систему Менеджер имеет следующие возможности: заполнить, удалить или просмотреть записи в турнирной таблице.
На рисунке 1.4 представлена диаграмма вариантов использования для роли Гость.
Рисунок 1.4 - Диаграмма вариантов использования для роли Гость
После загрузки приложения гость может просматривать турнирную таблицу, узнавать информацию о матчах и о командах.
1.4 Требования к системе
Разрабатываемая в рамках данной курсовой работы система «Футбольный чемпионат» должна оперировать следующими объектами: страна, матч, работник, турнир. Нужно разработать такую систему, в которой пользователь имел бы возможность зарегистрироваться и модифицировать необходимую информацию.
На объекты и правила взаимодействия между объектами в системе накладываются определенные ограничения, совокупность которых называется бизнес-логикой.
Согласно бизнес-логике системы необходимо реализовать: автоматическое начисление очков командам в зависимости от выигрыша, проигрыша или ничьи в данном матче.
2. Проектирование
2.1 Выбор инструментальных средств разработки системы
В данном пункте будет выбран сервер баз данных, и посредством чего будет происходить связь пользователя с БД, так же будет выбрана технология реализации системы и архитектура.
2.1.1 Сервер базы данных
На данный момент существует огромное количество серверов баз данных таких как: MySQL, PostgreSQL, Microsoft Access и другие.
PostgreSQL - это объектно-реляционная система управления базами данных, работающая как клиент-серверная система. Основываясь на базовых понятиях реляционных БД, PostgreSQL поддерживает и ряд "объектных" операций, например, наследование. PostgreSQL соответствует базовой спецификации SQL99 и поддерживает большое число возможностей, описанных стандартом SQL92.
Oracle несколько превосходит PostgreSQL в таких вопросах как использование индексов, репликация и восстановление данных, да и вообще инструменты администрирования. Oracle более развиты (но вместе с тем и более сложны). С другой стороны, PostgreSQL предоставляет возможность использовать в качестве процедурного языка помимо PL/pgSQL (очень схожего с PL/SQL, используемым в Oralce), также PL/Perl, PL/Python, PL/Tcl, что позволяет разработчику выбрать более привычный инструмент.
В MySQL каждая таблица заносится в собственный файл (для большинства типов БД), организуея единую файловую структуру.
В MySQL акцент делается на наилучшую скорость чтения (выборки) данных, чем и объясняется популярность этой СУБД в среде веб-разработчиков, где выборка - основная операция. Достигается это отсутствием транзакций (они реализованы только для некоторых типов таблиц, например InnoDB, BerkleyDB) и многопоточной работой, однако это же и является причиной несколько меньшей надежности данной СУБД. В плане прав доступа MySQL позволяет задавать права доступа не только на уровне таблицы, но и на уровне столбца, однако в PostgreSQL это компенсируется возможностью создавать пользовательские представления.
Apache Derby это реляционная СУБД, написанная на Java, предназначенная для встраивания в Java-приложения или обработки транзакций в реальном времени. Занимает 2 MB на диске. Apache Derby разрабатывается как open source и распространяется на условиях лицензии Apache 2.0. Дерби был ранее известен как IBM Cloudscape. Sun распространяет те же бинарные файлы под именем Java DB.
В данной курсовой работе было использовано PostgreSQL - базы данных, требующие высокой степени надежности хранения информации, предъявляющие повышенные требования к проверке всех изменений, имеющие необходимость в автоматической корректировке большого числа данных при изменении информации в одной из таблиц, а также задачи, где требуется возможность разработки нетривиальных решений, использование нестандартных операторов и т.д.
2.1.2 Технологии реализации системы
JSP (JavaServer Pages) -- технология, позволяющая веб-разработчикам легко создавать содержимое, которое имеет как статические, так и динамические компоненты. По сути, страница JSP является текстовым документом, который содержит текст двух типов: статические исходные данные, которые могут быть оформлены в одном из текстовых форматов HTML, SVG, WML, или XML, и JSP элементы, которые конструируют динамическое содержимое. Кроме этого могут использоваться библиотеки JSP тегов, а также EL (Expression Language), для внедрения Java-кода в статичное содержимое JSP-страниц.
JSP -- одна из высокопроизводительных технологий, так как весь код страницы транслируется в java-код сервлета с помощью компилятора JSP страниц Jasper, и затем компилируется в байт-код виртуальной машины java (JVM). Контейнеры сервлетов, способные исполнять JSP страницы, написаны на языке Java, который может работать на различных платформах. JSP страницы загружаются на сервере и управляются из структуры специального Java server packet, который называется Java EE Web Application, в большинстве своём упакованные в файловые архивы.war и.ear.
Выгода, которую дает технология JSP в сравнении с другими веб-технологиями заключается в том, что JSP является платформонезависимой, переносимой и легко расширяемой технологией для разработки веб-приложений.
JSP 2.0 это новая версия спецификации JSP дополнена функциональностью увеличивающей скорость работы программиста. А именно:
– Expression Language (EL) -- язык выражений, позволяет среди прочего создавать разработчикам шаблоны в стиле Velocity;
– более простой и быстрый способ создавать новые теги с помощью файлов.tag, теперь для создания новых тегов не обязательно знать Java;
– удобный способ управления вложеными бинами (JavaBeans);
– более быстрый и лёгкий способ отображения параметров переменных.
Сервлет является Java-интерфейсом, реализация которого расширяет функциональные возможности сервера. Сервлет взаимодействует с клиентами посредством принципа запрос-ответ.
Хотя сервлеты могут обслуживать любые запросы, они обычно используются для расширения веб-серверов. Для таких приложений технология Java Servlet определяет HTTP-специфичные сервлет классы.
JSTL(JavaServer Pages Standard Tag Library) -- в переводе с английского «стандартная библиотека тегов JSP». Она расширяет спецификацию JSP, добавляя библиотеку JSP тегов для общих нужд, таких как разбор XML данных, условная обработка, создание циклов и поддержка интернационализации. JSTL -- конечный результат JSR 52, разработанного в рамках JCP(Процесса Java сообщества).
JSTL является альтернативой такому виду встроенной в JSP логики, как скриплеты, то есть прямые вставки Java кода. Использование стандартизованного множества тегов предпочтительнее, поскольку получаемый код легче поддерживать и проще отделять бизнес-логику от логики отображения.
Java Persistence API (JPA) -- API, входящий с версии Java 5 в состав платформ Java SE и Java EE, предоставляет возможность сохранять в удобном виде Java-объекты в базе данных.
Существует несколько реализаций этого интерфейса, одна из самых популярных использует для этого Hibernate.
Поддержка сохранности данных, предоставляемая JPA , покрывает области:
– непосредственно API, заданный в пакете javax.persistence;
– платформо-независимый объектно-ориентированный язык запросов Java Persistence Query Language;
– метаинформация, описывающая связи между объектами;
– генерация DDL для сущностей.
2.2 Проектирование архитектуры системы
слой база данных модуль servlet
Архитектура системы будет такой, какая приведена в анализе (рисунок 1.1) и методах решения задачи.
Роль слоя интеграции (слоя источника данных) состоит в том, чтобы обеспечить возможность взаимодействия приложения с различными компонентами инфраструктуры для выполнения необходимых функций. Главная составляющая подобной проблемы связана с поддержкой диалога с базой данных -- в большинстве случаев реляционной. Одной из самых серьезных причин успеха реляционных систем является поддержка ими SQL -- наиболее стандартизованного языка коммуникаций с базой данных.
Способ реализации слоя интеграции зависит от взаимодействия бизнес логики с базой данных. Выбор, который делается на этом этапе, имеет далеко идущие последствия и отменить его бывает трудно или даже невозможно.
Поэтому он заслуживает наиболее тщательного осмысления. Нередко подобными решениями как раз и обусловливаются варианты компоновки бизнес - логики.
Разумнее обособить код SQL от бизнес логики, разместив его в специальных классах. Удачный способ организации подобных классов состоит в "копировании" структуры каждой Объекты базы данных в отдельном классе, который формирует шлюз, поддерживающий возможности обращения к таблице. Теперь основному коду приложения нет необходимости что-либо "знать" о SQL, а все SQL-операции сосредоточиваются в компактной группе классов. Более удачный вариант состоит в том, чтобы изолировать модель предметной области от базы данных, возложив на промежуточный слой всю полноту ответственности за отображение объектов домена в Объекты базы данных. Подобный преобразователь данных обслуживает все операции загрузки и сохранения информации, инициируемые бизнес-логикой, и позволяет независимо варьировать как модель предметной области, так и схему базы данных. Это наиболее сложное из архитектурных решений, обеспечивающих соответствие между объектами приложения и реляционными структурами, но его неоспоримое преимущество заключается в полном обособлении двух слоев.
На сегодняшний день Java разработчики могут воспользоваться уже имеющимися средствами: сериализация, средства объектно - реляционного отображения, объектные базы данных и EJB. Каждое из этих средств имеет свои области применения и, следовательно, некоторые недостатки. JDO позволяет устранить эти недостатки и обеспечивает большую прозрачность.
Сериализация . Встроенный Java-механизм, обеспечивающий преобразование объектов в последовательность байт, которые могут быть сохранены в файл или переданы по сети. Сериализация очень проста в использовании, но и весьма ограниченна. При использовании сериализации объект сохраняется как одно целое. Она не поддерживает транзакции, а так же использование одного и того же сериализованного объекта в различных потоках или программах без возникновения конфликтов между ними;
Объектно-реляционное отображение(JPA). JPA не является новой технологией, а, скорее, это собрание идей лучших из имеющихся технологий, таких как Hibernate, TopLink и JDO. Как результат JPA является стандартизованной спецификацией входящей в J2EE5, что позволяет строить слой сохранения данных независимо от каких-либо конкретных провайдеров. Т.е. реализаций спецификации JPA может быть много, одной из таких, например, является фреймворк OpenJPA или тот же Hibernate.
Объектные базы данных . Объектные базы данных были специально разработаны для хранения объектов и полностью вписываются в концепцию объектно-ориентированного программирования. Object Database Management Group (ODMG) была создана для разработки единого API для работы с такими базами. Однако, многие поставщики баз данных все еще не решаются перейти с хорошо себя зарекомендовавшей реляционной системы на объектно - ориентированную. Так же меньшее число средств анализа данных доступно для объектных баз и очень большое количество данных уже сохранено в реляционных базах. По этим причинам, а так же по множеству других, объектные базы данных не нашли такого широкого применения, на которое надеялись их создатели;
Enterprise Java Beans (EJBs) . EJB представляют собой компоненты, которые хранят свое состояние в реляционной базе данных и обеспечивают объектно-ориентированное отображение постоянных данных. В отличие от продуктов объектно-реляционного отображения, EJB имеют жесткую спецификацию, что делает возможным использование продуктов от различных поставщиков. К сожалению, EJB стандарт ограничен в объектно-ориентированном отношении. Они не поддерживают наследование, полиморфизм и т.п. Так же EJB компоненты требуют больших затрат для их написания и часто специального программного обеспечения для их работы.
На сегодняшний день существуют различные фреймворки, использующие данную технику программирования. Вот некоторые из них:
Hibernate, iBATIS, Java Data Objects (JDO), JPOX, Cayenne, TopLink, JPA.
При организации ORM с использованием различных технологий необходимо создать файлы отображения объектов; создать конфигурационные файлы, в которых указываются файлы ресурсов, источники данных, поддержка транзакций и т.д.
2.2.1 Проектирование слоя бизнес логики и бизнес правил
Принцип работы данной системы:
Администратор заносит данные о работниках, чемпионатах, командах;
Пользователи просматривают турнирную таблицу и информацию о чемпионатах;
Регистрируются не обязательнаю, она необходима только для модификации данных;
Была созданная дополнительная таблица для реализации связи много-ко-многим. zakaz_dop_uslugi (связывает заказ с дополнительными услугами).
Следовательно, можно спроектировать такие классы домена (рисунок 2.4).
Рисунок 2.4 - Классы домена
Согласно бизнес-логике системы необходимо автоматически начислять очки за проигрыши, выигрыши и ничьи соответственно.
2.2.2 Проектирование слоя доступа к данным
Для доступа к данным, хранящимся во внешнем хранилище, удобнее всего определить отдельные интерфейсы с методами для манипуляции данными. Реализация этих интерфейсов может быть любая, например, использующая JDBC или JPA, JAXB или даже простые Java-коллекции. В качестве упращения данного курсового проекта был выбран JPA. Для того, чтобы можно было использовать разные реализации интерфейсов доступа к данным удобно применить шаблон проектирования "Абстрактная фабрика" или "Фабричный метод". В данном случае такой фабрикой выступает абстрактный класс DAOFactory, который содержит определение абстрактных методов, возвращающих реализации интерфейсов(рисунок 2.4).
Среди всех операций доступа к данным можно отчетливо выделить базовые CRUD (create, read, update, delete) опреации - создание объекта, удаление объекта, обновление объекта, получение объекта по идентификатору, и получение всех объектов. Вынесение таких операций в отдельный супер класс позволит избежать дублирования кода. Такие базовые операции также были вынесены в отдельный базовый интерфейс IGenericDao
Рисунок 2.4 - Диаграмма классов DAO
2.2.3 Проектирование слоя отображения
Данный слой представляет собой тонкий клиент.
Для работы с приложением были созданы страниц, который обеспечивают вывод, добавление, редактирование и удаление данных. Главная страница, на которую попадает незарегестрированный пользователь, index.jsp. Также были созданы дополнительные странички для добавления и редактирования данных, но только на правах администратора.
3. Разработка
3.1 Разработка базы данных системы
3.1.1 Разработка схемы базы данных
Исходя из анализа, проектирования слоя бизнес логики и правил, структуру БД можно сделать следующей (рисунок 3.1)
Рисунок 3.1 - Логическая схема БД
Физическая схема БД показана на рисунке 3.2
Рисунок 3.2 - Физическая схема БД
В базе данных программной системы содержится вся информация относительно её объектов, а именно:
Турнирная таблица;
Команды;
Пользователь;
Работник;
Зарплата;
Чемпионат.
В каждой таблице уникальный первичный ключ является внешним. Это дополнительное служебное поле, добавленное к уже имеющимся информационным полям таблицы, единственное предназначение которого -- служить первичным ключом. Значения этого поля не образуется на основе каких-либо других данных из БД, а генерируются искусственно. Главное достоинство внешнего ключа состоит в том, что он никогда не изменяется, поскольку не является информативным полем таблицы (не несёт никакой информации об описываемом записью объекте). Использовать внешний ключ имеет смысл в случае, когда возможны изменения полей, составляющих (естественный) первичный ключ. В этом случае возникает проблема так называемых "каскадных изменений". При использовании же внешнего ключа в качестве первичного, изменять его не придётся. Также, при выполнении запросов, использующих внешние ключи, сравнение полей будет происходить быстрее, в особенности, если естественный первичный ключ представляет собой строку.
3.1.2 Обеспечение целостности данных
Ограничения целостности приведены в таблице 3.1
Таблица 3.1 - Описание таблиц БД
|
Название таблицы |
Описание |
Тип данных |
Ограничение |
||
|
идентификационный код работника |
Первичный ключ |
||||
|
Адрес работника |
строка, 20 символов |
обязательное для ввода |
|||
|
Дата рождения |
строка, 20 символов |
обязательное для ввода |
|||
|
Фамилия, имя. Отчество работника |
строка, 60 символов |
обязательное для ввода; |
|||
|
Телефонный номер работника |
Строка 20 символов |
обязательное для ввода |
|||
|
Внешний ключ пользователя |
целое число |
||||
|
Внешний ключ чемпионата |
целое число |
для ввода; уникальных значений |
|||
|
идентификационный код матча |
Первичный ключ |
||||
|
Дата проведения матча |
строка, 20 символов |
обязательное для ввода |
|||
|
Команда играющая в гостях |
строка, 20 символов |
обязательное для ввода |
|||
|
Принимающая команда |
строка, 20 символов |
обязательное для ввода |
|||
|
Счет игры |
строка, 20 символов |
||||
|
Номер тура |
целое число |
обязательное для ввода |
|||
|
Внешний ключ команды |
целое число |
для ввода; уникальных значений |
|||
|
идентификационный код пользователя |
Первичный ключ |
||||
|
Логин для входа на сай |
строка, 20 символов |
обязательное для ввода |
|||
|
Пароль для входа на сай |
строка, 20 символов |
обязательное для ввода |
|||
|
Внешний ключ роли |
целое число |
для ввода; уникальных значений |
|||
|
идентификационный код таблицы |
Первичный ключ |
||||
|
Количество матчей, сыгранных в ничью |
целое число |
обязательное для ввода |
|||
|
Количество очков за матч |
целое число |
обязательное для ввода |
|||
|
Количество проигранных матчей |
целое число |
обязательное для ввода |
|||
|
Количество выигранных матчей |
целое число |
обязательное для ввода |
|||
|
идентификационный код зарплаты |
Первичный ключ |
||||
|
Количество выработанных часов |
целое число |
обязательное для ввода |
|||
|
Размер премии |
Вещественный тип данных |
||||
|
Размер штрафа |
Вещественный тип данных |
||||
|
Внешний ключ работника |
целое число |
для ввода; уникальных значений |
|||
|
идентификационный код права |
Первичный ключ |
||||
|
Внешний ключ роли |
целое число |
для ввода; уникальных значений |
|||
|
Действие, которое может выполнять указанная роль |
строка, 30 символов |
для ввода; уникальных значений |
|||
|
идентификационный код роли |
Первичный ключ |
||||
|
строка, 30 символов |
обязательное для ввода |
||||
|
идентификационный код команды |
Первичный ключ |
||||
|
Название города |
строка, 20 символов |
обязательное для ввода |
|||
|
Название команды |
строка, 20 символов |
обязательное для ввода |
|||
|
ФИО тренера |
строка, 60 символов |
обязательное для ввода |
|||
|
Внешний ключ таблицы |
целое число |
обязательное для ввода |
|||
|
идентификационный код чемпионата |
Первичный ключ |
||||
|
Дата проведения чемпионата |
обязательное для ввода |
||||
|
Название страны |
строка, 40 символов |
обязательное для ввода |
|||
|
Внешний ключ таблицы |
целое число |
обязательное для ввода |
3.1.3 Разработка базовых запросов
При разработке базовых запросов, JPQL был выбран языком разработки.
Ниже приведено описание основных запросов, их реализация приведена в приложении А.
getKomandasByTablicaId - запрос на выборку значений из таблицы «Команда», где id таблицы - параметр для получения команды.
findKomandaByName- запрос на выборку команды, где name таблицы - параметр для получения команды.
getTablicaByChempionatId - запрос на выборку значений из таблицы «Таблица», где id чемпионата - параметр для получения таблицы.
getKomandasByTablicaId - запрос на выборку значений из таблицы «Команда», где id таблицы - параметр для получения таблицы.
findUserByNameAndPassword- запрос на выборку значений из таблицы «Пользователь», где login пользователя равно первому параметру, а password второму.
getWorkerByChempionatId- запрос на выборку значений из таблицы «Работник», где id чемпионата - параметр для получения работника.
getZarplatasByWorkerId - запрос на выборку значений из таблицы «Зарплата», где id работника - параметр для получения зарплаты.
3.1.4 Создание ролей, выбор индексов и представлений
Роли:
Были созданы несколько ролей с различными правами доступа к базам данных:
Create role "admin" LOGIN UNENCRYPTED PASSWORD "qwerty"
Create role "manager" LOGIN UNENCRYPTED PASSWORD "qwerty1"
Create role "director" LOGIN UNENCRYPTED PASSWORD "qwerty2"
Права доступа к отношениям chempionat, komanda, matchi, prava, "role", tablica, users, worker, zarplata могут быть описаны следующим образом:
grant select, delete, insert, update on chempionat, komanda, matchi, prava, "role", tablica, users, worker, zarplata to admin
grant select, delete, insert, update on tablica, matchi, komanda to manager
Индексы:
При выборе индексов главным критерием было, частое обращение к определенному полю
Для повышения эффективности работы с данными были созданы индексы для полей часто используемых при выборке данных:
create index i_worker on worker(id);
create index i_komanda on komanda(id);
create index i_matchi on matchi(id);
create index i_zarplata on zarplata(id)
Представления:
Для реализации частичного доступа к таблице tablica было создано следующее представление:
create view w_guest (kolnichiyih,kolocheck,kolproigrashey,kolviigrashey,idchampionata) as
select kolnichiyih, kolocheck, kolproigrashey, kolviigrashey, idchampionata from tablica ;
create role guest LOGIN UNENCRYPTED PASSWORD "qwerty3"
grant select on w_guest to guest
3.1.5 Разработка хранимых процедур и триггеров
Триггеры:
1) Триггер, который вносит значение в поле premiya при добавлении записи в таблицу Zarplata. Если значение поля kolChasov превышает определенное значение.
CREATE OR REPLACE FUNCTION ins()
RETURNS trigger AS
UPDATE "zarplata"
SET "premiya" =("kolchasov" - 176)*100
From "zarplata", "worker"
where ("kolchasov" >8);
LANGUAGE "plpgsql";
CREATE TRIGGER trig_11 AFTER INSERT ON "zarplata"
FOR EACH ROW EXECUTE PROCEDURE ins();
2) Триггер, который добавляет запись в поле сумма таблицы зарплата, при добавлении или обновлении записи в таблице. Значение этого поля определяется значением полей ставка, штраф и премия.
create or replace function addSumInZarplata()returns trigger as
declare shtr float:=(select shtraf from zarplata where id=new.id);
declare prem float:=(select premiya from zarplata where id=new.id);
declare s float:= (select summa from zarplata where id=new.id);
update zarplata set
summa = s+prem-shtr where id=new.id;
language plpgsql;
create trigger trigAddSumZarplat
on zarplata for each row
execute procedure addSumInZarplata();
Хранимые процедуры :
1) Разработать хранимую процедуру, которая будет возвращать список матчей, которые должны состояться сегодня. Входные параметры отсутствуют. Выходным параметром будет таблица матчей.
CREATE OR REPLACE FUNCTION func_1()
RETURNS TABLE(id integer, gost character varying(30), hozain character varying(30),
schet character varying(10), tur integer, idkomandy integer, data date) AS $$
SELECT * FROM "matchi" WHERE "data" = timenow()::date; $$
2) Разработать хранимую процедуру, которая будет возвращать название команды, которая набрала наименьшее количество очков в определённом чемпионате. Входные параметры - название страны. Выходным параметром будет название команды.
CREATE OR REPLACE FUNCTION func_2(strana character varying(40))
SELECT "name" FROM "komanda", "tablica", "chempionat" WHERE "komanda"."idtablici" = "tablica"."id" AND "kolocheck" IN (SELECT MIN("kolocheck") FROM "tablica") AND "idchampionata" IN (SELECT "id" FROM "chempionat" WHERE "strana" = $1); $$
3) Разработать хранимую процедуру, которая будет возвращать top-10 команд турнирной таблицы. Входные параметры - название страны. Выходным параметром будет таблица, состоящая из названий 10-ти лучших команд и их количества очков.
CREATE OR REPLACE FUNCTION func_3(strana character varying(40))
RETURNS TABLE(_name character varying(20), kolocheck integer) AS $$
WITH subquery AS (SELECT "name", "kolocheck" FROM "komanda", "tablica", "chempionat" WHERE "komanda"."idtablici" = "tablica"."id" AND "idchampionata" IN (SELECT "id" FROM "chempionat" WHERE "strana" = $1) GROUP BY 1, 2 ORDER BY "kolocheck" DESC)
SELECT * FROM "subquery" GROUP BY 1, 2 HAVING COUNT("name") <= 10; $$
4) Разработать хранимую процедуру, которая будет возвращать название команды лидера турнирной таблицы определенного чемпионата. Входные параметры - название страны. Выходным параметром будет название лидера.
CREATE OR REPLACE FUNCTION func_5(strana character varying(40))
RETURNS character varying(20) AS $$
SELECT "name" FROM "komanda", "tablica", "chempionat"
WHERE "komanda"."idtablici" = "tablica"."id" AND "kolocheck" IN (SELECT MAX("kolocheck") FROM "tablica") AND "idchampionata" IN (SELECT "id" FROM "chempionat" WHERE "strana" = $1); $$
3.1.6 Организация защиты данных
В разработанной системе имеется несколько ролей и для каждой них в программной системе «Футбольный чемпионат» разный функционал. Возможности каждого из видов пользователей в данной программной системе приведены в таблице 3.2
Таблица 3.2- Защита данных
|
Пользователь/ Страница |
Администратор |
Зарегистрированный пользователь |
Незарегистрированный пользователь |
|
|
Просмотр списка чемпионатов, список мачей, проведённых в текущий день,турнирной таблицы, переход по страницам, изменение данных таблицы чемпионата |
Просмотр списка чемпионатов, список мачей, проведённых в текущий день турнирной таблицы, переход по страницам, переход на страницу личной информации |
Просмотр списка чемпионатов, список мачей, проведённых в текущий день турнирной таблицы переход по страницам, возможность регистрации |
||
|
Редактирование данных таблицы |
Просмотр турнирной таблицы, детальной информации о команде, топ 10 команд, лучшую и худшую команду |
Просмотр турнирной таблицы, детальной информации о команде, топ 10 команд, лучшую и худшую команду |
||
|
addEdtKomanda.jsp |
Редактирование данных о команде |
|||
|
Просмотр детальной информации о команде |
Просмотр детальной информации о команде |
|||
|
Просмотр матчей, добавление, удаление, редактирование |
Просмотр матчей, изменение данных матча |
Просмотр матчей |
||
|
Добавление, удаление, изменение прав |
||||
|
Просмотр зарплаты |
Просмотр, редактирование зарплаты |
3.1.7 Объектно-реляционное отображение
При разработке программы осуществляется доступ к данным, поэтому для упрощения разработки такой программы и для увеличения эффективности и скорости работы с полученными данными использовалось объектно-реляционное отображение.
Объектно-реляционное отображение (ORM) - это техника программирования, которая связывает реляционную базу данных с концепциями объектно-ориентированного программирования и создает «виртуальную базу данных объектов».
ORM автоматически синхронизируют загруженные в память объекты с базой данных. Для того чтобы это было возможным, после создания объект-в-SQL-преобразующего SQL-запроса полученные данные копируются в поля объекта, как во всех других реализациях ORM.
Системы управления реляционными базами данных показывают хорошую производительность на глобальных запросах, которые затрагивают большой участок базы данных, но объектно-ориентированный доступ более эффективен при работе с малыми объёмами данных, так как это позволяет сократить семантический провал между объектной и реляционной формами данных.
Все системы ORM обычно проявляют себя в том или ином виде, уменьшая в некотором роде возможность игнорирования базы данных. Более того, слой транзакций может быть медленным и неэффективным (особенно в терминах сгенерированного SQL). Все это может привести к тому, что программы будут работать медленнее и использовать больше памяти, чем программы, написанные «вручную».
Но ORM избавляет программиста от написания большого количества кода, часто однообразного и подверженного ошибкам, тем самым значительно повышая скорость разработки. Кроме того, большинство современных реализаций ORM позволяют программисту при необходимости самому жёстко задать код SQL-запросов, который будет использоваться при тех или иных действиях (сохранение в базу данных, загрузка, поиск и т. д.) с постоянным объектом.
При разработке приложения, которое требует осуществления доступа к данным, необходимо упростить разработку такого приложения, увеличив эффективность и скорость работы с получаемыми данными. Поэтому данная проблема остаётся актуальной и сегодняшнее время.
Для её решения был выбран JPA(Java Persistence API).
На приведенной ниже диаграмме показана взаимосвязь между основными компонентами JPA архитектуры.
Рисунок 3.3 - Архитектура JPA
Persistence - класс содержит вспомогательные статические методы для получения EntityManagerFactory независимым от поставщика способом.
EntityManagerFactory - интерфейс, реализация которого является фабрикой для создания объектов EntityManager.
EntityManager - является основным JPA интерфейсом используемый в приложениях. Каждый EntityManager управляет набором хранимых объектов и содержит API для вставки новых объектов и удаления существующих. С каждым EntityManager связан свой EntityTransaction и, также, EntityManager выступает фабрикой для объектов Query.
Entity - сущность, которая является хранимым объектом.
EntityTransaction - объект, который производит управления транзакциями при выполнении операций с хранимыми объектами Entity. Операции группируются и либо выполняются полностью, либо нет, оставляя хранилище данных в неизменном состоянии.
Query - интерфейс для выполнения запросов по нахождению хранимых объектов, которые удовлетворяют заданным критериям. JPA поддерживает запросы на объектном языке Java Persistence Query Language (JPQL) и стандартном структурированном языке Structured Query Language (SQL). Получить экземпляры Query можно из объекта EntityManager.
3.2 Разработка модулей системы
3.2.1 Разработка модулей слоя бизнес-логики и бизнес-правил
Данный модуль представляет собой описания всех сущностей нашей БД. Он включает в себя одиннадцать классов, а именно:
Matchi.java - класс, который описывает матчи. Содержит такую информацию: дата проведения матча, гость, хозяин, счёт матча, номер тура. Он содержит методы получения и записи полей.
Komanda.java - класс, который описывает команды. Содержит такую информацию: название команды, ФИО тренера, город команды. Он содержит методы получения и записи полей.
Tablica.java - класс, который описывает турнирную таблицу. В нём содержатся поля: количество очков команды, количество проигрышей, выигрышей и ничьих. Он содержит методы получения и записи полей.
Chempionat.java - класс, который описывает чемпионат. В нём содержатся следующая информация: дата начала дата окончания мемпионата, название страны, в которой он проводится. Он содержит методы получения и записи полей.
Worker.java - класс, который описывает работника. В нём содержатся следующая информация: ФИО работника, дата рождения, телефон, адрес. Он содержит методы получения и записи полей.
User.java - класс, который описывает пользователя. В нём содержатся следующая информация: логин и пароль для входа в систему. Он содержит методы получения и записи полей.
Role.java - класс, который описывает роль пользователя. В нём содержатся следующая информация: имя пользователя. Он содержит методы получения и записи полей.
Prava.java - класс, который описывает права пользователя. В нём содержатся следующая информация: права, под пользователь которыми он входит в систему
3.2.2 Разработка модулей слоя доступа к данным
Доступ к данным осуществляется с помощью DAO. Этот модуль представлен двумя пакетами с интерфейсами и их реализациями. В нём содержатся следующие интерфейсы:
– ITablicaDao.java - интерфейс, который содержит описания методов, для работы c таблицей. В нём описан следующий методы:
public Collection
Реализация методов находится в классе TablicaDaoJpa.
– IKomandaDao.java - интерфейс, который содержит описания методов, для работы со списком команд. В нём описаны следующие методы:
a)
public
Collection
b) public Komanda findKomandaByName(String name) throws PersistenceException метод для получения команды по имени.
c) getTheWorstKomandaByChampId(String name) throws PersistenceException метод для получения наихудшей команды в чемпионате;
d) public String getTheBestKomandaByChampId(String name) throws PersistenceException метод для получения наилучшей команды в чемпионате;
e)
public
Collection
Подобные документы
Структура базы данных. Визуализация трехуровневой архитектуры, состоящей из презентационного слоя, бизнес-слоя и слоя баз данных, реализованной с помощью UML схем. Основные структурные особенности трехслойных приложений. Исходный код некоторых модулей.
курсовая работа , добавлен 03.11.2012
Проектирование модели разрабатываемой базы данных гостиниц. Разработка триггеров, хранимых процедур, запросов. Создание пользовательского интерфейса. Автоматизация работы по регистрации, учету, поиску, а также по формированию отчетности о работодателях.
курсовая работа , добавлен 29.11.2015
Характеристика основных потоков данных, существующих на предприятии. Способы и средства для разработки программного обеспечения. Проектирование пользовательского интерфейса. Разработка слоя взаимодействия с базой данных. Разработка слоя бизнес сервисов.
дипломная работа , добавлен 10.07.2017
Определение функциональных зависимостей. Разработка структуры базы данных. Организация запросов к базе данных. Использование триггеров для поддержки данных в актуальном состоянии. Разработка хранимых процедур и функций. Ограничения ведения базы данных.
курсовая работа , добавлен 17.06.2014
Сущность базы данных - набора, совокупности файлов, в которых находится информация. Система управления базой данных - программная система (приложение), обеспечивающая работу с базой данных (файлами данных). Назначение и польза от применения триггеров.
курсовая работа , добавлен 22.02.2011
Проектирование реляционной базы данных, организация выборки информации из нее. Разработка представлений для отображения результатов. Проектирование хранимых процедур. Механизм управления данными при помощи триггеров. Требования к техническому обеспечению.
дипломная работа , добавлен 03.07.2011
Разработка и отладка БД серверного типа с веб-интерфейсом "Учет продукции" для мебельного производства. Физическая модель данных. Описание индексов и ограничений, запросов и представлений данных, отчетов и диаграмм. Описание триггеров и хранимых процедур.
курсовая работа , добавлен 20.02.2015
Язык манипуляции данными. Процесс отбора данных. Использование агрегатных функций и специальных операторов в условиях отбора. Создание и использование представлений и хранимых процедур. Использование триггеров, разработка интерфейса пользователя.
лабораторная работа , добавлен 13.02.2013
Логическая и физическая структура базы данных. Аппаратное и программное обеспечение системы. Создание представлений, хранимых процедур, пользовательских функций, триггеров. Описание основной структуры ASP.NET документов. Пользовательский интерфейс.
курсовая работа , добавлен 21.05.2013
Понятие базы данных. Разработка таблиц, форм ввода и вывода информации, основных запросов, хранимых процедур и триггеров базы "Доска объявлений". Подготовка для вывода на печать. Анализ необходимости администрирования, средств защиты информации.
Цели урока: создать условия для восприятия и закрепления учебного материала по теме “Моделирование в текстовом процессоре”
- Продолжить знакомить учащихся с возможностями моделирования в текстовом процессоре Word;
- Познакомить учащихся с понятием и видами структурных моделей;
- Научить общему подходу к созданию образно-знаковых моделей в текстовом процессоре;
- Обеспечить выполнение заданий по моделированию в среде текстового процессора.
Развивающая:
Развитие приемов умственной деятельности (обобщение, анализ, синтез, сравнение), памяти (лучше всего запоминается то, что связано с преодолением препятствия), развитие модельного стиля учащихся.
Воспитательная:
Развитие познавательных способностей учащихся, посредством рассмотрения разнообразных задач на моделирование в среде текстового процессора.
Тип урока: комбинированный.
Оборудование урока: компьютер, проектор, презентация (приложение 1 ), карточки с заданием для практической работы (приложение 2 ).
Ход урока:
I. Орг. момент.
Постановка целей урока, сообщение учащимся основных этапов урока.
II. Актуализация опорных знаний учащихся.
- Фронтальная работа с классом:
– Какие модели называю знаковыми?
– Назовите известные вам виды знаковых моделей?
– Какую знаковую модель называют словесной?
– Какой текстовый документ называется составным?
– Приведите примеры оформительских задач, решаемых с помощью создания составных документов в текстовом редакторе.
III. Изучение нового материала.
Структурой называется взаимное расположение составных частей чего либо.
Структура данных – совокупность элементов информации находящихся в определенной, заранее заданной взаимосвязи, а также способ описания такой взаимосвязи. (Приложение 1 слайд 3 ),
Структурная модель данных – модель данных, представленная в виде структуры – множества типов данных и связей между ними.
Наиболее распространенными в текстовых документах являются следующие виды информационных структур: (приложение 1 слайд 4 )
- Таблица
- Схема – отражает внешний вид классификации объектов (приложение 1 слайд 5 )
Внешне схема классификации напоминает перевернутое дерево, и представляет иерархию объектов. В иерархических схемах каждый объект имеет только одного предка и может иметь несколько потомков. Самый верхний уровень (корень дерева) не имеет предка и задает основные признаки, позволяющие отличить объекты этого класса от других.
С подобными схемами вы встречаетесь в биологии, истории и других предметах.
Задание: Постройте структурную схему для родословной по следующему описанию:
Молодожены нормально владеют правой рукой. В семье женщины было еще две сестры, нормально владеющие правой рукой, и три брата левши. Мать женщины – правша, отец – левша. У отца есть сестра и 2 брата правши. Дед по линии отца – правша, бабка – левша. У матери женщины есть два брата и сестра – все правши. Мать мужа – правша, отец – левша. (Приложение 1 слайд 6 )
На уроках русского языка вам приходилось делать синтаксический разбор предложения, а поскольку предложение является системой, состоящей из слов, можно построить схему, которая показывает главные и второстепенные члены предложения. (Приложение 1 слайд 7 )
- Блок-схема – совокупность геометрических фигур, каждая из которых обозначает определенное действие, взаимосвязь между которыми устанавливается с помощью стрелок или линий (Приложение 1 слайд 8 )
- Документы со структурой, определенной законодательством
Очень часто в жизни мы встречаемся с различного рода документами. Это справки, заявления, приказы и многое другое. Любой из перечисленных документов является носителем информации и должен быть оформлен юридически правильно. В настоящее время все чаще для составления таких документов используется прикладная среда текстового редактора.
Вам, конечно же, приходилось составлять протокол ведения классного собрания.
– Что такое протокол? (Протокол – документ фиксирующий ход обсуждения вопросов и принятия решения на собраниях, совещаниях и т.д.)
– Какая обязательная информация на ваш взгляд должна быть отражена в протоколе? (дата заседания; количество присутствующих; повестка дня; ход обсуждения; решения собрания) (Приложение 1 слайд 9 )
На слайд 10 приложения 1 приведен образец оформления протокола классного собрания.
IV. Закрепление изученного материала.
Выполнение практической работы “Создание знаковой структурной модели” на компьютере (приложение 2 )
V. Итог урока.
1. Анализ итогов выполнения практической работы:
– что получилось?
– что не получилось?
– какие трудности испытывали при выполнении
заданий?
2. Выставление отметок за выполнение практической работы.
VI. Домашнее задание.
Составить в рабочих тетрадях (в текстовом процессоре) схему классификации школьных принадлежностей.
Размер: 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. Программу и материалы статей
Федеральное Агентство Железнодорожного Транспорта
Кафедра «Связь»
Курсовая работа.
Проектирование базы данных.
Работу выполнил:
студент гр. Ит-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. Футбол — командный вид спорта, в котором целью является забить мяч в ворота соперника ногами или другими частями тела (кроме рук) большее количество раз, чем команда соперника. Является самым популярным видом спорта в мире. В качестве основы для базы данных Access Футбольная Команда был выбран футбольный клуб Спартак. Предметная область - футбольная команда. Цель – создание базы данных для хранения, поиска и ознакомления с информацией о игроках, играх, результатах игр, футбольных командах и т.д. В данной БД реализована возможность просмотреть бомбардиров клуба, вывести список легионеров ФК Спартак, выгрузить календарь игр, посмотреть статистику каждого игрока ФК Спартак, статистику игр. Также можно сформировать турнирную таблицу после каждого тура, просмотреть движение каждой команды в чемпионате РФПЛ в виде графика. При желании БД можно переделать под любой другой футбольный клуб. База данных Access Футбольная Команда содержит 7 таблиц , 12 запросов, 8 форм + главная кнопочная форма, 7 отчетов. Данная база данных 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 скачать;
Атрибуты
Соответствие
Фамилия
Famil
Имя
Imya
Отчество
Otchestvo
Телефон
Tel
Команда 1
Komanda_1
Команда 2
Komanda_2
Очки 1
ochki_1
Очки 2
ochki_2
Время
Vremya
Вид чемпионата
Vid_chemp
Год оснавания
God_osn
Город
Gorod
Страна
Strana
Тренеровочные базы
Basi
Адрес
Adres
Название
Nazvanie
Дата начала
Data_nachala
Дата_конца
Data_konza
Результат выполнения работы представляется в виде базы Access, который должен содержать:
структуру спроектированных таблиц,
схему данных со связями между таблицами,
формы, обеспечивающих интерфейс пользователя,
запросы ,
отчеты,
главную кнопочную форму.
