Типовая организация современной СУБД. Естественно, организация типичной СУБД и состав ее компонентов соответствует рассмотренному нами набору функций.

Напомним, что мы выделили следующие основные функции СУБД управление данными во внешней памяти управление буферами оперативной памяти управление транзакциями журнализация и восстановление БД после сбоев поддержание языков БД. Логически в современной реляционной СУБД можно выделить наиболее внутреннюю часть - ядро СУБД часто его называют Data Base Engine, компилятор языка БД обычно SQL , подсистему поддержки времени выполнения, набор утилит.

В некоторых системах эти части выделяются явно, в других - нет, но логически такое разделение можно провести во всех СУБД. Ядро СУБД отвечает за управление данными во внешней памяти, управление буферами оперативной памяти, управление транзакциями и журнализацию. Соответственно, можно выделить такие компоненты ядра по крайней мере, логически, хотя в некоторых системах эти компоненты выделяются явно, как менеджер данных, менеджер буферов, менеджер транзакций и менеджер журнала.

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

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

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

Наконец, в отдельные утилиты БД обычно выделяют такие процедуры, которые слишком накладно выполнять с использованием языка БД, например, загрузка и выгрузка БД, сбор статистики, глобальная проверка целостности БД и т.д. Утилиты программируются с использованием интерфейса ядра СУБД, а иногда даже с проникновением внутрь ядра. Ранние подходы к организации БД. Системы, основанные на инвертированных списках, иерархические и сетевые СУБД. Примеры.

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

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

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

Как мы упоминали, понятие модели данных фактически вошло в обиход специалистов в области БД только вместе с реляционным подходом. Абстрактные представления ранних систем появились позже на основе анализа и выявления общих признаков у различных конкретных систем. c. В ранних системах доступ к БД производился на уровне записей.

Пользователи этих систем осуществляли явную навигацию в БД, используя языки программирования, расширенные функциями СУБД. Интерактивный доступ к БД поддерживался только путем создания соответствующих прикладных программ с собственным интерфейсом. d. Можно считать, что уровень средств ранних СУБД соотносится с уровнем файловых систем примерно так же, как уровень языка Кобол соотносится с уровнем языка Ассемблера.

Заметим, что при таком взгляде уровень реляционных систем соответствует уровню языков Ада или APL. e. Навигационная природа ранних систем и доступ к данным на уровне записей заставляли пользователя самого производить всю оптимизацию доступа к БД, без какой-либо поддержки системы. f. После появления реляционных систем большинство ранних систем было оснащено реляционными интерфейсами. Однако в большинстве случаев это не сделало их по-настоящему реляционными системами, поскольку оставалась возможность манипулировать данными в естественном для них режиме. 3.1. Основные особенности систем, основанных на инвертированных списках К числу наиболее известных и типичных представителей таких систем относятся Datacom DB компании Applied Data Research, Inc. ADR , ориентированная на использование на машинах основного класса фирмы IBM, и Adabas компании Software AG. Организация доступа к данным на основе инвертированных списков используется практически во всех современных реляционных СУБД, но в этих системах пользователи не имеют непосредственного доступа к инвертированным спискам индексам. Кстати, когда мы будем рассматривать внутренние интерфейсы реляционных СУБД, вы увидите, что они очень близки к пользовательским интерфейсам систем, основанных на инвертированных списках. 3.1.1. Структуры данных База данных, организованная с помощью инвертированных списков, похожа на реляционную БД, но с тем отличием, что хранимые таблицы и пути доступа к ним видны пользователям.

При этом a. Строки таблиц упорядочены системой в некоторой физической последовательности. b. Физическая упорядоченность строк всех таблиц может определяться и для всей БД так делается, например, в Datacom DB . c. Для каждой таблицы можно определить произвольное число ключей поиска, для которых строятся индексы.

