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

УрГУПС
Кафедра «Связь»
Курсовая работа.

Проектирование базы данных.
Работу выполнил:

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

Медведев Н.В.
Работу проверил:

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

Пащенко М.А.
Екатеринбург,

2006 г.

Содержание

Введение 3

1. 
   Инфологическое проектирование 5
   
   1. 
      Описание предметной области 5
      
   2. 
      Описание информационных потребностей пользователей 5
      
   3. 
      Построение инфологической модели 6
      
2. 
   Даталогическое проектирование 7
   
   1. 
      Выбор и характеристика СУБД 7
      
   2. 
      Построение даталогической модели 9
      
   3. 
      Создание базы данных 11
      
   4. 
      Заполнение БД 12
      
   5. 
      Запросы к БД 14
      

Заключение 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<p<16) и знак; с помощью q задается число цифр справа от десятичной точки (q<p, если q = 0, оно может быть опущено);

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

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

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. Для этого нужно каждой сущности и характеристикам поставить в соответствие набор отношений (таблиц) и их атрибутов (полей).

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


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

Сущность	Соответствие
Команда	Team
Члены команды	Ludi
Матчи	Matchi
Тренер	Trener
Чемпионат	Chemp
Работает	Work1
Позиция	Pozitziya

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

Атрибуты	Соответствие
Фамилия	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

Рисунок 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");

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».



2.5. Запросы к БД

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. Выводит количество играков каждой команды:

select nazvanie, count(famil) from ludi, team where team.kod_komandi=ludi.kod_komandi group by nazvanie;



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

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




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


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

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