Основные сведения о структуре данных

Проектирование баз данных SQL Server

Введение в системы управления базами данных (MS SQL Server).

Компоненты базы данных SQL Server

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

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

База данных SQL Server состоит из совокупности таблиц, в которых хранятся некоторые наборы структурированных данных. Таблица (сущность) состоит из набора строк (кортежей) и столбцов (атрибутов). Каждый столбец таблицы предназначен для хранения данных определенного типа (например, дат, имен, денежных сумм или чисел). Корректность данных таблицы обеспечивается различными управляющими объектами (ограничениями, правилами, триггерами, значениями по умолчанию и специализированными пользовательскими типами данных). Для таблиц могут быть созданы индексы (напоминающие предметные указатели книг), облегчающие поиск нужных строк. Можно добавить к таблице декларативные ограничения, обеспечивающие ссылочную целостность, а, следовательно, согласованность взаимосвязанных данных в различных таблицах. Предусмотрено также хранение в базах данных процедур, написанных на языке Transact-SQL (T-SQL) и предназначенных для выполнения определенных действий над данными базы; например, для сохранения представлений, обеспечивающих специализированный доступ к данным таблицы.

Так, для управления информацией в некоей компании мы можем построить базу данных под названием CompanyDB, в которой создается таблица Employees для хранения сведений обо всех работниках. Таблица состоит из столбцов EmpID, LastName, FirstName, Dept и Title. Чтобы в таблице не оказалось работников с одинаковым идентификатором (EmpID), а в столбце Dept были указаны только допустимые номера подразделений компании, необходимо добавить к таблице ограничения. Для ускорения поиска сведений об определенном работнике по его идентификатору или фамилии, следует определить индексы. Для каждого работника необходимо добавить к таблице данные в отдельной строке, поэтому для ввода данных о новых сотрудниках мы можем создать специализированную хранимую процедуру AddEmployee. Она выполняет операцию добавления строки в таблицу Employees. Если впоследствии мы захотим добавить итоговую информацию о работниках, сгруппированную по отделам, то надо определить представление под названием DeptEmps, которое формирует результат посредством объединения данных таблиц Departments и Employees.

Нормализация структуры базы данных

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

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

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

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

Создание базы данных с рациональной структурой

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

1. В таблице должен быть идентификатор

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

2. В таблице должны храниться сведения лишь об одном типе объектов

Если хранить в таблице слишком много информации, то эффективность и надежность хранения данных может снизиться.

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

В нормализованной базе данных сведения о книгах и издательствах будут храниться, по крайней мере, в двух таблицах: в одной сведения о книгах, а в другой — об издательствах.

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

3. В таблицах следует избегать столбцов, допускающих пустые значения

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

4. В таблице не должно быть повторяющихся значений или столбцов

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

Связи между сущностями

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

Существует три типа связей между таблицами: «один к одному», «один ко многим» и «многие ко многим». Тип связи зависит от того, как определены связанные столбцы.

Связь «один к одному»

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

Связь «один ко многим»

«Один ко многим» — наиболее распространенный тип связи. При этом типе связи одной строке таблицы А может соответстиовать множество строк таблицы В, но любой строке таблицы В может соответствовать только одна строка таблицы А. Например, в таблицах Publishers (Издательства) и Titles (Наименования книг) используется связь «один ко многим». Каждое издательство выпускает много книг, но любая книга выходит только в одном издательстве. Связь «один ко многим» возможна, если только один из связанных столбцов является первичным ключом или имеет ограничение, обеспечивающее уникальность.

Связь «многие ко многим»

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

Дата добавления: 2014-01-11