Создание базы данных гостиницы "Элеон"

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

Министерство образования, науки и молодежной политики

Краснодарского края

ГБПОУ КК Гулькевичский строительный техникум

Специальность: 09.02.03 Программирование в компьютерных системах

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

Создание базы данных гостиницы "Элеон"

Гулькевичи,2018

Содержание

Введение

1. Анализ предметной области. Постановка задачи

1.1 Описание предметной области и функции решаемых задач

2. Инфологическая (концептуальная) модель базы данных

2.1 Определение отношений и мощности отношений между объектами

2.2 Реализация проекта в среде конкретной СУБД

2.3 Разработка стратегии резервного копирования

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

Введение

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

Основные функции СУБД - это описание структуры базы данных, обработка данных и управление данными.

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

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

· Формирование и подержание базы данных

· Обработка информации

· Прием запросов

· Предоставление информации пользователям

· Обеспечение целостности и реорганизации ценностей базы данных

· Организация совместной работы пользователей

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

1. Анализ предметной области. Постановка задачи

1.1 Описание предметной области и функции решаемых задач

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

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

Основная задача БД - поддержка принятия решений и управление потоками входящей/исходящей информации.

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

Задачи, реализуемые в базе данных, заключаются в следующем:

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

· Формирование оперативных и аналитических отчетов и документов

· Поддержание в актуальном состоянии нормативно-справочной информации (НСИ) системы (описание категорий и номеров, прейскурант цен на проживание и т.д.)

· Обеспечение удобного ввода и удаления данных

· Просмотр уже введенных данных

· Реализация процесса поиска необходимой информации

Перечень входных данных

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

· Данные о заказанных номерах:

категория номера дата заезда, дата выезда, дата бронирования, стоимость, № номера

· Данные об используемых услугах:

номер заказа, номер услуги, дата, количество, общая стоимость.

· Данные о классе обслуживания:

категория номера, стоимость номера.

· Данные о клиентах:

номер клиента, ФИО, номер паспорта, серия паспорта.

· Данные об описании номера:

№ номера, состояние номера.

· Данные о перечне услуг предоставляемые гостиницей: номер услуги, наименование, стоимость.

Перечень выходных данных

При работе с базой данных в гостинице покупатель имеет возможности такие, как:

· Просмотр наличия свободных номеров в гостинице и их характеристики;

· Выбор нужного номера из свободных;

· Регистрация через Интернет или по телефону;

· Знание стоимости каждого номера в отдельности.

При работе с базой данных администратор должен уметь решать следующие задачи такие, как:

· Прием и регистрация новых покупателей в свободные номера, которые выбирают покупатели гостиницы;

· Размещение покупателей в свободные номера, которые выбирают покупатели гостиниц;

· Проведение опроса покупателей, например, для чего или с какой целью прибыли в наш город?

· Заполнение книги регистрации или бюллетень покупателей номеров гостиниц;

· Проведение проверки свободных или купленных номеров;

· Ведение учета, сколько, какие номера свободны или куплены покупателями и сколько по времени они будут заняты.

Ограничения предметной области

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

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

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

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

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

1) Новая функция шифрования действует только в отношении баз данных в формате ACCDB.

2) Это средство использует более стойкий алгоритм шифрования, чем в предыдущих версиях Access.

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

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

1. Монопольный режим.

Чтобы отрыть базу данных в монопольном режиме, следует на вкладке "Файл" выбрать команду "Открыть". В диалоговом окне "Открытие" найти файл, который нужно открыть, и выделить его. Потом нужно нажать на стрелку рядом с кнопкой "Открыть" и выбрать вариант "Монопольно".

2. Открытие задания пароля.

Чтобы открыть поле для задания пароля надо на вкладке "Файл" выбрать пункт "Сведения" и нажать кнопку "Зашифровать паролем".

Должно открыться диалоговое окно для задания пароля:

Вводим пароль в поле "Пароль", повторяем его в поле "Подтверждение" и нажимаем кнопку "ОК".

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

