Размещено на http://www.allbest.ru/

Контрольная работа

по дисциплине «Управление данными»

на тему: Проектирование БД спортивных соревнований

ОГЛАВЛЕНИЕ

• 1. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ
• 2. КОНЦЕПТУАЛЬНОЕ ПРОЕКТИРОВАНИЕ
• 3. ЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ
• 4. ФИЗИЧЕСКОЕ ПРОЕКТИРОВАНИЕ
• ЗАКЛЮЧЕНИЕ
• Приложения

1. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ

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

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

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

В качестве первого примера приводится сайт компании ОАО «Спортбокс» (www.sportbox.ru). Данный ресурс является одним из популярнейших в русском сегменте. На данном портале пользователю доступны функции просмотра информации о большинстве спортивных турнирах в разных видах спорта, статистика спортсменов и команд, просмотр прямых трансляций, календарь соревнований, новости о спорте и др. Так же для удобства имеется регистрация, что дает возможность участие в опросах, обсуждениях и др.

Со стороны пользователя, просмотр информации об определенном турнире выглядит следующим образом (Рис. 1).

Рис. 1. Информация о турнире на портале SPORTBOX.RU

В качестве второго примера был выбран сайт Чемпионат от компании Rambler&Co (www.championat.com). Он, как и первый пример, является одним из популярнейших в русском сегменте. На данном ресурсе пользователю также доступна информация о большинстве спортивных турнирах, статистика спортсменов и команд, календарь соревнований, новости и др. Тоже доступна регистрация, которая дает те же возможности. Но, по сравнению с первым примером, отсутствует функция просмотра видеотрансляций, однако имеется раздел о киберспорте и рейтинг букмекеров.

Со стороны пользователя, просмотр информации об определенном турнире выглядит следующим образом (Рис. 2).

Рис. 2. Информация о турнире на ресурсе Чемпионат

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

2. КОНЦЕПТУАЛЬНОЕ ПРОЕКТИРОВАНИЕ

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

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

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

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

Выделим основные действующие лица:

· Пользователь

· Администратор

Рассмотрим некоторые варианты использования.

Администратор решает следующие задачи:

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

2. Создание и редактирование обсуждений. Могут писать и удалять сообщения.

3. Имеют доступ к информации о пользователях

Пользователи решают следующие задачи:

1. Получают информацию о соревнованиях, спортсменах и командах

2. Осуществляют поиск информации по ключевым словам

3. Участвуют в обсуждениях

4. Добавление соревнований в избранное

Рассмотрим составленную диаграмму вариантов использования (Рис. 3)

Рис. 3. Диаграмма вариантов использования

В первом приближении для решения выделенных задач необходимо хранение данных о следующих объектах:

1. Пользователи

2. Турниры

3. Команды

4. Спортсмены

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

-условно-постоянные данные (например, команды);

-данные, которые часто обновляются(например, данные пользователей).

3. ЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ

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

Логическая модель данных является начальным прототипом будущей базы данных. Более того, логическая модель данных необязательно должна быть выражена средствами именно реляционной модели данных. Основным средством разработки логической модели данных в настоящий момент являются различные варианты ER-диаграмм (Entity-Relationship, диаграммы сущность-связь). Модель, или ER-диаграмма (Entity - Relation в русском переводе - модель «объект - отношение» или «сущность - связь») предназначена для формализованного описания предметной области на этапе логического проектирования базы данных. Модель представляет собой графическое описание предметной области с использованием стандартизированного набора обозначений. На основе ER-модели по определенным правилам строится логическая модель для реализации в конкретной СУБД.

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

Основные элементы, входящие в состав ER-моделей:

· сущности (объекты) предметной области;

· связи между объектами;

· атрибуты (свойства) объектов.

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

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

Связи выступают в модели в качестве средства, с помощью которого представляются отношения между сущностями, имеющими место в предметной области. При анализе связей между сущностями могут встречаться бинарные (между двумя типами сущностями), тернарные (между тремя типами сущностями) и общем случае n-арные связи.

Связь-это ассоциация между сущностями, включают по одной сущности из каждого участвующего в связи типа сущности.

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

Различные типы объектов и различные экземпляры одного типа объекта могут быть охвачены определенными отношениями, которые в рамках ER-модели выражаются связями.

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

Связи по признаку множественности могут быть трех типов:

1) «один-к-одному»;

2) «один-ко-многим»;

3) «многие-ко-многим»;

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

Построим ER-диаграмму типов всех сущностей и связей между ними.

Связь Участвует имеет тип M:M, т.к. команда может участвовать в нескольких турнирах, а каждому турниру нужны несколько команд. Сущность Команда имеет необязательный КП, считая, что команда может не участвовать в турнирах. Турнир имеет обязательный класс принадлежности, так как предполагаем, что он проходит при участии команд.



