Методология логического моделирования данных

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

КОНЦЕПТУАЛЬНАЯ, ЛОГИЧЕСКАЯ И ФИЗИЧЕСКАЯ МОДЕЛИ

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

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

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

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

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

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

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

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

Обеспечение непротиворечивости и целостности данных в базе

Для пользователей АИС важно, чтобы база данных отображала предметную область однозначно и непротиворечиво, т. е. чтобы она удовлетворяла условию целостности.

Выделяют два основных типа ограничений по условию целост­ности:

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

Пример 2.

Сотрудники отдела могут оказаться полными тезка­ми, родившимися в один и тот же день. Чтобы не нарушить условия целостности, добавляем в таблицу новый столбец — «№ пропуска», превращая ее в отношение (см. рис. 1.4). Таким образом, первое ог­раничение обеспечивается наличием в таблице — отношении пер­вичного ключа.

2. Внешний ключ не может быть указателем на несуществую­щую строку той таблицы, на которую он ссылается. Это ограниче­ние называется ограничением целостности по ссылкам.

Пример 3.

В столбце Название отдела таблицы «СОТРУДНИК» хранятся сведения о принадлежности сотрудников к отделу. Здесь Название отдела является внешним ключом для ссылки на таблицу «ОТДЕЛ». Для обеспечения ограни­чения целостности по ссылкам каждое Название отдела из таблицы «СОТРУДНИК» должно принадлежать конкретному отделу из таб­лицы «ОТДЕЛ».

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

Методология логического моделирования данных

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

1. Выявить и смоделировать сущности.

2. Выявить и смоделировать связи между сущностями.

3. Выявить и смоделировать атрибуты.

4. Указать уникальный идентификатор для каждой сущности.

5. Провести нормализацию.

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

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