Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология
Образование Политология Производство Психология Стандартизация Технологии


Даталогическое проектирование



Выполняется переход от инфологической модели к даталогической (логическая модель).

Исходные данные:

Инфологическая модель, информация по выбранному типу или марке СУБД.

Критериями оценки СУБД являются:

- адекватность;

- полнота;

- адаптируемость;

- универсальность;

- сложность структуры БД;

- степень дублирования данных в БД;

- сложность последующей обработки;

- объём требуемой памяти;

- скорость обработки информации.

Логические модели подразделяются на:

При проектировании учитываются следующие ограничения:

─ ограничения, накладываемые моделью данных

─ ограничения, накладываемые конкретной СУБД

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

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

Основные отличия от инфологической модели:

─ могут быть введены искусственные идентификаторы, то есть изменится число атрибутов

─ могут быть изменены (устранены) вычисляемые атрибуты

─ устранение связи: многие ко многим

─ соединение и расщепление данных

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

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

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

Для перехода от ранее полученной инфологической модели «сущность-связь» к логической реляционной модели выполняются следующие шаги:

1) преобразование исходной инфологической модели (ИМ)

2) переход к логической модели

3) нормализация отношений

4) дополнительные действия

 

I. ПРЕОБРАЗОВАНИЕ ИСХОДНОЙ ИНФОЛОГИЧЕСКОЙ МОДЕЛИ (ИМ):

На этом шаге нужно получить инфологическую модель, сущности которой содержат только элементарные свойства (одновременно простые, единичные и безусловные) и связаны между собой связями 1: М (или, как частный случай, 1: 1).

При этом могут применяться следующие преобразования.

Преобразования сущностей

1. Преобразование составного объекта.

Вложенные сущности выносятся на уровень главной сущности объекта и соединяются с ней внешними связями.

 

 

 

2. Преобразование обобщенного объекта

Преобразование может быть выполнено в нескольких формах:

а) сущности категорий выносятся на уровень главной сущности объекта и соединяются с ней внешними связями. При этом общие данные и данные категорий хранятся отдельно.

б) сущности категорий объединяются с частями главной сущности с образованием набора независимых сущностей объектов;

Недостатки: отрицательно сказывается в случае необходимости работы с общими данными

 

 

в) все сущности объединяются в единую сущность

 

Недостатки: пустые места (заведомо не используется часть полей), усложнение обработки таблицы.

 

 

Всё это иллюстрируется следующим образом:

 

3. Преобразование ассоциации.

Ассоциация рассматривается как обычная сущность, что сводится к простой замене изображения ассоциации на изображение сущности

 

 

Преобразования свойств

1. Преобразование составного свойства

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

 

 

2. Преобразование множественного свойства

Множественное свойство выносится в новую сущность, связываемую с исходной сущностью связью 1: М

 

 

Другим возможным вариантом является введение вместо одного множественного свойства достаточного числа свойств для поединичного хранения данных (например, если нужно хранение данных по месяцам в течение года – ввести 12 свойств).

 

3. Преобразование условного свойства

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

 

 

3. Вычисляемые свойства - данные, которые не вводятся с клавиатуры, а рассчитываются. Их можно хранить (в БД это свойство оставляем). А можно не хранить, а каждый раз вычислять. (Если расчетные данные должны соответствовать исходным данным на момент расчета).

 

Преобразования связей

1. Преобразование связи 1: 1.

В зависимости от степени связанности сущностей, соединяемых связью, возможно применение следующих преобразований:

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

 

 

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

 

 

2. Преобразование связи М: М

Вводится дополнительная связующая сущность, разбивающая связь М: М на две связи 1: М

 

 

II. ПЕРЕХОД К ЛОГИЧЕСКОЙ МОДЕЛИ:

На этом шаге элементы инфологической модели отображаются в элементы реляционной модели. Выполняются два основные действия.

1. Отображение сущностей инфологической модели в реляционные отношения.

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

Графически отношение можно представить в виде

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

 

 

 

Полученное итоговое отношение можно также записать как:

Отношение(Атрибут1, Атрибут2, Атрибут3)

 

2. Реализация связей отношений

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

 

 

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

 

III. НОРМАЛИЗАЦИЯ ОТНОШЕНИЙ

Выполняются в случае необходимости для исключения избыточности данных.

IV. ДОПОЛНИТЕЛЬНЫЕ ДЕЙСТВИЯ

Выполняются для повышения эффективности использования данных.

1. Введение искусственных идентификаторов. Выполняется в следующих случаях:

- Если составной (длинный) идентификатор

- Если не уникальный ключ

- Если динамический идентификатор

- Если первичный ключ часто меняется

2. Слияние таблиц: совместно используемые таблицы сливаются путем соединения (денормализация).

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

4. Вертикальное разделение отношений.

─ если есть ограничение на число полей записи или на длину записи;

─ если длина строки очень большая – программа выборки данных работает медленно;

─ как косвенный элемент защиты.

5. Горизонтальное разделение отношений:

Используется в случаях:

─ Если необходимо какой-то элемент таблицы защитить от пользователя;

─ Используется для повышение быстродействия (например, данные по студентам в университете разбиты по факультетам).


8. Ограничения целостности, виды и реализация

Обеспечение целостности данных является важнейшей задачей при проектировании и эксплуатации систем обработки данных (СОД).

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

Целостность данных - неотъемлемое свойство базы данных, и ее обеспечение является важнейшей задачей проектирования БД. Це­лостность данных описывается набором специальных предложений, называемых ограничениями целостности. Ограничения целостнос­ти представляют собой утверждения о допустимых значениях отдель­ных информационных единиц и связях между ними. Эти ограничения определяются в большинстве случаев особенностями предметной области, хотя могут отражать и чисто информационные (лингвисти­ческие) характеристики.

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

Источниками происхождения ограничений являются:

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

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

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

Например, возраст сотрудника не может быть отрицательным, а дата приема его на работу меньше, чем дата его рождения;

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

Например, расход сырья за месяц должен совпадать с суммой ежедневных расходов в данном месяце;

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

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

 


Поделиться:



Популярное:

Последнее изменение этой страницы: 2017-03-03; Просмотров: 1576; Нарушение авторского права страницы


lektsia.com 2007 - 2024 год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! (0.046 с.)
Главная | Случайная страница | Обратная связь