Надежный пароль: QWE123asd

Ненадежный пароль: Rjl123

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

Техническое задание на разработку базы данных.

Выбор средств/методологии проектирования. Выбор СУБД.

Для построения ER-модели было выбрано Visio 2013. Эта программа была выбрана потому, что она позволяет наглядно отображать сложные структуры данных. Visio идеально подходит для ИТ-специалистов, которым требуется интерпретировать, обновлять и передавать сложную информацию о процессах, инфраструктуре и приложениях. Например, Visio может помочь ИТ-специалистам создавать диаграммы, связанные с проектированием систем, разработкой приложений, инженерным проектированием, планированием пространства, устранением неполадок, обслуживанием, управлением активами, технической поддержкой, ИТ-операциями, бизнес-процессами и т.д.

Существует большое число СУБД. Для построения базы данных гостиницы "Элеон" я выбрала СУБД MS Ассеss (2013). MS Access является настольной, смешанной по использованию языков, по выполняемым функциям может быть, как информационной, так и операционной СУБД.

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

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

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

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

2. Инфологическая (концептуальная) модель базы данных

Выделение информационных объектов.

Инфологическое проектирование - построение формализованной модели предметной области. Такая модель строится с использованием стандартных языковых средств, обычно графических.

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

Описание сущностей:

В курсовом проекте гостиницы "Элеон" в соответствии с предметной областью были созданы следующие сущности:

- "Клиенты" - хранится информация о клиентах.

- "Учет работы" - хранится информация о работе сотрудников.

- "Персонал" - хранится информация о сотрудниках.

- "Номера" - хранится информация о номерах.

- "Категории" - хранится информация о категориях номеров в гостинице.

Определение атрибутов объектов.

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

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

Выявленные атрибуты могут быть следующих видов:

· простой (атомарный, неделимый) - состоит из одного компонента с независимым существованием;

· составной - состоит из нескольких компонентов (например, "ФИО", "адрес", и т. д.). Степень атомарности атрибутов, закладываемая в модель, определяется разработчиком. Если от системы не требуется выборки всех клиентов с фамилией Иванов или проживающих на улице Комсомольской, то составные атрибуты можно не разбивать на атомарные;

· однозначный - содержит только одно значение для одного экземпляра сущности (например, у кривой в плане может быть только одно значение радиуса, угла поворота, возвышения наружного рельса и т. д.);

· многозначный - содержит несколько значений;

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

· ключевой - служит для уникальной идентификации экземпляра сущности (входит в состав первичного ключа);

· не ключевой (описательный) - не входит в первичный ключ;

· обязательный - при вводе нового экземпляра в сущность или редактировании обязательно указывается допустимое значение атрибута, т. е. оно после редактирования не может быть неопределенным (NOT NULL).

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

· суперключ (superkey) - атрибут или множество атрибутов, которое единственным образом идентифицирует экземпляр сущности. Суперключ может содержать "лишние" атрибуты, которые необязательны для уникальной идентификации экземпляра. При правильном проектировании структуры БД суперключом в каждой сущности (таблице) будет являться полный набор ее атрибутов;

· потенциальный ключ (potential key) - суперключ, который не содержит подмножества, также являющегося суперключом данной сущности, т. е. суперключ, содержащий минимально необходимый набор атрибутов, единственным образом идентифицирующих экземпляр сущности. Сущность может иметь несколько потенциальных ключей. Если ключ состоит из нескольких атрибутов, то он называется составным ключом. Среди всего множества потенциальных ключей для однозначной идентификации экземпляров выбирают один, так называемый первичный ключ, используемый в дальнейшем для установления связей с другими сущностями;

· первичный ключ (primary key) - потенциальный ключ, который выбран для уникальной идентификации экземпляров внутри сущности;

· альтернативные ключи (alternative key) - потенциальные ключи, которые не выбраны в качестве первичного ключа.

