Способы обеспечения целостности данных реферат

Методы и средства обеспечения целост­ности данных

Содержание:

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

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

Методы и средства обеспечения целост­ности данных

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

• резервное копирование данных;
• продуманная настройка и поддержание требуемых («безопасных») зна­чений системных параметров;
• заблаговременная установка и освоение специализированных про­граммных средств восстановления данных.

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

Резервное копирование данных

Резервное копирование можно считать панацеей практически во всех ситуаци­ях, связанных с потерей или искажением данных. Одна­ко действительно универсальным «лекарством» резервное копирование ока­жется лишь в том случае, если соблюдать правила его применения. Особенности восстановления различных видов данных на основе резервных копий будут приведены в соответствующих главах раздела сейчас рассмотрим общие принципы резервного копирования.

Архивация и резервное копирование

Два этих понятия так часто используются совместно и публикациях и при ра­боте с данными, что иногда даже начинают восприниматься как синонимы. На самом деле, хотя архивация (английский термин archiving) и резервное копирование (backup) — большие «друзья», они вовсе не близнецы и вообще не «родственники».

Архивация очень близка к созданию некомпьютерных, «бумаж­ных» архивов. Архив — это место, приспособленное для хранения документов, которые либо потеряли свою актуальность, ли­бо используются относительно редко.

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

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

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

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

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

Методы резервного копирования

Резервное копирование обычно осуществляется в соответствии с одним из трех основных методов: полным, инкрементальным и дифференциальным.

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

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

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

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

Главной проблемой инкрементального и дифференциального копирования яв­ляется проблема выбора надежного критерия модификации файла. Обыч­но в качестве такового выступает атрибут Archive время создания/модификации файлов, размер файла или контрольная сумма содержимого файла. К сожалению, все они имеют те или иные недостатки, свя­занные с особенностями обработки атрибутов и прав доступа отдельными при­кладными программами.

Некоторые из современных программных средств резервного копирования предлагают принципиально иной подход к созданию резервных копий, который иногда называют копированием на лету. Его идея состоит в том, что любые изменения файлов, указан­ных пользователем при настройке программы, сразу переносятся в резервную копию. При очевидной простоте метода, он обладает целым рядом недостатков. Основной из них заключается в том, что произведенные изменения могут быть обусловлены ошибочными дей­ствиями пользователя или работой вредоносных программ. В результате возврат к «правильной» версии файла может оказаться невозможным.

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

С одной стороны, чем чаще выполняется копирование, тем более «свежая» ин­формация будет сохранена в качестве резервной копии. С другой стороны, ка­ждый сеанс резервного копирования требует определенных дополнительных затрат: и времени, и резервных носителей.

Для оптимизации числа используемых резервных носителей разработаны спе­циальные алгоритмы замены носителей (так называемые схемы ротации но­сителей). Наиболее часто используют следующие схемы:

• одноразовое копирование;
• простая ротация;
• «дед, отец, сын»;
• «Ханойская башня»;
• «10 наборов».

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

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

Схема «дед, отец, сын» имеет иерархическую структуру и предполагает ис­пользование комплекта из трех наборов носителей. Раз в неделю делается пол­ная копия дисков компьютера, ежедневно же проводится инкрементальное (или дифференциальное) копирование. Дополнительно раз в месяц произво­дится еще одно полное копирование. Набор для ежедневного инкрементально­го копирования называется «сыном», для еженедельного — «отцом», а для еже­месячного — «дедом». Состав носителей в ежедневном и еженедельном наборах является постоянным. При этом в ежедневном наборе каждый носитель соот­ветствует определенному дню недели, а в еженедельном наборе – каждой неделе месяца. Носители из «ежемесячного» набора обычно заново не исполь­зуются и откладываются в архив. Недостаток данной схемы состоит в том, что в архиве находятся только данные, имевшиеся на конец месяца. Как и при про­стой ротации, ежедневные копии подвергаются значительному износу, в то время как нагрузка на еженедельные копии сравнительно невелика.

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

Схема «10 наборов» также используется нечасто. Как следует из названия, схема рассчитана на использование 10 наборов носителей. Период из 40 недель делится на десять циклов. В пределах цикла за каждым набором закреплен один день недели. По прошествии четырехнедельного цикла осуществляется переход к следующему набору. Например, если в первом цикле понедельнику соответствовал набор 1, а за вторник — набор 2, то во втором цикле понедель­нику будет соответствовать набор 2, а вторнику — набор 3. Такая схема позво­ляет равномерно распределить нагрузку и, как следствие, выровнять износ но­сителей.

