Домашнее задание

1. Ознакомится с теоретическими сведениями лекции №27.

2. Ответить на контрольные вопросы.

Контрольные вопросы

1. В каких случаях необходимо использовать семантическое моделирование?

2. История систем автоматизации проектирования баз данных.

3. Подходы к семантическому моделированию.

4. Получение схемы реляционной базы данных из диаграмм классов.

5. Рекомендации, которые тесно связаны со спецификой диаграмм классов.

Тема 2.7.4. Особенности отображения свойств объектов и классов при моделировании баз данных. Моделирование бд. Лекция № 28 (2часа)

Тема: Схемы данных и модельно-ориентированный подход.

Цель: Рассмотреть существующие модели данных, охватывающие различные уровни абстракции при моделировании БД.

Литература:

1. Чен П.П. Модель “сущность-связь” – шаг к единому представлению данных. СУБД, N3, 1995 г.

2. Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем. М., Финансы и статистика, 1998.

3. Фаулер М., Скотт К. UML в кратком изложении. Применение стандартного языка объектного моделирования. М., Мир, 1999.

4. Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на C++. 2-е изд. М., Издательство Бином, СПб., Невский диалект, 1999.

5. Буч Г., Рамбо Д., Джекобсон А. Язык UML: руководство пользователя. М., ДМК, 2000.

Содержание

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

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

• точно отражать структуру предметной области;

• позволять программным приложениям эффективно работать с данными;

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

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

Для хорошего результата применима базовая идея визуального моделирования: разработку ПО удобно проводить как процесс создания уточняющих друг друга моделей. Именно так происходит переход от предметной области к работающему ПО.

Модель "сущность-связь"

При создании структур баз данных принято использовать моделирование, а не сразу писать код, например, на SQL/DDL. Общепринятым способом моделирования структуры данных является модель "сущность-связь", предложенная Петером Ченом еще в 1976 году.

Язык SQL/DDL является промышленным стандартом для задания схемы реляционных баз данных и поддерживается практически всеми промышленными СУБД. Этот язык позволяет описывать таблицы баз данных, задавать их поля, индексы, ключи и так далее.

СУБД (система управления базами данных) - это программное обеспечение, предназначенное для решения задач разработки, хранения и программного доступа к большим массивам данных. Самые известные СУБД - это Oracle, Microsoft SQL Server, MySQL.

Сущность (entity) - это "предмет" рассматриваемой предметной области, который может быть идентифицирован некоторым способом, отличающим его от других "предметов". Конкретные человек, компания или событие являются примерами сущности.

Связь (relationship) - это некоторое отношение между двумя и более сущностями, отражающее то, как они участвуют в общей деятельности, взаимодействуют друг с другом, совместно используются некоторой другой сущностью и т. д.

Рисунок 2.7.2 - Примеры моделей сущность-связь

На рис. 2.7.2 (а) показаны две сущности - "Студент" и "Кафедра", - которые связаны отношением "Принадлежит". Еще точнее будет сказать, что студент принадлежит кафедре. Это пример направленного отношения между двумя сущностями.

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

У сущностей-типов появляются атрибуты, которые аналогичны атрибутам классов в UML, а сами типы сущностей во многом похожи на классы. На рис. 2.7.2(г) показано, какие атрибуты имеют сущности: 1) "Студент" и "Кафедра". Например, ФИО - это набор из трех строк, представляющих фамилию, имя и отчество студента. Номер курса - это атрибут, который имеет диапазон значений от единицы до шести. Атрибут "специальность" имеет значение из некоторого заданного списка специальностей и т. д.

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

Несмотря на простоту модели "сущность-связь", она оказалась мощным инструментом при моделировании баз данных, поскольку ее нотация проста и доступна для восприятия разными специалистами и может, например, служить "мостом" между программистами и аналитиками предметной области. В том виде, в котором эту модель определил Петер Чен, в настоящий момент не применяется - создано большое количество различных нотаций, расширяющих и уточняющих эту модель, например, IDEF1x. Кроме того, многие виды диаграмм UML, не имеющие отношения к моделированию схем баз данных (диаграммы развертывания, диаграммы компонент, диаграммы классов, диаграммы объектов и т. д.), фактически, основываются на модели "сущность-связь", предлагая разработчикам ПО создавать специальные типы сущностей, их атрибуты и связи. Отметим, что диаграммы классов UML могут с успехом использоваться для моделирования схем баз данных (реляционных, объектно-ориентированных, постреляционных и т. д.).

Об уровнях абстракции при моделировании данных

В процессе проектирования схему данных удобно представлять с помощью следующих моделей:

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

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

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

Рисунок 2.7.3 - Различные модели данных

Далее следует реализация схемы данных в виде:

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

• "живой" базы данных, получаемой как результат исполнения средствами некоторой СУБД программы, задающей схему (SQL/DDL-скрипта); создается электронное хранилище, которое реализует доступ к данным со стороны программных приложений, а также обеспечивает сохранение данных после окончания работы приложения и выключения компьютера - это свойство данных обычно называют персистентностью (persistent).