Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Диго С.М. Базы данных проектирование и использование.doc
Скачиваний:
723
Добавлен:
14.05.2016
Размер:
12.04 Mб
Скачать

3.1.4. Определение состава базы данных

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

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

Такой подход имеет очевидные достоинства:

1) простота и однозначность в принятии решения «что хранить»;

2)отсутствие неявного дублирования информации со всеми вы­текающими из этого последствиями (меньше объем памяти, чем при хранении как исходных, так и производных показателей; проще про­блемы контроля целостности данных);

3) потенциальная возможность получить любой расчетный пока­затель, а не только те, которые хранятся в БД.

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

Рассмотрим некоторую гипотетическую предметную область, представляющую собой учебное заведение. Учащимся этого заведе­ния начисляется стипендия. Существует четкий алгоритм начисления стипендии. Предположим, что он выглядит следующим образом.

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

2. Известен размер обычной стипендии.

3. Тем, кто не имеет удовлетворительных оценок, назначается сти­пендия на 25% выше, чем обычная.

4. Тем, кто имеет только отличные оценки, стипендия увеличива­ется на 50% от размера обычной стипендии.

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

а) полученная величина многократно используется в дальнейшем;

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

в) размер стипендии не должен изменяться в течение семестра. Кроме того, имея реальный файл «Начисленная стипендия», легче контролировать его полноту и достоверность.

Предположим также, что к БД достаточно часто обращаются с запросом о среднем балле какого-либо студента или среднем балле по той или иной дисциплине и т.п.

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