Использование дополнительных характеристик концептуальной модели

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

Характеристики «число объектов», «рост числа объектов», «ле­тучесть» могут быть использованы для управления размещением дан­ных на носителе, выбора методов организации данных и доступа к ним, определения объемных характеристик БД (что относится к ста­дии физического проектирования БД). Эти характеристики также могут быть приняты во внимание при решении вопросов о целе­сообразности разбиения файла на несколько самостоятельных файлов.

«Класс членства» объектов в связи оказывает влияние не только на выбор варианта построения логической структуры, но и на задание ограничений целостности. (Более подробно об этом см. в главе 4.)

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

Дополнительные рекомендации по проектированию бд

Реляционная база данных, полученная в результате использова­ния предложенного выше алгоритма проектирования, является нор­мализованной и автоматически находится в четвертой нормальной форме (4 НФ).

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

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

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

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

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

Несмотря на очевидные недостатки горизонтального разбиения, к такому приему довольно часто прибегают в практике проектирова­ния. Чем это бывает вызвано? Во-первых, горизонтальное разбиение может обеспечить сокращение времени обработки данных, в том числе и за счет распараллеливания выполнения операций. Так, выполнение операций селекции и проекции над горизонтальными сечениями эк­вивалентно выполнению этих операций над всем отношением, и они могут осуществляться параллельно. При этом общее требуемое вре­мя выполнения запроса будет меньше, чем t / p, где t - время выполне­ния запроса над всем отношением; р - число доступных процессо­ров, так как время еще может сократиться и за счет работы с более короткими файлами.

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

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

Горизонтальное разбиение отношения может проводиться по раз­ным принципам. В качестве условия разбиения может использовать­ся значение какого-либо атрибута (как, например, в рассмотренном выше примере - значение атрибута ФАКУЛЬТЕТ). Довольно часто используется разбиение по временному признаку, например данные за каждый месяц хранятся в отдельном файле. Могут использоваться и другие принципы разбиения: по достижению определенного объе­ма файла, по активности записей и т.д.