Порядок работы с SILVERRUN-ВРМ

Необходимо выполнить команду Project → Project Description и ввести название проекта, название организации и название группы разработчиков, кодированное имя.

Cоответственно:

Система обслуживания процесса торговли.

Следует выполнить команду Model → Model Description и ввести название модели (диаграмма процесса торговли), фамилию разработчика (Иванов), кодированное имя SHOP.

Используя панель инструментов, необходимо нарисовать сначала контекстную диаграмму, а затем детализирующую диаграмму. Затем следует сохранить проект в файле.bpm (под именем dealer.bpm).

Для детализирующей диаграммы необходимо создать структуры данных. Для этого выполнить команду Project → Data Structures, заполнить таблицу именами структур – CLIENT, COMPL и DOGOV. Кодированные имена должны повторять название структур.

Для каждой структуры необходимо ввести имена атрибутов и их кодированные имена, а также определить идентификаторы. Для этого следует дважды щелкнуть на кнопки каждой структуры и в открывающемся окне ввести названия атрибутов (в нижних окошках редактирования) и их кодированные имена, а также признак идентификатора. Здесь же необходимо создавать и подструктуры (для DOGOV).

Для ввода кодированных имен и идентификаторов необходимо дважды щелкать на атрибутах.

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

Для этого нужно выполнить команду Project → Data Structures.

Далее следует выбрать имя структуры, щелкнуть на кнопке Data Structures и выбрать строку Stores. В открывающемся окне (снова) щелкнуть на кнопке Stores, выбрать из появившегося списка нужную структуру и щелкнуть на кнопке Link.

Затем необходимо сохранить данные во внутренней библиотеке системы SILVERRUN. Для этого следует выполнить команду Tools → Use WRM Dictionary. Затем выполнить команду File → UpDate WRM Dictionary из окна WRM Dictionary.

File → Save WRM Dictionary

(под именем dealer.wrm)

Затем необходимо сохранить проект в файле.bpm и завершить приложение SILVERRUN-BPM (в файле с именем dealer.bpm).

Использование SILVERRUN-ERX

CASE-инструмент SILVERRUN-ERX используется для построения ER диаграмм проектируемой БД.

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

Создание ER диаграммы являются первым шагом на пути разработки логической диаграммы БД.

Работа с CASE-инструментом SILVERRUN-ERX выполняется в следующем порядке:

После запуска на выполнение программы SILVERRUN-ERX необходимо из словаря данных системы загрузить информацию о всех структурах данных, созданных в SILVERRUN-BPM.

Для этого необходимо выполнить команду Util → WRM Dictionary. В главном меню должен появиться пункт WRM — Dictionary. С помощью этого пункта меню надо открыть словарь, созданный на предыдущем этапе. Для этого выполнить команду

WRM – Dictionary → Open WRM Dictionary

В диалоговом окне выбора файлов необходимо выбрать файл словаря, созданный ранее под именем dealer.wrm.

После этого следует изменить модель для использования ее SILVERRUN-ERX. Для этого необходимо выполнить команду

WRM – Dictionary → UpDate a Model,

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

Далее надо закрыть окно работы со словарем, выполнив команду WRM Dictionary → Close.

Затем необходимо в SILVERRUN–BPM поместить из преобразованной модели все структуры данных БД.

Следует выполнить команду меню Presentation → Pallets → Component: SR Store. Откроется окно с именами всех структур данных, созданных ранее. Щелкая правой кнопкой на каждой структуре данных, необходимо, удерживая кнопку нажатой, перетащить все структуры по очереди в окно SILVERRUN-ERX. Они все будут сосредоточены в центре окна. Поэтому их необходимо растащить и поместить каждую отдельно.

Начиная с этого момента, дальнейшую работу должен выполнять эксперт системы SILVERRUN-ERX. Поэтому необходимо выполнить команду меню Expert → Expert Mode, чтобы начал работу эксперт.

В начале эксперт должен нормализовать разработанную модель. Для этого следует выполнить команду Expert → Normalize Model. В результате действий по нормализации модели диаграмма изменится за счет возможного проявления дополнительных сущностей и связей между ними. Здесь снова необходимо растащить сущности и расположить их в удобном для вас порядке.

Затем разработчик должен осуществить проверку кардинальности связей и степени участия сущностей в связях. Это можно сделать вручную или с помощью эксперта. Но, в последнем случае, эксперт будет задавать вопросы, а разработчик должен на них правильно ответить. Это делается с помощью выполнения команды Expert → Verify Connectivities.

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

