7.Case -средства проектирования бд

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

• мощные графические средства для описания и документирования ИС, обеспечивающие удобный интерфейс с разработчиком и развивающие его творческие возможности;

• интеграция отдельных компонент CASE-средств, обеспечивающая управляемость процессом разработки ИС;

• использование специальным образом организованного хранилища проектных метаданных (репозитория).

С развитием компьютерных технологий и появлением CASE-моделирования (Computer Aided Software Engineering) возникла потребность в инструментах, которые бы поддерживали стандарты моделирования. Современный инструмент моделирования баз данных должен удовлетворять ряду требований.

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

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

• Инструмент моделирования должен поддерживать как логическое, так и физическое моделирование.

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

Все современные CASE-средства могут быть классифицированы в основном по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ. Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные задачи (tools), набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС (toolkit) и полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные общим репозиторием (workbench). Помимо этого, CASE-средства можно классифицировать по следующим признакам:

• применяемым методологиям и моделям систем и БД;

• степени интегрированности с СУБД;

• доступным платформам.

Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы:

• средства анализа, предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPwin (Logic Works));

• средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций Designer/2000 (ORACLE), Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;

• средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV;

• средства разработки приложений. (PowerBuilder, Delphi (Borland) и др.) и генераторы кодов.

• средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor.

8.ER-моделирование. Базовая ER-модель

Описание объектов предметной области и связей между ними представляется в виде так называемых ER-моделей (или ER-диаграмм). ER - Entity-Relationship - Сущность-Отношение.

Формализованный графический язык. Существует множество нотаций языка.

• Предметная область - часть реального (реже - виртуального) мира, представляющая интерес для данного исследования

• Сущность (объект) - это реальный или воображаемый объект, информация о котором представляет интерес.

• Класс объектов - совокупность объектов, обладающих одинаковым набором свойств

ER-модель строится на уровне классов объектов, а не отдельных экземпляров объектов.

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

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

Разновидности сложных объектов:

• Составной объект соответствует отображению отношения «целое–часть».

• Обобщенный объект отражает наличие связи «род-вид» между объектами предметной области.

Агрегированные объекты соответствуют обычно какому-либо процессу, в который оказываются «вовлеченными» другие объекты.

Изображение объекта.

Изображение объекта и его свойств:

Виды связей между объектами:

Изображение обобщенного объекта

Изображение агрегированного объекта

Изображение зависимой по идентификации сущности

В ER-модели должно быть отображено все, о чем идет речь в данной предметной области (во входных документах, в выходных документах и т.п. Понятия «объект» и «свойство» являются относительным. В качестве самостоятельного объекта в ER-модели следует изображать сущности:

− имеющие более одного идентификатора;

− для которых фиксируются какие-либо их свойства;

− которые участвуют более чем в одной связи.

При возникновении сомнений лучше принять решение о создании самостоятельного объекта, так как это в дальнейшем потребует меньших переделок модели.

Количественные характеристики всегда являются свойствами какого-либо объекта, и никогда – самостоятельными объектами.

При изображении предметной области надо стремиться отобразить информацию как можно более детально, так как это в дальнейшем даст возможность принять более обоснованные решения при проектировании структуры базы данных. Так, например, если «адрес», «ФИО» являются составными характеристиками, то желательно это отразить в ER-модели.

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

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

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

Естественно, что каждый подкласс может быть изображен в ER-модели как самостоятельный объект, а не как подкласс какого-то родового класса. Для того чтобы иметь больше информации о предметной области и сократить число элементов (свойств, связей) в ER-модели, в большинстве случаев лучше объединять подклассы в класс.