Эти индексы автоматически поддерживаются системой, но явно видны пользователям. 3.1.2. Манипулирование данными Поддерживаются два класса операторов a. Операторы, устанавливающие адрес записи, среди которых прямые поисковые операторы например, найти первую запись таблицы по некоторому пути доступа операторы, находящие запись в терминах относительной позиции от предыдущей записи по некоторому пути доступа. Операторы над адресуемыми записями Типичный набор операторов LOCATE FIRST - найти первую запись таблицы T в физическом порядке возвращает адрес записи LOCATE FIRST WITH SEARCH KEY EQUAL - найти первую запись таблицы T с заданным значением ключа поиска K возвращает адрес записи LOCATE NEXT - найти первую запись, следующую за записью с заданным адресом в заданном пути доступа возвращает адрес записи LOCATE NEXT WITH SEARCH KEY EQUAL - найти следующую запись таблицы T в порядке пути поиска с заданным значением K должно быть соответствие между используемым способом сканирования и ключом K возвращает адрес записи LOCATE FIRST WITH SEARCH KEY GREATER - найти первую запись таблицы T в порядке ключа поиска K cо значением ключевого поля, большим заданного значения K возвращает адрес записи RETRIVE - выбрать запись с указанным адресом UPDATE - обновить запись с указанным адресом DELETE - удалить запись с указанным адресом STORE - включить запись в указанную таблицу операция генерирует адрес записи. 3.1.3. Ограничения целостности Общие правила определения целостности БД отсутствуют.

В некоторых системах поддерживаются ограничения уникальности значений некоторых полей, но в основном все возлагается на прикладную программу. 3.2. Иерархические системы Типичным представителем наиболее известным и распространенным является Information Management System IMS фирмы IBM. Первая версия появилась в 1968 г. До сих пор поддерживается много баз данных, что создает существенные проблемы с переходом как на новую технологию БД, так и на новую технику. 3.2.1. Иерархические структуры данных Иерархическая БД состоит из упорядоченного набора деревьев более точно, из упорядоченного набора нескольких экземпляров одного типа дерева.

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

Пример типа дерева схемы иерархической БД Здесь Отдел является предком для Начальник и Сотрудники, а Начальник и Сотрудники - потомки Отдел. Между типами записи поддерживаются связи.

База данных с такой схемой могла бы выглядеть следующим образом мы показываем один экземпляр дерева Все экземпляры данного типа потомка с общим экземпляром типа предка называются близнецами.

Для БД определен полный порядок обхода - сверху-вниз, слева-направо.

В IMS использовалась оригинальная и нестандартная терминология сегмент вместо запись, а под записью БД понималось все дерево сегментов. 3.2.2. Манипулирование данными Примерами типичных операторов манипулирования иерархически организованными данными могут быть следующие Найти указанное дерево БД например, отдел 310 Перейти от одного дерева к другому Перейти от одной записи к другой внутри дерева например, от отдела - к первому сотруднику Перейти от одной записи к другой в порядке обхода иерархии Вставить новую запись в указанную позицию Удалить текущую запись. 3.2.3. Ограничения целостности Автоматически поддерживается целостность ссылок между предками и потомками.

Основное правило никакой потомок не может существовать без своего родителя.

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

Примером представления приведенной выше БД может быть иерархия 3.3. Сетевые системы Типичным представителем является Integrated Database Management System IDMS компании Cullinet Software, Inc предназначенная для использования на машинах основного класса фирмы IBM под управлением большинства операционных систем.

Архитектура системы основана на предложениях Data Base Task Group DBTG Комитета по языкам программирования Conference on Data Systems Languages CODASYL , организации, ответственной за определение языка программирования Кобол. Отчет DBTG был опубликован в 1971 г а в 70-х годах появилось несколько систем, среди которых IDMS. 3.3.1. Сетевые структуры данных Сетевой подход к организации данных является расширением иерархического.

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

