Концептуальная схема (диаграмма Питера Чена) для процесса приема и исполнения заказа
3.2 Содержание раздела «Построение логической модели реляционной бд» Логическое проектирование базы
На следующем этапе выполняется построение логической структуры (схемы) данных. Логическая схема получается преобразованием концептуальной схемы в логическую схему и далее в структуру данных, поддерживаемую выбранной СУБД.
Рассмотрим процесс построения структуры БД применительно к наиболее распространенной реляционной модели данных.
В процессе разработки реляционной структуры данных студент должен показать знания:
методики проектирования базы данных на основе последовательного построения информационной модели;
принципов нормализации данных.
В основу проектирования БД должны быть положены представления конечных пользователей конкретной организации — концептуальные требования к системе. При рассмотрении требований конечных пользователей необходимо принимать во внимание следующее, база данных должна:
удовлетворять актуальным информационным потребностям организации. Получаемая информация должна по структуре и содержанию соответствовать решаемым задачам;
обеспечивать получение требуемых данных за приемлемое время, то есть отвечать заданным требованиям производительности;
удовлетворять выявленным и вновь возникающим требованиям конечных пользователей;
легко расширяться при реорганизации и расширении предметной области;
легко изменяться при изменении программной и аппаратной среды.
А также:
загруженные в базу данных корректные данные должны оставаться корректными;
данные до включения в базу данных должны проверяться на достоверность;
доступ к данным, размещаемым в базе данных, должны иметь только лица с соответствующими полномочиями.
Основой для построения логической структуры данных является концептуальная схема.
Общий подход преобразования концептуальной схемы в логическую состоит в том, что каждую сущность, являющуюся представителем множества однотипных объектов, задают схемой отдельного отношения (нормализованной таблицы). При этом атрибуты сущности образуют столбцы таблицы, а реальные объекты (экземпляры сущности) будут представлены кортежами отношения. Первичный ключ сущности образует исходный первичный ключ таблицы, который в дальнейшем может быть изменен.
При таком подходе определения структуры таблицы возможны проблемы с множественными атрибутами. Если количество значений атрибута у разных экземпляров сущности изменяется мало и при этом атрибут не используется для поиска сущностей, то оправдано его представление одним столбцом строкового типа. Так, например, можно хранить номера телефонов для контактов с заказчиком. В том случае, если число значений атрибута у разных объектов колеблется существенно или атрибут используется в качестве условия поиска данных, то, следуя требованию нормализации отношения, такой атрибут необходимо вынести в отдельную вспомогательную таблицу. Для поддержания соответствия между экземпляром сущности в главной таблице и его атрибутами во вспомогательной таблице создается столбец внешнего ключа, в который заносятся значения первичного ключа сущности из главной таблицы. Таким образом, вынесенные в отдельную таблицу атрибуты поддерживают связь «многие к одному» через соответствие внешнего и первичного ключей (FK – PK).
Причем наличие экземпляра сущности – записи в главной таблице является обязательным для связанных записей ее атрибутов. Поэтому создаваемая связь должна обладать свойством ссылочной целостности и не допускать появления записей с атрибутом у несуществующей записи сущности. Создание отдельной таблицы для множественного атрибута решает проблему их хранения, но при этом несколько усложняет экранные формы для управления данными в приложениях. В формах для ввода и редактирования экземпляра сущности необходимо предусмотреть элементы управления для добавления, удаления, корректировки атрибута и отображения всех значений атрибута у экземпляра сущности.
Еще одним приемом, улучшающим структуру БД, является создание справочников и классификаторов данных. Для столбцов, значения которых принадлежат фиксированному ограниченному множеству или носят условно-постоянный характер, создаются справочники и классификаторы данных в виде отдельных таблиц. Например, цвет рам в компании по установке окон и дверей выбирается из фиксированного и ограниченного множества. Создание таблицы-справочника возможных цветов, состоящего из столбцов кода и названия цвета, позволит сжать информацию в базе, заменив во всех таблицах наименование цвета его коротким кодом и исключить ошибки пользователя при вводе цвета, заменив ввод данных выбором из предлагаемого набора.
При создании базы можно использовать белорусские и общероссийские классификаторы. Их количество измеряется десятками. Например, общегосударственный классификатор видов экономической деятельности (ОКЭД) Республики Беларусь, единый правовой классификатор (ЕПК) Республики Беларусь. Перечень общероссийских классификаторов можно найти по ссылке http://goskomstat.karelia.ru/uslugi/klassif.php3
После создания справочника или выбора готового классификатора вносятся изменения в структуры информационных таблиц путем замены имен и доменов полей, вошедших в справочники, их кодами.
Так как главной задачей проектирования базы данных, является выбор оптимального количества таблиц для хранения данных, полей, которые должны войти в ту или иную таблицу, а также планирование отношений между таблицами, то эту и многие другие проблемы при проектировании базы данных можно решить с помощью анализа каждой таблицы на принадлежность к нормальным формам, а при необходимости выполнить ее нормализацию. При проектировании баз данных могут применяться различные подходы. Основная цель проектирования баз данных – это сокращение избыточности хранимых данных, а следовательно, экономия используемых ресурсов (оперативной и дисковой памяти), уменьшение затрат на обновление избыточных копий данных, а также снижение вероятности нарушений целостности данных. Реляционная база данных – это совокупность отношений, в которых хранится вся информация баз данных. Для пользователя такая база данных представляется набором двумерных таблиц, что облегчает понимание структуры данных и управление ими. Таблицы реляционной базы данных связаны между собой отношениями. Нормализация – это процесс приведения структур данных в состояние, обеспечивающее лучшие условия выборки, включения, изменения и удаления данных.
Нормализация отношений
Декомпозицию отношения преобразованием к третьей нормальной форме можно в несколько этапов.
Данные, представленные в виде двумерной таблицы, являются первой нормальной формой (1NF) реляционной модели данных.
Первый этап нормализации заключается в образовании двумерной таблицы, содержащей все необходимые атрибуты информационной модели, и в выделении ключевых атрибутов. Очевидно, что полученная весьма внушительная таблица будет содержать очень разнородную информацию. В этом случае будут наблюдаться аномалии включения, обновления и удаления данных, так как при выполнении этих действий нам придется уделить внимание данным (вводить или заботиться о том, чтобы они не были стерты), которые не имеют к текущим действиям никакого отношения.
На данном этапе проверяется наличие прямой и однозначной (функциональной) зависимости данных в каждом неключевом атрибуте от всех значений первичного ключа.
Если часть неключевых атрибутов отношения зависит не от всех атрибутов первичного ключа, то эти атрибуты и определяющие их атрибуты первичного ключа выносятся из структуры данного отношения в новое отношение.
Если все возможные ключи отношения содержат по одному атрибуту, то это отношение задано во второй нормальной форме, так как в этом случае все атрибуты, не являющиеся первичными, полностью зависят от возможных ключей.
Если ключи состоят более чем из одного атрибута, отношение, заданное в первой нормальной форме, может не быть отношением во второй нормальной форме.
Приведение отношений ко второй нормальной форме заключается в обеспечении полной функциональной зависимости всех атрибутов от ключа за счет разбиения таблицы на несколько таблиц, в которых все имеющиеся атрибуты будут иметь полную функциональную зависимость от ключа этой таблицы.
В процессе приведения модели ко второй нормальной форме в основном исключаются аномалии дублирования данных.
Отношение задано во второй нормальной форме (2NF), если оно является отношением в первой нормальной форме и каждый атрибут, не являющийся первичным атрибутом в этом отношении, полностью зависит от любого возможного ключа этого отношения.
Если какое-то подмножество неключевых атрибутов функционально зависит от других неключевых атрибутов, и при этом транзитивно зависит от ключа таблицы, то определяющие и зависимые атрибуты образуют новое отношение. При этом зависимые атрибуты удаляются из структуры исходного отношения.
Отношение задано в третьей нормальной форме (3NF), если оно задано во второй нормальной форме и каждый атрибут этого отношения, не являющийся первичным, не транзитивно зависит от каждого возможного ключа этого отношения.
Транзитивная зависимость выявляет дублирование данных в одном отношении. Если А, В и С — три атрибута одного отношения и С зависит от В, а В от А, то говорят, что С транзитивно зависит от А, как это схематично показано на рисунке9 а).
Преобразование в третью нормальную форму происходит за счет разделения исходного отношения на два, как это показано на рисунке9 б).
