Проектирование и реализация базы данных

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

5. Полное  информационное содержание базы  данных представляется в виде  явных значений данных и такой  метод представления является  единственным. В частности, не  существует каких-либо специальных  "связей" или указателей, соединяющих одну таблицу с другой. Так, связи между строкой с БЛ = 2 таблицы "Блюда" на рис. 4 и строкой с ПР = 7 таблицы продукты (для приготовления Харчо нужен Рис), представляется не с помощью указателей, а благодаря существованию в таблице "Состав" строки, в которой номер блюда равен 2, а номер продукта – 7.

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

Рисунок 4.База данных "Питание" . 
3.3   Манипулирование реляционными данными

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

    Предложив реляционную модель данных, Э.Ф.Кодд создал и инструмент для удобной работы с отношениями – реляционную алгебру. Каждая операция этой алгебры использует одну или несколько таблиц (отношений) в качестве ее операндов и продуцирует в результате новую таблицу, т.е. позволяет "разрезать" или "склеивать" таблицы (рис. 5).

    

    Рисунок 5. Некоторые операции реляционной алгебры

    Созданы языки манипулирования данными, позволяющие реализовать все операции реляционной алгебры и практически любые их сочетания. Среди них наиболее распространены SQL (Structured Query Language – структуризованный язык запросов) и QBE (Quere-By-Example – запросы по образцу) . Оба относятся к языкам очень высокого уровня, с помощью которых пользователь указывает, какие данные необходимо получить, не уточняя процедуру их получения.

Глава 4. Проектирование и реализация базы данных.

4.1 Проектирование концептуальной модели базы данных.

          Концептуальная модель базы данных строилась по методу «Сущность-связь», который заключается в следующем:

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

представляем  каждую связь вида "M - M" или "1 - M" и т.д. между сущностями, как таблицу;

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

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

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

Процесс построения концептуальной модели базы данных "Отдел кадров фирмы" изображен  на рис. 1.

 

Рисунок 1 - Модель «Сущность-связь» базы данных «Отдел кадров фирмы»

В результате получаем:

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

Строки  имеют фиксированное число полей  и значений, т.е. значения в ячейках атомарные.

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

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

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

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

4.2 Проектирование логической модели базы данных.

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

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

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

-   Исключить дублирование информации  в таблицах.

-  Обеспечить возможность изменений в структуре таблиц.

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

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

Ненормализованные данные

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

Первая  нормальная форма

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

Вторая  нормальная форма

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

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

Третья  нормальная форма

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

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

Четвёртая нормальна форма

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

Пятая нормальная форма  и комбинированные  элементы 

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

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