Тип связи определяется для двух типов записи предка и потомка. Экземпляр типа связи состоит из одного экземпляра типа записи предка и упорядоченного набора экземпляров типа записи потомка. Для данного типа связи L с типом записи предка P и типом записи потомка C должны выполняться следующие два условия Каждый экземпляр типа P является предком только в одном экземпляре L Каждый экземпляр C является потомком не более, чем в одном экземпляре L. На формирование типов связи не накладываются особые ограничения возможны, например, следующие ситуации a. Тип записи потомка в одном типе связи L1 может быть типом записи предка в другом типе связи L2 как в иерархии. b. Данный тип записи P может быть типом записи предка в любом числе типов связи. c. Данный тип записи P может быть типом записи потомка в любом числе типов связи. d. Может существовать любое число типов связи с одним и тем же типом записи предка и одним и тем же типом записи потомка и если L1 и L2 - два типа связи с одним и тем же типом записи предка P и одним и тем же типом записи потомка C, то правила, по которым образуется родство, в разных связях могут различаться. e. Типы записи X и Y могут быть предком и потомком в одной связи и потомком и предком - в другой. f. Предок и потомок могут быть одного типа записи. Простой пример сетевой схемы БД 3.3.2. Манипулирование данными Примерный набор операций может быть следующим Найти конкретную запись в наборе однотипных записей инженера Сидорова Перейти от предка к первому потомку по некоторой связи к первому сотруднику отдела 310 Перейти к следующему потомку в некоторой связи от Сидорова к Иванову Перейти от потомка к предку по некоторой связи найти отдел Сидорова Создать новую запись Уничтожить запись Модифицировать запись Включить в связь Исключить из связи Переставить в другую связь и т.д. 3.3.3. Ограничения целостности В принципе их поддержание не требуется, но иногда требуют целостности по ссылкам как в иерархической модели. 3.4. Достоинства и недостатки Сильные места ранних СУБД Развитые средства управления данными во внешней памяти на низком уровне Возможность построения вручную эффективных прикладных систем Возможность экономии памяти за счет разделения подобъектов в сетевых системах. Недостатки Слишком сложно пользоваться Фактически необходимы знания о физической организации Прикладные системы зависят от этой организации Их логика перегружена деталями организации доступа к БД. Теоретические основы Мы приступаем к изучению реляционных баз данных и систем управления реляционными базами данных.

Этот подход является наиболее распространенным в настоящее время, хотя наряду с общепризнанными достоинствами обладает и рядом недостатков.

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

Реляционные системы далеко не сразу получили широкое распространение.

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

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

Еще одним часто отмечаемым недостатком реляционных баз данных является невозможность адекватного отражения семантики предметной области.

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

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

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

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

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

В самом общем виде домен определяется заданием некоторого базового типа данных, к которому относятся элементы домена, и произвольного логического выражения, применяемого к элементу типа данных.

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

В нашем примере значения доменов Номера пропусков и Номера групп относятся к типу целых чисел, но не являются сравнимыми. Заметим, что в большинстве реляционных СУБД понятие домена не используется, хотя в Oracle V.7 оно уже поддерживается. 4.1.3. Схема отношения, схема базы данных Схема отношения - это именованное множество пар имя атрибута, имя домена или типа, если понятие домена не поддерживается. Степень или арность схемы отношения - мощность этого множества.

Степень отношения СОТРУДНИКИ равна четырем, то есть оно является 4-арным. Если все атрибуты одного отношения определены на разных доменах, осмысленно использовать для именования атрибутов имена соответствующих доменов не забывая, конечно, о том, что это является всего лишь удобным способом именования и не устраняет различия между понятиями домена и атрибута. Схема БД в структурном смысле - это набор именованных схем отношений. 4.1.4. Кортеж, отношение Кортеж, соответствующий данной схеме отношения это множество пар имя атрибута, значение, которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения. Значение является допустимым значением домена данного атрибута или типа данных, если понятие домена не поддерживается. Тем самым, степень или арность кортежа, т.е. число элементов в нем, совпадает с арностью соответствующей схемы отношения.

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

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

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

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

Этой терминологии придерживаются в большинстве коммерческих реляционных СУБД. Реляционная база данных - это набор отношений, имена которых совпадают с именами схем отношений в схеме БД. Как видно, основные структурные понятия реляционной модели данных если не считать понятия домена имеют очень простую интуитивную интерпретацию, хотя в теории реляционных БД все они определяются абсолютно формально и точно.

Методы, использованные для решения задачи. Базовым инструментом для написания данного проекта был взят Delphi. Открытая архитектура Delphi Компания Borland в развитии своих объектно-ориентированных средств разработки явно пришла к тому выводу, что повторное использование кода и объектная ориентация не являются единственными средствами повышения производительности программистов. С появлением Delphi разработчик может не только создавать и предоставлять своим коллегам готовые к использованию компоненты, но и расширять функциональные возможности среды, в которой он работает, с помощью так называемых открытых интерфейсов. Такой подход позволяет использовать Delphi уже в роли общего ядра набора инструментальных средств на всех этапах создания прикладных систем - начиная с CASE-систем и заканчивая генерацией документации по создаваемым проектам, с полной их интеграцией в святая святых любой среды программирования - IDE. Рассмотрим основные возможности расширения функциональности среды Delphi для того, чтобы оценить степень открытости архитектуры этого инструмента.