Если некий атрибут (набор атрибутов) присутствует в нескольких сущностях, то его наличие обычно отражает наличие связи между экземплярами этих сущностей. В каждой связи одна сущность выступает как родительская, а другая - в роли дочерней. Это означает, что один экземпляр родительской сущности может быть связан с несколькими экземплярами дочерней. Для поддержки этих связей обе сущности должны содержать наборы атрибутов, по которым они связаны. В родительской сущности это первичный ключ. В дочерней сущности для моделирования связи должен присутствовать набор атрибутов, соответствующий первичному ключу родительской. Однако здесь этот набор атрибутов уже является вторичным ключом. Данный набор атрибутов в дочерней сущности принято называть внешним ключом (foreign key).

Атрибуты объектов:

· Клиенты: код клиента, Ф.И. О., паспортные данные, комментарии.

· Учет работы: код сотрудника, код номера, код клиента, дата заселения,

· дата выселения, стоимость проживания, обслуживание номе 6ра.

· Персонал: код сотрудника, Ф.И. О., должность, образование, дата рождения, паспортные данные, заработная плата.

· Номера: код номера, номер, количество человек, комфортность, цена, обслуживание номера.

2.1 Определение отношений и мощности отношений между объектами

Клиенты - Бронирование:

"Клиенты" главный объект, а "Бронирование" подчиненный объект. Тип связи "один-ко-многим", связь между этими объектами осуществляет "Код клиента".

Клиенты - Поселение:

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

Клиенты - Заказ еды:

"Клиенты" главный объект, а "Заказ еды" подчиненный объект. Тип связи "один-ко-многим", связь между этими объектами осуществляет "Код клиента".

Бронирование - Номера:

"Бронирование" главный объект, а "Номера" подчиненный объект. Тип связи "один-ко-многим", связь между этими объектами осуществляет "Код номера".

Поселение - Номера:

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

Поселение - Скидки при поселении:

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

Заказ еды - Номера:

"Заказ еды" главный объект, а "Номера" подчиненный объект. Тип связи "один-ко-многим", связь между этими объектами осуществляет "Код номера".

Номера - Комфортность:

"Номера" главный объект, а "Комфортность" подчиненный объект. Тип связи "один-ко-многим", связь между этими объектами осуществляет "Комфортность".

Скидки при поселении - Система скидок:

"Скидки при поселении" главный объект, а "Система скидок" подчиненный объект. Тип связи "один-ко-многим", связь между этими объектами осуществляет "Код скидки".

Комфортность - Система скидок_1:

"Комфортность" главный объект, а "Система скидо_1" подчиненный объект. Тип связи "один-ко-многим", связь между этими объектами осуществляет "Код скидки".

Комфортность - Система скидок:

"Комфортность" главный объект, а "Система скидок" подчиненный объект. Тип связи "один-ко-многим", связь между этими объектами осуществляет "Код скидки".



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

Логическая структура базы данных

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

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

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

· определение набора отношений;

· создание диаграммы сущность-связь;

· определение требований поддержки целостности данных.

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

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

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

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

При разработке таблиц базы данных гостиницы можно выделить следующие сущности:

"Клиенты": Для данной сущности выбраны атрибуты, характеризующие свойства клиента, его Ф.И. О., паспортные данные.

"Бронирование": Здесь атрибуты сущности заключаются в том, чтобы клиент мог за ранние забронировать нужный номер в удобное для него время поселения и освобождение.

"Поселение": Атрибуты сущности в том, что сотрудник сам заселяет клиента в номер, забивает в базу ФИО клиента, смотрит свободные номера, также ведется дата поселения и освобождения номера.

"Номера": Атрибуты сущности, № номера, количество проживающих, наименование комфортности номера и цена.

"Комфортность": Атрибут сущности, наименование комфортности.

"Заказ еды": Выбраны атрибуты сущности, заказа, какой именно номер и клиент сделал заказ, также стоимость заказа на 1 персону.

