4.3. Проектирование физической структуры бд

На этапе проектирования физической структуры БД решается во­прос о способе реализации БД, но после того, как будет определена це­левая СУБД. Целью этого этапа является описание способа физической реализации логической модели, полученной на предыдущем этапе, в среде выбранной СУБД.

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

о

Физическая модель фактически представляет собой ddl -скрипт по созданию объектов в БД: таблиц, описанных в реляционной модели данных, др. объектов (представлений, триггеров, процедур, функций и др.) для реализации необходимых бизнес-правил в среде СУБД. Пример физической модели для создания таблицы Личность представлен ниже:

CREATE TABLE Личность

(

фамилия VARCHAR2( 100) NOT NULL, имя VARCHAR2(80) NOT NULL, отчество VARCHAR2(90) NOT NULL, дата_рождения DATE, место рождения VARCHAR2(100), пол VARCHAR2( 10) NOT NULL, национальность VARCHAR2(30)

);

³ ddl (data definition language) - язык определения данных, используемый для созда­ния, изменения и удаления объектов БД

4.4. Case-средства, используемые при проектировании бд

На сегодняшний день рынок CASE-средств, используемых для проектирования БД, представлен достаточно широко, среди популярных продуктов можно выделить следующие: Computer Associates AllFusion ERwin Data Modeler, Oracle Designer, Microsoft Office Visio, Sybase Pow­er Designer, IDS Prof. Scheer ARIS и др.

Рассмотрим 2 мощных средства, позволяющих выполнить весь процесс проектирования БД от построения концептуальной схемы дан­ных ПрО до создания физической модели БД: Computer Associates All- Fusion ERwin Data Modeler и Oracle Designer.

ERwin Data Modeler

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

] ERwin является мощным и достаточно простым в использовании средством проектирования реляционных БД, завоевавшим широкое признание и популярность.

] На протяжении всего процесса - от логического моделирования требований к информации и бизнес-правилам, которые определяют БД, до оптимизации физической модели в соответствии с заданными харак­теристиками - ERwin позволяет наглядно отобразить структуру и ос­новные элементы БД.

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

] Однако необходимо понимать, что сам по себе ERwin - это по большому счёту лишь удобное средство «рисования» с множеством до­полнительных возможностей, позволяющее зафиксировать и наглядно представить то, что спроектировал пользователь. Использование ERwin (и стандарта IDEF1X в его рамках) само по себе не обеспечивает полу­чение оптимальной схемы БД. Поэтому для эффективного использова­ния данного инструмента необходимо хорошее знание теории проекти­рования реляционных БД.

] В ERwin предусмотрено два типа моделей: логическая и физиче­ская. Логическая модель - это абстрактный взгляд на данные, это КИМПО. Логическая модель данных является универсальной в том смысле что, она никак не связана с конкретной реализацией для вы­

бранной СУБД. Физическая модель - модель БД для конкретной СУБД, которая фактически является отображением системного каталога БД. В физической модели содержится уже информация не об объектах ПрО, а об объектах БД. Одной и той же логической модели могут соответство­вать несколько разных физических моделей.

] ERwin поддерживает стандарт моделирования IDEF1X (Integra­tion DEFinition for Information Modeling). IDEF1X является методом для разработки реляционных БД и использует условный синтаксис, специ­ально разработанный для удобного построения концептуальной схемы. IDEF1X подразумевает использование различных уровней моделирова­ния при проектировании системы.

Клиент

^ Код_клиента
Имя Фамилия Номер паспорта Дата рождения

Предмет_заказа

Код_клиента (FK) Номер заказа (FK) Код_товара

Заказ

•	Г— "Л Код_клиента (FK)
	^ Номер заказа	:
	Исполнитель (FK)
	Дата приёма
	Дата исполнения
чшшштшшшшшшш

Рис. 4.15. Фрагмент полной атрибутивной модели

—1 Логической модели в IDEF1X соответствуют три уровня моделиро­вания, отличающиеся по глубине представления информации о данных: • Диаграмма сущность-связь (Entity-Relationship Diagram (ERD)) - это модель данных верхнего уровня, которая включает сущности и взаимосвязи, отражающие основные бизнес-правила предметной области (рис. 4.13).

Клиент	§ А ~	Заказ	•1

Предмет_заказа

Рис. 4.13. Фрагмент диаграммы сущность-связь

• Модель данных, основанная на ключах (Key-Based Model (КВМ)) - более подробное представление данных, включает описа­ние сущностей и первичных ключей (рис. 4.14).

Клиент Заказ

Предмет_заказа

Рис. 4.14. Фрагмент модели данных, основанной на ключах

Физическая модель в IDEF1X представлена двумя уровнями: • Трансформационная модель (Transformation Model (ТМ)) - мо­дель данных, соответствующая конкретной СУБД. Структуры дан­ных оптимизируются исходя из возможностей СУБД, объёмов дан­ных, предполагаемых схем доступа и интенсивности использования данных (рис. 4.16).

ITEM

^ order_num: NUMBER (FK) ^ customerjd: NUMBER (FK) articlejd: NUMBER

