Файл: Учебное пособие СанктПетербург 2017.pdf

29
Без семантического моделирования можно обойтись, если число таб- лиц не превышает десяти, но оно совершенно необходимо, если БД включает более сотни таблиц.
В настоящее время на рынке существует большое количество систем ав- томатизации проектирования баз данных (Сomputer-Аided Software Engineer- ing – CASE-средств), обеспечивающих автоматизированное преобразование диаграммных концептуальных схем баз данных, представленных в той или иной семантической модели данных, в реляционные схемы данных конкрет- ной СУБД (подраздел 4.1). Все CASE-системы имеют развитые средства до- кументирования процесса разработки, автоматические генераторы отчетов по- зволяют подготовить отчет о текущем состоянии проекта с подробным описа- нием объектов БД и их отношений, что существенно облегчает ведение проек- та.
3.3 Проектирование базы данных «Университет»
3.3.1 Инфологическое проектирование
Инфологическое проектирование проводится, как правило, методом последовательных приближений к удовлетворительному набору схем отно- шений. Исходной точкой является представление предметной области в виде одного или нескольких отношений, а на каждом шаге проектирования произ- водится некоторый новый набор схем отношений, обладающих лучшими свойствами.
Пусть в результате системного анализа установлена необходимость от- разить в БД сведения о студентах вуза.
При этом БД должна содержать данные о каждом студенте: СТУ-
ДЕНТ(Номер зачетной книжки, Фамилия, Имя, Отчество, Номер группы,
Номер факультета, Наименование, Декан, Номер специальности, Наименова- ние специальности, Стоимость, Дата рождения, Курс, Коммерческий).
Определим функциональные зависимости в исходном отношении (рис. 14).

30
Рисунок 14 – Функциональные зависимости в исходном отношении СТУДЕНТ
Следовательно, инфологическая модель предметной области будет иметь вид, показанный на рис. 15.
Рисунок 15 – Инфологическая модель предметной области
Модель содержит не только информационные объекты, но и взаимо- связи между ними. Так, связь типа «один ко многим» устанавливается:

между объектами ГРУППА и СТУДЕНТ по их общему атрибуту
Номер группы;

между объектами ГРУППА и ФАКУЛЬТЕТ по их общему атрибуту
Номер факультета;

между объектами ГРУППА и СПЕЦИАЛЬНОСТЬ по их общему ат- рибуту Номер специальности.
Стоит, однако, обратить внимание на то, что полученная инфологиче- ская модель, в целом удовлетворяющая требованиям нормализации, с точки зрения логики может некорректно описывать предметную область. Модель

31 допускает существование некоторой специальности, которая не преподается ни на одном факультете. Естественным желанием при этом является добав- ление связи между объектами ФАКУЛЬТЕТ и СПЕЦИАЛЬНОСТЬ. Альтер- нативой этому может быть определение домена для атрибута Номер специ- альности, который будет содержать только «существующие» номера специ- альностей.
3.3.2 Даталогическое проектирование
Выполняется описание логических структур сформированных инфор- мационных объектов, предполагаемых к реализации в базе данных. Описания приведены в табл. 2 – 5.
Таблица 2 – Логическая структура информационного объекта СТУДЕНТ
Таблица 3 – Логическая структура информационного объекта ГРУППА

32
Таблица 4 – Логическая структура информационного объекта ФАКУЛЬТЕТ
Таблица 5 – Логическая структура информационного объекта
СПАЦИАЛЬНОСТЬ
После описания информационных объектов необходимо установить
правила ссылочной целостности для каждой связи инфологической модели.
Правила ссылочной целостности – это логические конструкции, ко- торые выражают правила использования взаимосвязанных данных при их добавлении, обновлении и удалении.
В ходе физической реализации БД каждой связи будут приписаны
триггеры ссылочной целостности (RI-триггеры), которые и обеспечат уста- новленное правило целостности.
Триггеры – это подпрограммы, которые запускаются всякий раз при выполнении команд вставки (INSERT), обновления(UPDATE) и удаления
(DELETE).
Допустим, что необходимо удалить один из экземпляров информаци- онного объекта ГРУППА. Экземпляр информационного объекта СТУДЕНТ не может существовать без соответствующего экземпляра объекта ГРУППА.
Следовательно, необходимо либо запретить удаление группы, в которой чис- лится хотя бы один студент, либо сразу удалять всех студентов вместе с