Эксперт может также проверить, все ли сущности имеют идентификаторы (ключевые атрибуты). Для этого нужно выполнить команду Expert → Search for Identifiers.

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

После этого всем сущностям и атрибутам необходимо назначить кодированные имена под которыми они будут известны в разрабатываемой БД (латинскими буквами).

Для этого надо дважды щелкать на сущностях и в открывшемся окне заполнять внизу поле “Coded Name” для каждого выделяемого атрибута.

Наконец, необходимо сохранить разработанную модель в.erx файле, выполнив команду меню File → Save Model As (под именем dealer.erx).

Рис. 37. ER диаграмма системы Dealer

На рис.37 показана разработанная с помощью СASE-средства Silverrun-ERX ER диаграмма системы Dealer.

Использование SILVERRUN-RDM

С помощью SILVERRUN-RDM осуществляется создание логической диаграммы проектируемой БД, а также физической диаграммы с учетом конкретной используемой СУБД. Работа завершается созданием сценария, создания разрабатываемой БД на языке SQL. Этот сценарий затем можно выполнить в IBExpert’e и создать все таблицы и их атрибуты для СУБД InterBase.

Порядок работы с CASE-инструментом SILVERRUN-RDM.

Вначале ER модель надо преобразовать в логическую модель. Для этого следует запустить на выполнение приложение ERX-RDM Bridge. Затем следует нажать клавиши Alt-T и в диалоговом окне выбора файлов выбрать.erx файл для разрабатываемой БД (dealer.erx).

Новую модель надо сохранить в.rdm файле (под именем dealer.rdm). Затем необходимо закрыть приложение ERX-RDM Bridge.

Далее следует открыть приложение SILVERRUN-RDM и, выполнив команду меню File → Open, загрузить в него.rdm файл, созданный в предыдущем пункте. При этом будет открыто диалоговое окно выбора СУБД. Выбрать в нем строку IntrBase → IntrBase 4.1.

После загрузки.rdm файла, в окне редактора появится логическая диаграмма БД.

Затем необходимо сгенерировать типы данных (домены) для выбранной СУБД (InterBase).

Необходимо выполнить команду Projects → Target Systems.

В открывшемся окне следует выбрать (выделить) строку “ InterBase 4.1” и щелкнуть на кнопке Generate. Будут сгенерированы все типы доменов для выбранной СУБД.

Чтобы проверить, имеются ли сгенерированные данные, необходимо выполнить команду Projects → Domains. Будет выведен список всех типов данных для применяемой СУБД.

Теперь необходимо каждому атрибуту БД назначить необходимые типы. Необходимо дважды щелкать на таблицах, выбирать по одному атрибуту и в поле Domain вводить необходимые типы. Это удобно делать с помощью кнопки

…

в поле Domain. После щелчка по этой кнопке откроется окно с перечнем возможных типов. Необходимо выделить нужный для данного атрибута тип и щелкнуть на кнопке ОК. Будет выполнен возврат к предыдущему окну, в котором необходимо определить, является ли данный атрибут обязательным к заполнению или нет (поле Null Value Possible), а также длину атрибута типа Char и VarChar.

После этого необходимо сгенерировать внешние ключи для всех таблиц. Необходимо выполнить команду Tools → Foreign Keys → Generate.

Далее следует выбрать в открывшемся окне строку «All Keys» и нажать ОК.

Далее необходимо определить правило для ссылочной целостности (что делать при изменении и удалении родительских записей и главных записей, на которые есть ссылки в зависимых и подчиненных таблицах). Это удобнее сделать с помощью Silverrun-RDM, который установит все правила по умолчанию, которые при необходимости можно будет изменить на этапе разработки приложения.

Для этого необходимо выполнить команду Tools → Generate → Direction Rules.

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

Tools → Generate → Сoded Names.

В открывшемся окне со списком возможных элементов необходимо выделить три строки

Combination (foreign)

Combination (other)

Combination (primary)

и установить для них тип «Partial». После этого необходимо нажать кнопку Generate.

На следующем шаге необходимо проверить целостность разработанной физической модели БД, выполнив команду Tools → Verify Integrity.

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

На следующем шаге надо определить владельца создаваемых таблиц БД.

Выполнить команду Project → Users и ввести имя «Администратор БД» и кодированное имя SYSDBA. Затем щелкать на прямоугольнике с именем каждой таблицы и устанавливать для них с помощью выпадающего списка имя «Администратор БД» в поле «Owner».

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

Далее следует выполнить команду Tools → Target System PlugIns → Forward Engineering.

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

