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

Модели данных - интегрированный набор понятий для описания данных, связей между ними и ограничений, накладываемых на данные в некоторой организации./11/

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

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

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

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

Цель построения модели данных заключается в представлении данных в понятном виде. Если такое представление, возможно, то модель данных можно будет легко применить при проектировании базы данных./11/

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

Иерархическая модель данных - модель, объединяющая записи, хранимые в общей древовидной структуре с одним корневым типом записи, который имеет нуль или больше подчиненных типов записей. Каждый подчиненный тип записи также может иметь нуль или больше подчиненных типов записей./11/

Как следует из названия, данные в этой модели структурированы иерархически. /12/

Размещено на http://www.allbest.ru/

Рис.2.1.1 Пример фрагмента иерархической схемы

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

Рис.2.1.2 Пример фрагмента сетевой схемы

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

Указанный недостаток снят в сетевой модели, где, по крайней мере, теоретически возможны связи «всех со всеми». Поскольку на практике это, естественно, невозможно, приходится прибегать к некоторым ограничениям. Использование иерархической и сетевой моделей ускоряет доступ к информации в базе данных. Но поскольку каждый элемент данных должен содержать ссылки на некоторые другие элементы, требуются значительные ресурсы как дисковой, так и основной памяти ЭВМ. Недостаток основной памяти, конечно, снижает скорость обработки данных. Кроме того, для таких моделей характерна сложность реализации СУБД.

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

Реляционная модель впервые была предложена Э.Ф.Коддом (E.F.Codd) в 1970 году в его основополагающей статье «Реляционная модель данных для больших совместно используемых банках данных». В настоящее время публикацию этой статьи принято считать поворотным пунктом в истории развития систем баз данных, хотя следует заметить, что еще раньше была предложена модель, основанная на множествах (Childs, 1968). Цели создания реляционной модели формулировались следующим образом.

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

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

Реляционная модель организации данных занимает доминирующее положение на рынке программных продуктов. Это, например, такие пакеты, как dBASEIY, FoxPro и Clipper-5./11/

Для представления модели можно использовать один из популярных программных продуктов Computer Associates BPwin, версия 4.0

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

BPwin поддерживает три методологии: IDEF0, DFD и IDEF3, позволяющие анализировать бизнес с трех ключевых точек зрения:

· функциональности системы (в рамках методологии IDEF0 (Integration Definition for Function Modeling) бизнес-процесс представляется в виде набора элементов-работ, которые взаимодействуют между собой);

· потоков информации в системе (диаграммы DFD (Data Flow Diagramming) могут дополнить то, что уже отражено в модели IDEF0, поскольку они описывают потоки данных, позволяя проследить, каким образом происходит обмен информацией между бизнес-функциями внутри системы);

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

Для рассмотрения бизнес-процессов блока «Учет недроиспользования» необходимо использовать методологию IDEF0.

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

В диаграмме по ведению учета недропользования рассматривается процесс сбора, обработки и хранения информации. Все это отражается в диаграмме IDEF0 «Учет недропользования» (см. рис.1 прил. 2).

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

· Обработка информации (распределение ресурсов, получение заявки на разработку недр) (см. рис.3 прил. 2);

· Хранение информации (занесение информации в базу данных, сортировка и каталогизация) (см. рис.4 прил. 2);

· Контроль (получение заявок от соискателя на разработку недр) (см. рис.5 прил. 2);

· Статистика (подведение итогов, решение о разработке недр) (см. рис.6 прил. 2);

2.2 Проектирование пользовательского интерфейса