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

МИНИСТЕРСТВО СЕЛЬСКОГО ХОЗЯЙСТВА РОССИЙСКОЙ ФЕДЕРАЦИИ

Федеральное государственное Бюджетное образовательное учреждение высшего образования «российский государственный аграрный университет - МСха имени К.А. Тимирязева» (ФГБОУ ВО ргау - МСХА имени К.А. Тимирязева)

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

По дисциплине «Базы данных»

Проектирование структуры БД и разработка бизнес-логики для учета клиентов фитнес-клуба «Мегаполис»

Выполнил

Мясников Н.А.

Руководитель:

Мастяев Ф.А.

Москва, 2017



Оглавление

Введение

Глава 1. Исследование предметной области и предметной деятельности

1.1 Краткая характеристика субъекта исследования

1.2 Организационная структура

1.3 Управленческая структура

1.4 Структура документооборота

1.5 Структура информационных потоков

1.6 Функциональные требования к базе данных и приложению доступа к данным

1.7 Обоснование выбора СУБД

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

2.1 Концептуальное проектирование структуры БД

2.2 Логическое проектирование структуры БД

2.3 Физическое проектирование структуры БД

Глава 3. Разработка бизнес-логики для учета клиентов фитнес-клуба «Мегаполис»

3.1 Определение состава бизнес-операций на основе функциональных требований

3.2 Реализация бизнес-логики в виде SQL-запросов

3.3 Демонстрация работоспособности разработанных SQL-запросов

Заключение

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



Введение

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

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

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

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

Объектом исследования курсовой работы выступают проблемы ведения клиентской базы, учет абонементов, предоставляемых клиентам клуба. Субъектом - фитнес-клуб «Мегаполис»

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

- Изучить теоретические основы проектирования баз данных

- Спроектировать структуру таблиц

- Составить схему данных со связями между таблицами

- Составить физическую модель базы данных

- Создать запросы для базы данных

Ожидаемые результаты курсовой работы состоят в получении навыков представления данных в тройственной схематической модели, определяющей три типа схем: внешней, концептуальной и внутренней; закреплении навыков использования модификации расширенной модели «сущность - связь».

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



Глава 1. Исследование предметной области и предметной деятельности

1.1 Краткая характеристика субъекта исследования

Фитнес-клуб «Мегаполис» - это сооружения, которые имеют площадки для проведения оздоровительных и фитнес-тренировок при помощи силовых упражнений и оборудования для кардио-тренировок и которые открыты для свободного посещения за плату на основе платежей за разовое посещение или по членской системе. Данный клуб предоставляет более 50 различных услуг и направлений. В распоряжении фитнес-клуба находиться более 150 различных тренажеров, 7 залов для групповых программ, игровая площадка, а также зона единоборств и бассейн.

Фитнес-клуб имеет огромное количество посетителей и сотрудников, поэтому своевременно внедряет самые передовые технологии для более быстрого обслуживания клиентов и упрощения работы сотрудников.

1.2 Организационная структура

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

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

Достоинства такой структуры на примере Фитнес-клуба «Мегаполис»:

· Тщательная проработка стратегических вопросов;

· Директору проще быть в курсе всех действий;

· Такая структура упрощает механизм контроля;

Недостатки такой структуры на примере Фитнес-клуба «Мегаполис»:

· Существует опасность перегрузки руководства;

· Имеет место быть тенденция к перекладыванию ответственности при решении проблем, в которых должны участвовать несколько отделов;

Должности, из которых состоят уровни в Фитнес-клубе «Мегаполис»:

Первый уровень:

1. Генеральный директор

2. Бухгалтер

Второй уровень:

1. Менеджер-консультант

2. Администратор

3. Тренера

4. Уборщик

Рисунок 1. Организационная структура

1.3 Управленческая структура

В фитнес-клубе «Мегаполис» существуют следующие структурные подразделения:

1.Отдел продаж

1) Отдел кадров

2. Рекламный отдел

3.Бухгалтерия

4. Отдел фитнеса

1) Отдел групповых занятий

2) Секция занятий боксом

3) Секция занятий с детьми

4) Отдел индивидуальных занятий

5) Отдел занятий на воде

Рисунок 2. Управленческая структура

1.4 Структура документооборота

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

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

В технологической цепочке обработки и движения документов выделяются этапы:

· прием и первичная обработка поступающих в организацию документов;

· предварительное рассмотрение и распределение документов;

· регистрация документов;

· контроль исполнения;

· информационно-справочная работа;

· исполнение документов, их составление, согласование, оформление;

· отправка или направление в дело.

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

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

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

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

1.5 Структура информационных потоков

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

* первичные документы;