Вывод

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

Источник

Целостность базы данных

Проблемы поддержания целостности баз данных на примере реляционной системы управления базами данных. Построение концептуальной и логической модели данных. Разработка приложений с базой данных «Компьютерные игры». Кнопочная форма и интерфейс пользователя.

Рубрика	Программирование, компьютеры и кибернетика
Вид	курсовая работа
Язык	русский
Дата добавления	18.12.2014
Размер файла	2,3 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

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

1. Целостность базы данных

1.1 Обеспечение целостности данных

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

Целостность БД не гарантирует достоверности содержащейся в ней информации, но обеспечивает, по крайней мере, правдоподобность этой информации, отвергая заведомо невероятные, невозможные значения. Таким образом, не следует путать целостность БД с достоверностью БД. Достоверность (или истинность) есть соответствие фактов, хранящихся в базе данных, реальному миру. Очевидно, что для определения достоверности БД требуется обладание полными знаниями как о содержимом БД, так и о реальном мире. Для определения целостности БД требуется лишь обладание знаниями о содержимом БД и о заданных для неё правилах. Поэтому СУБД может (и должна) контролировать целостность БД, но принципиально не в состоянии контролировать достоверность БД. Контроль достоверности БД может быть возложен только на человека, да и то в ограниченных масштабах, поскольку в ряде случаев люди тоже не обладают полнотой знаний о реальном мире. [3]

Одной из важнейших задач, решаемой СУБД, является поддержание в любой момент времени взаимной непротиворечивости, правильности и точности данных, хранящихся в БД. Этот процесс называется обеспечением целостности базы данных.

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

Целостность базы данных может быть нарушена в результате сбоя оборудования; программной ошибки в СУБД, операционной системе или прикладной программе; неправильных действий пользователей. Эти ситуации могут возникать даже в хорошо проверенных и отлаженных системах, несмотря на применяемые системы контроля. Поэтому СУБД должна иметь средства обнаружения таких ситуаций и восстановления правильного состояния базы данных.

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

Обеспечение целостности данных гарантирует качество данных в таблице.

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

1. Сущностная целостность — определяет строку как уникальную сущность в конкретной таблице. Она обеспечивает целостность столбцов идентификаторов или первичного ключа таблицы с помощью индексов и ограничений UNIQUE или PRIMARY KEY.

2. Доменная целостность — это достоверность записей в конкретном столбце. Она включает ограничения типа данных, ограничения формата при помощи ограничений CHECK и правил, а также ограничения диапазона возможных значений при помощи ограничений FOREIGN KEY, CHECK, DEFAULT, определений NOT NULL и правил.

3. Ссылочная целостность — сохраняет определенные связи между таблицами при добавлении или удалении строк.[4]

В SQL Server ссылочная целостность основана на связи первичных и внешних ключей (либо внешних и уникальных ключей) и обеспечивается с помощью ограничений FOREIGN KEY и CHECK. Ссылочная целостность гарантирует согласованность значений ключей во всех таблицах. Этот вид целостности требует отсутствия ссылок на несуществующие значения, а также обеспечивает согласованное изменение ссылок во всей базе данных при изменении значения ключа.

При обеспечении ссылочной целостности SQL Server не допускает следующих действий пользователей:

— Добавления или изменения строк в связанной таблице, если в первичной таблице нет соответствующей строки;

— Изменения значений в первичной таблице, которое приводит к появлению потерянных строк в связанной таблице;

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

4. Пользовательская целостность — позволяет определять бизнес-правила, не входящие ни в одну из категорий целостности. Поддержку пользовательской целостности обеспечивают все остальные категории целостности: любые типы ограничений уровня столбца и уровня таблицы в инструкции CREATE TABLE, хранимых процедурах и триггерах.[2]

1.2 Ограничения целостности

Ограничения целостности могут определяться: спецификой предметной области (возраст сотрудников организации может находиться в диапазоне от 16 до 80 лет) и непосредственно информационными характеристиками (артикул товара должен быть целым числом).

В процессе работы пользователя с базой данных СУБД проверяет, соответствуют ли выполняемые действия установленным ограничениям целостности. Действия, нарушающие целостность базы данных, отменяются, при этом обычно выводится соответствующее информационное сообщение.[1]

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

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

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

1. Для поля устанавливается конкретный тип данных: текстовый, числовой, дата/время, логический и т. д. Это не позволяет вводить, например, в числовое поле текст или даты, в поле с типом данных дата/время — числа.

