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

Размещено на 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.

Таблица 2.1

Информационные объекты и их атрибуты

Имя объекта	Атрибут	Признак ключа	Тип данных
Игрок	Код_игрока	Ключ	Счетчик
	Фамилия		Текстовый
	Имя		Текстовый
	Пол		Текстовый
	Дата_рождения		Дата/Время
Игра	Код_игры	Ключ	Счетчик
	Название_игры		Текстовый
	Вид_игры		Числовой
Учет	Код_игрока	Поле связи, входит в составной ключ	Числовой
	Код_игры	Поле связи, входит в составной ключ	Числовой
	Дата_игры		Дата/Время
	Продолжительность_игры		Числовой
	Результат		Текстовый
Вид_игры	Код	Ключ	Счетчик
	Вид_игры		Текстовый

Для функционирования базы данных между таблицами необходимо установить связи. Схема данных приведена на рисунке 2.5.

Рисунок 2.5 Схема данных БД «Компьютерные игры»



3. Разработка приложений с базой данных «Компьютерные игры»

3.1 Запросы

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

При разработке запросов в СУБД можно использовать: режим мастера, режим конструктора, язык SQL.

Первый запрос назовем «Игроки_Девушки». Здесь необходимо отобрать всех игроков женского пола. Данный запрос в режиме SQL будет выглядеть следующим образом:

SELECT Игрок.Фамилия, Игрок.Имя, Игрок.Пол, Игрок.Дата_рождения

FROM Игрок

WHERE (((Игрок.Пол)="жен"));

В режиме конструктор этот запрос приведен на рисунке 3.1.

Рисунок 3.1 Запрос «Игроки_Девушки» в режиме Конструктор

Данный запрос приведем в режиме таблицы на рисунке 3.2.

Рисунок 3.2 Запрос «Игроки_Девушки» в режиме тадлицы

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

SELECT Игра.Название_игры, Учет.Дата_игры

FROM Игра INNER JOIN Учет ON Игра.Код_игры=Учет.Код_игры

WHERE YEAR(Учет.Дата_игры)=год;

Этот запрос приведем в режиме Конструктор (рисунок 3.3) и в режиме таблицы (рисунок 3.4).

Рисунок 3.3 Запрос «Игры заданного года» в режиме Конструктор

Рисунок 3.4 Запрос «Игры заданного года» в режиме таблицы

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

UPDATE Игра SET Игра.Название_игры = "Солитер"

WHERE (((Игра.Название_игры)="Косынка"));

На рисунке 3.5 приведем данный запрос в режиме Конструктор

Рисунок 3.5 Запрос на обновления в режиме Конструктор

Рассмотрим запрос на удаление. После выполнения данного запроса из таблицы Игрок будет удалена запись об игроках, год рождения которых заканчивается на 1. SQL код рассматриваемого запроса приведен ниже

DELETE Игрок.*, Игрок.Дата_рождения

FROM Игрок

WHERE (((Игрок.Дата_рождения) Like "*1"));

В режиме Конструктор данный запрос приведен на рисунке 3.6.

Рисунок 3.6 Запрос на удаление в режиме Конструктор

Далее рассмотрим перекрестный запрос «Количество выигрышей и проигрышей по каждой игре». Результаты представлены в виде сводной таблицы с группировкой по строкам и столбцам и вычислениями по заданной функции (Count). В SQL данный запрос выглядит следующим образом

TRANSFORM Count(Результат)

SELECT Название_игры

FROM Игра INNER JOIN Учет ON Игра.Код_игры=Учет.Код_игры

GROUP BY Название_игры

PIVOT Результат;

Также представим данный запрос в режиме Конструктор (рисунок 3.7) и таблицы (рисунок 3.8).

Рисунок 3.7 Запрос «Количество выигрышей и проигрышей по каждой игре» в режиме Конструктор

Рисунок 3.8 Запрос «Количество выигрышей и проигрышей по каждой игре» в режиме таблицы

3.2 Формы

Cоздадим три формы: Игра, Игрок, Учет. Для этого необходимо на вкладке Создание выбрать Конструктор форм. В заголовке формы добавить надпись с названием формы. В область данных добавить необходимые поля, а также создать кнопки для удобного перемещения по записям. Форму Игра приведем на рисунке 3.9 в режиме Конструктор и на рисунке 3.10 в режиме формы.

Рисунок 3.9 Форма Игра в режиме Конструктор

Рисунок 3.10 Форма Игра в режиме формы

На рисунках 3.11 и 3.12 представлена форма Игрок в режиме Конструктор и режиме формы соответственно.

Рисунок 3.11 Форма Игрок в режиме Конструктор

Рисунок 3.12 Форма Игрок в режиме формы

Форма Учет приведена в режиме Конструктор (рисунок 3.13) и формы (рисунок 3.14).

Рисунок 3.13 Форма Учет в режиме Конструктор

Рисунок 3.14 Форма Учет в режиме формы

3.3 Отчеты

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

Приведем на рисунках 3.15 и 3.16 отчет Игроки_Девушки в режиме Конструктор и режиме представлние отчета соответственно.

Рисунок 3.15 Отчет Игроки_Девушки в режиме Конструктор

Рисунок 3.16 Отчет Игроки_Девушки в режиме представление отчета

Аналогично представлен «Количество выигрышей и проигрышей по каждой игре» отчет (рисунки 3.17 и 3.18)

Рисунок 3.19 Отчет «Количество выигрышей и проигрышей по каждой игре» в режиме Конструктор

Рисунок 3.18 Отчет «Количество выигрышей и проигрышей по каждой игре» в режиме представление отчета

база данные целостность приложение

3.4 Кнопочная форма и интерфейс пользователя

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

Создание и корректировка кнопочной формы производится с помощью надстройки Диспетчер кнопочных форм на закладке Работа с базами данных.

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

После создания всех страниц кнопочной формы и элементов на каждой странице закрываем диспетчер, а в базе данных кнопочная форма и таблица Switchboard Items, которая описывает иерархические уровни, подписи и действия кнопок формы. [8]

Главная страница кнопочной формы приведена на рисунке 3.19.

Рисунок 3.19 главная страница кнопочной формы БД «Компьютерные игры»

При нажатии на кнопку Ввод и просмотр данных открывается следующая страница, приведенная на рисунке 3.20.

Рисунок 3.20 Ввод и просмотр данных

При нажатии кнопок Игрок, Игра и Учет будут соответственно открываться формы с одноименными названиями, приведенные на рисунках 3.10, 3.12 и 3.14.

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

При нажатии на кнопку Отчетность открывается страница приведенная на рисунке 3.21.

Рисунок 3.21 Отчетность

При выборе кнопок «Списки игроков по каждой группе», «Игроки_Девушки», «Игры заданного года» и «Количество выигрышей и проигрышей по каждой игре» откроются соответстаующие им отчеты. Некоторые из них приведены на рисунках 3.16 и 3.18.

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

Кнопка Выход позволяет выйти из программы.

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