Создание базы данных склада (стр. 2 из 3)

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

5.2. Таблицы

Вся информация базы данных хранится в виде таблиц, такая БД носит название реляционной БД.

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

1. Каждая таблица состоит из однотипных строк и имеет уникальное имя.

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

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

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

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

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

5.3. Логическая структура базы данных

Логическая структура базы данных определяет:

• таблицы и их имена, также называемые сущностями (entities);

• имена полей, также называемые атрибутами (attributes) каждой таблицы;

• характеристики полей, например уникальность их значения и допустимость значений NULL, а также тип данных, хранимых в поле;

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

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

5.4. Типы связей

Существует три типа связей между таблицами:

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

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

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

5.5. Нормализация базы данных

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

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

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

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

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

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

Таким образом, каждая нормальная форма является в некотором смысле более ограниченной, но и более желательной, чем предшествующая. Это связано с тем, что "(N+1)-я нормальная форма" не обладает некоторыми непривлекательными особенностями, свойственным "N-й нормальной форме". Общий смысл дополнительного условия, налагаемого на (N+1)-ю нормальную форму по отношению к N-й нормальной форме, состоит в исключении этих непривлекательных особенностей.

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

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

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

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

5.6. Таблицы базы данных после нормализации

Вот основные преимущества нормализации:

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

создается большее число кластерных индексов, поскольку таблиц стало больше;

индексы становятся более компактными;

меньшее число индексов в одной таблице позволяет быстрее выполнять обновления записей;

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

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

5.7. Денормализация

Сложные реляционные соединения, обычно присутствующие в нормализованной базе данных, могут понизить производительность. В качестве примера рассмотрим получение отчета из базы данных регистрации студентов, в котором перечислены аудитории, где читается тот или иной курс. При создании отчета Вам потребуется извлекать имя студента из таблицы Students, коды посещаемых студентом курсов (CourseID) — из таблицы Registrations, код читающего курс лектора (LecturerID) — из таблицы Courses и номер аудитории (Room), где читается курс, — из таблицы Lecturers.

По правилам нормализации, номер аудитории не должен являться значением поля таблицы Courses. В противном случае возможна ситуация, когда данные не будут согласованными. Тем не менее здесь допустимо добавить поле Room в таблицу Courses, чтобы не обращаться к таблице Lecturers для поиска номера аудитории.

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