Множество пар имя атрибута значение которое содержит одно вхождение каждого имени атрибута

21.08.2019 431.1 Кб 2 ОГУ Экономическая теория.doc

17.05.2015 28.19 Кб 183 огэ общ 2 февр.docx

17.05.2015 21.84 Кб 23 ОГЭ ОБЩЕСТВО 26 ЯНВАРЯ.docx

19.08.2019 138.24 Кб 1 оконч.КР 2007.doc

19.08.2019 67.27 Кб 0 оконч.КР 2007.docx

06.09.2019 150.78 Кб 2 Окончательный вариант..docx

18.03.2016 26.19 Кб 5 Олимп респблика.docx

24.08.2019 63.37 Кб 9 Ольховский.docx

22.09.2019 74.79 Кб 1 ом.docx

22.12.2018 52.63 Кб 1 ОМЗ 17-40.docx

28.08.2019 92.57 Кб 8 ОНОТ Прогрессивные формы организации труда 4 ва. docx

Ограничение

Для продолжения скачивания необходимо пройти капчу:

Лекция 1. Введение в проектирование баз данных

**1-ый учебный вопрос: Основные определения курса.** *Проектирование баз данных* — процесс создания схемы базы данных и определения необходимых ограничений целостности. На самом деле, в нашем курсе мы пойдем несколько дальше и расширим данное выше определение до следующего вида: *Проектирование баз данных* — процесс создания схемы базы данных и определения необходимых ограничений целостности для реляционной модели данных, процесс создание схемы базы данных для хранилища данных и создание nosql моделей данных. Также, в процессе прохождения курса мы рассмотрим некоторые особенности релиза проекта баз данных в разных СУБД и некоторые особенности оптимизации базы данных на этапе ее релиза. *Концептуальное (инфологическое) проектирование* — построение семантической модели предметной области, то есть информационной модели наиболее высокого уровня абстракции. Такая модель создаётся без ориентации на какую-либо конкретную СУБД и модель данных. Будем принимать термины «семантическая модель», «концептуальная модель» и «инфологическая модель», которые могут встретиться в литературе, как синонимы. *Логическое (даталогическое) проектирование* — создание схемы базы данных на основе конкретной модели данных, например, чаще всего — реляционной модели данных. Для реляционной модели данных даталогическая модель будет включать в себя набор схем отношений, обычно с указанием первичных ключей, а также связей между отношениями, представляющих собой внешние ключи. На этапе логического проектирования учитывается специфика конкретной модели данных, но может не учитываться специфика конкретной СУБД. *Физическое проектирование* — создание схемы базы данных для конкретной СУБД. Специфика конкретной СУБД может включать в себя ограничения на именование объектов базы данных, ограничения на поддерживаемые типы данных и т.д. Кроме того, специфика конкретной СУБД при физическом проектировании включает выбор решений, связанных с физической средой хранения данных (выбор методов управления дисковой памятью, разделение БД по файлам и устройствам, методов доступа к данным), создание индексов и другие средства оптимизации. **2-ой учебный вопрос: Концептуальное проектирование БД.** Сразу необходимо отметить, что при осуществлении концептуального проектирования не учитывается ни модель данных, с которой инженер имеет дело, но формальные правила нотаций, которые будут использоваться при описании конкретной модели. Для осуществления моделирования такого рода обычно применяются стандарты, рекомендации или руководства, разработанные на предприятии, или же иные, распространенные абстрактные модели. В качестве одной из таких моделей может выступать модель “сущность-связь” (ER-модель). Ниже, дадим основные определения элементов концептуальной модели данных: *Сущность БД* – элемент базы данных, представляющий собой объект, который существует независимо от других, за которым хотел бы осуществлять наблюдение владелец базы данных. Каждая сущность обладает собственным именем и кратким описанием. *Экземпляр сущности* – отдельно взятый элемент сущности БД, конкретный представитель сущности. *Документирование сущностей* – ведение словаря данных концептуальной модели с записью сущностей. *Связь* – ассоциация, объединяющая несколько сущностей. Может существовать между несколькими сущностями (наиболее распространенная – между двумя сущностями, бинарная) или же между сущностью и ей самой (рекурсивная). *Класс принадлежности сущности* — это характер участия сущности в связи. Различают обязательные и необязательные классы принадлежности сущности к связи. Обязательным является такой класс принадлежности, когда экземпляры сущности участвуют в установлении связи в обязательном порядке. В противном случае сущность принадлежит к необязательному классу принадлежности. *Имя связи* – любое осмысленное название связи, выраженное в глагольном наклонении. Словарь данных концептуальной модели, связи — центральное хранилище информации, содержащее в себе “тройки”: “описание связи – тип связи – класс принадлежности сущностей, участвующий в связи”. *ER — модель* – наиболее часто применимая в логическом моделировании модель. ER — модель представляет собой формальную конструкцию, которая сама по себе не предписывает никаких графических средств её визуализации. В настоящий момент времени можно выделить две ключевых нотации для изображения графических диаграмм ER – модели: нотация Питера Чена и нотация Crow’s Foot. *Нотация Питера Чена* — множества сущностей изображаются в виде прямоугольников, множества отношений изображаются в виде ромбов. Если сущность участвует в отношении, они связаны линией. Если отношение не является обязательным, то линия пунктирная, рис. 1.  *Нотация Crow’s Foot.* Согласно данной нотации, сущность изображается в виде прямоугольника, содержащего её имя, выражаемое существительным. Связь изображается линией, которая связывает две сущности. Тип связи указывается графически, множественность связи изображается в виде “вилки” на конце связи. Класс принадлежности сущности так же изображается графически — необязательность сущности помечается кружком на конце связи. Именование обычно выражается одним глаголом в изъявительном наклонении настоящего времени: “имеет”, “принадлежит” и т. д.; или глаголом с поясняющими словами: “включает в себя”, и т.п. Наименование может быть одно для всей связи или два для каждого из концов связи. Во втором случае, название левого конца связи указывается над линией связи, а правого – под линией. Каждое из названий располагаются рядом с сущностью, к которой оно относится, рис. 2.  *Атрибут* – свойство сущности. Для каждого атрибута, при концептуальном проектировании определяются следующие значения: — имя атрибута, его краткое описание; — тип атрибута, размерность его значений (если это возможно); — значение атрибута “по умолчанию” (если необходимо); *Первичный ключ сущности* – атрибут сущности, позволяющий уникальным образом идентифицировать ее экземпляры. Далее, поэтапно, перечислим все процедуры концептуального проектирования. 1. Определение сущностей и их документирование. Каждой сущности присваивается имя, которое будет понятно другим пользователям. При этом имя будет точно характеризовать смысл сущности. Имена и описание сущностей заносятся в словарь данных. Для каждой сущности примерно устанавливается ожидаемое количество экземпляров. 2. Определение связей между сущностями и их документирование. Связям присваиваются логичные и понятные имена в глагольном наклонении. Описания связей с их типом, классом принадлежности сущностей и именами заносится в словарь данных. 3. Создание ER – модели предметной области. Создается несколько альтернативных макетов модели, называемых эскизами. Из этих вариантов выбирается оптимальный вариант модели хранения данных и оптимальный набор его элементов. 4. Определение атрибутов и их документирование. Каждому атрибуту присваивается осмысленное имя, понятное пользователю и точно раскрывающее его суть. Информация об атрибутах помещается в словарь данных. 5. Определение значений атрибутов и их документирование (если они дискретны). Дискретные атрибуты (построенные на дискретном, то есть – ограниченном множестве значений, которые они могут принимать) должны быть зафиксированы в словаре данных в виде конечного дискретного множества. Например, <холодный, теплый, горячий>. 6. Определение первичных ключей сущности и их документирование. Сведения об определенных ключах помещаются в словарь данных. 7. Корректировка эскизов моделей с конечными пользователями БД. Результат представляется ER-моделью с сопровождающей документацией (в первую очередь это – словарь данных). Модель корректируется до тех пор, пока не будет удовлетворять условиям технического задания и/или требованиям конечного пользователя. Возможно проведение аудита соответствия модели техническому заданию. **3-ий учебный вопрос: Логическое проектирование БД.** *Реляционная модель данных* — это набор отношений, имена которых совпадают с именами схем отношений в схеме БД. Основными понятиями реляционных моделей данных являются тип данных, домен, атрибут, кортеж, первичный ключ и отношение. Покажем смысл этих понятий на примере отношения “Сотрудники”, содержащего информацию о сотрудниках некоторого предприятия (рис. 3).  *Тип данных.* Понятие типа данных в реляционной модели данных полностью адекватно по¬нятию типа данных в языках программирования. Напомним, что традиционно (нестрогое) определение типа данных состоит из трех основных компонентов: — определение множества значений данного типа; — определение набора операций, применимых к значениям типа; — определение способа внешнего представления значе¬ний типа (литералов). Обычно в современных реляционных базах данных допускается хранение символьных, числовых данных, битовых строк, специализированных числовых данных (таких как «деньги»), специальных «темпоральных» данных (дата, время, временной интервал), изображений, звуков. В примере на рис. 3 мы имеем дело с данными трех типов: строки символов, целые числа и “деньги”. Домен. В общем виде домен определяется путем задания некоторого базового типа данных, к которому относятся элементы домена, и про¬извольного логического выражения, применяемого к элементу этого типа данных (ограничения домена). Элемент данных является элементом домена в том и толь¬ко в том случае, если вычисление этого логического выражения дает результат ис¬тиной. С каждым доменом связывается имя, уникальное среди имен всех доменов соответствующей базы данных. Наиболее правильной интуитивной трактовкой понятия домена является его восприятие как допустимого потенциального множества значений данного типа. *Схема отношения* — это именованное множество упорядоченных пар , если понятие домена не поддерживается. По определению степенью или «арностью» схемы отношения является мощность этого множества. Например, степень отношения Сотрудники (рис. 3 равна четырем, то есть оно является 4-арным (кватернарным). Если все атрибуты одного отношения определены на разных доменах, то, что¬бы не плодить лишних имен, разумно использовать для именования атрибутов имена соответствующих доменов. *Схема БД* — это множество именованных схем отношений. *Кортеж.* Множество упорядоченных пар , которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения. Значение должно быть допустимым значением домена, на котором определен данный атрибут. *Отношение* — это множество кортежей, соответствующих одной схеме отношения. Определение первичного ключа аналогично определению его в концептуальной модели данных. Далее, поэтапно, перечислим все процедуры логического проектирования. 1. Выбор модели данных. Чаще всего выбирается реляционная модель данных. 2. Определение набора отношений. В соответствии с реляционной моделью данных, на основании утвержденной концептуальной модели данных создаются схемы отношений, отношения и атрибуты логической модели данных. Устанавливаются связи между отношениями. Связи, отношения, доменные ограничения документируются. 3. Нормализация отношений. Как правило, отношения приводятся к третьей нормальной форме. Следует обратить внимания на случаи, когда нормализация не требуется. 4. Проверка логической модели данных на предмет возможности выполнения всех транзакций, заявленных пользователем в техническом задании или оговоренных при начале проектирования. 5. Определение требований поддержки целостности данных. Проверяются следующие типы ограничений: обязательные данные (без null), доменные ограничения, целостность сущностей (правильные первичные ключи), ссылочная целостность (правильные внешние ключи), ограничения по бизнес-правилам. 6. Корректировка логической модели данных с конечными пользователями. Результатом будет окончательный вариант словаря данных и er-модели, готовой к конвертации для реализации в одной из СУБД. **4-ий учебный вопрос: Физическое проектирование БД.** Соотнесем определения, которые мы дали применительно к сущности с терминами, которые используются при построении физической модели (табл. 1). Таблица 1.  Дадим ряд определений для некоторых элементов физической модели. *Физический тип данных* – тип данных, характеризующий столбец с данными. Эти типы данных могут значительно отличаться друг от друга в зависимости от СУБД (MS SQL Server, IBM DB2, Oracle 12c и т.д.), в которой реализована физическая модель. *Уникальный индекс первичного ключа* – индекс, передающий столбцу в таблице все свойства первичного ключа. Именно по этому индексу СУБД определит первичный ключ в таблице и установит условие ссылочной целостности. *Хранимая процедура* — объект базы данных, представляющий собой набор SQL-инструкций, который компилируется один раз и хранится на сервере. Хранимые процедуры очень похожи на обыкновенные процедуры языков высокого уровня, у них могут быть входные и выходные параметры и локальные переменные, в них могут производиться числовые вычисления и операции над символьными данными, результаты которых могут присваиваться переменным и параметрам. Обычная хранимая процедура запускается на исполнение пользователем БД. *Триггер* – хранимая процедура, запускаемая СУБД автоматически, при наступлении определенного в коде хранимой процедуры события. *Внешний ключ* — подмножество столбцов некоторой переменной таблицы R2, значения которых должны совпадать со значениями некоторого первичного ключа некоторой переменной таблицы R1. Таблица R2 в этом случае называется потомком, а таблица R1 – родителем. Выделим этапы физического проектирования баз данных. 1. Проектирование таблиц базы данных с учетом специфики выбранной СУБД. Помимо таблиц реализуются связи, представления, проводится индексирование. 2. Реализация бизнес-правил в выбранной СУБД. Бизнес-правила реализуются при помощи создания хранимых процедур и триггеров на языке SQL. 3. Дальнейшая оптимизация физической модели базы данных. Определяется нагрузка на отдельные элементы базы данных, оценивается пропускная способность и время отклика на запросы в обоих направлениях (на выдачу/на запись), создаются дополнительные индексы, если это требуется. 4. Разработка стратегии обеспечения безопасности информации. Определение пользовательских групп, наделение правами разных ролей, выдача пар “логин-пароль” пользователям БД. 5. Осуществление постоянного мониторинга базы данных и СУБД. Постоянная модернизация физической модели. Отслеживание угроз для БД и СУБД. 

Множество пар имя атрибута значение которое содержит одно вхождение каждого имени атрибута

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

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

4.1.1. Тип данных

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

4.1.2. Домен

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

Наиболее правильной интуитивной трактовкой понятия домена является понимание домена как допустимого потенциального множества значений данного типа. Например, домен «Имена» в нашем примере определен на базовом типе строк символов, но в число его значений могут входить только те строки, которые могут изображать имя (в частности, такие строки не могут начинаться с мягкого знака).

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

4.1.3. Схема отношения, схема базы данных

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

Схема БД (в структурном смысле) — это набор именованных схем отношений.

4.1.4. Кортеж, отношение

Кортеж, соответствующий данной схеме отношения, — это множество пар , которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения. «Значение» является допустимым значением домена данного атрибута (или типа данных, если понятие домена не поддерживается). Тем самым, степень или «арность» кортежа, т.е. число элементов в нем, совпадает с «арностью» соответствующей схемы отношения. Попросту говоря, кортеж — это набор именованных значений заданного типа.

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

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

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

Реляционная база данных — это набор отношений, имена которых совпадают с именами схем отношений в схеме БД.

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

Теоретические основы

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

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

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

Лекция 4. Общие понятия реляционного подхода к организации БД. Основные концепции и термины

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

4.1. Базовые понятия реляционных баз данных

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

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

4.1.1. Тип данных

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

4.1.2. Домен

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

Наиболее правильной интуитивной трактовкой понятия домена является понимание домена как допустимого потенциального множества значений данного типа. Например, домен «Имена» в нашем примере определен на базовом типе строк символов, но в число его значений могут входить только те строки, которые могут изображать имя (в частности, такие строки не могут начинаться с мягкого знака).

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

4.1.3. Схема отношения, схема базы данных

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

Схема БД (в структурном смысле) — это набор именованных схем отношений.

4.1.4. Кортеж, отношение

Кортеж, соответствующий данной схеме отношения, — это множество пар , которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения. «Значение» является допустимым значением домена данного атрибута (или типа данных, если понятие домена не поддерживается). Тем самым, степень или «арность» кортежа, т.е. число элементов в нем, совпадает с «арностью» соответствующей схемы отношения. Попросту говоря, кортеж — это набор именованных значений заданного типа.

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

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

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

Реляционная база данных — это набор отношений, имена которых совпадают с именами схем отношений в схеме БД.

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

4.2. Фундаментальные свойства отношений

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

4.2.1. Отсутствие кортежей-дубликатов

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

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

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

4.2.2. Отсутствие упорядоченности кортежей

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

4.2.3. Отсутствие упорядоченности атрибутов

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

4.2.4. Атомарность значений атрибутов

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

Можно сказать, что здесь мы имеем бинарное отношение, значениями атрибута ОТДЕЛЫ которого являются отношения. Заметим, что исходное отношение СОТРУДНИКИ является нормализованным вариантом отношения ОТДЕЛЫ:

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

Зачислить сотрудника Кузнецова (пропуск номер 3000, зарплата 115,000) в отдел номер 320 и

Зачислить сотрудника Кузнецова (пропуск номер 3000, зарплата 115,000) в отдел номер 310.

Если информация о сотрудниках представлена в виде отношения СОТРУДНИКИ, оба оператора будут выполняться одинаково (вставить кортеж в отношение СОТРУДНИКИ). Если же работать с ненормализованным отношением ОТДЕЛЫ, то первый оператор выразится в занесение кортежа, а второй — в добавление информации о Кузнецове в множественное значение атрибута ОТДЕЛ кортежа с первичным ключом 310.

4.3. Реляционная модель данных

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

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

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

4.3.1. Общая характеристика

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

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

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

4.3.2. Целостность сущности и ссылок

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

Второе требование называется требованием целостности по ссылкам и является несколько более сложным. Очевидно, что при соблюдении нормализованности отношений сложные сущности реального мира представляются в реляционной БД в виде нескольких кортежей нескольких отношений. Например, представим, что нам требуется представить в реляционной базе данных сущность ОТДЕЛ с атрибутами ОТД_НОМЕР (номер отдела), ОТД_КОЛ (количество сотрудников) и ОТД_СОТР (набор сотрудников отдела). Для каждого сотрудника нужно хранить СОТР_НОМЕР (номер сотрудника), СОТР_ИМЯ (имя сотрудника) и СОТР_ЗАРП (заработная плата сотрудника). Как мы вскоре увидим, при правильном проектировании соответствующей БД в ней появятся два отношения: ОТДЕЛЫ ( ОТД_НОМЕР, ОТД_КОЛ ) (первичный ключ — ОТД_НОМЕР) и СОТРУДНИКИ ( СОТР_НОМЕР, СОТР_ИМЯ, СОТР_ЗАРП, СОТР_ОТД_НОМ ) (первичный ключ — СОТР_НОМЕР).

Как видно, атрибут СОТР_ОТД_НОМ появляется в отношении СОТРУДНИКИ не потому, что номер отдела является собственным свойством сотрудника, а лишь для того, чтобы иметь возможность восстановить при необходимости полную сущность ОТДЕЛ. Значение атрибута СОТР_ОТД_НОМ в любом кортеже отношения СОТРУДНИКИ должно соответствовать значению атрибута ОТД_НОМ в некотором кортеже отношения ОТДЕЛЫ. Атрибут такого рода называется внешним ключом, поскольку его значения однозначно характеризуют сущности, представленные кортежами некоторого другого отношения (т.е. задают значения их первичного ключа). Говорят, что отношение, в котором определен внешний ключ, ссылается на соответствующее отношение, в котором такой же атрибут является первичным ключом.

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

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

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

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

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