Связь Состоит имеет тип М:1, так как один спортсмен может состоять только в одной команде, а в команде может быть несколько спортсменов. Сущность Команда имеет обязательный класс принадлежности, потому что в каждой команде должны быть спортсмены. Спортсмен имеет необязательный класс принадлежности, потому что спортсмен может не состоять в команде.

Связь Участвует имеет тип M:M, т.к. спортсмен может участвовать в нескольких турнирах, а каждому турниру нужны несколько спортсменов. Сущность Спортсмен имеет необязательный КП, считая, что спортсмен может не участвовать в турнирах. Турнир имеет обязательный класс принадлежности, так как предполагаем, что он проходит при участии спортсменов.

Связь Состоит имеет тип М:1, так как один турнир может проходить только в одном месте, а в одном месте может проходить несколько турниров. Сущность Турнир имеет обязательный класс принадлежности, потому что у турнира должно быть место проведения.

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

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

Связь «Участвует» соответствует условиям правила 6, в соответствии с которым получаем три отношения:

1. Команда (idКоманды, ….)

2. Турнир (idТурнира, ....)

3. Результат Команды (idКоманды, idТурнира, ...)

Связь «Состоит» соответствует условиям правила 5 - тип связи «1:М». Одна из сущностей имеет обязательный класс принадлежности, а другая необязательный. Получаем три отношения:

1. Спортсмен (idСпортсмена, …)

2. Команда (idКоманды, …)

3. СпортКом (idКоманды, idСпортсмена, ...)

Связь «Участвует» соответствует условиям правила 6, в соответствии с которым получаем три отношения:

1. Спортсмен (idСпортсмена, …)

2. Турнир (idТурнира, …)

3. Результат Спортсмена (idТурнира, idСпортсмена, ...)

Связь «Проходит» соответствует условиям правила 4 - тип связи «1:М». Одна из сущностей имеет обязательный класс принадлежности, а другая необязательный. Получаем два отношения:

1. Турнир (idТурнира, Название Места, …) - добавился неключевой атрибут Название Места

2. Место Проведения (Название Места, ...)

Добавим не ключевые атрибуты, чтобы отношения соответствовали требованиям третьей нормальной формы:

1) Команда (idКоманды, Страна, Город, Дата Основания, Вид СпортаК)

2) Турнир (idТурнира, Количество Участников, Название Места, Дата Начала, Дата Окончания)

3) Спортсмен (idСпортсмена, ФИО, СтранаС, ГородС, Дата Рождения, Пол, Вид СпортаС)

4) Результат Команды (idКоманды, idТурнира, Результат Ком, МестоКом)

5) Результат Спортсмена (idСпортсмена, idТурнира, Результат Спорт, Место Спорт)

6) Место Проведения (Название Места, Страна, Город, Дата Открытия)

7) Спорт Ком (idКоманды, idСпортсмена)

4. ФИЗИЧЕСКОЕ ПРОЕКТИРОВАНИЕ

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

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

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

В таблице «Спортсмен» (см. табл. 1) хранится информация о всех спортсменах.

Таблица 1 Структура таблицы «Спортсмен»

Имя поля	Тип данных	Обязательное поле	Ключ	Значение по умолчанию	Ограничение	Ссылка
idСпортсмена	int	NOT NULL	Первичный		>0
ФИО	Varchar(100)	NOT NULL
СтранаС	Varchar(100)	NOT NULL
ГородС	Varchar(100)	NOT NULL
Дата Рождения	date	NOT NULL
Пол	Varchar(10)	NOT NULL
Вид СпортаС	Varchar(100)	NOT NULL

В приложении А (п.3) приведен код SQL-оператора для создания таблицы «Спортсмен».

В приложении Б (Рисунок Б.1) приведен пример заполнения таблицы «Спортсмен».

В таблице «Команда» (см. табл. 2) хранится информация о командах.

Таблица 2 Структура таблицы «Команда»

Имя поля	Тип данных	Обязательное поле	Ключ	Ограничение	Ссылка
idКоманды	int	NOT NULL	Первичный	>0
СтранаК	Varchar(30)	NOT NULL
ГородК	Varchar(30)	NOT NULL
Дата Основания	date	NOT NULL
ВидСпортаК	Varchar(100)	NOT NULL

В приложении А (п.1) приведен код SQL-оператора для создания таблицы «Команда».

В приложении Б (Рисунок Б.2) приведен пример заполнения таблицы «Команда».

В таблице «Турнир» (см. табл. 3) хранится информация о турнирах.

Таблица 3 Структура таблицы «Турнир»

