книги / Основы автоматизации проектирования в строительстве
..pdfИерархическая модель была исторически первой для описа ния данных в БД. В ней структура отражаемых связей между дан ными представляется в виде дерева (рис. 7.1). Дерево или древовид ная структура иерархической модели - это ориентированный граф, не содержащий циклов. В иерархической БД связи направлены только от верхних вершин к нижним. В ориентированном графе вы деляют такие типы вершин, как корень и лист.
Корень - это вершина, имеющая одну или несколько исходя щих дуг (ветвей дерева) и ни одной входящей. Лист - это вершина, имеющая одну или несколько входящих дуг и ни одной исходящей. Вершину графа, не являющуюся ни корнем, ни листом, называют
узлом ветвления.
Корень
/
Рис. 7.1. Иерархическая модель
Основные понятия данной модели: запись (или сегмент) и ие рархические отношения. Сегментом называются вершины дерева. Иерархическое отношение (ветвь дерева) соединяет 2 типа записей: родительской и порожденной и представляет собой множество свя зей между экземплярами записей этих двух типов. В иерархической
структуре связи направлены только от верхних вершин к нижним, обратные связи отсутствуют. Между родительской и порожденны ми записями может существовать отношение - «один ко многим» или «один к одному».
На рис. 7.1. показана типичная иерархическая структура, в ко торой исходный родительский элемент (Фирма А) порождает дру гие элементы (виды продукции), причем эти элементы, в свою оче редь, порождают следующие элементы (технологические схемы TCI, ТС2, ТСЗ), а они соответственно - цены продукции (500, 600, 350, 400, 450).
Достоинства модели: высокая скорость манипулирования дан ными; низкие затраты на реализацию БД.
Недостатки: отсутствие математической основы построения модели; неполнота модели, т.к. не каждая предметная область может быть представлена этой моделью; неравнозначность данных, так как данные на нижних уровнях иерархического дерева подчинены дан ным на верхних уровнях; возможность представления связей только «один к одному» и «один ко многим»; сложность обновления БД.
Примером иерархической структуры в виде дерева служит схема управления большинства организаций.
2.2.Сетевая модель данных
Всетевой модели данные и их связи имеют структуру произ вольного графа. Здесь порожденный узел может иметь два (или бо лее) родительских. Сетевая структура содержит логические связи «один ко многим», «многие к одному», «многие ко многим». Наибо лее известными примерами использования сетевых моделей явля ются сетевые графики, широко применяемые в организации управ ления, или глобальная сеть Интернета. Иллюстрацией этой модели является пример, приведенный на рис. 7.2.
Достоинства модели: возможность эффективной реализации по затратам памяти и оперативности; более высокий уровень пол ноты по сравнению с иерархической моделью.
Недостатки: отсутствие математической теории построения модели; высокая сложность и жесткость БД.
|
|
Завод- |
|
|
|
посгавщпк |
|
Завод- |
---- п р о и з в о д и т Ж/б плиты |
производит |
|
изготовитель |
|
||
|
|
Цевгент |
|
|
входит в |
включает |
|
включает |
в К Л ЮIЧ Э е т |
||
состав |
|||
|
Ариатура |
Бетон |
|
Цех |
|
||
|
I |
||
|
производит |
||
|
включает |
Рабочие |
|
|
I |
|
|
Завод- |
Заполнитель |
|
поставщик |
||
I |
||
|
||
|
поставляют |
Карьеры
Рис. 7.2. Сетевая модель упрощенной БД производства
железобетонных плит
2.3. Реляционная модель данных
Реляционная модель данных является простейшей и наиболее привычной формой представления данных в виде таблицы (или не скольких, связанных между собой таблиц), состоящей из фиксиро ванного числа столбцов и некоторого переменного числа строк (рис. 7.3). Столбцы в реляционной БД принято называть полями (иногда их называют атрибутами объекта), а строки - записями. Поля образуют структуру БД, а записи составляют ту информацию, которая в ней содержится. Каждое поле таблицы имеет свое уни кальное имя и тип данных (см. табл. 7.1). Записи БД могут включать незаполняемые при вводе поля. Их значения могут быть получены в результате выполнения арифметических или других операций.
Такая форма представления данных привычна для специали ста, пользующегося различной справочной литературой, (например СНИПы в строительном проектировании).
Достоинства реляционной модели данных: наличие строгой математической теории построения модели; полнота модели; рав
нозначность данных; сравнительная простота инструментальных средств ее поддержки и обновления.
Недостатки', жесткость структуры данных; запрет дублика тов строк; зависимость скорости работы от размера БД; большие затраты на реализацию модели. Пример реляционной БД приведен на рис. 7.3.
|
|
|
Клиенты |
|
|
|
|
Код клиента |
Наименование |
Г«род |
|
|
|
1 |
Стройпрогресс |
Пермь |
|
|
|
2 |
Завод ЖБК |
|
Ижевск |
|
|
3 |
ЛесБумПром |
|
Витебск |
|
• г |
Заказы |
|
|
|
Код заказа |
Код клиента |
Дата исколи. Сотрудник |
|||
250 |
2 |
|
05.10.06 |
Иванов |
|
251 |
1 |
|
30.10.06 |
Петров |
|
252 |
3 |
|
13.10.06 |
Сидоров |
Рис. 7.3. Реляционная модель данных
В теории множеств таблице соответствует термин отношение (relation), который и дал название модели. Для нее имеется развитый математический аппарат- реляционное исчисление и реляционная алгебра, где для БД определены такие теоретико-множественные операции, как объединение, пересечение, соединение и другие.
Реляционная алгебра позволяет описывать последовательность операций над отношениями (таблицами), а реляционное исчисление - вид выходного документа. Оперирование отношениями предполагает просмотр всех записей в таблицах.
2.4. Ключевые поля и типы связей
Сила реляционных БД заключается в том, что в них можно бы стро найти и связать данные из разных таблиц. Для этого каждая таблица должна содержать одно или несколько полей, однозначно идентифицирующих каждую запись в таблице. Это называется клю чевым полем таблицы или первичным ключом.
Ключ - уникальное имя записи.
Можно выделить три типа ключевых полей:
1.Ключевые поля счетчика можно задать таким образом, что бы при добавлении каждой записи в таблицу в это поле автоматиче ски вносилось порядковое число. При удалении записи это число не восстанавливается, тем самым сохраняется однозначная идентифи кация записей.
2.Простой ключ: если поле содержит уникальные значения, такие как коды или инвентарные номера, то это поле можно опре делить как ключевое.
3.Составной ключ: в случаях, когда невозможно гарантировать уникальность значений каждого поля (например, поля ФАМИЛИЯ), существует возможность создать ключ, состоящий из нескольких по лей (например, ФАМИЛИЯ+ИМЯ+ОТЧЕСТВО).
Бывают и вторичные ключи, которые могут и не быть уникаль ными (т.е. допускаются повторы). Эти ключи служат для организа ции поиска по определенным полям. Например в БД «Адресная книга» поле ТЕЛЕФОН может быть вторичным ключом.
Существует также понятие внешнего ключа. С помощью внеш них ключей устанавливаются связи между таблицами.
Межтабличная связь - отношение, установленное между поля ми (столбцами) двух таблиц. Добавив поле кода из одной таблицы
вдругую (см. рис. 7.3) и определив связь, можно работать с данными из обеих таблиц.
Связи между объектами обусловлены смыслом задачи и не за висят от произвола разработчика БД. Основные типы связей в ре ляционной БД: «один к одному» (1:1); «один ко многим» (1:N); «многие к одному» (N: 1); «многие ко многим» (N:M). При отноше нии «один-к-одному» запись в таблице А может иметь не более одной связанной записи в таблице В, и наоборот (рис. 7.4).
В связи с отношением «один-ко-многим» каждой записи в таблице А могут соответствовать несколько записей в таблице В, а запись в таблице В не может иметь более одной соответствую щей ей записи в таблице А (рис. 7.5).
Таблица А "Сотрудники"
Код |
Фамилия |
Имя |
Отчество |
сотрудника |
|
|
|
---- 1 Иванов |
Сергей |
Петрович |
|
2 |
Петров |
Иван |
Иванович |
3 Михайлова |
Анна |
Николаевна |
|
4 |
Сидоров |
Андрей |
Семенович |
-Каждый руководитель имеет по одной соответствующей записи в таблице "Сотрудн
Табг ица В "Руководители"
од |
Должность |
Стаж |
сот|>;Шинка |
|
|
---- 1 |
Директор |
25 |
3 |
Начальник |
10 |
|
отдела |
|
Рис. 7.4. Пример связи «один-к-одному»
—Один постав иуж...
Таблица А "Поставщики"
Код Поставщик Адрес поставщика
----------- 1 ЖБК-1 |
|
гЛермь... |
|
|
|
|
2 ЖБК-2 |
|
г.Пермь... |
|
|
|
3 Завод СК |
г. Уфа... |
|
|
|
|
...может поставлять несколько товаров - |
|
|||
Таблица В "Товары" |
|
|
|
||
Код |
Наимено Цена |
Кол-во |
Код |
|
|
товара |
вание |
|
поставщика |
н |
|
1 Панели |
500 |
25 |
1 |
||
2 Балки |
200 |
100 |
1 |
||
3 Панели |
500 |
10 |
2 |
|
|
4 Арки |
600 |
20 |
3 |
|
-Но каждый товар имеет лишь одного поставщика.-
Рис. 7.5. Пример связи «один-ко-многим»
В связи «многие-ко-многим» одной записи в таблице А могут соответствовать несколько записей в таблице В, а одной записи в таблице В - несколько записей в таблице А. Такая схема может реализоваться с помощью третьей (связующей) таблицы (рис. 7.6).
Таблица А «Клиенты»
Код |
Клиент |
Адрес |
Дата |
заказа |
|
|
заката |
100 |
Фирма 1 |
г. Москва... |
12.05.2006 |
— 101 |
Завод ЖБК г. Пермь... |
05.08.2006 |
|
102 |
АО "АВС" |
г. Пермь... |
30.12.2006 |
|
— |
Ключ из таблицы «Заказы» |
Заказ может |
|
|- Ключ из таблицы «Товары» |
включать много |
|
|
|
|
|
товаров... |
Код |
Код Кол-во Цена |
|
||
|
заказа |
товара |
10110 5 000р.
Г25
101 |
30 |
5 |
5 |
600р. |
101 |
34 |
20 |
15 |
000р. |
-----*62- |
I-25 |
6 |
3 |
000р. |
...и каждый товар может быть во мнол-tx заказах.
Таблица В «Товары»
Код |
Наименование |
Цена |
говара |
|
|
---- |
25 Бетон |
500р. |
|
26 Цемент |
700р. |
Рис. 7.6. Пример связи «многие-ко-многим»
2.5. Структуризация данных при проектировании реляционных БД
Реляционная модель данных считается в настоящее время наи более перспективной для создания БД САПР. Проектирование ре ляционных БД в основном определяется спецификой проблемы предметной области и включает в себя решение следующих задач:
♦структуризация данных (определение числа и структуры таблиц);
♦формирование запросов к БД;
♦определение типов отчетных документов;
♦разработка алгоритмов обработки информации;
♦создание форм для ввода и редактирования данных в базе. Наиболее важной здесь является проблема структуризации
данных, на ней мы сосредоточим основное внимание.
При проектировании структур данных для автоматизирован ных систем можно выделить три основных подхода:
1.Сбор информации об объектах решаемой задачи в рамках одной таблицы и последующая декомпозиция ее на несколько взаи мосвязанных таблиц на основе процедуры нормализации отношений.
2.Формулирование знаний о системе (определение типов ис ходных данных и их взаимосвязей) и требований к обработке дан ных, получение с помощью CASE-системы (системы автоматиза ции проектирования и разработки БД) готовой схемы БД или даже готовой прикладной информационной системы.
3.Структурирование информации для использования в инфор мационной системе в процессе проведения системного анализа на основе совокупности правил и рекомендаций.
Первый из названных подходов является классическим и исто рически первым, его и рассмотрим на примере построения простей шей БД «Товары - Поставщики - Покупатели». Сведем информацию обо всех объектах: товарах, поставщиках, покупателях в одну табли цу (табл. 7.2). Ключевое поле - Код товара. Информация об адресах поставщика и покупателя в этой таблице не зависит от ключа.
Таблица 7.2
БД «Товар - Поставщик - Покупатель»
Код |
Наимено |
Цена |
Кол-во Поставщик |
Адрес |
Покупатель |
Адрес |
|
товара |
вание |
|
|
|
|
|
|
1 |
Панели |
500 |
25 |
ЖБК-1 |
г.Пермь... Фирма-1 |
г. Москва... |
|
|
|
|
|
|
|
Строит. |
|
2 |
Балки |
200 |
100 |
ЖБК-1 |
г.Пермь... компания |
г. Пермь... |
|
3 |
Панели |
500 |
10 |
ЖБК-2 |
г.Пермь... Фирма-2 |
г. Ижевск... |
|
|
|
|
|
|
|
Строит. |
|
4 |
Арки |
600 |
20 |
Завод СК |
г. Уфа... |
компания |
г. Пермь... |
Следовательно, эту информацию можно выделить в отдельные таблицы: «Поставщики» и «Покупатели». Этот процесс называется нормализацией, он позволяет исключить избыточное дублирование данных. В результате получается три связанных между собой таблицы (рис. 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 Информационные системы — прикладные программы, связанные
с организацией и обработкой информации в БД для решения конкретных задач автоматизации.