Информационная система туристического клуба

Министерство образования и науки Российской Федерации

Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования

«Комсомольский-на-Амуре государственный

технический университет»

 

 

Факультет компьютерных технологий

Кафедра «Информационные системы»

 

 

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

к курсовой работе

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

Информационная система туристического клуба

 

 

 

 

 

Студентка группы 1БИ(б)-1          Е.М. Халявина

Руководитель проекта           М.Ю. Казаков

Нормоконтролёр                      М.Ю. Казаков

 

 

 

 

2013 
Содержание

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Введение

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

Данная курсовая работа направлена на закрепление знаний и умений по дисциплине «Базы данных» и выработку новых навыков в создании реляционных баз данных.

 

 

 

 

 

 

 

 

 

 

 

 

 

1 Теоретические аспекты проектирования  баз данных

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

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

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

Третий этап проектирования состоит в привязке ДЛМ к среде хранения с помощью модели данных физического уровня. Описание физической структуры БД называется схемой хранения, соответствующий этап проектирования БД – физическим проектированием.

Общие сведения об ИЛМ. В предметной области в результате анализа ИЛМ выделяют классы объектов. Классом объектов называют совокупность объектов, обладающих одинаковым набором свойств.

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

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

Рисунок 1 - Обозначение объектов и их свойств

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

Различают связи типа: один к одному, один ко многим, многие ко многим.

Кроме степени связи в ИЛМ для характеристики связи между разными объектами указывается класс принадлежности, который показывает, может ли отсутствовать связь объекта одного класса с каким-либо объектом другого класса. Различают обязательный и необязательный класс принадлежности.

Среди объектов различают простые и сложные.

Сложные объекты подразделяют на составные, обобщенные и агрегированные.

Составной объект соответствует отображению связи «целое - часть».

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

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

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

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

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

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

Для перехода от ИЛМ к реляционной можно воспользоваться следующими рекомендациями:

1) Для каждого простого объекта  и его единичных свойств строится  таблица, атрибутами которой являются  идентификатор объекта и реквизиты, соответствующие каждому из единичных свойств;

2) Если у объекта имеются множественные  свойства, то каждому из них  ставится в соответствие отдельная таблица;

3) Если между объектом и его  свойством имеется условная связь, то при отображении в реляционную  модель возможны следующие варианты:

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

4) Если связь между объектами 1:1 и классы принадлежности обоих объектов являются обязательными, то для отображения данных объектов и связи между ними:

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

6) Если связь между объектами 1:1 и класс принадлежности одного  объекта является обязательным, а другого – необязательным, то  для каждого из этих объектов  используют отдельные таблицы, а  идентификатор объекта, для которого  класс принадлежности является  необязательным, добавляется в таблицу, соответствующую тому объекту, для  которого класс принадлежности обязательный;

7) Если связь между объектами 1:1 и класс принадлежности каждого  объекта является необязательным, то следует использовать три  таблицы: по одной для каждого  объекта и одно для отображения связи между ними;

8) Если между объектами предметной  области имеется связь 1:М и  класс принадлежности n – связного  объекта является обязательным, то используют две таблицы: по  одной для каждого объекта, и  в таблицу, соответствующую n – связному  объекту, добавляется идентификатор 1 – связного объекта;

9) Если между объектами предметной  области имеется связь 1:М и  класс принадлежности n - связного  объекта является необязательным, то создают три таблицы: по одной для каждого объекта и одну для отображения связи между ними;

10) Если между объектами предметной  области имеется связь М:М, то  для хранения такой информации  потребуется три таблицы: по одной  для каждого объекта и одна  для отображения связи между  ними (классы принадлежности могут  быть: оба – обязательными, оба - необязательными, один – обязательный, другой – необязательный);

11) Агрегированному объекту, имеющему  место в предметной области, в  ДЛМ ставится в соответствие  одна таблица, атрибутами которой  являются идентификаторы всех  объектов, «задействованных» в данном  агрегированном объекте, а также  реквизиты, соответствующие свойствам этого объекта.Такое объединение информации в одну таблицу возможно только в том случае, если между объектами имеется связь 1:1. Если же между объектами имеется связь М:1 (или М:М), то выделяют по одной таблице для каждого объекта и одну таблицу для связи;

12) При отображении обобщенных  объектов могут быть приняты  разные решения:

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

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

Строки таблицы содержат сведения о представленных в ней фактах (об однотипных объектах). На пересечении столбца и строки находятся конкретные значения содержащихся в таблице данных.

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

1) Каждое значение, содержащееся  на пересечении строки и столбца, должно быть атомарным.

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

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

4) Каждое поле имеет уникальное  имя.

5) Последовательность полей в  таблице несущественна.

6) Последовательность записей в  таблице несущественна.

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

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

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

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

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

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

Группа связанных таблиц называется схемой базы данных.

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

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

Пусть имеется отношение r(A1, A2, …, An). Атрибут А2 отношения r функционально зависит от атрибута A1 того же отношения, если в каждый момент времени каждому значению атрибута А1 соответствует не более, чем одно значение атрибута А2 (то есть функциональная зависимость А2 от А1 означает, что если в любой момент времени известно значение А1, то можно однозначно получить и значение А2). Обозначается: А1 ® А2.