Будь умным!


У вас вопросы?
У нас ответы:) SamZan.net

Концептуальное проектирование 2

Работа добавлена на сайт samzan.net: 2016-03-30

Поможем написать учебную работу

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

Предоплата всего

от 25%

Подписываем

договор

Выберите тип работы:

Скидка 25% при заказе до 19.5.2024

Основные этапы проектирования баз данных

1. Концептуальное проектирование

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

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

ER – модель сущность-связь. Выбор целевой СУДБ между К(1) и Л(2).

Модель сущность-связь ER

Тип сущности – группа объектов с одинаковыми свойствами, которая рассматривается в конкретной предметной области как имеющая независимое существование.

Тип сущности может быть объектом с физическим (реальным) существованием или объектом с концептуальным (абстрактным) существованием. Пример типа сущности – студент, дисциплина, продажа, аттестация т.д.

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

UML - унифицированный язык моделирования.

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

Студент

 

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

Экземпляр связи – однозначно-идентифицируемая ассоциация, которая включает по одному экземпляру сущности из каждого участвующего в связи типа сущности.

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

Характеристики типов связи:

Степень типа связи – количество типов сущностей, которые охвачены данной связью. На практике чаще всего встречаются связи со степенью 2, то есть двухсторонние.

Для описания связей со степенью больше 2 принято применять термин сложная связь. Наиболее распространенные – трехсторонние.

Для обозначения связей со степенью большей 2 применяются ромбы. Имя связи записывается внутри ромба.

Рекурсивная связь – связь, в которой одни и те же сущности участвуют несколько раз в разных ролях. (Односторонние)

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

Атрибут – свойство типа сущности или типа связи

Домен атрибута – набор допустимых значений одного или нескольких атрибутов

__________________

| Студент                    |

__________________

| ФИО                          |

| Номер зач. книжки|

| ИНН                         |

----------------------------

Простой атрибут – атрибут, состоящий из одного компонента с независимым существованием

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

Составной атрибут – АДРЕС включает в себя (регион, район, город, улица)

Однозначный атрибут – атрибут, который содержит одно значение  для каждого экземпляра сущности определенного типа

Многозначный атрибут – атрибут, который содержит несколько значений для каждого экземпляра сущности определенного типа

Многозначный атрибут – номер телефона

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

Дата Рождения – однозначный просто атрибут.

Возраст – производный атрибут от атрибута Дата Рождения

Сущность Группа –> производный атрибут Кол-во Студентов

Тип сущности – класс

Настройка Параметры отображения фигуры – Общие параметры ИМЯ, скрыть ОПЕРАЦИИ

Ключ

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

Потенциальный ключ не может содержать значение NULL

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

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

Составной ключ – потенциальный ключ, который состоит из 2 или нескольких атрибутов

AK – альтернативный ключ

PK – потенциальный ключ

PPK – часть потенциального ключа

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

Сущность слабого типа – тип сущности, существование которого зависит от какого-то другого типа сущности.

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

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

Структурные ограничения

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

Кратность сложной связи – количество (заданное как одно значение или как диапазон значений) экземпляров сущности определённого типа в n-ой связи определяемая после фиксации остальных n-1 значений.

Ограничение кратности фактически состоит из двух отдельных ограничений:

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

Наиболее распространённая связь 1:* (один ко многим). Также есть 1:1, *:*

Группа 1-* студент

Группа 1:1 староста

Расширенная модель СУЩНОСТЬ-СВЯЗЬ (EER)

ERR - ER модель, оснащенная дополнительными семантическими концепциями

Уточнение/обобщение

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

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

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

Подкласс – различимая вспомогательная группировка экземпляров типа сущности

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

Каждый элемент подкласса является также элементом суперкласса, иными словами сущность, которая относится к подклассу, является той же сущностью, которая относится и к суперклассу, но выполняет в суперклассе и подклассе разные роли. Связь между суперклассом и подклассом является связью один к одному 1:1 и называется связью суперкласс-подкласс.

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

Обобщение – процесс стирания различий между элементами сущности путем выявления их общих особенностей (восходящий подход)

Синоним связи – является (проверка)

Контрагент – его подклассы (физические лица) + (юридические лица)

Ограничение степени участия – определяет должен ли быть отнесен к какому-то подклассу каждый элемент суперкласса (связь может быть обязательной и необязательной)

Ограничение не пересечения – описывает связь между элементами подклассов, и указывает, может ли элемент суперкласса принадлежать только к одному или нескольким подклассам (пересекающиеся и непересекающиеся)

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

Реляционная модель

Сама реляционная модель была предложена в 70 году. (Кодд)

Особенность реляционной модели – потребность в запросах –> предпосылка сознания

Большинство БД – реляционные

Реляционные модели имеют математическую основу

Отношение – плоская таблица, состоящая из столбцов и строк

Атрибут – именованный столбец отношений

Домен – набор допустимых значений одного или нескольких атрибутов

Картеж – строка отношений

Свойства отношений:

  1.  Степень отношений – количество атрибутов, которое оно содержит
  2.  Кардинальность – количество картежей, которые содержатся в отношении

Реляционная БД – набор нормализованных отношений, которые различаются по именам

Свойства отношений:

  1.  Отношение имеет имя, которое отличается от имен всех других отношений в реляционной схеме
  2.  Каждая ячейка отношения содержит только одно элементарное неделимое значение
  3.  Каждый атрибут имеет уникальное имя
  4.  Значения атрибутов берутся из одного и того же домена
  5.  Каждый картеж является уникальным, то есть дубликатов картежей быть не может
  6.  Порядок следования атрибутов не имеет значения
  7.  Теоретически порядок следования картежей в отношении не имеет значения

Реляционные ключи

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

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

Основные свойства потенциального ключа:

  1.  Уникальность – в каждом картеже отношения значение ключа единственным образом идентифицирует данный картеж
  2.  Неприводимость – никакое допустимое подмножество потенциального ключа не обладает свойством уникальности

Первичный ключ – потенциальный ключ, который выбран для уникальной идентификации картежей внутри отношений

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

Реляционная целостность

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

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

Потенциальные ключи можно оставлять пустыми

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

Корпоративные ограничения целостности (бизнес правила) – дополнительные правила поддержки целостности данных

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

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

С декомпозицией крупного отношений на более мелкие связаны 2 важных свойства:

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

Функциональная зависимость – описывает связь между атрибутами отношений. Например если в отношении R, которое содержит атрибуты А и Б, атрибут Б функционально зависит от атрибута А, то каждое значение атрибута А связано только с одним значением атрибута Б. Причем атрибуты А и Б могут состоять из одного или нескольких атрибутов.

Детерминант функциональной зависимости – атрибут или группа атрибутов, расположенные на диаграмме функциональной зависимости слева от стрелки.

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

  1.  Определяют связь 1:1 между атрибутами, приведенными в левых и правых частей выражения зависимости.
  2.  Остаются справедливыми при любых условиях.
  3.  Являются не тривиальными

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

Говорят, что атрибут Б функционально полно  зависит от атрибута А, тогда и только тогда, когда в любой момент времени одному значению атрибута А соответствует только одно значение атрибута Б.

Ненормализованная форма – отношение, содержащее одну или несколько повторяющихся групп данных

Первая нормальная форма (1НФ) – отношения, в которых на пересечении каждой строки и каждого столбца содержится одно и только одно значение

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

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

Транзитивная зависимость – если для атрибутов А, Б и С некоторого отношения существуют зависимости вида А->Б и Б->С это означает что атрибут С транзитивно зависит от атрибута А через атрибута Б при условии, что атрибут А функционально не зависит ни от атрибута Б, ни от атрибута С.

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

Нормальная форма Бойса Кода – отношения находятся в НФБК тогда и только тогда, когда каждый его детерминант является потенциальным ключом.

Обобщенная методология

1.1 Создание локальной модели данных

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

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

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

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

1.2 Определение типов связи

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

В большинстве случаев связи являются двухсторонними.

Особое внимание стоит уделять проверки тому, были ли выделены все связи, явно или неявно присутствующие в спецификации к требованиям. То есть проверка на полноту.

1.3 Применение ЕР диаграмм для наглядного отображения сущностей и связей

Определение ограничений кратности

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

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

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

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

1.4 Определение атрибутов и сопоставление их с типами сущностей и связей

Выявление простых составных атрибутов, однозначных – многозначных атрибутов, и производных.

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

О каждом атрибуте в документацию помещаются следующие сведения:

  1.  Имя и описание
  2.  Тип данных и размерность значений
  3.  Характеристика псевдонима
  4.  Информация о том, является ли атрибут составным, и если это так, из каких атрибутов он состоит
  5.  Информация о том, является ли атрибут многозначным
  6.  Информация о том, является ли атрибут производным и если это так, какой метод используется для вычисления его значения
  7.  Значение по умолчанию
  8.  Допускаются ли пустые значения NULL

1.4 Определение доменных атрибутов

Домены должны содержать следующие данные:

  1.  Набор допустимых значений для атрибута
  2.  Сведения о размере и формате каждого из атрибутов

1.5 Определение атрибутов являющихся потенциальными первичными ключами\

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

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

1.6 Анализ необходимости применения расширенных понятий моделирования

(расширенная ER модель)

Уточнение-обобщение, агрегирование, композиция

1.7 Проверка модели на отсутствие избыточности

Повторное исследование связи 1:1 (исключение дубликатов сущности, удаление избыточных связей)

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

1.8 Проверка соответствия локальной концептуальной модели пользовательским транзакциям

Транзакция – действие, операция

1.9 Обсуждение локальных концептуальных моделей с конечными пользователями

2. Построение и проверка локальной, логической модели данных для каждого представления

  1.  Исключение особенностей несовместимых с реляционной моделью:

- Удаление связей многие ко многим *:*

- Удаление сложных связей

- Удаление многозначных атрибутов

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

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

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

Сильные типы сущности:

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

В случае составных атрибутов в отношения включаются только составляющие их простые атрибуты

Слабые типы сущности:

Для каждой слабой сущности создается отношение, включающее все простые атрибуты этой сущности

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

Двухсторонние связи типа 1:*

Для каждой двухсторонней связи 1:* сущность, находящаяся на стороне связи 1, определяются как родительская, а сущность на стороне связи * как дочерняя.

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

Двухсторонние связи типа 1:1

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

Новая лекция

Связи типа суперкласс-подкласс

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

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

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

  1.  Одно отношение с одним или несколькими определителями, позволяющими указать тип каждой записи.

Суперкласс – Контрагенты

Подклассы – Юридические лица – Физические лица

Создается одно отношение, которое включает в себя все атрибуты

  1.  Два отношения – одно для суперкласса, другое – для всех подклассов (с одним или несколькими определителями)

Создается 2 отношения, связь 1:1

  1.  Несколько отношений, по одному отношения для каждого сочетания суперкласс подкласс

  1.  Несколько отношений, одно для суперкласса, другие по одному для каждого подкласса

После завершения этапа 2.2 необходимо формально описать состав отношений на языке определения базы данных

Customer (IdCust, FName, LName, IdCity)

PK – IdCust

FK – IdCity, ссылается на City (IdCity)

On Delete – No Action

On Update – Cascade

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

  1.  Проверка отношений с помощью правил нормализации

Проверка логической модели данных, по крайней мере, на требование НФБК

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

  1.  Определение ограничения целостности

Можно выделить 5 типов ограничений целостности данных:

  1.  Обязательные данные
  2.  Доменная целостность
  3.  Сущностная целостность
  4.  Ссылочная целостность
  5.  Ограничения предметной области (бизнес-правила)

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

Стратегии:

  1.  No Check – нет ограничения
  2.  No Action – нельзя обновлять, если есть подчиненные
  3.  Set Default
  4.  Set Null
  5.  Cascade

Новая лекция

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

  1.  Создание и проверка глобальной логической модели данных

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

3.1 создание глобальной модели

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

- проблема синонимов и омонимов

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

2. анализ (пересмотр) имен и содержимого связей внешних ключей

- те же проблемы

3. слияние (объединение) сущностей/связей из отдельных локальных моделей данных

4. Включение (без слияния) сущностей/связей уникальных для каждой локальной модели данных

5. слияние связей внешних ключей из локальных моделей данных

6. включение (без слияния) связей внешних ключей уникальных для каждой локальной модели данных

7. проверка наличия недостающих сущностей отношений и связей внешних ключей

8. проверка внешних ключей

На этом этапе могут быть объединены сущности/отношения и связи, внешние ключи. Изменены первичные ключи и выявлены новые связи. Следует проверить, что внешние ключи в дочерних отношениях все еще остаются правильными и в случае необходимости внести соответствующие изменения.

Проверка ограничений целостности. Составление глобальной ER диаграммы / реляционной схемы.

Обновление документации.

  1.  Проверка глобальной логической модели данных

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

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

  1.  Обсуждение глобальной логической модели данных

  1.  Перенос глобальной логической модели данных в среду целевой СУБД
  2.  проектирование базовых отношений (таблиц)

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

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

Сущностная целостность

Доменная целостность

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

Бизнес-правила

PK

Тип данных

FK

Триггеры

Unique

Default

Декларативная ссылочная целостность

Хранимые процедуры

Identity (счетчик)

FK

Триггеры

Транзакции

Guid

Check (ограничение проверки)

Хранимые процедуры

Null – not null

Триггер

  1.  Проектирование физического представления БД

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

  1.  анализ транзакций

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

  1.  выбор файловой структуры

определение наиболее эффективной файловой структуры для каждого базового отношения

  1.  выбор индекса

определение того, будет ли добавление индексов способствовать повышению производительности системы

  1.  определение требований к дисковому пространству

Способы учета с привязкой ко времени в реляционных БД

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

