Создание базы данных для оценки радиационной обстановки в зоне расположения АЭС

 Для  атрибутов первичного ключа в  закладке General диалога Attribute Editor необходимо сделать пометку в окне выбора Primary Key.

 Закладки  Definition, Note и UDP несут те же функции, что и при определении сущности, но на уровне атрибутов.

 Для  большей наглядности диаграммы  каждый атрибут можно связать  с иконкой. Это можно сделать  при помощи списка выбора Icon в закладке General.

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

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

Результат работы показан на рисунке 2.2.

 

 

Рис.2.2. Логическая схема на уровне атрибутов.

 

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

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

Созданная логическая схема отображена на рисунке 2.3.

Рис.2.3. Логическая схема базы данных оценки радиационной обстановки.

 

 

Раздел 3. 
СОЗДАНИЕ ФИЗИЧЕСКОЙ СХЕМЫ БАЗЫ ДАННЫХ

 

3.1. Уровни физической модели.  

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

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

Физическая  модель содержит всю информацию, необходимую  для реализации конкретной БД. Различают два уровня физической модели:

– трансформационную  модель;

– модель СУБД.

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

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

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

3.2. Выбор сервера.

Целевая СУБД в Erwin указывается при создании новой модели (рисунок 3.1).

Рис. 3.1.Создание новой модели

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

Следует отметить, что Erwin позволяет генерировать и настольные (Desktop) СУБД, и "тяжелые", сетевые (рисунок 3.2).

 

 

Рис. 3.2. Создание модели в Erwin

3.3. Создание правил валидации.

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

 Если  щелкнуть по кнопке  , расположенной справа от раскрывающегося списка Valid , появляется диалог Validation Rule Editor, который служит для задания правил валидации. В нем можно задать максимальное и минимальное значение и тип валидации (где проверять - на сервере или в клиентском приложении).

Валидация через тип UserDefined (рисунок 3.3) осуществляется вводом выражения, соблюдая синтаксис выбранной СУБД. По умолчанию ERwin создает выражение - команду языка СУБД, используя значения, связанные с правилом валидации, и разделяя значения запятыми (например, С, D, М). В некоторых случаях правила синтаксиса СУБД требуют, чтобы каждое значение в команде заключалось в одинарные кавычки ('С', 'D', 'M').

Рис. 3.3. Валидация через тип UserDefined

 

Валидация через тип Min/Max (рисунок 3.4) осуществляется указанием минимального и максимального значения для заданного поля.

Рис. 3.4. Валидация через тип Min/Max

Редактор  Valid Value (рисунок 3.5) позволяет создавать список всех допустимых значений, которые можно хранить в колонке, и связать его с правилом валидации.

Рис. 3.5. Валидация через тип ValidValueList

 

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

Рис. 3.6. Присвоение колонке правила валидации

3.4. Создание представления по таблицам.

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

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

Рис. 3.7. Использование  механизма представлений.

 

Для упрощения  выборки данных создадим SQL-запросы:

 

CREATE VIEW V_13 AS SELECT Radionuklid.ID_radionuklida, Nacelennui_punkt.ID, Radionuklid.Nazvanie, Nacelennui_punkt.ID_nacelen_punkta, Nacelennui_punkt.Nazvanie,Nacelennui_punkt.PDK

FROM Radionuklid,Nacelennui_punkt

WHERE Radionuklid='Уран'

GROUP BY Nacelennui_punkt.PDK

HAVING Count(*)<200

;

CREATE PROCEDURE Uran AS

 

CREATE VIEW V_15 AS SELECT Facticheckoe_izmerenie.ID, Facticheckoe_izmerenie.Data,Facticheckoe_izmerenie.Vremj, 
Facticheckoe_izmerenie.Metod_kontrolj

FROM Facticheckoe_izmerenie, Dopuctimaj_doza,  
Nacelennui_punkt

WHERE Radionuklid='Торий'

GROUP BY Nacelen_punkt='Энергодар'

HAVING Count(*)=100

;

CREATE PROCEDURE Uran AS

 

CREATE VIEW V_16 AS SELECT Facticheckoe_izmerenie.ID, Facticheckoe_izmerenie.Data,  
Facticheckoe_izmerenie.Vremj,Facticheckoe_izmerenie.Metod_kontrolj

FROM Facticheckoe_izmerenie, Tochka_kontrolj,  
Reglament_kontrolj

WHERE Radionuklid='Уран'

GROUP BY Data='15/04/12'

HAVING Count(*)>100

;

CREATE PROCEDURE Uran AS

3.4. Категориальная связь.

Категориальная  связь - дочерняя сущность в иерархии наследования.

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

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

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

Иерархии  категорий делятся на два типа - полные и неполные. В полной категории  одному экземпляру родового предка (сущность Служащий) обязательно соответствует экземпляр в каком-либо потомке, т. е. в примере служащий обязательно является либо совместителем, либо консультантом, либо постоянным сотрудником.

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

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

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

 

ВЫВОДЫ

 

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

ИСПОЛЬЗОВАННЫЕ ИСТОЧНИКИ

 

 

Литература.

 

1. Маклаков C.В. BPWin и ERWin. Case-средства разработки информационных систем. М.: Диалог, 1999 – 438с;
2. Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем. -М.: Финансы и статистика, 1998. -176 с.
3. Методические материалы.

 

 

On-line.

 

4. http://www.sql.ru - Обсуждение вопросов, связанных с SQL Server;
5. http://max.program.ru/stats/case/case.html - практикум разработки информационных систем;