Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 30)

Горизонтальное разбиение отношения может проводиться по раз­ным принципам. В качестве условия разбиения может использовать­ся значение какого-либо атрибута (как, например, в рассмотренном выше примере - значение атрибута ФАКУЛЬТЕТ). Довольно часто используется разбиение по временному признаку, например данные за каждый месяц хранятся в отдельном файле. Могут использоваться и другие принципы разбиения: по достижению определенного объе­ма файла, по активности записей и т.д.

3.4. Создание физической модели в ERWin

3.4.1. Выбор целевой СУБД

Как было отмечено ранее, в ERWin представление структуры базы данных для конкретной целевой СУБД называется физической мо­делью.

Для отображения физической модели в ERWin следует восполь­зоваться списком выбора, расположенным в левой части панели ин­струментов (рис. 3.9).

Рис. 3.9. Переключение в режим отображения

физической модели

Перед созданием физической модели следует выбрать целевую СУБД. Для этого можно воспользоваться кнопкой (Select Target Server) инструментального меню. В появившемся окне (рис. 3.10) нужно выбрать желаемую СУБД и ее версию. Эта возможность до­ступна только на физическом уровне.

Если в явном виде СУБД не указана, то физическая модель стро­ится для СУБД, выбираемой по умолчанию (Oracle). Сменить целе­вую СУБД можно на любом этапе проектирования. Возможность ис­пользовать одну и то же логическую модель для получения разных физических моделей является большим преимуществом CASE-технологий.

Вид окна Target Server будет несколько различаться в зависимо­сти от выбранной СУБД.

Рис. 3.10. Выбор целевой СУБД

3.4.2. Нотации, используемые при построении физической модели

Так же как и при изображении логической модели, для представ­ления физической модели используется несколько нотаций (рис. 3.11), а именно: IDEF1X (Integration DEFinition for Information Modeling), IE (Information Engineering) и DM (Dimensional Modeling). Как видим, по сравнению с логическим моделированием появилась дополнитель­ная нотация - DM, о которой далее будет сказано особо.

Вид панели инструментов (ERWin Toolbox) для физической мо­дели в нотации IDEF1X представлен на рис. 3.12.

Кнопка соответствует таблице базы данных, кнопка представлению (view). Кнопки , и несут ту же функциональность, что аналогичные кнопки в логической модели. Кнопка (view relationship) используется для связывания представлений.

Рис. 3.11. Выбор методологии при создании физической модели

Рис. 3.12. Вид панели инструментов для физической модели

в нотации IDEFIX

На рис. 3.13 изображена физическая модель в нотации IDEF1X полученная из логической модели (см. рис. 2.99).

Редактор таблиц на стадии физического моделирования имеет отличия от соответствующего редактора, используемого на стадии логического моделирования. Более того, он имеет специфические особенности, связанные с характеристиками выбранной целевой СУБД. На рис. 3.14 представлен вид окна редактора таблиц (Table Editor) для целевой СУБД Access, а на рис. 3.15 - для целевой СУБД Oracle.

Рис. 3.13. Физическая модель данных

Рис. 3.14. Вид окна редактора таблиц для целевой СУБД Access

Рис. 3.15. Вид окна редактора таблиц для целевой СУБД Oracle

Контекстные меню также имеют некоторые различия в зависимо­сти от выбранной целевой СУБД (рис. 3.16, 3.17).

Рис. 3.16. Контекстное меню для целевой СУБД Access

Рис. 3.17. Контекстное меню для целевой СУБД Oracle

Вкладка Volumetrics может быть использована для оценки раз­мера БД (рис. 3.18). Для того чтобы оценить размер БД, предвари­тельно для каждой таблицы нужно задать число записей в них.

Рис. 3.18. Вид окна редактора таблиц. Вкладка Volumetrics

Посмотреть результат вычислений можно, выбрав позиции меню Tasks/Generate Reports и затем - нужный отчет. При открытии отче­та появится окно Опций Отчета (рис. 3.19). Если, описывая размер таблицы, указывать Grow By (прирост числа записей в месяц), то в отчете можно посмотреть не только начальный размер таблицы, но и прогнозируемый размер через заданное число месяцев.

Рис. 3.19. Вид окна Опции отчета

3.4.3. Уровни просмотра физической модели

Для физической модели, так же как для логической, существует возможность изменения уровня просмотра модели. Для этого можно воспользоваться одной из изображенных кнопок панели инструмен­тов: . Первая из них соответствует уровню сущностей, вторая - уровню колонок, третья - уровню определения (comments view). Эти уровни полностью совпадают с описанными при рассмот­рении логической модели.

Контекстное меню уровня просмотра для физической модели (рис. 3.20) несколько отличается от соответствующего меню для ло­гической модели. Как мы видим, по сравнению с рис. 2.101 отсут­ствует позиция меню Icon, но присутствует Physical Order. Атрибуту в логической модели в физической модели соответствует термин Ко­лонка (Column), a Сущности (Entity) — Таблица (Table).

Рис. 3.20. Контекстное меню «Переключения уровней отображения

для физической модели»

3.4.4. Сравнение логической и физической моделей

На рис. 3.21 изображен фрагмент логической модели. Сущность ДАТА отмечена как Logical Only, поэтому на физической модели со­ответствующая ей таблица отсутствует (рис. 3.22).

Рис. 3.21. Фрагмент логической модели

На физической модели появилась дополнительная связующая таб­лица СОТРУДНИК_ПРЕДМЕТ, которая разрывает связь М:М между этими сущностями. Преобразование связи М:М происходит автома­тически. В физической модели было создано представление (View), которое показывает фамилии сотрудников и названия предметов, которыми они владеют (V_S4). На схеме физической модели оно изоб­ражено пунктирным прямоугольником с закругленными углами, к которому ведут также пунктирные линии. На схеме логической моде­ли View не отражается.

Рис. 3.22. Фрагмент физической модели

3.4.5. Создание хранилищ данных

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

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

Для реализации многомерной модели данных в хранилищах дан­ных часто используется схема «звезда». Такая схема обычно содер­жит одну большую таблицу, называемую таблицей факта (fact table), помещенную в «центр» схемы, и меньшие по объему вспомогатель­ные таблицы, называемыми таблицами измерения (dimension tables), соединенные с таблицей факта радиальными связями. Схема может также содержать произвольное число вынесенных (консольных) таб­лиц (outrigger tables), соединенных с таблицами измерений.

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

Для получения многомерной^ модели данных (Dimensional Modeling) можно в окне Preferences в блоке Physical Notation выб­рать значение DM (рис. 3.23). Для того чтобы попасть в соответствую­щее окно, надо осуществить следующий выбор позиций меню: Option/ Preference/Methodology.

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

Модель (см. рис. 3.24) после преобразования ее в нотацию DM будет иметь вид, представленный на рис. 3.25.

Рис. 3.23. Выбор нотации DM

Рис. 3.24. Предупреждающее сообщение при переходе к нотации DM

Рис. 3.25. Вид модели в нотации DM

В многомерной модели для различения роли таблиц можно ис­пользовать специальные иконки: - для таблицы фактов, - для таблицы измерений, - для консольных таблиц. Чтобы эти иконки появились на схеме, следует выбрать позицию Dimensional Icon нис­падающего контекстного меню (рис. 3.26).

Рис. 3.26. Меню для изображения иконок в DM-модели

При преобразовании физической модели в DM-модель роль каж­дой таблицы определяется системой автоматически. Если имеется необходимость изменить роль таблиц, то надо в окне Редактор таб­лиц снять флажок Calculate Automatically и установить соответству­ющий переключатель (рис. 3.27).

Верхний ряд кнопок панели инструментов для многомерной мо­дели (рис. 3.28) не отличается от аналогичной панели для физичес­кой модели (см. рис. 3.12). Отличия заключаются в кнопках, обозна­чающих тип связи. Кнопка обозначает идентифицирующую связь, кнопка - связь с представлением, а кнопка - неидентифицирующую связь. Как мы видим, в многомерной модели явно не фикси­руются направление связи и кардинальное число. Предопределено, что связь идет по направлению от таблицы размерности к таблице факта и от консольных таблиц к таблице размерности.

Характеристики

Список файлов книги