"Система скидок": Атрибуты сущности, наименование скидки и ее размер.

"Скидки при поселении": Атрибуты сущности, определение скидки сотрудником при поселении клиента и наименование скидки.

Можно выделить три типа связей между таблицами:

· идентифицирующая связь - каждой записи одной таблицы соответствует только одна запись другой таблицы;

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

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

Как показано на рисунке 2:

Рисунок 2. Схема базы данных "Гостиницы"

Выше на рисунке 2, отображаются связи таблиц: "клиенты", "бронирование", "поселение", "заказ еды", "скидки при поселении", "номера", "систем скидок", "комфортность", "система скидок_1".

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

Физическая структура базы данных

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

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

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

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

Так как первичный ключ - это некое поле (столбец) или группа полей таблицы базы данных, значение которого (или комбинация значений, которых), используется в качестве однозначного уникального идентификатора записи (строки) этой таблицы, например, в таблице "Клиенты" в качестве первичного ключа целесообразно определить "Код клиента", в таблице "Номера" - поле "№ номера", в таблице "Поселение" - поле "Код скидки", в таблице "Комфортности" - поле "Код комфортности"

2.2 Реализация проекта в среде конкретной СУБД

рисунок 3. Структура таблицы "Бронирование"



рисунок 4. Структура таблицы "Заказ еды "

рисунок 5. Структура таблицы "Клиенты"

рисунок 6. Структура таблицы "Комфортность"



рисунок 7. Структура таблицы "Номера"

рисунок 8. Структура таблицы "Поселение"



рисунок 9. Структура таблицы "Система скидок"

рисунок 10. Структура таблицы "Скидки при поселении"



рисунок 11. Структура запроса "Количество свободных номеров"

рисунок 12. Структура запроса "Суммарная оплата номеров типа Люкс"

рисунок 13. Структура запроса "Список постоянных клиентов со скидкой 10%"



рисунок 14. Структура запроса "Список групп с предварительным заказом"

Разработка интерфейса

Интерфейс разрабатывается с помощью функции "Форма".

Ниже на рисунке 15 была сделана "Главная кнопочная форма" для навигации по другим "Формам" для удобного пользования таблицами.

рисунок 15. Внешний вид главной кнопочной формы



рисунок 16. Внешний вид формы "для поиска номеров"

рисунок 17. Внешний вид формы "Номера"



рисунок 18. Внешний вид формы "Клиенты"

рисунок 19. Внешний вид формы "Бронирования"



рисунок 20. Внешний вид формы "Поселение"

рисунок 21. Внешний вид формы "Заказ еды"



рисунок 22. Внешний вид формы "Комфортности и системы скидок"

Назначение прав доступа

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

Права доступа	Разрешенные действия	Объекты	Дополнительные права
Открытие/запуск (Open/Run)	Открытие базы данных, формы или отчета, запуск макроса	Базы данных, формы, отчеты и макросы
Монопольный доступ (Open Exclusive)	Открытие базы данных для монопольного доступа	Базы данных
Чтение макета (Read Design)	Просмотр объектов в режиме Конструктора	Таблицы, запросы, формы, отчеты и макросы
Изменение макета (Modify Design)	Просмотр и изменение макета объектов или удаление объектов	Таблицы, запросы, формы, отчеты и макросы	Чтение макета, Чтение данных, Обновление данных, Удаление данных
Администратора (Administer)	Для баз данных - установка пароля базы данных, репликация базы данных и изменение параметров запуска. Для обьектов базы данных - все разрешения на объекты и данные, в том числе предоставление разрешений на доступ	Базы данных, таблицы, запросы, формы, отчеты и макросы	Все остальные права
Чтение данных (Read Data)	Просмотр данных	Таблицы и запросы	Чтение макета
Обновление данных (Update Data)	Просмотр и изменение данных, но без их вставки или удаления	Таблицы и запросы	Чтение макета, Чтение данных
Вставка данных (Insert Data)	Просмотр и вставка данных, но без их изменения и удаления	Таблицы и запросы	Чтение макета, Чтение данных
Удаление данных (Delete Data)	Просмотр и удаление данных, но без их изменения и вставки	Таблицы и запросы	Чтение макета, Чтение данных

