Главная страница
Навигация по странице:

  • Термин Определение 1 2

  • 2.4. Методы организации целостности данных

  • 1. Основные положения теории баз данных 4 Основные понятия и определения теории баз данных 4


    Скачать 0.63 Mb.
    Название1. Основные положения теории баз данных 4 Основные понятия и определения теории баз данных 4
    Дата10.10.2022
    Размер0.63 Mb.
    Формат файлаdoc
    Имя файлаkurs_lekciy_trbd(1).doc
    ТипЛитература
    #724954
    страница3 из 6
    1   2   3   4   5   6

    2.3. Логическая модель данных



    Логическая модель данных – это модель данных логического уровня не привязанная ни к какой конкретной СУБД.

    Конкретные СУБД (Oracle, Firebird и т. д.) и такие специфические понятия баз данных как индексы, триггеры и т.д. будут рассмотрены в дальнейшем.

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

    Сначала ознакомимся с некоторыми основными терминами реляционных баз данных и моделирования логических структур данных (см. табл. 2).

    Таблица 2. Основные термины

    Термин

    Определение

    1

    2

    Таблица (Table)

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

    Строка (row)

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

    Столбец (column)

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

    Первичный ключ (primary key)

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

    Внешний ключ (foreign key)

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

    Ограничение (constraint)

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

    Индекс (index)

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


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

    Концептуальную модель данных можно преобразовать в логическую модель. Процесс преобразования изменяет связи многие-ко-многим (N:N), переопределяет атрибуты связей и учитывает зависимости ключей для идентифицирующих связей. Логическая модель данных для реляционной базы данных в Open ModelSphere называется реляционной моделью.

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

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

    Нормализация – это метод создания набора отношения с заданными свойствами на основе требований к данным.

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

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

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

    Служащий

    StaffNo

    SName

    SAddress

    Position

    Salary

    Br.No

    SL21

    SG37

    SG14













    B5

    B3

    B7


    Отделение

    Br.No

    BAddress

    TellNo

    B5

    B3

    B7








    Альтернативное представление данных с помощью одного отношения

    Служащий - Отделение

    StaffNo

    SName

    SAddress

    Position

    Salary

    Br.No

    BAddress

    TellNo

    SL21

    SG37

    SG14

    CH2













    B5

    B3

    B7

    B5








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

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

    Существуют два основных типа аномалий вставки.

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

    • Для вставки сведении о новом отделении, которое еще не имеет собственных сотрудников, потребуется присвоить значение 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НФ.

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

    BranchNo

    StaffNo

    B5

    SL10, CF2



    Ненормализованная форма.

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

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

    BranchNo

    StaffNo

    B5

    B5

    SL10

    CF2


    Это выравнивание.

    Э

    BranchNo



    B5



    то декомпозиция.


    StaffNo

    BranchNo

    SL10

    CF2

    B5

    B5


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

    Вторая нормальная форма основана на понятии полной функциональной зависимости.

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

    S taffNo, SName BranchNo

    (м. б. связано только с одним значением)

    Эта зависимость не является полной, т. к. существует зависимость

    S taffNo BranchNo

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

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

    Поставщик Рейтинг Город Поставки Количество

    SNo

    STATUS

    CITY

    PNO

    QTY

    S1

    S1

    S1

    S2

    S3

    S4

    S4

    20

    20

    20

    10

    10

    20

    20

    London

    London

    London

    Paris

    Paris

    London

    London

    P1

    P2

    P3

    P1

    P2

    P2

    P4

    300

    200

    400

    300

    200

    200

    300


    SECOND


    SNo

    STATUS

    CITY

    S1

    S2

    S3

    S4


    20

    10

    10

    20


    London

    Paris

    Paris

    London



    SP

    SNo

    PNO

    QTY

    S1

    S1

    S1

    S2

    S3

    S4

    S4

    P1

    P2

    P3

    P1

    P2

    P2

    P4

    300

    200

    400

    300

    200

    200

    300


    В отношении 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


    SNo

    CITY

    S1

    S2

    S3

    S4


    London

    Paris

    Paris

    London


    CITY


    STATUS

    London

    Paris

    20

    10

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

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

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

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

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

    Рис.3 Логическая модель данных

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

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

    Существует пять типов ограничений целостности данных:

    • обязательные данные;

    • ограничения для атрибутов;

    • целостность сущностей;

    • ссылочная целостность;

    • требования данного предприятия.

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

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

    Целостность сущностей – первичный ключ любой сущности не может содержать пустого значения. Сущность «отдел» должна содержать уникальное значение атрибута первичного ключа – «No отдела». Первичный ключ – это атрибут, который выбран для уникальной идентификации записей БД (в отношении).

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

    Требования данного предприятия – ограничения предприятия называются бизнес-правилами. Один работник не может участвовать в выполнении более трех проектов.

    1   2   3   4   5   6


    написать администратору сайта