* данные внутреннего документооборота (бумажного и электронного), включая приказы и распоряжения руководителя и менеджеров всех звеньев;

* данные бухгалтерского учета и другой обязательной отчетности за текущий и прошлые периоды;

* результаты анализа финансово-хозяйственной деятельности;

Внешнее информационное поле объединяет следующую информацию:

- нормативные акты федерального, регионального, местного уровня;

- отраслевые нормативно-справочные документы;

- данные о состоянии отрасли, основных рынков сбыта и сырья;

- данные о состоянии мировой экономики;

- реклама и информация партнеров и конкурентов;

- информация от клиентов;

- выводы консультантов и экспертов, результаты аудиторских проверок.

Рисунок 3. Структура информационных потоков

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

1.6 Функциональные требования к базе данных и приложению доступа к данным

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

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

К функциональным требованиям стоит отнести такие функции, как:

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

· Защита данных - обеспечение защиты данных от преднамеренного или непреднамеренного нарушения секретности, искажения или разрушения;

· Стандартизация построения и эксплуатации базы данных;

· Обеспечение защиты от ошибок при обновлении базы данных.

· Сохранение ссылочной целостности, путем разрешения/запрета каскадного удаления и обновления;

· Создание резервной копии при сбоях техники;

· Формирование видов - таблиц, производных от исходных и предназначенных конкретным пользователем;

· Создание и передача запросов;

· Выполнение логики приложения;

· Управление приложением;

· Создание базы данных;

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

· Управление параллельной обработкой.

1.7 Обоснование выбора СУБД

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

Ш MS Access

Ш SQLite

Ш MySQL

Ш PostgreSQL

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

Рассмотрим СУБД - MS Access.

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

К достоинствам относят:

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

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

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

4. Распространенность, которая обусловлена тем, что Access является продуктом компании Microsoft,

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

6. Полностью совместим с операционной системой Windows,

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

8. Широкие возможности по импорту/экспорту данных в различные форматы, от таблиц Excel и текстовых файлов, до практически любой серверной СУБД через механизм ODBC.

К недостаткам относят:

1. Ограничены возможности по обеспечению многопользовательской среды,

2. В ранних версиях (до Access 2003) отсутствуют такие средства как триггеры и хранимые процедуры, что заставляет разработчиков возлагать поддержание бизнес логики БД на клиентскую программу или разрабатывать процедуры с помощью встроенного средства VBA.

3. Обладает несложными способами защиты с использованием пароля БД (возможно применения дополнительных мер по защите от несанкционированного доступа с использованием процедур VBA),

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

5. Не распространяется бесплатно.

Рассмотрим СУБД - SQLite.

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

К достоинствам относят:

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

2. Используемые стандарты - хотя может показаться, что эта СУБД примитивная, но она использует SQL. Некоторые особенности опущенны (RIGHT OUTER JOIN или FOR EACH STATEMENT), но основные все-таки поддерживаются

3. Отличная при разработке и тестировании - в процессе разработки приложений часто появляется необходимость масштабирования. SQLite предлагает всё что необходимо для этих целей, так как состоит всего из одного файла и библиотеки написанной на языке C.

К недостаткам относят:

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

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

Рассмотрим СУБД - MySQL

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

К достоинствам относят:

1. Простота в работе - установить MySQL довольно просто. Дополнительные приложения, например GUI, позволяет довольно легко работать с БД

2. Богатый функционал - MySQL поддерживает большинство функционала SQL.

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

4. Масштабируемость - MySQL легко работает с большими объемами данных и легко масштабируется

5. Скорость - упрощение некоторых стандартов позволяет MySQL значительно увеличить производительность.

К недостаткам относят:

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

2. Проблемы с надежностью - из-за некоторых способов обработки данных MySQL (связи, транзакции, аудиты) иногда уступает другим СУБД по надежности.

3. Медленная разработка - Хотя MySQL технически открытое ПО, существуют жалобы на процесс разработки.

Рассмотрим СУБД - PostgreSQL

PostgreSQL является самым профессиональным из всех трех рассмотренных нами СУБД. Она свободно распространяемая и максимально соответствует стандартам SQL. PostgreSQL или Postgres стараются полностью применять ANSI/ISO SQL стандарты своевременно с выходом новых версий.

К достоинствам относят:

1. Открытое ПО соответствующее стандарту SQL - PostgreSQL - бесплатное ПО с открытым исходным кодом. Эта СУБД является очень мощной системой.

2. Большое сообщество - существует довольно большое сообщество, в котором вы запросто найдёте ответы на свои вопросы

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

4. Расширения - существует возможность расширения функционала за счет сохранения своих процедур.

5. Объектность - PostrgreSQL это не только реляционная СУБД, но также и объектно-ориентированная с поддержкой наследования и много другого