Создание индексов

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

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

Некоторые общие принципы, связанные с созданием индексов:

· индексы необходимо создавать для столбцов, которые используются в джойнах, по которым часто производится поиск и операции сортировки. При этом необходимо учесть, что индексы всегда автоматически создаются для столбцов, на которые накладывается ограничение primary key. Чаще всего они создаются и для столбцов с foreign key (в Access - автоматически);

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

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

· если поиск постоянно производится по определенному набору столбцов (одновременно), то в этом случае, возможно, есть смысл создать композитный индекс (только в SQL Server) - один индекс для группы столбцов;

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

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

2.3 Разработка стратегии резервного копирования

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

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

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

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

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

Файлы журналов восстановления и файл хронологии восстановления создаются автоматически при создании базы данных (схема 1). Эти файлы журналов применяются при восстановлении утерянных и поврежденных данных.

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

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

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

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

схема 1. Файлы восстановления базы данных

Те данные, которые легко воссоздать, можно хранить в невосстановимых базах данных. К таким данным относятся данные из внешних источников, используемые только для чтения, а также данные, малый объем операций с которыми делает неоправданным дополнительную сложности управления файлами журналов и повтора транзакций при восстановлении. Если оба параметра конфигурации базы данных logarchmeth1 и logarchmeth2 имеют значения "OFF", база данных называется невосстановимой. Это значит, что хранятся только журналы, требуемые для восстановления после отказа. Эти журналы называются активными журналами; они содержат данные текущих транзакций. Восстановление версии при помощи автономных резервных копий - основное средство восстановления невосстановимой базы данных. (Автономность резервной копии означает, что во время резервного копирования другие программы не используют базу данных.) Такую базу данных можно восстановить только в автономном режиме. Она восстанавливается до состояния, предшествующего созданию образа резервной копии. Восстановление путем повтора транзакций для такой базы данных не поддерживается.

Данные, которые нельзя легко воссоздать, надо хранить в восстановимой базе данных. К ним относятся данные, источник которых удаляется после их загрузки, и данные, которые модифицируются прикладными программами или пользователями после загрузки. У восстановимых баз данных значение параметра конфигурации баз данных logarchmeth1 или logarchmeth2 отлично от "OFF". Активные журналы для восстановления после сбоя по-прежнему доступны, но кроме того, появляются архивные журналы с данными принятых транзакций. Такую базу данных можно восстановить только в автономном режиме. Она восстанавливается до состояния, предшествующего созданию образа ее резервной копии. Однако при восстановлении с повтором транзакций можно выполнить повтор транзакций (то есть пройти дальше момента создания образа резервной копии), используя активные и архивные журналы либо до заданного момента времени, либо до окончания активных журналов.

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

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

Операции автоматизированного резервного копирования:

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

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

1. Конноли Т., Бегг К., Страчан А. Базы данных: проектирование, реализация и сопровождение. Теория и практика, 2-е изд.: Пер. с англ. - М.: Издательский дом "Вильямс", 2000. - 1120 с.

2. Карпова Т.С. Базы данных: модели, разработка, реализация. - СПб.: Питер, 2001. - 304 с.

3. Кен Гетц, Пол Литвин, Майк Гилберт. Access . Руководство разработчика. Т.1, 2. Пер. с англ. - К.: Издательская группа BHV, 2000. - 1264 с, 912 c.

4. Ульман Д., Уидом Д. Введение в системы баз данных / Пер. с англ. - М.: "Лори", 2000. - 374 с.

5. Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. Базы данных: Учебник для высших учебных заведений / Под ред. Проф. А.Д. Хомоненко. - Спб.: КОРОНА принт, 2000. - 416 с

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

...