Строительные блоки приложений - компоненты Как известно, фундаментальной основой визуальных средств Delphi является компонентный подход.

В чем же он заключается? Delphi строится на базе компилятора объектно-ориентированного языка Object Pascal, продолжающего линию диалектов Pascal - Turbo Pascal и Borland Pascal. По мере своего развития, каждая очередная реализация Pascal компании Borland включала все новые расширения синтаксиса, отражающие последние достижения в области языков программирования.

Если подходить к оценке качественных ступеней развития Pascal, особо следует отметить три из них, направленные на поддержку концепции повторного использования кода модульная архитектура, с возможностью разделения интерфейсной и описательной частей Turbo Pascal 4.0 средства объектной ориентации, со всеми, присущими ей характеристиками - наследованием, инкапсуляцией и полиморфизмом Turbo Pascal 5.5 поддержка механизмов RTTI Run-Time Type Information, позволяющих получать информацию о базовых характеристиках объектных типов классов и их экземпляров объектов с помощью языковых средств, непосредственно встроенных в системную библиотеку и структуру организации описаний классов Delphi 1.0 - Object Pascal Следствием введения поддержки RTTI стала возможность создания визуального инструмента разработки приложений, каковым и является Delphi.

На определенном уровне иерархии наследования базовой библиотеки классов Delphi появляется класс TPersistent, обеспечивающий необходимый уровень абстракции потокового ввода вывода объектов экземпляров классов. Его наследником выступает класс TComponent, определяющий основы поведения компонент Delphi VCL Visual Component Library в режиме design-time этап конструирования

Конец работы -

Эта тема принадлежит разделу:

Разработка программного обеспечения для Отделения Реанимации и Интенсивной Терапии новорожденных МГБ N1 г. Сургута

Сильные места и недостатки ранних систем 1. Основные особенности систем, основанных на инвертированных списках 33 3.1.1. Структуры данных 2.. Демографическая ситуация нашего региона достаточно благополучная. Рождаемость год от года не только не падает но еще и растет, но тяжелые условия крайнего севера и постоянно..

Если Вам нужно дополнительный материал на эту тему, или Вы не нашли то, что искали, рекомендуем воспользоваться поиском по нашей базе работ:

Что будем делать с полученным материалом:

Если этот материал оказался полезным ля Вас, Вы можете сохранить его на свою страничку в социальных сетях:

Естественно, организация типичной СУБД и состав ее компонентов соответствует рассмотренному нами набору функций. Напомним, что мы выделили следующие основные функции СУБД:

• управление данными во внешней памяти;
• управление буферами оперативной памяти;
• управление транзакциями;
• журнализация и восстановление БД после сбоев;
• поддержание языков БД.

Логически в современной реляционной СУБД можно выделить наиболее внутреннюю часть - ядро СУБД (часто его называют Data Base Engine), компилятор языка БД (обычно SQL), подсистему поддержки времени выполнения, набор утилит. В некоторых системах эти части выделяются явно, в других - нет, но логически такое разделение можно провести во всех СУБД.

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

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

Наконец, в отдельные утилиты БД обычно выделяют такие процедуры, которые слишком накладно выполнять с использованием языка БД, например, загрузка и выгрузка БД, сбор статистики, глобальная проверка целостности БД и т.д. Утилиты программируются с использованием интерфейса ядра СУБД, а иногда даже с проникновением внутрь ядра.

Пример: System R

Основными целями разработчиков System R являлись следующие:

• обеспечить ненавигационный интерфейс высокого уровня пользователя с системой, позволяющий достичь независимости данных и дать возможность пользователям работать максимально эффективно;
• обеспечить многообразие допустимых способов использования СУБД, включая программируемые транзакции, диалоговые транзакции и генерацию отчетов;
• поддерживать динамически изменяемую среду баз данных, в которой отношения, индексы, представления, транзакции и другие объекты могут легко добавляться и уничтожаться без приостановки нормального функционирования системы;
• обеспечить возможность параллельной работы с одной базой данных многих пользователей с допущением параллельной модификации объектов базы данных при наличии необходимых средств защиты целостности базы данных;
• обеспечить средства восстановления согласованного состояния баз данных после разного рода сбоев аппаратуры или программного обеспечения;
• обеспечить гибкий механизм, позволяющий определять различные представления хранимых данных, и ограничивать этими представлениями доступ пользователей к базе данных по выборке и модификации на основе механизма авторизации;
• обеспечить производительность системы при выполнении упомянутых функций, сопоставимую с производительностью существующих СУБД низкого уровня.

