книги / Основы автоматизации проектирования в строительстве

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

Корень - это вершина, имеющая одну или несколько исходя­ щих дуг (ветвей дерева) и ни одной входящей. Лист - это вершина, имеющая одну или несколько входящих дуг и ни одной исходящей. Вершину графа, не являющуюся ни корнем, ни листом, называют

узлом ветвления.

Корень

/

Рис. 7.1. Иерархическая модель

Основные понятия данной модели: запись (или сегмент) и ие­ рархические отношения. Сегментом называются вершины дерева. Иерархическое отношение (ветвь дерева) соединяет 2 типа записей: родительской и порожденной и представляет собой множество свя­ зей между экземплярами записей этих двух типов. В иерархической

структуре связи направлены только от верхних вершин к нижним, обратные связи отсутствуют. Между родительской и порожденны­ ми записями может существовать отношение - «один ко многим» или «один к одному».

На рис. 7.1. показана типичная иерархическая структура, в ко­ торой исходный родительский элемент (Фирма А) порождает дру­ гие элементы (виды продукции), причем эти элементы, в свою оче­ редь, порождают следующие элементы (технологические схемы TCI, ТС2, ТСЗ), а они соответственно - цены продукции (500, 600, 350, 400, 450).

Достоинства модели: высокая скорость манипулирования дан­ ными; низкие затраты на реализацию БД.

Недостатки: отсутствие математической основы построения модели; неполнота модели, т.к. не каждая предметная область может быть представлена этой моделью; неравнозначность данных, так как данные на нижних уровнях иерархического дерева подчинены дан­ ным на верхних уровнях; возможность представления связей только «один к одному» и «один ко многим»; сложность обновления БД.

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

2.2.Сетевая модель данных

Всетевой модели данные и их связи имеют структуру произ­ вольного графа. Здесь порожденный узел может иметь два (или бо­ лее) родительских. Сетевая структура содержит логические связи «один ко многим», «многие к одному», «многие ко многим». Наибо­ лее известными примерами использования сетевых моделей явля­ ются сетевые графики, широко применяемые в организации управ­ ления, или глобальная сеть Интернета. Иллюстрацией этой модели является пример, приведенный на рис. 7.2.

Достоинства модели: возможность эффективной реализации по затратам памяти и оперативности; более высокий уровень пол­ ноты по сравнению с иерархической моделью.

Недостатки: отсутствие математической теории построения модели; высокая сложность и жесткость БД.

Карьеры

Рис. 7.2. Сетевая модель упрощенной БД производства

железобетонных плит

2.3. Реляционная модель данных

Реляционная модель данных является простейшей и наиболее привычной формой представления данных в виде таблицы (или не­ скольких, связанных между собой таблиц), состоящей из фиксиро­ ванного числа столбцов и некоторого переменного числа строк (рис. 7.3). Столбцы в реляционной БД принято называть полями (иногда их называют атрибутами объекта), а строки - записями. Поля образуют структуру БД, а записи составляют ту информацию, которая в ней содержится. Каждое поле таблицы имеет свое уни­ кальное имя и тип данных (см. табл. 7.1). Записи БД могут включать незаполняемые при вводе поля. Их значения могут быть получены в результате выполнения арифметических или других операций.

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

Достоинства реляционной модели данных: наличие строгой математической теории построения модели; полнота модели; рав­

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

Недостатки', жесткость структуры данных; запрет дублика­ тов строк; зависимость скорости работы от размера БД; большие затраты на реализацию модели. Пример реляционной БД приведен на рис. 7.3.

Рис. 7.3. Реляционная модель данных

В теории множеств таблице соответствует термин отношение (relation), который и дал название модели. Для нее имеется развитый математический аппарат- реляционное исчисление и реляционная алгебра, где для БД определены такие теоретико-множественные операции, как объединение, пересечение, соединение и другие.

Реляционная алгебра позволяет описывать последовательность операций над отношениями (таблицами), а реляционное исчисление - вид выходного документа. Оперирование отношениями предполагает просмотр всех записей в таблицах.

2.4. Ключевые поля и типы связей

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

Ключ - уникальное имя записи.

Можно выделить три типа ключевых полей:

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

2.Простой ключ: если поле содержит уникальные значения, такие как коды или инвентарные номера, то это поле можно опре­ делить как ключевое.

3.Составной ключ: в случаях, когда невозможно гарантировать уникальность значений каждого поля (например, поля ФАМИЛИЯ), существует возможность создать ключ, состоящий из нескольких по­ лей (например, ФАМИЛИЯ+ИМЯ+ОТЧЕСТВО).

Бывают и вторичные ключи, которые могут и не быть уникаль­ ными (т.е. допускаются повторы). Эти ключи служат для организа­ ции поиска по определенным полям. Например в БД «Адресная книга» поле ТЕЛЕФОН может быть вторичным ключом.

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

Межтабличная связь - отношение, установленное между поля­ ми (столбцами) двух таблиц. Добавив поле кода из одной таблицы

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

