Построение концептуальной модели предметной области

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

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

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

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

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

Одной из распространенных моделей концептуальной схемы является модель «сущность - связь». Основными конструкциями данной модели являются сущности и связи.

Под сущностью понимают основное содержание объекта ПО, о котором собирают информацию. В качестве сущности могут выступать место, вещь, личность, явление.

Экземпляр сущности - конкретный объект.

Например:

сущность (объект) - служащий

экземпляр сущности - Иванов А.В.;

сущность (объект) - институт экземпляр сущности - ТГУ.

Сущность принято определять атрибутами - поименованными характеристиками. Например:

сущность - служащий

атрибуты: ФИО, год рождения, адрес, образование и т.д.

Чтобы задать атрибут в модели, ему надо присвоить имя и определить область допустимых значений. Одно из назначений атрибута - идентифицировать сущность.

Связь определяет отношения между сущностями. Типы связей: один к одному, один ко многим, многие ко многим.

При построении модели «сущность - связь» используют графические диаграммы (рисунок 5.4). При этом обозначают:

сущности - прямоугольниками,

атрибуты - овалами,

связи - ромбами.

Рис. 5.4. Пример модели "сущность - связь"

 

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

Рассмотрим пример проектирования концептуальной схемы. Пусть имеется задание «Спроектировать БД "Сессия"». База данных должна выдавать оперативную информацию об успеваемости студентов на факультетах в семестре. Результатами сессии считать только экзамены.

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

Выберем следующие сущности:

ИНСТИТУТ, ФАКУЛЬТЕТ, СТУДЕНТ, ПРЕПОДАВАТЕЛЬ, ДИСЦИПЛИНА.

В данном примере можно выделить сущность ЭКЗАМЕН или ВЕДОМОСТЬ, но можно не выделять, а сформировать ведомость из имеющихся данных по средствам связей.

Зададим каждую сущность набором атрибутов:

ИНСТИТУТ (название, подчиненность, адрес, телефон, ФИО ректора).

ФАКУЛЬТЕТ (название, код специальности, данные о кафедрах, число выпускников, декан).

СТУДЕНТ (ФИО, группа, курс, номер текущего семестра, пол):

ПРЕПОДАВАТЕЛЬ (ФИО, должность, звание, кафедра, стаж).

ДИСЦИПЛИНА (название, число часов, код дисциплины, виды занятий, число читаемых семестров, номера текущих семестров, на каких курсах преподается)

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

Определим связи между сущностями.

Название связи        Связи между сущностями

учится                          студент, факультет

изучает                        студент, дисциплина

имеет                            институт, факультет

работает                  преподаватель, факультет

преподает                 преподаватель, дисциплина

экзамен                      студент, дисциплина, преподаватель

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

Концептуальная схема БД "Успеваемость» представлена на рисунке 2.5 (атрибуты сущностей на диаграмме не показаны)(рисунок 5.5).

Рассмотрим некоторые ограничения в рассматриваемом примере:

1.  Значение атрибута "телефон" (сущность - ИНСТИТУТ) задается целым положительным шестизначным числом.

2.  Значение атрибута "код факультета" (сущность - ФАКУЛЬТЕТ) лежит в интервале 1-10.

3.  Значение атрибута "курс" (сущность - СТУДЕНТ) лежит в интервале 1-6.

4.  Значение атрибута "семестр" (сущность - СТУДЕНТ, ДИСЦИПЛИНА) лежит в интервале 1-12.

5.  Значение атрибута "число часов" (сущность - ДИСЦИПЛИНА) лежит в интервале 1-300.

6.  Одному студенту может быть приписана только одна группа.

7.  Один студент может учиться только на одном факультете.

8.  Один студент в семестре сдает от 3 до 5 дисциплин.

9.  Один студент изучает в семестре от 6 до 12 дисциплин.

10. Одному преподавателю приписывается только одна кафедра.

11. Один студент может пересдавать одну дисциплину не более трех раз.

12. Ключи: название института, название факультета, ФИО и группа студента, ФИО и кафедра преподавателя, название дисциплины.

В следующем пункте рассмотрим процесс логического проектирования.

 

Рис. 5.5. Концептуальная схема БД «Успеваемость»

 

Логическое проектирование

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

Процесс логического проектирования состоит из следующих этапов:

1.  Выбор конкретной СУБД.

2.  Отображение концептуальной схемы на логическую схему.

3.  Выбор ключей.

4.  Описание языка запросов.

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

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

Отобразим концептуальную схему, изображенную на рисунке 5.5, на реляционную модель. Каждый прямоугольник (сущность) этой схемы будет представлен в виде таблицы. Каждый столбец таблицы предназначен для записи одного атрибута и имеет свое уникальное имя. Представим сущность ПРЕПОДАВАТЕЛЬ (ФИО, должность, звание, кафедра, стаж), в виде таблицы.

 

ПРЕПОДАВАТЕЛЬ

ФИО	Должность	Звание	Кафедра	Стаж

 

Определим структуру каждой таблицы, то есть зададим типы и размеры полей.

Признак ключа	Поле	Тип поля	Размер поля
ключ	ФИО	символьный	21
	Должность	символьный	15
	Звание	символьный	10
ключ	Кафедра	символьный	20
	Стаж	числовой	2

 

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

На хранение одной записи необходимо 21+15+10+20+2=68 байт. Всего предусмотрено 100 записей, то есть на хранение таблицы потребуется 6800 байт.

Аналогично поступают со всеми остальными сущностями (объектами) концептуальной схемы.

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

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

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

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

Логическая модель отражает логические связи между элементами данных вне зависимости от их содержания и среды хранения.

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

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

В современных СУБД выполнение задач физического проектирования автоматизировано.