Трансформации объектов в ERWin Денормализация Приемы проектирования Соответствие

Трансформации объектов в ERWin. Денормализация. Приемы проектирования. Соответствие моделей процессов и данных. Бессарабов Н. В. bes@fpm. kubsu. ru 2007 г.

Трансформация объектов. Erwin 4. 1 • Слияние двух таблиц в одну и/или разбиение таблицы на две (денормализация). • Разрешение связи многие-ко-многим (создание ассоциативной сущности). • Три варианта преобразования иерархии категорий. • Горизонтальное разбиение таблиц (сегментирование). • Вертикальное разбиение таблиц (сегментирование). • Копирование колонок (сегментирование).

Наследование (1/5) Наследование объединяет сущности с общими характеристиками. Иерархию наследования создают когда сущности имеют общие атрибуты или связи. Ключевые атрибуты родителя немедленно передаются потомкам. Пример: Неключевой атрибут Ключевой атрибут

Наследование (2/5) Категории делятся на полные и неполные. В полной категории каждому экземпляру предка соответствует экземпляр в одном из потомков. В неполной такого потомка может не найтись. Символ полной категории: Символ неполной категории:

Наследование (3/5) Три способа перехода к физическому уровню: 1. Родительская и дочерние сущности представляются каждая своей таблицей (Sypertype-Subtype Identity) 2. И родительская и дочерние сущности представляются одной таблицей (Sypertype-Subtype Rollup) 3. Создаются таблицы только для дочерних сущностей (Sypertype-Subtype Rolldown) Для преобразования находясь в логическом уровне выделите символ категории. Выберите один из 2 подсвеченных инструментов: 3 1

Наследование (4/5) Для примера выбираем первый вариант нажав на знак Далее следуем указаниям мастера

Наследование (5/5) Итоги преобразования: на физическом уровне получаем три таблицы Результат для варианта Sypertype-Subtype Rolldown

Вертикальное сегментирование таблицы. Задание условий разбиения

Скрипт для генерации таблицы Tab с горизонтальным разбиением CREATE TABLE Tab ( c 3 VARCHAR 2(20) NULL, c 1 INTEGER NOT NULL, c 2 VARCHAR 2(20) NULL) PARTITION BY RANGE (c 2) ( PARTITION p 1 VALUES LESS THAN (0. 5*MAXVALUE) , PARTITION p 2 VALUES LESS THAN (MAXVALUE)); ALTER TABLE Tab ADD ( PRIMARY KEY (c 1) ) ;

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

The Chasm Trap • Наблюдается если одна из связей временная и проявляется именно после исчезновения этой связи. • Если, например, отдел остался без работников, как определить какие автомобили закреплены за отделом? Выход в создании связи между сущностями Отдел и Автомобиль.

Избыточные связи • Поскольку разрешение выдает та служба, которая обеспечивает правило, на основании которого выдано разрешение, то связь между сущностями «Служба» и «Разрешение» избыточна. • Для ответа на вопрос «какая служба выдала разрешение? » достаточно пройти через сущность «Служба» .

Нельзя расширять правило введения дополнительной сущности на более чем одну связь типа N: N Транзитивная связь функциональных зависимостей “Счет –Заказ” и “Заказ - Документ “

Замечание об альтернативных дугах. Подтип и супертип. Для некоторых строк таблицы могут требоваться свои связи, не приемлемые для других строк. Этот факт в нотации Р. Баркера изображают альтернативной дугой. Например, следующие связи • СТУДЕНТ получает СТИПЕНДИЮ или • СТУДЕНТ вносит ПЛАТУ_ЗА_ОБУЧЕНИЕ

Введение подтипа Для устранения альтернативной дуги в сущности СТУДЕНТ введены две подсущности. В таких случаях говорят о введении подтипов.

Введение супертипа Создан супертип «Субъект» , включающий типы «Ф/лицо» и «Организация» . Теперь естественным становится выявление общих свойств у последних двух типов.

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

Решение с неопределенным множеством связей

Модель структурных свойств сущности «ВЕЩЕСТВО»

Особенности модели структурных свойств сущности «ВЕЩЕСТВО» • Вместо отдельных связей в ней появилась сущность «СВЯЗЬ ВЕЩЕСТВ» . • Дополнительная сущность «ТИП СВЯЗИ ВЕЩЕСТВ» с тремя атрибутами может описывать и перечисленные связи и те, которые добавятся в будущем.

