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

Трансформации объектов в ERWin. Денормализация. Приемы проектирования. Соответствие моделей процессов и данных. Бессарабов Н.В. [email protected] 2007 г.

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

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

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

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

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

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

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

Скрипт для генерации таблицы Tab с горизонтальным разбиением CREATE TABLE Tab ( c3 VARCHAR2(20) NULL, c1 INTEGER NOT NULL, c2 VARCHAR2(20) NULL) PARTITION BY RANGE (c2) ( PARTITION p1 VALUES LESS THAN (0.5*MAXVALUE) , PARTITION p2 VALUES LESS THAN (MAXVALUE)); ALTER TABLE Tab ADD ( PRIMARY KEY (c1) ) ;  Бессарабов Н.В.2007

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

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

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

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

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

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

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

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

Решение с неопределенным множеством связей  Бессарабов Н.В.2007

Модель структурных свойств сущности «ВЕЩЕСТВО»  Бессарабов Н.В.2007

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

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

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

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

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

Запрос к реальным таблицам УМД на SQL по методу соединений SELECT T1.VAL,T2.VAL,T3.VAL,T4.VAL,T5.VAL FROM TC T1, TC T2, TC T3, TC T4, TC T5, TC T6, TC T7, TC T8 WHERE T1.COLUMN_NAME='ENAME' AND T1.TABLE_NAME='EMP' AND T1.SCHEME_NAME='SCOTT' AND T2.COLUMN_NAME='JOB' AND T2.TABLE_NAME='EMP' AND T2.SCHEME_NAME='SCOTT' AND T3.COLUMN_NAME='SAL' AND T3.TABLE_NAME='EMP' AND T3.SCHEME_NAME='SCOTT' AND T4.COLUMN_NAME='DEPTNO' AND T4.TABLE_NAME='EMP' AND T4.SCHEME_NAME='SCOTT' AND T5.COLUMN_NAME='DNAME' AND T5.TABLE_NAME='DEPT' AND T5.SCHEME_NAME='SCOTT' AND T6.COLUMN_NAME='DEPTNO' AND T6.TABLE_NAME='EMP' AND T6.SCHEME_NAME='SCOTT' AND T7.COLUMN_NAME='DEPTNO' AND T7.TABLE_NAME='DEPT' AND T7.SCHEME_NAME='SCOTT' AND T8.COLUMN_NAME='SAL' AND T8.TABLE_NAME='EMP' AND T8.SCHEME_NAME='SCOTT' AND T1.STRING_NUMBER=T2.STRING_NUMBER AND T1.STRING_NUMBER=T3.STRING_NUMBER AND T1.STRING_NUMBER=T4.STRING_NUMBER AND T1.STRING_NUMBER=T6.STRING_NUMBER AND T1.STRING_NUMBER=T8.STRING_NUMBER AND T2.STRING_NUMBER=T3.STRING_NUMBER AND T2.STRING_NUMBER=T4.STRING_NUMBER AND T2.STRING_NUMBER=T6.STRING_NUMBER AND T2.STRING_NUMBER=T8.STRING_NUMBER AND T3.STRING_NUMBER=T4.STRING_NUMBER AND T3.STRING_NUMBER=T6.STRING_NUMBER AND T3.STRING_NUMBER=T8.STRING_NUMBER AND T4.STRING_NUMBER=T6.STRING_NUMBER AND T4.STRING_NUMBER=T8.STRING_NUMBER AND T5.STRING_NUMBER=T7.STRING_NUMBER AND T6.STRING_NUMBER=T8.STRING_NUMBER AND (T6.VAL=T7.VAL AND TO_NUMBER(T8.VAL)>10000); Универсальная модель данных (5/6)

Универсальная модель данных (6/6) Запрос к реальным таблицам УМД на SQL по методу Т. Кайта SELECT T1.ENAME, T1.JOB, T1.SAL, T1.DEPTNO, T2.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) T1, (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) T2 WHERE T1.DEPTNO=T2.DEPTNO AND T1.SAL>10000;

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

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

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

Данные, зависящие от времени (вариант 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 <= требуемая_ дата)  Бессарабов Н.В.2007

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

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

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

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

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

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

Пример схемы “снежинка” [1]  Бессарабов Н.В.2007

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

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

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

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

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

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

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

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

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

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

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