лекции. Конспект лекций профессионального модуля пм. 02 Разработка и администрирование баз данных междисциплинарного курса
Скачать 0.63 Mb.
|
2.3. Логическая модель данныхЛогическая модель данных – это модель данных логического уровня не привязанная ни к какой конкретной СУБД. Конкретные СУБД (Oracle, Firebird и т. д.) и такие специфические понятия баз данных как индексы, триггеры и т.д. будут рассмотрены в дальнейшем. Перед созданием логической модели данных необходимо изучить такие понятия логической модели данных, как: таблицы, столбцы; первичные, потенциальные и внешние ключи; нормальные формы и правила ссылочной целостности. Сначала ознакомимся с некоторыми основными терминами реляционных баз данных и моделирования логических структур данных (см. табл. 2). Таблица 2. Основные термины
Далее мы, используя в качестве исходных данных созданную концептуальную модель, преобразуем ее с помощью системы Open ModelSphere в завершенную логическую модель, а затем на этапе физического моделирования получим сценарий SQL, который можно использовать для создания объектов базы данных. Концептуальную модель данных можно преобразовать в логическую модель. Процесс преобразования изменяет связи многие-ко-многим (N:N), переопределяет атрибуты связей и учитывает зависимости ключей для идентифицирующих связей. Логическая модель данных для реляционной базы данных в Open ModelSphere называется реляционной моделью. При проектировании БД основной целью является выбор подходящей логической структуры для заданного массива данных, который требуется поместить в БД. Нужно решить, какие необходимы отношения и какой выбор атрибутов они должны включать. При этом такой процесс называется концептуальным проектированием БД (относится к внешнему уровню представления данных). Для определения подходящего набора отношений используется метод, называемый нормализацией. Нормализация представляет собой один из вариантов восходящего подхода к проектированию БД, который начинается с установления связей между атрибутами и заканчивается созданием необходимых отношений, определяющих логическую структуру БД. Нормализация – это метод создания набора отношения с заданными свойствами на основе требований к данным. Нормализация часто выполняется в виде последовательности тестов, выполняемых над некоторым отношением и необходимых для проверки его соответствия требованиям заданной нормальной формы. Основная цель нормализации заключается в минимизации избыточности данных и сокращений объема памяти, необходимого для физического хранения БД. При наличии избыточности возникает ряд проблем, осложняющих процесс функционирования СУБД. Служащий
Отделение
Альтернативное представление данных с помощью одного отношения Служащий - Отделение
Избыточные данные: сведения об отделении повторяются в кортежах, относящихся к каждому сотруднику. Проблемы, возникающие при наличии избыточности в отношениях, называются аномалиями обновления и подразделяются на аномалии вставки, удаления и модификации. Существуют два основных типа аномалий вставки. При вставке сведений о новых сотрудниках необходимо указывать и сведения об отделении, в которых эти сотрудники работают, которые должны соответствовать сведениям об этом же отделении в других строках отношения «Служащий-отделение». Первые отношения не могут пострадать от такого потенциального несоответствия, так как требуется вводить только номер отделения. Сведения об отделении, кроме того, заносятся однократно. Для вставки сведении о новом отделении, которое еще не имеет собственных сотрудников, потребуется присвоить значение NULL всем атрибутам, включая номер сотрудника StaffNo. Однако, этот атрибут является ключом и попытка ввода NULL нарушит целостность сущностей. Первые отношения позволяют избегать возникновения этой проблемы. При удалении из отношения строки с информации о последнем сотрудники некоторого отделения, сведения об этом отделении будут полностью удалены из БД. Первые два отношения позволяют избежать возникновения этой проблемы. При попытке изменения значения одного из атрибутов для некоторого отделения в отношении необходимо обновить соответствующие значения в строках для всех сотрудников этого отделения. Если такой модификации будут подвергнуты не все требуемые строки, то база данных будет содержать противоречивые сведения. Приведенные примеры иллюстрируют, что первые два отношения обладают более приемлемыми свойствами, чем отношение Staff-Branch. Нормализация и служит для получения правильно спроектированных отношений. Но вначале следует познакомиться с концепцией функциональной зависимости. Функциональная зависимость описывает связь между атрибутами и является одним из основных понятий нормализации. Если в отношении R, содержащем атрибуты А и В, атрибут В функционально зависит от атрибута А (что обозначается А В), то каждое значение атрибута А связано только с одним значением атрибута В. (При этом каждый из атрибутов А и В может состоять из одного или нескольких атрибутов). А В Детерминантом функциональной зависимости называется атрибут или группа атрибутов, расположенная на диаграмме функциональной зависимости слева от символа строки. Staff – может быть несколько сотрудников с одинаковыми должностями. Связь между атрибутами StaffNo и Position относится к типу 1:1, поскольку для каждого номера сотрудника имеется только одна должность. А связь между атрибутами Position и StaffNo имеет тип 1:N, так существует несколько номеров сотрудников, занимающих одну и ту же должность. S taffNo – детерминант функциональной зависимости StaffNo Pjsition. Для выявления ключей отношения Staff - Brunch необходимо найти атрибут (или группу атрибутов), который уникальным образом идентифицирует каждую строку этого отношения. Это атрибут StaffNo. В отношении Branch потенциальными ключами являются TelNo и Branch-No. В отношении Staff – атрибут StaffNo. Нормализация - это формальный метод анализа отношения на основе их первичного ключа (или потенциальных ключей) и существующих функциональных зависимостей. Он включает ряд правил, которые могут использоваться для проверки отдельных отношений таким образом, чтобы вся БД могла быть нормализована до желаемой степени нормализации. Если некоторое требование не удовлетворяется, то нарушающее данное требование отношение необходимо декомпозировать на несколько отношений, каждое из которых удовлетворяет всем требованиям нормализации. При работе с реляционной моделью данных важно понимать, что только удовлетворение требований 1НФ (каждый кортеж содержит ровно одно значение для каждого атрибута) обязательно для создания отношений приемлемого качества. Все остальные формы могут использоваться по желанию проектировщиков. Однако, для того чтобы избежать аномалий обновления нормализацию рекомендуется выполнять как минимум до 3НФ. Отношение, в котором на пересечении каждой строки и каждого столбца содержится только одно значение (отсутствуют повторяющиеся группы данных).
Ненормализованная форма. Повторяющейся группой называется группа, состоящая из атрибута таблицы, в котором возможно наличие нескольких значений для единственного значения ключевого атрибута таблицы. Существует два подхода исключения повторяющихся групп – выравнивание и декомпозиция.
Это выравнивание. Э
При использовании выравнивания дальнейшая нормализация все равно приводит к необходимости декомпозиции исходного отношения. Вторая нормальная форма основана на понятии полной функциональной зависимости. В некотором отношении атрибут В называется полностью функционально зависимым от атрибута А, если атрибут В функционально зависит от полного значения атрибута А и не зависит ни от какого подмножества полного значения атрибута А. S taffNo, SName BranchNo (м. б. связано только с одним значением) Эта зависимость не является полной, т. к. существует зависимость S taffNo BranchNo Отношение, которое находится в первой нормальной форме и каждый атрибут которого, не входящий в состав первичного ключа, характеризуется полной функциональной зависимостью от этого первичного ключа. Если в отношении между атрибутами существует частичная зависимость, то функционально – зависимые атрибуты удаляются из него и помещаются в новое отношение вместе с копией их детерминанта. FIRST Поставщик Рейтинг Город Поставки Количество
SECOND
SP
В отношении FIRST первичный ключ SNo, PNo. Однако, только атрибут QTY (количество) полностью зависит от этого составного ключа. Атрибуты STATUS, CITY частично зависят от указанного ключа, т.к. существуют зависимости S No Status S No City Поэтому отношение First декомпозировано на два отношения Second и SP. В отношении Second помещены атрибуты STATUS и CITY, имеющие частичную зависимость от ключа SNo, PNo вместе с их детерминантом SNo. Если в отношении нет составного первичного ключа и оно находится в 1НФ, то оно автоматически также находится и в 2НФ. Третья нормальная форма основана на понятии транзитивной зависимости. Т ранзитивная зависимость. Если для атрибутов А, В и С некоторого отношения существуют зависимости вида А В и В С, то говорят, что атрибут С транзитивно зависит от атрибута А через атрибут В ( при условии., что атрибут А функционально не зависит ни от атрибута В, ни от атрибута С). Рассмотрим отношение “Служащий – Отделение”. В нем существуют следующие функциональные зависимости: S taffNo(номер следующего) BranchNo (номер отделения) и B ranchNo BAddress (адрес отделения) S No City C ity Status S No Status через City В этом случае транзитивная зависимость StaffNo Address осуществляется через атрибут BranchNo. Данное утверждение справедливо, поскольку атрибут StaffNo не зависит функционально от атрибутов BranchNo и BAddress. Третья нормальная форма. Отношение, которое находится в первой и второй нормальных формах и не имеет находящих в первичный ключ атрибутов, которые находились бы в транзитивной функциональной зависимости от этого первичного ключа. Пусть в отношении FIRST существует функциональная зависимость CITY STATUS, то есть статус поставщика определяется его местонахождением, например, все поставщики из Лондона должны иметь статус 20. Тогда отношение SECOND не находится в третьей нормальной форме, так как в нем существует транзитивная зависимость S No STATUS через атрибут CITY. ( SNo CITY и CITY STATUS) Отношение, которое находиться в 2НФ, но не находится в 3НФ, всегда может быть преобразовано в эквивалентный набор (двух) отношений, находящихся в 3НФ. Для этого транзитивно зависимые атрибуты удаляются из такого отношения и помещаются в новое отношение вместе с копией их детерминанта. SC CS
Уровень нормализации отношения определяется связями атрибутов, а не их конкретными значениями в некоторое время. Нельзя с первого взгляда на набор данных некоторого отношения однозначно определить, находится ли оно, например, в 3НФ. Для этого необходимо представлять себе существующие между атрибутами зависимости. Таким образом, процесс нормализации заключается в декомпозиции исходного отношения посредством последовательного выполнения нескольких операции проекции реляционной алгебры. Полученные в результате декомпозиции отношения обеспечивают выполнение их соединения без потерь данных, поэтому данную процедуру называют беспроигрышной. Результаты декомпозиции можно обратить посредством операции (естественного) соединения. Для реляционной модели необходимо сгенерировать внешние ключи, а также необходимо определить физические имена для всех элементов модели. Физические имена – это имена объектов сущностей, атрибутов и т.д., приведенные к сокращенной форме для обеспечения надежности реализации. Это можно сделать вручную или с помощью генератора физических имен системы Open ModelSphere. Однако возможности автоматической генерации физических имен довольно ограничены, генерируемые таким образом имена далеки от совершенства. Поэтому воспользуемся ручным способом. Будем все атрибуты формировать из начальной буквы имени сущности и второго слова имени атрибута. Например, атрибут Books Pages надо представить в форме BPAGES. Рис.3 Логическая модель данных 2.4. Методы организации целостности данных Ограничения целостности данных представляют собой такие ограничения, которые вводятся с целью предотвратить помещение в базу противоречивых данных. Рассмотрение вопросов целостности данных является обязательным на внешнем уровне представления БД, Полное и точное представление пользователя можно получить только после определения ограничений, необходимых с точки зрения сохранения целостности данных. Существует пять типов ограничений целостности данных: обязательные данные; ограничения для атрибутов; целостность сущностей; ссылочная целостность; требования данного предприятия. Обязательные данные – некоторые атрибуты всегда должны содержать одно из допустимых значений. Эти атрибуты не могут иметь пустого значения. Так, каждый работник должен занимать ту или иную должность. Ограничения для атрибутов – каждый атрибут должен иметь набор допустимых значений. Набор допустимых значений атрибута носит название домен. Например, атрибут «Пол» имеет домен, состоящий из двух допустимых значений «М» и «Ж». Целостность сущностей – первичный ключ любой сущности не может содержать пустого значения. Сущность «отдел» должна содержать уникальное значение атрибута первичного ключа – «No отдела». Первичный ключ – это атрибут, который выбран для уникальной идентификации записей БД (в отношении). Ссылочная целостность – внешний ключ связывает каждую строку зависимого отношения с той строкой первичного отношения, которая содержит это же значение соответствующего первичного ключа. Понятие ссылочной целостности означает, что если внешний ключ содержит некоторое значение, то оно обязательно должно присутствовать в первичном ключе одной из строк родительского отношения. Каждый работник работает в одном из отделов предприятия. Требования данного предприятия – ограничения предприятия называются бизнес-правилами. Один работник не может участвовать в выполнении более трех проектов. |