Универсальная модель данных (1/6) Структуры данных во время работы базы изменяются довольно редко. Однако, существует два типа систем, в которых схема базы перестраивается постоянно: Информационные системы (ИС) с данными, структуры которых невозможно предусмотреть заранее. Типичный пример – медицинские данные. Средства разработки ИС. Особый интерес представляют инструментальные средства, в которых структуры данных или же весь прототип ИС собирается «на ходу» в процессе сбора сведений о предметной области и задаче.

Универсальная модель данных (2/6) • Оказывается любую схему данных и сами данные можно разместить в так называемой универсальной модели (УМД), состоящей из небольшого количества таблиц. Этот набор таблиц один и тот же для любой представляемой виртуальной схемы. • Отличие УМД в том, что она хранит в себе и данные и метаданные. Вспомним, что метаданные в обычной РБД хранятся в отдельной базе -- словаре. • Таблицы УМД представляют иерархию данных и метаданных. В одном из вариантов это набор таблиц: “схема” – “таблица” – “столбец” – “данные”. Последняя таблица “данные” содержит значения, находящиеся в клетках таблиц виртуальной схемы. • На следующем слайде приведены схемы таблиц упрощенной УМД.

Универсальная модель данных (3/6) • • Базы в УМД обладают следующими недостатками: очень сложные запросы; низкое быстродействие; отсутствие во многих реализациях: ограничений целостности декларативных и процедурных (ОЦ), индексов, пользователей, ролей, представлений.

Универсальная модель данных (4/6) Запрос к виртуальным таблицам УМД на SQL SELECT emp. ename, emp. job, emp. sal, emp. deptno, dept. dname FROM emp, dept WHERE emp. deptno=deptno;

Универсальная модель данных (5/6) Запрос к реальным таблицам УМД на SQL по методу соединений SELECT T 1. VAL, T 2. VAL, T 3. VAL, T 4. VAL, T 5. VAL FROM TC T 1, TC T 2, TC T 3, TC T 4, TC T 5, TC T 6, TC T 7, TC T 8 WHERE T 1. COLUMN_NAME='ENAME' AND T 1. TABLE_NAME='EMP' AND T 1. SCHEME_NAME='SCOTT' AND T 2. COLUMN_NAME='JOB' AND T 2. TABLE_NAME='EMP' AND T 2. SCHEME_NAME='SCOTT' AND T 3. COLUMN_NAME='SAL' AND T 3. TABLE_NAME='EMP' AND T 3. SCHEME_NAME='SCOTT' AND T 4. COLUMN_NAME='DEPTNO' AND T 4. TABLE_NAME='EMP' AND T 4. SCHEME_NAME='SCOTT' AND T 5. COLUMN_NAME='DNAME' AND T 5. TABLE_NAME='DEPT' AND T 5. SCHEME_NAME='SCOTT' AND T 6. COLUMN_NAME='DEPTNO' AND T 6. TABLE_NAME='EMP' AND T 6. SCHEME_NAME='SCOTT' AND T 7. COLUMN_NAME='DEPTNO' AND T 7. TABLE_NAME='DEPT' AND T 7. SCHEME_NAME='SCOTT' AND T 8. COLUMN_NAME='SAL' AND T 8. TABLE_NAME='EMP' AND T 8. SCHEME_NAME='SCOTT' AND T 1. STRING_NUMBER=T 2. STRING_NUMBER AND T 1. STRING_NUMBER=T 3. STRING_NUMBER AND T 1. STRING_NUMBER=T 4. STRING_NUMBER AND T 1. STRING_NUMBER=T 6. STRING_NUMBER AND T 1. STRING_NUMBER=T 8. STRING_NUMBER AND T 2. STRING_NUMBER=T 3. STRING_NUMBER AND T 2. STRING_NUMBER=T 4. STRING_NUMBER AND T 2. STRING_NUMBER=T 6. STRING_NUMBER AND T 2. STRING_NUMBER=T 8. STRING_NUMBER AND T 3. STRING_NUMBER=T 4. STRING_NUMBER AND T 3. STRING_NUMBER=T 6. STRING_NUMBER AND T 3. STRING_NUMBER=T 8. STRING_NUMBER AND T 4. STRING_NUMBER=T 6. STRING_NUMBER AND T 4. STRING_NUMBER=T 8. STRING_NUMBER AND T 5. STRING_NUMBER=T 7. STRING_NUMBER AND T 6. STRING_NUMBER=T 8. STRING_NUMBER AND (T 6. VAL=T 7. VAL AND TO_NUMBER(T 8. VAL)>10000);

