ВУЗ: Томский государственный университет систем управления и радиоэлектроники
Категория: Учебное пособие
Дисциплина: Базы данных
Добавлен: 28.11.2018
Просмотров: 7009
Скачиваний: 47
106
• реализовать все связи между сущностями;
• разрешить все неопределенные связи с помощью дополнительных
сущностей.
Первым шагом второго этапа является выбор атрибутов в качестве пер-
вичных ключей для каждой сущности. Чаще всего в качестве первичного ключа
выбирается некоторый уникальный номер или идентификатор, который в даль-
нейшем будет отличать каждый экземпляр сущности от другого. Для покупате-
ля в качестве такового можно выбрать, например, номер ИНН, а для товара –
номер на штрих-коде. Кроме того, можно задать для большинства сущностей
собственную нумерацию на основе так называемого поля «Счетчик», который
для каждой новой записи просто выбирает очередной порядковый номер, ведь
подобный тип данных реализован в большинстве СУБД.
Далее для всех видов связей, кроме неопределенных, необходимо реали-
зовать миграцию первичных ключей родительских сущностей в дочерние. Для
каждой определенной связи необходимо определить признак зависимости по
идентификации, т. е. выделить идентифицирующие и неидентифицирующие
связи. Также выбрать способ реализации связей типа «Категория» и «Иерархи-
ческая рекурсия».
Неопределенные связи между сущностями необходимо разрешить за счет
введения новых сущностей и разделения каждой неопределенной связи на две
определенные идентифицирующие связи между двумя сущностями и третьей
новой сущностью.
По итогам второго этапа проектирования строится КВ-диаграмма пред-
метной области с указанием всех первичных и внешних ключей сущностей
(рис. 4.16).
Для каждой сущности в качестве первичного ключа был выбран числовой
атрибут «Номер». Для того чтобы не путаться при создании связей и миграции
ключей, к каждому первичному ключу в конце названия добавлена буква от
названия сущности: для сущности «Покупатель» первичным ключом является
атрибут «НомерП», для сущности «Товар» – «НомерТ», для сущности
«Накладная» – «НомерН».
Далее были реализованы выявленные на первом этапе связи. Определен-
ная неидентифицирующая связь была реализована посредством миграции пер-
вичного ключа родительской сущности «Покупатель» в область атрибутов до-
черней сущности «Накладная». Таким образом, в дальнейшем в каждой
накладной будет указан покупатель, на которого она оформлена.
107
Рис. 4.16 – КВ-диаграмма Торговой компании
Неопределенная связь между сущностями «Накладная» и «Товар» была
разрешена с помощью добавления новой сущности, которая получила название
«ТоварыНакладной». Также были образованы две определенные идентифици-
рующие связи между новой сущностью и двумя старыми, при этом первичные
ключи обеих родительских сущностей, мигрировавшие в дочернюю, образова-
ли новый составной ключ.
Этап 3. Построение полноатрибутной модели
Заключительным этапом проектирования является создание итоговой
полноатрибутной модели предметной области на основе полученной ранее
КВ-диаграммы. FA-диаграмма должна включать в себя, помимо сущностей,
связей, первичных и внешних ключей, ещё и набор всех неключевых атрибутов
каждой сущности, который позволит хранить весь необходимый объем инфор-
мации о предметной области.
Для торговой компании итоговая диаграмма модели предметной области,
изображенная на рисунке 4.17, дополнена набором неключевых атрибутов.
Сущность «Покупатель» дополнена атрибутами «ФИО», «Адрес» и «Телефон».
Сущность «Товары» теперь будет состоять из набора товаров, у каждого из ко-
торых есть наименование, категория и цена. В накладной будет указываться
номер, покупатель и дата оформления, а также необходимость в доставке това-
ров. Список товаров каждой накладной будет храниться в сущности «Товары-
Накладной». Можно обратить внимание, что атрибут «Цена» встречается в двух
сущностях одновременно – «Товар» и «ТоварыНакладной». Это связано с тем,
что каждый товар имеет некоторую текущую цену, т. е. цену, по которой товар
продается в данный момент. Эта информация хранится в сущности «Товар».
Естественно, что эта цена может измениться со временем, т. е. цена одного и
Накладная
НомерН (ПК)
НомерП (ВК)
ТоварыНакладной
НомерН (ПК, ВК)
НомерТ (ПК, ВК)
1
М
Товар
НомерТ (ПК)
М
1
Покупатель
НомерП (ПК)
М
1
108
того же товара в разных накладных, выписанных в разное время, может быть
различной. Таким образом и возникло два атрибута «Цена» – цена товара в
накладной и текущая цена товара.
Рис. 4.17 – FA-диаграмма Торговой компании
4.3.4 CASE-средства
Существует целый ряд программных продуктов, предназначенных для
автоматизации процесса проектирования, в том числе для построения диаграмм
модели IDEFIX, а также других известных нотаций [14]. Сэкономить времен-
ные ресурсы и создать структуру БД помогают так называемые CASE-средства
(Computer Aided Software Engineering) автоматизированного проектирования.
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
Под CASE-средствами понимается все программное обеспе-
чение, используемое для автоматизации процесса разработки ин-
формационных систем.
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
CASE-средства могут охватывать как отдельные этапы жизненного цикла
информационной системы, так и несколько этапов сразу.
Широкому внедрению CASE-средств в процесс разработки информаци-
онных систем способствовало:
• развитие методологии проектирования и формализация некоторых его
процессов;
• подготовка профессиональных аналитиков и программистов, воспри-
имчивых к структурному и объектно-ориентированному подходам в
разработке ИС;
Накладная
НомерН (ПК)
НомерП (ВК)
ТоварыНакладной
НомерН (ПК, ВК)
НомерТ (ПК, ВК)
1
М
Товар
НомерТ (ПК)
М
1
Покупатель
НомерП (ПК)
М
1
Дата
Доставка
Цена
Кол-во
ФИО
Адрес
Телефон
Наименование
Категория
Цена
109
• рост производительности компьютеров;
• внедрение и широкое распространение сетевых технологий, позволя-
ющих объединять усилия нескольких разработчиков в общий процесс
проектирования.
В общем случае современные CASE-системы имеют в своем составе сле-
дующие компоненты:
1. Репозиторий, или словарь данных. Представляет собой специализиро-
ванную базу данных, предназначенную для хранения состояний раз-
рабатываемой информационной системы. В репозитории хранится ис-
черпывающая информация о разрабатываемой системе, в том числе и
версии отдельных ее компонентов. Так что в любой момент проекти-
ровщики в случае неудачи могут вернуться к предыдущей версии.
2. Большое значение в использовании CASE-инструментов имеет разви-
тие диаграммных графических техник, позволяющих моделировать
поведение предметной области в графическом виде. По этой причине
все основные CASE-средства имеют в своем составе специализиро-
ванные графические редакторы.
3. Верификатор диаграмм. Служит для проверки построенных в процес-
се разработки диаграмм на предмет соответствия используемой мето-
дологии.
4. Документатор проекта. Позволяет получать информацию о состоянии
разработки проекта. С помощью документатора можно автоматизиро-
вать процесс создания документации.
5. Администратор проекта. Предназначен:
• для инициализации проекта;
• задания начальных параметров;
• назначения и изменения прав доступа к элементам проекта;
• мониторинга выполнения проекта.
6. Сервисы. Предназначены для выполнения различных вспомогатель-
ных функций, например архивирования или восстановления проекта
из архива.
Классификация CASE-средств
Существует несколько подходов к классификации CASE-инструментов.
Рассмотрим классификацию, ориентированную на процессы жизненного цикла
информационных систем.
110
• Средства анализа и проектирования: BPWin, Silverrun, Oracle Design-
er, Rational Rose, Paradigm Plus, Power Designer, System Architect.
• Средства проектирования баз данных: ERWin, Silverrun, Oracle De-
signer, Paradigm Plus, Power Designer, MySQL Workbench. Следует
также отметить, что практически все СУБД имеют в своем составе
средства графического проектирования баз данных.
• Средства управления требованиями: RequisitePro, DOORS (Dynamic
Object-Oriented Requirements System, динамическая объектно-
ориентированная система управления требованиями).
• Средства управления конфигурацией: PVCS, ClearCase, Telelogic Syn-
ergy.
• Средства документирования: Rational SoDA (Software Document Au-
tomation, автоматизированное документирование программного обес-
печения).
• Средства тестирования: Rational Suite TestStudio, Rational Robot.
• Средства управления проектами: Open Plan Professional, Microsoft
Project, Borland StarTeam, IBN.
• Средства переноса программного обеспечения в новую среду: Rational
Rose, Paradigm Plus [15].
В качестве примера рассмотрим простейшее CASE-средство, которое
позволяет осуществлять частичную автоматизацию процесса проектирования
БД MySQL. В программном продукте MySQL Workbench разработчик имеет
возможность проектировать модель предметной области с помощью редактора
ER-диаграмм и в дальнейшем интегрировать полученную модель непосред-
ственно в СУБД MySQL.
На рисунке 4.18 приведена модель предметной области «Торговая компа-
ния», реализованная в MySQL Workbench с использованием нотации IDEF1X.
На рисунке 4.19 приведена та же самая диаграмма с выбором нотации IE
для изображения связей.
MySQL Workbench является простейшим бесплатным CASE-средством и
не позволяет напрямую взаимодействовать с СУБД, отличными от MySQL. Тем
не менее данный продукт, как и большинство других CASE-средств, содержит
встроенный генератор SQL-кода, который на основе графического представле-
ния предметной области генерирует код, позволяющий реализовать данную
модель в виде готовой БД в произвольной СУБД. Для представленной на ри-