Структурная организация System R вполне согласуется с поставленными при ее разработке целями. Основными структурными компонентами System R являются система управления реляционной памятью (Relational Storage System - RSS) и компилятор запросов языка SQL. RSS обеспечивает интерфейс довольно низкого, но достаточного для реализации SQL уровня для доступа к хранимым в базе данным. Синхронизация транзакций, журнализация изменений и восстановление баз данных после сбоев также относятся к числу функций RSS. Компилятор запросов использует интерфейс RSS для доступа к разнообразной справочной информации (каталогам отношений, индексов, прав доступа, условий целостности, условных воздействий и т.д.) и производит рабочие программы, выполняемые в дальнейшем также с использованием интерфейса RSS. Таким образом, система естественно разделяется на два уровня - уровень управления памятью и синхронизацией, фактически, не зависящий от базового языка запросов системы, и языковой уровень (уровень SQL), на котором решается большинство проблем System R. Заметим, что эта независимость скорее условная, чем абсолютная: язык SQL можно заменить на другой язык, но он должен обладать примерно такой же семантикой.

Функции СУБД. Типовая организация СУБД.

Наименование параметра	Значение
Тема статьи:	Функции СУБД. Типовая организация СУБД.
Рубрика (тематическая категория)	Связь

ПОНЯТИЕ СУБД. ФУНКЦИИ. ВНУТРЕННЯЯ АРХИТЕКТУРА.

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

1. управление данными во внешней памяти;

2. управление буферами оперативной памяти;

3. управление транзакциями;

4. журнализация;

5. поддержка языков БД.

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

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

Управление буферами оперативной памяти. СУБД обычно работают с БД значительного размера; по крайней мере, данный размер существенно больше доступного объёма оперативной памяти. Понятно, что если при обращении к любому элементу данных будет производиться обмен с внешней памятью, то вся система будет работать со скоростью устройства внешней памяти. Практически единственным способом реального увеличения этой скорости является буферизация данных в оперативной памяти. При этом даже если операционная система производит общесистемную буферизацию (как в случае ОС UNIX), этого недостаточно для целœей СУБД, которая располагает гораздо большей информацией о полезности буферизации какой-либо части БД. По этой причине в развитых СУБД поддерживается собственный набор буферов оперативной памяти с собственной дисциплиной замены буферов.

Отметим, что существует отдельное направление СУБД, ĸᴏᴛᴏᴩᴏᴇ ориентировано на постоянное присутствие в оперативной памяти всœей БД. Это направление основывается на предположении, что в будущем объём оперативной памяти компьютеров будет настолько велик, что позволит не беспокоиться о буферизации.

Управление транзакциями. Транзакция - ϶ᴛᴏ последовательность операций над БД, рассматриваемых СУБД как единое целое. Либо транзакция успешно выполняется и СУБД фиксирует (COMMIT) изменения БД, произведенные этой транзакцией, во внешней памяти, либо ни одно из этих изменений никак не отражается на состоянии БД. Понятие транзакции крайне важно для поддержания логической целостности БД. В случае если вспомнить наш пример информационной системы с файлами СОТРУДНИКИ и ОТДЕЛЫ , то единственным способом не нарушить целостность БД при выполнении операции приема на работу нового сотрудника является объединœение элементарных операций над файлами СОТРУДНИКИ и ОТДЕЛЫ в одну транзакцию. Τᴀᴋᴎᴍ ᴏϬᴩᴀᴈᴏᴍ, поддержание механизма транзакций является обязательным условием даже однопользовательских СУБД (если, конечно, такая система заслуживает названия СУБД). В общем же понятие транзакции наиболее применимо к многопользовательским СУБД.

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

С управлением транзакциями в многопользовательской СУБД так же связаны важные понятия сериализации транзакций и сериального плана выполнения смеси транзакций.