Универсальная модель данных (6/6) Запрос к реальным таблицам УМД на SQL по методу Т. Кайта SELECT T 1. ENAME, T 1. JOB, T 1. SAL, T 1. DEPTNO, T 2. DNAME FROM (SELECT STRING_NUMBER, MIN(DECODE(COLUMN_NAME, 'ENAME', VAL)) ENAME, MIN(DECODE(COLUMN_NAME, 'JOB', VAL)) JOB, MIN(DECODE(COLUMN_NAME, 'SAL', VAL)) SAL, MIN(DECODE(COLUMN_NAME, 'DEPTNO', VAL)) DEPTNO FROM TC WHERE TABLE_NAME='EMP' AND SCHEME_NAME='SCOTT' GROUP BY STRING_NUMBER) T 1, (SELECT STRING_NUMBER, MIN(DECODE(COLUMN_NAME, 'DNAME', VAL)) DNAME, MIN(DECODE(COLUMN_NAME, 'DEPTNO', VAL)) DEPTNO FROM TC WHERE TABLE_NAME='DEPT' AND SCHEME_NAME='SCOTT' GROUP BY STRING_NUMBER) T 2 WHERE T 1. DEPTNO=T 2. DEPTNO AND T 1. SAL>10000;

Денормализация Может быть полезной такая последовательность действий при разработке схемы базы: • Нормализация до 3 НФ или НФБК; • Анализ времени выполнения запросов и сложных вычислений, анализ размеров столбцов и таблиц; • Частичная денормализация с принятием мер против появления аномалий.

Неявные ключи Если запросы о принадлежности работника к направлению встречаются достаточно часто, то желательно добавление избыточной связи, выделенной жирной линией.

Выводимые данные • Итоговый платеж (TOTAL_CHARGE) за аренду получается как сумма платежей (CHARGE_AMOUNT) за отдельные единицы арендуемого оборудования. В свою очередь CHARGE_AMOUNT получается умножением стоимости суточной аренды (DAILY_CHARGE) на количество дней (NUMBER_OF_DAYS).

Данные, зависящие от времени (вариант 1) Запрос: SELECT PRICE FROM PRICES WHERE PRICE_CODE = ’A’ AND START_DATE = (SELECT MAX(START_DATE) FROM PRICES WHERE PRICE_CODE = ’A’ AND START_DATE <= требуемая_ дата)

Данные, зависящие от времени (вариант 2) Запрос: SELECT PRICE FROM PRICES WHERE PRICE_CODE = ’A’ AND заданная_ дата BETWEEN START_DATE AND END_DATE;

Сверхномализация Вертикальное разделение таблицы применяют в двух случаях: • в «широкой» таблице в часто используемых запросах выбирают только часть столбцов; • часть столбцов «узкие» и помещаются в один блок или немногие блоки; другая часть «широкие» , так что каждый столбец занимает несколько блоков; запросы часто используют ту или другую группу столбцов

Многомерные базы Аналитикам удобнее всего представлять анализируемые агрегированные данные в виде многомерных кубов (гиперкубов). На рисунке справа заимствованный из [2] пример трёхмерного куба, изображающего зависимость объема продаж от года, продавца и марки машины. Из-за трудностей представления многомерных данных гиперкубы представляют визуально в виде набора закладок с двумерными срезами гиперкуба. Работа с многомерными данными (режим OLAP) связана с агрегированием больших объемов данных. Она существенно отличается от обычного режима работы с базой, называемого OLTP.

Схема “звезда” [1] Реляционные таблицы могут представлять многомерные кубы если домены всех столбцов ограничены. Обычно гиперкубы моделируют схемами “звезда” и “снежинка”. Центральная, обычно большая, таблица это таблица факта (на рисунке SALE) содержит исследуемый показатель (measure). Таблицы размерности (dimensional table) соединены с таблицей факта и представляют разметку одной из сторон куба. Нетрудно заметить, что на рисунке изображен четырехмерный гиперкуб с измерениями CUSTOMER, PRODUCT, SALESPEOPLE, TIME.

Что такое dimension? Размерности представляют иерархии агрегации, причем не только однородных данных, таких как “кварталы”, “месяцы” и “дни”. В приведенном примере [2] по вертикали агрегация ведется по салонам и менеджерам.

