Введение в системы БД (542480), страница 26
Текст из файла (страница 26)
~Мы! будем использовать термин отношение только в тех случаях, когда вместо него можно использовать термин "таблица" или "представление". Если неайходилю будет подчеркнуть, что данное отношение является хранимым отношением, а не представлением, то и зтам случае мы будем использовать термин базовое отношение изи базовая таблица " Подобные цитаты, к сожалению, — не редкость 109 Глава 3.
Введение в реляционные базы данных /" Нормальное завершение */ /* Аварийное завершение */ Отметим некоторые свойства транзакций. 1. Транзакции заведомо атомарны, т.е. они гарантируют (с логической точки зрения), что будут выполнены полностью или не выполнены вовсе, даже если в системе до окончания процесса выполнения транзакции произойдет сбой. 2. Транзакции гарантируют продолжительность результатов их выполнения в том смысле, что если транзакция успешно выполнила оператор СОММ1Т, то все выполненные ею изменения гарантированно будут реализованы в базе данных, даже если позднее в системе в какой-то момент произойдет сбой.
Замечание. По сути, благодаря именно этому свойству продолжительности транзакций данные в базе данных являются постоянными в том смысле, который объяснялся в главе 1. 3. Для транзакций также гарантируется изолированность одной транзакции от другой. Под этим подразумевается, что изменения в базе данных, выполненные некоторой транзакцией Т!, не будут видимы для любой транзакции Т2 до тех пор, пока и только пока транзакцией Т! не будет успешно выполнена операция СОММ?Т. После выполнения операции СОММ1Т изменения, которые были произведены некоторой транзакцией, становятся видимыми для других транзакций.
О таких изменениях говорят, что они зафиксированы, и гарантируется, что они никогда не будут отменены. Если же, напротив, транзакцией была выполнена операция НОЬЬВАСК, все изменения, которые были внесены в базу данных в процессе выполнения этой транзакции„ будут отменены (выполнен откат изменений).
В последнем случае конечный результат будет таким, как если бы данная транзакция вообще не выполнялась. 4. При параллельном выполнении нескольких транзакций, операции которых чередуются между собой, обычно гарантируется, что осуществление этих операций будет упорядоченным (зег(а!(гаЫе). Иначе говоря, результат выполнения каждой из транзакций будет точно таким же, как при строго последовательном выполнении этих же транзакций в некотором произвольном порядке. Развернутое обсуждение всех остальных аспектов данной темы будет продолжено в главах 14 и 15. 3.9.
База данных поставщиков и деталей На протяжении почти всей этой книги используется пример, названный нами базой данных поставщиков и деталей (поддерживаемой, как уже упоминалось в главе 1, вымышленной компанией КпомФаге, 1лс.). Назначение настоящего раздела — позна- 11О Часть / Основные понятия ВЕО?М ТНАМЯАСТ?ОМ 1 ОРРАТЕ ассоцпб А ; ОРЭАТЕ ассоцпС В 1 ?Р <Все ввлолнело услешноэ ТНЕМ СОММ1Т ЕВВЕ НОВ?ВАСК ЕМО 1Г ; /* Перевести ВВВ со счета А на счет В ь/ /* Снятие денег со счета А */ /ь Помещение денег на счет В */ комить читателя с этой базой данных, которая будет служить примером для ссылок в последуюших главах.
На рис. 3.8 показано множество значений ее данных. Именно эти конкретные значения будут фактически использоваться в дальнейшем (где это имеет смысл). На рис. 3.9 показано определение базы данных, для которого снова используется (несколько измененный) язык ТцзоНа! В. В частности, обратите внимание на спецификации первичных и внешних ключей. Кроме того, обратите внимание на то, что несколько столбцов имеют типы данных, которым присвоено название, аналогичное названию соответствующего столбца.
Столбцы ЯТАТОЯ и С1ТТ определены как имеющие не пользовательский, а встроенный тип данных — 1НТЕОЕН (целое) и СНАН (строка символов произвольной длины) соответственно. Наконец, необходимо отметить, что в отношении значений, показанных в столбцах на рис. 3.8, должно быть сделано одно важное замечание, однако мы еше не готовы к этому. Поэтому обсуждение упомянутого замечания будет отложено до главы 5, точнее — до подраздела "Внутренний уровень" в разделе 5.2.
Рис. 3.8. База данных поставщиков и детазей (пример значений) В базе данных предполагается следуюшая семантика. ° Переменная-отношение Я представляет поставщиков. Каждый поставшик имеет уникальный номер (8$); имя (ЯНЬНЕ), необязательно уникальное (хотя оно может быть уникальным, как в случае, представленном на рис. 3.8); значение рейтинга или статуса (ЯТйТОЯ); место расположения (С1ТТ). Предполагается, что каждый поставщик находится только в одном городе.
° Переменная-отношение Р представляет девали (точнее, виды деталей). У каждого вида детали есть номер детали (РР), который является уникальным; название детали (РНЬНЕ); цвет (СОЬОН); вес (НЕ16НТ); город, где хранится этот вид деталей (С1ТТ). Предполагается (где это имеет значение), что вес детали приведен в фунтах. Также предполагается, что каждый отдельный вид детали имеет только один цвет и хранится на складе только в одном городе.
111 Глава 3. Введение вреляционные базы данных ° Переменная-отношение БР представляет поставки. Она в известном смысле служит для организации логической связи двух других переменных-отношений. Например, первая строка переменной-отношения БР на рис. 3.8 связывает поставщика с номером ' 81' из переменной-отношения Я с соответствующей деталью, имеющей номер 'Р1' в переменной-отношении Р, т.е, представляет факт поставки деталей типа 'Р1' поставщиком с номером 'Я1' (а также указывает количество деталей— 300 штук). Таким образом, каждая поставка характеризуется номером поставщика (8$), номером детали (Р$) и количеством (ОТУ). Предполагается, что в одно и то же время может быть не более одной поставки для одного поставщика и одной детали, поэтому для каждой поставки комбинация значений столбцов 8$ и Р$ уникальна с точки зрения набора текущих поставок, представленных в переменной- отношении ЯР.
Замечание. На рис. 3.8 умышленно показано одно значение поставщика (с номером 'Я5'), для которого не существует ни одной поставки. ТУРЕ Я$ ТУРЕ ИАИЕ ТУРЕ Р$ ... ! ТУРЕ СОЫВ ... ТУРЕ ИЕ16НТ ТУРЕ ЕТУ ... ; ЧАВ Я ВАЯЕ ВЕЕАТ10Ы ( 8$ Я$, ЯИАИЕ ИАИЕ, ЯТАТОЯ 1ИТЕ6ЕВ, С1ТУ СНАВ ) РВУИАВУ КЕУ ( 8$ ЧАВ Р ВАЯВ ВЕЬАТ10И ( Р$ Р$, РИАИЕ ИАИЕ, СОЫВ СОЬОВ, ИЕ16ВТ ИЕ16ЕТ, С1ТУ СНАВ ) РВУИАВУ КЕУ ( Р$ ) > ЧАВ БР ВАБЕ ВЕЬАТ10Ы ( Я$ Б$, Р$ Р$, ОТУ ОТУ РВХИАВУ КЕУ ( 8$, Р$ ) ГОВЕ16И КЕУ ( 8$ ) ВЕГЕВЕИСЕЯ Я ГОВЕ16И КЕХ ( Р$ ) ВЕГЕВЕИСЕЯ Р ] Рис.
Зхй База данных поставщиков и деталей (определение данных) 11г Часть 1 Основные понятия Как отмечалось выше (в главе 1, раздел 1.3), детали и поставщиков можно рассматривать как сущности, а поставку — как связь между определенным поставщиком и определенной деталью. Однако в том же разделе было указано, что связи можно понимать как особый вид сущностей.
Одно из преимушеств реляционных баз данных состоит именно в том, что все сущности, независимо от того, что на самом деле они могут являться связями, представляются одним универсальным способом, а именно — с помощью строк, объединенных в отношения, как показано в нашем примере. И еще пара последних замечаний. ° Во-первых, наша база данных поставщиков и деталей исключительно проста, гораздо проще любой реальной базы данных, которая может встретиться на практике. Большинство реальных баз данных включает значительно больше сущностей и связей (и намного больше видов сущностей и связей).
Но несмотря на это предложенный здесь простой пример вполне подходит для иллюстрации большинства вопросов, обсуждаемых в оставшейся части книги, и (как уже отмечалось) будет использоваться как основа для большинства (но не для всех) примеров в нескольких последующих главах. ° Во-вторых, безусловно, не было бы ошибкой, если бы мы использовали более описательные названия переменных-отношений, подобные ЯОРРЫЕКЯ (поставщики), РАКИЯ (детали) и ЯН1РИЕКТЯ (поставки), вместо сокращенных названий Б, Р н ЯР.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
