Управление транзакциями
Транзакцией называется последовательность операций над базой данных, рассмат-риваемых СУБД как единое целое. Если все операции успешно выполнены, то тран-закция также считается успешно выполненной, и СУБД фиксирует (commit) все изменения данных, произведенные этой транзакцией (то есть заносит изменения во внешнюю память). Если же хотя бы одна операция транзакции заканчивается неудачей, то транзакция считается невыполненной, и производится ее откат (rollback) с отменой всех изменений данных, произведенных в ходе выполнения транзакции, и возвращением базы данных к состоянию до начала выполнения транзакции.
Управление транзакциями необходимо для поддержания логической целостности базы данных.
Поддержка механизма транзакций является обязательным условием работы даже однопользовательских, а тем более многопользовательских СУБД. Поскольку каждая транзакция начинается при целостном состоянии базы данных и оставляет это состояние целостным после своего завершения, понятие транзакции очень удобно использовать как единицу активности пользователя по отношению к базе данных. При должном управлении параллельно выполняющимися транзакциями со стороны СУБД каждый из пользователей может, в принципе, ощущать себя единственным пользователем СУБД.
С управлением транзакциями в многопользовательской СУБД связаны важные понятия сериализации и плана сериализации смеси транзакций. Под сериализации понимается параллельное выполнение смеси транзакций, результат которого эквивалентен результату их последовательного выполнения. План сериализации смеси транзакций — это такой план, который приводит к сериализации транзакций. Понятно, что если удается добиться реальной сериализации смеси транзакций, то для каждого пользователя, по инициативе которого начата транзакция, выполнение других транзакций будет незаметным (если не считать некоторого замедления работы по сравнению с однопользовательским режимом). Существует несколько базовых алгоритмов сериализации транзакций. В централизованных СУБД наиболее распространены алгоритмы, основанные на синхронизированных захватах объектов базы данных. При использовании любого алгоритма сериализации возможны конфликты между несколькими транзакциями по доступу к объектам базы данных. В этом случае для поддержания сериализации необходимо выполнить откат одной или нескольких транзакций. Это один из случаев, когда пользователь многопользовательской СУБД может реально (и достаточно неприятно) ощутить присутствие в системе обработки транзакций других пользователей.
Протоколирование
Одним из основных требований к СУБД является надежность хранения данных во внешней памяти. Под надежностью хранения понимается то, что СУБД должна быть в состоянии восстановить последнее согласованное состояние БД после любого аппаратного или программного сбоя.
Аппаратные сбои обычно подразделяются на два вида:
□ мягкие сбои связаны с внезапной остановкой компьютера и обычно являются следствием внезапного выключения питания или «зависания» операционной системы;
□ жесткие сбои характеризуются потерей информации на носителях внешней памяти.
Программные сбои обычно возникают вследствие ошибок в программах. Причем эти ошибки могут быть как в самой СУБД, что может привести к аварийному завершению ее работы, так и в пользовательской программе. Первый случай можно рассматривать как разновидность мягкого аппаратного сбоя. Во втором случае незавершенной остается только одна транзакция.
В любом случае для восстановления информации в базе данных необходимо иметь некоторую дополнительную информацию. Таким образом, для надежного хранения данных требуется их избыточность. Причем та часть информации, которая используется для восстановления, должна храниться особо надежно. Наиболее распространенным методом поддержания такой избыточной информации является ведение журнала изменений базы данных.
Журнал представляет собой недоступную пользователям и поддерживаемую с особой тщательностью часть базы данных, в которую поступают записи обо всех изменениях основной части базы данных. Иногда используются две копии журнала, располагаемые на разных физических дисках.
В разных СУБД изменения базы данных протоколируются на разных уровнях: иногда запись в журнале соответствует некоторой логической операции изменения базы данных, иногда — минимальной внутренней операции модификации страницы внешней памяти. Могут также использоваться одновременно оба иод-хода.
Во всех случаях придерживаются стратегии упреждающей записи в журнал (Write Ahead Log, WAL). Несколько утрируя, можно сказать, что эта стратегия подразумевает внесение в журнал записи об изменении любого объекта базы данных до того, как будет выполнено и зафиксировано изменение этого объекта. Если в СУБД поддерживается протокол WAL, то с помощью журнала можно решить все проблемы восстановления базы данных после любого сбоя.
Самая простая ситуация восстановления — откат отдельной транзакции. Строго говоря, для этого не требуется общесистемный журнал изменений базы данных. Достаточно для каждой транзакции поддерживать локальный журнал операций модификации базы данных, выполненных в этой транзакции, и производить откат транзакции путем выполнения обратных операций, следуя от конца локального журнала. В некоторых СУБД так и делают, но в большинстве систем локальные журналы не поддерживают, а откат отдельной транзакции выполняют по общеси-стемному журналу, для чего все записи, относящиеся к одной транзакции, связывают обратным списком (от конца к началу).
При мягком сбое во внешней памяти основной части базы данных могут находиться объекты, модифицированные транзакциями, не закончившимися к моменту сбоя, и могут отсутствовать объекты, модифицированные транзакциями, которые к моменту сбоя успешно завершились (по причине очистки буферов оперативной памяти при мягком сбое). При соблюдении протокола WAL во внешней памяти журнала должны гарантированно находиться записи, относящиеся к операциям модификации обоих видов объектов. Целью восстановления после мягкого сбоя является приведение внешней памяти основной части базы данных в такое состояние, которое возникло бы при фиксации во внешней памяти изменений всех завершившихся транзакций и не содержало бы никаких следов незаконченных транзакций. Для того чтобы этого добиться, сначала производят откат незавершенных транзакций, а потом повторно воспроизводят те операции завершенных транзакций, результаты которых не сохранились во внешней памяти.
Для восстановления базы данных после жесткого сбоя используют журнал и архивную копию базы данных. Архивная копия — это полная копия базы данных, полученная к началу заполнения журнала (хотя имеются и другие варианты трактовки этого термина). Естественно, для нормального восстановления базы данных после жесткого сбоя необходимо, чтобы журнал не пропал. Тогда восстановление базы данных состоит в том, что на основе данных архивной копии по журналу повторно выполняются все транзакции, которые закончились к моменту сбоя. В принципе, можно даже воспроизвести работу незавершенных транзакций и продолжить их работу после завершения восстановления. Однако в реальных системах это обычно не делается, поскольку процесс восстановления после жесткого сбоя является достаточно длительным.
Поддержка языков баз данных
Для работы с информацией, хранящейся в базе данных, используются специальные языки, носящие общее название языков баз данных. Чаще всего выделяется два языка:
□ язык определения схем данных (Schema Definition Language, SDL) служит главным образом для определения логической структуры базы данных;
□ язык манипулирования данными (Data Manipulation Language, DML) содержит набор операторов манипулирования данными, то есть операторов, позволяющих заносить данные в базу, а также удалять, модифицировать или выбирать существующие данные.
Несколько разных специализированных языков баз данных поддерживалось лишь в ранних СУБД. В современных СУБД обычно поддерживается единый интегри-рованный язык, содержащий все необходимые средства для работы с базой данных, начиная от ее создания, и обеспечивающий базовый пользовательский интерфейс с базами данных. Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL (Structured Query Language — язык структурированных запросов). Таким образом, указанные выше языки баз данных на сегодняшний день, фактически, являются подмножествами единого стандартного языка SQL.
Язык SQL позволяет определять схему реляционной базы данных и манипулировать данными. При этом именование объектов базы данных (для реляционной базы данных — именование таблиц и их полей) поддерживается на языковом уровне в том смысле, что компилятор языка SQL производит преобразование имен объектов в их внутренние идентификаторы на основании специально поддерживаемых служебных таблиц-каталогов.
Язык SQL содержит специальные средства определения ограничений целостности базы данных. Опять же, ограничения целостности хранятся в специальных таб-лицах-каталогах, и контроль целостности базы данных производится на языковом уровне — при компиляции операторов модификации базы данных компилятор SQL на основании имеющихся в базе данных ограничений целостности генерирует со-ответствующий программный код.
Специальные операторы языка SQL позволяют определять так называемые пред-ставления базы данных, фактически являющиеся хранимыми в базе данных запросами (результатом любого запроса к реляционной базе данных является таблица) с именованными столбцами, называемыми полями. Для пользователя представление является такой же таблицей, как любая базовая таблица, хранимая в базе данных, но с помощью представлений можно ограничить или, наоборот, расширить видимость данных для конкретного пользователя. Поддержка представлений производится также на языковом уровне.
Наконец, авторизация доступа к объектам базы данных тоже производится на основе специального набора SQL-операторов. Идея состоит в том, что для выполнения разных SQL-операторов пользователь должен обладать разными полномочиями. Пользователь, создавший таблицу базы данных, обладает полным набором полномочий для работы с данной таблицей. В число этих полномочий входит пол-номочие на передачу всех или части полномочий другим пользователям, включая полномочие на передачу полномочий. Полномочия пользователей описываются в специальных таблицах-каталогах, контроль полномочий поддерживается на языковом уровне.
ПРИМЕЧАНИЕ
Здесь дается лишь общее представление о языке SQL. Более подробно данный язык и его функции рассматриваются далее.
Билет 59.
Эволюция систем управления базами данных
На эволюцию СУБД существенное влияние оказывает бурное развитие микроэлектронных технологий и связанное с этим развитие персональных компьютеров. Темпы развития персональных компьютеров за последние 15-20 лет существенно превышают темпы развития «больших» ЭВМ. Область применения персональных компьютеров за последние несколько лет существенно расширилась. Можно выделить основные причины этой тенденции:
□ цена персональных компьютеров значительно ниже, чем больших ЭВМ;
□ по функциональным возможностям персональные компьютеры превосходят большие ЭВМ;
□ существенно сократился разрыв между производительностью персональных компьютеров и больших ЭВМ, кроме того, для многих задач обработки данных производительность компьютера не является решающим фактором;
□ архитектура систем на основе персональных компьютеров обладает большей гибкостью и мобильностью, а сфера их использования значительно шире области применения больших ЭВМ.
Общая тенденция движения от отдельных больших вычислительных машин (mainframes) к открытым распределенным системам оказала огромное влияние на развитие архитектур СУБД и поставила перед их разработчиками ряд сложных проблем. Главная проблема состояла в технологической сложности перехода от централизованного управления данными на одном компьютере и СУБД с собственными моделями, форматами представления данных и языками доступа к данным, к распределенной обработке данных в неоднородной вычислительной среде, состоящей из объединенных в сеть компьютеров различных моделей и производителей.
Постепенный переход от вычислительных систем на основе больших ЭВМ и централизованного управления данными к распределенным системам на основе персональных компьютеров, а также внедрение персональных компьютеров практически во все сферы деятельности привели и к изменению подходов к организации систем управления базами данных. В истории развития и совершенствования систем управления базами данных можно условно выделить три основных этапа. Кратко рассмотрим каждый из них.
СУБД первого поколения
Первый этап был связан с созданием первого поколения СУБД, опиравшихся на иерархическую и сетевую модели данных (на основе спецификаций CODASYL). В этот период времени на рынке вычислительной техники доминировали большие вычислительные машины, такие как IBM 360/370, которые в совокупности с СУБД первого поколения составили аппаратно-программную платформу больших информационных систем. СУБД первого поколения были в подавляющем большинстве закрытыми системами: отсутствовал стандарт внешних интерфейсов, не обеспечивалась переносимость прикладных программ.
Ранние СУБД с сегодняшней точки зрения имели массу недостатков, из которых наиболее существенными были:
□ сложность использования;
□ необходимость знать физическую организацию базы данных;
□ сильная зависимость прикладных систем от физической организации базы данных;
□ перегрузка логики прикладных систем деталями организации доступа к базе данных;
□ отсутствие средств автоматизации проектирования баз данных;
□ очень высокая стоимость.
Среди достоинств СУБД первого поколения можно отметить:
□ наличие развитых средств управления данными во внешней памяти на низком уровне;
□ возможность построения эффективных прикладных систем вручную;
□ возможность экономии памяти за счет совместного использования объектов (в сетевых системах).
Несмотря на все свои недостатки, СУБД первого поколения оказались весьма долговечными: разработанное на их основе программное обеспечение используется по сей день, и большие ЭВМ по-прежнему хранят огромные массивы актуальной информации. Главной причиной этого является, вероятно, экономический фактор — в свое время в аппаратное и программное обеспечение больших ЭВМ были вложены огромные средства, в результате многие продолжают их использовать, несмотря на морально устаревшую архитектуру. В то же время перенос данных и программ с больших ЭВМ на компьютеры нового поколения сам по себе представляет сложную техническую проблему и требует значительных затрат.
Билет 60.
Реляционные СУБД
Началом второго этапа в эволюции СУБД можно считать публикации в начале 70-х годов ряда статей Э. Кодда (Coad), в которых выдвигались, по сути, революционные идеи, существенно изменившие устоявшиеся представления о базах данных.
Будучи математиком по образованию, Кодд предложил использовать для обработки данных аппарат теории множеств (объединение, пересечение, разность, декартово произведение). Он показал, что любое представление данных сводится к совокупности двухмерных таблиц особого вида, известного в математике как отношение (по-английски — relationship, отсюда и название — реляционные базы данных).
Одна из главных идей Кодда заключалась в том, что связь между данными должна устанавливаться в соответствии с их внутренними логическими взаимоотношениями.
ПРИМЕЧАНИЕ
В СУБД первого поколения для связи записей из разных файлов использовались физические указатели или адреса на диске. Это означало, что в том случае, когда в разных файлах хранится логически связанная информация, а физическая связь между этими файлами отсутствует, для получения выборки (извлечения информации) из такой базы данных необходимо использовать низкоуровневые средства работы с файлами. В случае же реляционной базы данных сама СУБД поддерживает извлечение информации из базы данных на основе логических связей, и при работе с базой данных нет необходимости напрямую программировать обращения к файлам. Естественно, это существенно упрощает работу с базами данных.
Второй важный принцип, предложенный Коддом, заключается в том, что в реляционных системах одной командой могут обрабатываться целые файлы данных, в то время как в ранних СУБД одной командой обрабатывалась только одна запись. Реализация этого принципа существенно повысила эффективность программирования баз данных.
Реализация реляционных принципов в СУБД сделала возможным разработку простых языков запросов, вполне доступных пользователям, не являющимся специалистами в области программирования. Таким образом, благодаря снижению требований к квалификации существенно расширился круг пользователей баз данных.
ПРИМЕЧАНИЕ
На начальном этапе развития реляционных баз данных было разработано несколько языков запросов, среди которых наиболее известны QBE (Query by Example — запрос по образцу), Quel (Query Language — язык запросов) и SQL (Structured Query Lan-guage-структурированный язык запросов). Среди этих языков на сегодняшний день наибольшее распространение получил SQL, который в 1986 г. был принят институтом ANSI (American National Standards Institute — Американский национальный институт стандартов) в качестве стандарта языков реляционных баз данных. Последнее обновление этого стандарта было принято в 1992 г., и язык запросов, соответствующий этому стандарту, обычно обозначается как SQL-92.
Сейчас реляционные базы данных получили очень широкое распространение и, фактически, их можно рассматривать как стандарт СУБД для современных информационных систем.
Билет 61.
Объектно-ориентированные СУБД
Несмотря на большую популярность реляционных СУБД, развитие технологии управления данными на них не остановилось. Следующим этапом этого развития стало появление объектно-ориентированных баз данных, для которых характерны объектно-ориентированный подход, распределенность данных, наличие активного сервера баз данных, языки программирования четвертого поколения, фрагментация и параллельная обработки запросов, технологии тиражирования данных, многопоточная архитектура и другие революционные достижения в области обработки данных.
Объектно-ориентированный подход имеет ряд преимуществ для разработчика, из которых можно отметить следующие:
□ возможность разбить систему на совокупность независимых сущностей (объектов) и провести их строгую независимую спецификацию;
□ простоту эволюции системы за счет таких элементов объектного подхода, как наследование и полиморфизм;
□ возможность объектного моделирования системы, позволяющего проследить поведение реальных сущностей предметной области уже на ранних стадиях разработки.
Объектная модель данных более близка сущностям реального мира. Объекты можно сохранить и использовать непосредственно, не раскладывая по таблицам. Типы данных определяются разработчиком и не ограничены набором предопределенных типов.
При занесении сложного объекта в реляционную базу обязательна процедура декомпозиции его данных для того, чтобы разместить их в таблицах. При чтении объекта из реляционной базы он собирается из отдельных элементов и только затем может использоваться. В объектных же СУБД данные объекта, а также методы изменения этих данных помещаются в хранилище как единое целое.
Использование объектной модели представления данных (и, соответственно, объектно-ориентированной СУБД) наиболее привлекательно для информационных систем корпоративного уровня, разработка которых ведется методами объектного проектирования.
ПРИМЕЧАНИЕ
Несмотря на все достоинства объектно-ориентированных СУБД, их использование далеко не всегда оправданно. Нередко декомпозиция данных объекта не вызывает никаких проблем и вполне логична. В этом случае применение реляционной модели может быть более эффективным. Кроме того, ведущие производители реляционных СУБД IBM и Oracle доработали свои продукты (DB2 и Oracle соответственно), добавив объектную надстройку над реляционным ядром системы. Таким образом, работая с этими СУБД, можно использовать ту или иную модель данных в зависимости от конкретной ситуации. Вероятно, что в обозримом будущем рынок корпоративных систем пока останется за гибридными объектно-реляционными СУБД.
Билет 62.
Понятие типа данных в реляционной модели данных полностью эквивалентно соответствующему понятию в алгоритмических языках. Набор поддерживаемых. типов данных определяется СУБД и может значительно различаться в разных системах. Однако практически все СУБД поддерживают следующие типы данных:
□ целочисленные;
□ вещественные;
□ строковые;
□ специализированные типы данных для денежных величин;
□ специальные типы данных для временных величин (дата и/или время);
□ типы двоичных объектов — данный тип не имеет аналога в языках программирования; обычно для его обозначения используется аббревиатура BLOB (Binary Large Object — большой двоичный объект). Домен
Наименьшая единица данных реляционной модели — это отдельное атомарное (неразложимое) для данной модели значение данных. Доменом называется множество атомарных значений одного и того же типа. Иными словами, домен представляет собой допустимое потенциальное множество значений данного типа.
В нашем примере для каждого столбца таблицы можно определить домен.
□ Домены Имена и Специальности для столбцов Имя и Специальность соответственно будут базироваться на строковом типе данных — в число их значений могут входить только те строки, которые могут представлять имя и название специальности (в частности, такие строки не должны начинаться с мягкого знака).
□ Домен Даты_рождения для столбца Дата_рождения определяется на базовом временном типе данных — данный домен содержит только допустимый диапазон дат рождения студентов.
□ Домены Номера_курсов и Номера_студенческих_билетов базируются на целочисленном типе — в число их значений могут входить только те целые числа, которые позволяют обозначить номер курса университета (обычно от 1 до 6) и номер студенческого билета (обязательно положительное число).
Атрибуты, схема отношения, схема базы данных
Столбцы отношения называют атрибутами, им присваиваются имена, по которым к ним затем производится обращение.
Список имен атрибутов отношения с указанием имен доменов (или типов, если домены не поддерживаются) называется схемой отношения.
Схема нашего отношения СТУДЕНТ запишется так:
СТУДЕНТ {*_студенческого_билета Номера_студенческих_билетов Пия Имена.
Дата_рождения Даты_рождения. Курс Номера_курсов. Специальность Специальности}
Степень отношения — это число его атрибутов. Отношение степени один называют унарным, степени два — бинарным, степени три — тернарным,степени п — н-арным.
Степень отношения СТУДЕНТЫ равна пяти, то есть оно является 5-арным.
Схемой базы данных называется множество именованных схем отношений.
Кортеж
Кортеж, соответствующий данной схеме отношения, представляет собой множество пар {имя атрибута, значение}, которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения. Аргумент значение является допустимым значением домена данного атрибута (или типа данных, если понятие домена не поддерживается). Тем самым, степень кортежа, то есть число элементов в нем, совпадает со степенью соответствующей схемы отношения. Иными словами, кортеж — это набор именованных значений заданного типа.
Таким образом, отношение, по сути, является множеством кортежей, соответствующим одной схеме отношения. Кардинальным числом, или мощностью отношения называется число его кортежей. Мощность отношения СТУДЕНТЫ равна 6. В отличие от степени отношения, кардинальное число отношения изменяется во времени.
Пустые значения
В некоторых случаях какой-либо атрибут отношения может быть неприменим.' Например, в рассматриваемом в качестве примера отношении СТУДЕНТЫ может также храниться информация о потенциальных абитуриентах, посещающих подготовительные курсы вуза. В этом случае неприменимыми оказываются атрибуты №_студенческого_билета и Курс (так как абитуриенты еще не поступили в вуз и, следовательно, не имеют студенческого билета и не могут быть отнесены к какому-либо курсу). Кроме того, иногда при вводе информации в строку реляционной таблицы некоторые данные могут быть неизвестными и выясняться позже (при поступлении на подготовительные курсы абитуриент может еще не определиться окончательно, на какую специальность он будет поступать).
В обоих указанных случаях в поля, соответствующие неприменимым или неизвестным атрибутам, ничего не заносится, и строка записывается в базу данных с пустыми значениями этих атрибутов.
Следует понимать, что пустое значение — это не ноль и не пустая строка, а неизвестное значение атрибута, которое не определено в данный момент времени и, в принципе, может быть определено позднее. Ключи отношения
Поскольку отношение с математической точки зрения является множеством, а множества по определению не содержат совпадающих элементов, то никакие два кортежа отношения не могут быть дубликатами друг друга в любой произвольно заданный момент времени. Таким образом, в отношении всегда должен присутствовать некоторый атрибут (или набор атрибутов), однозначно определяющий каждый кортеж отношения и обеспечивающий уникальность строк таблицы. Такой атрибут (или набор атрибутов) называется первичным ключом отношения.
Более строго определить понятие первичного ключа можно следующим образом. Если R — отношение с атрибутами Д, А2,Д„ то множество атрибутов К = (Д, Ар Д.) отношения R является первичным ключом этого отношения тогда, и только тогда, когда удовлетворяются два независимых от времени условия:
□ уникальность — в произвольный момент времени никакие два кортежа отношения R не имеют одного и того же значения для Д, Д,Ak;
□ минимальность — ни один из атрибутов Д, Д,Д не может быть исключен из К без нарушения уникальности.
Для каждого отношения свойством уникальности обладает, по крайней мере, полный набор его атрибутов. Однако требуется обеспечить также условие минимальности. Поэтому, как правило, в отношении всегда имеется один атрибут, обладающий свойством уникальности и являющийся первичным ключом.
В зависимости от количества атрибутов, входящих в ключ, различают простые и сложные (или составные) ключи.
Простой ключ — ключ, содержащий только один атрибут. В общем случае операции объединения выполняются быстрее в том случае, когда в качестве ключа используется самый короткий и самый простой из возможных типов данных. С этой точки зрения наилучшим образом подходит целочисленный тип, который имеет аппаратную поддержку для выполнения над ним логических операций.
Сложный, или составной, ключ — это ключ, состоящий из нескольких атрибутов. Связанные отношения
В реляционной модели данные представляются в виде совокупности взаимосвязанных таблиц. Подобное взаимоотношение между таблицами называется связью (relation). Таким образом, еще одним важным понятием реляционной модели является связь между отношениями.
Для анализа связанных отношений воспользуемся рассмотренным ранее примером — отношением СТУДЕНТЫ (см. табл. 4.1). Данное отношение может быть связано с отношением УСПЕВАЕМОСТЬ, в котором содержатся сведения об успеваемости студентов по разным предметам. Внешние ключи отношения
В базах данных одни и те же имена атрибутов часто используются в разных отношениях. В рассматриваемом примере атрибут №_студенческого_билета присутствует как в отношении СТУДЕНТЫ, так и в отношении УСПЕВАЕМОСТЬ. В этом примере атрибут №_студенческого_билета иллюстрирует понятие внешнего ключа (foreign key).
Внешний ключ — это атрибут (или множество атрибутов) одного отношения, являющийся ключом другого (или того же самого) отношения.
Внешние ключи используются для установления логических связей между отношениями. Связь между двумя таблицами устанавливается путем присваивания значений внешнего ключа одной таблицы значениям ключа другой.
Так же как и любые другие ключи, внешние ключи могут быть простыми либо составными.
Часто связь между отношениями устанавливается по первичному ключу, то есть значениям внешнего ключа одного отношения присваиваются значения первичного ключа другого отношения. Однако это не является обязательным — в общем случае связь может устанавливаться и с помощью вторичных ключей. Кроме того, при установлении связей между таблицами необязательно требование уникальности ключа, по которому устанавливается связь.
Условия целостности данных
Чтобы информация, хранящаяся в базе данных, была однозначной и непротиворечивой, в реляционной модели устанавливаются некоторые ограничительные условия. Ограничительные условия — это правила, определяющие возможные значения данных. Они обеспечивают логическую основу для поддержания корректных значений данных в базе. Такие ограничения целостности позволяют свести к минимуму ошибки, возникающие при обновлении и обработке данных.
Важнейшими ограничениями целостности данных являются:
□ категорийная целостность;
□ ссылочная целостность.
Ограничение категорийной целостности заключается в следующем. Кортежи отношения представляют в базе данных элементы определенных объектов реального мира или, в соответствии с терминологией реляционных СУБД, категорий. Например, строка таблицы СТУДЕНТЫ представляет конкретного студента. Первичный ключ таблицы однозначно определяет каждый кортеж и, следовательно, каждый элемент категории. Таким образом, для извлечения данных, содержащихся в строке таблицы, или для манипулирования этими данными необходимо знать значение ключа для этой строки. Поэтому строка не может быть занесена в базу данных до тех пор, пока не будут определены все атрибуты ее первичного ключа. Это правило называется правилом категорийной целостности и кратко формулируется следующим образом: никакой атрибут первичного ключа строки не может быть пустым.
Дата добавления: 2015-08-29; просмотров: 28 | Нарушение авторских прав
| <== предыдущая лекция | | | следующая лекция ==> |