Схема “снежинка” • ERwin поддерживает использование вторичных таблиц размерности, называемых консольными таблицами (outrigger). Они позволяют нормализовать данных в таблицах размерности. Консольные таблицы связаны только c таблицами размерности, причем консольная таблица в этой связи родительская, а таблица размерности - дочерняя. Связь может быть идентифицирующей или неидентифицирующей. • Модель, в которой консольные таблицы строятся для каждой таблицы размерности называется схемой "снежинка".

Пример схемы “снежинка” [1]

Переключение в режим Dimensional Переключение возможно только на физическом уровне. Пройдите путь Model -> Model Properties и выберите опцию DM для физического уровня (Physical Notation)

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

Модель процессов и ее соответствие модели данных • Информация, которая моделируется в виде одной стрелки в BPWin, может содержаться в нескольких сущностях и атрибутах в модели данных и наоборот. • Работы в BPWin могут создавать или изменять данные, которые соответствуют входящим стрелкам. • BPWin позволяет связать элементы модели данных, документировать влияние работ на данные и тем самым позволяет создать спецификации на права доступа к данным для каждого процесса.

Связывание модели процессов и модели данных Последовательность действий В BPWin необходимо создать сущности и атрибуты. Они создаются двумя способами: 1) в словарях сущностей и атрибутов (в меню Dictionary/Entity Dictionary и /Attribute Dictionary )

Связывание модели процессов и модели данных (1/2) 2) в редакторе Entity and Attribute Dictionary Editor (в меню Model/ “Entity/Attribute Editor”)

Связывание модели процессов и модели данных (2/2) 2. Для создания экспортируемого файла с расширением. bpx, выберите в меню File/Export/ERWin(BPX). 3. В ERWin выбрать меню File/Inport/BPWin и в диалоге ERWin Open File указать файл BPX, в который была выгружена информация о модели.

Экспорт данных из ERWin в BPWin (1/2) Последовательность действий: 1. В ERWin откройте модель и выгрузите данные модели в файл с расширением *. eax. Для этого выберите пункт меню File/Export/BPWin. 2. В BPWin выберите пункт меню File/Import/ERWin(EAX). Появится диалог Import Differences Preview. Для внесения данных в модель процессов нажмите кнопку Accept.

Экспорт данных из ERWin в BPWin (2/2) 3. На вкладке Arrow Data диалога Arrow Properties, можете связать атрибуты со стрелкой. Каждая стрелка может быть связана с несколькими атрибутами различных сущностей.

Создание ассоциаций • Для документирования воздействия работ на данные используется Data Usage Editor • Для сущностей создается ассоциация CRUD (Create, Read, Update, Delete). • Для атрибутов создается ассоциация IRUN (Insert, Read, Update, Nullify) • Ассоциации CRUD и IRUN – это правила использования сущностей и атрибутов работами, т. е. то, что могут делать работы с входящими и исходящими данными. Так стрелки входа представляют данные, которые могут быть прочитаны (Read) или обновлены (Update). Эти данные нельзя создать (Create, Insert) или удалить (Delete, Nullify). Данные, поступающие по стрелкам управления можно только читать. Выходные данные можно обновлять, удалять или создавать. Для стрелок механизма нет ассоциаций.

Заключение Рассмотрены преобразования объектов базы в ERWin. Это позволило разрешать связи типа “многие-ко-многим”, появляющиеся в логической модели, но не реализуемые на физическом уровне. Появилась возможность использовать в РБД не присущее реляционной модели категории. Изучена денормализация, в том числе сегментирование таблиц, неявные ключи, работа с выводимыми данными. Кратко рассмотрена работа с данными, меняющимися во времени. Рассмотрены сомнительные структуры данных, возникающие на стадии проектирования базы. Показаны два варианта так называемой универсальной модели данных, позволяющей хранить в таблицах базы и данные и метаданные. Создание многомерных моделей OLAP, точнее реляционного варианта ROLAP, реализуемого схемами “звезда” и “снежинка”, позволяет создавать хранилища данных используемые для их анализа. В заключительной части рассмотрено решение проблемы соответствия структуры модели бизнес-процессов и схемы базы.

Литература 1. 2. Маклаков С. В. Создание информационных систем с All. Fusion. Modeling. Suite. – М. : ДИАЛОГ-МИФИ. 2005 – 432 с. Хрусталёв Е. М. Агрегация данных в OLAP-кубах. www. olap. ru