37. Средства автоматизированного проектирования баз данных. Power Designer

CASE-средства поддерживают концептуальное проектирование, позволяют осуществить логическое и физическое проектирование путем автоматической генерации БД для целевой СУБД. Но следует обратить внимание на различия в терминологии. Во многих CASE-системах ER-модель называется логической моделью, а представление логической структуры целевой БД – физической моделью.

При сравнении CASE-систем кроме используемой методологии ER-моделирования, необходимо учитывать специфические критерии, связанные с реализацией функций автоматизированного проектирования: 1)• число и перечень поддерживаемых целевых СУБД; 2)• поддержку распределенных БД; 3)• поддержку коллективной работы при проектировании (управление правами пользователей, ведение репозитория и т. д.); 4)• построение концептуальной ER-модели по описанию структуры существующей БД – реверс-инжиниринг;5)• автоматизируемые функции проектирования и степень их автоматизации; 6)• качество и жесткость проектных решений (возможность выбора из нескольких альтернативных решений, возможность ручного вмешательства в процесс); 7)• надежность работы; 8)• документирование проекта; 9)• открытость системы (возможность стыковки с другими средствами); 10)• удобство графического редактора; 11)• количественные ограничения (общее число сущностей, число уровней вложенности для обобщенной сущности и др.);12)• возможность автоматической оценки объема памяти для проектируемой БД; 13)• возможность автоматической генерации процедур; 14)• наличие средств моделирования хранилищ данных; 15)• требования к ресурсам компьютера; 16)• операционную среду; 17)• стоимость системы.

CASE-средства показывают модель с разной степенью детализации: 1) только обозначения сущностей и связей между ними; 2) сущности + ключи;3) сущности + ключи + внешние ключи;4) сущности + все атрибуты.

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

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

 

38 Проектирование баз данных на логическом и физическом уровне

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

Можно указать основные этапы логического проектирования.

I. Выбор требуемой СУБД, чаще всего выбирается СУБД реляционного типа. Можно отметить следующие факторы, которые влияют на мыбор СУБД:

-стоимость -инструментальные средства и возможности СУБД; -тип модели; - переносимость; рассматривается независимость от платформы, операционной системы и языка;-требование СУБД к оборудованию; учитываются требования СУБД к процессору, RAM (оперативной памяти), дисковому пространству и т. д.

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

4. Нормализация отношений (при необходимости).

5. Определение требований поддержки целостности данных. Оно включает обязательные данные (запрет на NULL-значение), ограничеиия для доменов, целостность объектов (первичный ключ объекта иг может содержать пустого значения), поддержка ссылочной целостности.

Так, при выборе первичных/внешних ключей необходимо рассмотреть следующие аспекты: -может ли данный внешний ключ принимать неопределенные значепия (NULL-значения); - задаются допустимые значения для дан¬ного отношения; как правило, ограничения таблицы ограничивают значения, которые могут быть в записях таблицы;- целостность по ссылкам - предполагает обеспечение целостности отношений, которые поддерживаются первичными и внешними ключами;-ограничения базы данных (деловые правила или утверждения) -задают допустимые значения для всей базы данных и связывают в раз¬личных выражениях значения столбцов из разных таблиц базы данных. Принятие решения о реализации правил поддержания ссылочной це-лостности сводится к тому, что на этапе логического моделирования документируется решение о том, как будут реализованы данные правила поддержания ссылочной целостности: декларативно либо с использованием триггеров.

6. Определение представлений. Следует определиться и с возмож¬ными представлениями — виртуальными логическими таблицами. Та¬кая таблица существует только в памяти СУБД, однако с ней можно работать как с реальной таблицей и производить необходимые опера¬ции над данными, не беспокоясь о том, что пользователь может удалить или добавить некорректные данные в реальную таблицу

7. Определение пользователей и прав доступа к объектам базы

данных

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

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

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

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

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

Обычно на основании физической модели создается DDL-скрипт (DDL - Data Definition Language, язык определения данных; позволя¬ет создавать различные объекты базы данных и переопределять их структуру) для объектов базы данных либо эти объекты генерируются с помощью выбранного CASE-средства, так как современные средства такого класса поддерживают различные механизмы доступа к данным и могут выступать в роли клиентского приложения, инициирующего выполнение DDL-скриптов.

Перечислим основные этапы физического проектирования.

1. Перенос логической модели данных в среду выбранной СУБД. Как уже указывалось, триггер представляет собой автоматически выполняемый процедурный SQL-код, который активизируется при каком-либо событии, связанном с изменением данных

2. Проектирование физического представления базы данных. Хранение данных является одной из важнейших целей физического проектирования базы данных. Для оценки эффективности работы с данными существует несколько показателей: пропускная способность транзакций -время ответа -дисковая память

Любое CASE-средство, предназначенное для работы с базами данных, предлагает возможности по созданию как концептуальной, так и логической модели данных, причем осуществляется взаимопереход между указанными моделями Итак, в PowerDesigner:-концептуальная модель данных или схема (Conceptual Data Model, CDM) - это формализованное представление общей структуры дан¬ных информационной системы без привязки к конкретной реализации на базе СУБД; модель представляется в виде ER-диаграммы, физическая модель данных или схема (Physical Data Model, PDM) соответствует логической модели данных с учетом выбранной СУБД реляционного типа. Данная логическая модель имеет однозначное ото¬бражение в DDL-скрипт, т. е. в набор инструкций на языке SQL, пред¬назначенный для создания и модификации основных объектов базы данных (т. е. непосредственно возможны переход к физической модели данных и корректировка базы данных уже в среде выбранной СУБД).

Как правило, если концептуальная модель достаточно адекватно отражает предметную область, получить физическую схему в PowerDesigner можно автоматически. В дальнейшем происходит лишь доработка полученной логической модели, создаются необходимые представления, индексы, права доступа. При доработке логической модели данных следует определить, как будут реализованы правила целостности данных: декла¬ративно либо с использованием триггеров. Кроме того, необходимо рас¬смотреть бизнес-правила предметной области, которые будут реализова¬ны как хранимые процедуры или функции, используемые в дальнейшем при работе с базой данных.

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

39. Power Designer как средство автоматизированного проектирования баз данных. Создание концептуальных моделей данных

40. Power Designer как средство автоматизированного проектирования баз данных. Создание физических моделей данных. Реинжиниринг в Power Designer

41. Использование Power Designer для создания моделей баз данных. Создание объектных моделей

42. Использование Power Designer для создания моделей баз данных. Создание XML-модели данных. Создание многомерной модели