К недостаткам относят:

1. Производительность - при простых операциях чтения PostgreSQL может значительно замедлить сервер и быть медленнее своих конкурентов, таких как MySQL

2. Популярность - по своей природе, популярностью эта СУБД похвастаться не может, хотя и присутствует довольно большое сообщество.

3. Хостинг - в силу вышеперечисленных факторов иногда довольно сложно найти хостинг с поддержкой этой СУБД.

После рассмотрения всех СУБД, наиболее подходящим вариантом выбран Microsoft Office Access, так как СУБД Access обеспечивает доступ ко всем типам данных и позволяет одновременно использовать несколько таблиц базы данных. Работая в среде Microsoft Office, пользователь получает в своё распоряжение полностью совместимые с Access текстовые документы(Word), электронные таблицы(Excel), презентации(PowerPoint). Также, несмотря на то, что Access является мощной и сложной системой, его использование несложно для непрофессиональных пользователей.



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

2.1 Концептуальное проектирование структуры БД

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

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

Чаще всего концептуальная модель базы данных включает в себя:

· описание информационных объектов, или понятий предметной области и связей между ними.

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

К этапам проектирования концептуальной модели относят:

· Создание локальной концептуальной модели данных;

· Определение типов связей;

· Определение типов сущностей;

· Определение атрибутов и связывание их с типами сущностей и связей;

· Определение доменов атрибутов;

· Определение атрибутов, являющихся потенциальными и первичными ключами;

· Проверка модели на отсутствие избыточности;

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

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

· Абонементы

· Клиенты

· Тренеры

· Залы

· Учет

Схема концептуальной модели базы данных фитнес-клуба показана на рисунке 4. база данный приложение запрос

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

2.2 Логическое проектирование структуры БД

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

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

К этапам логического проектирования относят:

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

2. Определение набора отношений исходя из структуры локальной логической модели данных.

3. Проверка модели с помощью правил нормализации.

4. Проверка модели в отношении транзакций пользователей.

5. Создание диаграммы сущность-связь.

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

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

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

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

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

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

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

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

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

Рис 5. Схема взаимосвязей

2.3 Физическое проектирование структуры БД

Целями физического проектирования являются:

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

· определение конкретных структур хранения данных и методов доступа к ним, обеспечивающих оптимальную производительность СУБД;

· разработка средств защиты создаваемой системы.

Физическая модель базы данных представлена в таблицах 1-5



Таблица 1. Физическая структура базы данных фитнес-клуба

Таблица Абонементы
Код_абонемента	Счетчик
Описание	Короткий текст
Цена	Денежный
Код_зала	Числовой
Таблица Залы
Код_зала	Счетчик
Наименование_зала	Короткий текст
Таблица Клиенты
Код_клиента	Счетчик
Фамилия_клиента	Короткий текст
Имя_клиента	Короткий текст
Телефон_клиента	Короткий текст
Код_тренера	Числовой
Таблица Тренеры
Код_тренера	Счетчик
Фамилия_имя_тренера	Короткий текст
Оклад	Денежный
Телефон_тренера	Короткий текст
Таблица Учет
Код_записи	Счетчик
Код_клиента	Числовой
Код_абонемента	Числовой
Месяц	Короткий текст
Произведена_оплата	Логический



Глава 3. Разработка бизнес-логики для учета клиентов фитнес-клуба «Мегаполис»

3.1 Определение состава бизнес-операций на основе функциональных требований

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

1. Каждой бизнес-операции ставится в соответствие подсистема в разрабатываемой системе.

2. каждому шагу бизнес-операции - функциональное требование.

Следующие функциональные требования ставятся в фитнес-клубе «Мегаполис»:

- Продажа абонементов

- Взаимосвязь с клиентами

- Взаимосвязь с тренерами

- Ведение отчетностей

- Поддержка работоспособности залов

3.2 Реализация бизнес-логики в виде SQL-запросов

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

Для быстрого вывода результата и удобства сотрудников в базе данных фитнес-клуба «Мегаполис» были созданы следующие запросы на языке SQL:

1. Клиенты, с действующими абонементами на текущий момент в большой бассейн:

SELECT Клиенты.Код_клиента, Клиенты.Фамилия_клиента, Клиенты.Имя_клиента, Залы.Код_зала

FROM Клиенты INNER JOIN (Залы INNER JOIN (Абонементы INNER JOIN Учет ON Абонементы.Код_абонемента = Учет.Код_абонемента) ON Залы.Код_зала = Абонементы.Код_зала) ON Клиенты.Код_клиента = Учет.Код_клиента

GROUP BY Клиенты.Код_клиента, Клиенты.Фамилия_клиента, Клиенты.Имя_клиента, Залы.Код_зала