Под сериализаций параллельно выполняющихся транзакций принято понимать такой порядок планирования их работы, при котором суммарный эффект смеси транзакций эквивалентен эффекту их некоторого последовательного выполнения. Сериальный план выполнения смеси транзакций - ϶ᴛᴏ такой план, который приводит к сериализации транзакций. Понятно, что если удается добиться действительно сериального выполнения смеси транзакций, то для каждого пользователя, по инициативе которого образована транзакция, присутствие других транзакций будет незаметно (если не считать некоторого замедления работы по сравнению с однопользовательским режимом).

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

Журнализация. Одним из базовых требований к СУБД является надежность хранения данных во внешней памяти. Под надежностью хранения принято понимать то, что СУБД должна быть в состоянии восстановить последнее согласованное состояние БД после любого аппаратного или программного сбоя. Обычно рассматриваются два возможных вида аппаратных сбоев: так называемые мягкие сбои, которые можно трактовать как внезапную остановку работы компьютера (к примеру, аварийное выключение питания), и жесткие сбои, характеризуемые потерей информации на носителях внешней памяти. Примерами программных сбоев бывают: аварийное завершение работы СУБД (по причинœе ошибки в программе или в результате некоторого аппаратного сбоя) или аварийное завершение пользовательской программы, благодаря чему некоторая транзакция остается незавершенной. Первую ситуацию можно рассматривать как особый вид мягкого аппаратного сбоя; при возникновении последней требуется ликвидировать последствия только одной транзакции.

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

Журнал - ϶ᴛᴏ особая часть БД, недоступная пользователям СУБД и поддерживаемая с особой тщательностью (иногда поддерживаются две копии журнала, располагаемые на разных физических дисках), в которую поступают записи обо всœех изменениях основной части БД. В разных СУБД изменения БД журнализуются на разных уровнях: иногда запись в журнале соответствует некоторой логической операции изменения БД (к примеру, операции удаления строки из таблицы реляционной БД), иногда – минимальной внутренней операции модификации страницы внешней памяти; в некоторых системах одновременно используются оба подхода. Во всœех случаях придерживаются стратегии "упреждающей" записи в журнал (так называемого протокола Write Ahead Log – WAL). Эта стратегия состоит по сути в том, что запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД. Известно, что если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить всœе проблемы восстановления БД после любого сбоя.

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

При мягком сбое во внешней памяти в основной части БД могут находиться объекты, модифицированные транзакциями, не закончившимися к моменту сбоя, и могут отсутствовать объекты, модифицированные транзакциями, которые к моменту сбоя успешно завершились (по причинœе использования буферов оперативной памяти, содержимое которых при мягком сбое пропадает). При соблюдении протокола WAL во внешней памяти журнала должны гарантированно находиться записи, относящиеся к операциям модификации обоих видов объектов. Целью процесса восстановления после мягкого сбоя является состояние внешней памяти основной части БД, ĸᴏᴛᴏᴩᴏᴇ возникло бы при фиксации во внешней памяти изменений всœех завершившихся транзакций и ĸᴏᴛᴏᴩᴏᴇ не содержало бы никаких следов незаконченных транзакций. Для того, чтобы этого добиться, сначала производят откат незавершенных транзакций (undo), а потом повторно воспроизводят (redo) те операции завершенных транзакций, результаты которых не отображены во внешней памяти. Этот процесс содержит много тонкостей, связанных с общей организацией управления буферами и журналом. Более подробно остановимся на этом при рассмотрении внутренней огранизации баз данных.

Для восстановления БД после жесткого сбоя используют журнал и архивную копию БД. Архивная копия - ϶ᴛᴏ полная копия БД к моменту начала заполнения журнала (имеется много вариантов и более гибкой трактовки смысла архивной копии). Конечно, для нормального восстановления БД после жесткого сбоя крайне важно, чтобы журнал не пропал. Как уже отмечалось, к сохранности журнала во внешней памяти в СУБД предъявляются особо повышенные требования. Тогда восстановление БД состоит в том, что исходя из архивной копии по журналу воспроизводится работа всœех транзакций, которые закончились к моменту сбоя. В принципе, можно даже воспроизвести работу незавершенных транзакций и продолжить их работу после завершения восстановления. При этом в реальных системах это обычно не делается, поскольку процесс восстановления после жесткого сбоя является достаточно длительным.

