entrant

PK id

name second_name surname birth_date birth_place

FK2 distinction_id FK1 citizen_id

FK3 education_id sex

rem original mod_date mod_user

	shapki
PK	id
	name
	shapki_order
	brief							pre_command
								PK,FK1		entrant_id
								PK,FK2		prog_id
										ball
										mod_date
			command							mod_user
										saved
				id
		FK1		entrant_id
		FK2		prog_id
		FK3		shapki_id
				ball
				saved
				mod_date
				mod_user

priority

PK,FK1 entrant_id

PK,FK2 prog_id

priority mod_date mod_user

exam

PK id

FK3 subj_id exam_date

FK1 exam_forma_id FK2 faculty_id

mark

FK1 entrant_id FK2 exam_id mark

mod_date mod_user

Рис. 27. Ообщий вид ER-диаграммы

plan

FK1 program_id quantity

	program
PK	id
	brief
FK2	faculty_id
FK3	spec_id
FK1	branch_id
	full

2.9. Ограничения целостности

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

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

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

82

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

Соответствующие ограничения можно разделить на две группы.

1.Внешние ограничения.

Эти ограничения связаны с адекватностью отражения предметной областью. Например, сотрудник организации не может быть моложе 17 и старше 90 лет. Соответствующее ограничение на год рождения (GR) можно записать следующим образом.

ТЕКУЩИЙ ГОД – 17 > GR > ТЕКУЩИЙ ГОД – 90.

Одним из способов задания таких ограничений является перечисление конечного множества допустимых значений какого-либо атрибута (так называемый «перечислимый» тип данных).

Например, должность преподавателя в вузе может принимать одно из следующих значений: ПРОФЕССОР, ДОЦЕНТ, СТАРШИЙ ПРЕПОДАВАТЕЛЬ, ПРЕПОДАВАТЕЛЬ, АССИСТЕНТ. Вводимое значение должности для конкретного экземпляра, не совпадающее с одним из перечисленных значений, является ошибкой.

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

стности, атрибуты ЧИСЛО МУЖЧИН, ЧИСЛО ЖЕНЩИН, ЧИСЛО ЛИЦ ОБЕИХ ПОЛОВ (по разным возрастным группам, по разным регионам и т.п.) Для контроля достоверности вводимых данных можно использовать следующую формулу.

ЧИСЛО ЛИЦ ОБЕИХ ПОЛОВ = ЧИСЛО МУЖЧИН + ЧИСЛО ЖЕНЩИН

Если равенство не достигается, какое-то из введенных чисел недостоверно.

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

83

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

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

2.10. Средства автоматизированного проектирования концептуальной модели

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

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

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

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

84

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

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

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

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

средств (Computer Aided Software/System Engineering). Конечно, соз-

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

При сопровождении все повторяется, за тем исключением, что генерируется не все приложение целиком, а только часть, которую надо изменять.

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

85

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

В настоящее время практически каждый производитель СУБД предлагает собственное программный продукт автоматизированного проектирования. Это Oracle Designer (Oracle), PowerDesinger (Sybase) и

другие. Демонстрационные версии данных программных продуктов можно загрузить с соответствующих сайтов (www.oracle.com, www.sybase.com).

Кроме того, на рынке представлены решения третьих фирм, не производящих СУБД. Одними из самых распространенных являются программные продукты фирмы AllFusion – AllFusion ERwin Data Modeler и AllFusion Process Modeler (ранее BPwin) и другие. На рос-

сийском рынке данные программы предлагает фирма Interface Ltd. (www.interface.ru). Программа AllFusion Process Modeler предназначе-

на для моделирования бизнес-процессов. Результатами ее работы могут быть не только диаграммы, но и сгенерированный для различных сред код для доступа к базам данных. Для этого, однако, необходимо еще создать диаграммы «сущность-связь» с помощью AllFusion ERwin Data Modeler.

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

По данным Interface Ltd. AllFusion ERwin Data Modeler (ранее: ERwin) позволяет проектировать, документировать и сопровождать базы данных, хранилища данных и витрины данных (data marts).

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

На сайте Interface Ltd. (www.interface.ru) доступна для загрузки демонстрационная версия AllFusion ERwin Data Modeler, которая представляет собой полнофункциональную версию, ограниченную по времени.

Основные характеристики AllFusion ERwin Data Modeler:

Поддержка различных способов записи диаграмм «СущностьСвязь» (нотаций).

86

Нотация диаграмм «Сущность-Связь» в AllFusion ERwin Data Modeler несколько отличается от нотации классических моделей «сущность-связь».

