5.6.7.3. Создание физической модели бд и генерация схемы бд

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

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

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

Для задания английсих имен таблиц необходимо воспользоваться радакто-ром таблиц, для остальных манипуляций - редактором колонок. Вызов любого их них можно осуществить при помощи всплывающего меню, представленно­го на рис. 5.6.26.

Диалоговое окно редактора колонок представлено на рис. 5.6.27.

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

Вносить изменения в шаблоны триггеров и хранимых процедур в рассмат­риваемом примере нет необходимости.

Последним шагом является генерация схемы БД. Все необходимые пара­метры можно задать на предназначенной для этого панели диалога (см. рис. 5.6.29). Нажатие кнопки Preview позволяет просмотреть код, который будет автоматически создан ERwin. Генерация схемы БД запускается нажатием кнопки Generate.

Глава 6* Системы, основанные на знаниях 6.1. Знания и их представление

6.1.1. Знания

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

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

1. Увеличение сложности решаемых задач приводит к тому, что программы становятся все сложнее для понимания, и поэтому затрудняется их раз­работка.

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

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

Однако существует класс задач, называемых неформализованными, харак­теризующихся одной или несколькими из следующих особенностей [33]: