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

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

Подписываем
Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Основные этапы проектирования баз данных
1. Концептуальное проектирование
2. Логическое проектирование процесс создания модели используемой на предприятии информации на основе выбранной модели организации данных, но без учета целевой СУБД и других физических аспектов реализации.
3. Физическое проектирование процесс подготовки описания реализации БД на вторично запоминающих устройствах. На этом этапе рассматриваются основные отношения организации файлов и индексов, предназначенных для обеспечения эффективного доступа к данным, а также все связанные с этим ограничения целостности и средства защиты. Физическое проектирование неразрывно связано с конкретной СУБД. Основной целью физического проектирования БД является описание способов физической реализации логического проекта БД средствами выбранной целевой СУДБ. Между логическим и физическим проектированием существует постоянная обратная связь, так как решение, принимаемое на этапе физического проектирования с целью повышения производительности системы способны повлиять на структуру логической модели данных.
ER модель сущность-связь. Выбор целевой СУДБ между К(1) и Л(2).
Модель сущность-связь ER
Тип сущности группа объектов с одинаковыми свойствами, которая рассматривается в конкретной предметной области как имеющая независимое существование.
Тип сущности может быть объектом с физическим (реальным) существованием или объектом с концептуальным (абстрактным) существованием. Пример типа сущности студент, дисциплина, продажа, аттестация т.д.
Экземпляр сущности однозначно-идентифицируемый объект, который относится к сущности определенного типа. Тип и экземпляр сущности связаны как тип данных и переменная в языках программирования.
UML - унифицированный язык моделирования.
Каждый тип сущности изображается в виде прямоугольника с именем сущности внутри него. В качестве имени обычно применяется существительное в единственном числе.
Студент |
|
Тип связи набор осмысленных ассоциаций между сущностями разных типов. Каждому типу связи присваивается имя, которое должно описывать его назначение.
Экземпляр связи однозначно-идентифицируемая ассоциация, которая включает по одному экземпляру сущности из каждого участвующего в связи типа сущности.
Каждый тип связи изображается в виде линий, соединяющий соответствующие типы сущности и обозначенные именем этой связи (обычно глагол). На схеме должно быть показано направления действия каждой связи. Поскольку на обычно имеет смысл только одно направление этой связи.
Характеристики типов связи:
Степень типа связи количество типов сущностей, которые охвачены данной связью. На практике чаще всего встречаются связи со степенью 2, то есть двухсторонние.
Для описания связей со степенью больше 2 принято применять термин сложная связь. Наиболее распространенные трехсторонние.
Для обозначения связей со степенью большей 2 применяются ромбы. Имя связи записывается внутри ромба.
Рекурсивная связь связь, в которой одни и те же сущности участвуют несколько раз в разных ролях. (Односторонние)
Связям могут присваиваться ролевые имена для указания на значение каждой сущности, участвующие в данной связи. Ролевые имена имеют большое значение в рекурсивных связях, поскольку позволяют определить функции каждого участника. Ролевые имена могут также использоваться, когда 2 сущности связаны несколькими связями.
Атрибут свойство типа сущности или типа связи
Домен атрибута набор допустимых значений одного или нескольких атрибутов
__________________
| Студент |
__________________
| ФИО |
| Номер зач. книжки|
| ИНН |
----------------------------
Простой атрибут атрибут, состоящий из одного компонента с независимым существованием
Составной атрибут атрибут, состоящий из нескольких компонентов, каждый из которых характеризуется независимым существованием
Составной атрибут АДРЕС включает в себя (регион, район, город, улица)
Однозначный атрибут атрибут, который содержит одно значение для каждого экземпляра сущности определенного типа
Многозначный атрибут атрибут, который содержит несколько значений для каждого экземпляра сущности определенного типа
Многозначный атрибут номер телефона
Производный атрибут (вычисляемый) атрибут, который представляет значение производное от значения связанного с ним атрибута или некоторого множества атрибутов, принадлежащих некоторому типу сущности (необязательного данного)
Дата Рождения однозначный просто атрибут.
Возраст производный атрибут от атрибута Дата Рождения
Сущность Группа > производный атрибут Кол-во Студентов
Тип сущности класс
Настройка Параметры отображения фигуры Общие параметры ИМЯ, скрыть ОПЕРАЦИИ
Ключ
Потенциальный ключ атрибут или минимальный набор атрибутов, который однозначно идентифицируют каждый экземпляр типа сущности
Потенциальный ключ не может содержать значение NULL
Первичный ключ потенциальный ключ, который выбран для однозначной идентификации каждого экземпляра сущности определенного типа
Выбор первичного ключа сущности осуществляется с учетом суммарной длины атрибутов, минимального количество необходимых атрибутов в ключе, а также наличие гарантий уникальности его значений в текущий момент времени и в обозримом будущем
Составной ключ потенциальный ключ, который состоит из 2 или нескольких атрибутов
AK альтернативный ключ
PK потенциальный ключ
PPK часть потенциального ключа
Сущность сильного типа тип сущности, существование которого не зависит от какого-то другого типа сущности. Характерной особенностью сильного типа является то, что каждый экземпляр сущности может быть однозначно идентифицирован с помощью атрибутов первичного ключа сущности этого типа
Сущность слабого типа тип сущности, существование которого зависит от какого-то другого типа сущности.
Для отображения атрибутов, относящихся к типу связи, применяется такое же условное обозначение, как и для типа сущности. Тем не менее, чтобы подчеркнуть различие между сущностью и связью, линия, которая соединяет прямоугольник с атрибутами и саму связь, отображается как штриховая
Если на схеме появляется связь с одними или несколькими атрибутами, это может свидетельствовать о том, что за этой связью скрывается не выявленный тип сущности
Структурные ограничения
Кратность количество (заданное как одно значение или как диапазон значений) возможных экземпляров сущности некоторого типа, которые могут быть связаны с одним экземпляром сущности другого типа с помощью определенной связи.
Кратность сложной связи количество (заданное как одно значение или как диапазон значений) экземпляров сущности определённого типа в n-ой связи определяемая после фиксации остальных n-1 значений.
Ограничение кратности фактически состоит из двух отдельных ограничений:
Наиболее распространённая связь 1:* (один ко многим). Также есть 1:1, *:*
Группа 1-* студент
Группа 1:1 староста
Расширенная модель СУЩНОСТЬ-СВЯЗЬ (EER)
ERR - ER модель, оснащенная дополнительными семантическими концепциями
Уточнение/обобщение
Понятие уточнение/обобщение связано со специальными типами сущности, которые принято называть суперклассами и подклассами, а также с процессом наследования атрибута
Типы сущности могут быть объединены в иерархии, состоящие из суперклассов и подклассов
Суперкласс тип сущности, включающий одну или несколько различимых вспомогательных группировок ее экземпляра
Подкласс различимая вспомогательная группировка экземпляров типа сущности
Типы сущности, в которые включают различные подклассы, называются суперклассами.
Каждый элемент подкласса является также элементом суперкласса, иными словами сущность, которая относится к подклассу, является той же сущностью, которая относится и к суперклассу, но выполняет в суперклассе и подклассе разные роли. Связь между суперклассом и подклассом является связью один к одному 1:1 и называется связью суперкласс-подкласс.
Уточнение процесс подчеркивания различий между элементами сущности путем выявления их отличительных особенностей (нисходящий подход)
Обобщение процесс стирания различий между элементами сущности путем выявления их общих особенностей (восходящий подход)
Синоним связи является (проверка)
Контрагент его подклассы (физические лица) + (юридические лица)
Ограничение степени участия определяет должен ли быть отнесен к какому-то подклассу каждый элемент суперкласса (связь может быть обязательной и необязательной)
Ограничение не пересечения описывает связь между элементами подклассов, и указывает, может ли элемент суперкласса принадлежать только к одному или нескольким подклассам (пересекающиеся и непересекающиеся)
Композиция - Особая форма агрегирования, представляющая зависимость между сущностями, которая характеризуется полной принадлежностью и совпадением срока существований между целым и частью
Реляционная модель
Сама реляционная модель была предложена в 70 году. (Кодд)
Особенность реляционной модели потребность в запросах > предпосылка сознания
Большинство БД реляционные
Реляционные модели имеют математическую основу
Отношение плоская таблица, состоящая из столбцов и строк
Атрибут именованный столбец отношений
Домен набор допустимых значений одного или нескольких атрибутов
Картеж строка отношений
Свойства отношений:
Реляционная БД набор нормализованных отношений, которые различаются по именам
Свойства отношений:
Реляционные ключи
Супер ключ атрибут или множество атрибутов, который единственным образом идентифицирует картеж данного отношения
Потенциальный ключ супер ключ, который не содержит подмножества, так же являющиеся супер ключом данного отношения
Основные свойства потенциального ключа:
Первичный ключ потенциальный ключ, который выбран для уникальной идентификации картежей внутри отношений
Внешний ключ атрибут или множество атрибутов внутри отношения, которые соответствуют потенциальному ключу некоторого отношения, возможного того же самого
Реляционная целостность
Пустое значение указывает, что значение атрибута в настоящий момент неизвестно или неприемлемо для этого картежа
Сущностная целостность - в базовом отношении ни один атрибут первичного ключа не может содержать пустых значений (NULL)
Потенциальные ключи можно оставлять пустыми
Ссылочная целостность если в отношении существует внешний ключ, то значение внешнего ключа должно либо соответствовать значению потенциального ключа некоторого картежа в его базовом отношении, либо внешний ключ должен полностью состоять из значений NULL
Корпоративные ограничения целостности (бизнес правила) дополнительные правила поддержки целостности данных
Основная цель проектирования реляционной БД заключается в группирование атрибутов в отношения, таким образом, чтобы минимизировать избыточность данных и тем самым сократить объем памяти, необходимый для физического хранения отношений представленных в виде таблиц.
При работе с отношениями, содержащих избыточные данные, могут возникать проблемы, которые называются аномалиями обновлений, и подразделяются на аномалии вставки, удаления и модификации.
С декомпозицией крупного отношений на более мелкие связаны 2 важных свойства:
Функциональная зависимость описывает связь между атрибутами отношений. Например если в отношении R, которое содержит атрибуты А и Б, атрибут Б функционально зависит от атрибута А, то каждое значение атрибута А связано только с одним значением атрибута Б. Причем атрибуты А и Б могут состоять из одного или нескольких атрибутов.
Детерминант функциональной зависимости атрибут или группа атрибутов, расположенные на диаграмме функциональной зависимости слева от стрелки.
При выявлении функциональных зависимостей между атрибутами отношения, необходимо проводить четкое различие между значениями, хранящимися в атрибуте в определенный момент времени и множеством всех возможных значений, которые могут храниться в атрибуте в тот или иной момент времени. Иными словами функциональная зависимость является свойством реляционной схемы, то есть абстрактной структурой, а не свойством конкретного экземпляра схемы, то есть ее реализацией. В процессе нормализации должны учитываться следующие основные характеристики функциональных зависимостей:
Нормализация формальный метод анализа отношений на основе их первичного ключа (или потенциальных ключей) и существующих функциональных зависимостей.
Говорят, что атрибут Б функционально полно зависит от атрибута А, тогда и только тогда, когда в любой момент времени одному значению атрибута А соответствует только одно значение атрибута Б.
Ненормализованная форма отношение, содержащее одну или несколько повторяющихся групп данных
Первая нормальная форма (1НФ) отношения, в которых на пересечении каждой строки и каждого столбца содержится одно и только одно значение
Полная функциональная зависимость если А и Б атрибуты отношения, то атрибут Б находится в полной функциональной зависимости от атрибута А, если атрибут Б является функционально зависимым от А, но не зависит ни от одного собственного подмножества атрибута А.
2НФ отношения, которые находятся в 1НФ, и каждый атрибут которого, не входящий в состав первичного ключа, характеризуется полной функциональной зависимостью от этого первичного ключа.
Транзитивная зависимость если для атрибутов А, Б и С некоторого отношения существуют зависимости вида А->Б и Б->С это означает что атрибут С транзитивно зависит от атрибута А через атрибута Б при условии, что атрибут А функционально не зависит ни от атрибута Б, ни от атрибута С.
3НФ отношения, которые находятся в первой и во второй нормальных формах и не имеют атрибутов, не входящих в первичный ключ атрибутов, которые находились бы в транзитивной функциональной зависимости от этого первичного ключа отсутствие транзитивных зависимостей от первичного ключа.
Нормальная форма Бойса Кода отношения находятся в НФБК тогда и только тогда, когда каждый его детерминант является потенциальным ключом.
Обобщенная методология
1.1 Создание локальной модели данных
Создание локальной концептуальной модели данных предприятия на основе представления предметной области каждого отдельного типа производства.
В представлении, как правило, выделяется подсистема и информационная система, которая в свою очередь определяются на основе реальных бизнес процессов предприятия. В зависимости степени из перекрытия некоторые пользовательские представления объединяются, и создается общее представление, которому присваивается подходящее имя.
Определение типов сущности анализ спецификации требований, появление документирования типов сущности. После выделения каждый сущности ей следует присвоить определенное осмысленное имя, которое обязательно должно быть понятно пользователю. Выбранное имя и описание сущности помещается в словарь данных. Если это возможно следует установить и внести в документацию данные об ожидаемом количестве экземпляров каждой сущности.
Если сущность известна пользователю под разными именами, все дополнительные имена рекомендуется определить как синонимы или псевдонимы и также занести в словарь данных.
1.2 Определение типов связи
Определение важнейших типов связи существующих между сущностями. Проектировщиков интересуют только те связи, которые необходимо для удовлетворения требований проекта.
В большинстве случаев связи являются двухсторонними.
Особое внимание стоит уделять проверки тому, были ли выделены все связи, явно или неявно присутствующие в спецификации к требованиям. То есть проверка на полноту.
1.3 Применение ЕР диаграмм для наглядного отображения сущностей и связей
Определение ограничений кратности
После выявления необходимых связей требуется проверить, служит ли каждая связь в модели подлинным отображением зависимости реального мира. Кроме того следует убедиться в том, нет ли в модели не выявленных дефектов соединения: дефект типа разветвления и дефект типа разрыв.
Проверка того, участвует ли каждая сущность, по меньшей мере, в одной связи.
Дефект типа разветвления имеет место в том случае, когда модель отображает связь между типами сущности, но путь между отдельными сущностями этого типа определен не однозначно (несколько связей типа 1:* исходят из одной сущности).
Дефект типа разрыв появляется в том случае, когда в модели предполагается наличие связи между типами сущности, но не существует пути между отдельными сущностями этих типов. Существует одна сущность с минимальной кратностью = 0, которая обозначает необаятельное участие. Эти связи составляют часть пути, между взаимосвязанными сущностями.
1.4 Определение атрибутов и сопоставление их с типами сущностей и связей
Выявление простых составных атрибутов, однозначных многозначных атрибутов, и производных.
К каждому выявленному атрибуту следует присвоить осмысленное имя, понятное пользователю.
О каждом атрибуте в документацию помещаются следующие сведения:
1.4 Определение доменных атрибутов
Домены должны содержать следующие данные:
1.5 Определение атрибутов являющихся потенциальными первичными ключами\
Определение потенциального ключа для каждого типа сущности, если таковых несколько, следует выбрать один в качестве первичного.
Документирование сведений о первичных ключах для каждой сильной сущности.
1.6 Анализ необходимости применения расширенных понятий моделирования
(расширенная ER модель)
Уточнение-обобщение, агрегирование, композиция
1.7 Проверка модели на отсутствие избыточности
Повторное исследование связи 1:1 (исключение дубликатов сущности, удаление избыточных связей)
Избыточность представленная в ней информация может быть получена с помощью других связей
1.8 Проверка соответствия локальной концептуальной модели пользовательским транзакциям
Транзакция действие, операция
1.9 Обсуждение локальных концептуальных моделей с конечными пользователями
2. Построение и проверка локальной, логической модели данных для каждого представления
- Удаление связей многие ко многим *:*
- Удаление сложных связей
- Удаление многозначных атрибутов
Если в концептуальной модели данных присутствует сложная связь, необходимо выполнить ее декомпозицию для выявления промежуточных сущностей. Сложная связь заменяется необходимым количеством двухсторонних связей, со вновь выявленной сущностью.
(Документирования сведений об отношениях и атрибутах внешних ключей, а также о новых первичных и потенциальных ключах)
Сильные типы сущности:
Для каждой сильной сущности в модели данных создается отношение, включающее все простые атрибуты этой сущности
В случае составных атрибутов в отношения включаются только составляющие их простые атрибуты
Слабые типы сущности:
Для каждой слабой сущности создается отношение, включающее все простые атрибуты этой сущности
Первичный ключ слабой сущности частично или полностью зависит от ключа сущности владельца и поэтому выявление первичного ключа слабой сущности невозможно выполнить до тех пор, пока не завершено преобразование в отношения всех связей сущностей владельцев
Двухсторонние связи типа 1:*
Для каждой двухсторонней связи 1:* сущность, находящаяся на стороне связи 1, определяются как родительская, а сущность на стороне связи * как дочерняя.
Для обозначения этой связи копия атрибута первичного ключа родительской сущности передается в отношение соответствующее дочерней сущности для использования в качестве внешнего ключа. В дочернюю сущность передаются также все атрибуты связи
Двухсторонние связи типа 1:1
Новая лекция
Связи типа суперкласс-подкласс
Для каждой связи типа суперкласс-подкласс (уточнение-обобщение) сущность, соответствующая суперклассу, определяется как родительская. А сущность, соответствующая подклассу, как дочерняя. Имеется также возможность преобразовать подобную связь в одно или несколько отношений. Выбор наиболее подходящего способа преобразования зависит от многих факторов, таких как:
ограничение не пересечения и степени участия; от того, участвуют ли подклассы в разных связях; а также от количества сущностей участвующих в связи.
Определитель (дискриминатор) это атрибут, указывающий, какому конкретному подклассу относится картеж в отношении, соответствующий суперклассу.
Суперкласс Контрагенты
Подклассы Юридические лица Физические лица
Создается одно отношение, которое включает в себя все атрибуты
Создается 2 отношения, связь 1:1
После завершения этапа 2.2 необходимо формально описать состав отношений на языке определения базы данных
Customer (IdCust, FName, LName, IdCity)
PK IdCust
FK IdCity, ссылается на City (IdCity)
On Delete No Action
On Update Cascade
На данном этапе для каждого отношения определен полный набор атрибутов, поэтому появляется возможность определить все новые первичные и альтернативные ключи. Эту операцию особенно важно выполнить для слабых сущностей, собственный первичный ключ которых формируется путем передачи первичного ключа из родительской сущности или сущностей. Кроме того должен быть обновлен словарь данных, с учетом всех новых и альтернативных ключей, выявленных на данном этапе.
Проверка логической модели данных, по крайней мере, на требование НФБК
Можно выделить 5 типов ограничений целостности данных:
Для поддержания ссылочной целостности данных устанавливаются ограничения на существование, определяющие условия, при которых потенциальный или внешний ключ может быть вставлен, обновлен или удален. Существуют несколько стратегий, позволяющих учитывать наличие дочерней строки (картежей), которая ссылается на родительскую строку, подлежащее удалению, обновлению.
Стратегии:
Новая лекция
К данному моменту для каждой локальной логической модели данных должны быть подготовлены ER диаграмма, реляционная схема, словарь данных и сопроводительная документация с описанием ограничений, которые распространяются на эту модель. На текущем этапе все перечисленные компоненты используются для выявления сходств и различий между локальными логическими моделями данных с целью из объединения.
3.1 создание глобальной модели
1. анализ (пересмотр) имен и содержимого сущностей/отношений и их потенциальных ключей
- проблема синонимов и омонимов
- следует также учитывать, что сущности или связи в одном представлении могут быть выражены в виде атрибутов в другом представлении
2. анализ (пересмотр) имен и содержимого связей внешних ключей
- те же проблемы
3. слияние (объединение) сущностей/связей из отдельных локальных моделей данных
4. Включение (без слияния) сущностей/связей уникальных для каждой локальной модели данных
5. слияние связей внешних ключей из локальных моделей данных
6. включение (без слияния) связей внешних ключей уникальных для каждой локальной модели данных
7. проверка наличия недостающих сущностей отношений и связей внешних ключей
8. проверка внешних ключей
На этом этапе могут быть объединены сущности/отношения и связи, внешние ключи. Изменены первичные ключи и выявлены новые связи. Следует проверить, что внешние ключи в дочерних отношениях все еще остаются правильными и в случае необходимости внести соответствующие изменения.
Проверка ограничений целостности. Составление глобальной ER диаграммы / реляционной схемы.
Обновление документации.
Проверка отношений, созданных на основе глобальной логической модели данных с помощью метода нормализации и определение того, поддерживают ли они все требуемой транзакции. Этот этап аналогичен этапам 2.3 и 2.4, но в данном случае необходимо проверить только те области модели, которые были созданы в результате изменений, внесенных в процессе объединения модели. В крупных системах такой подход позволяет существенно сократить объем повторной проверки.
определение способа представления всех выделенных в глобальной логической модели данных базовых отношений в целевой СУБД. Документирование результатов проектирование базовых отношений.
Сущностная целостность |
Доменная целостность |
Ссылочная целостность |
Бизнес-правила |
PK |
Тип данных |
FK |
Триггеры |
Unique |
Default |
Декларативная ссылочная целостность |
Хранимые процедуры |
Identity (счетчик) |
FK |
Триггеры |
Транзакции |
Guid |
Check (ограничение проверки) |
Хранимые процедуры |
|
Null not null |
|||
Триггер |
Определение оптимальной файловой структуры для хранения базовых отношений и индексов, необходимых для достижения приемлемой производительности, иными словами определение способа хранения отношения и картежей во вторичной памяти
Определение функциональных характеристик транзакций, которые будут выполняться в проектируемой БД и выделение наиболее важных из них
определение наиболее эффективной файловой структуры для каждого базового отношения
определение того, будет ли добавление индексов способствовать повышению производительности системы
Способы учета с привязкой ко времени в реляционных БД
Можно выделить 2 наиболее частых случая, для моделирования которых требуется использование учета с привязкой ко времени. Изменение во времени состояния объекта и регистрация событий происходящих с ним.
Основные способы организации учета во времени:
Create создать
Alter обновить