Новая лекция

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

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

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

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

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

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

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

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

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

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

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

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

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

Customer (IdCust, FName, LName, IdCity)

PK – IdCust

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

On Delete – No Action

On Update – Cascade

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

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

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

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

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

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

1. Обязательные данные

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

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

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

5. Ограничения предметной области (бизнес-правила)

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

Стратегии:

1. No Check – нет ограничения

2. No Action – нельзя обновлять, если есть подчиненные

3. Set Default

4. Set Null

5. Cascade

Новая лекция

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. Перенос глобальной логической модели данных в среду целевой СУБД

1. проектирование базовых отношений (таблиц)

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

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

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

   Сущностная целостность	Доменная целостность	Ссылочная целостность	Бизнес-правила
   PK	Тип данных	FK	Триггеры
   Unique	Default	Декларативная ссылочная целостность	Хранимые процедуры
   Identity (счетчик)	FK	Триггеры	Транзакции
   Guid	Check (ограничение проверки)	Хранимые процедуры
   	Null – not null
   	Триггер

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Create – создать

Alter – обновить