юироваиие баз данных SO Глава 3

Занятие 1 . Основные сведения о структуре баз данных

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

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

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

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

Изучив материал этог №тия, вы сможете:

рассказать о главных компонентах базы данных;

описать процесс нормализации и нормализовать таблицы, составляющие базу

данных;

определить связи между сущностями. Продолжительность занятия - около 30 минут.

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

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

данных таблицы обеспечивается различными управляющими объектами (ограничениями,

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

декларативные обеспечивающие ссылочную целостность, а следовательно,

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

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

Так, для управления информацией в компании построена база данных под названием MyCoDB (рис. 3-1).

В этой базе данных создается таблица Employees для хранения сведений обо всех работниках. Таблица состоит из столбцов EmpID. LastName, FirstName, Dept и I iil.; Чтобы

в таблице не оказалось работников с одинаковым идентификатором (EmpID), а в столбце Dept были указаны только допустимые номера подразделений компании, необходимо добавить к таблице ограничения. Дабы ускорить поиск сведений об определенном работнике по его идентификатору или фамилии, следует определить индексы. Для каждого работника необходимо добавить к таблице данные в отдельной строке, поэтому для ввода данных о новых сотрудниках создают иропаннузо хранимую процедуру AddEmp-loyee. Она выполняет операцию добавления строки в таблицу Employees. Если впоследствии вы захотите добавить итоговую информацию о работниках, сгруппированную по

отделам, то надо определить представление под названием DeptEmps, которое формирует

результат посредством объединения данных таблиц Departments и Employees.

столбцы

ТаЬлиш tmipluyees

Прадставяенгие DeplEmps

Рис. 3-1. База данные oDB, таблица Employees и представление DeptEmps

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

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

Разумная нормализация часто помогает поднять производительность. При наличии полезного индекса оптимизатор запросов SQL Server 2000 результативно выполняет выбор быстрых, эффективных соединений таблиц.

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

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

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

более эффективно, Тем не менее недостаточно нормализованные данные го-

раздо чаше, чем избыточно нормализованные. Разумнее всего нормализовать структуру, а затем выборочно сделать определенные таблицы денормализованными.

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

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

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

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

выходит далеко за рамки этой книги. Однако есть несколько правил, которым, в

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

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

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

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

В показанной на рис. 3-2 таблице Employees отсутствует столбец, который бы уникально идентифмиироьат строки таблицы. Обратите внимание, что имя David Mendlen появляется в таблице дважды. ГГоскол1.к. уникальный идентификатор в таблице отсутстпует. не существует простого способа отличить одну строку от другой. Если оба сотрудника занимают одинаковые должности в одном отделе, ситуация может оказаться еще хуже.

Таблица Employees

Рис. 3-2. Таблица без уникального идентификатора

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

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

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