Поддержка языков БД . Для работы с базами данных используются специальные языки, в целом называемые языками баз данных. В ранних СУБД поддерживалось несколько специализированных по своим функциям языков. Можно особо выделить два языка – язык определœения схемы БД (SDL –Schema Definition Language) и язык манипулирования данными (DML – Data Manipulation Language). SDL служил главным образом для определœения логической структуры БД, ᴛ.ᴇ. той структуры БД, какой она представляется пользователям. DML содержал набор операторов манипулирования данными, ᴛ.ᴇ. операторов, позволяющих заносить данные в БД, удалять, модифицировать или выбирать существующие данные. Рассмотрим более подробно языки ранних СУБД в последующих лекциях.

В современных СУБД обычно поддерживается единый интегрированный язык, содержащий всœе необходимые средства для работы с БД, начиная от ее создания, и обеспечивающий базовый пользовательский интерфейс с базами данных. Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL (Structured Query Language), который более подробно будет рассмотрен в 5 главе. Перечислим пока только основные функции реляционной СУБД, поддерживаемые на "языковом" уровне (ᴛ.ᴇ. функции, поддерживаемые при реализации интерфейса SQL).

Прежде всœего, язык SQL сочетает средства SDL и DML, ᴛ.ᴇ. позволяет определять схему реляционной БД и манипулировать данными. При этом именование объектов БД (для реляционной БД – именование таблиц и их столбцов) поддерживается на языковом уровне в том смысле, что компилятор языка SQL производит преобразование имен объектов в их внутренние идентификаторы на основании специально поддерживаемых служебных таблиц-каталогов. Внутренняя часть СУБД (ядро) вообще не работает с именами таблиц и их столбцов.

Язык SQL содержит специальные средства определœения ограничений целостности БД. Опять же, ограничения целостности хранятся в специальных таблицах-каталогах, и обеспечение контроля целостности БД производится на языковом уровне, ᴛ.ᴇ. при компиляции операторов модификации БД компилятор SQL на основании имеющихся в БД ограничений целостности генерирует соответствующий программный код.

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

Наконец, авторизация доступа к объектам БД производится также на базе специального набора операторов SQL. Идея состоит в том, что для выполнения операторов SQL разного вида пользователь должен обладать различными полномочиями. Пользователь, создавший таблицу БД, обладает полным набором полномочий для работы с этой таблицей. В число этих полномочий входит полномочие на передачу всœех или части полномочий другим пользователям, включая полномочие на передачу полномочий. Полномочия пользователœей описываются в специальных таблицах-каталогах, контроль полномочий поддерживается на языковом уровне.

Функции СУБД. Типовая организация СУБД. - понятие и виды. Классификация и особенности категории "Функции СУБД. Типовая организация СУБД." 2017, 2018.

Организация типичной СУБД и состав ее компонентов соответствует основным функциям СУБД.

В состав БД как сложной человеко-машинной системы включаются следующие взаимосвязанные и взаимозависимые компоненты :

1. Информационная компонента – базы данных, описание баз данных (схемы), информация о пользователях, информация о предметной области и некоторая другая информация.

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

2. Программные средства (обеспечение взаимодействия всех частей системы при ее функционировании) – СУБД, операционная система, прикладное программное обеспечение.

3. Языковые средства (обеспечение интерфейса пользователей с банком данных) – языки описания данных, языки манипулирования данными, языки запросов и другие языки.

4. Технические средства – универсальные ЭВМ, периферийные средства для ввода информации в базу данных, периферийные средства для отображения выводимой информации и другие.

5. Организационно-методические средства – инструкции, методические и регламентирующие материалы, предназначенные для пользователей разных категорий, взаимодействующих с банком данных. Администраторы, разработчики, прикладные программисты, пользователи.

Логически в современной СУБД можно выделить наиболее внутреннюю часть - ядро СУБД (часто его называют DataBase Engine), компилятор языка БД, подсистему поддержки времени выполнения, набор утилит . В некоторых системах эти части выделяются явно, в других - нет, но логически такое разделение можно провести во всех СУБД.

Ядро СУБД отвечает за управление данными во внешней памяти, управление буферами оперативной памяти, управление транзакциями и журнализацию. Функции этих компонентов взаимосвязаны, и для обеспечения корректной работы СУБД все эти компоненты должны взаимодействовать по тщательно продуманным и проверенным протоколам. Ядро СУБД обладает собственным интерфейсом, не доступным пользователям напрямую и используемым в программах, в подсистеме поддержки выполнения таких программ, в утилитах БД. Ядро СУБД является основной резидентной частью СУБД.

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