Имя поля	Тип данных	Обязательное поле	Ключ	Ограничение	Ссылка
idТурнира	Int	NOT NULL	Первичный	>0
Количество Участников	Int	NOT NULL		>0
Название Места	Varchar(100)	NOT NULL			Название Места в Место Проведения
Дата Начала	Datetime	NOT NULL
Дата Окончания	Datetime	NOT NULL
Место	Varchar(100	NOT NULL		>0

В приложении А (п.2) приведен код SQL-оператора для создания таблицы «Турнир».

В приложении Б (Рисунок Б.3) приведен пример заполнения таблицы «Турнир».

В таблице «Результат Команды» (см. табл.4) хранится информация о результатах команды.

Таблица 4 Структура таблицы «Результат Команды»

Имя поля	Тип данных	Обязательное поле	Ключ	Ограничение	Ссылка
idКоманды	int	NOT NULL	Первичный	>0	IdКоманды в Команда
idТурнира	int	NOT NULL	Первичный	>0	idТурнира в Турнир
Результат Ком	Varchar(255)	NOT NULL
Место Ком	int	NOT NULL		>0

В приложении А (п.4) приведен код SQL-оператора для создания таблицы «Результат Команды».

В приложении Б (Рисунок Б.4) приведен пример заполнения таблицы «Результат Команды».

В таблице «Результат Спортсмена» (см. табл.5) хранится информация о результатах спортсменов.

Таблица 5 Структура таблицы «РезультатСпортсмена»

Имя поля	Тип данных	Обязательное поле	Ключ	Ограничение	Ссылка
idСпортсмена	int	NOT NULL	Первичный	>:0	idСпортсмена в Спортсмен
idТурнира	int	NOT NULL	Первичный	>0	idТурнира в Турнир
Результат Спорт	Varchar(255)	NOT NULL
Место Спорт	int	NOT NULL		>0

В приложении А (п.5) приведен код SQL-оператора для создания таблицы «Результат Спортсмена». В приложении Б (Рисунок Б.5) приведен пример заполнения таблицы «Результат Спортсмена».

В таблице «Место Проведения» (см. табл.6) хранится информация о месте проведения соревнований.

Таблица 6 Структура таблицы «Место Проведения»

Имя поля	Тип данных	Обязательное поле	Ключ	Ограничение	Ссылка
Название Места	Varchar(100)	NOT NULL	Первичный		Название Места в Турнир
Страна	Varchar(100)	NOT NULL
Город	Varchar(100)	NOT NULL
Дата Открытия	Date	NOT NULL

В приложении А (п.6) приведен код SQL-оператора для создания таблицы «Место Проведения».

В приложении Б (Рисунок Б.6) приведен пример заполнения таблицы «Место Проведения».

Таблица 7 Структура таблицы «СпортКом»

Имя поля	Тип данных	Обязательное поле	Ключ	Ограничение	Ссылка
idСпортсмена	Int	NOT NULL	Первичный	>0	idСпортсмена в Спортсмен
idКоманды	int	NOT NULL	Первичный	>0	idКоманды в Команда

В приложении А (п.7) приведен код SQL-оператора для создания таблицы «СпортКом».

В приложении Б (Рисунок Б.7) приведен пример заполнения таблицы «СпортКом».

После создания структуры таблиц необходимо установить связи между таблицами. Для построения схемы данных (Рисунок 4) была использована среда DBdesigner. Она позволяет строить наглядные схемы данных, а так же создавать связи между таблицами.

база пользователь спортивный физический

Рис. 4. Схема Данных

ЗАКЛЮЧЕНИЕ

В качестве предметной области была выбрана тема проектирования БД спортивных мероприятий.

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

В ходе проделанной работы были решены следующие задачи:

1. Была рассмотрена выбранная предметная область. На выбор было выбрано два спортивных ресурса и были сформулированы функции, которые будут реализованы в проектируемой БД.

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

3. На этапе логического проектирования были построены диаграммы сущностей и связей между ними, определены типы связей и классы принадлежности сущностей. На основе анализа ER- диаграмм были сформированы отношения и добавлены неключевые атрибуты.

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

В дальнейшем будет разработан интернет ресурс с базой данных, реализованной на Microsoft SQL Server 2014. Пользователям будет доступны просмотр сведений о мероприятиях, спортсменах, командах и др. Также будет функция участия в обсуждениях.

ПРИЛОЖЕНИЯ

Приложение А

SQL-операторы создания таблиц

1. SQL -- операторы, необходимые для создания таблицы Команда

CREATE TABLE `Команда` (

`idКоманды` INT NOT NULL CHECK (>0),

`Страна` VARCHAR(30) NOT NULL,

`Город` VARCHAR(30) NOT NULL,

`ДатаОснования` DATE NOT NULL,

`ВидСпортаК` VARCHAR(100) NOT NULL,

PRIMARY KEY (`idКоманды`)

2. SQL -- операторы, необходимые для создания таблицы Турнир

CREATE TABLE `Турнир` (

`idТурнира` INT NOT NULL CHECK (>0),

`КоличествоУчастников` INT NOT NULL CHECK(>0),

`НазваниеМеста` VARCHAR(100) NOT NULL,

`ДатаНачала` DATETIME NOT NULL,

`ДатаОкончания` DATETIME NOT NULL,

`Результат` VARCHAR(255) NOT NULL DEFAULT 0,

`Место` INT NOT NULL CHECK(>0),

PRIMARY KEY (`idТурнира`),

FOREIGN KEY (`Место ПроведенияТ`) REFERENCES `Место Проведения`(`Название Места`)

3. SQL -- операторы, необходимые для создания таблицы Спортсмен (п.3)

CREATE TABLE `Спортсмен` (

`idСпортсмена` INT NOT NULL CHECK (>0),

`ФИО` VARCHAR(100) NOT NULL,

`СтранаС` VARCHAR(100) NOT NULL,

`ГородС` VARCHAR(100) NOT NULL,

`Дата Рождения` DATE NOT NULL,

`Пол` VARCHAR(10) NOT NULL,

`ВидСпортаС` VARCHAR(100) NOT NULL,

PRIMARY KEY (`idСпортсмена`)

);

4. SQL -- операторы, необходимые для создания таблицы Результат Команды

CREATE TABLE `Результат Команды` (

`idКоманды` INT NOT NULL CHECK(>0),

`idТурнира` INT NOT NULL CHECK(>0),

`РезультатКом` VARCHAR(255) NOT NULL DEFAULT 0,

`МестоКом` INT NOT NULL CHECK(>0),

PRIMARY KEY (`idКоманды`,`idТурнира`),

FOREIGN KEY (`idКоманды`) REFERENCES `Команда`(`idКоманды`),

FOREIGN KEY (`idТурнира`) REFERENCES `Турнир`(`idТурнира`)

5. SQL -- операторы, необходимые для создания таблицы РезультатСпортсмена

CREATE TABLE `РезультатСпортсмена` (

`idСпортсмена` INT NOT NULL AUTO_INCREMENT,

`idТурнира` INT NOT NULL AUTO_INCREMENT,

`РезультатСпорт` VARCHAR(255) NOT NULL,

`МестоСпорт` VARCHAR(255) NOT NULL,

PRIMARY KEY (`idСпортсмена`,`idТурнира`),

FOREIGN KEY (`idСпортсмена`) REFERENCES `Спортсмен`(`idСпортсмена`),

FOREIGN KEY (`idТурнира`) REFERENCES `Турнир`(`idТурнира`)

6. SQL -- операторы, необходимые для создания таблицы МестоПроведения

CREATE TABLE `МестоПроведения` (

`НазваниеМеста` VARCHAR(100) NOT NULL,

`Страна` VARCHAR(100) NOT NULL,

`Город` VARCHAR(100) NOT NULL,

`ДатаОткрытия` DATE NOT NULL,

PRIMARY KEY (`НазваниеМеста`)

7. SQL -- операторы, необходимые для создания таблицы СпортКом

CREATE TABLE `СпортКом` (

`idКоманды` INT NOT NULL,

`idКоманды` INT NOT NULL,

PRIMARY KEY (`idКоманды`,`idКоманды`) ,

FOREIGN KEY (`idКоманды`) REFERENCES `Команда`(`idКоманды`),

FOREIGN KEY (`idСпортсмена`) REFERENCES `Спортсмен`(`idСпортсмена`),

Приложение Б. Примеры заполнения таблиц

1. Данные таблицы Спортсмен

Размещено на http://www.allbest.ru/

Рисунок Б.1. Таблица Спортсмен

2. Данные таблицы Турнир

Рисунок Б.2. Таблица Турнир

3. Данные таблицы Результат Команды

Рисунок Б.3. Таблица Результат Команды

4. Данные таблицы Команда

Размещено на http://www.allbest.ru/

Рисунок Б.4. Таблица Команда

Данные таблицы Результат Спортсмена

Размещено на http://www.allbest.ru/

Рисунок Б.5. Результат Спортсмена

5. Данные таблицы Место Проведения

Размещено на http://www.allbest.ru/

Рисунок Б.6. Место Проведения

7. Данные таблицы СпортКом

Рисунок Б.7. СпортКом

Размещено на Allbest.ru