2. Домен указывается непосредственно — перечислением входящих в него значений или с помощью указания диапазона допустимых значений.

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

Тип данных создаваемого поля выбирается из предложенного списка доступных типов. При необходимости с помощью свойства поля Размер поля можно уточнить область определения размещаемых в нем данных. Указывается максимальный размер данных, сохраняемых в поле: количество символов для тестовых полей; размеры поля для числовых полей: байт (целое число от 0 до 255), целое (число в диапазоне от минус 32768 до 32768), одинарное с плавающей точкой и т. д.

Частным случаем определения домена можно считать автоматическое (по умолчанию) задание конкретного значения данных в некотором поле (в MS Access свойство поля Значение по умолчанию).

Некоторые нарушения целостности полей таблиц базы данных СУБД контролирует автоматически. Например, в поле, для которого определен тип данных дата/время, невозможно ввести значения 10.15.05 или 35.01.05.

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

Для полей таблиц могут поддерживаться и другие ограничения целостности.

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

2. Контролируется уникальность значений данных в поле. Если поле является простым первичным ключом таблицы, проверка уникальности значений данных в этом поле выполняется СУБД автоматически. При наличии в таблице вероятных простых ключей, можно исключить ввод в соответствующие поля повторяющихся значений данных. Для этого в MS Access для этих полей в свойстве Индексированное поле устанавливается значение Да (Совпадения не допускаются).[5]

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

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

2. Проектирование базы данных «Компьютерные игры»

2.1 Анализ предметной области

В курсовой работе необходимо построить базу данных «Компьютерные игры». Использовать необходимо следующие сущности: Игра, Игрок, Учет. Сущность «Игра» будет хранить информацию о всех сыгранных играх. Таблица «Игрок» будет содержать информацию о существующих игроках, а в таблице «Учет» будет вестись статистика победителей по каждой конкретной игре, также эта база данных позволяет определить какие игры предпочитает конкретный игрок. Также введем таблицу — справочник «Вид_игры», информацию которой будем использовать для подстановки в таблицу «Игра».

2.2 Построение концептуальной и логической модели данных

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

Для более детального изучения предметной области можно выделить два информационных объекта ИГРА и ИГРОК, которые будут находиться в отношении многие-ко-многим, то есть игрок может сыграть в несколько игр, а одна и та же игра может быть выбрана игроками неоднократно. Таким образом, между этими объектами можно определить связь ИГРАЕТ, составленную и множества пар, в каждой из которых имеется игрок и выбранная им игра. Полученная структура также является информационным объектом, позволяющим вести учет сыгранных игр. При этом игрок выбирает конкретную игру, имеющую свой уникальный номер, поэтому нет необходимости вносить полную информацию об игре каждый раз, когда ее выбрали, будет достаточно указать ее номер. Из объекта ИГРА можно выделить еще один объект — ВИД_ИГРЫ. Окончательный вариант ER-диаграммы представлен на рисунке 2.1.

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

Рисунок 2.1 ER-диаграмма

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

Существует 2 вида схем для рассмотрения логической структуры модели процесса функционирования систем: обобщенные схемы и детальные схемы моделирующих алгоритмов.

Укрупненная (обобщенная) схема модели задает общий порядок действий без каких-либо уточняющих деталей. Детальная схема модели содержит уточнения, отсутствующие в обобщенной схеме, и показывает, что следует выполнить на каждом шаге и как это выполнить. При ее построении учитывается, что моделирующий механизм имеет блочную структуру. Фактически обобщенная схема — это обобщенный вид блок-схемы, показывающий основные этапы.

Логическая модель базы данных приведена на рисунке 2.2.

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

Рисунок 2.2 Логическая модель данных

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

2.3 Физическая модель данных

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

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

Для создания таблицы Игра необходимо открыть Конструктор таблиц на вкладке Создание. В колонке Имя поля задаем имена полей: Код_игры, Название_игры, Вид_игры. Выбираем соответственно тип данных этих полей: Счетчик, Текстовый, Числовой. Поле Код_игры необходимо сделать ключевым, для связи этой таблицы с другими. Для этого нужно нажать кнопку Ключевое поля на вкладке Сервис. Данная таблица приводится в режиме Конструктор на рисунке 2.3 и в Режиме таблицы на рисунке 2.4.

Рисунок 2.3 Таблица Игра в режиме Конструктор

Рисунок 2.4 Таблица Игра в режиме таблицы

Аналогичным образом создаем таблицы Игрок, Учет и Вид_игры. Структура всех таблиц приведена в таблице 2.1.

Источник