Управление транзакциями
Транзакция - это последовательность операций над БД, рассматриваемых СУБД как единое целое. Либо транзакция успешно выполняется, и СУБД фиксирует (COMMIT) изменения БД, произведенные этой транзакцией, во внешней памяти, либо ни одно из этих изменений никак не отражается на состоянии БД. Понятие транзакции необходимо для поддержания логической целостности БД. Таким образом, поддержание механизма транзакций является обязательным условием даже однопользовательских СУБД (если, конечно, такая система заслуживает названия СУБД). Но понятие транзакции гораздо более важно в многопользовательских СУБД.
То свойство, что каждая транзакция начинается при целостном состоянии БД и оставляет это состояние целостным после своего завершения, делает очень удобным использование понятия транзакции как единицы активности пользователя по отношению к БД. При соответствующем управлении параллельно выполняющимися транзакциями со стороны СУБД каждый из пользователей может в принципе ощущать себя единственным пользователем СУБД (на самом деле, это несколько идеализированное представление, поскольку в некоторых случаях пользователи многопользовательских СУБД могут ощутить присутствие своих коллег).
С управлением транзакциями в многопользовательской СУБД связаны важные понятия сериализации транзакций и сериального плана выполнения смеси транзакций. Под сериализаций параллельно выполняющихся транзакций понимается такой порядок планирования их работы, при котором суммарный эффект смеси транзакций эквивалентен эффекту их некоторого последовательного выполнения. Сериальный план выполнения смеси транзакций - это такой план, который приводит к сериализации транзакций. Понятно, что если удается добиться действительно сериального выполнения смеси транзакций, то для каждого пользователя, по инициативе которого образована транзакция, присутствие других транзакций будет незаметно (если не считать некоторого замедления работы по сравнению с однопользовательским режимом).
Существует несколько базовых алгоритмов сериализации транзакций. В централизованных СУБД наиболее распространены алгоритмы, основанные на синхронизационных захватах объектов БД. При использовании любого алгоритма сериализации возможны ситуации конфликтов между двумя или более транзакциями по доступу к объектам БД. В этом случае для поддержания сериализации необходимо выполнить откат (ликвидировать все изменения, произведенные в БД) одной или более транзакций. Это один из случаев, когда пользователь многопользовательской СУБД может реально (и достаточно неприятно) ощутить присутствие в системе транзакций других пользователей.
Журнализация
Одним из основных требований к СУБД является надежность хранения данных во внешней памяти. Под надежностью хранения понимается то, что СУБД должна быть в состоянии восстановить последнее согласованное состояние БД после любого аппаратного или программного сбоя. Обычно рассматриваются два возможных вида аппаратных сбоев: так называемые мягкие сбои, которые можно трактовать как внезапную остановку работы компьютера (например, аварийное выключение питания), и жесткие сбои, характеризуемые потерей информации на носителях внешней памяти. Примерами программных сбоев могут быть: аварийное завершение работы СУБД (по причине ошибки в программе или в результате некоторого аппаратного сбоя) или аварийное завершение пользовательской программы, в результате чего некоторая транзакция остается незавершенной. Первую ситуацию можно рассматривать как особый вид мягкого аппаратного сбоя; при возникновении последней требуется ликвидировать последствия только одной транзакции.
Понятно, что в любом случае для восстановления БД нужно располагать некоторой дополнительной информацией. Другими словами, поддержание надежности хранения данных в БД требует избыточности хранения данных, причем та часть данных, которая используется для восстановления, должна храниться особо надежно. Наиболее распространенным методом поддержания такой избыточной информации является ведение журнала изменений БД.
Журнал - это особая часть БД, недоступная пользователям СУБД и поддерживаемая с особой тщательностью (иногда поддерживаются две копии журнала, располагаемые на разных физических дисках), в которую поступают записи обо всех изменениях основной части БД. В разных СУБД изменения БД журнализуются на разных уровнях: иногда запись в журнале соответствует некоторой логической операции изменения БД (например, операции удаления строки из таблицы реляционной БД), иногда - минимальной внутренней операции модификации страницы внешней памяти; в некоторых системах одновременно используются оба подхода.
Во всех случаях придерживаются стратегии "упреждающей" записи в журнал (так называемого протокола Write Ahead Log - WAL). Грубо говоря, эта стратегия заключается в том, что запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД. Известно, что если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя.
Самая простая ситуация восстановления - индивидуальный откат транзакции. Строго говоря, для этого не требуется общесистемный журнал изменений БД. Достаточно для каждой транзакции поддерживать локальный журнал операций модификации БД, выполненных в этой транзакции, и производить откат транзакции путем выполнения обратных операций, следуя от конца локального журнала. В некоторых СУБД так и делают, но в большинстве систем локальные журналы не поддерживают, а индивидуальный откат транзакции выполняют по общесистемному журналу, для чего все записи от одной транзакции связывают обратным списком (от конца к началу).
При мягком сбое во внешней памяти основной части БД могут находиться объекты, модифицированные транзакциями, не закончившимися к моменту сбоя, и могут отсутствовать объекты, модифицированные транзакциями, которые к моменту сбоя успешно завершились (по причине использования буферов оперативной памяти, содержимое которых при мягком сбое пропадает). При соблюдении протокола WAL во внешней памяти журнала должны гарантированно находиться записи, относящиеся к операциям модификации обоих видов объектов. Целью процесса восстановления после мягкого сбоя является состояние внешней памяти основной части БД, которое возникло бы при фиксации во внешней памяти изменений всех завершившихся транзакций и которое не содержало бы никаких следов незаконченных транзакций. Для того чтобы этого добиться, сначала производят откат незавершенных транзакций (undo), а потом повторно воспроизводят (redo) те операции завершенных транзакций, результаты которых не отображены во внешней памяти. Этот процесс содержит много тонкостей, связанных с общей организацией управления буферами и журналом. Более подробно мы рассмотрим это в соответствующей лекции.
Для восстановления БД после жесткого сбоя используют журнал и архивную копию БД. Грубо говоря, архивная копия - это полная копия БД к моменту начала заполнения журнала (имеется много вариантов более гибкой трактовки смысла архивной копии). Конечно, для нормального восстановления БД после жесткого сбоя необходимо, чтобы журнал не пропал. Как уже отмечалось, к сохранности журнала во внешней памяти в СУБД предъявляются особо повышенные требования. Тогда восстановление БД состоит в том, что исходя из архивной копии по журналу воспроизводится работа всех транзакций, которые закончились к моменту сбоя. В принципе, можно даже воспроизвести работу незавершенных транзакций и продолжить их работу после завершения восстановления. Однако в реальных системах это обычно не делается, поскольку процесс восстановления после жесткого сбоя является достаточно длительным.
Поддержка языков БД
Для работы с базами данных используются специальные языки, в целом называемые языками баз данных. В ранних СУБД поддерживалось несколько специализированных по своим функциям языков. Чаще всего выделялись два языка - язык определения схемы БД (SDL - Schema Definition Language) и язык манипулирования данными (DML - Data Manipulation Language).SDL служил главным образом для определения логической структуры БД, т.е. той структуры БД, какой она представляется пользователям. DML содержал набор операторов манипулирования данными, т.е. операторов, позволяющих заносить данные в БД, удалять, модифицировать или выбирать существующие данные.
В современных СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с БД, начиная от ее создания, и обеспечивающий базовый пользовательский интерфейс с базами данных. Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL (Structured Query Language). Перечислим основные функции реляционной СУБД, поддерживаемые на "языковом" уровне (т.е. функции, поддерживаемые при реализации интерфейса SQL).
Прежде всего, язык SQL сочетает средства SDL и DML, т.е. позволяет определять схему реляционной БД и манипулировать данными. При этом именование объектов БД (для реляционной БД - именование таблиц и их столбцов) поддерживается на языковом уровне в том смысле, что компилятор языка SQL производит преобразование имен объектов в их внутренние идентификаторы на основании специально поддерживаемых служебных таблиц-каталогов. Внутренняя часть СУБД (ядро) вообще не работает с именами таблиц и их столбцов.
Язык SQL содержит специальные средства определения ограничений целостности БД. Опять же, ограничения целостности хранятся в специальных таблицах-каталогах, и обеспечение контроля целостности БД производится на языковом уровне, т.е. при компиляции операторов модификации БД компилятор SQL на основании имеющихся в БД ограничений целостности генерирует соответствующий программный код.
Специальные операторы языка SQL позволяют определять так называемые представления БД, фактически являющиеся хранимыми в БД запросами (результатом любого запроса к реляционной БД является таблица) с именованными столбцами. Для пользователя представление является такой же таблицей, как любая базовая таблица, хранимая в БД, но с помощью представлений можно ограничить или наоборот расширить видимость БД для конкретного пользователя. Поддержание представлений производится также на языковом уровне.
Наконец, авторизация доступа к объектам БД производится также на основе специального набора операторов SQL. Идея состоит в том, что для выполнения операторов SQL разного вида пользователь должен обладать различными полномочиями. Пользователь, создавший таблицу БД, обладает полным набором полномочий для работы с этой таблицей. В число этих полномочий входит полномочие на передачу всех или части полномочий другим пользователям, включая полномочие на передачу полномочий. Полномочия пользователей описываются в специальных таблицах-каталогах, контроль полномочий поддерживается на языковом уровне.
Типовая организация современной СУБД
Естественно, организация типичной СУБД и состав ее компонентов соответствует рассмотренному нами набору функций. Напомним, что мы выделили следующие основные функции СУБД:
управление данными во внешней памяти;
управление буферами оперативной памяти;
управление транзакциями;
журнализация и восстановление БД после сбоев;
поддержание языков БД.
Логически в современной реляционной СУБД можно выделить наиболее внутреннюю часть - ядро СУБД (часто его называют Data Base Engine), компилятор языка БД (обычно SQL), подсистему поддержки времени выполнения, набор утилит. В некоторых системах эти части выделяются явно, в других - нет, но логически такое разделение можно провести во всех СУБД.
Ядро СУБД отвечает за управление данными во внешней памяти, управление буферами оперативной памяти, управление транзакциями и журнализацию. Соответственно, можно выделить такие компоненты ядра (по крайней мере, логически, хотя в некоторых системах эти компоненты выделяются явно), как менеджер данных, менеджер буферов, менеджер транзакций и менеджер журнала. Как можно было понять из первой части этой лекции, функции этих компонентов взаимосвязаны, и для обеспечения корректной работы СУБД все эти компоненты должны взаимодействовать по тщательно продуманным и проверенным протоколам. Ядро СУБД обладает собственным интерфейсом, не доступным пользователям напрямую и используемым в программах, производимых компилятором SQL (или в подсистеме поддержки выполнения таких программ) и утилитах БД. Ядро СУБД является основной резидентной частью СУБД. При использовании архитектуры "клиент-сервер" ядро является основной составляющей серверной части системы.
Основной функцией компилятора языка БД является компиляция операторов языка БД в некоторую выполняемую программу. Основной проблемой реляционных СУБД является то, что языки этих систем (а это, как правило, SQL) являются непроцедурными, т.е. в операторе такого языка специфицируется некоторое действие над БД, но эта спецификация не является процедурой, а лишь описывает в некоторой форме условия совершения желаемого действия (вспомните примеры из первой лекции). Поэтому компилятор должен решить, каким образом выполнять оператор языка прежде, чем произвести программу. Применяются достаточно сложные методы оптимизации операторов, которые мы подробно рассмотрим в следующих лекциях. Результатом компиляции является выполняемая программа, представляемая в некоторых системах в машинных кодах, но более часто в выполняемом внутреннем машинно-независимом коде. В последнем случае реальное выполнение оператора производится с привлечением подсистемы поддержки времени выполнения, представляющей собой, по сути дела, интерпретатор этого внутреннего языка.
Наконец, в отдельные утилиты БД обычно выделяют такие процедуры, которые слишком накладно выполнять с использованием языка БД, например, загрузка и выгрузка БД, сбор статистики, глобальная проверка целостности БД и т.д. Утилиты программируются с использованием интерфейса ядра СУБД, а иногда даже с проникновением внутрь ядра.
Лекция 4. Экспертные системы
Систему искусственного интеллекта, построенную на основе высококачествен ных специальных знании о некоторой предметной области (полученных от экспер тов - специалистов этой области), называют экспертной системой. Экспертные системы - один из немногих видов систем искусственного интеллекта получили широкое распространение и практическое применение. Существу ют экспертные системы по военному делу, геологии, инженерному делу, информа тике, космической технике, математике, медицине, метеорологии, промышленности, сельскому хозяйству, управлению, физике, химии, электронике, юриспруденции и т.д. И только то, что экспертные системы остаются весьма сложными, дорогими, а главное, узкоспециализированными программами, сдерживает их еще более широ кое распространение.
От других программ экспертные системы отличаются по следующим признакам:
компетентность - в конкретной предметной области экспертная система должна достигать того же уровня, что и эксперты - люди, при этом она должна пользоваться теми же эвристическими приемами, также глубоко и широко отражать предметную область;
символьные рассуждения - знания, на которых основана экспертная система, представляют в символьном виде понятия реального мира, рассуждения также происходят в виде преобразований символьных наборов;
глубина - экспертиза должна решать глубокие, нетривиальные задачи, отли чающиеся сложностью либо в плане сложности знаний, которые экспертная система использует, либо в плане их обилия, это не позволяет использовать полный перебор вариантов как метод решения задачи и заставляет прибегать к эвристическим, творческим, неформальным методам;
самосознание - экспертная система должна включать в себя механизм объяснения того, каким образом она приходит к решению задачи.
Экспертные системы, выполняющие интерпретацию, как правило, используют информацию от датчиков для описания ситуации. Например, это может быть интерпретация показаний измерительных приборов на химическом заводе для определения состояния процесса. Интерпретирующие системы имеют дело не с четкими символьными представлениями проблемной ситуации, а непосредственно с реальными данными. Они сталкиваются с затруднениями, которых нет у систем других типов, потому что им приходится обрабатывать информацию зашумленную, недостаточную, неполную, ненадежную или ошибочную. Им необходимы специ альные методы регистрации характеристик непрерывных потоков данных, сигналов пли изображений и методы их символьного представления.
Интерпретирующие экспертные системы могут обрабатывать разнообразные виды данных. Например, системы анализа сцен и распознавания речи, используя естественную информацию (в одном случае визуальные образы), анализируют их характеристики и понимают их смысл. Интерпретация в области химии использует данные дифракции спектрального анализа или ядерного магнитного резонанса для определения структуры веществ. Интерпретирующая система в геологии используетa зондирование - измерение проводимости горных пород, чтобы определить подповерхностные геологические структуры интерпретирующие системы используют показания (например, значения температуры, пульса, кровяного давления), диагноз или тяжесть заболевания. Наконец, в военном деле системы используют данные от радаров, радиосвязи и сонарных устройств оценить ситуацию и идентифицировать цели.
Экспертные системы, осуществляющие прогноз, определяют вероятностные условия заданных ситуаций. Примерами служат прогноз ущерба урожаю от вида вредных насекомых, оценивание спроса на нефть на мировом рынке прогнозирование места возникновения следующего вооруженного конфликта по данным разведки. Системы прогнозирования иногда используют моделирование, т.е. программы, которые отражают взаимосвязи в реальном мире, чтобы сгенерировать ситуации, которые могут возникнуть при тех или иных входных данных.
Экспертные системы выполняют Диагностирование, используя описания ситуа ции, поведения или знания о конструкции компонентов, чтобы установить вероятные причины неправильно функционирования диагностируемой системы. Примерами служат определение причин заболевания по симптомам, наблюдаемым у пациентов; локализация неисправностей в электронных схемах и определение неисправных компонентов в системе охлаждения ядерных реакторов. Диагностические системы часто являются консультантами, которые не только ставят диагноз, но и помогают в отладке. Они могут взаимодействовать с пользова телем, чтобы оказать помощь при поиске неисправностей, а затем предложить порядок действий по их устранению. Медицина представляется вполне естественной областью для диагностирования, и действительно, в медицинской области было разработано больше диагностических систем, чем в любой другой отдельно взятой предметной области. Однако в настоящее время многие диагностические системы разрабатываются для приложений к инженерному делу и компьютерным системам.
Экспертные системы, выполняющие проектирование, разрабатывают конфигура ции объектов с учетом набора ограничений, присущих проблеме. Примерами могут служить генная инженерия, разработка СБИС и синтез сложных органических молекул.
Экспертные системы, занятые планированием, проектируют действия; они опре деляют полную последовательность действий, прежде чем начнется их выполнение. Примерами могут служить создание плана применения последовательности химиче ских реакций к группам атомов с целью синтеза сложных органических соединений или создание плана воздушного нападения, рассчитанного на несколько дней, с целью нейтрализации определенного фактора боеспособности врага.
Экспертные системы, выполняющие наблюдение, сравнивают действительное поведение с ожидаемым поведением системы. Примерами могут служить слежение за показаниями измерительных приборов в ядерных реакторах с целью обнаруже ния аварийных ситуаций или оценка данных мониторинга больных, помещенных в блоки интенсивной терапии. Наблюдающие экспертные системы подыскивают наблюдаемое поведение, которое подтверждает их ожидания относительно нор мального поведения или их предположения о возможных отклонениях. Наблюдаю щие экспертные системы по самой своей природе должны работать в режиме реального времени и осуществлять зависящую как от времени, так и от контекста интерпретацию поведения наблюдаемого объекта.
Экспертные системы, выполняющие обучение, подвергают диагностике, «отладке» и исправлению (коррекции) поведение обучаемого. В качестве примеров приведем обучение студентов отысканию неисправностей в электрических цепях, обучение военных моряков обращению с двигателем на корабле и обучение студентов-медиков выбору антимикробной терапии. Обучающие системы создают модель того, что обучающийся знает и как он эти знания применяет к решению проблемы. Системы диагностируют и указывают обучающемуся его ошибки, анализируя модель и строя планы исправлений указанных ошибок. Они исправляют поведение обучающихся, выполняя эти планы с помощью непосредственных указаний обучающимся.
Экспертные системы, осуществляющие управление, адаптивно руководят поведени ем системы в целом. Примером служит управление производством и распределением компьютерных систем. Управляющие экспертные системы должны включать наблю дающие компоненты, чтобы отслеживать поведение объекта на протяжении времени, но они могут нуждаться и в других компонентах для выполнения любых пли всех из уже рассмотренных типов задач: интерпретации, прогнозирования, диагностики, проектирования, планирования, отладки, ремонта и обучения. Типичная комбина ция задач состоит из наблюдения, диагностики, отладки, планирования и прогноза.
Лекция №5. Теория реляционных баз данных
Модель данных — совокупность структур данных и операций по их обработке. С помощью модели данных можно наглядно представить структуру объектов и установленные меж ду ними связи. Для терминологии моделей данных характерны понятия «эле мент данных» и «правила связывания». Элемент данных описывает любой на бор данных, а правила связывания определяют алгоритмы взаимосвязи элементов данных. К настоящему времени разработано множество различных моделей дан ных, но на практике используется три основных. Выделяют иерархическую, сетевую и реляционную модели данных. Соответственно говорят об иерархичес ких, сетевых и реляционных СУБД.
О Иерархическая модель данных. Иерархически организованные данные встре чаются в повседневной жизни очень часто. Например, структура высшего учеб ного заведения — это многоуровневая иерархическая структура. Иерархичес кая (древовидная) БД состоит из упорядоченного набора элементов. В этой модели исходные элементы порождают другие элементы, причем эти элементы в свою очередь порождают следующие элементы. Каждый порожденный эле мент имеет только один порождающий элемент.
Организационные структуры, списки материалов, оглавление в книгах, пла ны проектов и многие другие совокупности данных могут быть представле ны в иерархическом виде. Автоматически поддерживается целостность ссы лок между предками и потомками. Основное правило: никакой потомок не может существовать без своего родителя.
Основным недостатком данной модели является необходимость использова ния той иерархии, которая была заложена в основу БД при проектировании. Потребность в постоянной реорганизации данных (а часто невозможность этой реорганизации) привели к созданию более общей модели — сетевой.
О Сетевая модель данных. Сетевой подход к организации данных является рас ширением иерархического подхода. Данная модель отличается от иерахической тем, что каждый порожденный элемент может иметь более одного по рождающего элемента. ■
Поскольку сетевая БД может представлять непосредственно все виды связей, присущих данным соответствующей организации, по этим данным можно переме щаться, исследовать и запрашивать их всевозможными способами, то есть сете вая модель не связана всего лишь одной иерархией. Однако для того чтобы со ставить запрос к сетевой БД, необходимо достаточно глубоко вникнуть в ее структуру (иметь под рукой схему этой БД) и выработать механизм навигации по базе данных, что является существенным недостатком этой модели БД.
О Реляционная модель данных. Основная идея реляционной модели данных за ключается в том, чтобы представить любой набор данных в виде двумерной таблицы. В простейшем случае реляционная модель описывает единственную двумерную таблицу, но чаще всего эта модель описывает структуру и взаи моотношения между несколькими различными таблицами.
Реляционная модель данных
Итак, целью информационной системы является обработка данных об объектах реального мира, с учетом связей между объектами. В теории БД данные часто называют атрибутами, а объекты — сущностями. Объект, атрибут и связь — фундаментальные понятия И.С.
Объект (или сущность) — это нечто существующее и различимое, то есть объектом можно назвать то «нечто», для которого существуют название и спо соб отличать один подобный объект от другого. Например, каждая школа — это объект. Объектами являются также человек, класс в школе, фирма, сплав, хи мическое соединение и т. д. Объектами могут быть не только материальные пред меты, но и более абстрактные понятия, отражающие реальный мир. Например, события, регионы, произведения искусства; книги (не как полиграфическая про дукция, а как произведения), театральные постановки, кинофильмы; правовые нормы, философские теории и проч.
Атрибут (или данное) — это некоторый показатель, который характеризует некий объект и принимает для конкретного экземпляра объекта некоторое чис ловое, текстовое или иное значение. Информационная система оперирует на борами объектов, спроектированными применительно к данной предметной области, используя при этом конкретные значения атрибутов (данных) тех или иных объектах. Например, возьмем в качестве набора объектов классы вшколе. Число учеников в классе — это данное, которое принимает числовое значение (у одного класса 28, у другого— 32). Название класса — это данное, принимающее текстовое значение (у одного — 10А, у другого — 9Б и т. д.).
Развитие реляционных баз данных началось в конце 60-х годов, когда по явились первые работы, в которых обсуждались; возможности использования при проектировании баз данных привычных и естественных способов представле ния данных — так называемых табличных даталогических моделей.
Основоположником теории реляционных баз данных считается сотрудник фирмы IBM доктор Э. Кодд, опубликовавший 6 (июня 1970 г. статью A Relational Model of Data for Large-Shared Data Banks (Реляционная модель данных для больших коллективных банков данных). В этой статье впервые был использован термин «реляционная модель данных. Теория реляционных баз данных, разработанная в 70-х годах в США докто ром Э. Коддом, имеет под собой мощную математическую основу, описывающую правила эффективной организации данных. Разработанная Э. Коддом теорети ческая база стала основой для разработки теории проектирования баз данных.
Э. Кодд, будучи математиком по образованию, предложил использовать для обработки данных аппарат теории множеств (объединение, пересечение, раз ность, декартово произведение). Он доказал, что любой набор данных можнопредставить в виде двумерных таблиц особого вида, известных в математике как «отношения».
Реляционной считается такая база данных, в которой все данные представле ны для пользователя в виде прямоугольных таблиц значений данных, и все операции над базой данных сводятся к манипуляциям с таблицами.
Таблица состоит из столбцов (полей) и строк (записей); имеет имя, уникаль ное внутри базы данных. Таблица отражает тип объекта реального мира (сущ ность), а каждая ее строка— конкретный объект. Каждый столбец таблицы — это совокупность значений конк ретного атрибута объекта. Значения выбираются из множества всех возможных значений атрибута объек та, которое называется доменом (domain).
В самом общем виде домен определяется заданием некоторого базового типа данных, к которому относятся элементы домена, и произвольного логического выражения, применяемого к элементам данных. Если при вычислении логическо го условия относительно элемента данных в результате получено значение «исти на», то этот элемент принадлежит домену. В простейшем случае домен определяется как допустимое потенциальное множество значений одного типа. Например, со вокупность дат рождения всех сотрудников составляет «домен дат рождения», а имена всех сотрудников составляют «домен имен сотрудников». Домен дат рож дения имеет тип данных, позволяющий хранить информацию о моментах време ни, а домен имен сотрудников должен иметь символьный тип данных.
Если два значения берутся из одного и того же домена, то можно выполнять сравнение этих двух значений. Например, если два значения взяты из домена дат рождения, то можно сравнить их и определить, кто из сотрудников старше. Если же значения берутся из разных доменов, то их сравнение не допускается, так как, по всей вероятности, оно не имеет смысла. Например, из сравнения имени и даты рождения сотрудника ничего определенного не выйдет.
Каждый столбец (поле) имеет имя, которое обычно записывается в верхней части таблицы. При проектировании таблиц в рамках конкретной СУБД имеет ся возможность выбрать для каждого поля его тип, то есть определить набор правил по его отображению, а также определить те операции, которые можно выполнять над данными, хранящимися в этом поле. Наборы типов могут разли чаться у разных СУБД.
Имя поля должно быть уникальным в таблице, однако различные таблицы могут иметь поля с одинаковыми именами. Любая таблица должна иметь, по крайней мере, одно поле; поля расположены в таблице в соответствии с порядком следования их имен при ее создании. В отличие от полей, строки не имеют имен; порядок их следования в таблице не определен, а количество логически не ограничено.
Так как строки в таблице не упорядочены, невозможно выбрать строку по ее позиции — среди них не существует «первой», «второй», «последней». Любая таблица имеет один или несколько столбцов, значения в которых однозначно идентифицируют каждую ее строку. Такой столбец (или комбинация столбцов) называется первичным ключом (primary key). Часто вводят искусственное поле, предназначенное для нумерации за писей в таблице. Таким полем, например, может быть его порядковый, который сможет обеспечить уникальность каж дой записи в таблице. Ключ должен обладать следующими свойствами.
Уникальностью. В каждый момент времени никакие два различных кортежа отношения не имеют одинакового значения для комбинации входящих в ключ атрибутов. То есть в таблице не может быть двух строк, имеющих одинако вый идентификационный номер или номер паспорта.
Минимальностью. Ни один из входящих в ключ атрибутов не может быть ис ключен из ключа без нарушения уникальности. Это означает, что не стоит со здавать ключ, включающий и номер паспорта, и идентификационный номер.Достаточно использовать любой из этих атрибутов, чтобы однозначно иденти фицировать кортеж. Не стоит также включать в ключ неуникальный атрибут, то есть запрещается использование в качестве ключа комбинации идентифи кационного номера и имени служащего. При исключении имени служащего из ключа все равно можно уникально идентифицировать каждую строку.
Каждое отношение имеет, по крайней мере, один возможный ключ, посколь ку совокупность всех его атрибутов удовлетворяет условию уникальности — это следует из самого определения отношения.
Один из возможных ключей произвольно выбирается в качестве первичного ключа. Остальные возможные ключи, если они есть, принимаются за альтерна тивные ключи. Например, если в качестве первичного ключа выбрать иденти фикационный номер, то номер паспорта будет альтернативным ключом.
Взаимосвязь таблиц является важнейшим элементом реляционной модели данных. Она поддерживается внешними ключами (foreign key).
При описании модели реляционной базы данных для одного и того же поня тия часто употребляют различные термины, что зависит от уровня описания (теория или практика) и системы (Access, SQL Server, dBase). В табл. 2.3 приве дена сводная информация об используемых терминах.
|