В третьем окне необходимо выбрать слева имя SYSDBA, тогда справа должны появиться имена всех таблиц БД. Далее следует нажать кнопку Generate и сохранить сценарий в файле с необходимым именем (dealer.sql).

Рис. 38. Реляционная диаграмма системы Dealer

На рис. 38 представлена реляционная диаграмма системы Dealer.

Реляционные базы данных и СУБД InterBase

СУБД InterBase, ее основные возможности и область применения

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

В июле 2000 г фирма Borland выпустила версию InterBase 6.0 Open Edition с открытыми исходными кодами. Сразу после этого большая группа профессиональных разработчиков создала проект Firebird с открытыми исходными кодами, который явился первым в новом поколении потомков InterBase. В настоящее время проект Firebird, его разработчики, в группу которых входят добровольцы и наемные специалисты, получающие финансирование из сообщества и коммерческих источников, никак не связан с компанией Borland.

Несмотря на свою простоту, этот сервер сочетает в себе огромный спектр возможностей:

- InterBase является кроссплатформенным продуктом, поддерживающим большое количество различных операционных систем, включая MS Windows всех разновидностей, Linux и несколько Unix-платформ;

- InterBase отличается чрезвычайно низкими системными требованиями и при этом высокой производительностью и легкостью администрирования. С сервером InterBase можно работать, используя несколько сетевых протоколов:TCP/IP, NetBEUI, IPX/SPX;

- одной из основных особенностей сервера InterBase можно считать версионную архитектуру, которая обеспечивает уникальные возможности при многопользовательской работе — пишущие пользователи никогда не блокируют читающих. Версионная архитектура позволяет также отказаться от использования протоколов транзакции (transaction log), которые в других СУБД служат для восстановления БД после сбоев. СУБД InterBase автоматически восстанавливает в таких случаях целостность БД при очередном запуске на выполнение сервера СУБД;

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

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

- некоторые механизмы, такие, например, как двухфазное подтверждение транзакции, до сих пор остаются совершенно уникальными, представленными только в сервере InterBase;

- немаловажной особенностью сервера InterBase является возможность расширения стандартного набора SQL-функций при помощи пользовательских библиотек – UDF (User Defined Function), а так же механизмы обработки BLOB полей (Binary Large Objects) на сервере при помощи BLOB-фильтров;

- InterBase отличается значительной устойчивостью в работе, поскольку специально был спроектирован для применения в InterBase-приложениях, приложениях для мобильных устройств и встроенных приложениях БД;

Имеется семейство серверов InterBase, так как на сегодняшний день существует несколько клонов, основанных на исходном коде Borland InterBase 6.0, Borland InterBase версии 6.0, 6.5 и 7.0, Firebird версии 1.x и Yaffil1.0. Все указанные продукты имеют много общего.

Для работы с InterBase всегда необходимо иметь средство администрирования InterBase. К сожалению, такой инструмент (IBConsole), поставляемый вместе с InterBase, недостаточно надежен и удобен, чтобы пользоваться им для администрирования InterBase, и тем более для разработки БД.

Однако существует множество отличных инструментов сторонних разработчиков, которые удовлетворяют самым изысканным потребностям администраторов и разработчиков БД для СУБД InterBase.

Среди самых известных и популярных можно перечислить IBExpert, Ems Quick-Desk, IBAdmin.

Типы данных

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

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

В InterBase существует 12 типов данных, которые подразделяются на 6 следующих групп:

- для хранения целых чисел – Integer и Smallint;

- для хранения вещественных чисел – Float и Double Precision;

- для чисел с фиксированной точностью;

- для хранения даты, времени и даты / времени – Date, Time и Timestamp;

- для хранения символов – Character (сокращенно Char) и Varying Character (сокращенно Varchar);

- для хранения большого массива данных – BLOB (Binary Large Objects).

Также возможно определять массивы значений всех перечисленных типов, кроме BLOB. Массивы могут иметь несколько размерностей.

Целочисленные типы

К ним относятся Smallint и Integer. Smallint имеет длину 2 байта, Integer – 4 байта.

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

Вещественные типы данных

Это типы для чисел с плавающей точкой – Float и Double Precision. Тип Float имеет недостаточную точность для хранения большинства дробных значений. Не рекомендуется хранить в нем денежные величины – в переменных этого типа очень быстро нарастают ошибки округления, что может сильно удивить бухгалтера при подведении итогов. Поэтому лучшим выбором для хранения чисел в бухгалтерских системах или в системах для научных расчетов будет тип Double Precision.