Эти отличия проявляются, прежде всего, в отсутствии атрибутов у связи. Наличие атрибутов у связи при классическом способе записи свидетельствует, что внутри связи скрыта некоторая сущность. В нотациях, используемых в AllFusion ERwin Data Modeler, связь не может иметь атрибутов, и изображается в виде линии, а ее название пишется выше и/или ниже линии.

Атрибуты внутри сущности в AllFusion ERwin Data Modeler разделяются на две группы линией. Ключевые атрибуты находятся сверху черты, остальные атрибуты снизу.

Сильная сущность обозначается прямоугольником с прямыми углами, слабая сущность – прямоугольником с закругленными углами. Идентифицирующая связь – сплошная линия, не идентифицирующая – прерывистая.

Поддержка проектирования информационных хранилищ. Поддержка совместного проектирования.

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

Автоматическая генерация SQL DDL для создания баз данных. Полная совместимость и поддержка 20-ти типов СУБД.

Приведем в качестве примера использования данного CASEсредства диаграмму «Сущность-Связь» фрагмента базы данных абитуриентов. В сущности entrant сохраняются анкетные данные об абитуриентах (entrant). Помимо этой сущности на диаграмме приведены сущности-справочники: виды предшествующего образования (education), данные о гражданстве (citizenship), а также данные о наличии у абитуриента золотой или серебряной медали или диплома с отличием (distinction). Сущности связаны между собой связью «имеет». Абитуриент имеет предшествующее образование, гражданство и данные об отличии диплома или аттестата.

На рисунках 28 и 29 приведены диаграммы «Сущность-Связь» на логическом и физическом уровне. Разделение на уровни используется в ERwin для удобства – на самом деле диаграмма одна, однако в зави-

87

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

education

код	entrant
	код
название
	имя
	отчество
	фамилия
	дата рождения	distinction
	место рождения
	код образования (FK)	код
	код отличия (FK)	название
	код гражданства (FK)
	пол
citizenship	примечание
код	оригинал документа
	дата модификации
название
	пользователь

Рис. 28. Логический уровень ER-диаграммы

education

id: NUMERIC(10,0)

name: VARCHAR(100)

citizenship

id: NUMERIC(10,0)

name: VARCHAR(50)

entrant

id: NUMERIC(10,0)

name: VARCHAR(15) second_name: VARCHAR(20) surname: VARCHAR(20) birth_date: DATE

birth_place: VARCHAR(20)

education_id: NUMERIC(10,0) distinction_id: NUMERIC(10,0)

citizen_id: NUMERIC(10,0) sex: VARCHAR(1)

rem: VARCHAR(200) original: VARCHAR(1) mod_date: DATE mod_user: VARCHAR(50)

distinction

id: NUMERIC(10,0)

name: VARCHAR(20)

Рис. 29. Физический уровень ER-диаграммы

88

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

На физическом уровне диаграмма будет выглядеть по-разному в зависимости от того, для какого сервера баз данных будет использоваться данная модель, и, соответственно, какие типы данных есть в данной СУБД. Приведенная на рисунке 29 диаграмма построена для СУБД Oracle 8.0.

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

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

…
CREATE TABLE education (	VARCHAR(100) NULL,
name
id	NUMERIC(10,0) NOT NULL,
PRIMARY KEY (id)
);
CREATE TABLE distinction (	VARCHAR(20) NOT NULL,
name
id	NUMERIC(10,0) NOT NULL,
PRIMARY KEY (id)
);
CREATE TABLE citizenship (	VARCHAR(50) NOT NULL,
name
id	NUMERIC(10,0) NOT NULL,
PRIMARY KEY (id)
);
CREATE TABLE entrant (	VARCHAR(15) NOT NULL,
name
id	NUMERIC(10,0) NOT NULL,
second_name	VARCHAR(20) NULL,
surname	VARCHAR(20) NOT NULL,

89

birth_date	DATE NULL,
birth_place	VARCHAR(20) NULL,
education_id	NUMERIC(10,0) NOT NULL,
distinction_id	NUMERIC(10,0) NOT NULL,
citizen_id	NUMERIC(10,0) NOT NULL,
sex	VARCHAR(1) NOT NULL,
rem	VARCHAR(200) NULL,
original	VARCHAR(1) NOT NULL,
mod_date	DATE NULL,
mod_user	VARCHAR(50) NULL,

PRIMARY KEY (id),

FOREIGN KEY (education_id)

REFERENCES education, FOREIGN KEY (distinction_id)

REFERENCES distinction, FOREIGN KEY (citizen_id)

REFERENCES citizenship

);

…

Окончание скрипта не приведено.

CASE средство ERwin Data Modeler в совокупности с AllFusion Process Modeler и другими продуктами фирмы AllFusion представляет стандартные возможности, характерные и для других CASE средств,

таких как Oracle Designer и PowerDesigner (Sybase).

90