- •Курсовой проект
- •Тема: «Проектирование приложения пользователя для ведения учета в турфирме»
- •Список используемых сокращений
- •Содержание
- •Введение
- •3. Разработка информационно-логической модели предметной области.
- •1. Формулировка задания на курсовой проект
- •2. Представление о реляционной модели данных
- •2.1. Определение базы данных
- •2.2. Концептуальная, логическая и физическая модели предметной области
- •2.3. Реляционная модель данных
- •3. Разработка информационно-логической модели предметной области
- •3.1. Описание предметной области и постановка задачи на курсовую работу
- •3.2. Логическое проектирование задачи учета в турфирме
- •3.2.1. Анализ документов
- •3.2.2. Выделение информационных объектов и определение их атрибутов
- •3.2.3. Определение связей и построение илм
- •3.2.4. Разработка контрольного примера
- •4. Создание бд в среде субд Microsoft Access
- •Заключение
- •Список литературных источников
- •Приложение 1 примеры документов учета и отчетности турфирмы
- •Личный листок по учету кадров
- •Агрегированный отчет о финансовых результатах (о прибылях и убытках) за ________год
- •Приложение 2 Категории услуг в отелях и их обозначения типы размещения
- •Классификация номеров
- •Типы питания в отелях
- •Приложение 3 Внесение данных контрольного примера в бд
- •Приложение 4 Интерфейс автоматизированной системы управления учетом в турфирме
2.3. Реляционная модель данных
Модель данных – это совокупность взаимосвязанных структур данных, операций над ними и множества ограничений для хранимых данных.
Выбор той или иной модели данных связан с определенной гипотезой о строении предметной области и, как следствие, с некоторыми допущениями. Исторически сложилось так, что первой появилась иерархическая модель данных, затем сетевая [5, С.29-32].
Подавляющая часть современных БД отвечает реляционной модели данных. Такие БД называются реляционными.
Основной единицей организации данных реляционной БД являются таблицы, соответствующие обычным двумерным таблицам, привычным для пользователя. Между таблицами устанавливаются связи (отношения) для возможности получения необходимых данных из двух и более таблиц. В современных БД, помимо взаимосвязанных таблиц, сохраняются такие объекты как запросы, а также объекты приложений: формы, отчеты, страницы, макросы и модули. Основные элементы реляционной модели отображены в табл. 1.
Таблица 1
Элементы реляционной модели
|
Термин реляционной модели |
Описание |
|
Схема БД |
Набор заголовков таблиц, взаимосвязанных друг с другом |
|
Отношение |
Таблица – совокупность объектов реального мира, которые характеризуются общими свойствами и характеристиками (поля таблицы) |
|
Заголовок отношения |
Заголовок таблицы – названия полей (столбцов) таблицы |
|
Тело отношения |
Тело таблицы – совокупность значений для всех объектов реального мира, которая представима в виде записей таблицы (строки таблицы) |
|
Схема отношения |
Строка заголовков столбцов таблицы («шапка» таблицы) |
|
Атрибут отношения |
Наименование столбца таблицы (поле таблицы) |
|
Значение атрибута |
Значение поля в записи (кортеже) |
|
Первичный ключ |
Один или несколько (в случае составного ключа) атрибутов, которые единственным образом определяют значение кортежа (значение строки таблицы) |
|
Внешний ключ |
Атрибут таблицы, значения которого соответствуют значениям первичного ключа в другой связанной (родительской, первичной) таблице. Внешний ключ может состоять как из одного, так и из нескольких атрибутов (составной внешний ключ). Если число атрибутов внешнего ключа меньше, чем количество атрибутов соответствующего первичного ключа, то он называется усеченным (частичным) внешним ключом |
|
Степень (арность) отношения |
Количество столбцов таблицы |
|
Мощность отношения |
Количество строк (кортежей) таблицы |
|
Экземпляр отношения |
Множество записей (кортежей) для данной таблицы (отношения). С течением времени экземпляр может изменяться. Поскольку обычная БД в текущий момент времени работает только с одной версией отношения, то такой экземпляр отношения называется текущим |
|
Тип данных |
Тип значений элементов таблицы |
|
Базовое отношение |
Отношение, содержащие один или несколько столбцов, характеризующих свойства объекта, а также первичный ключ |
|
Производное отношение |
Не является базовым отношением, т.е. не характеризует свойства объекта и используется для обеспечения связей между другими таблицами, может не содержать первичного ключа. Если первичный ключ задан, то он состоит из внешних ключей, связанных с первичными ключами базового отношения |
|
Связь |
Устанавливает взаимосвязь между совпадающими значениями в ключевых полях – первичным ключом одной таблицы и внешним ключом другой |
|
Связь «один-к-одному» (1:1) |
При использовании этого вида связи запись в одной таблице может иметь не более одной связанной с нею записи в другой таблице. В обеих таблицах ключевые поля должны быть первичными. Используется для разделения таблиц с многочисленными полями или по требованию защиты данных |
|
Связь «один-ко-многим» (1:M) |
При использовании этого вида связи каждой записи одной таблицы может соответствовать несколько записей второй, но каждой записи второй таблицы соответствует лишь одна запись первой таблицы. В первой таблицы обязательно должен быть задан первичный ключ, во второй – внешний |
|
Связь «многие-ко-многим» (N:M) |
При данном типе связи одной записи в первой таблице может соответствовать несколько записей второй таблицы, но и одной записи второй таблицы может соответствовать несколько записей первой. Уникальность ключей для таких таблиц не требуется. В процессе проектирования схемы БД такие связи преобразуют. Для этого необходимо ввести вспомогательное отношение, позволяющее заменить связь «многие-ко-многим» на две связи типа «один-ко-многим» |
Структура данных реляционной модели предполагает представление предметной области рассматриваемой задачи в виде набора взаимосвязанных отношений. В каждой связи одно отношение может выступать как основное (базовое, родительское), а другое – в роли подчиненного (производного, дочернего). Для поддержания этих связей оба отношения должны содержать набор атрибутов, по которым они связаны: в основном отношении это – первичный ключ отношения; в подчиненном отношении должен присутствовать набор атрибутов, соответствующий первичному ключу основного отношения. Здесь этот набор атрибутов уже является вторичным ключом или внешним ключом.
Множество взаимосвязанных друг с другом таблиц образуют схему БД [4, C. 33-44].
Индекс представляет собой средство ускорения поиска записей в таблице, а также других операций, использующих поиск: извлечение, модификацию, сортировку и т. д. Таблицу, для которой используют индекс, называют индексированной. Индекс содержит отсортированную по колонке или нескольким колонкам информацию и указывает на строки, в которых хранится конкретное значение колонки. Индекс выполняет роль оглавления таблиц, просмотр которого предшествует обращению к записям таблицы [4, С.48-52].
Основными ограничениями реляционной модели являются функциональные зависимости между полями реляционных таблиц. Считается, что одно поле в таблице функционально определяет другое, если каждому значению первого поля соответствует единственное значение второго.
Некоторые виды функциональной зависимости могут приводить к избыточности данных в базе. Для ее устранения (минимизации) при проектировании реляционных БД используется нормализация – процесс преобразования данных от одной нормальной формы к другой, боле высокой.
Нормальные формы (НФ) формируются последовательно и по возрастанию (1НФ, 2НФ, 3НФ), и чем больше номер, тем больше ограничений на хранимые значения должно соблюдаться в соответствующей реляционной таблице. Любая реляционная таблица находится в первой нормальной форме (1НФ).
Во второй нормальной форме (2НФ) в таблице не должно быть полей, зависящих только от части составного ключа (а не от него целиком).
Таблица может соответствовать 2 НФ, однако одно из полей может зависеть от ключа через другое не ключевое поле, что приводит к избыточности. Устранение этого недостатка приводит БД в соответствие с 3 НФ.
Для обеспечения целостности данных в реляционных БД должны выполняться определенные правила. Так для любой таблицы первичный ключ должен быть уникальным и не пустым (иметь конкретное значение). Для связанных таблиц все связи должны быть реальными, т.е. каждый вторичный ключ в подчиненной таблице должен ссылаться на действующий первичный ключ в главной таблице [2, 6].