33 группой. Такие правила ссылочной целостности называются RESTRICT и
CASCADE соответственно.
В другой ситуации, когда, например, экземпляр информационного объек- та СТУДЕНТ может существовать без ссылки на номер группы в объекте
ГРУППА, при удалении какой -либо группы информация о ней должна остать- ся в объекте СТУДЕНТ. Такое правило называется SET NULL. При этом значе- ние атрибута Номер группы объекта СТУДЕНТ принимает значение NULL.
Правило SET DEFAULT устанавливает атрибуту значение по умолча- нию. Например, при «удалении» группы все студенты, которые в ней учи- лись, зачисляются в другую группу (значению атрибута Номер группы объ- екта СТУДЕНТ присваивается значение по умолчанию).
Наконец, правило NONE не меняет значение атрибута. При «удалении» группы запись о ней «повисает в воздухе», т. е. экземпляр объекта СТУДЕНТ ссылается на несуществующую уже запись о группе.
3.3.3 Физическое проектирование
Основной целью физического проектирования базы данных является описание способа физической реализации логического проекта базы данных, т.е. реализации базы данных на вторичных запоминающих устройствах. На этом этапе рассматриваются основные отношения, организация файлов и ин- дексов, предназначенных для обеспечения эффективного доступа к данным, а также все связанные с этим ограничения целостности и средства защиты.
Физическое проектирование неразрывно связано с конкретной СУБД.
Между логическим и физическим проектированием существует постоянная обратная связь, так как решения, принимаемые на этапе физического проек- тирования с целью повышения производительности системы, способны по- влиять на структуру логической модели данных.
4 АВТОМАТИЗАЦИЯ ПРОЕКТИРОВАНИЯ БАЗ ДАННЫХ
4.1 Общая характеристика CASE-средств
Современные CASE-средства (Computer-Aided Software/System Enginee-
ring) охватывают обширную область поддержки многочисленных технологий проектирования информационных систем (ИС).
Обычно к этим средствам относят любое программное средство, авто- матизирующее ту или иную совокупность процессов жизненного цикла (ЖЦ)
ИС. Интегрированное CASE-средство (или комплекс средств, поддерживаю- щих полный ЖЦ ПО) содержит следующие компоненты:

репозиторий, являющийся основой CASE-средства. он должен обес- печивать хранение версий проекта и его отдельных компонентов, синхронизацию поступления информации от различных разработ- чиков при групповой разработке, контроль метаданных на полноту

34 и непротиворечивость;

графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм, об- разующих модели ИС;

средства разработки приложений, включая языки 4gl и генераторы кодов;

средства конфигурационного управления;

средства документирования;

средства тестирования;

средства управления проектом;

средства реинжиниринга.
Все современные CASE-средства могут быть классифицированы в ос- новном по типам и категориям.
Классификация по типам отражает функциональную ориентацию
CASE-средств на те или иные процессы жизненного цикла ИС.
Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает:

отдельные локальные средства, решающие небольшие автономные задачи (tools);

набор частично интегрированных средств, охватывающих большинст- во этапов жизненного цикла ИС (toolkit);

полностью интегрированные средства, поддерживающие весь ЖЦ
ИС и связанные общим репозиторием.
Помимо этого, CASE-средства можно классифицировать по следующим признакам:

применяемым методологиям и моделям систем и БД;

степени интегрированности с СУБД;