HAVING (((Залы.Код_зала)=1001));

2. Тренера, имеющие клиентов на данный момент:

SELECT Тренеры.Код_тренера, Тренеры.Фамилия_имя_тренера, Count(Клиенты.Код_клиента) AS Количество

FROM Тренеры INNER JOIN Клиенты ON Тренеры.Код_тренера = Клиенты.Код_тренера

GROUP BY Тренеры.Код_тренера, Тренеры.Фамилия_имя_тренера;

3. Тренера, получившие премию за текущий месяц:

SELECT Тренеры.Код_тренера, Тренеры.Фамилия_имя_тренера, Count(Клиенты.Код_клиента) AS Количество, [Оклад]*0.4 AS Премия

FROM Тренеры INNER JOIN Клиенты ON Тренеры.Код_тренера = Клиенты.Код_тренера

GROUP BY Тренеры.Код_тренера, Тренеры.Фамилия_имя_тренера, [Оклад]*0.4

HAVING (((Count(Клиенты.Код_клиента))>1));

4. Поиск Данных клиента по Фамилии клиента:

SELECT клиенты.код_клиента, клиенты.Фамилия_клиента, клиенты.Имя_клиента, клиенты.Телефон_клиента

FROM клиенты

WHERE (((клиенты.код_клиента)=[введите код клиента]));

5. Поиск данных тренера по коду тренера:

SELECT тренеры.код_тренера, тренеры.Фамилия_имя_тренера, тренеры.Телефон_тренера

FROM тренеры

WHERE (((тренеры.код_тренера)=[ введите код тренера(три значения вида "11х")]));

3.3 Демонстрация работоспособности разработанных SQL-запросов

Рис.6 Поиск данных клиента по фамилии

Таблица 8. Данные клиента с кодом «2»

поиск клиента
код_клиента	Фамилия_клиента	Имя_клиента	Телефон_клиента
4	Галустян	Михаил	89631522354

Рис.7 Поиск данных тренера по коду тренера



Таблица 9. Данные тренера с кодом «111»

тренера
код_тренера	Фамилия_имя_тренера	Оклад
111	Мясников Николай	100 000,00 ?

Таблица 9. Клиенты, имеющие абонемент в большой бассейн

Клиенты, с действующими абонементами на текущий момент
Код_клиента	Фамилия_клиента	Имя_клиента	Код_зала
1	Гончарова	Алиса	1001
2	Зайцев	Вячеслав	1001
4	Галустян	Михаил	1001

Таблица.10 Тренера, имеющие клиентов на данный момент

Запрос2
Код_тренера	Фамилия_имя_тренера	Количество Клиентов
112	Аршакян Армен	2
113	Королев Иван	1
114	Агуров Зухраб	1
115	Тайсон Майк	2
116	Пьеха Стас	1
117	Муринов Павел	1
118	Шепс Александр	1
119	Билан Дмитрий	1

Таблица 11. Тренера, получившие премию за текущий месяц

Запрос3
Код_тренера	Фамилия_имя_тренера	Количество Клиентов	Премия
112	Аршакян Армен	2	4600
115	Тайсон Майк	2	3000



Заключение

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

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

Были достигнуты поставленные цели, такие как:

- Изучение теоретических основ проектирования баз данных

- Составление структуры спроектированных таблиц

- Составление схемы данных со связями между таблицами

- Составление физическую модель базы данных

- Создание запросов для базы данных

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



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

1. Марков А.С. Базы данных. Введение в теорию и методологию. М.: Финансы и статистика, 2002 г.

2. Мейер Д. Теория реляционных баз данных. М., 1987. 608 с., ил.

3. Крёнке Д. Теория и практика построения баз данных. 8-е изд. СПб.:ПИТЕР, 2003 - 800с.

4. Бакаревич Ю., Пушкина Н. MS Access 2015 за 30 занятий. [Текст] / Бакаревич Ю.Б., Пушкина Н.В. - СПб: ВНV, 2000. - 657 с.

5. Бакаревич Ю.Б., Пушкина Н.В., Смирнова Е.Ю. Управление базами данных. [Текст] / Бакаревич Ю.Б., Пушкина Н.В. - СПб.: Изд. СПбГУ, 2009. - 754 с.

6. Золотова С.И. Практикум по Access.[Текст] / Золотова С.И. М.: Финансы и статистика, 2016г.

7. Горев А., Ахаян Р., Макашарипов С. Эффективная работа с СУБД. [Текст] / Горев А., Ахаян Р СПб.: Питер, 2015. - 412 с.

8. Скотт Баркер. Использование Microsoft Access. [Текст] / Скотт Баркер -Киев-Москва: Диалектика, 2016. - 506 с.

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