Проектирование базы данных для подведения итогов спортивных соревнований
Этапы разработки базы данных итогов чемпионатов по ручному мячу, которая предусматривает ввод результатов туров чемпионата с последующей автоматизацией подведения его итогов и обеспечивает хранение данных об участниках, призерах и итогах всех чемпионатов.
Рубрика | Программирование, компьютеры и кибернетика |
Вид | курсовая работа |
Язык | русский |
Дата добавления | 20.01.2013 |
Размер файла | 880,2 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
АКАДЕМИЯ МАРКЕТИНГА И СОЦИАЛЬНО-ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ - ИМСИТ (г. Краснодар)
Факультет информатики и ВТ
Кафедра компьютерных систем управления и обработки информации
КУРСОВАЯ РАБОТА
по дисциплине: «Базы данных»
на тему: «Проектирование базы данных для подведения итогов спортивных соревнований»
Работа выполнена студенткой
3 курса гр. 10-ПО-01
Саморуковой Алиной Сергеевной
Научный руководитель
к. ф-м. наук, доцент
Бужан В. В.
г. Краснодар 2012
РЕФЕРАТ
Курсовая работа на тему «Проектирование базы данных для подведения итогов спортивных соревнований» 26 с., 12 рис., 7 табл., 16 источников
РЕЛЯЦИОННАЯ МОДЕЛЬ ДАННЫХ, ТАБЛИЦА, ОТНОШЕНИЕ, ПОЛЕ, АТРИБУТ, ПРИЛОЖЕНИЕ, БАЗА ДАННЫХ, ФОРМА, ОТЧЁТ
Объектом исследования является база данных.
Цель работы состоит в приобретении навыков построения модели данных, их практическом применении в построении базы данных средствами СУБД и разработке приложения базы данных в соответствии с темой.
К полученным результатам относятся база данных «Проектирование базы данных для подведения итогов спортивных соревнований» и приложение базы данных для автоматизации управления данными. Теоретическая часть работы оформлена в виде рукописи.
Новизна результатов заключается в построенной модели данных, в полной мере отражающей сведения о наличии товаров и их характеристиках. Достоверность сведений обеспечивается соблюдением целостности данных, предусмотренной в модели.
Внедрение результатов предусматривается во всех спортивных организациях, проводящих соревнования и турниры среди спортивных команд.
Эффективность работы характеризуется простотой интерфейса и автоматическим формированием списка призёров на предварительном этапе соревнований.
СОДЕРЖАНИЕ
- ВВЕДЕНИЕ
- 1. ИССЛЕДОВАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ
- 1.1 Описание предметной области
- 1.2 Описание входных и выходных данных
- 1.3 Перечень ограничений к доступу данных
- 2. ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ
- 2.1 Построение инфологической модели
- 2.1.1 Описание сущностей
- 2.1.2 Описание связей
- 2.1.3 ER-диаграмма
- 2.2 Даталогическая модель
- 3. ПРАКТИЧЕСКАЯ РЕАЛИЗАЦИЯ БАЗЫ ДАННЫХ
- 3.1 Выбор системы управления базами данных
- 3.2 Создание таблиц
- 3.3 Запросы
- ЗАКЛЮЧЕНИЕ
- СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ И ЛИТЕРАТУРЫ
ВВЕДЕНИЕ
Предметом изучения в курсовой работе является проектирование баз данных. Данная тема является очень важной, без которой в наше время невозможно быть не только квалифицированным программистом и разработчиком приложений над базами данных, но даже и грамотным пользователем самих баз данных.
Уровень развития информационных технологий заставляет задумываться большинство средних и крупных организаций о создании действительно открытых и распределённых информационных систем баз данных на основе многопользовательских профессиональных СУБД. Информационные системы больших организаций содержат множество десятков баз данных, нередко распределённых между несколькими взаимосвязанными узлами вычислительной сети различных подразделений. Тенденции развития современных информационных технологий приводят к постоянному возрастанию сложности информационных систем, создаваемых в различных сферах деятельности человека.
В некоторых случаях реляционная база данных может служить источником информации для других баз данных. Например, данные наблюдений за изменением температур в некотором регионе могут быть использованы в базе данных метеонаблюдений в более крупном регионе или стране.
Вводить такие данные, которые мы будем называть промежуточными, в итоговую базу вручную контрпродуктивно, так как может потребовать значительного внимания и времени от пользователя. При этом ошибочно введённая информация может нарушить целостность данных в результирующей базе.
Если отношение результирующей базы имеет структуру, аналогичную структуре отношения промежуточной базы данных, то для решения проблемы используют SQL-запросы на добавление. Но если структуры не совпадают, то такой подход не приемлем и приходится искать иные пути решения. Например, если какой-либо атрибут результирующего отношения должен содержать часть промежуточных данных, то можно сформировать представление этой части, с тем, чтобы подставить его в данный атрибут.
Такого рода задачи обычно возникают при подведении итогов какого-либо события, основные характеристики которого оформлены в виде атрибутов отношения или группы отношений, описывающих это событие.
Данная работа посвящена решению одной из таких проблем - подведению итогов чемпионата по командным видам спорта на примере чемпионата по ручному мячу.
1. ИССЛЕДОВАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ
1.1 Описание предметной области
Рассматривается проблема подведения итогов чемпионата по ручному мячу среди женских команд. В чемпионате участвуют 10 команд. Чемпионат состоит из двух этапов.
На первом предварительном этапе команды встречаются между собой два раза по круговой системе.
На втором - заключительном этапе команды разбиваются на две финальные подгруппы. Первую подгруппу образуют команды, занявшие места с первого по шестое, а вторую подгруппу - команды, занявшие места с седьмого по десятое. Команды проводят финальные соревнования в два круга, каждая в своей подгруппе.
По их результатам определяются победители и призёры чемпионата в первой подгруппе и команды, занявшие места с седьмого по десятое, во второй подгруппе.
1.2 Описание входных и выходных данных
Исходя из описания предметной области можно заключить, что база данных оперирует следующими данными:
- год чемпионата;
- номер тура предварительного этапа;
- номер тура команд - участниц первой финальной подгруппы;
- номер тура команд - участниц второй финальной подгруппы;
- информация о командах - участницах чемпионата;
- таблица результатов предварительного этапа;
- таблицы результатов финального тура.
Среди них ко входным данным очевидно относятся: год чемпионата, номера туров предварительного и финального турниров и сведения о командах. Результаты финального турнира образуют выходные данные.
1.3 Перечень ограничений к доступу данных
Доступ к результатам чемпионата предполагается открытым всем желающим. К вводу и модификации данных имеет доступ только администратор базы данных.
2. ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ
2.1 Построение инфологической модели
2.1.1 Описание сущностей
По результатам исследований предметной области можно выделить три основных сущности. Первая сущность отражает годы проведения чемпионатов, вторая - туры текущего чемпионата, а третья - результаты текущего тура. Атрибутами первой сущности являются порядковые номера годов, второй сущности - номера тура, а третьей - названия команд текущего чемпионата и результатами встреч в каждом туре, которые характеризуются числом забитых и пропущенных мячей.
Таким образом, первая сущность «Годы» содержит единственный атрибут:
- год - порядковый номер года.
Вторая сущность «Туры» также состоит из единственного атрибута:
- тур - порядковый номер тура текущего чемпионата.
Третья сущность «Результаты» будет состоять из трёх атрибутов:
- команда - название команды, участницы текущего чемпионата;
- забито - количество мячей, забитых командой в матче тура;
- пропущено - количество мячей, пропущенных командой в матче тура.
2.1.2 Описание связей
Поскольку любой чемпионат состоит из туров, тип связи между первой и второй сущностями будет один ко многим (1:М). В свою очередь, каждый тур чемпионата характеризуется результатами встреч команд, забитыми и пропущенными каждой командой мячами. Поэтому тип связи между второй и третьей командами также будет 1:М.
2.1.3 ER-диаграмма
Исходя из представлений сущностей и анализа связей между ними, инфологическую модель предметной области на данном этапе исследования можно отобразить в виде ER-диаграммы, представленной на рисунке 1.
Рисунок 1 - Инфологическая модель предметной области на начальном этапе проектирования базы данных
Как можно видеть, свойства сущностей «Годы» и «Туры» являются статическими (литера «S») по понятным причинам. Поскольку какая-либо из команд могла выступать на различных чемпионатах под разными названиями, а матчи могут быть переиграны по причине протеста руководства команд, все атрибуты отношения «Результаты» должны быть динамическими (литера «D»). Исходя из дальнейшего анализа предметно области, в инфологической модели необходимо учесть предварительный и финальный турниры чемпионата. На предварительном этапе данные о его результатах должны быть внесены в отдельные сущности, показанные на рисунке 2.
Рисунок 2 - Предварительный этап соревнований
Затем, на основании результатов предварительного этапа, формируются две группы сущностей, в которых накапливаются результаты личных встреч команд, занявших места с 1 по 6 и с 7 по 10, соответственно. В итоге инфологическая модель примет окончательный вид (рисунок 3).
Рисунок 3 - Окончательная инфологическая модель предметной области
2.2 Даталогическая модель
база данные автоматизация чемпионат
Следующий этап проектирования базы данных предполагает дальнейшую детализацию инфологической модели, с целью приблизить её к практической реализации. Так в инфологической модели не обозначены первичные и внешние ключи, отсутствуют ссылки на типы данных атрибутов сущностей.
Согласно теории реляционных баз данных, в качестве первичного ключа должны выбираться одно или несколько полей, уникальных в своей совокупности. Для отношения «Годы» таковым очевидно будет атрибут «год». Для отношений «Турниры» - атрибут «тур», а для «Результаты» - атрибут «команда» (для краткости имена отношений сокращены до ключевого слова: «Предварительные турниры» - просто «Турниры» и т. п.).
Следуя требованиям целостности данных, внешний ключ должен соответствовать первичному ключу по типу данных и длине. Поэтому, в отношения, которые являются подчинёнными, добавлены атрибуты, удовлетворяющие данным требованиям: в отношение «Турниры» добавлен внешний ключ, одноименный первичному ключу «год чемпионата», а в отношение «Результаты» - внешний ключ, соответствующий первичному ключу «тур».
Нормализация отношений не требуется так как последние изначально определяют функциональные зависимости между ключевыми полями и другими атрибутами отношений без транзитивных зависимостей, а все атрибуты являются атомарными (рисунок 4).
Рисунок 4 - Функциональные зависимости (показаны стрелкой) между ключами и атрибутами отношений «Турниры» (а) и «Результаты» (б)
Поэтому можно утверждать, что все отношения находятся в третьей нормальной форме, что вполне удовлетворяет требованиям к большинству реляционных баз данных средней сложности.
Для полной картины определимся с типами данных атрибутов отношений. Результаты представлены в таблицах 1, 2 и 3 ключевые поля выделены полужирным шрифтом).
Таблица 1 - Отношение «Годы»
Атрибут |
тип данных |
|
год чемпионата |
числовой целый |
Таблица 2 - Отношение «Турниры»
Атрибут |
тип данных |
|
тур |
числовой целый |
|
год чемпионата |
числовой целый |
Таблица 3 - Отношение «Результаты»
Атрибут |
тип данных |
|
команда |
||
тур |
числовой целый |
|
забито |
числовой целый |
|
пропущено |
числовой целый |
Руководствуясь результатами проведённых исследований, построим даталогическую модель базы данных (рисунок 5).
Рисунок 5 - Даталогическая модель (PK - первичный ключ, FK - внешний ключ)
3. ПРАКТИЧЕСКАЯ РЕАЛИЗАЦИЯ БАЗЫ ДАННЫХ
3.1 Выбор системы управления базами данных
Существует большой выбор систем управления реляционными базами данных (СУБД) среди обширного семейства этой категории программных продуктов. Среди них можно выделить локальные СУБД и сетевые. Выбор диктуется областью их применения и характером использования. В рассматриваемом случае предполагается, что установку, администрирование и сопровождение базы данных будет осуществлять один пользователь - администратор баз данных или оператор ЭВМ. Доступ к базе может получить любой пользователь, но без права её обновления.
Данные требования диктуют выбор в качестве среды разработки и функционирования СУБД локального типа. На эту роль лучше всего подходит Microsoft Access. Его выбор объясняется широким распространением на территории Российской Федерации и стран СНГ. Access последних версий предоставляет пользователю обширный инструментарий создания локальных баз данных и приложений для работы с ними. А так же даёт возможность подключения других баз данных, включая сетевые, работающие на платформе клиент-сервер (Oracle, Microsoft SQL Server, Firebird, MySQL) с помощью технологий доступа данных ODBC, OLE DB и моделей доступа ADO, ADO .NET. Кроме того, имеется механизм, позволяющий конвертировать базы данных Access в базы данных SQL Server с поддержкой технологии OLE DB. Данный сервис позволит в дальнейшем конвертировать локальную базу данных в сетевую базу для СУБД SQL Server в случае перехода на клиент-серверную платформу.
3.2 Создание таблиц
На этом этапе практической реализации базы данных создаются таблицы, соответствующие даталогической модели, построенной в предыдущем разделе.
Для создания таблиц можно использовать два подхода. Первый подход заключается в применении SQL запросов. Второй подход использует визуальные средства Access. Он является наиболее удобным с точки зрения реализации по сравнению с первым подходом и поэтому был выбран для построения таблиц базы данных. В итоге построены таблицы имеющие структуру, показанную в таблицах 4 - 7.
Таблица 4 - Таблица «Год чемпионата»
поле |
тип данных |
описание |
|
id_year |
счётчик |
первичный ключ |
|
iYear |
числовой целое |
год |
Таблица 5 - Таблица «Тур чемпионата» / «ФинальныйТурнир1-6» / «ФинальныйТурнир7-10»
поле |
тип данных |
описание |
|
id_tur |
счётчик |
первичный ключ |
|
id_year |
длинное целое |
внешний ключ |
|
тур |
байт |
номер тура |
Таблица 6 - Таблица «Результаты» / «ФиналРезультаты1-6» / «ФиналРезультаты7-10»
поле |
тип данных |
описание |
|
id_res |
счётчик |
первичный ключ |
|
id_tur |
длинное целое |
внешний ключ |
|
command |
длинное целое |
связь с таблицей-словарём с названиями команд - участниц чемпионатов |
|
scored |
байт |
забито мячей в текущем туре |
|
missing |
байт |
пропущено мячей в текущем туре |
Таблица 7 - Таблица-словарь для подстановок в таблицы результатов
поле |
тип данных |
описание |
|
id_command |
счётчик |
первичный ключ |
|
id_name |
текстовый |
название команды |
3.3 Запросы
В соответствии с алгоритмом решения задачи, данные о годе чемпионата и результатах каждого тура предварительного этапа должны вноситься вручную в следующие таблицы: «Год чемпионата», «Тур чемпионата» и «Результаты», соответственно. При этом, для обеспечения целостности данных, их ввод должен происходить в том же порядке, в каком перечислены имена таблиц.
Следующий шаг - подвести итоги предварительного тура в форме таблицы. Но вначале создадим вспомогательный запрос, который формирует таблицу результатов всех туров. Его цель - определить разность забитых и пропущенных мячей и очки, набранные командами в каждом туре. Для этих целей выполняется SQL-запрос:
ЗапросРезультатыТуров
SELECT Команды.id_command, Команды.iName AS Команда, Результаты.scored AS Забито, Результаты.missing AS Пропущено, [Забито]-[Пропущено] AS Разность, IIf([Разность]>0,2,IIf([Разность]=0,1,0)) AS Очки
FROM (Год_чемпионата INNER JOIN Тур_чемпионата ON Год_чемпионата.id_year=Тур_чемпионата.id_year) INNER JOIN (Команды INNER JOIN Результаты ON Команды.id_command=Результаты.comand) ON Тур_чемпионата.id_tur=Результаты.id_tur
WHERE (((Год_чемпионата.iYear)=[Укажите год]));
Пример результата запроса «ЗапросРезультатыТуров» показан на рисунке 6.
Рисунок 6 - Результаты туров
Следующий запрос формирует таблицу итогов предварительного тура с распределением занятых мест, используя вспомогательный запрос «ЗапросРезультатыТуров»:
ЗапросИтогиПредварительногоЭтапа
SELECT ЗапросРезультатыТуров.id_command, ЗапросРезультатыТуров.Команда, Sum(ЗапросРезультатыТуров.Забито) AS [Sum-Забито], Sum(ЗапросРезультатыТуров.Пропущено) AS [Sum-Пропущено], Sum(ЗапросРезультатыТуров.Очки) AS [Sum-Очки], Sum(ЗапросРезультатыТуров.Разность) AS [Sum-Разность]
FROM ЗапросРезультатыТуров
GROUP BY ЗапросРезультатыТуров.id_command, ЗапросРезультатыТуров.Команда
ORDER BY Sum(ЗапросРезультатыТуров.Очки) DESC, Sum(ЗапросРезультатыТуров.Разность) DESC;
Пример данного запроса представлен на рисунке 7.
Рисунок 7 - Итоги предварительного этапа
Зная итоги предварительного тура, заполняем таблицы исходными данными для дальнейшей работы - заполнение таблиц результатами финальных игр. Как уже говорилось, финальных туров будет два - один для команд, занявших места на предварительном этапе с 1 по 6, а другой - для команд - с 7 по 10 место. Результаты игр команд первой группы будут накапливаться в таблицах «ФинальныйТурнир1-6» и «ФиналРезультаты1-6», а второй группы - в таблицах «ФинальныйТурнир7-10» и «ФиналРезультаты7-10», соответственно. Исходными данными для них будут названия команд, занявших соответствующие места по результатам итогов предварительного турнира. Для получения списков этих команд, созданы два запроса. Один формирует список команд с 1 по 6 место (см. пример на рисунке 8):
SELECT TOP 6 ЗапросИтогиПредварительногоЭтапа.id_command, ЗапросИтогиПредварительногоЭтапа.Команда, ЗапросИтогиПредварительногоЭтапа.[Sum-Забито], ЗапросИтогиПредварительногоЭтапа.[Sum-Пропущено], ЗапросИтогиПредварительногоЭтапа.[Sum-Очки], ЗапросИтогиПредварительногоЭтапа.[Sum-Разность]
FROM ЗапросИтогиПредварительногоЭтапа;
а второй список с 7 по 10 место создает запрос (рисунок 9):
SELECT ЗапросTEMP.id_command, ЗапросTEMP.Команда, ЗапросTEMP.[Sum-Забито], ЗапросTEMP.[Sum-Пропущено], ЗапросTEMP.[Sum-Очки], ЗапросTEMP.[Sum-Разность]
FROM ЗапросTEMP
ORDER BY ЗапросTEMP.[Sum-Очки] DESC , ЗапросTEMP.[Sum-Разность] DESC;
Здесь запрос TEMP, является вспомогательным, чтобы получить список команд без сортировки по набранным очкам и разности забитых и пропущенных мячей:
SELECT TOP 4 ЗапросИтогиПредварительногоЭтапа.id_command, ЗапросИтогиПредварительногоЭтапа.Команда, ЗапросИтогиПредварительногоЭтапа.[Sum-Забито], ЗапросИтогиПредварительногоЭтапа.[Sum-Пропущено], ЗапросИтогиПредварительногоЭтапа.[Sum-Очки], ЗапросИтогиПредварительногоЭтапа.[Sum-Разность]
FROM ЗапросИтогиПредварительногоЭтапа
ORDER BY ЗапросИтогиПредварительногоЭтапа.[Sum-Очки], ЗапросИтогиПредварительногоЭтапа.[Sum-Разность];
Рисунок 8 - Команды, занявшие места с 1 по 6
Рисунок 9 - Команды, занявшие места с 7 по 10
Таблицы на рисунках 8 и 9, свою очередь, используется в качестве подстановок для заполнения таблиц «ФиналРезультаты1-6» и «ФиналРезультаты7-10», соответственно. На рисунке 10 представлен пример, демонстрирующий использование данных подстановок.
Рисунок 10 - Использование таблицы на рисунке 8 в качестве подстановки на форме ввода результатов туров в таблицу «ФиналРезультаты1-6».
Для окончательного подведения итогов чемпионата достаточно повторить методику, использованную ранее для подведения итогов предварительного этапа соревнования, но к результатам выступлений команд на финальном этапе:
1. ЗапросФиналИтоги1-6 формирует результаты финального турнира команд, занявших места с 1 по 6:
SELECT [ЗапросРезультатыТуров1-6].comand, Sum([ЗапросРезультатыТуров1-6].scored) AS [Sum-scored], Sum([ЗапросРезультатыТуров1-6].missing) AS [Sum-missing], Sum([ЗапросРезультатыТуров1-6].Очки) AS [Sum-Очки], Sum([ЗапросРезультатыТуров1-6].Разность) AS [Sum-Разность]
FROM [ЗапросРезультатыТуров1-6]
GROUP BY [ЗапросРезультатыТуров1-6].comand
ORDER BY Sum([ЗапросРезультатыТуров1-6].Очки) DESC , Sum([ЗапросРезультатыТуров1-6].Разность) DESC;
(рисунок 11)
Рисунок 11 - Итоги турнира команд первой финальной группы
2. ЗапросФиналИтоги7-10 формирует результаты финального турнира команд, занявших места с 7 по 10:
SELECT [ЗапросРезультатыТуров7-10].comand, Sum([ЗапросРезультатыТуров7-10].scored) AS [Sum-scored], Sum([ЗапросРезультатыТуров7-10].missing) AS [Sum-missing], Sum([ЗапросРезультатыТуров7-10].Очки) AS [Sum-Очки], Sum([ЗапросРезультатыТуров7-10].Разность) AS [Sum-Разность]
FROM [ЗапросРезультатыТуров7-10]
GROUP BY [ЗапросРезультатыТуров7-10].comand
ORDER BY Sum([ЗапросРезультатыТуров7-10].Очки) DESC , Sum([ЗапросРезультатыТуров7-10].Разность) DESC;
(рисунок 12)
Рисунок 12 - Итоги турнира команд второй финальной группы
Описанная методика предоставляет следующие возможности:
· избавляет от необходимости считать очки и определять разность забитых и пропущенных мячей после каждого тура и этапа соревнования;
· автоматически формирует списки команд для финальных подгрупп.
ЗАКЛЮЧЕНИЕ
Результатом данной курсовой работы является база данных итогов чемпионатов по ручному мячу. Она предусматривает ввод результатов туров чемпионата с последующей автоматизацией подведения его итогов. Кроме того, обеспечивается хранение данных об участниках, призёрах и итогах всех прошедших чемпионатов, сведения о которых зафиксированы в базе данных.
Результаты, достигнутые в курсовой работе могут быть адаптированы к другим игровым командным видам спорта, а так же оказаться полезными для организаторов проведения чемпионатов различного уровня.
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ И ЛИТЕРАТУРЫ
1. Сеннов А. Access 2007. Практическая разработка баз данных. Учебный курс [Текст] / А. Сеннов -- СПб.: Питер, 2007. -- 256 с.
2. Бекаревич Ю.Б. Самоучитель Access 2007 [Текст] / Ю.Б. Бекаревич , Н.В. Пушкина -- СПб.: БХВ-Петербург, 2007. -- 720 с.
3. Гурвиц Г.А. Microsoft Access 2007. Разработка приложений на реальном примере [Текст] / Г.А. Гурвиц-- СПб.: БХВ-Петербург, 2007. -- 720 с.
4. Хомоненко А.Д. Базы данных. [Текст] / А.Д. Хомоненко, В.М. Цыганов, М.Г. Мальцев -- СПб.: Корона, 2004. -- 736 с.
5. Кайт Т. Oracle для профессионалов: архитектура, методики, программирования и основные особенности версий 9i и 10g. [Текст] / Т. Кайт -- М.: ООО «И.Д. Вильямс», 2008. -- 848 с.
6. Луни К. Oracle Database 10g. Полный справочник. Т.1, 2. [Текст] / К. Луни -- М.: «Лори», 2008.
7. Борри Х. Firebird: руководство разработчика баз данных. [Текст] / Х. Борри -- СПб.: БХВ-Петербург, 1104. -- 720 с.
8. Дюбуа П. MySQL. [Текст] / П. Дюбуа -- М.: ООО «И.Д. Вильямс», 2007. -- 1168 с.
9. Кузнецов М.В. MySQL 5. [Текст] / М.В. Кузнецов, И.В. Симдяков -- СПб.: БХВ-Петербург, 1104. -- 1024 с.
10. Веллинг Л. MySQL. Учебное пособие. [Текст] / Л. Веллинг, Л. Томсон -- М.: ООО «И.Д. Вильямс», 2005. -- 304 с.
11. Сейед М.М. Руководство по MySQL. [Текст] / М.М. Сейед, Е. Хью, Вильямс-- М.: Издательство «Русская Редакция», 2007. -- 544 с.
12. Харрингтон Дж.Л. Проектирование реляционных баз данных. [Текст] / Дж.Л. Харрингтон -- М.: «Лори», 2006. -- 230 с.
13. Дейт К.Дж. Введение в системы баз данных. [Текст] / К.Дж. Дейт -- М.: ООО «И.Д. Вильямс», 1072. -- 848 с.
14. Крёнке Д. Теория и практика построения баз данных. [Текст] / Д. Крёнке -- СПб.: Питер, 2003. -- 800 с.
15. Райордан Р. Основы реляционных баз данных. [Текст] / Р. Райордан -- М.: Издательско-торговый дом «Русская Редакция», 2001. -- 384 с.
16. Фролов А. В. Базы данных в Интернете: практическое руководство по созданию Web-приложений с базами данных. -- Изд. 2-ое, испр.[Текст] / А.В. Фролов, Г.В. Фролов -- М.: Издательско-торговый дом «Русская Редакция», 2000. -- 448 с.
Размещено на Allbest.ru
Подобные документы
Ввод данных в ячейку из раскрывающегося списка. Проверка содержимого ячеек при вводе данных с клавиатуры. Отмена проверки значения. Таблица после подведения промежуточных итогов. Консолидация данных и порядок ее выполнения, алгоритм и основные этапы.
презентация [1,8 M], добавлен 29.09.2013Понятие базы данных, модели данных. Классификация баз данных. Системы управления базами данных. Этапы, подходы к проектированию базы данных. Разработка базы данных, которая позволит автоматизировать ведение документации, необходимой для деятельности ДЮСШ.
курсовая работа [1,7 M], добавлен 04.06.2015Изучение особенностей функционирования базы данных Excel. Организация ввода и просмотра данных, сортировка, фильтрация и консолидация данных в таблицах. Подведение итогов и сводная таблица. Организация базы данных в Access. Создание запроса и отчетов.
курсовая работа [2,7 M], добавлен 04.10.2013Разработка исходной таблицы для хранения данных о выставках города. Сортировка данных и подведения промежуточных итогов. Параметры сортировки. Пример использования автофильтра. Сводные таблицы. Создание презентации в MS Powerpoint. Слайды презентации.
контрольная работа [4,1 M], добавлен 16.12.2013Авторизация с каталогами проектирования базы данных магазина. Задачи базы данных: учет всех товаров, поиск и выдача данных о клиентах, адрес, телефоны, цена и наличие товара. Этапы проектирования базы данных. Схема данных, создание запросов и их формы.
реферат [1,6 M], добавлен 22.10.2009Сущности и функциональные зависимости базы данных. Атрибуты и связи. Таблицы базы данных. Построение ER-диаграммы. Организация ввода и корректировки данных. Реляционная схема базы данных. Реализация запросов, получение отчетов. Защита базы данных.
курсовая работа [2,4 M], добавлен 06.02.2016Понятие реляционной модели данных, целостность ее сущности и ссылок. Основные этапы создания базы данных, связывание таблиц на схеме данных. Проектирование базы данных книжного каталога "Books" с помощью СУБД Microsoft Access и языка запросов SQL.
курсовая работа [838,9 K], добавлен 25.11.2010Проектирование базы данных "Спортивные соревнования" для автоматизации процесса контроля спортивных соревнований, используя систему управления базами данных MySQL. Разработка клиентского приложения. Диалог с пользователем и функциональные возможности.
курсовая работа [945,4 K], добавлен 03.01.2022Разработка автоматизированной информационной системы предприятия на основе баз данных, которая обеспечивает качественный контроль данных, автоматизацию документооборота, быстрое составление отчетов. Создание форм, отчетов и макросов, меню базы данных.
курсовая работа [4,8 M], добавлен 20.05.2014Создание базы данных "Автовокзал" как части информационной системы. Требования к базе данных и этапы ее разработки. Анализ информационных потоков, выбор модели. Входные и выходные данные. Программирование базы данных на языке Borland Delphi 7.0.
курсовая работа [105,8 K], добавлен 16.05.2011