В отдельные утилиты БД обычно выделяют такие процедуры, которые слишком накладно выполнять с использованием языка БД, например, загрузка и выгрузка БД, сбор статистики, глобальная проверка целостности БД и т.д. Утилиты программируются с использованием интерфейса ядра СУБД, а иногда даже с проникновением внутрь ядра.

Вопрос 11. Дайте определение понятиям индексирование и хеширование. Проанализируйте использо­вание индексов для ускорения извлечения данных

Во всех существующих СУБД имеется средство , обеспечивающее оптимальный по скорости доступ к данным. Такая надстройка над данными называется индексами базы данных.

Индекс – структура данных, которая помогает СУБД быстрее обнаружить отдельные записи в файле и сократить время выполнения запросов пользователей.

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

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

Хранимый файл может иметь несколько индексов. Они могут использоваться как раздельно, так и совместно для более эффективного доступа к записям о поставщиках.

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

При обновлении БД индекс приводится в соответствие с обновленной базой. Индексы поддерживаются динамически. Большое число индексов может замедлить работу с БД.

Использование индексов наряду со значительным ускорением процесса выборки или извлечения данных имеет и существенный недостаток. Это замедление процесса обновления данных, т.к. при каждом добавлении новой записи в индексированный файл потребуется также добавить новый индекс в индексный файл. При выборе некоторого поля для индексирования необходимо выяснить, что более важно для данной СУБД: скорость извлечения данных или скорость обновления?

Индекс представляет собой таблицу, которая содержит ключевые значения для каждой записи в таблице данных и записанные в порядке, требуемом для пользователя. Ключевые значения определяются на основе одного или нескольких полей таблицы. Кроме того, индекс содержит уникальные ссылки на соответствующие записи в таблице. На рис.1.12 показан фрагмент таблицы CUSTOMERS, содержащей информацию о покупателях, и индекс IDX_NAME, построенный на основе поля Name таблицы CUSTOMERS. Индекс IDX_NAME содержит значения ключевого поля Name, упорядоченные в алфавитном порядке, и ссылки на соответствующие записи в таблице CUSTOMERS. Каждая таблица может иметь несколько различных индексов, каждый из которых определяет свой собственный порядок следования записей. Например, таблица AUTHORS может иметь индексы для представления данных об авторах, упорядоченные по дате рождения или по алфавиту. Таким образом, каждый индекс используется для представления одних и тех же данных, но упорядоченных различным образом. Вообще говоря, таблицы в базе данных могут и не иметь индексов. В этом случае для большой таблицы время поиска определенной записи может быть весьма значительным и использование индекса становиться необходимым. С другой стороны, не следует увлекаться созданием слишком большого количества индексов, так как это может заметно увеличить время необходимое для обновления базы данных и значительно увеличить размер файла базы данных.

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

На практике используются многоуровневые индексы на основе бинарных деревьев.

Альтернативным деревьям и все более популярным подходом к организации индексов является использование техники хэширования.

Хеширование – вычисление записи по значению ключа.

Два достоинства: сжимает информацию, быстрый доступ к элементам.

Для хеширования главными задачами является: 1) выбор хеш-функции, так, чтобы уменьшить число конфликтных ситуаций; 2) нахождение разрешения способа конфликтных ситуаций.

Процесс хеширования делится на три этапа: 1) вычисление хеш-адреса; 2) уточнение хеш-адреса в случае конфликтной ситуации; 3) размещение ключа в памяти.

При выборе хеш-функции необходимо учитывать: 1) сложность вычислений; 2) равномерность распределения данных; 3) не допустить скучивания значений ключей.

В целом методы бинарных деревьев и хэширования все более сближаются.

Вопрос 12. Дайте определение понятиям пер­вичный и внешний ключи. Охарактеризуйте логические связи между отношениями в реляционной модели данных. Выделите наиболее часто используемые типы связей

Главная идея реляционной модели состоит в представлении произвольных структур данных в виде совокупности реляционных отношений - двумерных массивов типа "объекты-признаки", то есть таблиц. Таблица отражает тип объекта реального мира, а каждая ее строка – конкретный объект.

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

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

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

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

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