Основные способы организации учета во времени:

  1.  Хранение даты изменения. К имеющемуся ключу (идентификатор объекта) добавляется еще одно поле «дата изменения объекта».  Это поле имеет постой физический смысл – обозначение момента, в который было изменено состояние объекта. Например, цена товара. Промежуток между этой датой и самой ближней к ней новой и будет определять период актуальности состояния. Моделировать открытый интервал очень просто, он отсчитывается от максимальной даты в таблице и уходит в бесконечное будущее. Если объект некоторое время был недействительным, то такую семантику придется отражать использованием пустых значений полей (null) либо специальным полем-флагом. Из описания сразу виден недостаток этого способа – чтобы определить период (актуальность) необходимо просматривать и другие строки таблицы. Это ведет к утяжелению запросов, в которых придется делать соединение таблица на саму себя. Преимущества – отсутствие избыточности, быстрая вставка новых записей. Недостатки – относительно тяжелые соединяющиеся на себя вложенные запросы и null для атрибутов или дополнительное поле-флаг при моделировании пустых периодов. Метод хранения даты состояния можно рекомендовать в следующих случаях: при интенсивной вставки записей и при отсутствии частых массивных запросов по периодам.
  2.  Хранение интервала. Чтобы избежать вложенных соединяющихся на себя запросов, можно хранить интервал целиком. Поле «дата изменения», таким образом, становится полем «начало интервала», оно остается в составе ключа в предположении, что интервалы не пересекаются. Также нужно добавить в таблицу второе поле «окончание интервала». Для проверки непротиворечивости границ интервалов необходимо создать в таблице триггер, что, несомненно, отразиться на скорости вставки новых записей и модификации существующих. Такая структура также вызывает определенные осложнения для моделирования открытых интервалов. Преимущества – простота и эффективность запросов. Недостатки – необходимость дополнительного поля для хранения даты окончания интервала + накладные расходы для поддержания непротиворечивости + меньшая скорость вставки + сложность моделирования открытых периодов. Метод хранения интервалов можно рекомендовать в случае интенсивных и массивных запросов поиска, при невысоких требованиях к скорости вставки и допустимом использовании процедурного решения (триггеров) конкретной СУБД.
  3.  Хранение номера периода (интервала). Данные метод включает достоинства и недостатки двух предыдущих. Он наиболее уместен тогда, когда одни и те же интервалы многократно используются для одних и тех же сущностей. Наиболее характерный пример его применения - бухгалтерские, налоговые задачи с их понятиями учетных периодов. Следует отметить, что запросы получения данных последнего периода или выполнение нескольких запросов поиска по одному периоду эффективно оптимизируются. В первом случае нужен простой запрос, определяющий максимальный период по ключу без дополнительных фильтров, во втором значения номера периода предварительно запоминается в локальной переменной, после чего выполняется пакет запросов, тем самым снижается сложность  моделирования открытых периодов. Например, если учет ведется только постфактум, актуальным считается период с максимальным номером, для нахождение которого вообще не требуется поиск по датам начала и конца. Преимущества – меньшая избыточность по сравнение со вторым способом, за счет повторного использования интервалов, относительная простота запросов, разнесение логики хранения периодов и самих объектов по разным таблицам. Недостатки – более сложная структура, накладные расходы на поддержание непротиворечивости, меньшая скорость вставки. Метод хранения номеров периодов рекомендуется можно рекомендовать для решения задач бухгалтерского и управленческого учета. Выбор оптимального варианта будет лежать в плоскостях простота – избыточность и скорость вставки – скорость извлечения.

Create – создать

Alter – обновить




1. Антарес с 2006 года является надежным поставщиком светлых и темных нефтепродуктов
2. пространственная сфера распространения прямого воздействия предпринимателя
3. Тема- Тревожные расстройства Выполнила- студентка 2 курса 204 группыЯкушина ЮлияПроверил-
4.  адвокат по гражданским делам Настоящий Закон регулирует отношения возникающие между потребителями и из
5. Кредитный риск и способы его снижения
6. Хатынь трагедия и память
7. территориальное деление которой предусматривает определенную степень передачи прав на реализацию политики
8. по теме Методы и формы работы социального педагога с неполной семьёй
9. Алматинский универитет энергетики и связи Теплоэнергетический факультет Кафедра физики
10. Тарифная система оплаты труда в РБ.html
11. Характеристика способов формирования мировоззрения подростков в учебно-воспитательном процессе.html
12.  Примерные вопросы для зачета 1
13. і 50 бобові 50 злакові
14. Черного континента
15. РЕФЕРАТ дисертації на здобуття наукового ступеня кандидата історичних наук
16.  20г. БИЗНЕСПЛАН по инвестированию в создание инжиниринговой компани
17.  РЫНОК АКЦИЙ ВЕЛИКОБРИТАНИИ [2
18. РЕФЕРАТ дисертації на здобуття наукового ступеня кандидата історичних наук Київ ~ 2006
19. Обзор источников римского права
20. Использование веб-квест технологии в обучении иностранным языкам