Связи между объектами обусловлены смыслом задачи и не за­ висят от произвола разработчика БД. Основные типы связей в ре­ ляционной БД: «один к одному» (1:1); «один ко многим» (1:N); «многие к одному» (N: 1); «многие ко многим» (N:M). При отноше­ нии «один-к-одному» запись в таблице А может иметь не более одной связанной записи в таблице В, и наоборот (рис. 7.4).

В связи с отношением «один-ко-многим» каждой записи в таблице А могут соответствовать несколько записей в таблице В, а запись в таблице В не может иметь более одной соответствую­ щей ей записи в таблице А (рис. 7.5).

Таблица А "Сотрудники"

-Каждый руководитель имеет по одной соответствующей записи в таблице "Сотрудн

Табг ица В "Руководители"

Рис. 7.4. Пример связи «один-к-одному»

—Один постав иуж...

Таблица А "Поставщики"

Код Поставщик Адрес поставщика

-Но каждый товар имеет лишь одного поставщика.-

Рис. 7.5. Пример связи «один-ко-многим»

В связи «многие-ко-многим» одной записи в таблице А могут соответствовать несколько записей в таблице В, а одной записи в таблице В - несколько записей в таблице А. Такая схема может реализоваться с помощью третьей (связующей) таблицы (рис. 7.6).

Таблица А «Клиенты»

10110 5 000р.

Г25

...и каждый товар может быть во мнол-tx заказах.

Таблица В «Товары»

Рис. 7.6. Пример связи «многие-ко-многим»

2.5. Структуризация данных при проектировании реляционных БД

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

♦структуризация данных (определение числа и структуры таблиц);

♦формирование запросов к БД;

♦определение типов отчетных документов;

♦разработка алгоритмов обработки информации;

♦создание форм для ввода и редактирования данных в базе. Наиболее важной здесь является проблема структуризации

данных, на ней мы сосредоточим основное внимание.

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

1.Сбор информации об объектах решаемой задачи в рамках одной таблицы и последующая декомпозиция ее на несколько взаи­ мосвязанных таблиц на основе процедуры нормализации отношений.

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

3.Структурирование информации для использования в инфор­ мационной системе в процессе проведения системного анализа на основе совокупности правил и рекомендаций.

Первый из названных подходов является классическим и исто­ рически первым, его и рассмотрим на примере построения простей­ шей БД «Товары - Поставщики - Покупатели». Сведем информацию обо всех объектах: товарах, поставщиках, покупателях в одну табли­ цу (табл. 7.2). Ключевое поле - Код товара. Информация об адресах поставщика и покупателя в этой таблице не зависит от ключа.

Таблица 7.2

БД «Товар - Поставщик - Покупатель»

Следовательно, эту информацию можно выделить в отдельные таблицы: «Поставщики» и «Покупатели». Этот процесс называется нормализацией, он позволяет исключить избыточное дублирование данных. В результате получается три связанных между собой таблицы (рис. 7.7).

Рис. 7.7. Нормализация таблицы данных

Таблица 1 называется оперативной, а 2 и 3 - справочными.

Информация в оперативной таблице меняется часто, а в справоч­ ных - редко. Таблица 1 связана с таблицей 2 по полю Код постав­ щика, а с таблицей 3 - по полю Код покупателя. Поле Код постав­ щика является первичным ключом для таблицы 2 и внешним ключом

для таблицы 1. Кроме того, таблица 1 имеет собственный первичный ключ Код товара. Каждому значению первичного ключа в таблице 2

(и 3) соответствуют несколько (или ни одной) записей в таблице 1 (связь «один-ко-многим»).

Такая структура обеспечивает требования неизбыточности и це­ лостности реляционной БД.

§2. С и с т е м ы у п р а в л е н и я б а з а м и д а н н ы х (СУБД)

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

1. История СУБД

Начало СУБД для ПЭВМ положила фирма Ashton Tate (США) выпуском в 1980 году программы dBase.

Далее начали появляться dBase-подобные СУБД: Ребус, Ка­ рат, FoxPro, Clipper (версий и адаптированных вариантов гораздо больше). Общее для всех этих программ: формат представления данных (-dbf), работа с реляционными БД. Но командный язык, а также формат индексных файлов у них разный. Эти программы эпохи ОС MS-DOS.

Несколько позднее появились программы управления дан­ ными: Paradox, Clarion, db-Vista, имеющие другие форматы дан­ ных и вначале разрабатываемые под ОС MS-DOS, но после появ­ ления операционной системы Windows эти СУБД были переписа­ ны под нее.

Параллельно развивалась операционная система UNIX и СУБД под управлением этой ОС: Informix, Oracle, Progres, SyBase, Ingres

и другие. В основе этих СУБД лежит объектно-ориентированный язык управления данными - 4GL, 5GL.

7 Информационные системы — прикладные программы, связанные

с организацией и обработкой информации в БД для решения конкретных задач автоматизации.