Организация информационного фонда на ЭВМ с использованием баз данных

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

Пример. Разработка фрагмента модели данных «Сотрудники – проекты». Пусть речь идет о технологической службе предприятия, сотрудники которой, занимаясь технологической подготовкой производства, естественным образом участвуют в разработке проектов некоторых изделий. Исходные данные по сотрудникам представлены в так называемой сплошной таблице – см. табл. 13.1.

Таблица 13.1

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

1. Дублируется информация о сотрудниках, т.к. сотрудник может участвовать в нескольких проектах.

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

3. Если сотрудник увольняется, запись о нем удаляется из таблицы, а вместе с ней – и проект, хотя работа над ним должна продолжаться.

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

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

Чтобы устранить указанные выше недостатки, разобьем исходную таблицу на две: «Проекты» и «Сотрудники» - табл. 13.2 и 13.3.

Таблица 13.2

Таблица 13.3

Продолжим анализ и посмотрим на таблицу «Сотрудники». Несложно заметить следующие особенности:

1. Дублируется информация о телефонах для сотрудников одного отдела.

2. Если изменяется телефон отдела, необходимо изменять его у всех сотрудников отдела. Аналогичная ситуация будет наблюдаться при изменении размера окладов.

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

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

Поэтому, следуя правилам нормализации, необходимо выполнить декомпозицию таблицы «Сотрудники» и разбить ее на три таблицы: «Сотрудники», «Должности», «Отделы» - табл.13.4, 13.5, 13.6.

Таблица 13.4

Таблица 13.5

Таблица 13.6

Т.е окончательно сформированы четыре связанные между собой таблицы: «Проекты», «Сотрудники», «Должности» и «Отделы».

Покажем теперь логику представления фрагмента данных в БД «Режущие инструменты», а более подробно в ее разделе «Сверла». Информация о сверлах берется из справочника – см. табл.13.7.

Таблица 13.7

Общая структура данных показана на рис. 13.1.

Рис.13.1. Общая структура данных БД «Режущие инструменты»

После определения типа данных (здесь применяется два типа данных: «текстовый» - обозначен ниже буквами «С» и «числовой» - буквами «N») и длины полей получается логическая модель данных – рис. 13.2.

Рис.13.2. Логическая модель данных в БД «Режущие инструменты» в разделе «Сверла»

Ввиду того, что львиная доля работы по проектированию технологических процессов приходится на работу с данными и при этом перерабатывается очень большое количество информации, ряд САПР ТП построено на основе имеющихся СУБД. Это значительно облегчает создание прикладного программного обеспечения САПР. Так, например, САПР ТП «Техно/Про» построена на базе уже упоминавшейся СУБД Microsoft Access. Информация об этом мощном приложении изложена в специальной литературе и требует отдельного изучения, что не входит в рамки данной дисциплины. Отметим только, что физическое представление данных на диске в данной СУБД организуется в виде одного общего файла, файла базы данных, который имеет расширение .mdb.

Рис.13.1. Общая структура данных БД «Режущие инструменты»

После определения типа данных (здесь применяется два типа данных: «текстовый» - обозначен ниже буквами «С» и «числовой» - буквами «N») и длины полей получается логическая модель данных – рис. 13.2.

Рис.13.2. Логическая модель данных в БД «Режущие инструменты» в разделе «Сверла»

Ввиду того, что львиная доля работы по проектированию технологических процессов приходится на работу с данными и при этом перерабатывается очень большое количество информации, ряд САПР ТП построено на основе имеющихся СУБД. Это значительно облегчает создание прикладного программного обеспечения САПР. Так, например, САПР ТП «Техно/Про» построена на базе уже упоминавшейся СУБД Microsoft Access. Информация об этом мощном приложении изложена в специальной литературе и требует отдельного изучения, что не входит в рамки данной дисциплины. Отметим только, что физическое представление данных на диске в данной СУБД организуется в виде одного общего файла, файла базы данных, который имеет расширение .mdb.