1. Использование AllFusion ERwin Data Modeler при проектировании баз данных (основные возможности, элементы модели, уровни представления)

Возможности:

Позволяет создать 2 вида модели: физическая и логическая. Логическая представляет собой абстракт взгляд на данные. Данные представлены как в реальном мире. Нет привязки к СУБД, предназначена для обсуждения и экспертизы. Физическая модель ориентирована на целевую СУБД и представляет собой отображение системного каталога (таблицы, типы данных, ограничения, индексы).

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

Логическая модель

Физич модель

Позволяет проводить документирование модели: описание сущности и ее атрибутов, пример запроса, пример кортежа.

Различают 2 вида связей: идентифицирующая (между независимой сущностью и зависящей от нее сущностью) и неид-щая.

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

Слева – полн, справа неполная.

AllFusion Data Model Validator позволяет автоматич анализировать структ БД с целью выяснения ошибок и недочетов, а так же внесения исправлений.

Исходн мб:

1.модель ERWIN; 2.БД; 3.Скрипт проекта Oracle

Сущности и атрибуты

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

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

Идентифицирующая связь устанавливается между независимой

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

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

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

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

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

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

Элементы модели:

На логическом уровне:

• Сущность

• Категория

• Связи: идентифицирующая, неидентифицирующая, многие-ко-многим.

На физическом уровне:

• Сущность

• Представление

• Связи: идентифицирующая, неидентифицирующая, связь представлений.

Моделирование можно производить на разных уровнях.

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

Уровни логической модели

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

* диаграмма сущность-связь (Entity Relationship Diagram (ERD));

* модель данных, основанная на ключах (Key Based model (KB));

* полная атрибутивная модель (Fully Attributed model (FA)).

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

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

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

2. Основные этапы разработки базы данных с использованием AllFusion ERwin Data Modeler.

Концептуальное (инфологическое) проектирование

Концептуальное (инфологическое) проектирование — построение информационной модели наиболее высокого уровня абстракции. Такая модель создаётся без ориентации на какую-либо конкретную СУБД и модель данных.

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

Чаще всего концептуальная модель базы данных включает в себя:

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

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

Логическое (даталогическое) проектирование

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

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

Включает в себя

• Создание сущностей;

• Задание атрибутов сущностей

• Создание первичных и внешних ключей

• Задание отношений, иерархий обобщений

Физическое проектирование

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

Физическое проектирование обычно завершается генерацией базы в соответствующую целевую СУБД.

3. 5 Назначение AllFusion Data Model Validator. Основные типы обнаруживаемых ошибок (дать примеры ошибок).

AllFusion Data Model Validator позволяет автоматич анализировать структ БД с целью выяснения ошибок и недочетов, а так же внесения исправлений.

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

- возможность прямой и обратной проверки структур: при помощи продукта можно оптимизировать структуры существующих баз данных или проверять на корректность созданные в AllFusion Data Modeler модели  - автоматизирует сложные рутинные функции проверки на ошибки  - встроенная система подсказок предлагает варианты исправления выявленных ошибок и методы повышения эффективности баз данных

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

Ошибки и недостатки мод-ния колонок

1.противоречивое определение групп колонок (в таблице оплата1 – number, оплата2 – number, оплата3 – varchar(20))

2.неправильное или недостаточное моделирование колонок (в одной табл номер города varchar(20), в другой number)

3.таблица не имеет колонок ()

4.длина поля больше, чем позволяет СУБД

5.противоречивость значений по умолчанию

6.колонки представляют собой одни и те же данные, но имеют разный тип данных

7.наимен колон совпадает с зарезервированными словами SQL

8. таблица с неуникальными именами колонок

Ошибки,связанные с моделир индексов и ограничений

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

2.аномалии в определении индексов(*индекс функционально эквивалентен первичному ключу,*индекс содержит супернабор первичного ключа, *индекс содерж супернабор другого уник индекса)

3.неверно определен альтернативный ключ

4.различные определения ограничения CHECK

5.таблица не имеет уникальных ключей

6.табл не имеет кластеризованных индексов

7.первичн ключ имеет колонку/атрибут с типом «действительное число»

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

9. ненужный внешний ключ

10. отсутствие индексов

Ошибки связей

1.некорректная рекурсивная иерархическая связь

2.неопределенные связи

3.ненужый внешний ключ

4.бесконечные циклы

5.взаимно-пересекающ связи

6.таблица не имеет связей

Н.заказа

Н.сотрудн

Заказы клиенты

Н.клиента

Н.клиента

ФИО

Подчинен

Not null

6. Концепция и назначение хранилища данных, типовая обобщенная схема. Основные отличия от oltp-систем

Хранилище данных – предметно-ориентированный, интегрированный, привязанный ко времени и неизменяемый набор данных, предназначенный для поддержки принятия решений.

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

Свойства хранилищ данных:

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

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

3. Привязка ко времени. Данные в хр-ще точны и действительны, только если они привязаны к интервалу времени.

4. Неизменяемость – данные не обновляются в оперативном режиме, а лишь пополняются за счет инф-ции из систем оперативной обработки

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

OLTP	Хранилище данных
1.Содержит текущие данные 2.Данные являются динамическими 3.хранит подробные сведения 4.Характерен повторяющийся способ обработки данных 5.Высокая интенсивность обработки транзакций 6.Предсказуемый способ использования данных 7.Предназначен для поддержки принятия повседневных решений 8.Обслуживает большое количество работников исполняющего звена	1.Содержит исторические данные 2.Данные являются статическими 3.Хранят подробные и частично обобщенные сведения 4.Нерегламентир, неструктурированный, эвристический способ обработки данных 5.Средняя или низкая интенсивность обработки транзакций 6.Непредсказуемый способ использования данных 7.Поддержка принятия стратегических решений 8.Обслуживает малое кол-во работников руководящего звена

Основные проблемы, связанные с хранилищем данных:

1. Недооценка ресурсов, необходимая для хранения данных;

2. Скрытые проблемы источников данных – связана с источником данных и заключается в том, что некоторые поля остаются не заполнены (пропущены в процессе заполнения);

3. Отсутствие требуемых данных в имеющихся архивах;

4. Повышения требований конечных пользователей;

5. Унификация данных (при создании интегрированного представления данных разработчик может сделать акцент на подчёркивании сходств, а не отличий);

6. Высокие требования к ресурсам (требуется большой объём памяти);

7. Владение данными – создание хранилища данных может изменить статус конечных пользователей в отношении прав доступа к данным;

8. Сложность сопровождения;

9. Долговременный характер проекта (для создания проекта может потребоваться большой срок)