Проектирование баз данных и работа с ними Веб-приложений. Введение в БД, SQL Server, ADO.NET

9.1.3. Основные понятия реляционных БД

9.1.3.1. Таблицы

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

Столбы таблицы имеют следующие свойства:

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

Строки таблицы имеют следующие свойства:

• строки таблицы не имеют определенного порядка;
• в таблице может содержаться любое количество строк (в том числе и ни одной);
• стандарт ANSI/ISO не накладывает ограничений на количество строк в таблице, и во многих СУБД размер таблиц ограничен лишь свободным дисковым пространством компьютера или весьма высок.

9.1.3.2. Первичные и внешние ключи

Первичный ключ (primary key, PK) – минимальный набор полей, уникально идентифицирующий запись в таблице [1]. В правильно построенной реляционной базе данных в каждой таблице есть один или несколько столбцов, значения в которых во всех строках разные [16] – этот столбец (столбцы) и называется первичным ключом таблицы.

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

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

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

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

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

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

На рис. 9.3 показана связь внешнего и первичного ключа.

увеличить изображение
Рис. 9.3. Внешний и первичный ключи

9.1.3.3. Индексирование

Одна из основных задач, возникающих при работе с базами данных, – это задача поиска [1]. При этом, поскольку информации в базе данных, как правило, содержится много, перед программистами встает задача не просто поиска, а эффективного поиска, т.е. поиска за сравнительно небольшое время и с достаточной точностью. Для этого (для оптимизации производительности запросов) производят индексирование некоторых полей таблицы. Использовать индексы полезно для быстрого поиска строк с указанным значением одного столбца. Без индекса чтение таблицы осуществляется по всей таблице, начиная с первой записи, пока не будут найдены соответствующие строки. Если же таблица содержит индекс по рассматриваемым столбцам, то база данных может быстро определ ить позицию для поиска в середине файла данных без просмотра всех данных. Это происходит потому, что база данных помещает проиндексированные поля ближе в памяти, так, чтобы можно было быстрее найти их значения. Для таблицы, содержа щей 1000 строк, это будет как минимум в 100 раз быстрее по сравнению с последовательным перебором всех записей.

9.1.3.4. Нормальные формы

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

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

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

Приведем определения нескольких нормальных форм.

9.1.3.4.1. Первая нормальная форма (1NF)

Для определения первой нормальной формы необходимо дать два определения [12]:

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

Теперь можно дать определение первой нормальной формы:

• Отношение находится в 1NF, если значения всех его атрибутов атомарны.

9.1.3.4.2. Вторая нормальная форма (2NF)

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

Теперь можно дать определение второй нормальной формы [12]:

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

9.1.3.4.3. Третья нормальная форма (3NF)

Для определения третьей нормальной формы необходимо ввести понятие транзитивной функциональной зависимости:

• Пусть X, Y, Z – три атрибута некоторого отношения. При этом X Y и Y Z, но обратное соответствие отсутствует, т.е. Z / Y и Y / X. Тогда Z транзитивно зависит от X.

Теперь можно дать определение третьей нормальной формы [12]:

• Отношение находится в 3 NF, если оно находится во 2 NF, и каждый неключевой атрибут нетранзитивно зависит от первичного ключа.

9.1.3.4.4. Нормальная форма Бойса-Кодда (BCNF)

Эта нормальная форма вводит дополнительное ограничение по сравнению с 3 NF [12]:

• Отношение находится в BCNF, если оно находится во 3 NF, и в ней отсутствуют зависимости атрибутов первичного ключа от неключевых атрибутов.

9.1.3.6. Транзакции

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

Транзакция – это неделимая, с точки зрения воздействия на СУБД, последовательность операций манипулирования данными [20]. Для пользователя транзакция выполняется по принципу "все или ничего", т.е. либо транзакция выполняется целиком и переводит базу данных из одного целостного состояния в другое целостное состояние, либо, если по каким-либо причинам, одно из действий транзакции невыполнимо или произошло какое-либо нарушение работы системы, база данных возвращается в исходное состояние, которое было до начала транзакции (происходит откат транзакции ).

Транзакция обладает четырьмя важными свойствами, известными как свойства АСИД ( ACID ) [20, 21]:

• Атомарность (Atomicity). Транзакция выполняется как атомарная операция – либо выполняется вся транзакция целиком, либо она целиком не выполняется.
• Согласованность (Consistency). Транзакция переводит базу данных из одного согласованного (целостного) состояния в другое согласованное (целостное) состояние.
• Изоляция (Isolation). Транзакции разных пользователей не должны мешать друг другу (например, как если бы они выполнялись строго по очереди).
• Долговечность (Durability).Если транзакция выполнена, то результаты ее работы должны сохраниться в базе данных, даже если в следующий момент произойдет сбой системы.

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

• подана команда COMMIT WORK (зафиксировать транзакцию );
• подана команда ROLLBACK WORK (откатить транзакцию );
• произошло отсоединение пользователя от СУБД;
• произошел сбой системы.

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

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

9.1.4. Проектирование баз данных

Проектирование баз данных – процесс решения класса задач, связанных с созданием баз данных [22].

При выполнении данного процесса решаются следующие основные задачи [22, 23]:

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

Опишем основные этапы проектирования баз данных [22, 23, 24]:

• Концептуальное (инфологическое) проектирование – построение формализованной модели предметной области. Такая модель строится с использованием стандартных языковых средств, обычно графических, например, ER-диаграмм и не ориентируется на какую-либо конкретную СУБД. Основные элементы данной модели:
  • описание объектов предметной области и связей между ними;
  • описание информационных потребностей пользователей (описание основных запросов к БД);
  • описание документооборота. Описание документов, используемых как исходные данные для БД и документов, составляемых на основе БД;
  • описание алгоритмических зависимостей между данными;
  • описание ограничений целостности, т.е. требований к допустимым значениям данных и к связям между ними.
• Логическое (даталогическое) проектирование – отображение инфологической модели на модель данных, используемую в конкретной СУБД, например на реляционную модель данных. Для реляционных СУБД даталогическая модель – набор таблиц, обычно с указанием ключевых полей, связей между таблицами. Если инфологическая модель построена в виде ER-диаграмм (или других формализованных средств), то даталогическое проектирование представляет собой построение таблиц по определенным формализованным правилам, а также нормализацию этих таблиц.
• Физическое проектирование – реализация даталогической модели средствами конкретной СУБД, а также выбор решений, связанных с физической средой хранения данных: выбор методов управления дисковой памятью, методов доступа к данным, методов сжатия данных и т.д. – эти задачи решаются в основном средствами СУБД и скрыты от разработчика БД.