quantity: INTEGER

Рис. 4.16. Фрагмент трансформационной модели

• Модель СУБД (DBMS Model) - содержит определения объек­тов физической структуры БД в схеме СУБД или системном ката­логе БД, напрямую генерируется из ТМ. ERwin непосредственно поддерживает эту модель путём генерации схемы БД. Фактически эта модель представляет собой текст DDL-предложений на языке SQL:

CREATE TABLE CUSTOMER (

id NUMBER NOT NULL,

first name VARCHAR2(20) NULL, lastname CHAR( 18) NULL, passportnum CHAR( 18) NULL, birthday DATE NULL,

PRIMARY KEY (id));

CREATE TABLE ORDER (

id NUMBER NOT NULL,

ordernum NUMBER NOT NULL, makerid NUMBER NULL,

accept date DATE NULL, return date DATE NULL, PRIMARY KEY (id, order num), FOREIGN KEY (id)

REFERENCES CUSTOMER (id));

CREATE TABLE ORDER ITEM (

id NUMBER NOT NULL,

order num NUMBER NOT NULL, articlejd NUMBER NOT NULL, quantity INTEGER NULL,

PRIMARY KEY (order num, id, articlejd), FOREIGN KEY (id, order num)

CUSTOMER ORDER

Ц, id: NUMBER		Д customerjd: NUMBER (FK)] ^ order_num: NUMBER	ф
first_name: VARCHAR2(20) last_name: CHAR(18) passport_num: CHAR(18) birthday: DATE
		makerjd: NUMBER accept_date: DATE return_date: DATE
	•

REFERENCES ORDER (id, order num));

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

Oracle Designer

Oracle Designer - это сложное приложение, реализованное в среде СУБД Oracle, состоящее из 2 частей: серверной и клиентской. Сервер­ная сторона Oracle Designer представляет собой репозитарий (хранили­ще метаданных) и API по управлению репозитарием. Каждый раз, когда выполняется операция добавления, сохранения, удаления и т.д. в одном из инструментов клиентской стороны, изменения посредством API за­носятся в репозитарные таблицы. Для проектирования БД серверная часть не нужна, а необходимо использовать клиентскую часть Oracle Designer. Клиентская сторона продукта - это набор инструментов, включающий несколько диаграммеров, навигаторов, утилит преобразо­вания и генераторов, а также утилиты, поддерживающие все этапы раз­работки системы.

Для проектирования БД используются следующие инструменты Oracle Designer:

] Entity-Relationship Diagrammer - для проектирования КИМПО

и построения диаграммы сущность-связь ] Design Editor - для построения реляционной модели ПрО Фрагмент реляционная модели ПрО вуз представлен на диаграмме, построенной в Design Editor, на рис. 4.17.

J РАС ПИ САН И Е 3АНЯ ТИ И (S

i t 1 1 1 тч # * 7s, но№р_гр/ппы # * А ти п_недели # * А двнь_нвдели # * 78, нсжер_занятия * А дисциплина * А корпус * А аудитория * А и д_преподавателя ^ПРЕПОДАВАТЕЛЬ (Sis s| Mm 1* XI 1-1 * ?8, ид * а фио о ш дата_рождения * А долж ностъ * А кафвдра • • • \/ рН- ^ПОДРАЗДЕЛЕНИЕ (Sis sp
0 1 1 *	XI 1-1
* * А	название
* А	фио_начальника
о А	старшее • • •

V

]]ГРУППА СТУДЕНТОВ (Sis spravochnik)

А

д|ГИТУЛ_УЧЕБНОГО_ПЛАНА (Sis_

1 11*11 Н

Ы 1*1 1 и

^УЧЕБНЫЙ_ПРОЦЕСС (Sis_spravochn
i й	1 1*	1 1-1
# *	78,	и д_ти тул а_учеб ного_пл а на
# *	А	дисциплина
# *	78,	сшестр
# *	А	вид_занятии
*	78,	количество часов • • •

V

А

^СТУДЕНТ (Sis spravochnik)

\

N 1*1 1 1-1

# *	А	номер_3 а *-етной _кни ж к и
*	А	ног/ер_группы
*	А	фио
*	Ш	дата_рождения
*	А	пол
О	А	национальность
*	78,	ти п_фи на нси рэвани я
*	т	дата_за числения
о	Ш1	дата_отчиспения

# *	70,	ид
*	А	кафедра
*	78,	номер_спн_|иальности
*	А	форма_обуиени я
*	?8,	год_при ема
*	78,	срок_обу-ения
о	т	дата_утверж дени я

\/

^СПЕЦИАЛЬНОСТЬ (Sis sp
\ 1*	1 1-1
# * 78,	но1\/ер_по_гос
* А	название
* А	квалификация
О ?8ч	направление
	• • •

т

Рис. 4.17. Пример реляционной модели, построенной в Design Editor

Для получения физической структуры БД в Oracle Designer исполь­зуется утилита Generate Database from Server Model, которая создает ddl_фaйл для генерации объектов БД.