Заключение.

Давайте еще раз обратимся к рис.1. На нем приведены три уровня абстрагирования данных. Здесь были рассмотрены правила построения двух из них – концептуальной модели данных и физической модели, причем большая часть изложенного материала была посвящена концептуальному представлению данных. Почему же именно этому уровню, изображенному на схеме в середине, уделено такое внимание?

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

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

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

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

Наконец, сама предметная область с течением времени может изменяться под влиянием каких – либо внешних обстоятельств.

В полностью нормализованной модели данных внесение изменений сведется к добавлению новых атрибутов в уже имеющиеся отношения, либо добавлению к базе данных новых отношений. Существенно, что при этом не будут изменяться внешние представления для уже созданных приложений, а значит – не возникает необходимости изменения имеющихся приложений. Если же БД не полностью нормализована, а аномалии обработки данных разрешаются на уровне приложений, то изменение модели данных может повлечь за собой возникновение новых аномалий, что означает переделку всех приложений, причем в сторону усложнения.

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

2 Этот прием, хотя и широко применяется в проектировании БД, был известен задолго до появления первых компьютеров. Те же табельные марки работников применяются как минимум с XIX века.

3 Время поиска увеличивается при увеличении объема таблицы, хотя эта зависимость имеет нелинейный характер.

4 Читатели, знакомые с основами ООП могли заметить, что приведенное определение почти совпадает с определением класса, принятом в объектно – ориентированном проектировании.

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

6 Подробнее вопросы целостности данных будут рассмотрены ниже.

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

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