доступным платформам.
Классификация по типам в основном совпадает с компонентным со- ставом CASE-средств и включает следующие основные типы:

средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF, BPwin);

средства анализа и проектирования (Middle CASE), поддерживаю- щие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage
Team Builder, Designer/2000, Silverrun, PRO-IV, CASE Аналитик).
Выходом таких средств являются спецификации компонентов и ин- терфейсов системы, архитектуры системы, алгоритмов и структур данных;

средства проектирования баз данных, обеспечивающие моделиро- вание данных и генерацию схем баз данных (как правило, на языке

35
SQL)для наиболее распространенных СУБД.К ним относятся

ERwin, S-Designor и DataBase Designer.Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team
Builder, Designer/2000, Silverrun и PRO-IV;

средства разработки приложений. К ним относятся средства
4GL,JAM, PowerBuilder, Developer/2000, New Era, SQL Windows,
Delphi и др. и генераторы кодов, входящие в состав Vantage Team
Builder, PRO-IVи частично–в Silverrun;

средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД входят в состав Vantage Team Builder, PRO-IV, Silverrun,
Designer/2000, ERwin, S-Designor, Rational Rose.В области анализа программных кодов наибольшее распространение получают объ- ектно-ориентированные CASE-средства, обеспечивающие реинжи- ниринг программ на языке С++ (Rational Rose, Object Team).
В большинстве CASE-средств в целях автоматизации проектирования
БД реализована семантическая модель данных, которая требует отдельного рассмотрения.
4.2 Семантическая модель данных
Потребности проектировщиков баз данных в более удобных и мощных средствах моделирования предметной области вызвали к жизни направление семантических моделей данных, которые наиболее актуальны в автоматизи- рованном проектировании. При этом любая развитая семантическая модель данных, как и реляционная модель, включает структурную, манипуляцион- ную и целостную части.
Главным назначением семантических моделей является обеспечение возможности выражения семантики (смысла) данных и их взаимосвязей.
Наиболее часто на практике семантическое моделирование используется на первой стадии проектирования базы данных. При этом в терминах семан- тической модели производится концептуальная схема базы данных, которая затем вручную или автоматизированно преобразуется к реляционной (или ка- кой-либо другой) схеме. Этот процесс выполняется под управлением методик, в которых достаточно четко оговорены все этапы такого преобразования.
Одной из наиболее популярных семантических моделей данных явля- ется модель Сущность-Связь (Entity Relationship Model), часто ее называют кратко ER-моделью.
На использовании разновидностей ER-модели основано большинство современных подходов к проектированию баз данных (главным образом, ре- ляционных). Модель была предложена Ченом (Chen) в 1976 г. Моделирова- ние предметной области в этом случае базируется на использовании графи- ческих диаграмм, включающих небольшое число разнородных компонентов.

