Целостность СУБД. Основные правила целостности. Целостность по сущностям. Целостность по ссылкам. Целостность, определяемая пользователем.

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

Эта цель может быть достигнута лишь в определенных пределах: СУБД не может контролировать правильность каждого отдельного значения, вводимого в базу данных (хотя каждое значение можно проверить на правдоподобность).

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

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

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

3. Целостность, определяемая пользователем. Для любой конкретной базы данных существует ряд дополнительных специфических правил, которые относятся к ней одной и определяются разработчиком. Чаще всего контролируются: уникальность тех или иных атрибутов; диапазон значений (экзаменационная оценка от 2 до 5); принадлежность набору значений (пол "М" или "Ж").

Реляционная модель. Отношение – Таблица. Кортеж – Строка (Запись). Атрибут – Столбец (Поле).

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

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

Отношение является важнейшим понятием и представляет собой двумерную таблицу, содержащую некоторые данные.

Пусть дана совокупность типов данных T₁, T₂, ..., T_n, называемых также доменами, не обязательно различных. Тогда n-арным отношением R, или отношением R степени n называют подмножество декартовa произведения множеств T₁, T₂, ..., T_n^[1][2].

Отношение R состоит из заголовка (схемы) и тела. Заголовок представляет собой множество атрибутов (именованных вхождений домена в заголовок отношения), а тело — множество кортежей, соответствующих заголовку^[2]. Более строго:

• Заголовок (или схема) H отношения R — конечное множество упорядоченных пар вида (A_i, T_i), где A_i — имя атрибута, а T_i — имя типа (домена), i=1,…, n. По определению требуется, чтобы все имена атрибутов в заголовке отношения были различными (уникальными).
• Тело B отношения R — множество кортежей t. Кортеж t, соответствующий заголовку H, — множество упорядоченных триплетов (троек) вида <A_i, T_i, v_i>, по одному такому триплету для каждого атрибута в H, где v_i — допустимое значение типа (домена) T_i. Так как имена атрибутов уникальны, то указание домена в кортеже обычно излишне. Поэтому кортеж t, соответствующий заголовку H, нередко определяют как множество пар (A_i, v_i).

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

9. Информационные системы организаций. Прикладные БД - данные, необходимые для решения одной или нескольких прикладных задач. Предметные БД - данные, относящиеся к какой-либо предметной области (например, финансам, студентам и т.д.).

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

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

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

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

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

Наличие постоянных и разовых пользователей в автоматизированных информационных системах, и, следовательно, наличие потока регламентированных и произвольных по содержанию запросов требуют разработки специальных подходов к определению границ ПО и проектированию состава элементов информационной модели. Поэтому информационные системы больших организаций содержат несколько десятков БД, нередко распределенных между несколькими взаимосвязанными ЭВМ различных подразделений [5, 17]. (Так в больших городах создается не одна, а несколько овощных баз, расположенных в разных районах.)

Если бы в АИС существовал только поток регламентированных запросов и не ожидалось развитие системы, то можно было бы определить границы ПО и осуществить проектирование исходя из анализа содержания всей совокупности запросов пользователей – это так называемый подход к проектированию «от запросов пользователей» [17].

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

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

Такие БД объединяют данные, относящиеся к какой-либо предметной области [5] (например, финансам, обучению, торговле и т.п.) и называются предметными БД (соотносящимся с предметами организации, а не с ее информационными приложениями).

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

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

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

⇐ Предыдущая12345678910Следующая ⇒

Поделиться: