Средства проектирования баз данных

РЕФЕРАТ

по информатике

на тему: Средства проектирования баз данных

СОДЕРЖАНИЕ

1. ВВЕДЕНИЕ 2

2. ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ С ПОМОЩЬЮ 5

CASE-СРЕДСТВ

1. ЗАКЛЮЧЕНИЕ 22

ВВЕДЕНИЕ

РОЛЬ ПРОЕКТИРОВАНИЯ ДАННЫХ В ЖИЗНЕННОМ ЦИКЛЕ ИНФОРМАЦИОННЫХ СИСТЕМ

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

Целью таких проектов является разработка и создание информационной системы с базами данных. Практически во всех таких проектах решается задача проектирования баз данных определенного типа. Решение задачи проектирования повышает вероятность того, что разрабатываемая информационная система будет удовлетворять заданным функциональным и информационным требованиям с учетом заданных ограничений.

Процесс проектирования базы данных охватывает несколько основных сфер:

• Проектирование объектов базы данных (таблицы, представления, индексы, триггеры, хранимые процедуры, функции, пакеты) для представления данных предметной области в базе данных.

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

• Проектирование баз данных под конкретную вычислительную среду или информационную технологию (архитектура "клиент-сервер", параллельные архитектуры, распределенная вычислительная среда).

• Проектирование баз данных под назначение системы (интеллектуальный анализ данных, OLAP, OLTP и т.д.).

Жизненный цикл информационной системы в общем случае начинается в момент принятия решения о ее создании и заканчивается в момент выведения ее из эксплуатации. Основными его этапами являются:

• проведение предпроектного обследования;

• проектирование данных;

• разработка приложений, тестирование, написание документации;

• внедрение созданной информационной системы и обучение пользователей;

• эксплуатация и сопровождение;

• выведение из эксплуатации и утилизация.

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

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

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

случае является также тестирование и документирование создаваемого

продукта. Данный этап обычно завершается созданием дистрибутива приложения или его частей и документированием процедуры его инсталляции.

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

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

ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ С ПОМОЩЬЮ

CASE-СРЕДСТВ

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

данных.

К ключевым понятиям проектирования баз данных относятся:

• CASE-технологии - программная основа CASE-средств, применяемая для разработки и поддержки процессов жизненных циклов ПО, используемых в моделировании данных и генерации схем баз данных. Чаще всего программные коды в CASE-технологиях пишутся на языке SQL;

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

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

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

При проектировании баз данных с помощью CASE-средств выделяются и анализируются определенные бизнес-процессы, для которых создается БД, определяются взаимосвязи их элементов, оптимизируется их инфраструктура. CASE-средства позволяют существенно сократить

время на разработку БД и уменьшить количество ошибок в них.

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

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

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

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

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

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

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

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

обычно происходит на этапе логического проектирования.

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

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

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

В процессе физического проектирования следует определить наименования таблиц и типы данных для всех полей. Если необходимо, на этом же этапе описываются представления (если таковые будут создаваться) и может быть создан код хранимых процедур. Далее обычно полагается определить, какие именно объекты и как будут создаваться: например, с помощью каких SQL-предложений создаются индексы, с помощью каких объектов — триггеров или серверных ограничений — реализуется ссылочная целостность, создаются ли индексы для альтернативных ключей и т.д.

Пример диаграммы, отображающей физическую модель для SQL Server 7.0, соответствующую приведенной выше логической модели, представлен на рисунке

.

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

CREATE TABLE Customer (

CustomerID char(5) NOT NULL,

CompanyName nvarchar(40) NOT NULL,

ContactName nvarchar(30) NULL,

ContactTitle nvarchar(30) NULL,

Address nvarchar(60) NULL,

City nvarchar(15) NULL,

Region nvarchar(15) NULL,

PostalCode nvarchar(10) NULL,

Country nvarchar(15) NULL,

Phone nvarchar(24) NULL,

Fax nvarchar(24) NULL

)

ALTER TABLE Customer

ADD PRIMARY KEY (CustomerID)

CREATE TABLE Order (

OrderID int IDENTITY,

CustomerID char(5) NULL,

EmployeeID int NULL,

OrderDate datetime NULL,

RequiredDate datetime NULL,

ShippedDate datetime NULL,

ShipVia int NULL,

Freight money NULL,

ShipName nvarchar(40) NULL,

ShipAddress nvarchar(60) NULL,

ShipCity nvarchar(15) NULL,

ShipRegion nvarchar(15) NULL,

ShipPostalCode nvarchar(10) NULL,

ShipCountry nvarchar(15) NULL,

FOREIGN KEY (Custom

REFERENCES Customer)

CREATE INDEX XIF1Order ON Order ( CustomerID)

ALTER TABLE Order ADD PRIMARY KEY (OrderID)

create trigger tU_Customer on Customer for UPDATE as

begin

  declare @numrows int, @nullcnt int,

 @validcnt int, @insCustomerID char(5),

 @errno int, @errmsg varchar(255)

  select @numrows = @@rowcount

  if update(CustomerID)

  begin

if exists ( select * from deleted,Order where

Order.CustomerID = deleted.CustomerID )

begin

select @errno = 30005,

@errmsg = ‘Cannot UPDATE Customer because Order exists.’

goto error

end

  end

  return

error:

raiserror @errno @errmsg

rollback transaction

end

Как правило, современные средства проектирования данных поддерживают несколько типов СУБД (например, ERwin фирмы Computer Associates поддерживает более 20 различных СУБД). Уровень поддержки той или иной платформы в разных средствах проектирования данных может быть различен. Например, конкретное средство может поддерживать или не поддерживать для данной СУБД такие особенности, как создание хранимых процедур, генерация объектов физической памяти (табличных пространств, сегментов отката и др.), задание местоположения объектов базы данных в физических объектах и т.д. Поэтому, выбирая средство проектирования данных для решения конкретной задачи, стоит поинтересоваться, каковы его возможности с точки зрения поддержки особенностей той или иной платформы — при удачном раскладе можно сэкономить немало времени на «ручное» доведение создаваемой базы данных (или DDL-скрипта для ее генерации) до необходимого состояния. При этом, естественно, чем больше возможностей и платформ поддерживает конкретное средство проектирования данных, тем дороже оно стоит (следует отметить, что CASE-средства вообще относятся к не самым дешевым программным продуктам — цены на них составляют обычно от одной до нескольких десятков тысяч долларов).

Отметим, что физическое проектирование может включать и дополнительную «ручную» работу по доведению базы данных или скрипта для ее генерации до «товарного» вида. Например, нередко в скрипт также включаются SQL-предложения для заполнения некоторых таблиц, данные которых более или менее постоянны, таких, например, как список субъектов Российской Федерации или справочник телефонных кодов различных стран,

а также нестандартные триггеры и процедуры.

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

Подавляющее большинство современных средств проектирования

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

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

Кроме того, подавляющее большинство средств проектирования данных позволяют восстанавливать физическую модель данных их системного каталога и представлять ее в виде ER-диаграммы (этот процесс называется обратным проектированием — reverse engineering), а также производить синхронизацию системного каталога и физической модели. При создании информационной системы, которая должна использовать унаследованные от предшествующих ей систем данные, такая особенность весьма полезна — в этом случае логическое проектирование можно начать с модификации уже имеющейся модели (этот процесс получил название round-trip engineering).

Перейдём к рассмотрению наиболее популярных продуктов, с помощью которых можно его осуществить.

Для создания баз данных под наиболее распространенные СУБД чаще всего используются следующие CASE-средства:

ERwin (Logic Works) - CASE-инструмент для создания концептуальных и логических схем баз данных. Он позволяет редактировать различные наборы данных, представляя их в виде электронных таблиц, разрабатывать структуры баз данных, синхронизировать модели, скрипты и БД, настраивать

шаблоны, выводить рабочую информацию в виде отчетов, строить удобные и понятные диаграммы, отображающие различные процессы в системе и взаимосвязи между ними; ERwin разработан компанией Logic Works, которая в 1988 году была приобретена фирмой Platinum Technologies, а ее, в свою очередь, приобрела компания Computer Associates. Этот продукт в течение последних десяти лет занимает лидирующие позиции среди средств проектирования данных.

ERwin представляет собой специализированное средство проектирования данных. Его применение предполагает, что моделирование бизнес-процессов и потоков данных производится с помощью других продуктов (например, BPwin), c которыми можно осуществлять обмен сведениями о моделях.

ERwin не ориентирован на какую-то конкретную СУБД и поддерживает более 20 типов СУБД, включая СУБД всех ведущих производителей серверов баз данных (Oracle, Sybase, Microsoft, IBM, Informix), а также все популярные форматы настольных СУБД (включая dBase, Clipper, FoxPro, Access, Paradox), кроме, возможно, самых последних версий. Дело в том, что новые версии ERwin не выпускались уже довольно давно — как минимум год не было обновлений имеющейся версии и более двух лет не выпускались новые версии этого продукта. Поэтому при использовании ERwin с последними версиями некоторых СУБД могут возникнуть проблемы (например, некоторые типы данных SQL Server 7.0 это CASE-средство поддерживает не совсем корректно). Тем не менее ERwin остается одним из самых популярных в мире продуктов этого класса благодаря поддержке большого количества платформ, простоте интерфейса

и, что немаловажно, поддержке специфических особенностей организации физической памяти наиболее популярных серверных СУБД. Например, для СУБД Oracle, Microsoft SQL Server, Sybase этот продукт позволяет изменять местоположение и параметры хранения индексов, почти для всех популярных серверных СУБД создавать кластеризованные индексы и для

многих из них — указывать характеристики табличных пространств и сегментов отката.

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

ERwin поддерживает обмен моделями с репозитарием Designer/2000 и Microsoft Repository, а также генерацию клиентских приложений для Visual Basic и PowerBuilder.

Помимо однопользовательской работы ERwin может выступать в роли клиентского приложения для другого CASE-средства — ModelMart, которое позволяет организовать коллективную разработку моделей данных, предоставляя для этой цели разделяемый репозитарий, хранящийся в одной из серверных СУБД.

Недавно компанией Computer Associates был выпущен новый продукт — ERwin Examiner, представляющий собой инструмент проверки баз данных и DDL-скриптов с целью выявления ошибок проектирования данных, сказывающихся на целостности данных и производительности сервера, таких, например, как ошибки нормализации, противоречивые ключи и т.д. В результате проверки ERwin Examiner предлагает способы устранения

PowerDesigner (бывший S-Designor, принадлежавший компании PowerSoft) представляет собой инструмент, в состав которого входят средство создания концептуальных (то есть логических) моделей,

средство создания физических моделей и средство объектно-ориентированного моделирования, используемое при генерации клиентских приложений. Средство создания физических моделей представляет собой отдельный продукт — PowerDesigner PhysicalArchitect. В состав продукта PowerDesigner DataArchitect входят средства создания концептуальных и физических моделей, в состав PowerDesigner Developer — средства объектно-ориентированного моделирования и создания физических моделей, а в состав PowerDesigner ObjectArchitect — все три средства.

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

Помимо серверных СУБД производства Sybase (Adaptive Server Enterprise 12.0, Sybase SQL Anywhere) PowerDesigner DataArchitect способен работать с любыми ODBC-источниками. Как и ERwin, он поддерживает генерацию триггеров серверных СУБД, осуществляющих стандартную обработку событий, связанных с нарушениями ссылочной целостности.

PowerDesigner Developer и PowerDesigner ObjectArchitect могут генерировать код клиентских приложений для PowerBuilder, а также классы Java и компоненты JavaBeans. Возможно и обратное проектирование диаграмм классов из исходных текстов Java, байт-кодов и архивов Java. Поддерживается также генерация кода Web-приложений и объектов для Sybase Enterprise Application Server на основе физической модели.

PowerDesigner DataArchitect может импортировать логические и физические модели ERwin.

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

Отметим, что PowerDesigner DataArchitect весьма популярен на российском рынке, причем не только среди пользователей СУБД и средств

разработки Sybase.

ER/Studio (Embarcadero Technologies)

ER/Studio менее известен в нашей стране, чем ERwin и PowerDesigner DataArchitect. Однако возможности этого продукта также заслуживают внимания.

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

ER/Studio поддерживает написание макросов на SAX Basic (клон Visual Basic for Applications). Этот язык позволяет создавать макросы для выполнения однотипных операций, например добавления стандартных полей к вновь создаваемым сущностям. С помощью этого же языка можно генерировать стандартные триггеры и хранимые процедуры для вставки, удаления, изменения записей. Код на этом языке можно даже отлаживать и обращаться к свойствам сущностей для конструирования серверного кода. Однако, в отличие от ERwin, ER/Studio не позволяет добавить к каждой таблице свои шаблоны триггеров или просмотреть код конкретного триггера в процессе разработки модели — чтобы получить код одного триггера, нужно сгенерировать скрипт для всей модели.

Модели ER/Studio можно сохранить не только в виде DDL-скрипта, но и в формате XML. Можно также создать репозитарий для их хранения в любой серверной СУБД. ER/Studio может импортировать модели ERwin, но при импорте теряются связи шаблонов серверного кода с конкретными таблицами, и не все макросы ERwin корректно преобразуются в макросы SAX Basic.

ER/Studio позволяет сгенерировать Java-классы для клиентских приложений.

Отметим, что ER/Studio является COM-сервером, что позволяет использовать его в других приложениях, предоставляя им возможность просмотра и редактирования моделей данных, а также создавать другие решения на его основе.

System Architect 2001 представляет собой универсальное CASE-средство, позволяющее осуществить не только проектирование данных, но и структурное моделирование. Средство проектирования данных и создания ER-диаграмм является одной из составных частей этого продукта.

Этот продукт поддерживает СУБД практически всех ведущих производителей, включая Oracle (Oracle 8), Sybase, DB2, SQL Server, IBM (AS400, DB2), Informix, Sybase, Access, dBASE, Paradox и др.

В процессе логического моделирования можно проверить модель на соответствие правилам проектирования данных (например, на соответствие ее первой, второй или третьей нормальным формам). При генерации DDL-скрипта можно сгенерировать триггеры (в том числе и нестандартные).

Все компоненты System Architect позволяют документировать процесс работы над проектом, включая техническое задание, план тестирования и др. Модели System Architect 2001, как и в случае других CASE-средств, можно сохранять в репозитарии. Однако в отличие от традиционных репозитариев, обладающих более или менее стандартной структурой хранимых данных, репозитарий System Architect является настраиваемым —

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

System Architect обладает встроенным Visual Basic for Application, что позволяет создавать разнообразные решения на базе этого продукта, включая автоматическую генерацию моделей и проектной документации.

System Architect 2001 позволяет генерировать код клиентских приложений для Visual Basic, Delphi и PowerBuilder (на сегодняшний день это практически единственное CASE-средство, поддерживающее генерацию кода Delphi), классы C++, а также код и текстовые экранные формы COBOL.

Visible Analyst — весьма популярный продукт компании Visible Systems Corporation. Широко известны также ранее производимые этой компанией CASE-средства EasyER и EasyCASE — предшественники Visible Analyst.

Этот продукт выпускается в трех редакциях: Visible Analyst DB Engineer, который включает средства проектирования данных, Visible Analyst Standard, который кроме проектирования данных позволяет осуществлять структурное моделирование, и Visible Analyst Corporate, который помимо указанных выше возможностей позволяет осуществлять также объектно-ориентированное моделирование.

Visible Analyst поддерживает довольно широкий спектр СУБД с точки зрения генерации серверного кода, включая Oracle 7, Sybase SQL Server (System 10 и 4.x); Informix, DB2, Ingres. Последние версии многих серверных СУБД (Oracle 8, Microsoft SQL Server 6.5/7/2000, последние версии серверов Sybase) в этом списке пока отсутствуют.

Для Informix и DB2 указанный продукт позволяет генерировать DDL-скрипты, учитывающие специфические особенности организации физической памяти наиболее популярных серверных СУБД, такие как управление табличным пространством, размером экстентов, режимами блокировки данных, степенью заполнения данными (fill factor), а также

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

Модели Visible Analyst можно сохранять в многопользовательском репозитарии, созданном в одной из серверных СУБД.

Кроме того, Visible Analyst позволяет на оcнове созданных моделей генерировать код для Visual Basic, С++ и COBOL.

Отметим, что продукты семейства Visible Analyst имеют относительно невысокую стоимость, что также является их весьма привлекательной чертой.

Продукт под названием Visio, приобретенный в январе 2000 года корпорацией Microsoft вместе с его разработчиком — компанией Visio Corporation, позиционировался на рынке как одно из самых популярных средств создания схем и диаграмм. То, что один из членов семейства Microsoft Visio 2000 — Visio 2000 Enterprise — содержит в своем составе полноценное CASE-средство, было в определенной степени сюрпризом для пользователей CASE-инструментов. Однако, если вдуматься, появление своих средств проектирования данных, моделирования бизнес-процессов и объектно-ориентированного моделирования у Microsoft — шаг вполне закономерный, поскольку такие средства появляются рано или поздно у большинства производителей популярных серверных СУБД и средств разработки, каковым Microsoft является уже довольно давно.

Как и подавляющее большинство средств проектирования данных, Visio Enterprise позволяет производить прямое и обратное проектирование данных, преобразовывать логическую модель в физическую. Этим средством поддерживаются все ODBC- и OLE DB-источники данных. С его помощью можно создавать триггеры для стандартной обработки нарушений

ссылочной целостности в случае, если DDL-скрипт создается для Microsoft SQL Server, и серверные ограничения, если скрипт создается для другой СУБД. Отметим, что Visio при генерации скриптов позволяет указывать параметры организации физической памяти Oracle, Informix, Microsoft SQL Server, DB2 и некоторых других СУБД.

Отметим, что помимо средств проектирования данных Visio включает средства объектно-ориентированного моделирования и генерации кода приложений Visual Basic 6, а также классов C++ и Java. Модели Visio можно сохранять в Microsoft Repository.

Visio, в отличие от специализированных средств проектирования данных, не обладает скриптовым языком, позволяющим создавать серверный код, не связанный с конкретной СУБД. При использовании этого продукта такой код нужно создавать на этапе физического проектирования в уже созданном скрипте. Однако справедливости ради заметим, что и стоимость Visio Enterprise по сравнению с ERwin или PowerDesigner DataArchitect невысока, тем более что Visio в целом представляет собой продукт более широкого назначения, нежели другие рассмотренные выше средства проектирования данных. К тому же этот продукт является сервером автоматизации, обладает весьма обширной объектной моделью и встроенным средством разработки — Visual Basic for Applications, что позволяет, в частности, создавать на его базе разнообразные решения, в том числе и автоматизировать разработку моделей данных.

• S-Designor (SDP) - графический CASE-инструмент для проектирования структуры реляционных БД. Он создает модели баз данных в два этапа - выстраивая концептуальную модель и затем преобразуя ее в физическую, причем в данном процессе разработки возможен как прямой, так и обратный переход между моделями. Данный инструмент позволяет проектировать базы данных под различные СУБД, в том числе под Oracle и MySQL;

• DataBase Designer (ORACLE) - интегрированная CASE-среда, которая позволяет анализировать предметную область создания БД, выполнять программирование и проектирование, проводить оценку и тестирование, осуществлять сопровождение, обеспечивать качество, управлять конфигурацией и проектом, разрабатывать и анализировать требования к информационной системе.

В зависимости от того, на каком этапе проектирования баз данных используются CASE-средства, их относят к:

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

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

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

ЗАКЛЮЧЕНИЕ

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

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

1. Поддержка создания логических моделей, не зависящих от СУБД, и генерации физических моделей на их основе.

2. Поддержка нескольких типов СУБД, включая не только серверные, но и настольные.

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

4. Способность осуществлять обратное проектирование на основе либо имеющейся базы данных, либо имеющегося DDL-скрипта.

5. Возможность генерации отчетов и проектной документации на основе созданной модели.

6. Возможность сохранения модели в репозитарии, который во многих случаях может быть разделяемым.

7. Поддержка генерации кода для одного или нескольких средств разработки или языков программирования. Следует отметить, что в этом отношении самым популярным средством разработки является, по-видимому, Visual Basic.

СПИСОК ЛИТЕРАТУРЫ

1. Выбор средств разработки и создания баз данных. Режим доступа

URL: https://studopedia.info/8-78448.html (дата обращения: 16.02.2021).

2. Десять лучших инструментов для разработки и администрирования

MySQL. Режим доступа URL: https://habrahabr.ru/post/142385 (дата обращения: 16.02.2021)

3. Конструктор баз данных Руна. Режим доступа URL:

http://runabase.ru/ (дата обращения: 16.02.2021).

4. Лучший инструмент для работы с базами данных MySQL. Режим

доступа URL: https://www.devart.com/ru/dbforge/mysql/studio/ (дата обращения: 16.02.2021).

5. Обзор средств проектирования информационных систем. Режим

доступа URL: http://citforum.ru/database/kbd96/42.shtml (дата обращения: 16.02.2021).

7. Обзор программных средств для создания баз данных. Режим до-

ступа URL: https://videouroki.net/razrabotki/obzor-programmnykh-sriedstv-dlia-

sozdaniia-baz-dannykh.html (дата обращения: 16.02.2021).

8. Основные возможности Getreport. Режим доступа URL:

http://getreport.pro/Home/BasicFeatures (дата обращения: 17.02.2021).

9. Коннолли, Т. Базы данных. Проектирование, реализация и сопро-

вождение. Теория и практика : учебное пособие / Т. Коннолли, К. Бегг – Ви-

льямс, 2017. – 1440 с. 10. AquaDataStudio — управление базами данных. Режим доступа URL:

http://pro-spo.ru/winprog/1449-aqua-data-studio- (дата обращения: 23.01.2018).

11. DataExpress — конструктор баз данных. Режим доступа URL:

http://mydataexpress.ru/ (дата обращения: 23.01.2018). 12. ERwinDataModeler R8 — Программные продукты — Каталог ПО.

Режим доступа URL: http://www.interface.ru/home.asp?artId=101 (дата обращения: 18.02.2021).

13. NavicatPremium. Режим доступа URL: https://www2.navicat.com/ru/

(дата обращения: 18.02.2021).

13