36
В связи с наглядностью представления концептуальных схем баз данных, ER- модели получили широкое распространение в CASE-системах, поддержи- вающих автоматизированное проектирование реляционных баз данных.
Основными понятиями ER-модели являются сущность, связь и атри-
бут.
Сущность – это реальный или абстрактный объект, информация о ко- тором должна сохраняться и быть доступна.
Связь – это графически изображаемая ассоциация, устанавливаемая между двумя сущностями. Эта ассоциация всегда является бинарной и может существовать между двумя разными сущностями или между сущностью и ей же самой (рекурсивная связь).
В любой связи выделяются два конца (в соответствии с существующей парой связываемых сущностей), на каждом из которых указывается имя кон- ца связи, степень конца связи (сколько экземпляров данной сущности связы- вается), обязательность связи (т. е. любой ли экземпляр данной сущности должен участвовать в данной связи).
Связь представляется в виде линии, связывающей две сущности или ведущей от сущности к ней же самой.
Атрибутом сущности является любая деталь, которая служит для уточнения, идентификации, классификации, числовой характеристики или выражения состояния сущности.
Метод IDEF1X является стандартом для разработки реляционных баз данных и использует условный синтаксис, специально разработанный для удобного построения семантической модели.
Использование метода IDEF1X наиболее целесообразно для построения логической структуры базы данных после того, как все информационные ре- сурсы исследованы и решение о внедрении базы данных, как части корпора- тивной информационной системы, принято. Однако средства моделирования
IDEF1X изначально разработаны для построения реляционных информаци- онных систем, и если существует необходимость проектирования другой системы, скажем, объектно-ориентированной, то лучше избрать другие мето- ды моделирования (например, на основе языка UML).
Сущность в IDEF1X описывает собой совокупность или набор экземп- ляров, похожих по свойствам, но однозначно отличаемых друг от друга по одному или нескольким признакам. Каждый экземпляр является реализацией сущности. Таким образом, сущность в IDEF1X описывает конкретный набор экземпляров предметной области. Примером сущности IDEF1X может быть сущность СТУДЕНТ, свойства которой присущи всем студента университе- та, а один из них, скажем, Иванов Петр Сергеевич, является конкретной реа- лизацией этой сущности. В примере, приведенном на рис. 16, каждый экзем- пляр сущности СТУДЕНТ содержит некоторую информацию.

37
Рисунок 16 – Изображение в диаграмме сущности СТУДЕНТ
В IDEF1X-модели эти свойства называются атрибутами сущности. Ка- ждый атрибут содержит только часть информации о сущности.
Сущность описывается в диаграмме IDEF1X графическим объектом в виде прямоугольника. Каждый прямоугольник, отображающий собой сущ- ность, разделяется горизонтальной линией на часть, в которой расположены атрибуты первичного ключа, и часть, где расположены неключевые атрибу- ты. Верхняя часть называется ключевой областью, а нижняя часть – обла-
стью данных.
Первичный ключ –это набор атрибутов, выбранных для идентификации уникальных экземпляров сущности. Неключевой атрибут – это атрибут, ко- торый не был выбран в качестве ключевого.
В стандарте IDEF1X сущность может быть независимой или зависимой
(рис. 17). Сущность является независимой, если каждый экземпляр сущности может быть однозначно идентифицирован без определения его отношений с другими сущностями.
Рисунок 17 – Сущности в IDEF1X
Сущность называется зависимой, если однозначная идентификация эк- земпляра сущности зависит от его отношения к другой сущности.

38
Сущности могут иметь также внешние ключи (Foreign Key), которые могут использоваться в качестве части или целого первичного ключа или не- ключевого атрибута. Внешний ключ изображается с помощью помещения внутрь блока сущности имен атрибутов, после которых следуют буквы FK в скобках (рис. 18). Сущность, внешний ключ которой является частью пер- вичного ключа, является зависимой сущностью.
Рисунок 18 – Примеры внешних ключей
В стандарте IDEF1X определены типы связей, показанные в табл.
6Идентифицирующая связь между сущностью-родителем и сущностью- потомком изображается сплошной линией. Сущность-потомок в идентифи- цирующей связи является зависимой от идентификатора сущностью. Сущ- ность-родитель в идентифицирующей связи может быть как независимой, так и зависимой от идентификатора сущностью (это определяется ее связями с другими сущностями).
Пунктирная линия изображает неидентифицируемую связь. Сущность- потомок в неидентифицирующей связи будет независимой от идентификато- ра, если она не является также сущностью-потомком в какой-либо иденти- фицирующей связи.
Пунктирная линия изображает неидентифицирующую связь. Сущность- потомок в этой связи будет независимой от идентификатора, если она не яв- ляется также сущностью-потомком в какой-либо идентифицирующей связи.
Рекурсивной является связь между сущностью и ей же самой (в этом случае один или несколько экземпляров сущности ссылаются с помощью внешнего ключа на другой экземпляр той же сущности).